US 8621627

As a senior US patent analyst, I have conducted a thorough review of US Patent 8,621,627 as of May 1, 2026. Below is a concise summary of the patent and its legal status.

Summary of US Patent 8,621,627

Title: Intrusion detection and prevention processing within network interface circuitry

Assignee: The original assignee is Chelsio Communications Inc. The patent has been assigned multiple times, including to various banks as security interests, but the most recent assignments on record with the USPTO show these security interests have been released. As of the latest available information, Chelsio Communications Inc. appears to be the current assignee.

Inventors:

• Asgeir Thor Eiriksson
• Wael Noureddine
• Anamaya Sullerey

Filing Date: February 12, 2010

Issue Date: December 31, 2013

Abstract:
The patent describes a network interface controller (NIC) designed to work with a host computer that runs multiple virtual machines. The NIC is capable of receiving a data frame, determining if that frame requires additional processing (such as for security purposes), and if so, sending it to the host for that processing. After the host completes the additional processing, the NIC receives the frame back and directs it to its intended destination. This allows for efficient handling of tasks like intrusion detection in a virtualized environment by offloading some of the decision-making to the NIC.

Plain-Language Overview of Independent Claims

US Patent 8,621,627 has three independent claims: Claim 1, Claim 7, and Claim 24. Here is a plain-language overview of each:

Claim 1: This claim describes a Network Interface Controller (NIC) that connects a host computer with multiple virtual machines to a network. The core of this claim is a three-step process:

1. The NIC receives a data frame and decides if it needs special processing.
2. If special processing is needed, the NIC sends the frame to the host computer to perform that task.
3. After the host is finished, the NIC takes the processed frame back and sends it to its final destination.

Claim 7: This claim is also for a NIC with a "data frame processing pipeline." The key aspect here is that the NIC makes the decision to send a frame for additional processing based on a specific "indication" within the data frame itself. After the host performs the additional processing, the NIC then sends the frame on to its destination.

Claim 24: This claim outlines a broader method performed by a NIC. It involves:

1. Receiving a data frame.
2. Determining if additional processing is required.
3. If so, sending the frame for this additional processing before it goes to its final destination.
4. Finally, receiving the processed frame back and steering it to its destination.

Litigation Status

A search of the U.S. Court of Appeals for the Federal Circuit (CAFC) dockets for the year 2026 revealed no cases specifically citing US Patent 8,621,627. I have a high degree of confidence that there is no ongoing litigation involving this patent at the CAFC in 2026.

Litigation Search for US Patent 8,621,627

As of May 1, 2026, a comprehensive search of patent litigation databases reveals one known case involving US Patent 8,621,627.

• Case: Speednic LLC v. Nvidia Corp et al.
  • Plaintiff(s): Speednic LLC
  • Defendant(s): Nvidia Corp, Dell Technologies Inc
  • Jurisdiction: Texas Western District Court
  • Case Number: 7:26-cv-00148
  • Filing Date: April 16, 2026
  • Status: Open
  • Other Patents-in-Suit: 7,760,733; 7,826,350; 8,060,644; 8,589,587

This appears to be a recent filing, and no outcome has been determined. Searches of PACER, Unified Patents, and other dockets revealed no other historical or ongoing litigation specifically naming US patent 8,621,627.

Proceedings overview

There are no AIA trial proceedings on file for US Patent 8,621,627. This means that all claims of the patent remain untested in an AIA trial setting.

Strategic summary

As there are no PTAB proceedings on file for US Patent 8,621,627, all claims (1-29) remain unchallenged and are considered sustained from a PTAB perspective. This also means there is no estoppel landscape established by AIA trials, leaving all prior-art grounds available for potential future challenges. The absence of PTAB activity could indicate that the patent has not been extensively asserted, or that previous assertions have not led to defensive PTAB filings.

Recommended next steps

If facing an assertion of US Patent 8,621,627, a defendant would have the full range of prior art and statutory grounds available for a potential PTAB challenge (e.g., IPR, PGR, CBM), as no claims have been canceled or sustained through such proceedings. There are no active proceedings or upcoming milestones to monitor. The absence of PTAB challenges also suggests that if considering an IPR, a thorough prior art search would be crucial to identify strong invalidity grounds, as the patent has not been subjected to this scrutiny before.

Inventors

• Asgeir Thor Eiriksson (Chelsio Communications Inc.)
• Wael Noureddine (Chelsio Communications Inc.)
• Anamaya Sullerey (Chelsio Communications Inc.)

Original assignee

Chelsio Communications Inc. is an operating company that primarily designs and manufactures high-performance network adapters and other hardware for data centers. They ship products embodying the claims of US 8621627, as their NICs are designed to offload network processing and security functions. Chelsio Communications Inc. is currently operating.

Assignment timeline

• 2010-02-09 (executed) / recorded 2010-02-19 — Reel 023965/0447
  • Conveyance: Assignment
  • Assignor: EIRIKSSON, ASGEIR THOR; NOUREDDINE, WAEL; SULLEREY, ANAMAYA
  • Assignee: CHELSIO COMMUNICATIONS, INC., CALIFORNIA
  • Correspondent: Bjoern Nicolai, NIXON PEABODY LLP, 200 S. WACKER DRIVE, 36TH FLOOR, CHICAGO, ILLINOIS 60606. This correspondent does not recur in this chain.
  • Context: Original assignment from inventors to the filing company.
• 2013-05-09 (executed) / recorded 2014-03-19 — Reel 032479/0089
  • Conveyance: Security Interest
  • Assignor: CHELSIO COMMUNICATIONS, INC.
  • Assignee: EAST WEST BANK, MASSACHUSETTS
  • Correspondent: David J. Pierre, Rutan & Tucker LLP, 600 Anton Boulevard, 14th Floor, Costa Mesa, CA 92626. This correspondent does not recur in this chain.
  • Context: Securitization of assets by Chelsio Communications Inc.
• 2014-10-07 (executed) / recorded 2014-10-21 — Reel 033989/0930
  • Conveyance: Release by Secured Party
  • Assignor: EAST WEST BANK
  • Assignee: CHELSIO COMMUNICATIONS, INC., CALIFORNIA
  • Correspondent: David J. Pierre, Rutan & Tucker LLP, 600 Anton Boulevard, 14th Floor, Costa Mesa, CA 92626. This correspondent recurs on the previous entry.
  • Context: Release of security interest by East West Bank back to Chelsio Communications Inc.
• 2014-10-14 (executed) / recorded 2014-10-21 — Reel 033990/0451
  • Conveyance: Security Interest
  • Assignor: CHELSIO COMMUNICATIONS, INC.
  • Assignee: SILICON VALLEY BANK, CALIFORNIA
  • Correspondent: David J. Pierre, Rutan & Tucker LLP, 600 Anton Boulevard, 14th Floor, Costa Mesa, CA 92626. This correspondent recurs on the previous two entries.
  • Context: Securitization of assets by Chelsio Communications Inc.
• 2014-10-07 (executed) / recorded 2016-07-15 — Reel 039360/0596
  • Conveyance: Release by Secured Party
  • Assignor: EAST WEST BANK
  • Assignee: CHELSIO COMMUNICATIONS, INC., CALIFORNIA
  • Correspondent: David J. Pierre, Rutan & Tucker LLP, 600 Anton Boulevard, 14th Floor, Costa Mesa, CA 92626. This correspondent recurs on the previous three entries.
  • Context: Release of security interest by East West Bank back to Chelsio Communications Inc. (duplicate filing date, likely a corrective or delayed recording).
• 2016-07-29 (executed) / recorded 2016-07-29 — Reel 039296/0550
  • Conveyance: Security Interest
  • Assignor: CHELSIO COMMUNICATIONS, INC.
  • Assignee: NOVIRIAN CAPITAL, CALIFORNIA
  • Correspondent: David J. Pierre, Rutan & Tucker LLP, 600 Anton Boulevard, 14th Floor, Costa Mesa, CA 92626. This correspondent recurs on the previous four entries.
  • Context: Securitization of assets by Chelsio Communications Inc.
• 2017-04-11 (executed) / recorded 2017-04-25 — Reel 042142/0232
  • Conveyance: Release by Secured Party
  • Assignor: NOVIRIAN CAPITAL
  • Assignee: CHELSIO COMMUNICATIONS, INC., CALIFORNIA
  • Correspondent: David J. Pierre, Rutan & Tucker LLP, 600 Anton Boulevard, 14th Floor, Costa Mesa, CA 92626. This correspondent recurs on the previous five entries.
  • Context: Release of security interest by Novirian Capital back to Chelsio Communications Inc.
• 2019-08-09 (executed) / recorded 2019-08-14 — Reel 050050/0396
  • Conveyance: Security Interest
  • Assignor: CHELSIO COMMUNICATIONS, INC.
  • Assignee: WESTERN ALLIANCE BANK, AN ARIZONA CORPORATION, CAL
  • Correspondent: David J. Pierre, Rutan & Tucker LLP, 600 Anton Boulevard, 14th Floor, Costa Mesa, CA 92626. This correspondent recurs on the previous six entries.
  • Context: Securitization of assets by Chelsio Communications Inc.
• 2019-08-09 (executed) / recorded 2019-08-15 — Reel 050112/0234
  • Conveyance: Corrective Assignment
  • Assignor: CHELSIO COMMUNICATIONS, INC.
  • Assignee: WESTERN ALLIANCE BANK, AN ARIZONA CORPORATION, CAL
  • Correspondent: David J. Pierre, Rutan & Tucker LLP, 600 Anton Boulevard, 14th Floor, Costa Mesa, CA 92626. This correspondent recurs on the previous seven entries.
  • Context: Corrective assignment related to the security interest.
• 2024-01-22 (executed) / recorded 2025-12-18 — Reel 073264/0525
  • Conveyance: Release of Security Interest
  • Assignor: WESTERN ALLIANCE BANK, AN ARIZONA CORPORATION
  • Assignee: CHELSIO COMMUNICATIONS, INC., CALIFORNIA
  • Correspondent: David J. Pierre, Rutan & Tucker LLP, 600 Anton Boulevard, 14th Floor, Costa Mesa, CA 92626. This correspondent recurs on the previous eight entries.
  • Context: Release of security interest by Western Alliance Bank back to Chelsio Communications Inc.

Timeline diagram

timeline
    title Ownership of US 8621627
    2010 : Filed by Chelsio Communications Inc
    2013 : Issued to Chelsio Communications Inc
    2014 : Security Interest to East West Bank
         : Release by East West Bank
         : Security Interest to Silicon Valley Bank
    2016 : Release by East West Bank
         : Security Interest to Novirian Capital
    2017 : Release by Novirian Capital
    2019 : Security Interest to Western Alliance Bank
         : Corrective Assignment
    2025 : Release by Western Alliance Bank

NPE / troll-pattern signals

1. Shell-entity transfer — not present. The patent has consistently been assigned to and from Chelsio Communications Inc. and various banks for security interests. Chelsio is an operating company.
2. Known asserter in the chain — not present. Neither Chelsio Communications Inc. nor any of the banks appear on public NPE lists.
3. Repeat correspondent across the chain — present. David J. Pierre of Rutan & Tucker LLP is the correspondent on multiple security interest and release filings from 2014 to 2025 (Reel 032479/0089, Reel 033989/0930, Reel 033990/0451, Reel 039360/0596, Reel 039296/0550, Reel 042142/0232, Reel 050050/0396, Reel 050112/0234, Reel 073264/0525). This recurrence is a strong indicator of a consistent legal representative for Chelsio's patent-related financial transactions.
4. Cascading transfers — not present. The transfers primarily involve Chelsio Communications Inc. and various banks in a securitization context, not rapid transfers between shell entities.
5. Pre-litigation transfer — unclear. The latest assignment (a release back to Chelsio) was recorded on 2025-12-18 (executed 2024-01-22), while Speednic LLC v. Nvidia Corp et al. was filed on April 16, 2026. This is a period of roughly 4 months between the last recorded transfer and the litigation filing. However, the last actual transfer of ownership was the release back to Chelsio, which means Chelsio owned the patent leading up to the Speednic litigation. If Speednic LLC is an NPE, then the patent could have been transferred to Speednic shortly before the litigation, but this transfer is not yet publicly recorded.
6. Bankruptcy fire-sale — not present. There is no indication in the assignment records or general knowledge that Chelsio Communications Inc. has undergone bankruptcy proceedings that resulted in a patent sale.
7. Privateering — not present. There is no evidence to suggest Chelsio Communications Inc. transferred this patent to an NPE to assert on their behalf.
8. Defensive aggregator (anti-NPE) — not present. The chain does not terminate at a known defensive aggregator.

Verdict

Insufficient data to definitively declare NPE status. While there is current litigation in Speednic LLC v. Nvidia Corp et al., the assignment records available via USPTO Assignment Center (as of 2026-05-30) do not show a transfer from Chelsio Communications Inc. to Speednic LLC. All recorded assignments reflect security interests and releases, with Chelsio Communications Inc. consistently remaining the assignee. Without a recorded transfer to Speednic LLC or further evidence regarding Speednic LLC's nature, a high-confidence NPE verdict is not warranted based solely on the assignment chain.

USPTO Assignment Center search page: https://assignmentcenter.uspto.gov/

To identify the most relevant prior art for US patent 8,621,627, I will examine the "Citations" section of the patent itself, as this lists the prior art considered by the patent examiner during prosecution.

Most Relevant Prior Art for US Patent 8,621,627

Below are the patent citations listed for US Patent 8,621,627, along with their publication/filing dates, a brief description, and which claim(s) they potentially anticipate under 35 U.S.C. § 102. The current date is April 26, 2026.

