Software Patents, Alice, and § 101 in 2026: What Is Eligible and How to Draft Claims

You can still patent software in the United States in 2026. The Alice/Mayo two-step remains the test. Claims that automate business or mental steps on a generic computer are the ones that struggle. Claims that spell out a concrete improvement to computer functionality, or to another technology, have a clear path. Here is how we draft for eligibility, and how the United States compares to Europe and China.

What changed in 2026 for software eligibility?

Nothing fundamental. Alice/Mayo is still the framework examiners apply, and the USPTO continues to scrutinize computer-implemented claims closely. Bills to amend 35 U.S.C. § 101 have been introduced in Congress in recent sessions, so check the current status before you rely on any change in the statute.

• Section 101 sets the four statutory categories and, through judicial exceptions, excludes laws of nature, natural phenomena, and abstract ideas.
• Outcomes still vary with claim language and the record you build. The reliable path is to anchor the claims in a technical improvement, not a business result.

How does the Alice/Mayo test work, in plain English?

Step One asks whether the claim is directed to a judicial exception. For software, the usual exceptions are abstract ideas: fundamental economic practices, mathematical relationships, mental processes, or methods of organizing human activity.

Step Two asks whether, if an exception is implicated, the claim adds an inventive concept that is significantly more than the exception. Using generic computers, or well-understood, routine, and conventional components, is not enough. The added elements have to do meaningful technical work.

In practice we draft and argue as if Step One and Step Two are a single conversation with the examiner: what is the specific technical improvement, and where do the claim elements show it working in the machine.

Which software claims tend to survive § 101?

The ones that improve how computers operate, not how a business operates on a computer. Claims that tend to fare better recite things like:

• A new data structure that reduces copying or memory pressure during lookups.
• A scheduler that cuts inter-thread contention by changing lock acquisition order or using a non-blocking primitive.
• A network protocol step that reduces packet retransmissions or head-of-line blocking.
• A database index or compaction routine that shortens read amplification.
• A security process that changes key handling or enclave boundaries to harden the attack surface.
• Sensor fusion logic that filters noise at the device level to improve downstream signal quality.

By contrast, claims that say "receive data, analyze it, and act", or "apply a model to rank customers", usually fail unless the claim ties those steps to a concrete improvement in how the computer runs.

Red Flags That Trigger Alice Rejections

The same patterns draw § 101 rejections across art units:

• Results-only language such as "optimize", "improve", or "configure a processor to", with no how.
• Swapping in a buzzword, for example "blockchain" or "neural network", without a specific change to memory, storage, networking, or processing.
• Saying steps happen "on a server", "in the cloud", or "using an app", with no architectural detail.
• Automated business rules, scoring, or pricing that a person could do with pencil and paper.

Each of these can be salvaged if the application teaches a concrete system change and the claims are rewritten to recite it.

How to Draft Software Claims and a Specification That Pass § 101

Here is the playbook we use with inventors and product teams.

1) Frame a technical problem. Describe the computing bottleneck or failure mode: cache misses, queue contention, tail latency spikes, deadlocks, stale reads, memory churn, dropped packets, clock skew, power draw.

2) Describe the baseline system. Draw the pre-invention pipeline, data layout, or protocol state machine. Put names on components so you can point at them in the claims.

3) Teach the concrete change. Spell out the new data structure, control loop, message format, memory layout, or scheduling rule. Use nouns and verbs the examiner can map to boxes in your drawings.

4) Tie it to measurable effects. You do not have to promise numbers. You do have to explain the mechanism that reduces copying, cuts lock contention, shortens code paths, or increases cache locality. Mechanism beats marketing.

5) Claim the mechanism, not only the result. Avoid "configured to optimize". Recite the steps, the constraints, and how components interact. Useful claim verbs: allocating, pinning, batching, coalescing, deduplicating, prefetching, checkpointing, compacting, retry-backoff with jitter.

6) Write dependent claims that narrow with technical detail. Fallbacks should change how the computer works, not just who the user is or what business rule applies.

7) Draft multiple categories, keep one story. Method, system, and computer-readable medium formats are all examined under Alice. Use each to express the same technical improvement from a different angle.

8) Put evidence in the file where it helps. Diagrams, test setups, benchmark comparisons, and inventor declarations that explain the mechanism all strengthen a Step Two argument.

9) Keep the business logic separate. If your product has pricing, scoring, or UX flows, describe them, but keep the claims that will face § 101 focused on the computing improvement.

10) In prosecution, lead with the improvement. Examiner interviews often break an impasse once you walk line by line through the claim and the figure that shows the change in operation.

AI and Machine Learning Claims

