Specialist Chapter: Patenting computer-implemented inventions at the EPO
This is an Insight article, written by a selected partner as part of IAM's co-published content. Read more on Insight
Computer implemented inventions are patentable at the EPO, but can often face significant resistance, in particular in relation to inventive step and, with increasing frequency, sufficiency. Case law on the assessment of computer implemented inventions can give the impression that prosecution of these cases involve different considerations from other inventions. We explain that the assessment of inventive step at the EPO for computer implemented inventions can be more clearly understood as a normal application of the well-known problem-and-solution approach, and highlight areas to be considered to avoid insufficiency objections.
- Technical/non-technical subject matter
- Inventive step
- Computer-implemented inventions
Under the European Patent Convention (EPC), European patents should be granted for any inventions, in all fields of technology. At first glance this principle seems all-encompassing, similar perhaps to the US Supreme Court’s phrase from the 80s in relation to the limits of patentability: “Everything under the sun made by man”.
However, the European Patent Office (EPO) attaches great weight to the term ‘technology’, and from it imports a requirement that an invention must be ‘technical’ or have ‘technical character’. The EPO’s definition of technical also departs somewhat from the common-usage definition. Indeed, the EPO shies away from explicitly defining what is ‘technical’, although it does know what is not. The design of programs for computers is not considered by the EPO to be a technical pursuit, for example. Similarly, the devising of rules and methods for performing mental acts and mathematical methods, which often form the core of a computer program, is not a technical pursuit. In fact, the EPC is explicit that these things are not to be regarded as inventions.
That said, inventions implemented using computers are clearly patentable at the EPO. This is apparent from the large numbers of granted patents with claims that begin, “A computer-implemented method …”. More specifically, if you can show that the computer-implemented idea provides an advance in a field of technology that is not limited to one of the excluded classes mentioned above, you can be granted a European patent.
Practically, as is the case at other patent offices, two barriers must be overcome in order to patent a computer-implemented invention. First, the inherent patentability of an invention must be established. At the EPO, meeting this requirement is straightforward for a computer-implemented invention, since all that is required is that technical means be part of the claimed subject matter. Perhaps surprisingly, the use of a computer is considered sufficient technical means – in other words, a program for a computer is, paradoxically, always inherently patentable due to the implied use of a computer!
As a consequence, most of the substantive assessment of patentability (and technicality) comes with the second barrier – inventive step. It is this barrier that causes most problems for computer-implemented inventions at the EPO.
Computer-implemented inventions come in many forms. They may relate to machine learning, simulations, graphical user interfaces, databases and so on. Specific case law on technicality has developed in each of these categories, and this vast corpus of decisions can give the impression that different types of computer-implemented invention involve different considerations. In fact, the assessment of inventive step at the EPO for any computer-implemented invention can be understood as a normal application of the well-known problem-and-solution approach. Although the issues that can occur may seem numerous, if these are considered during the initial drafting process then prosecution can be greatly simplified.
The problem-and-solution approach involves the identification of an objective technical problem that is solved by the novel features in the context of the closest prior art document. Because of the word ‘technical’ in the phrase ‘objective technical problem’, novel features that are deemed to be non-technical are disregarded in the analysis. Indeed, examination reports issued by EPO examiners frequently list large numbers of identified novel features but present them as struck-out to indicate that they will, in effect, be ignored when deciding whether the claim is inventive.
When is a non-technical feature technical?
The word technical is the cause of much confusion since it is not defined in the EPC. Indeed, at every opportunity, the Enlarged Board of Appeal of the EPO has intentionally not defined the term. This is because it is not apparent what fields of technology will arise in the future, and so a fixed definition of the term may not be sufficient to capture future advances in technology. As such, applicants do not have explicit guidance as to what features of computer-implemented inventions may be considered technical. On the other hand, the Boards of Appeal have confirmed that certain features, such as artificial intelligence models and details of computational simulations, are inherently non-technical.
However, there is a caveat. A feature initially deemed non-technical by the examiner can be argued to make a technical contribution to a claim if, by its combination with other technical features, it contributes to solving the objective technical problem. Such features can then be brought back into play when assessing inventive step.
This caveat is key to the patenting of computer implemented inventions. Put explicitly, the features of the computer-implemented invention are by definition merely software or mathematical in nature and so are, in essence, non-technical. However, their influence on some technical process can involve technical character. For example, a mathematical method for calculating a value is not a technical feature in and of itself. But if that value is a control parameter used for flying an aircraft more efficiently, the mathematical method can be said to have technical character by virtue of its interaction with the control of the aircraft, a clearly technical process.
In this example, the software influences a technical process that is external to the computer. However, technical character may also be based on the influence of a technical process within a computer. This may be the case even if the purpose of the software being run is for an excluded application, such as a business method for insurance. A recent case (T2910/19) related to a computer-implemented method for calculating insurance losses incurred on properties following natural catastrophic events: a non-technical application. The calculations were carried out by parallel processing and the computer-implemented invention selected a processor based on the insurance-related functions already stored in the processors’ local caches. This was considered to import technical character because it enabled the system to avoid the transmission of those functions to the local cache of a processor selected purely on the basis of conventional methods. As such, the technical steps of computation were achieved more efficiently and the method was found to be inventive.
Since the software features of computer-implemented inventions are, absent their context, to be considered non-technical such that they cannot contribute to the inventive merit of a claim, the key focus of argumentation about inventive step is often related to the effect of those features on the technical process. For example, consider an algorithm trained by machine learning that is being used to determine the optimum time to refuel a vehicle. If the algorithm enabled the vehicle to work more efficiently, then the algorithm might be patentable. However, if the algorithm simply optimised the monetary cost of refuelling, then this would not be a technical advance. Arguments as to the particular effect achieved by claim features are therefore common. Prosecution can be assisted by a clear explanation of the technical ramifications of the claim features in the description.
Inventive across the full scope of the claim
Other conventional aspects of the problem-and-solution approach can become relevant in relation to arguments about the technical effects of features. For instance, it is well explored that for a claim to have an inventive step at the EPO, it must be inventive across the full scope of the claim. That is, the objective technical problem must be solved by virtually all embodiments within the claim. For computer-implemented inventions, this can be brought out in several ways, each of them usually depending on the way the relevant features are expressed.
The requirement that a claim must be inventive across its full scope in effect means that the claim must be technical across its full scope. If it is possible to envisage, within the scope of the claim, both embodiments where the novel features have technical character and embodiments where the novel features do not have technical character, then the claim is not inventive. The most straightforward example of this is that a purely mental implementation of the novel features must be ruled out (that is, if the task could be carried out by a human, no matter how long it might take). If a claim covers a purely mental implementation, then it will encompass a non-technical mental act and so not be technical across its full scope. This is typically an issue with the way a claimed feature is expressed. However, it might be problematic if the patent specification was not drafted with the EPO in mind.
A more troubling example is that of a core advancement in AI – say a new and improved model architecture. If this architecture is claimed to apply to a particular technical problem, such as image enhancement, all is fine as the model may be said to contribute to solving an objective technical problem. However, the model may be much more widely applicable than that (it might also be great at financial analysis, say). A broader claim encompassing the financial analysis application would likely fail as now there is an embodiment where only non-technical problems are being solved. All of a sudden, the technical character imported into the new model vanishes, leaving non-patentable subject matter.
A further corollary of the requirement that a claim must be inventive across its full scope is that the technical effect relied upon must be necessarily achieved, as opposed to being a mere potential technical effect. A potential technical effect is a downstream effect in a technical process that is dependent upon certain conditions. An example is the use of a simulation to model a chemical process. The simulation may be useful in predicting an increased yield of a product. However, unless the claim is restricted in such a way that the increased yield is definitely achieved, it might not be possible to rely upon this effect to establish an inventive step.
Is the technical effect achieved?
For a technical effect to be relied upon, it should be considered whether to limit the claim such that those conditions required for it to be achieved are recited as explicit limitations. In the case of a simulation, this may be achieved by (1) claiming the use of the simulation to solve a particular problem; (2) expressing the technical implementation that is specifically beneficial for the simulation; or (3) reciting a direct link with physical reality, such as explicitly claiming the sensing or control of a technical process.
When the inventive step relies upon the effect of novel software features on a technical process, care must be taken to ensure that those features actually influence the technical process as opposed to merely interact with it. As an example from case law (T1670/07), the use of technical means to send non-technical data does not imbue that data with technical character. However, data with some functional attribute beyond its information content may be technical.
Moreover, care must also be taken when a computer-implemented invention interacts with a user or operator. In many cases, technical character can be recognised in the use of software to assist a user in carrying out a technical task. For example, if the software presents information to the user that enables them to identify some otherwise non-observable parameter of a system – so that the user may better control the system, say – then it may be technical.
However, a technical effect must not rely on correct human decision-making. This is considered to break the chain of causality in achieving the technical effect. For example, if a computer program is provided to improve patient compliance with a drug regime, this could in some cases be recognised to have a technical effect. However, it is unlikely to do so if the improved compliance is conditional upon the correct behaviour of the patient.
The objective technical problem must be specific. It is not, for example, possible to simply recite in the claim non-specific, boiler-plate language such as “a computer-implemented method, used in a technical process, wherein ...”. It is necessary to limit the claim to the specific area in which the technical character is found. In the context of a computer-implemented invention that influences a technical process that exists outside the computer, it can therefore be beneficial to limit the claim to that specific process. For example, if the invention is the control of a manufacturing process, the claim might be limited either by reciting the manufacturing process itself or, alternatively, some feature that intrinsically links the computer-implemented invention to that manufacturing process.
The same limitation of the claim may be beneficial if the computer-implemented invention influences a technical process that exists within the computer. In one reported case (T2330/13), the invention defined novel process steps that in isolation would have been non-technical but were specifically adapted for use with bit-strings and bit-matrices. Because these were positively recited in the claim, the alleged effect of efficient parallel evaluation was achieved.
Comparison with the prior art
Of course, beyond the need for technical character, assessment of inventive step at the EPO always requires an identification of the technical effect achieved by the novel feature in comparison with the prior art. It is often the case with machine learning inventions that the technical achieved over the prior art is improved accuracy. Often the difference between a process for the estimation of a technical parameter by the claimed invention and by the prior art is the algorithm used for the estimation. In such cases, a technical effect should be recognised if the novel algorithm for estimation provides a more accurate value for that technical parameter.
However, beyond foreshadowing such improved accuracy, it is necessary to show that this improvement is achieved compared to the specific closest prior art cited by the examiner. If this prior art was not known to the applicant at the time of drafting, this may be problematic. Without evidence of the advantage, the objective technical problem may be defined as the mere selection of an alternative. In the context of machine learning, this can enable an examiner to argue that any machine learning algorithm may be simply substituted for the method of the prior art, and in the field of software there are rarely contraindications for such a substitution. Thus, it is important to establish an advantage over the prior art.
Interestingly, a similar situation often occurs in the field of chemistry, where it is common to file comparative data establishing that the purported advantage is achieved. This supporting evidence can be filed during prosecution to support arguments for patentability, as long as the technical effect is plausible from the originally filed specification. Although perhaps speculative, it is possible that a similar practice could arise in the field of machine learning.
The step of the problem-and-solution approach that requires the greatest care is typically the identification of the objective technical problem. Here, to avoid hindsight, it is important to remember that the problem that the skilled person is trying to solve in the prior art must not contain a ‘pointer towards the solution’. This is an area in which computer-implemented inventions can be disadvantaged, since the case law has developed such that non-technical pointers to the solution can potentially form part of the objective technical problem, for example as a constraint to be met by the skilled person.
When arguing in support of an inventive step the issue of technical prejudice can often be used to show that a modification of the prior art would not have been made. In keeping with the limitation of the inventive step to technical matters, it is not possible to rely upon a non-technical prejudice in the prior art leading the skilled person away from the invention. Just because a diligent administrator or HR person would teach against the modification does not render it inventive. There has to be clear technical teaching in the prior art away from a particular modification (such as a perceived technical incompatibility) for a prejudice argument to be run in favour of an inventive step.
The relevant considerations for computer-implemented inventions in connection with inventive step therefore follow from the same analysis that is applied to other types of invention. The main area of contention is whether it is possible to establish technical character for the various aspects of the claim under examination.
The consideration of sufficiency of disclosure is also the same for computer-implemented inventions as in other fields. However, in the field of AI and machine learning, this issue requires a little more attention to detail. In the case law (T161/18), some machine learning inventions have been found to be dependent, not only on the core algorithm used, but also on the selection and capture of training data. The same reasoning can be extended to other aspects, such as the choice of hyperparameters and basis functions. Many extra levels of detail can be provided for machine learning inventions, and they should not be routinely treated as a simple black box. Before drafting, there should be a comprehensive assessment of how all the aspects of the machine learning system contribute to its advantages.
While we are nowhere near a situation in which petabytes of exemplar training data need to be provided with every application, the requirement that the skilled person be able to carry out the invention based on the specification alone should nevertheless be taken seriously. In numerous cases this requires at least a discussion of how training data may be captured and what ‘good’ training data looks like. In some cases, the benefits of the machine learning invention might be robust to these details, and applicants must take care not to suggest that any of these details are essential to a technical effect that is to be relied upon for an inventive step. These issues should be explored in detail at the earliest stages and careful drafting with them in mind is crucial.
The task of patenting a computer implemented invention at the EPO can seem daunting given the long list of failed attempts reported in the case law and the seemingly complicated requirements. However, the patentability of computer-implemented inventions is certainly possible and is based on the same first principles as any other invention.
Moreover, as the EPO itself has recognised, AI and machine learning represent key driving forces in what may turn out to be the next technological revolution. Such techniques have already become ubiquitous in people’s daily lives. For those innovating in these fields, strong and effective IP protection is essential. This often includes the need to obtain patents that not only survive first contact with the patent office but are also robust enough to stand up to post-grant challenge and subsequent litigation.
Given the large numbers of AI applications being filed every year the case law will likely develop at a rapid pace over the lifetime of applications filed now. Inevitably, decisions made on some of the difficult edge machine learning cases will bleed back into wider software patentability as a whole.
More than ever, it is important to be familiar with how these existing patentability principles relate to software inventions when drafting. Drafting is almost always the one chance to really ‘get it right’, and practitioners and applicants will have many years to live with the decisions made here. This is particularly true in the field of machine learning, where familiarity with the underlying algorithm is essential to ensure the best and most robust scope of protection is achieved.