It is often asked at the drafting table whether a blockchain consensus tweak, a smart-contract framework, or a novel wallet workflow can be patented in India. Much of the confusion comes from objections under Section 3(k) for “computer program per se” or “algorithms”, and the worry that payment or settlement use-cases will be branded “business methods”. Since 2019, Indian courts and the Patent Office have clarified the path for computer-related inventions, and in 2025 the CRI Guidelines were overhauled. This article distils what actually works for blockchain filings in India and how it differs from ideas that will be refused.
The one liner rule under the Indian Law
Blockchain filings are examinable like any other computer-related invention. If your claims demonstrate a technical effect or technical contribution and are not just a business method, algorithm, or computer program per se, patenting is possible. Section 3(k) excludes those non-patentable categories, but the Delhi High Court in Ferid Allani v. Union of India (2019) confirmed that inventions showing technical effect are not barred merely because software is involved. The CRI Guidelines, now updated in 2025, reflect this approach.
What exactly crosses the section 3(k) line?
The “technical effect” test, in practice
Courts have directed the Patent Office to ask whether the claimed invention improves system functioning or solves a technical problem, rather than hunting for “novel hardware”. Decisions like Raytheon Company v. Controller (2023) and Microsoft Technology Licensing v. Assistant Controller (2023, 2024) reiterate that the focus is on technical effect or contribution, not on dressing a program with hardware jargon. The 2025 CRI Guidelines cite this line of cases.
For blockchain, persuasive technical effects commonly include: reduced consensus latency under Byzantine faults, lower communication overhead per block, improved fork-choice stability, better entropy for leader election, lower storage IO for state commitments, enhanced node security through protocol-level key handling, or measurable energy savings through scheduling, without shifting into a payment or trading logic claim.
The absolute bar for business methods
Where the substance of the claim is a commercial scheme, Section 3(k) applies absolutely. The Delhi High Court’s OpenTV decision treated “gift media” distribution as a business method despite its networked implementation, and more recent rulings, including Comviva (2024), warn that sprinkling terms like “payment” or “transactions” will invite a business-method refusal unless the real advance lies in the underlying technology.
“Computer program per se”, “algorithms” and media claims
Claims to computer program products, bare algorithms, or “instructions stored on a medium” are treated as per se and refused. The Guidelines and practice notes remain clear on this point; structure the claims as method, system, or apparatus with concrete technical features and effects.
How a blockchain invention become patentable?
Think in terms of technical problem → technical solution → measurable effect.
Consensus layer, for example a leader selection protocol that reduces message complexity from O(n²) to O(n) under a specified adversarial model, demonstrated with simulation benchmarks and failure-mode analysis.
Networking stack optimisations that cut block propagation delay through a defined peer-selection heuristic and congestion control, evidenced by measured hop counts and bandwidth usage on large-n topologies.
State management using a new authenticated data structure that lowers verification cost for light clients, shown with asymptotic and empirical comparisons.
Security architecture that hardens key handling inside a secure element, with a protocol proving resistance to replay or key-exfiltration at the interface level.
Each of these points to engineering rather than commerce. If the claims drift into settlement flows, token issuance rules, or staking pay-outs, you are back in 3(k) business-method territory. Draft to the pipes, not the payments.
Drafting strategy that works before Indian patent office
Claim format: Use a method claim performed by nodes of a distributed system, and a system claim that pins down processors, memory, network interfaces, and the inter-operation that delivers the effect. Avoid “computer program product” and avoid claims that read like pure instructions.
Technical story in the specification: Explain the pre-existing bottleneck and why known consensus, sharding, or mempool strategies fail under your constraints. Then report benchmarks: throughput, finality time, orphan rate, storage writes, CPU cycles, or energy usage. This is what examiners and courts look for when assessing technical effect, as emphasised in Ferid Allani and carried through in Raytheon and Microsoft.
Stay inside Section 59 when amending: Late-stage claim overhauls can be struck down. OpenTV is a cautionary tale on amendments that stray beyond the original disclosure. Build the best set at filing and keep amendments faithful.
Cite the right evidence: If your improvement uses cryptography, remember that a cryptographic method qua mathematics is excluded, but an applied protocol that improves security of a networked system with measurable effects is analysed as a technical contribution. Anchor claims accordingly.
What typically gets refusal?
Business logic: token sale mechanics, loyalty credits on-chain, settlement rules, or escrow flows, even if implemented via smart contracts. These are treated as business methods.
Abstract algorithms: consensus “ideas” stated at a high level without network, timing, or failure assumptions, or without evidence that system behaviour improves.
Media claims: “A computer-readable medium having instructions that…”. These fall to computer program per se.
The 2025 CRI Guidelines consolidate the case law, direct examiners to look for technical effect/technical contribution, and collect examples aligned with court language. They do not rewrite Section 3(k), however, so business methods remain excluded and pure code claims remain vulnerable.
Quick checklist
Before filing
Write the problem and technical effect in engineering terms.
Build comparative data against baseline protocols, include stress cases.
Decide claim sets: method plus system, and perhaps apparatus at node level.
Run a Section 3(k) screen for business-method drift.
During prosecution
Respond on technical effect, not on “novel hardware”. Use your benchmarks.
Keep amendments inside Section 59. No new matter, no late pivots to commerce.
After grant
Enforcement turns on claim mapping to the deployed stack. Preserve logs and measurements, and plan for discovery to show read-on in distributed deployments.
