How to Patent Software in 2026 — What Actually Gets Granted

Software patents aren't dead. They're just specific now.

After the Supreme Court's Alice v. CLS Bank decision in 2014, the USPTO started rejecting software patents that looked like "do a known business process on a computer." But patents that solve a concrete technical problem in a novel way still get granted every day.

What the USPTO actually grants in 2026

The patents that survive examination share a pattern: they don't claim "a method of doing X on a computer." They claim a specific technical architecture that produces a measurable technical effect.

Examples of granted software patents (all in the PatentBrief database):

• US10452978 — Google's Transformer attention mechanism. Not "a method of processing text." A specific neural network architecture with multi-head self-attention that improved machine translation accuracy by a measurable margin.
• US10832138 — GPT language model pre-training. Not "a method of generating text." A specific unsupervised pre-training pipeline with a particular transformer configuration.
• US11429864 — Nvidia's DLSS. Not "a method of improving graphics." A specific temporal feedback network that reconstructs high-resolution frames from low-resolution inputs with particular anti-aliasing properties.

The pattern: claim the how, not the what

Don't claim	Claim instead
"A method for recommending products"	"A collaborative filtering engine that computes similarity scores using a particular matrix factorization technique"
"A system for detecting fraud"	"A real-time anomaly detection pipeline that applies a specific statistical model to transaction graphs"
"A method for compressing video"	"A codec that applies a particular motion estimation algorithm with a novel quantization scheme"

The Alice two-step (still the law in 2026)

1. Is the claim directed to an abstract idea? If yes, proceed to step 2. If no (it's a concrete technical improvement), it's eligible.
2. Does the claim add "significantly more" than the abstract idea? If it recites a specific, unconventional technical solution — not just generic computer components — it passes.

The winning strategy: write claims that a patent examiner can map to a specific technical component (a particular data structure, a novel pipeline stage, an unconventional hardware-software interaction). If your claim could be performed by a human with a pencil and paper, it fails step 2.

Practical steps before you file

1. Run an idea check. PatentBrief's Idea Check compares your description against 795+ landmark patents by meaning, not just keywords. It surfaces the closest prior art so you know what you're up against before spending money.
2. Search by CPC class. Software patents cluster in G06F, G06N, and H04L. Browse those classes to see what's already been claimed.
3. Draft claims around the technical effect. What measurable improvement does your invention produce? Faster processing? Lower memory usage? Better accuracy? That's your hook.

What this means for founders

You don't need to be Google to get a software patent. You need a genuinely novel technical approach to a real problem. The bar is higher than it was in 1999, but it's not impossible — it's just honest.

Not legal advice. Consult a registered patent attorney for your specific situation.

The case law that decides what survives

Alice gave us the two-step test, but four Federal Circuit decisions since then are what examiners and courts actually lean on to separate an eligible claim from an abstract one:

• DDR Holdings v. Hotels.com (2014) — the first software claim to survive Alice at the Federal Circuit. The claims solved a problem "necessarily rooted in computer technology" (keeping a visitor on a retailer's page instead of being whisked away to a third-party site). Lesson: tie the invention to a problem that only exists because of how computers and networks work.
• Enfish v. Microsoft (2016) — a self-referential database table was held not abstract because it was an improvement to the functioning of the computer itself, not merely a task run on a computer. Lesson: if your invention makes the machine faster, smaller, or more efficient, say so and claim it that way.
• McRO v. Bandai (2016) — rules for automatically lip-syncing 3D animation were eligible because the claims recited a specific set of rules producing a concrete technical result, not a generic "do it on a computer." Lesson: specific, unconventional rules beat broad functional language.
• Berkheimer v. HP (2018) — whether a claim element is "well-understood, routine, and conventional" is a question of fact, not something an examiner can simply assert. Lesson: load your specification with technical detail showing your approach is not conventional — it is ammunition against a §101 rejection.

The framework examiners actually apply

Since the USPTO's 2019 Revised Patent Subject Matter Eligibility Guidance, examiners sort alleged abstract ideas into three buckets — mathematical concepts, certain methods of organizing human activity (fundamental economic practices, managing personal behavior, commercial interactions), and mental processes (things a person could do in their head or with pen and paper). If a claim falls in a bucket, the examiner then asks whether it integrates that idea into a practical application — a real technical improvement — or adds significantly more. Claims that improve the technology itself pass; claims that just automate a known human activity do not.

This is why "Uber for X" or "a marketplace that matches buyers and sellers" almost never survives: it is organizing human activity on a generic computer. A novel data structure, a new compression scheme, a specific way of training or running a model, or a protocol that cuts network round-trips improves the technology — and survives.

How to draft so it survives

• Lead with a technical problem and a technical solution. The specification should explain what was hard for the system and how your approach concretely fixes it — lower latency, less memory, higher accuracy, fewer round-trips.
• Claim structure, not just outcome. Recite the specific data structures, pipeline stages, or hardware-software interactions that produce the effect — not "a processor configured to" deliver the result.
• Avoid pure functional language. "Means for determining the best route" invites both a §101 and a §112 rejection; the actual algorithm does not.
• Arm a Berkheimer argument. Put enough technical detail in the spec to show the approach is unconventional, so an examiner cannot wave it away as routine.
• Mind the art unit. Applications routed to business-method art units (the USPTO's 3600 series) historically see far higher §101 rejection rates than those in core computing units — how you frame the invention affects where it lands.

Patent, copyright, or trade secret?

Software is unusual because three different IP regimes can apply, and they protect different things:

• Copyright protects the expression of your code automatically, the moment you write it — but not the underlying idea or method. A competitor who reimplements your functionality from scratch does not infringe your copyright.
• Trade secret protects anything valuable you can keep secret — a server-side algorithm you never ship, a training pipeline, a ranking formula — for as long as it stays secret, with no disclosure required. The catch: once it leaks or is independently discovered, the protection is gone.
• A patent protects the functional method itself, even against independent inventors — but only if you disclose exactly how it works to the public. For something you ship and competitors can inspect, that disclosure is often worth it; for a secret server-side process, a trade secret may protect more.

The strongest software companies use all three deliberately: patents on the novel shipped mechanisms, trade secrets on the back-end, copyright on the codebase, and trademarks on the brand.

The honest bottom line

Software patents are harder and narrower than they were before 2014, but the bar is clarity about your technical contribution, not impossibility. If you can point to a specific way your invention improves how a machine works — and draft claims that capture that mechanism rather than the business result — it can still be granted and enforced in 2026.