Technical Contribution without Novel Hardware: Madras High Court’s Section 3(k) Framework for Computer‑Related Inventions in Ab Initio Technology LLC v. Controller of Patents

Technical Contribution without Novel Hardware: Madras High Court’s Section 3(k) Framework for Computer‑Related Inventions in Ab Initio Technology LLC v. Controller of Patents

Citation: 2025 MHC 2579

Court: High Court of Judicature at Madras

Bench: Senthilkumar Ramamoorthy J.

Date of Judgment: 4 November 2025

I. Introduction

A. Parties and factual background

The appellant, AB Initio Technology LLC, a Delaware-based software company, challenged the rejection of its Indian patent application no. 4693/CHENP/2010, titled "Graphic Representations of Data Relationship". The application was the national phase entry of PCT application PCT/US2009/035293, claiming priority from US patent application no. 61/031,672 dated 26 February 2008.

The respondents were:

  • The Controller of Patents & Designs, New Delhi (respondent no. 1)
  • The Controller of Patents, Chennai Patent Office (respondent no. 2)

The invention was developed in the aftermath of the 2008 financial crisis to address the critical problem of tracing the source and propagation of flawed data items in complex, distributed data processing environments. Traditional approaches required laborious, step‑by‑step manual tracing through heterogeneous systems, which was both error‑prone and slow. AB Initio sought to patent a method and system that generate data lineage diagrams—graphical representations of how data items and programmes relate to each other, both upstream (where a piece of data came from) and downstream (where that data was used).

B. Procedural history

Key steps in the prosecution history were:

  • 27 July 2010: Filing of national phase application 4693/CHENP/2010 in India.
  • 20 February 2012: Request for examination filed.
  • 30 January 2018: First Examination Report (FER) issued raising objections on:
    • Novelty and inventive step (Section 2(1)(j)), citing D1 (US 2007/214179 A1) and D2 (US 6,718,319 B1),
    • Non‑patentability under Section 3(k),
    • Sufficiency of disclosure, and clarity/succinctness.
  • 12 July 2018: Response and amended claims filed.
  • 26 November & 11 December 2019: Hearing notices issued with further objections including:
    • Amendments allegedly beyond the scope (Section 10(4)(c)),
    • Non‑patentability under Sections 3(k) and 3(n),
    • Lack of novelty and inventive step vis‑à‑vis D1 under Section 2(1)(j).
  • 7 January 2020: Hearing conducted.
  • 21 January 2020: Written submissions and further amendments filed by the applicant.
  • 13 July 2020: Impugned order issued, finally rejecting the application on:
    • Section 3(k) – as a “computer programme per se / algorithm”; and
    • Section 2(1)(j) – lack of novelty and inventive step vis‑à‑vis D1.
  • Appeal: The applicant filed a Transfer Civil Miscellaneous Appeal (Patents) under Section 117A(2) of the Patents Act before the Madras High Court.

C. Core legal issues

The appeal posed two central questions:

  1. Section 3(k) – Exclusion of “computer programme per se or algorithms”
    Does AB Initio’s invention, which is implemented through software and algorithms on conventional hardware, fall foul of the exclusion in Section 3(k)? Or does it provide a technical contribution/effect such that it remains patent‑eligible?
  2. Section 2(1)(j) – Novelty and inventive step
    Is the claimed method and system for generating data lineage diagrams anticipated or rendered obvious by the prior art D1, which discloses systems for creating a unified graphical view of entity relationships across multiple hierarchies?

The judgment is particularly significant for its deep, structured treatment of Section 3(k) and its alignment of Indian law with the European Patent Office (EPO)’s technical contribution approach, while expressly declining to adopt the stricter UK “AT&T signposts” test.

II. Summary of the Judgment

A. Outcome

The High Court:

  • Allowed the appeal;
  • Set aside the Controller’s order dated 13 July 2020; and
  • Directed grant of patent on application no. 4693/CHENP/2010 on the basis of the latest set of claims filed by the appellant.

