US 6876668

I'll search for patent 6876668 specifically, including any 2026 litigation activity.

Let me check for any litigation/reexamination activity and the exact text of claim 1.

Let me verify whether there's any reexamination or court proceeding, and confirm the claim set.

US Patent 6,876,668 — Summary

Note on scope of my search: I searched for the literal identifiers "6876668," "6,876,668," and "US6876668B1" combined with litigation, reexamination, Federal Circuit, and 2026 docket terms. I found no court docket, CAFC appeal, or reexamination proceeding involving this patent. That is a negative search result, not affirmative proof of no litigation — for a definitive answer you'd want PACER/CourtListener and Docket Navigator, which I cannot query directly here.

---

Bibliographic data (per the patent front page / Google Patents)

Sources: https://patents.google.com/patent/US6876668/en ; https://patents.justia.com/patent/6876668

---

Abstract (verbatim)

"A system capable of dynamically reserving bandwidth and adjusting bandwidth reservations for active sessions of data communication in a data communications device is provided. The system generally separates the operation of bandwidth allocation and adjustment from the operation of data transport through the device, thereby allowing bandwidth reservations and adjustments to be made without disturbing sessions of data communication that are actively being transported through the device. The system can accept requests to allocate or reserve bandwidth in a data communications device using bandwidth reservation protocols such as RSVP. The reservation requests create sender state data that can be used to compute resource allocation data. The resource allocation data can be used to label data storage locations in a data storage mechanism according to the required bandwidth reservations. A data scheduling apparatus, which is ignorant of particular sessions and specific amounts of reserved bandwidth, examines data and deposits data into data storage locations having a label corresponding to a session identification specified in the data, if any. If an unknown or no session identification is specified in the data, the data scheduler deposits data into a data storage location that is unlabeled or that has an unreserved label. Thus session bandwidth is determined by the percentage of labeled data storage locations for the session. Changes in bandwidth reservations are reflected in the separate operation of alterations made in the data storage labeling scheme, and do not affect the data scheduler, or data dequeuing mechanisms, thus allowing data sessions to continue without interruption during bandwidth adjustments."

---

Core technical idea

The invention decouples two functions inside a router/switch:

1. Bandwidth reservation processor (bandwidth request handler/RSVP daemon + bandwidth labeler + resource allocation calculator + resource allocation table) — converts a requested bandwidth (e.g., 100 Kbps) into a percentage of the device's total path bandwidth, then applies that percentage as labels on a rotating queue's entries (e.g., 12-entry conveyor queue; 25% → 3 entries labeled "A").
2. Data transporter (data scheduler + queuing mechanism + dequeuer) — merely inspects each packet's RSVP/Tspec header and drops it into any queue entry bearing a matching label; unlabeled/unreserved ("U") entries take best-effort traffic.

Because bandwidth is expressed as a proportion of labeled storage locations rather than as a scheduler configuration, a bandwidth change (e.g., 64 Kbps → 100 Kbps for flow "B") is effected by re-labeling entries as they empty, without notifying or reconfiguring the scheduler and without dropping the session. The patent frames this as managing resources rather than time, avoiding the prior-art RSVP requirement to halt the sender and flush the network before renegotiating.

---

Independent claims — plain language

I have verbatim text only for claims 12–29 (Justia). Claim 1's exact wording was not in the retrieved excerpt, so the claim 1 characterization below is reconstructed from its dependent claims (11–13) and from parallel independent claims 14/27/29 — treat it as strongly inferred, not verbatim. Independent claims appear to be 1, 14, 27, 28, and 29, with claim 11 likely also independent (uncertain).

Claim 1 — Method (reconstructed): "dynamically adjusting reserved bandwidth in a data communications device while maintaining a session of data communication." Steps: (a) receive a first RSVP bandwidth reservation request associated with application data of a session, where the request is distinct from the application data; (b) establish a first bandwidth reservation in the device based on that request; (c) label a first percentage of available data storage locations with an identity of the session, the percentage based on the requested bandwidth; (d) transport the session's application data using those labeled locations; (e) receive bandwidth allocation adjustment information within a second RSVP request during the session; and (f) dynamically adjust the first reservation into a second reservation based on that adjustment information while continually maintaining the session.

• Dependent claim 13 limits the labeling to a percentage of queue entries of a queue.
• Dependent claim 12 recites examining a data stream identification field in the packet header (the Tspec field of the RSVP header).

Claim 11 — Method (likely independent; examining/depositing). Adds examining information associated with the session's application data and depositing that data into storage locations whose identity corresponds to the examined information (per dependent claims 12–13).

Claim 14 — Data communications device (apparatus). A device with communications interface, memory, processor, and interconnection, configured to: receive a first RSVP reservation request (distinct from the application data); establish a first reservation; label a first percentage of storage locations with the session identity; transport the session's data via those locations; receive adjustment information in a second RSVP request during the session; and dynamically produce a second reservation while continually maintaining the session. (Claim 15 adds computing/storing a first percentage of total device bandwidth; claim 16 requires a resource allocation table independently accessible so the percentage can be altered without disrupting labeling or transport.)

Claim 27 — Computer program product. A computer-readable medium with logic that, when run on a controller, performs the same six operations as claim 14 (the software/disk embodiment).

Claim 28 — "A content subscriber comprising…" A means-plus-function apparatus claim that mirrors claim 14 using "means for receiving / establishing / labeling / transporting / receiving / dynamically adjusting." ⚠️ Caution: the retrieved text contains what appears to be a drafting artifact — "wherein the computerized device is configured to produce a means for accessing presence information, such means including…" — which is unrelated to bandwidth allocation. I cannot confirm whether this is the literal granted text or an error in the secondary source. Treat claim 28's preamble and that clause as unverified.

Claim 29 — Method (dynamically adjusting reserved bandwidth while transporting a session). Recites the same six steps as claim 1/14 plus a final step: labeling, with the session identity, a second percentage of storage locations based on the second requested bandwidth, the second percentage being different from the first.

Claim count: 29 claims total (1–29), 4 prior-art patents cited (US 5,884,037 Aras; US 6,031,841 Woundy; US 6,336,129 Ise; US 6,353,616 Elwalid) plus RSVP RFC 2205 and three RSVP overview references.

---

Uncertainties / things I could not verify authoritatively

1. No 2026 CAFC docket found. No search result tied 6,876,668 to any Federal Circuit or district court matter in 2026 (or any year). Absence of results ≠ absence of litigation; the patent is marked Expired – Lifetime (anticipated expiration 2019-05-24), which makes new infringement actions unlikely.
2. No reexamination certificate found. However, the claim language retrieved ("first RSVP bandwidth reservation request … distinct from the application data") is notably narrower and more RSVP-specific than the description's generic "bandwidth reservation request" language, which sometimes signals post-issuance amendment. I found no evidence of a reexam, so I am flagging this as unexplained rather than asserting one occurred.
3. Claim 1 verbatim text not retrieved — reconstructed from dependent claims; verify against the USPTO Patent Public Search / PatentCenter "Claims" view for the authoritative wording.
4. Claim 28 anomaly noted above — verify against the official document.
5. The Google Patents page classifies the patent under H04L 49/90, H04L 47/52, H04L 47/724, H04L 47/765, H04L 47/822, H04L 47/803, H04L 47/82 — useful for prior-art searching, but note Google's CPC mapping is algorithmic.
6. One third-party indexing source (an EPO search report for WO 2009/021891) cites the patent with the inventor name misspelled "CHANLA HAMESH"; the correct name per the front page is Hamesh Chawla.

