US 8041815

I'll search for authoritative information on US patent 8041815.

Let me run more targeted searches to check for any litigation or CAFC activity.

Summary of US Patent 8,041,815

Important note on scope of my searches: I searched for this specific number (in both 8041815 and 8,041,815 forms) and for litigation/CAFC-related activity. The only authoritative record retrieved was the patent document itself (Google Patents, US8041815B2, fetched per the source header). I found no search results tying this patent to a Court of Appeals for the Federal Circuit docket or to any 2025–2026 litigation, and I did not retrieve a USPTO PatentCenter/assignment record beyond what the patent page itself reproduces. I therefore cannot confirm or deny pending litigation or a CAFC appeal; treat that as unverified, not as a negative finding. The bibliographic and claim data below come from the patent text supplied to me, which I treat as authoritative.

Bibliographic data

Abstract (as published)

Systems and methods are described for managing network connectivity for mobile users, particularly when a mobile user roams between two networks or between two subnets of a network. An announcer signal is broadcast by a host organization. The announcer signal includes a network identifier, an authorizer address and a verifier address. A mobile client monitors for the announcer signal and, when detected, provides an option to connect to the network via the authorizer. Once authorization is obtained, the mobile client communicates with the network through the verifier. The verifier receives tagged data packets from a mobile client and only accepts the data packets if a valid tag (created with an authorization key) is included therewith. Multiple verifiers may be used to provide load balancing and fault tolerance (in the event a verifier fails). If a mobile client disconnects from a network and later reconnects, the mobile client does not have to be re-authorized if the mobile client still has a valid authorization key.

Independent claims in plain language

Claim 1 — Method for broadcasting an announcement signal (broadcast side).
The method broadcasts three things over a computer network: (a) a network identifier signal that uniquely identifies the network; (b) an authorizer signal giving the network address of an authorizer that is configured to authorize mobile clients to use the network; and (c) a verifier signal giving the network address of a verifier that is configured to verify data packets sent by mobile clients using the network. The core idea: separate the "who may get in" function (authorizer) from the "is this packet allowed through" function (verifier), and advertise both addresses in the beacon.

Claim 8 — System.
A system comprising a computer network, a computing device configured as an authorizer, a computing device configured as a verifier, and a signal generator that generates at least one signal containing: the network-identifying signal, the authorizer address signal, and the verifier address signal — the same three-part advertisement as claim 1, expressed as an apparatus/system. (Note: the claim text as published contains a duplicated phrase, "identifies a verifier signal that identifies a verifier network address," which is a typographical artifact in the claim as printed.)

Claim 15 — Computer-readable storage medium.
A non-transitory-style computer-readable storage medium storing instructions that direct one or more computers to perform the same three broadcasting operations recited in claim 1 — i.e., the method of claim 1 implemented as software/instructions.

Dependent-claim coverage (for context)

• Claims 2–7 (depend from 1): periodic broadcasting (2); the three signals broadcast together as one announcer signal (3); authorizer/verifier addresses as IP addresses (4); substituting an alternate verifier for a preferred verifier (5); substitution triggered by a verifier load threshold (6); substitution triggered by detected preferred-verifier failure (7).
• Claims 9–14 (depend from 8): mirror claims 2–7 in system form.
• Claims 16–21 (depend from 15): mirror claims 2–7 in storage-medium form.

Notable drafting point: The load-balancing and fault-tolerance concepts discussed at length in the specification (FIGS. 7–9) appear in the claims only as the "substituting an alternate verifier address" limitations (claims 5–7, 12–14, 19–21). The roaming/private-vs-public network settings and the "reuse a still-valid authorization key on reconnect" features described in the specification (FIGS. 10–11) do not appear in any of the 21 issued claims — they reside in the abandoned divisional US 11/072,039 / US 2005/0149764 A1.

Caveats

• Issue date: the publication date listed on the patent page is 2011-10-18; this is roughly seven and a half years after the 2003 pre-grant publication, which suggests a long prosecution. The page does not explain the delay, and I have not verified the intervening prosecution history.
• "Adjusted expiration 2029-01-06": this is a computed terminal-disclaimer/PTA-style figure shown by the patent page. It reflects the page's own calculation and the status disclaimer that "the legal status is an assumption and is not a legal conclusion." Do not rely on it as a formal determination.
• Litigation/CAFC: as stated above, my searches surfaced nothing on point. I cannot confirm the existence of any 2026 CAFC docket involving this patent; absence of a hit in my searches is not proof that none exists.

Primary source: https://patents.google.com/patent/US8041815/en (Google Patents, US8041815B2, fetched 2026-09-30 per source header). Related family member: US 2005/0149764 A1.

I'll research litigation involving US Patent 8041815.

Litigation search results for U.S. Patent No. 8,041,815

Bottom line: I found no litigation — district court, Federal Circuit, or PTAB — specifically involving U.S. Patent No. 8,041,815. I want to be explicit that this is a "no results found" outcome, not a verified negative, and explain the limits below.

What I searched

• Keyword searches combining the patent number in both formats (8041815 / 8,041,815) with "litigation," "lawsuit," "infringement," "case," and "defendant."
• Searches pairing the patent's subject matter/title ("managing network connectivity for mobile users") and inventors (Bahl; Miu) with litigation terms.
• Searches against patent-litigation aggregators and court sources, including Unified Patents' portal (portal.unifiedpatents.com/litigation/caselist), CourtListener/RECAP, Docket Alarm, and CAFC opinion PDFs.

