US 7225267

I'll search for authoritative records on this patent, including any 2026 CAFC activity.

Let me run a couple more targeted searches for litigation/PTAB activity and USPTO status.

Search scope and caveats

I searched for the specific number 7,225,267 (application 10/351,800). Results below are drawn from the patent text you supplied (authoritative), Google Patents, Justia, FreePatentsOnline, and Patsnap, plus a targeted sweep of 2026 Federal Circuit reporting.

Two notes before the summary:

• Date discrepancy: your message states April 26, 2026; my session date is 2026‑09‑27. Nothing in the record turns on this, but flagging it.
• No CAFC activity found. I found no 2026 (or any) Federal Circuit docket, opinion, or oral-argument entry naming U.S. Patent 7,225,267, and no IPR/PGR involving it in the PTAB results I could retrieve. Absence of evidence here is not proof of absence — CAFC dockets are not fully indexed in general web search, and I could not open a live PACER/PTAB docket for this patent. Treat "no CAFC 2026 activity" as unverified.

Bibliographic data (US 7,225,267 B2)

Literal-reading note: the BR family member is listed under the title "Reactive bandwidth control for data sequencing," and the KR member as "Computer program manufacturing, resource demand adjustment methods, and end systems." I have not corrected these — they are reported as-is.

Abstract (as issued)

Real‑time communications over a network are adjusted to improve QoS under incipient congestion conditions. The system detects incipient network congestion and feeds back information about that incipient congestion to the transmitter. The transmission rate is then altered using a control algorithm that computes the altered rate from a weight parameter, a gain parameter, and information from a congestion report. The altered rate improves the transmitter's use of available bandwidth to maintain acceptable QoS at the receiver.

Technical gist

End systems negotiate ECN (Explicit Congestion Notification) capability – the sender marks packets as ECT (ECN Capable Transport), an intermediary (router/gateway/firewall/proxy) marks packets CE (Congestion Experienced) in a virtual queue when a threshold B is exceeded, and the receiver returns congestion reports over RTCP carrying counts of marked vs. sent packets. The sender runs a WTP ("weight‑per‑mark") control law that drives its sending rate toward a weighted fair share of the bottleneck. The specification also frames this generically as "resource demand" vs. "available resource" (transmit power, processing requests, storage requests).

Independent claims — plain language

There are three independent claims: 1, 15, and 27. All three are transmitter‑side ("resource consumer") claims. Notably, the receiver‑side "mark feedback codec / mark tracking module" end system described in the Summary of the Invention does not appear as an issued independent claim in the text I have.

Claim 1 — Computer program product (storage media)

A computer program product for adjusting a resource demand on an available resource by a resource consumer, based on an indication of incipient congestion detected by an intermediary device. The program:

1. determines a weight parameter relating to the consumer's fair share of the resource;
2. receives the incipient‑congestion indication;
3. determines a gain parameter k — and claim 1 itself recites the specific formula:

k = Min( 1/(B+1), MTI/(B·RTT) )

where B = number of packets expected in the intermediary's queue, MTI (Measurement Time Interval) = time between two consecutive congestion indications, and RTT = round trip time;
4. computes a new resource demand from the weight and gain parameters; and
5. adjusts actual use of the resource accordingly.

Characterization: this is the broadest claim, but it is narrow in one important respect — it is limited to the specific gain formula. A challenger cannot avoid this claim by arguing the gain is computed differently; the formula is an express element.

Claim 15 — Method

A method of adjusting a resource demand, with the same five‑step structure. Unlike claim 1, claim 15 embeds a specific weight‑parameter formula:

w = x_target · p_expected / (1 − p_expected)

where x_target is a transmission rate expected by a given number (N) of TCP connections and p_expected is an expected mark probability. Claim 15 does not itself recite the gain formula — that comes in dependent claim 26.

Confidence note: the exact typography of this formula is somewhat degraded in the extracted text (fraction formatting). Based on the equilibrium of the disclosed control law (x = w(1−p)/p at rest), the arrangement above is the correct reading, but I flag it as a medium‑confidence transcription rather than a verbatim rendering.

Claim 27 — End system

An end system providing reactive bandwidth control, comprising:

• a network transport layer module that receives the incipient‑congestion indication; and
• a WTP module that determines the weight parameter, determines the gain parameter, computes a new resource demand, and adjusts use of the resource — where the computation recites:

x_{x+1} = x_n + k·x_n · [ 1 − p_n − p_n·x_n/w ]

where x_n = resource demand at interval n, k = gain, w = weight, p_n = mark‑probability estimate at interval n.

Literal‑reading note: the claim text as published renders the left‑hand index as "x_{x+1}" (a typographical artifact; the specification consistently writes x_{n+1}). I have not auto‑corrected it. The claim text in my source also appears truncated mid‑clause before the formula ("…wherein computing the new resource."), which is a formatting artifact of the source, not necessarily of the issued claim. The remainder of claim 27 should be verified against the USPTO‑issued copy.

Dependents worth noting: claim 28 (media controller applies the new demand), claim 29 (marking module marks outgoing IP packets as ECN‑capable), claim 30 (gain formula as in claim 1), claim 14 (floor the new demand at a predefined minimum), claim 12/13 (the weight and rate formulas in product‑claim form).

Points of uncertainty

