Chapter 6: Necessary Claims: The Heart of Patent Policy

Every patent policy in every standards body revolves around one concept: necessary claims. Sometimes called essential claims, these are the patent claims that an implementer cannot avoid when building to a standard. If there's an alternative way to achieve the same result without practicing the claim, it's not a necessary claim — because competition among alternatives keeps pricing and licensing terms in check. But if there is no alternative, the patent holder has a monopoly created by the standard itself, and without the constraints of a patent policy, could abuse that position through unreasonable pricing, onerous terms, or injunctions.

This is the problem that RAND and royalty-free commitments solve. They restore the results of competition — reasonable pricing, accessible terms — in situations where the standard has effectively removed competition. The necessary claims definition is the mechanism that determines when those commitments apply.

6.1 The Logic: Blocking Patents and Market Discipline

In a normal market, competition among alternative technologies imposes discipline on patent holders. If someone holds a patent on one approach, an implementer can design around it, license a competitor's alternative, or build something different. The availability of alternatives keeps pricing and licensing terms reasonable — not because the patent holder is generous, but because the implementer has options.

Standards remove those options. When a technology is embedded in a standard, every implementer must use it. There is no designing around it — the standard says do it this way. A patent holder whose claims read on "this way" could, without a patent policy commitment, abuse that monopoly position: charge whatever they want, impose onerous terms, seek injunctions, or simply refuse to license. The implementer has no alternative and no leverage.

RAND and royalty-free commitments act to restore the results of competition. Even though the standard has eliminated competing approaches, the patent policy requires the patent holder to behave as if competition still existed — offering licenses on reasonable terms (in RAND) or at no charge (in royalty-free). The necessary claims definition determines when this obligation kicks in: only for claims that are truly unavoidable. Where alternatives exist, market forces do the work on their own.

This is why standards focus on the what, not the how. A specification describes the interface — the format of the data, the protocol for communication, the expected behavior. It generally does not prescribe how the implementation achieves those results internally. A number-sorting standard might say: accept a series of numbers, return them sorted lowest to highest. It doesn't say use bubble sort or quicksort. A patent on bubble sort wouldn't be a necessary claim because the implementer can choose a different algorithm. A patent on the act of sorting numbers in the format specified by the standard — if such a patent existed and couldn't be avoided — would be.

6.2 Parsing the Definition

The typical necessary claims definition reads something like: "claims of patents or patent applications, owned or controlled by a member or its affiliates, now or at any time in the future, that would necessarily be infringed by an implementation of the specification."

"Claims of patents or patent applications"

The commitment covers both issued patents and pending applications. This is intentional — if it only covered issued patents, a participant could keep their application pending throughout the standards process and only assert once the patent issues, after the standard is locked in and widely deployed. Including applications closes that gap.

"Owned or controlled"

The commitment extends beyond patents the participant directly owns to patents they control — through exclusive licenses, governance rights over an affiliate, or other legal arrangements. The intent is to prevent participants from structuring their patent holdings to avoid the commitment while retaining the economic benefit.

This generates real disputes. A venture-backed startup may be controlled by a VC that also controls hundreds of unrelated companies. A conglomerate's participation through one subsidiary doesn't necessarily mean it can bind patents held by a completely separate division. These are legitimate structural issues with no universal solution. Sometimes the answer is a side letter clarifying scope. Sometimes the answer is that the participant needs to sort out their internal arrangements before joining.

"Now or at any time in the future"

The commitment is forward-looking. If you acquire a patent after making the commitment — through R&D, purchase, or corporate acquisition — and that patent reads on the standard, it's pulled into the commitment. You can't make a commitment on Monday and buy a blocking patent on Tuesday.

"Necessarily be infringed by an implementation"

This is the core of the definition. The claim must be unavoidable. If there's any way to implement the specification without practicing the claim, it's not a necessary claim. The commitment doesn't cover the entire patent portfolio — just the claims that the standard forces implementers to practice.

6.3 Normative vs. Optional: The Empty Commitment Problem

Standards specifications typically contain both normative elements (things an implementer must do) and optional elements (things an implementer may do). The question of whether the necessary claims definition covers optional portions is more significant than it might appear.

If the definition only covers normative, required elements, then anything marked optional in the spec is outside the commitment. An implementer who chooses to implement an optional feature gets no patent protection for that feature. The patent holder can charge whatever they want — or seek an injunction — for optional elements.