B. Core holdings

  1. Section 3(k) – Technical contribution without novel hardware
    The Court held that:
    • A computer‑related invention (CRI) is not excluded by Section 3(k) merely because it uses algorithms and is implemented on a general‑purpose computer.
    • Novel or customised hardware is not mandatory for patent‑eligibility of a CRI.
    • A CRI is patent‑eligible if it makes a technical contribution or has a technical effect in the realm of practical methods and skills in the physical or natural sciences, even if implemented via software on standard hardware.
    • The AB Initio invention makes such a technical contribution by:
      • reducing query response time,
      • enabling dynamic, user‑configurable, upstream and downstream data lineage tracing, and
      • replacing time‑consuming manual data tracing with an automated, iterative query and diagram generation mechanism.
    Accordingly, the invention does not fall within the “computer programme per se or algorithm” exclusion.
  2. Section 2(1)(j) – Novelty and inventive step
    • D1 discloses a system for creating and displaying a unified graphical view of entity relationships drawn from multiple data hierarchies (e.g. customer, advisor, supervisor relationships).
    • By contrast, AB Initio’s invention is focused on data lineage among programmes and data, using metadata, configuration information sets and selection specifications to iteratively query a metadata management system and generate data lineage diagrams.
    • D1 does not disclose:
      • querying a metadata management system using configuration information sets comprising selection specifications associated with predetermined types (programme/data), nor
      • generation of a lineage diagram that represents the evolution and transformations of data items upstream and downstream.
    • Thus:
      • The invention is novel over D1; and
      • Even taking D1 as analogous prior art and adding common general knowledge, a person skilled in the art (PSITA) could not arrive at the claimed invention without ingenuity. The invention involves an inventive step.

The judgment also elaborates a detailed interpretive framework for Section 3(k), distinguishing between “technical contribution/effect” at the patent‑eligibility stage and “technical advance” under Section 2(1)(ja) at the inventive‑step stage.

III. Detailed Analysis

A. Statutory framework

1. Section 3(k): Exclusions

Section 3(k) reads:

“3. What are not inventions.—The following are not inventions within the meaning of this Act,—
…
(k) a mathematical or business method or a computer programme per se or algorithms;”

Key features:

  • Four excluded categories are bundled: mathematical methods, business methods, computer programmes per se, and algorithms.
  • The qualifier “per se” is applied only to computer programme, not to the other three elements.

The Court builds on its earlier decision in Microsoft Technology Licensing LLC v. Assistant Controller of Patents, 2024:MHC:2537 (Microsoft MHC), to:

  • Clarify the scope of “mathematical method” and “business method” as exclusions of abstract ideas or conceptual methods, not every claim that uses mathematical formulae or relates to business.
  • Emphasise that when a computer‑related invention is used in a business method, the relevant exclusion is not “business method” but may still be “computer programme per se or algorithm”.

2. Sections 2(1)(j) and 2(1)(ja): Invention, inventive step, and “technical advance”

Section 2(1)(j) defines “invention” as:

“a new product or process involving an inventive step and capable of industrial application”.

Section 2(1)(ja) defines “inventive step” as:

“a feature of an invention that involves technical advance as compared to the existing knowledge or having economic significance or both and that makes the invention not obvious to a person skilled in the art.”

The Court carefully distinguishes:

  • For inventive step:
    • “Technical advance over existing knowledge” requires comparison with prior art at the priority date.
    • “Economic significance” is an alternative or additional route; either can establish inventive step, subject to non‑obviousness.
  • For Section 3(k):
    • The question is whether the claimed invention makes a technical contribution/effect, not whether it is a “technical advance over existing knowledge”.
    • Therefore, at the Section 3(k) stage, one need not compare with prior art; that comparison belongs to the Section 2(1)(j) analysis.

This separation of the eligibility question (Section 3(k)) from the patentability question (Section 2(1)(j)) is central to the Court’s analytical structure.

B. Interpreting Section 3(k): From “computer programme per se” to technical contribution

1. Comparative law: EPC and UK Patents Act

