Akamai, AI, and the Three Layers of Liability: Why Your First Drafting Decision Must Be Who You Want to Sue

In 2014, the U.S. Supreme Court decided Limelight Networks, Inc. v. Akamai Technologies, Inc., 572 U.S. 915 (2014). The case had nothing to do with neural networks or large language models. It was about content delivery networks and a tagging step for cached web content. But if you draft or litigate AI patents, you are living in Akamai’s world whether you like it or not.

At the core of the Akamai line of cases is a deceptively simple rule:

A method claim is directly infringed only when all of the steps are performed by, or attributable to, a single actor.

That rule is devastatingly important for AI systems, because modern AI pipelines split behavior across multiple actors:

• Training (model developers, labs, foundation model companies)
• Inference and serving (cloud platforms, SaaS providers, product companies)
• User interaction (end users supplying prompts, images, and data)

Put bluntly: if your AI claim requires more than one of those actors to perform claimed steps, you may have no direct infringer at all, even if the accused system is obviously using your technology.

And there’s a deeper, rarely discussed strategic fork. For training-related inventions, are you trying to sue (1) the people who perform the training, or (2) the people who use a model trained with your inventive method? You cannot reliably do both with one method claim, and that choice should drive the architecture of the entire claim set.

This article walks through the case law, the three-layer AI stack, and then that strategic decision, with sample claim patterns for both “trainer” and “trained-model user” targeting.

The divided-infringement backdrop: Akamai and friends

U.S. patent law has been wrestling with “divided infringement” for nearly two decades: what happens when different parties perform different steps of a claimed method? Direct infringement under 35 U.S.C. § 271(a) requires that every step of a method claim be performed, and a series of Federal Circuit decisions, capped by Akamai, sets out when steps performed by different parties can be attributed to one of them.

BMC Resources, Inc. v. Paymentech, L.P., 498 F.3d 1373 (Fed. Cir. 2007)

In BMC, different entities performed different parts of an electronic payment method. The Federal Circuit held that the defendant wasn’t liable because it neither performed all the steps nor directed or controlled the other entities that did. The case firmly planted the idea that split performance usually defeats direct infringement.

Muniauction, Inc. v. Thomson Corp., 532 F.3d 1318 (Fed. Cir. 2008)

Muniauction involved a web-based auction system where some steps were performed by the system provider and others by bidders using the system through a browser. The Federal Circuit held that controlling access to a system and instructing customers on its use was not enough “direction or control” to attribute the customers’ actions to the provider. That’s a direct analog to today’s AI products: a hosted platform plus lots of user input.

McKesson Technologies Inc. v. Epic Systems Corp. (Fed. Cir. 2011)

In McKesson, some steps of an electronic communication method were performed by healthcare providers and others by patients using an online portal. The panel refused to find infringement because no single party performed all steps or directed or controlled the others. That panel decision was later vacated, and the case was decided together with Akamai by the en banc court in 2012, but the fact pattern remains a useful illustration of how provider-and-user methods fail.

Limelight v. Akamai (U.S. 2014; Fed. Cir. en banc 2015)

In Limelight v. Akamai, Limelight performed most steps of a CDN method but left the “tagging” step to its customers. The Supreme Court held that induced infringement under § 271(b) requires an underlying act of direct infringement, which in turn requires that all steps be attributable to a single entity under § 271(a). 572 U.S. at 921–22.

On remand, the en banc Federal Circuit broadened when other parties’ acts can be attributed to an accused infringer. Akamai Techs., Inc. v. Limelight Networks, Inc., 797 F.3d 1020 (Fed. Cir. 2015) (en banc). One entity is responsible for others’ performance of method steps where it directs or controls that performance, including where it:

• conditions participation in an activity or receipt of a benefit on performance of a step, and
• establishes the manner or timing of that performance,

or where the actors form a joint enterprise. Later cases applied that test to find direct infringement where, for example, a drug label conditioned a benefit on patients performing a step in a manner and at a time set by the physician. Eli Lilly & Co. v. Teva Parenteral Medicines, Inc., 845 F.3d 1357 (Fed. Cir. 2017).

But the practical message for everyday drafting is unchanged:

