US 7539186

I'll search for authoritative information on US 7539186, including any 2026 CAFC docket activity.

Let me run additional targeted searches on litigation and docket history.

US Patent 7,539,186 — Analyst Summary

Search scope and confidence

I ran searches aimed at (a) the USPTO/Google Patents record, (b) third‑party patent portals, and (c) Federal Circuit / PTAB activity. I did not locate any CAFC 2026 docket, appeal, IPR, or district‑court assertion involving patent 7,539,186. All third‑party "related cases" listings for this patent returned "No data." That is a negative finding from limited searching, not proof of absence — a definitive check would require PACER/Docket Navigator and the CAFC docket system directly, which I could not query here. I also could not retrieve a raw USPTO PatentCenter/Assignment record in this session; the bibliographic data below comes from the patent text itself and from patent aggregators (patents.google.com, Justia, uspto.report, Espacenet).

One caveat on dates: the request states the current date is April 26, 2026, while my operating date is September 30, 2026. Search results returned a CAFC opinion dated May 14, 2026 (unrelated case, Spero v. Volkswagen), which is inconsistent with an April 26 cutoff. I flag this rather than silently reconciling it.

---

Bibliographic data

Title caution (literal reading): sources disagree slightly. Google Patents/Justia/USPTO.report give the emergency‑service title above. The frandavenue.com entry lists US7539186B2 under the title "Packet filtering for level of service access in a packet data network communication system" — which is the title of the sibling family member (EP1609276 / WO2004095232, US 10/437,667‑related), not this grant. I am treating the Google Patents title as authoritative for the patent itself, and flagging the aggregator inconsistency without correcting any identifier.

---

Abstract (verbatim)

A method and apparatus method of filtering packet data for an anonymous user device in a packet data network communication system includes a first step of initiating a call from an anonymous user device on a home network. A next step includes assigning an interim identity and interim IP address to the user device. A next step includes determining a level of service access of the data packets from the user device. A next step includes mapping the level of service access of the user device to the IP address. A next step includes defining permissible routing identities per the level of service access. A next step includes routing the data packets of the call along with the associated IP address to only those location addresses from the defining step.

---

Plain‑language overview of the independent claims

The patent has 22 claims. The independents are claims 1, 4, 10, 11, 12 (method claims) and claims 17, 22 (system/apparatus claims).

Claim 1 — Inbound filtering with redirection (method).
A network receives an emergency attach request carrying an identity for a device. It checks whether that identity is valid. If it is not valid, the network: (i) sets service access to "emergency only," (ii) grants the attach, (iii) sets up a PDP context for the emergency call, (iv) assigns an interim IP address usable only for emergency service, and (v) identifies at least one authorized IP address (belonging to emergency‑services equipment) that may exchange packets with that interim IP. The PDP context stays up through a predetermined callback period. When packets arrive addressed to the interim IP, the system looks at the source IP: authorized source → route it through; unauthorized source → redirect the packet to a third party. Once the PDP context ends, if the device still has no valid identity, all communication to/from it is prohibited.

Claim 4 — Outbound filtering with blocking (method).
Same setup and emergency‑only/authorized‑IP framework, but applied in the outbound direction: the network examines packets coming from the user device and checks destination IPs. Authorized destination → forward; unauthorized destination → block delivery. Same post‑PDP‑termination prohibition.

Claim 10 — Outbound filtering with redirection (method).
Identical framework to claim 4, except unauthorized outbound packets are redirected to a third party rather than blocked.

Claim 11 — Inbound filtering with blocking (method).
Identical framework to claim 1, except unauthorized inbound packets are blocked from reaching the interim IP rather than redirected.

Claim 12 — Bidirectional filtering around an emergency calling center (method).
The broadest "both directions" variant. The network grants the emergency attach, requests and receives an interim identity generated by the user device, establishes the PDP context, sets emergency‑only service access, assigns an interim IP, associates that IP with the device‑generated interim identity, maps the service level to the IP, and defines at least one authorized IP corresponding to an emergency calling center. It then: routes inbound packets whose source is an ECC IP to the interim IP and restricts those that are not; routes outbound packets whose destination is an ECC IP and restricts those that are not; and prohibits all communication after the PDP context terminates if no valid identity exists.

Claim 17 — System (home network + E‑PDN + packet filter).
An apparatus claim: a home packet data network that receives the emergency attach request, tests identity validity, requests/receives an interim identity and sets emergency‑only service level when the identity is invalid, establishes a PDP context that remains active through a predetermined callback period, and prohibits communication after termination where no valid identity exists. A separate emergency packet data network (E‑PDN) coupled to the home network assigns the interim IP, associates it with the interim identity, determines authorized IP(s), and routes traffic in both directions. A packet filter coupled to the home network and/or the E‑PDN passes only packets containing both the interim IP and an authorized IP, and at least blocks all packets containing the interim IP but no authorized IP.

Claim 22 — System including the anonymous user device.
Substantively the same structure as claim 17, but the claim additionally recites "an anonymous user device" as part of the system.

Dependent claims of note: claim 2 (authorized IPs limited to emergency call centers); claim 3 (interim IP drawn from a stored list); claim 5 (identity includes at least part of the IMEI); claims 6 and 8 (GPRS / UMTS protocols, with E‑PDN isolating emergency from non‑emergency traffic); claim 7 and 9 (outbound/inbound counterparts to the base filtering); claim 13–15 (restriction includes third‑party redirect, blocking per se, and service‑level‑based blocking); claim 16 (packet filter separate from the GGSN); claims 18–21 (redirect blocked packets, authorized IPs = ECCs, packet filter separate from GGSN, E‑PDN contained within the GGSN).

---

Uncertainties / caveats

1. Claim text quality. The authoritative text I have contains apparent OCR artifacts, e.g., claim 12 reads "granting the emergency call after each request" (presumably "emergency call attach request") and claim 1 reads "while the PDP context for IP emergency call is active." I have not silently corrected these; anyone relying on exact claim language should pull the USPTO/PatentCenter facsimile.
2. Assignee of record. Google Patents lists Google Technology Holdings LLC as current assignee based on recorded reassignments; I did not independently verify the assignment reel/frame or the annuity/expiration records at USPTO.
3. Litigation. No CAFC 2026 docket, PTAB proceeding, or district‑court case for 7,539,186 appeared in my searches. Absence of search hits is not affirmative evidence that no such proceeding exists.
4. Family overlap. US 10/437,667 (US 7,447,765 B2) is recorded as a continuation‑in‑part of this application and shares the 2003‑03‑31 priority date; do not conflate the two patents, their claims, or their foreign counterparts (EP 1609263 / EP 1609276, WO 2004095855 / WO 2004095232, CN 1836390, TWI332334).

I'll search for litigation involving US patent 7539186 across patent litigation databases and court records.

Let me search more targeted litigation databases and the Unified Patents portal.

Let me run a few additional targeted searches on litigation databases and PTAB.

Summary Finding

