How to Build SEP Claim Charts That Hold Up to a Challenge

An SEP chart is only as strong as its weakest row. Here are the common mistakes that get these charts torn apart, and how to avoid them.

By the iCuerious Research Team

A standard-essential patent (SEP) claim chart looks simple to build. You put the patent claim on one side and the matching part of the technical standard on the other, and you show that they line up. If the standard says every compliant product must do something, and the claim covers that same thing, the patent is essential. Done.

In real life, it is rarely that clean. SEP charts are some of the most heavily challenged documents in patent licensing and litigation. And the charts that fall apart tend to fail for the same handful of reasons, over and over.

The reason is that "essential" is a high bar. A patent is only standard-essential if there is no way to build a compliant product without using the claim. So a patent that someone has declared essential is not the same as a patent that is essential. Independent reviews keep finding that a large share of declared patents don’t hold up when you look closely. A chart that assumes the patent is essential, instead of proving it, is easy to knock down.

“Declared essential” is a claim someone made. “Actually essential” is something you have to prove. A good SEP chart is that proof.

Below are the mistakes we see most often, with a bit more detail on the technical traps behind each one and the simple habit that fixes it. This is written for teams who build these charts for licensing talks, patent pools, or court, where a skeptical reader will hunt for the one weak row that brings down the rest.

---

Get the layout right: every SEP chart answers two questions, not one

Most SEP chart templates have two columns: the claim on the left, the standard on the right. That setup hides a problem, because there are really two separate questions here, and matching the claim to the standard only answers one of them.

The first question is about the standard: does the claim match a required part of it? The second is about the product: does the accused product actually do that required thing? There is a well-known rule from the courts that sits underneath this. In Fujitsu v. Netgear, the Federal Circuit said you can use a standard to prove infringement, but only for the parts the standard makes mandatory. If a feature is optional in the standard, you cannot lean on the standard alone; you have to compare the actual product to the claim. That single rule is why a strong chart needs three columns, not two: the claim limitation, the exact part of the standard it matches, and proof that the product really does it. The third column is the one most templates leave out, and skipping it is the most common way an "essential" chart ends up proving nothing about a real product.

---

The mistakes that get SEP charts torn apart

Mistake 1: Matching the claim to an optional feature

Standards are written to a strict drafting convention. When a specification says a product shall do something, that is a hard requirement. When it says should, that is only a recommendation, and may means it is optional. Only the "shall" parts can make a patent essential, because a product can be fully compliant and still skip everything that is merely recommended or optional. If your chart points to a "should" or "may" clause, the other side simply says a compliant product can leave it out, and the row collapses.

The technical trap is that "the product supports it" and "the standard requires it" are not the same thing. Modern standards carry a lot of optional behavior that a device turns on and advertises through capability signaling, in cellular, for example, a device reports what it supports through its capability information, and many features (certain carrier-aggregation combinations, some MIMO modes, particular codecs) are optional at the standard level even when a given phone happens to implement them. So, a mapping to one of these proves, at most, that this product does it. It does not prove that every compliant product must, which is what essentiality requires.

For every clause you cite, check the exact wording and mark it required, recommended, or optional. Watch for the middle case, features that are mandatory only if the device does something else first ("conditionally mandatory"). Those can support essentiality, but only for devices that meet the condition, so state the condition plainly (a band, a mode, a release). If the feature is truly optional, move it out of the essentiality argument and prove it as ordinary infringement instead, using product evidence.

A common claim-chart error is to treat a feature as mandatory merely because the standard defines or supports it. The safer approach is to identify the condition under which the standard actually requires the claimed operation.

See example:

Claim limitation: “applying an adaptive loop filter to a coding tree block”

The resulting chart should therefore state the condition explicitly:

ALF is conditionally required at the CTB level when the relevant alf_ctb_flag is set to 1. It should not be characterized as universally mandatory for every CTB merely because ALF is enabled at the slice level.

This distinction prevents an optional or conditional feature from being overstated as an unconditional requirement. The analyst should identify the triggering condition, the resulting mandatory behavior, and the scope of that behavior before concluding that the claim limitation is satisfied.

Mistake 2: Citing the wrong version of the standard

