US 7760733

A detailed analysis of U.S. Patent 7,760,733 reveals a technology focused on enhancing network efficiency by offloading packet filtering tasks to the network interface card (NIC), a hardware component. This approach is designed to reduce the processing load on a host computer's main processor.

Patent Number: US 7,760,733 B1

Title: Filtering ingress packets in network interface circuitry

Assignee: Chelsio Communications, Inc.

Inventors: Asgeir Thor Eiriksson, Chris Yuhong Mao

Filing Date: October 13, 2005

Issue Date: July 20, 2010

Abstract: The patent describes a method for managing data transfer between a peer application and a host computer through network interface circuitry. This circuitry, often a NIC, can offload data processing from the host for specific protocols. The core of the invention lies in applying filtering rules to incoming data based on its characteristics before it is passed to the host. When multiple filtering rules could apply, the system is designed to automatically determine the appropriate rule to use.

Plain-Language Overview of Independent Claims:

The independent claims of a patent define the core of the invention in the broadest terms. Here is a simplified explanation of each independent claim in US 7,760,733:

• Independent Claim 1: This claim outlines a method for network interface hardware to prioritize how it handles incoming data. The hardware can either "filter" the data (e.g., block or modify it) or perform "protocol processing" for connections that have been offloaded from the main computer to the network card for faster handling. The system uses a predefined order to decide which action takes precedence, with the offloaded protocol processing being the higher priority.

• Independent Claim 9: This claim focuses on a method for network interface hardware that is already handling offloaded connections. When new data arrives, the hardware first checks if it belongs to one of these offloaded connections. If so, it processes it accordingly. If the data does not belong to an offloaded connection, the hardware then looks for a matching filtering rule and applies the one with the highest priority based on a predetermined order.

• Independent Claim 12: This claim describes the physical network interface circuitry itself. It specifies that the hardware is built with the capability to receive data and determine the highest priority action to take—either protocol processing for an offloaded connection or filtering for all other data. A key aspect of the circuitry is its ability to selectively prevent data from ever reaching the host computer if a filtering rule dictates it should be blocked.

• Independent Claim 18: This claim is largely similar to claim 1, detailing a method for network interface hardware to process incoming data by choosing a "highest priority" action from a list that includes filtering and offloaded protocol processing. The decision is made by lookup circuitry that automatically gives preference to protocol processing for offloaded connections over the application of filtering rules.

CAFC Litigation:

A thorough search of the U.S. Court of Appeals for the Federal Circuit (CAFC) dockets for the year 2026 reveals no pending or decided cases specifically involving US Patent 7,760,733. Further investigation into litigation involving the assignee, Chelsio Communications, Inc., in the same timeframe also did not yield any results pertinent to this patent. Therefore, as of the current date, there is no indication of recent appellate-level litigation concerning this patent.

A search for litigation involving US Patent 7,760,733 was conducted using several resources, including Unified Patents, PACER, and CAFC dockets. As of April 26, 2026, no known litigation cases specifically naming US Patent 7,760,733 as the patent in question were found. The previously generated section regarding CAFC litigation, which states there is no indication of recent appellate-level litigation concerning this patent, remains consistent with these findings.

Proceedings overview

There are no AIA trial proceedings on file for US Patent 7,760,733 in the USPTO Open Data Portal. A comprehensive web search also did not reveal any active or concluded PTAB proceedings. Therefore, the patent currently has no PTAB activity on file, which means all claims remain untested by an AIA trial.

Strategic summary

As of the current date, all claims of US 7,760,733 are UNTESTED by any AIA trial proceeding. There are no canceled or sustained claims through PTAB review. This means there is no estoppel landscape from prior PTAB decisions that would bar a potential petitioner from raising any ground of unpatentability under 35 U.S.C. §§ 102, 103, or 112. The absence of PTAB activity could indicate that the patent has not been heavily asserted in litigation or that prior challenges have not materialized into formal AIA trials. Chelsio Communications, Inc. is an active technology company in high-performance networking and storage solutions, and holds several patents.

Recommended next steps

If facing an assertion of US 7,760,733, a potential defendant has a clear path to pursue an AIA trial (Inter Partes Review, Post-Grant Review, or Covered Business Method review, depending on eligibility) without being constrained by prior PTAB decisions. The absence of previous challenges means all prior art grounds under 35 U.S.C. §§ 102 and 103, and invalidity grounds under 35 U.S.C. § 112, are potentially available. There are no active proceedings or upcoming trial-stage milestones to monitor.

Inventors

• Asgeir Thor Eiriksson: Chelsio Communications Inc.
• Chris Yuhong Mao: Chelsio Communications Inc.

Both inventors were employed by Chelsio Communications Inc. at the time of filing. There is no unusual pattern of departure within 12 months of filing discernible from the provided information.

Original assignee

Chelsio Communications, Inc.
Chelsio Communications, Inc. is the entity named on the issued patent. They primarily develop and market high-performance Ethernet adapters for servers, storage, and embedded applications, embodying the claims in their products. As of the current date, Chelsio Communications, Inc. appears to be an operating company, as indicated by their continuous ownership of the patent and its use as collateral for ongoing financing.

Assignment timeline

• 2005-10-13 (executed) / recorded 2005-10-13 — Reel 017257/0090
  • Conveyance: ASSIGNMENT OF ASSIGNORS INTEREST
  • Assignor: ERIKISSON, ASGEIR THOR; MAO, CHRIS YUHONG
  • Assignee: CHELSIO COMMUNICATIONS, INC.
  • Correspondent: BLAKELY, SOKOLOFF, TAYLOR & ZAFMAN, LLP
  • Context: Original assignment of inventorship rights to the company.
• 2013-05-09 (executed) / recorded 2013-05-13 — Reel 030232/0330
  • Conveyance: SECURITY AGREEMENT
  • Assignor: CHELSIO COMMUNICATIONS, INC.
  • Assignee: EAST WEST BANK
  • Correspondent: SHEPPARD MULLIN RICHTER & HAMPTON LLP, 333 SOUTH HOPE STREET 43RD FLOOR, LOS ANGELES, CA 90071. This correspondent firm recurs in this chain.
  • Context: Patent used as collateral for a loan.
• 2014-10-21 (executed) / recorded 2014-10-24 — Reel 032549/0256
  • Conveyance: RELEASE
  • Assignor: EAST WEST BANK
  • Assignee: CHELSIO COMMUNICATIONS, INC.
  • Correspondent: SHEPPARD MULLIN RICHTER & HAMPTON LLP, 333 SOUTH HOPE STREET, 43RD FLOOR LOS ANGELES, CA 90071. This correspondent firm recurs in this chain.
  • Context: Release of security interest by East West Bank.
• 2014-10-21 (executed) / recorded 2014-10-24 — Reel 032549/0259
  • Conveyance: SECURITY AGREEMENT
  • Assignor: CHELSIO COMMUNICATIONS, INC.
  • Assignee: SILICON VALLEY BANK
  • Correspondent: COOLEY LLP, 3175 HANOVER STREET PALO ALTO, CA 94304-1130. This correspondent firm recurs in this chain.
  • Context: New security interest granted to Silicon Valley Bank.
• 2016-07-15 (executed) / recorded 2016-07-21 — Reel 036325/0747
  • Conveyance: RELEASE
  • Assignor: EAST WEST BANK
  • Assignee: CHELSIO COMMUNICATIONS, INC.
  • Correspondent: SHEPPARD MULLIN RICHTER & HAMPTON LLP, 333 SOUTH HOPE STREET 43RD FLOOR, LOS ANGELES, CA 90071. This correspondent firm recurs in this chain.
  • Context: Second release of security interest by East West Bank.
• 2016-07-29 (executed) / recorded 2016-08-01 — Reel 036398/0048
  • Conveyance: SECURITY AGREEMENT
  • Assignor: CHELSIO COMMUNICATIONS, INC.
  • Assignee: NOVIRIAN CAPITAL, LLC
  • Correspondent: O'MELVENY & MYERS LLP, 400 SOUTH HOPE STREET, 18TH FLOOR LOS ANGELES, CA 90071. This correspondent firm recurs in this chain.
  • Context: New security interest granted to Novirian Capital, LLC.
• 2017-04-25 (executed) / recorded 2017-04-26 — Reel 038030/0620
  • Conveyance: RELEASE
  • Assignor: NOVIRIAN CAPITAL, LLC
  • Assignee: CHELSIO COMMUNICATIONS, INC.
  • Correspondent: O'MELVENY & MYERS LLP, 400 SOUTH HOPE STREET, 18TH FLOOR LOS ANGELES, CA 90071. This correspondent firm recurs in this chain.
  • Context: Release of security interest by Novirian Capital, LLC.
• 2019-08-14 (executed) / recorded 2019-08-16 — Reel 047814/0396
  • Conveyance: SECURITY AGREEMENT
  • Assignor: CHELSIO COMMUNICATIONS, INC.
  • Assignee: WESTERN ALLIANCE BANK, AN ARIZONA CORPORATION
  • Correspondent: COOLEY LLP, 3175 HANOVER STREET PALO ALTO, CA 94304-1130. This correspondent firm recurs in this chain.
  • Context: New security interest granted to Western Alliance Bank.
• 2019-08-15 (executed) / recorded 2019-08-19 — Reel 050050/0396
  • Conveyance: CORRECTIVE ASSIGNMENT
  • Assignor: CHELSIO COMMUNICATIONS, INC.
  • Assignee: WESTERN ALLIANCE BANK, AN ARIZONA CORPORATION
  • Correspondent: COOLEY LLP, 3175 HANOVER STREET PALO ALTO, CA 94304-1130. This correspondent firm recurs in this chain.
  • Context: Corrective assignment to a prior security agreement.
• 2025-12-18 (executed) / recorded 2025-12-19 — Reel 061483/0321
  • Conveyance: RELEASE
  • Assignor: WESTERN ALLIANCE BANK, AN ARIZONA CORPORATION
  • Assignee: CHELSIO COMMUNICATIONS, INC.
  • Correspondent: COOLEY LLP, 3175 HANOVER STREET PALO ALTO, CA 94304-1130. This correspondent firm recurs in this chain.
  • Context: Release of security interest by Western Alliance Bank.

Timeline diagram

timeline
    title Ownership of US 7760733
    2005 : Inventors assign to Chelsio
    2010 : Patent issued
    2013 : Sec Agmt to East West Bank
    2014 : East West Bank releases
         : Sec Agmt to Silicon Valley Bank
    2016 : East West Bank releases
         : Sec Agmt to Novirian Capital
    2017 : Novirian Capital releases
    2019 : Sec Agmt to Western Alliance Bank
         : Corrective Assignment
    2025 : Western Alliance Bank releases

NPE / troll-pattern signals

1. Shell-entity transfer — Not present. The patent has consistently been held by Chelsio Communications, Inc., an operating company. All recorded transfers are security interests to financial institutions, not transfers of ownership to licensing-only entities.
2. Known asserter in the chain — Not present. None of the listed assignees (Chelsio Communications, Inc., East West Bank, Silicon Valley Bank, Novirian Capital, LLC, Western Alliance Bank, an Arizona Corporation) are known patent asserters or NPEs.
3. Repeat correspondent across the chain — Present.
   • SHEPPARD MULLIN RICHTER & HAMPTON LLP appears on Reel 030232/0330, 032549/0256, and 036325/0747.
   • COOLEY LLP appears on Reel 032549/0259, 047814/0396, 050050/0396, and 061483/0321.
   • O'MELVENY & MYERS LLP appears on Reel 036398/0048 and 038030/0620.
     While multiple correspondent firms recur, they are associated with the financial institutions in security interest transactions, which is typical for such financing arrangements and does not indicate an NPE pattern in this context.
4. Cascading transfers — Not present. Although there are multiple transactions, they are all security interests and releases, not transfers of ownership between chained LLCs. Chelsio Communications, Inc. has retained ownership throughout the recorded history.
5. Pre-litigation transfer — Not present. The previous litigation summary indicates no known litigation cases involving this patent.
6. Bankruptcy fire-sale — Not present. There is no indication that Chelsio Communications, Inc. has filed for bankruptcy, and the transfers are for securing financing.
7. Privateering — Unclear. There is no evidence in the assignment records or provided context to suggest privateering.
8. Defensive aggregator (anti-NPE) — Not present. The patent is held by an operating company, not a defensive aggregator.

Verdict

Insufficient data
There are no recorded transfers of ownership for US 7760733 to any entity other than the original assignee, Chelsio Communications, Inc. The extensive assignment history consists entirely of security agreements and their subsequent releases with various financial institutions, indicating the patent has been used as collateral for corporate financing rather than being transferred for assertion. Therefore, there are no signals to categorize it as an NPE asset.

USPTO Assignment Center Search for US7760733

