Patent Description:
The following description relates to a distributed quantum computing system, and in particular to handling user requests to access distributed quantum computing resources.

Quantum computers can perform computational tasks by executing quantum algorithms. Quantum algorithms are often expressed in terms of quantum logic operations applied to qubits. A variety of physical systems have been developed for quantum computing applications. Examples include superconducting circuits, trapped ions, spin systems and others.

<CIT> discloses a computer program product for use in conjunction with a computer system, the computer program product comprising a computer readable medium and a computer program mechanism embedded therein. The computer program mechanism comprises a quantum computing integrated development environment (QC-IDE module and a compiler module). The QC-IDE module is used to design a quantum logic for a plurality of qubits. <CIT> discloses computation systems computational systems that implement problem solving using heuristic solvers or optimizers. Such may iteratively evaluate a result of processing and modify the problem or representation thereof before repeating processing on the modified problem, until a terminal condition is reached. <CIT> discloses methods, systems and media for allowing access to quantum computers in a distributed computing environment (e.g., the cloud). Systems provided therein include user interfaces that enable users to perform data analysis in a distributed computing environment while taking advantage of quantum technology in the backend. <CIT> discloses an approach for managing the provisioning and utilization of resources. A management platform determines a request from a user for execution of one or more data processing tasks by a remote computing device. The management platform also processes and/or facilitates a processing of at least one execution constraint associated with the user, a group associated with the user, or a combination thereof to determine maximum number of clusters, cluster instances, or a combination thereof of the remote computing service to be provisioned for filling the request.

The present invention comprises a computer-implemented method of a server, a server and a computer-readable storage medium as defined in the claims. Examples that do not fall within the scope of the claims are to be interpreted as useful for understanding the invention.

<FIG> is a block diagram of an example computing system. The example computing system <NUM> shown in <FIG> includes a computing environment <NUM> and access nodes 110A, 110B, 110C. A computing system may include additional or different features, and the components of a computing system may operate as described with respect to <FIG> or in another manner.

The example computing environment <NUM> includes computing resources and exposes their functionality to the access nodes 110A, 110B, 110C (referred to collectively as "access nodes <NUM>"). The computing environment <NUM> shown in <FIG> includes a server <NUM>, quantum processor units 103A, 103B and other computing resources <NUM>. The computing environment <NUM> may also include one or more of the access nodes (e.g., the example access node 110A) and other features and components. A computing environment may include additional or different features, and the components of a computing environment may operate as described with respect to <FIG> or in another manner.

The example computing environment <NUM> can provide services to the access nodes <NUM>, for example, as a cloud-based or remote-accessed computer, as a distributed computing resource, as a supercomputer or another type of high-performance computing resource, or in another manner. The computing environment <NUM> or the access nodes <NUM> may also have access to one or more remote QPUs (e.g., QPU 103C). As shown in <FIG>, to access computing resources of the computing environment <NUM>, the access nodes <NUM> send programs <NUM> to the server <NUM> and in response, the access nodes <NUM> receive data <NUM> from the server <NUM>. The access nodes <NUM> may access services of the computing environment <NUM> in another manner, and the server <NUM> or other components of the computing environment <NUM> may expose computing resources in another manner.

Any of the access nodes <NUM> can operate local to, or remote from, the server <NUM> or other components of the computing environment <NUM>. In the example shown in <FIG>, the access node 110A has a local data connection to the server <NUM> and communicates directly with the server <NUM> through the local data connection. The local data connection can be implemented, for instance, as a wireless Local Area Network, an Ethernet connection, or another type of wired or wireless connection. Or in some cases, a local access node can be integrated with the server <NUM> or other components of the computing environment <NUM>. Generally, the computing system <NUM> can include any number of local access nodes.

In the example shown in <FIG>, the access nodes 110B, 110C and the QPU 103C each have a remote data connection to the server <NUM>, and each communicates with the server <NUM> through the remote data connection. The remote data connection in <FIG> is provided by a wide area network <NUM>, such as, for example, the Internet or another type of wide area communication network. In some cases, remote access nodes use another type of remote data connection (e.g., satellite-based connections, a cellular network, a private network, etc.) to access the server <NUM>. Generally, the computing system <NUM> can include any number of remote access nodes.

The example server <NUM> shown in <FIG> communicates with the access nodes <NUM> and the computing resources in the computing environment <NUM>. For example, the server <NUM> can delegate computational tasks to the quantum processor units 103A, 103B and the other computing resources <NUM>, and the server <NUM> can receive the output data from the computational tasks performed by the quantum processor units 103A, 103B and the other computing resources <NUM>. In some implementations, the server <NUM> includes a personal computing device, a computer cluster, one or more servers, databases, networks, or other types of classical or quantum computing equipment The server <NUM> may include additional or different features, and may operate as described with respect to <FIG> or in another manner.

Each of the example quantum processor units 103A, 103B operates as a quantum computing resource in the computing environment <NUM>. The other computing resources <NUM> may include additional quantum computing resources (e.g., quantum processor units, quantum virtual machines (QVMs) or quantum simulators) as well as classical (non-quantum) computing resources such as, for example, digital microprocessors, specialized co-processor units (e.g., graphics processing units (GPUs), cryptographic co-processors, etc.), special purpose logic circuitry (e.g., field programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), etc.), systems-on-chips (SoCs), etc., or combinations of these and other types of computing modules.

