US 7702742

US Patent 7,702,742, titled "Mechanism for enabling memory transactions to be conducted across a lossy network," was issued on April 20, 2010, from an application filed on January 17, 2006. The original assignee was Fortinet Inc, and the current assignee is Athena Security LLP. The inventors are Bert H. Tanaka, Daniel J. Maltbie, and Joseph R. Mihelich.

Abstract:
The patent describes a network interface designed to facilitate remote programmed I/O over a "lossy" network, such as Ethernet, where packets may be dropped. This interface receives multiple memory transaction messages (MTMs), identifies their destination as a remote node, and determines each MTM's transaction type. It then creates network packets from these MTMs, assigning a sending priority to each packet based on the MTM's transaction type. These prioritized packets are sent into the lossy network. The network interface ensures that a specific subset of these packets, sharing a particular sending priority, are received by the remote node in the correct sequence. This mechanism enables remote programmed I/O to be reliably conducted across lossy networks.

Plain-Language Overview of Independent Claims:

• Independent Claim 1 (Method): This claim describes a method for reliably transmitting memory access requests over an unreliable network. A network interface first receives memory transaction messages (MTMs) from a local computer's memory controller. It figures out that these messages are meant for a remote computer and determines what kind of memory operation each message requests (e.g., read, write). For each MTM, the network interface creates a network packet, embedding the MTM's information, and assigns a priority to this packet based on the type of memory operation and the rules of the computer's internal bus. These prioritized packets are then sent across a network where packets can be lost. Finally, the method ensures that at least a specific group of these packets, those with the same priority, arrive at the remote computer in the correct order.

• Independent Claim 11 (Computer System): This claim describes a computer system built to perform reliable remote memory access. The system includes a local processor, a local memory controller, local memory, and a specialized network interface. This network interface is designed to receive MTMs from the memory controller, identify them as destined for a remote computer, and determine their transaction types. It then builds network packets from these MTMs, assigns priorities based on transaction type and bus protocol rules, and sends them over a lossy network. Crucially, the network interface also ensures that packets of a given priority arrive at the remote computer in the correct sequence.

• Independent Claim 19 (Network Interface): This claim focuses on the network interface itself. It specifies that the interface has components for: (1) receiving MTMs from a local memory controller (which follow a standard bus protocol); (2) determining that these MTMs are for a remote computer and identifying their transaction types; (3) composing network packets that encapsulate MTM information; (4) assigning sending priorities to these packets based on the MTM type and bus protocol ordering rules; (5) sending these prioritized packets into a lossy network, with the sending order influenced by their priorities; and (6) ensuring that at least a subset of packets with a particular priority are received by the remote computer in the proper order.

Litigation and Status:
The patent US7702742B2 is currently active and is scheduled to expire on October 1, 2028. The patent family is involved in litigation, with cases filed in the Texas Western District Court. Specific case numbers mentioned are 7:26-cv-00158, 7:26-cv-00061, and 7:26-cv-00025. Additionally, the patent family has seen its first worldwide family litigation filed [cite: The provided patent text].

A search of the CAFC 2026 dockets as of April 26, 2026, did not yield any specific cases directly involving US Patent 7,702,742.

Known litigation involving US Patent 7,702,742 is as follows:

1. Athena Security, LLP v. Dell Technologies Inc.

   • Jurisdiction: Texas Western District Court
   • Case Number: 7:26-cv-00025
   • Filing Date: January 23, 2026
   • Plaintiff(s): Athena Security, LLP (Nevada)
   • Defendant(s): Dell Technologies Inc. (Delaware)
   • Current Status/Outcome: This case was terminated on May 6, 2026, and intradistrict transferred to the Western District-Austin Division, assigned case number 1:26-cv-1197-ADA. Dell Technologies Inc. filed an answer to the amended complaint with a counterclaim and a motion to dismiss on May 4, 2026.

2. Athena Security, LLP v. Google LLC

   • Jurisdiction: Texas Western District Court
   • Case Number: 7:26-cv-00158
   • Filing Date: April 20, 2026
   • Plaintiff(s): Athena Security, LLP
   • Defendant(s): Google LLC
   • Current Status/Outcome: As of May 5, 2026, Google LLC was granted a 45-day extension to respond to the complaint, with a new deadline of July 2, 2026. The case has been referred to Magistrate Judge Derek T. Gilliland.

It's important to note that searches for case numbers 7:26-cv-00061 (identified in the patent text as part of the litigation family) yielded results for cases not involving US7702742 and filed in different jurisdictions (e.g., North Carolina Eastern District Court or documents pertaining to IRS regulations from 2006). Therefore, those specific filings are not included in the above list as direct litigation for US7702742.

Proceedings overview

A search of publicly available PTAB records indicates no AIA trial proceedings (Inter Partes Review, Post-Grant Review, or Covered Business Method) have been filed against US Patent 7,702,742. This means that all claims of the patent remain untested at the PTAB.

Strategic summary

As of today, all claims of US Patent 7,702,742 are UNTESTED by AIA trial proceedings. This presents a unique landscape for a defendant, as no claims have been canceled or sustained by the PTAB. Consequently, there is no estoppel arising from prior PTAB challenges that would prevent a new petitioner from raising any available prior art grounds under § 102 or § 103. The absence of PTAB activity suggests that the patent has not yet been aggressively targeted by defensive aggregators or prior defendants.

Recommended next steps

Since no PTAB activity exists for US Patent 7,702,742, a defendant facing assertion of this patent would have a full range of prior art defenses available at the PTAB. Potential next steps include:

• Prior Art Search: Conduct a thorough prior art search to identify strong invalidity grounds for an IPR or PGR petition.
• Validity Analysis: Perform a detailed claim construction and validity analysis against any identified prior art to assess the strength of a PTAB challenge.
• Monitoring: Continue to monitor PTAB dockets for any newly filed petitions against this patent.

Inventors

• Bert H. Tanaka: Employed by Woven Systems, Inc. at the time of filing.
• Daniel J. Maltbie: Employed by Woven Systems, Inc. at the time of filing.
• Joseph R. Mihelich: Employed by Woven Systems, Inc. at the time of filing.

The inventors assigned their interest to Woven Systems, Inc. on the filing date of the patent application, January 17, 2006. There is no indication from the provided information of all inventors departing the original assignee within 12 months of filing.

Original assignee

The original assignee listed on the issued patent US7702742B2 is Fortinet Inc. Fortinet is an operating company that primarily specializes in cybersecurity solutions, including firewalls, endpoint security, and network infrastructure. While the patent describes technology related to high-performance network interfaces for memory transactions, it cannot be definitively determined from the provided patent text or assignment records whether Fortinet Inc. shipped a product directly embodying these specific claims. Fortinet Inc. is currently an active, publicly traded operating company.

Assignment timeline

• 2006-01-17 (executed) / recorded 2009-07-31 — Reel 023030/0677

  • Conveyance: ASSIGNMENT
  • Assignor: MALTBIE, DANIEL J.; MIHELICH, JOSEPH R.; TANAKA, BERT H.
  • Assignee: WOVEN SYSTEMS, INC.
  • Correspondent: LATHROP & GAGE LC, 2345 GRAND BLVD STE 2400, KANSAS CITY, MO 64108-2618
  • Context: Original assignment of invention from inventors to Woven Systems, Inc.

• 2009-07-24 (executed) / recorded 2009-09-02 — Reel 023306/0200

  • Conveyance: ASSIGNMENT
  • Assignor: WOVEN SYSTEMS, INC.
  • Assignee: WOVEN (ASSIGNMENT FOR THE BENEFIT OF CREDITORS), LLC
  • Correspondent: BEYER LAW GROUP LLP, MARK A BORING, P.O. BOX 1687, CUPERTINO, CA 95015. This correspondent also appears on the subsequent entry.
  • Context: Transfer of assets as part of an assignment for the benefit of creditors, indicating financial distress of Woven Systems, Inc.

• 2009-07-24 (executed) / recorded 2009-09-02 — Reel 023306/0201

  • Conveyance: ASSIGNMENT
  • Assignor: WOVEN (ASSIGNMENT FOR THE BENEFIT OF CREDITORS), LLC
  • Assignee: FORTINET, INC.
  • Correspondent: BEYER LAW GROUP LLP, MARK A BORING, P.O. BOX 1687, CUPERTINO, CA 95015. This correspondent also appears on the previous entry.
  • Context: Acquisition of intellectual property from Woven Systems' creditors' assignee by Fortinet, Inc.

• 2025-11-19 (executed) / recorded 2025-12-04 — Reel 057030/0225

  • Conveyance: ASSIGNMENT
  • Assignor: FORTINET, INC.
  • Assignee: PALISADE TECHNOLOGIES, LLP
  • Correspondent: NEAL G. KILGORE, 1500 WEST EL CAMINO REAL, SUITE 210, MOUNTAIN VIEW, CA 94040. This correspondent also appears on the subsequent entry.
  • Context: Transfer from operating company (Fortinet) to a new entity, potentially for licensing or assertion purposes.

