US 7826350

A concise summary of US Patent 7,826,350 is as follows:

Title: Intelligent network adaptor with adaptive direct data placement scheme

Assignee: Chelsio Communications Inc.

Inventors: Dimitrios Michailidis, Wael Noureddine, Felix A. Marti, Asgeir Thor Eiriksson

Filing Date: May 11, 2007

Issue Date: November 2, 2010

Abstract:
The patent describes a system where a host computer is connected to a network through an intelligent network adaptor. This adaptor handles the protocol processing for an application on the host that is receiving data from a peer over the network. The system can selectively place incoming application data directly into the application's memory. This decision is made by the operating system, which provides the adaptor with information about the application's memory. Initially, data may be copied from a general host memory area to the application's memory, but subsequently, data can be placed directly into the application's memory by the intelligent network adaptor.

Plain-Language Overview of Independent Claims:

• Claim 1: This claim outlines a method for an intelligent network adapter and a host computer to determine the most efficient way to handle incoming data for an application. The system decides whether to place data directly into the application's memory based on the specific request from the application, particularly considering the size of the memory buffer the application has provided.

• Claim 2: This claim details a process where a part of the incoming data for an application is first stored in a temporary memory location on the host (not directly usable by the application) and is then copied over to the application's designated memory space.

• Claim 5: Similar to Claim 2, this claim describes copying a portion of the application's data from a temporary host memory area to the application's own memory. The distinction lies in the technical description of the temporary memory not being associated with the specific data connection.

• Claim 10: This claim covers a computer program product, such as a disk or other non-transitory medium, that contains software instructions. When a host computer runs these instructions, it is enabled to decide whether to have its intelligent network adapter place data directly into an application's memory. The instructions also cover the process of copying data from a temporary memory location to the application's memory.

• Claim 13: This claim also pertains to a computer program product with instructions similar to those in Claim 10. The subtle difference is in the characterization of the temporary memory from which the data is copied.

• Claim 16: This claim specifies a method for handling data within an ongoing, state-aware network connection. The method involves deciding where the intelligent network adaptor should place incoming data based on the application's request. It also includes the step of copying a portion of the data from a temporary host memory area to the application's memory.

A search of the U.S. Court of Appeals for the Federal Circuit (CAFC) dockets for 2026 did not reveal any cases specifically involving US patent 7,826,350 as of the date of this analysis.

As of April 26, 2026, a search of publicly available litigation databases, including Unified Patents and information regarding CAFC and PACER dockets, did not reveal any known litigation specifically involving US patent 7,826,350. While Unified Patents tracks patent litigation and Inter Partes Reviews (IPRs), and provides a platform to search for cases by patent number, no results for US7826350 were found in their records. Similarly, general searches for patent litigation and specific patent numbers on CAFC and PACER resources did not yield any cases directly citing US patent 7,826,350.

Therefore, based on the performed searches, there is no known litigation involving US patent 7,826,350 to report at this time.

Proceedings overview

The USPTO ODP API returns no AIA trial proceedings for this patent as of the most recent ingest. No PTAB activity on file.

Strategic summary

As of today's date, May 27, 2026, there is no PTAB activity on file for US Patent 7,826,350. This means all claims of the patent (claims 1-16) remain untested by AIA trial proceedings.

The absence of PTAB challenges for this patent could imply several things. It might suggest that the patent has not been extensively asserted in litigation, thus not drawing the attention of potential petitioners. Alternatively, it could be that previous assessments by potential challengers concluded that the claims are robust and less susceptible to invalidation under §§ 102 or 103, or that the cost-benefit of an IPR does not favor a petition. Without any PTAB proceedings, there is no estoppel landscape to consider under § 315(e)(2) for this patent.

Recommended next steps

If facing an assertion of US Patent 7,826,350, a defendant should conduct a thorough prior art search and an in-depth analysis of the patent claims to identify potential grounds for an AIA trial (e.g., IPR, PGR, or CBM). The absence of prior PTAB activity means that all claims are currently presumed valid and have not been subjected to the scrutiny of an AIA trial.

Inventors

• Dimitrios Michailidis: Employed by Chelsio Communications Inc. at the time of filing.
• Wael Noureddine: Employed by Chelsio Communications Inc. at the time of filing.
• Felix A. Marti: Employed by Chelsio Communications Inc. at the time of filing.
• Asgeir Thor Eiriksson: Employed by Chelsio Communications Inc. at the time of filing.

All named inventors were employed by the original assignee, Chelsio Communications Inc., at the time the application was filed.

Original assignee

Chelsio Communications Inc. is the entity named on the issued patent. Chelsio Communications Inc. is primarily in the business of designing and marketing high-performance Ethernet network adapters (NICs), including those with TCP Offload Engine (TOE) capabilities, which embody the claims of US 7,826,350 concerning intelligent network adaptors and direct data placement schemes. As of the current date, Chelsio Communications Inc. is an active, operating company.

Assignment timeline

• 2007-05-11 (executed) / recorded 2007-05-11 — Reel 019685/0733

  • 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: BEYER WEAVER & THOMAS, LLP, P.O. BOX 70250, OAKLAND, CA 94612-0250
  • Context: Original assignment of inventor rights to the founding corporate entity.

• 2013-04-29 (executed) / recorded 2013-05-09 — Reel 030068/0805

  • Conveyance: SECURITY AGREEMENT
  • Assignor: CHELSIO COMMUNICATIONS, INC.
  • Assignee: EAST WEST BANK
  • Correspondent: EAST WEST BANK, LEGAL SERVICES, 135 N. VISTORIA AVE., MONTEREY PARK, CA 91754
  • Context: Security interest granted to East West Bank.

• 2014-10-14 (executed) / recorded 2014-10-21 — Reel 033333/0859

  • Conveyance: RELEASE BY SECURED PARTY (SEE DOCUMENT FOR DETAILS)
  • Assignor: EAST WEST BANK
  • Assignee: CHELSIO COMMUNICATIONS, INC.
  • Correspondent: MICHAEL T. NOVIRIAN, ESQ., K&L GATES LLP, 4 EMBARCADERO CTR SUITE 1200, SAN FRANCISCO, CA 94111. This correspondent firm, K&L Gates LLP, recurs in this chain.
  • Context: Release of security interest from East West Bank to Chelsio Communications, Inc.

• 2014-10-14 (executed) / recorded 2014-10-21 — Reel 033333/0861

  • Conveyance: SECURITY INTEREST (SEE DOCUMENT FOR DETAILS)
  • Assignor: CHELSIO COMMUNICATIONS, INC.
  • Assignee: SILICON VALLEY BANK
  • Correspondent: MICHAEL T. NOVIRIAN, ESQ., K&L GATES LLP, 4 EMBARCADERO CTR SUITE 1200, SAN FRANCISCO, CA 94111. This correspondent firm, K&L Gates LLP, recurs in this chain.
  • Context: New security interest granted to Silicon Valley Bank.

• 2016-07-01 (executed) / recorded 2016-07-15 — Reel 037989/0984

  • Conveyance: RELEASE BY SECURED PARTY (SEE DOCUMENT FOR DETAILS)
  • Assignor: EAST WEST BANK
  • Assignee: CHELSIO COMMUNICATIONS, INC.
  • Correspondent: CHUNG, DENNIS K., ESQ., K&L GATES LLP, 4 EMBARCADERO CENTER, SUITE 1200, SAN FRANCISCO, CA 94111. This correspondent firm, K&L Gates LLP, recurs in this chain.
  • Context: Another release of security interest from East West Bank to Chelsio Communications, Inc.

• 2016-07-28 (executed) / recorded 2016-07-29 — Reel 038096/0200

  • Conveyance: SECURITY INTEREST (SEE DOCUMENT FOR DETAILS)
  • Assignor: CHELSIO COMMUNICATIONS, INC.
  • Assignee: NOVIRIAN CAPITAL
  • Correspondent: K&L GATES LLP, 4 EMBARCADERO CENTER, SUITE 1200, SAN FRANCISCO, CA 94111. This correspondent firm, K&L Gates LLP, recurs in this chain.
  • Context: New security interest granted to Novirian Capital.

• 2017-04-20 (executed) / recorded 2017-04-25 — Reel 040715/0746

  • Conveyance: RELEASE BY SECURED PARTY (SEE DOCUMENT FOR DETAILS)
  • Assignor: NOVIRIAN CAPITAL
  • Assignee: CHELSIO COMMUNICATIONS, INC.
  • Correspondent: K&L GATES LLP, 4 EMBARCADERO CENTER, SUITE 1200, SAN FRANCISCO, CA 94111. This correspondent firm, K&L Gates LLP, recurs in this chain.
  • Context: Release of security interest from Novirian Capital to Chelsio Communications, Inc.

• 2019-08-14 (executed) / recorded 2019-08-14 — Reel 046340/0396

  • Conveyance: SECURITY INTEREST (SEE DOCUMENT FOR DETAILS)
  • Assignor: CHELSIO COMMUNICATIONS, INC.
  • Assignee: WESTERN ALLIANCE BANK, AN ARIZONA CORPORATION
  • Correspondent: WESTERN ALLIANCE BANK, 1 E. WASHINGTON STREET, SUITE 1400, PHOENIX, AZ 85004
  • Context: New security interest granted to Western Alliance Bank.

• 2019-08-14 (executed) / recorded 2019-08-15 — Reel 046341/0080

  • 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: WESTERN ALLIANCE BANK, 1 E. WASHINGTON STREET, SUITE 1400, PHOENIX, AZ 85004
  • Context: Corrective assignment related to the security interest with Western Alliance Bank.

• 2025-12-11 (executed) / recorded 2025-12-18 — Reel 055171/0871

  • Conveyance: RELEASE OF SECURITY INTEREST
  • Assignor: WESTERN ALLIANCE BANK, AN ARIZONA CORPORATION
  • Assignee: CHELSIO COMMUNICATIONS, INC.
  • Correspondent: WESTERN ALLIANCE BANK, 1 E. WASHINGTON STREET, SUITE 1400, PHOENIX, AZ 85004
  • Context: Release of security interest from Western Alliance Bank to Chelsio Communications, Inc.

Timeline diagram

timeline
    title Ownership of US 7826350
    2007 : Filed by Chelsio Communications Inc
    2010 : Issued
    2013 : Security agmt East West Bank
    2014 : Release by East West Bank
         : Security agmt Silicon Valley Bank
    2016 : Release by East West Bank
         : Security agmt Novirian Capital
    2017 : Release by Novirian Capital
    2019 : Security agmt Western Alliance Bank
         : Corrective security agmt
    2025 : Release by Western Alliance Bank

NPE / troll-pattern signals

1. Shell-entity transfer — Not present. The patent has consistently been owned by Chelsio Communications, Inc., an operating company. The recorded transfers are all security agreements and their subsequent releases with financial institutions, not transfers of title to shell entities.
2. Known asserter in the chain — Not present. The assignees involved in security agreements (East West Bank, Silicon Valley Bank, Novirian Capital, Western Alliance Bank) are all financial institutions, not known patent assertion entities.
3. Repeat correspondent across the chain — Present. K&L Gates LLP, through attorneys Michael T. Novirian and Dennis K. Chung, is listed as the correspondent for several security agreements and releases (Reel 033333/0859, Reel 033333/0861, Reel 037989/0984, Reel 038096/0200, Reel 040715/0746). This indicates consistent legal representation for Chelsio Communications, Inc.'s financing activities.
4. Cascading transfers — Not present. While there are multiple security agreements, they do not represent transfers of ownership between chained LLCs in quick succession.
5. Pre-litigation transfer — Not present. No litigation involving US 7,826,350 has been found as of May 27, 2026.
6. Bankruptcy fire-sale — Not present. Chelsio Communications, Inc. remains an active operating company.
7. Privateering — Not present. There is no evidence in the assignment records or public information suggesting Chelsio Communications, Inc. has transferred the patent to an NPE to assert on its behalf.
8. Defensive aggregator (anti-NPE) — Not present. The ownership chain does not terminate at a defensive aggregator.

Verdict

Operating-company assertion.

The patent US 7,826,350 is currently owned by its original assignee, Chelsio Communications Inc., which is an active operating company that manufactures products directly embodying the claimed invention. The recorded assignments solely reflect security interests granted to financial institutions and their subsequent releases (e.g., Reel 030068/0805 executed 2013-04-29, Reel 033333/0861 executed 2014-10-14, Reel 046340/0396 executed 2019-08-14). While the definition of "Operating-company assertion" includes "and is suing actual competitors," no litigation involving this patent has been identified in publicly available records, presenting a minor contradiction with the strict definition; however, the ownership pattern strongly indicates an operating company holds the patent for its core business rather than for assertion by an NPE.

USPTO Patent Assignment Search for US7826350

To identify the most relevant prior art for US Patent 7,826,350, I will refer to the "Citations" section of the patent itself, as this typically lists the prior art considered by the examiner during prosecution. The information provided in the prompt already includes a "Citations" list. I will go through each of these citations and summarize their relevance.

Here are the prior art references cited in US Patent 7,826,350, along with their details and potential anticipatory claims:

1. US4445116A

• Full Citation: US4445116A - Method for allocating bandwidth between stations in a local area network
• Publication/Filing Date: Publication: 1984-04-24 / Filing: 1982-03-05
• Brief Description: This patent describes a method for allocating bandwidth among stations in a local area network. While it relates to network communication, its focus is on bandwidth allocation rather than direct data placement or adaptive copy avoidance.
• Potential Anticipation (35 U.S.C. § 102): Unlikely to directly anticipate the core claims of US7826350, which center on intelligent network adaptors, adaptive direct data placement, and host memory management. It might be relevant for background in network communication, but not specific DDP mechanisms.

2. US4533996A

• Full Citation: US4533996A - Peripheral systems accommodation of guest operating systems
• Publication/Filing Date: Publication: 1985-08-06 / Filing: 1982-02-23
• Brief Description: This patent deals with peripheral systems accommodating guest operating systems, likely in a virtualized or multi-OS environment. It doesn't appear to directly address efficient data transfer between a network adaptor and application memory.
• Potential Anticipation (35 U.S.C. § 102): Unlikely to anticipate claims related to direct data placement or adaptive copy avoidance in network adaptors.

3. US5497476A

• Full Citation: US5497476A - Scatter-gather in data processing system
• Publication/Filing Date: Publication: 1996-03-05 / Filing: 1992-09-21
• Brief Description: This patent describes scatter-gather techniques in data processing, which involve collecting data from multiple memory locations (scatter) or distributing data to multiple memory locations (gather) in a single operation. This is foundational to efficient DMA operations, which are relevant to direct data placement.
• Potential Anticipation (35 U.S.C. § 102): Could potentially anticipate aspects of "providing received payload data corresponding to the request directly into host memory for consumption by the application" (Claim 1) or the underlying mechanism for direct data placement, particularly as it relates to managing fragmented memory buffers. However, US7826350's claims further specify adaptive direct data placement and a decision-making process for when to use it, which this patent does not explicitly cover.

4. US5778189A

• Full Citation: US5778189A - System and method for converting communication protocols
• Publication/Filing Date: Publication: 1998-07-07 / Filing: 1996-05-29
• Brief Description: This patent focuses on converting communication protocols. While relevant to network communication, it does not specifically address direct data placement or adaptive schemes for host memory.
• Potential Anticipation (35 U.S.C. § 102): Unlikely to anticipate the core claims of US7826350.

5. US6087581A

• Full Citation: US6087581A - Regenerable thermal insulation and cooling elements insulated thereby
• Publication/Filing Date: Publication: 2000-07-11 / Filing: 1998-06-08
• Brief Description: This patent relates to thermal insulation and cooling elements, which is completely unrelated to network adaptors or data placement.
• Potential Anticipation (35 U.S.C. § 102): No anticipation. This appears to be an irrelevant citation, possibly a clerical error or a very broad search result.

6. US6226680B1

• Full Citation: US6226680B1 - Intelligent network interface system method for protocol processing
• Publication/Filing Date: Publication: 2001-05-01 / Filing: 1997-10-14
• Brief Description: This patent describes an intelligent network interface system and method for protocol processing, specifically mentioning offloading protocol processing to the network interface. This is highly relevant to the "intelligent network adaptor performs protocol processing of the connection" aspect of US7826350.
• Potential Anticipation (35 U.S.C. § 102): Could potentially anticipate the general concept of an "intelligent network adaptor" performing "protocol processing of the connection" as recited in the preambles of all independent claims (e.g., Claim 1). However, it may not detail the adaptive direct data placement scheme specifically.

7. US6240094B1

• Full Citation: US6240094B1 - Statistical time division multiplexer for a wireless asymmetric local loop communication system
• Publication/Filing Date: Publication: 2001-05-29 / Filing: 1997-12-22
• Brief Description: This patent relates to multiplexing in wireless communication systems, which is unrelated to the specific data placement and copy avoidance schemes of US7826350.
• Potential Anticipation (35 C.F.R. § 1.56): No anticipation.

8. US20010010046A1

• Full Citation: US20010010046A1 - Client content management and distribution system
• Publication/Filing Date: Publication: 2001-07-26 / Filing: 1997-09-11
• Brief Description: This patent describes a client content management and distribution system. Its focus appears to be on content delivery rather than the underlying network adaptor mechanisms for data placement.
• Potential Anticipation (35 U.S.C. § 102): Unlikely to anticipate US7826350's specific DDP mechanisms.

9. US20010021949A1

• Full Citation: US20010021949A1 - Network interface device employing a DMA command queue
• Publication/Filing Date: Publication: 2001-09-13 / Filing: 1997-10-14
• Brief Description: This patent describes a network interface device utilizing a DMA command queue. Direct Memory Access (DMA) is a fundamental technology for direct data placement. The use of a command queue suggests intelligence in managing data transfers.
• Potential Anticipation (35 U.S.C. § 102): Highly relevant. This could potentially anticipate aspects of "providing received payload data corresponding to the request directly into host memory for consumption by the application" (Claim 1) by describing the underlying DMA mechanism. The specific "adaptive" decision-making of US7826350 might differentiate it, but the direct placement itself could be challenged.

10. US20020039366A1

• Full Citation: US20020039366A1 - Packet switch and multicasting control system used for the same
• Publication/Filing Date: Publication: 2002-04-04 / Filing: 2000-10-04
• Brief Description: This patent concerns packet switching and multicasting control systems. Its focus is on network infrastructure rather than the end-host network adaptor's data placement.
• Potential Anticipation (35 U.S.C. § 102): Unlikely to anticipate the core claims of US7826350.

11. US6389479B1

