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

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

What changed in 2026 for software eligibility?

Nothing fundamental. The sources we track in 2025–2026 report no statutory amendment to 35 U.S.C. § 101 and no new Supreme Court decision replacing Alice. Practitioner guides continue to apply the same Alice/Mayo framework and focus on practical drafting tactics.

• § 101 sets the four statutory categories and, through judicial exceptions, excludes laws of nature, natural phenomena, and abstract ideas.
• Post‑Alice, the USPTO tightened subject matter scrutiny for computer‑implemented inventions.
• Outcomes still vary by claim language and record. The safest path is to anchor the claims in a technical improvement, not a business result.

{{IMAGE: Decision-flow diagram of the Alice/Mayo two-step with brief examples at each node | The two-step test that examiners and courts apply in 2026}}

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

Step One asks whether the claim is directed to a judicial exception. For software, common exceptions are abstract ideas like 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 must 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 in 2026?

Short answer, the ones that improve how computers operate. Not how a business operates on a computer. Examples that often fare better include claims that recite:

• 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 attack surfaces.
• Sensor fusion logic that filters noise at the device level to improve downstream signal quality.

By contrast, claims that simply 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 computer operation.

{{IMAGE: Side-by-side comparison of two claim snippets: results-oriented business steps vs. concrete technical steps with architecture references | What examiners see as abstract vs technical}}

Red flags that trigger Alice rejections

We see the same patterns draw § 101 rejections across art units:

• Results-only language like “optimize,” “improve,” or “configure a processor to,” without the how.
• Swapping in a buzzword, for example “blockchain” or “neural network,” without a specific change to memory, storage, networking, or processing.
• Stating that steps are performed “on a server,” “in the cloud,” or “using an app,” with no architectural detail.
• Automated business rules, scoring, or pricing that a human could perform with pencil and paper.

Each of these can be salvaged if the application teaches an actual system change or computing improvement 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. Example prompts: 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 to 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 to measurable effects. You do not need to promise numbers. Do 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, constraints, and how components interact. Example claim verbs: allocating, pinning, batching, coalescing, deduplicating, prefetching, checkpointing, compacting, retry‑backoff with jitter.

6) Include 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, but keep the same story. Method, system, and computer‑readable medium formats are all examined under Alice. Use each to express the same technical improvement from different angles.

8) Put evidence in the file when helpful. Diagrams, test setups, and inventor declarations that explain the mechanism can strengthen Step Two arguments.

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) During prosecution, lead with the improvement. Examiner interviews often resolve impasses once we walk line‑by‑line through the claim and the figure that shows the change in operation.

A quick U.S. to Europe and China comparison

• Europe. The EPO asks whether the claimed features produce a technical effect beyond a computer program as such. Features that contribute to the technical solution are considered for inventive step. Business aspects usually do not move the needle unless tied to a technical contribution.
• China. Software‑related inventions are recognized where the claim presents a technical solution using technical means to achieve a technical effect. As in Europe, the focus is on a concrete technical contribution, not business automation.

This is a high‑level snapshot to guide strategy. If your U.S. claims hinge on a business rule, expect to revise for Europe and China to foreground the technical effect.

{{IMAGE: Simple world map with callouts summarizing “U.S.: Alice two-step,” “EPO: technical effect,” “China: technical solution” | How major offices frame software eligibility}}

From our files: turning a near-failing claim into an allowed case

A product team brought us a ranking engine for aggregating supplier offers. Their draft claim read like a flowchart of business steps. The examiner hit it with § 101. We sat with the engineers, traced the pipeline, and found the real improvement. Their 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. We 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 AI/ML pitfalls under § 101

Saying “use a model to classify” does not rescue a claim. Examiners look for a technical improvement such as a new training pipeline that reduces memory churn, a data structure for streaming inference, or a hardware‑aware batching routine that stabilizes tail latency. Focus the claims on the mechanism that changes how the computer processes data.

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, you can file now. A well‑written provisional can capture that detail while you gather more evidence, then you harden it in the non‑provisional.

Ready to move? Our attorney‑led team has been at this since 2016. We prosecute software patents in major jurisdictions and coordinate claim strategy across markets so the same technical story carries through.

{{IMAGE: Stepwise timeline from invention disclosure to provisional, to non-provisional, to foreign filings, with notes on adding technical detail at each stage | When to file and how to stage your evidence}}

Related reading

• US Provisional vs Non-Provisional 2026
• PCT National Phase US Entry 2026 Guide
• AI Inventorship Post-DABUS: US/EU 2026