In some implementations, the server <NUM> generates computing jobs, identifies an appropriate computing resource (e.g., a QPU or QVM) in the computing environment <NUM> to execute the computing job, and sends the computing job to the identified resource for execution. For example, the server <NUM> may send a computing job to the quantum processor unit 103A, the quantum processor unit 103B or any of the other computing resources <NUM>. A computing job can be formatted, for example, as a computer program, function, code or other type of computer instruction set. Each computing job includes instructions that, when executed by an appropriate computing resource, perform a computational task and generate output data based on input data. For example, a computing job can include instructions formatted for a quantum processor unit, a quantum virtual machine, a digital microprocessor, co-processor or other classical data processing apparatus, or another type of computing resource.

In some implementations, the server <NUM> operates as a host system for the computing environment <NUM>. For example, the access nodes <NUM> may send programs <NUM> to server <NUM> for execution in the computing environment <NUM>. The server <NUM> can store the programs <NUM> in a program queue, generate one or more computing jobs for executing the programs <NUM>, generate a schedule for the computing jobs, allocate computing resources in the computing environment <NUM> according to the schedule, and delegate the computing jobs to the allocated computing resources. The server <NUM> can receive, from each computing resource, output data from the execution of each computing job. Based on the output data, the server <NUM> may generate additional computing jobs, generate data <NUM> that is provided back to an access node <NUM>, or perform another type of action.

In some implementations, all or part of the computing environment <NUM> operates as a cloud-based quantum computing (QC) environment, and the server <NUM> operates as a host system for the cloud-based QC environment. For example, the programs <NUM> can be formatted as quantum computing programs for execution by one or more quantum processor units. The server <NUM> can allocate quantum computing resources (e.g., one or more QPUs, one or more quantum virtual machines, etc.) in the cloud-based QC environment according to the schedule, and delegate quantum computing jobs to the allocated quantum computing resources for execution.

In some implementations, all or part of the computing environment <NUM> operates as a hybrid computing environment, and the server <NUM> operates as a host system for the hybrid environment. For example, the programs <NUM> can be formatted as hybrid computing programs, which include instructions for execution by one or more quantum processor units and instructions that can be executed by another type of computing resource. The server <NUM> can allocate quantum computing resources (e.g., one or more QPUs, one or more quantum virtual machines, etc.) and other computing resources in the hybrid computing environment according to the schedule, and delegate computing jobs to the allocated computing resources for execution. The other (non-quantum) computing resources in the hybrid environment may include, for example, one or more digital microprocessors, one or more specialized co-processor units (e.g., graphics processing units (GPUs), cryptographic co-processors, etc.), special purpose logic circuitry (e.g., field programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), etc.), systems-on-chips (SoCs), or other types of computing modules.

The server <NUM> selects the type of computing resource (e.g., quantum or otherwise) to execute an individual computing job in the computing environment <NUM>. For example, the server <NUM> may select a particular quantum processor unit (QPU) or other computing resource based on availability of the resource, speed of the resource, information or state capacity of the resource, a performance metric (e.g., process fidelity) of the resource, or based on a combination of these and other factors. In some cases, the server <NUM> can perform load balancing, resource testing and calibration, and other types of operations to improve or optimize computing performance.

The example server <NUM> shown in <FIG> may include a quantum machine instruction library or other resources that the server <NUM> uses to produce quantum computing jobs to be executed by quantum computing resources in the computing environment <NUM> (e.g., by the quantum processor unit <NUM>). The quantum machine instruction library may include, for example, calibration procedures, hardware tests, quantum algorithms, quantum gates, etc. The quantum machine instruction library can include a file structure, naming convention, or other system that allows the resources in the quantum machine instruction library to be invoked by the programs <NUM>. For instance, the server <NUM> or the computing environment <NUM> can expose the quantum machine instruction library to the access nodes <NUM> through a set of application programming interfaces (APIs). Accordingly, the programs <NUM> that are produced by the access nodes <NUM> and delivered to the server <NUM> may include information that invokes a quantum machine instruction library stored at the server <NUM>. In some implementations, one or more of the access nodes <NUM> includes a local version of a quantum machine instruction library. Accordingly, the programs <NUM> that are produced by the access node 110B and delivered to the server <NUM> may include instruction sets from a quantum machine instruction library.

Each of the example quantum processor units 103A, 103B shown in <FIG> can perform quantum computational tasks by executing quantum machine instructions. In some implementations, a quantum processor unit can perform quantum computation by storing and manipulating information within quantum states of a composite quantum system. For example, qubits (i.e., quantum bits) can be stored in and represented by an effective two-level sub-manifold of a quantum coherent physical system. In some instances, quantum logic can be executed in a manner that allows large-scale entanglement within the quantum system. Control signals can manipulate the quantum states of individual qubits and the joint states of multiple qubits. In some instances, information can be read out from the composite quantum system by measuring the quantum states of the qubits. In some implementations, the quantum states of the qubits are read out by measuring the transmitted or reflected signal from auxiliary quantum devices that are coupled to individual qubits.

In some implementations, a quantum processor unit (e.g., QPU 103A or QPU 103B) can operate using gate-based models for quantum computing. For example, the qubits can be initialized in an initial state, and a quantum logic circuit comprised of a series of quantum logic gates can be applied to transform the qubits and extract measurements representing the output of the quantum computation. In some implementations, a quantum processor unit (e.g., QPU 103A or QPU 103B) can operate using adiabatic or annealing models for quantum computing. For instance, the qubits can be initialized in an initial state, and the controlling Hamiltonian can be transformed adiabatically by adjusting control parameters to another state that can be measured to obtain an output of the quantum computation.