• 2025-11-19 (executed) / recorded 2025-12-04 — Reel 057030/0227

  • Conveyance: ASSIGNMENT
  • Assignor: PALISADE TECHNOLOGIES, LLP
  • Assignee: ATHENA SECURITY, LLP
  • Correspondent: NEAL G. KILGORE, 1500 WEST EL CAMINO REAL, SUITE 210, MOUNTAIN VIEW, CA 94040. This correspondent also appears on the previous entry.
  • Context: Consecutive transfer between two entities, ending at the current assignee, Athena Security, LLP.

Timeline diagram

timeline
    title Ownership of US 7702742
    2006 : Inventors to Woven Systems Inc
    2009 : Woven Systems to Woven Creditors LLC
         : Woven Creditors LLC to Fortinet Inc
    2010 : Patent issued
    2025 : Fortinet Inc to Palisade Tech LLP
         : Palisade Tech LLP to Athena Security LLP
    2026 : First litigation filed

NPE / troll-pattern signals

1. Shell-entity transfer — Present. The patent transferred from Fortinet Inc., an operating company, to Palisade Technologies, LLP (Reel 057030/0225, executed 2025-11-19). This was followed by a transfer from Palisade Technologies, LLP to Athena Security, LLP (Reel 057030/0227, executed 2025-11-19). Both Palisade Technologies, LLP and Athena Security, LLP, with their "LLP" suffix and sequential transfers, exhibit characteristics of shell entities.

2. Known asserter in the chain — Present. Athena Security, LLP is the current assignee and is listed as having litigation associated with this patent family, with cases filed in the Texas Western District Court in 2026 [cite: The provided patent text]. This directly identifies Athena Security, LLP as an active patent asserter.

3. Repeat correspondent across the chain — Present. Neal G. Kilgore, located at 1500 West El Camino Real, Suite 210, Mountain View, CA 94040, is listed as the correspondent for both the transfer from Fortinet Inc. to Palisade Technologies, LLP (Reel 057030/0225) and the subsequent transfer from Palisade Technologies, LLP to Athena Security, LLP (Reel 057030/0227). This recurrence across consecutive assignments involving suspected shell entities is a strong signal. Mark A Boring of Beyer Law Group LLP also appears on two earlier, consecutive assignments related to the Woven Systems, Inc. insolvency (Reel 023306/0200 and 023306/0201).

4. Cascading transfers — Present. There were two consecutive assignments executed on the same day, 2025-11-19, from Fortinet Inc. to Palisade Technologies, LLP, and then from Palisade Technologies, LLP to Athena Security, LLP (Reel 057030/0225 and 057030/0227). These rapid, sequential transfers to entities with similar naming patterns and a shared correspondent are a strong indicator.

5. Pre-litigation transfer — Present. The assignments to Palisade Technologies, LLP and Athena Security, LLP were executed on November 19, 2025, and recorded on December 4, 2025 (Reel 057030/0225, 057030/0227). Litigation involving this patent family began in 2026, as evidenced by case filings in the Texas Western District Court (e.g., 7:26-cv-00158, 7:26-cv-00061, 7:26-cv-00025), placing these transfers within six months prior to the first infringement suits [cite: The provided patent text].

6. Bankruptcy fire-sale — Present. The transfer from Woven Systems, Inc. to WOVEN (ASSIGNMENT FOR THE BENEFIT OF CREDITORS), LLC, executed on July 24, 2009 (Reel 023306/0200), explicitly indicates an "ASSIGNMENT FOR THE BENEFIT OF CREDITORS," which is a form of insolvency proceeding or fire-sale.

7. Privateering — Unclear. While Fortinet, an operating company, transferred the patent to an NPE (Athena Security, LLP), there is no explicit information to suggest this transfer was made to assert the patent on Fortinet's behalf against competitors.

8. Defensive aggregator (anti-NPE) — Not present. The final assignee is Athena Security, LLP, which is identified as an asserter, not a defensive aggregator.

Verdict

NPE — high confidence. The chain of assignments, particularly the transfers in late 2025 (Reel 057030/0225, 057030/0227), exhibit multiple strong NPE signals: shell-entity transfers, cascading transfers, a repeat correspondent, and pre-litigation transfers leading to a known asserter (Athena Security, LLP) involved in active litigation in 2026. The initial bankruptcy sale of the patent from Woven Systems to Fortinet (Reel 023306/0200, 023306/0201) also provided an opportunity for the patent to enter the secondary market.

For verification, see the USPTO Patent Assignment Search for patent number 7702742: https://assignmentcenter.uspto.gov/.

Here is an analysis of the most relevant prior art for US Patent 7,702,742, based on the patent's own citations:

1. US5572688A

• Full Citation: US5572688A, Chen et al., "Method and apparatus for efficient communication in a data processing system"
• Publication/Filing Date: Published: November 5, 1996; Filed: October 28, 1994.
• Brief Description: This patent describes a communication system for efficient data transfer between processing nodes in a multiprocessing environment, utilizing a coherent communication adapter to handle memory access requests and maintain cache coherence. It involves request and response queues and a snooping mechanism.
• Potential Anticipation under 35 U.S.C. § 102: While it addresses inter-node memory access and data transfer, it does not explicitly disclose operating over a "lossy" network, assigning network sending priorities based on processor bus protocol transaction types, or the specific retransmission strategy (resending a timed-out packet and all subsequent packets of the same priority) employed by US7702742 to ensure ordered delivery across an unreliable network. Therefore, it does not appear to anticipate all elements of independent claims 1, 11, or 19.

2. US6058448A

• Full Citation: US6058448A, Dobbins et al., "Scalable coherent interface (SCI) using dynamic address translation"
• Publication/Filing Date: Published: May 2, 2000; Filed: October 22, 1997.
• Brief Description: This patent describes a system for a Scalable Coherent Interface (SCI) that allows multiple processors to share memory using dynamic address translation. It enables remote memory access by mapping remote memory addresses into a local address space and uses SCI packets for requests and responses, focusing on coherence and scalability.
• Potential Anticipation under 35 U.S.C. § 102: This patent relies on the SCI, a proprietary network known for its inherent reliability and ordered delivery. It does not address the challenges of a "lossy" network or the specific mechanisms in US7702742 for prioritizing network packets based on processor bus protocol transaction types and implementing a retransmission scheme to overcome packet loss and reordering in such a network. Thus, it does not anticipate the core inventive aspects of US7702742 related to lossy network handling.

3. US6243763B1

• Full Citation: US6243763B1, Arimilli et al., "Asynchronous packet passing for memory access operations"
• Publication/Filing Date: Published: June 5, 2001; Filed: September 30, 1999.
• Brief Description: This patent describes a data processing system that performs memory access operations using asynchronous packet passing, assigning sequence numbers to packets to ensure correct ordering of load and store operations even with multiple outstanding requests.
• Potential Anticipation under 35 U.S.C. § 102: While it addresses packet ordering and uses sequence numbers for memory access, it does not explicitly disclose operating over a "lossy" network with the specific retransmission logic of US7702742. Crucially, it lacks the teaching of assigning different sending priorities to network packets based on processor bus protocol transaction types (e.g., posted, non-posted, response) and transmitting them according to these priorities across an unreliable network. Therefore, it is unlikely to anticipate all elements of independent claims 1, 11, or 19.

4. US6460114B1

• Full Citation: US6460114B1, Gibson et al., "Coherent memory over a network"
• Publication/Filing Date: Published: October 8, 2002; Filed: June 27, 2000.
• Brief Description: This patent describes a system and method for supporting coherent memory operations across a network, involving a network interface that intercepts memory requests and directs them to local or remote memory, while maintaining data consistency.
• Potential Anticipation under 35 U.S.C. § 102: This patent focuses on cache coherence for memory accessed over a network. However, its abstract and general description do not indicate that it specifically addresses the challenges of a "lossy" network, such as dropped packets and reordering. It also does not disclose assigning network sending priorities based on processor bus protocol transaction types or the specific retransmission strategy to ensure reliable, in-order delivery over an unreliable network as taught by US7702742.

5. US6505260B1

• Full Citation: US6505260B1, Blumrich et al., "Method and apparatus for enabling processor to memory and memory to memory communications in a data processing system having a scalable coherent interface"
• Publication/Filing Date: Published: January 7, 2003; Filed: September 29, 2000.
• Brief Description: This patent describes enabling processor-to-memory and memory-to-memory communications in a data processing system using a Scalable Coherent Interface (SCI) network, allowing nodes to efficiently access remote memory.
• Potential Anticipation under 35 U.S.C. § 102: Similar to US6058448A, this patent operates within the context of an SCI network, which is inherently reliable and ordered. It does not teach the specific mechanisms required to ensure reliable and ordered memory transactions over a "lossy" network, including the prioritization of network packets based on processor bus protocol transaction types or the retransmission scheme described in US7702742.

6. US6745269B1

