Sensor locking features for mixed reality

Abstract

The invention relates to a sensor locking feature for a mixed reality head-mounted device. Embodiments include detecting, using a trusted software module of a head-mounted device, a user presence event when the head-mounted device is in a sensor lock enabled state. Embodiments include transitioning, using the trusted software module of the head-mounted device, the head-mounted device from the sensor lock enabled state to a sensor lock disabled state, the transitioning including providing power to a privacy sensitive sensor of the head-mounted device and powering up an indicator light of the head-mounted device. Embodiments include transitioning, using the trusted software module of the head-mounted device, the head-mounted device from the sensor-lock-disabled state to the sensor-lock-enabled state, the transitioning including removing power from the privacy-sensitive sensor of the head-mounted device and powering off the indicator light of the head-mounted device.

Description

[0001] Cross-references to related applications

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 698,449, filed September 24, 2024, and U.S. Non-Provisional Patent Application No. 19 / 318,056, filed September 3, 2025, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This disclosure generally relates to mixed reality headsets, and more specifically to sensor locking features for mixed reality headsets. Background Technology

[0004] As used herein, the term "mixed reality" or "MR" refers to a form of reality that has been adjusted in some way before being presented to a user. This form of reality can include, for example, virtual reality (VR), augmented reality (AR), extended reality (XR), mixed reality, or some combination and / or derivative thereof. Mixed reality content can include fully generated content or generated content combined with captured content (e.g., real-world photographs). Mixed reality content can include video, audio, haptic feedback, or some combination thereof, any one of which can be presented in a single channel or multiple channels (e.g., stereoscopic video that produces a three-dimensional (3D) effect for the viewer). Furthermore, in some embodiments, mixed reality can be associated with an application, product, accessory, service, or some combination thereof, for example, for interacting with content in an immersive application. Mixed reality systems that deliver mixed reality content can be implemented on a variety of platforms, including head-mounted displays (HMDs) connected to servers, host computer systems, standalone HMDs, mobile devices or computing systems, "cave" environments or other projection systems, or any other hardware platform capable of delivering mixed reality content to one or more viewers. Mixed reality may be equivalently referred to as "artificial reality" in this document.

[0005] As used herein, “virtual reality” or “VR” refers to an immersive experience in which the user’s visual input is controlled by a computing system. As used herein, “augmented reality” or “AR” refers to a system in which the user views images of the real world after they have passed through a computer system. For example, a tablet computer with a camera on its back can capture multiple images of the real world, which can then be displayed on a screen on the side of the tablet opposite the camera. The tablet computer can process and adjust or “enhance” these images as they pass through the system, for example, by adding virtual objects. AR also refers to a system in which light entering the user’s eyes is partly generated by a computing system and partly constitutes light reflected from objects in the real world. For example, an AR headset can be shaped as glasses with a pass-through display, which allows light from the real world to pass through a waveguide that simultaneously emits light from a projector in the AR headset, allowing the AR headset to present virtual objects blended with the real objects visible to the user. AR headsets can be light-blocking headsets with video pass-through capabilities. As used herein, “mixed reality” or “MR” means VR, AR, XR, or any combination or hybrid thereof. Summary of the Invention

[0006] Some embodiments of this disclosure provide a computer-implemented method for sensor lock-up features of a mixed reality head-mounted device. The method includes: when the head-mounted device is in a sensor lock-engaged state, detecting a user presence event using a trusted software module of the head-mounted device; using the trusted software module of the head-mounted device to transition the head-mounted device from the sensor lock-engaged state to a sensor lock disengaged state, the transition including providing power to a privacy-sensitive sensor of the head-mounted device and powering on an indicator light of the head-mounted device; and using the trusted software module of the head-mounted device to transition the head-mounted device from the sensor lock disengaged state to the sensor lock enabled state, the transition including removing power from the privacy-sensitive sensor of the head-mounted device and powering off the indicator light of the head-mounted device. Therefore, the embodiments provide a sensor lock-up feature for a mixed reality head-mounted device.

[0007] In another embodiment, the user presence event includes a head-mounted device wearing detection event detected using a sensor in the head-mounted device that is designated as not a privacy-sensitive sensor. Therefore, the embodiments provide further details regarding user presence events.

[0008] In another embodiment, the user presence event includes pressing a button on the head-mounted device. Therefore, the embodiments provide further details regarding user presence events.

[0009] In another embodiment, the user presence event includes a signed power-on message from a core processing unit communicatively coupled to the head-mounted device, the signed power-on message being generated by a trusted software module of the core processing unit in response to detecting a press of the core processing unit's power button. Therefore, the embodiments provide further details regarding user presence events when the head-mounted device is used with the core processing unit.

[0010] In another embodiment, in response to receiving a signed power status message from the core processing unit, the head-mounted device is switched from the sensor lock disabled state to the sensor lock enabled state. Therefore, the embodiments provide further details regarding the use of a head-mounted device with a core processing unit.

[0011] In another embodiment, the core processing unit is communicatively coupled to the head-mounted device via a removable tether. Therefore, the embodiments provide further details regarding the use of a head-mounted device with a core processing unit.

[0012] In another embodiment, the core processing unit is communicatively coupled to the head-mounted device via a wireless communication link. Therefore, the embodiments provide further details regarding the use of a head-mounted device with a core processing unit.

[0013] In another embodiment, in response to a removal detection event, the head-mounted device is switched from the sensor lock disabled state to the sensor lock enabled state. Therefore, the embodiments provide further details regarding the switch to the sensor lock enabled state.

[0014] Some embodiments of this disclosure provide a non-transitory computer-readable medium for storing a program for sensor-locking features of a mixed reality head-mounted device. When executed by a computer, the program configures the computer to: detect a user presence event using a trusted software module of the head-mounted device when the head-mounted device is in a sensor-locking enabled state; transition the head-mounted device from the sensor-locking enabled state to a sensor-locking disabled state using the trusted software module of the head-mounted device, the transition including providing power to a privacy-sensitive sensor of the head-mounted device and powering on an indicator light of the head-mounted device; and transition the head-mounted device from the sensor-locking disabled state to the sensor-locking enabled state using the trusted software module of the head-mounted device, the transition including removing power from the privacy-sensitive sensor of the head-mounted device and powering off the indicator light of the head-mounted device.

[0015] Some embodiments of this disclosure provide a system for sensor-locking features of a mixed reality head-mounted device. The system includes a processor and a non-transitory computer-readable medium storing a set of instructions that, when executed by the processor, configure the processor to: when the head-mounted device is in a sensor-lock enabled state, detect a user presence event using a trusted software module of the head-mounted device; transition the head-mounted device from the sensor-lock enabled state to a sensor-lock disabled state using the trusted software module of the head-mounted device, the transition including providing power to a privacy-sensitive sensor of the head-mounted device and powering on an indicator light of the head-mounted device; and transition the head-mounted device from the sensor-lock disabled state to the sensor-lock enabled state using the trusted software module of the head-mounted device, the transition including removing power from the privacy-sensitive sensor of the head-mounted device and powering off the indicator light of the head-mounted device. Attached Figure Description

