Invent — Convergence Radar

🛠 Invent — what can we INVENT at patents × breakthroughs × pain

The inventor + patent-analyst lens. A real invention appears where three things overlap: a technology or trade breakthrough that just changed what's possible, a patent-landscape signal (CROWDED = validated demand, design around; WHITESPACE = open to claim), and a real, specific pain. Each item is a concrete inventable artifact — a device, method, system, or defensible mechanism a solo founder can prototype in weeks. Kept only at feasibility ≥ 7/10 and a moat ≥ 3 months. Deliberately weighted away from federal money — money is at most a demand signal, never the thesis. JSON: /api/invent

FEAS 7 MOAT 4mo CROSS-DOMAIN TRANSFER Automated Out-of-Band Callback Verifier for Inbound 'Bank/Government' Calls 07-13 09:07

💡 Invention: We invent a phone-side service that, on any inbound call or text claiming to be a bank/government/carrier, intercepts it, looks the claimed institution up in a curated canonical-number directory, and automatically places an independent outbound call to that verified public number — bridging the user in only if the institution confirms an active contact, so spoofed caller-ID is defeated by out-of-band re-contact rather than by guessing.

Problem: FTC reports $3.5B lost to imposter scams in 2025, ~3x since 2020, dominated by fake bank/government 'security alert' calls; consumers (especially elders) have no automatic way to tell a spoofed inbound call from the real institution.

✳ novelty: The non-obvious transfer is taking out-of-band callback authentication — the proven anti-fraud mechanism banks use for card-not-present transactions and 2FA — and inverting it to defend the CONSUMER's inbound channel: an automated callback-to-canonical-number bridge triggered by inbound-call risk, with reconciliation of whether the institution actually has an open contact. The claim seed is the automated inbound-to-verified-outbound reconciliation flow. 📜 prior art: Whitespace on the mechanism, crowded on adjacency: carrier STIR/SHAKEN attests the CALLER but does nothing once a number is spoofed or a real number is social-engineered; existing consumer apps only do blocklist/heuristic scoring. Nobody productizes automated out-of-band callback reconciliation for the recipient — that specific flow is open.

🚀 breakthrough: Unified programmable voice+SMS on a single number with post-call transcripts through one handler (Vercel Chat SDK Dial support, id 35) collapses what used to be a full telephony pipeline into weeks of solo work, making automated intercept-and-callback economically buildable. ⚙ mechanism: Route the user's line through the service; on inbound, parse claimed institution from caller-ID/transcript; match against a maintained directory of canonical published numbers; place an outbound verification call/API check to that number; only bridge or greenlight if verified, else warn 'hang up — spoofed, we called the real number and there is no active contact'. Deterministic routing + directory lookup, not a black box.

🔧 prototype: In weeks: a single Twilio/Chat-SDK number that on inbound reads the claimed bank name, dials that bank's real published line, and demonstrates it catches a spoofed test call while passing a genuine one. 🛡 defense: Speed-to-market plus a curated, continuously-corrected canonical-number directory (a maintenance data moat); the flow itself is thin, so first-mover distribution and the directory are the durable edge.

bridges: complaint, platform 💰 Pays: Adult children buying elder protection (subscription); credit unions and community banks white-labeling it for their at-risk customers.

🔪 Kill test: Run 20 real bank/government lines through the callback flow: if carrier call-forwarding, IVR mazes, or shared numbers make automated reconciliation unreliable more than rarely, the false-alarm rate kills user trust and the product fails.

FEAS 8 MOAT 6mo CROSS-DOMAIN TRANSFER Personalized Changepoint Engine for Medication Response from a Consumer Smart Ring 07-13 09:07

💡 Invention: We invent a phone/cloud engine that runs sequential per-individual changepoint detection (CUSUM/Bayesian online changepoint) over a smart ring's continuous HRV, skin-temperature, respiratory-rate and sleep-architecture streams to flag the exact day a new medication (e.g., a GLP-1, SSRI, beta-blocker, or supplement) starts, stops, or adversely shifts a user's physiology relative to their own pre-drug baseline.

Problem: Patients starting or titrating chronic meds have no objective, cheap way to know if the drug is actually working or harming them between clinic visits; today it is subjective self-report. Clinical-grade wearable-efficacy measurement is being locked up by pharma, leaving the consumer self-tracking side unserved.

