Alice Corp. v. CLS Bank (2014): Patent eligibility and claim drafting

The Core Rule: A claim directed to an abstract idea does not become patent-eligible merely by requiring generic computer implementation. Under the Mayo–Alice framework, courts first identify whether the claim is directed to a judicial exception, then ask whether its additional elements—individually and as an ordered combination—supply an inventive concept.

1. Executive Summary

In Alice Corp. v. CLS Bank International, the Supreme Court unanimously held that Alice’s claims concerning a computerized scheme for mitigating settlement risk in financial transactions were ineligible under 35 U.S.C. §101. The claims used a third-party intermediary to create and maintain records reflecting obligations between parties and to ensure that a transaction would settle only if the parties had sufficient funds. Implementing that scheme on generic computers did not transform the abstract idea into a patent-eligible invention.

Alice is central to modern U.S. patent-eligibility analysis, especially for software, fintech, business methods, data-processing systems, and computer-implemented workflows. It does not mean software is categorically unpatentable. It means that describing an abstract idea and adding routine computer functions—such as receiving data, storing records, calculating, or communicating results—may not satisfy §101.

The Practical Lesson: Draft claims around a specific technical improvement, not only a business objective performed on a computer. The specification should explain the technical problem, the architecture or process that solves it, and the concrete improvement produced.

2. Case at a Glance

• Item: Court — Details: Supreme Court of the United States
• Item: Citation — Details: 573 U.S. 208 (2014)
• Item: Docket — Details: No. 13-298
• Item: Argued / decided — Details: March 31, 2014 / June 19, 2014
• Item: Opinion — Details: Justice Clarence Thomas
• Item: Vote — Details: Unanimous opinion; Justice Sotomayor joined the opinion and also filed a concurrence joined by Justices Ginsburg and Breyer
• Item: Statute — Details: 35 U.S.C. §101 — patentable subject matter
• Item: Disposition — Details: Federal Circuit affirmed; claims held patent-ineligible

3. Technical and Business Background

The patents described methods for reducing settlement risk in financial exchanges. In a transaction involving two parties, each party may be expected to deliver something of value. If one party performs but the other defaults, the first party may suffer a loss. Alice’s claimed approach used a computer system and a third-party intermediary to maintain records and ensure that obligations were settled only when the relevant conditions were met.

The business problem: settlement risk

Party A owes value to Party B, and Party B owes value to Party A or another participant.

If the parties’ obligations are not coordinated, one party may pay while the counterparty fails to perform.

An intermediary can track obligations and condition settlement on the parties’ ability to meet them.

The claimed solution at a high level

• Step: 1. Create records — Illustrative operation: A computer system creates records for the parties and their obligations. — Legal significance in Alice: Record creation was a generic computer function.
• Step: 2. Maintain balances — Illustrative operation: The system tracks or updates account information. — Legal significance in Alice: Generic data storage and updating did not supply an inventive concept.
• Step: 3. Use an intermediary — Illustrative operation: A third party monitors the transaction and coordinates settlement. — Legal significance in Alice: Intermediation was the abstract financial scheme identified by the Court.
• Step: 4. Settle conditionally — Illustrative operation: The transaction is completed only when required conditions are satisfied. — Legal significance in Alice: The claimed result was implemented using conventional computer functions.

Important: This is a simplified conceptual representation, not a verbatim reproduction of any claim. The legal decision depends on the claims as written and the Court’s characterization of their substance.

4. Procedural History

District Court — Held the asserted claims patent-ineligible under §101.

Federal Circuit — panel — Initially reversed in part, treating some claims as patent-eligible.

Federal Circuit — en banc — Affirmed the ineligibility judgment in a fractured decision, with no single rationale commanding a majority across all opinions.

Supreme Court — Affirmed the judgment that the claims were ineligible, applying the two-step framework associated with Mayo Collaborative Services v. Prometheus Laboratories.

5. Legal Question and Holding

Can a claim to an abstract financial settlement scheme become patent-eligible simply by requiring that the scheme be performed using a generic computer?

Holding: No. Merely instructing a generic computer to implement an abstract idea does not make the idea patent-eligible. The claims must add an inventive concept beyond the abstract idea itself.

6. Section 101: The Threshold Requirement

Section 101 covers processes, machines, manufactures, and compositions of matter, and qualifying improvements to them. The Supreme Court has recognized exceptions for laws of nature, natural phenomena, and abstract ideas. These exceptions protect basic tools of scientific and technological work from being monopolized.

Alice concerned the abstract-idea exception. The Court did not hold that all business methods or all software claims are unpatentable. Rather, it examined whether these claims, in substance, monopolized an abstract financial concept and added only generic computer implementation.

