It is frequently seen that applicants building software products are less worried about novelty and more anxious about the routine objection that arrives in the First Examination Report, that their claims are a “computer programme per se” or an “algorithm”. Drafts that read like instructions or equations often trigger Section 3(k) and stall otherwise strong innovations. This guide explains where such applications typically falter under Indian practice, what the law actually tests, and how to frame a prosecution path that moves from objection to allowance, without inflating cost or complexity.
Section 3(k) and the operative test, in plain words
Section 3(k) of the Patents Act excludes a mathematical or business method or a computer programme per se or algorithms. Examiners apply the Revised Guidelines for Examination of Computer Related Inventions, 2017, which call for a substance-over-form analysis and ask whether the claimed invention produces a technical effect or technical contribution beyond mere automation of mental steps.
Delhi High Court precedent has reinforced this approach. In Ferid Allani v. Union of India (2019), the Court held that a computer-implemented invention is not barred by Section 3(k) if it demonstrates a technical effect or technical contribution, and remitted the matter for fresh consideration. In Microsoft Technology Licensing v. Assistant Controller (2023–2024 orders), the Court set aside refusals where the decision did not engage with technical effect in substance and reiterated that software implementation alone is not fatal. In Comviva Technologies v. Assistant Controller (12 November 2024), the Court set aside a Section 3(k) refusal because the claims addressed a protocol-level security problem and delivered a concrete technical solution. While that case concerned payments, its ratio helps any software applicant who can show system-level improvement.
A practical development to watch is the IPO’s draft CRI Guidelines 2025, released for consultation, which continue to foreground technical effect and contribution, though the 2017 Guidelines remain in force until formal adoption.
Typical barriers for software and algorithm claims
1. “Computer programme per se” without a technical effect
If a claim reads like “receiving data, processing it according to steps A-D, and outputting a result” on general-purpose hardware, examiners characterise it as a programme per se. Recent commentary and orders underline that a mere series of instructions does not meet the threshold unless tied to a machine-level change or measurable system behaviour.
2. “Algorithm” or “mathematical method” labelling
Where the contribution lies in an equation, loss function, or matrix rule, and the specification does not show how machine operation changes, Section 3(k) is readily invoked as a mathematical method or algorithm. The 2017 CRI Guidelines caution against allowing mere calculations in disguise.
3. Enablement and sufficiency under Section 10
Many specifications recite objectives and block diagrams but omit the best method. In software, enablement means disclosing enough about the architecture, data constraints, scheduling, memory or I/O behaviour, or security handling so that a skilled person can practice the invention, not just identify a goal. Examiners routinely club 3(k) with Section 10 objections where detail is thin.
4. Inventive step over standards and public code
Much relevant prior art is found in standards, white papers, and open-source repositories, not only patents. Examiners use this material for obviousness. The CRI Guidelines remind that ordinary novelty and inventive-step tests apply in addition to 3(k).
Drafting software and algorithm claims that work in India
Start with a technical problem and a measurable effect
Frame the bottleneck your invention solves in computing terms, then quantify the outcome. For example, reduced handshake retransmissions on a noisy link, lower cache misses under a new scheduler, or improved fault tolerance through a specific message framing. This positions the contribution as technical, not merely functional. Ferid Allani and Microsoft both make the technical-effect lens decisive in outcome.
Structure claims in layers
Independent system or apparatus claim that recites concrete components and their configured interactions, for example a secure enclave interface, DMA pathway, message-queue scheduler, protocol state machine, or specialised accelerator hook, rather than a generic “processor and memory”.
Method claim that changes how the machine behaves, for example a handshake renegotiation policy that reduces latency, a memory layout that lowers cache thrash, or an entropy budget that reduces key-exchange retries.
Computer-readable medium claim only in support. Substance still controls eligibility.
Put evidence inside the specification
Include benchmarks, traces, or profiling counters that tie claim features to system metrics. Courts in Microsoft and Comviva responded positively where a tangible technical contribution was apparent on the record.
De-risk red flags early
Move pricing rules, UI labels, or business logic to background.
Avoid claims that are only accuracy goals or user outcomes. Convert these to machine metrics such as latency budgets, bandwidth, memory footprint, packet loss, or fault recovery.
Do not rely on “configured to” without saying how. Describe the configuration and its effect.
Prosecution playbook, step by step
Before filing: build a record you can use
Run controlled tests that isolate the effect of the claimed feature, not just end-user KPIs. Save packet captures, scheduler traces, or cache-miss statistics. These artefacts can underpin responses or affidavits. This aligns with the courts’ expectation that technical contribution be evidenced, not asserted.
Anticipate dual objections, Section 3(k) plus inventive step
Prepare differential charts against the closest standard or codebase to show what your feature adds at a system level. Then pivot to technical effect. Use Ferid Allani for the legal gateway and Microsoft for the requirement of a reasoned, substance-based analysis. Where your invention touches communications or security, Comviva helps underline protocol-level improvement.
Amend with a map
Carry fall-back claims that progressively crystallise the technical effect, for example narrowing to a specific packet framing that reduces retransmissions, a buffer policy that drops cache misses, or an enclave-mediated key release that changes handshake retries. Many favourable orders turn on whether the record shows a real problem–solution chain rather than cosmetic edits.
Use hearings to tell the machine story
A crisp hearing brief should walk the Controller from the technical problem to the claim and the measured outcome. Recent analyses emphasise that describing an invention as a series of instructions, without a machine-level delta, will not pass. Show before–after traces rather than adjectives.
Short answers to common questions inside the flow
Are pure algorithms patentable in India?
Not as such. If the claim is to a mathematical construct or abstract algorithm, it risks exclusion. If the algorithm is tied to a specific architecture that changes machine behaviour and yields a measurable technical effect, it can pass the 3(k) filter subject to novelty and inventive step. Ferid Allani and Microsoft frame this pathway.Will adding “a processor and memory” save my claim?
No. Examiners look through such dressing. You must show how the processor is configured and how that configuration changes operation in measurable terms. The CRI Guidelines expressly caution against relying on form over substance.Do I need to disclose code or datasets?
Usually not, but you must enable the invention. Disclose the best method, including architectural constraints, data characteristics that matter, scheduling, memory or I/O strategies, and security steps that make the effect repeatable. This addresses Section 10 sufficiency and often diffuses 3(k) concerns.Has the law become stricter or more lenient recently?
Both strands exist. Comviva illustrates a permissive approach where technical contribution is apparent, while other 2024–2025 orders uphold refusal when the claims reduce to instructions without a technical problem being solved. Outcomes turn on how well the file history demonstrates technical effect.A practical checklist for software applicants
Define the technical problem in computing terms such as network jitter, cache contention, buffer underflow, thermal throttling, or secure key release timing.
State measurable outcomes in the specification and keep bench artefacts ready. Prefer system metrics over user KPIs.
Lead with system or method claims that alter machine behaviour. Keep computer-readable medium claims supportive.
Pre-chart prior art from standards and repositories, not just patents, to position inventive step.
Map your arguments to Ferid Allani and Microsoft, and rely on Comviva wherever protocol-level security or communications improvements are central.
Prepare fall-backs tied to the measured effect, and use hearings to walk the Controller through the problem–solution chain, with traces.
Track the draft CRI 2025 process for examination nuance, while applying the 2017 Guidelines in current filings.
Way forward
Software and algorithm patents are not off-limits in India. The decisive move is to recast the contribution from instructions on paper to changes in machine behaviour backed by evidence. If your specification explains a real computing problem, claims the architecture that solves it, and shows measurable technical effect, Section 3(k) becomes a navigable hurdle rather than a wall. Recent Delhi High Court decisions have opened a clear path for well-framed computer-implemented inventions. The strategy is to put hard engineering detail into the patent, prosecute with data, and keep your fall-backs aligned to the effect you can prove.