Note: The analysis of which claims are potentially anticipated is based on the descriptions provided in US8621627 and the cited patents' titles/abstracts. A full anticipation analysis would require a detailed claim-by-claim comparison.

Cited US Patents:

1. US6594268B1 (Lucent Technologies Inc.)

   • Full Citation: US6594268B1, "Adaptive routing system and method for QOS packet networks".
   • Publication Date: July 15, 2003.
   • Filing Date: March 11, 1999.
   • Brief Description: This patent generally relates to adaptive routing and quality of service (QoS) in packet networks. While not directly addressing virtual machine intrusion detection, it deals with packet handling and routing based on network conditions and QoS requirements.
   • Potential Anticipation (35 U.S.C. § 102): Claims 1, 7, 24 (potentially, concerning the general concept of steering frames in a network, but likely not the specific virtual machine/intrusion detection context).

2. US6798743B1 (Cisco Technology, Inc.)

   • Full Citation: US6798743B1, "Packet prioritization processing technique for routing traffic in a packet-switched computer network".
   • Publication Date: September 28, 2004.
   • Filing Date: March 22, 1999.
   • Brief Description: This patent describes techniques for prioritizing packet processing and routing in a packet-switched network. Similar to US6594268B1, it focuses on network traffic management rather than virtualized security.
   • Potential Anticipation (35 U.S.C. § 102): Claims 1, 7, 24 (potentially, regarding general packet processing and routing, but less likely the specific security offload to a VM).

3. US20020039366A1 (Nec Corporation)

   • Full Citation: US20020039366A1, "Packet switch and multicasting control system used for the same".
   • Publication Date: April 4, 2002.
   • Filing Date: October 4, 2000.
   • Brief Description: This patent application details a packet switch and a multicasting control system. It covers aspects of switching and replication of data frames, which is relevant to the MPS functionality in US8621627.
   • Potential Anticipation (35 U.S.C. § 102): Claims 1, 7, 20, 21, 24 (potentially, concerning the replication and steering of frames to multiple destinations, particularly in the context of multicast, but without the specific intrusion detection component).

4. US6792502B1 (Freescale Semiconductor, Inc.)

   • Full Citation: US6792502B1, "Microprocessor having a content addressable memory (CAM) device as a functional unit therein and method of operation".
   • Publication Date: September 14, 2004.
   • Filing Date: October 12, 2000.
   • Brief Description: This patent describes a microprocessor incorporating a CAM for various operations. While CAMs can be used in packet filtering, this patent does not specifically detail their use for intrusion detection offload in a virtualized NIC context.
   • Potential Anticipation (35 U.S.C. § 102): May be relevant to the underlying hardware mechanisms for filter processing (e.g., Claim 5, 22, 28) if such filtering relies on CAMs for rule matching, but unlikely to anticipate the overall system and method.

5. US7031267B2 (802 Systems Llc)

   • Full Citation: US7031267B2, "PLD-based packet filtering methods with PLD configuration data update of filtering rules".
   • Publication Date: April 18, 2006.
   • Filing Date: December 21, 2000.
   • Brief Description: This patent discusses packet filtering methods using Programmable Logic Devices (PLDs) and dynamic updates of filtering rules. This is highly relevant to the "filter functionality" (Claim 5, 22, 28) and configurable rules (Claim 6, 23, 29) described in US8621627.
   • Potential Anticipation (35 U.S.C. § 102): Claims 5, 6, 22, 23, 28, 29 (highly relevant to the concept of NIC-based filtering and dynamically configurable rules, although not explicitly tied to intrusion detection in a virtual machine environment as the primary goal).

6. US20060209693A1 (Pmc-Sierra Ltd.)

   • Full Citation: US20060209693A1, "Feedback priority modulation rate controller".
   • Publication Date: September 21, 2006.
   • Filing Date: January 31, 2001.
   • Brief Description: This patent generally describes a rate controller for modulating feedback priority, likely in a communication system. Its relevance to US8621627's core claims appears limited.
   • Potential Anticipation (35 U.S.C. § 102): Unlikely to directly anticipate any of the independent claims.

7. US20040003094A1 (Michael See)

   • Full Citation: US20040003094A1, "Method and apparatus for mirroring traffic over a network".
   • Publication Date: January 1, 2004.
   • Filing Date: June 27, 2002.
   • Brief Description: This patent application describes mirroring network traffic, which could be used for monitoring or intrusion detection purposes by sending a copy of traffic to a security appliance. This has some conceptual overlap with sending frames for "additional processing" (Claim 1, 7, 24).
   • Potential Anticipation (35 U.S.C. § 102): Claims 1, 7, 24 (to the extent that "additional processing" could involve mirroring, but it lacks the explicit steering and host-based VM processing unique to US8621627).

8. US7474670B2 (Brooktree Broadband Holding, Inc.)

   • Full Citation: US7474670B2, "Method and system for allocating bandwidth".
   • Publication Date: January 6, 2009.
   • Filing Date: July 8, 2002.
   • Brief Description: This patent is about allocating bandwidth. It does not directly relate to intrusion detection or offloading security processing to a NIC in a virtualized environment.
   • Potential Anticipation (35 U.S.C. § 102): Unlikely to directly anticipate any of the independent claims.

9. US6717946B1 (Cisco Technology Inc.)

   • Full Citation: US6717946B1, "Methods and apparatus for mapping ranges of values into unique values of particular use for range matching operations using an associative memory".
   • Publication Date: April 6, 2004.
   • Filing Date: October 31, 2002.
   • Brief Description: This patent focuses on mapping value ranges for efficient matching using associative memory, likely for routing or filtering. Similar to US6792502B1, it describes a mechanism that could be used for filtering but not the specific application described in US8621627.
   • Potential Anticipation (35 U.S.C. § 102): May be relevant to the underlying hardware mechanisms for filter processing (e.g., Claim 5, 22, 28) if such filtering relies on associative memory for rule matching, but unlikely to anticipate the overall system and method.

10. US20040213235A1 (Marshall John W.)

    • Full Citation: US20040213235A1, "Programmable packet classification system using an array of uniform content-addressable memories".
    • Publication Date: October 28, 2004.
    • Filing Date: April 8, 2003.
    • Brief Description: This patent application describes a programmable packet classification system using CAMs. This is highly relevant to the filtering capabilities of a NIC.
    • Potential Anticipation (35 U.S.C. § 102): Claims 5, 6, 22, 23, 28, 29 (relevant to the technical means for implementing filter processing with configurable rules).

11. US20050083935A1 (Kounavis Michael E.)

    • Full Citation: US20050083935A1, "Method and apparatus for two-stage packet classification using most specific filter matching and transport level sharing".
    • Publication Date: April 21, 2005.
    • Filing Date: October 20, 2003.
    • Brief Description: This patent application details a two-stage packet classification method using specific filter matching. This is another example of advanced packet filtering that could be relevant to the NIC's filter functionality.
    • Potential Anticipation (35 U.S.C. § 102): Claims 5, 6, 22, 23, 28, 29 (relevant to advanced filter processing techniques).

12. US20050135412A1 (Fan Kan F.)

    • Full Citation: US20050135412A1, "Method and system for transmission control protocol (TCP) retransmit processing".
    • Publication Date: June 23, 2005.
    • Filing Date: December 19, 2003.
    • Brief Description: This patent application is concerned with TCP retransmit processing. It relates to protocol offload functions (Claim 2, 3, 8, 9, 14, 25, 26) but not directly to intrusion detection or the specific steering mechanism.
    • Potential Anticipation (35 U.S.C. § 102): Claims 2, 3, 8, 9, 14, 25, 26 (relevant to the concept of protocol offload processing on the NIC).

13. US20050135396A1 (Mcdaniel Scott)

    • Full Citation: US20050135396A1, "Method and system for transmit scheduling for multi-layer network interface controller (NIC) operation".
    • Publication Date: June 23, 2005.
    • Filing Date: December 19, 2003.
    • Brief Description: This patent application describes transmit scheduling for multi-layer NIC operations, which is related to NIC functionality and data handling.
    • Potential Anticipation (35 U.S.C. § 102): Could broadly relate to general NIC operation and data handling (Claim 1, 7, 24) but lacks the specific security and VM offloading aspects.

14. US20050135378A1 (Nortel Networks Limited)

    • Full Citation: US20050135378A1, "Service aware policer with efficient handling of in-profile traffic".
    • Publication Date: June 23, 2005.
    • Filing Date: December 22, 2003.
    • Brief Description: This patent application discusses a service-aware policer for traffic management. It's related to network control and filtering.
    • Potential Anticipation (35 U.S.C. § 102): Claims 5, 22, 28 (general filtering and traffic management on a NIC).

15. US20050289246A1 (International Business Machines Corporation)

    • Full Citation: US20050289246A1, "Interpreting I/O operation requests from pageable guests without host intervention".
    • Publication Date: December 29, 2005.
    • Filing Date: May 27, 2004.
    • Brief Description: This patent application relates to handling I/O requests from virtual machine "guests" without host intervention. This touches on virtualized environments and offloading host tasks, which is a foundational concept in US8621627.
    • Potential Anticipation (35 U.S.C. § 102): Claims 1, 7, 24 (relevant to the concept of offloading processing from the host in a virtualized environment).

16. US7583596B1 (Juniper Networks, Inc.)

    • Full Citation: US7583596B1, "Priority scheduling using per-priority memory structures".
    • Publication Date: September 1, 2009.
    • Filing Date: June 28, 2004.
    • Brief Description: This patent focuses on priority scheduling in network devices. Its direct relevance to intrusion detection offload is limited.
    • Potential Anticipation (35 U.S.C. § 102): Unlikely to directly anticipate any of the independent claims.

17. US7408883B2 (Nettest, Inc.)

    • Full Citation: US7408883B2, "Apparatus and method for performing a loopback test in a communication system".
    • Publication Date: August 5, 2008.
    • Filing Date: September 1, 2004.
    • Brief Description: This patent describes a loopback test in a communication system. While US8621627 utilizes a "loopback" to send frames to a VM for intrusion detection, this patent refers to a diagnostic test, not a security processing mechanism.
    • Potential Anticipation (35 U.S.C. § 102): Not directly anticipating the purpose or function of the loopback in US8621627, but conceptually relates to the idea of a frame being sent back within the system.

18. US20060075480A1 (Noehring Lee P)

    • Full Citation: US20060075480A1, "System and method for controlling a flow of data a network interface controller to a host processor".
    • Publication Date: April 6, 2006.
    • Filing Date: October 1, 2004.
    • Brief Description: This patent application describes controlling data flow between a NIC and a host processor, which is fundamental to US8621627's interaction between the NIC and the host for additional processing.
    • Potential Anticipation (35 U.S.C. § 102): Claims 1, 7, 24 (highly relevant to the interaction and data transfer between the NIC and the host for processing).

19. US20060080733A1 (International Business Machines Corporation)

    • Full Citation: US20060080733A1, "Offline analysis of packets".
    • Publication Date: April 13, 2006.
    • Filing Date: October 8, 2004.
    • Brief Description: This patent application relates to offline analysis of packets, which could involve intrusion detection, but doesn't explicitly describe offloading the decision and steering to a NIC in a virtualized environment.
    • Potential Anticipation (35 U.S.C. § 102): Could broadly relate to the concept of analyzing packets for security, but lacks the specific NIC-based steering and host-based VM processing.

20. US20060133267A1 (Utstarcom, Inc.)

    • Full Citation: US20060133267A1, "Processing platform selection method for data packet filter installation".
    • Publication Date: June 22, 2006.
    • Filing Date: December 21, 2004.
    • Brief Description: This patent application describes selecting processing platforms for packet filter installation. This is relevant to the configurability and deployment of filtering rules.
    • Potential Anticipation (35 U.S.C. § 102): Claims 5, 6, 22, 23, 28, 29 (relevant to the configuration of filter processing).

21. US20060206300A1 (Microsoft Corporation)

    • Full Citation: US20060206300A1, "VM network traffic monitoring and filtering on the host".
    • Publication Date: September 14, 2006.
    • Filing Date: March 11, 2005.
    • Brief Description: This patent application specifically addresses monitoring and filtering VM network traffic on the host. This is highly relevant as it describes a problem that US8621627 aims to solve by offloading some of this to the NIC. It anticipates the need for such processing for VMs.
    • Potential Anticipation (35 U.S.C. § 102): Claims 1, 7, 24 (highly relevant to the context of VM network security, but likely describes host-based solutions that US8621627 seeks to improve upon by offloading to the NIC).

22. US20060221832A1 (Sun Microsystems, Inc.)

    • Full Citation: US20060221832A1, "Virtualized partitionable shared network interface".
    • Publication Date: October 5, 2006.
    • Filing Date: April 4, 2005.
    • Brief Description: This patent application discusses a virtualized and partitionable shared network interface. This relates to NICs in virtualized environments, a core context for US8621627.
    • Potential Anticipation (35 U.S.C. § 102): Claims 1, 7, 24 (relevant to the general architecture of a NIC supporting virtual machines).

23. US20060281451A1 (Zur Uri E)

    • Full Citation: US20060281451A1, "Method and system for handling connection setup in a network".
    • Publication Date: December 14, 2006.
    • Filing Date: June 14, 2005.
    • Brief Description: This patent application describes handling connection setup. Its direct relevance to intrusion detection offload is limited.
    • Potential Anticipation (35 U.S.C. § 102): Unlikely to directly anticipate any of the independent claims.

