Six decisions of the EPO’s Boards of Appeal use a string of cautionary tales to map the absolute floor of what patent applications for AI inventions must disclose — and how spectacularly some applicants miss even that mark.
To many, artificial intelligence is a black box — which is precisely what makes it a tricky case under patent law. Anyone seeking a patent must disclose the invention clearly enough for a person skilled in the art to understand and reproduce it (Art. 83 EPC). But what if the invention’s beating heart is a neural network whose inner workings remain only partly intelligible even to the applicant? Six decisions of the EPO Boards of Appeal offer a clear answer — and show just how dark it can stay inside some applicants’ black box.
Three Levers, One Yardstick
Anyone developing an AI model makes choices on three fronts:
1. the model itself — its type, architecture and topology;
2. the training data and the training procedure; and
3. the accompanying parameters, such as hyperparameters or prediction modalities.
To an engineer, these three levers are simply part of the job. To a patent lawyer, each becomes a potential gap in disclosure.
Article 83 EPC does not require every one of these three levers to be specified down to the last detail. What matters is whether the skilled person, confronted with a gap, can bridge it using general knowledge in such a way that the technical effect sought by the patent is actually achieved. The well-nigh uncountable design choices available for model, training and accompanying parameters need only be narrowed where there is reason to fear that the skilled person, applying their own technical knowledge and the paradigms prevailing in the field, would not arrive directly at a working solution. Where the obvious path would be taken anyway, a hint suffices — or even silence.
Where that latitude runs out is what the following six decisions illustrate.
Six Decisions, One Message
In the first case, an application for determining cardiac output from the peripheral blood-pressure waveform (T161/18) described the training data required only as a “broad cross-section” of patients — without specifying which patient data descriptive of what group of patients, would actually contain the correlation to be decoded. In the second, an application for evaluating predicted vehicle trajectories (T606/21) claimed a deep neural network for assessing the similarity between two trajectories — yet in operation it received only a single trajectory as input, leaving open to what a resulting similarity score might exactly relate to. Reproducibility, unsurprisingly, presupposes that the skilled person knows what they are looking for, or in the present case against what they are comparing.
The starkest example came from an application for monitoring the wear of furnace linings (T1669/21). The claimed “computational model” was described as nothing more than a “neural network” — with no specifics on topology, node connectivity, activation functions or training method. As with cardiac output, the Board refused to let the skilled person off with a vague gesture toward some vast haystack of measurement data in which the sought-after correlation would presumably be hiding somewhere. The application, it held, needed to specify which data should contain the patterns underlying the classification, and how — if need be, with which model — those patterns were to be extracted. The Board’s laconic verdict: the application is an invitation to a research programme.
In the more software- and AI-adjacent cases, the same picture repeats from a different angle. An application for individualised therapy planning using already-known meta-learning (T1191/19) saw no need to mention training-data examples, a minimum number of patients, or sample values for the meta-parameters. The Board first observed — rightly, one might add — that merely applying machine learning to an existing application area lacked the inventive step required. As for the vague data specifications, it found that this application, too, amounted to more of an invitation to a research programme than a teaching of technical action. Another application, for performance monitoring of distributed IT systems (T1539/20), placed unshakeable faith in the skilled person’s omniscience by requiring them to map a complex, decentralised system onto a hierarchical model via an unspecified “mapping” — without a single rule for how. The Board’s comment was as apodictic as they come: automating the cognitive work of a process engineer would regularly exceed the capabilities of the average skilled person.
Finally, an application for knowledge distillation (T1425/21) by Google required a smaller model to replicate the outputs of a larger one — without indicating how the fidelity of that replication could be influenced, which architectures suited which source models, or what accuracy could realistically be expected. The parallel writes itself: once again, the Board found itself graciously invited to a research programme.
What Does This Mean for Drafting Practice?
Beyond the universal lesson that invitations to research programms tend be declined at the EPO, the six decisions resist being distilled into a definitive checklist. They do, however, point to which of the three levers introduced above is most often left under-specified, and roughly where the boundary of the acceptable lies.
With the model itself, what matters is not whether the application names every conceivable model class, but whether the skilled person can see which approach is meant to tackle the problem at hand. If the paradigm prevailing in the field would lead there anyway, nothing further needs specifying. But where it remains unclear what kind of model could even achieve the claimed result — as with the furnace-lining diagnostics of T1669/21 — the skilled person is left to guess. And guessing is not enough.
The same principle applies to training, with one further twist: the application must at least disclose how the right data — meaning data that actually contains the pattern the solution depends on — is to be selected or collected, at a minimum. A sibylline instruction to collect the right data as comprehensively as possible answers no such question. And that the data fed to the model in deployment should ideally match the input format the model expects ought, frankly, to go without saying.
The same goes for the accompanying parameters: a concrete parameter set need not necessarily be specified if the skilled person can work it out without difficulty. What matters is that the skilled person understands how to handle the model. Where the desired technical effect depends on particular control variables, the application must at least give a rough indication of which variables these are and how they need to be adjusted to push the effect, qualitatively and quantitatively, in the desired direction.
The common denominator in all this is a question anyone filing or attacking an AI invention should ask: what would the skilled person in this field do anyway — out of instinct, out of convention, or simply because it is the prevailing state of the art? And at which points does the invention depart from that so markedly that the skilled person, left without further guidance, would head off in the wrong direction or not know how to proceed at all? Precisely there — and only there — must the application take the lead. None of this, incidentally, is new: it held true for the mechanical inventions of the nineteenth century, and for every application in every field of technology since. AI has not introduced any new rules in this respect — merely new, and particularly spectacular, ways of breaking the old ones.
Applicants seeking patent protection for an AI-driven invention ought to ask these questions while drafting the application — rather than wait for the examining division to ask them instead. That, of course, presupposes legal counsel that genuinely understands the underlying technology: with AI inventions especially, much hinges on the details of model, training algorithms and parametrisation — details that translate cleanly into a patent application only with correspondingly deep technical expertise on the drafter’s side.
