US 7324551

I'll search for authoritative records on this specific patent number.

Summary of U.S. Patent No. 7,324,551

Sourcing note: I searched for the patent number, for litigation/CAFC activity tying it to that number, and for Cisco-side docket records. The bibliographic and claim data below come from the authoritative full-text record you supplied (Google Patents, fetched 2026‑09‑24) plus a confirming full-text hit at FreePatentsOnline and the USPTO-hosted PDF (patentimages.storage.googleapis.com/.../US7324551.pdf). Searches of Court of Appeals for the Federal Circuit 2026 dockets returned no results mentioning 7,324,551 / US7324551. Searches for Cisco patent litigation surfaced several other Cisco patents (e.g., 7,330,431, 7,420,952, 8,520,691, 6,891,855), but none of those documents referenced this patent. I found no evidence of any pending or decided CAFC appeal involving this patent, and I state that as a negative finding rather than a certainty — I cannot rule out an unindexed or unreported matter.

Bibliographic data

Abstract (verbatim)

"A method for managing bandwidth in a network environment is provided that includes monitoring a state transition of a communication session associated with an end user and initiating one or more resource reservation protocol (RSVP) actions based on the state transition. The method also includes controlling a bandwidth allocation associated with the end user based on one or more of the RSVP actions."

Core technical concept

The patent addresses mobile/wireless bandwidth management (2.5G/3G, PDSN or GGSN/SGSN contexts). The insight is that the packet gateway already knows when a terminal goes dormant and when it wakes up (dormancy state transitions are signaled to it). Instead of forcing the terminal to run RSVP signaling over the air link to get bandwidth reserved or released, the gateway itself triggers RSVP actions as a proxy based on those state transitions — active→dormant triggers release of the bandwidth allocation; dormant→active triggers a request to re-establish it. This eliminates over-the-air RSVP refresh signaling and the need for the terminal to maintain an RSVP signaling stack, while QoS parameters negotiated at initial session setup are stored (at the gateway or at a centralized server) and reused. FIG. 1 shows end user 12, RAN 14, IP networks 16a/16b, WAP gateway 20, packet gateway 22 with RSVP signaling element 24, plus centralized server 28, AAA server 36 and web server 40. FIG. 2 is a flowchart (steps 100–108) of session establishment → dormancy → reactivation → re-establishment.

Independent claims — plain language

There are five independent claims. All share the same inventive core; the differences are claim type and how the "no responsive communication from the end user" limitation is expressed.

Claim 1 — Apparatus. A packet gateway that monitors a state transition of an end user's communication session and, based on that transition, initiates one or more RSVP actions to control the bandwidth allocation for that end user. The gateway contains an RSVP signaling element that initiates those RSVP actions without requiring a responsive communication from the end user (i.e., the terminal doesn't have to answer or participate).

Claim 6 — Method. Monitor a state transition of an end-user communication session; initiate RSVP actions based on that transition; control the end user's bandwidth allocation based on those RSVP actions; and implement an RSVP signaling protocol that can initiate those actions based on the state transition without requiring a responsive communication from the end user.

Claim 11 — System. A packet gateway as in claim 1 (monitors state transition, triggers RSVP actions to control bandwidth, includes an RSVP signaling element acting without a responsive end-user communication), and the gateway stores one or more QoS parameters in a profile associated with the end user, and the state transition is a selected one of active→dormant and dormant→active, used respectively to release and request the end user's bandwidth allocation. This is effectively claim 1 collapsed together with the subject matter of claims 2–4.

Claim 12 — System (means-plus-function). Four means: means for monitoring a state transition of an end-user communication session; means for initiating RSVP actions based on that transition; means for controlling the end user's bandwidth allocation based on those RSVP actions; and means for initiating those RSVP actions based on the state transition without requiring a responsive communication from the end user.

Claim 15 — Computer-readable medium. Code that, when executed, causes a computer to: monitor a state transition of an end-user communication session; initiate RSVP actions based on that transition; control the end user's bandwidth allocation based on those RSVP actions; and initiate those RSVP actions based on the state transition without requiring a responsive communication from the end user.

Dependent claims at a glance

• Claims 2–5 (depend from 1): active→dormant releases bandwidth (2); dormant→active requests bandwidth (3); QoS parameters stored in an end-user profile at the packet gateway (4); a centralized server stores an end-user profile with bandwidth-reservation data and QoS data (5).
• Claims 7–10 (depend from 6): same release/request and QoS-profile concepts as 2–4, with claim 9 covering storing QoS parameters in a profile.
• Claims 13–14 (depend from 12): active→dormant release; dormant→active request.
• Claims 16–18 (depend from 15): active→dormant release; dormant→active request; storing QoS parameters in an end-user profile.

Two drafting observations worth flagging

1. Claim 10 contains an apparent dependency error: it reads "The method of claim 4, further comprising: storing a profile associated with the end user at a centralized server…" — but claim 4 is an apparatus claim, not a method claim, and claim 6 is the method claim it presumably should have referenced. This is a literal defect in the printed claim set; I am reporting it as printed rather than correcting it.
2. The specification contains a typo in the RSVP discussion ("The roll of RSVP signaling element 24 may be to provide resource admission control"), and one passage in the description is duplicated nearly verbatim.

Related-art context (from the record)

• Prior art cited on the face: US 6,157,648 (Bell Atlantic, network session management); US 6,483,835 (Hitachi); US 2005/0027870 A1 (Trebes); US 6,452,915 (Malibu Networks, IP-flow classification in wireless PTMP); US 6,449,588 (Accenture, customer-driven QoS); US 6,366,577 (MCI WorldCom, IP telephony QoS via end-to-end RSVP); US 2007/0133403 A1 (Avaya, VoIP endpoint call admission).
• Notable forward citation: US 8,270,411 B1 — "Bandwidth allocation based on dormancy transitions" (Sprint Communications, priority 2009‑12‑11) — a direct conceptual successor applying the same dormancy-transition-to-bandwidth linkage.

Confidence and uncertainty

• Title, inventor, assignee, application number, filing date, issue date, abstract, claim set, and legal-status data are high confidence — they are drawn from the authoritative patent text supplied and corroborated by independent full-text mirrors.
• The negative finding on CAFC 2026 docket activity is moderate-confidence: nothing surfaced in my searches, but I did not have direct query access to a docket database (e.g., PACER/CourtListener) for a case-number-level confirmation. If you need a definitive check on a specific appeal number, that would require a docket-level lookup rather than a web search.
• Because this patent's adjusted expiration is listed as 2025‑12‑08, it is expired; any 2026 appellate activity would be unusual but not impossible (e.g., an appeal of a validity ruling could outlive expiration). I found no indication of one.

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

