Synchronization of physiological data and game data to influence game feedback loop

Abstract

This document describes a system and method for synchronizing sensor data and game event data to influence subsequent game events, comprising: presenting a first instance of a first game event; associating the first instance of the first game event with a first set of one or more timestamps; receiving readings from one or more biosensors indicative of at least one physiological measurement of a user; associating at least some of the readings with corresponding timestamps, wherein the first set of one or more timestamps and the corresponding timestamps share a common time standard; using the first set of one or more readings to determine subsequent game events; and presenting the subsequent game events.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. Provisional Application No. 62 / 930,097, filed November 4, 2019, entitled “Synchronization of physiological and game data to influence game feedback loops,” the entire contents of which are incorporated herein by reference. Background Technology

[0003] Various sensors exist to detect physiological conditions or responses to stimuli (such as impulses). Games can be controlled or influenced by user input received via a game controller. However, games do not use the user's physiological responses to game events to modify subsequent game events or include mechanisms to do so. Summary of the Invention

[0004] Generally, the innovative aspects of the subject matter described in this disclosure may be embodied in a method comprising one or more processors presenting a first instance of a first game event on one or more user interfaces; associating the first instance of the first game event with a first set of one or more timestamps; receiving readings from one or more biosensors indicating at least one physiological measurement of a user; associating at least some of the readings with corresponding timestamps, wherein the first set of one or more timestamps and the corresponding timestamps share a common time standard; using the first set of one or more readings to determine subsequent game events, at least one of the first set of one or more readings being associated with a timestamp corresponding to a time occurring during or after the first set of one or more timestamps; and presenting subsequent game events on one or more user interfaces.

[0005] According to another innovative aspect of the subject matter described in this disclosure, a system includes a processor; and a memory storing instructions that, when executed, cause the system to: present a first instance of a first game event on one or more user interfaces; associate the first instance of the first game event with a first set of one or more timestamps; receive readings from one or more biosensors indicating at least one physiological measurement of a user; associate at least some of the readings with corresponding timestamps, wherein the first set of one or more timestamps and the corresponding timestamps share a common time standard; use the first set of one or more readings to determine subsequent game events, at least one of the first set of one or more readings being associated with a timestamp corresponding to a time occurring during or after the first set of one or more timestamps; and present subsequent game events on one or more user interfaces.

[0006] Other implementations of one or more of these aspects include corresponding systems, apparatuses, and computer programs configured to perform the actions of the method and encoded on a computer storage device. These and other implementations may each optionally include one or more of the following features.

[0007] Features may include using a second set of one or more readings to determine subsequent game events, at least one of the second set of one or more readings being associated with a timestamp indicating a time occurring before any timestamp in the first set of one or more timestamps; and comparing a function of the first set of one or more readings with a function of the second set of one or more readings. Features may include presenting a second instance of the first game event on one or more user interfaces; associating the second instance of the first game event with a second set of one or more timestamps; and using a second set of one or more readings to determine subsequent game events, at least one of the second set of one or more readings being associated with a timestamp corresponding to a time occurring during or after the second set of timestamps. Features may include presenting a second instance of the first game event via one or more user interfaces; associating the second instance of the first game event with a third set of timestamps, at least one of the third set of timestamps corresponding to a time occurring: before a first time indicated by at least one timestamp in the second set of one or more timestamps; and after a second time indicated by at least one timestamp in the second set of one or more timestamps. Features may include presenting a second instance of a first game event via one or more user interfaces; and associating the second instance of the first game event with a third set of timestamps, at least one of the timestamps in the third set corresponding to a time occurring within a maximum amount of time indicated by at least one of the timestamps in a second set of one or more timestamps. Features may include presenting a second game event via one or more user interfaces; associating the second game event with a second set of one or more timestamps; and using a second set of one or more readings to determine subsequent game events, at least one of the second set of one or more readings being associated with a timestamp corresponding to a time occurring during or after the second set of one or more timestamps. Features may include: one or more biosensors may include sensors that measure cardiac activity; one or more processors generate a first measurement of heart rate variability using the first set of one or more readings; one or more processors generate a second measurement of heart rate variability using the second set of one or more readings; the first value being a first measurement of stimulus intensity; the second value being a second measurement of stimulus intensity; and one or more processors using a measurement of the relationship between heart rate variability and stimulus intensity to determine subsequent game events. Features may include: one or more biosensors may include sensors that measure a user’s breathing; one or more processors generate a first measurement of breathing rate using a first set of one or more readings; one or more processors generate a second measurement of breathing rate using a second set of one or more readings; the first value is a first measurement of stimulation rate; the second value is a second measurement of stimulation rate; and one or more processors use a measurement of the relationship between breathing rate and stimulation rate to determine subsequent game events.Features may include receiving output from one or more game control devices, the output indicating a user's action; associating at least some of the outputs with corresponding timestamps of a public time standard; and using one or more of the outputs to determine subsequent game events, at least one of the one or more outputs being associated with a timestamp corresponding to a time occurring during or after a first set of one or more time periods. A first instance of the first game event is associated with an event data array, which may include time, name, and one or more expected data fields defined for the type of the first game event. Subsequent game events are determined to elicit a specific physiological response in the user. Subsequent game events include completion criteria modified based on the first set of one or more readings.

[0008] It should be understood that the list of features and advantages is not exhaustive, and many additional features and advantages are contemplated and fall within the scope of this disclosure. Furthermore, it should be understood that the language used in this disclosure has been chosen primarily for readability and instructional purposes, and not to limit the scope of the subject matter disclosed herein. Attached Figure Description

[0009] This disclosure is shown in the accompanying drawings by way of example rather than limitation, and similar reference numerals are used in the drawings to refer to similar elements.

[0010] Figure 1 A schematic diagram of an example system in which physiological readings affect computer games, according to certain embodiments of the present disclosure, is shown.

[0011] Figure 2 A block diagram of an example client device according to certain embodiments of the present disclosure is presented.

[0012] Figure 3 Schematic diagrams according to certain embodiments of the present disclosure are presented, illustrating example systems in which physiological readings affect computer games.

[0013] Figure 4 Schematic diagrams according to certain embodiments of the present disclosure are presented, illustrating an example system including a virtual reality user interface and game controls, wherein physiological readings affect a computer game.

[0014] Figure 5 Schematic diagrams according to certain embodiments of the present disclosure are shown, illustrating an example system in which physiological readings influence computer games and processing takes place remotely from physiological sensors and user interfaces.

[0015] Figure 6 This is a block diagram illustrating an example biofeedback engine according to one embodiment.

[0016] Figure 7 A flowchart illustrating certain embodiments of the present disclosure is presented, which shows a method for decoupling game logic development and biofeedback algorithm development.

[0017] Figure 8 A flowchart is shown according to certain embodiments of the present disclosure, illustrating a method for evoking specific physiological responses in a computer game.

[0018] Figure 9 A flowchart illustrating certain embodiments of the present disclosure is presented, demonstrating a method for modifying in-game completion criteria based on physiological effects.

[0019] Figure 10 A flowchart illustrating a method for physiological effects in computer games is presented according to certain embodiments of the present disclosure.

[0020] Figure 11 A flowchart illustrating a method for studying the physiological effects of computer games using baseline readings is presented according to certain embodiments of the present disclosure.

[0021] Figure 12 A flowchart according to certain embodiments of the present disclosure is presented, illustrating a method for presenting the physiological effects of a computer game on multiple instances of a single game event.

[0022] Figure 13 A flowchart illustrating certain embodiments of the present disclosure is presented, showing a method for presenting the physiological effects of a computer game on two game events.

[0023] Figure 14 A flowchart according to certain embodiments of the present disclosure is presented, illustrating a method for presenting the physiological effects of a computer game on two instances of a first game event, the second instance of which overlaps with a second game event.

[0024] Figure 15 A flowchart of certain embodiments of the present disclosure is presented, illustrating a method for assessing the physiological effects of a computer game using values ​​corresponding to presented game events.

[0025] Figure 16 A flowchart illustrating certain embodiments of the present disclosure is shown, demonstrating a method for determining the physiological effects of computer games on subsequent game events using game controller outputs and physiological readings.

[0026] Figure 17 A flowchart illustrating a method for determining physiological responses to computer game events is presented according to certain embodiments of the present disclosure.

[0027] Figure 18 A flowchart illustrating certain embodiments of the present disclosure is presented, showing a method for predicting a third variable using game event data and physiological readings. Detailed Implementation

[0028] The techniques described herein overcome, at least in part, the shortcomings and limitations of existing technologies by providing systems and methods for constructing simultaneously interactive experiences. It should be understood that the language used in this disclosure is chosen primarily for readability and instructional purposes and does not limit the scope of the topics disclosed herein.

[0029] This disclosure describes systems and methods for constructing simultaneous interactive experiences. In the following description, numerous specific details are set forth for purposes of explanation in order to provide a thorough understanding of this disclosure. However, it should be noted that this disclosure can be practiced without these specific details.

[0030] When an individual experiences a physiological response to a series of stimuli, it may be unclear which aspect of those stimuli triggered the response. Unlike real-world experiences, computer games allow for precise control over the stimuli a user experiences. Multiple stimuli can occur simultaneously, or with precise time delays between them. A series of stimuli may be repeated with precise repetition or specific variations. The frequency and intensity of the stimuli can be adjusted. Common user interface outputs that can be presented through a game include visual images generated by the display screen and sound generated by speakers. Examples of tactile output include vibrations and refreshable Braille displays. Virtual reality (VR) can generally refer to the experience conveyed through a display screen coupled to the user's face. The images displayed on a VR screen change according to the position and orientation of the user's face, and can create the illusion that the user is viewing three-dimensional objects from different perspectives. VR can provide a particularly immersive experience, one where details can be fully controlled and precisely adjusted. Augmented reality is a further adaptation of virtual reality, overlaying software-generated images onto a real-world background in front of the user.

