US 7444669

I'll search for authoritative information on this specific patent number, including any litigation or CAFC docket activity.

Let me dig deeper on the claims and any litigation/docket activity.

Let me attempt to locate the actual claim text, since the provided patent text is truncated before the claims.

US Patent 7,444,669 — Summary

Important note on sources: The full patent text you supplied is authoritative but is truncated — it ends mid‑sentence in the Detailed Description ("...an individual may be traveling thro"). The Claims section is not included, so I cannot quote or faithfully paraphrase the independent claims from the authoritative source. I flag this rather than reconstruct them. My searches also returned no CAFC 2026 docket activity tied to this number (details below).

Bibliographic data (from the supplied patent text)

Assignee uncertainty: The USPTO assignment record reproduced in the patent text shows a 2014‑12‑09 assignment to Microsoft Technology Licensing, LLC. However, a third‑party aggregator result (Unified Patents portal) surfaced "Intellectual Ventures I LLC" adjacent to this patent number and a priority date of 2000‑02‑21, with several sibling titles. That listing appears to be a family‑level aggregation and may not reflect the recorded assignee of the '669 patent specifically. I could not verify an IV assignment to the '669 patent and treat it as unconfirmed.

Abstract (verbatim from the patent)

"Systems and methods for providing network access, e.g. Internet access, are described. An architecture includes a host organization network through which network access is provided. The host organization network can be advantageously deployed in public areas such as airports and shopping malls. An authentication/negotiation component is provided for authenticating various users and negotiating for services with service providers on behalf of the system users. The authentication/negotiation component can include one or more specialized servers and a policy manager that contains policies that govern user access to the Internet. An authentication database is provided and authenticates various users of the system. An access module is provided through which individual client computing devices can access the Internet. In one embodiment, the access module comprises individual wireless access points that permit the client computing devices to wirelessly communicate data packets that are intended for the Internet. In one aspect, users are given a variety of choices of different service levels that they can use for accessing the Internet. The service levels can vary in such things as bandwidth allocation and security measures. The various service levels can be purchased by the users using their computing devices."

Plain‑language overview of the disclosed invention (specification, not claims)

The disclosure describes a PANS (Protocol for Authentication and Negotiation of Services) server plus a Policy Manager deployed in public venues (airports, malls, libraries) that:

1. Authenticates users — optionally via a globally accessible database (e.g., Microsoft Passport) in an end‑to‑end secure fashion, so the local PANS server never sees the user's credentials (SSL);
2. Issues each authenticated user a unique, dynamically generated token/key (arbitrary selectable length, e.g., 40/128/256 bits, with a randomly selected one of several encryption algorithms) that is embedded in each outbound packet and validated at the PANS server;
3. Negotiates service levels with third‑party ISPs on the user's behalf, per user‑selected parameters such as data rate and price;
4. Enforces user‑based (rather than flow‑based) quality of service, with a premium per‑user guaranteed‑bandwidth tier (Level I) and group‑arbitrated tiers (Levels II/III), using "go" signals and dynamic re‑allocation;
5. Accounts for traffic (per‑packet, per‑byte, or per‑time) for billing and scheduling;
6. Applies dynamic compression keyed to measured transmission error thresholds (FIG. 11 lookup table); and
7. Provides a GUI with bandwidth/cost sliders and real‑time data‑rate feedback (FIG. 12).

Reflecting this, the patent carries classifications including H04L47/805 (QoS/priority aware), H04L47/824 (portable/mobile terminals), H04L47/828 (per‑group resource allocation), H04L63/0815 (single sign‑on), H04W12/041 & H04W12/0431 (key generation/distribution), and G06Q20/3674 (wallet‑based authentication).

Independent claims — cannot be authoritatively provided

Because the supplied text omits the claims, I do not have authoritative claim language for US 7,444,669. Based on the title ("...providing variable rates of service for accessing networks, methods and systems for accessing the internet") and the sibling continuations, the independent claims most plausibly fall into at least two groups — (a) method/system claims for offering and enforcing variable rates/levels of service to users accessing a network, and (b) method/system claims for accessing the Internet through the host‑organization architecture. This is inference from the title and specification, not a reading of the claims, and should be verified against the granted claim set at patents.google.com/patent/US7444669B1/en or USPTO PatentCenter.

Litigation / CAFC 2026 docket check

• My targeted searches for "7444669" + CAFC 2026 / Federal Circuit docket returned no results. I found no evidence of any Court of Appeals for the Federal Circuit 2026 docket involving this patent number.
• Note also that the patent is recorded as Expired – Fee Related (anticipated expiration 2020‑05‑05), which makes active 2026 appellate litigation on the '669 patent itself unlikely. (The related IV v. Sprint/T‑Mobile matters surfaced in search involve different Intellectual Ventures patents such as 9,320,018 / 9,681,466 / 8,682,357 — not the '669 patent.)
• Bottom line: no authoritative indication of 2026 CAFC activity for US 7,444,669; I cannot confirm any, and absence of results is not proof of absence.

If you can supply the claims portion of the patent text (or the USPTO PatentCenter claim listing), I can give you an exact, claim‑by‑claim plain‑language breakdown of the independent claims.

I'll search for litigation involving US patent 7444669 across patent litigation databases.

Let me dig deeper into specialized litigation sources.

Bottom line

I could not identify any litigation — past or pending — involving U.S. Patent No. 7,444,669. Every search I ran returned the patent only in non‑litigation contexts (patent databases, prior‑art listings, and PTAB exhibit/citation lists). I found no complaint, docket, case number, plaintiff, or defendant tied specifically to the '669 patent.

I want to be explicit rather than pad the answer with look‑alike results: I am not reporting any case, because I did not find one.

What the patent is (relevant to why it may not have been litigated)

Per the authoritative full text and the Google Patents record:

