US 6834341

I'll search for this patent across the requested sources.

Let me get the full claim set and check for any CAFC litigation activity.

Let me pull the full claim text and check for any litigation/CAFC history.

US Patent 6,834,341 B1 — Analyst Summary

Source note: I was able to retrieve the patent's authoritative full text from Google Patents (patents.google.com/patent/US6834341) plus claim text mirrored on Justia (patents.justia.com/patent/6834341). I could not access a live USPTO PatentCenter/PTAB docket or a Federal Circuit docket system directly from this session; no CAFC 2026 activity for this number surfaced in search. Uncertainty is flagged where it exists.

---

1. Bibliographic data

Family / continuations (per the Google Patents event log, all claiming priority to this filing): US 09/565,818 (→ US 8,255,569 B1); US 09/565,558 (→ US 7,032,241 B1); US 10/835,377 (→ US 7,313,237 B2); US 10/834,828 (→ US 7,548,976 B2); US 10/850,881 (→ US 7,406,707 B2); US 10/850,880 (→ US 2004/0221155 A1); US 10/850,715 (→ US 7,444,510 B2); US 10/961,920 (→ US 7,085,924 B2); US 10/974,191 (→ US 7,089,415 B2); US 11/390,592 (→ US 7,500,263 B2). Note: these are separate patents/applications, not the patent in question.

---

2. Abstract (verbatim)

"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."

---

3. Plain-language overview of the independent claims

Based on the claim text retrieved (Justia mirror), the patent has at least four independent claims — claims 1, 14, 23, and 34. The claim set runs to at least claim 34; I did not retrieve the total claim count or the full verbatim text of claims 1 and 34, so the descriptions below for those two are reconstructed from dependent-claim language and the specification and are marked as such.

Claim 1 — System claim (verbatim text not fully retrieved; reconstructed). An authentication system, comprising a host organization network; at least one authentication component; at least one authentication database; and at least one access module. Confirmed from dependents:

• Claim 4 (dep. on 3): "the one authentication component is configured to link a user directly to the authentication d[atabase]"
• Claim 11: the authentication database may be a locally accessible authentication database.
• Claim 12: the authentication component is configured to issue a unique token to each user once authenticated, the token being provided for use with data packets transmitted from each user.
• Claim 13: the access module is configured to enable the user to wirelessly access the host network.

⚠️ Plain-language reading: a system that authenticates a user into a host network and then hands them a per-user token used to tag their packets. The verbatim preamble/body of claim 1 was not retrieved.

Claim 14 — System claim (independent; full text retrieved). An authentication system for users who want Internet access, comprising:

• at least one host organization network, comprising one or more subnets, each subnet having (a) at least one server that receives data packets from individual client computing devices and transmits them to the Internet, and (b) a plurality of public access points that receive wireless communication from a user's client device and pass the packets to that server before they go to the Internet; and
• at least one globally accessible authentication database containing information usable to authenticate a user without requiring the user to be affiliated with a particular ISP.

Plain-language: a public Wi‑Fi-style network where all traffic is funneled through a gateway server, and a worldwide authentication database verifies users regardless of their ISP affiliation.

• Dependents: user authenticates directly with the global database (15); server is not privy to the authentication information (16); authentication is end-to-end secure (17), e.g. SSL (18); the database notifies the server when authentication succeeds (19) and may provide user information, including billing information (20–21); the user is unaffiliated with any ISP (22).

Claim 23 — System claim (independent; full text retrieved). An authentication system comprising:

• multiple wireless nodes through which the Internet can be accessed;
• multiple access points with which those nodes communicate;
• a server that receives wireless communication from the access points and enables authentication of users; and
• at least one global authentication database containing user information usable to authenticate users without requiring ISP affiliation.

Plain-language: the multi-node/multi-access-point version of the same idea — a wireless access network plus a global (ISP-independent) identity database.

• Dependents: user logs directly onto the global database (24); server presents a web page with a link to the database (25); server is not privy to the authentication information (26); the database notifies the server (27) and supplies user information (28); server issues a unique token (29), which it may encrypt before issuing (30); access points define a wireless subnet (31); access points are in a publicly accessible area (32); wireless nodes are mobile computing devices (33).

Claim 34 — Method claim (independent; text truncated in retrieval). "A method of authenticating a user for Internet access, the method comprising: establishing a communication link between a mobile computing device and a server…" The remaining steps were not retrieved; based on the specification they track the authentication flow of FIG. 4 (link → user interface → secure link to the global authentication database → authenticate → notify the server → generate/issue a token).

⚠️ Only the preamble and first step were recovered. The full step list of claim 34 (and any claims numbered above 34) is not available in what I retrieved.

---

4. Litigation / CAFC 2026 docket check

I found no Federal Circuit (CAFC) 2026 docket activity involving US 6,834,341. A targeted search for "6834341" combined with Federal Circuit / 2026 appeal terms returned no results. I therefore cannot report any 2026 appellate proceeding for this patent.

What did surface in connection with the number:

• A Microsoft IPR/patent-declaration filing (IETF IPR disclosure, dated per the page as 2005/2008, related to draft-tschofenig-pana-bootstrap-kerberos) listing 6947725; 6834341; 7089415 with dates 09/20/2005; 12/21/2004; 08/08/2006 — i.e., Microsoft disclosed this patent as relevant IPR in an IETF standards context.
• Numerous forward citations of US 6,834,341 in later patents and PCT/EPO search reports (e.g., KR100800353B1, JP2006507570A, US10313341, and various international search reports). These are citations, not litigation.