If your claim reads on conduct distributed across independent actors, you’re in serious trouble unless one of them clearly directs or controls the rest, or they form a joint enterprise.

For AI, where the layers naturally separate across different companies and users, that’s a structural problem.

The three-layer AI stack (and where Akamai bites)

Most modern AI systems can be decomposed into three layers:

1. Training layer: model creation, pretraining, fine-tuning, RLHF, and similar.
2. Inference layer: serving the trained model, processing requests, returning outputs.
3. User interaction layer: prompts, uploaded data, UI selections, consumption of output.

Each layer tends to involve a different actor. A model developer or lab does the training. A cloud platform or product company runs inference. The end user initiates requests, supplies data, and uses results.

Whenever a single method claim spans multiple layers, you’ve likely triggered Akamai’s divided-infringement problem. That’s why a modern AI claim strategy should be built around layer-specific, actor-specific claim sets instead of one monolithic “end-to-end” method.

The most underrated strategic fork: trainer vs. user of the trained model

Nowhere is this more important than in training-related inventions. Whenever your novelty lives in how a model is trained, you face a fundamental question. Do you want to sue:

• the trainer who performs the training steps, or
• the user of a model that has been trained using your inventive method?

You architect claims very differently depending on the answer. You generally cannot safely target both in a single method claim without inviting divided infringement, because training and inference are so often done by different parties.

Option 1: Target the trainer with training method claims

Here you go after the actor who actually runs the training process: foundation model companies (OpenAI, Anthropic, Google DeepMind, Meta, and others), specialized labs doing domain-specific fine-tuning, and enterprises running internal pretraining or adaptation pipelines.

The claim is a method of training a model, with all training steps performed by one actor:

• receiving and preprocessing training data
• initializing parameters
• computing losses and gradients
• applying a particular optimization, regularization, or constraint
• updating parameters and outputting a trained model

If your claims stay entirely inside the training loop, you’re usually safe under Akamai and its predecessors because one entity performs every step.

Upside:

• Clean single-actor infringement by the trainer.
• Often technically rich and less vulnerable to an abstract-idea challenge.
• A good fit for licensing training procedures.

Downside:

• Once training is done, downstream inference by others does not infringe the training method claim.
• You may have limited leverage against pure model deployers who never run your training regimen.
• Training performed outside the United States generally doesn’t infringe a U.S. method claim, and importing the resulting model may not be reachable under § 271(g), which the Federal Circuit has limited to physical products rather than information. Bayer AG v. Housey Pharms., Inc., 340 F.3d 1367 (Fed. Cir. 2003).

This option is best when your economic theory is: “The training technique itself is the crown jewel.”

Option 2: Target the user of a model trained using your method

Sometimes the bigger prize is not the training lab but the large ecosystem of platforms and products that deploy the trained model: API providers and SaaS platforms, enterprises integrating the trained model into workflows, and device manufacturers running on-device inference.

The problem is that those entities didn’t perform the training steps. So how do you reach them without running into Akamai?

The key move: stop claiming training steps and characterize the trained model

Instead of claiming “a method of training comprising steps A, B, C,” you:

1. describe the trained model in structural or functional terms that result from the inventive training process, and
2. draft claims to using that trained model (method, system, and CRM claims) in which all steps are performed by the infringer.

Example approaches to characterizing the model:

• “a neural network whose parameters satisfy constraint X”
• “a model including a representation subspace learned under loss function Y with property Z”
• “a model exhibiting an error distribution property, sparsity pattern, or architectural configuration traceable to your method”
• “parameters obtained by optimizing under [a specific constraint or schedule]” (use with care; see below)

Now the affirmative steps in your claims are all inference-side, performed by the entity deploying the model, but the patentable weight of the claim sits in what the training produced.

Prefer structure over process language. A limitation that defines the model by how it was made (“obtained by,” “trained by”) is product-by-process language. For infringement, the process terms limit the claim, so you would still have to prove the accused model was made by that process. Abbott Labs. v. Sandoz, Inc., 566 F.3d 1282 (Fed. Cir. 2009) (en banc in relevant part). For patentability, the examiner can still reject the claim over a prior-art model that is the same or obviously similar, however it was made (MPEP § 2113). A measurable property that the inventive training produces is usually the stronger hook.