• Title: Methods and systems for providing variable rates of service for accessing networks, methods and systems for accessing the internet
• Patent No.: US 7,444,669 B1
• Inventors: Paramvir Bahl; Srinivasan Venkatachary (recorded as "Venkatatchary"/"Venkatachary" in the assignment history); Anand Balachandran
• Original assignee: [Microsoft Corp.](/litigations/by-plaintiff/Microsoft%20Corp.); current assignee: Microsoft Technology Licensing LLC
• Application No.: 09/566,168; Filed: 2000‑05‑05; Granted/Published: 2008‑10‑28
• Status: Expired – Fee Related; anticipated expiration 2020‑05‑05

It is a member of a Microsoft family (e.g., related siblings US 7,032,241; US 7,085,924; US 7,149,896; US 7,313,237; US 7,548,976) claiming priority to U.S. application Ser. No. 09/511,171 filed Feb. 22, 2000. Microsoft is a large, active litigant and a frequent target, so the absence of asserted litigation is notable — but it is a factual observation, not a guarantee that none exists.

Caveats on my search (please verify independently)

• The "7444669" hits I got were in PTAB/USPTO exhibit PDFs (e.g., Fortinet IPR exhibits, Unified Patents petitions, and long comma‑delimited patent‑number lists used in petition claim charts or related‑matter listings). Those are citations/prior‑art compilations, not evidence that the '669 patent was asserted in litigation. I did not treat them as case results.
• I could not directly query PACER or run a native docket search on the Unified Patents litigation portal in this session; my results came from general web search. The Google Patents page's "Discuss" / "Litigation" affordances did not surface any case for this patent.
• Google Patents legal‑status entries (assignments, expiration) are not litigation records.

Recommended next steps to confirm

To close the gap, I'd run the following direct checks:

1. Unified Patents district‑court litigation portal — search the exact patent number at https://portal.unifiedpatents.com/litigation/caselist (or the patent‑specific page https://portal.unifiedpatents.com/patents/patent/US-7444669-B1).
2. PACER / CourtListener RECAP — full‑text docket search for "7,444,669" and "7444669."
3. USPTO Patent Trial & Appeal Board — search the patent number for any IPR/PGR/CBM involving the '669 patent as the challenged patent.
4. USPTO Assignment/Reassignment records — confirm whether the '669 patent was ever transferred to a monetization entity (e.g., an IV or Uniloc‑type assignee), which historically precedes assertion activity. The record provided lists only Microsoft → Microsoft Technology Licensing LLC (2014).

If you'd like, I can attempt targeted searches against CourtListener/PACER and the PTAB docket APIs to try to surface any case directly.

I'll verify the structured "no proceedings" default against public sources before drafting.

The "669" hits so far are all different patents (a Cioffi DSL patent, Inari Medical, etc.). Let me check for any proceeding that names US 7,444,669 directly.

Proceedings overview

Total AIA trial proceedings on US 7,444,669: 0. The USPTO Open Data Portal canonical list (the "PTAB proceedings on file" block) returns no IPR, PGR, or CBM naming US 7,444,669 as the challenged patent — so the breakdown by status is 0 active / 0 invalidated / 0 sustained / 0 settled / 0 institution-denied. My independent web verification surfaced no proceeding either (and, importantly, every "669" hit in those searches is a different patent — a Cioffi/ASSIA DSL patent, an Inari Medical catheter patent, a Renesas semiconductor patent, a 3M film patent, etc.; those are false positives on the number string, not on this patent). Defensive posture: this patent has never been tested at the Board. That is a double-edged signal — there is no invalidating FWD you can borrow, but it also means the patent is an expired (2020-05-05), never-asserted Microsoft artifact, and the practical monetary exposure to a defendant in 2026 is close to nil (see § 286 analysis below).

Because the count is zero, there are no per-proceeding entries (no proceeding numbers to report, and I will not fabricate any).

---

What I verified, and how

