The Indian patent office has published a revised draft manual on 04 November 2010. This manual is a revised version of the previous draft manual published in 2008. It is in this context that we revisit the requirements for patentability of software.
Draft Manual, 2008:
Section 3 of the Indian patent act provides exclusions covering the subject matter that is not patentable. One of the exclusions is software per se (under section 3(k)). The draft manual published in 2008 had provided clarifications and provided circumstances under which an invention directed towards software may be patentable.
Crystallizing the clarifications and circumstances under which a software invention may be patentable, it can be said that software inventions are patentable under certain conditions. The conditions are as follows:
1. Claims must not be directed to software per se. Invention must be claimed “appropriately”.
2. There must exist machine (or hardware) limitation to the claims directed a method enabled by a software.
3. There must exist “technical effect”.
Condition 1 was the least ambiguous of all. It simply meant that claims must not be directed to “software” as the subject matter. In other words, a claim as the following will be rejected straight away:
x. A computer program adapted to perform..
Condition 2 was somewhat ambiguous. It meant that, a software method claim must recite specific machine limitations so as to make the method specific to the hardware. However, it was not clear whether the machine must be a specific machine or whether a general purpose machine (like a PC) would suffice to satisfy the condition.
Condition 3 was the most ambiguous. Conceptually, technical effect requirement stems out of the “inventive step” requirement (section 2(1)(ja)) as inventive step is defined as as feature of an invention that involves technical advancement. In hardware machine (like mechanical machines) based inventions, technical effect is there is for us see and feel. However, in the context of software inventions, it was not clear on what would be enough “technical advancement”. For example, would automating an existing process have enough technical advancement for it to satisfy “technical effect” requirement? Other than providing obvious examples, the 2008 draft manual did not delve deep enough to provide insights on what would be considered as “technical effect”. Also, software by its nature is technical and makes machines (computers) work differently based on its instructions. Therefore, the term “technical effect” was never clearly understood in the context of software.
Since the 2008 draft manual was released, I have always interpreted the technical effect requirement using an example (based on Vicom/Computer-related invention [1987] 1 OJEPO 14 (T208/84)) given in the 2008 draft manual in the context of mathematical methods. I quote the example hereunder:
..claims to a method of image processing which used the mathematical method to operate on numbers representing an image can be allowed. The reasoning was that the image processing performed was a technical (i.e. non- excluded) process which related to technical quality of the image and that a claim directed to a technical process in which the method used does not seek protection for the mathematical method as such. Therefore the allowable claims as such went beyond a mathematical method.
The language used in the aforementioned example suggests that enhancing image quality through a software on a general purpose computer may be considered to have enough “technical effect” for it to be patentable. It is also reasonable for one to imagine that as long as a software (whether based on a mathematical method or not) provided a technical effect, even adding general purpose machine based limitations to claims would satisfy condition 2.
Revised draft manual, 2010:
The revised draft manual has simplified the guidelines for practice and procedure in relation to section 3(k).
Let us consider the three conditions for software patentability. The revised draft manual reiterates condition 1. Hence, there is no ambiguity with respect to condition 1.
Now, with respect to condition 2, the revised draft manual has given a clarification. The clarification is almost on the face and leaves no scope for ambiguity this time. The manual states that “A computer programme which may work on any general purpose known computer does not meet the requirement of patentability”. Now, this may also be a case of over simplification, and a stricter interpretation even compared to the act. The act says that “computer program per se” is not patentable. I say that because going by this standard no invention based on a software that would run on a PC would be patentable. While such a strict interpretation of the law may help the patent office in rejecting business method claims morphed as method claims involving technical elements, it may deny eligible and patent worthy inventions their due. Let us consider the example of an important telecom software that does say packet routing based on quality of service. In the context of a telecom system, such a software may enable useful things like better bandwidth utilization and so on. And such a software can possibly run on a general purpose computer. In view of the new revised manual draft, such a software cannot be patented simply because there is no specific machine. Thus, in effect, the revised guidelines suggest that any software on the application layer of a computer may not be patentable.
Regarding condition 3, as in 2008 draft manual, there is no specific clarification provided. Given the clarification for condition 2, I believe no specific clarification may be required for condition 3. I say that because, according to the revised draft manual, every software invention must be claimed in relation to a new or a specific machine. Such an invention would almost always result in a new machine, and there by providing sufficient technical advancement.
In conclusion, the simplification of guidelines may have resulted in over simplification of the requirements for software patentability. Such over simplification may put our software industry in a disadvantageous position, and may defeat the purpose of the patent system itself.
By, Arun K Narasani, CEO.
