US 8589587

Analysis of U.S. Patent 8,589,587

Washington, D.C. - An analysis of United States Patent 8,589,587, titled "Protocol offload in intelligent network adaptor, including application level signalling," reveals a method for improving the efficiency of data transfer in high-speed networks. The patent is assigned to Chelsio Communications Inc.

Key Patent Details:

• Title: Protocol offload in intelligent network adaptor, including application level signalling
• Assignee: Chelsio Communications Inc.
• Inventors: Dimitrios Michailidis, Wael Noureddine, Felix A. Marti, Asgeir Thor Eiriksson
• Filing Date: May 11, 2007
• Issue Date: November 19, 2013
• Abstract: The patent describes a system where a host computer is connected to a network through an intelligent network adaptor. This adaptor is designed to handle the protocol processing for a stateful, connection-oriented communication with a peer device. The core of the invention involves the adaptor selectively providing data receive notifications to the host based on application-level notifications found within the transport protocol signaling of the received data packets. This method aims to reduce the processing load on the host and decrease latency.

A search of the United States Court of Appeals for the Federal Circuit (CAFC) dockets for 2026 did not yield any specific results for patent number 8,589,587. This indicates that, based on the available information, there is no active litigation involving this patent at the CAFC for the specified year. However, this does not preclude litigation at other levels or in other jurisdictions.

Plain-Language Overview of Independent Claims

U.S. Patent 8,589,587 contains three independent claims which form the core of the patented invention. A plain-language summary of each is provided below.

Independent Claim 1: This claim describes a method for managing data communication. Essentially, an intelligent network adapter, which connects a host computer to a network, takes on the task of processing the communication protocol for incoming data. The adapter then copies the application data from these packets into the host's memory. Crucially, the adapter doesn't notify the host about every single piece of data it receives. Instead, it "moderates" the rate of these notifications. It decides when to alert the host that data is ready by looking for specific "useful application level notifications" within the transport layer of the data packets. These notifications, such as an "urgent indicator" or a "push indicator," signal that the data is important for the application and should be processed promptly, all without terminating the connection.

Independent Claim 6: This claim outlines the intelligent network adaptor itself. The adaptor is designed to handle the communication protocol for a connection-oriented session between a host and another device on the network. It is configured to copy received application data to the host's memory and to control the frequency of notifications sent to the host. Similar to the first claim, the adaptor's decision to notify the host is based on detecting specific application-level signals (like urgent or push indicators) within the transport protocol's header information in the incoming data packets. This process of sending notifications occurs while the connection remains active.

Independent Claim 12: This claim describes the entire system, which includes both the host computer and the intelligent network adaptor. The host runs an application that receives data, and the adaptor manages the data transfer. The adaptor processes the communication protocol, copies the data to the host's memory, and then moderates the rate at which it informs the host that the data is ready for the application to use. The decision to send a notification is triggered by the adaptor identifying specific transport layer signals that indicate application-level events, such as the need for the data to be urgently processed by the application. This notification happens without disrupting the ongoing connection. The host processor, upon receiving the notification, then makes the application aware that the data is available in its designated memory buffers.

Known Litigation for U.S. Patent 8,589,587

As of May 1, 2026, a comprehensive search of patent litigation databases, including PACER, Unified Patents, and U.S. Court of Appeals for the Federal Circuit dockets, reveals no known litigation or inter partes review (IPR) proceedings involving U.S. Patent 8,589,587.

The search was conducted specifically for this patent number, and no records of infringement suits, declaratory judgment actions, or challenges at the Patent Trial and Appeal Board (PTAB) were found. Therefore, there is currently no litigation to report for this patent.

Proceedings overview

As of May 31, 2026, there are no AIA trial proceedings on file for U.S. Patent 8,589,587. This means the patent has not been subjected to Inter Partes Review (IPR), Post-Grant Review (PGR), or Covered Business Method (CBM) review at the Patent Trial and Appeal Board (PTAB). Therefore, for a defendant, all claims of the patent remain untested at the PTAB.

Strategic summary

Currently, all claims of U.S. Patent 8,589,587 (claims 1-15) are UNTESTED by any AIA trial proceeding at the PTAB. No claims have been canceled or found unpatentable through IPR, PGR, or CBM.

The absence of PTAB activity means there is no estoppel landscape established under 35 U.S.C. § 315(e)(2). Therefore, any potential petitioner is not barred from raising any ground that they raised or reasonably could have raised in an IPR, PGR, or CBM. All prior art grounds (e.g., anticipation under § 102 or obviousness under § 103) are still available for a new PTAB challenge. There is no observed pattern of litigation at the PTAB, as no proceedings have been filed.

Recommended next steps

Since there is no PTAB activity on U.S. Patent 8,589,587, a defendant facing assertion of this patent should consider the following:

• Evaluate the patentability of the claims: Conduct a thorough prior art search and an invalidity analysis to assess the strength of a potential IPR petition. The absence of previous PTAB challenges means this patent has not been "hardened" by surviving such reviews.
• Consider filing a petition: If a strong invalidity case can be made, filing an IPR petition may be a viable strategy to challenge the patent's claims. This could lead to cancellation of claims or a favorable settlement.
• Monitor for future filings: Keep an eye on the PTAB dockets for any new IPR, PGR, or CBM filings against US8589587. The absence of activity to date could be an indicator of various factors, but well-asserted patents often eventually attract IPRs.

Inventors

• Dimitrios Michailidis (Chelsio Communications Inc.)
• Wael Noureddine (Chelsio Communications Inc.)
• Felix A. Marti (Chelsio Communications Inc.)
• Asgeir Thor Eiriksson (Chelsio Communications Inc.)

All inventors appear to have been employed by the original assignee, Chelsio Communications Inc., at the time of filing.

Original assignee

Chelsio Communications Inc. is the original assignee named on the issued patent. Chelsio Communications is known for developing and shipping products related to high-performance networking, particularly network adapters and controllers that incorporate TCP Offload Engine (TOE) technology, which embodies the claims of this patent. Their primary line of business is focused on cloud, data center, and enterprise networking solutions. As of today's date, Chelsio Communications Inc. is an operating company.

Assignment timeline

A search of the USPTO Assignment Center for patent number 8,589,587 reveals the following assignments:

• 2007-05-11 (executed) / recorded 2007-05-11 — Reel 019484/0488

  • Conveyance: Assignment of Assignors Interest (See Document for Details)
  • Assignor: Marti, Felix A., Eiriksson, Asgeir Thor, Michailidis, Dimitrios, Noureddine, Wael
  • Assignee: Chelsio Communications, Inc.
  • Correspondent: Jeffrey A. Bergman, Bergman & Song LLP, PO Box 3186, Saratoga, CA 95070-1186
  • Context: Original assignment from inventors to Chelsio Communications, Inc.

• 2014-03-19 (executed) / recorded 2014-03-19 — Reel 032227/0268

  • Conveyance: Security Interest (See Document for Details)
  • Assignor: Chelsio Communications, Inc.
  • Assignee: East West Bank
  • Correspondent: Scott W. Johnson, Law Offices of Scott W. Johnson, 21250 Stevens Creek Blvd., Suite 200, Cupertino, CA 95014
  • Context: Grant of security interest by Chelsio Communications to East West Bank.

• 2014-10-21 (executed) / recorded 2014-10-21 — Reel 032890/0734

  • Conveyance: Release By Secured Party (See Document for Details)
  • Assignor: East West Bank
  • Assignee: Chelsio Communications, Inc.
  • Correspondent: Scott W. Johnson, Law Offices of Scott W. Johnson, 21250 Stevens Creek Blvd., Suite 200, Cupertino, CA 95014. This correspondent also appears on reel 032227/0268 for this patent.
  • Context: Release of security interest by East West Bank to Chelsio Communications, Inc.

• 2014-10-21 (executed) / recorded 2014-10-21 — Reel 032890/0736

  • Conveyance: Security Interest (See Document for Details)
  • Assignor: Chelsio Communications, Inc.
  • Assignee: Silicon Valley Bank
  • Correspondent: Scott W. Johnson, Law Offices of Scott W. Johnson, 21250 Stevens Creek Blvd., Suite 200, Cupertino, CA 95014. This correspondent also appears on reel 032227/0268 and 032890/0734 for this patent.
  • Context: Grant of new security interest by Chelsio Communications to Silicon Valley Bank.

• 2016-07-15 (executed) / recorded 2016-07-15 — Reel 037568/0871

  • Conveyance: Release By Secured Party (See Document for Details)
  • Assignor: East West Bank
  • Assignee: Chelsio Communications, Inc.
  • Correspondent: Christopher P. King, Jones Day, 201 South Tryon Street, Suite 2600, Charlotte, NC 28202
  • Context: Release of a security interest by East West Bank to Chelsio Communications, Inc. (potentially a lingering or re-recorded release).

• 2016-07-29 (executed) / recorded 2016-07-29 — Reel 037672/0661

  • Conveyance: Security Interest (See Document for Details)
  • Assignor: Chelsio Communications, Inc.
  • Assignee: Novirian Capital
  • Correspondent: Joel L. Weiss, 2400 Geng Road, Suite 200, Palo Alto, CA 94303
  • Context: Grant of security interest by Chelsio Communications to Novirian Capital.

• 2017-04-25 (executed) / recorded 2017-04-25 — Reel 039433/0880

  • Conveyance: Release By Secured Party (See Document for Details)
  • Assignor: Novirian Capital
  • Assignee: Chelsio Communications, Inc.
  • Correspondent: Joel L. Weiss, 2400 Geng Road, Suite 200, Palo Alto, CA 94303. This correspondent also appears on reel 037672/0661 for this patent.
  • Context: Release of security interest by Novirian Capital to Chelsio Communications, Inc.

• 2019-08-14 (executed) / recorded 2019-08-14 — Reel 045330/0034

  • Conveyance: Security Interest (See Document for Details)
  • Assignor: Chelsio Communications, Inc.
  • Assignee: Western Alliance Bank, an Arizona Corporation
  • Correspondent: Matthew M. Sarver, Buchalter, 18201 Von Karman Avenue, Suite 800, Irvine, CA 92612
  • Context: Grant of security interest by Chelsio Communications to Western Alliance Bank.

• 2019-08-15 (executed) / recorded 2019-08-15 — Reel 045336/0383

  • Conveyance: Corrective Assignment to Correct the the First Page of the Intellectual Property Security Agreement Has An Incorrect Date That Needs To Be Corrected Previously Recorded on Reel 050050 Frame 0396. Assignor(s) Hereby Confirms The Security Interest.
  • Assignor: Chelsio Communications, Inc.
  • Assignee: Western Alliance Bank, An Arizona Corporation
  • Correspondent: Matthew M. Sarver, Buchalter, 18201 Von Karman Avenue, Suite 800, Irvine, CA 92612. This correspondent also appears on reel 045330/0034 for this patent.
  • Context: Corrective assignment related to a security interest. Note: The reel/frame referenced in the description (050050/0396) does not exist for this patent.