Let me try more targeted searches on litigation databases.

Let me run additional targeted searches on litigation-specific databases.

Litigation Search Results for U.S. Patent No. 7,324,551

Bottom line: I found no litigation involving U.S. Patent No. 7,324,551. Based on my searches, there is no known district court action, ITC investigation, or Federal Circuit appeal asserting or challenging this patent. I should flag that my searches were limited (a general web/patent-database search set), so this is not a certified negative — see "Caveats" below.

Search methodology and what I looked for

I searched for the exact patent number (7,324,551), associated identifying information (title "System and method for managing bandwidth in a network environment"; inventor Timothy P. Stammers; assignee Cisco Technology, Inc.), and litigation-database sources including Unified Patents' litigation portal, Docket Alarm, Justia Dockets, RPX/Insight, and general CAFC/PACER-derived results.

Results returned

1. No case lists US 7,324,551 as a patent-in-suit. No plaintiff/defendant pair, case number, jurisdiction, filing date, or outcome could be associated with this specific number.
2. A near-miss I am explicitly excluding (not auto-correcting): One result was Realm Licensing LLC v. Insightly, Inc., D. Del., Case No. 1:20-cv-01462, filed October 28, 2020 (Judge Colm F. Connolly). That case's docketed patent numbers are 6,324,551; 6,330,573; and 7,996,356. The first number there is 6,324,551 — a different patent from 7,324,551. Per your instruction to interpret identifiers literally and not auto-correct, I do not treat this as litigation involving the patent at issue. It is a seven-digit number beginning with "6," not "7," and it should not be conflated.
3. The remaining hits were similarly inapposite — other Cisco-related litigations ('209, '775, '296, '757, parity/Cisco cases), other patents in the 7,3xx,xxx range, and PTAB/IPR matters involving unrelated patents. None named 7,324,551.

Why a null result is plausible here

This is consistent with the patent's public record:

• Owner: Cisco Technology, Inc. (original and current assignee), a large operating company that generally defends its portfolio rather than asserts it in NPE-style campaigns.
• Status: The patent is listed as "Expired – Lifetime," with an adjusted expiration of 2025-12-08 (i.e., it has lapsed). An expired patent cannot support ongoing injunctive relief, which reduces the practical incentive to litigate it.
• Family: Only a single U.S. application/publication is listed (US 10/316,726), with no foreign family, which is often associated with less enforcement activity.
• Citing references: I did see later patents citing the '551 patent, including US 8,270,411 B1 ("Bandwidth allocation based on dormancy transitions," Sprint Communications, filed 2009-12-11), which is the closest thematic relative. That is a citation relationship, not an assertion of the '551 patent.

Per-case breakdown

None available — there are no cases to report. For each requested field (plaintiff, defendant, jurisdiction, case number, filing date, status/outcome), the answer is no known litigation.

Caveats (stated so you can weigh the null result properly)

• I could not complete an exhaustive, query-by-query run against every litigation database (e.g., a full PACER/Docket Alarm party-and-patent-index sweep, or a full Unified Patents litigation build-out) before my search steps were exhausted. My conclusion rests on the searches actually performed.
• A "no litigation found" result can mean (a) no suit was ever filed, or (b) any suit is not indexed in free/aggregated sources. Sealed complaints, state-court matters, or cases indexed only under a different patent-number format could be missed.
• I would not, on my own, certify this as a definitive negative clearance. If you need a citable negative for a diligence memo, I recommend confirming with (i) a full PACER "patent number" search, (ii) Docket Alarm / Lex Machina patent-number lookup, and (iii) the Unified Patents litigation portal filtered to the exact number, plus a check of USPTO assignment records for any transfers that could have enabled assertion.

Summary: No known litigation involves U.S. Patent No. 7,324,551. The one superficially similar docket (Realm Licensing v. Insightly, D. Del. 1:20-cv-01462) concerns 6,324,551, a distinct patent, and is therefore excluded.

I'll verify the structured data against web sources before writing anything up.

PTAB Proceedings Analysis — US 7,324,551

Patent: System and method for managing bandwidth in a network environment
Patent Owner / Assignee: Cisco Technology, Inc. (original assignee; no recorded reassignment since the 2002-12-11 assignment at Reel/Frame 013576/0482)
Inventor: Timothy P. Stammers
Application: US 10/316,726 · Priority/Filing: 2002-12-11 · Granted: 2008-01-29
Record status: Expired – Lifetime · Adjusted expiration: 2025-12-08
Claims: 18 (1–18)

Source-of-record caveat up front. The structured PTAB block in this prompt states that the USPTO Open Data Portal returned no AIA trial proceedings for this patent as of the most recent ingest, and that this should be the default posture. My independent web searches (PTAB E2E/petition document hits, CourtListener, Google Patents/FPO litigation and citation records) surfaced no IPR, PGR, or CBM petition or proceeding naming US 7,324,551, and no Federal Circuit appeal arising from it. I could not open a PTAB E2E docket view for the patent directly, so this conclusion rests on the ODP structured block plus negative search results. Everything below is written accordingly — nothing here is drawn from a proceeding record, because no proceeding record exists.

Proceedings overview

Total AIA trial proceedings: 0 — 0 active, 0 with claims invalidated, 0 with claims sustained, 0 settled, 0 with institution denied. Every one of claims 1–18 is untested at the PTAB, and the defensive posture this gives a defendant is not "the patent is hardened" — it is "the patent has never been attack-tested, and it is expired, so the assertion window is closed prospectively and any remaining damages theory is a shrinking 6-year historical slice."

No proceedings to detail

Because the proceeding list is empty, the per-proceeding template (proceeding number, petitioner, panel, grounds, institution decision, FWD, settlement, appeal) has no entries and I will not manufacture any. Instead, the useful substitute is the claim-level status derived from the patent's own text:

No claim has ever been canceled, narrowed, or confirmed by the Board. There is no FWD to link to and no disposition to quote.

Two observations from the face of the claims (my reading, not PTAB holdings):

1. Claim 10 contains a dependency defect. It recites "[t]he method of claim 4," but claim 4 is an apparatus claim ("The apparatus of claim 1, wherein the packet gateway includes one or more quality of service parameters…"). A method claim depending from an apparatus claim is a classic § 112(d) / indefiniteness candidate and mirrors the same drafting slip in claim 9's neighborhood. This is exactly the kind of defect an IPR petitioner or a district-court § 112 defense would probe — but no one has, at the Board or elsewhere on the public record I could find.
2. The independent claims are functionally very broad. Claim 6 requires only monitoring a state transition, initiating RSVP actions, controlling a bandwidth allocation, and doing so without requiring a responsive communication from the end user. The specification backfills that breadth with respect to dormancy signaling (RAN→packet gateway dormancy/active messages) and 3GPP/3GPP2 packet-gateway roles (PDSN, SGSN/GGSN). Broad functional claiming of this shape over a well-documented protocol family (RSVP, RFC 2205; 3GPP2 dormancy) is normally where § 103 petitions succeed — the absence of any petition is therefore better explained by the patent never having been asserted than by the claims being unusually robust.