In some models, fault-tolerance can be achieved by applying a set of high-fidelity control and measurement operations to the qubits. For example, quantum error correcting schemes can be deployed to achieve fault-tolerant quantum computation, or other computational regimes may be used. Pairs of qubits can be addressed, for example, with two-qubit logic operations that are capable of generating entanglement, independent of other pairs of qubits. In some implementations, more than two qubits can be addressed, for example, with multi-qubit quantum logic operations capable of generating multi-qubit entanglement. In some implementations, the quantum processor unit 103A is constructed and operated according to a scalable quantum computing architecture. For example, in some cases, the architecture can be scaled to a large number of qubits to achieve large-scale general purpose coherent quantum computing.

The example quantum processor unit 103A shown in <FIG> includes controllers 106A, signal hardware 104A, and a quantum processor cell 102A; similarly the example quantum processor unit 103B shown in <FIG> includes controllers 106B, signal hardware 104B, and a quantum processor cell 102B. A quantum processor unit may include additional or different features, and the components of a quantum processor unit may operate as described with respect to <FIG> or in another manner.

In some instances, all or part of the quantum processor cell 102A functions as a quantum processor, a quantum memory, or another type of subsystem. In some examples, the quantum processor cell 102A includes a quantum circuit system. The quantum circuit system may include qubit devices, resonator devices and possibly other devices that are used to store and process quantum information. In some cases, the quantum processor cell 102A includes a superconducting circuit, and the qubit devices are implemented as circuit devices that include Josephson junctions, for example, in superconducting quantum interference device (SQUID) loops or other arrangements, and are controlled by radio-frequency signals, microwave signals, and bias signals delivered to the quantum processor cell 102A. In some cases, the quantum processor cell 102A includes an ion trap system, and the qubit devices are implemented as trapped ions controlled by optical signals delivered to the quantum processor cell 102A. In some cases, the quantum processor cell 102A includes a spin system, and the qubit devices are implemented as nuclear or electron spins controlled by microwave or radio-frequency signals delivered to the quantum processor cell 102A. The quantum processor cell 102A may be implemented based on another physical modality of quantum computing.

In some implementations, the example quantum processor cell 102A can process quantum information by applying control signals to the qubits in the quantum processor cell 102A. The control signals can be configured to encode information in the qubits, to process the information by performing quantum logic gates or other types of operations, or to extract information from the qubits. In some examples, the operations can be expressed as single-qubit logic gates, two-qubit logic gates, or other types of quantum logic gates that operate on one or more qubits. A sequence of quantum logic operations can be applied to the qubits to perform a quantum algorithm. The quantum algorithm may correspond to a computational task, a hardware test, a quantum error correction procedure, a quantum state distillation procedure, or a combination of these and other types of operations.

The example signal hardware 104A includes components that communicate with the quantum processor cell 102A. The signal hardware 104A may include, for example, waveform generators, amplifiers, digitizers, high-frequency sources, DC sources, AC sources and other type of components. The signal hardware may include additional or different features and components. In the example shown, components of the signal hardware 104A are adapted to interact with the quantum processor cell 102A. For example, the signal hardware 104A can be configured to operate in a particular frequency range, configured to generate and process signals in a particular format, or the hardware may be adapted in another manner.

In some instances, one or more components of the signal hardware 104A generate control signals, for example, based on control information from the controllers 106A. The control signals can be delivered to the quantum processor cell 102A to operate the quantum processor unit 103A. For instance, the signal hardware 104A may generate signals to implement quantum logic operations, readout operations or other types of operations. As an example, the signal hardware 104A may include arbitrary waveform generators (AWGs) that generate electromagnetic waveforms (e.g., microwave or radio-frequency) or laser systems that generate optical waveforms. The waveforms or other types of signals generated by the signal hardware 104A can be delivered to devices in the quantum processor cell 102A to operate qubit devices, readout devices, bias devices, coupler devices or other types of components in the quantum processor cell 102A.

In some instances, the signal hardware 104A receives and processes signals from the quantum processor cell 102A. The received signals can be generated by operation of the quantum processor unit 103A. For instance, the signal hardware 104A may receive signals from the devices in the quantum processor cell 102A in response to readout or other operations performed by the quantum processor cell 102A. Signals received from the quantum processor cell 102A can be mixed, digitized, filtered, or otherwise processed by the signal hardware 104A to extract information, and the information extracted can be provided to the controllers 106A or handled in another manner. In some examples, the signal hardware 104A may include a digitizer that digitizes electromagnetic waveforms (e.g., microwave or radio-frequency) or optical signals, and a digitized waveform can be delivered to the controllers 106A or to other signal hardware components. In some instances, the controllers 106A process the information from the signal hardware 104A and provide feedback to the signal hardware 104A; based on the feedback, the signal hardware 104A can in turn generate new control signals that are delivered to the quantum processor cell 102A.

In some implementations, the signal hardware 104A includes signal delivery hardware that interface with the quantum processor cell 102A. For example, the signal hardware 104A may include filters, attenuators, directional couplers, multiplexers, diplexers, bias components, signal channels, isolators, amplifiers, power dividers and other types of components. In some instances, the signal delivery hardware performs preprocessing, signal conditioning, or other operations to the control signals to be delivered to the quantum processor cell 102A. In some instances, signal delivery hardware performs preprocessing, signal conditioning or other operations on readout signals received from the quantum processor cell 102A.

The example controllers 106A communicate with the signal hardware 104A to control operation of the quantum processor unit 103A. The controllers 106A may include digital computing hardware that directly interface with components of the signal hardware 104A. The example controllers 106A may include processors, memory, clocks and other types of systems or subsystems. The processors may include one or more single- or multicore microprocessors, digital electronic controllers, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit), or other types of data processing apparatus. The memory may include any type of volatile or non-volatile memory, a digital or quantum memory, or another type of computer storage medium. The controllers 106A may include additional or different features and components.

