Can Software and AI Be Patented in India? Section 3(k) in Plain Language

On 30 August 2024 the Delhi High Court decided two BlackBerry appeals. Both concerned software. Both turned on Section 3(k) of the Patents Act, 1970. One was dismissed; the other was allowed.

The invention that lost was a method of resolving conflicts between wireless configuration servers — the Court found it ran on conditional logic, an algorithm with no substantial change to the hardware. The one that won automatically managed media files across device storage, and the Court accepted it produced a technical effect on the machine itself.

That is Indian software patent law in a single day's cause list. No blanket ban, no open door. What decides your application is what your invention does to a machine or a process — and whether your specification said so on the day you filed.

Quick answer

Software is not banned from patenting in India. Section 3(k) excludes "a mathematical or business method or a computer programme per se or algorithms" — four separate exclusions, not one.

A computer-implemented invention can be granted if it delivers a technical effect beyond the ordinary running of a program: faster processing, lower memory or storage use, better throughput or latency, improved security, or control of an external device or physical process. That is the test the High Courts have applied since Ferid Allani (2019), and the one written into the Patent Office's CRI Guidelines, 2025.

Two things it will not save. Business methods are excluded absolutely — "per se" does not attach to that limb. And an AI cannot be named as inventor: the Indian Patent Office has refused the DABUS application, and that refusal is under appeal before the Delhi High Court.

Four exclusions, not one

Section 3 lists what are "not inventions within the meaning of this Act". Clause (k) reads: "a mathematical or business method or a computer programme per se or algorithms".

Most published commentary treats that as a single software exclusion. It is four different exclusions, and only one of them is softened.

Two neighbouring clauses matter as much in practice. Section 3(m) excludes "a mere scheme or rule or method of performing mental act or method of playing game"; Section 3(n) excludes "a presentation of information". Examiners often raise all three against the same claim set, and each needs its own answer.

The practical point on Section 3(m) is that a method does not become "a mere scheme or rule or method of performing mental act" simply because a computer carries it out. Where the objection is really about software, the analysis belongs under Section 3(k), and a reply should say so rather than arguing all three clauses at once. For the wider list of exclusions, see what can be patented in India.

Why "per se" is the most important phrase here

Those two words were not in the original Bill. They were added deliberately, and the reason was recorded.

The Patents (Second Amendment) Bill, 1999 proposed excluding "a mathematical or business method or a computer programme or algorithms" — no qualifier. The Joint Committee of Parliament reported in December 2001 and explained the change it recommended:

"In the new proposed clause (k) the words 'per se' have been inserted. This change has been proposed because sometimes the computer programme may include certain other things, ancillary thereto or developed thereon. The intention here is not to reject them for grant of patent if they are inventions. However, the computer programmes as such are not intended to be granted patent."

Parliament enacted that through the Patents (Amendment) Act, 2002. It is the strongest evidence of legislative intent available, and it points one way: a narrow exclusion, not a total one.

There is a second episode, and honest advice includes it because it cuts the other way. The Patents (Amendment) Ordinance, 2004 would have widened the position, excluding only a computer programme other than its technical application to industry or a combination with hardware. The Ordinance lapsed, and the Patents (Amendment) Act, 2005 restored the 2002 wording.

So Parliament meant the exclusion to be narrow — and also declined, when squarely offered the chance, to write "technical application to industry" into the statute. Every Section 3(k) argument is fought in that gap.

What governs examination today: the CRI Guidelines, 2025

Your examiner starts not from case law but from the Guidelines for Examination of Computer Related Inventions — a document with a turbulent history.

The 2025 edition is a different animal: a chapter on CRI case law, flowcharts, roughly sixty worked examples, and a new Section 5 on AI, machine learning, deep learning, blockchain and quantum computing. Its most useful feature is that it stops treating Section 3(k) as one question — each limb gets its own assessment. The computer-programme test runs in four moves: construe the substance of the claim and identify its essential technical features; identify the core problem and the solution; ask whether the solution is technical; and ask whether that technicality produces a technical effect beyond a mere incidental effect. On "per se" the Guidelines are explicit — the suffix "means that the legislative intent for the exclusion under section 3(k) is not absolute with regard to all computer programme led inventions."

One caution. The Guidelines say they "do not constitute rule making", and that in any conflict the Act and Rules "will prevail over these guidelines". They bind nobody in court. They do tell you exactly what your examiner has been trained to look for — which is why they are worth reading before you draft, not after the objection arrives.

The technical effect test, as the courts apply it

The courts have settled more of this than the guidelines have, and the line of authority is short enough to know properly.

Notice how many the applicant lost. The refusals carry the drafting lessons.

The clearest short statement of the standard is one the Patent Office itself adopts, quoting the Delhi High Court in Ab Initio Technology LLC in the 2025 Guidelines: "'Technical effect' is the bridge or the connect between an input and the processor."

Accepted in practice: faster processing, reduced memory or disk access, less storage during processing, better compression, higher network throughput, lower latency, improved security, control of an external device or physical process.

Not accepted: organising information more conveniently, presenting it better, automating a commercial workflow, or an economic saving that is not also a machine-level improvement. The Guidelines call that the difference between a technical effect and a "mere incidental effect", and it decides most cases.