Standards are living documents. A big standard is developed in numbered releases (in cellular, for instance, work is organized into 3GPP Releases, Release 8 brought the first LTE, and 5G NR arrived around Release 15), and each individual specification then has its own version numbers and freeze dates. The text keeps moving as change requests are approved. So "the standard" is never one fixed thing; it is a specific document at a specific version.

This is where quiet errors creep in. Section numbers get renumbered between versions, thresholds and parameters change, and a feature that was optional in one release can become mandatory in a later one (or the reverse). A chart that cites a version the accused product never implemented can be perfectly accurate for that version and simply wrong for the one at issue. There is also a timing angle: the release a product implements has to line up with the version you cite, and separately, the patent’s priority date matters when anyone questions the patent’s own validity against earlier versions of the standard.

The fix: name the exact document and version for every citation, not just the standard family. Confirm that version against the release the product actually implements, its certification or capability records will tell you, and if a feature migrated between versions, say so and cite the specific version that supports your reading. Keep a version note in the chart itself so a reader never has to guess which text you relied on.

The Family: Cellular (LTE/5G NR)

The Document: 3GPP TS 36.423 (X2 Application Protocol)

A recent cellular SEP investigation involving a Secondary Node (SN) highlighted why citing only “3GPP TS 36.423” is not enough. During the analysis, the team had to distinguish between the legacy X2 procedures and the later EN-DC procedures within the same specification family. A chart that cited only “TS 36.423” could therefore have left the reader unsure which release, and consequently which version of the procedure and signalling requirements, was actually being relied upon.

The risk became particularly important because the claim involved SN-related functionality. TS 36.423 has evolved significantly across releases: Release 15 already introduced EN-DC procedures, while later releases added, modified, and corrected EN-DC, SN, NR and other X2AP functionality. Using a passage from a different release could therefore make a chart appear technically supported while relying on requirements that were not present, or were different, in the release applicable to the product or technology being assessed.

The practical fix was to pin the analysis to 3GPP TS 36.423 V19.1.0 (2026-02), Release 19, and record the exact section and procedure used for each mapping. The team could then separately check whether the cited functionality was present and mandatory in the release applicable to the relevant product and technology timeframe. This removed the ambiguity created by a generic “TS 36.423” citation and made the provenance of each standard mapping clear.

The lesson was simple: a correct quotation from the wrong release is still the wrong evidence. For an evolving standard, the chart should identify the exact specification version and date, and, where historical applicability matters, confirm that the cited requirement existed in the relevant release.

Mistake 3: Treating “declared essential” as proof

Declaration lists are self-reported. Under the disclosure rules of standards bodies, patent holders declare patents they believe may be essential, and the sensible move is to declare broadly to stay safe. Nobody at the standards body checks whether each declared patent is truly essential, and there is even an incentive to over-declare, because a bigger declared count can look like a bigger stake in the standard. So, a declaration tells you where to look. It does not tell you the answer.

The technical reality is that measured essentiality rates run well below declared numbers. When patent pools and independent evaluators actually test declared patents clause by clause, a sizeable portion turn out not to be essential, often because they map to optional features, rely on non-binding text, or read on only one of several allowed ways to meet the requirement. Building a chart on the declaration skips exactly the analysis a serious opponent will demand.

Treat every patent as not essential until your own clause-by-clause mapping shows otherwise. And be honest in the chart about the counter-arguments, a plausible design-around, or a narrower reading of the standard that avoids the claim, and answer them, rather than hoping the reader misses them. A chart that pre-empts the obvious objection is far harder to dislodge.

In a report for the European Commission, Regibeau, de Coninck, and Zenger (2016) found that only 10 to 50% of declared “essential” patents are genuinely essential.

Source: Deterring over-declaration of essential patents through random assessments, declaration fees, and royalty sharing

Mistake 4, Quoting parts of the standard that don’t carry weight

Not every line in a standard is a rule. Standards deliberately separate the binding requirements from the explanatory material, notes, examples, background, and many appendices that explain things but require nothing. In most specifications an appendix is even labelled as either "normative" (binding) or "informative" (for guidance only), and lines that begin with "NOTE" are not requirements. Only the binding text can support essentiality.

