CRI Guidelines 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.
Paragraph 5.2.3 of the CRI Guidelines 2025 gives seven non-exhaustive scenarios for AI, machine learning and deep learning inventions, with hypothetical Examples 9 to 16. Read closely, the scenarios are less about a claim passing or failing than about what the specification must disclose for each type of AI claim, and what aspect lifts the claim out of section 3(k).
The scenarios cover input-output transformation, pre-trained models, data pre-processing, reinforcement learning, improvement of a computer's internal operation, dataset traits and new learning algorithms versus data engineering. In every example the Guidelines describe a technical effect that may take the claim outside section 3(k) and then list the disclosure needed for enablement. The examples show what to put in the specification; they do not show an AI claim being refused. 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 background on inventorship and sufficiency see paragraphs 5.1 to 5.2.2. If a disclosure objection has been raised on an AI claim, a patent objection reply can use the scenario that matches your claim.
How to read the scenarios
Each scenario states a rule in general terms, gives a hypothetical example in a stated field, lists the sufficiency requirements and ends with the aspect that may take the claim out of the exclusion. The Guidelines call the whole set non-exhaustive. In the examples, the stated performance figures are shown as placeholders or described in words, which is itself a hint: the Office expects validated results in the specification.
The scenarios in TaxClue's table
| Scenario and example | Type of claim | Outcome in the Guidelines | Reason |
|---|---|---|---|
| 1, Example 9 | Neural network converting scanned handwritten prescriptions into structured records | Not excluded if disclosure is sufficient | Automates digitisation, reduces transcription errors and speeds clinical processing; the architecture, dataset, pre-processing, training and validation must be disclosed |
| 2, Example 10 | Failure prediction for industrial machines using a recurrent network on sensor data | Not excluded if disclosure is sufficient | Early detection of mechanical anomalies and better maintenance scheduling; the dataset, its link to the task, architecture, training and results must be disclosed |
| 3, Example 11 | Crop classification from satellite images where pre-processing matters | Not excluded if disclosure is sufficient | Large-scale classification that supports land-use management; every pre-processing step and its link to the model must be shown, with a benchmark showing its effect |
| 4, Example 12 | Reinforcement learning for traffic signal control | Not excluded if disclosure is sufficient | Reduces wait times and congestion by adjusting signals in real time; the agent, states, actions, rewards and training set-up must be defined |
| 5, Example 13 | A neural network inside an operating system kernel scheduler | Not excluded if disclosure is sufficient | Improves CPU use and system performance; input features, architecture and integration with the scheduler must be explained |
| 6, Example 14 | Face recognition trained on a dataset of older people | Not excluded if disclosure is sufficient | Reliable identification in elder care where the dataset trait is the innovation; the traits and a comparison with a baseline must be given |
| 7(a), Example 15 | A new deep learning architecture for crop classification | Not excluded if disclosure is sufficient | Better feature extraction across seasons; the full layout, training protocol and benchmarks must be given |
| 7(b), Example 16 | An inventive data pipeline that builds a harmonised dataset | Not excluded if disclosure is sufficient | The data creation process, not the classifier, drives accuracy; the pipeline, the rationale and the validation must be disclosed |
What each scenario asks of the applicant
Scenario 1: input-output transformation. Where the claim is mainly about turning input into output by logic that may be complex or derived on the go, the specification should explain the transformation with enough specificity for a skilled person to reproduce it. Test results validating accuracy should be included, especially where reliability matters, such as consistent output across runs, accuracy under varied but expected conditions, robustness to small input changes and low rates of critical error.
Scenario 2: a trained model. The training data must be identified and linked to the technical problem, the model and the training method described in full, and the trained model shown to solve the problem predictably, usually through validation and real-world results.
Scenario 3: pre-processing. If pre-processing is key, every step must be disclosed and tied to the end model. If a skilled person cannot see the link between raw and processed data, the claim risks failing enablement.
Scenario 4: reinforcement learning. The claim must say how the system interacts with its environment: the agent, states, actions and rewards. Omission can lead to a non-enabled disclosure.
Scenario 5: improving the computer itself. The specification should describe how the algorithm interacts with the hardware or system architecture and how it improves internal performance, such as storage, scheduling or processing speed.
Scenario 6: dataset traits. If inventiveness depends on traits of the training data, those traits must be disclosed unless a skilled person could identify them without undue experimentation. The Guidelines say that in most cases it is enough to describe the defining characteristics of the data rather than the dataset itself, which may be voluminous or sensitive.
Scenario 7: algorithm versus data. If the invention lies in a new learning algorithm, the algorithm must be described completely, including mathematical foundations and operational steps. If it lies in a new way of creating or curating data, the focus of disclosure shifts to the data process and the algorithm may be generic.
The pattern across all seven
Four requirements recur.
- Describe the architecture or pipeline specifically enough to reproduce it.
- Describe the data and how it was labelled or prepared.
- Describe the training or optimisation method.
- Show validated results that demonstrate the effect.
The second half of each example, the aspect that takes the claim out of section 3(k), always concerns a technical or practical outcome: faster processing, better control, higher reliability, lower resource use. That matches the test in paragraph 4.5.4.
How an objection is usually framed, and how to answer it
| Objection | Answer |
|---|---|
| "The invention is an abstract model; no enabling detail" | Point to the passages giving architecture, data, training and results; add missing detail only if the original specification supports it |
| "Training data not disclosed" | Describe the defining characteristics of the data (Scenario 6) and the link to the technical problem |
| "Pre-processing not explained" | Provide the step-by-step pipeline and its effect (Scenario 3) |
A worked example (invented)
Rasoi Insights files a claim to a model that recommends cooking temperatures from camera images of food. The specification names a "deep neural network" and the result "high accuracy". Reading Scenario 1 and Scenario 2, the examiner asks for the architecture, the nature of the image set, the training method and the validation results. Rasoi's reply points to the layer description, the labelled image characteristics and the cross-validation results already in its examples, and shows that the output drives a heater controller. The reply does not add new matter; it directs the examiner to what the specification already contains.
Common lapses
- Giving accuracy as a bare adjective with no measure or comparison.
- Omitting how data was labelled.
- Omitting a step in pre-processing because it seems routine to the inventor.
- Claiming an algorithm as new while the description shows that the real novelty is the dataset.
Need help with an AI patent specification?
For an AI claim the most common problem is the gap between what the model does and what the specification teaches. Our team can compare your draft with the scenario that fits and list the missing disclosure. See patent objection reply, and for the next technologies the Guidelines cover, read quantum computing and blockchain.
Key takeaways
- The scenarios set out disclosure requirements for different AI claim types.
- Each example ends with a technical outcome that may take it outside section 3(k).
- Describe architecture, data, training and validated results.
- For dataset-driven inventions, describe the defining traits of the data.
- For algorithm-driven inventions, describe the algorithm in full.
Read next
- CRI Guidelines 2025, paragraphs 5.1 to 5.2.2: AI inventions, inventorship and disclosure
- CRI Guidelines 2025, paragraph 4.5.4: computer programme per se
- CRI Guidelines 2025, paragraphs 5.3 and 5.4: quantum computing and blockchain
- 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.