• Full Citation: US6745269B1, Hughes et al., "System and method for providing direct access to a memory of a remote device via a network"
• Publication/Filing Date: Published: June 1, 2004; Filed: October 19, 2001.
• Brief Description: This patent describes a system and method for direct access to remote memory via a network, where a network interface translates local memory requests into network packets for transparent and efficient remote memory access, potentially using RDMA.
• Potential Anticipation under 35 U.S.C. § 102: While it discusses remote memory access, the patent does not explicitly detail solutions for a "lossy network" or the specific prioritization scheme for network packets based on processor bus protocol transaction types. The retransmission strategy of US7702742, particularly resending all subsequent packets of the same priority, is also not evident. Thus, it lacks key inventive elements of US7702742.

7. US6792476B1

• Full Citation: US6792476B1, Dobbins et al., "Network fabric interconnect with memory mapping"
• Publication/Filing Date: Published: September 14, 2004; Filed: June 15, 2001.
• Brief Description: This patent describes a network fabric interconnect for coupling processing units, enabling memory mapping, address translation, and communication between processors and memory controllers for high-performance distributed computing.
• Potential Anticipation under 35 U.S.C. § 102: This patent generally describes a network interconnect with memory mapping, but its abstract does not provide details on addressing the issues of a "lossy network" or the specific prioritization and retransmission mechanisms of US7702742. It focuses on a "network fabric interconnect," typically implying a reliable and controlled environment, rather than a general-purpose lossy network.

8. US6854002B1

• Full Citation: US6854002B1, Blumrich et al., "Low latency memory-to-memory communication system for data processing networks"
• Publication/Filing Date: Published: February 8, 2005; Filed: October 11, 2001.
• Brief Description: This patent describes a low-latency memory-to-memory communication system for data processing networks, particularly optimized for use with a Scalable Coherent Interface (SCI), focusing on minimizing latency for remote memory accesses.
• Potential Anticipation under 35 U.S.C. § 102: Like other SCI-based references, this patent operates within a framework of inherent network reliability. It does not address the problem of reliable and ordered communication over a "lossy network" using the specific MTM transaction-type-based prioritization and retransmission scheme disclosed in US7702742.

9. US6910086B2

• Full Citation: US6910086B2, Gaskins et al., "Memory controller having a network interface unit"
• Publication/Filing Date: Published: June 21, 2005; Filed: June 21, 2002.
• Brief Description: This patent describes a memory controller that integrates a network interface unit (NIU), allowing it to function as a network endpoint and handle memory access requests from both local processors and remote devices over a network.
• Potential Anticipation under 35 U.S.C. § 102: This patent describes a system component (memory controller with integrated network interface) relevant to remote memory access. However, its abstract does not detail how it specifically addresses the challenges of a "lossy network," including the prioritization of network packets based on processor bus protocol transaction types or the specific retransmission logic of US7702742 to ensure reliable, ordered delivery.

10. US20020059483A1

• Full Citation: US20020059483A1, Gibson et al., "Network-to-memory transaction system and method"
• Publication/Filing Date: Published: May 16, 2002; Filed: October 17, 2001.
• Brief Description: This patent application describes a network-to-memory transaction system where a network interface unit processes memory requests originating from a network and directs them to local memory.
• Potential Anticipation under 35 U.S.C. § 102: This application describes the receiving end of network-based memory transactions. It does not, however, describe the sending-side mechanisms of US7702742 for handling a "lossy network," particularly the assignment of network sending priorities based on processor bus protocol transaction types and the retransmission strategy for ensuring ordered delivery across such a network.

11. US20030046429A1

• Full Citation: US20030046429A1, Hughes et al., "System and method for transparent remote memory access"
• Publication/Filing Date: Published: March 6, 2003; Filed: October 19, 2001.
• Brief Description: This patent application describes a system and method for transparent remote memory access, allowing a local device to access remote memory as if it were local, via a network interface that translates requests into network packets.
• Potential Anticipation under 35 U.S.C. § 102: This application focuses on transparent remote memory access. Similar to its granted counterpart (US6745269B1), it does not detail solutions for a "lossy network," prioritized packet transmission based on processor bus protocol transaction types, or the specific retransmission mechanism of US7702742 for guaranteed in-order delivery over an unreliable network.

12. US20040054796A1

• Full Citation: US20040054796A1, Blumrich et al., "Mechanisms for implementing a shared memory over a switched network"
• Publication/Filing Date: Published: March 18, 2004; Filed: September 17, 2002.
• Brief Description: This patent application describes mechanisms for implementing shared memory over a switched network (e.g., InfiniBand), including address translation and managing coherence and synchronization, using transaction identifiers and queues.
• Potential Anticipation under 35 U.S.C. § 102: This application discusses shared memory over a switched network, typically assumed to be reliable. While it deals with ordering using transaction identifiers and queues, it does not explicitly teach addressing a "lossy network" or the unique combination of assigning network sending priorities based on processor bus protocol transaction types, ordering transmission based on these priorities, and implementing the specific retransmission strategy (resending timed-out packets and all subsequent packets of the same priority) to overcome the challenges of a lossy network, as claimed in US7702742.

13. US20040078519A1

• Full Citation: US20040078519A1, Blumrich et al., "Network interface supporting virtualized direct memory access"
• Publication/Filing Date: Published: April 22, 2004; Filed: October 18, 2002.
• Brief Description: This patent application describes a network interface that supports virtualized direct memory access (DMA), enabling applications to directly access remote memory with improved performance, involving address translation and access rights management over a network.
• Potential Anticipation under 35 U.S.C. § 102: This application focuses on virtualized DMA for remote memory access. Its abstract does not describe mechanisms for addressing the specific problems of a "lossy network," such as prioritizing network packets based on processor bus protocol transaction types or the specific retransmission scheme to ensure reliable, in-order delivery over an unreliable network, which are central to US7702742.

14. US20050015509A1

• Full Citation: US20050015509A1, Gaskins et al., "Multi-port memory hub with direct attached network interface"
• Publication/Filing Date: Published: January 20, 2005; Filed: June 21, 2002.
• Brief Description: This patent application describes a multi-port memory hub with a direct-attached network interface, acting as an interface between processors, memory, and a network to enable efficient remote memory access.
• Potential Anticipation under 35 U.S.C. § 102: This application describes a hardware architecture for remote memory access. While providing a relevant system component, its abstract does not detail the methodological innovations of US7702742 for handling a "lossy network," including the specific prioritization of network packets based on processor bus protocol transaction types and the retransmission strategy for guaranteeing ordered delivery.

15. US20050060431A1

• Full Citation: US20050060431A1, Arimilli et al., "High performance architecture for a multi-node, single-system-image computer system"
• Publication/Filing Date: Published: March 17, 2005; Filed: September 15, 2003.
• Brief Description: This patent application describes a high-performance architecture for a multi-node, single-system-image computer system, detailing techniques for efficient inter-node communication and memory access to present multiple nodes as a single system.
• Potential Anticipation under 35 U.S.C. § 102: This application describes a high-level architecture for multi-node systems. However, its abstract does not specify the mechanisms for addressing a "lossy network" or the inventive priority-based transmission and retransmission scheme of US7702742 for memory transaction messages (MTMs). The focus is on overall system efficiency rather than the specific problem of reliable, ordered communication of processor bus protocol transactions across a lossy network.

Obviousness Analysis under 35 U.S.C. § 103 for US Patent 7,702,742

This analysis identifies combinations of prior art references that would render the claims of US Patent 7,702,742 obvious to a person having ordinary skill in the art (PHOSITA) as of the priority date of January 18, 2005. The motivation for combining these references stems from the known problem of enabling cost-effective and efficient remote programmed I/O over commodity lossy networks, a problem explicitly articulated in the patent's background.

Problem Addressed by the Invention

The patent acknowledges that while distributed computing systems benefit from remote memory access via programmed I/O, standard commodity networks like Ethernet are "lossy" (i.e., they may drop or reorder packets). This inherent unreliability prevents them from meeting the processor's two main expectations for memory transactions: (1) MTMs must be processed in an order consistent with the processor bus protocol, and (2) MTMs cannot be dropped or ignored. Proprietary networks (e.g., SCI, DEC memory channel) previously used for this purpose were expensive, non-standard, and incompatible. The invention aims to overcome these limitations by providing a mechanism to enable remote programmed I/O across lossy networks.

Elements of Independent Claims (Claims 1, 11, and 19)

The independent claims describe a system, method, or network interface with the following key functionalities:

1. Receiving Memory Transaction Messages (MTMs) from a local memory controller, conforming to a processor bus protocol.
2. Determining MTMs are destined for a particular remote node.
3. Determining a transaction type for each MTM (e.g., posted request, non-posted request, response).
4. Composing network packets to encapsulate MTM information.
5. Assigning a sending priority to each network packet based on the MTM's transaction type and the ordering rules of the processor bus protocol.
6. Organizing network packets into groups (e.g., queues) based on sending priority.
7. Sending the network packets into a lossy network, with the sending order determined, at least partially, by their priorities.
8. Ensuring that at least a subset of network packets having a particular sending priority are received by the remote node in a proper sequence (e.g., using sequence numbers, acknowledgements, and retransmitting unacknowledged packets and all subsequent packets within that priority stream).