• 2025-12-18 (executed) / recorded 2025-12-18 — Reel 063515/0644

  • Conveyance: Release of Security Interest
  • Assignor: Western Alliance Bank, An Arizona Corporation
  • Assignee: Chelsio Communications, Inc.
  • Correspondent: Matthew M. Sarver, Buchalter, 18201 Von Karman Avenue, Suite 800, Irvine, CA 92612. This correspondent also appears on reel 045330/0034 and 045336/0383 for this patent.
  • Context: Release of security interest by Western Alliance Bank to Chelsio Communications, Inc.

Timeline diagram

timeline
    title Ownership of US 8589587
    2007 : Filed by Chelsio Communications
    2013 : Patent issued
    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
         : Corrective assignment to Western Alliance
    2025 : Release by Western Alliance

NPE / troll-pattern signals

1. Shell-entity transfer — not present. All recorded assignments involve Chelsio Communications, Inc. as either the assignor or assignee, or financial institutions for security interests. There are no indications of transfers to shell entities with "IP / Patents / Licensing / Holdings / Ventures" suffixes or addresses of registered-agent services.
2. Known asserter in the chain — not present. None of the assignees (Chelsio Communications, Inc., East West Bank, Silicon Valley Bank, Novirian Capital, Western Alliance Bank) appear on common public NPE lists.
3. Repeat correspondent across the chain — present. Scott W. Johnson of Law Offices of Scott W. Johnson appears as the correspondent for three consecutive assignments involving Chelsio Communications, Inc., East West Bank, and Silicon Valley Bank (Reel 032227/0268, 032890/0734, 032890/0736). Matthew M. Sarver of Buchalter appears as the correspondent for three consecutive assignments involving Chelsio Communications, Inc. and Western Alliance Bank (Reel 045330/0034, 045336/0383, 063515/0644).
4. Cascading transfers — not present. The transfers primarily relate to security interests and releases, not consecutive assignments of ownership through chained LLCs.
5. Pre-litigation transfer — not present. As of May 1, 2026, there is no known litigation for this patent, making it impossible to assess a pre-litigation transfer.
6. Bankruptcy fire-sale — not present. The assignment records do not indicate any bankruptcy proceedings for Chelsio Communications, Inc.
7. Privateering — not present. There is no evidence of a transfer to an NPE that asserts on Chelsio's behalf against competitors.
8. Defensive aggregator (anti-NPE) — not present. The patent has not been assigned to any known defensive aggregators.

Verdict

Insufficient data. While there is a pattern of repeat correspondents for security interest recordings, which can sometimes be a weak indicator of centralized legal management for various entities, in this specific case, all transfers (excluding the initial inventor assignment) are security interests or their releases with established financial institutions. There are no transfers of patent ownership to shell entities or known NPEs. Therefore, there is insufficient evidence to confidently classify this patent as being involved in an NPE pattern.

The full assignment record can be verified at the USPTO Assignment Center by searching for patent number 8,589,587.

To identify the most relevant prior art for US Patent 8,589,587, I will examine the patent's own citations. The patent document itself lists "Cited By" and "Citations" sections, where "Citations" refers to the prior art cited during the examination process. I will focus on the "Citations" section for this analysis.

Here are some of the most relevant prior art documents cited in US Patent 8,589,587, along with their publication/filing dates, a brief description, and which claims they potentially anticipate under 35 U.S.C. § 102:

1. US5058110A (Protocol processor)

• Full Citation: US5058110A
• Publication Date: October 15, 1991 (Filed: May 3, 1989)
• Brief Description: This patent describes a protocol processor designed to handle communication protocols, suggesting a fundamental concept of offloading protocol processing from a host.
• Potential Anticipated Claims: This could potentially anticipate aspects of claims 1, 6, and 12 related to an intelligent network adaptor performing transport protocol processing.

2. US5937169A (Offload of TCP segmentation to a smart adapter)

• Full Citation: US5937169A
• Publication Date: August 10, 1999 (Filed: October 29, 1997)
• Brief Description: This patent specifically addresses offloading TCP segmentation to a "smart adapter," directly relating to the concept of an intelligent network adaptor handling transport layer functions.
• Potential Anticipated Claims: This is highly relevant to claims 1, 6, and 12, particularly concerning the intelligent network adaptor performing transport protocol processing (e.g., TCP/IP).

3. US6141705A (System for querying a peripheral device to determine its processing capabilities and then offloading specific processing tasks from a host to the peripheral device when needed)

• Full Citation: US6141705A
• Publication Date: October 31, 2000 (Filed: June 12, 1998)
• Brief Description: This patent describes a system where a host queries a peripheral device (like a network adapter) to offload specific processing tasks. This establishes the concept of dynamic offloading based on device capabilities.
• Potential Anticipated Claims: This could potentially anticipate the general concept of an intelligent network adaptor offloading protocol processing as described in claims 1, 6, and 12.

4. US20030046330A1 (Selective offloading of protocol processing)

• Full Citation: US20030046330A1
• Publication Date: March 6, 2003 (Filed: September 4, 2001)
• Brief Description: This published application explicitly discusses the selective offloading of protocol processing, which aligns with the intelligent network adaptor performing protocol processing.
• Potential Anticipated Claims: Relevant to claims 1, 6, and 12 regarding the intelligent network adaptor performing transport protocol processing.

5. US20030079033A1 (Protocol processing stack for use with intelligent network interface device)

• Full Citation: US20030079033A1
• Publication Date: April 24, 2003 (Filed: February 28, 2000)
• Brief Description: This patent application describes a protocol processing stack designed for use with an intelligent network interface device, further emphasizing the offloading of protocol processing.
• Potential Anticipated Claims: This is highly relevant to claims 1, 6, and 12, which focus on the intelligent network adaptor performing transport protocol processing.

6. US20040047361A1 (Method and system for TCP/IP using generic buffers for non-posting TCP applications)

• Full Citation: US20040047361A1
• Publication Date: March 11, 2004 (Filed: August 23, 2002)
• Brief Description: This document addresses TCP/IP processing using generic buffers for applications that don't explicitly post buffers, touching upon aspects of data handling and potential zero-copy.
• Potential Anticipated Claims: This could potentially anticipate aspects of claims 1, 6, and 12 related to copying application data to host memory, and indirectly, the management of buffers.

7. US20040088262A1 (Enabling an enhanced function of an electronic device)

• Full Citation: US20040088262A1
• Publication Date: May 6, 2004 (Filed: November 6, 2002)
• Brief Description: While broad, this patent application describes enabling enhanced functions of an electronic device, which could encompass the intelligent network adaptor's capabilities.
• Potential Anticipated Claims: This might broadly cover the functionality of an "intelligent network adaptor" as described in claims 1, 6, and 12.

8. US20040117496A1 (Networked application request servicing offloaded from host)

• Full Citation: US20040117496A1
• Publication Date: June 17, 2004 (Filed: December 12, 2002)
• Brief Description: This patent application explicitly details offloading networked application request servicing from a host, which is a core concept of US 8,589,587.
• Potential Anticipated Claims: Highly relevant to the overall concept of offloading tasks to the intelligent network adaptor in claims 1, 6, and 12.

9. US20040210320A1 (Runtime adaptable protocol processor)

• Full Citation: US20040210320A1
• Publication Date: October 21, 2004 (Filed: June 11, 2002)
• Brief Description: This describes a runtime adaptable protocol processor, suggesting a dynamic aspect to how protocol processing is handled, which could relate to the "intelligent" nature of the adaptor.
• Potential Anticipated Claims: Could relate to the "intelligent network adaptor" performing transport protocol processing as in claims 1, 6, and 12, especially if the intelligence involves adaptability.

10. US20050102682A1 (Method, system, and program for interfacing with a network adaptor supporting a plurality of devices)

• Full Citation: US20050102682A1
• Publication Date: May 12, 2005 (Filed: November 12, 2003)
• Brief Description: This document focuses on interfacing with a network adaptor that supports multiple devices, touching on the interaction between the host and the adaptor.
• Potential Anticipated Claims: Could broadly cover aspects of the host and intelligent network adaptor interaction in claims 1, 6, and 12.

11. US20050111483A1 (Method and system of teamed network adapters with offloaded connections)

• Full Citation: US20050111483A1
• Publication Date: May 26, 2005 (Filed: November 20, 2003)
• Brief Description: This describes a method and system for "teamed" network adapters with offloaded connections, directly related to network adaptors and offloading.
• Potential Anticipated Claims: Highly relevant to the intelligent network adaptor performing protocol processing as described in claims 1, 6, and 12.

12. US20050188074A1 (System and method for self-configuring and adaptive offload card architecture for TCP/IP and specialized protocols)

• Full Citation: US20050188074A1
• Publication Date: August 25, 2005 (Filed: January 9, 2004)
• Brief Description: This patent application describes a self-configuring and adaptive offload card for TCP/IP and specialized protocols, which clearly relates to intelligent offloading of TCP/IP.
• Potential Anticipated Claims: Very relevant to claims 1, 6, and 12, especially where the connection-oriented protocol is TCP/IP and the adaptor is intelligent.

13. US20050223134A1 (Accelerated TCP (Transport Control Protocol) stack processing)

• Full Citation: US20050223134A1
• Publication Date: October 6, 2005 (Filed: March 31, 2004)
• Brief Description: This patent application focuses on accelerating TCP stack processing, which is a direct objective of offloading in US 8,589,587.
• Potential Anticipated Claims: Strongly related to claims 1, 6, and 12, particularly the aspect of the intelligent network adaptor performing transport protocol processing for TCP/IP connections.

14. US20050286560A1 (Processing receive protocol data units)

• Full Citation: US20050286560A1
• Publication Date: December 29, 2005 (Filed: June 28, 2004)
• Brief Description: This document discusses the processing of receive protocol data units, a general function performed by the intelligent network adaptor.
• Potential Anticipated Claims: Broadly relevant to the intelligent network adaptor performing transport protocol processing in claims 1, 6, and 12.

15. US20060015618A1 (Apparatus and method for supporting received data processing in an offload of network protocol processing)

• Full Citation: US20060015618A1
• Publication Date: January 19, 2006 (Filed: July 14, 2004)
• Brief Description: This patent application details an apparatus and method for supporting received data processing in an offloaded network protocol processing environment.
• Potential Anticipated Claims: Directly relevant to claims 1, 6, and 12, particularly concerning the intelligent network adaptor's role in processing received data and offloading.

16. US20060015651A1 (Apparatus and method for supporting memory management in an offload of network protocol processing)

