So you think you have a software patent. Do you really?
Software and computer-implemented inventions remain patentable in the United States. They are also where more patents go to die than almost anywhere else, because the line between “eligible” and “abstract idea on a computer” is narrow, unforgiving, and rewards the people who think about it while they are building, not after.
If you forget everything else in this article, let this be your one takeaway. The patent system will protect software in one of two situations: when it improves how the computer itself works (faster, more secure, a better data structure), or when it uses the computer to improve some other technical field (a manufacturing process, a sensor, a communications network, a navigation system). It will refuse software that takes a task humans or businesses could do anyway and simply runs it on a computer.
The key word here is technical. The improvement has to land in an engineering or applied-science domain. Improving a business, financial, or organizational practice, hedging risk, settling transactions, or scheduling events are improving a “method of organizing human activity,” and running it on a computer does not convert it into a patentable technology.
Here is the same takeaway phrased differently: imagine explaining your invention to a senior software engineer at another company. If their reaction is “okay, so you computerized the thing your industry used to do by hand,” you are in the danger zone. If their reaction is “huh, that’s a clever way to make the system itself behave better,” you are in the patentable zone.
That distinction is not a stylistic preference. It is the law. Below is how to think about it before you spend money on a patent application.
A QUICK WORD ON WHY THIS IS HARD
35 U.S.C Section 101 says you can patent any new and useful “process, machine, manufacture, or composition of matter.” Software inventions almost always fit one of those categories on paper. The problem is a judge-made exception: you cannot patent an “abstract idea,” even a brilliant one.
Courts apply a two-step test (often called Alice/Mayo, after Alice Corp. v. CLS Bank, 573 U.S. 208 (2014)). The USPTO has refined it into a sequence its examiners actually use:
Step 2A, Prong One: Does the claim recite an abstract idea (a mathematical concept, a method of organizing human activity, or a mental process)?
Step 2A, Prong Two: If so, does the claim integrate that idea into a practical application, typically by improving the functioning of a computer or another technology?
Step 2B: If not, does the claim add an inventive concept, “significantly more” than the abstract idea performed on generic, conventional hardware?
You win if you clear Prong Two. You also win if you clear Step 2B. You lose if you clear neither. Everything that follows is about giving yourself the cleanest possible path through that gauntlet.
STEP 1: REFRAME YOUR PROJECT AROUND A TECHNICAL PROBLEM
Most engineers and founders describe their work in business terms: “We help insurers price risk faster.” “We let warehouses route inventory automatically.” “We match riders to drivers.”
Patents do not work that way. The USPTO and the courts want to see a technical problem in computing or some other technology, AND a technical mechanism that solves it.
So before any patent conversation, translate the project into technical-problem language.
Two examples:
Example 1
Business framing: “We let users find files faster across their drives.”
Technical framing: “ The information management and database system of the present invention comprises a flexible, self-referential table that stores data. The table of the present invention may store any type of data, both structured and unstructured, and provides an interface to other application programs. The table of the present invention comprises a plurality of rows and columns. Each row has an object identification number (OID) and each column also has an OID. A row corresponds to a record and a column corresponds to a field such that the intersection of a row and a column comprises a cell that may contain data for a particular record related to a particular field, a cell may also point to another record. To enhance searching and to provide for synchronization between columns, columns are entered as rows in the table and the record corresponding to a column contains various information about the column. The table includes an index structure for extended queries.”
(That is, in substance, the invention the Federal Circuit upheld in Enfish, LLC v. Microsoft Corp., 822 F.3d 1327 (Fed. Cir. 2016) — a specific improvement to how the computer stores and retrieves data, not an abstract idea that happens to run on a computer.)
Example 2
Business framing: “We keep users from downloading malware.”
Technical framing: “Traditional virus scanners only recognize code that matches a database of already-known threats, so they miss new or disguised viruses. We generate a security profile that flags the suspicious behaviors of a downloadable file before it executes, and we link that profile to the file, allowing the system to catch previously unseen threats.”
(That is essentially Finjan, Inc. v. Blue Coat Systems, Inc., 879 F.3d 1299 (Fed. Cir. 2018), where behavior-based scanning was held to be a genuine improvement in computer functionality.)
Notice that the technical framings are not just dressed up with jargon. They are specific about what was broken in the technology and what technical thing fixes it. That specificity is the thing patents protect.
If you cannot write a technical framing of your invention, that is a signal. Either dig deeper into what is actually new about your technical approach, or accept that this work may not be patentable, which is fine. Trade secrets, copyright in your source code, and first-mover advantage may serve you better.
STEP 2: FIND OUT WHERE YOUR TECHNICAL IMPROVEMENT ACTUALLY LIVES
Sit down with your engineering team and answer this concretely: “if a competitor stripped away everything generic and used only what is genuinely new about our approach, what would be left?”
That residue is your invention. The following are almost never the answer:
“Our business logic” (automating a human or commercial process is the classic abstract idea)
“Our data” or “the dataset we trained on”
“Our user interface,” standing alone (merely reciting a GUI does not make a claim eligible)
“We do it faster than people could” (speed and efficiency from using a computer are not enough. See Electric Power Group, LLC v. Alstom S.A., 830 F.3d 1350 (Fed. Cir. 2016), and Recentive Analytics, Inc. v. Fox Corp., 134 F.4th 1205 (Fed. Cir. 2025))
“We’re the first to do this in [industry]” (an abstract idea does not become eligible by limiting it to one field of use)
The answer should look more like:
A specific data structure that the system uses to store and retrieve information more efficiently”
A non-conventional arrangement of known components that solves a problem the conventional arrangement could not. That was the inventive concept that saved the claims in BASCOM Global Internet Services, Inc. v. AT&T Mobility LLC, 827 F.3d 1341 (Fed. Cir. 2016)
A particular set of rules that automates a process in a fundamentally different way than humans did it. Those were the kind of specific rules upheld in McRO, Inc. v. Bandai Namco Games America Inc., 837 F.3d 1299 (Fed. Cir. 2016)
A specific method of navigating or presenting data that improves how the device itself functions. That was the inventive concept in Core Wireless Licensing S.A.R.L. v. LG Electronics, Inc., 880 F.3d 1356 (Fed. Cir. 2018) and in Data Engine Technologies LLC v. Google LLC, 906 F.3d 999 (Fed. Cir. 2018)
If you find more than one such answer, you may have more than one patentable invention. Track them separately.
The dividing line across all of these cases is the one the Enfish court drew: is the claim directed to an improvement in how the computer or technology operates (eligible), or is the computer merely a tool used to carry out an abstract idea (not eligible)? Put your invention on the right side of that line, or consider other forms of IP protection.
STEP 3: WHERE IS YOUR IMPROVEMENT WRITTEN DOWN? THE SPECIFICATION IS THE BATTLEGROUND
This is the step most teams skip, and it decides cases.
When courts uphold software patents, they almost always point to the specification, that is, the written description in the patent, to confirm that the invention is a real technical improvement. In Finjan and Core Wireless, the Federal Circuit relied on the specification’s explanation of what was wrong with the prior art and how the claimed invention fixed it. The same logic now drives examination at the USPTO: under the precedential Ex parte Desjardins decision (designated precedential November 4, 2025, and incorporated into the USPTO Manual of Patent Examining Procedure), USPTO patent examiners are instructed to look to the specification for a detailed, non-conclusory disclosure of a technical improvement, and not to dismiss claim limitations as “generic computer components” when those limitations actually confer the improvement.
What does that mean? It means that a thin specification that merely recites a result will sink you. A specification that explains the mechanism will carry the day.
For each piece of technical novelty you identified in Step 2 above, your team should be able to answer four questions clearly, and those answers should appear in the application:
1. “What was wrong with the prior state of the art?” Be specific. Not “the old systems were slow,” but “the conventional architecture required redirecting the user to a third-party page, which broke the host site’s control over the transaction” (the problem DDR Holdings, LLC v. Hotels.com L.P., 773 F.3d 1245 (Fed. Cir. 2014), solved).
2. “What is the mechanism of your improvement?” How it actually works, not just what it achieves.
3. “What is the measurable result?” Latency cut by X%, memory footprint reduced by Y, throughput increased to Z.
4. Why does the mechanism produce that result? The causal story tying the technical choice to the outcome.
A practical tip: run an internal “invention disclosure” review for each candidate before engaging counsel. Have the inventors write the four answers above in a two to three-page document. It dramatically improves the quality of the application and lowers the cost of prosecution.
STEP 4: CLAIM THE MECHANISM, NOT THE RESULT
Here is a sentence worth taping to your monitor, from the Finjan case: “a result, even an innovative result, is not patentable.” Claims that recite a desired outcome such as “a system that detects fraud” or “a method of optimizing routes” invite a § 101 rejection from the patent examiner. Claims that recite the specific steps or structure that accomplish the outcome are what survive.
Two related points your patent attorney will care about:
Avoid total preemption. In McRO, the court asked whether the claims would lock up every way of achieving the result, or only the specific way the inventor developed. Claims tied to a particular technical solution, rather than to the abstract goal itself, are far stronger. Consider claims of varying breadth: some narrow and specific, some broader, so you are not betting the whole portfolio on a single claim scope.
Generic hardware will not save a generic idea. Reciting “a processor,” “a memory,” and “a non-transitory computer-readable medium” adds nothing if the underlying idea is abstract. The inventive concept has to be in the arrangement or the operation, as it was in BASCOM, not in the boilerplate.
STEP 5: TIMING IS EVERYTHING
Patents protect what you have actually invented at the time you file, not the version that might be patentable once you finish refining it.
Some practical timing rules:
File when the technical mechanism is real, not merely when the idea exists. A working implementation with measured improvements over a baseline is enormously stronger than a concept.
File before public disclosure. A conference talk, a blog post, a published paper, an open-source release, or a sales demo can start clocks and create prior art against you. After a U.S. public disclosure you have a one-year grace period to file, but most other countries grant no grace period at all, so a public disclosure can permanently destroy your foreign rights.
File before launching publicly if international protection matters to your business.
Consider a provisional application if you have a real invention but need time to refine it. A provisional gives you 12 months to file the full application while locking in your priority date.
STEP 6: KNOW THE NEW TOOLS AND KEEP A CREDIBLE EXPERT CLOSE
The examination climate for software has shifted in your favor over the last two years, and you should use it.
The USPTO’s 2024 guidance update (effective July 17, 2024) and its August 4, 2025 memorandum to the software art units reminded examiners not to over-apply the abstract-idea exception and to credit claims that tie an idea to a concrete technical improvement.
Ex parte Desjardins, now precedential and embedded in the MPEP, instructs examiners to evaluate software and machine-learning claims under the Enfish “improvement” lens and warns them not to analyze claims at so high a level of generality that the actual improvement disappears.
The Subject Matter Eligibility Declaration (SMED) is a procedural tool for fighting back against a § 101 rejection. In plain terms, a SMED is a sworn declaration (under Rule 132) from a qualified technical expert explaining why a person skilled in the field would understand your invention as a genuine technical improvement, not abstract math. It cannot fix a vague specification, and importantly anything you put in it can be used against the patent later in litigation, so it is drafted with care.
You do not need to file a SMED proactively. But you should think early about who could serve as a credible declarant: a respected engineer, a researcher, an academic in your field. Relationships built during the inventive process such as advisory boards, collaborations, co-authored work, create options later.
One caution that the favorable climate does not change: examination and litigation are different battlefields. The USPTO is more willing to grant software patents right now. Courts apply the same Alice/Mayo framework they have applied for a decade. A patent that gets through examination but cannot survive a motion to dismiss in court is not worth much. Draft for both.
COMMON MISTAKES. DON’T DO THAT. PLEASE DON’T.
Pitching the business problem instead of the technical mechanism. Your patent attorney can only work with what you give them. If your disclosure reads like a sales pitch, the patent application will too, and so a rejection will be more likely.
“We use a computer to...” claims. Almost any claim framed as “we use software to [do the thing people already did]” is in trouble. The invention has to live in the “how”, not in the application of computing to a domain. This is exactly why Recentive lost: applying generic machine learning to the new field of event scheduling, without improving the machine learning itself, was held ineligible and the Supreme Court declined to disturb that holding in late 2025.
Confusing speed with invention. Doing an old task faster because computers are fast is not an invention. Electric Power Group and Recentive both make the point: efficiency gains that flow from using a computer, rather than from an improvement to the computer, do not confer eligibility.
Claiming the result instead of the steps. “A method that produces [outcome]” is not a claim; it is a wish. Recite the specific steps or structure.
Treating a user interface as automatically eligible. Core Wireless and Data Engine won because the GUIs were specific improvements the specification explained in detail. Merely reciting “a graphical user interface” does not clear § 101.
Starving the specification. If the written description does not explain the prior-art problem and the mechanism of your fix, you have handed the examiner (and later, opposing counsel) the abstract-idea argument for free.
Mistaking the friendlier USPTO posture for a free pass. It is easier to get a software patent issued today than it was three years ago. It is not easier to enforce one in court. Build the record for both.
WORKING CHECKLIST. BECAUSE IT WORKS.
Before you engage patent counsel on a software or computer-implemented invention, you should be able to answer “yes” to all of these:
1. We can describe the invention as a solution to a technical problem in computing (or another technology), not just a business problem.
2. The novelty lives in how the computer or system itself works, not in the data, the domain, or the boilerplate hardware.
3. We can articulate the mechanism of the improvement, not just the result it produces.
4. We have measurable evidence that the mechanism produces a technical improvement over a baseline.
5. Our specification (or disclosure draft) explains the prior-art problem and the mechanism in concrete, non-conclusory terms.
6. Our claims will recite specific steps or structure, not a desired outcome, and will not preempt every way of reaching the result.
7. We have not yet publicly disclosed the invention, or we are within the one-year U.S. grace period (and we understand foreign rights may already be at risk).
8. We can identify a credible technical expert who could vouch for the improvement if a § 101 rejection arrives.
If you can check all eight boxes, you are in good shape to move forward. If you cannot, the gaps tell you exactly what to work on first.
THIS GUIDE IS GENERAL INFORMATION, NOT LEGAL ADVICE. PATENT DECISIONS FOR SPECIFIC INVENTIONS SHOULD BE MADE WITH QUALIFIED COUNSEL WHO CAN EVALUATE YOUR PARTICULAR TECHNOLOGY AND BUSINESS SITUATION.