[0016] The accompanying drawings, which are included to provide further understanding and are incorporated in and constitute a part of this specification, illustrate the disclosed embodiments and, together with the specification, serve to explain the principles of the disclosed embodiments.

[0017] Figure 1 A network architecture for implementing sensor locking features for mixed reality head-mounted devices, according to some embodiments, is shown.

[0018] Figure 2 A block diagram illustrating details of a system for sensor locking features for a mixed reality head-mounted device according to some embodiments.

[0019] Figure 3An illustration depicts an example configuration of a mixed reality headset used in a sensor-locking feature for a mixed reality headset according to some embodiments.

[0020] Figure 4 A block diagram depicts an example configuration of sensor locking features for a mixed reality head-mounted device according to an illustrative embodiment.

[0021] Figure 5 An example state of a sensor locking feature for a mixed reality head-mounted device, according to an illustrative embodiment, is depicted.

[0022] Figure 6 An example state of a sensor locking feature for a mixed reality head-mounted device, according to an illustrative embodiment, is depicted.

[0023] Figure 7 A flowchart depicts an example process for sensor locking features for a mixed reality head-mounted device according to an illustrative embodiment.

[0024] Figure 8 An example state of a sensor locking feature for a mixed reality head-mounted device, according to an illustrative embodiment, is depicted.

[0025] Figure 9 An example configuration of a software module for implementing a sensor locking feature for a mixed reality head-mounted device, according to an illustrative embodiment, is described.

[0026] Figure 10 A flowchart depicts another example process for sensor locking features for a mixed reality head-mounted device, according to an illustrative embodiment.

[0027] In one or more embodiments, not all components depicted in each figure may be required, and one or more embodiments may include additional components not shown in the figures. Variations may be made in the arrangement and type of the components without departing from the scope of this subject matter disclosure. Within the scope of this subject matter disclosure, additional components, different components, or fewer components may be utilized. Detailed Implementation

[0028] Numerous specific details are set forth in the following detailed description to provide a thorough understanding of this disclosure. However, it will be apparent to those skilled in the art that embodiments of this disclosure may be practiced without these specific details. In other instances, well-known structures and techniques have not been shown in detail so as not to obscure this disclosure.

[0029] MR headsets typically include multiple sensors. MR headset users typically enable one or more sensors manually (e.g., by selecting sensors via a user interface) or automatically (e.g., when the user puts on or wears the headset). MR headset users typically disable one or more sensors manually (e.g., by selecting sensors via a user interface) or automatically (e.g., when the user takes off or removes the headset). Sensors can potentially be enabled without the user's knowledge or consent (e.g., via malware or accidental triggering of one or more sensors used to determine user proximity), which is a poor user experience. Therefore, a sensor locking feature is needed that cuts off power to one or more headset sensors, so that these de-powered sensors will never operate when the user does not expect them to be powered on, such as when the headset is not in use.

[0030] The embodiments of this disclosure address the aforementioned problems by implementing sensor locking features for mixed reality head-mounted devices. Specifically, in the embodiments: when the head-mounted device is in a sensor lock enabled state, a trusted software module of the head-mounted device detects a user presence event; the trusted software module of the head-mounted device transitions the head-mounted device from a sensor lock enabled state to a sensor lock disabled state, the transition including providing power to the privacy-sensitive sensors of the head-mounted device and powering on the indicator lights of the head-mounted device; and the trusted software module of the head-mounted device transitions the head-mounted device from a sensor lock disabled state to a sensor lock enabled state, the transition including removing power from the privacy-sensitive sensors of the head-mounted device and powering off the indicator lights of the head-mounted device.

[0031] Some MR headset implementations include a head-mounted device (HMD) and a separate core processing unit. The HMD and core processing unit are communicatively coupled via a detachable or non-detachable wired connection (also known as a cable) or via a wireless connection. Other MR headset implementations include only an HMD. The HMD typically includes one or more privacy-sensitive sensors, i.e., sensors that can be used to protect user privacy. Some non-limiting examples of sensors designated as privacy-sensitive sensors are color or monochrome cameras, microphones, and ultrasonic sensors. Some non-limiting examples of sensors or sensor systems designated as not privacy-sensitive sensors include: scintillation sensors; sensors for measuring the interpupillary distance (IPD—the distance between the centers of the pupils of the eyes in millimeters); sensors for performing inter-axis adjustments of a head-mounted device (HMD) to achieve visual clarity and comfort during use; capacitive sensing sensors; simultaneous localization and mapping (SLAM) inertial measurement units (IMUs); display IMUs; hinge or arm position sensors (for determining whether the arms of the HMD are open or closed); proximity sensors (for determining the distance from the HMD to the user); eye-tracking cameras; or other sensors. Capacitive sensing refers to a technique that measures changes in the sensing capacitance of one or more electrodes to detect significant changes in capacitance, which are used as input signals to determine whether a human is near (e.g., touching) a device server to help determine whether the user is currently wearing the device. SLAM allows head-mounted devices to create real-time tracking and mapping of objects in virtual space. This helps track the head-mounted device's position in six degrees of freedom (3D position and 3D rotation) and allows for the creation of spatial maps of boundaries so users will know when they are approaching a wall or object. An IMU (Inertial Measurement Unit) is an electronic sensor package that measures motion and orientation. When a user moves their head in all principal directions (e.g., when the user turns their head, tilts their head, or nods), the IMU allows for the measurement of the head-mounted device's linear acceleration and rotational speed. This data can then be used as one of the user's detection components. This data is also useful when tracking objects or boundaries, as it adds to the tracking data for the head-mounted device's position. A display IMU is a specialized inertial measurement unit that is mounted directly on the display or optical module. The display IMU is mounted on a movable module and tracks the module's motion relative to the head-mounted device. The main head-mounted device IMU can be used for SLAM tracking and attitude prediction, while the display IMU can be used for display calibration and parallax correction. This helps increase the sharpness between the left and right displays of the head-mounted device.These corrections are designed to prevent eye strain and reduce motion sickness in users.

[0032] MR headsets typically include an on / off switch or power button and one or more electronic components (e.g., a processor or a light projector (e.g., an LED)). If used, a core processing unit typically also includes an on / off switch or power button and one or more electronic components (e.g., a processor or a light projector (e.g., an LED)). Some HMD implementations used with the core processing unit do not have their own power on / off control, but instead have physical volume up / down controls.

[0033] In some MR headset implementations that include an HMD and a separate core processing unit, the software in the HMD is considered trusted, while the software in the core processing unit is implemented in two parts (trusted and untrusted parts). In some MR headset implementations that include only an HMD, all HMD software is considered trusted. In some MR headset implementations that include only an HMD, the software in the HMD is implemented in both trusted and untrusted parts.

[0034] In some embodiments, a user can put the HMD into a low power state (e.g., standby / sleep) by briefly pressing the HMD's power button, or the HMD will enter a low power state if the device is inactive. Once the HMD enters a low power state, the sensors are turned off, and indicator lights (e.g., privacy LEDs) are turned off, thereby notifying the user that the device sensors (including one or more privacy-sensitive sensors) are inactive.

