US 8027333

I'll research this patent across USPTO sources and CAFC/litigation dockets. Let me run several searches in parallel.

Let me search for the claim text and any 2026 litigation involving this specific patent.

Summary: US Patent No. 8,027,333 B2

Important note on scope: I was able to verify the bibliographic data, abstract, and specification against the full patent text and multiple sources. However, the authoritative full text you supplied is truncated before the claims section, and my searches for the verbatim claim language returned only third‑party patents (e.g., US 8,768,350; US 8,358,645; US 9,215,169; US 11,463,584; US 11,445,349) that are unrelated to this number. I therefore flag the claim‑level discussion below as inferred from the specification rather than quoted from the claims. I have deliberately not substituted any similar-looking number (e.g., "8,406,733," which is a different, Headwater Research patent).

Bibliographic data (verified)

Chain of title (per the assignment record on the patent page): 3Com Corporation → Hewlett-Packard Company (2010) → Hewlett-Packard Development Company, L.P. (2011–2012) → Hewlett Packard Enterprise Development LP (2015) → Quest Patent Research Corporation (2023-02-16) → Flash Uplink LLC (2024-03-22).

Abstract (verbatim)

"Providing enhanced emergency services (E-911) to an IP Telephony-based PBX or similar system, by utilizing aspects of the intelligence of end-user SIP client devices to address challenges and difficulties associated with E-911-like services in LAN-based telephony environments."

Plain-language overview

The patent addresses E‑911 in enterprise VoIP (SIP) networks. Its core idea is to push emergency‑location intelligence into the phone itself, so the phone—not a central call‑control element—can place a 911 call directly to a PSTN gateway.

Key concepts:

• Location discovery via the first managed switch port. A Location Server learns where a phone is by using the phone's MAC address or IP address to ask the Network Management System which managed access switch port the phone is attached to. That port maps to an Emergency Response Location (ERL).
• Providing ERL/ELIN to the phone. During boot/registration, the phone is given its ERL information — including one or more Emergency Location Identification Numbers (ELINs) — and optionally a default PSTN gateway identifier. This information is delivered in the SIP registration OK message (or during boot), and stored in the phone.
• Direct phone-to-gateway 911 signaling. On a 911 call, the intelligent phone sends a SIP INVITE directly to the PSTN gateway (bypassing the SIP Proxy), carrying the ERL information (in SDP or otherwise). The gateway selects an unused ELIN from the ERL's list and sets it as the outbound ANI.
• No user registration required. The phone reaches an "emergency services readiness" state (with dial tone) using a default profile, so even public phones with no registered user can place 911 calls.
• Call-integrity protections. The phone notifies the SIP Proxy that an emergency call is in progress (or de‑registers the user) so call‑waiting/other features can't interrupt it, and declines to send a SIP BYE (or auto-activates speaker/mic) so the caller cannot tear down the emergency call.
• Gateway-side ancillary functions. The gateway tracks in‑use ELINs, performs ELIN management (including re-assignment when all ELINs for an ERL are busy), produces CDRs, notifies the local security station, and can act as backup storage for phone ERL data.
• Supporting elements: DHCP server, software image download server, NMS (SNMP), ALI Liaison Server (converts ERL data to ALI format), Provisioning Server, Accounting Server, and a Local Security Station.

Independent claims — status and uncertainty

I cannot provide verbatim independent-claim text with confidence. The authoritative text supplied ends mid‑sentence in the "SIP Phone Initialization and Default Registration" section (before the claims), and my searches did not retrieve the actual claim set for 8,027,333.

What I can state with reasonable (not certain) confidence:

• A FreePatentsOnline snippet associated with this patent shows a claim range indicating 14 total claims ("...1-14..."). Treat this as moderate confidence only.
• Based on the SUMMARY section, the likely independent claims cover: (1) a method of providing enhanced emergency services in which an intelligent IP/SIP phone is provisioned with ERL/ELIN information and places an emergency call directly to a PSTN gateway using that stored information; (2) a corresponding intelligent IP phone / client device; and (3) possibly a PSTN gateway that accepts direct SIP INVITEs from phones and manages ELIN assignment. This mapping is inferred, not verified against claim language.

If you need exact claim text, the reliable next step is to pull the granted-claims PDF from the USPTO PatentCenter / Patent Public Search for application 12/204,837, or the FPO/Justia claim section — I could not retrieve it in this session.

Litigation / CAFC docket check (as requested)

• CAFC 2026 dockets: My search for a Federal Circuit 2026 appeal involving 8027333 returned no results. I have no authoritative evidence of any CAFC appeal for this patent.
• District-court NPE activity: Owner Flash Uplink LLC (an NPE, corporate parent Quest Patent Research Corporation) has an active 2026 campaign in the Eastern District of Texas (Judge Robert W. Schroeder, III), including Flash Uplink LLC v. Aikido Security BV (2:26‑cv‑00861, filed 09/21/2026) and Flash Uplink LLC v. Lenovo Group Limited et al. (2:26‑cv‑00072, filed 01/26/2026), plus a case against QNAP Systems.
  • Caution: I could not confirm that U.S. 8,027,333 is among the patents asserted in those suits. A Feb. 11, 2026 Unified Patents note describes a Flash Uplink patent as relating to "updating firmware on disk drives with reduced system downtime" — that is a different patent, so it should not be conflated with 802,733. Assertion of the '333 patent in the 2026 suits is unverified.
• I found no PTAB/IPR, reexamination, or other proceeding specific to 8,027,333.

Bottom line

• Verified: number, title, inventors, filing/issue/priority dates, abstract, assignee history (3Com → HP → HPE → Quest → Flash Uplink), expired status, and the technical subject matter as described in the specification.
• Uncertain / not verifiable in this session: verbatim independent-claim language; the precise total claim count (likely 14, unconfirmed); and whether 802,733 is actually asserted in any 2026 Flash Uplink litigation. I found no CAFC 2026 docket for this patent.