The Court situates Section 3(k) in a comparative context by examining:

  • Article 52 of the European Patent Convention (EPC), especially:
    • Article 52(2) – listing “programs for computers” among non‑inventions; and
    • Article 52(3) – limiting this exclusion to such subject matter “as such”.
  • Section 1(2) of the UK Patents Act, 1977, which mirrors Article 52 by listing non‑inventions and limiting them to things claimed “as such”.

These formulations are closely analogous to India’s use of “per se” in Section 3(k).

2. The UK “technical contribution” and AT&T signposts

The judgment carefully reviews a series of UK authorities:

  • Aerotel Ltd v. Telco Holdings Ltd; Macrossan’s Application [2006] EWCA Civ 1371
    • Set out a four‑step test:
      1. Contrue the claim;
      2. Identify the actual contribution;
      3. Determine whether the contribution falls wholly within excluded subject matter; and
      4. Check whether the contribution is technical in nature.
  • Symbian Ltd v. Comptroller General of Patents [2008] EWCA Civ 1066
    • Accepted that a computer program can be patentable if it makes the computer faster or more reliable, i.e., improves the computer as a machine.
  • AT&T Knowledge Ventures v. Comptroller General of Patents [2009] EWHC 343 (Pat)
    • Formulated five “signposts” to identify patent‑eligible computer‑implemented inventions, focusing on:
      • Effects outside the computer;
      • Effects at the level of the computer architecture;
      • Making the computer operate in a new way;
      • Increasing speed or reliability; and
      • Overcoming a technical problem rather than circumventing it.
  • HTC v. Apple [2013] EWCA Civ 451
    • Reinforced the focus on what the invention contributes “as a matter of practical reality”, over and above the fact that it is implemented by a computer.

The Court observes that UK law, particularly after Aerotel and AT&T, has tended to treat a computer‑implemented invention as a “computer program as such” unless it:

  • has an effect outside the computer system (e.g., controlling anti‑lock braking); or
  • directly alters the internal working or architecture of the computer (e.g., operating system level innovations improving speed or reliability).

This creates a high bar for software patents that “merely” improve information processing or user experience within a general‑purpose computer.

3. EPO approach: Two‑hurdle test and “further technical effect”

The Court then turns to the EPO Guidelines for Examination (April 2025) and key EPO Board of Appeal decisions.

(a) Two‑hurdle approach

  • First hurdle – Patent eligibility:
    • Does the claimed subject matter involve technical means? If yes, it is considered an “invention” under Article 52(1).
    • Even a single technical feature suffices; this determination is made without reference to prior art.
  • Second hurdle – Novelty and inventive step:
    • Once it clears the first hurdle, standard tests for novelty and inventive step are applied.

(b) Computer programs and “further technical effect”

Under EPO practice, a computer program is not excluded “as such” if it produces a further technical effect, i.e., a technical effect going beyond the normal physical interactions between software and hardware (like mere electric currents).

Examples of “further technical effect” include:

  • Controlling an anti‑lock braking system;
  • Determining emissions in an x‑ray device.

(c) Distinction between “computer program” and “computer‑implemented method”

The EPO draws a conceptual distinction:

  • A “computer program” is the sequence of instructions.
  • A “computer‑implemented method” is the actual process performed on a computer executing those instructions.

This supports the idea that a implemented method that yields a technical effect is not excluded as a “program as such”, even if its implementation involves software.

(d) Database management systems (T 1924/17, T 0697/17)

The Court places particular emphasis on EPO decisions related to database systems:

  • T 1924/17 (Accenture) – Enhanced efficiency in executing structured queries in a relational database management system (RDBMS) by managing data across multiple stores with different performance characteristics was held to solve a technical problem.
  • T 0697/17 (Microsoft) – The Board held that:
    “a database management system is not a computer program as such but rather a technical system.”
    The Board recognised:
    • Data structures like indexes and query trees,
    • Components like parsers and query optimisers, and
    • Processing techniques used purposively to store and process data
      as technical features that contribute to the technical character.

Conversely, purely semantic or linguistic information retrieval methods (e.g., image retrieval by textual description, semantic similarity matrices) were deemed non‑technical in earlier cases, illustrating that “technical” has a specific, science‑and‑engineering oriented meaning.

