US 8745191

I'll search for authoritative information on this patent and any litigation/docket records.

Let me search specifically for the claims of this patent and any litigation naming it.

Let me try to retrieve the actual claim text of this patent.

US 8,745,191 — Summary

Caveat on sourcing: I searched public web sources (Google Patents, Justia, FreePatentsOnline, uspto.report, Unified Patents, CourtListener/PTACTS mirrors). I did not have live query access to USPTO PatentCenter/Full‑Text or the CAFC docket system, so the litigation findings below rest on secondary/published court documents, not on a direct CAFC docket query. Where I could not verify something, I say so.

---

Bibliographic data

Family/continuity: The specification states that application 13/253,013 (the '191) is a continuation‑in‑part of application 12/380,759, filed March 2, 2009, and the family traces to provisionals filed Jan. 28, 2009 (61/206,354), Feb. 4, 2009 (61/206,944), Feb. 10, 2009 (61/207,393), Feb. 13, 2009 (61/207,739), Jul. 6, 2009 (61/270,353), Nov. 24, 2009 (61/264,126), and later filings including 61/348,022 (May 25, 2010) and 61/389,547 (Oct. 4, 2010, "User Notifications for Device Assisted Services"). A continuation was filed as 14/292,282 and published as US 2015/0072641 A1.

---

Abstract (as granted)

"A method comprising storing information about a service plan, the service plan having a limit on usage of at least one of one or more network services, the service plan being associated with an end user device; detecting a device action that reflects or is associated with a past, current, or intended use by the end user device of the at least one of the one or more network services; identifying the device action as a trigger event; identifying notification request information based on the trigger event, the notification request information for use by the end user device in presenting, through a user interface of the end user device, a notification message comprising notification information, the notification information based on the notification request information; and transmitting the notification request information to the end user device in response to the trigger event."

---

Plain‑language overview of the independent claims

Important limitation on this section: I was not able to retrieve the full, verbatim claim set of the '191 from an authoritative source in this session (Google Patents' claim text was not returned in my searches). The following is reconstructed from (a) the patent's own Summary of the Invention, which tracks the independent claims closely, (b) the grant abstract above, which matches the independent method claim, and (c) the identically‑titled continuation US 2015/0072641 A1, which recites the device‑side claim. Claim numbering and exact wording should be verified against USPTO/Google Patents full text before reliance.

The '191 appears to contain at least three independent claims spanning the network side and the device side:

1. Network‑side method claim (aligned with the abstract). A network element stores service‑plan information for an end‑user device where the plan limits usage of one or more network services. It detects a "device action" reflecting a past, current, or intended use of a network service, identifies that action as a trigger event, determines notification request information based on the trigger event, and transmits the notification request information to the device so the device can present a notification message through its own user interface. Key point: the notification request is sent, not necessarily the full message — the message content is separate and is obtained/rendered by the device.

