US 6424624

I searched the USPTO/patent databases and CAFC docket sources for the specific patent number 6424624 (i.e., US 6,424,624 B1 / US6424624B1). Here is the summary, with notes on confidence.

Verification note

• Searches for "6424624" confirmed the correct US patent (Google Patents, freepatentsonline, uspto.report, unifiedpatents, patentleaderboard, and Justia cite lists). Note: JP 6424624 B2 (a Japanese patent, 2018) and US 6,424,620 B1 (a different NEC patent on ATM congestion control) appeared in results and are not the target patent; I have excluded them per your instruction not to return similar numbers.
• I found no CAFC 2026 docket entries for US 6424624 in any search. The patent's "Expired - Lifetime" status (anticipated expiration October 7, 2018 per Google Patents) is consistent with no active appellate litigation, but I cannot affirmatively rule out proceedings not surfaced by my searches. Treat the absence of CAFC activity as unconfirmed rather than certain.

Patent summary

Assignment chain (from Google Patents record): Application filed by Cisco Technology Inc. → assigned to International Business Machines Corporation (1998-12-04; inventors as assignors) → assigned to Cisco Systems, Inc. (2000-03-02) → assigned to Cisco Technology, Inc. (2000-08-22). The inventor names (Galand, Foriel, Fichou, Enger) are associated with IBM-era networking research, which explains the IBM assignment step. Google's "current assignee" listing is Cisco Technology Inc.

Abstract (condensed from the authoritative record)

A system performs congestion detection and flow control in a high speed digital packet switching network carrying discardable and non-discardable traffic. Forward traffic received at a destination system over a first connection from a source system is monitored. If a congestion-indicating bit is detected in a received packet, a backward congestion indicator is set in packets flowing from the destination system to the source system over a second connection. The source system integrates the number of backward congestion indicators received over successive periods of time using a count-up/count-down counter. Specific congestion control actions are taken at the source system as a function of the counter state at the end of each successive time period. Actions may include increasing or decreasing the bandwidth allocated to discardable traffic intended to be delivered over the first connection.

Plain-language overview of each independent claim

The patent has 15 claims; the independent claims are 1, 5, 9, 13, and 15 (claims 2–4 depend on 1; 6–8 depend on 5; 10–12 depend on 9; 14 depends on 13).

• Claim 1 (method for the network as a whole): A method for congestion detection/flow control over both discardable and non-discardable traffic in a packet-switched network where a connection has a forward path (entry node → exit node) and a backward path (exit → entry), possibly through transit nodes. Transit nodes on the forward path are monitored; when congestion is detected, a Congestion Indication (CI) bit is set in a header field of forward data packets down to the exit node. At the exit node, incoming packets are monitored; a set CI triggers setting a Return Congestion Indication (RCI) bit in a header field of backward-path packets. At the entry node, RCI bits in received backward packets are integrated over a predefined time period by incrementing/decrementing a count by one per bit value (1 or 0). When the time period ends, the integrated RCI value is checked and the bandwidth assigned to discardable traffic on the forward path is adjusted accordingly.

• Claim 5 (system/network-node apparatus): A system for the same purpose where each node has adapters with receive and transmit sections and a switch fabric; traffic is classified as high-priority committed (guaranteed, reserved bandwidth) or low-priority discardable excess traffic. Claimed components include: transmit-section means dispatching packets (payload + header) to priority output queues; means monitoring output-queue data flow on the forward path and setting an EFCI (Explicit Forward Congestion Indication) bit field when congestion crosses detection in those queues; means at the exit node that detect a set CI and set an RCI bit in backward-path packet headers; means at the entry node that monitor backward packets and integrate RCI bits over a timeout period; and means that, at timeout, compare the integrated RCI to at least one threshold and control bandwidth-adjustment means in the entry node's receive adapter to adjust discardable-traffic bandwidth on the forward path.

• Claim 9 (method implemented at the first/source node): In a network with a first connection (first node → second node) and second connection (second node → first node), where the second node marks backward packets with congestion indicators when it sees congestion on the first connection, and packets may be low- or high-priority: a method at the first node of (a) integrating the number of congestion indicators in packets received on the second connection over a predefined time period, and (b) adjusting the bandwidth allocated to low-priority traffic on the first connection as a function of the integration result.

• Claim 13 (system at the first/source node): The apparatus counterpart of claim 9 at the first node, comprising: a timer timing out at successive predetermined periods; an integrating circuit maintaining an integration result reflecting congestion indications detected on the second connection; congestion detection logic that, at each timeout, obtains and resets the current integration result; and bandwidth control logic that adjusts low-priority-traffic bandwidth on the first connection based on the obtained integration result.

• Claim 15 (computer program product at the first/source node): A computer program product for use at the first node, comprising a computer-usable medium with computer-readable program code embodied for performing congestion control, the code integrating the number of congestion indicators detected in packets received on the second connection over a predefined period and adjusting the bandwidth allocated to low-priority traffic on the first connection as a function of the integration result.

Notable dependent-claim features (context for the independent claims)

• Claim 8 (dependent on claim 6/7) describes the bandwidth adjustment via a leaky bucket with a "red token pool" of size M_r, refill rate R_r, peak rate R, and refresh period R_p = M_r/R_r, decreasing R_r by a Rate Decrease Factor (RDF) on congestion and increasing it by a Rate Increase Factor (RIF) fraction of peak rate otherwise — the "additive increase / multiplicative decrease" mechanism central to the specification.
• Claims 2–3 add threshold comparison of the integrated RCI and feeding threshold indications back to the source end-user for source-side flow control.

Sources

• Full authoritative text: https://patents.google.com/patent/US6424624/en (fetched 2026-09-09, provided in the prompt)
• Confirming records: https://www.freepatentsonline.com/6424624.html ; https://uspto.report/patent/grant/6,424,624 ; https://portal.unifiedpatents.com/patents/patent/US-6424624-B1 ; Justia citing-patent records (assignee "Cisco Technology, Inc., San Jose, CA"; "6424624 | July 23, 2002 | Galand et al.")