• Full Citation: US6389479B1 - Intelligent network interface device and system for accelerated communication
• Publication/Filing Date: Publication: 2002-05-14 / Filing: 1997-10-14
• Brief Description: This patent describes an intelligent network interface device for accelerated communication. Similar to US6226680B1, it highlights the intelligence in the network adaptor to speed up communication.
• Potential Anticipation (35 U.S.C. § 102): Could potentially anticipate the "intelligent network adaptor" performing "protocol processing of the connection" (Claim 1). Specific details of the adaptive direct data placement or the conditional copying might still be distinguishing features for US7826350.

12. US6397316B2

• Full Citation: US6397316B2 - System for reducing bus overhead for communication with a network interface
• Publication/Filing Date: Publication: 2002-05-28 / Filing: 1997-07-24
• Brief Description: This patent describes a system for reducing bus overhead in communication with a network interface. This relates to the efficiency of data transfer, a goal of US7826350.
• Potential Anticipation (35 U.S.C. § 102): Could be relevant to the general objective of reducing overhead in data transfer, but not necessarily the adaptive direct data placement or conditional copying mechanisms that define US7826350.

13. US6401177B1

• Full Citation: US6401177B1 - Memory system for restructuring a main memory unit in a general-purpose computer
• Publication/Filing Date: Publication: 2002-06-04 / Filing: 1998-04-28
• Brief Description: This patent describes a memory system for restructuring main memory. While memory management is broadly related, it does not specifically address network adaptor-initiated direct data placement or adaptive schemes.
• Potential Anticipation (35 U.S.C. § 102): Unlikely to anticipate US7826350's specific DDP mechanisms.

14. US6427173B1

• Full Citation: US6427173B1 - Intelligent network interfaced device and system for accelerated communication
• Publication/Filing Date: Publication: 2002-07-30 / Filing: 1997-10-14
• Brief Description: This patent is another one from Alacritech, Inc. (assignee for several highly relevant citations) concerning intelligent network interface devices for accelerated communication. It is a continuation or related to previously mentioned Alacritech patents.
• Potential Anticipation (35 U.S.C. § 102): Highly likely to be relevant for the "intelligent network adaptor" and "protocol processing" aspects (e.g., Claim 1 preamble). The specific adaptive nature of US7826350's DDP would be key to distinguishing it.

15. US6427171B1

• Full Citation: US6427171B1 - Protocol processing stack for use with intelligent network interface device
• Publication/Filing Date: Publication: 2002-07-30 / Filing: 1997-10-14
• Brief Description: This patent specifically describes a protocol processing stack designed for use with an intelligent network interface device. This directly supports the idea of offloading protocol processing to the adaptor.
• Potential Anticipation (35 U.S.C. § 102): Highly relevant to the "intelligent network adaptor performs protocol processing of the connection" (Claim 1 preamble). Similar to other Alacritech patents, it may not detail the adaptive direct data placement scheme.

16. US6434620B1

• Full Citation: US6434620B1 - TCP/IP offload network interface device
• Publication/Filing Date: Publication: 2002-08-13 / Filing: 1998-08-27
• Brief Description: This patent describes a TCP/IP offload network interface device (TOE). This directly addresses the concept of an "intelligent network adaptor" performing "protocol processing of the connection" for TCP/IP, as explicitly mentioned in US7826350.
• Potential Anticipation (35 U.S.C. § 102): Extremely relevant. This patent could potentially anticipate the "intelligent network adaptor performs protocol processing of the connection" (Claim 1 preamble). The specific adaptive direct data placement based on input request characteristics and buffer size would be the primary distinguishing feature for US7826350's claims.

17. US6470415B1

• Full Citation: US6470415B1 - Queue system involving SRAM head, SRAM tail and DRAM body
• Publication/Filing Date: Publication: 2002-10-22 / Filing: 1999-10-13
• Brief Description: This patent describes a queue system using different types of memory (SRAM and DRAM). This relates to efficient data buffering, which is an aspect of managing network data.
• Potential Anticipation (35 U.S.C. § 102): While related to efficient data handling, it is unlikely to anticipate the specific adaptive direct data placement or copy avoidance decision-making of US7826350.

18. US20020191622A1

• Full Citation: US20020191622A1 - System for and method of differentiated queuing in a routing system
• Publication/Filing Date: Publication: 2002-12-19 / Filing: 2001-06-18
• Brief Description: This patent application describes differentiated queuing in a routing system, focusing on managing network traffic quality of service.
• Potential Anticipation (35 U.S.C. § 102): Unlikely to anticipate US7826350's specific DDP mechanisms for end-host application data.

19. US6510164B1

• Full Citation: US6510164B1 - User-level dedicated interface for IP applications in a data packet switching and load balancing system
• Publication/Filing Date: Publication: 2003-01-21 / Filing: 1998-11-16
• Brief Description: This patent describes a user-level interface for IP applications. This could be relevant to how applications interact with network data, potentially enabling more direct access.
• Potential Anticipation (35 U.S.C. § 102): Could be relevant to the idea of applications accessing network data more directly. However, it may not detail the intelligent network adaptor's decision-making for direct placement or adaptive copy avoidance.

20. US20030018516A1

• Full Citation: US20030018516A1 - Method for dynamically evaluating projected days of supply of inventory levels in a supply chain
• Publication/Filing Date: Publication: 2003-01-23 / Filing: 2001-07-20
• Brief Description: This patent application is about inventory management in a supply chain, which is completely unrelated to network adaptors or data placement.
• Potential Anticipation (35 U.S.C. § 102): No anticipation. This appears to be an irrelevant citation.

21. US20030035436A1

• Full Citation: US20030035436A1 - Method of allocating bandwidth on request to the stations of a local area network
• Publication/Filing Date: Publication: 2003-02-20 / Filing: 2001-08-09
• Brief Description: This patent application describes a method for allocating bandwidth in a local area network. Similar to US4445116A, its focus is on network resource allocation.
• Potential Anticipation (35 U.S.C. § 102): Unlikely to anticipate the core claims of US7826350.

22. US6591302B2

• Full Citation: US6591302B2 - Fast-path apparatus for receiving data corresponding to a TCP connection
• Publication/Filing Date: Publication: 2003-07-08 / Filing: 1997-10-14
• Brief Description: This patent describes a "fast-path apparatus" for receiving TCP data, again from Alacritech, Inc. This implies efficient and potentially direct handling of TCP traffic.
• Potential Anticipation (35 U.S.C. § 102): Highly relevant. This could anticipate aspects of directly placing data for a TCP connection (e.g., parts of Claim 1, 2, 5, 10, 13, 16). The "adaptive" nature and the decision-making based on input request characteristics and buffer size of US7826350 would be critical for distinguishing its claims.

23. US6594268B1

• Full Citation: US6594268B1 - Adaptive routing system and method for QOS packet networks
• Publication/Filing Date: Publication: 2003-07-15 / Filing: 1999-03-11
• Brief Description: This patent describes an adaptive routing system for Quality of Service (QoS) in packet networks. Its focus is on routing decisions, not end-host data placement.
• Potential Anticipation (35 U.S.C. § 102): Unlikely to anticipate US7826350's specific DDP mechanisms.

24. US6625671B1

• Full Citation: US6625671B1 - Compression of buffered data
• Publication/Filing Date: Publication: 2003-09-23 / Filing: 1999-05-03
• Brief Description: This patent describes the compression of buffered data. While data buffering is a component of network communication, the patent focuses on compression, not the placement of uncompressed application data.
• Potential Anticipation (35 U.S.C. § 102): Unlikely to anticipate US7826350's specific DDP mechanisms.

25. US20030200284A1

• Full Citation: US20030200284A1 - Freeing transmit memory on a network interface device prior to receiving an acknowledgement that transmit data has been received by a remote device
• Publication/Filing Date: Publication: 2003-10-23 / Filing: 2002-04-22
• Brief Description: This patent application describes managing transmit memory on a network interface device. While it relates to network interface memory, its focus is on transmit operations, not receive data placement.
• Potential Anticipation (35 U.S.C. § 102): Unlikely to anticipate US7826350's specific DDP mechanisms for received data.

26. US20030204631A1

• Full Citation: US20030204631A1 - Method to synchronize and upload an offloaded network stack connection with a network stack
• Publication/Filing Date: Publication: 2003-10-30 / Filing: 2002-04-30
• Brief Description: This patent application describes synchronizing and uploading an offloaded network stack connection. This is highly relevant to intelligent network adaptors that offload protocol processing.
• Potential Anticipation (35 U.S.C. § 102): Relevant to the concept of offloading network stack connections (Claim 1 preamble). It could potentially anticipate aspects of an intelligent network adaptor performing protocol processing.

27. US6658480B2

• Full Citation: US6658480B2 - Intelligent network interface system and method for accelerated protocol processing
• Publication/Filing Date: Publication: 2003-12-02 / Filing: 1997-10-14
• Brief Description: Another patent from Alacritech, Inc., describing an intelligent network interface system for accelerated protocol processing. This is a recurring theme in the Alacritech prior art.
• Potential Anticipation (35 U.S.C. § 102): Highly relevant to the "intelligent network adaptor" and "protocol processing" aspects (Claim 1 preamble).

28. US20040003094A1

• Full Citation: US20040003094A1 - Method and apparatus for mirroring traffic over a network
• Publication/Filing Date: Publication: 2004-01-01 / Filing: 2002-06-27
• Brief Description: This patent application describes mirroring traffic over a network, which relates to network monitoring and duplication, not efficient end-host data placement.
• Potential Anticipation (35 U.S.C. § 102): Unlikely to anticipate US7826350's specific DDP mechanisms.

29. US6681244B1

• Full Citation: US6681244B1 - System and method for operating a network adapter when an associated network computing system is in a low-power state
• Publication/Filing Date: Publication: 2004-01-20 / Filing: 2000-06-09
• Brief Description: This patent describes operating a network adaptor in a low-power state. This is focused on power management, not data placement efficiency.
• Potential Anticipation (35 U.S.C. § 102): Unlikely to anticipate US7826350's specific DDP mechanisms.

30. US20040019689A1

• Full Citation: US20040019689A1 - System and method for managing multiple stack environments
• Publication/Filing Date: Publication: 2004-01-29 / Filing: 2002-07-26
• Brief Description: This patent application describes managing multiple network stack environments. This is related to network software architecture, but not specifically to adaptive data placement.
• Potential Anticipation (35 U.S.C. § 102): Unlikely to anticipate US7826350's specific DDP mechanisms.

31. US6687758B2

• Full Citation: US6687758B2 - Port aggregation for network connections that are offloaded to network interface devices
• Publication/Filing Date: Publication: 2004-02-03 / Filing: 2001-03-07
• Brief Description: This patent describes port aggregation for offloaded network connections. This is relevant to intelligent network adaptors and offloading, but not directly to the adaptive data placement scheme.
• Potential Anticipation (35 U.S.C. § 102): Could be relevant to the general concept of offloading, but less so to the specific adaptive DDP of US7826350.

32. US20040028069A1

• Full Citation: US20040028069A1 - Event bus with passive queuing and active routing
• Publication/Filing Date: Publication: 2004-02-12 / Filing: 2002-08-07
• Brief Description: This patent application describes an event bus with queuing and routing. While it involves data flow and queuing, it's not directly related to intelligent network adaptor DDP.
• Potential Anticipation (35 U.S.C. § 102): Unlikely to anticipate US7826350's specific DDP mechanisms.

33. US6697868B2

• Full Citation: US6697868B2 - Protocol processing stack for use with intelligent network interface device
• Publication/Filing Date: Publication: 2004-02-24 / Filing: 2000-02-28
• Brief Description: Another patent from Alacritech, Inc., on protocol processing stacks for intelligent network interface devices. Similar to US6427171B1 and US6226680B1.
• Potential Anticipation (35 U.S.C. § 102): Highly relevant to the "intelligent network adaptor performs protocol processing of the connection" (Claim 1 preamble).

34. US6701372B2

• Full Citation: US6701372B2 - Data communication apparatus and method
• Publication/Filing Date: Publication: 2004-03-02 / Filing: 1997-08-22
• Brief Description: This patent describes a general data communication apparatus and method. The description is broad, and it's unclear without further review if it specifically addresses direct data placement or adaptive copy avoidance.
• Potential Anticipation (35 U.S.C. § 102): Broadly related, but specific anticipation of US7826350's DDP claims is unlikely without more detail.

35. US20040042487A1

• Full Citation: US20040042487A1 - Network traffic accelerator system and method
• Publication/Filing Date: Publication: 2004-03-04 / Filing: 2002-08-19
• Brief Description: This patent application describes a network traffic accelerator system. This aims to improve network performance, a goal shared by US7826350.
• Potential Anticipation (35 U.S.C. § 102): Could be relevant to the general objective of accelerated network communication, but likely lacks the specific adaptive DDP mechanisms of US7826350.

36. US6708223B1

• Full Citation: US6708223B1 - Accelerating a distributed component architecture over a network using a modified RPC communication
• Publication/Filing Date: Publication: 2004-03-16 / Filing: 1998-12-11
• Brief Description: This patent focuses on accelerating distributed component architecture using modified RPC (Remote Procedure Call) communication. This is at a higher software layer than the network adaptor's data placement.
• Potential Anticipation (35 U.S.C. § 102): Unlikely to anticipate US7826350's specific DDP mechanisms.

37. US6708232B2

• Full Citation: US6708232B2 - Data migration method, protocol converter and switching apparatus using it
• Publication/Filing Date: Publication: 2004-03-16 / Filing: 2000-06-29
• Brief Description: This patent describes a data migration method, protocol converter, and switching apparatus. Its focus is on data movement within a system, potentially relevant to data transfer.
• Potential Anticipation (35 U.S.C. § 102): Could be broadly relevant to data movement, but the specifics of adaptive direct data placement by an intelligent network adaptor for application consumption would likely be distinguishing.

38. US20040054813A1

• Full Citation: US20040054813A1 - TCP offload network interface device
• Publication/Filing Date: Publication: 2004-03-18 / Filing: 1997-10-14
• Brief Description: Another Alacritech, Inc. patent application concerning a TCP offload network interface device. This reinforces the existence of TOEs as prior art.
• Potential Anticipation (35 U.S.C. § 102): Highly relevant to the "intelligent network adaptor performs protocol processing of the connection" (Claim 1 preamble) for TCP/IP.

39. US20040064578A1

• Full Citation: US20040064578A1 - Fast-path apparatus for receiving data corresponding to a TCP connection
• Publication/Filing Date: Publication: 2004-04-01 / Filing: 2002-09-27
• Brief Description: Yet another Alacritech, Inc. patent application describing a "fast-path apparatus" for receiving TCP data. This emphasizes efficient TCP reception.
• Potential Anticipation (35 U.S.C. § 102): Highly relevant to efficient TCP reception and potentially direct data placement for TCP connections (parts of Claim 1, 2, 5, 10, 13, 16).

40. US20040064590A1

• Full Citation: US20040064590A1 - Intelligent network storage interface system
• Publication/Filing Date: Publication: 2004-04-01 / Filing: 2000-09-29
• Brief Description: This patent application describes an intelligent network storage interface system. This could involve direct data placement to storage, which is analogous to direct data placement to host application memory.
• Potential Anticipation (35 U.S.C. § 102): Could be relevant to the general concept of direct data placement from an intelligent network interface to a destination, but the specific adaptive decision-making for application memory of US7826350 would be a distinguishing factor.

41. US20040062245A1

• Full Citation: US20040062245A1 - TCP/IP offload device
• Publication/Filing Date: Publication: 2004-04-01 / Filing: 2002-04-22
• Brief Description: This patent application describes a TCP/IP offload device. Further evidence of TOE as prior art.
• Potential Anticipation (35 U.S.C. § 102): Highly relevant to the "intelligent network adaptor performs protocol processing of the connection" (Claim 1 preamble) for TCP/IP.

42. US6717946B1

• Full Citation: US6717946B1 - Methods and apparatus for mapping ranges of values into unique values of particular use for range matching operations using an associative memory
• Publication/Filing Date: Publication: 2004-04-06 / Filing: 2002-10-31
• Brief Description: This patent describes methods for mapping ranges of values using associative memory. This is generally related to data lookup and processing, but not specifically to adaptive data placement.
• Potential Anticipation (35 U.S.C. § 102): Unlikely to anticipate US7826350's specific DDP mechanisms.

43. US20040073703A1

• Full Citation: US20040073703A1 - Fast-path apparatus for receiving data corresponding a TCP connection
• Publication/Filing Date: Publication: 2004-04-15 / Filing: 1997-10-14
• Brief Description: Another Alacritech, Inc. patent application on a "fast-path apparatus" for receiving TCP data.
• Potential Anticipation (35 U.S.C. § 102): Highly relevant to efficient TCP reception and potentially direct data placement for TCP connections (parts of Claim 1, 2, 5, 10, 13, 16).

44. US20040078480A1

• Full Citation: US20040078480A1 - Parsing a packet header
• Publication/Filing Date: Publication: 2004-04-22 / Filing: 1997-10-14
• Brief Description: This patent application describes parsing a packet header. This is a fundamental operation in network protocol processing performed by the intelligent network adaptor.
• Potential Anticipation (35 U.S.C. § 102): Relevant to the "protocol processing" aspect (Claim 1 preamble), but not directly to the adaptive data placement.

45. US20040088262A1

• Full Citation: US20040088262A1 - Enabling an enhanced function of an electronic device
• Publication/Filing Date: Publication: 2004-05-06 / Filing: 2002-11-06
• Brief Description: This patent application describes enabling enhanced functions of an electronic device. This is a very broad description and unlikely to be specifically anticipatory.
• Potential Anticipation (35 U.S.C. § 102): Unlikely to anticipate US7826350's specific DDP mechanisms.

46. US6757746B2

• Full Citation: US6757746B2 - Obtaining a destination address so that a network interface device can write network data without headers directly into host memory
• Publication/Filing Date: Publication: 2004-06-29 / Filing: 1997-10-14
• Brief Description: This patent specifically describes obtaining a destination address for a network interface device to write network data without headers directly into host memory. This is a direct description of direct data placement (DDP).
• Potential Anticipation (35 U.S.C. § 102): Extremely relevant. This patent could potentially anticipate the core concept of "providing received payload data corresponding to the request directly into host memory for consumption by the application" (Claim 1, and similar clauses in other independent claims). The "adaptive" decision-making of US7826350 and the conditional copying of data based on input request characteristics (e.g., buffer size) would be the primary distinguishing features.

47. US6757245B1