None of these returned a docket, complaint, judgment, or PTAB proceeding identifying US 8,041,815 as an asserted or challenged patent. The related-patent and citation tables on the Google Patents page for this patent list nothing under a "litigation" heading, and the family shows only a divisional application (US 11/072,039, abandoned) — no assertion history in the family data.

Patent context (for orientation)

Important caveats

1. Absence of results is not proof of absence. After issuance in 2011, this patent (a Microsoft networking patent with a 2029 adjusted expiration) could have been asserted in a case that predates or falls outside the aggregators' free coverage, or in a docket where the patent number is not indexed by the free search tools.
2. I could not access the Unified Patents litigation portal, PACER, or Lex Machina directly with the tools available here. Those are the authoritative sources and should be checked directly — PACER/RECAP for district court dockets, the Unified Patents litigation caselist, and the CAFC docket search for any appeal naming this patent.
3. Watch for number confusion. US 8,041,815 is easily confused with other 8,04x,xxx and 8,041,8xx patents. I did not find any other patent's cases that could be misattributed here, but a definitive answer requires searching by patent number within each database rather than by keyword.

Recommended verification steps for a definitive answer

• Search PACER's Patent Docket Report / Patent Litigation Docket by patent number 8,041,815.
• Search the Unified Patents litigation caselist and their patent page for US 8,041,815.
• Search PTAB (ptacts.uspto.gov) for IPR/PGR/CBM petitions against 8,041,815.
• Search the CAFC docket for appeals referencing 8,041,815.
• Check Lex Machina, Docket Alarm, or RPX/Insight for any assertion activity tied to the patent or to Microsoft Technology Licensing as plaintiff.

If you'd like, I can attempt additional targeted searches (e.g., by assignee "Microsoft Technology Licensing" as plaintiff combined with the patent number) or draft a PACER/Unified Patents query set for a paralegal to run.

I'll start by verifying whether any AIA trial proceedings exist for this patent, since the structured ODP block reports none.

No results there. Let me try a few more targeted queries to be thorough.

No PTAB hit so far. Note one search surfaced a different patent (8,041,805, OpinionLab) — that's not this patent. Let me run a couple more checks specifically tying the '815 patent to any challenge.

PTAB / AIA Trial Landscape — U.S. Patent No. 8,041,815

Patent: Systems and methods for managing network connectivity for mobile users — Bahl & Miu; app. 09/960,258, filed 2001-09-21; granted 2011-10-18; current assignee Microsoft Technology Licensing LLC; adjusted expiration 2029-01-06.

Proceedings overview

The structured USPTO ODP block for this patent reports zero (0) AIA trial proceedings — no IPRs, no PGRs, no CBMs — and web searches surface nothing that contradicts that: the patent has never been the subject of a PTAB trial, so there are no claims canceled, no claims sustained, no settlements, and no Federal Circuit appeals. Bottom line for a defendant: this is not a "hardened-by-IPR" patent and it is not a "claims-already-killed" patent either — it is a procedurally untested patent, which cuts both ways (no free invalidations to cite, but also no confirmed validity and no petitioner estoppel constraining your side). ⚠️ Caveat: absence of indexed proceedings is not proof of absence; a very recently filed petition (within weeks) may not yet appear in ODP. Verify directly at PTAB E2E before relying on the null result.

---

Proceeding-by-proceeding

None on file. There are no proceeding numbers to enumerate, and I will not invent any. For completeness, the "for each proceeding" subsections below are intentionally empty.

No proceedings identified

No IPR / PGR / CBM docket numbers exist for U.S. 8,041,815 in the structured ODP data or in search results. Consequently there is no judge panel, no petition ground, no institution decision, no Final Written Decision, no settlement, and no Rule 36 / merits appeal to report.

Disambiguation flag (important — do not conflate)

One search result referenced PTAB activity around U.S. Patent No. 8,041,805 (Qualtrics v. OpinionLab, CBM denying institution, reported ~2016-04-13). That is a completely different patent — a market-research/website-feedback patent owned by OpinionLab, not Microsoft's '815 networking patent. Per the operating rule to read identifiers literally, I am not treating '805 as '815 or vice versa. Any research memo that merges these two is wrong.

---

Strategic summary

1) Claim status: all 21 claims are UNTESTED. The patent has 21 claims across three independent claim families — method (claim 1), system (claim 8), and CRM/computer-readable-medium (claim 15) — with dependent claims covering periodic broadcast (2, 9, 16), combined "announcer signal" broadcast (3, 10, 17), IP addresses (4, 11, 18), and verifier substitution for load balancing (6, 13, 20) and verifier-failure failover (7, 14, 21). None of these claims has ever been construed by the PTAB, none has been canceled, and none has been adjudicated valid. There is therefore no "surviving claim set" narrowed by post-grant review to point to — the full claim 1–21 set remains live and enforceable on paper. Note the file-history wrinkle: a divisional, US 11/072,039 (pub. US 2005/0149764 A1, filed 2005-03-04), went abandoned, so the live enforcement vehicle is the '815 patent itself.

2) Estoppel landscape: essentially none exists. Because no IPR/PGR/CBM was ever instituted against this patent, no § 315(e)(2) estoppel attaches to anyone. For a defendant being accused today, that is favorable on the invalidity side: every prior-art ground — § 102 anticipation, § 103 obviousness, § 112 written-description/enablement/indefiniteness — remains fully available in district court and, if you are still inside the § 315(b) one-year window from service of the complaint, available in a fresh IPR you would file yourself. There is no prior petitioner whose grounds you inherit or are boxed out of, and no institution decision fixing claim scope against you.