[0035] Some embodiments of MR headsets have multiple wake-up sources that, when triggered, bring the device out of a low-power state. This trigger wakes the HMD and activates one or more privacy-sensitive sensors to minimize the time a user can interact with the HMD. The wake-up signal does not need to be based on explicit user action; therefore, the HMD sensors can be activated without user intent. When the device exits the low-power state, an indicator light (e.g., a privacy LED) turns on, notifying the user that the device sensors (including one or more privacy-sensitive sensors) are active.

[0036] In some embodiments, the user needs to select the sensor lock function from the settings menu of the HMD. With sensor lock enabled, when the user puts on the headset from sleep mode, the display will not wake automatically, and the user will need to provide some positive input (e.g., pressing the power button) to wake the device and activate one or more device sensors. Once the user provides positive input (e.g., pressing the power button), the user is loaded into their home environment, and indicator lights (e.g., privacy LEDs) turn on. It is expected that the user will develop “muscle memory” and initiate positive input while wearing the headset.

[0037] In some other embodiments, sensor lock is enabled by default. In HMDs without proximity sensors and automatic wake-up functionality, the user experience is the same whether sensor lock is on or off. When a user puts on the headset from sleep mode, the user needs to provide some positive input (e.g., pressing the power button) to wake the device and activate one or more device sensors. Once the user provides positive input (e.g., pressing the power button), the user is loaded into their home environment, and indicator lights (e.g., privacy LEDs) turn on.

[0038] When sensor lock is enabled, the trusted software module of the head-mounted device prevents power from reaching one or more privacy-sensitive sensors. Other software executing within the head-mounted device or core processing unit cannot enable any privacy-sensitive sensors while sensor lock is enabled. When sensor lock is disabled, software executing within the head-mounted device or core processing unit can individually enable or disable any privacy-sensitive sensor.

[0039] When the head-mounted device is in a sensor-lock enabled state, embodiments executing within the trusted software module of the head-mounted device detect user presence events. In some embodiments, a user presence event is a head-mounted device wearing detection event detected using sensors in the head-mounted device that are designated as not privacy-sensitive sensors. For example, a proximity sensor can be used to detect the proximity of the head-mounted device's arm to the user's ear or temple, or a hinge position sensor can be used to detect whether the two arms of the head-mounted device have moved more than a predetermined number of degrees from a zero-degree (i.e., closed) position and are therefore considered open, or a combination of multiple sensors designated as not privacy-sensitive sensors can be used to detect that the head-mounted device is in a configuration consistent with being worn by the user. In some embodiments, a user presence event is a button press on a button in the head-mounted device (e.g., volume + / - control, power on / off button, or moving a power switch to the "on" position). In some embodiments, a user presence event is a signed power-on message from a core processing unit. The core processing unit is communicatively coupled to the head-mounted device, and the signed power-on message is generated by a trusted software module of the core processing unit in response to the detection of a button press (e.g., a power button press) in the core processing unit.

[0040] Upon detecting a user presence event while the sensor lock is enabled, an embodiment executing within the trusted software module of the head-mounted device transitions the head-mounted device from the sensor lock enabled state to the sensor lock disabled state. The transition to the sensor lock disabled state includes supplying power to the privacy-sensitive sensors of the head-mounted device and powering on the indicator lights of the head-mounted device.

[0041] Embodiments executing within a trusted software module of the head-mounted device transition the head-mounted device from a sensor-lock disabled state to a sensor-lock enabled state. Transitioning to the sensor-lock enabled state includes removing power from the head-mounted device's privacy-sensitive sensors and de-energizing the head-mounted device's indicator lights. In some embodiments, transitioning the head-mounted device from a sensor-lock disabled state to a sensor-lock enabled state is performed in response to a removal detection event. For example, a camera may be used to detect that the user's eyes are no longer in a position consistent with when the head-mounted device is being worn, that no user activity may have been detected for a predetermined period of time, that the head-mounted device or core processing unit may have entered or been commanded into a low-power state, that a proximity sensor may be used to detect that the head-mounted device's arms are not close to the user's ears or temples, that a hinge position sensor may be used to detect whether the two arms of the head-mounted device are below a predetermined degree from a zero-degree (i.e., closed) position and are therefore considered closed, that a combination of sensors may be used to detect that the head-mounted device is in a configuration consistent with when it has been removed by the user, or that another event may have occurred. In some embodiments, transitioning the head-mounted device from a sensor-lock disabled state to a sensor-lock enabled state is performed in response to a command from the core processing unit.

[0042] Figure 1 A network architecture 100 for implementing sensor-locking features for a mixed reality head-mounted device is illustrated according to some embodiments. The network architecture 100 may include one or more client devices 110 and a server 130, which are communicatively coupled to each other via a network 150 and coupled to at least one database 152. The database 152 may store data and files associated with the server 130 and / or the client devices 110. In some embodiments, the client device 110 collects data, video, images, etc., for uploading to the server 130 for storage in the database 152.

[0043] Network 150 may include wired networks (e.g., fiber optic, copper wire, telephone lines, etc.) and / or wireless networks (e.g., satellite networks, cellular networks, radio frequency (RF) networks, Wi-Fi, Bluetooth, etc.). Network 150 may also include one or more of local area networks (LANs), wide area networks (WANs), and the Internet. Furthermore, network 150 may include, but is not limited to, any or more of the following network topologies: bus networks, star networks, ring networks, mesh networks, etc.

[0044] Client device 110 may include, but is not limited to, laptop computers, desktop computers, and mobile devices such as smartphones, tablets, televisions, wearable devices, head-mounted devices, and display devices.

[0045] In some embodiments, server 130 may be a cloud server or a group of cloud servers. In other embodiments, some or all of server 130 may not be cloud-based servers (i.e., may be implemented outside of a cloud computing environment (including but not limited to on-premises environments)) or may be partially cloud-based. Some or all of server 130 may be part of a cloud computing server, including but not limited to rack-mounted computing devices and panels. Such panels may include, but are not limited to, processing boards, switch boards, routers, and other network devices. In some embodiments, server 130 may also include client devices 110, such that they are peers.

[0046] Figure 2 This is a block diagram illustrating details of a system 200 for sensor locking features of a mixed reality head-mounted device according to some embodiments. Specifically, Figure 2 An example is shown Figure 1 The exemplary client device 110-1 (of client device 110) and the exemplary server 130-1 (of server 130) in the network architecture 100.

[0047] Client device 110-1 and server 130-1 are communicatively coupled via network 150 through corresponding communication modules 202-1 and 202-2 (hereinafter collectively referred to as "communication module 202"). Communication module 202 is configured to connect to network 150 to send and receive information from other devices on network 150, such as requests, data, messages, commands, etc. Communication module 202 may be, for example, a modem or Ethernet card, and / or may include radio hardware and software for wireless communication (e.g., via electromagnetic radiation, such as radio frequency (RF), near field communication (NFC), Wi-Fi, and Bluetooth radio technologies).