Saying "use a model to classify" does not rescue a claim. The Federal Circuit has affirmed early ineligibility for generic machine-learning claims that lack a concrete technical improvement, and examiners look for the same thing: a new training pipeline that reduces memory churn, a data structure for streaming inference, a hardware-aware batching routine that stabilizes tail latency. Constrain the architecture in the claim: model topology, feature extractors, quantization scheme, cache-aware data layout, and how each interacts with computing resources.

Who Counts as the Inventor When AI Helped

In the United States, only a natural person can be named as an inventor. AI is treated as a tool, and the traditional conception standard still applies. That is a documentation job as much as a legal one. For AI-assisted work, keep contemporaneous records of the human contributions that materially shaped conception:

• How the problem was framed and scoped.
• Architectural design choices, including model topology and feature engineering decisions.
• Training and validation protocols, and the reasoning behind them.
• The data structures and system constraints the team chose.

Align the inventor declarations with those records. Europe takes the same position on the inventor question: the focus stays on the technical contribution of the claimed subject matter, and there is no route to naming an AI as inventor. Our companion post, AI Inventorship Post-DABUS, goes deeper on the documentation.

The United States and Europe Side by Side

China takes a similar line to Europe. Software-related inventions are recognized where the claim presents a technical solution, using technical means, to achieve a technical effect. If your United States claims lean on a business rule, expect to revise them for Europe and China so the technical effect sits in front.

From Our Files: Turning a Near-Failing Claim Into an Eligible One

A product team brought us a ranking engine that aggregated supplier offers. Their draft claim read like a flowchart of business steps, and the examiner hit it with § 101. We sat with the engineers, traced the pipeline, and found the technical improvement: the system used a graph-based index that avoided repeated deserialization and cut contention in the hot path. We rewrote the independent claim to recite the index layout, the lock-free merge operation, and the cache-aware fetch, and amended the figures to show where in memory each piece lived. On the next action, eligibility was withdrawn and the case moved forward on prior art.

The lesson is simple. If you can point to a machine-level change, claim it. If you cannot, consider keeping it as a trade secret, or building more technical depth before you file.

Common Pitfalls That Sink an Application

• Results-only claims. "Apply machine learning to data" with no architecture, training regimen, data structure, or system-level gain.
• Mental-process framing. If the steps can be analogized to pen-and-paper analysis, Step Two integration fails.
• A thin technical narrative. Algorithmic detail that is never tied to memory, latency, throughput, security, or control gives the examiner nothing to work with, on either side of the Atlantic.
• Misaligned inventorship. For AI-assisted work, no record of the human contribution to conception is an avoidable weakness.
• Vague prosecution. Responses with no comparative data and no system diagrams stretch prosecution out and weaken your position.
• Deadline drift. The 12-month window to convert a provisional, the office action response window, and the appeal deadline all move fast.

Strategy for a 2026 Filing Program

1. Lead with the technical improvement in both the specification and the independent claims, and map every claim element back to it.
2. Draft multi-layered claims: system, method, and computer-readable medium, with dependent claims that lock in concrete data structures, pipeline stages, scheduler policies, and hardware interactions.
3. Front-load evidence: comparative benchmarks, ablation results, and architecture diagrams support eligibility, non-obviousness, and a smoother examiner interview.
4. Book examiner interviews early, to agree on the improvement story and find the surgical amendment that turns abstract language into a grounded technical recitation.
5. Use the PCT to stage global rights. File early to lock priority, then tailor claims for the United States "significantly more" standard and the EPO "technical effect" standard at national and regional phase entry.
6. Audit the portfolio. Concrete, architecture-specific claims are what hold up. Consider continuations to capture improvements, and EPO divisionals to pursue an alternative technical effect.

What It Costs and How Long It Takes

USPTO and EPO patent fees change with entity status, claim count, and route, and they are not something to quote from a blog post. Work from the current USPTO fee schedule and the EPO fee calculator, both linked below, and see our patent services for what the drafting and prosecution work costs with us. Examination is not quick in either office, so plan your filing program around a multi-year horizon rather than a launch date. More general questions are answered on our FAQ.

Should you file now or wait?

If your innovation is mostly a business rule on a server, waiting rarely helps. If you can document a technical improvement and show it in the architecture, file. A well-written provisional can capture that detail while you gather more evidence, and you harden it in the non-provisional.

Related Reading

• US Provisional Patent Applications: A 2026 Strategy Guide
• PCT National Phase US Entry 2026 Guide
• AI Inventorship Post-DABUS: US/EU 2026

Sources

• USPTO MPEP § 2106: Patent Subject Matter Eligibility
• EPO Guidelines G-II 3.6: Programs for computers
• USPTO fee schedule
• EPO fees and fee calculator
• WIPO PCT Applicant's Guide