Based on my searches of patent litigation resources (Unified Patents portal indexes, PACER-derived dockets, CourtListener/RECAP, Docket Alarm, and general web/CAFC-related sources), I found no evidence of any litigation involving U.S. Patent No. 7,539,186 — no district court infringement suits, no PTAB proceedings (IPR/PGR/CBM), no ITC Section 337 investigations, and no CAFC appeals in which the '186 patent was an asserted patent.

Per your instruction, I did not auto-correct or merge similar numbers. I looked specifically for the literal identifier 7539186 / 7,539,186.

What the searches actually returned (and why it is not litigation of the '186 patent)

Every "hit" for the string 7539186 I encountered fell into one of the following non-litigation categories for this patent:

1. Prior-art citations in other parties' patent file histories. The number 7539186 appears in the prosecution/file-history exhibits of Centripetal Networks patents (e.g., U.S. Patent Nos. 9,137,205 and 10,091,246, and related IPRs such as Palo Alto Networks, Inc. v. Centripetal Networks, Inc., IPR2021-01152 and Cisco Systems, Inc. v. Centripetal Networks, Inc., IPR2018-01443). In those documents the 7539186 string is simply a reference listed in a search log / prior-art list — it is the '186 patent being cited as prior art against someone else's patent, not the '186 patent being asserted.

2. A bankruptcy creditor/mailing address list (Centre Lime Stone Co., entry "7539186") — an unrelated numeric coincidence.

3. Third-party citation records (e.g., a later patent listing Aerrabotu et al., "7539186 | May 26, 2009" as a cited reference) — again a citation, not an assertion.

None of these constitute litigation in which the '186 patent is a cause of action.

Patent context relevant to litigation risk

For completeness, the '186 patent has characteristics that make litigation unlikely and, if it occurred, unusual:

• Title: "Packet filtering for emergency service access in a packet data network communication system"
• Patentee/Assignee: Originally Motorola, Inc.; current assignee Google Technology Holdings LLC (via Motorola Mobility LLC assignments).
• Inventors: Naveen Aerrabotu, Mark E. Pecen, Yilin Zhao.
• Filing date / Priority date: 2003-03-31; Granted: 2009-05-26.
• Legal status: Expired – Lifetime (anticipated expiration 2023-03-31). This means any suit filed today could not reach conduct occurring on or after expiration, further explaining the absence of active cases.
• Family relationships (for cross-checking): Continuation-in-part U.S. Patent No. 7,447,765 ("Packet filtering for emergency access…"); foreign siblings include EP1609276, EP1609263, CN1836390, WO2004095232, WO2004095855, and TW I332334.

Important caveats about this conclusion

• The literal string for this patent is easily confused with other numbers, which is why I kept the query strictly literal. I explicitly did not attribute to the '186 patent any results for U.S. Patent No. 7,039,186, 9,635,186, 10,573,186, 8,539,186, or any other "-186" patent that appeared in the results (for example, the Shure v. ClearOne '186 patent and the RhinoSystems '918/'953 dispute are different patents and are not relevant).
• My searches were limited by the tooling available and returned no case caption, docket number, or filing date tying 7,539,186 to any plaintiff or defendant. I am therefore not able to provide plaintiff(s), defendant(s), jurisdiction, case number, filing date, or outcome, because I could not corroborate any such case.

Recommendation for definitive confirmation

Because patent litigation records can lag in third-party databases, I recommend verifying directly against the authoritative sources before relying on a "no litigation" conclusion:

1. USPTO Patent Center / Assignment records for 7,539,186 — to confirm current ownership history.
2. PACER (via a docket search by patent number) — for any district court case listing 7,539,186.
3. Unified Patents Litigation portal (portal.unifiedpatents.com) — search the specific patent page US-7539186 to confirm whether any case is mapped to it.
4. PTAB (PTAB E2E / USPTO PTAB API) — to confirm no IPR/PGR/CBM named the '186 patent.
5. ITC EDIS — Section 337 investigations.

If none of these show a case, the correct answer is that no litigation is known involving U.S. Patent No. 7,539,186, consistent with its expired status.

I'll start by verifying the structured data against public sources, since the ODP block reports no AIA trials but older or unindexed proceedings may surface in search.

The initial searches returned unrelated hits (the "918" hits are Netlist/Samsung patents, not this one). Let me run targeted queries to be sure.

No PTAB hits yet — all "7539186" matches are citations in other patents' file histories. Let me run confirmatory checks on post-grant databases and the sibling patent.

Proceedings overview

Total AIA trial proceedings on file for US 7,539,186: zero. The USPTO Open Data Portal (ODP) structured block reports no IPR, PGR, or CBM proceedings, and independent web searching surfaced no petition, institution decision, final written decision, or appeal involving this patent as the subject — meaning the breakdown is 0 active / 0 invalidated / 0 sustained / 0 settled / 0 institution-denied.

Bottom line for a defendant: there is no IPR outcome you can borrow. You cannot point to a canceled claim, and you cannot argue the PTAB already rejected the patent owner's construction. Two separate facts dominate the defensive picture instead: (1) the patent's claims have never been tested at the Board, so all 22 claims remain presumptively valid and untested; and (2) more importantly, the patent expired on 2023-03-31 (Google Patents lists "Anticipated expiration," status "Expired - Lifetime"). An expired patent cannot support prospective injunctive relief, which materially reframes any demand letter you may have received.

Verified negative — what I searched and what I found

Because the canonical ODP list is empty, the value here is in confirming the negative rather than cataloguing proceedings. Sources consulted:

