CRI Guidelines 2025 explained: this guide covers what it means, who it applies to, the step-by-step process, documents required, fees, due dates and penalties in India — so you can stay compliant with confidence and avoid costly mistakes.
The algorithm exclusion in section 3(k) is the one applicants meet most often in software, artificial intelligence and security filings. Paragraph 4.5.3 of the CRI Guidelines 2025 explains it as a question of abstractness versus enablement: does the claim leave the steps as a detached concept, or does it supply the technical specifics that make them work?
Algorithms "in all forms" are excluded, including any sequence of steps expressed as a finite list of defined instructions. A claim is treated as abstract if it lists procedural steps without technical implementation details. It escapes the exclusion if the steps are enabled, with the technical components needed to implement them, producing a technical solution to a real-world problem (para 4.5.3.1). The Guidelines are the Patent Office's guidance and do not have the force of law; the Patents Act, 1970 and the Patents Rules, 2003 as now in force prevail.
The Office revises its guidelines, so check the current version on ipindia.gov.in. For the earlier limbs see the business method article. If an examiner has called your claim an algorithm, a patent objection reply that supplies the missing implementation detail from the description is the usual answer.
What the Guidelines treat as an algorithm
Paragraph 4.5.3 defines the excluded class widely: a set of rules or procedures, any sequence of steps, or any method expressed as a finite list of defined instructions, whether for solving a problem or otherwise, and whether logical, arithmetical or computational, recursive or otherwise.
The wide definition means that nearly every software claim contains an algorithm. The Guidelines do not exclude software that contains an algorithm; they exclude the claim whose substance is the algorithm without more.
Abstractness: when a claim is "just the steps"
A claim is typically abstract, the Guidelines say, if it presents a sequence of procedural steps without enough technical implementation detail, leaving the algorithm as an isolated concept detached from practical application. Two illustrations in the text:
- A sorting algorithm (quicksort or merge sort) whose claim only lists the steps, without saying how they are technically applied in a context such as database query performance in a cloud system or real-time data streams in a 5G network.
- A cryptographic algorithm claim that only recites generating a key and encrypting data, without explaining how it is implemented in a payment system, for example through the card's firmware or real-time transaction validation.
The Office's phrase for these is an abstract idea "camouflaged" as a technical invention. The remedy it describes is that the claim must provide specific enabling details to solve a real-life problem: the logical flow and also its technical realisation in a technical framework.
The three-step assessment (paragraph 4.5.3.1)
| Step | What the examiner does | What the applicant should show |
|---|---|---|
| 1. Construe and identify the steps | Understand the invention as a whole, find where its core lies and identify the series of steps forming a sequential process | The steps of the claim, clearly set out |
| 2. Abstractness or enablement | Ask: (a) are the steps abstract, devoid of the technical specifics or components needed to implement them; or (b) are they enabled, with the technical specifics and components, detailing implementation and resulting in a technical solution to a real-world problem | The components, data structures, protocols or hardware that carry out each step, and the real-world problem |
| 3. Conclude | 2(a): excluded as an algorithm. 2(b): not excluded | Argument aligned with 2(b) |
This mirrors the structure used for the mathematical method and business method limbs, but the question at step 2 is different: it asks whether the steps are tied to technical means and to a real problem.
The first worked example: pseudo-random numbers
In the Guidelines' Example 5, the claim covers generating pseudo-random numbers with an input module that receives a seed, a permutation engine that applies a series of permutations, and an output module that outputs the sequence.
The Office finds the steps highly abstract. The claim does not say how the seed is received, which permutations are applied or how they are chosen or executed, or how the output sequence is derived. The permutation engine is a conceptual component. Nor does the claim connect the numbers to a use, such as secure communication, simulation or sampling. It falls under step 2(a) and is excluded.
The second worked example: encrypted transmission
In Example 6, the claim covers encrypting and transmitting data using permutation-based pseudo-random numbers. It names a hardware security module in a network interface card that receives a seed from true random entropy sources, a permutation unit that produces a stream of fixed-length numbers and stores intermediate states in a high-speed buffer, a cryptographic processor that retrieves the numbers and encrypts a block of data using a standard encryption engine, a packetisation engine and transmission.
The Office finds substantial technical specifics on how the numbers are generated and used, and identifies the real-world problem as insecure data transmission and vulnerability to cryptographic attacks. The claim details how the implementation achieves enhanced resistance to attack through specific components. It falls under step 2(b) and is not excluded.
What the two examples teach together
The mathematical idea in both examples is the same: permutation-based number generation. The difference lies in the claim. Example 5 stops at a function; Example 6 names where each step runs, with what, and what problem the whole solves. If you are drafting, ask of every step: on what component does this run, what data does it take and give, and what technical problem does the sequence solve?
How the objection is usually framed, and how to answer it
| Objection | Answer |
|---|---|
| "The claim is a set of steps with no implementation" | Point to the passages and drawings that disclose the components and the data flow, and amend the claim to recite them |
| "The claim describes a conceptual module" | Replace the conceptual label with the structure disclosed in the description |
| "No real-world problem is solved" | Identify the real-world problem in the specification and the technical effect in the claim |
The ruling cited in paragraph 3.5.9 of the Guidelines (BlackBerry v Assistant Controller) points the same way: where the invention is implemented through software that results in a technical effect, the implementation is the inventive feature, not the algorithm. See our article on the rulings.
A worked example (invented)
Meghdoot Analytics claims "a method of ranking records by applying a ranking function to a feature vector and outputting a ranked list". The examiner treats it as an algorithm. Meghdoot amends the claim to recite that the ranking runs on an edge device with a stated memory limit, that features are read from a named sensor interface, and that the ranked list triggers a specified alert on a connected controller; the description states the latency problem of sending data to a remote server. The claim now supplies the components and the real-world problem that the Guidelines look for under step 2(b).
Common lapses
- Claiming the algorithm in "module" language with no structure in the description.
- Relying on a standard cryptographic or sorting method without showing where and how it is applied.
- Omitting the real-world problem from the specification.
- Treating a recitation of "a processor and a memory" as technical implementation.
Need help with an algorithm objection?
The response usually depends on how much implementation detail the original specification contains. We can read your description against paragraph 4.5.3 and tell you what can be claimed. See patent objection reply and, for the programme limb that comes next, computer programme per se.
Key takeaways
- Algorithms in all forms are excluded as such; software containing an algorithm is not automatically excluded.
- The question is abstractness versus enablement.
- A claim must give the technical realisation and solve a real-world problem.
- Pseudo-random number generation with no implementation fails; the same idea tied to a security module and network card passes.
- The description must carry the implementation detail the claim will rely on.
Read next
- CRI Guidelines 2025, paragraph 4.5.2: the business method exclusion
- CRI Guidelines 2025, paragraph 4.5.4: computer programme per se
- CRI Guidelines 2025, Annexure I: Examples 35 to 40 on algorithms
- Software Patents in India: Can Software Be Patented
Disclaimer: Based on the manuals and guidelines published by the Office of the Controller General of Patents, Designs and Trade Marks that are named in the article, as consulted on 4 October 2026. They are guidance and do not have the force of law; the Patents Act, 1970 and the Patents Rules, 2003 as amended (including the 2024 amendment rules) prevail, and the current versions on ipindia.gov.in should be checked. This article is general information, not legal advice; check the official text before acting.