Can You Patent Software, an Algorithm, or an AI Model?

Ask the internet whether software can be patented and you will find two confident answers. One side says no, because software is abstract. The other says yes, because thousands of software patents exist.

Both answers are too lazy to be useful.

Here is the version I wish founders and engineers heard first: a patent does not normally protect a block of code. Copyright protects the code you wrote as an expression. A patent, where available, protects an invention described through technical features and defined by claims—even if a competitor later implements those features with entirely different code.

That is why the honest answers to three common questions are all “sometimes”:

• Can software be patented? Sometimes.
• Can an algorithm be patented? Sometimes, when it is part of more than an abstract method.
• Can an AI model be patented? Sometimes, when the claimed invention is a concrete technical solution rather than the label “AI” attached to a result.

I know “sometimes” is not the satisfying answer. But it leads to the useful question: what technical problem does the invention solve, how does it solve it, and what exactly would the patent claim?

The three things people keep mixing up

These three layers are easy to collapse into one.

The code is the particular source text: the functions, variable names, structure, and implementation you wrote. Copyright can protect that expression, but it does not normally stop somebody from independently writing different code that performs the same function.

The algorithm is the logic or mathematical procedure. A sorting rule, scoring formula, optimization method, or neural-network architecture may be intellectually impressive and commercially valuable. In the abstract, however, mathematical methods and abstract ideas are commonly excluded from patent protection.

The computer-implemented invention is the algorithm operating inside a defined technical system to produce a technical result. That might be a controller that changes battery charging in response to predicted degradation, an image-processing pipeline that compensates for sensor distortion, or a scheduling method that reduces congestion in a communications network.

The third layer is usually where a credible patent case begins. The code is one implementation. The invention is the technical teaching underneath it.

In the US, adding “on a computer” changes nothing

In the United States, a software or AI claim must first fit within patent-eligible subject matter under 35 U.S.C. 101. Courts have created exceptions for abstract ideas, laws of nature, and natural phenomena. That means adding “using a computer” to an abstract business rule does not automatically turn it into an invention.

The USPTO’s current subject-matter eligibility guidance asks, among other things, whether a claim is directed to a judicial exception and whether it integrates that exception into a practical application. Its AI examples deliberately contrast claims that merely recite mathematical concepts with claims that use them in a concrete application.

Eligibility is only the first gate. The invention must still be new, useful, and non-obvious, and the application must describe it adequately. A claim can be perfectly “technical” and still fail because an earlier patent or paper already disclosed it. It can also fail because the application promises a function without teaching how to achieve it.

This is why software patentability is not a naming exercise. “AI-powered,” “cloud-based,” and “implemented by a processor” are decorative unless the application explains the engineering underneath them.

Europe asks whether the contribution is technical

Europe uses different language but arrives at a related practical challenge. Under the European Patent Convention, computer programs and mathematical methods “as such” are excluded. Computer-implemented inventions can nevertheless be patentable when the relevant features contribute to the invention’s technical character and help solve a technical problem.

The EPO’s 2026 guidance states that AI and machine-learning models are abstract mathematical in nature by themselves. Their use does not automatically make an invention unpatentable. They can contribute when applied to a technical purpose or adapted to a specific technical implementation.

The EPO gives useful examples. A neural network used in a heart-monitoring apparatus to identify irregular heartbeats can make a technical contribution. So can classification of images, video, audio, or speech based on low-level signal features. By contrast, classifying text only by its linguistic content is not automatically a technical purpose.

There is no single worldwide “software patent” rule. That is inconvenient, but the drafting lesson is simple: describe the real engineering thoroughly enough that different legal frameworks can see it.

Four sentences that expose the difference

Compare these pairs.

Weak: “Use AI to reduce energy consumption”

The statement contains a goal and a fashionable tool, but no invention. What consumes the energy? Which signals are observed? What does the model predict? Which physical operation changes? Why does that change reduce consumption rather than merely reporting it?

Stronger: adaptive control of an industrial cooling system

The system receives temperature, pressure, flow, and compressor-state data; generates a near-term thermal-load prediction; constrains the prediction according to equipment limits; and changes compressor sequencing to reduce peak demand while maintaining a defined temperature range. The model, control loop, constraints, and equipment interaction can now be searched and described.

Weak: “An algorithm that ranks the best suppliers”

This may be commercially useful, but ranking business options from commercial data looks much closer to an abstract decision process.

Stronger: network routing under changing radio interference

The method measures channel conditions at defined intervals, produces a congestion estimate from link-level data, assigns packets across routes under latency constraints, and updates the routing table when a threshold is crossed. The claim is no longer “choose the best option.” It is tied to the operation of a communications system.

Neither stronger example is guaranteed a patent. They have simply crossed the line from slogan to mechanism, which is where the patent question becomes worth asking.

“It uses a neural network” is not a disclosure

AI applications have a particular drafting trap: the model becomes a black box in the exact sentence where all the interesting work happens. I see the same shortcut constantly.

“The model generates an optimized output” tells the reader almost nothing. A useful draft may need to explain:

• what the input represents and how it is obtained;
• preprocessing and feature construction;
• the relevant model architecture or processing stages;
• how training and inference are performed;
• constraints, thresholds, feedback, or post-processing;
• how the output changes a technical system; and
• which alternatives produce the same technical effect.

