IBM Patent Application Targets More Efficient Sharing of Quantum Computers

Insider Brief
- An IBM patent application describes a way to run multiple users’ quantum jobs together while reducing the work required for error mitigation.
- The proposed scheduler would group compatible circuits and reuse stored noise models, with checks for available qubits, execution time and user preferences.
- The filing describes potential billing rebates for users who allow sharing but does not report measured improvements in throughput, waiting times or costs.
IBM is seeking patent protection for a method that would let multiple users share a quantum processor while reducing some of the work needed to compensate for errors, potentially allowing providers to get more useful computation from their hardware, according to a newly published patent application.
The application, titled “Quantum Queue Optimization for Error Mitigation,” describes software that examines waiting jobs, identifies programs that can run together and schedules them to reuse previously collected information about the processor’s noise.
The application, which was filed May 5, 2025 and approved on Nov. 5 of this year, addresses two related sources of inefficiency. A user’s program may require only a portion of a processor’s qubits, the basic units of quantum information. Giving that program exclusive access can leave other qubits unused. Meanwhile, error mitigation can require additional experiments to characterize how noise affects the operations being performed.
Simultaneous Operations
Running more jobs at once could improve hardware use, but simultaneous operations can affect one another and change the errors that need to be accounted for. IBM’s approach would consider those errors when deciding which programs to run together.
Some error-mitigation methods require extra measurements to learn how a processor’s noise affects particular groups of operations. Those operations, called quantum gates, are the steps that make up a quantum program.
The application describes storing the resulting information in noise models—descriptions of the errors associated with those operations. The scheduling software would then look for programs that can run together using noise models already available.
For example, two programs might use separate parts of a processor. If their combined operations match a pattern the system has already measured, it could reuse that information instead of repeating the measurements, according to the filing.
The match depends on which connections between qubits are active. A noise model for one set of connections does not automatically apply to a different set, even if fewer connections are being used. The software would check that the combined programs fit the available noise information.
That information also needs to stay current. A quantum processor’s noise changes over time, so the system would update frequently used models and discard outdated ones.
The software could also move a waiting program forward in the queue if doing so lets it use noise information while that information is still valid. This would help avoid repeating measurements simply because a compatible program waited too long to run.
127-Qubit Processor
The application illustrates how programs could share a 127-qubit processor. One program uses 52 qubits and another uses 30. Four unused qubits separate the two groups to help limit crosstalk, in which activity in one part of the chip affects another. Other qubits remain available for additional work.
Before combining programs, the software would check whether there are enough suitable qubits and whether the connections between them meet each program’s needs. It would also account for users’ requirements, such as keeping their programs a certain distance from other activity on the chip.
Timing is another consideration. If one program finishes using its assigned qubits while another continues running elsewhere on the processor, the software could fit additional work into that opening without extending the overall run.
The filing describes several ways to decide when programs can share the machine. Under the strictest option, the system would combine them only when it already has the necessary noise models. Another option would allow it to take additional measurements and save the new models. A third would use existing models to derive the noise information needed for a different pattern of operations.
The system could choose among these options based on how many jobs are waiting, the processor’s available resources, interference between programs and job priorities. The application also describes using machine learning to help decide where programs should run.
Users would have a say in whether and how their programs share the processor. The billing system could offer rebates to encourage participation, according to the application. Once the calculations are complete, the software would separate the results for each job.
The filing identifies interference, the risk of information leaking between users and the difficulty of coordinating different programs as challenges the system must address.
Other researchers are also developing ways to share quantum hardware. The Quantum Insider previously reported on Columbia Engineering’s HyperQ, which was tested on IBM processors. HyperQ uses quantum virtual machines to assign portions of a physical processor to different programs so they can run at the same time.
IBM’s application focuses on coordinating that shared use with the measurements needed for error mitigation. By choosing compatible programs and reusing noise information, the approach aims to reduce repeated preparation work and make more of the processor available for calculations.
The inventors listed on the application, according to Patentlyze, are Ana Paula Appel, Daniel Josef Egger, Kaelyn Jae Ferris, Sanjay Kumar Lalta Prasad Vishwakarma and Razvan Paul Sebastian Brandhofer.

Keep track of everything going on in the Quantum Technology Market. In one place.
Topics
Matt Swayne
Get the latest research, company news, and market intelligence every week.