In some implementations, the controllers 106A include memory or other components that store quantum state information, for example, based on qubit readout operations performed by the quantum processor unit 103A. For instance, the states of one or more qubits in the quantum processor cell 102A can be measured by qubit readout operations, and the measured state information can be stored in a cache or other type of memory system in or more of the controllers 106A. In some cases, the measured state information is used in the execution of a quantum algorithm, a quantum error correction procedure, a quantum processor unit (QPU) calibration or testing procedure, or another type of quantum process.

In some implementations, the controllers 106A include memory or other components that store quantum machine instructions, for example, representing a quantum program for execution by the quantum processor unit 103A. In some cases, the quantum machine instructions are received from the server 108A in a hardwareindependent format. For example, quantum machine instructions may be provided in a quantum instruction language such as Quil, described in the publication "<NPL>, or another quantum instruction language. For instance, the quantum machine instructions may be written in a format that can be executed by broad range of quantum processor units or quantum virtual machines.

In some instances, the controllers 106A can interpret the quantum machine instructions and generate a hardware-specific control sequences configured to execute the operations proscribed by the quantum machine instructions. For example, the controllers 106A may generate control information that is delivered to the signal hardware 104A and converted to control signals that control the quantum processor cell 102A.

In some implementations, the controllers 106A include one or more clocks that control the timing of operations. For example, operations performed by the controllers 106A may be scheduled for execution over a series of clock cycles, and clock signals from one or more clocks can be used to control the relative timing of each operation or groups of operations. In some cases, the controllers 106A schedule control operations according to quantum machine instructions in a quantum computing program, and the control information is delivered to the signal hardware 104A according to the schedule in response to clock signals from a clock or other timing system.

In some implementations, the controllers 106A include processors or other components that execute computer program instructions (e.g., instructions formatted as software, firmware, or otherwise). For example, the controllers 106A may execute a quantum processor unit (QPU) driver software, which may include machine code compiled from any type of programming language (e.g., Python, C++, etc.) or instructions in another format. In some cases, QPU driver software receives quantum machine instructions (e.g., based on information from the server <NUM>) and quantum state information (e.g., based on information from the signal hardware 104A), and generates control sequences for the quantum processor unit 103A based on the quantum machine instructions and quantum state information.

In some instances, the controllers 106A generate control information (e.g., a digital waveform) that is delivered to the signal hardware 104A and converted to control signals (e.g., analog waveforms) for delivery to the quantum processor cell 102A. The digital control information can be generated based on quantum machine instructions, for example, to execute quantum logic operations, readout operations, or other types of control.

In some instances, the controllers 106A extract qubit state information from qubit readout signals, for example, to identify the quantum states of qubits in the quantum processor cell 102A or for other purposes. For example, the controllers may receive the qubit readout signals (e.g., in the form of analog waveforms) from the signal hardware 104A, digitize the qubit readout signals, and extract qubit state information from the digitized signals.

The other QPU 103B and its components (e.g., the quantum processor cell 102B, the signal hardware 104B and controllers 106B) can be implemented, and in some instances operate, as described above with respect to the QPU 103A; in some cases, the QPU 103B and its components may be implemented or may operate in another manner. Similarly, the remote QPU 103C and its components can be implemented, and in some instances operate, in analogous manner.

<FIG> is a block diagram of example computing system <NUM>. Example computing system <NUM> comprises an example server <NUM> and one or more example QPUs <NUM>. Example server <NUM> may be, e.g. server <NUM> described in <FIG>. The one or more example QPUs <NUM> may be, e.g. a QPU 103A, 103B, 103C described in <FIG>. Server <NUM> manages job requests from one or more users that wish to access a QPU <NUM>. Server <NUM> includes a gateway module <NUM>, a user database memory module <NUM>, a job server <NUM>, a queueing module <NUM>, a compiler module <NUM>, a QPU queueing module <NUM>, a quantum virtual machine (QVM) queueing module <NUM>, a QVM <NUM>, a result queueing module <NUM>, an archive worker <NUM>, and an archive module <NUM>. Example server <NUM> and example QPU <NUM> may include additional or different features, and the components of server <NUM> and QPU <NUM> may operate as described with respect to <FIG> or in another manner. The modules of server <NUM> may be software modules stored in a memory, e.g. a computer-readable storage medium. The software modules may comprise computer instructions which may be executed by one or more processors of server <NUM>.

Gateway module <NUM> is configured with an interface for receiving asynchronous job requests from multiple local or remote users, e.g. an access nodes <NUM>, via a corresponding local or remote connections over a network, as described for computing system <NUM> described in <FIG>. In some cases, the user requests are requests for access to quantum computing resources. In an implementation, users that submit job requests may be disparate and may have different goals when submitting a job request. After submitting a job request, a user does not have to remain connected. For example, the user may establish a temporary connection to gateway module <NUM> via the interface to submit a new job request, or request status or results of a previously requested job, and may disconnect after completing the request. A job request includes a user id. In some cases, the user request may include an indication of what resource the user is requesting to use, e.g. QVM or QPU. The job request may also include a program received from the user, e.g. programs <NUM> described in <FIG>. In some cases, not forming part of the invention, the program may be a compiled program. In other cases, according to the invention, the program may be an uncompiled computer program. For example, a user may submit a job request to have the uncompiled computer program executed. In some cases, the program may be in a quantum instruction language, such as Quil. The gateway module <NUM> may provide a first level of user authorization when a job request is received from a user. In an implementation, the interface of gateway module <NUM> may be an application programming interface (API). For example, the API may receive job requests via the Hypertext Transfer Protocol (HTTP). In some cases, the API interface requires an API key for access by a user. Gateway module <NUM> may reject a job request is it fails authentication at the interface. If the user is authenticated, gateway module <NUM> forwards the job request to job server <NUM>.