[0048] The client device 110-1 further includes a processor 205-1 and a memory 220-1, and the server 130-1 further includes a processor 205-2 and a memory 220-2. Processors 205-1 and 205-2 will be collectively referred to as "processor 205" hereinafter, and memories 220-1 and 220-2 will be collectively referred to as "memory 220". Processor 205 can be configured to execute instructions stored in memory 220 to cause client device 110-1 and / or server 130-1 to perform methods and operations consistent with embodiments of this disclosure.

[0049] Client device 110-1 is coupled to at least one input device 230-1, and server 130-1 is coupled to at least one input device 230-2. Input devices 230-1 and 230-2 are collectively referred to as "input device 230" below. Input device 230 may include a mouse, controller, keyboard, pointer, stylus, touch screen, microphone, voice recognition software, joystick, virtual joystick, touch screen display, etc. In some embodiments, input device 230 may include a camera, microphone, sensor, etc. In some embodiments, the sensor may include a touch sensor, acoustic sensor, inertial motion unit, etc.

[0050] In other examples, input device 230 may include a biometric component, a motion component, an environmental component, a location component, and various other components. For example, a biometric component may include components that detect facial expressions (e.g., gestures, facial expressions, vocalizations, body postures, or eye tracking), measure biosignals (e.g., blood pressure, heart rate, body temperature, sweating, or brainwaves), and identify a person (e.g., voice recognition, retinal recognition, facial recognition, fingerprint recognition, or EEG-based recognition). The biometric component may include a brain-machine interface (BMI) system that allows communication between the brain and an external device or machine. This can be achieved by recording brain activity data, converting this data into a computer-understandable format, and then using the resulting signals to control the device or machine.

[0051] Examples of BMI technologies include: electroencephalography (EEG)-based BMIs, which use electrodes placed on the scalp to record electrical activity in the brain; invasive BMIs, which use electrodes surgically implanted into the brain; and optogenetic BMIs, which use light to control the activity of specific nerve cells in the brain.

[0052] Any biometric data collected by biometric identification components is collected and stored only with the user's consent and deleted upon the user's request. Furthermore, this biometric data may be used for very limited purposes, such as authentication. To ensure the limited and authorized use of biometric information and other personally identifiable information (PII), only authorized personnel can access this data. Any use of biometric data may be strictly limited to authentication purposes, and the data will not be shared or sold to any third party without the user's explicit consent. In addition, appropriate technical and organizational measures are implemented to ensure the security and confidentiality of this sensitive information.

[0053] Client device 110-1 is also coupled to at least one output device 232-1, and server 130-1 is also coupled to at least one output device 232-2. Output devices 232-1 and 232-2 are collectively referred to below as "output device 232". Output device 232 may include a screen, a display (e.g., the same touchscreen display used as an input device), a speaker, an alarm, etc. Users can interact with client device 110-1 and / or server 130-1 via input device 230 and output device 232.

[0054] Memory 220-1 may also include application 222 configured to execute on client device 110-1 and coupled to input device 230-1 and output device 232-1, and to implement sensor-locking features for a mixed reality head-mounted device. Application 222 may be downloaded by a user from server 130-1 and / or may be hosted by server 130-1. Application 222 may include specific instructions that, when executed by processor 205-1, cause to perform operations according to embodiments of this disclosure. In some embodiments, application 222 runs on an operating system (OS) installed on client device 110-1. In some embodiments, application 222 may run in a web browser. In some embodiments, processor 205-1 is configured to control (e.g., across at least a portion of input device 230 and output device 232) a graphical user interface (GUI) for a user of client device 110-1 to access server 130-1.

[0055] In some embodiments, memory 220-2 includes application engine 234. Application engine 234 can be configured to perform methods and operations according to embodiments of this disclosure. Application engine 234 can share or provide features and resources with client device 110-1, including data, libraries, and / or applications retrieved by application engine 234 (e.g., application 222). Users can access application engine 234 through application 222. Application 222 can be installed on client device 110-1 by application engine 234, and / or can execute scripts, routines, programs, applications, etc. provided by application engine 234.

[0056] Memory 220-1 may also include application 223, which is configured to execute in client device 110-1. Application 223 may communicate with service 233 in memory 220-2 to provide sensor locking features for the mixed reality headset. For example, application 223 may communicate with service 233 via API layer 240.

[0057] Figure 3 An example configuration of a mixed reality headset, according to some embodiments, is depicted for use in a sensor locking feature for a mixed reality headset.

[0058] Figure 3 A mixed reality head-mounted display (HMD) system 350 is depicted, comprising a mixed reality head-mounted display (HMD) 352 and a core processing unit 354. The HMD 352 and the core processing unit 354 can communicate via a wireless connection (e.g., a 60 GHz link) as shown by link 356 or via a wired connection (e.g., a fixed or removable cable) as shown by link 357. In other embodiments, the mixed reality HMD system 350 includes only a head-mounted display without external computing devices, or includes other wired or wireless connections between the mixed reality HMD 352 and the core processing unit 354. The mixed reality HMD 352 may include an on / off switch or power button (not shown) and one or more electronic components, such as a processor or a light projector (e.g., an LED). The core processing unit 354 may include an on / off switch or power button (not shown) and one or more electronic components, such as a processor or a light projector (e.g., an LED).

[0059] The Mixed Reality HMD 352 includes a pass-through display 358 and a frame 360. The frame 360 ​​can house various electronic components (not shown), such as one or more light projectors (e.g., lasers, LEDs, etc.), cameras, eye-tracking sensors, micro-electro-mechanical system (MEMS) components, network components, microphones, ultrasonic sensors, flicker sensors, distance or position detectors, inertial measurement units (IMUs), proximity sensors, hinge position sensors, etc. Another part of the frame 360 ​​or the Mixed Reality HMD 352 may include audio electronics, such as speakers (not shown). The speakers can output audio from various audio sources, such as telephone calls, VoIP sessions, or other audio channels. These electronic components can be configured to implement audio switching based on user gameplay or XR interaction.

[0060] The projector can be coupled to the pass-through display 358, for example, via optical elements, to display media to the user. The optical elements may include one or more waveguide components, one or more reflectors, one or more lenses, one or more mirrors, one or more collimators, one or more gratings, etc., for guiding light from the projector to the user's eyes. Image data can be transmitted from the core processing unit 354 to the mixed reality HMD 352 via link 356 or link 357. A controller in the mixed reality HMD 352 can convert the image data into multiple light pulses from the projector, which can be transmitted as output light to the user's eyes via the optical elements. The output light can be mixed with light passing through the pass-through display 358, allowing the output light to render virtual objects that appear to exist in the real world.

[0061] The mixed reality HMD system 350 may also include motion and position tracking units, cameras, light sources, etc., which allow the mixed reality HMD system 350 to track itself, for example in 3DoF or 6DoF, track various body parts of the user (e.g., hands, feet, head, or other body parts), render virtual objects as if they were stationary while the mixed reality HMD 352 moves, and make virtual objects react to gestures and other real-world objects. For example, the mixed reality HMD system 350 can track the movement and position of the user's wrist as input gestures for performing XR navigation. As an example, the mixed reality HMD system 350 may include a coordinate system for tracking the relative positions of various XR objects and elements in a shared artificial reality environment.

