More than a decade after Alice Corp. v. CLS Bank International, software patent applicants still face a landscape where a well-written specification describing a real technical innovation can be rejected as claiming nothing more than an "abstract idea." The rule hasn't changed. What has changed — slowly, through a series of Federal Circuit decisions and evolving USPTO guidance — is how to draft and argue around it.
Software patents are still obtainable, and they are still valuable. But winning a software patent in 2026 is a drafting problem before it is an argument problem. This post walks through the framework examiners apply, the patterns that consistently fail, and the strategies that consistently work.
The Alice/Mayo Framework in Plain English
Under 35 U.S.C. § 101, the USPTO applies a two-step test. Step one asks whether the claim is "directed to" a judicial exception — an abstract idea, a law of nature, or a natural phenomenon. If yes, step two asks whether the claim contains additional elements that amount to "significantly more" than the exception itself — an inventive concept that transforms the abstract idea into a patent-eligible application.
In practice, examiners in the software art units apply this test aggressively. Claims that recite collecting data, analyzing data, and displaying results are routinely characterized as abstract. The fight is almost always about step two: what makes your claim more than the abstract idea the examiner identified?
The Patterns That Consistently Fail
Before discussing what works, it's worth recognizing what doesn't. The following claim patterns receive § 101 rejections almost automatically:
- Claims that look like business methods. "A method of matching buyers and sellers" or "a system for managing inventory" trigger the abstract-idea filter immediately, regardless of the technical implementation.
- Claims that describe results, not mechanisms. "A system that optimizes X" tells the examiner what you achieve but not how. Without the how, there is nothing technical to evaluate.
- Claims that recite generic computer components doing what computers already do. "A processor configured to receive data, process data, and transmit data" adds nothing beyond the abstract idea of processing data.
- Claims drafted entirely at the user-experience level. Describing what the user sees is rarely enough. The question is what the system does underneath.
What Actually Works: Drafting Strategies
1. Anchor the invention in a technical problem
The Federal Circuit's decisions in Enfish, McRO, and DDR Holdings share a common thread: the claimed invention addressed a technical problem specific to computer operation, and the solution improved the functioning of the computer itself. Your specification should open by explaining the technical problem — not the business problem — in enough detail that an examiner reading it understands why conventional systems fall short.
2. Claim the mechanism, not the outcome
If your algorithm uses a specific data structure, a specific decomposition of the problem, a specific ordering of operations, or a specific hardware interaction, that specificity goes in the claim. Claims that recite how the computer's behavior differs from generic data processing survive § 101 far more often than claims describing only what is achieved.
3. Tie software claims to concrete technical effects
Reduced memory usage, lower latency, better cache behavior, reduced network traffic, improved GPU utilization, or decreased power consumption are all concrete technical effects that Federal Circuit panels have accepted as evidence of patent eligibility. Describe the effect in the specification and, where possible, reflect it structurally in the claim.
"The difference between an eligible software claim and an ineligible one often isn't what the invention does — it's whether the claim tells the reader how the system does it in a way that's tied to the technical characteristics of a computer."
4. Layer your claim set
Don't stake everything on a single broad independent claim. A well-structured application includes a broad claim, a more implementation-specific claim, and one or more claims reciting specific data structures, training procedures, hardware configurations, or system architectures. If the broadest claim draws a § 101 rejection, the narrower claims give you amendment options that don't require surrendering the invention.
Responding to § 101 Rejections
When a § 101 rejection arrives, three techniques are disproportionately effective:
- Attack the examiner's step-one characterization. Examiners often describe claims at a high level of abstraction that strips away the technical detail. A good response quotes specific claim language the examiner ignored and explains why the claim is directed to a technical improvement, not the abstract idea the examiner named.
- Point to the specification for technical improvement. Federal Circuit case law repeatedly holds that the specification's description of technical improvements is relevant to the eligibility analysis. Cite specific paragraphs. Tie them to specific claim elements.
- Request an examiner interview. Abstract-idea rejections are judgment calls, and a fifteen-minute conversation often accomplishes what a twenty-page response cannot. The goal is to understand the examiner's specific concern and propose amendments that address it without over-narrowing.
AI and Machine Learning: A Special Note
ML patent applications face a particularly aggressive § 101 environment. "A system that uses a neural network to predict Y" reads almost identically to examiners as "a system that predicts Y" — the neural network adds nothing, in their view. Successful ML applications drill into specifics: how is the model architected, what are the training signals, how is inference deployed, what is the specific technical problem the model was designed to overcome?
The most defensible ML claims I draft tend to combine a model-architecture element, a data-preparation or training-process element, and a concrete technical effect. Together these three anchors make the claim specific enough that the examiner has trouble mapping it onto a generic "abstract idea" framing.
Key Takeaways
- Software patents are obtainable in 2026, but drafting matters more than arguing.
- Anchor claims in technical problems, technical mechanisms, and technical effects — not business outcomes.
- Layer your claim set so a § 101 rejection has room to be addressed without surrendering the invention.
- For ML inventions, claim architecture, training, and inference specifics. Generic "uses a model" language will not survive.
- When responding to a § 101 rejection, attack the examiner's characterization and tie claim language to specific technical improvements described in the specification.
Next Steps
If you're preparing to file a software or AI patent — or you've received a § 101 rejection and want a clear-eyed strategy for responding — schedule a consultation. Software eligibility problems are much easier to solve during drafting than after rejection.