• I could not directly retrieve a live USPTO Patent Center page for 10/351,800; the status ("Expired – Fee Related," adjusted expiration 2025‑07‑23) comes from Google Patents' rendering, which itself labels legal status as an assumption.
• I could not confirm or rule out any 2026 CAFC appeal involving this patent. No such appeal appeared in searches of 2026 Federal Circuit opinion summaries (WilmerHale Patent Watch, Panitch caselaw updates, Patterson Sheridan weekly summaries, Oblon newsletters).
• No IPR/PGR of 7,225,267 surfaced; the Microsoft PTAB matters returned (e.g., IPR2026‑00297 v. ToutVirtual over U.S. 12,079,667; Microsoft v. Sandpiper CDN; Microsoft v. VirtaMove) involve unrelated patents.
• One non‑relevant hit to dismiss: the Patsnap page shows "Inactive Publication Date: 2007‑05‑29" while Google Patents shows the patent as granted on that date. These are consistent descriptions of the same event, not conflicting data.

Sources

• https://patents.google.com/patent/US7225267/en (bibliographic data, claims, abstract, description)
• https://patents.justia.com/patent/7225267 (claims text)
• https://www.freepatentsonline.com/y2004/0148423.html (pre‑grant publication US 2004/0148423 A1)
• https://eureka-patsnap-com.sutd.idm.oclc.org/patent-[US7225267B2](/patent/US7225267B2) (assignee/inventor fields)

I'll research litigation involving US patent 7225267. Let me run several targeted searches.

Let me check patent litigation databases directly.

Bottom line

I found no evidence of any litigation involving U.S. Patent No. 7,225,267. Based on the sources I was able to reach, the patent does not appear to have ever been asserted in a U.S. district court, the ITC, the PTAB, or the Federal Circuit.

What the patent is (for identification)

Source: https://patents.google.com/patent/US7225267/en

Scope and method of my search (and its limits)

I ran targeted searches against patent-litigation-oriented sources and general web indexes: Google Patents' own litigation/assignee records for this patent, CourtListener/Justia dockets, PACER-derived case aggregators, Unified Patents' litigation/PTAB case-list material, and CAFC opinion/order documents. I was cut off after a limited number of queries, so this is not an exhaustive Docket Navigator/LexisNexis KeyCite equivalent — I want to be candid about that.

Critically, the authoritative Google Patents record for US 7,225,267 (fetched 2026-09-26) contains only two downstream sections — "Cited By" and "Families Citing this family" — and no "Litigation" section. Google Patents populates a litigation table when it has docket data for a patent, so its absence is meaningful corroboration, though not a guarantee.

What I did find — and what it is not

Several results superficially matched the digits "7225267" or "7,225,267," but none are litigation involving this patent:

1. Prior-art citation, not litigation. PCT publication WO 2010/082208 A2 cites "US7225267" as prior art, describing it as disclosing "Reactive bandwidth control for streaming data in video conferencing." This is a citation in another patent document, not a lawsuit.

2. Different patents in the same numeric neighborhood. Search hits for U.S. Patent Nos. 7,211,267 and 7,232,572 (Galderma/Sun Pharmaceutical ANDA litigation, D. Del. 1:18-cv-01588) are different patents — the three digits are transposed — and must not be conflated with '267.

3. Non-U.S. identifiers. A French application number FR 7225267 (granting as FR 2145637 B1) and several unrelated Chinese filing/case identifiers containing the string "7225267" surfaced; none relate to US 7,225,267.

4. Unrelated streaming-codec/adaptive-bitrate disputes. Cases such as Emblaze Ltd. v. [Microsoft Corp.](/litigations/by-plaintiff/Microsoft%20Corp.) (N.D. Cal. 3:12-cv-05422, U.S. Pat. No. 6,389,473), the MediaPointe/Microsoft matter (W.D. Tex. 2:22-cv-01009), and various adaptive-bitrate IPRs (e.g., IPR2024-00044 on U.S. Pat. No. 11,470,138) involve different patents in the same technology area. Under your strict-ID rule, they are not reportable here.

Status

No litigation is known for US 7,225,267. No plaintiff, defendant, jurisdiction, case number, filing date, or outcome can be reported, because no case was found.

A few practical notes for verification, given my limited search budget:

• The patent is held by Microsoft (an operating company), has been expired for fee non-payment since 2025-07-23, and its assertion value is low — consistent with the absence of litigation.
• To confirm definitively, I'd recommend a KeyCite/Lexis or Docket Navigator patent-level query (KeyCite "Direct History" is the standard method USPTO reexam units themselves use, as seen in the file histories surfaced above), plus a PACER nationwide "case number" search and an ITC EDIS Section 337 search on "7,225,267."
• If a search on the exact number returns a case, it should be reported against the exact string "7,225,267"; results for 7,211,267 or 7225267-as-application-number should be excluded.

If you can lift the search cap or point me at a specific database (e.g., Docket Navigator or RPX Insight), I can run a more thorough confirmatory pass.

I'll start by checking whether any AIA trial proceedings exist for this patent, since the structured block says none are on file.

No proceedings surfaced. Let me run a few more targeted checks to be thorough before concluding.

Let me do two final confirmation searches — one for litigation, one for any PTAB docket record.

Proceedings overview

Zero AIA trial proceedings are on file. Per the structured USPTO Open Data Portal block, there are no Inter Partes Reviews (IPR), Post-Grant Reviews (PGR), or Covered Business Method (CBM) reviews involving US 7,225,267. Independent web searching surfaced no PTAB petition, institution decision, Final Written Decision, or Federal Circuit appeal naming this patent, and no district-court or ITC assertion that would have attracted an IPR — I found no litigation asserting 7,225,267 at all. Breakdown: 0 active / 0 claims invalidated / 0 claims sustained / 0 settled / 0 institution denied. The bottom-line defensive posture for a defendant is unusual and, on balance, favorable: the patent's claims have never been tested by the PTAB, but the patent is now expired (adjusted expiration 2025-07-23, per the structured data), so a present-day assertion can only target past damages within the six-year lookback of 35 U.S.C. § 286 — and there is no PTAB record either hardening or weakening the 30 claims for that past-damages fight.