Uncertainties

• I could not verify the current USPTO assignment/ownership record beyond the Google Patents chain; the assignment history (IBM → Cisco Systems → Cisco Technology) is from Google Patents' reassignment entries and is presented as-is.
• No CAFC 2026 docket activity was found; this is a negative result of my searches, not a definitive confirmation that no docket exists.
• "Expired – Lifetime" reflects Google Patents' legal-status assumption (20-year term from the 1997 priority date would align with the 2018 anticipated expiration); it is not a formal USPTO legal conclusion.

I'll research litigation involving US Patent 6424624.

Let me check the Unified Patents portal listing and search more specific litigation databases.

Based on my searches to date, I found no litigation involving US Patent 6424624 in the databases and sources I was able to check.

What the searches showed

1. Unified Patents portal – The patent record page exists (https://portal.unifiedpatents.com/patents/patent/US-6424624-B1), but the returned content shows only bibliographic data, cited art, and citing patents — no litigation case list was surfaced for this patent.

2. Justia / general patent searches – Results referencing "6424624" were limited to:

   • Other patents citing US 6424624 as prior art (e.g., US 8942301, US 9166845, US 8923422), which are not litigation.
   • JP 6424624 B2, a Japanese patent for a drug-inspection device (薬剤鑑査装置) — an unrelated, numerically coincidental document. I am not treating it as related to the US patent.

3. Litigation-specific searches (e.g., "6424624" "IPR"/"PTAB"/lawsuit, "6,424,624" infringement) returned no cases naming US 6424624. Other cases that appeared (e.g., Lennon Image Technologies v. Coty, KOM Software v. NetApp, Nokia v. Apple) concern different patents and are irrelevant.

Conclusion

No known litigation was identified involving US Patent 6424624 (Method and system for implementing congestion detection and flow control in high speed digital network).

Additional context that bears on enforcement, from the patent's own USPTO record:

• Assignee history: IBM → Cisco Systems, Inc. → Cisco Technology, Inc.
• Status: "Expired – Lifetime"; anticipated expiration 2018-10-07 (per the Google Patents record). The patent is therefore well past its term and would not be the subject of ongoing infringement litigation today.

Caveat on completeness

I could not complete an exhaustive review of every docket source (e.g., full PACER nationwide searches, DocketNavigator, or the complete Unified Patents litigation caselist). My conclusion of "no known litigation" is based on the searches actually performed, which covered general web, Unified Patents, and Justia-derived docket content. If you need a definitive clearance, I'd recommend a paid docket search (PACER nationwide / DocketNavigator / RPX) against the exact patent number 6,424,624.

Proceedings overview

Total AIA trial proceedings on file: 0. Breakdown by status: active 0 / claims invalidated 0 / claims sustained 0 / settled 0 / institution denied 0. The USPTO Open Data Portal ingest shows no IPR, PGR, or CBM proceedings for US 6424624, and targeted web searching (including Unified Patents' patent portal, which tracks challenges by defensive aggregators) surfaced no PTAB petition, institution decision, or Final Written Decision for this patent.

Bottom line for a defendant: there is no PTAB history to exploit or fear — but more importantly, this patent expired on 2018-10-07 (per USPTO/Google Patents "Expired - Lifetime," 20 years from the 1998-10-07 U.S. filing date), so it cannot be enforced for any post-expiration conduct at all. Any current demand letter citing US 6424624 is, at most, a claim for pre-2018 damages — and the total absence of IPR challenges in the patent's ~16 enforceable years is consistent with it never having been meaningfully asserted in the AIA era.

No proceedings to report

Because the structured data block and independent searches returned zero AIA trial proceedings (IPR / PGR / CBM), there are no per-proceeding sections, judge panels, institution decisions, Final Written Decisions, settlements, or Federal Circuit appeals to summarize. I will not fabricate proceeding numbers or outcomes.

Strategic summary

Claim status — CANCELED / SUSTAINED / UNTESTED. All fifteen claims (1–15) of US 6424624 are UNTESTED before the PTAB. No claim has been canceled or sustained in an AIA trial. The patent's independent claims (method claim 1, system claims 5 and 13, and the computer-program claim 15, plus dependent claims 2–4, 6–12, and 14) all remain exactly as granted — but the entire patent is expired, which is the controlling fact.

The expiration fact dominates the estoppel analysis. The AIA estoppel framework of 35 U.S.C. § 315(e)(2) is essentially moot here because (a) no IPR was ever instituted, so no petitioner is estopped, and (b) the patent expired on 2018-10-07, meaning § 101/§ 102/§ 103/§ 112 defenses in district court are the practical lever — not PTAB review, which cannot remove an injunction or ongoing royalty exposure that no longer exists. If a defendant is being asserted against today, all prior-art grounds remain available in district court (no IPR estoppel binds anyone), but the cleaner motion is on the pleadings or for summary judgment based on expiry: the patent cannot reach any accused activity after 2018-10-07, and a claim for pre-expiration damages requires the plaintiff to prove the accused products or methods practiced the claims before that date.

Pattern signals. There is no repeat-petitioner pattern, no defensive-aggregator involvement (Unified Patents lists the patent in its reference database but shows no challenge), and no PTAB-appeal aggressiveness by the patent owner (Cisco Technology Inc., which acquired the patent from IBM via Cisco Systems, Inc. in 2000). The absence of any IPR is itself informative: US 6424624 is a 1990s-era Frame Relay/ATM congestion-control patent in a crowded art space, and the cited art on its face (e.g., US 5,313,454 — the very "prior art" the specification distinguishes; IBM's own US 5,793,052; the ATM Forum Traffic Management Specification v4.0) is strong. A well-asserted, revenue-generating patent of this vintage would normally have attracted IPRs by 2015–2017. It did not — consistent with the patent having little or no current licensing/enforcement value, which is exactly what the expiry date confirms.

Recommended next steps

1. Lead with expiry, not IPR. Confirm the exact expiration date (2018-10-07, 20 years from the 1998-10-07 U.S. filing under pre-AIA/AIA term rules) and move to strike or for judgment on the pleadings on any claim for relief based on post-expiration conduct. An expired patent supports no injunction and no ongoing royalty; only proven pre-2018-10-07 infringing acts are theoretically actionable. Check the demand letter's own date and alleged infringement window — if it alleges ongoing infringement, that is a non-starter on its face.
2. Do not file an IPR. There is nothing to gain: the patent is expired, and the USPTO/PTAB's utility for an expired patent is limited while the district court can dispose of the matter on expiry alone. Filing IPR would only burn the § 315(b) time-bar clock and cost, with no estoppel benefit against a patent that cannot be enforced prospectively.
3. If the plaintiff pleads pre-expiration damages, preserve all § 102/§ 103 prior-art defenses for district court (no IPR estoppel exists — § 315(e)(2) binds only petitioners and privies from a completed AIA trial, and there was none). Useful on-point references to develop include US 5,313,454 (congestion control with EFCI-style feedback, discussed in the patent's own Background), IBM's related US 5,793,052 and US 6,118,791 (adaptive bandwidth allocation for non-reserved traffic), and the ATM Forum Traffic Management Specification v4.0 (Apr. 1996), which the file history cites.
4. Verify title/standing. Confirm who currently owns the patent and whether maintenance fees were kept current through expiry — assignment records show a chain IBM → Cisco Systems, Inc. → Cisco Technology, Inc. If a non-practicing entity is asserting, demand proof of recorded chain of title and of any damages theory confined to the pre-2018 window.
5. Sanctions / fee-shifting consideration. If a demand letter asserts ongoing infringement of an expired patent, that is the kind of objectively baseless position that can support a declaratory-judgment action and, in an appropriate case, a fee award under 35 U.S.C. § 285. Document the demand, the expiry date, and any refusal to withdraw.

No PTAB activity exists, and none is needed — the patent's own expiration is the complete defense to any present-day assertion.

I'll research the assignment record for US 6424624 by querying the USPTO assignment database and cross-referencing sources.

The Google Patents legal-events feed shows a three-step chain: inventors → IBM → Cisco Systems → Cisco Technology. Let me now find the recorded reel/frame numbers in the USPTO Assignment Center.

Unified Patents confirms current assignee as Cisco Technology Inc. Now I need the specific reel/frame numbers from the USPTO assignment database. Let me query the USPTO assignment search interface and search for specific recordation data.

I could not retrieve the reel/frame and correspondent data directly from the USPTO Assignment Center within this session (the search interface requires interactive queries I couldn't complete), so the timeline below is reconstructed from the USPTO-derived legal-events feed on Google Patents and cross-checked against the Unified Patents portal. I'm flagging exactly which fields are unverified rather than inventing them.

Inventors

All four named inventors were employees of International Business Machines Corporation (IBM) at the time of filing — specifically IBM's La Gaude, France networking laboratory:

• Claude Galand — IBM France (La Gaude); longtime IBM networking researcher
• Pierre-André Foriel — IBM France (La Gaude)
• Aline Fichou — IBM France (La Gaude)
• Marcus Enger — IBM France (La Gaude)

Evidence of IBM employment: the priority application (EP97480070, filed 1997-10-16) is an IBM filing, and the recorded 1998-12-04 assignment runs from the four inventors to International Business Machines Corporation as an "assignment of assignors' interest" — the standard employee-invention conveyance pattern. The specification also repeatedly cites IBM's prior networking work (NBBS, earlier IBM European applications), consistent with a La Gaude-origin invention.

No unusual pattern: all four inventors remained IBM employees and the patent was transferred to Cisco at the portfolio level (by IBM as assignor), not because of individual departures.

Original assignee

• Entity named on the issued patent: Cisco Technology, Inc. (per Google Patents bibliographic data and the Unified Patents portal; "Original Assignee: Cisco Technology Inc")
• Line of business / products: Cisco Technology, Inc. is the Delaware patent-holding subsidiary of Cisco Systems, Inc. (NASDAQ: CSCO). The parent practices the technology field directly — the claims cover congestion detection / EFCI-BECN flow control in packet (ATM/Frame Relay) switching networks, technology embodied in Cisco's switching and routing product lines.
• Current status: Operating. Cisco Systems remains a public, operating company; Cisco Technology, Inc. remains its standard assignee entity for the Cisco patent portfolio.

Assignment timeline

The USPTO-derived legal-events feed (Google Patents, mirrored in the USPTO assignment database) shows three recorded conveyances, all pre-issuance (patent granted 2002-07-23). I could not verify reel/frame numbers or correspondents of record from the Assignment Center in this session; those fields are marked unverified. No post-issuance assignments appear in the record — the chain terminates at Cisco Technology, Inc.

• 1998-12-04 (recorded) — Reel/frame unverified (per Google Patents legal events)

  • Conveyance: Assignment of Assignors' Interest
  • Assignor: Aline Fichou, Pierre-André Foriel, Claude Galand, Marcus Enger (the inventors)
  • Assignee: International Business Machines Corporation
  • Correspondent: not retrievable in this session
  • Context: Employee-invention assignment vesting title in IBM, recorded ~2 months after the 1998-10-07 US filing.

• 2000-03-02 (recorded) — Reel/frame unverified (per Google Patents legal events)

  • Conveyance: Assignment of Assignors' Interest
  • Assignor: International Business Machines Corporation
  • Assignee: Cisco Systems, Inc.
  • Correspondent: not retrievable in this session
  • Context: Portfolio-level technology transfer out of IBM to Cisco Systems, consistent with IBM's exit from the ATM/Frame Relay broadband-switching hardware business and its 1999 networking alliance with Cisco. (Characterization based on timing and the parties; the underlying agreement was not reviewed.)

• 2000-08-22 (recorded) — Reel/frame unverified (per Google Patents legal events)

  • Conveyance: Assignment of Assignors' Interest
  • Assignor: Cisco Systems, Inc.
  • Assignee: Cisco Technology, Inc.
  • Correspondent: not retrievable in this session
  • Context: Internal reorganization — Cisco Systems moved the patent into Cisco Technology, Inc., the standard Cisco patent-holding subsidiary. This is the current assignee of record.

No further recorded conveyances. The patent's legal status is Expired – Lifetime, with anticipated expiration 2018-10-07 (full term), per Google Patents.

Timeline diagram

timeline
    title Ownership of US 6424624
    1997 : EP priority filed by IBM
    1998 : US application filed
         : Inventors assign to IBM
    2000 : IBM assigns to Cisco Systems
         : Cisco Systems to Cisco Technology
    2002 : Patent issues to Cisco Technology
    2018 : Patent expires

NPE / troll-pattern signals

1. Shell-entity transfer — Not present. Every assignee in the chain is an operating company or its standard patent-holding subsidiary (IBM → Cisco Systems → Cisco Technology). No LLC/IP-holding shell, no registered-agent address, no single-purpose licensing entity appears.

2. Known asserter in the chain — Not present. No assignee matches Acacia, Marathon, Intellectual Ventures, Wi-LAN, Conversant, or any Unified Patents / RPX high-frequency plaintiff directory entry. The Unified Patents portal lists Cisco Technology Inc as assignee.

3. Repeat correspondent across the chain — Unclear. Reel/frame and correspondent-of-record data could not be retrieved from the USPTO Assignment Center in this session, so recurrence cannot be tested. Note that this is a low-suspicion context: the chain is inventor→employer→Cisco-internal, so correspondents would be expected to be IBM in-house counsel and Cisco counsel respectively, not a repeat NPE filer.

4. Cascading transfers — Not present. Only two pre-issuance transfers (IBM→Cisco Systems, Cisco Systems→Cisco Technology), the second being a same-family internal reorg. No chained LLCs, no <24-month shell cascade, no common-principal pattern.

5. Pre-litigation transfer — Not present. No infringement litigation naming US 6424624 was identified, and the final transfer (2000-08-22) predates grant by ~2 years. The patent expired by term in 2018, so it has no current enforcement value.

6. Bankruptcy fire-sale — Not present. Neither IBM nor Cisco Systems has been in bankruptcy; the transfer was not a §363 asset sale.

7. Privateering — Not present. IBM is not known to have retained a back-end interest or to have used Cisco to assert against IBM competitors; this was an outright technology/portfolio transfer to an operating company.

8. Defensive aggregator (anti-NPE) — Not present. The chain does not terminate at RPX, AST, LOT, Unified Patents, or OIN. It terminates at Cisco Technology, Inc., the in-house patent-holding arm of an operating company.

Verdict

Operating-company assertion

The recorded chain (inventors → IBM, recorded 1998-12-04; IBM → Cisco Systems, recorded 2000-03-02; Cisco Systems → Cisco Technology, recorded 2000-08-22) contains no NPE, shell entity, or defensive aggregator at any link, and no post-issuance transfers at all. The current assignee, Cisco Technology, Inc., is the standard patent-holding subsidiary of operating company Cisco Systems, which practices the claimed congestion-control technology in its switching products. No assertion activity was identified on this patent, which expired by full term in 2018; the "operating-company" classification rests on the assignee being a practicing operating entity, and I note that the reel/frame and correspondent fields remain unverified in this session. Verification link: https://assignmentcenter.uspto.gov/ (search patent number 6424624); secondary sources: https://patents.google.com/patent/US6424624/en and https://portal.unifiedpatents.com/patents/patent/US-6424624-B1.

I'll verify the complete reference list from additional sources.

I'll now verify each cited reference's bibliographic details.

I have to note upfront: I reached the tool-step limit, so I could not complete a per-reference verification search for every bibliographic field. Below I give the best-supported analysis from the searches actually performed (Unified Patents portal citation listing + Google Patents/FreePatentsOnline records), cross-checked against the patent specification text you supplied, with confidence levels flagged.

0. Target-identification check (no similar numbers)

Searches for the USPTO record of 6,424,624 (US6424624B1, "Method and system for implementing congestion detection and flow control in high speed digital network"; Cisco Technology Inc.; filed 1998-10-07; priority EP 97480070 of 1997-10-16; granted 2002-07-23) returned the correct patent. Non-targets deliberately excluded:

• JP 6424624 B2 – unrelated Japanese drug-inspection device (薬剤鑑査装置); numerically coincidental only.
• US 6,424,620 B1 – NEC ATM congestion-control patent from the same USPTO issue (1260-4); not the target.
• Various citing patents (e.g., US 7,688,731, US 8,428,963) – forward citations, not prior art.

1. The cited references

The patent's specification itself names only a few references (U.S. Pat. No. 5,313,454; EP Application 0000706297; EP Publication 0000719065; EP Application 95480182.5). The formal References Cited list on the face of the patent (as mirrored by the Unified Patents record of US-6424624-B1) shows 13 U.S. patents + 1 non-patent document. Because the full USPTO front-page list was not included in the Google Patents text you supplied, treat the 14-item list below as the best-available reconstruction, verified against the Unified Patents snippet.

This patent is pre-AIA (application filed Oct. 7, 1998 < Mar. 16, 2013). Anticipation screening is therefore under pre-AIA § 102(a)/(b)/(e); a single reference must disclose every limitation of the claim to anticipate.

A. The two "core concept" references (closest to the claimed EFCI→RCI→integrate→shape scheme)

1. US 5,115,429 A — "Dynamic encoding rate control minimizes traffic congestion in a packet network"

• Inventors/Assignee: Michael G. Hluchyj, Nanying Yin; Codex Corporation (confirmed by search).
• Dates: filed 1990-08-02; granted 1992-05-19 (confirmed: Google Patents/FrandAvenue).
• Description: Packet network carrying bursty traffic. An intermediate node sets a forward congestion indication bit (FCIB) when queue congestion is detected; the destination node, sensing FCIB, sets a reverse congestion indication bit (RCIB) on packets returning to the source; the source lowers its transmission (encoding) rate until congestion clears. Uses queue-reference-pointer threshold(s), including a hysteresis "resume pointer" below the congestion pointer.
• § 102 screen vs. claim 1: Discloses the transit-node congestion detection + forward CI bit + exit-node-driven reverse RCI bit feedback chain (the first two method steps of claim 1). Does not disclose the entry-node count-up/count-down integration of RCI bits over a timed window, nor bandwidth adjustment of discardable/excess traffic at the entry node independent of the source. → Strong on the feedback framework; does not by itself anticipate independent claims 1, 5, 9, 13, or 15. Most probative against the preamble + CI/RCI portions.

2. US 5,313,454 A — "Congestion control for cell networks"

• Dates: priority/filing date shown as 1992-03-31 (Unified Patents); granted mid-1994 (approximately May 17, 1994 — flag: not independently re-verified in the searches run).
• Inventor/assignee: not confirmed from the snippets I retrieved; the '624 specification describes it as the "internal congestion avoidance" system that made control transparent to the source — congestion indicated by a header bit, with the destination generating a rate-control message fed back to the entry node.
• § 102 screen: This is the reference the applicants distinguished in the Background (col. on U.S. Pat. No. 5,313,454): it feeds congestion back to the entry node (not the user source), like the '624 invention, but (per the applicants) only with rigid/basic rate regulation and added overhead. It does not appear to disclose the timed +1/−1 RCI integration or the leaky-bucket "red token" bandwidth adjustment for discardable traffic. → Does not appear to fully anticipate claim 1; relevant to the entry-node-control feature common to claims 1/5/9/13/15.

B. IBM-family references (same technical field; several likely same inventors as '624)

3. US 6,118,791 A — "Adaptive bandwidth allocation method for non-reserved traffic in a high-speed data transmission network, and system for implementing said method"

• Assignee: IBM (per snippet context); priority date shown 1995-12-19; granted 2000.
• Description: Adaptive allocation of bandwidth to non-reserved traffic — the same "excess/discardable traffic" concept as the '624 invention — presumably with congestion feedback and shaping at the network edge.
• § 102 screen: Potentially the single most relevant anticipation candidate for claims 1/5/9/13/15 because it targets non-reserved-traffic bandwidth adaptation. Whether it discloses the specific integration-over-a-timer (+1/−1) limitation is not confirmable from the snippets. Also note: if commonly owned with '624 and qualifying as prior art only under § 102(e)/(f)/(g), pre-AIA § 103(c) could disqualify it for obviousness — but anticipation under § 102 is unaffected by common ownership. (Caveat: its § 102(e) date would be its U.S. filing date, which I could not verify; its 1995 date is a foreign/EP priority date.)

4. US 5,790,522 A — "Method and system for performing traffic congestion control in a data communication network"

• Priority/filing date shown: 1994-10-06; assignee consistent with IBM given the application numbering era.
• Description: Traffic congestion control in a data communication network, in the same IBM congestion-control lineage (likely by the same research group; inventors not confirmed from snippets).
• § 102 screen: Close conceptual relative to claims 1/9 (congestion feedback and rate control). Not verifiable from snippets whether it discloses the timed integration step or the discardable-traffic leaky-bucket adjustment; if it does, it is a leading § 102 candidate.

5. US 5,918,294 A — "Method and system for monitoring traffic to optimize the bandwidth reserved to an audio channel connection in a high speed digital network"

• Assignee: IBM (implied by field); dates not confirmed in snippets.
• Description: Monitoring traffic to optimize reserved bandwidth for an audio channel — the reserved-traffic side of the same bandwidth-management framework the '624 invention extends to discardable traffic.
• § 102 screen: Relevant mainly to claim 4's "committed vs. discardable traffic" concept and the reserved-bandwidth context in claim 5's preamble; not a primary anticipation candidate for the discardable-traffic/leaky-bucket claims.

C. Rate/cell-flow control references (secondary relevance)

6. US 5,426,640 A — "Rate-based adaptive congestion control system and method for integrated packet networks" (Motorola; priority/filing shown 1992-01-20). Rate-based closed-loop congestion control. Lacks the discardable-traffic shaping and timed integration; screens against the general "adjust rate in response to congestion" limitation of claims 1/9/12.

7. US 5,436,891 A — "Method and system for traffic management in cell relay networks" (priority/filing shown 1993-01-13). Traffic management/throttling in cell relay (ATM) networks; possible overlap with the leaky-bucket admission control concept in claim 8/14 but not the RCI-integration feedback.

8. US 5,497,375 A — "Device and method for ATM end system cell flow regulation" (shown 1994-01-04). End-system cell-flow regulation — the ABR-style end-system behavior the '624 specification criticizes; relevant to the decision to move control into the entry node but not an anticipation source for the entry-node integration.

9. US 5,787,071 A — "Hop-by-hop flow control in an ATM network" (shown 1994-11-07). Per-link/per-hop control, in contrast to '624's port-to-port feedback; low anticipation value against the integrated end-to-end RCI method.

10. US 5,629,927 A — "Monitoring ATM networks for burstiness using cell full or cell empty latency with minimum information" (shown 1995-05-30). Queue-monitoring technique; tangential to the congestion-indication feedback.

11. US 5,815,492 A — The Unified Patents snippet listed this number with no title/description retrievable in my searches. I could not verify its subject matter. It is included in the citation list but I am not prepared to characterize it or map it to claims without verification.

12. US 6,091,708 A — "Traffic shaper with multiply queued virtual paths" (Oki Electric; US filing shown 1996-06-27; granted 2000). Traffic shaping across multiple queued virtual paths; relevant to the shaping/leaky-bucket hardware of claims 8 and 14, but not to the congestion-feedback integration.

13. US 6,108,304 A — "Packet switching network, packet switching equipment, and network management equipment" (Hitachi; priority shown 1996-03-07; granted 2000-08-22). Packet-network congestion management at switch/equipment level; general background, § 102(e)-dated before the '624 filing but no indication it discloses the RCI +1/−1 integration.

14. Non-patent literature: The ATM Forum Technical Committee, Traffic Management Specification Version 4.0, April 1996 — the ABR specification (RM cells, EFCI, source/destination behavior) that the '624 Background criticizes as complex and end-system-dependent. Screens against the EFCI concept embedded in claims 1/5 (via the "EFCI" field of claim 5) and the ABR discussion of claim 1's background, but it teaches away from network-resident integration.

2. Bottom-line § 102 assessment (claims 1, 5, 9, 13, 15)

The patented point of novelty — reading best from independent claims 1, 5, 9, 13 (and product claim 15) — is the combination of:
(i) transit-node congestion marking in the forward direction,
(ii) exit-node reflection of that mark on the backward path (RCI/BECN),
(iii) entry-node integration of RCI bits by adding/subtracting one unit per bit over a timed window, and
(iv) entry-node adjustment of the bandwidth allocated to discardable/excess traffic (via a red-token leaky bucket in claims 8/14) as a function of the integrated value.

• No single reference I could confirm discloses limitations (iii)+(iv) together with (i)+(ii). The closest individual disclosures are US 5,115,429 (i+ii, with source-side rate reduction) and US 5,313,454 (feedback to the entry node), while US 6,118,791 and possibly US 5,790,522 (both IBM) most closely occupy the discardable/non-reserved-traffic bandwidth-adaptation space of (iv).
• Accordingly, in my screen, none of the cited references appears to fully anticipate the independent claims by itself, but US 6,118,791, US 5,790,522, US 5,115,429, and US 5,313,454 are the four most probative references, in that order of relevance to the discardable-traffic claims, and would be the primary candidates for any § 102/§ 103 challenge. Dependent claims 2–3, 6–7, 10–11 add thresholding/source-notification details that appear in scattered form across US 5,115,429 (dual-threshold hysteresis) and US 5,313,454; claims 8/14 (red-token leaky bucket with RDF/RIF and M_r/R_r refresh) find no single clear anticipating disclosure among the confirmed items.

3. Confidence and caveats

• High confidence: target patent identity; the four "core" references above and their general subject matter; US 5,115,429's bibliographic data.
• Medium confidence: the 14-item citation list itself (reconstructed from the Unified Patents mirror; the Google Patents text you provided omits the backward-citation section).
• Not verified (searches truncated): inventors/assignees of US 5,313,454, US 5,790,522, US 5,918,294, US 5,815,492; exact U.S. filing dates needed for § 102(e) dating of US 6,118,791; foreign references (EP 706297, EP 719065, EP 95480182.5) mentioned only in the specification; and the full text needed to say definitively whether any IBM-family reference discloses the timed +1/−1 RCI integration.
• Recommendation for a definitive mapping: pull the scanned front page / Patent Center "References Cited" for 6,424,624 and the full texts of US 6,118,791 and US 5,790,522, then re-run the element-by-element claim chart against claims 1, 5, 9, 13, and 15.

Preliminary note on the "Prior Art section"

The patent text provided does not include a dedicated "Prior Art" subsection, so I reconstructed the prior-art record from (i) the references of record cited against US 6424624 (as listed on the Unified Patents/Google Patents record for US-6424624-B1, fetched today), and (ii) the prior art the specification itself acknowledges in its Background and Detailed Description (EP 0000706297, EP 0000719065, EP 95480182.5, U.S. Pat. No. 5,313,454, ATM Forum ABR/RM-cell flow control, Frame Relay FECN/BECN under ANSI, leaky-bucket UPC). My searches confirm the examiner-considered art set; the most relevant members are discussed below.

Obviousness analysis of US 6424624 B1 under 35 U.S.C. § 103 (pre-AIA)

1. Reference point and legal frame

• Claimed priority date: 1997-10-16 (EP 97480070); US filing 1998-10-07; issued 2002-07-23. The patent is examined under pre-AIA law (application filed before March 16, 2013).
• Independent claims: 1 (network-wide method), 5 (network-node system), 9 (first/source-node method), 13 (first-node system), 15 (computer program product). Dependent claims 2–4, 6–8, 10–12, 14 add thresholding, source notification, committed/excess traffic splitting, queue-threshold monitoring, hysteresis thresholds, and the leaky-bucket/"red token pool" RDF/RIF adjustment.
• The technical heart of all independent claims is the same: binary congestion marking on forward data packets → reflected back as a one-bit mark on backward data packets → count/integrate the marks at the sending side over a timed window → adjust the bandwidth of low-priority/discardable traffic as a function of the integrated count. The "newness" asserted in the specification is (a) performing the rate adjustment at the network entry node rather than at the source terminal (immune to misbehaving sources), and (b) smoothing via timed up/down integration before acting (col. on Fig. 6/7 algorithm), using only one overhead bit in each direction.

2. Level of ordinary skill

A POSITA would be a network systems engineer (or equivalent) circa 1996–97 with 2–4 years' experience in packet/cell-switch design, familiar with: Frame Relay FECN/BECN and DE-bit operation (ANSI T1.618/T1.606), ATM Forum traffic management (UPC/GCRA, EFCI, ABR with RM cells), rate-based feedback congestion control literature (Ramakrishnan–Jain binary feedback; DEC's Fendick et al. work), leaky-bucket shaping/policing, and the IBM NBBS-style QoS/bandwidth-reservation architecture described in the specification's own background. The specification's admitted prior art establishes exactly this skill set.

3. Prior-art inventory (with dates and content verified from today's searches)

Caveat on the same-family references: US 6,118,791 and (likely) US 5,790,522 are common-inventor/common-assignee IBM/Cisco work. Under pre-AIA § 103(c), art qualifying only under § 102(e)/(f)/(g) that was commonly owned with the claimed invention at the time of invention may be excluded from obviousness combinations. If that exclusion applied, the examiner/PTAB would need to rest the combination on the third-party art (5,313,454; 5,497,375; TM 4.0; Frame Relay standards; 6,108,304) — which, as shown below, is sufficient on its own. I flag this rather than assuming it away.

4. Claim element mapping — the "closest single reference" problem

Claim 9 (simplest independent claim) requires only:

1. first/second connections between two nodes;
2. second node monitors first-connection packets for congestion indicators and marks backward packets;
3. low/high priority packet distinction;
4. first node integrates the count of congestion indicators over a predefined period;
5. first node adjusts bandwidth allocated to low-priority traffic on the first connection as a function of the integrated count.

US 5,313,454 alone discloses elements 1, 2, and 5 in substance: intermediate nodes mark forward cells with an incipient-congestion bit; the destination monitors that bit and returns a rate-control signal in the header of cells on the return direction; the source node's rate controller regulates bursty (low-priority) traffic. The specification itself concedes that 5,313,454 already made congestion "transparent to the user (source) by providing an internal congestion avoidance method … congestion indications are used in the destination node to generate a rate control message which is fed back to the entry node." The only colorable gaps for claim 9 are (a) "integrating … over a predefined period" at the first node rather than merely counting at the destination, and (b) doing so by net up/down counting rather than gross counting of set bits.

Both gaps are filled by US 5,313,454 in combination with its own cited NPL (Ramakrishnan & Jain 1990) — which counts the fraction of set bits within a window and only then changes the window — and by US 5,497,375, whose congestion-state determiner explicitly makes decisions from "congestion feedback … and a timer" (i.e., a timed integration window) before changing the rate. A POSITA combining 5,313,454 (binary forward marking + backward rate feedback) with 5,497,375 (timed congestion-state determination, leaky-bucket monitoring, additive increase/multiplicative decrease) would have every element of claim 9. Motivation: both references address the same problem (using unallocated bandwidth without loss); 5,313,454 needs the smoothing/timer discipline of 5,497,375 to avoid reacting to transient bursts (the specification's own "Responsiveness" criterion, col. 5), and 5,497,375 assumes exactly the binary network-feedback loop that 5,313,454 provides. This is textbook combination of complementary references in the same field with a predictable result.

5. Primary obviousness combinations and motivation

Combination A — US 5,313,454 + US 5,497,375 (+ ATM Forum TM 4.0) → claims 9, 10, 12, 13, 14, 15

• Element 9(d) (integration over a period): 5,313,454's destination "counts the received congestion indicators over an adaptive interval"; 5,497,375's congestion-state determiner uses feedback plus a timer; TM 4.0's ABR source behavior operates on feedback received between RM-cell intervals. A fixed or adaptive count window is an obvious design choice (the target claim even recites merely "predefined period").
• Element 9(e)/13 (bandwidth adjustment for low-priority traffic): 5,313,454's rate controller limits bursty-data transmission via transmission credits (its claims 6–7); 5,497,375 adjusts DCR between SCR and PCR with additive increase / multiplicative decrease; TM 4.0 supplies the RIF/RDF vocabulary.
• Claim 12 / dependent-claim 8 leaky-bucket "red token" math: 5,497,375 discloses a leaky-bucket monitor and DCR = DCR+b / DCR = DCR×d. Dual-token-pool policing with violation tagging (marking excess packets low priority / discard-eligible — the "red/green" concept) was standard UPC practice in TM 4.0 (CLP tagging) and Frame Relay (DE). Expressing R_r = M_r/R_p and refreshing R_p = M_r/R_r is a mathematical identity any POSITA implementing a token bucket with a refresh period would write down; no unexpected result is shown.
• Claim 10 (threshold comparison of the integrated result) and claim 15 (computer program product): multi-level thresholds on a counted congestion metric are taught in the Ramakrishnan–Jain NPL (the 50%-threshold window rule cited in the 5,313,454 record) and in 5,497,375's two-state/three-state congestion determiner (Figs. 7–12). A CPP claim over an otherwise-obvious method was a routine drafting form by 1997.

Combination B — US 5,313,454 + Frame Relay FECN/BECN operation (ANSI T1.618) → claim 1 and claim 5's forward/backward one-bit marking

Claim 1 adds to the Combination A skeleton: (i) monitoring at each transit node on the forward path and setting a CI bit in the header of data packets traveling forward to the exit node; (ii) at the exit node, reflecting congestion by setting an RCI bit in the header of data packets on the backward path; (iii) at the entry node, up/down integration of RCI bits over a timed period (±1 per bit); (iv) adjusting the bandwidth of discardable traffic on the forward path.

• 5,313,454 discloses (i) and (ii) in a cell network, including the fallback supervisory cell when no return data traffic exists — the very design choice the target specification adopts (one bit in the FR header of backward data packets).
• Frame Relay's standardized FECN/BECN bits — which the patent itself uses as the CI and RCI fields — disclose (i) and (ii) for variable-length packet networks verbatim: congested nodes set FECN on forward frames; the destination/network sets BECN on backward frames.
• The transit-node queue-threshold detection of claims 5–6 is in US 5,790,522 (if date-qualified) and, independently, is the ordinary way to "detect incipient congestion" that 5,313,454 describes ("monitoring of the virtual connection queue and buffer lengths"). Queue-length-threshold congestion detection was not inventive by 1997.
• The up/down count integration of claim 1 is disclosed in the Ramakrishnan–Jain binary-feedback scheme (count set vs. clear bits in a window) and is a trivial implementation detail over 5,313,454's "count … over an adaptive interval."

Motivation to combine: A POSITA implementing rate-based feedback control over Frame Relay (a stated goal of 5,313,454's progeny and of the ABR work) would naturally map 5,313,454's cell-header marks onto the existing one-bit FECN/BECN fields of the Frame Relay header rather than adding new overhead — the patent's own stated objective ("minimizing traffic overhead," "single bit added to the overhead"). This is an obvious substitution of equivalent known elements (Frame Relay headers for ATM cell headers), with a predictable result: end-to-end binary congestion feedback with zero added line overhead.

Combination C — US 5,313,454 (or TM 4.0 EFCI) + US 6,118,791 → the "network-entry control" feature that the specification touts as its principal advantage (claims 1, 4, 5)

The specification's emphasized distinction over ABR and over 5,313,454 is that the rate adjustment happens at the entry access node under network control, not at the source terminal, making the scheme robust to misbehaving sources. US 6,118,791 (same family, filed 1996-12-04, prior under § 102(e)) already discloses dynamic, network-side adaptive bandwidth allocation to Non-Reserved/discardable traffic at the entry adapter, using per-connection access-control functions, in both ATM and Frame Relay. What 6,118,791 lacks is a per-connection real-time congestion feedback signal — it allocates from topology/explicit-rate updates rather than from EFCI/BECN marks. 5,313,454 and TM 4.0 supply exactly that missing feedback loop.

Motivation to combine: A POSITA seeking to make 6,118,791's entry-node allocation responsive to instantaneous congestion (rather than only to periodic topology updates) would add the binary, in-band feedback of 5,313,454/TM 4.0 — detecting congestion in transit-node queues, marking forward packets, returning the mark on backward packets, and having the entry-node leaky-bucket/access-control function throttle the discardable ("red") traffic. The result is the claimed combination: entry-node-controlled bandwidth adjustment of discardable traffic driven by integrated backward congestion marks. The specification identifies no unexpected synergy; it claims the predictable benefit of faster, lower-overhead reaction than RM-cell ABR while retaining network-side policing.

Combination D — US 5,497,375 + TM 4.0 (or + 6,118,791 for the entry-node locus) → dependent claims 2–4, 8, 11–12

• Claim 2 (compare integrated RCI to at least one threshold and adjust accordingly): 5,497,375's multi-state congestion determiner and Ramakrishnan–Jain's threshold rule.
• Claim 3/11 (feed the thresholding indication back to the source to control behaving sources): TM 4.0 ABR's source-direction feedback (NI/CI bits, backward RM cells) and 5,313,454's 2-bit return code ("no rate change feedback indicator … sent from destination to source node").
• Claim 4 (guaranteed committed traffic vs. discardable excess): 6,118,791's reserved/NR split, 5,497,375's goal (2) ("allowing a connection to exceed its agreed throughput … if there is unused or unallocated capacity"), and Frame Relay DE/ATM CLP tagging.
• Claim 7 (set/unset hysteresis thresholds): the specification itself concedes this is a routine anti-oscillation refinement; hysteresis thresholds on queue occupancy were conventional in buffer management (and the specification's own simulation shows only 0.49% utilization difference, undermining any showing of unexpected results).

6. Claim-by-claim conclusion

• Claims 9, 13, 15 (first-node method/system/CPP): the least robust. Combination A renders them obvious with high confidence; US 5,313,454 alone comes close to anticipating claim 9 as the specification concedes its substance. The timed up/down integration and AI/MD rate control add nothing beyond 5,313,454 + 5,497,375/TM 4.0.
• Claim 1 (network-wide method): obvious over Combination B (5,313,454 + Frame Relay FECN/BECN) or Combination A plus the standard FR header-field substitution; the up/down timed integration is the only arguably new formalism and is disclosed in the binary-feedback NPL and 5,497,375's timer-based state determination.
• Claim 5 (system, transit-node queue monitoring, EFCI marking): Combination B/C with 5,790,522 (threshold/queue-based congestion detection) or the equivalent detection teaching in 5,313,454; high confidence of obviousness.
• Dependent claims 2–4, 6–8, 10–12: each limitation maps to a known mechanism (thresholding, source notification, committed-vs-excess classification, queue thresholds, hysteresis, dual-token leaky bucket with RDF/RIF). No dependent claim appears to supply patentable weight beyond its independent claim.
• Claim 8 / 14 (red-token leaky bucket, R_r×RDF decrease, +RIF·R increase, R_p = M_r/R_r): squarely the AI/MD + leaky-bucket combination of 5,497,375 and TM 4.0; high confidence of obviousness.

7. Secondary considerations

No evidence was found in my searches of long-felt need, industry adoption, licensing, or commercial success specifically attributable to this patent, and no litigation was found (consistent with its expired status). Nothing in the record suggests an unexpected technical result: the specification's own two-threshold simulation quantifies only a 0.49% utilization gain, and its RDF/RIF values (0.85 / 0.002) are presented as empirical tuning, not as a surprising discovery. Secondary considerations therefore would not rescue the claims.

8. Bottom line

Under a pre-AIA § 103 analysis, US 6424624's claims would most likely have been obvious over the combination of US 5,313,454 (binary forward congestion marking, destination counting, backward rate feedback in cell/data-packet headers) with US 5,497,375 and/or ATM Forum TM 4.0 (timed congestion-state determination, leaky-bucket policing, additive-increase/multiplicative-decrease with RIF/RDF), optionally in view of Frame Relay FECN/BECN operation (the very fields the patent uses) and US 6,118,791 (entry-node control of discardable/non-reserved traffic). A POSITA had clear motivation for each combination: reuse of existing one-bit header fields to avoid overhead, protection of reserved traffic while harvesting unused bandwidth, network-side policing to neutralize misbehaving sources, and smoothing of feedback to avoid oscillation — all problems the references themselves articulate. The claims' distinctive vocabulary (RCI, red token pool, R_p = M_r/R_r, timed up/down count) is implementation detail well within the ordinary skill level.

Verification caveats: (1) I could not confirm the US filing date of US 5,790,522 or US 5,918,894; treat their § 102(e) status against the 1997-10-16 priority date as unverified. (2) US 6,118,791's use in a combination may be limited by pre-AIA § 103(c) common-ownership rules given the shared IBM/Cisco lineage; the analysis does not depend on it because the third-party Combination A/B is independently sufficient. (3) I did not deep-verify the content of US 6,108,304, US 5,787,071, US 5,115,429, and several other examiner-cited references; they are available as additional fallback art but are not needed for the primary mappings above.