This second post is part of an ongoing SFLC.in project comprising an empirical study of the software patents granted annually in a given financial year by the Indian Patent Office from 2014-22, and the trends arising therefrom.
Introduction
In the second part of the blog post, we will be examining how things have panned out, and whether the Executive and the Judiciary, along with the Legislature have a role to play in the quagmire that we are in.
The study shows that the number of irregular patents being granted by the patent office in violation of Section 3(k) of the Patents Act have been increasing over the years. Many a time, the decisions of granting patents to applications in the software field lack any real reasoning, are unsigned, and do not even mention the application number or any other identifier. This is an example of such an order:
Fig. 3 Many orders lack proper reasoning and objections are mysteriously cleared.
Misplaced reliance on EU jurisprudence
Many a time, cases have been decided erroneously by misapplying EU jurisprudence in the Indian context. One such case is Ericsson vs. Intex (2015) in which it was decided that a computer program having a ‘technical effect’ is patentable. Through this, a back-door entry was given to the provision from the Patents (Amendment) Ordinance, 2004 which was expressly rejected by the Parliament.
The phrase “technical effect” has not been defined in Indian law. However, as per the European Patent Office (EPO) in T 1173/97, “technical effect” means mere interaction with a computer. The execution of a computer program, by itself, has physical and electrical effects on the hardware, and thus has a “technical” effect. Thus, as reiterated by the EPO in T 1125/17, mere ‘technical effect’ produced by a computer program onto the hardware does not suffice in making the computer program patentable.
There is a ‘further technical effect’ required that contributes towards solving a technical problem and goes beyond the “normal” physical interactions between the computer program and the hardware. However, there is a caveat – the evaluation of ‘further technical effect’ does not require examining prior art. This position came to be after the abandonment of the “technical contribution approach” deployed in T 208/84.
According to this approach, a computer program may be patentable if it produces a ‘technical effect’ as compared to prior art. It is quite clear that abandoning the ‘contribution approach’ has left a void in the law, which hasn’t quite been filled by other approaches such as the “further technical effect approach”. One of the reasons for this is the absence of prior art examination. The ‘contribution approach’ may be flawed in the sense that it relies on the ‘partial’ technical character argument.
In other words, it argues that even though there are non-technical features in a computer-implemented invention, it may still be considered as technical as long as there is technical contribution in the state of art. But this is an example of the “technical leakage fallacy” (as later discussed by the EPO), according to which the mere interaction with technical elements is not enough to make the whole process technical, and thus produce a ‘technical effect’.
While the contribution may have its shortcomings, evaluation of prior art is a must. Since ‘further technical effect’ is the yardstick by which a computer program is granted a patent, it makes no sense to not evaluate the further technical effect being produced by a computer program against the further technical effects of existing computer programs. Hence, neither the contribution test nor the further technical effect test is up to the mark, and there needs to be another test in place.
For CRI-ing out loud
Enter the CRI guidelines. But what are the CRI guidelines? Like the Patent Manuals, the Computer Related Inventions (CRI) Guidelines are a series of guidelines that are to be used by Patent Examiners in evaluating applications for patenting computer-related inventions. Thus, they are supposed to limit the number of Software Patents granted. However, the opposite is true.
Fig. 4 The CRI guidelines have enabled the granting of software patents
Another problem with the CRI guidelines is that they masquerade as law since they along with the Manuals lack the force of law. Thus, they could be called as a wolf in sheep’s clothing as they cannot even be strictly challenged before a court of law.
The 2015 CRI guidelines were problematic and there was a 40% increase in the average number of software patents that were granted in the brief duration for which the 2015 CRI Guidelines existed.
In contrast, the 2016 CRI guidelines slowed down the number of software patents being granted presumably because of the three-part test which proposed that for patenting a software there must also be the presence of novel hardware. This requirement led to the slow-down in the number of software patents being granted, as research shows.
Furthermore, the latest 2017 CRI Guidelines immediately worsened things as there was a 54% monthly increase in the number of software patents being granted. This is presumably because of the removal of both the three-part test, and the ‘further technical effect’ test, and the treatment of software at par with other general inventions.
Proprietary programs and patents: So long FOSS!
As long as it can be run, it can be patented. Because of this vulnerability in law, in many patents, patentees just add a ‘hardware limitation’ by stating that the program is run on a general-purpose computer to circumvent the law and thus become eligible for a patent. This endemic is not limited only to computer programs, algorithms are completely prohibited from being patented irrespective of per se or not – yet giants like Google, Facebook (now Meta) are still being granted patents for their algorithms.
Generally, the creative part such as a source code may be eligible for copyright protection, whereas the functional part such as the algorithm and the program itself may be patentable – just not in India.
Thus, there is no doubt that this Latin phrase could become the death knell for FOSS and the trojan horse of software patents, hiding the soldiers of proprietary software to single-handedly destroy the city of FOSS.