Prior Art Landscape and PHOSITA Knowledge (as of 2005)

A PHOSITA in 2005 would possess knowledge in several relevant technical areas, many of which are explicitly or implicitly referenced in the patent:

• Processor Bus Protocols (Reference A): Standard computer architecture and bus specifications (e.g., PCI, PCI Express, or CPU vendor specifications) would disclose different types of memory transaction messages (e.g., posted writes, non-posted reads, responses) and their associated ordering rules, as summarized in FIG. 4 of the patent.
• Remote Memory Access / Distributed Shared Memory (DSM) (Reference B): Techniques for accessing memory on a remote node as if it were local were known, including mapping remote memory into a local address space and encapsulating memory requests into network messages. The patent specifically mentions proprietary solutions like SCI (Scalable Coherent Interface, IEEE Std 1596-1992) and DEC Memory Channel as prior art in this domain.
• Lossy Networks (e.g., Ethernet): The characteristics of commodity networks like Ethernet, including their propensity to drop or reorder packets, were well-understood.
• Network Quality of Service (QoS) (Reference C): Mechanisms for prioritizing network traffic, such as priority queuing, weighted fair queuing, and differentiated services (DiffServ, e.g., IETF RFCs 2474, 2475 from 1998; IEEE 802.1p for Layer 2 priority), were well-established for managing traffic in networks, including those that are lossy.
• Reliable Data Transfer Protocols (ARQ) (Reference D): Fundamental networking protocols like TCP (Transmission Control Protocol) provided robust mechanisms for ensuring reliable, in-order delivery of data over unreliable underlying networks using sequence numbers, acknowledgements, and retransmission strategies (e.g., Go-Back-N or Selective Repeat, as described in standard networking textbooks). The patent's "Prior art keywords" include "network," "queue," "packet," "packets," and "sending," all pointing to general networking concepts.

Obviousness Argument: Combination of References

A PHOSITA, motivated by the desire to leverage inexpensive, commodity lossy networks (e.g., Ethernet) for remote programmed I/O, thereby avoiding the high cost and incompatibility of proprietary solutions, would have found it obvious to combine the teachings of References A, B, C, and D as follows:

1. Establishing Remote Memory Access (Elements 1, 2, 4):

   • Reference B would teach a PHOSITA how to implement remote memory access, including receiving MTMs at a local component (e.g., a network interface), determining their remote destination, and encapsulating them into network packets for transmission. This addresses the foundational aspects of extending local memory access to a remote node.

2. Mapping Processor Bus Priorities to Network Priorities (Elements 3, 5, 6, 7):

   • Recognizing that processor bus protocols (Reference A) dictate strict ordering rules based on MTM transaction types (e.g., posted requests often bypass other transaction types, as illustrated in FIG. 4), and that a processor expects these rules to be upheld even for remote memory access, a PHOSITA would be motivated to preserve this ordering across the network.
   • Knowing that network QoS mechanisms (Reference C) provide the capability to assign priorities to packets and implement priority-based queuing and sending, it would be an obvious design choice to map the established processor bus MTM priorities (e.g., posted request > response > non-posted request) directly to network packet sending priorities. This mapping ensures that the relative ordering expected by the processor for different transaction types is reflected in the network's packet transmission order. For instance, packets encapsulating posted write MTMs (highest bus priority) would be assigned the highest network priority and sent first from priority-based queues (Reference C).

3. Ensuring Reliable and In-Order Delivery Per Priority (Element 8):

   • Since the target network is "lossy" and cannot guarantee delivery or in-order arrival (as per general knowledge), a PHOSITA would naturally turn to reliable data transfer protocols (Reference D).
   • To meet the processor's expectation that MTMs are not dropped and are processed in order, a PHOSITA would find it obvious to apply an Automatic Repeat Request (ARQ) mechanism. Given that packets are now prioritized and queued (as per Reference C and the mapping in point 2), a PHOSITA would recognize the need to ensure in-order delivery within each priority stream. This is crucial because processing an out-of-order memory transaction can lead to serious errors like data coherency issues or deadlocks, as noted in the patent.
   • A common ARQ strategy, such as a Go-Back-N approach where a timed-out packet and all subsequent packets in its stream are retransmitted, would be an obvious choice to ensure strict sequential delivery for that specific priority stream. The use of linked-lists to track sent but unacknowledged packets within each priority group (as described in FIGS. 8 and 9 of the patent) is a conventional data structure for managing such ARQ retransmission buffers (Reference D). Similarly, the remote node's behavior of dropping out-of-sequence packets until the expected one arrives is a known method to enforce strict ordering for applications requiring it (Reference D).

By combining these known elements—processor bus protocol semantics, remote memory access techniques, network QoS, and reliable data transfer protocols—a PHOSITA would arrive at the claimed invention as an obvious solution to the long-standing problem of efficiently and reliably conducting remote programmed I/O over commodity lossy networks, thereby achieving the desired goals of cost-effectiveness and compatibility.

To get the most accurate and up-to-date information regarding US Patent 7,702,742 directly from the USPTO, one would typically use the Patent Center or Patent Public Search tools available on the USPTO website. The USPTO does not calculate expiration dates for patents, but provides a downloadable calculator and guides on how to obtain the necessary information to estimate the expiration date.

Based on the provided patent text and general patent law:

• Patent Term Adjustments (PTA): Patent Term Adjustment (PTA) can extend the term of a U.S. patent to compensate for delays by the USPTO during the prosecution of a utility or plant patent application. This applies to applications filed on or after May 29, 2000. Delays can include failure to issue a first office action within 14 months, respond to an applicant's reply within four months, or issue the patent within three years of the actual filing date. The specific amount of PTA for US7702742 would be detailed in the Issue Notification Letter that was mailed approximately three weeks prior to the patent's issuance. This information is not explicitly provided in the patent document itself but would be part of its official prosecution history accessible via USPTO search tools.
• Patent Term Extensions (PTE): Patent Term Extensions (PTE) are available for patents on certain human drugs, food or color additives, medical devices, animal drugs, and veterinary biological products to restore time lost during pre-market government regulatory review. Since US Patent 7,702,742 describes a mechanism for memory transactions across a lossy network, it is highly unlikely to be eligible for PTE, as it does not fall into these categories.
• Continuation Applications: A continuation application allows an applicant to pursue additional claims based on the same specification and drawings as a previously filed "parent" application, while retaining the earlier priority date. It is essentially a new application with new claims but the same underlying invention as the parent.
• Divisional Applications: A divisional application is a specific type of continuing application that results when the USPTO determines that a parent application contains more than one invention and issues a restriction requirement. The applicant then files a divisional application to pursue claims directed to the invention(s) not elected in the parent application, also retaining the priority date of the original application.
• Related Family Members: The patent states that it claims the benefit of U.S. Provisional Application Ser. No. 60/645,000, filed on January 18, 2005. This provisional application is a family member. The patent also lists US20090319634A1 as another version and US12/762,407 as a priority to it [cite: The provided patent text]. Patent families link patent iterations back to a priority date and can include international filings. To fully detail all related family members, a comprehensive search using USPTO or international patent search tools would be required.
• Projected Expiration Date: The patent is currently active and has a stated expiration date of October 1, 2028 [cite: The provided patent text]. For utility patents filed on or after June 8, 1995, the term generally expires 20 years from the earliest filing date of the application, subject to any PTA or terminal disclaimers. The filing date for US7702742 is January 17, 2006, and it claims priority to a provisional application filed on January 18, 2005. The expiration date of October 1, 2028, indicates that there has been an adjustment to the standard 20-year term from the earliest priority date (January 18, 2005), which would normally lead to an expiration date around January 18, 2025. This adjustment is likely due to Patent Term Adjustment (PTA) as a result of USPTO delays in prosecution. However, without access to the official USPTO patent prosecution history for US7702742, the exact PTA calculation cannot be determined here.

Defensive Disclosure: Derivative Works for US Patent 7,702,742

This document describes a series of derivative works and extensions for the technology disclosed in US Patent 7,702,742, "Mechanism for enabling memory transactions to be conducted across a lossy network." The purpose of this defensive disclosure is to expand the scope of prior art, making future incremental improvements to reliable remote programmed I/O over lossy networks, or applications thereof, potentially obvious or non-novel to a Person Having Ordinary Skill in the Art (PHOSITA). The derivations focus on various technical axes, ensuring the descriptions are technically enabling and include architectural or flow diagrams.

Core Claim Summary of US7702742 (for context, not repeated in output)

The independent claims (1, 11, 19) of US7702742 generally describe:

• Receiving Memory Transaction Messages (MTMs) from a local memory controller, conforming to a processor bus protocol.
• Determining remote destination and transaction type for each MTM (e.g., posted request, non-posted request, response).
• Composing network packets from MTMs.
• Assigning sending priority to each network packet based on the MTM's transaction type and the ordering rules of the processor bus protocol.
• Organizing network packets into groups (e.g., queues) based on sending priority.
• Sending prioritized packets into a lossy network, with sending order influenced by priorities.
• Ensuring a subset of packets with a particular priority are received by the remote node in the proper sequence (e.g., using sequence numbers, acknowledgements, and retransmitting unacknowledged packets and all subsequent packets within that priority stream).

