US 7042898

I'll search for authoritative information on US Patent 7,042,898, including any 2026 CAFC activity.

Let me search specifically for 2026 litigation/docket activity and current ownership.

Let me do one more targeted check for any 2026 appellate or district-court activity and the current owner of record.

US Patent 7,042,898 — Analyst Summary

Important scope note: I could not access the USPTO Patent Center / PACER / CAFC CM-ECF dockets directly; the findings below come from public web sources (Google Patents, Justia, FreePatentsOnline, RPX, Unified Patents, Docket Alarm) plus the full patent text supplied. I found no 2026 CAFC docket entry, appeal, or litigation naming U.S. 7,042,898 specifically. My searches surfaced no CAFC 2026 activity for this patent. Treat that as "no evidence found," not as affirmative proof of absence.

---

Bibliographic data (confirmed across Google Patents and the official PDF)

Note on assignees: Google Patents' reassignment history shows Alacritech → A-TECH LLC (Nov. 15, 2013) → back to Alacritech, Inc. (June 22, 2016). I have not independently verified the current chain of title beyond that record.

(Minor source artifacts: some Google/OCR records render the first inventor as "Bilghtman" and Boucher as "Laurnce B. Boucher." These are transcription errors; the official patent front page reads Blightman and Boucher.)*

---

Abstract (verbatim)

"A first partial checksum for the header portion of a TCP header is generated on an intelligent network interface card (INIC) before all the data of the data payload of the TCP message has been transferred to the INIC. A pseudopacket with the first partial checksum and the data is assembled in DRAM on the INIC as the data arrives onto the INIC. When the last portion of the data of the data payload is received onto the INIC, a second partial checksum for the data payload is generated. The pseudopacket is read out of DRAM for transfer to a network. While the pseudopacket is being transferred, the second partial header is combined with the first partial header and the resulting final checksum is inserted into the pseudopacket so that a complete TCP packet with a correct checksum is output from the INIC to the network."

---

Independent claims in plain language

Claim 1 — Method

A five-step method:

• (a) Transfer the message's data payload from host memory into a first memory of the network interface device (the spec calls this DRAM).
• (b) Before step (a) finishes, create — on the network interface device itself — a "pseudoheader" and store it in a second memory of the device (the spec calls this SRAM). The pseudoheader contains a header portion plus a checksum portion, and critically that checksum covers only the header portion, not the data payload (a partial checksum).
• (c) Also before step (a) finishes, move that pseudoheader from the second memory into the first memory (so header and payload end up co-located).
• (d) After (c), compute a checksum for the data payload on the network interface device. The pseudoheader + payload together are termed a "pseudopacket."
• (e) Read the pseudoheader and at least part of the payload out of the first memory, and combine the header checksum with the payload checksum to produce the final checksum, insert that final checksum into the pseudopacket to form a complete TCP packet, and output the complete packet from the device onto the network.

The inventive point is the timing/where of the checksum work: the header-side checksum is computed early and stored with the data, and only the final combine-and-insert happens on the fly during the DRAM-to-network read, avoiding a slow late write of the completed header into DRAM.

Claim 5 — Apparatus (means-plus-function)

The same five operations as claim 1, but recited as functional "means" elements: means for transferring the payload to first memory; means for creating the pseudoheader in a second memory before the transfer completes (header-only partial checksum); means for transferring the pseudoheader to the first memory; means for generating the payload checksum after that; and means for reading the pseudopacket and combining the two partial checksums into the final checksum inserted into the outgoing TCP packet.

Dependent claims (all narrow the independent claims structurally):

• Claim 2 – first memory is DRAM; second memory is SRAM.
• Claim 3 – the second memory has a faster access time than the first memory.
• Claim 4 – the network interface device is part of a host computer, and the host memory is another part of that same host computer.
• Claim 6 – the apparatus comprises a host computer, with the network interface device and host memory being parts of it.
• Claim 7 – the reading means includes a sequencer; the creating means includes a processor.

---

Litigation / IPR posture (as found)

• I found no IPR or PGR petition against US 7,042,898 in the public records reviewed.
• 7,042,898 was not among the patents asserted in Alacritech's 2016 Eastern District of Texas campaign (the asserted set was 7,124,205; 7,237,036; 7,337,241; 7,673,072; 7,945,699; 8,131,880; 8,805,948; 9,055,104 — e.g., Alacritech v. CenturyLink/Dell/Wistron, No. 2:16-cv-693 et al.). That campaign ended with a stipulated dismissal with prejudice of the CenturyLink defendants in November 2023.
• The prominent CAFC Alacritech appeal decisions I located — Alacritech, Inc. v. Intel Corp., 966 F.3d 1367 (Fed. Cir. 2020) — concern the '880 patent, not the '898 patent. Several 2021–2022 notices of appeal from IPR2017-01410 likewise concern '880.
• The patent does appear in a Broadcom/Emulex driver document listing it among patents that "apply" to certain adapter products, which is consistent with Alacritech's licensing activity — but that is a documentation reference, not litigation.
• No 2026 CAFC docket item for 7,042,898 was found.

---

Caveats / uncertainty

1. 2026 docket negative is not definitive. I could not query PACER, the CAFC CM-ECF docket, or USPTO Patent Center directly; my conclusion rests on public search results, which returned nothing for this patent in 2026. Late-2026 filings may exist that are not yet indexed.
2. Expiration is taken from the Google Patents record ("Expired – Lifetime, expires 2021-04-26"), which is consistent with the face-of-patent PTA of 1,095 days. I did not independently recompute the term or verify post-issuance maintenance-fee payments.
3. Current title holder is per reassignment records (Alacritech → A-Tech LLC → Alacritech, Inc.). I did not verify with a current USPTO assignment abstract of title.
4. The text above reflects the authoritative full-text you supplied; where search results conflicted in formatting/OCR, I deferred to the patent document.

I'll research litigation involving US patent 7042898. Let me search multiple sources.

Let me search more specifically for cases asserting this exact patent.

Let me dig into which specific cases asserted the '898 patent.

Based on my searches, here is what I found regarding U.S. Patent No. 7,042,898. I want to be upfront: I hit my research-step limit before I could exhaustively query every litigation database (Unified Patents, PACER, Docket Navigator, RPX), and the searches I ran did not surface any lawsuit in which U.S. Patent No. 7,042,898 was specifically named as an asserted patent-in-suit. Below I explain what I did and did not find, and give the relevant context.

Bottom line

No confirmed litigation asserting U.S. Patent No. 7,042,898 ("Reducing delays associated with inserting a checksum into a network message") was located. The patent appears repeatedly in Alacritech's portfolio and in related litigation paperwork (e.g., as a family member of patents that were asserted, and in licensing/notice lists), but I found no complaint, case number, or docket in which the '898 patent itself was asserted against a defendant.

