US 12368799

I'll search for authoritative information on this patent and any related litigation.

Let me check the Federal Circuit docket and case details.

Let me look for the actual claim text to describe the independent claims accurately.

US Patent 12,368,799 — Summary Report

Verification & header data

Continuity chain (per the specification): US 18/984,041 is a continuation of US 18/896,197 (filed Sep. 25, 2024), which is a continuation-in-part of US 18/483,670 (Oct. 10, 2023), a continuation of US 18/193,163 (Mar. 30, 2023), a continuation of US 17/279,188 (Mar. 24, 2021), which is the U.S. national-stage entry of PCT/US19/52847 (Sep. 25, 2019), claiming priority to provisional 62/737,315 (Sep. 27, 2018).

Classifications: H04M1/72436, H04M1/72445 (SMS/RCS/browser UI on mobile phones); H04W12/06 (authentication); H04W4/12, H04W4/14 (messaging / SMS); H04W4/20 (auxiliary data signalling).

Family members referenced on the record: US20250119493A1, US12,438,978B2 (from application 19/192,732), and US20260012531A1 (from 19/324,477).

---

Abstract (as granted)

Systems and methods for receiving a request to provide content to at least one authorized recipient; generating a customized message comprising at least one action associated with the content; causing transmission of the customized message to a mobile computing device associated with the at least one authorized recipient; requesting authorization data corresponding to the at least one authorized recipient; responsive to receiving the requested authorization data: verifying that the authorization data correlates to an identity of the at least one authorized recipient or an identity of the mobile computing device; determining a classification of the at least one authorized recipient; and generating a Rich Communication Service (RCS) message comprising the content; and scheduling, using a machine learning model and based on the determined classification, delivery of the RCS message to the mobile computing device.

---

Plain-language overview of the independent claims

⚠️ Important caveat: The claim set is not reproduced in the authoritative text supplied to me, and I could not retrieve the verbatim granted claim language for every independent claim. What follows is grounded in (a) the patent's own Summary section, which mirrors the independent claims nearly word-for-word, and (b) a third-party analysis of the district-court complaint (not authoritative for claim text). Claim numbering below should be treated as probable, not confirmed. The claim text should be verified against the USPTO PatentCenter / grant document before being relied upon.

The patent appears to carry at least three independent claim families plus at least one additional independent method claim:

1. Independent method claim (~claim 1) — "RCS campaign with ML-scheduled delivery"
Receive a request to provide content to an authorized recipient; generate a customized message with at least one action (link, button, carousel, quick reply) associated with that content; send the message to the recipient's mobile device; when the user selects the action, request authorization data for that recipient; if the authorization data checks out against the recipient/device identity, classify the recipient; then generate an RCS message containing the content and schedule its delivery using a machine-learning model based on that classification. (E.g., a text with a carousel offering to complete a purchase or resume an abandoned journey, sent back as a rich RCS message at a time the ML model predicts the user will engage.)

2. Independent system claim — "Automated messaging subscription and distribution system"
Same pipeline recast as a processor + memory system: request content for a service subscriber → customized message with an action → transmit → on selection, request subscription data → verify the subscription data correlates to the subscriber/device identity → classify the subscriber → generate RCS content based on the classification → ML-scheduled delivery.

3. Independent non-transitory computer-readable storage medium claim
Same pipeline recast as program instructions, using "at least one link" as the actionable element, with subscription-data verification, classification, RCS generation, and ML-based scheduling.

4. Independent method claim (~claim 18) — "Silent Network Authentication Protocol (SNAP)"
This is the claim that matches the patent's title and FIG. 18. Per the complaint analysis (not authoritative claim text): generate a customized webpage with transaction information for a subscriber; generate and transmit a message containing a link to perform the transaction; receive a request from the client device to perform the transaction via the link; cause initiation of a silent network authentication protocol comprising (i) generating a security code packet containing a subscriber network credential and a client device carrier identifier, (ii) transmitting that packet to an authentication service provider (e.g., the mobile carrier), and (iii) receiving an indication that the credentials match or fail to match existing records; and perform the transaction responsive to a match. On a failed match, the specification describes falling back to alternative authentication (e.g., an SMS/MMS/RCS-delivered PIN or access code, or non-cellular/Wi-Fi paths).

Note on claim 6: The complaint analysis references a claim chart for "independent claim 6," implying an additional independent claim (likely the system claim). I could not independently confirm this.

Common dependent-claim subject matter (from the Summary): delivering the RCS message per schedule; carousels of selectable options (secure transaction, appointment scheduling, resuming abandoned journeys); UI rendered in a mobile browser; send/receive typing indicators; authorizing the RCS sender and, on failure, sending an SMS warning; and actions to transact, select a suggested response, return to a prior browsing session, or return to a prior application session.

---

Litigation status

• District court (found): IQX Corp. v. Intuit Inc., No. 2:26-cv-00351 (E.D. Tex., Marshall Division), assigned to Judge Rodney Gilstrap (Magistrate Judge Roy S. Payne), nature of suit 830 (Patent), cause 35 U.S.C. § 271, jury demand. The accused instrumentality is alleged to be Intuit's MailChimp text-message marketing system. The complaint (filed April 30, 2026 per the docket; the docket also lists a separate '924 patent in the same case) asserts the '799 patent.

  • Google Patents' "Family has litigation" entry links to this same Texas Eastern District case number (2:26-cv-00351) and a Darts-IP "first worldwide family litigation" family ID (94175196).
  • Date discrepancy to flag: the docket reports a filing date of April 30, 2026, which is after the current-date instruction of April 26, 2026 in this request. I am reporting the docket as retrieved rather than adjusting it.

• CAFC (2026): I found no Federal Circuit appeal, petition, or docket entry associated with US 12,368,799. The case appears to be at the district-court pleading stage as of the latest docket data ("Last Updated ~3 days ago" relative to retrieval). If you need a definitive CAFC check, the CM/ECF docket for the Federal Circuit should be queried directly for "IQX."

---

Explicit uncertainties

1. Claim language: I could not retrieve the verbatim granted claims (1, 6, 18, and the system/CRM independents). The overviews above are paraphrases derived from the patent's Summary and a third-party complaint analysis; verify against the grant document.
2. Claim numbering: The identification of claim 1, claim 6, and claim 18 as independent claims is inferential. Claim 6 comes only from a non-authoritative complaint analysis.
3. No CAFC activity confirmed for this patent as of the retrieval date — absence of results is not proof of absence.
4. The 2026 docket details come from third-party aggregators (Justia, PacerMonitor, GAEFLEX staging, Ex Parte AI analysis); the authoritative source is the E.D. Tex. CM/ECF docket.

I'll search litigation databases for this specific patent number. Let me run several targeted searches.

Let me dig deeper into the docket details, other defendants, PTAB proceedings, and any appellate activity.

Litigation involving US 12,368,799