One item to flag explicitly for cross-checking with the earlier sections: a Unified Patents portal page (https://portal.unifiedpatents.com/patents/patent/US-7444669-B1) lists "Intellectual Ventures I LLC" adjacent to this number. That page is a patent-record/prior-art aggregation, not a docket; the IV label appears to be a family-level artifact (it also appears next to Microsoft sibling US 7,032,241). The recorded assignee chain in the authoritative text is Microsoft Corp. → Microsoft Technology Licensing LLC (2014-12-09). I found no record of an IV assignment to '669 specifically, and no PTAB proceeding filed by or against IV on this patent. Treat the IV association as unconfirmed.

---

Strategic summary

Claim status. There is no PTAB-certified claim status for US 7,444,669, because no claim has ever been canceled or confirmed in an AIA trial. Every claim is therefore UNTESTED at the Board — not "hardened," not "invalidated." Contrast the sibling continuations in the same Microsoft family (US 7,313,237 and US 7,548,976, which claim priority to the '669 filing stream) — the family field is active (e.g., US-7444669 appears in the citation lists of multiple unrelated IPRs), but the '669 patent itself is not a proceeding target.

Estoppel landscape. § 315(e)(2) estoppel is not triggered here, because no petitioner has ever been a party to an instituted IPR/PGR on this patent. There is accordingly no estoppel bar on any prior-art ground for a would-be challenger. In theory, all § 102/§ 103 grounds remain available in a fresh petition. In practice, the expiration date (2020-05-05) is the dominant fact:

• Under 35 U.S.C. § 286, damages are limited to infringement occurring within six years before the complaint. A complaint filed today (2026-10-01) reaches back only to 2020-10-01 — which is after the patent's expiration. The entire infringement (and damages) window has therefore already run out. A defendant's realistic monetary exposure on a pre-expiration patent this old is essentially zero, which in turn removes the economic reason to file an IPR.
• The CBM transitional program has sunset (the AIA § 18 window closed 2020-09-16), so the CBM avenue that this patent's G06Q20/36 / G06Q30/02 "business-method-adjacent" classifications might once have supported is no longer available, even though CBM-eligibility (a "financial product or service" + "technological invention" analysis) is exactly where such a patent would have been vulnerable.
• PGR is unavailable by definition (the patent has a 2000 priority date, well outside the 9-month PGR window).

Pattern signals. No repeated petitioner, no patent-owner appeal, no defensive-aggregator (Unified et al.) action on this number. This is consistent with the earlier litigation section's finding of no identified litigation — the patent appears never to have been asserted, which is why it never drew an IPR. Well-asserted Microsoft wireless-Internet patents of this era (cf. the i4i '449 litigation) did attract attack; the '669 patent did not.

---

Recommended next steps

1. If you have a demand letter citing US 7,444,669: the first-line response is expiration + § 286, not an IPR. The patent expired 2020-05-05, and the six-year damages lookback from any 2026 filing post-dates expiration — so demand-letter exposure is essentially a nuisance value at most. Verify the expiration and status at patents.google.com/patent/US7444669B1/en and USPTO PatentCenter (application 09/566,168).
2. Do not file an IPR as a reflex. There is no live PTAB proceeding, the patent is expired, and an IPR on an expired patent yields no amendment rights for the owner and limited practical benefit for you — the cost/benefit is poor unless a co-defendant or insurer needs a validity adjudication for indemnity reasons.
3. If you nonetheless need an invalidity adjudication (e.g., for a declaratory-judgment or contractual purpose), the viable non-AIA route is ex parte reexamination under 35 U.S.C. §§ 301–307 — it survives expiration and is far cheaper than an IPR. An AIA IPR is permissible on an expired patent (the Board may institute), but expect discretionary-denial headwinds on efficiency grounds.
4. Confirm the dockets yourself before relying on the zero-count result. Run: USPTO PTAB E2E / PTAB Decisions search on patent number 7444669; CourtListener RECAP / PACER full-text search for "7,444,669" and "7444669"; and the Unified Patents litigation portal page for US-7444669-B1. Absence of search hits is evidence, not proof, of absence — but three independent checks (ODP, Google Patents, general web) agree here.
5. Do not confuse this patent with other "669" patents. Multiple 2025–2026 PTAB papers reference a '669 patent in active IPRs (e.g., ASSIA/Cioffi DSL claims 1 and 14; Inari Medical 12,156,669). None of those is US 7,444,669; do not import their holdings or claim dispositions into an analysis of this patent.

Bottom line: No AIA trial proceeding has ever been filed on US 7,444,669. No claims have been canceled or sustained. The patent is expired, has never been asserted in identified litigation, and — because of expiration plus the § 286 lookback — presents minimal defensive urgency; the correct posture is a validity/exposure memo keyed to expiration, not an IPR petition.

I'll research the assignment record for US 7,444,669, starting with the sources I can query.

Let me search for the specific 2014 assignment details and the original inventor assignment record.

I have solid bibliographic data. Let me pin down the specific reel/frame entries for this patent's assignments.

Assignment Reconstruction — US 7,444,669 B1

Source / verification note before the findings: I was able to pull the Google Patents legal-events record (authoritative for dates and event text) and cross-check the Unified Patents patent page and Espacenet INPADOC family records. I was not able to open the individual USPTO Assignment Center abstracts or the underlying assignment PDFs for this patent in this session, so reel/frame numbers and the correspondent-of-record are only partially recoverable. Where I could not confirm a value I say so rather than fill the gap. Verify at:

• Assignment Center: https://assignmentcenter.uspto.gov/ (search "7444669")
• Legacy mirror: https://assignment.uspto.gov/patent/index.html
• Legal events: https://patents.google.com/patent/[US7444669B1](/patent/US7444669B1)/en
• Unified Patents patent page: https://portal.unifiedpatents.com/patents/patent/US-7444669-B1

This patent has a short, clean, all-Microsoft chain — no third-party or NPE links. Details below.

Inventors

All three were Microsoft Research wireless-networking researchers at the time of the 2000-05-05 filing, and all three appear as assignors on the inventors→Microsoft record. No unusual pattern: there is no evidence any inventor left Microsoft within 12 months of filing (Bahl in particular remained a long-tenure Microsoft Research figure). No "team-walks-out-then-fire-sale" signature. One minor housekeeping wrinkle: the second inventor's surname was misspelled ("Venkatatchary") on the original record and fixed by a corrective assignment in 2001 (see timeline).

Original assignee

Microsoft Corporation (One Microsoft Way, Redmond, WA 98052). Named on the issued patent and on the inventors→assignee records.

• Line of business / status: operating company; software and services. Still operating; not dissolved, not in bankruptcy.
• Did it ship a product embodying the claims? Partially/indirectly. The claims and spec describe a "PANS" server + Policy Manager deployed as a host-organization WLAN architecture for public-space Internet access (an architecture/protocol rather than a discrete shrink-wrapped product). Microsoft is unambiguously an operating company whose platforms (wireless networking in Windows, later Azure networking) touch this space, but the specific claimed host-organization architecture was research-stage in 2000. This is an operating-company patent, not an NPE-acquired patent.

Assignment timeline

Chronological, from the Google Patents legal-events record (dates are as listed; executed dates are not exposed in that record):

• Recorded 2000-10-10 — Reel 011172 / 0844 (see caveat)

  • Conveyance: Assignment (assignment of assignors' interest)
  • Assignor: Bahl, Paramvir; Venkatatchary, Srinivasan; Balachandran, Anand (individuals)
  • Assignee: Microsoft Corporation
  • Correspondent: not recoverable from sources retrieved (assignment PDF not opened)
  • Context: Original inventor assignment on an application filed 2000-05-05; ordinary employee-assignment record.
  • Caveat: the reel 011172/0844 value is taken from the cross-reference in the 2001 corrective record, which cites it as the previously recorded assignment. Reel 011172 is consistent time-wise with a 2000 recording.

• Recorded 2001-01-16 — Reel/Frame not exposed in the retrieved record

  • Conveyance: Correction ("corrective assignment to correct the 2nd assignor's name, previously recorded at reel 011172 frame 0844")
  • Assignor: Bahl, Paramvir; Venkatachary, Srinivasan (corrected spelling); Balachandran, Anand
  • Assignee: Microsoft Corporation
  • Correspondent: not recoverable from sources retrieved
  • Context: Administrative correction only — fixes the second inventor's surname; no change in ownership (change-of-spelling/name-in-record only).

• Recorded 2014-12-09 (effective date on the family records: 2014-10-14) — Reel/Frame within the Microsoft 2014 mass-transfer band (~0345xx) but exact frame for '669 NOT confirmed

  • Conveyance: Assignment
  • Assignor: Microsoft Corporation
  • Assignee: Microsoft Technology Licensing, LLC (One Microsoft Way, Redmond, WA)
  • Correspondent: not recoverable for '669 from sources retrieved. (For context, sibling Microsoft apps transferred in the same December 2014 batch show single consistent recording — e.g., US 11/834,406 recorded at reel 034543/0001 and US 13/468,949 at reel 034544/0541 on 2014-12-09 — indicating one high-volume correspondents' pipeline handled the entire Microsoft→MTL transfer. I could not confirm the specific frame assigned to '669.)
  • Context: internal corporate reorganization — Microsoft's 2014 spin-out of its IP-holding/licensing subsidiary (Microsoft Technology Licensing, LLC) during the Nadella restructuring. Volume transfer (~20% of 2014 US patent sales/assignments reported by IAM), not an arm's-length sale.

No other assignments are recorded. In particular, there is no transfer to any third-party NPE/asserter, and the chain ends at a wholly owned Microsoft subsidiary.

Contradiction flagged and resolved. The earlier patent summary flagged an unconfirmed "Intellectual Ventures I LLC" adjacency from an aggregator page. That is now explained: the Unified Patents page for US-7444669-B1 lists Intellectual Ventures I LLC's US-7,190,284-B1 as prior art cited against '669, not as an assignee. The recorded assignee is Microsoft Technology Licensing, LLC. The IV listing is a citation, not an ownership link — treat the IV theory as disconfirmed.

Timeline diagram

timeline
    title Ownership of US 7444669
    2000 : Inventors assign rights to Microsoft Corp
         : Application filed May 2000
    2001 : Corrective assignment fixes inventor name
    2008 : Patent issued to Microsoft Corp
    2014 : Transfer to Microsoft Tech Licensing LLC
    2020 : Patent expires

NPE / troll-pattern signals

1. Shell-entity transfer — not present. The only operating-company→LLC transfer is Microsoft Corp → Microsoft Technology Licensing, LLC (recorded 2014-12-09). MTL carries a "Licensing" suffix and holds no products, but the other shell tells fail: it is not a single-purpose third-party LLC, its address is One Microsoft Way (Redmond) — not a registered-agent service — and it is a wholly owned Microsoft subsidiary. This is an internal reorg, not a transfer to a shell.

2. Known asserter in the chain — not present. Neither assignee (Microsoft Corporation, Microsoft Technology Licensing LLC) appears on any of the cited NPE lists (Acacia, Marathon, Intellectual Ventures, IPNav, Wi-LAN, Mosaid/Conversant, Vringo, Pendrell, Innovatio, MPHJ, Round Rock, etc.). MTL is Microsoft's own licensing/litigation arm, not an unaffiliated NPE.

3. Repeat correspondent across the chain — unclear / not determinable. Only one post-issuance link exists (MSFT→MTL, 2014), so recurrence cannot be shown; and I could not open the '669 assignment abstracts to capture the correspondent-of-record. Family records suggest a single high-volume recording pipeline for all December-2014 Microsoft→MTL transfers (reels 034543, 034544, etc., all recorded 2014-12-09), but I am not attributing a name to '669 without the abstract. No finding.

4. Cascading transfers — not present. One ownership-changing assignment (2014) across ~14 years of post-issuance life; no chained LLCs.

5. Pre-litigation transfer — not present. No infringement suit naming US 7,444,669 was found in any source searched, so there is no assignment timed to precede one.

6. Bankruptcy fire-sale — not present. Microsoft has never filed Chapter 7/11; no proceeding appears in the chain.

7. Privateering — not present. The 2014 transfer is an internal reorg to Microsoft's own subsidiary, not a transfer to an unaffiliated NPE asserting on Microsoft's behalf. (MTL does litigate/license Microsoft's own patents — e.g., Kyocera — but that is the operating company asserting its own portfolio, not privateering.)

8. Defensive aggregator — not present. The chain does not terminate at RPX, AST, LOT Network, Unified Patents, or OIN. Note the patent is Expired – Fee Related (anticipated expiration 2020-05-05), so it has limited forward assertion value regardless.

Verdict

Operating-company assertion (closest fit in the required menu) — with an explicit caveat that no assertion of this specific patent was found, so on the narrower question "is this an NPE/troll chain?" the answer is no.

Justification: the entire recorded chain is (a) inventors → Microsoft Corporation, recorded 2000-10-10 (per cross-reference, reel 011172/0844), (b) a correction-only record on 2001-01-16 fixing the second inventor's name (no ownership change), and (c) an internal reorganization transfer, recorded 2014-12-09, from Microsoft Corporation to its wholly owned subsidiary Microsoft Technology Licensing, LLC. There is no third-party transfer, no NPE on any public asserter list, no cascading LLC chain, no bankruptcy sale, and the patent is expired (2020-05-05). This is a captive operating-company portfolio, not an NPE acquisition chain. The only residual "operating-company assertion" flavor is that the terminal assignee, MTL, is Microsoft's in-house licensing/litigation entity.

If you want the exact reel/frame, effective date, and correspondent for the 2014 MSFT→MTL record and the 2000 original, the abstracts must be pulled directly from Assignment Center by patent number (they are not exposed through the Google Patents/Espacenet records I could reach), or I can attempt to fetch the specific assignment PDFs if you authorize a second research pass.

I'll search for the specific prior-art citations on US 7,444,669. Let me run targeted queries.

Let me target the front-page "References Cited" table and the Unified Patents prior-art listing more precisely.

Important scope note before the analysis

Two limitations govern everything below, and I am flagging them rather than papering over them:

1. The claims of US 7,444,669 are not in the authoritative text you supplied. That text is truncated mid‑sentence in the Detailed Description ("…an individual may be traveling thro") and contains no claims. This is consistent with the earlier "Patent summary" section, which already flagged the missing claim set. Therefore I cannot perform a true 35 U.S.C. §102 element‑by‑element anticipation mapping, because §102 anticipation requires that a single reference disclose every element of an identified claim. Without the claim language there is nothing to compare elements against. What follows is a theme‑based candidate mapping, not a legal anticipation conclusion.

2. I could not query USPTO PatentCenter/PatFT natively in this session (no direct API access). The reference list below was surfaced from the Unified Patents patent page for US‑7444669‑B1 (https://portal.unifiedpatents.com/patents/patent/US-7444669-B1) and corroborated against Google Patents (https://patents.google.com/patent/US7444669B1/en). I must be candid that the Unified Patents page presents a document list that may be algorithmically generated "similar documents" rather than the literal front‑page "(56) References Cited" table; I could not retrieve the USPTO‑native front‑page citation table. Treat the list as the best available candidate set, pending front‑page verification.

A related caution on dates: the Unified Patents listings give what appear to be earliest priority dates, not publication dates. For §102(a)/(b)/(e) purposes the publication date and US filing date control, not the priority date. I have labeled dates accordingly rather than silently treating them as publication dates.

---

What the '669 patent is (for framing the references)

• US 7,444,669 B1, "Methods and systems for providing variable rates of service for accessing networks, methods and systems for accessing the internet"
• Inventors: Paramvir Bahl; Srinivasan Venkatachary; Anand Balachandran
• App. No. 09/566,168; filed 2000‑05‑05; granted 2008‑10‑28; expired (anticipated expiration 2020‑05‑05)
• Priority claim from U.S. App. Ser. No. 09/511,171 (filed 2000‑02‑22)
• On the USPTO's pre‑AIA framework applicable here, the critical prior‑art dates are: §102(b) = publications/patents before 1999‑05‑05 (one year before the US filing date); §102(e) = US patents/applications whose filing predates the applicant's invention date; §102(a) = prior knowledge/use/patenting by others before invention.

---

Candidate prior references with requested attributes

Claim groups (labels used because claim numbers are unavailable — see the caveat in §1):

• G‑A = offering/selecting "variable rates of service" (multiple service levels, differing bandwidth/security, user selection, pricing)
• G‑B = negotiating services with ISPs/service providers on the user's behalf
• G‑C = authentication to a network/Internet access (incl. independent of ISP/employer affiliation)
• G‑D = per‑user dynamic key generation / selectable key length / multiple encryption algorithms
• G‑E = accounting & billing for use (per packet/byte/time)
• G‑F = user‑based QoS / guaranteed bandwidth / scheduling ("go" signals, group arbitration)
• G‑G = dynamic compression tied to measured error thresholds
• G‑H = GUI feedback (bandwidth/cost selectors, real‑time data‑rate display)

Prior references

For references 1–5 and 7–26 I did not independently verify the assignee/title against the printed front page; they come from the Unified Patents listing and should be confirmed.

---

Preliminary §102 observations (with the standing caveat)

Given the claim language is unavailable, the most defensible statement is at the level of claim‑group themes, using the specification and title (which plainly emphasize "variable rates of service"):

• G‑A (variable rates/levels of service) is the group most likely to be the independent claim theme of the '669 patent (per its title). The strongest potential §102 candidates on that theme are US 5,802,502 (BT, pricing‑based connection selection) and US 6,363,150 (AT&T, multiple service/security levels with billing). Whether either anticipates depends entirely on whether the independent claim recites elements such as a mobile client on a host‑organization network selecting a service level and paying for it — an element these references may not supply in a single reference.
• G‑B (ISP negotiation) candidates: US 6,243,754 and US 6,145,002.
• G‑C (authentication for Internet access) candidates: US 5,898,780, US 6,145,002, US 6,338,140, US 6,546,392.
• G‑D (per‑user dynamic keys / selectable key length / multiple algorithms) candidates: US 6,094,486, US 5,199,069, US 5,341,426, US 5,455,863.
• G‑E (accounting/billing) candidates: US 5,625,690, US 6,363,150.
• G‑G (error‑threshold dynamic compression) candidates: US 5,138,616, US 6,477,669 (the Viasat FEC patent), US 7,190,284, US 6,339,450, US 5,701,302, US 6,021,198.

But I want to be explicit: I am not asserting that any reference anticipates any claim. Under §102, a reference anticipates only if it discloses all limitations of a claim, arranged as claimed. Several of the above references are, on their face, directed to individual components (encryption, compression, billing) rather than the integrated public‑venue, multi‑service‑level architecture that the '669 title/specification describes — which is precisely the kind of situation where anticipation fails and the analysis would shift to §103 obviousness. I therefore cannot responsibly name specific claim numbers as "anticipated."

Also note the two same‑family references (US 7,032,241 and US 7,085,924), which share inventors/applicant with '669: these are not available as prior art against '669 and should be excluded from any §102 chart.

---

Contradiction / consistency check against the earlier sections

• No contradiction with the earlier "Patent summary" and "Litigation summary" sections: both flagged that the claim text is absent, and this analysis reaches the same conclusion for the same reason.
• The earlier summary noted uncertainty whether the current assignee is Microsoft Technology Licensing LLC vs. an Intellectual‑Ventures‑linked entity surfacing on a third‑party portal. The Unified Patents page I relied on here lists Intellectual Ventures I LLC as the assignee of US 7,190,284 B1 (a cited reference), not of the '669 patent — so that IV hit is best explained as an artifact of listing a cited reference, not evidence that IV owns '669. This supports the earlier caveat rather than contradicting it.

---

Recommended verification steps (to convert the above into a defensible §102 chart)

1. Retrieve the actual claims of US 7,444,669 from USPTO PatentCenter (https://patentcenter.uspto.gov) or the granted‑PDF front matter, so a genuine element‑by‑element comparison is possible.
2. Obtain the literal "(56) References Cited" table from the printed patent (front page) or USPTO PatentCenter "References Cited" — to confirm whether the Unified Patents list above matches the examiner‑cited art, and to capture the examiner's cited publication dates (which control §102(b)/(e) status).
3. Resolve the two unverified entries (US 5,699,365 and the assignee/title for US 5,701,302).
4. For each confirmed reference, pull publication date vs. US filing date and apply the pre‑AIA §102(a)/(b)/(e) tests against the '669 filing (2000‑05‑05) and its 09/511,171 priority (2000‑02‑22).

If you can paste the claims portion of the patent text (or the USPTO PatentCenter claim listing), I will produce an exact, claim‑by‑claim §102 mapping with element comparisons rather than the theme‑level candidates above.

I'll first try to recover two things the prior sections flagged as missing: the actual claim language, and the prior-art references of record. Then I'll assess what can and cannot be grounded.

The prior-art section referenced in the task does not appear in the material provided to me, and the claims are still not in the text I have. Let me make one more attempt to recover claim language and to see the references of record before I write the analysis.

Let me make one final attempt to pull the actual patent-office citations (the "References Cited" block) so the analysis can be grounded in references of record rather than only my own identification.

Preliminary caveats — two required inputs are missing

Before the analysis, I have to be straight about the record, because it changes how much of this can be stated with confidence:

1. The "Prior Art section" referenced in the task was not supplied to me. Nothing in my working context contains a list of prior-art references for US 7,444,669 (no office-action citations, no IDS list, no third-party prior-art chart). I cannot "use the results" of a section I was not given. I flag this rather than pretend otherwise.

2. The claims are still not in the record. Consistent with the earlier sections of this analysis, the authoritative patent text ends mid‑sentence in the Detailed Description and does not include the Claims. I therefore cannot quote claim language, and any §103 analysis must be scoped to the title, abstract, and specification rather than to literal claim elements. That is a genuine limitation: obviousness is judged against "the subject matter as a whole" of each claim, and without claim text I can map prior art only to the disclosed features, not to claim limitations.

So what follows is a feature-by-feature §103 framework keyed to the specification, using candidate prior art that I identified independently (clearly labeled as such). Every reference below should be validated against the actual references of record and the actual claims before being relied on. Where I am not confident of a specific identifier, I say so.

---

1. Governing law and the level of ordinary skill

Statute. The '669 patent was filed 2000‑05‑05, claiming priority to Ser. No. 09/511,171 filed 2000‑02‑22. It is a pre‑AIA patent. Obviousness is therefore governed by pre‑AIA 35 U.S.C. § 103(a) and the Graham v. John Deere framework (scope/content of the prior art; differences; PHOSITA level; secondary considerations), as refined by KSR Int'l v. Teleflex (2007). The AIA's § 102/§ 103 provisions do not apply.

Critical dates for art:

PHOSITA (reconstructed). Given the field (public WLAN access, AAA, IP QoS), a person of ordinary skill would be an engineer with a B.S. in EE/CS and roughly 2–3 years of experience in IP networking and/or wireless LAN systems — familiar with IP, DHCP/DNS, RADIUS‑style AAA, IEEE 802.11, router QoS (WFQ/CBQ), and applied cryptography for session keys. Every reference below is either a standards document or an academic/commercial disclosure that such a person would have known or readily located.

Legal framework for the combinations. Under KSR and MPEP 2143, a combination is obvious where the prior art provides any articulated rationale, including: (A) combining known elements per known methods to yield predictable results; (B) simple substitution; (C) use of a known technique to improve a similar device in the same way; (D) applying a known technique to a known device ready for improvement; (E) "obvious to try" with a finite number of identified, predictable solutions; (F) market forces/design incentives; (G) predictable variation. An explicit teaching, suggestion, or motivation is not required.

---

2. Assumed claim scope (reconstructed, not read)

Because the claims are absent, I infer two independent-claim families from the title ("Methods and systems for providing variable rates of service for accessing networks, methods and systems for accessing the internet") and the abstract/spec:

• Family A — "variable rates of service": present a user (via an access point / intermediary server) with multiple service levels differing in bandwidth and/or security; receive a selection; enforce the selected rate (allocation, scheduling, encryption strength); optionally charge per the selected level.
• Family B — "accessing the internet": establish a wireless link to an access point; authenticate the user (optionally via a third‑party/global database in an end‑to‑end secure channel where the local server is not privy to credentials); issue a token/key used on subsequent packets; route packets through an intermediary PANS-type server.

I will treat the following specification features as the element set to attack: (1) hosting WLAN in public venues; (2) authentication via a global DB the local server cannot read; (3) per-user dynamically generated key of arbitrary/selectable length; (4) selection among multiple encryption algorithms; (5) negotiation with ISPs on the user's behalf; (6) user-based (vs. flow-based) QoS with premium per-user tier and group-arbitrated tiers; (7) accounting per packet/byte/time; (8) dynamic compression modulated by measured error rate; (9) GUI with bandwidth/price sliders and real-time rate feedback.

---

3. Candidate prior art (my identification; verify against the record)

These are references I identified from the field and era. They are not a reproduction of the patent's "Prior Art section," which I was not given. All dates predate the 2000‑02‑22 priority date unless noted.

Authentication / AAA / network access

• RADIUS — Rigney, Willens, Rubens, Simpson, Remote Authentication Dial In User Service, RFC 2058 (Jan 1997); updated RFC 2138 (Apr 1997). Per‑user authentication, authorization profiles, and accounting; centralized AAA server mediating network access.
• Mobile IP — Perkins, IP Mobility Support, RFC 2002 (Oct 1996). Foreign‑agent/home‑agent architecture; roaming across subnets.
• Kerberos V5 — Kohl & Neuman, RFC 1510 (Sep 1993). Authenticated principal receives a session key/ticket used to authenticate subsequent messages.
• IEEE 802.11 (1997) — WLAN MAC/PHY; open/closed authentication.

Cryptography / key management

• TLS 1.0 — Dierks & Allen, RFC 2246 (Jan 1999). Cipher‑suite negotiation (selection among a set of algorithms/lengths) over an untrusted channel; end‑to‑end confidentiality.
• IPsec/IKE — Kent & Atkinson, RFC 2401; Harkins & Carrel, RFC 2409 (Nov 1998). Negotiated keys; algorithm agility.
• Blaze, Diffie, Rivest, Schneier, Shimomura, Thompson, Wiener, Minimal Key Lengths for Symmetric Ciphers to Provide Adequate Commercial Security (1996). Variable‑key‑length vs. cost/security tradeoff.
• SSL‑secured web login / third‑party identity (public by 1999; e.g., Microsoft Passport, 1999 — the patent's own named embodiment).

QoS / scheduling

• Demers, Keshav, Shenker, Analysis and Simulation of a Fair Queueing Algorithm, SIGCOMM 1989 — the canonical flow‑based fair‑queueing reference.
• Parekh & Gallager, A Generalized Processor Sharing Approach…, IEEE/ACM ToN 1993.
• Floyd & Jacobson, Link‑sharing and Resource Management Models for Packet Networks, IEEE/ACM ToN 1995 — class‑based queueing (aggregating flows into classes).
• IEEE 802.1p (1998) / 802.1D — traffic‑class prioritization.
• DiffServ — Blake et al., RFC 2475 (Dec 1998); IntServ/RSVP — RFC 2210/2211/2212 (1997).

Compression

• Jacobson, Compressing TCP/IP Headers for Low‑Speed Serial Links, RFC 1144 (Feb 1990).
• ITU‑T V.42bis (1990) — adaptive data compression over error‑prone links.

Pricing / user‑selected service

• MacKie‑Mason & Varian, Pricing the Internet, in Public Access to the Internet (1995).
• Shenker, Clark, Estrin, Herzog, Pricing in Computer Networks: Reshaping the Research Agenda, ACM CCR 1996.
• Odlyzko, Paris Metro Pricing for the Internet, ACM EC 1999.
• Commercial hotspot portals (Wayport, MobileStar) — note: public‑use evidence may be needed; I have not verified specific deployment dates and flag them as unconfirmed.

---

4. Proposed § 103 grounds

Ground 1 — Variable rates/levels of service (Family A)

Combination: RADIUS (RFC 2058/2138) + a WLAN access architecture (802.11) + DiffServ/802.1p + per‑user bandwidth policing at the gateway.

• What each teaches: RADIUS discloses a centralized server holding per‑user policy profiles and doing accounting; 802.11 discloses wireless client‑to‑access‑point access; DiffServ/802.1p disclose assigning different forwarding treatment (bandwidth/priority) to different traffic.
• Motivation (rationale A + F): a POSITA implementing a public WLAN would combine a per‑user AAA profile with a per‑class bandwidth mechanism to give each user the service his profile specifies — using each element for its known purpose, with predictable results. Market forces (differentiated paid tiers in public hotspots) supply independent motivation.
• Strength: Strong as to "different service levels enforced per user." The accounting hook (billing per byte/packet) is squarely RADIUS accounting.

Ground 2 — User‑selectable QoS with price + real‑time feedback + GUI (Family A, GUI feature)

Combination: the pricing literature (MacKie‑Mason/Varian; Shenker et al.; Odlyzko) + IntServ/DiffServ or 802.1p + a web/HTML portal.

• What each teaches: the pricing papers expressly propose letting users choose among service classes and pay accordingly; DiffServ/802.1p provide the enforcement mechanism; web portals for login/self‑service were routine.
• Motivation (rationale A + G): the pricing references supply the idea of user‑selected paid tiers; putting a slider/selector GUI and a live rate readout on it is a predictable presentation of that idea using a known interface technique. Adding a network‑management‑style rate display (the kind used in SNMP/router consoles) is a routine design choice.
• Strength: Strong. The "bandwidth slider + price slider + live rate" feature set is the kind of predictable GUI/telemetry combination that KSR treats as obvious.

Ground 3 — Per‑user token + arbitrary‑length key + multiple algorithms (Family B security)

Combination: Kerberos (RFC 1510) + TLS 1.0 cipher‑suite negotiation (RFC 2246) + IPsec/IKE (RFC 2401/2409) + Blaze et al. (variable key lengths), optionally + RFC 2002.

• What each teaches: Kerberos discloses an authenticated principal receiving a unique session key used to authenticate subsequent messages (the functional heart of the "embedded token" idea). TLS/IKE disclose negotiating which algorithm/key parameters to use from a set. Blaze et al. discuss selecting key length as a security/cost tradeoff.
• Motivation (rationale A + B + C): an open wireless medium demands per‑session confidentiality. Using a freshly negotiated per‑session key for each user is the known technique in Kerberos/TLS/IKE; extending "negotiate the algorithm" (TLS/IKE) and "choose key length" (Blaze) to a wireless access server is applying known techniques to a known device ready for improvement, with predictable results. The patent's own stated advantage (per‑user keys avoid the shared‑key compromise of fixed‑key systems) is precisely the known benefit of session keys.
• Strength: Strong. Detaching the per‑user key from a statically assigned key and making it dynamically generated is a predictable improvement, and the "different users, different algorithm/length" idea is the ordinary TLS/IKE negotiation applied per client.

Ground 4 — End‑to‑end authentication the local server cannot read (Family B)

Combination: TLS/SSL (RFC 2246) + third‑party single‑sign‑on / identity‑provider model (public by 1999; e.g., Passport) + RADIUS.

• What each teaches: TLS gives an end‑to‑end confidential channel in which only the endpoints hold the plaintext; the identity‑provider model has the user authenticate to a remote authority while the local network merely facilitates.
• Motivation (rationale A + F): privacy/security concerns for public access — a POSITA would not want every hotspot operator to hold user credentials; routing the user to a trusted global authority over TLS is the known solution, with predictable results.
• Strength: Moderate‑to‑strong. The "PANS server is not privy to authentication information" feature reads as a natural application of TLS endpoints plus an SSO architecture.

Ground 5 — User‑based (vs. flow‑based) QoS with per‑user premium tier and group arbitration

Combination: Demers/Keshav/Shenker (fair queueing) + Floyd/Jacobson (class‑based queueing) + a centralized scheduler/polling MAC (e.g., an AP‑mediated "go"/polling scheme).

• What each teaches: fair queueing allocates bandwidth fairly across flows; class‑based queueing aggregates flows into classes and allocates per class; polling/central‑scheduler MACs (802.11 PCF; token‑passing schemes) let a central node grant transmission turns.
• Motivation (rationale A + C + F): the literature expressly identifies the problem the patent notes — a single user with many flows can monopolize bandwidth. Aggregating flows by user into a class (CBQ) to fix exactly that problem is applying a known technique to a known deficiency, with predictable results. The "go signal" is the known polling technique. Group arbitration among tier members is a predictable extension of class‑based allocation.
• Strength: Moderate‑to‑strong. This combination maps well, and the motivation is unusually clean because the prior art identifies the very problem the patent solves.

Ground 6 — Server negotiates service with third‑party ISPs on the user's behalf

Combination: roaming/brokerage architectures (GSM roaming clearinghouses; Mobile IP + AAA brokers, RFC 2002; RADIUS proxy/broker models, RFC 2138) + market forces.

• What each teaches: mobile networks already used intermediary brokers/clearinghouses to arrange service across providers; RADIUS can proxy authentication/authorization to third parties.
• Motivation (rationale D + F): automating a known business arrangement (a broker selecting a provider) via a server that queries several providers and picks the best fit is the classic "automation of a known activity" case — obvious where the automation uses known networking techniques and yields predictable results.
• Strength: Moderate. The strongest attack is that this is automation of a pre‑existing commercial process using known AAA/proxy machinery.

Ground 7 — Accounting per packet/byte/time

Combination: RADIUS accounting (RFC 2058/2138) + standard router counters/SNMP (RFC 1157/1757 era).

• Motivation (rationale A): RADIUS accounting already records session usage; counting at the gateway that all traffic transits is the known technique. Billing per packet/byte/time is a matter of unit choice.
• Strength: Strong.

Ground 8 — Dynamic compression modulated by measured error rate

Combination: V.42bis (1990) + RFC 1144 header compression + adaptive‑link/error‑control techniques (ARQ; modem link adaptation).

• What each teaches: V.42bis is an adaptive compression protocol over noisy links; RFC 1144 compresses headers; modems performed link adaptation based on error conditions.
• Motivation (rationale E + G): on a wireless link, error conditions vary (the patent itself cites line‑of‑sight obstruction). A POSITA facing data loss would try varying compression based on observed errors — a finite, identified approach with predictable effect. This is an "obvious to try" ground.
• Strength: Weakest / most contestable. The specific direction — reduce compression when errors rise — is arguably counterintuitive (one might expect more compression under bandwidth pressure). Absent a reference expressly teaching the inverse relationship between detected errors and compression amount, this feature is the best candidate for non‑obviousness, and would need a stronger primary reference (e.g., an explicit adaptive‑compression‑vs‑error‑rate teaching) to carry the ground.

---

5. Where obviousness is strongest vs. weakest

The single most defensible non‑obviousness argument for the '669 patent is the inverse error/compression relationship (Ground 8), because it is the one feature where the prior art's natural teaching points the other way. Everything else reads as a combination of known techniques producing predictable results under KSR.

---

6. Secondary considerations

There is no probative objective evidence available. The patent expired 2020‑05‑05, was never asserted in any identified litigation, and has never been the subject of an AIA proceeding (per the earlier PTAB section) — so there is no commercial‑success, licensing, copying, or long‑felt‑need record to weigh. Nothing here rebuts the § 103 case.

---

7. What you must verify before relying on any of this

1. Get the claims. This entire analysis is scoped to features, not claim limitations. Pull the granted claim set (Google Patents US7444669B1; USPTO PatentCenter, app 09/566,168) and re‑run the mapping claim‑by‑claim. Obviousness of a feature ≠ obviousness of a claim.
2. Get the actual "Prior Art section." The references I used are my own identification of the field. The references of record (the front‑page "References Cited" and any IDS/office‑action citations) are the ones the task asked me to use, and I did not have them.
3. Confirm dates for the commercial/prior‑use items (Wayport, MobileStar, Passport deployments). I listed them as unconfirmed; public‑use art requires actual‑date proof.
4. Confirm every specific identifier. I am confident in the standards (RFC 2058/2138, RFC 2002, RFC 1510, RFC 2246, RFC 2401/2409, RFC 1144, 802.11, 802.1p) and the named academic papers. I deliberately did not assert specific U.S. patent numbers for the cited technology because I could not verify them in this session — do not accept any patent number I did not give.

Bottom line: On the disclosed feature set, US 7,444,669 presents a strong‑to‑moderate §103 obviousness profile for the core "variable rates/levels of service over a public WLAN with per‑user AAA, key negotiation, user‑based QoS, and accounting" content — most of it is a straightforward KSR‑style combination of RADIUS, TLS/IPsec/Kerberos, DiffServ/802.1p and class‑based queueing, motivated by the ordinary demands of public wireless access and the prior art's own recognition of the multi‑flow monopoly problem. The error‑modulated compression feature is the one element that plausibly resists a clean obviousness showing on the art I identified. But because neither the claims nor the Prior Art section were provided, this is a framework for a §103 analysis, not a completed one.