Upside:

• You can reach downstream users even if they didn’t do the training.
• Infringement recurs every time the model is run.
• You can align infringement with where value is monetized (APIs, SaaS, embedded products).

Downside:

• You must describe the model in a way that’s definite and detectable, and supported by the specification.
• You must avoid drifting into pure abstraction (“a model that works better”) without concrete structure or technical effect. Claims that merely apply generic machine learning to a new data environment remain vulnerable under 35 U.S.C. § 101. Recentive Analytics, Inc. v. Fox Corp., 134 F.4th 1205 (Fed. Cir. 2025); see MPEP § 2106.05(a).
• Discovery and proof can be more complex.

This strategy fits when your economic thesis is: “The real money is in the use of the trained model, not in the training itself.”

Why you rarely want training and inference steps in a single method claim

Suppose you write a method claim like this:

• Steps 1–4: training a model using a novel regime (performed by Company A)
• Step 5: using the trained model to serve user queries (performed by Company B)
• Step 6: the user acts on the output (performed by End User C)

That is textbook divided infringement under BMC, Muniauction, and Akamai: no single actor performs all steps, and often there is no direction-or-control relationship strong enough to attribute them to one party.

In some fact patterns, you can argue conditioned participation or joint enterprise under the en banc Akamai test. But you do not want the enforceability of your core AI patents to hinge on that.

Rule of thumb: training steps and inference steps should usually live in different method claims, directed to different infringers. Use training method claims for trainers. Use trained-model and inference claims for model users.

Layered claiming: training, inference, and user interaction

Once you adopt an actor-aligned mindset, the broader claim strategy for AI patents becomes clearer.

Training layer: targeting trainers

• A method of training a machine learning model.
• A system configured to train the model.
• A CRM storing training instructions.
• Architecture claims whose novelty arises from the training regime.

All steps are performed by one actor.

Inference layer: targeting server operators and integrators

• Methods “performed by a server system” or “at a computing system.”
• System claims with a processor executing a trained model.
• A CRM storing inference code.

User actions are recast as “receiving data from a client device,” not as user-performed method steps.

User interaction layer: targeting devices and integrators, not end users

• System or device claims (for example, a wearable, a vehicle, or a sensor platform) that use the model.
• Avoid method claims in which end users must perform steps.
• Treat user interactions as signals and data, not steps in the method.

Example claim sets: trainers vs. users of the trained model

Below are illustrative claim patterns you can adapt. They’re simplified to highlight structure and infringer alignment.

A. Claim set targeting the trainer (training method strategy)

Independent claim 1: method of training (the trainer is the infringer)

1. A computer-implemented method of training a machine learning (ML)
   model, the method comprising:
     receiving, by one or more processors, a training dataset comprising
       input-output pairs, wherein each input-output pair includes an
       input and a target output;
     initializing, by the one or more processors, one or more parameters
       of the ML model; and
     for each batch of the training dataset:
       generating, by the ML model and for each of the input-output pairs,
         a predicted output based on the input of the input-output pair;
       for each of the input-output pairs, computing a loss value based on
         a difference between the predicted output and the target output;
         and
       updating the one or more parameters of the ML model using the loss
         value and an optimization algorithm;
     wherein [CHARACTERIZATION].

This is an exemplary structure that recites each of the main training steps. In practice, consider whether you need to recite each of these steps, and how the characterization of the training or the ML model itself should be recited.

Key points:

• Every step is performed by one entity (the training operator).
• There is no user, no client device, and no separate inference actor.
• Akamai risk is minimal because a single actor performs every step.

Claim 2: training system

2. A system, comprising:
     one or more processors; and
     one or more memory devices storing instructions that, when executed
       by the one or more processors, cause the system to perform the
       method of claim 1.

Claim 3: training CRM

3. A non-transitory, computer-readable medium storing instructions that,
   when executed by one or more processors, cause the one or more
   processors to perform the method of claim 1.

