Protecting Software Inventions in Europe

This article first appeared in Patents in Europe 2016/2017, a supplement to Intellectual Asset Management, published by Globe Business Media Group – IP Division. To view the issue in full, please go to

The protection of software inventions in Europe and the United States has often been described in terms of a pendulum swinging between a liberal position, in which almost anything can be protected, and a restrictive position, in which it is much harder to obtain patents for inventions relating to or using software.  While the United States has recently taken a decisive swing to the restrictive side, the position in Europe has been relatively stable for the best part of a decade.  There has perhaps been a small shift towards the liberal side very recently, but the European Patent Office’s (EPO) basic approach to the examination of inventions involving software and other nontechnical features has not changed – namely, only technical features can contribute to inventive step.  However, an open question remains as to exactly what is meant by ‘technical’.  The EPO Boards of Appeal have generally declined to define ‘technical’, perhaps wisely fearful of creating a hostage to fortune in an ever-changing technological landscape.  This chapter outlines the EPO’s current approach to examination of inventions involving software and other non-technical subject matter and discusses what kinds of things are regarded as technical and non-technical in the EPO.  It also advises on the presentation of inventions to best emphasise their favourable aspects.  


To be patentable, an invention must:

  • not comprise excluded subject matter;
  • be novel; and
  • have an inventive step.

It is settled case law that non-technical matter is excluded and that technical subject matter is not excluded. Computer-implemented inventions often involve a mixture of technical features (eg, a computer) and non-technical features (eg, steps in a procedure). The EPO’s current approach to the examination of inventions involving both technical and non-technical features (referred to as ‘mixed inventions’) was developed between 2000 and 2007 in a series of cases (most notably Comvik, T 0641/00) which decided that the presence in a claim of any technical feature, no matter how banal or old, means that the claimed invention is not excluded.

However, that only addresses the first of the three criteria and most attention is now focused on the nature of the inventive step.

Technical inventive step

The current approach requires a technical inventive step; further, non-technical features may not contribute to that technical inventive step.  Thus, if the invention is a straightforward, uninventive implementation of a non-technical idea, such as a business method, no patent will be granted.  In other words, just putting ‘computerimplemented’ in front of a business method will not result in a patent. 

Therefore, a key step in the examination of mixed inventions is to identify which features are technical and which features are not.  Once that has been done, the examiner will ignore the nontechnical features and consider only whether an invention can be found in the remaining technical features.  The EPO will divide a claim feature such as “a processor adapted to filter received market data in accordance with filter criteria” (as found in Deutsche Börse, T 1992/07) into two parts: the processor (which is technical) and the function it performs (which in this case is not).  Ignoring the latter, we are left only with a generic processor, which is not novel.  Various justifications have been given for this approach. One is that inventive step must be judged from the point of view of a technical person (eg, a developer tasked with implementing a non-technical idea).  Alternatively, it is said that the non-technical features form part of a background ‘requirements’ phase that takes place before the potentially inventive implementation process carried out by a developer.

A recent modification to this approach, which could be seen as a slight shift towards liberalisation, is to allow a non-technical feature to contribute to inventive step, provided that it combines with other technical features in the claim to solve a technical problem.  This change, reflected in the EPO’s new Guidelines for Examination issued on November 1 2015, derives from the 2013 PayPal decision (T 0844/09).  This decision related to the authentication of a user by the use of test transactions to a bank or credit card account. In this case, the Board of Appeal took the view that the business method was subverted to solve the needs of the technical problem, in contrast with the widely cited Hitachi auction method decision (T 0258/03), in which a patent application for a modified online auction method designed to cope with uncertain transmission delays was refused.  Setting out a clear rationale for why PayPal’s application was allowed and Hitachi’s was refused is difficult.  Perhaps the difference is that PayPal carried out non-technical steps (ie, the test transactions) that served no purpose in the overall business method in order to solve a technical problem; whereas in Hitachi the overall business method (ie, the procedure for an auction) was modified to avoid, rather than solve, the technical problem (ie, the uncertain transmission delays).

Contentious fields

So how do we know what is technical and what is not?  The list of excluded categories in Article 52(2) of the European Patent Convention – which includes methods of doing business, mathematical methods, rules for games, aesthetic creations and computer programs – is not exhaustive, so other things may also be non-technical.  As mentioned, the Boards of Appeal have avoided giving any general definition of what is technical and recently explicitly refused to do so, stating: “boards therefore interpret what is or is not technical in each individual case before them using their judgment” (Uniloc, T1461/12).  The UK Court of Appeal has criticised this approach, comparing it to saying “the exclusion is like an elephant: you know it when you see it, but you can’t describe it in words” (Aerotel & Macrossan, EWCA Civ 1371/2006).

There seem to be two approaches to deciding whether an invention relates to technical subject matter.  The first is to look at the qualifications of the person who might try to implement an invention (or part thereof).  This derives from the ‘problem and solution’ approach to inventive step, which focuses on what a skilled person would do to solve a problem or implement a non-technical idea.  If the skilled person would be expected to have a science or engineering degree, all is good; if he or she needs an MBA, the prospects are not so great.  The second approach is to look at how inventions in similar fields have been treated in the Boards of Appeal case law, which is extensive in this field.  The diagram below illustrates subjects wherein the Boards of Appeal have considered some inventions technical and others not.  This chapter is too short to discuss all of these in detail, but a few examples can be considered. Uncontroversial areas include:

  • operating systems;
  • communications and networking;
  • image, audio and video processing;
  • cryptography and compression;
  • bioinformatics;
  • database structures; and
  • synchronisation.

