Product to Patent Mapping Strategy to Align with German Patent Tax Laws

Marcus, senior patent counsel at a global networking equipment manufacturer, contacted us with an unusual request. His company’s German subsidiary faced a tax penalty. 

The German Tax Authority challenged the transfer pricing structure, specifically questioning whether the European patents licensed to the subsidiary were actually used in products generating revenue in Germany.

Marcus’s request was surgically precise:

“I need a claim-by-claim analysis showing which patents are practiced in German-sold products and which are not. Portfolio-level assertions won’t work.” 

Based on internal review, Marcus identified 58 EU patents where clarity was lacking and requested a self-infringement analysis. 

Unlike typical projects, this was not about valuation, quality scoring, or landscape mapping. The requirement was singular: determine the exact extent to which patent claims were implemented in products so that the company could calculate tax obligations accurately based on actual usage.

KEY OUTCOME

6 patents showed complete claim overlap with relevant products. The remaining patents had partial alignment, with several claims not implemented in product technology. A significant portion of products operated on conditional claims. 

Each of these insights was documented in detail, enabling precise calculation of tax exposure based on actual claim coverage.

The Context: An Internal Licensing Structure Under Scrutiny

In June 2023, the German Tax Authority initiated a transfer pricing audit of the German subsidiary for the 2018 to 2022 period. Among the requirements was a clear mapping between licensed patents and products sold in Germany.

While the company maintained strong patent records and product documentation, a direct linkage at the claim level was not readily available. This was partly due to natural organizational evolution. Some engineers involved in earlier product development had transitioned out, and product architectures had advanced over time. As a result, historical mapping between patents and current product behavior required reconstruction and validation.

The 58 patents shared for analysis required independent, claim-level verification.

Portfolio Inventory

The first step was to validate and structure the patent portfolio under consideration. While the licensing agreement provided an initial list, further refinement was required.

The portfolio included:

• Patents filed between 2008 and 2019, with priority dates going back to 2006
• Technical areas including Ethernet link establishment (22 patents), auto-negotiation (18 patents), MAC-layer control (12 patents), and Energy Efficient Ethernet or 802.3az (6 patents)
• 31 distinct patent families, with several continuations and divisionals

Some patents listed in earlier agreements had expired or been abandoned, while others had been added later. This validation ensured that only relevant, enforceable patents were considered.

Product Scope Definition

Defining the product scope was more complex. The German subsidiary sold dozens of networking products, but not all were manufactured or configured identically. After discussions with product management and engineering, the scope was limited to:

• Product families sold in Germany during the audit period (2018–2023): ES Series (Gen 2, Gen 3, Gen 4), ESwitch Series (ABC-24, ABC-48, ABC-Aggregation), IP switches (US-Industrial)
• Exclusions: Products sold only in non-EU markets, beta firmware not shipped to customers, custom enterprise configurations created for specific contracts, products discontinued before 2018
• Hardware generations: Each product family had multiple hardware revisions with different chipsets and architectures
• Firmware branches: Major firmware updates sometimes changed Ethernet negotiation behavior without corresponding hardware changes

This segmentation was critical. A patent may cover ES Gen 2 (accounting for 18% of German sales during the audit period) but not Gen 3 (accounting for 47% of sales). Product-level analysis would miss this distinction.

The Missing Link Between Patents and Products

Early in the process, a critical gap surfaced. While patent files and product documentation were both well maintained, there was no direct linkage at the level that mattered, individual claim elements mapped to actual product behavior.

At first glance, the documentation suggested strong alignment. Product materials described features in detail, and engineering records captured design intent across generations. However, when examined through a claim-level lens, this information proved insufficient. Functional descriptions did not confirm whether specific claim conditions were met. In several cases, features referenced in patents had been modified, replaced, or removed as products evolved.

This gap was not due to a lack of information, but due to the absence of a structured way to connect legal claims with real-world implementation.

To resolve this, the analysis shifted from relying on static records to reconstructing product behavior. We worked closely with engineering and product teams to validate available inputs and fill in missing context. These internal insights were then cross-checked with independent technical evidence, including standards, configuration behavior, and observed outputs.

This combined approach allowed us to move beyond assumptions and establish a clear, evidence-backed mapping between what the patents claimed and what the products actually did.

Reframing the Analysis: From Relevance to Self-Infringement

Rather than applying relevance or overlap scores, the analysis was reframed around a familiar question: whether the company’s own products would infringe the patents if those patents were held by a third party.

As a result, we agreed on a four-tier classification system for each patent-product combination

Critically, Marcus recommended treating ‘Probably in Use’ as excluded from the final tax position unless additional validation could be obtained. This conservative approach would prevent the German Tax Authorities from challenging borderline classifications.

No Claim Charts, No Correlation! The Documentation Gap That Almost Derailed the Analysis

The first evidence-gathering request to engineering was met with confusion. ‘Do we have claim charts mapping our patents to our products?’ The answer was no. 

‘Do we have technical documentation showing which IEEE 802.3 mechanisms are implemented in each firmware version?’ Partially. 

Some existed for Gen 3, but Gen 2 documentation was incomplete.

This exposed a critical organizational gap: the company had excellent patent prosecution files (maintained by outside counsel) and extensive product engineering documentation (maintained by engineering teams), but no process connecting the two, no standardization that makes this correlation easy. 

Evidence Reconstruction and Technical Correlation

Claim implementation was evaluated using only sources that demonstrated actual product behavior. These included publicly available configuration guides, observed product demonstrations, applicable IEEE 802.3 standards constraints, reverse-engineering and teardown material where available, and independent technical publications. 