What I found (and why it is not a hit for the '898 patent)

The '898 patent is a parent/sibling in Alacritech's large patent family. It issued May 9, 2006 from Application No. 09/802,426 (filed Mar. 9, 2001), claiming priority to Oct. 14, 1997. Alacritech's major enforcement campaigns asserted other members of that family:

1. Alacritech, Inc. v. CenturyLink, Inc., et al.

   • Court: U.S. District Court, Eastern District of Texas (Marshall Division)
   • Case No.: 2:16-cv-00693 (lead case; consolidated with 2:16-cv-00692)
   • Filed: June 30, 2016
   • Asserted patents: 7,124,205; 7,237,036; 7,337,241; 7,673,072; 7,945,699; 8,131,880; 8,805,948; 9,055,104 — the '898 patent is NOT among them.
   • Status: RPX lists the case as closed 11/30/2023; the docket (via CourtListener) shows extensive activity through late 2023, including pretrial motions, a deconsolidation order (Oct. 13, 2023), and Intel/Dell and Cavium intervenor participation.

2. Alacritech, Inc. v. Wistron Corp., Wiwynn Corp., SMS Infocomm Corp.

   • Court: E.D. Tex.
   • Case No.: 2:16-cv-00692
   • Filed: June 30, 2016
   • Consolidated into the CenturyLink lead case. Asserted the same family patents (all except '699) — again, not the '898 patent.

3. Alacritech, Inc. v. [Microsoft Corp.](/litigations/by-plaintiff/Microsoft%20Corp.)

   • Court: N.D. Cal., Case No. 04-cv-03284
   • Referenced in IPR exhibits (e.g., a Nov. 2004 expert declaration). However, this 2004 filing predates the '898 patent's May 9, 2006 issuance, so the '898 patent could not have been asserted there.

4. Related PTAB proceedings (Intel, Cavium, Dell petitions, e.g., IPR2017-01405/01406/01409/01410 and IPR2018-00226/00234) challenged family members such as the '205, '036, '880, and '948 patents — not the '898 patent. Alacritech's mandatory notices in these IPRs list the '898 patent only as a family member ("U.S. Patent Application No. 09/802,426 … issued … as 7,042,898 patent"), which is a portfolio description, not an assertion.

Why the '898 number appears in some documents

• Alacritech IPR mandatory notices (e.g., IPR2018-00234): '898 listed as a sibling in the '036 patent family.
• Broadcom/Emulex OEM documentation (e.g., Emulex driver manuals): the number 7042898 appears in a list of third-party patents in a proprietary/legal notices section — a licensing/notice list, not litigation.

Neither of these is a lawsuit.

Caveats and confidence

• Confidence that no litigation exists asserting '898: moderate, not high. I could not complete queries against Unified Patents' litigation portal, PACER, or Docket Navigator before reaching my step limit. It is possible a case exists that I did not surface (for example, a later Alacritech campaign, a declaratory-judgment action by a manufacturer, or a case where '898 was added by amended contentions).
• The Google Patents page for US7042898B2 does not list any litigation in the "Litigation" section, and no accused-products/litigation data appeared for it — consistent with a finding of no asserted use.
• I found no CAFC appeal specifically concerning the '898 patent.

Recommendation

To definitively confirm, I would check (which I could not complete):

• Unified Patents litigation portal: https://portal.unifiedpatents.com/litigation/caselist (search patent number 7042898)
• RPX Insight: https://insight.rpxcorp.com (search 7,042,898)
• FreeLawProject/CourtListener and Justia Dockets for any Alacritech complaint referencing the '898 patent, including amended infringement contentions in the 2016 E.D. Tex. campaign.

If you'd like, I can run those targeted queries now that the scope is narrowed to "Alacritech + 7,042,898 only."

I'll start by verifying the structured "no PTAB activity" baseline against public sources, since 7042898 sits in the heavily-litigated Alacritech family.

Let me dig specifically for any IPR or district court case naming the '898 patent.

Let me check the Alacritech litigation campaigns and any PTAB references to the '898 specifically.

PTAB Proceedings Report — U.S. Patent No. 7,042,898

"Reducing delays associated with inserting a checksum into a network message"
Assignee of record: Alacritech, Inc. · Application 09/802,426, filed 2001-03-09 · Issued 2006-05-09 · Earliest priority claimed 1997-10-14 · Adjusted expiration 2021-04-26 (Google Patents: https://patents.google.com/patent/[US7042898](/patent/US7042898)/en)

---

Proceedings overview

There are zero AIA trial proceedings on file for U.S. Patent No. 7,042,898: the USPTO Open Data Portal returns no IPR, PGR, or CBM naming this patent, and my independent searching surfaced no petition, institution decision, Final Written Decision, or appeal captioned against the '898 patent. The breakdown is therefore 0 active / 0 claims invalidated / 0 claims sustained / 0 settled / 0 institution denied. The defensive posture this gives a defendant is not "hardened by surviving IPRs" and not "claims 1–5 are dead" — it is that the patent has never been tested at the Board, has no PTAB-estoppel roadmap attached to it, and its term has already lapsed (2021-04-26), so any assertion of it today is a stale-portfolio play rather than a live enforcement threat. The absence of PTAB activity here is not the usual "well-asserted patents eventually attract IPRs" signal, because the '898 was never among the patents Alacritech put in suit even during its most aggressive campaigns.

Caution on identifier collisions. Searches for "the '898 patent" return two unrelated patents that are frequently confused with this one: Oyster Optics, LLC's optical-transmission patent (subject of IPR2017-01870/-01881, IPR2018-00070, IPR2018-00257) and a PS Industries gate patent (7,042,898 is not that patent either — the gate case cites a different '898). Neither is U.S. 7,042,898. I flag this because none of those proceedings should be attributed to Alacritech's '898.

---

Per-proceeding sections

None to report. No proceeding number can be listed without fabrication, so the template is intentionally empty.

---

Appendix — Sibling-family PTAB activity (expressly NOT proceedings on 7,042,898)

The '898 is a continuation-in-part in the same Alacritech 09/802,xxx family as the patents Alacritech did assert and did get IPR'd. Those proceedings are material context for a defendant (they supply a ready-made invalidity template and a forensics record), but none of them adjudicated any claim of 7,042,898. Alacritech itself lists 7,042,898 only as a family member in its mandatory notices (e.g., "U.S. Patent Application No. 09/802,426 (filed Mar. 9, 2001, issued May 9, 2006 as 7,042,898 patent)" — IPR2018-00328 / IPR2018-00234 notices).

IPR2017-01409 & IPR2017-01410 — Intel Corp. (with Cavium, LLC, Dell Inc.) v. Alacritech, Inc. — U.S. 8,131,880

• Type: Inter Partes Review
• Filed: 2017 (petitions); joined Cavium/Dell via later requests
• Status: Final Written Decision issued 2018-11-14 — challenged claims held unpatentable
• Judge panel: not confirmed from my sources for these two papers
• Petition grounds: § 103 obviousness over Thia (ROPE reduced-operation protocol engine) in view of Tanenbaum, Computer Networks (3d ed. 1996)
• Final Written Decision: '409 held unpatentable claims 1, 5–10, 12, 14, 16, 17, 20–23, 27, 28, 45, 55; '410 held unpatentable claims 32, 34, 35, 37–39, 41–43
• Appeal: Alacritech, Inc. v. Intel Corp., Nos. 2019-1467, 2019-1468 (Fed. Cir. July 31, 2020) (Moore, Chen, Stoll, JJ.) — affirmed as to claims 1 and 32; vacated-in-part and remanded as to claims 41–43 because the Board's obviousness analysis of the "reassembly in the network interface" limitation was "untethered from either party's position" and failed the APA's reasoned-decision requirement. See the panel's opinion and contemporaneous analyses (McDermott, Nat'l L. Rev. Aug. 2020). Separately, the consolidated Alacritech appeals in No. 19-1464 were vacated and remanded in light of Arthrex, over Alacritech's petition for rehearing en banc filed 2020-03-16.
• Defensive value: the Board's Thia+Tanenbaum theory has already been credited against sibling claims once, but its application to the reassembly limitations was vacated — so a defendant using this art against the '898 must independently build the record the Federal Circuit found missing.

IPR2017-01391 — Intel Corp. (with Cavium, LLC, Wistron Corp., Dell Inc.) v. Alacritech, Inc. — U.S. 7,237,036

• Type: Inter Partes Review
• Status: instituted on all challenged claims (claims 1–7); FWD issued (dated on or about 2019-01-16 when Alacritech noticed appeal)
• Judge panel: APJs Stephen C. Siu, Daniel N. Fishman, Charles J. Boudreau (Boudreau authored)
• Grounds: § 103, claims 1–7
• Joined petitioners: Cavium (IPR2017-01718), Wistron (IPR2018-00327), Dell (IPR2018-00371)
• Note: Alacritech litigated RPI/privity aggressively, arguing Intel and Wistron were privies (shared expert Dr. Robert Horst, near-verbatim petitions). The panel declined to find Dell a controlling RPI at institution.

Other sibling petitions (numbers verified, dispositions mixed)

• IPR2017-01405 ('205, Intel/Cavium), IPR2017-01392/-01393/-01406 (companions)
• IPR2017-01395 and IPR2017-01402 ('241 and related) — institution denied on procedural grounds; substantively re-filed as IPR2018-00234 ('948), IPR2018-00328 ('241, Wistron), IPR2018-00374 ('104)
• IPR2017-01734 (Cavium) — institution denied on procedural grounds
• IPR2018-00226 ('699, Intel/Cavium) — time-bar and RPI disputes over whether Cavium's intervention in the Dell case made Intel's petition timely

Related litigation (non-PTAB)

• Alacritech, Inc. v. [Microsoft Corp.](/litigations/by-plaintiff/Microsoft%20Corp.), No. C04-03284 JSW (N.D. Cal.) — asserted U.S. 6,427,171 and 6,697,868; preliminary injunction granted 2005-04-12 against Microsoft's "Chimney" TCP offload; settled July 2005 with licenses to Microsoft and Broadcom. The '898 was not asserted.
• Alacritech, Inc. v. CenturyLink, Inc., No. 2:16-cv-00693 (lead) / v. Wistron Corp., 2:16-cv-00692 / v. Dell Inc., 2:16-cv-00695 (E.D. Tex.). Patents-in-suit: '205, '036, '241, '072, '699, '880, '948, '104. The '898 is absent from the asserted-patent list. Docket: https://www.courtlistener.com/docket/[4389061](/patent/4389061)/alacritech-inc-v-centurylink-inc/

---

Strategic summary

Claim status of 7,042,898: entirely UNTESTED — and moot. Claims 1–7 (all seven claims: independent claims 1 and 5; dependent claims 2–4, 6–7) have never been construed by the PTAB, never been the subject of a petition, and never been canceled or confirmed. No claim is "canceled," so there is no FWD to link and no disposition to quote. The independent claims are directed to generating a partial header checksum before the payload transfer completes, storing a pseudoheader in the faster second memory, moving it to the payload memory, then combining the data-payload checksum with the header checksum on the fly during read-out to form the complete TCP packet (claims 1 and 5, with claim 2 reciting DRAM/SRAM and claim 7 reciting a sequencer plus processor). The more important fact for anyone reading a demand letter today is that the patent's term ended 2021-04-26, so post-expiration conduct cannot infringe and pre-expiration damages are confined to the 35 U.S.C. § 286 six-year lookback — a suit filed now reaches back only to roughly 2020-10-01, leaving an assertable window of about seven months.

Estoppel landscape: no § 315(e)(2) estoppel attaches to this patent at all. Because no IPR was ever instituted against the '898, no petitioner — Intel, Cavium, Dell, Wistron, or anyone else — is barred from raising any ground against it in district court, and conversely a defendant gets no benefit from the Board having already rejected Alacritech's arguments. Every prior-art ground (including the Thia/Tanenbaum combination that felled sibling claims, had it been applied here) remains fully available, subject only to the ordinary § 282 burden. The corollary risk runs the other way: the sibling IPRs show the family's claims are vulnerable to 1990s protocol-engine art, but the Federal Circuit's July 2020 vacatur on the reassembly limitations shows that vulnerability is not automatic.

Pattern signals. The same petitioner group (Intel + Cavium + OEM defendants Dell and Wistron) filed a coordinated wave of roughly a dozen petitions against Alacritech's family in 2017–2018, with Alacritech accusing them of serial harassment and pressing RPI/privity theories; the Board denied several on procedural grounds and allowed re-filed versions. Alacritech pursued Federal Circuit appeals aggressively — including an Arthrex Appointments Clause challenge it later asked to withdraw, and a rehearing petition that candidly cited the failing health of founder Larry Boucher as a reason to avoid remand. No defensive aggregator (Unified Patents, RPX) appears in the chain for the '898; RPX appears only peripherally as a cited authority in Alacritech's privity briefing.

---

Recommended next steps

• If a demand letter cites U.S. 7,042,898: lead with expiration. The patent's adjusted expiration is 2021-04-26. Post-expiration making/using/selling is not infringement, and any damages theory is capped by § 286 to a pre-expiration window that has now largely been consumed by the passage of time. Ask the sender to identify (a) the accused acts, (b) their dates, and (c) whether the acts predate 2021-04-26. If they cannot, the demand is defective on its face.
• Do not expect to find a PTAB win to cite. There is no FWD, no certificate of cancellation, and no IPR estoppel. Any argument that "claims 1–7 are canceled" would be false. The correct framing is: untested claims, lapsed term, no live injunction exposure.
• Check the license chain. The 2005 Microsoft settlement granted licenses to Microsoft and Broadcom, and Alacritech's own product documentation states that portions of its acceleration technology are used under Broadcom license. If your accused product is a Broadcom-supplied NIC/ASIC or a Microsoft TCP-Chimney-enabled stack, an exhausted/licensed-goods defense may be dispositive. Verify against the actual settlement documents, which were confidential.
• If you nonetheless need invalidity contentions (e.g., for a declaratory-judgment or a pre-2021 damages tail), mine the sibling record rather than starting from scratch: the Thia + Tanenbaum obviousness theory (IPR2017-01409/-01410 exhibits and the Alacritech v. Intel Nos. 2019-1467/-1468 appendix are public) is the highest-value starting point, and the Board's 2018-11-14 FWDs on 8,131,880 show how it maps to "intelligent network interface card" claim language materially similar to claim 1 of the '898.
• Docket links for citation: PTAB E2E — https://ptacts.uspto.gov/ptabweb; PTAB decisions — https://www.uspto.gov/patents/ptab/decisions; Federal Circuit opinions — https://cafc.uscourts.gov/opinions-orders; CourtListener (Alacritech v. CenturyLink docket) — https://www.courtlistener.com/docket/4389061/alacritech-inc-v-centurylink-inc/.

Confidence note: I am highly confident that no AIA trial proceeding names U.S. 7,042,898 — the structured ODP data says so and my searches found none. I could not independently verify the claim-level dispositions or panel compositions of several sibling proceedings (notably the final outcome of IPR2017-01391 and the post-Arthrex remand results), so I have deliberately left those unstated rather than guess.

I'll research the assignment record, inventor backgrounds, and Alacritech's corporate history to reconstruct the ownership chain.

Let me try to pin down the specific reel/frame records and the A-Tech LLC entity details.

Ownership & Assignment Analysis — US 7,042,898

Patent: "Reducing delays associated with inserting a checksum into a network message"
Appl. No.: 09/802,426 · Filed: 2001-03-09 · Issued: 2006-05-09 (from US2001/0036196A1, pub. 2001-11-01)
Family: Continuation-in-part of 09/464,283 ('173), 09/384,792 ('620), 09/067,544 ('880), etc.; earliest priority 1997-10-14.

Source note / limitation. The USPTO Assignment Center (https://assignmentcenter.uspto.gov, indexing the same records as https://assignment.uspto.gov/patent/index.html) was not directly readable in this research pass. The three recorded transfers below are taken from the Google Patents legal-events record for US7042898B2, which mirrors the assignment data. I could not retrieve the '898-specific reel/frame numbers or the recorded correspondent names, so where a reel/frame is shown it is the family-analogue reel/frame cited by Alacritech in its PTAB mandatory notices for sibling patents — flagged as such and not fabricated as '898-specific.

---

Inventors

All six named inventors were Alacritech, Inc. personnel at the time of filing; the invention was reduced to practice on Alacritech's "intelligent NIC" (INIC), and every inventor appears as an Alacritech company figure in the firm's contemporaneous histories.

Unusual patterns: None evidenced. I found no record of the inventors departing Alacritech within 12 months of the 2001-03-09 filing date, and the inventors had already assigned earlier family members (e.g., 09/464,283 / 09/384,792) to Alacritech, consistent with a settled employer-assignment program rather than an equity fire-sale. One data-quality quirk worth recording literally: the 2001-06-19 assignment record misspells the CEO's name as "Laurnce B. Boucher" (and the surname is consistently rendered "Higgen"). Treat as the same persons.

---

Original assignee

Alacritech, Inc. (San Jose / Santa Clara, CA) — a privately held operating company, founded 1997 by Larry Boucher with >$35M in VC funding.

• Shipped products embodying the claims: yes. Alacritech marketed "intelligent" NICs implementing Dynamic TCP Offload — the 100x2 DualServer Adapter, 1000x1, and the SEN2000/2100/3000 Scalable Network Accelerators built around its Internet Protocol Processor (IPP) ASIC. The '898 invention (generating the TCP checksum on the INIC as data moves, inserting the header checksum on the fly) is precisely the data-path behavior of those cards. Later the ANX 1500 NFS acceleration appliance carried the same offload silicon.
• Primary line of business: TCP/IP offload engine (TOE) server/storage NICs (1997–2008), then NFS storage-acceleration appliances (2008–2013). It also licensed its TOE patents to Broadcom, Microsoft, and Neterion.
• Enforcement history: sued Microsoft and Broadcom for infringement in 2004 (N.D. Cal.), settled in 2005 with licenses taken.
• Current status: Ceased operations. It did not achieve ANX sales and "essentially shut down" manufacturing and development in November 2013; as of ~2018 it was in the business of licensing its technology. I found no Chapter 7/11 filing — this was a wind-down, not a bankruptcy.

⚠️ Contradiction to flag. StorageNewsletter (2013-11-08) reported that on liquidation "its patent portfolio was acquired by NetApp." The USPTO assignment record contradicts this: the portfolio was recorded to A-Tech LLC (a Delaware entity), and Alacritech continued to own and litigate the family through 2023. Per the operating rule to prefer the primary/authoritative record, I treat the NetApp claim as inaccurate (NetApp was at most a licensee).

---

Assignment timeline

Three recorded transfers appear in the legal-events record. No '898-specific reel/frame was retrieved; family-analogue reel/frames are shown in brackets where Alacritech itself cited them in IPR mandatory notices.

• 2001-06-19 (recorded 2001-06-19) — Reel NNNNNN/NNNN not retrieved

  • Conveyance: Assignment ("ASSIGNMENT OF ASSIGNORS INTEREST")
  • Assignor: Higgen, David A.; Blightman, Stephen E. J.; Boucher, Laurence B. (rec. "Laurnce B."); Craft, Peter K.; Philbrick, Clive M.; Starr, Daryl D.
  • Assignee: Alacritech, Inc. (San Jose, CA)
  • Correspondent: not retrieved
  • Context: Initial inventor-to-company assignment of application 09/802,426 (recorded ~3 months post-filing — normal for a CIP).

• 2013-11-15 (recorded 2013-11-15) — Reel not retrieved; family analogues [031644/0783] (per '104 IPR2018-00374) and [031887/0753] (per '948 IPR2018-00234)

  • Conveyance: Assignment
  • Assignor: Alacritech, Inc.
  • Assignee: A-Tech LLC (Newark, DE)
  • Correspondent: not retrieved
  • Context: Portfolio transfer to an affiliated Delaware holding LLC, concurrent with Alacritech's Nov-2013 operational wind-down. (Corroborating tell: sibling application 14/038,297 — later US 8,805,948 — was filed 2013-09-26 naming A-Tech LLC as applicant, i.e., the holding entity was populating itself with the family in the same window.)

• 2016-06-22 (recorded 2016-06-22) — Reel [039068/0884] (family analogue; the same reel/frame is cited for every sibling in Alacritech's notices, suggesting one omnibus re-assignment record)

  • Conveyance: Assignment
  • Assignor: A-Tech LLC
  • Assignee: Alacritech, Inc.
  • Correspondent: not retrieved
  • Context: Reassignment of the portfolio back to Alacritech — executed/recorded 8 days before Alacritech filed its June 30, 2016 E.D. Tex. assertion campaign. A portfolio-level "clean standing before asserting" reorganization (though the '898 itself was not among the asserted patents).

If a same-record correspondent is later retrieved, the key check is whether the 2013 (into A-Tech LLC) and 2016 (out of A-Tech LLC) recordings share one attorney/firm of record; that recurrence — not the LLC names — would be the strongest tell. It could not be confirmed here and is not inferred.

---

Timeline diagram

timeline
    title Ownership of US 7042898
    1997 : Alacritech founded in San Jose
    2001 : Application 09 802 426 filed
         : Inventors assign to Alacritech
    2006 : Patent 7042898 issues
    2013 : Portfolio assigned to A-Tech LLC
         : Alacritech winds down operations
    2016 : A-Tech reassigns to Alacritech
         : Alacritech sues in East Texas

---

NPE / troll-pattern signals

1. Shell-entity transfer — PRESENT (moderate). The patent moved out of operating assignee Alacritech into A-Tech LLC on the 2013-11-15 record (family reels 031644/0783 and 031887/0753), a Delaware LLC in Newark, DE with no products in commerce. Two caveats keep this from being a clean "present-strong": (a) the name carries no IP/Licensing/Holdings suffix, and (b) the chain round-trips back to Alacritech, so A-Tech LLC reads as an affiliated holding/reorg vehicle at wind-down, not a detached third-party shell.

2. Known asserter in the chain — NOT PRESENT. No classic NPE-list entity (Acacia, Marathon, Intellectual Ventures, IPNav, Wi-LAN/Conversant, Vringo, Pendrell, Round Rock, Spangenberg entities, etc.) appears anywhere in the chain. All assignees are Alacritech, Inc. or its affiliate A-Tech LLC. Nuance: Alacritech is itself a former operating company that became a non-practicing enforcer after 2013 (large 2016 E.D. Tex. campaign vs. CenturyLink, Wistron, Dell, et al.), but it is not surfaced on the standard NPE registries.

3. Repeat correspondent across the chain — UNCLEAR / NOT DETERMINABLE. Correspondent names were not retrievable. No finding either way; do not infer from the LLC naming.

4. Cascading transfers — NOT PRESENT. Only two post-issuance transfers, spaced ~31 months apart (2013-11-15 → 2016-06-22). This is not a rapid <24-month LLC cascade.

5. Pre-litigation transfer — NOT PRESENT for the '898 itself. The '898 was never asserted, so no transfer ties to a suit naming it. Portfolio-level observation (not a '898 finding): the 2016-06-22 A-Tech→Alacritech reassignment sits 8 days before the 2016-06-30 complaint filings — a clean-standing setup — but those suits asserted the '205/'036/'241/'072/'880/'948/'104/'699 patents, not the '898.

6. Bankruptcy fire-sale — NOT PRESENT. No Chapter 7/11 located; Alacritech wound down operations rather than liquidating through bankruptcy. (See the flagged StorageNewsletter/NetApp contradiction above.)

7. Privateering — NOT PRESENT / UNCLEAR. No evidence of an operating company transferring to an NPE to assert on its behalf. Alacritech does its own enforcing.

8. Defensive aggregator — NOT PRESENT. The chain does not terminate at RPX, AST, LOT, Unified Patents, or OIN. Current owner is again the original operating company, now non-practicing.

---

Verdict

NPE — moderate confidence.

The chain shows a genuine operating company (Alacritech, which shipped cards embodying these claims) transferring its whole portfolio to A-Tech LLC, a Newark, Delaware holding entity with no apparent products, on the 2013-11-15 record as operations wound down — and then reassigning it back to Alacritech on the 2016-06-22 record (family reel 039068/0884), eight days before launching its 2016 E.D. Tex. campaign, after which Alacritech practices nothing. That non-practicing-enforcer posture plus the holding-LLC transfer is one strong signal, so moderate rather than high: no classic NPE-list entity appears, no repeat NPE correspondent could be confirmed, the transfers are three years apart (not a rapid cascade), and US 7,042,898 itself was never asserted.

Verify at: https://assignmentcenter.uspto.gov/ (search patent 7042898) and https://patents.google.com/patent/US7042898B2/en (legal events).

I'll research the specific prior-art references cited against US 7,042,898, starting with the patent itself and the most checksum-relevant citations.

Prior-Art Analysis — U.S. Patent No. 7,042,898 B2

Note on scope and method. I searched for the exact number (7042898 / 7,042,898) and relied on the authoritative full text you supplied, which reproduces the patent's own "Patent Citations (93)" and "Family Cites Families (6)" lists. I retrieved full/public text for the highest-relevance references and used title/assignee-level descriptions (clearly flagged) for the low-relevance background art. I did not retrieve the full specification of all 93 references, so descriptions for Tier 3–5 below are derived from the citation data on the patent's face and should be verified against the actual documents before being relied upon in a validity opinion.

---

A. The patent and what must be anticipated

Critical limitation set (independent claims 1 and 5):

1. (a) Transfer a data payload from host memory to a first memory of a network interface device (NID).
2. (b) On the NID, before (a) completes, create a pseudoheader (header portion + a checksum of the header portion only, not the data payload) and store it in a second memory of the NID.
3. (c) On the NID, before (a) completes, transfer the pseudoheader from the second memory to the first memory.
4. (d) After (c), generate on the NID a checksum for the data payload; pseudoheader + payload = "pseudopacket."
5. (e) Read the pseudoheader and at least a portion of the payload from the first memory and combine the header checksum with the payload checksum to generate a final checksum, insert it into the pseudopacket to form a complete TCP packet, and output the complete packet from the NID to a network (checksum inserted "on the fly" during read-out).

Dependent-claim features: DRAM/SRAM split (2); second memory faster than first (3); NID part of host computer (4); same for claim 6; sequencer does the reading and a processor does the creating (7).

Priority-date nuance (important for §102 analysis). Although '898 claims 1997 benefit, it is a CIP filed 2001-03-09. The examiner cited numerous references filed/published in 1998–2000. Those can only be §102 prior art if (i) the specific '898 claims are not entitled to the 1997 priority date (a real risk for CIP claims), or (ii) they qualify under §102(e) as U.S. patents/applications whose filing dates precede the '898's effective date. Any reference given a 1997-10-14-or-earlier priority is squarely §102(a)/(b)/(e) art. I flag this where it matters.

Observation on citation provenance. In the reproduced citation lists, only two references carry the "cited by examiner" asterisk: US 5,541,920 (Bay Networks, delayed-replace streaming packet modification engine) and US 5,898,713 (Cisco, IP checksum offload). The remaining ~91 patent references appear to have been IDS-submitted by the applicant. This strongly suggests the examiner viewed those two checksum-insertion references as the closest art — and they are, indeed, the most on-point to claim 1(e).

---

B. Tier 1 — Most relevant references (detailed §102 assessment)

1. US 5,541,920 A — Method and apparatus for a delayed replace mechanism for a streaming packet modification engine

• Assignee: Bay Networks, Inc. | Filed: Jun. 15, 1995 | Issued: Jul. 30, 1996 | Examiner-cited (*)
• Disclosure: A streaming packet-modification engine buffers a packet through a data FIFO while inserting a placeholder + tag where a checksum field will go. The engine computes the new checksum as the packet streams through and stores the result in a replace FIFO. As the packet is streamed out, FIFO control logic sees the tag, retrieves the replacement value, and overwrites the placeholder while transmission continues (delaying only if the replacement isn't ready). An alternative uses a replace SRAM for multiple out-of-order replacements. The specification expressly notes the checksum field is "embedded within the header with subsequent data being utilized in determining" it, and that the technique "allows for data streaming of data packets in which a field may be modified based on data following it within the same data packet," eliminating "load and store accesses to a conventional memory array."
• §102 impact: This is the single best anticipation candidate for the "generate checksum on the fly and insert it into the packet as it is read out" concept of claim 1(e)/claim 5(e). It discloses the placeholder → compute-while-buffering → overwrite-on-output mechanism. However, it does not disclose: (i) the split between a header-only partial checksum (pseudoheader) and a separate data-payload checksum that are combined; (ii) the host-memory → NID first memory payload transfer of step (a); or (iii) header built in a second (faster) memory before payload transfer completes (steps b–c). A careful reading shows it computes a single header checksum (IP-style), not the TCP pseudoheader-plus-payload combination. Anticipation of claim 1 as a whole is unlikely; it is, however, the strongest §103 base reference for the on-the-fly insertion limitation.

2. US 5,898,713 A — IP checksum offload

• Assignee: Cisco Technology, Inc. | Filed: Aug. 29, 1997 | Issued: Apr. 27, 1999 | Examiner-cited (*), listed under "Family Cites Families"
• Disclosure: Offloads IP checksum generation from a host to a control unit. The host generates an IP datagram without checksum information, transmits it to the control unit over an "IP checksum offload link"; the control unit calculates the checksum, loads it into the header, and forwards the packet onto the network. Symmetrically, the control unit can verify a received checksum before forwarding to the host.
• §102 impact: Directly relevant to the "generate the checksum at the network device and insert it into the packet header" aspects of claims 1(d)–(e)/5(d)–(e). Its claims 5–6 recite the "host generates packet without checksum → offload device calculates checksum → load into header → transfer to network" sequence. It does not disclose the two-part (header partial + payload partial) checksum, the SRAM/DRAM ordering, or the pre-completion pseudoheader build. Not a standalone anticipation of claim 1; strong §103 material for the checksum-offload concept.

3. US 5,937,169 A — Offload of TCP segmentation to a smart adapter (Connery et al.)

• Assignee: 3Com Corp. | Filed: Oct. 29, 1997 | Issued: Aug. 10, 1999
• Disclosure: Host supplies a large datagram + a TCP/IP header template to a "smart" NIC; the NIC segments the payload and creates per-packet TCP/IP headers from the template, computing IP header checksums and TCP checksums at the network interface. Notably teaches the option (B) of "only download[ing] the header (and perhaps some of the payload) and download[ing] additional payload as needed," with headers produced and checksums computed "as the segments are pulled."
• §102 impact: Relevant to claims 1(a)–(d). It teaches host→NID header-template transfer followed by payload transfer, and checksum computation at the NID. It does not clearly teach a header-only partial checksum stored in fast memory and later combined with a payload checksum on read-out. This reference was later the primary reference in IPRs against other Alacritech family patents (e.g., the '072/'104 patents), so it is a serious §102/§103 reference; standalone anticipation of '898 claim 1 is doubtful.

4. US 6,173,333 B1 — TCP/IP network accelerator system and method which identifies classes of packet traffic for predictable protocols (Jolitz et al.)

• Assignee: Interprophet Corp. | Priority: Jul. 18, 1997 | Filed: May 17, 1999 | Issued: Jan. 9, 2001
• Disclosure: Hardware network accelerator performing TCP/IP protocol processing at signaling rates; programmable logic processes packet headers in parallel and during memory transfers without store-and-forward; packets with checksum errors are handled in software; continuous-flow delivery via CAM pattern matching.
• §102 impact: Relevant background to the NID-offload and hardware-checksum environment of claim 1. It emphasizes avoiding store-and-forward, whereas '898 uses DRAM assembly, so it does not disclose the pseudoheader-in-SRAM-then-DRAM sequence. §103 combination material, not anticipation.

5. US 6,034,963 A — Multiple network protocol encoder/decoder and data processor (and sibling publication WO 1998/019412 A1)

• Assignee: iReady Corp. | Priority: Oct. 31, 1996 | Pub.: May 7, 1998 | Patent issued: Mar. 7, 2000
• Disclosure: Programmable/large-scale-integration protocol encoder/decoder for consumer devices; network protocol processing (TCP/IP) offloaded into dedicated hardware.
• §102 impact: General prior art as to offloading protocol/checksum processing to an interface device. §103 background; no disclosure of the two-memory pseudoheader assembly.

6. US 6,141,705 A — System for querying a peripheral device to determine its processing capabilities and then offloading specific processing tasks from a host to the peripheral device

• Assignee: [Microsoft Corp.](/litigations/by-plaintiff/Microsoft%20Corp.) | Priority: Jun. 12, 1998 | Issued: Oct. 31, 2000
• Disclosure: Host queries a peripheral's capabilities and offloads selected protocol-processing tasks (conceptually including checksum tasks) to it.
• §102 impact: General "offload to peripheral" art for the NID-based processing premise of claims 1/5. §103 background, not anticipation.

Tier 1 conclusion: No single Tier-1 reference discloses all of claim 1, principally because none teaches the (i) header-only partial checksum built in a second memory before the payload transfer completes, then (ii) combined on read-out with a separately computed payload checksum. The two examiner-cited references (US 5,541,920 and US 5,898,713) collectively teach most of the on-the-fly/offload concept, making them the most dangerous §103 combination.

---

C. Full citation table — the remaining 87 patent citations

Legend: C1 = claim 1 (method); C5 = claim 5 (apparatus); C2/C3 = DRAM/SRAM & faster second memory; C4/C6 = NID part of host computer; C7 = sequencer reads / processor creates. "Bg" = background only. Descriptions from title/assignee data unless a document was retrieved. All are §102(a)/(b)/(e) candidates only if entitled as prior art given the priority-date nuance in Section A.

C.1 Networking / protocol-processing interface hardware

C.2 Memory architecture / DMA / FIFO / DRAM-SRAM references (relevant to claims 2–3)

C.3 Storage / file-server / RAID / Fibre-Channel references (low relevance)

C.4 Routers / packet switches / misc. (very low relevance)

C.5 IETF/offload-era and Jolitz/IP-applicant references

Note: The official "Patent Citations (93)" list orders these slightly differently (e.g., it lists US 6,136, etc.), but the substantive set is as tabulated. Two entries in the reproduction are duplicate/renumbered (US 5,930,830 and the second listing of the Alacritech parents); I have de-duplicated.

---

D. "Family Cites Families (6)" references

These are references cited against related family members, not necessarily against '898; several predate the 1997 priority.

---

E. Consolidated §102 assessment

No cited reference appears to anticipate claim 1 (or its apparatus counterpart claim 5) as a whole. Anticipation requires a single reference disclosing every limitation, including the distinctive ordered combination:

• build a header-only partial checksum (pseudoheader) in a second (faster) memory before the payload transfer finishes,
• move the pseudoheader into the first (DRAM) memory, then
• combine it with a separately computed payload checksum on the fly during read-out to form the final TCP checksum, and output the complete packet.

The two examiner-cited references cover adjacent ground:

• US 5,541,920 (Bay Networks) — placeholder + compute-while-streaming + overwrite-on-output (the claim 1(e) insertion mechanic), but for a single checksum and without the host-memory/dual-memory payload-assembly.
• US 5,898,713 (Cisco) — checksum computation/insertion offloaded to the network-control-unit, but no pseudoheader/partial-checksum split and no SRAM→DRAM ordering.

The most likely examiner/validity theory is therefore §103 combining a checksum-offload reference (US 5,898,713 and/or US 5,541,920) with an intelligent-NIC/protocol-offload reference (US 5,937,169 Connery; US 6,173,333 Jolitz; US 6,034,963 iReady), not §102. References such as US 5,412,782 (early-interrupt Ethernet adapter), US 5,752,078 (latency minimization), and US 5,930,830 (discontiguous-page/scatter-gather) support isolated limitations or the motivation to reduce transmit latency.

Dependent-claim art:

• Claims 2/3 (DRAM first memory; faster SRAM second memory): US 5,699,317 (Ramtron enhanced DRAM), US 5,701,516 (Auspex NVRAM write cache), US 5,664,114 (HP FIFO queuing), US 5,097,442 (TI FIFO) show fast/slow memory hierarchies or replace-FIFO buffering — but none in the claimed pseudoheader context.
• Claim 7 (sequencer reads / processor creates): US 5,303,344 (Hitachi control/data split) and US 5,541,920 (separate data-FIFO and replace-FIFO/control logic) are the closest structural analogues.

---

F. Confidence, caveats, and what to verify

• Confidence: High that the two examiner-cited references are the closest art (they are the only "*" entries and both concern checksum handling). Moderate-to-high on the Tier-1 analyses (full text retrieved for US 5,541,920, US 5,898,713, US 5,937,169, US 6,173,333, US 6,034,963). Low-to-moderate on Tier 3–5 descriptions, which are title/assignee-level inferences — treat them as leads, not conclusions.
• Priority-date caveat (material): Whether the 1998–2001 filings are §102 art at all depends on whether the '898 claims are entitled to the Oct. 14, 1997 priority date. Because '898 is a CIP with substantial new matter (the pseudoheader/on-the-fly scheme), a defendant or IPR petitioner would likely argue an effective date closer to the Mar. 9, 2001 filing, which would remove many post-1997 references from §102 and shift the case to §103/§102(e).
• Not prior art: US 6,226,680 and US 6,247,060 (and WO 2000/013091) are applicant's own family members, cited for completeness but unavailable as prior art against '898.
• Suggested next steps: (1) pull the file wrapper (App. No. 09/802,426) to confirm which references the examiner actually applied and under what statutory basis; (2) retrieve full text of US 5,412,782, US 5,752,078, and US 5,937,169 for the latency/offload limitations; (3) confirm no litigation/PTAB challenge to '898 (consistent with the previously generated litigation section, which found no asserted case).
• Tooling limit: I reached my research-step limit while retrieving full text for the lower-tier references; the Tier 3–5 descriptions above are drawn from the patent's own citation data rather than independent full-text review.

I'll ground this analysis by verifying the content of the key examiner-cited references before building the obviousness combinations.

I have strong content for the Cisco and Bay Networks references. Let me verify a few more cited references relevant to the NIC-offload and checksum-decomposition elements.

Obviousness Analysis — U.S. Patent No. 7,042,898 Under 35 U.S.C. § 103

Patent: US 7,042,898 B2, "Reducing delays associated with inserting a checksum into a network message"
Assignee: Alacritech, Inc. (now A-Tech LLC / Alacritech)
Application: 09/802,426, filed Mar. 9, 2001; priority claimed to Oct. 14, 1997 (CIP chain)
Claims analyzed: 1–7 (7 total; 2 independent)
Prior-art source: the citation lists on the Google Patents page for US7042898B2 (the "Patent Citations (93)" and "Non-Patent Citations (47)" sections) — treat this as the scope of the "Prior Art section." Note that Alacritech's own family members (US 6,226,680; 6,247,060; 6,427,173; 6,434,620) appear in those lists but are the inventors' own commonly-owned prior applications and are disqualified as § 103 references under pre-AIA § 103(c); I exclude them below.

Evidence caveat up front. For several references I have only the title/abstract and, for the two most important ones, verified specification text. Where I map a limitation to a reference, I say whether I am relying on verified text (US 5,541,920; US 5,898,713) or on title/abstract-level knowledge. A full validity opinion would require the complete specifications and the prosecution history. Where I lack the text, I flag it rather than assert it.

---

I. Governing framework and level of ordinary skill

Because the application was filed in 2001 and claims priority to 1997, pre-AIA § 103 governs. The question is whether the differences between the claimed subject matter and the prior art are such that the subject matter as a whole would have been obvious to a person of ordinary skill at the time of the claimed invention. Graham v. John Deere Co., 383 U.S. 1 (1966). Where the claimed "invention" is the arrangement of known elements (a NIC, two memories of different speeds, checksum hardware, a transmit engine marked "must insert a checksum into network message"), the combination is presumed obvious when it does no more than yield predictable results. KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398, 416–17, 421 (2007).

POSITA: a designer of network interface hardware/software with a B.S. in EE/CS (or equivalent) and ~2–3 years' experience in network-adapter and protocol-offload design as of 1997–2001. Such a person would (i) understand the TCP/IP checksum arithmetic, (ii) know the classic latency bottleneck of "checksum depends on the entire payload, but the checksum field precedes the payload," and (iii) know the NIC-offload design patterns of the late 1990s.

The single technical problem the claim addresses. The patent's own Background concedes the entire problem statement (spec., "Background Information": "the checksum of the TCP packet is located near the front of the packet … The checksum is a function of all the data of the data payload. Consequently all the data of the payload must generally be transferred to the INIC … before the checksum can be generated"). The claimed solution is the specific choreography of when and where the partial checksums are computed and how the final value is injected — not the existence of NIC checksum offload, which was old.

---

II. Claim 1, element by element, against the cited prior art

Claim 1 is a five-step method. Mapping the steps to the strongest cited references:

Why Bay Networks US 5,541,920 is the dispositive reference for step 1(e)

This reference, cited by the examiner, is "Method and apparatus for a delayed replace mechanism for a streaming packet modification engine." Its verified specification states the exact mechanism:

"when the Checksum field for an IP data packet reaches the packet modify engine, the data written into the data FIFO may include dummy data or the old Checksum value. In addition, an identifier or tag is stored … indicating the presence of a Checksum field … to be overwritten upon transmission." … "In response to this control signal, the FIFO control logic instructs the replace FIFO to provide the result data through the multiplexing logic into the reserved space of the data packet being streamed out of the data FIFO." … "If the FIFO control logic determines that the replace data is not yet available, it delays the transmission until the data is present."

That is, in substance:

• a placeholder / partial value is written into the packet buffer early (claim 1(b)/(c) analog),
• the real value is computed after the dependent data streams by (claim 1(d) analog), and
• the computed value is substituted into the packet as it is read out and streamed to the network (claim 1(e) exactly).

Bay Networks even recites the general problem the '898 patent claims to solve: "fields like the Checksum field which may change … Note that the Checksum field is embedded within the header with subsequent data being utilized in determining the value of the Checksum field." Bay Networks uses a FIFO/SRAM, and the abstract expressly notes "a fast memory such as a static random access memory (SRAM) may be implemented" for the replacement data.

The only facial difference is that US 5,541,920 illustrates an IP header checksum in a router, whereas claim 1 is a TCP checksum over header+payload. That difference is bridged by Cisco US 5,898,713, which expressly discloses computing the TCP checksum at the network-side device and loading it into "a conventional TCP or UDP header," and by Stevens pp. 325–326, which set out the TCP pseudo-header arithmetic. A POSITA applying the Bay Networks delayed-replace mechanism to the TCP checksum would do no more than apply a known field-replacement mechanism to a known field.

---

III. The primary obviousness grounds

Ground 1 (strongest): Bay Networks US 5,541,920 in view of Cisco US 5,898,713, further in view of Connery US 5,937,169

• US 5,541,920 (Bay Networks): delayed replace of a checksum field into a packet as it streams out, using a placeholder + tag and a fast replacement memory. → claims 1(b)–(e) mechanism.
• US 5,898,713 (Cisco): offload of the TCP/UDP checksum calculation to the network-side control unit, with the computed value loaded into the TCP header; also incremental/selective checksum handling. → converts the Bay Networks IP-checksum teaching into a TCP checksum at the adapter, and supplies step 1(d).
• US 5,937,169 (Connery / 3Com): smart adapter builds TCP/IP headers from a header template and computes IP and TCP checksums; "handling a large quantity of data at the TCP layer allows the protocol … to avoid allocating blocks of data for copies of the packet header, copying it, and freeing it." → supplies steps 1(b) and 1(c) (header constructed in adapter memory and placed into the packet buffer without a per-packet host round trip).

Result: every limitation of claim 1 appears in the combination, and the combination yields only the predictable result of "compute the header contribution early, stream payload in, inject the final checksum on egress."

Ground 2: Cisco US 5,898,713 in view of Connery US 5,937,169 and Stevens (TCP/IP Illustrated)

A reference-per-limitation mapping using Cisco for checksum offload/insertion, Connery for adapter-side header construction and TCP checksum computation, and Stevens for the TCP pseudo-header decomposition. This is the "all elements in the same field" ground and is a natural fallback if Bay Networks is distinguished as an IP-only (router) reference.

Ground 3: Add the "intelligent NIC" context references

• Interprophet US 6,173,333 — "Processing of packet headers is performed in parallel and during memory transfers without the necessity of conventional store and forward techniques resulting in a substantial reduction in latency." → supplies the motivation (reduce latency by processing headers during data movement) and adapter-side header processing (1(b)–(c)).
• iReady US 6,034,963 — hardware protocol encoder/decoder that "adds formats to the packet, and checksums the … header information, and forwards the resulting network packet." → adapter computes header checksum (1(b)).
• US 5,752,078 (IBM) — handling packet error "while transferring data packet from adapter memory to host memory" → evidence that on-the-fly packet manipulation during a memory transfer was known; supports the streaming premise of 1(e).

---

IV. Motivation to combine (the KSR analysis)

A POSITA in 1997–2001 had multiple, concrete, articulated reasons to combine these references — the "articulated reasoning" requirement is satisfied by each of the following independent rationales:

1. Same field, same problem, same solution. All references are in packet processing / network-adapter offload. The '898 Background itself concedes the problem (checksum field precedes a payload on which it depends) is old; Bay Networks frames it identically and offers the same class of solution (defer the field and replace it on egress).
2. Known technique applied to a known field. The Internet checksum is linear: the header contribution and payload contribution can each be computed independently and summed. That property is the core of Cisco's incremental checksum handling and is set out in Stevens at 325–326 and in RFC 1071. Once one knows the checksum is a separable sum, it is a mere design choice to compute the header half early.
3. Named, predictable improvement in the prior art. Interprophet expressly promises "a substantial reduction in latency" by processing headers during memory transfers; Cisco promises reduced host CPU cost; Connery promises avoidance of header copying. The '898 patent claims exactly that predictable benefit (avoiding the "slow write to DRAM of the complete TCP header"). KSR, 550 U.S. at 417 ("if a technique has been used to improve one device, and a person of ordinary skill … would recognize that it would improve similar devices in the same way, using the technique is obvious"). Improvement in one known technology does not make a claim nonobvious.
4. Design-incentive / finite number of identified solutions. Reducing per-packet latency on the transmit path by eliminating a post-payload DRAM write is a classic bottleneck; the prior art had already identified "compute early / insert on egress" as a solution. This is a "design incentive … [with] a finite number of identified, predictable solutions." Id. at 421.
5. Two-memory split was itself old. The '898 specification concedes the SRAM-for-headers / DRAM-for-payload architecture was pre-existing, and US 5,699,317 (Ramtron, "Enhanced DRAM with all reads from on-chip cache and all writes to memory array") is cited for the memory-speed differential. The claim's only distinctive requirement is a relative speed ordering (claim 3) — textbook SRAM-vs-DRAM. Cf. Tanenbaum, Computer Networks (cited NPL).

No teaching away appears in any reference, and the references are combinable by simple substitution of one known packet-processing element (a checksum-insertion engine) into the known NIC architecture, producing predictable results.

---

V. Dependent claims 2–7

Thus claims 2–7 add no limitation that survives the same combination; each is either expressly suggested by a cited reference or is an admitted/per se design choice.

---

VI. Anticipated rebuttals and how they fare

1. "Bay Networks is about routers/IP, not TCP at a NIC." Rebutted by Cisco US 5,898,713 (TCP checksum computed at the control unit and loaded into the TCP/UDP header) and Stevens pp. 325–326 (TCP pseudo-header arithmetic). The field-replacement mechanism is protocol-agnostic; applying it to the TCP checksum is the predictable use of a known mechanism for its known function. KSR, 550 U.S. at 416–17.
2. "The references don't teach computing the header checksum before the payload transfer completes." This is inherent in the property that the header contribution is independent of the payload; Cisco's incremental/offload approach and the "header template" of Connery (header built before/independent of the payload segments) supply it. The temporal limitation is the natural consequence of a separable checksum and parallel data movement (Interprophet: process headers "during memory transfers").
3. "The references don't teach combining the two partial checksums." One's-complement addition of partial sums is elementary (RFC 1071; Stevens). Combining partial checksums is not a separate inventive act.
4. Secondary considerations (§ 103 objective indicia). I have not seen evidence of nexus-bearing unexpected results, industry praise, copying, or long-felt-but-unsolved need tied to the claim-1 features. The patent's own Background characterizes the architecture as a known design with one latency disadvantage, which undercuts any "unexpected results" argument. Any rebuttal evidence would need to be evaluated for nexus to these specific limitations.

---

VII. Confidence, and what would change the conclusion

• High confidence that US 5,541,920 (Bay Networks) discloses the core step-1(e) mechanism and the placeholder-then-replace idea, because I verified its specification text.
• High confidence that US 5,898,713 (Cisco) discloses adapter-side TCP checksum calculation and insertion into the TCP header, because I verified its text.
• Moderate-to-high confidence on the Connery/iReady/Interprophet teaching of adapter-side header construction and TCP checksum computation; these are supported by verified abstracts and specification excerpts, but a complete charting would require full specification pin-cites.
• Lower confidence on the precise internal configuration of US 5,752,078 (IBM), US 5,569,840/5,566,170 (StorageTek), and US 5,699,317 (Ramtron); I used them only as corroborating background.

A formal § 103 challenge would still want to (i) pin-cite each limitation to a column/line of the full texts, (ii) confirm the effective filing date of each claim (the CIP claims may only be entitled to the Mar. 2001 date for the added matter, which helps the references — all are from 1995–1999), (iii) check whether any claim-specific limitation was argued during prosecution, and (iv) confirm no § 103(c) common-ownership disqualification applies to any chosen reference.

Bottom line: On the record of the references cited on the '898 patent itself, claim 1 is prima facie obvious over US 5,541,920 in view of US 5,898,713 and US 5,937,169, with Stevens (TCP/IP Illustrated, pp. 325–326) as the teaching of the TCP pseudo-header/checksum decomposition, and with US 6,173,333 and US 6,034,963 supplying the intelligent-NIC context. Claims 2–7 are obvious over the same combinations plus the conventional SRAM/DRAM and sequencer/processor design choices.