Can Software Be Patented? A Software Patent Attorney Explains

Yes. Software-related inventions can be patented in the United States. But using software does not, by itself, make an invention patent eligible. The analysis turns on the invention actually claimed: what the claim requires the system or process to do, how its elements work together, and whether it satisfies the applicable legal requirements.

For a developer, the useful starting question is often: what did you change about the way the technology works? A product’s feature list may explain its commercial value without identifying the technical invention that a patent application needs to describe.

I am J. Matthew Miller, III, a registered U.S. patent attorney and Special Counsel at Kean Miller in New Orleans. Before becoming an attorney, I worked as a professional software engineer, and I earned my B.A. at Duke University with majors in Computer Science and Psychology. That background informs my approach to software patent preparation and prosecution: understand the implementation before trying to define the invention. You can read more about my background and in my Kean Miller biography.

What makes a software invention patent eligible?

Section 101 of the Patent Act identifies eligible categories of inventions, including processes and machines. Courts also recognize exceptions for abstract ideas, laws of nature, and natural phenomena. Software claims commonly raise the abstract-idea question. There is no rule excluding all software from patent protection.

The Supreme Court’s Alice/Mayo framework asks whether a claim is directed to a judicial exception and, if so, whether its additional elements, considered individually and as an ordered combination, supply an inventive concept sufficient to transform it into a patent-eligible application. Merely implementing an abstract idea on a generic computer does not accomplish that. See Alice Corp. v. CLS Bank International, 573 U.S. 208 (2014).

In examination, the USPTO applies that framework through the analysis in MPEP § 2106:

1. Step 1: Does the claim fit a statutory category?
2. Step 2A, Prong One: Does it recite a judicial exception? The USPTO groups abstract ideas into mathematical concepts, certain methods of organizing human activity, and mental processes.
3. Step 2A, Prong Two: If an exception is recited, does the claim as a whole integrate it into a practical application? A qualifying improvement to computer functionality or another technology can support eligibility here.
4. Step 2B: If the claim remains directed to an exception, do the additional elements amount to significantly more than the exception itself? This is the inventive-concept inquiry.

“Practical application” has a specific role in this analysis. It does not mean merely that a product is useful, commercially valuable, or deployed in a particular industry.

Is patent eligibility the same as patentability?

No. Eligibility is one requirement. A new idea can still fail § 101, and an eligible invention can fail other requirements. Those other questions include:

• Novelty, § 102: Is the claimed invention already disclosed in qualifying prior art? See the USPTO’s overview of the AIA prior-art framework.
• Nonobviousness, § 103: Would the claimed invention as a whole have been obvious to a person of ordinary skill in the relevant art before its effective filing date? This can involve combinations of prior-art teachings. See MPEP § 2141.
• Disclosure and claim clarity, § 112: Does the application adequately describe and enable the claimed invention, and do the claims define their subject matter with the required certainty? The USPTO discusses these separate requirements for computer-implemented inventions in MPEP § 2161.01.

Calling a feature “innovative” does not resolve these questions. A patent strategy needs to consider them separately, even when the same technical facts matter to more than one inquiry.

Why does the technical implementation matter?

Consider two descriptions: “the software retrieves results faster” and “the system uses this data layout and these lookup steps to avoid these repeated reads.” The second gives the attorney something concrete to investigate. Which operation changes? Why does it change? What tradeoffs or constraints does the implementation introduce?

Architecture identifies where the work happens. Data structures explain what information is stored and how it is accessed. Algorithms describe the processing steps. System interactions show how components coordinate, exchange messages, maintain state, or recover from failures. Together, these details help distinguish the proposed invention from an instruction to achieve a result.

The USPTO’s August 4, 2025 eligibility memorandum emphasizes evaluating the whole claim, avoiding oversimplification, and distinguishing a technological improvement from using a computer as a tool. It also cautions against treating limitations that cannot practically be performed in the human mind as mental processes. That does not remove other possible abstract-idea issues, including mathematical concepts.

For drafting, I want to connect three things: the technical problem, the disclosed mechanism that addresses it, and the features the claims actually require. Simply adding more engineering vocabulary does not establish that connection. Nor does a bare assertion that the software is faster or more secure.

Section 112 creates a related but distinct reason to get the description right. Written description concerns whether the application conveys possession of the claimed invention when filed. Enablement concerns whether a skilled person can make and use the claimed invention across its scope without undue experimentation. See MPEP § 2161.01 and § 2164.

Depending on the invention, useful disclosure may include diagrams, processing flows, pseudocode, data formats, and supported alternatives. The right level of detail depends on the claims and technology. The objective is an intelligible technical disclosure, rather than a marketing description or a source-code dump.

What types of software inventions might qualify?

The following are hypothetical directions for investigation, not eligibility conclusions or descriptions of client matters:

