Introduction
On the 8th of April 2022 the Technical Board of Appeal of the European Patent Office realised the latter decision over software patentability (computer-implemented simulations). An illustrative example of the interaction between law and technology, an opportunity to explore how technological has reshaped law throughout the software patentability context.
At the beginning of the century the debate among software was its patentability: shall it be patented or not? Nowadays, this debate is outdated. The reality is that the relevant States leading high technology industries accept the patentability of software (varying the degree). In fact, we have witnessed the dwindle of requirements for the software patentability, to the extent that even the initial exclusions within the law can be patented.
Computer-related inventions (‘CRI’ or ‘CII’) and Internet of Things (‘IOTs’) (which have been landing to our life and they would flood our future) are ‘Trojan horses’ granting patents to excluded patentable software. In consequence, the debate must move beyond the subject-matter and embrace alternatives within the current patent system to curtail undesired patented-software.
Mandatory patentability
International legal framework
The software protection is an international problem. Reaching a consensus over software legal protection has been a graveyard of good faiths in the international arena. As a result, it was not until the TRIPS Agreement (‘TRIPS’) that the issue was ‘successfully’ faced.
The TRIPS was the first international instrument dealing with software directly. In its article 10.1 states that they are literary works under the Berne Convention. A trend that was present in the EU Directive and followed by the 1996 WIPO Copyright Treaty. In this sense, the notion of software as a literary work was worldwide accepted.
However, a more complex issue was debated: the software patentability. The patentability issue in TRIPS, addressed in article 27, brings the definition and requirements, but does not contain an explicit mention to software.
The TRIPS Agreement leaves the patentability of all software unanswered. But as far as there is no negative direct or indirect provision excluding it, an international mandate over software patentability is possible.
States practice
The current practice of the States can be divided into three tendencies: the explicit exclusion, explicit allowing and lacking specific provision.
Within the first category, the EPO, China or India do not allow the patentability of all the softwares. This blogpost focus is now on the first: the EPO. The EPO Convention has a direct exclusion in the patentability of softwares ‘as such’ article 52 (2)(c).
Initially, it was an extended exception of the subject-matter. However, with the technological evolution in the computer sector the first exception came into play (VICOM Decision), which in addition to the newest improvements as the ICC or the IOT had undermine its firsts decisions where the exclusion was applied very restrictively. To adopt the patentability to the new technological improvements, the EPO bypassed the prohibition by the creation of further distinctions over software. Thus, the current regulation of the EPO focuses on the innovative step and requires to the innovation (software) to have a ‘technical character’.
However, this requirement does not seem to be the most adequate, as far as software ‘as such’, by definition, is conceived as ‘technical’. Any software inserted into a hardware is going to produce, at least, an electric current, thus, the technical effect is intrinsic. For those reasons, the EPO required that, to bypass the exclusion, the technical effects had to go ‘further’.
Currently, the EPO guidelines do not provide a clear and precise definition of ‘technical character’. The characterisation of the term must be found in its decisions in a case-by-case fashion. An ad-hoc approach that can be portrayed as flexible and adaptable or, in other words, due to the prohibition over the subject-matter, as a dragged patch.
Some cases might be useful to understand the practical implications of the prohibition and the exceptions such as Comvik and Hitachi cases (software methods and computer-implemented inventions), Nokia (clarifying technical character) and G1/19 (software-simulations). From the abovementioned cases, it is clear that a software might be patentable if it impacts into physical objects i.e. controlling the brakes of a car. However, difficulties arose in relation to computers where the further technical feature can be loose as there might not be a physical interaction. There, the improvement of data management, improving communication between devises, securing data transmission or improving the resource allocation might serve as guidelines. Furthermore, areas such as AI, blockchain and bioinformatics seem to fulfil those requirements with ease.
The EPO evolution has proved to be tortuous towards its invention requirement interpretation. In the resulting practice, the technical effect of the invention has been interpreted ‘loosely’, whereas the exclusion of art 52 (2) (c) has been applied restrictively. Even the EU Commission stated that ‘(…) patentability of programs as such is now admitted in the practice of the EPO (…)’. As a result, the risks of patenting software ‘as such’ continuous and it has been admitted by the EPO. Nowadays, the patentability of software ‘as such’ is present and has come to stay.
Assuming the current situation
The software patentability risks are not new, and the problem is not the teleological protection granted by the patent, but the misuse of it. The desirability of software patentability passes throughout the need to go beyond the subject-matter ban approach and embrace further possibilities in the international and regional/national level dealing with its requirements: novelty, inventive step and industrial application, or, even further, the length and limitations to software patent.
The subject-matter has proved to not be the appropriate firewall against undesirable software patents and it is time to move forward. The current situation must be accepted, and the patentability of all softwares shall allowed. At the end, the mistake has been to drag such prohibition over the time since the ratification of the treaty (in a very specific social and technological context), questioning such prohibition is necessary. It is no more an issue of subject-matter, but of patentability requirements. The focus and energy of the debate must be on its requirements (novelty, inventive step and industrial application) which can curtail unwilled applications.
Searching within the patentability requirements: industrial application
The EPO example shows that the current technological needs have shifted, and the initial broad exclusion had to be reshaped. There, the innovate step is playing a catalytic role. Nevertheless, this blog aims to stress another alternative (even complementary) found in the last requirement of the patentability: industrial application (in the US ‘utility’). Such element is sometimes unnoticed, but it could take a decisive step dealing with abstract ideas, inherent to software ‘as such’. It might serve to avoid vague (and strategic) language in the claims which could endow abusive power.
Remembering Lemley proposal which based the software patent on the specific way to implement the function rather than the software function one could propose that industrial applicability criteria shall enforce a ‘kind’ of similar approach. In these terms, it would not protect the ‘process’ as Lemley proposed, but it would reduce the scope of protection from the patent to the applicability disclosed.
Therefore, the protective scope of the intellectual property right will be limited to the functions exposed on the application. Such approach would limit future unexpected uses of that software that might come into the future, and, at the same time, it will forbid abstract registrations. If the industrial application is not clear (because it is too broad), if there is a ‘non’ practical useful outcome, the protection would not be granted. Thus, challenging the classic reticent of ‘non’ practical useful outcome from abstract software patents.
Therefore, without denying the patentability, the changes in its requirements will help to diminish the software patent portfolio and deal with the boundaries of the software (avoiding claims for its broadest meaning) and it could even route the patent to akin of more practical outcome (within its abstractness).
Conclusions
The current situation must be accepted, and the patentability of all softwares shall be embraced as its requirements (novelty, inventive step and industrial application) can curtail unwilled applications. The subject-matter has proved to not be the appropriate and it is time to move forward.
Assuming the status quo shall be seen as an opportunity to reshape the software patent requirements, length and limits. This is the current battlefield of software patentability. By the meantime, exacerbated patents are granted to allegedly excluded softwares which are undermining innovation and creating unnecessary and unfair technological fences to progress.

Guillem Gabriel-Pizarro
Guillem Gabriel-Pizarro is a PhD researcher at the European University Institute in Florence, Italy. His research interests are Insolvency, Intellectual Property and Private International Law. Before starting his PhD at the EUI he studied at the University of Edinburgh and the Autonomous University of Barcelona.