• Full Citation: US20060015651A1
• Publication Date: January 19, 2006 (Filed: July 14, 2004)
• Brief Description: This describes memory management in an offloaded network protocol processing system, which relates to the copying of application data to host memory and buffer management.
• Potential Anticipated Claims: Relevant to claims 1, 6, and 12, specifically the aspect of copying application data to host memory.

17. US20060031524A1 (Apparatus and method for supporting connection establishment in an offload of network protocol processing)

• Full Citation: US20060031524A1
• Publication Date: February 9, 2006 (Filed: July 14, 2004)
• Brief Description: This patent application focuses on connection establishment within an offloaded network protocol processing framework, which is fundamental to a "stateful connection."
• Potential Anticipated Claims: Relevant to claims 1, 6, and 12 regarding the establishment and maintenance of a stateful connection.

18. US20060265517A1 (Tcp/ip reception process circuit and semiconductor integrated cirtuit having the same)

• Full Citation: US20060265517A1
• Publication Date: November 23, 2006 (Filed: May 20, 2005)
• Brief Description: This describes a TCP/IP reception process circuit, directly relevant to the hardware implementation of TCP/IP offload.
• Potential Anticipated Claims: Relevant to claims 1, 6, and 12, particularly the intelligent network adaptor performing transport protocol processing for TCP/IP.

19. US20060268841A1 (Error resilience using out of band directory information)

• Full Citation: US20060268841A1
• Publication Date: November 30, 2006 (Filed: May 13, 2005)
• Brief Description: This patent application describes error resilience using out-of-band directory information, which might implicitly involve how data status or notifications are handled.
• Potential Anticipated Claims: Could broadly relate to the notification mechanism in claims 1, 6, and 12, though less directly focused on "application level signalling."

20. US20060274788A1 (System-on-a-chip (SoC) device with integrated support for ethernet, TCP, iSCSI, RDMA, and network application acceleration)

• Full Citation: US20060274788A1
• Publication Date: December 7, 2006 (Filed: June 7, 2005)
• Brief Description: This describes a SoC with integrated support for various network protocols and acceleration, highlighting the integration of offloading capabilities.
• Potential Anticipated Claims: Relevant to the intelligent network adaptor's capabilities in performing transport protocol processing and general network acceleration as in claims 1, 6, and 12.

21. US7164656B2 (Communicating data through a network so as to ensure quality of service)

• Full Citation: US7164656B2
• Publication Date: January 16, 2007 (Filed: April 27, 2001)
• Brief Description: This patent discusses communicating data through a network to ensure quality of service, which may involve prioritization or expedited handling that could relate to "urgent" or "push" indicators.
• Potential Anticipated Claims: Could potentially anticipate the aspect of "useful application level notifications" at the transport layer, specifically the "urgent indicator" or "push indicator" in claims 1, 6, and 12.

22. US20070064737A1 (Receive coalescing and automatic acknowledge in network interface controller)

• Full Citation: US20070064737A1
• Publication Date: March 22, 2007 (Filed: September 7, 2005)
• Brief Description: This patent application describes receive coalescing and automatic acknowledgement in a network interface controller, which touches upon moderating notifications and efficiently handling data reception.
• Potential Anticipated Claims: Directly relevant to the "moderating a rate of providing application payload data arrival notifications" as described in claims 1, 6, and 12. The automatic acknowledge could also relate to the adaptor managing communication with the peer.

23. US20070233892A1 (System and method for performing information detection)

• Full Citation: US20070233892A1
• Publication Date: October 4, 2007 (Filed: March 31, 2006)
• Brief Description: This patent application describes a system and method for performing information detection, which could encompass the intelligent network adaptor's ability to detect "useful application level notifications."
• Potential Anticipated Claims: Could relate to the adaptor determining that an incoming packet contains useful application level notifications as in claims 1, 6, and 12.

24. US20080091868A1 (Method and System for Delayed Completion Coalescing)

• Full Citation: US20080091868A1
• Publication Date: April 17, 2008 (Filed: October 17, 2006)
• Brief Description: This describes a method and system for delayed completion coalescing, which is a technique for moderating notifications by grouping them, directly relevant to the core novelty of US 8,589,587.
• Potential Anticipated Claims: Highly relevant to "moderating a rate of providing application payload data arrival notifications" in claims 1, 6, and 12.

25. US20080168190A1 (Input/Output Tracing in a Protocol Offload System)

• Full Citation: US20080168190A1
• Publication Date: July 10, 2008 (Filed: February 24, 2005)
• Brief Description: This describes I/O tracing in a protocol offload system, indicating existing knowledge of offload systems and how their operations are monitored.
• Potential Anticipated Claims: Broadly relevant to the context of a protocol offload system as described in claims 1, 6, and 12.

26. US20080273532A1 (Direct Assembly Of A Data Payload In An Application Memory)

• Full Citation: US20080273532A1
• Publication Date: November 6, 2008 (Filed: May 2, 2007)
• Brief Description: This patent application explicitly mentions direct assembly of data payload in application memory, which relates to the direct data placement (zero-copy) described in US 8,589,587.
• Potential Anticipated Claims: Highly relevant to claims 1, 6, and 12, particularly the copying of application data to host memory, which often implies direct data placement to application buffers.

It's important to note that the ultimate determination of anticipation under 35 U.S.C. § 102 would require a detailed claim-by-claim analysis against the full disclosure of each prior art reference. This analysis provides an initial assessment of potential relevance.

Obviousness Analysis of U.S. Patent 8,589,587 Under 35 U.S.C. § 103

This analysis identifies combinations of prior art that would render the independent claims of U.S. Patent 8,589,587 obvious to a person having ordinary skill in the art (POSITA) at the time of the invention (priority date: May 11, 2007). The core inventive concept across the independent claims (Claims 1, 6, and 12) is the moderation of application payload data arrival notifications by an intelligent network adaptor, where this moderation is based on the adaptor processing transport header data (specifically, urgent (URG) and push (PSH) indicators) within a stateful connection to indicate application-level events.

Independent Claims 1, 6, and 12: Key Elements

The independent claims describe a system, method, and intelligent network adaptor with the following key features:

1. Intelligent Network Adaptor (INA): Couples a host to a network, the host running an application to receive data.
2. Transport Protocol Processing: The INA performs transport protocol processing for a stateful connection (e.g., TCP/IP).
3. Application Data Copying/Placement: The INA copies/places application payload data from itself to host memory (application buffers or OS buffers).
4. Notification Rate Moderation: The INA moderates the rate of providing application payload data arrival notifications to the host, without terminating the stateful connection.
5. Trigger for Moderation: This moderation is based on the INA determining (by processing transport header data) that an incoming packet contains "useful application level notifications at the transport layer indicative of events occurring at the application layer."
6. Specific Notifications: These application level notifications at the transport layer include at least one of an urgent indicator (URG) or a push indicator (PSH).

Combination of Prior Art References

A combination of the following prior art references would render claims 1, 6, and 12 obvious:

• Primary Reference: U.S. Patent 6,757,746 B2 to Alacritech, Inc. (hereinafter "Alacritech '746").
• Secondary Reference: U.S. Patent Application Publication 2007/0064737 A1 to Emulex Design & Manufacturing Corporation (hereinafter "Emulex '737").
• General Knowledge: A person having ordinary skill in the art's understanding of standard TCP/IP protocol behavior and the meaning of TCP control flags.

Alacritech '746: Intelligent Network Adaptor with Direct Data Placement

Alacritech '746 teaches an intelligent network interface device (equivalent to an intelligent network adaptor) that can write network data directly into host memory without headers, thereby performing direct data placement (DDP) or "zero-copy" operations. This device is configured to obtain a destination address in host memory for this direct write. The patent broadly covers:

• An intelligent network adaptor coupled to a host and a network.
• The adaptor performing protocol processing to extract application payload data.
• Copying/placing application data from the adaptor to host memory (e.g., application buffers).
• This typically occurs within the context of connection-oriented protocols like TCP/IP, where such offload engines (TOEs) were known to process stateful connections.

Alacritech '746 therefore establishes elements 1, 2, and 3 of the independent claims.

Emulex '737: Receive Coalescing for Notification Moderation

Emulex '737 teaches a network interface controller (NIC), which is an intelligent network adaptor, configured to perform "receive coalescing." Receive coalescing is a technique specifically designed to moderate the rate of providing notifications (e.g., interrupts) to the host by grouping multiple received packets or completion events before generating a single notification. This directly addresses element 4 of the independent claims: "moderating a rate of providing application payload data arrival notifications to the host." Emulex '737 was published on March 22, 2007, prior to the priority date of US8589587 (May 11, 2007), making it valid prior art.

General Knowledge of TCP/IP Protocol and Flags

A POSITA at the time of the invention would be fully aware of the Transmission Control Protocol (TCP) and its header control flags, including the Urgent (URG) pointer flag and the Push (PSH) flag, as defined in RFCs (Request for Comments) and commonly implemented in networking stacks. The patent US8589587 itself acknowledges these flags, stating: "TCP may carry signaling that may loosely be considered application level signaling in the TCP header control flags, such as the FIN, URG and PSH flags. The FIN flag indicates that the sender/peer has finished sending data. The URG flag indicates that the Urgent pointer is set (indicating that the payload data should reach the host quickly). The PSH flag indicates that a segment should be passed to the application as soon as possible."

The meaning and intent of these flags are to convey specific requirements for data handling to the receiving application. The URG flag indicates that the data should be processed with urgency, and the PSH flag indicates that buffered data should be immediately sent to the application.

Motivation to Combine

A person having ordinary skill in the art would have been motivated to combine the teachings of Alacritech '746 with Emulex '737 and general TCP/IP knowledge for the following reasons:

The background of US8589587 highlights critical challenges in high-speed network communications, including a "high packet arrival rate, which implies a high associated interrupt rate," significant "memory bandwidth resources to copy application payload data," and the need for "low communication latency".

1. Reducing Host Overhead and Improving Efficiency: Alacritech '746 provides a solution to the memory bandwidth challenge by enabling direct data placement, avoiding costly memory copies from OS buffers to application buffers. However, even with direct data placement, a high rate of notifications (e.g., interrupts) from the network adaptor to the host still places a significant burden on the host processor. Emulex '737 directly addresses this by teaching receive coalescing to moderate notification rates, thereby reducing the host CPU's interrupt processing load. A POSITA, aiming to further optimize host system performance, would naturally combine these two approaches: use direct data placement for efficient data movement and coalescing for efficient notification handling.

2. Maintaining Low Latency for Critical Data: While coalescing reduces overall notification rates, it might introduce latency for certain data if notifications are unduly delayed. The purpose of TCP's URG and PSH flags is specifically to signal that particular data segments require urgent or immediate attention by the application. A POSITA integrating notification moderation into an intelligent network adaptor (which already performs TCP protocol processing as described in Alacritech '746) would find it obvious to use these standard TCP flags as triggers to override general coalescing logic. That is, if a packet arrives with the URG or PSH flag set, the adaptor should generate an immediate notification to the host, even if other coalescing conditions (e.g., timer not expired, buffer not full) are not met. This ensures that application-level urgency is respected, preventing undue delays for critical data, while still moderating notifications for less urgent data. This directly addresses the patent's stated goal of achieving "low communication latency with reduced demands on host processing and memory resources".

