Search

US-12626424-B1 - Trusted reality compositor (TRC): OS-level per-frame, fail-closed, receipt-gated rendering, labeling, and egress gating for AR/VR/camera overlays

US12626424B1US 12626424 B1US12626424 B1US 12626424B1US-12626424-B1

Abstract

Systems and methods for receipt-gated, fail-closed rendering and egress of synthetic overlays in AR/VR/camera pipelines. An OS-resident reality compositor admits an overlay only when a per-overlay Reality Receipt (R2) verifies, within the frame budget, to a current signed head of an append-only public log under a freshness policy, using an inclusion proof and, on head advance, append-only evolution (consistency); an anti-replay tuple prevents reuse. A view-permit latch binds time-of-check/time-of-use (TOCTOU) verify-to-pixels and returns a Structured Precondition-Failure (code) while dropping non-conformant draws; PASS draws are labeled in machine-readable (optionally machine-audible) form. The same predicates govern rendering and at least one of share, upload, record/capture, or clipboard. An attested boundary (TEE/secure element) may aggregate a device run-permit across apps. The system emits view and interaction receipts and a digitally signed certification result that commits to receipt and signed-head identifiers, enabling portable evidence for policy consumers and audit systems.

Inventors

  • Yong Bok Lee

Assignees

  • Yong Bok Lee

Dates

Publication Date
20260512
Application Date
20251015

