FSF India's response to the Draft Patents Manual

			 19th August 2008

To

Mr. N. N. Prasad,

 Joint Secretary,

 Ministry of Commerce and Industry,

 Department of Industrial Policy and Promotion

Dear Sir,

Subject: Regarding the Draft Patents Manual

This is presented with reference to the Draft Patents Manual on which your office has invited comments. On behalf of Free Software Foundation of India (http://www.gnu.org.in/), I hereby submit our response and comments pertaining to the relevant sections that refer to computer programs. May I also inform you that our earlier representation along with Knowledge commons submitted to you is also included at the end of the letter.

1. Computer programs (software) is not patentable as per the Clause 3(k) of the Indian Patent Act. This point is clearly stated in the manual. However, Section 4.11 of the Draft Manual makes an attempt to inform the inventors and potential Patent applicants that while software per se is not patentable, software in combination with hardware can be patented. The draft appears to make a room for this possibility. This is important to recollect that an amendment to this effect was suggested in the Presidential Oridinance tabled in the parliament in December 2005, and the house rejected this amendment. Therefore, what the policy of the land rejected cannot be enabled through instructions in a manual, subverting the legal framework already laid. In what follows we demonstrate how the draft manual is enabling this possibility.

2. 4.11.2 does not preclude a computer program embedded in a ROM as what constitutes a computer program. According to 4.11.2 a computer program “may be expressed in various forms e.g., a series of verbal statements, a flowchart, an algorithm, or other coded form and maybe presented in a form suitable for direct entry into a particular computer, or may require transcription into a different format (computer language). It may merely be written on paper or recorded on some machine readable medium such as magnetic tape or disc or optically scanned record, or it maybe permanently recorded in a control store forming part of a computer. ” (4.11.2)

3. It is very important to state that computer program can be encoded in various kinds of digital media including those that are invented as well as those that may in future be invented. E.g. ROM, EPROM or BIOS are also embedded memories where computer programs can be embedded. Mere inclusion of data or computer programs in such chips on the board are also not patentable. Such chips are often present on the board of a digital device should therefore be explicitly mentioned in the manual as one of the forms in which a computer programs can be encoded and hence excluded from patentable invention.

4. Since such a statement is absent in the draft manual, we suggest, it must be explicitly included in 4.11.2. A sample statement that we propose can be as follows:

   A computer program may be encoded or stored in the form of an electronic chip or read only memory (ROM) or in a component that can be embedded as a part of an electronic circuit. Since this is a mere extension of a recordable surface of code over which any digitized data can be stored including a computer program, mere inclusion of a software or data in such electronic chip or ROM will not be considered as a hardware innovation and therefore not allowed.

5. 4.11.3 again indicates that “The source/pseudo/object codes may be incorporated in the description optionally.” When the law clearly states that source code (a computer program), pseudo code (an algorithm) or not patentable, how can an invention be described in that form. 4.11.3 should be removed completely. This point opens up a room for patenting software in combination with hardware or process patents. This should be forbidden, unless the law says that software can be patented in combination with hardware and processes. Since the law does not say so, this makes no sense to tell an inventor to provide code.

6. 4.11.4 is a clarification on what constitutes a prior art, which is done elsewhere in the document. Specifically mentioning this under this section gives a wrong message. Since the objective of the section 3(k) is to exclude what is patentable, and hardware inventions are not excluded under this section and are already covered under techn ical inventions and so do not need a separate mention under this chapter.

7. 4.11.5 mentions that there can be three kinds of computer inventions. Once computer programs are separated out, what remains in the computer is innovations pertaining to electronics and communication. Therefore, talking about them in this context only opens up a room for people to think that patenting software in combination with hardware is possible. First: method or procedure in the context of a computer is nothing but a program which is not patentable. Second: inventing an apparatus or a system is patentable and therefore should not be included in this section. Including in this section only helps inventors to interpret that apparatus or a system in combination with software is patentable.

8. The following statement from 4.11.6 clearly brings out what the draft manual is trying to achieve: “Technical applicability of the software claimed as a process or method claim, is required to be defined in relation with the particular hardware components. Thus, the “software per se” is differentiated from the software having its technical application in the industry is about “technical applicability of the software claimed as a method or a process claim.” Our response to this is already presented to your office in a representation made earlier. Please see the attachment 1. Since we have already placed in detail how this interpretation is not useful is presented in that document in greater detail with references to other countries where such interpretation was attempted. In what follows, we present our concern of how this interpretation can open up a possibility making all software patentable.

9. 4.11.6 is an attempt to explain what can be the interpretation of “per se” in the clause 3(k). If the above interpretation is accepted, it religates software to be a mere expression, for an expression does not have any technical application, except that a human interpreter trained in coding can read and understand. Therefore, what this draft is informing the community is clear. Since, all software can have technical application, when we file for patents we have to spell out the intended application of the software, and if there is a novelty in applying the software, patents can be granted. So, here the innovation is to think of a novel application even if the software per se is not novel. This line of interpretation opens up what 3(k) intends to preclude.

10. The implication is that if a software, let us say an email client, in combination with a special gadget, say some USB pendrive, which in turn can be combined with say a bluetooth communication device, etc., can be claimed for a patent since no such innovation is a prior art. This is absurd, since here each of the three are performing independently of each other and mere combination is not an innovation. This is a mere exploration of making what is possible. One may say that the output of one device becomes an input for the other device. The innovation consists in linking these two devices as one. But this idea of linking input output devices is a known art.

11. By Allowing this interpretation the domain of patentable art increases by several folds. We understand that the wealth of Patent's office enhances as well as a section of the industry due to increasing the domain of patentable inventions. This should not be the objective of the patent's office. The office should on the other hand exclude such mere combinations as an art of the possible and clearly state in the manual that such a combination art is not patentable. This will encourage innovators belonging to small and medium scale industries and young entreprenuers who can perform these combinations and come up with innovations without becoming a victim of the big patent holding corporations.

12. The other danger is that big corporations will hire people to explore all the logical possibilities of these combinations and claim patents on all of them. This should be prevented if the patent office is really interested in encouraging a large number of individuals to enjoy the benefits of science and technology. If people at large do not participate in such combination art, science and technology will not percolate to people at large. People should have the right to implement ideas, and should not be living in a world where there will always be threat that some company will prevent them for their innovations.

13. The terms “software claimed as a process” and “software claimed as a method”, (Cf. 4.11.5 and 4.11.6) are not clearly defined in the law. Therefore, such terms cannot be brought into the manual.

14. Section 4.11.9's interpreation of the law is a very serious threat to a innovating society. A draft manual has no right to bring in such a blatant back door entry of a rejected statement by the house of the country. This kind of amendment was attempted in 2005 through a presidential ordinance, and Parliament rejected it. The patent's office has no right to bring it back without first making an amendment.

15. FSF India, as well as several other organizations, reacted strongly to this proposed amendment. Since the draft manual makes an attempt to reintroduce this possibility by explicitly stating that software in combination with hardware (embedded systems) (Cf.4.11.9) is patentable, it is important to reiterate the arguments, which are as follows:

1. Any software can be embedded into a hardware by using either flash or ROM or some some rule set embedded in the circuit. E.g., a large number of mathematical, graphic and audio manipulations which were at one time performed by software are all currently available as embedded solutions within the integrated boards. Each such integration should not be considered patentable.

2. All hardware that does symbolic manipulations can also be simulated in a software. E.g., if a computer does not have a direct 3D rendering as a part of a VGA card, such computer can perform 3D rendering by using a software library.

3. This clearly indicates that the entire domain of symbolic and data manipulation must be kept completely out of the domain of patentability. That is clearly the wisdom of 3(k) where all the innovations that happen in the domain of symbolic manipulations such as mathematics, algorithms, computer programs are kept out of the domain of patentability.

4. The most important ontological issue here is that there does not exist any software that can be made to work independently of any hardware. Some active media, either hardware or wetware (a living human or intelligent being), is required for performing the symbolic manipulation (executing instructions). Therefore, all software---since all software works only in combination with some hardware---is patentable.

5. Allowing software in combination with hardware multiplies the domain of what is patentable by several folds. The domonstration of this is very simple. Software A in combination with hardware A, hardware B, hardware C etc. are all independently patentable for each of the combination is an innovation according to what the draft manual. The popular demand from the big industry who are supporting this kind of amendment all over the world is therefore clear. What they want is to increase somehow the domain of patentable innovations, so that they can continue to ensure their monopoly. Protecting monopoly is not the objective of the Patent's office, but to encourage innovation as well as enhance the number of innovative citizens. Which cannot happen without giving them an open space to operate.

6. We therefore request that these sections that explicitly encourage innovators to claim “software in combination with hardware” be not only be removed, but explicitly inform the community that they are not patentable. This will encourage innovators to work out the art of the possible and a healthy competitive world will result in this domain since no fear exists among the innovators and even small time innovators could venture. The objective of the patent's office should be not to enhance the domain of patentability, but to limit, since in this case it is very clear that such a provision restricts the participation of community at large to participate in the innovation.

7. In Section 4.11, which is a guide to 3(k), it should be clearly mentioned that “A mathematical or business method or a computer programme per se or algorithms are not patentable” because as such such methods are already protected under the copyright act. Therefore the desirable interpretation of 3(k) should be, computer programs per se are not allowed under patents act and are only allowed under copyright since a computer program per se is nothing but an expression, and expressions are protected under copyright and expressions are not considered patentable innovations. Please also see the recommended interpretation of 3(k) in the attached representation made earlier by the Knowledge Commons in the section 13.

8. Combining an expression (mathematical or computer programs or algorithm) with different variety of hardware is an art of the possible and therefore such a combination art should not considered patentable innovation. All industries small or big should be encouraged to participate in combining them innovatively without any fear of stepping on a 'land mine'.

9. Free(dom) software (popularly known as free and open source software coming out from GNU, Gnome, KDE, Apache, Mozilla, freeBSD, RedHat, Ubuntu, and such projects) is increasingly getting embedded in several embedded (hardware) devices and their usage is increasing by several folds every day. Our community is concerned about the recurring enthusiasm our Patent's office in finding a way to make software related innovations and bring them to allowable category. On behalf of FSF India, a representative of a global community of free software community, requests the office to redo the elaborations of 3(k). FSF India can enthusiastically help in re-drafting this portion if the office gives us a chance. As an important stakeholder of a very large free software community globally, neglecting our serious objections will hinder the industry and community at large to take the full benefit of free software.

10. Considering that the ICT revolution took place without allowing software patents, there is no need for expanding the domain of patentable innovations.

11. Even if other countries made such provisions, India as the world's largest democracy should not create an society where people at large are excluded from participating in creative engagements. As a country with a large human resource, we have a bigger challenge of harnessing more creativity among the country, and that will happen by bringing each and every citizen under creative participation and not by bringing each and every invention under allowable patents category. India should lead the rest of the world by clearly stating in the manual that computer programs are not patentable in India by any other way and are per se protected only under copyright.

12. Practical advantage of not allowing software patents in India will enable Indians to work with those ideas that are otherwise patented elsewhere.

    We therefore appeal the office not to publish the manual without making the suggested modifications.

        Thanking you

        best regards

       
        
        (Nagarjuna G.), Chairperson, Free Software Foundation of India.
Attachment 1. Representation of Knowledge Commons.