Patent

Revisiting – patentability of computer programs and Section 3(k), a different perspective


544580_501330909883958_1986446066_n

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).

OSI Model

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’.

Rajiv Kr. Choudhry

Rajiv Kr. Choudhry

Rajiv did his engineering from Nagpur University in 2000 in electronics design technology. He has completed his LL.B. from Delhi University, Law Center II in 2006, while working as an engineer at ST Microelectronics in NOIDA. After his LL.B., he went on to The George Washington Univeristy, Washington DC to do his LL.M. in 2007. After his LL.M., he has worked in the US at a prestigious IP law firm based out of Philadelphia. Till 2014, he was Of-Counsel to a Noida based IP law firm where he specialized in advising clients on wireless, telecommunication, and high technology. Rajiv is a co-founder of RHA Legal, a New Delhi based law firm specializing in IP law, with a focus on high - technology, and patent law. His core IP interest areas are the intersection of technology and IP, Indian IP policy, innovation, and telecommunications patents. He is also an inventor with pending applications in machine-to-machine communications domain (WO2015029061).

One comment.

  1. AvatarMurti

    Congratulations to Rajiv for the excellent clarity given by him to this ‘confusing’ topic. As one with a background in IT and Law, I very much appreciate his vital Contribution.

    Earlier my answer to ‘Software patentability’ while addressing a non-tech, law oriented audience is that: Embedded Systems which use Software to drive some hardware ‘as a whole’ are patentable while the ‘Software, per se, cannot be patented’. My emphasis was that Software cannot receive a Patent in a stand-alone basis but it should go along with the hardware it drives.

    Rajiv’s apt example is with reference to Network Communications which I fully appreciate (and request his permission to use this example from now on to my audience!). I request his comments to the example of ’embedded systems’ I have cited infra.

    Best regards to an expert in this Subject

    Dr. Poolla R.K. Murti
    M.Tech. Ph.D. M.B.A. LL.M. Ph.D. (Law)
    Dean R&D, http://www.jits.in

    Reply

Leave a Reply

Your email address will not be published.