How to Help an EPO Examiner and Improve Your Odds of Patenting a Computer-Implemented Invention

“What matters is defining the essential features that contribute to the technical effect of the invention at a sufficient level of detail, even if these features, considered individually, are of algorithmic nature.” – Jean-Marc Deltorn

EPO Headquarters in Munich.

I recently had the opportunity to speak on the record with three examiners at the European Patent Office (EPO) about their advice, pet peeves, and approaches to examining computer implemented inventions, particularly in the field of artificial intelligence (AI), and how the EPO compares with the U.S. patent examination system. It was a wide-ranging and thoroughly enjoyable conversation with three professionals who obviously know this area very well, and who were willing to provide keen insight into ways applicants can and should improve technical disclosures to maximize the likelihood of obtaining a patent.

These EPO examiners, in the order in which they first speak in the interview that follows, are:

Jean-Marc Deltorn (JMD) holds a PhD in Theoretical physics, a Master of Laws and is currently finishing a PhD in Law on the interplay between AI and privacy. Deltorn has been a patent examiner at the EPO in the Information and Communication Technologies (ICT) sector since 2003, working in a variety of fields, from image analysis to pattern recognition and machine learning and focusing currently on speech recognition. He is also is a member of the EPO Guidelines Working Group on computer-implemented inventions (CIIs), and has co-authored the course material on “patentability of artificial intelligence”.

Abderrahim Moumen (AM) holds a master degree and a Ph.D. degree in the field of Telecommunications and Radars. He joined the EPO in 2000 as an examiner in the ICT sector. In 2017, he was appointed team manager leading a team of examiners dealing with patent applications in the field of antennas and microwaves. He specializes in the area of antennas (including smart antennas and antenna optimization), telecommunications, and the Internet of Things (IoT).

Anton Versluis (AV) studied Applied Physics with a specialization in Artificial Intelligence. He worked on Smart Robotics for the handicapped at the Netherlands Research Institution TNO and joined the EPO in 2006 as examiner in Pattern Recognition (G06K9), a technical area with a large role for AI, for instance in Self Driving Vehicles.

Without further ado, here is my interview with Examiners Deltorn, Versluis and Moumen.

GQ:    It’s not every day that we get to go officially on the record with examiners, but I know that applicants always wonder what it is that we can do that will help streamline the process, make better applications and really make your life easier, because I know if we make your life easier and give you what you want, it’s going to lead to better and hopefully quicker answers for us. What one piece of advice would you give applicants that is most important when dealing with the EPO?

JMD:  The first thing I would like to state here is that inventions related to AI are patentable at the EPO. I would recommend reading our Guidelines. The latest version published in November 2018 provides a detailed overview of the EPO’s practice, with updated sections on Mathematical Methods and a new section on Artificial Intelligence and Machine Learning. On a more practical basis, with regard to the drafting of an application, a contextual presentation of the underlying concepts of the claimed invention is always very helpful; for example, through a description of the prior art. The definition of the essential features, too, is of great importance. Identifying essential features early on in the independent claims forms the examiner’s understanding of the invention.


Disclose, Disclose, Disclose

AM: There are two points I would like to give as advice. The first is to indicate in the description the technical problem that is being solved by the invention, and how it is being solved with the help of AI or machine learning, and then to indicate how this solution is different from the prior art. This is very useful for examiners in the treatment of AI patent applications: it points us very early in the right direction in terms of what the claimed improvements really consist of, and enables us to assess if there is any surprising technical effect contained that could not be anticipated in advance on the basis of the knowledge available prior to the time of filing. It’s also good to have a fallback position in the description by mentioning some concrete cases, for example. This increases the applicant’s chances— especially of being able to file allowable amendments in respect of the known prior art when the application enters substantive examination.

AV:     I would like to build on those comments and say that it is really important for us that the invention is disclosed in a clear and sufficient manner for an expert to carry it out. That goes for the main invention as well as for the fallback positions. You have to bear in mind that it is not possible to amend the descriptions later in a way that would add subject matter. I’m sure in the U.S. it’s the same. It’s a point that we are often confronted with at the EPO.

