US 6046979

I'll verify the patent against current sources, including any 2026 litigation activity, before summarizing.

Let me check for litigation history and any 2026 appellate activity specifically.

US Patent 6,046,979 — Analyst Summary

Source of truth: the full patent text at https://patents.google.com/patent/[US6046979](/patent/US6046979)/en (fetched 2026‑09‑12). Where search results and training data conflict, I've deferred to that text.

Bibliographic Data

Assignee — note a real discrepancy in the record. The Google Patents header lists Current Assignee as Nokia of America Corp and Original Assignee as Cabletron Systems Inc. However, the assignment-history entries on the same page show the application was assigned to YAGO SYSTEMS, INC. on 1998‑05‑04 (assignor Bauman), then to CABLETRON SYSTEMS, INC. on 1999‑08‑20, then to RIVERSTONE NETWORKS, INC. on 2000‑10‑19, then (2014) to LUCENT TECHNOLOGIES INC. and ALCATEL‑LUCENT USA INC. I am reporting these literally rather than reconciling them; the "Original Assignee: Cabletron" label appears to reflect a later-recorded chain rather than the as-filed owner.

Family (per Google Patents): EP1082831B1, CA2329020C, WO1999057825A1, AU746446B2.

Abstract (as published)

A method and apparatus for controlling the flow of variable-length packets to a multiport switch involve accessing forwarding information in a memory based at least partially on layer 4 information from a packet, then forwarding the packet only if it is within a bandwidth consumption limit specified in that forwarding information. A credit bucket algorithm enforces the limits: layer 2 headers are stripped; layer 3/layer 4 information is used to look up flow-specific forwarding and flow-control information in a memory holding a linked list of table entries; and the credit bucket algorithm is implemented in embedded devices inside an application-specific integrated circuit, allowing per-application control of packet flows.

Plain-Language Overview of the Independent Claims

Claim 1 — Method (layer 3 + layer 4 indexed policing).
On a multiport switch: receive a variable-length packet with header info; access a memory holding forwarding information that includes bandwidth-management information; search that memory using TCP or UDP information together with IP or IPX information from the packet header; find the forwarding entry for that packet; extract its bandwidth-management information, which includes a bandwidth consumption limit; compare that extracted information against the packet; forward the packet if doing so will not exceed the limit; and either drop the packet or tag it with an adjusted priority before switching if forwarding would exceed the limit.

Claim 5 — Apparatus (means-plus-function, flow-control-specific circuitry).
An apparatus with: means for receiving a packet carrying layer 3 and layer 4 header information; a memory whose searchable registers store flow-specific forwarding information including layer 4 application protocol information; means for locating the flow-specific entry based at least in part on that application protocol information; means implemented in circuitry specific to packet flow control for comparing the packet's arrival time to the time the flow's forwarding entry was last accessed (to test whether a pre-established time interval has expired); means in that same flow-control circuitry for comparing a credit bucket value representing a maximum-size packet against the received packet's size — forwarding if the packet is smaller or equal, dropping/limiting if larger; and means for decrementing the credit bucket each time a packet from the flow is forwarded and refreshing it back to a pre-established value whenever the time interval has expired. (Claims 6–8 add: all said means on a single ASIC; a direct data connection between memory and that ASIC; and means for selecting system-counter bits representing the time interval.)

Claim 9 — Method (TCP/IP-compatible switch, L2 strip + L3/L4 lookup).
On a TCP- and IP-compatible multiport switch handling packets with layer 2, 3 and 4 headers: receive a packet of a particular length; strip the layer 2 header; access a memory of flow-specific information; use the packet's layer 3 and layer 4 header information to look up that flow-specific information; compare the flow-specific information both to the packet's length and to a clock value representing the time the packet was received; and forward the packet if its length does not exceed a maximum packet length determined by a credit bucket indicator in the flow-specific information. (Claim 10 adds refreshing that maximum length from a credit-refresh indicator when a time-select-defined interval has expired; claim 11 adds tuning the interval or maximum length; claim 12 adds accumulating a preselected credit value on each interval expiry.)

