Indian patent law treats software differently from the US. Section 3(k) of the Patents Act, 1970 excludes ‘a mathematical or business method or a computer programme per se or algorithms’ from patentability. The two words that decide every software patent application in India are per se — and the Delhi High Court’s reading of those two words in Ferid Allani v. Union of India (2019) reset the landscape.
This piece walks through what is and is not patentable software in India, what the Ferid Allani guidelines actually said, and how Indian patent offices examine software claims today.
What Section 3(k) excludes
The full text excludes four categories:
- A mathematical method
- A business method
- A computer programme per se
- Algorithms
The Patent Office’s Computer Related Inventions (CRI) Guidelines, last revised in 2017, originally read Section 3(k) very strictly — almost any software-implemented invention was rejected. The Ferid Allani matter challenged this strict reading.
Ferid Allani — the line that reopened software patentability
In Ferid Allani v. Union of India (Delhi High Court, 2019), the court ordered the Patent Office to re-examine a refused application and emphasised that the term per se in Section 3(k) was deliberately chosen by the legislature. The court held that not every computer programme is excluded — only those that are programmes as such, without any additional technical contribution.
The court’s reasoning: if a computer programme demonstrates a ‘technical effect’ or ‘technical contribution’, it crosses the Section 3(k) bar and becomes patentable subject matter. The technical effect must be something more than the routine functioning of the program as a program — it must be a genuine improvement in how the computer or some external technical system operates.
A program by itself is not patentable. A program that makes the machine do something genuinely new is.
What ‘technical effect’ means in practice
Indian Patent Office examiners now apply a workable list of factors after Ferid Allani:
- Hardware improvement — does the software make hardware operate more efficiently, faster, with lower power consumption?
- System architecture — does it introduce a novel arrangement of computing systems (distributed processing, novel memory management, novel communication protocols)?
- Physical-world effect — does the software produce a measurable physical effect (e.g., controlling a manufacturing process, IoT sensor calibration, real-time vehicle steering)?
- Technical problem solved — does the software solve a problem characterised in technical terms, rather than business or administrative terms?
If at least one of these is present and demonstrated in the patent specification, the application has a reasonable shot at clearing Section 3(k). If the invention is purely a better dashboard, smarter workflow or improved business logic, Section 3(k) will refuse it.
What is typically rejected
- SaaS workflow improvements with no hardware effect
- Better UI/UX
- Business-method automation (online shopping checkout, payment routing logic, marketing automation)
- Mathematical algorithms without technical application
- Methods of doing business implemented in software
- Generic data-processing improvements
What has been allowed
- Hardware-accelerated cryptographic processing
- Novel ML model architectures tied to specific hardware behaviour
- Communication protocols with measurable bandwidth or latency improvements
- Image-processing methods producing genuine technical effects
- Control systems for physical processes (robotics, manufacturing, IoT)
- Distributed system primitives with novel consistency or fault-tolerance properties
Have a genuinely novel software invention? A patentability search before filing tells you in 5-10 days whether the invention clears Section 3(k) and the prior-art bar.
Request patentability search →The CRI Guidelines — current status
The 2017 Computer Related Inventions Guidelines remain the official guidance for examiners. They were revised after Ferid Allani to reflect the ‘technical effect’ analysis, but they still tilt towards refusal in close cases. Practitioner experience suggests that strong technical-effect framing and clear specification of the hardware or physical effect material improves the odds substantially.
How India compares to the US and Europe
- US — broader software patentability under 35 USC 101, after Alice/CLS Bank tightening. Methods with abstract-idea characterisation are still rejected. Business methods continue to face high bar.
- Europe — explicit technical-character requirement under Article 52 EPC. Indian Section 3(k) reading after Ferid Allani is closest to the European framework.
- India — strict Section 3(k) bar, opened by Ferid Allani technical-effect framing. Closer to Europe than to the US.
The takeaway
Software is not unpatentable in India. Software per se is. The line is technical effect — a genuine improvement in how a computing system or hardware behaves, measurable and characterisable beyond the routine running of code. Most Indian SaaS innovations are pure business-method or workflow improvements and will not clear the bar. Genuinely novel system architectures, hardware-tied algorithms, and physical-effect software increasingly do. A patentability search and a technical-effect mapping before filing is the cheapest way to find out which side of the line your invention sits on.
Your brand is only yours when you file it.
10,000+ Indian brands filed with IPForte. 48-hour turnaround. 130+ countries via Madrid Protocol. First call is free, no commitment.