US 6289023

I'll search for authoritative information on US 6289023, including any recent litigation/docket activity.

Let me check for any litigation or CAFC docket activity specifically tied to this patent.

US 6,289,023 B1 — Analyst Summary

Bibliographic data (per the grant front page / Google Patents, fetched 2026‑09‑24)

Source: https://patents.google.com/patent/US6289023/en and the USPTO‑derived listing at https://uspto.report/patent/grant/6289023

Abstract (as published)

"A fly-by checksum is generated at a lower layer of the protocol stack and travels up to a high layer of a protocol stack to verify incoming data. In one embodiment, a network adapter comprises includes one or more protocol stacks and a LAN controller that includes a fly-by checksum generation unit. A checksum algorithm is registered with the fly-by checksum generation unit for each protocol layer that is to receive a fly-by checksum. As an incoming packet is transferred from network media to network adapter memory, the fly-by checksum generation unit calculates a fly-by checksum for each checksum algorithm that has been registered. After the fly-by checksums are complete, they are transmitted to the network adapter memory and are transmitted up the appropriate protocol stack within a checksum channel. When data reaches a layer of the protocol stack for which the fly-by checksum was generated, the fly-by checksum is removed from the checksum channel and is used to verify the integrity of the data."

Independent claims — plain-language overview

Claim 1 — method (receive path with DMA). A network node has a network adapter and a multi‑layer protocol stack. The method: (1) receive packet bytes at a transceiver coupled to the network media; (2) move those bytes to a DMA unit; (3) DMA them into adapter memory; (4) calculate a code over only a portion of the incoming packet, in parallel with the media‑to‑memory transfer; (5) put the code into a "code channel" associated with the protocol stack; (6) deliver data extracted from the packet to a first layer of the stack; and (7) that layer verifies the extracted data using the code taken from the code channel. The key idea is that the checksum rides alongside the data ("fly‑by") rather than being computed after the packet arrives at the consuming layer.

Claim 4 — method (byte counting / begin-byte accumulation). Same overall receive‑path and channel/verify structure, but the calculating step is expressed structurally: transfer packet bytes from network media to memory; count the bytes of the incoming packet; accumulate a code on bytes identified by a beginning byte position; terminate accumulation; move the code to the code channel; deliver extracted data to a first layer; verify using the channel's code.

Claim 7 — method (with algorithm registration). Adds an initial step of registering a checksum algorithm, then: transfer packet bytes from network media to memory; calculate a code over a portion of the packet as the bytes are transferred; put the code in the code channel; deliver extracted data to a first layer; verify using the code. This is the claim that captures the "protocol layer registers its checksum requirements with the hardware up front" aspect highlighted in the specification.

Claim 10 — apparatus (network node). A network node comprising: a protocol stack; a memory unit; a transceiver coupleable to network media; a memory access unit between transceiver and memory for transferring incoming packet bytes from network media to main memory; an algorithm execution unit that executes an algorithm to compute a code over a portion of the packet as the bytes are being transferred; and a code channel associated with the protocol stack that receives the code from the algorithm execution unit and carries it up the stack together with the received packet data.

Dependent claims add: checksum code vs. generic code (2, 16); TCP/IP stack (3, 17); ending byte position/register (5, 13, 14); post‑processing such as odd‑octet padding (6, 15); registration specifying beginning/ending byte positions (8, 19); parallel computation for each registered algorithm (9, 18); beginning byte register (12); algorithm‑unit accepting registration requests and computing a code per registered algorithm (18).

Claim‑drafting note

The claims deliberately use the broader terms "code" and "code channel" rather than "checksum" and "checksum channel" (the specification explains that the same mechanism may carry error‑correcting codes or decryption results — see the "checksum algorithm unit 84 may be programmed to generate an error correcting code…" and "decrypted channel" passages). Claim 2/16 then narrow to a checksum code specifically. Claim 1 also differs from claims 4 and 7 by reciting the explicit transceiver → DMA unit → adapter memory path.

Literal‑transcription caveat: the Google Patents OCR text of the claims contains apparent typos — claim 10 reads "a transceiver coupled capable of being coupled to network media" and "the maim memory unit"; claim 4 reads "terminating accumulating the coded"; claim 6 reads "tempting accumulating." Likewise, FIG. 5's description states the packet "is 124 bytes long" but then says "bytes 121‑1124 hold MAC CRC code 103." I cannot verify from the sources retrieved whether these errors exist in the printed patent or are OCR artifacts — treat them as uncertain and check the USPTO PDF (https://patentimages.storage.googleapis.com/3a/df/c4/9946882b71ee8c/US6289023.pdf) before relying on exact claim wording.

Litigation / CAFC 2026 docket check

I ran targeted searches for any Federal Circuit or district-court activity citing patent 6,289,023. I found no Federal Circuit 2026 docket entry, opinion, IPR, or pending litigation naming US 6,289,023. I must flag a genuine limitation here: my searches were general web searches, not a direct query of the USPTO PatentCenter/PAIR or the CAFC docket system, so I cannot state with high confidence that no such proceeding exists. What I can say with confidence is that (a) the patent is recorded as expired as of the 2017‑09‑25 statutory term end on the sources retrieved, and (b) no co‑pending or recent Federal Circuit matter referencing this number surfaced. Note also that search results frequently conflate this number with unrelated patents or other documents numbered "'023," so any cite you find elsewhere should be verified against the application number 08/937,912 rather than the bare "023" suffix.

Context worth knowing

The patent cites as prior art US 5,522,039 (Snyder et al., Hewlett-Packard, "Calculation of Network Data Check Sums by Dedicated Hardware With Software Corrections") — the "gross checksum minus irrelevant portions = net checksum" approach — and expressly distinguishes it: here the hardware is pre‑configured with per‑layer beginning/ending byte offsets so each layer's checksum is computed correctly the first time, in parallel, and carried up the stack. It also cites EP0572146A2, US5430842, US5491802, US5500864, US5,581,385, EP0725346A1, WO1996041424A1, US5815516, and US5805818. The specification reports a measured throughput improvement of roughly 10%–20% in receive‑heavy nodes such as network printers, and notes backward compatibility with protocol stacks that do not support fly‑by checksums.