This matters because many specifications are predominantly optional. The office file formats, for instance, are roughly 95% optional features. If you want to build a word processor that doesn't support bold text, the spec allows that. But nobody builds a word processor without bold text. If the patent commitment only covers the handful of truly mandatory elements, it may cover very little of what implementers actually need.

This criticism was leveled against some early patent grants in the industry — the argument being that because nearly everything was optional, the licensing commitment was effectively empty. The intent wasn't to create an empty commitment, but the drafting didn't anticipate the issue.

More modern policies address this explicitly. They typically cover the normative elements of optional portions — meaning that if you choose to implement an optional feature, the patent commitment extends to the required elements within that feature. You don't have to implement bold text, but if you do, the patent commitment covers it.

If you're reviewing a policy that's silent on optional portions, flag it. The silence may be deliberate or may be an oversight, but either way it creates ambiguity that can undermine the value of the commitment.

"Shall" vs. "May" — The Language That Drives It

In standards drafting, the words "shall" and "may" have specific, consequential meanings. "Shall" denotes a normative requirement — an implementer must do this. "May" denotes an optional feature — an implementer can do this but doesn't have to.

This distinction directly maps to the necessary claims analysis. A patent claim that reads on a "shall" element is more likely to be a necessary claim because every compliant implementation must practice it. A patent claim that reads on a "may" element is only necessary for implementers who choose to implement that option — and only if the policy extends the commitment to normative elements of optional portions.

When reviewing a specification alongside its patent policy, pay attention to how liberally the drafters used "shall" versus "may." A specification that marks most features as "may" reduces the mandatory surface area and, depending on the policy, may narrow the patent commitment significantly. This can be deliberate — a way for patent holders to limit their exposure — or it can be a natural consequence of a specification that genuinely offers implementers flexibility. Either way, the language choices in the spec and the necessary claims definition in the policy interact to determine what's actually covered.

6.4 When Commitments Lock In

In open source, patent commitments typically attach at the moment of contribution. You submit code, the license terms apply, and the commitment is made.

Standards work differently. The patent commitment generally locks in when the specification is finalized and approved by the working group — not when individual contributions are made during the drafting process. This means that during development, contributions are provisional. The commitment crystallizes at the end, and it covers the final deliverable as a whole, regardless of who contributed what.

This has several implications.

First, it means you're making a commitment to the entire final specification, not just to the parts you contributed. If another participant introduces technology that reads on your patents, your commitment covers it — assuming it ends up in the final spec and your claims are necessary.

Second, it creates a window during development where participants can evaluate the evolving spec and decide whether to stay or withdraw. If the spec moves in a direction you didn't anticipate — you thought you were building a microwave standard, and the group decided to make a toaster — you have the opportunity to withdraw before the commitment locks in. This microwave-becomes-a-toaster problem is one of the most common sources of friction in standards work, and it's why scope — the definition of what a working group can and cannot work on — matters so much. We'll discuss scope in depth in Chapter 8.

Third, it means that interim drafts, working documents, and rejected proposals generally don't carry patent commitments. Only the approved final deliverable does.

6.5 The Contribution Trigger vs. the Participation Trigger

Patent policies use one of two triggers for the commitment: participation or contribution.

A participation trigger means that by joining the working group, you've made the commitment. Your necessary claims are subject to the licensing terms for whatever the group produces, regardless of whether you contributed any technology. You're in the room, you're bound.

A contribution trigger means the commitment only attaches to technology you actually contributed. If you participate as an observer and contribute nothing, you have no patent commitment. But the commitment on what you do contribute may be broader — sometimes covering not just the specific contribution but anything in the final spec that relates to it.

The participation trigger is more protective for implementers. It ensures that everyone in the room has skin in the game, and it prevents a participant from sitting quietly while their patents get embedded in the spec and then asserting without constraint.

The contribution trigger is more protective for patent holders. It limits exposure to what you actually brought to the table. The tradeoff is that it creates a category of participants — observers with relevant patents — who benefit from the standard without contributing to the patent commitment pool.

Most modern royalty-free policies use a participation trigger. RAND policies are more varied. Either way, understanding which trigger your policy uses is essential for advising clients on what joining a working group actually means.

6.6 Successors and Assigns

What happens to the patent commitment when patents change hands? If a participant sells a patent that's subject to a standards commitment, does the commitment travel with the patent?

Most well-drafted policies address this by requiring that any transfer of committed patents be subject to the existing commitment. The buyer takes the patent subject to the licensing obligation. This prevents a participant from making a commitment and then selling the patent to a third party that asserts freely.