On the other hand, areas that frequently receive
rejections are:

  • mobile phone billing schemes;
  • financial prediction algorithms; and
  • trading systems.

Digital rights management is a good example of a subject area where some inventions are readily protectable and others are clearly not.  Cases that concern the cryptographic underpinnings of
whatever mechanism restricts copying or use of content are readily protectable; however, a new rule as to what uses are allowed (eg, the terms under which loans or transfers are allowed) is not.  In the advertising field, the basic idea of tailoring advertisements to the user has been held to be a commercial one, as are specific criteria to be used for the selection or evaluation of advertisements (Sony, T 1000/08).  However,
there is plenty of scope for protecting the methods and hardware that actually deliver the right advertisement to the right place at the right time.  In some other fields (eg, mobile payments and transaction processing systems), patentability very much depends on the detail of an invention and the manner in which it is described in the application.  Applications with plenty of technical detail and explanation of technical problems overcome often fare better than those which are light on implementational detail.

Maximising your chances

How can you maximise the chances of obtaining a patent?  The most important consideration is the initial drafting of the application.  Examination of an application is likely to go much more smoothly if the examiner starts on the footing that the invention is technical.  However, if an objection is raised that the invention or parts of it are non-technical, it can be hard to overcome.  Therefore, a high level of technical detail of the implementation of a method must be described, even if not initially claimed. Drawings of systems and flowcharts of methods are generally helpful, if specific to the invention.  Most important of all, from the perspective of the EPO at least, is to present a technical problem and its technical solution.  It can help hugely if the problem is old and the invention is a new, technically improved solution.  Often, putting the invention in this light is a matter of picking the right level of generality for the problem.  In PayPal the problem could have been seen as quite specific – “how to implement a scheme of test transactions” – or more general – “how to authenticate a user on-line without real world contact”.  In this case, the more general problem (accepted by the board) allowed the test transactions to be presented as a specific technical solution to the problem and supported patentability.  The more specific problem (initially adopted by the Examining Division) left the claimed invention as a straightforward and uninventive implementation of the process of test transactions.

However, in some cases the opposite applies and a more specific problem is more appropriate.  One example is in route planning, where an invention expressed in terms of finding an optimised route through a graph of nodes and edges having associated ‘cost values’ would be considered an abstract mathematical method (as demonstrated in Beacon navigation, T2035/11).  By specifying that the edges are roads and the ‘cost values’ are distances or estimated travel times, the invention is given a clear technical character, rooted in a real world problem.



Once an objection has arisen, there is less that can be done because of the limitation of working within the scope of the application as filed.  However, it is important to focus efforts on profitable avenues and avoid wasting time and effort on arguments that will never succeed.  Where the EPO examiner considers that an application contains no technical content of significance, he or she may refuse to search the application at all.  The basis for this procedure is that if the only technical content is entirely generic (eg, general-purpose computers and networks), then such content is ‘notorious’ (ie, so well known that there is no need to cite specific prior art).  Recovering from such an objection is very difficult, but not impossible.  A useful approach is to cite prior art yourself, with the aim of showing that a variety of technical solutions to the problem at hand are possible.  Otherwise, you must draw the examiner’s attention to features that are believed to be technical and non-standard.

With prior art to consider, the key point is to reframe the problem in the appropriate way.  Even if a technical problem has been put forward in the application itself, the examiner
might not adopt that approach or the prior art might present a different starting point.  Prior art that seeks to solve the same problem in a different way can often be helpful; however, it is necessary to draw out differences in the technical implementation of any underlying non-technical process, rather than in the nontechnical process itself.  Ideally, you should show technical improvements in the implementation, such as:

  • more efficient use of resources such asbandwidth or processing power;
  • increased speed or reliability; or
  • increased user convenience.

Ideally, such advantages should be substantiated and supported in the application itself, rather than merely asserted in argument.  

Dead-end arguments

A review of the case law reveals arguments and requests that are frequently advanced, but do not go down well at the Boards of Appeal:

  • attacks on the validity of the board’s approach to mixed inventions and requests for questions to be referred to the Enlarged Board;
  • the argument that because some technical measures have been applied to solve a problem, the problem must itself be technical;
  • the argument that an invention is technical because some technical information is presented to a user or something technical happens as a result of user action;
  • the argument that because the software is new, the computer running it operates in a new way; and
  • the argument that the invention is inventive because it overturns some non-technical prejudice (eg, a commercial disincentive) in the relevant art.

The latter point goes against some case law in the United Kingdom, but has been reiterated by the Boards of Appeal, which take the view that if something is technically obvious, commercial reasons should not make it non-obvious.


To obtain a patent in Europe for an invention relying on software it is necessary to consider whether what the software does is technical or whether it is an implementation of a nontechnical idea (eg, a business method).  If the former, then the patent application – and if necessary the arguments during examination – can focus on what is done or how it is done, according to where the novelty lies.  However, if the invention implements a non-technical idea then it is necessary to identify technical aspects of the implementation and focus the application on those technical aspects.  In this case, showing novelty and improved results in the implementation is also necessary.


Search by Name or Specialism