No proceedings to report

There is no {PROCEEDING_NUMBER} — {Petitioner} v. {Patent Owner} heading to populate. I will not invent one. For completeness, here is the procedural posture I was able to confirm about the patent itself:

• Patent: US 7,225,267 B2 — "Reactive bandwidth control for streaming data" (Google Patents)
• Application: US 10/351,800; filed 2003-01-27; granted 2007-05-29
• Inventors: Peter B. Key, Dinan S. Gunawardena, Laurent Massoulie
• Assignee: [Microsoft Corp.](/litigations/by-plaintiff/Microsoft%20Corp.) (original) → Microsoft Technology Licensing LLC (2014-12-09)
• Claims: 30 (independent claims 1, 15, 27)
• Status (verbatim from structured data): "Expired - Fee Related"; adjusted expiration 2025-07-23
• Foreign family: EP1441288B1, JP4448341B2, KR101046105B1, CN100446466C, BRPI0400085A, DE60327040D1, ATE428140T1
• Evidence of third-party scrutiny: The patent is cited by ~15 later documents (Adobe, Alcatel Lucent, Qualcomm, Microsoft, Canon, Hitachi, et al.) and cited in PCT search reports (e.g., WO2010082208A2, which characterizes US7225267 as disclosing reactive bandwidth control for video conferencing). Forward citation is not a PTAB challenge — none of these is an AIA proceeding.

Strategic summary

Claim status: all 30 claims are UNTESTED in any AIA forum. Claims 1–14 (computer program product), 15–26 (method), and 27–30 (end system) have never been the subject of a PTAB institution decision, motion to amend, or Final Written Decision. There are consequently no canceled claims and no claims adjudged patentable by the Board. If you are being asserted against, you cannot point to a canceled claim — but you also are not fighting a claims set that the patent owner already defended and had confirmed by the PTAB. A confirmed claims set ("the patent has survived IPR") is a materially harder target than an untested one; this patent is the latter.

Estoppel landscape: empty. Because no IPR/PGR was ever filed, § 315(e)(2) estoppel has not attached to anyone. There are no petitioner-privies barred from raising art they raised or reasonably could have raised. Every prior-art ground, every § 102/§ 103 combination, and every § 112 written-description/enablement theory remains fully available to a defendant, unencumbered. The only estoppel-adjacent constraint that matters here is temporal: with the patent expired as of 2025-07-23, a defendant's § 102/§ 103 challenge is aimed at defeating past damages, not at clearing an ongoing royalty.

Pattern signals: none. No petitioner has filed even one IPR against this patent, let alone multiple. There is no NPE/troll ownership pattern in the record — the patent has been held by Microsoft and its licensing entity continuously since 2003, which is consistent with a defensive portfolio asset rather than an assertion vehicle. There is no defensive aggregator (Unified Patents, RPX, etc.) in the chain. The absence of IPRs is a meaningful negative signal about assertion value: a 2003-filed Microsoft patent that is now expired and that no one has ever been sued on (per available records) has not demonstrated the litigation-attracting profile that typically spawns PTAB challenges.

One caveat on scope of my search: the ODP block is canonical and says "no proceedings," and my web searches are consistent with that. I could not access PTAB E2E itself within this session; if you need a belt-and-suspenders confirmation, the authoritative check is a party-name search ("Microsoft Technology Licensing") and a patent-number search on PTAB E2E and the USPTO PTAB Decisions database.

Recommended next steps

If you are a defendant facing a demand letter on 7,225,267:

1. Lead with expiration. The structured data shows an adjusted expiration of 2025-07-23, which predates today (2026-09-27). Any assertion can reach only past damages under 35 U.S.C. § 286 (six-year lookback) — and this patent's term effectively capped out, so verify the PTA calculation in the front-page "Notice" and the maintenance-fee history via Patent Center to confirm the exact expiration and whether any terminal disclaimer or fee lapse affects enforceability of the tail period.
2. There is no IPR to leverage and no FWD to quote. Because no claims were ever canceled, you cannot say "claim 1 is dead." Your invalidity case is built from scratch — which cuts both ways: no petitioner estoppel helps you, but no prior PTAB record helps the patent owner either.
3. Check the family for a second bite. The '267 patent has EP, JP, KR, CN, and BR counterparts (EP1441288B1, JP4448341B2, KR101046105B1, CN100446466C). If the assertion is multinational, foreign prosecution/opposition history may contain examined-art admissions useful here — but do not assume any of that art was considered by the U.S. examiner without checking the US file wrapper.
4. Preserve reliance on the third-party citations. The ~15 forward-citing documents (including Alcatel Lucent, Qualcomm, and Adobe patents) post-date the 2003 priority date and are not prior art, but they are useful for mapping the claim terms ("weight parameter," "gain parameter," "incipient congestion," "congestion report") to conventional implementations and supporting a § 103 obviousness narrative and/or an eligibility challenge.
5. No PTAB-estoppel or § 315(b) clock is running. There is no time bar created by a prior proceeding, so if you do decide to file an IPR (IPR remains available for this pre-AIA patent; PGR/CBM are not, since it was filed well before 2013-03-16), you control the timing — though weigh the cost against an expired patent with only a past-damages tail.

If you were expecting an IPR record to exist: the correct conclusion is that none does, not that it is unfindable. The patent has never been before the Board. Treat that as a factual finding, not a gap in research.

I'll research the assignment record for US 7,225,267 via USPTO Assignment Center and cross-referencing sources.