I'll search for litigation involving US patent 6289023 across patent litigation sources.

Let me search more specifically across patent litigation databases.

Let me check the Google Patents litigation tab and other patent litigation aggregators directly.

Litigation Search Results: US Patent No. 6,289,023

Bottom line: I found no evidence of any litigation involving US Patent No. 6,289,023 (US6289023B1). The patent does not appear to have ever been asserted in a district court, the ITC, or the PTAB.

The patent itself (for identification)

The patent is a Hewlett-Packard hardware checksum-offload patent covering a "fly-by checksum" generated in the LAN controller ASIC and propagated up the protocol stack via a "checksum channel." Family members: EP0905938B1 (EP), JPH11168451A (JP), DE69828233T2 (DE).

What I searched and found

1. Google Patents litigation records for US6289023B1 — No litigation section, and the "Cited By / Families Citing" tables list only later patent filings (e.g., Alacritech, Broadcom, Juniper, Intel, VMware offload/checksum patents), not lawsuits.
2. Unified Patents litigation portal / case lists — No results referencing this patent.
3. RPX Insight / Docket Navigator–oriented queries — No hits.
4. General web and CourtListener/CAFC searches for "6289023" and "6,289,023" — Only false positives, none of which involve this patent:
   • An Illinois Assistant Chief Deputy Attorney General's attorney registration number (#6289023) appearing in unrelated civil-rights filings.
   • U.S. Patent No. 10,853,023 (Sonos v. Linkplay IPR) — a different patent whose number contains "023."
   • U.S. Patent No. 11,283,454 citing 6,289,023 as prior art (patent citation, not litigation).
   • "6,616,397" / "064号专利" verdicts in Orange v. Autel — unrelated patents.

Caveats / limitations

• I could not authenticate into the subscription litigation databases (Docket Navigator, LexisNexis Reed Tech, Westlaw Litigation Analytics) that would give a fully exhaustive assertion history; my searches relied on publicly indexed sources.
• I therefore state the result with appropriate confidence rather than certainty: based on the publicly available and searchable records, no infringement suit, ITC Section 337 investigation, or PTAB validity challenge (IPR/PGR/CBM) involving US 6,289,023 has been identified. Any litigation that may have occurred in a district court with poor online docket indexing could escape this search.
• Note the patent expired 2017-09-25, which is consistent with the absence of contemporary assertion activity — it would be an unusual candidate for PAE assertion given its age and expiration.

Recommended verification steps (if you need a litigation-grade conclusion)

1. Run the patent number in Docket Navigator (patent → "patents in suit" field) and in Lex Machina.
2. Run it in RPX Insight under the "Litigation" tab / "Patents in Suit."
3. Confirm via PACER and the CAFC docket search, and check Unified Patents Portal case lists by patent number.
4. Check HP's own enforcement history and any ITC Section 337 complaints naming HP as complainant.

If you would like, I can draft a short case-status memorandum documenting the negative search and the sources consulted, suitable for a freedom-to-operate or due-diligence file.

I'll start by verifying the canonical source (the ODP block states no AIA proceedings) against public records.

The first pass surfaced nothing relevant. Let me run more targeted queries on the patent number and known litigation patterns.

No PTAB hits so far. Let me check for any assertion/litigation history and confirm on CourtListener and uspto.report.

Proceedings overview

Total AIA trial proceedings on file: zero. The USPTO Open Data Portal returns no AIA trial proceedings for US 6,289,023, and my independent web searches across multiple query formulations (patent number in both 6289023 and 6,289,023 formats, title, inventor names, assignee, PTAB E2E, and CourtListener) surfaced no IPR, PGR, CBM, or Federal Circuit appeal involving this patent. There is therefore no breakdown by status to report — no active proceedings, no invalidated claims, no sustained claims, no settlements, no institution denials. Defensive posture: the patent's claims are entirely untested at the PTAB, which cuts both ways. Nothing has been canceled, so you cannot knock out an assertion by pointing to a prior FWD — but equally, the patent owner has never had to defend these claims against a skilled challenger, and the art cited on the face of the patent during prosecution (see below) was never tested in an adversarial AIA proceeding. Note also that the patent's 20-year term expired 2017-09-25 (Google Patents status: "Expired - Fee Related"; "Anticipated expiration" 2017-09-25), which materially limits the practical value of filing a new IPR today. Full text: https://patents.google.com/patent/US6289023/en

Proceedings by case

None. No proceeding sections are provided because no AIA trial proceeding exists for this patent. I will not manufacture proceeding numbers, panels, or dispositions.

What I checked, and what came back empty:

Caveat on the negative: a "no results" web search is not the same as a certified docket check. It is possible that a proceeding exists that is not well-indexed by general search engines, and it is possible someone filed a petition very recently that neither the ODP ingest nor search has picked up. Treat this as a high-confidence negative, not an absolute one. The cheapest way to make it absolute is a direct PTAB E2E / Patent Center party-name and patent-number query (see Recommended next steps).

Strategic summary

Claim status: 19 claims, all UNTESTED. US 6,289,023 issued 2001-09-11 with 19 claims. No claim has been canceled, confirmed, or even instituted for trial by the PTAB. Claims 1–3 (method of receiving data with a code calculated "as the packet bytes are transferred from network media to memory" and transferred to "a code channel") and claims 10–19 (the network-node apparatus counterpart reciting an "algorithm execution unit" and a "code channel") stand as issued, unpoliced by any AIA proceeding. The dependent claims — e.g., claim 4's counting/beginning-byte-position limitation, claim 13's ending-byte-position termination, and claim 19's registration with beginning and ending byte positions — have never been construed by the Board.

Estoppel landscape: there is none. Because no petitioner has ever instituted an IPR on this patent, § 315(e)(2) estoppel is a blank sheet. Every prior-art ground is available to a defendant today. No party is barred, and no petitioner's privies are barred, from raising § 102 or § 103 challenges based on patents or printed publications — whether at the PTAB (subject to the § 315(b) one-year bar running from service of a complaint on you) or in district court. The prior art already on the face of the patent, which the examiner considered but no adversarial body has tested, includes:

• Snyder et al., U.S. 5,522,039 ("Calculation of Network Data Check Sums by Dedicated Hardware With Software Corrections"), cited at column 2 of the specification as generating a "gross checksum" over an entire packet during a DMA transfer, with higher layers subtracting a locally computed checksum to form a "net checksum." This is the closest cited reference and the most obvious § 103 starting point — the patent itself distinguishes Snyder only on the timing of the subtraction, and the applicant's own specification concedes Snyder "incurs a smaller time penalty than other prior art methods."
• EP 0572146 A2 (Hewlett-Packard) and U.S. 5,500,864 (Honeywell), both cited on the face of the patent; the EP counterpart's prosecution history shows the European examiner distinguished these on the ground that they were "silent about the provision of a code channel associated with a protocol stack." That is a candid statement of the claimed point of novelty and, correspondingly, the narrowest point to attack.
• U.S. 5,430,842 and U.S. 5,491,802 (both Hewlett-Packard, cited in the citations list) on adapter-side checksum insertion.

Pattern signals: none to report. No repeat petitioner, no defensive aggregator (no Unified Patents or RPX-sponsored filing), no patent-owner appeal activity. The "Cited By" list on Google Patents is long (100+ entries), but those are later patents citing this patent as background — not IPRs against it. Note that the cited-by list does include many Alacritech/IPR2022-00211-type proceedings, but those involve other patents (e.g., Alacritech's TCP offload family, Broadcom TCP offload, Juniper header processing); none of them challenge US 6,289,023. Do not let a search engine's adjacency mislead you into citing them as this patent's PTAB history — they are not.

Practical read: This is a 1997-priority Hewlett-Packard (now Hewlett Packard Development Company, L.P.) patent covering hardware checksum offload with a "checksum channel" that carries the code up the protocol stack alongside the data. It expired in 2017. Its absence from PTAB dockets is unsurprising — the technology (NIC receive-side checksum offload) became ubiquitous and standardized in the years after issuance, so there was little commercial reason for anyone to spend $250K+ invalidating a patent that had already stopped generating royalty revenue. The absence of IPRs is not evidence the patent is strong; it is evidence nobody needed to challenge it.

Recommended next steps

1. Do not represent to a court or opposing counsel that this patent has been invalidated. It has not. Claims 1–19 are all live in the sense that they were never canceled, though the 2017-09-25 expiration sharply limits any damages window and any prospective injunction theory. Any demand letter asserting this patent should be met with a § 102/§ 103 invalidity defense and an exhaustion/laches analysis focused on the pre-2017 damages period, not with a qui tam-style "the PTAB already killed it" argument, which would be refuted instantly.

2. Confirm the negative with a direct PTAB E2E query before relying on it in a pleading: search Patent Trial and Appeal Board E2E (https://e2e.uspto.gov/) by patent number 6,289,023 and by party name for Hewlett-Packard / Hewlett Packard Development Company / HP Inc. Also pull the full file wrapper via USPTO Patent Center (https://patentcenter.uspto.gov/) to confirm whether any ex parte or inter partes reexamination was ever requested — reexaminations are not AIA trials and would not appear in an AIA-proceedings dataset, and the ODP "PTAB proceedings" default would not capture them. This is the single most likely place a hidden challenge would live, given the patent's age and the prevalence of reexam filings against HP networking patents in the 2000s.

3. If you receive a demand letter on this patent, the filing window matters. Your § 315(b) one-year clock runs from service of a complaint alleging infringement, not from the demand letter. But filing an IPR against a patent that expired in 2017 has limited utility: the Board will still institute on a timely petition (there is no rule barring IPR of an expired patent), but the practical payoff is only avoiding past damages. Weigh the IPR against a straightforward district-court invalidity case built on Snyder '039 + the applicant's own admissions, which carries no § 315 estoppel risk and lets you put the commercial-success and secondary-considerations evidence in front of a jury.

4. Quotable for a demand-letter response: No IPR, PGR, or CBM has ever been instituted against US 6,289,023; there is no Final Written Decision to link; and no Federal Circuit appeal exists. The only public adversarial record is the European counterpart, EP 0905938 B1 (granted 2004-12-22, national DE69828233T2), where the claimed point of novelty was identified as the "code channel associated with a protocol stack" — a useful roadmap for the narrow claim-construction fight you are likely to face on claims 10–19.

I'll research the assignment record for US 6289023 before assembling the report.

Let me try to pin down reel/frame and correspondent details from assignment-record mirrors.

US 6289023 — Assignment Record Reconstruction

Data note (read first): This patent has recorded events, but neither the Google Patents legal-events table (my authoritative text for this patent) nor the USPTО assignment mirrors I could reach (uspto.report, assignmentcenter.uspto.gov indexes) returned reel/frame numbers or the correspondent of record for US 6289023's own recordings. I was unable to retrieve those two data-points and will not fabricate them. The timeline below is built from the recorded legal events in the Google Patents record (https://patents.google.com/patent/US6289023/en, fetched 2026-09-24); each entry is dated, but the corresponding reel/frame is marked "not retrieved." Where I cite reel/frame numbers at all below, they are from other patents' filings and are flagged as such — they are context, not records for this patent.

Inventors

• All three inventors executed an assignment of interest to Hewlett-Packard Company, recorded 1998-02-23 (Google Patents legal events: "ASSIGNMENT OF ASSIGNORS INTEREST… Assignors: DOWLING, BRIAN M.; WARLING, CHRISTIAN J.; WENDT, JAMES G."). That contemporaneous conveyance is the basis for stating HP as their employer at filing.
• Unusual-pattern check: no evidence that any inventor left HP within 12 months of filing, and no inventor-initiated reversion or later individual assignment is recorded. Nothing in the record supports an inventor-departure / portfolio-fire-sale precursor. (Determination is limited: individual employment history is not obtainable from the assignment record.)

Original assignee

Hewlett-Packard Company (Palo Alto, CA) is the entity named on the issued patent as original assignee; the patent's bibliographic data lists original assignee "Hewlett-Packard Co" and current assignee "Hewlett Packard Development Co LP."

• Line of business: HP was a diversified computing/printing hardware company. This patent is squarely in its networking-silicon and network-peripheral business: the specification explicitly frames the invention around "Hewlett-Packard's line of JetDirect network adapters," which receive data from a network, run it through a protocol stack, and forward stripped data to a printer, and describes implementing the checksum in the LAN-controller ASIC (transceiver, MAC, byte buffer, DMA, fly-by checksum unit).
• Product embodiment: Plausible-to-likely. The claims cover a network adapter / LAN-controller method and apparatus for generating a "fly-by" checksum as bytes are DMA'd from network media to memory (claims 1–19). HP's JetDirect adapters and its in-house Ethernet LAN-controller ASICs are the natural commercial embodiment, and the spec names JetDirect directly. I cannot verify a specific SKU that practices every claim.
• Current status: Not operating under this name. Hewlett-Packard Company ceased to exist as such; the corporate family split in November 2015 into HP Inc. and Hewlett Packard Enterprise. The patent's title sits with the IP-holding entity Hewlett-Packard Development Company, L.P. (per the 2011-09-22 recorded assignment and the Google Patents "current assignee" field). Note a data discrepancy: uspto.report/patent/grant/6289023 still lists the current assignee as "Hewlett-Packard Company," which appears to be stale relative to the 2011 recording.
• Patent status: Expired – Fee Related, anticipated expiration 2017-09-25. As of today (2026-09-30) the patent is expired and unenforceable.

Assignment timeline

All entries are from the Google Patents legal-events record for US 6289023. No reel/frame numbers or correspondents could be retrieved for any of these entries (see data note). Execution dates are not exposed by the legal-events table; the dates below are the recorded dates.

• executed n/a / recorded 1998-02-23 — Reel not retrieved

  • Conveyance: Assignment of assignors' interest
  • Assignor: Brian M. Dowling; Christian J. Warling; James G. Wendt
  • Assignee: Hewlett-Packard Company
  • Correspondent: not retrieved. (Contextual only — in unrelated HP chain-of-title filings, HP's recorded IP correspondence is handled internally by "Hewlett-Packard Company, Intellectual Property Administration, 3404 E. Harmony Road, Mail Stop 35, Fort Collins, CO 80528," Customer No. 22879, e.g. by Catherine M. Voisinet, Senior Patent Counsel, in a 2011 filing for US 5,978,951. That is not a confirmed record for US 6289023.)
  • Context: Original inventor-to-employer assignment.

• executed n/a / recorded 2001-01-16 — Reel not retrieved

  • Conveyance: Merger (per the legal-events description)
  • Assignor: Hewlett-Packard Company
  • Assignee: Hewlett-Packard Company
  • Correspondent: not retrieved
  • Context: Internal corporate reorganization — an intra-HP merger whose effect is recorded as vesting the asset back in the surviving Hewlett-Packard Company entity; no change in ultimate ownership.

• executed n/a / recorded 2011-09-22 — Reel not retrieved

  • Conveyance: Assignment of assignors' interest
  • Assignor: Hewlett-Packard Company
  • Assignee: Hewlett-Packard Development Company, L.P.
  • Correspondent: not retrieved
  • Context: Internal reorganization / transfer to HP's IP-holding subsidiary; the asset moves from the operating parent into the family IP entity. (This 2011 pattern is consistent with HP's broader 2011 IP-consolidation recordings; I did not confirm a companion recording number for this patent.)

• 2017-09-25 — not an assignment: anticipated expiration recorded; status "Expired – Fee Related."

Stop condition check: the Assignment Center is not empty for this patent — three recordings exist — so the "no records" shortcut does not apply. However, all three are intra-HP events: inventors→HP, an HP-internal merger, and HP→HP's IP subsidiary. There is no arm's-length or third-party transfer of this patent.

Timeline diagram

timeline
    title Ownership of US 6289023
    1997 : Filed by Hewlett-Packard Company
    1998 : Inventors assign rights to HP
    2001 : Recorded as merged within HP
    2011 : Assigned to HP Development Company LP
    2017 : Patent expired

NPE / troll-pattern signals

1. Shell-entity transfer — Not present. The only non-inventor assignee is Hewlett-Packard Development Company, L.P. (2011-09-22 recording). HPDC LP is HP's long-standing corporate IP-holding subsidiary, not a licensing-only shell with a registered-agent address; there is no single-purpose Delaware/Texas LLC and no known-products-free licensing vehicle in the chain.

2. Known asserter in the chain — Not present. No assignee in any recorded link (HP Company, HP Company, HP Development Company LP) matches any entity on the Acacia / Marathon / IV / IPNav / Wi-LAN / Converso / Vringo / Pendrell / Innovatio / Round Rock / Spangenberg lists, and no Unified Patents or RPX high-frequency plaintiff appears.

3. Repeat correspondent across the chain — Unclear / not determinable. This is the signal I most wanted to test, and it is the one the accessible sources defeat: none of the three recordings for this patent exposed a correspondent of record to me. I therefore cannot state that a correspondent recurs, and I will not infer one. The only corroborated HP IP-correspondence data point I found (HP Intellectual Property Administration, Fort Collins CO; Catherine M. Voisinet) comes from an unrelated HP patent's filing and, per the rules, a single such appearance is not a finding.

4. Cascading transfers — Not present. The three recordings span 13 years (1998 → 2001 → 2011), with no sub-24-month chained-LLC sequence, and all assignees are the same corporate family / its subsidiary — the opposite of a rapid shell cascade.

5. Pre-litigation transfer — Not present. No infringement suit naming US 6289023 was surfaced in any search, so there is no litigation date against which a 6-month lookback could attach. The last transfer (2011) predates expiration (2017) by six years with no assertion in between.

6. Bankruptcy fire-sale — Not present. No Chapter 7/11 proceeding involving an assignor or assignee of this patent was found, and no sale-of-portfolio recording exists.

7. Privateering — Not present. The patent never left HP's corporate family; there is no operating-company-to-NPE transfer and no SEC/EFF/Patent Progress coverage of HP using an NPE proxy on this patent.

8. Defensive aggregator (anti-NPE) — Not present. The chain does not terminate at RPX, AST, LOT, Unified Patents, or OIN. It terminates at an operating company's IP subsidiary, and then at expiration.

Cross-reference results: Google Patents family = EP0905938B1 (granted 2004-12-22), DE69828233T2, JPH11168451A — all HP-owned, all expired/expired-lifetime. No publicly tracked infringement assertion of US 6289023 was located (no RPX/Unified/asserter-directory hit). SEC filing search returned no HP 10-K/8-K tying this specific patent to an assertion or transfer event; the 2015 HP Inc. / HPE split is general corporate knowledge but I did not retrieve a filing that individually lists this patent as reallocated between the successor entities.

Verdict

Insufficient data — no NPE classification is supported.

Justification: the record for US 6289023 consists of the 1998-02-23 inventor→Hewlett-Packard original assignment, a 2001-01-16 HP-internal merger recording, and a 2011-09-22 HP→Hewlett-Packard Development Company, L.P. subsidiary recording — i.e., only intra-family HP events, with no third-party or NPE transfer at any point, and no litigation. I could not retrieve the reel/frame numbers or correspondent of record for any recording, so even the repeat-correspondent tell (signal 3) is untestable here, and I decline to infer it. The patent expired 2017-09-25 and is unenforceable. On the available evidence this is a non-NPE, non-asserted operating-company asset chain, but because the defining NPE evidence (post-issuance arm's-length transfers, reel/frame, correspondent) is absent or unobtainable, "Insufficient data" is the honest classification rather than a positive finding of any specific pattern.

Verify independently at the USPTO Assignment Center, search by patent number 6289023: https://assignmentcenter.uspto.gov/ (mirror: https://assignment.uspto.gov/patent/index.html) — this is where the reel/frame and correspondent fields I could not capture should appear.

I'll research this systematically. Let me start by verifying the patent and its cited prior art via search.

Good. Now let me research the remaining cited references in parallel.

Prior-Art Analysis — US 6,289,023 B1

"Hardware checksum assist for network protocol stacks"

1. Verification of the patent (searched, not auto-corrected)

Source: https://patents.google.com/patent/US6289023/en ; https://uspto.report/patent/grant/6289023

2. Important framing note on "anticipation" (§ 102)

The ten references below are the examiner-cited prior-art references appearing in the "Patent Citations" list of US 6,289,023. Because the patent issued with all 19 claims intact, none of these references was found by the examiner to fully anticipate a claim under 35 U.S.C. § 102 (i.e., none discloses every element of any one claim as arranged). Accordingly, the mappings below identify the claims each reference is most relevant to and could arguably implicate, together with the element each is missing. Treat these as § 102 candidates (and, more realistically, § 103 obviousness art), not as established anticipations.

The single most distinguishing limitation across the record is the "code/checksum channel associated with the protocol stack" — a data structure that carries the hardware-generated code up the stack alongside the packet data so that any layer can read it. The European counterpart's prosecution expressly stated this:

"EP-A-0 572 146 and US-A-5 500 864 basically describe the generation of a checksum but are silent about the provision of a code channel associated with a protocol stack."
— EP0905938B1, [0013] (https://patentimages.storage.googleapis.com/83/9b/ce/45b80163dd8c1d/EP0905938B1.pdf)

That limitation appears in independent claims 1, 4, 7, and 10 (all recite transferring the code to "a code channel associated with the protocol stack"). None of the ten references below discloses it.

3. Reference-by-reference analysis

3.1 US 5,500,864 A — Honeywell Inc.

• Full citation: Gonia, P.S. & Hoff, J.F., "Checksum calculation unit and method for error detection on data packets," U.S. Patent 5,500,864, assignee Honeywell Inc.
• Dates: Appl. No. 076827 filed June 14, 1993; continuation of Ser. No. 07/574,822 filed Aug. 29, 1990 (priority 1990-08-29); issued March 19, 1996.
• Description: High-performance hardware transport-layer checksum unit that calculates a checksum simultaneously with DMA data movement (single scan of memory). Uses three partial adders; supports delayed checksumming and buffer-chaining of discontinuous blocks. Checksum-compliant with ISO IS/8073 (Fletcher).
• Claim mapping (§ 102 candidates): Most relevant to independent apparatus claim 10 and to the "calculating a code … as the packet bytes are transferred from network media to memory" step of claims 1 and 4. Its DMA-concurrent hardware checksum accumulation corresponds to the "algorithm execution unit … as the bytes are transferred" element and the "memory access unit coupled between the transceiver and the memory unit."
• Missing element / why it did not anticipate: No code channel associated with the protocol stack; no transfer of the code up the stack alongside the data; the checksum is inserted into the packet itself. Also no transceiver→DMA→adapter-memory receive path with a registered algorithm per protocol layer.

3.2 EP 0 572 146 A2 — Hewlett-Packard Company

• Full citation: Thompson, M.I.; Congdon, P.T.; Burnett, J.L.; Fiduccia, F., "Insertion of network data check sums by a network adapter," European Patent Application EP 0 572 146 A2 (granted as EP0572146B1, published 2000-08-16).
• Dates: Filed 14.05.1993; priority 29.05.1992 (US 891505); published 01.12.1993 (A3 search report 25.01.1995).
• Description: Network adapter generates/inserts checksums for packets. A processor builds the packet in main memory; during DMA transfer to adapter packet-storage memory, hardware "snoops" the adapter's internal bus and computes the checksum on the fly, then inserts it into the packet. A checksum header prepended to the packet carries control information (whether to checksum, what data to checksum, where to insert the result).
• Claim mapping: Most relevant to claims 1, 4, 7 (on-the-fly code calculation during transfer) and to the "registering a checksum algorithm" notion of claims 7–9 via its prepended checksum control information. The control field specifying "what data … is to be checksummed" is the closest prior art to the beginning/ending byte-position concept of claims 8/19.
• Missing element: The checksum control information is prepended inbound on the outbound transmit path; there is no receive-side code channel propagating a code up a protocol stack to a layer for verification. Distinguished on that basis during EP prosecution.
• Note (family link): This is the same HP patent family as cited US 5,430,842 / US 5,491,802 (below).

3.3 US 5,430,842 A — Hewlett-Packard Company

• Full citation: Thompson, M.I.; Congdon, P.T.; Burnett, J.L.; Fiduccia, F. (heirs), "Insertion of network data checksums by a network adapter," U.S. Patent 5,430,842, assignee Hewlett-Packard Company.
• Dates: Appl. No. 07/891,505 filed May 29, 1992; issued July 4, 1995.
• Description: U.S. counterpart of EP0572146. Processor constructs packet in main memory; adapter computes checksum during DMA transfer and inserts it into the packet in adapter storage memory. Checksum configuration information (whether to checksum, what data to checksum, insertion location) is prepended or supplied by the processor.
• Claim mapping: Same as 3.2 — most relevant to claims 1 and 4 (hardware code generation concurrent with transfer) and the registration concept of claims 7–9. Cited by examiner.
• Missing element: No code channel; checksum handled on the transmit/insertion path, not propagated up a receiving protocol stack for layer-level verification.

3.4 US 5,491,802 A — Hewlett-Packard Company

• Full citation: Congdon, P.T. et al., "Network adapter for inserting pad bytes into packet link headers based on destination service access point fields for efficient memory transfer," U.S. Patent 5,491,802, assignee Hewlett-Packard Company.
• Dates: Appl. No. 07/891,302 filed May 29, 1992; issued February 13, 1996.
• Description: Adapter inspects the DSAP field of the network link header on the fly and inserts 0–3 pad bytes to 4-byte-align subsequent headers (e.g., IP/TCP/UDP) as bytes stream into an adapter buffer. Related family member EP0572145B1 ("Network adapter for headers alignment").
• Claim mapping: Weakest of the set as to the checksum claims; most relevant to the byte-position / header-identification concepts supporting claims 4, 5, and 8 (identifying where a header starts in a byte stream as it is received). It demonstrates on-the-fly header parsing by adapter hardware.
• Missing element: It concerns alignment/padding, not checksum/code generation, code channel, or layer verification. It cannot anticipate any of claims 1–19 on its own.

3.5 US 5,522,039 A — Hewlett-Packard Company (Snyder et al.)

• Full citation: Snyder, R.D.; Zimmer, P.R.; Thompson, M.I.; Congdon, P.T.; Bridges, K.M. III, "Calculation of network data check sums by dedicated hardware with software corrections," U.S. Patent 5,522,039, assignee Hewlett-Packard Company.
• Dates: Appl. No. 118,959 filed September 9, 1993; issued May 28, 1996.
• Description: Adapter accumulates a "gross checksum" of all data during DMA into host memory (dedicated data-path hardware, no CPU intervention). Software later computes a small header checksum and subtracts it from the gross checksum to yield the "net checksum" for the user-data portion.
• Claim mapping: This is the most important reference and the closest prior art. It is expressly discussed in the patent's Background (col. 1) and is directed at the same problem (offloading protocol-layer checksums to adapter hardware during DMA). It is most relevant to claims 1, 4, 7 and 10.
• Missing element: It generates a single gross checksum over the whole packet and requires software post-correction per layer — it does not (a) calculate in parallel a code for each registered algorithm (claims 7, 9, 18, 19), (b) provide beginning/ending byte registers defining the checksummed portion (claims 5, 8, 13, 14, 19), or (c) deliver the code via a code channel up the protocol stack to the registering layer for verification (claims 1, 4, 7, 10). This is the primary reference an obviousness rejection would combine with the byte-register art.

3.6 US 5,583,859 A — Bell Communications Research, Inc.

• Full citation: "Data labeling technique for high performance protocol processing," U.S. Patent 5,583,859, assignee Bell Communications Research, Inc.
• Dates: Filed August 30, 1994; issued December 10, 1996.
• Description: A technique for labeling data as it is processed through a protocol stack to improve high-performance protocol processing (associating metadata/tags with packet data moving up the layers).
• Claim mapping: Most relevant to the "code channel associated with the protocol stack" element of claims 1, 4, 7, and 10 — it is believed to be cited for its labeling/association of auxiliary information with data traversing a stack.
• Missing element / caveat: I do not have the full text of this reference in the retrieved record; based on the title and citation context it concerns labeling, not hardware checksum/code generation. It cannot alone anticipate any claim (it lacks the transceiver→DMA→adapter-memory hardware code-generation elements). Flagged as lower-confidence because the full specification was not retrieved.

3.7 EP 0 725 346 A1 — Tandem Computers Incorporated

• Full citation: "Apparatus and method for efficient modularity in a parallel, fault tolerant, message based operating system," European Patent Application EP 0 725 346 A1, applicant Tandem Computers Incorporated.
• Dates: Filed January 23, 1995; published August 7, 1996.
• Description: Modularity architecture for a parallel, fault-tolerant, message-based operating system (message-passing between layered modules).
• Claim mapping: Peripheral. Possibly cited as general background for passing auxiliary information/modules alongside data — conceptually adjacent to, but not disclosing, the code-channel element of claims 1/4/7/10.
• Missing element: No network-adapter hardware checksum generation, no byte-register-limited code accumulation, no layer-level verification using a propagated code. Does not anticipate any claim.

3.8 WO 96/41424 A1 — Micron Technology, Inc.

• Full citation: "High speed cyclical redundancy check system using a programmable architecture," PCT publication WO 1996/041424 A1, applicant Micron Technology, Inc.
• Dates: Filed June 7, 1995; published December 19, 1996.
• Description: A programmable high-speed CRC/checksum engine architecture (programmable polynomial/algorithm).
• Claim mapping: Most relevant to the programmable/registered algorithm aspects of claims 7–9 and 18–19 ("registering a checksum algorithm"; "calculates a code for each registered algorithm") and to the programmable checksum algorithm unit 84 described in the specification (FIG. 4).
• Missing element: It is a CRC engine per se. It does not disclose the network-adapter receive path, DMA-to-adapter-memory transfer, a code channel up a protocol stack, or layer-level verification. Does not anticipate any claim.

3.9 US 5,815,516 A — International Business Machines Corporation

• Full citation: "Method and apparatus for producing transmission control protocol checksums using internet protocol fragmentation," U.S. Patent 5,815,516, assignee International Business Machines Corporation.
• Dates: Filed April 5, 1996; issued September 29, 1998.
• Description: Producing TCP checksums in the context of IP fragmentation (handling checksum computation across fragmented packets).
• Claim mapping: Most relevant to claim 3 ("protocol stack is a TCP/IP stack") and generally to the TCP/IP checksum context of claims 1, 2, 16, 17.
• Missing element: Concerns software/host-side checksum production for fragmented TCP segments; does not disclose hardware code generation during network-media-to-memory transfer, nor a code channel. Does not anticipate any claim.

3.10 US 5,805,818 A — Novell, Inc.

• Full citation: "System for acknowledging availability of neighbor node using data packet containing data that is ordinarily forwarded to neighbor node," U.S. Patent 5,805,818, assignee Novell, Inc.
• Dates: Filed September 11, 1996; issued September 8, 1998.
• Description: Acknowledging neighbor-node availability via a data packet containing data ordinarily forwarded to the neighbor node (protocol/node-availability messaging).
• Claim mapping: Weakest relevance. Cited by the examiner as general network-protocol-stack art; touches on packets being processed/forwarded through protocol layers.
• Missing element: No checksum/code generation, no code channel, no layer-level verification. Does not anticipate any of claims 1–19.

4. Summary and ranking

Bottom line: All ten references pre-date the 1997-09-25 priority date and qualify as prior art (§ 102(a)/(b)/(e)). On the record, none anticipates any claim of US 6,289,023 as issued. The prior art collectively teaches (i) hardware checksums computed during DMA (US 5,500,864; US 5,522,039; EP 0 572 146 / US 5,430,842), (ii) programmable/registered CRC engines (WO 96/41424), and (iii) on-the-fly header parsing/positioning (US 5,491,802). What it does not teach is the "code channel associated with the protocol stack" that carries a per-registered-algorithm hardware code up the stack alongside the packet data so that the registering layer can verify the extracted data — the acknowledged point of novelty (EP0905938B1, [0013]) and the limitation recited in each independent claim 1, 4, 7, and 10.

Caveats

• Full text was retrieved for US 5,500,864, EP 0 572 146, US 5,430,842, US 5,491,802, and US 5,522,039. For US 5,583,859, EP 0 725 346 A1, WO 96/41424 A1, US 5,815,516, and US 5,805,818 I relied on the citation record and titles (the search budget was exhausted before full texts could be pulled); the mappings for those five are therefore lower-confidence and should be confirmed against the full specifications before being used in a validity opinion.
• "Cited By," "Similar Documents," and family-member lists were not treated as prior art, since they post-date or merely parallel US 6,289,023.

I'll ground this analysis in the actual prior-art references cited on the patent page. Let me verify the key references.

Let me verify the remaining cited references.

Obviousness Analysis — U.S. Patent 6,289,023 B1

"Hardware checksum assist for network protocol stacks"
Inventors: Dowling, Warling, Wendt · Assignee: Hewlett-Packard (orig.), HP Development Co. LP (current)
App. No. 08/937,912 · Filed 1997‑09‑25 · Granted 2001‑09‑11 · Expired – Fee Related (anticipated expiration 2017‑09‑25)
Source: https://patents.google.com/patent/[US6289023](/patent/US6289023)/en

1. Analytical framework and the inventive core

The patent expired 2017‑09‑25, so §103 is being assessed against the pre‑AIA statute (35 U.S.C. §103(a), as amended by KSR v. Teleflex, 550 U.S. 398 (2007)). All references from the page's Patent Citations table pre‑date the 1997‑09‑25 priority date and are therefore available under §102(a)/(b)/(e).

Reading the claims against the specification, the inventive core is narrow. Every independent claim (1, 4, 7, 10) reduces to:

1. A checksum/code is accumulated in network hardware during the DMA transfer of the packet from media into memory ("as the packet bytes are transferred from network media to memory") — i.e., a "fly‑by" checksum;
2. The accumulation is computed over a sub‑portion of the packet defined by beginning/ending byte positions registered ahead of time (claims 4, 5, 7, 8, 11–14, 19);
3. The code is placed on a "code channel" / checksum channel that travels up the protocol stack alongside the packet data (claims 1, 4, 7, 10);
4. A higher layer reads the code off the channel and verifies the extracted data (all independent claims).

The specification itself concedes the center of gravity of the invention to the art: the Background expressly discusses Snyder et al., U.S. 5,522,039 and characterizes its "gross checksum / net checksum" scheme as a known hardware-checksumming approach. That concession is significant — it frames step (1) as admitted prior art and leaves only the portion‑defined‑by‑registered‑byte‑offsets and channel-propagation features as the point of novelty.

2. Prior‑art inventory (all from the page's Patent Citations table)

Not usable as §102/§103 art: the large Cited By list (Alacritech, Broadcom, Juniper, Mellanox, etc.). Alacritech's earliest listed priority is 1997‑10‑14 — 19 days after '023's 1997‑09‑25 priority date — and the rest post‑date it by years. They are useful only as evidence of the ordinary skill level and of the commercial trajectory of the field (TCP offload), not as anticipating art.

3. Primary obviousness combination

Combination A — Snyder (US 5,522,039) + HP (US 5,430,842 / EP 0 572 146) + Bellcore (US 5,583,859), optionally + Micron (WO 96/41424)

Element‑by‑element mapping (independent claims 1, 4, 7, 10):

Motivation to combine (KSR‑sufficient)

1. Snyder itself supplies the motivation to modify. '023's Background criticizes Snyder precisely because the upper layer must compute and subtract a header checksum in software before it can use the gross checksum. HP '842/'146 already teaches eliminating that software correction by having the adapter checksum only a host‑specified byte range ("a specification of what data in the network packet is to be checksummed"). A POSITA seeking to remove Snyder's residual CPU overhead would look directly at HP's adapter‑side range‑specification mechanism — same field, same problem (offloading checksum work from the host CPU), same hardware locus (the LAN adapter ASIC).
2. All three primary references are HP's own or closely analogous adapter‑side checksumming art, and Snyder is cited on the face of '023. Combining references within the same device family and the same problem space is the paradigm KSR "predictable combination of familiar elements."
3. The "channel" is a labeling/plumbing choice. Once the hardware produces a checksum at the bottom of the stack for a layer the hardware does not otherwise understand (the very problem '023 identifies at col. describing "hardware layer 12 has no knowledge of transport layer 18"), the designer must decide how to deliver it. Bellcore '859 teaches exactly this — attach a descriptive label/chunk header to the data units and carry it up the stack so each layer can self‑select what it needs. IBM '5815516 concretely teaches a lower module handing a collected checksum up to the consuming TCP module. Using a defined data structure, or a pointer, or reserved space in the packet buffer (all three are offered in '023's own specification as interchangeable implementations of the "channel") is routine engineering, not invention.
4. No teaching away. Snyder's software‑correction approach is criticized as slow in '023's own Background; HP '842 and Bellcore '859 point away from software correction toward hardware range‑specification and labeled sideband delivery.
5. Predictable result. '023's own stated benefit is merely incremental throughput (it asserts ~10–20%). A combination that removes a CPU‑side subtraction step and eliminates a second pass over the packet predictably yields exactly that.

Anticipation vs. obviousness

A §102 challenge on Snyder alone fails: Snyder accumulates over the entire packet and requires a software subtraction, and it does not disclose a code traveling on a channel to a registering layer. Conversely, HP '842/'146 alone discloses adapter‑side range‑limited checksumming during DMA, but its checksum is inserted into the outbound packet or appended to the inbound packet — not propagated as a separate code up the stack. So the correct posture is §103, with the primary combination above.

4. Secondary / alternative combinations

• Combination B — HP (US 5,430,842 / EP 0 572 146) + Bellcore (US 5,583,859). Cleanest two‑reference case for claims 1, 4 (if "counting packet bytes" is read as inherent in range specification), 7, 10. HP supplies the fly‑by checksum over a host‑specified byte range; Bellcore supplies the labeled sideband that rides up the stack. Motivation: both target high‑performance protocol processing and the elimination of host data‑touching; Bellcore's stated goal is delivering per‑data‑unit control information through layered protocol entities without re‑scanning.
• Combination C — US 5,500,864 (Honeywell) + Bellcore '859 (+ IBM '5815516). Honeywell supplies simultaneous DMA/checksum, programmable boundaries, and buffer‑chaining of selected blocks; Bellcore supplies the up‑stack label channel. This combination maps claims 11–14 (beginning/ending positions) and 5 neatly.
• Combination D — IBM '5815516 + Snyder '039. IBM supplies the cross‑layer hand‑off of a hardware‑collected checksum (IP → TCP); Snyder supplies doing so during the DMA transfer. This squarely addresses the "code channel" limitation for a TCP/IP stack (claims 3, 17) because IBM's reference is TCP/IP‑specific.

5. Dependent‑claim disposition

None of the dependent claims adds a limitation with an independent inventive contribution; each is either expressly disclosed or a predictable implementation detail.

6. Counter‑considerations a challenger must address

1. The specification's own statement of the problem is the strongest defense. '023 asserts that in prior art stacks "hardware layer 12 has no knowledge of transport layer 18," and that Snyder's scheme "must be provided at each network client." A patentee will argue that none of the cited references registers a checksum algorithm at a lower layer on behalf of a higher layer and returns a channel index to the registering layer — the specification's described handshake ("notifying the TCP layer that the proper checksum will be the first checksum in the checksum channel"). That registration/hand‑off feature is arguably the non‑obvious kernel, and it is the feature least squarely met by the cited art.
2. Secondary considerations (Graham factors). '023 asserts a ~10–20% throughput gain for packet‑heavy nodes (network printers, boot‑over‑network workstations) and backward compatibility with legacy stacks. The throughput gain is likely weak because its nexus is contested: the gain flows from hardware DMA checksumming, which Snyder and HP '842 already taught, not from the channel/registration feature standing alone. Backward compatibility is also arguably a design constraint inherent in any incremental adapter change, and no claim recites it. No evidence of industry praise, copying, or failed attempts by others is present on the page. No strong objective indicia appear available.
3. Priority‑date discipline. Any attempt to use the Cited By corpus (Alacritech, Broadcom, Juniper, Mellanox) must fail: Alacritech's earliest listed date, 1997‑10‑14, is after '023's 1997‑09‑25 priority date, and every other cited‑by document is years later. Only the ten Patent Citations references may be used.
4. Claim‑construction caution. Claim 1 does not recite a "registered algorithm" or byte positions, so it is the broadest and most exposed claim; claims 7/10 (with registration) and 4 (with beginning‑byte accumulation) are progressively narrower. A validity challenge should target claim 1 first via Combination A or B.

7. Bottom line

• Claim 1 (and its dependents 2, 3, 6, 15, 16, 17) is reasonably likely obvious over Snyder US 5,522,039 + HP US 5,430,842 / EP 0 572 146 + Bellcore US 5,583,859, with the "code channel" met by Bellcore's up‑stack labeling (or, alternatively, by IBM US 5,815,516's cross‑layer checksum hand‑off). Motivation is supplied by Snyder's own admitted deficiency (software correction) and HP's existing adapter‑side range specification.
• Claim 4 (and 5, 8, 19 and the register claims 11–14) is likely obvious over US 5,500,864 + HP US 5,430,842 + Bellcore US 5,583,859, since Honeywell provides simultaneous DMA/checksum with defined packet boundaries and buffer chaining.
• Claim 7/10 are the most defensible, because the "registering a checksum algorithm" and "code channel" combination is not squarely disclosed by any single reference; but the combination of HP US 5,430,842 (host‑specified range/control information), Micron WO 96/41424 (programmable checksum architecture) and Bellcore US 5,583,859 (labeled sideband up the stack) supplies every element with an articulated motivation, so these too are vulnerable.
• Overall assessment: more likely than not invalid under §103 as to independent claims 1 and 4 and their dependents; a closer call, but still vulnerable, as to claims 7 and 10 given the registration/hand‑off nuance.

Caveat: this is a technical validity screen, not a legal opinion or a PTAB determination. The strongest residual defense is the specific lower‑layer registration / channel‑index handshake described in the specification, which none of the cited references is shown to disclose verbatim.