[0031] Responses to stimuli can manifest as observable physiological responses. Physiological measurements can include, but are not limited to, heart rate, heart rate zones, heart rate variability, respiratory rate, respiratory volume, respiratory level and intensity, sweat concentration, body temperature, blood pressure, eye movements, head position and rotation, and the movement of various muscles. Each of these physiological parameters can be measured using a variety of types of biosensors. For example, electrocardiography (ECG) or photoplethysmography (PPG) can be used to detect cardiac contractions and derived measurements such as heart rate and heart rate variability (HRV). Respiratory position can be measured using sensors that detect the position of a band fixed around the chest cavity or the force within that band. Derived measurements such as respiratory rate and respiratory volume can be derived from measurements of respiratory position. Thermocouples and thermistors measure temperature, which in turn can indicate metabolic rate. The electrical properties of the skin (e.g., resistance, potential, impedance, and admittance) can indicate physiological characteristics such as sympathetic nervous system arousal. Electromyography can be used to determine muscle movement. Blood pressure can be measured using various automated methods, including oscillometrics and sphygmomanometers. Eye movements can be quantified by analyzing video recordings of the eyes. Cameras that communicate with image processing capabilities can quantify the frequency and speed of a person's body movements. A variety of techniques, including electroencephalography (EEG), localized electron computed tomography (PET), and functional MRI (fMRI), can be used to measure neural activity in different parts of the brain or body.

[0032] Game outputs can be controlled or influenced by various inputs from the user. Hardware that captures game input includes, for example, buttons, joysticks, accelerometers, and gyroscopes under the conscious control of the user. While existing games can typically measure a user's physiological responses to the game, they do not correlate these responses with specific game events that, in turn, subtly influence subsequent game events. This physiological game feedback loop could have a wide range of applications, including tuning games to optimal intensity levels and therapeutic applications.

[0033] Example system implementation:

[0034] Figure 1A schematic diagram of an example system according to certain embodiments of the present disclosure, in which physiological readings affect a computer game, is shown. The illustrated system 100 includes a client device 106, an atomic clock 146, and a data server 122, which are communicatively coupled via a network 102 for interacting with each other. For example, the client device 106 may be coupled to the network 102 via signal line 114. The data server 122 may be connected to the network 102 via signal line 116. The atomic clock 146 may be coupled to the network 102 via signal line 126. In some embodiments, as shown by line 110, a user 112 may access the client device 106. The data server 122 may include one or more data sources (collectively referred to as data source 120, collectively referred to as multiple data sources 120). One or more data sources may be included in the data server 122, such as data source 120a, coupled to the data server 122 as direct access memory (DAS), as shown by data source 120b and line 118, coupled to the data server 122 via the network 102 as network accessible memory (NAS) (not shown), or a combination thereof.

[0035] Network 102 may include any number of networks and / or network types. For example, network 102 may include, but is not limited to, one or more local area networks (LANs), wide area networks (WANs) (e.g., the Internet), virtual private networks (VPNs), mobile networks (e.g., cellular networks), wireless wide area networks (WWANs), Wi-Fi networks, etc. network, Communication networks, peer-to-peer networks, other interconnected data paths across which multiple devices can communicate, and various combinations thereof. Data transmitted by network 102 may include packetized data (e.g., Internet Protocol (IP) data packets) routed to designated computing devices coupled to network 102. In some implementations, network 102 may include a combination of wired and wireless (e.g., terrestrial or satellite-based transceiver) networking software and / or hardware that interconnects the computing devices of system 100. For example, network 102 may include packet switching equipment that routes data packets to various computing devices based on information included in the header of the data packets.

[0036] Data exchanged over network 102 can be represented using technologies and / or formats, including Hypertext Markup Language (HTML), Extensible Markup Language (XML), JavaScript Object Notation (JSON), Binary JavaScript Object Notation, Comma-Separated Values ​​(CSV), etc. Furthermore, conventional encryption technologies such as Secure Sockets Layer (SSL), Secure Hypertext Transfer Protocol (HTTPS), and / or Virtual Private Network (VPN) or Internet Protocol Security (IPsec) can be used to encrypt all or some of the links. In another embodiment, entities may use custom and / or dedicated data communication technologies to replace or supplement the aforementioned technologies. Depending on the embodiment, network 102 may also include links to other networks.

[0037] Client device 106 is a computing device with data processing and communication capabilities. Although Figure 1 A client device 106 is shown, but this specification applies to any system architecture having one or more client devices 106. In some embodiments, client device 106 may include a processor (e.g., virtual, physical, etc.), memory, power supply, network interface, and may include other software or hardware components such as a display, graphics processor, wireless transceiver, input device (e.g., mouse, keyboard, controller, camera, sensor, etc.), firmware, operating system, drivers, and various physical connection interfaces (e.g., USB, HDMI, etc.). Client devices 106 can be coupled and communicate with each other via network 102 using wireless and / or wired connections, and can also be coupled and communicate with other entities of system 100 (e.g., data server 122).

[0038] Examples of client devices 106 may include, but are not limited to, VR headsets (e.g., Oculus Quest 2, Sony PlayStation VR, HTC Vive Cosmos, etc.), mobile phones (e.g., feature phones, smartphones, etc.), tablets, laptops, desktops, netbooks, server appliances, servers, virtual machines, TVs, set-top boxes, media streaming devices, portable media players, navigation devices, personal digital assistants, etc. Although for clarity and convenience, Figure 1 A client device 106 is depicted, but system 100 may include any number of client devices 106. Furthermore, any number of client devices 106 may be computing devices of the same or different types. In the depicted embodiment, client device 106 includes an instance of game logic 222, an instance of biofeedback engine 224, an output device 210, an input device 212, and sensors—sensor A 214 and sensor N 214n.

[0039] Game logic 222 may be stored in memory and may be executed by the processor of client device 106. In one embodiment, when executed by the processor, game logic 222 enables a user to play a game that includes one or more game events. As used herein, a game may refer to any instruction and / or memory state that determines a perceptible sequence of outputs generated by a computer through a user interface, wherein such stimuli are linked together by a set of logical processes to form a simulation, whereby input received from a human player influences the outputs according to a set of predefined rules. Input received from a human user may include, for example, physiological readings from biosensors or conscious actions of game control devices. As used herein, a game event (or simply “event”) may refer to a response of computing hardware to an input, wherein the response occurs within a given time period and may take the form of: (a) one or more stimuli generated by the user interface, or (b) one or more changes in the memory state of the game, wherein the input may be generated by (i) the player of the game or (ii) the processor executing instructions for the game. As an example and not a limitation, a game event may include a single screen image, a portion of a screen image, a representation of a 3D object (which may appear in multiple potential screen images depending on the virtual viewpoint and distance), a series of screen images, a series of images including a portion of the screen, a series of representations of a 3D object, sound, a series of sounds, haptic output, or a series of haptic outputs. A game event may be a feature or feature change of the user interface output. For example, a game event may be a change in image brightness or volume.

[0040] Game events may or may not be triggered by user actions. For example, game events may be based on actions of a computer character (e.g., AI-based or random behavior), the result of a simulation (e.g., simulated plant growth exceeding a threshold), or scripted events (e.g., a dancing character ending their dance and leaving the stage). Some game events may be triggered, for example, by a period of inactivity. In some embodiments, a game event may include, for example, starting a timer in the absence of user action that will trigger a specific stimulus at a future time. Instantaneous events are associated with a single timestamp, while interval events are associated with at least two timestamps indicating the start and end times of the interval event. Multiple game events may (but are not required to) occur simultaneously.

[0041] In one embodiment, game logic 222 provides event data to biofeedback engine 224, as further described below, which can be used to modify subsequent game events based on the user's physiological response to game events.

[0042] In one embodiment, game logic 222 includes a set of subscriptions to a set of biofeedback algorithms. For example, game logic 222 may include subscriptions to biofeedback algorithms associated with range of motion, allowing biofeedback engine 224 to determine the presentation of subsequent game events based on limitations of the user's range of motion. In another example, game logic 222 may include subscriptions associated with fear, and based on one or more of the user holding their breath, their pulse, and sweating determined using sensors, biofeedback engine 224 may determine the presentation of subsequent game events to induce a desired level of fear (e.g., heart rate, breath-holding, conductance of skin, conductance of skin response, specified rise in skin temperature).

[0043] The biofeedback engine 224 may be stored in memory and may be executed by the processor of the client device 106. The biofeedback engine 224 applies biofeedback algorithms to synchronized event and sensor data to modify the presentation of subsequent game events via game logic 222. Examples of modification may include, but are not limited to, altering the game's narrative (e.g., presenting event 2a to event 2b based on the user's physiological response to the first event), changing parameters associated with subsequent game events (e.g., the speed of enemy characters, the number of enemy characters, a threshold for completing a task or event in the game, the intensity of stimuli such as game audio volume, screen brightness or contrast, haptic feedback intensity, etc.). The threshold for completing a task or event in the game may sometimes be referred to as a completion criterion. As an example and not a limitation, examples of completion criteria may include one or more of a plurality of actions to be taken (e.g., repeating 10 times), the time required to perform multiple actions (e.g., within one minute), the ranking required to advance (e.g., achieving first place), another metric (e.g., collecting 10 coins, achieving more than 10,000 points in the level, achieving a heart rate of 100 BPM, achieving an X degree of knee flexion), etc. In some implementations, meeting completion criteria may be necessary to advance the game's narrative (e.g., completing a level), earn rewards (e.g., digital trophies or badges), or change the diagnosis (e.g., changing the predetermined rating of damage).

[0044] In one embodiment, the implementation of game logic 222 and biofeedback engine 224 decouples the development cycle of game content and biofeedback algorithm generation. For example, generating a new game or adding additional events to an existing game may occur much faster than the research, testing, and approval of the biofeedback algorithm. Therefore, in one embodiment, game logic 222 subscribes to biofeedback algorithms and versions, which can be updated, for example, when biofeedback algorithm module 240 deploys a new algorithm.

[0045] Depending on the game logic 222 and the use case, the biofeedback algorithm can provide one or more potential benefits, including, for example, therapeutic outcomes and user engagement. Regarding therapeutic outcomes, in one embodiment, the game logic 222 can be a game that addresses cognitive behaviors (e.g., fear of public speaking, quitting smoking, anxiety, etc.) and the biofeedback algorithm can be designed to help users address or overcome these cognitive behaviors. For example, a game for overcoming fear of public speaking presents a VR environment with a large audience that gently triggers the user's fear of speaking, but not to the point of complete withdrawal, and the game can gradually increase the audience size as the user adapts to a growing number of viewers. In one embodiment, the game logic 222 can be a game that addresses physical conditions (e.g., injury, chronic back pain), and the biofeedback algorithm can be designed to help users address or improve their physical conditions. For example, based on sensor data received during a calibration event, a physical therapy game for recovery from a rotator cuff injury can be tailored to limit the necessary range of motion of the user's shoulder in subsequent game events to a specific range, speed, and number of repetitions.

