Event recap: Technical Character at the EPO—Latest Guidelines & Case Law for Patenting AI & Software

Speakers: Emmanouil Rovilos (Directorate Procedural Guidance & Registers, EPO) and Magdalena Kolasa (Directorate Patent Law & Processes, EPO)
By Aidan Persinger, Student Reporter

This EPO session landed on a simple truth with real drafting consequences: you don’t win European protection for software and AI by proving the math is elegant, you win by proving that the part you’re proudest of produces a technical effect that solves a technical problem. That through-line, familiar to veterans of the COMVIK approach, wasn’t presented as abstract doctrine but as a practical, repeatable recipe for getting AI and software claims across the line at the EPO.

Rovilos and Kolasa began with the policy gate: Europe protects “inventions in all fields of technology,” but excludes abstract matter, like mathematical methods, business methods, computer programs, and presentations of information. Crossing that threshold is straightforward: involve technical means (e.g., make the implementation by, on, or with a computer explicit). But that’s only the on-ramp. The real analysis is an inventive step under COMVIK: only those distinguishing features that contribute to technical character can support inventiveness. In plain English, the “clever bit” must actually do something technical to a non-excluded system or process: cause a technical effect, serve a technical purpose, or solve a technical problem.

For AI in particular, the presenters framed two reliable doors into patentable space: (1) technical application, your model is used in a field of technology, such as signal processing or medical devices; or (2) specific technical implementation, you exploit computer architecture (e.g., CPU/GPU division of labor, memory layout, cache behavior) so the improvement flows from how the computer is used, not merely from a nicer algorithm. Either path works, but each demands that the claim text make the causal chain explicit and the specification support the effect across the whole scope.

Where the line is: three worked examples worth emulating (or avoiding)

1. T 1286/09 — training with exemplar images (allowed).
   An image-classification method that generates exemplar images and uses them to train a classifier was allowed because the algorithmic steps, in context, improved a digital image classifier—a technical process. The math isn’t protected as such; the improved operation of the technical system is. If you lead with classifier performance (accuracy, robustness), not with the elegance of the data augmentation, you’re arguing in the key the EPO expects.

2. T 0702/20 — pruning “loosely coupled” ANN nodes (refused).
   Here the Board viewed the benefits as stemming from a simpler algorithm, not from any adaptation of the computer’s internal functioning. Nothing about the computer changed; therefore the pruning features did not contribute to technical character. If your “efficiency” is just fewer operations on paper, you’re on thin ice; if it arises from architecture-aware choices (threading, vectorization, memory traffic), you can show technical effect.

3. EP 1 569 128 — splitting ML steps across CPU/GPU (allowed).
   This claim assigned preparatory steps to the CPU and data-intensive steps to the GPU. It wasn’t “sprinkling hardware nouns” into a math claim; it was a specific implementation that exploits hardware characteristics to improve training. The benefit flows from the implementation choice itself, so it contributes and anchors the inventive step. Map each claimed step to a hardware trait (parallel units, memory bandwidth, DMA) and you mirror the reasoning the Office accepted.

It’s important to draft the causal story on day one. The presenters’ “practical tips” amounted to an instruction to author the causal narrative—problem → technical approach → specific implementation → measurable technical effect, in the application as filed. Put technical means in the independent claim so you clear the “as such” exclusions; then place the inventive weight on features that affect a non-excluded process (accuracy of a classifier, signal-to-noise ratio, deterministic latency bounds, cache-miss reductions). And do not count on later lawyering to rescue “faster software” as a “better computer”—if performance gains don’t arise from how the computer or sensor system is used, they won’t be treated as technical.

This session slots neatly into the EPO’s broader drafting philosophy highlighted in CLA’s companion talk, “Be Clear, Be Technical, and Directly, Unambiguously Derivable.” There, Gerry Van Dooren distilled the Art. 84 clarity triad (clarity, conciseness, description support) and the Art. 123(2) added-matter rule into operational advice: engineer modular, amendment-ready disclosure at filing so every later narrowing route is “directly and unambiguously derivable.” If you define the technical field, constraints, and advantages up front; police claim/description consistency; and front-load fallbacks (alternative ranges, explicit feature combinations, negative boundaries), you reduce risk and make COMVIK analyses straightforward because the technical effect and its evidence are already in the record.

Van Dooren also cautioned against “direct conversion” of U.S. filings: avoid sprawling independent-claim stacks, purge claim-like language from the description, and don’t try to build new embodiments by stitching together features from different sections after filing, classic Art. 123(2) traps. The practical upshot is to adopt an EP-first drafting posture: embed clarity and derivability in the base text, then layer any U.S.-specific material on top. That posture pairs perfectly with this webinar’s insistence that the inventive weight must rest on features that truly do something technical.

One timely coda: parties remain responsible for their submissions even if they use AI to help draft or analyze. The EPO itself is piloting AI in examiner toolkits (including minute drafting), but decisions remain human. Treat AI as an aid for articulating the causal story, not a substitute for it, and certainly not a source of post-hoc “evidence” that never made it into the spec.

So what do you change? Open with the field and constraints (latency, bandwidth, compute budget) and state the technical problem plainly. Then write the spec so that the measured effect matches that problem.

Claim a specific implementation that changes how the computer/sensor system operates (e.g., CPU orchestration + GPU kernels; pinned memory and tiling that reduce cache misses). In the description, tie each step to a hardware trait and show why that trait matters.

Evidence the effect across the whole claim scope. If some embodiments don’t deliver it, narrow before examination forces you to, and make sure the fallback you need is already derivable from the filing text.

Keep the Guidelines open (CII Index; AI section G-II, 3.3.1) and draft to them, not around them. It’s faster than arguing your way back to the same place.

The EPO’s current software/AI practice rewards causation you can prove. If your independent claim and your specification tell a tight story, from technical problem to specific computer-aware implementation to measurable technical effect, you’re arguing in the language of COMVIK and giving examiners what they need to allow. Marry that with clarity and derivability discipline at filing, and you turn novelty, inventive step, and post-G 1/24 description adaptation from existential risks into a predictable, manageable process.