• Patentability concept: §101 eligibility — Question asked: Is the claim directed to eligible subject matter, and does it avoid a judicial exception? — How it differs from Alice’s issue: The central issue.
• Patentability concept: §102 novelty — Question asked: Was the claimed invention previously disclosed? — How it differs from Alice’s issue: A new idea can still be abstract and ineligible.
• Patentability concept: §103 non-obviousness — Question asked: Would the invention have been obvious to a skilled person? — How it differs from Alice’s issue: A claim must pass this separately.
• Patentability concept: §112 disclosure — Question asked: Are the claims supported, enabled, and sufficiently definite? — How it differs from Alice’s issue: Good drafting cannot cure a §101 problem alone.

7. The Mayo–Alice Two-Step Framework

Step 1 — Is the claim directed to an abstract idea?

The court considers the claim as a whole to determine whether its focus is an abstract idea, such as a fundamental economic practice, a method of organizing human activity, or a mathematical concept. In Alice, the Court characterized the claims as directed to intermediated settlement, a longstanding financial practice.

Step 2 — Is there an inventive concept?

If the claim is directed to an abstract idea, the court examines the additional elements, individually and as an ordered combination, to determine whether they transform the claim into a patent-eligible application. Conventional computer functions—such as receiving, storing, processing, and transmitting information—generally do not suffice merely because they are performed by a computer.

Do Not Treat This As A Checklist Trick: Adding words such as “computer,” “processor,” “database,” “network,” or “real time” does not automatically make a claim eligible. The question is what the claimed technology actually contributes.

8. Applying Step 1 to Alice

Identify the claimed focus — The claims concerned mitigating settlement risk through a third-party intermediary.

Look beyond the computer terminology — The Court looked at the substance of the scheme, not just the fact that the claims recited computer systems and method steps.

Ask whether the concept is abstract — Intermediated settlement was treated as a fundamental economic practice, not a specific technological invention.

Drafting implication: describe the technical problem precisely. If the real contribution is a new way to manage financial obligations, simply reciting the business workflow on a computer may leave the claim focused on the abstract idea. If the contribution is a specific improvement in computer security, data architecture, processing, or network operation, the claims and specification should make that contribution concrete and supported.

9. Applying Step 2 to Alice

• Claim element: Generic computer — What it contributed in the Court’s analysis: Provided a platform to perform the scheme. — Why it was insufficient: Using a computer as a tool did not change the abstract nature of the idea.
• Claim element: Data processing — What it contributed in the Court’s analysis: Created, updated, or consulted records. — Why it was insufficient: Routine data operations were conventional functions.
• Claim element: Communications — What it contributed in the Court’s analysis: Enabled the system and parties to exchange information. — Why it was insufficient: Generic communication functions did not provide an inventive concept.
• Claim element: Elements in combination — What it contributed in the Court’s analysis: Arranged the computer functions to carry out intermediated settlement. — Why it was insufficient: The ordered combination still implemented the abstract scheme through conventional computer operations.

The Court did not say that a computer-implemented invention can never be eligible. It held that the particular claims before it did not describe a sufficient inventive concept.

10. Demonstration: Weak vs. More Technically Grounded Drafting

Example A — high §101 risk

Illustrative Claim Concept: A computer-implemented method comprising: receiving transaction information; storing account balances; determining whether each party has sufficient funds; and authorizing settlement if the balances satisfy a condition.

Why this is vulnerable: it states a financial objective and implements it through generic receiving, storing, determining, and authorizing operations. The computer is described as a tool, while the claimed focus may remain the abstract settlement idea.

Example B — stronger technical focus, not a guarantee

Illustrative Claim Concept: A transaction-processing system that addresses a specified technical failure in distributed settlement by using a defined state-transition protocol, cryptographically verifiable event records, and a concrete recovery sequence that prevents duplicate commitment when nodes lose connectivity.

Why it may be better grounded: the hypothetical identifies a technical problem and concrete system behavior rather than only a business result. Eligibility would still depend on whether the claimed features are genuinely specific, adequately described, non-conventional in the relevant analysis, and claimed with appropriate scope. Merely adding cryptography or distributed-system terminology is not enough.

Example C — words that do not rescue a claim by themselves

Illustrative Claim Concept: Perform the same settlement process using a “specialized processor,” “AI engine,” “blockchain,” or “real-time database,” without explaining a specific technical improvement.

Why this remains risky: naming a modern technology does not explain how the claim improves the technology or transforms the abstract idea into a specific inventive application.