4. Indian precedents and CRI Guidelines

The Court harmonises its reasoning with leading Indian decisions:

  • Ferid Allani v. Union of India, 2019:DHC:6944
    • Introduced the “technical effect / technical contribution” test: if a computer‑implemented invention demonstrates a technical effect or contribution, it may be patentable despite involving software.
  • Lava International Ltd v. Telefonaktiebolaget LM Ericsson, 2024:DHC:2698
    • Clarified that an invention is not a “computer programme per se” merely because it uses algorithms or computer‑executable instructions.
    • Gave the example of a smart thermostat dynamically adjusting heating/cooling based on real‑time parameters as a patentable CRI.
  • Microsoft Technology Licensing LLC v. Assistant Controller of Patents and Designs, 2023 SCC OnLine Del 2772
    • Held that a two‑tier user authentication system solved a technical problem, and reiterated that software‑based inventions must be examined for technical advancement and real‑world application.
  • Raytheon Co. v. Controller General of Patents and Designs, 2023:DHC:6738
    • Reaffirmed that for CRIs, the Patent Office must examine whether the invention delivers a technical contribution or technical effect.
  • Ab Initio Technology LLC v. Assistant Controller of Patents and Designs, 2024:DHC:708
    • Noted that a system or method enabling more efficient and faster output and communication constitutes a technical effect.
  • Microsoft MHC, 2024:MHC:2537
    • Earlier judgment by the same judge, analysing Section 3(k), the meaning of “computer programme per se”, and the interplay with Copyright Act definitions for “computer” and “computer programme”.

The Court also relies expressly on the CRI Guidelines 2025 issued by the Indian Patent Office. These include:

  • Table 1: Non‑exhaustive list of aspects indicating that an invention may not fall within the “computer programme per se” exclusion, such as:
    • Technical implementation of efficient searching, indexing, or retrieval of data from databases that improve system performance;
    • Technically optimised data synchronisation, consistency, or fault‑tolerance in distributed systems or cloud environments.
  • Table 2: Non‑exhaustive list of aspects indicating that an invention may fall within the exclusion, such as:
    • Mere automation of manual tasks without additional technical gain; and
    • Inventions whose main function is visual/textual data presentation (e.g. dashboards) without technical solutions in data handling or display.

5. Clarifying “technical”, “technical effect” and “technical advance”

The judgment tackles a key conceptual confusion: the use of “technical” in various phrases—technical effect, contribution, character, nature, and advance.

(a) Meaning of “technical”

Surveying dictionaries and EPO case law, the Court concludes that in patent law:

  • “Technical” is used in the sense of practical methods and skills in the physical and natural sciences (e.g. physics, engineering, electronics), not in the broader sense of any specialised knowledge (like law or finance).
  • Thus, methods dealing purely with linguistic or semantic aspects of information without impacting physical processes would generally be non‑technical.

(b) Technical effect / contribution vs. technical advance

  • Technical effect / contribution (relevant to Section 3(k)):
    • Focuses on what the invention does in practical, physical or engineering terms.
    • Need not be assessed against prior art; the question is whether the claimed features, taken as a whole, solve a technical problem or produce a tangible technical outcome.
  • Technical advance (relevant to Section 2(1)(ja)):
    • Requires comparison with “existing knowledge” (prior art);
    • Assesses whether the invention marks a progress over that knowledge.

6. The Court’s distilled rule under Section 3(k)

After synthesising UK, EPO and Indian authorities, the Court states its core conclusion (paraphrased):

Under Indian law, a computer‑related invention, even without novel hardware or direct impact on the internal working of a computer, is not excluded by Section 3(k) if it makes a technical contribution or has a technical effect.

The Court explicitly:

  • Aligns Indian law with the EPO’s approach, and
  • Declines to adopt the stricter UK approach (e.g. AT&T signposts) requiring direct, transformative effects on hardware or effects outside the computer system.