24. US20070070901A1 (Eliezer Aloni)

    • Full Citation: US20070070901A1, "Method and system for quality of service and congestion management for converged network interface devices".
    • Publication Date: March 29, 2007.
    • Filing Date: September 29, 2005.
    • Brief Description: This patent application deals with QoS and congestion management in converged NICs. While related to NIC functionality, it doesn't address the specific security offload described in US8621627.
    • Potential Anticipation (35 U.S.C. § 102): Unlikely to directly anticipate any of the independent claims.

25. US7899864B2 (Microsoft Corporation)

    • Full Citation: US7899864B2, "Multi-user terminal services accelerator".
    • Publication Date: March 1, 2011.
    • Filing Date: November 1, 2005.
    • Brief Description: This patent relates to accelerating multi-user terminal services. While it deals with efficiency in a multi-user context, its relevance to NIC-based intrusion detection for VMs is not direct.
    • Potential Anticipation (35 U.S.C. § 102): Unlikely to directly anticipate any of the independent claims.

26. US7660306B1 (Chelsio Communications, Inc.)

    • Full Citation: US7660306B1, "Virtualizing the operation of intelligent network interface circuitry".
    • Publication Date: February 9, 2010.
    • Filing Date: January 12, 2006.
    • Brief Description: This patent, assigned to the same entity as US8621627, describes virtualizing the operation of intelligent network interface circuitry. This is extremely relevant as it lays groundwork for NICs operating in virtualized environments.
    • Potential Anticipation (35 U.S.C. § 102): Claims 1, 7, 24 (highly relevant to the general concept of intelligent NICs in virtualized environments, and likely foundational to the problem solved by US8621627).

27. US7925795B2 (Broadcom Corporation)

    • Full Citation: US7925795B2, "Method and system for configuring a plurality of network interfaces that share a physical interface".
    • Publication Date: April 12, 2011.
    • Filing Date: April 30, 2007.
    • Brief Description: This patent focuses on configuring multiple network interfaces that share a physical interface. This is relevant to NIC architecture in virtualized or multi-function scenarios.
    • Potential Anticipation (35 U.S.C. § 102): Claims 1, 7, 24 (relevant to the configuration and management of NICs in a shared environment, potentially contributing to the architecture enabling US8621627).

28. US20090254990A1 (Mcgee William Gerald)

    • Full Citation: US20090254990A1, "System and method for intelligent coordination of host and guest intrusion prevention in virtualized environment".
    • Publication Date: October 8, 2009.
    • Filing Date: April 5, 2008.
    • Brief Description: This patent application is highly relevant as it directly addresses intelligent coordination of host and guest intrusion prevention in a virtualized environment. This clearly describes the problem domain and solutions that US8621627 aims to improve upon.
    • Potential Anticipation (35 U.S.C. § 102): Claims 1, 7, 24, and dependent claims related to intrusion detection and virtual machines (very high relevance, likely anticipates the need and general concept of coordinating intrusion prevention between host and guest, even if the specific NIC-offload mechanism differs).

Most Directly Relevant Prior Art:

Based on the descriptions, the following patents appear to be most directly relevant to the core innovations of US8621627:

• US7031267B2 (802 Systems Llc): Highly relevant to NIC-based filtering and dynamically configurable rules.
• US20040213235A1 (Marshall John W.): Relevant to programmable packet classification systems using CAMs for filtering.
• US20050289246A1 (International Business Machines Corporation): Relevant to offloading processing from the host in a virtualized environment.
• US20060075480A1 (Noehring Lee P): Highly relevant to the interaction and data transfer between the NIC and the host for processing.
• US20060206300A1 (Microsoft Corporation): Highly relevant to the context of VM network security and the problem US8621627 addresses.
• US7660306B1 (Chelsio Communications, Inc.): Extremely relevant as it describes virtualizing intelligent NIC operations, likely a foundational patent for the assignee.
• US20090254990A1 (Mcgee William Gerald): Most directly relevant as it addresses intelligent coordination of host and guest intrusion prevention in a virtualized environment, directly anticipating the problem space.

These documents collectively establish a prior art landscape that includes NIC-based packet filtering, offloading host tasks in virtualized environments, and the need for intrusion prevention in virtual machine settings. The novelty of US8621627 likely resides in the specific architectural design and methods for efficiently steering data frames for intrusion detection processing to a host-based VM and receiving them back for final routing, specifically leveraging NIC functionality to offload and optimize this process.

Obviousness Analysis under 35 U.S.C. § 103 for US Patent 8,621,627

This analysis considers combinations of prior art references that would render the claims of US Patent 8,621,627 obvious to a person having ordinary skill in the art (POSA) at the time of the invention (filing date: February 12, 2010). The motivation to combine these references is also discussed.

The core innovation of US Patent 8,621,627 lies in offloading intrusion detection and prevention processing to a virtual machine on the host, with a Network Interface Controller (NIC) intelligently steering traffic for this processing, and potentially performing initial filtering itself. The patent emphasizes the efficiency gains and latency reduction compared to conventional software virtual switches or external appliances.

Prior Art References for US8621627:

The patent itself lists several prior art documents. While some are general, others are more directly relevant to the claimed invention.

• US 2006/0206300 A1 (Microsoft Corporation): "VM network traffic monitoring and filtering on the host"
  • This reference describes monitoring and filtering VM network traffic on the host. This directly addresses intrusion detection in a virtualized environment.
• US 2009/0254990 A1 (McGee, William Gerald): "System and method for intelligent coordination of host and guest intrusion prevention in virtualized environment"
  • This patent application explicitly discusses intelligent coordination of host and guest intrusion prevention, which aligns with the overall goal of US8621627.
• U.S. patent application Ser. No. 11/250,894 (Chelsio Communications, Inc.): "Filtering Ingress Packets In Network Interface Circuitry."
  • This is explicitly incorporated by reference into US8621627 and describes filter functionality within the NIC, applying accept/reject actions and additional filtering rules.

Obviousness Combinations:

Combination 1: US 2006/0206300 A1 (Microsoft) in view of US 2009/0254990 A1 (McGee) and general knowledge of NIC capabilities.

• Rationale: US 2006/0206300 A1 teaches monitoring and filtering VM network traffic on the host, which covers the "additional processing" aspect (intrusion detection) being performed by a VM on the host. US 2009/0254990 A1 further details "intelligent coordination of host and guest intrusion prevention," reinforcing the concept of a dedicated VM for such security tasks. A POSA would understand that traditional software virtual switches can be performance bottlenecks, as acknowledged in the background of US8621627. Given the known capabilities of NICs to offload network processing (e.g., TCP/IP offload engines were already prevalent), a POSA would have been motivated to offload some of the network traffic steering and initial filtering related to intrusion detection to the NIC itself to improve performance and reduce host overhead. The motivation would be to enhance the efficiency of the intrusion detection system by leveraging hardware acceleration available in NICs. This combination would likely render Claim 1 obvious, as it teaches receiving a data frame, determining if additional processing (intrusion detection from US 2006/0206300 A1 and US 2009/0254990 A1) is needed, sending it to the host VM for that processing, and then receiving it back and steering it to the destination.

Combination 2: Combination 1 further in view of U.S. patent application Ser. No. 11/250,894 (Chelsio).

• Rationale: Building on Combination 1, U.S. patent application Ser. No. 11/250,894 (Chelsio) directly teaches "Filtering Ingress Packets In Network Interface Circuitry." This reference explicitly describes filter functionality within the NIC that can apply accept/reject actions and modify frames. A POSA, seeking to further optimize the performance of the intrusion detection system described in Combination 1, would be motivated to integrate the NIC's filtering capabilities to pre-process frames. This pre-processing would allow the NIC to drop clearly malicious or unnecessary frames before they even reach the host-based intrusion detection VM, thereby reducing the load on the host and the intrusion detection VM. This combination would particularly render Claim 5 and Claim 22 obvious, which claim that the NIC can drop frames that would otherwise be sent to the host for additional processing. It would also contribute to the obviousness of Claim 7, as the filtering rules applied by the NIC could be considered an "indication in the data frame" (or derived from it) upon which the determination for additional processing is based. Furthermore, the configuration of these filter rules by the host-based intrusion detection processing, as mentioned in US8621627, aligns with the "intelligent coordination" described in McGee.

Combination 3: Combination 2 further in view of the "oVLAN tag" concept (Embodiment 2) or "MAC-in-MAC encapsulation" (Embodiment 3) from the specification of US8621627 and general networking knowledge.

• Rationale: The specification of US8621627 introduces specific mechanisms like oVLAN tags (Embodiment 2) and MAC-in-MAC encapsulation (Embodiment 3) for the NIC to indicate that a frame needs intrusion detection processing and for steering. These are well-known networking techniques for tagging and encapsulating traffic to influence forwarding decisions. A POSA, having the motivation to use the NIC for intelligent steering (as established in Combination 1 and 2), would readily apply these established networking techniques to differentiate and steer traffic to the intrusion detection VM. For example, adding an oVLAN tag to frames requiring inspection or encapsulating them in a MAC-in-MAC header with a specific destination MAC address (e.g., for the IDS VM) would be an obvious implementation choice to signal the NIC to route the traffic appropriately. This specifically addresses the "based on an indication in the data frame" aspect of Claim 7 and Claim 13 (adding an indication) and Claim 19 (Ethernet header as an indication). The patent itself notes that an oVLAN tag refers to a 4-byte IEEE 802.1 Q-in-Q encapsulation according to Ethernet standards, indicating it as a known technology.

Motivation to Combine:

The primary motivation for a POSA to combine these prior art references would be to overcome the performance bottlenecks and latency issues associated with host-based software virtual switches and external network appliances for intrusion detection in virtualized environments, as explicitly identified in the background of US8621627. The desire to improve efficiency, reduce CPU overhead on the host, and minimize communication latency for security processing would drive a POSA to leverage the capabilities of a NIC to offload and intelligently steer network traffic for intrusion detection. The existing knowledge of NIC offload functions and standard networking encapsulation techniques would provide the tools for implementing such a solution.

I'll research the specific record for US 8,621,627, focusing on term adjustments, family members, and expiration. Let me run targeted searches.

Let me look for the front-page term-adjustment notice and the patent-office record directly.

Let me try to pin down the exact PTA figure and family/continuation details.

Scope, identity check, and verification

Literal-identifier discipline. I searched on the exact string 8621627. The only authoritative hits returned were US 8,621,627 B1 itself and its sibling US 8,856,947 B1. No similar-number substitution (e.g., 8,621,671 / 8,626,127 / 8,612,627) was made, and nothing in the returned set belonged to a different patent.

Sources grounding this section

• Full authoritative record: https://patents.google.com/patent/US8621627/en (fetched 2026-09-25)
• https://www.freepatentsonline.com/8621627.html (examiner of record JAMSHIDI, GHODRAT; attorney Lee & Hayes PC/CHELSIO)
• https://uspto.report/patent/grant/8621627
• Family/litigation cross-references in the record: Unified Patents docket link (…/case/7%3A26-cv-00148), Darts-ip family link (…?family=49776265)
• USPTO Assignment Center: https://assignmentcenter.uspto.gov/

Date note (contradiction flagged, not resolved). This task states the current date is April 26, 2026; the system context states 2026-09-30; the fetched Google Patents record is timestamped 2026-09-25. All three are incompatible. I use the record dates as ground truth for the patent and treat the "current date" only as the vantage point. Any date-sensitive statement below is anchored to a record-dated event, not to "today."

---

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

What the record states, verbatim

Under Classifications / legal-status the record reads:

Status: Active · expires 2031-09-24
2031-09-24 — Adjusted expiration · legal-status · Critical

Derived PTA figure — ≈ 589 days (inference, not a quoted front-page number)

Day-count check: 2030-02-12 → 2031-02-12 = 365 days; 2031-02-12 → 2031-09-24 = 224 days (Feb 12→Mar 12 = 28; +31, +30, +31, +30, +31, +31 = 212; +12 = 224). 365 + 224 = 589.

Plausibility check. Pendency was 2010-02-12 → 2013-12-31 = 1,418 days (~3.88 years). The "B-delay" ceiling alone (pendency minus the 3-year mark of 1,095 days) is ≈ 323 days, before any A-delay credit and before any § 154(b)(2)(C) applicant-delay or RCE exclusion. A total of 589 days is therefore arithmetically consistent with an A-delay + B-delay computation under Wyeth v. Kappos, 591 F.3d 1364 (Fed. Cir. 2010) — which is the correct standard because the '627 issued 2013-12-31, long after the PTO's 2010 switch to Wyeth-conforming calculations.

Confidence / what I could NOT confirm. I assign moderate confidence to the 589-day figure. My searches returned no PTA-determination document, Notice of Allowance PTA notice, request for reconsideration, or certificate of correction specifically for 8,621,627 — the PTA hits I retrieved (e.g., '781, '499, 7,579,227, 8,394,084, 8,647,677, 9,150,619) are unrelated patents. The figure above is a derivation from the record's own adjusted-expiration field, not a reading of the printed front-page "Notice." To state the PTA as a hard number, pull the front page of the US 8,621,627 B1 grant PDF or the Patent Center Patent Term Adjustment tab (https://patentcenter.uspto.gov).

Reduction risk already ruled out / not ruled out.

• No terminal disclaimer shown for '627. The record explicitly marks a terminal disclaimer where one exists — e.g., sibling-family patent US 9,537,878 B1 is annotated "This patent is subject to a terminal disclaimer" — and no such annotation appears on '627 or on the '577 application. Compare 35 U.S.C. § 154(b)(2)(B): a terminal disclaimer would cap the adjusted term at the disclaimed date.
• No § 154(b)(2)(C) applicant-delay recalculation event is visible in the record (no certificate of correction reducing PTA). The "Legal Events" table for '627 contains no certificate-of-correction or PTA-recalculation entry — only assignments, grant, and three maintenance-fee payments.