[0062] Figure 4 A block diagram depicts an example configuration of sensor locking features for a mixed reality head-mounted device according to an illustrative embodiment. Application 222 andFigure 2 The application in 222 is the same.

[0063] When the head-mounted device is in a sensor-lock enabled state, the user presence module 410, which is executing within the trusted software module of the head-mounted device, detects a user presence event. In some embodiments of the user presence module 410, the user presence event is a head-mounted device wearing detection event detected using sensors in the head-mounted device that are designated as non-privacy-sensitive sensors. For example, a proximity sensor can be used to detect the proximity of the head-mounted device's arms to the user's ears or temples, or a hinge position sensor can be used to detect whether the two arms of the head-mounted device have opened more than a predetermined degree from a zero-degree (i.e., closed) position and are therefore considered open, or a combination of multiple sensors designated as non-privacy-sensitive sensors can be used to detect that the head-mounted device is in a configuration consistent with being worn by the user. In some embodiments of the user presence module 410, the user presence event is a button press on a button in the head-mounted device (e.g., volume + / - control, power on / off button, or moving a power switch to the "on" position). In some embodiments of the user presence module 410, the user presence event is a signed power-on message from the core processing unit, received and processed by the communication module 430. The core processing unit is communicatively coupled to the head-mounted device, and the signed power-on message is generated by a trusted software module of the core processing unit in response to the detection of a button press (e.g., a power button press) in the core processing unit.

[0064] Upon detecting a user presence event while the sensor lock is enabled, the sensor lock module 420, executing within the trusted software module of the head-mounted device, transitions the head-mounted device from the sensor lock enabled state to the sensor lock disabled state. The transition to the sensor lock disabled state includes supplying power to the privacy-sensitive sensors of the head-mounted device and powering on the indicator lights of the head-mounted device.

[0065] Sensor locking module 420, executed within the trusted software module of the head-mounted device, transitions the head-mounted device from a sensor lock disabled state to a sensor lock enabled state. Transitioning to the sensor lock enabled state includes removing power from the privacy-sensitive sensors of the head-mounted device and de-energizing the indicator lights on the head-mounted device. In some embodiments of sensor locking module 420, the transition from sensor lock disabled to sensor lock enabled state is performed in response to a removal detection event. For example, a camera may be used to detect that the user's eyes are no longer in a position consistent with when the head-mounted device is being worn, that no user activity may have been detected for a predetermined period of time, that the head-mounted device or core processing unit may have entered or been commanded into a low-power state (received and processed by communication module 430), a proximity sensor may be used to detect that the arms of the head-mounted device are not close to the user's ears or temples, a hinge position sensor may be used to detect that both arms of the head-mounted device are below a predetermined degree from a zero-degree (i.e., closed) position and are therefore considered closed, a combination of sensors may be used to detect that the head-mounted device is in a configuration consistent with when it has been removed by the user, or that another event may have occurred. In some implementations of the sensor locking module 420, in response to a command received and processed by the communication module 430 from the core processing unit, the head-mounted device is switched from a sensor locking disabled state to a sensor locking enabled state.

[0066] Figure 5 An example state of a sensor locking feature for a mixed reality head-mounted device, according to an illustrative embodiment, is depicted.

[0067] In state 510, with the sensor lock disabled, the user removes the headset. After an idle timeout (state 520), in state 530, the headset transitions from the sensor lock disabled state to the sensor lock enabled state. A short time later (state 540), the user puts the headset back on, and in state 550, the headset transitions from the sensor lock enabled state to the sensor lock disabled state. Afterward, when the user removes the headset, the headset returns to state 510.

[0068] Figure 6 An example state of a sensor locking feature for a mixed reality head-mounted device, according to an illustrative embodiment, is depicted.

[0069] In transition 17 (T17), when the user selects to power off in the headset's software or presses and holds the headset's power button (for 1 to 3 seconds), the headset transitions from state 600 (any state) to state 610 (headset off). In state 610, when the headset's power button is pressed and held (for 1 to 3 seconds), the headset transitions from transition (T1A) to state 620 (headset is woken up and sensor lock is off or disabled), or if the headset's battery is depleted while not in use, it transitions (T1B) to state 640 (startup screen, i.e., presented to the user via the user interface requiring user confirmation, and sensor lock is enabled).

[0070] In one embodiment, at state 620, when the headset is removed, the headset transitions (T2A) to state 630, where a sleep timer is started and sensor lock is off. In another embodiment, at state 620, when the sleep timer expires, the headset transitions (T2B) to state 650 (the headset sleeps and sensor lock is on). At state 620, if the user selects a software restart, the headset restarts and then transitions (T3) back to state 620. At state 620, if the user selects a firmware update, the headset transitions (T4A) to state 640 if an update is available, and remains at state 620 if no update is available. At state 620, when the power button of the headset is pressed briefly (approximately one second), the headset transitions (T5) to state 650.

[0071] In state 630, when the sleep timeout expires, the head-mounted device transitions (T6) to state 650. In state 630, when the user puts on the head-mounted device, the head-mounted device transitions (T7) to state 620.

[0072] In state 640, when the power button of the headset is pressed briefly (for about one second), the headset transitions (T15) to state 620. When the user removes the headset or the sleep timeout expires, the headset transitions from state 640 to state 650 (T16).

[0073] In state 650, when the power button of the headset is pressed briefly (approximately one second), the headset transitions (T11) to state 620. In state 650, when the user puts on the headset, the headset remains (T10) in state 650. In state 650, when the wake-up timer expires, the headset transitions (T12) to state 670. In state 670, the headset wakes up and searches for an over-the-air (OTA) firmware update. If no firmware update is available, the headset transitions back to state 650 (T12). In state 650, when the headset restarts, the headset transitions (T13) to state 660.

[0074] In state 660, when the user puts on the headset, the headset transitions (T9) to state 640. In state 660, when the sleep timeout expires, the headset transitions (T8) to state 650.

[0075] In state 670, if a firmware update is available, the headset restarts and transitions (T14A) to state 660. In state 670, if no firmware update is available, the headset transitions (T14B) to state 650.

[0076] Figure 7 A flowchart depicts an example process for sensor locking features of a mixed reality head-mounted device according to an illustrative embodiment. Process 700 can be... Figure 2 It is implemented in application 222.

[0077] At box 702, the process detects that the head-mounted device has transitioned from a sleep state to a wear state when it is in sleep mode. At box 704, in response to this detection, the process determines that the sensor lock feature of the head-mounted device is activated. At box 706, after this determination, the process, in response to detecting activation of the power button on the head-mounted device, transitions the head-mounted device from sleep mode to wake state. At box 708, in response to this detection, after determining that the sensor lock feature of the head-mounted device is disabled, the process transitions the head-mounted device from sleep mode to wake state. The process then ends.