I'll research litigation involving US patent 8027333 using multiple searches.

Let me run more targeted searches on this specific patent's litigation.

Summary of Findings: Litigation Involving U.S. Patent No. 8,027,333

Bottom line: I found no record of any litigation asserting U.S. Patent No. 8,027,333. Based on the searches performed, no district court complaint, ITC action, or Federal Circuit appeal involving the '333 patent is documented in the accessible sources. I want to be explicit that this is a negative finding based on available results, not a certification that no such case exists.

What the '333 patent is

• Patent: U.S. 8,027,333 B2 — "IP-based enhanced emergency services using intelligent client devices"
• Assignee trail: Originally 3Com Corporation → Hewlett-Packard → HP Enterprise → Quest Patent Research Corporation (2023-02-16) → Flash Uplink LLC (2024-03-22)
• Application: US 12/204,837, filed 2008-09-05 (continuation of Ser. No. 10/690,074, filed 2003-10-21)
• Status: Expired – Lifetime (adjusted expiration 2024-08-15)
• Subject matter: E-911 / emergency services for VoIP, using intelligent SIP phone clients and a location server (ELIN/ERL mapping)

Litigation status

No case asserting the '333 patent was found.

Important disambiguation — these search hits involved different patent numbers and must not be attributed to the '333 patent:

Context on the assignee's enforcement activity

Flash Uplink LLC — the current owner of the '333 patent and an NPE affiliated with Quest Patent Research Corporation — launched its first-ever patent suit in January 2026. That campaign (Lenovo, QNAP, Aikido Security) targets the '633 firmware patent, not the '333 E-911 patent. RPX reports that QPRC assigned eight HPE-origin patents to Flash Uplink in June 2023, so the '333 patent could yet be asserted in a future case, but no such suit appears in the sources reviewed as of this search.

High-confidence caveats

• The '333 patent's term expired 2024-08-15, which reduces (but does not eliminate) the incentive to assert it, though past damages remain recoverable for pre-expiration infringement within the limitations period.
• I was unable to directly retrieve the Unified Patents litigation portal page or a full PACER docket search filtered on the '333 patent before reaching the research step limit. Those are the sources most likely to surface a case if one exists.
• If you need a definitive answer, I recommend running a targeted docket search (PACER / Docket Navigator / RPX / Unified Patents Portal) restricted to "8,027,333" as the patent-in-suit, rather than relying on keyword web searches, which returned primarily same-last-three-digit noise.

Would you like me to attempt additional targeted searches (e.g., the Unified Patents case list or a specific docket query) to confirm the negative finding?

I'll start by verifying the canonical source block and then run targeted searches for any PTAB activity on this patent.

Let me search more specifically for this E-911 patent and its current owner.

PTAB Proceedings Analysis — US Patent 8,027,333

Patent: US 8,027,333 B2 — "IP-based enhanced emergency services using intelligent client devices"
Inventors: David Grabelsky, Michael Homeier, Anoop Tripathi, Boby Joseph
Original assignee: 3Com Corporation → Hewlett-Packard → HPE Development LP → Quest Patent Research Corp. (2023-02-16) → Flash Uplink LLC (2024-03-22)
Priority: 2003-10-21 · Granted: 2011-09-27 · Status: Expired – Lifetime, adjusted expiration 2024-08-15

Proceedings overview

Total AIA trial proceedings on file: 0. The USPTO Open Data Portal (ODP) returns no IPR, PGR, or CBM proceeding for US 8,027,333, and independent web searches of PTAB dockets and public decision repositories surfaced no petition, institution decision, or Final Written Decision naming this patent. Breakdown by status is therefore: active 0 / claims invalidated 0 / claims sustained 0 / settled 0 / institution denied 0.

Bottom line for a defendant: no PTAB proceeding has ever narrowed this patent — all claims remain UNTESTED at the Board, so there is no FWD to point to as invalidating art and no § 315(e) estoppel to exploit. But the more important fact is the calendar: the patent reached its adjusted expiration on 2024-08-15. As of today (2026-09-30) it is expired, so no prospective infringement (and no injunction) is available; exposure is limited to past damages inside the 35 U.S.C. § 286 six-year lookback window. The absence of any PTAB challenge is itself a signal — this patent was never a high-priority NPE monetization target, and the litigation activity that did materialize around Flash Uplink's portfolio centered on a different patent (see below).

Proceeding-by-proceeding

None. There are no proceedings to enumerate. I will not invent proceeding numbers, panels, or dispositions.

What I checked (and did not find):

• PTAB E2E / USPTO PTAB Decisions — no record for 8,027,333.
• Patent Trial & Appeal Board public petition repository (ptacts.uspto.gov) — no petition naming this patent.
• General web search on "8,027,333," "8027333," "IP-based enhanced emergency services" + IPR/PTAB — no AIA trial hit.

False positives I explicitly excluded (do not conflate these with 8,027,333):

• U.S. 8,919,333 (MCP IP, LLC) — Bowtech, Inc. v. MCP IP, LLC, IPR2019-00386. Different patent, different technology.
• U.S. 8,630,234 — IPR2022-00638 (T-Mobile). Different patent.
• U.S. 9,917,563 — IPR2025-00372 (Kangxi v. Skyworks). Different patent.
• The medical-device "'333 Patent" in Becton Dickinson-style papers and the Shire/Fresenius '333 — all different patents.

Litigation / ownership context (relevant to defensive posture)

The structured PTAB block and my searches agree there is no PTAB activity, but there is meaningful non-PTAB activity worth flagging:

I could not confirm that 8,027,333 has ever been asserted in litigation. The evidence indicates Flash Uplink's campaign to date has targeted the firmware patent. Flagging this as an open item to verify against PACER/Docket Navigator before relying on it.

Strategic summary

