Patching the Patent: Intellectual Property in Post-Sale Software Updates to Medical Devices in India

Introduction

A modern infusion pump, pacemaker programmer or radiology workstation is rarely a finished object at the point of sale. The manufacturer keeps changing it: firmware patches, feature unlocks, and now machine-learning models that are retrained and pushed out long after the device has left the factory. That ongoing change creates a problem Indian intellectual property law never set out to solve. When the code on a device that has already been sold is rewritten, does the rewrite create new proprietary rights? Does it risk fresh infringement? And who answers for the patient who depends on the device while all of this happens in the background?

This blog treats the post-sale software update as a legal event in its own right, one that sits across three regimes at once: the Patents Act, 1970, the Copyright Act, 1957, and the medical-device rules administered by the Central Drugs Standard Control Organisation (CDSCO). It sets out the governing provisions, examines how patent scope and copyright actually behave as software keeps changing, reviews the authorities that shape software protection in India, and then turns to what all of this means for manufacturers, hospitals, repairers and the patients at the end of the chain.

Legal Provisions

Three statutory regimes converge on the medical - device software update.

Patents. Section 3(k) of the Patents Act, 1970 keeps out of patentability “a mathematical or business method or a computer programme per se or algorithms.” A granted patent lasts twenty years from the date of filing, and the Controller General’s Guidelines for Examination of Computer Related Inventions guide how software-linked claims are read

.

Copyright. Section 2(o) of the Copyright Act, 1957 places computer programmes inside the category of “literary work,” and Section 2(ffc) defines a computer programme as a set of instructions that can make a computer perform a task. The owner’s exclusive rights to reproduce, adapt and issue copies flow from Section - 14, and protection lasts for the author’s life plus sixty years. Section 52(1) then sets out a few narrow exceptions: back-up copies, acts needed to make an independently written programme interoperable, and study of how a programme works. Pulling the other way, Sections 65A and 65B punish the circumvention of technological protection measures and interference with rights-management information.

Medical-device regulation. The Medical Devices Rules, 2017, made under the Drugs and Cosmetics Act, 1940,10 apply to these products ever since a 2020 notification folded medical-device software into the definition of a “drug.” On 21 October 2025 CDSCO issued a Draft Guidance Document on Medical Device Software that separates Software in a Medical Device (SiMD) from Software as a Medical Device (SaMD), and for the first time speaks directly to post-approval changes and algorithm-change protocols. Two further layers sit on top: the Digital Personal Data Protection Act, 2023 and its 2025 Rules, which govern the telemetry and health data such devices collect, and the Department of Consumer Affairs’ right-to-repair framework, which supplies the consumer angle.

Legal Analysis

The patent monopoly does not stretch to fit the update

It is tempting to assume that pushing out an update somehow refreshes the patent on the device. It does not. The parent patent expires twenty years after it was filed, no matter how many improvements reach the field later. An update can still matter for patent purposes, but in a different way: it may itself be a new invention. Suppose a post-sale patch adds a genuinely novel and inventive technical feature, say a closed-loop dosing algorithm that measurably improves how the pump’s hardware performs. The maker can apply for a separate patent on that feature, with its own twenty-year clock starting from its own priority date. Clearing the bar is not easy. Section 3(k) shuts out computer programmes per se, so the update has to satisfy the “technical effect” test that the courts have read into those words. Software that merely automates an abstract task stays excluded; software that delivers a real technical improvement to the device or system can be patented. The system, in other words, rewards the update for being inventive, not for being an update.

Copyright renews far more readily than patents

Copyright works on a different logic. Source code and object code are both protected as literary works, so each substantial rewrite of the firmware is a fresh literary work in its own right, or an adaptation of an earlier one, and it attracts copyright the moment it is written down. The practical effect is striking. A device can be well past the life of its patents and still run firmware that is squarely protected by copyright, and every new update tops up that protection. The control this gives is real but limited. Copyright reaches the expression of the code, not the function it performs, which leaves a rival free to write its own code that does the same clinical job. The interoperability and study exceptions cut the monopoly down a little further, since someone who lawfully holds the software may reverse-engineer it within limits to make their own product work with it. The catch is the anti-circumvention rules. A biomedical engineer in a hospital, or an independent repairer, who breaks a technological lock can run into liability under those rules even when the goal is an ordinary repair.