Claims (20)

  1. 1 . A computer-implemented system comprising one or more processors and a non-transitory memory storing instructions that, when executed by the one or more processors, cause the system to: (a) include a system-level compositor pipeline, the system-level compositor pipeline comprising a reality compositor configured to merge a sensor or liveness layer with at least one synthetic overlay for presentation on a render surface; (b) execute, in a compositor render path of the system-level compositor pipeline and before scan-out, a receipt verifier comprising receipt-verification logic that is executed by the one or more processors and configured to validate, within a frame budget and under a freshness policy, a Reality Receipt (R2) associated with the synthetic overlay, the R2 comprising at least: (i) an overlay identifier; (ii) an origin signature; (iii) a scene digest; (iv) one or more policy predicates including geographic fences, jurisdictional fences, and safety budgets; and (v) an inclusion proof for the R2 or for a commitment derived from the R2 relative to a current signed head of an append-only public log and, responsive to head advance under the freshness policy, a consistency proof demonstrating append-only evolution of the append-only public log; and (c) enforce, in the compositor render path and before scan-out, a view-permit latch that is coupled to the reality compositor and comprises compositor-resident gating logic that determines whether the synthetic overlay is eligible to be rendered based on an outcome of the validation in (b), the view-permit latch being configured to: (i) refuse rendering of the synthetic overlay and return a Structured Precondition-Failure code when the validation in (b) fails any requirement; and (ii) inject a machine-readable label onto the render surface when the validation in (b) succeeds.
  2. 2 . The system of claim 1 , deployed on a device comprising a trusted execution environment (TEE) or secure element and further comprising a run-permit latch coupled to a graphics control path, the system configured to: aggregate per-application predicate results; enforce fail-closed behavior within a frame budget upon violation; re-arm upon satisfaction; and emit allow and deny evidence records including a hardware-secured signature, a scene digest, a fail-close time, and a re-arm time.
  3. 3 . The system of claim 1 , wherein the R2 further references a Right-of-Publicity Consent Token (RPCT) for a face, voice, or likeness present in the overlay, and the view-permit latch refuses rendering when the RPCT is missing or expired.
  4. 4 . The system of claim 1 , wherein the receipt verifier validates freshness to a signed head obtained within a maximum-merge-delay (MMD) window and, responsive to observing a newer head, validates a prior-to-current consistency proof demonstrating append-only evolution of the append-only public log between the prior signed head and the newer signed head.
  5. 5 . The system of claim 1 , wherein the receipt verifier verifies an anti-replay tuple comprising a nonce, a monotonic counter, a device profile identifier, a policy epoch, and the scene digest, and refuses reuse of the anti-replay tuple.
  6. 6 . The system of claim 1 , wherein the scene digest comprises at least one of camera pose, a depth map, a feature map, or a camera-pipeline timecode computed at capture time.
  7. 7 . The system of claim 1 , wherein a Kids device profile enforces age policies and ad-frequency caps and the view-permit latch denies overlays that exceed the cap with a KIDS_POLICY code.
  8. 8 . The system of claim 1 , wherein a Critical device profile denies overlays not whitelisted for driver or medical contexts and emits a DRIVER_DISTRACTION code on violation.
  9. 9 . The system of claim 1 , wherein the receipt verifier denies overlays that violate geographic/jurisdictional fences with a deny code selected from GEOFENCE_FAIL or JURIS_FAIL.
  10. 10 . The system of claim 1 , wherein the presentation pipeline includes at least one of: (i) layer admission or submit; (ii) scene-graph commit; (iii) present scheduling with a token-bound present fence; (iv) overlay-plane promotion in a display engine; (v) hardware composition or atomic present; (vi) egress duplication for cast/mirror/remote composition paths; or (vii) snapshot/export paths including Record/Capture and Clipboard/Drag-Drop, provided gating occurs before scan-out or subscriber visibility.
  11. 11 . The system of claim 1 , wherein the reality compositor further gates audio and haptic overlays in synchrony with visual overlays and injects a machine-audible label corresponding to PASS, HOLD, FAIL, or STALE.
  12. 12 . The system of claim 1 , wherein the receipt verifier validates an offline Short-Receipt and defers Share or Upload until freshness is obtained; stale receipts are denied, and Short-Receipt renders carry a watermark corresponding to a HOLD label state until PASS.
  13. 13 . The system of claim 1 , wherein the compositor binds verify-to-pixels by associating the validation outcome with a frame token, and any change in layers, surfaces, or presentation mode that would display pixels not covered by the verified token forces FAIL or HOLD and drops the overlay enforce time-of-check-to-time-of-use (TOCTOU) binding.
  14. 14 . The system of claim 1 , wherein for screen casting, mirroring, or remote composition, the view-permit latch is enforced at an egress path, and overlays without a bound, fresh frame token associated with the validation outcome are masked or dropped.
  15. 15 . The system of claim 1 , wherein the latch is implemented in a display-engine overlay-plane controller or guarded by a system memory management unit (MMU), or both, and attempts to bypass the compositor plane are denied within the frame budget.
  16. 16 . The system of claim 1 , wherein the system emits allow and deny evidence records that include fields comprising label_state, receipt_id, scene_digest, fail_close_time, rearm_time, and code, each signed with a hardware-secured key and posted to a transparency-style log.
  17. 17 . The system of claim 1 , wherein a verifier timeout is treated as a Structured Precondition-Failure code with TIME_BUDGET_EXCEEDED, and the overlay is dropped within the frame budget.
  18. 18 . The system of claim 1 , wherein the R2 further comprises model_id, model_version, prompt_hash, and a safety_verdict for overlays produced by a generative model, and the view-permit latch returns a deny code selected from MODEL_UNATTESTED and PROMPT_UNBOUND upon validation failure.
  19. 19 . A computer-implemented method comprising: receiving an overlay intent; validating, within a frame budget and under a freshness policy, a Reality Receipt (R2) associated with the overlay; when validation succeeds, rendering the overlay and injecting a machine-readable label; when validation fails, dropping the overlay and returning a Structured Precondition-Failure code; and emitting View Receipts for renders and Interaction Receipts for user actions associated with the overlay.
  20. 20 . The method of claim 19 , further comprising applying the same predicates at Render and at least one of Share, Upload, Record/Capture, or Clipboard/Drag-Drop and returning a Structured Precondition-Failure code on violation.

Description

