Ericsson v. Intex, part II – The Perils and Pitfalls of Software Patenting

(Image Source: )
(Image Source: )

The first part of this post looked at the Ericsson v. Intex judgment as a whole, while this second part is looking at the specific potential influence it can have on the issue of Software Patents in India. We have addressed the issue of software patenting, in India and beyond, on multiple occasions – specifically, here, here, here and here. The Indian position has been quite ambiguous for a very long time – or rather, as Prof Shamnad Basheer puts it, confusingly confounding. But this judgement by Justice Manmohan Singh of the Delhi High Court throws a lot of light on the issue. [Very long post ahead.]

The ‘per se’ debate

Before going into the Court’s judgment, let’s take a step back and see what the broader debate is. The distinction laid down by the Court here rests on the usage of software “per se”, a distinction quite similar to the one laid down by the European Union’s European Patent Office’s Board of appeals in its 1998 decisions, which drew the line between ‘software as such’, the phrase used by the European Patent Convention, and ‘technical software’. The argument here is that when the Act bans the patenting of ‘software per se’, the use of the term ‘per se’ is meant to indicate a narrow category of software which is ‘simply’ software. When the software has, in the terms used by the judgment, a ‘technical contribution’ or a ‘technical effect’, it is no longer ‘not merely a computer program per se’, and is therefore patentable.

 The present judgement does not delve into what exactly qualifies as a ‘technical contribution’ or a ‘technical effect’ other than the quotes it uses from previous cases such as Alice Corp. and HTC v. Apple. The essential implication of the judgment is that anything that brings a level of technical application to the software and therefore means that the software is not merely software, i.e. not merely restricted to being an abstract list of commands for the computer, but gives it a visible technical consequence, counts as a ‘technical contribution/effect’.

However, it should be noted here that, as Amlan points out in his earlier post, the inclusion of the ‘technical application’ test with regards to the patenting of software has actually already been rejected by the Parliament back in 2004 when they rejected an ordinance that used the words “a computer programme per se other than its technical application to industry or a combination with hardware”. The Draft Guidelines for Examination of Computer Related Inventions (‘CRIs’) that were released by the Indian Patent Office in 2013 make note of the same, though it must be noted here that the guidelines remain as draft guidelines still, and have not been formalised. The Guidelines go on to note a definite hardware-based tilt to the ‘per se’ exception, and advising the examiner to carefully consider how integrated the novel hardware is with the programme. Directly on the point of the ‘per se’, the guidelines state that “if a claim of an invention is oriented towards a novel, inventive and industrially applicable computer or related device along with the programme for defining its functionality, then it may be considered to be patentable.” The focus on the hardware rather than the software itself is unmistakable.  The perspective taken by the Guidelines is therefore narrower, speaking specifically of ‘software’ as it worked with specific hardware.

The intention of the legislature, then, would seem to be to not apply this test in this context. This is the exact opposite of what the judgment does when it states “thus, it […] appears to me prima facie that any invention which has a technical contribution or has a technical effect and is not merely a computer program per se […] and […] is patentable”. It has thus read the ‘technical contribution/effect’ test into the ‘per se’ part of Section 3(k).  In coming to this conclusion, the Court has borrowed from the ‘technical features/character’ doctrine used in the European Union and the ‘significantly more’ doctrine used in the United States, as discussed in the post here. If this is accepted as precedent, it would settle the debate on the interpretation of ‘per se’, which has been contentious for quite a long time, turning on its head quite a few arguments and interpretations. The perspective taken by the Court is far wider than that recommended by the Guidelines, as the Court’s approach is buttressed on the tests of the EU and US, them being more software centric, allowing even pure software patents.

The value of the pronouncement of the Court is debateable – it came in response to one of the arguments that had been raised by Intex against the maintainability of Ericsson’s claims regarding its own patents, and was the reason for its dismissal. And yet, arguably, it is not part of the final ratio of the Court. Thus, it would seem to me that the true weight given to this pronouncement is something only future judgements, and its acceptance as precedent, can tell (if any of the readers have a better idea regarding this, please do let us know your thoughts).

The Problems with Software Patenting

