User-related display performance interface

Abstract

Various implementations disclosed herein include devices, systems, and methods that enable an application to query a wearable device to determine whether current usage of the wearable device by a user satisfies performance requirements. For example, a process can include receiving a request that corresponds to the wearable device satisfying performance requirements needed by the application to perform a function while the wearable device is worn by the user. The process can also obtain device performance data corresponding to the capabilities of the wearable device while the wearable device is worn by the user. The process can also provide a response to the request based on the performance requirements and the device performance data. The response can provide or enable a determination of whether the wearable device will satisfy the performance requirements needed by the application to perform the function while the wearable electronic device is worn by the user.

Description

Technical Field

[0001] This disclosure relates in general to systems, methods, and devices that enable applications to query devices to determine whether a user’s current use of the device meets performance requirements. Background Technology

[0002] Various applications have diverse performance requirements for the electronic devices on which they run. For example, an application may require its head-mounted display (HMD) to provide a minimum field of view (FOV) to the current user. Existing technologies do not adequately enable such applications to discover device characteristics and / or otherwise ensure that performance requirements will be met. Summary of the Invention

[0003] The various specific implementations disclosed herein include systems, methods, and devices that enable applications to query wearable devices such as head-mounted devices (HMDs) to determine whether a user's current use of the wearable device meets user- and / or device-specific performance requirements (e.g., visual and / or audio requirements). For example, a medical application may be configured to query the HMD to verify that a user (such as a physician or patient) is able to view a specific size of field of view (FOV) on the HMD's display, or that a patient is able to maintain a specified stimulus in their peripheral view. In some implementations, the query may be enabled via an interface such as, for example, an application programming interface (API).

[0004] In some specific implementations, performance requirements may involve user-related / specific (e.g., user cooperation) and / or application-specific (e.g., medical imaging applications) display requirements, such as FOV requirements, color uniformity requirements, distortion (e.g., FOV-related) requirements, pixels per degree (PPD) requirements, sharpness requirements, camera characteristic requirements, etc.

[0005] In some implementations, the query response may result in a notification indicating that a performance requirement has not yet been met. In some implementations, the query response may be provided by an application and / or a wearable device. In some implementations, the query response may provide instructions (to the user of the wearable device) for modifying the wearable device. In some implementations, the query response may provide instructions related to how to use and / or wear the wearable device. In some implementations, the query response may result in a notification being sent / shared to a second device that monitors the use of an application on a first device. For example, a patient may use a device such as an HMD to perform medical tests (e.g., eye / vision examinations), and another device, such as a tablet (i.e., communicating with the HMD), may be used to monitor the tests, such that the tablet is configured to alert a medical practitioner (using the tablet) that the patient is currently outside the permissible performance envelope within the HMD.

[0006] In some implementations, query responses can be configured to provide indicators such as pass / fail indicators, computed values, and privacy-preserving representations. For example, an alert can be issued if a user is unable to achieve a specified field of view (FOV) as required by management entities, application design specifications, etc.

[0007] In some specific implementations, determining whether performance requirements have been met can be based on the user's current location relative to the wearable device. For example, the assessment of what the user can actually view can be based on the user's current location relative to the wearable device, such as using ray tracing models to predict or simulate the light that will travel from a portion of the HMD's display to the user's eyes, for example, whether light from a specific pixel or group of pixels will reach the pupil, retina, etc.

[0008] In some embodiments, the wearable device has a processor (e.g., one or more processors) that executes instructions stored in a non-transitory computer-readable medium to perform a method. The method performs one or more steps or procedures. In some embodiments, the wearable electronic device receives requests from an application, such as requests from the application regarding device status, capabilities, current configuration, location relative to a user, etc. The request may correspond to the wearable electronic device meeting the performance requirements needed by the application to perform functions when the wearable electronic device is worn by a user. In some embodiments, device performance data corresponding to the device's capabilities when the wearable electronic device is worn by a user is obtained, and a response to the request is provided based on the performance requirements and the device performance data. In some embodiments, the response provides or implements a determination of whether the wearable electronic device will meet the performance requirements needed by the application to perform functions when the wearable electronic device is worn by a user.

[0009] According to some embodiments, an apparatus includes one or more processors, non-transitory memory, and one or more programs; the one or more programs are stored in the non-transitory memory and configured to be executed by the one or more processors, and the one or more programs include instructions for performing or causing to perform any of the methods described herein. According to some embodiments, a non-transitory computer-readable storage medium stores instructions that, when executed by one or more processors of the apparatus, cause the apparatus to perform or cause to perform any of the methods described herein. According to some embodiments, an apparatus includes: one or more processors, non-transitory memory, and components for performing or causing to perform any of the methods described herein. Attached Figure Description

[0010] To enable those skilled in the art to understand this disclosure, more detailed descriptions can be made with reference to aspects of some exemplary embodiments, some of which are shown in the accompanying drawings.

[0011] Figure 1 Exemplary electronic devices operating in a physical environment according to some specific implementations are illustrated.

[0012] Figure 2 An example of a notification framework based on some specific implementations is shown, which uses sensor data, performance requirement data, and user / device performance modules to enable applications to query wearable devices to determine whether the current use of the wearable device meets performance requirements.

[0013] Figure 3A and Figure 3B An example is given of an environment that includes a view of content provided to the user relative to the field of view, based on some specific implementations.

[0014] Figure 3C and Figure 3D Examples of FOV patterns based on the Visual Fidelity API are shown in some specific implementations.

[0015] Figure 4 An exemplary ray tracing model of an optical module of an electrical device according to some specific implementation is illustrated.

[0016] Figure 5 This is a block diagram illustrating an example system of a user device configured, based on some specific implementation, to enable an application to query the wearable device to determine whether the current use of the wearable device meets the user's specific performance requirements.

[0017] Figure 6 This is a flowchart representation of an exemplary method, based on some specific implementations, that enables an application to query a wearable device (such as an HMD) to determine whether a user's current use of the HMD meets user / device-based performance requirements.

[0018] Figure 7 These are example electronic devices based on some specific implementations.

[0019] Figure 8A Examples of methods for calling application programming interfaces (APIs) to obtain information and provide that information to the system are provided.

[0020] Figure 8B Examples of methods for calling application programming interfaces (APIs) to obtain information and perform corresponding operations are provided.

[0021] As is customary practice, various features illustrated in the accompanying drawings may not be drawn to scale. Therefore, for clarity, the dimensions of various features may be arbitrarily expanded or reduced. Furthermore, some drawings may not depict all components of a given system, method, or apparatus. Finally, similar reference numerals may be used throughout the specification and drawings to denote similar features. Detailed Implementation

[0022] Numerous details have been described to provide a thorough understanding of the exemplary embodiments illustrated in the accompanying drawings. However, the drawings illustrate only some exemplary aspects of this disclosure and should not be considered limiting. Those skilled in the art will understand that other effective aspects and / or variations do not include all the specific details described herein. Furthermore, well-known systems, methods, components, devices, and circuits have not been described exhaustively so as not to obscure further relevant aspects of the exemplary embodiments described herein.

[0023] Figure 1 An exemplary electronic device 105 operating in a physical environment 100 is illustrated. Additionally, the example environment 100 may include an information system 104 (e.g., a device control framework or network) communicating with the electronic device 105. Figure 1 In the example, physical environment 100 is a room including table 120. Electronic device 105 includes one or more cameras, microphones, depth sensors, or other sensors that can be used to capture and evaluate information about physical environment 100 and objects within it, as well as information about user 102 of electronic device 105. Information about physical environment 100 and / or user 102 can be used to provide visual and audio content, and / or identify the current location of physical environment 100 and / or the location of the user within physical environment 100.

[0024] In some implementations, a view of an extended reality (XR) environment may be provided to one or more participants (e.g., user 102 and / or other participants not shown) via an electronic device 105 (e.g., a wearable device such as an HMD). Such an XR environment may include a view of a 3D environment generated based on camera images and / or depth camera images of the physical environment 100, and a representation of user 102 based on camera images and / or depth camera images of user 102. Such an XR environment may include virtual content positioned at a 3D location relative to a 3D coordinate system associated with the XR environment, which may correspond to the 3D coordinate system of the physical environment 100.

[0025] In some implementations, requests such as queries may be received via API from applications running on electronic device 105 and / or information system 104. These requests may correspond to performance requirements of electronic device 105 (e.g., a wearable device such as an HMD) that are necessary for the application to perform its functions when electronic device 105 is worn by user 102 (e.g., by legal or regulatory entities, by device functional requirements, etc.). Performance requirements may include user-related / specific and / or application-specific requirements, such as, for example, the field of view (FOV) required for specific application use. For example, the effective performance of the device may be user-specific, particularly based on the registration of user 102's eyes and / or hands, active sensing of user 102's eyes relative to the display of electronic device 105 (e.g., the HMD), etc.

[0026] In some specific implementations, device performance data may be obtained from, for example, sensors. Device performance data may correspond to the capabilities of electronic device 105 when worn by user 102. Device performance data may include model-specific or device-specific audio / video application and / or user-specified characteristics, particularly related to FOV, distortion, PPD, chromatic aberration, brightness, brightness uniformity, color, color uniformity, sharpness, contrast, virtual image distance, pupil positioning relative to the device worn by user 102, gaze angle associated with pupil positioning (determined based on sensor data), interpupillary distance (IPD), known device characteristics, ray tracing model of the optical stack between the display of device 105 and the eyes of user 102, camera characteristics (image sensor, optics, etc.), etc.

[0027] In some implementations, obtaining device performance data may include acquiring and determining the characteristics of user 102 based on the current location of user 102 relative to device 105, such as whether user 102 is wearing glasses. In some implementations, obtaining device performance data may include predicting or simulating performance data based on current device and / or user characteristics, the positional relationship between device 105 and user 102, etc.