Non-Trademark Notice. “Trusted Reality Compositor” and “TRC” are technical labels/abbreviations for convenience only; no trademark rights are asserted. Applicant may commercialize the technology under different brand names. The scope of the invention is defined solely by the claims. Equivalents (illustrative; non-limiting). References to particular transports, logs, proof systems, display stacks, or operating systems are illustrative. A “provenance anchor verifiable under a freshness policy” includes, without limitation, transparency-style logs and certificate-transparency signed heads, attested ledgers, certificate chains, quorum attest services, authenticated append-only structures, or vector-commitment/accumulator systems that provide substantially similar freshness and append-only evolution (consistency) semantics. Mention of external policies, regulations, or standards is not an admission that any is prior art. CROSS-REFERENCE TO RELATED APPLICATIONS Priority and incorporation. This application claims the benefit of U.S. Provisional Application No. 63/876,985 (filed Sep. 6, 2025) under 35 U.S.C. § 119 (c). The disclosure of the provisional application is incorporated by reference for non-essential subject matter only to the extent permitted by 37 C.F.R. § 1.57. In the event of any inconsistency, the present disclosure controls; all essential material supporting the claims is provided herein. Cross-reference (illustrative; non-limiting). TRC is interoperable with the PoPC rail (Receipt-Anchored Policy-Compliant Execution and Outcome-Based Ranking), which emits verifiable receipts and verification/settlement artifacts that TRC may consume at compositor gatepoints. Interoperability includes, illustratively, sensor ingress (TSIL), model-load admission (AML-Gate), verify-then-write model memory (UPL), and settlement rails (ISL). These cross-references are evidentiary only and are not incorporated by reference; the claims control. Independence (illustrative; non-limiting). Interoperability with external rails (e.g., PoPC) is optional; TRC operates without any specific receipt format so long as receipt semantics are satisfied. Standards and references (non-limiting). References to public specifications or standards (e.g., WebAuthn/passkeys, certificate-transparency signed heads, RFC 8785 JSON canonicalization (JCS), RFC 8949 deterministic CBOR, JSON Schema, post-quantum signature suites) are illustrative and used for terminology and interoperability only; adherence is not required unless expressly claimed. Appendices as part of the specification. Appendices A-L are submitted as part of this specification and form an integral portion of the written description. The appendices provide normative schemas and protocols, representative APIs, definitions, mapping ledgers, conformance tests, ethical-use guidance, and security considerations and optional hardening profiles. These materials are illustrative and non-limiting; the claims control. Appendix map (illustrative; non-limiting). Appendix A (definitions), B (schemas/APIs), C (claims-to-figs mapping), D (protocols), E (transcripts/certificates), F (conformance), G (store/policy template), H (reference builds), I (deny codes), J (R2 v1.1 extensions), K (ethical-use covenant), and L (transparency report). Equivalents & non-limiting posture. Functionally equivalent schemas, transports, cryptographic suites, log structures, and proof systems that provide comparable attestation, append-only verifiability, and freshness enforcement are within scope. Examples are illustrative; unless expressly claimed, no particular standard is required. Policy context & NPL (illustrative; non-limiting). Evolving safety frameworks (e.g., the International Scientific Report on the Safety of Advanced AI, 2025, and state-level measures such as New York's RAISE Act) motivate auditable controls, incident reporting, and verifiable safeguards. Such non-patent literature is cited solely as background context and is not incorporated by reference and does not limit the claims. FIELD OF THE INVENTION Field. This disclosure relates to computer-graphics composition and safety for AR/VR/camera systems. In particular, it addresses how an operating-system compositor decides whether to render synthetic overlays and how that decision is made auditable. Particular focus (illustrative; non-limiting). The invention concerns an OS-level compositor gate that refuses to render a synthetic overlay unless the overlay is accompanied by verifiable evidence (a “Reality Receipt,” R2) that satisfies defined policy predicates (e.g., freshness, anti-replay, geo/jurisdiction fences, safety budgets). When predicates are satisfied, the system injects a machine-readable label; when predicates are not satisfied, the overlay is dropped and a Structured Precondition-Failure (code) is returned. Where human likeness or voice is present, deployments MAY require consent artifacts (e.g., Right-of-Publicity Consent Tokens, RPCT). (