✳ novelty: The non-obvious core is transferring statistical process control (SPC/CUSUM) from factory quality monitoring into per-person pharmacodynamics: a personalized-baseline sequential changepoint model that calibrates to each individual's noise floor and emits a dated onset/adverse-shift event with a confidence band, rather than a population model or a bare LLM 'insight'. The claimable seed is the personalized-baseline calibration + drug-event alignment method. 📜 prior art: Mixed and honestly readable: Sanofi's filed utility patent on 'evaluating drug efficacy using wearable sensors' (id 6357) shows the CLINICAL/pharma end is actively being claimed and is getting CROWDED — but that filing targets sponsored trials and pharma-owned devices; the CONSUMER-ring self-titration use with personalized changepoint calibration is whitespace. Design around the clinical claims, own the consumer method.

🚀 breakthrough: The maturation of the consumer smart-ring platform (Oura Ring 5, id 6126) exposing continuous multi-sensor physiological streams via API at clinical-adjacent fidelity — the first time a solo dev can get labeled, dense, longitudinal individual data without hardware, combined with cheap autonomous analysis tooling (id 675). ⚙ mechanism: Pull the ring API's nightly HRV/temp/respiration/sleep series; fit a personalized baseline over a 14-day pre-event window; run online Bayesian changepoint + CUSUM on standardized residuals; when the user logs a med start, align detected changepoints to the dose window and score onset latency, direction, and magnitude; surface a dated 'response detected / no response / adverse shift' card with the underlying series. No 'AI decides' — it is an explicit, auditable statistical pipeline.

🔧 prototype: In two to three weeks: pull one developer's own ring history around a known physiological intervention (caffeine cessation, alcohol, or a real med start), implement CUSUM + one online changepoint library, and show the detector fires on the known-onset day and stays silent on control weeks. 🛡 defense: Data moat + speed: the labeled corpus of (drug event → personalized physiological response) accumulates with every user and cannot be copied; ship the consumer method before pharma's patents extend downstream.

bridges: wearable, ai 💰 Pays: Patients self-titrating GLP-1s and psychiatric meds (subscription); telehealth/coaching clinics wanting objective between-visit signal; supplement brands wanting efficacy proof for their buyers.

🔪 Kill test: On an existing labeled dataset with a known-onset intervention, check whether personalized CUSUM separates real onset from week-to-week noise at usable sensitivity/specificity — if changepoints fire as often on control weeks as on drug weeks, the signal is not real and the product dies.

FEAS 7 MOAT 4mo BREAKTHROUGH-ENABLED ARTIFACT WristCast: commodity-wrist-IMU in-air gesture controller for budget AR glasses 07-13 09:07

💡 Invention: We invent a wrist-IMU SDK that turns an ordinary smartwatch/wristband into a universal multi-stage in-air gesture controller streaming HID events to the new wave of controller-less budget AR glasses.

Problem: Sub-$300 display AR glasses are shipping without any input device, leaving app builders no reliable hands-free controller for cheap glasses that lack cameras/controllers.

✳ novelty: Non-obvious core: a multi-stage (arm-then-finger) gesture state machine running on low-cost consumer wrist IMU data mapped to a standard BLE-HID control surface any glasses app can consume — device-agnostic input where none is bundled. 📜 prior art: Crowded/validated: Meta's utility patent on multi-stage in-air wrist-detected gestures for smart-glasses UI (id 6356) confirms the paradigm is real and the core is being claimed — so this must design around Meta's specific claims and rely on speed, not a blocking patent.

🚀 breakthrough: Mass-market controller-less AR glasses arriving now (XREAL $300 glasses id 3263; Vision Pro third-party controller spec id 3265 confirming demand for external input) — the display hardware is finally cheap and widespread but ships input-less. ⚙ mechanism: On-wrist app samples the watch IMU, an on-device classifier segments arm-lift + micro-finger-flick stages, debounces via a state machine, and emits standard BLE-HID pointer/select events the glasses' host consumes with no glasses-side code.

🔧 prototype: A Wear OS app that recognizes 3 gestures (point, pinch-select, swipe) and drives a cursor on a tethered XREAL display via BLE-HID. 🛡 defense: Speed-to-market to become the default controller-less input layer before OEMs standardize, since Meta's patent blocks the strongest claims.

bridges: wearable, android 💰 Pays: Budget-AR app studios and glasses OEMs wanting a bundled input story; SDK license or OEM integration fee.

🔪 Kill test: Blind-test gesture accuracy on 10 users wearing a stock smartwatch; if false-trigger rate makes it unusable versus a phone touchpad, kill it.