While acknowledging that a case‑by‑case analysis of “technical contribution” is more demanding administratively, the Court finds this a “price worth paying” to avoid unduly excluding valuable software innovations that contribute technically.

C. Applying Section 3(k) to AB Initio’s data lineage invention

1. The claimed invention: method and system for data lineage diagrams

Independent Claim 1 (method) and Claim 26 (system) can be summarised as follows:

  • Environment:
    • A metadata management system (340) storing metadata items about programmes and data;
    • A user interface (300) through which a user selects a metadata item to investigate;
    • A storage system (360) that stores multiple configuration information sets, each containing several selection specifications associated with different predetermined types (e.g. programme or data);
    • A diagram generator (320).
  • Core method:
    1. Receive a request identifying a first metadata item (e.g. a particular data field or transformation) from the UI.
    2. Retrieve a corresponding configuration information set from storage; each selection specification within this set is associated with a type (programme/data) and describes how to select related metadata items.
    3. Query the metadata management system using one or more of these selection specifications to identify a set of related metadata items.
    4. Iterate this querying process, discovering further related items across multiple “iterations” using the appropriate selection specifications (as illustrated in the judgment’s discussion of Figures 3 and 4A–4B).
    5. Generate a data lineage diagram:
      • Nodes represent programmes and data items (based on metadata);
      • Edges represent data lineage relationships (i.e., which programme consumed which data and what outputs were produced).

This allows a user to initiate complex upstream and downstream tracing of data transformations and dependencies across heterogeneous sources by simply selecting a starting metadata item.

2. Controller’s Section 3(k) finding

The Controller rejected the claims under Section 3(k) on the following basis:

  • The claims “help a user find answers to data relationship queries” and are therefore non‑technical.
  • The subject matter is a set of computer‑executable instructions implemented on a general‑purpose computer; only conventional processors and memory are disclosed.
  • All steps are carried out by a computer program; no specific hardware is claimed.
  • The program does not have a technical effect beyond “normal interactions” between program and hardware.
  • The algorithmic change is said to have no technical motivation and trivial implementation.

On this basis, the invention was labelled a “computer algorithm” falling squarely within Section 3(k).

3. Court’s evaluation: is there a technical contribution?

The Court undertakes a detailed functional analysis of how the invention operates (relying on the complete specification and Figures 3, 4A–4B, 5, 6) and identifies the following technical contributions:

  • Automated, iterative query mechanism:
    • Selection specifications associated with types of metadata (programme/data) guide the traversal of the metadata graph.
    • The system automatically performs multiple query interactions based on configuration files, retrieving different sets of related items at each iteration.
    • This replaces manual, step‑by‑step tracing by users across distributed systems.
  • Reduction of query response time and processing overhead:
    • By embedding technical logic in configuration information sets and selection specifications, the system optimises how data lineage queries are executed.
    • This produces a performance improvement in retrieving lineage information.
  • Dynamic and user‑configurable lineage diagrams:
    • The user can pose multiple ad hoc queries about different types of data relationships.
    • The system dynamically generates diagrams based on user‑defined configurations, reflecting the lineage of data through programmes and transformations.
  • Specialised technical architecture:
    • Components like the diagram generator, metadata management system interface and configuration file storage combine to implement a sophisticated data management function akin to the EPO’s conception of a database management system.

The Court recognises that the ultimate user‑facing function—presenting data lineage diagrams—has a strong cognitive dimension (it presents information to users). However, it emphasises that the technical contribution lies in:

  • How the system internally manages and retrieves data; and
  • How it structurally organises queries and configuration sets to efficiently map data lineage.

Thus, despite the informational output, there is a technical solution to a technical problem related to data management and query execution.

4. Database management systems as technical systems

Crucially, the Court explicitly adopts the EPO Board’s view in T 0697/17:

“a database management system is not a computer program as such but rather a technical system.”

Applying this logic, the Court holds that AB Initio’s invention—concerned with querying, processing, and representing metadata relationships in a structured, iterative, technically optimised manner—falls squarely within the realm of technical database management rather than being a mere non‑technical information presentation tool.

