Alice test explained for software developers

If you build apps, APIs, ML pipelines, or infrastructure code, you have probably heard two contradictory things: “everything software is patentable” and “software patents are dead after Alice.” Neither is quite right. The Alice/Mayo framework still allows software patents — but only when the invention is tied to a concrete technical problem and a non-routine computer implementation.

This guide explains the Alice test the way developers actually need it: what examiners look for in code, how to document an “inventive concept,” and where teams lose eligibility before they ever reach novelty (§102) or non-obviousness (§103).

Why Alice changed the conversation

In Alice Corp. v. CLS Bank International (2014), the Supreme Court held that claims to intermediated settlement — essentially using a third party to reduce settlement risk — were directed to an abstract idea and lacked an inventive concept when implemented on a generic computer. The decision did not ban software patents. It raised the bar: you cannot patent mental steps, pure business methods, or generic data processing merely by adding “on a computer” or “over a network.”

For developers, the practical effect shows up in USPTO office actions: §101 rejections often arrive before the examiner deeply compares your code to prior art. That means eligibility is a gating issue — weak §101 framing can kill an application even when the underlying engineering is clever.

The two-step Alice/Mayo framework (plain English)

The Federal Circuit and USPTO apply a two-step test from Mayo and Alice:

1. Step 1 — Abstract idea? Is the claim directed to a judicial exception: an abstract idea, law of nature, or natural phenomenon? For software, this often means fundamental economic practices, certain methods of organizing human activity, mathematical concepts, or mental processes performed without a particular machine.
2. Step 2 — Inventive concept? If yes, do the claim elements (individually or as an ordered combination) add something “significantly more” than the exception — an unconventional technical implementation that is not well-understood, routine, or conventional?

Step 2 is where strong engineering documentation wins. The claim must do more than automate a human workflow. It should solve a technical problem in a specific way: a particular data structure, control loop, memory layout, security boundary, latency tradeoff, or measurable performance gain tied to computer operation.

Abstract ideas in software — the categories that trip up teams

Examiners frequently map software inventions to these abstract-idea buckets:

• Fundamental economic practices — hedging, intermediated settlement, advertising pricing models without a technical hook.
• Methods of organizing human activity — workflow orchestration, scheduling meetings, matching buyers and sellers when the computer adds nothing unconventional.
• Mathematical concepts — applying a formula, statistical model, or ML architecture without claiming a specific technical application and improvement.
• Mental processes — steps a human could perform with pen and paper, even if coded.

A React dashboard that “displays analytics” is often abstract or obvious on its face. A caching layer that cuts p99 latency by 40% using a novel eviction policy tied to request fingerprints is closer to patentable subject matter — if you claim the technical mechanism, not the business outcome.

What counts as an “inventive concept” in code

Post-Alice case law gives developers useful patterns (not guarantees):

• Specific improvement to computer functionality — faster execution, lower memory, stronger security, better parallelism, fault tolerance. Enfish, LLC v. Microsoft (2016) is often cited for self-referential table indexing that improved how the computer stored and retrieved data.
• Non-conventional technical combination — merging known pieces in a way that produces an unexpected technical effect, not merely a business result.
• Particular machine or architecture — not “any computer,” but a defined pipeline, protocol, or resource manager with concrete steps.
• Measurable technical effect — benchmark deltas, error-rate reduction, bandwidth savings, with enough detail to distinguish from generic automation.

Website presentation cases like DDR Holdings, LLC v. Hotels.com (2014) show that even internet-commerce contexts can survive §101 when claims recite a specific technical solution to a technical problem (there, a particular way of modifying web pages to avoid visitor loss). The through-line is specificity.

Worked example: generic rate limiting vs. specific improvement

Token-bucket rate limiting is decades old (RFCs, open-source middleware, cloud vendor docs). A claim that says “receive requests, count tokens, reject when empty” is directed to an abstract idea or well-known computer practice and will struggle at Step 2.

Now suppose your service implements an adaptive rate limiter that:

• maintains per-client EWMA statistics on burst shape, not just request count;
• pre-allocates a reserve bucket 200–500ms before predicted spikes based on historical fingerprints;
• throttles refill rates when downstream error rates rise, coupling admission control to observed failure feedback.

The eligibility argument is not “we rate-limit API traffic” (abstract business goal). It is: a particular admission-control architecture that reduces false-positive throttling and improves tail latency under bursty load, with the specific data structures and control loops spelled out in the spec and claims.

That framing is how engineers pass Step 1–2 screening long enough for §102/§103 analysis to matter.

Code shapes that help (and hurt) §101

Weak pattern — describes outcomes, not mechanism:

def process(data):
    score = model.predict(data)  # generic ML inference
    return {"label": score}

A claim built only around “receive data, predict, return label” reads as a mathematical concept on a generic computer.

Stronger pattern — ties claims to a specific technical pipeline and improvement:

class AdaptiveLimiter:
    """Pre-allocates reserve tokens from EWMA burst forecast;
    couples refill rate to downstream 5xx ratio (see bench §4.2)."""
    def _maybe_preallocate_reserve(self, client_id: str) -> None:
        forecast = self._ewma_burst[client_id].predict_horizon(ms=300)
        if forecast > self._threshold:
            self._reserve_bucket.credit(forecast * self._priority_weight(client_id))