[0078] Figure 8 An example state of a sensor locking feature for a mixed reality head-mounted device, according to an illustrative embodiment, is depicted.

[0079] In particular, Figure 8Example states of sensor lock-up features in an embodiment where the head-mounted device is communicatively coupled to the core processing unit are depicted. 810 depicts a sensor lock-up state of the head-mounted device. 820 depicts a core processing unit state. On the head-mounted device, the sensor lock-up state is managed by a trusted software module that controls the power supply to the sensors. The head-mounted device always starts in the sensor lock-up enabled state and moves to the sensor lock-up disabled state when wear detection occurs (e.g., using one or more sensors designed not to be privacy-sensitive sensors, such as proximity sensors and hinge detection), when a user presses a button on the head-mounted device (e.g., volume + / - buttons), or when a signed message is received from the core processing unit indicating that a user has been detected by a button press on the core processing unit (e.g., power button press). A transition to the sensor lock-up enabled state occurs when the core processing unit enters a low-power mode or sleep mode. If this transition is untrusted because power management is implemented in an untrusted part of the core processing unit's software, an indicator light (e.g., a privacy LED) remains illuminated throughout the time the head-mounted device is in the sensor lock-up disabled state.

[0080] The power state transitions on the core processing unit interact with the sensor lock state machine. Therefore, when the core processing unit powers on or is woken up by a user, it can use secondary user detection (primary user detection being proximity and other sensors on the headset) to disable sensor lock. When the core processing unit is woken up, but sensor lock is not yet disabled, the untrusted software of the core processing unit presents a user interface, allowing the user to disable sensor lock. The core processing unit also transmits its power state to the headset as an indication that the user has unintentionally and actively used the device, thus enabling sensor lock. In the "Full Power / Detect User Present" state on the core processing unit, it polls the current sensor lock state. If sensor lock is already disabled, the core processing unit immediately transitions to the "Full Power / Awake" state without affecting the user interface. Conversely, if sensor lock is enabled, the core processing unit presents a user interface prompting the user to physically interact with the core processing unit or the head-mounted device to trigger wear detection. The core processing unit then waits in this state until sensor lock on the head-mounted device is deactivated. In one embodiment, if the core processing unit is awakened but no wear signal is detected on the head-mounted device, the core processing unit renders a display using a lock screen that prompts the user to press any button on the head-mounted device or any button on the core processing unit to unlock the device. In another embodiment, if the core processing unit is awakened but no wear signal is detected on the head-mounted device, either the core processing unit does not drive the display / backlight, or the head-mounted device cuts off the voltage to the display / backlight, thereby indirectly forcing the user to press any button to wake the device.

[0081] Figure 9 An example configuration of a software module implementing a sensor locking feature for a mixed reality head-mounted device according to an illustrative embodiment is depicted. Application 222 and... Figure 2 The application in 222 is the same.

[0082] Executed within the trusted zone 910 of the head-mounted device, application 222 receives on / off detection events detected by one or more proximity sensors 916, receives button press events from volume buttons 918, and uses a power management integrated circuit (PMIC) 919 to control one or more privacy-sensitive sensors 912 and illuminate a privacy LED 914.

[0083] Specifically, the put / take off detection logic notifies application 222 of the change in the put / take off state and responds to queries from application 222 regarding the current put / take off state. Application 222 manages the sensor lock state; it is the true source of the current sensor lock state and is responsible for ensuring the privacy of this feature. Application 222 implements... Figure 8 The sensor lock state machine depicted in the head-mounted device sensor lock state 810 derives a shared secret key using currently available technology, receives and verifies tokens from the core processing unit 920 (using the shared secret key) to deactivate or disable sensor lock (e.g., for hardware or software verification in a test environment), receives intent from the core processing unit 920 to transition sensor lock to an enabled state, and reports the current sensor lock state whenever the state changes or when queried by the core processing unit 920.

[0084] Privacy LED 914 is used to indicate the on / off state of privacy-sensitive sensors 912 (e.g., a camera or microphone) and the sensor lock state. If any privacy-sensitive sensor 912 is on, privacy LED 914 must remain on at least a predetermined minimum brightness level. Even if all privacy-sensitive sensors 912 are off (e.g., via another module of the headset software), privacy LED 914 remains on if sensor lock is disabled. When sensor lock is enabled, privacy LED 914 is off (i.e., off). Application 222 controls privacy LED 914 via general-purpose input / output (GPIO) to allow application 222 to activate privacy LED 914 even when power to privacy-sensitive sensors 912 is cut off (e.g., when sensor lock is disabled), or to implement user interface behaviors such as blinking or minimum on time.

[0085] Application 222 communicates with the Sensor Lock HAL via a secure communication channel. The Sensor Lock HAL is a software module that executes in the untrusted area 922 of the core processing unit 920. Because events originating from the power button 926 are handled by a trusted software module (the trusted application (TA) of the Sensor Lock, which executes in the trusted area 924 of the core processing unit 920), the power button event is considered a trusted event.

[0086] The Sensor Locking HAL is a key component on the core processing unit 920, used to bootstrap the sensor locking state machine. The Sensor Locking HAL is responsible for loading and initializing the Sensor Locking Trusted Application (TA) within the trusted zone 924 of the core processing unit 920. When needed, it queries the latest sensor locking state from application 222, receives sensor locking state change notifications from application 222 and propagates the state changes to higher layers without caching, detects power button presses used to start / wake the system, and calls the trusted zone application programming interface (API) to obtain a signed token to be sent to application 222 via a secure channel.

[0087] The Sensor Locking TA is responsible for deriving the shared key, using it to sign messages (or tokens) sent to Application 222 via the secure channel to disable Sensor Locking, and verifying any messages received by Sensor Locking HAL from Application 222 when needed. Note that tokens generated by the Sensor Locking TA should be used only once and must have a reasonable expiration time. Otherwise, software executing in untrusted zone 922 could abuse the token to disable Sensor Locking. One way to implement signed token expiration is to first request a random number from Application 222 and then use that random number to generate the signed token. In addition to verifying the token's signature, Application 222 must also verify the random number and cache it for a predetermined period.

[0088] The Sensor Lock User Confirmation (UC) activity module is a software module that executes in the untrusted zone 922 of the core processing unit 920. It is a user interface component that prompts the user to interact with the headset or core processing unit, with the purpose of triggering wear detection (e.g., using a confirmation screen). The Sensor Lock UC activity module receives sensor lock state change notifications from the Sensor Lock HAL and is activated whenever the sensor lock state transitions to the active state (e.g., prompting the user or consuming the power button press). When sensor lock is deactivated, the Sensor Lock UC activity module deactivates (goes to the background). The Sensor Lock UC activity module also listens for hot-plug events (i.e., when the headset and core processing unit are connected to each other while powered on) and queries the current sensor lock state to avoid waiting for state change notifications from the headset. The Sensor Lock UC activity module always queries the headset for the current sensor lock state before interacting with the user via the user interface. If a malicious actor disrupts the Sensor Lock UC activity module, the malicious actor may prevent the confirmation screen from appearing, but cannot deactivate sensor lock.