FEAS 7 MOAT 6mo BREAKTHROUGH-ENABLED ARTIFACT RingBridge: consumer smart-ring raw signals → validated clinical trial endpoints 07-13 09:07

💡 Invention: We invent a decentralized-trial SDK that ingests raw PPG/skin-temp/HRV/accelerometer streams from consumer smart rings and transforms them into pre-registered, statistically-validated digital efficacy endpoints with a tamper-evident provenance trail.

Problem: Pharma/CRO decentralized trials want continuous physiological data but consumer rings emit raw/proprietary streams, not the pre-specified, auditable endpoints regulators and statisticians require.

✳ novelty: The claim seed is the deterministic, versioned pipeline that converts device-specific raw signals into a locked, pre-registered endpoint definition plus a cryptographic provenance chain linking each endpoint value back to raw samples — not any new sensor. 📜 prior art: Validated but crowded: Sanofi's utility patent on evaluating drug efficacy via wearable sensors (id 6357) proves major-pharma demand and that the outcome space is claimed — so design around by claiming the raw-to-endpoint transform + provenance layer, not efficacy measurement itself.

🚀 breakthrough: The consumer smart-ring platform maturing to research-grade and API-accessible (Oura Ring 5, id 6126) — continuous multi-signal capture at consumer scale that a solo dev can pull today without building hardware. ⚙ mechanism: SDK pulls raw ring samples via vendor API, runs signal-quality gating + a pre-registered feature transform (e.g., nocturnal HRV recovery slope) whose code hash is locked before unblinding, writes each endpoint value with a Merkle-linked pointer to source samples, and exports a regulator-friendly dataset + audit log.

🔧 prototype: Build the ingest+locked-transform+provenance chain against Oura's API and reproduce one published digital biomarker end-to-end from raw data. 🛡 defense: Data moat (accumulated validated device-to-endpoint mappings) plus speed to occupy the pre-registration/provenance niche Sanofi's patent doesn't claim.

bridges: wearable, ai 💰 Pays: Pharma sponsors and CROs running decentralized/hybrid trials; per-trial or per-subject licensing.

🔪 Kill test: Have a trial biostatistician review one locked endpoint's provenance output; if it can't be trusted for regulatory submission versus a hospital-grade device, the value prop collapses.

FEAS 8 MOAT 7mo BREAKTHROUGH-ENABLED ARTIFACT Manifest-to-MCP: auto-generate a spec-compliant on-device Android agent server 07-13 09:07

💡 Invention: We invent an Android SDK that introspects an existing app's declared intents, content-provider schemas, and Room DAOs and auto-emits a bound, on-device MCP server so OS-level agents invoke the app's functions directly instead of driving its UI.

Problem: Android 17 lets an app be an on-device MCP server, but hand-authoring tool descriptors + a spec-compliant server for every function is real work, and the 2026-07-28 MCP spec deadline means most servers are non-compliant.

✳ novelty: Deriving agent-callable tool schemas (names, params, side-effect flags, auth scopes) automatically from an app's manifest + persistence layer, plus a codegen'd server that self-validates against the dated spec — the claimable core is the introspection-to-tool-descriptor transform, not the transport. 📜 prior art: Whitespace-adjacent: swaggertomcp (id 2208) covers web OpenAPI/SQL, and mcp-spec-check (id 5781) only audits compliance — neither generates an on-device server from Android app surfaces; the on-device Android MCP capability (id 839) is weeks old, so the design-around space is open.

🚀 breakthrough: Android 17 exposing apps as on-device MCP servers (id 839) — before it, a system agent could only navigate an app's UI; now app functions are directly invocable, making descriptor auto-generation worth building. ⚙ mechanism: At build/install time the SDK reads the merged manifest intents, exported content-provider URIs, and annotated DAO methods, maps each to an MCP tool descriptor (typed args, read/write side-effect tag), and stands up an AIDL-bound local MCP endpoint that marshals agent calls to the corresponding Intent/query and streams typed results, validating the emitted schema against the 2026-07-28 spec.

🔧 prototype: A Gradle plugin + runtime lib that, for a demo to-do app, auto-exposes 'add/list/complete task' as MCP tools and answers a live agent call end-to-end. 🛡 defense: Speed-to-market + ecosystem-default lock-in (be the library everyone integrates before Google ships first-party codegen), plus accumulated mapping heuristics as a data moat.

bridges: android, ai 💰 Pays: Android app publishers who want agent-driven distribution and must hit the spec deadline; per-app license or SaaS.

