What is “technical” at the European Patent Office? Understanding flaws in some common arguments helps understand what is required.
It can, in terms of EPO patent applications, be hard to understand what is technical. A 2013 case explored some flawed logic sometimes used to argue things are technical.
In this article there are some thoughts based on T1670/07, which was an appeal on a Nokia patent application relating to planning a shopping route. Whilst this case was heard a little while ago, it is good to re-visit the decision as it provides a useful insight into how the EPO analyses certain types of invention.
One of the concepts that is hard to explain and understand when prosecuting software-implemented patent applications is the requirement for technical features that can interact with technical elements so as to produce a technical effect. This is a well known feature of EPO case law and is developed out of a case dating from 1988 relating to X-ray tubes (Koch & Sterzel) and so is now quite old. Koch & Sterzel is a good example to discuss as it is easy to understand: software (computer program) was implemented on a technical piece of apparatus (the X-ray apparatus) and the result of this combination was that the X-ray source lasted longer. Thus the interaction of the non-technical and technical integers had a real effect on the apparatus, which lasted longer. This is all well and good, but what does it mean in less compact systems?
The example from Koch & Sterzel is nice and straightforward to follow as it relates to a physical apparatus. What happens when you start to try and apply that logic to more complex systems? How would you apply it to a server-based method of planning a shopping trip, so that the user’s route is optimised and therefore time and energy are saved during that shopping trip? This was the subject matter of the Nokia patent application considered in case T1670/07, which was ultimately held to be non-patentable; i.e. there was no interaction between the technical and non-technical integers.
Some useful concepts were introduced in the case, which go some way to explaining how non-technical elements can and cannot be used in the thought process of assessing what is inventive. The case looked at some examples of flawed logic that can be used to argue for patentability. Of course, knowing when the logic is flawed can help to better understand what can be protected before the EPO. The three fallacies discussed in the decision are: the technical leakage fallacy; the broken technical chain fallacy; and the non-technical prejudice fallacy.
It is helpful to take each of these in turn and understand what each of them means.
The technical leakage fallacy may be thought of as simply arguing that because an item is computerised (i.e. it runs on a technical apparatus) it imparts technicality onto non-technical steps. In the case, it was argued that:
“the alleged non-technical feature of the information regarding the group of vendors “interacts with technical elements, in the form of the server, to produce a technical effect in the selection of vendors and the transmission of processed information regarding that selection to the mobile wireless communications device”.
It was held that the selection of vendors was not technical and simply because it interacted with a server could not make it technical. In other words, the mere use of software on a computer does not provide the interaction with a technical element.
The broken technical chain fallacy may be thought of as there being a break in the technical elements that provide the ultimate technical effect of an invention. So there is some non-technical element in that chain. One example was taken from an earlier decision relating to Graphical User Interfaces (GUI) where the ultimate technical effect was realised only after a user had made some interaction with the computer providing the GUI.
The final fallacy, the non-technical prejudice fallacy, is perhaps the hardest to understand. It requires an understanding of how the EPO assesses inventive step: elements of an invention that are held to be non-technical cannot contribute to the inventive step of an idea and, more harshly, are deemed to be known by the skilled person so that it would be obvious for them to implement non-technical ideas. That is, it cannot be inventive to implement (such as, for example, by writing software) a non-technical element, even if that non-technical element is new.
In the Nokia case, it was argued that the invention was technical as it “solved the problem of reducing the number of failed attempts to fulfil an order”. This sounds technical, which is no doubt why the argument was put forward, but it was held to be a fallacy because it involved using non-technical elements in the inventive step argument. In this regard, it was stated:
“The question is not whether the skilled person would consider providing these features because that has already been decided in formulating the technical problem. The question is simply how it would be done. As mentioned above, in this case, the “how” comprises conventional hardware carrying out the tasks in an obvious way.”
That is, the mere fact that a computer had been programmed to perform a non-technical method does not become technical if there is an apparent “technical” result.
This case does therefore provide some useful guidance as to what is and what is not technical in the eyes of the EPO. As with any patent office, there can be differences between examiners at the fringes of what is and what is not patentable.
We would be happy to discuss the above in more detail; please contact your usual Barker Brettell patent attorney if you would like more information on this topic or have any specific inventions where you would appreciate guidance as to whether the idea might be seen as sufficiently technical.