Business methods: the limb with no escape hatch

This is what fintech and marketplace founders discover too late. "Per se" qualifies computer programmes. It does not qualify business methods. In OpenTV, Justice Prathiba M. Singh held that the drafting difference is deliberate and decisive, and the 2025 Guidelines adopt the holding verbatim:

"The bar in India to grant of business method patents has to be read as an absolute bar without analysing issues relating to technical effect, implementation, technical advancement or technical contribution."

If you build payments, lending, insurance, logistics or marketplace software, read that twice. Once the Controller concludes the substance of your claim is a business method, the technical-effect argument that rescues a computer-programme claim is simply unavailable.

OpenTV's application covered a system and method to gift media content, argued on a two-way network architecture. The Court held that known components adapted to enable the giving of a gift remained a business method however the claim was labelled. Justice Singh directed that the judgment go to DPIIT for policy consideration, but applied the statute as it stands. As on 20 August 2026, nothing has changed.

Vocabulary is not the lever either way. The Guidelines warn examiners that the "mere presence of the words such as 'enterprise', 'business', 'business rules', 'supply-chain', 'order', 'sales', 'transactions', 'commerce', 'payment'" does not by itself decide the question. Substance is assessed, not diction.

What helps is finding the genuine machine-level problem inside the product. A payments company rarely has a patentable "method of settling merchant payouts faster". It may well have a patentable method of cutting message round-trips in distributed settlement reconciliation. The commercial outcome is a consequence of the invention, not the invention itself.

How claims get drafted around Section 3(k)

Three rules do most of the work, and the third is the one that costs people patents.

Substance beats form. The Guidelines put it plainly: "the focus should be on the underlying substance of the invention, not the particular form in which it is claimed". Excluded subject matter drafted as a method, an apparatus or a computer-readable medium is still excluded.

But file more than one claim format anyway. A persistent myth says only system claims survive Section 3(k). The Guidelines contradict it: "section 3(k) does not limit that only system or only method claims are to be granted". Method claims are what you enforce against a service operator, system claims against a device maker. On means-plus-function language the Guidelines are strict — such claims "shall not be allowed if the structural features of those means are not disclosed in the specification".

The technical problem and the technical solution must be in the specification as filed. Section 59(1) permits amendment only "by way of disclaimer, correction or explanation" and forbids an amended specification from describing matter "not in substance disclosed" before amendment. If your specification describes a fintech product and your First Examination Report says "business method", you cannot then add the latency measurements or architectural explanation that would have answered it. Section 10(4) compounds the point: the specification must "fully and particularly describe the invention and its operation or use and the method by which it is to be performed".

An illustrative contrast. These are hypothetical, written to show framing.

The second framing is not spin: it requires that your engineers know where the bottleneck was and can say what changed. If nobody can answer "what does this do to the machine that the previous approach did not", there may be no patent here.

AI, question one: is an AI-implemented invention patentable?

In principle yes — the same Section 3(k) question as any other CRI, plus a disclosure question that is genuinely harder for AI.

Section 5 of the 2025 Guidelines covers AI, ML, deep learning, blockchain and quantum computing. Practitioner analysis of that chapter indicates the Patent Office expects an AI specification to explain the logic transforming input into output, the correlation between input and output data for a trained model, any pre-processing, and the network structure including activation functions and learning mechanisms. A claim to "an AI model that predicts X", with the model as a black box, invites both a Section 3(k) objection and a sufficiency objection.

The sufficiency point is the underrated one. Section 10(4) requires full and particular description and the best method of performing the invention. For a trained model the fair question is whether anyone could reproduce it without the training data and learned weights — and Indian law offers no deposit mechanism for model artefacts.

The Madras High Court has already fired both barrels. In Caleb Suresh Motupalli v. Controller of Patents (C.M.A.(PT) No. 2 of 2024, Justice Senthilkumar Ramamoorthy, 29 January 2025) an appeal concerning a device integrating human cognition with AI was dismissed. The refusal rested on Section 3(k) — the claimed invention showed no technical effect on the hardware — and, just as damagingly, on disclosure: Section 10(4)(a) because the specification did not enable a skilled person to work the invention without undue experimentation, Section 10(4)(b) because it gave no workable criteria for achieving the promised result, and Section 10(5) because the claims were long, vague and not fairly based on the specification. Sections 3(b) and 3(m) were raised too.

An Indian AI patent is won in the specification, months before anyone reads a claim.

AI, question two: can an AI be the inventor?

A separate question, and the Indian answer today is no.

Stephen Thaler's application naming his DABUS system as inventor (202017019068, filed 5 May 2020) was refused by the Indian Patent Office in 2026, on the footing that an AI system cannot be the "true and first inventor". Reports indicate the refusal rested on a second, independent ground as well — want of inventive step — which matters, because it means the inventorship question may not be strictly necessary to the outcome.

