Copyright protects how software is written. Trade secrets protect what stays hidden. Neither protects what usually matters most, what the software actually does. That is the gap patents are built to fill, and the European rules for filling it are more workable than their reputation suggests.
When a founder tells their patent attorney, “We need to protect our AI,” the useful reply is not reassurance. It is a question: which part?
Treating a software system as a single object to be defended is one of the most expensive mistakes in technology strategy. An AI product is not one thing; it is a stack of components, and each component answers to a different area of law.
A typical system contains training data, a model architecture, the weights and hyperparameters tuned over months of experimentation, source code, interfaces, outputs, documentation, a brand, and engineering know-how held only by the team. Source code is a matter for copyright. Weights and tuning recipes are usually best kept as trade secrets. A genuinely new technical method may be patentable. The brand belongs to trademark. The generated outputs raise their own, still-unsettled questions about authorship.
The task, then, is never to choose a single right for “the AI.” It is to map the system and match an instrument to each layer. That matters most at the point where the two cheapest and most automatic protections, copyright and trade secrets, both fall away: the part of the software that usually carries the most commercial value.
Where copyright and trade secrets fall short
Copyright is the natural first reflex. It is free, automatic, long-lived, and good at its job: stopping others from copying your code, manuals, and screens. But copyright protects expression, not function. It guards the particular words a programmer chose, not the idea behind them, not the algorithm, not the method, not the behaviour of the running system.
European law is explicit on this. The Software Directive (2009/24/EC) protects the expression of a computer program while leaving the ideas and principles underlying any element of it, interfaces included, outside copyright. The Court of Justice confirmed the corollary in SAS Institute v World Programming: a program’s functionality, its programming language, and the format of its data files are not protected as expression. A competitor may study how your software behaves and rebuild that behavior from scratch, in entirely different code, without infringing copyright. The Directive even supplies the tools, permitting lawful users to observe, study, and test a program to extract its underlying ideas, and in defined circumstances to decompile it for interoperability.
These are deliberate, pro-competition rules. They also show that copyright was never meant to be a monopoly over what software does.
Trade secrets cover a different area and leave a different hole. They can protect precisely what copyright cannot, the server-side model, the training pipeline, the tuning parameters, the internal architecture, but only for as long as those things stay secret. A trade secret exists only while it is secret, only while it derives value from being secret, and only where its owner has taken reasonable steps to keep it so.
The protection fails against anyone who reaches the same result independently. The EU Trade Secrets Directive (2016/943) expressly permits both independent creation and the reverse engineering of a product lawfully in one’s possession, subject to any valid contractual restrictions. It also protects employee mobility: people may use the experience and skill they honestly acquired on the job. For software, shipped to customers, exposed through APIs, benchmarked, decompiled, and built by engineers who move between employers, these are real limits, not theoretical ones. Once a product reaches the market, much of what made it distinctive can be inferred, and the secret begins to erode.
This is the gap. Software’s value tends to lie in its technical behaviour, yet behaviour is exactly what copyright declines to protect and what secrecy cannot hold once the product is in use.
What a patent protects, and at what price
A patent is the one mainstream instrument that protects a technical solution itself, rather than its written form or its concealment. It does not matter whether the infringer ever saw your code: if a competitor arrives at the same patented method independently, that is no defense. This is what makes patents valuable wherever a software advantage is visible from the outside, in network traffic, in benchmarks, in a security handshake, in an interoperable interface, which is to say, in most of the places where trade secrecy is weakest.
The price is disclosure. To obtain a patent, you must describe the invention clearly enough for a skilled person to reproduce it, and that description is published. This is the core trade-off: a time-limited right to exclude, in exchange for permanent publication.
That is why not every innovation should be patented. If your advantage depends on something an outsider could never reverse-engineer, a proprietary data-curation process, a set of confidential tuning heuristics, publishing it in a patent may simply hand it to competitors. The strategic question is therefore not “can we patent this?” but “do we want to disclose this in exchange for exclusivity, or is it worth more kept secret?”
This is why mature software portfolios are layered rather than singular. Copyright forms the floor, useful against literal copying. Trade secrets protect the volatile, hidden details, datasets, parameters, internal tooling. Patents claim the stable technical abstractions: the processing flows, protocols, device interactions, and performance mechanisms a competitor could otherwise lawfully reinvent. The skill lies in the division: patent the structure, keep the settings secret.
Can AI be patented in Europe?
There is a persistent belief that software, and AI in particular, cannot be patented in Europe, that because an AI model is “just mathematics,” it falls outside the system. This is too simple.
The European Patent Convention does exclude mathematical methods, business methods, game rules, presentations of information, and “programs for computers” from patentability. But it excludes them only “as such,” and that qualification carries the weight. The European Patent Office does not ask whether an invention uses software, an algorithm, or a neural network, nearly everything does. It asks whether the claimed subject matter has technical character, and whether the features relied on for inventiveness contribute to solving a technical problem by technical means.
The structure around that question is clear once you see it. The first hurdle is low: a claim involving a computer, a processor, or a network has technical character and is not excluded outright. But clearing that threshold is not the same as being patentable. When inventiveness is assessed, the examiner sets aside every feature that does not contribute to technical character and weighs only what remains. This is the logic of the EPO’s COMVIK decision, and its consequences are significant. A business rule, a pricing formula, a marketing goal, or a game mechanic may all appear in the claim, but they are treated as constraints, part of the problem handed to the engineer, never as the source of the invention. The inventiveness must lie in the non-obvious technical way the system meets those constraints. For software specifically, the program must produce a “further technical effect,” something beyond the ordinary operation of code on a processor.
Two contrasting examples show where the line falls, and they generalize. A neural network trained to detect irregular heartbeats from a signal is patentable in principle: it serves a concrete technical purpose. A neural network that sorts legal documents into billing categories by their text is not: its purpose is linguistic and administrative, however sophisticated the underlying mathematics. The model is the same in kind. What differs is the problem it is aimed at.
The harder cases: when the invention looks commercial
The same principle governs inventions that look commercial. The EPO does not prohibit patents in advertising, finance, or gaming; it prohibits relying on the advertising, finance, or gaming for inventiveness.
In a video game, predicting the trajectory of a billiard ball, however accurately, solves no technical problem beyond implementation. But adjusting the simulation’s step size in real time according to measured network latency is technical, because it addresses a genuine networking and processing problem rather than the rules of play.
The same rule reaches AI’s most prominent techniques. A training process can become patentable when its design solves an engineering problem. For instance, assigning data-intensive training stages to a GPU and preparatory steps to a CPU, with specified memory transfers between them, to make execution more efficient is technical in a way that “training a model to predict better” is not. The EPO has also grown stricter about vague claims. In recent decisions it has rejected claims whose promised benefit, less memory, more speed, was not credible across the full scope of what was claimed, and has held that reinforcement learning is not, in itself, a technical field. The drafting lesson is unforgiving: name the mechanism, not the aspiration.
The same test, expressed differently abroad
None of this transfers cleanly across borders, which is the practical complication behind any global filing strategy. The major jurisdictions differ less in outcome than in the route they take.
The United States runs claims through the Alice framework, asking whether a claim is directed to an abstract idea and, if so, whether it has been integrated into a practical application or amounts to more than generic computer implementation. China requires a “technical solution” and now openly credits algorithmic features where they combine closely with technical ones, improving processing speed, cutting storage, reducing transmission. Japan looks for a creation of technical ideas using the laws of nature, realized concretely through hardware resources.
Britain, until recently the outlier, has moved significantly closer. In Emotional Perception AI Ltd v Comptroller-General UKSC 3, decided in February 2026, the UK Supreme Court set aside the Aerotel test that had governed software and AI eligibility for nearly two decades, finding that it had misread the European Patent Convention. The judgment points UK examiners toward the EPO’s approach: the “any hardware” threshold for what counts as an invention, and the assessment of inventive step on technical features alone, broadly in line with the Enlarged Board of Appeal’s decision G 1/19. The UKIPO has since withdrawn its dedicated AI examination guidelines. How closely the two systems will track each other in practice remains to be seen, the practical detail is still unsettled, the application has been sent back to the office, and little domestic case law has yet been built on the new test, but the direction of travel is clear: toward the European approach, not away from it.
The convergence is real. The reliable approach everywhere is the same, namely draft around a concrete technical problem, the specific mechanism that solves it, and the measurable result, then adjust the framing to each office’s preferred vocabulary. The recurring mistake is also the same: claiming a business idea, a recommendation, or a game rule, then restating it in generic computing language and hoping it passes. It does not. Examiners and courts look at substance, not form. Renaming a “rule” a “module,” or wrapping non-technical logic in talk of servers and clients, persuades no one.
Good drafting is good engineering
There is a final point, and it turns the exercise from defensive to constructive. The European framework’s central demand, describe the technical problem, identify the technical means, and connect them to a credible technical effect, is not merely a procedural hurdle. It is, almost exactly, the discipline of good engineering: this non-technical requirement creates this technical problem; here is the mechanism that solves it; here is the effect it produces.
A team that can describe its invention in those terms usually understands it better than one that cannot. The framework rewards clarity about what the software actually does, which returns us to the opening question. The founder who says “we need to protect our AI” is asking the wrong question; the patent attorney’s “which part?” is the start of the right one.
Start by mapping the system
In practice, the work begins well before any application is filed. The most useful early step is to map the system layer by layer and decide, for each, where its value lies and how that value is best held. What is genuinely new, technical, and visible once a competitor examines the product is the candidate for a patent. What can be kept hidden and is hard to reverse-engineer is the candidate for trade-secret protection. Code, documentation, and interfaces are covered by copyright. The brand is a matter for trademark.
Doing this early, rather than after a launch or an investment round, is what makes the difference, because decisions about disclosure are difficult to reverse. A method kept secret can still be patented later, but a method already disclosed, in a paper, a demonstration, or a patent of its own, generally cannot afterwards be protected as a secret.
So the components that can be hidden should be hidden, deliberately. The part that is genuinely new, genuinely technical, and visible the moment a competitor takes the product apart is the part patents exist to protect. Identifying that part early, before the options narrow, is where sound IP strategy begins.
Mohammad Ahmadi Bidakhvidi recently explored this subject in depth during a presentation in Leuven, where he explained the layered approach to protecting AI systems and discussed the practical aspects of patenting software-related inventions in Europe. The accompanying presentation slides can be downloaded here.