It is also correct to include formulas or pseudocode [a formal but non-programming language description of what a computer program or algorithm does] to explain your invention. We’ve seen patent applications fail on the fact that a plus and a minus sign were reversed, and that is a pity. It is therefore important to ensure that both the disclosure and also the description of the technical advantages of the fallback positions are absolutely clear.

GQ:    This is all really great stuff. Let’s pick up on the last point, because when you talk about pseudocode, would you all agree that that is a good idea to include that in an application?

JMD:  Absolutely. Pseudocode is particularly helpful in describing AI and machine learning algorithms. The patent examiners working in fields related to AI are trained in reading pseudocode, and this makes our understanding of the algorithmic features much easier than attempting to express the same notions in natural language.

GQ:     Abderrahim, do you agree?

AM:    The more details that are disclosed in the description, the better for the patent examiner, of course. I can understand there is a trade-off for applicants between what is being kept secret and what is being disclosed. They have to find the right balance there. This is where the challenge lies because, as my colleagues already mentioned, adding subject matter later on is legally not possible. If, at an early stage, claims do not seem to be novel or inventive, the examiner has to establish if anything is left in the description that can be used. If there is not much else there, that could be the end.

Make Connections

AV:     Another aspect to remember is that in this field we are dealing mostly with abstract concepts. It’s easy to forget to say how certain parts of an invention are linked. If I say that an artificial neural network is trained, and I forget to indicate where it is getting its data and the labels for the data from, then the invention isn’t properly described. That goes for other connections between parts as well: they are important details to include.

GQ:    Yeah, I couldn’t agree more. The one nice thing about having code, pseudocode for sure, but code specifically, is lightening time. When you are dealing with software in particular, I find that people are moving incredibly fast when they are filing and sometimes they don’t really have the invention built, or sometimes they do have it built and they need to get something filed quickly for whatever variety of reasons. I am a fan of saying, if you have something built, make sure that you supply enough to enable at least what you have that is built. And filing some of the critical code can be a great way to make sure that you have that support in the application for everything that you will need. Would you agree with that?

JMD:  It all depends on where the invention lies. What matters is defining the essential features that contribute to the technical effect of the invention at a sufficient level of detail, even if these features, considered individually, are of algorithmic nature. These algorithmic features should then be disclosed in sufficient detail, for example, through a piece pseudo-code, for a skilled person to put them into practice.

GQ:    Right, and that gets us back to the fact that, a lot of times, people don’t want to do that because they want to keep it secret and that just defeats the whole purpose of getting the patent to some extent in the first place. So, it is something they have to think about ahead of time, I think, and not just dip their toe in the water. But the other thing that I see, and I’d like to get all of your thoughts on this, is that when I look at software patents, whatever the field may be, whether it is autonomous driving or whether it is machine learning or AI, that there are just too few flowcharts and too few schematic drawings. I just don’t think there are enough illustrations in these applications. Would you agree with that sentiment or would you disagree, and why?

JMD:  I think that graphical or written representations of a process can be equally legible for the skilled person. Flowcharts can be very helpful in understanding the logic of the process itself. Both ways of writing and expressing the essential features of the invention are very helpful.

Distinguishing CII and Software Inventions

AV:     I’d like to comment on the wording of your question. At the EPO, we prefer the term “computer implemented inventions” over “software patents” because our law clearly states that software as such cannot be patented. This is only possible in a clear combination with computers or sensors.

GQ:    That’s really insightful, and I wish we did that in the U.S. more because the problem with the world of software seems to be that the app on your phone that helps you track your weight that you are trying to lose is a piece of software, and there’s nothing really remarkable or innovative about that. And Watson, which IBM is programming, that can beat a human on Jeopardy, well that’s software too, and those are wholly different orders of magnitude.  And so, it’s interesting that you guys really make the distinction—you just simply don’t refer to it as software at the EPO then?

AV:     That’s absolutely correct. Our guidelines relate to CII, or computer implemented inventions.

AM:    In our practice, we don’t focus on the software itself, but on what happens when it runs on a machine, device or network, and on the technical problem that this solves, which is the challenge. When we look at AI and machine learning, the algorithms sometimes are not run on the claimed device itself:  In self-driving vehicles, for example, algorithms could run in the cloud or in a far remote system and communicate with the vehicles via 5G networks. This means that an applicant drafting claims needs to make sure that the invention actually is embedded in the claims. This has both an impact on the category of the claims as well as on their scope.