In some implementations, a user may query gateway module <NUM> for status of a previously submitted job request. For example, a user may inquire if a particular job has completed. A job identifier (also referred to as a job id) may be assigned by job server <NUM>, as described below, and provided back to gateway module <NUM> to be used as a reference for the job request. In some cases, the gateway module <NUM> provides the job id to the user which may be used by the user as a reference number to check on the status of the job. When the user receives the job id from gateway module <NUM>, it may release the connection to the gateway module. Later, the user may make status inquiry of the job request to gateway module <NUM> and include the job id in the status inquiry. Gateway module <NUM> may forward the status inquiry to the job server <NUM> for processing.

Job server <NUM> is connected to gateway module <NUM> and receives the job request from gateway module <NUM>. In some implementations, job server <NUM> authenticates the user, receives the program from the user request, and in some cases, individualizes the user request based on the user. Job server <NUM> is also connected to a memory module comprising a user database <NUM>. In some cases, job server <NUM> accesses user database <NUM> to verify the user's credentials. In some cases, this may be a primary authorization of the user or may be secondary to an authorization performed by gateway module <NUM>. On authorization of the user, job server <NUM> may assign a job id to the job request. In some cases, job server <NUM> may provide the assigned job id to gateway module <NUM>, and gateway module <NUM> may provide the job id to the user associated with the job request. In an example, the gateway module <NUM> may use the assigned job id to process queries from the user regarding a requested job, e.g. in order to provide status and/or results to the user. In some cases, job server <NUM> may store the incoming job request from the user in user database <NUM>. The job server <NUM> may also store the assigned job id associated with the job request in database <NUM>. In an implementation, the job server <NUM> pushes the program to queueing module <NUM>. In some instances, job server <NUM> may push relevant user information with the program to queueing module <NUM>. Relevant user information may include user preferences and permissions associated with the requested quantum computing resource, e.g. QPU <NUM> or QVM <NUM>. In one implementation, a user may have a preference, e.g. a user's choice, of using QPU <NUM> or QVM <NUM> for running a job. In some cases, the user may not have a preference in which case, job server <NUM> may select either QPU <NUM> or QVM <NUM> for processing the user's job request. The user's choice may be indicated in the job request or stored in database <NUM> and retrieved by job server <NUM> while processing a job request. Relevant user information may also include user permissions, such as, permissions associated with a user's subscription, permissions for running a job on a QPU <NUM> or QVM <NUM>, permissions providing access to a particular sized qubit array of QPU <NUM> or QVM <NUM>, particular run time limits for the user, computer memory limits of the user, a dedicated time window for the user, etc. In some cases, the relevant user information is stored in user database <NUM> and obtained by job server <NUM> on a per job request basis. For example, job server <NUM> may retrieve user information from user database <NUM> using the user id received in the user request. In cases in which job server <NUM> makes selections for a particular user's job request, job server <NUM> may update the user database <NUM> and/or the job request with the selections. In some cases, before forwarding the job request for processing, job server <NUM> may determine on which quantum computing resources the job should be executed, e.g. QPU <NUM> or QVM <NUM>. This information, if applicable, as well as other relevant user information is associated with the job request. The job server <NUM> pushes the program to a queue, e.g. queueing module <NUM>, for further processing.

2B illustrates an alternative configuration that includes an authorization gateway module 210B, user database 215B and job server 220B. In this configuration, the functionality is similar to that as described for <FIG>, except the authorization gateway module 210B is connected to the user database 215B rather than the job server 220B being connected to the user database. In this implementation, the authorization gateway module 210B accesses user database 215B to verify the user's credentials and to perform authorization of the user. The authorization gateway module 210B may also obtain relevant user information, such as the information described above, from user database 215B. In that case, authorization gateway module 210B provides the job request and relevant user information to the job server 220B, and job server 220B pushes the program and, in some cases, relevant user information to a queue, e.g. queueing module <NUM>.

Queueing module <NUM> is connected to the job server <NUM>. In an implementation, queueing module <NUM> receives the program, via the connection, from job server <NUM> on authentication of the user. In an example, job server <NUM> pushes the program to queueing module <NUM>, and program is queued in the queueing module <NUM> to await compilation. In some cases, relevant user information associated with the job request is also pushed by the job server <NUM> with the program at queueing module <NUM>. The term "push" is used throughout to describe a process by which information, e.g. a program, output data, user information, etc., is sent, provided, and/or written to a queue. The term "pull" is used throughout to describe a process by which information, e.g. a program, output data, user information, etc. is retrieved, obtained, and/or read from a queue. A polling process may be performed to first check if any information is in the queue before performing a pull operation.

