US 7310309

I'll verify against live sources before summarizing.

Verification note

I ran two live searches: a patent-text search for 7310309 / "Dynamic rate limiting adjustment" / Foundry Networks, and a separate search for 7310309 + CAFC 2026 dockets. The first returned the Google Patents and Justia records for US 7,310,309 (and its two continuations). The second returned no Federal Circuit or USPTO post-grant docket referencing 7,310,309 — results were unrelated documents that merely contained the digit string. Caveat below.

US 7310309 — bibliographic summary

Abstract (as printed): "Dynamic rate limiting adjustment may be provided by sampling actual output rates from a rate limited device and utilizing this information to modify configured traffic limits. This allows the device to achieve actual output rates much closer to the desired rate limits for users and services."

Core mechanism (specification): A credit-based hardware component (up to 128 traffic classes per chip) plus a software component. Software computes an initial credit count C per time interval from a configured rate R_c, and a "dynamic rate adjustor" samples the actual average output rate R_s every Δt seconds, computes Δc from Δr = R_c − R_s, and re-issues C + Δc to the hardware. Two hardware modes are described: fixed mode (unused credits at interval end are lost; counter reset to C) and accumulated mode (unused credits carry over; C added to the running counter). Packets are charged credit based on packet size ÷ credit size C_s and dropped when the counter goes below zero.

Plain-language overview of the independent claims

Group 1 — Feedback-loop method/apparatus (broadest formulation)

• Claim 1 (method). Implement a rate limit on the incoming traffic of a traffic type; sample the outgoing traffic to get an outgoing rate; then repeat both steps with a new rate limit chosen to shrink the gap between the configured rate limit and the measured outgoing rate. This is the closed-loop core: police inbound, measure outbound, retune.
• Claim 26 (apparatus). A traffic-type rate limit receiver, an incoming-traffic rate limit implementer coupled to it, and an outgoing traffic sampler; the apparatus is configured to repeat implementing/sampling with a new rate limit that reduces the configured-vs-actual difference.
• Claim 36 (apparatus, means-plus-function). Same three functions expressed as means: means for implementing the rate limit on incoming traffic, means for sampling outgoing traffic, means for repeating with a different rate limit that reduces the difference.
• Claim 49 (program storage device). The claim 1 method embodied as computer-readable instructions.

Group 2 — Credit-arithmetic methods (fixed vs. accumulated mode)

• Claim 14 (method, "fixed mode"). Uses a credit number C per interval (each credit = C_s bits; R_c = C·C_s·N_i). Each interval: set counter = C. Each packet: packet size ÷ credit value = credits owed; subtract from counter; drop if counter < 0. Then sample outgoing rate R_s over a period of N_i intervals, recompute C = C + (R_c − R_s)/(N_i·C_s), and repeat everything with the recomputed C.
• Claim 20 (method, "accumulated mode"). Reset the counter; each interval add C to it (carryover); same per-packet divide/subtract/drop logic. Sample R_s, recompute C by the same formula, and repeat including the reset. (Note: the printed preamble recites "wherein R_s = C·C_s·N_i," whereas the parallel claims 14/30/33 recites "R_c = C·C_s·N_i." I am reporting this literally rather than correcting it.)
• Claim 52 (method). The credit-based fixed-mode body (counter set equal to credits per interval, divide/subtract/drop) folded into the claim 1 style — implement on incoming traffic, sample outgoing, repeat with a new rate limit.
• Claim 54 (method). Same as claim 52 but with the accumulated-mode body (reset counter, add credits each interval).
• Claim 50 (program storage device). Fixed-mode credit method as instructions; packet handling plus recompute-and-repeat. (Printed text recites "R_s = C·C_s·N_i" in the preamble.)
• Claim 51 (program storage device). Preamble says "using a fixed mode," but the body recites the accumulated-mode steps (reset counter; add C each interval; divide/subtract/drop; sample R_s; recompute C; repeat). (A literal reading of the printed claim shows this fixed/accumulated mismatch; noted, not corrected.)

Group 3 — Credit-arithmetic apparatuses

• Claim 30 (apparatus, fixed mode). Functional blocks: traffic type credit number receiver; counter setter (counter = C each interval); packet-size-by-credit-value divider; packet-credit-value-from-counter subtractor; packet dropper (counter < 0); outgoing traffic sampler producing R_s over N_i intervals; and a credit number recomputer that computes C = C + (R_c − R_s)/(N_i·C_s), with the sequence repeatable.
• Claim 33 (apparatus, accumulated mode). Same architecture, but with a counter resetter and a credit-number-to-counter adder in place of the counter setter; same sampler and recomputer, same repeat.
• Claim 56 / 58 (apparatus). The claim 26 architecture (receiver + implementer + sampler + repeat) with the fixed-mode (56) or accumulated-mode (58) credit-handling logic built into the implementer.
• Claim 60 / 62 (apparatus, means-plus-function). The same claim 26-style means structure with the fixed-mode (60) or accumulated-mode (62) credit logic inside the "means for implementing."

Common dependent-claim themes: rate limit expressed as credits/interval × bits/credit (claims 2–3, 37–38); forwarding when counter ≥ 0 (5, 7, 16, 22, 32, 35, 40, 42, 53, 55, 57, 59, 61, 63); sampling by measuring bits output per interval (8, 43); new-rate-limit determination by subtracting sampled bits ÷ bits-per-credit and adding the difference (9, 29, 44); traffic type tied to a port (11, 17, 23, 46), an outgoing queue for a port (12, 18, 24, 47), or an ACL-group-defined flow pattern (13, 19, 25, 48); sending the rate limit/credit number to a rate limiting component (10, 15, 21, 27, 31, 34, 45).

Family, citations, and related publications

• Continuations claiming the 2002-07-17 priority: US 11/998,654 → US 7,724,662 B2 (filed 2007-11-30) and US 12/760,537 → US 7,990,864 B2 (filed 2010-04-14). Published relatives: US 2008/0089232 A1 and US 2010/0208589 A1.
• Note the continuation US 7,724,662 B2 appears to carry a differently worded independent apparatus claim (an apparatus comprising an incoming traffic rate limit implementer and an outgoing traffic sampler, with dependent claims reciting network traffic and "a network switch or a network router"). That is a separate patent from 7,310,309; its claims should not be attributed to 7,310,309.
• Prior art cited on the face of 7,310,309: US 6,046,979 A (Cabletron Systems); US 2003/0035374 A1 (Carter); US 2003/0223369 A1 (Anderson); US 2003/0223370 A1 (Jain); US 2003/0227872 A1 (Tundlam).
• Selected third-party forward citations include US 2008/0062873 A1 (Alcatel, credit-based rate control) and US 11,252,091 B1 (Juniper Networks, "Updating a traffic rate limit for policing traffic").

Litigation / 2026 docket status — and uncertainties