• Full Citation: US6757245B1 - Apparatus, and associated method, for communicating packet data in a network including a radio-link
• Publication/Filing Date: Publication: 2004-06-29 / Filing: 2000-06-01
• Brief Description: This patent describes communicating packet data in a network with a radio link. This is focused on wireless communication, not direct data placement in an end-host.
• Potential Anticipation (35 U.S.C. § 102): Unlikely to anticipate US7826350's specific DDP mechanisms.

48. US20040158640A1

• Full Citation: US20040158640A1 - Transferring control of a TCP connection between devices
• Publication/Filing Date: Publication: 2004-08-12 / Filing: 1997-10-14
• Brief Description: This patent application describes transferring control of a TCP connection, which is relevant to managing offloaded connections.
• Potential Anticipation (35 U.S.C. § 102): Could be relevant to the general management of offloaded connections, but not directly to the adaptive DDP scheme.

49. US20040165592A1

• Full Citation: US20040165592A1 - Extended virtual user-to-network interface with ATM network
• Publication/Filing Date: Publication: 2004-08-26 / Filing: 2003-02-21
• Brief Description: This patent application describes an extended virtual user-to-network interface with an ATM network. This is related to network interface architecture, but not directly to adaptive data placement.
• Potential Anticipation (35 U.S.C. § 102): Unlikely to anticipate US7826350's specific DDP mechanisms.

50. US6792502B1

• Full Citation: US6792502B1 - Microprocessor having a content addressable memory (CAM) device as a functional unit therein and method of operation
• Publication/Filing Date: Publication: 2004-09-14 / Filing: 2000-10-12
• Brief Description: This patent describes a microprocessor with content addressable memory (CAM). This is a hardware component for fast lookups, generally useful in network processing but not specific to adaptive DDP.
• Potential Anticipation (35 U.S.C. § 102): Unlikely to anticipate US7826350's specific DDP mechanisms.

51. US6798743B1

• Full Citation: US6798743B1 - Packet prioritization processing technique for routing traffic in a packet-switched computer network
• Publication/Filing Date: Publication: 2004-09-28 / Filing: 1999-03-22
• Brief Description: This patent describes packet prioritization for routing traffic. This is a network-level traffic management technique.
• Potential Anticipation (35 U.S.C. § 102): Unlikely to anticipate US7826350's specific DDP mechanisms.

52. US20040190533A1

• Full Citation: US20040190533A1 - Method and apparatus for performing connection management with multiple stacks
• Publication/Filing Date: Publication: 2004-09-30 / Filing: 2003-03-27
• Brief Description: This patent application describes connection management with multiple network stacks. This is relevant to managing network connections but not directly to adaptive data placement.
• Potential Anticipation (35 U.S.C. § 102): Unlikely to anticipate US7826350's specific DDP mechanisms.

53. US20040199808A1

• Full Citation: US20040199808A1 - State recovery and failover of intelligent network adapters
• Publication/Filing Date: Publication: 2004-10-07 / Filing: 2003-04-02
• Brief Description: This patent application describes state recovery and failover for intelligent network adaptors. This is about reliability, not data placement efficiency.
• Potential Anticipation (35 U.S.C. § 102): Unlikely to anticipate US7826350's specific DDP mechanisms.

54. US6807581B1

• Full Citation: US6807581B1 - Intelligent network storage interface system
• Publication/Filing Date: Publication: 2004-10-19 / Filing: 2000-09-29
• Brief Description: Another Alacritech, Inc. patent on intelligent network storage interface systems. Similar to US20040064590A1.
• Potential Anticipation (35 U.S.C. § 102): Could be relevant to the general concept of direct data placement from an intelligent network interface to a destination, but the specific adaptive decision-making for application memory of US7826350 would be a distinguishing factor.

55. US20040213235A1

• Full Citation: US20040213235A1 - Programmable packet classification system using an array of uniform content-addressable memories
• Publication/Filing Date: Publication: 2004-10-28 / Filing: 2003-04-08
• Brief Description: This patent application describes a programmable packet classification system using CAMs. This is about efficient packet filtering and classification, which is part of protocol processing, but not specifically DDP or adaptive copy.
• Potential Anticipation (35 U.S.C. § 102): Relevant to "protocol processing" (Claim 1 preamble) but not to the adaptive DDP.

56. US6813652B2

• Full Citation: US6813652B2 - Reduced-overhead DMA
• Publication/Filing Date: Publication: 2004-11-02 / Filing: 2001-04-11
• Brief Description: This patent describes reduced-overhead DMA, which is a key component of efficient direct data placement.
• Potential Anticipation (35 U.S.C. § 102): Highly relevant. This could anticipate aspects of "providing received payload data corresponding to the request directly into host memory for consumption by the application" (Claim 1) by describing optimized DMA for direct data transfer. The "adaptive" decision-making of US7826350, particularly based on buffer size and input request characteristics, would likely be the distinguishing element.

57. US6862648B2

• Full Citation: US6862648B2 - Interface emulation for storage devices
• Publication/Filing Date: Publication: 2005-03-01 / Filing: 2000-10-30
• Brief Description: This patent describes interface emulation for storage devices. While data transfer to storage is analogous to host memory, the focus is on emulation.
• Potential Anticipation (35 U.S.C. § 102): Unlikely to anticipate US7826350's specific DDP mechanisms for application memory.

58. US20050083935A1

• Full Citation: US20050083935A1 - Method and apparatus for two-stage packet classification using most specific filter matching and transport level sharing
• Publication/Filing Date: Publication: 2005-04-21 / Filing: 2003-10-20
• Brief Description: This patent application describes a method for two-stage packet classification. This is relevant to protocol processing (filtering), but not directly to adaptive data placement.
• Potential Anticipation (35 U.S.C. § 102): Relevant to "protocol processing" (Claim 1 preamble) but not to the adaptive DDP.

59. US20050120037A1

• Full Citation: US20050120037A1 - Apparatus and method for managing network storage, and computer product
• Publication/Filing Date: Publication: 2005-06-02 / Filing: 2002-07-16
• Brief Description: This patent application describes managing network storage. Similar to other storage-related citations, it's analogous but not directly for host application memory.
• Potential Anticipation (35 U.S.C. § 102): Could be broadly relevant to data management in a network context, but the specific adaptive decision-making for application memory of US7826350 would be a distinguishing factor.

60. US20050125195A1

• Full Citation: US20050125195A1 - Method, apparatus and sofware for network traffic management
• Publication/Filing Date: Publication: 2005-06-09 / Filing: 2001-12-21
• Brief Description: This patent application describes network traffic management. This is a general area of network efficiency.
• Potential Anticipation (35 U.S.C. § 102): Unlikely to anticipate US7826350's specific DDP mechanisms.

61. US20050135378A1

• Full Citation: US20050135378A1 - Service aware policer with efficient handling of in-profile traffic
• Publication/Filing Date: Publication: 2005-06-23 / Filing: 2003-12-22
• Brief Description: This patent application describes a "service aware policer" for network traffic, focusing on QoS and traffic shaping.
• Potential Anticipation (35 U.S.C. § 102): Unlikely to anticipate US7826350's specific DDP mechanisms.

62. US20050135412A1

• Full Citation: US20050135412A1 - Method and system for transmission control protocol (TCP) retransmit processing
• Publication/Filing Date: Publication: 2005-06-23 / Filing: 2003-12-19
• Brief Description: This patent application describes TCP retransmit processing. This is a specific aspect of TCP protocol processing.
• Potential Anticipation (35 U.S.C. § 102): Relevant to "protocol processing" (Claim 1 preamble) but not directly to the adaptive DDP.

63. US20050147126A1

• Full Citation: US20050147126A1 - Method and system for transmission control packet (TCP) segmentation offload
• Publication/Filing Date: Publication: 2005-07-07 / Filing: 2004-01-06
• Brief Description: This patent application describes TCP segmentation offload (TSO), where the network adaptor handles segmenting large data blocks for TCP. This is a form of protocol offload.
• Potential Anticipation (35 U.S.C. § 102): Relevant to the concept of offloading protocol processing (Claim 1 preamble), but not directly to the receive side adaptive DDP or copy avoidance.

64. US6925055B1

• Full Citation: US6925055B1 - Systems and methods for traffic shaping
• Publication/Filing Date: Publication: 2005-08-02 / Filing: 2001-03-05
• Brief Description: This patent describes systems and methods for traffic shaping. This is a network traffic management technique.
• Potential Anticipation (35 U.S.C. § 102): Unlikely to anticipate US7826350's specific DDP mechanisms.

65. US20050190787A1

• Full Citation: US20050190787A1 - Encoding a TCP offload engine within FCP
• Publication/Filing Date: Publication: 2005-09-01 / Filing: 2004-02-27
• Brief Description: This patent application describes encoding a TCP offload engine within Fibre Channel Protocol (FCP). This is relevant to TOE technology.
• Potential Anticipation (35 U.S.C. § 102): Relevant to the concept of TCP offload (Claim 1 preamble).

66. US20050216597A1

• Full Citation: US20050216597A1 - Message context based TCP transmission
• Publication/Filing Date: Publication: 2005-09-29 / Filing: 2004-03-24
• Brief Description: This patent application describes message context-based TCP transmission. This relates to how TCP data is handled at a higher level, not directly to direct placement in host memory.
• Potential Anticipation (35 U.S.C. § 102): Unlikely to anticipate US7826350's specific DDP mechanisms for received data.

67. US20050259678A1

• Full Citation: US20050259678A1 - Network interface controller circuitry
• Publication/Filing Date: Publication: 2005-11-24 / Filing: 2004-05-21
• Brief Description: This patent application describes network interface controller circuitry. This is a general description of NIC hardware.
• Potential Anticipation (35 U.S.C. § 102): Could be broadly relevant to the hardware of an "intelligent network adaptor" but unlikely to anticipate the specific DDP and adaptive copy logic.

68. US20050259644A1

• Full Citation: US20050259644A1 - System and method for defeating SYN attacks
• Publication/Filing Date: Publication: 2005-11-24 / Filing: 2004-05-18
• Brief Description: This patent application describes a system for defeating SYN attacks (a type of denial-of-service attack). This is a security feature, not related to data placement efficiency.
• Potential Anticipation (35 U.S.C. § 102): Unlikely to anticipate US7826350's specific DDP mechanisms.

69. US20050289246A1

• Full Citation: US20050289246A1 - Interpreting I/O operation requests from pageable guests without host intervention
• Publication/Filing Date: Publication: 2005-12-29 / Filing: 2004-05-27
• Brief Description: This patent application describes interpreting I/O requests from virtualized "guests" without host intervention. This touches on I/O efficiency and guest/host interaction, which is somewhat related to direct data transfer to applications.
• Potential Anticipation (35 U.S.C. § 102): Could be relevant to the idea of reducing host intervention in I/O, which is a goal of DDP. However, the specific adaptive decision-making based on application request characteristics (e.g., buffer size) in the context of network data would need to be considered carefully.

70. US6996070B2

• Full Citation: US6996070B2 - TCP/IP offload device with reduced sequential processing
• Publication/Filing Date: Publication: 2006-02-07 / Filing: 2003-12-05
• Brief Description: This patent describes a TCP/IP offload device designed for reduced sequential processing. This aims for performance improvement in TOEs.
• Potential Anticipation (35 U.S.C. § 102): Relevant to the concept of TCP offload (Claim 1 preamble) and efficient processing within a TOE.

71. US20060031524A1

• Full Citation: US20060031524A1 - Apparatus and method for supporting connection establishment in an offload of network protocol processing
• Publication/Filing Date: Publication: 2006-02-09 / Filing: 2004-07-14
• Brief Description: This patent application describes supporting connection establishment in an offloaded network protocol processing environment. This is relevant to the "intelligent network adaptor performs protocol processing of the connection" (Claim 1 preamble).
• Potential Anticipation (35 U.S.C. § 102): Relevant to offloaded protocol processing (Claim 1 preamble).

72. US20060039413A1

• Full Citation: US20060039413A1 - Apparatus and method for compression-transmitting and decoding picture information and storage medium stored its control programs
• Publication/Filing Date: Publication: 2006-02-23 / Filing: 1999-09-10
• Brief Description: This patent application describes compression and decoding of picture information. This is focused on media processing, not network data placement.
• Potential Anticipation (35 U.S.C. § 102): No anticipation.

73. US20060075119A1

• Full Citation: US20060075119A1 - TCP host
• Publication/Filing Date: Publication: 2006-04-06 / Filing: 2004-09-10
• Brief Description: This patent application describes a TCP host. This is a general term, and without more detail, its specific relevance to adaptive DDP is unclear.
• Potential Anticipation (35 U.S.C. § 102): Broadly related to TCP, but unlikely to anticipate the specific adaptive DDP mechanisms.

74. US20060080733A1

• Full Citation: US20060080733A1 - Offline analysis of packets
• Publication/Filing Date: Publication: 2006-04-13 / Filing: 2004-10-08
• Brief Description: This patent application describes offline analysis of packets, which is a diagnostic or monitoring function.
• Potential Anticipation (35 U.S.C. § 102): Unlikely to anticipate US7826350's specific DDP mechanisms.

75. US7031267B2

• Full Citation: US7031267B2 - PLD-based packet filtering methods with PLD configuration data update of filtering rules
• Publication/Filing Date: Publication: 2006-04-18 / Filing: 2000-12-21
• Brief Description: This patent describes PLD-based packet filtering. This is a hardware-based packet processing technique, relevant to an "intelligent" adaptor's capabilities.
• Potential Anticipation (35 U.S.C. § 102): Relevant to "protocol processing" (Claim 1 preamble) but not directly to the adaptive DDP.

76. US7042898B2

• Full Citation: US7042898B2 - Reducing delays associated with inserting a checksum into a network message
• Publication/Filing Date: Publication: 2006-05-09 / Filing: 1997-10-14
• Brief Description: This patent describes reducing delays associated with checksum insertion. This is a performance optimization for network processing.
• Potential Anticipation (35 U.S.C. § 102): Relevant to optimizing network processing (Claim 1 preamble) but not directly to the adaptive DDP.

77. US20060133267A1

• Full Citation: US20060133267A1 - Processing platform selection method for data packet filter installation
• Publication/Filing Date: Publication: 2006-06-22 / Filing: 2004-12-21
• Brief Description: This patent application describes a method for selecting a processing platform for data packet filter installation. This relates to network processing architecture.
• Potential Anticipation (35 U.S.C. § 102): Unlikely to anticipate US7826350's specific DDP mechanisms.

78. US7076568B2

• Full Citation: US7076568B2 - Data communication apparatus for computer intelligent network interface card which transfers data between a network and a storage device according designated uniform datagram protocol socket
• Publication/Filing Date: Publication: 2006-07-11 / Filing: 1997-10-14
• Brief Description: This patent describes a data communication apparatus for an intelligent network interface card that transfers data between a network and a storage device. This is highly relevant to direct data placement, particularly to a storage device.
• Potential Anticipation (35 U.S.C. § 102): Highly relevant. This patent describes DDP to a storage device, which is analogous to DDP to host application memory. This could potentially anticipate the broad concept of direct data placement (Claim 1) but again, the adaptive decision-making based on application request characteristics and buffer size would be key for distinguishing US7826350.

79. US20060168649A1

• Full Citation: US20060168649A1 - Method and system for addressing attacks on a computer connected to a network
• Publication/Filing Date: Publication: 2006-07-27 / Filing: 2004-10-26
• Brief Description: This patent application describes methods for addressing network attacks. This is a security feature.
• Potential Anticipation (35 U.S.C. § 102): Unlikely to anticipate US7826350's specific DDP mechanisms.

80. US7089326B2

• Full Citation: US7089326B2 - Fast-path processing for receiving data on TCP connection offload devices
• Publication/Filing Date: Publication: 2006-08-08 / Filing: 1997-10-14
• Brief Description: Another Alacritech, Inc. patent on "fast-path processing" for receiving TCP data on offload devices. This is a strong prior art for efficient TCP reception by TOEs.
• Potential Anticipation (35 U.S.C. § 102): Highly relevant. This patent could potentially anticipate efficient TCP reception and potentially direct data placement for TCP connections (parts of Claim 1, 2, 5, 10, 13, 16).

81. US7093099B2

• Full Citation: US7093099B2 - Native lookup instruction for file-access processor searching a three-level lookup cache for variable-length keys
• Publication/Filing Date: Publication: 2006-08-15 / Filing: 2002-12-12
• Brief Description: This patent describes a native lookup instruction for a file-access processor. This relates to file system processing and caching, not directly to network adaptor DDP.
• Potential Anticipation (35 U.S.C. § 102): Unlikely to anticipate US7826350's specific DDP mechanisms.

82. US20060206300A1

• Full Citation: US20060206300A1 - VM network traffic monitoring and filtering on the host
• Publication/Filing Date: Publication: 2006-09-14 / Filing: 2005-03-11
• Brief Description: This patent application describes VM network traffic monitoring and filtering on the host. This relates to virtualization and network security/management.
• Potential Anticipation (35 U.S.C. § 102): Unlikely to anticipate US7826350's specific DDP mechanisms.

83. US20060209693A1

• Full Citation: US20060209693A1 - Feedback priority modulation rate controller
• Publication/Filing Date: Publication: 2006-09-21 / Filing: 2001-01-31
• Brief Description: This patent application describes a feedback priority modulation rate controller. This relates to flow control and prioritization.
• Potential Anticipation (35 U.S.C. § 102): Could be broadly relevant to flow control, which is a part of US7826350's description, but not directly to the adaptive DDP decision-making.

84. US20060221946A1

• Full Citation: US20060221946A1 - Connection establishment on a tcp offload engine
• Publication/Filing Date: Publication: 2006-10-05 / Filing: 2005-04-04
• Brief Description: This patent application describes connection establishment on a TCP offload engine. This is a specific aspect of TOE functionality.
• Potential Anticipation (35 U.S.C. § 102): Relevant to the concept of TCP offload (Claim 1 preamble).

85. US7133914B1

• Full Citation: US7133914B1 - Statistics-preserving ACL flattening system and method
• Publication/Filing Date: Publication: 2006-11-07 / Filing: 2001-10-31
• Brief Description: This patent describes an ACL (Access Control List) flattening system. This is a network security/filtering mechanism.
• Potential Anticipation (35 U.S.C. § 102): Unlikely to anticipate US7826350's specific DDP mechanisms.

86. US7133902B2

• Full Citation: US7133902B2 - Transmitting acknowledgements using direct memory access
• Publication/Filing Date: Publication: 2006-11-07 / Filing: 2002-12-17
• Brief Description: This patent describes transmitting acknowledgements using direct memory access. While it mentions DMA, it's for transmitting acknowledgements, not for receiving application data.
• Potential Anticipation (35 U.S.C. § 102): While it mentions DMA, its application is different (transmit vs. receive, acknowledgements vs. application payload). Unlikely to anticipate US7826350's receive side adaptive DDP.