The trap is that the explanatory text is often the clearest and most quotable. A note or an informative appendix will sometimes describe a behavior in plain, helpful language, while the actual requirement is buried in a terse "shall" clause elsewhere. Quote the friendly note and you have cited words that bind no one, and a knowledgeable opponent will point that out immediately.

The fix: confirm the status of every passage you cite. Check whether the appendix is marked normative or informative, and make sure the sentence is a requirement, not a note or an example. When the clearest description lives in a note, trace it back to the binding clause that actually requires the behavior and cite that clause, using the note only as a plain-language aid.

Mistake 5, Showing the standard matches, but never the product

This is the mistake the three-column layout is built to stop, and it deserves its own section because it is so common. A chart can match the claim perfectly to a required, correctly versioned, binding part of the standard, and still say nothing about whether a specific product actually does that thing. Compliance is often assumed from a marketing line ("5G ready," "Wi-Fi certified"), but a label like that is a lead, not proof, and the other side knows it.

There is good, checkable product evidence available if you go looking for it. Independent certification programs test devices against a standard before they can carry the badge, and their records can show what a product was required to demonstrate. Conformance test specifications spell out the exact behaviors a device must pass. A teardown can identify the specific chip or modem inside a product, which ties it to documented capabilities. And a protocol log or over-the-air capture can show the required signaling actually happening on the wire. Any of these is far stronger than an inference from the vendor’s own marketing.

The fix: back the product column with real, independent evidence, a certification record, chip or component documentation, a teardown finding, or a captured log of the required behavior. This is the same evidence discipline that governs any strong claim chart: sources that are independent, checkable, and dated beat a guess based on a label. It is also the point where an optional-but-implemented feature gets proved, through the product, not the standard.

Mistake 6, Skipping the step that explains what the claim words mean

A patent claim and a standard almost never use the exact same words for the same idea. The claim might say "a processing unit configured to allocate resources," while the standard talks about a "scheduler" doing something in a named procedure. If your chart jumps straight from the claim wording to the standard wording, it skips the step that matters most, what the claim words actually mean, and hands the other side room to argue for a narrower meaning under which the match no longer works.

The technical nuance is that claim meaning is not a free choice; it comes from the patent’s own specification and its prosecution history, and in US litigation it is fixed by the court in claim construction. Some terms carry extra baggage, a "means for" term, for example, is read as limited to the specific structure described in the patent, which can narrow it sharply. If your mapping quietly assumes a broad, everyday meaning that the patent does not actually support, the whole row is exposed the moment a construction is decided.

The fix: for each claim term that could be argued over, state what you take it to mean and why, grounded in the specification and file history, then show how that meaning lines up with the standard’s own term. Each row should read as a clear chain: claim term, then its meaning, then the matching concept in the standard, then the binding clause that requires it. No silent jumps.

In an investigation related to Video Coding, the claim language and the standard did not use identical terminology. The useful bridge was to identify the technical operation described by the claim term and then determine how that operation is defined and implemented in the standard.

---

A quick check before the chart goes out

Before an SEP chart leaves your desk, for a licensing pack, a pool, or a court filing, run every row past the questions the other side will ask:

1. Is the part you cited a real requirement, or just a note or an informative appendix?
2. Is the behavior mandatory (“shall”)? If it’s mandatory only in certain cases, did you state the condition?
3. Did you name the exact document and version, and does it match the product’s implemented release?
4. Is there real, independent proof the product does it, certification, chip docs, teardown, or a log, not just a marketing label?
5. Did you state what each disputed claim term means, with a basis, and link it to the standard’s wording?
6. Did you spot the obvious design-arounds and narrower readings, and answer them?

An SEP chart isn’t a table you fill in. It’s the case for why a patent is essential, and it’s judged by its weakest row, not its best one.

---

Where iCuerious comes in

Building SEP charts that hold up is about careful evidence, not filling in a template. For over a decade, iCuerious has built essentiality maps and evidence-of-use charts that tie every citation to a real, correctly versioned requirement and back every product claim with proof you can check. If you’re getting an SEP portfolio ready for licensing, a pool, or court, or pressure-testing charts you already have, we’d be glad to talk.

Talk to the iCuerious SEP team → www.icuerious.com