Compiler module <NUM> is connected to the queueing module <NUM>. In some implementations, compiler module <NUM> may communicate with the queueing module <NUM> via the connection, e.g. to make queries and/or to retrieve programs awaiting compilation. In an implementation, compiler module <NUM> pulls a program, which in some cases includes the relevant user information associated with the program, from queueing module <NUM>. Compiler module <NUM> polls the queueing module <NUM> to determine if a program has been queued before retrieving, e. g pulling, the program. After pulling the program, compiler module <NUM> compiles the uncompiled program into a schedule of instructions. The schedule of instructions may be native control instructions. In some implementations, compiler module <NUM> compiles for a certain QPU <NUM> or QVM <NUM>. In some cases, the uncompiled program is compiled according to the relevant user information, e.g. user's choice of QPU <NUM> or QVM <NUM>. In some cases, the compiler module <NUM> is connected to a calibration data memory module 1060A in the QPU <NUM>. Compiler module <NUM> pulls calibration information specific to a quantum processor 1020A from the calibration database on the memory module 1060A, and the calibration data is used in program compilation. In this instance, calibration of the QPU is handled as a job in the queue, rather than, for instance, shutting the system down for calibration. In some cases, the program may already be compiled, and thus, the compiler module does not need to generate a schedule of instructions. In that case, the compiler skips the compilation process.

In some instances, the compiler module <NUM> directs the schedule of instructions to one of the QPU <NUM> and the QVM <NUM> based on a user's request for processing on the QPU <NUM> or QVM <NUM>. In some cases, the user's request for processing is received with the program. In other cases, the compiler module <NUM> directs the schedule of instructions to one of the QPU <NUM> and the QVM <NUM> according to other instruction or criteria. For example, the compiler module <NUM> may direct the schedule of instructions based on a determination of a run-time of the schedule of instructions on the QPU <NUM> and the QVM <NUM>. In some cases, the compiler module <NUM> may direct the schedule of instructions to either the QPU <NUM> or the QVM <NUM> depending on which has the shorter run time for the schedule of instructions. In other cases, the compiler may send the schedule of instructions to both the QPU <NUM> and the QVM <NUM>. The compiler module <NUM> directs the schedule of instructions to the QPU <NUM> and/or QVM <NUM> by pushing the schedule of instructions to a queue corresponding to the QPU <NUM> and/or a queue corresponding to the QPU <NUM>.

Compiler module <NUM>, as described above, directs the schedule of instructions according to whether the program is to be executed on the QPU <NUM> or QVM <NUM>, or in some cases, both, e.g. based on the user's request as described above. A QPU queueing module <NUM> is connected to the compiler module <NUM>. In some implementations, compiler module <NUM> pushes the schedule of instructions to the QPU queueing module <NUM>, and the schedule of instructions from the compiler module <NUM> are stored in the QPU queueing module <NUM>, e.g. as an entry in the queue. In some cases, a QVM queueing module <NUM> is connected to the compiler module <NUM>. In one example, compiler module <NUM> pushes the schedule of instructions to the QVM queueing module <NUM>, and the schedule of instructions from the compiler module <NUM> are stored in the QVM queueing module <NUM>, e.g. as an entry in the queue. The schedule of instructions will remain in the QPU queueing module <NUM> until the QPU pulls the job for execution. Similarly, the schedule of instructions will remain in the QVM queueing module <NUM> until the QVM pulls the job for execution. In some implementations, each QPU <NUM> may have a distinct QPU queuing module <NUM>. In some cases, the QPU queueing module <NUM> and/or the QVM queueing module may receive a poll request polling the queue for programs awaiting execution.

In an implementation, QPU <NUM> pulls the schedule of instructions from QPU queueing module <NUM> and executes the schedule of instructions. In some cases, QPU <NUM> polls the QPU queueing module <NUM> to determine if a program has been queued for execution before retrieving, e. g pulling, the program. In some instances, after execution of the program, QPU <NUM> pushes output data to a result queuing module <NUM> via a connection between QPU <NUM> and result queuing module <NUM> on server <NUM>. In another implementation, QVM <NUM> pulls the schedule of instructions from the QVM queueing module <NUM> and executes the schedule of instructions. In some cases, QVM <NUM> polls the QVM queueing module <NUM> to determine if a program has been queued for execution before retrieving, e. g pulling, the program. An example of a QVM is described in "A Practical Quantum Instruction Set Architecture" R. Smith et al. , available at https://arxiv. org/pdf/<NUM>. QVM <NUM> pushes output data to the result queuing module <NUM> via a connection between QVM <NUM> and result queuing module <NUM>, both on server <NUM>. As shown in <FIG>, in certain implementations, the result queueing module <NUM> may be connected to QPU <NUM>, to QVM <NUM> in server <NUM>, or to both.

Output data pushed to the results queueing module <NUM> from a QPU <NUM> and/or QVM <NUM> is stored in the results queueing module <NUM> until pulled by an archive worker <NUM> that is connected to the result queuing module <NUM>. For example, the archive worker <NUM> pulls output data, which includes execution results, from the result queuing module <NUM> and stores the output data at archive module <NUM>. In some cases, the archive worker <NUM> may poll the result queueing module <NUM> to check if output data for a program is available before pulling the output data. Archive module <NUM> is connected to the job server <NUM>. Job server <NUM> pulls the output data from archive module <NUM> and, in some cases, makes the output data available to an authenticated user via gateway module <NUM>. For example, job server <NUM> receives a request from a user, via the interface of gateway module <NUM>, for the results of a particular job id. On authentication of the job id and/or the user, job server <NUM> pulls the output data from archive module <NUM>, and provides the output data associated with the job id to the user through the gateway module <NUM> in FIG. 2B or the authorization gateway module 210B in FIG. In some cases, job server <NUM> may poll archive module <NUM> to check if output data for the job id and/or the user is available before pulling the output data from archive module <NUM>.