Claim status. Every claim of 8,027,333 is UNTESTED — none canceled, none sustained, because no AIA trial was ever instituted. There is no narrowing IPR history to work with, and equally no adverse FWD holding any claim patentable that a patent owner could wave at you. Two independent clocks dominate the analysis: (1) the adjustment/term clock — adjusted expiration 2024-08-15 means the patent is expired; and (2) the § 286 lookback clock — damages, if any, reach back only six years from the date a complaint was (or is) filed, and only for conduct before expiration. A defendant today is defending against a past-damages-only theory, which materially changes both settlement leverage and the value of an invalidity challenge.

Estoppel landscape. There is no § 315(e)(2) estoppel of any kind, because no IPR/PGR ever reached a final written decision. For a defendant currently (or prospectively) facing assertion, that means the full prior-art field is open. Practical vehicle constraints: PGR is unavailable (this is a pre-AIA, 2003-priority patent — no first-inventor-to-file applicability and the 9-month window is long gone); CBM is unavailable (the transitional program sunset for new petitions on 2020-09-16, and the E-911/telephony claims are a poor fit for CBM eligibility anyway). That leaves IPR under §§ 102/103 and ex parte reexamination. Note that IPR against an expired patent is permissible where the claims remain enforceable for past damages, and the Board construes expired claims under the Phillips framework rather than the AIA's broadest-reasonable-interpretation standard — a subtle but useful difference for claim-construction arguments.

Pattern signals. No repeat petitioner, no patent-owner PTAB appeal history, no defensive aggregator on this patent. The notable pattern in the family is ownership-driven: a 3Com→HP→HPE lineage culminating in an NPE spinoff (Flash Uplink, a Quest Patent Research entity) in 2024 — coinciding with expiration. Unified Patents is active against a sibling Flash Uplink patent via reexam, indicating that the portfolio (not 8,027,333 specifically) is under scrutiny. Given expiration, the rational challenger strategy shifts from IPR to past-damages invalidity defenses and § 286 damages cutoff arguments.

Recommended next steps

1. Confirm the expiration date and the § 286 window first. Pull the patent's entire file wrapper and term-adjustment record (Google Patents US8027333B2; FreePatentsOnline). The decisive question is whether any asserted claim can support recovery for conduct before 2024-08-15 within six years of the complaint date.

2. There is no FWD to cite. Because no AIA trial was ever instituted, you cannot point to an invalidation. Your validity attack must be built from scratch — likely § 102/§ 103 art around SIP E-911 (e.g., the Schulzrinne IETF drafts and Taylor "SIP Emergency Assistance Scenarios" already of record), filed either as an IPR or, given expiration economics, advanced primarily as an invalidity defense/reexam.

3. Verify whether 8,027,333 has in fact been asserted in any Flash Uplink complaint (the public complaints I found plead a different patent). If it has not, the practical posture for most defendants is low urgency until a demand materializes.

4. If assertion occurs, weigh IPR timing against the § 315(b) one-year bar from service of the complaint, and note the statutory 1-year trial clock from institution. But recognize the economics: an IPR on an expired patent is often a defensive-settlement tool rather than a stay-generator, since forward-looking relief is off the table.

5. Set a verification reminder. This analysis rests on the ODP block (no AIA proceedings) plus searches. If a petition is filed after the most recent ODP ingest, it would not yet appear — re-check PTAB E2E and PTAB Decisions before finalizing any litigation position.

Confidence note: I have high confidence in the "no PTAB activity" conclusion (corroborated by both the structured ODP data and independent searches) and in the expired/assignment facts (directly from the patent record). I have lower confidence on the negative claim that 8,027,333 has never been litigated — that is an absence-of-evidence finding and should be confirmed against PACER or a commercial docket service rather than treated as established.

I'll research the assignment record for this patent across USPTO Assignment Search, Google Patents legal events, and NPE directories. Let me run parallel searches.

Let me dig deeper for the specific reel/frame records and the QPRC/HPE purchase agreement.

Research note on source completeness

I could not retrieve the full reel/frame set for this patent in this session. The USPTO Assignment Center / assignment.uspto.gov interfaces could not be queried directly, and secondary sources surfaced only partial reel/frame data. Rather than fabricate reel/frame numbers, I have reconstructed the chain from (a) the Google Patents legal-events record embedded in the authoritative patent text you supplied, and (b) one reel/frame explicitly referenced in that record (Reel 027329). Where a reel/frame is not evidenced, I say so. All dated assignment events below are real and sourced; the reel/frame fields are the gap.

Verification link (search by patent number): https://assignment.uspto.gov/patent/index.html → query 8027333; and https://assignmentcenter.uspto.gov/

Inventors

Unusual-pattern check: The "all inventors leave within 12 months of filing" tell is not present / no evidence. The parent was filed 2003-10-21; 3Com was not acquired by HP until 2010 (≈7 years later), and no inventor-departure data is in the record. I have no evidence of a near-filing inventor exodus that would signal a portfolio fire-sale. Employer attribution to 3Com is based on the co-filed sibling application and the 3Com-name cohort, not on an inventor-declaration document I could pull.

Original assignee

• Named on the issued patent: Hewlett-Packard Company (per the Google Patents "Original Assignee" field and the FPO record, whose correspondent of record is listed as "Hewlett Packard Enterprise").
• True originating filer: 3Com Corporation — the 2003 parent (Ser. No. 10/690,074) was a 3Com filing; the 2008-09-05 continuation (Ser. No. 12/204,837) post-dates HP's acquisition of 3Com and was prosecuted by HP. The "Hewlett-Packard Company" original-assignee label is the post-merger assignee of record, not the 2003 filer.
• Primary line of business: 3Com was a networking-equipment maker (Ethernet switches, routers, and enterprise IP telephony — VCX/NBX IP-PBX product lines). The '333 patent (SIP-based E-911 for enterprise IP phones) plausibly read on 3Com's enterprise voice products, but I cannot confirm a shipping embodiment from the record — treat "shipped a product embodying the claims" as moderate confidence, unverified.
• Current status: 3Com as a legal entity was absorbed by Hewlett-Packard in 2010 (merger closed April 2010); the 3Com brand is now controlled by HP/HPE. The patent itself is Expired – Lifetime (adjusted expiration 2024-08-15).