• Computer performance: A memory-management or scheduling mechanism that changes how a system allocates resources. The useful questions concern the mechanism and the operations it changes, rather than a general promise of speed.
• Image processing: A particular processing pipeline that addresses image noise or tracking across frames. Identify the transformations, their relationships, and the technical problem they address.
• Network communications: A protocol or coordination mechanism for handling congestion, packet delivery, or synchronization. Explain the messages, state transitions, and interactions between network components.
• Data processing: A data structure or processing arrangement that changes storage or retrieval operations. Improving how a database functions presents a different question from merely organizing business information in a database.
• Security: A mechanism that detects or responds to a defined computer threat through particular system operations. “Use software to detect fraud” alone leaves the implementation and the claimed contribution unresolved.

None of these labels creates a safe harbor. Actual claims and disclosure require analysis. The USPTO’s 2024 Examples 47–49, which remain linked from its current guidance, illustrate how eligibility can differ between claims involving related technology. Example 47 addresses anomaly detection and network security; the examples are teaching materials, not determinations about your invention.

What do the 2025–2026 USPTO updates change?

The relevant updates refine examination guidance and evidence practice; they do not establish blanket eligibility for software.

The USPTO’s December 5, 2025 MPEP notice concerning Ex parte Desjardins addresses improvements to machine-learning technology. The decision concerned training a model on new tasks while protecting performance on earlier tasks. The notice emphasizes reading the specification for a disclosed technological improvement and ensuring the claims reflect it. A claim need not literally announce the resulting benefit, but it must include the components or steps providing the improvement. A conclusory statement of improvement in the specification is insufficient.

Evidence can also matter during prosecution. Subject Matter Eligibility Declarations, or SMEDs, are optional declarations under 37 C.F.R. § 1.132. The USPTO issued updated applicant best practices on April 30, 2026, replacing its December 2025 applicant best-practices memorandum, followed by a September 29, 2026 supplement and analysis flowchart. The September memorandum recommends focused factual evidence, identifying the eligibility issue being addressed, and considering submission early in prosecution. It expressly does not announce a new practice or procedure.

The December 4, 2025 memorandum to examiners explains an important limit: a declaration can help establish how a skilled person would understand the disclosed invention, with evidence connected to the claims. It cannot supply information that was required in the original disclosure when filed. A declaration is not a substitute for a properly prepared application.

These are USPTO examination materials. Courts apply controlling judicial precedent; agency guidance is not a guarantee of how a court will decide eligibility. The USPTO maintains its current guidance, examples, and subsequent updates in one place. This discussion reflects the materials available on October 19, 2026.

What should a software inventor prepare for a patent attorney?

Prepare an explanation that another technically trained person can follow, including what is distinctive and how you know. After an engagement is established and counsel provides an appropriate way to exchange materials, the following can make the discussion more productive:

• The problem and earlier approaches: What limitation are you addressing? Bring known patents, papers, products, documentation, and relevant open-source projects. Explain the differences without assuming that a different product name makes the technology new.
• Architecture and diagrams: Identify components, deployment boundaries, data flows, interfaces, and which device or service performs each operation.
• Implementation details: Explain algorithms, data structures, state changes, and important edge cases. Identify which features are essential and which are implementation choices.
• Support for the asserted improvement: Bring available measurements, test conditions, comparisons, and known limitations. Distinguish measured results from expectations.
• People and ownership: Identify who contributed to the inventive concepts and relevant employment, contractor, or collaboration agreements. Authorship of code and patent inventorship are different questions.
• A dated disclosure timeline: Identify demonstrations, conference talks, papers, public repositories, offers for sale, customer access, and planned releases. Include what was disclosed, to whom, and under what confidentiality arrangements.

Discuss timing before publishing or launching when possible. U.S. law provides limited exceptions for certain inventor-originated disclosures made within one year before the effective filing date, but those exceptions are not a general permission to disclose first. Foreign rights may be lost through a prefiling disclosure even where a U.S. exception could apply. See MPEP § 2153 and the USPTO’s international-filing guidance. If disclosure has already occurred, have counsel assess the actual dates and circumstances promptly.

An inquiry does not create an attorney-client relationship. Please do not send confidential information unless you have already signed paperwork to engage Kean Miller to represent you.

Why work with a patent attorney who understands software development?

Developers and patent attorneys need a shared understanding of the invention. Firsthand development experience can help an attorney follow an architecture discussion, recognize an unstated implementation assumption, and ask whether an apparent limitation is essential to the approach or simply a choice made in one version.

My engineering background gives me practical context for those discussions. I am interested in how the algorithm interacts with the data model, where the system maintains state, and why a particular arrangement changes its operation. Those questions help turn an invention disclosure into a technical description and proposed claims. During prosecution, the same understanding helps in comparing the claims with cited prior art and explaining the disclosed technology to the examiner.

My representative patent experience includes preparing and prosecuting an application for data-mining software and obtaining protection for wide-area network resource management. Separately, I am a named co-inventor on three issued U.S. patents titled Video surveillance system. Those inventor credentials are distinct from my work as counsel for clients; neither establishes the eligibility of a different invention.

If you are evaluating a software invention, start by identifying the technical problem, the mechanism you developed, and any upcoming disclosure dates. My software patent practice page explains how that technical background fits my legal work. Contact me at Kean Miller to discuss a potential engagement, without sending confidential details.

This article provides general information about U.S. patent law, not legal advice about a particular invention. Patent eligibility and the other requirements depend on the claims, disclosure, prior art, and applicable law.