Let me dig deeper into the specific assignment records and Microsoft's 2014 restructuring.

Let me try to pin down the specific reel/frame for this patent's Microsoft→MTL transfer.

Ownership & Assignment Analysis — US 7,225,267 B2

Methodology note (read first)

I queried the publicly reachable surfaces (Google Patents legal-events record, Espacenet/INPADOC legal-status records for the family, plansite/legacy-assignments mirrors) but I was cut off by a search-step cap before I could pull the USPTO Assignment Center's per-patent record for 7,225,267 itself. I therefore report below what is attested and explicitly mark the two fields I could not retrieve (reel/frame and correspondent of record) as NOT RETRIEVED rather than guess them. I did not invent any assignment.

Inventors

The Google Patents assignment event dated 2003-01-27 names all three as assignors: "ASSIGNORS: GUNAWARDENA, DINAN S.; KEY, PETER B.; MASSOULIE, LAURENT" (source: https://patents.google.com/patent/US7225267/en). All three are publicly documented researchers at Microsoft Research's Cambridge lab; the assignor address of record in contemporaneous Microsoft filings is "c/o Microsoft Corp., One Microsoft Way, Redmond, WA 98052."

Unusual patterns: none. All three inventors assigned to their employer on the filing date, and no inventor is named as an assignor in any subsequent assignment. There is no "all inventors departed within 12 months" signal — and more importantly, no evidence of any inventor-held residual interest being monetized later.

Caveat: employer attribution above is inferred from the inventors' well-documented MSR-Cambridge affiliation and the standard Microsoft assignor address, not read directly off a reel/frame record.

Original assignee

Microsoft Corporation (Redmond, WA) — named on the issued patent and on the patent as published (US 2004/0148423 A1).

• Primary business: software, platforms and cloud services (NASDAQ: MSFT). Operating company.
• Product embodiment: Microsoft shipped real-time media products in the relevant window (Windows Media, Live Meeting, later Lync/Skype for Business and Teams) whose RTP/RTCP transport and congestion-control logic plausibly practice the "weight-per-mark" reactive bandwidth control claimed here. I could not verify a specific product-to-claim mapping from the sources reachable, so treat embodiment as plausible but unconfirmed.
• Current status: operating. The patent itself no longer sits with Microsoft Corporation — see the 2014 transfer below. Google Patents lists the current legal status as Expired – Fee Related; adjusted expiration 2025-07-23 (i.e., lapsed and in the public domain), well before any 20-year term would have run out (filing 2003-01-27).

Assignment timeline

The Google Patents legal-events record for US 7,225,267 discloses exactly two assignment events:

• 2003-01-27 (executed, same day as filing) / recorded date NOT RETRIEVED — Reel NOT RETRIEVED

  • Conveyance: Assignment of Assignors' Interest (see document for details)
  • Assignor: Dinan S. Gunawardena; Peter B. Key; Laurent Massoulié (joint inventors)
  • Assignee: Microsoft Corporation
  • Correspondent: NOT RETRIEVED (Microsoft filings of this era were typically recorded by Microsoft's in-house patent administration at One Microsoft Way, Redmond, WA — unverified for this record)
  • Context: Standard employment/invention assignment to the operating-company employer — not an acquisition.

• 2014-10-14 (effective) / recorded 2014-12-09 — Reel NOT RETRIEVED

  • Conveyance: Assignment of Assignor's Interest
  • Assignor: Microsoft Corporation
  • Assignee: Microsoft Technology Licensing, LLC
  • Correspondent: NOT RETRIEVED
  • Context: Intra-corporate reorganization — Microsoft's 2014 carve-out of essentially its entire U.S. patent portfolio into a wholly-owned licensing subsidiary. Confirmed pattern for this transfer at Microsoft: INPADOC records for other Microsoft U.S. patents show "ASSIGNMENT; NEW OWNER: MICROSOFT TECHNOLOGY LICENSING, LLC … EFFECTIVE DATE: 20141014 … ASSIGNOR: MICROSOFT CORPORATION" recorded 2014-12-09 (e.g. REEL/FRAME 034543/0001 and 034766/0001 on sibling Microsoft patents). The specific reel/frame carrying 7,225,267 could not be verified; Microsoft's bulk MTL recordings occupy numerous 0345xx–0348xx reels, so a candidate cannot be responsibly named without the Assignment Center hit.

No third assignment exists in the record. There is no transfer to an IP-holding shell, no security interest, no license record, no release, and no post-2014 movement of any kind.

Contradiction check vs. the earlier litigation section: none. That section found no litigation for 7,225,267. An unasserted Microsoft→MTL internal reorg is fully consistent with, and corroborates, that finding.

Timeline diagram

timeline
    title Ownership of US 7225267
    2003 : Filed by Microsoft Corporation
         : Inventors assign to Microsoft
    2007 : Patent granted
    2014 : Effective transfer to Microsoft Technology Licensing
         : Recorded December 9 2014
    2025 : Lapsed for failure to pay maintenance fees

NPE / troll-pattern signals

Verdict

Defensive / non-asserting — with an explicit taxonomy caveat.

Justification (2–3 sentences): The complete recorded chain is a single inventor-to-employer assignment executed 2003-01-27 (Microsoft Corporation as assignee) followed, more than a decade later, by the intra-corporate Microsoft Corporation → Microsoft Technology Licensing, LLC transfer effective 2014-10-14 and recorded 2014-12-09; there is no third link, no security interest, and no transfer to any third party. None of the eight NPE signals is present, and the patent has since lapsed for failure to pay maintenance fees ("Expired – Fee Related," adjusted expiration 2025-07-23), which is consistent with the earlier finding that 7,225,267 has never been asserted. I selected the "Defensive / non-asserting" label because it is the only non-NPE, non-assertion option available; flagging the mismatch plainly: the chain does not terminate at a defensive aggregator (RPX/AST/LOT/Unified/OIN) — it terminates at Microsoft's wholly-owned operating-company licensing subsidiary, so this is best characterized as non-asserting operating-company ownership, not defensive aggregation. The "Operating-company assertion" verdict also does not fit, because Microsoft is not suing anyone on this patent.

Verification links:

• USPTO Assignment Center (search by patent number 7225267): https://assignmentcenter.uspto.gov/ — also indexed at https://assignment.uspto.gov/patent/index.html
• Google Patents legal events for the patent: https://patents.google.com/patent/US7225267/en

Two open items that require the Assignment Center hit I could not obtain: (1) the exact reel/frame for each of the two recordings, and (2) the correspondent of record for each. If run, pull the "Reel/Frame" and "Correspondent" fields for both hits and confirm no hidden third entry (e.g., a license or security agreement) exists. Given the expiry and the absence of litigation, I expect the record to confirm a clean two-link chain with no third-party break.

I'll research the prior art cited against (or by) US 7,225,267. Let me start with targeted searches.

Let me pull the specific citation lists from the patent's own record and its EP family member's search report.

Let me try more targeted queries for the citation list itself.

Scope note and a hard limitation up front

I ran targeted searches for 7,225,267 only, and interpreted every identifier literally. Results for 7,211,267, 7,232,572, FR 7225267 (granting as FR 2145637 B1), the ACADVL locus string "7217125..7225267," and a Brazilian corporate registration "7225267" were all encountered and excluded as non-matching identifiers.

The limitation you need to know about: I could not retrieve the "References Cited" / "Patent Citations" (backward-citation) table for US 7,225,267 from any source I reached. The authoritative Google Patents text you supplied contains only "Cited By (15)" and "Families Citing this family (48)" — no backward-citation section, and the fetch is visibly truncated (it ends mid-string at "JP75414"). Patsnap's count line ("9 Cites 27 Cited by") confirms that a 9-item backward-citation list exists, but the contents of that list are not in anything I retrieved.

So I cannot give you a verbatim, face-of-the-patent citation list. Below I give you (A) what the record does verify, (B) the candidate analogous art I identified for the claims — clearly labelled as field-derived, not confirmed face-of-patent citations — and (C) exactly how to close the gap.

I'm flagging this rather than filling it in, because inventing plausible-looking prior-art citations for a specific patent number is the single easiest way to produce a confident, wrong answer.

(Date flag, carried forward: your task header says April 26, 2026; my session date is 2026-09-27. Nothing turns on it.)

A. What the record actually verifies

A.1 Forward citations (these are not § 102 prior art)

These are documents citing '267. They all postdate the 2003-01-27 priority date and therefore cannot anticipate it (they could only be relevant to other patents):

Also verified: WO 2010/082208 A2 cites "US7225267" as background art, describing it as disclosing "Reactive bandwidth control for streaming data in video conferencing" and noting it "uses some probe packets and the RTT to evaluate certain parameters." That is a citation in a later document, not prior art and not litigation.

A.2 The one substantive clue in the record

The specification itself tells us what the examiner-facing art space was. The patent's background section expressly frames the three existing approaches it improves on — (i) RTP/RTCP loss-based rate adaptation, (ii) enlarged buffering + FEC, (iii) static bottleneck-bandwidth estimation — and describes RED and virtual queue AQM as the marking mechanisms. That narrows the field and is the basis for the candidate list in Section B.

B. Candidate analogous prior art (field-derived — not confirmed face-of-patent citations)

Pre-AIA § 102 governs (filed 2003-01-27). Every item below is a printed publication with a date before 2003-01-27, so each is facially § 102(b) art. Confidence that these are the actual cited references: low. Confidence that these are the correct technical neighbors of the claims: high.

Read the § 102 column with this caveat: anticipation requires a single reference disclosing every element. None of the items below appears to do that for any independent claim, principally because claim 1 recites the gain formula and claim 15 recites the weight formula as express elements. I flag these as § 102 candidate / § 103 in practice.

B.1 What I deliberately did not assert

• I did not assert any of the above is on the face of '267. The retrieved record does not contain the backward-citation table.
• I did not assert that any item anticipates any claim under § 102 as a standalone reference.

B.2 Why standalone § 102 anticipation looks unlikely for the independents

• Claim 1 recites as an element the formula k = Min(1/(B+1), MTI/(B·RTT)). Anticipation would require one reference disclosing that exact gain bound. The Kelly/Maulloo/Tan stability analysis (item 8) gives arguably equivalent conditions, but "equivalent" is an obviousness argument, not anticipation.
• Claim 15 recites w = x_target·p_expected/(1 − p_expected) as an element. Items 7–9 supply the concept, not the expression.
• Claim 27 recites x_{x+1} = x_n + k·x_n·[1 − p_n − p_n·x_n/w] (rendered literally as "x_{x+1}" in the source text; the spec consistently writes x_{n+1}). See the prior section's literal-reading flag: the published claim text also appears truncated just before the formula, and should be verified against the USPTO-issued copy before any invalidity position is built on it.

The realistic posture is therefore § 103 combinations, e.g. Kunniyur & Srikant (virtual-queue B) + Kelly/Maulloo/Tan (control law and gain) + Floyd ECN work (marking and feedback) + TFRC (measurement interval and TCP-equivalent target).

C. How to close the gap I couldn't close

To get the actual "References Cited" list — which is what you asked for — use any of these; each exposes the examiner-cited art directly:

1. USPTO Patent Center / Patent Application Locating and Monitoring for application 10/351,800 — open the "References Cited" and "Notice of References Cited (PTO-892)" documents in the file wrapper. This is the authoritative source and the one I could not open.
2. FreePatentsOnline, US 7,225,267 full text — the "Referenced Cited" / "References Cited" block renders as HTML text and is searchable.
3. Justia Patents US 7,225,267 — "Referenced Cited" section.
4. Espacenet / EPO Register for EP 1 441 288 B1 and the EP 1 441 288 A1 search report (PCT/ISA/210-equivalent "Documents Considered to Be Relevant") — this lists the art the EPO examiner applied to the same disclosure, and since EP 1 441 288 shares the 2003-01-27 priority, its citation list is the best proxy for the US list.
5. The DE 60 327 040 D1 / AT 428 140 T1 opposition-track documents in the same family — the AT/DE grant-stage files sometimes carry an extended citation list.

If you paste the "References Cited" block (or the EP search report) into a follow-up, I'll map each actual listed reference to the specific claim elements it does or does not disclose, and separate the genuine § 102 candidates from the § 103-only ones — using the claim-element breakdown rather than this field-derived proxy list.

D. Contradictions / status of the prior sections

• No contradiction found between these findings and the earlier patent summary and litigation summary. The earlier sections' "Expired – Fee Related / adjusted expiration 2025-07-23," the absence of any IPR/PGR or district-court record, and the family table (EP 1441288 B1; JP 4448341 B2; KR 101046105 B1; CN 100446466 C; AT E428140 T1; BR PI0400085 A; DE 60327040 D1) all remain consistent with what I retrieved. The BR/KR title anomalies noted earlier ("…for data sequencing" / "Computer program manufacturing, resource demand adjustment methods, and end systems") are reproduced as-is and not corrected.
• New gap to record: the authoritative source text you supplied for '267 contains no backward-citation ("Patent Citations") section, only forward citations. Any list of prior art cited by '267 in this analysis is therefore reconstructed from the field, not read off the patent — and should be replaced with the verified list per Section C before it is relied on.

Sources

• https://patents.google.com/patent/US7225267/en (bibliographic data, description, claims, "Cited By," family; no backward-citation table present)
• https://patents.justia.com/patent/[12262032](/patent/12262032) (shows '267 as a cited reference in a later Microsoft case)
• https://FreePatentsOnline.com/[8190750](/patent/8190750).html (shows '267 as a cited reference in US 8,190,750)
• https://patents.google.com/patent/KR20040068880A/en and https://patents.google.com/patent/EP1441288B1/de (family records)
• https://patentimages.storage.googleapis.com/d7/80/f3/35d23bfd91a8b6/WO2010082208A2.pdf and https://patents.google.com/patent/WO2010082208A2/en (forward citation describing '267)
• https://eureka-patsnap-com.sutd.idm.oclc.org/patent-[US7225267B2](/patent/US7225267B2) (citation-count line only; contents not retrievable)

I'll gather the actual prior-art-of-record cited on this patent's page before building the §103 analysis.

Let me pin down the specific references cited on the face of this patent (Patsnap shows "9 Cites").

Obviousness Analysis — U.S. Patent No. 7,225,267 under 35 U.S.C. § 103

(Building on the prior bibliographic and litigation sections; not repeating them. One date note carried forward: the task states 2026‑04‑26, session date is 2026‑09‑27. Immaterial here.)

1. Threshold: what "prior art" actually exists on this page

This matters before any § 103 analysis, and it cuts against the framing of the assignment.

The Google Patents record supplied for US 7,225,267 contains:

Conclusion: the "Prior Art" data visible on this page is forward citation material. It is prior art to those later documents, not to '267. No ground of rejection under § 103 can be built from it. Anyone who treats the "Cited By" list as an obviousness arsenal has the arrow pointing backwards.

I was cut off before I could retrieve the page's backward "Patent Citations" table (Patsnap shows "9 Cites"), so the analysis below is built from three defensible sources: (a) art the patent itself admits and cites; (b) art surfaced in the family's foreign search reports; (c) pre‑2003 references whose existence and content I can state with high confidence. Each limitation mapping is confidence-labelled. The actual 9-of-record citations must be pulled from the USPTO IFW / EP search report before this analysis is used adversarially.

2. Applicant-admitted prior art (from the '267 specification itself)

These are admissions usable under § 103 without any evidentiary fight:

Significance: the patent's own frame is "loss-based adaptation was known; we substitute an incipient-congestion signal." That framing is close to a concession of obviousness over the admitted art once ECN is added — and ECN's express purpose is exactly that substitution.

3. Governing law and the POSITA

• Pre‑AIA § 103(a) applies (filed 2003‑01‑27). Graham v. John Deere, 383 U.S. 1 (1966) factors; KSR Int'l v. Teleflex, 550 U.S. 398 (2007) governs the motivation analysis for any challenge brought today, including predictable variation, "obvious to try," and design incentives/market pressure.
• POSITA: a network-protocols engineer with an advanced degree (or equivalent experience) in packet-switched networking, familiar with TCP/IP, RED/AQM, ECN, RTP/RTCP, and with the control-theoretic literature on end-to-end congestion control (fluid models, proportional fairness, delay stability). This is a high-skill POSITA — which helps a challenger on the math-heavy claims.
• Analogous art: all references below are in the same field of endeavor (end-to-end congestion control / real-time media transport) or are reasonably pertinent to the same problem.

4. The limitations that actually decide this

From the earlier claim section, the independent claims are narrow in exactly one way each:

Everything else in all three claims (weight parameter, congestion report, gain parameter, new demand, adjusting use) is generic. A § 103 case therefore lives or dies on the three formulae. This is the single most important strategic point: an obviousness challenge that proves the framework obvious but not the formulae fails on all three independents.

5. Proposed grounds of rejection

Ground 1 — The framework claims (1–11, 16–25, 27–29), and the "incipient" language

Combination: Ramakrishnan & Floyd, RFC 2481 (Jan. 1999) — or its successor RFC 3168 (Sept. 2001) — in view of Floyd & Jacobson, "Random Early Detection Gateways for Congestion Avoidance" (1993) and Schulzrinne et al., RTP/RTCP (RFC 1889/RFC 3550).

Motivation to combine — and this one is unusually clean. RFC 2481 does not merely permit application to non-TCP transports; it invites it:

"Notifications to other transport protocols (e.g., unreliable unicast or multicast, reliable multicast, other reliable unicast transport protocols) could be considered as those protocols are developed and advance through the standards process."

(RFC 2481, Abstract)

RTP/UDP is precisely "unreliable unicast or multicast." And the same RFC supplies the "incipient congestion" vocabulary and the explicit reason to prefer marking over dropping: "The use of the CE bit would allow the receiver(s) to receive the packet, avoiding the potential for excessive delays due to retransmissions after packet losses" — which is the patent's entire stated problem (Background: loss detection "is too late"; buffering "replaces data loss with increased latency"). A POSITA reading RFC 2481 with RFC 1889 in hand would have every reason to substitute ECN marks for loss events in the admitted RTCP adaptation loop, with a reasonable expectation of the claimed benefit.

Additional KSR-style motivations: Cisco was already shipping ECN marking (IOS 12.2.8(4), admitted); RED was "currently being deployed in the Internet backbone" per RFC 2481 — i.e., market/design pressure existed. KSR, 550 U.S. at 417, 421.

Ground 2 — The gain parameter of claim 1 (and claims 6, 26, 30)

Combination: Ground 1 + the proportional-fairness/delay-stability literature, principally:

• Johari & Tan, "End-to-end congestion control for the Internet: delays and stability," IEEE/ACM Trans. Networking (2001) — stability of rate-control loops with feedback delay; and/or
• Massoulié, "Stability of distributed congestion control with heterogeneous feedback delays," MSR Tech. Report MSR‑2000‑111 (2000); and/or
• Laevens, Key & McAuley, "An ECN-based end-to-end congestion-control framework: experiments and evaluation," Microsoft Technical Paper, Oct. 2000 (XP002273199) — cited in the search report of EP 1 187 401 A3 (source PDF). Note this is the same Microsoft Research Cambridge group as the inventors (Key is a named inventor on '267).

Why the formula is obvious from this art — medium confidence on the specific algebra, high confidence on the reasoning:

Claim 1's k = Min( 1/(B+1), MTI/(B·RTT) ) has a transparent two-term structure:

1. 1/(B+1) — the classic discrete-step upper bound for a mark-probability feedback loop whose loop gain scales with the queue/marking parameter B. Reduce the gain as the marking threshold grows; a first-year control result.
2. MTI/(B·RTT) — the delay-limited term, scaling the step with the update interval measured in round-trip times (r = MTI/RTT, exactly as the '267 specification itself defines it). Delay-dependent gain bounds of this shape are the central result of the Johari–Tan / Massoulié delay-stability line.

The patent's own language gives the game away: the specification states the algorithm is "locally stable…if the gain parameter k satisfies two conditions" — i.e., k is derived from a stability analysis, not invented. Deriving a step size from a linearized fluid model of a known control loop is routine optimization, and a predictable result from known methods: In re Boesch; In re Aller; KSR, 550 U.S. at 417 ("a court must ask whether the improvement is more than the predictable use of prior art elements according to their established functions").

Motivation to combine: the same references supply both the ECN marking signal (Ground 1) and the loop-stability mathematics needed to set a discrete step size for that signal. Combining a signaling mechanism with the published stability analysis for controls driven by that mechanism is not hindsight — it is the standard engineering workflow in this exact subfield, and Massoulié (a named co-inventor here) published the stability result himself in 2000.

Ground 3 — The weight parameter of claims 12 and 15

Combination: Ground 1 + Kelly, "Charging and rate control for elastic traffic," European Transactions on Telecommunications (1997); Kelly, Maulloo & Tan, "Rate control for communication networks: shadow prices, proportional fairness and stability," J. Operational Research Society (1998); Key & Massoulié, "User policies in a network implementing congestion pricing," Workshop on Internet Service Quality Economics, MIT (Dec. 1999); Gibbens & Kelly, "Resource pricing and the evolution of congestion control," Automatica (1999).

Claim 15's w = x_target·p_expected/(1 − p_expected) is algebraically the equilibrium condition of a congestion-priced flow: the user's charge per unit of congestion (per mark) equals w, and at rest x = w(1−p)/p. Rearranged, w = x·p/(1−p). That is the "weight per mark" — the WTP ("willingness to pay") parameter — which is the literal object of Key & Massoulié's Dec. 1999 pricing paper and the Kelly/Maulloo/Tan weighted-log-utility framework. The claim merely restates it with "target rate" substituted for equilibrium rate. Confidence: medium‑high (I could not pull the Key & Massoulié paper's text, and the claim's typography is degraded, as flagged earlier).

Corroboration that WTP-driven ECN rate control was a live, published technique: a University of Surrey thesis (open-research repository) describes a window-based controller in which "the source increases the cwnd according to the user's wtp," the router "marks the packets that cause congestion by setting their CE bit to '1'," and the receiver "sets the ECNecho bit." That is the same architecture with WTP weighting — but I flag that I could not establish its date; treat it as corroborative of the state of the art only if its publication date is verified pre‑2003.

Motivation to combine: claims 3/17 themselves specify that the weight is chosen to mimic "a rate expected by a given number (N) of TCP connections." Once a designer's goal is TCP-compatible/weighted-fair sharing of a bottleneck, the Kelly framework is the canonical, well-known way to express that target as a per-mark weight. Motivation is supplied by the reference itself and by the stated problem.

Ground 4 — The update law of claim 27

Combination: Ground 1 + Ground 3 + Kunniyur & Srikant, "End-to-end congestion control schemes: utility functions, random losses and ECN marks" (INFOCOM 2000 / IEEE‑ACM ToN 2003); Athuraliya & Low, REM (2000/2001); Mo & Walrand, "Fair end-to-end window-based congestion control" (2000).

Claim 27's x_{n+1} = x_n + k·x_n·[1 − p_n − p_n·x_n/w] is the discrete-time primal algorithm of the proportional-fairness family: multiplicative-increase term k·x_n·(1−p_n) tempered by a price term k·x_n·p_n·x_n/w. That structure — rate steps proportional to (1 − mark probability) minus a weighted congestion-price term driven by p — is the textbook end-to-end ECN congestion controller of the 1998–2002 literature. Confidence: medium on exact-form identity; high that the claimed structure (proportional-fair primal law with mark-probability feedback and a weight) is squarely disclosed by this class of references.

Motivation to combine: the ECN marking signal (Ground 1) is only useful if the source has a control law keyed to mark probability; these references are the canonical control laws keyed to mark probability. Same field, same problem, and predictably combinable.

Ground 5 — Real-time / streaming-specific adaptation (claims 8, 9, 28, and the media-controller embodiment)

Combination: Grounds 1–4 + Rejaie, Handley & Estrin, "RAP: An end-to-end rate-based congestion control mechanism for realtime streams in the Internet" (INFOCOM 1999); Sisalem & Schulzrinne, "The loss-delay based adjustment algorithm" (1998); Jacobs & Eleftheriadis, "Real-time dynamic rate shaping and control for Internet video" (1997); Floyd, Handley, Padhye & Widmer, TFRC (RFC 3448 / pre‑2003 drafts, incl. ECN variants).

These establish: (i) rate-based (not window-based) congestion control for real-time flows; (ii) TCP-friendly/weighted fairness as the design target for streaming; (iii) receiver→sender reports at a measurement interval as the control input; (iv) encoding-parameter adaptation (quantizer, layers) as the actuation mechanism — which disposes of claim 28's "media controller" and the layered-coding/single-quantizer alternatives the '267 specification itself describes as conventional. Confidence: high on (i)–(iii) as the state of the art; medium on exact pin-cites.

Ground 6 — Closest single reference (for a § 102 or § 103 "lead compound" attack)

Laevens, Key & McAuley, "An ECN-based end-to-end congestion-control framework: experiments and evaluation," Microsoft Technical Paper, Oct. 2000. Same institutional group as the inventors, ECN-based, end-to-end, framework-level. This is the reference I would retrieve first. If its content includes a per-mark weighting and an interval/RTT-based gain, it materially shortens the obviousness path on claims 1, 15 and 30. Confidence in its existence and date: high (it appears as XP002273199 in EP 1 187 401 A3's search report). Confidence in its content: low — not inspected.

6. Motivation to combine — consolidated argument (KSR-compliant)

1. Same field of endeavor. All references concern end-to-end congestion control for packet-switched networks; the streaming references concern the identical application. In re Bigio; In re Keller.
2. Same problem, same solution type. '267's stated problem is that loss-based feedback is untimely, that buffering trades loss for latency, and that static estimates fail on variable bottlenecks. RFC 2481 addresses the first two directly and in the same words ("incipient congestion"; avoiding "excessive delays due to retransmissions").
3. Express lead from the primary reference. RFC 2481 names non-TCP/unreliable transports as the next application — a classic "try it" motivation under KSR, 550 U.S. at 421.
4. Predictable result. Marking instead of dropping is a known technique used to improve the same kind of system in the same way, with the claimed benefit (higher utilization without loss/latency) as its known output. KSR at 417, 425.
5. Market/design pressure. RED deployed at backbone; Cisco shipping ECN marking (both admitted by the patent). KSR at 417.
6. The formulae are optimization, not invention. The specification presents k as a derived stability condition and w as an equilibrium relation. Deriving a gain from a stability analysis, and a weight from a pricing equilibrium, are routine engineering with predictable results. In re Boesch; In re Aller; KSR at 417.
7. Common provenance. Several references (Massoulié 2000; Key & Massoulié 1999; Laevens/Key/McAuley 2000) are from the same laboratory as the inventors, which strengthens the "would have consulted" showing and diminishes the hindsight objection.

7. Where this analysis is weak (defenses the patent owner would press)

8. Confidence ledger and what must be verified

To convert this into a filing-grade § 103 position, retrieve in this order: (1) the nine citations on the face of US 7,225,267 (USPTO IFW / EP 1 441 288 B1 search report); (2) the Laevens/Key/McAuley Oct. 2000 technical paper; (3) Johari & Tan (2001) full text; (4) Key & Massoulié (Dec. 1999) full text; (5) Kunniyur & Srikant (2000/2003). Grounds 1–5 stand or fall on those five retrievals, and specifically on whether any of them recites a gain bound containing both a 1/(B+1)-type term and an MTI/(B·RTT)-type term, or a discrete update of the form x_{n+1} = x_n + k·x_n·[1 − p_n − p_n·x_n/w].