There is a threefold problem with taking such a position. The first is that Software patents encourage more patenting, not more (innovative/useful/novel) software. This can clearly be seen from the history of these provisions in the US and EU. Soon after the patenting of software was allowed, even with restrictions similar to the ones above, there was a massive boom in the number of software patents in both the regions – patents which it later turned out were hardly novel. The first problem then, is the massive potential for abuse for such a provision.

The second problem, which aggravates the first, arises from the ambiguity of the distinction. Setting apart software that is ‘software per se’ from all other types of software is not an easy task. It would require a set of guidelines as to what exactly software needs to accomplish before it achieves a sufficient level of ‘technical effect’, and the judgement does not quite set apart anything to meet this requirement. This is again an issue that the software patents in the US have ruefully had to deal with, and are still dealing with. Furthermore, it opens the doors to a rush from most of the involved parties towards patenting their software before someone else beats them to the punch, and would require the settlement of the contested claims that come up therein, fuelling the boom mentioned earlier.

Finally, and perhaps more crucially, is the problem of innovation. Multiple studies, starting from 1966 up to 2013, indicate that software patents are bad for innovation. On the face of it, the first point mentioned above opens to the door to an immense increase in transaction costs for companies involved in the technology industry, especially start-ups. This is even more crucial for India at this juncture, due to the immense weight the Government seems to be putting behind the Digital India and Make in India initiatives, especially in the context of technology start-ups. In the context of the second point, the barrier that it creates is that of litigation costs, in setting up the guidelines necessary for software patenting, and on top of that are the costs of settling contesting claims. Furthermore, the technology patents arena is already burdened with problems which would only be immensely aggravated due to the patent stacking in software that would necessarily follow. And then you have the costs of dealing with patent trolls!

Furthermore, there is a level of inherent defect in giving 20 year patents on software. The rules that apply to most patentable innovations are not practically directly applicable to software, due to the fact that software tends to have much shorter innovation cycles, making the long and strict protection term unnecessarily arduous. The ‘novelty’ requirement for patents just doesn’t work for software as well as it does for other innovations. Software, as Eric Goldman puts it, gets patented at too high a level of abstraction, resulting in patents which are too broad, and not even actually ‘novel’, as mentioned earlier – and this has been a noted experience in the US. Of the many examples of ‘frivolous’ patents granted, some include the two infamous US patents for upgrading computer software over the internet, and  for buying goods online through the click of a mouse! An Indian example is one we wrote about a few days ago – Facebook’s patent application for Truveo’s webcrawler!

Thus, it appears that the Intex judgement may have opened the doors to a new era of software patenting in India, if not by setting down new law then by codifying and implementing a different and contested interpretation of the existing law. Whether this is a positive step or not is something that only time will be able to tell for sure, but I would argue on the basis of the above, that it is quite clearly not.

Tags: ,

1 thought on “Ericsson v. Intex, part II – The Perils and Pitfalls of Software Patenting”

  1. Interesting and well analyzed article..

    But one thing that has to be seen are the facts of the present case. It would have been even more insightful if you could have given some hint or idea about the nature of the patents Kartik.

    I would assume that the patents being of Ericsson, were something related to telecom networks/mobile phones and in such cases, the patents would have been tested on the anvil of technical contribution/effect test. I am not sure, but there are very high chances that the patents were not those related to those much hated software giants who file the patents even for programs, having probably no other technical effect.

    Further, for being part of the discussions at the Patent Office on the draft guidelines on CRI, I can also recall some very senior members/patent practitioners therein highlighting during the meetings, that the approach of Patent Office wherein novelty in relation to CRI have been equated with ‘novel hardware’ approach was completely irrational and unfounded. A simple example was given by someone wherein it was stated that it would be highly difficult to change the telecom network time and again, rather it would be efficient to improve the existing networks (read existing hardware) by using improved techniques on the same, which may be covered by patents, having ‘technical contribution/effect’ to existing hardware also.

    Still, it will be interesting to see the legal contribution/effect of the present judgment.. as a whole and also on the muddy waters of Section 3(k).

Leave a Comment

Discover more from SpicyIP

Subscribe now to keep reading and get access to the full archive.

Continue reading

Scroll to Top