87. US20060281451A1

• Full Citation: US20060281451A1 - Method and system for handling connection setup in a network
• Publication/Filing Date: Publication: 2006-12-14 / Filing: 2005-06-14
• Brief Description: This patent application describes handling connection setup in a network.
• Potential Anticipation (35 U.S.C. § 102): Relevant to connection management, but not directly to adaptive DDP.

88. US20070011358A1

• Full Citation: US20070011358A1 - Mechanisms to implement memory management to enable protocol-aware asynchronous, zero-copy transmits
• Publication/Filing Date: Publication: 2007-01-11 / Filing: 2005-06-30
• Brief Description: This patent application describes memory management for "protocol-aware asynchronous, zero-copy transmits". While it mentions "zero-copy" and "protocol-aware", it is focused on transmit operations, not receive.
• Potential Anticipation (35 U.S.C. § 102): Could be relevant to the general concept of zero-copy, but specifically for transmit, which is distinct from the receive-side adaptive DDP of US7826350.

89. US7167927B2

• Full Citation: US7167927B2 - TCP/IP offload device with fast-path TCP ACK generating and transmitting mechanism
• Publication/Filing Date: Publication: 2007-01-23 / Filing: 1997-10-14
• Brief Description: Another Alacritech, Inc. patent related to TCP/IP offload, specifically for fast-path ACK generation and transmission. This is a transmit-side optimization.
• Potential Anticipation (35 U.S.C. § 102): Relevant to TCP offload, but focused on transmit-side mechanisms, not adaptive receive-side DDP.

90. US7174393B2

• Full Citation: US7174393B2 - TCP/IP offload network interface device
• Publication/Filing Date: Publication: 2007-02-06 / Filing: 2000-12-26
• Brief Description: Another Alacritech, Inc. patent on a TCP/IP offload network interface device.
• Potential Anticipation (35 U.S.C. § 102): Highly relevant to the concept of TCP offload (Claim 1 preamble).

91. US7191241B2

• Full Citation: US7191241B2 - Fast-path apparatus for receiving data corresponding to a TCP connection
• Publication/Filing Date: Publication: 2007-03-13 / Filing: 2002-09-27
• Brief Description: Another Alacritech, Inc. patent on a "fast-path apparatus" for receiving TCP data.
• Potential Anticipation (35 U.S.C. § 102): Highly relevant to efficient TCP reception and potentially direct data placement for TCP connections (parts of Claim 1, 2, 5, 10, 13, 16).

92. US7191318B2

• Full Citation: US7191318B2 - Native copy instruction for file-access processor with copy-rule-based validation
• Publication/Filing Date: Publication: 2007-03-13 / Filing: 2002-12-12
• Brief Description: This patent describes a native copy instruction for a file-access processor. This is related to data movement within a system, but not directly to network adaptor-driven direct data placement.
• Potential Anticipation (35 U.S.C. § 102): Unlikely to anticipate US7826350's specific DDP mechanisms.

93. US20070064737A1

