This post is in continuation to the previous post informing our readers about the new CRI guidelines. And it was necessitated because of the serious debate triggered as evinced by the several comments on the previous post. This post will provide more details on how patents relating to software are being interpreted by courts / juries in the US, and some examples from Europe are also being provided.
However, before I get into the same, I must acknowledge the stellar role played by the Software Freedom Law Center in following up on this issue with the Controller’s office and the DIPP. It is because of the sincere efforts of the SFLC, and other members in civil society in pursuing this matter with DEITY, DIPP and other government departments that these guidelines have come across. For more details see, SFLC’s site here and here.
In the previous post, I had referenced a few US cases – These included the seminal Alice Corp. case holding that “specific hardware” consisting of a “data processing unit,” a “communications controller,” and a “data storage unit” were “purely functional and generic”. We then had Microstrategy holding that claims reciting “data storage devices,” “an intelligence server,” “an object server,” “a query engine,” and “an analytical engine” covered generic computer functions. Similarly, Intellectual Ventures I LLC held as “generic” a “telephone, pager, PDA, or the like,” a “pager network,” and a “cellular network”, etc. If I were to summarize these decisions – I would say that inclusion of generic hardware elements, does not confer patentability on software using such hardware.
In all the examples pointed out in the new CRI Guidelines, I see similar logic. Generic hardware has been used but there is nothing novel or inventive in putting together known elements to come up with a new result. Standard elements have been used as defined under the Von Neumann Architecture (Input | Processing Unit & Memory | Output ) – computers, desktops, palmtops, or smartphones. Put simply, just because a machine does it, does not mean it is patentable. A new generation processor is guaranteed to be faster than a previous generation processor. However, that is because the hardware is boosted significantly – what is the role of software in increasing the performance. Viewed from the lens of statute (other than computer programme per se), the machine should benefit from this new software – for software to be patentable (i.e. it should have something extra).
Can Alice be applied to the examples given in the CRI guidelines: Under example 1, computing a compatibility score (whether done by a computer or by hand) has no benefit to the machine (generic machine is used). In example 3, just because sorting manually takes time, does not mean that if a computer does sorting faster, the software is patentable. Similarly, for example 4. In example 5, it is same old hardware determining pension benefits. Similarly, examples 6 – 13, and 15 do not have anything extra other than generic hardware to implement the software, and hence they too fall under Alice.
Example 14: Some of the comments specifically addressed MPEG codecs case – I must make it clear that the following is my academic viewpoint only. I understand encoders / decoders to be related to compression and decompression of data – i.e. they help approximate data by building numerical models having a best fit for the data. Hence the obvious “advantage to the machine” is that by using the compression / decompression technique, it uses or has to read less data. With this, let us analyze the claim (I find it easy to read a claim – if I parse it completely):
| A method of determining, |
| from transform coded data, |
| an inverse transform to generate |
| a number of bits required to represent an output value |
| which would be obtained as a result of an inverse transform |
| being performed on said transform coded data, said method comprising the steps of: |
| obtaining, at an MPEG decoder, |
| a sum of coefficient values within said transform coded data (204); |
| comparing, in the MPEG decoder, this sum to a pre-determined threshold value (206); |
| deciding, in the MPEG decoder, as a consequence of said comparison which inverse transform implementation, selected from an 8 bit inverse transform implementation, |
| and a 9 bit inverse transform implementation, should be performed when decoding said transform coded data; and performing in the MPEG decoder on the transform coded data, the decided inverse transform. |
This particular claim computes the number of bits required to represent an output value, and where such number of bits required are computed according to a set of instructions. This claim too uses generic hardware to implement known functions (Fourier Transform, etc.), and hence this too may fail under the Alice framework. There is also no benefit to the machine here.
The Per Se test:
In my view, the language in Section 3(k) is clear – that computer programmes per se are not patentable. So is the corollary – what is per se not a computer programme should be patentable. In one of my previous post, I had mentioned that “[I]n Europe, a computer program is software ‘per se’ because there may be no transformation of data/signal/input, or there is no tangible benefit to the device if this software is run on the device. The benefit to the device may be in terms of efficiency, or increase/decrease in certain attributes.”
To understand this efficiency proposition – consider that a motor running at certain maximum RPM, Rmaxi. As an inventor, you make a “software” that sits in between the power source, and runs on with a processor, which renders the Rmaxi to be Rmaxii (Rmaxii > Rmaxi). In my view, this software (obviously it will run on the processor and not the motor directly) is patentable.
Take another example, you have a great Amplifier at home. As an inventor, you invent a software that makes the circuits function such that the resultant power is 1.00001 times than without your software. This too is patentable.
Take another example, as inventor you have invented a software + hardware module that sits in between a vehicles engine, and is also connected to the braking system, as well as infotainment unit. If all that your module does is provide the infotainment unit precise information about the engine, then in my view it is not patentable. You may ask why – well all previous generation vehicles had all sorts of mechanical guages to inform the driver – all that you did was take out the mechanical guage, and replace it with a LCD display. However, if you module captures the information and somehow increases efficiency of the vehicle in manner, it is patentable.
Finally, some comments mentioned that negative definitions do not help. I don’t agree. I see the logic behind the negative examples, and it is similar logic.
I thank all our readers who by their incisive comments have encouraged in putting up this post. I believe, I can say this for the entire Spicyip team, that readers comments keep us on our toes, and encourage us to bring more clarity in our posts! Thank you!!