[0046] Regarding user engagement, in one embodiment, game logic 222 can be a game that increases user engagement. User engagement can be improved through various mechanisms. For example, user engagement with game logic 22 can be increased (e.g., the amount of time spent playing) by adjusting the threshold for completing a task, optimizing the difficulty or time required to complete the task, keeping the user engaged in the game flow, and preventing them from becoming bored (e.g., too easy or too slow to play) or frustrated (e.g., too difficult to complete). In another example, the user engages with game logic 222 by inducing desired physiological responses, such as fear, excitement, or satisfaction, and the accompanying release of adrenaline or dopamine, to enhance the game's progression.

[0047] Data server 122 may include one or more computing devices with data processing, storage, and communication capabilities. For example, data server 122 may include one or more hardware servers, server arrays, storage devices, systems, etc., and / or may be centralized or distributed / cloud-based. In some implementations, data server 122 may include one or more virtual servers that run in a host server environment and access the host server's physical hardware, including, for example, processors, memory, storage devices, network interfaces, etc., via an abstraction layer (e.g., a virtual machine manager).

[0048] In one embodiment, data server 122 includes a DBMS 220 module. The DBMS 220 module may be stored in memory and may be executed by the processor of data server 122 to provide access to data stored in data source 120. For example, in one embodiment, DBMS 220 provides access to data stored in data source 120 via network 102. Data source 120 may be stored on one or more non-transitory computer-readable media for storing data.

[0049] Although Figure 1 A single data server 122 is shown, but it should be understood that this is merely an example, and other embodiments may include any number of data servers 122 or may omit data servers 122 altogether. The data source 120 and the data stored thereon may vary depending on the embodiment. As an example and not a limitation, examples of data source 120 include insurance data sources (e.g., from data server 122 associated with a health insurance provider), demographic data, patient data (e.g., from electronic medical records (EMRs) via data server 122 associated with a healthcare provider such as a clinic or hospital, including clinical context such as prescriptions or other or concurrent treatments), survey data (e.g., user responses to games or treatments), usage data (e.g., usage time, frequency of use, duration of use), research data, clinical trial data, and other data (e.g., financial, telephone, and internet usage).

[0050] It should be understood that Figure 1 The system 100 shown represents an example system according to one embodiment, and various different system environments and configurations are expected and within the scope of this disclosure. For example, various functions can be moved from the server to the client and vice versa, and some implementations may include additional or fewer computing devices, services and / or networks, and various functionalities can be implemented on the client or server side.

[0051] Furthermore, various entities of system 100 can be integrated into a single computing device or system, or may include additional computing devices or systems. For example, in one embodiment, game logic 222 may be included wholly (e.g., in a cloud-based game) or partially on a server (not shown). In another example, in one embodiment, biofeedback engine 224 may be wholly or partially included on a server (not shown). For example, in such an embodiment, remote sensor data can be processed on the server, and local sensor data can be processed locally (on client device 106) to reduce latency.

[0052] Figure 2This is a block diagram of an example client device 106 according to one embodiment. As shown, the client device may include a processor 202, a memory 204, and a communication unit 208, which are communicatively coupled via a communication bus 206. Figure 2 The client device 106 depicted is provided by way of example and it should be understood that it may take other forms, other physical configurations, and include additional or fewer components without departing from the scope of this disclosure. For example, although not shown, the input device 212 and the output device 210 may be a single device (e.g., a touchscreen that receives input and presents a visual user interface, or a VR headset that includes the output device 210 (i.e., a display) and the sensor 214 (i.e., a gyroscope)).

[0053] Processor 202 can execute code, routines, and software instructions by performing various input / output, logical, and / or mathematical operations. Processor 202 has various computing architectures to process data signals, including, for example, Complex Instruction Set Computer (CISC) architecture, Reduced Instruction Set Computer (RISC) architecture, and / or architectures that implement instruction set combination. Processor 202 can be physical and / or virtual, and can include a single core or multiple processing units and / or cores. In some implementations, processor 202 may be able to generate electronic display signals and provide them to output device 210, support image display, capture and transmit images, perform complex tasks including various types of feature extraction and sampling, etc. In some implementations, processor 202 may be coupled to memory 204 via bus 206 to access data and instructions from it and store data therein. Bus 206 can couple processor 202 to other components of client device 106, including, for example, memory 204 and communication unit 208.

[0054] Memory 204 can store data and provide access to that data to other components of client device 106. In some implementations, memory 204 can store instructions and / or data that can be executed by processor 202. For example, in the illustrated embodiment, memory 204 can store game logic 222 and biofeedback engine 224. Memory 204 can also store other instructions and data, including, for example, operating systems, hardware drivers, other software applications, databases, etc. Memory 204 can be coupled to bus 206 for communication with processor 202 and other components of client device 106.

[0055] Memory 204 includes a non-transitory computer-usable (e.g., readable, writable, etc.) medium, which can be any means or device capable of containing, storing, communicating, propagating, or transmitting instructions, data, computer programs, software, code, routines, etc., for processing by or in conjunction with processor 202. In some embodiments, memory 204 may include one or more of volatile memory and non-volatile memory. For example, memory 204 may include, but is not limited to, dynamic random access memory (DRAM) devices, static random access memory (SRAM) devices, discrete storage devices (e.g., PROM, FPROM, EPROM, EEPROM, ROM), hard disk drives (HDD), and optical disk drives (CD, DVD, Blu-ray). TM One or more of the following (etc.). It should be understood that the memory 204 may be a single device, or may include multiple devices, multiple types of devices, and multiple configurations.

[0056] In one embodiment, processor 202 may communicatively couple to and execute instructions including a biofeedback engine 224 stored on memory 204, which cause processor 202 to present game events on one or more user interfaces (e.g., via output device 210), associate game events with at least one timestamp, associate at least some readings from physiological sensors 214 with timestamps using the same time standard as the timestamps associated with the game events, determine subsequent game events using a first set of readings generated during or after a first game event determined by the timestamps associated with the readings and one or more timestamps associated with the game events, and present subsequent game events on one or more user interfaces.

[0057] In some embodiments, processor 202 executes instructions for selecting subsequent game events (e.g., biofeedback engine 224). In some embodiments of the method, one or more processors (sometimes collectively referred to as "processing") associate both the game event presented to the user and the physiological data generated by the user (captured by one or more sensors) with corresponding timestamps. Each timestamp is synchronized with a single time standard, thereby allowing the timing of the physiological readings associated with the presentation of the game event to be determined. When the game is an instantaneous event, it can be associated with a single timestamp. When the event is an intervalized event, it may be associated with multiple timestamps. In some embodiments, each reading from one or more sensors 214 is associated with a timestamp. However, those skilled in the art will understand that substantially similar results can be obtained even if not all readings are associated with timestamps. The physiological response to the game event can be determined based on physiological readings generated during or after the presentation of the game event (for intervalized events) (for instantaneous or intervalized events). That is, the physiological response to the game event can be determined by processing physiological readings associated with timestamps indicating a time after the timestamp indicating the start of the game event. When multiple sensors and multiple game events overlap, a data structure with readings and associated timestamps can be particularly useful. This structure can be used to determine which game event (or combination of game events) triggered a specific physiological response.

[0058] Bus 206 may include a communication bus for transmitting data between components of client device 106 and / or computing devices (e.g., client device and game server 156), a network bus system including network 102 or a portion thereof, a processor grid, combinations thereof, etc. In some implementations, game logic 222, biofeedback engine 224, and various other software running on the client device (e.g., operating system, etc.) may cooperate and communicate via software communication mechanisms implemented in association with bus 206. Software communication mechanisms may include and / or facilitate, for example, inter-process communication, local function or procedure calls, remote procedure calls, object proxies (e.g., CORBA), direct socket communication between software modules (e.g., TCP / IP sockets), UDP broadcast and receive, HTTP connections, etc. Furthermore, any or all communication may be secure (e.g., SSH, HTTPS, etc.).