---

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

None, and none is legally available. PTE under § 156 compensates a patentee for a regulatory review period for a "product" — a drug, medical device, food additive, or color additive — before commercial marketing. US 8,621,627 claims a network interface controller and frame-steering methods (class H04L 63/14xx, H04L 63/02xx, H04L 67/10xx). There is no FDA/regulatory pre-market review period to compensate. No PTE entry, no § 156 application, and no PTE-related legal event appears anywhere in the record.

Practical consequence: the entire extension of the '627 term consists of PTA under § 154(b). Unlike PTE, PTA is subject to the statutory ODP interaction addressed in In re Cellect / Allergan v. MSN — see note in §6 below.

---

3. Continuation, divisional, and CIP applications

The record's "Priority Applications (2)", "Family Applications (2)", and "Related Child Applications (1)" tables are mutually consistent and exhaustive within the displayed family:

• Divisionals: none recorded. No application in the family is designated a divisional.
• Continuations-in-part: none recorded. All family members carry a priority date of 2010-02-12, identical to the parent's filing date — which is what you would expect for a straight continuation and would not expect for a CIP (a CIP would add new matter and could shift the priority date for some claims).
• Continuation of the continuation / further children of '577: none shown. "Family Applications After (1)" lists only US 14/099,577.
• Reissue / reexamination: none shown in the record's legal-events table.

Sequencing anomaly to be aware of (not a correction). The '627 timeline displays a single line, "2013-12-06 — Priority to US14/099,577," which reads as though the parent obtained priority from the child. Reading it literally against the two structured tables, 2013-12-06 is the child's filing date, and the child's priority date is 2010-02-12. The parent did not gain priority from the child. I flag this only so the odd line is not misread as a priority claim running the wrong direction.

---

4. Related family members

• Family (INPADOC/Google) ID: 49776265, tied in the record to the Darts-ip link https://patents.darts-ip.com/?family=49776265… labelled "First worldwide family litigation filed."
• Country Status: "(1) US (2)" — one jurisdiction (US), two family members. No foreign family members are shown (no EP, JP, CN, KR, or PCT-national-stage counterparts). This resolves the uncertainty flagged in the earlier Derivative-works section: on the displayed record, there are no non-US family members. If you need to be certain, confirm against Espacenet's INPADOC extended family, which occasionally surfaces members Google omits.
• "Also Published As": US 8,856,947 B1 (2014-10-07) — the only sibling.
• No US pre-grant publication is listed ("Publications (1)" lists only US8621627B1). Given a 2010-02-12 filing, an 18-month publication (≈ August 2011) would ordinarily exist. Its absence from the record is a data gap, not proof of a nonpublication request. Low confidence — do not treat as established.
• Not family members. EP 3,476,101 A4 (Pensando Systems) and US 2005/0138402 A1 appear in the record only because EP'101's search report cites US 8,621,627 B1 as a "Y" reference (passage "column 2, line 44 – column 5, line 33") with US 2005/0138402 A1 as the "X" reference. That is citation traffic, not kinship.
• Litigation in the family: the '627 record carries a Unified Patents docket entry for a Texas Western District Court case (7:26-cv-00148), matching Speednic LLC v. Nvidia Corp et al. as described in the previously generated litigation section. Litigation does not change term.

---

5. Projected expiration date

Confidence: High for the '627 expiration of 2031-09-24 as the record's stated adjusted expiration. Moderate as to the reason (589 days of PTA) because I derived it rather than reading a quoted PTA notice. Unable to verify the '947 sibling's PTA and expiration.

Caveats that could move the date:

1. A certificate of correction altering the printed PTA. None appears in the '627 legal-events table, but patentee-side PTA litigation in this era (Wyeth/Exelixis/Novartis) is exactly the kind of event that produced such corrections on other patents.
2. A terminal disclaimer filed but not shown. § 154(b)(2)(B) would cap the term at the disclaimed date.
3. A statutory disclaimer of all claims, or a reissue surrender — none shown.
4. Because the '627 term runs to 2031-09-24 and the '947 continuation claims the same 2010-02-12 priority, the family presents a potential obviousness-type double-patenting question of the In re Cellect / Allergan v. MSN type (whether PTA-extended term on one member is properly counted for ODP purposes). Note: this is my analysis, not a record fact, and no ODP proceeding, rejection, or terminal disclaimer appears in the record.

---

6. Maintenance fees — no lapse risk

All three maintenance fees are recorded, the last one on 2025-06-20 (12th-year, small entity, event code M2553). The 11.5-year payment sustains the patent for the remainder of the statutory term, so no further maintenance fee is due before expiration in 2031, and there is no fee-based early-expiration risk. The only ways the patent ends before 2031-09-24 are adverse events (full statutory disclaimer, reissue surrender, or a final holding in the pending litigation that eliminates all asserted claims).

---

7. Contradictions with previously generated sections (flagged per instruction)

1. Current assignee. The earlier "Patent summary," "Assignment history," "NPE/troll-pattern signals," and "Verdict" sections all conclude that Chelsio Communications Inc. remained the assignee and that no Chelsio→Speednic transfer was recorded. The authoritative record contradicts this: Current Assignee = SPEEDNIC LLC, reassignment recorded 2026-02-13 ("ASSIGNMENT OF ASSIGNOR'S INTEREST," assignor Chelsio Communications, Inc.). The later Derivative-works section already corrected this; I record it once here for completeness. The "Verdict" of insufficient data on NPE status should be re-read in light of the now-recorded transfer plus the W.D. Tex. filing.
2. Silicon Valley Bank security interest. The "Assignment history" timeline lists the 2014-10-14 SVB security interest (Reel 033990/0451) but never shows a corresponding release from Silicon Valley Bank, while the record's 2025-12-26 entry releases CSNK WORKING CAPITAL FINANCE CORP. (Reel 074070/0784) — an entity that appears nowhere in the earlier assignment timeline. The earlier chain is therefore incomplete on the SVB lineage. I flag it rather than attempt a reconstruction.
3. Derivative-works open question now closed. That section listed "whether foreign family members exist under INPADOC family 49776265" as uncertain. The record's Country Status "(1) US (2)" answers it: no foreign members shown.
4. PTA day count is still the "exact § 154(b) patent-term-adjustment day count" that the Derivative-works section flagged as uncertain on the printed front page. That remains unresolved; §1 above supplies the derived value (589) and the method to confirm it.

---

8. Bottom line

• PTA: yes — the record's adjusted expiration of 2031-09-24 implies ≈ 589 days of adjustment on a 20-year term from 2010-02-12; the exact front-page figure is unconfirmed by any document I could retrieve.
• PTE: none, and not legally available (no § 156 regulatory-review product).
• Continuations: exactly one — US 14/099,577, filed 2013-12-06, granted as US 8,856,947 B1 on 2014-10-07.
• Divisionals/CIPs: none in the family.
• Family: INPADOC/Google family 49776265, two members, US only; no foreign counterparts shown.
• Projected expiration of US 8,621,627: 2031-09-24, all maintenance fees paid, no terminal disclaimer shown.

Highest-value next verification steps: (1) front page of the US 8,621,627 B1 grant PDF for the literal "extended or adjusted under 35 U.S.C. 154(b) by ___ days" line; (2) the Patent Center PTA tab for the A / B / C / overlap / applicant-delay breakdown; (3) the US 8,856,947 B1 front page for the sibling's own PTA; (4) Espacenet INPADOC extended family for family 49776265 to confirm the US-only finding.

I'll first verify the patent record against the USPTO-facing sources, then build the disclosure.

DEFENSIVE DISCLOSURE / PRIOR-ART PREEMPTION DOCUMENT

Target patent under analysis: US 8,621,627 B1 — “Intrusion detection and prevention processing within network interface circuitry”
Application: US 12/704,884 · filed 2010-02-12 · granted 2013-12-31 · family ID 49776265 · continuation US 14/099,577 → US 8,856,947 B1
Record retrieved and verified: patents.google.com/patent/US8621627/en (full authoritative text), freepatentsonline.com/8621627.html, uspto.report/patent/grant/8621627, patentimages.storage.googleapis.com PDF of US008621627B1
Disclosure date: 2026-04-26
Purpose: Establish enabling, dated prior art that renders downstream incremental improvements obvious under 35 U.S.C. § 103 and non-novel under § 102(a)(1)/(a)(2), in each of the derivation axes below.

---

0. Verification notes and reading conventions

0.1 USPTO-identity check (literal). A search for the identifier 8621627 returned exactly two things: US 8,621,627 B1 itself and its own continuation US 8,856,947 B1 (application 14/099,577, filed 2013-12-06). No similar-number substitution was made. Examiner of record per FreePatentsOnline: JAMSHIDI, GHODRAT; attorney of record: Lee & Hayes PC/CHELSIO. This differs from the correspondent listed on the original 2010 assignment (Nixon Peabody LLP), which is not a contradiction — prosecution counsel and assignment correspondent are independent fields.

0.2 Ownership contradiction resolved. The authoritative record lists Current Assignee: SPEEDNIC LLC, reassignment recorded 2026-02-13, conveyance “ASSIGNMENT OF ASSIGNOR’S INTEREST,” assignor CHELSIO COMMUNICATIONS, INC. This supersedes the earlier section’s conclusion that no Chelsio→Speednic transfer was recorded. The co-pending litigation (Speednic LLC v. Nvidia Corp, Dell Technologies Inc, W.D. Tex. 7:26-cv-00148, filed 2026-04-16) is consistent with that transfer.

0.3 The patent is already functioning as prior art. Independent of this document, a third-party search hit shows US 8,621,627 B1 cited as a “Y” (obviousness) reference against claim 13 of a separate family — cited passage “column 2, line 44 – column 5, line 33” — in the EPO file for EP3476101A4 (Pensando Systems Inc., “Network security methods and systems”), with US 2005/138402 A1 cited as the “X” reference. Source: patentimages.storage.googleapis.com/76/05/e8/4585b0f2c4c262/EP3476101A4.pdf. This is direct evidence that the ‘627 disclosure is being read broadly as genus-level prior art in the NIC-inline-security space, which is exactly the reading this document extends.

0.4 Conventions. Each entry DD-x.y is an independent enabling disclosure (a stand-alone prior-art publication). “Pre-empts” names the claim element or specification embodiment that the disclosure is meant to foreclose as a later point of novelty. All figures are Mermaid and intended for programmatic rendering. Numeric parameters are given as disclosed embodiments, not as optima.

0.5 Anchors used (no re-summary of the patent). Claim 1 (receive → determine → provide to host via host bus → receive back → steer by destination address), claim 7 (the determination is made “based on an indication in the data frame,” plus claims 10–19 on the nature of the indication: control tag, oVLAN tag, Ethernet header), claim 24 (provide for additional processing prior to providing to a destination), and the dependent themes of claims 2–3/25–26 (protocol offload), 5–6/22–23/28–29 (NIC-side filter drop with host-configurable rules), 20–21 (replication to multiple destinations), and the specification’s Embodiments 1–4 (source-port steering; oVLAN tag; MAC-in-MAC; prefix flit/word).

---

PART A — DERIVATIVES OF CLAIM 1

(Independent claim: receive frame → determine whether additional processing is required → provide to host via host bus → receive processed frame back → steer by destination address.)

DD-1.1 — Axis 1 (Material/Component Substitution): TCAM + FPGA steering fabric on a coherent CXL host bus

Enablement. Replace the multi-purpose switch function with a discrete classification/steering fabric: an 8,192-entry × 512-bit ternary CAM matched against the tuple {SA[48], DA[48], outer-VLAN[12], oVLAN-present[1], EtherType[16], L4-SPORT[16], L4-DPORT[16], ingress-port[3]}, with an SRAM exact-match hash of 64K entries as miss path and a 4K-entry DA-indexed L2 lookup producing a 16-bit egress bitmap plus an 802.1D multicast expansion RAM. Replace the host bus with CXL 3.0 ×16 (64 GT/s/lane, 256-byte flit, memory-semantic). Frames with verdict INSPECT are DMA-written into a host-attached cache-coherent inspection ring of 1,024 × 2 KB descriptors, doorbelled through a CXL.mem MMIO aperture; the IDS agent (a KVM guest owning an SR-IOV VF) rewrites payload in place and posts a completion descriptor on a return ring; the NIC firmware drains the return ring via CXL.cache and drives egress. Rule updates use a double-buffered CAM shadow with RCU-style pointer swap so classification never stalls. Disclosed round-trip budget: ≤ 4 µs at 60 % offered load.

Pre-empts: claim 1 host-bus element combined with claim 7 “indication” classification; any later claim to a coherent-interconnect NIC loopback to a host inspection agent.

graph LR
  A["Ingress MAC 400GE"] --> B["512-bit TCAM classifier"]
  B -->|"verdict drop"| C["Discard + counter"]
  B -->|"verdict inspect"| D["CXL 3.0 coherent ring write"]
  D --> E["Host IDS agent on VF"]
  E --> F["Completion return ring"]
  F --> G["DA indexed L2 lookup"]
  G --> H["16-bit egress bitmap"]
  H --> I["Egress MAC / replication RAM"]

DD-1.2 — Axis 1 (Material/Component Substitution): DPU-resident Arm cluster as the processing endpoint, verdict computed by eBPF/XDP