2. Network‑side system claim. A system with memory storing service‑plan information; at least one processor configured to detect the device action, identify it as a trigger event, and identify a notification request based on the trigger event; and a communications interface configured to transmit the notification request to the end‑user device in response to the device action. (The Summary language for this claim uses, in places, the unusual phrasing of "transmitting to the end user device the at least a portion of the notification request," which is the patent's own drafting.)

3. End‑user‑device method claim (from the continuation's claim 1, which is the counterpart device‑side claim). The device stores one or more notification actions corresponding to one or more notification requests. It performs a device action reflecting a past or intended use of the network service. It receives one of the notification requests from a network element in response to that device action. It performs the corresponding notification action, which causes the device to retrieve at least a portion of a notification message associated with the status of the use — the message portion being separate from the notification request — and presents the notification message on a user interface of the device.

Representative limitations appearing in the disclosure as associated with these claims:

• The notification request may include a network destination identifier, and the notification action causes the device to access a server at that destination to fetch the message portion; the network element sends an index (numeric index, alphanumeric string, pointer, GUID, or other indicator) identifying the message portion.
• Alternatively, the notification request identifies the message portion in a local notification store on the device, and the network element configures that local store with the message content.
• The device action may be: a request to access a new network service; exceeding a threshold usage amount of a service (or of a category of services); a roaming event; or a tethering request.
• The end‑user device may be an intermediate device (e.g., a hotspot/tethering gateway), where the device action reflects past or intended use by other end‑user devices connected through it.
• A network service may be classified as a first type before the usage limit is reached and a second type after the limit is reached.
• Usage limits may indicate when a service is no longer available, when a billing rate changes, when an allocation is consumed, or when an allocation is changed.
• Messages may include offers to cancel/modify/replenish/replace the plan, learn more about a plan feature, links to further information, requests to acknowledge a usage amount or new billing rate, and user‑response options.

The specification's broader disclosure (usage monitors at device/gateway/network agents, usage report stores, trigger event detection, service controllers, notification policy management UI) is the supporting "device assisted services" (DAS) architecture, but the claims are focused on the notification request/action/message retrieval mechanism, not the whole architecture.

---

Litigation / docket check (as of the search)

• The Google Patents page carries a "Family has litigation" flag and a Darts‑IP link for the family — that flag attaches to the family, not necessarily to the '191 itself.
• I found no case in my search results that expressly names U.S. 8,745,191 as an asserted patent. Headwater's published infringement contentions and complaint exhibits that appeared in my results asserted other patents, e.g.:
  • Headwater Research LLC v. [[Verizon Communications Inc.](/litigations/by-defendant/Verizon%20Communications%20Inc.), et al.](/litigations/by-defendant/Verizon%20Communications%20Inc.%2C%20et%20al.), No. 2:23‑cv‑00352‑JRG‑RSP (E.D. Tex.) — asserted 8,589,541; 8,924,543; 9,198,042; 9,215,613 (jury verdict July 23, 2025: willful infringement of claim 1 of 9,215,613 and claim 83 of 8,589,541; $175,000,000 lump sum; judgment entered April 23, 2026 holding the asserted claims unenforceable against Verizon under implied waiver).
  • Several 2025 E.D. Tex. actions (Charter/Comcast/Dish/Google/Apple/Amazon, etc.) asserting other Headwater patents.
  • A Headwater notice of appeal in the Verizon case docketed as USCA No. 26‑1884 (May 29, 2026) and then deactivated — again, not the '191.
• I therefore cannot confirm any CAFC 2026 appeal or district‑court assertion specifically involving U.S. 8,745,191. Its closely related siblings (e.g., 9,386,165 and 10,798,252, both titled "System and method for providing user notifications") appear in the same family litigation cluster, but I did not verify whether either was asserted.

Uncertainty flags:

1. Exact, verbatim independent claim text and claim count for the '191 — not directly retrieved; verify at https://patents.google.com/patent/US8745191/en or USPTO PatentCenter for application 13/253,013.
2. Whether the '191 itself has ever been asserted — I found no positive evidence; absence of evidence in my search set is not proof it never was.
3. The 2029‑03‑02 expiration date is Google Patents' assumption based on the priority chain and is not a legal conclusion.

Sources: https://patents.google.com/patent/US8745191/en; https://uspto.report/patent/grant/8745191; https://patents.justia.com/patent/8745191; https://www.freepatentsonline.com/y2016/0373588.html; https://patentimages.storage.googleapis.com/3f/b7/d2/1b6c8f190cbcaf/US20150072641A1.pdf; https://archive.org/download/gov.uscourts.txed.[224022](/patent/224022)/gov.uscourts.txed.224022.473.0.pdf; https://ptacts.uspto.gov/ptacts/public-informations/petitions/[1558526](/patent/1558526)/

I'll research litigation involving US patent 8745191 using multiple sources.

Litigation Involving U.S. Patent No. 8,745,191

Bottom line

I could not identify any litigation in which U.S. Patent No. 8,745,191 ("System and method for providing user notifications") was specifically asserted as a patent-in-suit. Searching patent-litigation trackers, PACER-derived dockets, Law360 case pages, and the Headwater-related briefing surfaced in these searches, the '191 patent does not appear among the asserted patents-in-suit in any case I could locate.

I want to be explicit about the limits of that statement rather than implying more certainty than I have: I was unable to run a definitive, all-jurisdictions docket sweep of the exact string "8,745,191" before exhausting my search budget, and free litigation databases sometimes index patents-in-suit incompletely. So treat this as "no confirmed assertion found," not as an affirmative proof of non-assertion.

Why this patent is nonetheless litigation-adjacent

U.S. 8,745,191 is a Headwater Research LLC patent (original assignee Headwater Partners I LLC; inventors Gregory G. Raleigh, Alireza Raissinia, James Lavine, Jeffrey Green), with a priority date of January 28, 2009 and a filing date of October 4, 2011 (App. No. 13/253,013), granted June 3, 2014. It sits in the large Headwater "device-assisted services" family that has been the subject of an extensive and well-documented assertion campaign. The Google Patents page for the '191 patent even carries a "Family has litigation" flag and a Darts-IP family link — that flag refers to litigation in the family, not necessarily to this specific patent.

The Headwater campaign (context, with the '191 patent conspicuously absent)

Headwater Research has filed numerous infringement suits in the Eastern and Western Districts of Texas. Representative matters I confirmed in the sources retrieved:

The patents actually appearing across these filings are numbers such as 8,023,425; 8,589,541; 8,631,102; 8,635,335; 8,639,935; 8,666,364; 8,667,571; 8,799,451; 9,143,976; 9,154,428; 9,179,359; 9,215,613; 9,232,403; 9,277,445; 9,392,462; 9,491,564; 9,609,510; 9,609,544; 9,615,192; 9,647,918; 9,973,930; 10,064,055; 10,096,055 (11,096,055); 10,237,757; 10,321,320; 10,791,471; 11,405,429; 11,966,464; 11,985,155. U.S. 8,745,191 is not among them in any of the records I retrieved.

Note two nearby numbers that are not the patent you asked about and should not be confused with it:

• 8,745,220 — a distinct Headwater Partners I LLC patent ("Headwater Partners I LLC" family member appearing in the '191 patent's priority chain on Google Patents).
• 8,667,571 — a Headwater patent actually asserted against Apple (W.D. Tex. 7:25-cv-00318 and N.D. Cal.), which sounds similar but is a different number.

Notable outcomes in the related campaign (background)

• Headwater reportedly won a $279 million verdict against Samsung and obtained a $175 million settlement from Verizon (reported in Law360 as of the August 2025 filing spree). I could not independently verify these figures beyond the secondary reporting.
• Headwater v. Apple (7:25-cv-00318) was dismissed by joint motion in late October/November 2025 — Headwater's claims with prejudice, Apple's counterclaims without prejudice.
• Apple Inc. v. Headwater Research LLC (N.D. Cal. 3:25-cv-07591) — declaratory judgment action, terminated November 3, 2025 via stipulated dismissal.
• In the Verizon (Cellco Partnership) matter, the court (E.D. Tex., Marshall Division) issued a ruling in 2026 finding Verizon entitled to equitable relief under implied waiver based on Headwater's delay from its 2017 infringement investigation to its July 2023 suit, while rejecting Verizon's equitable-estoppel theory.

Caveats and recommended next steps

1. The Google Patents "Family has litigation" flag is a family-level flag — it should not be read as evidence that the '191 patent itself was asserted.
2. A precise confirmation would require a PACER/litigation-database query on the exact string 8,745,191 (or 8,745,191), which I was unable to complete here. If you need a documented negative, I'd recommend a paid docket search (Docket Navigator, Lex Machina, or Darts-IP family 45973799) filtered to that patent number.
3. If the '191 patent has been asserted, it would most plausibly be in one of the Texas Headwater complaints whose patents-in-suit lists I did not capture in full — the secondary sources summarized those lists incompletely.

In short: no known litigation involving U.S. 8,745,191 specifically was identified; the patent is a member of a family that has been heavily litigated by Headwater Research LLC, but I found no case asserting this particular number.

AIA Trial Proceedings — U.S. Patent No. 8,745,191

Analyst note on sourcing. The structured "PTAB proceedings on file" block in my instructions is the canonical list and it reports that the USPTO Open Data Portal returns no AIA trial proceedings for US 8,745,191. I ran independent web searches to catch anything ODP has not yet indexed (recent filings, older decisions, CAFC activity). Those searches surfaced a very large Headwater IPR docket — but nothing on the '191 patent. I have not invented any proceeding numbers to fill the gap. Where I cite other Headwater matters, I say so explicitly and identify the patent they actually involve.

Proceedings overview

Total AIA trial proceedings against US 8,745,191: 0 — 0 active, 0 with claims invalidated, 0 claims sustained, 0 settled, 0 institution-denied. As of 2026-09-30 there is no IPR, PGR, or CBM on this patent docketed at the PTAB, no Final Written Decision, no termination, and no Federal Circuit appeal arising from a PTAB trial on the '191 claims. The bottom-line defensive posture: the patent is completely untested at the Board and is not hardened by any prior IPR, but it also carries zero adversarial estoppel — a defendant today has a clean, unfettered § 311 window (subject to the § 315(b) one-year clock) to be the first to attack it.

Proceedings on US 8,745,191

None on file

There is no proceeding to itemize. What I can affirmatively document:

• Structured source (canonical): USPTO ODP ingest shows no AIA trial proceedings for US 8,745,191. Verify independently at PTAB E2E / PTACTS and the patent's USPTO Patent Center record.
• Web-search corroboration: Headwater's assertion campaign (2022–2025) spans dozens of patents and 39+ district court complaints, and Samsung alone reports filing 26 IPR petitions against Headwater patents. None of the petition listings, mandatory-notice related-matter tables, or IPR dockets I reviewed name U.S. Patent No. 8,745,191 as the challenged patent.
• Representative Headwater IPRs I did find (NOT the '191 patent — listed only to show the search was real and where the activity actually sits): IPR2024-00942 on U.S. 8,589,541; IPR2024-01041/-01042 on U.S. 8,924,543; IPR2024-01181 (Lenovo) ; IPR2025-00481/-00482 on Headwater patents asserted by Samsung; IPR2025-01572 on U.S. 10,064,055 (Apple); IPR2026-00106 on U.S. 10,321,320 (Amazon); IPR2026-00153 (Target). These establish that Headwater is a serial PTAB target — which makes the absence of an IPR on '191 a substantive data point, not an artifact of sparse searching.
• The '191 patent also does not appear in the asserted-patent lists from Headwater v. Samsung (2:23-cv-00641), v. T-Mobile/Sprint (2:24-cv-00015), v. AT&T (2:23-cv-00397), v. Verizon (2:23-cv-00352), or the 2025 Apple/Amazon/Google/Comcast/Charter/Dish wave. Headwater has not put '191 in suit in any campaign I could surface, which is the most likely reason no petition exists.

Residual uncertainty (stated honestly): ODP ingest lags newly filed petitions by weeks, and a 2026-filed petition could exist without appearing in my search results. Treat "zero proceedings" as high-confidence but not as verified-live; confirm on E2E before relying on it in a filing.

Strategic summary

Canceled vs. sustained vs. untested. For US 8,745,191 the answer is simple: all claims are untested. No claim has been canceled, no claim has been confirmed, and no claim has been the subject of an institution decision. There is therefore no narrowed "surviving claim set" to build around and no dead claim to attack — the patent stands as issued (all originally issued claims, subject only to ordinary prosecution-history and district-court invalidity defenses). Contrast this with sibling/near-neighbor Headwater notification-family patents that have drawn PTAB fire (e.g., the message-link-server line, including U.S. 9,615,192, which appears repeatedly in the 2025 assertion wave). I have not independently confirmed the priority/continuation relationship between '191 and 9,615,192, so do not treat that as an established family link — it is a lead to verify in the '191 file wrapper.

Estoppel landscape. Because there is no proceeding, no § 315(e)(2) estoppel attaches to anyone with respect to '191. Severally: (i) no petitioner has been estopped, so a new defendant is not "second in line"; (ii) no patent-owner-side amendment (motion to amend or certificate) has narrowed the claims, so there is no prosecution-by-IPR record to mine; and (iii) conversely, Headwater has not been able to use an IPR win to bolster validity and has no PTAB-confirmed claims. Every prior-art ground — anticipation, obviousness, and any § 112 theory that is IPR-eligible — remains fully available to a first petitioner, subject only to § 325(d) (avoid art already before the examiner) and the discretionary-denial overlay discussed next.

Pattern signals. (1) Same petitioner, many patents: Samsung is the dominant petitioner (26 petitions reported; multiple instituted), with Apple, Amazon, Google, Lenovo and the carriers also filing — but the pattern is patent-by-patent, never '191. (2) Patent owner's PTAB posture is defensive, not aggressive: Headwater's strategy in these campaigns has been to request discretionary denial (Fintiv + the Stewart Memorandum considerations), to drop patents from litigation once institution is granted, and to settle instituted IPRs rather than litigate them to FWD — e.g., Samsung's briefing recites that institution on 6 of 9 patents in the first litigation caused Headwater to drop those patents, and that one of the second-litigation IPRs settled. Headwater does not appear to be a serial CAFC appellant on PTAB outcomes. (3) No defensive aggregator visible in the chain for '191 (Unified Patents page references to Headwater appear to be portfolio/tagging pages, not IPRs on '191). (4) Monetization backdrop: reported results include a $279M Samsung verdict and a ~$175M Verizon settlement — Headwater has both the resources and the inclination to assert, and its settlement posture is real (which matters for a defendant weighing IPR-as-leverage).

Recommended next steps

1. Confirm the null result before you rely on it. Pull the '191 docket in PTAB E2E/PTACTS and the Patent Center transaction history for US 8,745,191 (application 13/253,013), and check for any ex parte reexam that would not appear as an AIA trial. (Note: at least one Headwater-family ex parte reexam, 90/015,746, appears in the 2026 record — confirm it is not directed at '191.)
2. If you are a defendant being asserted on '191, move immediately on § 315(b). With no proceedings on file, you can be the first petitioner, which is the strongest procedural position available: no General Plastic serial-petition risk, no § 315(e) estoppel, and full freedom to pick your best art. Calendar the one-year-from-service bar now.
3. Anticipate Fintiv-style discretionary denial, not a merits denial. Headwater's playbook in every campaign is a Patent Owner Preliminary Response arguing (i) the EDTX/parallel-litigation posture, (ii) "settled expectations," and (iii) the Stewart Memorandum's March 26, 2025 workload-management factors, plus (iv) § 325(d). Prepare the petition with a strong merits showing and a Sotera-plus stipulation up front (Samsung's broader-than-Sotera stipulation in IPR2025-00481/-00482 is the model), because in this docket the institution decision — not the FWD — is the real battleground.
4. Watch the sibling-family IPRs for free claim-construction and invalidity intelligence. Even though they are not '191, the instituted/instituted-and-settled proceedings on the notification/message-link and device-assisted-service family patents supply the Board's constructions, the examiner's treatment of the shared specification, and the art with which the family has already been attacked — all directly transferable to an '191 petition.
5. Do not quote a nonexistent FWD. If an opposing demand letter or a plaintiff's damages theory leans on "PTAB-confirmed validity" of '191, that representation is false on the current record — there is no PTAB decision of any kind. Conversely, do not tell a client that any '191 claim is "invalidated"; nothing has been canceled.

Bottom line: no AIA trial activity on US 8,745,191 as of 2026-09-30. The absence is itself informative: in a campaign where 26 petitions have been leveled at Headwater's portfolio, '191 has either never been asserted or has never been worth petitioning — so its validity is an open question a first petitioner can still answer unilaterally.

I'll reconstruct this from the authoritative patent text first, then verify assignment specifics and assertion history via search.

Good context. Now let me pin down reel/frame, correspondent of record, and whether '191 itself has been asserted.

Let me verify the specific reel/frame records, correspondent of record, and whether '191 itself appears in any assertion campaign.

Ownership & Assignment Reconstruction — US 8,745,191 B2

Patent: US 8,745,191 B2 — "System and method for providing user notifications"
App. 13/253,013, filed 2011-10-04; issued 2014-06-03; earliest priority 2009-01-28
Verification sources: the patent's own legal-events record (Google Patents, https://patents.google.com/patent/US8745191/en) and USPTO Assignment Center (https://assignmentcenter.uspto.gov/).

Evidence-quality note up front (important): The Google Patents legal-events feed for this patent exposes the recordation dates, conveyance types, assignors and assignees for both post-filing records, but it does not expose reel/frame or the correspondent of record. I was not able to pull the underlying Assignment Center abstract sheets for '191 before my research budget closed. Reel/frame below is therefore given where independently corroborated, and flagged where it is inferred from portfolio-wide sibling records rather than read off the '191 record itself. Nothing below is invented.

---

Inventors

Unusual patterns — yes, and they are the defining fact of this chain:

• Inverted departure pattern. This is not the classic "all inventors quit the assignee within 12 months" fire-sale tell. It is the mirror image: two of four inventors arrived from Qualcomm within ~12 months of the priority filing. Raleigh left Qualcomm 2008-09-19 and filed the 2009-01-28 provisional months later; Raissinia was still a Qualcomm employee on the priority date.
• Qualcomm's employment agreement contained a one-year post-employment assignment presumption. This produced a multi-year standing challenge. Samsung argued ownership vested in Qualcomm because the applications were filed within one year of the inventors' departures (E.D. Tex. 2:22-cv-00422, Headwater Research LLC v. Samsung, standing R&R). Headwater won the standing fight by proving conception occurred after the inventors left Qualcomm, and Judge Gilstrap's opinion is now the leading authority that corroboration is required only to prove an earlier conception date, not a later one.
• A named inventor later returned to the allegedly wronged party. Raissinia went back to Qualcomm and "still works at Qualcomm today" (per Headwater's summary-judgment briefing). Qualcomm never intervened or sued over ownership.
• Qualcomm tried to acquire the patents. Raleigh testified Qualcomm proposed settling its claim by taking additional ItsOn equity, later tried to buy the patents outright, and eventually let the limitations period run; the deal fell through on price.
• Inventor testimony conflicts. Lavine's deposition ("Greg had written the… provisional applications and had them filed before… they started the company") was used by defendants to attack Raleigh's conception timeline; the court found the testimony mischaracterized.

---

Original assignee

Headwater Partners I LLC — a Delaware limited liability company; original assignee on the face of the issued patent. Address of record at formation: 2995 Woodside Road, Ste. 400, Woodside, CA 94062-2048; later 350 Marine Parkway, Suite 300, Redwood Shores, CA 94065.

• Line of business: No evidence that Headwater Partners I LLC manufactured or sold a product practicing the claims. It was formed in 2008 by Dr. Raleigh to develop mobile operating-system / cloud device-management technology and to hold the resulting IP. The technology was licensed to ItsOn Inc. (a separate company, also founded by Raleigh in 2008), which built and sold carrier-facing software that implemented it. Headwater's own role in the record is as an IP developer/licensor, not a product vendor.
• Status: Dissolved by merger. On 2016-12-29 Headwater Partners I LLC merged with and into Headwater Management LLC, the survivor being renamed Headwater Research LLC (Delaware Certificate of Merger, SR 20167326785, File No. 4966025). Not in bankruptcy; no fire-sale or Article 9 securitization appears in this chain.
• Litigation posture of the portfolio: flag "Family has litigation" is set on the Google Patents record (Darts-IP first-worldwide-family-litigation). Post-2022 the family is the subject of an extensive assertion campaign (details in the signals section).

---

Assignment timeline

Two post-filing records exist. Both are corroborated by the patent's own legal-events feed.

1. Inventors → Headwater Partners I LLC

• Executed: not captured for '191 in the sources reviewed (sibling Headwater assignments in this family were executed between 2011-10-26 and 2011-12-12) / Recorded 2012-01-04 — Reel not confirmed for '191
  • Conveyance: Assignment of assignors' interest ("ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS)")
  • Assignor: RALEIGH, Gregory G.; RAISSINIA, Alireza; LAVINE, James; GREEN, Jeffrey
  • Assignee: Headwater Partners I LLC (Delaware LLC, Woodside CA)
  • Correspondent: not captured — the legal-events feed does not publish it, and I could not retrieve the '191 abstract sheet. ⚠️ Do not treat as "none." The only attorney signature I could tie to this portfolio is Krista S. Jacobsen, Reg. No. 59,374, who signed an Application Data Sheet for sibling application RALEP032C1 (13/134,028) in Nov. 2013 — but that is prosecution correspondence, not the assignment-recordation correspondent, and it must not be conflated.
  • Context: Founder/inventor-to-company assignment; standard original acquisition, not a transfer to a third party.

2. Headwater Partners I LLC → Headwater Research LLC

• Executed 2016-12-29 (Merger Agreement dated as of 2016-12-29; Delaware merger effective 3:02 p.m. that day) / Recorded 2017-01-04 — Reel 041248 / 0777
  • Conveyance: Merger and Change of Name (per the USPTO "NATURE OF CONVEYANCE" box on the filed cover sheet, effective date 12/29/2016)
  • Assignor: HEADWATER PARTNERS I LLC and HEADWATER MANAGEMENT LLC
  • Assignee: Headwater Research LLC (surviving entity; Delaware LLC)
  • Correspondent: not captured. The merger cover sheet I recovered is truncated at "Marc A." and I will not speculate on a surname or firm.
  • Reel/frame caveat: Reel 041248/0777 is the recordation cited on sibling Headwater merger abstracts (e.g. app. 14,667,516 / 16/740,625 and E.D. Tex. 2:23-cv-00641 Dkt. 170-7). Because the merger was recorded portfolio-wide, the same reel/frame almost certainly covers '191 — but I did not read the '191-specific entry, so treat the reel/frame attribution as high-probability, not verified.
  • Context: Internal reorganization / change of name only. No new economic party entered the chain; the practical effect is that the surviving entity was re-branded from an operating-adjacent holding company (Partners I) to a portfolio/assertion vehicle (Headwater Research). Delaware certificate signed by Greg Raleigh for Headwater Management LLC.

No further assignments are recorded. In particular, there is no transfer to Headwater Partners II LLC (the separate entity that filed the 2024 Verizon/AT&T/T-Mobile suits on other patents in the family), and no transfer to any third-party licensing entity. The chain has terminated at Headwater Research LLC and has been static since 2017.

---

Timeline diagram

timeline
    title Ownership of US 8745191
    2008 : Raleigh forms Headwater
    2009 : Priority date Jan 28
    2011 : Application 13253013 filed
    2012 : Inventors assign to Headwater Partners I
    2014 : Patent US 8745191 issues
    2017 : Merger creates Headwater Research LLC
    2022 : Headwater Research begins assertion suits

---

NPE / troll-pattern signals

1. Shell-entity transfer — PRESENT (qualified).
There is a shift from a development/holding entity to a pure portfolio-and-assertion entity, but it did not take the form the signal describes (no sale to an unrelated licensing LLC). It was an internal Delaware merger, recorded as Merger and Change of Name at Reel 041248/0777 (executed 2016-12-29, recorded 2017-01-04). The current assignee is a Delaware LLC with no products in commerce, whose address of record in PTAB filings is c/o Farjami & Farjami LLP, 26522 La Alameda Ave., Suite 360, Mission Viejo, CA 92691 — a law-firm c/o address rather than an operating premises, which is a genuine shell-adjacent tell. Counterweight: the LLC is founder-controlled (Raleigh), not anonymous. Qualified present.

2. Known asserter in the chain — NOT PRESENT as defined; UNCLEAR beyond the named lists.
Headwater Research LLC does not match any of the enumerated lists (Acacia, Marathon, IV, IPNav, Wi-LAN, Mosaid/Conversant, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, Document Generation Corp, Spangenberg entities). It is an inventor-founded, self-funded asserter, not a portfolio-acquisition vehicle. However, it matches the behavioral definition of a high-frequency plaintiff: dozens of infringement suits filed 2022–2026 against Samsung, Verizon, AT&T, T-Mobile, Motorola, Google, Amazon, Comcast, Charter and Apple across E.D. Tex., W.D. Tex. and N.D. Cal. (see, e.g., E.D. Tex. 2:23-cv-00352; 2:25-cv-00897 through 2:25-cv-00919). I could not confirm an RPX or Unified Patents "high-frequency plaintiff" designation from the sources I reached — mark unclear on that specific cross-reference.

3. Repeat correspondent across the chain — NOT PRESENT / INSUFFICIENT DATA.
The chain has only two links, and I could not retrieve the assignment-recordation correspondent for either. There is therefore no recurrence to cite, and I decline to infer one. (Litigation counsel of record — Russ August & Kabat (Marc Fenster) with Miller Fair Henry PLLC as local counsel — is a litigation firm, not an assignment-recordation firm, and is not evidence on this signal.)

4. Cascading transfers — NOT PRESENT.
Two records over five years (2012-01-04, 2017-01-04), both to entities within the same founder-controlled corporate family. No chained LLCs, no shared registered-agent pattern, no <24-month cascade.

5. Pre-litigation transfer — NOT PRESENT.
The only structural change (merger, effective 2016-12-29) predates the first assertion suits (2022) by roughly five years. Notably, this is the opposite of a clean-standing set-up: the court in Headwater v. Verizon (E.D. Tex. 2:23-cv-00352) found Headwater knew of Verizon's infringement by 2017 and delayed suit to capture the full six-year § 286 damages period, granting equitable relief on implied waiver. That is a delay-for-damages finding, not a transfer-to-enable-assertion finding.

6. Bankruptcy fire-sale — NOT PRESENT.
No Chapter 7/11 proceeding, no § 363 sale, no security agreement or lien recorded against this patent in the chain.

7. Privateering — NOT PRESENT (and arguably inverted).
This is not an operating company parking patents with a third-party NPE to sue competitors. Headwater is the inventor's own company, and the interesting inversion is that Verizon and Qualcomm were investors/partners in Headwater and ItsOn before becoming defendants — Verizon paid ItsOn >$4M in 2010 and took equity in both Headwater and ItsOn; the court nonetheless rejected Verizon's equitable-estoppel and waiver defenses premised on those investments.

8. Defensive aggregator (anti-NPE) — NOT PRESENT.
The chain does not terminate at RPX, AST, LOT, Unified Patents or OIN. Headwater Research LLC is an active plaintiff, not a neutralizer.

---

Verdict

NPE — moderate confidence.

The determinative facts are that the record chain ends at Headwater Research LLC, a Delaware LLC with no products in commerce, created by internal merger (Merger and Change of Name, executed 2016-12-29, recorded 2017-01-04 at Reel 041248/0777), and that this owner has run a sustained, high-volume assertion campaign since 2022 in which a federal court expressly characterized it as a "sophisticated patent-assertion entity" and found it delayed suit to maximize recoverable damages. That is one strong signal (non-practicing assertion entity at the end of the chain) plus weak supporting signals (law-firm c/o address of record; sister entity Headwater Partners II LLC spun up in 2024 to assert other family members), but the enumerated chain-based signals — shell transfer to an unrelated LLC, listed-NPE match, repeat assignment correspondent, cascading transfers, pre-suit transfer, bankruptcy — are absent, and I could not verify the correspondents of record that would be needed to elevate this. Because the campaign's scale and the judicial characterization cut toward "high," this is a defensible borderline call, but on the assignment-chain evidence alone, moderate is the honest grade.

⚠️ Two things to finish verification: (1) the Assignment Center abstract sheets for app. 13/253,013 to capture the correspondent of record and reel/frame for both records — this is the single highest-value missing data point, and the signal-3 recurrence test cannot be run without it; (2) confirm whether US 8,745,191 itself has ever been asserted — none of the Headwater asserted-patent lists I recovered ('541, '543, '042, '613, '544, '935, '918, '571, '364, '976, '250, '177, etc.) include the '191 patent, which would be mildly exculpatory.

Verify at: https://assignmentcenter.uspto.gov/ (search by patent number 8745191) and cross-check https://patents.google.com/patent/US8745191/en (Legal Events).

I'll research the prior art cited on the face of US 8,745,191 and in its prosecution. Let me run several targeted searches.

Let me search for the citation list more specifically.

Let me try to pull the actual citation lists from patent databases.

I hit my search-budget limit before retrieving the verbatim front-page citation list for this patent, so I'm going to be explicit about what I verified, what I could not verify, and what I will not do (fabricate per-reference § 102 mappings). Here is the honest result.

---

1. USPTO/originality check on the number "8745191" — including a literal-match false positive you should be aware of

Confirmed target patent (matches the authoritative full text supplied):

⚠️ Literal-string false positive. A search for the bare string 8745191 also returns AU 8745191 A (publication 1992-05-20), which is an Australian application number in the family of WO 92/06653 / EP 0811359 (a biomedical implant "three-dimensional skeleton" case). That is not US Patent 8,745,191 and must not be substituted for it. Likewise, US 8,745,220 (another Headwater Partners I patent) is a different number and is not this patent. Per the operating rule, I have not auto-corrected or merged any of these.

---

2. What I was and was not able to retrieve about the '191 citations

Not retrieved (blocking the requested per-reference analysis): the '191's own "References Cited" block — i.e., the U.S. patent documents, U.S. application publications, foreign documents, and other publications listed on the face of US 8,745,191, together with any examiner-applied art from the 13/253,013 file.

Why this matters: the task asks me to map each cited reference to the claim(s) it potentially anticipates under 35 U.S.C. § 102. That mapping requires the actual reference identities. I do not have them. Producing a numbered list of references and § 102 anticipations from memory would be fabrication, and I will not do it.

Relevant material I did surface (so you can see the trail I ran and pick it up):

1. Same-examiner sibling with a published citation list. Justia's page for US 10,798,252 ("System and method for providing user notifications" — a sibling in the same Headwater notification family) lists a very large References Cited set of U.S. patents/publications. Because the '191, the '252, and the pending continuation share the same inventor family and the same examiner (Rudy, Andrew J.), that list is the best available proxy for what the office considered against this disclosure — but it is a proxy, not the '191's own citations, and I have not verified the overlap.
2. IDS in the direct continuation. The Information Disclosure Statement filed in 14/292,282 (the '191's direct continuation, filed 2014-05-30, examiner Rudy, Andrew J.) appeared via a Docket Alarm mirror. The OCR was badly garbled; only fragments were legible (apparent entries such as 9,135,037; 9,172,553; 9,177,455; 2005/0060525; 2006/0200663; 2007/0061800; 2007/0255769). I do not treat these as reliable and I did not map them to claims.
3. Forward citations (the '191 as prior art to later patents). The '191 appears in the Referenced Cited lists of later patents, including US 9,961,096 (Cisco, "Distributed behavior based anomaly detection") and on Justia's lists for US 10,129,273 and US 10,873,508. These are citations to the '191, not by it, and they say nothing about § 102 against the '191.

---

3. The strongest verifiable signal about the relevant prior-art field

The one authoritative thing I can give you that bears directly on § 102 is the classification the office assigned to the '191 (from the Google Patents full text supplied):

• H04M 15/852 — Notification aspects … Low balance or limit reached
• H04L 12/1417 — Advice of charge with threshold, e.g. user indicating maximum cost
• H04L 12/1414 — Indication of costs in real-time
• H04L 12/1435 — Metric aspects … volume-based
• H04M 15/66 (Policy and charging system), H04M 15/8038 (Roaming/handoff), H04W 4/24, H04W 12/08, G06Q 30/016

These classes define the examiner's field of search and therefore the category of art most likely to have been cited and most likely to anticipate. Concretely, the art with true § 102 potential against claims 1/13/20-type limitations would be within:

• Advice-of-charge / real-time cost-threshold notification systems (network computes usage against a plan limit and pushes a threshold notification to the handset) → directed at the "detect a device action … identify as a trigger event → transmit notification request" limitations.
• Volume-based quota/limit notification systems (e.g., carrier "80% of your data allowance" alerts, 3GPP/OMA charging-notification schemes) → directed at "usage limit / billing rate changes / allocation consumed."
• Art where a network trigger is separate from the displayed message and the device fetches or renders the message from a URL/index or local store → directed at the distinguishing limitations of the '191 (notification request separate from notification information; network destination identifier; index; local notification store).

I am labeling this as claim-element → art-category framing, not as a citation-by-citation § 102 chip shot, because I do not have the reference identities.

---

4. Exactly how to obtain the '191 citation list (so the per-reference § 102 table can be completed)

1. Google Patents (fastest, has both directions): https://patents.google.com/patent/US8745191/en — scroll to the "Patent Citations" table (backward citations) and "Cited By" (forward citations). The "Similar Documents" and "Priority/Same-family" tables are separate and should not be conflated.
2. Justia: https://patents.justia.com/patent/8745191 → Referenced Cited block.
3. FreePatentsOnline: https://www.freepatentsonline.com/8745191.html → front-page "References Cited."
4. USPTO PatentCenter: patentcenter.uspto.gov → application 13/253,013 → Documents & Transactions → locate the filed PTO/SB/08a (IDS) and any examiner PTO-892 / Notice of References Cited. The PTO-892 is the authoritative record of what the examiner actually applied, and the "Applicant's IDS" shows what was merely disclosed.
5. USPTO Patent Public Search: ppubs.uspto.gov — search the exact string US8745191 (not 8745191 alone, to avoid the AU 8745191 false positive), and pull the full-text "References Cited" and "Examiner's search" fields.
6. Family/litigation cross-check: Darts-IP family 45973799 (the link on the Google Patents page) for any IPR/PGR prior-art record; note that the Google "Family has litigation" flag is family-level and, consistent with the earlier analysis, I found no case asserting the '191 itself.

---

5. Caveats and contradictions

• I could not complete the specific deliverable you asked for (per-citation § 102 mapping). The reason is retrieval, not analysis. Everything in § 3 above is framed as claim-element → art-category, explicitly not as identified references.
• Contradiction flag (dates): the previously generated sections describe events dated after the "current date" stated in this task (e.g., a judgment dated 2026-04-23 and a notice of appeal docketed 2026-05-29, versus a task date of 2026-04-26). I cannot reconcile these and did not rely on either for the prior-art analysis.
• Sourcing caveat: the claim-limitation framing in § 3 rests on the patent's own Summary/abstract and the same-family continuation, because the verbatim claim set was not independently retrieved in this session either — consistent with the earlier flag that claim text should be verified at the sources in § 4.
• I have not auto-corrected any number. US 8,745,191 ≠ AU 8745191 A ≠ US 8,745,220.

If you can drop the front-page "References Cited" list (or the PTO-892) into the thread, I will produce the full reference-by-reference table — citation, publication/filing date, brief description, and the specific claim(s) each reference potentially anticipates under § 102 — against the '191's independent claims.

I'll gather prior-art references relevant to the '191 claims before building the §103 analysis.

Let me pull the specific prior-art references cited during prosecution of the '191 and its siblings.

Let me try to retrieve the actual cited-references tables and any PTAB/IPR prior-art record for this patent.

Obviousness Analysis — U.S. Patent No. 8,745,191 under 35 U.S.C. § 103

Analyst note on the record used. The task directs me to use "the results from the Prior Art section of this page." The Google Patents page for US 8,745,191 as fetched exposes only the "Prior art keywords: service, notification, usage, network, information" metadata and the family/priority chain; the "Patent Citations" table itself did not render in the fetched text. I therefore reconstructed the prior-art record from (a) the patent's own specification, which expressly identifies and discusses prior art; (b) the citation lists surfaced for the '191 and its family (Justia's citation table for 8,745,191; the IDS "Other Publications" list appearing across the Headwater family); and (c) independently known pre-2010 references that are within the field and are IPR-eligible (§ 311(b): patents and printed publications only). The verbatim claim set and the verbatim PTO citation table still need to be pulled from PatentCenter/Global Dossier before any filing-grade use. I flag every place where I am inferring.

Date discrepancy flagged (not auto-corrected): the system header gives today as 2026-09-30; the task block states April 26, 2026. The analysis is date-insensitive, but the two should be reconciled in the final work product.

---

1. Governing law and the critical date

Critical date. This is the single most important variable in the analysis, and it is contestable:

• The claimed subject matter is a CIP addition. The specification and family records show a provisional titled "User Notifications for Device Assisted Services," Application No. 61/389,547, filed October 4, 2010 (RALEP035+). That provisional is the natural § 112 support for the notification-request/notification-action claims.
• The earlier provisionals (61/206,354 filed Jan. 28, 2009; 61/206,944 Feb. 4, 2009; 61/207,393 Feb. 10, 2009; 61/207,739 Feb. 13, 2009) are titled "Services Policy Communication System and Method" and, on their face, are about service policy provisioning — not about a network element sending a notification request that causes the device to retrieve message content.
• Working assumption: the effective filing date for the independent claims is October 4, 2010, with a fallback argument available to patentee for January 28, 2009. The two dates materially change which references qualify, so I analyze against October 4, 2010 as the conservative (patentee-friendly-to-challenger-neutral) date and flag where the 2009 date would remove art.

POSITA. A person having ordinary skill in the art as of Oct. 2010 would have a bachelor's degree in EE, CS, or a comparable field and 2–4 years of experience in wireless data networking, network charging/billing architecture, and client-server (device/network) systems, or equivalent. Familiarity with 3GPP policy-and-charging architecture and with mobile push/data-messaging standards would be routine baseline knowledge, not an inventive contribution.

Element chart (from the reconstructed claim set — see the earlier Summary section, whose claim reconstruction I adopt and build on rather than repeat). The independent claims require, in substance:

The inventive core that any § 103 ground must reach is E4–E6 read together: decoupling the trigger/request from the message content, so that what crosses the airlink is a compact request/identifier and the device locally or remotely obtains the content. Everything else (monitoring, limits, thresholds, service plans) was a crowded art.

Corroboration that the field was crowded: the '191's own CPC assignments include H04M 15/852 — "Low balance or limit reached" and H04L 12/1417 — "Advice of charge with threshold, e.g. user indicating maximum cost." Those are classification-level admissions that notifying a subscriber of a usage/limit condition was a recognized, populated art by the priority date.

---

2. The prior-art record I could verify

What I could NOT establish: I did not find an IPR/PGR petition challenging the '191, and therefore no petitioner-framed ground exists to borrow. The PTAB petition documents that surfaced in my searches (1558372, 1558368, 1558369, 1556677, 1548688, 1558526) concern other patents' subject matter (in-vehicle message notification; PCT/Austin-Lane stock alerts) and are not directed at the '191.

---

3. Grounds of rejection

Ground 1 — Network-side independent claim (E1–E6): EPA1/EPA2 (or EPA7 usage-notification art) in view of EPA4 (push-with-URI)

EPA1/EPA2 supply E1–E3 and the reason for a notification. TS 23.203 defines the PCRF/PCEF/OCS triad that (i) stores per-subscriber policy and charging data including a usage limit/spending limit, (ii) monitors usage at the PCEF, and (iii) detects a threshold condition — including on a per-service/flow basis — and emits a policy/charging trigger. A "device action that reflects a past, current, or intended use" is exactly what the PCEF inspects: the service-data-flow request (an intended use) and the accumulated volume (a past use). Pre-AIA § 102 art need not label it a "device action"; the inquiry is what the reference discloses.

EPA4 supplies E4–E6. WAP Push is not a network-charging document, but it discloses precisely the decoupling the claims require: the network transmits a compact push containing a URI (a "network destination identifier") rather than the message body, and the device dereferences the URI to retrieve the content and render it through the device's UI. That is E4 (notification request information), E5 (device presents a message based on the request information), and E6 (transmission of the request, content separate) in the same terms.

Combination is a plug-in, not a redesign. EPA1/EPA2 already determine when and to whom a notification must go; EPA4 tells the artisan how to deliver it efficiently on a wireless network. Substituting a push-with-URI transport for a fully-formed message requires no change to the monitoring, trigger, or policy layers — the trigger output is simply routed into the push bearer instead of into an SMS/message body.

Motivations (MPEP 2143 factors):

1. Air-interface/network economy — the '191's own specification identifies the motivating problem (network capacity is constrained; increases are not commensurate with demand). Sending a short index rather than a full localized message is the ordinary way to conserve capacity.
2. Content dynamism and freshness — the '191 repeatedly stresses that offers, rates, and plan terms change. A request/identifier lets the network update message content unilaterally, without re-provisioning the device. That is the stated purpose of EPA6 (dynamic alert definitions) and the inherent benefit of a dereferenced URI.
3. Reuse of an existing, standardized mechanism — WAP Push was ubiquitous carrier infrastructure by 2010; using it for usage notifications avoids building a parallel transport.
4. Thin-client / server-authoritative design — keeping offers and pricing logic on the server while the device renders them is a known architectural preference where the operator must retain control of the commercial content (a theme throughout the Headwater family's own background).
5. Enabling richer, branded, interactive UIs — the '191 claims UI-level interactivity (acknowledgment buttons, plan-choice buttons). Server-defined markup rendered locally is the ordinary way to achieve that.

Reasonable expectation of success. Both references are software/protocol-level; the combination is the routing of one output into an existing bearer. No new physics, no unpredictable result.

---

Ground 2 — Local-notification-store dependents: Ground 1 further in view of EPA6 and client-side template catalogs

The dependent limitation "the notification request identifies the at least a portion of the notification message in a local notification store" is met by well-established indexing architectures, any of which supplies the missing teaching:

• SNMP trap + MIB object identifiers — a network element sends a numeric/alphanumeric OID; the managed device resolves the OID to locally-stored text/behavior.
• SIM Toolkit (STK) proactive commands — the network sends a command referencing pre-stored display text on the UICC.
• OMA Device Management / client message catalogs — server-sent tokens resolving to locally cached strings.
• EPA6 — extensible document definitions supplying the message structure dynamically.

Motivation: avoid an airlink round-trip (latency and cost), allow the notification to be presented when the device is not able to reach the server, reduce bandwidth for the operator, and support localization without transmitting localized text. This is a classic bandwidth/latency/robustness tradeoff — squarely a KSR "known technique, predictable result" situation.

---

Ground 3 — Device-side independent claim (the notification-action claim)

The family's device-side independent claim language (verbatim, from the RALEP035 continuation chain, US 2023/0046839 A1 claim 1 — not verified as identical to the '191's own claim 1) recites:

"storing on an end user device one or more notification actions corresponding to one or more notification requests … receiving by the end user device one of the one or more notification requests from a network element in response to the device action … performing … one of the one or more notification actions … causing the end user device to retrieve at least a portion of a notification message … the at least a portion of the notification message being separate from the one of the one or more notification requests; and presenting the notification message on a user interface of the end user device."

This is the same inventive content seen from the client side, and is met by the same EPA4-type teaching (the device receives a push/request and dereferences it to fetch content). The only additional building blocks are:

• A push receiver + URI client on the device — standard WAP Push client behavior.
• A mapping table of "notification actions ↔ notification requests" — a lookup table; no more than routine programming. Ground 2's catalogs supply it directly.

Ground 3 therefore stands or falls with Ground 1, with no additional independent contribution.

---

Ground 4 — The dependent limitations

Each of these is a single-reference or single-reference-plus-routine-implementation limitation, and none adds an element that changes the character of the claimed invention. They would be obvious individually and a fortiori in combination.

---

4. Consolidated motivation-to-combine statement (for an expert declaration)

A POSITA as of Oct. 2010, facing the acknowledged problem of notifying subscribers of usage-limit events on capacity-constrained wireless networks with limited-cost/ambient plans, would have:

1. Looked to the 3GPP PCC/charging architecture (EPA1/EPA2/EPA3) because it is the industry-standard source of the usage limit, the monitoring point, and the threshold trigger, and it already contemplates notifying/asking the subscriber;
2. Looked to the network's existing push/data-messaging layer (EPA4) because it is the standard, already-deployed mechanism for delivering a server-originated notification to a mobile device without consuming a full message-sized airlink payload;
3. Recognized that transmitting an identifier and letting the device resolve it (whether to a remote URI or a local catalog) is the ordinary, beneficial design because it conserves airlink capacity, keeps fast-changing commercial content under network control, supports richer/interactive UI, and follows from the well-known thin-client pattern; and
4. Implemented the mapping of trigger types to notification payloads as a lookup table — the routine implementation of a decision already made.

Every step yields predictable results, uses known components, and was within the ordinary skill of a network-services engineer. KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007).

---

5. Anticipated rebuttals

1. "The prior art sent the whole message; the claims require the request to be separate from the message."
   The strongest non-obviousness argument, but WAP Push defeats it: a push carrying a URI that the device dereferences is a request separate from the content — literally E4–E6. EPA6 defeats it too for server-defined, dynamically generated client-rendered alerts. Any "the combination changes the principle of operation" argument would fail because the operation (detect condition → notify user) is unchanged; only the transport and content-sourcing change.

2. "The trigger must be a device action, not a network-observed condition."
   Pre-authorization/credit-control on a new service request (an intended use) is exactly a device action observed by the network element; and the asserted claims are drafted to cover network-side detection ("detecting a device action"), which is what a PCEF/OCS does.

3. "The claims require the device to retrieve; the art merely delivers."
   The "retrieve" verbs are the crux of the dereference step in EPA4 and the local-store lookup in Ground 2.

4. Secondary considerations. Expect an argument based on commercial success and copying (the Headwater portfolio's large licensing/verdict footprint — a reported $175M Verizon outcome and a reported Samsung verdict per the earlier Litigation section). KSR/In re GPAC require a nexus between the evidence and the claimed feature. The portfolio's commercial traction appears driven by the device-assisted-services platform as a whole, conspicuously not by the notification-request/retrieval mechanism, and the nexus must be established feature-by-feature — a substantial burden. Note also that the earlier Litigation section found the '191 itself not identified as asserted, weakening any "industry copied this claim" story.

5. Non-§ 103 defenses I would flag but do not analyze here: § 101 eligibility (the claims arguably recite the abstract idea of "notify the user when a limit is reached," implemented with generic networking/serving steps — Alice step two would be contested), and § 112 written-description support for the CIP-added claims if the 2009 provisionals do not support them. These are separate workstreams.

---

6. Explicit limitations, caveats, and cross-section flags

1. ⚠ Same-inventor/§ 102 disqualification risk for the reference the '191 itself calls prior art. The specification states that US 2010/0198698 ("Adaptive Ambient Services") discloses the ambient-service techniques on which the notification environment builds. That application is Raleigh et al. — the same inventive entity as the '191 (Raleigh, Raissinia, Lavine, Green) and shares the Jan. 28, 2009 priority. Under pre-AIA § 102, an application is § 102(e) art only if "by another"; a same-inventive-entity reference is not § 102(e) prior art. I therefore do not rely on 2010/0198698 as the primary reference and use it only as background/evidence of the state of the art and of the problem, which is how the patentee's own specification uses it. Verify inventorship line-by-line before relying on it in any substantive filing.
2. Verbatim claims not retrieved. My element chart is built on the grant abstract (which matches the network-side independent claim) and the reconstructed claim set in the earlier Summary section, plus the verbatim device-side claim language I found in the RALEP035 continuation chain (US 2023/0046839 A1, claim 1). The '191's own claim 1 may be the network-side or the device-side claim — I have not confirmed which. Confirm before filing.
3. EPA7 candidate references verified only as citations, not as disclosures. I confirmed that the Scherzer / Kashanian / Ahmed / Baker / Aaltonen / Davis publications appear on the face of the '191 per Justia, but I did not verify their specifications or their pre-critical-date US filing dates. Under pre-AIA § 102(e) they can only be art if their US filing dates precede the critical date. Do not treat them as qualifying art without a date check.
4. The "family has litigation" flag is family-level. Consistent with the earlier Litigation section: no case asserting the '191 specifically was identified. The Google Patents Darts-IP family link attaches to the family (Darts-IP family 45973799), not to this patent. There is no contradiction between the two earlier sections on this point, and this analysis does not repeat their litigation findings.
5. No IPR petition located for the '191. Grounds above are constructed from printed publications and patents, all of which satisfy the § 311(b) eligibility limit for inter partes review.
6. Expiration assumption unchanged. The 2029‑03‑02 date on Google Patents is the site's own assumption from the priority chain and remains a non-legal estimate; it does not affect this § 103 analysis.

---

7. Bottom line

Strong prima facie obviousness case on the independent claims, resting on a two-reference core: usage-limit detection and notification-triggering art (EPA1/EPA2/EPA3, alternatively the EPA7 usage-notification publications) in view of push-with-identifier/dereference art (EPA4, alternatively EPA6). The point of novelty — separating the notification request from the notification message content and having the device retrieve the content — is squarely disclosed by the push-with-URI mechanism, which was standardized, ubiquitous carrier infrastructure well before the critical date. Grounds 2–4 dispose of the dependents with routine-implementation and single-reference teachings, with EPA5 supplying the roaming-notification limitation nearly verbatim and EPA1/2010/0198698 supplying the service-plan-offer and post-limit class-change content (subject to the same-inventor caveat in § 6.1).

The most probable patentee rebuttal is a nexus-based secondary-considerations argument keyed to the Headwater platform's commercial traction; its weakness is that the nexus must run to the notification-request/retrieval feature specifically, and no litigation asserting this patent has been identified.

Recommended next steps: (1) pull the verbatim claim set and the PTO "References Cited" table for 13/253,013 from PatentCenter/Global Dossier; (2) verify the filing dates and disclosures of the EPA7 publications; (3) confirm inventorship overlap for 2010/0198698 before using it for anything beyond background; (4) reconcile the 2026‑04‑26 / 2026‑09‑30 date discrepancy.

---

Sources: https://patents.google.com/patent/US8745191/en · https://patents.justia.com/patent/8745191 · https://patents.justia.com/patent/[10798252](/patent/10798252) · https://patents.justia.com/patent/[9386165](/patent/9386165) · https://www.freepatentsonline.com/y2012/0101952.html · https://www.freepatentsonline.com/WO2012047932.html · https://www.patents-review.com/a/20230046839-system-method-providing-user-notifications.html · https://patents.google.com/patent/[US10200541](/patent/US10200541) · https://patents.google.com/patent/[US9225797](/patent/US9225797) · https://patents.google.com/patent/[US8406748](/patent/US8406748) · https://portal.unifiedpatents.com/patents/patent/US-[11750477](/patent/11750477)-B2 · https://www.docketalarm.com/patentapps/US/16-213,800/System_and_Method_for_Providing_User_Notifications/ · https://www.docketalarm.com/patentapps/US/14-292,282/SYSTEM_AND_METHOD_FOR_PROVIDING_USER_NOTIFICATIONS/ · https://ptacts.uspto.gov/ptacts/public-informations/petitions/1558372/ · https://ptacts.uspto.gov/ptacts/public-informations/petitions/1548688/