Software Patent

Software patent is not a distinct, formally defined category at the U.S. Patent and Trademark Office (USPTO) — there is no separate “software patent” statute the way there is for design or plant patents. It is the common working term for a utility patent whose claims are directed to a computer-implemented invention: an algorithm, a data-processing method, a system or apparatus whose novelty resides substantially in what a computer program does. What actually distinguishes software patents from most other technology is not a different statute but a much harder path through the same one: eligibility under 35 U.S.C. § 101 turns on a judicially created “abstract idea” exception, and the Supreme Court’s two-step Alice/Mayo framework causes software claims to fail at the threshold far more often than claims to a mechanical, chemical, electrical, or most biological inventions ever do. For a university technology transfer office (TTO) deciding whether and how to protect a piece of research software, this is not an abstract legal footnote — it directly shapes claim drafting, filing cost, litigation risk, and, often, the decision to patent at all versus license under an open-source model or rely on trade secret protection.

The Statutory Starting Point: 35 U.S.C. § 101

The eligibility inquiry begins with the same broad statute that governs every utility patent. 35 U.S.C. § 101 provides: “Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.” Read literally, a novel software process would seem to fit comfortably inside “process.” But the Supreme Court has long read three implicit exceptions into that language: laws of nature, natural phenomena, and abstract ideas are not patentable subject matter, no matter how narrowly a claim is drafted, because they are treated as the basic tools of scientific and technological work that no one may monopolize. Software claims are tested against the third of these — the abstract-idea exception — and it is that exception, not the text of § 101 itself, that makes software patentability genuinely harder than patentability in most other fields.

The Alice/Mayo Two-Step Framework

The controlling framework comes from two Supreme Court decisions. Mayo Collaborative Services v. Prometheus Laboratories, Inc., 566 U.S. 66 (2012), first set out a two-step test for separating patent-ineligible laws of nature from patent-eligible applications of them. Alice Corp. v. CLS Bank International, 573 U.S. 208 (2014), then extended that same framework to the abstract-idea exception and applied it directly to computer-implemented claims — patent claims to a computerized method of mitigating settlement risk in financial transactions. The Court unanimously held the claims ineligible, and in doing so gave the framework its now-standard two-step form, generally referred to as the Alice/Mayo test:

• Step One. Is the claim, as a whole, “directed to” a patent-ineligible concept — here, an abstract idea? Courts look at what the claim is fundamentally about, not just whether it happens to involve or touch on an abstract concept somewhere in its language.
• Step Two. If so, do the elements of the claim, individually or as an ordered combination, contain an “inventive concept” sufficient to transform the claim into “significantly more” than a patent on the abstract idea itself? Reciting generic, well-understood, routine computer components — a processor, a memory, a network interface — performing their ordinary functions is not enough. The Court in Alice was explicit that merely requiring an abstract idea to be implemented “on a computer” does not supply the necessary inventive concept; simply “applying” an otherwise ineligible concept using conventional technology does not transform it into a patentable invention.

If a claim clears Step One — it is not “directed to” an abstract idea, a law of nature, or a natural phenomenon in the first place — the inquiry ends there and the claim is eligible without ever reaching Step Two. Most mechanical, chemical, and electrical inventions clear Step One routinely, because they are not, at their core, claims to an abstract idea; they are claims to a physical structure, composition, or process. Software inventions are the field where Step One is hardest to clear, because a computer-implemented method can very easily be described, at a high level of generality, as an abstract idea — a mathematical calculation, a way of organizing information, or an automated version of a pre-existing human or business process.

What Counts as an “Abstract Idea” in Software Claims

The USPTO’s own patent-examining guidance (Manual of Patent Examining Procedure, MPEP § 2106) operationalizes Alice/Mayo for examiners as Step 2A (itself split into two prongs — does the claim recite a judicial exception, and if so, is that exception integrated into a “practical application”) and Step 2B (the search for an inventive concept). For software specifically, USPTO guidance groups abstract ideas into three recurring categories: mathematical concepts (formulas, equations, and calculations, however expressed), certain methods of organizing human activity (fundamental economic practices, commercial or legal interactions, managing personal behavior or relationships), and mental processes (concepts that can be performed in the human mind, or with pen and paper, even if the claim recites a computer performing them). Importantly, software is not automatically an abstract idea merely because it involves calculation or data manipulation — a claim to a specific technical improvement in how a computer or network functions can clear Step One entirely, or clear Step Two by supplying a genuine inventive concept rooted in that technical improvement rather than in the underlying idea alone.

Why Software Patents Are Harder to Obtain and Defend Than Most Other Technology

Three practical consequences follow directly from the framework above, and together they explain why software is treated as a categorically harder patenting environment than most other technology areas:

