Electronic device for providing information for health care

Abstract

This wearable electronic device comprises: a sensor; a processor; and a memory for storing instructions. The instructions, when executed by the processor, may cause the electronic device to: periodically acquire sensor values from the sensor; and acquire a plurality of samples by extracting some of the sensor values acquired from the sensor. The instructions, when executed by the processor, may cause the electronic device to: generate first information related to health by using the samples; and store, in the memory, log data including the first information and the samples. The instructions, when executed by the processor, may cause the electronic device to: generate second information by using the samples in the log data, on the basis that an event requesting verification of the first information has occurred; compare the second information with the first information; and determine the integrity of the first information on the basis of the result of the comparison.

Description

Electronic devices that provide information for health management

[0001] The present disclosure relates to an electronic device that provides information for health management, for example, a wearable electronic device that provides information used for health management of a user.

[0002] Wearable electronic devices (e.g., smart watches, smart rings) may be equipped with various sensors (e.g., accelerometers, barometric pressure sensors, optical sensors, biometric sensors). The information collected using these sensors can be used as raw data to provide health or wellness information (e.g., step counts, arrhythmias, respiration rate, sleep quality, blood pressure, etc.) for the user wearing the wearable electronic device.

[0003] The above information is provided as background information to aid in understanding the present disclosure. No claim or determination is made as to whether any of the above is applicable as prior art related to the present disclosure.

[0004] Wearable electronic devices can use software development kits (SDKs) to generate health-related information from raw data obtained from sensors.

[0005] Wearable electronic devices can have low-power software architectures capable of multitasking. In such architectures, there may be a difference between the raw data obtained from sensors (sensor values) and the input values ​​fed into the algorithms that utilize the raw data (algorithm input values).

[0006] For example, in a clinical study related to sleep, blood oxygen saturation (SpO2) can be determined during sleep. An electronic device can acquire raw data from an accelerometer and a photoplethysmography (PPG) sensor, use the acquired raw data to determine the start and end times of sleep, and check SpO2 while the user is sleeping. If the desired data frequency (sample rate) for the clinical study is, for example, 25 Hz, but the accelerometer only supports a higher data frequency, this will cause an increase in current consumption in the accelerometer, and thus the logging task for recording raw data may not be performed for a period of time (for example, 10 hours) desired by the user (for example, the developer) for the clinical study.

[0007] Data frequencies and event occurrence cycles may vary by sensor. Therefore, separate processing may be required to synchronize the time at which raw data is generated. Synchronization issues can occur continuously within the processor (e.g., the sensor hub processor) and / or the framework.

[0008] When new sensors and algorithms are added to a device, related SDKs may also need to be added. For clinical applications, data integrity may be required. For example, procedures may be needed to verify that sensor values ​​are actually used as algorithm inputs.

[0009] In an embodiment of the present disclosure, the electronic device can perform long-term logging and ensure the integrity of data.

[0010] The technical problems to be achieved in the present disclosure are not limited to the technical problems mentioned above, and other technical problems not mentioned will be clearly understood by a person having ordinary skill in the technical field to which the present disclosure pertains from the description below.

[0011] According to one embodiment, a wearable electronic device includes a sensor; a processor; and a memory storing instructions. The instructions, when executed by the processor, may cause the electronic device to periodically acquire sensor values ​​from the sensor and to acquire a plurality of samples by extracting some of the sensor values ​​acquired from the sensor. The instructions, when executed by the processor, may cause the electronic device to generate first information related to health using the samples, and to store log data including the first information and the samples in the memory. The instructions, when executed by the processor, may cause the electronic device to generate second information using the samples from the log data based on the occurrence of an event requesting verification of the first information, compare the second information with the first information, and determine whether the first information is intact based on a result of the comparison.

[0012] According to one embodiment, a wearable electronic device may include a sensor; a communication circuit; a processor; and a memory storing instructions. The instructions, when executed by the processor, may cause the electronic device to periodically obtain a sensor value from the sensor and to obtain a plurality of samples by extracting some of the sensor values ​​obtained from the sensor. The instructions, when executed by the processor, may cause the electronic device to generate first information related to health using the samples and to store log data including the first information and the samples in the memory. The instructions, when executed by the processor, may cause the electronic device to transmit the log data to an external electronic device through the communication circuit based on the occurrence of an event requesting verification of the first information.

[0013] According to one embodiment, a method of operating a wearable electronic device is provided. The method may include: obtaining a plurality of samples by extracting some of sensor values ​​obtained from a sensor of the wearable electronic device; generating first information related to health using the samples; and storing log data including the first information and the samples in a memory of the wearable electronic device. The method may include generating second information using the samples in the log data based on the occurrence of an event requesting verification of the first information, comparing the second information with the first information, and determining whether the first information is intact based on a result of the comparison.

[0014] According to embodiments of the present disclosure, an electronic device can perform long-term logging and ensure data integrity. Furthermore, various benefits, directly or indirectly identified through this document, may be provided.

[0015] FIG. 1 is a block diagram of an electronic device within a network environment according to various embodiments.

[0016] FIGS. 2A and 2B are front and rear perspective views of a wearable electronic device having a wrist-worn structure, according to one embodiment.

[0017] FIG. 3 illustrates a hierarchical architecture of an electronic device according to one embodiment.

[0018] FIG. 4 is a flowchart illustrating operations performed in an electronic device (300) based on the electronic device being set to a sleep mode, according to one embodiment.

[0019] FIG. 5 is a flowchart illustrating operations performed in an electronic device (300) based on the electronic device being set to an exercise mode, according to one embodiment.

[0020] FIG. 6 is a flowchart illustrating operations performed in an electronic device (300) based on the electronic device being set to a user-defined mode, according to one embodiment.

[0021] FIG. 7a is a diagram for explaining a scenario in which the integrity of the sensor algorithm is not secured in the electronic device of FIG. 3, and FIG. 7b is a diagram for explaining a scenario in which the integrity of the sensor algorithm is secured by a virtual sensor according to one embodiment.

[0022] FIG. 8 is a flowchart illustrating operations performed in an electronic device according to one embodiment.

[0023] FIG. 9a and FIG. 9b illustrate examples of user interface (UI) screens displayed on an electronic device.

[0024] FIG. 10 is a flowchart illustrating operations for data logging in an electronic device according to one embodiment.

[0025] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the drawings so that those skilled in the art can easily implement the present disclosure. However, the present disclosure may be implemented in various different forms and is not limited to the embodiments described herein. In connection with the description of the drawings, the same or similar reference numerals may be used for identical or similar components. Furthermore, in the drawings and related descriptions, descriptions of well-known functions and configurations may be omitted for clarity and conciseness.

[0026] FIG. 1 is a block diagram of an electronic device (101) within a network environment (100) according to various embodiments. Referring to FIG. 1, in the network environment (100), the electronic device (101) may communicate with an electronic device (102) via a first network (198) (e.g., a short-range wireless communication network), or may communicate with at least one of an electronic device (104) or a server (108) via a second network (199) (e.g., a long-range wireless communication network). According to one embodiment, the electronic device (101) may communicate with the electronic device (104) via the server (108). According to one embodiment, the electronic device (101) may include a processor (120), a memory (130), an input module (150), an audio output module (155), a display module (160), an audio module (170), a sensor module (176), an interface (177), a connection terminal (178), a haptic module (179), a camera module (180), a power management module (188), a battery (189), a communication module (190), a subscriber identification module (196), or an antenna module (197). In some embodiments, the electronic device (101) may omit at least one of these components (e.g., the connection terminal (178)), or may have one or more other components added. In some embodiments, some of these components (e.g., the sensor module (176), the camera module (180), or the antenna module (197)) may be integrated into one component (e.g., the display module (160)).

[0027] The processor (120) may, for example, execute software (e.g., a program (140)) to control at least one other component (e.g., a hardware or software component) of the electronic device (101) connected to the processor (120) and perform various data processing or calculations. According to one embodiment, as at least a part of the data processing or calculations, the processor (120) may store commands or data received from other components (e.g., a sensor module (176) or a communication module (190)) in a volatile memory (132), process the commands or data stored in the volatile memory (132), and store result data in a non-volatile memory (134). According to one embodiment, the processor (120) may include a main processor (121) (e.g., a central processing unit or an application processor) or a secondary processor (123) (e.g., a graphics processing unit, a neural processing unit (NPU), an image signal processor, a sensor hub processor, or a communication processor)) that can operate independently or together therewith. For example, if the electronic device (101) includes a main processor (121) and a secondary processor (123), the secondary processor (123) may be configured to use less power than the main processor (121) or to be specialized for a specified function. The secondary processor (123) may be implemented separately from the main processor (121) or as a part thereof.

[0028] The auxiliary processor (123) may control at least a portion of functions or states associated with at least one component (e.g., a display module (160), a sensor module (176), or a communication module (190)) of the electronic device (101), for example, on behalf of the main processor (121) while the main processor (121) is in an inactive (e.g., sleep) state, or together with the main processor (121) while the main processor (121) is in an active (e.g., application execution) state. In one embodiment, the auxiliary processor (123) (e.g., an image signal processor or a communication processor) may be implemented as a part of another functionally related component (e.g., a camera module (180) or a communication module (190)). In one embodiment, the auxiliary processor (123) (e.g., a neural network processing unit) may include a hardware structure specialized for processing artificial intelligence models. The artificial intelligence models may be generated through machine learning. This learning can be performed, for example, on the electronic device (101) itself where the artificial intelligence model is executed, or can be performed through a separate server (e.g., server (108)). The learning algorithm can include, for example, supervised learning, unsupervised learning, semi-supervised learning, or reinforcement learning, but is not limited to the examples described above. The artificial intelligence model can include multiple artificial neural network layers.The artificial neural network may be one of a deep neural network (DNN), a convolutional neural network (CNN), a recurrent neural network (RNN), a restricted Boltzmann machine (RBM), a deep belief network (DBN), a bidirectional recurrent deep neural network (BRDNN), a deep Q-network, or a combination of two or more of the above, but is not limited to the examples described above. In addition to, or alternatively to, a hardware structure, an artificial intelligence model may include a software structure.

[0029] The memory (130) can store various data used by at least one component (e.g., processor (120) or sensor module (176)) of the electronic device (101). The data can include, for example, software (e.g., program (140)) and input data or output data for commands related thereto. The memory (130) can include volatile memory (132) or non-volatile memory (134).

[0030] The program (140) may be stored as software in the memory (130) and may include, for example, an operating system (142), middleware (144), or an application (146).

[0031] The input module (150) can receive commands or data to be used in a component of the electronic device (101) (e.g., a processor (120)) from an external source (e.g., a user) of the electronic device (101). The input module (150) can include, for example, a microphone, a mouse, a keyboard, a key (e.g., a button), or a digital pen (e.g., a stylus pen).

[0032] The audio output module (155) can output audio signals to the outside of the electronic device (101). The audio output module (155) can include, for example, a speaker or a receiver. The speaker can be used for general purposes, such as multimedia playback or recording playback. The receiver can be used to receive incoming calls. In one embodiment, the receiver can be implemented separately from the speaker or as part of the speaker.

[0033] The display module (160) can visually provide information to an external party (e.g., a user) of the electronic device (101). The display module (160) may include, for example, a display, a holographic device, or a projector and a control circuit for controlling the device. In one embodiment, the display module (160) may include a touch sensor configured to detect a touch, or a pressure sensor configured to measure the intensity of a force generated by the touch.

[0034] The audio module (170) can convert sound into an electrical signal, or vice versa, convert an electrical signal into sound. According to one embodiment, the audio module (170) can acquire sound through the input module (150), output sound through the sound output module (155), or an external electronic device (e.g., electronic device (102)) (e.g., speaker or headphone) directly or wirelessly connected to the electronic device (101).

[0035] The sensor module (176) can detect the operating status (e.g., power or temperature) of the electronic device (101) or the external environmental status (e.g., user status) and generate an electrical signal or data value corresponding to the detected status. According to one embodiment, the sensor module (176) can include, for example, a gesture sensor, a gyro sensor, a barometric pressure sensor, a magnetic sensor, an acceleration sensor, a grip sensor, a proximity sensor, a color sensor, an IR (infrared) sensor, a biometric sensor, a temperature sensor, a humidity sensor, or an illuminance sensor.

[0036] The interface (177) may support one or more designated protocols that may be used to directly or wirelessly connect the electronic device (101) with an external electronic device (e.g., the electronic device (102)). In one embodiment, the interface (177) may include, for example, a high definition multimedia interface (HDMI), a universal serial bus (USB) interface, an SD card interface, or an audio interface.