Your patent application still must claim the architecture precisely — comments alone are not enough — but code and design docs that expose why this is not a textbook token bucket become evidence for an inventive concept.

Backend, ML, and UI — three different Alice profiles

Backend / infrastructure

Best positioned when you improve how systems run: concurrency control, storage formats, network protocols, fault containment, resource scheduling. Document baseline approaches you rejected (fixed windows, naive buckets, static limits) and measured deltas.

Machine learning

Hardest when claims look like “train a neural network to classify X.” Stronger when you claim a specific training pipeline, hardware-aware quantization flow, federated aggregation protocol, or inference architecture that solves a technical bottleneck (memory, latency, privacy boundary) in a non-routine way. See our companion post on patenting ML models.

UI and front-end

Layouts, forms, and dashboards alone are often abstract. Eligibility improves when the UI embodies a technical solution — e.g., a particular way of rendering that reduces client CPU, a novel synchronization model between offline and online state, or a security-sensitive interaction pattern that mitigates a concrete attack class.

Documenting eligibility while you still remember the design

Examiners and courts look at the specification and prosecution history. Engineers should capture:

• Problem statement in technical terms — not “users were unhappy,” but “p99 latency exceeded SLO under bursty OAuth traffic.”
• Rejected alternatives — what you tried (fixed window, sliding log, ML classifier) and why it failed benchmarks.
• Human design decisions — especially if AI tools suggested code; note what you changed and why (critical for inventorship too).
• Benchmarks and dates — commit hashes, load-test configs, before/after tables.
• Glossary — define terms like “reserve bucket,” “burst fingerprint,” or “feedback-coupled refill” so claims are anchored to your implementation.

Patent PreCheck’s Filing Readiness pillar (§112) and eligibility pillar (§101) both reward this kind of documentation in source and notebooks.

How §101 interacts with §102 and §103

Teams often conflate the pillars. Alice/§101 asks whether the subject matter is patent-eligible. §102 asks whether it is novel over prior art. §103 asks whether it would have been obvious to combine references.

You can lose on §101 even with no identical prior art citation — because the claim is directed to an abstract idea without inventive concept. Conversely, you can survive §101 and still fail §102/§103 when token buckets, EWMA traffic engineering, or ML serving papers anticipate your combination.

That is why a free score should surface all four statutory pillars plus human conception strength, not a single headline number.

Common developer mistakes (and fixes)

• Claiming the business result — “increase revenue by personalizing offers.” Fix: claim the technical pipeline that enables personalization with a specific architecture.
• Generic computer language — “a processor configured to…” without structural detail. Fix: name modules, data flows, and unconventional interactions.
• Hiding the invention in UI copy — the real novelty lives in the service layer; claims must follow the code.
• No comparison to conventional approaches — examiners map you to textbook solutions. Fix: cite what conventional systems do and where yours differs measurably.
• AI-generated code with no human conception record — eligibility and inventorship both suffer. Fix: document edits, tests, and design tradeoffs you made personally.

Checklist before you talk to a patent attorney

1. Can you state the technical problem in one sentence without mentioning revenue or users?
2. Can you point to a specific module/class/function that implements a non-routine solution?
3. Do you have benchmarks or traces showing improvement over a conventional baseline?
4. Did you document rejected designs and why they were inadequate?
5. Are you ready to distinguish the closest GitHub repos, RFCs, and papers?

If you answer “no” to several items, you are not necessarily unpatentable — but you are not yet file-ready. Strengthen documentation first; it improves §101, §112, and attorney efficiency.

What a §101 office action looks like (and how to respond)

When the USPTO issues a §101 rejection, the examiner usually says your claims are directed to an abstract idea and that the remaining elements are “well-understood, routine, conventional activities” when considered at Step 2. The action often cites Alice, Mayo, and a string of software cases with fact patterns that may not match yours.

Developer teams should treat the first §101 action as a specification problem as much as a claims problem. Practical response steps:

1. Map claim elements to code modules — show where each limitation lives in your implementation; if a limitation is not implemented, amend or remove it.
2. Amend with technical detail — add data-structure relationships, timing constraints, feedback loops, or resource boundaries that are not generic computer functions.
3. Argue with evidence — affidavits or declarations with benchmark data can support an unexpected technical improvement (use cautiously; counsel should draft).
4. Distinguish cited cases — many examiner citations are boilerplate; explain why your architecture is not intermediated settlement, a pure business method, or a mental process.
5. Preserve human conception facts — especially for AI-assisted development, show design decisions you made that led to the technical implementation.

Early preparation — before filing — is cheaper than a multi-round §101 fight. That is the point of scoring eligibility and documentation quality before counsel drafts claims.

How Patent PreCheck scores Alice risk in your source

Our free tier analyzes pasted or uploaded code against four pillars (§101–§103 plus §112 documentation) and human conception strength. The eligibility pillar flags abstract-idea patterns: generic receive/process/display flows, outcome-only ML wrappers, and missing technical specificity.

Interactive Code Review ($69.95) walks your code section by section, suggests plain-English edits that strengthen weak pillars, and runs a 200-match prior-art search so you can see what examiners may cite alongside §101 challenges.

Not legal advice. We help you prepare; a licensed patent attorney should draft and prosecute claims.

Next steps

Run a free Alice-aware score on your code · Read Can my code be patented? · Deep dive on prior art for code · See sample report