Caveat: absence of search hits is not affirmative proof that no 2026 CAFC matter exists (e.g., a case captioned only by party name or by the related family patent 7,033,241 / 7,085,924 / 7,089,415 could exist). To be certain, Docket Alarm, PACER, and the CAFC's own docket would need to be queried directly.

---

5. Confidence and uncertainty

• High confidence in the bibliographic fields, abstract, and the text of independent claims 14 and 23 (retrieved verbatim).
• Medium confidence in the reconstruction of claim 1 (built from claims 4, 11, 12, 13 — the exact claim 1 language was not retrieved).
• Low confidence / incomplete on claim 34's full step list, the total number of claims, and the contents of any claims above 34.
• No evidence found of CAFC 2026 activity for US 6,834,341; this is a negative search result, not a verified absence.
• Per the operating rules, I have interpreted the patent number and identifiers literally (e.g., noting the inventor surname is rendered "Venkatachary" on Google Patents) and have not auto-corrected them.

I'll search for litigation involving US patent 6834341 using the sources you specified.

Let me run additional targeted searches on litigation databases.

Litigation Search Report — U.S. Patent No. 6,834,341

Patent identified: U.S. Patent No. 6,834,341 B1 ("'341 patent")

• Title: Authentication methods and systems for accessing networks, authentication methods and systems for accessing the internet
• Inventors: Paramvir Bahl, Srinivasan Venkatachary, Anand Balachandran
• Original Assignee: [Microsoft Corp.](/litigations/by-plaintiff/Microsoft%20Corp.); Current assignee: Microsoft Technology Licensing LLC
• Filing/Priority: February 22, 2000; Granted: December 21, 2004
• Application No.: 09/511,171

---

Result: No litigation located for U.S. Patent No. 6,834,341

Based on searches of patent-litigation resources (Unified Patents portal, CourtListener/RECAP, docket-oriented indexes, and general litigation coverage), I found no district court lawsuits, no Court of Appeals for the Federal Circuit appeals, and no PTAB proceedings (IPR/PGR/CBM) involving U.S. Patent No. 6,834,341.

Because no case exists, I cannot provide plaintiff(s), defendant(s), jurisdiction, case number, filing date, or outcome — there are none to report on the record located.

---