[0089] Figure 10A flowchart depicts another example process for a sensor locking feature for a mixed reality head-mounted device according to an illustrative embodiment. Process 1000 can be... Figure 2 It is implemented in application 222.

[0090] At box 1002, the process uses a trusted software module of the head-mounted device to detect a user presence event when the head-mounted device is in a sensor lock enabled state. At box 1004, the process uses the trusted software module of the head-mounted device to transition the head-mounted device from a sensor lock enabled state to a sensor lock disabled state. This transition includes providing power to the privacy-sensitive sensors of the head-mounted device and powering on the indicator lights of the head-mounted device. At box 1006, the process uses the trusted software module of the head-mounted device to transition the head-mounted device from a sensor lock disabled state to a sensor lock enabled state. This transition includes removing power from the privacy-sensitive sensors of the head-mounted device and powering off the indicator lights of the head-mounted device. The process then ends.

[0091] Many of the features and applications described above can be implemented as software processes, which are defined as a set of instructions recorded on a computer-readable storage medium (also known as a computer-readable medium, machine-readable medium, or machine-readable storage medium). When these instructions are executed by one or more processing units (e.g., one or more processors, one or more processor cores, or one or more other processing units), the instructions cause the one or more processing units to perform the actions indicated in the instructions. Examples of computer-readable media include, but are not limited to, RAM, ROM, read-only compact disc (CD-ROM), recordable compact disc (CD-R), rewritable compact disc (CD-RW), read-only digital versatile optical disc (e.g., DVD-ROM, dual-layer DVD-ROM), various recordable / rewritable DVDs (e.g., DVD-RAM, DVD-RW, DVD+RW, etc.), flash memory (e.g., SD card, mini SD card, micro SD card, etc.), magnetic and / or solid-state hard disk drives, high-density optical discs, any other optical or magnetic media, and floppy disks. In one or more embodiments, the computer-readable medium does not include carrier waves and electronic signals transmitted wirelessly or via a wired connection, or any other transient signals. For example, the computer-readable medium may be entirely limited to a tangible physical object that stores information in a computer-readable form. In one or more embodiments, the computer-readable medium is a non-transitory computer-readable medium, a computer-readable storage medium, or a non-transitory computer-readable storage medium.

[0092] In one or more embodiments, a computer program product (also referred to as a program, software, software application, script, or code) may be written in any type of programming language (including compiled or interpreted languages, declarative or programming languages) and may be deployed in any form, including as a standalone program or module, component, subroutine, object, or other unit suitable for a computing environment. A computer program may, but does not need to, correspond to a file in a file system. A program may be stored as a portion of a file containing other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple collaborating files (e.g., a file storing one or more modules, subroutines, or code portions). A computer program may be deployed to execute on a single computer or on multiple computers located in one location or distributed across multiple locations and interconnected via a communication network.

[0093] While the above discussion primarily concerns microprocessors or multi-core processors that execute software, one or more embodiments are executed by one or more integrated circuits, such as application-specific integrated circuits (ASICs) or field-programmable gate arrays (FPGAs). In one or more embodiments, such integrated circuits execute instructions stored on the circuit itself.

[0094] While this specification contains numerous details, these details should not be construed as limiting the scope of the claims, but rather as descriptions of particular embodiments of the subject matter. Certain features described in the context of independent embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments. Furthermore, although features may be described above as functioning in certain combinations, and even initially claimed in this way, one or more features from a claimed combination may be removed from that combination in some cases, and the claimed combination may be for sub-combinations or variations thereof.

[0095] Those skilled in the art will understand that the various illustrative blocks, modules, elements, components, methods, and algorithms described herein can be implemented as electronic hardware, computer software, or a combination of both. To illustrate this interchangeability between hardware and software, the various illustrative blocks, modules, elements, components, methods, and algorithms have been described above in terms of their functionality. Whether this functionality is implemented as hardware or software depends on the specific application and design constraints on the overall system. Those skilled in the art can implement the described functionality in different ways for each specific application. Various components and blocks can be arranged differently (e.g., in different orders or in different ways), all without departing from the scope of the subject matter.

[0096] It should be understood that any particular order or hierarchy of boxes in the disclosed process is illustrative of the example method. Depending on implementation preferences, it should be understood that a particular order or hierarchy of boxes in the process may be rearranged, or not all shown boxes may be executed. Any boxes may be executed concurrently. In one or more embodiments, multitasking and parallel processing may be advantageous. Furthermore, the separation of various system components in the above embodiments should not be construed as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

[0097] For example, the subject matter has been described in accordance with the foregoing aspects. This disclosure is provided to enable any person skilled in the art to practice the aspects described herein. This disclosure provides various examples of the subject matter, and the subject matter is not limited to these examples. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects.

[0098] Unless otherwise specified, elements mentioned in the singular do not mean "one and only one," but rather "one or more." Unless otherwise specified, the term "some" means one or more. Masculine pronouns (such as his) include feminine and neuter pronouns (such as her and its), and vice versa. Titles and subtitles (if any) are used for convenience only and do not limit this disclosure.

[0099] With regard to the terms “comprising,” “having,” etc., used in the specification, claims, or clauses, the term is intended to be inclusive in a manner similar to the term “including,” as interpreted when “including” is used as a transitional word in a claim.

[0100] As used herein, the term "exemplary" means "serving as an example, instance, or illustration." Any embodiment described herein as "exemplary" is not necessarily to be construed as being more preferred or advantageous than other embodiments. In one aspect, the various alternative configurations and operations described herein may be considered at least equivalent.

[0101] As used herein, the phrase “at least one of…” following a series of items, along with the terms “and” or “or” used to separate any items, modifies the entire list, not each member of the list (i.e., each item). The phrase “at least one of…” does not require the selection of at least one item; rather, the phrase allows for the inclusion of at least one of any one item, and / or at least one of any combination of items, and / or at least one of each item. For example, the phrases “at least one of A, B, and C” or “at least one of A, B, or C” each refer to only A, only B, or only C; any combination of A, B, and C; and / or at least one of each of A, B, and C.

[0102] Phrases such as "aspect" do not imply that the aspect is essential to the subject matter, nor do they imply that the aspect is applicable to all configurations of the subject matter. Disclosures relating to an aspect may apply to all configurations, or one or more configurations. An aspect may provide one or more examples. Phrases such as "aspect" may refer to one or more aspects, or vice versa. Phrases such as "embodiment" do not imply that the embodiment is essential to the subject matter, nor do they imply that the embodiment is applicable to all configurations of the subject matter. Disclosures relating to an embodiment may apply to all embodiments, or one or more embodiments. An embodiment may provide one or more examples. Phrases such as "embodiment" may refer to one or more embodiments, or vice versa. Phrases such as "configuration" do not imply that such a configuration is essential to the subject matter, nor do they imply that such a configuration is applicable to all configurations of the subject matter. Disclosures relating to a configuration may apply to all configurations, or one or more configurations. A configuration may provide one or more examples. Phrases such as "configuration" may refer to one or more configurations, or vice versa.