I'll search for litigation involving US patent 6876668.

Initial searches didn't surface litigation. Let me try more targeted litigation databases.

Let me investigate whether the "668 patent" in the Cisco/Arista ITC case is actually US 6,876,668, and check the Unified Patents litigation portal.

Summary of Findings — US Patent No. 6,876,668

Bottom line: I could not confirm any litigation that specifically names U.S. Patent No. 6,876,668 as a patent-in-suit.

I searched litigation-focused sources (Unified Patents litigation portal references, Docket Alarm/PTAB records, ITC § 337 publications, Federal Register notices, PTAB IPR petitions, and general case databases). No case caption, docket entry, complaint, or PTAB petition I retrieved expressly identifies 6,876,668 ("Apparatus and methods for dynamic bandwidth allocation," Chawla & Waclawsky, Cisco Technology, Inc.) as an asserted patent.

Important caveat — do not conflate the identifiers

Several search results reference a "'668 patent" in the long-running Cisco Systems v. Arista Networks dispute (e.g., ITC Inv. No. 337-TA-945; related PTAB proceeding IPR2016-00309). Per your strict rule, I am not treating that "'668 patent" as U.S. 6,876,668. In the excerpts I retrieved:

• The ITC/PTAB documents refer only to "the '668 patent" without stating the full seven-digit number.
• That ITC '668 patent was found infringed and was held unpatentable by the PTAB (Fed. Cir. summarily affirmed Feb. 14, 2018) — Cisco's public statements describe it as covering, inter alia, a "Pip CoPP" feature.
• I could not verify in the retrieved record that this "668" patent is the same as U.S. 6,876,668, and I did not find any source tying the two together.

Other "668-adjacent" hits were unrelated (e.g., the Paltalk v. Cisco audio-conferencing verdict concerned U.S. 6,683,858; the enhanced-data-streaming case concerned other patents). I flag these only to note they are not matches.

Proposed entry (unverified — flagged, not confirmed)

If you intend to pursue whether the ITC '668 patent is 6,876,668, the candidate matter would be:

Caveat: The row above describes the Cisco v. Arista "'668 patent." I could not confirm that this is U.S. 6,876,668, so I am not asserting that 6,876,668 was litigated.

Other notes