What the searches did return (and why each is not litigation on the '341 patent)

Per your instruction to interpret identifiers literally and not auto-correct, here is everything keyed to the number "6834341," with an explanation of why it is not a litigation hit:

1. JP 6834341 B2 — Japanese Patent No. 6834341 (Dai Nippon Printing Co., Ltd.; "液体吐出容器、及び組み合わせ体" / liquid-discharge container). This is an unrelated Japanese patent that merely shares the numeral 6834341. It is not the U.S. patent and involves no U.S. litigation.

2. IETF IPR Disclosure (datatracker.ietf.org/ipr/2914) — A Microsoft statement about IP (IPR) related to RFC 5296 and RFC 6696, listing U.S. patents 6834341, 7085924, and 7089415. This is an IETF standards-body patent-disclosure filing, not litigation. Note: 7,085,924 and 7,089,415 are Microsoft continuations/relatives in the same family as the '341 patent — so this disclosure confirms the '341 patent's family was disclosed to the IETF, but it is not a lawsuit or PTAB challenge.

3. Unified Patents patent-information page (US-6021198-A) and other PTAB filings that cite patents of similar number (e.g., 6,289,434; 8,064,434; 8,338,683) — these concern different patents (different numbers), and none assert or challenge the '341 patent.

4. Trademark/registry hits (e.g., CT liquor-control listing "6834341 CANDonI," a Chinese trademark opposition involving registration no. 6834341, and a Lithuanian registry notice) — unrelated non-patent records.

I did not find the '341 patent on any district-court asserted-patent list, in any Unified Patents litigation case list, or in any PACER/RECAP docket.

---

Important caveats and limitations

• I was unable to complete direct, live queries against the Unified Patents litigation caselist and PACER in this session (the tools returned limited/blocked results). My conclusion rests on the search results I could retrieve, which were consistent across multiple queries.
• This is not a legal-clearance or freedom-to-operate opinion, and it is not a certification that no litigation exists. A definitive negative requires a direct PACER docket search, a Docket Alarm / Lex Machina / Unified Patents portal query, and confirmation from the assignee (Microsoft Technology Licensing LLC).
• As a general matter, the '341 patent family (including continuations such as 7,085,924 and 7,089,415) is Microsoft-owned. Microsoft patents of this type were commonly encountered in litigation as defendant/counterclaim patents rather than as NPE assertion patents, which is consistent with the absence of an assertion campaign around the '341 patent. That observation is contextual, not a factual litigation finding.

Bottom line: On the evidence located, no litigation is known involving U.S. Patent No. 6,834,341. If you need a court-certified negative, the next step is a direct PACER/RECAP and Unified Patents portal pull, which I recommend before relying on this for any formal purpose.

I'll source the canonical proceedings list from the structured ODP block, then verify against web sources for anything the ODP may not have indexed.

Let me run a couple of targeted checks for any litigation or PTAB activity involving this patent and its family.

Proceedings overview

There are no AIA trial proceedings on file for US 6,834,341 — zero IPRs, zero PGRs, and zero CBMs. The structured USPTO ODP "PTAB proceedings on file" block returns no AIA trials, and independent web searches for PTAB activity on this patent (and on its continuation-family siblings, e.g. US 7,085,924 and US 7,089,415) surfaced nothing beyond the patent being cited as prior art inside other parties' proceedings. There is consequently no proceeding to walk through claim-by-claim, no FWD, no settlement, and no CAFC appeal to report. The defensive posture is therefore not "the patent has been hardened by surviving IPRs" — there is simply no PTAB track record either way.

No proceeding to report

Per your constraint ("If no PTAB activity exists, say so plainly"), I am not going to fabricate a proceeding number or manufacture an outcome in order to fill the template. Specifically:

• No IPR / PGR / CBM docket exists for US 6,834,341 in the ODP ingest or in public PTAB/E2E materials I could locate.
• Searches surfaced the '341 patent only as a cited reference (e.g., it appears as a cited Microsoft reference in the family of KR100800353B1, and US 6,834,341 / US 7,085,924 / US 7,089,415 appear in IEEE 802.11ai Letter-of-Assurance correspondence). Being cited in someone else's paper is not a PTAB proceeding against this patent, and I am flagging it only so it isn't mistaken for one.
• USPTO PTAB E2E is the authoritative place to confirm: https://ptacts.uspto.gov/ptacts/ (search by patent number 6834341).

Structured-data status: the ODP record reflects "no AIA trial proceedings." That is the canonical answer.

Strategic summary

Claim-by-claim status: every claim is UNTESTED at the PTAB. There is no claim of US 6,834,341 that has been canceled, and none that has been confirmed in an FWD. Any statement that "claims 1–5 are dead" or that "the patent survived two IPRs" would be false here — neither has happened. Because there is no FWD, there is also no § 315(e)(2) estoppel attaching to anyone: no petitioner is barred from raising any ground, because no petitioner has appeared.

The more consequential fact for a defendant is not PTAB-related at all: the patent's term has expired. US 6,834,341 issued from an application filed 2000-02-22 and was granted 2004-12-21; Google Patents lists "Anticipated expiration 2020-02-22," i.e., 20 years from the earliest effective filing date with no apparent patent-term adjustment. If that holds (confirm against the face of the patent and any PTA certificate), the patent cannot be infringed today by ongoing conduct, and any residual exposure is limited to pre-2020-02-22 damages — themselves subject to the six-year recovery bar of 35 U.S.C. § 286. A demand letter asserting this patent against current products has a serious temporal problem regardless of invalidity.

Why so quiet? This is a Microsoft-originated, individual-centric wireless-authentication patent (the "PANS server" / Policy Manager architecture). It sits in a thick continuation family (US 7,032,241; US 7,315,237; US 7,406,707; US 7,444,510; US 7,548,976; US 8,255,569; and the 7,085,924 / 7,089,415 reissues of the challenge-handling line), which historically made it unattractive as a standalone assertion target and explains the absence of both litigation-driven IPRs and defensive-aggregator (Unified Patents, RPX) challenges. The absence of any IPR is a signal that no one has found it worth asserting — the opposite of the "well-asserted patents eventually attract IPRs" pattern.

Recommended next steps

• Treat "no PTAB activity" as the established baseline. Before doing anything else, confirm on PTAB E2E (https://ptacts.uspto.gov/ptacts/) and via the ODP API that no petition was filed after the last ingest. If a fresh petition exists, it will show up there and in the ODP delta feed first.
• Lead with the expiration/section 286 argument, not invalidity. If you are receiving a demand citing US 6,834,341, the dispositive question is whether the asserted acts occurred before the ~2020-02-22 expiration and within six years of suit. Pull the patent's face, any PTA certificate, and the maintenance-fee history to nail this down (the ODP legal-status field shows "Expired – Lifetime").
• Check the IEEE LOA provenance if standards practice is implicated. The '341 patent and its siblings appear in IEEE 802.11ai Letter-of-Assurance correspondence. If the demanded product practices 802.11ai (EAP re-authentication), determine whether a Microsoft assurance/commitment encumbers the patent and whether any successor (Microsoft Technology Licensing) is bound — that can transform the analysis from invalidity to licensing/FRAND posture. I could not verify from the search results that a binding RAND commitment was executed, so treat this as a lead to confirm, not a conclusion.
• Do not assert an estoppel defense. With no FWD, there is no § 315(e)(2) estoppel to leverage and no canceled claims to point a court to. Any invalidity theory you run would be a first-instance challenge — in district court (clear-and-convincing, § 282 presumption) rather than before the Board.
• Recheck before relying on this. Because the ODP ingest lags and the patent expired in 2020, a late-filed IPR is legally impossible now (no claim can be challenged after expiration for prospective relief, and the § 315(b) / standing posture is degraded), so I would not expect the picture to change.

I'll research this patent's assignment record using the sources available.

Let me dig deeper into the assignment records and any litigation history.

Let me try to pin down the specific reel/frame numbers for this patent.

Ownership reconstruction — US 6,834,341 B1

Patent. "Authentication methods and systems for accessing networks, authentication methods and systems for accessing the internet." Application 09/511,171, filed 2000-02-22, granted 2004-12-21. Legal status per Google Patents: Expired – Lifetime, anticipated expiration 2020-02-22.

Verification links: USPTO Assignment Center · Google Patents legal events for US 6834341 · USPTO PatentCenter

Scope note before you read further. The record for this patent is short: two recorded events over 20 years. I was able to confirm the identity, parties and dates of both, but not the corresponding correspondence/correspondent block for either, and not the exact reel/frame for the 2014 recording on this patent specifically. Where I lack data I say so rather than filling it in. No litigation naming this patent surfaced in the sources I could reach.

Inventors

Pattern notes: the three inventors are the Microsoft Research team behind the "PANS" (Protocol for Authentication and Negotiation of Services) work, and all three appear as assignors on the same 2000-05-08 recording — i.e. a clean, single-shot employee-invention assignment to the employer, the normal case.

I found no evidence of the "inventors depart within 12 months of filing" precursor pattern: no re-assignment of this patent back to any inventor was recorded, and no inventor-name assignment to a third party appears in the chain. I could not verify individual departure dates with high confidence, so treat that as an absence of evidence rather than proof of continuity.

Original assignee

Microsoft Corporation (Redmond, WA) — the entity named on the issued patent and confirmed by the 2000-05-08 recorded assignment of assignors' interest, and again by the 2014 INPADOC/Google legal-event entry showing Microsoft Corporation as assignor to Microsoft Technology Licensing, LLC.

• Line of business: global software, services and hardware operating company (Windows, Office, Azure, Xbox and related).
• Did they ship a product embodying the claims? The claimed subject matter — a network-side authentication/negotiation server brokering user authentication, per-user keys, QoS levels and accounting, with client-side supplicant behavior — maps to Microsoft's Wi-Fi/802.1X supplicant and network-access-control stack in Windows. I could not verify with high confidence which specific shipping product embodies these exact claims, and I am not going to assert one; the closest firm statement is that the assignee is an operating company with products in the relevant technical space.
• Current status: operating. The patent itself now sits with Microsoft Technology Licensing, LLC, a wholly-owned Microsoft subsidiary (see below).

Assignment timeline

2000-02-22 (executed) / recorded 2000-05-08 — Reel/frame: not exposed in the sources I could reach

• Conveyance: Assignment of assignors' interest ("ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS)")
• Assignor: Bahl, Paramvir; Venkatachary, Srinivasan; Balachandran, Anand
• Assignee: Microsoft Corporation
• Correspondent: not retrievable from the sources I accessed — this is a data gap, not an absence. A single appearance would not be a finding under your rule regardless.
• Context: initial employee-invention assignment to the employer, executed the same day the application was filed.

2014-10-14 (effective) / recorded 2014-12-09 — Reel 034543/xxxx or 034544/xxxx (exact frame for '341 not confirmed)

• Conveyance: Assignment (AS)
• Assignor: Microsoft Corporation
• Assignee: Microsoft Technology Licensing, LLC (Redmond, WA)
• Correspondent: not retrievable from the sources I accessed.
• Context: internal corporate reorganization — this is the 2014 carve-out in which Microsoft moved its entire patent estate into a wholly-owned licensing subsidiary. The recording was a bulk sweep: sibling Microsoft patents resolved in the same event carry reel/frame 034543/0001 and 034544/0541, with effective date 2014-10-14 and recordal 2014-12-09. I located those reel/frame cites for sibling/related Microsoft patents, not for US 6,834,341 itself, so I am not attributing a specific frame to this patent.

Nothing else is recorded. No security agreement, no license recordal, no release, no correction, no change of name, no transfer to any third-party licensing entity.

Timeline diagram

timeline
    title Ownership of US 6834341
    2000 : Inventors assign to Microsoft Corp
    2004 : Patent issued 21 Dec 2004
    2014 : Reorg to Microsoft Tech Licensing LLC
    2020 : Patent expired 22 Feb 2020

NPE / troll-pattern signals

1. Shell-entity transfer — not present.
There is a transfer to a "…Licensing, LLC" in 2014 (recorded 2014-12-09, effective 2014-10-14), which is the trigger phrase. But the substance fails the test: the transferee is a wholly-owned subsidiary of the assignor operating company, the transfer swept Microsoft's entire portfolio in one bulk recording (sibling reel cites 034543/0001 and 034544/0541), and there is no registered-agent-service address, no single-purpose standalone LLC created to hold this patent, and no products-in-commerce gap (the parent ships products in this space). Naming alone is not a finding; the corroborating evidence points the other way.

2. Known asserter in the chain — not present.
Neither Microsoft Corporation nor Microsoft Technology Licensing, LLC matches the public NPE lists you enumerated (Acacia, Marathon, Intellectual Ventures, IPNav, Wi-LAN, Mosaid/Conversant, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, Document Generation Corp, Spangenberg entities). Neither appears in the chain as a purchaser from or seller to any such entity. Note for completeness: IV has historically acquired some Microsoft-origin assets, but no IV (or other listed asserter) link to US 6,834,341 appears in the record.

3. Repeat correspondent across the chain — unclear / not determinable.
I could not retrieve the correspondent of record for either of the two recordings. Two recordings by the same corporate assignor would in any event be a weak signal. No finding — but flag this as the one measurement you'd want to close out directly in Assignment Center, which exposes the correspondent field that the aggregator sources I reached do not.

4. Cascading transfers — not present.
Two recorded events, 14 years and 10 months apart. No chained LLCs, no shared correspondent address, no sub-24-month sequence.

5. Pre-litigation transfer — not present.
The last recorded transfer is 2014-12-09. I found no infringement suit naming US 6,834,341 in the sources I could reach, so there is no "assignment within 6 months before first suit" event to evaluate. (The only litigation-adjacent hit was this patent's appearance inside a prior-art/search string in a Fortinet IPR exhibit and a Microsoft IETF IPR disclosure — neither is an assertion of this patent. See below.)

6. Bankruptcy fire-sale — not present.
No Chapter 7/11, no trustee sale, no SEC-reported asset sale involving this patent. Microsoft never filed.

7. Privateering — not present.
The chain terminates inside the original operating company's own corporate family, not at an arm's-length NPE funded to assert against Microsoft's competitors. MTL is Microsoft's disclosed patent-holding affiliate; there is no third-party NPE in the chain at any point.

8. Defensive aggregator — not present.
The chain does not terminate at RPX, AST, LOT Network, Unified Patents or OIN. No defensive neutralization event exists to find.

Adjacent facts worth recording (not NPE signals).

• Microsoft disclosed US 6,834,341, together with US 7,085,924 and US 7,089,415, in an IETF IPR disclosure relating to RFC 5296 and RFC 6696 (Microsoft Corporation's IPR statement, datatracker entry ipr/2914). This is a standards-body disclosure, the opposite of a secret-troll posture — the owner put the patent on the record where implementers could find it.
• The '341 patent is the head of a substantial Microsoft-controlled family (continuations/companions including US 7,032,241; US 7,085,924; US 7,089,415; US 7,313,237; US 7,406,707; US 7,444,510; US 7,548,976; US 7,500,263; US 8,255,569). All remain in the Microsoft family; the whole family moved in the same 2014 reorganization.
• The patent expired 2020-02-22 on the 20-year term and is recorded "Expired – Lifetime" — i.e. it was not abandoned for fee non-payment, and it can no longer be asserted by anyone.

Verdict

Operating-company assertion.

Justification: the record contains exactly two events — the inventors' 2000-05-08 assignment to Microsoft Corporation, and a 2014-12-09 bulk internal reorganization to Microsoft Technology Licensing, LLC (effective 2014-10-14; sibling reel cites 034543/0001 and 034544/0541). There is no shell-entity transfer to an arm's-length licensing vehicle, no listed asserter anywhere in the chain, no cascading LLC transfers and no pre-litigation transfer; every NPE signal in your list reads not present, and the only "Licensing, LLC" name in the chain is a wholly-owned subsidiary of the original operating assignee. Two caveats I am stating rather than burying: (a) I did not locate an infringement suit naming this patent, so the "assertion" prong of this verdict is unproven for the specific patent — the verdict rests on the owner being an operating company rather than an NPE; and (b) the patent expired 2020-02-22, so it is effectively non-asserting today regardless. If your taxonomy wants a stricter label, the honest fallback is "Insufficient data" on the assertion question only — the ownership chain itself is complete and is not an NPE chain.

I'll search for the prior-art references cited on US 6,834,341's face and examine prosecution history.

Prior-Art Analysis — US 6,834,341 B1

Important methodological caveat (read first)

The task asks me to "look at each patent citation for 6834341" and map each reference to the claim(s) it anticipates. I was unable to retrieve the authoritative front-page "References Cited" list (the U.S. patent documents, foreign documents, and non-patent publications cited by the examiner) for US 6,834,341 in this session. My searches repeatedly returned (a) the patent's own description/specification text, (b) forward citations (later patents that cite '341), and (c) unrelated documents that merely share the numeral "6834341" (e.g., Japanese Patent No. 6834341 B2, Dai Nippon Printing, a liquid-discharge container — an entirely different patent). The tool hit its step limit before I could pull the (56) References Cited block from the patent images/PDF or from a bibliographic mirror.

Per my operating rules, I will not fabricate a list of cited references or invent § 102 mappings. Below I separate (1) what I could confirm, (2) what the '341 specification itself treats as prior art (which is citable), and (3) a rigorous § 102 framework keyed to the actual claim elements — so that each reference can be slotted in once the (56) block is obtained.

---

1. What the searches confirmed (and why it is not prior art on '341)

These are "cited-by" / forward citations — patents that cite '341 — not prior art that '341 cites:

These tell us the '341 family was disclosed to the IETF as standards-relevant IP, and that later patents build on it — they are not § 102 art against '341. (This is consistent with the earlier-generated Litigation section, which separately found no district-court or PTAB activity on '341.)

⚠️ Flagged contradiction: the earlier-generated sections said they "did not retrieve the total claim count" and reconstructed claim 1. Nothing in today's search resolves that gap; the claim-count limitation still stands.

---

2. Prior art that is affirmatively identifiable — the specification's own admitted background

Even without the (56) block, the '341 specification itself describes and distinguishes prior-art systems. Under 35 U.S.C. § 102 such statements, if relied upon as "applicant-admitted prior art," can be cited against the claims. The admitted art is:

1. ISP-tied wired Internet access — account with an ISP, modem/special line, ISP-provided browser software ("an individual's Internet access is either tied to their wired link provider, or to the ISP").
2. Employer/corporate-network access — "Internet access is tied to their employer and/or their employer's resources."
3. Wide-area cellular / 3G data networks — "current wide-area data networks (e.g. which use a Ricochet modem from Metricom) support transmission rates that are about 50 Kbps"; 3G "up to around 2 Mbps per cell."
4. WLAN systems — "transmission rates are as high as 11 Mbps today … expected to go up to around 54 Mbps."
5. Fixed-key encryption systems — "other network systems that utilize a fixed number of keys for a variable number of users … four or five keys that are allocated for use among numerous different users" (the specific thing claim 12 / 29–30's per-user dynamic token improves over).
6. Proxy-based authentication — "systems that authenticate a user by serving as a proxy for the user" (the specific thing claims 16 / 26's "not privy to" element improves over).
7. Flow-based QoS scheduling — "flow-based scheduling … streams of packets or 'flows' … a router typically evaluates the flows … and then attempts to allocate a fair share of the bandwidth among the different flows" (the specific thing claims on user-based scheduling improve over).

§ 102 relevance: items 5, 6, and 7 are the most probative, because each maps to an express claim element. If the examiner cited a reference (or the applicant conceded this art), it would most plausibly be mapped as follows (subject to verification once the (56) block is obtained):

• Admitted fixed-key/shared-key art → potential § 102 challenge to the token/key limitations in claims 12, 29, and 30 (though those claims add "unique … token" and "encrypt" limitations the admitted art lacks).
• Admitted proxy-authentication art → potential § 102 challenge to claims 15, 16, 24, 26 (direct-login / server-not-privy), which were added specifically to distinguish it.
• Admitted ISP-tied access art → potential § 102 challenge to claim 14's / 22's "without requiring the user to be affiliated with a particular ISP" element.

---

3. § 102 framework mapped to the independent claims (for slotting each reference in)

Because the claim set runs to at least claim 34 with independents 1, 14, 23, and 34, any cited reference must be evaluated against these four. The critical § 102 datum for each is the reference's publication date vs. the 2000-02-22 priority date — a reference cannot anticipate under § 102(a)/(b) unless its public availability predates that date (with § 102(e) unavailable against a patent whose filing date is the same).

Claim 14 (system): needs (i) host network with a subnet, (ii) a server that receives client packets and transmits to the Internet, (iii) a plurality of public access points passing wireless traffic to that server before it reaches the Internet, and (iv) a globally accessible authentication database that authenticates without ISP affiliation. A § 102 reference would have to disclose all four — most public hot-spot/gateway art of the late 1990s supplies (i)–(iii) but typically fails on the ISP-independence of (iv).

Claim 23 (system): multiple wireless nodes + multiple access points + server enabling authentication + global authentication database usable without ISP affiliation. A reference disclosing a wireless ISP network with a carrier-tied AAA server would fail the ISP-independence element (dependent claim 22 expressly recites "unaffiliated with any ISP").

Claim 1 (system): per the earlier-generated section, reconstructed from dependents — host network + authentication component + authentication database + access module, with (claim 12) issuance of a unique token to each user, and (claim 13) wireless access. A § 102 reference would need the per-user token element, not merely shared-key encryption.

Claim 34 (method): preamble "establishing a communication link between a mobile computing device and a server"; rest of the steps were not retrieved (still unresolved), but per the FIG. 4 flow they track: display UI → establish secure link to global authentication database → authenticate → notify server → generate/issue token.

---

4. Bottom line

• I could not verify the examiner-cited prior art for US 6,834,341. I will not present an unverified reference list as if it were the patent's (56) citations.
• What the record does confirm is the forward-citation landscape (US 9,542,560; US 7,707,427; and the IETF/IPR and IEEE 802.11ai disclosures listing 6834341, 7085924, 7089415) — useful for showing the patent's influence, not for § 102.
• The only anticipation-ready material I can identify with confidence is the specification's own admitted background (ISP-tied access; employer access; Metricom/Ricochet and 3G WANs; 11/54 Mbps WLANs; fixed-key encryption; proxy authentication; flow-based QoS) — the last three being the most probative against the token, "server not privy," and user-based-scheduling claim elements respectively.

To complete this task properly, the next step is to pull the verbatim (56) References Cited block from the US 6,834,341 front page (USPTO PatentCenter "References Cited," the Google Patents "References Cited" table, or the patentimages PDF), plus the full text of claims 1 and 34. Once that list is in hand, each reference can be dated against the 2000-02-22 priority date and slotted into the § 102 framework in Section 3 element-by-element. I recommend treating this response as a framework, not a finished anticipation opinion.

I'll research the prior art cited on this patent's page and related references before building the § 103 analysis.

Let me pull the actual cited references and family IDS lists from the patent's own page and mirrors.

Obviousness Analysis — U.S. Patent No. 6,834,341 B1 under 35 U.S.C. § 103

Critical date: February 22, 2000 (filing/priority). Pre‑AIA § 103(a) governs. Art must qualify under pre‑AIA § 102(a)/(b)/(e)/(f) or be an admissible printed publication.

---

0. Provenance caveat — read this first

You asked me to use "the results from the Prior Art section of this page." I need to be straight with you about what I could and could not retrieve:

1. The authoritative full text supplied for US 6,834,341 was truncated — it ends mid‑sentence in the Detailed Description ("The PANS Authorizer 302b authenticates users just as described abov…"). The Google Patents page's "Patent Citations," "Referenced By," and "Similar Documents" tables were not captured in that fetch. So I do not have the '341 patent's own front‑page 56‑reference list.
2. My searches keyed to "6834341" returned mostly forward citations — later documents that cite the '341 patent (e.g., US 2003/0033375 A1, US 6,931,597 B1, US 2012/0204028 A1, US 7,787,863 B2, US 8,484,695 B2, US 9,740,846 B2, US 7,084,734 B2). These are not § 102/103 prior art against '341, because they all post‑date 2000‑02‑22. I will not mischaracterize them as prior art.
3. What did surface and is genuinely useful: (a) the IETF IPR disclosures listing 6834341 alongside its family members 7,085,924 and 7,089,415; (b) the appearance of US 5,708,780 (Levergood) in the reference lists of documents in this same art space; and (c) several pre‑2000 RFCs and standards that are the actual state of the art here.

Accordingly, the grounds below are built from (i) art that surfaced in connection with this patent number/family and (ii) the well‑documented Feb‑2000 state of the art that a POSITA would have known. I flag confidence explicitly. If you can paste the actual "References Cited" table from the '341 front page, I will re‑anchor every ground to those specific references.

⚠️ Contradiction to flag between the previously generated sections: the "Patent summary" section describes an IETF IPR disclosure related to draft‑tschofenig‑pana‑bootstrap‑kerberos (that is IPR #930), while the "Litigation summary" section describes IPR #2914 relating to RFC 5296 / RFC 6696. These are two different Microsoft IPR filings, not the same one. Both list 6834341. Minor, but worth correcting in the record.

---

1. What the claims require (built on the prior sections)

Per the previously generated summary (which I treat as authoritative for cross‑reference), the independent claims are 1, 14, 23, and 34. The limitations that actually drive obviousness are:

Everything else in the patent — QoS tiers, group arbitration, accounting, dynamic compression, the GUI — lives in dependent claims or the specification, and is analyzed separately in § 6–7 below.

---

2. The relevant prior‑art landscape as of Feb 2000

Tier A — art that surfaced in searching this patent/family (higher confidence these are of record or closely related):

Tier B — the documented state of the art a POSITA would have known (I have high confidence these documents exist and say what I attribute to them):

---

3. Ground I — Claims 1, 13, 14, 23, 31, 32, 33

Combination: Levergood '780 + 802.11 (1997/1999) + RADIUS RFC 2138.

• Levergood '780 supplies: a host/access‑control network wrapping a gateway server; interception of client packets; a separate authentication function; and monitoring/accounting — i.e., every structural element of claim 14(a) and claim 1 except the wireless and global‑database aspects.
• IEEE 802.11 supplies: a plurality of access points constituting a wireless subnet that hands traffic to the infrastructure before it reaches the wider network, with seamless roaming inside the subnet (claims 31–33; "publicly accessible area" is inherent in a WLAN deployed in a mall/airport, and the '341 spec concedes APs/wireless protocols are conventional).
• RADIUS supplies: the gateway‑as‑NAS separate from the authenticator, which is the backbone of claims 1 and 14.

Motivation (KSR‑compliant): all three are in the same field of "controlling access to a packet network"; a POSITA seeking to extend an existing web access‑control gateway to a public wireless deployment would predictably substitute an 802.11 access‑point subnet for the wired access path, and would predictably use the standard AAA protocol (RADIUS) already used by every ISP dial‑up NAS of the era. KSR rationales: (a) known technique (wireless LAN) in the same field; (b) simple substitution of one access medium for another; (c) market pressure to move Internet access into airports/malls (a pressure the '341 patent itself identifies as the problem to be solved).

---

4. Ground II — Claims 14, 15, 16, 17, 18, 19, 20, 21, 22, 24, 25, 26, 27, 28, and 34

Combination: Ground I + RFC 2607/RFC 2477 roaming brokers (or Passport) + SSL/TLS + Kerberos.

• The "globally accessible authentication database… without requiring ISP affiliation" element (claims 14, 22, 23) is met by roaming‑broker / clearinghouse art (RFC 2607, RFC 2477) and by Microsoft's own Passport, which the specification itself names as the global database. A POSITA building an airport hotspot in 1999 would self‑evidently look to a roaming clearinghouse precisely so that a traveler is not tied to one ISP.
• "Direct" authentication (15, 24) and "server is not privy" (16, 26): Kerberos V5 has taught since 1993 that a client can authenticate to a KDC and then present a ticket to a service that never sees the credential. SSL/TLS supplies the "only the database can decrypt" feature the spec describes (steps 404–406).
• "End‑to‑end secure / SSL" (17, 18): TLS RFC 2246 / SSL 3.0 — verbatim.
• "Database notifies the server of authentication" (19, 27): RADIUS Access‑Accept (the AAA server's success signal to the NAS) and Kerberos service tickets both disclose the authenticator‑notifies‑the‑gateway pattern.
• "User information, including billing information" (20, 21, 28): RADIUS Accounting (RFC 2139) + the notion of a clearinghouse supplying remittance data — squarely within the '341 spec's own description of the global DB providing credit‑card/billing data.
• "Web page with a hyperlink to the database" (25): Levergood's redirect‑to‑login‑URL mechanism, and the Nomadix‑style captive portal.
• Method claim 34: the flowchart of FIG. 4 (link → UI → secure link to global DB → authenticate → notify server → issue token) is a straight recitation of Levergood + RADIUS + SSL; the "mobile computing device" framing adds only 802.11.

Motivation: a POSITA would combine these because (i) they are all in the same art of network AAA; (ii) using a broker/global identity provider was the recognized solution to the very problem the patent states (access not tied to an employer or a single ISP); (iii) the incremental technical step — pointing the login page at a remote, SSL‑protected authentication service instead of a local one — is a predictable variation with no change in the underlying operation.

---

5. Ground III — Claims 12, 29, 30 (per‑user token/key, encrypted)

Combination: Levergood '780 or Kerberos/RADIUS + SSL/TLS.

• Levergood's session identifier appended to subsequent requests ≈ the claimed "unique token used to identify the user in subsequent data packet transmissions."
• Kerberos V5 (RFC 1510) discloses a unique per‑principal session key/ticket — and the '341 spec's own statement that this is an improvement over "a fixed number of keys for a variable number of users" concedes that key‑per‑user issuance is the natural design.
• RFC 2865 (RADIUS) / RFC 2138 discloses per‑session attributes (Class, Session‑Key) that the NAS can use to identify/secure a session.
• Claim 30 (encrypt the token before issuing): SSL/TLS transport of the token — the '341 spec itself says the key is transported "using secure transport protocols, e.g. https."

Motivation: issuing a distinct credential per session and delivering it over the session's secure channel is the ordinary, expected design choice; KSR's "use a known technique to improve similar devices in the same way."

---

6. Ground IV — QoS and accounting claims (dependent)

• Per‑user bandwidth guarantees, group/class‑based allocation, arbitration, and "go" signals: RSVP/IntServ, WFQ/class‑based queueing (Floyd & Jacobson 1995), and packet‑scheduling literature.
• ⚠️ This is the patent's strongest non‑obviousness position — and the examiner's best 103 target. The specification deliberately frames "user‑based scheduling" as an improvement over "flow‑based" scheduling (WFQ). Because the '341 spec admits flow‑based scheduling is prior art, the claimed delta reduces to choosing the granularity of the scheduling entity (per‑user vs. per‑flow). Under KSR, that is arguably a predictable design choice — but a patent owner can argue there is a teaching away in the art's uniform emphasis on flows and that the change produces the unexpected result of eliminating flow‑hogging. This is contestable both ways.
• Accounting (per‑packet / per‑byte / per‑time billing): RADIUS Accounting (RFC 2139), and ordinary ISP usage billing — very strong art; these claims are the most vulnerable.

---

7. Ground V — Dynamic compression claims (dependent)

• RFC 1144 and RFC 2507 (header compression for error‑prone, low‑bandwidth links), plus the general practice of lowering compression aggressiveness when the channel degrades (V.42bis / modem‑negotiated compression). The '341 feature — reduce compression as the measured error rate rises — is a straightforward application of a known trade‑off (compressed data is more fragile; damaged compressed packets waste more bandwidth).
• Motivation: the trade‑off was well known; the patent's own FIG. 11 table (error bucket → compression %) is a routine engineering lookup table. Expect this to be found obvious.

---

8. The overarching KSR motivation narrative

For each ground, the record supports multiple independent rationales:

1. Same field / reasonably pertinent. All references address AAA, wireless access, or QoS in packet networks.
2. Known techniques. SSL, Kerberos, RADIUS, 802.11, RSVP/WFQ, DHCP/NAT were all standard by Feb 2000 — the '341 spec repeatedly calls them "known" and "not discussed further."
3. Simple substitution / predictable variation. Wired→wireless access; local auth DB→global auth DB; local login→redirect to remote SSL login; fixed key set→per‑user key.
4. Market pressure / design incentive. The specification itself states the demand-driven problem (public‑place Internet access, ISP independence). A problem the applicant characterizes as an unmet market need is not itself an inventive contribution.
5. Applicant's own admissions (MPEP 2145). The '341 spec concedes: flow‑based scheduling and fixed key pools are prior art; Passport is the global DB; APs, SSL, DHCP and NAT are conventional. These admissions supply much of the motivation.

---

9. Where the '341 patent can plausibly resist § 103

• Claim 14 / 22 / 23's "without requiring the user to be affiliated with a particular ISP," combined with the gateway‑mediated packet path. If the cited roaming‑broker art (RFC 2607‑type) is used only for dial roaming and does not teach interposing an access‑controlled gateway over a wireless access‑point subnet with remotely authenticated users, the owner can argue the specific combination was not suggested. This is the claim family's best defense.
• Token‑based enforcement at the gateway (claims 12, 29, 30) combined with the "server is not privy" feature. Kerberos covers the concept, but not obviously the packet‑tagging‑with‑the‑session‑token‑at‑a‑hotspot‑gateway implementation. A Token/Browser‑cookie + captive‑portal reference is what the examiner would need.
• No secondary‑considerations record surfaced in the material reviewed (no commercial‑success, licensing, or copying evidence tied to these claims was located). I did not find any litigation or PTAB record for '341 (consistent with the earlier "Litigation summary"), so there is no written record of how these claims fared against art in an adversarial proceeding.

---

10. Conclusions and confidence

Bottom line: On the state of the art as of February 2000, the independent claims are highly vulnerable under § 103. The gateway‑plus‑remote‑authentication architecture (Levergood + RADIUS + Kerberos), deployed over an 802.11 public access‑point subnet (IEEE 802.11), with a global roaming/identity provider and SSL, is a combination a POSITA would have been motivated to make — and the specification's own admissions supply the motivation. The only claim family with a genuine non‑obviousness argument is the user‑based (as opposed to flow‑based) QoS scheduling in the dependents, and even that is contestable under KSR.

Confidence: high on the legal framework, the RFC/standards art, and the motivation analysis; medium on the specific identity/scope of the '341 patent's own cited references, because the "References Cited" table was not captured in the text I was given. Please supply that table and I will re‑run every ground against the actual references of record rather than the reconstructed art base above.