Strategic summary

Claim status after PTAB review: everything survives, because nothing was reviewed. There is no canceled-claim set, no surviving-narrowed-claim set, and no estoppel-producing FWD. Claims 1–18 are all in force as granted (subject to the expiration below), and a defendant cannot tell a court or a plaintiff that any claim has been invalidated. That is the single most important cross-proceeding fact: you cannot shortcut this patent with a PTAB outcome.

Estoppel landscape is unusually clean. Because no IPR, PGR, or CBM was ever filed by anyone, no § 315(e)(2) estoppel attaches to any party and there is no privy-based estoppel chain to trace. For a defendant now facing assertion, every prior-art ground is theoretically available — §§ 102 and 103 on patents and printed publications in an IPR, plus the broader district-court kit (on-sale bar, public use, § 112, and § 101) that the Board cannot hear at all in an IPR. The practical constraints are instead:

• § 315(b): if you have been served with a complaint alleging infringement, you have one year from service to file an IPR or lose the right entirely. The clock is service-based and strictly enforced.
• Expiration: the patent is recorded as expiring 2025-12-08. IPRs may still be filed against expired patents (the Board applies Phillips-style claim construction to an expired claim), but the economics change completely — an expired patent cannot be prospectively infringed, and damages are limited to acts before 2025-12-08 and only within the § 286 six-year lookback measured back from the filing of the complaint. As of today (2026-09-30) that reachable window is roughly 2020-09-30 to 2025-12-08, and it shrinks every day while the far edge is fixed. That is a strong reason to weigh a § 286/§ 282 damages defense and a laches-adjacent equitable argument alongside any validity fight.
• PGR and CBM are unavailable. The patent is pre-AIA (filed 2002-12-11), so PGR (which requires a post-2013 filing date) never existed for it; the CBM program sunset on 2020-09-16 and this is a networking/bandwidth patent, not a financial-services business method, so CBM was never a fit. IPR is the only AIA trial vehicle available.

Pattern signals: none of the usual ones. There is no repeat petitioner, no serial-petition pattern, no joinder activity, no Unified Patents or other defensive aggregator involvement that I could find, and no patent-owner appeal activity (there being no FWD to appeal). Cisco has held title continuously since 2002 and the patent has never left the original assignee. The realistic reading is that '551 is a defensive portfolio asset that was never asserted — not a hardened patent that survived attack. The "absence of IPRs" signal cuts both ways, and here it should be read as low assertion pressure, not high validity confidence.

One data point worth noting for freedom-to-operate work rather than for PTAB purposes: US 8,270,411 B1 (Sprint, "Bandwidth allocation based on dormancy transitions," filed 2009-12-11) is a later patent that cites '551 — i.e., the industry continued to patent in this exact dormancy-transition/bandwidth-allocation space, which is relevant to the § 103 picture if you ever do build an obviousness case.

Recommended next steps

1. Do not rely on any PTAB outcome — there is none. Because no claim has been canceled, you cannot tell opposing counsel that "claims 1–5 are dead." Any such statement would be false on this record. If the demand letter asserts claims 1–18, all 18 are live and unadjudicated.
2. Verify the record yourself at the primary sources before you build a defense: PTAB E2E (search by patent number for any petition, decision, or terminated proceeding) and USPTO Patent Center for the '551 file wrapper — specifically checking for a reissue, an ex parte reexamination certificate, a statutory disclaimer, a certificate of correction, and the maintenance-fee chain (the record shows the 12-year fee paid 2019-07-29 and the "Expired – Lifetime / adjusted expiration 2025-12-08" marker; confirm no lapse-and-revival event). A reexam certificate, if one exists, would be the moral equivalent of a claim amendment and is not captured in the "PTAB proceedings" block. Also confirm the expiration date itself against the patent's PTA/terminial-disclaimer math, since 2025-12-08 is the linchpin of a damages-only posture.
3. If you are within the § 315(b) one-year window, treat an IPR as a real option — but price the expiration first. An IPR on an expired patent yields invalidity findings but no injunction relief either way; the value is in defeating the historical damages claim. Given the broad functional independent claims (1, 6, 11, 12, 15) and the documented RSVP + dormancy-signaling prior art, a § 103 challenge on claims 1–18 plausibly has traction — but that is a prediction, not a record finding, and I have not verified what art was before the Examiner during prosecution (the "Citations (7)" list in the record shows only US 6,157,648; US 6,483,835; US 20050027870; US 6,452,915; US 6,449,588; US 6,366,577; and US 20070133403).
4. If no IPR is filed, the fallback is a district-court invalidity + damages/expiration defense. Assert § 112 against claim 10's defective dependency, run § 103 against the independent claims on the RSVP/dormancy art, and independently move to cap damages under § 286 given the 2025-12-08 expiration and the rolling six-year lookback.
5. Watch for late-filed petitions. Nothing is pending, but a petition filed shortly before expiration-related deadlines would be a new fact. Because the patent expired in 2025, a petitioner today is buying an invalidity ruling against a dead patent — worth monitoring, and worth flagging to co-defendants if you are in a multi-defendant case, since no estoppel currently constrains anyone.

Confidence statement: I am highly confident there are no AIA trial proceedings on file for US 7,324,551 based on the ODP structured data and my searches. I did not independently confirm the absence of an ex parte reexamination or a district-court assertion by opening the file wrapper, and I have not audited the maintenance-fee history or the PTA calculation behind the 2025-12-08 expiration date. Those are the two things I would verify before relying on this in a litigation or settlement posture.

I'll verify the assignment chain and check for any assertion history before writing up.

Let me do a couple of final checks on assertion history and the recorded reel/frame.

US 7,324,551 B1 — Assignment & Ownership Analysis