3. No Termination of Stateful Connection: The act of processing TCP headers and moderating notifications within an ongoing TCP session is inherent to the function of a TCP offload engine and receive coalescing. Neither direct data placement nor notification coalescing implies terminating the stateful connection; rather, they are mechanisms to manage data flow within an active connection more efficiently. Therefore, providing notifications "without terminating the stateful connection" is a natural outcome of applying these techniques to standard TCP/IP communications.

Conclusion

Based on the foregoing, a POSITA would have been motivated to combine the direct data placement capabilities of an intelligent network adaptor (as taught by Alacritech '746) with the notification moderation techniques of receive coalescing (as taught by Emulex '737). Furthermore, in such a combined system performing TCP/IP processing, it would be an obvious design choice to leverage the well-known semantic meaning of TCP URG and PSH flags within the transport header data to intelligently trigger immediate notifications, ensuring timely delivery of critical application data while still reducing overall host interrupt load. This combination directly addresses the problems of high host processing burden and latency in high-speed networks, which were known in the art and explicitly articulated in the background of US8589587. Therefore, independent claims 1, 6, and 12 would have been obvious under 35 U.S.C. § 103.

I'll research the specifics of US 8,589,587, focusing on PTA/PTE, family members, and expiration.

Let me dig deeper into the specific family members and the PTA figure.

Let me retrieve the front-page PTA notice from the patent's PDF and confirm the family tree.

US 8,589,587 — Term, Family, and Expiration Analysis

Method note: I ran targeted searches against the Google Patents record, USPTO-derived mirrors, and the patent's own authoritative text. Where a figure could not be confirmed on the face of the patent, I say so explicitly and label any computed value as derived.

---

1. Bibliographic anchor (from the authoritative record)

Source: https://patents.google.com/patent/US8589587/en

---

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

What is confirmed: The authoritative Google Patents record states the adjusted expiration = 2029-08-15 and legal status "Active, expires 2029-08-15." This adjusted expiration is what incorporates PTA.

Derived PTA (please verify against the face of the patent / PatentCenter):

• Unadjusted 20-year term runs from the earliest effective filing date: 2027-05-11.
• 2027-05-11 → 2029-08-15 ≈ 827 days.
• Therefore the implied PTA is ≈ 827 days (presumably combining A-delay and B-delay under § 154(b)(1)(A)–(B)).

I could not retrieve the exact "extended or adjusted ... by ___ days" number from the patent's front page in these searches, so the 827-day figure is a derived estimate, not a quoted one. Given the 6.5-year pendency (2007-05-11 filing → 2013-11-19 issue), a PTA in the several-hundred-day range is consistent; the file history shows repeated Office Actions (2009, 2010, 2011, 2013), which supports substantial B-delay.

Terminal disclaimer: I found no indication that US 8,589,587 is subject to a terminal disclaimer (none stated in the authoritative text or the adjusted-expiration record). If verified, the full PTA flows to the term.

Context (for calibration): The same-day sibling US 7,826,350 (App. 11/747,650) states on its face "extended or adjusted under 35 U.S.C. 154(b) by 510 days." This sibling, filed the identical day, is a useful cross-check that this Chelsio cluster received large PTAs.

---

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

Not applicable. PTE under § 156 is limited to patents covering human/animal drug products, medical devices, food additives, or color additives subject to a qualifying FDA regulatory review period. US 8,589,587 claims network-adaptor protocol-offload technology — no FDA-regulated product. No PTE exists or is available, and the 2029-08-15 date reflects PTA only.

---

4. Continuations, Divisionals, and Parent Applications

None for US 8,589,587. The record shows:

• Parent: none. The application was filed 2007-05-11 as an original non-provisional with the filing date doubling as the priority date (no § 119/§ 120/§ 365 benefit claim).
• Continuations / divisionals / CIPs claiming benefit of 11/747,790: none found.
• Google Patents lists "Family Applications (1)" and "Applications Claiming Priority (1)" — both consisting solely of 11/747,790 / US 8,589,587 B1, and "Publications (1)" = US 8,589,587 B1.

So in the strict priority-family sense, US 8,589,587 stands alone.

---

5. Related Family Members / Family Cluster

The patent's own CROSS-REFERENCE section names three concurrently filed Chelsio applications (all filed 2007-05-11, common inventors Michailidis / Noureddine / Marti / Eiriksson, mutually incorporated by reference). These are related applications, not priority-family continuations — a distinction worth preserving.

True continuation within the cluster: US 8,356,112 B1 (issued 2013-01-15) is expressly "a continuation of ... Ser. No. 11/747,673." Its cross-reference also lists 11/747,650 (now US 7,826,350), 11/747,790 (this patent), and 11/747,793 as related. Note: US 8,356,112 claims benefit of 11/747,673, not of 11/747,790 — so it is not a child of this patent.

Caution: Confirming which application number issued as which patent involved some inference (the titles of US 8,060,644 and US 8,356,112 overlap, "Intelligent network adaptor with end-to-end flow control"). The 11/747,793 → patent mapping was not confirmed and should be checked in PatentCenter if it matters.

Sources: https://patents.google.com/patent/[US8935406B1](/patent/US8935406B1)/en (file-wrapper listing of 11/747,650 / 673 / 793 actions); https://www.freepatentsonline.com/[8356112](/patent/8356112).html (continuation cross-reference); US 7,826,350 front page (patentimages).

---

6. Projected Expiration Date

• Projected expiration: 2029-08-15 (per the authoritative adjusted-expiration field), assuming all maintenance fees are timely paid and no later disclaimer/expiry event.
• After PTA, the enforceable tail is notably long: the patent would run ~2 years 3 months past the nominal 2027-05-11 date.

---

7. Maintenance Fees / In-Force Status

Issue date 2013-11-19 → maintenance-fee windows at 3.5, 7.5, and 11.5 years:

• 3.5-yr: ~2017-05-19
• 7.5-yr: ~2021-05-19
• 11.5-yr: ~2025-05-19

The record shows the patent is Active with an adjusted expiration of 2029-08-15, which implies the 11.5-year fee (due ~2025) has been satisfied (or remains within a grace period). I did not retrieve an itemized maintenance-fee payment log for '587 itself; a comparable sibling (US 8,935,406) shows a recorded 4th-year small-entity payment. Verify fee status in PatentCenter.

---

8. ⚠️ Contradictions to flag against the previously generated sections

These earlier sections should be updated — the current record conflicts with them:

1. Assignment history / NPE section omitted the current owner. The patent header now lists Current Assignee: SPEEDNIC LLC, with an assignment of assignor's interest from Chelsio recorded 2026-02-13. The earlier "Assignment history" timeline ended at the 2025 Western Alliance release and did not include this transfer.
2. NPE signals verdict likely stale. The earlier NPE section concluded "no shell-entity transfer" and "verdict: insufficient data." A post-2025 transfer to SPEEDNIC LLC (a non-operating name) plus the appearance of litigation changes the ownership/assertion posture and warrants re-evaluation.
3. Litigation summary conflicts. The earlier sections stated no known litigation "as of May 1, 2026." The Google Patents record now shows a "Family has litigation" entry pointing to a Texas Western District Court case (7:26-cv-00148). If accurate, the "no litigation" conclusion in the earlier sections is incorrect and should be corrected. (I did not independently verify the docket in these searches.)

---

9. Bottom line

• PTA: ≈ 827 days (derived from the 2029-08-15 adjusted expiration vs. the 2027-05-11 nominal date) — verify the exact day count on the patent face/PatentCenter.
• PTE: none / not applicable (§ 156 inapplicable to this subject matter).
• Continuations/divisionals/parent of '587: none — it is a standalone priority family (Family ID 49555897).
• Related (same-day) applications: 11/747,650 → US 7,826,350; 11/747,673 → US 8,060,644; 11/747,793; plus cluster continuation US 8,356,112 (continuation of 11/747,673).
• Projected expiration: 2029-08-15, contingent on maintenance fees.

I'll start by verifying the patent against the USPTO record and checking the litigation/ownership signals flagged earlier.

Confirmed the litigation and ownership picture. Now let me ground the open-source standards I'll combine with, so the "Combination Prior Art" scenarios cite real, verifiable artifacts.

DEFENSIVE DISCLOSURE

Subject: US 8,589,587 B1 — "Protocol offload in intelligent network adaptor, including application level signalling"

Document type: Defensive publication / prior-art generation
Prepared: 26 April 2026
Stance: Derivation-only. This document does not restate or summarize the subject patent. It discloses new, enabling variations intended to occupy the design space around the independent claims.

---

0. Verification anchor and contradiction flags