In an implementation, QPU <NUM> is connected to server <NUM>, as in <FIG>. In some cases, QPU <NUM> of computer system <NUM> includes: a calibration data memory module 1060A, a classical processing module 1062A, a control module1040A, a quantum processor 1020A, and in some cases, a shared memory 1064A. For example, the calibration data memory module 1060A, classical processing module 1062A, and shared memory 1064A may be, or included in, controllers 106A of QPU <NUM> described in <FIG>. Also, control module 1040A may be, or included in, signal hardware 104A, and quantum processor 1020A may be, or included in, a quantum processor cell 102A of QPU <NUM> also described in <FIG>. In some examples, a quantum processor 1020A may comprise a processor that may be one or more of a trapped ion quantum processor, a quantum gate array processor and a superconducting-material based quantum processor.

As shown in <FIG>, classical processing module1062A is connected to server <NUM> and is also be connected to calibration data memory module module1060A in QPU <NUM>. In an implementation, classical processing module1062A pulls a schedule of instructions from QPU queueing module <NUM> and pulls calibration information specific to quantum processor 1020A from memory module 1060A. Classical processing module 1062A is also connected to control module 1040A. For each event in the schedule of instructions pulled from QPU queueing module <NUM>, classical processing module 1062A generates control signals derived from the schedule of instructions and the calibration information. The control signals are executed on the quantum processor 1020A by the control module 1040A. The control module 1040A returns results from executing the control signals on the quantum processor 1020A to classical processing module 1062A.

In some cases, QPU <NUM> may be configured for asynchronous quantum/classical computation. QPU <NUM> includes a shared memory module 1064A connected to the classical processing module 1062A and the control module 1040A. In asynchronous quantum/classical computation, classical processing module 1062A, or a sub-module thereof, handles the classical part of the computation. For some of these circuit devices, and computing regimes described herein, having the shared memory physically close to the quantum processor, and also in some cases, close to the classical processing module allows optimum performance of the system. For example, classical processing module 1062A is connected to the control module 1040A via shared memory 1064A. In this case, the control signals generated by classical processing module 1062A may be stored in shared memory 1064A, and retrieved by control module <NUM> for execution on quantum processor 1020A. In some cases, the control module 1040A returns results from execution of the control signals on quantum processor 1020A to the classical processing module 1062A via shared memory 1064A. In an implementation, classical processing unit 1062A of QPU <NUM> is connected to the result queueing module <NUM> on the server. Classical processing unit 1062A pushes output data, that includes execution results, from QPU <NUM> onto the result queueing module <NUM> via the connection. In other cases, QPU <NUM> may be configured for hybrid quantum/classical computation. In that scenario, QPU <NUM> includes a shared memory module connected to the classical processing module 1062A and the control module 1040A, and the classical process module 1062A performs the classical part of the computation, as described above.

<FIG> are a flow diagrams showing example processes 300A, 300B of operating a computer system. The example processes 300A, 300B can be performed, for example, by a computer system that receives and handles job requests from users that do not have access to quantum computing resources. Operations in the processes 300A, 300B are performed by the server <NUM> in the example communication system <NUM> shown in <FIG>, or in another type of communication system. The example processes 300A, 300B may exchange information with other processes performed by server <NUM> or by a quantum computing processor, e.g. QPU <NUM>. The example processes 300A, 300B may include additional or different operations, and the operations may be performed in the order shown or in another order. In some cases, one or more of the operations shown in <FIG> are implemented as processes that include multiple operations, sub-processes or other types of routines. In some cases, operations can be combined, performed in parallel, iterated or otherwise repeated or performed in another manner. In some examples, the processes 300A, 300B are performed by job server <NUM> of server <NUM> which receives and handles job requests from multiple users that do not have access to quantum computers or other quantum resources.

At <NUM> of process 300A in <FIG>, a job request for accessing a quantum computing resource is received. The job request comprises a user id and a program, e.g. program <NUM>. A quantum computing resource comprises a QPU, e.g. QPU <NUM>, and may further comprise a QVM <NUM>. In some cases, the job request is received from a remote user at a gateway interface, e.g. gateway module <NUM>. Additional job requests may be received asynchronously at the gateway interface from multiple users.

On authorization of a user associated with the job request, the job request is processed. The user may be authenticated based on data in a memory module that includes a user database, e.g. user database <NUM>. At <NUM>, a job identifier is assigned to the job request.

At <NUM>, a particular quantum computing resource is selected for the job request. In some cases, a particular quantum computing resource for the job request is selected based on a user preference. In some cases, the user preference may be a preference for execution of the job on a quantum processing unit (QPU) or a preference for execution of the job on a quantum virtual machine (QVM). In some cases, the user may indicate no preference, or may not indicate a preference, at all. In some instances, the user preference is retrieved from the user database. In other instances, the user preference is received in the job request.

At <NUM>, the job request is individualized based on user permissions. In some cases, user permissions may include one or more of the following: permissions associated with a user's subscription, permissions for running a job on a particular quantum computing resource by the user, permissions providing access to a particular sized qubit array of the quantum computing resources for the user, run time limits of the user, computer memory limits of the user, and a dedicated time window for the user.

At <NUM>, the job request is pushed onto a queue to be processed by the quantum computing resource. The queued job request contains the user information needed by a compiler, e.g. compiler module, to compile an uncompiled program for execution on the quantum computing resource.

<FIG> illustrates process 300B performed, which in one example, may be performed by job server <NUM>, after execution of the program by the quantum computing resource. At <NUM>, output data associated with job request is pulled after execution by the quantum computing resource. In one implementation, output data from execution of the program is received, e.g. pushed, from the quantum computing resource at a result queue. The output data is pulled from the result queue, e.g. by archiver worker <NUM> of server <NUM>, and stored in archive memory, e.g. archive module <NUM>. The output data is pulled, e.g. by job server <NUM>, from the archive memory by job server <NUM>.