Accordingly, the Court concludes that:

  • The invention uses algorithms and computer programmes, but
  • Such use produces a technical effect by improving the efficiency and capability of the data management system.

Therefore, the invention is not excluded by Section 3(k) and must be examined on its merits for novelty and inventive step.

D. Novelty and inventive step: Section 2(1)(j) analysis

1. The prior art D1: unified view of entity relationships

D1 (US 2007/214179 A1) discloses:

  • A method and system for:
    • Searching, filtering, creating, displaying, and managing relationships between entities from a repository of data hierarchies;
    • Providing a unified view of primary and secondary entities and their relationships across multiple data sources.
  • Entities include customers, advisors, organisations, etc.
  • Entity data and relationship data are organised into data hierarchies.

Independent claims 1 and 33 of D1 (as quoted in the judgment) describe:

  • A GUI that displays a unified view of multiple entities and their relationships drawn from different hierarchies; and
  • A method for viewing and managing such hierarchies, including relationships established through intermediary entities (e.g., the “cross” relationship between two entities via a third).

For example, the judgment explains D1 in the context of:

  • A customer (Alice Lewis) with a savings account;
  • Her service advisor (James Stuart);
  • James Stuart’s supervisor (David Caldwell);
  • The system shows relationships among these individuals and others having related accounts or roles.

The focus is firmly on entities and their inter‑se relationships, not on the lineage of data items through programmes and transformations.

2. Novelty: Do D1’s disclosures anticipate AB Initio’s claims?

The Court holds that D1 does not anticipate the claimed invention:

  • D1’s “data hierarchies” are described as collections of:
    • Entity data; and
    • Relationship data about entities.
  • While D1 has a notion of “originating data source” (the initial source of a hierarchy), it does not:
    • Query a metadata management system using configuration information sets with plural selection specifications associated with types (programme/data);
    • Execute an iterative selection and retrieval process over metadata items to trace data lineage both upstream and downstream; or
    • Generate diagrams showing the lineage of data through programmes (nodes as programmes/data; edges as data lineage relationships).

Given this, all key features of AB Initio’s claims are not found in D1. The invention is therefore novel.

3. Inventive step: Would the invention be obvious to a PSITA in light of D1?

The Court treats D1 as analogous prior art since both relate to data management across hierarchies, but emphasises the difference in technical problem:

  • D1’s problem: How to create and maintain a unified view of customer‑related entities across multiple, disparate data sources.
  • AB Initio’s problem: How to trace the lineage of data items (including transformations) upstream and downstream to identify flawed data and all computations affected by it.

Even if a PSITA knew D1 and the common general knowledge, the Court reasons, such a person:

  • Would not be naturally led to design a system that:
    • Operates on metadata instead of entity data;
    • Uses configuration information sets comprising selection specifications for different types;
    • Performs an iterative, type‑dependent querying of a metadata management system; and
    • Generates a data lineage diagram showing programmes and data nodes connected by lineage edges.
  • Would thus require ingenuity beyond what D1 and common knowledge suggest.

This aligns with the structure of inventive‑step analysis articulated in earlier Indian authorities like:

  • Agriboard International LLC v. Deputy Controller of Patents, 2022:DHC:1206 – requiring:
    1. Identification of prior art disclosure,
    2. Comparison with the claimed invention, and
    3. Assessment of why the invention would or would not be obvious to a PSITA.
  • Agfa NV v. Assistant Controller of Patents, 2023:DHC:4030 – stressing the need to specify what constitutes “common general knowledge”.

The Court, therefore, finds that the AB Initio invention involves an inventive step under Section 2(1)(j).

IV. Simplifying Key Legal and Technical Concepts

1. Computer‑related invention (CRI)

A CRI typically involves:

  • A computer, network, or programmable device; and
  • At least one feature implemented by a computer program (software).

Examples: operating systems, database management systems, AI algorithms controlling physical processes, authentication systems, etc.

2. Metadata and metadata management system

  • Metadata is “data about data” – e.g., table names, column definitions, data types, transformation rules, programme dependencies.
  • A metadata management system stores and manages this metadata so that software tools can understand how data is organised, processed, and related.