Patent: System and method for managing bandwidth in a network environment
Appl. No.: 10/316,726 · Filed: 2002-12-11 · Issued: 2008-01-29
Status: Expired – Lifetime (adjusted expiration 2025-12-08)
Sources: Google Patents legal events (https://patents.google.com/patent/[US7324551B1](/patent/US7324551B1)/en), FreePatentsOnline, Justia, USPTO Assignment Center (https://assignmentcenter.uspto.gov/), USPTO Public/Assignment records.

Inventors

• Corroboration of employer: Stammers is a career Cisco inventor. PatentLeaderboard (data through Dec 31, 2025) credits him with 103 issued US patents, all assigned to Cisco (https://www.patentleaderboard.com/cisco/timothy-peter-stammers/10560). Earlier same-family filings list him at Raleigh, NC with assignee Cisco Technology, Inc. (e.g., US 6,754,492, application 09/925,113, filed 2001-08-08; family EP1999618 lists "CISCO TECHNOLOGY, INC., 170 WEST TASMAN DRIVE SAN JOSE, CA" and "STAMMERS, TIMOTHY, P. RALEIGH, NC 27612").
• No unusual departure pattern. The classic fire-sale tell (all inventors leaving the original assignee within 12 months of filing) is absent: Stammers is still filing Cisco-assigned applications two decades later (e.g., publicly available Cisco applications from 2024–2025 with inventors Andreasen / Stammers / Zgonjanin, agent of record Polsinelli P.C.). This is a single-inventor corporate patent by a long-tenured employee, not a founder-departure patent.

Original assignee

Cisco Technology, Inc. (a California corporation; principal address of record 170 West Tasman Drive, San Jose, CA 95134).

• Relationship to the operating business: Cisco Technology, Inc. is the wholly-owned Cisco holding entity that takes title to most Cisco Systems, Inc. patent filings (the operating company is Cisco Systems, Inc., the Delaware corporation). The assignment record names "CISCO TECHNOLOGY, INC., CALIFORNIA"; the patent front page and Google Patents list "Cisco Technology Inc" as both original and current assignee. The dual-entity structure is standard Cisco housekeeping across thousands of patents and is not an NPE indicator by itself.
• Primary line of business: Networking hardware, software, and services (routers, switches, mobile packet core). The '551 claims are directed to a packet gateway (PDSN / SGSN / GGSN per the specification) that triggers RSVP actions off terminal dormancy state transitions — i.e., mobile packet-core functionality.
• Did they ship a product embodying the claims? Likely (moderate confidence). Cisco sold PDSN/GGSN-class mobile packet gateway products in the 2.5G/3G timeframe contemplated by the specification. I could not verify, in this research pass, a specific Cisco product release note or datasheet tying RSVP-triggered dormancy bandwidth handling to a named SKU; treat the product-embodiment statement as inference from the specification's own product framing (PDSN/SGSN/GGSN, Cisco CNS Access Registrar, Cisco Broadband Policy Manager) rather than as documented evidence.
• Current status: Operating. Cisco Systems, Inc. remains a public NYSE company and active patent enforcer/defendant in both directions. Cisco Technology, Inc. is not dissolved, not in bankruptcy, and has no recorded transfer of this patent.
• Maintenance discipline: Fees paid at 4 years (2011-07-29), 8 years (2015-07-29), and 12 years (2019-07-29, large entity). Cisco paid to run this patent to its full term. No abandonment, no lapse-for-nonpayment, no sale.

Assignment timeline

The USPTO record contains exactly one assignment for US 7,324,551 — the original, filing-time, employee-to-employer assignment. There are no post-issuance assignments of any kind. Google Patents' "Legal Events" table for this patent shows only the assignment event (plus grant and fee-payment events), and no Assignments/Mergers/Change-of-Name events appear after 2002.

• 2002-12-10 (executed) / recorded 2002-12-11 — Reel 013576/0482
  • Conveyance: Assignment of assignors' interest ("ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS)")
  • Assignor: Timothy P. Stammers
  • Assignee: Cisco Technology, Inc. (California)
  • Correspondent: Not exposed in the source surfaced here. The public record I retrieved (Google Patents legal-events mirror, USPTO assignment reel/frame 013576/0482) shows the reel/frame, parties, conveyance, and effective date, but does not reproduce the correspondent/correspondent-address field. Because the signal the client cares about is recurrence of a correspondent across a chain, and this chain has exactly one link, I am declining to name a correspondent rather than infer one from unrelated Cisco prosecution filings. The Assignment Center entry at https://assignmentcenter.uspto.gov/ is the authoritative place to read that field; nothing in the retrieved record suggests an unusual recording agent, and the same-day/next-day recording latency is consistent with in-house or outside counsel filing a routine corporate assignment contemporaneously with the application.
  • Context: Internal, filing-time corporate assignment. Executed 2002-12-10, filed 2002-12-11 — rights were assigned to the employer before/at filing, as is standard for employee inventions. This is not an acquisition, fire-sale, securitization, or transfer-to-asserter; it is the baseline employment assignment.
  • Recurrence flag: N/A — this correspondent appears only once because there is only one link in the chain.

Timeline diagram

timeline
    title Ownership of US 7324551
    2002 : Stammers assigns rights to Cisco
         : Application filed 11 Dec 2002
    2008 : Patent issued 29 Jan 2008
    2011 : 4-year maintenance fee paid
    2019 : 12-year maintenance fee paid
    2025 : Patent term expires 8 Dec 2025

NPE / troll-pattern signals

Verdict

Insufficient data — only the original assignment.

The record for US 7,324,551 contains a single recorded assignment — reel 013576/0482, executed 2002-12-10, recorded 2002-12-11, conveying Timothy P. Stammers' rights to Cisco Technology, Inc. — and nothing else: no post-issuance transfer, no merger, no security interest, no license record, no change of name. Under the rubric this squarely fits "Insufficient data (no records, or only the original assignment)," but the substantive read is the opposite of a troll case: this is a clean, single-owner, operating-company patent (Cisco) that was maintained to full term with 4-, 8-, and 12-year fee payments (2011-07-29, 2015-07-29, 2019-07-29) and expired on 2025-12-08 without ever being sold or asserted. No NPE signal is present, and none of the eight patterns can be evidenced from the assignment record.

Verification links:

• USPTO Assignment Center (search patent 7324551): https://assignmentcenter.uspto.gov/
• USPTO Patent Assignment Search (legacy UI): https://assignment.uspto.gov/patent/index.html
• Google Patents legal events: https://patents.google.com/patent/US7324551B1/en

Caveats and confidence: High confidence that Cisco Technology, Inc. is the only ever-assignee and that no post-issuance assignment exists — Google Patents legal events, the reel/frame citation, and maintenance-fee history all align. Moderate confidence on product embodiment (inferred from the specification's own PDSN/GGSN framing, not from a verified product datasheet). The correspondent-of-record field for reel 013576/0482 was not retrievable from the mirrored sources used here and is affirmatively marked unknown rather than inferred; a definitive read requires the Assignment Center's per-record detail view. Absence of litigation is based on searches that surfaced no suit naming the '551 patent — it is evidence of absence, not proof, though the expired status makes assertion moot now.

I'll verify the patent record and examine each cited reference. Let me search authoritative sources.

Let me gather details on the remaining cited references.

Prior-Art Analysis — U.S. Patent No. 7,324,551

Verified record (not a similar number): U.S. Patent 7,324,551 B1, "System and method for managing bandwidth in a network environment"; inventor Timothy P. Stammers; assignee Cisco Technology, Inc.; App. No. 10/316,726; filed and priority-dated 2002‑12‑11; granted 2008‑01‑29. Confirmed against the Google Patents full text you supplied, the FreePatentsOnline mirror (freepatentsonline.com/7324551.html), the Justia mirror (patents.justia.com/patent/7324551), and the USPTO-hosted PDF (patentimages.storage.googleapis.com/.../US7324551.pdf). The prior-art date for the §102 analysis below is therefore December 11, 2002.

Sourcing limitation (flagged): I completed USPTO/Google Patents lookups for US6157648A, US6366577B1, US6452915B1 and US6449588B1. My searches for US6483835B1, US2005/0027870A1 and US2007/0133403A1 were cut off by tool limits, so for those three the description relies on the authoritative citation table in the patent you supplied plus general bibliographic knowledge, and I mark it as lower-confidence.

The seven references cited on the face of US 7,324,551

1. US 6,157,648 B1 — "Network session management"

• Full citation: Voit, E.A.; Balkovich, E.E.; Farris, R.D.; Goodman, W.D.; Gadre, J.G.; White, P.E.; Young, D.E.; U.S. Patent 6,157,648 B1; Bell Atlantic Network Services, Inc.; app. 08/931,477 filed 1997‑09‑16 (continuation‑in‑part of 08/812,075 filed 1997‑03‑06); granted 2000‑12‑05. (uspto.report/patent/grant/6,157,648)
• Description: A communication system providing telephony across combined circuit‑switched and packet‑switched networks using a distributed "directory object" and multiple gateway objects. The directory object polls gateways for status and performs intelligent routing; the abstract expressly states that "reservability of communication paths and/or bandwidth may be provided" and that "specified bandwidth [may be provided] either on a subscribed basis or on point of call demand," with customer routing/handling parameters stored (claims 5, 6, 32–33 recite quality‑of‑service parameters and requester profile information).
• §102 analysis: This is the only cited reference whose abstract expressly recites bandwidth reservability and stored customer QoS/routing parameters, which maps to the profile‑based dependent claims (4, 5, 9, 10, 18) and to the "control a bandwidth allocation" element. It does not, however, disclose a packet gateway that (i) monitors a dormancy state transition of a communication session, (ii) triggers RSVP actions from that transition, or (iii) does so "without requiring a responsive communication from the end user." Reservations here are made on point‑of‑call demand by the calling terminal/directory, not autonomously by a gateway from a state change. It does not anticipate any claim (independent claims 1, 6, 11, 12, 15 or their dependents). Its realistic role is a §103 reference on the profile/QoS‑storage and bandwidth‑reservation concepts of claims 4–5 and 9–10.

2. US 6,483,835 B1 — "Communication system with communication route retrieval and selection function"

• Full citation: Hitachi, Ltd.; U.S. Patent 6,483,835 B1; filed 1997‑06‑12; granted 2002‑11‑19. (lower-confidence — search truncated)
• Description: Route retrieval and selection in a communication system — path/route discovery and selection functionality.
• §102 analysis: Route selection is at most tangentially related to the "controlling a bandwidth allocation" and "state transition" elements. There is no teaching of RSVP signaling, dormancy transitions, packet gateways, or end‑user‑independent triggering. It anticipates no claim; lowest‑relevance reference in the set — background art only.

3. US 2005/0027870 A1 — "System and method for providing peer‑oriented control of telecommunication services"

• Full citation: Trebes, Harold Herman; U.S. Publication 2005/0027870 A1; filed/priority 1998‑04‑14; published 2005‑02‑03. Statutory basis: §102(e) (pre‑2002‑12‑11 effective filing date).
• Description: Peer‑oriented control of telecommunication services. (lower-confidence — search truncated)
• §102 analysis: A peer‑oriented service‑control architecture does not disclose RSVP actions triggered by an end‑user dormancy state transition at a packet gateway, nor the "no responsive communication from the end user" limitation. It anticipates no claim. Because its effective date predates the '551 filing date, it remains available as a §102(e)/§103 backdrop, but it is not on point.

4. US 6,452,915 B1 — "IP‑flow classification in a wireless point to multi‑point (PTMP) transmission system"

• Full citation: Malibu Networks, Inc.; U.S. Patent 6,452,915 B1; priority 1998‑07‑10 (provisional 60/092,452); filed 1999‑07‑09; granted 2002‑09‑17. (patents.google.com/patent/US20030067903; continuation issued as US 7,251,218 B2)
• Description: A QoS‑aware packet‑centric wireless PtMP architecture. Claim 1 recites a wireless base station, CPE stations "in wireless communication … over a shared bandwidth," a "resource allocation means optimizing end‑user quality of service (QoS) and allocating shared bandwidth," and a classifier that analyzes/schedules IP flows. This is the cited reference most concerned with shared‑bandwidth allocation to wireless end users and QoS classification.
• §102 analysis: It closely maps to the "control a bandwidth allocation associated with the end user" element and the QoS/profile‑related dependent claims (4, 9, 18), in a wireless context analogous to the patent's RAN/mobile setting. But its bandwidth allocation is driven by IP‑flow classification and scheduling, not by a dormancy state transition, and it contains no RSVP action and no gateway acting "without requiring a responsive communication from the end user." No claim is anticipated. Best characterized as a §103 reference on wireless QoS/bandwidth‑allocation and on the general wireless environment.

5. US 6,449,588 B1 — "Customer‑driven QoS in hybrid communication system"

• Full citation: Bowman‑Amuah, Michel K.; Accenture LLP (now Accenture Global Services); app. 09/324,348 filed 1999‑06‑02; granted 2002‑09‑10. (freepatentsonline.com/6449588.html; portal.unifiedpatents.com/patents/patent/US-6449588-B1)
• Description: A "Customer Quality of Service Management system" for hybrid circuit/packet networks. Its specification discusses next‑generation networks that "dynamically reconfigure the network so that it can guarantee a predetermined amount of bandwidth for the requested quality of service (QOS)," a rules database holding subscriber profiles (QoS terms, service‑level‑agreement terms, bandwidth/QoS requirements), and per‑customer profile storage used to control service delivery.
• §102 analysis: This is the closest cited reference on the "profile … includes bandwidth reservation data … and data associated with one or more quality of service parameters" limitation of dependent claims 5, 10, 9, 18. It is a central‑server/rules‑database profile architecture, matching the patent's centralized server 28 concept. However, it is a QoS management, monitoring and reporting system; it discloses no packet gateway, no RSVP actions, and no dormancy‑state‑transition trigger, so it cannot supply the independent‑claim elements. It anticipates no claim; it is a strong §103 reference against claims 5 and 10 (and the "centralized server stores a profile" concept).

6. US 6,366,577 B1 — "Method for providing IP telephony with QoS using end‑to‑end RSVP signaling"

• Full citation: Donovan, Steven R.; MCI WorldCom, Inc.; app. 09/586,203 filed 2000‑06‑02 (continuation‑in‑part; priority 1999‑11‑05); granted 2002‑04‑02. (patentimages.storage.googleapis.com/ea/39/3b/af0e22b6b291e3/US6366577.pdf; freepatentsonline.com/6366577.html)
• Description: Combines SIP, RSVP, COPS and OSP to set up, maintain and tear down Internet calls with QoS. Network elements receive an RSVP PATH or RESV request and query a policy server; a policy server checks a local database/clearinghouse; upon positive acknowledgment "the policy server confirms policy in network elements to accept RSVP PATH and RESV requests for the particular reserved data flow," so that "the called telephone will not ring until policy has been provisioned … and resources have been reserved — end‑to‑end." Includes RSVP reservation, call admission and traffic classification.
• §102 analysis: This is unquestionably the closest art on the RSVP limitation — it discloses RSVP actions and controlling bandwidth/QoS reservations based on RSVP — and it is the reference the examiner likely relied on most for the "initiating one or more resource reservation protocol (RSVP) actions … controlling a bandwidth allocation" elements of claims 6 and 15. But it is decisively different on the two limitations that define the '551 invention:
  1. Trigger: In Donovan, the reservation is initiated by the end user's own terminal sending RSVP PATH/RESV messages ("SIP client 11i requests network resources for QoS using RSVP"). The '551 patent instead requires the packet gateway to trigger RSVP actions based on a dormancy state transition.
  2. No end‑user signaling: Donovan is built on end‑to‑end end‑user RSVP signaling, which is the exact overhead the '551 patent eliminates; the '551 claims require the action be taken "without requiring a responsive communication from the end user."
     Because it teaches away from (rather than discloses) the state‑transition‑triggered, end‑user‑independent RSVP action, it does not anticipate claims 1, 6, 11, 12 or 15 or their dependents under §102. It is nonetheless the primary §103 reference against the RSVP‑related elements.

7. US 2007/0133403 A1 — "VoIP endpoint call admission"

• Full citation: Avaya Technology Corp.; U.S. Publication 2007/0133403 A1; priority 2002‑09‑30; published 2007‑06‑14. Statutory basis: §102(e) (effective filing date before 2002‑12‑11). (lower-confidence detail — search truncated)
• Description: Call admission control for VoIP endpoints — deciding whether to admit a call/flow based on resource availability.
• §102 analysis: Call admission is conceptually adjacent to the "controlling a bandwidth allocation" element and to the §102 admission/resource‑allocation classification of the '551 patent, and its pre‑filing priority makes it a §102(e) reference. But it discloses endpoint‑driven admission, not a packet‑gateway monitoring a dormancy transition and autonomously triggering RSVP release/request. It anticipates no claim; at most a §103 reference on the call‑admission/QoS aspect of claims 1, 6, 12 and 15.

Bottom line

• No cited reference anticipates any claim of US 7,324,551 under 35 U.S.C. § 102. None discloses the combination that defines every independent claim (1, 6, 11, 12, 15): a packet gateway that (a) monitors a dormancy state transition of an end user's communication session, (b) initiates RSVP actions based on that transition, and (c) does so without requiring a responsive communication from the end user — with active→dormant releasing and dormant→active requesting the bandwidth allocation (claims 2/3/7/8/13/14/16/17).
• Strongest §102 challengers if the claims were construed broadly (none succeeds on the full claim): Donovan/US 6,366,577 on the RSVP‑action elements (claims 6, 15); Malibu/US 6,452,915 on wireless bandwidth allocation/QoS (claims 4, 9, 11, 18); Accenture/US 6,449,588 and Bell Atlantic/US 6,157,648 on profile‑based QoS/bandwidth reservation at a central server (claims 5, 10).
• The references collectively support a §103 obviousness narrative, not §102 anticipation: Donovan supplies RSVP‑based reservation/admission; Malibu supplies wireless shared‑bandwidth QoS allocation to end users; Accenture, Bell Atlantic and Avaya supply customer profiles with QoS/bandwidth parameters, centralized profile storage and call admission. The non‑obvious point of novelty is the linkage — using the gateway's known dormancy state transition as the sole trigger for autonomous RSVP release/request, eliminating over‑the‑air RSVP refresh signaling.
• Corroborating indicator (not prior art): the examiner/third‑party forward citation US 8,270,411 B1, "Bandwidth allocation based on dormancy transitions" (Sprint, priority 2009‑12‑11) is a direct conceptual successor applying the same dormancy‑transition→bandwidth linkage — consistent with the '551 patent's core being the novel contribution rather than the individual building blocks recited in the references above.

If you want, I can next map each reference element‑by‑element against claim 1 (and claim 6) in a §102/§103 claim chart, or pull the full text of US 6,483,835, US 2005/0027870 A1 and US 2007/0133403 A1 to complete the three lower‑confidence entries.

I'll ground this §103 analysis by pulling the cited references' actual disclosures.

Let me pull the remaining cited references to ground the combination analysis.

Obviousness Analysis — U.S. Patent No. 7,324,551 (35 U.S.C. § 103)

Analysis date: April 26, 2026 (per task); note the system clock reads 2026-09-30 and the prior section was fetched 2026-09-24. I flag the discrepancy but it does not affect the substance below.

Applicable law: The application was filed 2002-12-11, so pre-AIA § 103(a) governs (no AIA § 102(d)/103 reordering). The controlling framework is Graham v. John Deere (scope/content, differences, PHOSITA level, secondary considerations) as refined by KSR Int'l v. Teleflex, 550 U.S. 398 (2007). As a post-KSR matter, "a court must ask whether the improvement is more than the predictable use of prior art elements according to their established functions."

Practical threshold note: the patent's exclusive rights expired 2025-12-08 (per the record). This analysis is therefore relevant principally to retrospective defenses (damages periods, pending or contemplated validity challenges), not to prospective injunctive exposure.

1. Level of ordinary skill

A PHOSITA here would hold a B.S. in EE/CS (or equivalent) plus 2–4 years of experience in packet-switched networking, with familiarity with RSVP/int-serv (IETF RFC 2205, RFC 1633), IP QoS architecture, and 2.5G/3G wireless data (PDSN, GGSN/SGSN) including terminal dormancy. All of the cited references are themselves framed at this level.

2. Constructions that matter for § 103

3. What the prior art actually teaches (grounded)

US 6,366,577 B1 — Donovan (MCI WorldCom), priority 1999-11-05. Method for providing IP telephony with QoS using end-to-end RSVP signaling. Teaches using SIP + RSVP + COPS + OSP together "to setup, maintain, and teardown Internet communications having an acceptable QoS," with "dynamically establishing RSVP policy based on SIP telephony requests." Emphases relevant here:

• Network-side initiation of resource control: policy may be "provisioned on a real time basis to the router (PUSH) instead of the router querying for the policy on a real time basis (PULL)." That is, a signaling event triggers resource control; endpoint-driven RSVP refresh is not required.
• Release on session end: FIG. 4 is expressly "RSVP teardown signaling and release of QoS resources."
• Per-flow reservation with a classifier/policy: policy server "confirms policy in network elements to accept RSVP PATH and RESV requests for the particular reserved data flow."
• Motivation language: the stated goal is that "the called telephone will not ring until policy has been provisioned… and resources have been reserved end-to-end."
  Source: https://patents.google.com/patent/US6366577

US 6,452,915 B1 — Jorgensen (Malibu Networks), filed 1999-07-09, priority 1998-07-10. IP-flow classification in a wireless PTMP transmission system. This is the wireless/QoS architecture reference:

• "a resource allocation device optimiz[ing] end-user quality of service (QoS) and allocat[ing] shared bandwidth among the subscriber CPE stations."
• RSVP support and, critically, translation into access-link resources: "configurable translation of RSVP Flowspecs for QoS resource allocation in wireless base station 302"; recognizes "Path messages, Reservation (Resv), Path teardown messages, Resv teardown messages, Path error messages, Resv error messages, and Confirmation messages" and objects including Flowspec.
• Per-terminal state at the access node: "The wireless base station 302 has a state machine, and knows the state of each CPE station 294 having a connection therewith (i.e., having an IP flow recognized by the wireless base station)."
• Per-subscriber QoS/SLA profiles at the node: SLA priority data table 1570/1670, DEN data table 1572/1672, and OAM&P module 1108 for provisioning subscriber SLA.
• Stated design driver: wireless "limited bandwidth," high BER, and the need for "application-specific flow control" to conserve "scarce wireless bandwidth."
  Source: https://patents.google.com/patent/[US6452915B1](/patent/US6452915B1)

US 6,157,648 — Bell Atlantic Network Services ("Network session management"). From the citation list and the related record I retrieved, this reference is directed to managing call/session establishment and teardown across a hybrid circuit/packet network, with service control points/databases and service-control triggers governing session handling. Verification flag: the PTAB petition excerpt I retrieved quotes a "Bellovin" reference (Ex. 1003/1004) disclosing a packet-IP telephony system with Border Telephony Interfaces, gate controllers, and edge-router "gates," and states that on call termination there are "messages to release the reserved bandwidth and to close the gates in the edge routers," and that when a call is placed on hold the "bandwidth reservation… is decommitted, but the reservation for the resource is maintained so that it is available if its call was to resume," with the reverse process performed to resume. I could not confirm in this session that Ex. 1003 is US 6,157,648 specifically. I therefore rely on that teaching below only as a secondary, moderate-confidence ground and not as a linchpin. Source: https://patents.google.com/patent/[US6157648A](/patent/US6157648A)/en and https://ptacts.uspto.gov/ptacts/public-informations/petitions/[1459858](/patent/1459858)/download-documents

US 6,449,588 B1 — Accenture (Bowman-Amuah et al.). Customer-driven QoS in hybrid communication system. Teaches retrieving "Quality of Service details for a customer from a rules database server," mapping network events to "a service offering of the hybrid network and to a customer," and network-manager control over bandwidth allocation/QoS. Weakness as to claims 5/10: its disclosed output is report generation, not bandwidth reservation. It is usable for the storage of centralized per-customer QoS data concept only. Source: https://patents.google.com/patent/[US6449588B1](/patent/US6449588B1)

Not retrieved (tool limit reached before fetch): US 2007/0133403 A1 (Avaya, "VoIP endpoint call admission," effective § 102(e) date 2002-09-30 — within the critical date window), US 2005/0027870 A1 (Trebes, § 102(e) date 1998-04-14), US 6,483,835 (Hitachi). I will not characterize their disclosures; Avaya '403 is the most promising unexplored reference because its title places it squarely in admission control at a VoIP endpoint, and its 2002-09-30 date is available as prior art notwithstanding its 2007 publication.

4. Ground 1 — Donovan '577 + Jorgensen '915 (primary)

Proposed rejection: claims 1–4, 6–9, 11–15, 18 obvious over Donovan in view of Jorgensen; claim 5 and claim 10 further in view of Accenture '588 (or Jorgensen's SLA/OAM&P tables).

Element mapping (claim 1 / claim 6 / claim 11 / claim 12 / claim 15 share the same core):

Motivation to combine (KSR rationales, all supported):

1. Known technique, predictable result. Jorgensen already recognizes and supports RSVP (RFC 2205) and explicitly contemplates translating RSVP Flowspecs into access-link resource allocation. Substituting RSVP as the reservation protocol in a network-initiated QoS architecture (Donovan) is the use of a known technique for its known purpose.
2. Industry standardization/market pressure. Donovan's entire premise is that SIP/RSVP/COPS interoperation is desirable so sessions get end-to-end QoS across administrative domains. A PHOSITA in 2002 had strong reason to use the IETF standard reservation protocol rather than a proprietary one.
3. The design need identified by the art itself. Jorgensen emphasizes scarce wireless bandwidth and the cost of over-the-air signaling; Donovan's PUSH model eliminates endpoint round trips for policy. Combining them to move reservation control to the network node directly addresses the stated problem.
4. No teaching away. Donovan expressly states the "concept can also be extended for use with any end-to-end reservation protocol" and applies to network-provisioned policy.

Claims 2/3, 7/8, 13/14, 16/17 (release on active→dormant; request on dormant→active). Donovan's FIG. 4 (RSVP teardown/release) supplies release-on-session-end. For the dormancy-specific pairing, the secondary ground below supplies "decommit on hold / recommit on resume," which is the same release/request dyad. Independently, the '551 specification admits that the dormancy signaling itself is conventional: "a message may be sent from RAN 14… that indicates end user 12 is dormant. A subsequent message may then indicate that end user 12 is now active. This state transitioning protocol is recognized by packet gateway 22." That admission reduces the dependent claims to the linkage of a known state signal to a known RSVP action.

Claims 4/9/18 (QoS parameters stored in an end-user profile). Jorgensen's SLA priority data table, per-flow QoS requirement tables (1534/1634), and OAM&P provisioning module 1108 store per-subscriber QoS parameters at the node. The '551 spec concedes location is optional ("any of the information stored on centralized server 28 may be alternatively stored within packet gateway 22"), which forecloses a nonobviousness argument premised on location.

Claims 5 and 10 (centralized server storing profile with bandwidth-reservation data and QoS data). Accenture '588 teaches retrieving customer QoS details from a rules database server and mapping events to a customer's service offering. Weak but adequate for the storage/provisioning concept; alternatively Jorgensen's OAM&P/DEN/SLA provisioning satisfies "profile… including data associated with one or more QoS parameters," and "bandwidth reservation data" is supplied by either reference's reservation parameters (Donovan's Flowspec/policy data, Jorgensen's Flowspec translation). Caveat: claim 10 as printed depends from claim 4 (an apparatus claim) while reciting a "method" — a facial § 112 defect I flagged in the prior section. A § 103 challenge to claim 10 should be pleaded in the alternative (obvious over '577+'915+'588 if construed as a method claim) because its indefiniteness may make a clean obviousness holding awkward.

5. Ground 2 — Secondary: network-session-management reference (Bellovin/'648) + Donovan '577

Why it adds value: the record excerpt teaches exactly the release/request-on-state-change behavior the dependent claims require, achieved by network elements rather than endpoint renegotiation:

• Call termination: "messages to release the reserved bandwidth and to close the gates in the edge routers."
• Call hold: "bandwidth reservation for sending voice data… is decommitted, but the reservation for the resource is maintained so that it is available if its call was to resume"; on resume, "the reverse process is performed."
• Gating is per-flow: the gate grants higher QoS only to packets matching "Source IP/Destination IP/Destination Port" — i.e., a traffic classifier in the QoS forwarding path, which is the '551's own characterization of RSVP signaling element 24's function ("install a traffic classifier… how to classify packets from a particular flow and what forwarding treatment to provide").

Combined with Donovan's RSVP teardown/release and PUSH-model policy provisioning, the resulting system is the claim 2/3 (and 7/8, 13/14, 16/17) subject matter: bandwidth released on active→inactive and re-requested on inactive→active, accomplished by network elements acting on session state, with the reservation "maintained" across the inactive interval — precisely the '551's stated advantage of eliminating "the signaling overhead needed for refreshing bandwidth reservations."

Motivation: (i) both references address IP-telephony QoS over a packet backbone and seek to avoid service degradation; (ii) replacing a proprietary reservation signaling scheme with the IETF-standard RSVP protocol is a predictable substitution yielding the same QoS result with better interoperability; (iii) the record reference's own keepalive/refresh mechanism exists only because it lacks a state-transition trigger — using the network's known call state to drive reservation changes eliminates that overhead, which is a recognized design incentive.

Confidence caveat: as noted, my attribution of these teachings to US 6,157,648 specifically is moderate, not high. If verified, this becomes the closest single reference for the dependent claims; if not verified, Ground 1 stands independently.

6. Anticipation-adjacent observation

For all five independent claims, the only element not squarely met by the combination of Donovan + Jorgensen is the explicit negative limitation "without requiring a responsive communication from the end user." Donovan's PUSH model and its policy-server confirmation flow disclose network-side provisioning of the reservation without an endpoint response, and Jorgensen's base-station state machine acts on state it already possesses. A PHOSITA would recognize that if the network already knows the terminal's state, requiring the terminal to answer would be a redundant, resource-wasting step — the very defect the '551 identifies in its Background.

7. Presumed rebuttal arguments and assessment

8. Artifacts and corrections to avoid propagating

1. The "Cited By" list is not prior art. Every forward citation on the page post-dates the 2002-12-11 filing date — including the conceptually closest one, US 8,270,411 B1 (Sprint, "Bandwidth allocation based on dormancy transitions," filed 2009-12-11, granted 2012-09-18). Sprint '411 cannot be used in a § 102/§ 103 rejection against '551. Its value is evidentiary only: it shows that linking dormancy transitions to bandwidth allocation was a natural, industry-recognized design direction — but that is not a permissible primary rationale, and any draft rejection leaning on it should be removed.
2. Avaya '403 is the gap in this analysis. US 2007/0133403 A1 has an effective § 102(e) date of 2002-09-30, inside the critical window. I could not retrieve its text and will not speculate. It should be pulled before finalizing the rejection.
3. Do not "fix" the identifiers. US 6,157,648 is listed on the face as "Network session management," Bell Atlantic; US 6,366,577 is Donovan/MCI WorldCom; US 6,452,915 is Jorgensen/Malibu; US 6,449,588 is Accenture; US 2005/0027870 A1 is Trebes; US 6,483,835 is Hitachi. I have used the numbers exactly as printed.
4. Claim 10 dependency defect (recites "method of claim 4," an apparatus claim) is carried forward as printed and affects how a claim-10 rejection should be framed.

9. Bottom line

• Claims 1–4, 6–9, 11–15, 18: Strongly vulnerable under § 103 over US 6,366,577 (Donovan) in view of US 6,452,915 (Jorgensen). The combination supplies every element of the independent claims, including the negative "no responsive end-user communication" limitation, and the motivation is supplied by the references themselves plus ordinary standardization pressures and the recognized need to conserve access-link bandwidth.
• Claims 2/3, 7/8, 13/14, 16/17 (dormancy release/request): Vulnerable, with the state-transition-to-reservation-change dyad available from the network-session-management reference (Bellovin, moderate-confidence attribution to US 6,157,648) and independently weakened by the specification's own admission that the dormancy signaling protocol is pre-existing and "recognized by packet gateway 22."
• Claims 5 and 10: Vulnerable but on thinner ground; rely on US 6,449,588 (Accenture) plus Jorgensen's SLA/OAM&P profile provisioning for the centralized-profile limitation.
• Highest-value next steps: (1) retrieve US 2007/0133403 A1 (Avaya) and evaluate it as a standalone or secondary reference for the admission-control-in-response-to-session-state limitation; (2) verify the Bellovin exhibit-to-patent-number mapping before relying on Ground 2; (3) confirm whether the asserted "state transitioning protocol" of the '551 specification has an express evidentiary basis in a prior-art mobile-IP/dormancy reference, since that would convert the dependent claims into a near-anticipation posture.

Confidence summary: claim text, claim constructions, and the Donovan/Jorgensen disclosures are high confidence (retrieved and quoted). The Bellovin/'648 mapping is moderate confidence and expressly flagged. Avaya '403, Trebes '870, and Hitachi '835 contents are not characterized — I did not obtain them.