Together, claims 1–3 form a traditional training-focused claim set targeting the actor who actually runs the training. Claims 2 and 3 refer back to claim 1 for brevity. Many practitioners instead write the system and CRM claims out in full as independent claims, which avoids any dispute over whether a claim in a different statutory category is a proper dependent claim under 35 U.S.C. § 112(d) and how it is counted for fees.

B. Claim set targeting users of the trained model (trained-model and inference strategy)

Now assume you want to reach platforms and products that deploy the trained model, even if they never touched the training code. You shift to model characterization and inference claims.

Independent claim 4: the trained model as a product

4. A trained machine learning (ML) model stored on a non-transitory
   computer-readable medium, the trained ML model comprising:
     a plurality of layers including an intermediate representation
       layer; and
     a plurality of parameters associated with the plurality of layers,
     wherein the plurality of parameters have been trained such that
       activations at the intermediate representation layer satisfy
       [STRUCTURAL OR FUNCTIONAL PROPERTY Y] that results from
       application of [CHARACTERIZATION X] during training.

This is one of many possible ML model claims. Frame your particular technology first, and let that dictate the language.

Notes:

• No training steps are claimed.
• The novelty is embodied in property Y, which arises from your inventive training method. Ideally, property Y can be detected in the accused model without proving how it was trained.
• Infringement occurs by making, using, selling, offering to sell, or importing the trained model under § 271(a), not by performing training steps.

Independent claim 5: inference method using the trained model (the server operator is the infringer)

5. A computer-implemented method performed by a server system, the
   method comprising:
     receiving, at the server system from a remote client device, an
       input data object;
     processing, by the server system, the input data object using the
       trained ML model of claim 4 to generate an inference output; and
     transmitting, from the server system to the remote client device, a
       response message comprising data derived from the inference
       output.

Key Akamai features:

• All steps are performed “by a server system.”
• The client or user is only a source and sink of data; they do not perform claimed steps.
• The infringer is the operator of the server that runs the model of claim 4.

Independent claim 6: system claim (broadening the target to integrators)

6. A system, comprising:
     a communication interface configured to exchange data with one or
       more remote client devices;
     one or more processors; and
     one or more memory devices storing:
       (i) the trained ML model of claim 4; and
       (ii) computer-readable instructions that, when executed by the one
            or more processors, cause the system to:
              receive, via the communication interface, an input data
                object from a remote client device;
              process the input data object using the trained ML model to
                generate an inference output; and
              provide, via the communication interface, a response
                message based on the inference output to the remote
                client device.

Now you’re targeting any entity that makes, uses, or sells a system implementing the trained model.

Claim 7: CRM for inference

7. A non-transitory, computer-readable medium storing instructions that,
   when executed by one or more processors of a server system, cause the
   server system to perform the method of claim 5.

Together, claims 4–7 form a trained-model and inference claim set aimed squarely at model deployers, not trainers, while staying Akamai-safe by keeping each method claim’s steps within a single actor (the server system).

How this all fits together in a real portfolio

A sophisticated AI patent family might include all of the following:

Each group is actor-aligned:

• Trainers infringe training methods.
• Model users infringe by making, using, or selling models and systems embodying the trained model.
• No claim requires multiple independent actors to complete all steps.

That is what it means, in practice, to draft AI claims that survive Akamai. If you can’t afford to pursue every group in the first application, file the specification so it supports all of them, and pursue the rest in continuations. Our article on preserving support and priority when filing the non-provisional covers how to do that.

Closing thoughts

In light of Akamai, AI patent drafters need to think like systems engineers and litigators at the same time:

• Who actually performs each step?
• Which company controls which layer?
• Do I want to sue the training lab, the cloud platform, the product company, or the end user?

For training-heavy inventions in particular, your first real drafting decision should be:

Am I targeting the trainer, the SaaS entity hosting the trained model, or the user of the trained model?

Once you answer that, your claim architecture, whether a training method or a trained model with inference claims, almost writes itself.

If you mix layers and actors in a single method claim, the divided-infringement cases (BMC, Muniauction, Akamai) are waiting for you. If you align claims to one actor per claim across the training, inference, and interaction layers, you can build AI portfolios that are both technically meaningful and actually enforceable.

This article was originally published on our Medium blog on March 17, 2026, and has been updated with additional citations.