JMD:  The reference to a “computer-implemented invention” helps clarify that we refer to a technical entity, i.e., one that necessarily includes some technical component. With this specific wording it is easier to understand that we refer to a technical object in the sense of the EPC.

GQ:    That makes a lot of sense. For example, the guy who received the first U.S. “software patent,” Marty Getz, has written for us on IPWatchdog a number of times and he constantly says, “I stopped using the word ‘software’ because that’s really where the problem arises.” And I must confess that, I know that’s true, but I’m not sure I ever really got it until I just was hearing you guys make that distinction. A light bulb went on in my head and I’m almost embarrassed to admit that, but I get now what Marty has been trying to get me to understand for years.

I interrupted you when you were trying to talk about the drawings and the charts and the schematics. Did you have any other thoughts on that, Anton?

Don’t Mix and Match

AV:     We already find a lot of schematics in patent applications from the United States. The only advice I would give is that if you plan to have fallback positions—with more steps or side steps or alternative steps—that you make that really clear, because our practice does not allow mixing and matching of embodiments. We frequently encounter applicants trying to mix features from different embodiments, and unfortunately, we cannot allow that. As for the question of software patents and computer-implemented inventions: In 1973, when our legal framework, the European Patent Convention (EPC), was drafted, computer programs were not that sophisticated. Which is why we have seen case law evolve since then to adapt to ever more sophisticated types of computer programming, until, in 1997, the first patent was granted for what we could now describe as a computer-implemented invention. But in 1973, computer programs basically meant adding numbers together and data retrieval, which was seen as an administrative matter, and not necessarily innovative.

AV:     In the fields where I work—Pattern Recognition (G06K9 in the CPC)—we actually have a lot of classes for applications and a lot of classes for technology use, as the technology always goes hand-in-hand with an application. The other field that we have at the EPO, Machine Learning, is of a more abstract nature, which is more difficult to patent without an actual implementation

CONTINUE READING Part II, which dives deeper into the EPO’s approach to AI applications.


Warning & Disclaimer: The pages, articles and comments on do not constitute legal advice, nor do they create any attorney-client relationship. The articles published express the personal opinion and views of the author as of the time of publication and should not be attributed to the author’s employer, clients or the sponsors of

Join the Discussion