[0037] The connection terminal (178) may include a connector through which the electronic device (101) may be physically connected to an external electronic device (e.g., electronic device (102)). According to one embodiment, the connection terminal (178) may include, for example, an HDMI connector, a USB connector, an SD card connector, or an audio connector (e.g., a headphone connector).

[0038] A haptic module (179) can convert electrical signals into mechanical stimuli (e.g., vibration or movement) or electrical stimuli that a user can perceive through tactile or kinesthetic sensations. In one embodiment, the haptic module (179) can include, for example, a motor, a piezoelectric element, or an electrical stimulation device.

[0039] The camera module (180) can capture still images and videos. According to one embodiment, the camera module (180) may include one or more lenses, image sensors, image signal processors, or flashes.

[0040] The power management module (188) can manage power supplied to the electronic device (101). According to one embodiment, the power management module (188) can be implemented, for example, as at least a part of a power management integrated circuit (PMIC).

[0041] A battery (189) may power at least one component of the electronic device (101). In one embodiment, the battery (189) may include, for example, a non-rechargeable primary battery, a rechargeable secondary battery, or a fuel cell.

[0042] The communication module (190) may support the establishment of a direct (e.g., wired) communication channel or a wireless communication channel between the electronic device (101) and an external electronic device (e.g., electronic device (102), electronic device (104), or server (108)), and the performance of communication through the established communication channel. The communication module (190) may operate independently from the processor (120) (e.g., application processor) and may include one or more communication processors that support direct (e.g., wired) communication or wireless communication. According to one embodiment, the communication module (190) may include a wireless communication module (192) (e.g., a cellular communication module, a short-range wireless communication module, or a global navigation satellite system (GNSS) communication module) or a wired communication module (194) (e.g., a local area network (LAN) communication module, or a power line communication module). Among these communication modules, the corresponding communication module can communicate with an external electronic device (104) via a first network (198) (e.g., a short-range communication network such as Bluetooth, wireless fidelity (WiFi) direct, or infrared data association (IrDA)) or a second network (199) (e.g., a long-range communication network such as a legacy cellular network, a 5G network, a next-generation communication network, the Internet, or a computer network (e.g., a LAN or WAN)). These various types of communication modules can be integrated into a single component (e.g., a single chip) or implemented as multiple separate components (e.g., multiple chips). The wireless communication module (192) can verify or authenticate the electronic device (101) within a communication network such as the first network (198) or the second network (199) by using subscriber information (e.g., an international mobile subscriber identity (IMSI)) stored in the subscriber identification module (196).

[0043] The wireless communication module (192) can support 5G networks and next-generation communication technologies following the 4G network, such as NR access technology (new radio access technology). The NR access technology can support high-speed transmission of high-capacity data (eMBB (enhanced mobile broadband)), minimization of terminal power and connection of multiple terminals (mMTC (massive machine type communications)), or high reliability and low latency (URLLC (ultra-reliable and low-latency communications)). The wireless communication module (192) can support, for example, a high-frequency band (e.g., mmWave band) to achieve a high data transmission rate. The wireless communication module (192) can support various technologies for securing performance in a high-frequency band, such as beamforming, massive multiple-input and multiple-output (MIMO), full dimensional MIMO (FD-MIMO), array antenna, analog beam-forming, or large scale antenna. The wireless communication module (192) can support various requirements specified in the electronic device (101), an external electronic device (e.g., the electronic device (104)), or a network system (e.g., the second network (199)). According to one embodiment, the wireless communication module (192) can support a peak data rate (e.g., 20 Gbps or more) for eMBB realization, a loss coverage (e.g., 164 dB or less) for mMTC realization, or a U-plane latency (e.g., 0.5 ms or less for downlink (DL) and uplink (UL), or 1 ms or less for round trip) for URLLC realization.

[0044] The antenna module (197) can transmit or receive signals or power to or from an external device (e.g., an external electronic device). In one embodiment, the antenna module (197) may include an antenna including a radiator formed of a conductor or a conductive pattern formed on a substrate (e.g., a PCB). In one embodiment, the antenna module (197) may include a plurality of antennas (e.g., an array antenna). In this case, at least one antenna suitable for a communication method used in a communication network, such as the first network (198) or the second network (199), may be selected from the plurality of antennas by, for example, the communication module (190). A signal or power may be transmitted or received between the communication module (190) and an external electronic device through the selected at least one antenna. In some embodiments, in addition to the radiator, another component (e.g., a radio frequency integrated circuit (RFIC)) may be additionally formed as a part of the antenna module (197).

[0045] According to various embodiments, the antenna module (197) may form a mmWave antenna module. According to one embodiment, the mmWave antenna module may include a printed circuit board, an RFIC disposed on or adjacent a first side (e.g., a bottom side) of the printed circuit board and capable of supporting a designated high-frequency band (e.g., a mmWave band), and a plurality of antennas (e.g., an array antenna) disposed on or adjacent a second side (e.g., a top side or a side side) of the printed circuit board and capable of transmitting or receiving signals in the designated high-frequency band.

[0046] At least some of the above components can be interconnected and exchange signals (e.g., commands or data) with each other via a communication method between peripheral devices (e.g., a bus, GPIO (general purpose input and output), SPI (serial peripheral interface), or MIPI (mobile industry processor interface)).

[0047] According to one embodiment, commands or data may be transmitted or received between the electronic device (101) and an external electronic device (104) via a server (108) connected to a second network (199). Each of the external electronic devices (102 or 104) may be the same or a different type of device as the electronic device (101). According to one embodiment, all or part of the operations executed in the electronic device (101) may be executed in one or more of the external electronic devices (102, 104, or 108). For example, when the electronic device (101) is to perform a certain function or service automatically or in response to a request from a user or another device, the electronic device (101) may, instead of or in addition to executing the function or service itself, request one or more external electronic devices to perform the function or at least a part of the service. One or more external electronic devices that receive the request may execute at least a portion of the requested function or service, or an additional function or service related to the request, and transmit the result of the execution to the electronic device (101). The electronic device (101) may process the result as is or additionally and provide it as at least a portion of a response to the request. For this purpose, cloud computing, distributed computing, mobile edge computing (MEC), or client-server computing technology may be used, for example. The electronic device (101) may provide an ultra-low latency service by using distributed computing or mobile edge computing, for example. In one embodiment, the external electronic device (104) may include an Internet of Things (IoT) device. The server (108) may be an intelligent server using machine learning and / or a neural network. According to one embodiment, the external electronic device (104) or the server (108) may be included in the second network (199).The electronic device (101) can be applied to intelligent services (e.g., smart home, smart city, smart car, or healthcare) based on 5G communication technology and IoT-related technology.

[0048] In various embodiments of the present disclosure, a wearable electronic device is defined as a device having a structure that can be worn on the human body. For example, a smart watch worn on the wrist or a smart ring worn on the finger may be classified as a wearable electronic device.

[0049] FIGS. 2A and 2B are front and rear perspective views of a wearable electronic device (200) having a structure wearable on a wrist, according to one embodiment.

[0050] Referring to FIGS. 2A and 2B, a wearable electronic device (200) (e.g., electronic device (101) or electronic device (102) in FIG. 1) may include a housing (210) including a first side (or front side, a side viewed from above in a downward direction (e.g., -z direction)) (210A), a second side (or back side, a side viewed from below in a upward direction (e.g., z direction)) (210B), and a side surface (210C) surrounding a space between the first side (210A) and the second side (210B), and a fastening member (250, 260) (e.g., a strap, a connecting member, and / or a joining member) connected to at least a portion of the housing (210) and configured to removably fasten the wearable electronic device (200) to a user's wrist. In one embodiment (not shown), the housing (210) may refer to a structure forming a portion of the first side (210A), the second side (210B), and the side surface (210C) of FIG. 2A. The housing (210) may have various shapes other than the illustrated circular shape (e.g., square, rounded square).

[0051] The first side (210A) may be formed by a front plate (201) that is at least partially substantially transparent (e.g., a glass plate or a polymer plate including various coating layers). The second side (210B) may be formed by a substantially opaque back plate (207). The back plate (207) may be formed by, for example, coated or colored glass, ceramic, polymer, metal (e.g., aluminum, stainless steel (STS), or magnesium), and / or a combination of at least two of the foregoing materials. The side surface (210C) may be formed by a side bezel structure (or “side member”) (206) that is joined to the front plate (201) and the back plate (207) and includes a metal and / or a polymer.

[0052] The wearable electronic device (200) may include at least one of a display (220) (e.g., a display module (160) of FIG. 1), an audio module (205, 208) (e.g., an audio module (170) of FIG. 1), a biosensor (211) (e.g., a sensor module (176) of FIG. 1), a key input device (202, 203, 204) (e.g., an input module (150) of FIG. 1), and a connector hole (209) (e.g., a connection terminal (178) of FIG. 1). The electronic device (200) may omit at least one of the components (e.g., the key input device (202, 203, 204) and / or the connector hole (209)) or may additionally include other components. For example, a wearable electronic device (200) may include a processor (e.g., a processor (210) of FIG. 1), a memory (e.g., a memory (130) of FIG. 1), a flexible printed circuit board (FPCB), a communication module (e.g., a communication module (190) of FIG. 1), a battery (e.g., a battery (189) of FIG. 1), a power management integrated circuit (PMIC) (e.g., a power management module (188) of FIG. 1), and an antenna module (e.g., an antenna module (197) of FIG. 1).

[0053] The display (220) may be visually exposed through a significant portion of the front plate (201). The shape of the display (220) may correspond to the shape of the front plate (201), and may have various shapes such as a circle, an oval, and / or a polygon. The display (220) may be combined with or disposed adjacent to a touch detection circuit, a pressure sensor capable of measuring the intensity (pressure) of a touch, and / or a fingerprint sensor.

[0054] The audio module (205, 208) may include a microphone hole (205) and a speaker hole (208). The microphone hole (205) may have a microphone positioned therein for acquiring external sounds, and in some embodiments, multiple microphones may be positioned therein to detect the direction of sounds. The speaker hole (208) may be used as an external speaker and a receiver for calls. In some embodiments, the speaker hole (208) and the microphone hole (205) may be implemented as a single hole, or a speaker (e.g., a piezo speaker) may be included without the speaker hole (208).

[0055] The biometric sensor (211) may be placed on the second surface (210B) of the housing (210). The wearable electronic device (200) may further include various sensors in addition to the biometric sensor (211). For example, the wearable electronic device (200) may further include at least one of a Hall sensor (e.g., Hall IC) (in other words, a magnetic sensor), a gesture sensor, a gyro sensor, a barometric pressure sensor, a magnetic sensor, an acceleration sensor, a grip sensor, a color sensor, an IR (infrared) sensor, a temperature sensor, a humidity sensor, an illuminance sensor, and an electrode sensor.

[0056] The key input device (202, 203, 204) may include an annular member (202) (e.g., a bezel housing, a rotatable wheel, a wheel key) disposed on a first surface (210A) of the housing (210) and rotatable in at least one direction, and / or a side key button (203, 204) disposed on a side surface (210C) of the housing (210). For example, the key button (203, 204) may include a physical button, a watch crown, or a sensor that responds to touch or pressure. The key button (203, 204) may include a metal through which an electrical signal is transmitted. Accordingly, the button (203, 204) may be utilized as an interface for an electrode sensor. The annular member (202) may have a shape corresponding to the shape of the front plate (201). The annular member (202) can rotate clockwise or counterclockwise about the center of the display (220). The wearable electronic device (200) may not include some or all of the above-described key input devices (202, 203, 204), and the key input devices (202, 203, 204) that are not included may be implemented in other forms, such as soft keys, on the display (220). The connector hole (209) may include another connector hole (not shown) that can accommodate a connector (e.g., a USB connector) for transmitting and receiving power and / or data with an external electronic device (e.g., a smart phone or a TA (travel adapter)) and can accommodate a connector for transmitting and receiving audio signals with the external electronic device. The electronic device (200) may further include, for example, a connector cover (not shown) that covers at least a portion of the connector hole (209) and blocks the inflow of external foreign substances into the connector hole.

[0057] The fastening member (250, 260) can be detachably fastened to at least a portion of the housing (210) using the locking member (251, 261). The fastening member (250, 260) can include one or more of a fixing member (252), a fixing member fastening hole (253), a band guide member (254), and a band fastening ring (255). The fastening member (252) can be configured to fasten the housing (210) and the fastening member (250, 260) to a part of the user's body (e.g., a wrist and / or an ankle). The fastening member fastening hole (253) can fasten the housing (210) and the fastening member (250, 260) to a part of the user's body in response to the fastening member (252). The band guide member (254) is configured to limit the range of movement of the fixing member (252) when the fixing member (252) is fastened to the fixing member fastening hole (253), thereby allowing the fastening member (250, 260) to be fastened in close contact with a part of the user's body. The band fastening ring (255) can limit the range of movement of the fastening member (250, 260) when the fixing member (252) and the fixing member fastening hole (253) are fastened.