[0059] The communication unit 208 may include one or more interface devices (I / F) for wired and / or wireless connection to the network 102. For example, the communication unit 208 may include, but is not limited to, a CAT interface; a wireless transceiver (4G, 3G, 2G, etc.) for transmitting and receiving signals to communicate with a mobile network; and for Wi-Fi. TM and close range (e.g., Radio transceiver connectivity such as NFC; USB interfaces; various combinations thereof; and so on. In some implementations, communication unit 208 can link processor 202 to network 102, which in turn can be coupled to other processing systems. Communication unit 208 can provide additional connections to network 102 and other entities of system 100 using various standard network communication protocols.

[0060] Although Figure 2 Two sensors—sensor A 214a and sensor N 214n—are shown; however, the description herein applies to systems having one or more sensors (individually referred to as sensor 214, and collectively as multiple sensors 214). Furthermore, while sensor A 214a and sensor N 214n are shown communicatively coupled to bus 206, sensor 214 may be a separate device communicatively coupled to client device 106 via communication unit 208 (e.g., via USB, Bluetooth, etc.). Examples of sensors include, but are not limited to, ECG, PPG, HRV, respiratory position sensors, thermocouples, thermistors, sensors for resistance, potential, impedance, and admittance, electrocardiographs, oscilloscopes, blood pressure monitors, cameras, EEG, PET, fMRI, skin temperature sensors, and electrodermal activity sensors.

[0061] Output device 210 can be any device capable of outputting information. Output device 210 may include one or more displays (LCD, OLED, etc.), printers, haptic devices, audio playback devices, touchscreen displays, telecomputing devices, etc. In some implementations, the output device is a display that can show electronic images and data output by processor 202 to the user. In some implementations, the output device is a VR headset with a stereoscopic display that can show binocular electronic images and data output by processor 202 to the user.

[0062] Input device 212 receives input generated by a user interacting with the game. Examples of input devices include, but are not limited to, keyboards, mice, touchscreens, etc. In one embodiment, input device 212 includes one or more game controls. Game events in many computer games are influenced by game controls, even if not determined by the game user's conscious control. Common types of game controls include buttons, joysticks, rotatable knobs and wheels, motion detectors in the form of accelerometers and gyroscopes, and cameras that capture user images and couple them with logic to analyze the images. A housing including one or more game controllers may sometimes be referred to as a controller, game controller, or game console.

[0063] Figure 3A schematic diagram of a system 300 illustrating the physiological effects of computer games according to certain embodiments of this disclosure is presented. System 300 includes a processor 202 communicatively coupled to a memory 204. The dashed line connecting the two components indicates that they are communicatively coupled; information can be transferred from one to the other, but a physical connection is not necessarily required. Processor 202 can execute instructions stored in memory 204. Processor 202 can store and retrieve data from memory 204, such as recorded timestamps and associated physiological readings and game events, and process the data to determine subsequent game events. Processor 202 and memory 204 may be the only components of system 300. Additionally, system 300 may optionally include one or more user interfaces presented via an output device 210, to which processor 202 can transmit one or more game events. Optionally, system 300 may include one or more physiological sensors 214 communicatively coupled to one or more processors 202. Processor 202 receives readings from physiological sensors 214a and associates timestamps with the readings. Processor 202 executes instructions from memory 204, causing processor 202 to present a first game event on the user interface. Processor 202 associates the first game event with one or more timestamps that share a common time standard with the timestamps associated with the readings. Using readings from physiological sensor 214a (each reading associated with a timestamp corresponding to a time occurring during or after one or more timestamps associated with the first game event), processor 202 determines subsequent game events and presents them on user interface 210.

[0064] Some embodiments of this disclosure use a technology commonly referred to as Virtual Reality (VR). VR generally refers to games and other electronic content presented on an output device 210 fixed to a user's face. The display 210, coupled with a fastening component, may be referred to as VR goggles. VR goggles typically include one or more gyroscopes (sensors that measure angular acceleration). The gyroscopes generate an output indicating the orientation of the user's head. VR goggles may also include one or more accelerometers that measure linear acceleration. As the user's head orientation changes, the image is processed and adjusted to generate a stereoscopic view on the output device 210, thereby creating the illusion that the user is viewing a three-dimensional environment including three-dimensional objects. For this reason, VR games can provide a particularly immersive experience, making VR game events particularly effective in evoking physiological responses.

[0065] Figure 4A schematic diagram of an example system 400 according to certain embodiments of the present disclosure is shown. The system includes a VR user interface as an input device 212 and a game controller, wherein physiological readings influence computer gameplay. System 400 includes a processor 202 communicatively coupled to a memory 204. The processor 202 can execute instructions stored in the memory 204. The processor 202 can store and retrieve data from the memory 204, such as recorded timestamps and associated physiological readings and game events, and process the data to determine subsequent game events. In this embodiment, the system includes VR goggles 402 acting as a user interface. The VR goggles 402 include a display screen as an output device 210 and a three-axis gyroscope 414c, each communicatively coupled to the processor 202. The processor 202 receives readings from a heart sensor 414a and a respiratory sensor 414b, and receives output from the game controller. The processor 202 associates timestamps with the readings and outputs. The processor 202 executes instructions from the memory 204 such that the processor 202 presents a first game event on the display screen. Processor 202 associates a first game event with one or more timestamps. Using readings from heart sensor 414a and respiratory sensor 414b and outputs from the game controller (each reading and output associated with a timestamp occurring during or after one or more timestamps associated with the first game event), processor 202 determines subsequent game events and presents them on the display. Processor 202 adjusts the presentation of subsequent game events based on outputs from three-axis gyroscope 414c so that the image is aligned with the user's head orientation.

[0066] Processing and data storage do not need to occur near the physiological sensors or the user interface, nor do they need to occur near each other. In some embodiments, one or more processors that determine game events can send information to a remote user interface via a network such as the Internet. Similarly, readings from physiological sensors can be transmitted to one or more remote processors via a network such as the Internet. Such embodiments may be useful, for example, if the game is provided as SaaS (Software as a Service). Similarly, when using a separate timing means, that timing means can be located remotely from other components of the system.

[0067] Figure 5A schematic diagram of a system 500 according to certain embodiments of the present disclosure, in which physiological readings influence computer games and processing is performed remotely from physiological sensors and a user interface, is shown. System 500 includes a processor 202 communicatively coupled to a memory 204. Cloud-shaped symbols surrounding the processor 202, memory 204, and atomic clock 146 represent each element communicatively coupled to other elements via a network 102 (e.g., the Internet) and not requiring a specific geographical location. The processor 202 can execute instructions stored on the memory 204. The processor 202 can store and retrieve data from the memory 204, such as recorded timestamps and associated physiological readings and game events, and process the data to determine subsequent game events. In this embodiment, the system includes a VR headset 402 that acts as a user interface. The processor 202 receives readings from a physiological sensor 214a and a game controller 212 and associates timestamps with the readings and outputs. The processor 202 executes instructions from the memory 204 such that the processor 202 presents a first game event on the VR headset 402. The processor associates the first game event with one or more timestamps. Using readings from physiological sensor 214a and outputs from game controller 212 (each reading and output being associated with a timestamp occurring during or after one or more timestamps associated with the first game event), processor 202 determines subsequent game events and presents them on VR goggles 402.

[0068] refer to Figure 6 According to one embodiment, a biofeedback engine 224 is shown in more detail. The biofeedback engine 224 may include code and routines for providing the functionality described herein. For example, the biofeedback engine 224 receives sensor inputs and game events, and modifies subsequent game events.

[0069] Sensor data module 632 includes code and routines for receiving sensor data generated by one or more sensors. Examples of physiological sensors 214 include, but are not limited to, ECG, PPG, HRV, respiratory position sensors, thermocouples, thermistors, resistance, potential, impedance and admittance sensors, electrocardiographs, oscilloscopes, blood pressure monitors, cameras, EEG, PET, fMRI, etc.

[0070] Readings from the sensor can be received by the sensor data module 632 as unprocessed (“raw”) or output, which is a derived measurement meaningful in a physiological context. For example, a raw reading may simply be an electrical characteristic such as current, voltage, or resistance at a specific time. The physiological significance of the raw reading can be obtained by understanding the type and location of the sensor that generated the reading. For example, if the sensor is an ECG electrode placed on the heart, an increase in voltage can indicate heart contractions.

[0071] Alternatively, some sensors can preprocess raw readings and provide derived readings to the sensor data module 632. For example, an ECG sensor can analyze the voltage output of the ECG electrodes and generate readings corresponding to the timing of cardiac contractions. Further derived readings can also be considered as readings. For example, an ECG sensor can deliver readings corresponding to heart rate variability (HRV), which is the result of processing time for multiple cardiac contractions.

[0072] Some sensor readings can be fixed-frequency time series. For example, sensor data points received at a specific frequency. An ECG signal is a voltage time series sampled 500 to 2000 times per second, while a PPG sensor can estimate heart rate every 5 seconds. In one embodiment, fixed-frequency data without timestamps is collected; if data is lost, a "zero" value is stored to maintain a complete time series. Some readings may appear at unpredictable or irregular intervals (e.g., in response to a physical event). In one embodiment, such readings are associated with timestamps.

[0073] Event data module 636 includes code and routines for receiving event data. In one embodiment, event data module 636 receives event data generated from a user interacting with game logic 222. Depending on the embodiment, the event data may vary in structure and the information included. In one embodiment, event data includes data points in an array. For example, event data module 636 receives a JSON array. In one embodiment, event data includes time, type, and data. For example, in one embodiment, event data module 636 receives event data points in a JSON array, where each data point is represented as a JSON object having a time field, an event type, and expected fields associated with the event type.

[0074] The time field indicates the timing of the event. In some embodiments, the time is a timestamp. For example, in one embodiment, the time is the number of milliseconds since the start time.

[0075] The event type describes the type of event that occurs during gameplay. In one embodiment, the event type is a human-readable string. Examples of event types include, but are not limited to, downward control, upward control, selection control, grabbing an item, canceling grabbing an item, storing an item, discarding an item, placing an item, removing an item, activating an item, deactivating an item, entity state change, starting the game, ending the game, pausing the game, restarting the game, starting a level, ending a level, starting an activity, progressing through an activity, ending an activity, activity state change, score evaluation, reward, change in biotic feedback level, customization, etc.

[0076] Expected fields may vary depending on the event type. Examples include, but are not limited to, objects (e.g., the name of a control, the name of an item, the name of an entity, the name of a prize), themes (e.g., entities that activate or deactivate controls, entities that make choices, entities that grab, de-grab, store, put down, place, remove, entities that activate or deactivate items, entities that change state, entities that receive prizes, etc.), locations (e.g., the name of a storage or placement location), qualifiers (e.g., describing the use of an activated or deactivated item, describing how the activity is performed, the score being evaluated, the value to which the biofeedback level has changed), transitions (e.g., describing the state left before a transition, describing the state entered as part of a state change after a transition), names (e.g., describing the type of game that started or ended, the name of a level that has started or ended, the name of an activity that has started, is in progress, or has ended, the type of score being evaluated, the biofeedback level being changed, etc.), percentages (e.g., how far the activity has progressed), stages (e.g., the number of stages the activity is currently in), and the number of stages.

[0077] In some embodiments, events may be based on interactions with game logic 222 and the game logic therein. For example, completing a level, interacting with an item, etc. In some embodiments, events may be based on physiological responses. For example, an event occurs when a user's heart rate increases by a predetermined amount or exceeds a threshold.

[0078] Synchronization module 638 includes code and routines for synchronizing event data and sensor data. In one embodiment, synchronizing event data and sensor data includes generating timestamps. One or more timing devices can be used to generate timestamps. When more than one timing device is used, each timing device can share a common time standard. Various timing methods can be used to generate timestamps. Because processors typically perform calculations on regular time cycles, some embodiments may count processor cycles as a means of measuring time (and thus generating timestamps). When physiological sensors generate readings at regular time intervals, some embodiments may count the number of sensor readings to measure the passage of time. Alternatively, a separate time measuring device can be used to generate timestamps. Examples of alternative time measuring devices include electronic clocks, such as quartz clocks, electrically driven clocks, synchronized clocks, and radio-controlled clocks that are wirelessly synchronized with a time standard, such as atomic clock 146 or atomic clock 146 itself. In some embodiments, synchronization module 638 calculates an offset and applies that offset to one or more of the sensor data and event data. For example, in one embodiment, the synchronization module 638 calculates a first offset and applies it to event data from the VR headset, wherein the first offset describes the difference between the clock of the VR headset and the atomic clock, and calculates a second offset and applies it to sensor data from the first sensor, wherein the second offset describes the difference between the clock of the first sensor and the atomic clock.

[0079] Based on timestamps, synchronization module 638 associates event data with sensor data, thereby associating the user's physiological readings with game events. In one embodiment, synchronization module 638 associates event data with sensor data based on timestamps using a common time standard. The association with the timestamp does not need to be a physical or spatial association. Data corresponding to game events, physiological readings, or game control outputs only needs to be recorded in a way that is associated with a specific time. This association can take the form of, for example, an address in memory or a physical location on a disk.

[0080] The biofeedback algorithm module 640 includes code and routines for determining subsequent events based on the physiological outcomes of game events. In one embodiment, the biofeedback algorithm can access and apply one or more biofeedback algorithms (not shown), or there can be multiple biofeedback algorithm modules 640, each associated with a different algorithm or set of algorithms (not shown).

[0081] One or more biofeedback algorithms may include different versions of biofeedback algorithms and / or biofeedback algorithms with different roles / purposes (e.g., inducing a certain physiological response related to fear or excitement, setting parameters related to game speed, etc.). In one embodiment, the biofeedback algorithm applied by biofeedback algorithm module 640 may be obtained from a subscription, for example, pulled from a subscription database or provided in a request from game logic 222.

[0082] In some embodiments, the biofeedback algorithm module 640 applies the algorithm to perform real-time analysis. Real-time data analysis can be useful for a series of game events designed to elicit specific physiological responses. Real-time data analysis can also be useful when determining subsequent actions to determine the visual aspects of the event, as the analysis may need to run at the game's frame rate to modify that visual aspect in a timely manner. However, in some embodiments, the biofeedback algorithm module 640 applies the algorithm to perform post-hoc analysis, because a dataset comprising annotations of game events and physiological readings, each associated with a timestamp of a shared public time standard, can be useful for determining patterns of stimuli and physiological responses on a post-hoc basis. The algorithm or output of the post-hoc analysis may vary based on embodiments or use cases. However, as examples and not limitations, examples of post-hoc analyses and outputs include a better understanding of physiological responses at the group or population level, which can be fed back into the system by adjusting a set of parameters for future users, and a better understanding of physiological responses for a particular user, which can be fed back into the system by adjusting a set of parameters for the particular user's subsequent game sessions.

[0083] In some embodiments, such as those where the game is intended for therapeutic purposes, the biofeedback algorithm module 640 may include a diagnosis determination module 642. The diagnosis determination module 642 includes code and routines for determining a diagnosis. The diagnosis determined by the diagnosis determination module 642 can be used by the subsequent event determination module 648 to present subsequent events.

[0084] For example, when the diagnostic determination module 642 determines that the user suffers from insomnia, in one embodiment, the subsequent event determination module 648 may determine that it is after dark and the blue light on the display is reduced to minimize the impact of artificial light on the user's sleep hormones or cycles. In another example, when the diagnostic determination module 642 determines that the user suffers from heart disease, in one embodiment, the subsequent event determination module 648 may adjust the intensity of game events. For example, assuming the game includes a start event, such as someone screaming and rushing out of a dark doorway, in one embodiment, the subsequent event determination module 648 may illuminate the shadows in the doorway to make the person's bright silhouette visible and reduce the volume of the scream, thereby reducing the risk of cardiac shock caused by a startling game event. In yet another example, the diagnostic determination module 642 determines the user's finite range of motion based on sensor data and adjusts the gameplay (i.e., one or more subsequent events) based on that finite range of motion. For example, a game for entertainment may be adjusted to work within the user's finite range of motion, while a therapeutic game may be adjusted to push or slightly exceed the limits of the user's range of motion in a way that expands the user's range of motion over time. In yet another example, when the diagnosis determination module 642 determines that a user has a phobia; in one embodiment, the follow-up event determination module 648 may adjust the game to use the phobia to combat and treat the phobia by exposing it in a therapeutic manner, or to exploit the fear if the game is designed to be frightening.

[0085] In some embodiments, the diagnosis determination module 642 can determine a diagnosis by obtaining an explicit diagnosis. For example, in one embodiment, the diagnosis determination module 642 can receive a diagnosis from the user's (anonymous in some embodiments) EMR. In some embodiments, the diagnosis determination module 642 can determine a diagnosis implicitly. For example, the diagnosis determination module 642 can determine insomnia based on a pattern of playing games late at night or determine carpal tunnel syndrome based on the degree of use. The foregoing are merely examples of implicit diagnoses. In some embodiments, the diagnosis determination module 642 can apply machine learning (e.g., supervised, semi-supervised, or unsupervised) to the data source 120 to determine a diagnosis. As mentioned above, the data source 120 can include various types of data (e.g., medical, insurance, financial, personal, etc.), from which various physiological, epidemiological, cognitive, and behavioral diagnoses can be inferred by applying machine learning.

[0086] Physiological responses to game events can be determined on an absolute scale. For example, if an ECG sensor indicates a heart rate exceeding 120 beats per minute (BPM) after a first game event, some embodiments can determine subsequent game events with a lower stimulus intensity than the first game event. However, such a criterion is not optimal because it does not account for changes in physiological measurements from before to after the first game event. If the game user's heart rate is 120 BPM both before and after the first game event, no physiological response can be attributed to the first game event. Therefore, some embodiments include a baseline determination module 644. The baseline determination module 644 includes code and routines for determining a baseline. For example, the baseline determination module 644 determines a heart rate of 120 BPM as the baseline heart rate.

[0087] The response determination module 646 includes code and routines for determining how the user 112 responds to game events. In one embodiment, how the user 112 responds to game events is based on physiological responses represented by sensor data or changes in sensor data.

[0088] Processing physiological readings generated during or after the first game event can produce some measurements of the physiological response to the first game event. However, those skilled in the art will understand that the useful determination of subsequent game events does not require specific physiological parameters. For example, in embodiments using ECG readings, processing does not need to determine a specific measurement of heart rate per minute (BPM) when selecting subsequent game events. Calculations without specific physiological significance, such as the sum of raw ECG electrical outputs over a period of time, can serve as a substitute for heart rate. Any number of methods for processing readings from physiological sensors can be used to select subsequent game events without determining the physiological measurement itself.

[0089] In some embodiments, the utility of this method may include determining physiological responses to gaming events, regardless of whether the measured physiological responses are subsequently used to determine subsequent gaming events. For example, determining an increase in heart rate in response to a gaming event simulating combat may be used to establish a diagnosis of combat-related post-traumatic stress disorder (PTSD). Establishing physiological responses to gaming events can be useful, even if not for the diagnosis or treatment of a medical or behavioral condition. For example, researchers may wish to quantify the degree of physiological response to a particular set of stimuli in order to determine the amount of change in mental sensitivity to a particular condition. For example, researchers may wish to establish changes in physiological responses to gaming events simulating danger or social embarrassment. The methods described herein for determining subsequent gaming events can be applied to determining physiological responses to gaming events, regardless of whether the determined physiological responses are used to determine subsequent gaming events.

[0090] In some embodiments, the response may be based on a defined baseline. For example, in some embodiments, the system uses a reading associated with a timestamp indicating a time prior to the first game event (i.e., the baseline) and a reading associated with a timestamp indicating a time subsequent to the first game event (i.e., the response) to determine subsequent game events. For example, when the response determination module 646 determines based on ECG sensor data indicating an increase of at least 50 beats per minute in heart rate from before the first game event to after the first game event, some embodiments may determine that subsequent game events have a lower stimulus intensity than the first game event.

[0091] Determining a physiological response after a single presentation of a game event provides only a single observation for determining the user's reaction to the game event and increases the possibility that the physiological response is caused by some other confounding factor, not the game event itself. Therefore, in some embodiments, the response determination module 646 may determine the response by comparing physiological readings (from one or more sensors 214) generated after each of multiple presentations of a single game event, and the subsequent event determination module 648 may determine the response based on this comparison. Such embodiments can better determine the physiological effects of a game event without confounding factors such as the novelty of experiencing the game event for the first time. In these embodiments, the game event may be the same or functionally identical on each presentation. In some embodiments, the subsequent event determination module 650 may determine subsequent game events based on an analysis by the response determination module 646 using readings generated after the first and second presentations of the game event. For example, some embodiments may compare the average of the readings generated after the first presentation of the game event with the average of the readings generated after the second presentation of the game event. The comparison measurement may take various forms, including, for example, the difference between averages or the ratio of averages. Determining subsequent game events may include, for example, determining whether the comparison metric is greater than or less than a threshold.

[0092] The subsequent event determination module 650 determines subsequent events based on the user's physiological response to at least one event. The determined subsequent events can define the game's narrative (e.g., presenting event 2a to event 2b) and / or modify parameters of the subsequent events, such as intensity, completion criteria, thresholds, etc.

[0093] After associating the first game event and physiological readings with corresponding timestamps, one or more processors can use the timestamped readings to determine subsequent game events, indicating when they occurred during or after the first game event. The time range of readings used to determine subsequent game events can depend on the type of the first game event. For example, if the first game event is sudden (e.g., a loud noise), the response value can be determined from readings associated with timestamps occurring within a very short time interval after the game event. However, if the first game event is a gradual transition from day color to night color, the readings used to determine subsequent game events can be associated with timestamps occurring over a longer period of time after the first game event. After determining subsequent game events, one or more processors can present the subsequent game events on one or more user interfaces.

[0094] In some embodiments, the subsequent event determination module 650 determines a subsequent event that is identified as triggering a specific physiological response to the subsequent event. For example, in one embodiment, the subsequent event determination module 650 sets completion criteria for physical therapy-related game events such that the patient (user) does not become overly challenged (e.g., set to make the patient feel challenged or experience a certain degree of discomfort or fatigue). Such embodiments can advantageously reduce situations where completion criteria are initially set too ambitiously and the user injures himself / herself while attempting to complete them.

[0095] In some embodiments, the subsequent event determination module 650 uses physiological readings generated after each of the first and second game events to determine subsequent game events. Determining physiological responses to multiple game events may be advantageous because doing so allows the method to determine the effect of each of the multiple parameters individually, without potential interaction effects between parameters that would occur if the multiple parameters appeared in the same game event. For example, some embodiments may use readings associated with timestamps indicating that they occurred after a first game event including bright light but no loud sound, and readings associated with timestamps indicating that they occurred after a second game event including loud sound but no bright light, to determine subsequent game events. In a particular embodiment, processing may use readings generated after each of the first and second game events to determine subsequent game events, processing those readings after each game event to measure physiological responses to each of bright light and loud sound.

[0096] In addition to physiological readings, some embodiments may use other types of input that influence the determination of subsequent game events. For example, some embodiments may use diagnostics to modify subsequent game events. In another example, some embodiments may use values ​​corresponding to measurements of game events. Game event values ​​may quantify various attributes, including but not limited to: volume, monitor brightness, average hue, stimulus frequency, number of stimuli appearing on the screen, stimulus size appearing on the screen, or any other metric. In some embodiments, the processing uses four values ​​to determine subsequent game events: physiological readings generated during or after a first game event; the metric of the first game event; physiological readings generated during or after a second game event; and the metric of the second game event. This type of embodiment can be used to identify the relationship between quantifiable game event metrics and physiological responses to game events. Subsequent game events can then be selected based on the determination of this relationship. Depending on the embodiment and implementation, subsequent events may be subsequent in one or more respects. For example, subsequent events may be subsequent in time, which may include subsequent events in the game narrative, subsequent events within the same game session, or subsequent game sessions of the same or different games. Regarding subsequent sessions of the same or different games, assuming that based on sensor data, the biofeedback algorithm module 640 observes that resonant breathing is the most effective activity observed for a particular user at 9 seconds per breath. In one embodiment, the biofeedback algorithm module 640 can determine to provide content or input (i.e., subsequent events) at this frequency.

[0097] In some embodiments, the biofeedback algorithm module 640 uses machine learning to train the algorithm and determine subsequent events. Some embodiments employ machine learning (ML) techniques to identify patterns in data, including data elements corresponding to timestamped game events and data elements corresponding to timestamped physiological readings.

[0098] The variations in game types (e.g., entertainment, therapy), game events, diagnostics (e.g., physical and cognitive), sensors, and sensor data (e.g., describing a user's physiological responses and / or event conditions, such as game volume) based on implementation examples and use cases are so numerous that an exhaustive list is impossible. Similarly, the variety of supervised, semi-supervised, and unsupervised machine learning algorithms is also too vast to list exhaustively. Example types of ML include neural networks, Markov models, support vector machines, decision trees, random forests, and augmented stumps.

[0099] Some embodiments may use supervised machine learning techniques, in which one or more processors use training data to generate a model that uses other variables (input variables) to predict some variables (output variables). When the outcome variable is unknown or unmeasured, the model fitted to the training data can be subsequently used to predict the outcome variable. In addition to data elements corresponding to game events and physiological readings, the training data may optionally include input variables that add predicted values ​​to the model or output variables of interest as outcomes. Optional input variables may include, for example, attributes of game events and timestamped outputs from game controls. Optional output variables may include, for example, a user's diagnosis, treatment, and the response of the diagnosis to treatment (if any), whether individually or in combination. Optional output variables may also include categories with further predicted values, such as categories or measurements of user cognitive characteristics. The model generated using the training data can then be applied to situations where the input variables are known but the output variables are unknown. Some embodiments may use unsupervised machine learning techniques, in which one or more processors identify patterns in data including timestamped game events and timestamped physiological readings.

[0100] In some embodiments, the machine learning is trained on specific data to present subsequent events to a user. For example, the subsequent events presented to user A are determined entirely based on user A's physiological responses to one or more previous events. In some embodiments, the machine learning is trained on data from multiple users, which may be anonymized. For example, using machine learning, the subsequent event determination module 650 determines multiple user categories and, based on user A's physiological responses, determines that user A belongs to a first user category (e.g., expert) and determines subsequent game events associated with that user category.

[0101] Example method implementation:

[0102] Figure 7 A flowchart illustrating a decoupled method 700 for game logic development and biofeedback algorithm development according to certain embodiments of the present disclosure is presented. At block 702, the biofeedback algorithm module 640 applies a first biofeedback algorithm to game content (e.g., game event 1). At block 704, a second biofeedback algorithm is received. For example, an updated version of the biofeedback algorithm is received. At block 706, the second biofeedback algorithm received at block 704 is applied to the game content (e.g., the first event), and method 700 ends. Therefore, in the illustrated method 700, the development and use of the biofeedback algorithm are decoupled from the development of game content and events.

[0103] Figure 8A flowchart of a method 800 for evoking a specific physiological response in a computer game according to certain embodiments of the present disclosure is shown. At block 802, an event data module 634 receives event data for event 1. At block 804, a sensor data module 632 receives sensor data from one or more sensors (i.e., sensors AN). At block 806, a synchronization module 638 determines a first set of sensor AN data (e.g., based on timestamp association) associated with game event 1. At block 808, a subsequent event determination module 650 determines a subsequent event predicted to elicit a specified physiological response in the user (e.g., increasing the user's heart rate by X, or causing an increase in the user's respiration), and method 800 terminates.

[0104] Figure 9 A flowchart illustrating a method 900 for modifying in-game completion criteria based on physiological effects, according to certain embodiments of the present disclosure, is presented. At block 802, event data module 634 receives event data for event 1. At block 804, sensor data module 632 receives sensor data from one or more sensors (i.e., sensors AN). At block 806, synchronization module 638 determines a first set of sensor AN data (e.g., based on timestamp association) associated with game event 1. At block 908, subsequent event determination module 650 determines subsequent events by modifying completion criteria associated with subsequent events, and method 900 terminates.

[0105] Figure 10 A flowchart illustrating a method (1000) for physiological effects on a computer game according to certain embodiments of this disclosure is presented. At block 1020, one or more processors (collectively, “process”) present a game event on one or more user interfaces. At block 1030, the process associates the game event with a first set of one or more timestamps indicating the time when the game event was presented on one or more user interfaces. At block 1025, the timestamps are generated by one or more timing means sharing a common time standard. At block 1045, the process associates at least some physiological readings (1035) with corresponding timestamps. The readings (1035) indicate at least one physiological measurement of a user capable of perceiving the game event presented by one or more user interfaces. The respective timestamps associated with the readings (1035) share the same time standard (1025) used for the one or more timestamps associated with the game event. At block 1080, the process uses the first set of one or more readings to determine subsequent game events. At least one reading in the first set of one or more readings is associated with at least one timestamp corresponding to a time occurring during or after the first set of one or more timestamps (indicating that at least one reading was generated after the start of the first game event). In box 1090, the subsequent game events are processed and then presented on one or more user interfaces, and method 1000 ends.

[0106] Figure 11 A flowchart illustrating a method 1100 for the physiological effects of a computer game using baseline readings, according to certain embodiments of this disclosure, is presented. At block 1020, one or more processors (collectively, “process”) present game events on one or more user interfaces. At block 1030, the process associates the game events with a first set of one or more timestamps indicating the time the game events were presented on one or more user interfaces. At block 1025, the timestamps are generated by one or more timing means sharing a common time standard. At block 1045, the process associates at least some physiological readings (1035) with corresponding timestamps. The readings (1035) indicate at least one physiological measurement of a user capable of perceiving the game events presented by one or more user interfaces. The respective timestamps associated with the readings (1035) share the same time standard (1025) as used for the one or more timestamps associated with the game events. At block 1180, the process determines subsequent game events using a first set of one or more pre-event readings and a second set of one or more post-event readings, as determined by the timestamps associated with the readings and the game events. At block 1090, the process then presents the subsequent game events on one or more user interfaces, and method 1100 terminates.

[0107] Figure 12A flowchart illustrating a method 1200 for presenting the physiological effects of a computer game in presenting multiple instances of game events, representing certain embodiments of this disclosure, is provided. Depending on the implementation, the multiple instances may be repeated instances of the same game event (e.g., repetition of the same content, such as the same enemy character jumping down from the same dark doorway) or multiple instances of equivalent game events (e.g., the first instance of an equivalent game event may be an enemy jumping down from a dark doorway, while the second instance may be a cat jumping down from an open box in the game; this can be equivalent because they are both intended to elicit a startle response from the user). In box 1020, one or more processors (collectively, “processing”) present game events on one or more user interfaces. In box 1030, the processing associates the game events with a first set of one or more timestamps indicating the time when the game events were presented on one or more user interfaces. In box 1025, the timestamps are generated by one or more timing means sharing a common time standard. In box 1045, the processing associates at least some physiological readings (1035) with the corresponding timestamps. The readings (1035) indicate at least one physiological measurement of a user capable of perceiving the game events presented by one or more user interfaces. The individual timestamps associated with the readings (1035) share the same time standard (1025) as the one or more timestamps associated with the game event. In box 1250, the process then presents a second instance of the first game event on one or more processors, and in box 1260, associates the second instance of the first game event with a second set of one or more timestamps. In box 1270, the process associates the second set of one or more physiological readings (1035) with corresponding timestamps. The first set of readings is associated with timestamps indicating a time occurring after the first set of one or more timestamps (the first instance of the first game event) but before the second set of one or more timestamps (the second instance of the first game event). The second set of readings is associated with timestamps indicating a time occurring after the first set of one or more timestamps (the first instance of the first game event) and the second set of one or more timestamps (the second instance of the first game event). In box 1280, the process uses the first set of one or more timestamps and the second set of one or more timestamps to determine subsequent game events. In box 1290, the process then presents the subsequent game events on one or more user interfaces, and method 1200 ends.

[0108] Figure 13A flowchart illustrating a method 1300 for presenting the physiological effects of a computer game on two game events, according to certain embodiments of this disclosure, is presented. At block 1020, one or more processors (collectively, “process”) present the game event on one or more user interfaces. At block 1030, the process associates the game event with a first set of one or more timestamps indicating the time the game event was presented on one or more user interfaces. At block 1025, the timestamps are generated by one or more timing means sharing a common time standard. At block 1045, the process associates at least some physiological readings (1035) with corresponding timestamps. The readings (1035) indicate at least one physiological measurement of a user capable of perceiving the game event presented by one or more user interfaces. The respective timestamps associated with the readings (1035) share the same time standard (1025) as used for the one or more timestamps associated with the game event. At block 1350, the process then presents a second game event on one or more user interfaces, and at block 1360, associates the second game event with a second set of one or more timestamps. In box 1270, the process associates a second set of one or more physiological readings (1035) with corresponding timestamps (1025). The first set of readings is associated with timestamps indicating times occurring after the first set of one or more timestamps (first game event) but before the second set of one or more timestamps (second game event). The second set of readings is associated with timestamps indicating times occurring after the first set of one or more timestamps (first game event) and the second set of one or more timestamps (second game event). In box 1380, the process uses the first set of one or more timestamps and the second set of one or more timestamps to determine subsequent game events. In box 1090, the process then presents the subsequent game events on one or more user interfaces, and method 1300 ends.

[0109] In some cases, it may be advantageous to compare the effect of a first stimulus alone with its effect in combination with a second stimulus. Some embodiments use readings generated after each of a plurality of instances of a first game event to determine subsequent game events, where some instances of the first game event are accompanied by a second game event that temporally overlaps with a particular presentation of the first game event. Such embodiments may be advantageous for determining how two stimuli interact. For example, if the first game event includes a bright visual element and the second game event includes a loud sound, some embodiments may compare physiological readings generated after the first game event alone with physiological readings generated after the combined presentation of the first and second game events. In this way, the additional effect of loud sound on bright visual elements can be determined. Some embodiments may compare physiological readings generated after each of the first and second game events presented individually with readings generated after the first and second game events presented in a temporally overlapping manner.

[0110] There are several ways to combine and present the first and second game events, i.e., to overlap them in time. If the first game event is an interval event and the second game event is an instantaneous game event, then overlapping game events can occur when the second game event is presented after the first timestamp associated with the first game event but before the last timestamp associated with the first game event. Conversely, if the second game event is an interval event and the first game event is an instantaneous game event, then overlapping game events can occur when the first game event is presented after the first timestamp associated with the second game event but before the last timestamp associated with the second game event. If both the first and second game events are interval events, overlap can occur when the first timestamp of either game event appears after the first timestamp of the other game event and before the last timestamp of the other game event. When both the first and second game events are instantaneous game events, overlap can be defined based on the maximum time interval between the two game events. To achieve the perceptual effect of two instantaneous game events occurring together, the two game events do not need to be associated with the same timestamp. If the two game events occur within the maximum amount of time they are in, they can functionally overlap, thus appearing to occur in the same time period rather than the same moment. Similarly, when one or two game events are interval events, time overlap can also be defined based on the maximum amount of time between the two events. A start time, an end time, or a function of one or both can be the basis for determining the elapsed time between two game events.

[0111] Figure 14A flowchart illustrating a method 1400 for presenting the physiological effects of a computer game with two instances of a first game event, according to certain embodiments of this disclosure, is presented, where a second instance of the first game event overlaps with a second game event. At block 1020, one or more processors (collectively, “process”) present the game event on one or more user interfaces. At block 1030, the process associates the game event with one or more timestamps from a first set indicating the time at which the game event is presented on one or more user interfaces. At block 1025, the timestamps are generated by one or more timing means sharing a common time standard. At block 1045, the process associates at least some physiological readings (1035) with corresponding timestamps. The readings (1035) indicate at least one physiological measurement of a user capable of perceiving the game event presented by one or more user interfaces. The respective timestamps associated with the readings (1035) share the same time standard (1025) as used for the one or more timestamps associated with the game event. At block 1450, the process then presents a second instance of the first game event overlapping with the first instance of the second game event on one or more processors. The first and second game events may overlap temporally in the various ways described above. In box 1260, the process associates a second instance of the first game event with a second set of one or more timestamps. In box 1360, the process associates the second game event with a third set of one or more timestamps. In box 1470, the process associates a second set of one or more physiological readings (1035) with corresponding timestamps (1025). The first set of readings is associated with timestamps indicating times occurring after the first set of one or more timestamps (the first instance of the first game event) but before the second and third sets of one or more timestamps (the second instances of the first and second game events, respectively). The second set of readings is associated with timestamps indicating times occurring after the first, second, and third sets of one or more timestamps (the first and second instances of the first and second game events, respectively). In box 1480, the process uses the first set of one or more readings and the second set of one or more readings to determine subsequent game events. In box 1090, the process then presents the subsequent game events on one or more user interfaces, and method 1400 ends.

[0112] Figure 15A flowchart illustrating a method 1500 for the physiological effects of a computer game using values ​​corresponding to presented game events, according to certain embodiments of this disclosure, is shown. At block 1020, one or more processors (collectively, “process”) present game events on one or more user interfaces. At block 1030, the process associates the game events with a first set of one or more timestamps indicating the time when the game events were presented on one or more user interfaces. At block 1025, the timestamps are generated by one or more timing means sharing a common time standard. At block 1045, the process associates at least some physiological readings (1035) with corresponding timestamps. The readings (1035) indicate at least one physiological measurement of a user capable of perceiving the game events presented by the one or more user interfaces. The respective timestamps associated with the readings (1035) share the same time standard (1025) as used for the one or more timestamps associated with the game events. At block 1350, the process then presents a second game event on one or more processors, and at block 1360, associates the second game event with a second set of one or more timestamps. At block 1270, the process associates the second set of one or more physiological readings (1035) with corresponding timestamps. The first set of readings is associated with timestamps indicating a time occurring after one or more timestamps in the first set (first game event) but before one or more timestamps in the second set (second game event). The second set of readings is associated with timestamps indicating a time occurring after one or more timestamps in the first set (first game event) and one or more timestamps in the second set (second game event). In box 1580, the process uses one or more readings in the first set, one or more readings in the second set, a first value (1591) corresponding to the measurement of the first game event, and a second value (1592) corresponding to the measurement of the second game event to determine subsequent game events. In box 1090, the process then presents the subsequent game events on one or more user interfaces, and method 1500 ends.

[0113] In some such embodiments, physiological readings indicate heart rate, and the game event metric is a measure of stimulus intensity. Examples of intensity measurements may include volume or volume variation, display monitor brightness or brightness variation, or the number or frequency of visual target stimuli. Based on raw readings of cardiac activity, the process can determine a measurement of heart rate variability (HRV) that may be associated with psychological stress. By presenting two game events with different stimulus intensities and determining the HRV after each event, the process can determine the extent to which the HRV is affected by changing the stimulus intensity and select subsequent game events from which a target HRV level is calculated. Those skilled in the art will understand that selecting subsequent game events expected to elicit the target HRV can be achieved without calculating numbers that explicitly represent the relationship between stimulus intensity and HRV.

[0114] In some such embodiments, the readings indicate the respiratory cycle, and the game event measurement is the stimulus frequency. The stimulus frequency can be represented by a variety of means, from simple things like flashing light to more complex representations like images of flowers opening and closing. In these embodiments, the process determines whether the respiratory cycle occurs at the same or nearly the same frequency as the stimulus frequency. Such embodiments can be used, for example, to reward a user for matching his or her breathing to the rate of the stimulus during interval game events. If the process determines that the breathing rate is sufficiently close to the stimulus rate, subsequent game events can be presented to the user, including, for example, color images and pleasant music.

[0115] Most game events in computer games are influenced by game controls, even if not determined by the game user's conscious manipulation. Common types of game controls include buttons, joysticks, rotatable knobs and wheels, motion detectors in the form of accelerometers and gyroscopes, and cameras that capture user images and couple them with logic to analyze those images. The output of game controls typically manifests as output to one or more user interfaces, whether it be sound or images representing a specific action. Some embodiments of this disclosure may use output from the game controller along with readings from physiological sensors to determine subsequent game events. While game control outputs can serve the general purpose of allowing the user to manipulate the game environment, they can also provide insights into the user's physiological state. For example, measuring a user's reaction time can provide insight into the user's level of fatigue if the user is instructed to react to a game stimulus as quickly as possible. Game control outputs can also be considered game events, and physiological readings can be processed to determine the physiological response to a user's game control actions.

[0116] Similar to game events and physiological readings, embodiments that include outputs from the game controller associate at least some of these outputs with timestamps on the same time standard used to generate the game events and physiological readings. The timestamps indicate when the outputs were generated. The timestamps allow processing to determine when the game control outputs occurred relative to the game events and physiological readings.

[0117] Figure 16A flowchart illustrating a method 1600 for determining the physiological effects of a computer game on subsequent game events using game controller outputs and physiological readings, according to certain embodiments of this disclosure, is presented. At block 1020, one or more processors (collectively, “process”) present game events on one or more user interfaces. At block 1030, the process associates the game events with a first set of one or more timestamps indicating the time when the game events were presented on one or more user interfaces. At block 1025, the timestamps are generated by one or more timing means sharing a common time standard. At block 1045, the process associates at least some physiological readings (1035) with corresponding timestamps. The readings (1035) indicate at least one physiological measurement of a user capable of perceiving the game events presented by the one or more user interfaces. The respective timestamps associated with the readings (1035) share the same time standard (1025) as used for the one or more timestamps associated with the game events. At block 1660, the process associates at least some game control outputs (1655) with corresponding timestamps. The corresponding timestamp associated with the output (1655) shares the same time standard (1025) as the timestamps associated with the game event and the corresponding timestamps associated with the physiological readings (1035). In box 1680, processing uses a first set of one or more readings associated with timestamps across various time ranges relative to the game event, along with at least some game control outputs, to determine subsequent game events. At least one reading in the first set of one or more readings is associated with at least one timestamp corresponding to a time occurring during or after the first set of one or more timestamps (indicating that at least one reading was generated after the start of the first game event). In box 1090, processing then presents the subsequent game event on one or more user interfaces, and method 1600 ends.

[0118] Figure 17A flowchart illustrating a method 1700 for determining a physiological response to a computer game event, according to certain embodiments of the present disclosure, is presented. At block 1020, one or more processors (collectively, “process”) present a game event on one or more user interfaces. At block 1030, the process associates the game event with a first set of one or more timestamps indicating the time the game event was presented on one or more user interfaces. At block 1025, the timestamps are generated by one or more timing means sharing a common time standard. At block 1045, the process associates at least some physiological readings (1035) with corresponding timestamps. Sensor readings (1035) indicate at least one physiological measurement of a user capable of perceiving the game event presented by one or more user interfaces. The respective timestamps associated with the readings (1035) share the same time standard (1025) as used for the one or more timestamps associated with the game event. At block 1770, the process uses the first set of one or more readings to determine a measurement of the physiological response to the game event, and method 1700 ends.

[0119] Figure 18 A flowchart illustrating a method 1800 for predicting a third variable using game event data and physiological readings according to certain embodiments of this disclosure is shown. At box 1020, one or more processors (collectively, “process”) present game events on one or more user interfaces. At box 1030, the process associates the game events with a first set of one or more timestamps indicating the time the game events were presented on one or more user interfaces. At box 1025, the timestamps are generated by one or more timing means sharing a common time standard. At box 1045, the process associates at least some physiological readings (1035) with corresponding timestamps. The readings (1035) indicate at least one physiological measurement of a user capable of perceiving the game events presented by one or more user interfaces. The respective timestamps associated with the readings (1035) share the same time standard (1025) used for the one or more timestamps associated with the game events. At box 1850, the process trains a supervised machine learning model to predict a third measurement variable using the timestamped game events and the timestamped physiological readings. Examples of the third variable may include a user’s diagnosis, treatment, diagnosis of response to single or combined treatments (if any), or a user’s cognitive characteristics. In box 1890, the processing then uses timestamped biosensor readings and timestamped game events to generate predictions for a third variable, and method 1800 concludes.

[0120] The above description is neither exclusive nor exhaustive, and does not necessarily describe all possible embodiments (also referred to as “examples”), and is not intended to limit the scope of the claims. Embodiments may include elements other than those described, and in some cases may include only a subset of the elements described in a particular embodiment. Embodiments may include any combination of elements from the described embodiments, except for elements not explicitly described. As used herein, the articles “a” and “an” may include one or more nouns modified by “an” or “at least one,” without regard to other uses of phrases such as “one or more” or “at least one.” Unless otherwise stated, the word “or” is used inclusively. Terms such as “first,” “second,” and “third” are used as labels to distinguish elements and do not indicate order unless otherwise stated. In addition to the embodiments described above, embodiments include any embodiments that will fall within the scope of the appended claims.

Claims

1. A method comprising: A first instance of a first game event associated with a first set of one or more timestamps is presented by one or more processors and on one or more user interfaces; The system receives a first set of sensor readings from one or more processors and from one or more sensors, indicating at least one physiological measurement of the user, wherein at least one of the first set of sensor readings is associated with a timestamp corresponding to a time occurring during or after the first set of one or more timestamps associated with the first game event; The diagnosis of the user's condition is determined by the one or more processors based on the first set of sensor readings, including the user's at least one physiological measurement; The one or more processors determine subsequent game events based on the diagnosed user condition and using the first set of sensor readings. The subsequent game events include modifiable criteria for determining the completion of the subsequent game events. The modifiable criterion for determining the completion of the subsequent game event is associated with a specific physiological response to be triggered in the user to resolve the user's condition, and completion is considered complete when the specific physiological response occurs. The modifiable standard is modified at least in part based on one or more of the user conditions and the first set of sensor readings; and The subsequent game events are presented by the one or more processors and on the one or more interfaces.

2. The method according to claim 1, further comprising: The subsequent game event is determined using a second set of sensor readings, at least one of which is associated with a timestamp indicating a time prior to any of the first set of one or more timestamps. as well as The function of the first set of sensor readings is compared with the function of the second set of sensor readings.

3. The method according to claim 1, further comprising: A second instance of the first game event is presented on one or more interfaces; Associate the second instance of the first game event with one or more timestamps in the second group; as well as The subsequent game event is determined using a second set of sensor readings, at least one of which is associated with a timestamp corresponding to a time that occurs during or after one or more of the second set of timestamps.

4. The method according to claim 3, further comprising: A second instance of the first game event is presented through one or more interfaces; The second instance of the first game event is associated with a third set of timestamps, at least one of which corresponds to a time occurring at: Before the first time indicated by at least one of the timestamps in the second group of one or more timestamps; as well as After the second time indicated by at least one of the timestamps in the second group of one or more timestamps.

5. The method according to claim 3, further comprising: A second instance of the first game event is presented through one or more interfaces; as well as The second instance of the first game event is associated with a third set of timestamps, at least one of which corresponds to a time that occurs within a maximum amount of time indicated by at least one of the timestamps in the second set of one or more timestamps.

6. The method according to claim 1, further comprising: The second game event is presented through one or more of the interfaces; Associate the second game event with one or more timestamps in the second group; as well as The subsequent game event is determined using a second set of sensor readings, at least one of which is associated with a timestamp corresponding to a time that occurs during or after one or more of the second set of timestamps.

7. The method according to claim 6, wherein: The one or more sensors include sensors that measure cardiac activity; The one or more processors use the first set of sensor readings to generate a first measurement of heart rate variability; The one or more processors use the second set of sensor readings to generate a second measurement of heart rate variability; as well as The one or more processors use measurements of the relationship between heart rate variability and stimulus intensity to determine the subsequent game events.

8. The method according to claim 6, wherein: The one or more sensors include sensors that measure the user's breathing; The one or more processors use the first set of sensor readings to generate a first measurement of respiratory rate; The one or more processors use the second set of sensor readings to generate a second measurement of respiratory rate; as well as The one or more processors use a measurement of the relationship between breathing rate and stimulation rate to determine the subsequent game events.

9. The method according to claim 1, further comprising: Receive output from one or more game control devices, the output indicating the user's actions and associated with corresponding timestamps; as well as The subsequent game event is determined using one or more of the outputs, at least one of the outputs being associated with a timestamp corresponding to a time that occurs during or after the first set of one or more timestamps.

10. The method according to claim 1, wherein, The first instance of the first game event is associated with an event data array, which includes time, name, and one or more expected data fields defined for the type of the first game event.

11. The method according to claim 1, wherein, The subsequent game events are presented to the user as part of the resolution of the diagnosed user condition, wherein the diagnosed user condition is determined automatically and implicitly based on the first set of sensor readings.

12. The method according to claim 1, further comprising: Receive a second set of sensor readings from the one or more sensors, indicating at least one physiological measurement of the user; Based on whether the second set of sensor readings describes the specific physiological response elicited in the user in response to the subsequent game event, it is determined whether the modifiable criteria used to determine completion are met; and In response to determining whether the modifiable criteria used to determine completion satisfy one or more of the following: The second subsequent game event is determined at least in part based on the readings of the second set of sensors, and the second subsequent game event is presented. as well as Modify the diagnosed user condition associated with the user, wherein the diagnosed user condition was initially determined based on the first set of sensor readings.

13. A system comprising: One or more processors; as well as A memory for storing instructions, which, when executed by the one or more processors, cause the system to: Present a first instance of a first game event associated with a first set of one or more timestamps on one or more user interfaces; Receive a first set of sensor readings from one or more sensors that indicate at least one physiological measurement of the user, wherein at least one of the first set of sensor readings is associated with a timestamp that corresponds to a time that occurs during or after the first set of one or more timestamps; The first set of sensor readings is used to determine subsequent game events. The subsequent game events include modifiable criteria for determining the completion of the subsequent game events. The modifiable criterion for determining the completion of the subsequent game event is associated with a specific physiological response to be triggered in the user to resolve the user's condition, and completion is considered complete when the specific physiological response occurs. The modifiable standard is modified at least in part based on one or more of the user conditions and the first set of sensor readings; and The subsequent game events are presented on one or more of the interfaces.

14. The system of claim 13, wherein the memory further stores instructions that, when executed by the one or more processors, cause the system to: The subsequent game event is determined using a second set of sensor readings, at least one of which is associated with a timestamp indicating a time prior to any timestamp in the first set of one or more timestamps; and The function of the first set of sensor readings is compared with the function of the second set of sensor readings.

15. The system of claim 13, wherein the memory further stores instructions that, when executed by the one or more processors, cause the system to: Presenting a second instance of the first game event on one or more interfaces; associating the second instance of the first game event with a second set of one or more timestamps; and The subsequent game event is determined using a second set of sensor readings, at least one of which is associated with a timestamp corresponding to a time that occurs during or after one or more of the second set of timestamps.

16. The system of claim 15, wherein the memory further stores instructions that, when executed by the one or more processors, cause the system to: A second instance of the first game event is presented through one or more interfaces; The second instance of the first game event is associated with a third set of timestamps, at least one of which corresponds to a time occurring at: Before the first time indicated by at least one of the timestamps in the second group of one or more timestamps; and After the second time indicated by at least one of the timestamps in the second group of one or more timestamps.

17. The system of claim 15, wherein the memory further stores instructions that, when executed by the one or more processors, cause the system to: A second instance of the first game event is presented through one or more interfaces; and The second instance of the first game event is associated with a third set of timestamps, at least one of which corresponds to a time that occurs within a maximum amount of time indicated by at least one of the timestamps in the second set of one or more timestamps.

18. The system of claim 13, wherein the memory further stores instructions that, when executed by the one or more processors, cause the system to: The second game event is presented through one or more of the interfaces; Associate the second game event with one or more timestamps in the second group; as well as The subsequent game event is determined using a second set of sensor readings, at least one of which is associated with a timestamp corresponding to a time that occurs during or after one or more of the second set of timestamps.

19. The system of claim 13, wherein the memory further stores instructions that, when executed by the one or more processors, cause the system to: Receive output from one or more game control devices, the output indicating the user's actions and associated with corresponding timestamps; and The subsequent game event is determined using one or more of the outputs, at least one of the outputs being associated with a timestamp corresponding to a time that occurs during or after the first set of one or more timestamps.

20. The system of claim 13, wherein the first instance of the first game event is associated with an event data array, the event data array including time, name, and one or more expected data fields, the one or more expected data fields being defined for the type of the first game event.

Images