New rights, and new exposure to infringement

So a single update can hand the manufacturer new rights and, at the same moment, expose it to new claims. The rights are easy to see: fresh copyright in the rewritten code, and, if the technical bar is met, a possible new patent. The exposure is less obvious. An update can infringe someone else’s IP for the first time, because a feature added after sale may suddenly read on a competitor’s patented method and turn a device that was perfectly lawful when sold into an infringing one out in the field. There is a flip side on the manufacturer’s own conduct. A maker that uses updates to switch off interoperable consumables, slow the device down, or block third-party servicing may attract attention under right-to-repair thinking and, in some cases, competition law. Patients and repairers face the mirror image: someone who alters the firmware to bring back a disabled function may infringe the maker’s copyright or fall foul of the anti-circumvention rules, however good the safety reason.

Safety makes the update a regulated event, not merely a proprietary one

Medical devices carry an extra layer that ordinary software does not. Here the update is not just an IP event; it is a regulated one. CDSCO’s 2025 draft guidance treats embedded firmware (SiMD) as taking the risk class of the device it lives in, while standalone SaMD is graded on its own from Class A to Class D according to clinical risk. Changes run through the Rules’ change-control structure. A significant change can need prior approval, and a change that shifts the device’s intended use or its risk class can trigger a fresh licensing step. For AI and machine-learning tools the guidance allows an Algorithm Change Protocol, so pre-authorised model updates can be rolled out and reported instead of re-licensed every time, with cybersecurity-vulnerability reporting and periodic safety reports alongside. The upshot is plain. A manufacturer cannot use IP or a tightly drafted licence as cover for holding back a safety-critical security patch, and it cannot push a functional change without clearing it with the regulator. Exclusive rights and patient safety end up tied to the same lifecycle.

Case Laws

Ferid Allani v. Union of India is still the reference point for software patentability in India. The Delhi High Court held that a computer-related invention is not caught by Section 3(k) once it shows a technical effect or technical contribution, and it noted that almost every product made today carries some computer programme inside it.15 The court returned to the same reasoning in Microsoft Technology Licensing, LLC v. Assistant Controller of Patents, refusing to read the section as a blanket bar on computer-related inventions.16 For a medical-device update, the takeaway is direct: whether the logic in an update can be patented depends on the technical contribution it actually makes to the device.

The copyright authorities pull in a complementary direction. In Tata Consultancy Services v. State of Andhra Pradesh the Supreme Court accepted that software carries intellectual property worth protecting, and placed code within the wider IP setting. Microsoft Corporation v. Yogesh Papat shows the enforcement side, with the Delhi High Court awarding relief and damages against the unauthorised installation of, and dealing in, the plaintiff’s software. R.G. Anand v. Delux Films marks the outer limit, as the leading statement of the idea-expression dichotomy: copyright protects the expression, not the idea or the function behind it, which is exactly the question when a rival writes its own firmware to do the same thing.

One foreign decision is worth a mention, even though it does not bind Indian courts. In Google LLC v. Oracle America, Inc. the United States Supreme Court treated the reuse of software interfaces for compatibility as fair use.20 That is a useful signal on the interoperability problem updates keep raising, and Indian courts may weigh it when they set the interoperability exceptions against a maker’s proprietary claims.

Practical Implications

For manufacturers, the update calls for an IP strategy that is layered and honest about what each right can do. Copyright and trade-secret protection cover the codebase; patents are best kept for features that are genuinely inventive in a technical sense; and end-user licences should stop short of the ground the safety regulator already occupies. The harder shift is that IP planning now has to move in step with CDSCO’s post-approval-change and algorithm-change obligations, because an update that looks routine from a product standpoint can be significant from a regulatory one. Handling cybersecurity reports and filing periodic safety updates, both flagged in the 2025 draft guidance, become standing compliance tasks, and any telemetry gathered through an update brings the Data Fiduciary duties of the DPDP regime into play.