These are educational hypotheticals, not legal advice and not proposed claims for filing.

11. Claim-Drafting Recommendations

Start with a concrete technical problem. — Identify a problem in computer operation—such as latency, memory usage, consistency, fault recovery, security, bandwidth, or data integrity—rather than only a commercial objective.

Explain the technical mechanism. — Describe the architecture, data structures, state transitions, processing sequence, or hardware/software interaction that produces the improvement.

Claim the implementation, not only the result. — Avoid claims that merely say “determine,” “optimize,” “secure,” “match,” or “settle” without specifying how the computer performs the task.

Support the claim in the specification. — Include implementation detail, system diagrams, data-flow descriptions, relevant alternatives, and examples of how the mechanism operates. Do not add unsupported technical features at filing.

Show why the arrangement matters. — Explain how the elements work together and why the ordered combination is not merely ordinary computer activity used to implement the abstract idea.

Use dependent claims strategically. — Add meaningful technical limitations as fallback positions—such as defined data structures, protocol steps, error-handling logic, or resource-management techniques—where supported.

Keep claim scope aligned with disclosure. — Do not claim every way of achieving a business result if the specification only teaches one narrow implementation.

Analyze eligibility alongside other requirements. — Novelty, non-obviousness, enablement, written description, and definiteness remain separate requirements.

Avoid magic-word drafting. — Terms such as “AI,” “blockchain,” “cloud,” “machine learning,” and “real time” are not substitutes for a concrete technical contribution.

12. A Practical Drafting Workflow

• Stage: 1. Problem statement — Question to answer: What technical limitation exists in the current systems? — Drafting output: Specific problem statement tied to computer operation.
• Stage: 2. Mechanism — Question to answer: What exact steps or architecture solve it? — Drafting output: Flowchart, system diagram, and detailed description.
• Stage: 3. Technical effect — Question to answer: What measurable or observable improvement results? — Drafting output: Supported explanation and examples; measurements where available.
• Stage: 4. Claim focus — Question to answer: Does the independent claim recite the mechanism, or only the desired result? — Drafting output: A claim whose limitations define the technical implementation.
• Stage: 5. Alternative embodiments — Question to answer: What variations preserve the same technical principle? — Drafting output: Supported alternative implementations and dependent claims.
• Stage: 6. §101 stress test — Question to answer: Could the claim be summarized as an abstract idea plus routine computer activity? — Drafting output: Revise where the actual contribution is not clearly reflected in the claim.
• Stage: 7. Full patentability review — Question to answer: Are novelty, non-obviousness, enablement, written description, and definiteness addressed? — Drafting output: Separate legal and technical review.

13. Drafting Demonstration: Turning a Business Goal into a Technical Disclosure

Suppose the business goal is “reduce failed online settlements.” A weak specification may repeat that goal and list generic components: a server, database, and processor. A more useful technical disclosure would identify a concrete system failure and explain a reproducible mechanism that addresses it.

• Weak description: “The system securely processes transactions.” — More useful technical description: Specify the threat or failure mode, the information protected, the verification steps, and how the system handles invalid or repeated messages.
• Weak description: “The system stores transaction data in a database.” — More useful technical description: Describe the relevant record structure, state transitions, consistency rules, and how conflicting updates are detected or resolved.
• Weak description: “The system prevents duplicate settlement.” — More useful technical description: Explain the concrete idempotency or commitment protocol, the conditions for state change, and the recovery behavior after interruption.
• Weak description: “The system uses AI to identify risk.” — More useful technical description: Specify inputs, model role, system integration, output handling, and the technical improvement attributable to the claimed implementation.

DRAFTING PRINCIPLEThese descriptions are examples of disclosure specificity, not safe-harbor phrases. A claim still needs a careful legal analysis under Alice and the applicable patentability requirements.

14. Common Mistakes to Avoid

Assuming that putting an abstract idea on a computer automatically creates eligibility.

Relying only on a generic processor, server, database, network, or user interface.

Describing a desired outcome without explaining the technical means that achieve it.

Treating novelty or commercial value as a substitute for §101 eligibility.

Adding technical vocabulary without describing a real technical mechanism.

Ignoring the claim as a whole and the ordered combination of its elements.

Claiming a broad result that extends beyond the technical implementation actually disclosed.

15. Relationship to Earlier and Later Cases

