US 7092358

I'll search for this specific patent number to verify and check for any litigation dockets.

Let me run a couple more targeted searches to confirm there's no litigation and to cross-check the bibliographic data.

US Patent 7,092,358 — Verification Summary

Sourcing note: My tools are general web search, not a direct USPTO/CAFC docket API. I could not query an authenticated USPTO PatentCenter or the Federal Circuit docket system directly. The bibliographic data below is corroborated across Google Patents (patents.google.com/patent/US7092358), FreePatentsOnline (freepatentsonline.com/7092358.html), and uspto.report (uspto.report/patent/grant/7,092,358), which agree with each other and with the authoritative full text.

---

1. Bibliographic Data

⚠️ Discrepancy to flag, stated literally: The Google Patents record lists the Current Assignee as "Nokia Inc," while the USPTO assignment entry (2004-02-02) and other databases list NOKIA CORPORATION. These are not the same identifier, and I am not auto-correcting one to the other. Google Patents itself carries the disclaimer that listed assignees may be inaccurate. Treat "NOKIA CORPORATION" as the more likely operative assignee given the assignment record, but the discrepancy is noted.

---

2. Abstract (verbatim)

"A system and method of providing flexible QoS actions through communication to neighboring network elements of the local QoS actions taken by the local network element. The neighboring network elements may then take into account the QoS actions taken by the local network element when the neighboring network elements are contemplating their own QoS actions to be taken. Thus, a limited range of visibility of QoS actions facilitates subsequent QoS actions taken by the network elements within the limited range of visibility."

---

3. Technical Field / Problem Addressed

The patent addresses a known weakness in DiffServ (Differentiated Services) IP networking: each router makes QoS decisions locally and independently, based only on the DiffServ codepoint, without knowing that a neighboring router already dropped or delayed packets from the same connection. Chained routes can therefore cumulatively degrade one stream (e.g., a VoIP/video stream) until the receiving codec fails, while other streams are untouched. The invention distributes local QoS actions to nearby network elements so subsequent congestion actions can be spread fairly across different connections — a "limited range of visibility" (in contrast to heavy end-to-end Integrated Services signaling).

---

4. Independent Claims in Plain Language

The patent has 20 claims total, of which four are independent: claims 1, 8, 13, and 20.

Claim 1 — Method (distributing QoS information).
A first network entity watches the congestion level of at least one data stream it is handling. When it performs a QoS action aimed at limiting how much resources that stream consumes, it tells a second network entity that will process that same stream later. The second entity, on learning this, raises the relative precedence of its other data streams for purposes of limiting their resource consumption — i.e., it shifts the burden away from the stream that already got hit, so one connection doesn't absorb repeated QoS penalties.

Claim 8 — System (distributing QoS actions by precedence priority).
A system with: (a) a network element at the network boundary; (b) a first forwarding terminal that exchanges data streams with that element and applies QoS actions to a first subset of those streams, which thereby receives a first precedence priority; and (c) a second forwarding terminal exchanging streams with the first one and receiving signaling about those QoS actions. The second terminal then applies its own resource-limiting QoS actions only to a second subset of streams whose precedence priority is equal to or higher than the first priority — again, sparing the already-penalized streams.

Claim 13 — Communication device (router with QoS unit).
A device with: a routing unit that receives data streams carrying signaling about prior QoS actions taken at earlier network nodes (actions taken to limit resource consumption there); a buffering unit holding the streams; a congestion control unit monitoring how full the buffer is; and a QoS unit. When it needs to relieve buffer pressure, the QoS unit acts on packets whose signaling indicates a lack of prior QoS actions — i.e., it preferentially drops/modifies/delays streams that have not already been penalized, limiting the compounded effect of earlier nodes' actions.

Claim 20 — Computer-readable medium (instructions).
Instructions for applying QoS actions to streams exchanged between two or more applications. On detecting a need to act, the code: (1) retrieves a history of prior QoS actions on each stream; (2) prioritizes that history so that the most recently penalized streams receive a low priority; (3) selects a stream whose priority level is equal to or greater than that low priority; and (4) applies the QoS action to the selected stream — limiting the effect on streams already carrying low priorities.

Common thread across all four independent claims: local congestion relief is deliberately steered away from streams that have already suffered QoS actions, using either in-band codepoint signaling or out-of-band signaling (e.g., SNMP/MIBs) within a bounded neighborhood of network elements.

---

5. CAFC 2026 Docket Search — Result: No Case Found

I searched specifically for a 2026 Federal Circuit docket involving patent 7,092,358 or US7092358B2. My searches returned no CAFC or district-court litigation referencing this patent number. The results I retrieved discussed unrelated patents (e.g., patents in the ASUS/Celerity v. AT&T/Verizon/T-Mobile EDTX dispute, and various unrelated Federal Circuit appeals), so I am not associating any of them with 7,092,358.

Confidence/uncertainty flag: Because I do not have direct, authenticated access to the USPTO PatentCenter or the CAFC docket system, the absence of litigation in my search results is not authoritative proof that none exists. A definitive litigation check would require querying PACER, the CAFC docket, or a commercial litigation database (e.g., Docket Navigator, Lex Machina). Within the scope of what my tools surface, however, I found nothing.

---

6. Additional Notable Points from the Specification

• The patent's own figures and description include a worked example (FIG. 5) where a router that already dropped 10% from stream 504 gives that stream preferential treatment later, so total loss equalizes at 15% across streams instead of 20%/10%/10% absent the invention.
• The description contemplates QoS actions beyond dropping: delay, prioritized transmission, and packet modification (compression/truncation), and states the drop/delay/history/marking units can be substituted accordingly.
• The patent cites the IETF DiffServ framework (Assured Forwarding, per Heinanen et al., RFC 2597; Nichols et al. DS field; Blake et al. DiffServ architecture) as non-patent literature.
• It distinguishes itself from end-to-end Integrated Services QoS on the ground that e2e methods require "heavy control, signalling, and management functions" and thus saw limited adoption.

If you need a hard litigation confirmation, I can attempt additional targeted docket searches, but I want to be explicit that the current result set does not establish one way or the other.

I'll search for litigation involving US patent 7092358.

Let me run more targeted searches on litigation databases.

Litigation Search Results — US Patent 7,092,358

Bottom Line