Section 6 confines the right to apply to the true and first inventor, an assignee, or a legal representative. Section 2(1)(y) defines "true and first inventor" only negatively — it "does not include either the first importer of an invention into India, or a person to whom an invention is first communicated from outside India". That is the gap Thaler exploits: the Act nowhere states that an inventor must be human. The counter is that Sections 6, 7 and 10 assume throughout a legal person capable of declaring, assigning and being bound.

The question is live: Thaler's appeal is pending before Justice Jyoti Singh of the Delhi High Court, which as reported on 30 July 2026 has sought the Patent Office's response. A separate Thaler copyright matter produced a Delhi High Court order, reported on 9 April 2026, directing the Copyright Office to decide his AI-generated artwork application within eight weeks — without ruling on the merits of whether AI-generated work can be registered at all.

India is not an outlier. The UK Supreme Court held in Thaler v. Comptroller-General [2023] UKSC 49 (20 December 2023) that an inventor must be a natural person; the EPO refused the DABUS applications on the ground that a designated inventor must have legal capacity; and the US Court of Appeals for the Federal Circuit reached the same conclusion in 2022, with the Supreme Court declining review. South Africa granted a DABUS patent in 2021, but it does not substantively examine applications — an administrative outlier rather than a contrary holding.

Could India change? The Parliamentary Standing Committee on Commerce recommended in its 161st report (23 July 2021) that the Patents Act and Copyright Act be reviewed to accommodate AI-related inventions. As on 20 August 2026 no amendment has been enacted. The workable position for an Indian company is unchanged: name the humans who conceived the invention, even where AI tools were used heavily, and keep records of who contributed what.

When a patent is the wrong tool

For many software companies the honest answer is a combination — and sometimes it does not include a patent.

For an AI company whose real asset is a training corpus and a set of weights, secrecy usually beats a patent — because a patent requires you to publish how it works.

One position has moved sharply. The Designs Office was historically hostile to GUI and icon designs. In UST Global (Singapore) Pte Ltd v. Controller of Patents & Designs the Calcutta High Court held GUIs could be considered and remanded the application — after which the Designs Office refused it again. The position shifted in NEC Corporation v. Controller of Patents and Design (Calcutta High Court, Justice Ravi Krishan Kapur, March 2026), which held that GUIs are eligible for design registration subject to Sections 2(a) and 2(d) of the Designs Act, and set aside a series of Controller's orders refusing icons, menus and screen layouts on the ground that they were merely software. If you have a distinctive interface, this route is worth a fresh look — it was worth little in 2020.

A decision framework before you pay anyone

Run this yourself, in an hour, before briefing any firm.

• Write one sentence stating the technical problem — not the customer problem. "Merchants wait too long for payouts" is a customer problem. "Reconciliation requires O(n²) message exchanges across settlement nodes" is a technical one. If you cannot write the second sentence, look at copyright and secrecy instead.
• Put a number on the machine-level effect — latency, throughput, memory, storage, power, accuracy at fixed compute — from your own reproducible benchmarks.
• Ask whether a Controller would call this a business method. If the centre of gravity is a commercial or administrative rule, the technical-effect argument is unavailable. Be ruthless: this exclusion has no escape.
• Check whether the effect is already known. A patentability search comes before drafting: Section 3(k) is only the first hurdle, and novelty under Section 2(1)(j) and inventive step under Section 2(1)(ja) still have to be cleared.
• For AI, ask the enablement question. Could a skilled person reproduce this without your training data and weights? If not, the specification needs far more engineering detail — or the asset belongs in a vault rather than a published document.
• Decide what you are protecting against. Independent development needs a patent; copying needs copyright; departing employees need contracts and secrecy discipline; a distinctive interface may need a design registration. Most software companies need three of the four.

How MYCrave can help

MYCrave Consultancy & Services handles computer-related inventions within a wider patent practice — 3,200+ patents filed, 8,000+ prior art searches and 2,400+ FER and examination replies — with prosecution led by a Registered Patent Agent (No. 5509), the qualification required to represent an applicant before the Indian Patent Office. On a software or AI matter that means:

• A patentability assessment that answers the Section 3(k) question first, before you spend on drafting — including an honest recommendation not to file where the invention is a business method
• Prior art searching across patent and non-patent literature, including the repositories and technical publications where software prior art actually lives
• Specification drafting built around the technical problem and the technical effect, with machine-level detail and figures on record from the filing date, because Section 59 closes that door afterwards
• Claim sets in more than one format — system, method and, where appropriate, computer-readable medium — with functional language backed by disclosed structure
• Section 3(k) objection replies and Controller hearings, including files where 3(k), 3(m) and 3(n) have all been raised
• The alternative routes when a patent is not the answer: copyright for code, design registration for interfaces, and trade-secret structuring where disclosure would cost more than the monopoly is worth

See patent registration and prosecution for how a software file is scoped.

The question to answer before drafting starts

Indian law does not ask whether your product is software. It asks what your invention does to a machine or a process, and whether you said so when you filed.

So before commissioning a specification, have your engineering lead write two paragraphs: the technical problem, and the measurable machine-level effect of your solution. If they are strong, you have something to work with. If they are thin, you have learned something valuable cheaply — and copyright, secrecy and a design registration may serve you better than a patent that will not be granted.

Frequently asked questions

Keep reading