Enablement. The NIC die is replaced by a DPU with an 8-core Arm Cortex-A78 cluster, a 32 MB system-level cache and a hardware mailbox. The “additional processing” entity is a Linux instance on the DPU itself rather than a guest on the server CPU. The steering verdict is produced by an XDP program compiled at runtime to the NIC’s match-action pipeline: bpf_redirect_map() to a DEVMAP indexed by a 3-entry verdict vector {host_inspect, dpu_inspect, fast_forward}, with per-flow rate and byte budgets enforced by a token bucket in the pipeline. Program replacement is atomic via a two-slot pipeline image with a generation counter; a version tag in pipeline metadata lets the steering stage detect frames classified by a stale image and re-run them. Disclosed: 25 M frames/s per Arm cluster, verdict-to-redirect latency 900 ns.

Pre-empts: later claims reciting “host” as any co-packaged general-purpose processor performing the additional processing (the live claim-construction question in the 7:26-cv-00148 complaint analysis).

graph TD
  A["Frame ingress"] --> B["Programmable parser header vector"]
  B --> C["eBPF XDP program slot A/B"]
  C -->|"host_inspect"| D["Mailbox to server CPU VM"]
  C -->|"dpu_inspect"| E["Arm cluster IDS container"]
  C -->|"fast_forward"| F["Direct egress"]
  D --> G["Return with original SA"]
  E --> G
  G --> H["Egress bitmap and replication"]

DD-1.3 — Axis 2 (Operational Parameter Expansion): 1.6 Tb/s with split fast/slow paths and 80 ns cut-through

Enablement. Scale the receive path to 1.6 Tb/s aggregate (64 × 25 Gb/s PAM4 SerDes lanes or 32 × 800GBASE-R), with HBM3 packet buffer (8 GB, 1.2 TB/s). Because the inspection loopback cannot meet line rate for every frame, the pipeline is split: a cut-through fast path (store ≤ 128 B header, forward after 80 ns) carries flows marked verified by a per-flow trust table, and a store-and-forward slow path (full frame, 512 KB on-die SRAM) carries unverified flows routed to the host. Trust is granted by the host IDS writing a 20-bit 5-tuple hash with a 60-second refresh TTL into a 1M-entry table; a hash collision in the trust table forces the flow onto the slow path. Per-queue credit-based flow control (802.1Qbb PFC on 8 priority classes) with occupancy alarm thresholds at 40 % / 70 % / 90 % prevents head-of-line collapse under inspection backlog.

Pre-empts: later claims differentiating on line rate, cut-through vs store-and-forward, or per-flow trust caching in a NIC inspection loopback.

graph LR
  A["1.6 Tb/s ingress"] --> B["128B header sniff"]
  B --> C{"Trust table hit?"}
  C -->|"hit"| D["Cut-through forward 80ns"]
  C -->|"miss"| E["Store-and-forward SRAM 512KB"]
  E --> F["Loopback to IDS endpoint"]
  F --> G["Trust grant write 20-bit hash"]
  G --> C
  D --> H["Egress scheduler PFC 8 classes"]
  E --> H

DD-1.4 — Axis 2 (Operational Parameter Expansion): wide-temperature and radiation-tolerant variant

Enablement. A variant qualified for −55 °C to +125 °C junction temperature and total ionizing dose of 100 krad(Si), for automotive zonal gateways and LEO satellite payloads. Specific measures: silicon-on-insulator CMOS; triple-modular-redundant steering finite-state machine with 2-of-3 voting on the verdict word; SECDED EDAC on all SRAM with scrubbing every 1 s and correctable-error counters that force a fail-safe transition after 4 errors/second; magnetoresistive (MRAM) rule table immune to single-event upsets; rad-tolerant SerDes with 10⁻¹⁵ BER and adaptive equalization. Thermal design keeps the 8 MB inspection ring in a separate power domain that can be clock-gated to 1/16 rate at 125 °C while the steering path continues at full rate. Disclosed latch-up immunity > 120 mA and SEL-free operation at 125 °C.

Pre-empts: later claims reciting space-qualified or automotive-qualified NIC-inline inspection.

graph TD
  A["Ingress from rad-tolerant SerDes"] --> B["MRAM rule table"]
  B --> C["TMR steering FSM 2of3 voting"]
  C --> D["Inspection ring EDAC + scrub"]
  D --> E["Scrubder correctable error counter"]
  E -->|"14 err/s"| F["Fail-safe degraded steering"]
  C --> G["Thermal domain governor"]
  G --> H["Clock-gate ring at 125C"]
  G --> I["Full-rate egress"]

DD-1.5 — Axis 3 (Cross-Domain): avionics ARINC 664 / AFDX and rail ETCS

Enablement. Apply the receive-determine-provide-return-steer loop to a deterministic avionics Ethernet. Frames carry ARINC 664 Part 7 Virtual Link identifiers (VL ID, 16-bit) and a Bandwidth Allocation Gap; the NIC’s steering table is keyed on VL ID rather than MAC DA. Because VLs are statically configured and every VL has a defined Lmax (max frame size) and BAG, the “additional processing” verdict is computed from a per-VL integrity state machine: if the received frame length exceeds Lmax, if the BAG is violated beyond tolerance, or if the integrity-check sequence on a redundant A/B network pair disagrees, the frame is routed to the avionics IDS partition instead of the consuming line-replaceable unit. On the return path the frame is emitted on both A and B networks with a 1 ms skew budget. Rail ETCS variant keyed on ETCS telegram identifiers with a 2 s safety timeout that forces the partition into a safe state.

Pre-empts: later claims applying the technique in deterministic / safety-critical switched Ethernet.

graph LR
  A["VL frame from A or B network"] --> B["VL ID keyed steering table"]
  B --> C{"Lmax and BAG check"}
  C -->|"pass"| D["Deliver to LRU partition"]
  C -->|"violation"| E["Avionics IDS partition"]
  E --> F["Verdict and repair"]
  F --> G["Dual-network egress A plus B"]
  G --> D

DD-1.6 — Axis 3 (Cross-Domain): agricultural ISOBUS field gateway and substation IEC 61850 GOOSE

Enablement. Two concrete non-networking-industry instantiations. (a) ISOBUS: a tractor/implement gateway with a 100BASE-T1 physical layer; the steering key is the ISO 11783 source address and PGN triplet; frames containing a Working Set Master claim from an unrecognized implement address are looped to an IDS instance running on the vehicle controller before the task controller receives them; latency budget 10 ms (ISO 11783 slow cycle). (b) Substation: a merging unit / bay controller using IEC 61850 GOOSE with a 3 ms transfer-time requirement; the IDS loopback is restricted to a sample mode in which only the first N frames of each changed-state sequence are inspected, with sticky trust on stNum/sqNum continuity, so that steady-state GOOSE traffic bypasses inspection. Both variants retain the destination-address-keyed steering on the return path.

Pre-empts: later claims applying inspection loopback in industrial or agricultural fieldbus-over-Ethernet.

graph TD
  A["Fieldbus Ethernet frame"] --> B["Source-address and PGN key"]
  B --> C{"Trusted implement or stNum continuity?"}
  C -->|"yes"| D["Direct to task controller"]
  C -->|"no"| E["Loopback to IDS instance"]
  E --> F["Sticky trust write"]
  F --> D
  D --> G["10 ms or 3 ms deadline monitor"]

DD-1.7 — Axis 3 (Cross-Domain): consumer CPE router and hospital VLAN segmentation appliance

Enablement. (a) Consumer CPE: a single-chip gateway (4× GbE + Wi-Fi 6) where the “additional processing” entity is a container on the SoC’s second Cortex-A53; the steering verdict uses a 4,096-entry connection tracker in DRAM rather than on-die CAM, and the return path redirects by NAT-translated destination. Budget: 200 Mb/s inspected, unlimited uninspected, with a user-visible LED when inspection is saturated. (b) Hospital edge: an 802.1Q-based segmentation appliance where the steering key includes the VLAN pair (ingress/egress) and a Medical Device Class tag; frames crossing between a clinical VLAN and a guest network always take the loopback path to the security appliance; frames within a clinical VLAN bypass unless a device's risk score (maintained as a 8-bit counter incremented per anomaly) exceeds 128. Both use the same return-path destination resolution.

Pre-empts: later claims on consumer-grade or healthcare-grade NIC inspection offload.

graph LR
  A["Ingress frame"] --> B["VLAN pair and device class key"]
  B --> C{"Cross-segment or risk above 128?"}
  C -->|"yes"| D["Loopback to security appliance"]
  C -->|"no"| E["Bypass to host stack"]
  D --> F["Risk counter update"]
  F --> G["Steer by destination address"]
  E --> G

DD-1.8 — Axis 4 (Emerging Tech): learned steering policy and closed-loop telemetry

Enablement. Replace the hand-written filter rule set with a gradient-boosted decision tree (max depth 6, 511 nodes, quantized to int8, 6 KB) evaluated in the steering stage on a 64-byte feature vector derived from the frame: header field deltas, inter-arrival time histogram (16 bins), per-flow byte count bucket, TTL bucket, TCP flag mask, entropy estimate of the first 64 payload bytes, and a flow-age bucket. Output is a scalar suspiciousness score; scores above θ₁ take the loopback path, scores below θ₂ bypass, and the band between is deterministically loopbacked with 1-in-16 sampling. The host IDS emits ground-truth labels on the return descriptor; the NIC firmware accumulates these in a 65,536-sample ring and retrains out-of-band, loading a new tree through a shadow slot. Disclosed drift guard: if the positive-label rate deviates >3σ from the trailing 24 h baseline, the pipeline reverts to θ₂ = 0 (all-loopback) fail-safe.

Pre-empts: later claims reciting ML/MLOps in NIC steering decisions.

graph LR
  A["Frame header and timing"] --> B["64-byte feature vector"]
  B --> C["GBDT 511 nodes int8"]
  C --> D{"Score above theta1"}
  C --> E{"Score below theta2"}
  D -->|"yes"| F["Loopback to IDS"]
  E -->|"yes"| G["Fast forward"]
  D -->|"no"| H["Sampled loopback 1in16"]
  F --> I["Label return descriptor"]
  I --> J["65K sample ring and retrain"]
  J --> C

DD-1.9 — Axis 4 (Emerging Tech): IoT sensor attestation, TEE-bound keys, and blockchain-anchored verdict ledger

Enablement. Sensor-side attestation using IEEE 802.1AR IDevID and TPM 2.0 quotes; the NIC verifies the sensor quote via a SPDM exchange before granting a trust entry, so that an unattested sensor’s frames always take the loopback path. The IDS verdict and a 32-byte BLAKE3 digest of the canonicalized frame header plus a 8-byte epoch counter are appended to a per-NIC append-only log. Every 10 s the log’s Merkle root is signed with an NIC-resident ECDSA P-256 key held in a secure element and published to a permissioned ledger; a get_proof(index) call returns the Merkle inclusion path so any auditor can verify that a given frame was inspected with a given verdict without the NIC disclosing payload. The chain anchor is intentionally decoupled from the data path: ledger unavailability degrades to local 64 MB spooling, then to a ledger_degraded flag, never to packet loss.

Pre-empts: later claims combining NIC inspection with distributed-ledger audit or hardware attestation gating.

sequenceDiagram
  participant S as Sensor
  participant N as NIC Steering
  participant I as IDS Endpoint
  participant L as Ledger
  S->>N: IDevID and SPDM quote
  N->>N: Verify quote, write trust entry
  N->>I: Loopback frame plus flow id
  I->>N: Verdict plus BLAKE3 digest
  N->>N: Append to hash log
  N->>L: Merkle root every 10s
  L-->>N: Anchor ack or spool

DD-1.10 — Axis 5 (Inverse / Failure Mode): fail-open, fail-closed, and low-power degraded personalities

Enablement. Three selectable personalities with explicit transition conditions. (a) Fail-open HA profile: if the host IDS fails to return a frame within T_inspect (default 5 ms) the NIC forwards the frame unmodified and sets a per-flow uninspected bit in a sideband timestamp register; after 100 consecutive timeouts the pipeline latches to bypass and raises a management interrupt; no frames are dropped. (b) Fail-closed containment profile: on the same timeout the frame is copied to a quarantine ring (a separate 802.1Q VLAN, default 4094) and the originating port is administratively damped with an exponential backoff (1 s, 2 s, 4 s… capped at 60 s); management must explicitly clear. (c) Low-power sniff-only personality: the IDS endpoint is not resident; the steering stage only copies candidate frames to a 4 MB mirror ring and forwards originals untouched, with the pipeline clocked at 1/8 and the copy engine limited to 1 Mb/s. Disclosed brownout behavior: below 2.9 V the rule table is preserved in MRAM and the pipeline enters bypass (a) unconditionally, because losing forwarding is judged worse than losing inspection.

Pre-empts: later claims reciting inspection timeouts, quarantine VLANs, or power-state-dependent inspection bypass.

stateDiagram-v2
  [*] --> Active
  Active --> Timeout: IDS return overdue
  Timeout --> FailOpen: profile HA
  Timeout --> Quarantine: profile containment
  Quarantine --> Damped: port backoff 1s to 60s
  Active --> SniffOnly: low power profile
  SniffOnly --> Active: power restored
  FailOpen --> Active: IDS heartbeat
  Damped --> Active: management clear
  Active --> Bypass: brownout below 2.9V
  Bypass --> Active: rail restored

---

PART B — DERIVATIVES OF CLAIM 7

(Independent claim: the inspect/do-not-inspect determination is made “based on an indication in the data frame”; claims 10–19 particularize the indication.)

DD-7.1 — Axis 1 (Material/Component Substitution): NSH Service Header in place of the oVLAN tag