• The Google Patents record for US 6,876,668 shows the patent as "Expired – Lifetime," with anticipated expiration May 24, 2019, and lists no litigation in the fetched page.
• A continuation/related application (US 11/051,227, filed Feb. 4, 2005, pub. US2005/0128951A1) claims further subject matter (future bandwidth-allocation modification), but no litigation on that family surfaced either.
• I did not obtain a direct query result from the Unified Patents litigation case list (https://portal.unifiedpatents.com/litigation/caselist) because my search steps were exhausted; that portal should be checked directly to close the gap.

Recommended next steps to confirm definitively

1. Query the Unified Patents litigation portal and Docket Alarm / PACER directly for "6,876,668" (not just "668").
2. Pull the ITC 337-TA-945 complaint and the IPR2016-00309 petition to read the full patent number of the "'668 patent."
3. Check USPTO Patent Center / Assignment records for any reissue, disclaimer, or IPR certificate affecting 6,876,668.

If you'd like, I can draft the exact search strings and portal URLs to run these checks.

If no litigation involving US 6,876,668 is confirmed, the correct statement is: no known litigation asserts US Patent No. 6,876,668.

I'll verify the structured-data signal with searches before reporting.

Let me run a couple more targeted checks before concluding.

One more check on ownership/assertion history, since that affects the defensive posture.

Proceedings overview

Zero AIA trial proceedings are on file for US 6,876,668. The canonical structured block from the USPTO Open Data Portal returns no AIA trial proceedings, and four independent web searches (petition-level, patent-number-level, litigant-level, and aggregator-level) surfaced no IPR, PGR, or CBM petition naming this patent — no petition number, no institution decision, no Final Written Decision, and no Federal Circuit appeal of any Board decision on it. Because the count is zero, the per-proceeding breakdown requested (active / claims invalidated / claims sustained / settled / institution denied) is 0 / 0 / 0 / 0 / 0, and the "most-impactful proceeding first" ordering has nothing to order. There is no proceeding section to write, so below I substitute (a) the verification trail, (b) what the absence of PTAB activity means, and (c) a separate, largely non-PTAB defensive posture that is actually stronger than any IPR outcome would have been.

The bottom line for a defendant is not "the patent is hardened by surviving IPRs." It is: no challenger has ever tested these claims at the Board, and it likely no longer matters, because the patent record shows expiry. That is a different — and generally better — posture than a hardened patent, but it comes with a caveat about term that must be verified (see below).

No proceedings on file — verification trail

• Type / Filed / Status / Panel / Grounds / Institution / FWD / Settlement / Appeal: N/A — no proceeding exists. I am not populating these fields with synthetic content.
• Searches run (all negative for this patent):
  • Petitioner/patent pairing ("IPR20… / CBM20… '6876668'") — no hits tying any Board case number to this patent.
  • Litigant-level searches for Cisco-challenger and Cisco-patent-owner AIA proceedings — returned IPRs on other Cisco-related patents (e.g., Monarch Networking Solutions v. Cisco IPR2020-01226/01227/01678, Cisco v. Centripetal IPR2022-01151), none on 6,876,668.
  • Assertion-history searches for the number as a case exhibit — no complaint, docket entry, or exhibit list referencing 6,876,668.
  • Defensive-aggregator check — a Unified Patents portal page did appear in results, but it is for a different patent (US 10,341,243, "Systems and Methods for Providing Content and Services on a Network System"). I found no evidence that Unified Patents or any other aggregator has challenged 6,876,668. I am explicitly flagging this rather than implying an aggregator connection.
• Authoritative record relied on: https://patents.google.com/patent/US6876668/en (fetched 2026-09-24T07:20:58.260Z; legal status "Expired - Lifetime"; anticipated expiration 2019-05-24).

One unresolved lead I could not verify — treat as a to-do, not a finding. A Federal Register issue dated 2018-07-02 contains the phrase "relevant claims of the '668 patent are unpatentable" (https://www.govinfo.gov/content/pkg/FR-2018-07-02/pdf/2018-14192.pdf), but the surrounding text I could retrieve is an unrelated DOJ antitrust matter, and "'668" is used by many patents. I could not confirm which patent that phrase attaches to, and it may reflect an Article III judgment or an unrelated Office notice rather than a Board decision. Do not cite it as a PTAB outcome. Confirm the patent number in context before relying on it.

---

Strategic summary

Claim status: every claim of 6,876,668 is UNTESTED, not canceled and not sustained. There is no FWD, so there are no canceled claims, no surviving claims as narrowed by the Board, and no claim construction or patentability holding to bind anyone. The claims as granted (the "bandwidth reservation processor / labeler / resource allocation table / percentage-of-storage-locations" family described throughout the specification, including the resource-allocation-table data structure embodiment) remain in their original issued form. That is a real limitation on what I can tell you: I cannot say a single claim number is dead, because the Board has never said so. If a demand letter cites specific claims, PTAB history gives you no shortcut — the invalidity work has not been done for you.

Estoppel: none. Zero § 315(e) estoppel attaches to anyone. Section 315(e)(2) estoppel is triggered by a final written decision in an instituted IPR (and § 325(e)(2) analogously for PGR). With no institution and no FWD, no petitioner and no privy is barred from raising any ground in district court or before the Office. Conversely, and importantly for you: you are not the beneficiary of anyone else's estoppel either, and you are not the victim of it. The entire prior-art landscape — including art a hypothetical earlier petitioner could have raised — remains fully available to you. The practical corollary is that the usual "one-year § 315(b) clock" question is moot until you are actually served; if you were served, that clock would be running from service, but see the expiry point below before spending on a petition.

Pattern signals: none. No petitioner has filed even a first petition, so there is no serial-filer pattern to analyze (no General Plastic / Fintiv discretionary-denial story), no patent owner pushing a PTAB appeal strategy to the Federal Circuit, and no aggregator in the chain that I could substantiate. Cisco Technology, Inc. appears on the record as the assignee of an internal, operating-company portfolio (inventors Chawla and Waclawsky; the family includes US 6,771,661 "Swapping bandwidth reservations," US 7,477,601, US 7,072,343, and US 7,209,446, plus continuation application 11/051,227, published as US 2005/0128951 A1 with claims directed to "future bandwidth allocation modification information"). That is the profile of a defensive corporate portfolio patent that was never weaponized — the mirror image of an NPE-held patent that attracts a swarm of IPRs. The absence of PTAB activity here is therefore informative but should not be over-read: the usual inference ("well-asserted patents eventually attract IPRs") applies, but so does the competing inference, visible in the data, that this patent was never asserted at all.

The controlling fact is not PTAB — it is term. The record shows filing/priority date 1999-05-24, grant 2005-04-05, and legal status "Expired - Lifetime" with anticipated expiration 2019-05-24. If that expiry holds, then: (i) there is no prospective infringement to enjoin for any conduct after 2019-05-24; (ii) under 35 U.S.C. § 286, a suit filed today (2026-09-30) reaches back only six years to 2020-09-30, i.e., a window entirely after expiry, so recoverable past damages are effectively nil absent some pre-2019 accrual already in suit; and (iii) an IPR, while technically still available on an expired patent, would be a poor expenditure. Caveat I cannot resolve from the sources I have: patent term adjustment. "Anticipated expiration" is the nominal 20-year date; a PTA award on the face of the patent would push actual expiry later. Verify this before relying on expiry, because it is the pivot on which the whole defense turns.

---

Recommended next steps

1. Do not build a defense around PTAB outcomes — there are none. There is no FWD to quote, no disposition to link, and no claim-level verdict to cite. Any representation that claims of 6,876,668 have been canceled or sustained is fabricated; I have deliberately made no such statement.

2. Verify the expiry date on the face of the patent and in USPTO Patent Center before anything else. Pull the printed patent and check for a "Patent Term Adjustment" notice, then confirm the maintenance-fee and expiration status at https://patents.google.com/patent/US6876668/en and in the ODP/Patent Center record. If expiry is confirmed at 2019-05-24, the demand letter is answered by § 286 plus the absence of post-expiry infringement — a far cheaper resolution than an IPR. If PTA extended the term, re-run the analysis.

3. Confirm current ownership, not the historical assignee. The structured record lists Cisco Technology, Inc. as original and current assignee, but assignee listings can lag. Because the value of this patent to an asserting party depends entirely on whether it moved to a non-practicing entity, check the USPTO Assignment recordation database ("USPTO Assignment") linked from the Google Patents page.

4. If an active assertion does exist and the patent is not actually expired, the milestones to calendar are the ordinary AIA ones: a § 315(b) one-year clock from service; the Board's three-month institution-deadline target under § 314(b) (six months from the notice of accord); the statutory twelve-month deadline from institution to FWD under § 316(a)(11); and, if institution is sought, the Fintiv / § 314(a) discretionary-denial fight, with the Director's discretionary-denial briefing process (patent owner brief within two months of the notice of accord, petitioner opposition one month later) as currently administered.

5. If you want to check the dockets yourself rather than rely on this report, the two primary free sources are PTAB E2E / PTAB Decisions at https://ptacts.uspto.gov/ptacts/ and CourtListener at https://www.courtlistener.com/ — searching the patent number in either should return nothing for this patent, consistent with the ODP signal. If you find a proceeding in either that ODP has not indexed, treat this report as superseded and re-analyze the claim-level outcome before relying on it.

Bottom line: no PTAB activity on file — stated plainly, as the structured data and independent searching agree. That absence means no claim of 6876668 has been canceled and none has been affirmed; estoppel is a blank slate in both directions. The likely dispositive defense sits outside the AIA entirely, in the patent's expired legal status, which I recommend confirming on the face of the patent and in Patent Center before you decide whether any Board filing is worth pursuing.

I'll search for assignment records, litigation, and any chain-of-title information for this patent.

I was unable to reach a live USPTO Assignment Center session or any indexed reel/frame record for this patent within my tool budget. Everything below is grounded in the authoritative Google Patents legal-events block supplied in the full patent text, cross-checked against the earlier sections of this analysis. Where I could not verify a data point (notably reel/frame numbers), I say so explicitly rather than inventing one.

Inventors

Pattern notes:

• Both inventors assigned to Cisco on the filing date itself (1999-05-24), which is the signature of a standard employee invention-assignment obligation executed at filing, not of a later negotiated transfer. There is no evidence of a pre-filing third-party obligation.
• No evidence of inventor departure preceding a fire-sale. I found no data on when either inventor left Cisco, and no portfolio-level transaction in which this patent moved. In the absence of a recorded transfer, inventor-departure timing is moot for ownership purposes here.
• Caution on secondary sources: a third-party inventor-index page (radaris) blends multiple Chawla/Waclawsky filings and displays a "What is claimed is…" block reciting "bandwidth allocation information indicating future bandwidth allocation modification information … determining a future event …". That text is not from US 6,876,668's claim set — it appears to belong to a different family member or a separate Chawla application. Treat aggregator pages that concatenate several patents under one inventor name as unreliable for claim text. (This also indirectly warns against leaning on the earlier section's reconstructed claim 1 without a PatentCenter check.)

Original assignee

• Entity on the issued patent: Cisco Technology, Inc. (San Jose, CA) — original and current assignee per Google Patents.
• Relationship to the operating business: Cisco Technology, Inc. is the patent-holding subsidiary of Cisco Systems, Inc. Cisco routes the bulk of its US patent filings through this entity. So although the named assignee is technically a subsidiary, it is not an arm's-length NPE — it is an internal holding vehicle for an operating company that ships the accused-capable products.
• Product embodying the claims: Cisco shipped RSVP-capable IOS-based routers and switches in the 1999–2005 window; the patent describes an implementation-level mechanism (labeling rotating-queue entries to encode reserved bandwidth) for an RSVP-capable data communications device. I have not independently verified that a specific shipping Cisco product line implemented the claimed "label a percentage of storage locations" mechanism, so I mark embodiment as plausible and consistent with Cisco's product line rather than affirmatively documented.
• Current status: Cisco Technology, Inc. is an active, wholly owned subsidiary of a publicly traded operating company (Cisco Systems, Inc., NASDAQ: CSCO). It is not dissolved, not in bankruptcy, and has not been acquired. No SEC 8-K or 10-K disclosure of a divestiture of this patent was found.

Assignment timeline

Honest statement of what the record shows: Based on the Google Patents legal-events block (the authoritative text provided), the only recorded assignment in the chain is the original inventor→Cisco assignment dated/filed 1999-05-24. There are no recorded post-issuance assignments, security interests, mergers, name changes, releases, or corrections visible on that record. I could not retrieve the reel/frame number from assignmentcenter.uspto.gov within this session, and I will not invent one.

• 1999-05-24 (executed) / recorded 1999-05-24 — Reel/frame NOT VERIFIED (accessible via search at https://assignmentcenter.uspto.gov/ and https://assignment.uspto.gov/patent/index.html)

  • Conveyance: Assignment
  • Assignor: Hamesh Chawla; John G. Waclawsky
  • Assignee: CISCO TECHNOLOGY, INC. (San Jose, CA)
  • Correspondent: Not verified from a primary record. The earlier section of this analysis reports the patent's attorney/agent of record as Chapin & Huang, LLC; I could not confirm whether that firm is the recording correspondent on the reel/frame entry (which is a distinct field from the prosecution attorney of record). Cisco records of this era are typically filed by Cisco's in-house patent department or its outside recording counsel — I decline to guess. No recurrence pattern can be assessed from a single link.
  • Context: Contemporaneous employee invention assignment — executed on the filing/priority date, i.e., an employment-obligation assignment at filing, not an acquisition or a fire-sale.

• 2005-02-04 — Not an assignment. Google Patents records this as a priority link to continuation application 11/051,227 (published as US 2005/0128951 A1). A continuation claims priority to, but does not transfer, the parent. It is included here only so the timeline is not mistaken for a second conveyance. (Family-continuity note, not chain-of-title.)

If Assignment Center returns additional hits (e.g., a 2000s-era security agreement or an unbundled transfer), that would be new information I could not see; the Google Patents legal-events block is the limiting record I have.

Timeline diagram

timeline
    title Ownership of US 6876668
    1999 : Application filed by Cisco
         : Inventors assign rights to Cisco Technology
    2005 : Patent 6876668 issues
         : Continuation application filed
    2019 : Anticipated expiration

Text kept punctuation-free and under 40 characters per the constraint; because only one conveyance exists, the chain is a straight line rather than a cascade.

NPE / troll-pattern signals

1. Shell-entity transfer — Not present. Current assignee is Cisco Technology, Inc. on the only recorded conveyance; there is no LLC with an IP/Holdings/Ventures/Licensing suffix anywhere in the chain. No recorded transfer at all after 1999-05-24.
2. Known asserter in the chain — Not present. No assignee matches Acacia, Marathon, Intellectual Ventures, IPNav, Wi-LAN, Conversant/Mosaid, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, or any Erich Spangenberg entity. Cisco Technology, Inc. does not appear on Unified Patents' or RPX's high-frequency-plaintiff directories.
3. Repeat correspondent across the chain — Unclear / not assessable. Only one recorded link exists, and I could not verify the recording correspondent from a primary record. A single appearance is expressly not a finding under the stated test; I make no call.
4. Cascading transfers — Not present. Zero post-issuance transfers, hence no chain of LLCs and no shared correspondent address to test.
5. Pre-litigation transfer — Not present. No infringement suit naming this patent was located (consistent with the earlier section's negative search result), and no transfer occurred at all, so there is nothing to date against a complaint.
6. Bankruptcy fire-sale — Not present. No assignor bankruptcy. Cisco Systems has never filed Chapter 7/11.
7. Privateering — Not present. No transfer from Cisco to an NPE acting on Cisco's behalf appears in the record or in any coverage I located.
8. Defensive aggregator (anti-NPE) — Not present. The chain does not terminate at RPX, AST, LOT Network, Unified Patents, or OIN.

Verdict

Insufficient data — in the sense defined by the rubric: the record contains only the original assignment. The sole recorded conveyance is the 1999-05-24 inventor→Cisco Technology, Inc. assignment filed contemporaneously with application 09/317,381, and Google Patents lists Cisco Technology, Inc. as both original and current assignee through the 2019-05-24 anticipated expiration. There are no shell LLCs, no known asserters, no cascading or pre-litigation transfers, and no defensive-aggregator termination — so there is no basis for any NPE classification, high or moderate. Practically, this is a clean, single-owner, operating-company patent that expired in 2019, making assertion activity both unsupported by the record and commercially unattractive. I could not verify reel/frame numbers from a primary source; verify at USPTO Assignment Center and the Google Patents legal events view.

I'll research each prior-art reference cited on the face of US 6,876,668. Let me run targeted searches.

Prior Art Analysis — US Patent No. 6,876,668

0. Identifier confirmation and scope

The number resolves to exactly one patent; no similar numbers were substituted.

Source: https://patents.google.com/patent/US6876668/en (also the patent PDF at https://patentimages.storage.googleapis.com/bf/dd/e3/2a1875a5651f99/US6876668.pdf)

Two scope caveats, stated up front:

1. What follows is an analysis of the references cited on the face of 6,876,668 (the "References Cited" list), i.e., the examiner-cited and applicant-cited art. That is not the same thing as a full invalidity search. A validity-grade search would also pull art under the CPC buckets the patent actually sits in — materially H04L 47/52 (bandwidth attributed to queues), H04L 47/724 (RSVP), H04L 47/765 (in-call renegotiation triggered by end-points) — and that art (see § 6) is often closer than the cited list.
2. I re-verified the four cited U.S. patents in this session. I was not able to re-retrieve the complete face-of-patent list, so the non-patent-literature entries (RFC 2205 plus the RSVP overview references) are carried forward from the previously generated section of this analysis and are flagged as not independently re-confirmed here. Where I give a filing or issue day-of-month that I could not read off a front page in this session, I say so.

---

1. The cited references, at a glance

---

2. Reference-by-reference

PA-1 — US 5,884,037

Full citation. U.S. Patent No. 5,884,037, "System for allocation of network resources using an autoregressive integrated moving average method." Inventor record: Aras (per the previously generated citation list). Issued March 1999 (front page shows the "Mar." issue date; I did not verify the exact day or the filing date this session).

Description (verified). A reservation-based bandwidth management system for a data-processing network. It allocates network resources to client systems based on a bandwidth-predicting algorithm that uses autoregressive integrated moving average (ARIMA) trend analysis to forecast future values of bandwidth capacity at a link or system level. The front page frames the problem of reservation systems where less than 100% of users participate in the reservation scheme, so "the non-conforming portion of the network fluctuates over time and thus makes it difficult to determine the amount of bandwidth available to the reservation system." An "NCBP" (network capacity bandwidth predictor) is described as an off-line function that "does not affect the network performance." Source: https://patentimages.storage.googleapis.com/2b/3b/1f/92f1eb9595827f/US5884037.pdf

§ 102 mapping. Weak. It can arguably map to a determination that a requested resource is available — the "admission control" predicate recited in the specification and in 6,876,668's background discussion of prior-art RSVP (col. describing admission control 102 / policy control 103). But:

• It is not RSVP-based and does not disclose or suggest receiving an RSVP bandwidth reservation request, which is a literal claim limitation in independent claims 1, 14 and 29 as previously characterized ("first RSVP bandwidth reservation request … distinct from the application data").
• It contains no disclosure of labeling a percentage of available data storage locations / queue entries with a session identity, and no disclosure that reserved bandwidth is made to equal the proportion of labeled storage locations. That limitation is the point of novelty across the independent claims.
• Its predictor is explicitly an off-line function; it is the opposite of "dynamically adjust … while continually maintaining the session."

Conclusion: Not an anticipatory reference for any independent claim. It is § 103 background, useful only for the admission/availability-determination concept. Any claim in 6,876,668 reciting a bare "determine whether sufficient resources are available" step would be the only place it gets near § 102, and I have not seen such a standalone claim.

---

PA-2 — US 6,031,841 (the closest cited art)

Full citation. U.S. Patent No. 6,031,841, "RSVP support for upstream traffic." Inventor: Richard Woundy (North Reading, Mass.). Assignees: MediaOne Group, Inc. and U S West, Inc. Appl. No. 08/996,349, filed 1997-12-23; issued 2000-02-29. Class 370/410. 8 claims. (Continuation: US 6,385,207, filed 1999-12-20, issued 2002-05-07.) Sources: https://patentimages.storage.googleapis.com/5a/21/c9/38d7201d91b555/US6385207.pdf ; https://patents.searchlight.law/doc/US6031841 ; http://www.everypatent.com/comp/pat6031841.html

Description (verified). A method for dynamically allocating upstream network resources in a packet-based broadband cable data network using RSVP, with a CMTS connected to user terminals via cable modems. The stated advance: it is desirable for the CM to perform the "packet classifier" function and the CMTS to perform most of the "packet scheduler" function, but prior CMTS SID schemes were "fixed and inefficient in that there was no ability to control how much of the available resources a user would be able to reserve." The patent introduces three MAC management messages — Dynamic Session Addition, Dynamic Session Deletion, Dynamic Session Acknowledgement — and a management protocol. Claim 1 (verbatim, from the granted text) recites: generating an RSVP path message; passing it to the destination; performing packet classification at the destination cable modem by transmitting a resource reservation signal requesting resources for upstream communication; performing packet scheduling at the CMTS by determining whether resources are available and, if so, generating a SID message comprising at least one filter spec parameter; receiving the SID at the CM; and setting a filter spec parameter in the CM equal to the SID's parameter. Claim 3 adds detecting an unused SID and sending a reservation-termination message; claims 7–8 add the dynamic session addition/deletion messages.

§ 102 mapping. This is the reference that most nearly touches the preamble/problem statement of 6,876,668, and it is plainly the reason the examiner wanted the RSVP-art cluster addressed. Element-by-element against the independent claims as characterized:

Conclusion: US 6,031,841 does not anticipate any independent claim of 6,876,668, because it fails the "label a percentage of available data storage locations with a session identity" limitation, which every independent claim family in 6,876,668 appears to carry (and which dependent claims 12–13 sharpen to "queue entries" and to reading the session ID from the packet header). Its proper role is as primary § 103 art for the motivation and framework (RSVP reservation establishment + mid-session addition/deletion), and as the clearest demonstration that 6,876,668's inventive contribution is the mechanism of bandwidth enforcement (label proportion of a rotating queue), not the RSVP signaling. Note also the specification of 6,876,668 expressly characterizes Woundy-style implementations as the problem: "if the RSVP daemon … were to attempt to change the allocation of reserved bandwidth during an active session … the scheduler might need to reconfigure queuing structures and the classifier might need to be made aware of the new bandwidth allocation scheme."

---

PA-3 — US 6,336,129

Full citation. U.S. Patent No. 6,336,129, "Packet transfer method and node device using resource reservation or priority transfer control without requiring virtual connection merging." Inventor record: Ise et al. Issued January 2002 (day not verified this session; filing/priority not verified). Source: https://uspto.report/patent/grant/6336129

Description (verified in part). The patent is directed to transferring packets from a sender to one or more receivers via a network of nodes having a network-layer processing function, using resource reservation or priority transfer control without requiring virtual connection (VC) merging. It distinguishes RSVP Path message and Resv message flows (FIGS. 9A/9B) and the conventional label-switch-router VC-merging setup (FIG. 10). The related continuation US 6,643,258 ("Communication resource management method and node device using priority control and admission control") frames the same design space as 6,876,668's own background: it critiques RSVP/int-serv per-flow scheduling and policing at every node as a processing bottleneck, and critiques DiffServ/SIMA edge-tagging at a rate proportional to the flow's allocated bandwidth as unable to guarantee per-flow quality or to let a node know the reserved bandwidth of flows traversing it. Source: https://patents.google.com/patent/US6643258

§ 102 mapping. Moderate, again at the level of the problem statement, not the solution.

• It is RSVP-aware and reservation-oriented, so it touches the same field.
• It does not disclose labeling a percentage of data storage locations/queue entries with a session identity as the enforcement mechanism. Its mechanism is forwarding/priority control and reservation signaling at nodes with VC-merge avoidance.
• Its continuation's stated goal — guaranteeing per-flow bandwidth while avoiding per-flow scheduling and keeping nodes aware of reserved bandwidth — is a plausible § 103 motivation to look for a representation of reserved bandwidth that a node can enforce cheaply. That is exactly the gap 6,876,668 fills by turning reserved bandwidth into a count of labeled queue entries.

Conclusion: Not anticipatory. Useful as secondary § 103 art for the motivation to represent reserved bandwidth in an enforcement-cheap form. Note the direction of travel: Ise's family treats node-level awareness of reserved bandwidth as the problem, which cuts against using it to read on 6,876,668's affirmative "resource allocation table" teaching.

---

PA-4 — US 6,353,616

Full citation. U.S. Patent No. 6,353,616 B1, titled "Adaptive processor scheduler and method for reservation protocol message processing." Issued March 2002 (day not verified this session). Confirmed via the Unified Patents record, which also lists "Apparatus and Methods for Dynamic Bandwidth Allocation" in the same reference neighborhood — consistent with the two patents being in the same RSVP processing art. Source: https://portal.unifiedpatents.com/patents/patent/US-6353616-B1

Description. An adaptive processor scheduler that schedules processing of reservation-protocol (RSVP) messages at a network node — i.e., it addresses the CPU/processing burden of handling reservation-signaling messages, as distinct from the transport of the media stream. This is a processing-time/throughput allocation invention on the reservation-signaling control path.

§ 102 mapping. Weak, and it is important not to overstate it. It can map to the "bandwidth request handler" / "bandwidth reservation processor" structural element of 6,876,668's apparatus claims 14 and 27 to the extent those claims recite a processor that handles reservation requests. But:

• It discloses no bandwidth-reservation data structure keyed to a percentage of total device bandwidth, and no labeling of storage locations.
• Its "scheduler" is a processor/message scheduler, not the data scheduler that deposits session payload into matching-labeled storage locations.
• Critically, it does not disclose that reservation processing proceeds asynchronously and independently of data transport so that a bandwidth change can be made without notifying the data scheduler. That separation is the asserted heart of 6,876,668.

Conclusion: Not anticipatory. Relevant only as background for the routing/processing of RSVP reservation messages. If an independent claim were ever read to cover "a processor that processes reservation requests concurrently with data transport," this is the reference to check in detail — but the granted claims as characterized carry the labeling limitation, which this reference lacks.

---

NPL-1 — RFC 2205

Full citation. R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource ReSerVation Protocol (RSVP) — Version 1 Functional Specification," IETF RFC 2205, September 1997 (as cited on the face of 6,876,668 and as it appears in contemporaneous RSVP-art patents, e.g., US 6,765,927).

Description. The RSVP protocol standard: Path and Resv message formats, receiver-initiated reservations, admission control, policy control, and the packet classifier / packet scheduler split with filter spec (classifier) and flow spec (scheduler). This is the protocol framework 6,876,668 operates within.

§ 102 mapping. RFC 2205 can only be anticipatory if a claim were limited to bare RSVP protocol behavior — receiving reservation requests, Path/Resv exchange, admission/policy control. It expressly does not specify the intra-device mechanism: 6,876,668 itself recites that "RSVP simply provides a mechanism to exchange bandwidth reservation and path messages … The mechanisms to set aside or reserve the bandwidth resources in the device are implementation dependant." So RFC 2205 cannot anticipate the independent claims: it teaches the absence of the very implementation (percentage-labeled storage locations) the claims recite. It is admitted prior art, cited for the protocol, and is the correct § 103 base for a "combine RFC 2205 + a queue-partitioning reference" theory.

---

NPL-2, -3, -4 — the three RSVP overview references

Status: not independently verified this session. The face of 6,876,668 is recorded as citing, alongside RFC 2205, three RSVP overview/architecture references. I could not re-retrieve their exact citations or contents within this session's search budget, and I will not reconstruct titles, authors, venues or dates — that would be fabrication.

Provisional § 102 assessment. On their face these are RSVP tutorial/overview items. By their nature they explain RSVP's purpose, message types, and the classifier/scheduler model — the same content as RFC 2205 and subject to the identical analysis above: they do not disclose a percentage-of-storage-locations labeling mechanism, a resource allocation table independently accessible from a bandwidth labeler, or relabeling-during-transport. Anticipatory value: none, pending retrieval and confirmation of their actual content. Treat them as § 103 background/teaching-the-RSVP-field art only.

---

3. Composite § 102 verdict

No cited reference anticipates any independent claim of US 6,876,668. On the independent claims as previously characterized, every one of the 1 / 14 / 27 / 28 / 29 family (and, if it is independent, 11) includes the limitation that reserved bandwidth is established by labeling a percentage of available data storage locations — typically queue entries — with the session identity, that percentage being derived from the requested bandwidth. None of US 5,884,037, US 6,031,841, US 6,336,129, US 6,353,616, RFC 2205, or (provisionally) the RSVP overview items discloses that limitation, alone or in the operative combination. Anticipation requires every element in a single reference (35 U.S.C. § 102), so the § 102 count is zero.

Where the cited art is genuinely dangerous is § 103, not § 102:

• US 6,031,841 + RFC 2205 supply (a) RSVP bandwidth reservation establishment, (b) mid-session addition/deletion of reserved resources, and (c) the admission/policy-control predicates. A challenger would then need only a secondary reference teaching partitioning a queue by session and taking a session's share as a fraction of queue space to argue obviousness of the labeling step. The patent's own "Labeling" claim (percentage of total queue size) is exactly the kind of proportional-allocation teaching that cyclic-service/queue-partitioning art (see § 6) supplies.
• US 5,884,037 and US 6,336,129 each contribute an independent motive to represent reserved bandwidth in a form the node can enforce without per-flow scheduling — useful as a § 103 "reason to modify."

Practical note on weight. Per the record, 6,876,668 shows Expired – Lifetime with anticipated expiration 2019-05-24, and the prior sections of this analysis found no IPR/PGR/CBM proceeding and no confirmed litigation naming this patent. A § 102/§ 103 attack on an expired patent is generally academic unless it is being run to defend a past-damages claim, so this analysis should be read as a validity assessment, not a live-filing recommendation. The one thing that would change that is patent term adjustment: if a PTA award on the face of the patent pushed actual expiry past 2019-05-24, term — not prior art — becomes the live issue, and this art analysis becomes secondary.

---

4. Corrections and flags

1. Claim 1 wording is not verbatim here. The § 102 element tables above use the reconstructed claim 1 / 14 / 29 language from the previously generated section. If the granted claims do not in fact recite "RSVP" in every independent claim, then RFC 2205's and US 6,031,841's relevance drops; if they do, it rises (it becomes a literal-limitation question rather than a broad "bandwidth reservation request"). Verify claim 1 against USPTO Patent Public Search / Patent Center before relying on the tables.
2. The four U.S. patents are the universe of patent citations I could confirm. If the face of 6,876,668 cites additional U.S. patents beyond these four (the previously generated section states "4 prior-art patents cited"), a full copy of the front page should be pulled to confirm there are no others, since an unexamined citation could matter.
3. PA-4 title confirmation. The Unified Patents listing renders the title as "Adaptive Processor Schedulor" (sic). That is a source typo; the patent title is "Adaptive processor scheduler and method for reservation protocol message processing." I have not changed any patent number.
4. Do not conflate the "668 patents." A separate Cisco-related "'668 patent" appears in the Cisco v. Arista ITC/PTAB record; as the earlier litigation section concluded, that is not confirmed to be US 6,876,668. Nothing in this prior-art analysis depends on, or supports, that identification.

---

5. What would make this analysis materially better

1. Pull the actual "References Cited" page of the 6,876,668 PDF and transcribe the four U.S. patents and the non-patent-literature block verbatim, so NPL-2…4 are identified rather than described generically.
2. Obtain and quote claim 1 and claim 11 verbatim (granted text) — the entire § 102 mapping hinges on whether the labeling limitation and the "RSVP" limitation are as characterized.
3. For each of US 6,031,841 and US 6,336,129, pull the full claim sets (I have US 6,031,841 claims 1–8 in part; US 6,336,129 not at all) to test whether any claim — not just the disclosure — reads on a 6,876,668 claim.
4. Check the continuations: US 6,385,207 (Woundy) and US 6,643,258 (Ise) may contain disclosure broader than their parents on the mid-session reservation-change point.

---

6. Beyond the cited list — art worth pulling if you need a real validity picture

Explicitly outside the requested citation set, and offered only as leads, not as § 102 findings:

• US 5,463,620 (Sriram) — cyclic service discipline with dynamic time slices per queue on a high-speed (ATM) node. This is the most directionally relevant class of art I saw: it enforces per-class bandwidth as an allocation of the service cycle, which is structurally adjacent to "a percentage of queue entries." It would be a § 103 secondary reference candidate against the labeling limitation.
• US 5,903,735 (Kiffer et al.) and US 5,881,246 (Crawley et al.) — cited in the RSVP-art patents pulled above; RSVP/QoS resource-management background.
• US 6,643,258 / US 6,643,258-family (Ise) — the continuation of PA-3, with the more explicit "node must be aware of reserved bandwidth" critique that supplies § 103 motivation.

---

Bottom line for the requested question: on the cited record, the four U.S. patents and RFC 2205 (and, provisionally, the three RSVP overview items) are § 103 art, not § 102 art. US 6,031,841 (Woundy) is the most relevant cited reference — it supplies the RSVP-based dynamic bandwidth-reservation framework, including mid-session addition/deletion, but it implements reservations through SID/filter-spec parameters and packet scheduling, not through labeling a percentage of available data storage locations with a session identity, so it does not anticipate. US 5,884,037 (Aras) reaches only the admission/availability predicate; US 6,336,129 (Ise) and US 6,353,616 are field-and-motivation art on reservation handling in a node and on RSVP message processing, respectively. The independent claims' distinguishing limitation across all of them is the percentage-of-storage-locations labeling mechanism — none of the cited references discloses it.

I'll build on the claim/PTAB sections already produced and focus this task on § 103. First, let me verify the actual prior-art references on the face of the patent and their content.

Good — I've confirmed the content of four of the cited references. Let me verify the Woundy reference and check for the actual claim text plus any additional art of record.

Obviousness Analysis — US 6,876,668 under 35 U.S.C. § 103

Note on tool limits: My search budget was exhausted partway through this task. I retrieved and verified full/partial text for four of the six reference groups in the patent's "Prior Art" section (the four US patents). I did not retrieve RFC 2205's text, the three RSVP "overview" references, the verbatim text of claim 1, or the prosecution history. Where I rely on the prior-generated section's reconstruction of claim 1, I say so. This is an analysis of the art of record on the face of the patent, not an independent prior-art search.

---

0. Framework and the one fact that changes everything

Governing law (pre-AIA). Application 09/317,381 was filed 1999-05-24, so pre-AIA §§ 102/103 apply. The test is Graham v. John Deere, 383 U.S. 1 (1966): scope/content of the prior art → differences → level of ordinary skill → secondary considerations, with the legal question of obviousness judged under KSR Int'l v. Teleflex, 550 U.S. 398 (2007). KSR supplies the combination rationales I use below (known technique, predictable result, design incentive, market/design trend). Claim construction, if contested, follows Phillips v. AWH.

The threshold caveat, restated from the earlier sections: the patent is recorded as Expired – Lifetime, anticipated expiration 2019-05-24. A § 103 analysis is therefore only operative if (a) the expiry actually holds and there is pre-2019 accrued conduct in suit, or (b) the expiry is wrong — i.e., patent term adjustment extends the term. I cannot resolve PTA from my sources. I flag this because it is the pivot, but I proceed as instructed to analyze § 103 on the merits.

A second caveat carried forward: the earlier section could not retrieve verbatim claim 1 and reconstructed it from claims 11–13 and the parallel independents 14/27/29. My mapping below is to that reconstruction. Verify claim 1's literal text before relying on any row of this analysis.

---

1. The prior art of record, as verified

These are the references cited on the face of US 6,876,668 (per the earlier section's count: four US patents, RFC 2205, and three RSVP overview references).

Verified datum worth highlighting: the Unified Patents portal page for US 6,353,616 renders the title "Apparatus and Methods for Dynamic Bandwidth Allocation" — i.e., a metadata cross-link between the Elwalid reference and this patent. That is corroboration that 6,353,616 is squarely in the same field, and it is useful for the analogous-art / field-of-endeavor argument. (It is a portal labeling artifact, not a legal statement.)

---

2. Level of ordinary skill (POSITA)

For a 1999 filing date, a POSITA is a person with a bachelor's degree in EE/CS (or equivalent) and 2–4 years' experience in packet-switched network device design, including hands-on familiarity with RSVP (RFC 2205), router queuing/scheduling (WFQ, GPS), and buffer management. Under KSR, this person has ordinary creativity and is not an automaton; combining known elements from the same field is within skill.

---

3. Element-by-element landscape: what each reference alone supplies

Direct and damaging disclosure — the patent's own Admission: the Background states that prior-art RSVP implementations "cannot adjust the amount of reserved bandwidth without clearing the session from end-to-end," and that they "require that the sending host halt the transmission of data." That is an admission of what the art does, and it is also the problem statement that supplies the motivation for (f). It does not admit that any reference solves it.

---

4. The combination cases

Combination A (primary): Woundy + Elwalid + RFC 2205, optionally + Ise

Why these three, and why the POSITA would combine them.

1. Same field, same problem, same protocol. All three are packet-network QoS/reservation references; Woundy and Elwalid both discuss RSVP's classifier/scheduler architecture explicitly (verified text above). Combining references that describe the same protocol stack is the archetypal KSR "predictable variation."
2. Woundy supplies the "dynamic" half. Its express object is to move away from "fixed and inefficient" per-SID bandwidth levels toward dynamic reservation where the amount of reserved resource can be controlled. A POSITA reading Woundy in 1999 would take from it: bandwidth reservations are meant to be re-sized in service.
3. Elwalid supplies the "in-service re-commitment" half. Verified: the Elwalid reference expressly covers a reservation requested "during an established connection" and an intermediate router that "commits the requested bandwidth" on receipt of the RESV message. That is limitations (e) and part of (f) read almost literally — a second reservation message during an ongoing flow that changes the committed bandwidth without tearing down the connection. This is the single most important reference for the non-disruption claim element, because Elwalid's flow-state is established first and the bandwidth commitment is made on the later message.
4. RFC 2205 / Woundy supply the "distinct control message vs. application data" limitation and admission/policy gating.

Motivation to combine, framed for a petition or invalidity contention: a POSITA seeking to satisfy the patent's own stated goal — allowing a receiver to obtain more bandwidth for an active video stream without halting the sender — would have been led directly to Woundy's dynamic reservation scheme and Elwalid's mechanism for committing bandwidth on a message arriving during an already-established flow, because both were known techniques for the same purpose (adjustable QoS reservation in RSVP-capable routers), and the combination yields nothing more than the predictable sum of their disclosures.

Strength: moderate. A through (e) are well met. (f) is met at the level of "adjust the committed bandwidth without tearing down the flow," which is what Elwalid's flow-state mechanism delivers.

Combination B (primary alternative): Ise + Aras

Why. Ise supplies a stored data structure mapping a session/route to capacity and used bandwidth and a computed available amount — useful against claim 16's "resource allocation table independently accessible so the percentage can be altered without disrupting labeling or transport," and against claim 15's "computing/storing a first percentage of total device bandwidth." The verified Ise-family table (ROUTE IDENTIFIER | ROUTE CAPACITY (kbps) | USED BANDWIDTH (kbps)) is a numeric resource table whose modification does not require touching the forwarding path, which is structurally the claim-16 idea. Aras supplies continuous re-computation of available bandwidth (ARIMA forecasting) and its express recognition that unreserved/unconforming load "fluctuates over time," which motivates periodic recalculation of the allocation percentage — i.e., the "dynamically adjusting" step.

Motivation: Aras's problem — predicting how much bandwidth the reservation system can safely promise when non-conforming traffic varies — is precisely the problem a device implementing the claim's percentage calculation faces. A POSITA would combine Aras's forecasting input with Ise's capacity/used-bandwidth table to keep the computed percentage current.

Strength: moderate-to-weak on its own; strong as a secondary showing against claims 15–16.

Combination C (the hard limitation): reaching "label a percentage of data storage locations"

This is where the obviousness case is weakest, and I want to be explicit rather than overstate it.

• What the art of record actually gives you is proportional resource allocation: Elwalid's GPS weights and per-connection "share of the bandwidth … limit[ed] to a specified value," and Aras's per-request allocation. A POSITA would read those as computing a fraction of a resource — which is the percentage of total device bandwidth arithmetic of claim 15.
• What none of the four verified references shows, in the text I retrieved, is the enforcement mechanism: physically marking individual rotating-queue entries with a session identity so that a scheduler that "is unaware of particular sessions" is nevertheless constrained to place exactly N-of-M packets per rotation for that session. That is the patent's actual point of novelty ("manages resources, and is not focused on managing time"), and I found no reference of record that discloses it.
• The strongest available § 103 route to this limitation is a "known technique" / analogous-art argument that I have NOT yet grounded in a reference. The functionally identical idea exists in the art as slotted/slot-reservation channel access: in a frame divided into M slots, assigning a station N of the M slots per frame is a percentage-of-storage-locations bandwidth allocation (N/M of the frame), and simple TDMA/slotted-ring designs do exactly that. If a 1999-or-earlier slotted-ring or TDMA slot-assignment reference is combined with Woundy/Elwalid/RFC 2205, limitation (c) becomes arguable under KSR ("a known technique … used to improve similar devices in the same way"). But I did not retrieve such a reference from this patent's prior-art section, and I will not assert one exists of record. This is a gap that requires a dedicated search (see § 6).

Realistic assessment: a § 103 contention built only on the art cited on the face of the patent is strong for claims' internal-decomposition-independent elements (a), (b), (d), (e) and vulnerable on (c) and the precise "non-disruptive adjustment" wording of (f). The prior art of record would most plausibly support an obviousness rejection of the broadest claims if they were construed to cover any proportional reservation, but the "label storage locations" + "data scheduler ignorant of sessions" architecture is the limitation a patent owner would defend, and the art of record does not obviously reach it.

Claim 28 (means-plus-function) and claim 27 (CRM)

If claim 1's structure is obvious, claim 27 falls with it — a computer-readable medium performing the same steps adds only the Beauregard-type carrier, which is not a patentable distinction. Claim 28's means-plus-function limitations map to the same structures. But recall the earlier section's flag: the retrieved text of claim 28 contains an apparently unrelated clause ("produce a means for accessing presence information…"), which I could not confirm is the literal granted text. Do not brief claim 28 until the official text is verified — a means-plus-function claim with an unverified claim set is not a safe target.

---

5. Secondary considerations and counter-arguments (be candid about these)

• No evidence of secondary considerations found. I retrieved no licensing, no commercial-success, no unexpected-results, and no praise-of-others evidence for 6,876,668. Absence of evidence is not evidence of absence; a patent owner could develop a nexus argument around Cisco's RSVP/QoS product line, and I have not searched Cisco product materials. Do not represent that no secondary considerations exist.
• The "non-disruption" claim cuts both ways. The patent frames a genuine technical advantage (no flush-and-re-establish). If Elwalid's flow-state mechanism is read as NOT avoiding disruption, the patent owner has a real KSR-era argument that the combination would not have achieved the claimed result. Elwalid is my best reference on this point precisely because it commits bandwidth during an established connection — but the reference says nothing about the queue remaining undisturbed.
• Teaching away: I did not find one in the four verified references. The patent's Background (prior art "require[s] that the sending host halt") is the closest thing, and it is an admission of a problem, not a teaching away from the solution.
• Expectation of success is high for the combination rationales in § 4 (A) and (B) — all references sit on the same RSVP classifier/scheduler architecture.

---

6. What must be verified before this analysis is usable

1. Claim 1 verbatim (the earlier section's reconstruction is a placeholder) and claim 28's literal text — pull from USPTO Patent Center / Patent Public Search "Claims."
2. US 6,336,129's filing/priority date — my verification of Ise came from the family (US 6,643,258 / US 2004/0131013), not from 6,336,129 itself. Confirm it qualifies under pre-AIA § 102(e).
3. RFC 2205 and the three RSVP overview references — I did not retrieve them; I relied on the patent's own Background concession. That is usable as an admission but is not a substitute for the printed reference.
4. A dedicated search for slotted/frame-slot reservation art (TDMA slot assignment, slotted-ring / token-queue slot ownership) issued or published before 1999-05-24 — this is the single highest-value search for the one limitation (§ 4, Combination C) the art of record does not clearly reach.
5. Prosecution history — I did not retrieve it. The earlier section noted the claim language is narrower and more RSVP-specific than the specification; the file wrapper may reveal why, and any examiner-stated reasons for allowance or applicant arguments about the labeling mechanism would directly shape the § 103 theory. Worth pulling before investing further.
6. Patent term adjustment — resolves whether the whole exercise has any damages exposure at all.

---

7. Bottom line

• The art of record supports a colorable § 103 case against the claims' reservation-half (receiving an RSVP reservation distinct from data; establishing it; receiving adjustment information in a second RSVP message during the session; adjusting while the flow continues). Woundy + Elwalid + RFC 2205 is the strongest combination, with Ise + Aras as the secondary combination aimed at the percentage-calculation and resource-table limitations.
• The art of record does not, on the text I retrieved, clearly reach the enforcement mechanism — labeling a percentage of rotating-queue storage locations with a session identity so that an otherwise session-ignorant scheduler is bandwidth-constrained. That is the limitation on which the patent would survive, and closing that gap requires finding a slotted/slot-reservation-type reference that I did not locate.
• I have not fabricated a reference or a quote. Everything attributed to Aras, Woundy, Elwalid, and Ise above is from text I actually retrieved, cited at the URL where I retrieved it. Everything about RFC 2205 is drawn from the patent's own Background and flagged as such.
• Practical posture (consistent with the earlier sections): with the patent recorded as expired and no PTAB or litigation activity found, a § 103 challenge is likely worth advancing only if a non-trivial pre-2019 damages claim is actually on the table — and only after confirming PTA on the face of the patent.