---

Derivative Variations

1. Material & Component Substitution

Derivative 1.1: Optoelectronic Network Interface with FPGA-based Protocol Engine

• Axis: Material & Component Substitution
• Enabling Description: This derivative replaces the conventional copper-based Ethernet physical layer and general-purpose network interface controller (NIC) logic with an optoelectronic network interface unit (O-NIU) and a Field-Programmable Gate Array (FPGA)-based protocol engine. The O-NIU utilizes vertical-cavity surface-emitting lasers (VCSELs) for optical signal transmission and photodiodes for reception, communicating over multi-mode or single-mode optical fibers to an optical network switch. The FPGA is specifically programmed to implement the MTM reception, destination determination, transaction type identification, packet composition, priority assignment, queue management (using on-chip block RAMs for queues), priority-based sending, and reliable delivery mechanisms (sequence numbering, ACK processing, retransmission logic via a retransmission buffer in high-speed external DDR4 DRAM) as described in US7702742. The FPGA design allows for custom, high-speed serialization/deserialization (SerDes) of MTMs into optical packets, offloading significant processing from the host CPU and achieving deterministically low latency in the priority processing and transmission stages. The retransmission buffer management uses a circular buffer approach in the DDR4, with pointers managed by the FPGA logic to track acknowledged and unacknowledged packets per priority stream.

flowchart TD
    A[Local Processor/Memory Controller] --> B(O-NIU with FPGA Protocol Engine)
    B -- MTMs --> C{MTM Parser & Type/Dest Determiner}
    C --> D{Packet Composer & Priority Assigner}
    D --> E{Priority Queues (FPGA Block RAM)}
    E -- Ordered Tx --> F[Optical SerDes]
    F --> G(Optical Network Link)
    G --> H[Remote O-NIU]
    H -- ACKs/Seq #s --> I{Retransmission Manager (FPGA + DDR4)}
    I -- Resend if Timeout --> F
    I -- Remove Acknowledged --> E

Derivative 1.2: Memristor-Enhanced Network Interface with Non-Volatile Packet Queues

• Axis: Material & Component Substitution
• Enabling Description: This variation introduces memristor-based crossbar arrays as the primary packet buffering mechanism within the network interface and employs specialized Memristor-Based Logic (MBL) for certain high-speed protocol processing tasks. Instead of volatile DRAM or SRAM, packet queues for different priorities are implemented using non-volatile memristor memory arrays. This allows the network interface to maintain packet state and queued MTMs even during power loss or system resets without requiring explicit saves to persistent storage, enabling "instant-on" recovery of network transactions. The MBL components accelerate tasks such as sequence number comparison for incoming ACKs, priority-based arbitration for outgoing packets, and potentially checksum calculations, leveraging the inherent analog and parallel processing capabilities of memristors for low-power, high-density operations. The network interface incorporates dedicated power management circuitry to manage memristor states. The retransmission buffer is also implemented using these memristor arrays, ensuring persistent tracking of unacknowledged packets.

classDiagram
    class LocalNode {
        Processor
        MemoryController
    }
    class MemristorNIC {
        +MTMReceiver()
        +DestTypeDeterminer()
        +PacketComposer()
        +PriorityAssigner()
        +MemristorQueues
        +MBLProtocolEngine
        +PacketSender()
        +RetransmissionMonitor()
    }
    class MemristorQueues {
        <<Non-Volatile>>
        Priority1Queue: MemristorArray
        Priority2Queue: MemristorArray
        Priority3Queue: MemristorArray
    }
    class MBLProtocolEngine {
        <<Hardware Accelerator>>
        SequenceComparator
        PriorityArbitrator
    }
    LocalNode --* MemristorNIC
    MemristorNIC -- MemristorQueues
    MemristorNIC -- MBLProtocolEngine
    MemristorNIC -- NetworkLink : Lossy

Derivative 1.3: Quantum-Resistant Cryptographic Network Interface

• Axis: Material & Component Substitution
• Enabling Description: This derivative focuses on securing remote memory transactions against quantum computing threats. The network interface, implemented as a hardware security module (HSM) with integrated networking capabilities, incorporates quantum-resistant cryptographic algorithms (e.g., lattice-based cryptography for key exchange, hash-based signatures for authentication) for encrypting MTMs within network packets and authenticating acknowledgements. Instead of relying solely on sequence numbers and ACKs, each packet and ACK is cryptographically signed and encrypted to prevent malicious injection, alteration, or replay attacks across the lossy network. The hardware within the network interface includes dedicated processing units (e.g., specialized ASICs) for rapid execution of these complex post-quantum cryptography (PQC) primitives, ensuring that the overhead does not negate the performance benefits of prioritized transmission. Key management for PQC is handled by a secure element within the NIC, with periodic re-keying. The reliable delivery mechanism of US7702742 is augmented with cryptographic integrity checks on received sequence numbers and MTM content.