I searched litigation-specific sources (Justia dockets, PacerMonitor, Docket Alarm, Unified Patents' litigation portal, Ex Parte AI complaint analyses, Law360 dockets, Dockets.Justia). Two district-court cases brought by the patent owner appear in the record. No Federal Circuit appeal and no PTAB proceeding involving the '799 patent were found.

---

Case 1 — IQX Corp. v. Intuit Inc. (the case flagged by the patent record itself)

Confirmation that this case involves the '799 patent — two independent corroborations:

1. The Google Patents record for US 12,368,799 itself carries a "Family has litigation" flag linking to "Texas Eastern District Court / case/2:26-cv-00351" (portal.unifiedpatents.com/litigation), plus a Darts-IP "first worldwide family litigation" link with family ID 94175196.
2. The Ex Parte complaint analysis for 2:26-cv-00351 analyzes U.S. Patent No. 12,368,799 – "Automated silent network authentication protocol", identifying asserted independent claim 18 and noting the complaint's reference to "independent claim 6," with a claim chart attached as Exhibit 4 (not filed publicly). Source: ai-lab.exparte.com/case/dct/txed/2:26-cv-00351/doc/analysis/1.

Infringement theories alleged (from the complaint analysis, non-authoritative): direct infringement and induced infringement under § 271(b) via Intuit's user manuals/instructional materials; willful infringement with a request for enhanced damages under § 284. Plainitff's counsel identified as Russ August & Kabat (per the third-party analysis) and Reza Mirzaie (per the docket signature block). Venue pleaded on the basis that Intuit resides in the district, has committed acts of infringement there, and maintains a regular and established place of business there.

---

Case 2 — IQX Corp. v. Salesforce, Inc. (possible second assertion of the same family — '799 assertion not confirmed)

Sources: PacerMonitor case page; Ex Parte AI case page; Patexia case list. Treat this as a possible related assertion pending verification of the asserted patents.

---

What was not found

• No CAFC appeal / petition naming IQX Corp. or US 12,368,799. Absence of results is not proof of absence; a direct CM/ECF query for "IQX" on the Federal Circuit docket would be definitive.
• No PTAB proceeding (no IPR, PGR, or CBM) against the '799 patent. The only PTAB hits were unrelated (Unified Patents v. Flexiworld, Bradium, etc.).
• No ITC Section 337 investigation and no other district-court defendant associated with the '799 patent beyond the two above.

---

⚠️ Date discrepancies to flag explicitly

1. The task prompt states the current date is April 26, 2026, but the retrieved docket record contains events dated after that: the Intuit complaint (April 30, 2026), the Salesforce complaint (May 28, 2026), and the stipulation to extend contentions deadlines (July 9, 2026). I am reporting the dockets as retrieved rather than adjusting them, but the dates cannot all be reconciled with an April 26, 2026 "today." The system-provided date for this session is September 25, 2026, which is consistent with all retrieved docket entries.
2. This matches the discrepancy already flagged in the previously generated section, which noted the April 30, 2026 filing date postdating the April 26, 2026 instruction. No contradiction with the earlier section — the case number, court, judge, accused product, and patents asserted all align.
3. Prior generated sections listed the case as IQX Corp. v. Intuit Inc., No. 2:26-cv-00351, E.D. Tex. (Judge Gilstrap), accusing MailChimp and asserting the '799 and '924 patents. All of that is corroborated here, with the addition that the case is in the Marshall Division and remains at the contentions stage.

Verification caveat

All docket content above is drawn from third-party aggregators (PacerMonitor, Justia, Docket Alarm/GAEFLEX, Ex Parte AI, Law360) rather than the E.D. Tex. and W.D. Tex. CM/ECF dockets directly. The authoritative sources are the courts' PACER/CM-ECF dockets and, for claim-scope questions, the USPTO PatentCenter record for US 12,368,799.

I'll research the IPR proceeding on file and any related appellate activity.

Let me dig deeper into the specific proceeding and related filings.

Let me try to pull the proceeding page directly and check for related filings and any appeal.

PTAB / AIA Trial Analysis — US 12,368,799 B2

"Automated silent network authentication protocol" · IQX Corp. · Inventors Sacha Spindler, Aidan Wright

Sourcing note. The proceedings list below is taken from the structured "PTAB proceedings on file" block supplied with this task (USPTO Open Data Portal ingest), which is the canonical list. I did not add, infer, or renumber any proceeding. Everything else is either (a) attributed to a specific retrieved source, or (b) explicitly labeled as an estimate/inference. Where a field was not retrievable, it is marked not retrieved — nothing has been filled in by assumption.

---

Proceedings overview

One (1) AIA trial proceeding is on file against US 12,368,799 — IPR2026-00475, filed 2026-09-24, status Pending — with zero claims invalidated, zero claims sustained, zero institution decisions, zero Final Written Decisions, zero settlements, and zero Federal Circuit appeals; the patent is therefore entirely untested at the PTAB, which means a defendant today faces neither a "hardened, IPR-survived patent" nor a "claims-are-dead" gift — it faces a live, four-day-old petition whose outcome is unknowable and stays are unlikely in the parallel E.D. Tex. case.

The defensive posture is a blank slate with a very short clock. There is nothing to cite in an invalidity contention that carries the Board's imprimatur, and there is no estoppel yet. But there is also nothing for the patent owner to wave at the court. The practical asymmetry is timing: the petition was filed 2026-09-24, so the § 314(b) institution decision is still months away, while the district court case that first asserted this patent (IQX Corp. v. Intuit Inc., No. 2:26-cv-00351, E.D. Tex.) has already been moving.

---

IPR2026-00475 — Salesforce, Inc. v. IQX Corp.

• Type: Inter Partes Review (IPR) — 35 U.S.C. §§ 311–319
• Filed: 2026-09-24
• Status: Pending (verbatim from the structured data) — plain-English gloss: petition filed and docketed; the Board has not yet issued a Notice of Filing Date Accorded, an institution decision, or any other merits paper, and the proceeding has not been assigned a panel.
• Judge panel: Not retrieved / pending assignment. No APJ panel for IPR2026-00475 appears in any source retrieved. (By way of comparison only, the concurrently filed sibling IPR2026-00478 shows "Pending Judge Assignment" on the Ex Parte PTAB case page — but that is a different proceeding and I do not import its status onto the '475.)
• Petition grounds: Not retrieved. I could not obtain the petition, its statutory-grounds table, the challenged claim list, or the art relied upon. I will not guess. Contextual note, clearly flagged as inference only, not retrieved: the '799's independent claims as reflected in the patent's own Summary and FIG. 17 recite an RCS-generation + ML-scheduled-delivery pipeline, and the asserted claim in the W.D. Tex. action is reported as independent claim 12 (see the conflict note below); a challenge to those claims would most plausibly be a § 103 combination, since the previously generated Obviousness section found no single reference that anticipates the full element chain. That is a prediction, not a fact.
• Institution decision: None. No decision on institution has issued (proceeding is 4 days old as of the 2026-09-28 session date). Statutory clock: under 35 U.S.C. § 314(b) the Director's institution determination is due within 3 months after the patent owner's preliminary response, or the last date such a response could be filed. Patent Owner's Preliminary Response is ordinarily due 3 months after service of the petition (37 C.F.R. § 42.107(b)) — i.e., on or about 2026-12-24 absent an extension or a first-action-type notice — putting the institution decision in the ~2027-03 window. These dates are statute/rule-derived estimates, not docket entries.
• Final Written Decision: None issued. Consequently there is no claim-level disposition to report whatsoever — no independent claim canceled, no dependent claim canceled, no claim held patentable, and no panel reasoning to quote. Under § 316(a)(11) a FWD would not be due until one year after institution (extendable up to six months for good cause), i.e., roughly early 2028 on the estimate above.
• Settlement / termination: None. No termination, no adverse judgment, no joint motion, no settlement on any terms (confidential or otherwise).
• Appeal: None. No appeal of anything exists, because no appealable decision exists. I found no Federal Circuit docket entry, petition, or opinion naming IQX Corp. or US 12,368,799. Absence of results is not proof of absence — the confirming step is a direct CM/ECF query for "IQX" on the Federal Circuit docket.
• Defensive value: Low as precedent, high as optionality. You cannot cite this proceeding for anything today — no estoppel has attached (see § 315(e)(2) below), no claim has been canceled, and no institution decision exists to lean on. Its real value is as a bridge: if Salesforce obtains institution, the Board's claim constructions and any cancellation of asserted claim 12 would become the single most useful piece of leverage in the parallel infringement actions. Until then, treat it as an open file, not a weapon.

---

Related, non-canonical observation (flagged, not part of the canonical list)

A same-day sibling petition surfaced in retrieval but is not in the canonical structured block: IPR2026-00478 — Salesforce Inc. v. Iqx Corp. — filed 09/24/26 — Status: Pending (Ex Parte PTAB case page: ai-lab.exparte.com/case/ptab/IPR2026-00478). The numbering (-475, -478) and the identical filing date are consistent with a multi-patent, same-day Salesforce petition set against the IQX family. I am reporting it as a lead only and am not treating it as an AIA trial on the '799; the asserted-patent list for -00478 was not retrieved. If confirmed, it would matter to the estoppel and coordination analysis because multiple concurrently filed Salesforce petitions would create a single, coordinated § 315(e)(2) bar running from each instituted proceeding.

---

Strategic summary

Claim-level inventoried status: every claim of the '799 is UNTESTED. There are no CANCELED claims and no SUSTAINED claims, because no Final Written Decision has ever issued in any AIA trial on this patent. The only claim number reported as asserted anywhere in this record comes from the litigation side, not the PTAB: third-party complaint analyses of IQX Corp. v. Salesforce, Inc. report "Asserted Claims: independent claim 12" (ai-lab-cl-prod.azurewebsites.net/case/dct/txwd/7:26-cv-00213/doc/analysis/1), while the Intuit-side analysis referenced claim 6 and recited claim 18. Those three figures remain unreconciled across the earlier sections and I am not auto-correcting them here; the granted claim document controls. My retrieval in this turn did not produce a petitioner-side challenged-claim list for IPR2026-00475.

Estoppel landscape — currently empty, but it is about to matter. Section 315(e)(2) estoppel binds a petitioner (and its real parties in interest and privies) only after a Final Written Decision, and only as to grounds raised or that reasonably could have been raised. With no institution and no FWD, no estoppel has attached to anyone, and no ground is foreclosed in the district court by operation of this IPR. The countervailing point is one-way-door risk in the other direction: if the Board institutes on Salesforce's petition, Salesforce's own § 315(e)(2) bar begins to crystallize at FWD, which is why petitioners in this posture typically file litigation stipulations (as Microsoft did in the retrieved QOMPLX materials: not to pursue in litigation the specific grounds raised, or any § 102/§ 103 ground that reasonably could have been raised on patents or printed publications in the instituted proceeding). Watch for whether Salesforce files a comparable stipulation — its presence materially improves the petitioner's position against discretionary denial. For other defendants (e.g., Intuit), the estoppel analysis is different: they are not privies of Salesforce on this record, so Salesforce's petition does not bar Intuit from running its own § 102/§ 103 grounds at the Board or in court — subject to § 315(b) timing as to Intuit's own petition window.

Pattern signals. (i) Single petitioner to date on the '799: Salesforce, Inc. — but with a same-day sibling petition (-00478) suggesting a set, not an isolated filing. (ii) No defensive aggregator in the chain — this was not a Unified Patents or RPX filing; the petitioner is a named litigation defendant accused in W.D. Tex., which is the classic defensive-IPR posture rather than a proxy filing. (N.B., the RPX/Salesforce "real party in interest" case law that surfaced in retrieval — Applications in Internet Time, LLC v. RPX Corp., Fed. Cir. — involved Salesforce as the alleged beneficiary of an RPX proxy filing; the facts here are the inverse, with Salesforce filing directly. That case is background on § 315(b) RPI/privy doctrine, not authority about this petition.) (iii) Patent owner has not yet had an opportunity to respond, so there is no evidence of aggressive PO appellate behavior — and because the '799 issued 2025-07-22, this is a within-two-years-of-issuance challenge, which the Director's recent informative decision in Tesla, Inc. v. Bulletproof Property Management, LLC, IPR2026-00204 et al. (PTAB June 15, 2026) (designated informative) treated as weighing against finding the strong "settled expectations" that favor discretionary denial. (iv) Discretionary-denial risk is real and should be tracked, given the parallel IQX v. Intuit and IQX v. Salesforce district cases; the relevant framework is the Director's March 26, 2025 Memorandum and the subsequent Interim Processes for PTAB Workload Management line, which codified factors including "[w]hether the PTAB or another forum has already adjudicated the validity or patentability of the challenged patent claims."

---

Recommended next steps

1. Get the petition. Because nothing is public about IPR2026-00475's grounds beyond its existence, the first action item is to pull the papers from PTAB E2E / PTACTS: https://ptacts.uspto.gov/ and the USPTO Open Data Portal AIA-trial endpoint. Specifically obtain (a) the challenged claims list, (b) the statutory-grounds table (§ 102 / § 103 / § 112), (c) the prior-art exhibit list (Ex. 1001–10xx), and (d) any § 315(b) / RPI / privity statement. This is the single largest gap in the analysis and everything else depends on it.
2. Docket the statutory milestones. With filing at 2026-09-24: Patent Owner Preliminary Response due ~2026-12-24 (3 months from service, 37 C.F.R. § 42.107(b)); institution decision ~2027-03-24 (§ 314(b)); FWD due ~12 months after institution (~2028-03), extendable. There is no FWD to link to and no disposition to quote — do not represent otherwise in any filing or opinion. Estimated deadlines are not docket facts and should be replaced with E2E paper numbers as they issue.
3. Monitor for a Salesforce litigation stipulation and for discretionary-denial briefing. Under the current Director's practice and the Tesla informative decision, the petitioner's probability of institution rises materially with a broad stipulation not to pursue in district court the grounds raised or that reasonably could have been raised on patents/printed publications. Conversely, the patent owner will almost certainly file a Request for Discretionary Denial keyed to the co-pending district-court actions.
4. If you are a defendant being asserted today and you are NOT Salesforce: no estoppel runs against you, and no claim of the '799 has been canceled. Your § 102/§ 103 runway is entirely open — see the previously generated Obviousness section for candidate grounds (the SNAP-claim ground over dynamic-personalization-link art combined with carrier-side silent-authentication art, and the RCS/ML-scheduling ground contingent on the CIP priority-date fork, which remains the decisive threshold issue). Be aware of the § 315(b) one-year bar from service of an infringement complaint, and consider whether joining or coordinating with a concurrent petition is advantageous.
5. Verify the asserted-claim conflict before relying on any claim number. The '799 has been reported as asserted at claim 6 (Intuit analysis), claim 12 (Salesforce analysis), and claim 18 (recited SNAP claim), all from non-authoritative third-party sources. Pull the granted claim set from USPTO PatentCenter and the complaints' claim-chart exhibits. Do not draft an opinion on claim scope until this is resolved.
6. Federal Circuit check. Absence of results is not proof of absence. Query the Federal Circuit CM/ECF for "IQX" directly, and CourtListener (https://www.courtlistener.com/) for any IQX Corp. opinions. Nothing was found in this session.

---

Carried-forward discrepancies and verification caveats

• No FWD, no panel, no grounds, no outcome. The most important thing this section can tell you is what it cannot tell you: IPR2026-00475 is four days old. Any statement that the '799 "has survived an IPR," has "canceled claims," or has "instituted trials" would be fabricated. It has none of those.
• Date reconciliation (carried forward, unresolved). This task states the current date as 2026-09-28; earlier sections in this analysis were instructed with 2026-04-26 and flagged that session date 2026-09-25. Retrieved docket/prosecution events span 2026-04-30 (IQX v. Intuit complaint) through 2026-09-24 (this petition). The 2026-09-28 instruction is consistent with all retrieved events; the earlier April 26 date was not. No new contradiction — this is the same gap flagged in the Litigation, Prior-art, Obviousness, Extensions, and Derivative works sections.
• Claim 6 / claim 12 / claim 18 conflict — still unresolved and now relevant to the PTAB analysis specifically, because the challenged-claim list in IPR2026-00475 will be the first authoritative claim-number disclosure for the '799. When the petition is pulled, reconcile it against all three figures.
• Sibling proceeding IPR2026-00478 is reported from a third-party aggregator, not the canonical structured block. Confirm on PTACTS before citing.
• Sources. Canonical proceedings list: the structured "PTAB proceedings on file" block (USPTO Open Data Portal). Support/context: PTACTS, Ex Parte PTAB – IPR2026-00478, Ex Parte complaint analysis – 7:26-cv-00213. No specific Board opinion, institution decision, or FWD for the '799 exists to link to, because none has issued.

I'll research the ownership chain for US 12,368,799, focusing on the assignment record and any NPE indicators.

Let me dig into the assignment record specifics and IQX Corp's corporate history.

I have useful corporate-history leads. Now let me try to pull the actual assignment record (reel/frame) and correspondent data.

Ownership & Assignment Analysis — US 12,368,799 B2

"Automated silent network authentication protocol" · Assignee of record: IQX Corp

Source note / verification caveat (read first). I was unable to complete a direct, record-by-record pull of the USPTO Patent Assignment Center for this patent (the search tooling hit its step limit before returning an Assignment Center result page). The assignment facts below are drawn from the Google Patents legal-events record for US 12,368,799, which republishes USPTO assignment/reassignment events, supplemented by USPTO face-of-patent data and third-party sources. I could not confirm the reel/frame number, the executed date, or the correspondent of record (recording attorney/agent). Those three fields are the ones the task flags as most diagnostic, so they remain open. Verify directly at assignmentcenter.uspto.gov or assignment.uspto.gov/patent/index.html before relying on the negative findings.

---

Inventors

Pattern note (inventor set). The '799 names only two inventors — Spindler and Wright. Sibling family members (e.g., US 11,876,924; US 12,126,752; and the pending 18/483,670 line) additionally name Andrew Lewin. So the '799 carries a narrower inventorship than its siblings — a drafting choice worth noting, since it means any assignment executed by Lewin on the siblings need not appear on the '799's chain.

Employer at filing. All named inventors were associated with iQX Corp (Spindler as founder/CEO; the applications were filed with iQX Corp as applicant/assignee from the PCT stage forward, per US 11,765,262 which lists "IQX CORP., Beverly Hills, CA" as assignee). No evidence of inventors departing the assignee within 12 months of filing — there is a single assignor→assignee assignment and no subsequent inventor-signed transfers.

---

Original assignee

IQX Corp (also stylized "iQX Corp.") — the entity named on the issued '799 patent, and also the current assignee.

• Primary line of business: a software-as-a-service text-marketing / direct-text sales platform. A January 5, 2017 company release (Seattle, WA dateline) announced "iQX Amplify," described as a cloud-based direct-text marketing and sales platform integrating with WooCommerce, and naming Sacha Spindler as Founder and CEO. The patent specification itself is built around this product ("the communication technique… is sometimes referred to as 'Amplify'"; "ADDP," "UEMWEB," "CSC input," "Amplify Decision Delivery Processor"). So the claims map onto the assignee's own shipped product concept.
• Address history visible in the record: Seattle, WA (2017 release) → Beverly Hills, CA (face of US 11,765,262) → Carson City, NV ("iQX Corp., 6 Carson City, NV," per patent-profile aggregators for a later family application). Address churn is common for small private companies and is not, by itself, evidence of a shell — see signals below.
• Current status: Not established. I found no dissolution, bankruptcy, acquisition, or wind-down record. The company's continued assertion activity (two 2026 district-court suits) is evidence it at least remains a functioning litigant. Whether it currently ships a product embodying the '799 claims is unverified.

⚠️ Do not conflate with "iQX Limited." Multiple search hits for "IQX Limited" (ACN 155 518 380), an Australian NSX-listed life-sciences investment/funds-management group (Dr George Syrmalis; iQ Group Global) are a different entity in a different industry. There is no evidence linking it to US 12,368,799. The patent owner is the US text-marketing company founded by Spindler.

---

Assignment timeline

The Google Patents legal-events record for US 12,368,799 shows exactly one assignment/reassignment event:

• Executed: not shown in the retrieved record / Recorded 2024-12-18 — Reel/Frame: not retrieved
  • Conveyance: Assignment of Assignors' Interest (original assignment; "SEE DOCUMENT FOR DETAILS")
  • Assignor: SPINDLER, Sacha; WRIGHT, Aidan
  • Assignee: IQX CORP.
  • Correspondent: Not retrieved. (The recording attorney/agent of record is the single most diagnostic field for shell-LLC chains; it must be pulled from Assignment Center directly.)
  • Context: Original inventor-to-company assignment — the founders' conveyance of rights to their own operating company, recorded one day after the continuation application was filed (application filed 2024-12-17; assignment recorded 2024-12-18). This is a routine "assignment-on-filing," not a third-party transfer.

No other assignments are on the record for this patent. In particular, there is no evidence of:

• a transfer to any licensing/"IP"/"Holdings" entity;
• a second or later assignment of any kind;
• a security interest, license, merger, change-of-name, or release recorded against the '799.

Related family context (not assignments of the '799, but relevant to the chain): the Google Patents legal events show the '799's priority relationships (PCT/US2019/052847, 2019-09-25; the 18/896,197 parent; later filings 19/192,732 → US 12,438,978B2 and 19/324,477 → US 20260012531A1). These reflect continuation/priority filings, not ownership transfers.

If the Assignment Center, on a direct query, returns additional post-issuance records (e.g., a 2025–2026 assignment to a litigation vehicle), that would materially change the analysis below.

---

Timeline diagram

timeline
    title Ownership of US 12368799
    2017 : iQX Corp launches Amplify platform
    2018 : Provisional application filed
    2019 : PCT application filed
    2024 : Continuation filed
         : Inventors assign rights to iQX Corp
    2025 : Patent issued to iQX Corp
    2026 : Infringement suits filed

---

NPE / troll-pattern signals

---

Verdict

Operating-company assertion — with a flagged caveat.

Justification (2–3 sentences). US 12,368,799 has stayed with its original operating-company owner: the single recorded assignment (recorded 2024-12-18, executed on/by the 2024-12-17 filing) is an inventor→IQX Corp. original assignment, and no transfer to any shell, licensing vehicle, known NPE, or defensive aggregator exists on the record — so 7 of the 8 troll-pattern signals are affirmatively not present. IQX Corp is a real operating entity that developed and marketed the accused-product category itself ("iQX Amplify," a direct-text marketing SaaS platform launched in 2017, with inventor Spindler as founder/CEO), and it is now asserting the '799 against commercial messaging-platform operators it competes with (IQX Corp. v. Intuit Inc., No. 2:26-cv-00351, E.D. Tex., filed 2026-04-30; IQX Corp. v. Salesforce, Inc., No. 7:26-cv-00213, W.D. Tex., filed 2026-05-28). Caveat: this is a small, apparently non-practicing-at-present operating company, and I could not verify that IQX Corp currently ships products embodying the '799 claims (which issued only in 2025) — if it has ceased operations and is monetizing solely through litigation, the correct label would shift toward an NPE characterization, and the single most important open item is the Assignment Center correspondent of record, which I was unable to retrieve.

Verification link: USPTO Patent Assignment Center — search "12368799" (mirror: assignment.uspto.gov/patent/index.html)

---

Open items to close before this verdict is final

1. Pull the reel/frame and the executed date for the 2024-12-18 assignment directly from Assignment Center (my retrieval failed).
2. Capture the correspondent of record (recording attorney/agent + firm + address) and check whether that name recurs across IQX Corp's other family patents (US 11,765,262 / 11,876,924 / 11,949,806 / 12,041,197 / 12,126,752 / 12,438,978) — a single repeat player across the family is the highest-value tell here.
3. Confirm IQX Corp's corporate status and current product posture (NV/CA/WY secretary-of-state registry; any wind-down, assignment-for-benefit-of-creditors, or litigation-funding arrangement).
4. Check for any 2025–2026 post-issuance assignment recorded after the '799 granted (2025-07-22) — none appears in the Google Patents legal events, but Assignment Center is authoritative.

All factual assertions above are sourced from the authoritative patent record supplied (inventors, assignee, 2024-12-18 reassignment event, filing/grant dates), US 11,765,262's face data, and the cited public sources. No assignment, reel/frame, or correspondent was invented; where a field was not retrieved, it is marked "not retrieved."

I'll search for the prior-art citations associated with this patent number, being careful to target the exact number.

Let me try more targeted searches for the citation data.

I found a lead — sibling patent citation data. Let me pull the actual citation lists for the '799 and its family.

Prior-Art / Citation Analysis — US 12,368,799 B2

"Automated silent network authentication protocol" (IQX Corp.)

---

⚠️ Up-front honesty on what I could and could not retrieve

I was not able to retrieve the verbatim "(56) References Cited" list for US 12,368,799. Two independent problems:

1. The authoritative fetched record supplied to me is truncated. The Google Patents text at https://patents.google.com/patent/US12368799/en that was supplied cuts off inside the Detailed Description (mid-paragraph, at "In some embodiments, when a client"). It does not include the "Citations," "Cited By," or "Similar Documents" tables. So the authoritative source in my possession has no citation data for the '799 at all.
2. Web search did not surface the '799's own citation table. My searches returned citation tables for other patents (unrelated ones), not for the '799. Under the step budget I could not complete a direct pull of the '799's citation list.

Therefore I cannot honestly give you "each patent citation for 12,368,799" as an enumerated, verified list. Anyone who gives you that list without the (56) block in hand is guessing. What follows is (a) the citation set that is on the public record for a same-family sibling (a legitimate proxy, clearly labeled), (b) a forward-citation data point that does name the '799, and (c) a substantive § 102 gap analysis. The definitive list must be pulled from USPTO PatentCenter / the grant PDF's front page (item 56) or Google Patents' "Citations" tab.

---

0. A number-collision you must not confuse with this patent (per the "no similar numbers" rule)

A search for the literal string 12368799 returned an unrelated hit: EP 1001459 A2 lists a priority document rendered as "US 12368799 P 19990310" (a 1999 provisional/application identifier). That is a different instrument with a coincidentally colliding digit string — an integrated-circuit capacitor case — and has nothing to do with US Patent 12,368,799. Excluded, as instructed. (Source: https://data.epo.org/gpi/EP1001459A2)

---

1. Family-shared citation set (PROXY — labeled, not confirmed for the '799 itself)

Same-family sibling US 12,647,506 B2, "Systems and methods for performing silent network authentication protocols for mobile devices" (IQX Corp., pub. 2026-06-02) — which shares the '799's specification — is publicly indexed with the following patent citations:

Source: https://eureka.patsnap.com/patent/[US12647506B2](/patent/US12647506B2) (Patsnap Eureka "Citation Information → Patent Citations" for US 12,647,506 B2).

* Dates marked "approx." are derived from the US patent-number issuance series, not read from the documents. They are reliable to a few weeks but must be verified. I did not verify assignee/inventor for items 1–5 in this session; do not attribute them without pulling the front pages.

⚠️ Critical caveat on this table

• These are the sibling's citations. Because the '799 shares the sibling's specification, the citations are likely — but not confirmed — to overlap. Treat the table as a lead list, not as the '799's (56) block.
• A second, family-sibling publication (US 2025/0016262, "…security, verification, and access control for cellular handheld devices") is also indexed with the same specification (https://www.patents-review.com/a/20250016262-automated-silent-network-authentication-protocol-security.html).

---

2. Forward citation that explicitly names the '799

Reading: because US 2018/0103004 A1 published before the '799's 2018-09-27 priority date, it is § 102(a)(1) prior art and is a cited reference (backward citation) of the '799 — it is squarely relevant to the abandoned/resumed-journey dependent claims ("return to a prior browsing session," "resuming at least one abandoned user journey"). This is the one '799-side citation I could confirm by name.

---

3. § 102 mapping — what each reference can and cannot reach

Legal framing (be disciplined here): a reference appearing in a patent's (56) block is not an admission that it anticipates. Under AIA § 102(a)(1)/(a)(2) (the '799 is post-AIA — first effective filing 2018), a reference anticipates only if it discloses every element of the claim as arranged in the claim. Given the '799's independent claims recite a specific ordered pipeline, most cited references will be § 103 art, not § 102 art. My assess

Bottom line of § 102 exposure: on the reference set I could surface, the broad, RCS-plus-ML-scheduling independent claims are unlikely to be § 102-anticipated by any one listed reference; the realistic attack is § 103 (e.g., "texted payment link" + "integrated messaging" + "customized web pages" + a send-time/ML scheduler). The SNAP independent claim (~claim 12 per the Salesforce complaint analysis, or ~18 per the Intuit analysis — see the conflict note below) will likely not be reached by any of these five references, because none discloses the security code packet carrying a subscriber network credential plus a client device carrier identifier being passed to a carrier-side authentication provider.

---

4. Prior-art classes the listed citations almost certainly do not cover (where the real § 102/§ 103 art lives)

Because the '799's distinguishing claim limitations (RCS + ML-scheduled delivery; SNAP carrier verification) were added in the 2023–2024 CIP chain, the cited references above likely predate and omit them. A serious validity search should target:

1. Silent Network Authentication (SNA). The commercial SNA/phone-number-verification space (e.g., carrier-identity "silent verification" vendors) is a dense patent thicket predating 2018. I am not naming specific patent numbers because I have not verified them for this session — do not rely on any number I have not sourced. This is the single highest-value search area for the SNAP claim.
2. RCS messaging with interactive carousels / typing indicators / read receipts. Standardized RCS Universal Profile features (buttons, carousels, suggested replies) are pre-2018 public disclosures — potentially § 102(a)(1) "public use/printed publication" art against the RCS-content dependent claims.
3. ML/algorithmic send-time optimization ("send-time optimization," "just-in-time messaging"). Notably, the accused product here is Intuit/MailChimp's text-messaging system (per the previously generated Litigation summary), and send-time-optimization is a well-published technique. This is the most promising § 103 field against the "scheduling, using a machine learning model … based on the determined classification" limitation.
4. Abandoned-cart / session-resumption messaging — see US 2018/0103004 A1 above.
5. Subscriber classification / tiering ("tier 1 buyers / tier 2 link-clickers / tier 3" in the spec, FIG. 10) — engagement-tiering art.

---

5. Conflicts and discrepancies to flag explicitly

1. Asserted-claim number conflict (new). A third-party complaint analysis for IQX Corp. v. Salesforce, Inc., No. 7:26-cv-00213 (W.D. Tex.) states the '799's "Asserted Claims: independent claim 12" ('799 Patent, Compl. ¶37). This conflicts with the earlier generated sections, which identified claim 6 (Intuit analysis) and claim 18 (title-matching SNAP claim). Source: https://ai-lab-cl-prod.azurewebsites.net/case/dct/txwd/7:26-cv-00213/doc/analysis/1. All three figures come from non-authoritative third-party analyses; the granted claim set must be pulled from PatentCenter. I am not auto-correcting any of them.
2. Date discrepancy (carried forward). This task states April 26, 2026; the session date is September 25, 2026; and retrieved docket records contain events dated April 30, 2026 – July 9, 2026, after the April 26 date. This repeats the discrepancy already flagged in the previously generated Litigation and PTAB sections. No contradiction — just the same unreconciled gap.
3. Consistency with earlier sections: the earlier sections listed no PTAB activity (later superseded by IPR2026-00475, filed 2026-09-24) and the same Intuit/Salesforce district-court cases. Nothing in this citation search contradicts those sections.

---

6. Verification caveats (read before relying on anything above)

• The '799's own (56) References Cited list was NOT obtained. Everything in § 1–§ 3 is inferred from (a) a sibling patent's citation list and (b) one forward citation naming the '799. Do not represent the § 1 table as the '799's citation list.
• Approximate issue dates were derived from patent-number series, not read from the documents.
• Assignees/inventors for US 10,122,824; US 10,298,739; US 10,699,264; US 11,158,009; and CN 101553038 were not verified in this session.
• Definitive next step: open the '799's grant PDF front page (item 56) or Google Patents → "Citations" tab, and cross-check the examiner's cited art against the prosecution file wrapper (PatentCenter) for the parent 17/279,188 and the CIP 18/483,670 — post-2023 RCS/ML art, if any, will appear there rather than on the '799's face.

Grounding URLs used: https://patents.google.com/patent/US12368799/en (authoritative record, truncated) · https://eureka.patsnap.com/patent/US12647506B2 (sibling citations) · https://patents.google.com/patent/US20180103004A1#17 (forward citation naming the '799) · https://www.freepatentsonline.com/y2025/0119493.html · https://www.patents-review.com/a/20250119493-automated-silent-network-authentication-protocol.html · https://ai-lab-cl-prod.azurewebsites.net/case/dct/txwd/7:26-cv-00213/doc/analysis/1

I'll verify the key prior-art references from the Prior Art section before building the § 103 analysis, since that section flagged several as unverified.

Good — those searches confirmed several key reference details. Let me verify two more critical areas: the machine-learning send-time art and the Silent Network Authentication art (the asserted SNAP claim's field).

Obviousness Analysis — US 12,368,799 B2 under 35 U.S.C. § 103

Patent: US 12,368,799 B2, "Automated silent network authentication protocol" (IQX Corp.; inventors Spindler & Wright; app. 18/984,041; granted 2025-07-22)
Instruction environment: current date April 26, 2026 (session date 2026-09-25 — same unreconciled gap flagged in every prior section; not re-litigated here)
Scope: this section analyzes § 103 only, using the reference set from the previously generated Prior Art section. § 101/§ 112 issues are noted only where they feed the obviousness analysis.

---

0. Bottom line up front

One-sentence verdict: The RCS-campaign independents (method/system/CRM) are vulnerable to a textbook KSR combination of known elements — ML-personalized customized page flows (Reflektion), a texted unique link to a phone-number-bound transactional webpage (Up N' Go), and RCS-with-fallback messaging (Samsung) — while the SNAP claim that the co-pending complaints actually assert is the least exposed claim in the patent on the art retrieved.

---

1. Analytic gates you must clear before any § 103 ground is worth drafting

1.1 The threshold gate: the effective filing date (scenario fork)

Under AIA § 100(i), the "effective filing date" is the actual filing date or the filing date of the earliest application to which the claim is entitled to priority/benefit for the claimed subject matter. That single determination sets the entire art universe, and for this patent it forks:

This is the highest-value diligence question in the whole file. The patentee cannot simultaneously claim 2018 priority to avoid the 2019–2023 art and rely on the 2023–2024 specification for § 112 written description of the RCS/AMDA/SNAP limitations. Any § 103 or § 112 opinion that does not pin this down is built on sand. The prior sections flagged the CIP branch structurally; this section flags its obviousness consequence.

1.2 The claim-text caveat (carried forward, unresolved)

The claim set is still not in hand. The Intuit complaint analysis recites claim 18 (SNAP elements) and references an "independent claim 6"; the Salesforce analysis asserts "independent claim 12." Do not auto-reconcile these — the grant document controls. The analysis below is therefore keyed to functional elements (E1–E8, S1–S5 from the prior Derivative works section), not claim numbers.

1.3 Person of ordinary skill in the art (POSITA)

A POSITA here is a software/systems engineer with 3–5 years in mobile messaging and web personalization, or an ML engineer with messaging-platform experience, who is familiar with: SMS/MMS/RCS (including the GSMA RCS Universal Profile and RCS Business Messaging), push and OTT channels, server-side web personalization and A/B optimization, cookie/token-based device identity, the client-side web stack, and applied ML for ranking/scheduling (collaborative filtering, logistic regression, gradient boosting). Notably, the '799's own specification recites exactly this toolkit as conventional (LLM/RNN/transformer "or any other type of ML model," on-device or server-hosted applications). That breadth of "conventional" disclosure cuts against the patentee.

---

2. The prior-art universe — what I verified this session

I re-queried the five references carried in the Prior Art section. Refinements and new facts obtained today (search-verified):

New lead surfaced during verification (flagged, not relied upon — see §11): US 2022/0294794 A1, "Computerized system and method for increasing, retaining and maintaining network user resource sessions," app. 17/199,884, filed 2021-03-12, published 2022-09-15, classifications H04L 29/06 / H04L 29/08 / G06N 20/00 / G06N 5/04. Claim 14 recites "applying a machine learning algorithm to the device information, recency information and frequency information, and determining predicted return information," with a session token carrying the predicted time of return, pre-loading at a time proximate to the predicted return, and "nudge the user by sending him/her messages … that will cause the user to act and reengage." Assignee not verified. This reference post-dates the 2018 priority and is therefore usable only under Scenario B.

---

3. Ground Combination 1 (GC-1) — the RCS/ML campaign independents (E1–E8)

3.1 The combination

Primary: US 10,122,824 B1 (Reflektion) · Secondary: US 11,158,009 B2 (Up N' Go) · Secondary: Samsung integrated-messages RCS/fallback reference · Optional tertiary: US 2018/0103004 A1 (Facebook) for classification-by-engagement and sender indicators.

flowchart LR
  A["'824: ML engine predicts per-individual KPI<br/>selects UI component<br/>2-stage customized page flow (E6, E2, E3)"] --> Z["Combined system (E1-E8)"]
  B["'009: texted unique URL bound to customer phone number<br/>browser page with payment field + verification code (E2-E5)"] --> Z
  C["Samsung: RCS first message, SMS/MMS fallback<br/>same content (E7)"] --> Z
  D["'004 (opt.): threshold-based gating on engagement/interest;<br/>rich message object w/ hyperlinks; sender indicator (E6, E2, E9)"] --> Z
  Z --> E["ML-scheduled RCS delivery (E8)"]

3.2 Element-by-element

3.3 Motivation to combine (why a POSITA would have done this)

Apply KSR and MPEP 2144.04's enumerated rationales — GC-1 satisfies at least four:

1. The references themselves state the problem and the direction of the solution (rationale A — combine known elements for a predictable result).

• '004 expressly identifies the very fact pattern the '799 claims to solve: "many customers who place items in their online shopping cart, only to leave the website before purchasing anything," and criticizes popups as "pushy and ineffective" — which is a direct, express motivation to re-engage the user through an out-of-band message rather than in-page.
• '824 expressly identifies the challenge of per-individual page-flow customization and names abandon rate as a KPI to optimize.
• '009 expressly identifies the friction in the conventional pay-at-table flow (get the server's attention, print the check, split it, etc.) and motivates a texted unique link that resolves to a phone-number-bound transactional page.

1. Substituting a better-known channel for a known channel (rationale B — substitution of one known element for another, predictable result). Replacing SMS (taught by both '824 and '009) with RCS to deliver the same message content is exactly what the Samsung reference does as a matter of course, and the '799's own specification concedes channel interchangeability: "while SMS messaging was used in the preceding discussion, different communication channels may be used in other embodiments, e.g., email, EMS, and/or MMS." Richer media, read receipts, and interactive actions are the predictable benefit of that substitution — they are the reasons RCS exists.

2. Using a known technique to improve a similar system in the same way (rationales C/D). ML send-time/engagement optimization applied to a personalized-messaging pipeline is a known technique applied to a known system "ready for improvement," with a finite design space (time-of-day buckets, channel choice, template variant) and a directly measurable objective (read receipts, clicks, conversions). Under KSR and Intel v. PACT (Fed. Cir. 2023), a POSITA would recognize that applying the '824 ML engine to the timing dimension — not just the content dimension — improves the system in the same way, and the result is predictable at the system level.

3. Design incentives and market forces (rationale F). The entire field of outbound marketing messaging is organized around "right message, right person, right time." Once a system already (a) identifies the individual, (b) classifies them, (c) personalizes a page flow, and (d) sends a message with a link, routing that send to the richest supported channel and timing it for predicted engagement is a natural, cost-driven design choice, not an inventive leap.

4. Single-reference sufficiency on the two-stage architecture. '824 alone discloses the '799's architectural spine — interaction-triggered generation of a second customized document after the recipient acts on the first. That is the E2→E4 transition the '799 treats as its pipeline, and it is 2016 art.

3.4 Reasonable expectation of success

High. Each element is a conventional engineering primitive on a conventional platform; no reference needs to be modified in an untested way; the RCS/fallback path is already implemented in the Samsung reference; and the ML element is a ranking/scheduling problem for which the specification itself offers only a generic layer taxonomy ("data ingestion layer … data models training layer … feedback loops layer") plus a list of model families. A generic functional recitation of "a machine learning model" is met by any conventional model that performs the stated function — which both supports enablement of the claim and undercuts non-obviousness.

3.5 Where GC-1 is weakest

E8 only. The patentee's best argument is that no reference discloses scheduling delivery of an RCS message using an ML model based on the determined classification — i.e., that the classification is the input feature to the scheduler. '824's ML engine decides what to present, and '004's gating decides whether to send; neither is framed as a per-recipient tier → send-time function. Counter: '824's engine predicts per-individual KPIs before presenting; supplying a tier as a covariate to a send-time model is the textbook "obvious to try" case — the candidate approaches are finite and identified in the art (send-time, engagement tier, channel). If, however, the granted claim recites specific features of the classification or a particular model input/output structure, this element could bear the patent's weight.

---

4. Ground Combination 2 (GC-2) — the dependent claims (E9, abandoned journeys, sender trust)

These are the easiest to invalidate and the least likely to be separately argued:

Motivation: each dependent merely adds a predictable variation (rationale G) of a capability that the primary combination already delivers, or a substitution of a protocol primitive.

---

5. Ground Combination 3 (GC-3) — Scenario-B-only art (if the claims take the 2023 CIP date)

If the RCS/AMDA/SNAP limitations are held unsupported by the 2018/2019 disclosure, the following become available and materially strengthen GC-1/E8:

• US 2022/0294794 A1 (pub. 2022-09-15; filed 2021-03-12) — ML over device/recency/frequency → predicted return time → "nudge" messages at a time proximate to the prediction, plus message holding/release timed to the predicted return. This is essentially the "ML-scheduled re-engagement delivery" limitation in isolation, with a G06N 20/00 classification. Combined with '824 and '009, E8 moves from moderate-to-strong to strong.
• The intervening commercial literature and platform documentation (send-time optimization, RCS Business Messaging rollouts, cart-recovery messaging) that I did not verify this session — a high-value search area for a real invalidity contention.

Motivation in Scenario B is trivial and self-evident: by 2021–2023 every major messaging-marketing platform was doing exactly this, and the patent's own specification describes the AMDA as an integration of then-conventional channels and ML — an admission against interest about the ordinary-skill baseline.

---

6. The SNAP independent claim (S1–S5) — no § 103 ground on this record

On the retrieved and re-verified set, nothing reaches:

generating a security code packet comprising a subscriber network credential and a client device carrier identifier → transmitting that packet to an authentication service provider → receiving an indication that the credential/identifier match or fail to match existing records → performing the transaction on a match.

• '009 gets close on the friction axis ("sending a verification code to the customer device via the first network," phone-number-bound link, phone number passed to the merchant system) but that is an SMS one-time-code flow, not a carrier-side silent verification of a subscriber network credential against a device carrier identifier.
• '824's cookies and '264's phone-number-linking/biometrics are client- or server-side identity bindings, not carrier-network validations.
• CN 101553038 is irrelevant to this element.

Therefore: on this record, S1–S5 stand. The correct § 103 framework if a carrier-verification reference is located is a substitution rationale (KSR rationale B): replacing a known, friction-bearing OTP (expressly taught by '009) with a known silent carrier/number-verification technique — performed by a carrier or authentication service provider against the device's subscriber credential — to obtain the predictable result of the same or better identity assurance with less user friction and better anti-fraud (anti-SIM-swap) properties. That rationale is well-formed; I have not verified any specific SNA reference, and I will not name one. This is the single highest-value prior-art search target in the file (the Prior Art section reached the same conclusion independently).

---

7. Secondary considerations and the patentee's best defenses

7.1 What IQX can realistically argue

1. Specific ordering / information flow. The claims require verification in response to selecting the action and before classification and RCS generation — arguably an inversion of convention, where authentication happens at the transaction, not at the link click. Rebuttal: '009 already triggers server-side processing (bill retrieval + code verification) on the link request, and '824 already generates the second document only "in response to an interaction"; step order dictated by the claim's own logic carries limited patentable weight (Mformation v. RIM, Fed. Cir. 2013; In re Kollar).
2. The classification-to-scheduler link (E8). Discussed in §3.5 — the strongest single-element argument.
3. The SNAP element. Discussed in §6 — genuinely unimpeached on this record.
4. Unexpected results / nexus. The patent touts a "customer capture rate of greater than 10%… e.g., 14.5%." That is a business metric and, on this record, is the expected result of personalization + channel selection + send-time optimization. No evidence of a nexus to a specific claimed feature, and no comparative data showing the result is unexpected relative to the closest prior art. Secondary considerations are unlikely to carry weight without a Rule 132-type evidentiary showing.

7.2 The gate that protects the other direction — common ownership

A defendant cannot build § 103 art out of IQX's own earlier-filed family applications or patents relied on as § 102(a)(2) disclosures, because commonly-owned subject matter is removed from § 102(a)(2) by the § 102(b)(2)(C) exception (which applies to § 103 as well). But note the asymmetry the prior sections did not draw: § 102(b)(2)(C) does not reach § 102(a)(1) public disclosures. IQX's own family publications that issued or published more than one year before the effective filing date (e.g., the 2020 PCT publication WO 2020068911 A1, and the earlier family patents/publications) are not saved by the § 102(b)(1)(A) grace period (which reaches only disclosures ≤1 year before the effective filing date) and are therefore § 102(a)(1) art — to anyone. This only bites if those earlier publications actually disclose the RCS/AMDA/SNAP subject matter — which is precisely the Scenario-B premise. In Scenario A the point is moot (the patentee owns the 2018 date). Flag it as a conditional, not a conclusion.

---

8. Assessment, with confidence

Practical read: the '799 is not a patent whose validity rests on the RCS-campaign claims — those are exposed. It rests on the SNAP claim that the complaints actually chart. Any validity/opinion strategy should therefore split the two families: attack the campaign claims under GC-1/GC-3 and reserve resources for a dedicated, verified SNA-art search for the SNAP family.

---

9. Verification actions to close this analysis

1. Pull the granted claim set from PatentCenter for app. 18/984,041 and resolve the 6 / 12 / 18 independent-claim conflict. Every element boundary above depends on it.
2. Determine the effective filing date (Scenario A vs. B): compare the '799's RCS/AMDA/SNAP specification paragraphs against the 62/737,315 provisional and the PCT/US2019/052847 specification. This is the pivotal fact for the entire art universe.
3. Retrieve US 10,298,739 B2 and confirm it is the Samsung US counterpart of EP 3073682 A1 (KR 10-2015-0040024).
4. Retrieve US 2022/0294794 A1 in full; verify assignee, and whether claim 14's ML-return-prediction subject matter is supported by its 2021-03-12 filing (it is only art under Scenario B).
5. Run the SNA search (carrier number verification / silent verification / anti-SIM-swap, both patent and non-patent literature, pre-2018 and 2018–2024). This is the highest-value open item; no ground on the current record touches S1–S5.
6. Verify the GSMA RCS Universal Profile revision and dates before citing rich-card/carousel/typing-indicator features as a printed publication.
7. Pull the '799's own (56) citations and the parent file wrappers (17/279,188; 18/483,670; 18/896,197) — post-2023 RCS/ML art, if the examiner considered any, will appear there rather than on the '799's face.

---

10. Newly surfaced leads — flagged, not relied upon

---

11. Cross-reference and contradiction log

• No contradictions with the prior Prior Art section; the five-reference set is confirmed and enriched (assignees, inventors, filing/priority dates, and enabling-quote level detail for '824, '009, '004, and the Samsung family). The Prior Art section's warning that its table was a sibling-patent proxy still stands for items it could not verify; today's searches independently corroborate the title/number pairs it listed and fill in the missing bibliographic data.
• Refinement, not contradiction: the Prior Art section listed "US 10,298,739 B2 — Method and apparatus for transmitting integrated messages" with an "approx." 2019 date and no assignee. Today I verified the EP 3073682 A1 family member (Samsung, KR priority 2015-03-23). The US number itself remains unverified — flagged.
• Refinement, not contradiction: the Prior Art section's § 102 bottom line — that the listed references do not reach the SNAP claim — is confirmed here under § 103 as well.
• Date discrepancy carried forward: task date 2026-04-26 vs. session date 2026-09-25 and docket/PTAB events spanning 2026-04-30 → 2026-09-24. Same unreconciled gap flagged in the Litigation, PTAB, Prior-art, Obviousness, Extensions, and Derivative works sections. Not a new contradiction.
• Claim-number conflict unchanged: claim 6 (Intuit analysis) / claim 12 (Salesforce analysis) / claim 18 (Intuit analysis recitation). Not auto-reconciled.

Sources used this session (search-verified): US 10,122,824 B1 and US 11,250,098 B2 full texts (patentimages/Google Patents/Justia); US 11,158,009 B2, US 11,720,983 B2 and US 10,699,264 B1 family/claim text (Google Patents, Justia, Patents-Review); US 2018/0103004 A1 (Google Patents, FreePatentsOnline, patentimages); EP 3073682 A1 (Google Patents) — Samsung integrated messages; US 2022/0294794 A1 (Justia). Not retrieved: the '799's granted claims, its (56) citation list, US 10,298,739 B2 itself, and any verified SNA reference.

I'll search for the specific patent number and its term-adjustment data across USPTO and patent-record sources.

The broad searches returned general PTA law, not the specific patent's data. Let me target the patent record directly.

Patent Term, Adjustment & Family Analysis — US 12,368,799 B2

"Automated silent network authentication protocol" · App. 18/984,041 · IQX Corp.

---

0. Sourcing caveat — what I could and could not verify for the exact ID

Strict-rule compliance note: I searched for the literal identifier 12368799 (and the punctuated forms 12,368,799 / US12368799). My targeted queries for the USPTO Patent Center / Patent Public Search face-of-patent PTA figure and the patent's own "References Cited"/term block did not return a page for the exact ID — the search tooling returned general PTA/PTE legal material and unrelated patents, and ultimately hit its step limit. I therefore could not read the patent's front-page "Notice of Patent Term Adjustment" line verbatim, nor the official Certificate of Correction/reconsideration record.

Everything below is built from:

1. The authoritative Google Patents record supplied in this task (filing/grant dates, continuity chain, "Anticipated expiration 2039-09-25," priority/claim data, family links) — this is the controlling source per the operating rules; and
2. The previously generated sections of this analysis (continuity chain, family members, inventors/assignee), cross-referenced rather than repeated.

Where the record does not supply a field (e.g., the PTA day count, terminal disclaimers, restriction requirements), I say so rather than invent a number. Do not treat any PTA day figure below as retrieved from the patent — there is none to cite.

---

1. How the term of this patent is set (the threshold point)

US 12,368,799 is a continuation, so it does not get its own fresh 20-year term. Under 35 U.S.C. § 154(a)(2), the term runs 20 years from the U.S. filing date, or — where the application references an earlier-filed application — from the earliest such filing date. As the previously generated Patent summary and Obviousness sections establish, the chain is built on a national-stage entry of an international application, and under 35 U.S.C. § 363 the U.S. "filing date" of a § 371 national-stage application is the international filing date.

• International filing date (PCT/US2019/052847): 2019-09-25 (per the authoritative record's "Priority claimed from PCT/US2019/052847, 2019-09-25").
• Provisional 62/737,315 (2018-09-27): does not count toward the 20-year term (provisionals are excluded), even though the record lists a "priority date" of 2018-09-27.
• Net base (pre-adjustment) expiration: 2039-09-25 = exactly 20 years from 2019-09-25.

Cross-reference / no contradiction: the previously generated sections describe the priority date as 2018-09-27 and the "anticipated expiration" as 2039-09-25. Both are consistent with § 154(a)(2) + § 363 once you note that the priority date (provisional) and the term-measuring date (PCT) are different dates. No conflict.

---

2. Patent Term Adjustment (PTA) — 35 U.S.C. § 154(b)

What the record shows (controlling)

• Application 18/984,041, filed 2024-12-17; granted 2025-07-22.
• Listed "Anticipated expiration: 2039-09-25."

Analysis

The recorded anticipated expiration (2039-09-25) equals exactly the un-adjusted 20-year date from the PCT filing. On the Google Patents convention — which generally folds PTA into the "anticipated expiration" — that equality implies a statutory PTA of approximately zero days, i.e., no adjustment. Prudence requires flagging the alternative reading: if the record's date is merely the statutory 20-year term without the PTA field applied, then any granted PTA would push expiry later than 2039-09-25. Only Patent Center / the grant front page can resolve this.

Why zero (or near-zero) PTA is the expected outcome for this application

PTA is computed per application, on that application's own prosecution timeline (37 C.F.R. §§ 1.702–1.703), even for continuations. Here the pendency is only ~7 months (2024-12-17 → 2025-07-22):

Conclusion (with the stated caveat): on the facts in the record, the '799's own application accrued no A/B/C statutory delay, so PTA is very likely 0 days, and the projected expiration remains 2039-09-25. I did not retrieve the official day count and will not represent one. (General PTA principles above — A/B/C delay definitions, the RCE/B-delay treatment, and the applicant-delay reduction — are confirmed by the USPTO MPEP 2700 material and the Federal Circuit's Gilead/FDA-delay discussions surfaced in search.)

⚠️ Do not confuse sibling PTA with this patent's PTA. A different application in the same chain can have entirely different prosecution length and therefore a materially different PTA day count. Even a large PTA on a parent does not transfer to the '799, though it would change the earliest family expiration analysis (relevant to the double-patenting/Odp issues flagged in the earlier Obviousness section). The record shows no PTA value for 18/984,041.

Terminal disclaimer

The record contains no indication of a terminal disclaimer on the '799. If one was filed (common with large continuations to obviate ODP), it would cap the '799's term at the expiration of the referenced patent and could extinguish any PTA (§ 154(b)(2)(B)). Unverified — pull the file wrapper.

---

3. Patent Term Extension (PTE) — 35 U.S.C. § 156

Conclusion: PTE is not applicable and none should be expected.

PTE (Hatch-Waxman) extends term only for a patent claiming a drug product, a medical device, a food additive/color additive, or a method of using/manufacturing such a product that was subject to a regulatory review period (FDA approval). US 12,368,799 claims software/telecommunications methods and systems (RCS messaging, silent network authentication, ML-scheduled delivery) — it does not claim an FDA-regulated product. It is therefore ineligible for PTE, and no PTE certificate would issue. (The earlier prior-art/obviousness sections likewise treat this as a mobile-messaging/authentication patent with no pharma nexus.)

Result: 0 days PTE.

---

4. Continuation applications (continuity chain)

Per the patent's CROSS-REFERENCE TO RELATED APPLICATIONS (specification) and the Google Patents "priority/continuation" events:

Title-of-record relationship: the specification states 18/984,041 "is a continuation of U.S. application Ser. No. 18/896,197, filed Sep. 25, 2024." That is the operative continuity claim for term purposes.

Verify the "continuation" characterization of 18/896,197. The record (and the earlier Obviousness section) describes 18/896,197 as reaching back through a CIP (18/483,670). A CIP does not reset the term: new matter added in a CIP does not create a new 20-year clock — the term still runs from the earliest non-provisional application in the chain (here the 2019 PCT). This is the crux of the priority/branch analysis in the earlier Obviousness section, and it matters here because it means the '799 expires with its family on 2039-09-25 (subject to PTA/disclaimer), notwithstanding that it claims 2023–2024-added subject matter.

---

5. Divisional applications

No divisional application is indicated on the record for the '799.

A divisional arises under 35 U.S.C. § 121 only from a restriction requirement. Nothing in the authoritative record (or the prior sections) reflects a restriction requirement against 18/984,041 or a § 121 divisional carved from it. The several family applications above are continuations / a CIP, not divisionals. This is a negative finding based on the retrieved record; a file-wrapper pull is required to rule out a restriction requirement.

---

6. Related family members

(a) Members confirmed on the authoritative record

(b) Sibling patents named in the previously generated sections (unverified in this session)

The earlier sections referenced, as same-family/IQX members: US 11,765,262, US 11,876,924, US 11,949,806, US 12,041,197, US 12,126,752, and US 12,647,506 B2 ("Systems and methods for performing silent network authentication protocols for mobile devices"). These numbers were not re-verified against USPTO records in this turn and should be confirmed before reliance.

⚠️ Discrepancy to flag (new). The authoritative record attributes app. 19/324,477 (event dated 2025-09-10) to publication US 2026/0012531 A1. The earlier Obviousness section, however, described US 12,647,506 B2 as "filed 2025-09-10, published 2026-06-02." Those two statements do not reconcile: they assign different outputs to the same 2025-09-10 filing date/line. Per the operating rules I am not auto-correcting either; treat 19/324,477 → US 2026/0012531 A1 as controlling (authoritative record) and re-verify US 12,647,506 B2's parent and dates via Patent Center. This also bears on the "family expiration / ODP" watch item from the prior Strategic summary.

---

7. Projected expiration date

Maintenance fees (to reach full term): due at 3.5, 7.5, and 11.5 years from grant (grant 2025-07-22) → approximately 2029-01-22, 2033-01-22, 2037-01-22. Failure to pay lapses the patent before 2039. The record lists status Active — but that reflects the legal-status feed, not fee-payment verification.

---

8. Explicit uncertainties and open items

1. PTA day count — NOT retrieved. I could not read the patent's front-page "extended or adjusted under 35 U.S.C. 154(b) by ___ days" line or a PTA determination for 18/984,041. My "~0 days" is a derivation from the recorded expiration date and the 7-month pendency, not a retrieved fact.
2. No PTA-reconsideration / Certificate of Correction record was retrieved.
3. Terminal disclaimer status for the '799 (and across the family) is unverified — this is the single most likely field to change the effective expiry from 2039-09-25.
4. Sibling patent numbers (US 11,765,262; 11,876,924; 11,949,806; 12,041,197; 12,126,752; 12,647,506 B2) were not re-verified this session.
5. The 19/324,477 vs. US 12,647,506 B2 filing-date conflict (§6) is unresolved and should be adjudicated against Patent Center.
6. No divisional application is indicated — but a restriction requirement could exist in the file wrapper; not ruled out.
7. Date reconciliation (carried forward): the task states April 26, 2026; the session date is September 25, 2026; and retrieved docket/prosecution events span April–July 2026 plus the IPR filed 2026-09-24. This is the same unreconciled gap flagged in the earlier Litigation, PTAB, Prior-art, and Obviousness sections — not a new contradiction.

Definitive verification steps (authoritative sources):

• USPTO Patent Center → application 18/984,041 → Patent Term Adjustment tab (A/B/C delay breakdown, non-overlapping PTO delay, applicant delay, total PTA) and the front-page PTA statement on the issued patent.
• Patent Center → Transaction History → confirm any terminal disclaimer, restriction requirement, or Certificate of Correction/PTA reconsideration.
• USPTO Patent Assignment Center (already an open item per the prior Ownership section) → no bearing on term, but completes the record.
• Google Patents "Family" / Espacenet Global Dossier for the PCT/US2019/052847 family to reconcile the 19/192,732, 19/324,477, and 12,647,506 members.

Bottom line: On the authoritative record, US 12,368,799 is a continuation that shares its family's 20-year term measured from the 2019-09-25 PCT filing date, giving a base and (most likely) adjusted expiration of 2039-09-25; no PTE is available (non-pharma), no divisional is indicated, its direct parent is 18/896,197 (a CIP of 18/483,670), and the only variable that can move the date is a PTA award and/or a terminal disclaimer — neither of which I was able to confirm from the exact-ID USPTO record in this session.

I'll do a quick diligence search on the exact identifier before drafting the disclosure.

Defensive Disclosure Package

Subject Matter: US 12,368,799 B2 — "Automated silent network authentication protocol" (IQX Corp.)

---

0. Threshold corrections and cautions before the disclosure

0.1 — Scope honesty: this dossier cannot invalidate the '799 itself. Every derivative below is dated 2026, which is after the '799's 2018-09-27 provisional, its 2019-09-25 PCT filing date, and its 2023-10-10 CIP branch. A 2026 publication therefore cannot be § 102 prior art against the '799. Its purpose is precisely the one assigned: to pre-empt competitor patents on incremental improvements filed after the publication date, and to supply § 103 combination art against later-filed claims. If the objective were instead to invalidate the '799's own RCS/ML claims, the correct lever is the pre-2023 art and the CIP written-description question addressed in the previously generated Obviousness section — not this dossier.

0.2 — Claim numbering remains unverified. Consistent with the earlier Plain-language overview, I do not have the verbatim granted claim set. I therefore address claim families functionally. The retrieved record does confirm the substance: the Intuit complaint analysis recites the claim 18 SNAP elements ("security code packet comprising a subscriber network credential and a client device carrier identifier … transmitting … to an authentication service provider … receiving an indication that the credentials match or fail to match"), and the Salesforce complaint analysis separately asserts "independent claim 12." Both figures are from non-authoritative third-party analyses; do not auto-reconcile them — the grant document controls.

0.3 — Date discrepancy (carried forward). The task states the current date is April 26, 2026. The session date is September 25, 2026, and previously retrieved docket/prosecution events span April–July 2026 plus a PTAB petition filed 2026-09-24. This is the same unreconciled gap already flagged in the Litigation, PTAB, Prior-art, Obviousness, and Extensions sections — not a new contradiction. This document uses the instructed date while noting the divergence.

0.4 — Family-member exclusion. Do not treat US 12,647,506 B2 (IQX Corp, filed 2025-09-10, pub. 2026-06-02) or US 2025/0274544 A1 as prior art. They share the target's disclosure and are § 102(b)(2)(C) commonly-owned self-disclosures. Note this also resolves the earlier flagged conflict: the authoritative record ties app. 19/324,477 to pub. US 2026/0012531A1, while US 12,647,506 B2 is confirmed by the retrieved record as a separate 2025-09-10 filing. Both are IQX family; neither is available as art.

0.5 — Functional claim-element map used throughout (keyed to the patent's own Summary and FIGS. 17–18, per prior sections):

---

1. Derivative disclosure — Family A: RCS generation, recipient classification, ML-scheduled delivery (elements E1–E8)

A-1 · Axis 1 — Material & Component Substitution: On-device federated contextual bandit + sender-constrained tokens + carrier-native transport

Enabling description. The centralised server-side scheduler of the target is replaced element-for-element as follows. (i) Scheduler component: substitute a supervised send-time regressor with a per-user LinUCB contextual bandit whose arm set is the cross-product of {send-hour bucket, channel (RCS / RCS-with-fallback-MMS / push), message-template variant}. Context vector dimension 64, comprising last_open_delta_h, session_depth, device_class, radio_access_tech, battery_soc, tz_offset, historical_read_latency_p50. Reward is the weighted sum 0.2·read + 0.5·click + 1.0·txn_complete, observed via IMDN read receipts and click telemetry. (ii) Training topology: federated — the device computes a local gradient over a 24-hour sliding window, transmits an update wrapped in Bonawitz-style secure aggregation (pairwise-masked, dropout-resilient), and the aggregator applies DP-SGD with σ = 0.8, δ = 10⁻⁵, ε ≈ 2.0 before parameter averaging. Model artefact is exported to ONNX INT8 and executed locally by ONNX Runtime Mobile; only the chosen arm identifier ever leaves the device. (iii) Token substitution: replace a plain bearer JWT with an RFC 9449 DPoP-bound access token — the client proves possession of an ephemeral P-256 private key in the platform keystore (Android StrongBox / Secure Enclave) by signing htm, htu, jti, iat, and the ath of the access token. (iv) Transport substitution: an abstraction layer probes RBM agent capability over SIP OPTIONS/GET /capabilities and selects a carrier MaaP REST path, else Google Jibe-style RCS, else SMPP 3.4 submit_sm with esm_class set for MMS fallback.

Formaliser signature: classify(identity) → tier ∈ {T1,T2,T3}; bandit.arm(tier, context) → (t*, channel*, template*); txn_guard = DPoP_verify(proof, ath).

flowchart LR
  A["Content request E1"] --> B["Identity verification E4-E5"]
  B --> C["Classifier E6"]
  C --> D["LinUCB bandit E8"]
  D --> E{"Capability probe"}
  E -->|MaaP REST| F["RCS send E7 via carrier agent"]
  E -->|Jibe| G["RCS send E7 via cloud agent"]
  E -->|no RCS| H["SMPP fallback MMS"]
  F --> I["IMDN read receipt"]
  I --> J["Reward update local"]
  J --> K["Secure aggregation"]
  K --> D

Disclosed claim-style statement (E1–E8): A method in which recipient classification and delivery scheduling are performed by a federated contextual-bandit model executing on the recipient's own device, with only an arm identifier and an aggregated, differentially private gradient update leaving the device, and in which the resulting RCS message is transmitted over a capability-negotiated carrier MaaP REST endpoint authenticated by a DPoP sender-constrained token.

---

A-2 · Axis 2 — Operational Parameter Expansion (hyperscale): 10⁹ subscribers, 2.5·10⁵ msg/s, 45-day scheduling horizon

Enabling description. At this scale the scheduler is a sharded, time-bucketed priority queue: the key space is hash(MCC||MNC||hour_bucket||cohort_id); each shard owns a Redis sorted set keyed on send_epoch_seconds with member msg_id, and an ingest consumer group (Kafka, 64 partitions per carrier) decouples feature scoring from dispatch. Feature scoring is hierarchical: a global base model (gradient-boosted trees, 400 rounds, depth 8), a per-carrier adapter (low-rank rank-8 LoRA over the leaf-weight vector), and a per-cohort head for the top 5 % of cohorts by revenue. Token-budget enforcement is a token-bucket limiter per (carrier, SMPP bind, second) sized to that carrier's contracted TPS, with overflow spilled to the next bucket and a hard cap preventing duplicate submit_sm via an idempotency key msg_id and a 48-hour dedupe window. Compliance windows are computed from the IANA tzdb and a per-jurisdiction rules table encoding the TCPA 08:00–21:00 local window plus per-country quiet periods (e.g., statutory holidays, DST transitions, Ramadan timing shifts); the scheduler refuses to emit a message whose target instant falls outside the intersection. Backpressure is handled by shedding the lowest-priority tier first (T3 bulk), then downgrading RCS to SMS, never by exceeding carrier TPS.

Scale parameters (enabling): 10⁹ distinct MSISDNs; 2.5·10⁵ messages/s peak; p99 queue latency < 900 ms; 45-day look-ahead; 400 M feature rows/day; cold-start model served from a GPU pool with 8 ms batch-1 inference.

flowchart TD
  A["Feature store"] --> B["Global base model"]
  B --> C["Carrier adapter LoRA"]
  C --> D["Cohort head"]
  D --> E["Kafka shard by MCC MNC"]
  E --> F["Redis sorted set per hour bucket"]
  F --> G{"TPS token bucket"}
  G -->|available| H["Dispatch to carrier"]
  G -->|exhausted| I["Spill next bucket"]
  H --> J["Idempotency ledger 48h"]
  J --> K["Dedupe filter"]

Disclosed claim-style statement: A scheduler that maintains a per-carrier token-bucket rate governor and a 48-hour idempotency ledger over a sharded, time-bucketed priority queue, and that computes per-jurisdiction quiet windows from a timezone database, such that a scheduled RCS delivery is deferred rather than emitted in violation of a carrier throughput contract or a local messaging-time regulation.

---

A-3 · Axis 2 — Operational Parameter Expansion (hostile/extreme environment): non-terrestrial and constrained-radio delivery

Enabling description. The campaign path is relocated to a non-terrestrial network (NTN): the RCS/MaaP client stack is adapted to 3GPP Rel-17 NTN operation in S-band with GEO/LEO backhaul, where RTT reaches 600 ms and Doppler on LEO passes reaches ±40 kHz at 2 GHz; the agent therefore pre-reserves HARQ and relies on repetition and extended TTI bundling, and the scheduler's send-window computation includes a satellite pass predictor (TLE-based SGP4 propagator) so that messages are queued for the pass that maximises the probability of an acknowledged transfer. Where no RCS bearer exists, the delivery degrades to store-and-forward using a Delay-Tolerant Networking Bundle Protocol (RFC 5050) agent with 7-day bundle TTL and custody transfer, and the ML model is compiled for TFLite Micro (256 KB RAM, 1 MB flash) using CMSIS-NN kernels with 8-bit symmetric quantisation; per-device context and the last 32 arm rewards are persisted in MRAM to survive power cycling. Operating envelope: −40 °C to +85 °C, 5 kV HBM ESD, 30 krad(Si) TID shielding on the modem die, solar/battery duty cycling at 2 % for the inference task.

flowchart LR
  A["Campaign queue"] --> B["Pass predictor SGP4"]
  B --> C{"RCS bearer present?"}
  C -->|yes| D["MaaP send with HARQ bundling"]
  C -->|no| E["BPv7 bundle agent TTL 7d"]
  E --> F["Custody transfer on next pass"]
  D --> G["Ack and reward capture"]
  F --> G
  G --> H["MRAM persisted state"]
  H --> I["TFLite Micro inference"]

Disclosed claim-style statement: A method of scheduling a rich message to a mobile device in which the send instant is selected from a satellite pass schedule derived from an orbital propagator, delivery is attempted over an RCS bearer where available and otherwise converted to a delay-tolerant bundle with custody transfer, and the machine-learning scheduler executes quantised on a microcontroller-class processor with non-volatile persistence of arm-reward state across power cycles.

---

A-4 · Axis 3 — Cross-Domain Application: AgTech, Aerospace MRO, and Consumer Electronics

Enabling description — three separate reductions to practice of the same mechanism.

(a) AgTech. A pivoted irrigation/fertigation advisory service: soil-moisture and tensiometer readings (SDI-12 over LoRaWAN, uplink class A, 15-min cadence) feed a stream processor; when the 30 cm volumetric water content drops below a crop-specific refill point (e.g., 0.22 m³/m³ for maize at V8), the AMDA-equivalent cohort classifier promotes the grower to T1, and the ML scheduler times an RCS message to the agricultural worker's shift window, not the owner's, using the field-crew roster as the availability prior. The RCS carousel offers three actions: confirm irrigation, defer to next window, or request agronomist callback. SNAP-equivalent device-possession verification binds the operator to the certified applicator's MSISDN for subsidy/compliance attestation (e.g., nutrient-management programme eligibility).

(b) Aerospace MRO. An aircraft-on-ground (AOG) parts campaign: the ATA-chapter part demand derives from the maintenance management system; the cohort model classifies licensed A&P mechanics by duty shift and station; the scheduler selects a send time inside the mechanic's on-shift window and outside the jet-bridge turn window; the RCS carousel offers "hold part", "view AOG alternatives", and "authorise AOG shipment". Silent carrier authentication binds the responding device to the certificate holder's number before any airworthiness documentation is surfaced (and see B-4 for the assurance-level treatment).

(c) Consumer electronics. An OTA firmware adoption campaign: fleet telemetry (build number, region, SoC revision, free storage) drives the cohort; the ML scheduler chooses an install window predicted from charging-state and screen-off history; the carrier-authentication step binds the eUICC EID to the MSISDN so that the entitlement cannot be replayed onto a second device.

flowchart TD
  subgraph G1["AgTech"]
    A1["SDI-12 soil telemetry"] --> A2["Refill-point rule"] --> A3["RCS irrigation carousel"]
  end
  subgraph G2["Aerospace MRO"]
    B1["Maintenance system AOG demand"] --> B2["ATA-chapter part build"] --> B3["RCS AOG carousel"]
  end
  subgraph G3["Consumer electronics"]
    C1["Fleet OTA telemetry"] --> C2["EID bound entitlement"] --> C3["RCS update window card"]
  end
  A3 --> Z["Shared classifier and ML send-time engine"]
  B3 --> Z
  C3 --> Z
  Z --> Y["Silent carrier possession check"]

Disclosed claim-style statement: A message-automation system in which the recipient cohort and ML-selected send instant are derived from a domain telemetry source drawn from the group consisting of agricultural soil/moisture sensors, aircraft maintenance-management records, and consumer-device firmware telemetry, and in which the recipient's authority to act is confirmed by binding a hardware subscriber identity to the messaging endpoint.

---

A-5 · Axis 4 — Integration with Emerging Tech: generative composition with retrieval-augmented grounding

Enabling description. The template-selection step is replaced by constrained LLM generation. A retrieval index (HNSW, 768-d embeddings, 10⁷ chunks) is built over the recipient's own engagement history (CDR metadata, prior RCS interactions, cart/quote objects) and the sender's catalogue; at send time the top-k = 32 chunks are inserted into a prompt and a 7B-parameter decoder emits an RBM-compliant JSON payload restricted by a grammar/FSM-constrained decoder to the GSMA RBM schema (richCard | carousel | suggestedAction), so the output is syntactically valid by construction. A pre-emit safety stack runs: (i) a jurisdiction policy classifier (gambling, alcohol, financial-promotion, health-claim flags), (ii) a PII re-identification check on the rendered string, (iii) an LLM-as-judge consistency check against the retrieved facts with a 0.85 entailment threshold, and (iv) a novelty/dedupe check against the last 30 sends. Every emitted message is logged with a signed manifest (device-signed DSSE envelope over the prompt hash, retrieved-document hashes, model digest, and output hash) so that any future dispute is resolvable without re-running the model. For on-device personalisation the system distils the teacher into a 3B model plus a rank-4 LoRA adapter, shipped as a signed OCI artefact.

sequenceDiagram
  participant C as Campaign Service
  participant R as Retrieval Index
  participant L as Constrained LLM
  participant S as Safety Stack
  participant T as RBM Transport
  C->>R: query with recipient context
  R-->>C: top 32 chunks
  C->>L: prompt plus JSON grammar
  L-->>C: RBM-compliant payload
  C->>S: policy, PII, entailment, dedupe
  S-->>C: pass or suppress
  C->>T: send with signed manifest
  T-->>C: read receipt and click event

Disclosed claim-style statement: A message-generation method in which the content of a rich message is produced by a grammar-constrained generative model conditioned on documents retrieved from the recipient's own engagement history and the sender's catalogue, and is emitted only after a policy, re-identification, entailment, and duplicate-suppression gate, with a cryptographic manifest binding the prompt, retrieved documents, model digest, and output.

---

A-6 · Axis 4 — Integration with IoT sensors for real-time campaign triggering

Enabling description. The campaign trigger is moved from a scheduled batch to an event-time stream: device telemetry arrives over MQTT 3.1.1/5.0 with Sparkplug B topic namespace spBv1.0/{group}/{message_type}/{edge_node}/{device}, or over LwM2M (OMA) for constrained nodes, and is consumed by a stateful processor (Flink, event-time windows with 2-minute allowed lateness and a watermarking strategy keyed on device sequence numbers). A deterministic rule stage handles the high-precision triggers (e.g., courier cold-chain excursion above 8 °C for 10 minutes; industrial compressor vibration RMS above 4.5 mm/s), and the ML stage handles ambiguity (which of three similar alerts merits a rich message). The rendered RCS message carries live telemetry values at commit time, sourced from the processor's keyed state, not from the batch store, so the number the recipient reads is the number that triggered the alert. Idempotency is enforced downstream so that a device re-delivering the same payload after an MQTT reconnect cannot double-fire a campaign. A digital-twin shadow (Eclipse Ditto model) supplies the last-known state for messages triggered by absence-of-telemetry rather than by a value.

flowchart LR
  A["MQTT Sparkplug edge nodes"] --> B["Flink event-time window"]
  B --> C{"Deterministic rule"}
  C -->|fire| D["Live value snapshot"]
  C -->|ambiguous| E["ML trigger arbiter"]
  E --> D
  D --> F["RCS compose"]
  F --> G["Idempotent dispatch"]
  G --> H["Recipient device"]
  B --> I["Digital twin shadow"]
  I --> F

Disclosed claim-style statement: A method in which a rich message is triggered by device telemetry evaluated in an event-time stream with watermark-based lateness handling, the message content includes a telemetry value read from the processor's keyed state at commit time, and duplicate delivery of the same device payload is suppressed by an idempotency key.

---

A-7 · Axis 5 — Inverse / Failure Mode: "fail-silent, never-annoy" suppression architecture

Enabling description. This variation inverts the objective: the system is designed to not send. Three suppression gates are interposed between scoring and dispatch. (i) Confidence gate: if the bandit's posterior variance on the chosen arm exceeds a threshold, or the model's calibration error for that cohort exceeds 0.05 (measured by a rolling expected-calibration-error monitor), the message is suppressed and replaced by an append-only, hash-chained suppression record containing the reason code — written to a WORM store with an Ed25519 signature over (msg_id, reason, features_hash, ts). (ii) Dignity gate: a hard cap of one message per 72 hours per recipient, enforced by a Carmack-style sliding-window counter, and a k-anonymity guard that suppresses any cohort-targeted send whose cohort size falls below k = 25. (iii) Resource gate: if device thermal state is at/above THERMAL_STATUS_SEVERE, battery below 5 % without charging, or the radio is in a low-power or limited-service state, the message is deferred to the next eligibility window rather than delivered. On any component fault — feature store unavailable, carrier DRA down, model artefact digest mismatch — the system fails closed by design: it enters DEGRADED_READONLY, holds the queue with a 12-hour TTL, and requires a signed operator attestation to exit. A watchdog independently hard-disables the dispatcher if the suppression-record chain fails verification.

stateDiagram-v2
  [*] --> Scoring
  Scoring --> Suppressed : low confidence or small cohort
  Scoring --> ThermalHold : device thermal or battery gate
  Scoring --> Eligible : all gates pass
  Eligible --> Dispatched : carrier ack
  Eligible --> DegradedReadOnly : dependency fault
  ThermalHold --> Eligible : next window
  DegradedReadOnly --> Eligible : signed operator attestation
  Suppressed --> [*]
  Dispatched --> [*]

Disclosed claim-style statement: A message-delivery system comprising a suppression-record chain that immutably logs reasons for non-delivery, a k-anonymity threshold gate on cohort-targeted sends, a device resource-state gate, and a fail-closed degraded mode requiring a cryptographically signed operator attestation for re-enablement.

---

2. Derivative disclosure — Family B: Silent network authentication (elements S1–S5)

B-1 · Axis 1 — Material & Component Substitution: eUICC/iUICC roots, modern carrier query surfaces, and PAKE credential transport

Enabling description. The client device carrier identifier of the target is generalised across four substitution classes. (i) Identity root substitution: replace the removable UICC with an embedded UICC (eUICC) provisioned under GSMA SGP.22 remote SIM provisioning, or an integrated UICC (iUICC) instantiated in the modem SoC's secure element; the credential set then includes the EID and the enabled-profile ICCID in addition to IMSI/MSISDN. (ii) Query-surface substitution: the authentication service provider may be reached over SS7/MAP anyTimeInterrogation, Diameter Sh/S6a (AIR, ULR), the 5G service-based architecture (Nudm_SDM_Get for SUPI↔GPSI mapping, Nudm_UEAuthentication), an IMS AKA exchange (3GPP TS 33.203), or a CAMARA-style carrier network API exposing Number Verification and SIM-Swap resources. (iii) Cryptographic substitution: instead of transmitting an HMAC over a shared secret, the device proves possession of the subscriber credential by an OPAQUE-style augPAKE/PAKE exchange so no offline-verifiable secret leaves the device; the resulting session key wraps a short-lived ES256 JWS. (iv) Platform-attestation substitution: the packet is additionally bound to a hardware key attestation certificate chain (Android Key Attestation with StrongBox security level, or DeviceCheck/App Attest on iOS) whose attestationChallenge is the server nonce. The security code packet is a CBOR/COSE-signed structure: {nonce, ts, iccid_hash, eid_hash, imsi_sub, mcc_mnc, device_class, attestation_cert_ref, key_id}.

sequenceDiagram
  participant D as Device secure element
  participant S as Verification Service
  participant C as Carrier HSS/UDM
  participant A as Attestation Root
  D->>S: PAKE initiation with nonce
  S-->>D: server share and nonce
  D->>S: COSE-signed packet with EID and ICCID hashes
  S->>A: verify hardware key attestation challenge
  A-->>S: attestation valid
  S->>C: Number Verification and SIM status lookup
  C-->>S: match or fail
  S-->>D: short-lived ES256 JWS

Disclosed claim-style statement: A silent authentication method in which possession of a subscriber credential is proven by a password-authenticated key exchange executed against a secure element, the resulting security code packet is bound to a hardware key-attestation challenge nonce and carries at least one of an eUICC identifier and an integrated-UICC profile identifier, and the carrier-side validation is performed through a network API rather than through an over-the-air messaging exchange.

---

B-2 · Axis 2 — Operational Parameter Expansion: 2·10⁵ verifications/s at p99 ≤ 180 ms with risk-tiered cache paths

Enabling description. The verification fabric is deployed as edge points of presence co-located with carrier DRA/STP and SBA NRF instances (Anycast, QUIC with 0-RTT resumption, connection pooling at 512 streams per peer) so that the network hop to the carrier's subscriber database is a single-digit-millisecond operation. Requests are classified into a fast path and a full path: a Bloom-filter negative cache of known-bad (MSISDN, device_binding) pairs and a positive cache with a maximum TTL of 30 seconds for (subscriber binding, carrier) pairs absorb the repeat-verification traffic characteristic of a checkout retry loop; cache hits still require a fresh DPoP proof, so caching never permits replay. The full path performs the carrier query with a per-carrier circuit breaker (closed → open at 5 % error rate over 30 seconds, half-open probe after 2 seconds) and request coalescing of identical in-flight queries via singleflight. Match/fail results carry an authenticated reason code (SIM_SWAP_RECENT, MISMATCH_IMSI, PORT_IN_PROGRESS, UNREACHABLE_DEFERRED) so that the caller can distinguish a hard fail from an inconclusive result. Persistence is a consistent-hash shard per IMSI-prefix so that a subscriber's verifications serialise on one node, eliminating read-after-write races during a porting window. Throughput: 2·10⁵/s sustained, 6·10⁵/s burst for 60 s; p99 180 ms including the carrier round trip; 99.999 % availability with a declared UNREACHABLE_DEFERRED outcome rather than a false pass.

flowchart LR
  A["Verification request"] --> B["DPoP proof check"]
  B --> C{"Negative cache hit?"}
  C -->|yes| D["Reject fast"]
  C -->|no| E{"Positive cache under 30s?"}
  E -->|yes| F["Pass with fresh nonce"]
  E -->|no| G["Singleflight coalesce"]
  G --> H["Carrier circuit breaker"]
  H -->|closed| I["DRA or NRF query"]
  H -->|open| J["UNREACHABLE_DEFERRED"]
  I --> K["Reason-coded verdict"]

Disclosed claim-style statement: A verification service that serves silent authentication requests through a sub-30-second positive cache requiring a fresh proof-of-possession on every hit, a Bloom-filter negative cache, request coalescing, per-carrier circuit breakers, and IMSI-prefix consistent hashing, and that emits a reason-coded inconclusive outcome in preference to a false positive when the carrier query surface is unavailable.

---

B-3 · Axis 2 — Operational Parameter Expansion: roaming, satellite backhaul, and machine fleets

Enabling description. Three edge conditions are handled explicitly. (i) Roaming: with S8HR or local breakout, the home UDM may be unreachable or the GPSI mapping stale; the service therefore maintains a porting and roaming state machine (recently_ported, roaming_in, roaming_out, dormant_m2m) derived from Number-Portability and SIM-Swap event feeds, and treats a mismatch during an active porting window as PORT_IN_PROGRESS (a deferred, not a denial) with a mandatory re-verification after the porting completion estimate. (ii) Satellite backhaul: when the transport is NTN, the protocol shrinks to a single-round-trip design (request carries the nonce and the device's COSE packet; the response is a single signed verdict) to avoid the second RTT, and a monotonic counter in secure storage defeats replay across the multi-second round trip; custody is transferred to an on-board store-and-forward agent when the link drops mid-exchange. (iii) Machine fleets: for M2M/eSIM fleets, verification is performed per eSIM profile state (enabled / disabled / deleted under SGP.22 or the SGP.32 IoT profile-assistant model) rather than per human subscriber, and the packet carries the EID plus profile ICCID; the classification step of Family A then treats the fleet as a cohort. Envelope: −40 °C to +85 °C for roadside/fleet modems; 12-year field life; battery budget of 25 mJ per verification.

stateDiagram-v2
  [*] --> Idle
  Idle --> PortingWindow : porting event observed
  Idle --> RoamingQuery : visitor or outbound roamer
  Idle --> FleetQuery : M2M profile lookup
  PortingWindow --> Deferred : verdict PORT_IN_PROGRESS
  Deferred --> Idle : after completion estimate
  RoamingQuery --> Verified : home UDM match
  FleetQuery --> Verified : profile enabled match
  Verified --> [*]

Disclosed claim-style statement: A silent verification method that classifies a subscriber's state into a porting, roaming, or machine-profile regime prior to issuing a carrier query, emits a deferred rather than negative verdict during an active porting window, and completes verification within a single round trip over a high-latency satellite backhaul using a monotonic counter in secure storage.

---

B-4 · Axis 3 — Cross-Domain Application: clinical e-prescribing, vehicle sharing, and public-benefit identity assurance

Enabling description — three unrelated industries.

(a) Healthcare. For electronic prescribing of controlled substances, silent carrier authentication is deployed as one factor of a two-factor scheme (device possession plus a knowledge or biometric factor), with the assurance level expressed in the language of NIST SP 800-63-3 (AAL2 for routine prescribing, AAL3 where a hardware authenticator is present). All verification artefacts are stored with the minimum necessary PHI: the MSISDN is retained only as a salted, per-tenant keyed hash, audit records are APPEND-ONLY and retained to the applicable federal/state retention period, and the device-binding key is rotated on each credential change.

(b) Vehicle sharing. A driver's reservation is bound to a phone by silent carrier verification at booking, and the resulting assertion is issued as a short-lived credential to the vehicle telematics unit (over a mutually authenticated TLS channel, certificate pinned to the OEM CA) which unlocks only while the credential is unexpired and the vehicle is within the geofence of the reservation location. If the phone disappears mid-session, the vehicle transitions to a safe-stop-prepare state and prompts for an in-cabin PIN; it never doors-open on an expired assertion.

(c) Public benefits. Identity proofing for benefit enrolment is expressed as an assurance ladder with an explicit mapping to IAL/AAL levels; silent carrier verification supplies the "possession of the claimed phone number" signal for IAL2-equivalent proofing, while document and biometric checks supply the remaining assurance. A low-confidence outcome routes the applicant to an in-person or video-assisted path rather than denying the application.

flowchart TD
  A["Silent carrier verification"] --> B{"Domain"}
  B -->|Healthcare| C["Possession factor plus knowledge factor yielding AAL2"]
  B -->|Vehicle sharing| D["Short-lived assertion to telematics unit"]
  B -->|Public benefits| E["IAL2-equivalent possession signal"]
  C --> F["Keyed-hash audit record"]
  D --> G["Geofenced unlock with safe-stop prepare"]
  E --> H["Assisted fallback path if low confidence"]

Disclosed claim-style statement: An authentication system in which a silent carrier-possession check is one factor of a multi-factor scheme whose output is expressed as an assurance level, the assertion is bound to a non-telephony relying party that is one of a clinical prescribing system, a vehicle telematics unit, or a government benefit-enrolment system, and the subscriber identifier is retained only in keyed-hash form.

---

B-5 · Axis 4 — Integration with Emerging Tech: federated risk scoring, verifiable credentials, and zero-knowledge issuance

Enabling description. Three integrations are specified. (i) Federated risk engine: an on-device logistic/tree ensemble fuses SIM-swap recency, porting recency, device-fingerprint novelty, behavioural cadence (inter-keystroke and gyroscope micro-motion features), and network context (cell ID churn), producing a continuous risk score; only the score and a bounded gradient leave the device under the same secure-aggregation and differential-privacy regime described in A-1, so the carrier never receives raw behavioural telemetry. (ii) Verifiable credentials: the verified identity assertion is issued as a W3C Verifiable Credential signed by the carrier as issuer, presented by the wallet to the relying party using an OpenID4VP-style exchange, with the holder bound by a DID whose verification method is the same secure-element key used for the silent check — so the "silent" check and the later credential presentation are cryptographically the same possession proof. Audit receipts are EIP-712-typed structured messages anchored to a permissioned ledger (Hyperledger Fabric channel with RAFT ordering) or to a public transparency log, giving append-only, tamper-evident records without putting personal data on-chain. (iii) Zero-knowledge issuance: where the relying party needs only a predicate ("the subscriber has held this number continuously for ≥ 90 days and no swap occurred"), the carrier issues a zk-SNARK proof over a signed state commitment, revealing no MSISDN; a Groth16 circuit over the commitment tree is the specified construction, with a 2 ms verification budget.

flowchart LR
  A["SIM swap and porting feed"] --> B["Federated risk model"]
  C["Device behavioural features"] --> B
  B --> D{"Risk below threshold?"}
  D -->|yes| E["Carrier issues W3C VC"]
  D -->|no| F["Step-up challenge"]
  E --> G["OpenID4VP presentation"]
  E --> H["zk-SNARK predicate proof"]
  G --> I["Relying party"]
  H --> I
  I --> J["EIP-712 receipt to ledger"]

Disclosed claim-style statement: A system in which a carrier-issued verifiable credential is bound to the same secure-element key used for silent possession verification, a zero-knowledge proof is issued over a signed subscriber-state commitment to establish a predicate without revealing the subscriber number, and verification receipts are written as typed, signed records to an append-only ledger.

---

B-6 · Axis 5 — Inverse / Failure Mode: graded-assurance fail-closed with oracle-attack resistance

Enabling description. This variant is engineered to degrade downward in capability, never upward in trust. The verifier maintains a ladder of sessions: L0 unauthenticated (marketing content only, no PII, no transactional affordances) → L1 possession-verified, read-only (account summary, no mutation) → L2 possession-verified + knowledge/biometric, transactional within a monetary cap → L3 hardware-authenticated, uncapped. Every failure transitions one rung down, never skipping upward. Specific defences: (i) timing-oracle resistance — all credential comparisons are constant-time and all outcomes wait on a fixed 250 ms floor so that match and mismatch are indistinguishable by latency; (ii) response-uniformity — the external error surface is a single generic auth_failed code, with the rich reason code available only on an operator-channel audit endpoint; (iii) silent lockout — after 5 mismatches in 10 minutes the endpoint returns success-shaped noise to the attacker while internally quarantining the binding, defeating enumeration; (iv) honeypot bindings — synthetic MSISDN bindings are seeded so that bulk probing is detectable; (v) fail-closed on dependency loss — if the carrier surface is unreachable, the system holds at L0/L1 rather than permitting L2, in direct opposition to a fail-open design; (vi) deliberate expiry — the possession assertion is capped at 15 minutes and the transactional cap at a per-tenant value, after which a re-verification is mandatory.

stateDiagram-v2
  [*] --> L0
  L0 --> L1 : possession verified
  L1 --> L2 : second factor verified
  L2 --> L3 : hardware authenticator verified
  L2 --> L1 : cap reached or assertion expiry
  L1 --> L0 : dependency unavailable
  L3 --> L1 : assertion expiry
  L0 --> Quarantine : five mismatches in ten minutes
  Quarantine --> L0 : lockout expiry

Disclosed claim-style statement: An authentication system comprising an assurance ladder in which each failed or inconclusive verification descends exactly one level, comparisons are constant-time with a fixed minimum response latency, external failure responses are uniform while reason codes are restricted to an operator audit channel, and dependency unavailability causes denial of the higher assurance levels rather than permissive fallback.

---

B-7 · Axis 1 — Material & Component Substitution: possession proofs that do not rely on the SIM or on the cellular identifier

Enabling description. The target binds the security code packet to a carrier identifier. This derivative removes that dependency in four substitutions, which matters for Wi-Fi-only tablets, MVNO grey areas, and enterprise-managed devices. (i) Authenticator-key substitution: replace SIM possession with possession of a FIDO2/WebAuthn authenticator (platform passkey in the secure element, or a roaming security key over CTAP2/NFC) whose credential ID is enrolled alongside the telephone number at onboarding; the "silent" assertion is then a WebAuthn getAssertion with userVerification: required and a server nonce as challenge, giving phishing-resistant, replay-proof possession. (ii) Network-attestation substitution: on Wi-Fi-only devices, substitute an 802.1X/EAP-TLS client certificate identity or a Passpoint/OpenRoaming certificate, or a TPM-backed device certificate, for the carrier identifier; the "subscriber network credential" then denotes a network access credential rather than a UICC credential. (iii) Proximity substitution: require a BLE GATT or UWB (IEEE 802.15.4z) ranging proof that the claiming device is within 2 m of a second factor device (a point-of-sale terminal or a colleague's enrolled phone), with the distance measurement signed by both endpoints and a freshness window of 5 seconds. (iv) Backup-channel substitution: where the carrier surface is unavailable, perform the possession check over the IMS/voLTE registration state exposed by the device (registered, IMSI present, scheme agreed) rather than over an SMS or a database lookup.

flowchart TD
  A["Claimed identity"] --> B{"Binding available"}
  B -->|UICC or eUICC| C["Carrier silent check"]
  B -->|FIDO2 passkey| D["WebAuthn assertion with nonce"]
  B -->|Wi-Fi enterprise| E["EAP-TLS certificate identity"]
  B -->|Proximate device| F["UWB or BLE signed ranging"]
  C --> G["Assurance level assignment"]
  D --> G
  E --> G
  F --> G
  G --> H["Session credential issuance"]

Disclosed claim-style statement: An authentication method in which the possession factor is satisfied by a WebAuthn assertion, an EAP-TLS client-certificate identity, or a signed ultra-wideband ranging measurement, any of which may be substituted for a subscriber identity module credential, with the resulting assurance level normalised before a session credential is issued.

---

3. Derivative disclosure — Family C: Personalized link generation, session binding, and abandoned-journey resumption

C-1 · Axis 1 — Material & Component Substitution: resume tokens instead of "hot" cookies, and channel substitution for the link itself

Enabling description. The target's device-bound "hot cookie" is replaced by a stateless, single-use resume artefact. Concretely: the server mints a JWE (alg HPKE with X25519 + ChaCha20-Poly1305, or ECDH-ES+A256GCM) whose plaintext claims are {sub, cart_ref, price_version, nonce, jti, exp, acr}; the artefact is bound to the device by a DPoP or WebAuthn-derived public key thumbprint stored in the claims (cnf.jkt), so possession of the token alone is worthless on a second device. Consumption is single-use, enforced by a jti-keyed replay store with a TTL equal to exp, and price_version invalidates the artefact if the underlying catalogue changed. The delivery channel for the link is likewise substituted: RCS rich card, push (APNs/FCM) deep link, an App Clip / Instant App invocation, a QR or GS1 Digital Link resolvable to the same resume artefact, an NFC tag (NDEF URI record), or a scannable code printed on a receipt. The landed page is composed at request time from the artefact claims plus live inventory, is not addressable without the artefact, and is never indexed.

sequenceDiagram
  participant U as User
  participant M as Messaging Channel
  participant R as Resume Service
  participant I as Inventory
  U->>M: selects link in rich message
  M->>R: GET resume with artefact
  R->>R: verify JWE and cnf.jkt binding
  R->>R: consume jti single use
  R->>I: fetch live price and stock
  I-->>R: availability
  R-->>U: composed page bound to device key

Disclosed claim-style statement: A method of resuming a prior online interaction in which a stateless encrypted resume artefact containing a confirmation-key thumbprint, a price-version discriminator, and a single-use identifier is delivered over any of a plurality of channels and is accepted only from the device holding the corresponding private key, and in which the destination document is composed at request time and is not otherwise addressable.

---

C-2 · Axis 2 — Operational Parameter Expansion: session lifetimes from 5 minutes to 10 years, and cross-device handoff

Enabling description. At one extreme, resume artefacts have a 5-minute TTL and are bound to a seat hold (concert ticketing), requiring re-minting on every interaction and forcing a forced re-composition of the document. At the other extreme, archival resume with a 10-year nominal lifetime is implemented by separating the artefact from a long-lived user-consent record: the artefact remains short-lived, but the server retains a cart_ref snapshot with a monotonic consent_version, and re-minting is permitted only for a consent that is still valid and whose jurisdiction still permits the processing. Key rotation is annual with a 24-month overlap window so that an archived artefact can be re-derived but not replayed. Cross-device handoff is implemented by showing a QR on device A that encodes a one-time pairing secret; device B proves possession of the pairing secret over a mTLS or DPoP channel and the server re-binds the artefact to device B's key thumbprint, revoking device A's binding atomically (compare-and-swap on the binding record) so the two bindings can never be simultaneously live. Volume envelope: 10⁸ resume artefacts minted per day, collision-free 11-character base58 identifiers over a 128-bit space with a distributed monotonic counter, and an artefact-store p99 read of 12 ms.

flowchart LR
  A["Prior session snapshot"] --> B["Consent record with version"]
  B --> C{"TTL class"}
  C -->|5 min seat hold| D["Mint ephemeral artefact"]
  C -->|10 year archival| E["Mint short artefact tied to consent"]
  D --> F["Device A binding"]
  E --> F
  F --> G["Pairing secret via QR"]
  G --> H["Device B proves pairing secret"]
  H --> I["Atomic rebind revokes device A"]

Disclosed claim-style statement: A resume system in which a short-lived encrypted artefact is decoupled from a long-lived consent record bearing a version, and in which device handoff atomically replaces a first confirmation-key binding with a second by compare-and-swap so that at most one binding is live at any instant.

---

C-3 · Axis 2 / Axis 5 — Low-power and limited-functionality operation: USSD, DTMF, and no-script paths

Enabling description. The entire resume mechanism is reduced to operate on a feature phone over 2G with no data session. A USSD session (*123*4#) drives a stateful menu on the network side, with each screen limited to 182 GSM-7 characters and each user response a single digit; the session state is keyed on the MSISDN-transaction-ID pair and persisted with a 90-second idle timeout. Where USSD is unavailable, an SMS keyword gateway accepts RESUME <code> and returns a 160-character confirmation with a numeric callback for IVR; the IVR path presents a DTMF menu (press 1 to complete, 2 to change quantity, 0 for an agent) whose selections are written to the same cart_ref. The web path is a no-JavaScript, single-column, progressive-enhancement page under 1 KB compressed, using POST-based form actions and server-side sessions keyed on a cookie-less opaque path segment, satisfying WCAG 2.2 AA (contrast ≥ 4.5:1, focus visible, 44×44 CSS-pixel targets, form labels programmatically associated) and functioning over GPRS at 50 kbit/s with a 3-second first-contentful-paint target. Assurance in these modes is deliberately capped: no payment-instrument details are ever rendered, and the final purchase uses an operator-assisted or callback confirmation.

stateDiagram-v2
  [*] --> EntryMenu
  EntryMenu --> IdentifierEntry : user dials USSD
  EntryMenu --> SmsKeyword : user texts RESUME code
  EntryMenu --> IvrMenu : user calls voice number
  IdentifierEntry --> ItemConfirm : code matched
  SmsKeyword --> ItemConfirm : code matched
  IvrMenu --> ItemConfirm : DTMF selection
  ItemConfirm --> AssistedClose : capped assurance
  AssistedClose --> [*]

Disclosed claim-style statement: A method of resuming a prior commerce session over a circuit-switched or unstructured supplementary service data channel, in which the session state is keyed on a subscriber number and a transaction identifier and is advanced by single-digit responses, and in which the resulting order is closed through an operator-assisted or callback confirmation rather than an in-session payment.

---

C-4 · Axis 3 — Cross-Domain Application: lending, airline booking, and utility enrolment

Enabling description — three unrelated industries.

(a) Financial services. An abandoned loan or account application is resumed with the partial-application state (verified income band, employment data, document-upload completion flag) preserved, but sensitive fields are never persisted in the resume artefact — only a reference to the tenant's own encrypted store, keyed per applicant. Regulated disclosures are re-rendered in full on every resume, with a fresh timestamp, because the artefact's price_version/terms_version claim forces re-disclosure if the APR table changed.

(b) Airline booking. An abandoned itinerary resume artefact carries the fare-class basis code and the hold expiry; on resume, the system re-validates against the fare-filing system, and if the basis has closed, presents rebooking options rather than an error. Name/DOB data are collected at the final step and are bound to the carrier-verified possession of the contact number to reduce fraudulent ticketing.

(c) Utility/telecom enrolment. An abandoned broadband signup resume carries the address candidate set and the coverage query result hash; on resume, the coverage query is re-executed (because address-level coverage changes), and the artefact carries a coverage_version claim so that a stale artefact triggers re-verification rather than a false activation.

flowchart TD
  A["Abandoned journey artefact"] --> B{"Vertical"}
  B -->|Lending| C["Reference to tenant encrypted store"]
  B -->|Airline| D["Fare basis and hold expiry"]
  B -->|Utility| E["Address candidates and coverage hash"]
  C --> F["Re-render disclosures with fresh terms version"]
  D --> G["Revalidate fare filing or offer rebook"]
  E --> H["Re-execute coverage query"]
  F --> I["Resumed session"]
  G --> I
  H --> I

Disclosed claim-style statement: A resume method in which the artefact carries a versioned claim for the governing terms, fare basis, or coverage result, and in which resumption re-validates that version against the live system and renders the full required disclosure afresh when the version has changed.

---

C-5 · Axis 4 — Integration with Emerging Tech: generative reconstruction, credential-anchored consent, and IoT restock triggers

Enabling description. (i) Reconstruction: a session-replay/telemetry embedding pipeline (sequence model over page-view and inter-event-timing tokens, 128-d embedding, FAISS index) infers the abandoned intent class and reconstructs candidate cart contents even where the original cart record is absent, presenting the inferred cart as a ranked shortlist with an explicit "[inferred]" affordance and a one-tap correction control that feeds back as a supervised label. (ii) Credential-anchored consent: the consent to re-contact is issued as a W3C Verifiable Credential with a purpose and validUntil field, presented on resume via OpenID4VP, so the resume flow can prove the basis for processing rather than merely asserting it; revocation is a status-list check performed at request time with a 60-second cache. (iii) IoT restock: a connected device (printer, water filter, espresso machine) reports a consumable level over MQTT; at a threshold (typically 15 %), the system mints a resume artefact for the previously purchased SKU, resolves the compatible replacement via GTIN matching, and offers one-tap reorder in a rich card — with the caveat that the consumable's counter may be consumer-resettable, so a stateless fallback (page-count deltas over a 30-day window) is used to corroborate.

flowchart LR
  A["Session telemetry"] --> B["Intent embedding and FAISS retrieval"]
  B --> C["Ranked inferred cart"]
  D["Consent VC with purpose"] --> E["Status list check"]
  F["Printer or filter telemetry"] --> G["Consumable threshold rule"]
  G --> H["GTIN compatibility match"]
  H --> I["One tap reorder card"]
  C --> J["Resume page"]
  E --> J
  I --> J

Disclosed claim-style statement: A resumption system in which an abandoned cart is reconstructed from session telemetry as a ranked shortlist presented with an explicit inference affordance and a correction control, the basis for re-contact is proven by presenting a verifiable consent credential subject to a status-list check, and a resupply trigger originates from consumable telemetry corroborated by a stateless usage-delta model.

---

C-6 · Axis 5 — Inverse / Failure Mode: privacy-preserving and share-resistant failure behaviour

Enabling description. The design assumes the link will leak. (i) Leak detection: whenever an artefact is presented from a device whose key thumbprint differs from the bound thumbprint, the system does not merely deny — it records a binding_mismatch event, rate-limits the presenting IP/ASN, and (where the presenter subsequently enrols their own number) issues a fresh artefact bound to them, converting a leaked link into a capture event rather than a data exposure. (ii) Honeypot artefacts: a small fraction of delivered messages carry artefacts pointing at decoy cart_ref values; access to a decoy is a strong signal of link harvesting, and the associated ASN is throttled. (iii) Revocation surface: the recipient is given one-tap "revoke this link", "revoke everything", and a self-service list of live bindings; revocation is a status-list write propagatable in under 60 seconds. (iv) Crypto-shredding for erasure: personal data is encrypted under a per-subject data key; a valid erasure request destroys the data key, rendering ciphertext unrecoverable, while the append-only audit record retains only a tombstone with a erasure_completed event. (v) Analytics minimisation: conversion analytics are computed only over cohorts of k ≥ 50 with differential-privacy noise on counts, so individual resume behaviour cannot be inferred from reporting. Failure of any of these controls (status-list unreachable, data-key service unavailable) causes the resume flow to fall back to a generic, un-personalised landing page with no cart contents.

flowchart TD
  A["Artefact presented"] --> B{"Thumbprint matches binding"}
  B -->|no| C["Record mismatch and throttle ASN"]
  B -->|yes| D["Check revocation status list"]
  D -->|revoked| E["Generic landing no cart data"]
  D -->|live| F["Serve personalised resume"]
  C --> G["Offer enrolment and reissue"]
  E --> H["Erasure request path"]
  H --> I["Destroy per subject data key"]
  I --> J["Tombstone in append only log"]

Disclosed claim-style statement: A resume system that detects presentation of an artefact from an unbound device and responds by throttling the presenting network while offering enrolment and reissue, that seeds decoy artefacts to identify harvesting, that implements erasure by destroying a per-subject data key while retaining only a tombstone record, and that serves an un-personalised fallback whenever a revocation or key-management dependency is unavailable.

---

4. Derivative disclosure — Family D: Sender trust, rich interactive UI primitives, and fallback messaging (element E9)

D-1 · Axis 1 — Material & Component Substitution: sender authentication across stacks, and durable warnings on a second channel

Enabling description. The target's "determine the sender, and on failure send an SMS warning" step is generalised by substituting the sender-authentication mechanism across stacks while keeping the warning behaviour invariant. Candidate substitutions: STIR/SHAKEN PASSporT verification (RFC 8224/8226) for the originating voice/SMS path, including full attestation (A), partial (B), and gateway (C) attestation levels and their treatment (A = treat as verified, B = treat as unverified for transactional actions, C = treat as blocked for transactional actions); RCS brand/verified-sender registration with the carrier's agent registry (agent ID, branding, colour, logo, and a signed agentInfo manifest); SPF/DKIM/DMARC alignment plus ARC sealing for the email path; VAPID JWT signing plus APNs certificate pinning for the push path; and DNSSEC + TLSA pinning of the RBM agent endpoint certificate so that a hijacked DNS answer cannot redirect the agent channel. On any failure, the warning is now delivered on a channel distinct from the suspect channel (push or email where the suspect is RCS; RCS or email where the suspect is SMS), and it is non-actionable: no URIs, no shortened links, no phone numbers — only a human-readable code the recipient can compare against an in-app code, plus an out-of-band verification affordance the recipient initiates. Warnings carry a 30-day retention and a warning_delivered receipt so that the campaigner can prove notice.

sequenceDiagram
  participant S as Sending Agent
  participant V as Sender Verifier
  participant R as Recipient Device
  participant W as Warning Channel
  S->>V: submit with PASSporT and agent manifest
  V->>V: verify attestation level and brand registry
  V-->>S: verified or unverified
  V->>R: deliver rich message when verified
  V->>W: send non-actionable warning when unverified
  W->>R: warning with human-readable comparison code
  R-->>V: acknowledgement of notice

Disclosed claim-style statement: A method in which, upon failure to authenticate the sender of a rich message, a warning is transmitted over a communication channel distinct from the channel of the suspect message and contains no actionable uniform resource identifier, no dialable number, and only a human-readable comparison code.

---

D-2 · Axis 2 — Operational Parameter Expansion: 10³ carriers, 200+ jurisdictions, and cost-optimised fallback ladders

Enabling description. At global scale the delivery decision becomes a constrained optimisation: choose the channel and the carrier route that minimise cost subject to (a) a deliverability SLA, (b) content-class admissibility in the destination jurisdiction, and (c) sender-authentication continuity. The fallback ladder is ordered by jurisdiction, not globally: RCS → MMS → SMS → OTT messaging → voice IVR, where the transition rules encode carrier-specific RCS coverage (some carriers operate RCS but not RBM), device capability, and content admissibility (e.g., a carousel with an image cannot degrade to SMS; it must degrade to a text summary plus a callback number). Regulatory constraints are compiled into a matrix keyed on ISO-3166 country code × content class, covering prior express written consent requirements, registration regimes (sender-ID pre-registration, short-code provisioning lead times measured in weeks), and quiet hours. A per-country delivery-quality feedback loop recomputes the ladder on a rolling 15-minute window so that a degrading route is deprioritised automatically. Volume envelope: 10⁹ messages/day across 10³ routes; ladder resolution in 4 ms; cost model refreshed hourly.

flowchart TD
  A["Message with content class"] --> B["Jurisdiction admissibility matrix"]
  B --> C{"RCS RBM available"}
  C -->|yes| D["RCS rich delivery"]
  C -->|no| E{"MMS supports media"}
  E -->|yes| F["MMS degradation"]
  E -->|no| G["SMS with text summary and callback"]
  D --> H["Delivery quality feedback loop"]
  F --> H
  G --> H
  H --> I["Route reweighting every 15 minutes"]

Disclosed claim-style statement: A multi-channel delivery method in which a fallback ladder is selected per destination jurisdiction from a content-class admissibility matrix, degradation from a rich format to a text format is accompanied by a substitution of media with a textual summary and a callback affordance, and route weights are recomputed from a rolling delivery-quality window.

---

D-3 · Axis 3 — Cross-Domain Application: emergency notifications, campus alerts, and cold-chain logistics

Enabling description — three unrelated industries.

(a) Emergency notifications. Alerting to a population within a polygon uses the same rich-message pipeline, with additional constraints: cell-broadcast (ETWS/CMAS/PWS) as the preferred path where the population is large and the message is short, RCS/SMS as the follow-up path carrying map cards and shelter links, and location determination via the carrier location API or the device's GNSS fix. The pipeline must operate without recipient opt-in, so the consent gate is replaced by a legal-basis gate, and the suppression gates of A-7 are disabled for the emergency class only.

(b) Campus alerts. Campus police dispatch feeds (CAD) generate alerts through a policy engine that maps incident type to channels and to building-level subgroups; the RCS card carries a "I am safe" action whose response is aggregated as k-anonymous counts rather than per-student locations, satisfying FERPA-minded data minimisation.

(c) Cold-chain logistics. A reefer telematics unit raising a temperature-excursion event triggers a message to the driver with a live temperature chart and to the consignee with a compliance document; the driver card offers escalate-to-dispatch and mark-inspection actions, and the message is logged with the telemetry hash for chain-of-custody purposes.

flowchart LR
  subgraph E["Emergency"]
    A1["Polygon alert"] --> A2["Cell broadcast"] --> A3["RCS map card follow up"]
  end
  subgraph C["Campus"]
    B1["CAD incident feed"] --> B2["Policy engine by building"] --> B3["I am safe aggregation"]
  end
  subgraph L["Logistics"]
    C1["Reefer excursion event"] --> C2["Driver temperature chart"] --> C3["Consignee compliance doc"]
  end
  A3 --> Z["Shared delivery ladder"]
  B3 --> Z
  C3 --> Z

Disclosed claim-style statement: A notification system in which a class-of-message policy selects among cell broadcast, rich messaging, and text messaging based on population size and content, incident or telemetry events are mapped to building-level or vehicle-level subgroups, and recipient responses are aggregated in k-anonymous form.

---

D-4 · Axis 4 — Integration with Emerging Tech: synthetic-media detection and attested sender registries

Enabling description. Sender trust is extended from identifiers to content provenance. (i) Media provenance: rich media attached to a message carries C2PA Content Credentials; the delivery pipeline verifies the manifest signature chain back to a trusted signer before rendering, and suppresses rendering (substituting a placeholder) if the manifest fails or if the manifest records generative derivation without a declared producer. (ii) Voice/avatar spoof detection: for voice-callback affordances and for avatar-based rich cards, an on-device liveness and synthetic-speech classifier (spectral-flatness, phase-coherence, and prosody-consistency features feeding a 4-layer CNN with a 3-second window) gates whether the affordance is presented; the classifier runs locally so that the recorded audio never leaves the handset. (iii) Sender registry: agent identities are published to an append-only transparency log (RFC 6962-style Merkle tree; Sigstore Rekor is the specified implementation) with the agent's signing key, brand artwork hash, and carrier authorisations; recipients' devices perform inclusion-proof verification on first contact and a monitor-style consistency check thereafter, so that a revoked agent is detectable without a round trip. (iv) IoT-attested senders: devices that originate campaigns (an edge gateway on a factory floor) sign the message manifest with a TPM-backed key whose endorsement certificate chains to a manufacturer root.

flowchart TD
  A["Outbound message with media"] --> B["C2PA manifest verification"]
  B -->|valid| C["Render media"]
  B -->|invalid| D["Placeholder rendering"]
  A --> E["Voice affordance liveness check"]
  E -->|genuine| F["Expose callback action"]
  E -->|synthetic| G["Suppress affordance"]
  A --> H["Agent inclusion proof via transparency log"]
  H -->|included and unrevoked| C
  H -->|revoked or absent| D

Disclosed claim-style statement: A messaging method in which attached media are rendered only upon verification of a content-provenance manifest chain, voice and avatar affordances are gated by an on-device synthetic-media classifier, and the sending agent's identity is verified through a Merkle inclusion proof against an append-only transparency log whose consistency is monitored for revocation.

---

D-5 · Axis 5 — Inverse / Failure Mode: pre-degraded safe messaging when signing is impossible

Enabling description. When the signing infrastructure is unavailable — HSM in maintenance, signature service degraded, carrier STIR/SHAKEN attestation withheld — the system does not send an unsigned message with the same affordances. It enters a pre-authored degraded mode: (i) all URIs, deep links, phone numbers, and one-tap actions are stripped at the composer level by a rendering filter that operates on the final byte stream, so no consumer of the pipeline can bypass it; (ii) the message is replaced with a fixed, pre-approved, human-reviewed template (versioned and hash-pinned) containing only the sender's legal name, a purpose statement, and a short reference code; (iii) the send is rate-limited to one degraded message per recipient per 7 days and excluded from the ML scheduler entirely (fixing the send instant to a fixed hour in the recipient's time zone); (iv) the recipient is invited to verify the message through an offline verification procedure (compare the reference code against the last statement or in-app notification) rather than by clicking anything; and (v) a degraded_delivery record with a manifest of stripped elements is written for audit. This is deliberately a worse message than an unsigned rich message would be — the design intent is that the absence of signing produces a message with strictly less capability.

stateDiagram-v2
  [*] --> SignCapable
  SignCapable --> DegradedMode : signing unavailable
  DegradedMode --> StripAffordances : rendering filter on byte stream
  StripAffordances --> FixedTemplate : hash pinned pre-approved text
  FixedTemplate --> ThrottledSend : one per recipient per seven days
  ThrottledSend --> OfflineVerify : compare code against statement
  DegradedMode --> SignCapable : signing restored and key revalidated

Disclosed claim-style statement: A messaging method that, upon loss of message-signing capability, applies a byte-stream rendering filter to remove every actionable element, substitutes a hash-pinned pre-approved template, fixes the send instant independent of any learned scheduler, and instructs the recipient to verify by comparing a reference code against an independent record.

---

D-6 · Axis 1 / Axis 2 — Material & Component Substitution for the UI primitives: carousels, typing indicators, and suggested actions across protocol stacks

Enabling description. Each rich-UI primitive claimed as dependent subject matter is disclosed in at least three protocol realisations, so that no single one can be claimed as the inventive choice. (i) Carousel. Realisations: RCS richCard array with cardOrientation: HORIZONTAL and per-card suggestedAction (GSMA Universal Profile); MMS SMIL presentation (<seq> of <img> and <text> with a linking <a href>), degrading to a <txtregion>-only layout on non-SMIL clients; an AMP-for-Email-style carousel or an XHTML/CSS scroll-snap container inside an embedded browser; a WhatsApp Flows / interactive-list payload; and a plain interactive voice menu where the "carousel" is an aural list navigated by DTMF. (ii) Typing/send-receive indicators. Realisations: CPIM isComposing/state in an MSRP or SIP session (RFC 3994) carried over the RCS IMS channel; a bespoke JSON state frame over a WebSocket when the RCS session is proxied through an OTT bridge; the Signal/Matrix ephemeral event (m.typing) in a Matrix room bridged to the agent; and — where no bidirectional session exists — a server-side simulated indicator driven by the agent's own composition timers, explicitly disclosed so that "the indicator need not reflect a human typist." (iii) Suggested responses. Realisations: RCS suggestedChipList; SMS keyword reply mapping (1/2/3 to semantic actions stored server-side against the message ID); email mailto with prefilled subject; and a signed short-code response for the degraded mode of D-5. Representation in each case is generated from a single channel-agnostic interaction schema (an ordered list of {id, label, action_type, payload}) rendered by a per-channel adapter.

flowchart TD
  A["Channel agnostic interaction schema"] --> B{"Target stack"}
  B -->|RCS| C["richCard array and suggested chips"]
  B -->|MMS| D["SMIL sequence with text region"]
  B -->|Email| E["HTML with scroll snap and mailto"]
  B -->|Messaging app bridge| F["Interactive list and typing event"]
  B -->|Voice| G["DTMF navigated aural list"]
  C --> H["Typing state frame"]
  F --> H
  H --> I["Response mapping to action identifier"]

Disclosed claim-style statement: A messaging method in which a channel-agnostic interaction schema comprising ordered interactive elements is rendered by a per-channel adapter into any of a rich-card carousel, a synchronized-multimedia-integration-language presentation, an HTML embedded-browser container, an application interactive list, or a dual-tone multi-frequency navigable list, and in which a typing indicator may be generated by the server from composition timers independently of any human typist.

---

5. Combination Prior Art scenarios (target patent + existing open standards)

Each scenario below is a publication-ready combination disclosure: the enumerated standard plus the described composition step, dated on publication, is § 102(a)(1) art against any later claim to the composition.

COMB-1 — RCS Universal Profile / RBM × CAMARA Network APIs × OpenID Connect CIBA + DPoP

Enabling description. Compose (i) the GSMA RCS Universal Profile agent model (RBM agent with agentId, signed agent manifest, rich cards, suggested actions, IMDN read receipts) with (ii) the CAMARA carrier network APIs — specifically Number Verification (returns a verified boolean against an access token issued to the device over the mobile data path, requiring no SMS OTP) and SIM Swap (returns the date of the most recent SIM swap) — and (iii) OpenID Connect with CIBA (Client-Initiated Backchannel Authentication) for decoupled authentication, and RFC 9449 DPoP for sender-constrained tokens. The composition rule disclosed is: a campaign message is dispatched over the RCS agent channel only if NumberVerification == true for the device's access token, and SIM Swap date is older than a configured freshness window (default 7 days), and the subsequent agent API calls present the DPoP-bound access token; otherwise the message is downgraded to a non-actionable text as in D-5. This combination is machine-checkable and requires no proprietary element.

sequenceDiagram
  participant App as Mobile App
  participant IDP as OpenID Provider
  participant CAM as CAMARA Network API
  participant AG as RCS Agent Platform
  App->>IDP: CIBA backchannel auth request
  IDP->>CAM: Number Verification for access token
  CAM-->>IDP: verified true
  IDP->>CAM: SIM Swap recency
  CAM-->>IDP: last swap older than window
  IDP-->>App: DPoP bound access token
  App->>AG: agent API call with DPoP proof
  AG-->>App: rich message delivered

---

COMB-2 — 3GPP GBA / EAP-AKA′ × W3C WebAuthn × OpenID4VP

Enabling description. Compose (i) 3GPP Generic Bootstrapping Architecture (TS 33.220) with EAP-AKA′ (RFC 5448) — or IMS AKA under TS 33.203 — to derive a shared key Ks_NAF between the device's UICC and a Network Application Function without transmitting the long-term secret; (ii) W3C WebAuthn Level 2 with platform authenticators for a user-presence and user-verification gesture; and (iii) OpenID4VP for presentation of a carrier-issued verifiable credential bound to the WebAuthn credential's public key. The disclosed composition: the GBA bootstrap establishes a device-network shared key used to authenticate the transport to the relying party; the WebAuthn assertion supplies the user-verification factor and the holder binding; the OpenID4VP presentation conveys the carrier's identity assertion to a third-party relying party with a predicate ("number held continuously ≥ 90 days") evaluated by the issuer rather than the relying party. This yields a silent-plus-explicit, phishing-resistant, privacy-minimising authentication stack built entirely from published standards.

flowchart LR
  A["UICC and Bootstrapping Server"] --> B["EAP-AKA prime key derivation"]
  B --> C["Network Application Function session"]
  D["Platform authenticator"] --> E["WebAuthn assertion with challenge"]
  C --> F["Carrier credential issuance"]
  E --> F
  F --> G["OpenID4VP presentation to relying party"]
  G --> H["Predicate satisfied without revealing number"]

---

COMB-3 — ONNX Runtime × Feast × OpenTelemetry × Flower × OpenLineage

Enabling description. Compose an ML-delivery pipeline from open components: Feast as the online/offline feature store providing point-in-time-correct features for the classification and scheduling model; ONNX Runtime as the portable inference engine (INT8 quantised graph exported from any trainer) executing both server-side and on-device; Flower as the federated-learning orchestration layer with secure aggregation; OpenLineage for lineage capture of every feature set, model artefact, and training run; and OpenTelemetry for tracing the inference call, the channel dispatch, and the receipt event under one trace ID. The disclosed composition is the system: a point-in-time-correct, federated, lineage-tracked, traceable message-scheduling service — i.e., the engineering realisation of "scheduling, using a machine learning model and based on the determined classification." None of these components is novel; their combination into a compliant campaign scheduler is disclosed here as obvious engineering.

flowchart TD
  A["Feast offline store"] --> B["Point in time feature join"]
  B --> C["Model training with OpenLineage capture"]
  C --> D["ONNX artefact registry"]
  D --> E["Flower federated round"]
  E --> F["On device ONNX Runtime inference"]
  D --> G["Server side ONNX Runtime inference"]
  F --> H["OpenTelemetry span emission"]
  G --> H
  H --> I["Dispatch and reward logging"]

---

COMB-4 — schema.org Commerce × W3C Web Payments × GS1 Digital Link × OpenID for Verifiable Credentials

Enabling description. Compose (i) schema.org Offer/Order/OrderAction vocabulary serialised as JSON-LD to describe the resumable cart; (ii) W3C Web Payments (Payment Request API and Payment Handler API) for the in-context completion step, with a payment handler registered by the merchant's origin; (iii) GS1 Digital Link (https://id.gs1.org/01/{GTIN}/21/{SERIAL}) as the resolvable, standards-based identifier printed on the package or the receipt and resolvable to the same resume artefact; and (iv) OpenID for Verifiable Credentials for presenting a purchase-authorising credential. The disclosed composition is a resume flow in which a scannable GS1 Digital Link on a physical object resolves through a merchant-controlled resolver to an artefact in the sense of C-1, the cart is described in schema.org JSON-LD, the payment is completed through the Web Payments APIs without leaving the browsing context, and any age or entitlement predicate is proven by presenting a verifiable credential rather than by uploading identity documents.

flowchart LR
  A["Physical object with GS1 Digital Link"] --> B["Resolver maps to resume artefact"]
  B --> C["Cart described in schema.org JSON-LD"]
  C --> D["Payment Request API invocation"]
  D --> E["Registered Payment Handler"]
  B --> F["OpenID4VC predicate presentation"]
  F --> G["Age or entitlement satisfied"]
  G --> D
  D --> H["Order confirmation"]

---

COMB-5 — STIR/SHAKEN × C2PA × MQTT/Sparkplug B × Sigstore Rekor and Hyperledger Fabric

Enabling description. Compose a chain-of-custody messaging stack: STIR/SHAKEN (RFC 8224 PASSporT; RFC 8226 certificate management) attests the originating telephone identity; C2PA attests the provenance of attached media; MQTT with the Sparkplug B topic namespace carries the triggering telemetry from field devices with birth/death certificates establishing session state; Sigstore Rekor provides an append-only transparency log with Merkle inclusion proofs for agent identities, message manifests, and firmware artefacts; and Hyperledger Fabric (RAFT ordering, private data collections) stores the permissioned business record. The disclosed composition is a supply-chain-verified messaging pipeline: a Sparkplug B telemetry event from a cold-chain asset triggers a rich message whose telemetry payload hash, media provenance manifest, sender attestation, and agent identity inclusion proof are all recorded as a single atomic, append-only audit entry that a downstream consignee can independently verify without trusting the sender.

flowchart TD
  A["Cold chain sensor Sparkplug B event"] --> B["Message compose with telemetry hash"]
  C["STIR SHAKEN PASSporT"] --> B
  D["C2PA media manifest"] --> B
  B --> E["Agent identity inclusion proof from Rekor"]
  E --> F["Fabric private data record"]
  F --> G["Consignee independent verification"]
  G --> H["Dispute resolution with chain of custody"]

---

6. Publication protocol (how to make this art legally effective)

---

7. Prior-art matrix — derivative → element neutralised

---

8. Residual uncertainties and verification actions

1. Claim text and numbering remain unverified — consistent with every prior section. The elements above are keyed to the patent's Summary and FIGS. 17–18 and to the claim-18 recitation reported in the Intuit complaint analysis. Verify against the granted claims before any filing or opinion that depends on element boundaries.
2. The claim 6 / claim 12 / claim 18 discrepancy is unresolved and is now triply sourced: the Intuit analysis references "independent claim 6" and recites claim 18; the Salesforce analysis asserts "independent claim 12"; my retrieval corroborated both third-party analyses verbatim. Do not auto-reconcile. The grant document controls.
3. Date discrepancy carried forward — task date 2026-04-26; session date 2026-09-25; docket and PTAB events span 2026-04-30 through 2026-09-24. Same unreconciled gap as prior sections; not a new contradiction.
4. Legal effect caveat. As stated in §0.1, this dossier creates art only against later-filed third-party claims. It does not, and cannot, invalidate US 12,368,799. The '799's own vulnerability, if any, lies in the CIP written-description/priority question (whether the RCS/AMDA/SNAP limitations are supported by the 2018-09-27 provisional and the 2019-09-25 PCT) and in the pre-2023 art set analysed in the previously generated Obviousness section.
5. Standards references are recited by identifier, not verified clause-by-clause in this session. Confirm current revision numbers and section references against the standards bodies' published documents before relying on any clause-level citation in a filing.