Microsoft Technology Licensing, LLC v. Assistant Controller of Patents marks what may be Madras HC’s first authoritative decision on the patentability of a computer program, in this case, involving command surfaces u/s. 3(k). In this post, first, I will discuss the facts constituting the case. Then, I will discuss whether MHC’s understanding aligns or deviates from DHC’s jurisprudence over the last five years. Then, I engage with MHC’s observation that ‘enablement’ is not a relevant inquiry when deciding the patentability of computer program u/s. 3(k). Lastly, I look at the dilution debate surrounding 3(k) and whether the MHC missed an opportunity to course-correct.
Facts
The invention, in this case, was purely software-based (or software-related invention) without any novel hardware. Largely, it sought to resolve the problem of having to use multiple command surfaces to provide instructions to multiple applications on a web surface. It claimed it was difficult to process multiple unrelated applications at the same time without having to create independent command surfaces for each application. As a result, conventional systems were inefficient.
The present invention created a system where a single command surface, through a command manager, is coupled with multiple components, which, in turn, can be used to process multiple unrelated applications with a single command surface.
The Controller rejected the Patent application for lack of inventive step u/s. 2(1)(ja) (no technical advancement) and being computer programme per se u/s. 3(k).
Sticking to DHC’s 3(k) Jurisprudence
Is a ‘computer programme’ patentable? The Delhi HC has grappled with this issue in the past. (here, here, here, here, and here) This blog has also discussed the issue extensively over the years. (here, here, here, and here)
Put briefly, the key observations and findings in these judgements have been-
- Computer programs u/s. 3(k) are qualified with the phrase per se. Therefore, not all inventions based on computer programs are unpatentable. (here) Only a computer program without technical effect, technical feature or technical character by itself is not patentable.
- The words per se are to ensure that genuine inventions based on computer programs are not refused patent protection. (here)
- An invention which is purely software-based without any novel hardware is also patentable. (here)
- On one hand, Lava says that the computer programme, to be patentable, must demonstrate a ‘further technical effect’ that improves the system functionality or efficiency. On the other, Microsoft, the court says that the invention should not only improve the functionality of the system but achieve an ‘innovative’ technical advantage. The exact threshold requirement to surmount 3(k) is thus unclear.
- A computer programme must have practical application i.e. it must produce a technical effect or exhibit technical advancement or an innovative technical advantage (the position is unclear). The technical advancement should satisfy the novelty and non-obviousness requirements. (here and here)
- To determine technical advancement, the Court will see if the computer program provides a technical solution to a technical problem in the field. It will also see if the computer program improves the functionality of the system. (here)
The Madras High Court, in this case, concurred with DHC’s understanding of 3(k).
In Para 36, it notes that a computer program would not be barred u/s. 3(k) if it either provides a technical effect which improves the functionality of the system or provides a technical solution to a technical problem. In other words, it should not be a computer programme without technical advancement.
The Court also refers to various European cases for ‘signposts’ or guidance as to when a computer program is patentable and excluded from 3(k). The DHC has also, on various occasions, referred to European cases for guidance to decide issues arising under 3(k). Was the MHC right in emulating the DHC’s approach here? This is discussed in a bit more detail later in the post.
Largely, the Madras HC does not say anything different from what has already been laid down by the DHC. Except for one thing: The enablement requirement, which I discuss next.
Enablement requirement: Not relevant for 3(k)?
First, the court notes in Para 37 that ‘enablement’ was not a relevant consideration u/s. 3(k). The Patent Office had denied the patent application on the grounds, among others, that the enablement requirement was not met. (Para 10) In short, the enablement requirement requires that the description of the invention must be sufficient for a Person skilled in the art (PSITA) to both make and use the invention.
The CRI guidelines, 2017, under heading 4.4, provide specific ‘signposts’ for Courts while deciding when a CRI meets the enablement requirement. The relevant ones for our purposes are-
- There must be a description of the necessary sequence of steps and information required to perform the invention.
- Best mode of performing the invention along with a specification for implementation of the invention.
The above requirements need to be fulfilled for a CRI to become eligible for patent protection u/s. 3(k). Otherwise, it will be rejected for lack of enablement. It is not enough to show technical advancement or technical effect or contribution to a system, enablement remains a necessary pre-condition for the grant of a patent.
Japanese Patent Office guidelines on CRI provide the enablement requirement for the CRI program under the sub-heading 1.1.1.1. Specifically, it provides that in case the (i) description of the CRI is not provided to the extent that a PSITA cannot carry out the invention; or (ii) the description does not describe how the technical procedures or function of the CRI are to be carried out and PSITA, based on common knowledge, cannot understand the invention, the invention does not satisfy the enablement requirement. In other words, the CRI is not patentable.
Further, the US Patent Office on CRI guidelines (I am not sure if this is the latest version, please do let me know if you find it!), it is clearly stated that the disclosure must satisfy the ‘enablement’ requirement i.e. teach a PSITA how to make and use the invention without any undue experimentation. Otherwise, the invention will be denied patent protection.
The requirement of enablement has important public policy considerations. The Patent bargain refers to a quid pro quo between an inventor and society viz. in exchange for a limited monopoly of the invention, the inventor must fully disclose so the public can benefit from it and expand on it. (here and here) As Swaraj and Praharsh write, this bargain is premised on the theory that the societal cost of allowing a limited monopoly is allowed in the belief that the net benefit to society will be greater in the long term since the invention is disclosed.
To the extent that the Court states that enablement is an irrelevant inquiry u/s. 3(k), I would not disagree. 3(k) merely provides which subject matters are patentable or not. The question of enablement, on the other hand, is a separate inquiry. Enablement seeks to determine whether a particular invention deserves patent protection i.e. eligible for patent protection. The question of whether an invention is sufficiently disclosed or enabled comes later after the subject matter of the invention itself is found patentable.
Section 10(4) of the Act requires the inventor to provide the use and method by which it is to be performed. DHC in Merck Sharp v. Glenmark Pharmaceuticals had noted that a specification u/s. 10(4) should teach what the invention is and the method of making and using it (i.e. enablement)
Considering the Patents Act, policy aspects, CRI guidelines and international practices, it is important to discuss the question of enablement. However, the MHC awarded the patent in the case without discussing enablement at all, brushing it aside as an irrelevant inquiry u/s. 3(k).
The Controller, in its order, had rejected the patent on grounds of lack of enablement, among others, since the invention failed to specify how ‘command surfaces’ would associated/disassociated with a particular component. Considering the technical solution provided by the invention viz. sending commands to multiple applications by a single command surface using corresponding components, if the invention fails to specify how the invention is implemented, it fails the enablement requirements.
Therefore, the Court should have looked into the merits of the enablement argument u/s. 10(4) rather than doing away with it as an irrelevant inquiry u/s. 3(k).
Dilution of 3(k): A missed opportunity?
There have been debates about the ‘dilution’ of 3(k) by the Courts for allowing software-based inventions to be patented.
On one hand, it is argued, that software-based inventions, which do not work in combination with hardware, are patentable i.e. not excluded u/s. 3(k). Prathiba M. Singh, in Prathiba M. Singh on Patents, writes that 3(k) needs to be read in a restrictive manner or otherwise, “it will render any innovation in the digital space non-patentable.” Relying on the JPC report, she argues that “any invention which satisfies the test of patentability cannot be rejected merely because they are based on computer programs or software.” In her view, the words per se were inserted to bring the Indian position on computer programs in line with the international position i.e. CRI which has technical contribution or technical effect are patentable. On Patent (Amendment) Ordinance, 2004 (later repealed), which said “computer programme per se other than its technical application to industry or a combination with hardware” were excluded u/s. 3(k), she argues that the same would not have changed the scope of 3(k). Rather, it would continue to have the same meaning i.e. CRI with technical effect and technical contribution are patentable.
On the other, it is argued that allowing CRI, which is completely based on software, dilutes sec. 3(k). For instance, these posts on the blog (here, here and here) argue that the Patent (Amendment) Ordinance, 2004 had sought to dilute the provisions of 3(k). Relying on the text, it is argued that the Ordinance intended to provide patent protection to software-based inventions, which had no novel hardware but technical application to industry. Clearly, the ordinance diluted the threshold for patent eligibility of CRI by allowing even software-based inventions to be patented. However, this ordinance was later repealed by the Patent (Amendment) Act, 2005. The repeal of the ordinance, the argument goes, presents a clear intention that the Parliament was against the dilution of sec. 3(k).
Nevertheless, subsequent CRI guidelines of the Patent Office (here) have narrowed sec. 3(k) by allowing software-based inventions to be patented without any requirement of hardware.
Personally, it is a question of lack of clarity. The Courts have relied upon international jurisprudence (albeit rendered in different legislative contexts) to argue that per se in sec. 3(k) means that abstract computer programs are unpatentable but software-based inventions are patentable. A narrow reading of 3(k), in their view, promotes innovation and the digital industry by excluding very few computer program-based inventions.
Critics of the approach rely upon legislative history and debates to argue that patents for computer programme dilute 3(k) despite clear language. In their view, a narrow reading of 3(k) disincentivises creativity and innovation since even non-patent-worthy software(under a strict reading of 3(k)) is made patent-eligible. Thus software which could otherwise be in the public domain for tools for further (genuine, patentable) innovation, is instead monopolised.
We must remind ourselves why computer programs were excluded from patent protection. Brad Sherman, in this paper, provides that computer programs were considered abstract algorithms which had no practical useful outcomes. The idea was that patents should not granted for inventions which do not provide practical tangible outcomes.
The author distinguishes between, on the one hand, computer programs, and on the other, inventions which use computer programs. While the former may be abstract without practical application, the latter merely utilises an excluded subject matter to provide practical or technical application. The important principle is that one should look at the invention as a whole and determine- whether is it a mere abstract idea or does it have useful practical application. If it is the latter, it should be patentable. I agree with this approach since it balances innovation on one hand and prevents people from monopolising abstract ideas.
In this sea of unclarity, what MHC could or should have done is anyone’s guess. At least, until the Parliament steps in to clarify. Readers’ thoughts are welcome!