Quantum error correction patents: where the invention is

A quantum error correction patent is strongest when its claims cover something a physical machine does: a decoder that meets a real-time deadline, a syndrome-extraction pulse sequence, or a code layout mapped onto a specific qubit lattice. Claims to a code or a decoding rule as pure math tend to hit 35 U.S.C. § 101, the statute that sets what kinds of inventions are eligible for patents.
This article is for quantum hardware and software teams deciding what to file on their error correction work. I explain where the protectable invention usually sits in the QEC stack, why abstract code claims run into trouble, and how to build a claim set that holds up. For the broader question of what is patentable across quantum computing, start with my earlier post, What can you patent in quantum computing? This piece goes one level deeper, into error correction alone.
Key takeaways
- A new code described only by its stabilizers and parameters is a mathematical concept. Claim it alone and expect a § 101 rejection.
- The strongest claims tie the code to hardware: decoder circuits, syndrome-extraction pulse sequences, and layouts mapped to a physical coupler graph.
- Under the USPTO’s current guidance, an improvement to how the machine works can make a math-based claim eligible, if the specification explains the improvement and the claim recites the steps that deliver it.
- Write measured data into the application: latency, logical error rates, qubit counts, cycle times.
- File layered claims (system, method, decoder hardware, layout) so a design-around on one layer does not escape the others.
Where is the invention in a quantum error correction patent?
Quantum error correction spans five layers: the code itself, the decoding algorithm, the decoder hardware, the control operations that measure syndromes, and the layout that places the code on real qubits. The first two are mostly math. The last three are machines and physical processes, and they are where the strongest patent claims usually sit.
A syndrome is the pattern of stabilizer measurement outcomes that tells you an error happened, without measuring the encoded data. A decoder is the classical system that reads syndromes and decides which correction to apply.
| QEC layer | Example | § 101 risk | Typical claim type |
|---|---|---|---|
| Code definition | A new family of stabilizer codes with better rate and distance | High | Rarely claimed alone; recited inside a system claim |
| Decoding algorithm | A faster matching or clustering rule for syndrome graphs | Medium to high | Method claim tied to a quantum processor and timing |
| Decoder hardware | A pipelined FPGA or ASIC decoder with a fixed latency budget | Low | Apparatus and system claims |
| Control and syndrome extraction | A gate schedule or pulse sequence that limits hook errors or leakage | Low | Method of operating a quantum device |
| Physical layout | Mapping a code onto a degree-limited coupler lattice | Low | Device claims; method of fabrication or operation |
Why do pure codes and decoding math run into 35 U.S.C. § 101?
Section 101 covers any new and useful process, machine, manufacture or composition of matter, but courts exclude abstract ideas, laws of nature and natural phenomena. A stabilizer code defined by its check matrix is a mathematical relationship. Claimed alone, examiners will treat it as an abstract idea under the Alice/Mayo framework.
The statute itself is short. 35 U.S.C. § 101 says whoever invents “any new and useful process, machine, manufacture, or composition of matter” may obtain a patent. The exceptions come from case law, and the USPTO applies them through the step-by-step test in MPEP § 2106, the examiners’ manual section on eligibility.
How the USPTO test applies to QEC claims
Step 2A, Prong One asks whether the claim recites a judicial exception. “Mathematical concepts” are one listed grouping, and a code construction or a decoding cost function usually falls inside it. But the MPEP also says a claim that is merely based on or involves math does not necessarily recite a mathematical concept.
Step 2A, Prong Two asks whether the claim as a whole integrates the exception into a practical application. This is where QEC claims are won or lost. An improvement to the functioning of a computer, or to another technology, counts. Step 2B then asks whether the extra elements add an “inventive concept” beyond routine activity.
What changed in 2025 and 2026
Three developments matter for quantum teams. First, an August 4, 2025 USPTO memo on § 101 reminded examiners not to stretch the “mental process” grouping to steps a person cannot practically perform, and to reject only when ineligibility is more likely than not. No human performs syndrome decoding in a microsecond budget.
Second, the Appeals Review Panel’s September 26, 2025 decision in Ex parte Desjardins, designated precedential on November 4, 2025, held machine learning claims eligible because they improved how the model itself operated. The panel warned that “Examiners and panels should not evaluate claims at such a high level of generality,” and said §§ 102, 103 and 112 “are the traditional and appropriate tools to limit patent protection to its proper scope.” The USPTO added the decision to MPEP § 2106 guidance in December 2025.
Third, the courts are less generous than the Office. In Recentive Analytics, Inc. v. Fox Corp. (Fed. Cir. 2025), the court held that claims that “do no more than apply established methods of machine learning to a new data environment” are not eligible. The Supreme Court declined review in December 2025. The lesson carries over: applying a known decoder to a new qubit platform, with no disclosed improvement to the decoder or the machine, is weak. A patent must survive litigation, not just examination.
What makes a strong quantum error correction patent claim?
A strong QEC claim recites concrete physical or timing features that deliver a measurable technical result: lower logical error rates, decoding within a cycle budget, fewer physical qubits per logical qubit, or reduced leakage. These features make the claim eligible and also make it harder to design around.
Decoder hardware
Real-time decoding is a hard engineering problem, not an abstraction. In Google Quantum AI’s below-threshold experiment, later published in Nature (see the arXiv preprint), the team reported a distance-7 surface code on 101 qubits, a 1.1 μs error-correction cycle, and a real-time decoder with an average latency of about 63 μs at distance 5. Numbers like these show why decoder architecture is a technical field in its own right.
Good decoder claims recite structure: how syndrome data streams in, how the decoding graph is partitioned across processing elements, how partial results merge at boundaries, and what latency or throughput the pipeline achieves. A claim to “a decoder configured to apply minimum-weight matching” says little. A claim to a windowed decoder whose processing elements each handle a fixed time slice of the syndrome history, with a defined commit rule for overlapping regions, says much more.
Control pulses and syndrome extraction
The order and shape of gates in a syndrome-extraction circuit decide which physical faults spread into correlated data errors. A gate schedule that keeps “hook” errors from aligning with a logical operator, or a pulse sequence that returns leaked qubits to the computational subspace between rounds, is a method of operating a physical device. Claims like these read naturally as processes performed on hardware.
Recite the physical operations: which couplers fire in which time step, which qubits are reset or measured mid-circuit, and what the controller does with the result. If the invention exploits a property of your platform, such as biased noise in a bosonic qubit or fast neutral-atom shuttling, put that property in a dependent claim.
Code layouts tied to a physical architecture
A code becomes much easier to claim once it is mapped onto real hardware. Many codes assume connectivity that real chips lack. A layout that embeds a code into a degree-limited lattice, routes long-range checks through a specific coupler or bus arrangement, or uses flag qubits to make up for missing connections is a device feature.
This is also where the scientist’s view matters. The useful question is not “is the code new?” but “what does the chip have to look like for this code to work, and what does that buy you?” The answer usually gives you the independent claim. For more on how I approach this work, see my quantum computing patent practice.
How to structure the claim set: a worked example
A layered claim set protects one QEC invention from several directions. Each independent claim targets a different infringer: the chip maker, the controller vendor, the decoder supplier and the operator running the machine. If one claim category fails on eligibility or prior art, the others can still stand.
Suppose a team has built a decoder for a code laid out on a square lattice with a few added long-range couplers. The decoder splits each syndrome round into regions, decodes them in parallel on an FPGA, and keeps latency below the cycle time. Here is how I would map the claims:
- System claim. A quantum computing system comprising the qubit array with the specified coupler arrangement, a control system that performs the syndrome-extraction schedule, and a decoder that returns corrections within a stated number of cycles.
- Decoder apparatus claim. The FPGA or ASIC decoder on its own: the processing elements, the region partitioning, the boundary-merge logic and the memory layout. This reaches a supplier who never builds a qubit.
- Method of operating claim. Applying the gate sequence, measuring ancilla qubits, streaming outcomes to the decoder and applying or tracking corrections. This reaches the operator.
- Device or layout claim. The chip with the coupler arrangement that supports the code. This reaches the hardware maker.
- Dependent claims. Code distance ranges, noise-bias conditions, leakage handling, specific latency figures and fallback behavior when the decoder falls behind.
- Computer-readable medium claim, used with care. Instructions for the decoding method. This is the most exposed to § 101, so it should recite the same hardware ties as the method claim.
Avoid leaning on “means for decoding” language. Under 35 U.S.C. § 112(f), functional “means” language covers only the structures described in the specification and their equivalents. For computer-implemented functions, the USPTO requires a disclosed algorithm, or the claim is indefinite. Section 112(a) also requires a written description showing you possessed what you claim.
How should the specification support eligibility?
The specification has to make the technical improvement visible to a skilled reader, and the claims must include the features that deliver it. USPTO guidance after Desjardins says the improvement need not be stated in so many words, but a bare assertion is not enough. Data and mechanism carry the argument.
In practice, I want four things in a QEC application:
- The bottleneck. What limits prior approaches on real hardware: decoder backlog, connectivity, leakage or measurement time.
- The mechanism. Why your design removes that bottleneck, explained in physical and engineering terms, not only as equations.
- Evidence. Simulated or measured logical error rates, threshold estimates, latency, qubit overhead and resource counts against a baseline.
- Variations. Other code distances, lattices and decoder hardware, so a competitor cannot sidestep a single embodiment.
If an examiner still rejects under § 101, there is now a formal evidence route. A September 29, 2026 USPTO memo on Subject Matter Eligibility Declarations describes optional declarations under 37 CFR 1.132 that offer objective evidence on eligibility. It recommends filing them as early as possible, ideally before the first Office action on the merits, and notes that evidence from disinterested parties carries more weight than the applicant’s own statements.
A pre-filing checklist for QEC teams
Before filing, confirm that the invention has a hardware anchor, that the data supports the improvement, and that nothing has been made public too early.
- Name the physical component or operation the invention changes: decoder circuit, pulse schedule, coupler layout or readout path.
- State the technical result in measurable terms, and gather the data behind it.
- Identify the closest known codes and decoders, so the novelty argument under §§ 102 and 103 is clear. Section 102 covers novelty; § 103 covers obviousness.
- Draft at least one independent claim with no pure-math step left unanchored to hardware.
- List variations a competitor might try, and cover them in the specification.
- Check talks, preprints and code releases. U.S. law gives inventors a one-year grace period for their own disclosures, but foreign rules differ, so check before any public release if you want rights abroad. My post on why the filing clock starts earlier than you think covers the timing.
- Record who conceived each claimed element, since software and hardware contributors are often different people.
If you are raising money, investors will ask which layer your patents cover. A portfolio that claims only a code family is easier to design around than one that also claims the decoder and the layout. I cover the investor angle in what investors ask about your patents.
Frequently asked questions
Can you patent a quantum error correction code?
Not as a bare mathematical object. A code defined only by its stabilizers or check matrix is a mathematical concept, and a claim to it alone will likely be rejected under 35 U.S.C. § 101. You can often protect the same idea by claiming a quantum system or device that implements the code, with physical layout, control and decoding features that deliver a measurable improvement.
Is a decoding algorithm patentable?
Sometimes. A decoding method claimed as math on a generic computer is vulnerable. A method tied to a quantum processor, a latency budget and specific hardware, and supported by data showing a technical improvement, stands a much better chance. USPTO guidance after Ex parte Desjardins treats real improvements to how a machine operates as eligible.
Does open-sourcing our decoder affect patentability?
Yes. A public code release is a disclosure that can become prior art. In the United States, an inventor’s own disclosure starts a one-year grace period for filing. Rules outside the United States differ, so file before release if foreign rights matter to you.
Should we file on hardware or software first?
File on whatever is closest to public disclosure, then build out. Many teams start with a provisional application covering the whole stack: layout, control and decoder. A provisional is an informal filing that secures a date for up to 12 months. That keeps the hardware and software claims tied to one early priority date.
Talk it through before you publish
If your team has a new decoder, schedule or layout and a paper or release coming up, it helps to map the claims before the details go public. I read the physics first, then decide where the claims should sit.
This article is general information, not legal advice, and reading it does not create an attorney-client relationship. Patent law changes and every situation differs. Please talk to a patent attorney about yours.