3. Data lineage

Data lineage refers to the history and flow of data:

  • Where a data item came from (source systems, upstream processes);
  • What transformations it underwent; and
  • Where it was used (downstream processes and reports).

Lineage is crucial in regulated industries (e.g., finance) to understand how errors propagate and to ensure traceability and auditability.

4. Configuration information sets and selection specifications

  • A configuration information set is a stored set of rules that tells the system how to traverse metadata relationships for lineage queries.
  • Each selection specification within such a set:
    • Is associated with a predetermined type (like programme or data item); and
    • Describes which related metadata items to select and how (e.g., “from a data item of type X, follow relationships Y and Z to find related items of type A or B”).

5. Person skilled in the art (PSITA) and common general knowledge

  • A PSITA is a hypothetical person with average technical skill in the relevant field but no inventive flair.
  • Common general knowledge comprises what such a person would normally know in that field at the priority date—standard textbooks, well‑known techniques, widely practised methods.
  • For inventive step, the question is whether such a PSITA, with this knowledge, would find the claimed invention obvious.

6. Technical effect vs. mere information presentation

  • Simply presenting data in a new layout or graphical style (e.g., a dashboard) without changing how the data is processed is usually considered non‑technical.
  • If, however, the invention changes how the system stores, retrieves, or processes data—e.g., more efficient database querying, new indexing structures, optimised data synchronisation—then it may have a technical effect.

V. Impact and Implications

A. Clarified standard for Section 3(k): Indian law now firmly EPO‑aligned

This judgment is a major doctrinal step in Indian patent law for CRIs:

  • It clearly endorses the technical contribution / technical effect test as the governing standard under Section 3(k).
  • It rejects the idea that patent‑eligible CRIs must:
    • Use novel or customised hardware; or
    • Directly alter the internal working of the computer or have effects outside the computer system (as emphasised in the UK AT&T signposts).
  • It explicitly aligns Indian practice with the EPO’s two‑hurdle approach, rather than with the UK’s stricter criteria.

This alignment brings Indian examination practice closer to global norms relevant to high‑tech industries and provides greater predictability for innovators.

B. Consequences for database, analytics, and enterprise software patents

The case is particularly significant for inventions in:

  • Database management systems (e.g., indexing, query optimisation, storage strategies);
  • Data lineage and governance tools;
  • Analytics platforms that structure and process large, heterogeneous datasets; and
  • Complex enterprise software solutions (e.g., ETL tools, metadata‑driven integration frameworks).

By characterising database management systems as technical systems (in line with T 0697/17) and recognising improvements in query execution and data handling as technical, the Court opens the door for:

  • More consistent acceptance of database‑related CRIs as patent‑eligible; and
  • A clearer path for patentees to frame such inventions around their technical contributions (e.g., reduced response time, improved resource utilisation, fault tolerance), rather than just high‑level business advantages.

C. Guidance for patent drafting and prosecution strategy

The reasoning in this judgment yields several practical lessons:

  • Emphasise technical problem and solution:
    • Clearly articulate the technical problem (e.g., inefficiency of manual data‑lineage tracing, high latency in complex queries) and how the invention solves it using technical means.
  • Highlight system‑level architecture:
    • Describe components (e.g., metadata management system, diagram generator, configuration storage) and how they interact.
    • Show how these interactions improve performance or functionality.
  • Avoid presenting the invention as a mere reporting or visualisation tool:
    • Claims that focus solely on diagrams or reports without underlying technical processing improvements risk falling into the Section 3(k) exclusion as mere “presentation of information”.
  • Separate Section 3(k) arguments from Section 2(1)(j) arguments:
    • For Section 3(k): focus on technical effect/contribution in absolute terms.
    • For Section 2(1)(j): then address novelty and inventive step over prior art.
  • Use comparative law persuasively:
    • Decisions and guidelines from the EPO and other jurisdictions can be cited—as the appellant successfully did here—to show how similar inventions have been treated.

D. Institutional and doctrinal significance