• Case: Gottschalk v. Benson (1972) — Core principle: A claim cannot monopolize an abstract mathematical algorithm in substance. — Relationship to Alice: Part of the foundation for the abstract-idea exception.
• Case: Parker v. Flook (1978) — Core principle: Conventional post-solution activity may not make an otherwise ineligible claim eligible. — Relationship to Alice: Supports scrutiny of what is added to the idea.
• Case: Diamond v. Diehr (1981) — Core principle: A specific industrial process can be eligible when the claim is considered as a whole. — Relationship to Alice: Contrast with generic computer implementation of an abstract idea.
• Case: Bilski v. Kappos (2010) — Core principle: Hedging claims were abstract; machine-or-transformation is not the exclusive test. — Relationship to Alice: Precursor to the modern framework.
• Case: Mayo v. Prometheus (2012) — Core principle: Routine steps added to a natural law may not create an inventive concept. — Relationship to Alice: Alice adapted the Mayo two-step framework to abstract ideas.
• Case: Enfish v. Microsoft (Fed. Cir. 2016) — Core principle: Certain claims to a specific improvement in computer functionality can be eligible. — Relationship to Alice: Illustrates that software claims are not categorically excluded.
• Case: McRO v. Bandai (Fed. Cir. 2016) — Core principle: Specific rules for automating animation were treated as a technological improvement rather than merely stating a result. — Relationship to Alice: Shows the importance of specific claimed rules and implementation.

16. What Alice Does — and Does Not — Hold

• Alice holds: Generic computer implementation alone may not transform an abstract idea into eligible subject matter. — Alice does not hold: All software is unpatentable.
• Alice holds: Courts assess the claim’s focus and the additional elements, individually and as an ordered combination. — Alice does not hold: Any claim mentioning finance, business, data, or computers is automatically abstract.
• Alice holds: An inventive concept must be more than routine computer activity used to implement the abstract idea. — Alice does not hold: Adding technical words or a computer component automatically cures a §101 problem.
• Alice holds: The claims before the Court were ineligible. — Alice does not hold: Every claim to a computer-implemented process fails §101.

17. Ratio Decidendi

RATIOA claim directed to an abstract idea is not patent-eligible under §101 when its additional elements, individually and as an ordered combination, amount to no more than generic computer implementation and fail to supply an inventive concept. In Alice, the abstract idea was intermediated settlement, and the claimed computer functions did not transform it into a patent-eligible invention.

18. Key Terms

• Term: Abstract idea — Meaning: A judicial exception covering certain fundamental concepts, economic practices, and methods of organizing human activity.
• Term: Patent eligibility — Meaning: The §101 threshold inquiry into patentable subject matter and judicial exceptions.
• Term: Inventive concept — Meaning: Additional claim elements sufficient to transform a claim directed to an exception into a patent-eligible application.
• Term: Ordered combination — Meaning: The claim elements considered together in the arrangement claimed.
• Term: Generic computer implementation — Meaning: Use of ordinary computing functions without a sufficient specific technological contribution.
• Term: Pre-emption — Meaning: Concern that a claim may monopolize a fundamental idea or basic tool of innovation.
• Term: Technical improvement — Meaning: A specific improvement in computer or other technology, as opposed to merely using technology to carry out an abstract objective.
• Term: Dependent claim — Meaning: A claim that incorporates another claim and adds further limitations.

19. Primary Sources and Further Reading

Official U.S. Reports case record — GovInfo https://www.govinfo.gov/app/details/USREPORTS-573/USREPORTS-573-208

Official U.S. Reports PDF — Supreme Court opinion https://www.govinfo.gov/content/pkg/USREPORTS-573/pdf/USREPORTS-573-208.pdf

Cornell Legal Information Institute — full opinion https://www.law.cornell.edu/supremecourt/text/13-298

Supreme Court docket — No. 13-298 https://www.supremecourt.gov/search.aspx?filename=/docketfiles/13-298.htm

35 U.S.C. §101 — Patentable subject matter https://uscode.house.gov/view.xhtml?req=granuleid:USC-prelim-title35-section101&num=0&edition=prelim

USPTO — subject matter eligibility guidance portal https://www.uspto.gov/patents/laws/examination-policy/subject-matter-eligibility

20. Final Takeaway

Remember This: Alice is not a rule against software patents. It is a rule against claiming an abstract idea and relying on generic computer implementation to make it patentable. Stronger drafting identifies and claims a concrete technical mechanism, explains how it works, and supports the scope sought—without assuming that wording alone guarantees eligibility.

Educational case summary and drafting guidance only; not legal advice. Patent eligibility is fact-specific and depends on the actual claims, specification, prosecution history, relevant precedent, and current USPTO practice.

Related patent research

Bilski v. Kappos (2010): Business methods and abstract ideas

Diamond v. Diehr (1981): Computer-implemented industrial processes

Explore Rightium's patent search and prior-art research services