[0058] FIG. 3 illustrates a hierarchical architecture of an electronic device (300) according to one embodiment. Referring to FIG. 3, the electronic device (300) (e.g., the electronic device (201) of FIG. 1 or the wearable electronic device (200) of FIG. 2) may include software (301) and hardware (302). The software (301) (e.g., the program (140) of FIG. 1) may include an operating system (303), middleware (304) (e.g., a framework), and an application (305). The hardware (302) may include a sensor (310), a display (315), a communication circuit (317), a memory (388), and a processor (399). The operating system (303) (e.g., the operating system (142) of FIG. 1) may include a sensor driver (321), a sensor algorithm (323), a virtual sensor (325), a virtual sensor controller (327), a kernel (330), and a hardware abstraction layer (HAL) (333). The middleware (304) (e.g., the middleware (144) of FIG. 1) may include a sensor manager (340). The application (305) (e.g., the application (146) of FIG. 1) may include a data log application (351) and a tracking application (353).

[0059] The sensor manager (340) may include a sensor SDK. The sensor SDK may provide the sensor manager (340) with an interface for obtaining the sensor value (raw data) generated by the sensor (310) from the sensor driver (321). The sensor SDK may provide the sensor manager (340) with an interface for obtaining health-related information (e.g., output value) generated by using the sensor value in the sensor algorithm (323) from the sensor algorithm (323). The sensor manager (340) may obtain data (e.g., sensor value, output value) from the sensor driver (321) or the sensor algorithm (323) through the interface provided by the sensor SDK and provide it to the application (305). For example, the sensor manager (340) may include an acceleration SDK (341) for connection with an acceleration driver (321a), a PPG SDK (342) for connection with a PPG driver (321b), a pressure SDK (343) for connection with a pressure driver (321c), a sleep time SDK (344) for connection with a sleep time determination module (361), a sleep state SDK (345) for connection with a sleep state determination module (362), an HR SDK (346) for connection with a HR / RRI (RR intervals) determination module (365), an SpO2 SDK (347) for connection with an SpO2 acquisition module (363), a VO2Max SDK (348) for connection with a VO2Max (maximum oxygen uptake) acquisition module (364), and an RRI SDK (349) for connection with a HR / RRI determination module (365). Here, RRI may represent the interval between the peaks of two consecutive R waves. In one embodiment, the sensor manager (340) may include a virtual sensor SDK (350). The virtual sensor SDK (350) may provide the sensor manager (340) with an interface for obtaining data from the virtual sensor (325).The sensor manager (340) can obtain data from the virtual sensor (325) through the virtual sensor SDK (350) and provide it to the application (305). According to one embodiment, instead of the virtual sensor SDK (350) being configured in the sensor manager (340), a virtual sensor manager (360) having the same function as the virtual sensor SDK (350) (e.g., obtaining data from the virtual sensor (325) and providing it to the application (305)) may be separately configured in the middleware (304).

[0060] The tracking application (353) can check the input / output values ​​of the sensor driver (321) and / or the sensor algorithm (323) corresponding to the operation mode (e.g., sleep mode, exercise mode, custom mode) currently set in the electronic device (300) through the sensor manager (340) or the virtual sensor manager (360) and provide the input / output values ​​to the data log application (351). The data log application (351) can collect log data corresponding to the operation mode currently set in the electronic device (300) through the tracking application (353).

[0061] The memory (388) may include non-volatile memory (e.g., non-volatile memory (134) of FIG. 1) and volatile memory (e.g., volatile memory (132) of FIG. 1). Software (301) may be stored as instructions in the non-volatile memory and loaded into the volatile memory to be executed by the processor (399). According to one embodiment, the processor (399) may include a sensor hub processor (e.g., a low-power sensor processor) configured to be driven at low power. The sensor driver (321), the sensor algorithm (323), the virtual sensor (325), and the controller (327) may be loaded into the volatile memory and executed by the sensor hub processor.

[0062] A sensor (310) (e.g., sensor module (176) of FIG. 1) may be configured to generate raw data used to provide health-related information of a user wearing an electronic device (300). According to one embodiment, the sensor (310) may include a biometric sensor (311) and a motion sensor (312).

[0063] A biosensor (311) (e.g., a biosensor (211) of FIG. 2) may be configured to generate a biosignal (e.g., a signal indicating the intensity of blood flow, a signal indicating the speed of blood flow, a signal indicating the intensity of a heartbeat, a signal indicating the cycle of a heartbeat, a signal indicating a change in the amount of blood in a blood vessel) as raw data used to obtain bioinformation of a user (e.g., blood pressure, blood oxygen saturation (SpO2), heart rate (HR), heart rate variability (HRV)). For example, the biosensor (311) may include a heart rate monitoring (HRM) sensor, a photoplethysmogram (PPG) sensor, an electrocardiogram (ECG) sensor, an optical blood flow measurement sensor, an optical volumetric pulse wave measurement sensor, or an optical volumetric measurement sensor.