sequenceDiagram
    participant LP as Local Processor
    participant LMC as Local Memory Controller
    participant LNI_QC as Local NI (Quantum-Resistant)
    participant LN as Lossy Network
    participant RNI_QC as Remote NI (Quantum-Resistant)
    participant RMC as Remote Memory Controller
    participant RP as Remote Processor

    LP->LMC: MTM Request (Read/Write)
    LMC->LNI_QC: MTM
    LNI_QC->LNI_QC: Determine Type, Assign Priority, Compose Packet (Seq #)
    LNI_QC->LNI_QC: Encrypt & Sign Packet (PQC)
    LNI_QC->LN: Send Encrypted Packet (Prio-based)
    alt Packet Lost
        LN--xLNI_QC: No ACK received (timeout)
        LNI_QC->LN: Resend (PQC-protected) timed-out & subsequent packets
    else Packet Arrives
        LN->RNI_QC: Encrypted Packet
        RNI_QC->RNI_QC: Decrypt & Verify Signature (PQC)
        RNI_QC->RNI_QC: Validate Sequence Number
        RNI_QC->RMC: MTM to be processed
        RMC->RP: Access Remote Memory
        RP->RMC: Response (if non-posted)
        RNI_QC->RNI_QC: Compose ACK (Seq #)
        RNI_QC->RNI_QC: Encrypt & Sign ACK (PQC)
        RNI_QC->LN: Send Encrypted ACK
        LN->LNI_QC: Encrypted ACK
        LNI_QC->LNI_QC: Decrypt & Verify ACK
        LNI_QC->LNI_QC: Remove Packet from Retransmission Buffer
    end

2. Operational Parameter Expansion

Derivative 2.1: Ultra-High Frequency Trading (HFT) Remote I/O with Sub-microsecond Determinism

• Axis: Operational Parameter Expansion
• Enabling Description: This derivative optimizes US7702742 for ultra-low latency, sub-microsecond determinism required in High-Frequency Trading (HFT) environments over potentially lossy data center networks (e.g., congested Ethernet or InfiniBand in shared infrastructure). The network interface employs custom FPGA logic and high-speed SerDes (e.g., 400Gbps+) for packet processing. MTMs representing critical trade orders (posted requests for market data updates) are assigned the absolute highest priority. Non-posted requests (e.g., query for account balance) have lower priority, and responses are intermediate. Hardware-level timestamping (e.g., using PTP/NTP synchronized clocks) is integrated into each packet and ACK to precisely measure and control latency jitter. The retransmission timeout mechanism is extremely aggressive (e.g., tens of nanoseconds), and rather than simple retransmission, may involve speculative execution at the remote node or redundant transmission across multiple diverse paths for critical transactions to guarantee near-zero observable loss. Queues are implemented in extremely low-latency SRAM with hardware arbiters, minimizing software overhead.

graph TD
    A[HFT Application] --> B(Local Market Data Controller)
    B -- MTMs (Order, Quote) --> C[HFT-Optimized NI]
    C -- High-Speed SerDes --> D(Lossy Data Center Network)
    D --> E[Remote Exchange Gateway NI]
    E -- Process MTM --> F(Exchange Order Book)

    subgraph HFT-Optimized NI
        C1(MTM Prioritizer & Timestamp)
        C2(Ultra-Low Latency Priority Queues)
        C3(Aggressive Retransmission Engine)
        C --> C1
        C1 --> C2
        C2 --> C3
        C3 --> D
    end

    subgraph Remote Exchange Gateway NI
        E1(Packet Receiver & Timestamp Check)
        E2(Sequence Validator & MTM Decapsulator)
        E3(ACK Generator)
        E --> E1
        E1 --> E2
        E2 --> E3
        E3 --> D
    end

    C3 -- Retransmit/Redundant --> D
    E3 -- ACK (Timestamped) --> D

Derivative 2.2: Deep-Space Communication with Extreme Latency/Loss Adaption

• Axis: Operational Parameter Expansion
• Enabling Description: This derivative applies the core mechanism of US7702742 to deep-space communication links, characterized by extreme, variable latency (minutes to hours) and very high, unpredictable packet loss rates due to signal degradation, cosmic interference, and limited bandwidth. The network interface (Deep-Space Comm Unit - DSCU) integrates a long-duration retransmission buffer (using radiation-hardened flash memory or MRAM for persistence across power cycles) capable of holding packets for days or weeks. The "timeout" period for retransmission is dynamically adjusted based on estimated round-trip time (RTT) which is itself variable and influenced by orbital mechanics. Instead of immediate retransmission, the DSCU might employ Forward Error Correction (FEC) aggressively for high-priority MTMs (e.g., critical command & control instructions), and only retransmit when FEC fails or after a calculated optimal waiting period. Prioritization might include "mission-critical," "science-data-request," and "telemetry-update." ACKs might be bundled or delayed to conserve bandwidth. The sequencing ensures that command execution on a remote probe is strictly ordered even with immense communication delays.

graph TD
    A[Ground Station Commander] --> B(Mission Control CPU/Memory)
    B -- MTMs (Commands, Queries) --> C[Ground DSCU NI]
    C -- Encapsulate, Prioritize, FEC, Seq # --> D(Deep Space Comm Link)
    D -- Extreme Latency & Loss --> E[Remote Probe DSCU NI]
    E -- Decapsulate, Validate, Process MTM --> F(Probe Subsystem Controller)

    subgraph Ground DSCU NI
        C1(MTM Prioritizer)
        C2(Adaptive FEC Encoder)
        C3(Long-Duration Retransmission Buffer)
        C4(Adaptive Timeout & Transmission Scheduler)
        C --> C1 --> C2 --> C3 --> C4 --> D
    end

    subgraph Remote Probe DSCU NI
        E1(FEC Decoder)
        E2(Sequence Validator)
        E3(MTM Processor)
        E4(Bundled ACK Generator)
        D --> E1 --> E2 --> E3 --> F
        E3 --> E4 --> D
    end

    C4 -- Re-transmit if no ACK/FEC fails --> D

Derivative 2.3: Nanoscale Inter-Chip Memory Access over Noisy On-Chip Networks

• Axis: Operational Parameter Expansion
• Enabling Description: This derivative scales down the invention to nanoscale, enabling reliable remote memory access between functional blocks (e.g., processor cores, accelerators) within a single System-on-Chip (SoC) using a noisy, lossy Network-on-Chip (NoC). MTMs are micro-packets exchanged between memory controllers integrated into each functional block. The NoC, due to voltage scaling, process variations, or transient faults, can exhibit packet loss or reordering. The "network interface" is a highly integrated NoC adapter (NOC-A) within each block. It categorizes MTMs (e.g., cache-line reads/writes, control registers) and assigns priorities. The packet composition and sequencing logic are optimized for ultra-low power and area, using minimal hardware. Retransmission buffers are small, high-speed registers. Timeout mechanisms are based on clock cycles, and retransmission for specific priority streams ensures coherence and correct program execution despite NoC unreliability. This enables a logically distributed memory model across the SoC, even with unreliable interconnects.

graph TD
    A[Core 1] -- MTM --> N1[NOC-A 1]
    B[Core 2] -- MTM --> N2[NOC-A 2]
    N1 -- Micro-Packets (Prio, Seq #) --> NOC[Noisy NoC]
    N2 -- Micro-Packets (Prio, Seq #) --> NOC
    NOC --> N1
    NOC --> N2

    subgraph NOC-A 1
        N1_1(MTM Classifier & Prioritizer)
        N1_2(Micro-Packet Composer)
        N1_3(Priority Queues - Registers)
        N1_4(Retransmission Logic - Hardware FSM)
        N1_5(ACK Processor)
        N1 --> N1_1 --> N1_2 --> N1_3 --> NOC
        NOC --> N1_5 --> N1_4
        N1_4 -- Resend --> N1_3
    end

    subgraph Noisy NoC
        NOC_R(Loss/Reordering)
        NOC -- N_R --> NOC
    end

3. Cross-Domain Application

Derivative 3.1: Distributed Avionics Memory Access (Aerospace)

• Axis: Cross-Domain Application
• Enabling Description: This derivative applies US7702742 to distributed avionics systems in aircraft or spacecraft. Multiple avionics control units (ACUs), sensors, and actuators form a network, where critical flight control data, sensor readings (e.g., altitude, speed, engine parameters), and command messages are exchanged. The internal network (e.g., ARINC 664, or a high-speed Ethernet variant) can be "lossy" due to electromagnetic interference (EMI), single-event upsets (SEUs) in radiation environments, or temporary link failures. The network interface in each ACU is a radiation-hardened module. It assigns "flight-critical" (e.g., flight surface commands, engine thrust changes) as the highest MTM priority, "navigation-data" as medium, and "cabin-systems-status" as lowest. Retransmission ensures that even if packets are lost due to transient faults, critical commands are eventually executed in the correct sequence, preventing cascading failures. A "safe-mode" MTM is always assigned the highest priority to ensure emergency commands reach their destination.

graph TD
    A[Flight Control Computer] -- Flight Control MTMs --> B(Avionics NI)
    B --> C(Lossy Avionics Network)
    C --> D(Engine Control Unit NI)
    C --> E(Actuator Control Module NI)
    D --> F[Engine Controller]
    E --> G[Actuator System]

    subgraph Avionics NI
        B1(MTM Classifier & Prio Assign)
        B2(Prioritized Tx Queues)
        B3(Hardened Retransmission Engine)
        B1 --> B2 --> B3 --> C
        C --> B3
    end

    subgraph Engine Control Unit NI
        D1(Recv, Seq Validate)
        D2(Process Critical MTM)
        D1 --> D2 --> F
        D2 -- ACK --> C
    end

Derivative 3.2: Remote Surgery and Diagnostics (Medical)

• Axis: Cross-Domain Application
• Enabling Description: This derivative adapts the patent's mechanism for real-time remote surgery or high-resolution diagnostic imaging over wide-area networks (WANs) or hospital intranets, which can be lossy and suffer from congestion. A local surgical robot console or diagnostic imaging machine sends MTMs (e.g., precise robotic arm movements, high-bandwidth image stream requests, patient vital sign monitoring commands) to a remote robot or imaging device. "Surgical Control" MTMs (e.g., precise cuts, movements) are assigned the highest priority to ensure deterministic execution, with strict sequence preservation. "Diagnostic Imaging" requests (e.g., high-resolution MRI slice data) receive a high but lower priority, and "Patient Telemetry" (e.g., heart rate, blood pressure updates) a medium priority. The network interface incorporates specific medical device communication protocols (e.g., DICOM, HL7 in some contexts) and ensures that retransmission guarantees delivery for all priority types, preventing errors during delicate procedures or data corruption in diagnostics. Jitter and latency control are paramount, with retransmission timeouts dynamically adjusted based on the specific medical procedure's real-time constraints.

sequenceDiagram
    participant SC as Surgeon Console (Local)
    participant S_NI as Surgical NI (Local)
    participant WN as WAN (Lossy)
    participant R_NI as Robot NI (Remote)
    participant SR as Surgical Robot (Remote)

    SC->S_NI: MTM (Surgical Command, Image Req, Telemetry)
    S_NI->S_NI: Classify MTM, Assign Prio (Surgical > Image > Telemetry)
    S_NI->S_NI: Compose Packet (Seq #)
    S_NI->WN: Send Packet (Prio-based)

    alt Packet Lost
        WN--xS_NI: No ACK (Timeout)
        S_NI->WN: Resend timed-out & subsequent packets (of same Prio)
    end

    WN->R_NI: Packet
    R_NI->R_NI: Validate Seq #, Decapsulate MTM
    R_NI->SR: Execute Surgical Command / Retrieve Image Data
    SR->R_NI: Response / Image Data
    R_NI->WN: Send ACK / Data Packet (Prio-based)
    WN->S_NI: ACK / Data Packet
    S_NI->S_NI: Process ACK / Data, Remove from Retransmit Buffer
    S_NI->SC: Update Console / Display Image

Derivative 3.3: Smart Grid Distributed Energy Resource Management (Energy)

• Axis: Cross-Domain Application
• Enabling Description: This derivative applies the reliable remote I/O mechanism to smart grid infrastructure, specifically for managing distributed energy resources (DERs) like solar inverters, battery storage systems, and smart meters. Control center commands (e.g., "reduce solar output," "charge battery," "disconnect load") are MTMs transmitted over a diverse and often lossy mix of communication mediums (e.g., cellular, unlicensed wireless, power line communication). The network interface in a Grid Control Unit (GCU) or DER controller prioritizes MTMs: "Emergency Load Shedding" as highest, "Grid Stabilization Command" as medium, and "Metering Data Upload" as lowest. The system ensures that critical grid commands are reliably delivered and executed in the correct sequence, preventing grid instability or blackouts due to dropped or reordered control messages. The retransmission mechanism is robust against intermittent connectivity, and the acknowledgment process provides feedback on command execution status.

graph TD
    A[Grid Control Center] -- Control MTMs --> B(GCU NI)
    B --> C(Lossy Smart Grid Network)
    C --> D(Solar Inverter NI)
    C --> E(Battery Storage NI)
    C --> F(Smart Meter NI)

    subgraph GCU NI
        B1(Command Parser & Prio Assign)
        B2(Prioritized Tx Queues)
        B3(Reliable Comm Engine)
        B1 --> B2 --> B3 --> C
        C --> B3
    end

    subgraph Solar Inverter NI
        D1(Recv, Seq Validate)
        D2(Execute Prio Command)
        D1 --> D2
        D2 -- ACK --> C
    end

4. Integration with Emerging Tech

Derivative 4.1: AI-Driven Adaptive Priority and Retransmission Optimization

• Axis: Integration with Emerging Tech
• Enabling Description: This derivative integrates an AI module, specifically a reinforcement learning (RL) agent, into the network interface. The RL agent observes real-time network conditions (e.g., latency, jitter, packet loss rate), application-level MTM completion rates, and historical performance data. Based on these observations, it dynamically adjusts: (1) the precise "sending priority" assigned to network packets (e.g., finer-grained priorities than just 1, 2, 3), potentially overriding static processor bus protocol mappings based on current network state; (2) the retransmission timeout values for each priority stream; and (3) the retransmission strategy (e.g., whether to use Go-Back-N, Selective Repeat, or even forward error correction for certain conditions). The goal is to maximize overall system throughput or minimize latency for critical MTMs under fluctuating lossy network conditions, learning optimal strategies over time. The AI module operates on a dedicated low-power processing unit (e.g., a neural processing unit - NPU) within the network interface.

graph TD
    A[Local Processor/Memory Controller] --> B(Network Interface with AI)
    B -- MTMs --> C{MTM Classification & Initial Prio}
    C --> D{AI-Driven Adaptive Priority Logic}
    D --> E{Prioritized Packet Queues}
    E --> F[Packet Sender]
    F --> G(Lossy Network)
    G --> H[Remote Node NI]
    H -- ACKs/Network Metrics --> D
    H -- ACKs --> I{Retransmission Buffer & Logic}
    I -- Resend if Timeout --> F
    D -- Adjust Timeout/Strategy --> I

    subgraph Network Interface with AI
        subgraph AI Module
            D1(RL Agent)
            D2(Network State Monitor)
            D3(Performance Evaluator)
            G -- Network Metrics --> D2
            D2 --> D1
            D1 --> D
            I -- Retransmission Events --> D1
            H -- ACKs/Network Metrics --> D2
        end
    end

Derivative 4.2: IoT Edge Gateway with Real-time Remote Memory for Sensor Fusion

• Axis: Integration with Emerging Tech
• Enabling Description: This derivative envisions an IoT edge gateway acting as a local node, collecting data from various local sensors (e.g., temperature, vibration, video) via local buses. These sensor data streams, often aggregated into MTMs, need to be accessed by remote cloud-based analytics engines or other edge nodes for real-time sensor fusion and anomaly detection. The network interface in the edge gateway is optimized for lossy, intermittent wireless connectivity (e.g., LoRaWAN, 5G NR-U). MTMs are prioritized: "critical alarm" (highest), "high-fidelity sensor reading" (medium), "routine telemetry" (lowest). The system leverages the reliable delivery mechanism of US7702742, but also incorporates real-time IoT sensor data compression and edge-based pre-processing to reduce payload size, improving efficiency over bandwidth-constrained lossy networks. The remote cloud memory acts as a shared global view of the physical environment, with the network interface ensuring that critical updates are consistently propagated despite network challenges.

graph TD
    A[Local IoT Sensors] --> B(IoT Edge Gateway)
    B -- MTM (Sensor Data/Commands) --> C[Edge Gateway NI]
    C --> WN[Lossy Wireless Network]
    WN --> D[Cloud Remote Memory Interface]
    D --> E[Cloud Analytics Engine]

    subgraph IoT Edge Gateway
        C1(Sensor Data Aggregator)
        C2(MTM Prioritizer & Composer)
        C3(Reliable Comm Engine)
        C1 --> C2 --> C3 --> WN
        WN --> C3
    end

    subgraph Cloud Remote Memory Interface
        D1(Packet Receiver & Validator)
        D2(Remote Memory MTM Processor)
        D1 --> D2 --> E
        D2 -- ACK --> WN
    end

Derivative 4.3: Blockchain-Verified Memory Transaction Logging

• Axis: Integration with Emerging Tech
• Enabling Description: This derivative enhances the reliable remote memory access mechanism with blockchain technology for immutable logging and verification of MTMs and their execution. Each network packet containing an MTM, upon successful delivery and processing at the remote node, triggers the creation of a transaction on a private blockchain. This blockchain transaction includes: a cryptographic hash of the MTM content, the assigned priority, sender/receiver IDs, sequence number, and a timestamp. The acknowledgement packet from the remote node also includes a hash of the blockchain transaction ID, confirming successful logging. If an MTM times out and is retransmitted, subsequent successful transmission will result in a new blockchain entry, explicitly linking to the retransmitted instance. This provides an auditable, tamper-proof record of all remote memory transactions, their order, and their completion status, which is critical for compliance in sectors like finance or defense. The network interface integrates a lightweight blockchain client for cryptographic hashing and transaction submission.

sequenceDiagram
    participant LMC as Local Memory Controller
    participant LNI as Local Network Interface
    participant LN as Lossy Network
    participant RNI as Remote Network Interface
    participant RMC as Remote Memory Controller
    participant PB as Private Blockchain

    LMC->LNI: MTM
    LNI->LNI: Prio, Seq #, Hash MTM
    LNI->LN: Send Packet (MTM + Hash)
    LN->RNI: Packet
    RNI->RNI: Validate Seq #, Verify MTM Hash
    RNI->RMC: Process MTM
    RMC->RNI: Result/Completion
    RNI->PB: Log Transaction (MTM Hash, Seq #, Status)
    PB->RNI: Transaction ID (TXID)
    RNI->LN: Send ACK (Seq # + TXID Hash)
    LN->LNI: ACK
    LNI->LNI: Process ACK, Remove from Buffer
    LNI->PB: Optionally verify TXID Hash on blockchain

5. The "Inverse" or Failure Mode

Derivative 5.1: Graceful Degradation and Local Cache Fallback Mode

• Axis: The "Inverse" or Failure Mode
• Enabling Description: This derivative defines a network interface designed to intelligently degrade performance and fall back to local resources when the lossy network becomes excessively unreliable or completely fails. The network interface continuously monitors packet loss rates, retransmission counts, and latency for each priority stream. If a predefined threshold of unreliability is crossed (e.g., loss rate > 20% for high-priority MTMs, or sustained high retransmission rates), the network interface triggers a "degraded mode." In this mode: (1) remote memory access requests for non-critical MTMs are buffered indefinitely or discarded, preventing resource exhaustion; (2) critical MTMs attempt to access a pre-designated local cache (e.g., local NVRAM) containing a stale but potentially usable copy of the remote data; (3) the local processor is notified to switch to local-only operations or use cached data. Upon network recovery, the network interface attempts to synchronize the local cache with the remote memory via high-priority updates.

stateDiagram
    [*] --> NormalOperation
    NormalOperation --> MonitorNetwork : Monitor Loss, Latency, Retransmissions
    MonitorNetwork --> NormalOperation : Network within thresholds
    MonitorNetwork --> DegradedMode : Network exceeds thresholds

    state NormalOperation {
        ProcessMTM(Prio) : Send/Recv with Retransmission
        NetworkInterface : Active Remote I/O
    }

    state DegradedMode {
        BufferOrDiscardNonCritical()
        FallbackToLocalCacheForCritical()
        NotifyLocalProcessor()
        DegradedNetworkInterface : Limited Remote I/O
    }

    DegradedMode --> Recovering : Network recovers
    Recovering --> NormalOperation : Cache Sync Complete

Derivative 5.2: Low-Power Standby and Wake-on-MTM Mode

• Axis: The "Inverse" or Failure Mode
• Enabling Description: This derivative describes a network interface optimized for extreme power efficiency, featuring a "low-power standby" mode. In this mode, the main processing components (e.g., FPGA, large memory buffers) of the network interface are largely powered down. A minimal hardware "wake-on-MTM" detection circuit remains active, monitoring the network link for incoming packets. This circuit is capable of parsing only the header of incoming packets to detect if they contain an MTM destined for the local node and if that MTM is of a "wake-up" priority type. Upon detection of a qualifying MTM, the wake-on-MTM circuit triggers the rapid power-up of the full network interface. Similarly, on the sending side, if no MTMs are queued for transmission for a configured period, the network interface transitions to this low-power state. This is particularly relevant for battery-powered distributed systems or deep-sleep IoT nodes that occasionally need to perform remote memory transactions.

stateDiagram
    [*] --> Active
    Active --> LowPowerStandby : No MTMs for timeout OR Explicit Command
    LowPowerStandby --> Active : Wake-on-MTM event detected OR Explicit Command

    state Active {
        MTMProcessing : Full functionality
        PacketTransmission : Prioritized & Reliable
    }

    state LowPowerStandby {
        WakeOnMTM_Circuit : Active
        MainLogic : Powered Down
        DetectsIncomingPacket() --> WakeOnMTM_Circuit
        WakeOnMTM_Circuit --> ParseHeader()
        ParseHeader() --> CheckDestination()
        CheckDestination() --> CheckPriority()
        CheckPriority() --> TriggerPowerUp : If Wake-up Prio & Dest Match
    }

Derivative 5.3: Diagnostic and Event Logging Mode for Post-Mortem Analysis

• Axis: The "Inverse" or Failure Mode
• Enabling Description: This derivative enhances the network interface with an advanced diagnostic and event logging mode, crucial for debugging complex distributed systems operating over lossy networks. In this mode, the network interface internally logs every significant event related to MTM processing and packet transmission/reception. This includes: MTM arrival, determined transaction type, assigned sending priority, packet composition, sequence number assignment, timestamp of transmission, ACK receipt (or lack thereof), retransmission events (which packet, how many times), perceived packet loss, and detected out-of-sequence packets at the receiver. This verbose logging (stored in a dedicated, often non-volatile, diagnostic memory buffer) can be triggered automatically upon detection of system anomalies (e.g., repeated MTM timeouts, deadlock detection, system crash) or manually. The log data can then be extracted for post-mortem analysis, enabling engineers to reconstruct the exact sequence of remote memory transactions and identify the root cause of failures within the lossy network. The logging itself is designed to be low-overhead but comprehensive.

sequenceDiagram
    participant LMC as Local Memory Controller
    participant LNI as Local Network Interface (Diagnostic Mode)
    participant LEL as Local Event Logger (NVM)
    participant LN as Lossy Network
    participant RNI as Remote Network Interface (Diagnostic Mode)
    participant REL as Remote Event Logger (NVM)
    participant RMC as Remote Memory Controller

    LMC->LNI: MTM
    LNI->LEL: Log(MTM_Arrived, Type, Prio)
    LNI->LN: Send Packet (Seq #)
    LNI->LEL: Log(Packet_Sent, Seq #, Timestamp)
    LN->RNI: Packet (or lost)
    alt Packet Lost
        LNI->LEL: Log(Packet_Timeout, Seq #)
        LNI->LN: Resend Packet (Seq #)
        LNI->LEL: Log(Packet_Retransmitted, Seq #)
    else Packet Received by RNI
        RNI->REL: Log(Packet_Received, Seq #, Timestamp)
        RNI->RNI: Validate Seq #
        alt Out of Sequence
            RNI->REL: Log(Out_of_Seq_Packet_Dropped, Expected #, Received #)
        end
        RNI->RMC: Process MTM
        RNI->REL: Log(MTM_Processed, Seq #)
        RNI->LN: Send ACK (Seq #)
        RNI->REL: Log(ACK_Sent, Seq #)
        LN->LNI: ACK
        LNI->LEL: Log(ACK_Received, Seq #)
        LNI->LEL: Log(Packet_Acknowledged, Seq #)
    end

---

Combination Prior Art Scenarios

Here are three scenarios combining the core concepts of US Patent 7,702,742 with existing open-source standards, demonstrating how such combinations would be obvious to a PHOSITA.

1. Integration with InfiniBand (IB) for Lossy-to-Reliable Protocol Bridging

• Scenario: A PHOSITA would find it obvious to apply the MTM prioritization, sequencing, and reliable retransmission mechanism of US7702742 as a bridging layer between a legacy lossy Ethernet network and a high-performance, typically reliable, InfiniBand (IB) network.
• Enabling Description: In this scenario, a specialized gateway device or network interface unit acts as a protocol bridge. On the "lossy" (e.g., Ethernet) side, it implements the full sending and receiving logic of US7702742: encapsulating MTMs into Ethernet packets, assigning priorities based on processor bus protocol, transmitting them, and managing retransmissions to ensure reliable, in-order delivery of MTM streams. Once a reliable stream of MTMs is established from the lossy network, these MTMs are then translated and transmitted over the InfiniBand network using its native Reliable Connected (RC) or Unreliable Datagram (UD) Queue Pair (QP) services. While IB's RC service offers inherent reliability, using the US7702742 mechanisms on the lossy ingress network ensures that the required MTM ordering and delivery guarantees are met before conversion to IB fabric messages. This effectively allows an unreliable front-end network to interface with a high-performance, low-latency, typically reliable backend, extending the reach of remote programmed I/O from commodity Ethernet to specialized fabrics. The gateway leverages IB's RDMA capabilities to directly place or retrieve MTM data from remote memory spaces once the MTM stream is reliably reassembled and ordered.
• Open-Source Standard: InfiniBand (IB) Architecture Specification (e.g., InfiniBand™ Architecture Specification Release 1.3).
• Obviousness Argument: Given the motivation to connect commodity lossy networks to high-performance fabrics, it would be obvious to a PHOSITA to use US7702742's proven reliability layer on the lossy segment and then pass the now-reliable MTM streams to a standard high-performance interconnect like InfiniBand for final delivery. This combines two known solutions for different parts of the problem: reliable transport over lossy links, and high-performance transport over reliable links.

2. Enhancing RDMA over Converged Ethernet (RoCE) with Fine-Grained MTM Prioritization

• Scenario: A PHOSITA would find it obvious to integrate the MTM transaction type-based prioritization of US7702742 into existing RDMA over Converged Ethernet (RoCE) implementations to provide more granular control and guaranteed ordering for specific memory transactions over lossy Ethernet.
• Enabling Description: RoCE (version v1 or v2) typically uses InfiniBand transport protocols over Ethernet. While RoCEv2 can leverage DiffServ (DSCP) for QoS, this often applies to entire traffic classes rather than specific memory transaction types from a processor bus perspective. A network interface implementing US7702742's logic would specifically inspect incoming MTMs from the local memory controller (e.g., a read request, a posted write), assign an internal RoCE priority queue ID (QP) or set specific DSCP markings based on the MTM's transaction type and the processor bus protocol rules. For example, posted writes (high bus priority) would be mapped to a RoCE QP with a higher priority or a specific DSCP value indicating higher urgency. Non-posted reads (low bus priority) would be mapped to a lower priority QP or a different DSCP value. The retransmission and sequencing mechanism of US7702742 would operate within each RoCE QP's data stream (or across DSCP flows) to ensure that despite Ethernet's lossy nature, MTMs of the same transaction type are delivered in strict order, and that higher-priority MTMs generally bypass lower-priority ones. This provides a more direct mapping of processor expectations onto the network layer than standard RoCE QoS, enabling deterministic behavior for critical remote memory operations.
• Open-Source Standard: RDMA over Converged Ethernet (RoCE) Specification (e.g., from InfiniBand Trade Association, IBTA).
• Obviousness Argument: Recognizing that standard RoCE QoS might not perfectly align with fine-grained processor bus protocol ordering needs, it would be obvious to a PHOSITA to apply the MTM-specific prioritization and reliability features of US7702742 to RoCE packet encapsulation. This would ensure that processor-level ordering expectations are directly enforced across a converged Ethernet network, bridging the semantic gap between a CPU's bus and the network fabric.

3. Secure and Reliable IPC using POSIX Shared Memory over Lossy Network with US7702742

• Scenario: A PHOSITA would find it obvious to extend POSIX Shared Memory for inter-process communication (IPC) across a lossy network by tunneling memory-mapped operations using the reliable MTM mechanism of US7702742.
• Enabling Description: In a distributed system, processes often need to share data structures residing in memory. Traditionally, POSIX shared memory (shm_open, mmap) provides a fast IPC mechanism within a single host. This derivative involves a "remote shared memory" driver that intercepts memory accesses to specially designated shared memory regions. When a local process attempts to read from or write to such a remote-mapped shared memory page, the driver converts this into an MTM (e.g., a "remote shared memory write" or "remote shared memory read"). This MTM is then passed to a network interface implementing US7702742. The network interface assigns priorities (e.g., "critical shared flag update" highest, "bulk data copy" medium) and ensures its reliable, ordered delivery over the lossy network to a remote node. The remote node's network interface reconstructs the shared memory access and applies it to its local shared memory segment. This enables distributed applications to transparently use a POSIX shared memory abstraction, even when the underlying communication is over an unreliable network, with the guarantees provided by US7702742's reliability layer. Secure mechanisms (e.g., IPC-specific tokens, access control lists) would be included in the MTMs to manage access rights.
• Open-Source Standard: POSIX Shared Memory API (IEEE Std 1003.1-2008, also known as Single UNIX Specification, Version 4).
• Obviousness Argument: Given the widespread use of POSIX shared memory for IPC and the desire to extend IPC transparency across network boundaries, it would be obvious to a PHOSITA to leverage US7702742's ability to reliably transport memory transactions over lossy networks. This combines a standard IPC abstraction with a robust network transport layer to provide distributed shared memory semantics, effectively making remote IPC as reliable as local IPC despite network unreliability.