ARTICLE
29 July 2025

Decoding The 'Algorithm' Exclusion: A Closer Look At Draft CRI Guidelines 2025

LS
Lakshmikumaran & Sridharan

Contributor

Lakshmikumaran & Sridharan (LKS) is a premier full-service Indian law firm specializing in areas such as corporate & M&A/PE, dispute resolution, taxation and intellectual property. The firm, through its 14 offices across India works closely on litigation and commercial law matters, advising and representing clients both in India and abroad.
As technologies like Artificial Intelligence (‘AI') rapidly evolve, the Indian Patent Office (‘IPO') appears to have recognized the need to modernize its approach to maintain pace.
India Intellectual Property

Introduction

As technologies like Artificial Intelligence ('AI') rapidly evolve, the Indian Patent Office ('IPO') appears to have recognized the need to modernize its approach to maintain pace. Release of draft Version 2.0 (available here) of the Guidelines for Examination of Computer Related Inventions ('CRIs'), along with Annexure-I, on 26 June 2025, reflects this effort. The updated Guidelines, issued after stakeholder feedback on the first draft that was released on 25 March 2025, now include more detailed examples clarifying patentable and non-patentable subject matter.

The Guidelines address all exclusions carved by Section 3(k) of the Indian Patent Act that exclude four categories of inventions, namely, mathematical methods, business methods, computer programs per se, and algorithms.

This article analyzes how the Guidelines propose to determine whether or not a claimed invention is excluded as an 'algorithm'.

Understanding the 'Algorithm' exclusion from the Guidelines

The Guidelines aim to clarify the distinction between abstract ideas and patentable inventions, a distinction that was not explicitly addressed in the CRI Guidelines of 2017. In particular, the Guidelines specify that a claim would be considered abstract if it merely outlines a series of procedural steps without detailing how those steps are technically implemented, thus categorizing algorithms as abstract concepts rather than practical solutions. In other words, the Guidelines seem to prescribe that claims should specify not only what is being done, but also how it is being done, to demonstrate that the claimed invention provides a technical solution to a technical problem, rather than merely constituting a theoretical concept.

To determine whether a claimed invention falls within the exclusion of an 'algorithm' under Section 3(k), the Guidelines, in Section 4.5.3.1, introduce a two-step test. In the first step, a claim of an invention is to be examined as a whole to identify its actual substance, looking beyond the wording of the claims to understand what is truly being claimed. This involves determining whether the claim recites a series of sequential steps or a procedural flow. Second, the identified steps of the claim are to be assessed to determine if they are merely abstract or sufficiently enabled. By way of the two-step test, the Guidelines prescribe that if the steps of the claim lack technical specificity and do not include concrete implementation details, such as components or mechanisms required for technical execution, the claim is to be treated as abstract and excluded as an algorithm. However, if the steps of the claim include clear technical implementation aimed at solving a real-world technical problem, the claimed invention does not fall within the exclusion of 'Algorithm'.

In Section 4.5.3.2 of the Guidelines, two examples, Examples 5 and 6, are provided to illustrate the application of the two-step test for determining whether a claimed invention falls under the 'algorithm' exclusion.

Example 5 describes a method for cryptographic key generation, involving steps such as receiving a seed, applying permutations, and outputting pseudo-random numbers. Under Step 1, the claim is recognized as a sequential process for generating numbers. Under Step 2, the claim is deemed abstract because it lacks technical details, as there is no detail on how the permutations are applied, how the system components function, or how the output is technically realized. The 'permutation engine' is identified as a conceptual element without any concrete technical disclosure or enabling detail. Since the claim does not demonstrate how it solves a real-world technical problem through a specific technical implementation, the Guidelines conclude that the subject matter of the claim of Example 5 is abstract and, hence, falls within the exclusion of an 'algorithm' under Section 3(k).

The conclusion in respect of the claim of Example 5 appears to be sound, as the claim is abstract in so much as it fails to demonstrate any practical application through the steps recited in the claim. However, concerns arise when the requirement for technical features in patent claims is equated with the inclusion of hardware features or structural components in the method claim, as appears to be the case in Example 6 and other examples provided in Annexure I of the revised Guidelines.

In the claim of Example 6, a method for encrypting and transmitting data is recited. The method includes a series of operations that are closely tied to tangible hardware elements, such as a Hardware Security Module (HSM) integrated into a Network Interface Card (NIC), a permutation unit, a cryptographic processor, and components like an AES-GCM encryption engine and a packetization engine.

Based on the analysis accompanying Example 6, the Guidelines seemingly emphasize that such hardware or physical features are indispensable for the claim to be considered allowable. This could potentially disadvantage genuine software-based inventions that achieve technical outcomes without relying on physical structures. The emphasis on hardware references may inadvertently conflate 'technical feature' with 'hardware inclusion,' thereby narrowing the interpretation of what qualifies as patentable under the Guidelines.

In practice, in the case of CRIs, most method claims are assessed (or are likely to be assessed) to be algorithms if accompanying hardware is not specified. The examples in the Guidelines seem to indicate that all CRI method claims should recite hardware features, which appears to be over-restrictive and not aligned with either Indian jurisprudence or global best practices. Such a requirement arises only in cases where the steps of the method can be carried out mentally.

As such, assessment of whether a method claim is excluded as an algorithm should depend on its practical application, regardless of whether hardware is specified in the method claim. Including hardware features in the method claim does not automatically make the method non-abstract, nor does omitting them necessarily make the method abstract. However, reciting such physical constructional features in the claims, as opposed to describing them in the specification, actively serves to limit the scope of the reasonable protection that could be afforded by the claim.

Although the Guidelines do not explicitly require hardware features in claims and suggest assessing CRIs based on substance rather than form in which the claims are presented, the heavy reliance on hardware-based examples in the Guidelines may inadvertently prompt Examiners/Controllers to interpret 'technical implementation details' too narrowly. As a result, valid claims for software-based inventions, particularly AI-based inventions, may be categorized as algorithms, even when they address technical issues.

Conclusion

While the revised Guidelines make a genuine effort to standardize the assessment criteria for CRIs, it appears to overemphasize on inclusion of hardware features in the method claims. As the Guidelines themselves acknowledge, the focus in assessing patentability of the CRIs should be on the underlying substance of the invention, not the particular form in which it is claimed.

Insisting on reciting physical features in the claims, at the very least, risks leading to unwarranted objections during examination. Valid software-based inventions that do not rely on specialized hardware or improve hardware functionality may be incorrectly categorized as algorithms despite solving concrete technical problems. The Guidelines, if enforced in their present form, could lead to denial of protection for inventions solely because they lack hardware features, thereby risking the exclusion of legitimate software-based inventions from patentability.

The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.

Mondaq uses cookies on this website. By using our website you agree to our use of cookies as set out in our Privacy Policy.

Learn More