• Software claims disproportionately reach Step One’s abstract-idea inquiry at all. A claim to a novel chemical compound, a mechanical assembly, or most biological inventions (see Patentability of Biological Subject Matter, which works through the same judicial-exceptions doctrine as applied to natural phenomena and products of nature rather than abstract ideas) is rarely even characterized as “directed to” an abstract idea, a law of nature, or a natural phenomenon — it typically clears Step One and the eligibility inquiry ends immediately. A computer-implemented method claim is much more easily framed, by an examiner or an accused infringer’s litigation counsel, as “directed to” an underlying abstract idea (a calculation, a business practice, an organizational scheme) that merely happens to be carried out by a computer — pushing the claim into the much less forgiving Step Two inquiry.
• The bar at Step Two is genuinely demanding. Generic computer hardware performing well-understood, routine, conventional functions does not supply an inventive concept, no matter how commercially valuable or non-obvious the underlying business idea is. This is a categorically different (and, for software, generally harder) hurdle than the novelty and non-obviousness inquiries under 35 U.S.C. §§ 102–103 that every invention — software or otherwise — must also separately clear; see Prior Art and the related guide on 35 U.S.C. § 102: Patent Novelty and Invention Disclosure Timing for that separate analysis. A software claim can be genuinely novel and non-obvious and still fail § 101 if it is not tied to a specific technical improvement.
• Software patents are disproportionately exposed to post-issuance and litigation-stage challenge. Because § 101 eligibility is a question of law that can be raised early — on a motion to dismiss, at summary judgment, or in an inter partes review — a defendant sued for patent infringement on a computer-implemented patent has a comparatively cheap, fast avenue to challenge validity that is far less available against, say, a claimed chemical composition. Multiple empirical studies of Federal Circuit decisions in the years following Alice have found software- and business-method-related claims invalidated under § 101 at substantially elevated rates compared with other technology areas — reported invalidation rates in these studies have varied considerably by study period and methodology (accounts range roughly from the high-40s to mid-80s percent for claims actually reaching a reported Federal Circuit § 101 decision), but every such study agrees on the direction: software and business-method claims are invalidated under § 101 markedly more often than claims in other fields. Treat any single precise percentage cited elsewhere with caution; the consistent, well-documented finding is the elevated-risk trend itself, not one settled figure.

Practical Implications for University Technology Transfer

For a TTO evaluating an invention disclosure that centers on software — a novel algorithm, a data-processing pipeline, a machine-learning method, a simulation tool — Alice/Mayo has concrete downstream effects:

• Claim drafting has to do more work. Claims that merely recite “a computer” or “a processor” performing a described algorithm, without tying that algorithm to a specific improvement in how the computer or a technical system functions, are the paradigm case Alice itself rejected. Claims drafted around a concrete technical problem specific to computing or networked systems — and a technical solution to it — have a materially better chance of surviving both examination and later validity challenge.
• Eligibility risk is a real input into the patent-vs-open-source-vs-trade-secret decision. Because a software patent is more expensive to prosecute defensibly and more vulnerable to invalidation than patents in most other fields, many TTOs weigh open-source release (see Open Source Software Licensing in University Technology Transfer) or trade secret protection more heavily for software inventions than they would for, say, a novel compound or device, where a granted patent is a comparatively durable and defensible asset.
• Where a software patent is still the right call — commonly where the invention is a specific technical improvement to a system’s underlying operation, not just an application of a known method to a computer — the ordinary utility-patent process still applies: a provisional patent application to establish an early filing date, followed by prosecution, and potentially a PCT filing for international coverage. Licensing terms for a granted software patent (see Patent Licensing: Exclusive Terms, Royalties, and Startup vs. Established Deals) also need to account for the elevated post-grant invalidity risk when negotiating royalty structures or warranties with a licensee.

Software Patents in Context: Related Patent-Eligibility Doctrines

Software patentability is one specific application of a broader, judicially created doctrine that also governs other technology areas differently:

• Utility patent — the general statutory category software patents belong to; most utility patents (mechanical, electrical, chemical) rarely encounter the abstract-idea exception at all.
• Patentability of Biological Subject Matter — the same family of judicially created § 101 exceptions (laws of nature and natural phenomena rather than abstract ideas), applied to isolated genes, naturally occurring compounds, and diagnostic methods, with its own controlling case law (Diamond v. Chakrabarty, Association for Molecular Pathology v. Myriad Genetics, and Mayo itself).
• Prior art and 35 U.S.C. § 102 — the separate novelty and non-obviousness inquiry every invention must also clear, independent of § 101 eligibility.
• Patent prosecution — the examination process in which § 101 rejections under the Alice/Mayo framework are most commonly raised and, where possible, overcome through claim amendment.

Worked Examples

Example 1 (ineligible): A patent claim reciting a computerized method of using a computer, a data-processing system, and a communications controller to implement “intermediated settlement” — a third party guaranteeing that both sides of a financial exchange perform — was held ineligible in Alice Corp. v. CLS Bank International, 573 U.S. 208 (2014), because intermediated settlement is a fundamental, centuries-old economic practice, and reciting generic computer components to carry it out added no inventive concept beyond automating a pre-existing practice.

Example 2 (eligible): A patent claim reciting a specific method for generating a “hybrid” web page — combining the visual look and feel of a host website with a third-party merchant’s product data, triggered by a particular way of processing outbound hyperlinks so a visitor is not simply redirected away from the host site — was held eligible in DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245 (Fed. Cir. 2014). The Federal Circuit found the claims “necessarily rooted in computer technology” to solve a problem that arises specifically in networked computing (retaining a website’s visitors despite outbound merchant links), rather than merely taking a pre-internet business practice and instructing that it be performed on a computer.

Counter-example: A patent claim reciting generic “a processor,” “a memory,” and “a communications module” configured to perform a well-known organizational or business practice — verifying a transaction, matching buyers to sellers, tracking inventory — is not, by itself, a software patent that clears Alice. Adding conventional, off-the-shelf computer hardware to implement a pre-existing abstract process is exactly the pattern Step Two’s inventive-concept requirement is designed to exclude, regardless of how commercially valuable or novel the underlying business idea is.