[0028] In some implementations, the response to the request (i.e., the query) may be based on performance requirements and device performance data. In some implementations, the response may provide or enable a determination of whether electronic device 105 will meet the performance requirements required for an application to perform its functions when worn by a user. In some implementations, the response may include pass / fail indications, calculated values ​​of the device's current performance capabilities, privacy-preserving representations (such as indicating whether a minimum FOV is available without revealing the actual FOV), and / or actual user characteristics used to determine the actual FOV. In some implementations, the response may be provided to the requesting application to enable the application to perform appropriate actions, such as, in particular, notifying user 102, preventing or allowing the use of the application on device 105.

[0029] Figure 2 An example of a notification framework 200 according to some specific implementation is illustrated, which utilizes sensor data 210 from sensor 205, performance requirement data 212, and user / device performance module 215 to enable application 226 to query (via API 217 and query tool 216) wearable devices such as HMDs (e.g., Figure 1 Device 105) to determine the user (e.g., Figure 1 (102) Whether the current use of the wearable device meets the user's specific performance requirements. For example, a medical application may be configured to query the HMD to ensure that the viewer is viewing a specified field of view (FOV) or that the patient is able to view a specified stimulus in their periphery.

[0030] Notification framework 200 includes (e.g., Figure 1 The electronic device 105 includes sensors 205, such as image sensors, inertial measurement unit (IMU) sensors, accelerometers, gyroscopes, etc. Similarly, the notification framework 200 includes sensor data 210, user / device performance module 215, tools / software 208, applications 226, APIs, and a control system 220, which in some implementations communicate via a data communication network 202 (e.g., a local area network (LAN), a wide area network (WAN), the Internet, a mobile network, or a combination thereof). Wearable devices, control systems 220, or any combination thereof may include components of the notification system 200 (e.g., tools / software 208, user / device performance module 215, APIs 217, and applications 226).

[0031] Tools / software 208 include query tool 216 and notification tool 212.

[0032] In some implementations, API 217 enables application 226 to query (via query tool 216) the HMD (or any type of wearable device) to determine whether the current use of the HMD meets a set of performance requirements (e.g., obtained from performance requirement data 212). Determining whether the current use of the HMD meets the set of performance requirements may be applicable to scenarios such as, for example, medical testing, training simulations, high-precision applications, etc. For example, the device's performance requirements may be user-specific, particularly based on the user's eye and / or hand registration, active sensing of the user's eyes relative to the display of the electronic device 105 (e.g., the HMD), etc.

[0033] In some implementations, the query (performed via query tool 216) can be configured to evaluate user-relevant and device-specific factors (via user / device performance module 215 in real time) relative to user-specific or application-specific performance requirements (e.g., FOV, sharpness, distortion, or stimuli in the surroundings) that are being met. For example, it may be necessary to maintain the following application- or user-specific visual / audio parameter target metrics to achieve optimal performance for a given application: (a) FOV metrics, such as minimum acceptable viewing angle; (b) distortion metrics, such as the degree of distortion allowed across the field of view based on the current user positioning and head movement; (c) pixels per degree (PPD) metrics, such as changes in PPD across user gaze, pupil positioning, etc.; (d) chromatic aberration metrics, such as tolerance for color fringing or misalignment; (e) luminance metrics, such as the luminance level required for the application / use; and (f) luminance uniformity metrics, such as across the HMD display. (g) Uniform distribution of brightness; (h) Color accuracy measures, such as tolerance for deviation from a reference color; (i) Color uniformity measures, such as consistency of color reproduction across the field of view (FOV); (j) Sharpness measures, such as the sharpness of displayed details; (k) Contrast measures, such as the ratio of bright to dark areas indicating the dynamic range of the display; (l) Virtual image distance measures, such as the simulated distance from the eye to the perceived image plane; (m) Pupil positioning measures relative to the device, such as the alignment of the user's eye with the optical center of the lens; (d) Gaze angle measures, such as the user's line of sight relative to the display.

[0034] In some specific implementations, dynamic user information can be obtained from sensor 205 in real time to enable performance calculations (for query inputs), such as in particular: (a) pupil localization based on real-time tracking of pupil position relative to the display; (b) the user's gaze direction relative to the display center of the HMD; and (c) interpupillary distance (IPD), such as the user-specific distance between pupils.

[0035] In some implementations, known device characteristics can be obtained from the query input. For example, information associated with the HMD's display and optics, such as display resolution and pixel layout, optical lens stacking parameters (e.g., lens shape, magnification, etc.), device calibration data, etc.

[0036] In some specific implementations, ray tracing models can be used to predict or simulate: (a) light propagation from the display (e.g., pixels) to the user's eye; (b) light propagation through specific areas of lenses / optics; (c) peripheral visibility to ensure that stimuli are displayed correctly within the desired angle; and / or (d) changes in the user's eye positioning (e.g., when the user adjusts the fit of the HMD).

[0037] In some specific implementations, image sensor specifications (e.g., resolution, color accuracy, noise, etc.) and optical specifications (e.g., focal length, field of view, etc.) can be used as query input.

[0038] In some implementations, application 226 can be configured to initiate queries relative to the HMD via API 217 to determine performance requirements. For example, the query may specify: (a) the type of metric (e.g., FOV, sharpness, etc.); (b) an application-specific threshold (e.g., FDA or medical requirements for a given peripheral visual stimulus) and / or (c) user-related thresholds (e.g., ensuring patient-specific PPD, etc.). In response to the query, API 217 may obtain real-time sensor data (e.g., pupil localization, gaze, etc.) and device characteristics such as: (a) current device localization and user eye-tracking data; (b) internal and external camera data for FOV and light leakage characteristics; (c) display settings such as resolution, color profile, etc.; and / or (d) lens attribute data. Similarly, API 217 and user / device performance module 215 can be configured to use a ray tracing model to simulate optical path characteristics to predict the visual outcome of the user's current localization by performing pixel-to-lens mapping, pupil intersection calculation, FOV calculation, PPD determination, etc. Subsequently, each feature can be evaluated relative to application-specific and / or user-related thresholds, for example via a lookup table (LUT) method that pre-maps expected feature / performance values ​​for different pixel regions and gaze positioning. API 217 can then proceed with device-level compensation / instructions. In response to the feature evaluation, API 217 can provide a detailed response indicating whether performance requirements have been met. Similarly, notification tool 214 can provide associated notifications 228, such as, for example, (a) pass / fail indications, such as binary pass / fail status provided for each feature; (b) calculated values ​​of metrics such as FOV, PPD, luminance, etc.; (d) privacy-preserving representations including specified data (e.g., gaze information) for protecting user privacy; and / or (e) guidance on correcting feature failures, such as, for example, “adjust head positioning or device fit to increase FOV.”

[0039] In some implementations, notification frame 200 may be implemented relative to the medical imaging application. For example, notification frame 200 may be enabled to ensure that the user's pupil is centered relative to the lens of the HMD to ensure diagnostic accuracy. In some implementations, associated failures may trigger notification 228 to a supervising practitioner, such as a physician. Similarly, medical imaging applications may require a specific FOV to display peripheral visual stimuli in compliance with FDA regulations, and therefore, the application may be configured to query the HMD to ensure that a minimum (e.g., 90°) FOV is achieved by calculating the amount of display currently visible to the user's eye using ray tracing to account for lens distortion and user alignment. If the minimum FOV is not achieved (e.g., due to incorrect alignment or lens problems), the user may be notified to adjust the alignment or alignment of the HMD.

[0040] In some specific implementations, a notification framework 200 can be implemented relative to the training simulator application, so that FOV and distortion levels are monitored to ensure that if a minimum threshold is not achieved, immersive and accurate simulation cues are provided to the user to adjust the HMD.

[0041] In some implementations, notification tool 214 can be configured to provide direct user notification 228, enabling direct prompting to the user to perform functions such as adjusting the head-mounted device or changing positioning. For example, it can be determined that the field of view (FOV) is too small, and in response, notification tool 214 can suggest repositioning the HMD to better align the pupil with the HMD's display. Similarly, it can be determined that minimum sharpness has not been achieved, and in response, notification tool 214 can recommend tightening the HMD headband to reduce display movement or adjust the user's distance from the display.

[0042] In some implementations, notification tool 214 may be configured to provide external notifications, such as warnings delivered to practitioners or regulators. In some implementations, notification tool may be configured to provide visual guidance to enable, for example, users to self-correct HMD positioning.

[0043] In some implementations, the notification framework 200 can be configured to address privacy and security considerations. For example, a privacy-preserving summary of performance metrics can be used to prevent applications from accessing, for instance, raw user eye-tracking data. Similarly, the notification framework 200 can be configured to allow users to opt-in to performance queries to ensure transparency and control over the shared data.

[0044] Figure 3AAn environment 300 is illustrated, comprising a view 302a containing content 310 provided to a user 302 via an HMD 305. The view 302a includes content 310 (e.g., a bird) rendered such that the current field of view (FOV) 308a prevents the user 302 from fully viewing the content 310 (i.e., performance requirements are not yet met) (e.g., FOV 308a is less than a minimum FOV threshold). For example, portions of the content 310 (such as the bird's wing portion and head) are not viewable within FOV 308a. FOV 308a is provided based on horizontal FOV projections 304a and 314a (between projections 304a and 314a) and vertical FOV projections 316a and 312a (between projections 316a and 312a). In response, a notification frame (e.g., Figure 2 The notification framework 200 is configured (in response to a query) to provide (user 302) a notification indicating that a performance requirement (i.e., FOV requirement) has not yet been met. The notification may additionally include instructions for modifying the operation and / or use / coordination of the HMD 305. In response, user 302 may modify the operation and / or use / coordination of the HMD 305 according to the instructions, thereby enabling user 302 to fully view content 310 (i.e., increase the FOV size), as described below relative to... Figure 3B As described. In some specific implementations, notifications may be sent / shared to another device (e.g., a tablet) that monitors the use of the HMD 305. For example, a patient may use the HMD 305 to perform a medical test (e.g., an eye / vision examination), and the tablet may be used to monitor the test, such that the tablet is configured to alert, for example, a medical practitioner (using the tablet), that the patient is currently outside the permissible performance envelope within the HMD 305.

[0045] Figure 3B Examples include user 302 according to the above relative to Figure 3A The described instructions modify the operation of HMD 305 and / or the environment 300 of view 302b of content 310 provided to user 302 via HMD 305 after use / cooperation. View 302a includes content 310 (e.g., a bird), which is rendered such that the current FOV 308b has been adjusted according to a minimum FOV threshold (in a user-specific manner), thereby allowing user 302 to fully view content 310 (e.g., all parts of content 310 are viewable within FOV 302b). FOV 308b is provided based on horizontal FOV projections 304b and 314b forming a minimum angle (between FOV projections 316b and 312b) and vertical FOV projections 316b and 312b forming a minimum angle (between FOV projections 304b and 314b).

[0046] Figure 3C A baseline FOV pattern 340 is illustrated according to some specific implementations. The baseline FOV pattern 340 incorporates a developer-friendly API pattern that enables the selection of a minimum FOV using predefined predefined zones. For example, the baseline FOV pattern 340 enables the API to: (a) present predefined binocular FOV zones (e.g., zones 1-4); (b) allow developers to select target zones to implement; (c) provide in-head-mounted visualization so developers can view the coverage of each zone; and (d) indicate whether the user's current fit / eye positioning satisfies one of zones 1-4. In some specific implementations, the baseline FOV pattern 340 includes the following attributes: (a) FOV definition: binocular; (b) predefined style: zone-based; (c) communication style: in-head-mounted visualization; and (d) zone threshold: platform-defined.

[0047] Figure 3D An advanced user FOV mode 350 is illustrated according to some specific implementations. Advanced user FOV mode 350 includes a precision API mode that enables developers to define and implement a minimum FOV using explicit geometric constraints. For example, advanced user FOV mode 350 enables an API that allows developers to define the monocular FOV boundary using rays 360 from the pupil. For example, each ray may include a developer-specified range in tangential space, and rays 360 may be configured to form a polygon representing the minimum acceptable FOV. In some implementations, advanced user FOV mode 350 allows evaluation of whether the user's current FOV satisfies the polygon and the results can be provided via a dashboard view. In some implementations, advanced user FOV mode 350 includes the following attributes: (a) FOV definition: monocular; (b) communication style: configured to illustrate the impact of angular requirements on the FOV shape on a developer dashboard; and (c) zone definition: developer-defined rays in tangential space.

[0048] Figure 4 Examples include electrical equipment (such as, for example) Figure 3A and Figure 3B An exemplary ray-tracing model 400 of the optical module of the electrical device 305. In this example, the model 400 of the optical module includes 3D positioning of multiple layers 412, 414, 416 of the optical module, as well as 3D positioning of the display 418 and the eye / viewpoint 410. The model can also model specific content on the display 418, for example, by dividing the model of the display into multiple rectangular sub-regions having different content (e.g., bright or dark) corresponding to the actual content to be displayed on the display.

[0049] Model 400 can be used to model or simulate an optical path. For example, optical path 420 can be modeled as traveling from the modeled display 418 through layers 416 and 414, bouncing back through layers 414 and 416, and then bouncing to reach the modeled eye / viewpoint 410.

[0050] Model 400 enables ray tracing across the lens region. For example, since the lens's distortion and magnification properties can be known at each point, the model allows the system (e.g., Figure 2 The notification system 200) is capable of tracking light rays from each display pixel through a specific point of gaze of the user on the lens to the pupil. For example, by calculating which part of the lens the user is viewing through: (a) the API can be configured to determine whether the user is viewing through the center (sharper area) or the peripheral area (distortion / magnification) of the lens; (b) the API can be configured to calculate how pixel density (e.g., perceived PPD) shifts due to differences in magnification across the lens; and / or (c) can determine that the distortion level is within acceptable limits based on applied criteria.

[0051] Figure 5 This is a block diagram illustrating an example system of user device 500 configured to enable an application to query a wearable device to determine whether the current use of the wearable device meets user / device-specific performance requirements. User device 500 (e.g., a wearable device) may include an input module 502, a user / device performance requirements module 504, an output / display module 506, and a lightweight engine 508.

[0052] In some implementations, the input module 502 is configured to accept input data 505 (e.g., internal or external sensor data from the user equipment 500 and / or external to it, such as image sensors, inertial measurement unit (IMU) sensors, accelerometers, gyroscopes, etc.) to perform performance calculations (for query inputs), such as, in particular: (a) pupil localization based on real-time tracking of the pupil position relative to the display; (b) the user's gaze direction relative to the center of the HMD's display; and (c) interpupillary distance (IPD), such as the user-specific distance between pupils.

[0053] Input 510 from input module 502 may be fed to user / device performance requirements module 504. User / device performance requirements module 504 may include one or more learning-based and / or non-learning-based models for sensing, synthesizing, and inferring information to determine whether the user's current use of the wearable device meets user and / or device-specific performance requirements, and apply rule-based query responses to provide instructions (to the user of the wearable device) for modifying the wearable device. Those skilled in the art will understand that activity identification module 504 may include any suitable number of rule-based processes to generate output 512 based on input 510.

[0054] In some implementations, the user / device performance requirements module 504 can be used to deterministically simulate optical path characteristics using a ray tracing model to predict the visual outcome of the user's current positioning by performing pixel-to-lens mapping, pupil intersection calculation, FOV calculation, PPD determination, etc. Each characteristic can then be evaluated relative to application-specific and / or user-related thresholds, for example via a lookup table (LUT) method that can use defined rules to pre-map the expected characteristic / performance values ​​for different pixel regions and gaze positioning.

[0055] In some implementations, user device 500 may optionally choose to use a lightweight engine 508 instead of user / device performance requirement module 504 to deterministically simulate optical path characteristics using computer vision techniques and / or algorithmic methods, thereby predicting visual outcomes for the user's current positioning. Each feature can then be evaluated, for example, via a lookup table (LUT) method relative to application-specific and / or user-related thresholds, which can use defined rules to pre-map expected feature / performance values ​​for different pixel regions and gaze positioning. Lightweight engine 508 may be a non-learning network.

[0056] In some implementations, the output / display module 506 is configured to accept results from the user / device performance requirement module 504 and / or the lightweight engine 508.

[0057] For example, output from the user / device performance requirements module 504 and / or the lightweight engine 508 is provided to the output / display module 506, which provides the user experience on the wearable device.

[0058] Those skilled in the art will understand that the user / device performance requirements module 504 may include any suitable machine learning model that is well-known or widely available, such as regression techniques, classification techniques, neural networks, and deep learning networks. For example, the user / device performance requirements module 504 may include neural networks such as artificial neural networks (ANNs), convolutional neural networks (CNNs), recurrent neural networks (RNNs), adversarial networks (GANs), reinforcement learning models (RLMs), encoder / decoder networks, and / or transformer-based models (e.g., bidirectional encoder representations from transformers (BERT), generative pre-trained transformers (GPTs), and / or multimodal large language models (LLMs)). Additionally or alternatively, those skilled in the art will understand that the user / device performance requirements module 504 may be any suitable non-learning process, such as rule-based systems, heuristics, decision trees, knowledge-based systems, statistical or stochastic systems, and expert systems.

[0059] In one instance where the user / device performance requirements module 504 is a machine learning-based model, the trainable model determines whether the user's current use of the wearable device meets user- and / or device-specific performance requirements (e.g., visual and / or audio requirements), and if it is determined that the user's current use of the wearable device does not meet user- and / or device-specific performance requirements, then the implementation provides a query response (to the user of the wearable device) with instructions to modify the wearable device.

[0060] In some implementations, the user / device performance requirements module 504 can be trained using both synthetic and non-synthetic data.

[0061] In some implementations, the user / device performance requirements module 504 may be deployed as one or more generative models, wherein content is automatically generated by one or more computers in response to a request to generate content. The automatically generated content may optionally be generated on the device (e.g., at least partially generated by the computer system that received the request to generate content) and / or generated outside the device (e.g., at least partially generated by one or more nearby computers available via a local network or one or more computers available via the Internet). The automatically generated content may optionally include visual content (e.g., images, graphics, and / or video) and / or text content.

[0062] In some implementations, novel, automatically generated content is referred to as generative content (e.g., generative images, generative graphics, generative videos, and / or generative text). Generative content is typically generated based on prompt input 510 to the user / device performance requirement module 504. The input module 502 optionally includes one or more preprocessing steps (e.g., adjusting user-provided prompts, creating system-generated prompts, and / or selecting AI models) to adjust the input before it is used by an artificial intelligence (AI) model to generate an output image. The display module 506 optionally includes one or more postprocessing steps to adjust the output 512 of the user / device performance requirement module 504 (e.g., passing AI model output to different AI models, scaling up, cropping, formatting, and / or adding or removing metadata) before the output 512 of the user / device performance requirement module 504 is used for other purposes (such as being provided to different software processes for further processing or (e.g., visually) presented to the user).

[0063] The prompt input 510 used to generate generative content may include one or more of the following: one or more words (e.g., written or spoken natural language prompts), one or more images, one or more pictures, and / or one or more videos. The generative pre-trained transformer model is an LLM that can efficiently generate novel generative content based on the prompt input 510. In some embodiments, the user / device performance requirement module 504 uses the prompt input 510, which includes text, to generate various generative text, generative audio content, and / or generative visual content. In other embodiments, the user / device performance requirement module 504 uses the prompt input 510, which includes visual content and / or audio content, to generate generative text (e.g., transcriptions of audio and / or descriptions of visual content). In still other embodiments, the user / device performance requirement module 504 uses the prompt input 510, which includes multiple types of content (e.g., text, images, audio, video, and / or other sensor data), to generate generative content. The prompt input 510 may sometimes also include values ​​of one or more parameters indicating the importance of various parts of the prompt. Some input prompts 510 include a set of structured instructions that can be provided to the user / device performance requirements module 504, which includes wording, specified style, relevant context (e.g., starting content and / or one or more examples) and / or roles for the user / device performance requirements module 504.

[0064] Generative content is typically based on prompts, but is not deterministically selected from pre-generated content; rather, it is generated using the prompt as a starting point. In some implementations, pre-existing content (e.g., audio, text, and / or visual content) is used as part of the prompt for creating the generative content (e.g., pre-existing content is used as a starting point for creating the generative content). For example, prompt input 510 may request modifications to visual content to include or exclude content specified by the prompt (e.g., removing identified features from the visual content, adding features described in the prompt to the visual content, changing the visual style of the visual content, and / or creating additional visual elements based on the visual content beyond its spatial or temporal boundaries). In some implementations, a random or pseudo-random seed is used as part of the prompt input 510 for creating the generative content (e.g., random or pseudo-random seed content is used as a starting point for creating the generative content). For example, when generating an image from a diffusion model, random noise patterns are iteratively denoised based on prompt input 510 to generate the image. While a particular type of user / device performance requirement module 504 has been described herein, it should be understood that a variety of different user / device performance requirement modules can be used to generate generative content based on prompts.

[0065] In an instance where the user / device performance requirements module 504 is a non-learning system, the performance requirements module 504 can use a predefined set of rules or a predefined structure to make decisions based on the input seen by the process. For example, the user / device performance requirements module 504 can be used to guide a deterministic method to determine whether the user's current use of device 500 (e.g., HMD) meets performance requirements associated with, for example, user-related / application-specific (e.g., medical imaging applications) display requirements, and if the performance requirements are not yet met, instructions can be issued to change device 500 and / or how / wearing the device.

[0066] Some implementations described herein may include the use of learning-based and / or non-learning-based processes. This use may include collecting, preprocessing, encoding, labeling, organizing, analyzing, recommending, and / or generating data. Entities that collect, share, and / or otherwise utilize user data should provide transparency and / or obtain user consent when collecting such data. This disclosure recognizes that the use of data in rule-based or machine learning (ML)-based processes can be used to benefit users. For example, the data can be used to train models that can be deployed to improve the performance, accuracy, and / or functionality of applications and / or services. Therefore, the use of data enables rule-based processes or ML to adapt and / or optimize operations, thereby providing a more personalized, efficient, and / or enhanced user experience. Such adaptation and / or optimization may include customizing content, recommendations, and / or interactions for individual users, as well as simplifying processes and / or implementing more intuitive interfaces. This disclosure also envisions further beneficial uses of data in rule-based processes.

[0067] This disclosure envisions that, in some implementations, data used by rule-based processes may be used to include publicly available data. To protect user privacy, data may be anonymized, aggregated, and / or otherwise processed to remove or, where possible, limit any individual identification. As discussed herein, entities that collect, share, and / or otherwise utilize such data should obtain user consent before collecting such data and / or provide transparency when collecting such data. Furthermore, this disclosure envisions that entities responsible for the use of data (including, but not limited to, data used in connection with rule-based processes) should strive to comply with robust privacy policies and / or privacy measures.

[0068] For example, such entities may implement and consistently follow strategies and measures deemed to meet or exceed industry standards and regulatory requirements for developing and / or training ML-based processes. In doing so, efforts should be made to ensure that all intellectual property and privacy considerations are maintained. Training should include measures to protect training data (such as personal information) by providing adequate safeguards against misuse or exploitation. Such strategies and measures should cover all phases of process development, training, and use, including data collection, data preparation, model training, model evaluation, model deployment, and ongoing monitoring and maintenance. Transparency and measurability should always be maintained. Such policies should be readily accessible to users and should be updated as data collection and / or use change. User data should be collected for the entity's lawful and reasonable use and not shared or sold outside of these lawful uses. Furthermore, such collection and sharing should be conducted in a transparent manner to users and / or with their informed consent. Additionally, such entities should consider taking any necessary steps to defend and safeguard access to such data and ensure that others with access to the data comply with their privacy policies and processes. Furthermore, such entities should be subject to appropriate third-party assessments for transparency purposes to demonstrate their compliance with widely accepted privacy policies and practices. In addition, policies and / or practices should be appropriate for the specific types of data collected and / or accessed, and tailored to specific use cases and applicable laws and standards, including jurisdiction-specific considerations.

[0069] In some implementations, the ML-based process may utilize a model that can be trained (e.g., in a supervised or unsupervised learning manner) using a variety of training data, including data collected using the user's device. This use of the user-collected data may be limited to operations on the user's device. For example, model training may be performed locally on the user's device, so that no part of the data is transmitted to another device. In other implementations, model training may be performed using one or more other devices besides the user's device (e.g., a server), but in a privacy-preserving manner, such as through multi-party computation, encrypted by secretly sharing data, or other means, ensuring that user data is not leaked to these other devices.

[0070] In some implementations, the trained model can be centrally stored on the user device or on multiple devices, as is the case in federated learning. This distributed storage can also be done in a privacy-preserving manner, for example, through encryption, where each piece of data is fragmented so that the data cannot be reassembled or used by a device alone (i.e., only in conjunction with another device) or only by the user device. In this way, user or device behavior patterns are not leaked, while leveraging the increased computing resources of other devices to train and execute the ML model. Therefore, user-collected data can be protected. In some specific implementations, data from multiple devices can be combined in a privacy-preserving manner to train the ML model.

[0071] In some implementations, this disclosure envisions that data used for the user / device performance requirements module 504 may be kept strictly separate from the platform on which the user / device performance requirements module 504 is deployed and / or used for user interaction and / or data processing. In such implementations, data used for offline training of the user / device performance requirements module 504 may be maintained in a secure data repository with restricted access and / or not retained for longer than necessary for the training purpose. In some implementations, the user / device performance requirements module 504 may utilize a local memory cache to temporarily store data during a user session. The local memory cache can be used to improve the performance of rule-based processes. However, to protect user privacy, data stored in the local memory cache may be erased after the user session ends. Any temporary cached data used for online learning or inference may be quickly erased after processing. All data collection, transfer, and / or storage should be performed using industry-standard encryption and / or secure communication.

[0072] In some implementations, as described above, techniques such as federated learning, differential privacy, secure hardware components, homomorphic encryption and / or multi-party computation, and others, can be used to further protect personal information data during rule-based ML training and / or use. The user / device performance requirement module 504 should be monitored for changes in the underlying data distribution, such as conceptual drift or data skew that may reduce the performance of the user / device performance requirement module 504 over time.

[0073] In some implementations, a combination of offline and online training is used to train the user / device performance requirement module 504. Offline training can use a carefully selected dataset to establish a baseline model performance, while online training allows the user / device performance requirement module 504 to continuously adapt and / or improve. This disclosure recognizes the importance of maintaining strict data management measures throughout this process to ensure user privacy is protected.

[0074] In some implementations, the User / Device Performance Requirements Module 504 process may be designed with safeguards to maintain compliance with the original intended purpose, even if the User / Device Performance Requirements Module 504 is adapted based on new data. Any significant changes to the data collection and / or application used by the User / Device Performance Requirements Module 504 may (and in some cases should) be transparently communicated to affected stakeholders, and / or include obtaining user consent when the manner of collecting and / or utilizing user data changes.

[0075] Regardless of the foregoing, this disclosure also contemplates implementations that allow users to selectively restrict and / or block the use and / or access to data. That is, this disclosure contemplates that hardware and / or software elements may be provided to prevent or block access to data. For example, with respect to some services, the inventive technology should be configured to allow users to opt-in or opt-out to participate in data collection at any time during or after service registration. In another example, the inventive technology should be configured to allow users to opt out of providing certain data used for training the user / device performance requirements module 504 and / or as input during the inference phase of such systems. In yet another example, the inventive technology should be configured to allow users to choose to limit the length of time data is retained or to completely prohibit rule-based processes from using their data. In addition to providing "opt-in" and "opt-out" options, this disclosure also contemplates providing notifications related to access to or use of personal information. For example, users may be notified when their data is input into the user / device performance requirements module 504 for training or inference purposes, and / or reminded when the user / device performance requirements module 504 generates output or makes decisions based on their data.

[0076] This disclosure recognizes that the user / device performance requirements module 504 should incorporate explicit limitations and / or oversight to mitigate risks that may still exist even when such systems have been designed, developed, and / or operated in accordance with industry best practices and standards. For example, outputs may be generated that could be considered erroneous, harmful, offensive, and / or biased; such outputs may not necessarily reflect the opinions or positions of the entities that developed or deployed these systems. Furthermore, in some cases, references to or non-references to third-party products and / or services in these outputs should not be construed as an endorsement or association by the entity providing the rules-based process with the third-party products and / or services. The generated content may be filtered to remove potentially inappropriate or dangerous material before being presented to the user, while maintaining the ability for human oversight and / or to cover or correct erroneous or undesirable outputs as a safeguard.

[0077] This disclosure also envisions that users of the User / Device Performance Requirements Module 504 should avoid using the Service in any way that infringes upon, misappropriates, or violates the rights of any party. Furthermore, the User / Device Performance Requirements Module 504 should not be used for any illegal or unlawful activities, nor should it be used to develop any application or use case that will commit or assist in the committing of a crime or other tortious, illegal, or unlawful act, including misinformation, false information, false statements (e.g., deepfakes), deception, impersonation, and propaganda. The User / Device Performance Requirements Module 504 should not violate, misappropriate, or infringe upon any party's copyright, trademark, privacy and portrait rights, trade secrets, patents, or other proprietary or statutory rights, and should be appropriately attributed to the content as needed. Additionally, the User / Device Performance Requirements Module 504 should not interfere with any security, digital signature, digital rights management, content protection, verification, or authentication mechanisms. The User / Device Performance Requirements Module 504 should not incorrectly represent machine-generated output as human-generated.

[0078] Figure 6 This is a flowchart illustrating an exemplary method 600, based on some specific implementations, that enables an application to query a wearable device (such as an HMD) to determine whether a user's current use of the HMD meets user- and / or device-specific performance requirements. In some specific implementations, method 600 is represented by a wearable device (such as...) Figure 1 The wearable device 105 110) performs this function. In some specific implementations, the wearable device has a screen for displaying images and / or a screen for viewing stereoscopic images, such as a head-mounted display (HMD, such as, for example... Figure 1 Device 105), OST-AR device, etc. In some embodiments, method 600 is executed by processing logic (including hardware, firmware, software, or a combination thereof). In some embodiments, method 600 is executed by a processor that executes code stored in a non-transitory computer-readable medium (e.g., memory). Each block in method 600 can be enabled and executed in any order.

[0079] At box 602, method 600 receives a request (to or from an application) corresponding to user-specific performance requirements that the wearable electronic device needs to perform functions when the wearable electronic device is worn by a user. For example, API 217 may enable application 226 to query the HMD to determine whether the current use of the HMD satisfies the requirements relative to the user's needs. Figure 2 The set of performance requirements described.

[0080] In some specific implementations, a request may correspond to a performance requirement that a wearable electronic device meets relative to the functional requirements (e.g., display requirements) of the electronic device.

[0081] In some specific implementations, a request may correspond to a wearable electronic device meeting performance requirements relative to legal or regulatory requirements (e.g., FDA regulations).

[0082] In some specific implementations, the request may correspond to performance requirements of the wearable electronic device that meet both user-related requirements (e.g., the user's positioning relative to the wearable electronic device) and application-specific requirements (e.g., the field of view (FOV) required by the application). For example, the effective performance of the device may be user-specific, particularly based on the registration of the user's eyes and / or hands, active sensing of the user's eyes relative to the display of the electronic device (e.g., the user's FOV provided by the HMD), etc.

[0083] In some specific implementations, user-related and application-specific requirements are related to the FOV, distortion parameters, color difference parameters, sharpness parameters, color performance parameters, etc. required for the use of the application.

[0084] At box 604, method 600 obtains device performance data corresponding to user-specific capabilities of the device when the wearable electronic device is worn by a user. For example, as relative to Figure 1 and Figure 2 The described parameters are FOV, distortion, PPD, chromatic aberration, brightness, brightness uniformity, color, color uniformity, sharpness, contrast, virtual image distance, and pupil positioning relative to the wearable electronic device worn by user 102.

[0085] In some implementations, device performance data can provide location data related to the user's current location relative to the electronic device.

[0086] In some specific implementations, such as relative to Figure 4 As described, the location data is determined by using a model (e.g., ray tracing model 400) to simulate how much light will propagate from the display of a wearable electronic device to at least one of the user's eyes (e.g., the pupil).

[0087] In some implementations, device performance data provides information about the user, such as whether the user is wearing glasses.

[0088] In some specific implementations, device performance data is used to generate simulation data based on current device characteristics, current user characteristics, or the locational relationship between the electronic device and the user.

[0089] At box 606, method 600 provides a response to the request based on performance requirements and device performance data. The response can provide or implement a determination of whether the wearable electronic device will meet the user-specific performance requirements required for the application to perform its functions when worn by a user. For example, API 217 can provide a detailed response indicating whether the performance requirements have been met, and notification tool 214 can provide associated notifications 228, such as, for example, relative to… Figure 2 The described pass / fail indication.

[0090] In some implementations, the response provides a graphical indicator (e.g., pass / fail, illumination, etc.) that presents a determination of whether the wearable electronic device will meet the performance requirements.

[0091] In some specific implementations, the response provides a definite value related to the current performance capabilities of the wearable electronic device.

[0092] In some implementations, the response provides a representation of whether the minimum performance parameters of the wearable device are usable by the user, without providing user characteristics related to the actual performance parameters of the wearable device. In some implementations, performance parameters are, for example, field of view (FOV) parameters, distortion parameters, chromatic aberration parameters, sharpness parameters, color performance parameters, etc.

[0093] In some implementations, the response is provided to the application to provide notifications to the user.

[0094] In some implementations, the response is provided to the application to prevent the application from being used on the electronic device.

[0095] In some implementations, the response is provided to the application to allow the application to be used on the wearable electronic device.

[0096] In some implementations, the response to a request is a query received via an application programming interface (API).

[0097] In some implementations, method 600 is performed at a first computer system (e.g., an HMD, such as the electronic device 105 described herein) via a system process (e.g., an operating system process, a server system process, or another system-level service), which is different from one or more applications executed and / or installed on the first computer system.

[0098] In some implementations, method 600 is executed at the first computer system by an application different from the system process. In some implementations, the application's instructions, when executed, control the first computer system to execute method 600 by invoking an application programming interface (API) provided by the system process. In some implementations, the application executes at least a portion of method 600 without invoking the API.

[0099] Specific embodiments within the scope of this disclosure may be implemented, in whole or in part, using a tangible computer-readable storage medium (or a plurality of tangible computer-readable storage media of one or more types) that encodes one or more computer-readable instructions. It should be understood that computer-executable instructions may be organized in any format, including applications, components, processes, software, software modules, and / or components.

[0100] Specific embodiments within the scope of this disclosure include computer-readable storage media encoding instructions organized as an application that, when executed by one or more processing units, controls the execution of an electronic device. Figure 6 The methods and / or one or more other processes and / or methods described herein.

[0101] It should be recognized that an application can be any suitable type of application, including one or more of the following: query applications, field of view (FOV) applications, browser applications, applications used as execution environments for plugins, widgets, or other applications, fitness applications, health applications, digital payment applications, media applications, social networking applications, messaging applications, and / or map applications. In some implementations, the application is configured to support the operation of the HMD, including display testing, calibration, content rendering, accessibility modes, or device control functions related to user-related display performance operations.

[0102] In some embodiments, the application is pre-installed on the first computer system at the time of purchase (e.g., a first-party application). In other embodiments, the application is provided to the first computer system via operating system update files (e.g., a first-party application). In other embodiments, the application is provided via an app store. In some specific embodiments, the app store is pre-installed on the first computer system at the time of purchase (e.g., a first-party app store) and allows the download of one or more applications. In some embodiments, the app store is a third-party app store (e.g., an app store provided by another device, downloaded via a network, and / or read from a storage device). In some embodiments, the application is a third-party application (e.g., an application provided by an app store, downloaded via a network, and / or read from a storage device). In some embodiments, the application controls the first computer system to execute method 600 by calling an application programming interface (API) provided by a system process using one or more parameters.

[0103] In some implementations, at least one API is a software module that provides an interface (e.g., a set of computer-readable instructions) that allows different sets of instructions (e.g., API call instructions of an application) to access and use one or more functions, methods, procedures, data structures, classes, and / or other services provided by a set of implementation instructions of system procedures. The API may define one or more parameters passed between API call instructions and implementation instructions.

[0104] As described above, in some implementations, an application controls the execution of method 600 of a first computer system by invoking an application programming interface (API) provided by a system procedure using one or more parameters. For example, this could involve an application using a first API to provide a request to determine whether the current usage (of the HMD) meets a set of performance requirements (as described in box 602), and using a second API to provide a response to the request based on the set of performance requirements and device performance data (e.g., as described in box 606).

[0105] In some implementations, applications use API information to obtain information from the device's hardware components, the device's software modules (e.g., instruction sets), and / or external hardware components (e.g., peripherals, accessory devices, servers, etc.). In some implementations, the information obtained includes user information, environmental information, electronic device status information, hardware information, motion information, medical testing information, real-time sensor information, training simulation information, high-precision application information, FOV information, or any other type of application-related information.

[0106] In some implementations, one or more steps of method 600 are performed in response to a trigger. In some implementations, the trigger includes the detection of an event, a notification received from the system, user input, and / or a response to a call to an API provided by the system.

[0107] In some implementation schemes, Figure 6 One or more steps of the method involve calling the API using one or more parameters defined by the API. In some implementations, one or more parameters include constants, keys, data structures, objects, object classes, variables, data types, pointers, arrays, lists, or pointers to functions or methods and / or references to data or other items to be passed via the API in another way.

[0108] Some implementations utilize APIs as software modules comprising a set of one or more computer-executable instructions. In some implementations, the API provides an interface that allows different sets of instructions (e.g., API call instructions) to access and / or use one or more functions, methods, procedures, data structures, classes, and / or other services provided by the system's implementation instructions. For example, API call instructions can access features of the implementation instructions through one or more API calls or references exposed by the API (e.g., embodied by function or method calls), and can pass data and / or control information via one or more parameters using the API calls or references. In some implementations, the API allows applications to use services provided by software development kit (SDK) libraries. In other implementations, applications combine calls to functions or methods provided by the SDK library and those provided by the API, or use data types or objects defined in the SDK library and provided by the API. In some implementations, API call instructions make API calls via the API to access and use features of the implementation instructions specified by the API. In such implementations, the implementation instructions can return a value to the API call instructions via the API in response to the API call. This value can report to the application the capabilities or status of the device's hardware components (e.g., comparative information), including those capabilities or statuses related to aspects such as input capabilities and status, output capabilities and status, processing capabilities, power status, storage capacity and status, and / or communication capabilities. In some implementations, the API is implemented in part by firmware, microcode, or other low-level logic executed in part on the hardware components.

[0109] In some implementations, the API allows the developer of the API calling instructions (which may be a third-party developer) to utilize features provided by the implementation instructions. In such implementations, there may be one or more sets of API calling instructions that communicate with the implementation instructions. In some implementations, the API allows multiple sets of API calling instructions written in different programming languages ​​to communicate with the implementation instructions (e.g., the API may include features for translating calls and returns between the implementation instructions and the API calling instructions), while the API is implemented in a specific programming language. In some implementations, the API calling instructions call APIs from different providers, such as a set of APIs from an OS provider, another set of APIs from a plugin provider, and / or another set of APIs from another provider (e.g., a software library provider) or the creator of another set of APIs.

[0110] In some implementations, the execution instructions respond to an API call from an API call instruction by returning a value via the API. While the API defines the syntax and result of the API call (e.g., how to reference the API call and what the API call can do), the API may not reveal how the implementation instructions perform the function specified by the API call. Various API calls can be transmitted via one or more application programming interfaces between the API call instruction and the implementation instructions. Transmitting API calls may include issuing, initiating, referencing, calling, receiving, returning, and / or responding to function calls or messages. In other words, transmission can describe the action performed by either the API call instruction or the implementation instructions. In some implementations, the API function call or other reference transmits and / or receives one or more parameters via a parameter list or other structure.

[0111] In some implementations, implementation instructions provide more than one API, each API providing a different view or aspect of the functionality implemented by the implementation instructions. For example, one API of the implementation instructions may provide a first set of functions and be exposed to third-party developers, while another API of the implementation instructions may be hidden (e.g., not exposed) and provide a subset of the first set of functions, and also provide another set of functions, such as test or debug functions not in the first set of functions. In some implementations, implementation instructions call one or more other components via lower-level APIs, and are therefore both a set of API call instructions and a set of implementation instructions. It should be recognized that implementation instructions may include additional functions, methods, classes, data structures, and / or other features not specified through the API and not available to the API call instructions. Additionally, it should be recognized that API call instructions may be on the same system as the implementation instructions, or may be remotely located and accessed via a network using the API. In some implementations, implementation instructions, APIs, and / or API call instructions are stored in a machine-readable medium, which includes any mechanism for storing information in a machine-readable form (e.g., a computer or other data processing system). For example, machine-readable media may include disks, optical disks, random access memory; read-only memory and / or flash memory devices.

[0112] Figure 7 This is a block diagram of example device 700. Device 700 illustrates a device used for... Figure 1Exemplary device configurations of electronic devices 105 and 110. Although certain specific features are illustrated, those skilled in the art will understand from this disclosure that various other features are not illustrated for the sake of brevity and to avoid obscuring more relevant aspects of the specific embodiments disclosed herein. Therefore, as a non-limiting example, in some specific implementations, device 700 includes one or more processing units 702 (e.g., microprocessors, ASICs, FPGAs, GPUs, CPUs, and / or processing cores, etc.), one or more input / output (I / O) devices and sensors 706, one or more communication interfaces 708 (e.g., USB, Firewire, Thunderbolt, IEEE 802.3x, IEEE 802.11x, IEEE 802.16x, GSM, CDMA, TDMA, GPS, IR, Bluetooth, ZigBee, SPI, I2C, and / or similar types of interfaces), one or more programming (e.g., I / O) interfaces 710, one or more displays 712, one or more internal and / or external image sensor systems 714, memory 720, and one or more communication buses 704 for interconnecting these components and various other components.

[0113] In some embodiments, one or more communication buses 704 include circuitry for interconnecting system components and controlling communication between system components. In some embodiments, one or more I / O devices and sensors 706 include at least one of the following: an inertial measurement unit (IMU), an accelerometer, a magnetometer, a gyroscope, a thermometer, one or more physiological sensors (e.g., a blood pressure monitor, a heart rate monitor, a blood oxygen sensor, a blood glucose sensor, etc.), one or more microphones, one or more speakers, a haptic engine, one or more depth sensors (e.g., structured light, time-of-flight, etc.), etc.

[0114] In some embodiments, one or more displays 712 are configured to present a view of a physical or graphical environment to a user. In some embodiments, one or more displays 712 are configured to present content to a user (determined based on the user's determined user / object position within the physical environment). In some embodiments, one or more displays 712 correspond to holographic, digital light processing (DLP), liquid crystal display (LCD), liquid crystal on silicon (LCoS), organic light-emitting field-effect transistor (OLET), organic light-emitting diode (OLED), surface-conducting electron emission display (SED), field emission display (FED), quantum dot light-emitting diode (QD-LED), microelectromechanical systems (MEMS), and / or similar display types. In some embodiments, one or more displays 712 correspond to waveguide displays such as diffraction, reflection, polarization, and holography. In one example, device 700 includes a single display. In another example, device 700 includes displays for each of the user's eyes.

[0115] In some embodiments, one or more image sensor systems 714 are configured to acquire image data corresponding to at least a portion of the physical environment 105. For example, one or more image sensor systems 714 include one or more RGB cameras (e.g., having a complementary metal-oxide-semiconductor (CMOS) image sensor or a charge-coupled device (CCD) image sensor), monochrome cameras, IR cameras, depth cameras, event-based cameras, etc. In various embodiments, one or more image sensor systems 714 also include an illumination source emitting light, such as a flash. In various embodiments, one or more image sensor systems 714 also include an on-camera image signal processor (ISP) configured to perform multiple processing operations on the image data.

[0116] In some specific implementations, sensor data can be obtained from devices (e.g., Figure 1The devices 105 and 110 acquire the sensor data during a scan of the room's physical environment. The sensor data may include a 3D point cloud and a sequence of 2D images corresponding to views of the room captured during the scan. In some embodiments, the sensor data includes image data (e.g., from an RGB camera), depth data (e.g., depth images from a depth camera), ambient light sensor data (e.g., from an ambient light sensor), and / or motion data from one or more motion sensors (e.g., accelerometers, gyroscopes, IMUs, etc.). In some embodiments, the sensor data includes visual inertial odometry (VIO) data determined based on the image data. The 3D point cloud can provide semantic information about one or more elements of the room. The 3D point cloud can provide information about the location and appearance of surface portions within the physical environment. In some embodiments, the 3D point cloud is acquired over time (e.g., during a scan of the room) and can be updated, with updated versions of the 3D point cloud obtained over time. For example, when the 3D representation is updated / adjusted over time (e.g., when a user scans a room), the 3D representation can be obtained (and analyzed / processed).

[0117] In some embodiments, sensor data may be positioning information, and some embodiments include VIO (Vehicle Identification and Odometry) to determine equivalent odometry information to estimate travel distance using sequential camera images (e.g., light intensity image data) and motion data (e.g., acquired from an IMU / motion sensor). Alternatively, some embodiments of this disclosure may include a Simultaneous Localization and Mapping (SLAM) system (e.g., a positioning sensor). This SLAM system may include a GPS-independent, multi-dimensional (e.g., 3D) laser scanning and range measurement system that provides real-time simultaneous localization and mapping. This SLAM system can generate and manage highly accurate point cloud data produced by reflections from laser scans of objects in the environment. Accurately tracking the movement of any points in the point cloud over time allows the SLAM system to use points in the point cloud as reference points for its location, maintaining an accurate understanding of its position and orientation as it travels through the environment.

[0118] In some embodiments, device 700 includes an eye-tracking system for detecting eye positioning and eye movement (e.g., eye gaze detection). For example, the eye-tracking system may include one or more infrared (IR) light-emitting diodes (LEDs), an eye-tracking camera (e.g., a near-infrared (NIR) camera), and an illumination source (e.g., an NIR light source) that emits light (e.g., NIR light) towards the user's eyes. Furthermore, the illumination source of device 700 may emit NIR light to illuminate the user's eyes, and the NIR camera may capture images of the user's eyes. In some embodiments, the images captured by the eye-tracking system may be analyzed to detect the positioning and movement of the user's eyes, or to detect other information about the eyes such as pupil dilation or pupil diameter. Furthermore, the gaze point estimated from the eye-tracking images enables gaze-based interaction with content displayed on a near-eye display of device 700.

[0119] Memory 720 includes high-speed random access memory, such as DRAM, SRAM, DDR RAM, or other random access solid-state memory devices. In some embodiments, memory 720 includes non-volatile memory, such as one or more disk storage devices, optical disk storage devices, flash memory devices, or other non-volatile solid-state storage devices. Memory 720 optionally includes one or more storage devices remotely located to one or more processing units 702. Memory 720 includes a non-transitory computer-readable storage medium.

[0120] In some embodiments, memory 720 or a non-transitory computer-readable storage medium of memory 720 stores an optional operating system 730 and one or more instruction sets 740. Operating system 730 includes procedures for handling various basic system services and for performing hardware-related tasks. In some embodiments, instruction set 740 includes executable software defined by binary information stored in charge form. In some embodiments, instruction set 740 is software executable by one or more processing units 702 to perform one or more of the techniques described herein.

[0121] Instruction set 740 includes performance requirement instruction set 742 and request / response instruction set 744. Instruction set 740 can be represented as a single software executable file or multiple software executable files.

[0122] The performance requirement instruction set 742 is configured with instructions executable by the processor to receive requests, such as queries received via an API, to determine whether a wearable electronic device meets the performance requirements required by an application to perform functions when the wearable electronic device is worn by a user.

[0123] The request-response instruction set 744 is configured with instructions that can be executed by the processor to provide a response to the request based on performance requirements and device performance data.

[0124] Although instruction set 740 is shown as residing on a single device, it should be understood that in other specific implementations, any combination of elements may reside in separate computing devices. Furthermore, Figure 7 This is intended more as a functional description of various features present in a particular specific implementation than as a structural diagram of the specific implementation described herein. As will be appreciated by those skilled in the art, the items shown individually can be combined, and some items can be separated. The actual number of instruction sets and how features are allocated therein will vary depending on the specific implementation and may depend in part on the specific combination of hardware, software, and / or firmware chosen for that particular implementation.

[0125] Specific embodiments within the scope of this disclosure may be implemented, in whole or in part, using a tangible computer-readable storage medium (or a plurality of tangible computer-readable storage media of one or more types) that encodes one or more computer-readable instructions. It should be understood that computer-executable instructions may be organized in any suitable format, including applications, components, processes, software, software modules, and / or software components.

[0126] Specific embodiments within the scope of this disclosure include computer-readable storage media encoding instructions organized as an application (e.g., instruction set 740) that, when executed by one or more processing units (e.g., CPU 702 of device 700), control electronic devices (e.g., device 700 and / or device 105). Figure 6 The methods and / or one or more other processes and / or methods described herein.

[0127] It should be recognized that instruction set 740 can be any suitable type of application. For example, instruction set 740 may include one or more of the following: browser applications; applications used as execution environments for plugins, widgets, or other applications; fitness applications; device-specific performance requirement applications, health or medical applications; digital payment applications; media applications; social networking applications; messaging applications; map applications; and / or HMD-related applications used for display testing, calibration, rendering control, querying, providing FOV modes, or accessibility optimization. In some embodiments, instruction set 740 is pre-installed on device 700 at the time of purchase (e.g., a first-party application). In other embodiments, instruction set 740 is provided to device 700 via operating system update files (e.g., a first-party or second-party application). In other embodiments, instruction set 740 is provided via an app store. In some embodiments, the app store is pre-installed on device 700 at the time of purchase (e.g., a first-party app store). In other embodiments, the app store is a third-party app store (e.g., provided by another entity, downloaded via a network, and / or read from a storage device).

[0128] refer to Figure 8A , ( Figure 7 The instruction set 740 obtains information at step 810. In some embodiments, at step 810, information is obtained from at least one hardware component of the device (e.g., Figure 7 Information is obtained from one or more I / O devices and sensors 706, one or more displays 712, and / or one or more image sensor systems 714 of device 700. In some embodiments, at step 810, information is obtained from at least one software module (e.g., a set of instructions stored in memory 720 and executable by processing unit 702). In some embodiments, at step 810, information is obtained from at least one hardware component external to the device (e.g., peripheral devices, accessory devices, calibration instruments, servers, etc.). In some embodiments, the information obtained at step 810 includes FOV information, query information, performance requirement information, location information, time information, notification information, user information, environmental information, electronic device status information, weather information, media information, historical information, event information, hardware information, and / or motion information. In some embodiments, in response to obtaining information at step 810 and / or thereafter, at step 820, instruction set 740 provides information to the system.

[0129] In some implementations, the system is an operating system hosted on device 700 (e.g., an operating system 730 stored in memory 720). In some implementations, the system is implemented on an external device (e.g., a server, peripheral device, accessory, personal computing device, etc.) that includes the operating system and / or system services.

[0130] refer to Figure 8B In step 830, instruction set 740 obtains information. In some embodiments, the information obtained at step 830 includes FOV information, query information, performance requirement information, location information, time information, notification information, user information, environmental information, electronic device status information, weather information, media information, historical information, event information, hardware information, and / or motion information. In response to obtaining information at step 830 and / or thereafter, at step 840, instruction set 740 performs an operation based on the information.

[0131] In some implementations, the operations performed at step 840 include: providing notifications based on information; delivering messages based on information; displaying information; controlling the user interface of a fitness application based on information; controlling the user interface of a health application based on information; controlling focus mode based on information; setting reminders based on information; adding calendar entries based on information; controlling display modes based on information (e.g., dark mode or light mode rendering); repositioning displayed content within the field of view based on information; adjusting rendering parameters; enabling FOV mode based on the Visual Fidelity API, performing queries, determining performance requirements, and / or initiating operations that affect HMD display output (e.g., FOV, brightness modulation, contrast optimization, or optical attenuation control) based on information.

[0132] In some implementations, execution is performed in response to a trigger. Figure 8A Methods and / or Figure 8B The method involves one or more steps. In some implementations, triggering includes event detection, notifications received from the operating system 730, user input, and / or responses to calls to APIs provided by the operating system 730.

[0133] In some implementations, when the instructions of instruction set 740 are executed, control device 700 and / or device 105 execute by calling application programming interfaces (APIs) provided by operating system 1330 and / or another system service. Figure 8A Methods and / or Figure 8B The method. In some implementations, instruction set 740 executes without invoking such APIs. Figure 8A Methods and / or Figure 8B At least a part of the method.

[0134] In some implementation schemes, Figure 8A Methods and / or Figure 8BOne or more steps of the method involve invoking the API using one or more parameters defined by the API. In some implementations, one or more parameters include constants, keys, data structures, objects, object classes, variables, data types, pointers, arrays, lists, pointers to functions or methods, and / or references to data or other items to be passed via the API in another manner.

[0135] In some embodiments, instruction set 740 includes application implementation instructions and API call instructions stored as part of instruction set 740 in memory 720 and executable by processing unit 702. In some embodiments, the application implementation instructions correspond to one or more operations performed by instruction set 740, including operations for adjusting rendering parameters, enabling FOV mode based on visual fidelity API, performing queries, determining performance requirements, generating or selecting brightness modes, obtaining photometric or sensor measurements, generating contrast maps, estimating optical scattering and / or light curtain brightness contributions, and determining display-control actions based on measured or predicted contrast changes. In some embodiments, API call instructions enable communication with operating system 730 and / or other system services.

[0136] In some implementations, the API provides an interface that allows instruction set 740 to access and / or use one or more functions, methods, procedures, data structures, classes, and / or services provided by operating system 730 and / or other system software. For example, instruction set 740 may call the API to obtain sensor data, query device status, control user interface elements, modify rendering parameters, request display mode changes, or provide contrast map information for system-level display optimization. In some implementations, return values ​​from the API indicate the capabilities or status of hardware components, including input capabilities and status, output capabilities and status, processing capabilities, power status, storage capacity and status, and / or communication capabilities.

[0137] Examples of such APIs may include one or more of the following: query API, FOV API, pairing API, device detection API, payment API, user interface API, location detection API, map API, health sensor API, sensor API, messaging API, push notification API, streaming API, collaboration API, video conferencing API, app store API, advertising service API, web browser API, transportation API, networking API, Wi-Fi API, Bluetooth API, NFC API, UWB API, fitness API, smart home API, contact transfer API, photo API, camera API, and / or image processing API. In some implementations, the sensor API provides access to raw sensor data and / or data derived from raw sensor data, including temperature data, image data, video data, audio data, heart rate data, IMU data, LiDAR data, location data, GPS data, camera data, ambient light data, and / or eye-tracking data.

[0138] In some implementations, system software (e.g., operating system 730 and / or other system services) performs an operation in response to receiving an API call from instruction set 740 and provides an API response as a result of processing the API call. While the API may define the syntax and result of the API call (e.g., how to reference the API call and what the API call can do), the API may not reveal how the system software performs the function specified by the API call. In some implementations, operating system 1330, system services, and / or applications 1360 are stored in a machine-readable medium, which includes any mechanism for storing information in a machine-readable form, including disks, optical disks, RAM, ROM, and / or flash memory devices.

[0139] In some implementations, exemplary APIs provided by the operating system 730 and / or associated system services include one or more of the following: query API, FOV API, pairing API (e.g., for establishing a secure connection with an accessory device), device detection API (e.g., for locating nearby electronic devices such as media devices or smartphones), payment API, user interface API (e.g., a UIKit-type framework for generating graphical user interfaces), location detection API, map API, health sensor API, general sensor API, messaging API, push notification API, streaming API, collaboration API, video conferencing API, app store API, advertising service API, web browser API (e.g., a WebKit-type API), transportation API, networking API, Wi-Fi API, Bluetooth API, NFC API, UWB API, fitness API, smart home API, contact transfer API, photo API, camera API, and / or image processing API.

[0140] In some implementations, one or more API definitions provided by the operating system 730 can be accessed via API call instructions of the instruction set 740. The definition of the API call may specify one or more call parameters, including, for example, authentication credentials, device identifiers, sensor configuration parameters, display configuration parameters, environmental or context metadata, user preference data, calibration inputs, timing parameters, rendering control variables, communication protocol identifiers, data format specifications, or other structured inputs suitable for calling system services.

[0141] In some implementations, the API call response provided to the instruction set 740 includes one or more response elements, such as processed sensor data, device status information, capability indicators, confirmation of the requested operation, calibration results, display optimization parameters, rendering control output, diagnostic information, error codes, or derived analysis results (e.g., contrast metrics, brightness characteristics, or environmental context determination). Such responses can be used by the instruction set 740 to adapt device behavior, refine display output, or initiate subsequent processing operations.

[0142] In some implementations, the set of implementation instructions corresponding to operating system 730 and / or other system services includes a system software module comprising computer-readable instructions configured to perform operations in response to a received API call. The implementation instructions may generate an API response based on the processing of the API call. In some implementations, the implementation instructions are stored within device 700 and executed locally. In other implementations, the implementation instructions reside on a separate electronic device (e.g., a server, accessory device, or distributed computing system) communicatively coupled to device 700 and configured to provide system services accessible via an API.

[0143] Those skilled in the art will understand that well-known systems, methods, components, devices, and circuits have not been described exhaustively so as not to obscure more relevant aspects of the specific embodiments of the examples described herein. Furthermore, other effective aspects and / or variations do not include all the details in the specific details described herein. Therefore, several details are described to provide a thorough understanding of the exemplary aspects illustrated in the accompanying drawings. Moreover, the drawings only illustrate some exemplary embodiments of this disclosure and should not be considered limiting.

[0144] While this specification contains numerous specific implementation details, these details should not be construed as limiting the scope of any invention or potentially claimed content, but rather as descriptions of features specific to particular embodiments of a particular invention. Certain features described in the context of different 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, while certain features may be described above as functioning in certain combinations and even initially claimed in this manner, one or more features of a claimed combination may be removed from that combination in some cases, and the claimed combination may involve sub-combinations or variations thereof.

[0145] Similarly, although the operations are depicted in a specific order in the accompanying drawings, this should not be construed as requiring such operations to be performed in a sequential order or the specific order shown, or requiring all illustrated operations to achieve the desired result. In some situations, multitasking and parallel processing may be advantageous. Furthermore, the partitioning of the various system components in the above embodiments should not be construed as requiring such partitioning in all embodiments, and it should be understood that the described program components and systems may generally be integrated together in a single software product or packaged into multiple software products.

[0146] Therefore, specific embodiments of the subject matter have been described. Other embodiments are also within the scope of the following claims. In some cases, the actions described in the claims can be performed in a different order and still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific order or sequence shown to achieve the desired result. In some embodiments, multitasking and parallel processing may be advantageous.

[0147] The embodiments of the subject matter and operation described in this specification may be implemented in digital electronic circuits or in computer software, firmware, or hardware (including the structures disclosed in this specification and their structural equivalents) or in a combination thereof. Embodiments of the subject matter described in this specification may be implemented as one or more computer programs, such as one or more modules of computer program instructions encoded on a computer storage medium for execution by or control of the operation of a data processing device. Alternatively or additionally, the program instructions may be encoded on artificially generated propagating signals, such as machine-generated electrical, optical, or electromagnetic signals, which are generated to encode information for transmission to a suitable receiver device for execution by the data processing device. The computer storage medium may be or be included in a computer-readable storage device, a computer-readable storage substrate, a random or serial access memory array or device, or a combination thereof. Furthermore, although the computer storage medium is not a propagating signal, it may be a source or destination of computer program instructions encoded in artificially generated propagating signals. The computer storage medium may also be or be included in one or more separate physical components or media (e.g., multiple CDs, disks, or other storage devices).

[0148] The term "data processing apparatus" encompasses all kinds of devices, apparatuses, and machines for processing data, including programmable processors, computers, systems-on-a-chip, or many or combinations of the foregoing. The apparatus may include special-purpose logic circuitry (e.g., FPGAs (Field-Programmable Gate Arrays) or ASICs (Application-Specific Integrated Circuits)). In addition to hardware, the apparatus may include code that creates an execution environment for the computer program under consideration, such as code constituting processor firmware, protocol stacks, database management systems, operating systems, cross-platform runtime environments, virtual machines, or combinations thereof. The apparatus and execution environment can implement a variety of different computing model infrastructures, such as web services, distributed computing, and grid computing infrastructures. Unless otherwise specifically stated, it should be understood that throughout this specification, discussions using terms such as "processing," "computing," "calculating," "determining," and "identifying" refer to the actions or processes of computing devices, such as one or more computers or similar electronic computing devices, that manipulate or convert data represented as physical electronic or magnetic quantities within the memory, registers, or other information storage devices, transmission devices, or display devices of a computing platform.

[0149] The one or more systems discussed herein are not limited to any particular hardware architecture or configuration. A computing device may include any suitable arrangement of components that provide results conditioned on one or more inputs. Suitable computing devices include computer systems based on multi-purpose microprocessors that access stored software that programs or configures the computing system from a general-purpose computing device to a special-purpose computing device that implements one or more specific implementations of this subject. The teachings contained herein may be implemented in the software used for programming or configuring the computing device using any suitable programming, scripting, or other type of language or combination of languages.

[0150] Specific implementations of the methods disclosed herein can be performed in the operation of such computing devices. The order of the boxes presented in the examples above can be varied; for example, the boxes can be reordered, combined, and / or divided into sub-blocks. Some boxes or processes can be executed in parallel. The operations described in this specification can be implemented as operations performed by a data processing apparatus on data stored on one or more computer-readable storage devices or received from other sources.

[0151] The use of "applies to" or "configured to" in this document implies open and inclusive language, which does not exclude applicability to or configuration for performing additional tasks or steps. Additionally, the use of "based on" implies openness and inclusivity, as processes, steps, calculations, or other actions "based on" one or more of the stated conditions or values ​​may in practice be based on additional conditions or values ​​beyond those stated. The headings, lists, and numbering included herein are for illustrative purposes only and are not intended to be restrictive.

[0152] It will also be understood that while terms such as "first," "second," etc., may be used in this document to describe various elements, these elements should not be limited by these terms. These terms are merely used to distinguish one element from another. For example, a first node may be called a second node, and similarly, a second node may be called a first node, changing the meaning of the description, provided that all occurrences of "first node" are consistently renamed and all occurrences of "second node" are consistently renamed. First nodes and second nodes are both nodes, but they are not the same node.

[0153] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the claims. As used in the description of these embodiments and in the appended claims, the singular forms “a,” “an,” and “the” are intended to also cover the plural forms unless the context clearly indicates otherwise. It will also be understood that, as used herein, the term “and / or” refers to and covers any and all possible combinations of one or more of the associated listed items. It will be further understood that the term “comprising,” when used in this specification, specifies the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0154] As used herein, the term "if" can be interpreted as meaning "when the prerequisite is true" or "when the prerequisite is true" or "in response to determination" or "according to determination" or "in response to detection" that the prerequisite is true, depending on the context. Similarly, the phrases "if it is determined [the prerequisite is true]" or "if [the prerequisite is true]" or "when [the prerequisite is true]" can be interpreted as meaning "when it is determined that the prerequisite is true" or "in response to determination" or "according to determination" that the prerequisite is true or "when it is detected that the prerequisite is true" or "in response to detection" that the prerequisite is true, depending on the context.

Claims

1. A method, the method comprising: In wearable electronic devices with processors: Receive a request to the application, the request corresponding to the wearable electronic device meeting the performance requirements required for the application to perform functions when the wearable electronic device is worn by a user; Obtain device performance data corresponding to the capabilities of the wearable electronic device when worn by the user; as well as A response to the request is provided based on the performance requirements and the device performance data, wherein the response provides or implements a determination of whether the wearable electronic device will meet the performance requirements required for the application to perform the function when the wearable electronic device is worn by a user.

2. The method of claim 1, wherein the device performance data provides location data related to the current location of the user relative to the wearable electronic device.

3. The method of claim 2, wherein the positioning data is determined by using a model to simulate how much light will propagate from the display of the wearable electronic device to at least one of the user's eyes.

4. The method of claim 1, wherein the device performance data provides the characteristics of the user.

5. The method according to claim 1, wherein the device performance data is used to generate simulation data based on current device characteristics, current user characteristics, or the positional relationship between the wearable electronic device and the user.

6. The method of claim 1, wherein the response provides a graphical indicator that presents the determination of whether the wearable electronic device will meet the performance requirements.

7. The method of claim 1, wherein the response provides a determined value related to the current performance capabilities of the wearable electronic device.

8. The method of claim 1, wherein the response provides an indication of whether a minimum performance parameter is available to the user, without providing user characteristics associated with the actual performance parameter.

9. The method of claim 8, wherein the minimum performance parameter and the actual performance parameter each comprise a parameter selected from the group consisting of: field of view (FOV) parameter, distortion parameter, chromatic aberration parameter, sharpness parameter, and color performance parameter.

10. The method of claim 1, wherein the response is provided to the application for providing a notification to the user.

11. The method of claim 1, wherein the response is provided to the application to prevent the use of the application on the wearable electronic device.

12. The method of claim 1, wherein the response is provided to the application to allow the application to be used on the wearable electronic device.

13. The method of claim 1, wherein the request is a query received via an application programming interface (API).

14. The method of claim 1, wherein the request corresponds to the wearable electronic device meeting the performance requirements relative to the functional requirements of the wearable electronic device.

15. The method of claim 1, wherein the request corresponds to the wearable electronic device meeting the performance requirements relative to laws and regulations.

16. The method of claim 1, wherein the request corresponds to the wearable electronic device meeting the performance requirements relative to user-related and application-specific requirements.

17. The method of claim 16, wherein the user-related and application-specific requirements are related to FOV parameters, distortion parameters, chromatic aberration parameters, sharpness parameters, or color performance parameters required for the use of the application.

18. A wearable device, the wearable device comprising: Non-transitory computer-readable storage medium; as well as One or more processors coupled to the non-transitory computer-readable storage medium, wherein the non-transitory computer-readable storage medium includes program instructions that, when executed on the one or more processors, cause the wearable device to perform operations including: Receive a request to the application, the request corresponding to the wearable electronic device meeting the performance requirements required for the application to perform functions when the wearable electronic device is worn by a user; Obtain device performance data corresponding to the capabilities of the wearable electronic device when worn by the user; as well as A response to the request is provided based on the performance requirements and the device performance data, wherein the response provides or implements a determination of whether the wearable electronic device will meet the performance requirements required for the application to perform the function when the wearable electronic device is worn by a user.

19. The wearable device of claim 18, wherein the device performance data provides location data related to the current location of the user relative to the wearable electronic device.

20. A non-transitory computer-readable storage medium storing program instructions executable by one or more processors to perform operations including: In wearable electronic devices with processors: Receive a request to the application, the request corresponding to the wearable electronic device meeting the performance requirements required for the application to perform functions when the wearable electronic device is worn by a user; Obtain device performance data corresponding to the capabilities of the wearable electronic device when worn by the user; as well as A response to the request is provided based on the performance requirements and the device performance data, wherein the response provides or implements a determination of whether the wearable electronic device will meet the performance requirements required for the application to perform the function when the wearable electronic device is worn by a user.

Images