Revisiting Patentability of Computer Programs and Section 3(k): A Different Perspective

This post continues from my previous (academic) posts on the topic re patentability of software, and provides an academic reasoning of what constitutes software / computer programme per se. The reason why I am limiting the issue only to the term software per se is because of the recent discussions draft guidelines issued by our Patent Office on the topic, and the subsequent discussions on the same.  

As we know that the term per se did not come into the act directly.  It came in on the recommendation of the Joint Parliamentary Committee (“JPC”). The JPC inserted the term to address the patentability of inventions relating to computer programs that may include certain other things that were ‘ancillary thereto’ or ‘developed thereon’.  Accordingly, if computer programs per se are not patentable, something that is ancillary thereto or developed thereon is patentable.

The picture that develops is that although the legislature never intended to prohibit software inventions but only the underlying computer programs or algorithms, the language used leaves much to be desired.  The clarifications re patentability of inventions relating to computer programs were left to things ‘ancillary thereto’ or ‘developed thereon’ and obfuscate the issue even further.

I believe that “ancillary thereto or developed thereon” be read with appropriate language so as to be assist the query whether the software under question is patentable.

Let me explain more: In a paper titled, Implementing Communication Protocols Using Object-Oriented Techniques by Lavender, Kafura, and Tomlinson describe the open system interconnect model: The diagram on the left side of Figure 1 illustrates the basic Reference Model as it is commonly represented. The diagram serves only to illustrate a partitioning of the functional layers into upper layers and lower layers. The primary purpose of the upper layers is to impose structure onto an otherwise unstructured transport service. The primary function of the lower layers is to provide end-to-end delivery of data, subject to quality of service requirements (e.g., reliable connection-oriented or unreliable connection-less delivery). The distinction is relevant from the perspective that the lower layers are commonly implemented in the operating system and hardware while the upper layers are not.(Emphasis added).

This model of upper and lower layers, ancillary / developed thereon, read with the terms ancillary thereto or developed thereon may help in answering the query.

For example, we can instinctively tell that an email program is not patentable but a method of routing / path determination may be patentable, depending on all other conditions of patentability being fulfilled.

In other terms, the closer one gets to hardware (lower layers), the closer one gets to patentability.  Connecting this to ancillary thereto or developed thereon, software may be patentable if it is related to the functioning of the Physical layer – Transport layers.  However, if the software relates to upper layers, Application, Presentation layers, it may not be so.  The position with respect to Session layer may not be as clear as it is the interface between Application / Presentation layers with that of the Transport layer.

I finally end with the caveat that this is my personal perspective and an attempt to the connect the dots relating to the terms ‘software per se, ancillary thereto or developed thereon’.