Invalidity dossier
US 8032109
Method and system for obtaining emergency caller location
Current assignee: TP Lab Inc
Added 9/26/2026, 4:26:48 AM
Active provider: DeepSeek · deepseek-v4-flash
Auto-generating section 1 of 2: Extensions…
Each section takes ~30-60s with web-search grounding. Keep this tab open — sections will fill in below as they complete.
Patent summary
Title, assignee, inventors, filing/issue dates, abstract, and a plain-language overview of the claims.
I'll run targeted searches for this exact patent number across patent and litigation sources.
Let me run one more targeted check for any litigation or appellate activity tied to this patent.
US Patent 8,032,109 — Summary
Important methodological note up front: I searched for this exact number across patent databases and Federal Circuit materials. I found no Federal Circuit appeal or 2026 CAFC docket entry involving U.S. Patent 8,032,109, and I found no district-court infringement case asserting this specific patent. I am reporting that absence explicitly rather than inferring litigation. Details on what does exist are in the litigation section below.
Bibliographic data
| Field | Value |
|---|---|
| Patent number | US 8,032,109 B1 |
| Title | Method and system for obtaining emergency caller location |
| Inventors | Chi Fai Ho; Shin Cheung Simon Chiu |
| Original assignee | TP Lab Inc. |
| Later assignments | → Local Intelligence, LLC (recorded 2017‑09‑19, effective 2017‑08‑16); → TP Lab, Inc. (recorded 2019‑11‑15 and 2019‑11‑18, effective 2019‑11‑13) |
| Application | US 11/750,281 |
| Filing date | 2007‑05‑17 |
| Priority date | 2005‑07‑14 |
| Issue date | 2011‑10‑04 |
| Relationship | Continuation of US 11/182,219 (issued as US 7,272,402); the head of an 8‑member U.S. family (US7272402B1, US8032109B1, US8121613B1, US8219061B1, US8503973B1, US8744400B1, US9137634B1, US9510175B1) |
| Status | Expired – Fee Related. Google Patents lists "lapsed due to failure to pay maintenance fee, effective 2019‑10‑04," with a nominal adjusted expiration of 2028‑09‑30. The two entries are inconsistent as displayed; the operative event is the nonpayment lapse. |
| Claims | 4 total (2 independent: claim 1 method, claim 3 system) |
| Representative CPC | H04W 4/02; H04W 4/90; H04W 76/50; H04M 3/5116; H04M 2242/04, 2242/30; H04M 7/006 |
| Notable citations | US 2005/0026650 A1 (SBC Knowledge Ventures); US 2005/0083911 A1 (3Com); US 2010/0233991 A1 (AT&T) |
| Cited by | US 2009/0147926 A1 / US 8,630,390 B2 (Verizon, "Automated E911 route verification"); US 10,129,390 B2 (Kone, elevator emergency test calls) |
Abstract (as issued)
Methods and systems for obtaining the location of a caller during an emergency or other telephone call. Before or during a call, a phone system can obtain from one or more sources a subscriber access line identity associated with a subscriber location record that includes a subscriber access line identity attribute and a subscriber location attribute. The phone system sends a query including the subscriber access line identity to a subscriber location query system, which returns the subscriber location record or subscriber location. The caller location can then be displayed to an agent/operator so emergency services can be dispatched. Using a similar procedure and a memory, phone systems can also determine if a subscriber phone has changed location. Methods for testing the emergency call capabilities of a subscriber access line are also disclosed.
Independent claims in plain language
Claim 1 — method (the core claim). For a call from a phone connected through a subscriber access line to a subscriber access line module, which in turn connects to a phone system, the method comprises:
- (a) the phone system determines a subscriber access line identity of the subscriber access line;
- (b) the phone system sends a query containing that identity to a subscriber location query system;
- (c) the phone system receives back the corresponding subscriber location, where — importantly — the subscriber location is defined as comprising "a physical or link layer property of the subscriber access line module to which the subscriber access line is coupled"; and
- (d) subscriber phone equipment (attached via the same access line) determines whether an emergency call can be made over that access line, by (d1) an emergency call test module sending a query to the subscriber access line module or an emergency phone system, and (d2) receiving a response indicating whether the emergency call can be made.
So claim 1 is a hybrid: the location-lookup mechanism (a)–(c) resides in the network side, while the emergency-capability self-test (d) resides in the subscriber premises equipment.
Claim 3 — system. The apparatus counterpart, reciting: a subscriber access line (with identity); a subscriber access line module; a phone coupled to the module via the access line; a subscriber location query system holding the location corresponding to the line identity; and a phone system that receives the call, determines the line identity, queries the location query system, and receives back the subscriber location (again with the "physical or link layer property of the subscriber access line module" limitation). It further recites subscriber phone equipment comprising an emergency call test module that queries the access line module or an emergency phone system and receives a response indicating whether an emergency call can be made.
Dependent claims.
- Claim 2 (depends on 1) / Claim 4 (depends on 3): the subscriber phone equipment further includes an emergency call test indicator, which is set according to the test response. The specification describes this indicator as, e.g., an LED turned green/red, or a text panel displaying "emergency call Test Succeeds" / "emergency call Test fails."
Notable scope observations
- The specification discloses a much broader system (location-change detection via stored line identity, VoIP/IP-address change detection, service-change updates, colored LED combinations for combined test results, routing emergency calls to the subscriber-access-line provider's phone system, and non-emergency uses such as location-specific directory services and toll-free calls). None of those embodiments are captured in the four issued claims — the granted claim set is notably narrow, essentially the base lookup method/system plus the emergency-call self-test module and its indicator.
- The "physical or link layer property of the subscriber access line module" language in claims 1 and 3 is a meaningful narrowing that distinguishes the claimed subscriber location from a mere street address lookup.
Litigation / CAFC status — what I found and did not find
- The Google Patents page carries a "Family has litigation" flag pointing to a Darts‑IP family link (family ID 38481853) for the whole TP Lab emergency‑location family. This is a family-level flag and is not evidence that the '109 patent itself was asserted.
- No CAFC 2026 docket entry, opinion, Rule 36 judgment, or oral-argument calendar entry referencing 8,032,109 or its application number 11/750,281 appeared in my searches. I therefore cannot report any appellate activity for this patent. If you need a definitive negative, that should be confirmed against the CAFC docket system directly, since I am relying on web-indexed results.
- Context from secondary reporting (Mondaq, 2024): the TP Lab emergency-caller-location family was transferred to Local Intelligence, LLC (a Dominion Harbor affiliate) in August 2017 and transferred back to TP Lab in November 2019; per that report Local Intelligence "never asserted patents from this family." Later 2024 suits by a separate plaintiff (Lab Technology LLC) asserted other TP Lab patents — e.g., 8,503,973, 8,515,032, 8,498,388, 9,578,570 (and 9,219,982 from a different family) — against Samsung and Verizon, but 8,032,109 was not among the identified asserted patents.
- The patent's lapse for nonpayment of maintenance fees effective 2019‑10‑04 further makes fresh infringement exposure unlikely (past damages only, subject to the § 286 six-year bar).
Uncertainty disclosure: I do not have authoritative confirmation of (i) a complete litigation history for the '109 patent, or (ii) the precise docket status before the CAFC in 2026. My statements of absence are based on the searches I ran and should be verified against PACER and the CAFC docket if a negative finding is material to your analysis.
Generated 9/26/2026, 4:27:09 AM
Cases on file (0)
Specific litigation cases in our database that name US patent 8032109. The free-form analysis below may also discuss cases beyond this list.
No cases on file mention this patent. Upload a CSV or add a case manually in Admin → Manage litigation cases.
Litigation summary
Past and pending lawsuits — plaintiffs, defendants, jurisdictions, outcomes, and notable rulings.
I'll run targeted searches on litigation databases for this exact patent number.
Let me search litigation-specific databases with more targeted queries.
Litigation search results for U.S. Patent No. 8,032,109
Bottom line: I found no litigation — no district-court complaint, no ITC Section 337 investigation, no PTAB proceeding, and no CAFC appeal — that specifically asserts or challenges U.S. Patent No. 8,032,109. Searches across patent-litigation aggregators (RPX Empower/Litigation, Unified Patents litigation and PTAB case lists, PACER-derived feeds such as PacerMonitor and UniCourt, CourtListener, and general web indices) returned no case tying this exact number to a party, docket, or filing date.
Because you asked me not to auto-correct identifiers, I want to be explicit that I did not treat any near-miss number as this patent.
What I searched and what came back
| Query target | Result |
|---|---|
US patent 8032109 litigation |
No litigation hit. Only the patent's own Google Patents / FreePatentsOnline pages. |
"8032109" patent lawsuit defendant |
Only the patent itself, plus unrelated records: a Brazilian RG identity number 8032109, a Mercosur tariff classification 8032109, and other non-US-patent uses of the digit string. |
"8,032,109" patent infringement lawsuit |
No hit for this patent. Returned unrelated patents with similar-looking numbers (see "false positives" below). |
unifiedpatents litigation 8032109 TP Lab |
No hit; Unified's litigation/PTAB case lists surfaced nothing for this number. |
"TP Lab" patent lawsuit 8032109 |
No hit tying 8032109 to a case. |
Local Intelligence LLC TP Lab patent assertion 8032109 |
No hit asserting 8032109. |
Near-misses I deliberately did not report as litigation against '109 (false positives)
These appeared in results and are different patents/identifiers, not U.S. 8,032,109:
- U.S. 8,549,109 — Maxell, Ltd. ITC Section 337 complaint against VIZIO, Inc. (smart TVs). Same last four digits, different patent.
- U.S. 7,612,109 — Vifor/American Regent pharmaceutical patent (Injectafer®), asserted against generic ANDA filers (e.g., D. Del.). Different patent, different field.
- U.S. 8,031,064 — Orange Electronics v. Autel (Shenzhen Autel / 道通科技), E.D. Tex., TPMS products; Fed. Cir. appeal reported Jan. 2026 (patent held invalid). Different patent.
- Brazilian RG No. 8032109; Mercosur tariff code 8032109; South Carolina municipal procurement act "8032109." Non-patent identifiers.
Family-level flag (not evidence of '109-specific suits)
As noted in the earlier section, the Google Patents page carries a "Family has litigation" flag keyed to the Darts‑IP family ID 38481853 covering the whole eight-member TP Lab emergency-location family. That flag is family-scoped and, on its own, is not evidence that the '109 patent was asserted in any particular case. I could not retrieve a Darts‑IP case list through open web search to identify which family member(s) drove the flag.
Closest known related activity (does not name '109)
- Lab Technology LLC filed a series of suits in the E.D. Tex. (2024) asserting patents "apparently received from TP Lab," per RPX Empower (June 8, 2024): defendants included Samsung, Verizon, Amazon, Anritsu, AT&T, Bose, Ericsson, Stryker, and Quectel. Based on the earlier section of this analysis, the patents identified in those complaints were 8,503,973 / 8,515,032 / 8,498,388 / 9,578,570 (plus 9,219,982 from a different family) — 8,032,109 was not among them. (RPX Empower)
- Local Intelligence, LLC (Dominion Harbor affiliate) held the family from the Aug. 2017 assignment until the Nov. 2019 transfer back to TP Lab. Secondary reporting indicates Local Intelligence did not assert this family.
Practical/status context
- The '109 patent lapsed for failure to pay maintenance fees, effective 2019‑10‑04 (Google Patents legal events). A lapsed patent can still support past damages for pre-lapse infringement if a suit were filed within the 35 U.S.C. § 286 six-year look-back, but no such suit was found.
- Current assignee of record per USPTO assignment records: TP Lab, Inc. (recorded Nov. 2019).
Caveats and how to verify a definitive negative
My finding of absence is search-based, not docket-authoritative. Specifically:
- Unified Patents litigation portal, RPX Empower, Darts‑IP, and PACER were reachable only through indexed web results, not direct structured queries in this session. A negative should be confirmed by a direct search in those systems (and in the Darts‑IP family 38481853 case list) if it is material.
- CAFC: I found no 2026 (or earlier) Federal Circuit docket entry, opinion, or Rule 36 judgment referencing 8,032,109 or its application number 11/750,281. Confirm against the CAFC docket/CM‑ECF if an appellate negative matters.
- PTAB: No IPR/PGR/CBM referencing 8,032,109 surfaced. Confirm in the USPTO PTAB API/PatentCenter if needed.
- § 337: No ITC investigation referencing 8,032,109 surfaced. Confirm via EDIS.
If you require a certified-negative litigation history for 8,032,109 (e.g., for a freedom-to-operate or damages opinion), it should be confirmed directly against PACER, the Unified Patents litigation list, RPX, and Darts‑IP family 38481853, since I am relying on web-indexed results rather than those authoritative dockets.
Generated 9/26/2026, 4:47:24 AM
Proceedings on file (0)
All PTAB activity →AIA trial proceedings (IPR / PGR / CBM) filed at the USPTO Patent Trial and Appeal Board against this patent. Sourced from the USPTO Open Data Portal and refreshed every six hours; each proceeding number deep-links to the PTAB E2E docket.
No PTAB proceedings on file. This patent has not been challenged via IPR, PGR, or CBM. The absence is itself a signal — well-asserted patents eventually attract IPRs. The LLM analysis below may surface filings the ODP feed hasn’t indexed yet.
PTAB challenges
AIA trial proceedings at the USPTO Patent Trial and Appeal Board — IPR, PGR, and CBM. Petitioners, judge panels, claim-level invalidation outcomes from Final Written Decisions, and Federal Circuit appeals. The single most important defensive datapoint after litigation history.
I'll verify the structured "no proceedings on file" default against live sources before writing the report.
Let me run a few more targeted checks before concluding.
Proceedings overview
Zero AIA trial proceedings. The USPTO Open Data Portal structured block is unambiguous — "The USPTO ODP API returns no AIA trial proceedings for this patent as of the most recent ingest" — and my independent web checks found no IPR, PGR, or CBM petition naming U.S. Patent 8,032,109 anywhere in the public record. There is nothing to report under active / instituted / settled / FWD categories, because no proceeding exists to categorize.
The bottom-line defensive posture is therefore neither of the two archetypes in the prompt. This is not a "hardened by surviving IPRs" patent, and it is not a "claims canceled — the troll has no case" patent. It is an untested-across-the-board patent that has already expired for fee nonpayment, which is a different and generally weaker assertion posture than either.
One material caveat on my negative finding: my verification relied on web-indexed results plus the ODP feed. A truly definitive negative requires a direct lookup in PTAB E2E / Patent Center → "Patent Trial and Appeal Board" tab for application 11/750,281. I could not complete that primary-source check, so treat the negative as high-confidence-but-not-certified.
Proceedings
None. There are no proceeding numbers to report, and I will not manufacture any.
Keyword traps — proceedings that superficially match but are not this patent
These are the false positives my searches surfaced. Flagging them explicitly, because each one will mislead a defendant doing a docket search on "109" or on the TP Lab/emergency-location subject matter.
| What you'll find | What it actually is | Why it is not this patent |
|---|---|---|
| IPR2024-01477 — Samsung v. Truesight Communications | An IPR on U.S. 8,898,803 ("the '803 Patent"), a different patent owned by a different patent owner; includes a Sotera stipulation and Fintiv briefing | The "803" shorthand refers to 8,898,803, not 8,032,109. Unrelated technology and parties. |
| IPR2025-00434, IPR2025-00274 | Cited in a Pantech-related petition brief as discretionary-denial authority | Applied-Optoelectronics / Berkshire precedent citations, not proceedings on this patent. |
| Maxell ITC complaint re "the '109 Patent" | U.S. 8,549,109 (smart televisions) | A same-suffix trap: "109" ≠ 8,032,109. |
| Apotex / Vifor ANDA counterclaims re "the '109 patent" | U.S. 7,612,109 (ferric carboxymaltose) | Same-suffix trap in the pharmaceutical space. |
| Ricoh suit re "the '109 Patent" | U.S. 6,631,109 | Same-suffix trap. |
| CAST Lighting ITC § 337 response re "Asserted Patents" and inequitable conduct | Unrelated lighting patents | Different parties and patents entirely. |
Also note: a Unified Patents portal page exists for US 8,219,061 B1, a sibling in this TP Lab family. That page shows "Parent Company: Lab Technology LLC" and an expiration of 2027-05-16. A Unified Patents patent page is a catalog entry, not a Unified-filed IPR. I found no Unified Patents (or any defensive-aggregator) petition against the '109 or its siblings. Do not read the portal page as estoppel-generating activity.
Strategic summary
Claim status of 8,032,109: claims 1, 2, 3, and 4 are all UNTESTED. The patent has four issued claims — independent claim 1 (method) and claim 3 (system), with dependents claim 2 and claim 4 (emergency call test indicator). No claim has been canceled, construed by the Board, or held patentable in an AIA trial. There is no narrowing to report and no surviving-claims list to give, because the Board has never written on this patent.
Estoppel landscape: there is no estoppel. Because no IPR, PGR, or CBM was ever instituted, 35 U.S.C. § 315(e)(2) bars no one. Every § 102/§ 103 ground based on patents and printed publications remains fully available to any defendant in district court, and any defendant who has not been served with a complaint more than one year earlier remains free to file a fresh IPR petition under § 315(b). There are also no § 325(e) PGR estoppels and no § 315(a) civil-action bars to consider. This is, purely on the estoppel axis, an open field.
The dominant fact is not the PTAB record — it is the fee lapse. Per the ODP/Google Patents legal events, the patent expired for failure to pay maintenance fees with an effective date of 2019-10-04, and the record shows no petition to accept late payment and no reinstatement. The "Family has litigation" Darts-IP flag discussed in the earlier section is a family-level flag and, per the Mondaq reporting already noted, Local Intelligence LLC "never asserted patents from this family." The 2024 Lab Technology LLC campaign asserted other TP Lab patents (8,503,973, 8,515,032, 8,498,388, 9,578,570), not 8,032,109. Combined with the lapse, the practical exposure window is essentially closed: any suit filed now would be limited to past damages under § 286, and the six-year lookback from a 2026 filing reaches only conduct after 2020 — after the patent had already lapsed. That timing arithmetic is the strongest defense available, and it requires no PTAB outcome at all.
Pattern signals. No repeat-petitioner behavior is observable because there are no petitioners. The patent owner has never appeared before the Board on this patent, so there is no history of aggressive or passive PTAB appeal conduct to read. No defensive aggregator appears in the chain for this patent or its siblings. Non-practice for 19 years, a fee lapse, an unasserted family, and zero PTAB filings collectively describe a patent that the market treated as low-value — which is itself the signal here.
Recommended next steps
If you are a defendant and the plaintiff cites claims 1–4 of 8,032,109:
- I cannot link you to an FWD or quote a disposition, because none exists. Anyone who tells you claims of this patent were canceled in an IPR is mistaken — possibly misled by one of the same-suffix traps tabulated above. Demand the proceeding number before accepting any such representation.
- Run the primary-source negative yourself at USPTO Patent Trial and Appeal Board E2E and the Patent Center "Patent Trial and Appeal Board" tab for application 11/750,281. My negative is drawn from the ODP feed and web index, not from E2E directly.
- Lead with the expiration, not with invalidity. Confirm the 2019-10-04 lapse-for-nonpayment in the prosecution/legal-events record and pair it with § 286. If the demand letter postdates the lapse by more than six years of damages accrual, the damages theory may fail as a matter of law regardless of the merits of the infringement case.
- If you have not been served more than one year ago and need a merits kill, the IPR door is open and estoppel-free. Expired claims can still be challenged in an IPR (the patent owner simply cannot amend them), which matters if you face a live past-damages claim and want a Board ruling rather than a district-court invalidity verdict. There is no § 315(b) bar unless and until you are served.
- Do not build any part of your strategy on offense by the patent owner. Nothing in the record shows this patent has ever been asserted, and the earlier section's finding — no district-court case asserting 8,032,109 and no CAFC appeal — is consistent with everything I found here.
If no PTAB activity exists, say so plainly — and I am. The absence is a weak signal in isolation (well-asserted patents eventually attract IPRs), but in this case the absence is corroborated by a fee lapse, a documented non-assertion of the family, and no defensive-aggregator interest. The combined picture is of a patent that was never worth challenging because it was never worth asserting.
Uncertainty disclosed: (i) I could not query PTAB E2E directly, so my zero-proceeding finding rests on the ODP feed plus web search; (ii) I have no authoritative confirmation of the complete litigation history of the '109 patent itself; (iii) the ODP ingest date was not specified in the structured block, so I cannot quantify how recently the "no proceedings" state was established.
Generated 9/26/2026, 4:47:44 AM
Ownership chain (4)
Asserters network →Structured records extracted from the assignment-history narrative below. Each entity links to its full ownership-network profile.
2007-05-11 · recorded 2007-05-17 · reel 019311/0103 · Assignment
2017-08-16 · recorded 2017-09-19 · reel 043628/0373 · Assignment
TP Lab, Inc.Local Intelligence, LLC
transfer-to-asserter
2019-11-13 · recorded 2019-11-15 · reel 051019/0819 · Assignment
2019-11-13 · recorded 2019-11-18 · reel 051033/0529 · Assignment
Assignment history
Inventors, original assignee, and the chain of ownership recorded with the USPTO — including the correspondent attorney who recorded each assignment, since shell-LLC chains often share one repeat-player attorney even when the entity names look unrelated. Surfaces NPE / patent-troll patterns: shell-entity transfers, known asserters in the chain, repeat correspondent fingerprints, pre-litigation assignments, and bankruptcy fire-sales.
I'll research the assignment chain for this patent, focusing on reel/frame records and correspondents of record.
Let me dig into the specific assignment records and the entities involved.
Assignment & Ownership Analysis — US 8,032,109
Source note / limitation up front. I pulled the recorded-assignment data from the Google Patents legal-events block for this patent (which mirrors the USPTO Assignment Center record) and cross-referenced secondary reporting. I was not able to retrieve the "correspondent of record" field (the recording attorney/firm) for any of the four post-issuance/recorded instruments in this session — my searches did not surface the assignment cover sheets or the Assignment Abstract of Title page that carries that field. I am reporting the reel/frame, dates, assignors and assignees as recorded, and I am explicitly flagging the correspondent column as not determinable from my sources rather than guessing. Anyone needing the correspondent names should pull each reel/frame directly from https://assignmentcenter.uspto.gov/.
Inventors
| Inventor | Role / employer at filing | Notes |
|---|---|---|
| Chi Fai Ho | Co-inventor; founder and CEO of TP Lab | Named on the earlier, related TP Lab families as well; not an arms-length employee-inventor |
| Shin Cheung Simon Chiu | Co-inventor; TP Lab | Per Mondaq (2024), Chiu is the sole named inventor on the separate TP Lab family that issued Dec 2014–Dec 2015 (e.g., US 9,219,982), and a co-inventor with Ho on the 12-patent emergency-caller-location family that includes the '109 |
Both inventors assigned to TP Lab effective 2007‑05‑11 and appear never to have departed the assignee — one of them founded it. No "inventors departed within 12 months" pattern is present here; the fire-sale-style tell you asked about is absent.
Original assignee
- TP Lab, Inc. (recorded in the 2007 instrument as "TP LAB, California"; Google Patents lists the current assignee as TP Lab Inc), Palo Alto, California.
- Line of business: an early-2000s telecom/software IP developer — the portfolio spans emergency caller location, IP/VoIP telephony, media players and audio-content processing (see the Justia assignee listing for TP Lab). It is a pure R&D/IP-holding shop, not a carrier; it does not appear to ship an emergency-services product embodying this claim set.
- Current status: TP Lab, Inc. is the re-acquirer and current recorded owner (2019 recordings below). It has no public product in commerce that I could identify, and the patent itself is expired for failure to pay maintenance fees.
Assignment timeline
All four instruments below are the ones surfaced in the Google Patents / USPTO legal-events record for application 11/750,281.
2007‑05‑11 (executed) / recorded 2007‑05‑17 — Reel 019311/0103
- Conveyance: Assignment (of assignors' interest)
- Assignor: Chi Fai Ho; Shin Cheung Simon Chiu
- Assignee: TP Lab ("TP LAB, CALIFORNIA"; later recorded as TP Lab, Inc.)
- Correspondent: not determinable from my sources — not captured in the records I could reach.
- Context: original inventor-to-company assignment at formation of the portfolio; this is the standard startup assignment, not a reorg or sale.
2017‑08‑16 (effective) / recorded 2017‑09‑19 — Reel 043628/0373
- Conveyance: Assignment
- Assignor: TP Lab, Inc.
- Assignee: Local Intelligence, LLC (recorded address: Texas)
- Correspondent: not determinable from my sources.
- Context: transfer to an NPE/asserter affiliate. Mondaq (May 2024) identifies Local Intelligence, LLC as "an affiliate of Dominion Harbor Enterprises, LLC" and confirms this family was moved from TP Lab to Dominion's Local Intelligence in August 2017 — matching the effective date here.
2019‑11‑13 (effective) / recorded 2019‑11‑15 — Reel 051019/0819
- Conveyance: Assignment
- Assignor: LOCAL INTELLIGENCE
- Assignee: TP LAB, INC. (California)
- Correspondent: not determinable from my sources.
- Context: reverse transfer back to the original operating assignee — the portfolio "came home."
2019‑11‑13 (effective) / recorded 2019‑11‑18 — Reel 051033/0529
- Conveyance: Assignment
- Assignor: LOCAL INTELLIGENCE, LLC
- Assignee: TP LAB, INC. (California)
- Correspondent: not determinable from my sources.
- Context: apparent duplicate / confirmatory re-recording of the same Nov 13, 2019 transfer. Note the assignor-name variance ("LOCAL INTELLIGENCE" vs. "LOCAL INTELLIGENCE, LLC") and the three-day recording gap. This is consistent with a corrective or belt-and-suspenders second recording rather than two economically distinct transfers — but I could not confirm which, and the two reel/frames should be compared side-by-side.
Timing flag: the maintenance-fee lapse effective 2019‑10‑04 predates both November 2019 recordations. In other words, the patent had already lapsed when the assets were recorded back to TP Lab.
No Chapter 7/11 filings, no security agreements, no merger/change-of-name instruments, and no recorded licence appear in this chain.
Timeline diagram
timeline
title Ownership of US 8032109
2007 : Inventors assign to TP Lab
: Application filed as continuation
2011 : Patent issued
2017 : Assigned to Local Intelligence LLC
: Dominion Harbor affiliate
2019 : Assigned back to TP Lab Inc
: Second confirmatory recording
: Patent lapses for unpaid fees
NPE / troll-pattern signals
Shell-entity transfer — PRESENT. Reel 043628/0373 (effective 2017‑08‑16) moves the patent from operating IP-holder TP Lab to Local Intelligence, LLC, which Mondaq describes as a Dominion Harbor Enterprises affiliate — a licensing/assertion vehicle. This is the one clean "operating → licensing-only LLC" step in the chain. Caveat: Local Intelligence held it for ~27 months and never asserted this family.
Known asserter in the chain — PRESENT (with a material caveat). Dominion Harbor / Local Intelligence is a recognized high-frequency patent plaintiff; Mondaq documents Local Intelligence's pre-2020 campaign asserting US 9,219,982 against Samsung (E.D. Tex.), HTC (N.D. Cal.) and LG Electronics (D. Del.). The same source states Local Intelligence "never asserted patents from this family" — i.e., the '109 was warehoused, not litigated. So the entity is a known asserter, but this patent was not an asserted asset.
Repeat correspondent across the chain — UNCLEAR / NOT DETERMINABLE. The correspondent field was not retrievable for any of reel 019311/0103, 043628/0373, 051019/0819 or 051033/0529 in my sources. I cannot make a recurrence finding. This is exactly the field that would have been most probative (e.g., a single Dominion Harbor-side attorney recurring on both the 2017 outbound and the 2019 inbound recordings), so this gap should be closed by pulling the four cover sheets.
Cascading transfers — UNCLEAR. Two recordings landed within three days in Nov 2019 (051019/0819 and 051033/0529) with the identical effective date and identical assignee. That is consistent with a corrective re-recording rather than a chained-LLC cascade, but the near-duplication is unusual enough to verify. There is no <24-month chain of multiple distinct LLC assignees sharing an address or principal.
Pre-litigation transfer — NOT PRESENT. No infringement suit naming US 8,032,109 was found (consistent with the earlier summary section of this analysis). The 2017 transfer therefore cannot be tied to a six-month window before an assertion of this patent. Related-family suits by Lab Technology LLC in 2024 assert 8,503,973 and other TP Lab patents — not the '109 (Mondaq, 2024).
Bankruptcy fire-sale — NOT PRESENT. No bankruptcy of TP Lab, Local Intelligence, or Dominion Harbor appears in the record; the 2019 transfer back to TP Lab is inconsistent with a liquidation.
Privateering — UNCLEAR / WEAK. The 2017 TP Lab → Dominion Harbor-affiliate step has the shape of privateering (operating company parking patents with an NPE), but the two facts that would confirm it are absent: Local Intelligence never sued on this family, and the assets were returned to TP Lab in Nov 2019. Without an SEC filing or a suit tying this family to a TP Lab competitor, I will not call it privateering.
Defensive aggregator — NOT PRESENT. The chain does not terminate at RPX, AST, LOT, Unified Patents or OIN. It terminates at the original operating assignee, TP Lab, Inc.
There is also a family-level "Family has litigation" flag on the Google Patents page pointing to a Darts‑IP family record (family ID 38481853). As noted in the earlier summary, that is a family-level flag and is not evidence the '109 itself was asserted.
Verdict
NPE — moderate confidence.
Two signals fire, both traceable to a single link: the 2017 transfer at Reel 043628/0373 moved the patent from operating IP-holder TP Lab, Inc. to Local Intelligence, LLC, a Dominion Harbor Enterprises affiliate that is a recognized high-frequency patent plaintiff (Mondaq, 2024) — i.e., a shell/licensing transfer plus a known asserter in the chain. But the pattern is materially weaker than a classic troll chain: Local Intelligence never asserted this family, transferred the assets back to TP Lab at Reels 051019/0819 and 051033/0529 (effective 2019‑11‑13), and the patent then lapsed for non‑payment of maintenance fees effective 2019‑10‑04. No suit naming the '109 patent was found, so pre-litigation-transfer and privateering signals do not fire, and the chain does not terminate at a defensive aggregator — which is why this is moderate, not high, confidence, and why a "defensive / non-asserting" reading cannot be fully ruled out for this specific patent.
Verification links: USPTO Assignment Center search — https://assignmentcenter.uspto.gov/ (search patent number 8032109); underlying reels 019311/0103, 043628/0373, 051019/0819, 051033/0529.
Open items to close: (1) correspondent of record for all four instruments — needed to test signal 3; (2) whether 051019/0819 and 051033/0529 are two instruments or a corrective re-recording; (3) confirm on PACER that no 2024–2025 Lab Technology or other complaint names US 8,032,109.
Generated 9/26/2026, 4:47:52 AM
Prior art
Earlier patents, publications, and products that may anticipate or render the claims unpatentable.
I'll search for this exact patent number and each of its cited references. Let me start with the patent itself and its examiner-cited prior art.
I have solid data on the three examiner-cited references. Let me verify the citation list for this exact patent and check the parent/family art.
Prior-art analysis for U.S. Patent No. 8,032,109
Method note. I searched for the exact number 8,032,109 and did not substitute any near-miss number (e.g., 8,549,109, 7,612,109, 8,021,610). The authoritative source for the citation list is the full text of the patent itself (Google Patents, https://patents.google.com/patent/[US8032109](/patent/US8032109)/en), which is the only place the "Patent Citations" list for this exact patent is set out. I was unable to retrieve the file-wrapper office actions (the actual rejection record) in this session, so the claim-mapping below is my own element-by-element inference, not a quotation of the examiner's reasoning. I flag that limitation up front.
1. Effective filing date that controls the § 102 analysis
- Application: US 11/750,281, filed 2007-05-17; a continuation of US 11/182,219 (filed 2005-07-14, issued as US 7,272,402).
- Therefore the presumptive effective filing / priority date for the '109 claims is 2005-07-14 (the parent's filing date), and my § 102(a)/(b)/(e) analysis is keyed to that date.
Consequence: a reference is only § 102 art to the '109 if it published or was filed before 2005-07-14 (or, for on-sale/public-use/§102(b), more than one year before that date). Any reference dated after 2005-07-14 — including several shown on the patent's own page — cannot anticipate the '109.
2. The three "Patent Citations" listed for US 8,032,109
The patent page lists exactly three patent citations, each marked as cited by examiner (*), and no non-patent literature:
| # | Citation | Filed | Published / Issued | Assignee | Qualifies as §102 art to '109? |
|---|---|---|---|---|---|
| A | US 2005/0026650 A1 | 2003-07-30 | 2005-02-03 (issued as US 7,146,153 B2, 2006-12-05) | SBC Knowledge Ventures, L.P. | Yes — §102(a) & §102(e) |
| B | US 2005/0083911 A1 | 2003-10-21 | 2005-04-21 (issued as US 8,027,333 B2, 2011-09-27) | 3Com Corporation | Yes — §102(a) & §102(e) |
| C | US 2010/0233991 A1 | 2009-03-12 (prov. 61/159,522) | 2010-09-16 (issued as US 8,396,445 B2 / 8,938,209 B2) | AT&T Intellectual Property I, L.P. | No — postdates the '109 priority date; not § 102(a)/(b)/(e) art |
Reference A — US 2005/0026650 A1 (SBC Knowledge Ventures)
- Full citation: U.S. Patent Application Publication 2005/0026650 A1, "Provisioning of wireless private access subscribers for location based services," inventor Alicia Marie Russell; App. No. 10/629,807, filed 2003-07-30, published 2005-02-03; issued as US 7,146,153 B2 on 2006-12-05. (A same-titled family member, US 7,542,763, also surfaced; I did not fully verify its lineage, so I rely on the published application and US 7,146,153.)
- URL: https://patents.google.com/patent/US20050026650
- Brief description: A private wireless network (Wi-Fi/Bluetooth access point, e.g., 802.11g) connects a mobile terminal to a transport network. A softswitch or access-point controller holds a database associating a telephone number with the access point's identification (e.g., a MAC address). A call originated from the access point is associated with the E.164 telephone number of the physical transport facility (the copper pair/DSL line) at the customer premises, and that number is placed into call-setup signaling, so that "a location-based service, such as emergency 911, can locate a caller." The access point also (i) detects loss of power/voice-data connection, (ii) runs a routine on power-up to verify the telephone number of the premises, (iii) periodically checks for a dial tone or sends a ping, and (iv) confirms it has not moved by comparing an access-point ID received in response to a test call with a stored access-point ID.
- Potential § 102 relevance:
- Claim 1(a): arguably anticipates — a network element "determines"/associates a telephone number based on the access point ID / physical transport facility of the call (the "subscriber access line identity" analog).
- Claim 1(b)–(c): arguably anticipates — a database lookup maps the number to the premises location for 911 purposes. (Whether the separate "subscriber location query system" is met depends on how the softswitch/database is mapped.)
- Claim 1(d): weak / likely not met. The disclosure does have self-test behavior at the access point (dial-tone check, ping, power-up verification, test call with ID comparison), but it is a connectivity/premises-movement check, not a query to a "subscriber access line module or emergency phone system" returning a yes/no on whether an emergency call can be made. This element is the likely reason the '109 was allowed over this reference.
- Claim 3 / claim 4: same mapping; the system analog is largely present, but the emergency-call-test module + test indicator limitations of claims 3/4 are not clearly disclosed.
- Statutory basis: § 102(a) (published 2005-02-03, before 2005-07-14) and § 102(e) (US application filed 2003-07-30).
Reference B — US 2005/0083911 A1 (3Com Corporation)
- Full citation: U.S. Patent Application Publication 2005/0083911 A1, "IP-based enhanced emergency services using intelligent client devices," inventors David Grabelsky, Michael Homeier, Anoop Tripathi, and Boby Joseph; 3Com Corporation; filed 2003-10-21, published 2005-04-21; issued as US 8,027,333 B2 (2011-09-27). Continuations/divisionals include US 2009/0003535 A1 and US 2011/0267986 A1.
- URL: https://patents.google.com/patent/US20050083911
- Brief description: E-911 for IP-telephony/PBX environments using intelligent SIP client devices. A 911 Location Server maintains an ERL database and a Phone Location database. On a phone's registration, the location server uses the phone's IP and/or MAC address to query a network-management system and determine the managed switch port (and physical connection point) to which the phone is connected, then looks up the associated Emergency Response Location (ERL) and returns ERL/ELIN information to the phone. The phone then can place a 911 call with the ERL/ELIN; the system runs periodic self-consistency / verification checks, and the phone enters a state of "emergency readiness."
- Potential § 102 relevance:
- Claim 1(a)–(c): This is the closest art of the three. Determining a device's location by resolving a physical switch port / MAC address (a link-layer property) and looking up a location record strongly overlaps the "subscriber access line identity → query → subscriber location" structure — including the '109's distinctive "physical or link layer property" limitation in claims 1(c)/3.
- Claim 1(d): weak / likely not met. 3Com's "verification check" is a network-side location self-consistency process, and the phone is "emergency-ready," but there is no disclosure of an emergency call test module in subscriber phone equipment that queries a subscriber access line module or emergency phone system and receives a yes/no response on emergency-call capability.
- Claim 3 / claim 4: the location subsystem of claim 3 is well met; the emergency-call-test module and indicator limitations again appear to be the point of distinction.
- Statutory basis: § 102(a) (published 2005-04-21, before 2005-07-14) and § 102(e) (US application filed 2003-10-21).
Reference C — US 2010/0233991 A1 (AT&T) — ⚠️ a contradiction to flag
- Full citation: U.S. Patent Application Publication 2010/0233991 A1, "Method to implement E911 services in IMS (IP multimedia subsystem)," inventors Dwayne Crawford, Richard L. Khan, Min Lu; AT&T Intellectual Property I, L.P.; App. No. 12/484,514, filed 2009-06-15 (provisional 61/159,522, 2009-03-12), published 2010-09-16; issued as US 8,396,445 B2 and US 8,938,209 B2.
- URL: https://patents.google.com/patent/US20100233991
- Brief description: Generating an E911 profile for a VoIP subscriber, pushing it to an IMS HSS, and having the E-CSCF retrieve it and route the emergency call to the right PSAP; a monitoring component detects location changes from registration info (e.g., IP address), classifying the subscriber as home / visiting-tenant / nomadic.
- § 102 assessment (important): Because its earliest effective date (2009-03-12) is after the '109's 2005-07-14 priority date and even after the '109's own 2007-05-17 filing date, reference C is not prior art to the '109 under § 102(a), (b), or (e), and it cannot anticipate any claim (1–4).
⚠️ Contradiction flagged: The '109 patent page presents US 2010/0233991 A1 as an examiner citation, but by date it cannot be § 102 art against the '109. The most likely explanations are that the citation was aggregated by Google Patents from a later continuation in the same family (e.g., US 12/205,883, filed 2008-09-07, or later) or was an IDS/background citation. The previously generated sections and this section are therefore in tension with the raw Google Patents "Patent Citations (3)" list; I treat the date-based conclusion as controlling and recommend confirming against the '109 file wrapper.
3. Supplementary — most relevant family-cited prior art
These come from the "Family Cites Families" list (references cited in the broader TP Lab family, including the parent '402). They are not '109-specific citations, but several are true pre-2005-art and are the more technically pertinent references. Pre-/post-priority status is marked.
| Citation | Filed | Issued/Published | Assignee | Relevance | § 102 to '109? |
|---|---|---|---|---|---|
| US 6,666,561 B1 — "System for discovering and maintaining geographic location information in a computer network to enable emergency services" | 2001-06-19 | 2003-12-16 | Cisco Technology | Discovering/maintaining host location in an IP network for 911 — direct analog to claims 1(a)–(c)/3 | Yes (§102(a)/(e)) |
| US 7,843,934 B2 — "Methods and apparatus for providing emergency telephone service to IP-based telephone users" | 2002-01-08 | 2010-11-30 | Verizon Services | Emergency service for IP telephony users; location provisioning | Yes |
| US 6,707,888 B1 — "Location evaluation for callers that place emergency telephone calls over packet networks" | 2002-05-06 | 2004-03-16 | Sprint | Evaluating caller location for packet-network 911 | Yes |
| US 6,968,044 B2 — "Telephone emergency response system and method" | 2003-12-05 | 2005-11-22 | Bellsouth | Emergency-call handling/response architecture | Yes |
| US 8,116,720 B2 — "Method and apparatus for emergency call routing using an end node" | 2005-05-06 | 2012-02-14 | Alcatel-Lucent | Emergency routing using an end node | Yes (§102(e), filed 2005-05-06) |
| US 2006/0293024 A1 — "Methods and apparatus for improved 911 support for VoIP service" | 2005-06-23 | 2006-12-28 | Lucent Technologies | 911 support for VoIP | Yes (§102(e), filed 2005-06-23) |
| US 6,134,941 A — access/control for telephone information databases | 1998-01-29 | 2000-10-10 | Bellsouth | Telephone information-database access/control | Yes |
| US 6,473,031 B1 — "Position privacy in an electronic device" | 2000-10-16 | 2002-10-29 | Scott C. Harris | Position/location handling | Yes |
| US 6,973,317 B2 — "Call completion based on movement of mobile station" | 2000-12-18 | 2005-12-06 | Ericsson | Movement-based call handling | Yes |
| US 6,600,914 B2 — emergency call channel allocation | 1999-05-24 | 2003-07-29 | Arraycomm | Emergency-call resource allocation | Yes |
| US 7,711,094 B1 — "E911 location server" | 2005-11-16 | 2010-05-04 | Verizon Data Services | E911 location server | No (post-2005-07-14) |
| EP 1,935,153 A4 — "Emergency call logic for Internet telephony" | 2005-09-22 | 2011-08-03 | Grape Technology Group | Internet-telephony emergency logic | No (post-2005-07-14) |
| US 7,272,402 B1 | 2005-07-14 | 2007-09-18 | TP Lab | The '109's own parent | N/A — same family, not "by another" |
Most relevant of this group for the '109's actual claim language: US 6,666,561 (Cisco) and US 2006/0293024 (Lucent) — both address IP/VoIP emergency-location resolution before the priority date and are the kind of art an examiner would cite against claim 1(a)–(c) / claim 3.
4. Documents on the patent page that are not § 102 prior art to the '109
- US 2009/0147926 A1 / US 8,630,390 B2 (Verizon, "Automated E911 route verification") and US 10,129,390 B2 (Kone, "Processing test calls from elevator emergency telephones") appear under "Cited By" — i.e., they cite the '109. They are later art, not prior art.
- The AT&T '991 publication (Reference C above) is likewise not prior art by date.
5. Bottom line
- Direct "patent citations" for US 8,032,109 = three references (SBC US 2005/0026650; 3Com US 2005/0083911; AT&T US 2010/0233991), all listed as examiner citations, with no non-patent literature.
- Two of the three are genuine § 102 art: SBC (2005/0026650, § 102(a)/(e)) and 3Com (2005/0083911, § 102(a)/(e)). The 3Com reference is the most technically on-point, especially against the "physical or link-layer property… of the subscriber access line module" limitation of claims 1(c) and 3.
- The third (AT&T US 2010/0233991) cannot be § 102 art given the '109's 2005-07-14 priority — a genuine contradiction with how the citation list is displayed; verify in the file wrapper.
- No single listed reference appears to disclose the full claim 1, because the emergency-call-status self-test (the emergency call test module querying the subscriber access line module or emergency phone system, with a returned yes/no response — claims 1(d), 2, 3, and 4) is not clearly taught by SBC or 3Com. The most plausible prosecution posture is § 102 against the location-lookup elements (a)–(c) and § 103 for the remainder; but I could not retrieve the actual office actions to confirm this, so treat the claim-by-claim anticipation calls above as reasoned inferences, not as the examiner's record.
Uncertainty disclosure (unchanged methodology from earlier sections): I could not access the '109 file-wrapper/office actions, the exact rejection grounds, or any non-patent-literature citations in this session. If a definitive § 102/§ 103 prosecution history is material, it should be confirmed against USPTO PatentCenter / Global Dossier for application 11/750,281.
Generated 9/26/2026, 4:48:35 AM
Obviousness
Combinations of prior art that suggest the claimed invention would have been obvious under 35 U.S.C. § 103.
I'll ground the prior-art mapping by confirming the disclosures of the key references cited on the patent page.
Obviousness Analysis — U.S. Patent No. 8,032,109 under 35 U.S.C. § 103
Analysis prepared April 26, 2026. Builds on the prior summary and litigation sections; does not repeat them.
0. Scope and a critical date caveat
This patent has a single effective critical date of 2005‑07‑14 — the filing date of parent application 11/182,219 (which issued as US 7,272,402), to which the '109 application (11/750,281) is a straight continuation claiming the same § 112 support. Because application 11/750,281 was filed 2007‑05‑17, pre‑AIA § 103(a) governs.
The prior-art window therefore closes on 2005‑07‑14. That produces three date problems I want to flag before any charting, because two of the references printed on the '109 Google Patents page cannot be used as prior art:
| Reference (as printed on the '109 page) | Its date | Usable against '109? |
|---|---|---|
| US 2010/0233991 A1 — AT&T, "Method to implement e911 services in IMS" | priority 2009‑03‑12 | No — post‑dates the 2005‑07‑14 critical date by ~4 years. It appears in the "Patent Citations (3)" list, but it is not § 102/§ 103 art against these claims. Its presence is likely an artifact of a later family member's prosecution. |
| US 7,272,402 B1 — TP Lab (same inventors, Ho/Chiu) | 2005‑07‑14 | No — same inventive entity / parent of '109; not "by another." It is the family archive, not art. |
| US 7,602,886 B1 — Sprint, network‑provided location for VoP | filed 2005‑07‑19 | No — five days after the critical date. Do not use, despite its attractive flowchart (source‑IP → access‑network location DB → insert location). |
| EP 1935153 A4 (Grape, 2005‑09‑22); US 7,711,094 B1 (Verizon, 2005‑11‑16) | post‑critical‑date | No. |
The references I actually rely on below all pre‑date 2005‑07‑14 and are § 102(a)/(b) or § 102(e) art:
| Short name | Full citation | Filing/priority | § 102 basis |
|---|---|---|---|
| Cisco '611 | US 6,665,611 B1, Oran & Gai, Cisco Technology — System for discovering and maintaining geographic location information in a computer network to enable emergency services | filed 2001‑06‑19; granted 2003‑12‑16 | § 102(b) |
| SBC '650 | US 2005/0026650 A1 (later US 7,542,763), Russell, SBC Knowledge Ventures — Provisioning of wireless private access subscribers for location based services | filed 2003‑07‑30; pub. 2005‑02‑03 | § 102(b) |
| 3Com '911 | US 2005/0083911 A1 (later US 7,440,442), Grabelsky et al., 3Com — IP‑based enhanced emergency services using intelligent client devices | filed 2003‑10‑21; pub. 2005‑04‑21 | § 102(b) |
| Sprint '888 | US 6,707,888 B1, Cope, Sprint — Location evaluation for callers that place emergency telephone calls over packet networks | filed 2002‑05‑06; granted 2004‑03‑16 | § 102(b) |
| Sprint '931 | US 6,956,931 B1 (continuation of '888) | filed 2004‑01‑14; granted 2005‑10‑18 | § 102(e) |
| Verizon '934 | US 7,843,934 B2 — Methods and apparatus for providing emergency telephone service to IP‑based telephone users | priority 2002‑01‑08 | § 102(e)/(b) |
| Lucent '720 | US 8,116,720 B2 — Method and apparatus for emergency call routing using an end node | priority 2005‑05‑06 | § 102(e) |
| Lucent '024 | US 2006/0293024 A1, Benco et al. — Methods and apparatus for improved 911 support for VoIP service | priority 2005‑06‑23 | § 102(e) |
| Avaya '385 (corroborating) | US 7,130,385 B1 — Advanced port‑based E911 strategy for IP telephony | priority 2004‑03‑05 | § 102(e) |
Sources: Cisco '611; SBC '650; 3Com '911; Sprint '888; Verizon '934; Lucent '720; Lucent '024.
1. The person of ordinary skill (PHOSITA)
A PHOSITA here is a telecommunications/packet‑voice engineer with a B.S. in EE/CS and roughly 3–5 years' experience in telephony signaling, VoIP, and E911/ALI architecture (or equivalent). Critically, this person would know, as of 2005, (i) that the ALI model maps a fixed subscriber line to a street address, (ii) that ALI keyed to a telephone number breaks for phones that move, and (iii) that both the FCC's VoIP E911 First Report and Order (FCC 05‑116, adopted May 19, 2005 — i.e., within weeks before the critical date) and the industry were pressing for location solutions for movable VoIP devices. The '109 specification's own Background section concedes this exact problem and the motivation behind the invention — a near-admission of the "known problem / known need" prong.
2. The pivotal claim-construction point
The narrowing language that matters is in claims 1(c) and 3: the returned "subscriber location comprises a physical or link layer property of the subscriber access line module to which the subscriber access line is coupled."
Under the OSI model, "physical layer" = Layer 1 and "link layer" = Layer 2. Read literally, the claim requires the location value to be bound to a hardware/port/MAC‑layer characteristic of the access module (the '109 specification at Fig. 1 lists the module as an MDF, DSLAM, DLC, CMTS/CDMTS, base station/BSC — i.e., the physical access node). It is not an ALI street‑address lookup keyed by phone number. That construction is important because it maps with unusual precision onto Cisco '611 and SBC '650, both of which key location off a port or a MAC/link‑layer identifier rather than off a directory number.
3. Claim 1 — element‑by‑element mapping
Claim 1 recites a hybrid: a network‑side location lookup (a)–(c) plus a premises‑side emergency‑capability self‑test (d). I address each element and its best mapping.
| '109 Claim 1 element | Primary disclosure | Supporting disclosure |
|---|---|---|
| Preamble — phone coupled to a subscriber access line module via an access line; module coupled to a phone system | Cisco '611: VoIP phone coupled to network switch (the "intermediate network device"/access module) via the LAN; switch connects to the network. SBC '650: mobile terminal → access point → network element (softswitch/AP controller). | Sprint '888: packet phone → "packet network interface." |
| (a) phone system determines a subscriber access line identity | Cisco '611: the switch records the port on which the frame from the phone arrived — a Layer‑1/2 identity of the access module. SBC '650: network element associates a call with a telephone number based on the access point ID (a hardware/MAC address); the DB stores "telephone number and an access point identification." | Cisco '611 also teaches discovery via Cisco Discovery Protocol (CDP) — the access line identity is derived from the physical port binding. |
| (b) phone system sends a query with that identity to a subscriber location query system | Sprint '888 / '931: service node transfers the source packet address to a location server (query); '931 claim 1 recites "transferring the source packet address from the service node to the location server." Cisco '611: the phone/switch performs a look‑up in the geo‑location table; the switch can also be queried by the endpoint. | Verizon '934; Lucent '720 (end‑node‑based emergency routing). |
| (c) receives the subscriber location, comprising a physical or link‑layer property of the access module | Cisco '611 (best): physical coordinates are bound to the port on which the message is received and stored in a "geo‑location table having at least one entry for each port." The reference expressly frames the network in terms of the "data link and physical layers of a communications architecture (i.e., a protocol stack)." SBC '650: the DB correlates location with the access point's MAC/hardware address (a link‑layer identifier). | Sprint '931: location server "transfer[s] an indication of the location." |
| (d) subscriber phone equipment determines whether an emergency call can be made over that access line | SBC '650 (best): the access point / premises equipment contains a software routine that runs on power‑up and periodically to verify the premises' telephone number and check for dial tone; it "periodically determine[s] if there is a dial tone from the voice and data connection for POTS service," and monitors loss of the voice/data connection (PENDING→ACTIVE status). The reference expressly states that "the call is an emergency call" and that confirmation can occur "in response to a test call." | 3Com '911: an intelligent client device (SIP endpoint) participates in E911 — the client can send/receive network messages to obtain/verify what it needs. |
| (d1) an emergency‑call test module sends a query to the access line module or an emergency phone system | SBC '650: the premises routine queries/checks the access line and the network element; the AP controller/softswitch can be pinged. Cisco '611: the VoIP phone "could query the network switch 124 and receive its physical coordinates." | Lucent '024 / Verizon '934 for querying a network E911 element. |
| (d2) receives a response indicating whether or not the emergency call can be made | SBC '650: the access point receives/stores an indication of connection status (dial‑tone present/absent; ACTIVE/PENDING) — functionally an indication of whether an emergency call can be placed. | 3Com '911 client‑network response model. |
No single reference hits all of (a)–(d). Cisco '611 supplies (a)–(c) but not the premises emergency self‑test. SBC '650 supplies the access‑point‑ID location correlation and the premises self‑test but frames the lookup differently (telephone number as the returned data, not a "subscriber location"). Claim 1 is therefore best attacked as an obvious combination, not as anticipated by one reference — which is also why the examiner's two genuinely prior‑art citations (SBC '650 and 3Com '911) were insufficient on their own to force rejection.
4. Grounds of rejection — specific combinations
Ground 1 (primary): SBC '650 in view of Cisco '611
- SBC '650 teaches the premises/access‑point side: associating a call with an access point identifier (a link‑layer MAC address), storing access point ID + telephone number in a database, periodically testing the connection/dial tone, issuing a test call, detecting that the access point has moved, and expressly addressing the emergency call use case.
- Cisco '611 teaches the network side: binding geographic location to the specific port of the access device (a physical/link‑layer property of the access module), maintaining a geo‑location table indexed by port, and letting the endpoint query the switch and receive its location.
- Result: substituting Cisco's port‑bound geo‑location table for SBC's phone‑number/AP‑ID record yields every element of claim 1. SBC supplies (d)–(d2); Cisco supplies (a)–(c), including the "physical or link layer property" limitation.
Ground 2: Sprint '888 / '931 in view of SBC '650 and 3Com '911
- Sprint '888/'931 supplies the service‑node → location server query/response architecture keyed to a device/network identifier, and the routing of emergency calls based on the returned location (directly on point for (a)–(c)).
- SBC '650 supplies the premises self‑test and access‑point‑ID location correlation; 3Com '911 supplies the "intelligent client device" that participates in E911 (element (d)/(d1)).
- Result: the combination reads on claim 1, including the premises emergency test module.
Ground 3: Cisco '611 in view of 3Com '911, further in view of SBC '650
- Cisco '611 supplies the port/link‑layer location lookup; 3Com '911 supplies the intelligent client device performing E911‑related network interaction; SBC '650 supplies the explicit emergency‑capability test of the access connection. Avaya '385 ("Advanced port‑based E911 strategy for IP telephony," 2004) independently corroborates that port‑based E911 was known art at the critical date — a useful secondary reference if a patentee disputes Cisco's port‑mapping teaching. (Note: Avaya '385 is not on the '109's own citation page; I use it only as corroborating context.)
Ground 4 (alternative network‑side references)
For the emergency‑handling/response side, Verizon '934, Lucent '720, and Lucent '024 each teach network elements that resolve E911 location for IP endpoints and pass it to a PSAP/emergency system — usable to supply any element a patentee argues Cisco/Sprint do not, and to reinforce (d1)'s "emergency phone system" alternative.
5. Motivation to combine (the KSR/MPEP 2143 rationales)
A PHOSITA would have combined these references for several independent, articulable reasons:
- Same field, same problem, same solution space. All of Cisco '611, SBC '650, 3Com '911, and Sprint '888 sit in packet‑voice/E911 location for devices that can move. Combining references from the same art to solve the same recognized problem is the paradigm KSR combination. KSR Int'l v. Teleflex, 550 U.S. 398, 417 (2007); MPEP 2143.
- Known technique improving a similar device (MPEP 2143(C)). Using a stable hardware/port identity (Cisco's port, SBC's MAC/AP‑ID) instead of a telephone number to index location is a known technique applied to a known system (the ALI/location database) — predictable result, no new mechanism.
- Market/regulatory force (MPEP 2143(F)). The FCC's May 19, 2005 VoIP E911 order and the well‑documented industry scramble to make movable VoIP/private‑network phones E911‑capable supplied an express design incentive to use the access‑line identity rather than the directory number. The '109 Background itself recites this pressure.
- Design incentive / predictable variation (MPEP 2143(B), (F)). Adding a premises‑side capability test (SBC's dial‑tone/test‑call check) to a system that already resolves location is a predictable, low‑risk enhancement; both references already contemplate the emergency context.
- Reasonable expectation of success. Every element is a routine database lookup, a signaling query/response, or a supervision check (off‑hook/dial‑tone) that was standard telephony practice; no unpredictable technology (e.g., RF triangulation) is required.
- No teaching away. None of the references disparages keying location to an access‑line/port identity; if anything, the art recognizes the superiority of physical/link‑layer binding for movable endpoints (the very premise of Cisco '611 and Avaya '385).
6. Dependent claims 2 and 4, and system claim 3
- Claim 3 (system): The apparatus counterpart maps to the same references in structural form (access line + access line module + phone + location query system + phone system + subscriber phone equipment with emergency call test module). Cisco '611's switch/geo‑location table and SBC '650's access point/controller map onto the recited "subscriber location query system" and modules.
- Claims 2 and 4 (emergency call test indicator set according to the response): This is the weakest element for the patentee. SBC '650 already discloses a status indicator (ACTIVE/PENDING) reflecting the premises connection state. Turning a status light or displaying a message according to an automatically determined result is a predictable design choice — "the use of a known [status‑indicator] technique to improve a similar device in the same way." MPEP 2143(C)/(D); In re Kuhle-line reasoning on indicator implementation. A PHOSITA knowing that users must be warned when E911 is unavailable (the very concern the '109 Background recites) would attach such an indicator as a matter of ordinary engineering. The '109's green/red/yellow/amber LED scheme is thus not patentably distinct from SBC's status signaling plus routine UI design.
7. Secondary considerations (objective indicia)
I find no evidence of nexus‑supported objective indicia:
- Commercial success: none demonstrated; to the contrary, the '109 patent lapsed for nonpayment of maintenance fees effective 2019‑10‑04, and the family was not asserted before lapse (per the prior sections). Weak‑to‑negative signal.
- Long‑felt need / failure of others: the art (Cisco 2001/2003, SBC 2003, Sprint 2002, Avaya 2004) shows the industry was already solving this problem before the critical date — evidence of contemporaneous, not long‑delayed, solutions.
- Unexpected results: none; the claimed result (a correct location returned for a movable phone) is the predictable output of indexing location by access‑line identity.
- Licensing/industry praise: the 2017 transfer to Local Intelligence and back, with no assertion, is not evidence of nexus‑based recognition.
8. Where the obviousness case is weakest (what a patentee would argue)
For a balanced analysis, the counter‑arguments a patent owner would raise:
- "Physical or link layer property" construction. If the patentee persuades a tribunal that this phrase excludes any identifier merely because it is stored at the access device (i.e., that it must be a coordinate or a distinctly physical property), Cisco's port‑bound coordinates still satisfy it — so this argument is unhelpful to the patentee. If anything, the phrase is narrow and Cisco '611 is a bullseye.
- Non‑analogous art? Not available — all references are in the same field.
- "Reference does not teach a separate emergency call test module." A patentee may argue SBC's dial‑tone check is a generic connectivity check, not an "emergency call test module," and that the limitation should be given structure (a dedicated module in subscriber phone equipment). But the specification's own Fig. 6 describes the test as nothing more than querying the module/system or checking for dial tone — i.e., the same generic supervision check. This is a § 112/§ 103 fight the patentee likely loses on the specification's own disclosures.
- § 112 note (flagged, not argued): Claim 1's (d1) refers to "an emergency phone system" while (d2) refers back to "the phone system," and the specification (Fig. 6) describes querying "a phone system 690" (not an "emergency" phone system). That antecedent mismatch is a latent indefiniteness/lack‑of‑written‑description vulnerability independent of obviousness.
9. Bottom line
Claims 1 and 3 are, in my assessment, reasonably likely to be held obvious over the combination of SBC '650 + Cisco '611 (optionally with 3Com '911, Sprint '888/'931, and Avaya '385), with claims 2 and 4 obvious as a predictable indicator design choice over the same art in view of routine user‑interface practice. The strongest single reference for the pivotal "physical or link layer property of the subscriber access line module" limitation is Cisco '611, which binds location to the port of the access device and expressly reasons in OSI physical/data‑link‑layer terms — art the examiner does not appear to have had before it in the '109 prosecution (the prosecution citations shown are SBC '650, 3Com '911, and the post‑dating AT&T '991).
10. Caveats and uncertainty disclosure
- Dates are the load‑bearing facts. My negative prior‑art determinations for AT&T 2010/0233991 (2009), Sprint US 7,602,886 (2005‑07‑19), and the Grape/Verizon 2005 references depend on the priority/filing dates as printed on the patent page; a formal opinion must confirm each reference's actual § 102(e) U.S. filing date in PatentCenter, because a § 102(e) reference is measured by its earliest effective U.S. filing date, not its publication date.
- I reviewed abstracts and substantial excerpts, not complete full texts of every reference (retrieved via the searches cited above). Element attributions for (d1)/(d2) rest on SBC '650's dial‑tone/test‑call/connection‑monitoring passages and Cisco '611's "query the switch" passage; a full‑text and file‑wrapper review is required before relying on this for litigation or an IPR petition.
- Prosecution history not available in this session; I infer the examiner's cited art only from the Google Patents "Patent Citations" list, which may be incomplete or may aggregate citations from related family members.
- This is a technical/legal‑analytical assessment, not a legal opinion. A validity opinion of counsel should independently verify reference dates, claim construction, and objective indicia.
- Practical note: the '109 patent is expired (fee lapse effective 2019‑10‑04), so obviousness matters here chiefly for historical/past‑damages exposure and for assessing the strength of the family, not for prospective injunctive relief.
Generated 9/26/2026, 4:48:48 AM
Extensions
Patent term adjustments, term extensions, continuations, divisionals, family members, and expiration dates.
Derivative works
Defensive disclosure: derivative variations of each claim designed to render future incremental improvements obvious or non-novel.
Keep exploring
Other patents in Wireless Technologies
- US 6801579I'll search for litigation/docket information and verify details for this specific patent number. Let me check for any Federal Circuit docket activity in 2026 and USPTO records specific to this patent. US Patent 6,801,579 B1 — Analyst…
- US 6928292I'll search for authoritative information on this specific patent number and any 2026 CAFC docket activity. Let me verify whether the '292 patent appears in any 2026 Federal Circuit appeal (e.g., the Maxell v. Samsung docket) and confirm…
- US 10965512I'll search for authoritative information on this specific patent number, then synthesize. Let me check for Federal Circuit activity and the IPR outcomes specifically. Let me do one targeted check for any Federal Circuit (CAFC) 2026…
- US 8761739I'll verify the current status of this specific patent before summarizing. Let me verify the IPR outcome and the Federal Circuit matter involving this patent. US Patent 8,761,739 B1 — Analyst Summary Verification note up front: I ran…
- US 12200165I'll search for authoritative information on this specific patent number and any related litigation. Let me search for litigation and CAFC docket activity involving this patent and its assignee. Let me search for the claim text and any…
- US 12368799I'll search for authoritative information on this patent and any related litigation. Let me check the Federal Circuit docket and case details. Let me look for the actual claim text to describe the independent claims accurately. US Patent…
- US 8798953I'll search for authoritative information on US patent 8798953, including any litigation or CAFC docket activity. US Patent 8,798,953 — Analyst Summary Sourcing note I searched for this patent number across general web and patent-database…
- US 6049705I'll search for this specific patent number on USPTO and CAFC dockets. Let me do a couple of targeted checks for any litigation or appeal activity involving this specific patent. Search scope and confidence note I ran targeted searches…