Enablement. The control indication is an RFC 8300 Network Service Header rather than an 802.1Q Q-in-Q outer tag. Fabric: 4-byte base header (TTL=63, Length=6 × 4-byte words, MD Type=0x1, Next Protocol=0x1 IPv4 / 0x2 IPv6), 4-byte Service Path Header (Service Index decremented per service hop; a 24-bit Service Path ID), and one 4-byte Context Header whose 8-bit “Action” nibble pair encodes action=3 for “loop to inspection endpoint, do not consume SI.” Ingress filtering accepts NSH only from an internal encapsulation port and only if the SPI is in the locally-owned 16-bit range; an NSH arriving on a physical port is dropped and counted. The NIC strips the NSH on egress to a non-NSH destination and writes the original outer 802.1Q back from the Context Header. Disclosed: SI floor of 8 prevents circular service chaining; TTL 0 causes a nsh_ttl_expired drop rather than looping.

Pre-empts: later claims reciting NSH or service-chaining headers as the inspection trigger.

graph LR
  A["Frame with NSH MD1"] --> B{"SPI locally owned?"}
  B -->|"no"| C["Drop and count"]
  B -->|"yes"| D["Read SI and Action nibble"]
  D -->|"action 3"| E["Loop to inspection endpoint"]
  E --> F["Decrement SI"]
  F --> G{"SI below 8"}
  G -->|"yes"| H["nsh_ttl drop"]
  G -->|"no"| I["Strip NSH and restore VLAN"]
  I --> J["Egress"]

DD-7.2 — Axis 1 (Material/Component Substitution): Geneve TLV and VXLAN-GPE option as the indication

Enablement. Use RFC 8926 Geneve with a critical bit set in a Type-Length-Value option (class 0x0143 locally defined, type 0x01, length 8) whose 4-byte value carries {inspect_required:1, original_source_index:17, hop_budget:8, reserved:6}. The NIC parses the Geneve header (Opt Len × 4, protocol type 0x6558 for transparent Ethernet bridging), validates the critical bit, and applies the option. Unrecognized critical options → drop; unrecognized non-critical → forward. Equivalent VXLAN-GPE encoding using the next-protocol field and a reserved-bit option. Original source identity survives the round trip for the return path because original_source_index is carried in the option rather than inferred from the port, which removes the need for any later inference from the ingress queue.

Pre-empts: later claims reciting Geneve/VXLAN options to mark frames for host inspection, or carrying original-source metadata in the marker itself.

graph LR
  A["Geneve frame"] --> B["Parse opt len and TLVs"]
  B --> C{"Critical bit set"}
  C -->|"yes"| D{"Recognized class type"}
  D -->|"no"| E["Drop unknown critical"]
  D -->|"yes"| F["Extract inspect_required and source index"]
  F --> G["Loop to inspection endpoint"]
  G --> H["Return with source index preserved"]
  H --> I["Destination-keyed egress"]

DD-7.3 — Axis 1 (Material/Component Substitution): the indication lives in the interconnect flit, not the Ethernet frame

Enablement. On a host-side packet pipeline, each Ethernet frame is preceded by a fixed 64-byte prefix descriptor carried in the interconnect flit. Field map: bits 0–7 descriptor type/version; 8–9 replication_mode (none/unicast/multicast/broadcast); 10 inspect_override; 11 origin_is_ids; 12–31 origin_vnic_id; 32–47 egress_queue_id; 48–55 hop_count; 56–63 crc8 of descriptor. The inspection determination is made by setting inspect_override=1 in a prefix generated by egress firmware; the same descriptor is regenerated on the return path with origin_is_ids=1 and origin_vnic_id preserved so the pipeline can override normal steering and route the frame to the intended destination vector without re-deriving the source from a port. A descriptor with a bad CRC8 or unknown descriptor type causes a deterministic fallback: full inspection, no bypass. This is a concrete realization of the specification’s “prefix flit/word” embodiment extended with a self-checking field.

Pre-empts: later claims reciting sideband descriptors, prefix words, or pipeline metadata as the inspection trigger and as the carry-forward of original source identity.

graph TD
  A["Host egress frame plus 64B prefix"] --> B["CRC8 and type check"]
  B -->|"bad"| C["Force inspect, no bypass"]
  B -->|"ok"| D{"inspect_override bit"}
  D -->|"1"| E["Loop to inspection endpoint"]
  D -->|"0"| F["Normal steering"]
  E --> G["Return prefix origin_is_ids=1"]
  G --> H["Desired destination vector from prefix"]
  H --> I["Egress"]

DD-7.4 — Axis 2 (Operational Parameter Expansion): stacked indications, depth budgets, and 64-bit markers

Enablement. Extend the indication to a stack of up to 4 nesting levels, each level adding one 4-byte outer marker, so that framed traffic may be routed through a chain of inspection stages. A 4-bit depth field in the innermost marker bounds recursion; the NIC maintains a per-frame depth register decremented at each inspection entry and drops frames at depth 0 with an inspection_loop counter. The marker is widened to 64 bits: {version:4, depth:4, stage_id:8, original_vnic:16, idempotency_key:16, hmac_trunc:8, reserved:8}. The 16-bit idempotency key derived by hashing the original frame header lets the endpoint drop a duplicate that arrives due to retry after a timeout, which is the failure mode that otherwise causes double-counted IDS alerts in multi-stage chains. Tested with 9,000-byte jumbo frames and 4-level nesting, MTU 17,000.

Pre-empts: later claims on nested inspection markers, re-inspection loops, or idempotency in the inspection path.

graph LR
  A["Frame with up to 4 markers"] --> B["Read depth nibble"]
  B --> C{"depth zero"}
  C -->|"yes"| D["Drop inspection_loop counter"]
  C -->|"no"| E["Enter inspection stage"]
  E --> F["Decrement depth, keep idempotency key"]
  F --> G{"Duplicate idempotency key"}
  G -->|"yes"| H["Silent discard at endpoint"]
  G -->|"no"| I["Inspect and re-emit"]
  I --> B

DD-7.5 — Axis 2 (Operational Parameter Expansion): stateless terabit-scale marking with no per-flow state

Enablement. At 1.6 Tb/s the pipeline cannot afford a per-flow state lookup for marking, so marking is made stateless. A CRC32-based hash over {SA, DA, SPORT, DPORT, protocol} selects among 4,096 mark_profile slots; each slot holds a 32-bit mask specifying which of up to 32 conditions (DSCP equality, TCP flag mask, payload length range, VLAN pair, ingress port set) trigger the mark, plus a 16-bit sample rate. A splitmix-style counter per slot provides sampling without per-flow memory: (counter++ * rate) >> 16 == 0. Disclosed: parse cost 42 cycles, zero CAM lookups on the mark path, deterministic behavior for a given hash bucket, and a 1 s profile_epoch so policy changes are observable in telemetry without a state flush.

Pre-empts: later claims on sampling-based or stateless decisions to route frames to inspection.

graph LR
  A["Frame at 1.6 Tb/s"] --> B["CRC32 five-tuple hash"]
  B --> C["Profile slot 4096"]
  C --> D["Condition mask and sample rate"]
  D --> E{"Condition matched"}
  E -->|"yes"| F["Counter splitmix sample"]
  E -->|"no"| G["No mark"]
  F -->|"sampled"| H["Set mark bit"]
  F -->|"not sampled"| G
  H --> I["Loop to inspection endpoint"]
  G --> J["Egress fast path"]

DD-7.6 — Axis 3 (Cross-Domain): telecom 5G N3/N6 — the indication in the GTP-U extension header

Enablement. Apply the marking mechanism at a 5G UPF. The indication is carried in a GTP-U (3GPP TS 29.281) PDU Session Container extension header (extension header type 0x85) whose 1-byte flags field carries a locally reserved bit; PDU type 0 carries the QoS flow identifier. The UPF's steering stage parses the outer UDP/IP layer 4, then GTP-U, then the extension header chain (Next Extension Header Type linked list, terminated by 0x00), and routes frames with the reserved bit to an inspection function co-located on the same host. Inner IP is left opaque. Return-path steering uses the TEID + QFI pair so that the de-encapsulated frame re-emerges on the correct N3 tunnel. Disclosed: extension-header chain depth limit of 8 guards against malformed linked lists; a frame with a truncated extension header is dropped and counted on a per-TEID basis.

Pre-empts: later claims on GTP-U/GTP-C field-based inspection routing or mobile-core inline inspection offload.

graph TD
  A["N3 GTP-U packet"] --> B["Parse UDP and GTP-U header"]
  B --> C["Walk extension header chain"]
  C --> D{"Reserved inspect bit set"}
  D -->|"yes"| E["Loop to UPF inspection function"]
  D -->|"no"| F["Forward to N6"]
  E --> G["TEID and QFI keyed return"]
  G --> H["Re-encapsulate and egress N6"]
  C --> I{"Chain depth above 8"}
  I -->|"yes"| J["Drop malformed and count per TEID"]

DD-7.7 — Axis 3 (Cross-Domain): automotive zonal gateway (SOME/IP) and industrial AVTP/EtherCAT

Enablement. (a) Automotive: the indication is a SOME/IP-SD entry in the service-discovery payload (service ID, instance ID, event group) plus a 1-bit field in the 4-byte SOME/IP header length/type word reserved by the OEM; the zonal gateway loops frames whose service ID maps to a safety- or security-classified service to a hypervisor-resident inspection VM. Budget 500 µs on 100BASE-T1 / 1000BASE-T1 links. (b) Industrial/AVTP: IEEE 1722 AVTP control-format stream data with a reserved-bit indicator in the AVTP header’s version/sv field combination; the inspection endpoint runs on a TSN endpoint synchronized to gPTP so that inspect-and-return occupies a scheduled guard band (802.1Qbv) rather than competing with scheduled traffic. (c) EtherCAT-over-Ethernet: the indication is an EtherCAT datagram command/value marker in a reserved work-counter slot.

Pre-empts: later claims on automotive service-oriented or industrial AVTP/EtherCAT inspection marking.

graph LR
  A["Vehicle or industrial frame"] --> B["Protocol discriminator"]
  B -->|"SOME-IP"| C["Service and instance ID map"]
  B -->|"AVTP 1722"| D["Reserved indicator bit"]
  B -->|"EtherCAT"| E["Datagram work-counter slot"]
  C --> F["Safety or security class lookup"]
  D --> F
  E --> F
  F -->|"classified"| G["Loop to inspection endpoint in guard band"]
  F -->|"unclassified"| H["Scheduled egress"]

DD-7.8 — Axis 3 (Cross-Domain): broadcast contribution SMPTE ST 2110 and satellite DTN

Enablement. (a) SMPTE ST 2110-20/30/40: each essence is a separate RTP/UDP flow; the indication is a locally-scoped RTP header extension (RFC 8285 two-byte form, profile 0xBEDE, appbits reserved) and steering is keyed on the SDP session description so that a compressed video essence marked for inspection is looped while an audio essence on the same multicast address bypasses. Latency budget 1 field (16.7 ms) for contribution; a missed deadline triggers a redundancy switch to the ST 2022-7 hitless stream before inspection is retried. (b) Satellite: Delay/Disruption-Tolerant Networking bundle protocol (RFC 9171) where the indication is a bundle processing control flag plus a canonical block of type inspect-required; because round trips are minutes long, inspection is asynchronous and the bundle is held in a custody-transfer ring until the verdict returns.

Pre-empts: later claims on essence-based or custody-based inspection marking in media or delay-tolerant networks.

sequenceDiagram
  participant SRC as Source
  participant NIC as Gateway Steering
  participant IDS as Inspection Endpoint
  participant DST as Destination
  SRC->>NIC: RTP or bundle with inspect indicator
  NIC->>IDS: Loop candidate essence or bundle
  IDS->>NIC: Verdict and repair
  alt realtime deadline met
    NIC->>DST: Forward within field or bundle window
  else deadline missed
    NIC->>DST: Redundancy switch or custody hold
  end

DD-7.9 — Axis 4 (Emerging Tech): cryptographically bound indications, TEE-bound keys, and post-quantum tag signing

Enablement. Make the indication non-forgeable. The 64-bit marker of DD-7.4 adds an 8-byte truncated tag HMAC-SHA-256(K_epoch, marker || SA || frame_digest_64B), where K_epoch is a 256-bit key held in an NIC secure element and rotated every 300 s with the Key ID carried in the marker. A frame whose marker tag fails verification is dropped, not inspected, and counted as marker_forgery. For long-lived audit obligations, the marker carries a post-quantum signature using ML-DSA-44 (FIPS 204) over the digest, transported in an out-of-band metadata frame rather than in-band to avoid the ~2.4 KB signature inflating data frames. Rules for the endpoint are themselves signed and verified against an allow-list of rule-signing keys before being installed. Disclosed: HMAC verify cost 0.9 µs at 4 parallel engines, forgery false-accept 2⁻⁶⁴.

Pre-empts: later claims on authenticated inspection markers, kernel-key rotation, or post-quantum signing of in-band control metadata.

graph TD
  A["Frame with 64-bit marker"] --> B["Extract key id and hmac_trunc"]
  B --> C["Lookup K_epoch in secure element"]
  C --> D{"HMAC-SHA-256 first 8 bytes match"}
  D -->|"no"| E["Drop as marker_forgery"]
  D -->|"yes"| F["Honor inspect bit"]
  F --> G["Loop to inspection endpoint"]
  G --> H["Return verdict"]
  H --> I["Out-of-band ML-DSA-44 audit record"]

DD-7.10 — Axis 5 (Inverse / Failure Mode): malformed, spoofed, and stuck indications