Not every application needs source code, exact weights, or the complete training dataset. But if the effect depends on particular dataset characteristics, those characteristics may need to be disclosed. The EPO specifically notes that training-data features required to reproduce a technical effect should be explained when a skilled person could not otherwise determine them without undue burden.

The same principle applies outside AI: do not hide the inventive step behind the word “automatically.”

Can the model itself be the invention?

Sometimes applicants want to protect a trained model as an object separate from the system that uses it. This can be difficult.

A model may be characterized as mathematical parameters, a data structure, a computer-readable implementation, a training method, an inference method, or part of a larger device. Those are not interchangeable claim strategies. Their treatment also differs by jurisdiction.

In practical terms, the case is usually stronger when you can explain at least one of these:

• a specific technical use of the model;
• a model architecture adapted to a technical constraint;
• a training process that produces a demonstrable technical effect;
• a particular deployment that improves the operation of hardware or another technical system; or
• a computer-level improvement such as memory use, processing distribution, security, latency, or resource consumption.

The EPO’s mathematical-method guidance gives an unusually concrete example: allocating data-intensive training steps to a GPU and preparatory steps to a CPU can contribute to technical character when the implementation exploits the computing platform’s architecture. “Faster AI” is vague. A defined way of using hardware to achieve the improvement is much more useful.

Do not forget inventorship when AI helped create it

There is a second AI issue that has nothing to do with whether the technology is eligible: who invented it?

Under the USPTO’s revised November 2025 guidance, only natural persons can be named as inventors. AI systems are treated as tools, and the ordinary legal standard is applied to the humans who conceived the claimed invention.

Using AI during research or development does not automatically prevent a patent. It does make documentation sensible. Keep a record of the technical problem the team identified, the decisions people made, which proposed outputs were accepted or rejected, and how the claimed solution took shape.

The patent should not turn into a diary of every prompt. The company should still be able to explain the human conception behind what it claims.

For the full international picture, including the different human-contribution tests applied in the US, Germany, Japan, and other patent systems, continue with Can an AI Be Named as an Inventor? Where Every Major Patent Jurisdiction Stands in 2026.

Search more than product names

Software founders often search the name of their product category, find nothing, and feel relieved. I would feel suspicious. The relevant prior art may describe the same mechanism in a completely different market.

A queue-management technique for cloud jobs may resemble scheduling used in telecommunications. A fraud-detection feature may share architecture with fault detection in industrial sensors. A recommendation model may look novel in retail but familiar in media ranking.

Search the technical mechanism at several levels:

1. The result. What does the system accomplish?
2. The method. What sequence or model produces that result?
3. The architecture. Which components exchange what data?
4. The constraint. What technical limitation is being overcome?
5. The effect. What becomes faster, safer, more accurate, less resource-intensive, or physically different?

Patenta lets you describe that mechanism in ordinary language and search patent documents by meaning across jurisdictions. Once you find the closest systems, you can compare their features with yours and carry the distinctions into a structured draft instead of restarting from a blank document.

Patent databases are not the whole prior-art universe. For software and AI, papers, standards, documentation, conference material, open-source repositories, and earlier public products may matter too. Use the patent search as a strong starting point, not a promise that nothing else exists.

Decide what belongs in the patent—and what does not

A patent is not the only way to protect a software product.

• Copyright protects the source code and other original expression, not the underlying function.
• Trade-secret protection may suit model weights, internal evaluation methods, data-cleaning processes, or server-side techniques that can stay confidential.
• A patent may protect a claimed technical method or system even when a competitor writes different code.

The business question is whether disclosure is worth the potential right. If a process is invisible on your servers and difficult to detect from the outside, keeping it secret may be the stronger move. If the invention will be visible in a product, standard, API behavior, or device, patent protection may be more valuable.

The answer can also be a combination: patent the externally meaningful technical architecture, keep tuning methods and operational data confidential, and rely on copyright for the code itself.

A practical drafting checklist

Before starting a software or AI patent draft, write down:

1. The technical problem. Avoid describing only the business objective.
2. The system context. Identify devices, services, sensors, processors, networks, or storage involved.
3. The processing path. Follow data from input to technical output.
4. The inventive distinction. State what happens here that the closest prior art does not teach.
5. The technical effect. Explain the operational improvement and how the claimed features produce it.
6. The implementation. Include enough detail to prevent the key step from becoming a black box.
7. The alternatives. Record different architectures, models, thresholds, and deployment arrangements.
8. The evidence. Preserve benchmarks, simulations, and design reasoning without inventing results you do not have.
9. The human contribution. Keep a practical inventorship record when AI tools participated in development.

That is enough to begin a meaningful search and first draft. The draft will tell you, without much diplomacy, where the explanation still relies on labels instead of engineering.

The bottom line

Software, algorithms, and AI models are not categorically outside the patent system. Nor are they patentable merely because they are new code.

The strongest candidate is a concrete technical solution: one you can explain as a system or method, distinguish from prior art, connect to a technical effect, and disclose with enough detail to be implemented.

Do not begin with “we use AI.” Begin with the problem, the mechanism, and the change the mechanism produces.

Think your software or AI system contains a patentable technical invention? Describe it in Patenta, search for the closest patent prior art, and turn the surviving technical difference into a structured first draft.