3 comments so far.

  • [Avatar for Ternary]
    July 22, 2019 02:42 pm

    I like the term “computer implemented invention.” Mainly because it captures the physical aspect of a machine.

    “But in 1973, computer programs basically meant adding numbers together and data retrieval, which was seen as an administrative matter, and not necessarily innovative.”

    This is of course verifiably incorrect. Benson,decided in 1972, solves a technical problem. Digital signal processing including filters existed since the 1950s. Digital image processing took already place in the 1960s. Pulse Code Modulation based on digitization of signals goes back to the 1920s. Error correcting codes were invented in the 1950s.

    There has long been an aversion against algorithmic type of inventions. Basically because mathematics is used to describe the functioning of algorithmic devices. I applaud the EPO for the recognition of the patentability of these inventions. The USPTO and US inventors are still suffering from the incorrect decision of SCOTUS on Benson.

    The earlier remark by AV implies that “computer implemented inventions” in the 1970s were just too simple. That is of course incorrect. If anything, they were too complex and difficult to grasp, as they required math (gasp) to be understood. This attitude is reflected in the US in Benson wherein a physical device (a shift register based digital machine) was deemed patent ineligible, because math was used to describe it.

    Shannon’s invention to use math (Boolean Algebra) to describe binary digital circuits, has been used and is still used against inventors in the USA to make inventions patent ineligible. The Europeans, originally suffering from the same syndrome, have grown with the industry and have largely shed this misinformed prejudice against math as an engineering tool.

  • [Avatar for zoobab]
    July 22, 2019 11:03 am

    The term “Computer implemented invention” does not have any meaning in the field of computer science.

    It was invented by the patent industry in order to get software patents through.

    The “technical” term was also criticized by Judge Jacob as being a restatement of the same problem.

    Furthermore, the EPO does whatever it wants, since they are not bound by courts decisions against them, such as Free Vs Orange in France, where judges clearly said the EPO grant of software patents does not have any legal ground.

  • [Avatar for Anon]
    July 22, 2019 11:02 am

    While I love the title of the article, and certainly appreciate the view in regards to obtaining suitable patent protection in any Sovereign, I would pause to add a note of caution, as well as a note of emphasis, that the patent protection system of THIS Sovereign (the United States) should carefully be noted as NOT the same as the (even “per se” and “as such”) mechanisms of the EPO and their emphasis on “technical.”

    I have long put forth that the US Sovereign choice of providing patent protection for anything that may be claimed in at least one of the statutory categories and provides utility within the Useful Arts is a far more broader and extensive provision of innovation protection than the EPO’s “technical arts.”

    Additionally, I have a few comments up to (but stopping at) the “Make Connections” point of the article:

    Two of the set of first comments from Mr. Deltorn reveal a LACK of understanding of the bigger picture in which (certainly for the US) innovators must operate within.

    The suggestions of “through a description of the prior art” and “definition of essential features” simply ignore the real life aspects of what is commonly known as Patent Profanity. I would certainly expect US examiners to be aware of this reality, and would find that if examiners are wanting items that HURT the ability of innovators to have fully viable innovation protection, that part of any dialogue on finding common ground is for individuals such as Mr. Deltorn to understand exactly why patent applications will NOT engage in at least these two items.

    Similar comments go to the first suggestions from Mr. Moumen. These examiners seem to be less “real world” and more “academic.” While it is certainly helpful to indicate at least one technical problem that may be solved with an innovation, it is client-Unfriendly to artificially cabin an innovation into solving only one technical problem. Quite in fact, most all US patent practitioners that I know have been taught the very opposite in the effort of writing claims NOT being limited to a single resolution of a technical problem.

    As with Mr. Delorn, Mr. Moumen’s desire for indications of how a (singular) solution is different from the prior art may well make the examiner’s job easier, but such is strictly Patent Profanity and is NOT advice to be followed (generally) by US practitioners. If nothing else were to come from this exchange, I would certainly hope that these examiners come to understand WHY the “what” that they want is NOT the “what” that we as practitioners have been trained to give them in the pursuit of maximum value for our clients.

    Not to be overly negative, as Mr. Moumen does give solid advice as to having fallback positions. These of course should not be treated as in relation to prior art, but rather, should be treated in the US sense of broadest to narrowest claims. I would add here that in the sense of “narrowing,” that US practitioners should avoid merely making obvious narrowings, and that the distinctions in the more narrow claims are to be aimed at being inventive in and of themselves (whenever possible).

    I also appreciate Mr. Versluis’s advice on clarity and sufficiency – throughout the intended scope of claims, including fallback positions.

    Not mentioned here, but of possible interest is a larger discussion with the client as to the aim of a patent application in the sense of whether the application is being aimed to be a “short and direct hit” or more of a launching vehicle for a family of Continuations and/or Divisionals.

    Having this conversation at the onset will help with BOTH managing client expectations as to cost and innovation protection coverage, as well as help practitioners understand – and relate to – examiners in the inevitable “negotiations” that ensue after filing.

    Additionally, I commend Mr. Moumen for recognizing the very real trade-off between (even) pseudocode and that which may be desired to be kept as “technically” secret as possible (that is, secret on the technical aspects). Some of the “big bucks” aspect actually comes from being able to translate the underlying “technical aspects” INTO a non-technical AND “natural language” description. After all, the examiners are not the only (and some would even venture so far as to say not the primary) audience to which an application is written. Applications are NOT engineering documents, and I think that the set of examiners here may be a bit “academic” in wanting the applications TO BE engineering documents.

    I can certainly see why they would want this, and why (if for example, there was no such thing as patent profanity), a far more deeply “engineering detail” style MAY WELL be a better thing, but the reality of the situation is that patent applications are LEGAL documents, and NOT engineering documents, and that – as Mr. Moumen rightly recognizes – there IS a trade-off involved in what is included in a patent application.

    From a personal standpoint, I recently had one of my own applications “redacted” in the client review phase because my writing revealed “too much.”