Each patent underwent a structured verification protocol to systematically test claim coverage. The process began with claim element extraction, parsing independent claims into discrete, testable components while identifying dependencies and conditional requirements. A patent might claim a method with four distinct steps, each representing a separate element that required independent verification. One element failing would cause the entire claim to fail, regardless of how well the other elements were satisfied.

Where Functional Alignment Failed Claim-Level Testing

One patent (EP2XXX123) provides a detailed illustration of how this analysis proceeded and what it revealed. EP2XXX123 claimed a method for Ethernet link parameter negotiation with the following independent claim elements:

1.    Detecting conflicting speed/duplex advertisements from a link partner

2.    Invoking a priority MAC selection mechanism based on hardware identifier comparison

3.    Automatically adopting the higher-priority MAC’s parameters without user intervention

4.    Transmitting a confirmation frame containing the selected parameters

On reviewing the ES product documentation, the patent appeared highly relevant. The product datasheet stated: ‘Advanced auto-negotiation with intelligent conflict resolution ensures optimal link parameters.’ Marketing materials referenced ‘automatic parameter selection.’

Initial classification: Probably in Use.

However, on examining the actual protocol traces from ES Gen 3 (firmware v2.0+, representing 47% of German sales), a different picture emerged:

• Element 1 (conflict detection): ✓ SATISFIED – Protocol traces showed detection of conflicting advertisements
• Element 2 (priority MAC mechanism): ✗ NOT SATISFIED – Gen 3 deferred to standard IEEE 802.3 Clause 28 priority rules based on advertised capabilities, not hardware identifier comparison. The priority MAC mechanism described in the patent was not invoked.
• Element 3 (automatic adoption): ✓ SATISFIED – Parameters were adopted automatically
• Element 4 (confirmation frame): ✗ NOT SATISFIED – Standard 802.3 acknowledgment messages were used, not a separate confirmation frame as claimed

The failure of Elements 2 and 4 triggered a deeper investigation. Engineering review revealed:

• ES Gen 2 (2018-2020, 18% of German sales) did implement a priority MAC mechanism similar to the patent, using a proprietary conflict resolution approach
• ES Gen 3 (2020-present, 47% of German sales) switched to a revised MAC-layer state machine that eliminated the proprietary mechanism in favor of strict IEEE 802.3 Clause 28 compliance
• The change was documented in firmware release notes as ‘improved standards compliance’ but not flagged as affecting patent coverage
• The priority MAC feature was removed from configuration options entirely; it was not disabled by default, but was absent from the codebase

Finally, the classification led to:

• ES Gen 2: Probably in Use (pending additional Gen 2 validation)
• ES Gen 3 & Gen 4: Definitely Not in Use
• ESwitch series: Definitely Not in Use (all generations used Gen 3-style architecture)

Because Gen 3+ products represented 78% of German sales during the audit period, EP2XXX123 was ultimately classified as non-applicable for transfer pricing purposes.

The downgrade was not driven by doubt about overall functionality, but by the absence of a single required operational condition. Similar patterns were observed across other product families. 

One Absent Condition. One Failed Claim. One Patent Removed from 78% of Sales.

Translating claims into concrete functional requirements proved decisive. In multiple instances, patents that appeared relevant at a conceptual level failed on a single dependency, such as an automatic fallback condition or a mandatory negotiation step, that the products did not satisfy.

Equal weight was given to documenting non-use. For each excluded patent, the analysis recorded the specific reason coverage failed, whether due to deprecated features, architectural changes, or product scope limitations.

Marcus emphasized that this record was essential: a credible submission to tax authorities must explain not only why certain patents apply, but why others do not.

This negative mapping strengthened the defensibility of the overall position.

Outcome and Broader Implications

The analysis delivered exactly what Marcus had requested, a clear, claim-level view of how each of the 58 patents aligned with products sold in Germany.

6 patents were classified as definitely in use, meaning that all claim elements were fully satisfied by the product’s behavior. These patents represented the highest level of overlap and, as a result, carried the most weight in determining tax obligations.

For the remaining patents, the outcome was not framed as a simple inclusion or exclusion. Instead, each patent was assessed based on the percentage of claim overlap with the relevant products. In several cases, only specific claims or conditional elements were implemented, while others were not. This created a graded understanding of implementation rather than a binary view.

This distinction was critical. It allowed the client to move away from broad assumptions and instead quantify how much each patent actually contributed to the revenue generated by the products.

The result was a structured, defensible basis for tax calculation, directly tied to real product behavior at a claim level. This approach differed from typical patent analysis, which often focuses on relevance or portfolio strength. Here, the value came from precision, measuring actual implementation and translating it into actionable financial insight.

What should you do if you need your product-patent mapping in a licensing situation?

Every situation brings its own requirements, and this case made that clear. The challenge was not about assessing portfolio strength, but about demonstrating, with precision, what the portfolio actually covered in practice.

When scrutiny increases, assumptions are no longer sufficient.

Therefore, the better question isn’t whether your portfolio is strong, but whether you can demonstrate what it actually covers when tax authorities ask you to prove it.

Wondering if your licensing agreements would survive this level of scrutiny? 

Most companies assume their portfolios align with products until someone asks for proof. Tax audits, customs reviews, and royalty disputes don’t accept portfolio-level assertions. 

If you are managing cross-border licensing, preparing for M&A diligence, or facing questions about patent implementation from tax advisors, fill out our assessment form to determine whether a claim-level analysis makes sense for your situation.