[0103] In one respect, unless otherwise stated, all measurements, numerical values, ratings, positions, quantities, dimensions, and other specifications listed in this specification (including the appended claims or clauses) are approximate values, not precise values. In another respect, they are intended to have a reasonable range consistent with the functions they address and the conventions of the field to which they belong. It should be understood that some or all steps, operations, or processes can be performed automatically without user intervention.

[0104] Method claims or clauses may be provided to present elements of various steps, operations, or processes in a sample order, but this does not mean being limited to the specific order or hierarchy presented.

[0105] In one respect, a method can be an operation, instruction, or function, or vice versa. In another respect, a claim can be modified to include some or all of the words (e.g., instruction, operation, function, or component) referenced in one or more other claims, one or more words, one or more sentences, one or more phrases, one or more paragraphs, and / or one or more claims.

[0106] All structural and functional equivalents of the various configurations described herein, which are known or will be known hereafter by one of ordinary skill in the art, are expressly incorporated herein by reference and are intended to be included in the subject matter. Furthermore, nothing disclosed herein is intended to be offered to the public, whether or not such disclosure is expressly stated in the foregoing description.

[0107] The title, background techniques, and accompanying drawings of this disclosure are hereby incorporated into this disclosure and are provided as illustrative examples, not as limiting descriptions. It should be understood at the time of filing that they are not intended to limit the scope or meaning of the claims. Furthermore, in the detailed description, it will be apparent that illustrative examples are provided, and various features are combined in various embodiments to simplify this disclosure. This approach to disclosure should not be construed as reflecting an intention that the included subject matter requires more features than expressly recited in any claim. Rather, as reflected in the claims, the inventive subject matter lies in all features of fewer than a single disclosed configuration or operation. The claims are hereby incorporated into the detailed description, each claim independently representing a separate patentable subject matter.

[0108] The claims or terms are not intended to be limited to the aspects described herein, but should be given the full scope consistent with the language of the claims and cover all legal equivalents.

[0109] The embodiments according to this disclosure can be combined with any combination of features or aspects of the embodiments described herein.

Claims

1. A computer-implemented method, the method comprising: When the head-mounted device is in sensor lock enabled state, the trusted software module of the head-mounted device is used to detect user presence events; The trusted software module of the head-mounted device is used to switch the head-mounted device from the sensor lock enabled state to the sensor lock disabled state, the switch including providing power to the privacy-sensitive sensors of the head-mounted device and powering on the indicator lights of the head-mounted device; as well as The trusted software module of the head-mounted device is used to switch the head-mounted device from the sensor lock disabled state to the sensor lock enabled state. This switch includes removing power from the privacy-sensitive sensors of the head-mounted device and de-energizing the indicator lights of the head-mounted device.

2. The computer-implemented method according to claim 1, wherein, The user presence event includes a head-mounted device wearing detection event detected by a sensor in the head-mounted device that is designated as not a privacy-sensitive sensor.

3. The computer-implemented method according to claim 1, wherein, The user presence event includes pressing a button on the head-mounted device.

4. The computer-implemented method according to claim 1, wherein, The user presence event includes a signed power-on message from a core processing unit communicatively coupled to the head-mounted device, the signed power-on message being generated by a trusted software module of the core processing unit in response to detecting a press of the core processing unit's power button.

5. The computer-implemented method according to claim 4, wherein, In response to receiving a signed power status message from the core processing unit, the head-mounted device is switched from the sensor lock disabled state to the sensor lock enabled state.

6. The computer-implemented method according to claim 4, wherein, The core processing unit is communicatively coupled to the head-mounted device via a removable cable.

7. The computer-implemented method according to claim 4, wherein, The core processing component is communicatively coupled to the head-mounted device via a wireless communication link.

8. The computer-implemented method according to claim 1, wherein, In response to a removal detection event, the head-mounted device is switched from the sensor-locked disabled state to the sensor-locked enabled state.

9. A non-transitory computer-readable medium storing a program that, when executed by a computer, configures the computer to: When the head-mounted device is in sensor lock enabled state, the trusted software module of the head-mounted device is used to detect user presence events; The trusted software module of the head-mounted device is used to switch the head-mounted device from the sensor lock enabled state to the sensor lock disabled state, the switch including providing power to the privacy-sensitive sensors of the head-mounted device and powering on the indicator lights of the head-mounted device; as well as The trusted software module of the head-mounted device is used to switch the head-mounted device from the sensor lock disabled state to the sensor lock enabled state. This switch includes removing power from the privacy-sensitive sensors of the head-mounted device and de-energizing the indicator lights of the head-mounted device.

10. The non-transitory computer-readable medium according to claim 9, wherein, The user presence event includes a head-mounted device wearing detection event detected by a sensor in the head-mounted device that is designated as not a privacy-sensitive sensor.

11. The non-transitory computer-readable medium according to claim 9, wherein, The user presence event includes pressing a button on the head-mounted device.

12. The non-transitory computer-readable medium according to claim 9, wherein, The user presence event includes a signed power-on message from a core processing unit communicatively coupled to the head-mounted device, the signed power-on message being generated by a trusted software module of the core processing unit in response to detecting a press of the core processing unit's power button.

13. The non-transitory computer-readable medium according to claim 12, wherein, The transition of the head-mounted device from the sensor-locked disabled state to the sensor-locked engaged state is performed in response to receiving a signed power status message from the core processing unit.

14. The non-transitory computer-readable medium according to claim 12, wherein, The core processing unit is communicatively coupled to the head-mounted device via a removable cable.

15. The non-transitory computer-readable medium according to claim 12, wherein, The core processing component is communicatively coupled to the head-mounted device via a wireless communication link.

16. The non-transitory computer-readable medium according to claim 9, wherein, The transition of the head-mounted device from the sensor-locked disabled state to the sensor-locked enabled state is performed in response to a removal detection event.

17. A system comprising: processor; as well as A non-transitory computer-readable medium storing a set of instructions that, when executed by the processor, configure the system to: When the head-mounted device is in sensor lock enabled state, the trusted software module of the head-mounted device is used to detect user presence events; The trusted software module of the head-mounted device is used to switch the head-mounted device from the sensor lock enabled state to the sensor lock disabled state, the switch including providing power to the privacy-sensitive sensors of the head-mounted device and powering on the indicator lights of the head-mounted device; as well as The trusted software module of the head-mounted device is used to switch the head-mounted device from the sensor lock disabled state to the sensor lock enabled state. This switch includes removing power from the privacy-sensitive sensors of the head-mounted device and de-energizing the indicator lights of the head-mounted device.

18. The system according to claim 17, wherein, The user presence event includes a head-mounted device wearing detection event detected by a sensor in the head-mounted device that is designated as not a privacy-sensitive sensor.

19. The system according to claim 17, wherein, The user presence event includes pressing a button on the head-mounted device.

20. The system according to claim 17, wherein, The user presence event includes a signed power-on message from a core processing unit communicatively coupled to the head-mounted device, the signed power-on message being generated by a trusted software module of the core processing unit in response to detecting a press of the core processing unit's power button.

Images