US 6888797

I'll search for this specific patent number across USPTO and litigation sources.

Search findings for US Patent No. 6,888,797

Caveat up front

I searched for the exact number "6888797" combined with CAFC / Federal Circuit / 2026 terms. I found no 2026 Federal Circuit docket activity for US 6,888,797, and no evidence the patent has been in appellate litigation of any kind recently. Because I do not have direct, authoritative access to PACER/CAFC docket systems, treat that as "nothing located," not as a verified negative. I also note the identifier collision problem: the string "6888797" appears in unrelated contexts (e.g., JP Patent No. 6888797, a FINRA CRD number 6888797, Dutch Staatsblad document number 6888797, and a Westlaw citation number 6888797). None of those are this patent, and I did not merge them into the results below.

Bibliographic data (from the authoritative full text)

Assignment history of record: Lucent Technologies Inc. → Alcatel-Lucent USA Inc. (with a Credit Suisse AG security interest in 2013, released 2014); Google Patents lists the current assignee as Nokia of America Corp (consistent with the Alcatel-Lucent → Nokia lineage).

Litigation (per Google Patents' Unified Patents/Darts-ip links): two 2014 US district court cases in the District of Delaware — case 1:14-cv-00574 and case 1:14-cv-00628. These are the only litigation entries shown. Since the patent expired 2020-03-25, any 2026 appellate activity would be unusual and, again, none was found.

Abstract (verbatim)

"A hashing-based router and method for network load balancing includes calculating a hash value from header data of incoming data packets and routing incoming packets based on the calculated hash values to permissible output links in desired loading proportions."

Plain-language overview of the independent claims

The patent has 19 claims; claims 1 and 14 are the independent claims.

Claim 1 — method of traffic splitting (independent, method)

1. Compute a value from the header data of the incoming data, using a hash function of the form x = K modulo M, where x is the value, M is a preselected modulus, and K is related to the header data.
2. Determine an output link in accordance with a predetermined algorithm, based on that value and on network load directions (i.e., the desired load proportions across the candidate links).
3. Couple (route) the incoming data to the selected outgoing link.

Literal-reading note: the claim preamble and step 1 read "calculating the value from entirety of header data" — the antecedent is not properly introduced ("a value" is never recited first), and the phrase "entirety of header data" is grammatically truncated. Per the strict no-auto-correction rule, I am reporting the text literally: claim 1 as issued appears to contain a drafting error, and a court or examiner would have to construe it. Dependent claims 3–9 narrow which header fields are used (destination field plus protocol ID, destination port, source address and/or source port; XOR-combined fields; segmented fields), claim 2 restates that the value comes from "a hash function," and claims 10–13 specify lookup-table or threshold-based selection and static vs. condition-based load directions.

Claim 14 — router (independent, apparatus, in "improvement" form)
A router with input links, a routing element that directs packets to outgoing links, and a controller, the improvement comprising:

• a many-to-few mapping element that (a) obtains a value from data contained in the headers of incoming packets and (b) applies that value to the controller; and
• a controller modified to be responsive to that value and to a desired loading of the outgoing links, and to route incoming packets — among those that may be routed to any of a plurality of output links — in accordance with the value and the desired loading.

Dependent claims 15–19 add: the header data includes destination address combined with at least a portion of one or more of protocol ID / source port / destination address / destination port (claim 15); the many-to-few mapper computes a hash value (claim 16); the controller uses a modulo-based evaluation of the value against output links (claim 17); or against thresholds (claim 18); with thresholds set by desired network loading (claim 19).

In essence: the two independent claims cover (1) a method, and (2) a router, for deterministic hash-based load balancing, where a modulo hash over packet-header fields yields a bucket value that is then mapped to one of several permissible output links according to an operator-specified load distribution. Flow affinity (same header data → same link) is what avoids the packet reordering problem the specification criticizes in round-robin inverse multiplexing schemes.

Uncertainty notes

• I could not independently confirm Nokia of America Corp's current ownership from a USPTO assignment record in these search results; that is Google Patents' listed assignee. The assignment chain I can cite is Lucent → Alcatel-Lucent USA, plus the Nokia corporate lineage generally (Nokia acquired Alcatel-Lucent in 2016, per separate court testimony located in searching).
• No CAFC 2026 docket entry was located for this patent number. I am flagging this as "not found," not as a confirmed absence, since I cannot query PACER/CAFC directly.
• The two 2014 Delaware case numbers come from the Google Patents litigation links (Unified Patents portal URLs); I did not retrieve the underlying complaints or outcomes.

I'll research litigation involving US patent 6888797. Let me start with searches.

Let me look up the specific Delaware cases referenced on the patent page.

Let me search more specifically for the case numbers and parties.

Litigation involving US Patent 6,888,797

I was able to reach the tool limit before fully resolving every party/outcome detail, so I'm going to separate what is firmly grounded from what I could not confirm, rather than fill in gaps.

Confirmed from the patent's own record (Google Patents page for US6888797B1)

The Google Patents record for US6888797B1 contains a "Family has litigation" flag and two litigation links under "US case filed in Delaware District Court," sourced to Unified Patents' litigation data:

The page also flags that the family (Darts‑ip family ID 34525776) has its "First worldwide family litigation filed," linking to https://patents.darts-ip.com/?family=34525776. No foreign counterpart litigation is separately identified in the record.

What I could NOT verify

• The plaintiff and defendant identities for 1:14‑cv‑00574 and 1:14‑cv‑00628. My web searches for those exact docket numbers did not return the case captions (the results surfaced unrelated Delaware matters with similar numbers, e.g., Xpoint Technologies v. Microsoft, 09‑cv‑00628, and In re FIGS shareholder litigation, 1:23‑cv‑00628 — those are different cases and should not be conflated with the '797 patent cases).
• Filing dates, the specific claims asserted, and the outcome/disposition (dismissal, settlement, transfer, etc.) of either case.
• Any CAFC appeal arising from these cases — none surfaced.
• Any PTAB proceedings (IPR/PGR) challenging US6888797 — none surfaced.
• Any cases in other districts or the ITC involving this patent.

Caveats / recommended next steps

I want to be explicit: I do not have high-confidence information on the parties or outcomes for the two Delaware dockets, and I have not auto-corrected or inferred them. To confirm, the authoritative sources would be:

1. PACER / CourtListener RECAP for D. Del. dockets 1:14‑cv‑00574 and 1:14‑cv‑00628 (docket sheet will show caption, filing date, and disposition).
2. Unified Patents portal at the two URLs above (the portal's case pages list plaintiff, defendant, and status).
3. Darts‑ip family 34525776 for the "first worldwide family litigation."

Patent status (for context, from the record)

US6888797B1: priority 1999‑05‑05 (provisional 60/132,574); filed 2000‑03‑25; granted 2005‑05‑03; original assignee Lucent Technologies Inc.; current assignee listed as Nokia of America Corp; maintenance fee (12‑year) recorded 2016‑10‑24; anticipated expiration 2020‑03‑25; legal status Expired – Lifetime. Given that expiry, any 2014 litigation is well in the past, but I cannot state its disposition.

Bottom line: The only litigation I can confirm is the existence of two 2014 Delaware District Court cases, 1:14‑cv‑00574 and 1:14‑cv‑00628, flagged in the patent's own record as involving US6888797. I cannot confirm the parties, filing dates, or outcomes without direct PACER/CourtListener or Unified Patents lookups, and I decline to guess at those details.

I'll verify the canonical "no PTAB activity" default against live sources before writing the analysis.

Proceedings overview

Total AIA trial proceedings on file: 0. The USPTO ODP structured block returns no IPR, PGR, or CBM proceeding for US 6,888,797, and my independent web checks surfaced no petition, institution decision, Final Written Decision, or Federal Circuit appeal directed at this patent — so the breakdown by status is 0 active / 0 claims invalidated / 0 claims sustained / 0 settled / 0 institution denials. The defensive posture this gives a defendant is neutral-to-favorable but for reasons unrelated to PTAB: the patent has never been tested at the Board, and it expired on 2020-03-25 (20 years from the 2000-03-25 filing date), so there is no remaining term to enjoin and any exposure is retrospective only.

Because there are no proceedings to report, I am not going to manufacture the per-proceeding subsections in the template. Below I explain what I checked, what I did find adjacent to the patent, and what it means.

No proceedings — verification trail

• Canonical source (authoritative for this task): USPTO Open Data Portal returns no AIA trial proceedings for US 6,888,797 as of the most recent ingest. Default position = "no PTAB activity on file."
• Web corroboration (2026-09-23): targeted searches for 6888797 combined with IPR, CBM, PGR, petition numbers (IPR2014/IPR2015/IPR2016), and party names (Unified Patents, Nokia, Lucent, Alcatel-Lucent) returned no PTAB docket, petition, or decision for this patent. The only hits bearing the number 6888797 were the Google Patents record itself, a Japanese patent JP 6888797 B2 (NEC — an unrelated coin-counting/register system), and figure/gene-table numbers that coincidentally contain the digit string.
• Google Patents status fields confirm the posture: Expired – Lifetime, anticipated expiration 2020-03-25; original assignee Lucent Technologies Inc.; current assignee listed as Nokia of America Corp; priority 1999-05-05 via provisional 60/132,574.
• No appeal is possible in this posture. With no Final Written Decision, there is nothing for the Federal Circuit to review, so no CAFC docket number or CourtListener opinion exists for this patent.

Adjacent matter worth flagging (NOT a PTAB proceeding)

The Google Patents record carries a "Family has litigation" flag pointing to two District of Delaware civil actions — 1:14-cv-00574 and 1:14-cv-00628, sourced from Unified Patents Litigation Data:

• https://portal.unifiedpatents.com/litigation/Delaware%20District%20Court/case/1%3A14-cv-00574
• https://portal.unifiedpatents.com/litigation/Delaware%20District%20Court/case/1%3A14-cv-00628

These are district court infringement cases, not AIA trials, and I could not confirm the parties, the asserted claims, or the disposition from public search — so I am explicitly not characterizing them. Two points matter for a defendant, though:

1. The timing is diagnostic. A 2014 assertion wave is exactly the fact pattern that historically attracts IPR petitions (the IPR2014/2015 petition cohorts). None were filed against this patent. That is a meaningful negative signal about the patent's value as an assertion target rather than a positive signal about its strength.
2. Unified Patents' appearance here is litigation-data sourcing, not petitioner involvement. Unified's name attaches to the docket because it publishes the litigation dataset; I found no Unified Patents petition against 6,888,797, and I would not read a defensive-aggregator IPR into this record.

The patent's "Cited By" list does include later multipath-hashing filings — e.g., US 2006/0126625 A1 / US 2009/0116488 A1 (Schollmeier, Nokia Siemens Networks, "Method for distributing traffic using hash-codes corresponding to a desired traffic distribution in a packet-oriented network comprising multipath routing") — but citations are not challenges. No petition in this family appears in the record.

Strategic summary

Claim status: entirely UNTESTED. All 19 claims — independent claims 1 and 14 and dependents 2–13 and 15–19 — stand as issued and as never adjudicated. Nothing is canceled, nothing has been confirmed by the Board, and nothing has been narrowed through a certificate of correction or reexamination on this record. The claim set as it exists is the claim set that issued on 2005-05-03: claim 1 reciting the x = K modulo M hash over "entirety of header data," and claim 14 reciting a many-to-few mapping element in a router. The practical caveat is that an untested patent is not a hardened patent — it is simply an unexamined-in-litigation one, and its validity has never been subjected to adversarial art.

Estoppel landscape: empty. Because no IPR, PGR, or CBM was ever instituted, § 315(e)(2) estoppel attaches to no one. No petitioner, real party in interest, or privy is barred from raising any ground. If you are a defendant today, you have the full universe of prior art available — § 102 and § 103 art on any reference, whether or not it was "reasonably could have been raised" in a proceeding that never happened. That is categorically different from the usual post-IPR posture, and it is the single most usable fact on this page. The flip side is that there is also no Board ruling to lean on: no claim construction, no validity finding, no FWD you can hand a district judge.

Pattern signals: none, and the clock ran out. No serial petitioner, no multi-petition campaign, no PTAB appeal history, no defensive aggregator in the chain. The dominant fact is temporal: the patent expired 2020-03-25, more than six years ago. Well-asserted patents eventually attract IPRs — this one did not, and it is now past the point where an IPR would deliver an injunction-avoidance benefit. Note the asymmetry, though: expiration does not make an IPR legally unavailable (the Board has instituted on expired patents, where claims are construed under Phillips and amendment is impossible), but it removes almost all of the economic motive to file one.

Recommended next steps

• If you are a defendant and a demand letter cites US 6,888,797: the first line of defense is the calendar, not the Board. The patent's term expired 2020-03-25 per the Google Patents anticipated-expiration entry. Confirm independently in USPTO Patent Center (https://patents.google.com/patent/[US6888797B1](/patent/US6888797B1)/en links through to USPTO PatentCenter) and establish the operative expiration and any maintenance-fee or terminal-disclaimer history. If the accused conduct postdates 2020-03-25, there is no infringement to litigate; if it predates it, you are in a § 286 six-year damages lookback analysis, which will usually cap or eliminate exposure given the assertion dates.
• There is no FWD to quote. Do not build a defense around a PTAB disposition — none exists. Any argument that "the claims are already invalidated" would be false here, and asserting it would be sanction-bait in the other direction.
• Take the full § 102/§ 103 art set to your invalidity contentions. With zero estoppel, you may use any reference: Lucent's own EP 0 801 473 A, the OSPF-OMP working draft (Villamizer, March 1998) and Thaler's "Multipath Issues in Unicast and Multicast" (January 1997) that the specification itself discusses as the state of the art, plus the prior commercial router hash-on-destination-address practice the spec concedes. Since there is no IPR, there is also no § 315(b) one-year bar concern and no Fintiv-style discretionary-denial risk if you nonetheless want to file one.
• Before concluding "no PTAB activity," re-verify against the authoritative trial registries in case of ingest lag: PTAB E2E / PTAB Center (https://ptacts.uspto.gov/ptab/) and the PTAB API, searching patent number 6888797 directly; and CourtListener RECAP for the two Delaware dockets (1:14-cv-00574, 1:14-cv-00628) to identify the parties and disposition — https://www.courtlistener.com/?q=6888797.
• Bottom line to a client: this is not an IPR-defanged patent. It is an expired, never-challenged patent. Your leverage comes from the expiration date and the empty estoppel docket, not from anyone else's prior win at the Board.

I'll research the litigation and assignment record for this patent before reconstructing the chain.

Key finding on the first case. Let me pin down both Delaware cases and the asserted patents.

Inventors

Both inventors executed an assignment to Lucent Technologies Inc. with signing dates between 2000‑03‑06 and 2000‑03‑17 — i.e., before the 2000‑03‑25 non‑provisional filing, which is the normal and healthy pattern for a corporate R&D shop.

Pattern check — inventor departure: Not determinable. I found no public record of either inventor's tenure or departure date. I explicitly decline to infer a "fire‑sale precursor" here: there is no evidence either inventor left within 12 months of filing, and the recordation history shows no distress transfer.

Original assignee

Lucent Technologies Inc. (Murray Hill, NJ) — assignee on the issued patent; the Google Patents cover‑sheet line reads "Lucent Technologies Inc." with the issue date 2005‑05‑03.

• Line of business: large operating telecommunications equipment vendor; this patent came out of Bell Labs' IP‑routing research (the specification targets routers, ECMP traffic splitting, and ISP backbone load balancing — squarely Lucent's then‑current product line of packet/circuit switching platforms).
• Product embodiment: Lucent sold routing/switching platforms in this era, but I have no evidence that any specific Lucent product implemented the claimed "x = K modulo M" table‑based splitting. Mark this as plausible but unverified — the patent itself is a method/apparatus claim not tied to a named SKU.
• Current status: Lucent Technologies Inc. was acquired by Alcatel (merger closed 2006‑11‑30), becoming a subsidiary of Alcatel‑Lucent; the US entity of record became Alcatel‑Lucent USA Inc. Alcatel‑Lucent was in turn acquired by Nokia (announced 2015, closed 2016). Google Patents lists the current assignee as Nokia of America Corp — consistent with that lineage, though I did not retrieve a Nokia‑era USPTO assignment record confirming it. The patent is Expired – Lifetime, full term, anticipated expiration 2020‑03‑25 (20 years from the 2000‑03‑25 filing), with maintenance fees paid at 4, 8 and 12 years (last on 2016‑10‑24).

Assignment timeline

Source caveat first, because it matters for your correspondent analysis: everything below comes from Google Patents' "Legal Events" and "Reel/Frame" fields, which reproduce the reel/frame from the recorded cover sheets. I could not reach assignmentcenter.uspto.gov / assignment.uspto.gov records directly in this session, so the "Correspondent of record" field is a genuine gap, not a null result — it is exactly the field you'd want and I will not invent it.

1. 2000‑03‑06 to 2000‑03‑17 (executed) / recorded 2014‑03‑11 — Reel 032401/0458

• Conveyance: Assignment (Assignment of interest)
• Assignor: CAO, ZHIROU; WANG, ZHENG
• Assignee: LUCENT TECHNOLOGIES INC. (New Jersey)
• Correspondent: Not exposed in the sources I could reach. This is the single most important record in the chain for your purpose and the correspondent is exactly what Assignment Center would disclose.
• Context: Original inventor→employer assignment, recorded ~14 years late — a title‑curative recordation filed weeks before the May 2014 infringement suit.

2. Effective 2013‑01‑30 / recorded 2013‑03‑07 — Reel 030510/0627

• Conveyance: Security Agreement ("SECURITY INTEREST")
• Assignor: ALCATEL‑LUCENT USA INC.
• Assignee: CREDIT SUISSE AG, NEW YORK
• Correspondent: Not exposed in the sources I could reach. (Note: a 2013 secured‑lender collateral recording is characteristically filed by the borrower's corporate/finance counsel, not by patent‑litigation counsel — so a repeat correspondent here would be a funding tell, not an NPE tell.)
• Context: Securitization/collateral — blanket security interest over ALU USA's patent portfolio under a credit facility; this implies ALU USA already held title to the '797 patent by 2013.

3. Effective 2014‑08‑19 / recorded 2014‑10‑09 — Reel 033949/0531

• Conveyance: Release ("RELEASE BY SECURED PARTY")
• Assignor: CREDIT SUISSE AG
• Assignee: ALCATEL‑LUCENT USA INC.
• Correspondent: Not exposed in the sources I could reach.
• Context: Release of security interest — collateral discharged; title clean again.

Missing link (important, and I am flagging it rather than smoothing it over): there is no recorded assignment in the Google Patents event list transferring title from Lucent Technologies Inc. to Alcatel‑Lucent USA Inc. That is expected — it happened by the 2006 Alcatel/Lucent merger / name change by operation of law, which is typically not recorded as an "Assignment" event. But it means the on‑face assignee name (Lucent Technologies Inc.) and the 2013/2014 secured‑party assignor name (Alcatel‑Lucent USA Inc.) differ, and the only record bridging them is the corporate transaction, not a recorded conveyance. If you need a clean standing record, that gap is the thing to check at Assignment Center.

No Assignment Center records located for any post‑2014 transfer — every entry above predates or is contemporaneous with the 2014 litigation. There is no chain leading to a licensing entity.

Timeline diagram

timeline
    title Ownership of US 6888797
    1999 : Provisional filed 05 May
    2000 : Application filed 25 Mar
    2000 : Inventors assign to Lucent
    2005 : Patent issues as US 6888797
    2013 : Credit Suisse security interest recorded
    2014 : Inventor assignment recorded at reel 032401
         : Security interest released
         : Alcatel-Lucent sues Fortinet in Delaware
    2016 : Nokia acquires Alcatel-Lucent
    2020 : Patent reaches full term

NPE / troll-pattern signals

1. Shell‑entity transfer — NOT PRESENT. The chain is Lucent Technologies Inc. → (merger/name change) → Alcatel‑Lucent USA Inc. → Nokia of America Corp. Every entity is a large operating corporation or a bank acting as secured lender (Credit Suisse AG). No "IP/Holdings/Ventures/Licensing" suffix, no single‑purpose Delaware LLC, no registered‑agent mailbox anywhere in reels 030510/0627, 032401/0458, 033949/0531.

2. Known asserter in the chain — NOT PRESENT. Assignees across all three recordings are Lucent Technologies Inc., Credit Suisse AG, and Alcatel‑Lucent USA Inc. — none appear on any Acacia / Marathon / IV / Wi‑LAN / Conversant / Vringo / Pendrell / MPHJ / Lumen View / Round Rock list. Trap to avoid: Acacia Research Group sued Alcatel‑Lucent entities in 2015 (e.g. 2:2015‑cv‑00581 and 2:2015‑cv‑00604, per a KIPO case table I indexed) — there, Alcatel‑Lucent is the defendant, not the assignee, and those cases do not touch this patent. Do not let that Acacia↔Alcatel‑Lucent proximity get misread as an Acacia interest in the '797 chain.

3. Repeat correspondent across the chain — UNCLEAR / UNAVAILABLE. This is the signal I most wanted to resolve and could not: Google Patents legal events do not carry the correspondent field, and I did not reach Assignment Center's records. I have no correspondent name for any of the three reel/frame entries, so I can neither confirm nor deny recurrence. Flagging as not assessed rather than "not present."

4. Cascading transfers — NOT PRESENT. Three recordings across 2013‑03‑07 → 2014‑10‑09, with no chained LLC hops, no shared anonymous addresses, and — critically — no transfer of ownership at all in that window: two of the three are a security interest and its release, and the third is a 2000 inventor assignment being recorded. Nothing cascades.

5. Pre‑litigation transfer — NOT PRESENT (benign variant). The recording 2014‑03‑11 (reel 032401/0458) lands ~7 weeks before the first Delaware complaint (2014‑05‑01), which superficially trips the "within 6 months" box. But examine what was recorded: the execution date is 2000, and the conveyance is inventors→Lucent, not a transfer to the plaintiff of record or to a new asserting entity. This is classic standing‑record housekeeping — curing an unrecorded 2000 assignment before filing — not chain‑arrangement to enable assertion. Calling this signal "present" would be a false positive.

6. Bankruptcy fire‑sale — NOT PRESENT. Neither Lucent, Alcatel‑Lucent, nor Nokia filed Chapter 7/11. The 2013 Credit Suisse recording shows leverage, not insolvency, and the security interest was released on 2014‑08‑19 — five years before ALU's eventual absorption into Nokia. There is no Kodak/Nortel/Polaroid‑style sale here; the patent simply ran to its 2020‑03‑25 expiration.

7. Privateering — NOT PRESENT for this patent (but see context). Lucent did operate a well‑documented assertion vehicle: the Multimedia Patent Trust (Delaware statutory trust formed 2006‑11‑28; Lucent the settlor), which received nine video‑coding patents and litigated against Microsoft. That is genuine privateering architecture inside this portfolio family. However, the MPT transfers I can document are the video‑coding patents (Netravali '272, Haskell '226, Puri '878, Agulnick '295, Fleming '759, Day '356) — US 6,888,797 does not appear among them, and no MPT‑related recording appears in this patent's event history. Signal: not present for the '797, with MPT noted as adjacent context only.

8. Defensive aggregator — NOT PRESENT. No RPX, AST, LOT, Unified, or OIN recording. Chain terminates at an operating vendor (Nokia of America Corp). I found no evidence of a defensive aggregation event. (Conversely, the patent was asserted, so it is not a "neutralized" asset.)

Verdict

Operating‑company assertion.

The complete recorded chain is Lucent Technologies Inc. → (2006 Alcatel merger / name change) → Alcatel‑Lucent USA Inc. → Nokia of America. The only ownership‑affecting recordings are a 2013‑03‑07 security interest to Credit Suisse AG (reel 030510/0627) and its 2014‑10‑09 release (reel 033949/0531) — a corporate financing, not a transfer — plus the 2014‑03‑11 recordation of the 2000 inventor assignment (reel 032401/0458). The patent's only litigation was brought by the operating owner itself: Alcatel‑Lucent USA Inc. v. Fortinet Inc., D. Del. 1:14‑cv‑00574, filed 2014‑05‑01 (Judge Leonard P. Stark, 35 U.S.C. § 271), which the Unified Patents litigation portal classifies with patent owner "Operating Company." Zero NPE signals are present; three are affirmatively negated (shell entity, known asserter, cascading transfers); two are unassessable (correspondent recurrence, and confirmation of the D. Del. 1:14‑cv‑00628 party — that second case number collides with several unrelated matters, e.g. Xpoint v. Microsoft 1:09‑cv‑00628 (D. Del.) and IPR2023‑00628 (VideoLabs/Roku), and I could not confirm its party or that this patent was asserted in it).

Contradiction check against the earlier sections: consistent, and this section adds what the earlier one lacked — the earlier summary had only the two Delaware case numbers and could not name the plaintiff; the plaintiff is now identified as Alcatel‑Lucent USA Inc., the operating owner. Two minor cleanups: the earlier bibliographic table rendered the title as "Hashed‑based network load balancing" (the patent reads "Hashing‑based"), and I could not confirm its note about Nokia of America Corp as current assignee from a USPTO record — that remains Google Patents' listing only.

Verify at:

• USPTO Assignment Center — https://assignmentcenter.uspto.gov/ (search 6888797; this is where you'll recover the correspondent of record for reels 030510/0627, 032401/0458, 033949/0531 — the one field I could not reach)
• Google Patents legal events — https://patents.google.com/patent/US6888797/en
• Alcatel‑Lucent USA Inc. v. Fortinet Inc., D. Del. 1:14‑cv‑00574 — https://dockets.justia.com/docket/delaware/dedce/1:2014cv00574/54849
• Unified Patents litigation portal entry — https://portal.unifiedpatents.com/litigation/Delaware%20District%20Court/case/1%3A14-cv-00574

I'll verify the cited prior art references and their details.

Both examiner citations are confirmed. Let me verify the non-patent literature cited in the specification and check for the Load-Balanced Port Group disclosure details.

Let me verify the Thaler draft version cited by the patent and the Load Balanced Port Group disclosure in the 3Com reference.

Prior-art analysis for US 6,888,797 B1 ("Hashing-based network load balancing")

Building on the bibliographic and claim analysis already produced, this section focuses strictly on the reference set. I confirmed each item against primary/secondary sources where possible and flag every place a literal identifier or date did not match a search result.

1. What "cited" references actually exist on the face of this patent

The USPTO/Google Patents record for US6888797B1 lists a "Patent Citations (2)" table (both entries carrying the examiner-citation marker * per Google's legend * Cited by examiner, † Cited by third party):

There is no third-party (†) citation in the patent-citation table, and the patent's Cited By lists are later documents that cite this patent (not prior art against it). Separately, the specification itself discusses three non-patent prior-art items (Fredette, Villamizar, Thaler) — these are applicant acknowledgments of prior art, not Form-892 citations. Both categories are analyzed below.

Data caveat: the fetched page renders the "Cited By" table twice, once headed "Cited By (61)" and once "Cited By (125)." This is a source-rendering artifact, not a claim about the patent. I also could not retrieve the underlying Form PTO-892 to independently confirm examiner vs. applicant provenance of the two patent citations; I am relying on Google's * marker.

2. Reference 1 — US 5,978,951 A (the only substantively relevant patent citation)

Full citation. US 5,978,951 A, "High speed cache management unit for use in a bridge/router," inventors Christopher P. Lawler, Shannon Q. Hill, David Lipschutz, Thomas A. Radogna, John A. Flanders, Robert M. France, Stephen L. Van Seters; assignee 3Com Corporation (Santa Clara, CA); Appl. No. 08/927,336; Int. Cl. H03M 13/00; U.S. Cl. 714/758, 370/392, 370/401.
Source: https://patentimages.storage.googleapis.com/00/64/55/27a840519c7361/US5978951.pdf and https://patents.google.com/patent/[US5978951A](/patent/US5978951A)/en

Dates.

• Filed: September 11, 1997
• Issued/patented: November 2, 1999
• (Later ownership per a Korean IP-dispute report: final rights holder PLECTRUM LLC; maintenance-term expiry noted 2017-09-11. Not relevant to validity, but flags it as a former 3Com asset that passed to an NPE.)

Brief description (from the abstract and figures as fetched). A hardware cache-management unit for a bridge/bridge-router. It keeps a network address cache plus an age table, searches the cache for Layer-2 and Layer-3 addresses taken from received frame headers, and returns lookup results. A cyclic redundancy code (CRC) engine performs a hash on the MAC source address (SA) or destination address (DA) "using cache configuration info and protocol ID", and the resulting hash is used as the index into a 4-way set-associative cache (see the flowchart steps "CRC PERFORMS HASH ON MAC SA USING CACHE CONFIGURATION INFO AND PROTOCOL ID," and the analogous DA step). The abstract also states the unit "can identify and select destination ports within a Load Balanced Port Group for frame forwarding." Claim 8 (representative, as reproduced in a third-party analysis) recites: an input register for header info including source and destination addresses; a CRC generator forming CRC-encoded addresses; a packetizer; a cache lookup unit and associated cache searched with the formatted CRC-encoded addresses; etc.

Which claims of '797 it potentially bears on, and under which subsection.

• Legal posture: Because US 5,978,951 issued after the '797 priority date (May 5, 1999) but was filed before it (Sept. 11, 1997), pre‑AIA § 102(e) is the correct subsection (the '797 application was filed March 25, 2000, so pre‑AIA §§ 102/103 govern). It is not § 102(a)/(b) art by publication, because its publication date (Nov. 2, 1999) is after the priority date. This is a common mis-citation trap; the reference is only prior art via its filing date.
• Claim 2 (value "determined from a hash function") and claim 16 ("many-to-few mapping element computes a hash value"): US 5,978,951 expressly computes a hash (CRC) over header fields — MAC DA/SA plus protocol ID — to derive an index. These are the strongest mapping points.
• Claims 3 / 7 / 15 (destination field combined with protocol ID, or "a portion" of protocol ID/source address/destination port/source port): US 5,978,951's hash uses destination address + protocol ID (and, for SA lookups, source address + protocol ID). Claim 7's "destination field and at least one of … protocol ID, destination port, source address, source port" is at least partially met (destination + protocol ID), though the claim phrase "said selected fields" ties back to claim 5's XOR combination.
• Claims 10 / 17 (output-link determination "effected through a look-up table"): the reference's core is a table (set-associative cache) lookup indexed by the hash value, so the "look-up table" concept is disclosed, though in the address-cache context rather than a load-distribution table.
• Claims 1 and 14 (the independents): Weak. Two limitations are not clearly met:
  1. Claim 1 requires calculating the value "from entirety of header data" — a literally-recited (and grammatically defective) limitation. US 5,978,951 hashes selected fields (SA or DA plus protocol ID), not the entirety of header data, so the reference actually points away from this element as recited.
  2. Claim 1 and claim 14 both require routing based on "network load directions" / "desired loading of said outgoing links" — i.e., operator/condition-specified load proportions. US 5,978,951's abstract mention of a "Load Balanced Port Group" is the closest disclosure, but the hash there is used for address-cache indexing, and "load-balanced" appears to describe the port-group configuration rather than a proportion-weighted splitting algorithm. I did not locate, in the material retrieved, a disclosure of thresholding/weighting hash outputs to achieve a specified percentage split.
• Claims 5 / 6 / 9 (XOR-combined field segments, four-way address segmentation): Not disclosed. The reference uses a CRC/hash generator, not the XOR-combination recited.

Bottom line: US 5,978,951 is a genuine § 102(e) reference and a credible § 103 combination base for the hashing sub-features (claims 2, 16, and arguably 3/7/15 and the "look-up table" concept of claims 10/17), but it does not appear to anticipate independent claims 1 or 14 on its own.

3. Reference 2 — US 6,496,928 B1 (cited, but facially non-analogous)

Full citation. US 6,496,928 B1, "System for transmitting subscription information and content to a mobile device," inventors Vinay Deo (Bellevue, WA), David Tuniman (Redmond, WA), Daniel R. Simon (Redmond, WA); assignee Microsoft Corporation (Redmond, WA); Appl. No. 09/108,145.
Sources: https://patents.google.com/patent/[US6496928B1](/patent/US6496928B1)/en ; https://uspto.report/patent/grant/[6496928](/patent/6496928) ; https://worldwide.espacenet.com/publicationDetails/biblio?CC=EP&NR=[1051824](/patent/1051824)

Dates.

• Priority: provisionals US 60/070,720 (Jan. 7, 1998), 60/074,236 (Feb. 10, 1998), 60/075,123 (Feb. 13, 1998); parent app. 09/108,953 filed June 30, 1998.
• Filing (this patent): June 30, 1998
• Issued: December 17, 2002
• Foreign counterpart EP 1 051 824 A1 published Nov. 15, 2000 — after the '797 priority date, so the EP publication is not itself prior art to '797.

Brief description. Controls access to broadcast messages received by multiple mobile devices (pagers/PDAs). Selected devices are given a broadcast encryption key (BEK) including a group code; broadcast messages are encrypted with a message-specific broadcast key (MSBK) derived from the BEK and message-specific data, broadcast over an address and group code, and decrypted on the selected devices. Representative claim 1: providing a BEK including a group code; encrypting broadcast messages with the BEK/MSBK; adding the unencrypted message-specific data and a header; broadcasting; and decrypting on the mobile device.

Which claims it potentially anticipates: none.

This reference is directed to broadcast encryption and key provisioning for mobile/pager devices. It discloses no hash function, no modulus, no header-field combination for traffic splitting, no output-link selection, and no load distribution. It does not disclose any element of claims 1–19. Its appearance on the face of '797 is best explained as an artifact of the citation record (or as a citation of a marginal secondary reference), not as substantive art. Note also the USPTO's own "Patent Citations (2)" table gives both of its entries the examiner marker — so this is not a third-party-submitted reference, and the mismatch is worth flagging as a record anomaly: I found nothing in US 6,496,928 that is relevant to the '797 claims, and I decline to construct a relevance theory the record does not support.

4. The more material prior art: the specification's own NPL acknowledgments

These are the references the patent itself identifies as prior art (Background section). In my assessment, the Thaler draft is more material than either cited patent, and the record's failure to cite it on the face of the patent is notable.

(a) D. Thaler, "Multipath Issues in Unicast and Multicast Next-Hop Selection" (Internet Draft; later RFC 2991, November 2000).

• As cited by '797: "working draft, January 1997."
• Date discrepancy — flagging explicitly: IETF document-history records show draft-thaler-multipath-00 as dated 1998-08-14 (https://dt-main.dev.ietf.org/doc/draft-thaler-multipath/history/), not January 1997. The final RFC 2991 is dated November 2000. I could not locate a January 1997 version. Under the strict no-auto-correction rule I report both: the patent says 1997; the IETF archive says the earliest -00 revision is Aug. 14, 1998. Either date precedes the '797 priority date (May 5, 1999), so the reference is prior art on either reading (if 1998‑08‑14: § 102(a) printed publication; if the 1997 date is correct: § 102(b)).
• Disclosure (verified text): § 4 "Solutions" recites three algorithms:
  • "Modulo-N Hash": "To select a next-hop from the list of N next-hops, the router performs a modulo-N hash over the packet header fields that identify a flow."
  • "Hash-Threshold": the router "first selects a key by performing a hash over the packet header fields that identify the flow. The N next-hops have been assigned unique regions in the hash function's output space. By comparing the hash value against region boundaries the router can determine which region the hash value belongs to and thus which next-hop to use."
  • "Highest Random Weight (HRW)": a key per next-hop; the highest-value next-hop wins, "approximately N times as expensive as a modulo-N hash."
  • It also states the granularity definition of a "flow": "identified solely by destination address, or … by (source address, destination address, protocol id) triplet," with port numbers noted in the microflow definition (RFC 2474).
  • Source: https://www.rfc-editor.org/rfc/rfc2991.html ; https://dt-main.dev.ietf.org/doc/draft-thaler-multipath/05/
• '797 claims potentially implicated: This is the closest thing I found to a per-element mapping onto claim 1 ("hash function x = K modulo M … determining … an output link based on the value and on network load directions") and claim 11 ("determining an output link … through comparing said value to thresholds," which is exactly Hash-Threshold's region-boundary comparison). It also maps onto claim 2 and the header-field selections of claims 3, 4, 7, 8 (destination address; source/destination address + protocol id triplet; and possibly ports), and onto the router-side claims 16, 18.
• Caveat on anticipation: RFC 2991/draft is largely framed around equal-cost multipath (equal splitting, "Modulo-N"). The '797 independent claims require selection based on "network load directions" (claims 12–13: specified proportions, or proportions supplied per network load conditions). Thaler's draft does not appear to teach proportion-weighted, unequal load distribution; the unequal-division problem is instead attributed in '797 to the Villamizar OSPF-OMP draft (below). So Thaler is best characterized as strong § 102(a)/§ 103 art for the hashing/threshold mechanism and a serious anticipation candidate for aspects of claim 1's first step and claim 11, not necessarily for the "load directions" element.

(b) C. Villamizar, "OSPF Optimized Multipath (OSPF-OMP)," Internet-Draft (IETF OSPF WG).

• Verified: draft-ietf-ospf-omp-00, dated 16 March 1998, 18 pages, author C. Villamizar (IETF announcement, 18 March 1998: https://mailarchive.ietf.org/arch/msg/ospf/xRjNHJFyMlyxWk4lpRbgJ0mi5HA/). Later revisions include -02 and -03 (Aug. 1999).
• Disclosure: an OSPF extension using Opaque LSAs to distribute loading information and to adjust forwarding; the draft states "An unequal division of traffic among the available paths is generally preferable" and proposes an algorithm to adjust load gradually. '797 itself characterizes the draft as proposing "per-packet round robin, dividing destination prefixes among available next hops in the forwarding table, and dividing traffic according to a hash function applied to the source and destination pair. However, the actual hash functions for traffic splitting is not defined."
• '797 claims potentially implicated: the "network load directions" element of claims 1, 12, 13 and 14 ("desired loading of said outgoing links"), and the general unequal-multipath-adjustment concept. Crucially, the patent's own characterization concedes this reference does not disclose the hash function itself, which is the crux of claim 1 — so it is a combination partner (§ 103), not an anticipatory reference.

(c) P. Fredette, "The Past, Present and Future of Inverse Multiplexing," IEEE Network, April 1995.

• Disclosure: inverse multiplexing by round-robin / fair queuing over multiple narrowband trunks; the BONDING consortium standardization; packet reordering and sequencing issues.
• '797 claims potentially implicated: None for anticipation. It is cited as background describing the problem (misordering from round-robin) that the '797 hash approach avoids. It does not disclose hash-based splitting, modulus, or load-proportional thresholding.

(d) OSPF generally / RFC 2328 (Moy, April 1998) — referenced only as the protocol that "has incorporated support for multiple equal-cost paths" but does "not specify" splitting algorithms. Background only.

Also note the applicant's own admission in the Background that "Hashing-based schemes for load balancing have been used in some commercial router products … typically using the last 2-3 bits of the Internet Protocol (IP) destination address or simple hashing over the IP destination address." This is a § 102(b)/admission-against-interest statement about prior-art commercial routers; it narrows what claim 1 can read on, and any such product documentation (router manuals, release notes) would be worth obtaining as prior art.

5. Consolidated anticipation map

Highest-value observation: the examiner's two-citation set does not include the specification's Thaler draft, which discloses the very mechanism (modulo-N hash over flow-identifying header fields; hash-threshold boundary comparison) that overlaps most closely with claim 1's hash step, claim 2, and the threshold-based claims 11/18. Conversely, the second examiner citation (US 6,496,928) is facially unrelated to the '797 subject matter. Combined with the patent's own admission of prior commercial hash-based load balancers, the strongest invalidity theories run through § 103 over {Thaler (or OSPF-OMP) + Fredette/OSPF background} and § 102(e)/§ 103 over US 5,978,951 for the hashing sub-claims — not through a single-reference § 102 anticipation of independent claims 1 or 14.

6. Explicit uncertainty / verification gaps

• Provenance of the two patent citations (examiner vs. applicant, Form PTO-892, and any accompanying reasons for allowance) is inferred from Google Patents' * marker only; I did not retrieve the file wrapper.
• US 5,978,951's "Load Balanced Port Group" disclosure may bear on the "network load directions" element, but I could not obtain the full specification/claims text to test whether it teaches proportion-weighted splitting. This should be checked against the full document (columns discussing the port group and Figure 6 flowchart).
• The Thaler draft's date is inconsistent between the patent (Jan. 1997) and the IETF archive (earliest revision 1998‑08‑14). I have not reconciled this; it does not change prior-art status but does affect whether § 102(b) versus § 102(a) applies.
• I found no additional patent citations beyond the two listed, and I did not attempt an independent prior-art search beyond the record (no evidence of an IPR/PGR art set was located in the earlier sections either).

I'll ground this §103 analysis in the actual prior-art record for US 6,888,797. Let me pull the two examiner-cited references and the NPL cited in the specification.

Key hits. Let me pin down the exact January 1997 Thaler draft (the patent's own admitted art) and check what the Microsoft reference actually discloses.

Obviousness Analysis — US 6,888,797 B1 under 35 U.S.C. § 103

This builds on the earlier "Patent summary" and "Litigation summary" sections. I do not restate the bibliographic data or the claim overview; I use them (plus the flagged claim‑1 drafting defect) as the starting point.

1. Framework and critical dates

Because the application was filed before 2013, pre‑AIA §103 applies and the pre‑AIA §102 categories define the available art. The practical consequence: references published before 1999‑05‑05 are squarely §102(a)/(b) art; US patents/applications filed before 1999‑05‑05 are §102(e) art even if they issued later.

2. The prior-art record actually available

The examiner cited only two references (US 5,978,951, US 6,496,928). The specification itself cites three NPL items, which operate as admitted prior art (M.P.E.P. §2129; Riverwood Int'l v. R.A. Jones).

Caveat on the Microsoft reference (US 6,496,928): I could not verify any teaching in it pertinent to claims 1 or 14. Any obviousness ground naming it must first identify a specific passage; I decline to invent one. It may have been cited under §102(e) for a tangential reason, or as background. Note its incorporated‑by‑reference application Ser. No. 09/107,899 ("efficient routing and translation of data") as a possible but unverified source of routing disclosure.

Caveat on the Thaler draft (the single most important evidentiary gap): the patentee's own Background describes the Jan‑1997 Thaler scheme in the same terms as RFC 2991 §4's HRW ("each next‑hop is assigned with a weight based on a simple pseudo‑random number function seeded with the flow identifier and the next‑hop identifier … approximately N times as expensive as a hashing‑based scheme"). That corroborates that the Jan‑1997 draft existed and contained HRW. It does not by itself prove the Jan‑1997 draft contained the Modulo‑N Hash and Hash‑Threshold sections. Obtain draft-thaler-multipath-00 from the IETF archive before relying on those passages.

3. Claim 1, element by element

Reciting my earlier literal-reading note: "calculating the value from entirety of header data" is defective. Two constructions are possible, and they matter:

• (A) "the entirety of the data from which the value is calculated is header data" (i.e., a header‑vs‑payload limitation). Under this reading, dependent claims 3–9 (subsets of fields) are consistent, and the claim is met by the art.
• (B) literally "all header data must be hashed." Under this reading, claim 1 is not met by OMP (source+dest only) and conflicts with dependent claims 3–9 (a dependent claim cannot broaden). This construction would raise a §112(b) indefiniteness problem, i.e., validity would fail on a different ground.

Claim 1 is a close call for anticipation and a strong candidate for obviousness. The only element OMP arguably misses is the field selection (src+dst vs. src+dst+others); and Modulo‑N Hash in Thaler supplies the modulo form on "the packet header fields that identify a flow." That gap is precisely the gap the patentee admitted: the '797 Background states OMP proposed "dividing traffic according to a hash function applied to the source and destination pair. However, the actual hash functions for traffic splitting is not defined." The claimed advance is therefore which header fields to feed the hash — a selection from a genus the admitted art already disclosed.

4. Claim 14 (router, "improvement" form)

Claim 14's preamble is environmental; under pre‑AIA practice it is treated as old, so the analysis focuses on the improvement. The improvement is the combination of '951's hash‑to‑a‑few mapper with OMP's load‑proportional allocation of the hash space. Obviousness of claim 14 is strong.

5. Dependent claims

6. Why a POSITA would have combined these references

1. Same field, same problem, same elements (KSR; In re Keller). All the references address selecting one of several parallel next hops/ports for a packet flow. '951 is a bridge/router addressing "Load Balanced Port Group" selection; OMP is an intra‑domain routing extension for splitting traffic over equal‑cost paths. Combining them is not a field‑crossing; it is a hardware‑mechanism‑meets‑allocation‑policy combination.
2. Explicit suggestion in the primary reference family. OMP expressly proposes hashing header fields and splitting the hash space "by either setting thresholds or performing a modulo operation," and states the technique "is the best technique available for a high speed WAN." The remaining question — which fields — is answered in the same technical community by Thaler (src/dst/protocol‑id triplet; microflow including ports) and, in hardware, by '951 (MAC SA/DA + protocol ID hashed to an index).
3. The patentee's own admission narrows the gap to a design choice. The Background concedes OMP proposed hashing the source/destination pair and complains only that "the actual hash functions for traffic splitting is not defined." Where the art discloses a genus and identifies a finite set of candidate species, choosing among them is obvious (KSR; In re Petering; M.P.E.P. §2144.04). The candidate species here are the five IPv4 header fields recited in claims 3–6 — plus "segments" thereof, which the specification admits is merely a granularity accommodation for small M.
4. Predictable result, no change in function. Each reference performs its own function unchanged: '951 hashes and indexes; OMP/Thaler allocate hash space to paths. The combined result (flow‑affine, load‑proportional forwarding) is exactly what each reference states it seeks — "Equal flow distribution is achieved when the hash function is uniformly distributed" (Thaler), and "the amount of hash space allocated to a path is incremented… decremented" (OMP). This is the classic "arrangement of old elements yielding no more than expected."
5. Design incentive to improve granularity. The '797 patent asserts as a benefit that "a larger value of M provides for finer granularity." OMP already states a 14–16‑bit hash "provides fine adjustment granularity." So the alleged benefit was known and the design tradeoff (finer split ⇒ wider hash) was already articulated in the art.
6. Problem recognized in the art → solution suggested. Fredette (1995) and the '797 Background both identify the reordering harm from round‑robin (false TCP fast‑retransmit). Thaler identifies the same harm and states the "natural solution … is to ensure that packets for the same flow always use the same path." That is a documented motivation in the art to adopt hashing, not to avoid it.

7. Rebuttal arguments to anticipate

• Teaching away (limited, claims 4/6/8 and their dependents). Thaler's later versions expressly caution that "including transport‑layer information in the next‑hop selection process can actually be problematic" (fragmentation; MTU caching) and recommend src/dst [/protocol]. If the Jan‑1997 draft contains that caution, there is a real teaching‑away argument for the port‑reciting claims (4, 6, 8 and apparatus counterparts). Counter: the caution is a tradeoff, not a disavowal, and the '797 specification is silent on fragments; where a reference "criticizes, or even teaches away from" only one embodiment, the remaining embodiments can still render claims obvious.
• "Entirety of header data" (construction (B)). If a court construes claim 1 literally, the claim is likely invalid under §112(b) rather than §103. Either way the claim is exposed; only the ground changes.
• §112 and the antecedent "the value." Claim 1's "calculating the value" before any "a value" is recited is the same drafting defect noted in the earlier summary. It may be curable by a certificate of correction or by construction, but it does not create a §103 defense.
• Public accessibility of Internet‑Drafts. The Jan‑1998/Mar‑1998 OMP drafts were posted to the IETF Internet‑Drafts directories and announced on the IETF mailing list (I‑D ACTION announcement, 18 Mar 1998, https://mailarchive.ietf.org/arch/msg/ospf/xRjNHJFyMlyxWk4lpRbgJ0mi5HA/). That is good, but not conclusive, evidence of "printed publication"; expect the patentee to probe actual public accessibility and indexing. The Dec‑1998 OMP slides (http://www.ietf.org/proceedings/98dec/slides/ospf-moy-omp-98dec.pdf) are an independent, independently dated corroborating publication.
• Secondary considerations. I located no evidence of commercial success, long‑felt need, failure of others, or industry praise with nexus to the claims. The only indirect signal is that the patent was asserted in the two 2014 D. Del. cases (1:14‑cv‑00574, 1:14‑cv‑00628) — but assertion value is not a secondary consideration without a nexus, and I could not verify the parties or outcomes. Note also that the current assignee lineage is Lucent → Alcatel‑Lucent → (per Google Patents) Nokia of America, so any licensing revenue would need to be tied to the claimed features to have weight.

8. Bottom line

Overall: the patent's thin prosecution (two cited references, no IPR/PGR located, no foreign counterpart family) is not indicative of strength. Its own Background supplies the dispositive admissions, and the claimed subject matter is largely the implementation detail the admitted art left open. The center of gravity for any §103 challenge is OSPF‑OMP draft‑00 + the January 1997 Thaler draft, with US 5,978,951 supplying the hardware many‑to‑few mapper and port‑group selection for the apparatus claims.

9. Items I could not verify (flagged, not assumed)

1. The text of draft‑thaler‑multipath‑00 (Jan 1997). I retrieved only the Feb‑2000 draft and RFC 2991, both of which post‑date the '797 filing and are not prior art to it.
2. Any load‑balancing/hashing teaching in US 6,496,928; and the examiner's rationale for citing it.
3. Whether draft‑ietf‑ospf‑omp‑01/-02 contain materially different disclosures; EP 1 313 269 references a 18 Feb 1999 OMP draft, which would also predate 1999‑05‑05.
4. Whether the January 1997 Thaler draft contains the "including transport‑layer information … can be problematic" caution relied on for the teaching‑away argument.
5. The identity of any primary reference that expressly teaches exclusive‑OR combination of the five named header fields.
6. No IPR/PGR or CAFC proceeding for US 6,888,797 was located; that is a negative search result, not a verified absence.