TL;DR
Yes, you can patent software in the United States, but not all software is patentable. Under the Alice/Mayo framework, software claims must do more than implement an abstract idea on a generic computer. To survive a §101 challenge, your claims need to describe a specific technical improvement, whether that is to the computer itself, to another technology, or to a technical process that could not practically be performed by a human mind. How you describe and claim your invention matters as much as what the invention does.
Key Definitions
- 35 U.S.C. § 101
- The section of patent law that defines what types of inventions are eligible for patent protection. It covers any new and useful process, machine, manufacture, or composition of matter.
- Abstract Idea
- A judicially created exception to patent eligibility. Abstract ideas, laws of nature, and natural phenomena cannot be patented. The courts have not provided a precise definition of “abstract idea,” which is a core source of uncertainty in software patent law.
- Alice/Mayo Framework
- The two-step test established by the Supreme Court in Alice Corp. v. CLS Bank International (2014) and Mayo Collaborative Services v. Prometheus Laboratories (2012) for determining patent eligibility under §101.
- Step 2A (Prong One)
- Does the claim recite an abstract idea, law of nature, or natural phenomenon?
- Step 2A (Prong Two)
- If yes, does the claim integrate the judicial exception into a practical application?
- Step 2B
- If not integrated into a practical application, does the claim recite an “inventive concept” that amounts to significantly more than the abstract idea?
- 2019 PEG
- The USPTO's 2019 Revised Patent Subject Matter Eligibility Guidance, which organized abstract ideas into three categories: mathematical concepts, certain methods of organizing human activity, and mental processes.
- Inventive Concept
- Under Step 2B, something in the claim beyond the abstract idea itself that transforms it into a patent-eligible application. Well-understood, routine, and conventional activity does not qualify.
Introduction
“Can you patent software?” is one of the most searched patent questions on the internet, and the answer has gotten more complicated, not less, over the past decade.
The short version: software is patentable in the United States. The USPTO grants thousands of software-related patents every year. But since the Supreme Court's 2014 decision in Alice Corp. v. CLS Bank International, the path to getting a software patent allowed has narrowed considerably. Claims that merely describe an abstract idea implemented on a general-purpose computer are routinely rejected.
The challenge for inventors is that the line between a patentable software invention and an unpatentable abstract idea is not clearly defined. The courts have acknowledged this. The USPTO has acknowledged this. Multiple Federal Circuit judges have called the current framework inconsistent and difficult to apply. And as of early 2026, a high-profile petition (USAA v. PNC Bank, No. 25-853) is asking the Supreme Court to revisit the entire doctrine.
This guide explains the current legal framework, walks through the key cases that define it, and provides practical strategies for framing software claims that survive §101 scrutiny. Whether you are a developer filing your first provisional or a founder working with patent counsel, understanding the eligibility landscape is essential before investing time and money in a software patent application.
The Legal Framework: Alice/Mayo in Plain Language
The foundation of software patent eligibility is 35 U.S.C. § 101, which says you can patent “any new and useful process, machine, manufacture, or composition of matter.” Read literally, that covers almost everything. But the Supreme Court has created three exceptions: laws of nature, natural phenomena, and abstract ideas.
Software patents live and die on the “abstract idea” exception. The test for whether a software claim is patent-eligible comes from two Supreme Court decisions: Mayo Collaborative Services v. Prometheus Laboratories (2012) and Alice Corp. v. CLS Bank International (2014). Together they established a two-step analysis.
Step 1: Is the claim directed to an abstract idea?
The first question is whether the claim, taken as a whole, is directed to a patent-ineligible concept. For software, this usually means asking whether the claim is directed to an abstract idea.
The USPTO's 2019 Revised Patent Subject Matter Eligibility Guidance (the “2019 PEG”) broke this step into two prongs. Prong One asks whether the claim recites an abstract idea at all. The 2019 PEG groups abstract ideas into three categories: mathematical concepts (formulas, calculations, relationships), certain methods of organizing human activity (commercial interactions, managing relationships, following rules), and mental processes (observations, evaluations, judgments that can be performed in the human mind).
If the claim does recite an abstract idea under Prong One, Prong Two asks whether the claim as a whole integrates that abstract idea into a “practical application.” If the claim applies the abstract idea in a way that imposes a meaningful limit on it, the claim is patent-eligible and the analysis stops. The claim does not need to pass Step 2.
Step 2: Does the claim contain an “inventive concept”?
If the claim is directed to an abstract idea and does not integrate it into a practical application, Step 2 asks whether the remaining elements of the claim add something “significantly more” than the abstract idea. This is the “inventive concept” inquiry. Generic computer components performing their ordinary functions (processing data, storing information, transmitting over a network) do not qualify. The claim needs something beyond “apply it on a computer.”
The Cases That Define Software Eligibility
The Alice decision itself involved patents on a computerized escrow system for financial transactions. The Supreme Court held that the claims were directed to the abstract idea of intermediated settlement and that implementing that idea on a generic computer did not add an inventive concept. The opinion has been applied broadly to software and business method patents, though the Court did not mention “software” specifically.
Since Alice, the Federal Circuit has built the case law that determines what software can and cannot be patented. A few decisions stand out as landmarks.
Cases Where Software Claims Survived
Enfish, LLC v. Microsoft Corp. (2016). This case involved a self-referential database structure that improved how computers store and retrieve data. The Federal Circuit held the claims were not directed to an abstract idea because they described a specific improvement to computer functionality. The court explicitly rejected the idea that software claims are inherently abstract, stating that some improvements in computer-related technology, when properly claimed, are “undoubtedly not abstract.” The key was that the specification described the problems with conventional databases and explained how the self-referential structure provided specific technical advantages (faster lookups, more flexible data storage).
McRO, Inc. v. Bandai Namco Games America Inc. (2016). The patents covered a method for automating lip synchronization in animated characters using specific rules applied to phoneme sequences. The Federal Circuit found the claims eligible because they improved an existing technological process (animation). The claimed rules enabled automation of tasks that previously required subjective human judgment. The court emphasized that the improvement came from the specific rules themselves, not just the use of a computer.
Finjan, Inc. v. Blue Coat Systems, Inc. (2018). The patent described a system for identifying malicious code by comparing incoming code to previously analyzed behavior-based security profiles. The Federal Circuit held the claims were directed to a non-abstract improvement in computer security, not the abstract idea of filtering content. The specific technical approach (behavior-based rather than signature-based detection) distinguished the claims from generic content filtering.
Core Wireless Licensing v. LG Electronics (2018). The claims covered an improved user interface for mobile devices that displayed application summaries in a specific way. The court held the claims eligible because they recited a particular manner of displaying information that improved the user experience of mobile devices. The claims contained precise language about what data to display and how to display it.
Cases Where Software Claims Failed
Alice Corp. v. CLS Bank International (2014). The claims described a computer system for managing settlement risk in financial transactions using a third-party intermediary. The Court found this was the abstract idea of intermediated settlement, and the addition of generic computer hardware did not transform it into something patent-eligible.
Electric Power Group v. Alstom (2016). The claims covered methods for monitoring and analyzing electric power grid data in real time. The Federal Circuit held the claims were directed to the abstract idea of collecting, analyzing, and displaying data. The claims did not specify how the data was gathered or analyzed, only that it was.
Recentive Analytics v. Fox Corp. (2025). The patent claimed a system using predictive analytics to generate television advertising proposals. The Federal Circuit found the claims ineligible because using AI or predictive analytics to automate an existing business practice did not, on its own, constitute a technical improvement. Simply labeling a claim with “artificial intelligence” or “machine learning” does not overcome Alice.
USAA v. PNC Bank (2025). The Federal Circuit struck down patents covering USAA's mobile check deposit technology, finding the claims were directed to the abstract idea of depositing a check using a mobile device. The court held that the claim elements recited only routine steps (authenticating customers, capturing images, reading amounts) and were silent on specific software or technical advances. USAA filed a petition for certiorari in January 2026, arguing the Federal Circuit has stretched “abstract idea” far beyond its intended meaning. The Supreme Court has requested a response from PNC, and the case is being watched closely by the patent community as a potential vehicle for revisiting Alice.
What the Pattern Tells You
Looking across the wins and losses, a clear pattern emerges for what makes software claims survive §101.
Claims that survived described specific technical improvements. Enfish improved how databases store data. McRO improved how animation is automated. Finjan improved how malware is detected. Core Wireless improved how mobile interfaces display information. In each case, the specification explained what was wrong with existing technology and how the claimed invention produced a measurable technical benefit.
Claims that failed described results without technical mechanisms. Alice described what a settlement system should do without specifying how. Electric Power Group described collecting and analyzing data without specifying the analysis method. USAA described depositing checks with a mobile device without claiming specific technical advances in how the capture, validation, or processing worked.
The lesson: your claims need to describe how your software achieves its result, not just what result it achieves. And your specification needs to explain why that approach is a technical improvement over what existed before.
Recent Developments: What Changed in 2024, 2025, and 2026
The eligibility landscape continues to evolve. Several developments are shaping how software patents are examined and litigated right now.
The 2024 USPTO Guidance Update. In July 2024, the USPTO issued updated subject matter eligibility guidance with particular attention to AI inventions. The update reaffirmed the 2019 PEG framework while providing additional examples for how eligibility applies to claims involving machine learning, neural networks, and predictive analytics. The guidance emphasized that a claim involving AI is not automatically abstract, but also that labeling something “AI-powered” does not automatically make it eligible.
Ex Parte Desjardins (PTAB, September 2025). In this Appeals Review Panel decision, the PTAB faulted a lower panel for evaluating a machine learning claim at too high a level of generality. The ARP held that Enfish is the proper precedent for evaluating claims directed to improvements in computer technology, including software and ML improvements. The USPTO subsequently updated the MPEP to incorporate this decision. This is a positive signal for software and AI patent applicants, as it requires examiners to look more carefully at whether claims describe genuine technical improvements before rejecting them under §101.
The 2025 USPTO Memo. The USPTO issued a memo reaffirming both the 2024 Guidance and the 2019 PEG, signaling policy continuity. The memo also referenced the Desjardins decision as part of the updated MPEP guidance.
USAA v. PNC Bank (Supreme Court, pending). USAA filed a cert petition in January 2026 after the Federal Circuit invalidated its mobile check deposit patents. The petition raises two questions: whether the Federal Circuit has expanded “abstract idea” to cover concrete technological processes, and whether computer-implemented inventions must improve the computer's own functionality to be patent-eligible. The Supreme Court has requested a response from PNC (due April 8, 2026). If the Court takes the case, it could be the first significant revisitation of Alice since 2014.
AIPLA Amicus Brief (March 2026). The American Intellectual Property Law Association filed an amicus brief supporting USAA's cert petition, arguing that the Federal Circuit's application of Alice Step Two has revived the subjective “invention” requirement that the Patent Act of 1952 was designed to eliminate.
Practical Strategies for Framing Software Claims
Given the current landscape, here are the strategies that give software patent claims the best chance of surviving §101.
Lead with the technical problem and technical solution
Your specification should open by identifying a specific technical problem with existing systems and explain how your invention solves it through a specific technical mechanism. Avoid framing the problem in business terms. “Reducing customer acquisition costs” is a business problem. “Reducing network latency in distributed event processing by implementing a priority-weighted routing algorithm that evaluates queue depth across edge nodes in real time” is a technical problem with a technical solution.
Claim the implementation, not the outcome
The strongest software claims describe how the system works, not what result it produces. Instead of claiming “a system for optimizing delivery routes,” claim the specific combination of data structures, algorithms, processing steps, and system interactions that achieve the optimization. Each element should describe a technical operation, not a business objective.
Anchor claims to concrete technical components
Use specific technical language: processors, memory, databases, APIs, network interfaces, data structures. But go beyond listing hardware. Describe what each component does in the context of your invention's technical improvement. A claim that says “a processor configured to execute instructions” is generic. A claim that says “a processor configured to apply a weighted graph traversal algorithm to a dynamically updated node map, wherein each node's priority score is recalculated based on real-time latency measurements received via a monitoring API” is specific.
Describe what cannot be done in the human mind
One of the three categories of abstract ideas under the 2019 PEG is “mental processes,” which covers concepts that can be performed in the human mind or with pen and paper. If your software does something that a human could practically do manually (evaluating data, comparing values, making a decision based on criteria), your claims are vulnerable. Emphasize the aspects of your invention that require computational capabilities beyond human capacity: real-time processing of large datasets, parallel execution across distributed systems, continuous monitoring of streaming data, or training and inference using machine learning models.
Build a strong specification that supports eligibility
The Enfish and McRO decisions both relied heavily on the specification to establish eligibility. Your specification should explicitly describe the problems with prior art approaches, explain why existing technology was inadequate, detail how your invention improves upon it, and quantify the improvement where possible (faster processing, reduced latency, lower error rates, better accuracy). This narrative supports the argument at Step 2A Prong Two that your claim integrates the abstract idea into a practical application.
Use multiple claim types
Draft system claims, method claims, and computer-readable medium claims. Each type covers a different class of potential infringement. System claims protect the architecture. Method claims protect the process. CRM claims protect the software itself. If one claim type faces eligibility issues, the others may survive.
If you are using Patent Geyser, the platform's workflow is designed around these strategies. Module 1 (Intake & Screening) pressure-tests your invention concept through an Advocate/Examiner AI debate that surfaces both strengths and weaknesses. Module 4 (White Space & Claims) generates claim variations with §101 survival in mind, anchoring claims to concrete technical implementations rather than abstract outcomes. The system prompts in Module 5 explicitly instruct the AI to ground software claims in physical hardware and specific technical operations, following the Enfish framework. But as always, AI-generated claims are a starting point. Have a registered patent practitioner review and refine them before filing.
The SaaS and Blockchain Angle
SaaS and blockchain inventions face the same §101 framework as all software, but with additional nuances.
SaaS inventions often involve multi-tenant architectures, API-driven integrations, real-time data processing, and cloud infrastructure optimizations. The patentable aspects typically lie in the technical implementation, not the business model. A SaaS platform that “connects freelancers with clients” is a business method. A SaaS platform that uses a specific probabilistic matching algorithm running on a distributed event-driven architecture to reduce match latency from minutes to sub-second is a technical invention with a concrete improvement.
Blockchain inventions involve consensus mechanisms, smart contract architectures, cryptographic protocols, and distributed ledger optimizations. Many blockchain patents have faced §101 rejections when claims describe the business application (managing digital transactions) rather than the technical innovation (a novel consensus protocol that reduces confirmation time by eliminating redundant validation rounds). The strongest blockchain patent claims describe specific technical mechanisms in the protocol layer, not the application layer.
For both SaaS and blockchain, the key is the same: describe the technical problem, the technical solution, and the technical improvement. If your description could apply to any technology stack, it is too abstract. If it could only apply to the specific architecture you built, you are on the right track.
Conclusion
Software is patentable in the United States, but the eligibility bar is higher than it was before Alice. The framework rewards specificity: specific technical problems, specific technical solutions, and specific technical improvements. Claims that describe what a system does without explaining how it does it, or that implement a known business practice on generic computing hardware, will face rejection.
The landscape is still evolving. The USAA v. PNC Bank cert petition pending at the Supreme Court could lead to the first significant reexamination of the abstract idea doctrine since 2014. The USPTO's incorporation of the Desjardins decision into the MPEP signals a push toward more rigorous analysis of whether software claims describe genuine technical improvements. And the 2024 AI-focused guidance update clarifies (without fully resolving) how eligibility applies to machine learning and predictive analytics.
For inventors in software, SaaS, and blockchain, the practical takeaway is straightforward: invest in your technical description. The stronger your specification, the stronger your claims. The stronger your claims, the better your chances of getting a patent that survives examination and litigation.
Patent Geyser helps you build that foundation, from brainstorming and prior art research through claim generation and technical diagrams, with §101 eligibility strategies built into every module. But Patent Geyser does not provide legal advice, and its output is a draft, not a filing-ready application. Before you file, have a registered patent practitioner review your application. The PatentFit Directory can help you find one with specific experience in software patent prosecution.
Frequently Asked Questions
The Basics
Is software patentable in the United States?
Yes. Software inventions are patent-eligible under 35 U.S.C. §101, provided the claims describe a specific technical improvement and do not merely implement an abstract idea on generic computing hardware. The USPTO grants thousands of software patents every year. The challenge is not whether software can be patented, but how the claims must be drafted to survive the Alice/Mayo eligibility framework. Claims that describe the technical mechanism (how the software works) rather than just the outcome (what it achieves) have the strongest chance of allowance.
What is the Alice test?
The Alice test is a two-step analysis the USPTO and courts use to determine whether a patent claim is directed to patent-eligible subject matter under §101. Step 1 asks whether the claim is directed to an abstract idea. If yes, Step 2 asks whether the claim contains an “inventive concept” that transforms the abstract idea into something patent-eligible. The test comes from the Supreme Court's 2014 decision in Alice Corp. v. CLS Bank International and its earlier 2012 decision in Mayo Collaborative Services v. Prometheus Laboratories.
How is an “abstract idea” defined?
It is not, at least not precisely. The Supreme Court has declined to define the term. The USPTO's 2019 PEG organizes abstract ideas into three categories (mathematical concepts, certain methods of organizing human activity, and mental processes), but the boundaries remain blurry, especially for software. Multiple Federal Circuit judges have publicly criticized the doctrine as almost impossible to apply consistently. The pending USAA v. PNC Bank cert petition asks the Supreme Court to clarify the definition.
Filing Strategy
How do I make my software patent application survive a §101 rejection?
Focus on three things. First, describe a specific technical problem with existing technology in your specification. Second, describe a specific technical mechanism your invention uses to solve that problem. Third, draft claims that recite the technical implementation, not just the business outcome. If you receive a §101 rejection, you can often overcome it by amending claims to add technical specificity, pointing to specification language that describes the technical improvement, and arguing under the Enfish or McRO frameworks that your claims are directed to a specific improvement in technology. A registered patent practitioner experienced in software prosecution can be extremely valuable here.
Can I patent an AI or machine learning invention?
Yes, but with the same caveats that apply to all software. Simply using “AI” or “machine learning” in your claims does not make them patent-eligible. The 2024 USPTO Guidance Update addressed AI specifically, noting that training a neural network may not recite an abstract idea if the claim does not set forth specific mathematical formulas or equations. The Desjardins decision (2025) further reinforced that ML-related claims should be evaluated under Enfish when they describe improvements to computer technology. The key is describing what the model does differently at a technical level, not just that a model is used.
Patent Geyser is an AI-assisted provisional patent drafting platform specializing in software, SaaS, and blockchain inventions. It does not provide legal advice and does not produce filing-ready patent applications. All AI-generated drafts should be reviewed by a registered patent practitioner before filing with the USPTO.