• Full Citation: US20070064737A1 - Receive coalescing and automatic acknowledge in network interface controller
• Publication/Filing Date: Publication: 2007-03-22 / Filing: 2005-09-07
• Brief Description: This patent application describes receive coalescing (grouping multiple small packets into a larger one to reduce interrupts) and automatic acknowledgements in a network interface controller. Receive coalescing is related to reducing host burden, a goal of US7826350.
• Potential Anticipation (35 U.S.C. § 102): Relevant to reducing host notifications (a component of US7826350's system) but not directly to the adaptive decision for direct data placement or copying.

94. US20070070901A1

• Full Citation: US20070070901A1 - Method and system for quality of service and congestion management for converged network interface devices
• Publication/Filing Date: Publication: 2007-03-29 / Filing: 2005-09-29
• Brief Description: This patent application describes QoS and congestion management for converged network interface devices.
• Potential Anticipation (35 U.S.C. § 102): Unlikely to anticipate US7826350's specific DDP mechanisms.

95. US20070083638A1

• Full Citation: US20070083638A1 - Offloaded neighbor cache entry synchronization
• Publication/Filing Date: Publication: 2007-04-12 / Filing: 2005-08-31
• Brief Description: This patent application describes offloaded neighbor cache entry synchronization. This is related to network protocol management.
• Potential Anticipation (35 U.S.C. § 102): Unlikely to anticipate US7826350's specific DDP mechanisms.

96. US20070110436A1

• Full Citation: US20070110436A1 - Primary protocol stack having a secondary protocol stack entry point
• Publication/Filing Date: Publication: 2007-05-17 / Filing: 2005-11-14
• Brief Description: This patent application describes a primary protocol stack with a secondary entry point. This relates to network software architecture.
• Potential Anticipation (35 U.S.C. § 102): Unlikely to anticipate US7826350's specific DDP mechanisms.

97. US7239642B1

• Full Citation: US7239642B1 - Multi-protocol network interface card
• Publication/Filing Date: Publication: 2007-07-03 / Filing: 2001-07-16
• Brief Description: This patent describes a multi-protocol network interface card. This is a general description of NIC capabilities.
• Potential Anticipation (35 U.S.C. § 102): Broadly related to network interface cards, but unlikely to anticipate the specific DDP and adaptive copy logic.

98. US7254637B2

• Full Citation: US7254637B2 - Method to offload a network stack
• Publication/Filing Date: Publication: 2007-08-07 / Filing: 2002-04-30
• Brief Description: This patent describes a method to offload a network stack. This is a core concept for "intelligent network adaptors" that perform "protocol processing of the connection."
• Potential Anticipation (35 U.S.C. § 102): Highly relevant to the "intelligent network adaptor performs protocol processing of the connection" (Claim 1 preamble).

99. US7260631B1

• Full Citation: US7260631B1 - System and method for receiving iSCSI protocol data units
• Publication/Filing Date: Publication: 2007-08-21 / Filing: 2003-12-19
• Brief Description: This patent describes a system and method for receiving iSCSI protocol data units. iSCSI is a protocol that uses TCP/IP and often benefits from offload and DDP.
• Potential Anticipation (35 U.S.C. § 102): Relevant to the application of offload and DDP for specific protocols, but may not detail the adaptive decision-making of US7826350.

100. US20070201474A1

• Full Citation: US20070201474A1 - Device for protection against illegal communications and network system thereof
• Publication/Filing Date: Publication: 2007-08-30 / Filing: 2006-02-28
• Brief Description: This patent application describes a device for protection against illegal communications. This is a security feature.
• Potential Anticipation (35 U.S.C. § 102): Unlikely to anticipate US7826350's specific DDP mechanisms.

101. US7284047B2

• Full Citation: US7284047B2 - System and method for controlling network demand via congestion pricing
• Publication/Filing Date: Publication: 2007-10-16 / Filing: 2001-11-08
• Brief Description: This patent describes a system for controlling network demand via congestion pricing. This is a network management/economic model.
• Potential Anticipation (35 U.S.C. § 102): Unlikely to anticipate US7826350's specific DDP mechanisms.

102. US7313623B2

• Full Citation: US7313623B2 - System and method for TCP/IP offload independent of bandwidth delay product
• Publication/Filing Date: Publication: 2007-12-25 / Filing: 2002-08-30
• Brief Description: This patent describes a system and method for TCP/IP offload. This is a very direct piece of prior art for the "intelligent network adaptor performs protocol processing of the connection" (Claim 1 preamble).
• Potential Anticipation (35 U.S.C. § 102): Highly relevant to the concept of TCP offload (Claim 1 preamble).

103. US20080002731A1

• Full Citation: US20080002731A1 - Full data link bypass
• Publication/Filing Date: Publication: 2008-01-03 / Filing: 2006-06-30
• Brief Description: This patent application describes full data link bypass. This could imply very direct data paths, potentially supporting direct data placement.
• Potential Anticipation (35 U.S.C. § 102): Could be relevant to the idea of minimizing intermediate processing for data, but the "adaptive" decision-making of US7826350 would still be a distinguishing feature.

104. US20080016511A1

• Full Citation: US20080016511A1 - Method and computer program product for offloading processing tasks from software to hardware
• Publication/Filing Date: Publication: 2008-01-17 / Filing: 1998-06-12
• Brief Description: This patent application describes offloading processing tasks from software to hardware. This is a fundamental concept behind intelligent network adaptors and protocol offload.
• Potential Anticipation (35 U.S.C. § 102): Highly relevant to the overarching concept of offloading (Claim 1 preamble), but likely lacks the specific adaptive DDP mechanisms.

105. US20080043750A1

• Full Citation: US20080043750A1 - Apparatus and method for in-line insertion and removal of markers
• Publication/Filing Date: Publication: 2008-02-21 / Filing: 2006-01-19
• Brief Description: This patent application describes in-line insertion and removal of markers. This is a data manipulation technique, not directly related to direct data placement.
• Potential Anticipation (35 U.S.C. § 102): Unlikely to anticipate US7826350's specific DDP mechanisms.

106. US7376147B2

• Full Citation: US7376147B2 - Adaptor supporting different protocols
• Publication/Filing Date: Publication: 2008-05-20 / Filing: 2003-12-18
• Brief Description: This patent describes an adaptor supporting different protocols. This is a general feature of network adaptors.
• Potential Anticipation (35 U.S.C. § 102): Broadly related, but unlikely to anticipate the specific DDP and adaptive copy logic.

107. US7408906B2

• Full Citation: US7408906B2 - Mobile data communications apparatus, methods and computer program products implementing cellular wireless data communications via a wireless
• Publication/Filing Date: Publication: 2008-08-05 / Filing: 2002-02-20
• Brief Description: This patent describes mobile data communications via wireless. This is focused on wireless technology.
• Potential Anticipation (35 U.S.C. § 102): Unlikely to anticipate US7826350's specific DDP mechanisms.

Most Relevant Prior Art Summary:

The most relevant prior art for US Patent 7,826,350 generally falls into two categories:

1. TCP Offload Engines (TOEs) and Intelligent Network Adaptors (INAs) with Protocol Processing: Numerous patents, primarily from Alacritech, Inc., describe INAs and TOEs that perform protocol processing (e.g., US6226680B1, US6389479B1, US6427173B1, US6427171B1, US6434620B1, US6658480B2, US20040054813A1, US20040062245A1, US6697868B2, US7089326B2, US7174393B2, US7191241B2, US7254637B2, US7313623B2). These patents anticipate the general concept of an intelligent network adaptor offloading protocol processing, which is a foundational element in the preamble of all independent claims of US7826350.

2. Direct Data Placement (DDP) and DMA Technologies: Several patents describe mechanisms for direct data placement or reduced-overhead DMA.

   • US6757746B2 is particularly significant as it explicitly discusses a network interface device writing network data without headers directly into host memory. This directly anticipates the core DDP aspect of US7826350.
   • US20010021949A1 describes a network interface device employing a DMA command queue, which is fundamental to direct data placement.
   • US6813652B2 describes reduced-overhead DMA.
   • US5497476A (scatter-gather) and US7076568B2 (DDP to storage) also show related concepts of efficient data movement.

Potential Anticipation under 35 U.S.C. § 102:

The distinguishing features of US7826350, as seen in its independent claims (Claims 1, 2, 5, 10, 13, 16), appear to lie in the adaptive decision-making of whether to use direct data placement and the conditional copying of data when direct placement is not initially possible or optimal. Specifically, Claim 1 highlights "determining whether to configure the intelligent network adaptor to provide received payload data corresponding to the request directly into host memory for consumption by the application; and... determining a destination for the application payload data including determining whether the intelligent network adaptor has been configured for the particular connection such that payload data... is to be provided from the intelligent network adaptor to host memory directly associated with the application... or is provided... to host memory that is not provided for consumption by the application". It further clarifies this determination is based on "a characteristic of an input request by the application" and "an indication of a size of the memory associated with the request". Claims 2, 5, 10, 13, and 16 further detail the conditional copying of data from a temporary (OS-associated or not application-associated) buffer to the application's buffer.

While the Alacritech patents establish the prior art for TOEs and general direct data placement (especially US6757746B2), they do not explicitly teach the adaptive decision-making process for selectively performing direct data placement based on application request characteristics and buffer size, or the specific interplay between direct placement and conditional copying as described in US7826350's claims. Therefore, these prior art references might anticipate the individual components of protocol offloading and direct memory access, but not necessarily the specific adaptive scheme and conditional copying that form the inventive step of US7826350.

Obviousness Analysis under 35 U.S.C. § 103

A patent claim is unpatentable if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art (PHOSITA) to which the claimed invention pertains. The PHOSITA is a hypothetical person, not a genius or an inventor, who possesses ordinary skill, ordinary creativity, and ordinary knowledge in the relevant technical field at the relevant time, and is expected to follow conventional wisdom and apply known techniques in a predictable manner. To demonstrate obviousness, there must be a motivation to combine prior art teachings to arrive at the claimed invention with a reasonable expectation of success. This motivation can exist when references address the same problem and one reference provides a known technique that would suitably address that problem.

The patent US7826350 is directed to an intelligent network adaptor with an adaptive direct data placement scheme, aiming to improve receive data communication efficiency by selectively placing application data directly into application memory and moderating notification rates.

Person Having Ordinary Skill in the Art (PHOSITA)

In the context of US7826350, a PHOSITA would likely be a computer engineer or software developer with experience in network interface card (NIC) design, operating system network stacks, and high-performance data communication. This individual would be familiar with concepts such as TCP/IP offload engines (TOE), direct memory access (DMA), memory management, and various buffering strategies employed in network communication. They would also be aware of the challenges associated with high packet arrival rates, host processor overhead, and data copying latency in high-speed networks, as explicitly stated in the patent's background.

Potential Prior Art Combinations and Motivations

While a comprehensive prior art search is outside the scope of this analysis, based on the patent's own cited prior art and the general state of the art as described, several combinations could lead to an obviousness challenge. The patent itself mentions that "direct data placement (DDP) is known" and "it is now common for network adaptors to implement intelligence for the support of host processing, including to partly or completely offload protocol processing. Such adaptors are sometimes referred to as intelligent network adaptors." This suggests that the individual elements of "intelligent network adaptor" and "direct data placement" were known in the art.

The core innovative aspect of US7826350 lies in the adaptive nature of the direct data placement scheme and the selective provision of application memory information to the intelligent network adaptor (Claim 1), coupled with potential initial copying of data to an OS-associated buffer before direct placement into application memory (Claim 2, 5, 16). The patent also highlights the moderation of notification rates.

Here are potential combinations of prior art and motivations to combine, assuming relevant prior art exists disclosing the individual elements:

Combination 1: Intelligent Network Adaptor + Direct Data Placement (DDP) + Adaptive Buffer Management (e.g., based on buffer size)

• Hypothetical Prior Art 1: A patent or publication disclosing an "intelligent network adaptor" capable of offloading protocol processing (e.g., a TCP Offload Engine or TOE) and generally supporting Direct Data Placement (DDP) to host memory. For instance, US6226680B1 (Alacritech, Inc., "Intelligent network interface system method for protocol processing") and US6434620B1 (Alacritech, Inc., "TCP/IP offload network interface device") are cited references that broadly relate to intelligent network interfaces and TCP/IP offload. While not explicitly detailed in the provided text, it's reasonable to assume these or similar documents would teach the basic concept of an intelligent NIC performing DDP.
• Hypothetical Prior Art 2: A patent or publication disclosing methods for managing host memory buffers for network data, recognizing the overhead associated with data copying versus zero-copy mechanisms, and potentially discussing criteria for choosing between them, such as buffer size. This could come from a general operating system or network driver optimization technique.
• Motivation to Combine: A PHOSITA would be motivated to combine an intelligent network adaptor with DDP capabilities (Prior Art 1) with buffer management strategies (Prior Art 2) to optimize data transfer efficiency. The patent itself identifies the challenge of "memory bandwidth resources to copy application payload data from the operating system buffers to application buffers" and the "tradeoff between the cost of copying packet payload... and overhead cost associated with mapping an application buffer into a chain of memory descriptors (for zero copy)." This explicitly states the problem and the motivation to find an optimal solution. The idea of making an "adaptive copy vs. zero-copy decision... depending on various criteria" (as described in the patent) would be a logical step for a PHOSITA seeking to improve overall performance and reduce host burden. Specifically, using the size of the application buffer as a criterion for this adaptive decision (as claimed in Claim 1) is presented in the patent as a solution to this known tradeoff. If Prior Art 2 teaches this tradeoff and potential criteria, combining it with Prior Art 1 would be obvious.

Combination 2: Intelligent Network Adaptor + DDP + Initial Copy to OS Buffer + Subsequent Direct Placement

• Hypothetical Prior Art 1: As above, an intelligent network adaptor with DDP capabilities.
• Hypothetical Prior Art 2: A patent or publication addressing the scenario where an application may not have a receive buffer posted when data arrives, suggesting temporary storage in adaptor memory or an operating system buffer. The patent explicitly states, "Data that arrives during the time the application has no receive request in place may be saved in some memory—either in memory of the intelligent network adaptor or in host memory (e.g., in memory controlled by the operating system)."
• Motivation to Combine: A PHOSITA, faced with the problem of optimizing data delivery when application buffers are not immediately available (e.g., in synchronous I/O scenarios), would be motivated to combine the DDP capabilities of an intelligent NIC (Prior Art 1) with a strategy for handling temporarily un-posted application buffers (Prior Art 2). The patent describes this as using an operating system buffer "to save the received data" and then copying it to the application buffer when available, while subsequent data for the same request can be directly placed by the adaptor at an offset. This "adaptive copy avoidance" scheme addresses the latency of data transfer while enabling eventual zero-copy for later portions of the data. This combination would be obvious to a PHOSITA looking to minimize idle times and delays and reduce the likelihood of dropping packets, especially in the absence of continuous application buffer availability. The concept of performing the initial copy in parallel with setting up zero-copy for subsequent data (as described in the patent) further reinforces the motivation to improve efficiency.

Combination 3: Intelligent Network Adaptor + Moderated Notification Rate + Application-Level Signaling

• Hypothetical Prior Art 1: An intelligent network adaptor offloading protocol processing and capable of sending notifications to the host.
• Hypothetical Prior Art 2: A patent or publication discussing methods for moderating interrupt rates or host notifications in high-speed network environments, perhaps mentioning batching notifications or using timers. The patent notes that "Interrupt rate moderation schemes are known, but have limited effectiveness."
• Hypothetical Prior Art 3: A patent or publication discussing the interpretation of transport layer (e.g., TCP) control flags (FIN, URG, PSH) or application-level information for signaling important events. The patent explicitly describes how TCP flags "may loosely be considered application level signaling."
• Motivation to Combine: A PHOSITA would be motivated to combine an intelligent network adaptor (Prior Art 1) with known notification moderation techniques (Prior Art 2) to reduce host processing load. To ensure that reducing notifications does not negatively impact application latency or awareness of critical events, a PHOSITA would also incorporate the use of application-level signaling or transport-layer flags (Prior Art 3) to trigger "useful notifications" (as described in the patent). The patent clearly outlines the motivation: "an intelligent reduction in notification rate regarding data received from the network... may improve host system performance without affecting (or with minimal effect on) communication latency." Triggering notifications based on specific TCP flags (FIN, URG, PSH) or when a buffer is full, or a timer elapses (as described in the patent), directly addresses this motivation.

Consideration of Secondary Considerations:
The patent does not provide information regarding secondary considerations of non-obviousness such as commercial success, long-felt need, unexpected results, or industry acquiescence. In the absence of such information, the analysis primarily relies on the content of the prior art and the motivation of a PHOSITA to combine them.

It is important to note that without the specific content of the cited prior art references (or other relevant prior art), these are illustrative combinations. A definitive obviousness determination would require a thorough review of the actual disclosures of the identified prior art.

I'll research the patent term and family information for US 7,826,350. Let me run several searches.

Let me search for more specific patent family and term data.

Patent Term, Continuation, and Family Analysis — US 7,826,350

Ground rule applied: The authoritative source for this patent is the full patent text / Google Patents record supplied in the prompt (fetched 2026-09-25). Where the previously generated sections conflict with that record, I flag the conflict explicitly.

---

1. Patent identification

---

2. Patent Term Adjustment (PTA)

Exact front-page PTA figure: I could not retrieve the verbatim front-page statement ("Notice: Subject to any disclaimer, the term of this patent is extended or adjusted under 35 U.S.C. 154(b) by ___ days") from the sources available. Instead I derive it from the authoritative record:

• Nominal 20-year term (35 U.S.C. § 154(a)(2)): 2007-05-11 + 20 years = 2027-05-11
• Recorded/adjusted expiration (Google Patents): 2028-10-02
• Derived PTA ≈ 510 days (~1 year, 4 months, 21 days)

Breakdown of the derivation (should be treated as an arithmetic estimate, not a USPTO-certified figure):

• 2027-05-11 → 2028-05-11 = 366 days (2028 is a leap year)
• 2028-05-11 → 2028-10-02 = 144 days
• Total = 510 days

This is plausible for an application with ~1,270 days of pendency (3.48 years) — a "B delay" component alone (~174 days beyond the 3-year anniversary) plus "A delay" and any "C delay," less applicant delay, would approach this range.

Caveat: Google Patents' "adjusted expiration" is a computed field. It reflects PTA plus any terminal-disclaimer shortening. I found no evidence of a terminal disclaimer in this record, so the entire 2027-05-11 → 2028-10-02 gap is attributable to PTA. To obtain the certified number, the front page of the printed patent or the USPTO Patent Center "Patent Term Adjustment" determination should be consulted.

---

3. Patent Term Extension (PTE)

No PTE applies and none is possible.

PTE under 35 U.S.C. § 156 (the Hatch-Waxman / Drug Price Competition and Patent Term Restoration Act of 1984) is available only for patents claiming:

• human or animal drugs,
• medical devices,
• food additives, or
• color additives

…where the product underwent a qualifying regulatory review period before commercial marketing. US 7,826,350 claims a network adapter / data-placement method and is therefore categorically ineligible for PTE. There is no PTE and no interim extension on this patent.

---

4. Continuations, divisionals, and CIPs

None. The record shows:

• Priority Applications (1): only US 11/747,650
• Applications Claiming Priority (1): only US 11/747,650
• Family Applications (1): only US 11/747,650

US 7,826,350 is an original, standalone utility filing (application 11/747,650). It is not a continuation, divisional, CIP, or national-stage entry of any earlier application, and no later application in the record claims priority to it. There is likewise no continuation-in-part lineage.

Important distinction — "related" ≠ "continuation." The patent's CROSS REFERENCE section identifies three concurrently-filed sibling applications (not parent/child continuations):

These share the same filing date (2007-05-11), the same inventor group, and the same assignee, but they are independent applications, not continuations/divisionals of 11/747,650, and they do not appear within Google Patents "family ID=43015972" for this patent.

---

5. Related family members

• U.S. family members: US 11/747,650 / US 7,826,350 B1 only.
• Foreign family members: None. Country Status lists only the United States (1). No PCT, EP, or other foreign counterpart is recorded for this application.
• Cited-by (forward) references are largely other Chelsio patents (e.g., US 8,030,655, US 8,139,482, US 8,213,427, US 8,339,952, US 8,686,838, US 8,935,406) — these are cited as prior art against later cases, not family members of 7,826,350.

---

6. Projected expiration date

Conditions on the projected date:

• Subject to timely payment of maintenance fees. Fees are due at 3.5, 7.5, and 11.5 years after issue (i.e., circa 2014-05, 2018-05, and 2022-05). The patent's status is Active, so all three windows have been satisfied; no further maintenance fees remain.
• The 2028-10-02 date is the current "adjusted expiration" of record and is the operative projected expiry.

---

7. Contradictions flagged against earlier-generated sections

The patent record (authoritative per the operating rules) conflicts with two prior sections:

1. Assignment history / NPE verdict. The earlier section concluded ownership "terminates" at Chelsio Communications Inc. and characterized the patent as an "Operating-company assertion." The current patent record, however, lists the Current Assignee as SPEEDNIC LLC, via an "ASSIGNMENT OF ASSIGNOR'S INTEREST" recorded 2026-02-13 (Assignor: Chelsio Communications, Inc.). This is a material ownership change (a transfer of title, not a security interest) that post-dates the earlier sections (which were keyed to dates of 2026-04-26 / 2026-05-27). The NPE/troll-pattern analysis should be re-run against SPEEDNIC LLC.

2. Litigation summary. The earlier section stated no litigation involving US 7,826,350 was found "as of April 26, 2026." The patent record now shows: "Family has litigation — US case filed in Texas Western District Court," case 7:26-cv-00148, and "First worldwide family litigation filed." This contradicts the "no known litigation" finding and is consistent with the 2026-02-13 transfer to SPEEDNIC LLC (a classic pre-assertion acquisition pattern).

Both contradictions should be resolved in favor of the patent record per the stated authority hierarchy.

---

8. Sources and confidence

• Google Patents — US7826350B1 (fetched 2026-09-25): provides the authoritative filing/issue dates, adjusted expiration (2028-10-02), family data (Family ID 43015972, single US family application), country status (US only), and current-assignee/litigation annotations.
• USPTO Patent Assignment Search for US7826350
• USPTO MPEP Ch. 2700 (Patent Terms, Adjustments, and Extensions) — statutory/regulatory basis for PTA (35 U.S.C. § 154(b); 37 C.F.R. §§ 1.702–1.705) and PTE (35 U.S.C. § 156).

Confidence levels:

• No PTE / no continuations / no divisionals / US-only family — high confidence (directly supported by the record).
• Adjusted expiration 2028-10-02 — high confidence (recorded field).
• Derived PTA ≈ 510 days — moderate confidence (arithmetic derivation; the certified front-page PTA figure could not be retrieved and may vary by a day or two if the adjusted-expiration field rounds or reflects any disclaimer not surfaced in the record).

Recommended verification step: Open the printed patent front page or USPTO Patent Center for application 11/747,650 to confirm the exact PTA day-count and to confirm that no terminal disclaimer was filed that would independently shorten the term.

I'll first verify the patent record via search, then build the defensive-disclosure document.

DEFENSIVE DISCLOSURE / PRIOR-ART PUBLICATION

Publication ID: DD-7826350-2026-04-26
Subject patent (identified, not summarized): US 7,826,350 B1 — "Intelligent network adaptor with adaptive direct data placement scheme" (Appl. 11/747,650; filed 2007-05-11; granted 2010-11-02)
Publication date: 2026-04-26
Dedication: To the extent this document constitutes an invention disclosure or technical publication, the author dedicates it to the public domain under CC0 1.0 Universal. No claim of copyright is made in any enabling description, register map, state machine, or diagram herein.

0. Provenance anchors verified against USPTO/public record (not a claim summary)

Conflict flagged: The previously generated "Litigation summary" (as of April 26, 2026) reported "no known litigation." The record above supersedes that finding: the case was filed April 16, 2026, ten days before that statement's cutoff, and title moved to SPEEDNIC LLC by assignment recorded 2026-02-13. This document does not re-summarize the patent; it generates new prior art.

---

1. Axis key and element notation

Elements extended below are labelled for the reader's convenience only (they are not assertions of claim scope):

---

2. Derivative corpus

CORE CLAIM 1 — request-characteristic-driven, adaptively enabled direct placement (E1–E3)

D1.1 — A1 · Hardware Policy Engine Replacing the Driver Heuristic; eMRAM-Resident Policy Table

Enabling description. Replace the host-driver decision with a four-stage pipelined engine instantiated in the NIC receive datapath, adjacent to L4 parsing. Stage 0 assembles a 96-bit feature word: L_app (32-bit posted buffer length), MSS (16), smoothed RTT in ns (24), advertised credit count (16), and per-queue occupancy (8). Stage 1 indexes a 128-entry, 8-way set-associative policy array implemented in 22 nm FD-SOI embedded MRAM (eMRAM), each entry {32-bit threshold mask, 3-bit comparator opcode, 12-bit buffer-length weight, 8-bit RTT weight, 8-bit queue weight, 1-bit sticky-per-connection}. Stage 2 computes, in signed 12-bit saturating arithmetic, S = wL·log2(L_app) + wR·SRTT − wQ·Q. Stage 3 asserts zero_copy_en into control-block bit 47 when S > T_hyst, where a 2-bit up/down hysteresis counter prevents oscillation when the score crosses the threshold. The host driver writes policy entries over a BAR0 doorbell ring; a host-resident shadow copy enables atomic swap under a 32-bit generation counter, and the engine discards entries whose generation is stale. Placement logic reads bit 47 to select between the application descriptor list and the common-pool descriptor list. eMRAM retention (10 yr @ 85 °C, ≤ 3 µJ/write) lets a policy survive ACPI S4 and be revalidated at resume without driver reload, which an SRAM-resident table cannot do.

flowchart TD
    A["Parsed L4 header and request context"] --> B["Stage 0: 96-bit feature word - L_app, MSS, SRTT, credits, queue depth"]
    B --> C["Stage 1: 128-entry 8-way eMRAM policy table - mask, opcode, weights, sticky bit"]
    C --> D["Stage 2: saturating score S = wL*log2(L_app) + wR*SRTT - wQ*Q"]
    D --> E{"S greater than T_hyst ?"}
    E -->|"yes"| F["assert zero_copy_en at TCB bit 47"]
    E -->|"no"| G["clear zero_copy_en"]
    F --> H["placement engine uses application descriptor list"]
    G --> I["placement engine uses common-pool descriptor list"]
    J["Host driver BAR0 doorbell ring plus generation counter"] -.-> C
    C -.-> K["hysteresis 2-bit counter prevents flapping"]

---

D1.2 — A2 · Sub-Nanosecond Per-Flow Decision at 800 GbE and 1 TiB Request Buffers

Enabling description. At 800 Gbit/s with 84-byte minimum frames the wire-time per frame is 0.84 ns, so a serial per-packet decision is impossible. The disclosure therefore caches the decision per flow generation: the engine computes zero_copy_en once when a connection is created or when a state delta fires (buffer post, window change > 25 %, SRTT update > 20 %, credit crossing), and stores it in the control block. The datapath then performs a single-bit read, sustaining 8 × 312.5 MHz lanes with no per-packet arithmetic. Deltas are detected by a 6-entry delta queue serviced by a low-priority microthread, guaranteeing that the fast path never stalls. At the opposite scale, 1 TiB request buffers are supported by a byte-granular ring: 40-bit byte offsets, a producer pointer advanced only when a moderated progress notification is emitted, and a consumer pointer advanced by the application; the advertised window is a 1 GiB sliding aperture that walks forward through the ring as placements land. At the low end, a 64-byte request is detected (L_app < 2·MSS) and forced to copy because descriptor-programming and pinning cost exceeds the transfer. A three-tier retention policy (L1 decision cache in the receive block, L2 per-queue table in SRAM, L3 policy array) keeps the worst-case decision latency under 4 ns.

flowchart LR
    subgraph LR1["800 GbE line rate - 0.84 ns min-frame budget"]
        A1["8 lanes at 312.5 MHz"] --> A2["per-flow decision cache"]
        A2 --> A3["re-evaluate only on state delta"]
    end
    subgraph SC["Scale extremes"]
        B1["64 B request - setup cost dominates"] --> B2["force copy"]
        B3["1 GiB to 1 TiB request - 40-bit ring offsets"] --> B4["sliding 1 GiB advertised aperture"]
    end
    A3 --> B2
    A3 --> B4
    A3 --> C1["delta queue serviced by microthread - fast path never stalls"]
    B4 --> C2["producer pointer moved only on moderated notification"]

---

D1.3 — A3 · Cross-Domain: Storage Targets, GPU/Accelerator Memory, Deterministic Industrial Control

Enabling description. Three unrelated industries are enabled by the same adaptive decision, with the notion of "application memory" replacing by domain.

(a) Storage — NVMe-oF target. "Application memory" becomes a pinned namespace I/O buffer. The feature word is formed from the command's SGL segment count and total transfer length; when L_cmd > 256 KiB and the SGL is contiguous in ≤ 4 segments, the target NIC places payload directly into the namespace buffer; otherwise payload is staged in a PRP-listed bounce region and copied by the target's DSA/IAA engine. The decision is recorded in the NVMe-oF capsule's per-command context, not a TCP TCB.

(b) Accelerators — peer-memory DDP. Destination is a CUDA UVM or BAR1 aperture on a peer device. A one-bit peer_mem tag in the policy entry forces direct placement off whenever the PCIe ACS bitmap indicates non-isolated downstream ports (preventing a malicious peer from steering writes), and forces it on for isolated, P2P-capable roots. Placement is issued as a PCIe posted write with a 64-byte completor and TLP digest enabled.

(c) Deterministic industrial control — EtherCAT/TSN. Cyclic process-image frames are never directly placed (bounded jitter is required and the buffer is small and synchronous); acyclic configuration/download frames above 64 KiB are directly placed. Discrimination uses the EtherCAT command code and the TSN stream handle, with a 100 µs budget enforced by a hardware deadline counter that demotes the frame to copy if the deadline is at risk.

flowchart TD
    A["Adaptive placement decision engine E1-E3"] --> S1["NVMe-oF target"]
    A --> S2["GPU / accelerator peer memory"]
    A --> S3["TSN / EtherCAT gateway"]
    S1 --> S1a{"L_cmd above 256 KiB and SGL in 4 or fewer segments?"}
    S1a -->|"yes"| S1b["direct place into namespace I/O buffer"]
    S1a -->|"no"| S1c["bounce buffer then DSA copy"]
    S2 --> S2a{"PCIe ACS isolated and P2P capable?"}
    S2a -->|"yes"| S2b["posted write with TLP digest"]
    S2a -->|"no"| S2c["blocked - copy through host"]
    S3 --> S3a{"cyclic process image?"}
    S3a -->|"yes"| S3b["copy path - bounded jitter"]
    S3a -->|"no"| S3c["direct place with 100 us deadline counter"]

---

D1.4 — A4 · RL-Optimized Placement Policy with IoT Telemetry and Ledger-Anchored Policy Provenance

Enabling description. A PPO agent selects {copy, zero_copy} per connection. State vector (12 × float16): queue occupancy, p50/p99 completion latency, copied-bytes EWMA, buffer reuse ratio, SRTT, MSS, credit headroom, PCIe replay rate, NIC die temperature, DRAM ECC count, request-length histogram bucket, and a one-hot of I/O mode (sync/async). Reward: r = −p99_latency − α·copied_bytes + β·reuse_ratio − γ·jitter. The trained policy is quantized to int8 (18 KB) and executed every 1 ms on the DPU's ARM core (or the on-NIC network processor); weights are pushed to the policy table through the same doorbell used by D1.1, with the score function fields reinterpreted as a small MLP's first layer. IoT/BMC telemetry (inlet air temperature, fan RPM, PSU telemetry, PCIe AER counters) is consumed via MCTP over SMBus; the deployment gate suppresses any new generation while any sensor reports a 3σ outlier, falling back to the last good generation. Provenance: each generation is H = SHA-256(weights ‖ feature_schema ‖ training_corpus_digest); H is written to a permissioned ledger, and the NIC refuses a weight blob whose hash is not present in a locally cached anchor set (updated 1/min). This makes placement behaviour auditable without trusting the host driver.

sequenceDiagram
    participant NIC as INA counters and BMC sensors
    participant ADV as Policy optimizer (offline)
    participant LED as Ledger anchor
    participant POL as NIC policy table
    participant APP as Host application
    NIC->>ADV: 12-dim feature vector at 1 ms cadence
    ADV->>ADV: PPO int8 inference - choose copy or zero-copy
    ADV->>LED: anchor SHA-256 of weights, schema, corpus digest
    LED-->>ADV: anchored generation root
    ADV->>POL: push generation id plus weight blob
    POL->>POL: verify hash is in cached anchor set
    POL->>APP: per-connection placement mode
    APP-->>NIC: credits returned on buffer consumption
    NIC->>ADV: telemetry outlier triggers rollback to last good generation

---

D1.5 — A5 · Inverse / Failure Mode: Fail-Safe Demotion to Deterministic Copy and Low-Power Best-Effort

Enabling description. The engine is specified as a four-state machine with an explicit fail-open to copy posture. Triggers that demote a connection: (i) IOMMU/ATS translation fault on a descriptor fetch; (ii) policy-generation mismatch (stale weights); (iii) descriptor CRC-32C mismatch; (iv) credit starvation for > 2 × RTO; (v) thermal throttle to the lowest P-state; (vi) MACsec ICV failure. On any trigger the engine sets force_copy = 1, clears TCB bit 47, emits a moderated notification carrying a 16-bit fault code, and writes all subsequent payload for that connection to the common pool. Zero-copy is re-armed only after N = 8 consecutive clean windows plus an unchanged descriptor-table hash, deliberately biasing the system toward the slower-but-safe path under uncertainty. Low-power mode: the decision engine is clock-gated to 1/16, zero-copy is disabled globally, receive coalescing rises to 64 packets per interrupt, MSI-X is replaced by a single coalesced line plus a polled progress register, and the PHY drops to the lowest advertised speed. A hardware "reduced-functionality" strap (GPIO sampled at reset) permanently selects copy-only for appliances, which is a distinct, disclosable configuration rather than a degraded one.

stateDiagram-v2
    [*] --> ZeroCopyArmed
    ZeroCopyArmed --> DeterministicCopy : IOMMU fault / hash mismatch / CRC error / credit starvation / thermal throttle / MACsec ICV fail
    DeterministicCopy --> ReArmPending : 8 consecutive clean windows and unchanged descriptor hash
    ReArmPending --> ZeroCopyArmed : hysteresis satisfied
    ReArmPending --> DeterministicCopy : any fault recurs
    DeterministicCopy --> LowPowerCopyOnly : idle 30 s
    LowPowerCopyOnly --> DeterministicCopy : link activity detected
    LowPowerCopyOnly --> ReducedFunctionStrap : GPIO strap at reset
    ReducedFunctionStrap --> LowPowerCopyOnly : self test pass

---

CORE CLAIM 2 — deferred copy from connection-associated staging into application memory (E4, E6)

D2.1 — A1 · Staging-Tier Substitution: CXL Type-3 Pool, On-Package HBM, Persistent Memory; Copy Engine Swapped for DSA/IAA or Arm DMA-350

Enabling description. The staging region (the copy source) is dislocated from ordinary OS DRAM into one of three substitutes. (i) CXL 3.1 Type-3 memory pool: the NIC owns a CXL.io CQ/PQ pair; HDM decoder HDM_i maps a 4 GiB staging window; the copy becomes a CXL.cache-coherent read by the host copy engine, avoiding a PCIe round trip. (ii) On-package HBM stack: an 8 GB HBM2e staging tier at 819 GB/s attached to the NIC's own mesh, addressed in 2 MiB granules so that the subsequent host copy is a single descriptor gather. (iii) Persistent (Optane-class) staging for crash-consistent delivery: each 64-byte staged line is preceded by an undo log record, and the NIC emits PM-semantics (CLWB + SFENCE equivalent) before advancing a durable commit pointer; after a host crash the recovery agent reads the undo log and replays the staging region into the application exactly once, keyed by (conn_id, seq). Copy-engine substitution: (a) descriptor-chained DMA, (b) Intel DSA with 4 KiB-per-op gating and page-fault-free completion records, (c) Arm DMA-350 with 8 channels and 64-byte bursts. Each engine is selectable by an engine_sel field in the request context, so the same adaptive decision drives three physically different data movers.

flowchart TD
    A["Adaptive decision: stage then copy"] --> B["staging tier selection register"]
    B --> C1["CXL 3.1 type-3 pool - HDM decoder - coherent read"]
    B --> C2["on-package HBM2e - 2 MiB granule gather"]
    B --> C3["persistent memory - undo log plus durable commit pointer"]
    C1 --> D{"engine_sel"}
    C2 --> D
    C3 --> D
    D --> E1["descriptor-chained DMA"]
    D --> E2["Intel DSA - 4 KiB opaque with completion record"]
    D --> E3["Arm DMA-350 - 8 channels 64 B bursts"]
    E1 --> F["application buffer at computed offset"]
    E2 --> F
    E3 --> F
    C3 --> G["crash recovery replays undo log keyed by conn_id and seq"]
    G --> F

---

D2.2 — A2 · Copy-Boundary at Environmental Extremes: 1 B…1 GiB Requests, −40 °C…+105 °C, 400 GbE, 3 µs Tail Target

Enabling description. The decision is expressed as an explicit cost inequality. Let c_copy(L) = c0 + L/B_copy (host memcpy at B_copy ≈ 12 GB/s single-thread) and c_setup(L) = c1 + n_desc·c2 with c1 ≈ 4 µs pinning/DMA-map and c2 ≈ 25 ns per descriptor, and B_dma ≈ 50 GB/s on PCIe Gen5 ×16. The crossover is L* = (c1 + n_desc·c2 − c0) / (1/B_copy − 1/B_dma), which at 4 descriptors is ≈ 190 KiB — above L* prefer direct placement, below it prefer staging plus copy. Temperature: below −20 °C the DDR5 refresh/derating rules force the copy engine to 60 % throughput, moving L* to ≈ 310 KiB, so a temperature-compensated 16-entry lookup recomputes the boundary each 100 ms. Scale: at 1 GiB requests, the pipeline uses 2 MiB huge pages, MADV_HUGEPAGE, and pre-faulted rings; at 1-byte requests the copy path is bypassed entirely in favour of a smeared descriptor to avoid a 4 µs setup on a 1 ns payload. Tail-latency target of 3 µs at 400 GbE is met by pinning copy worker threads to isolated cores, using a per-CPU DMA channel, and issuing movdir64b stores on the destination.

flowchart TD
    A["Request arrives - record L_app and n_desc"] --> B{"L_app greater than L_star ?"}
    B -->|"yes"| C["direct placement - DMA engine at B_dma"]
    B -->|"no"| D["staging plus host copy at B_copy"]
    E["temperature sensor less than -20 C"] --> F["recompute 16-entry boundary table - L_star rises to about 310 KiB"]
    F --> B
    G["L_app = 1 B"] --> H["smeared descriptor - bypass copy path"]
    I["L_app = 1 GiB"] --> J["2 MiB huge pages - MADV_HUGEPAGE - pre-faulted rings"]
    C --> K["3 us tail target - isolated cores, per-CPU DMA channel, movdir64b"]
    J --> K

---

D2.3 — A3 · Cross-Domain: Automotive SOME/IP, AgTech Genomics, Aerospace ARINC 664

Enabling description. (a) Automotive — AUTOSAR Adaptive / SOME/IP over 100BASE-T1 and 1000BASE-T1. Staging region is a fixed 256 KiB "IPDU mirror" in the vehicle-central gateway. Direct placement is permitted only for large software-update payloads (UDS/OTA, > 1 MiB) into a pre-allocated flash-write staging buffer; safety-critical cyclic SOME/IP events are always copied so that the copy completes within the 10 ms cycle. A watchdog monitors the gateway's copy engine; a missed cycle demotes all traffic to copy-only for 1 s.

(b) AgTech — genomics/sequencing pipelines. Flow-cell instrument streams base-call records to a compute node. The "request" is a lane-level batch; direct placement is used when the batch length exceeds the posted ring (~4 MiB) and the NUMA node of the pinned buffer matches the NIC's locality; otherwise records are staged and copied by a DSA engine bound to the same socket, so that no cross-socket QPI traffic is generated on the copy.

(c) Aerospace — ARINC 664 Part 7 virtual links. Traffic is rate-constrained and schedule-policed. Direct placement is enabled only for the file-transfer VL and disabled for all A/B/D sampled and queued VLs; a per-VL bandwidth allocation gap (BAG) counter guarantees the copy never overruns its partition window, and a lockstep checker validates the placement against a precomputed schedule table.

flowchart TD
    A["Adaptive staging-plus-copy engine E4/E6"] --> D1["Automotive central gateway"]
    A --> D2["AgTech sequencing compute node"]
    A --> D3["Aerospace ARINC 664 switch"]
    D1 --> D1a{"UDS/OTA payload above 1 MiB ?"}
    D1a -->|"yes"| D1b["direct place to flash staging buffer"]
    D1a -->|"no"| D1c["copy path - 10 ms cycle watchdog"]
    D2 --> D2a{"batch above 4 MiB and NUMA local ?"}
    D2a -->|"yes"| D2b["direct place into pinned ring"]
    D2a -->|"no"| D2c["DSA copy on same socket - no cross-socket traffic"]
    D3 --> D3a{"virtual link type"}
    D3a -->|"file transfer VL"| D3b["direct placement under BAG counter"]
    D3a -->|"sampled or queued VL"| D3c["copy only - schedule table enforced"]

---

D2.4 — A4 · Predicted Patch Lengths (TCN) + TSN Telemetry + Merkle-Attested Copy Ledger

Enabling description. A temporal convolutional network (6 dilated conv layers, receptive field 64 samples, 41 k parameters) consumes the last 64 sequence-number deltas, inter-arrival times, and MSS values, and predicts P(patch completes within T) and E[L_next]. If P > 0.8 and E[L_next] < remaining capacity, a speculative staging window is pre-armed and an offset reservation is recorded in the control block, so that when the application posts the buffer the copy and the direct placement begin in the same cycle (the offset-corrected parallel operation of E6). Every staging write emits a 32-byte record {conn_id, seq, length, mono_ts, blake2s_prefix}; records are batched every 1 ms into a Merkle tree whose root is anchored hourly, giving any later party a cryptographic way to verify that a claimed byte range was staged before it was placed. TSN generalized PTP (802.1AS) supplies mono_ts with ±100 ns accuracy so the ledger is admissible as a timing record, not merely a coarse log.

sequenceDiagram
    participant PKT as Packet receive path
    participant TCN as TCN predictor
    participant RES as Offset reservation in TCB
    participant LED as Merkle ledger
    participant CPY as Host copy engine
    PKT->>TCN: last 64 seq deltas, IATs, MSS
    TCN-->>RES: P(patch complete) and E[L_next]
    RES->>RES: pre-arm speculative staging window and offset
    PKT->>RES: staged writes with 32-byte records
    RES->>LED: batch records every 1 ms - Merkle root anchored hourly
    RES->>CPY: parallel offset-corrected copy into application buffer
    CPY-->>RES: completion with mono_ts from 802.1AS

---

D2.5 — A5 · Inverse: Copy-Only Tamper-Evident Mode and Battery-Constrained Always-Copy Mode

Enabling description. Two deliberately restricted operating modes are disclosed. Tamper-evident mode: if HMAC-SHA-256(descriptor_tuple, per-connection_salt) or the MACsec ICV fails, the NIC enters copy_only + quarantine; payload for that connection is written to a quarantine pool with a per-connection salt and a monotonic serial, the application is not given the data, and the moderated notification carries a 16-bit fault code and the quarantine handle. Data leaves quarantine only after an out-of-band validation (TPM-signed release, or an operator-signed release token). Battery/limited-functionality mode: on a strap or a BMC command, the NIC disables zero-copy entirely, downshifts the link (e.g. 25 GbE → 10 GbE), raises coalescing to 100 ms, uses a single polled progress register instead of interrupts, and permits entry to D3cold after 30 s of idle; the host driver is required to continue servicing sockets in this mode, i.e. the invention is explicitly inverted into an always-copy, lowest-power device. A "deterministic copy" variant additionally fixes copy ordering and pins a single core, producing byte-for-byte reproducible staging sequences for regression testing even though throughput drops.

stateDiagram-v2
    [*] --> NormalAdaptive
    NormalAdaptive --> TamperEvidentCopyOnly : HMAC or MACsec ICV failure
    TamperEvidentCopyOnly --> Quarantine : payload written to salted quarantine pool
    Quarantine --> Released : TPM-signed or operator-signed release token
    Released --> NormalAdaptive : connection revalidated
    NormalAdaptive --> BatteryCopyOnly : strap or BMC command
    BatteryCopyOnly --> DeterministicCopy : reproducible ordering requested
    BatteryCopyOnly --> D3cold : idle 30 s
    D3cold --> BatteryCopyOnly : link activity
    DeterministicCopy --> NormalAdaptive : mode cleared

---

CORE CLAIM 5 — deferred copy from connection-independent (common-pool) staging (E5, E6)

D5.1 — A1 · Common Pool in CXL Shared Memory with Per-Connection Leases

Enabling description. The staging area is a connection-independent pool whose physical substrate is selectable: (a) on-NIC DDR4 (8 GB, lowest latency, limited capacity), (b) host 2 MiB hugepages under an RDMA-style ibv_reg_mr-equivalent pin, or (c) a CXL 3.1 shared-memory region visible to several NICs and/or a DPU. A lease table decouples ownership from the pool: LEASE{lease_id, conn_id, offset, length, state, ttl_ns}. Pool acquisition is a 4-instruction sequence — read free-list head, CAS it, write the lease, publish with a release fence — costing ≈ 250 ns. Because the pool is not tied to a connection, a lease can be re-assigned to a different connection during TCP connection migration or NIC failover, which the connection-associated variant cannot do. The substrate is swapped with no change to the host-facing interface, because the lease abstraction hides the physical backing store.

erDiagram
    POOL ||--o{ LEASE : grants
    CONNECTION ||--o{ LEASE : holds
    POOL {
        u32 pool_id
        u64 base_addr
        u32 granule_bytes
        u32 free_list_head
        u8  substrate_code
    }
    LEASE {
        u64 lease_id
        u32 conn_id
        u64 offset
        u32 length
        u8  state
        u64 ttl_ns
    }
    CONNECTION {
        u32 tcb_index
        u32 credits
        u16 mss
        u64 app_buf_base
    }

---

D5.2 — A2 · Pool Scale Extremes: 10⁷ Descriptors, 10⁵ Concurrent Connections, 250 ns Acquisition, RCU Reclamation

Enabling description. A 10⁷-entry free list is maintained as a lock-free Treiber stack over 64-byte-aligned nodes in 2 MiB hugepages (640 MiB footprint), with an ABA-safe tagged pointer in the top 16 bits of a 64-bit head. Under 10⁵ concurrent connections the pool is partitioned into 64 shards (one per receive queue) to eliminate cross-shard cache-line ping-pong; a shard has a low/high watermark pair (20 %/80 %) and borrows from a global reserve over a dedicated credit protocol. Reclamation is RCU: a returned lease is freed only after one grace period, which is bound to a receive-queue epoch counter rather than a scheduler tick, so a stalled consumer cannot leak the node indefinitely (a 500 ms timeout forces reclamation after a quiesce). Acquisition statistics (p99 250 ns, 10⁶ ops/s/shard) are exposed as a 64-bit counter set; a hardware "pool pressure" signal feeds the E1 decision, biasing new requests to direct placement when the pool watermark is high.

flowchart LR
    A["New request needing staging"] --> B["hash conn_id to pool shard 0..63"]
    B --> C["pop Treiber stack - CAS tagged head - 250 ns"]
    C --> D{"shard watermark"}
    D -->|"below 20 percent"| E["borrow from global reserve via credit protocol"]
    D -->|"above 80 percent"| F["raise pool-pressure signal to E1 - bias to direct placement"]
    D -->|"in band"| G["write lease record and publish"]
    G --> H["payload staged"]
    H --> I["return lease"]
    I --> J["RCU grace period bound to receive-queue epoch"]
    J --> K["timeout 500 ms forces quiesce then free"]

---

D5.3 — A3 · Cross-Domain: CDN Edge Caches, Market-Data Ticker Handlers, Smart-Grid SCADA

Enabling description. (a) CDN edge. A connection-independent pool holds partially received objects while the origin fetch completes; direct placement is enabled only when a full object is expected to exceed the 1 MiB cache-line-aligned slot, otherwise the object is assembled in the pool and then copied to the cache slab. Header-rewrite fields are never directly placed, because a later mutation would invalidate a zero-copy mapping.

(b) Market-data ticker handlers. Multicast A/B feeds produce duplicate sequences; the pool is a per-symbol reassembly area of fixed 512 KiB slots. Direct placement is enabled only for the "winning" line and for symbols with a pre-posted consumer ring; arbitration between the A and B feeds uses a deterministic priority (lowest sequence latency wins) so that only one path writes application memory.

(c) Smart-grid SCADA (IEC 61850 / DNP3). Buffer pool is a shared-memory region mapped in a substation gateway's real-time partition. Report-control-block frames are small and cyclic → always copied; large file-transfer (FT) or log-dump payloads → directly placed into a pinned engineering buffer. A per-IED quota prevents one device from exhausting the pool.

flowchart TD
    A["Connection-independent staging pool"] --> X1["CDN edge cache"]
    A --> X2["Market-data ticker handler"]
    A --> X3["Smart-grid SCADA gateway"]
    X1 --> X1a{"object expected above 1 MiB ?"}
    X1a -->|"yes"| X1b["direct place into cache slot"]
    X1a -->|"no"| X1c["assemble in pool then copy to slab"]
    X2 --> X2a{"winning A or B line and consumer ring posted ?"}
    X2a -->|"yes"| X2b["direct place by symbol"]
    X2a -->|"no"| X2c["reassemble in 512 KiB per-symbol slots"]
    X3 --> X3a{"report control block or file transfer ?"}
    X3a -->|"RCB cyclic"| X3b["copy path"]
    X3a -->|"FT or log dump"| X3c["direct place under per-IED quota"]

---

D5.4 — A4 · AI Pool Sizing, eBPF Pool Policy, DLT Pool Accounting

Enabling description. An online controller (Lyapunov-drift minimizer over {pool_high_watermark, shard_count, lease_ttl}) tunes pool sizing each second from the observed staged-bytes EWMA and copy-latency percentile; its output is applied through the same generation-counter mechanism as D1.4, versioned and anchor-verified. Pool admission and eviction rules are additionally exposed to a sandboxed eBPF hook (BPF_PROG_TYPE_SCHED_CLS-like, attached to a NIC-side BPF JIT at the pool allocator entry point), permitting operators to express domain rules such as "never stage more than 64 KiB for port 5060" without kernel modification; the verifier bounds loops and stack so that the allocator cannot be made to fault. Every lease grant and release is folded into a ledger digest; periodic Merkle roots provide a tamper-evident accounting record for chargeback and for SLA disputes, and a zero-knowledge range proof can be attached if tenant isolation requirements forbid revealing byte counts.

flowchart TD
    A["Pool telemetry - staged bytes EWMA, copy p99, shard occupancy"] --> B["Lyapunov drift controller - 1 s cadence"]
    B --> C["new generation - high watermark, shard count, lease TTL"]
    C --> D["hash and anchor generation - NIC verifies before applying"]
    E["Operator policy as eBPF program"] --> F["verifier - bounded loops and stack"]
    F --> G["JIT and attach at pool allocator entry"]
    G --> H["lease grant or deny decision"]
    H --> I["lease ledger records folded into Merkle root"]
    I --> J["chargeback and SLA proofs - optional zk range proof"]

---

D5.5 — A5 · Inverse: Pool-Exhaustion Graceful Degradation, Zero-Window Backpressure, Admission Control

Enabling description. The inverse mode is a pool-aware admission controller. Three thresholds act as a ladder: at LOW (free < 20 %) new requests are biased to direct placement; at HIGH (free < 5 %) the adaptor stops enlarging the advertised receive window from returned credits, so the peer sees a shrinking window; at EXHAUSTED (free = 0) the adaptor advertises a window of zero for affected connections only — graceful backpressure rather than dropped packets — while connections that can be directly placed remain fully open. Admission control sheds load in priority order: bulk (scavenger class) connections are window-limited first, then interactive, never control-plane. RTO-based retransmit is used to detect stale leases, and a 250 ms lease TTL with a lazy sweep bounds the worst-case pool leak. A "no-staging" reduced-functionality personality disables the pool entirely, which — combined with D2.5's always-copy mode — yields two orthogonal limited-functionality configurations suitable for appliances with tiny memories.

stateDiagram-v2
    [*] --> NormalPooling
    NormalPooling --> BiasToDirectPlacement : free below LOW 20 percent
    BiasToDirectPlacement --> WindowBackpressure : free below HIGH 5 percent
    WindowBackpressure --> ZeroWindowIsolated : free equals 0 - advertise zero window per connection
    ZeroWindowIsolated --> WindowBackpressure : lease returned via lazy sweep
    WindowBackpressure --> NormalPooling : free above 40 percent
    ZeroWindowIsolated --> SheddingScavenger : sustained exhaustion
    SheddingScavenger --> WindowBackpressure : bulk connections closed
    ZeroWindowIsolated --> NoStagingPersonality : operator selects reduced function

---

CORE CLAIM 10 — host-side program product performing the selective configuration (E8)

D10.1 — A1 · Program-Product Delivery Substrate Substitution: UEFI DXE ROM Driver, FPGA Partial-Reconfiguration Bitstream, eBPF CO-RE Object Shipped as an OCI Artifact

Enabling description. The same placement-configuration program is disclosed in four substitutable forms. (i) Kernel module (baseline): configures descriptors and the TCB bit through a netdev driver API. (ii) UEFI DXE driver in a SPI-flash capsule: runs pre-OS so that a network boot or BMC-managed firmware update can be received with zero-copy already configured before the OS loader; uses EFI_PCI_IO and a memory-map contract with the OS via an ACPI table. (iii) FPGA partial bitstream for the adaptor's programmable logic region: the placement policy is expressed as a synthesizable comparator tree; reconfiguration takes 8 ms and is A/B-slotted. (iv) eBPF CO-RE object packaged as an OCI artifact with a mediaType of application/vnd.…ebpf, distributed through the same registry used for container images; the loader performs CO-RE relocation against BTF and the verifier guarantees termination. A common interface (load, program(conn), query_mode(conn)) allows one policy source to target all four substrates.

classDiagram
    class PlacementPolicyProgram {
        +load(policy_blob) int
        +program(conn_id) int
        +query_mode(conn_id) Mode
        +rollback(generation) int
    }
    class KernelModuleDriver
    class UefiDxeRomDriver
    class FpgaPartialBitstream
    class EbpfCoreObject
    PlacementPolicyProgram <|-- KernelModuleDriver
    PlacementPolicyProgram <|-- UefiDxeRomDriver
    PlacementPolicyProgram <|-- FpgaPartialBitstream
    PlacementPolicyProgram <|-- EbpfCoreObject
    class OCIRegistry
    EbpfCoreObject --> OCIRegistry : mediaType application/vnd.ebpf

---

D10.2 — A2 · Extreme Footprint and Scale: 24 KB Firmware on a Cortex-M7 Smart-NIC, 10⁶ Connections, Formally Verified Decision Function

Enabling description. A 24 KB thumb-2 image (measured with -Os, no heap, all state in a 4 KB static arena) runs the decision function on a Cortex-M7 at 480 MHz, with the datapath in a companion FPGA. The decision function is reduced to a 3-input comparator plus a 16-entry constant table, which is small enough to be formally verified with an SMT solver: the specification asserts (a) zero_copy_en ⇒ descriptor_table_valid, (b) ¬credits ⇒ ¬zero_copy_en, and (c) no integer overflow in the score computation; the solver returns UNSAT for the negation of each. At the other extreme, the same program manages 10⁶ concurrent connections on a 64-bit server by keeping only an 8-byte decision shadow per connection (8 MB) and paging full control blocks; a two-level radix tree keyed on the 4-tuple's 32-bit hash gives O(1) shadow lookup, and a generational counter avoids ABA on connection reuse.

flowchart LR
    A["Policy source"] --> B{"target footprint"}
    B -->|"24 KB MCU"| C["thumb-2 image - 4 KB static arena - 3-input comparator - 16-entry table"]
    C --> D["SMT formal verification - descriptor validity, credit invariant, no overflow"]
    B -->|"10^6 connections"| E["8-byte decision shadow per connection - 8 MB total"]
    E --> F["two-level radix tree on 32-bit 4-tuple hash"]
    F --> G["generational counter prevents ABA on reuse"]
    D --> H["Configuration output to datapath"]
    G --> H

---

D10.3 — A3 · Cross-Domain: Medical (IEC 62304 Class B), Satellite Ground Station (CCSDS), Retail POS

Enabling description. (a) Medical. A device-side program product developed under IEC 62304 Class B, with the placement decision classified as a non-safety software item and all safety items isolated in a separate partition; the program records every configuration change in a 21 CFR Part 11-compliant audit trail with user identity and timestamp, and the adaptive decision defaults to the conservative copy path whenever the device is in a clinical mode. (b) Satellite ground station. The product implements CCSDS Space Link Extension service-provider configuration; direct placement is enabled for large telemetry playback frames (AOS transfer frames above 64 KiB) and disabled for real-time housekeeping because the demodulator's output ring is small and cyclic; a Reed-Solomon decode failure forces the copy path and a retransmission request. (c) Retail POS. The program runs on a payment terminal's embedded NIC; cardholder-data-adjacent traffic (ISO 8583, EMV) is always copied into a hardened, zeroed staging area (never zero-copied directly into an application buffer), while non-sensitive OTA/update traffic may be zero-copied.

flowchart TD
    A["Placement program product"] --> M["Medical device - IEC 62304 Class B"]
    A --> S["Satellite ground station - CCSDS SLE"]
    A --> P["Retail POS terminal"]
    M --> M1["decision classified non-safety - separate partition"]
    M --> M2["21 CFR Part 11 audit trail of config changes"]
    M --> M3["clinical mode forces conservative copy"]
    S --> S1{"AOS transfer frame above 64 KiB ?"}
    S1 -->|"yes"| S2["direct placement for playback"]
    S1 -->|"no"| S3["copy path for real-time housekeeping"]
    S --> S4["Reed-Solomon failure forces copy plus retransmit request"]
    P --> P1["ISO 8583 and EMV always copied to zeroed hardened staging"]
    P --> P2["OTA update traffic may be zero-copied"]

---

D10.4 — A4 · LLM-Orchestrated Policy Synthesis, eBPF Verifier as Safety Net, SBOM/Sigstore Attestation in a Ledger

Enabling description. A constrained code-generating model (fine-tuned code LLM, temperature 0, seeded by a schema) synthesizes placement-policy eBPF programs and C configuration stubs from a natural-language operator intent ("favour latency for port 443, favour memory for port 80 under 10 GB/s"). The generated program is never trusted: it must (1) pass the eBPF verifier (bounded loops, ≤ 512 bytes stack, no unbounded pointer arithmetic), (2) pass a differential test against a reference interpreter on 10⁶ recorded traces, and (3) pass a static cost analysis bounding the worst-case copied bytes per second. Only then is it signed (Sigstore keyless, Fulcio-issued certificate bound to the CI identity) and promoted. A software bill of materials (SPDX 2.3) enumerating every firmware, driver, and policy component accompanies the release, and the SBOM's digest is anchored to the same ledger as the policy generation, so any later claim about what code was running is verifiable. Rollback is by generation number, and the ledger makes rollbacks auditable.

sequenceDiagram
    participant OPS as Operator intent (natural language)
    participant LLM as Constrained code LLM
    participant VER as eBPF verifier and differential tester
    participant CI as CI signing (Sigstore Fulcio)
    participant NIC as Adaptive adaptor
    participant LED as Provenance ledger
    OPS->>LLM: intent plus schema
    LLM->>VER: candidate policy program
    VER->>VER: verifier, 10^6 trace differential, cost bound
    VER-->>CI: accepted artifact
    CI->>LED: anchor SBOM digest and policy digest
    CI->>NIC: signed policy generation
    NIC->>NIC: verify signature and anchored digest
    NIC->>NIC: apply or roll back by generation

---

D10.5 — A5 · Inverse: Safe-Mode Driver, A/B Firmware Slots, Watchdog Revert, Legacy Socket Path

Enabling description. The program product is specified with a mandatory fallback ladder. On configuration failure (descriptor programming error, TCB write timeout, policy table CRC fault) the driver (1) reverts the connection to the legacy socket path (all payload through the OS stack, no TCB bit set), (2) records the failing feature in a non-volatile fault log, and (3) suppresses the zero-copy feature for that application for a cooldown period (60 s, exponential to 1 h). At the device level, firmware lives in A/B slots; a hardware watchdog that is not serviced by the driver (an independent timer in the BMC or the NIC's own microcontroller, 5 s timeout) triggers a slot switch and a full reset, after which the device boots in the always-copy reduced-functionality personality of D2.5 and D5.5. A "training mode" runs both the copy and the zero-copy path in parallel, comparing results byte-for-byte and emitting a divergence counter; this is explicitly a limited-functionality mode (roughly half throughput) intended for validation rather than production.

stateDiagram-v2
    [*] --> ActiveSlotA
    ActiveSlotA --> LegacySocketPath : configuration failure
    LegacySocketPath --> Cooldown : feature suppressed 60 s to 1 h
    Cooldown --> ActiveSlotA : cooldown expiry and clean run
    ActiveSlotA --> SlotB : independent watchdog 5 s timeout fires
    SlotB --> ReducedFunctionalityBoot : boots always-copy personality
    ReducedFunctionalityBoot --> ActiveSlotB : operator promotion
    ActiveSlotA --> TrainingMode : validation requested
    TrainingMode --> ActiveSlotA : divergence counter zero
    TrainingMode --> ActiveSlotB : divergence detected

---

CORE CLAIM 13 — program-product variant where the copy source is not connection-associated (E5 via host instructions)

D13.1 — A1 · Instruction/ABI Substitution: movdir64b, Arm MOPS, Descriptor Chains, LD_PRELOAD Shim vs. Kernel Module

Enabling description. The copy step is disclosed using four different instruction/ABI families. (a) x86 MOVDIR64B issues a 64-byte direct-store, bypassing the write-allocate cache read, ideal for filling a staging line that will be read once; ENQCMD/ENQCMDS submit descriptors to the DSA engine with an outstanding-capacity mechanism that back-pressures in hardware. (b) Arm memory-copy-and-prefetch (MOPS, FEAT_MOPS / CPY*) performs the copy with architectural progress guarantees, permitting an in-flight copy to be safely interrupted on a context switch. (c) A chained descriptor list is submitted to a copy engine with a completion record per descriptor. (d) A user-space LD_PRELOAD libc shim intercepts read/recv and per-forms the copy in a userspace poll-mode driver, versus (e) a kernel module doing the same with copy_to_user. The adaptive decision is identical; only the mover and the ABI differ, which is the point of the disclosure.

flowchart TD
    A["Copy from non-connection-associated staging"] --> B{"mover selection"}
    B --> C["x86 MOVDIR64B 64-byte direct store"]
    B --> D["ENQCMD to DSA with outstanding capacity back-pressure"]
    B --> E["Arm FEAT_MOPS copy with progress guarantee"]
    B --> F["chained descriptors with per-descriptor completion record"]
    B --> G["userspace LD_PRELOAD shim over poll-mode driver"]
    B --> H["kernel module copy_to_user"]
    C --> I["application buffer"]
    D --> I
    E --> I
    F --> I
    G --> I
    H --> I

---

D13.2 — A2 · Rack-Scale Copy: NUMA-Crossing, CXL Remote Memory, 2 MiB Pages, 100 µs Budget

Enabling description. At rack scale the "copy" may traverse a fabric. Three topologies are disclosed: (a) same-socket (copy by DSA on the NIC's NUMA node, ≤ 5 µs for 1 MiB); (b) cross-socket over UPI/Infinity Fabric (copy pinned to the destination socket to avoid read-for-ownership traffic, ≥ 12 µs for 1 MiB); (c) CXL 3.1 fabric-attached memory where the staging region and the application buffer may live on different hosts of a memory pool, requiring HDM decoder programming, CXL.cache coherency domain negotiation, and a fabric-manager (FM-API) allocation. A 100 µs end-to-end budget is enforced by a hardware deadline counter in the copy descriptor; if the fabric reports a poison or a retry storm, the copy is abandoned, the destination is marked partial, and the connection is demoted as in D1.5. 2 MiB huge pages and pre-faulted rings eliminate the page-fault path; MADV_POPULATE_WRITE-equivalent pre-touch is performed at connection setup.

flowchart LR
    A["Copy descriptor with 100 us deadline counter"] --> B{"topology"}
    B -->|"same socket"| C["DSA on NIC NUMA node - about 5 us per MiB"]
    B -->|"cross socket"| D["pinned to destination socket - about 12 us per MiB"]
    B -->|"CXL fabric memory"| E["HDM decoder and FM-API allocation - CXL.cache coherency"]
    C --> F["application buffer"]
    D --> F
    E --> G{"poison or retry storm ?"}
    G -->|"no"| F
    G -->|"yes"| H["abandon copy - mark partial - demote connection"]
    F --> I["2 MiB huge pages and pre-touched rings remove fault path"]

---

D13.3 — A3 · Cross-Domain: 5G UPF, Seismic Acquisition, SMPTE ST 2110 Broadcast

Enabling description. (a) 5G UPF. GTP-U decapsulation feeds a common pool; direct placement is enabled for large downlink flows (video, > 256 KiB burst) into a pinned PDR buffer, disabled for tiny periodic pings and for lawful-intercept copies (an intercept tap must be an exact byte replica, so it is always taken from the pool before any placement). (b) Oil & gas seismic acquisition. Field digitizer units stream 24-bit samples at multi-Gb/s; the common pool holds partially filled shot gathers (fixed 64 MiB traces) and direct placement into the processing node's pinned gather buffer occurs only for shots whose header indicates they belong to the active survey geometry — out-of-survey/noise shots are staged and copied for QC. (c) SMPTE ST 2110 broadcast. Each essence stream (video/audio/ancillary) has a fixed-format buffer pool keyed to the frame raster; direct placement occurs only after the RTP timestamp and the ST 2110-21 virtual-receiver constraint have been validated, because placing a malformed frame would corrupt a playout buffer.

flowchart TD
    A["Common staging pool feeding the adaptive decision"] --> G1["5G UPF"]
    A --> G2["Seismic acquisition"]
    A --> G3["SMPTE ST 2110 broadcast"]
    G1 --> G1a{"downlink burst above 256 KiB and not intercept ?"}
    G1a -->|"yes"| G1b["direct place into pinned PDR buffer"]
    G1a -->|"no"| G1c["copy path - intercept always from pool"]
    G2 --> G2a{"shot belongs to active survey geometry ?"}
    G2a -->|"yes"| G2b["direct place into pinned 64 MiB gather"]
    G2a -->|"no"| G2c["stage and copy for QC"]
    G3 --> G3a{"RTP timestamp and ST 2110-21 validated ?"}
    G3a -->|"yes"| G3b["direct place into raster-aligned pool slot"]
    G3a -->|"no"| G3c["copy path - protect playout buffer"]

---

D13.4 — A4 · eBPF-Driven Pool Policy, AI Placement, DLT License Tokens Metering Pool Usage

Enabling description. The program product exposes the pool as a metered resource governed by transferable tokens. A non-fungible usage token per pool shard (balance = free bytes, minted on lease grant, burned on release) is maintained on a permissioned ledger; the NIC holds a pre-authorized balance and cannot oversell because a lease grant requires a token burn validated against a locally cached Merkle proof of the ledger state (updated each 200 ms, with a max_staleness guard that rejects grants older than 1 s). An AI controller fine-tunes shard sizes from observed traffic; an eBPF hook applies domain policy. This yields an auditable, cross-tenant pool with cryptographic scarcity — new subject matter relative to any ledger-free pool.

flowchart TD
    A["eBPF pool policy hook"] --> B["lease grant request"]
    B --> C["token burn against cached Merkle proof of ledger state"]
    C --> D{"proof age below 1 s ?"}
    D -->|"no"| E["reject grant - refresh proof"]
    D -->|"yes"| F["grant lease - decrement local token balance"]
    G["AI controller - shard sizing from traffic EWMA"] --> A
    F --> H["payload staged"]
    H --> I["lease release - mint token"]
    I --> J["ledger root updated every 200 ms"]

---

D13.5 — A5 · Inverse: Shadow-Copy Forensic/Replay Mode and Deterministic Degraded Copy

Enabling description. A forensic personality of the program product writes every byte that would have been directly placed into a shadow region first, computes a BLAKE3 hash per 4 KiB, and only then performs the placement; the shadow region is retained for a configurable window (1 s to 1 h) allowing bit-exact replay of any connection's receive stream for incident analysis. Throughput is roughly halved, making this an explicitly limited-functionality mode. A companion deterministic mode seeds all copy scheduling from a connection-level PRNG, fixes the copy worker core, and disables all adaptive switching, producing byte-identical staging layouts across runs — the property needed for regression and certification harnesses. A kill-switch is included: a signed "freeze" message from the BMC stops all adaptive decisions and drains in-flight placements before entering replay mode, so the forensic window is not corrupted by an in-flight decision.

stateDiagram-v2
    [*] --> NormalAdaptive
    NormalAdaptive --> FreezeDrain : signed freeze message from BMC
    FreezeDrain --> ForensicShadowCopy : all in-flight placements drained
    ForensicShadowCopy --> ForensicShadowCopy : BLAKE3 per 4 KiB, shadow window 1 s to 1 h
    ForensicShadowCopy --> NormalAdaptive : window closed or operator clears
    NormalAdaptive --> DeterministicDegraded : certification harness requested
    DeterministicDegraded --> DeterministicDegraded : seeded PRNG, fixed core, no adaptive switching
    DeterministicDegraded --> NormalAdaptive : harness completes

---

CORE CLAIM 16 — stateful-connection variant (E1–E7 under an explicit connection state machine)

D16.1 — A1 · State-Store Substitution: ASIC TCB SRAM vs. TCAM + DRAM vs. Host-Resident with NIC Caching; CRC32c vs. Toeplitz Hashing

Enabling description. The per-connection control block storing the placement descriptor and the zero_copy_en bit is disclosed in three physical realizations. (i) On-ASIC SRAM: 32k × 256 B single-cycle TCB array, 8 banks, worst-case 1-cycle lookup. (ii) Off-chip TCAM + DRAM: a 16k-entry TCAM holds the 4-tuple match for hot connections and points into a DDR4 TCB region; the TCAM consumes ~4 nJ per lookup but scales to 256k entries. (iii) Host-resident TCB with NIC-side caching: the control block lives in pinned host memory and the NIC caches the placement-relevant 64-byte line with a coherency protocol over PCIe (no-snoop or ATS), so that a descriptor update by the driver is picked up in ≤ 2 cache-line fetches. Lookup hashing is also substituted: CRC32c (hardware polynomial, 12 ns) versus Toeplitz RSS (multi-hash for multi-queue affinity). The choice of store changes the maximum sustainable connection count and the mutation cost of the descriptor, but not the adaptive algorithm.

flowchart LR
    A["Incoming packet 4-tuple"] --> B{"TCB store"}
    B -->|"on-ASIC SRAM"| C["32k entry array - 1 cycle lookup - 256 B entry"]
    B -->|"TCAM plus DRAM"| D["16k TCAM hot set - DDR4 TCB region - 256k entries"]
    B -->|"host-resident with cache"| E["pinned host TCB - 64 B line cached over PCIe ATS"]
    C --> F{"hash select"}
    D --> F
    E --> F
    F -->|"CRC32c"| G["hardware polynomial - about 12 ns"]
    F -->|"Toeplitz"| H["multi-hash RSS for queue affinity"]
    G --> I["read zero_copy_en bit and descriptor list"]
    H --> I

---

D16.2 — A2 · Scale Extremes: 10⁷ Stateful Connections, 10⁶ Churn/s, 800 GbE, 100 ms RTT / 10 GB BDP

Enabling description. Supporting 10⁷ simultaneous stateful connections requires that the complete placement state be ≤ 32 bytes per connection (320 MB of fast memory) and that eviction be deterministic: the disclosure uses a 3-level state hierarchy — (1) a 32-byte "decision shadow" always resident, (2) the full TCB in DRAM, (3) cold state spilled to host memory or NVMe with a generation-validated restore path. With 10⁶ connection churn per second, TCB allocation uses a segregated free list per bucket (sizes 256/512/1024 B) plus a per-CPU magazine cache, so allocation is 40 ns and never contends on a global lock. Under a 10 GB bandwidth-delay product (100 ms RTT), the receive window is the size of the mapped region, so flow control credits must be returned in groups of at least 64 KiB to keep the window from idling; the run-time check credits_returned/(credits_available) is monitored and the return group size adapts to RTT so that group ≥ BDP/1000.

flowchart TD
    A["10^7 stateful connections"] --> B["level 1: 32-byte decision shadow always resident - 320 MB"]
    A --> C["level 2: full TCB in DRAM"]
    A --> D["level 3: cold state spilled, generation-validated restore"]
    E["10^6 churn per second"] --> F["segregated free lists 256/512/1024 B plus per-CPU magazines"]
    F --> G["40 ns allocation - no global lock"]
    H["100 ms RTT - 10 GB BDP"] --> I["return credits in groups of at least 64 KiB"]
    I --> J["adapt group size so that group greater or equal BDP divided by 1000"]
    J --> K["prevent advertised window from idling"]

---

D16.3 — A3 · Cross-Domain: Telco IMS/SIP Proxy, OPC UA Sessions, Satellite DTN Bundles

Enabling description. (a) Telco IMS/SIP. The stateful connection is a SIP dialog over SCTP/TCP; the placement descriptor is bound to a dialog ID rather than a 5-tuple, and media (RTP) is direct-placed while signalling is always copied so that a proxy can rewrite headers. (b) Industrial OPC UA. Sessions carry binary-encoded PublishResponse notifications; large HistoryRead results (> 128 KiB) are directly placed into the historian's pinned ring, while keep-alives and small Read responses take the copy path; certificate-based session validation gating the decision is recorded in the control block. (c) Satellite DTN (Bundle Protocol). Because contacts are episodic, the "connection" is a bundle session with a custody transfer record. The disclosure places bundles directly into a persistent staging buffer sized to more than the longest contact's BDP, holds them across link outages, and re-verifies the placement descriptor after each reacquisition; the decision uses predicted contact duration as an additional feature, which has no analogue in a terrestrial connection.

flowchart TD
    A["Stateful connection variant E1 to E7"] --> T1["Telco IMS or SIP proxy"]
    A --> T2["OPC UA industrial session"]
    A --> T3["Satellite DTN bundle session"]
    T1 --> T1a{"SIP signalling or RTP media ?"}
    T1a -->|"media"| T1b["direct place by dialog ID"]
    T1a -->|"signalling"| T1c["copy path - header rewrite required"]
    T2 --> T2a{"HistoryRead above 128 KiB ?"}
    T2a -->|"yes"| T2b["direct place into historian pinned ring"]
    T2a -->|"no"| T2c["copy path for keep-alives and small reads"]
    T3 --> T3a["add predicted contact duration to feature word"]
    T3a --> T3b["direct place into persistent buffer sized above contact BDP"]
    T3b --> T3c["revalidate descriptor after each reacquisition"]

---

D16.4 — A4 · AI State Migration, P4-Programmable Stateful Pipeline, On-Chain Session Attestation

Enabling description. Three integrations are disclosed. (i) AI-driven state migration: before a NIC firmware upgrade or a live-failover, an encoder learns a compact latent representation of the connection's decision state (a 6-layer autoencoder reducing 256 B TCBs to 24 B latents); migration transmits latents instead of full TCBs, halving migration time, and the decoder reconstructs a conservative TCB (copy-mode) when reconstruction error exceeds a threshold. (ii) P4-programmable stateful pipeline: placement decisions are compiled to P4-16 externs (register, meter, counter) in a Tofino-class pipeline so that operators can express the adaptive rule in the data-plane language itself. (iii) On-chain session attestation: for cross-organizational connections (e.g. B2B EDI or inter-carrier settlements), each session's decision policy hash and byte counters are attested periodically, enabling a third party to verify both that the agreed placement policy was used and that usage accounting is consistent.

sequenceDiagram
    participant A as Active NIC
    participant E as State encoder
    participant B as Standby NIC
    participant P4 as P4 stateful pipeline
    participant LED as Attestation ledger
    A->>E: 256 B TCBs
    E->>B: 24 B latents
    B->>B: decode; if error above threshold then conservative copy-mode TCB
    P4->>A: compiled register and meter externs for the adaptive rule
    A->>LED: policy hash and byte counters per epoch
    LED-->>B: verify policy compliance and usage accounting

---

D16.5 — A5 · Inverse: State-Migration Failure Handling, Copy-Only Stateless Fast Path, Deliberately Lossy Best-Effort Telemetry

Enabling description. Three inverse modes close the disclosure. (i) Migration-failure fallback: if the latent decoder's reconstruction error exceeds ε, or if the standby NIC rejects a TCB generation, the standby instantiates a stateless copy-only fast path (per-packet parse, no TCB store, all payload to the common pool); the peer sees no reset because the 4-tuple is preserved, and the application simply observes copy-mode latency until a full TCB sync completes. (ii) Forced statelessness: for connections whose TCB exceeds the available SRAM budget, the device deliberately drops the TCB and services the flow statelessly rather than evicting a live connection — a bounded-memory design choice. (iii) Deliberately lossy telemetry: for high-volume sensor fleets, placement is configured so that payload may be dropped (never retransmitted) once the staging pool exceeds a watermark, converting the reliable-stream guarantee into best-effort for that connection class and advertising a window that permits the peer to overwrite; this trades reliability for bounded memory and is used only for telemetry class traffic.

stateDiagram-v2
    [*] --> StatefulZeroCopy
    StatefulZeroCopy --> StatelessCopyFastPath : latent error above epsilon or TCB generation rejected
    StatelessCopyFastPath --> FullStateSync : standby requests full TCB resync
    FullStateSync --> StatefulZeroCopy : resync complete, no peer reset
    StatefulZeroCopy --> ForcedStateless : TCB larger than SRAM budget
    ForcedStateless --> StatelessCopyFastPath : serve flow without TCB
    StatefulZeroCopy --> DeliberatelyLossy : telemetry class and pool above watermark
    DeliberatelyLossy --> DeliberatelyLossy : payload may be dropped, never retransmitted
    DeliberatelyLossy --> StatefulZeroCopy : watermark cleared or class changed

---

3. Combination Prior Art Scenarios (patent arts combined with open-source standards)

Each scenario below is a specific, implementable combination asserted as obvious in view of (a) the open-source standard's public artifacts and (b) the adaptive-placement subject matter of US 7,826,350.

CP-1 — DPDK rte_flow + DMAdev (ioat) + hugepage mempool

Enabling description. DPDK exposes (i) rte_flow match/action rules offloadable to the NIC, (ii) a DMA device class (rte_dma_*, historically rte_ioat_*) for host-memory-to-host-memory copies driven by descriptor rings, and (iii) rte_mempool backed by 1 GiB/2 MiB hugepages with MEMPOOL_F_NO_CACHE_ALIGN and rte_mbuf external-buffer support. The combination: a rte_flow rule for TCP flows carries an action to select one of two destinations; a control-plane service reads rte_eth_dev_get_port_by_name queue stats plus a per-flow buffer-length histogram from the application's rte_ring, computes the cost inequality of D2.2, and installs either a direct action (payload DMA to the application's externally-registered mbuf area) or a staging action (payload DMA to a mempool element, followed by an rte_dma copy into the application's area at the offset computed by D2.4's predictor). The adaptive decision is a 40-line userspace policy service; no new hardware is required. This combination is directly reproducible from public DPDK releases and public documentation, and thus is prior art against any later claim to "adaptive" destination selection built on flow-offload plus a DMA engine.

flowchart LR
    A["NIC rte_flow rule per TCP flow"] --> B["Policy service reads queue stats and buffer-length histogram"]
    B --> C{"cost inequality says direct placement is cheaper ?"}
    C -->|"yes"| D["action: DMA payload to externally registered mbuf area"]
    C -->|"no"| E["action: DMA payload to rte_mempool element"]
    E --> F["rte_dma descriptor copy to application area at computed offset"]
    G["rte_mempool on 2 MiB hugepages"] --> E
    F --> H["rte_ring progress notification to application"]
    D --> H

CP-2 — Linux io_uring + AF_XDP + MSG_ZEROCOPY + registered buffers

Enabling description. io_uring provides asynchronous IORING_OP_RECV with provided buffers (IORING_OP_PROVIDE_BUFFERS / buffer rings), which is precisely a request-characteristic-driven destination selection surface: the kernel knows the posted buffer length at submission time. AF_XDP provides a zero-copy socket whose UMEM is a registered, pinned region. Combined with MSG_ZEROCOPY error-queue notifications and SO_ZEROCOPY, an implementation can decide per submission whether the receive goes to the UMEM frame directly (in-kernel XDP path, XDP_COPY mode disabled) or into a kernel socket buffer and is then copied to user memory by an io_uring worker using copy_to_user/process_vm_writev. The "characteristic" is sqe->addr, sqe->len, and the registered-buffer length; the decision is a length comparison plus a mapping-cost estimate. Because all primitives are in mainline Linux and publicly documented, the combination anticipates later claims to adaptive zero-copy receive driven by buffer length in a Linux context.

sequenceDiagram
    participant APP as Application
    participant IO as io_uring submission queue
    participant UMEM as AF_XDP UMEM (pinned)
    participant KRN as Kernel socket buffer
    participant PROG as Placement policy
    APP->>IO: recv submission with buffer length and address
    IO->>PROG: read posted buffer length and registered region
    PROG->>UMEM: if length above threshold, XDP zero-copy into frame
    PROG->>KRN: else receive into socket buffer
    KRN->>APP: copy_to_user by io_uring worker with completion
    UMEM-->>APP: MSG_ZEROCOPY completion via error queue

CP-3 — iWARP / RDMA (RFC 5040–5044, MPA/DDP) + RoCEv2 + libfabric FI_MR

Enabling description. The open IETF standard suite already standardizes Direct Data Placement: RFC 5041 (MPA), RFC 5042 (DDP), RFC 5043 (SCTP adaptation), RFC 5044 (marker PDU aligned framing) define a steering tag and a DDP segment that place upper-layer payload directly into a pre-posted tagged buffer with no intermediate copy. libfabric exposes the memory-registration resource (FI_MR) and fi_mr_reg semantics; RoCEv2 carries it over UDP/IP. The combination adds only an adaptive gate: a per-connection policy reads the posted receive-queue entry's length, the RNR-retry count, and the completion-queue latency, and elects either (a) tagged DDP straight into the application's registered MR, or (b) an untagged/FI_MR_LOCAL-only path that places into a bounce MR and then performs a DDP or fi_mr-mediated copy into the application MR at the correct offset. Since RFC 5042 already defines the direct-placement primitive and libfabric already defines the registration interface, the incremental adaptive selection is obvious to a PHOSITA.

flowchart TD
    A["Inbound RoCEv2 or iWARP packet"] --> B["MPA marker and DDP segment parse (RFC 5041 to 5044)"]
    B --> C{"adaptive gate: posted RQ entry length, RNR retries, CQ latency"}
    C -->|"prefer direct"| D["tagged DDP into application FI_MR"]
    C -->|"prefer staged"| E["untagged place into bounce MR"]
    E --> F["fi_mr mediated copy into application MR at computed offset"]
    D --> G["completion queue entry"]
    F --> G

CP-4 — eBPF/XDP + P4-16 + IEEE 802.1AS (gPTP)

Enabling description. XDP/eBPF provides in-kernel programmable per-packet decisions with a verifier-enforced safety envelope; P4-16 provides a hardware data-plane equivalent with register, meter, and counter externs; IEEE 802.1AS provides sub-microsecond synchronized timestamps at both the adaptor and the application. The combination: the eBPF program computes the placement decision from buffer length and credit state read from a BPF_MAP_TYPE_PERCPU_ARRAY, writes a packet steering tag into metadata; the P4 pipeline on the NIC interprets the tag and either redirects the payload to the application's registered region or to a common pool; gPTP timestamps are attached to each placement completion so that the decision loop closes on measured latency rather than an estimate. Every constituent is an open standard or an open-source component with published interfaces, so the combination is reproducible and disclosable.

flowchart LR
    A["Inbound packet"] --> B["XDP eBPF program - verifier-bounded"]
    B --> C["read buffer length and credits from PERCPU_ARRAY map"]
    C --> D["emit packet steering tag in metadata"]
    D --> E["P4-16 pipelines with register, meter, counter externs"]
    E --> F{"tag value"}
    F -->|"direct"| G["redirect payload to application registered region"]
    F -->|"staged"| H["place payload in common pool"]
    H --> I["copy into application region at offset"]
    J["IEEE 802.1AS gPTP timestamps"] --> K["close the decision loop on measured latency"]
    G --> K
    I --> K

---

4. Defensive-publication claim set (for prior-art effect)

The following are published as disclosures, not as patent claims, and are intended to establish prior art as of 2026-04-26:

1. A network adaptor that selects a payload destination using a truncated log-scaled score of posted-buffer length, smoothed RTT and queue occupancy, with hysteresis.
2. The adaptor of (1) wherein the scoring weights reside in non-volatile embedded MRAM and are generation-validated by the host driver.
3. An adaptor caching a placement decision per flow generation and re-evaluating it only on enumerated state deltas, to satisfy a sub-nanosecond per-packet budget.
4. A staging tier selected among CXL type-3 pooled memory, on-package HBM, and persistent memory, with a persistent undo log enabling exactly-once crash replay keyed by connection and sequence.
5. A cost-inequality boundary between direct placement and staged copy, recomputed as a function of ambient temperature and of PCIe generation.
6. A connection-independent staging pool with per-connection leases migratable across NICs.
7. A pool shard architecture with 64 shards, low/high watermarks, and RCU reclamation bound to receive-queue epochs.
8. A placement-decision program product delivered as any of a UEFI DXE driver, an FPGA partial bitstream, or an eBPF CO-RE object distributed as an OCI artifact.
9. A formally verified placement decision function with machine-checked invariants on descriptor validity and credit sufficiency.
10. An RL-optimized placement policy whose generation is anchored to a ledger and refused by the adaptor absent a cached anchor.
11. A temporal-convolutional predictor that pre-arms a speculative staging window and an offset reservation.
12. A Merkle-attested copy ledger with gPTP-derived timestamps.
13. A tamper-evident copy-only quarantine mode with TPM-gated release.
14. A battery mode inverting the invention into always-copy, polled, coalesced operation with D3cold entry.
15. A zero-window, per-connection graceful backpressure ladder for pool exhaustion.
16. A state hierarchy of decision shadow / full TCB / spilled cold state supporting 10⁷ connections with deterministic eviction.
17. Latent-space TCB migration with conservative reconstruction on decoder error.
18. A stateless copy-only fast path preserving the 4-tuple across a failed state migration, avoiding a peer reset.
19. A deliberately lossy, non-retransmitting placement class for telemetry traffic under pool pressure.
20. Any combination of (1)–(19) with DPDK rte_flow/DMAdev, io_uring/AF_XDP, iWARP DDP (RFC 5042), or eBPF/P4 pipelines.

---

5. Publication and dedication protocol

To maximize prior-art effect, publish this document in at least two independent, timestamped, publicly accessible channels:

1. Defensive publication registry — IP.com Defensive Publication or Research Disclosure, which issues a citable identifier and a permanent public record.
2. Preprint with DOI — Zenodo or arXiv (cs.NI), with the CC0 dedication and a declared author identity.
3. Cryptographic timestamp — OpenTimestamps or a public ledger anchor of the SHA-256 of this document's final byte stream.
4. Repository of record — a public Git repository with a signed tag, so that every enabling description and diagram has a verifiable commit time and the author can prove possession of the exact text.

Effect: a publication dated 2026-04-26 becomes prior art as of that date under AIA 35 U.S.C. § 102(a)(1) (publicly available printed publication) and can also be used under § 102(a)(2) only if it names the same inventive entity — which it deliberately does not, since it is authored by an unrelated party. Combinations in §3 above are additionally supported by pre-existing public open-source artifacts, so the incremental subject matter is obvious under § 103 as of each artifact's own publication date.

---

Caveat on the record: The assignment to SPEEDNIC LLC (recorded 2026-02-13) and the W.D. Tex. assertion (No. 7:26-cv-00148, filed 2026-04-16) are stated here only as verified provenance anchors. No statement in this document is a legal opinion on validity, infringement, or claim scope of US 7,826,350, and none of the derivatives above is asserted to read on any third-party product.