Enablement. Define the negative space explicitly. (i) Unknown marker version → treat as requiring inspection (never as bypass), count marker_unknown. (ii) Marker present on a port classified as untrusted and the SA not in the trust table → drop, count marker_spoof; this is the specific defense against a rogue sender setting the indication itself. (iii) Explicit tag-add request from host firmware/driver → rejected as an error condition because only NIC hardware may add the indication. (iv) Stuck marker: if the same idempotency_key is observed with an unchanged frame digest more than 3 times in 100 ms, the frame is dropped and the flow's mark bit is cleared for 1 s (marker_stuck). (v) Marker loss: if a frame returns from the inspection endpoint with the marker missing but the endpoint's completion descriptor claims a verdict, the pipeline re-marks and re-inspects once, then, on second loss, forwards with an unverified_return sideband bit and increments a per-endpoint counter used by the orchestrator to consider endpoint eviction.

Pre-empts: later claims on marker anti-spoofing, marker-version fallback, or detection of lost/stuck markers.

stateDiagram-v2
  [*] --> Parse
  Parse --> Drop: unknown version or untrusted SA
  Parse --> Exempt: explicit host tag request
  Parse --> Inspect: valid marker
  Inspect --> Returned
  Returned --> Forward: marker and verdict consistent
  Returned --> ReInspect: marker missing first time
  ReInspect --> Returned
  ReInspect --> UnverifiedForward: marker missing second time
  Inspect --> StuckDrop: idempotency key repeated
  StuckDrop --> Forward: clear mark bit for 1s

---

PART C — DERIVATIVES OF CLAIM 24

(Independent claim: cause the frame to be provided for additional processing prior to providing the frame to its destination.)

DD-24.1 — Axis 1 (Material/Component Substitution): the processing endpoint is an in-network programmable switch, not the host

Enablement. Substitute a PISA-architecture programmable switch ASIC (e.g., a Tofino-class device with 32 ports × 400 Gb/s, 12-stage ingress/egress pipelines, 20 MB SRAM, 4 MB TCAM) for the host-attached endpoint. The NIC or host-facing leaf switch inserts an NSH (DD-7.1) with SI=255; the fabric switch’s ingress parser matches nsh.action==3 and nsh.spi in a locally-owned range, resubmits to a service pipeline (stage budget 8 stages, 22 stages of budget available), applies a 4-stage regex/Aho-Corasick signature matcher over the first 512 bytes, then mirror-and-drop or forward. Stateless by design: the pipeline stores per-flow state only in 8 register arrays of 65,536 × 32-bit entries indexed by CRC32 of the 5-tuple. Disclosed: 6.4 Tb/s inspection-capable forwarding, per-frame budget 1.2 µs.

Pre-empts: later claims on off-NIC/in-network inspection staging of the frame prior to destination delivery.

graph LR
  A["Frame with NSH SI255"] --> B["Ingress parser"]
  B --> C{"nsh action equals 3"}
  C -->|"yes"| D["Resubmit to service pipeline"]
  D --> E["Aho-Corasick 512B signature match"]
  E -->|"clean"| F["Forward to destination"]
  E -->|"malicious"| G["Mirror to collector and drop"]
  C -->|"no"| F

DD-24.2 — Axis 1 (Material/Component Substitution): peer-to-peer DMA to a GPU/DPU accelerator for deep inspection

Enablement. The additional-processing endpoint is a GPU (or a DPU with a DLA-class tensor engine) reached by PCIe peer-to-peer DMA, bypassing host DRAM. NIC ingress writes candidate frames into a GPU-mapped pinned buffer (2 MB ring, 512 descriptors), rings a doorbell over PCIe, and the GPU kernel performs regex matching via a DFA table in shared memory (or a small transformer encoder with 4 layers, hidden 256, for anomaly scoring at 1.2 M frames/s). The verdict returns over a second doorbell; the NIC then performs destination-keyed steering. Disclosed: 78 % of frames take the P2P path with host CPU utilization below 5 %; a fallback path routes through host DRAM if the GPU is reset, which is essential because a GPU reset otherwise deadlocks the receive ring.

Pre-empts: later claims on accelerator-attached inspection with P2P DMA and destination-keyed re-entry.

sequenceDiagram
  participant NIC
  participant GPU as GPU or DLA
  participant HOST as Host CPU
  NIC->>GPU: P2P DMA of candidate frame
  NIC->>GPU: Doorbell over PCIe
  GPU->>GPU: DFA or small encoder scoring
  GPU->>NIC: Verdict over return doorbell
  alt GPU healthy
    NIC->>NIC: Destination-keyed egress
  else GPU reset
    NIC->>HOST: Fallback through host DRAM ring
  end

DD-24.3 — Axis 1 (Material/Component Substitution): die-to-die partitioned SoC instead of a discrete NIC

Enablement. Decompose the function across UCIe chiplet boundaries: a MAC/PCS chiplet (2× 800G), a programmable-match chiplet (TCAM + P4 pipeline), an inspection-endpoint chiplet (16 Arm A78 cores, 64 MB LLC), and a coherent I/O chiplet. Inter-chiplet traffic uses UCIe 1.1 advanced package with 512 GB/s per direction and a 64-byte flit; each flit carries a 4-bit path_id so the match chiplet can address the endpoint chiplet without host involvement and without exposing the loopback on a PCIe link. Frames crossing a chiplet boundary are protected by a 16-bit CRC plus a sequence number; a CRC failure triggers retry (up to 2) then a chiplet-isolating degrade in which the endpoint is marked out-of-service and all traffic bypasses.

Pre-empts: later claims on chiplet-partitioned NIC inspection fabric.

graph TD
  A["MAC PCS chiplet"] --> B["UCIe flit 64B path_id"]
  B --> C["Programmable match chiplet"]
  C -->|"inspect"| D["Endpoint chiplet 16 cores"]
  C -->|"forward"| E["Coherent IO chiplet"]
  D --> F["Return flit with verdict"]
  F --> E
  B --> G["CRC16 and sequence check"]
  G -->|"failure retry twice"| B
  G -->|"persistent failure"| H["Isolate endpoint, bypass all"]

DD-24.4 — Axis 2 (Operational Parameter Expansion): multi-site, multi-tenant inspection at hyperscale

Enablement. Grow to 100,000 tenants and 6 inspection sites. Per-tenant state is a 64-bit tenant ID resolved from a VXLAN VNI or NSH MD2 context; rules and inspection endpoints are per-tenant namespaces. Frames requiring inspection are hashed by {tenant_id} into a 4,096-entry Anycast group; the pipeline selects the nearest healthy site by a 3-bit health vector plus round-trip-time bucket (RTT measured by a periodic 64-byte probe, bucketed into 8 levels). Cross-site loopbacks carry an NSH with SI=254 and a 32-bit session_token so the returning frame can be re-associated with the originating tenant and destination vector. Tenant isolation is enforced by not allowing a rule in tenant A to match a frame bearing tenant B's ID; a violation sets cross_tenant_attempt and drops. Disclosed target: 99.99 % inspection availability with any 2 sites down.

Pre-empts: later claims on multi-tenant, multi-site inspection routing with session tokens.

graph LR
  A["Frame with tenant ID from VNI or NSH MD2"] --> B["Per-tenant rule namespace"]
  B --> C{"Rule matches within tenant"}
  C -->|"no"| D["cross_tenant_attempt drop"]
  C -->|"yes"| E["Anycast group 4096 hash"]
  E --> F["Select site by health and RTT bucket"]
  F --> G["NSH SI254 plus session token"]
  G --> H["Remote inspection site"]
  H --> I["Return with token to origin tenant"]
  I --> J["Destination keyed egress"]

DD-24.5 — Axis 2 (Operational Parameter Expansion): hard real-time inspection and batteryless energy-harvesting extremes

Enablement. Two ends of the scale. (a) Deterministic 10 µs: a TSN endpoint using 802.1Qbv gates and 802.1Qch cyclic queuing; the inspection endpoint is scheduled in a 10 µs guard window; any frame not returned by the window close is forwarded deterministically (not dropped) and reported via a per-cycle deadline-exceeded counter; the worst-case chain is bounded by pre-computed per-hop budgets (a 6-hop chain with 1.4 µs/hop plus 1.2 µs inspection). (b) Batteryless: a 1 Mb/s energy-harvesting sensor gateway where the inspection endpoint is optional and duty-cycled at 0.1 %; frames are inspected only on a 1-in-1,024 sample, and the sample decision is seeded by the harvested-energy integrator so that inspection happens preferentially when a supercapacitor is above 3.0 V.

Pre-empts: later claims on deadline-bounded inspection windows or energy-state-dependent inspection rates.

graph TD
  A["Frame arrival in TSN cycle"] --> B["802.1Qbv gate opens"]
  B --> C{"Energy integrator above 3.0V?"}
  C -->|"no"| D["Sample 1 in 1024 only"]
  C -->|"yes"| E["Full inspection window 10us"]
  D --> F["Forward deterministically"]
  E -->|"returned in window"| F
  E -->|"deadline exceeded"| G["Forward plus deadline counter"]
  G --> F

DD-24.6 — Axis 3 (Cross-Domain): electronic trading gateway with a 100 ns inspection budget

Enablement. Apply the pre-delivery inspection to a market-data / order-entry path. Frames are FIX over TCP or Nasdaq ITCH over UDP multicast, delivered on 10GBASE-KR to a trading NIC. Because the budget is ~100 ns of added latency, the design inspects only the first 64 bytes and only against a 512-entry exact-match tuple table (no regex, no DFA): any frame whose symbol field, order type, and price band fall outside an allow-list is diverted to a slow-path inspection host before reaching the matching engine. Mechanism: a content-addressable pre-filter in the receive MAC that compares 64 bytes in parallel and asserts divert within 12 ns; the frame is cloned to a slow-path ring only if divert is asserted, so the fast path stays at 100 % line rate and zero added latency for the >99 % of frames that pass. Disclosed: measured determinism σ < 3 ns using a hardware timestamping unit.

Pre-empts: later claims on ultra-low-latency pre-delivery filtering with cloning to a slow path.

graph LR
  A["Market data frame 10GBASE-KR"] --> B["64B parallel content filter 12ns"]
  B --> C{"Symbol type and price band allow"}
  C -->|"pass"| D["Matching engine at line rate"]
  C -->|"divert"| E["Clone to slow path ring"]
  E --> F["Host inspection with 100ns budget"]
  F -->|"cleared"| D
  F -->|"blocked"| G["Quarantine"]
  B --> H["HW timestamp sigma below 3ns"]

DD-24.7 — Axis 3 (Cross-Domain): medical device network and remote-surgery transport

