Patent 10528129

Derivative works

Defensive disclosure: derivative variations of each claim designed to render future incremental improvements obvious or non-novel.

Active provider: Google · gemini-2.5-flash

Derivative works

Defensive disclosure: derivative variations of each claim designed to render future incremental improvements obvious or non-novel.

✓ Generated

Defensive Disclosure: Derivative Variations of US Patent 10,528,129

This defensive disclosure document describes derivative variations of the core inventive concepts found in US Patent 10,528,129, "Immersive displays." The purpose is to provide "prior art" that would render obvious or non-novel future incremental improvements by competitors. The focus is on the mechanism of replacing dynamic content in peripheral areas of an immersive display with static images simulating facial features (like a nose or cheeks) to enhance user experience and reduce motion sickness.

Derivative Variations

1. Material & Component Substitution

Derivative 1.1: Dedicated Micro-LED Sub-Arrays for Static Occlusion

Enabling Description:
Instead of rendering static nose/cheek images on the primary high-resolution display panel, this derivative employs dedicated, ultra-low-power micro-LED sub-arrays. These sub-arrays are physically integrated into the perimeter of the main display unit, corresponding to the physiological occlusion zones for each eye. Each sub-array features a sparse grid of monochromatic (e.g., skin-tone spectrum) micro-LEDs, operating at a refresh rate significantly lower than the primary display (e.g., 1-5 Hz) or even driven in a pulsed mode with low duty cycle to maintain the static visual impression. A dedicated, minimal-logic FPGA or ASIC, separate from the main display controller, directly drives these sub-arrays, receiving static image data (e.g., a bitmap representing a nose contour) once during initialization or user calibration. The sub-arrays are designed with a diffused optical layer to blend the discrete light sources into a continuous, soft-edged simulated occlusion. Power consumption is minimized by only updating the state of the micro-LEDs when the static image itself needs to be changed (e.g., user customization) rather than continuously refreshing dynamic pixels.