In practice, enforcement of successor provisions is uncertain. A patent troll that acquires a patent may argue it had no knowledge of the standards commitment, or that the commitment doesn't run with the patent as a matter of law. Courts haven't fully resolved these questions, and the answers may vary by jurisdiction.

What this means practically is that successor and assign provisions are necessary but not sufficient. They provide a contractual basis for arguing the commitment survives a transfer, but they may not prevent assertion by a determined acquirer. This is one of the areas where the theoretical framework of patent policies meets the messy reality of patent transactions.

6.7 The Versioning Question

One of the most debated areas in necessary claims practice is how commitments carry across specification versions.

You participate in version 1.0 of a specification. Your necessary claims are committed. Then the group begins work on version 2.0. Several scenarios arise.

You stay and participate in 2.0. Your commitment extends to 2.0 through the normal operation of the policy — you're participating, the spec is finalized, the commitment locks in.

You leave after 1.0, and 2.0 adds new sections without changing 1.0. Your commitment clearly covers 1.0. It likely doesn't cover the new sections in 2.0, since you weren't involved. But the 1.0 material is still in the field, still being implemented, and your commitment to it survives your departure.

You leave after 1.0, and 2.0 modifies the 1.0 material. This is where it gets contested. Your commitment was to the 1.0 text. The 2.0 text is different, even if your patents still read on it. Does your commitment carry forward?

Some policies address this with a "substantially similar" formulation — if the technology is used in a substantially similar way for a substantially similar purpose, the commitment persists. Others treat each version as an entirely new commitment. Many are silent, which creates ambiguity that tends to surface at the least convenient time.

A related issue arises with normative references. If version 2.0 of a specification includes a normative reference to version 1.0 — essentially saying "go implement v1.0, then come back here for the new material" — the v1.0 commitment is preserved intact because the text hasn't changed. But if the v2.0 team copies the v1.0 text into the new document and edits it, the commitment to the original text may not clearly extend to the modified version.

These aren't theoretical problems. They arise in practice when participants withdraw from working groups and later seek to assert patents against the continued work. The best protection is clear policy language. The second-best protection is a normative reference structure that avoids modifying committed text.

6.8 Software and Implementation Patents

One area that trips up newcomers is the distinction between patents on the standard and patents on the implementation.

The necessary claims definition covers patents that read on the specification — the normative description of what an implementation must do. It generally does not cover patents on how the implementation achieves that result internally.

Going back to the sorting example: a patent on accepting numbers in the specified format and returning them sorted as described would be a necessary claim. A patent on a particular sorting algorithm used internally would not — because the standard doesn't prescribe the algorithm.

This distinction is what allows competition among implementers. Everyone implements the same interface, but they compete on how efficiently, how quickly, or how cleverly they do the internal work. Implementation patents remain outside the standards commitment and subject to normal market dynamics.

The boundary isn't always clean. Encryption standards, for instance, sometimes require specific algorithms — the standard can't be implemented without using the exact algorithm described. In those cases, patents on the algorithm itself may be necessary claims. But those are the exception. For most standards, the interface is what's committed; the implementation is what's competed.

6.9 The Game Theory of Necessary Claims

As discussed briefly in Chapter 3, there's a counterintuitive dynamic in how necessary claims are argued in disputes.

When a patent holder asserts a claim against an implementer, both sides generally have an incentive to agree the claim is a necessary claim — even though they'll fight over everything else.

The implementer wants the claim to be necessary because that brings it within the RAND or royalty-free commitment. The patent holder gets a reasonable royalty (in RAND) or no royalty (in RF), but the implementer avoids unconstrained damages and injunctive relief.

The patent holder also often prefers the claim to be necessary — paradoxically — because proving infringement is dramatically simpler. If the implementer has a certification logo on their product (Wi-Fi, Bluetooth, etc.), they've already told the world they implement the standard. The patent holder doesn't need to prove infringement claim by claim. The only question is the rate.

If the implementer successfully argues the claim is not necessary — just an implementation detail — they've escaped the standards commitment but walked into a regular patent infringement case. No RAND protection. No rate cap. Full damages and injunctive relief are on the table.

This dynamic is why disputes over necessary claims are surprisingly rare compared to disputes over rates. Both sides prefer to be inside the system, arguing about the price, rather than outside it, arguing about liability.

One related and highly contested question — whether a RAND-committed patent holder can seek injunctions against implementers — is addressed in Chapter 7.