3) Pattern signals: the patent simply hasn't been a litigation target. The absence of any IPR/PGR/CBM over a patent that has been enforceable since 2011 (and whose family dates to 2001) is itself informative. Well-asserted patents in the crowded 802.11/Wi-Fi connectivity space almost inevitably attract invalidity challenges — so the null PTAB docket suggests the '815 patent has not been aggressively asserted in a way that provoked (or justified the cost of) an AIA petition. There is no evidence of a defensive aggregator (no Unified Patents–style filer), no repeat petitioner, and no patent-owner appeal pattern to infer. Treat this as a low-signal, quiet patent rather than one that has been repeatedly stress-tested.

---

Recommended next steps

• If you are a defendant: you get no free invalidations, but you also inherit zero estoppel. Assume the full claim set 1–21 is live. The most attackable subject matter, if the patent is asserted on load-balancing or failover functionality, sits in dependent claims 5–7 / 12–14 / 19–21 (verifier substitution on load threshold or verifier failure) — these depend on the separate "preferred/alternate verifier" architecture and are worth scrutinizing against 2001-era prior art on server load balancing and failover (note the patent itself cites Sun DHCP/packet-filter art of the 1996–1999 era).
• Before relying on "no PTAB activity": independently confirm via USPTO PTAB E2E (https://ptacts.uspto.gov) and the patent's ODP record, in case a petition was filed within the last several weeks and hasn't propagated to the structured feed. Also check the sibling application US 2005/0149764 A1 for any challenge history.
• Timing if you elect to file your own IPR: the § 315(b) one-year clock runs from service of an infringement complaint. If a complaint issues, calendar the one-year bar immediately, and monitor the statutory 1-year-from-institution deadline for any FWD (35 U.S.C. § 316(a)(11)) once trial is instituted.
• If you are the patent owner / licensor: your strength is a clean, never-challenged claim set with a 2029 adjusted expiration; your weakness is that you have no PTAB-confirmed validity to brandish and no narrowing history to moot a competitor's attacks. Expect invalidity to be litigated from scratch if you assert.

---

Confidence and limitations: The "no PTAB proceedings" conclusion rests on the structured ODP block (stated as no AIA trials) plus search results, which surfaced no '815-specific petition, institution decision, FWD, or appeal. I could not retrieve a PTAB E2E docket directly within this session. I have not fabricated any proceeding numbers, panels, dates, or dispositions; where information does not exist, I have said so explicitly. The one apparent "hit" (U.S. 8,041,805, Qualtrics/OpinionLab) is a different patent and is flagged as such, not reported as activity on this patent.

I'll research the assignment record for US 8041815 before constructing the analysis.

Let me dig deeper for the specific reel/frame records for US 8041815.

I've gathered enough from the patent's own legal-events record and corroborating assignment/INPADOC sources. One note up front: I could confirm the event structure and assignees but not retrieve the exact reel/frame for this patent number from the sources I could reach, so I flag that explicitly rather than invent it.

---

Inventors

Unusual-pattern check: Not present. The typical fire-sale precursor — all inventors exiting the original assignee within ~12 months of filing — does not appear here. Both inventors are tied to a deep-pocketed operating company (Microsoft) and the patent later moved only within the Microsoft corporate family. No inventor-side signal of an orphaned, unsupported portfolio.

(Caveat: the "Microsoft Research" employer attribution is inferred from the assignee of record being Microsoft Corporation and the inventors' well-documented roles; I did not independently re-verify each employment badge for 2001.)

---

Original assignee

• Entity on the issued patent: Microsoft Corporation, One Microsoft Way, Redmond, Washington 98052.
• Primary line of business: Software / platforms / cloud — a large, diversified operating company, not a licensing vehicle.
• Product embodying the claims: Unclear-to-partial. The patent's architecture (a broadcast announcer signal carrying network + authorizer + verifier addresses; a verifier enforcing per-packet tags) tracks Microsoft's late-1990s/early-2000s wireless-networking research (the Microsoft Research "CHOICE"-era public wireless work) and Microsoft's Windows XP–era wireless stack. I can state the assignee is an operating company that shipped wireless networking software in this era, but I cannot confirm a specific commercial product that practices all independent claims from the sources I reached.
• Current status: Operating. The patent remains live (Google Patents shows status Active, adjusted expiration 2029-01-06) and has been parked in Microsoft's wholly-owned licensing subsidiary (below).

---

Assignment timeline

I located two transfer events. The exact reel/frame for US 8041815 itself was not retrievable from the sources I could reach; I am therefore not assigning reel numbers I cannot verify. What is verifiable is the assignor/assignee pair and dates from the patent's own legal-events record.

• 2002-07-09 (recorded) — Reel/frame not confirmed from available sources

  • Conveyance: Assignment (of assignors' interest)
  • Assignor: BAHL, PARAMVIR; MIU, ALLEN K.L. (the two named inventors)
  • Assignee: MICROSOFT CORPORATION, One Microsoft Way, Redmond, Washington 98052
  • Correspondent: Not determined from my sources (would require the Assignment Center abstract-of-title page).
  • Context: Standard inventor-to-employer assignment of rights; the initial vesting of title in the operating company.

• 2014-10-14 (executed) / 2014-12-09 (recorded) — Reel/frame not confirmed for US 8041815 (this was part of a bulk Microsoft→MTL transfer recorded under a series of reels in the ~0345xx range; adjacent Microsoft patents in the same transfer appear at, e.g., reel 034543/0001 and 034541/0477)

  • Conveyance: Assignment
  • Assignor: MICROSOFT CORPORATION
  • Assignee: MICROSOFT TECHNOLOGY LICENSING, LLC, One Microsoft Way, Redmond, Washington 98052
  • Correspondent: CPA Global Limited, Liberation House, Castle Street, St Helier, JE1 1BL, Jersey (the IP-management/annuity firm of record on Microsoft's 2014 bulk reassignment to MTL). This correspondent recurs across the entire Microsoft→MTL transfer — thousands of patents — which is the signature of a corporate portfolio reorg handled by a centralized IP-services vendor, not of an NPE lawyer running shell LLCs.
  • Context: Internal corporate reorganization / change of beneficial ownership vehicle — Microsoft consolidated patent ownership into its wholly-owned subsidiary Microsoft Technology Licensing, LLC. Effective date corroborated by INPADOC ("EFFECTIVE DATE: 20141014") and by the EPO/UK register language for the same deed ("deed of assignment dated 14.10.2014"). Not a sale to a third party.

If Assignment Center returns additional records for this number (e.g., a security interest or a later transfer), they were not recoverable in my sources and should be pulled directly. As the record stands, there is no post-issuance transfer to any entity outside the Microsoft corporate family.

---

Timeline diagram

timeline
    title Ownership of US 8041815
    2001 : Application filed by Microsoft
    2002 : Inventors assign rights to Microsoft Corporation
    2011 : Patent issued as US 8041815
    2014 : Transferred to Microsoft Technology Licensing LLC
         : Wholly owned Microsoft subsidiary

---

NPE / troll-pattern signals

1. Shell-entity transfer — not present. The only post-issuance move is to Microsoft Technology Licensing, LLC, whose recorded address is One Microsoft Way, Redmond, WA 98052 — Microsoft's own headquarters, not a registered-agent service address. Although "Licensing" appears in the name, MTL is a wholly-owned operating-company subsidiary, and the 2014-12-09 recording (correspondent CPA Global Limited) swept in thousands of Microsoft patents as a single portfolio reorganization. Name suffix alone is not a finding; there is no single-purpose shell indicia (no registered-agent address, no unrelated principals, no product-less Delaware/Texas LLC).

2. Known asserter in the chain — not present. Neither Microsoft Corporation nor Microsoft Technology Licensing, LLC matches the NPE lists cited (Acacia, Marathon, IV, Wi-LAN/Conversant, Mosaid, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, Spangenberg entities, etc.). MTL licenses but is not an NPE — it is held inside an operating company.

3. Repeat correspondent across the chain — not present (as an NPE tell). CPA Global Limited appears as correspondent on the 2014-12-09 recording, and it recurs across the entire Microsoft→MTL bulk transfer. I flag it because recurrence is exactly what the rubric asks me to capture — but the recurrence is a bulk-corporate-reorg artifact (a portfolio-maintenance vendor acting for one industrial client), not the "one lawyer running many unrelated shell LLCs" pattern. No NPE-assertion-list correspondent (Unified Patents / RPX / Patent Progress) appears on this chain.

4. Cascading transfers — not present. There is a single post-issuance transfer, roughly 13 years after filing. No chain of consecutive LLCs within <24 months; no shared-principal / shared-correspondent cascade.

5. Pre-litigation transfer — not present. I found no infringement suit naming US 8041815, and the only assignment predates any hypothetical suit by more than a decade. Nothing indicates the chain was arranged to establish standing or venue.

6. Bankruptcy fire-sale — not present. No Chapter 7/11 of the original assignee; Microsoft has not been in bankruptcy.

7. Privateering — not present. No transfer to an NPE asserting on an operating company's behalf; the 2014 move stayed inside the Microsoft family.

8. Defensive aggregator (anti-NPE) — not present. The chain does not terminate at RPX, AST, LOT, Unified Patents, or OIN. MTL is not a defensive aggregator; it is a monetization/licensing arm, but of the original operating company itself.

---

Verdict

Insufficient data — and I want to be precise about why, because this is not a data gap so much as a substantive non-NPE finding. The record contains only the original inventor→Microsoft assignment (recorded 2002-07-09) plus a 2014-12-09 intra-corporate transfer to Microsoft Technology Licensing, LLC (executed 2014-10-14; effective date corroborated by INPADOC and the EPO register). No third-party sale, no litigation, no NPE assignee, no pre-litigation timing, no cascading shells. Under the rubric this collapses to "the original corporate family still owns the patent," which is captured by Insufficient data; it is emphatically not an NPE chain.

Verification link: search the patent number at the USPTO Assignment Center — https://assignment.uspto.gov/patent/index.html (same records as https://assignmentcenter.uspto.gov/ ) — and cross-check the legal events on https://patents.google.com/patent/[US8041815B2](/patent/US8041815B2)/en .

Two honesty caveats, stated plainly:

• I could not confirm the exact reel/frame for US 8041815's two recordings. The MTL recording sits in the ~0345xx reel series (adjacent Microsoft patents in that bulk deed appear at 034541/0477 and 034543/0001), but I will not assert a specific reel/frame for this patent without the abstract-of-title page.
• The 2002 assignment's correspondent of record was not determinable from my sources and should be read off the Assignment Center abstract directly.

I'll search for the specific patent and each cited reference to verify the citation data and assess relevance.

Let me verify several more cited references, including the "family cites" entry and other key prior art.

Prior-Art Analysis — US Patent 8,041,815 B2

1. USPTO / database search result for the specific number

I searched the literal strings 8041815 and US8041815 (and the grant form). The record retrieved matches the patent under analysis and no other number:

• US 8,041,815 B2 — "Systems and methods for managing network connectivity for mobile users"; Application US 09/960,258; filed/priority 2001-09-21; inventors Paramvir Bahl and Allen K. L. Miu; original assignee Microsoft Corporation; current assignee Microsoft Technology Licensing, LLC; granted 2011-10-18; pre-grant publication US 2003/0061363 A1 (2003-03-27). Source: https://patents.google.com/patent/US8041815/en (US8041815B2, fetched 2026-09-30 per source header); corroborated by uspto.report/patent/grant/8041815.

The patent page lists 18 "Patent Citations" and 2 "Family Cites Families" entries. That is the citation set analyzed below.

2. Two important caveats before the per-reference mapping

(a) What the citation list does and does not tell us. The "Citations (18)" list on the patent page is the face-of-patent/specification reference list. It does not state which reference was applied against which claim during prosecution. I did not retrieve the file wrapper/Office Actions for US 09/960,258. Therefore the "potentially anticipates under § 102" mapping below is my own analysis of subject-matter overlap, not a record of actual USPTO rejections — treat it as analytical, not evidentiary.

(b) § 102 vs. § 103. Anticipation under § 102 requires a single reference disclosing every element of a claim. Independent claims 1, 8, and 15 each require broadcasting all three signals together — a network-identifying signal and an authorizer address and a verifier address. None of the 18 cited references, on the descriptions available, discloses that full three-part advertisement in one document. Accordingly, the realistic § 102 exposure sits mainly in the dependent claims (notably claims 5–7 / 12–14 / 19–21, the "alternate verifier" substitution limitations), while the bulk of the list is § 103 (obviousness) material for the independent claims. I flag this rather than overstate anticipation.

(c) Data-anomaly flag (contradiction in the record). One entry in the citation list — US 6,864,341 B2 (Bausch & Lomb, "High refractive index aromatic-based prepolymer precursors") — has a priority date of 2001-11-02, i.e., after the '815 priority date of 2001-09-21, and is technologically unrelated (ophthalmic lens polymers). Interpreted literally, it cannot be § 102 prior art and is not technically pertinent. Similarly, EP 0 519 563 A3 ("System for converting synchronous time-division-multiplex signals into asynchronous time-division data packets," Koninklijke Philips, pub. 1997) is background switching/transport art. I do not auto-correct these entries; I report them as listed and flag their apparent irrelevance.

3. Reference-by-reference analysis

Tier 1 — Closest to the claimed subject matter (authorizer/verifier separation; packet verification)

Tier 2 — Authorization, address assignment, and mobility infrastructure

Tier 3 — Wireless/mobile addressing background art

Tier 4 — Apparent non-prior-art / background entries

4. Bottom line — most relevant prior art

Ranked closest-to-furthest from the issued claims:

1. US 6,833,434 B1 (Microsoft) — same-family/same-inventor-lineage reference that discloses the authorizer-plus-token-gated-verifier model; the single most on-point item (though it is a "Family Cites Families" entry, i.e., same-assignee, not third-party art).
2. US 7,185,360 B1 (Hereuare) — clearest third-party disclosure of the authentication-vs-access-control split that underlies the "authorizer" and "verifier" roles in claims 1/8/15.
3. US 6,163,843 (Toshiba) — closest to the "verifier that verifies data packets sent by mobile clients" limitation.
4. US 5,848,233 (Sun/Radia) — dynamic, login-then-user packet-filter assignment, closely aligned with the verification/failover mechanisms.
5. US 6,877,104 (NEC Infrontia) — most relevant to the fault-tolerance dependent claims 7/14/21.

Nature of the exposure. Because each independent claim requires the combined broadcast of network-ID + authorizer address + verifier address, no single cited reference appears to wholly anticipate claims 1, 8, or 15; those stand or fall more on § 103 combinations (e.g., Hereuare or Microsoft '434 in view of Toshiba '843 and/or Sun '233). The dependent claims carrying the load-balancing / alternate-verifier substitution limitations (5–7, 12–14, 19–21) carry the greatest § 102/§ 103 risk, with NEC '104 (fault recovery) and Sun '233 (filter reconfiguration) the most pertinent.

5. Limitations of this analysis (stated explicitly)

• I did not retrieve the prosecution file wrapper or any Office Action for US 09/960,258, so I cannot tell you which references the examiner actually applied and to which claims. The mapping above is subject-matter analysis, not a rejection record.
• I completed searches confirming bibliographic/claim detail for US 7,185,360, US 6,163,843, US 5,848,233, and the family-cited US 6,833,434; I hit a tool-call limit before individually re-verifying the remaining cited references against live sources, so for those the dates/descriptions above rely on the authoritative patent text supplied in the record (the "Citations (18)" and "Family Cites Families" lists) rather than independently re-fetched pages. Where a live source and the patent text could disagree, the patent text was treated as authoritative per the operating rules.
• No litigation or CAFC activity for this patent surfaced in my searches; absence of a hit is not proof that none exists.

Primary source: https://patents.google.com/patent/US8041815/en (US8041815B2). Supporting: https://patents.google.com/patent/US7185360 ; https://patents.google.com/patent/[US6163843A](/patent/US6163843A) ; https://patents.google.com/patent/US5848233 ; https://patents.google.com/patent/[US6834341](/patent/US6834341) ; https://uspto.report/patent/grant/8041815 ; https://portal.unifiedpatents.com/patents/patent/US-[7185360](/patent/7185360)-B1 ; https://portal.unifiedpatents.com/patents/patent/US-[6163843](/patent/6163843)-A.

I'll research the key prior-art references from the patent's citations section to ground the obviousness analysis.

Let me pull details on the Sun Microsystems references and the Siemens/AT&T mobility references.

Obviousness Analysis — U.S. Patent No. 8,041,815 under 35 U.S.C. § 103

Patent: US 8,041,815 B2, "Systems and methods for managing network connectivity for mobile users" (app. 09/960,258; filed & priority 2001‑09‑21; issued 2011‑10‑18).
Source of record: https://patents.google.com/patent/US8041815/en
Prior art considered: the references listed in the "Patent Citations (18)" and "Family Cites Families (2)" sections of the patent page, plus the applicant's own specification, which is usable as an admission of the state of the art.

Scope note / consistency flag. The previously generated Litigation summary found no litigation or PTAB record. Nothing in the prior-art references below changes that; none of them carries an assertion history. This section is a § 103 analysis only. Where I rely on a reference whose full text I did not retrieve, I say so.

---

1. Governing standard

• Graham v. John Deere Co. (1966): obviousness is assessed against (i) the scope and content of the prior art, (ii) the differences between the prior art and the claims, (iii) the level of ordinary skill, and (iv) secondary considerations.
• KSR Int'l Co. v. Teleflex Inc. (2007): a combination is obvious where the claimed elements were each known, the combination does no more than yield predictable results, and there existed a design incentive, market pressure, or "finite number of identified, predictable solutions." A mere "aggregation of familiar elements" is not patentable.
• The claims here are broad — three independent claims (1, 8, 15) that recite, in three forms, exactly one inventive core: broadcasting a network ID together with an authorizer address and a verifier address. Every other feature discussed at length in the specification (roaming between private/public networks, key reuse on reconnect, per-packet tagging) is not claimed (see the earlier Patent summary; those features live in abandoned divisional US 11/072,039 / US 2005/0149764 A1).

---

2. Person of ordinary skill in the art (PHOSITA)

As of 2001‑09‑21: a person holding a B.S. in electrical engineering or computer science and 2–4 years of experience in wireless data networking and/or network security, or an M.S. with less experience. Such a person would be familiar with (a) IEEE 802.11 beaconing and access-point discovery, (b) authentication servers and per-packet access control in wireless LAN/public-network deployments, and (c) server load balancing and failover. This is a modest skill level; the field was active and crowded in 2001.

---

3. Claim-term construction relevant to § 103

The claims require broadcast of addresses, not the authentication logic, the key, or the tagging scheme. That is what makes the § 103 case tractable.

---

4. The prior-art references, and what each supplies

4.1 The strongest references

(A) US 7,185,360 B1 — HereUare Communications, "System for distributed network authentication and access control" (filed 2000‑08‑01; priority 2000‑07‑31).
https://portal.unifiedpatents.com/patents/patent/US-[7185360](/patent/7185360)-B1
Verified content: a mobile user connects (wirelessly or wired) to a private/target network; if unauthorized, the user is redirected to an authentication server that collects credentials; a gate keeper server authenticates and sends an "unblock" message to an access control device; thereafter "all further traffic from the client device flows through the access control device until an access expiration event happens, such as a timer expiration."
→ Supplies 1b (authorizer) and 1c (verifier/access-control node), including the architectural separation of who-may-enter (authentication server) from what-traffic-passes (access control device), and an expiring authorization.

(B) US 6,163,843 A — Toshiba, "Packet inspection device, mobile computer and packet transfer method … improved … authenticity check scheme" (filed 1997‑10‑23; priority 1996‑10‑24; granted 2000‑12‑19).
https://patents.google.com/patent/[US6163843A](/patent/US6163843A)
Verified content: a packet inspection device (gateway 4) that "judges whether a passing of a packet transmitted from a mobile computer … is permitted … according to a mobile computer identification information contained in said packet," refuses (sends a refuse message) or transfers accordingly, and checks user information and returns requested key information to the mobile computer.
→ Supplies 1c (verifier) almost verbatim: per-packet authenticity gating on a distinct node plus key issuance. This is a § 102/§ 103-level teaching of the "verifier" concept in mobile computing.

(C) US 6,834,341 B1 — Microsoft, "Authentication methods and systems for accessing networks … and … the internet" (filed 2000‑02‑22). (Listed on the patent page under "Family Cites Families.")
https://patents.google.com/patent/US6834341
Verified content: a PANS server that authenticates the user, hands the user a token/key which the user then attaches to "all subsequent data packet transmissions," whereupon "all user data packets containing this token or key … are allowed passage through the PANS server"; also grants limited pre-authentication access, enforces QoS policies, and accounts for packets.
→ Supplies 1b + 1c in one node (the PANS server both authorizes and gates), plus token-based packet admission. Note this reference shares substantial disclosure lineage with the patent-at-issue; it is nonetheless genuine 102(e) art by its 2000 filing date.

(D) US 6,877,104 B1 — NEC Infrontia, "Wireless local area network system, fault recovery method …" (filed 1999‑03‑29).
https://patents.google.com/patent/[US6877104B1](/patent/US6877104B1)/en
Verified content: a wireless LAN with multiple access points that "transmit beacon information … at regular intervals"; on an AP fault, the client "starts searching for another access point" and re-establishes a link to continue communication.
→ Supplies periodic broadcast of discovery/beacon information (claim 2 / 9 / 16) and failover-to-alternate-node (claims 7 / 14 / 21) — the fault-tolerance limitations.

(E) US 6,073,016 A — Telxon, "Mobile device ID allocation system and method" (filed 1997‑01‑02; granted 2000‑06‑06).
https://patents.google.com/patent/US6073016
Verified content: a host computer on a network backbone that determines whether a roaming mobile unit has a valid identification code, refuses registration until one is assigned, and assigns a valid ID so the unit may access the network; the unit roams cell-to-cell.
→ Supplies network-side admission/registration controlled by a central server, and the notion of the network (not the client) determining validity.

4.2 Supporting/mobility references

• US 5,519,706 (IBM) — dynamic user registration in a mobile network.
• US 5,812,949 (NEC) — paging/registration of a mobile terminal.
• US 5,848,233 (Sun) — dynamic packet filter assignment (per-client packet filters established after authentication). (Retrieved by title only.)
• US 5,884,024 (Sun) — secure DHCP server; authenticated address assignment. (Retrieved by title only.)
• US 5,922,049 (Sun) — DHCP + marking to override learned IP addresses. (Retrieved by title only.)
• US 6,732,036 (Siemens), US 6,731,621 (Hitachi), US 6,763,007 (Lucent), US 6,487,406 (Telcordia), US 6,845,094 (UTStarcom), US 6,671,735 (Qualcomm) — mobile-IP/roaming, IP-address assignment, and wireless-unit identification; general background establishing that discovering topology/address information over the air and redirecting traffic to a new serving node were routine.

4.3 References that are not available as prior art, or are irrelevant

• US 6,864,341 B2 (Bausch & Lomb), "High refractive index aromatic-based prepolymer precursors" — priority 2001‑11‑02, after the patent's 2001‑09‑21 filing. It is not prior art under § 102(a)/(e). It also appears non-analogous (contact-lens polymers). Its presence in the citation list is almost certainly a citation artifact and should not be relied upon.
• EP 0 519 563 A3 (Philips) — a 1991 synchronous-to-asynchronous TDM packet converter; technically unrelated to mobility and, at best, weak general background.
• The five "Cited By" documents (e.g., US 2007/0118742, US 2012/0218077, US 9,220,053, US 9,949,127, US 10,872,478) and the 31 "Families Citing this family" documents post-date the filing and are not prior art; they are relevant only as post-filing evidence of what the art later did.

Date integrity check. Most cited references that granted after 2001 (e.g., US 6,877,104 granted 2005; US 7,185,360 granted 2007; US 6,834,341 granted 2004) are still prior art only under § 102(e), by virtue of their earlier U.S. filing dates. Any obviousness position built on them must be pleaded on the § 102(e) filing dates (1999‑03‑29, 2000‑08‑01, 2000‑02‑22 respectively), not on their grant dates. I flag this because it is a common failure point in § 103 contentions.

---

5. Element-by-element mapping for the independent claims

Claim 1 (method of broadcasting)

Claim 8 (system: network + authorizer device + verifier device + signal generator)

The system claim is the same three signals implemented as an apparatus. US 7,185,360 supplies the network, the authentication server (authorizer) and the access control device (verifier) as separate apparatus; US 6,877,104 supplies a "signal generator"-equivalent in the APs that "transmit beacon information … at regular intervals." Combining them yields claim 8.

Claim-drafting flag (carried over): claim 8 as printed contains the duplicated phrase "identifies a verifier signal that identifies a verifier network address." This is a typographical artifact and does not change the § 103 analysis; the claim would be construed to require the same three signals as claim 1.

Claim 15 (computer-readable storage medium)

Claim 15 recites the same three broadcasting operations as instructions. Because claim 1's operations are the same, claim 15 rises or falls with claim 1 under § 103. (Separately, a post-Alice § 101 vulnerability exists for a claim directed to "broadcasting" generic information, but that is a § 101 issue, outside this task.)

---

6. Motivation to combine (the KSR analysis)

The central question is why a PHOSITA in 2001 would put (i) a network-identifying beacon, (ii) an authorizer address, and (iii) a verifier address into a single broadcast. The record supplies several independent, mutually reinforcing motivations:

1. The problem itself dictates the solution. The applicant's own Background admits that public networks "typically perform packet-level processing for both user-level authentication and privacy, and for offering different kinds of services." Providing wireless Internet access to unknown mobile users in a public venue (airport, mall) necessarily requires both an identity decision and a continuing per-packet admission decision. Once those are two functions, the client must learn where each function lives before it can use the network — and a broadcast is the only channel available before the client is authorized. (The spec acknowledges this at FIG. 3, where the authorizer address is "given out … before a user has been authorized … so that the user can access information … and … download network access software.")

2. The split architecture was known and its benefits were known. US 7,185,360 already separates the authentication server from the access control device; US 6,163,843 already isolates a packet inspection device as the enforcement point. Combining these known nodes into one advertised service set is the predictable "arrangement of old elements." The applicant's own specification concedes the point: "Because the task of the authorizer and the verifier are separated, multiple verifiers may be deployed …" That sentence is an admission that separation was a known, desired architecture — supplying the very motivation to advertise both addresses.

3. Discovery-by-broadcast was the established technique. US 6,877,104 teaches that wireless LAN access points routinely broadcast beacon information at intervals so clients can discover and attach. Adding server-address fields to a discovery beacon is a predictable, conventional extension of a known broadcast — analogous to the "arrangement of old elements" approved in KSR.

4. A finite number of predictable options. Given a network with an authorizer node and a verifier node, the client must be told their addresses by one of only a few mechanisms: static/manual configuration, DHCP-type provisioning, or broadcast. Broadcasting is the only one that works for a roaming, pre-authorized client — the very use case the reference set addresses.

5. Predictable results / no unexpected behavior. The combination yields nothing more than the expected sum: the client learns where to authenticate and where to send packets. There is no synergy, no criticality of any specific parameter, and no teaching away in any reference.

---

7. The dependent claims

7.1 Claims 2, 9, 16 — "each signal is broadcast periodically"

Rendered obvious by US 6,877,104, which expressly describes access points transmitting "beacon information … at regular intervals." Periodic beaconing is also the ordinary operation of 802.11.

7.2 Claims 3, 10, 17 — the three signals "broadcast together in an announcer signal"

This is the narrowest point of novelty relative to the individual references, but it is a foreseeable packet-format/design choice: once the decision is made to broadcast discovery information (motivation 3 above), placing the network ID and the two server addresses in a single frame is the natural, lowest-overhead implementation. KSR squarely permits this ("a combination … of familiar elements according to known methods … when it does no more than yield predictable results"). The spec itself gives no technical significance to co-location beyond convenience.

7.3 Claims 4, 11, 18 — addresses as IP addresses

Obvious as a matter of design choice: US 6,732,036, US 6,731,621, US 6,763,007, US 6,487,406, US 6,845,094 all operate on IP-based mobile networks, and the specification states the addresses "are Internet address[es] or host organization network address[es]."

7.4 Claims 5–6, 12–13, 19–20 — substituting an alternate verifier address (load-balancing)

The "substituting" step is server load balancing / redirection, which was ubiquitous by 2001 (round-robin DNS, L4 load balancers). The architecture supplies the motive: US 6,877,104 is explicitly directed to "preventing throughput from being decreased," i.e., load management across nodes — establishing the design incentive to steer new clients to a less-loaded verifier. Combined with the broadcast mechanism of the base combination (which is how the advertised address is changed), claim 5/6 is obvious. Note the diminishing significance of this limitation: the switching mechanism is the same broadcast already required by claim 1; only the trigger is added.

7.5 Claims 7, 14, 21 — substituting on detected preferred-verifier failure

Rendered obvious by US 6,877,104, which discloses precisely this: detect a node fault, and have the client search for and connect to an alternate access point. Mapping AP-failover onto verifier-failover is a direct, predictable application of a known fault-recovery technique to an analogous node type — the paradigm case for KSR.

---

8. Secondary considerations

I found no evidence of: unexpected results, long-felt unmet need attributable to the claimed broadcast, industry praise, or copying tied to claims 1/8/15. The specification alleges no criticality. Two counterweights exist but are weak:

• Commercial success / licensing: the patent is held by Microsoft Technology Licensing, LLC, but any success of Microsoft's networking products is not coextensive with a signal that merely broadcasts a network ID plus two server addresses (no nexus), so it carries little weight.
• Long prosecution (2003 publication, 2011 issuance): delay in prosecution is not a secondary consideration; it typically cuts the other way (more intervening art).

---

9. Bottom line

A strong prima facie § 103 case exists against all 21 claims. The reference set cited on the patent's own face supplies every element:

• US 7,185,360 (HereUare) — separated authorizer (authentication/gate-keeper server) and verifier (access-control device), with expiring access.
• US 6,163,843 (Toshiba) — a packet-inspection/verification node gating mobile-computer packets on embedded identification information, plus key return.
• US 6,834,341 (Microsoft PANS) — authentication + token-based packet admission + policy/accounting, in the same technical space and lineage.
• US 6,877,104 (NEC Infrontia) — periodic beacon broadcast and fault-driven failover to an alternate node (claims 2/9/16 and 7/14/21).
• US 6,073,016 (Telxon) and the Sun IP-provisioning references — network-side admission and address assignment (claims 4/11/18).

The only feature not squarely met by a single reference is the co-location of the three signals in one "announcer signal" (claims 3/10/17); that limitation is a foreseeable format choice with no demonstrated criticality and is vulnerable under KSR.

Where the patent may retain traction (not in the claims): The genuinely differentiated subject matter — automatic saving/restoration of private-network settings when roaming to/from a public network, and reuse of a still-valid authorization key to skip re-authentication on reconnect (FIGS. 10–11) — appears only in the specification and in the abandoned divisional US 11/072,039 / US 2005/0149764 A1, not in any of the 21 issued claims. If the objective is to attack or design around this patent, the broadcast claims are the soft target; those unclaimed features are where the disclosure's real technical contribution sits.

---

Caveats and verification items

1. Full text not retrieved for the Sun references (US 5,848,233; US 5,884,024; US 5,922,049), US 5,519,706, US 5,812,949, US 6,732,036, or US 6,671,735. Their roles above are assigned from their titles and known subject matter; each should be read in full before being relied on as an element-by-element teaching.
2. Coverage of the "single announcer signal" limitation (claims 3/10/17) is the weakest link and should be documented with a specific beacon-format teaching (e.g., an 802.11 or analogous beacon carrying multiple service fields), not with general knowledge alone.
3. § 102(e) dates, not grant dates, must be used for US 6,877,104 (1999‑03‑29), US 7,185,360 (2000‑08‑01), and US 6,834,341 (2000‑02‑22).
4. US 6,864,341 (Bausch & Lomb) is not prior art (priority 2001‑11‑02, after the filing date) and is non-analogous; it should be excluded from any contention. Its presence in the citation list is a likely artifact.
5. All statements about reference content above are grounded in the retrieved text at the cited URLs; statements about the patent itself are grounded in the authoritative full text supplied.

Primary sources: https://patents.google.com/patent/US8041815/en · https://patents.google.com/patent/US6163843A · https://patents.google.com/patent/US6877104B1/en · https://patents.google.com/patent/US6834341 · https://portal.unifiedpatents.com/patents/patent/US-7185360-B1 · https://patents.google.com/patent/US6073016