Rejected under Section 3(k)? Your software invention may not be dead.
The examiner says ‘computer programme per se’. Most founders read that as a full stop. It is usually a comma. Here is what Indian examiners actually want to see.
Software as such cannot be patented in India, but an invention that uses software to produce a technical effect, such as faster processing, lower power use, better security or more accurate control of a machine, often can. The fix is usually in how the claims and specification are written, not in the invention itself.
The email arrives on a Tuesday. Your First Examination Report lists a dozen objections, and the one in bold says your invention is a ‘computer programme per se’ and therefore not an invention under Section 3(k) of the Patents Act. For a software company, that sentence reads like a verdict. It rarely is.
What Section 3(k) actually excludes
Section 3(k) excludes mathematical and business methods, computer programmes per se and algorithms. The two words doing the heavy lifting are ‘per se’. Code on its own, a pure algorithm, or a new way of running a business process cannot be patented. But Indian courts have said clearly that an invention is not excluded just because software is involved.
The Delhi High Court's 2019 decision in Ferid Allani v. Union of India is the one to know. The court held that inventions based on computer programmes can be patentable where they show a technical effect or technical contribution. The Patent Office's guidelines on computer-related inventions follow the same line.
What a technical effect looks like
Examiners are looking for a real-world improvement that goes beyond the code. Faster processing, reduced memory use, lower energy consumption, stronger security of a system, more accurate control of a physical device, or better communication between machines are common examples. ‘It makes life easier for users’ or ‘it saves the business money’ usually is not.
Here is a useful test. Explain the invention to an electrical engineer who does not care about your market. If what excites them is how the system works better, you probably have a technical effect. If they shrug and call it a clever workflow, you may have a business method.
How to respond to the objection
Recast the claims so they describe the system, not the steps a user takes. Name the hardware, the data flow between components and the specific technical problem solved. Point the examiner to the passages in your specification that describe the technical effect, with benchmarks if you have them. You cannot add new matter at this stage, so everything must already be supported by what you filed.
If the objection stands, request a hearing. A good number of software applications in India are granted after a hearing where the applicant simply walks the Controller through the technical contribution in plain language, diagram by diagram.
If you have not filed yet
Write the specification with Section 3(k) in mind from the first draft. Describe the technical problem before the commercial one. Include system architecture diagrams, not just flowcharts. Record performance data. The best answer to a 3(k) objection is a specification that has already answered it.
And if the honest answer is that your edge lives in the workflow rather than the machine, keep it as a trade secret and rely on copyright for the code. Not every advantage has to be a patent to be worth protecting.