CRI 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.
Examples 51 to 60 in Annexure I of the CRI Guidelines 2025 are the counterpart of Examples 41 to 50. They apply the same four steps to ten everyday software tools: shift scheduling, business reports, digital art, personal finance, playlists, invoices, social media scheduling, Sudoku puzzles, loyalty points and email templates. In every one, the Annexure finds the claim excluded as a computer programme per se.
The Annexure finds all ten examples (51 to 60) excluded. The reasoning is identical each time: the claim is made of standard software modules on generic computer hardware, the problem is administrative, creative or convenience-based, and the only benefit is the speed and convenience of automation, an incidental effect and not a technical effect. 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 test see the computer programme per se article. If your claim resembles one of these, an early patent objection reply or a redraft around the technical layer is the way forward.
How the ten are analysed
Each example runs the four steps of paragraph 4.5.4.1. Step 1 lists the essential technical features; here they are modules such as an input interface, a rule-based module, a display or export module, and a processor and memory. Step 2 states the problem and solution. Step 3 asks whether a technical effect results. Step 4 concludes. These claims are invented by the Office and this article describes them in TaxClue's words.
The ten examples
| No. | Field | Outcome in the Annexure | Reason given |
|---|---|---|---|
| 51 | Scheduling employee shifts: collecting availability, applying predefined rules, notifying staff | Excluded | Automation of a routine administrative task with standard modules; no improvement to the computer, database or network |
| 52 | Generating business reports: collecting sales data, formatting tables and charts, exporting to a document format | Excluded | Convenience and efficiency in business administration; conventional processing, formatting and export |
| 53 | Creating digital art: choosing a colour palette, applying randomisation, displaying the image | Excluded | Automation of an aesthetic or creative process; the Annexure links it to the category of claims concerned with aesthetics or artistic creation |
| 54 | Managing personal finances: recording expenses, setting budgets, charting spending | Excluded | Information management and presentation for convenience; basic arithmetic and standard charts |
| 55 | Generating music playlists from user preferences by querying a song database | Excluded | Automation of a routine entertainment or information retrieval process; only convenience results |
| 56 | Generating invoices | Excluded | Automation of a routine business or administrative process |
| 57 | Scheduling social media posts | Excluded | Automation of a routine scheduling and posting process |
| 58 | Generating Sudoku puzzles | Excluded | Automation of a creative, mental or game-related process; the effect is entertainment or mental challenge |
| 59 | Managing customer loyalty points | Excluded | Automation of a routine business or administrative process |
| 60 | Generating email templates | Excluded | Automation of a routine communication or template management process |
The reasoning pattern
Across the ten, the Annexure keeps to the same points.
- Generic components. The essential features are standard modules and a processor and memory. There is no novel interaction with hardware.
- A non-technical problem. Manual scheduling, manual reporting, the wish for pleasing images or entertaining puzzles: these are administrative, organisational or creative problems.
- Automation only. The solution digitises an existing manual task using generic functions.
- No technical effect. The effect is efficiency or convenience, which the Annexure calls an incidental benefit of using a computer. It notes no improvement in system efficiency, resource use or user interaction at a technical level.
- Conclusion. The claim falls within the exclusion as it gives no technical solution to a technical problem and no effect beyond automating a routine process.
How these differ from Examples 41 to 50
Place the two groups side by side and the dividing line is clear.
| Examples 41 to 50 | Examples 51 to 60 |
|---|---|
| Data from sensors, networks, storage or memory | Data entered by users or taken from databases |
| A control or protection step acting on a system or device | A display, notification or file as the end product |
| A problem in engineering terms (latency, interference, security, fragmentation) | A problem of convenience, administration or creativity |
| A measurable effect on system performance | Efficiency of the human task only |
This is not a rule that scheduling, reporting or playlists can never be patented. The Annexure treats the claims as drafted. A scheduler that, say, reduces contention in a database or shortens a measured processing time could be framed under the first column, but the claim and the description would then have to show that effect.
What to do if your product looks like one of these
- Ask where the technical contribution lies. If the honest answer is that the product saves people time, the claims as drafted are likely to meet an objection like these examples.
- Look below the user interface. A new way of storing, indexing, transmitting or processing the data may carry a technical effect even in a business tool.
- Check whether another right fits. The Annexure's reasoning on digital art points to copyright for aesthetic output; for software as such, see our post on software copyright versus patent.
- Draft the technical layer into the claim. A technical effect described only in the specification will not rescue a claim that does not recite it.
How the objection is usually framed, and how to answer it
| Objection | Answer |
|---|---|
| "Claim is a computer programme per se: automation of a routine process" | Identify any technical problem the description solves beyond automation, and the claim features that solve it |
| "Standard modules on generic hardware" | Show structure or processing in the claim that is not standard, tied to a measured effect |
| "No technical effect beyond convenience" | Point to the effect on system operation, with data from the description |
If the invention truly lies in the business or creative idea, the honest reply may be that the claim cannot be saved; narrowing to the technical layer or choosing another form of protection is better than a long argument.
A worked example (invented)
Mitra Rosters files a system for generating duty rosters for hospital staff, with an interface, a rule module and a notification module. The examiner cites the pattern of Example 51. Mitra's description shows no technical effect beyond convenience, though it records a method of storing rosters in a way that reduces database read time for large wards, measured in tests. Mitra drops the roster claims and files a new application directed to the storage method and its effect on read time, relying on the contrast with Examples 44 and 51. The roster logic stays outside the claims.
Common lapses
- Drafting an application around the business benefit and adding technical wording only after the objection.
- Reciting a processor and memory as if they were a technical contribution.
- Citing the speed of automation as the technical effect.
- Assuming a claim is safe because it avoids the words "business method".
Need help reframing a software product for a patent?
If your product resembles these examples, the first task is to find the technical layer, if one exists, and decide whether it is worth claiming. Our team can assess the specification against the four steps and, if an objection has arrived, prepare the reply. See patent objection reply, and for the claims that pass, read Examples 41 to 50.
Key takeaways
- The Annexure finds all of Examples 51 to 60 excluded as computer programme per se.
- The common feature is automation of a routine task on generic hardware.
- Convenience and speed from automation are incidental effects, not technical effects.
- Technical layers beneath a business tool may still be claimable if they are in the claim and the description.
- Aesthetic and creative output points towards copyright rather than patent.
Read next
- CRI Guidelines 2025, paragraphs 4.5.4 and 4.5.5: computer programme per se
- CRI Guidelines 2025, Annexure I: Examples 41 to 50
- CRI Guidelines 2025, paragraph 4.5.2: the business method exclusion
- Software Copyright vs Software Patent: Which Protection
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.