• I found no CAFC 2026 docket entry, and no USPTO post-grant proceeding (IPR/PGR), involving US 7,310,309. Search results for "7310309 + CAFC 2026" were false positives (unrelated documents containing that digit string, e.g., a German admissions list and 2026 Federal Circuit newsletters covering other patents such as 10,755,409, 10,681,109, and 10,155,981).
• Confidence limits. My search was a general web search, not a direct query of USPTO Patent Center/PAIR APIs, the PTAB docket, or the CAFC CM/ECF docket. I cannot certify the absence of 2026 litigation or post-grant activity; I can only state that nothing surfaced. A definitive check would require those primary docket systems.
• Status date caveat. The Google Patents record lists "Expired – Lifetime" with an adjusted expiration of 2025-03-20, i.e., the patent is expired on its face. If it is expired, any 2026 CAFC docket activity would be unusual (though an expired patent can still be litigated for past damages within the § 286 six-year lookback window).
• Two literal-text anomalies flagged above (claim 20 and claims 50/51 stating "R_s = C·C_s·N_i" where parallel claims state "R_c"; claim 51's "fixed mode" preamble with accumulated-mode body) are reported as printed. They may reflect prosecution-era typographical drafting rather than substantive intent, but under the strict no-auto-correction rule I have not rewritten them.

I'll search for litigation involving US patent 7310309.

Let me search more targeted litigation databases and sources.

Litigation Search Results: US Patent 7,310,309

Bottom line

Based on my searches of patent litigation resources (Google Patents litigation/citation data, RPX insight litigation documents, Justia federal docket repositories, CAFC/N.D. Cal. filings surfaced via the search, and general web searches), I found no litigation — no district court action, no CAFC appeal, no ITC Section 337 investigation — in which US 7,310,309 ("Dynamic rate limiting adjustment") was asserted or challenged.

I could not directly reach the Unified Patents litigation caselist or PACER with the tooling available, so this conclusion rests on the secondary sources above (the Google Patents page for US 7,310,309, which lists only patent citations and family members, not litigation), plus targeted searches for the patent number and for its owners (Foundry Networks, Brocade, Avago/Broadcom). No smoking-gun docket appeared.

Important caveat on an easily-confused patent

One result set (Brocade Communications Systems, Inc. / Foundry Networks, LLC v. A10 Networks, Inc., N.D. Cal. Case No. 5:10-cv-03428, filed Aug. 4, 2010, Judge Lucy Koh) prominently asserts a patent referred to throughout the filings as "the '009 Patent." That is US 7,581,009 ("Global Server Load Balancing" — a continuation of US 7,454,500), not US 7,310,309. Per your instruction to interpret identifiers literally, these are distinct patents:

• US 7,581,009 — "Global Server Load Balancing" (Asserted in Brocade v. A10, CV10-03428, along with '500, '629, '301, '678, '185, '427, '370, '195, '833, '965, '508, '977.)
• US 7,310,309 — "Dynamic rate limiting adjustment" (the patent at issue here) — not identified as asserted in that case.

So the Brocade v. A10 litigation should not be reported as litigation involving US 7,310,309. I flag it only to prevent a mistaken match.

Summary table

Notes on why litigation is plausible but unconfirmed

US 7,310,309 issued Dec. 18, 2007 to Foundry Networks (inventor Fan Xu), and passed through the Foundry → Brocade → Avago/Broadcom chain (per the Google Patents assignment history). Foundry/Brocade were litigious against A10 Networks in the early 2010s, so a '309 assertion would be plausible — but I have no evidence it was ever asserted, and the patent is now expired (no longer in force; adjusted expiration 2025-03-20), which reduces the likelihood of recent enforcement.

What I could not verify

• Direct Unified Patents / PACER / Docket Navigator confirmation (tools could not reach those portals).
• Any ITC Section 337 complaint referencing US 7,310,309.

Recommendation for a definitive answer: run the patent number through Unified Patents' litigation caselist (https://portal.unifiedpatents.com/litigation/caselist), Docket Navigator, or Lexis CourtLink/Westlaw KeyCite, which index district court, ITC, and CAFC activity directly. If those return nothing for 7,310,309 specifically, the correct statement is that no litigation is known involving this patent.

I am not representing that no litigation exists — only that none appeared in the sources I could search. If the exact patent number cannot be independently confirmed via those databases, that uncertainty should be stated rather than assumed.

AIA Trial Proceedings — US Patent 7,310,309 ("Dynamic rate limiting adjustment")

Analyst note on sourcing. The structured "PTAB proceedings on file" block in the prompt is the canonical list from the USPTO Open Data Portal, and it reports no AIA trial proceedings for US 7,310,309. I ran independent web searches against PTAB E2E content, PTAB petition PDFs (ptacts.uspto.gov), and third‑party PTAB dockets to surface anything the ODP ingest may have missed. Those searches identified no IPR, PGR, or CBM involving US 7,310,309 by any petitioner, and no Federal Circuit appeal arising from such a proceeding. Details and the near-miss false positives I ruled out are listed at the end.

Proceedings overview

Total AIA trial proceedings on US 7,310,309: 0 — zero active, zero claims invalidated, zero claims sustained, zero settled, zero institution denials. The patent has never been challenged at the PTAB. The defensive posture is therefore not "hardened by surviving IPRs" and not "claims canceled — no case." It is a third, less common posture: untested at the Board, but also expired and largely bereft of forward-looking value. A defendant today is not facing a hardened patent; it is facing an old, narrow, expired-since-2025-03-20 patent whose only remaining leverage is pre-expiration back damages — and a $0 PTAB record that offers neither a ready-made invalidity roadmap nor any § 315(e) estoppel protection to build on.

Proceedings detail

None to report. There is no proceeding to place "most-impactful first," because there are no proceedings.

For completeness, the family members that could independently have attracted challenges also show no AIA activity in the sources reviewed:

(Family/continuation data drawn from the Google Patents family table for US7310309B1: https://patents.google.com/patent/US7310309/en)

Strategic summary

Claim status: 100% UNTESTED, and all 63 claims now expired. Claims 1–63 of US 7,310,309 stand exactly as issued on 2007-12-18. Nothing has been canceled in an AIA trial, nothing has been confirmed, nothing has been narrowed by certificate of correction, reexamination, or reissue that I could locate. There is no claim-level PTAB disposition to quote, and I will not invent one. The only "narrowing" of consequence is temporal: the patent's adjusted expiration is 2025-03-20, and the two continuation patents (US 7,724,662, US 8,990,864) are likewise expired. Practically, this means (a) no injunctive relief is available going forward, (b) damages are confined to the six-year lookback before the complaint (§ 286) and to the pre-expiration window, and (c) because PGR is limited to first-inventor-to-file patents, PGR was never available for this pre-AIA (2002 filing) patent, and CBM review was sunset for new petitions on 2020-09-16 — so IPR was the only realistic AIA vehicle, and nobody used it.

Estoppel landscape: essentially empty, which cuts both ways. No petitioner has been through an instituted IPR, so no one is subject to § 315(e)(2) estoppel on these claims — a current defendant retains the full universe of § 102/§ 103 prior-art grounds (patents and printed publications) for an IPR, subject only to the § 315(b) one-year bar running from service of an infringement complaint. That is the upside. The downside is that the absence of a prior IPR means there is no adjudicated invalidity record, no Board claim constructions, and no expert record to borrow — any challenge must be built from scratch, and the File History and the asserted prior art would need to be assembled cold. A defendant with a real defense should also weigh that on an expired patent the Board is frequently a poor economic fit (no prospective relief to enjoin; amendment unavailable to the patent owner because the term has run), and that a district-court § 102(b) on-sale/public-use theory — unavailable in an IPR — may be the more potent route.

Pattern signals: none of the usual troll/aggregator markers. There is no repeat petitioner, no serial IPR family, no Unified Patents or other defensive-aggregator involvement that I could find, and no Patent Owner appeal to the Federal Circuit because there is no Board decision to appeal. The patent originated with Foundry Networks, Inc. (assignment recorded 2002-07-17; inventor Fan Xu), passed by name change to Foundry Networks, LLC (2010-07-21), then through the Brocade security-interest chain, and via the 2018-10-18 Brocade-to-Avago assignment now lists Avago Technologies International Sales Pte. Ltd. as current assignee, with Foundry Networks LLC also appearing. That is an operating-company/acquired-portfolio provenance, not an NPE assertion pattern — consistent with, though not proof of, why no IPR was ever filed. Separately, I could not confirm that the '309 patent was ever asserted in the Brocade/Foundry enforcement campaigns (e.g., the Brocade v. A10 Networks matter in N.D. Cal. asserted other Foundry/Brocade patents such as the '833 patent); treat any assumption that '309 was litigated as unverified.

Recommended next steps

If you are a defendant being asserted against today:

1. Lead with expiration and § 286. Google Patents records the adjusted expiration as 2025-03-20; the two continuations are expired as well. Confirm the expiration date against USPTO Patent Center / the patent's prosecution and maintenance record before relying on it, since an "adjusted expiration" is a computed term (the ODP/Google entry expressly frames legal status as an assumption, not a legal conclusion). If expiry holds, the case is a damages-only, backward-looking dispute capped by the six-year lookback.
2. Say plainly what the record shows: "There is no PTAB proceeding on US 7,310,309" — I searched and found none. Do not represent to a court or adversary that any claim of '309 has been invalidated; no claim has been canceled by anyone.
3. Preserve your IPR option if you were served within the last year. § 315(b) gives you one year from service of a complaint alleging infringement. Because there is no prior FWD, there is no statutory estoppel against you, and you are free to run § 102/§ 103 grounds on patents and printed publications. If the one-year window has already closed, IPR is time-barred and your invalidity case must go to the district court.
4. Build the invalidity record yourself. The natural candidates are the pre-2002 credit/leaky-bucket rate-limiting art cited on the face of the patent and its siblings — including US 6,046,979 (Cabletron) and the published applications US 2003/0035374, US 2003/0223369, US 2003/0223370, and US 2003/0227872 (Google Patents citation list for US7310309B1) — plus the Foundry JetCore/NetIron "fixed rate limiting" and "Adaptive Rate Limiting" product documentation. Note the timing trap: the Foundry configuration/management guides I located are dated Jan. 2006 and © 2006, i.e., after the 2002-07-17 filing date, so those particular documents are not § 102(b) prior art; earlier product releases and manuals would need to be dated and authenticated. Treat the device-art route as a district-court § 102(b) theory, not an IPR theory.
5. Where to look for confirmation of anything in this report: USPTO PTAB E2E / PTAB Decisions for any AIA case, USPTO Patent Center and the Assignment recordation system for the expiry and chain of title, and CourtListener / the Federal Circuit docket for any appeal. I have no specific opinion or docket URL to cite for a proceeding on this patent, because there is no proceeding.

Verification trail (what I searched, and what I ruled out)

• Queried for "US7310309 IPR / PTAB," "'7,310,309' IPR petition," and "'7,310,309' dynamic rate limiting adjustment IPR/CBM/PGR," plus a PTAB-docket-specific query. No proceeding on this patent surfaced.
• Ruled out as confused-prior-art false positives (these are different patents with similar numbers, and I do not treat them as proceedings on '309):
  • US 7,310,929 — agricultural merger patent; subject of Inter Partes Review of U.S. Pat. 7,310,929, IPR2016-00926 (a same-number-family typo trap; unrelated art).
  • US 7,611,309 — ABS Global, Inc. v. Cytonome/ST, LLC, IPR2017-02161 (microfluidic sheath flow); unrelated.
  • US 9,789,731 — HS Hyosung Advanced Materials Corp. v. Kolon Industries, Inc., IPR2025-00662 (polyester tire cord); unrelated.
• Confidence statement: I have high confidence that no AIA trial proceeding is on file for US 7,310,309, based on the ODP-derived structured block plus the searches above. I have lower confidence about the precise expiration date (2025-03-20) and about whether the patent was ever asserted in district court, and I flag both as unverified rather than asserting them as fact. If a proceeding on this patent does exist outside the sources reviewed, it would most likely be a very recent filing not yet indexed — but nothing in the searches supports that, and I would not invent a number for it.

I'll research the assignment record for US 7310309, focusing on reel/frame data, correspondents, and the ownership chain.

I was able to reach the general web but not the USPTO Assignment Center / Assignment Search (assignmentcenter.uspto.gov, assignment.uspto.gov), PlainSite's assignment detail pages, or PACER before exhausting my tool budget. That materially limits this report: I can reconstruct the chain from the Google Patents legal-events record (which is derived from the same USPTO assignment data), but I could not retrieve reel/frame numbers, execution dates, or correspondents of record for the '309 patent's own assignments. Rather than fabricate any of those fields, I have marked each one as not retrieved and told you exactly where to pull it. This is a data-availability limitation, not an absence of records — the patent does have a recorded chain.

Inventors

Unusual-pattern check. The prompt flags "all inventors departing the original assignee within 12 months of filing." There is only one inventor here, so the multi-inventor departure pattern does not apply. I found no evidence of when Fan Xu left Foundry (or whether he did), so I cannot confirm or rule out a near-filing departure. Finding: not determinable / no signal. Nothing in the record suggests a pre-fire-sale inventor exodus.

Original assignee

The issued patent's original assignee is Foundry Networks, Inc. — the 2002-07-17 assignment to that entity is the first recorded link in the chain.

Literal-text discrepancy to flag (per your no-auto-correction rule): Google Patents renders the filing event as "Application filed by Foundry Networks LLC," while the assignment event on the same date names "FOUNDRY NETWORKS, INC." Foundry Networks, LLC did not exist in 2002 — it is the post-2010 name-change successor. The "LLC" in the filing event is therefore an anachronistic database normalization, and the correct 2002 assignee is Foundry Networks, Inc. I am reporting both as printed rather than silently harmonizing them.

• Primary line of business: high-end Ethernet switches and routers for enterprises and service providers — product families BigIron, FastIron, NetIron, ServerIron, IronPoint, SecureIron, and the XMR chassis (per the Foundry Networks corporate history). Rate limiting / traffic policing is a standard QoS feature of exactly this class of gear, so the '309 claims plausibly read on Foundry's shipped switch/router line (the spec itself is written around per-port and per-queue rate limiting on a "web switch"). I did not independently confirm a specific SKU practicing the claims.
• Current status: Acquired / absorbed. Foundry agreed on 2008-07-21 to be acquired by Brocade Communications Systems, Inc.; the deal closed 2008-12-18 (Foundry became a Brocade subsidiary and was wound down as a standalone brand). Brocade later reorganized Foundry Networks, Inc. into Foundry Networks, LLC (recorded 2010-07-21, "Change of Name"). Brocade itself was acquired by Broadcom / Avago (completed Nov 2017), and the Brocade-branded networking business was subsequently sold to Extreme Networks — though, per the 2018 assignment below, the patents travelled to Avago Technologies International Sales Pte. Ltd., not to Extreme.

Assignment timeline

Source note. The entries below are the recorded legal events shown on the Google Patents page for US 7,310,309 (https://patents.google.com/patent/US7310309/en), which mirrors the USPTO assignment record. Reel/frame, exact execution date, and correspondent of record were not retrievable with my tooling and are marked "not retrieved" for every entry. I have not invented any reel/frame value. To fill these fields, query https://assignmentcenter.uspto.gov/ (or https://assignment.uspto.gov/patent/index.html) by patent number 7,310,309 and read the "Assignment Abstract of Title" — it will display reel/frame, execution date, and correspondent for each of the 8 links below.

• 2002-07-17 (recorded on/near 2002-07-17) — Reel not retrieved

  • Conveyance: Assignment of assignors' interest (inventor → company)
  • Assignor: Fan Xu
  • Assignee: Foundry Networks, Inc.
  • Correspondent: not retrieved
  • Context: routine inventor-to-employer assignment at filing — not an acquisition or transfer-to-asserter.

• 2008-12-22 — Reel not retrieved

  • Conveyance: Security Agreement
  • Assignor(s): Brocade Communications Systems, Inc.; Foundry Networks, Inc.; Inrange Technologies Corporation; McData Corporation
  • Assignee: Bank of America, N.A., as Administrative Agent
  • Correspondent: not retrieved
  • Context: securitization — collateral pledge securing Brocade's $1.225B credit facility used to fund the Foundry acquisition. Not an ownership transfer; the patent is pledged, not sold. The grant/agent role is consistent with the Oct 7, 2008 Credit Agreement (Cahill represented Bank of America as Administrative Agent) and the Aug 4, 2010 release discussed below.

• 2010-01-20 — Reel not retrieved

  • Conveyance: Security Agreement
  • Assignor(s): Brocade Communications Systems, Inc.; Foundry Networks, LLC; Inrange Technologies Corporation; McData Corporation; McData Services Corporation
  • Assignee: Wells Fargo Bank, National Association, as Collateral Agent
  • Correspondent: not retrieved
  • Context: securitization — second-lien / noteholder collateral pledge in the Jan 2010 secured-notes financing (this is the Jan 13, 2010 offering-memorandum collateral package). Again a pledge, not a conveyance of title.

• 2010-07-21 — Reel not retrieved

  • Conveyance: Change of Name
  • Assignor: Foundry Networks, Inc.
  • Assignee: Foundry Networks, LLC
  • Correspondent: not retrieved
  • Context: internal reorg / change of name only — same corporate owner, new entity form. No change in beneficial ownership.

• 2015-01-21 — Reel not retrieved

  • Conveyance: Release by Secured Party
  • Assignor: Bank of America, N.A. (as Administrative Agent)
  • Assignee(s): Foundry Networks, LLC; Brocade Communications Systems, Inc.; Inrange Technologies Corporation
  • Correspondent: not retrieved
  • Context: lien release — Bank of America releases its security interest; collateral no longer encumbered. Not an ownership change.

• 2015-01-22 — Reel not retrieved

  • Conveyance: Release of Security Interest
  • Assignor: Wells Fargo Bank, National Association (as Collateral Agent)
  • Assignee(s): Foundry Networks, LLC; Brocade Communications Systems, Inc.
  • Correspondent: not retrieved
  • Context: lien release — Wells Fargo releases its security interest. Not an ownership change.

• 2018-10-18 — Reel not retrieved

  • Conveyance: Assignment of assignor's interest
  • Assignor: Brocade Communications Systems LLC
  • Assignee: Avago Technologies International Sales Pte. Ltd. (Singapore; Broadcom/Avago group)
  • Correspondent: not retrieved
  • Context: post-M&A portfolio transfer — this is the only true title transfer after the 2002 inventor assignment, and it is Brocade's parent-level portfolio handoff to Broadcom/Avago (Brocade was acquired by Avago in Nov 2017). This is an operating-company-to-operating-company transfer, not a transfer to an NPE.

• 2025-03-20 — Adjusted expiration (no reel/frame; a legal-status entry, not an assignment)

Net effect: one inventor assignment (2002), two security pledges and their two releases (2008–2015), one change of name (2010), and one corporate M&A assignment (2018). There is no recorded sale of title to a licensing vehicle at any point.

Supporting corroboration (secondary source, could not confirm '309 is on the schedule): a PlainSite assignment record titled "Patent Assignment from Brocade Communications Systems, Inc.; Foundry Networks, LLC; and Mcdata Corporation to Bank of America, NA" (id=7341855) matches the security-agreement parties and timing; I cite it as context for the pledge events, not as proof that '309 specifically appears on that schedule.

Timeline diagram

timeline
    title Ownership of US 7310309
    2002 : Inventor Fan Xu assigns to Foundry Networks Inc
    2007 : Patent issued as US 7310309
    2008 : Brocade closes acquisition of Foundry
         : Bank of America security pledge
    2010 : Wells Fargo collateral pledge
         : Name change to Foundry Networks LLC
    2015 : BofA lien released
         : Wells Fargo lien released
    2018 : Brocade assigns portfolio to Avago
    2025 : Adjusted expiration

NPE / troll-pattern signals

Verdict

Operating-company assertion.

The recorded chain (Google Patents legal events for US 7,310,309 — https://patents.google.com/patent/US7310309/en) is a textbook operating-company lineage: the 2002-07-17 inventor assignment runs to Foundry Networks, Inc.; the 2008 and 2010 events are security pledges to Bank of America and Wells Fargo (not title transfers), later released in 2015; the 2010 event is a change of name to Foundry Networks, LLC; and the sole subsequent title transfer is the 2018-10-18 assignment from Brocade Communications Systems LLC to Avago Technologies International Sales Pte. Ltd., a parent-level M&A handoff. None of the eight NPE signals is present on the evidence available — two consecutive security agreements plus a name change is the opposite of a shell-entity/cascading-LLC pattern. Two honest caveats: (a) I could not retrieve reel/frame, execution dates, or correspondents, so signal #3 (repeat correspondent) is genuinely unclear rather than negative; and (b) the verdict describes the character of the ownership chain — I found no evidence the '309 patent was ever asserted in litigation, and it is expired on its face (adjusted expiration 2025-03-20), so "assertion" is not documented.

Verify at: https://assignmentcenter.uspto.gov/ (search patent 7,310,309 → Assignment Abstract of Title) and https://assignment.uspto.gov/patent/index.html — pull the correspondent field on each record to close out signal #3, which is the only open item.

I'll verify the citations on the face of US 7,310,309 with live searches before mapping them to claims.

I ran the citation lookups against Google Patents, Justia, FreePatentsOnline, and the patentimages PDFs. Note on dates: the task header says April 26, 2026 while the system clock says 2026-09-27; that discrepancy doesn't affect anything below, since all relevance dates are the patent's own 2002-07-17 filing/priority date.

Also, one scope point up front: the "patent citations" on the face of US 7,310,309 are exactly five (confirmed via https://patents.google.com/patent/US7310309/en). Google Patents separately lists seven "Family Cites Families" documents that are cited in the '309 family (i.e., by US 7,724,662 and US 7,990,864, the continuations). I treat those as a second tier, clearly labeled, because they are not face-of-'309 citations — and several of them are at least as relevant to the claims as the five face citations.

I. Statutory framework — which § 102 subsections apply

US 7,310,309 was filed 2002-07-17 and claims no earlier priority. It is therefore a pre-AIA patent, and the pre-AIA § 102 categories govern:

Two consequences worth flagging because they change the answer materially:

1. The three 2002-filed published applications all published after 2002-07-17. They cannot be § 102(a) or § 102(b) art; they are § 102(e)-only art. US 2003/0223369, US 2003/0223370 and US 2003/0227872 all share a June 2002 US filing/provisional basis, which precedes 2002-07-17, so they are § 102(e) references.
2. US 2003/0035374 (Carter) claims a GB priority of 2001-08-08. Under the Hilmer doctrine (pre-AIA), a foreign priority date does not give a § 102(e) date — the § 102(e) date is the US filing date. I could not confirm Carter's US filing date from the records retrieved; treat its § 102(e) date as unverified and likely 2002 (which would still precede 2002-07-17, but must be checked).

II. The five citations on the face of US 7,310,309

Sources: https://patents.google.com/patent/US7310309/en ; http://www.everypatent.com/comp/pat6046979.html ; https://www.freepatentsonline.com/y2003/0035374.html ; https://patentimages.storage.googleapis.com/f4/aa/48/8b45510b12bb82/[US7280476B2](/patent/US7280476B2).pdf ; https://FreePatentsOnline.com/y2003/0223370.html ; https://patentimages.storage.googleapis.com/91/90/a2/f8292cff02d796/US7652988.pdf

Reference 1 — US 6,046,979 A (Bauman et al., Cabletron Systems)

Description. A multiport switch that reads forwarding information out of memory keyed at least partly on Layer 4 packet information, where the forwarding entry carries a bandwidth consumption limit. The preferred implementation is an explicit credit-bucket algorithm: a credit_bucket vector holds the maximum data forwardable in the remainder of the current time interval, a credit_refresh vector holds the credit value restored at each interval, and a time_select/time_stamp pair determines whether the interval has expired. On a forwarded packet the bucket is decremented; on interval expiry the bucket is updated from credit_refresh. A packet is forwarded if within the limit, and otherwise dropped or tagged with adjusted priority. Claim 11 recites "adjusting said preselected time interval or said maximum packet length to change a characteristic of the flow," and claim 12 recites "adding a preselected credit value to said credit bucket indicator each time a preselected time interval has expired."

What it teaches against the '309 claims. It is a near-complete disclosure of the implementing half of the '309 claims — the credit-per-interval accounting, the counter, the compare-forward/drop logic, and per-interval credit refresh — including both a reset-style (fixed) and an add-style (accumulated) refresh. It is silent on the claimed sampling of outgoing traffic and on feeding a rate difference back to modify the credit allotment.

Bottom line: strong § 102(b) art for the credit-accounting subject matter; not an anticipation of any independent claim. Its real value is as the § 103 anchor for a "conventional credit-bucket policer + a known feedback/adaptive control" combination.

Reference 2 — US 2003/0035374 A1 (Carter) — the most relevant of the five

Description. Congestion control by sampling the traffic egressing an output buffer at sequential intervals to determine a bit rate at each interval, computing an autocorrelation-based statistical measure related to long-range dependence, determining whether raising or lowering the scheduler dispatch rate will reduce that measure, and adjusting the dispatch rate accordingly. Claim 1 recites "sampling the output traffic to determine a bit rate at each sample … and adjusting the scheduler dispatch rate so as to reduce the estimated statistical measure." Dependent claims cover successive-sample averages and IP/optical-layer application.

What it teaches against the '309 claims. This is the only one of the five face references that discloses a genuine closed loop: measure the actual egress rate from samples, and change the egress rate setting in response. That maps onto the '309 point of novelty — "sample the outgoing traffic … repeat with a new rate limit chosen to reduce a difference." The two mismatches are (a) Carter's error signal is a long-range-dependence/congestion statistic, not the difference between a configured rate limit and the measured output rate, and (b) Carter's control variable is a scheduler dispatch rate for egress traffic, not a rate limit implemented on incoming traffic.

Bottom line: best § 103 combination reference for the feedback-loop group; a narrow § 102 candidate only for the per-interval output-bit-rate-measurement limitations (8/43).

Reference 3 — US 2003/0223369 A1 (Anderson) / US 7,280,476 B2

Description. Explicitly a credit-bucket (token-bucket) traffic-control mechanism at a network node: "each credit provides permission to forward a certain number of bits"; a fixed number of credits is added to the bucket at fixed time intervals; "to forward a packet, a number of credits equal in bit size to the packet must be removed from the bucket"; if credits ≥ packet requirement, forward; if not, hold or drop. It further teaches accumulation: "Credit buckets continue to accumulate credits even when there is no traffic to forward," capped at a maximum value, and it separately discusses policers (drop) vs. shapers (buffer/delay), per-class implementation, and periodic refresh of all buckets at the same interval.

What it teaches against the '309 claims. This is a clean, express disclosure of essentially the entire "implementing the rate limit" body of the '309 independent claims — including the accumulated-mode behavior (unused credits retained up to a cap) that the '309 characterizes as its two hardware modes.

Bottom line: the best § 102(e) reference for the credit-arithmetic and accumulated-mode limitations; not an anticipation of any independent claim.

Reference 4 — US 2003/0223370 A1 (Jain et al.) / US 7,652,988 B2 — the most dangerous reference

Description. A hardware-based credit-bucket rate controller that (i) lets credits accumulate over multiple time-slices up to a maximum credit limit — expressly contrasted against the "use-it or lose-it" scheme that "allocates a fixed number of credits … at the beginning of each time interval" and loses unused credits; (ii) caps dispatch per time-slice at a maximum drain rate; and (iii) includes a traffic characterization / flow characterization engine that takes multiple samples of the packet traffic, determines actual rates, identifies the traffic as bursty vs. smooth, and a settings controller that changes the refresh rate, maximum credit limit and maximum drain rate in response. Its own background section recites the use-it-or-lose-it scheme and the burst/TCP-retransmission rationale that the '309 specification recites almost verbatim as its motivation.

What it teaches against the '309 claims. Two of the '309's pillars are disclosed here: (a) the "fixed" vs. "accumulated" credit modes, as express alternatives; and (b) sampling the traffic and adaptively changing the rate-control settings in response — i.e., a feedback path, though triggered by a burstiness characterization rather than a configured-rate-vs-output-rate difference.

Bottom line: the highest-value reference of the five — squarely on the fixed/accumulated distinction, on the bursty-TCP problem statement, and on adaptive re-tuning of rate-control parameters. Note for completeness that US 2003/0223370 A1 is itself cited as a § 102/§ 103 reference in later art (e.g. US 10,705,985 B1 and an IPR2021-01469 exhibit), which is a market signal of its perceived strength.

Reference 5 — US 2003/0227872 A1 (Tundlam) — lowest relevance, weaker confidence

Description (title-level only). Hierarchical rate limiting at a network node using an "infinity rate-limit check." I was unable to retrieve the full text or claim set in this pass (search budget exhausted on this item), so I am describing it by title and will not invent element-level mappings. The title indicates a two-level (hierarchical) rate-limiting scheme in which a per-flow or per-class limit is checked against an aggregate/parent limit, with a special "infinity" case handling a limit configured (or computed) as unlimited.

What it teaches against the '309 claims. On its face, hierarchical rate limiting is a different mechanism from a single-level credit counter with an outer feedback loop. None of the '309's independent claims recites hierarchy, parent/child limits, or an unlimited-rate special case.

Bottom line: flag as low-confidence / unverified. Its inclusion on the IDS list is best explained as general rate-limiting background, not as anticipatory art. Before relying on it, pull the full document.

III. Second tier — references cited in the '309 family (US 7,724,662 / US 7,990,864)

These are not face-of-'309 citations, so I present them separately. They are nonetheless the most likely candidates for a real § 102/§ 103 attack, because they were cited against closely-related claims and several are the era's canonical rate-policing patents. All dates are from the Google Patents "Family Cites Families" table for US7310309B1.

Because several of these were filed before 2002-07-17, they carry § 102(e) dates as well as their issue-date § 102(b) significance for later-issued ones. US 7,068,602 B2 ("Feedback priority modulation rate controller") is the single reference I would prioritize for a validity attack on independent claims 1/26/36/49, because it is the only reference in either tier whose title and provenance target the feedback loop directly.

IV. Device / printed-publication art surfaced in related litigation exhibit lists

The searches surfaced Foundry Networks product documentation dates that are § 102(b)-eligible (all before 2001-07-17) and that describe the applicant's own architecture, as listed in the exhibit/IDS sections of US 7,978,614 and US 9,030,943:

• Foundry Networks, BigIron Architecture Technical Brief — Oct. 1998 (v1.0), Oct. 1998 (v1.02), Dec. 1998 (v1.03), May 1999 (v2.0), May 1999 (v2.01), Jul. 2001 (v2.02).
• Mier Communications, Lab Testing Summary Report — Layer-3 Switches, Foundry BigIron 4000, Report No. 231198, Oct. 1998; and Report No. 210998, Sep. 1998.
• The Tolly Group Nos. 199133 (Oct. 1999) and 199111 (May 1999).

Timing warning: the JetCore™ Based Chassis Systems architecture brief is dated 2003-01-17, i.e., after the '309 filing date, and the "Next Generation Terabit System Architecture" document is 2003-11-17 — both cannot be § 102(b) art for '309. The 1998–2001 items can be, if their public availability before 2001-07-17 can be authenticated.

V. Consolidated § 102 mapping and candid bottom line

Candid bottom line: On the records retrieved, none of the five face-of-'309 citations is a clean § 102 anticipation of any of the 16 independent claims (1, 14, 20, 26, 30, 33, 36, 49, 50, 51, 52, 54, 56, 58, 60, 62). Each supplies at most one of the two pillars — either the credit-based implementing body (US 6,046,979; US 2003/0223369; US 2003/0223370) or a measured-output feedback loop (US 2003/0035374), but not the specific combination of implementing on incoming traffic + sampling outgoing traffic + recomputing the credit allotment as C = C + (Rc − Rs)/(Ni·Cs) and repeating. The five citations read most naturally as § 103 combination art — e.g., US 6,046,979 or US 2003/0223369 as the primary credit-bucket reference, combined with US 2003/0035374 or US 2003/0223370 for the adaptive/feedback teaching. If a stronger § 102 position is wanted, the place to look next is the family-cited US 7,068,602 B2 and the pre-2001-07-17 BigIron Architecture Technical Brief releases, not the five face citations.

Confidence and gaps I am not papering over: (1) I could not retrieve the substance of US 2003/0227872 A1 (Tundlam) — its assessment is title-level only and should be treated as provisional; (2) the US filing date of US 2003/0035374 A1 (Carter) is unverified, which affects whether it is § 102(e) art at all; (3) I did not verify element-by-element claim charts against the actual claim language of each reference — the mappings above identify exposure, not a concluded anticipation analysis; (4) the two literal text anomalies already reported for '309 (claim 20's "Rs = CCsNi" preamble, and claim 51's "fixed mode" preamble with an accumulated-mode body) carry through to any validity analysis of those specific claims and I have not corrected them.

I'll pull the details of the five references cited on the face of US 7,310,309 so I can map their teachings element-by-element to the claims.

Good detail on four references. Let me firm up the Cabletron '979 disclosure and check the family-cited references plus any prosecution record.

Obviousness Analysis — US 7,310,309 B1 ("Dynamic rate limiting adjustment")

Scope note. Per instruction, this analysis is built on the prior-art references listed in the Prior Art / Citations section of the Google Patents record for US 7,310,309 (https://patents.google.com/patent/US7310309/en) — specifically the five Citations (5) that appear on the face of the patent, plus the Family Cites Families (7) entries. I do not repeat the bibliographic, litigation, or PTAB sections already generated; where those flagged literal-text anomalies in claims 20/50/51, I carry them forward rather than re-argue them.

Contradiction check. No contradiction found between the previously generated sections and the prior-art record. One item to flag: the earlier sections correctly noted that the patent is expired (adjusted expiration 2025-03-20). That does not change the § 103 analysis, but it changes the venue economics — see § H.

A. Legal framework and the person of ordinary skill

• Statute/version. The '309 has a filing and priority date of 2002-07-17, so pre-AIA 35 U.S.C. § 103 governs, including pre-AIA § 103(c) and pre-AIA § 102(e). Obviousness is judged as of the effective filing date (no earlier priority is claimed on the face of the record).
• POSITA. A person having ordinary skill would hold a B.S. in EE/CS (or equivalent) and roughly 2–4 years of experience in network switch/router datapath design, including packet classification, queuing/scheduling, and token- or credit-bucket policing/shaping, including ASIC register-level control of credit counters. All five references are directed at that same skill set.
• Claim construction posture. Claim 1 is deliberately result-oriented: it recites what the adjusted limit must achieve ("chosen to reduce a difference between the rate limit … and said outgoing traffic rate") but not how the new limit is computed, nothing about the sampler, no threshold, no convergence criteria, and no credit arithmetic. That breadth is central to the obviousness case.
• Key drafting detail for the credit claims. Claims 14/20/30/33 and 50/51 express the adjustment as the discrete control law C ← C + (R_c − R_s)/(N_i · C_s). As shown in § F, that is simply the textbook integral-error form of the increment in credit units.

B. The references of record, with § 102 status and date risk

Family-cited additional references (secondary, unverified by me): US 6,724,721 B1 (Cisco, approximated per-flow rate limiting); US 7,068,602 B2 (PMC-Sierra, "Feedback priority modulation rate controller") — the most interesting unexamined lead for the feedback element; US 7,027,393 B1 (Cisco, TCP-optimized single rate policer); US 6,798,741 B2 (Riverstone, rate shaping); US 7,227,840 B1 (Juniper, probabilistic rate policer); US 7,161,904 B2 (Fortinet, hierarchical metering). I did not retrieve these texts and do not map them to claims; treat them as candidate secondary references only.

Threshold point for the whole analysis. R3, R4, R5 are all Riverstone Networks filings (attorney docket prefix "RSTN-" appears in the Tundlam record; the granted '507 later shows Alcatel-Lucent as owner). They are not commonly owned with the '309 (Foundry Networks), so pre-AIA § 103(c)'s common-ownership carve-out does not shield them — they remain available for § 103 combination provided their § 102(e) dates hold. If the provisional-support dates fail, R5 (and possibly R3/R4) drop out entirely.

C. Element decomposition of the '309 claims

Stripping the apparatus/means/CRM wrappers, the '309 reduces to three functional elements plus two implementation sub-systems:

• E1 — Inbound policing of a traffic type. Implement the configured rate limit on incoming traffic of the traffic type (claims 1, 26, 36, 49, 52, 54, 56, 58, 60, 62).
• E2 — Outbound measurement. Sample the outgoing traffic of that traffic type to obtain an outgoing traffic rate (all independent claims).
• E3 — Closed-loop retune. Repeat E1/E2 with a new rate limit chosen to reduce the difference between the configured limit and the measured outgoing rate (all independent claims; the credit-controlled versions give the specific arithmetic).
• S1 — Credit machinery. Rate limit = credits/interval × bits/credit; per-packet charge = packet size ÷ credit size; drop when the counter goes below zero (claims 2–7, 52, 54; apparatus analogues).
• S2 — Mode selection. Fixed mode (counter reset to C each interval → "use-it-or-lose-it") vs. accumulated mode (reset once, then add C each interval → carryover) (claims 4–7, 14, 20, 30, 33, 50, 51).

The '309's own Background concedes E1+S1 almost verbatim: rates are set by the ISP, "dividing a second into many time intervals, converting the configured rate into credits for each interval, and decrementing the credits for each packet sent or received." That is a § 103 obviousness admission (MPEP 2144.03 / In re Fout style) covering the credit scaffolding. The entire inventive weight therefore sits on E2+E3.

D. Grounds of rejection

Ground 1 — Cabletron '979 (R1) in view of Carter '374 (R2) → claims 1, 2, 3, 8–13, 26–29, 36–49, 52, 53, 56–63

Gap and closure. R1 alone does not disclose a feedback path. R2 alone does not disclose an inbound credit-bucket rate limit for a classified traffic type — its adjustment acts on the egress scheduler. The combination supplies both. The only conceptual delta is R2's objective (minimize a burstiness/LRD measure) versus the claim's objective (reduce the configured-vs-measured difference). That delta is addressed by Ground 3 and by the motivation in § E.

Ground 2 — Jain '370 (R4) in view of Cabletron '979 (R1) → claims 1, 2, 3, 6, 7, 14, 16, 20, 22, 30, 32, 33, 35, 50, 51, 54–59

This is the strongest ground for the mode-dependent claims (6/7/20/22 and the accumulated-mode apparatus claims 33/58/62), because R4 describes both modes and supplies the adaptivity. It is also close to anticipatory for claims 4/5 and 6/7 to the extent R4's Background descriptions of the two schemes are treated as disclosures of known art (see § D.6).

Ground 3 — Jain '370 (R4) in view of Carter '374 (R2), further in view of Cabletron '979 (R1) → claims 1, 26, 36, 49, 52, 56, 60 (the broad loop claims)

This is the combination that most cleanly closes E1→E2→E3 with the "outgoing traffic" wording intact:

• R4 supplies the credit-bucket rate limit on the classified traffic and the "measure actual rate, compare to refresh rate, adjust settings" loop;
• R2 supplies the express step of sampling the outgoing/egress traffic at intervals to determine a bit rate and feeding it back to change the output rate;
• R1 supplies the inbound credit-bucket enforcement framing and the L3/L4 flow classification that R2 lacks.

A POSITA implementing R4's settings controller against R2's egress sampling circuit would arrive at "implement inbound rate limit; sample outbound rate; retune to reduce the difference" without any leap.

Ground 4 — Anderson '369 (R3) in view of Jain '370 (R4) → claims 4, 5, 14, 16, 30, 32, 50, 56, 57, 60, 61

R3 supplies the per-class credit bucket with periodic re-allotment and a per-packet forward/drop decision against the credit value, including credit registers. R4 supplies the adaptive re-allotment driven by measured rate. R3+R4 together read directly onto claim 14's counter/divide/subtract/drop sequence plus the recompute-and-repeat step.

Ground 5 — Tundlam '872 (R5) in view of Cabletron '979 (R1) → the traffic-class dependent claims 11–13, 17–19, 23–25, 46–48

R5's classification hierarchy — P = physical port, Q = subnet, R = protocol, S = socket, plus TOS and L2 field-based classification — covers claim 11 (traffic type = a port) and provides the hardware rule-selection/credit-bucket framework for claim 12 (outgoing queue for a port). R1 supplies L3/L4 flow classification.

⚠️ Weakest link: claim 13 (traffic type "associated by a flow pattern defined by an access control list (ACL) group"). None of R1–R5 retrieved discloses ACL-group-based classification. R1's L3/L4 look-up and R5's TOS/L2 classification are close but not the same thing. A challenger should pair Ground 5 with a contemporaneous hardware-ACL/packet-classification reference (the field was crowded; the family-cited Riverstone/Cisco/Fortinet documents are candidates). I would not assert claim 13 as obvious on R1–R5 alone.

Ground 6 (single-reference / § 102 overlays — noted, not relied on)

• Claims 4 and 5 (fixed mode) map nearly element-for-element onto R4's description of the typical "use-it-or-lose-it" scheme: fixed allotment at the start of each interval, unused credits lost, packet forwarded only with sufficient credits. Whether this is anticipation depends on whether a reference's description of the prior art in its own Background is treated as a disclosure — it can be (In re Fout; MPEP 2127/2129), but the challenger should also plead it as obviousness in the alternative.
• Claims 6, 7, 20, 22 map onto R4's accumulated-mode teaching. The remaining mismatch is R4's sampling being of the traffic associated with the credit bucket rather than the device's outgoing traffic — which is exactly what R2 cures (Ground 3).
• Claims 2/3 (limit = credits/interval × bits/credit; credits are fixed-bit units) are admitted in the '309's own Background plus R1/R3/R4.
• Caveat: R2's and R4's "typical/Background" statements are prior-art descriptions, not claimed subject matter; a defendant should expect the patent owner to attack them as non-enabling or as describing hypothetical rather than actual systems.

E. Why a POSITA would have been motivated to combine (KSR rationales, MPEP 2143)

1. Express teaching/motivation in the art (MPEP 2143(A)(7)). R4 itself frames the problem and the solution: "the parameters of the rate control algorithms … are typically set once and then left alone. This 'set and forget' approach … may not work as well when the traffic pattern tends to be unpredictable." That is a direct invitation to make the credit allotment adaptive at runtime.
2. Known problem, known fix (MPEP 2143(A)(3)–(4)). The '309's own Background identifies the failure mode — bursty arrival, indivisible credit granularity, and TCP back-off drive the actual rate away from the configured rate. The art already contained the cure in the form of closed-loop egress measurement and rate adjustment (R2) and measured-rate-driven credit-setting adaptation (R4). Applying a known feedback technique to a known credit-bucket limiter to yield the predictable result (measured error shrinks) is the paradigm of KSR.
3. Same field, same problem (analogous art). R1 (multiport switch flow control), R2 (router/switch congestion control), R3/R4/R5 (network-node rate control) all address rate/congestion management of packet streams in switches and routers. Combination would not have required importing distant art.
4. Predictable results / design choice. E3 is expressed as a result, not a mechanism. A POSITA implementing E3 on the credit-bucket architecture of R1/R3/R4 would naturally implement the control law as a proportional/integral correction in credit units — which is precisely claim 14's C ← C + (R_c − R_s)/(N_i · C_s). That formula is the algebraic statement of "error in bits/sec ÷ (bits per credit × credit intervals per second) = error in credits per interval." No inventive insight is required; it is routine controller design.
5. Both modes were known alternatives. R4 describes the fixed/"use-it-or-lose-it" scheme as typical and teaches accumulated mode as the fix for bursty traffic. Choosing between them (claims 4–7, 14, 20) is a design choice between known options with predictable trade-offs — the fixed mode tightens conformance, the accumulated mode absorbs bursts.
6. Software/hardware implementation was routine. R2 states the control loop is performed "automatically under the control of software … within a network manager"; R4's settings controller writes class-specific values into credit registers (claim 25 of R4 — structurally identical to the '309's own FIG. 2 register map, 0x1280000–0x1280200). This supplies the "send the rate limit/credit number to a rate limiting component" dependent claims (10, 15, 21, 27, 31, 34, 45) and supports the program-storage-device independent claims (49, 50, 51) under KSR's "known technique applied to a known device."

F. Mapping of the sixteen independent claims

Takeaway: the sixteen independent claims collapse into two vulnerability clusters — (i) the bare loop (1, 26, 36, 49, 52, 54, 56, 58, 60, 62), which is resolved by R4 + R2 (+ R1); and (ii) the credit-arithmetic families (14, 20, 30, 33, 50, 51), which are resolved by R4 (+ R3), because R4 supplies both modes and the measured-rate-driven adaptation, and the recompute formula is routine controller algebra.

G. Where the case is strong, and where a patent owner will fight

Strong.

• E2+E3 as a result-oriented limitation. Claim 1 gives no algorithm, no sampler structure, no threshold. Under KSR, a functional recitation of a desired result achieved by known feedback means is not a patentable advance.
• R4 is nearly a roadmap. Its Background criticizes the fixed/"use-it-or-lose-it" scheme (the '309's fixed mode) and the "set and forget" approach (the '309's stated problem), and its Summary teaches the accumulated-mode fix plus runtime adaptation based on measured rate. Combining R4 with an egress sampler is a small step.
• The '309's own Background admissions remove E1/S1 from the inventive calculus.
• The recompute formula is arithmetic. Claim 14's control law is dimensionally forced once you accept "adjust credits by the rate error"; that defeats any argument that the formula itself is inventive.

Contested.

• R2's objective mismatch. Carter adjusts toward minimizing a burstiness/LRD metric, not toward a configured rate. The patent owner will argue this is a different purpose and cite the '309's stated aim of convergence to the configured rate. Rebuttal: purpose-of-the-inventor arguments are disfavored (KSR; MPEP 2145.X); the claim's own "reduce a difference" language is satisfied by any negative-feedback correction, and R4 supplies the configured-rate reference signal ("actual rate vs. refresh rate").
• "Incoming" vs. "outgoing" traffic. R4's sampler is of the traffic associated with the credit bucket (the policed stream), which in R4's own architecture is incoming to the provider edge. The patent owner will say R4 samples the wrong stream. Rebuttal: R2 supplies egress sampling expressly, and the combination is the point of Ground 3.
• The § 102(e) date exposure. This is the single biggest risk to all of R2/R3/R4/R5 (see § B). If the June 4–5, 2002 provisionals do not support the relied-on disclosure, R3/R4/R5 are not prior art to a 2002-07-17 filing, and Grounds 2–4 largely collapse — leaving only R1 (Solid § 102(b)), which has no feedback teaching. That would leave claim 1 supported only by Ground 1 with R2, whose own U.S. filing date is unverified.
• Claim 13 (ACL-group flow pattern) — not covered by R1–R5 as retrieved.
• Examiner considered all five references and the patent still issued. The five references are of record (they are on the face of the '309). That is not a defense, but a challenger must explain why the Examiner missed the combination — typically that the Examiner treated each reference in isolation (e.g., using R1 for the bucket, R5 for hierarchy) and never articulated the R4/R2 feedback combination. This is also a caution: because these references were before the Examiner, a § 325(d)-style discretionary-denial argument is available to the patent owner in any IPR, and it is a real risk at the PTAB.

H. Procedural posture and evidence needed

1. The patent is expired (adjusted expiration 2025-03-20). Validity will therefore be tested only in district court (or via ex parte reexamination), not as an IPR race. An expired patent still supports past damages within the § 286 six-year lookback, so an obviousness defense remains live in any pending action.
2. If IPR is contemplated, § 315(b) runs one year from service of a complaint alleging infringement; there is no prior FWD on this patent (per the earlier PTAB section), so no § 315(e) estoppel impedes a petitioner.
3. Evidence to assemble before pleading these grounds:
   • Full text of US 6,046,979 (claim 1 and the credit-bucket passages) — the record I retrieved gives only the abstract; the credit-bucket and L3/L4-lookup passages must be pinpoint-cited to columns/lines.
   • U.S. filing dates and provisional contents for US 2003/0035374, US 2003/0223369, US 2003/0223370, US 2003/0227872 (and the provisionals 60/385,978 and 60/386,646), to establish § 102(e) dates. For R2, resolve whether 2001-08-08 is a foreign priority or a PCT international filing (the pre-AIA § 102(e) proviso requires English-language PCT publication).
   • Authenticated copy of the granted counterparts US 7,652,988 B2 (R4) and US 7,450,507 B2 (R5), which are citable as patents and carry a cleaner § 102(e) story if their provisionals support the relied-on matter.
   • The '309 file history, to determine whether claim 1 was ever rejected and what (if anything) was argued — a prior art-specific argument or amendment is a potential prosecution-history estoppel lever.
4. Note on the previously flagged claim-text anomalies. Claim 20's preamble recites "wherein R_s = C·C_s·N_i" while the parallel claims recite "R_c," and claim 51's preamble says "fixed mode" over an accumulated-mode body. These do not help the patent: under a literal reading, claim 20's preamble makes the recompute expression internally inconsistent, and claim 51's body reads directly on R4's accumulated mode despite its label. Both are best handled as § 112 indefiniteness/construction points layered on top of the § 103 grounds, not as substitutes for them.

I. Confidence statement

• High confidence: R4 (US 2003/0223370 / US 7,652,988) discloses both the fixed and accumulated credit-bucket modes, the measured-rate comparison to a refresh rate, and the express motivation to abandon "set and forget." R2 (US 2003/0035374) discloses sampling egress bit rate at intervals and feeding it back to adjust the output rate. R1 (US 6,046,979) is solid § 102(b) art for credit-bucket rate limiting of classified variable-length packet flows. These support Grounds 1–4 as drafted.
• Moderate confidence: the precise § 102(e) dates of R2, R3, R4, and especially R5. All three Riverstone references depend on June 4–5, 2002 provisionals supporting the relied-on disclosure; R5's own U.S. filing (2003-02-19) postdates the '309.
• Low confidence / not asserted: any obviousness ground resting on the family-cited references (including US 7,068,602, "Feedback priority modulation rate controller") — I did not retrieve or verify their texts or dates, and I am not mapping them to claims. I also did not retrieve the '309's file history, so I cannot state whether the Examiner applied or distinguished any of R1–R5 against claim 1.
• Not asserted as obvious: claim 13 (ACL-group-defined flow pattern) on the references of record alone.

This is a technical prior-art analysis to support a § 103 position, not a legal opinion. The § 102(e) date determinations in particular require verification against the provisionals and USPTO Patent Center/PAIR before any of these grounds is relied upon.