Hospitals, biomedical-engineering teams and independent repairers get some room from the interoperability and study exceptions, but warranty terms, licence restrictions and the anti-circumvention rules keep that room narrow. The everyday risk is concrete: a vendor update that “bricks” or quietly downgrades a device, or a product line that is discontinued and simply stops receiving security patches, lands as both a clinical and a financial problem for the people running the equipment.

On policy, the clash between intellectual property and the right to repair bites hardest in healthcare, where an update that is held back can put a patient in danger. India’s right-to-repair framework has not really reached medical devices yet, and nothing clearly stops a maker from using a technological lock to keep others out of safety-relevant servicing. The lifecycle approach in the 2025 draft guidance, especially the Algorithm Change Protocol and the post-market-surveillance expectations, is a step in the right direction, because it treats changing software as an ongoing duty rather than a one-off approval. As AI and machine-learning SaMD spread and over-the-air updates become normal, in line with International Medical Device Regulators Forum (IMDRF) practice, these questions will only get sharper.

Conclusion

The post-sale update reveals a mismatch built into Indian law. Patent scope is narrow and runs out on a fixed clock, so it will not stretch to cover ordinary updates unless they are inventive on their own. Copyright is wide and renewable, which lets firmware stay proprietary long after the patents have gone. And the safety regime is moving towards treating every meaningful update as a regulated change. Put side by side, the more convincing reading is that an update creates new rights and new infringement risk together, and that neither can be judged without the regulatory layer that medical devices alone carry.

Three changes would help these regimes fit together. First, the law could state plainly that technological protection measures and licence terms must not be used to block safety-critical security updates or the legitimate repair of medical devices. Second, India could build a right-to-repair carve-out designed for medical devices, with guaranteed access to security patches for as long as the device stays in clinical use. Third, IP India and CDSCO could work in tandem, so that one update is assessed coherently as both an IP event and a regulated change. Until that happens, manufacturers, clinicians and patients are left to work across three regimes that, for now, barely talk to each other.

Author: Vaishnavi.M, in case of any queries please contact/write back to us via email to chhavi@khuranaandkhurana.com or at  Khurana & Khurana, Advocates and IP Attorney.

References

1. The Patents Act, 1970, § 3(k), No. 39, Acts of Parliament, 1970 (India).

2. The Patents Act, 1970, § 53 (India).

3. Office of the Controller Gen. of Patents, Designs & Trade Marks, Guidelines for Examination of Computer Related Inventions (CRIs) (2017) (India).

4. The Copyright Act, 1957, § 2(o), No. 14, Acts of Parliament, 1957 (India).

5. The Copyright Act, 1957, § 2(ffc) (India).

6. The Copyright Act, 1957, § 14 (India).

7. The Copyright Act, 1957, § 22 (India).

8. The Copyright Act, 1957, § 52(1)(aa)–(ad) (India).

9. The Copyright Act, 1957, §§ 65A–65B (India).

10. The Medical Devices Rules, 2017, G.S.R. 78(E) (Jan. 31, 2017), framed under the Drugs and Cosmetics Act, 1940 (India).

11. Ministry of Health & Family Welfare, Notification No. S.O. 648(E) (Feb. 11, 2020) (India).

12.  Cent. Drugs Standard Control Org., Draft Guidance Document on Medical Device Software (Oct. 21, 2025) (India).

13. The Digital Personal Data Protection Act, 2023, No. 22, Acts of Parliament, 2023 (India); Digital Personal Data Protection Rules, 2025, G.S.R. 846(E) (Nov. 13, 2025) (India).

14. Dep’t of Consumer Affairs, Gov’t of India, Right to Repair Portal (2022).

15. Ferid Allani v. Union of India, 2019 SCC OnLine Del 11867 (India).

16. Microsoft Tech. Licensing, LLC v. Assistant Controller of Patents & Designs, C.A. (COMM.IPD-PAT) 29/2022 (Del. High Ct. 2023) (India).

17. Tata Consultancy Servs. v. State of Andhra Pradesh, (2005) 1 SCC 308 (India).

18. Microsoft Corp. v. Yogesh Papat, (2005) 118 DLT 580 (Del.) (India).

19. R.G. Anand v. Delux Films, (1978) 4 SCC 118 (India).

20. Google LLC v. Oracle Am., Inc., 593 U.S. 1 (2021).