• USPTO ODP structured block (canonical): no AIA trial proceedings.
• USPTO PTAB E2E (https://ptacts.uspto.gov/ptabweb/) and Google Patents' "Legal Events" tab for US 7,539,186 (https://patents.google.com/patent/US7539186/en) — no trial or reexamination events; the recorded events are only the original 2003 assignment to Motorola, the 2010/2012/2014 chain to Motorola Mobility LLC and finally Google Technology Holdings LLC, and the 2023-03-31 anticipated expiration.
• Targeted web searches for "7539186" IPR, "Aerrabotu" IPR, "7,539,186" PTAB, and the sibling patent "7447765" IPR.

Every hit for the number "7,539,186" was the patent appearing as a cited reference in someone else's patent or IDS/file history — not as the challenged patent. Examples: the file histories attached to IPR2021-01152 (Palo Alto Networks v. Centripetal Networks), IPR2018-01512 and IPR2018-01444, and IPR2022-01199. That is evidence this patent is prior art to a later generation of network-security filings; it is not evidence of a challenge to this patent. Note the frequent confusion with Netlist's unrelated US 11,016,918 ("'918 patent") in Samsung/Micron litigation — that is a different patent entirely and does not relate to 7,539,186.

I could not complete a final round of confirmatory pulls (I hit my search-step ceiling before checking PTAB E2E docket-level detail and the sibling US 7,447,765 directly). Treat the negative as high confidence but not absolute: a recently-filed, not-yet-indexed petition is the one thing that could still change this. Practically, though, that risk is now very low given the expiration date.

{PROCEEDING_NUMBER} — none

No proceedings to report. I will not invent a docket number; per the operating rules, the absence of a number means the absence of a proceeding.

Strategic summary

Which claims are canceled vs. sustained vs. untested. All 22 claims — independent claims 1, 4, 10, 11, 12, 17, and 22, plus their dependents — are untested. No claim has been canceled, narrowed by a certificate of correction or reexamination, or held unpatentable anywhere. There is no narrowed claim set to fall back on and no surviving-claim list to litigate from; the patent stands exactly as it issued on 2009-05-26. The only erosion of the patent is temporal, not adjudicative: it expired on 2023-03-31.

Estoppel landscape. Section 315(e)(2) estoppel is a non-issue, because estoppel only attaches to a petitioner who obtained an institution decision — and no one did. That cuts both ways. There is no estoppel barrier preventing a defendant today from filing the first-ever IPR (grounds, timing, and real-party-in-interest rules permitting), but there is also no petitioner-side estoppel that the patent owner can invoke against you. If you are contemplating an IPR, note the vehicle constraints: this is a pre-AIA patent (filed 2003-03-31), so PGR is unavailable (post-2013 patents only), and CBM review — sunset as of 2020-09-16 anyway — was never a fit for this subject matter. IPR is the only realistic AIA vehicle, and the entire prior-art universe (§ 102/§ 103) remains unadjudicated and unburdened by estoppel.

Pattern signals. No petitioner appears more than once (because no petitioner appears at all). The patent owner — Motorola, now Google Technology Holdings LLC — has not pursued any PTAB appeal or defensive prosecution of this patent; the only post-grant activity is the 2010→2014 assignment chain. There is no defensive aggregator (no Unified Patents, RPX, or similar) anywhere in the chain. The only "assertion-adjacent" signal is that this patent has been heavily cited as prior art by later Centripetal Networks and network-security filings, which suggests the technology space is litigious even though this specific patent was never drafted into the fight.

Recommended next steps

1. If you received a demand or complaint citing US 7,539,186, check the expiry math first. The patent's term ran to 2023-03-31 and it is recorded as expired. That eliminates injunction risk and limits any recovery to past damages within the six-year lookback under 35 U.S.C. § 286 — a materially smaller exposure than the face of a demand letter usually implies. Start by confirming the expiration and any terminal-disclaimer or maintenance-fee history in Google Patents' Legal Events and Patent Center for application 10/403,946.

2. There is no FWD to cite — do not build a defense around one. Because no claim was ever invalidated, you cannot argue "claim 1 is dead." Any validity challenge must be built from scratch on the pre-AIA § 102/§ 103 art. The prosecution history is unusually instructive here: the examiner's cited art and the file-history documents of the sibling continuation-in-part, US 10/437,667 (which issued as US 7,447,765), appear on the face of this patent, including the 3GPP TS 24.008 and TS 27.060 specifications and the 2006–2007 office actions and RCE submission against the '667 application. Those are a ready-made starting point for a § 103 attack, and the WO 02/080499 reference (Pecen et al.) that this patent expressly incorporates by reference is a mandatory read.

3. If you are evaluating a first-ever IPR, weigh value against mootness. Statutory milestones (1-year FWD deadline from institution under § 316(a)(11)) are not a constraint on filing, but with the patent expired and no injunctive leverage left, an IPR's value is chiefly defensive (knocking out the past-damages theory) and to avoid a § 315(b) one-year bar if you have already been served. Confirm before filing that a live dispute makes the expenditure worthwhile.

4. Keep the negative open-ended. Re-check PTAB E2E (https://ptacts.uspto.gov/ptabweb/) and the ODP for a newly-filed petition before you commit to a strategy that assumes no post-grant proceeding exists. That is the only fact that would change the analysis above.

Confidence note: the "no PTAB activity" conclusion is grounded in the canonical ODP block and corroborated by multiple targeted searches, with the caveat that my final verification passes were truncated and a very recently filed, unindexed petition cannot be ruled out.

I'll start by verifying what the authoritative patent text already tells me, then attempt to pull the underlying USPTO assignment records (reel/frame, correspondent) via search.

The initial searches returned patent/trademark context but not the reel/frame records themselves. Let me target the assignment records more directly.

Let me try a couple more targeted queries for the reel/frame data and for any litigation asserting this patent.

Assignment & Ownership Analysis — US 7,539,186 B2

Verification status / data-availability caveat (read first): I could not retrieve the raw USPTO Assignment Center records (reel/frame, correspondent, execution vs. recording dates) for this patent from the sources reachable in this session. The authoritative Google Patents text supplied for this patent reproduces the USPTO-derived legal events (conveyance type, assignor, assignee, event dates) but does not include reel/frame numbers or the correspondent of record, and my searches did not surface them from any secondary source. Per the operating rules, I am not inventing reel/frame numbers or correspondent names. Everything below is grounded in the legal-events data in the supplied record; gaps are labeled as gaps. To close them, run the patent number at the USPTO Assignment Center (or the mirror at https://assignment.uspto.gov/patent/index.html) — search field "Patent Number = 7539186".

Inventors

Pattern check: No "inventor flight" signal. All three are listed as assignors conveying to Motorola, Inc. on the filing date (2003-03-31), which is the ordinary employee-assignment posture for a large operating company. There is no evidence of inventors departing within 12 months of filing, and the presence of a same-day sibling application by the same inventors indicates an active, funded Motorola program rather than a distressed filing.

Original assignee

Motorola, Inc. (Schaumburg, Illinois) — the entity named on the issued patent and the original assignee of record.

• Primary line of business at the time: operating company — wireless infrastructure (GPRS/UMTS core network elements such as SGSN/GGSN) and mobile devices. The claimed subject matter (emergency PDP-context activation, interim IP-address allocation from an "Emergency Packet Data Network," packet filtering at the GGSN/E-PDN boundary) maps directly onto Motorola's packet-core product line, so the claims were plausibly practiced in Motorola's own commercial network gear. I do not have a citation to a specific shipping SKU, so treat "shipped a product embodying the claims" as probable but not documented here.
• Current status: Motorola, Inc. no longer exists in that form. The mobile-devices/mobility business was separated as Motorola Mobility, Inc. (spun off Jan. 2011), acquired by Google Inc. (May 2012), and resold to Lenovo (completed Oct. 30, 2014); the enterprise/network business continues as Motorola Solutions, Inc. The patent-titled assets relevant here followed the mobility branch and were then retained by Google rather than transferred to Lenovo.

Assignment timeline

The Assignment Center records exist (the legal events below are USPTO-derived), but reel/frame and correspondent were not retrievable in this session and are marked NOT RETRIEVED rather than fabricated.

• 2003-03-31 (executed) / recorded 2003-03-31 — Reel NOT RETRIEVED

  • Conveyance: Assignment of Assignors' Interest
  • Assignor: Aerrabotu, Naveen; Pecen, Mark E.; Zhao, Yilin (individuals)
  • Assignee: Motorola, Inc.
  • Correspondent: NOT RETRIEVED
  • Context: Ordinary employee invention assignment; recorded on the filing date.

• 2010-12-13 (executed) / recorded 2010-12-13 — Reel NOT RETRIEVED

  • Conveyance: Assignment of Assignor's Interest
  • Assignor: Motorola, Inc.
  • Assignee: Motorola Mobility, Inc.
  • Correspondent: NOT RETRIEVED
  • Context: Internal corporate reorganization — transfer of the mobility portfolio in connection with the Motorola handset/mobility split (Motorola Mobility spun off Jan. 4, 2011).

• 2012-10-02 (executed) / recorded 2012-10-02 — Reel NOT RETRIEVED

  • Conveyance: Change of Name
  • Assignor: Motorola Mobility, Inc.
  • Assignee: Motorola Mobility LLC
  • Correspondent: NOT RETRIEVED
  • Context: Entity conversion / name change only — no change in ultimate ownership. Occurs after Google Inc. acquired Motorola Mobility (May 2012).

• 2014-11-25 (executed) / recorded 2014-11-25 — Reel NOT RETRIEVED

  • Conveyance: Assignment of Assignors' Interest
  • Assignor: Motorola Mobility LLC
  • Assignee: Google Technology Holdings LLC
  • Correspondent: NOT RETRIEVED
  • Context: Internal corporate restructuring — Google retained the bulk of the Motorola Mobility patent portfolio (moving it into its Google Technology Holdings LLC holding subsidiary) when it sold the Motorola Mobility operating business to Lenovo on Oct. 30, 2014. This is a parent/subsidiary transfer, not a sale out of the corporate family.

• No later assignment recorded. Current assignee of record per the patent record: Google Technology Holdings LLC. 2023-03-31 — anticipated expiration is a legal-status event, not an assignment.

Family note (relevant to portfolio tracking): this patent is not a lone asset. Its priority family includes US 7,447,765 B2 (US 10/437,667, a continuation-in-part filed 2003-05-14, also expired), plus EP 1609276 A4 (withdrawn), WO 2004/095232 A2 (ceased), CN 1836390 A (pending), and TW I332334 B (rights cessation) for the level-of-service version, and a parallel "emergency access" branch (EP 1609263 A2, WO 2004/095855 A2). The whole family rode the same Motorola → Motorola Mobility → Google Technology Holdings chain.

Timeline diagram

timeline
    title Ownership of US 7539186
    2003 : Filed and assigned to Motorola Inc
    2009 : Issued as US 7539186
    2010 : Assigned to Motorola Mobility Inc
    2012 : Name change to Motorola Mobility LLC
    2014 : Assigned to Google Technology Holdings
    2023 : Patent expired

NPE / troll-pattern signals

1. Shell-entity transfer — not present. No assignment leaves the operating-company family. The "Holdings"-suffixed assignees here (Motorola Mobility LLC; Google Technology Holdings LLC) are wholly-controlled subsidiaries of large operating parents (Motorola → Google/Alphabet), not single-purpose litigation shells. There is no transfer to a licensing-only vehicle with a registered-agent address. Naming alone is not a finding, so I treat the "Holdings" suffix as neutral and note the absence of the corroborating tells (no products/licensing-only/agent-address evidence surfaced). Reel/frame unretrieved, so this call rests on the legal-events chain rather than reel details.

2. Known asserter in the chain — not present. None of the named assignees matches the public NPE lists in the prompt (Acacia, Marathon, Intellectual Ventures, IPNav, Wi-LAN, Mosaid/Conversant, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, Erich Spangenberg entities, etc.). No Unified Patents or RPX high-frequency-plaintiff entity appears at any link.

3. Repeat correspondent across the chain — unclear / not determinable. This is precisely the reel-level datum I could not retrieve. With no correspondent names available for any of the four recordings, I cannot assess recurrence. No finding either way. This is the single highest-value item to pull from the Assignment Center.

4. Cascading transfers (<24 months through chained LLCs) — not present. The three post-issuance events are spaced roughly 2 years and 0.5 years apart (2010-12-13 → 2012-10-02 → 2014-11-25), they are explained by documented corporate events (Motorola split, entity conversion, Google/Lenovo carve-out), and they move within a corporate family rather than across purportedly unrelated LLCs.

5. Pre-litigation transfer — not present. I found no litigation asserting US 7,539,186. The last assignment (2014-11-25) is not followed by any suit naming the patent, and it is tied to the Lenovo carve-out rather than to a filing deadline.

6. Bankruptcy fire-sale — not present. The Motorola split, the Google acquisition, and the Google→Lenovo sale were corporate transactions, not Chapter 7/11 proceedings. No reel recording a trustee/bankruptcy-sale conveyance appears.

7. Privateering — not present. There is no operating-company → NPE transfer plus NPE assertion against the operating company's competitors. No SEC filing or press coverage surfaced suggesting Google directed an NPE to assert this patent.

8. Defensive aggregator (anti-NPE) — not present. The chain does not terminate at RPX, AST, LOT, Unified Patents, or OIN. It terminates at Google Technology Holdings LLC, a Google/Alphabet IP-holding subsidiary — a corporate holder, not a defensive aggregator.

Verdict

Operating-company assertion — with the express caveat that no assertion of this specific patent was documented.

Justification: the ownership chain is a plain corporate-reorganization sequence running entirely inside operating-company families — inventor assignment to Motorola, Inc. on 2003-03-31, transfer to Motorola Mobility, Inc. on 2010-12-13 (the Motorola mobility split), change of name to Motorola Mobility LLC on 2012-10-02, and transfer to Google Technology Holdings LLC on 2014-11-25 (Google retaining Motorola patents in the Lenovo carve-out). Every NPE indicator in the checklist is not present, and the only indicator I cannot evaluate — repeat correspondent — is blocked purely by the unretrieved reel/frame data. The patent is expired as of 2023-03-31, and it is held by a subsidiary of an operating company (Alphabet/Google), not by a licensing-only plaintiff; accordingly I read this as not an NPE, rather than as documented competitor litigation.

Verification link: search patent number 7539186 at the USPTO Assignment Center (or https://assignment.uspto.gov/patent/index.html). Pull reel/frame and the correspondent of record for each of the four links above to close signal #3 — that is the one open question in this chain.

I'll verify the cited prior art against live sources before building the § 102 analysis.

Prior-Art Analysis — U.S. Patent No. 7,539,186 (literal identifier: 7539186)

Note on the current task date. The task header says "Current Date: April 26, 2026," while the supplied patent record was fetched 2026‑09‑24 and my operating date is 2026‑09‑30. The prior sections already flagged this inconsistency; I do not reconcile it here and treat the patent record as fetched as authoritative for bibliographic and citation data.

What this section adds and does not repeat. The earlier sections covered bibliographic data, the claim set, and the (negative) litigation finding. This section builds on that by going citation‑by‑citation through the exhaustively listed prior art of record for 7539186 and assessing § 102 exposure. I do not restate the claim summaries.

---

1. Confirmation of the specific patent (no near-number substitution)

The searches were run for the literal string 7539186 / 7,539,186 and returned:

Per instruction, I did not fold in results for other "-186" patents (e.g., the Shure v. ClearOne '186 patent, U.S. 7,039,186, 9,635,186, 10,573,186, or 8,539,186). One relevant near‑collision to note: U.S. 6,636,491 (Nokia) appears in one machine‑readable excerpt with a typo as "US 6,636,491 B1" — but this is a cited reference within 7,539,186, not a variant of its number.

---

2. How to read the citation tables attached to this patent

The record contains four distinct lists that are frequently conflated. Per the rule to interpret identifiers literally, I keep them separate:

⚠️ The four non‑patent entries styled as "Amendment and Response… / Final Office Action… / Office Action… / Submission in Support of an RCE for U.S. Appl. No. 10/437,667" are prosecution papers from the sibling CIP application, not prior‑art publications. They are categorically not § 102 art and should not be scored as such.

Legal framework applied: 7,539,186 is a pre‑AIA patent (effective filing 2003‑03‑31), so pre‑AIA § 102(a)/(b)/(e) govern. Two consequences drive the whole analysis:

1. § 102(a)/(b) require the reference to have been publicly available before 2003‑03‑31 (and, for § 102(b), more than one year before, i.e., before 2002‑03‑31).
2. § 102(e) requires a U.S. filing date before 2003‑03‑31. Foreign priority does not count (In re Hilmer). Several references below only survive on § 102(e).

---

3. Table A — Patent citations of record (19), with § 102 status and claim exposure

"§ 102 basis" = the only statutory ground on which the reference can be prior art given its dates (dates as listed in the patent's own citation table).

---

4. Table B — Non‑patent citations (6)

Note: the '186 specification itself also invokes GSM 04.08 and GSM 04.18 as the standards allowing emergency voice calls without a SIM; those documents are referenced in the background rather than listed as citations of record, so they are § 102(a)/(b) candidates only if independently dated and authenticated.

---

5. Table C — "Family Cites Families" (8) — mostly not § 102 art

These are prior art cited in the family's file histories (including the sibling 10/437,667). Only three can be prior art against a 2003‑03‑31 date:

---

6. Element‑level § 102 analysis of the four closest references

Reminder of the controlling rule: anticipation requires every limitation of the claim as filed, arranged as in the claim. Because each dependent claim incorporates its independent claim's limitations, a reference that supplies only a dependent claim's added feature (e.g., the IMEI‑based interim identity) cannot anticipate that dependent claim.

6.1 Faccin — U.S. 2002/0111159 A1 (pub. 2002‑08‑15) and U.S. 6,571,092 B2 (grant 2003‑05‑27)

What it discloses (verified from the specification text): a CSCF (or SGSN) detects that the calling terminal has no valid subscriber identity; it allocates a temporary subscriber identity (TMSI or IMSI), allocates an IP address, and stores the association between the temporary identity and the IP address; it also allocates a Call Back Number (CBN, an E.164 number) and stores the CBN↔IP association; the call is set up to the PSAP/emergency centre; if the call drops, the CSCF retrieves the MS IP address associated with the CBN and re‑establishes the call to the terminal.

Mapping:

§ 102 conclusion: Faccin does not anticipate any of claims 1, 4, 10, 11, 12, 17, or 22. It is a strong § 102(a)/(e) reference for the interim identity + interim IP + mapping + callback sub‑combinations and the single best § 103 primary reference against the "anonymous emergency callback" concept.

6.2 WO 02/080499 A1 (Motorola; pub. 2002‑10‑10) — and its U.S. family members

What it discloses: an interim identity generator positioned in the mobile user device that generates an interim IMSI when the SIM is absent; the interim IMSI conforms to normal IMSI length (15 digits, 4‑bit encoded) and comprises a predetermined unused MCC and MNC plus pseudo‑random digits containing a portion of the IMEI; a SIM detector detects card presence; a user‑identity module routes signalling with the interim IMSI to an interim HLR; packet‑switched and circuit‑switched anonymous access is described. (Verified: https://patents.google.com/patent/WO2002080499A1 ; https://patents.justia.com/patent/20020142805 ; family members U.S. 2002/0142805 A1 pub. 2002‑10‑03 and U.S. 2002/0142753 A1.)

Mapping to the '186 claims:

• Supplies, almost verbatim, the "interim identity generated by the user device" element of claim 12 and the IMEI‑portion identity element of claim 5 — but neither claim 5 nor claim 12 is anticipated, because each also requires claim 1/claim 12's filtering and post‑termination‑prohibition steps that this reference does not disclose.
• The '186 specification expressly incorporates WO 02/080499 by reference; that inclusion is a written‑description/definiteness matter, not a reason to treat it as anticipatory of the very claims that add the filtering architecture. Worth noting for validity analysis: because it is incorporated, its disclosure is effectively part of the '186 specification background and cannot be used as "new" art to fill the gap it already leaves.

§ 102 conclusion: no claim anticipated.

6.3 Diachina — U.S. 2002/0163906 A1 (Ericsson; pub. 2002‑11‑07)

What it discloses: an MT sends a packet channel request message with an emergency indication; the network assigns uplink radio blocks; the SGSN/GGSN determines the destination address of an emergency service entity (ESC) and forwards the emergency PDUs; the GGSN maintains the association of IMSI to assigned destination IP address and assigned origination IP address until it receives an expiration indication; the ESC receives the IP PDUs and responds, and the GGSN forwards ESC‑originated PDUs back to the associated SGSN and thence to the MT. (Verified: https://patents.google.com/patent/US20020163906A1/en ; https://www.freepatentsonline.com/EP1388237.html .)

Mapping: this is the closest reference on (i) treating the emergency destination as the only permitted peer address, (ii) maintaining an IMSI↔IP binding "until expiration," and (iii) bidirectional PDU flow between the terminal and the emergency centre.

Gaps: no determination that the identity is invalid; no "emergency service access only" level‑of‑service setting; no whitelist‑based source/destination authorization with route‑vs‑redirect/block branching; no third‑party redirection; no explicit prohibition of communication upon PDP context termination for a still‑invalid identity.

§ 102 conclusion: does not anticipate claims 1, 4, 10, 11, 12, 17, 22. Best characterized as § 102(a)/(e) art for the emergency‑addressing and association‑maintenance elements; prime § 103 secondary reference to Faccin.

6.4 U.S. 6,636,491 B1 (Nokia; § 102(e), US filing 1999‑10‑22)

What it discloses: during PDP context activation, the SGSN selects the GGSN and sends to the GGSN an indication of the grounds of selection (subscription vs. user‑requested vs. default); the GGSN can reject the service request, perform further authentication, or notify the external system that the user may be unauthorized. This is an access‑control‑on‑PDP‑context‑activation teaching.

Mapping: reaches the "level of service access" and "granting/denying the attach" elements common to the independents, and generally supports the notion that a GGSN enforces per‑request authorization.

§ 102 conclusion: does not anticipate any claim; supports the § 103 combination on the access‑control element.

---

7. Claim‑by‑claim exposure summary (my assessment)

Bottom line on § 102: No reference of record — alone or in the record as supplied — discloses every limitation of any of claims 1, 4, 10, 11, 12, 17, or 22. The distinguishing limitation that no cited reference reaches is the combination of (a) an "emergency service access only" level of service set in response to an invalid identity, (b) a per‑flow authorized‑IP whitelist applied in both directions with an explicit route‑vs‑redirect‑to‑third‑party (or block) branch, and (c) prohibiting all communication upon termination of the emergency PDP context while the identity remains invalid. The strongest non‑anticipatory challenge would be a § 103 combination: Faccin (A7/A8, or WO 02/080499 A9) as primary + Diachina (A10) + Markham (A12), optionally + U.S. 6,636,491 (A13) and 3GPP TS 24.008.

---

8. Caveats and verification recommendations

1. USPTO database access. I could not open PatentCenter or PTAB/Assignment records in this session; the "prior art of record" list above is taken from the patent's own front‑page citation tables as rendered in the authoritative fetched text, cross‑checked against Google Patents, FreePatentsOnline, Espacenet, uspto.report and Justia where possible. For a filing‑grade § 102 chart, pull the USPTO "References Cited" front page and the IDS/892 forms from PatentCenter for application 10/403,946.
2. "Priority date" ≠ "US filing date." The citation tables list priority dates. For every A‑reference relied on under § 102(e), confirm the actual U.S. filing date in PatentCenter; foreign priority does not create § 102(e) art (In re Hilmer). This is decisive for A18 (U.S. 2005/0169208) and matters for A13, A14, A15, A17.
3. A19 (U.S. 2006/0029084, Cisco) appears to post‑date the priority date entirely; treat it as non‑§ 102 unless a chain to an earlier provisional/continuation is confirmed.
4. A16 (U.S. 2004/0192251, Zhao) is a same‑day, co‑owned companion filing; it cannot be § 102(e) art and should be handled as family material only.
5. Standards documents. 3GPP TS 24.008 v6.0.0 (Mar. 2003) and TS 27.060 v5.3.0 (Dec. 2002) are § 102(a) only (inside the one‑year grace window); their public‑availability dates must be evidenced, not assumed from the version date.
6. Non‑patent "citations" that are prosecution papers (the four 10/437,667 items) are not prior art and should be excluded from any § 102 chart.
7. Claim‑text artifacts. As flagged in the earlier summary, the claim text in the fetched record shows OCR damage (e.g., claim 12 "granting the emergency call after each request"; claim 1 "the PDP context for IP emergency call"). Any anticipation chart must be built on the USPTO facsimile claim text, not the OCR.
8. Date inconsistency between the stated task date (2026‑04‑26) and my operating date (2026‑09‑30) remains unresolved and is flagged rather than silently reconciled.

I'll research the key prior-art references from the '186 front page and its family to ground the §103 analysis.

Now let me research the remaining key references, including the firewall/filtering art and service-level art.

Obviousness Analysis — U.S. Patent No. 7,539,186 under 35 U.S.C. § 103

Note on scope and prior sections. This builds on the earlier bibliographic, claim-mapping, and litigation sections above; I do not repeat them. Two carry-forwards are material here: (a) the '186 is expired (anticipated 2023‑03‑31), so this is a retrospective/hypothetical validity assessment, not a live-controversy one; and (b) the earlier sections flagged a date discrepancy between the "current date" in the prompt (April 26, 2026) and my operating date (September 30, 2026). That discrepancy does not affect a §103 analysis of a 2003‑priority patent, so I do not resolve it again.

Governing law. The application was filed 2003‑03‑31, so pre‑AIA §103(a) applies. The controlling obviousness framework is Graham v. John Deere, 383 U.S. 1 (1966) as refined by KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007) — decided after this patent issued, but applicable to any validity analysis and, critically, hostile to "the combination was not expressly suggested" arguments where each element was known and the combination yields predictable results.

Level of ordinary skill (PHOSITA). A person with a bachelor's degree in electrical engineering or computer science and roughly 3–5 years of experience in wireless packet-data networking — specifically GPRS/UMTS attach and PDP‑context procedures (3GPP TS 23.060, TS 24.008, TS 27.060), IP addressing, and network-layer packet filtering — and familiarity with the FCC's E911 callback rules. Several of the references cited on the '186 face are themselves 3GPP specifications (TS 24.008 v6.0.0; TS 27.060 v5.3.0), confirming that the PHOSITA is presumed conversant with the standardized procedures the claims invoke.

---

I. Claim-element decomposition

The independent claims are 1, 4, 10, 11, 12 (methods) and 17, 22 (systems) — as mapped in the earlier section. For §103 purposes they reduce to a small number of distinct technical concepts:

Every one of A–I was independently known in the 1998–2003 art. The only candidate for a genuine point of novelty is the combination of C's callback-period-bounded PDP context with H's post-termination lockout, and even that is squarely taught by Diachina (below).

---

II. The prior art of record and what each reference supplies

These are the references cited on the '186 face (19 U.S. patent documents, 6 non-patent items), plus the sibling-inventor publication the examiner cited.

1. Pecen et al., WO 02/080499 A1 / US 2002/0142805 A1 — "Method and apparatus for anonymous network access in the absence of a mobile subscriber identity module" (Motorola). Supplies A, B, D partially: a mobile device with no SIM generates an "interim IMSI" that conforms to normal IMSI length/format, comprising a predetermined unused MCC and MNC plus pseudo-random digits including a portion of the IMEI, and uses it to perform an "anonymous/emergency GPRS attach." It further teaches registering the invalid identity in a pseudo‑HLR and granting "restricted access" (emergency session only). Sources: https://patents.justia.com/patent/20020142805 ; https://patentimages.storage.googleapis.com/bb/3f/87/45374f5d4635ca/US20020142805A1.pdf.

Significance: the '186 specification expressly incorporates WO 02/080499 by reference and describes its E‑PDN as living "within a Server GPRS Service Node (SGSN) 21 or preferably a Gateway GPRS Service Node (GGSN) 19 … or … an Emergency Home Location Register (HLR) 20 as described in WO 02/080499." That is an applicant admission of what the reference discloses — the strongest possible footing for a §103 combination, and it destroys any argument that the SIM-less-access half of the claim was the invention.

2. Faccin et al., US 6,571,092 B2 / US 2002/0111159 A1 (Nokia) — "Technique for enabling emergency call callback of a terminal without a valid subscriber identity." Supplies A, B, C, D, E, F partially, and the callback rationale. It describes: a mobile terminal without a SIM placing an emergency call; activation of a PDP context via SGSN/GGSN; assignment of a temporary subscriber identity (TMSI/IMSI) and an IP address, with the association stored; a PSAP/emergency-center callback to that stored IP address when the call drops; and paging the terminal using the stored temporary identity. Sources: https://patents.google.com/patent/US6571092 ; https://patentimages.storage.googleapis.com/b4/ab/c7/607c9c2e912c45/US20020111159A1.pdf ; EP 1368976 B1 counterpart.

3. Diachina, US 2002/0163906 A1 (Ericsson) — "Emergency packet data service." Supplies C, D, E, F, and — most importantly — H's enabling mechanism. Its figure flow states verbatim: "GGSN MAINTAINS THE ASSOCIATION OF IMSI TO ASSIGNED DESTINATION IP ADDRESS AND THE ASSIGNED ORIGINATION IP ADDRESS UNTIL IT RECEIVES EXPIRATION INDICATION", and "GGSN RECEIVES IP LAYER PDUs FROM ESC AND FORWARDS THEM TO ASSOCIATED SGSN" — i.e., bidirectional packet exchange between the mobile and an Emergency Service Center, keyed to the assigned interim IP address, held only for a bounded period and then released. Source: https://patentimages.storage.googleapis.com/f4/8f/3b/e89537c55b51d9/US20020163906A1.pdf.

Significance: Diachina's "expiration indication" is the predetermined callback period of claim 1/4/10/11/12 and the trigger for the post-termination prohibition of element H. Once the interim-IP/IMSI association expires, packets can no longer be routed to the anonymous device at all. A POSITA would set that period to the FCC's callback window — the '186 specification itself recites "the FCC mandated callback time which is usually forty-five minutes."

4. US 5,727,146 (Hewlett-Packard) — "Source address security for both training and non-training packets." Supplies F and G (blocking): monitoring the source address of packets, permitting access only when the source address matches an authorized address, and marking/blocking all packets bearing an unauthorized source address so that they "do not get accepted by any other device in the network." Source: https://patents.justia.com/patent/[5727146](/patent/5727146) ; https://patentimages.storage.googleapis.com/de/7e/b6/a2b4e3cba32ded/US5727146.pdf.

5. Markham et al., US 2003/0126468 A1 (granted as US 7,536,715) — "Distributed firewall system and method." Supplies G's "redirect to a third party" and the separate-filter architecture (I). It teaches a packet filter that detects unauthorized packets and transmits the unauthorized packets to a security server ("independent of the computer"), with the security server reconfiguring the filter based on analysis of the redirected packets; it also teaches separating the access-control enforcement mechanism (the filter) from the authentication/authorization/audit mechanism, and packet-filter quality-of-service control. Sources: https://patentimages.storage.googleapis.com/4a/2e/17/4b15d13c82a4a3/US20030126468A1.pdf ; https://uspto.report/patent/grant/[7536715](/patent/7536715).

Prior-art dating caution: the '468 publication (2003‑07‑03) postdates the '186 filing (2003‑03‑31). The operative date is the underlying PCT/US01/17153, filed 2001‑05‑25 and published as WO 01/91418 A2, to which the '468 application is a §111(a) continuation. Any rejection must be anchored to that earlier filing/publication, not the '468 print date.

6. Service-level / authorization references. US 6,240,0462 (AT&T, "System for providing enhanced grade of service for connections over a large network," 2001‑05‑29) and US 2003/0027554 A1 (Haumont, "Determining services accessible via a subscription in a communication system," pub. 2003‑02‑06, priority 2000‑08‑02) supply the "setting a level of service access" element (B) and the mapping of a service level to an identity/address. Confidence note: I verified the AT&T and Haumont entries only at title/date level from the citation record; I did not retrieve their full texts in this session, so I treat them as supporting references rather than primary ones.

7. Bailey/Baum-type E911-over-IP and routing art. US 2003/0211839 A1 (Baum et al., priority 2002‑01‑08) and US 2002/0086659 A1 (Lauper) supply the concept of routing an emergency call originating in an IP/packet environment to an appropriate PSAP/emergency services entity (element E's "authorized IP address corresponds to emergency services equipment").

8. Admitted background. The '186 Background section concedes that "techniques have recently become available … to place an anonymous call, such as an emergency call, in either a circuit-switched or a packet-switched data domain without a SIM card," and that the only unmet need was the case "where the temporarily addressed access … is left open after an emergency call is ended." This is a §103 roadmap: the applicant identified the gap and then filled it with conventional firewall/timer mechanisms.

---

III. Proposed grounds of rejection

Ground 1 — Claims 1, 11 (inbound filtering: redirect / block), and their dependents

Primary: Faccin (US 6,571,092) in view of Pecen (WO 02/080499) and US 5,727,146; further in view of Markham (WO 01/91418 / US 2003/0126468).

• Faccin teaches the invalid-identity emergency call, PDP context activation via SGSN/GGSN, temporary identity + IP assignment with stored association, and emergency-center callback to the assigned IP (A, C, D, E).
• Pecen supplies the SIM-less attach with a device-generated interim IMSI containing the IMEI portion, and restricted/emergency-only access (B, and claim 5's "at least part of an IMEI").
• HP '146 supplies the source-address comparison and the blocking of packets whose source address is not in the authorized set (F, G-block → claim 11).
• Markham supplies redirecting unauthorized packets to a security server / third party rather than dropping them (G-redirect → claim 1, and claim 13).

For the callback-period and lockout, the Diachina expiration-indication mechanism supplies the predetermined active window and the release of the interim-IP association.

Ground 2 — Claim 4 and claim 10 (outbound filtering: block / redirect)

Primary: Diachina in view of Faccin and Markham. Diachina already describes the bidirectional path ("GGSN receives IP layer PDUs from ESC and forwards them to associated SGSN"; and the mobile's PDUs forwarded to the destination address). Adding destination-address inspection (F, outbound) with block (claim 4) or redirect-to-third-party (claim 10) is the mirror image of the HP '146 / Markham teachings — a textbook KSR "known technique applied to a predictable variant" case.

Ground 3 — Claim 12 (bidirectional method around an ECC)

Primary: Faccin in view of Pecen, Diachina, and Haumont/AT&T '462. Claim 12 merely aggregates Grounds 1 and 2 and adds "(a) requesting and receiving an interim identity from the user device" (Pecen's device-generated interim IMSI), "(b) mapping the level of service access to the interim IP" (Haumont / '462), and "(c) restricting delivery where the level of service is other than emergency" (claim 15's analog). Aggregating separately known limitations into one claim does not confer patentability where the combination is a predictable union of known functions.

Claim-text caveat (flagged earlier, restated): claim 12 as fetched reads "granting the emergency call after each request," an apparent OCR corruption of "emergency call attach request." Any chart should quote the PatentCenter facsimile, not this rendering.

Ground 4 — Claims 17 and 22 (system claims)

Primary: Pecen (WO 02/080499) in view of Faccin and Markham. The "home packet data network … request and receive an interim identity … [and] set a level of service access … to emergency service access only" is Pecen. The "emergency packet data network … assign an interim IP … associate the interim IP with the interim identity … determine at least one authorized IP … route in both directions" is Faccin + Diachina. The "packet filter … operable to pass only those data packets that include both the interim IP and the at least one authorized IP and to at least block all data packets that include the interim IP but not the at least one authorized IP" is Markham's filtering-plus-central-authorization architecture, plus the source-address allow-listing of HP '146. Claim 21's "E‑PDN contained within the GGSN" and claim 16/20's "packet filter separate from the GGSN" are both express alternatives in the '186's own specification ("the E‑PDN 10 can be included within a … GGSN 19"; and "it is preferred that the packet filter functionality is separated from the GGSN"), so they cannot distinguish over art showing either arrangement — and the specification's statement that the filter "should be separated from the GGSN application functionalities" reads as an admission that collocation was the known baseline.

---

IV. Why a PHOSITA would have combined these references

1. Same field, same problem, overlapping disclosures. Faccin, Pecen, Diachina, the '186, and its NPL citations (3GPP TS 24.008; TS 27.060) all address emergency service for GPRS/UMTS devices, and Faccin and the '186 recite the same FCC callback requirement as the animating problem. KSR teaches that combining references that address the same problem in the same field is obvious where the results are predictable.

2. A regulatory mandate supplies an explicit, articulable motivation. The FCC's E911 rules require a callback path for a device with no subscriber identity within a defined window (the '186 itself says "usually forty-five minutes"). That mandate motivated (i) interim identity/IP allocation (Faccin, Pecen), (ii) keeping the packet path open for the callback (Diachina; Faccin), and (iii) closing it afterwards (Diachina's expiration indication). "Set the timer to the regulator's number" is about as predictable as an engineering step gets.

3. Common-assignee / family knowledge. WO 02/080499 (Pecen et al.) and the '186 are both Motorola filings, and the '186 expressly incorporates WO 02/080499. A POSITA working on the '186 would have had the Pecen solution to the access half directly in hand; the Federal Circuit has repeatedly credited common ownership/familiarity as a motivation to combine.

4. The references themselves point to the gap. Faccin explicitly observes that its callback-number technique "does not provide a complete solution … the MSC cannot page the mobile station with a CBN … and therefore needs enhancement by reserving a more complete temporary subscriber identity including also an IMSI or TMSI." That is a teaching-away-free invitation to combine the temporary-IMSI art with the callback-number art. Likewise, HP '146 states the problem of "network access for packets with invalid source addresses" and solves it by allow-listing — precisely the '186's inbound filter.

5. Firewalls/ACLs were notoriously well-known and simple to apply. By 2003, address-based packet filtering (permit/deny rules on source/destination IP) was elementary network engineering; the Federal Circuit treated such filtering as conventional. Adding an ACL bound to a specific interim IP and an ECC IP is a combination of known elements "according to known methods to yield predictable results."

6. Obvious to try. Even if one viewed the particular block-vs-redirect-vs-restrict choice as unproven, KSR makes clear that a finite number of identified, predictable solutions (block; redirect to a third party for review; restrict by service level) renders the claimed alternatives obvious. Notably, the '186 does not assert unexpected results for any of the three; it presents them as equivalent policy options.

---

V. Where the claims might survive (and why I think the arguments are weak)

• "The prior art does not teach killing the pipe after the PDP context ends." The strongest counter to Grounds 1–4 would be that Faccin keeps the callback path alive and does not teach outright prohibition of all traffic post-context. But Diachina's "maintains the association … until it receives expiration indication" supplies a bounded hold-and-release, and the combination of a bounded callback hold with a terminal revocation step is a two-step, predictable sequence; claim 1's "upon termination … prohibiting communication" is essentially the negative image of the E‑PDN not assigning an interim address at all when no valid identity exists (Pecen's restricted-access grant). I would not expect this to carry the day.
• Secondary considerations. I found no evidence in the record before me of commercial success, licensing, copying, or a long-felt-but-unmet need tied with a nexus to the claims, and the patent expired in 2023, which further undermines any nexus-based argument. The only candidate is the regulatory "long-felt need" for SIM-less E911 callback — but Faccin, Pecen, and Diachina all address that need, which is fatal to a long-felt-need argument.
• Prosecution history as a caution light. The '186's own NPL citation list enumerates a Non-Final Office Action (2006‑12‑14), a Final Office Action (2007‑08‑28), an Amendment and Response (2007‑06‑12), and a Request for Continued Examination submission for the sibling application 10/437,667 (US 7,447,765). That record indicates the examiner pressed a substantial rejection in the closely parallel case. I have not reviewed the substance of those actions in this session, and I flag that as a gap — the actual examiner reasoning for the sibling is the best available evidence of how these references were viewed at the time and should be pulled before anyone relies on this analysis.

---

VI. Confidence and limitations

• High confidence that the individual concepts A–I are each disclosed by the cited art, based on the full texts I retrieved for Faccin, Pecen, Diachina, HP '146, and Markham.
• Moderate confidence in the precise mapping of the "level of service access" element (B) to Haumont US 2003/0027554 and AT&T US 6,240,0462, because I verified only their titles/dates from the citation record, not their disclosures.
• Explicit caveat on dating: US 2003/0126468 (Markham) and US 2003/0211839 (Baum) published after the '186's 2003‑03‑31 filing; they are available as §102(e) art only through their earlier underlying filings (PCT/US01/17153, 2001‑05‑25, for Markham; the 2002‑01‑08 priority application for Baum). US 2003/0027554 (Haumont, priority 2000‑08‑02) and US 2002/0142805 / WO 02/080499 (priority 2001‑04‑02, published 2002‑10‑10) are comfortably prior. Any formal rejection must respect these dates.
• One examiner-cited item deserves a flag rather than a reliance: US 2004/0192251 A1 (Yilin Zhao), "Establishing emergency sessions in packet data networks for wireless devices having invalid subscriber identities," is listed among the cited references, but it was filed the same day (2003‑03‑31) as the '186. Same-day filings do not qualify as "before the invention by another" under pre-AIA §102(e), so despite appearing in the citation list it cannot be used as §103 prior art against the '186. It is, however, a sibling disclosure in the same family and is useful only as evidence of what the inventors considered known.

Bottom line. On the record cited in the '186 itself, there is a strong prima facie §103 case. The most efficient ground is Faccin (US 6,571,092) + Pecen (WO 02/080499) + Diachina (US 2002/0163906) + HP (US 5,727,146), optionally + Markham for the redirect variant: the first supplies the invalid-identity emergency PDP session and callback-to-assigned-IP; the second supplies emergency-only restricted access with a device-generated interim identity containing the IMEI; the third supplies the time-bounded interim-IP association and bidirectional ECC packet routing; and the fourth (with Markham) supplies the address-based allow-listing plus block/redirect of unauthorized packets. The claimed contribution over that combination — keeping the emergency PDP context alive for the FCC callback window and then refusing all further packets once it expires — is the predictable application of a known timer to a known filtering architecture, motivated by an express federal mandate that Faccin and the '186 both recite.