Institutionally, the judgment:

  • Provides the Indian Patent Office with a detailed, judicially endorsed framework for examining CRIs;
  • Validates and integrates the CRI Guidelines 2025 into judicial reasoning;
  • Encourages Controllers to carefully separate:
    • eligibility (Section 3(k)) from
    • patentability (Section 2(1)(j)) and evidentiary requirements for common general knowledge.

Doctrinally, the decision:

  • Consolidates the “technical contribution/effect” line of authorities from the Delhi High Court and the Madras High Court’s own Microsoft MHC decision;
  • Clarifies the meaning of “technical” in patent law as tied to physical/natural sciences and engineering, not just any specialised field;
  • Shows willingness to adjust earlier reasoning (e.g., acknowledging an earlier misstep in conflating AT&T signposts), reflecting a maturing jurisprudence.

E. Remaining grey areas

Despite the clarity offered, certain areas will likely continue to generate litigation:

  • Borderline cases between technical and non‑technical features:
    • For example, recommendation systems, semantic analysis tools, or user‑interface improvements may have both cognitive and technical aspects. Courts and the Patent Office will have to determine whether the core contribution lies in technical data processing or in non‑technical mental/linguistic rules.
  • Mixing business logic with technical implementation:
    • Where inventions embed business rules (pricing, customer segmentation, etc.) in software that also has technical optimisations, disentangling the technical from the non‑technical will be critical for inventive step analysis, following approaches similar to the EPO’s “Comvik” line of cases.
  • Interface with other exclusions:
    • Section 3(m) (mental acts), 3(n) (method of playing game or doing business), and Section 3(i) (treatment methods) may intersect with CRIs in healthcare, fintech, and gaming; the precise boundaries will need further case‑law development.

VI. Conclusion

The Madras High Court’s decision in Ab Initio Technology LLC v. Controller of Patents, 2025 MHC 2579, is a landmark in Indian patent jurisprudence on computer‑related inventions. It does three things of lasting significance:

  1. Establishes a clear, EPO‑aligned test under Section 3(k)
    The Court holds that:
    • A CRI is not barred by Section 3(k) merely because it uses software and runs on general‑purpose hardware.
    • Patent‑eligibility turns on whether the invention makes a technical contribution or has a technical effect in the realm of the physical/natural sciences—such as improving data retrieval performance, resource utilisation, reliability, or enabling new technical capabilities.
    • Novel hardware or direct modification of computer architecture is not required.
  2. Clarifies the separate roles of Section 3(k) and Section 2(1)(j)
    The Court neatly separates:
    • Section 3(k): Does the invention, taken as a whole, solve a technical problem or make a technical contribution? This is assessed without reference to prior art.
    • Section 2(1)(j) & (ja): Is the invention new and does it involve an inventive step (technical advance or economic significance) over existing knowledge? This is where prior art and PSITA are relevant.
  3. Demonstrates application of the framework to a sophisticated data‑lineage system
    In applying these principles to AB Initio’s invention, the Court:
    • Recognises the invention as a technical database management solution that improves query processing and enables dynamic, user‑configurable tracing of data lineage;
    • Rejects the Controller’s characterisation of the invention as a mere algorithmic presentation tool;
    • Finds the invention novel and inventive over D1, which is confined to unified views of entity relationships and does not address data lineage among programmes and data.

For practitioners, the judgment offers a detailed roadmap for both drafting and litigating CRI patents in India. It provides comfort that genuinely technical software innovations—even those built on conventional hardware—can find protection, provided their technical contributions are clearly articulated and substantiated. At the same time, it signals that mere business automation or cosmetic data presentation, unaccompanied by substantive technical improvements, will continue to be excluded.

In sum, Ab Initio Technology LLC v. Controller of Patents significantly strengthens and clarifies India’s approach to software and database‑related patents, anchoring it in a balanced, internationally compatible, and technically grounded interpretation of Section 3(k).

Case Details

Year: 2025
Court: Madras High Court

Judge(s)

Honourable Mr.Justice SENTHILKUMAR RAMAMOORTHY

Advocates

Comments