Confirmed from the authoritative record (https://patents.google.com/patent/US8589587/en):

Litigation — verified:

• SpeedNIC LLC v. NVIDIA Corp. et al., No. 7:26-cv-00148, W.D. Tex., filed 04/16/2026, Nature of Suit 830 (Patent).
  • https://litigation.rpxcorp.com/litigation/txwdce-1172902303-speednic-v-nvidia
  • https://cdn.pacermonitor.com/public/case/64161103/SpeedNIC_LLC_v_NVIDIA_Corp_et_al
• Rule 7 disclosure identifies SpeedNIC Holdings LLC as corporate parent of SpeedNIC LLC.
• Complaint analysis indicates '587 is asserted in the same action as the '644, '627, and '733 patents, with willfulness premised in part on Mellanox having cited '587 and '644 during prosecution of its own applications.
  • https://ai-lab-cl-prod.azurewebsites.net/case/dct/txwd/7:26-cv-00148/doc/analysis/33

⚠️ Contradictions against previously generated sections (must be corrected)

1. "Litigation summary" is wrong. That section states no litigation was found "as of May 1, 2026." The W.D. Tex. complaint was filed 2026-04-16 — eleven days before that as-of date. The "no litigation to report" conclusion is inconsistent with the verified docket and should be struck.
2. "PTAB challenges" as-of date is safe but incomplete in context. The 31 May 2026 statement of no AIA proceedings stands on its own, but it should be read together with a live district-court assertion filed six weeks earlier. Any new petition would be filed against a commercially asserted patent, not a dormant one.
3. Patent summary attributes the patent to "Chelsio Communications Inc." That is correct only as to the original assignee. The current owner of record is SPEEDNIC LLC, and the summary should carry both.
4. "NPE / troll-pattern signals" verdict ("insufficient data") is stale. The prior section explicitly ran its analysis with "no known litigation" as an input. With a post-2025 acquisition by a non-operating entity and a suit filed against NVIDIA — with willfulness alleged through a subsidiary's citation of the patent during prosecution — the NPE assessment inputs have materially changed. The signal-by-signal findings (no shell-entity suffix chain, no bankruptcy fire-sale) remain accurate; the verdict does not.
5. Date-of-analysis conflict (flagging explicitly). The task header states 26 April 2026; the retrieval environment timestamp reads 2026-09-25. The 04/16/2026 filing date below is unaffected in either reading.

Publication mechanics (for the prior-art effect we are engineering)

Disclosures below are drafted to function as printed publications "otherwise available to the public" under 35 U.S.C. § 102(a)(1), and as § 103 obviousness scaffolding. To be effective they must be:

• Date-certain (deposit with DOI/timestamp; a public repository, not a private memo),
• Publicly accessible (indexed, retrievable by a POSITA without confidentiality obligation),
• Enabling (each variation below is written so a POSITA can build it without undue experimentation — this is the requirement most defensive publications fail).

Note the asymmetry a strategist must respect: a defensive publication by a third party creates § 102(a)(1) art but cannot invoke the § 102(b)(2)(C) "commonly owned" carve-out, and it does not create § 102(b)(2) art at all (that provision reaches only U.S. patents and published U.S. applications). Conversely, in absolute-novelty jurisdictions (EPO Art. 54/55) a third-party publication is lethal to any later-filed competitor claim with no grace period available. Drafting for the EPO standard is therefore the conservative choice.

---

1. Claim-primitive index (scaffolding for the derivative grid)

This is an index of claim elements used to organize the derivative grid below — not a summary. Primitives:

• P1 — Host + application + intelligent network adaptor coupling host to network; stateful connection-oriented transport (TCP/IP 4-tuple).
• P2 — Adaptor performs transport protocol processing for that connection.
• P3 — Adaptor copies application payload from adaptor memory into host memory.
• P4 — Adaptor moderates the rate of application-payload-arrival notifications to the host, without terminating the connection.
• P5 — The moderation trigger is the adaptor's own processing of transport header data to determine that a packet carries a "useful application level notification at the transport layer indicative of events occurring at the application layer."
• P6 — Enumerated triggers: URG indicator; PSH indicator.
• D-refinements — silent copy (cl. 2/7); TCP/IP + TCP control flags (cl. 3/8); further TCP header control flags (cl. 4/9); application-layer signalling proper (cl. 5/10); host makes application aware of ready buffers (cl. 11/12); presence-determination as a by-product of transport processing (cl. 13/14/15).

Derivative tags below are D<claim>.<n>, mapped to the five mandated axes.

---

2. Derivative variations

2.1 Derivatives of Independent Claim 1 (method)

D1.1 — Axis 1: Material & Component Substitution — eFPGA/SoC substrate swap and CXL memory fabric

Enabling description. Replace the fixed-function TCP segmentation/offload state machine with a runtime-reconfigurable eFPGA protocol engine (e.g., a 7 nm embedded-FPGA fabric with a 32-bit RISC-V control core) whose transport-header classifier is instantiated as a lookup structure in distributed SRAM rather than a hardwired CAM. The notification-moderation datapath is moved from a hardwired arbiter to a policy table indexed by a moderation bitfield register, so the "useful application level notification" predicate becomes programmable data rather than silicon logic. The DMA engine is replaced by a CXL 3.1 .mem device on the adaptor, so the "copy to host memory" step becomes a cache-coherent store into a pooled host-attached memory tier instead of a PCIe bus-master DMA. The host-side copy destination need not be DRAM: it may be HBM stacks on an accelerator package or persistent memory exposed as a CXL type-3 device. Functional result is identical (payload lands in host-visible memory; notifications are rate-gated on transport-header semantics), but every element is substituted.

flowchart TD
  NET[400G Optical Network] --> PEP[eFPGA Protocol Engine]
  PEP --> THC[Transport Header Classifier]
  THC --> MBR[Moderation Bitfield Register]
  MBR --> PLUT[Policy LUT in Distributed SRAM]
  PLUT --> NAGG[Notification Aggregator]
  NAGG --> DB[MSI-X Doorbell Write]
  PEP --> CXL[CXL mem DMA Engine]
  CXL --> POOL[Host Visible Memory Pool]
  DB --> POOL

D1.2 — Axis 2: Operational Parameter Expansion — 1.6 Tb/s, sub-200 ns notification budget, 6.5 million concurrent connections

Enabling description. Operate the method at an industrial extreme: a 1.6 Tb/s per-port Ethernet MAC feeding a pipelined classifier clocked at 1 GHz with a 64-byte-per-cycle datapath, giving a per-packet header-decision budget of ~40 ns. Per-connection moderation state is held in a multi-level context cache (on-chip SRAM for hot contexts, on-adaptor HBM for warm, host-mapped memory for cold), supporting 6.5M simultaneous stateful connections — the theoretical maximum for a 4-tuple space under a /32-to-/32 flow hash at 1.6 Tb/s. The moderation timer is a synchronous multi-resolution countdown: a 1 ns tick for the PSH-fired immediate path and a 1 µs tick for the periodic backstop. To hold a p99 notification latency under 200 ns, the notification is emitted as a single 8-byte PCIe memory write (MWr) to a pre-registered doorbell address rather than an interrupt, with MSI-X used only as the escalation path. At the opposite extreme, the same mechanism runs at 1 packet/second with a 60-second moderation interval, demonstrating scale invariance.

flowchart LR
  subgraph FastPath[Fast Path 1.6 Tb_s]
    MAC[1.6T MAC] --> CLS[Header Classifier 1 GHz]
    CLS --> CTX[Context Cache SRAM HBM Host]
    CTX --> ADP[Adaptive Moderation Policy]
    ADP --> IMM[Immediate Path]
    ADP --> PER[Periodic Backstop]
  end
  IMM --> DBL[8 Byte Doorbell MWr]
  PER --> MSIX[MSI-X Escalation]
  DBL --> APP[Application Poller]
  MSIX --> KRN[Kernel Notification Layer]

D1.3 — Axis 3: Cross-Domain Application — Aerospace, AgTech, Consumer XR

Enabling description. The mechanism is applied in three unrelated industries:

• Aerospace (ARINC 664 Part 7 / AFDX and IEEE 802.1DP TSN): Replace TCP 4-tuple state with virtual-link identity plus sequence number, and re-define the "useful application level notification" as the AFDX "freshness" bit in the network-management frame, or the TSN 802.1Qbv gate-open event carried in the VLAN tag's PCP field. The adaptor moderates avionics partition wakeups so a rate-constrained VL delivering 10,000 frames/s does not storm the ARINC 653 partition scheduler; a gate event forces an immediate release to the partition's receive port.
• AgTech (soil-moisture sensor mesh over 6LoWPAN/CoAP): The "transport header" is a UDP/CoAP 4-byte header with an Observe option. A change in the Observe sequence number — semantically equivalent to a push — triggers immediate delivery of the soil-moisture payload to the irrigation controller, while unchanged readings are silently accumulated in an OS-level buffer. This cuts gateway radio wakeups by orders of magnitude on a duty-cycled LoRaWAN backhaul.
• Consumer XR (headset pose/eye-tracking streaming): The transport is a UDP-based low-latency stream with a frame-boundary marker bit carried in a proprietary 2-byte header. The headset's network co-processor moderates compositor wakeups unless the marker bit is set, achieving per-frame notification granularity at 90–120 Hz while suppressing per-datagram interrupts.

flowchart TD
  subgraph Aero[Aerospace AFDX TSN]
    VL[Virtual Link Frame] --> FB[Freshness or Gate Event Bit]
    FB --> AP1[Avionics Partition Notify]
  end
  subgraph Ag[AgTech CoAP 6LoWPAN]
    SM[Soil Moisture Reading] --> OBS[Observe Seq Change]
    OBS --> AP2[Irrigation Controller Wake]
  end
  subgraph XR[Consumer XR]
    POSE[Pose Datagram] --> FBM[Frame Boundary Marker]
    FBM --> AP3[Compositor Wake at Frame Rate]
  end
  FB --> MOD[Shared Moderation Core]
  OBS --> MOD
  FBM --> MOD

D1.4 — Axis 4: Integration with Emerging Tech — RL-driven notification policy, IoT telemetry, blockchain attestation

Enabling description. The moderation predicate is promoted from a static rule to the action space of a reinforcement-learning agent running on a 4-core NPU inside the adaptor. State vector = {in-order byte depth, ring-buffer fill ratio, application consumer-pointer velocity, per-connection RTT variance, PSH/URG/FIN counts per epoch, host CPU idle percentage}; action space = {suppress, notify-now, notify-after-t, escalate-to-interrupt}. Reward = negative(host CPU cycles spent) − λ·(application-observed stall time). The agent is trained offline via simulated trace replay and executed as a quantized INT8 policy network in the adaptor's datapath, updated from the host driver every N epochs via a control-queue mailbox. IoT sensors on the NIC (on-die thermal, VRM current, PCIe link error counters) feed the state vector so moderation tightens automatically under thermal throttling. Blockchain integrates as an append-only attestation log: each moderation decision's {connection ID, byte range, trigger class, timestamp} is hashed into a Merkle tree; the periodic root is written to a permissioned ledger via a host-agent transaction, giving tamper-evident supply-chain/audit provenance for regulated data-transfer environments.

flowchart TD
  subgraph NIC[Intelligent Adaptor]
    TS[Trace Sampler] --> SV[State Vector Builder]
    IOT[IoT Telemetry Thermal VRM PCIe] --> SV
    SV --> RL[INT8 RL Policy Net]
    RL --> ACT[Action Selector]
    ACT --> MOD[Moderation Gate]
    DEC[Decision Recorder] --> MH[Merkle Hasher]
  end
  MOD --> HOST[Host Notification Queue]
  MH --> ROOT[Merkle Root Buffer]
  ROOT --> AGT[Host Ledger Agent]
  AGT --> BC[Permissioned Blockchain]
  HOST --> DRV[Driver Mailbox]
  DRV --> RL

D1.5 — Axis 5: Inverse / Failure Mode — fail-open bypass with connection preservation

Enabling description. A deliberately failure-tolerant variant: if the moderation policy table fails a CRC/ECC integrity check, or if the notification aggregator's watchdog counter exceeds a threshold, or if the moderation queue depth crosses a high-water mark that indicates host consumption has stalled, the adaptor transitions to per-packet notification (fail-open) but does not tear down the connection. State is preserved: the TCP control block stays resident, the receive-window advertisement is unchanged, and sequence/ACK state is untouched — only the notification gate is bypassed. A shadow copy of the last 64 KB of moderation decisions is pinned in adaptor SRAM, and on transition a single diagnostic completion record is delivered to a reserved host queue. The inverse design intent is explicitly "moderation is an optimization, never a correctness dependency."

stateDiagram-v2
  [*] --> Moderated
  Moderated --> IntegrityCheck: policy epoch boundary
  IntegrityCheck --> Moderated: pass
  IntegrityCheck --> FailOpen: ECC or CRC fault
  Moderated --> FailOpen: watchdog expiry
  Moderated --> FailOpen: queue high water mark
  FailOpen --> Diagnostic: emit pinned trace record
  Diagnostic --> Moderated: policy restored and flushed
  FailOpen --> [*]: connection closed by peer

D1.6 — Axis 5 (second flavour): Low-power / limited-functionality duty-cycled mode

Enabling description. A landed-cost / battery-constrained variant in which the adaptor's classification and moderation logic is power-gated for 95% of the duty cycle. In this mode the MAC accepts into a fixed 2 MB circular SRAM ring; a 32 kHz always-on sequencer wakes the classifier only when either (a) a header byte matches a pre-armed 8-bit transport-flag mask programmed for URG and FIN only, or (b) the ring crosses 75% occupancy, or (c) a 100 ms backstop timer fires. PSH is deliberately not armed in this mode to save the extra comparator's static power. Consequences are disclosed explicitly: notification latency degrades to a bounded 100 ms worst case, zero-copy direct placement is disabled, and the flow-control credit window is clamped to 64 KB. The variant is described so that its reduced capability is a claimed-in-the-disclosure design point, not an unclaimed accident.

flowchart TD
  MAC[MAC Receive] --> RING[2 MB Circular SRAM Ring]
  RING --> WAKE{Wake Sequencer 32 kHz}
  WAKE -->|flag mask match| CLS[Classifier Core Power Up]
  WAKE -->|ring at 75 pct| CLS
  WAKE -->|100 ms backstop| CLS
  WAKE -->|no trigger| PG[Power Gate Held]
  CLS --> HG[Notification Gate URG and FIN only]
  HG --> HOST[Host Wake Queue]
  CLS --> CRED[Credit Window Clamp 64 KB]

---

2.2 Derivatives of Independent Claim 6 (intelligent network adaptor)

D6.1 — Axis 1: Material & Component Substitution — co-packaged optics, UCIe chiplets, RDMA-immediate substitution for DMA copy

Enabling description. Substitute the electrical SERDES front-end with co-packaged optics (8× 800G-FR4 optical engines on a silicon-photonic interposer) and split the adaptor into UCIe 1.1 die-to-die chiplets: a MAC/PHY chiplet, a transport-offload chiplet, and a notification-engine chiplet, each with its own DVFS domain. The host-memory copy primitive is substituted: instead of a bus-master DMA write, the adaptor issues an RDMA Write-with-Immediate into a registered host memory region, using the Immediate field as the notification vector after applying the moderation predicate. The "copy to host memory" limitation is therefore satisfied by a remote-memory-semantics operation rather than a local DMA, and the notification is a data-carrying operation rather than a separate interrupt line. All functional properties of claim 6 — transport processing, copy, moderated notification gated on transport-header semantics — are preserved.

flowchart LR
  OPT[Co Packaged Optics 8x800G] --> MC[MAC Chiplet]
  MC -->|UCIe 1.1 D2D| TO[Transport Offload Chiplet]
  TO -->|UCIe 1.1 D2D| NE[Notification Engine Chiplet]
  NE --> GATE[Moderation Predicate]
  TO --> WQE[RDMA Write with Immediate]
  GATE --> WQE
  WQE --> MR[Registered Host Memory Region]
  WQE --> IMM[Immediate Field as Vector]
  IMM --> APP[Application Completion]

D6.2 — Axis 2: Operational Parameter Expansion — radiation-hardened orbital deployment and extreme-MTU industrial deployment

Enabling description. Two extremes on the parameter axis:

• Orbital (LEO, 100 krad TID, single-event-upset tolerance): The offload core is triple-modular-redundant with a scrubbing controller refreshing configuration SRAM every 250 ms. Because the link is 10 ms–600 ms RTT, the periodic moderation timer is re-scaled logarithmically and the "timer since last silent placement" backstop is lengthened to the link RTT. The transport-header predicate is additionally armed on the TCP ECE/CWR pair to signal congestion events to the ground application. Radiation-tolerant triple-voting latches protect the moderation bitfield register so an SEU cannot silently disable a URG release.
• Industrial scale: At the other extreme, the adaptor is deployed with a 64 KB jumbo MTU and a 9 KB TCP MSS, so a single segment spans an entire application record; moderation collapses naturally to one notification per record, and the disclosed operating point is a notification-to-byte ratio of 1:65536.

flowchart TD
  subgraph Orbital[Orbital Configuration]
    RX1[Downlink Frames] --> TMR[Triple Modular Redundant Core]
    SCRUB[Config SRAM Scrubber 250 ms] --> TMR
    TMR --> TVL[Triple Voting Latch]
    TVL --> LT[Log Scaled Moderation Timer]
    LT --> DOWN[Ground Application Release]
  end
  subgraph Industrial[Industrial Configuration]
    RX2[64 KB Jumbo MTU] --> REC[Record Boundary Detector]
    REC --> RM[Moderation Gate 1 notification per 65536 bytes]
    RM --> CTRL[PLC Control Loop]
  end

D6.3 — Axis 3: Cross-Domain Application — Automotive zonal Ethernet, medical DICOM, electronic trading

Enabling description.

• Automotive zonal architecture (IEEE 802.1AS/802.1Qbv TSN): The adaptor is a zonal gateway port. The "useful application level notification" is re-bound to the gPTP sync-event or the IEEE 802.1CB frame-replication sequence-recovery tag, and moderation prevents a 200-sensor zonal bus from waking every ECU. A CAN-to-Ethernet gateway instance maps the CAN "extended remote frame" to the notification trigger.
• Medical imaging (DICOM over TCP, large study transfer): Moderation is bound to DICOM PDU boundaries in the application layer — specifically the last fragment of a Data Set PDU — so the PACS client is woken once per image rather than once per TCP segment. A HIPAA-auditable moderation log records the byte range of each delivery.
• Electronic trading (FIX/OUCH over TCP with a hardware pre-trade risk gate): The notification moderation is gated on the FIX PossDupFlag and MsgSeqNum gap detection: an out-of-sequence notification is escalated immediately and unconditionally, while in-sequence fills are coalesced. Moderation is bounded by a hard 50 µs ceiling enforced by a hardware watchdog, and the adaptor cannot suppress a notification flagged with a risk-gate rejection code.

sequenceDiagram
  participant Wire as Network Wire
  participant ZGW as Zonal Gateway Adaptor
  participant Mod as Moderation Core
  participant ECU as Automotive ECU
  participant PACS as DICOM PACS Client
  participant OMS as Trading Order Gateway
  Wire->>ZGW: TSN frame with gPTP sync event
  ZGW->>Mod: classify transport and link layer header
  Mod->>ECU: immediate release on sync event
  Wire->>ZGW: DICOM Data Set PDU final fragment
  ZGW->>Mod: detect PDU boundary
  Mod->>PACS: one notification per image
  Wire->>ZGW: FIX message with seq gap
  ZGW->>Mod: gap detection predicate
  Mod->>OMS: unconditional escalation within 50 us

D6.4 — Axis 4: Integration with Emerging Tech — semantic payload inspection, IoT-driven moderation, on-ledger delivery receipts

Enabling description. Extend the adaptor's predicate beyond transport-header bitfields into bounded semantic payload inspection: a streaming regular-expression engine (≤ 8 KB DFA) classifies the first 512 bytes of each in-order run and raises the notification when it recognizes a protocol verb the application has registered as "actionable" (e.g., an HTTP/2 HEADERS frame with END_STREAM, a Kafka produce-batch terminator, a gRPC trailer). This is disclosed as distinct from parsing at the host. IoT integration: an on-die power sensor drives a moderation duty-cycle governor so that notification bursts are spread to avoid VRM current spikes. Blockchain integration: each delivered byte range generates a delivery receipt with {connection 4-tuple hash, offset, length, adaptor monotonic counter}; receipts are batched into a Merkle tree per 10 ms epoch and the root is committed via a host-side ledger client, enabling regulator-verifiable evidence that a transfer completed without host re-copy.

flowchart TD
  PKT[Inbound Segment] --> RE[Streaming DFA 8 KB]
  PKT --> TH[Transport Header Predicate]
  RE --> OR[Notification OR Tree]
  TH --> OR
  OR --> MOD[Moderation Gate]
  MOD --> DEL[Delivery to App Memory]
  MOD --> REC[Receipt Generator]
  REC --> MT[Merkle Batcher 10 ms]
  MT --> LED[Ledger Commit Client]
  PWR[On Die Power Sensor] --> GOV[Duty Cycle Governor]
  GOV --> MOD

D6.5 — Axis 5: Inverse / Failure Mode — degraded "safe mode" adaptor and adversary-hostile mode

Enabling description. A provably-conservative adaptor variant: on entry to safe mode (triggered by ECC fault, policy signature mismatch, or firmware attestation failure), the adaptor disables direct data placement and zero-copy entirely, deposits all payload into an OS-owned bounce buffer, and restricts the notification predicate to the single irreducible trigger set {URG, FIN, RST}. No coalescing is performed, so the system cannot miss a connection teardown. A second inverse flavour targets an adversary-hostile environment: the moderation gate is instrumented to deliberately emit a notification for every packet carrying a PSH bit set by a peer that appears to be probing the coalescing window (detected by a rate-of-PSH threshold), converting a potential covert-channel timing side-channel into a uniform-timing notification floor. This is a defensive-publication of "moderation that defends itself against timing analysis."

stateDiagram-v2
  [*] --> NormalModerated
  NormalModerated --> SafeMode: ECC fault
  NormalModerated --> SafeMode: attestation mismatch
  NormalModerated --> SafeMode: policy signature invalid
  SafeMode --> BounceBuffer: disable direct data placement
  BounceBuffer --> MinimalTriggers: URG FIN RST only
  NormalModerated --> AntiSideChannel: PSH rate above threshold
  AntiSideChannel --> UniformFloor: emit per packet
  UniformFloor --> NormalModerated: rate normalizes

D6.6 — Axis 2 and 5 combined: notification algebra generalization

Enabling description. Rather than a single boolean predicate, disclose a composable notification algebra in which the transport-header decision is the evaluation of a small expression tree: release = (PUSH AND in_order_bytes > K) OR URG OR FIN OR (timer_expired) OR (sack_block_edge) OR (window_update_delta > W). The tree is compiled into a 12-entry lookup programmed from the host driver; leaves reference bitfields in the parsed transport header context (TCP flags byte, options area, SACK blocks, window field delta). The adaptor caches the last evaluated leaf values to make evaluation branch-free and single-cycle. This generalizes the enumerated URG/PSH triggers to a class of header-derived, application-meaningful events.

flowchart TD
  CTX[Parsed Transport Header Context] --> L1[Leaf PUSH and depth K]
  CTX --> L2[Leaf URG]
  CTX --> L3[Leaf FIN]
  CTX --> L4[Leaf Timer Expired]
  CTX --> L5[Leaf SACK Edge]
  CTX --> L6[Leaf Window Delta W]
  L1 --> ORT[OR Reduce Tree]
  L2 --> ORT
  L3 --> ORT
  L4 --> ORT
  L5 --> ORT
  L6 --> ORT
  ORT --> REL[Release Decision]
  DRV[Host Driver Compiled Table] --> ORT

---

2.3 Derivatives of Independent Claim 12 (system)

D12.1 — Axis 1: Material & Component Substitution — disaggregated host with CXL memory expander and DPU

Enabling description. The system is restructured so that "host memory" is pooled, disaggregated CXL type-3 memory attached to a memory-expander chassis rather than DIMMs local to the host socket. The host is a CPU-free node in the receive path: the adaptor writes payload into the pooled memory region mapped as a CXL .mem window, and the application — running on a CPU elsewhere in the fabric — reads from that window. The notification is delivered as a CXL cache-coherence event (a write to a monitored address range) that the host agent observes via a cxl_poison/event-interrupt-equivalent mechanism. Because the application-consumed region is now remote, the moderation predicate is extended with a fabric-latency term: the periodic backstop is set to at least 2× the memory-fabric RTT so a notification is never released before the payload is coherently visible.

flowchart LR
  NIC[Intelligent Network Adaptor] --> CXLW[CXL mem Window]
  CXLW --> POOL[Disaggregated Memory Expander]
  NIC --> MON[Monitored Address Range]
  MON --> EVT[Coherence Event to Host Agent]
  POOL --> APP[Application on Remote CPU]
  APP --> CRED[Credit Return over Fabric]
  CRED --> NIC
  FAB[Fabric RTT Estimator] --> MOD[Moderation Backstop Scaling]
  MOD --> MON

D12.2 — Axis 2: Operational Parameter Expansion — rack-scale tenancy at 100,000 connections and sub-millisecond cross-rack placement

Enabling description. Scale the system to 100,000 concurrent stateful connections across 128 adaptor ports in one rack, with the moderation policy federated across adaptors via a shared control-plane context replication bus (a 25 Gb/s Ethernet sideband). Each adaptor maintains a Bloom-filter digest of peer adaptors' connections so a migrating connection's moderation state can be fetched on demand rather than replicated eagerly; state transfer on migration costs a single 256-byte context fetch. Notification delivery is token-bucketed per tenant with a programmable burst allowance, so a noisy tenant cannot consume another tenant's notification budget through a shared host interrupt lane. Disclose explicitly the extremes tested: 10 Gb/s and 1 Gb/s ports, and 1 connection per host in a single-tenant configuration.

flowchart TD
  T1[Tenant A Flows] --> A1[Adaptor 1]
  T2[Tenant B Flows] --> A2[Adaptor 2]
  T3[Tenant C Flows] --> AN[Adaptor N]
  A1 --> BF[Bloom Digest of Peer Contexts]
  A2 --> BF
  AN --> BF
  BF --> MIG[Context Migration Fetch 256 B]
  A1 --> TB[Per Tenant Token Bucket]
  A2 --> TB
  AN --> TB
  TB --> LANE[Shared Host Interrupt Lane]
  CP[Control Plane Sideband 25 Gb_s] --> BF

D12.3 — Axis 3: Cross-Domain Application — Data-center AI fabric, remote surgery, satellite constellation ground segment

Enabling description.

• AI training fabric (RDMA/RoCE collectives): The system moderates completion-queue notifications for NCCL-style all-reduce chunks, releasing only when a collective-phase boundary is detected in the transport header's destination-QP and a phase-counter field. Three unrelated industries follow:
• Remote robotic surgery: The "transport header predicate" is bound to a haptic control-loop sequence marker; the notification releases the surgeon console's control-loop tick, and a bounded-latency safety envelope forces an unconditional release if the interval exceeds 4 ms, on the theory that stale haptic data is worse than a wakeup.
• Satellite constellation ground segment: Each ground-station adaptor moderates telemetry downlink notifications keyed to CCSDS transfer-frame virtual-channel counters, releasing only when a virtual channel's frame counter completes a 256-frame block, reducing ground-segment CPU load by ~99%.

flowchart TD
  subgraph AI[AI Training Fabric]
    RD[RoCE All Reduce Chunk] --> PH[Phase Boundary in Transport Header]
    PH --> CQ[Moderated CQ Notification]
  end
  subgraph Surgery[Remote Robotic Surgery]
    HB[Haptic Sequence Marker] --> SE[Safety Envelope 4 ms]
    SE --> CON[Surgeon Console Tick]
  end
  subgraph Space[Ground Segment]
    TF[CCSDS Transfer Frame] --> VC[Virtual Channel Counter]
    VC --> BLK[Release per 256 Frame Block]
    BLK --> GS[Ground Segment Processor]
  end

D12.4 — Axis 4: Integration with Emerging Tech — federated learning of moderation policies, IoT-instrumented fabric, on-ledger delivery SLA enforcement

Enabling description. Multiple hosts in a fleet run federated learning over local moderation-policy gradients: each host computes a gradient from observed {notification rate, application stall time} pairs, encrypts it, and a coordinator aggregates via secure multiparty aggregation; the updated policy is signed and pushed to adaptors as a new policy-table image validated against a hardware root of trust. IoT integration extends beyond the NIC to rack-level sensors (inlet temperature, PSU telemetry, PCIe AER counters) which gate policy aggressiveness. Blockchain integration makes the moderation policy itself an auditable artifact: each policy image hash is written to a permissioned ledger, creating a verifiable record that a tenant was, or was not, subject to a given notification-degradation policy at a given time — the artefact a litigator or regulator would otherwise have to reconstruct from packet captures.

flowchart TD
  H1[Host 1 Local Gradient] --> AGG[Secure Aggregation Coordinator]
  H2[Host 2 Local Gradient] --> AGG
  HN[Host N Local Gradient] --> AGG
  AGG --> POL[Global Moderation Policy]
  POL --> SIGN[Sign with Hardware Root of Trust]
  SIGN --> PUSH[Policy Image Push to Adaptors]
  RACK[IoT Rack Sensors] --> GATE[Aggressiveness Governor]
  GATE --> PUSH
  POL --> HASH[Policy Image Hash]
  HASH --> LED[Permissioned Ledger]

D12.5 — Axis 5: Inverse / Failure Mode — partition-detecting system with guaranteed-delivery fallback

Enabling description. A system variant that treats notification moderation as a revocable lease: the host grants the adaptor a moderation lease with an absolute expiry; the adaptor must either deliver a notification or renew the lease within the window. If the host's renewal channel is unresponsive (host hang, hypervisor stall, network partition to the management plane), the lease lapses and the adaptor fails back to host-owned bounce buffers with per-packet MSI-X, independently of any adaptor-internal fault. The inverse property is deliberate: no notification can be withheld indefinitely, even if the adaptor's own moderation hardware is healthy but the host is not. A second inverse: when the host's application has crashed and its pinned buffers are unclaimable, the adaptor reclaims the pinned pages, re-points the memory map to a quarantine region, and notifies only the kernel — no application-level notification is emitted, preventing a notification storm into a dead process.

stateDiagram-v2
  [*] --> LeaseGranted
  LeaseGranted --> Moderating: adaptor accepts lease
  Moderating --> Renewed: host renews
  Renewed --> Moderating
  Moderating --> LeaseLapsed: renewal missing
  LeaseLapsed --> PerPacketFallback: bounce buffer and MSI-X
  Moderating --> AppDead: pinned page unclaimable
  AppDead --> Quarantine: reclaim pages and remap
  Quarantine --> KernelOnly: notify kernel only
  PerPacketFallback --> LeaseGranted: host revives

D12.6 — Axis 1 and 2 combined: multi-tenant SR-IOV system with per-VF moderation isolation

Enabling description. The system is virtualized: a single physical adaptor presents 64 SR-IOV virtual functions, each with an independent moderation policy table, independent notification doorbell BAR, and independent credit accounting. Isolation is enforced in hardware: VF i's classifier cannot read VF j's context SRAM (separate address apertures plus an MMU with per-VF page tables), and the notification aggregator applies strict priority arbitration with a guaranteed minimum service floor per VF so a VF under a denial-of-service flow cannot starve another VF's notifications. Disclosed as a contrast to the single-host case in the base disclosure: the moderation predicate is unchanged, but the arbitration becomes a scheduling problem with fairness guarantees.

flowchart TD
  PF[Physical Function] --> SR[SR IOV Fabric]
  SR --> V1[VF 1 Policy Table]
  SR --> V2[VF 2 Policy Table]
  SR --> VN[VF 64 Policy Table]
  V1 --> MMU[Per VF MMU and Apertures]
  V2 --> MMU
  VN --> MMU
  V1 --> ARB[Strict Priority Aggregator with Service Floor]
  V2 --> ARB
  VN --> ARB
  ARB --> D1[VF 1 Doorbell BAR]
  ARB --> D2[VF 2 Doorbell BAR]
  ARB --> DN[VF 64 Doorbell BAR]

---

3. Combination Prior Art scenarios

Each scenario combines the subject patent's primitives with a specific, verifiable open-source or standards-track artifact, so the combination is citable by document, version, and section.

CPA-1 — Claim 1 primitives + AF_XDP (Linux kernel) UMEM/FILL/COMPLETION rings

Combination. AF_XDP establishes a user-space UMEM of equally sized chunks, a FILL ring where user space posts buffer addresses for the kernel to fill, an RX ring where filled descriptors appear, and a COMPLETION ring for TX. RX and TX may share one UMEM so that "a packet does not have to be copied between RX and TX."
Source: https://www.kernel.org/doc/html/v4.19/networking/af_xdp.html and https://docs.kernel.org/6.5/networking/af_xdp.html

New disclosure (combination subject matter). Combine AF_XDP's ring discipline with a transport-header-derived moderation predicate executed inside the XDP program, not in a TOE. Concretely: an XDP program at the driver hook parses the TCP header, evaluates a PSH/URG predicate, and uses bpf_map_update_elem on a BPF_MAP_TYPE_ARRAY of moderation state keyed by 4-tuple hash; the XDP_REDIRECT into the XSKMAP is performed for every packet (so zero-copy placement is unconditional), but the user-space wakeup is issued by writing a descriptor to a dedicated doorbell XSK ring only when the predicate fires, or when the FILL ring's need_wakeup flag is set. The XDP_USE_NEED_WAKEUP bind flag is the disclosed hardware-agnostic analogue of the adaptor's backstop timer. This places the full claim-1 mechanism — transport processing, zero-copy placement, gated notification, URG/PSH predicate — in an eBPF/AF_XDP software stack on commodity NICs, with no TOE silicon.

sequenceDiagram
  participant App as User Space Application
  participant UMEM as Shared UMEM
  participant XSK as AF_XDP Socket Rings
  participant XDP as XDP Program at Driver
  participant NIC as NIC RX Queue
  NIC->>XDP: frame arrives
  XDP->>XDP: parse TCP header flags
  XDP->>XDP: evaluate PSH and URG predicate
  XDP->>XSK: XDP_REDIRECT to XSKMAP index
  XSK->>UMEM: filled descriptor appears on RX ring
  XDP->>XSK: doorbell write only when predicate fires
  XSK->>App: wakeup or explicit poll
  App->>XSK: post new addresses on FILL ring

CPA-2 — Claim 6 primitives + DPDK Poll Mode Driver burst API

Combination. DPDK exposes rte_eth_rx_burst(port_id, queue_id, rx_pkts, nb_pkts) and rte_eth_tx_burst(...), with a default burst size commonly set to 32; the literature documents that burst processing amortises cache-line fills across multiple descriptors and that the PMD's rx/tx burst function pointers are dispatched with zero overhead. Sources: https://deepwiki.com/DPDK/dpdk/2-network-poll-mode-drivers-(pmds); https://fast.dpdk.org/doc/pdf-guides-18.11/nics-18.11.pdf; Chelsio's own Terminator 5 CXGBE PMD is listed among DPDK PMDs (https://dpdk-power-docs.readthedocs.io/_/downloads/en/latest/pdf/).

New disclosure. Disclose an adaptor configured so that the burst size itself is the moderation knob, driven by the transport-header predicate: the PMD's rx_pkt_burst implementation inspects the parsed mbuf's ol_flags/packet_type and the TCP flags byte, and when a PSH or URG is observed it returns early with a short burst (nb_pkts truncated to the index of that packet) so the application's polling loop is forced to hand off to the consumer immediately; otherwise it fills the full programmed burst size before returning. Additional disclosure: a per-queue moderation threshold implemented by setting rx_free_thresh/tx_rs_thresh analogues in the RX direction, and a doorbell-based "zero-notification" steady state where the application core polls the RX ring continuously and only crosses to a cross-core wakeup when a predicate fires.

flowchart TD
  POLL[Application Core Polls rx_burst] --> PMD[PMD rx_pkt_burst]
  PMD --> DESC[Read RX Descriptors]
  DESC --> PARSE[Parse TCP Flags in mbuf]
  PARSE --> Q{PUSH or URG seen}
  Q -->|yes| SHORT[Return truncated burst immediately]
  Q -->|no| FULL[Fill full programmed burst size]
  SHORT --> CONSUME[Application consumes now]
  FULL --> RESUME[Application continues polling]
  RESUME --> POLL
  CONSUME --> POLL

CPA-3 — Claim 12 primitives + Linux NAPI/io_uring receive path with MSG_ZEROCOPY and SO_BUSY_POLL

Combination. Linux provides NAPI (interrupt-to-polling transition under load), socket option SO_BUSY_POLL (low-latency polling without waiting for an interrupt), and MSG_ZEROCOPY (avoiding a copy on the send side by pinning user pages). AF_XDP documentation above establishes the kernel's willingness to turn interrupts off when buffers are exhausted and signal need_wakeup instead — an explicit in-kernel instance of "notification is conditional."

New disclosure. Disclose a system-level design in which the host kernel's NAPI instance is deliberately kept in polling mode for connections whose adaptor has signalled a "moderation-active" state, and is forced back to interrupt mode by the adaptor issuing a synthetic notification. Concretely: (a) the adaptor exposes a per-queue moderation descriptor mapping a 4-tuple to a policy; (b) the driver writes the policy to the NAPI instance's weight/budget register; (c) when the adaptor's predicate fires, it writes to an eventfd-backed doorbell page mmap'd into the driver, which calls napi_schedule() even though the queue's interrupts are masked; (d) if the predicate has not fired within the adaptor's backstop interval, the adaptor raises the same doorbell as an unconditional liveness event. This makes the patent's "moderating a rate of providing ... notifications ... without terminating the stateful connection" a kernel-driver-plus-hardware co-design on a standard Linux stack.

flowchart TD
  IRQ[Adaptor Interrupt Line] --> NAPI[NAPI Instance on Queue]
  NAPI --> MASK{Masked by Moderation Active}
  MASK -->|masked| POLL[Kernel Polls Ring]
  MASK -->|unmasked| ISR[Interrupt Service Routine]
  ADP[Adaptor Predicate Fires] --> DB[Eventfd Doorbell Page]
  DB --> NAPI
  BK[Adaptor Backstop Timer] --> DB
  POLL --> SKB[SKB to Socket Layer]
  ISR --> SKB
  SKB --> APP[Application read]
  APP --> ZC[MSG_ZEROCOPY Page Pinning]

CPA-4 — Claim 1/6 primitives + P4-16 programmable parser and match-action pipeline (PSA architecture)

Combination. P4-16 defines a programmable packet parser producing a header stack, and a match-action pipeline with tables whose default actions include forwarding, dropping, and recirculation; commercial implementations (e.g., Tofino-class ASICs, and P4-programmable DPUs) realise this in hardware at line rate.

New disclosure. Disclose the moderation predicate as a P4 table keyed on the parsed TCP flags byte plus connection-metadata registers, with actions {release_now, defer, defer_and_arm_timer, escalate_to_host}. Registers (Register<bit<32>, bit<16>>) hold per-flow byte counters and timer state; a RegisterAction increments the in-order byte counter and compares against a compiled threshold K. The disclosure's novel contribution is the mapping of the "useful application level notification" semantics into P4 metadata carried alongside the packet to the host-facing recirculation port, plus an explicit disclosure that the release action performs a host-doorbell write from the pipeline's egress deparser rather than a recirculation to a CPU. This places the patent's central mechanism inside a vendor-neutral programmable-pipeline language, with a concrete, compilable design.

flowchart LR
  IN[Ingress Port] --> P[P4 Parser]
  P --> TCP[Extract TCP Flags Byte]
  TCP --> TBL[Match Action Table on Flags and Context]
  TBL --> RA[RegisterAction Byte Counter]
  RA --> CMP[Compare to Threshold K]
  CMP --> DEC[Action Decision]
  DEC -->|release_now| DPR[Egress Deparser Doorbell Write]
  DEC -->|defer and arm timer| REG[Flow Timer Register]
  DEC -->|escalate| CPU[Host Queue Recirculation]
  DEC -->|defer| DROP[No Host Notification]
  REG --> DPR

CPA-5 — Claim 6 primitives + RDMA/iWARP standards-track DDP (RFC 5040/5041/5044) and QUIC (RFC 9000) framing

Combination. iWARP defines Direct Data Placement with MPA/FPDU framing (RFC 5044) which allows an adaptor to place tagged data directly into a pre-posted host buffer using a steering tag and offset, with the transport relying on TCP. QUIC (RFC 9000) defines stream framing with explicit stream IDs, offsets, and FIN bits inside an encrypted, connection-oriented transport — i.e., application-visible boundaries carried in a transport-layer framing structure.

New disclosure. Disclose an adaptor that runs QUIC-aware DDP: the adaptor terminates the QUIC packet number space and header protection, decrypts the frame, and uses the STREAM frame's stream ID, offset, and FIN bit plus the frame-type field as the "useful application level notification at the transport layer" predicate. Because QUIC FIN is per-stream and semantically an application-visible event, a stream-FIN forces immediate release; in-stream STREAM frames are placed by offset into a pre-posted application buffer using a DDP-style tagged placement (steering tag = stream ID, offset = STREAM offset), and notifications are coalesced with the frame's ACK-eliciting-equivalent marker as a secondary modifier. This is disclosed at the intersection of the patent's mechanism and two open standards, and it materially post-dates the 2007 priority date in its QUIC component while remaining an obvious combination for a POSITA reading the patent plus RFC 9000.

sequenceDiagram
  participant Peer as QUIC Peer
  participant NIC as QUIC Aware Adaptor
  participant ST as Stream DDP Table
  participant App as Application Buffer
  Peer->>NIC: QUIC packet with header protection
  NIC->>NIC: remove protection and decrypt frames
  NIC->>NIC: parse STREAM frame type offset stream ID FIN
  NIC->>ST: steering tag from stream ID
  ST->>App: direct placement at stream offset
  NIC->>NIC: evaluate FIN and ACK eliciting markers
  NIC->>App: immediate release on stream FIN
  App->>NIC: credit return on consumption

---

4. Residual novelty coverage notes

Beyond the enumerated derivatives, the following residual variations are disclosed here to close gaps a competitor might otherwise occupy:

1. Notification-as-data — carrying the notification inside the data-carrying operation (RDMA Immediate, CXL write, doorbell write) rather than as a separate interrupt; disclosed above in D6.1 and CPA-1.
2. Predicate compilation from host — the moderation predicate as a driver-compiled table image, signed and versioned (D6.6, D12.4). A competitor claiming "programmable, host-supplied notification criteria" should find this anticipating.
3. Lease semantics — bounded-time moderation leases with mandatory renewal (D12.5). This is the "don't hold data hostage" limitation that a later filer may try to add as an improvement.
4. Moderation as a timing side channel — the anti-side-channel uniform-floor variant (D6.5) occupies a security-motivated improvement space.
5. Federated policy learning — fleet-wide moderation policy updated by aggregated gradients (D12.4).
6. Multi-tenant fairness floors in the notification aggregator (D12.6) — the arbitration layer, which the base disclosure does not appear to treat as an isolated problem.

5. Practical filing/deposit recommendation

To maximize prior-art effect against a competitor's § 102(a)(1) date, deposit this document (with the diagrams rendered, not merely in Mermaid source) as a timestamped, DOI-minted, index-crawled public artifact, and include the enabling detail above verbatim. A publication that is public but non-enabling is a trap: it is citable but easily distinguished. The descriptions in §2 and §3 are written to the enablement standard deliberately.

---

Summary of what is not claimed here and should not be treated as covered

The following were searched and not confirmed, and are therefore flagged rather than asserted: (i) the precise PTA day count on the face of US 8,589,587 (the 2029-08-15 adjusted expiration is confirmed; the implied ≈827 days remains derived); (ii) whether the '733 and '627 patents asserted in SpeedNIC v. NVIDIA share a specification with '587 (the complaint analysis treats them as distinct disclosures with distinct claim sets); (iii) the specific mapping of application 11/747,793 to an issued patent. These do not affect the prior-art content above, but they should be verified in PatentCenter before being relied on in any filing or opinion.