Aug 6, 2026
Enterprise

Software patents are claims on technical inventions, not code alone

In the U.S., software-related patents depend on the claims, the technical solution described, and separate patentability tests.

Wei-Lin Zhao

By Wei-Lin Zhao · AI Correspondent

· 4 min read

Software patents are a loose label for patents on software-related inventions, rather than ownership of code in the abstract. In the United States, eligibility depends heavily on what a patent claim describes: practitioner guidance says a specific technical application may be eligible, while a claim directed only to an abstract idea or a broad result may not be.

A granted patent covers the invention defined in its claims. Eligibility also does not resolve whether an invention is novel or non-obvious. This is a general U.S.-focused explanation, not individualized legal advice.

What the label covers

There is no official, single definition of a “software patent.” A 2007 empirical study constructed its own definition for research purposes. The term is commonly used for patent protection sought for computer-implemented inventions.

Patent claims, rather than a product category, define the covered invention. Practitioner guidance describes common forms of software-related claims as a computer system configured to perform specified actions, a computer-implemented method, or a computer-readable medium configured to cause specified actions.

Three questions to keep separate

“Can we patent this?” combines distinct inquiries.

  • Subject-matter eligibility: Whether the claimed invention is eligible for patent protection. For software-related claims, the abstract-idea limitation is often central.
  • Novelty: Whether the invention meets the novelty requirement.
  • Non-obviousness: Whether the invention meets the non-obviousness requirement.

The USPTO examines applications for novelty, non-obviousness, and subject-matter eligibility. Passing one inquiry does not establish the others.

The U.S. question after Alice

Alice Corp. v. CLS Bank, a 2014 U.S. Supreme Court decision, is a key reference point for software-related eligibility. Practitioner accounts describe a two-step inquiry: whether a claim is directed to an abstract idea and, if it is, whether additional claimed elements make it a patent-eligible application. The assessment depends on the underlying technology and how the claim is written.

Patent practitioners identify a specific improvement in computing as a useful indicator. Their examples include enabling computations that were previously unavailable, speeding a computing process, reducing required computing resources, or using components or an arrangement in an unconventional technical way. These are indicators, not a checklist that guarantees a patent.

Technical mechanism versus user outcome

  • More technically grounded: A claim identifies a particular mechanism and the computing problem it addresses. One practitioner example is a self-referential lookup table used to improve a database system’s memory configuration.
  • More exposed to an abstract-idea objection: A claim mainly describes what a user can accomplish, such as archiving digital images, without specifying the technical means that accomplish it.

A user benefit may be part of the description, but it does not by itself identify a technical contribution. A claim focused on one concrete solution also does not establish rights over every way of addressing the same customer problem.

Why software businesses still care

The issue has been economically significant, although available headline counts are historical. A 2007 study found that software patents then made up 15% of all patents, with more than 20,000 granted annually. It also found that only 5% belonged to software publishers and that large manufacturing firms in industries associated with strategic patenting held much of the total. Those findings describe the period studied, not the current filing market.

A peer-reviewed study published in 2023 characterized Alice as having drastically narrowed software-patent protection. It found that narrower protection was associated with greater open-source activity and improved sales at software firms. The reported relationships are associations, not proof that the narrower legal scope caused either outcome.

A practical starting checklist

  1. Describe the technical problem, not only the buyer problem or product benefit.
  2. Write down the mechanism that addresses it, such as a data structure, processing steps, resource constraint, or system configuration.
  3. Identify any claimed improvement in speed, available computation, resource use, or another aspect of computer functionality.
  4. Review eligibility, novelty, and non-obviousness as separate questions.

This exercise does not predict a filing outcome. It helps distinguish a product concept or customer outcome from the technical invention described in a claim.

Frequently asked questions

What makes software patent-eligible in the United States?

It depends on the technology and the claims. Practitioner guidance says a claim may have a stronger eligibility argument when it identifies a specific technical solution, such as an improvement in computer functionality or an unconventional technical implementation, rather than claiming a broad result or abstract idea.

How did Alice Corp. v. CLS Bank change software patents?

A 2023 peer-reviewed study describes the 2014 Supreme Court decision as drastically narrowing the scope of software-patent protection. Practitioner accounts frame the inquiry around whether a claim is directed to an abstract idea and, if so, whether additional elements make it a patent-eligible application.

Are patent eligibility, novelty, and non-obviousness the same thing?

No. The USPTO examines novelty, non-obviousness, and subject-matter eligibility as separate requirements.

Did narrower software-patent protection affect open source?

A 2023 study found that narrower software-patent protection was associated with greater open-source activity and improved sales at software firms. The study reported associations, not proof that the legal change caused those outcomes.

Sources

More from Enterprise

All Enterprise →