🔪 Kill test: Point the generator at 5 real open-source apps; if the auto-derived tools require manual rewrite more often than not, the automation thesis dies.

FEAS 8 MOAT 4mo DESIGN-AROUND N-of-1 Efficacy Engine on Consumer Rings (Around Pharma's Clinical-Device Patent) 07-13 09:07

💡 Invention: We invent a within-subject change-point engine that measures whether a specific drug or supplement actually moves a person's objective sleep/HRV/temperature signal, computed from passive consumer smart-ring data keyed to self-logged dose timing — no clinical device, no validated biomarker required.

Problem: Proving a compound 'works for me' is locked behind clinical trials and proprietary medical wearables; consumers and DTC brands have no cheap, credible way to show real-world efficacy.

✳ novelty: The non-obvious core is a Bayesian change-point / interrupted-time-series method that infers efficacy from noisy CONSUMER passive data around dose onset/withdrawal, rather than the incumbent's device-specific validated-biomarker measurement. 📜 prior art: CROWDED (Sanofi and others are actively patenting wearable-sensor efficacy measurement) — validating the market — but claims lean on clinical/validated-device means; the consumer-ring, change-point statistical route is a lawful design-around.

🚀 breakthrough: The current smart-ring generation delivers research-grade continuous HRV/temperature/sleep via open APIs, and autonomous research-agent tooling lets a solo dev auto-generate the N-of-1 protocol and statistical writeup — the pair that makes this buildable in weeks. ⚙ mechanism: Pull continuous ring metrics, align to a user's dose/withdrawal log, run interrupted-time-series with a change-point detector and effect-size + credible interval, and emit a plain-language 'did it move your baseline' report; the agent handles protocol generation and narrative, the statistics do the actual detection.

🔧 prototype: Ingest one user's ring export, detect a KNOWN effect (caffeine or melatonin on HRV/sleep) above noise, and produce a signed effect-size report. 🛡 defense: Method patent on the consumer-data change-point efficacy pipeline plus a data moat from accumulated per-compound response distributions.

bridges: wearable, ai 💰 Pays: Supplement and DTC-pharma brands wanting real-world evidence, plus biohacker/patient N-of-1 subscribers.

🔪 Kill test: Run it on rings from people taking a compound with a known objective effect: if it can't recover that effect above noise, the mechanism is invalid.

FEAS 7 MOAT 4mo DESIGN-AROUND Finger-Ring Micro-Gesture Bridge for Budget Display Glasses (Around Meta's Wrist-Wearable Claim) 07-13 09:07

💡 Invention: We invent a phone-hosted bridge that turns micro-gestures sensed by a device users already wear on a FINGER (smart ring IMU) or in-ear buds into UI control for camera-free display glasses, achieving hands-free glasses control without the wrist-worn controller incumbents require.

Problem: Cheap display glasses (XREAL, MemoMind) have no good hands-free input; the emerging answer — a dedicated wrist-wearable detecting in-air gestures — adds a whole extra device most buyers won't wear, and it's being patented.

✳ novelty: The non-obvious core is mapping finger-borne IMU micro-taps/rotations (ring) — a different body location and sensing means than the claimed WRIST device — into a multi-stage glasses-UI command grammar, sidestepping the wrist-wearable limitation of the incumbent claim. 📜 prior art: CROWDED and actively-claimed (Meta's wrist-gesture-for-glasses filing) — validated demand — but the claims are anchored on a WRIST-WORN detector; finger-ring / in-ear sensing is a lawful design-around, not open whitespace.

🚀 breakthrough: Consumer smart rings now ship precise low-power IMUs with open-ish BLE data, and sub-$300 display glasses give a real installed surface — the exact hardware convergence that makes a bridge buildable now. ⚙ mechanism: A companion app ingests the ring/earbud IMU stream, runs a lightweight on-device gesture classifier (tap, double-tap, roll, hold) into a state machine, and emits BLE HID/companion commands to the glasses to move focus, select, and dismiss — no camera, no wrist device.

🔧 prototype: Pair one commodity smart ring + one $300 display-glass SDK, ship a demo where ring taps navigate a glasses menu with sub-150ms latency. 🛡 defense: Patent on the finger/ear-to-glasses gesture-mapping mechanism plus speed-to-market before the ecosystem standardizes on wrist controllers.

bridges: wearable, android 💰 Pays: Budget AR-glasses makers wanting an input story without shipping their own controller, and accessibility buyers needing non-voice, non-camera control.

🔪 Kill test: Blind-test ring-tap navigation vs a physical glasses button: if accuracy/latency is meaningfully worse than a button, nobody adopts it.

FEAS 8 MOAT 4mo DESIGN-AROUND eBPF Runtime Sentinel for the GhostLock Stack-UAF (No Recompile, No Kernel Patch) 07-13 09:07

💡 Invention: We invent a userspace-installable eBPF sensor that detects live exploitation of the GhostLock/IonStack stack use-after-free at runtime by watching for its signature stack-frame reuse pattern, giving unpatched Linux fleets an interim mitigation without recompiling anything.

Problem: A stack-UAF (GhostLock) is disclosed as present in all Linux distros for ~15 years; every incumbent defense (shadow stacks, CFI, ASAN) requires recompiling the kernel/binaries or an intrusive kernel patch that ops teams cannot ship on production fleets overnight.

✳ novelty: The non-obvious core is detecting the exploit BEHAVIORALLY at the syscall/stack-tracepoint layer via eBPF — flagging a freed stack region being re-entered/dereferenced within a suspicious window — rather than preventing the bug at compile time. The patent-claim seed is the specific eBPF probe set + heuristic that fingerprints stack-frame-reuse-after-return. 📜 prior art: CROWDED cluster (shadow-stack/CFI/instrumentation patents are dense) but every incumbent claims a COMPILE- or KERNEL-modification means; the runtime, zero-recompile eBPF detection path around those claims is comparatively open — design-around, not whitespace.

🚀 breakthrough: The GhostLock disclosure gives the exact exploitation primitive to fingerprint, and mature stable eBPF stack-walk/tracepoint tooling lets a solo dev instrument the kernel from userspace without patching it. ⚙ mechanism: An eBPF program hooks return/free-adjacent tracepoints, tracks stack-frame lifetimes per task, and raises an alert (or kill) when a returned/freed frame region is dereferenced in a way matching the GhostLock primitive; a small AI-security-tooling layer triages the alert stream for false positives.

🔧 prototype: Write the eBPF probe against a public GhostLock PoC in a VM, prove it catches the exploit and measures false-positive rate + overhead on a normal workload; ship as a one-command loadable sensor. 🛡 defense: Speed-to-market + trade-secret detection heuristics; the fingerprint tuning is the moat, and being first with a no-recompile control captures the disclosure-window demand.

bridges: dev, ai 💰 Pays: Enterprises and MSPs running large unpatched Linux fleets (finance, telco, cloud) who need a documented interim control between disclosure and full patch rollout.

🔪 Kill test: Run the sensor on a busy production-like workload: if it either misses the PoC exploit or throws intolerable false positives / >5% overhead, it is dead.

FEAS 7 MOAT 4mo WHITESPACE CLAIM Runtime eBPF sensor for the GhostLock (IonStack) stack-UAF pattern 07-13 09:07

💡 Invention: We invent a userspace-loadable eBPF sensor that detects the specific GhostLock stack use-after-free exploitation pattern at runtime on unpatched Linux fleets and alerts/mitigates without waiting for a kernel patch.

Problem: GhostLock is a freshly disclosed stack UAF claimed present across all Linux distributions for 15 years; fleets cannot patch instantly, and there is no targeted detection for exploitation of this exact class in the patch-gap window.

✳ novelty: A tuned kprobe/eBPF signature for the IonStack stack-reuse-after-free access pattern — detecting the anomalous stack-slot lifetime/reuse sequence characteristic of GhostLock exploitation, rather than generic heap-UAF heuristics. 📜 prior art: WHITESPACE (time-boxed). The disclosure is brand new (signal 6122); generic UAF detectors exist but no shipped tool encodes this specific stack-UAF signature. AI vuln tooling like Daybreak (signal 1055) is being pointed at discovery/patching broadly, but a targeted runtime detector for this named bug is unclaimed for now — first mover in the patch-gap window.

🚀 breakthrough: The GhostLock/IonStack public disclosure itself (signal 6122), which specifies the vulnerable stack-reuse mechanism precisely enough to write a behavioral signature — paired with AI-assisted vuln analysis (signal 1055) to derive and refine the detection pattern. ⚙ mechanism: An eBPF program attaches kprobes to the implicated allocation/free and stack-frame reuse sites, watches for the disclosed lifetime-violation sequence (freed stack region re-accessed before reallocation), scores it, and emits an alert or blocks the offending syscall path; ships as a signed loadable module + userspace agent, no kernel rebuild.

🔧 prototype: Reproduce the disclosed pattern in a test harness, write the eBPF probe that flags it, and validate detection vs. a false-positive baseline on ordinary workloads — a weeks-long build for a competent eBPF/security dev. 🛡 defense: Speed-to-market and trade-secret detection heuristics during the patch window; moat is short because distros will patch and signatures get copied.

bridges: dev, ai 💰 Pays: Ops/security teams running large unpatched Linux fleets (the r/sysadmin buyer) that need coverage during the patch-gap; MSSPs bundling it into detection stacks.

🔪 Kill test: Run the sensor against a benign production workload for a week; if false-positive rate is high enough to be un-deployable — or distros patch faster than sensor adoption — it is dead.

FEAS 8 MOAT 6mo WHITESPACE CLAIM Payment-bound proof-of-delivery receipts for machine-payable MCP tools 07-13 09:07

💡 Invention: We invent a middleware that turns any MCP tool into a machine-payable endpoint whose x402 payment is cryptographically bound to a signed proof-of-delivery receipt, enabling automatic agent-side reconciliation and refunds.

Problem: Agents can now pay per request for tools/APIs via x402, but there is no verifiable link between a payment and whether the tool actually returned a correct/complete result — agents pay blind, with no automated dispute or refund path.

✳ novelty: A signed per-invocation receipt that hashes together {input, output, price, timestamp, tool identity} at the moment of settlement, so the paying agent can independently verify delivery and trigger an automated refund on non-delivery — payment and result provenance fused into one artifact. 📜 prior art: WHITESPACE. x402 (signal 16) only just made per-request agent payment possible, and one-command MCP-server generation (signal 2208) only just made tool endpoints cheap to stand up; both are settlement/plumbing layers. Neither claims the proof-of-delivery receipt binding payment to a verifiable tool output — the machine-to-machine dispute layer is unbuilt and unclaimed.

🚀 breakthrough: Cloudflare's x402 monetization gateway making arbitrary resources (including MCP tools) payable per-request by autonomous agents (signal 16), combined with instant OpenAPI/DB-to-MCP server generation (signal 2208). ⚙ mechanism: Middleware wraps an MCP tool; on call it requires an x402 payment, executes the tool, then returns the result plus a receipt signed by the provider key committing to a hash of the request+response+price; a lightweight verifier lets the paying agent confirm the receipt matches what it received, and a rule (e.g., empty/error output) auto-triggers an x402 refund.

🔧 prototype: Build the wrapping middleware, put one demo MCP tool behind x402, emit signed receipts, and ship a verifier CLI/library that validates a receipt and flags non-delivery — a weekend-to-weeks build on today's x402 + MCP tooling. 🛡 defense: Patent on the payment-bound proof-of-delivery receipt mechanism, plus data/network effects as it becomes the receipt format agents check before trusting a paid tool.

bridges: platform, ai 💰 Pays: Tool/API providers monetizing to agents (they gain a trust badge that lifts conversion), and agent operators/fleets that need spend auditability and automatic refunds on bad calls.

🔪 Kill test: Instrument 10 real agent→paid-tool calls; if agents/providers won't verify or act on receipts (i.e., nobody disputes or the volume of bad calls is negligible), the refund layer has no buyer.

FEAS 8 MOAT 9mo WHITESPACE CLAIM On-device MCP capability-firewall for Android agents 07-13 09:07

💡 Invention: We invent an on-device MCP capability-firewall that mediates every OS-agent call into a third-party Android app through signed, per-invocation, user-consented capability tokens with a tamper-evident local audit ledger.

Problem: Android 17 lets apps expose functions as on-device MCP servers callable by OS-level agents, but there is no app-side mechanism to scope, consent to, revoke, or audit an individual agent's access to those functions — it is all-or-nothing OS trust.

✳ novelty: Issuing a short-lived, capability-scoped, cryptographically attested consent token PER agent invocation (not per app/session OAuth), evaluated by an on-device policy engine, with single-agent revocation and a signed local ledger of every call. 📜 prior art: WHITESPACE. The app-as-MCP-server surface only shipped with Android 17 (signal 839), so almost nothing claims the app side yet. Microsoft's agent-governance toolkit (2257) targets enterprise/cloud agent identity mapped to OWASP Agentic Top 10 — it governs the agent, not the device-local per-invocation consent broker inside the callee app. The exact mechanism (per-call scoped token + on-device consent card + local signed audit) is unclaimed.

🚀 breakthrough: Android 17's new capability for an app to act as an on-device MCP server that OS agents invoke directly instead of driving its UI (signal 839) — this callable surface did not exist before. ⚙ mechanism: An Android SDK wraps the app's MCP tool registration; each incoming agent call hits a local policy check, optionally raises a consent card, then mints a short-lived token scoped to that one tool+arguments class; the call executes only with a valid token; every issuance/denial is appended to a signed on-device ledger; revoking one agent's key kills its authority without touching others.

🔧 prototype: A drop-in Android library plus a sample app exposing 3 MCP tools gated by the broker, a consent UI, per-agent key revocation, and an exportable signed audit log — buildable in weeks against the Android 17 API. 🛡 defense: Patent on the per-invocation scoped-consent-token mechanism for OS-agent-to-app MCP calls, plus speed-to-market as first mover before the Android 17 agent API is widely adopted.

bridges: android, ai 💰 Pays: Android app developers shipping agent-invocable apps (SDK license), and enterprises/regulated app publishers that need per-agent auditability of what OS agents did inside their app.

🔪 Kill test: Ship the SDK to 5 Android agent-app developers; if they will not gate their exposed MCP tools behind a consent/audit layer (or Google bakes an equivalent broker into the platform SDK), it is dead.

FEAS 7 MOAT 4mo COMBINATION INVENTION Cross-Vendor Wrist-Gesture Input Bridge for Third-Party AR Glasses 07-13 09:07

💡 Invention: We invent a phone-hosted bridge that turns an off-the-shelf smartwatch's IMU into a multi-stage in-air gesture controller for cheap third-party AR glasses, exposed as OS-agent-invocable actions.

Problem: Sub-$300 AR display glasses (XREAL) are now mainstream but have no good hands-free input — users are stuck with phone taps or clumsy touchpads — while the wrist-gesture paradigm is being locked up by Meta for its own first-party stack only.

✳ novelty: The non-obvious combination is a consumer smartwatch IMU (not a bespoke EMG band) driving a NON-Meta glasses stack. Meta's patent (6356) covers wrist-detected multi-stage gestures for ITS glasses; the whitespace is the same interaction on commodity watch + commodity third-party glasses, bridged through the phone. 📜 prior art: CROWDED on the interaction concept (Meta is patenting it, 6356) but the claims are device-tied to Meta's own hardware pairing; WHITESPACE for a cross-vendor bridge on existing consumer watches and open glasses — a deliberate design-around, not a head-on collision.

🚀 breakthrough: XREAL's $300 internationally-available AR glasses (3263) making a large installed base of open display glasses exist, combined with Android on-device MCP (839) letting the bridge expose gestures as agent-callable functions. ⚙ mechanism: A lightweight model on the phone reads the watch accelerometer/gyro stream, segments multi-stage gestures (pinch-hold-flick) via a small temporal classifier, maps each to an action, and dispatches it to the glasses' display app — and registers those actions as MCP tools so an OS agent can also invoke them.

🔧 prototype: A solo dev trains a gesture classifier on Apple Watch/Wear OS IMU data for 4 gestures and drives a scrolling HUD on XREAL glasses over BLE, in a single demo app. 🛡 defense: Speed-to-market before Meta's ecosystem ships and a data-moat of labeled cross-device gesture samples; honest that Meta's patent forces a careful design-around and caps the durable moat.

bridges: wearable, android 💰 Pays: AR-glasses app developers and accessory buyers wanting an input method today; prosumer users of budget glasses.

🔪 Kill test: Field-test the gesture classifier across 10 wrists and watch bands — if false-trigger/miss rates make it more annoying than a phone tap, the input paradigm fails on ergonomics alone.

FEAS 8 MOAT 5mo COMBINATION INVENTION Govern-on-Generate: Policy-Baked MCP Server Compiler 07-13 09:07

💡 Invention: We invent a compiler that turns any OpenAPI spec or SQL database into a spec-current MCP server with OWASP-Agentic-Top-10 governance policies (identity, sandboxing, scope-limits) auto-injected at generation time.

Problem: Businesses are racing to wire legacy APIs/DBs to AI agents, but hand-generated MCP servers ship raw — no per-tool auth scoping, no rate/scope guards, and thousands already fail the imminent 2026-07-28 spec — creating both a security gap and a hard-deadline migration crunch.

✳ novelty: Nobody has combined MCP-server GENERATION with governance POLICY at compile time — generators emit bare tool wrappers; governance toolkits are applied by hand afterward, if at all. The novel artifact is a single pass that emits a server already carrying scoped identity, sandbox boundaries, and spec-conformance baked into each tool. 📜 prior art: WHITESPACE at the intersection: swaggertomcp (2208) does generation only; Microsoft's governance toolkit (2257) does policy only as a separate library; the spec-check tool (5781) only audits. Each half is mature and independently shipped, but the compile-time fusion is unclaimed.

🚀 breakthrough: swaggertomcp (2208) proving API/DB-to-MCP generation needs no hand-written server code, plus Microsoft first-partying agent governance (2257) as an off-the-shelf policy set to inject — the two mature halves that just appeared. ⚙ mechanism: Parse the OpenAPI/SQL schema into a tool graph; for each tool, attach a policy record from the governance ruleset (required scope, allowed callers, sandbox class); emit an MCP server that enforces those at request time and self-validates against the target spec version; a diff mode re-runs against existing servers to produce a remediation codemod before the 2026-07-28 deadline.

🔧 prototype: A solo dev wraps swaggertomcp's output with a policy-injection step for ONE governance rule (per-tool scope enforcement) plus a spec-conformance validator, run against 5 public OpenAPI specs. 🛡 defense: Speed-to-market against the hard 2026-07-28 spec deadline plus a growing library of API-shape→policy mappings; first governed-by-default generator sets the reference format.

bridges: ai, dev 💰 Pays: Enterprises and mid-market teams exposing legacy systems to agents who will be asked by security review for governed, spec-current MCP servers; the deadline creates urgent, dated demand.

🔪 Kill test: Generate a governed server from a real messy enterprise OpenAPI spec and have a security engineer find the injected policies are trivially bypassable or break the tools — if governance can't survive one real spec, it's theater.

FEAS 8 MOAT 6mo COMBINATION INVENTION Wearable-to-Endpoint Provenance Bridge for Decentralized Drug Trials 07-13 09:07

💡 Invention: We invent a consumer-wearable data-adjudication layer that converts raw Oura/Apple-Health streams into cryptographically-provenanced, pre-registered clinical efficacy endpoints (CDISC-shaped) a sponsor can file.

Problem: Small biotechs running decentralized/remote trials want drug-efficacy signal from cheap consumer wearables, but consumer devices emit un-validated, un-audited raw streams with no chain-of-custody, firmware pinning, or endpoint definition — unusable as regulatory evidence.

✳ novelty: The non-obvious core is the mismatch of ownership: pharma (Sanofi patent 6357) is claiming efficacy-measurement-via-wearable, while the wearable makers own the data pipeline but never validated it clinically. The invention is the middle layer nobody owns — a pre-registered transform + immutable provenance envelope (device model, firmware version, sampling gaps, timestamp attestation) binding a raw stream to a named endpoint before any data is seen. 📜 prior art: Validated-but-crowded on the CONCEPT (Sanofi is actively filing 6357, so demand is proven and the space is real), but WHITESPACE on the cross-vendor provenance/adjudication layer: incumbents patent their own device+drug pairing, not a device-agnostic evidence bridge.

🚀 breakthrough: Oura Ring 5 (6126) maturing into a stable, continuously-sampling consumer platform with a documented data API — the first time a camera-free, always-on consumer sensor is reliable enough to feed an endpoint pipeline. ⚙ mechanism: Sponsor pre-registers an endpoint spec (e.g. nocturnal HRV delta over 8 weeks) as a signed manifest; the bridge pulls each participant's raw stream via wearable API, records firmware/gap metadata, applies ONLY the manifest transform, hashes input+transform+output into a tamper-evident log, and emits a per-subject endpoint dataset plus an audit trail. No inference about efficacy is made — it is deterministic transformation with provenance.

🔧 prototype: A solo dev builds a single-endpoint pipeline against the Oura API + Apple HealthKit export: manifest parser, deterministic transform runner, and a hash-chained audit log, demoed on one synthetic 30-subject cohort. 🛡 defense: Data-moat + speed: the accumulating library of validated, pre-registered endpoint manifests and firmware-behavior mappings is the asset, plus first-mover format lock-in before a wearable vendor ships its own.

bridges: wearable, ai 💰 Pays: Small/early biotechs and CROs running decentralized trials who cannot afford Medidata-class platforms; digital-biomarker startups needing defensible endpoints.

🔪 Kill test: Show a validated pre-registered endpoint derived from a consumer ring is rejected as evidence by a single CRO/biostatistician for want of device-grade sampling — if it can't clear one real reviewer, the thesis dies.