No litigation is known involving U.S. Patent 7,092,358. My searches of patent-litigation and PTAB resources (including Unified Patents' litigation/PTAB portal, Docket Alarm, USPTO PTAB filings, CourtListener/RECAP, and general web sources) returned no district-court case, no ITC investigation, no PTAB proceeding (IPR/PGR/CBM), and no Federal Circuit or CAFC appeal in which US 7,092,358 was asserted, challenged, or otherwise at issue.

What the Searches Did Return (and why it is not this patent)

To be explicit about the "do not auto-correct / do not return similar numbers" rule, here is what the searches surfaced and why each is distinguishable:

Patent Status (for context, not litigation)

• US 7,092,358 B2 — "System and method for facilitating flexible quality of service"
• Inventors: Jussi Ruutu, Marko Suoknuuti
• Assignee: Nokia Inc / Nokia Corporation (now recorded as Nokia OYJ on some aggregators)
• Application No. US 10/693,002; filed 2003-10-24; granted 2006-08-15
• Publication US 2005/0089042 A1 (2004-04-28)
• Legal status: Expired – Fee Related, adjusted expiration 2023-12-28

The patent's technology (DiffServ/QoS congestion-handling coordination among neighboring routers) is the sort of subject matter that has been asserted by NPEs in wireless/network infrastructure campaigns, but I found no evidence that this specific patent was ever asserted.

Confidence and caveats

• High confidence that no litigation is indexed in the major public litigation/PTAB databases as of this search. The patent's own Docket Alarm/Unified portal records — which typically list related cases when they exist — show none.
• Caveat: I could not run a PACER docket-number-level query or a paid Docket Navigator / Lex Machina search from this environment. It is possible that a very short-lived or sealed case exists that is not captured in the open sources searched. If you require court-record certainty, the recommended follow-up is a direct PACER search on "7,092,358" and a Docket Navigator party/patent query.

Conclusion: Based on available records, US 7,092,358 has no known litigation history. If you need this confirmed at PACER/CAFC docket level, that specific check remains outstanding.

Proceedings overview

Total AIA trial proceedings on file for US 7,092,358: zero (0). The USPTO Open Data Portal structured block for this patent returns no IPR, PGR, or CBM proceeding. My independent web checks (PTAB petition/decision documents, PTAB E2E/PTACTS, Unified Patents portal, Google Patents "Cited By"/"Families Citing" tables, uspto.report) also surfaced no AIA trial naming US 7,092,358 — so the breakdown is 0 active / 0 claims invalidated / 0 claims sustained / 0 settled / 0 institution denied. Bottom-line defensive posture: there is no PTAB record to attack or lean on. All 20 claims (1–20, including independent claims 1, 8, 13, and 20) are untested at the Board. The patent's most important defensive fact is not a PTAB outcome at all — it is its expiration (adjusted expiration 2023-12-28 per the structured record), which I address in the strategic summary.

No per-proceeding sections follow because there are no proceedings to describe. Inventing an IPR number here would be fabrication, so I have not done it.

What I searched, and what I found (verification trail)

False-positive flag (do not auto-correct these into US 7,092,358). Web results are littered with different patents that share the trailing digits "358" and are frequently mistaken for this one:

• U.S. 9,708,358 (Columbia/Qiagen v. Illumina; IPR petition by Illumina) — a DNA-sequencing patent, not this one.
• U.S. 7,106,358 (Telepresence Communications; Motorola v. Microsoft) and U.S. 7,096,358 (MAZ Encryption v. Apple) — neither is this patent.
• Medtronic v. Barry / "the '358 patent" (spinal derotation, Fed. Cir.) — a different '358 entirely.
• JP 7092358 B2 (ultrafine bubble generator, Tokyo Univ. of Science) — a Japanese patent that happens to print as "JP7092358."

None of these is US 7,092,358. Anyone running a docket-clearing search on "7092358" will trip over them; treat them as noise.

Strategic summary

Claim status. Because no AIA trial was ever instituted, nothing has been canceled, narrowed, or disclaimed at the PTAB. Independent claims 1 (method), 8 (system), 13 (communication device), and 20 (computer-readable medium) all stand as issued, together with dependent claims 2–7, 9–12, 14–19. The only claim-level changes of record are those made during prosecution — not litigation or PTAB history — so the issued claim set is the operative one. Practically, a defendant's invalidity attack must be built from scratch, in district court or in a first-ever AIA petition, with no estoppel, no FWD reasoning, and no PTAB-tested prior art to borrow.

The dominant fact is expiration, not invalidity. The structured record shows legal status "Expired - Fee Related," with an adjusted expiration of 2023-12-28. That means:

• No prospective injunctive relief. An expired patent cannot be infringed going forward; only past damages are on the table, and only for acts within the six-year lookback of 35 U.S.C. § 286 measured from the complaint date. A pre-2020 damages theory is time-barred by § 286 absent tolling/exception arguments.
• The IPR clock is effectively irrelevant for future conduct but not for past damages — an IPR can still be filed against an expired patent to knock out past-damages exposure, subject to the § 315(b) one-year bar if the defendant has been served. There is no estoppel obstacle because no one has petitioned before.
• Whether the "expired for fee non-payment" characterization reflects the curable § 41(c) window is a factual question for the patent owner / USPTO PatentCenter; do not assume the record is stale without checking the fee history at USPTO PatentCenter.

Estoppel landscape. § 315(e)(2) estoppel is empty — it attaches only to petitioners who reach an FWD, and there have been none. Likewise no § 325(e)(1) PGR estoppel and no CBM estoppel. Caveat: the expired-patent posture also means a PGR is unavailable (PGR is limited to patents with a claim having an effective filing date on or after 2013-03-16, and to a 9-month post-grant window linked to issuance in 2006 — long gone). For a defendant today, the realistic AIA vehicle, if any, is an IPR on § 102/§ 103 grounds, filed within one year of service.

Pattern signals. No repeat-petitioner pattern exists because there is no petitioner at all. There is also no defensive-aggregator footprint on this patent — Unified Patents lists US-7092358-B2 only as a portfolio entry, not as a challenge target. One ownership lead worth verifying (I could not confirm it applies to this patent): a Patent Purchase Agreement between Nokia Technologies Oy / Nokia Solutions and Networks B.V. / Alcatel Lucent SAS and Provenance Asset Group LLC appears at USPTO Reel 043877, Frame 0364, and that kind of Nokia→Provenance transfer is precisely how mid-2000s Nokia networking patents ended up in assertion campaigns. The patent's own assignment record shows only the original chain (Nokia Inc, filed 2003-10-24; assigned to Nokia Corporation on 2004-02-02). Check the current recorded owner in PatentCenter before treating Nokia as the real party in interest — a Provenance or PAE assignment materially changes the litigation calculus.

Recommended next steps

1. If you are a defendant and the demand cites claims 1, 8, 13, or 20: those claims have not been invalidated. There is no FWD to link to and no canceled-claim shield to invoke. Do not represent to a court or opposing counsel that this patent has been PTAB-tested — it has not.
2. Run the expiration/§ 286 analysis first. Confirm the fee status and adjusted expiration (2023-12-28 per the structured record) in USPTO PatentCenter. If the patent is truly expired, drop injunction and ongoing-royalty theories and cap exposure to the six-year lookback; then assess whether the asserted past-sales period is even within that window.
3. Confirm ownership in the assignment record (Reel/Frame chain from the 2004-02-02 Nokia Corporation assignment forward, including any Provenance Asset Group transfer at Reel 043877, Frame 0364) to identify the correct real party in interest before negotiating.
4. If you intend to file an IPR, mind § 315(b): the one-year clock runs from service of a complaint alleging infringement of this patent. There is no prior petitioner whose estoppel or prior-art work you can inherit — you build the § 102/§ 103 record yourself, and the patent's own cited art (Lucent/Pluris/Nortel/Cisco/Cascade references listed in the 25-item "Patent Citations" table) is a natural starting point.
5. If instead you want affirmative confirmation, search PTAB E2E / PTACTS for the patent number directly before relying on this report. The absence of PTAB activity here is a real signal — a 2006 networking patent expired in 2023 never drew a single IPR — but it is a negative finding and should be re-verified against the live ODP feed on the day it matters.

Confidence note: I have high confidence in the zero-proceeding finding, since it is consistent across the canonical ODP block and my secondary searches. I have lower confidence in the ownership lead (Provenance Asset Group) as applied to this specific patent — I saw the Nokia→Provenance purchase agreement in a PTAB exhibit but could not verify that US 7,092,358 is listed on its Exhibit A. Verify before relying on it.

I'll research this patent's assignment record before producing the analysis.

Let me dig deeper on possible post-issuance transfers (Nokia portfolio sales) and any litigation involving this patent.

US Patent 7,092,358 — Assignment & Ownership Analysis

Verification entry points: USPTO Assignment Center · legacy Assignment Search (search 7092358 / 10/693,002) · Google Patents legal events · uspto.report grant page

Data-availability caveat up front (read before using the timeline): I was not able to complete a live query of the Assignment Center record detail page for this patent within this session. The reel/frame numbers and the correspondent of record for the one assignment that is documented in the public sources below were therefore not retrieved, and I will not invent them. Everything below is grounded in Google Patents' legal-events panel, the patent face, and uspto.report; where a required field is missing, it is marked not retrieved rather than guessed.

---

Inventors

Unusual-pattern check: Not determinable from the data retrieved. Both inventors are recorded as assigning to Nokia Corporation on 2004-02-02 — i.e. a conventional, contemporaneous inventor-to-employer assignment, not a departure-triggered transfer. I found no evidence of either inventor leaving Nokia within 12 months of the 2003-10-24 filing, and I will not infer one. (Jussi Ruutu is a long-tenured Nokia researcher, but that is background, not an assignment-record finding.)

---

Original assignee

Nokia Corporation (Keilalahdentie 4, Espoo, Finland) — recorded as assignee via the 2004-02-02 assignment of assignors' interest from Ruutu and Suoknuuti.

• Naming inconsistency to be aware of: Google Patents lists the original assignee as "Nokia Inc" (the US subsidiary, 6000 Connection Drive, Irving, Texas — the entity that appears on many Nokia US filings of that era), and the Unified Patents portal shows "Nokia OYJ"; uspto.report states the patent is "currently assigned to Nokia Corporation." Nokia Inc., Nokia Oyj, and Nokia Corporation are the same corporate family — a US subsidiary, the Finnish parent's Finnish-language and English-language names — not separate assignment links. There is no record of a Nokia Inc. → Nokia Corporation transfer, so this is a database-labeling variant, not a chain link.
• Line of business / product embodiment: Nokia in 2003–2006 was a mobile-handset and network-infrastructure manufacturer; the patent sits in its IP-routing / DiffServ traffic-management work (Nokia Research Center, Finland) and is directed at congestion control inside IP routers. Nokia did market IP routing/gateway platforms in that period, but I cannot confirm from the record that any shipped Nokia product embodied claims 1–20, so treat "shipped product" as unverified rather than established.
• Current status: Nokia Corporation remains an operating company (devices business divested to Microsoft in 2014; networks business consolidated through Nokia Solutions and Networks / Alcatel-Lucent; patent holdings reorganized into Nokia Technologies Oy). The patent itself is expired — Google Patents legal status: Expired – Fee Related, adjusted expiration 2023-12-28. It is in the public domain.

---

Assignment timeline

Chronological recorded/posted events. Only one assignment of record was surfaced. No reel/frame or correspondent was retrievable.

• 2003-10-24 (filing date; execution date matches) / recorded — Reel not retrieved

  • Conveyance: Assignment of assignors' interest (inventor → company), per Google Patents event "Assigned to NOKIA CORPORATION … ASSIGNMENT OF ASSIGNORS' INTEREST"
  • Assignor: Jussi Ruutu; Marko Suoknuuti
  • Assignee: Nokia Corporation
  • Correspondent: not retrieved
  • Context: standard inventor-to-employer assignment executed at filing; no acquisition, fire-sale, or securitization character.

  (Note: the same-date "Application filed by Nokia Inc" event is a filing/ownership-of-record entry, not a separate assignment.)

• 2004-02-02 (recorded) / — Reel not retrieved

  • Conveyance: Assignment (reassignment entry on Google Patents legal events)
  • Assignor: Ruutu, Jussi; Suoknuuti, Marko
  • Assignee: Nokia Corporation
  • Correspondent: not retrieved
  • Context: internal/administrative perfection of the inventor assignment to the parent — the only recorded assignment in the chain.

No post-issuance assignment, security agreement, merger, change-of-name, license, or release appears in any source checked. That is itself the finding: the patent never left the Nokia corporate family.

---

Timeline diagram

timeline
    title Ownership of US 7092358
    2003 : Filed by Nokia
    2004 : Inventors assign rights to Nokia Corporation
    2006 : Patent issued to Nokia Corporation
    2023 : Patent expired fee related

(The single 2004 assignment link is the only ownership transfer of record; the pre-2004 "Nokia Inc" and post-2004 "Nokia OYJ" labels are the same family, so they are not drawn as separate events.)

---

NPE / troll-pattern signals

---

Verdict

Insufficient data — in the strict sense the rubric defines ("no records, or only the original assignment").

The entire recorded chain is a single 2004-02-02 inventor-to-employer assignment from Ruutu and Suoknuuti to Nokia Corporation; no post-issuance assignment, security interest, merger, or change-of-name appears in Google Patents' legal events or in the secondary sources checked, and no litigation naming this patent was surfaced. Substantively, this is a clean single-owner operating-company patent that was never asserted and never transferred out of the Nokia family, and it expired (fee-related) on 2023-12-28. None of the eight NPE signals is "present"; the only residual uncertainty is the non-retrievable reel/frame and correspondent fields on the one recorded assignment, plus the unverified question of whether this patent rode along in the Nokia → Provenance Asset Group purchase (Reel 043877/Frame 0352) — confirm both directly at the USPTO Assignment Center before relying on this as a final chain-of-title opinion.

I'll search the USPTO and patent databases to verify the patent and examine each cited reference.

Let me verify the two references that are the strongest anticipation candidates—the congestion-notification and QoS-feedback references—plus the Assured Forwarding RFC.

Prior Art Analysis — US Patent 7,092,358 B2

Patent under analysis: US 7,092,358 B2 ("System and method for facilitating flexible quality of service"), App. No. US 10/693,002, filed 2003‑10‑24, granted 2006‑08‑15, inventors Jussi Ruutu and Marko Suoknuuti, assignee Nokia.

Methodology note. The USPTO full‑text page (source of the authoritative record) lists the references the Examiner considered. I worked from that citation list rather than relying on training data, and I verified several of the closest items against Google Patents / Espacenet / FreePatentsOnline / Unified Patents. Two caveats stated up front:

• This patent granted over every reference below, so the Examiner did not find, and I do not assert, that any single reference anticipates the claims as allowed. "Potentially anticipates" below means "the reference discloses elements that map onto claim language and is the class of art that a §102 challenge would be built on" — not "the reference was held to anticipate."
• A true §102 anticipation requires a single reference disclosing every limitation of a claim, arranged as in the claim. Where a reference discloses only part, I say so and note it is §103‑class art.

The four independent claims (all grounded in the authoritative claim text) are:

• Claim 1 (method): monitor congestion of a data stream at a first network entity → perform a QoS action limiting that entity's resource consumption by the stream → communicate the QoS action to a second network entity that subsequently processes the stream → second entity increases relative precedence for limiting consumption by its other data streams.
• Claim 8 (system): boundary network element + first forwarding terminal applying QoS actions to a first stream portion (giving it a first precedence) + second forwarding terminal receiving signalling of those actions, acting on a second portion having precedence ≥ the first.
• Claim 13 (device): routing unit receiving streams carrying signalling of prior QoS actions at earlier nodes + buffering unit + congestion control + QoS unit that acts on streams whose signalling indicates a lack of prior QoS actions.
• Claim 20 (CRM): retrieve history of prior QoS actions → prioritize so most‑recently‑penalized streams get low priority → select a stream at/above that low priority → apply the QoS action.

---

Tier 1 — Closest art (the references a §102 challenge would target)

1. WO 02/052801 A1 / US 2004/0090917 A1 — "Selecting data packets" (Ruutu, Nokia)

• Full citation: WO 02/052801 A1 to Nokia Corporation (inventor Jussi Ruutu), published 2002‑07‑04; US counterpart US 2004/0090917 A1, published 2004‑05‑13; priority GB 0031536.6 dated 2000‑12‑22; US App. 10/450,612.
• Description: Maintains a drop history identifying flows from which packets were recently dropped and selects the next packet to drop so it is not consecutive with (and preferably not in) the already‑penalized flow, spreading loss across flows. Explicitly aims to avoid a single application flow suffering consecutively lost packets — the same fairness rationale as the patent at issue. It also discusses DiffServ codepoints and drop schemes (DropTail, RED, etc.).
• §102 relevance: This is the most material reference and, notably, shares an inventor and assignee with the patent. It discloses the "history of prior QoS actions" and "prioritize … most recently … receive a low priority" concepts of claim 20, and the "prioritizing the recorded QoS actions … least most recently modified data stream" language of claim 4, and the drop action of claim 5. However, it operates locally at a node based on that node's own drop record; it does not disclose receiving signalling from a second/upstream network entity about a QoS action that entity took, nor the downstream "increase the precedence of other streams" step. So it maps strongly onto claims 4, 5, 20 (history/prioritization portion) but not the inter‑node communication element central to claim 1. Best characterized as §102‑adjacent for the history/prioritization limitations and strong §103 art for the remainder.

2. US 5,828,653 A — "Quality of service priority subclasses" (Cascade Communications)

• Full citation: US 5,828,653 A, Goss, filed 1996‑04‑26, granted 1998‑10‑27, assignee Cascade Communications Corp.
• Description: In an ATM network element, each QoS queue has thresholds/trip points; at the onset of congestion, cells within a QoS of lower priority are discarded while higher‑priority cells are enqueued (plus the CLP bit for finer discard priority). Explicitly: "different traffic streams within a single queue have different priorities, enabling intelligent discard of lower priority traffic … before the respective queue is full."
• §102 relevance: Discloses the "precedence priority … in response to the QoS actions" mechanism and the notion of preferentially acting on higher‑precedence (less‑protected) streams when a congestion threshold is exceeded — the "limits consumption … by the at least one data stream" concept of claim 1 and the precedence‑ranking concepts behind claims 1/8/13. Critically, it is wholly local (a single ATM switch) and discloses no communication of the QoS action to another network entity. Therefore it does not anticipate claims 1, 8, 13, or 20, but it is the strongest cited reference for the precedence‑priority‑on‑threshold half of the independent claims.

---

Tier 2 — Directly relevant to specific claim elements (mainly §103 art)

3. US 6,535,482 B1 — "Congestion notification from router" (Nortel)

• Filing 1998‑05‑08; granted 2003‑03‑18. A congested router sends an indication of its congestion degree to the source / other nodes at the network layer (e.g., ICMP Source Quench), optionally marking the packet; downstream routers may act when they find the CE bit already set. Expressly addresses multiple congested routers in the path and "flow control fairness."
• §102 relevance: Directly implicates the "communicating the QoS action to a second network entity" element of claim 1 and the in‑band signalling of claim 6. But its purpose is to make the source reduce its rate, not to make a downstream node increase the precedence of its other streams to spare the already‑hit stream — so it does not fully anticipate claim 1. Strong §103 art against the communication limitation.

4. US 6,822,940 B1 — "Method and apparatus for adapting enforcement of network QoS policies based on feedback about network conditions" (Cisco Technology)

• Filing 2000‑09‑29; granted 2004‑11‑23. Adapts QoS policy enforcement in response to feedback about network conditions.
• §102 relevance: Relevant to the feedback/signalling loop of claims 1, 6, and 7 (in‑band and out‑of‑band communication of a QoS action). The feedback is about conditions/enforcement, not a neighbour's specific drop/delay action used to re‑rank other streams, so it does not anticipate the independent claims.

5. US 6,826,147 B1 — "Method and apparatus for aggregate flow control in a differentiated services network" (Nortel)

• Priority US 60/220,631 filed 2000‑07‑25; granted 2004‑11‑30. DiffServ drop‑precedence marking (dp0/dp1/dp2) at edge devices, AF PHB at the core, a credit system, and control packets monitored for drop occurrence in the core with the edge adjusting forwarding accordingly.
• §102 relevance: Closely matches the DiffServ/AF and drop‑precedence framework underpinning the specification and claims 1, 8, 13 (precedence priorities; edge/applies filtering; monitoring drop occurrence of data in the network). Like the others, the "monitor drop occurrence" is used to modulate the sender's own rate, not to shift QoS actions onto other streams at a downstream node — so §103‑class, not a clean §102 hit.

6. US 6,625,118 B1 — "Receiver based congestion control" (Nortel)

• Filing 1998‑05‑08; granted 2003‑09‑23. Receiver‑based congestion control — congestion handling driven by downstream feedback.
• §102 relevance: Relevant to the downstream‑node‑reacts‑to‑upstream‑information concept of claims 1/8; does not disclose the "increase precedence of other streams" limitation.

7. US 2003/0088690 A1 — "Active queue management process" (Moshe Zuckerman)

• Filing 2001‑08‑09; published 2003‑05‑08. Active queue management (early drop/mark as a queue fills).
• §102 relevance: Maps onto "congestion control unit adapted to monitor a storage level of the buffering unit" (claim 13) and the threshold‑triggered action of claims 1/13. No inter‑node signalling.

8. US 6,252,848 B1 — "System performance in a data network through queue management based on ingress rate monitoring" (Pluris)

• Filing 1999‑03‑22; granted 2001‑06‑26. Queue management driven by ingress rate monitoring, queue/threshold adjustment.
• §102 relevance: Background on threshold‑based queue management (claim 13 congestion monitoring); no cross‑node QoS‑action distribution.

9. US 6,631,135 B1 — "Method and apparatus for negotiating Quality‑of‑Service parameters for a network connection" (Nortel)

• Filing 2000‑03‑27; granted 2003‑10‑07. QoS parameter negotiation for a connection.
• §102 relevance: Relevant to the "precedence priority"/QoS‑parameter signalling background of claims 8/13; not an anticipation reference.

10. US 2003/0081547 A1 — "Signaling for parameterized quality of service (QoS) support" (Jin‑Meng Ho)

• Filing 2001‑11‑01; published 2003‑05‑01. Signalling to support parameterized QoS.
• §102 relevance: Bears on the signalling limitations of claims 6 and 7 (providing signalling information indicative of a QoS action). Does not disclose distributing a congestion‑triggered QoS action to a neighbouring node for fair re‑ranking.

11. US 2002/0191622 A1 — "System for and method of differentiated queuing in a routing system" (Zdan)

• Filing 2001‑06‑18; published 2002‑12‑19. Differentiated queuing (queue structures per class/priority).
• §102 relevance: Supports the "buffering unit … QoS unit" architecture of claim 13 and the AF/queue treatment described in the spec; no cross‑node action signalling.

12. US 2004/0090914 A1 — "Communications network" (Briscoe, Robert J.)

• Filing 2001‑03‑07; published 2004‑05‑13. DiffServ‑style class‑of‑service handling in a communications network.
• §102 relevance: Background on differentiated handling/precedence (claims 1/8); no anticipatory disclosure of the claimed distributed QoS‑action fairness method.

13. US 6,744,767 B1 — "Method and apparatus for provisioning and monitoring Internet Protocol quality of service" (AT&T)

• Filing 1999‑12‑30; granted 2004‑06‑01. Prov. and monitoring of IP QoS.
• §102 relevance: Background on QoS provisioning/monitoring; not per‑claim anticipatory.

14. US 2004/0022191 A1 — "Network quality of service for qualitative applications" (Yoram Bernet) — priority 1999‑11‑30; published 2004‑02‑05.

• §102 relevance: General QoS‑for‑applications background (incl. the "qualitative applications"/codec‑tolerance theme of the patent's background). Not anticipatory.

15. US 2004/0081093 A1 — "Policy based quality of service" (Haddock) — priority 1998‑02‑03; published 2004‑04‑29.

• §102 relevance: Policy‑based QoS enforcement background; not anticipatory.

16. US 2005/0007954 A1 — "Network device and method for categorizing packet data flows and load balancing for packet data flows" (Nokia)

• Filing 2003‑07‑11; published 2005‑01‑13. Flow categorization and load balancing across flows.
• §102 relevance: Note this is a Nokia filing after (and roughly contemporaneous with) the patent at issue; its flow‑categorization/load‑balancing theme touches the "distribute effects among streams" idea but does not disclose communicating a QoS action to a downstream node that then re‑ranks other streams. §103‑class at most. (Also caution: as a post‑priority Nokia publication it may be more relevant as a family‑mate citation than as prior art.)

---

Tier 3 — Peripheral citations unlikely to bear on any claim

These are cited but disclose unrelated or only tangentially related subject matter. None provides the "communicate the QoS action to a neighbouring node → downstream node spares the already‑hit stream" combination:

---

Non‑patent literature (the standards that define the claim vocabulary)

1. J. Heinanen et al., "Assured Forwarding PHB Group," RFC 2597, June 1999, pp. 1–10. Defines the four AF classes and three drop‑precedence levels (AF11–AF43) — the exact "AF class, drop precedence" vocabulary used in claims and the Table 1 of the specification. Bearing on the "precedence priority" limitations of claims 1 and 8. Standards reference, not standalone anticipation.
2. K. Nichols et al., "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers," RFC 2474, Dec. 1998, pp. 1–18. Defines the DSCP codepoint — the "signal within the data stream" of claim 6 and the packet‑marking mechanism of claim 19.
3. S. Blake et al., "An Architecture for Differentiated Services," RFC 2475, Dec. 1998, pp. 1–33. The DiffServ architecture (classification/conditioning at boundaries, PHB at interior nodes) that frames claim 8's "network element coupled to a boundary."

These three are background/definitional; they supply claim terms but do not disclose the invention's distinguishing feature (bounded‑range propagation of a QoS action so a downstream node re‑ranks other streams).

---

Bottom line

• Most relevant single reference: the Nokia "Selecting data packets" family (US 2004/0090917 A1 / WO 02/052801 A1, Ruutu) — same inventor/assignee; it discloses the drop‑history/prioritization‑to‑spread‑loss mechanism that underlies claim 20 and dependent claims 4–5, but only locally (no upstream‑signalling + downstream‑re‑ranking).
• Best §102 candidates for the precedence‑on‑threshold element: US 5,828,653 A (Cascade) and US 6,826,147 B1 (Nortel).
• Best §102 candidates for the communicating‑to‑a‑neighbouring‑node element: US 6,535,482 B1 and US 6,822,940 B1.
• No cited reference discloses all elements of any of independent claims 1, 8, 13, or 20 in a single reference, which is consistent with the patent having granted. The strongest realistic challenge to the patent is a §103 combination — e.g., a threshold‑based priority‑drop reference (Cascade 5,828,653) or a DiffServ drop‑precedence reference (Nortel 6,826,147) in view of a congestion‑notification/feedback reference (Nortel 6,535,482 or Cisco 6,822,940), and/or the Ruutu drop‑history reference — to supply the inter‑node communication and the downstream "spare the already‑hit stream" limitation.

---

Discrepancies flagged (per the "do not auto‑correct" rule)

• Publication date of US 2005/0089042 A1: the earlier litigation summary listed "(2004‑04‑28)" in one spot; the authoritative record gives 2005‑04‑28. The 2005‑04‑28 date is correct.
• Priority date: the Google Patents/authoritative record gives 2003‑10‑24; a secondary aggregator (Unified Patents) listed 2003‑10‑23. Stated literally, not reconciled.
• Assignee: authoritative assignment record and uspto.report give Nokia Corporation / NOKIA CORPORATION; Google Patents' "Current Assignee" field shows "Nokia Inc," and the litigation summary noted one aggregator showing "Nokia OYJ." Not auto‑corrected.
• Claim 8 textual irregularity: the authoritative claim text contains an apparent typographical error ("by en a first portion"); I have quoted/paraphrased the claim as written without correcting it.

I'll ground the analysis in the prior-art list from the patent page, with a few verification searches on the key primary references.

Obviousness Analysis — U.S. Patent 7,092,358 B2

"System and method for facilitating flexible quality of service"

Under 35 U.S.C. § 103 (pre-AIA, as the application was filed 2003-10-24)

---

0. Scope, methodology, and evidence caveats

Governing framework. Because US 10/693,002 was filed before 2013-03-16, pre-AIA § 103(a) and pre-AIA § 102 art categories govern. KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007), applies to pre-AIA patents and controls the motivation-to-combine analysis, superseding rigid application of the teaching-suggestion-motivation test. The Graham v. John Deere factors apply: (1) scope/content of the prior art; (2) differences between prior art and claims; (3) level of ordinary skill; (4) secondary considerations.

Evidence base and limits. The prior art I am permitted to use is the set recited on the patent page itself ("Patent Citations (25)" / "Citations (24)" and the three Non-Patent Citations). For most of these I have only the bibliographic record, title, and the patent's own characterization. I ran verification searches on four key references and have fuller disclosure text for those; those are marked ✅ below. Where I describe a reference's teachings from its title or the '358 specification's characterization alone, that is an inference, not a verified quotation, and a formal invalidity contention would require full-text citation with column/line cites.

Two literal-count observations from the page (not auto-corrected):

• The page presents "Citations (24)" and a separate "Patent Citations (25)"; the 25th entry is US 2004/0090917 A1 (Ruutu, "Selecting data packets"), the U.S. counterpart of WO 2002/052801 A1. That reference matters a great deal (Section 4).
• Google Patents lists the Current Assignee as "Nokia Inc," while the assignment record and EP family members list Nokia Corporation — the discrepancy flagged in the prior section stands and is not resolved here.

---

1. Identifying the actual inventive hook being tested

The '358 specification's background section concedes almost everything the claims recite as environment:

• DiffServ codepoint marking and per-hop behavior are admitted prior art ("The basic idea of DiffServ networks is that ingress data packets receive stamps called DiffServ codepoints...").
• Local, per-router drop decisions are admitted prior art.
• The problem is admitted: "if other IP routers in the forwarding path select the same data connection for QoS actions, then a possibility exists that the cumulative QoS actions of the daisy chained IP routers will adversely affect the final QoS."
• The desired solution is admitted: "It would, therefore, be desirable to implement a QoS solution that provides an expanded view of the cumulative QoS operations being performed on a particular data connection, while decreasing the amount of processing required of the e2e QoS methods."

Those are applicant admissions usable as prior art and, more importantly for § 103, they supply the design incentive (KSR rationale (D): known technique applied to a known device ready for improvement).

Against that admitted backdrop, the only limitations that carry weight are:

H1 and H2 are the two limitations an obviousness case must reach. The rest — buffering, congestion-threshold monitoring, drop/delay/modify, DiffServ marking, drop-history storage — is patentably weak on its face.

Level of ordinary skill (PHOSITA): a B.S. in EE/CS (or equivalent) plus ~3–5 years of experience in packet-switched network design, including DiffServ/AF and queue management, or an M.S. with ~1–2 years. This is a mature, well-documented art with three IETF RFCs cited as NPL.

---

2. Prior art landscape — what each reference supplies

Grouping the cited art by the limitation it can supply:

Group A — DiffServ architecture, AF drop precedence, codepoint marking (supplies the mechanism of H2, and the "precedence priority" vocabulary of claim 8)

Group B — Router-originated congestion notification / feedback (supplies H1)

Group C — Adaptive/feedback-driven QoS policy enforcement (the single strongest teaching for H1+H2 together)

Group D — Queue management / history-based drop selection (supplies the "retrieve history → prioritize → select" mechanics of claims 4, 17, 18, 20)

Group E — Edge-to-edge coordination in DiffServ, incl. reacting to drops elsewhere (supplies H1 at the network level)

Additional cited art (US 6,021,116 A1 Lucent virtual queues; US 2003/0081547 A1 Ho parameterized QoS signaling; US 2003/0112756 A1 Le Gouriellec MPLS LSP bandwidth subscription; US 2003/0202476 A1 Harris ad-hoc QoS routing; US 2003/0231594 A1 Xu wireless QoS; US 2004/0022191 A1 Bernet qualitative QoS; US 2004/0090914 A1 Briscoe communications network) is peripheral but collectively confirms that per-flow QoS reservation, signaling of QoS state between nodes, and QoS-aware selection/routing were all routine by 2003.

---

3. The prior art "quotation" problem and why it does not save the claims

Critically, the '358 does not claim a new physical mechanism. Every structural element it recites is in the prior art:

• routing unit + output buffer + congestion monitor + drop unit → Ruutu '801 ✅ (identical architecture, incl. a drop history unit)
• codepoint marking to reflect changed drop precedence → RFC 2474/2597, NPL
• a node receiving congestion/QoS information from elsewhere and changing which flows it penalizes → Cisco '940 ✅
• a node altering its treatment of a flow because of drops that occurred at another node in the core → Nortel '147 ✅
• a node reading an upstream node's congestion indication and suppressing its own action → Nortel EP 0 955 749 ✅

The only thing left is H2's sign convention: the prior art teaches penalizing based on current congestion/rate; the '358 claims penalizing based on prior QoS actions recorded against that same stream, so as to spare it. That inversion is where any § 103 attack lives — and Section 7 explains why it is, on these references, a design choice rather than an invention.

---

4. Strongest combination: Ruutu WO 2002/052801 ('917) in view of Cisco US 6,822,940, optionally further in view of Nortel US 6,535,482

This is the most dangerous combination because the primary reference is the same inventors' and same assignee's own earlier application, directed to the same problem ("multiple lost IP packets of the same data stream," codec failure) with the same architecture (routing unit, output buffer, drop unit, drop history unit) and the same solution logic (maintain a per-flow record of which stream was last hit; do not hit it again; distribute loss across streams).

What Ruutu '801 lacks: it is purely local. Its drop history is populated only by drops at that router; it does not receive or propagate any indication of QoS actions taken by other nodes. So it does not literally disclose H1 (inter-node communication) nor the "signalling indicates a lack of prior QoS actions" wording of claims 13/20.

What supplies H1 and closes the gap:

• Cisco '940 supplies the feedback loop: receive then-current network conditions, select flows, and move them to a different service level. ✅ Verified abstract language.
• Nortel '482 / EP 0 955 749 supplies router-originated congestion signaling between nodes plus the node-suppression logic. ✅ (EP text verified)
• Nortel '147 supplies the teaching of reacting to drop occurrences elsewhere in the core — exactly the "prior QoS actions at network nodes that previously processed the data streams" language of claim 13. ✅ Verified.

Claim-1 mapping (Ruutu '801 + '940):

Motivation to combine (KSR): The two references are in the same field (DiffServ QoS at IP routers), address the same problem (consecutive drops killing real-time codecs), and the combination is the straightforward engineering extension of Ruutu's local fairness rule to a path of routers. KSR rationale (C)/(D): using a known technique (per-flow QoS-action history) to improve a similar device in the same way, yielding the predictable result of smoother end-to-end loss distribution. The '358's own background supplies the incentive verbatim.

§ 103(c) caution (important and must be flagged): If US 2004/0090917 and WO 2002/052801 name Ruutu and Suoknuuti as a joint inventive entity (the EP 1344354 register entry lists both Ruutu and Suoknuuti as inventors ✅), then Ruutu '801 is not "by another" and is not § 102(e) art as to the '358; and because both are commonly owned by Nokia, pre-AIA § 103(c) may disqualify it as prior art for obviousness. On the page as fetched, US 2004/0090917 is listed with a single inventor ("Jussi Ruutu"), which would make it a different inventive entity and thus available art — but the EP family record contradicts this. This ownership/inventorship question is decisive for this combination and cannot be resolved from the page alone. Recommendation: obtain the front page of US 2004/0090917 and the assignment records before relying on this ground.

---

5. Secondary combination: Cisco US 6,822,940 + Nortel US 6,826,147 + RFC 2597 (Heinanen)

Avoids the § 103(c) problem entirely — none of these are Nokia/Nokia-assignee art.

• '940 (primary) → adaptively selects flows and demotes them to a lower service level based on then-current congestion feedback, with per-flow identification and header marking. This discloses most of claims 13–19's architecture-plus-behavior and claim 20's "select a stream and apply the QoS action."
• '147 (secondary) → (i) supplies dp0/dp1/dp2 drop-precedence and AF PHB semantics; (ii) supplies the exact problem ("multiple congestion points in the core," conformant aggregates punished by congestion elsewhere); (iii) supplies edge/nodes adjusting forwarding behavior based on monitored drop occurrence elsewhere in the core via control packets. This is the closest thing on the page to H1 in a DiffServ-native setting.
• RFC 2597 / RFC 2474 / RFC 2475 (NPL) → precedence levels and codepoint marking/rewriting for claims 6, 10, 12, 19.

Motivation: All three are directed to the same problem — preventing unfair, cumulatively punitive QoS treatment of a flow traversing multiple congested core nodes. '147 explicitly identifies the multi-congestion-point problem and solves it by making node treatment depend on drops observed elsewhere; '940 explicitly provides the "select flows and re-assign service level based on network feedback" engine; RFC 2597 provides the drop-precedence ranks that make "raise the relative precedence of the other flows" implementable without any new mechanism. Rationale (A): combination of known elements according to known methods to yield the predictable result of fairer loss distribution. Rationale (F): '147's design incentive ("improve fairness") expressly prompts the variation.

Gap to argue: Neither '940 nor '147 explicitly states the sign inversion (spare the frequently-penalized flow; hit the un-penalized flows). That is the battleground.

---

6. Third combination: Nortel US 6,826,147 + US 6,535,482 + Pluris US 6,252,848 (or Zuckerman US 2003/0088690)

A purely DiffServ/queue-management attack that avoids both the Nokia-art and the Cisco-art issues, at the cost of needing more references and more argument.

• '147 + '482 → core drops are observed by edges; nodes coordinate their treatment (H1).
• '252,848 / '690 → buffer-occupancy threshold triggering and per-flow drop selection from maintained state (claim 2, claim 14/15 threshold logic).
• This combination maps cleanly to claims 1–7, but the "compare to prior QoS actions on that stream rather than to current congestion" element is still the weak link.

For claim 8, add Haddock US 2004/0081093 (policy-based QoS defining precedence classes) and Zdan US 2002/0191622 (differentiated queuing), plus the boundary-conditioning teaching of RFC 2475.

---

7. Motivation to combine — consolidated KSR rationales

On the "reciprocal screening" limitation specifically: the strongest § 103 argument is that it is the complement of a teaching already in the art. Ruutu '801 teaches "do not pick the stream that was just hit." Cisco '940 teaches "use network feedback to decide which flows to demote." A POSITA implementing Ruutu's rule in a multi-router DiffServ domain, given '482/'147's inter-node signaling, would necessarily arrive at "downstream router avoids the stream already flagged" — the result being the admitted desideratum. That is precisely the situation KSR describes as "[t]he combination of familiar elements according to known methods is likely to be obvious when it does no more than yield predictable results."

---

8. Dependent claims — all are independently weak

Note: Every dependent claim adds only mechanism that the cited art already discloses. If the independent claims fall under § 103, the dependents fall with them.

---

9. Where the obviousness case is weakest (candor about the counterarguments)

A rigorous analysis must identify the defenses the patent owner would raise:

1. The sign inversion is not literally taught. No reference on this page states, in so many words, "a downstream node shall increase the precedence of other streams to spare a stream already penalized." Patent owner will argue the examiner (who had all 25 references) allowed the claims precisely because this reciprocal-screening element was absent. The rebuttal is KSR rationale (E)+(A): two identified choices, one admittedly failing, plus Ruutu '801's express anti-consecutive-loss objective.

2. § 103(c) / "by another" issue on Ruutu '801 (Section 4). If Ruutu '801 is commonly owned Nokia art by the same inventive entity, it is disqualified as § 103 prior art. The Cisco+Nortel+Pluris combination in Section 5 avoids this but is a weaker evidentiary fit.

3. No express TSM statement in the '147/'940 references pointing at "the other streams" specifically; a petition/contention must build the motivation from the problem statements in '147 and the '358's own background admissions rather than from an explicit pointer.

4. Secondary considerations. None is of record on the page. There is a colorable long-felt-need story (the patent's own background notes e2e IntServ "has not enjoyed widespread use due to... excessive processing requirements"), but a long-felt need in the same field is also what motivates the combination — so it cuts against the patent here rather than for it. No evidence of commercial success, copying, or licensing is present, and the patent is Expired – Fee Related (adjusted expiration 2023-12-28), so no injunction/long-term commercial-success narrative is available.

5. Dependency on full text. My reference characterizations for Group A/C art other than the four verified references rest on the page's own listing. A challenge built only on titles would be vulnerable; the verified quartet (Ruutu '801/'917 ✅, Cisco '940 ✅, Nortel '147 ✅, EP 0 955 749 ✅) is where the strength is.

---

10. Conclusion

Claims 1 and 8 are the strongest § 103 targets; claims 13 and 20 are somewhat stronger still for the challenger.

• Best ground: Ruutu WO 2002/052801 / US 2004/0090917 in view of Cisco US 6,822,940, further in view of Nortel US 6,535,482 (or its EP 0 955 749 relative). Ruutu supplies the identical architecture and the identical per-flow drop-history "do not hit the same stream twice" rule; Cisco '940 supplies the feedback-driven flow-selection-and-demotion engine and the marking unit; Nortel supplies node-to-node propagation of QoS/congestion actions and upstream-action-responsive suppression. Result: fairer distribution of drops — the admitted desideratum of the '358's own background.
• Fallback ground (avoids the common-ownership problem): Cisco US 6,822,940 + Nortel US 6,826,147 + Heinanen RFC 2597 / Nichols RFC 2474 / Blake RFC 2475, optionally + Pluris US 6,252,848.
• Pivot point for either ground: the reciprocal-screening limitation (H2). It is best attacked not as a positive teaching in any single reference, but as the complement of Ruutu '801's express anti-consecutive-loss objective combined with '940's flow-selection engine — i.e., an "obvious to try" choice between two identified alternatives whose failing branch the reference itself describes.

Confidence: Moderate-to-high that claims 1, 8, and 20 are invalid under § 103 over the Ruutu-'801 + '940 (+ '482) combination, conditioned on (a) both inventors being named on the Ruutu reference (which would trigger the § 103(c) problem) and (b) full-text verification of the Ruutu '917 and '482 disclosures. Moderate that claims 13–19 are invalid over Cisco '940 + Nortel '147 + RFC 2597/2474/2475, since that combination reaches the device architecture and feedback-driven flow selection but relies on a stronger motivation argument for the sign inversion.

Outstanding checks I cannot complete from this environment: (i) front-page inventor lists and assignment records for US 2004/0090917 and WO 2002/052801 to resolve the § 103(c) question; (ii) full-text column/line citations for US 6,535,482 and US 6,252,848 (I have only bibliographic/title-level data for those two, and my characterization of '482 is drawn from its EP relative); (iii) the '358 file wrapper, to confirm no claim amendments or examiner reasons-for-allowance that would narrow the estoppel position.