To identify the most relevant prior art for US Patent 7,760,733, I will analyze the patent citations listed within the patent itself, as this directly indicates what the examiners and inventors considered relevant during prosecution.

Prior Art Analysis for US Patent 7,760,733

The following are the most relevant prior art references cited in US Patent 7,760,733. For each reference, a brief description and potential anticipation of claims under 35 U.S.C. § 102 are provided. Anticipation under 35 U.S.C. § 102 requires that all elements of a claimed invention are disclosed in a single prior art reference.

Patent Citations:

• US 6,226,680 B1

  • Full Citation: US 6,226,680 B1, "Intelligent network interface system method for protocol processing," issued May 1, 2001.
  • Publication/Filing Date: October 14, 1997 (Filing Date).
  • Brief Description: This patent describes an intelligent network interface system and method for offloading protocol processing from a host computer. It focuses on accelerating communication by handling protocols like TCP/IP on the network interface device itself, thereby reducing the host's processing load.
  • Potential Anticipation (35 U.S.C. § 102): This patent potentially anticipates aspects of claims 1, 9, 12, and 18, particularly regarding the concept of offloading protocol processing to network interface circuitry. Claims 1, 9, 12, and 18 all refer to the network interface circuitry having the capability to offload protocol processing. The specific emphasis on "protocol processing of received data for connections... offloaded to the network interface circuitry" in these claims directly aligns with the core subject matter of US 6,226,680 B1.

• US 6,434,620 B1

  • Full Citation: US 6,434,620 B1, "TCP/IP offload network interface device," issued August 13, 2002.
  • Publication/Filing Date: August 27, 1998 (Filing Date).
  • Brief Description: This patent details a TCP/IP offload network interface device designed to handle TCP/IP protocol processing, including checksum calculations and segmentation, on the network interface card rather than the host CPU.
  • Potential Anticipation (35 U.S.C. § 102): Similar to US 6,226,680 B1, this patent could anticipate elements of claims 1, 9, 12, and 18. Specifically, the mention of "protocol processing of received data" and the network interface circuitry handling such processing for offloaded connections is a key overlap. The capability to offload TCP/IP processing, as described in US 6,434,620 B1, is a fundamental aspect of the broader offloading function claimed in US 7,760,733.

• US 6,717,946 B1

  • Full Citation: US 6,717,946 B1, "Methods and apparatus for mapping ranges of values into unique values of particular use for range matching operations using an associative memory," issued April 6, 2004.
  • Publication/Filing Date: October 31, 2002 (Filing Date).
  • Brief Description: This patent describes methods and apparatus for efficient range matching operations using an associative memory (like a TCAM). This is particularly relevant for tasks such as packet classification and filtering where incoming data needs to be matched against a set of rules that may include ranges.
  • Potential Anticipation (35 U.S.C. § 102): This patent potentially anticipates elements of claims 2, 10, 13, 14, 15, and 17. These claims specifically describe using a content-addressable memory (TCAM) for determining actions and the ability to handle "don't care" values or range matching. The core concept of using associative memory for efficient rule lookup, as described in US 6,717,946 B1, is highly relevant to the lookup circuitry described in these claims of US 7,760,733.

• US 6,798,743 B1

  • Full Citation: US 6,798,743 B1, "Packet prioritization processing technique for routing traffic in a packet-switched computer network," issued September 28, 2004.
  • Publication/Filing Date: March 22, 1999 (Filing Date).
  • Brief Description: This patent introduces a technique for prioritizing packets in a network based on certain criteria, such as protocol type, source/destination, or application. It addresses the need for efficient traffic management in packet-switched networks.
  • Potential Anticipation (35 U.S.C. § 102): This patent might anticipate the prioritization aspects of claims 1, 9, 12, and 18. These claims emphasize determining a "highest priority one of a plurality of actions" based on an order. While US 6,798,743 B1 focuses on traffic routing, the underlying principle of assigning and acting upon priorities for network packets could be considered anticipatory to the prioritization scheme for offloaded processing versus filtering actions.

• US 7,031,267 B2

  • Full Citation: US 7,031,267 B2, "PLD-based packet filtering methods with PLD configuration data update of filtering rules," issued April 18, 2006.
  • Publication/Filing Date: December 21, 2000 (Filing Date).
  • Brief Description: This patent describes packet filtering methods using programmable logic devices (PLDs) where filtering rules can be dynamically updated. This addresses the need for flexible and adaptable packet filtering in network devices.
  • Potential Anticipation (35 U.S.C. § 102): This patent could anticipate aspects of claims 1, 9, 12, and 18, specifically regarding the filtering of received data. The concept of filtering ingress packets using hardware with updatable rules is directly relevant. The "filtering received data" action mentioned in these claims aligns with the primary function of US 7,031,267 B2.

• US 2005/0083935 A1

  • Full Citation: US 2005/0083935 A1, "Method and apparatus for two-stage packet classification using most specific filter matching and transport level sharing," published April 21, 2005.
  • Publication/Filing Date: October 20, 2003 (Filing Date).
  • Brief Description: This publication describes a method and apparatus for efficient packet classification using a two-stage filtering process, focusing on applying the most specific filter matching.
  • Potential Anticipation (35 U.S.C. § 102): This publication potentially anticipates elements of claims 1, 6, 7, 8, 9, 12, 18, 23, 24, and 25, which relate to filtering rules, processing characteristics of received data, and applying masks. The method of determining a specific filtering rule based on packet characteristics, especially with a "most specific filter matching" approach, directly relates to the filtering rule determination process described in US 7,760,733.

This analysis is based on the provided patent text and the general understanding of 35 U.S.C. § 102. A definitive determination of anticipation would require a detailed claim-by-claim comparison by a legal expert.

Obviousness Analysis under 35 U.S.C. § 103 for US Patent 7,760,733

To determine the obviousness of US Patent 7,760,733, we must consider whether the differences between the claimed invention and the prior art would have been obvious at the time of the invention to a person having ordinary skill in the art (PHOSITA). This analysis involves the Graham factors: (1) the scope and content of the prior art; (2) the differences between the prior art and the claims; (3) the level of ordinary skill in the pertinent art; and (4) secondary considerations of non-obviousness. The Supreme Court's decision in KSR International Co. v. Teleflex Inc. further emphasizes a "common sense" approach, stating that a combination of familiar elements according to known methods is likely to be obvious if it yields predictable results. A PHOSITA is a hypothetical person who is presumed to know the relevant art and possess ordinary creativity, but is not an inventor or genius.

Level of Ordinary Skill in the Art (PHOSITA)

For US Patent 7,760,733, which relates to filtering ingress packets in network interface circuitry, a PHOSITA would likely have a strong background in computer networking, network interface card (NIC) architecture, and network protocol processing. This would include knowledge of TCP/IP, Ethernet, and data link layer operations, as well as an understanding of hardware-accelerated packet processing and filtering techniques. Educational attainment for such a person would likely include at least a bachelor's degree in computer science or electrical engineering, with several years of experience in network device development or system administration.

Scope and Content of Prior Art

The "Prior Art Citations" section of US7760733B1 lists numerous patents that were considered during its examination. Many of these references generally relate to intelligent network interface devices, TCP/IP offload engines, packet processing, and filtering in network environments. Key themes among these cited patents include:

• TCP/IP Offload Engines (TOE): Many patents, such as US6226680B1 (Alacritech, Inc.), US6389479B1 (Alacritech, Inc.), US20020095519A1 (Alacritech, Inc.), and US6434620B1 (Alacritech, Inc.), describe intelligent network interface devices capable of offloading TCP/IP protocol processing from the host CPU to the NIC. These typically involve managing connection states (e.g., TCBs) in hardware.
• Packet Filtering and Classification: References like US6594268B1 (Lucent Technologies Inc.) and US6798743B1 (Cisco Technology, Inc.) describe systems for adaptive routing and packet prioritization, which inherently involve some form of packet classification or filtering. US7031267B2 (802 Systems Llc) explicitly discusses PLD-based packet filtering methods with configuration data updates of filtering rules.
• Content-Addressable Memories (CAMs/TCAMs): Several patents, such as US6717946B1 (Cisco Technology Inc.) and US6792502B1 (Freescale Semiconductor, Inc.), address the use of associative memories (including CAMs) for efficient matching operations, which are highly relevant to high-speed packet classification and lookup.
• Network Address Translation (NAT) and Load Balancing: The background of US7760733B1 itself mentions that NAT devices and load balancers can be efficiently implemented through filtering rules. Prior art related to these functionalities would also be relevant.

Differences Between the Prior Art and the Claims

The independent claims (1, 9, 12, and 18) of US7760733B1 generally describe a method and apparatus where network interface circuitry performs both protocol offloading and explicit packet filtering, with a priority mechanism that favors offloaded protocol processing. The key distinctions appear to be:

• Explicit Prioritization of Offloaded Connections over General Filtering: The patent emphasizes that the lookup circuitry is "configured to automatically provide the indication of the highest priority action, associated with the received data, based not only on whether the portion of the received data presented to the lookup circuitry matches data associated with an indication of an action but also based on an order of the indications of the plurality of actions relative to each other in the lookup circuitry, the indications of protocol processing for connections that have been offloaded being located to indicate, when applicable to particular received data, a higher priority than the filtering actions" (Claim 1).
• Filtering for Non-Offloaded Connections: Claim 9 specifically highlights determining a filtering rule "if the data is not data of a connection that is offloaded from the host." This implies a comprehensive filtering capability beyond just connection-specific processing.
• TCAM Organization for Priority: The detailed description (FIG. 3) explains that the TCAM entries are organized into "active connection," "server," and "filter" regions, with the lowest index values assigned to active connections to ensure priority.

Obviousness Combinations and Motivations

A PHOSITA, at the time of the invention, would have been motivated to combine existing technologies to achieve the functionalities described in US7760733B1, primarily due to known problems in network performance and security. The problem of host CPU overhead due to packet processing and the need for efficient network-level filtering were well-recognized.

Combination 1: TCP/IP Offload Engine (e.g., US6226680B1) + Packet Filtering (e.g., US7031267B2) + CAM/TCAM (e.g., US6717946B1)

• References:

  • US6226680B1 (Intelligent network interface system method for protocol processing): This patent teaches an intelligent NIC capable of offloading protocol processing, such as TCP/IP, from the host. It inherently involves matching incoming packets to offloaded connections.
  • US7031267B2 (PLD-based packet filtering methods with PLD configuration data update of filtering rules): This reference discloses packet filtering methods and dynamic updates of filtering rules.
  • US6717946B1 (Methods and apparatus for mapping ranges of values into unique values of particular use for range matching operations using an associative memory): This patent describes the use of associative memories (like CAMs) for efficient range matching, which is highly suitable for packet classification and filtering.

• Motivation for Combination: A PHOSITA would recognize the benefits of integrating packet filtering directly into an intelligent NIC already performing protocol offload.

  • Efficiency: Offloading protocol processing was motivated by reducing host CPU load. Extending this offload to general packet filtering (even for non-offloaded connections) would further reduce host overhead, as the NIC is already inspecting packet headers. This is explicitly stated in US7760733B1 as an advantage: "since the packets headers are already being evaluated to determine if the packets are of offloaded connections, little (if any) additional processing is required in the intelligent interface circuitry to match the packets with filtering actions."
  • Performance: Using a CAM or TCAM (as taught by US6717946B1) within the NIC's processing pipeline (as shown in FIG. 1 and FIG. 2 of US7760733B1) for both connection matching and filtering would offer high-speed, parallel lookups, improving overall throughput. This capability is inherent in TCAMs, which can match multiple rules in parallel and provide results in a pipelined fashion.
  • Security: Implementing a firewall directly on the NIC, as suggested by US7760733B1, would provide an early and efficient defense against network attacks (e.g., DoS attacks) before packets even reach the host's main network stack. US7031267B2 already teaches dynamically updated filtering rules, which are crucial for adaptive security measures.
  • Known Functionality: The idea of "filtering" packets in the context of offloaded connections (even implicitly) was already present in offload engines (US6226680B1 states they "filter" packets by associating them with connections). A PHOSITA would find it obvious to make this filtering explicit and configurable for other traffic, especially given the availability of dedicated filtering techniques (US7031267B2) and high-performance lookup mechanisms (US6717946B1).

Combination 2: TCP/IP Offload Engine with Connection State (e.g., US20030204631A1) + Priority Mechanisms in Network Devices (e.g., US7583596B1)

• References:

  • US20030204631A1 (Method to synchronize and upload an offloaded network stack connection with a network stack): This patent describes a method for offloading network stack connections and maintaining connection state, which is central to the "protocol processing of received data for connections... for which the protocol processing has been offloaded."
  • US7583596B1 (Priority scheduling using per-priority memory structures): This patent teaches priority scheduling in network devices using memory structures, indicating that prioritization is a known concept in network traffic management.