[0064] According to one embodiment, the biosensor (311) may include an optical sensor (e.g., a photoplethysmogram (PPG) sensor). The optical sensor may include an emitter and a receiver. The light emitting unit can emit light of various bands (e.g., green, red, infrared (IR), blue, yellow, ultraviolet (UV). For example, the light emitting unit can include an LED, a laser, or a vertical cavity surface emitting laser (VCSEL). The light receiving unit (Receiver) can receive light reflected or transmitted from the light emitting unit. The optical signal received by the light receiving unit can be converted into a digital signal (biometric value) by an analog to digital converter (ADC) and stored in a memory (388) or a buffer configured in the sensor (310) by the control unit of the sensor (310). The light receiving unit can include a photodiode or a CMOS (camera). The light receiving unit can include a filter. The light receiving unit can receive light of a specific band through the filter or filter out light other than a specific band. The control unit of the sensor (310) (e.g., a micro controller unit (MCU)) can include an IC (integrated circuit) or an AFE (analog front end) The front-end may be configured to control the light emitting unit and the light receiving unit. The control unit may process data received from the light receiving unit and transmit the processing result to the processor (399) or store it in the memory (388). As a non-limiting example, raw data generated from a light sensor (e.g., a photoplethysmogram (PPG) sensor) may be utilized by another component (e.g., the processor (399)) to identify advanced glycation end products (AGEs).

[0065] In one embodiment, the biosensor (311) may include an acoustic sensor. The acoustic sensor can detect an object by emitting acoustic waves and receiving reflected waves. In addition to optical sensors or acoustic sensors, various sensors (e.g., image sensors) may be used as the biosensor (311).

[0066] According to one embodiment, the biosensor (311) may include a biomarker that detects a specific substance or component within the body. The biomarker may detect an indicator (e.g., blood sugar, alcohol, AGEs (advanced glycation end-products), antioxidants) that can indicate changes in substances within the body, such as cells, blood vessels, proteins, DNA, RNA (ribonucleic acid), and metabolites.

[0067] According to one embodiment, the biosensor (311) may include an electrode sensor (e.g., four electrodes or two electrodes). The electrode sensor is an interface for measuring electrical characteristics (e.g., voltage, current, impedance) through a living body, and may detect various physical characteristics (e.g., electrocardiogram (ECG), electromyogram (EMG), electroencephalogram (EEG)). The biosensor (311) may obtain body composition (e.g., body fat, body water) through body impedance analysis (BIA) measurement using four electrodes. The biosensor (311) may measure electrodermal activity (EDA) of the skin using two electrodes. EDA may include all measurements related to skin electrical responses, such as skin conductance, galvanic skin response (GSR), electrodermal response (EDR), and psychogalvanic reflex (PRG). According to one embodiment, when the number of electrodes arranged in the electronic device (300) increases, the types of measurable biosignals may increase. For example, in the case of a biosignal requiring four-point touch measurement (e.g., a bioimpedance signal), the electronic device (300) may measure the biosignal using four electrodes (e.g., two electrodes arranged on the back of the electronic device (300) (e.g., the second side (210B) of FIGS. 2A and 2B) and two electrodes arranged on the side of the electronic device (300) (e.g., the side (210C) of FIGS. 2A and 2B)). In one embodiment, even for a biosignal that can be measured using a three-point touch method (e.g., heart rate, blood pressure), additional electrodes may be utilized to compensate for errors or remove noise to improve the sensitivity or accuracy of biosignal measurement.In one embodiment, some of the four electrodes (e.g., three electrodes) may be utilized to measure biosignals (e.g., electrocardiogram, stress), or four electrodes may be utilized to measure biosignals, or to increase sensitivity and / or accuracy.

[0068] The motion sensor (312) may be configured to generate a motion signal (e.g., an acceleration signal, an angular velocity signal, a geomagnetic signal) as raw data used to obtain motion information of the electronic device (300). For example, the motion sensor (312) may include an inertial measurement unit (IMU) configured with an acceleration sensor, a gyroscope (in other words, an angular velocity sensor), and a magnetometer. In the motion sensor (312), the acceleration sensor may be configured to generate a first acceleration value corresponding to motion in the x-axis direction (see FIGS. 2A and 2B), a second acceleration value corresponding to motion in the y-axis direction, and a third acceleration value corresponding to motion in the z-axis direction. In the motion sensor (312), the gyroscope may be configured to generate a first angular velocity value corresponding to a rotational motion about the x-axis, a second angular velocity value corresponding to a rotational motion about the y-axis, and a third angular velocity value corresponding to a rotational motion about the z-axis. For example, a geomagnetic sensor (or a Hall sensor) may include a transmitter for generating a magnetic field of a specific frequency and a receiver for receiving the magnetic field generated by the transmitter, and may obtain form factor change information (e.g., movement direction or movement distance) of the electronic device (300). For example, the geomagnetic sensor may measure a direction using a magnetic field and magnetic force lines, and the Hall sensor may detect the strength of a magnetic field to obtain form factor change information of the electronic device (300). The sensor algorithm (323) can calculate Euler angles (e.g., roll, pitch, yaw) using raw data generated from the motion sensor (312) (e.g., data indicating acceleration values ​​of each axis and data indicating the direction in which the Earth's magnetic force is directed).

[0069] The sensor (310) may further include a barometer (atmospheric pressure sensor) (313) configured to measure atmospheric pressure as one of the raw data used to calculate a heart rate. According to one embodiment, the sensor (310) may further include a proximity sensor. The proximity sensor may detect the presence of an object close to the exterior of the electronic device (300) without physical contact. For example, the electronic device (300) may check the cradle status of the electronic device (300) or whether the electronic device (300) is being used through the proximity sensor.

[0070] The display (315), communication circuit (317), and processor (399) are implemented substantially identically to the display module (160), communication module (190), and processor (120) of FIG. 1, respectively, and thus can perform the same functions.

[0071] The sensor driver (321) can periodically obtain sensor values ​​from the sensor (310). The sensor driver (321) can provide the sensor values ​​(raw data) to the sensor algorithm (323). The sensor driver (321) can also provide the sensor values ​​to the sensor manager (340) through the kernel (330) in response to a request from the sensor manager (340).

[0072] According to one embodiment, the sensor driver (321) may include an acceleration driver (321a), a PPG driver (321b), and a pressure driver (321c). The acceleration driver (321a) may periodically acquire acceleration values ​​from raw data generated by the motion sensor (312) based on a sampling rate (or sampling frequency) specified for acceleration. Here, the sampling rate may be defined as the number of sensor values ​​(e.g., acceleration values) extracted per unit time (e.g., 1 second) from the raw data generated by the sensor (310). The unit may be Hertz (Hz). For example, the sampling rate specified for acceleration is 50 Hz, and accordingly, the acceleration driver (321a) may acquire acceleration values ​​from the motion sensor (312) every 20 ms (= 1 / 50 Hz). The sampling rate specified for PPG is 25 Hz, and accordingly, the PPG driver (321b) can obtain a PPG value from the biosensor (311) every 40 ms (= 1 / 25 Hz). The sampling rate specified for barometric pressure is 1 Hz, and the barometric pressure driver (321c) can obtain a barometric pressure value from the barometer (313) every second.

[0073] The sensor algorithm (323) can periodically receive sensor values ​​from the sensor driver (321). The sensor algorithm (323) can generate information related to the user's health using the sensor values ​​periodically received from the sensor driver (321). The sensor algorithm (323) can, in response to a request from the sensor manager (340), provide output values ​​(e.g., health-related information) to the sensor manager (340) through the kernel (330). According to one embodiment, the sensor algorithm (323) can provide input / output values ​​(e.g., sensor values, health-related information) to the virtual sensor (325).

[0074] According to one embodiment, the sensor algorithm (323) may include a sleep time determination module (361). The sleep time determination module (361) may determine (e.g., calculate) a sleep time including a time point of starting (going to sleep) and a time point of waking up, using acceleration values ​​periodically received from the acceleration driver (321a). According to one embodiment, the acceleration driver (321a) may receive acceleration values ​​from the acceleration sensor in the motion sensor (312) every first cycle (e.g., 20 ms (=1 / 50 Hz)). The sleep time determination module (361) may extract samples from acceleration values ​​output from the acceleration driver (321a) every second cycle (e.g., 100 ms (=1 / 10 Hz)) that is longer than the first cycle (e.g., 20 ms (=1 / 50 Hz)). For example, in relation to the acceleration value, if the sampling rate given to the acceleration driver (321a) is 50 Hz and the sampling rate given to the sleep time determination module (361) is 10 Hz, the sleep time determination module (361) can extract the (n*5)th acceleration value from among the acceleration values ​​acquired by the acceleration driver (321a) as a sample for determining the sleep time. Ideally, the (n*5)th acceleration value should be extracted as a sample, but due to noise generated in the electronic device (300) (e.g., sampling error due to system delay), an acceleration value other than the (n*5)th acceleration value (e.g., the (n*5-1)th or (n*5+1)th acceleration value may be extracted. The sleep time determination module (361) can determine the sleep time using the samples extracted every second cycle. The sleep time determination module (361) can provide input values ​​(e.g., acceleration samples) and output values ​​(e.g., information about the sleep time) to the virtual sensor (325). The sleep time determination module (361) may, in response to a request from the sensor manager (340), provide an output value (e.g., information related to sleep time) to the sensor manager (340) through the kernel (330).

[0075] According to one embodiment, the sensor algorithm (323) may include a sleep state determination module (362). While the electronic device (300) is set to a sleep mode to monitor the user's sleep, the sleep state determination module (362) may determine the sleep state using acceleration values ​​periodically received from the acceleration driver (321a). According to one embodiment, the acceleration driver (321a) may receive acceleration values ​​from the acceleration sensor in the motion sensor (312) every first cycle (e.g., 20 ms (=1 / 50 Hz)). The sleep state determination module (362) may extract samples from the acceleration values ​​output from the acceleration driver (321a) every second cycle (e.g., 100 ms (=1 / 10 Hz)) that is longer than the first cycle. The sleep state determination module (362) can determine the heart rate (HR) and RR intervals (RRI) every third cycle (e.g., 1 second) using the acceleration samples extracted every second cycle. The sleep state determination module (362) can determine the sleep state (e.g., the degree of waking up or tossing and turning, the proportion of REM sleep, light sleep, and deep sleep in the sleep time confirmed through the sleep time determination module (361)) using the HR and RRI determined every third cycle. The sleep state determination module (362) can provide input values ​​(e.g., acceleration samples, HR, RRI) and output values ​​(e.g., information about the sleep state) to the virtual sensor (325). The sleep state determination module (362) can also provide output values ​​(e.g., information about the sleep state) to the sensor manager (340) through the kernel (330) in response to a request from the sensor manager (340).

[0076] According to one embodiment, the sensor algorithm (323) may include an SpO2 acquisition module (363). The SpO2 acquisition module (363) may periodically acquire SpO2 using acceleration values ​​periodically received from the acceleration driver (321a) and PPG values ​​periodically received from the PPG driver (321b). According to one embodiment, the acceleration driver (321a) may receive acceleration values ​​from the acceleration sensor in the motion sensor (312) every first period (e.g., 20 ms (=1 / 50 Hz)). The SpO2 acquisition module (363) may extract samples from acceleration values ​​output from the acceleration driver (321a) every second period (e.g., 40 ms (=1 / 25 Hz)) that is longer than the first period. The PPG driver (321b) can receive PPG values ​​from the PPG sensor in the biosensor (311) every fourth cycle (e.g., 40 ms (= 1 / 25 Hz)). The SpO2 acquisition module (363) can receive PPG values ​​from the PPG driver (321b) every fourth cycle. The SpO2 acquisition module (363) can determine SpO2 every fifth cycle (e.g., 1 second) by using acceleration samples received every second cycle and PPG values ​​received every fourth cycle. The SpO2 acquisition module (363) can provide input values ​​(e.g., acceleration samples, PPG values) and output values ​​(e.g., information about SpO2) to the virtual sensor (325). The SpO2 acquisition module (363) may, in response to a request from the sensor manager (340), provide an output value (e.g., SpO2-related information) to the sensor manager (340) through the kernel (330).

[0077] According to one embodiment, the sensor algorithm (323) may include a VO2Max acquisition module (364). The VO2Max acquisition module (364) may periodically acquire VO2Max using acceleration values ​​periodically received from the acceleration driver (321a) and PPG values ​​periodically received from the PPG driver (321b). According to one embodiment, the acceleration driver (321a) may receive acceleration values ​​from the acceleration sensor in the motion sensor (312) every first period (e.g., 20 ms (= 1 / 50 Hz)). The VO2Max acquisition module (364) may extract samples from the acceleration values ​​output from the acceleration driver (321a) every second period (e.g., 40 ms (= 1 / 25 Hz)). The PPG driver (321b) can receive PPG values ​​from the PPG sensor in the biosensor (311) every fourth cycle (e.g., 40 ms (= 1 / 25 Hz)). The VO2Max acquisition module (364) can receive PPG values ​​from the PPG driver (321b) every fourth cycle. The VO2Max acquisition module (364) can determine VO2Max every sixth cycle (e.g., 1 second) using acceleration samples received every second cycle and PPG values ​​received every fourth cycle. The VO2Max acquisition module (364) can provide input values ​​(e.g., acceleration samples, PPG values) and output values ​​(e.g., information about VO2Max) to the virtual sensor (325). The VO2Max acquisition module (364) may, in response to a request from the sensor manager (340), provide an output value (e.g., VO2Max related information) to the sensor manager (340) via the kernel (330).

[0078] According to one embodiment, the sensor algorithm (323) may include a HR / RRI determination module (365). The HR / RRI determination module (365) may determine HR and RRI using acceleration values ​​periodically received from the acceleration driver (321a), PPG values ​​periodically received from the PPG driver (321b), and barometric pressure values ​​periodically received from the barometric pressure driver (321c) while the electronic device (300) is set to an operation mode (e.g., exercise mode) that allows the user's movement to be monitored. According to one embodiment, the acceleration driver (321a) may receive acceleration values ​​from the acceleration sensor in the motion sensor (312) every first cycle (e.g., 20 ms (= 1 / 50 Hz)). The HR / RRI determination module (365) may extract samples from the acceleration values ​​output from the acceleration driver (321a) every second cycle (e.g., 40 ms (= 1 / 25 Hz)). The PPG driver (321b) can receive PPG values ​​from the PPG sensor in the biosensor (311) every fourth cycle (e.g., 40 ms (= 1 / 25 Hz)). The HR / RRI determination module (365) can receive PPG values ​​from the PPG driver (321b) every fourth cycle. The barometric pressure driver (321c) can receive barometric pressure values ​​from the barometer (313) every seventh cycle (e.g., 1 second). The HR / RRI determination module (365) can receive barometric pressure values ​​from the barometric pressure driver (321c) every seventh cycle. The HR / RRI determination module (365) can determine HR and RRI every third cycle (e.g., 1 second) by using the acceleration samples received every second cycle, the PPG values ​​received every fourth cycle, and the barometric pressure values ​​received every seventh cycle. The HR / RRI determination module (365) can provide input values ​​(e.g., acceleration samples, PPG values, barometric pressure values) and output values ​​(e.g., HR, RRI) to the virtual sensor (325).The HR / RRI decision module (365) may, in response to a request from the sensor manager (340), provide output values ​​(e.g., HR, RRI) to the sensor manager (340) via the kernel (330).

[0079] According to one embodiment, the HR / RRI determination module (365) may determine HR and RRI using only data acquired from the biosensor (311) and barometer (313), without acceleration values.

[0080] In addition to the modules (361, 362, 363, 364, 365) described above, the sensor algorithm (323) may further include various modules for the operation of the electronic device (300). For example, the sensor algorithm (323) may further include a wearing detection module and a wrist state detection module. The wearing detection module may receive sensor values ​​(e.g., a sensor value of the proximity sensor and / or a sensor value of the biometric sensor (e.g., a PPG sensor)) from the sensor driver (321) and, based on the received sensor values, determine whether the electronic device (300) (e.g., a smart watch) is worn on the user's wrist. The wearing detection module may provide input / output values ​​(e.g., a sensor value, information indicating whether wearing is detected) to the virtual sensor (325). The wrist state detection module may obtain multiple samples by sampling acceleration values ​​periodically received from the acceleration driver (321a). The wrist state detection module can detect the wrist state using the acquired samples. The wrist state detection module can provide input / output values ​​(e.g., acceleration samples, wrist state) to the virtual sensor (325). The wrist state detection module can provide output values ​​(e.g., wrist state) to the sensor manager (340) through the kernel (330) in response to a request from the sensor manager (340). The electronic device (300) can turn the display (315) on or off based on the wrist state. For example, the electronic device (300) can turn the display (315) on based on whether the wrist state indicates an action of raising the user's wrist. The electronic device (300) can turn the display (315) off based on whether the wrist state indicates an action of lowering the wrist. As another example, the sensor algorithm (323) can further include an irregular heart rhythm notification (IHRN) module.

[0081] The virtual sensor (325) can communicate with the sensor driver (321) and the sensor algorithm (323) and control the operation of the sensor driver (321) and the sensor algorithm (323) based on the control of the virtual sensor controller (327). According to one embodiment, the virtual sensor controller (327) can grant the virtual sensor (325) access to data based on the operation mode of the electronic device (300). The virtual sensor (325) can check the access permission list (380) stored in the memory (388) for the data corresponding to the operation mode. The virtual sensor (325) can receive data to which it has access permission from the sensor driver (321) and / or the sensor algorithm (323).

[0082] Mode Access Allowed ListSleepSleep TimeSleep StatusAccelerationSpO2ExerciseAccelerationPPGBarometric PressureVO2MaxHR / RRICustomAccelerationPPGHR / RRIWrist Detect

[0083] Referring to Table 1 described above, when the electronic device (300) is set to operate in sleep mode, the virtual sensor (325) may be granted access to the sleep time determination module (361), the sleep state determination module (361), the acceleration driver (321a), and the SpO2 acquisition module (363) from the virtual sensor controller (327). Depending on the access permission, the virtual sensor (325) may receive input / output values ​​(e.g., acceleration samples, sleep time) from the sleep time determination module (361). The virtual sensor (325) may receive input / output values ​​(e.g., acceleration samples, HR, RRI, sleep state) from the sleep state determination module (362). The virtual sensor (325) may receive input / output values ​​(e.g., acceleration values) from the acceleration driver (321a). The virtual sensor (325) can receive input / output values ​​(e.g., acceleration samples, PPG values, SpO2) from the SpO2 acquisition module (363).

[0084] Referring to Table 1 described above, when the electronic device (300) is set to operate in exercise mode, the virtual sensor (325) may be granted access to the acceleration driver (321a), the PPG driver (321b), the barometric pressure driver (321c), the VO2Max acquisition module (364), and the HR / RRI determination module (365) from the virtual sensor controller (327). Depending on the access permission, the virtual sensor (325) may receive input / output values ​​(e.g., acceleration values) from the acceleration driver (321a). The virtual sensor (325) may receive input / output values ​​(e.g., PPG values) from the PPG driver (321b). The virtual sensor (325) may receive input / output values ​​(e.g., barometric pressure values) from the barometric pressure driver (321c). The virtual sensor (325) can receive input / output values ​​(e.g., acceleration samples, PPG values, VO2Max) from the VO2Max acquisition module (364). The virtual sensor (325) can receive input / output values ​​(e.g., acceleration samples, PPG values, barometric pressure values, HR, RRI) from the HR / RRI determination module (365).

[0085] Referring to Table 1 described above, when the electronic device (300) is set to operate in a user-specified mode, the virtual sensor (325) may be granted access to the acceleration driver (321a), the PPG driver (321b), the HR / RRI determination module (365), and the wrist state detection module from the virtual sensor controller (327). Depending on the access permission, the virtual sensor (325) may receive input / output values ​​(e.g., acceleration values) from the acceleration driver (321a). The virtual sensor (325) may receive input / output values ​​(e.g., PPG values) from the PPG driver (321b). The virtual sensor (325) may receive input / output values ​​(e.g., acceleration samples, PPG values, barometric pressure values, HR, RRI) from the HR / RRI determination module (365). The virtual sensor (325) can receive input / output values ​​(e.g., acceleration values ​​(or acceleration samples), wrist states) from the wrist state detection module in the sensor algorithm (323). The items granted access rights in the user-defined mode in Table 1 are only examples, and the user-defined mode is not limited to these items. According to one embodiment, a menu may be displayed on the display (315) to enable the user to set the user-defined mode. The menu may include items indicating the types of sensor values ​​that can be collected by the sensor (e.g., acceleration, PPG, gyro, air pressure) and items indicating the types of health information that can be generated by the sensor algorithm (323) using the collected sensor values ​​(e.g., sleep time, sleep state, VO2Max, SpO2, HR, RRI, IHRN, ECG). The virtual sensor (325) can receive access rights for items selected by the user in the menu from the virtual sensor controller (327).

[0086] The virtual sensor (325) (or virtual sensor controller (327)) can generate log data (370) using data received from the sensor driver (321) and / or the sensor algorithm (323) and store the log data (370) in the memory (388). According to one embodiment, the virtual sensor (325) (or virtual sensor controller (327)) can include input / output values ​​of the sensor algorithm (323) in the log data (370). According to one embodiment, the virtual sensor (325) (or virtual sensor controller (327)) can include values ​​(e.g., sensor values) of the sensor driver (321), which is the source of the values ​​input to the sensor algorithm (323), in the log data (370). The virtual sensor (325) can provide the log data (370) to the sensor manager (340) and / or the virtual sensor manager (360) through the kernel (330) based on the control of the virtual sensor controller (327).

[0087] Log data (370) can be used to verify the integrity of the sensor algorithm (323). According to one embodiment, the log data (370) can include sleep mode log data (371), exercise mode log data (373), and user-specified mode log data (375). At least one of sleep mode log data (371), exercise mode log data (373), and user-specified mode log data (375) can be used to verify the integrity of the sensor algorithm (323). According to one embodiment, the sensor manager (340) can include a virtual sensor SDK (350) as an interface for accessing the virtual sensor (325). The sensor manager (340) can access the virtual sensor (325) through the virtual sensor SDK (350) to obtain input values ​​and output values ​​(or input / output values) of the sensor algorithm (323) from the virtual center (325). The sensor manager (340) may provide the input and output values ​​of the sensor algorithm (323) to a module for integrity verification of the sensor algorithm (323) based on the occurrence of an event (e.g., user input received through the display (315)) requesting verification of the output value generated from the sensor algorithm (323). For example, the application (305) may include a verification module configured to perform substantially the same function as the sensor algorithm (323). The verification module may generate an output value using the input value. In the application (305), the verification module may determine that the sensor algorithm (323) is intact based on the fact that the generated output value is identical to the output value received from the sensor manager (340).

[0088] In one embodiment, instead of the virtual sensor SDK (350) being configured in the sensor manager (340), the middleware (304) may include a virtual sensor manager (360) that provides the same functionality as the virtual sensor SDK (350). The virtual sensor manager (360) may access the virtual sensor (325) to obtain input and output values ​​of the sensor algorithm (323). The virtual sensor manager (360) may provide the input and output values ​​to a verification module (e.g., a verification module configured to perform substantially the same functionality as the sensor algorithm (323).

[0089] According to one embodiment, a module for verifying the integrity of the sensor algorithm (323) may be provided in an external device (e.g., server (108) of FIG. 1). The sensor manager (340) (or virtual sensor manager (360)) may transmit input / output values ​​(e.g., log data (370)) of the sensor algorithm (323) to the external device via the communication circuit (317).

[0090] According to one embodiment, the virtual sensor (325) may perform data logging for each operating mode of the electronic device (300) and provide log data (370) stored in the memory (388) as a result of the logging to a higher layer (e.g., an application (305)).

[0091] According to one embodiment, the virtual sensor controller (327) can check the operation mode set in the electronic device (300). The virtual sensor controller (327) can check the data to be logged (or collected) according to the confirmed operation mode from the access permission list (380). The virtual sensor controller (327) can control the virtual sensor (325) to collect only the data confirmed in the access permission list (380). The virtual sensor (325) can collect data corresponding to the operation mode currently set in the electronic device (300) from the sensor driver (321) and / or the sensor algorithm (323) based on the control of the virtual sensor controller (327). Accordingly, drivers or modules unrelated to the current operation mode are not driven, thereby reducing power consumption and enabling efficient use of resources provided in the electronic device (300).

[0092] FIG. 4 is a flowchart for explaining operations performed in an electronic device (300) based on the electronic device (300) being set to a sleep mode according to one embodiment.

[0093] Referring to FIG. 4, while the electronic device (300) is set to sleep mode, in operation 410, the virtual sensor (325) may perform a data logging operation of receiving sleep mode log data (e.g., sleep mode log data (371) of FIG. 3) from the acceleration driver (321a), the sleep time determination module (361), the sleep state determination module (362), and the SpO2 acquisition module (363) and storing the sleep mode log data in the memory (388).

[0094] Sleep mode input value output value sleep time determination module (361) acceleration value (10 Hz) sleep time, wake-up time sleep state determination module (362) acceleration value (25 Hz) HR (1 Hz) RRI (1 Hz) sleep state SpO2 acquisition module (363) acceleration value (25 Hz) PPG (25 Hz) sleep state SpO2 (1 Hz) acceleration driver (321a) acceleration value (50 Hz)

[0095] Referring to Table 2 described above, an example of operation 410 is explained as follows.

[0096] The acceleration driver (321a) can receive acceleration values ​​from the acceleration sensor at a sampling rate of 50 Hz and output them to the sensor manager (340) and / or the sensor algorithm (323). The virtual sensor (325) can receive acceleration values ​​input to the acceleration driver (321a) at a sampling rate of 50 Hz and output from the acceleration driver (321a).

[0097] The number of acceleration samples per unit time required for SpO2 acquisition may be approximately 25. Accordingly, in order to efficiently use resources (e.g., long-term data logging) and reduce power consumption, the sensor algorithm (323) may down-sample the acceleration values ​​output from the acceleration driver (321a) at a sampling rate of 50 Hz to a sampling rate of 25 Hz and output them to the SpO2 acquisition module (363). The SpO2 acquisition module (363) may receive PPG values ​​(e.g., red, green, infrared radiation) from the PPG driver (321b) at a sampling rate of 25 Hz. The SpO2 acquisition module (363) may acquire information about the sleep state from the sleep state determination module (362) as an input value used to determine SpO2. The SpO2 acquisition module (363) can calculate SpO2 at a sampling rate of 25 Hz using acceleration values ​​and PPG values ​​received at a sampling rate of 25 Hz and information about the sleep state acquired from the sleep state determination module (362). The SpO2 acquisition module (363) can down-sample SpO2 values ​​calculated at a sampling rate of 25 Hz to, for example, a sampling rate of 1 Hz and output them. The virtual sensor (325) can receive acceleration values ​​input to the SpO2 acquisition module (363) at a sampling rate of 25 Hz and PPG values ​​input to the SpO2 acquisition module (363) at a sampling rate of 25 Hz from the SpO2 acquisition module (363). The virtual sensor (325) can receive SpO2 output from the SpO2 acquisition module (363) at a sampling rate of 1 Hz (or 25 Hz).

[0098] The number of acceleration samples per unit time required to determine a sleep state may be sufficient at about 25. Accordingly, in order to efficiently use resources and reduce power consumption, the sensor algorithm (323) may down-sample the acceleration values ​​output from the acceleration driver (321a) at a sampling rate of 50 Hz to a sampling rate of 25 Hz and output them to the sleep state determination module (362). The sleep state determination module (362) may obtain HR and RRI from the HR / RRI determination module (365) at a sampling rate of 1 Hz (or 25 Hz) as input values ​​used to determine a sleep state. The sleep state determination module (362) may determine a sleep state using the HR and RRI obtained from the HR / RRI determination module (365) at a sampling rate of 1 Hz (or 25 Hz) and the acceleration values ​​input at a sampling rate of 25 Hz. The virtual sensor (325) can receive an acceleration value input to the sleep state determination module (362) at a sampling rate of 25 Hz from the sleep state determination module (362). The virtual sensor (325) can receive HR and RRI acquired at a sampling rate of 1 Hz (or 25 Hz) as input values ​​used for determining the sleep state from the sleep state determination module (362). The virtual sensor (325) can receive information about the sleep state from the sleep state determination module (362).

[0099] The number of acceleration samples per unit time required to determine the sleep time may be approximately 10. Accordingly, in order to efficiently use resources and reduce power consumption, the sensor algorithm (323) may down-sample the acceleration values ​​output from the acceleration driver (321a) at a sampling rate of 50 Hz to a sampling rate of 10 Hz and output the down-sampled values ​​to the sleep time determination module (361). The sleep time determination module (361) may determine the sleep time using the acceleration values ​​input at a sampling rate of 10 Hz. The virtual sensor (325) may receive the acceleration values ​​input to the sleep time determination module (361) at a sampling rate of 10 Hz from the sleep time determination module (361). The virtual sensor (325) may receive information about the sleep time from the sleep time determination module (361).

[0100] The virtual sensor (325) can store sleep mode log data (371) (e.g., input values ​​and output values ​​in Table 2) received from the acceleration driver (321a), sleep time determination module (361), sleep state determination module (362), and SpO2 acquisition module (363) in the memory (388).

[0101] In operation 420, the virtual sensor (325) can provide sleep mode log data (371) to the user program (401) (e.g., the sensor manager (340) or the virtual sensor manager (360)). The user program (401) can receive data from modules (e.g., the acceleration driver (321a), the sleep time determination module (361), the sleep state determination module (362), and the SpO2 acquisition module (363)) that receive and output data at different cycles through a single integrated interface (e.g., the virtual sensor (325)). The virtual sensor (325) can provide data to the user program (401) through a buffer. The buffer can be a memory area for storing the sleep mode log data (371) allocated to the virtual sensor (325) in the memory (388). The virtual sensor (325) can determine the cycle (e.g., batching cycle) for providing data to the user program (401) based on the size of the buffer. The virtual sensor (325) can also determine the cycle for providing data based on the cycle of input values ​​and / or output values. For example, the virtual sensor (325) can receive acceleration values ​​from the SpO2 acquisition module (363) every 40 ms (1 / 25 Hz) and provide them to the user program (401) through the buffer. The virtual sensor (325) can receive acceleration values ​​from the acceleration driver (321a) every 20 ms (1 / 50 Hz) and provide them to the user program (401) through the buffer.

[0102] FIG. 5 is a flowchart illustrating operations performed in an electronic device (300) based on the electronic device (300) being set to an exercise mode according to one embodiment.

[0103] Referring to FIG. 5, while the electronic device (300) is set to exercise mode, at operation 510, the virtual sensor (325) may perform a data logging operation of receiving exercise mode log data (e.g., exercise mode log data (373) of FIG. 3) from the acceleration driver (321a), the PPG driver (321b), the barometric pressure driver (321c), the VO2Max acquisition module (364), and the HR / RRI determination module (365) and storing the data in the memory (388).

[0104] Exercise modeInput valueOutput valueHR / RRI determination module (365)Acceleration value (25Hz)PPG value (25Hz)Barometric value (1Hz)HR (1Hz)RRI (1Hz)VO2Max acquisition module (364)Acceleration value (25Hz)PPG value (25Hz)VO2Max (1Hz)Acceleration driver (321a)Acceleration value (50Hz)PPG driver (321b)PPG value (25Hz)Barometric driver (321c)Barometric value (1Hz)

[0105] Referring to Table 3 described above, an example of operation 510 is explained as follows.

[0106] The acceleration driver (321a) can receive acceleration values ​​from the acceleration sensor at a sampling rate of 50 Hz and output them to the sensor manager (340) and / or the sensor algorithm (323). The virtual sensor (325) can receive acceleration values ​​input to the acceleration driver (321a) at a sampling rate of 50 Hz and output from the acceleration driver (321a).

[0107] The PPG driver (321b) can receive PPG values ​​from the PPG sensor at a sampling rate of 25 Hz and output them to the sensor manager (340) and / or the sensor algorithm (323). The virtual sensor (325) can receive PPG values ​​input to the PPG driver (321b) at a sampling rate of 25 Hz and output from the PPG driver (321b).

[0108] The barometric driver (321c) can receive a barometric value from the barometer (313) at a sampling rate of 1 Hz and output it to the sensor manager (340) and / or the sensor algorithm (323). The virtual sensor (325) can receive a barometric value input to the barometric driver (321c) at a sampling rate of 1 Hz and output from the barometric driver (321c).

[0109] The number of acceleration samples per unit time required to acquire VO2Max may be sufficient at about 25. Accordingly, in order to efficiently use resources and reduce power consumption, the sensor algorithm (323) may down-sample the acceleration values ​​output from the acceleration driver (321a) at a sampling rate of 50Hz to a sampling rate of 25Hz and output the down-sampled values ​​to the VO2Max acquisition module (364). The VO2Max acquisition module (364) may receive the PPG values ​​from the PPG driver (321b) at a sampling rate of 25Hz. The VO2Max acquisition module (364) may calculate VO2Max at a sampling rate of 1Hz using the received acceleration values ​​and PPG values. The virtual sensor (325) can receive an acceleration value input to the VO2Max acquisition module (364) at a sampling rate of 25 Hz and a PPG value input to the VO2Max acquisition module (364) at a sampling rate of 25 Hz from the VO2Max acquisition module (364). The virtual sensor (325) can receive a VO2Max output from the VO2Max acquisition module (364) at a sampling rate of 1 Hz from the VO2Max acquisition module (364).

[0110] The number of acceleration samples per unit time required for HR / RRI determination may be approximately 25. Accordingly, in order to efficiently use resources and reduce power consumption, the sensor algorithm (323) may down-sample acceleration values ​​output from the acceleration driver (321a) at a sampling rate of 50 Hz to a sampling rate of 25 Hz and output the down-sampled values ​​to the HR / RRI determination module (365). The HR / RRI determination module (365) may receive PPG values ​​from the PPG driver (321b) at a sampling rate of 25 Hz. The HR / RRI determination module (365) may receive barometric pressure values ​​from the barometric pressure driver (321c) at a sampling rate of 1 Hz. The HR / RRI determination module (365) may calculate HR and RRI at a sampling rate of 1 Hz using the received acceleration values, PPG values, and barometric pressure values. The virtual sensor (325) can receive, from the HR / RRI determination module (365), an acceleration value input to the HR / RRI determination module (365) at a sampling rate of 25 Hz, a PPG value input to the HR / RRI determination module (365) at a sampling rate of 25 Hz, and a barometric pressure value input to the HR / RRI determination module (365) at a sampling rate of 1 Hz. The virtual sensor (325) can receive, from the HR / RRI determination module (365), the HR and RRI output from the HR / RRI determination module (365) at a sampling rate of 1 Hz.

[0111] The virtual sensor (325) can store exercise mode log data (371) (e.g., input values ​​and output values ​​in Table 3) received from the acceleration driver (321a), the PPG driver (321b), the barometric pressure driver (321c), the VO2Max acquisition module (364), and the HR / RRI determination module (365) in the memory (388).

[0112] In operation 520, the virtual sensor (325) may provide exercise mode log data (373) to a user program (501) (e.g., a sensor manager (340) or a virtual sensor manager (360)). The user program (501) may receive data from modules (e.g., an acceleration driver (321a), a PPG driver (321b), a barometric pressure driver (321c), a VO2Max acquisition module (364), and a HR / RRI determination module (365)) that receive and output data at different cycles through a single integrated interface (e.g., a virtual sensor (325)). The virtual sensor (325) may provide data to the user program (401) through a buffer. The buffer may be a memory area for storing exercise mode log data (373) allocated to the virtual sensor (325) in the memory (388). The virtual sensor (325) can determine the cycle (e.g., batching cycle) for providing data to the user program (401) based on the size of the buffer. The virtual sensor (325) can also determine the cycle for providing data based on the cycle of input values ​​and / or output values. For example, the virtual sensor (325) can receive acceleration values ​​from the HR / RRI determination module (365) every 40 ms (1 / 25 Hz) and provide them to the user program (401) through the buffer. The virtual sensor (325) can receive acceleration values ​​from the acceleration driver (321a) every 20 ms (1 / 50 Hz) and provide them to the user program (401) through the buffer.

[0113] FIG. 6 is a flowchart illustrating operations performed in an electronic device (300) based on the electronic device (300) being set to a user-defined mode according to one embodiment.

[0114] Referring to FIG. 6, while the electronic device (300) is set to a user-defined mode, in operation 610, the virtual sensor (325) may perform a logging operation on data of interest to the user. For example, as the targets of the logging operation are set to sleep state and SpO2, the virtual sensor (325) may perform a data logging operation of receiving user-defined mode log data (e.g., user-defined mode log data (375)) from the sleep state determination module (362) and the SpO2 acquisition module (363) and storing the user-defined mode log data in the memory (388).

[0115] User-defined modeInput valueOutput valueSleep state determination module (362)Acceleration value (25Hz)HR (1Hz)RRI (1Hz)Sleep stateSpO2 acquisition module (363)Acceleration value (25Hz)PPG (25Hz)Sleep stateSpO2 (1Hz)

[0116] An example of operation 610 is described below with reference to Table 4 described above.

[0117] The sensor algorithm (323) can down-sample the acceleration values ​​output from the acceleration driver (321a) at a sampling rate of 50 Hz to a sampling rate of 25 Hz and output the down-sampled values ​​to the sleep state determination module (362). The sleep state determination module (362) can calculate HR and RRI at a sampling rate of 1 Hz using the received acceleration values. The sleep state determination module (362) can determine the sleep state using the HR and RRI calculated at a sampling rate of 1 Hz. The virtual sensor (325) can receive acceleration values ​​input to the sleep state determination module (362) at a sampling rate of 25 Hz from the sleep state determination module (362). The virtual sensor (325) can receive HR and RRI calculated at a sampling rate of 1 Hz from the sleep state determination module (362) as input values ​​used for determining the sleep state. The virtual sensor (325) can receive information about the sleep state from the sleep state determination module (362).

[0118] The sensor algorithm (323) can down-sample acceleration values ​​output from the acceleration driver (321a) at a sampling rate of 50 Hz to a sampling rate of 25 Hz and output the down-sampled values ​​to the SpO2 acquisition module (363). The SpO2 acquisition module (363) can receive PPG values ​​(e.g., red, green, infrared radiation) from the PPG driver (321b) at a sampling rate of 25 Hz. The SpO2 acquisition module (363) can obtain information about the sleep state from the sleep state determination module (362) as an input value used to determine SpO2. The SpO2 acquisition module (363) can calculate SpO2 at a sampling rate of 25 Hz by using the acceleration values ​​and PPG values ​​received at a sampling rate of 25 Hz and the information about the sleep state obtained from the sleep state determination module (362). The SpO2 acquisition module (363) can output SpO2s calculated at a sampling rate of 25 Hz by down-sampling them to, for example, a sampling rate of 1 Hz. The virtual sensor (325) can receive, from the SpO2 acquisition module (363), an acceleration value input to the SpO2 acquisition module (363) at a sampling rate of 25 Hz and a PPG value input to the SpO2 acquisition module (363) at a sampling rate of 25 Hz. The virtual sensor (325) can receive, from the SpO2 acquisition module (363), SpO2 output from the SpO2 acquisition module (363) at a sampling rate of 1 Hz (or 25 Hz).

[0119] The virtual sensor (325) can store user-specified mode log data (375) (e.g., input values ​​and output values ​​in Table 4) received from the sleep state determination module (362) and the SpO2 acquisition module (363) in the memory (388).

[0120] In operation 620, the virtual sensor (325) can provide user-specified mode log data (375) to the user program (601) (e.g., the sensor manager (340) or the virtual sensor manager (360)). The user program (601) can receive data from modules (e.g., the sleep state determination module (362) and the SpO2 acquisition module (363)) that receive and output data at different cycles through a single integrated interface (e.g., the virtual sensor (325)). The virtual sensor (325) can provide data to the user program (401) through a buffer. The buffer can be a memory area for storing the user-specified mode log data (375) allocated to the virtual sensor (325) in the memory (388). The virtual sensor (325) can determine a cycle (e.g., a batching cycle) for providing data to the user program (401) based on the size of the buffer. The virtual sensor (325) may also determine the provision cycle based on the cycle of the input values ​​and / or output values.

[0121] In one embodiment, the electronic device (300) may be set to an automatic mode. For example, the virtual sensor controller (327) may recognize that the user is sleeping or exercising through the sensor algorithm (323). Upon recognizing that the user is sleeping, the virtual sensor controller (327) may control the virtual sensor (325) to perform data logging operations corresponding to the sleep mode (e.g., Table 2). Based on the user is exercising, the virtual sensor controller (327) may control the virtual sensor (325) to perform data logging operations corresponding to the exercise mode (e.g., Table 3).

[0122] FIG. 7a is a diagram for explaining a scenario in which the integrity of the sensor algorithm is not secured in the electronic device of FIG. 3, and FIG. 7b is a diagram for explaining a scenario in which the integrity of the sensor algorithm is secured by a virtual sensor according to one embodiment.

[0123] Referring to Fig. 7a, the acceleration driver (321a) can output acceleration values ​​at a sampling rate of 50 Hz. The sensor algorithm (323) can extract acceleration samples by down-sampling (720) the acceleration values ​​output from the acceleration driver (321a) at a sampling rate of 10 Hz. The sleep time determination module (361) can determine and output the sleep time (730) using the acceleration samples extracted at a sampling rate of 10 Hz.

[0124] The sensor manager (340) can obtain acceleration values ​​output from the acceleration driver (321a) at a sampling rate of 50 Hz using the acceleration SDK (341). The sensor manager (340) can provide the obtained acceleration values ​​to the verification module (710) (e.g., the application (305) of FIG. 3 or the server (108) of FIG. 1). The verification module (710) can extract acceleration samples by down-sampling (711) the acceleration values ​​received from the sensor manager (340) at a sampling rate of 10 Hz. In the verification module (710), the sleep time determination module (713) can determine and output the sleep time (740) using the acceleration samples extracted at the sampling rate of 10 Hz.

[0125] The downsampling (711) cycle in the verification module (710) may differ from the downsampling (720) cycle in the sensor algorithm (323) due to the influence of noise. Due to this influence, the acceleration samples extracted by the verification module (710) may differ from the acceleration samples extracted by the sensor algorithm (323). Accordingly, the sleep time (740) determined by the verification module (710) may differ from the sleep time (730) determined by the sensor algorithm (323). This may cause the sensor algorithm (323) to be mistaken as lacking integrity even though it is actually intact. In other words, health-related information provided by the electronic device (300) may be mistaken as being unreliable.

[0126] Referring to FIG. 7b, the acceleration driver (321a) can output acceleration values ​​at a sampling rate of 50 Hz. The sensor algorithm (323) can extract acceleration samples by down-sampling (720) the acceleration values ​​output from the acceleration driver (321a) at a sampling rate of 10 Hz. The sleep time determination module (361) can determine and output the sleep time (730) using the acceleration samples extracted at the sampling rate of 10 Hz.

[0127] The virtual sensor (325) can receive the sleep time (730) and acceleration samples (acceleration values) used to determine the same from the sensor algorithm (323). The virtual sensor (325) can provide the sleep time (730) to a verification module (750) (e.g., the application (305) of FIG. 3 or the server (108) of FIG. 1). The verification module (750) can determine and output the sleep time (760) using the acceleration samples received from the sensor algorithm (323) through the virtual sensor (325) without downsampling.

[0128] Since the acceleration samples used to determine the sleep time are identical, the probability that the sleep time (760) determined by the verification module (750) and the sleep time (730) determined by the sensor algorithm (323) are identical may be higher than in the scenario illustrated in FIG. 7a. This may ensure the integrity of the sensor algorithm (323).

[0129] FIG. 8 is a flowchart illustrating operations performed in an electronic device (300) according to one embodiment. FIGS. 9A and 9B illustrate examples of user interface (UI) screens displayed in the electronic device (300). Instructions (e.g., sensor driver (321), sensor algorithm (323), virtual sensor (325), and virtual sensor controller (327)) may be stored in a memory (388). When executed by a processor (399) (e.g., a low-power sensor processor), the instructions may cause the electronic device (300) to perform the operations of FIG. 8.

[0130] In operation 810, the electronic device (300) may activate the virtual sensor (325) to perform the above-described function given to the virtual sensor (325). For example, the electronic device (300) may display a menu on the display (315) that allows the user to select whether to activate a service or function using the sensor (310) in the electronic device (300). Based on whether activation of the service or function using the sensor (310) is selected from the menu, the electronic device (300) may activate the virtual sensor (325). Accordingly, the virtual sensor (325), when executed by the processor (399), may have access to data input to the sensor driver (321) and the sensor algorithm (323) and data output from the sensor driver (321) and the sensor algorithm (323). Additionally, the virtual sensor (325), when executed by the processor (399), can communicate with an application (305) or an external device (e.g., server (108) of FIG. 1) through a virtual sensor manager (360) or a virtual sensor SDK (350).

[0131] In operation 820, the electronic device (300) may set the operation mode of the electronic device (300) to sleep mode, exercise mode, user-defined mode, or automatic mode. For example, the electronic device (300) may display a menu (910; see FIG. 9A) for setting the operation mode of the electronic device (300) on the display (315). Based on which item (e.g., sleep mode (911), exercise mode (912), automatic mode (black box mode) (913), or user-defined mode (914)) is selected by the user in the menu, the electronic device (300) may set the operation mode of the electronic device (300). According to one embodiment, the menu (910) may be a UI screen provided by the data log application (351; see FIG. 3) when the data log application (351) is executed by the processor (399). When one of the items is selected, the electronic device (300) may display a UI screen (920; see FIG. 9b) indicating the currently set operation mode (e.g., sleep mode) on the display (315).

[0132] In operation 830, the electronic device (300) can check in the access permission list (380) what data is permitted to be accessed corresponding to the set operation mode.

[0133] In operation 840, the electronic device (300) may perform a logging operation on the data to which access is permitted. The logging operation may be the same as that illustrated in FIG. 4, FIG. 5, or FIG. 6. According to one embodiment, based on the activation of the virtual sensor (325), a tracking application (353; see FIG. 3) may be executed by the processor (399). The tracking application (353) may, through the sensor manager (340) or the virtual sensor manager (360), check the input / output values ​​of the sensor driver (321) and / or the sensor algorithm (323) corresponding to the currently set operation mode and provide the input / output values ​​to the data log application (351). When executed by the processor (399), the data log application (351) may cause the electronic device (300) to collect log data corresponding to the currently set operation mode and store the log data in the memory (388).

[0134] The data log application (351) can be used for sleep-related research, analysis, or clinical approval. For example, the data log application (351) can be used for the development and research of solutions utilizing synchronized biosignals while a user is sleeping. The data log application (351) can be used for integrity verification or performance improvement of sensor algorithms operating during sleep (e.g., sleep state time determination module (361), sleep state determination module (362)). The data log application (351) can be used for clinical approval of sensor algorithms operating during sleep.

[0135] The data log application (351) can be used for research, analysis, and clinical approval related to exercise. For example, the data log application (351) can be used for the development and research of solutions utilizing synchronized bio-signals while a user is exercising. The data log application (351) can be used for integrity verification or performance improvement of sensor algorithms operating during exercise (e.g., HR / RRI determination module (365), VO2Max acquisition module (364)). The data log application (351) can be used for clinical approval of sensor algorithms operating during exercise.

[0136] The data log application (351) can be used to check for malfunctions and improve performance while the electronic device (300) is operating in automatic mode.

[0137] When the electronic device (300) operates in a user-specified mode, drivers or modules not specified by the user are not driven, thereby reducing power consumption and enabling efficient use of resources (e.g., battery, memory (388)) provided in the electronic device (300).

[0138] FIG. 10 is a flowchart illustrating operations for data logging in an electronic device (300) according to one embodiment. Instructions (e.g., a sensor driver (321), a sensor algorithm (323), a virtual sensor (325), and a virtual sensor controller (327)) may be stored in a memory (388). When executed by a processor (399) (e.g., a low-power sensor processor), the instructions may cause the electronic device (300) to perform the operations of FIG. 10.

[0139] In operation 1010, the electronic device (300) may periodically obtain a sensor value from the sensor (310). In one embodiment, based on the electronic device (300) being set to a sleep mode to monitor sleep, the electronic device (300) may receive an acceleration value from the motion sensor (312) at a given cycle (e.g., 1 / first sampling rate (e.g., 50 Hz)). The electronic device (300) may receive a PPG value from the biosensor (311) at a given cycle (e.g., 1 / second sampling rate (e.g., 25 Hz)). In one embodiment, based on the electronic device (300) being set to a movement mode to monitor movement, the electronic device (300) may receive an acceleration value from the motion sensor (312) at a given cycle (e.g., 1 / first sampling rate (e.g., 50 Hz)). The electronic device (300) can receive PPG values ​​from the biosensor (311) at a given cycle (e.g., 1 / 2 sampling rate (e.g., 25 Hz)). The electronic device (300) can receive barometric pressure values ​​from the meter (313) at a given cycle (e.g., 1 / 3 sampling rate (e.g., 1 Hz)).

[0140] In operation 1020, the electronic device (300) may obtain a plurality of samples by extracting some of the sensor values ​​obtained from the sensor (310). According to one embodiment, the electronic device (300) may extract acceleration samples by down-sampling acceleration values ​​received from the motion sensor (312) at a given period (1 / first sampling rate) to a fourth sampling rate (e.g., 10 Hz; see Table 2). According to one embodiment, the electronic device (300) may extract acceleration samples by down-sampling acceleration values ​​received from the motion sensor (312) at a given period (e.g., 1 / first sampling rate) to a fifth sampling rate (e.g., 25 Hz; see Table 2-3).

[0141] In operation 1030, the electronic device (300) may generate first health-related information (e.g., sleep time, sleep state, SpO2, HR, RRI, VO2Max) using the acquired samples. According to one embodiment, the electronic device (300) may determine the sleep time using acceleration samples obtained by down-sampling at a fourth sampling rate (e.g., 10 Hz). According to one embodiment, the electronic device (300) may determine the sleep state using acceleration samples obtained by down-sampling at a fifth sampling rate (e.g., 25 Hz). According to one embodiment, the electronic device (300) may obtain SpO2 at a given cycle (e.g., a sixth sampling rate (e.g., 1 Hz; see Table 2)) using acceleration samples obtained by down-sampling at the fifth sampling rate (e.g., 25 Hz) and PPG values ​​obtained by the second sampling rate (e.g., 25 Hz). According to one embodiment, the electronic device (300) can obtain HR and RRI at a given cycle (e.g., 1 / 7th sampling rate (e.g., 1 Hz; see Table 3)) using acceleration samples obtained by down-sampling at a fifth sampling rate (e.g., 25 Hz), PPG values ​​obtained by a second sampling rate (e.g., 25 Hz), and barometric pressure values ​​obtained by a third sampling rate (e.g., 1 Hz). According to one embodiment, the electronic device (300) can obtain VO2Max at a given cycle (e.g., 1 / 8th sampling rate (e.g., about 1 Hz; see Table 3)) using acceleration samples obtained by down-sampling at a fifth sampling rate (e.g., 25 Hz) and PPG values ​​obtained by a second sampling rate (e.g., 25 Hz).

[0142] In operation 1040, the electronic device (300) may store log data (e.g., log data (370) of FIG. 3) including first information and samples used to generate the same in the memory (388).

[0143] Additionally, in operation 1050, the electronic device (300) may verify the integrity of the sensor algorithm (e.g., the sensor algorithm (323) of FIG. 3) used to generate the first information using samples included in the log data. According to one embodiment, a verification module (e.g., the application (305) of FIG. 3) in the electronic device (300) may check the samples in the log data (370) and use them to generate the second information. The verification module may compare the second information with the first information to determine whether the sensor algorithm is intact. According to one embodiment, the electronic device (300) may display a menu on the display (315) to initiate verification of the sensor algorithm. The electronic device (300) may confirm that an event requesting verification has occurred through the menu. Based on the occurrence of the verification request event, the electronic device (300) may perform operation 1050.

[0144] In one embodiment, operation 1050 is omitted and the electronic device (300) may transmit log data to an external device (e.g., server (108) of FIG. 1) based on the occurrence of a verification request event. The electronic device (300) may receive the external device's judgment result regarding the integrity of the sensor algorithm from the external device.

[0145] According to one embodiment, a wearable electronic device (e.g., wearable electronic device (200) of FIG. 2, electronic device (300) of FIG. 3) includes a sensor (e.g., sensor (310) of FIG. 3); a processor (e.g., processor (399) of FIG. 3); and a memory (e.g., memory (388) of FIG. 3) that stores instructions. The instructions, when executed by the processor, may cause the electronic device to periodically acquire sensor values ​​from the sensor and to extract some of the sensor values ​​acquired from the sensor, thereby acquiring a plurality of samples. The instructions, when executed by the processor, may cause the electronic device to generate first information related to health using the samples, and to store log data including the first information and the samples in the memory. The above command, when executed by the processor, may cause the electronic device to generate second information using the samples in the log data based on an occurrence of an event requesting verification of the first information, compare the second information with the first information, and determine whether the first information is intact based on a result of the comparison.

[0146] The above command, when executed by the processor, may cause the wearable electronic device to include sensor values ​​obtained from the sensor in the log data.

[0147] The sensor may include an acceleration sensor, and the instructions, when executed by the processor, may cause the wearable electronic device to receive acceleration values ​​from the acceleration sensor every first period (e.g., 20 ms (1 / 50 Hz)) based on a sleep mode being set to monitor a user's sleep, and to extract samples from among the acceleration values ​​received from the acceleration sensor every second period longer than the first period. The instructions, when executed by the processor, may cause the electronic device to generate the first information using the samples extracted every second period.

[0148] The above command, when executed by the processor, may cause the wearable electronic device to determine a sleep onset time and a wake-up time using acceleration samples extracted every second cycle (e.g., 100 ms (1 / 10 Hz)). The above command, when executed by the processor, may cause the electronic device to include in the log data the samples extracted every second cycle and information regarding the sleep onset time and the wake-up time.

[0149] The above command, when executed by the processor, may cause the wearable electronic device to determine a sleep state using samples extracted every second cycle (e.g., 40 ms (1 / 25 Hz)) and HRs and RRIs acquired every third cycle. The above command, when executed by the processor, may cause the electronic device to include the samples extracted every second cycle, the HRs (heart rates) and RRIs (RR intervals) acquired every third cycle, and information about the sleep state in the log data.

[0150] The sensor may further include a biometric sensor. The instructions, when executed by the processor, may cause the wearable electronic device to receive a biometric value from the biometric sensor every fourth period (e.g., 40 ms (1 / 25 Hz)), and determine SpO2 every fifth period (e.g., 1 second) using samples extracted every second period (e.g., 40 ms (1 / 25 Hz)) and biometric values ​​received every fourth period. The instructions, when executed by the processor, may cause the electronic device to include the samples extracted every second period, the biometric values ​​received every fourth period, and the SpO2s acquired every fifth period in the log data.

[0151] The above command, when executed by the processor, may cause the wearable electronic device to display a screen for mode setting on a display of the wearable electronic device and detect sleep based on a sleep mode being selected on the screen.

[0152] The sensor may include an acceleration sensor and a biometric sensor. The instructions, when executed by the processor, may cause the wearable electronic device to receive an acceleration value from the acceleration sensor every first period (e.g., 20 ms (1 / 50 Hz)) and receive a biometric value from the biometric sensor every fourth period (e.g., 40 ms (1 / 25 Hz) from a PPG sensor), and extract a sample from among the acceleration values ​​received from the acceleration sensor every second period longer than the first period, based on the wearable electronic device being set to an exercise mode for monitoring the user's exercise. The instructions, when executed by the processor, may cause the electronic device to generate the first information using the samples extracted every second period and the biometric values ​​received every fourth period.

[0153] The above instructions, when executed by the processor, may cause the wearable electronic device to obtain VO2Max (maximum oxygen uptake) every sixth period (e.g., 1 second) using the samples extracted every second period and the biometric values ​​received every fourth period. The instructions, when executed by the processor, may cause the electronic device to include the samples extracted every second period, the biometric values ​​received every fourth period, and the VO2Max extracted every sixth period in the log data.

[0154] The sensor may further include a barometric pressure sensor. The instructions, when executed by the processor, may cause the wearable electronic device to receive a barometric pressure value from the barometric pressure sensor every seventh period, and to obtain RRI (RR intervals) and HR (heart rate) every third period (e.g., 1 second) using the samples extracted every second period, the biometric values ​​received every fourth period, and the barometric pressure values ​​received every seventh period. The instructions, when executed by the processor, may cause the electronic device to include the samples extracted every second period, the biometric values ​​received every fourth period, the barometric pressure values ​​received every seventh period, the RRIs obtained every third period, and the HRs obtained every third period in the log data.

[0155] The above command, when executed by the processor, may cause the wearable electronic device to display a screen for mode setting on a display of the wearable electronic device and detect the exercise based on the exercise mode being selected on the screen.

[0156] According to one embodiment, a wearable electronic device (e.g., wearable electronic device (200) of FIG. 2, electronic device (300) of FIG. 3) includes a sensor (e.g., sensor (310) of FIG. 3); a communication circuit (e.g., communication circuit (317) of FIG. 3); a processor (e.g., processor (399) of FIG. 3); and a memory (e.g., memory (388) of FIG. 3) that stores instructions. The instructions, when executed by the processor, may cause the electronic device to periodically acquire sensor values ​​from the sensor and extract some of the sensor values ​​acquired from the sensor, thereby acquiring a plurality of samples. The instructions, when executed by the processor, may cause the electronic device to generate first information related to health using the samples, and to store log data including the first information and the samples in the memory. The above command, when executed by the processor, may cause the electronic device to transmit the log data to an external electronic device through the communication circuit based on the occurrence of an event requesting verification of the first information.

[0157] According to one embodiment, a method of operating a wearable electronic device (e.g., the wearable electronic device (200) of FIG. 2, the electronic device (300) of FIG. 3) is provided. The method may include: obtaining a plurality of samples by extracting some of sensor values ​​obtained from a sensor of the wearable electronic device; generating first information related to health using the samples; and storing log data including the first information and the samples in a memory of the wearable electronic device. The method may include generating second information using the samples in the log data based on the occurrence of an event requesting verification of the first information, comparing the second information with the first information, and determining whether the first information is intact based on a result of the comparison.

[0158] The method may further include an operation of including sensor values ​​obtained from the sensor in the log data.

[0159] The sensor may include an acceleration sensor, and the wearable electronic device may be set to a sleep mode to monitor a user's sleep, and the acquisition operation may include an operation of receiving an acceleration value from the acceleration sensor every first period (e.g., 20 ms (1 / 50 Hz)) and extracting a sample from among the acceleration values ​​received from the acceleration sensor every second period longer than the first period. The generation operation may include an operation of generating the first information using the samples extracted every second period.

[0160] The first information may include information about sleep onset time and wake-up time, and the log data may include samples extracted for each second period and the first information.

[0161] The above generation operation may include an operation of determining a sleep state using samples extracted for each second period and HR (heart rate) and RRI (RR intervals) acquired for each third period, the first information may include information about the sleep state, and the log data may include samples extracted for each second period, HR (heart rate) and RRI (RR intervals) acquired for each third period, and the first information.

[0162] The sensor may include a biosensor, and the generating operation may include an operation of determining SpO2 every fifth period using samples extracted every second period and biometric values ​​received from the biometric sensor every fourth period, and the first information may include SpO2s acquired every fifth period, and the log data may include samples extracted every second period, biometric values ​​received every fourth period, and the first information.

[0163] The above sensor may include an acceleration sensor and a biometric sensor, and the wearable electronic device may be set to an exercise mode to monitor the user's exercise, and the acquisition operation may include an operation of receiving an acceleration value from the acceleration sensor every first period, receiving a biometric value from the biometric sensor every fourth period, and extracting a sample from among the acceleration values ​​received from the acceleration sensor every second period longer than the first period. The generation operation may include an operation of generating the first information using the samples extracted every second period and the biometric values ​​received every fourth period.

[0164] The above generating operation may include an operation of obtaining VO2Max (maximum oxygen uptake) for each sixth period by using samples extracted for each second period and biometric values ​​received for each fourth period, and the first information may include VO2Max values ​​obtained for each sixth period, and the log data may include samples extracted for each second period, biometric values ​​received for each fourth period, and the first information.

[0165] The effects that can be obtained from the present disclosure are not limited to the effects mentioned above, and other effects that are not mentioned will be clearly understood by a person having ordinary skill in the art to which the present disclosure pertains.

[0166] In the above explanation, the prefixes “first,” “second,” and “third” are only used to distinguish between the same names and do not have any special meaning in themselves, such as importance or order.

[0167] Electronic devices according to the various embodiments disclosed in this document may take various forms. Electronic devices may include, for example, portable communication devices (e.g., smartphones), computer devices, portable multimedia devices, portable medical devices, cameras, wearable devices, or home appliances. Electronic devices according to the embodiments of this document are not limited to the aforementioned devices.

[0168] The various embodiments of this document and the terminology used therein are not intended to limit the technical features described in this document to specific embodiments, but should be understood to include various modifications, equivalents, or substitutes of the embodiments. In connection with the description of the drawings, similar reference numerals may be used for similar or related components. The singular form of a noun corresponding to an item may include one or more of the items, unless the context clearly indicates otherwise. In this document, each of the phrases "A or B", "at least one of A and B", "at least one of A or B", "A, B, or C", "at least one of A, B, and C", and "at least one of A, B, or C" can include any one of the items listed together in the corresponding phrase among those phrases, or all possible combinations thereof. Terms such as "first," "second," or "first" or "second" may be used merely to distinguish one component from another, and do not limit the components in any other respect (e.g., importance or order). When a component (e.g., a first component) is referred to as "coupled" or "connected" to another component (e.g., a second component), with or without the terms "functionally" or "communicatively," it means that the component can be connected to the other component directly (e.g., wired), wirelessly, or through a third component.

[0169] The term "module" used in various embodiments of this document may include a unit implemented in hardware, software, or firmware, and may be used interchangeably with terms such as logic, logic block, component, or circuit. A module may be an integral component, or a minimum unit or part of such a component that performs one or more functions. In one embodiment, a module may be implemented in the form of an application-specific integrated circuit (ASIC).

[0170] Various embodiments of the present document may be implemented as software (e.g., a program (140)) including one or more instructions stored in a storage medium (e.g., an internal memory (136) or an external memory (138)) readable by a machine (e.g., an electronic device (101)). For example, a processor (e.g., a processor (120)) of the machine (e.g., an electronic device (101)) may call at least one instruction among the one or more instructions stored from the storage medium and execute it. This enables the machine to operate to perform at least one function according to the at least one called instruction. The one or more instructions may include code generated by a compiler or code executable by an interpreter. The machine-readable storage medium may be provided in the form of a non-transitory storage medium. Here, 'non-transitory' simply means that the storage medium is a tangible device and does not contain signals (e.g., electromagnetic waves), and the term does not distinguish between cases where data is stored semi-permanently or temporarily on the storage medium.

[0171] According to one embodiment, the method according to various embodiments disclosed in this document may be provided as a computer program product. The computer program product may be traded between sellers and buyers as a product. The computer program product may be distributed in the form of a device-readable storage medium (e.g., compact disc read-only memory (CD-ROM)) or may be provided through an application store (e.g., Play Store). TM ) or directly between two user devices (e.g., smart phones), online distribution (e.g., downloading or uploading). In the case of online distribution, at least a portion of the computer program product may be at least temporarily stored or temporarily created in a machine-readable storage medium, such as the memory of a manufacturer's server, an application store's server, or an intermediary server.

[0172] According to various embodiments, each component (e.g., a module or a program) of the above-described components may include one or more entities, and some of the entities may be separated and placed in other components. According to various embodiments, one or more components or operations of the aforementioned components may be omitted, or one or more other components or operations may be added. Alternatively or additionally, a plurality of components (e.g., a module or a program) may be integrated into a single component. In such a case, the integrated component may perform one or more functions of each of the plurality of components identically or similarly to those performed by the corresponding component among the plurality of components prior to the integration. According to various embodiments, the operations performed by a module, program, or other component may be executed sequentially, in parallel, iteratively, or heuristically, or one or more of the operations may be executed in a different order, omitted, or one or more other operations may be added.

Claims

1. In wearable electronic devices, sensor; processor; and Contains memory that stores instructions, The above instructions, when executed by the processor, cause the wearable electronic device to: Periodically acquire sensor values ​​from the above sensor, Obtaining multiple samples by extracting some of the sensor values ​​obtained from the above sensor, Using the above samples, first health-related information is generated, Store the log data including the first information and the samples in the memory, Based on the occurrence of an event requesting verification of the first information, second information is generated using the samples in the log data, Compare the above second information with the above first information, A wearable electronic device that determines whether the first information is intact based on the result of the above comparison.

2. In the first paragraph, when the command is executed by the processor, the wearable electronic device, A wearable electronic device that includes sensor values ​​obtained from the above sensor in the above log data.

3. In the first paragraph, the sensor includes an acceleration sensor, and the command, when executed by the processor, sets the wearable electronic device to a sleep mode that monitors the user's sleep. Receive acceleration values ​​from the acceleration sensor every first cycle, Extracting samples from the acceleration values ​​received from the acceleration sensor every second period longer than the first period, A wearable electronic device that generates the first information using samples extracted every second period.

4. In the third paragraph, when the command is executed by the processor, the wearable electronic device, Using the samples extracted for each of the above second periods, the sleep onset time and wake-up time are determined, The wearable electronic device that includes samples extracted for each of the second periods and information about the sleep onset time and the wake-up time in the log data.

5. In the third paragraph, when the command is executed by the processor, the wearable electronic device, Using the samples extracted for each of the second cycles and the HR (heart rates) and RRIs (RR intervals) obtained for each of the third cycles, the sleep state is determined, A wearable electronic device that includes samples extracted every second cycle, HRs and RRIs acquired every third cycle, and information about the sleep state in the log data.

6. In the third paragraph, the sensor further includes a biometric sensor, and the command, when executed by the processor, causes the wearable electronic device to: Receive biometric values ​​from the biometric sensor every fourth cycle, Using the samples extracted every second cycle and the biometric values ​​received every fourth cycle, SpO2 is determined every fifth cycle, A wearable electronic device that includes in the log data the samples extracted every second cycle, the biometric values ​​received every fourth cycle, and the SpO2 values ​​acquired every fifth cycle.

7. In the third paragraph, when the command is executed by the processor, the wearable electronic device, Display a screen for mode setting on the display of the above wearable electronic device, A wearable electronic device that detects sleep based on the sleep mode selected on the above screen.

8. In the first paragraph, the sensor includes an acceleration sensor and a biometric sensor, and the command, when executed by the processor, is based on the wearable electronic device being set to an exercise mode that monitors the user's exercise. Receive acceleration values ​​from the acceleration sensor every first cycle and receive biometric values ​​from the biometric sensor every fourth cycle, Extracting samples from the acceleration values ​​received from the acceleration sensor every second period longer than the first period, A wearable electronic device that generates the first information using samples extracted every second period and biometric values ​​received every fourth period.

9. In the 8th paragraph, when the command is executed by the processor, the wearable electronic device, Using the samples extracted every second cycle and the biological values ​​received every fourth cycle, VO2Max (maximum oxygen uptake) is obtained every sixth cycle. A wearable electronic device that includes in the log data the samples extracted every second period, the biometric values ​​received every fourth period, and the VO2Max extracted every sixth period.

10. In the 8th paragraph, the sensor further includes a pressure sensor, and the command, when executed by the processor, causes the wearable electronic device to: Receive the pressure value every 7 cycles from the above pressure sensor, Using the samples extracted every second cycle, the biometric values ​​received every fourth cycle, and the barometric values ​​received every seventh cycle, RRI (RR intervals) and HR (heart rate) are obtained every third cycle, A wearable electronic device that includes in the log data samples extracted every second cycle, biometric values ​​received every fourth cycle, barometric values ​​received every seventh cycle, RRIs acquired every third cycle, and HRs acquired every third cycle.

11. In the 8th paragraph, when the instruction is executed by the processor, the wearable electronic device, Display a screen for mode setting on the display of the above wearable electronic device, A wearable electronic device that detects the exercise based on the exercise mode selected on the above screen.

12. In wearable electronic devices, sensor; communication circuit; processor; and Contains memory that stores instructions, The above instructions, when executed by the processor, cause the wearable electronic device to: Periodically acquire sensor values ​​from the above sensor, Obtaining multiple samples by extracting some of the sensor values ​​obtained from the above sensor, Using the above samples, first health-related information is generated, Store the log data including the first information and the samples in the memory, A wearable electronic device that transmits the log data to an external electronic device through the communication circuit based on the occurrence of an event requesting verification of the first information.

13. A method for operating a wearable electronic device, An operation of obtaining a plurality of samples by extracting some of the sensor values ​​obtained from the sensor of the wearable electronic device; An operation of generating first health-related information using the above samples; and An operation of storing log data including the first information and the samples in a memory of the wearable electronic device; and A method comprising: generating second information using the samples in the log data based on the occurrence of an event requesting verification of the first information, comparing the second information with the first information, and determining whether the first information is intact based on the result of the comparison.

14. In paragraph 13, A method further comprising an action of including sensor values ​​obtained from the sensor in the log data.

15. In the 13th paragraph, the sensor includes an acceleration sensor, and the wearable electronic device is set to a sleep mode to monitor the user's sleep, The above acquisition operation includes an operation of receiving an acceleration value from the acceleration sensor every first period, and extracting a sample from among the acceleration values ​​received from the acceleration sensor every second period longer than the first period. A method wherein the above generating operation includes an operation of generating the first information using samples extracted for each of the second periods.

Images