Freedom to Operate for Software and AI Models: Why the Old Playbook Doesn't Fit
If you have done freedom to operate work on a physical product, you know the rhythm. You get a product description, maybe a bill of materials, maybe a prototype on the table. You find patents that could be relevant, pull their independent claims, and build a chart. Each claim element goes on the left, the matching product feature goes on the right. If even one element has no counterpart, the claim isn't infringed. It is orderly, repeatable, and easy to explain to a board.
Now try handing that process to a team shipping a machine learning product. The first thing you notice is that the chart has nothing solid to point at.
That is the real problem with FTO for AI. The patents are still patents, and the law hasn't changed. What breaks is the assumption underneath the method: that the product is a fixed thing you can inspect and compare against words on a page.
The product keeps moving
A conventional product has a design freeze. You can say "this is the thing we are selling" and mean it. A model is different. It gets retrained on fresh data, fine tuned for a new customer, quantized for a smaller device, and wrapped in new prompts or retrieval layers every few weeks. Is the accused product the architecture, the trained weights, the training pipeline, or the deployed service? The honest answer is all of them, at different moments.
An FTO opinion written against last quarter's system may say very little about this quarter's. Teams often don't realize this until an engineer casually mentions, in the middle of a review meeting, that they swapped the ranking component a month ago.
Claims are written at a different altitude
Mechanical claims tend to describe structure. A bracket, a gear ratio, a specific arrangement of parts. Software and ML claims often describe function and flow: receiving data, generating a representation, training a model to minimize some objective, outputting a prediction.
That sounds precise but isn't. Words like "model," "feature," "embedding," "representation," and "training data" don't have one settled meaning across the field. A claim written in 2018 around a "neural network" has to be read against what that phrase meant then, and a lot has changed since. A transformer, a diffusion model, a gradient boosted ensemble and a small classifier hiding in a pipeline might all arguably fall inside one broad claim term, or none of them, depending on how a court construes it.
So the claim construction step, which is a quiet background task in a mechanical FTO, becomes the main event. Most of the real analysis lives in the question of what the words mean, not in the matching.
You often can't see inside the thing you are mapping
There is an awkward irony here. Even for your own product, the people doing the legal analysis often can't see what the system actually does. Model behavior emerges from data and training, and the engineers themselves may describe it in loose terms. Ask three people on the same team how the recommendation system works and you may get three slightly different answers.
If you are assessing someone else's product, it is harder still. Weights are opaque, training data is secret, and the architecture might only be hinted at in a blog post. That matters for FTO because the risk isn't just whether you infringe. It is also whether anyone could realistically prove it, and whether they could even find out. Those practical questions shape how a patent holder behaves, and they deserve a place in your risk view.
Infringement is spread across actors and places
Many claims in this field are method claims, and a method claim requires every step to be performed. In an ML system, the steps are rarely done by one party in one place. Data is collected by one entity, a model is pretrained by another, fine tuned by a third, hosted in a cloud region somewhere else, and called through an API by an end user in a different country.
In the US, direct infringement of a method claim generally requires that all steps be performed by, or attributable to, a single party. That doctrine of divided infringement can protect you in some cases and expose you in others, depending on contracts, control, and who directs whom. Territorial limits add another wrinkle. Training in one country and serving in another can change which national patents are even relevant.
A traditional chart doesn't capture any of this because it asks "does the product meet the claim," when the more useful question is "who does each step, where, and under whose control."
The stack is built on other people's work
Almost no one builds a model from nothing. There is an open source framework, a pretrained base model, a public dataset, a cloud provider, maybe a third party API for one capability. Each layer arrives with its own license terms, and not all of them say anything about patents.
Some permissive licenses include an express patent grant, though those grants usually fall away if you start suing over the code. Other model licenses are silent on patents, or carry usage restrictions that complicate things. A team can do a flawless claim analysis and still be exposed because nobody read the license on the pretrained checkpoint. FTO for AI is partly a supply chain exercise.
What to do instead
None of this means FTO is impossible for AI. It means the method needs adapting. Here is what has worked in practice.
Start with a proper technical walkthrough, and treat it as a living document. Before searching anything, sit with the engineers and draw the system. What data comes in, where, and from whom? What gets trained, by whom, on what infrastructure? What runs at inference, and where? What happens to outputs? Capture it as a diagram plus a short written description, and date it. This replaces the physical prototype you would otherwise point at. Then agree on triggers for refreshing it, such as a new model architecture, a new deployment region, or a new data source.
Break the system into stages and actors. Instead of one big chart against one product, look at the pipeline stage by stage: collection, preprocessing, training, fine tuning, deployment, inference, post processing, feedback. For each stage, note who performs it and in which jurisdiction. When you later review a patent, you can see quickly which stage its claims touch and whether your company is even the one performing it.
Search by problem and function, not by buzzword. Patent drafters in this area use wildly different vocabulary for the same idea. A search built around "transformer" will miss claims that say "attention based sequence model" or "neural encoder." Think about what the system accomplishes and describe it three or four different ways. Use classification codes as a starting point, but don't stop there. Look at the portfolios of the companies most active in your space, and keep an eye on pending applications and continuations, since the claims you worry about today might not be the claims that issue next year.
Spend more time on claim construction and flag the soft terms. Instead of forcing a yes or no on every element, annotate the ambiguous ones. If a claim hinges on "a trained model" and the term could plausibly be read narrowly or broadly, say so, and show how the analysis changes under each reading. Look at the specification and prosecution history to see how the applicant themselves described it, since narrowing statements made to get the patent allowed can limit its reach.
Use the means-plus-function angle when it appears. In the US, claim language that recites a function without enough structure, such as a "module configured to classify," can be construed under Section 112(f) as limited to the algorithm disclosed in the specification and its equivalents. For software patents this can shrink a seemingly sweeping claim to something much narrower. It is one of the more useful tools in this area, and it is easy to overlook if you are only reading claims in isolation.
Sort claims by type and by who would infringe. Method claims, system claims, and computer readable medium claims behave differently. A system claim might be infringed by whoever provides the deployed service. A training method claim might sit with whoever runs the training job. Knowing which type of claim you are looking at tells you whether your company, your vendor, or your customer is the one at risk, and that tells you where contracts and indemnities matter.
Use a graded view of risk instead of a binary one. Clear, not clear is too blunt here. A more helpful output is a short ranking: patents that read closely on what you do, patents that could read on you under a broader construction, and patents that need a design change or a closer look at the facts. Pair each with a note about the owner. A patent held by an operating competitor, an aggressive licensing entity, or a university technology office presents different practical risk even when the claim coverage looks similar.
Make the design flexibility work for you. One real advantage in ML is that the system is often modular. You may be able to change the loss function, the architecture, the order of steps, or where a computation runs without damaging the product. If a patent looks threatening, ask the engineers what a workaround would cost. Sometimes the answer is a two week change. Just keep in mind the doctrine of equivalents, because a tweak that looks different on the whiteboard may still fall within the reach of a claim.
Look at validity and eligibility, but don't lean on them as clearance. In the US, subject matter eligibility challenges under Section 101 have knocked out plenty of software claims. In India, Section 3(k) and its guidelines on computer programs, and in Europe the focus on technical effect, shape what gets granted and what survives. These doctrines are useful for assessing how strong a patent is. But an eligibility argument is a litigation position, not a clearance. It costs time and money to run, and outcomes vary. An FTO opinion that says "we're fine because the claims are probably abstract" isn't much of an opinion.
Read the licenses and contracts as part of the FTO. For every third party component, check what rights come with it. Does the license include a patent grant? Does it terminate under certain conditions? Does the vendor offer an indemnity, and does it cover the way you actually use the product? Flag the gaps and take them to the people negotiating the deals.
Make it a process, not a document
The deeper change is that FTO for AI works better as an ongoing practice than a one time report. The product changes, the patent filings change, and your architecture changes. A static PDF written in March tells you very little in September.
A lightweight rhythm helps. Keep a current system description. Run periodic watches on the key technical areas and the key players. Review when something significant changes. Keep legal and engineering in the same conversation, because the most important facts for FTO sit in the heads of people who don't usually attend legal meetings.
None of this makes the work less rigorous. If anything, it asks more of everyone involved, because you can't hide behind a tidy claim chart when the underlying product refuses to hold still. But teams that adapt end up with something more useful than the old format ever delivered: a clear picture of where the real exposure sits, and a plan for what to do about it.
This article is general commentary and not legal advice. Specific FTO questions should go to a qualified patent attorney in the relevant jurisdictions.
Comments