At <NUM>, the output data is provided to the user associated with the job request. In an aspect, the job server is able to associate the output data with the job request based on the user id assigned, by the job server <NUM>, when the job request was initially received. The output data may be provided to the user associated with the job request in response to a user query for job status and/or results.

<FIG> is a flow diagram of process <NUM>, which are performed by a compiler, e.g. compiler module <NUM> of server <NUM> on an uncompiled program. At <NUM>, the individualized job request is pulled, by the compiler, from the queue and the program in the job request is compiled into a schedule of instructions according to the selected quantum computing resource. Calibration data is obtained from a calibration database stored at a QPU, e.g. QPU <NUM>, and the calibration data is used in program compilation.

At <NUM>, the compiler pushes the schedule of instructions to a queue associated with the quantum computing resource that was selected, e.g. QPU queueing module <NUM> or QVM queueing module <NUM>. In an implementation, the compiler pushes the schedule of instructions to a queue based on which quantum computing resource has the shorter run time for the schedule of instructions. In other instances, the compiler pushes the schedule of instructions to a quantum processing unit (QPU) queue, to a quantum virtual machine (QVM) queue, or to both a QPU queue and a QVM queue. The schedule of instructions may be stored as an entry in the associated queue when received, e.g. pushed, from the compiler. The queue provides the schedule of instructions to the quantum computing resource associated with the queue. For example, the quantum computing resource pulls the schedule of instructions from the queue associated with the quantum computing resource, and executes the schedule of instructions. For example, QPU <NUM> pulls a schedule of instructions from QPU queueing module <NUM>, whereas QVM <NUM> pulls a schedule of instructions from QVM queueing module <NUM>. In an implementation, the schedule of instructions are pulled from the queue to be processed for execution by a QPU, e.g. QPU <NUM>. The QPU generates control signals for execution on the QPU. The control signals are derived from the schedule of instructions and calibration information. The results from execution of the control signals on the QPU are returned to a result queue, e.g. result queueing module <NUM> on server <NUM>.

Some of the subject matter and operations described in this specification can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Some of the subject matter described in this specification can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions, encoded on a computer storage medium for execution by, or to control the operation of, data-processing apparatus, e.g. server <NUM>. The subject matter described in this specification may be implemented using various types of codes, languages, and systems. A computer storage medium can be, or can be included in, a computer-readable storage device, a computer-readable storage substrate, a random or serial access memory array or device, or a combination of one or more of them.

Some of the operations described in this specification can be implemented as operations performed by a data processing apparatus, e.g. server <NUM>, on data stored on one or more computer-readable storage devices or received from other sources.

The term "data-processing apparatus" encompasses all kinds of apparatus, devices, and machines for processing data, including by way of example a quantum processor, a programmable processor, a computer, a system on a chip, or multiple ones, or combinations, of the foregoing.

A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code).

Processors suitable for the execution of a computer program include, by way of example, quantum processors, general and special purpose microprocessors, and processors of any kind of digital computer. Elements of a computer can include a processor that performs actions in accordance with instructions, and one or more memory devices that store the instructions and data. Moreover, Devices suitable for storing computer program instructions and data include all forms of non-volatile memory, media and memory devices, including by way of example semiconductor memory devices (e.g., EPROM, EEPROM, flash memory devices, and others), magnetic disks (e.g., internal hard disks, removable disks, and others), magneto optical disks, and CD ROM and DVD-ROM disks. In some cases, the processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.

A computer system may include a single computing device, or multiple computers that operate in proximity or generally remote from each other and typically interact through a communication network. Examples of communication networks include a local area network ("LAN") and a wide area network ("WAN"), an inter-network (e.g., the Internet), a network comprising a satellite link, and peer-to-peer networks (e.g., ad hoc peer-to-peer networks). A relationship of client and server may arise by virtue of computer programs running on the respective computers and having a client-server relationship to each other.

In a general aspect of the examples described, user requests to access distributed a quantum computing resource are managed.

Claim 1:
A method executed by one or more processors of a server (<NUM>) comprising:
receiving (<NUM>) a job request for accessing a quantum computing resource comprising a quantum processing unit (QPU) configured for quantum-classical computation, the job request comprising a user id and a computer program comprising a computer instruction set, wherein the computer program is an uncompiled computer program, and wherein the QPU comprises a quantum processor (1020A) for running quantum parts of a computation, a control module (1040A) for operating the quantum processor, a classical processing module (1062A) for running classical parts of the computation, and a shared memory (1064A) connected to the control module and the classical processing module; and
on authentication of a user associated with the job request, by operation of the one or more processors:
selecting (<NUM>) a particular quantum computing resource for the job request;
individualizing (<NUM>) the job request based on user permissions;
pushing (<NUM>) the job request onto a first queue to be processed for execution by the selected quantum computing resource;
pulling (<NUM>), by a compiler, the job request from the first queue and compiling the computer program in the job request into a schedule of instructions according to the selected particular quantum computing resource;
pushing (<NUM>) the schedule of instructions to a second queue associated with the selected particular quantum computing resource;
providing, by the second queue associated with the selected particular quantum computing resource, the schedule of instructions to the selected particular quantum computing resource;
wherein compiling the computer program in the job request comprises:
obtaining calibration data specific to the quantum processor of the QPU from a calibration database stored at the QPU; and
using the calibration data in compiling the computer program, wherein the calibration data is collected by a calibration routine executed on the QPU, the calibration routine being a job in a queue associated with the QPU.