AI & Software Patents
A may not be patentable. A* may be.
Software, AI, mathematical models, business logic and aesthetic concepts are not automatically outside patent protection in Europe.
The decisive question is not what the invention is called.
It is:
What does it technically do?
Under the EPO’s COMVIK approach, a claim may contain both technical and non-technical features. But for inventive step, the decisive features are those that contribute to a technical solution to a technical problem. A feature that looks non-technical in isolation may still count if, in the claimed context, it produces a technical effect serving a technical purpose. (EPO Guidelines G-VII, 5.4)
That creates an important drafting distinction:
A may describe an excluded or non-technical idea.
A* may use the same underlying idea as part of a technical system, tied to a technical input, implementation, constraint or output.
That difference can determine whether there is anything technically inventive for the EPO to assess.
Mathematics
A — A better equation
A mathematical method for processing abstract numbers, optimising an abstract objective function or performing a Fast Fourier Transform on abstract data is, by itself, mathematical subject-matter. A generic computer implementation may get the claim past the “as such” exclusion, but that does not mean the mathematics contributes to inventive step. (G-II, 3.3)
A* — The equation is functionally tied to a technical effect
A mathematical model predicting an optimum value from a dataset.
A model receiving vibration measurements from an industrial rotor and deriving a physical imbalance state used to control the rotor operating condition.
Now the mathematics is not merely producing an interesting number. It is causally linked to a specific technical purpose.
The EPO expressly recognises mathematical methods as potentially technical where, for example, they control a specific technical process or derive a physical state from measured physical properties. (G-II, 3.3)
Do not stop at: calculate X.
Ask: calculate X from what technical input, representing what physical state, and for what technical consequence?
Artificial intelligence
B — An AI model
“Neural network”, “support vector machine” and “reasoning engine” are not magic patent words.
AI and machine-learning models are, in themselves, abstract computational or mathematical constructs. Training them does not automatically make them technical. (G-II, 3.3.1)
B* — AI performing a technical function
A neural network classifying documents according to textual meaning.
A neural network processing sensor signals from a cardiac monitoring device to identify an abnormal physiological pattern.
The EPO itself contrasts linguistic classification with technical AI applications. Classification according to textual content is not per se a technical purpose, whereas AI used in a technical application can make a technical contribution. (G-II, 3.3.1)
AI classifies network records into categories.
AI classifies measured network states and its output is used to modify packet routing to mitigate a detected congestion condition.
The second claim does not rely merely on the cleverness of the classifier. The classification participates in a technical process.
Training an AI model
C — Better training data
A sophisticated training methodology is not necessarily technical merely because it improves prediction quality.
C* — Training is part of achieving the technical purpose
Where the classifier itself serves a technical purpose, the generation of the training set and the training steps may also contribute to technical character when they help achieve that technical purpose. The EPO also expects the characteristics of training data necessary to reproduce the asserted technical effect to be disclosed when those characteristics matter. (G-II, 3.3.1)
Select training examples to make an AI classifier more accurate.
Generate labelled training samples from sensor waveforms having defined sampling and noise characteristics so that a classifier used in a technical monitoring system can distinguish a specified physical condition.
The second formulation begins to explain why this training architecture matters technically.
AI implementation
D — A faster algorithm
“Faster” alone can be deceptive.
If a mathematical method serves no technical purpose and merely runs on an ordinary computer, algorithmic efficiency alone does not necessarily establish a technical contribution. (G-II, 3.3)
D* — An algorithm adapted to the machine
An AI training algorithm requiring fewer arithmetic operations.
A training architecture assigning data-intensive parallel operations to a GPU and preparatory operations to a CPU so as to exploit the respective processor architectures.
The EPO expressly gives CPU/GPU allocation adapted to the computing platform as an example of a specific technical implementation that can contribute to technical character. (G-II, 3.3)
You do not always need a technical application outside the computer.
A software invention can also be technical because it improves the functioning of the computer itself.
Software
E — Software that performs a useful task
A computer program “as such” is excluded. Merely running it on conventional hardware is not enough: the ordinary electrical activity of the computer is not the relevant technical contribution. The EPO looks for a further technical effect. (G-II, 3.6)
E* — Software changing a technical process or the computer itself
Examples recognised by the EPO include software for controlling an ABS system; processing X-ray measurements; video compression; restoring distorted digital images; encrypting communications; processor load balancing; memory allocation; protecting boot integrity. (G-II, 3.6.1)
Software that organises information more efficiently.
Software that changes memory allocation in response to runtime conditions so that a defined resource-management effect is achieved.
A more convenient way to build software objects.
A build process that regenerates only runtime objects affected by modified development objects, thereby limiting computing resources required for the build.
The latter is close to an express EPO example. (G-II, 3.6.1)
Business methods
F — A better business rule
Business logic can be commercially brilliant and still be irrelevant to inventive step.
Pricing, billing, advertising, licensing, contractual arrangements, workflows, forecasting and managerial optimisation are classic examples of business-related subject-matter. Putting them on a server does not automatically convert the underlying business idea into a technical contribution. (G-II, 3.5.3)
F* — A technical implementation solving a technical problem
Select which offer should be displayed to a customer according to commercial criteria.
Distribute selected media files from a central server to local stores in advance, maintain local caches and retrieve requested content locally so as to reduce repeated network transfer and remote-server demand.
Remove a customer-information requirement from a payment process to make transactions faster.
That remains essentially an administrative decision even if it incidentally reduces transmitted data.
Modify the communications protocol, message structure or caching mechanism itself to reduce bandwidth or processing load.
The EPO draws precisely this distinction:
Changing a business rule to avoid a technical constraint is not the same as technically solving the constraint. (G-II, 3.5.3)
Fintech
G — A new financial model
Calculate a more accurate credit score.
Probably still difficult merely because the computation is performed by AI. The quality of the financial decision remains a non-technical benefit.
A distributed transaction system changing cryptographic verification, message sequencing or resource allocation to maintain transaction integrity under a defined network condition.
Patent the technical machinery around the financial process, not merely the financial logic.
Simulation
H — A realistic simulation
A simulation of a technical object is not automatically technical merely because the object being simulated is technical.
A highly accurate virtual turbine model can still produce nothing more than numerical data representing a model. Under G 1/19 and the current Guidelines, that alone is not decisive. (G-II, 3.3.2)
H* — The simulation output is tied to a technical use
Simulate the aerodynamic behaviour of a turbine blade.
Simulate candidate blade geometries and output manufacturing parameters for controlling production of a selected blade geometry.
Or: generate simulation output functionally limited to configuring a technical control system.
The intended technical use of calculated numerical data can matter where that use is explicitly or implicitly reflected in the claim. (G-II, 3.3.2)
Digital twins
I — A digital model of a machine
Calling something a “digital twin” does not itself solve COMVIK.
Maintain a virtual model reflecting the theoretical state of a machine.
Receive real sensor measurements from a specific machine, update a state model and generate a control or maintenance signal based on the derived physical condition.
Now the architecture moves from model of reality toward technical processing of reality.
Aesthetics
J — A more beautiful image
Aesthetic effect is not itself a technical effect.
A colour combination, artistic style, typography or visually pleasing layout does not become technically inventive because software generates it. (G-II, 3.4)
J* — Technical means producing or exploiting the visual result
AI generates an image in a particular artistic style.
An image-processing pipeline detects and compensates display distortion caused by a defined optical characteristic of a head-mounted display.
Generate an attractive texture for a product.
Generate a tread geometry whose pattern controls water displacement from a tyre-contact region.
The EPO expressly uses the tread example to illustrate how a visual pattern can become technically relevant because of the physical effect it produces. (G-II, 3.4)
Generative AI
K — Generate better content
Use an LLM to generate more persuasive advertising copy.
Use an LLM to summarise legal documents more accurately.
Commercially useful. Technically weak.
A model receives structured diagnostic logs from distributed computing nodes, identifies a machine state satisfying defined technical conditions and generates a machine-executable remediation sequence subject to system-state constraints.
The distinction is not: AI versus non-AI.
It is: technical contribution versus non-technical contribution.
User interfaces
L — A nicer interface
Move a button to a more attractive position. Use a more elegant menu hierarchy.
Aesthetic preferences and information presentation normally do not support inventive step.
L* — Interaction solving a technical HCI problem
What the screen looks like.
Provide an input mechanism constrained by the operating state of a technical device so that the user can reliably enter a command under defined machine conditions.
The EPO distinguishes mere graphic design and subjective preferences from mechanisms enabling user input, which are more likely to make a technical contribution. (G-II, 3.7.1)
How the human input is technically acquired, interpreted and used by the machine.
Data
M — Better organised information
A more elegant information model, ontology or logical data structure is not automatically technical.
M* — Data structure serving the operation of a technical system
The stronger case is where the claimed structure affects storage, retrieval, transmission, processing or another technical operation of the computer.
Meaning of the data is not the same thing as technical handling of the data.
Cybersecurity
N — A security policy
Require a user to obtain approval from two managers.
That is largely organisational.
Verify boot integrity using cryptographically protected machine-state measurements before permitting execution of a software component.
Or: introduce countermeasures against power-analysis leakage in a cryptographic implementation.
The EPO expressly recognises such software security mechanisms as capable of producing further technical effects because they rely on the internal functioning of the computer. (G-II, 3.6.1)
Logistics
O — A better delivery schedule
Optimising delivery routes for cost, staff utilisation or customer convenience remains primarily business optimisation.
Adding GPS coordinates does not automatically change that.
O* — Technical control of a physical logistics system
A different case may arise where the optimisation controls physical equipment subject to technical constraints—for example, routing autonomous vehicles while accounting for battery state, communication coverage and collision constraints and issuing corresponding machine-control commands.
The claim should make that causal technical chain visible.
What COMVIK changes
One of the most misunderstood points in European software patent practice is this:
A claim can be technical enough to avoid exclusion — and still fail because its clever part is non-technical.
Adding “implemented by a computer” may make the claimed method technical as a whole.
But at inventive-step stage, COMVIK asks another question:
Which differences over the prior art actually contribute to technical character?
If the only new idea is a pricing rule, a linguistic classification, an artistic preference, a mathematical optimisation of an abstract problem, or a managerial decision, that feature may be included in the formulation of the problem given to the skilled technical person rather than treated as part of the inventive technical solution. (G-VII, 5.4)
This is why good European drafting cannot simply add hardware nouns to a non-technical concept.
The A → A* test
When we assess an AI or software invention, we repeatedly ask:
A — What is the abstract idea?
And then: A* — What changes technically because of it?
| A | A* |
|---|---|
| mathematical prediction | physical state derived from sensor measurements |
| AI classifier | classifier controlling a technical process |
| faster algorithm | algorithm adapted to processor architecture |
| business workflow | network architecture solving latency/load problem |
| financial rule | cryptographic or transaction-system mechanism |
| simulation | simulation output functionally tied to technical use |
| digital twin | measured physical state → technical action |
| attractive graphic | image processing compensating display distortion |
| elegant GUI | technical input mechanism |
| organised data | data structure changing computer operation |
| AI-generated text | model producing machine-executable technical remediation |
| security policy | technical integrity-verification mechanism |
That is not a formula guaranteeing patentability. Novelty, inventive step, sufficiency, clarity and added matter still matter.
But it is often the most useful first diagnostic question.
We draft from the technical effect backwards
For AI and software cases, we often begin before writing claim 1.
Then we ask whether the description actually explains that chain.
Because a technically ambitious claim cannot be rescued later if the application merely says: “AI may be used.”
The EPO requires the claimed technical effect to be credible and, where necessary, supported by explanation, mathematics, experimental evidence or other disclosure. Mere assertion is not enough. (G-II, 3.3.1)
AI is not the technical effect
“Using AI” is usually not the invention.
The invention may instead lie in:
- what technical data the model receives;
- how that data represents a physical or machine state;
- how the model is technically implemented;
- what hardware constraint shaped the model;
- what technical output is generated;
- what device, network or process changes because of that output;
- or what computer resource is used differently as a result.
That is where we look for the European patent case.
A software idea should not be made “technical” after drafting.
It should be understood technically before drafting begins.
At Stan Advoka, we use the COMVIK framework at the beginning of the work—not only after an examiner cites it.
For AI and software inventions, that means identifying the potentially non-technical core, locating the genuine technical contribution, and building the specification around the causal relationship between the two.
Because A may not be patentable.
But A* may be.