Assignment timeline

Chronological. Conveyance types are as recorded on the patent page. Reel/Frame is given only where evidenced; otherwise marked "not retrieved."

• 2010-07-06 (recorded; execution date not shown) / Reel not retrieved

  • Conveyance: Merger (see document for details)
  • Assignor: 3Com Corporation
  • Assignee: Hewlett-Packard Company
  • Correspondent: not captured this session. (Related-record clue: a companion 3Com→HP chain-of-title recording for the Grabelsky application Ser. No. 10/671,375 is at Reel 024630/Frame 0820, filed 2011-05-31 — plausibly the same merger recording, but I cannot confirm it covers the '333.)
  • Context: internal reorg — HP's acquisition of 3Com; 3Com's portfolio absorbed into HP.

• 2010-07-15 (recorded) / Reel not retrieved

  • Conveyance: Corrective Assignment (correct the attached)
  • Assignor: 3Com Corporation
  • Assignee: Hewlett-Packard Company
  • Correspondent: not captured this session.
  • Context: internal reorg — administrative correction to the merger recording.

• 2011-12-06 (recorded) / Reel 027329 (Frames 0001 and 0044) — this reel/frame is expressly stated in the patent's own legal-events record as the location of the earlier recording referenced by the corrective assignment below

  • Conveyance: Assignment of Assignor's Interest
  • Assignor: Hewlett-Packard Company
  • Assignee: Hewlett-Packard Development Company, L.P.
  • Correspondent: not captured this session.
  • Context: internal reorg — HP entity restructuring (HP Co. → HP Development Co., L.P.).

• 2012-05-01 (recorded) / Reel 027329 (corrective of the frames above)

  • Conveyance: Corrective Assignment — "previously recorded on Reel 027329 Frame 0001 and 0044"
  • Assignor: Hewlett-Packard Company
  • Assignee: Hewlett-Packard Development Company, L.P.
  • Correspondent: not captured this session.
  • Context: internal reorg — correction of the 2011-12-06 recording.

• 2015-11-09 (recorded) / Reel not retrieved

  • Conveyance: Assignment of Assignor's Interest
  • Assignor: Hewlett-Packard Development Company, L.P.
  • Assignee: Hewlett Packard Enterprise Development LP
  • Correspondent: not captured this session.
  • Context: internal reorg — the 2015 HP split into HP Inc. and Hewlett Packard Enterprise; the patent lands with the HPE side.

• 2023-02-16 (recorded; executed July 2022 per QPRC's SEC Form POS AM) / Reel not retrieved

  • Conveyance: Assignment of Assignor's Interest (see document for details)
  • Assignor: Hewlett Packard Enterprise Company and Hewlett Packard Enterprise Development LP
  • Assignee: Quest Patent Research Corporation (QPRC)
  • Correspondent: not captured this session.
  • Context: transfer-to-asserter / portfolio monetization — HPE sold a patent package to publicly traded NPE QPRC. Execution/recording gap flagged: QPRC's SEC filing describes a July 2022 purchase agreement; the USPTO record date is 2023-02-16.

• 2024-03-22 (recorded; executed 2023-06-15 per RPX) / Reel not retrieved

  • Conveyance: Assignment of Assignor's Interest (see document for details)
  • Assignor: Quest Patent Research Corporation
  • Assignee: Flash Uplink LLC
  • Correspondent: not captured this session. Security-agreement contact found: Jon C. Scahill, QPRC, 411 Theodore Fremd Ave., Suite 206S, Rye, NY 10580 (jscahill@qprc.com) appears as the QPRC contact on a Flash Uplink LLC Patent Security Agreement — i.e., the same person/address for the parent NPE and its subsidiary LLC.
  • Context: transfer-to-asserter / securitization — QPRC dropped eight HPE-origin patents (per RPX) into subsidiary Flash Uplink LLC; Flash Uplink later pledged the portfolio under a patent security agreement.

Flagged contradiction vs. your prior section: Your earlier summary lists the QPRC→Flash Uplink event dated 2024-03-22. RPX reports the execution as 2023-06-15. These are different dates (execution vs. recording) and should not be read as two separate transfers. Likewise HPE→QPRC: RPX says "summer of 2022," SEC says July 2022, USPTO shows 2023-02-16 recorded. Execution ≠ recording in both steps.

No separate inventor→3Com assignment appears in the retrieved record (consistent with an at-filing assignment that predates this dataset).

Timeline diagram

timeline
    title Ownership of US 8027333
    2003 : Filed by 3Com Corporation
    2010 : 3Com merges into Hewlett-Packard
         : Corrective merger filing recorded
    2011 : Assigned to HP Development Company
    2012 : Corrective assignment recorded
    2015 : Assigned to HPE Development LP
    2022 : HPE agrees to sell package to QPRC
    2023 : QPRC assignment recorded
         : QPRC assigns to Flash Uplink LLC
    2024 : Flash Uplink recording
         : Adjusted term expiration

NPE / troll-pattern signals

1. Shell-entity transfer — PRESENT. Operating-company patent moved to licensing-only vehicles in two hops: HPE → Quest Patent Research Corporation (recorded 2023-02-16) → Flash Uplink LLC (recorded 2024-03-22; executed 2023-06-15). Flash Uplink is a single-purpose licensing LLC whose contact of record is the QPRC address (411 Theodore Fremd Ave., Suite 206S, Rye, NY) and QPRC's Jon C. Scahill — supported by the Flash Uplink Patent Security Agreement. This is a name-plus-evidence finding, not a name-only inference.

2. Known asserter in the chain — PRESENT. Current assignee Flash Uplink LLC is described by Unified Patents (Feb 11, 2026 and Jun 19, 2026 posts) as "an NPE and entity of Quest Patent Research Corporation"; RPX (Jan 24, 2026) reports QPRC assigned eight HPE-origin patents to Flash Uplink and that Flash Uplink filed its first suit against Lenovo (E.D. Tex. 2:26-cv-00072), with additional suits against QNAP Systems and Aikido Security BV. Caveat: those suits assert U.S. 7,426,633 (disk-drive firmware), not the '333 — but the entity is a confirmed NPE/high-frequency asserter, which is the signal.

3. Repeat correspondent across the chain — UNCLEAR (single data point only). The only correspondent evidence retrieved is Jon C. Scahill (QPRC, Rye, NY) on the Flash Uplink security agreement. I did not recover the recorded correspondent for the 2023-02-16 or 2024-03-22 assignments, and a single appearance is not a finding per the signal's own rule. Flagging for follow-up: pull the Assignment Center correspondent field for both QPRC-era reel/frame entries; if Scahill (or one firm) recurs, this upgrades to PRESENT.

4. Cascading transfers — PRESENT. Seven recorded events across the chain, and the decisive two (HPE→QPRC, QPRC→Flash Uplink) occur within ~13 months of each other (2023-02-16 → 2024-03-22, with 2023-06-15 execution). Common-address/common-officer link: QPRC address and QPRC officer on Flash Uplink documents.

5. Pre-litigation transfer — NOT PRESENT (as to this patent). No suit asserting the '333 is documented; Flash Uplink's first suit (Jan 2026) is on the '633. The QPRC→Flash Uplink transfer is not shown to be coupled to a '333 complaint.

6. Bankruptcy fire-sale — NOT PRESENT. 3Com exited via an HP merger (April 2010), not bankruptcy; the HPE→QPRC step was a direct negotiated purchase (SEC: July 2022 purchase agreement), not a court-supervised sale.

7. Privateering — UNCLEAR. HPE sold the package to an NPE, but there is no evidence (SEC disclosure, Patent Progress/EFF coverage) that HPE retained a license-back or is directing assertion against competitors. Do not assume privateering from the sale alone.

8. Defensive aggregator — NOT PRESENT. Chain terminates at Flash Uplink LLC (QPRC subsidiary), not at RPX, AST, LOT Network, Unified Patents, or OIN.

Verdict

NPE — high confidence.

Two or more strong signals are met: (i) a shell-entity transfer — the patent leaves operating company HPE for QPRC (recorded 2023-02-16, executed July 2022) and then for single-purpose Flash Uplink LLC (executed 2023-06-15, recorded 2024-03-22), both tied to the Rye, NY QPRC address and QPRC's Jon C. Scahill; and (ii) a known asserter in the chain — Unified Patents and RPX independently classify Flash Uplink LLC as "an NPE and entity of Quest Patent Research Corporation," with active 2026 suits against Lenovo, QNAP, and Aikido Security (albeit on the sibling '633 patent, not the '333). Cascading transfers inside ~13 months reinforce the pattern. The '333 patent's term expired 2024-08-15, so any assertion would be for past damages only.

Verification: pull the reel/frame + correspondent fields for the two QPRC-era records at https://assignment.uspto.gov/patent/index.html (query 8027333) — those are the two fields I could not confirm and the ones most likely to upgrade signal #3.

Integrity caveats (repeat, explicitly)

• Reel/frame numbers for six of the seven events are unknown to me and are left as "not retrieved" rather than invented. Only Reel 027329 (Frames 0001/0044) is evidenced, and that comes from the corrective-assignment caption in the patent's own legal-events record.
• Reel 024630/Frame 0820 (3Com→HP) is a related-record clue from a companion Grabelsky/3Com application, not confirmed to cover the '333.
• The Flash Uplink security agreement (credit line against the portfolio) is a securitization signal, but I retrieved only the contact/parties, not the agreement's assets schedule, so I cannot confirm the '333 is listed on it.

I'll research the prior art cited on the face of US 8,027,333 and related family members. Let me run several searches in parallel.

I found the claim text on Justia. Now let me retrieve the cited references lists from the patent's front page and family members.

Scope and verification status — read this first

I hit the research step limit before I could pull the front‑page "References Cited" list for US 8,027,333. Several of my queries returned unrelated patents (e.g., a medical‑supply patent family under PCT/US2009/033811, and various lens/downhole patents), and I will not attribute any of those to the '333 patent. Per your strict rule, I have not substituted or auto‑corrected any number, and I have not invented citations to fill the gap.

So the honest position is:

• What I newly verified in this pass: the verbatim claim text of US 8,027,333 (claims 1–12 in full, claim 13 partially) from the Justia patent page. This fixes the "inferred / unverified" flag raised in the previous two sections.
• What I could NOT retrieve: the examiner's citation list and the applicant's Information Disclosure Statement references printed on the face of the '333 patent. I therefore cannot give you a citation‑by‑citation § 102 mapping against verified references.

I flag one small metadata inconsistency: the framing says "Current Date: April 26, 2026," while the session header says 2026‑09‑30. This does not change the prior‑art date math below.

1. Verified claims of US 8,027,333 (now confirmed, not inferred)

Source: https://patents.justia.com/patent/20090003535#4 (claim section reproduced for the '333 grant). The earlier sections' caution that claim text was "inferred" should be superseded by the following:

Claim 1 (independent, method):

"A method of configuring a packet based phone for initiating an emergency call in a packet based network, comprising:

• responsive to sending a request from the packet based phone to register for communication services in the packet based network, receiving at the packet based phone a registration response from the packet based network that includes an ERL record, said ERL record being associated with the phone's emergency response location; and
• transmitting from the packet‑based phone at least a portion of the ERL record as part of an emergency call setup process."

Dependent claims 2–12 (verbatim, abbreviated):

• 2 — the packet based network is an IP network.
• 3 — the ERL record includes one or more ELINs, and the phone transmits at least one ELIN.
• 4 — the one or more ELINs are transmitted using SIP.
• 5 — the packet‑based phone uses SIP.
• 6 — the ELIN is transmitted in an SDP contained in a SIP INVITE message.
• 7 — the phone transmits at least a portion of the ERL record to a PSTN gateway device.
• 8 — the phone selects the PSTN gateway device according to information in the ERL record.
• 9 — the portion comprises an ERL ID, and the gateway inserts a corresponding ELIN into the caller‑identification portion of an outgoing 911 call.
• 10 — the portion comprises one or more ELINs, and the gateway inserts one into the caller‑ID portion.
• 11 — the PSTN gateway maintains a list of ELINs associated with active outgoing 911 calls and selects ELINs for new 911 calls.
• 12 — the phone transmits at least a portion of the ERL record to a call signaling device.
• 13 — (partial, truncated at "The method of…") — further dependent limitation; text not fully retrieved.
• 14 — not retrieved. The earlier indication of a 14‑claim total remains moderate confidence, consistent with claims 1–13 being present.

This resolves the earlier uncertainty: claim 1 is a method of configuring the phone whose gist is (i) receiving the ERL record in a registration response, and (ii) the phone itself transmitting ERL data as part of emergency call setup. There is no verified independent claim for a "PSTN gateway" or a standalone "phone" apparatus in the retrieved text — the earlier three‑independent‑claim hypothesis is not supported by what I now have (claims 1–12 are a single method chain).

2. Element‑by‑element anticipation framework for claim 1

Any § 102 reference must disclose all three limitations:

Element B + C together are the crux: prior art in which the server/gateway holds the location and injects the ELIN (the classic PBX/ALI model, and the Cisco model described in the spec) does not anticipate, because the phone does not receive the ERL record in a registration response and does not originate the ERL in call setup.

3. Prior art on the face of the specification (applicant‑acknowledged)

The specification itself identifies the closest known art. These are product/system references, not patent numbers — I have not converted them into patent citations because I could not verify any:

1. Cisco Emergency Responder (spec: "utilize a centralized device (e.g., the Emergency Responder node) to query a network device (e.g., the CallManager) to obtain a list of registered phones. The central device then queries individual switches to determine which physical ports are associated with those phones").

   • Date/relevance: product available from Cisco around 2003, i.e., potentially § 102(a)/102(b) art relative to the 2003‑10‑21 priority date.
   • § 102 hit? No, not on claim 1 — it is server‑side location tracking; the phone does not receive an ERL record in a registration response and does not transmit ERL data at call setup. It is relevant as § 103 background, not § 102 anticipation.

2. Cisco "Emergency Response E‑911 system" (spec: multiple ELINs assigned per multi‑station ERL, statistically dimensioned).

   • § 102 hit? Anticipates none of claims 1–12 as a whole; it relates to multi‑ELIN provisioning (cf. claims 9–11 concepts), but lacks the phone‑centric registration‑response delivery and phone‑originated ERL transmission.

3. APCO E‑911 terminology web page (www.apco911.org/about/pbx/index.html), reproduced in the spec's "Emergency E911 Terminology."

   • § 102 hit? A printed publication as to definitions (ELIN, ERL, PSAP, ALI); cannot anticipate any claim — it discloses no phone/gateway architecture.

4. Family‑level prior‑art leverage (verifiable cross‑references)

Because I could not read the '333 face citations, the most reliable next step is to pull the citation lists of the same‑family documents, which typically share the examiner's art:

• US 2005/0083911 A1 — publication of the parent Ser. No. 10/690,074 (filed 2003‑10‑21). Justia: https://patents.justia.com/patent/20050083911
• US 2009/0003535 A1 — publication of the '333 application (12/204,837). Justia: https://patents.justia.com/patent/20090003535
• US 8,509,225 B2 — sibling continuation (Ser. No. 13/178,911). This case, granted later, will carry its own examiner citations and any applicant IDS, often overlapping the '333 art.

I did not retrieve reference lists for any of these in this session; I am naming them as the highest‑yield sources, not as a citation list.

5. What I cannot yet do (and will not fake)

• I cannot name specific patent numbers as "cited references" for 8,027,333, because I did not obtain the front‑page "References Cited" table.
• I cannot assert any reference "anticipates claim X under § 102" without the verified reference and its disclosure — doing so would be fabrication.

To complete the deliverable you asked for, run these targeted retrievals:

1. Google Patents "Citations" and "Cited By" tabs for patents.google.com/patent/US8027333B2/en (the API/section labeled Patent Citations).
2. USPTO Patent Public Search / PatentCenter for application 12/204,837 → "References Cited" (US Patents, Foreign Patents, Other Publications) and the IDS/892 forms.
3. The PCT/ISA search report for the family's international counterpart of Ser. No. 10/690,074 (the parent's PCT filing), which lists the examiner's X/Y/A‑category references — usually the best single source of § 102 art.

Once those lists are in hand, map each reference against the three element rows in § 2 above (Element A/B/C), which is the exact test that separated the applicant's claims from the Cisco server‑centric art.

If you can paste the "References Cited" table from PatentCenter (or allow another search round), I can produce the full per‑reference citation/date/description/§ 102‑claim mapping you requested.

I'll first try to retrieve the claim text and the actual prior-art references cited on the face of this patent, since the supplied text is truncated before the claims and before any "References Cited" list.

Let me try to retrieve the actual claim language and the cited-reference list for this patent.

Important scope and evidentiary caveats (read first)

Before any § 103 analysis I have to be explicit about two gaps, because they change how much weight you can put on what follows:

1. The supplied "page" contains no References Cited / Prior Art list. The full text you provided is truncated mid-sentence in the "SIP Phone Initialization and Default Registration" section — before the claims and before any front-page reference list. Google Patents' "Prior art keywords" field (phone, erl, call, sip, record) is an algorithmic keyword string, not a citation list, and must not be treated as prior art.
2. Verbatim claim text is still unavailable. This confirms (rather than contradicts) the limitation already flagged in the prior sections of this analysis. I could not retrieve the granted claims for US 8,027,333 in this session either. All claim-level mapping below is therefore keyed to the disclosed embodiments in the specification and is labeled as inferred; it is not a claim-chart.

Because of (2), everything below is a provisional obviousness assessment of the disclosed subject matter, not a formal invalidity opinion. A real § 103 opinion requires (a) claim construction, (b) a defined POSITA, and (c) verified prior-art dates.

1. The effective priority date, and why it constrains the art

• Effective filing date: October 21, 2003. The '333 patent is a continuation of App. Ser. No. 10/690,074, filed 2003-10-21 (stated verbatim in the supplied text: "This application claims priority from and is a continuation of U.S. application Ser. No. 10/690,074, which was filed on Oct. 21, 2003…"). The 2008-09-05 filing date of the continuation does not move the art cutoff; only the 2003 date matters.
• Consequence: a large amount of the E-911/VoIP material that surfaces in searches — AudioCodes ELIN Gateway manuals, the Cisco Collaboration SRND E911 chapter (2018), Microsoft Lync/Teams E9-1-1 documentation, and the 2005 Korean survey of VoIP E-911 (ETRI Electronics and Telecommunications Trends), all of which describe "SIP INVITE carrying location → ELIN gateway sets ANI → PSAP callback via ELIN table" — post-date the priority date and are therefore not § 102/§ 103 prior art against the '333 patent. They are useful only as evidence of what a POSITA would have regarded as conventional in 2003, and even that use requires care.

2. What prior art is actually "on this page"

2a. Applicant-admitted prior art inside the Description of Related Art

The specification's background is unusually candid and itself supplies the strongest art. It literally names reference systems as known solutions:

An applicant's characterization of a system as an existing solution is usable as an admission of what was known, even if the exact public date of vendor documentation needs independent proof.

2b. Cited non-patent literature (moderate confidence)

A FreePatentsOnline snippet for this patent surfaced one cited NPL reference:

H. Schulzrinne (Columbia U.), "Providing Emergency Call Services for SIP-based Internet Telephony," IETF Internet-Draft, July [2001] — surfaced at https://www.freepatentsonline.com/8027333.html.

I flag this as moderate confidence: it appeared in a search snippet, not in a document I retrieved in full, and I could not independently confirm the exact draft revision or its publication date. If genuine and dated July 2001, it predates the 2003-10-21 priority date by two years and is squarely available art. Its subject matter — how SIP phones and SIP infrastructure should handle emergency calls — places it directly against the phone-side and proxy-side limitations. Verify before relying on it.

2c. A same-family document that is not art

The search surfaced US 2005/0083911 A1, whose text contains paragraphs [0046]–[0059] that are verbatim identical to the '333 specification's background. This is the pre-grant publication of the parent application 10/690,074. It is the same invention, not prior art to the '333 patent (§ 102(b)(2)/§ 103(c) common-ownership and same-family logic). Do not cite it against the '333 patent.

2d. Related art I saw but cannot yet clear as prior art

• US 7,627,091 B2 (Erb) — "mapping a selected Network Layer address against a set of Network Layer addresses to determine an ELIN", claims 1–21 (IP address/subnet → ELIN, ELIN common to devices in an ERL, registering triggers mapping, forwarding ELIN to PSAP). Facially this reads on the "ERL/ELIN mapping" concept. However, it issued 2009-12-01; I could not confirm its filing/priority date in this session. If its priority post-dates 2003-10-21 it is not art. US 7,778,406 B2 (Erb) likewise discusses ELIN/CESID at the phone/PBX. Both need date verification before use.
• US 8,428,049 B2 and EP 1 850 532 A1 (emergency LAN/VLAN broadcast schemes) — both are 2006-era, i.e., post-date the '333 priority date and are not art.

Net prior art available from "this page": the PSTN E-911 framework (admitted), Cisco Emergency Responder (admitted), Cisco's multi-ELIN-per-ERL E-911 technique (admitted), MAC/IP→switch-port→location discovery via NMS/SNMP (admitted, HP OpenView named), DHCP/SIP-based phone provisioning (admitted as conventional), and — if confirmed — the Schulzrinne IETF draft.

3. Inferred claim 1 and element-by-element art mapping

Labeled inferred; derived from the SUMMARY and FIGS. 4–7 call flows in the supplied text. A plausible independent method claim recites:

1. receiving, at a network element, an identifier (IP or MAC address) of an IP phone;
2. determining, from the identifier, a physical switch port / ERL of the phone (via NMS);
3. providing ERL information including one or more ELINs (and optionally a default gateway identifier) to the phone;
4. storing the ERL/ELIN information in the phone;
5. at the phone, upon a 911 trigger, sending call-setup signaling (SIP INVITE) carrying the ERL information directly to a PSTN gateway, bypassing the call-processing proxy;
6. at the gateway, selecting an unused ELIN and setting it as the outbound ANI to the PSTN.

Observation: every element maps to either (i) applicant-admitted prior art or (ii) a basic, pre-2003 SIP capability. That is the structural reason the claims are vulnerable — the patent's novelty largely resides in where the intelligence sits (phone) and which path the INVITE takes (direct to gateway), not in new signaling or new PSTN interfaces.

4. Combinations that would render the subject matter obvious

POSITA definition (proposed): a bachelor's degree in EE/CS (or equivalent) with ~2–4 years' experience designing enterprise VoIP/SIP telephony, including familiarity with RFC 3261 SIP, DHCP auto-provisioning of IP phones, SNMP/NMS topology discovery, and PSTN E-911/ALI/ELIN concepts. This is a routine-skill level; no extraordinary creativity is required for any of the combinations below.

Ground 1 — Cisco Emergency Responder + Cisco multi-ELIN E-911 + conventional SIP gateway signaling

• Teaches/renders obvious: elements 1–3 and 6 directly; elements 4–5 by routine SIP engineering.
• Motivation: (a) the specification itself frames the problem as the centralized responder's polling cost — "the central device must repeat this process continuously. If the time between queries is short, the amount of network traffic can become large, and if the time interval is too long, the risk of improperly reporting the ERL increases." Reducing that polling/reliance is an express, articulated engineering goal. (b) The spec also identifies reliance on the call-control element as a failure point and the cost of redundant call-control nodes and same-site proxy placement. Dereferencing the phone (it holds its own ERL) and letting it signal the gateway directly addresses both. This is the classic KSR posture: a known problem in the field, a finite number of identified, predictable solutions, and a design incentive to eliminate a single point of failure and a recurring WAN cost.
• Predictable result: the phone's ERL comes from the same switch-port mapping; the ELIN list comes from the same per-ERL pool; the gateway already has to select an ELIN and set the ANI. Moving that logic so the phone carries the ERL to the gateway changes no PSTN-side component.

Ground 2 — Cisco Emergency Responder + Cisco multi-ELIN E-911 + Schulzrinne (if verified)

• Adds: the teaching that SIP endpoints/UA-side logic should participate in emergency call setup and carry emergency/location context toward the PSAP path.
• Motivation: express design guidance in the art that SIP clients have a role in emergency calling, combined with the admitted multi-ELIN pool and admitted switch-port location discovery. Combining produces a phone that stores its ERL/ELIN set and uses it at emergency-call time.

Ground 3 — MAC/IP→port discovery (NMS/SNMP, HP OpenView) + DHCP/SIP auto-provisioning of IP phones

• Teaches: delivering per-device configuration to a phone at boot/registration (DHCP custom options or the SIP 200 OK).
• Motivation: the phone's ERL must be kept current as phones move; auto-provisioning is the conventional mechanism for pushing per-device parameters to IP phones. A POSITA looking to give a phone its ERL would naturally reuse the existing provisioning channel (boot or REGISTER/OK) rather than invent a new one — and the spec concedes both channels are conventional ("may be included in a DHCP option field"; "the ERL information is preferably sent in the OK message").

Ground 4 — Call-integrity limitations (do-not-BYE / notify proxy / de-register / speaker-mic activation)

• Per se admitted prior art: the spec states as background that "if the caller hangs up the phone during a 911 call, the call should not be released… Other potentially interrupting service features must similarly be disabled. The PSTN typically provides these capabilities." The requirement is therefore known art.
• Motivation: implementing that known requirement inside a SIP UA is routine — SIP de-REGISTER and suppression of a locally generated BYE are standard UA behaviors; auto-answering/speakerphone functions on IP phones are conventional. For the video/monitoring variant, adding the existing speaker/mic capability is a predictable substitution.
• Caveat: if a dependent claim recites a specific signaling sequence (e.g., a NOTIFY to the SIP proxy with an emergency indicator), the specification's own disclosure of that mechanism is thin, and the combination argument should be re-verified against the actual claim language.

Ground 5 — Gateway ancillary functions (in-use ELIN registry, re-assign longest-in-use ELIN, CDRs, security-station NOTIFY, backup storage of phone ERL data)

• Motivation, supplied by the spec itself: the multi-call-per-ERL collision problem is explicitly framed as the reason for multi-ELIN pools ("there could arise a circumstance in which a 911 call is made from an ERL when all ELINs for that ERL are active"). Once a gateway holds a pool, tracking which ELINs are in use and picking one is the obvious, predictable implementation. Notifying an on-site security station and generating CDRs are the admitted conventional PBX E-911 behaviors ("Typically in a PBX system, an on-site emergency facility will be notified when a 911 call is placed"; "An Accounting Server is a repository of records related to calls").

5. Why a POSITA would have combined them (KSR / TSMC motivation analysis)

1. Regulatory and market pressure. The background notes E-911 precision requirements and that "the allowable size and definition of such internal areas may be subject to different regulatory rules in different states or localities." Known regulatory demand for accurate MLTS/enterprise E-911 location supplies a strong, non-hindsight motivation to improve location precision and callback reliability.
2. A specific, articulated deficiency in the admitted art. The spec names the exact shortcomings of Cisco Emergency Responder (polling load vs. staleness) and of proxy-dependent call setup (failure point; redundant-element expense; same-site proxy requirement). Where the art itself frames the defect and the design goal, the motivation prong is easy.
3. Finite, predictable solutions. The possible moves were few: (i) keep the centralized poller (known), (ii) push ERL data to the endpoint, or (iii) leak location into signaling. The references supply the building blocks for (ii)/(iii) directly.
4. Ordinary design choice, predictable results. Storing an ERL/ELIN set in the phone and having the UA place the INVITE to the gateway does not change any PSTN-side behavior; the gateway still selects an ELIN and sets the ANI exactly as before. "Obvious to try," with a reasonable expectation of success.
5. Cost/robustness. The spec's own economic argument (avoid a second full set of hardware-identifying DIDs; avoid redundant call-control nodes; allow small sites to use WAN-based call control for non-emergency calls) is a classic "better at lower cost" motivation.

6. Counterarguments the patentee would raise (and how they land)

7. Confidence ledger and required verification before filing anything

Verification steps needed before any § 103 reliance:

1. Pull the granted-claims PDF for App. No. 12/204,837 from USPTO PatentCenter / Patent Public Search (or the FPO/Justia claim section) and confirm claim 1's actual limitations.
2. Pull the front-page References Cited list for the exact NPL and patent citations (the supplied page omits it).
3. Establish the public-availability date of the Cisco Emergency Responder 1.x documentation (must be ≤ 2003-10-21) if it is to be cited as printed publication rather than as an admission.
4. Date-check US 7,627,091 and US 7,778,406 (Erb) — if their priorities post-date 2003-10-21, exclude them.
5. Confirm the Schulzrinne draft revision and date at the IETF datatracker before citing it.

No contradiction was found with the earlier sections of this analysis; the claim-text gap previously flagged is reconfirmed, and the earlier litigation finding (no case asserting the '333 patent; Flash Uplink's 2026 campaign targets U.S. 7,426,633, not '333) is unaffected by anything found here.