Claim 13 — Method (time-select-centric framework).
Same overall structure as claim 1 (receive → access memory with bandwidth-management information → search on the packet's header info → locate entry → extract bandwidth-management information → compare → forward or drop/tag), but with the additional step of isolating a "time select" vector that indicates significant bits of a system counter and thereby determines the pre-established time interval. (Dependent claims 14–19 add a time-stamp vector for last-access time, a credit-bucket vector, a credit-refresh vector, and the specific comparison/update steps: compare clock vs. time stamp; if not expired compare credit bucket to packet; if expired update the limit from the credit-refresh vector and re-test; and update the credit-bucket vector accordingly.)

Supporting Details Worth Noting

• Credit bucket granularity: credits count 32-byte "switching blocks"; the credit-bucket field is 14 bits, the credit-refresh field 12 bits (minimum resolution four switching blocks / 128 bytes); the time-select vector is 4 bits selecting one of eleven staggered counter groups (factor-of-four spacing) off a 45-bit, 50 MHz system counter; the time-stamp field is 10 bits.
• Priority vector: setting it to "11" causes a violating packet to be dropped; any other setting causes it to be tagged with lowered priority.
• "Use it or lose it" refresh: leftover credits are not carried between intervals in the preferred embodiment; accumulating-bucket and tandem (peak + average) variants are described as alternatives.
• Fuzz function (FIGS. 8–9): a 12-bit timer value's upper three bits are reduced by a "fuzz" function to one bit appended to the lower nine, producing a 10-bit "fuzzed" value intended to mitigate wrap-around error and binary-back-off cadence collisions.
• Prior art distinguished: U.S. 5,381,407 (Chao), criticized as ATM-specific and VCI-dependent, hence inapplicable to variable-length protocols such as Ethernet; FIG. 2 architecture (central CPU + software L3/L4 lookups) criticized for speed bottlenecks.
• Worked examples: Tables 3–5 give time-select intervals and rate-limit pairs, e.g. an ~8 Kbps limit via time-select 10 (171.80 s) with refresh 1,342 (171,776 bytes), and a 100 Mbps limit via time-select 0 (163.84 µs) with refresh 16 (2,048 bytes); stated range is below 8 Kbps to over 1 Gbps.

Litigation / CAFC 2026 Check — Important Caveats

What I could verify. The Google Patents record flags a US case in Delaware District Court, case 1:14‑cv‑00574, sourced to Unified Patents litigation data, plus a "First worldwide family litigation" entry from Darts‑ip. I did not independently verify the parties, outcome, or asserted claims of that 2014 case, and the free web sources I reached did not surface its docket details.

What I could not find — and I want to be explicit rather than fill the gap. My searches returned no results indicating any 2026 (or any) Court of Appeals for the Federal Circuit docket involving US 6,046,979. Queries aimed directly at that number plus CAFC/2026, at the Delaware case number, and at "Federal Circuit appeal … Nokia of America" for this patent all returned empty or unrelated hits. I also could not query the USPTO Patent Center or the Federal Circuit's own docket systems directly — my tools are general web search, not authenticated docket databases — so absence of results here is not affirmative evidence that no 2026 appeal exists, particularly since appellate records are often indexed poorly.

Two contextual points bearing on plausibility: (1) the patent's anticipated expiration was 2018‑05‑04, so live 2026 infringement litigation is unlikely, though damages tails and licensing disputes can outlive a patent; and (2) the "Nokia of America" hits my searches did return concern Finesse Wireless LLC v. AT&T Mobility LLC, No. 2024‑1039 (Fed. Cir. Sept. 24, 2025) — a $166.3M award vacated over U.S. Patents 7,346,134 / 9,548,775. That case involves entirely different patents and technologies and has no connection to the '979 patent; I mention it only to flag it as a false positive that shares the "Nokia of America" name.

Net: treat the bibliographic and claim content above as authoritative for the patent itself; treat any statement about 2026 appellate activity as unverified, and re-check against PACER/CM-ECF and the Federal Circuit docket directly if that question is material.

I'll research litigation involving US 6046979. Let me run several searches.

Let me dig into the specific Delaware case and related searches.

Bottom line

Only one litigation record is tied to US 6,046,979 ("Method and apparatus for controlling the flow of variable-length packets through a multiport switch," filed 1998‑05‑04, granted 2000‑04‑04, expired 2018‑05‑04) in the authoritative record I have in this session:

Source in the patent record itself:

• https://portal.unifiedpatents.com/litigation/Delaware%20District%20Court/case/1%3A14-cv-00574 — "US case filed in Delaware District Court," presented under the Family‑has‑litigation heading.
• A parallel Darts‑ip family link: https://patents.darts-ip.com/?family=22105894&... — labeled "First worldwide family litigation filed."

I must be explicit about the limits here rather than fill in gaps: my searches for this case number (and for "6046979" + litigation variants) returned no substantive results — the only hits were unrelated (e.g., a patent numbered 10,844,697, which is a different patent and I am not substituting it). I could not retrieve the PACER/Unified case detail page, so I cannot name the parties, the exact filing date, the asserted claims, or the disposition. Treat those four fields as unverified, not as "none."

What this means practically

1. The Google Patents "family has litigation" flag is attached to the case number above and to the Darts‑ip family ID 22105894. Note the linking is at least partly family‑level: the Darts‑ip entry says "First worldwide family litigation," so it may reflect litigation on a family member (e.g., EP 1 082 831 B1, CA 2,329,020 C, AU 746446 B2, or WO 99/57825 A1 — all claiming priority to this application) rather than on US 6,046,979 itself. Do not assume all of these are US proceedings against the '699 patent.
2. No PTAB proceedings (IPR/PGR/CBM) are listed in the record I have. Absence in this snapshot is not affirmative proof of none, but it is consistent with none.
3. Timing note relevant to identifying the likely plaintiff: USPTO assignment records in the patent record show the chain Cabletron Systems → Yago Systems → Cabletron → Riverstone Networks (recorded 2000‑10‑19) → Lucent Technologies (recorded 2014‑01‑21) → Alcatel‑Lucent USA (merger, recorded 2014‑01‑21). The 2014 recording date sits right at the 2014 case numbering. That is a lead, not a finding — I did not verify that Alcatel‑Lucent USA was the plaintiff in 1:14‑cv‑00574. Separately, Google's listed current assignee is Nokia of America Corp, which would bear on any later‑filed (2018‑expiry‑window) assertions.
4. Because the patent's statutory term ended 2018‑05‑04 (status "Expired – Lifetime"), any case still pending would be limited to past damages; the 2014 case almost certainly resolved years ago either by dismissal, settlement/license, or judgment, but I cannot state which.

Verification steps I recommend (I could not complete these within this session)

• PACER (D. Del.): query case 1:14‑cv‑00574 directly for plaintiff, defendant, complaint filing date, docket entries, and termination/ judgment. This is the definitive source.
• CourtListener/RECAP free docket mirror for 1:14‑cv‑00574.
• Unified Patents Portal patent detail page for US 6,046,979 (litigation + PTAB tabs), and their District Court litigation search filtered by patent number.
• Darts‑ip family 22105894 to enumerate foreign counterparts and any non‑US suits in the same family.
• Docket Navigator / Lex Machina for any second wave of suits on the '699 patent that the Google snapshot may not have joined to this patent record (e.g., suits against additional defendants under the same case number, or later‑numbered cases).
• USPTO PatentCenter / Assignment Search for the recorded 2014 assignments to confirm who held title on the 1:14‑cv‑00574 filing date.

Strict‑rule compliance note

I interpreted the identifier literally throughout: the patent at issue is US 6,046,979 / US6046979A (application 09/072,148). The only search hit that superficially resembled the number was US 10,844,697, a different patent in an unrelated case (DynaEnergetics Europe GmbH v. GR Energy Services, W.D. Tex.), which I have excluded and flag only so you know it was not mistaken for the target.

If you can provide the PACER docket text or a Unified/Darts‑ip case detail export for 1:14‑cv‑00574, I can complete the plaintiff/defendant/filing‑date/outcome fields with citations.

I'll verify the structured "no PTAB proceedings" default against live sources before writing.

Let me run additional targeted queries against likely owners and the litigation trail.

Proceedings overview

Zero AIA trial proceedings are on file for US 6,046,979. The structured USPTO Open Data Portal block in my tasking is unambiguous — no IPR, no PGR, no CBM — and my independent web searches turned up nothing that contradicts it. There is therefore no breakdown to report by status (no active proceedings, no claims invalidated by the Board, no claims sustained in a Final Written Decision, no settlements, no institution denials).

The bottom-line defensive posture is unusual and worth stating plainly: the patent is not "hardened" by PTAB wins — it is simply untested at the Board and, more importantly, expired. Status is "Expired – Lifetime," with anticipated expiration 2018-05-04 (per the patent record at https://patents.google.com/patent/US6046979/en, consistent with the bibliographic section already generated). No petitioner ever attacked it at the PTAB, so there is no Board record to cite for any claim — but there is also no live patent left to assert prospectively. A demand letter citing the '979 patent today is a past-damages / expired-patent conversation, not an injunction conversation. If such a letter arrives, the correct first move is not an IPR (see the § 315(b) analysis below) but a challenge to the damages theory and the assertion timeline.

Per-proceeding write-ups are omitted because there are no proceedings to write up. I will not construct entries for proceedings that do not exist.

Why there are no proceedings — and what that does and does not mean

The absence is real, and it is explainable. Well-asserted patents normally attract IPRs. Three features of this patent's history depress that likelihood:

1. Term. With a 1998-05-04 filing and a 2018-05-04 expiration, the entire economically useful assertion window for IPR-motivated defendants closed roughly eight years ago. The 2014 case flagged in the record (D. Del. 1:14-cv-00574, per https://portal.unifiedpatents.com/litigation/Delaware%20District%20Court/case/1%3A14-cv-00574) is described in the earlier-generated litigation section, and I noted there that the parties, outcome, and asserted claims remain unverified from my sources. What I can say is that no PTAB proceeding is joined to that case in any source I reached.
2. Procedural unavailability of the other two AIA vehicle types. PGR is unavailable: the application was filed 1998-05-04, well before the March 16, 2013 first-inventor-to-file cutoff, so it is not a PGR-eligible patent. CBM is likewise unavailable — the transitional program sunset 2018-09-16, and in any event the '979 patent is directed to multiport switch hardware and a credit-bucket rate limiter, not a "financial product or service," so it would not have qualified. IPR was the only AIA path available, and it was never used.
3. That said, absence of results is not affirmative proof. My tools are general web search, not authenticated docket systems. I could not query PTAB E2E (https://ptab.uspto.gov/), the PTAB Decisions collection, the USPTO ODP API directly, or CourtListener's docket search (https://www.courtlistener.com/) in this session. Treat "no PTAB activity" as high-confidence but not exhaustively verified. One search result that superficially resembled a hit was US 7,822,048 B2 (QoS policing), on whose Unified Patents portal page US-6046979-A appears only as a listed/citing reference — that is a citation, not a proceeding, and I am explicitly not reporting it as one.

Strategic summary

Claim status: every claim of 6,046,979 is UNTESTED at the PTAB — none canceled, none sustained. The full claim set (independent claims 1, 5, 9, 13, plus dependents 2–4, 6–8, 10–12, and 14–19) stands as issued, never having been subjected to an institution decision, an institution denial, or a Final Written Decision. This is a different posture from a patent that has survived IPRs: there is no Board reasoning adopting or rejecting the patent owner's claim constructions, no adopted obviousness findings, and no PTAB-favorable record for the owner to wave at a district court. Conversely, a defendant gets no free invalidity roadmap. The patent's practical weakness is its term (expired 2018-05-04), not a PTAB record.

Estoppel landscape: 35 U.S.C. § 315(e)(2) is a non-issue in both directions. Because no IPR was ever instituted, no petitioner (or privy) is estopped from raising any ground, and conversely there is no petitioner-side art that has been locked in or knocked out. If you are a defendant facing assertion, your prior-art and § 112 grounds are fully available in district court — nothing has been waived or foreclosed by a prior PTAB run. The counterweight is timing: § 315(b) bars an IPR petition filed more than one year after service of a complaint alleging infringement. Any defendant served in the 2014 Delaware action is long past that window, which is precisely why the "file an IPR" reflex is the wrong one here even if the patent were not expired.

Pattern signals: none of the usual ones. There is no repeat petitioner, no defensive aggregator (Unified Patents or similar) in the PTAB chain for this patent, and no patent-owner appeal pattern to the Federal Circuit traceable to an AIA trial. The '979 patent has a rich reassignment history (Yago Systems → Cabletron → Riverstone Networks → Lucent Technologies → Alcatel-Lucent USA, with the Google-listed current assignee being Nokia of America Corp) — this is an ownership chain, not an assertion campaign, and it should not be read as evidence of PTAB activity. On the art side, the field was crowded: the patent's own specification distinguishes U.S. 5,381,407 (Chao) as ATM/VCI-specific, and later rate-limiting patents such as Foundry/Brocade's US 7,310,309 and US 7,724,662 cite the '979 patent as a reference — useful context if you ever need to frame obviousness, but not a substitute for a Board record.

Recommended next steps

• If no PTAB activity (the operative finding): say so plainly to your client, and pivot the defense away from AIA trials. The absence here is not the usual "well-asserted patents eventually attract IPRs" signal — it is explained by the patent's 2018-05-04 expiration and the fact that PGR and CBM were never available for it.
• Confirm the negative independently before relying on it. Run US 6,046,979 through PTAB E2E (https://ptab.uspto.gov/) and the USPTO Open Data Portal / PTAB API; confirm with the PTAB Decisions collection and the patent's USPTO Patent Center page. Cross-check the 2014 Delaware case (1:14-cv-00574) on PACER and CourtListener/RECAP to determine parties, asserted claims, and disposition — that docket, not the PTAB, is where this patent's history actually lives.
• If a demand letter arrives citing '979: do not budget for an IPR. Given the 2018-05-04 expiration and the § 315(b) one-year bar running from service of any earlier complaint, an IPR petition is likely time-barred and would in any event yield only a paper victory against an expired patent. Focus instead on (a) the assertion timeline and the limitations/damages period, (b) whether the demand letter rests on the expired claims at all, and (c) the identification of the real party in interest along the Yago → Cabletron → Riverstone → Lucent → Alcatel-Lucent → Nokia chain, which is where title and standing questions will be sharpest.
• If you are a new defendant served today (an unlikely scenario for an expired patent, but if it occurs): the § 315(b) clock would start at service, so an IPR petition would be procedurally timely for one year — but the patent's expired status makes the remedy question dominate, and you should weigh the cost of an AIA trial against what is realistically recoverable from you.

Nothing in this section should be read as confirming a proceeding number, a panel, a claim-level disposition, or a Federal Circuit appeal, because none exists on file for this patent.

I'll research the assignment record before writing anything, since reel/frame and correspondent data are the crux of this task.

Let me try to locate the actual USPTO assignment records and any correspondent-of-record data.

Assignment Chain Analysis — US 6,046,979

Critical data-availability note before anything else. I could not retrieve the USPTO Assignment Center / Patent Assignment Search records for this patent in this session — the searches I ran (patent number, assignee names, "reel frame" variants) returned no assignment-record pages, and my tools are general web search, not the authenticated Assignment Center or PatentCenter interfaces. Consequently no reel/frame numbers and no correspondent-of-record names are available to me for any link in this chain. I am reconstructing the chain from the assignment-history block in the Google Patents legal events for US6046979A, which reports conveyances, assignors and assignees but not execution dates, reel/frame, or correspondent. I have not invented any of those fields. Fields I cannot source are marked N/A — not retrieved.

Inventors

Pattern note — I can state this, and I decline to state more. The ideal NPE-precursor pattern ("all inventors depart the original assignee within 12 months") is not something I can evaluate: I have no employment-departure data, no personnel announcements, and no corroborating record. What the assignment record does show is that Bauman's personal assignment to Yago Systems was recorded the same day the application was filed, and that Yago Systems was itself assigning the application to Cabletron Systems within roughly 15 months (1999‑08‑20). That is consistent with a startup acquired by a larger buyer, not with inventor flight. I would need Yago Systems' corporate history and Bauman's subsequent employment to say anything stronger, and I can't source either here.

Original assignee

Two entities are honestly in play, and the record is genuinely inconsistent on this point:

• Google Patents "Original Assignee": Cabletron Systems, Inc. (per the patent-page header).
• Earliest recorded assignee on the documents: Yago Systems, Inc. (1998‑05‑04, from Bauman).

The reconciliation that fits both: Yago Systems was the as-filed owner and Cabletron Systems was the owner by the time the patent issued (2000‑04‑04 entry lists Cabletron as assignee). So "the entity named on the issued patent" is best read as Cabletron Systems, Inc., with Yago Systems as the pre-issue owner.

• Primary line of business. Yago Systems was a Layer 3/4 switch startup; Cabletron Systems was a publicly traded (NYSE) enterprise network equipment manufacturer. The patent's FIG. 3 architecture (IPP/OPP ASICs, data path multiplexer, scheduler, L3/L4 table in DRAM) is a description of the product line this work fed.
• Did they ship a product embodying the claims? The specification is written as an implementation description of a shipping multiport switch (Ethernet at layer 2, TCP/IP at layers 3–4, 10/100 Mbps and 1 Gbps links, 32-byte switching-block segmentation in an IPP ASIC), and the inventors' employer was a switch vendor. The described architecture matches the SSR/SmartSwitch Router family that Cabletron derived from the Yago acquisition. I am treating "a product embodying the claims was shipped" as highly likely but not documentarily verified in this session — I have no product datasheet or claim chart in front of me.
• Current status of the original assignee. Cabletron Systems no longer exists as an independent company; it was broken up in the early 2000s, with Riverstone Networks carrying the relevant routing/switching business forward. Riverstone Networks subsequently entered Chapter 11 (2006), and its assets were acquired by the Alcatel‑Lucent group. Google Patents currently lists the assignee as Nokia of America Corp (Alcatel‑Lucent was acquired by Nokia in 2016). I am flagging the 2006 Riverstone transaction as recalled context, not a source I retrieved today — I was unable to pull the bankruptcy docket or the asset-sale instrument in this session.

Assignment timeline

Provenance caveat applies to every entry below: dates shown are the dates Google Patents attaches to the legal events (recording/event dates). Execution dates, reel/frame, and correspondent of record are N/A — not retrieved. If the Assignment Center has no records for this patent under some query formulations, note that the records do exist for this chain (they are reflected in the patent's own legal-events record); the gap is my access, not the USPTO's records. Verify each line at the Assignment Center.

1. 1998‑05‑04 (executed date N/A) / recorded 1998‑05‑04 — Reel N/A/ N/A

• Conveyance: Assignment of interest
• Assignor: James A. Bauman (inventor)
• Assignee: YAGO SYSTEMS, INC.
• Correspondent: N/A — not retrieved. No recurrence can be flagged.
• Context: Inventor-to-employer assignment, executed on the filing date — routine startup practice.

2. 1999‑08‑20 (executed date N/A) / recorded 1999‑08‑20 — Reel N/A/N/A

• Conveyance: Assignment of interest
• Assignor: YAGO SYSTEMS, INC.
• Assignee: CABLETRON SYSTEMS, INC.
• Correspondent: N/A — not retrieved.
• Context: Acquisition — Cabletron's absorption of Yago Systems.

3. 2000‑10‑19 (executed date N/A) / recorded 2000‑10‑19 — Reel N/A/N/A

• Conveyance: Assignment of interest
• Assignor: CABLETRON SYSTEMS, INC.
• Assignee: RIVERSTONE NETWORKS, INC.
• Correspondent: N/A — not retrieved.
• Context: Internal reorg / spin-out — Riverstone carried Cabletron's routing-switch business out as a separate company.

4. 2013‑03‑07 (executed date N/A) / recorded 2013‑03‑07 — Reel N/A/N/A

• Conveyance: Security interest
• Assignor: ALCATEL‑LUCENT USA INC.
• Assignee: CREDIT SUISSE AG
• Correspondent: N/A — not retrieved.
• Context: Securitization — blanket security interest over Alcatel‑Lucent USA's patent portfolio in favour of a lender.

5. 2014‑01‑21 (executed date N/A) / recorded 2014‑01‑21 — Reel N/A/N/A

• Conveyance: Assignment of interest
• Assignor: RIVERSTONE NETWORKS, INC.
• Assignee: LUCENT TECHNOLOGIES INC.
• Correspondent: N/A — not retrieved.
• Context: Distressed-asset acquisition (Riverstone Chapter 11 → Alcatel‑Lucent group), recorded roughly eight years after the transaction it evidences — a late/confirmatory recording.

6. 2014‑01‑21 (executed date N/A) / recorded 2014‑01‑21 — Reel N/A/N/A

• Conveyance: Merger
• Assignor: LUCENT TECHNOLOGIES INC.
• Assignee: ALCATEL‑LUCENT USA INC.
• Correspondent: N/A — not retrieved.
• Context: Internal reorg by merger — title consolidated into the Alcatel‑Lucent US operating entity.

7. 2014‑10‑09 (executed date N/A) / recorded 2014‑10‑09 — Reel N/A/N/A

• Conveyance: Release by secured party
• Assignor: CREDIT SUISSE AG
• Assignee: ALCATEL‑LUCENT USA INC.
• Correspondent: N/A — not retrieved.
• Context: Securitization unwind — release of the 2013‑03‑07 security interest.

Two anomalies in the record worth flagging

1. Ordering inconsistency. The security interest (§4, 2013‑03‑07) names Alcatel‑Lucent USA Inc. as assignor/lien-grantor — but the assignment that would plausibly establish that entity's title is recorded later, on 2014‑01‑21 (§5 and §6). Either Alcatel‑Lucent USA already held beneficial title through an unrecorded earlier step, or the 2014 filings are clean-up recordings of transactions that closed years earlier (consistent with the Riverstone Chapter 11 timing). Either way, the recorded dates do not reflect the economic dates, which is material if anyone tries to date the chain from these entries.
2. Missing final link. Google Patents lists Nokia of America Corp as current assignee, but no Alcatel‑Lucent → Nokia conveyance appears in the legal-events list. That gap is unexplained by the data I have. It may be an unrecorded/blanket corporate transaction, or a Google entity-mapping artifact rather than a recorded assignment. I am not asserting an assignment that isn't there.

Timeline diagram

timeline
    title Ownership of US 6046979
    1998 : Filed by Yago Systems
         : Bauman assigns to Yago Systems
    1999 : Assigned to Cabletron Systems
    2000 : Assigned to Riverstone Networks
    2013 : Security interest to Credit Suisse
    2014 : Assigned to Lucent Technologies
         : Merger into Alcatel-Lucent USA
         : Delaware suit filed
         : Credit Suisse release recorded
    2016 : Alcatel-Lucent acquired by Nokia
    2018 : Patent term expired

NPE / troll-pattern signals

1. Shell-entity transfer — Not present.
Every assignee in the chain is an operating company or a lender: Yago Systems (switch startup), Cabletron Systems (public equipment maker), Riverstone Networks (spun-out public company), Lucent Technologies / Alcatel‑Lucent USA (operating telecom equipment), Credit Suisse AG (secured lender). There is no "IP / Patents / Licensing / Holdings / Ventures" suffix anywhere in the seven recorded events, and no single-member LLC. I did not retrieve addresses, so I cannot test the registered-agent-address tell either way; the naming-and-substance evidence points away from a shell.

2. Known asserter in the chain — Not present.
None of the enumerated NPEs (Acacia, Marathon Patent Group, Intellectual Ventures, IPNav, Wi‑LAN, Mosaid/Conversant, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, Document Generation Corp, Spangenberg entities) appears as any assignor or assignee in the chain. Qualified caveat: Alcatel‑Lucent USA ran a visibly active patent-monetization and assertion program in exactly the 2013–2014 window these recordings cluster in, and Nokia of America is a large operating company that also licenses and asserts. Under the standard definition used here, neither is an NPE. I flag the timing, not a classification.

3. Repeat correspondent across the chain — Unclear (unassessable, not exonerated).
This is the signal I most wanted to test and could not. The Assignment Center's correspondent-of-record field is exactly the right instrument, and I could not reach those records. I have zero correspondent names for this chain and will not supply one. No recurrence finding is possible; record this as an open item, not a clean bill.

4. Cascading transfers — Weakly present as a cluster; not present as an NPE pattern.
Four recordings fall inside a ~19‑month window: 2013‑03‑07 (security interest), 2014‑01‑21 ×2 (intra-group assignment + merger), 2014‑10‑09 (release). That is a genuine multi-step burst, but the steps are a lien, a lien release, and an internal reorganisation — not chained single-purpose LLCs. I have no shared-correspondent or common-principal evidence (see signal 3), so the cluster does not convert into an indicator.

5. Pre-litigation transfer — Unclear, and this is the closest thing to a real flag.
The only litigation record tied to this patent is D. Del. case 1:14‑cv‑00574 (flagged in the patent record against Unified Patents litigation data, with a parallel Darts‑ip "first worldwide family litigation" entry). The 2014‑01‑21 intra-group recordings (Riverstone → Lucent → Alcatel‑Lucent USA) fall in the same calendar year. If the plaintiff in that case was Alcatel‑Lucent USA, then the chain was being papered into the operating entity's name in the run-up to assertion — a clean-standing-record move. But I have not verified the plaintiff, defendant, or exact filing date of 1:14‑cv‑00574, so I cannot place any assignment inside the 6-month window the signal requires. Marked unclear on the merits, not dismissed.

6. Bankruptcy fire-sale — Present in substance, but not to an NPE.
Riverstone Networks entered Chapter 11 and its assets were acquired by the Alcatel‑Lucent group; the assignment evidencing this is recorded 2014‑01‑21 (§5). This is a real distress transaction, and it explains why the 2014 recordings appear at all. It is not an NPE signal, because the buyer was an operating company that kept the technology in-house. (Standard caveat: I am relying on recalled corporate history for the 2006 transaction; I could not pull the bankruptcy docket or the sale instrument in this session.)

7. Privateering — Not present.
No operating company transferred this patent to a separate licensing vehicle to assert on its behalf. To the extent the patent was asserted in 2014, the recording chain shows it was asserted by the operating-company titleholder itself (Lucent Technologies / Alcatel‑Lucent USA after the 2014 merger recordings), not by a spun-out assertion entity.

8. Defensive aggregator (anti-NPE) — Not present.
The chain does not terminate at RPX, AST, LOT Network, Unified Patents, or OIN. It terminates at Nokia of America Corp, an operating company. Note, however, that the patent's term expired 2018‑05‑04 (status: Expired – Lifetime), so the asset is now neutralised by expiry rather than by defensive acquisition. No post‑2018 assertion is possible on this patent itself (family members have their own terms — see below).

Verdict

Operating-company assertion.

Justification: every one of the seven recorded conveyances runs between operating companies or a secured lender — Bauman → Yago Systems (1998‑05‑04) → Cabletron Systems (1999‑08‑20) → Riverstone Networks (2000‑10‑19) → Lucent Technologies / Alcatel‑Lucent USA (2014‑01‑21) — with Credit Suisse AG appearing only as lienholder (2013‑03‑07, released 2014‑10‑09), and no shell LLC, no enumerated NPE, and no defensive aggregator anywhere in the chain. The one assertion record, D. Del. 1:14‑cv‑00574, coincides with the 2014 intra-group papering, which is consistent with an operating company confirming title before suing — but I could not verify the plaintiff, defendant, or filing date, and I retrieved no reel/frame and no correspondent names at all.

Two honest qualifiers keep this short of "high confidence" in either direction: the patent expired 2018‑05‑04, so this is a historical posture rather than a live NPE threat; and the correspondent-of-record analysis — the single strongest NPE tell available in the Assignment Center — was not possible because I could not reach those records (signal 3).

Verify at: https://assignmentcenter.uspto.gov/ (patent-number search 6046979) and https://assignment.uspto.gov/patent/index.html — pull each of the seven recordings above for reel/frame, execution date, and correspondent, and reconcile the missing Alcatel‑Lucent → Nokia link. Also check the family members (EP1082831B1, CA2329020C, WO1999057825A1, AU746446B2), since the Darts‑ip "first worldwide family litigation" entry may attach to a non‑US counterpart rather than to US 6,046,979 itself — a distinction that matters, because the non‑US members may not share this patent's 2018 expiry.

Data gaps — stated plainly, not filled in

• Reel/frame numbers: not retrieved for any of the seven events.
• Correspondent of record: not retrieved for any of the seven events; no recurrence finding is possible.
• Execution dates: not retrieved; the dates shown are recording/event dates and demonstrably lag the underlying transactions (see anomaly 1).
• Party identity in 1:14‑cv‑00574: unverified.
• Alcatel‑Lucent → Nokia of America assignment: not present in the legal-events record I have; I have not asserted one.
• Family-level litigation flags are not attributable to US 6,046,979 without checking each counterpart.

I'll research the prior art cited in US 6,046,979, starting with the patent's citation records.

The initial searches returned mostly irrelevant hits. Let me target the patent's front-page citation list specifically.

Let me target the citation list directly through FreePatentsOnline, Justia, and the Google Patents page.

I was able to make several searches, but I need to be direct about a key limitation before giving the analysis. Here is what I found and what I could not.

Prior-Art Analysis — US Patent 6,046,979

1. Target patent — verified identifiers

2. Important limitation on this answer (please read before using it)

You asked me to enumerate each patent citation on the face of 6,046,979 (the "References Cited" / "Patent Citations" list). I could not retrieve that front‑page list in this session, and I will not invent it:

• The authoritative patent text I was given from https://patents.google.com/patent/US6046979/en omitted the "Patent Citations" block — the fetched text jumps from the drawing images straight to Classifications, with no U.S. Patent Documents / Foreign Documents / Other Publications table.
• My web searches for "6046979" "References Cited", freepatentsonline 6046979, and Justia's '979 page returned forward citations (later patents citing '979) and unrelated same‑number records — not the backward prior‑art list.
• One search hit that looked promising (patents.justia.com, listing "6046979 | April 4, 2000 | Bauman" alongside non‑patent literature such as Tsai, "A Dynamic Bandwidth Allocation Scheme for ATM Networks") was actually the citation list of a different patent (US 7,536,473), where '979 appears as a cited reference. That NPL is not prior art to '979 and I am not attributing it to this patent.
• I hit the tool‑call limit before I could open the USPTO Patent Public Search "Citations" panel or the FreePatentsOnline references table directly.

So: I can confirm exactly one prior‑art reference of record with high confidence. I cannot supply the complete citation list, and I am flagging that rather than fabricating numbers.

3. Confirmed prior-art reference cited by the '979 patent

U.S. Patent No. 5,381,407 — Chao, "Method and System for Controlling User Traffic to a Fast Packet Switching System."

This reference is discussed by name in the '979 specification's Background, which is the authoritative source:

"Another approach to network traffic control is disclosed in U.S. Pat. No. 5,381,407, entitled 'Method and System for Controlling User Traffic to a Fast Packet Switching System,' issued to Chao. Chao is an asynchronous transfer mode (ATM) specific method and system that applies a well known leaky bucket algorithm to control the flow of 53‑byte fixed‑length packets…"

Brief description (from the '979 spec's characterization): An ATM‑specific system that applies a leaky‑bucket algorithm to control the flow of 53‑byte fixed‑length cells. A bucket large enough to hold bursts releases packets at a rate governed by credit availability; the flow is controlled by controlling the supply of credits, and the credit supply is derived from the virtual channel identifier (VCI) of each ATM cell.

Potential § 102 anticipation of the '979 claims — analysis

Anticipation under § 102 requires a single reference to disclose every element of a claim. Chao is the only confirmed reference of record, and on its face it does not anticipate any of the independent claims (1, 5, 9, 13), because each contains limitations Chao lacks:

Conclusion on Chao: It is a § 103 (obviousness) reference, not an anticipation reference. It discloses the general credit/leaky‑bucket concept and interval‑based refresh, but the '979 claims are expressly drafted around the very distinctions the patent uses to distinguish Chao — variable‑length (Ethernet/TCP‑IP) packets instead of fixed‑length ATM cells, and L3/L4 application‑protocol indexing instead of VCI indexing. The specification itself frames Chao as unable to "control user traffic" for TCP/IP networks. A § 102 challenge on Chao alone would fail against claims 1, 5, 9, and 13 on the record I can see.

4. What I can responsibly say about the rest of the citation list

I did not retrieve the remaining "U.S. Patent Documents" cited on '979's face, so I am not listing them. Based on the field and the specification's own discussion, the of‑record citations will fall into these classes (this is characterization, not an enumeration of specific numbers):

1. ATM leaky‑/token‑bucket flow‑control patents (the Chao family) — relevant to the credit mechanism, but ATM/fixed‑cell, so unlikely to anticipate on their own.
2. Packet‑switch flow‑control / congestion‑management patents — relevant to the credit‑bucket and drop/tag concepts in claims 1, 5, 9, 13.
3. L3/L4 lookup and application‑aware routing patents — relevant to the "search memory based on TCP/UDP + IP/IPX" and "layer 4 application protocol information" limitations (claims 1, 5, 9).

Named forward citations I saw (NOT prior art to '979 — these post‑date it): US 7,536,473; US 7,826,048; US 9,836,424; US 8,274,971; US 7,088,731 (Dune Networks); US 7,724,662 (Foundry Networks); US 9,479,436; WO/others. These list '979 in their "Patent References," i.e., '979 is cited by them. They cannot be § 102 art against '979. I flag them only so they are not mistaken for prior art.

5. How to obtain the authoritative citation list (could not complete here)

To fill the gap I left open, query these under the exact number 6,046,979:

• USPTO Patent Public Search (ppubs.uspto.gov) → open 6,046,979 → "References Cited" / "Cited By" tabs (authoritative front‑page listing).
• FreePatentsOnline: https://FreePatentsOnline.com/6046979.html → "US Patent References" table.
• Google Patents: https://patents.google.com/patent/US6046979A/en → scroll to "Patent Citations" (the section the fetched text omitted).
• Espacenet / Global Dossier for the family (EP 1 082 831 B1, CA 2,329,020 C, WO 99/57825 A1, AU 746446 B2) for the international‑search‑report citations, which often differ and add NPL.

If you can paste the "References Cited" table from any of these, I will complete the per‑reference § 102 element‑by‑element mapping (title, inventor, assignee, issue/filing dates, brief description, and the specific claims each potentially anticipates) for the full list.

Bottom line: The only prior‑art reference I can confirm is cited by US 6,046,979 is US 5,381,407 (Chao); it supports a § 103 analysis but does not anticipate claims 1, 5, 9, or 13 under § 102. The complete front‑page citation list was not retrievable with the tools available in this session, and I have deliberately not guessed at the remaining reference numbers.

I'll ground this obviousness analysis in verifiable prior art before reasoning. Let me run several searches in parallel.

Let me gather more specific prior art on per-flow token/credit policing and switch forwarding engines.

Obviousness Analysis — US 6,046,979 under 35 U.S.C. § 103

Scope note: The patent's effective filing/priority date is 1998‑05‑04 (pre‑AIA regime; pre‑AIA § 102/§ 103 apply throughout). The patent expired 2018‑05‑04 ("Expired – Lifetime"), so this is necessarily a retrospective validity analysis — relevant, for example, to the recorded D. Del. case 1:14‑cv‑00574 flagged in my earlier section. I continue to use identifiers literally (US 6,046,979 / US6046979A; application 09/072,148; prior art US 5,381,407; etc.).

Cross‑reference note / minor inconsistency: the full patent text I fetched is timestamped 2026‑09‑12; the task header states the current date as 2026‑04‑26. I flag this rather than silently reconciling it. Nothing in this analysis turns on the difference.

Search‑tool limitation (material to confidence): my session hit its tool‑call ceiling partway through reference gathering. I fully verified the existence and subject matter of the references I rely on below, but I could not exhaustively run the follow‑up searches I wanted (e.g., per‑flow rate‑shaping/GCRA patents, IPX‑specific classification art). Where a reference's filing date matters for its §102(e) status, I say so and flag it as needing verification. I have not fabricated docket facts, application numbers, or dates.

1. Legal framework applied

• Governing test: Graham v. John Deere Co., 383 U.S. 1 (1966) — scope/content of the claims, differences over the prior art, level of ordinary skill, and secondary considerations.
• Controlling refinement: KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007) — a claimed combination is obvious where the elements were known, the combination does no more than yield predictable results, and some articulated reasoning with rational underpinning supports combining. A rigid TSM test unsupported by the field is error.
• Examiner rationales: MPEP § 2143 and § 2144.01 — including (A) known elements combined to yield predictable results; (B) simple substitution of one known element for another; (C) use of a known technique to improve similar devices in the same way; (D) applying a known technique to a known device ready for improvement; (F) design incentives and other market forces.
• Applicant's own admissions: statements in the specification describing what "prior art devices" did are usable as evidence of the state of the art. Riverwood Int'l Corp. v. R.A. Jones & Co., 324 F.3d 1346 (Fed. Cir. 2003); MPEP § 2129.
• Means‑plus‑function claims: claims 5–8 invoke § 112 ¶ 6; the claimed functions are compared against the prior art, with the corresponding structures identified from FIG. 10 (Table Look‑up Unit 204, Time Compare Unit 208, Credit Bucket Management Unit 212). MPEP § 2183.
• Materiality of unclaimed spec detail: the claims recite no bit widths, no "fuzz" function, no 32‑byte block size, no linked‑list structure, no GUI. Under In re Self, 671 F.2d 1344 (CCPA 1982), advantages flowing from unclaimed subject matter cannot overcome a prima facie obviousness case. This is decisive against several likely non‑obviousness arguments (developed in § 7).

2. Level of ordinary skill in the art (POSITA)

A bachelor's degree in electrical engineering or computer science, or equivalent, plus roughly two to five years of experience in packet‑switched networking — specifically Ethernet/TCP‑IP switching and routing, ATM/leaky‑bucket traffic policing, and the design of ASIC‑based packet‑forwarding engines. This is modest, ordinary skill for a 1998 filing by a switch vendor (the applicant's own architecture, FIG. 3/FIG. 10, assumes exactly this skill set).

3. What the claims actually cover (distilled)

Stripped to its essentials, the '979 invention is:

Per‑flow bandwidth policing in a hardware multiport switch, where the policing state (credit bucket, refresh value, timestamp, interval selector) is stored in the same forwarding‑table entry that is indexed by L3/L4 header fields, and where credit consumption is measured in fixed‑size blocks derived from the variable‑length packet.

Every element of that sentence is either a known algorithm (leaky/token bucket), a known addressing scheme (5‑tuple classification), a known architectural goal (wire‑speed forwarding), or a design choice the specification itself concedes is arbitrary. The analysis below shows why.

4. Prior art references relied upon

Additionally, and purely as background on the ordinary level of skill (not as primary references): token/leaky‑bucket policing and Generic Cell Rate Algorithm parameters were standardized (IETF RFC 1363's flow specification, 1992; ATM Forum UNI GCRA), fair‑queuing and per‑flow state management were well known in the 1989–1995 literature, and by 1998 the IETF Integrated Services/RSVP work — which the '979 specification itself calls "emerging resource reservation protocols" — assumed per‑flow classification and policing at routers.

5. Combination grounds, with motivations

Ground 1 — Chao + the FIG. 2 admitted prior‑art device → claims 1, 2, 9, 13

Rationale (KSR/MPEP 2143 (A), (C), (D), (F)). Both references are in the same field (packet‑switch traffic control) and address the same problem (limiting a flow's bandwidth consumption). The FIG. 2 device already receives variable‑length Ethernet/TCP‑IP packets, extracts L3/L4 headers, looks up application protocol information in databases 40, and applies flow controls packet‑by‑packet. Chao already supplies the credit/leaky‑bucket mechanism with a per‑connection credit store and a drop‑on‑exhaustion rule. The only thing the combination lacks is putting Chao's bucket into the FIG. 2 device's per‑flow database entry — which is the natural organization, since that entry is precisely the per‑flow record the device already maintains.

Motivation is supplied by conceded market forces (MPEP 2143 (F)): the specification itself states the demand for QoS delivery of data/voice/video over TCP/IP and that "network devices need to be able to control network traffic on a flow‑by‑flow basis." And it supplies the design incentive (KSR: "design incentives … market forces"): the FIG. 2 architecture is criticized because it is software on a multipurpose processor and therefore too slow relative to link bandwidth. That criticism is itself a reason to move the same lookup‑and‑police functions into dedicated hardware.

Limitation‑by‑limitation map (claim 1):

Answer to the anticipated "Chao is ATM‑only" argument. Chao's VCI addressing and 53‑byte cell orientation are indeed protocol‑specific — the '979 specification says so, and I accept that Chao alone does not anticipate. But for § 103 the question is not whether Chao is an Ethernet reference; it is whether adapting a known policing algorithm to a known, ready‑for‑improvement TCP/IP switch would have been within the ordinary skill. It plainly would: the specification itself concedes the leaky bucket is "well known," and that the credit supply is the only thing controlled. Chao does not disparage variable‑length traffic, and it is not "teaching away" merely because it happens to be an ATM patent. That is a § 102 point, not a § 103 point.

Answer to "packets are not released incomplete" / block granularity. The '979 switch already segments variable‑size packets into fixed‑length switching blocks (its own IPP description). Metering credits in units of those blocks is a simple substitution (MPEP 2143 (B)) with the predictable consequence the specification concedes: rounding to the nearest block produces over/undercounting that "will tend to zero for a flow of randomly variable sized packets."

Ground 2 — + Bustini (US 5,313,454) → the drop/tag alternative and credit refresh

Where the claim recites the alternative of dropping or tagging with an adjusted priority, Bustini's expendable/discard‑eligibility indicator — encoded in the cell header and used to discard marked traffic under congestion — supplies the second alternative. Where a claim recites alternatives, a reference teaching one alternative satisfies that element for the purposes of a § 103 rejection, and Bustini plus Chao supply both.

Ground 3 — + EP 0 691 768 → claims 3, 14, 15, 17, 19 (timestamp / interval expiry / refresh)

Claim 3's core is: compare the packet's arrival time to the last time the flow's entry was accessed; if the interval expired, refresh the bucket; then compare the bucket to the packet. This is nothing more than the standard per‑flow state‑update discipline for a leaky bucket that avoids maintaining one hardware timer per flow — a single shared clock plus a stored timestamp, which is why the technique was ubiquitous. EP 0 691 768 is directly on point: it addresses "the leaky bucket operation within the high‑speed data transmission network" and the problem of comparing two timer values to determine elapsed time, including timer wrap‑around.

Critically, EP 0 691 768's use of the two most significant bits of the timer to partition the counter range into intervals is material to claim 13's "time select vector that indicates significant bits of a system counter." Selecting high‑order bits of a counter to define a coarse interval is a known technique, and under In re Kuhle, 526 F.2d 553 (CCPA 1975) and In re Rose, choosing a particular bit position or width is a design choice within the skill of the artisan.

Ground 4 — + US 5,956,721 and WO 97/05727 → claim 1/13's multi‑field search step

Claim 1's search is "based on TCP or UDP information, and internet protocol, IP, or internet packet exchange, IPX, information." Multi‑field classification of packets on the concatenated header tuple (IP source/destination + protocol + TCP/UDP ports) was established art: US 5,956,721 builds reference patterns from destination address + destination port and provides priority arbitration among overlapping classifications; WO 97/05727 maintains connection records keyed by ip_src, p_src, ip_dst, p_dst, proto. Each is a "known technique to improve similar devices in the same way" (MPEP 2143 (C)).

Ground 5 — ASIC integration → claims 5, 6, 7, 8

Claim 5's "means … formed in circuitry that is specific to packet flow control" and claims 6–7's single‑ASIC/direct‑memory‑connection limitations rest on the proposition that implementing known forwarding and policing functions in dedicated hardware is inventive. It is not. The applicant's own specification gives the reason: a multipurpose processor running application‑specific software is too slow relative to link bandwidth, creating "bottlenecks." Dedicated logic for wire‑speed forwarding was the defining engineering trend of the period, and the '979 architecture (IPP/OPP ASICs feeding a data‑path multiplexer) is a textbook instance. This is KSR rationale (D) — applying a known technique to a known device ready for improvement — with a reasonable expectation of success supplied by the fact that Chao's policing was already realized in hardware credit units and registers.

Claim 8's "means for selecting bits from a system counter" is a multiplexer — the specification says so itself (elements 194/196). Reciting a MUX as a "means for selecting bits" cannot confer patentability.

6. Consolidated claim chart

7. Anticipated non‑obviousness arguments — and why they likely fail

1. "Chao is ATM/fixed‑cell and VCI‑based, so the combination is improper." This conflates § 102 with § 103. Chao discloses the policing mechanism; the FIG. 2 device discloses the variable‑length TCP/IP L3/L4 switch. Combining a known enforcement mechanism with a known classification front end to police variable‑length flows is a predictable result. There is no teaching away — Chao neither criticizes Ethernet nor disclaims variable‑length traffic.

2. "The specific bit widths (4‑bit time‑select, 10‑bit timestamp, 14‑bit bucket, 12‑bit refresh) are inventive." In re Kuhle, In re Rose; and fatally, the specification itself: "the exact number of bits and the exact number of counter groups are not critical to the invention" and "other bit lengths can be used while balancing the tradeoffs between more accuracy with more bits or less accuracy with fewer bits." An admitted tradeoff is the antithesis of a nonobvious design.

3. "The 'fuzz' function overcomes wrap‑around and is a novel contribution." Not claimed — no claim recites it. Under In re Self, it cannot rebut prima facie obviousness. Separately, EP 0 691 768 already addresses timer wrap‑around in a leaky‑bucket context.

4. "Use‑it‑or‑lose‑it (and the tandem peak+average variant) produce unexpected results." The specification presents these as deliberate, understood alternatives with stated costs ("may cost more bits … and more embedded hardware devices," "may result in enforced rate limits being less than the rate specified"). That is a recitation of expected tradeoffs, not unexpected results.

5. "Wire‑speed L4 policing was a breakthrough." Speed of execution is the classic non‑entitled consideration; the specification attributes the gain to moving known functions from software to an ASIC — a well‑motivated engineering choice (KSR rationale (D), (F)), not an inventive contribution.

6. "Secondary considerations — commercial success / the 2014 litigation." No evidence of record is before me tying any commercial success to the claimed combination, and no nexus is established. The patent was asserted only in the 2014 window (D. Del. 1:14‑cv‑00574, parties and outcome not verified in my earlier sections) and expired 2018‑05‑04. Long‑deferred, near‑expiry assertion is weak, non‑nexus evidence at best.

Note on the patent's strongest point. The one element that is genuinely architecture‑level rather than algorithmic — storing the policing state inside the L3/L4 forwarding entry, indexed by application protocol, so that classification and metering happen in one lookup at wire speed — is the closest thing to a real insight, and it is where a patent owner would focus. But it is squarely answered by obviousness rationale (A): the FIG. 2 device already maintained per‑flow L3/L4 records and applied per‑packet flow controls; Chao already kept per‑connection credit state in memory; a POSITA seeking wire‑speed policing would naturally merge the meter into the record it already had to fetch.

8. Bottom line

• No single reference anticipates. Chao lacks variable‑length/L4‑indexed operation; the FIG. 2 device lacks any bucket; WO 97/05727 and US 5,956,721 lack bandwidth metering. I am not asserting § 102.
• Claims 1, 2, 9, and 13 are prima facie obvious over Chao in view of the FIG. 2 admitted prior‑art device, further in view of US 5,956,721 and/or WO 97/05727 for the multi‑field classification step, and US 5,313,454 for the drop‑or‑tag alternative.
• Claims 3, 10, 14–17, and 19 are prima facie obvious with the addition of EP 0 691 768 A1 (leaky bucket with timer/date comparison and wrap‑around handling) for the timestamp/interval‑expiry/refresh limitations.
• Claims 5–8 are prima facie obvious treating the § 112 ¶ 6 functions against Chao + FIG. 2, with the ASIC‑integration limitations answered by KSR rationale (D) and the MUX‑as‑"selecting means" limitation of claim 8 being a known element.
• Claims 4, 11, 12, and 18 are prima facie obvious as design choices (In re Kuhle, In re Rose) and known bucket variants.
• Relative strength of a validity challenge: weakest — claims 2 and 12 (admitted art; classic accumulating bucket) and claim 8 (a MUX). Strongest for the patent owner — claim 1 as a whole, because it requires the conjunction of L4‑indexed classification with a bandwidth‑consumption‑limit test and a drop/tag outcome, which no single reference discloses. Even there, a KSR‑grounded combination rejection should be sustainable.

9. Verification gaps I am explicitly flagging

1. US 5,956,721's filing date is needed to confirm pre‑AIA § 102(e) status relative to 1998‑05‑04. I verified its content but not its application/filing date. If it post‑dates the '979 filing, it remains probative as evidence of the level of ordinary skill or as a § 102(a) reference only if published earlier — do not rely on its 102(e) date without confirming in Patent Center.
2. I hit the search‑tool ceiling before I could pull additional per‑flow rate‑shaping references (e.g., GCRA/dual‑leaky‑bucket and per‑flow queuing patents) that would likely strengthen Grounds 1–3. Their absence here is a limitation of my session, not a conclusion that none exist.
3. No PACER/docket‑verified facts are asserted; the 2014 case remains unverified as to parties and outcome per my earlier sections.
4. I have not verified the full text (as opposed to search excerpts) of US 5,313,454 and EP 0 691 768 A1; my characterizations are drawn from verified excerpts and should be re‑checked against full documents before being placed in a formal invalidity contention.