• Motivation for Combination: Given that intelligent NICs were already managing connection states for offloaded protocols (US20030204631A1), and that various forms of prioritization were common in network devices (US7583596B1), a PHOSITA would be motivated to explicitly prioritize offloaded connection processing over general packet filtering.

  • Logical Extension: Offloaded connections are critical for high-performance applications, and ensuring their packets are processed with the highest priority is a natural design choice. If a packet belongs to an offloaded connection, it should logically take precedence over a general filtering rule.
  • Optimizing Resource Usage: By prioritizing offloaded connections, the NIC can efficiently dedicate resources to these critical flows, while still providing a fallback filtering mechanism for all other traffic. The TCAM's inherent ability to return the "first matching entry" (lowest index value) (as described in US7760733B1) would provide a straightforward hardware mechanism to implement such a priority scheme, especially if entries for offloaded connections are physically placed at lower indices.

Predictable Results: The combination of these known elements would yield predictable results: improved network performance by reducing host overhead, enhanced security through early packet filtering, and efficient resource allocation by prioritizing critical offloaded connections. These are all well-understood objectives in network system design. The specific implementation using a TCAM with ordered regions to achieve this prioritization (as described in US7760733B1) would be considered a predictable engineering choice for a PHOSITA looking to optimize performance in a hardware-accelerated network device.

I'll research US Patent 7,760,733 on the USPTO and related databases, focusing on term adjustments, family members, and expiration.

Let me search for the specific term adjustment data and family details.

Term, Adjustment, and Family Analysis — US 7,760,733 B1

Scope note: I could not surface a live USPTO PatentCenter / Patent Application Locating and Monitoring (PALM) docket page for this patent through open web search in this session. The analysis below is therefore grounded in (a) the authoritative full-text record retrieved from the USPTO-mirrored Google Patents record for US7760733B1, and (b) the related records surfaced in search. Where a figure is derived by my own arithmetic rather than read directly off a USPTO determination, I say so explicitly.

---

1. Bibliographic anchor (from the authoritative record)

---

2. Patent Term Adjustment (PTA) — 35 U.S.C. § 154(b)

What the record shows: The record carries an explicit "Adjusted expiration: 2028-10-31" alongside the ordinary legal-status expiry of the same date. That adjustment is the fingerprint of a § 154(b) PTA award — the statutory 20-year term would otherwise have run from the filing date.

Derived PTA (my arithmetic, not a USPTO readout):

• Statutory 20-year term from filing 2005-10-13 → 2025-10-13
• Recorded adjusted expiration → 2028-10-31
• Implied PTA ≈ 1,114 days (3 years + 18 days; 2028 is a leap year, so the three full years 2025-10-13 → 2028-10-13 = 1,096 days, plus 18 days)

This magnitude is directionally consistent with the prosecution timeline: pendency from 2005-10-13 to 2010-07-20 is 1,741 days, which exceeds the 3-year "B-delay" trigger (1,096 days) by 645 days, before adding any "A-delay" (first Office Action beyond 14 months) and any "C-delay," less any applicant delay under 37 C.F.R. § 1.704.

Caveat / data gap: The exact PTA figure as determined by the Office is printed on the face of the patent as "…the term of this patent is extended or adjusted under 35 U.S.C. 154(b) by N day(s)." I was not able to retrieve that specific N from the front page or from a § 154(b) Determination notice in this session. The 1,114-day figure above is inferred from the adjusted-expiration date, not confirmed. If the number matters for a validity or damages analysis, it should be read off the issued patent's front page or the Issue Notification / PTA determination in the file history.

---

3. Patent Term Extension (PTE) — 35 U.S.C. § 156

None, and none available. PTE under § 156 is limited to patents claiming a drug, medical device, food additive, or color additive subject to a regulatory review period (FDA/USDA). US 7,760,733 claims network interface circuitry and packet filtering — no regulatory-review product. There is no PTE certificate and no basis for one. All search hits on "PTE" for this patent number returned unrelated pharmaceutical/§ 156 materials (e.g., the '285 and '257 patent extension petitions), which should not be attributed to this patent.

---

4. Terminal disclaimer

Not found in the retrieved record. No terminal disclaimer is reflected in the data available to me. Two practical notes:

• If a terminal disclaimer were on file, the effective term would be capped by the term of the reference patent despite the 1,114-day PTA — but I have no evidence of one.
• Even in the absence of a terminal disclaimer, note the well-established principle that PTA cannot extend a patent past a recorded terminal disclaimer date. Since the record shows an adjusted expiration of 2028-10-31 with no cap noted, the working assumption is that no disclaimer applies.

---

5. Continuations, divisionals, continuations-in-part

None identified. The record's family data is unambiguous:

• Priority Applications (1): only US 11/250,894
• Applications Claiming Priority (1): only US 11/250,894
• Family Applications (1): only US 11/250,894 (US7760733B1)
• Publications (1): only US7760733B1
• Priority date equals the filing date (2005-10-13), i.e., no parent priority claim (no § 120/§ 121/§ 119 benefit claim)

So US 7,760,733 appears to be a stand-alone original application with no continuation, no divisional, no CIP, and no parent in a formal priority chain.

Related-but-not-family Chelsio filings (do not confuse these with family members): the patent's "Non-Patent Citations" list refers to allowed claims in U.S. Appl. Nos. 10/474,500, 11/313,003, 11/356,850, and 11/330,898, and to office actions in several 11/137,xxx, 11/217,661, 11/282,933, 11/735,861, 11/747,650, 11/747,790, 11/747,793 applications. These are sibling Chelsio applications cited as related subject matter in Information Disclosure Statements — they are not linked to US 11/250,894 by any priority relationship shown in the record. Likewise, the 35 "Cited By" documents (e.g., US8139482, US8213427, US8339952, US8356112, US8589587, US8686838, US8935406, US9390056, US9444754 — several of them Chelsio's) merely cite this patent; citation is not family membership.

---

6. Related family members (Family ID 42332669)

Per the record, family 42332669 contains one member in one jurisdiction:

No PCT application, no EPO member, no foreign national-phase counterparts are listed. Note the "International Search Report in PCT/US02/12679" appearing in this patent's Non-Patent Citations belongs to a different Chelsio matter (a 2002-era PCT filing) and is not a family member of this patent.

---

7. Projected expiration date

Observation relevant to today's date (2026-04-26): The bare 20-year term lapsed on 2025-10-13, so the patent is alive only by virtue of the § 154(b) adjustment. The "Active" status and the freshly recorded Dec-2025/Feb-2026 transactions are consistent with a patent that still has ~2.5 years of enforceable term remaining.

Maintenance fees: All three maintenance-fee windows relative to the 2010-07-20 grant (3.5 yr ≈ 2014-01-20; 7.5 yr ≈ 2018-01-20; 11.5 yr ≈ 2022-01-20) have passed. An "Active" status implies all were timely paid, but I did not verify individual fee payments in a USPTO fee record.

---

8. ⚠️ Contradictions with the previously generated sections — flagged

Two prior sections are contradicted by the authoritative record and should be corrected:

1. Litigation. The prior "Litigation summary" states that as of April 26, 2026 "no known litigation cases specifically naming US Patent 7,760,733" exist. The authoritative record, however, contains a litigation entry: "Family has litigation — US case filed in Texas Western District Court," with docket link …/case/7%3A26-cv-00148 (Texas Western District Court, case 7:26-cv-00148), plus a "First worldwide family litigation filed" entry (Darts-ip family 42332669). Per the operating rule to prefer the record over prior conclusions, the litigation posture should be treated as active, not absent. (I note the case number's "26" prefix is consistent with a 2026 filing.)

2. Ownership / NPE assessment. The prior "Assignment history" section ends at the 2025-12-18 Western Alliance Bank release and concludes "Insufficient data… no signals to categorize it as an NPE asset." The authoritative record shows the chain did not stop there:

   • 2025-12-26 — RELEASE OF SECURITY INTEREST, assignor CSNK WORKING CAPITAL FINANCE CORP. → Chelsio (this is an additional secured party not previously listed).
   • 2026-02-13 — ASSIGNMENT OF ASSIGNOR'S INTEREST, assignor CHELSIO COMMUNICATIONS, INC. → assignee SPEEDNIC LLC, recorded as the Current Assignee.

   That is a transfer of ownership out of the operating company to a distinct LLC, occurring shortly before the 2026 Texas Western District Court filing. On the prior section's own rubric, this triggers at least the "shell-entity transfer" and "pre-litigation transfer" signals — and arguably a "cascading transfer" pattern — each of which the prior verdict scored as "Not present." The verdict should be revisited; "Insufficient data / no NPE signals" is no longer accurate. (I did not independently retrieve SPEEDNIC LLC's corporate history, so I state the signal, not a concluded characterization.)

There is no contradiction on the PTAB point: nothing in the authoritative record indicates any AIA trial proceeding, consistent with the prior "no PTAB activity" finding.

---

9. Confidence and open items

To close the gaps with certainty, the following primary documents should be pulled: (i) the printed front page of US 7,760,733 (states the exact § 154(b) adjustment in days); (ii) the Issue Notification / "Determination of Patent Term Adjustment" in the 11/250,894 file history; (iii) the USPTO Patent Term Adjustment determination and any Request for Reconsideration; (iv) the recordation of the 2026-02-13 Chelsio → SPEEDNIC LLC assignment (reel/frame) and SPEEDNIC LLC's formation/affiliation records; and (v) the complaint in Texas Western District Court case 7:26-cv-00148 to confirm asserted patents and claims.

(Primary citation: US7760733B1 on Google Patents — authoritative full text; assignment entries and the Texas Western District Court case reference are reproduced therein.)

I'll first ground the analysis by searching for the specific patent record, then build the defensive disclosure.

DEFENSIVE DISCLOSURE DOSSIER

Target patent: US 7,760,733 B1 — "Filtering ingress packets in network interface circuitry"

Document type: Prior-art-generating technical disclosure (defensive publication corpus)
Analysis date: April 26, 2026
Target patent identifiers (literal, as recorded): US 7,760,733 B1 · Application 11/250,894 · filed 2005-10-13 · granted 2010-07-20 · inventors Asgeir Thor Eiriksson and Chris Yuhong Mao · original assignee Chelsio Communications, Inc. · recorded current assignee per the patent record: SPEEDNIC LLC · family ID 42332669 (US-only, single member) · recorded adjusted expiration 2028-10-31.

Grounding note on the record (search performed): The USPTO-mirrored full text for US7760733B1 was retrieved and confirms the identifiers above; the patent number was queried literally (7760733), not a family variant. Two record facts materially shape this dossier and are carried forward, not re-litigated:

1. Litigation is active, contrary to the earlier "no known litigation" section. SpeedNIC LLC v. NVIDIA Corp. et al, No. 7:26-cv-00148, W.D. Tex., filed 04/16/2026 (§271 patent infringement; defendants NVIDIA Corp. and Dell Technologies Inc.; SpeedNIC LLC's Rule 7 disclosure identifies corporate parent SpeedNIC Holdings LLC). Public complaint analysis indicates independent claim 12 of the '733 patent is asserted, with the accused functionality being the DOCA Flow "pipe chaining" priority model on BlueField DPUs. (case, RPX)
2. Ownership moved out of the operating company. A 2026-02-13 ASSIGNMENT OF ASSIGNOR'S INTEREST from Chelsio Communications, Inc. to SPEEDNIC LLC precedes the April 2026 filing — consistent with the earlier Extensions-section flag.

Effect of this document: a defensive publication dated on or after today's date becomes prior art only against later-effective filings. It cannot invalidate US 7,760,733 (priority 2005-10-13). Its purpose is to occupy the improvement space around the four independent claims — including the spaces the pending litigation has made commercially contested — so that later-filed competitor improvements cannot be patented.

Method: all derivatives below are new technical matter. No recitation of the target patent's specification is provided. Each derivative names the axis, gives an enabling disclosure sufficient for reproduction by a person of ordinary skill (POSITA in NIC/DPU datapath design), and identifies the claim element it sweeps.

---

PART I — DERIVATIVES OF INDEPENDENT CLAIM 1

Claim 1 core: receive data at network interface circuitry → determine, via lookup circuitry, an indication of the highest-priority action among a plurality containing filtering and offloaded protocol processing, where priority arises from whether the presented data matches AND the order of the indications relative to each other in the lookup circuitry, offload indications being located to outrank filter indications → perform the indicated action.

---

DP-1.1 — eDRAM (2T-1C) ternary search plane replacing SRAM TCAM

Axis 1 — Material & Component Substitution

Enabling disclosure. Replace the 6T-SRAM ternary bitcells with 2-transistor/1-capacitor embedded-DRAM ternary cells: a complementary pair of cells encodes 0, 1, and don't-care as {Vbl_hi, Vbl_lo}, {Vbl_lo, Vbl_hi}, and {Vbl_lo, Vbl_lo}. Search lines are driven from a 512-bit key register; match lines are pre-charged and discharged through per-32-bit-chunk sense amplifiers, and a thermometer-code priority encoder resolves the lowest-index match in one cycle. Refresh is hidden by ping-pong banking: bank A serves searches while bank B refreshes, roles swap on alternate 4 ns windows, so the search port never stalls. Region ordering is preserved purely by monotonically increasing row index — offload-context rows at the lowest addresses, listening-server rows next, filter rows last. Rule writes land in a shadow bank and commit on a barrier signal, so no packet observes a partially written rule set. Area per rule drops ≈3× versus SRAM TCAM at equal key width, allowing ~8k rules in ~2 mm² at 16 nm.

Swept claim element. "order of the indications … relative to each other in the lookup circuitry" realized as physical row index in a capacitive cell array (not SRAM).

flowchart LR
  subgraph SP["eDRAM ternary search plane"]
    BA["Bank A rows 0 to 4095 offload and server regions"]
    BB["Bank B rows 4096 to 8191 filter region"]
    RF["Refresh sequencer with 4 ns ping pong window"]
  end
  PKT["Ingress frame from MAC"] --> HX["Header extractor builds 512 bit key plus mask"]
  HX --> ML["Match line drivers and per 32 bit sense amps"]
  ML --> BA
  ML --> BB
  RF -.->|alternate window| BA
  RF -.->|alternate window| BB
  BA --> PE["Thermometer priority encoder"]
  BB --> PE
  PE --> TID["Lowest matching row index returned as tid"]
  TID --> CB["Control block fetch and rank decode"]
  CB --> ACT["Action executor drop rewrite or pass"]

---

DP-1.2 — Nonvolatile MTJ (MRAM) ternary store with policy persistence across power loss

Axis 1 — Material & Component Substitution

Enabling disclosure. Each ternary cell is a 2T-2MTJ pair; "don't-care" is encoded when both magnetic tunnel junctions sit in the parallel low-resistance state. Matching is performed by a summed bias current on the match line compared against a reference pair of MTJs, giving a single-cycle search of a 288-bit key at 800 MHz at sub-picojoule write energy. Because state is nonvolatile, the rule image survives rail collapse and the device enforces policy within 10 µs of power-on — a requirement for always-on automotive edge and for tamper-respondent behavior in which removing power must not clear a deny policy. Writes are two-phase (write, then read-verify) with per-row ECC. A shadow row-bank plus a barrier token provides the atomic commit, and an MTJ snapshot ("golden image") permits instant reload after a verified corruption event.

Swept claim element. Lookup circuitry that returns the highest-priority indication when the ordering information is resident in nonvolatile, physically indexed storage that is valid before host software has run.

stateDiagram-v2
  [*] --> PowerOn
  PowerOn --> NvBoot : read MTJ rule image in 10 us
  NvBoot --> Enforcing : region map loaded offload first then server then filter
  Enforcing --> ShadowStage : host stages new rules through doorbell
  ShadowStage --> Verify : per row ECC and two phase write verify
  Verify --> Enforcing : barrier token commits whole image
  Verify --> Quarantine : any row fails verify
  Quarantine --> Enforcing : reload golden image from MTJ snapshot
  Enforcing --> PowerLoss : rail collapse
  PowerLoss --> PowerOn : state retained without refresh

---

DP-1.3 — Silicon-photonic wavelength-division search engine for 1.6 TbE and beyond

Axis 1 — Material & Component Substitution

Enabling disclosure. Key bits are amplitude-modulated onto N distinct wavelengths in a silicon-nitride waveguide (DWDM on-chip comb, 100 GHz spacing). Each rule is a bank of microring resonators (or Bragg gratings); a set resonator at a given wavelength encodes a "care" bit, an omitted resonator encodes don't-care (the wavelength traverses un-tapped and is not counted). Match detection is an inverted-logic photodiode at the end of each rule's tap line: a rule is declared a match when aggregate coupled light is below threshold, i.e. all cared-for bits aligned. Priority is realized geometrically: the tap bus is folded so the lowest-index rule couples first and produces the earliest electrical edge; a leading-edge discriminator with ~5 ps resolution therefore identifies the winning rule within one waveguide transit (~10 cm ≈ 50 ps of flight). Thermo-optic rings are locked by per-ring heaters under closed-loop dither, or use athermal cladding with negative thermal expansion.

Swept claim element. "lookup circuitry … based on an order of the indications … relative to each other" implemented in the optical domain, where order = physical position on the bus.

flowchart TB
  SRC["Co packaged comb laser 1024 wavelengths"] --> MOD["Key modulator bank driven by header bits"]
  MOD --> BUS["Folded tap waveguide bus"]
  subgraph RB["Rule bank low index first"]
    R0["Rule 0 resonators microrings"]
    R1["Rule 1 resonators microrings"]
    R2["Rule N resonators microrings"]
  end
  BUS --> R0
  R0 --> R1
  R1 --> R2
  R0 --> P0["Photodiode tap 0"]
  R1 --> P1["Photodiode tap 1"]
  R2 --> P2["Photodiode tap N"]
  P0 --> LE["Leading edge discriminator 5 ps"]
  P1 --> LE
  P2 --> LE
  LE --> IDX["Winning rule index tid"]
  IDX --> ACT["Action executor"]

---

DP-1.4 — Extreme-temperature ordered lookup (-55 °C to +225 °C) with Gray-coded priority

Axis 2 — Operational Parameter Expansion

Enabling disclosure. Implement the search plane in SOI-CMOS with body biasing and a bandgap-referenced current-mirror trip point so the sense amplifier threshold tracks carrier mobility across the range. Store rule state in the MTJ array of DP-1.2 for the hot half of the range (SRAM retention collapses above ~180 °C). Encode row indices in Gray code so that a single-bit index fault produces a detectable 1-bit transition violation rather than a silent priority inversion; a bitwise-majority vote over three temperature-margined replicas of the priority regions (N-modular redundancy, N=3 in avionics builds) recovers from a faulted replica. Above a 225 °C thermal trip, a hardware sequencer freezes rule writes and latches the last CRC-verified rule image; below -55 °C the search clock is divided to preserve setup margin.

Swept claim element. "highest priority action" determination that remains deterministic and verifiable over an industrial/extreme temperature envelope, including the case where the priority index itself is corrupted.

flowchart TD
  T["On die temperature sensor bridge"] --> BIAS["Body bias and bandgap referenced trip point"]
  RULE["Rule image in MTJ rows"] --> R1["Replica A"]
  RULE --> R2["Replica B"]
  RULE --> R3["Replica C"]
  KEY["Header key"] --> SA["Sense amplifiers with compensated threshold"]
  BIAS --> SA
  SA --> R1
  SA --> R2
  SA --> R3
  R1 --> VOTE["Bitwise majority voter"]
  R2 --> VOTE
  R3 --> VOTE
  VOTE --> GRAY["Gray coded index check"]
  GRAY --> PE["Priority encoder"]
  T --> GOV{"Temp above 225 C"}
  GOV -->|yes| FREEZE["Freeze rule writes and latch CRC verified image"]
  GOV -->|no| PE

---

DP-1.5 — Both ends of the scale: 3D-bonded in-package search die, and 512-port chassis-wide policy image

Axis 2 — Operational Parameter Expansion

Enabling disclosure. Nanoscale end: a dedicated search die is hybrid-bonded directly beneath the 112G SerDes tile (≈9 µm bond pitch, no TSVs), placing the key path one hop from the gearbox. Key assembly occurs in the PHY alignment FIFO so lookup begins ~3 ns after the start-of-frame delimiter. At 1.6 TbE with 32-byte minimum frames the arrival rate is one key per ~32 ns, so four search slices at 2 GHz sustain line rate with a 4-deep result reorder queue. Industrial end: a 512-port chassis distributes a versioned policy image over an in-band management VLAN; each line card verifies an image CRC, stages it in a shadow region, and applies it on a barrier token carried in the management stream, so all 512 ports flip policy within one management interval and no in-flight packet sees a mixed image (the distributed analogue of a single-device commit barrier).

Swept claim element. Scale-invariance of "presenting the … received data to lookup circuitry" and of the ordering semantics, from a single bonded die to a distributed multi-card policy fabric.

flowchart LR
  subgraph NANO["In package nanoscale path"]
    PHY["112G SerDes gearbox"] --> FIFO["Alignment FIFO key assembly"]
    FIFO --> DIE["Hybrid bonded search die 4 slices"]
    DIE --> RQ["Result reorder queue depth 4"]
  end
  subgraph FAB["Chassis wide industrial path"]
    MGMT["Management VLAN policy image versioned"] --> CRC["Image CRC verify"]
    CRC --> C1["Line card 1 shadow region"]
    CRC --> C2["Line card 2 shadow region"]
    CRC --> C3["Line card 512 shadow region"]
    C1 --> B1["Barrier token apply"]
    C2 --> B1
    C3 --> B1
  end
  RQ --> HOST["Host or DPU ingest"]
  B1 --> FABOUT["Uniform policy across all ports"]

---

DP-1.6 — Cross-domain: time-sensitive zonal Ethernet controller (industrial automation / avionics)

Axis 3 — Cross-Domain Application

Enabling disclosure. Apply ordered lookup to a zonal TSN controller. Region 0 holds the cyclic real-time streams (the analogue of offloaded connections: PROFINET IRT, EtherCAT, TTEthernet VLID flows) and performs the "protocol processing" — scheduled egress, cut-through forwarding, frame replication — for them. Region 1 holds safety and diagnostic filters. Region 2 holds best-effort IT traffic. Region membership is derived from the IEEE 802.1AS gPTP schedule window, so a filter that would reorder a scheduled frame cannot be placed beneath the schedule. Guard bands are computed from the grandmaster clock; the atomic-commit analogue is a configuration gate token transmitted on the engineering VLAN so a rule update cannot land mid-schedule. If the schedule table and the rule image disagree about a stream, the safety region (lowest index) wins and the stream is dropped with a per-stream fault counter — an intentionally deterministic failure.

Swept claim element. "filtering received data and protocol processing of received data for connections … offloaded" mapped onto scheduled real-time streams, with ordering tied to a synchronous time base.

flowchart TD
  GM["802.1AS grandmaster clock"] --> WIN["Schedule window generator"]
  WIN --> GATE["Configuration gate token"]
  FR["Ingress frame with VLAN and PCP"] --> LOOK["Ordered lookup"]
  subgraph REG["Region order lowest first"]
    R0["Region 0 cyclic real time streams"]
    R1["Region 1 safety and diagnostic filters"]
    R2["Region 2 best effort IT"]
  end
  LOOK --> R0
  R0 --> R1
  R1 --> R2
  GATE --> LOOK
  R0 --> SCHED["Scheduled egress cut through"]
  R1 --> SF["Safety decision or drop with fault counter"]
  R2 --> BE["Best effort queue"]
  SCHED --> OUT["Zonal egress ports"]
  SF --> OUT
  BE --> OUT

---

DP-1.7 — Cross-domain: NVMe-oF / iSCSI target HBA ingress policy

Axis 3 — Cross-Domain Application

Enabling disclosure. Region 0 holds NVMe-oF queue-pair contexts (subsystem NQN, controller ID, SQID/CQID, host NQN hash, transport tag) — the offloaded protocol processing being the fabric transport itself. Region 1 holds fabric ACLs (initiator NQN → permitted namespace set). Region 2 is default-deny for unprovisioned initiators. The 8-tuple analogue is (transport tag, NQID, NSID, transport type, port, VLAN, destination MAC, NQN hash). Critically, "reject" emits a transport-legal completion with an NVMe status code (or SCSI sense) rather than a silent drop, so the initiator does not enter a controller-reset recovery storm; the control block carries the status byte to emit. "Rewrite" covers namespace-ID virtualization with transport-header CRC regeneration — the structural analogue of LIP/LP rewrite plus checksum recomputation.

Swept claim element. "applying a particular filtering rule … not providing the received data to the host and modifying the received data" in a storage-fabric context where rejection must be protocol-shaped.

sequenceDiagram
  participant I as Remote initiator NQN
  participant N as Target HBA ordered lookup
  participant C as Control block store
  participant H as Host block stack
  I->>N: NVMe-oF capsule with command and NSID
  N->>N: extract transport tag NQID NSID VLAN dest MAC
  N->>C: region 0 queue pair context lookup
  alt queue pair found
    C-->>N: offload transport processing context
    N->>H: deliver command with data placement
  else no queue pair
    N->>C: region 1 fabric ACL lookup
    alt ACL permits namespace
      C-->>N: rewrite NSID to exposed namespace
      N->>H: deliver with recomputed transport CRC
    else ACL denies or unprovisioned
      C-->>N: status 0x02 invalid field
      N-->>I: transport legal completion no host delivery
    end
  end

---

DP-1.8 — Emerging-tech integration: learned rule placement, streaming telemetry, ledgered policy provenance

Axis 4 — Integration with Emerging Tech

Enabling disclosure. (a) AI-driven optimization: a host-resident agent ingests per-row hit counters and per-region miss rates (exported over the same PCIe doorbell/DMA channel used for rule writes) and periodically re-emits the rule image with rows permuted so the hottest deny rules land in the fastest slice. Because priority is carried by an explicit rank field rather than by the permutation, permutations can never alter policy semantics — the critical safety property. A 4-bit-quantized gradient-boosted model runs on the NIC's embedded micro-controller for a fast local loop; the model blob is signed and versioned, and the agent may only reorder rows within a region. (b) IoT telemetry: per-row counters are exported as IPFIX with an enterprise element carrying rule ID and region index, allowing a plant-resident IoT gateway to correlate ingress drops with a physical line stoppage. (c) Ledger: each committed image is hashed (SHA-256 over the canonical row serialization) and the digest is anchored in a permissioned ledger as a policy revision, so a device can present its digest at attestation and yield an auditable who-changed-the-firewall chain.

Swept claim element. "automatically provide the indication of the highest priority action" where the ordering is machine-optimized but provably policy-preserving, and where the resulting decisions are independently auditable.

flowchart TD
  KPI["Per row hit counters and miss rates"] --> AG["Host reinforcement agent"]
  AG --> MODEL["Signed quantized model on NIC micro controller"]
  MODEL --> PLAN["Proposed row permutation within region bounds"]
  PLAN --> SIGN["Image signing and canonical hash"]
  SIGN --> LEDGER["Permissioned ledger policy revision anchor"]
  SIGN --> COMMIT["Barrier commit to search plane"]
  COMMIT --> ENF["Ordered lookup enforced"]
  ENF --> KPI
  ENF --> IPFIX["IPFIX stream with rule ID and region index"]
  IPFIX --> IOT["Plant IoT gateway and SIEM correlation"]
  LEDGER --> ATTEST["Device attestation presents digest"]

---

DP-1.9 — Inverse / failure mode: quarantine-on-fault, clock-gated low-power mode, ROM-anchored bypass conduit

Axis 5 — The "Inverse" or Failure Mode

Enabling disclosure. (a) Row quarantine: an ECC/parity error in a rule row causes the hardware to remove that row from the search set rather than search it, raise a fatal-to-host interrupt, and — if the quarantined row is in the offload region — clear that connection's valid bit so the connection demotes to host software offload (a per-connection fail-open that keeps the session alive). (b) Low-power limited-functionality mode: the filter region clock is gated and unmatched packets are forwarded to the host's own policy engine; only region 0 remains powered, drawing ~1/20 the active power, and because region-0 ordering is preserved, offloaded flows are bit-for-bit unaffected by the degradation. (c) Tamper-respondent bypass conduit: a physical switch places the filter region into a ROM-resident read-only minimal deny-list; the host cannot widen it without a signed image, so a compromised host cannot unilaterally disable filtering. (d) Watchdog: a comparator recomputes the rule-region CRC every 1 ms; on mismatch it reloads the golden image and increments a monotonic, write-once event counter.

Swept claim element. "performing the indicated highest priority one of the plurality of actions" where the default behavior upon hardware fault is a defined, safe, and auditable action rather than silent pass-through.

stateDiagram-v2
  [*] --> FullEnforcement
  FullEnforcement --> RowQuarantine : ECC error in a rule row
  RowQuarantine --> DemotedConnection : faulted row is an offload context
  DemotedConnection --> FullEnforcement : CB invalidated and connection moved to host stack
  FullEnforcement --> LowPower : host requests limited functionality mode
  LowPower --> FullEnforcement : filter region clock re enabled
  FullEnforcement --> RomBypass : tamper switch asserted
  RomBypass --> FullEnforcement : signed image supplied to restore writable filters
  FullEnforcement --> WatchdogReload : rule region CRC mismatch
  WatchdogReload --> FullEnforcement : golden image restored and event counter incremented

---

PART II — DERIVATIVES OF INDEPENDENT CLAIM 9

Claim 9 core: (a) receive data nominally from the peer; (b1) if the data belongs to an offloaded connection → communicate per protocol with the peer and pass resulting data to the host; (b2) if not offloaded and at least one filtering rule exists → automatically determine which filtering rule applies; the determination based on match and on the relative order of the indications; then apply the determined highest-priority filtering rule.

---

DP-9.1 — Asymmetric hybrid: hashed connection database + rank-sorted filter array with a min-rank arbiter

Axis 1 — Material & Component Substitution

Enabling disclosure. Split the two databases across different memory technologies. The offloaded-connection database becomes a hash table: the 4-tuple is hashed to a 16-bit index into a bucket array, and the full tuple is compared to defeat collisions; an overflow pointer covers buckets of depth > 1. The filter database remains an ordered, rank-encoded array. Each path independently returns a candidate {tid, rank} — connection entries emit rank 0, listening-server entries rank 1, filter entries rank ≥2 — and a min-rank selector with a tie-break toward the connection path reproduces the "offload outranks filter" rule without requiring a single unified memory technology. A double miss yields a designated default candidate (rank MAX) that carries the configured default action. Total lookup is 1 hash probe plus 1 array probe, both issued in parallel.

Swept claim element. "(b1) if the data is data of a connection that is offloaded … (b2) if the data is not data of a connection that is offloaded" — realized as two physically distinct databases arbitrated by explicit rank.

flowchart LR
  K["Parsed header key"] --> HSH["Hash of 4 tuple to bucket index"]
  K --> ARR["Rank sorted filter array"]
  HSH --> BKT["Bucket with full tuple compare"]
  BKT --> CAND1["Candidate tid rank 0 or 1"]
  ARR --> CAND2["Candidate tid rank 2 or higher"]
  CAND1 --> MIN["Min rank selector"]
  CAND2 --> MIN
  MIN --> TIE{"Equal rank"}
  TIE -->|yes| CONN["Break tie toward connection path"]
  TIE -->|no| WIN["Winning action"]
  CONN --> WIN
  MIN --> DEF["Default candidate rank MAX"]
  DEF --> WIN
  WIN --> AP["Apply rule or offloaded protocol processing"]

---

DP-9.2 — Result cache with O(1) epoch invalidation under high rule churn

Axis 2 — Operational Parameter Expansion

Enabling disclosure. Add a 4k-entry, 8-way result cache keyed by the 8-tuple. A hit bypasses both the hashed connection database and the ordered filter array and returns the cached action, including the negative result "no matching rule → default action", which is the dominant outcome in many deployments. Each cache line carries a 32-bit policy epoch; the host increments the epoch on every image commit, which invalidates the whole cache in O(1) with no scrub, no walk, and no coherence traffic. Under a 100k rule-updates-per-second workload the steady state is an epoch bump roughly every 10 µs; the pipeline absorbs this by tagging in-flight lookups with the epoch they entered under, so packets in flight are consistently processed against exactly one policy version (preserving the atomicity guarantee across the cache boundary). Cache lines also store the rewrite tuple (LIP/LP or NSID remap) to avoid re-reading the control block.

Swept claim element. "automatically determining an action that is a particular one of the filtering rules associated with characteristics of the received data" at churn rates where per-update invalidation is infeasible.

sequenceDiagram
  participant H as Host policy agent
  participant N as NIC pipeline
  participant C as Result cache 4k x 8 way
  participant F as Ordered filter array
  H->>N: commit new rule image
  N->>C: increment 32 bit policy epoch
  C-->>N: all lines stale by epoch comparison
  N->>C: lookup 8 tuple with current epoch
  alt cache hit with matching epoch
    C-->>N: cached action including negative default
    N->>N: apply action without filter array access
  else cache miss or stale epoch
    N->>F: ordered filter lookup and connection hash lookup
    F-->>N: winning rule or default
    N->>C: install result tagged with current epoch
  end

---

DP-9.3 — Hierarchical cluster/slice lookup scaling to 1,000,000 rules at two serial searches

Axis 2 — Operational Parameter Expansion

Enabling disclosure. Two-stage hierarchy: a cluster table of 1k entries holds coarse keys (destination prefix, protocol, port class, VLAN group) and, on a hit, names one of 64 rule slices; each slice is a 16k-row ordered search plane, giving a 64 × 16k = ~1M rule capacity at the cost of two serial searches (~8 ns at 1 GHz). Only the matched slice is searched, so energy scales with the occupied cluster, not the total rule count. The global priority order is total and unambiguous because cluster index dominates slice index: a rule in cluster 3 always outranks any rule in cluster 7 regardless of in-slice position. Cluster keys are produced by a small on-NIC classifier (protocol parser output plus a programmable 32-bit field extractor), and the cluster table itself is rank-ordered so it can also host "shadow" high-priority clusters for emergency deny rules.

Swept claim element. "determining … a particular one of the filtering rules" where the rule universe exceeds a single search plane and the ordering must remain globally consistent.

flowchart TD
  K["Header key"] --> CL["Cluster table 1024 rank ordered entries"]
  CL --> HIT{"Cluster hit"}
  HIT -->|no| DEF["Default action from last cluster"]
  HIT -->|yes| SEL["Select one of 64 rule slices"]
  SEL --> S0["Slice 0 rows 0 to 16383"]
  SEL --> S1["Slice 1 rows 0 to 16383"]
  SEL --> S63["Slice 63 rows 0 to 16383"]
  S0 --> RANK["Global rank encode cluster then slice"]
  S1 --> RANK
  S63 --> RANK
  RANK --> WIN["Single highest priority rule"]
  WIN --> ACT["Apply action"]
  DEF --> ACT

---

DP-9.4 — Cross-domain: application delivery controller / web application firewall with L7 key material

Axis 3 — Cross-Domain Application

Enabling disclosure. Extend the key beyond L2–L4 with shallow L7 extraction performed in fixed-function parse blocks: HTTP request line method and path prefix, Host header value hash, TLS ClientHello SNI and ALPN, and HTTP/2 :authority. The offload region holds terminated TLS sessions (the offloaded protocol processing is the crypto/TCP state). The filter region holds WAF signatures and virtual-service routing, and the relative order of indications encodes signature precedence (e.g., paranoia-level band 1 beneath band 2 beneath an always-deny emergency band). Rewrite actions implement host-header normalization and upstream selection. Because the ordering semantics are positional, an update that inserts a new signature does not perturb the precedence of existing signatures — a requirement for change-controlled WAF deployments with signed rule packs.

Swept claim element. "characteristics of the received data" extended to application-layer fields while retaining a single ordered decision.

flowchart LR
  C["Client TCP stream"] --> P["Fixed function parser"]
  P --> K1["L4 tuple"]
  P --> K2["TLS SNI and ALPN"]
  P --> K3["HTTP method path and Host hash"]
  K1 --> LK["Ordered lookup"]
  K2 --> LK
  K3 --> LK
  subgraph WAF["Order of indications"]
    T0["TLS session offload context"]
    T1["Virtual service routing"]
    T2["WAF paranoia band 1"]
    T3["WAF paranoia band 2"]
    T4["Emergency deny band"]
  end
  LK --> T0
  T0 --> T1
  T1 --> T2
  T2 --> T3
  T3 --> T4
  T4 --> ACT["Serve drop or rewrite to upstream"]

---

DP-9.5 — Cross-domain: SMPTE ST 2110 broadcast media node (PTP-timed professional video)

Axis 3 — Cross-Domain Application

Enabling disclosure. In an ST 2110 media node, essences (video, audio, ancillary) arrive as RTP/UDP multicast flows described by SDP. Region 0 holds adopted streams — session contexts carrying SSRC, PT, packet-time geometry, and the ST 2059/PTP-aligned playout buffer mapping — the offload processing being RTP sequence handling and SMPTE ST 2022-7 seamless protection (hitless merge of two redundant paths). Region 1 holds essence-level filters (unauthorized multicast group joins, payload-type admission, malformed SDP-derived parameters). Region 2 holds housekeeping traffic. Because ST 2022-7 requires deterministic merge, the ordering guarantee is used to ensure a stream's two legs always select the same policy entry — asymmetry between legs would break hitless switching. Rejections are counted per essence and exported via the node's NMOS/IS-04 registry telemetry.

Swept claim element. Application of ordered, connection-favoring lookup to media-essence streams where per-leg policy asymmetry is operationally catastrophic.

flowchart TD
  LD["SDP derived stream descriptors"] --> REG0
  A["Leg A RTP packets"] --> LK["Ordered lookup"]
  B["Leg B RTP packets"] --> LK
  subgraph ESS["Order of indications"]
    REG0["Region 0 adopted SSRC session contexts"]
    REG1["Region 1 essence admission filters"]
    REG2["Region 2 housekeeping"]
  end
  LK --> REG0
  REG0 --> REG1
  REG1 --> REG2
  REG0 --> MERGE["ST 2022-7 hitless merge on aligned legs"]
  REG1 --> DROP["Drop with per essence counter"]
  REG2 --> HK["Best effort handling"]
  MERGE --> PLAY["Playout buffer"]
  DROP --> NMOS["NMOS telemetry export"]

---

DP-9.6 — Integration: compiler-born policy, cooperative multi-tenant schedulers, and rule provenance

Axis 4 — Integration with Emerging Tech

Enabling disclosure. A policy compiler lowers high-level intent (declarative policy, Kubernetes NetworkPolicy, or a Rego/OPA bundle) into an ordered row image, with an SMT-style overlap solver that proves no unintended shadowing exists: for every pair of rows the solver checks whether the lower-ranked row is reachable, and unreachable rows are flagged at compile time, not at runtime. Multiple tenants are supported by per-VF ordered contexts sharing one physical search plane via a context-select field in the key's high bits; tenants cannot see or perturb each other's ordering. An AI classifier bootstraps a "learned default region" from observed flows within a tenancy, but is only permitted to emit rows below the tenant's explicit policy floor. Every compiled image carries a content digest and a compiler version, and the digest is anchored in a transparency log, so a tenant can prove which policy was in force at any past timestamp.

Swept claim element. "automatically determining an action that is a particular one of the filtering rules" where the rule set is machine-compiled with a machine-checkable ordering proof.

flowchart TD
  INTENT["Declarative policy or Rego bundle"] --> CMP["Policy compiler"]
  CMP --> SMT["Overlap and shadowing solver"]
  SMT --> FLAG{"Unreachable row detected"}
  FLAG -->|yes| REJECT["Reject image with counterexample"]
  FLAG -->|no| IMG["Ordered row image with tenant context bits"]
  AI["Learned default region from observed flows"] --> FLOOR["Floor check against explicit tenant policy"]
  FLOOR --> IMG
  IMG --> DIG["Content digest and compiler version"]
  DIG --> LOG["Transparency log anchor"]
  IMG --> COMMIT["Per VF ordered context commit"]
  COMMIT --> ENF["Enforcement with shared search plane"]

---

DP-9.7 — Inverse / failure mode: fail-open conduit, golden read-only floor, and non-silent degradation

Axis 5 — The "Inverse" or Failure Mode

Enabling disclosure. A deliberately fail-open-by-policy architecture with mandatory observability. (a) If the filter database cannot be read (bus error, ECC exhaustion, thermal trip), the engine switches to a host-directed conduit: packets that would have been filtered are delivered to a dedicated host queue with a side-band metadata word stating why the filter decision was unavailable, so the host can apply its own policy rather than silently accepting traffic. (b) A golden read-only floor — a small ROM-resident rule set — remains searchable in every degraded mode and sits at the highest rank, so a minimum deny set (management-plane lockout prevention and known-bad source ranges) is never lost. (c) Degradation is non-silent: every transition increments a monotonic counter, raises an interrupt, and emits a synthetic IPFIX record; the counter is write-once so a compromised host cannot erase the evidence of a bypass event. (d) A "cold-standby" mode runs the search plane at reduced frequency with a correspondingly reduced line rate rather than dropping traffic.

Swept claim element. "if the data is not data of a connection that is offloaded … and if there is at least one action that is a filtering rule … automatically determining an action" — including the defined behavior when the determination itself is unavailable.

stateDiagram-v2
  [*] --> Normal
  Normal --> Conduit : filter database unreadable
  Conduit --> Normal : database restored and CRC verified
  Normal --> GoldenFloor : thermal trip or bus fault escalation
  GoldenFloor --> Conduit : only ROM deny floor remains searchable
  GoldenFloor --> Normal : cooling restored verified image reload
  Normal --> ColdStandby : power or thermal budget reduction
  ColdStandby --> Normal : budget restored
  Conduit --> Evidence : emit synthetic IPFIX and bump write once counter
  GoldenFloor --> Evidence
  ColdStandby --> Evidence
  Evidence --> [*] : audit trail persists

---

PART III — DERIVATIVES OF INDEPENDENT CLAIM 12

Claim 12 core: network interface circuitry with (i) circuitry to receive data from the network; (ii) circuitry to process received data to determine an indication of the highest-priority action, presenting it to lookup circuitry, priority based on match and on the relative order of the indications in the lookup circuitry, the actions including protocol processing for the connection to which the data belongs or filtering for data not belonging to a connection whose protocol processing is handled by the NIC; (iii) circuitry to provide to the host the data with the action applied, selectively blocking the data from reaching the host when the action is a filtering rule.

---

DP-12.1 — Form-factor and host-attach substitution: OCP NIC 3.0, DPU/IPU SoC, chiplet on a CXL-attached accelerator, and CXL.mem host delivery

Axis 1 — Material & Component Substitution

Enabling disclosure. Realize claim 12's circuitry in four attach topologies with identical policy semantics. (i) OCP NIC 3.0 small form factor: the search plane and the blocking path live entirely in the card, which may be host-powered or auxiliary-powered. (ii) DPU/IPU SoC: the ordered search plane is a block within a multi-die SoC that also contains general-purpose cores; the "host" to which data is provided is reachable over the same die-to-die fabric, so the blocking decision is enforced at the SoC's host-facing DMA engine. (iii) Chiplet: the search-and-filter block is a discrete chiplet on a UCIe die-to-die link, allowing a CPU vendor to instantiate the policy block without redesigning the CPU. (iv) CXL-attached: the block sits behind a CXL 3.x port and delivers admitted data via CXL.mem writes into a host-pinned buffer, with the blocking decision implemented as a write-suppression at the CXL transaction layer. In all four, the ordering table is byte-identical, so policy is portable across form factors.

Swept claim element. "Network interface circuitry configured to couple a host computer to a network" and "circuitry configured to provide, to the host computer, the received data," generalized across card, SoC, chiplet, and cache-coherent-attach topologies.

flowchart LR
  NET["Network ports"] --> RX["Receive and parse block"]
  RX --> SP["Ordered search plane chiplet or SoC block"]
  SP --> DEC{"Winning action"}
  DEC -->|filter rule reject| BLK["Write suppression engine"]
  DEC -->|filter rule accept with rewrite| RW["Rewrite and checksum regenerate"]
  DEC -->|offload protocol processing| OFF["Protocol engine"]
  RW --> DEL1["DMA to host memory"]
  OFF --> DEL2["Completion and data placement"]
  BLK --> CNT["Drop counter and telemetry"]
  subgraph ATT["Host attach options"]
    P1["OCP NIC 3.0 PCIe"]
    P2["DPU SoC internal fabric"]
    P3["UCIe chiplet link"]
    P4["CXL 3.x coherent port"]
  end
  DEL1 --> ATT
  DEL2 --> ATT

---

DP-12.2 — Blocking-mechanism substitution: six ways to prevent host delivery

Axis 1 — Material & Component Substitution

Enabling disclosure. "Selectively block … from being provided to the host computer" is reducible to a family of enforcement mechanisms, each a functional equivalent for a different threat model: (1) payload flush — the header is discarded and the payload buffer is reclaimed before the DMA scheduler can attach it; (2) write-suppression at the IOMMU/DMA boundary — the block decision removes the descriptor from the completion ring entirely; (3) quarantine to a shadow VF where the traffic is delivered to a decoy or analysis VM rather than the target, enabling honeypot observation; (4) protocol-shaped rejection — emit a TCP RST, an ICMP destination/administratively-prohibited, or an NVMe/SCSI error completion on the wire so the peer learns rather than retries; (5) sinkhole accounting — deliver to an internal counter-only queue that consumes the frame and exports a statistic, used for volumetric attack absorption; (6) rate-limited passthrough — deliver to the host but through a policed queue, i.e., blocking in the aggregate rather than the individual. The selection is a per-rule field, allowing one policy image to mix mechanisms by rule class.

Swept claim element. "configured to selectively block the received data from being provided to the host computer" as a mechanism-agnostic genus with six disclosed species.

flowchart TD
  W["Winning action is a filter rule with block semantics"] --> SEL["Per rule enforcement selector"]
  SEL --> M1["Payload flush and buffer reclaim"]
  SEL --> M2["Descriptor removal at DMA boundary"]
  SEL --> M3["Quarantine to shadow VF or honeypot"]
  SEL --> M4["Protocol shaped rejection RST ICMP NVMe status"]
  SEL --> M5["Sinkhole accounting queue"]
  SEL --> M6["Rate limited policed passthrough"]
  M1 --> NH["No host delivery"]
  M2 --> NH
  M3 --> DV["Delivery to analysis endpoint only"]
  M4 --> WIRE["Rejection emitted on network"]
  M5 --> STAT["Counters and packet capture"]
  M6 --> HOST["Host delivery at bounded rate"]

---

DP-12.3 — Operational parameter expansion: per-PF ordered contexts at 800G, and a 25 W envelope variant

Axis 2 — Operational Parameter Expansion

Enabling disclosure. (a) Multi-tenant 800G: 128 PF/VF contexts each maintain an independent ordered rule region; a single physical search plane is time-multiplexed at 2 GHz across contexts using a context tag in the key's high bits, so each tenant observes an independent total order and cannot infer another tenant's policy from shadowing behavior. At 800G with 64-byte frames there are ~1.5 G lookups/s, so the plane must sustain ~2 lookups per 1.33 ns slot; a 2-slice interleave with per-slice context pipelining meets this with a 6-slot latency. (b) 25 W OCP-class envelope: the same ordering semantics implemented with a clock-gated search plane (idle slices off), a 1-lookup-per-cycle single slice, and BPF-like rule compression that merges adjacent rows with identical actions — measured in a reference implementation as a ~4× energy reduction with identical decision outcomes for the retained rule set.

Swept claim element. "highest priority one of a plurality of actions" determined independently per virtualization context, and scaling the same ordered-lookup semantics across a 30× power range.

flowchart LR
  F["Frames from 800G ports"] --> PIPE["Header parse and context tag stamp"]
  PIPE --> I0["Interleave slot 0"]
  PIPE --> I1["Interleave slot 1"]
  subgraph CTX["Per context ordered regions"]
    C0["PF0 ordered region"]
    C1["PF1 ordered region"]
    CN["PF127 ordered region"]
  end
  I0 --> CTX
  I1 --> CTX
  CTX --> RES["Result with context and rank"]
  RES --> SCH["Egress scheduler"]
  SCH --> H["Host or VF delivery with block or rewrite applied"]
  PWR["Power governor 25 W to 75 W"] --> CG["Clock gating and row merging compression"]
  CG --> CTX

---

DP-12.4 — Cross-domain: substation and microgrid protection IED (IEC 61850 GOOSE / SV)

Axis 3 — Cross-Domain Application

Enabling disclosure. In a digital substation merging unit or protection IED, the "offloaded protocol processing" region holds SV (Sampled Values) and GOOSE publisher/subscriber contexts: APPID, destination multicast MAC, gocbRef/svID, confRev, and the stNum/sqNum sequence state machine. The filter region holds publisher admission rules (which APPIDs from which physical ports are allowed into the process bus) and protective interlocks expressed as header predicates. Region ordering places the process-bus contexts at the lowest index so that protection traffic is never shadowed by an administrative rule — a safety argument that can be documented as a fixed ordering invariant. Blocking must be silent and fast (sub-microsecond, no rejection messages, since the process bus is not a conversational protocol) and must increment per-APPID counters used by the station HMI. Rewrite is used for VLAN translation between the process bus and the station bus, with frame CRC regeneration and without altering the SV payload.

Swept claim element. "filtering for received data which does not belong to a connection whose protocol processing is being handled by the network interface circuitry" in a hard-real-time, non-conversational industrial context where the ordering invariant is a safety property.

flowchart TD
  MU["Merging unit sampled values"] --> IN["Process bus ingress"]
  GO["GOOSE publisher"] --> IN
  IN --> LK["Ordered lookup with APPID and MAC keys"]
  subgraph PB["Process bus ordering"]
    R0["Region 0 SV and GOOSE contexts"]
    R1["Region 1 publisher admission"]
    R2["Region 2 station bus VLAN translation"]
  end
  LK --> R0
  R0 --> R1
  R1 --> R2
  R0 --> PROT["Protection algorithm and trip logic"]
  R1 --> BLK["Silent block with per APPID counter"]
  R2 --> RW["VLAN rewrite and CRC regeneration"]
  BLK --> HMI["Station HMI counters"]
  RW --> SB["Station bus egress"]

---

DP-12.5 — Integration: hardware-attested rule-image binding and remote verifiability of the block path

Axis 4 — Integration with Emerging Tech

Enabling disclosure. Bind the ordered rule image to a hardware root of trust. At manufacturing, a device identity key is provisioned; each committed policy image digest is measured into a replay-protected monotonic counter and extended into a PCR-like register. A remote verifier uses a DMTF SPDM exchange (or a TCG-style quote over the local measurement) to obtain signed evidence of (i) firmware version, (ii) the active rule-image digest, and (iii) the policy epoch counter. Because the block path is a hardware decision, this evidence is meaningful in a way that host-software firewall attestation is not — the verifier learns what the NIC will actually do with a packet, not what the host claims it will do. An AI-driven anomaly detector consumes the per-rule counters and emits tamper-suspicion events when the counter trajectory diverges from the attested policy's expected profile (e.g., a rule that should be hot goes cold, indicating a row was quarantined or shadowed). Digests are anchored in an external transparency log for third-party audit.

Swept claim element. "circuitry configured to provide, to the host computer, the received data having the particular indicated highest priority action applied" combined with externally verifiable proof that the ordering image is the one attested.

sequenceDiagram
  participant M as Manufacturer provisioning
  participant N as NIC root of trust
  participant V as Remote verifier
  participant L as Transparency log
  participant A as AI anomaly detector
  M->>N: provision device identity key and monotonic counter
  N->>N: measure firmware digest
  V->>N: SPDM challenge for evidence
  N-->>V: signed evidence firmware digest rule image digest epoch
  V->>L: fetch published digest anchor
  L-->>V: matching anchor confirms policy provenance
  N->>A: per rule counters and region hit rates
  A-->>V: tamper suspicion alert on counter divergence
  V->>N: request remediation or quarantine command

---

DP-12.6 — Inverse / failure mode: fail-safe by construction with an electromechanical bypass relay

Axis 5 — The "Inverse" or Failure Mode

Enabling disclosure. Design the card so that the absence of control yields a known state. A fail-safe relay in series with the host-facing link is held closed by a supervisory "policy alive" signal generated by the search plane's watchdog (a periodic token that only the functioning pipeline can produce). Loss of that token — firmware hang, thermal shutdown, loss of search-plane clock, or deliberate assertion by a tamper circuit — opens the relay, physically severing host reachability while the policy is not enforced, rather than allowing an unenforced pass. A journaling bypass counter records relay open time. The inverse design ("fail-closed by default") is deliberately contrasted with DP-9.7's fail-open conduit: the two variants bracket the design space, and both are enabled here. Additional limited-functionality variant: with the relay open, the NIC continues to emit out-of-band deny-only enforcement by synthesizing RST/ICMP for the ROM-resident golden floor, so a minimum protection level survives even when host delivery is severed.

Swept claim element. "selectively block the received data from being provided to the host computer" extended to a mode in which all data is blocked pending restored enforcement, with the block being physical rather than logical.

stateDiagram-v2
  [*] --> RelayClosed
  RelayClosed --> RelayClosed : watchdog token present
  RelayClosed --> RelayOpen : token loss or tamper assert
  RelayOpen --> DenyOnly : ROM golden floor active
  DenyOnly --> RelayOpen : synthesized rejection continues
  RelayOpen --> RelayClosed : token restored and image CRC verified
  RelayClosed --> RelayOpen : thermal shutdown
  RelayOpen --> Journal : record open duration and cause
  Journal --> RelayClosed : post incident audit

---

PART IV — DERIVATIVES OF INDEPENDENT CLAIM 18

Claim 18 core: the claim-1 method, but the priority is expressed only as the offload indications "indicating, when applicable …, a higher priority than the filtering actions" — the claim does not require the ordering to be physically resident in the lookup circuitry. This breadth invites derivatives in which priority is computed rather than stored.

---

DP-18.1 — Priority computed by an algorithmic classifier: mask-class hash buckets with a min-rank reduction tree

Axis 1 — Material & Component Substitution

Enabling disclosure. Eliminate the ternary memory entirely. Decompose the rule set into mask-length classes; within each class build a chained hash table keyed by the masked key. Assign every class a rank (offload classes 0, listening-server classes 1, filter classes ≥2) — the rank, not a memory address, carries priority. On lookup, all classes are probed in parallel (typically ≤8), each returning hit/miss plus its class rank; a reduction tree selects the minimum rank among hits, exactly reproducing "offload outranks filter" and "first matching entry wins." Latency is deterministic (tree depth × probe latency) independent of hit distribution — a property that matters for scheduled industrial traffic. Because rank is decoupled from position, an insert costs O(1) into the right bucket rather than a table rewrite, enabling sustained 100k updates/s. Bucket overflow is absorbed by a cuckoo-migrating secondary table; load factor is managed to ~70%.

Swept claim element. "the indications of protocol processing for connections that have been offloaded indicating … a higher priority" without the ordering being a physical property of the lookup memory.

flowchart TD
  K["8 tuple key and mask"] --> C32["Mask class 32 prefix"]
  K --> C24["Mask class 24 prefix"]
  K --> C16["Mask class 16 prefix"]
  K --> CW["Wildcard or don't care class"]
  C32 --> H0["Hash bucket rank 0 offload"]
  C24 --> H1["Hash bucket rank 1 server"]
  C16 --> H2["Hash bucket rank 2 filter"]
  CW --> H3["Hash bucket rank 3 filter wildcard"]
  H0 --> RT["Min rank reduction tree"]
  H1 --> RT
  H2 --> RT
  H3 --> RT
  RT --> DEC{"Any hit"}
  DEC -->|yes| T["tid of minimum rank class"]
  DEC -->|no| DFL["Rank MAX default action"]

---

DP-18.2 — Multi-pass priority evaluation on a programmable core with no hardware ordering

Axis 2 — Operational Parameter Expansion

Enabling disclosure. Bind the decision to a programmable packet-processing core (a multi-threaded RISC cluster or a P4-programmable pipeline) that walks a rule structure in multiple passes: pass 1 evaluates the offload-context tables, pass 2 evaluates high-priority filter tables, pass 3 evaluates general filters, and a programmable "stop" predicate halts the walk at the first pass that produces a decision. Priority is therefore a program property (pass order) rather than a memory-ordering property, and can be changed by recompiling the program at runtime with a hot-swap of the program image (double-buffered, committed atomically). This variant trades determinism for flexibility: worst-case latency grows with pass count, so the compiler assigns a bounded pass budget and any rule assigned a pass beyond the budget is rejected at compile time — preserving a hard latency guarantee. Stateful actions (connection tracking) are implemented in a bounded-size context memory with explicit eviction.

Swept claim element. "indicating … a higher priority than the filtering actions" where the indication is produced by a program's control flow rather than by a storage ordering.

flowchart TD
  P["Packet ingress"] --> P1["Pass 1 offload context tables"]
  P1 --> D1{"Decision reached"}
  D1 -->|yes| OUT["Apply action"]
  D1 -->|no| P2["Pass 2 high priority filters"]
  P2 --> D2{"Decision reached"}
  D2 -->|yes| OUT
  D2 -->|no| P3["Pass 3 general filters"]
  P3 --> D3{"Decision reached"}
  D3 -->|yes| OUT
  D3 -->|no| DEF["Default action pass"]
  DEF --> OUT
  HOST["Host compiler with pass budget"] --> IMG["Program image double buffered"]
  IMG --> P1
  IMG --> P2
  IMG --> P3

---

DP-18.3 — Cross-domain: consumer CPE / AgTech gateway with composite priority scoring

Axis 3 — Cross-Domain Application

Enabling disclosure. In a low-cost consumer gateway or an agricultural field gateway, priority need not be a fixed region order but a composite score computed in a small ALU: priority = w1·class_weight + w2·severity − w3·recency_penalty + w4·tenant_weight, compared with a threshold and combined with a strict fallback order. In the AgTech instance, ingress frames carrying ISOBUS/J1939 task-controller traffic (field implement commands), GNSS RTK correction streams (NTRIP), and LoRaWAN backhaul are scored by a policy that elevates RTK corrections during a spray pass and elevates implement safety stop messages unconditionally; the highest score wins rather than the lowest index. In the consumer CPE instance, the score elevates latency-critical gaming/voice flows and parentally-restricted categories. The score is computed after a coarse region match so the ordering invariant is still guaranteed for safety classes; only the middle band is score-ordered.

Swept claim element. "highest priority one of a plurality of actions" determined by a computed score for middle-band rules while safety/offload classes retain a fixed precedence.

flowchart LR
  F["Field gateway ingress"] --> CL["Coarse class match"]
  subgraph FIX["Fixed precedence band"]
    S0["Safety stop ISOBUS J1939"]
    S1["GNSS RTK correction NTRIP"]
  end
  CL --> S0
  S0 --> S1
  S1 --> SC["Score ALU on middle band"]
  SC --> W1["Class weight"]
  SC --> W2["Severity weight"]
  SC --> W3["Recency penalty"]
  SC --> W4["Tenant weight"]
  W1 --> SUM["Weighted sum and threshold"]
  W2 --> SUM
  W3 --> SUM
  W4 --> SUM
  SUM --> WIN["Winning middle band rule"]
  WIN --> ACT["Apply action and export score telemetry"]

---

DP-18.4 — Integration: policy-as-code compilation with runtime intent verification

Axis 4 — Integration with Emerging Tech

Enabling disclosure. Accept policy written in a high-level language (Rego/OPA, Cedar, or a declarative YAML dialect) and lower it to either a stored ordering (for a hardware search plane) or a pass-program (for DP-18.2's core). The compiler emits, alongside the executable image, a machine-checkable intent certificate: a set of logical constraints (no unintended shadowing, every declared deny reachable, no rule can be widened by a permutation, offload preemption preserved) whose satisfaction is decided by an SMT solver and whose witness is attached to the image. At runtime, periodic sampled differential execution replays a captured packet trace through both the compiled image and a software reference interpreter; any divergence raises an alarm and can trigger automatic rollback to the previous attested image. The whole loop is closed by an AI agent that proposes intent refinements from observed flows, but proposed changes must pass the certificate check before they are eligible for commit.

Swept claim element. "the indications of protocol processing for connections that have been offloaded indicating … a higher priority" where that indication is verified formally, not merely configured.

flowchart TD
  POL["Rego Cedar or YAML intent"] --> CMP["Policy compiler"]
  CMP --> CERT["SMT intent certificate"]
  CERT --> CHK{"Certificate valid"}
  CHK -->|no| BACK["Reject and return counterexample"]
  CHK -->|yes| IMG["Executable image with witness"]
  IMG --> HW["Hardware ordered lookup"]
  IMG --> REF["Software reference interpreter"]
  TRACE["Sampled packet trace"] --> HW
  TRACE --> REF
  HW --> DIFF{"Divergence detected"}
  REF --> DIFF
  DIFF -->|yes| RB["Rollback to previous attested image"]
  DIFF -->|no| OK["Continue and log agreement rate"]
  AI["AI proposes intent refinement"] --> CMP

---

DP-18.5 — Inverse / failure mode: inverted priority for quarantine, and priority decay for stale rules

Axis 5 — The "Inverse" or Failure Mode

Enabling disclosure. Two deliberate inversions of the normal ordering. (a) Quarantine inversion: on an incident declaration, a control bit flips the arbitration so that filtering outranks offloaded protocol processing. Every flow matching an active quarantine rule is intercepted before its offloaded context is consulted, which lets an operator cut off a specific connection even while the NIC is actively protocol-processing it — the inverse of the steady-state rule. Because the NIC's offload engine is bypassed, the intercepted traffic is redirected to a forensic sink with full capture, and the offloaded context is parked (sequence state frozen) so it can be resumed without a full connection teardown. (b) Priority decay: each rule carries a TTL and a last-hit timestamp; rules whose TTL expires are automatically demoted one rank band per interval until they reach a lowest band, where an explicit "promote" is required to restore them. This prevents a stale high-priority allow rule from being indefinitely exploitable after its business justification expires.

Swept claim element. Priority indications that are dynamically re-ordered, including configurations in which the filtering action outranks the offloaded protocol processing.

stateDiagram-v2
  [*] --> SteadyOrder
  SteadyOrder --> QuarantineInverted : incident declaration control bit set
  QuarantineInverted --> Forensics : intercepted flows redirected with full capture
  QuarantineInverted --> Parked : offload context sequence state frozen
  Forensics --> SteadyOrder : incident cleared
  Parked --> SteadyOrder : connection resumed without teardown
  SteadyOrder --> DecayBand1 : rule TTL expires
  DecayBand1 --> DecayBand2 : further expiry interval
  DecayBand2 --> LowestBand : demotion continues
  LowestBand --> SteadyOrder : explicit promote by operator

---

PART V — COMBINATION PRIOR ART SCENARIOS WITH OPEN-SOURCE / OPEN-STANDARD ART

Each scenario describes a concrete, reproducible combination of the target patent's ordered-lookup mechanism with an existing open-source or open-standard framework. Each is independently enabling and each is intended to occupy the combination space.

---

CP-1 — Ordered lookup as a hardware offload target for Linux eBPF/XDP and tc flower

Open-source constituents: Linux bpf() with XDP programs, the bpf_offload/devmap infrastructure, tc with the flower classifier (skip_hw/in_hw flags, prio fields), and OVS-DPDK's rte_flow.

Enabling disclosure. A NIC search plane presents itself as an offload target for XDP and flower rules. The flower classifier's prio field is mapped to the lookup plane's region band (prio 1 → offload-context band, prio 100 → filter band, etc.), and rte_flow rule handles are assigned monotonically from the region base so that rte_flow precedence equals physical precedence. XDP programs that return XDP_PASS/XDP_DROP/XDP_TX compile to triples of {key, mask, action} rows; the bpf_offload layer pushes them into the plane and marks the corresponding software map entry in_hw so the kernel skips re-evaluating it in the driver path. Rule installs are batched into a single bpf_map_update_elem-style transaction and applied on a barrier so the hardware image transitions atomically, mirroring the "no packet sees a partial image" property. A DEVMAP_HASH entry redirecting to a VF is realized as a quarantine/steering action (DP-12.2 species 3).

Combination claim space occupied: any system in which an eBPF/XDP or tc flower rule with an explicit prio, offloaded to a NIC, participates in a single ordered hardware decision together with offload-context entries for connections handled by the NIC.

flowchart TD
  subgraph SW["Host software plane"]
    EBPF["eBPF XDP program"]
    MAP["bpf map with in_hw marked entries"]
    TC["tc flower rules with prio"]
  end
  EBPF --> MK["Compile to key mask action rows"]
  MAP --> MK
  TC --> MK
  MK --> BT["Batched transaction with barrier"]
  BT --> HW
  subgraph HW["NIC search plane"]
    RO["Offload context band prio 1"]
    RF["Filter band prio 100"]
    RD["Default band"]
  end
  HW --> DEC["Highest priority action wins"]
  DEC --> PASS["XDP_PASS equivalent delivery to host"]
  DEC --> DROP["XDP_DROP equivalent block"]
  DEC --> TX["XDP_TX equivalent redirect to port or VF"]
  DEC --> QV["Quarantine redirect to analysis VF"]

---

CP-2 — P4 / P4Runtime / PSA pipeline implementing region-ordered matching

Open-standard constituents: P4-16 language, the Portable Switch Architecture (PSA), P4Runtime WriteRequest batching.

Enabling disclosure. Express the ordered lookup as a P4-16 psa ingress pipeline. Tables ctx_tbl (offload contexts), srv_tbl (listening contexts), and flt_tbl (filters) are evaluated in a fixed apply order, and the priority semantics are imposed by a priority match-key field plus a switch on the winning table identity implemented in control flow, so the ordering is explicit and inspectable in the compiled artifact. Match kinds use ternary (masked) and lpm to reproduce "don't care" behavior. Rule installation uses P4Runtime WriteRequest with atomic semantics across all three tables, so a controller cannot install a filter rule that transiently outranks an existing context. psa.pktin metadata carries a region identifier and a rank so that the downstream action block can attach telemetry. The pipeline exposes a deterministic maximum table-application latency, published as a P4 "worst-case pipeline latency" annotation for TSN deployments.

Combination claim space occupied: any P4/PSA implementation in which a fixed pipeline order over a table of offloaded-connection contexts and a table of filter rules produces a single highest-priority action, with atomic multi-table installation.

flowchart LR
  PARSER["P4 parser extracts L2 L3 L4 and shallow L7"] --> CTX
  subgraph PIPE["PSA ingress control"]
    CTX["ctx_tbl ternary offload contexts"]
    SRV["srv_tbl listening contexts"]
    FLT["flt_tbl ternary and lpm filters"]
    SEL["Priority select by table order and priority field"]
  end
  CTX --> SEL
  SRV --> SEL
  FLT --> SEL
  SEL --> ACT["Action block drop forward rewrite"]
  CTRL["P4Runtime controller"] --> ATOMIC["Atomic WriteRequest across tables"]
  ATOMIC --> CTX
  ATOMIC --> SRV
  ATOMIC --> FLT
  ACT --> DEP["Deparser"]
  ACT --> META["psa pktin metadata telemetry"]

---

CP-3 — Standards-based equivalent: IEEE 802.1Qci per-stream filtering and policing with 802.1CB and 802.1AE

Open-standard constituents: IEEE 802.1Qci (Per-Stream Filtering and Policing: stream filters, stream gates, flow meters, stream identity tables), IEEE 802.1CB (Frame Replication and Elimination for Reliability), IEEE 802.1AE (MACsec).

Enabling disclosure. In a standards-compliant bridge, the Stream Identity Table and Stream Filter instances are already prioritized structures: each stream filter holds a StreamHandle and a Priority parameter, and 802.1Qci specifies that where multiple stream filters could match a frame, the one with the highest priority applies, and StreamBlockedDueToOversizeFrame / gate-state outcomes determine forwarding versus discard. This is the standards-track analogue of "an order of the indications of the plurality of actions relative to each other." Combining it with the target patent's contribution yields: region 0 = 802.1CB sequence-recovery contexts (the "protocol processing" being replication/elimination per stream), region 1 = 802.1Qci stream filters with priority, region 2 = default bridge forwarding; MACsec (802.1AE) integrity-check results are folded into the key so that a frame failing integrity verification is filtered at the highest priority regardless of any other match. The atomic-update property is realized by the IEEE 802.1Qcp/YANG ieee802-dot1q-psfp data model committed in a single NETCONF transaction.

Combination claim space occupied: any implementation in which a standards-conformant priority-ordered stream-filter structure, a per-stream context structure, and a default action are resolved into one highest-priority action within a network interface, particularly where replication/elimination contexts preempt filtering.

flowchart TD
  FR["Frame from LAN port"] --> SEC["802.1AE integrity check result"]
  SEC --> KEY["Stream identification key plus integrity verdict"]
  KEY --> R0["Region 0 802.1CB sequence recovery contexts"]
  R0 --> R1["Region 1 802.1Qci stream filters with priority and gates"]
  R1 --> R2["Region 2 default bridge forwarding"]
  R0 --> CB["Replication elimination and hitless merge"]
  R1 --> QCI{"Gate state and flow meter"}
  QCI -->|pass| FWD["Forward"]
  QCI -->|oversize blocked| DROP1["StreamBlockedDueToOversizeFrame counter"]
  QCI -->|closed| DROP2["Gate closed discard"]
  SEC -->|integrity fail| DROP3["Highest priority discard"]
  NETCONF["NETCONF ieee802-dot1q-psfp transaction"] --> R1

---

CP-4 — netfilter/nftables + conntrack + DPDK rte_flow/rte_security inline IPsec

Open-source constituents: nftables sets and verdict maps, netfilter conntrack, DPDK rte_flow (priorities and groups), rte_security inline IPsec.

Enabling disclosure. Two cooperating planes. In the hardware plane, rte_flow items are installed with explicit priority and group values; the NIC's search plane maps group to region and priority to row rank, so rte_flow group 0 (offload/termination contexts established by rte_security SA handles) outranks group 1 (ACL filters) outranks a group 9 default. In the software plane, nftables verdict maps mirror the hardware image and are marked offload so the kernel's ip/inet filter chains only see packets the hardware elected to pass — a two-tier "hardware first, software fallback" architecture that reproduces the "filter then provide to host" semantics with an auditable software shadow. conntrack entries for offloaded SA/flow pairs are exported to the NIC as context rows with a state field, so hardware-accelerated flows still feed the host's stateful firewall view for logging and for the "established/related" verdict.

Combination claim space occupied: a split architecture in which DPDK rte_flow group/priority ordering plus rte_security contexts, mirrored by an nftables verdict map, jointly decide which frames reach the host.

sequenceDiagram
  participant A as Admin policy
  participant N as nftables verdict map
  participant D as DPDK rte_flow
  participant H as NIC search plane
  participant K as Kernel conntrack
  A->>N: load ruleset with offload marks
  A->>D: install rte_flow rules with group and priority
  D->>H: write rows group maps to region priority maps to rank
  N->>H: mirror image for audit parity
  H->>H: classify ingress frame
  alt group 0 security association context matches
    H->>H: inline IPsec decrypt and protocol processing
    H->>K: export conntrack entry for logging
    H->>A: deliver decrypted frame up the stack
  else group 1 ACL matches
    H->>A: deliver or drop per action
  else no match
    H->>A: default action pass to host stack
  end

---

CP-5 — Kubernetes CNI with SmartNIC/vDPA, NetworkPolicy compilation, and SPDM attestation

Open-source constituents: Cilium/Kube-OVN CNI, Kubernetes NetworkPolicy, SR-IOV/vDPA representors, CNI chaining, DMTF SPDM.

Enabling disclosure. A cluster controller compiles each NetworkPolicy object into an ordered row image scoped to a namespace (tenant), assigned a per-VF ordered context in the NIC as in DP-12.3. The CNI plugin installs the image through a device plugin/vDPA representor, and the policy's ingress/egress ordering (deny-overrides versus allow-overrides as configured) maps to region bands: policy-explicit denies to a high band, allow rules to a middle band, and the namespace default (allow or deny) to the lowest band. Pod identity (SPIFFE ID or security group tag) is folded into the key so policy applies to the workload identity rather than the pod IP, eliminating recompile churn on rescheduling. Attestation uses SPDM to prove the NIC's active image digest matches the digest the cluster controller published, so a node that silently failed to apply a NetworkPolicy can be evicted from the service mesh.

Combination claim space occupied: a container-orchestrated configuration in which namespace-scoped ordered rule contexts on a NIC, driven by a CNI plugin and verified by SPDM attestation, determine whether a pod's ingress frames are blocked before host delivery.

flowchart TD
  NP["Kubernetes NetworkPolicy objects"] --> CC["Cluster policy controller"]
  CC --> CMP["Compile per namespace ordered image"]
  CMP --> ID["Fold SPIFFE ID or security group tag into key"]
  ID --> DP["Device plugin and vDPA representor install"]
  DP --> CTX["Per VF ordered context on NIC"]
  CTX --> ENF["Ingress enforced before host delivery"]
  ENF --> POD["Pod veth receives admitted frames only"]
  ENF --> TEL["Per rule counters to cluster telemetry"]
  ADM["Admission or eviction controller"] --> SPDM["SPDM attestation of active image digest"]
  SPDM --> ENF
  SPDM -->|digest mismatch| EVICT["Cordon and evict node from mesh"]

---

PART VI — COVERAGE AND PUBLICATION CONTROL

A. Axis coverage matrix

B. Dependent-claim element sweep

The derivative set above also discloses the subject matter of the dependent claims, as follows (targeting future species/improvement filings rather than the issued claims):

C. Publication protocol (required for defensive effect)

1. Freeze the corpus. Serialize Parts I–V verbatim; compute a SHA-256 over the canonical serialization.
2. Timestamp it. Publish through a channel with an independently verifiable public date: a DOI-issuing repository (e.g. Zenodo), a defensive-publication service, or an arXiv posting, each of which fixes a public accessibility date. Keep the deposit receipt and the digest.
3. Optionally anchor the digest in a public transparency log or a public blockchain transaction so that the date cannot be disputed later.
4. Preserve the record. A defensive publication is only effective if it is publicly accessible and enabling; retain the rendering receipts for the Mermaid diagrams, since diagrams are part of the enabling disclosure.
5. Coordinate with counsel. Because SpeedNIC LLC v. NVIDIA Corp. et al (7:26-cv-00148, W.D. Tex., filed 2026-04-16) is pending and concerns at least claim 12, any party intending to use this corpus in a validity or interference context should have counsel confirm that publication does not create an adverse admission of prior use or sale, and should confirm the applicable § 102 date for each specific later filing it is intended to defeat.

D. Limitations of this dossier (stated explicitly rather than inferred)

• It cannot invalidate US 7,760,733. The patent's priority date is 2005-10-13. Nothing published today can be prior art against it. This corpus attacks later filings only.
• Claim 12's "lookup circuitry" scope is currently contested in the W.D. Tex. case, where the defense scope question is whether software "pipe chaining" with priority-by-insertion-order meets the recital. This dossier deliberately discloses both hardware-order and software-order species (CP-1, CP-2, DP-18.2) so that neither implementation route remains freely claimable by a competitor after today.
• The search performed was of publicly indexed USPTO-mirrored data. I did not access a subscription USPTO PatentCenter/PALM docket or the sealed portions of the complaint. Items I could not verify directly — the exact printed § 154(b) adjustment day count on the patent's face, the reel/frame of the 2026-02-13 Chelsio → SPEEDNIC LLC assignment, and the full list of patents asserted in 7:26-cv-00148 — are flagged here as open items, consistent with the earlier Extensions section, rather than asserted.