Enablement. A hospital or surgical-robot network where the pre-delivery inspection must never be able to extend an interruptible path. Design: dual-path with a watchdog-and-mirror rather than inline inspection. The live path forwards frames immediately and unconditionally; the inspection endpoint receives a mirror and its verdicts affect only future flows (a verdict of malicious installs a block rule for the flow's next connection, and raises an operator alert), never the current frame. A separate "quarantine on next handshake" mechanism ensures that a detected payload cannot be re-sent byte-identically: the block rule keys on a rolling 64-bit payload fingerprint, not just the 5-tuple, so a replayed payload is dropped while a clinically different payload on the same 5-tuple is allowed. Disclosed: added latency 0 ns; adversarial payload propagation bounded to one frame.

Pre-empts: later claims on zero-added-latency inspection with next-flow enforcement for safety-critical transports.

sequenceDiagram
  participant DEV as Device
  participant NIC as Safety NIC
  participant IDS as Inspection Endpoint
  participant PEER as Clinical Peer
  DEV->>NIC: frame
  NIC->>PEER: immediate mirror-free forward
  NIC->>IDS: asynchronous mirror copy
  IDS->>NIC: verdict and payload fingerprint
  alt verdict malicious
    NIC->>NIC: install next-flow block rule
    NIC->>IDS: raise operator alert
  else verdict clean
    NIC->>NIC: refresh allow entry
  end

DD-24.8 — Axis 3 (Cross-Domain): autonomous-vehicle zonal gateway with hypervisor-resident inspection

Enablement. A zonal gateway with 8× 1000BASE-T1 links and a 16 Gb/s switching fabric, running a Type-1 hypervisor: one safety VM owns the CAN/Ethernet translation, one inspection VM owns the IDS. Reception on any port triggers a sensor-fusion-aware verdict: frames carrying perception traffic (lidar/radar point clouds over Ethernet, 20 Mb/s per sensor) bypass inspection unless they violate a rate or size envelope, because latency is safety-critical; frames carrying diagnostics, OTA, or consumer-app traffic always take the pre-delivery loopback. Loopback path shares no core with the safety VM (core isolation, cache coloring, dedicated SRAM), so an inspection VM fault cannot delay a braking command. Disclosed worst-case inspection VM restart at 40 ms with the safety VM unaffected.

Pre-empts: later claims on automotive zonal inspection with class-of-traffic differentiated pre-delivery routing.

graph TD
  A["Zonal gateway port"] --> B["Traffic class classifier"]
  B -->|"perception"| C{"Rate and size envelope ok"}
  C -->|"ok"| D["Bypass to safety VM"]
  C -->|"violation"| E["Pre-delivery loopback"]
  B -->|"diagnostics OTA app"| E
  E --> F["Inspection VM on isolated cores"]
  F --> G["Return and destination steering"]
  D --> G

DD-24.9 — Axis 4 (Emerging Tech): federated rule learning, encrypted-traffic inspection, and confidential-computing attestation

Enablement. Three integrations that compose: (a) Federated learning: each NIC accumulates a 16-feature sketch of flows with local labels; only gradient deltas (int8, 12 KB) leave the node, aggregated by a parameter server with secure aggregation (pairwise masking), so the raw traffic never leaves the fleet. (b) Encrypted-traffic inspection: where TLS 1.3 is used, the inspection endpoint receives only the observable side channel (record sizes, inter-record timing, ALPN, certificate transparency metadata) and a statistical classifier trained on those features; the pre-delivery loopback is gated on a per-connection entropy score rather than payload content. Where keys are available (enterprise TLS-inspection proxy or TLS 1.3 with an internal CA), the endpoint uses a shared-key session cache so inspection needs no re-handshake. (c) Attestation: the inspection endpoint runs in an AMD SEV-SNP or Intel TDX confidential VM; the NIC will not route frames to it unless a remote attestation report (measurement + TCB version) validates against a policy, so a compromised hypervisor cannot silently substitute a permissive endpoint. Disclosed: attestation refresh every 600 s; failure to attest falls back to the fail-open or fail-closed personality of DD-1.10 per operator policy.

Pre-empts: later claims combining NIC inspection routing with federated learning, encrypted-traffic classification, or confidential-computing attestation gating.

graph LR
  A["Flow on the node"] --> B["16-feature sketch and local label"]
  B --> C["Gradient delta int8 12KB"]
  C --> D["Parameter server secure aggregation"]
  D --> E["Global model back to NIC"]
  A --> F{"Keys available for this flow"}
  F -->|"yes"| G["Payload inspection endpoint"]
  F -->|"no"| H["Side channel classifier"]
  G --> I["SEV-SNP or TDX attestation check"]
  H --> I
  I -->|"attested"| J["Route to endpoint"]
  I -->|"not attested"| K["Fallback personality"]
  J --> L["Return and destination steering"]
  K --> L

DD-24.10 — Axis 5 (Inverse / Failure Mode): control-plane partition, replay, and tamper-evident degradation

Enablement. Define behavior when the orchestration plane is unavailable. (i) Control-plane partition: the NIC keeps the last-known-good rule set and a 24 h grace timer; after grace expiry it applies a conservative rule set (loopback all inter-tenant traffic, bypass intra-tenant) rather than the last-known-good set, on the theory that an unbounded stale policy is worse than a coarse policy. (ii) Endpoint partition: if the inspection endpoint's heartbeat is lost, an optional remote endpoint is used (DD-24.4 anycast) only if its attested RTT bucket is within one level of the local endpoint; otherwise the fallback personality of DD-1.10 applies. (iii) Replay of uninspected frames: frames bypassed during an outage are dumped to a replay ring (64 MB) with their ingress hardware timestamps; on recovery the endpoint replays them in timestamp order against the current rule set, and any rule hit produces a retroactive alert tagged historical rather than a forwarding decision, so recovery never re-injects stale traffic. (iv) Tamper-evidence: each state transition (fail-open, fail-closed, bypass, quarantine) is written to an append-only log whose entries chain by hash, so an operator cannot later conceal that inspection was off.

Pre-empts: later claims on grace-timer policy degradation, replay rings with historical alerting, or hash-chained inspection availability logs.

stateDiagram-v2
  [*] --> Normal
  Normal --> GraceTimer: control plane lost
  GraceTimer --> Conservative: 24h elapsed
  GraceTimer --> Normal: control plane restored
  Normal --> RemoteEndpoint: local endpoint heartbeat lost
  RemoteEndpoint --> Fallback: RTT bucket too high
  Normal --> BypassRing: outage bypass
  BypassRing --> Replay: endpoint recovered
  Replay --> Normal: historical alerts emitted
  Fallback --> Normal: endpoint attested again
  Conservative --> Normal: policy refresh received

---

PART D — COMBINATION PRIOR-ART SCENARIOS

(Each scenario is a concrete, implementable combination of the ‘627 subject matter with an existing open-source standard or project. Each is publishable as a stand-alone prior-art disclosure.)

CP-1 — Open vSwitch + DPDK + OpenFlow/OVSDB representor ports

A hypervisor runs Open vSwitch with the DPDK datapath (netdev datapath type). Each VM vNIC is bound to a representor port on the NIC; OVS learns MACs and installs flows in the DPDK rte_flow table. A dedicated IDS VM is a normal OVS port. The combination: the NIC is configured (via rte_flow actions with RTE_FLOW_ACTION_TYPE_MIRROR plus a MARK) such that frames matching an "uninspected" mark are mirrored to the IDS representor and held by the OVS conntrack state machine until the IDS returns them marked "inspected," at which point the flow is re-injected and forwarded by normal L2/L3 lookup. Naturally occurring enabling details: the mark occupies the RTE_MBUF_F_RX_FDIR/rte_flow mark field; a RTE_FLOW_ACTION_TYPE_JUMP to a dedicated group implements the "return to destination" step; OVS ct_state=+trk-new distinguishes first-pass from returned frames.
Value as prior art: establishes that hardware marking plus mirror-to-IDS-plus-reinject was an ordinary configuration of an existing open-source switch by 2010–2014, with all four steps of the loop present.

graph LR
  A["VM vNIC representor"] --> B["OVS DPDK datapath"]
  B --> C["rte_flow mark uninspected"]
  C --> D["Mirror to IDS port"]
  D --> E["IDS returns with inspected mark"]
  E --> F["OVS conntrack ct_state plus trk"]
  F --> G["L2 L3 lookup and reinject"]
  G --> H["Destination VM"]

CP-2 — eBPF/XDP + Cilium + Geneve overlay on Kubernetes

A CNI (Cilium) attaches XDP and tc eBPF programs to each veth and to the NIC's physical port. Inter-node traffic is Geneve-encapsulated with the pod identity in the tunnel metadata. The combination: a tc BPF program sets a per-packet skb->mark derived from the Cilium identity and writes a Geneve TLV (DD-7.2) when a policy of type toEntities: inspection matches; the physical-port XDP program redirects marked packets to an IDS pod's AF_XDP socket via bpf_redirect_map(); the IDS returns them through a second AF_XDP socket; the tc program then performs the destination lookup in the Cilium ipcache/lxc map and forwards. Enabling details: AF_XDP zero-copy UMEM rings, BPF_MAP_TYPE_LPM_TRIE for policy, bpf_skb_pull_data for the encapsulation headers, XDP_REDIRECT flags.
Value as prior art: ties the inspection gate to a policy-layer identity (Cilium identity / Kubernetes NetworkPolicy) and to a standard overlay marker, all implemented with publicly documented primitives.

graph TD
  A["Pod veth"] --> B["tc eBPF identity mark"]
  B --> C{"Policy toEntities inspection"}
  C -->|"yes"| D["Geneve TLV marker"]
  C -->|"no"| E["Direct forward"]
  D --> F["XDP bpf_redirect_map to AF_XDP"]
  F --> G["IDS pod"]
  G --> H["Return AF_XDP socket"]
  H --> I["Cilium ipcache destination lookup"]
  I --> J["Egress"]
  E --> J

CP-3 — P4 / P4Runtime / PSA with NSH service chaining on a programmable switch

A P4-16 program for a PSA target implements the pipeline. Its ingress parser recognizes Ethernet + VLAN + NSH; a ServiceHeader header type carries spi, si, action. The Ingress control block has a service_chain table keyed on {nsh.spi, nsh.action} that resubmits into a signature_match control block using a Register array indexed by hash(frame.five_tuple) and a Hash extern for flow hashing; egress writes nsh.si - 1 and, for a clean verdict, deparser emits without NSH. The controller installs nsh.action=3 per flow via P4Runtime WriteRequest with a TableEntry including a priority and a DirectCounter. Enabling details: @name annotations for control-plane-visible tables, Register for the token-bucket state, Digest extern to report drops to the controller.
Value as prior art: establishes that an NSH-action-keyed, controller-programmable inspection chain with flow hashing and counters is an obvious P4 application, not a novel architecture.

graph LR
  A["Ethernet VLAN NSH parser"] --> B["service_chain table keyed spi action"]
  B -->|"action 3"| C["resubmit signature_match"]
  C --> D["Register hash five tuple"]
  D --> E{"Signature and budget hit"}
  E -->|"clean"| F["Egress deparser without NSH"]
  E -->|"malicious"| G["Digest to controller and drop"]
  B -->|"action 1"| F

CP-4 — SR-IOV + virtio-net/vDPA + vhost-user with a bridge-based inspection port

A host exposes 64 VFs; a Type-1 hypervisor binds the IDS VM to a dedicated VF. The hypervisor's bridge (or OVS-DPDK with a vhost-user port) mirrors first-pass frames of flows whose source VF is not marked trusted to the IDS VF. The VF's mailbox (VIRTIO_NET_CTRL_MQ/VIRTIO_NET_CTRL_RX mode) is used by the guest driver to declare readiness for the inspection queue. The combination is notable because the mechanism that "makes the NIC aware of the original source" is the VF/queue index on which the frame returns — precisely the specification's disguised-source-identity variation — and it is a plain consequence of the SR-IOV VF-to-queue binding.
Enabling details: VFLR handling, PF mailbox VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET, per-VF MAC/VLAN anti-spoof filters, bonding for the return path.
Value as prior art: forecloses later claims that tie "the NIC knows the original sender" to queue-based identity when using SR-IOV.

sequenceDiagram
  participant VM as Source VM on VF1
  participant PF as NIC PF Bridge
  participant IDS as IDS VM on VF9
  VM->>PF: Frame from VF1 untrusted
  PF->>PF: Mirror decision by VF index
  PF->>IDS: Deliver on VF9 with queue index
  IDS->>PF: Return frame on VF9 queue N
  PF->>PF: Map queue N to original VF1 identity
  PF->>PF: Destination lookup by DA
  PF->>VM: Forward to destination VF

CP-5 — Snort/Suricata rule sets as the host-configurable filter rules

The NIC's drop/accept table is compiled from a Suricata ruleset (Emerging Threats Open or an equivalent public ruleset). Because Suricata rules are action proto src_ip sport -> dst_ip dport (options) with a sid, the compiler maps any rule whose action is drop and whose header is a pure 5-tuple predicate to a hardware CAM entry, leaves rules with content, pcre, flow, or threshold options to the host IDS, and records the mapping in a shadow file so that the host IDS can re-emit (hot-reload) the hardware subset with suricatasc reload-rules. This concretely realizes claims 5/22/28 (NIC-side drop) with claims 6/23/29 (rules configurable by the host-based inspection), using a public rule language.
Value as prior art: forecloses later claims that make rule-language compilation or rule-subset partitioning the point of novelty.

graph TD
  A["Public ruleset file"] --> B["Rule compiler"]
  B --> C{"Pure 5-tuple drop rule"}
  C -->|"yes"| D["Compile to CAM entry with sid"]
  C -->|"no"| E["Keep in host IDS rule set"]
  D --> F["NIC drop table"]
  E --> G["Host IDS deep inspection"]
  G --> H["Hot reload request"]
  H --> B
  F --> I["Shadow mapping file with sid"]

CP-6 — Kubernetes NetworkPolicy + SPIFFE/SPIRE workload identity + gNMI telemetry

Workload identity from SPIFFE (SVID in a Unix socket) is bound to a pod's network identity by the CNI, and a Kubernetes NetworkPolicy expresses which flows must be inspected. The NIC resolves the destination identity from an SPIFFE-aware map (vni → trust domain + path) rather than from an IP, and a gNMI/OpenConfig stream exports per-identity inspection counters (inspect-required, inspect-timeout, verdict-malicious) to the fleet controller, which can widen policy automatically when the timeout ratio exceeds 0.1 %. Enabling details: StreamSubscribe with on_change for the counters, SetRequest with replace for the NIC's compiled policy, origin openconfig-network-instance.
Value as prior art: forecloses later claims that couple workload identity, policy language, and telemetry-driven policy adaptation to the inspection loopback.

graph LR
  A["SPIFFE SVID per pod"] --> B["CNI binds identity to vni"]
  B --> C["NetworkPolicy to inspect mapping"]
  C --> D["NIC identity aware steering"]
  D --> E{"Identity requires inspection"}
  E -->|"yes"| F["Loop to inspection endpoint"]
  E -->|"no"| G["Forward by identity"]
  F --> H["gnmi counters per identity"]
  H --> I{"Timeout ratio above 0.1pct"}
  I -->|"yes"| J["SetRequest widens policy"]
  J --> C

---

PART E — NOVELTY-DEFEAT INDEX

---

PART F — PUBLICATION AND TIMESTAMPING PROTOCOL

To function as prior art under AIA § 102(a)(1)/(a)(2), this document must be publicly accessible and dated. Recommended, in order of strength: (1) deposit with a defensive-publication service that issues a permanent identifier and a public-accessible date (IP.com Prior Art Database or equivalent), capturing the full text including the Mermaid sources; (2) simultaneous deposit of the machine-readable Mermaid sources in a public Git repository with signed commits and a release tag; (3) archival deposit with a DOI on a preprint server that accepts technical disclosures, so the publication date is independently citable; (4) an OpenTimestamps or RFC 3161 timestamp over the SHA-256 of the concatenated artifact set. The disclosure date of record for this document is 2026-04-26.

Confidence statements. High confidence: the identity of US 8,621,627, its claims, its continuation US 8,856,947 B1, the Speednic LLC assignment recorded 2026-02-13, and the citation of US 8,621,627 as a “Y” reference in the EP3476101A4 file. Moderate confidence: the exact specification-completeness of every cited standard’s field layout as summarized in DD-7.1, DD-7.4, DD-7.6, and DD-7.9 — designers must confirm the current revision of RFC 8300, RFC 8926, 3GPP TS 29.281, IEEE 1722, and FIPS 204 before implementing, because field widths and extension-header type codes have been amended since first publication. Uncertain and flagged as such: whether foreign family members exist under INPADOC family 49776265, and the exact § 154(b) patent-term-adjustment day count on the printed front page of US 8,621,627.