graph TD
    A[Main Processor] -- Initial Config --> B[Dedicated Sub-Array Controller (FPGA/ASIC)]
    B -- Static Image Data --> C[Micro-LED Sub-Array (Left Eye)]
    B -- Static Image Data --> D[Micro-LED Sub-Array (Right Eye)]
    E[Primary Immersive Display Controller] -- Dynamic Image Data --> F[Primary Display Panel (Left Eye)]
    E -- Dynamic Image Data --> G[Primary Display Panel (Right Eye)]
    C -- Optical Diffusion --> H[User's Left Eye Field of View]
    D -- Optical Diffusion --> I[User's Right Eye Field of View]
    F -- Perceived Immersion --> H
    G -- Perceived Immersion --> I
    subgraph Immersive Display Device
        B
        C
        D
        E
        F
        G
    end
Derivative 1.2: Electrochromic/Liquid Crystal Occlusion Shutters

Enabling Description:
This derivative utilizes electrochromic (EC) or liquid crystal (LC) shutters positioned between the main display panel and the user's eyes. These shutters are segmented into areas corresponding to the nose and cheek occlusion zones. Each segment is individually addressable. Upon system initialization or user calibration, a low-voltage electrical signal is applied to the specific EC/LC segments to adjust their transparency or light absorption properties. For EC materials, this would involve a voltage-induced redox reaction to transition the material to a specific, static opacity or color (e.g., a skin tone or dark gray). For LC shutters, a voltage would reorient the liquid crystal molecules to block or scatter light, creating a static, non-transmissive area. The state of these segments is maintained by a minimal holding current or capacitance, significantly reducing power consumption compared to continuously rendered pixels. These shutters act as physical, but electronically controllable, occluders that present a static visual element without consuming primary display rendering resources.

graph TD
    A[Main Processor] -- Configuration Signal --> B[Shutter Control Unit]
    B -- Low Voltage Drive --> C{EC/LC Shutter Segment (Left Nose Area)}
    B -- Low Voltage Drive --> D{EC/LC Shutter Segment (Right Nose Area)}
    E[Primary Immersive Display] -- Dynamic Content --> F[User's Field of View]
    C -- Static Occlusion --> F
    D -- Static Occlusion --> F
    subgraph Immersive Display Device
        A
        B
        C
        D
        E
    end

2. Operational Parameter Expansion

Derivative 2.1: Hyper-Resolution Perceptually-Calibrated Static Occlusion with Foveated Rendering

Enabling Description:
This variation integrates the static physiological occlusion into a foveated rendering pipeline operating at extremely high effective resolutions. The static nose/cheek images are not merely low-resolution textures, but are rendered using hyper-resolution, perceptually-calibrated static texture maps (e.g., 3000 DPI equivalent) that meticulously mimic the fine details and subtle variations of human skin or a specified custom texture. Eye-tracking data from internal cameras (e.g., operating at 1000 Hz with sub-degree angular precision) dynamically refines the exact boundaries and subtle shading of this static occlusion. While the static image itself doesn't change content, its definition and interaction with simulated virtual lighting are modulated. For instance, if the user's foveal region momentarily glances towards the edge of the static occlusion, the rendering engine dynamically increases the fidelity of the static texture's anti-aliasing and micro-surface details in that specific region, maintaining a seamless perceived stability without introducing dynamic content into the occluded area. This ensures the "static" reference feels perfectly crisp and integrated with the foveated dynamic content, preventing any jarring transition or blur artifacts at the boundary.

graph TD
    A[Eye Tracking System] -- Gaze Vector & Gaze Point --> B{Foveated Rendering Engine}
    C[Biometric Profile DB] -- Static Texture Maps (Hyper-Res, Calibrated) --> B
    B -- Dynamic Foveal Render --> D[High-Res Display Core]
    B -- Dynamic Peripheral Render --> E[Lower-Res Display Periphery]
    B -- Static Occlusion Layer (Boundary Refinement) --> F[Occlusion Zone Blending Module]
    F -- Static Content Display --> G[Display Output]
    D -- Combined Output --> G
    E -- Combined Output --> G
    subgraph Immersive Display
        A
        B
        C
        D
        E
        F
        G
    end
Derivative 2.2: Adaptive Staticity with Real-Time Environmental Light Sensing

Enabling Description:
This derivative implements an adaptive "static" occlusion where the visual attributes of the simulated nose/cheek are not entirely fixed, but subtly adjust to real-world ambient lighting conditions. The immersive display incorporates an external photodetector array (e.g., a multi-spectral sensor for visible and IR light) and internal eye-safe illuminance sensors. These sensors continuously monitor ambient light intensity, color temperature, and primary light source direction. A real-time rendering adjustment engine then modulates the perceived properties of the static nose/cheek image. For instance, if ambient light dims, the simulated nose might become subtly darker with reduced specular highlights. If a warm light source is detected from the right, the static image might display a subtle, non-changing warm-toned highlight on its right flank and a cooler shadow on its left. This adaptation is not dynamic content from the virtual environment, but a static overlay's properties shifting to maintain perceptual consistency with the user's actual external environment, thereby enhancing the realism of the static reference and reducing the perception of a "flat" static image regardless of external conditions. The "static" image retains its fixed content but its material properties (e.g., albedo, specularity) are modulated.

graph TD
    A[External Photodetector Array] -- Ambient Light Data --> B[Environmental Sensing Unit]
    C[Internal Illuminance Sensors] -- Intra-HMD Light Data --> B
    B -- Real-time Light Params --> D{Adaptive Static Render Engine}
    E[User Biometric Profile] -- Base Static Image Data --> D
    D -- Modulated Static Image --> F[Display Occlusion Areas]
    G[Primary Dynamic Render Pipeline] -- Dynamic Scene --> H[Display Dynamic Areas]
    F -- Blended Output --> I[Combined Display Output]
    H -- Blended Output --> I
    subgraph Immersive Display
        A
        B
        C
        D
        E
        F
        G
        H
        I
    end

3. Cross-Domain Application

Derivative 3.1: Industrial Monitoring VR with Peripheral Static Gauge Clusters

Enabling Description:
In a Virtual Reality (VR) system designed for remote monitoring and maintenance of industrial plants (e.g., a chemical processing facility), the principles of US 10,528,129 are applied to display static, non-interactive "gauge clusters" or warning indicators in the user's peripheral field of view. While the central foveated area of the VR display provides a dynamic 3D walkthrough of the plant with real-time equipment telemetry, the extreme left and right peripheral zones present static, always-visible dials, warning lights (e.g., "Pressure OK," "Temperature Nominal," "Emergency Stop Available") or system health summaries. These peripheral static elements are low-resolution, monochrome bitmaps or simple iconography, designed not to distract from the central task. Their content is "static" in the sense that they only change when a pre-defined threshold is crossed (e.g., a pressure gauge moving from "nominal" to "high"), rather than continuously updating like the central dynamic telemetry. This reduces rendering load on the main engine and provides persistent, glanceable status information without demanding foveal attention.

graph TD
    A[VR Scene Generator (Dynamic)] -- Central View Content --> D[Primary Display Driver]
    B[Static Gauge Data Source (Threshold-based)] -- Peripheral Static Overlay --> C[Peripheral Display Renderer]
    C -- Low-res, Static Render --> D
    D -- Combined Output --> E[Immersive Display Output]
    subgraph Industrial VR System
        A
        B
        C
        D
        E
    end
Derivative 3.2: Surgical AR with Static Anatomical Reference Occlusions

Enabling Description:
In an Augmented Reality (AR) system used for surgical navigation, the concept of a static peripheral reference is applied to display fixed anatomical markers or surgical tool guides. During a pre-operative planning phase, patient-specific 3D anatomical data (e.g., from CT/MRI scans) is registered. In the AR overlay viewed by the surgeon, the central, foveated vision area dynamically renders real-time anatomical structures and instrument positions. However, in the periphery of the display, static 3D anatomical reference points (e.g., a fixed landmark on a bone, or a pre-defined incision line) are rendered as static, transparent overlays. These static overlays remain fixed relative to the perceived patient anatomy, even as the surgeon moves their head or changes their foveal gaze within the dynamic surgical field. The static nature ensures that critical, non-changing reference points are always consistently available in the peripheral awareness, reducing cognitive load and reliance on dynamically re-rendering complex guidance cues in the central, high-resolution view.

graph TD
    A[Real-time Camera Feed (Patient)] --> B[AR Tracking & Registration]
    C[Pre-operative 3D Anatomical Model] --> B
    B -- Registered Patient Pose --> D{AR Rendering Engine}
    E[Dynamic Instrument Tracking] -- Live Tool Position --> D
    F[Static Anatomical Markers Database] -- Fixed Reference Points --> D
    D -- Dynamic Surgical Field --> G[Primary AR Overlay]
    D -- Static Peripheral References --> H[Peripheral AR Overlay]
    G -- Fused View --> I[Surgeon's AR Display]
    H -- Fused View --> I
    subgraph Surgical AR System
        A
        B
        C
        D
        E
        F
        G
        H
        I
    end
Derivative 3.3: Automotive HUD with Static Side-Mirror Indicators

Enabling Description:
For an advanced automotive Head-Up Display (HUD) system, the principles of peripheral static display are utilized. The HUD projects augmented reality information directly onto the windshield, visible to the driver. The central field of view dynamically displays navigation, speed, and real-time collision warnings. In the peripheral regions of the HUD, specifically corresponding to the typical driver's visual expectation of side-view mirrors, static, stylized icons representing the side mirrors are projected. These icons are static images (e.g., simple vehicle outlines) that remain fixed in the driver's perception, regardless of head movement or dynamic environmental changes. If a vehicle enters a blind spot, this static side-mirror icon might change to a specific static warning graphic (e.g., a flashing red car silhouette) without introducing a dynamic video feed into that peripheral region. This provides persistent, stable points of reference for critical external information without increasing the computational load of dynamically rendering complex external camera feeds into the driver's periphery.

graph TD
    A[Vehicle Sensor Data (Speed, Nav, Blind Spot)] --> B{HUD Controller}
    C[Dynamic AR Renderer] -- Central Dynamic Data --> B
    D[Static Icon Generator (Side Mirror, Warnings)] -- Peripheral Static Data --> B
    B -- Projected Image --> E[Windshield Projector]
    E -- Augmented View --> F[Driver's Field of View]
    subgraph Automotive HUD System
        A
        B
        C
        D
        E
        F
    end

4. Integration with Emerging Tech

Derivative 4.1: AI-Driven Personalized Static Occlusion Optimization

Enabling Description:
This derivative employs an AI/Machine Learning (ML) model to dynamically optimize the attributes (e.g., shape, size, skin tone, translucency, perceived texture) of the static nose/cheek images for each individual user, maximizing comfort and immersion while minimizing motion sickness. The system utilizes internal eye-tracking cameras (for gaze stability and pupil dilation), internal facial cameras (for biometric facial feature mapping), and biofeedback sensors (e.g., galvanic skin response, heart rate variability from an integrated wearable) to collect continuous user experience data. The AI/ML model (e.g., a deep reinforcement learning agent) is trained on a large dataset of user preferences and physiological responses to various static occlusion configurations. In real-time, the model processes the live user biometric and comfort data to infer the optimal static occlusion parameters. For example, if eye-tracking data indicates slight discomfort or repeated brief glances at the occlusion boundary, the AI might subtly adjust its translucency or softness. Initial personalization involves the user interacting with a calibration routine where they provide subjective feedback while the AI explores a parameter space of static nose/cheek representations. This creates a hyper-personalized static reference tailored to the user's unique perception and physiology.

graph TD
    A[Internal Eye-Tracking] -- Gaze Data --> B{AI/ML Optimization Engine}
    C[Internal Facial Camera] -- Facial Biometrics --> B
    D[Biofeedback Sensors] -- Comfort Metrics --> B
    E[User Subjective Feedback] -- Training Data --> B
    B -- Optimized Static Parameters --> F[Static Image Renderer]
    F -- Static Occlusion Layer --> G[Immersive Display]
    subgraph AI-Optimized Immersive Display
        A
        B
        C
        D
        E
        F
        G
    end
Derivative 4.2: IoT-Driven Environmental Adaptation of Static Occlusion

Enabling Description:
This derivative integrates the immersive display with a network of external Internet of Things (IoT) environmental sensors to dynamically adapt the material properties of the static nose/cheek images. These IoT sensors (e.g., ambient light, temperature, humidity, particulate matter concentration) are deployed in the user's physical surroundings. They transmit real-time environmental data to a central IoT hub, which then relays relevant parameters to the immersive display's processing unit. The display's rendering pipeline then adjusts the perceived surface properties of the static nose/cheek images to reflect these real-world conditions. For instance, if the IoT sensors report high humidity, the static nose image might develop a subtle, static "condensation" effect or a slightly more reflective sheen. If ambient temperature drops significantly, the simulated skin tone might shift marginally to appear slightly paler or with reduced blood flow texture. This ensures that even the static, artificial occlusion visually conforms to the current physical environment, deepening the sense of realism and reducing cognitive dissonance. The "static" content remains unchanged, but its simulated interaction with the user's real environment is dynamically adapted.

graph TD
    A[Environmental IoT Sensors] -- Real-time Data --> B[IoT Hub]
    B -- Environmental Params --> C{Static Image Adaptation Module}
    D[Base Static Image Data] --> C
    C -- Adjusted Material Properties --> E[Static Image Renderer]
    E -- Static Occlusion Layer --> F[Immersive Display]
    subgraph IoT-Integrated Immersive Display
        A
        B
        C
        D
        E
        F
    end
Derivative 4.3: Blockchain-Verified Custom Static Occlusion Profiles

Enabling Description:
This derivative utilizes a blockchain network to securely store and verify user-customized static occlusion profiles. When a user creates a personalized static nose/cheek image (e.g., adjusting size, shape, skin tone, or selecting from a pre-defined library), this profile data is cryptographically hashed and recorded as a transaction on a private or consortium blockchain. Each user has a unique wallet address linked to their personalized profiles. When the user switches to a different immersive display device or logs into a new VR application, the device or application can query the blockchain to retrieve the user's verified static occlusion profile. This ensures consistency and security of personalized comfort settings across disparate hardware and software platforms. The blockchain record ensures the integrity and authenticity of the user's chosen static reference, preventing unauthorized alteration and facilitating seamless migration of personalized immersive experiences.

sequenceDiagram
    participant U as User
    participant HMD as Immersive Display
    participant APP as VR/AR Application
    participant BC as Blockchain Network
    U->HMD: Customize Static Occlusion (e.g., nose)
    HMD->APP: Send Customization Data
    APP->BC: Hash & Record Profile (Transaction)
    BC-->APP: Transaction Confirmation
    U->APP: Login/Launch App (New Device)
    APP->BC: Query User Profile
    BC-->APP: Verified Profile Data (Hash)
    APP->HMD: Apply Static Occlusion Profile
    HMD->HMD: Display Personalized Static Occlusion

5. The "Inverse" or Failure Mode

Derivative 5.1: Critical System Failure - Safe Degradation to Monochrome Static Occlusion

Enabling Description:
In the event of a critical system failure (e.g., GPU overheating, primary power supply degradation, or core rendering pipeline error) within the immersive display, the system automatically initiates a "safe degradation mode." In this mode, all dynamic virtual environment rendering is immediately halted or greatly simplified (e.g., to a low-refresh rate wireframe). Concurrently, the display controller shifts to a minimal, redundant power circuit to maintain only the static nose/cheek occlusion images, along with a critical system status overlay (e.g., "SYSTEM FAULT - EXIT VR"). The static nose/cheek images revert to a pre-defined, monochrome (e.g., gray-scale) low-resolution bitmap, driven at a very low refresh rate (e.g., <1 Hz) or held in a static state, to provide the essential stable reference necessary to prevent acute motion sickness or disorientation during system shutdown or troubleshooting. This prioritized rendering ensures user safety and comfort by preserving the most critical non-dynamic visual cue until the user can safely disengage from the immersive environment.

stateDiagram
    [*] --> Normal_Operation
    Normal_Operation --> Critical_System_Failure : GPU Overheat | Power Loss | Render Error
    Critical_System_Failure --> Safe_Degradation_Mode : Activate Redundant Power | Halt Dynamic Render
    Safe_Degradation_Mode --> Display_Monochrome_Static_Occlusion : Prioritize Static Reference
    Safe_Degradation_Mode --> Display_Critical_Status_Overlay : Alert User
    Display_Monochrome_Static_Occlusion --> User_Exits_VR
    Display_Critical_Status_Overlay --> User_Exits_VR
    User_Exits_VR --> [*]
Derivative 5.2: Low-Power Mode - Asymmetric Occlusion Reduction

Enabling Description:
When the immersive display detects a low-power condition (e.g., battery below 15% charge) or is explicitly commanded into a "power-saving mode," it implements an asymmetric occlusion reduction strategy. In this mode, the static nose/cheek image for one eye (e.g., the non-dominant eye, or a user-configurable preference) is entirely disabled or replaced with a simple black mask, effectively ceasing rendering/driving for that peripheral region. The static nose/cheek image for the other eye is maintained, potentially at a reduced resolution or refresh rate (e.g., 5 Hz), continuing to provide at least a monocular static reference. This significantly reduces the computational and display power required for the peripheral static elements, extending operational time, while still offering some level of motion sickness mitigation by preserving a stable physiological reference for one eye.

graph TD
    A[Power Management Unit] -- Low Power Signal --> B{Occlusion Management Module}
    B -- Normal Mode (Default) --> C[Render Static Occlusion (Left Eye)]
    B -- Normal Mode (Default) --> D[Render Static Occlusion (Right Eye)]
    B -- Low Power Mode --> E[Disable Static Occlusion (Left Eye)]
    B -- Low Power Mode --> F[Render Static Occlusion (Right Eye, Reduced)]
    C -- Output --> G[Left Display Peripheral]
    D -- Output --> H[Right Display Peripheral]
    E -- Output --> G
    F -- Output --> H
    subgraph Immersive Display
        A
        B
        C
        D
        E
        F
        G
        H
    end

Combination Prior Art Scenarios

These scenarios combine the inventive concepts of US Patent 10,528,129 with existing open-source standards, demonstrating how the patent's teachings could be implemented within or extended by these standards, thereby serving as prior art for future developments.

  1. US 10,528,129 + OpenXR Standard for Physiological Occlusion Layers:
    An extension to the OpenXR API, named XR_VARJO_static_physiological_occlusion (or similar), would define a new type of XrCompositionLayer specifically for rendering static physiological occlusions (like nose or cheek elements). This layer would allow VR/AR application developers to submit static texture assets (e.g., XrSwapchainImage for a single frame) and specify their desired position and blending attributes relative to the user's view, corresponding to the "first area" and "second area" as defined in claim 1. The OpenXR runtime, in conjunction with the device's main processor, would be responsible for "providing adjusted information by removing part of the information to replace first information from a first area of the first images with a first static image...". This integration within a widely adopted open standard would make the method of US 10,528,129 readily available and implementable by a broad developer community, thus constituting clear prior art for any subsequent efforts to implement similar static physiological occlusions in an OpenXR environment.

  2. US 10,528,129 + Vulkan Graphics API for Optimized Fixed-Function Occlusion Pipeline:
    A specialized rendering pipeline within a Vulkan-based graphics engine (e.g., VK_KHR_fixed_viewport_occlusion extension, or a similar vendor-specific extension) would define a mechanism to declare and manage static "occlusion meshes" or "static texture quads" that correspond to the user's nose and cheek regions. These occlusion meshes would be rendered once with a static texture (e.g., a skin-tone bitmap or transparent black) into specific, pre-defined regions of the framebuffer before the main dynamic scene rendering pass. The Vulkan pipeline would then implement "early-Z" culling or a scissor test to prevent any subsequent dynamic scene pixels from being rendered into these static occlusion regions, thereby "removing part of the information" as described in claim 1 and "reducing processing requirements, memory requirements, and bandwidth utilized." This would demonstrate the application of US 10,528,129's resource optimization and static replacement using a low-level, high-performance graphics API.

  3. US 10,528,129 + WebXR Device API for Browser-Based User-Configurable Static Reference:
    The WebXR Device API could incorporate a feature (e.g., a XRSystem.requestStaticReferenceSpace() method or a specialized XRLayer property) that allows web-based VR/AR applications to request and configure a persistent, non-interactive visual element corresponding to a user's physiological features. This feature would expose parameters for setting the shape, color, opacity, and relative_position of the "first static image" and "second static image" (e.g., a simulated nose or cheek). The WebXR user agent (browser) would then handle the rendering of this static element as a fixed overlay within the immersive session, ensuring it remains stable while the dynamic WebXR content changes. This provides a user-configurable, browser-native implementation of the static occlusion, demonstrating the core inventive step of US 10,528,129 in a ubiquitous web environment.

Generated 6/19/2026, 6:04:07 AM