Heatstroke risk notification system, monitoring terminal, parent terminal program, and server device

Abstract

A heatstroke risk notification system that enables quick and effective responses tailored to the situation. [Solution] The heatstroke risk notification system comprises a monitored terminal that acquires location information and at least one of illuminance, ultraviolet intensity, external temperature, and internal temperature to determine the heatstroke risk and provide notification according to the risk level; a guardian terminal that receives and displays the risk level; and a server that relays the risk level between the monitored terminal and the guardian terminal. The monitored terminal includes a location acquisition unit, an environment acquisition unit, a determination unit, and a notification unit. The guardian terminal program receives and displays the risk level. The server device receives and transmits the risk level.

Description

Technical Field

[0001] The present invention relates to a heatstroke risk notification system, a monitored terminal, a protector terminal program, and a server device.

Background Art

[0002] Heatstroke in summer poses a serious health risk, especially for children who are active outdoors. To prevent heatstroke, it is important to grasp the risk level of the environment using heat indices such as WBGT (Wet-Bulb Globe Temperature) and take appropriate measures.

[0003] Conventionally, various devices and systems for heatstroke countermeasures have been proposed. For example, there are wearable devices that measure the body temperature of a wearer and the ambient temperature and humidity, determine the risk of heatstroke, and warn the wearer. In addition, a monitoring service that allows a protector to check the location information and activity status of a child via a smartphone application has also become widespread (Patent Document 1).

[0004] However, the conventional technologies have several problems. Even if an individual wearable device enables a child to recognize danger, it may be difficult for a protector to immediately grasp the situation and give appropriate instructions or take corresponding actions. In addition, it is necessary to consider the possibility that a child may not notice the warning of the device or may not be able to respond correctly.

[0005] Furthermore, the wide-area heat information provided by the Japan Meteorological Agency etc. does not always accurately reflect the situation of the local environment where a child is actually active (for example, the sunny side of a schoolyard, around playground equipment in a park, a poorly ventilated school route, etc.), and there is a limit to the accuracy of heatstroke risk assessment. Also, when a sensor tag device is placed in a bag etc., there is a problem that the temperature measurement becomes inaccurate due to the heat trapped inside.

[0006] Thus, there was a need for a comprehensive system that would enable children to accurately understand the heat risks around them, share that information appropriately with parents and other relevant parties, and respond quickly and effectively. [Prior art documents] [Patent Documents]

[0007] [Patent Document 1] Japanese Patent Publication No. 2020-161906 [Overview of the project] [Problems that the invention aims to solve]

[0008] The present invention aims to provide a heatstroke risk notification system, a monitored terminal, a guardian terminal program, and a server device that can notify a person being monitored of information regarding the risk of heatstroke in the environment in which the person being monitored is located. [Means for solving the problem]

[0009] To solve the above problems, a heatstroke risk notification system according to one aspect of the present invention comprises a monitored terminal that acquires location information, acquires at least one of illuminance, ultraviolet intensity, external temperature, and internal temperature to determine the heatstroke risk and provides notification according to the risk level; a guardian terminal that receives and displays the risk level; and a server that relays the risk level between the monitored terminal and the guardian terminal. [Effects of the Invention]

[0010] According to the present invention, it becomes possible to notify the person being monitored of information regarding the risk of heatstroke in the environment in which they are placed. [Brief explanation of the drawing]

[0011] [Figure 1] This is a system configuration diagram showing in detail the overall configuration of a heatstroke risk notification system according to one embodiment of the present invention. [Figure 2A]This is a perspective view specifically showing an example of the appearance of a monitored terminal according to one embodiment of the present invention. [Figure 2B] This is a block diagram specifically showing the hardware configuration of a monitored terminal according to one embodiment of the present invention. [Figure 2C] This is a functional block diagram showing the functional configuration of a monitored terminal according to one embodiment of the present invention, along with the data flow. [Figure 3] This flowchart shows the detailed flow of the risk level notification process performed by a monitored terminal according to one embodiment of the present invention. [Figure 4] This is an explanatory diagram illustrating the correspondence between risk levels and notification patterns in one embodiment of the present invention, along with specific examples. [Figure 5] This is a conceptual diagram illustrating the physical background of the ambient temperature correction process in one embodiment of the present invention. [Figure 6] This figure shows in detail an example of the main dashboard screen of a parent device in one embodiment of the present invention. [Figure 7] This is a sequence diagram showing the interaction between the monitored terminal, the server, and the guardian terminal in chronological order in the system of this embodiment. [Figure 8] This is a screen transition diagram showing an example of the main screen transitions of the application on the parent device in this embodiment. [Figure 9] In this embodiment, a data structure diagram is shown that illustrates an example of the structure of the data payload transmitted from the monitored terminal to the server. [Figure 10] This is a functional block diagram showing the functional configuration of a parental control terminal related to one embodiment of the present invention. [Figure 11] This is a functional block diagram showing the functional configuration of a server relating to one embodiment of the present invention. [Modes for carrying out the invention]

[0012] Hereinafter, embodiments of the present invention will be described in great detail with reference to the drawings. In this specification, in order to avoid omissions in the description and to describe each component and its operation from various angles, those skilled in the art can easily implement the present invention. Particularly, when considering the risk of heatstroke for children who are active outdoors, the amount of solar radiation from the sun (observable as illuminance or ultraviolet intensity), the ambient air temperature (observable as external temperature), and further the temperature rise in a closed space such as inside a bag (estimable by comparison with the internal temperature) are extremely important physical factors. The present invention attempts to evaluate a more realistic heatstroke risk by directly or indirectly capturing at least one of these factors.

[0013] (Definition of Terms) In this specification, "determining the heatstroke risk" refers to information processing that classifies or assigns, based on one or more pieces of acquired environmental information, into any of a plurality of predetermined discrete stage levels (for example, categories such as "safe", "caution", "dangerous", or stages from "level 1" to "level 4") that indicate the degree of risk to human health. This can be distinguished from a mode of simply calculating, displaying, or transmitting continuous values of physical quantities.

[0014] (Interpretation of "Performing Notification According to the Risk Degree") In this specification, for the monitored terminal to "perform notification according to the risk degree" means that at least one of the presence or absence of notification, the mode of notification (type, intensity, frequency, content, etc.) is controlled based on at least one stage level of the determined heatstroke risk degree or its change. For example, both a mode of starting notification only when the risk degree exceeds a predetermined threshold level (e.g., the "caution" level) and a mode of gradually changing, for each stage level of the risk degree (e.g., "safe", "caution", "warning", "dangerous"), the color of the light for notification, the blinking pattern, the presence or pattern of vibration, the type and volume of sound, the content of the message displayed on the display 104, the type of warning icon, etc. (see FIG. 4) can be included in this. What is important is that there is an objectively recognizable correspondence relationship between the determined risk degree and the notification.

[0015] (Supplementary Explanation Regarding "Determining Heat Stroke Risk Level")[[]END] In this specification, when a monitored terminal "determines the heat stroke risk level", it is not limited to the mode where the monitored terminal independently completes the process of finally classifying or assigning to any of a plurality of discrete stage levels indicating the degree of heat stroke risk based on the acquired information. For example, the process of the monitored terminal calculating a heat index value (e.g., WBGT value) from the acquired environmental information, determining which range of a plurality of pre-stored threshold values the heat index value belongs to, and generating a determination result (i.e., an internal identifier or flag indicating which risk level stage it corresponds to) is also included in the process of "determining the heat stroke risk level". In this case, the monitored terminal itself can perform notification based on the internal identifier or flag. Also, a distributed processing system can be considered where the heat index value calculated by the monitored terminal and the internal determination result as described above are transmitted to the server, and the server determines the final stage level name (e.g., "Level 4: Dangerous") based on this information and notifies the monitored terminal and the guardian terminal. Even in such a case, the monitored terminal has executed the essential information processing (calculation of the index value and determination of the threshold value range) for deriving the stage level of the heat stroke risk level and plays an indispensable role in determining the risk level for the entire system, so it can be interpreted as substantially "determining the heat stroke risk level". What is important is that the monitored terminal is not merely relaying raw sensor data but is executing information processing directly related to the stage evaluation of the heat stroke risk.

[0016] In this specification, the term "acquiring location information" for a monitored terminal is not limited to the monitored terminal itself performing positioning calculations using GNSS or the like to calculate absolute coordinates such as latitude and longitude. For example, a configuration in which the monitored terminal collects wireless environment information in its surroundings (e.g., SSID / BSSID of a Wi-Fi access point, ID of a BLE beacon, cell ID of a mobile phone base station), transmits that wireless environment information to a server or other terminal, and receives location information calculated by the server or other terminal based on that wireless environment information (so-called cloud positioning) is also included in "acquiring location information." This cloud positioning allows for highly accurate positioning results with fewer terminal resources than before, solving the technical challenge of battery life for the computer (monitored terminal) and improving its functionality. In short, it means that information indicating the location of the monitored terminal, calculated by some part of the system, becomes available for use by the monitored terminal for subsequent processing (e.g., determining the risk of heatstroke).

[0017] In this specification, the term "acquiring location information" for a monitored terminal is not limited to the monitored terminal itself performing positioning calculations using GNSS or the like to calculate absolute coordinates such as latitude and longitude. For example, a configuration in which the monitored terminal collects wireless environment information in its surroundings (e.g., SSID / BSSID of a Wi-Fi access point, ID of a BLE beacon, cell ID of a mobile phone base station), transmits that wireless environment information to a server or other terminal, and receives location information calculated by the server or other terminal based on that wireless environment information (so-called cloud positioning) is also included in "acquiring location information." This cloud positioning allows for highly accurate positioning results with fewer terminal resources than before, solving the technical challenge of battery life for the computer (monitored terminal) and improving its functionality. In short, it means that information indicating the location of the monitored terminal, calculated by some part of the system, becomes available for use by the monitored terminal for subsequent processing (e.g., determining the risk of heatstroke).

[0018] 1. Overall system configuration and operation (Figures 1 and 7) Figure 1 is a system configuration diagram showing in detail the overall configuration of a heatstroke risk notification system 1 according to one embodiment of the present invention. The heatstroke risk notification system 1 mainly consists of a monitored terminal 10 carried by a user (person being monitored), such as a child, a guardian terminal 20 held by a guardian or other related party, and a server 30 that relays information between these terminals. The monitored terminal 10, the guardian terminal 20, and the server 30 can each be connected to a network NW via appropriate communication means (for example, a mobile phone network, the internet, or short-range wireless communication such as BLE (Bluetooth® Low Energy)).

[0019] The monitored terminal 10 is designed for outdoor activities and connects to the network NW (Internet) via a cellular network (LTE-M / NB-IoT network in this diagram) to communicate with the server 30. In short-range situations, it can also connect directly to the guardian terminal 20 via short-range wireless communication (BLE in this diagram).

[0020] Server 30 is a cloud server built on a network NW and includes web server functionality, application server functionality, and a database (DB) 35. Server 30 receives data transmitted from the monitored terminal 10, stores it in the database 35, and transmits data in response to requests from the guardian terminal 20. Server 30 can also send push notifications to the guardian terminal 20 in emergencies.

[0021] The parent device 20 connects to the network NW via Wi-Fi or a cellular network (4G / 5G) and communicates with the server 30 using the HTTPS protocol. A dedicated application program runs on the parent device 20 and displays the information received from the server 30.

[0022] (Supplementary information regarding the system provider) The heatstroke risk notification system 1 described herein is not limited to a configuration in which a single business operator provides and operates all of its components (the monitored terminal 10, the program running on the guardian terminal 20, and the server 30). For example, an entire ecosystem in which one business operator (platform provider) provides the monitored terminal 10, the server 30, and its API (Application Programming Interface), and another business operator or individual developer (third party) develops and distributes an application that runs on the guardian terminal 20 using that API, can also be covered by the present invention. Furthermore, if the guardian terminal 20 is a general-purpose computer device and the guardian themselves installs and uses a third-party application, the functionality of the present invention is realized only when multiple entities are involved in the overall system. Thus, even if the components of the system are provided, managed, or used by multiple different entities, as long as they cooperate and function as a whole to solve the problems of the present invention, they should be interpreted as falling under the system of the present invention.

[0023] Next, using the sequence diagram in Figure 7, we will explain in chronological order how these three components work together. (S701) The monitored terminal 10 starts its own processing at regular intervals (for example, every minute) based on its built-in timer. First, it acquires environmental information from various sensors and location information from the GPS module. (S702) Next, the monitored terminal 10 performs an internal "heatstroke risk determination process" based on the acquired information. Details of this process will be described later (see Figure 3). (S703) If the determination results in a predetermined risk level (for example, "caution" or higher), or if a certain amount of time has elapsed since the last transmission, the monitored terminal 10 generates a payload containing risk information and sensor data and transmits it to the server 30. (S704) Upon receiving the data, server 30 first saves the data to database 35. This allows for the accumulation of past history. (S705) Next, the server 30 evaluates the received risk level. If the server determines that the risk level is particularly high (for example, "Danger" level), the server 30 sends a push notification to the parent terminal 20. This is to inform the parent of the urgency even if the application is inactive. (S706) The parent terminal 20 receives push notifications and displays alerts in the OS notification center, etc. (S707) When a parent launches the application, or when the application periodically updates data, the parent terminal 20 sends a "request to retrieve the latest data" to the server 30. (S708) Upon receiving the request, server 30 reads the latest information on the relevant monitored terminal from database 35 and sends it to parent terminal 20 as a response. (S709) The parent terminal 20 updates the screen display based on the received data. In this way, seamless information sharing is achieved through the collaboration of each component.

[0024] 2. Details of the monitored terminal 10 (Figures 2, 3, 4, 5, and 9) 2.1. Hardware Configuration (Figures 2A and 2B) Figure 2A is a perspective view showing the external appearance of the monitoring terminal 10 in more detail. The housing 100 is made of impact-resistant ABS resin or the like so that it can withstand the active movements of a child, and may also be further covered with an elastic silicone cover. The size is, for example, about 5 cm in height, 4 cm in width, and 1.5 cm in thickness, making it easy to attach to a child's school bag or clothing. As an attachment mechanism, a strap hole 103 or a loop for attaching a carabiner is provided at the top. The surface of the housing 100 is provided with slits 101 to efficiently guide ambient light to the internal light sensors (illuminance sensor 142, ultraviolet sensor 141). The front also features a translucent light diffusion guide 102 to diffuse the light from the internal light-emitting element 151, making it easily visible from any angle, a display 104 for showing the current danger level, and buttons 105 for receiving user input.

[0025] Figure 2B is a block diagram that specifically shows the internal hardware configuration of the monitored terminal 10. The centrally located MCU110 is the central processing unit of this terminal, and for example, a System on Chip (SoC) is used. This MCU may incorporate a low-power processor, a BLE 5.x compatible wireless transceiver, and a wide range of peripherals. The memory unit 120 consists of flash memory (for program storage) and RAM (for data processing) built into the MCU 110. The communication unit 130 consists of a wireless function built into the MCU 110 and a separately mounted LTE-M / NB-IoT communication module. The sensor group 140 is a core element of this terminal and consists of multiple sensors. These include an ultraviolet sensor 141 and an illuminance sensor 142, an external temperature sensor 143 (an NTC thermistor located near the outer surface of the housing), an internal temperature sensor 144 (a temperature sensor built into the MCU or mounted on the circuit board), and an acceleration sensor 145. The notification unit 150 consists of a light-emitting element 151 (e.g., an RGB LED) capable of full-color display and a coin-shaped vibration motor 152 that provides tactile feedback. The display 104 is, for example, a small organic EL display or liquid crystal display, and displays characters and icons based on instructions from the MCU 110. Button 105 is a physical push button, and its press signal is input to MCU 110. The distance calculation unit 160 is, for example, a distance measuring module using UWB (Ultra-Wideband) wireless technology, and measures the distance between itself and the parent terminal 20, which also supports UWB. The power supply unit 170 includes a rechargeable secondary battery (e.g., a lithium polymer battery) and a charging control circuit, and supplies operating power to each part of the monitored terminal 10. The location information acquisition unit 180 is composed of a low-power GNSS module and is compatible with satellite positioning systems such as GPS, GLONASS, and Galileo. These memory unit 120, communication unit 130, sensor group 140, notification unit 150, display 104, button 105, distance calculation unit 160, power supply unit 170, and location information acquisition unit 180 are connected to the MCU 110 via a bus.

[0026] 2.2. Functional Configuration and Conceptual Hierarchy (Figure 2C) Figure 2C is a block diagram that shows in detail the functional configuration of the monitored terminal 10, along with the data flow. These functions are mainly realized by the MCU 110 reading and executing programs from the memory unit 120.

[0027] (a) Position acquisition unit 205 Specific implementation example: The MCU110 is implemented as a software module that controls the position information acquisition unit 180 (GNSS module) and analyzes the received satellite signals. Alternatively, as a variation, it may be implemented as a cloud positioning client function that collects information from surrounding base stations using a Wi-Fi module or cellular communication module, transmits it to a server, and receives position information feedback. Core function: Obtain geographic coordinate information (latitude and longitude) indicating the current location of the monitored terminal 10. This is the basis for local risk assessment, as the risk of heatstroke varies greatly depending on the location. Specific processing steps: (1) The GNSS module is powered on periodically or in response to a specific trigger (e.g., motion detection by an accelerometer). (2) Signals from satellites are received, and positioning calculations are performed to obtain latitude, longitude, altitude, and time information. (3) The obtained position information is stored in internal memory and provided to the determination unit 230 and the communication processing unit 255. In the case of cloud positioning, (1) surrounding wireless environment information is scanned, (2) this information is sent to the server via the communication processing unit 255, and (3) the position information returned from the server is received and stored. Coordination with other elements: The hardware controls the location information acquisition unit 180. The acquired location information is used by the determination unit 230 to determine the degree of risk and by the communication processing unit 255 to transmit data to the server.

[0028] (b) Environmental Acquisition Department 210 Specific implementation example: The MCU110 is implemented as a software module that controls the sensor group 140 (UV sensor 141, illuminance sensor 142, external temperature sensor 143, internal temperature sensor 144, acceleration sensor 145, etc.) and reads the analog or digital output from each sensor. Core function: To acquire physical quantities related to the surrounding environment of the monitored terminal 10 (including at least one of "illuminance, ultraviolet intensity, external temperature, and internal temperature" as claimed) as digital data. This serves as basic data for objectively evaluating the risk of heatstroke. Higher concept: A function that digitizes the physical environment surrounding the user. Intermediate concepts: (1) Acquisition of the light environment (illuminance, ultraviolet rays), (2) Acquisition of the thermal environment (temperature), (3) Acquisition of the motion state (acceleration), (4) Acquisition of the atmospheric environment (humidity, atmospheric pressure, etc., optional). Sub-concept (this embodiment): The ultraviolet sensor 141 reads UVI (ultraviolet index), the illuminance sensor 142 reads illuminance (lux), the external temperature sensor 143 reads external temperature Tout (°C), the internal temperature sensor 144 reads internal temperature Tin (°C), and the acceleration sensor 145 reads triaxial acceleration (m / s²), each at a predetermined sampling period. Specific processing steps: (1) Send an initialization command to each sensor. (2) Periodically read the measured values ​​from each sensor. (3) If necessary, perform calibration processing and unit conversion processing on the read values. (4) Store the processed environmental data in internal memory and provide it to the correction unit 220 and the determination unit 230. Coordination with other elements: The sensor group 140 is controlled as hardware. The acquired environmental data is used for data correction by the correction unit 220, risk level determination by the judgment unit 230, and data transmission to the server by the communication processing unit 255.

[0029] (Generalization and diversity of acquired environmental information) In this specification, "environmental information" acquired by the monitored terminal 10 broadly refers to information relating to the physical conditions surrounding the monitored terminal or the condition of the user wearing or carrying the monitored terminal, which can contribute to the assessment of the risk of heatstroke. The "illuminance," "ultraviolet intensity," "external temperature," and "internal temperature" exemplified in the claims are particularly effective sources of information for capturing the effects of solar radiation and temperature in outdoor environments, but the present invention is not limited to these. For example, the environmental information acquisition unit 210 may acquire humidity using a humidity sensor or atmospheric pressure using a barometric pressure sensor, in addition to or instead of some of these. It is also conceivable to acquire information indicating the user's activity level and exercise intensity using an acceleration sensor 145, or to acquire biometric information such as the user's heart rate and body surface temperature by separately providing a heart rate sensor (not shown). These additional or alternative pieces of information can also be used alone or in combination with other information in the heatstroke risk determination logic (determination unit 230). The important point is to acquire data related to heatstroke risk from some objective source and evaluate the risk level based on that data.

[0030] (The essence of environmental information acquisition and the flexibility of sensor selection) As described above, "environmental information" in the present invention can include a variety of information sources. The reason why the claim specifies "at least one of illuminance, ultraviolet intensity, external temperature, and internal temperature" is because these are representative environmental parameters that have high relevance and practicality in heatstroke risk assessment. However, the core of the technical concept of this invention lies in the fact that the monitored terminal uses a portable sensor to acquire some objective physical or physiological parameter related to the onset of heatstroke, and then evaluates and notifies the risk based on that parameter. Therefore, configurations that determine the risk of heatstroke using sensors that measure parameters other than the four elements mentioned above, such as humidity, atmospheric pressure, activity level, or physiological indicators such as skin temperature and sweating, either alone or in combination with any of these four elements, or using only alternative parameters without using any of these four elements, can also be included within the scope of the technical idea of ​​the present invention, insofar as they achieve the problem that the present invention aims to solve (i.e., objective heatstroke risk assessment and notification based on data). For example, the environmental acquisition unit 210 may be equipped only with a high-precision humidity sensor and an acceleration sensor, and based on the information obtained from these, it may calculate the discomfort index and exercise intensity, and combine them to determine the risk of heatstroke. In this case as well, the system as a whole functions within the framework of the present invention, which evaluates and notifies of the risk of heatstroke. The use of such alternative or additional sensors may be selected as appropriate in response to future advancements in sensor technology and optimization for specific use cases (e.g., indoor sports, specific climatic conditions, etc.).

[0031] (c) Correction unit 220 Specific implementation example: A software module that runs on the MCU110 and performs numerical calculations and algorithm execution. Core function: The environmental acquisition unit 210 corrects for measurement error factors (e.g., trapped heat) in the raw sensor data (especially temperature information) acquired by the unit, and calculates a more accurate environmental evaluation value. It also integrates multiple environmental data to calculate an overall heat stress index (e.g., WBGT). Higher-level concept: A function that extracts and generates higher-level information from raw sensor data. Intermediate concepts: (1) Thermal environment correction (reduction of the effects of trapped heat), (2) Integrated calculation of heat stress indicators (WBGT calculation, etc.). Lower-level concept (thermal environment correction, see Figure 5): The larger the difference between the external temperature T_{out} and the internal temperature T_{in}, the greater the effect of trapped heat, and the equation $T_{ext} = T_{out} - \alpha \cdot (T_{in} - T_{out})$ (where \alpha is a correction coefficient) is used to calculate an estimated external temperature $T_{ext}$ that is closer to reality. Sub-concept (integrated calculation of heat stress index): Based on the estimated outside temperature Text, illuminance acquired by the environmental acquisition unit 210, and separately acquired humidity information (e.g., provided by the server 30 or acquired from the built-in humidity sensor), a modified WBGT value is calculated in accordance with, for example, the Japan Society of Biometeorology's "Guidelines for Preventing Heatstroke in Daily Life". Specific processing steps: (1) Receive external temperature $T_{out} and internal temperature T_{in} from the environment acquisition unit 210. (2) Calculate estimated external temperature T_{ext} using the correction formula above. (3) Receive illuminance data and, if necessary, humidity data from the environment acquisition unit 210. (4) Calculate the WBGT value based on the WBGT calculation formula using this data. (5) Provide the calculated corrected external temperature T_{ext}$ and WBGT value to the determination unit 230. Coordination with other elements: The environment acquisition unit 210 receives data and passes the processing result to the determination unit 230.

[0032] (d) Determination unit 230 Specific implementation example: A software module that runs on the MCU110 and performs comparison judgments and logical operations. Core function: Based on the location information acquired by the location acquisition unit 205 and various environmental information (or heat stress index) output by the correction unit 220 (or environment acquisition unit 210), the risk of heatstroke is determined to be one of several predetermined levels. Higher-level concept: A function that judges a situation based on acquired and generated information and derives conclusions that trigger actions. Intermediate concepts: (1) Threshold determination based on a single indicator, (2) Weighted comprehensive determination based on multiple indicators, (3) Predictive determination using machine learning models (see Appendix G), (4) Situational adaptive determination based on location information. Sub-concept (in this embodiment, threshold determination): The corrected WBGT value calculated by the correction unit 220 is compared with several threshold values ​​for WBGT pre-stored in the memory unit 120 (e.g., less than 25°C is "safe", 25°C or more and less than 28°C is "caution", 28°C or more and less than 31°C is "warning", and 31°C or more is "dangerous"). Similarly, the ultraviolet index (UVI) acquired by the environment acquisition unit 210 is compared with several threshold values ​​for UVI stored in the memory unit 120 (e.g., 2 or less is "weak", 3 to 5 is "moderate", 6 to 7 is "strong", 8 to 10 is "very strong", and 11 or more is "extremely strong"). These comparison results are comprehensively evaluated according to predetermined logic (e.g., prioritizing WBGT and raising the risk level by one level if UVI is "very strong" or higher), and the final heatstroke risk level is determined in four stages: "Level 1: Safe," "Level 2: Caution," "Level 3: Warning," and "Level 4: Dangerous." Specific processing steps: (1) Receive corrected WBGT value from correction unit 220, UVI value from environment acquisition unit 210, and location information from location acquisition unit 205. (2) (As a modified example) Determine whether it is outdoors or indoors based on the location information and adjust the parameters of the determination logic. (3) Compare the WBGT value and UVI value with their respective thresholds. (4) Input the comparison results into the comprehensive evaluation logic to determine the final risk level. (5) Provide the determined risk level to the notification control unit 240 and the communication processing unit 255. Coordination with other elements: Information is received from the position acquisition unit 205, the environment acquisition unit 210, and the correction unit 220, and the determined risk level is passed to the notification control unit 240 and the communication processing unit 255.

[0033] (Clarifying the role of location information in determining risk level) When the determination unit 230 determines the heatstroke risk level, "based on location information" means that the acquired location information is used as a parameter that directly or indirectly influences the logical determination process for deriving the heatstroke risk level. This includes, but is not limited to, the following embodiments: (1) A method of changing the weighting coefficients in the evaluation of other environmental information (illuminance, temperature, etc.) or changing the thresholds applied, depending on the environmental context estimated from location information (e.g., outdoors / indoors, sunny / shaded, inside / around a specific facility). For example, increasing the contribution of solar radiation-related parameters when it is determined to be outdoors. (2) An embodiment in which more detailed local weather information (e.g., pinpoint humidity, wind speed, radiant heat data) and hazard information (e.g., areas where heatstroke warning alerts have been issued), which can be obtained from the server 30 etc. based on location information, are referenced as input parameters for risk assessment. In this case, the monitored terminal queries the server using location information and incorporates the obtained information into the judgment logic. (3) An approach that analyzes changes in location information from the past (movement speed and movement pattern), estimates the user's current activity level and metabolic rate, and uses these as corrective factors for risk assessment. Thus, the location information acquired by the monitored terminal is not simply treated as geographic coordinates indicating its location, but is actively incorporated into the internal processing of the judgment unit 230 as important decision-making material to improve the accuracy and individual suitability of heatstroke risk assessment. This makes it possible to determine the level of risk with greater reliability compared to relying solely on environmental sensors.

[0034] (Modified example: Refinement of risk assessment using location information) The determination unit 230 can more actively utilize the acquired location information in the process of determining the risk of heatstroke. For example, the following embodiments are possible. (1) Based on the acquired location information, the system determines whether the monitored device is currently outdoors or indoors, and applies adjustments such as increasing the weight of solar radiation-related parameters (illuminance, ultraviolet intensity) only if it is outdoors, or lowering the risk level by one level if it is determined to be indoors. (2) The acquired location information is associated with more detailed local weather information (e.g., wind speed and radiant heat information for a specific area) and map information (e.g., parks, urban areas with a lot of asphalt, waterfront areas, etc.) provided by the server 30, and risk correction is performed according to the characteristics of the location. (3) Based on past movement history (location information trajectory), it is determined whether the user is currently moving (e.g., walking) or staying in one place, and the result of this determination is used to estimate the amount of activity and reflected in the risk assessment. These processes not only acquire environmental information but also enable more situation-specific and highly accurate risk assessments that take into account "where" and "in what situation" the user is. These processes utilize the information processing capabilities of the computer (the monitored terminal or server) to realize risk assessments based on detailed situational analysis, which was previously difficult, and improve the functionality.

[0035] (e) Notification control unit 240 Specific implementation example: A software module that operates on the MCU110 and controls the drivers for the notification unit 150 (light-emitting element 151, vibration motor 152) and the display 104. Core function: The determination unit 230 notifies the user of the risk of heatstroke in a direct and perceptible manner, according to the determined heatstroke risk level. Higher-level concept: The function of presenting determined information in a form perceptible to humans. Intermediate concepts: (1) Visual notification (light color and flashing pattern), (2) Tactile notification (vibration intensity and pattern), (3) Auditory notification (buzzer sound pattern, optional), (4) Detailed information notification via display. Lower-level concept (see Figure 4 in this embodiment): The determination unit 230 receives the danger level (e.g., "Level 4: Dangerous"). Referring to the notification pattern table 400 in Figure 4, the notification pattern corresponding to the level is identified. For example, if it is "Level 4", control signals are generated to "blink the light-emitting element 151 in red with a period of 2 times per second" and "drive the vibration motor 152 in a pattern of repeating vibration for 0.5 seconds and stopping for 1.5 seconds", and these are output to the corresponding hardware drivers in the notification unit 150. At the same time, a drawing command is sent to the display 104 to display a warning message such as "Danger! Take a break immediately" and the danger level. Specific processing steps: (1) Receive the danger level from the determination unit 230. (2) Refer to the notification pattern table 400 stored in the memory unit 120 and identify the light emission pattern, vibration pattern, and display message corresponding to the received danger level. (3) Instruct the driver of the light-emitting element 151 to operate with the identified color and flashing period. (4) Instruct the driver of the vibration motor 152 to operate with the identified vibration pattern. (5) Instruct the driver of the display 104 to display the identified message and danger level. Coordination with other elements: The system receives the risk level from the determination unit 230 and controls the hardware of the notification unit 150 and the display 104.

[0036] (Supplementary information regarding the timing and manner of notification) In this specification, when the monitored terminal 10 "provides notification according to the determined level of danger," in its most basic form, it means that the notification control unit 240 autonomously controls the notification unit 150 (light-emitting element 151, vibration motor 152) and the display 104 to perform notification based on the level of danger determined by the determination unit 230 (see S307 in Figure 3). However, the phrase "providing notification according to the degree of risk" in this invention may also include the following embodiments. (1) Notification control via server cooperation: The monitored terminal 10 first sends the determined risk level information (or the information underlying it) to the server 30, and the server 30, considering that information and other information (e.g., guardian settings, wide-area weather information, time of day, etc.), instructs the monitored terminal 10 on the execution, timing, or manner of notification (e.g., raising or lowering the notification level, activating only specific notification means, temporarily suppressing it, etc.), and the monitored terminal 10 makes notifications according to those instructions. In this case, the notifications made by the monitored terminal can be interpreted as substantially "responding" to both the risk level it initially determined and the instructions from the server (which are also related to the initially determined risk level). (2) Conditional autonomous notification: After the monitored terminal 10 determines the level of danger, it will autonomously provide notification unless there is an explicit instruction from the server 30, but will comply if the server 30 gives an instruction to suppress or modify the notification under specific conditions (e.g., class time mode). In these embodiments as well, the monitored terminal 10 is the entity that performs notification actions in relation to the degree of danger it has acquired and determined, and plays an important role in achieving the objective of the present invention, which is to inform the user of danger as a whole system.

[0037] (f) Communication processing unit 255 Specific implementation example: A software module that operates on the MCU110, controls the drivers for the communication unit 130 (BLE module, LTE-M module), and generates and analyzes data formats (e.g., CBOR / JSON in Figure 9). Core function: The determination unit 230 transmits information regarding the heatstroke risk level, as well as various data acquired by the location acquisition unit 205 and the environment acquisition unit 210, to the server 30. It also receives instructions and data from the server 30 (e.g., weather forecasts, threshold settings). Specific processing steps (during data transmission): (1) The latest risk level is received from the determination unit 230, location information from the location acquisition unit 205, and various sensor data from the environment acquisition unit 210. (2) This information is formatted and packaged into a predetermined data payload 900 format as shown in Figure 9 (e.g., serialized with CBOR and encrypted with AES-128-GCM). (3) The data is transmitted to the specified endpoint of the server 30 via the communication unit 130. (4) The transmission result (success / failure) is checked, and retransmission processing is performed as necessary. Coordination with other elements: The system receives transmission data from the determination unit 230, the position acquisition unit 205, and the environment acquisition unit 210, and controls the hardware of the communication unit 130 to communicate with the server 30.

[0038] (External identifiability of risk determination) The risk level determined by the determination unit 230 can be clearly observed externally via the notification control unit 240, through a unique notification pattern by the notification unit 150 (see Figure 4) and a display on the display 104. For example, when a risk level of "Level 4: Dangerous" is determined, a notification is always made that is distinguishable from other levels, namely a rapid flashing of red light. Therefore, by observing this unique notification pattern from the outside, it is possible to objectively identify that a risk level of "Level 4: Dangerous" has been determined inside the monitored terminal 10. Furthermore, the determined risk level is included in the data payload 904 shown in Figure 9 and transmitted to the server 30. By observing this communication data, it is also possible to identify the existence and result of the internal determination process.

[0039] 2.3. Processing Flow (Figure 3) Figure 3 is a detailed flowchart of the processes that the monitored terminal 10 periodically executes. (S301) When processing begins, the position acquisition unit 205 first starts the GNSS module and acquires position information. (S302) Next, the environmental data acquisition unit 210 acquires various environmental data from the sensor group 140. (S303) The correction unit 220 corrects the outside temperature using the acquired $T_{out}$ and T_{in}$. (S304) The correction unit 220 calculates the Wet Bulb Globe Temperature (WBGT) using the corrected outside temperature, etc. (S305) The determination unit 230 determines whether the calculated WBGT and UVI exceed the threshold values ​​set for each. (S306) The judgment unit 230 determines the final risk level (1 to 4) based on the judgment result. (S307) The notification control unit 240 controls the lighting and flashing of the LEDs and the driving of the vibration motor in the pattern shown in Figure 4 according to the determined level, and also displays information on the display 104 to notify the user. (S308) The communication processing unit 255 determines whether the current risk level has changed since the last transmission, or whether a certain amount of time (e.g., 15 minutes) has elapsed. (S309) If the transmission conditions are met (YES in S308), the communication processing unit 255 generates a data payload as shown in Figure 9 and sends it to the server 30 via the communication unit 130. After that, the process ends. If the transmission conditions are not met (NO in S308), the process ends without transmission.

[0040] 3. Details of Server 30 (Figure 11) Figure 11 is a block diagram showing the functional configuration of the server 30 according to this embodiment. The functions of the server 30 are realized, for example, by one or more server computers operating on a cloud computing environment executing a predetermined program. The server 30 mainly comprises a terminal communication unit 1110, an application communication unit 1120, a risk assessment unit 1130, a data storage unit 1140, and a push notification unit 1150.

[0041] (Supplementary and expanded interpretation of the server role "relay") In this specification, when the server 30 "relays" the risk level between the monitored terminal 10 and the guardian terminal 20, in its most basic form, it refers to the function of transmitting the risk level information (or related information) received from the monitored terminal 10 to the guardian terminal 20 without substantially changing it, or after performing minor processing such as converting it into a format suitable for display. However, the role of the server 30 in the present invention is not limited to such a simple data relay function. The "relaying" function may also include the following embodiments. (1) Data storage and history management: Received risk information and related data (location information, sensor data, etc.) are stored chronologically in the data storage unit 1140 and provided as history information upon request from the parent terminal 20. In this case, the data is first stored on the server and then transmitted upon request, so this can also be considered a "relay" in a broad sense. (2) Data processing and generation of value-added information: The server 30 performs major risk assessment processing based on the received information (including raw sensor data and intermediate indicator values) (see modified example C), or statistically processes information from multiple monitored terminals to generate value-added information such as regional risk trends and average values, and transmits this along with the original risk information to the guardian terminal. In this case as well, the information is ultimately delivered to the guardian terminal, so it can be interpreted as a form of "relay" involving processing. (3) Management of two-way communication: Not only risk level information, but also status information of the monitored device (battery level, communication status, etc.), messages from guardians, distribution of firmware updates, etc., are managed and mediated between the monitored device and the guardian's device. (4) Limited involvement: Even when the primary communication is directly between the monitored terminal 10 and the guardian terminal 20 (e.g., BLE, Wi-Fi Direct) (see modified example A), the "server" of the present invention may also be considered to have a limited role in contributing to the overall information transmission of the system, such as a function to relay communication as a backup when the two are outside the direct communication range, or a function to mediate the exchange of terminal information during the initial connection. Therefore, the server 30 can take various forms, ranging from simple data relay to those with advanced information processing and management functions, contributing to the smooth transmission of information between the monitored terminal and the guardian terminal and realizing the overall functionality of the system.

[0042] (a) Terminal communication unit 1110 Specific implementation examples: This can be implemented as application logic running on a communication gateway compatible with IoT protocols such as LTE-M / NB-IoT, and on an MQTT broker or HTTP server that accepts incoming data. Core function: Establish and maintain wireless communication (mainly uplink) with the monitored terminal 10, receive data, and perform basic verification (e.g., data format, authentication information). Internal structure and data retention: Receive buffer, authentication token verification module, data parser. Specific processing steps: (1) Constantly wait for data transmission from the monitored terminal 10 (see Figure 9) (e.g., TCP / IP socket listening). (2) When data is received, identify the terminal ID from the header information and perform authentication. (3) Deserialize the payload (e.g., CBOR to JSON) and verify that the data format is correct. (4) Asynchronously pass the verified data to the risk determination unit 1130 (in the case of modified example C) and the data storage unit 1140 via the internal message queue. Coordination with other elements: Data is received from the monitored terminal 10 and passed to the risk assessment unit 1130 and the data storage unit 1140.

[0043] (b) App Communications Unit 1120 Specific implementation example: It will be implemented as a Web API that handles HTTP / HTTPS requests from applications on the parent device 20. API endpoints such as / latest_status, / history, and / settings will be provided. Core function: Establish and maintain secure communication with the parent terminal 20, provide data in response to requests from the parent terminal, and send instructions to the push notification unit 1150 that trigger push notifications. Internal structure and data retention: API gateway, request handler, response generation module, session token management module. Specific processing steps: (1) Receive data acquisition requests from the parent terminal 20 (e.g., latest risk level information for a specific terminal ID, historical data for the past 24 hours) via HTTPS. (2) Verify the authentication token included in the request. (3) Search and acquire the necessary data from the data storage unit 1140 using SQL queries, etc., according to the request. (4) Format the acquired data into a JSON format that is easy for the parent terminal 20 to process and send it back as an HTTPS response. (5) If a setting change request (e.g., change of notification threshold) is received from the parent terminal, save the contents in the data storage unit 1140. Coordination with other elements: It communicates bidirectionally with the parent terminal 20, acquires and updates data from the data storage unit 1140, and sends instructions to the push notification unit 1150.

[0044] (c) Risk assessment unit 1130 Specific implementation example: A software module containing a rule-based engine or machine learning model inference engine that becomes active when the risk level is determined on the server side, as described in Modification C (Server-side implementation of the risk level determination function). Core function: Based on raw environmental information (or primary processed information) received from the monitored terminal 10 and supplementary information (e.g., wide-area weather forecast, user-set individual thresholds, past similar situation data) stored in the data storage unit 1140, the system determines the risk of heatstroke. Internal structure and stored data: Decision rule set, machine learning model (see Appendix G), weather information acquisition module (integrates with external weather API). Specific processing steps: (1) Receive environmental information and location information of the monitored terminal from the terminal communication unit 1110. (2) Obtain the risk level determination threshold set by the user of the terminal and the latest wide-area weather forecast (humidity, wind speed, etc.) corresponding to the location from the data storage unit 1140. (3) Using this information as input, execute a predefined determination logic (e.g., WBGT calculation formula, threshold comparison rule, machine learning model) to determine the risk level. (4) Store the determined risk level and the main parameters that formed the basis of it in the data storage unit 1140. (5) If the risk level meets a predetermined condition (e.g., rises to the "danger" level), instruct the push notification unit 1150 to send an immediate notification. Coordination with other elements: The terminal communication unit 1110 receives environmental information, the data storage unit 1140 acquires and stores supplementary information, and the determined risk level is passed to the application communication unit 1120 (as requested by data) or the push notification unit 1150.

[0045] (d) Data storage unit 1140 Specific implementation example: A configuration combining a relational database management system (RDBMS) with a database specialized for time-series data. User account information, terminal information, and configuration information are stored in the RDBMS, while sensor data and risk history generated over time are stored in the time-series database. An ORM (Object-Relational Mapper) or a dedicated query language is used for data access. Core function: Permanently records and manages all time-series data (location, environment, risk level) received from the monitored terminal 10, data determined and generated on the server side, user account information, and parent terminal settings information, and quickly provides data in response to requests from other functional units. Internal structure and data retention: User table, terminal table, sensor data table (time series), risk history table (time series), settings table, etc. Index, backup and restore mechanism. Specific processing steps: (1) Accept data write requests (INSERT, UPDATE) from other functional units and persist them to the database under transaction management. (2) Accept data read requests (SELECT), execute queries, and return result sets. (3) Perform periodic data backups and data aggregation / statistical processing (e.g., daily / weekly risk summary generation). Integration with other elements: Accessed by all functional units within the server, it serves as the central hub for data persistence and retrieval.

[0046] (e) Push notification unit 1150 Specific implementation examples: A client library for connecting to push notification services provided by mobile OS platform providers, such as APNs (Apple Push Notification Service) and FCM (Firebase Cloud Messaging), and a software module containing the logic for managing and sending notification messages. Core function: When a specific event occurs (e.g., the risk level reaches "dangerous", the battery level is low), it sends a real-time push notification to the application on the parent device 20. Internal structure and stored data: Notification templates, device token management list (linked to data storage unit 1140), transmission queue. Specific processing steps: (1) Receive notification instructions and notification content (message, payload) for a specific user (parent device) from the application communication unit 1120 or the risk assessment unit 1130. (2) Obtain the latest device token of the target user's parent device 20 from the data storage unit 1140. (3) Format the notification content to match the specifications of each push notification service (APNs / FCM). (4) Send the formatted notification request to the corresponding push notification service. (5) Log the transmission result (success, failure, invalid token, etc.) and update the device token information in the data storage unit 1140 as necessary. Integration with other elements: Receiving instructions from the application communication unit 1120 and the risk assessment unit 1130, the device token is obtained from the data storage unit 1140, and the system integrates with external push notification services.

[0047] 4. Details of the parent device 20 (Figure 10) Figure 10 is a block diagram showing the functional configuration of the parental terminal 20 according to this embodiment. These functions are realized by the execution of a dedicated application program installed on the parental terminal 20 by its processor. The parental terminal 20 mainly comprises a communication unit 1010, a data management unit 1020, a display control unit 1030, and a user input receiving unit 1040.

[0048] (a) Communications Department 1010 Specific implementation example: A software module that performs HTTP / HTTPS communication using network APIs provided by the smartphone's operating system (e.g., URLSession, OkHttp / Retrofit). Core function: Secure data communication (mainly sending requests and receiving responses) with server 30 to obtain heatstroke risk information and other related information. It also handles the registration process for receiving push notifications. Specific processing steps: (1) Based on instructions from the data management unit 1020, generate and send an HTTP / HTTPS request (e.g., GET request to retrieve the latest status, POST request to update settings) to the API endpoint of server 30. The request includes authentication information (e.g., access token). (2) Receive the HTTP / HTTPS response from server 30. (3) Check the status code of the response, and if successful, extract the payload (e.g., JSON data) and pass it to the data management unit 1020. If there is an error, perform error handling. (4) When the application starts, obtain a device token from the push notification service (APNs / FCM) and register it with server 30. Integration with other elements: Based on requests from the data management unit 1020, a request is sent to the server 30, and the received data is passed to the data management unit 1020. It also integrates with the OS's push notification function.

[0049] (b) Data Management Department 1020 Specific implementation examples include data model classes within the application, state management libraries, and accessors to local persistent storage. Core function: The application centrally stores and manages risk level information, location information, sensor data history, and parental settings information of the monitored terminal received from the server 30. It also processes and provides the data in the format required by the display control unit 1030 and notifies of changes in the data status. Internal structure and retained data: Latest risk status object, location information object, time-series data list, user-defined object. Data caching mechanism. Specific processing steps: (1) Receive server response data (JSON, etc.) from the communication unit 1010 and parse (convert) it into a data model object in the application. (2) Hold the parsed data as a state in memory and persist it to local storage as needed. (3) Provide the data necessary for display in an appropriate format in response to a request from the display control unit 1030 (e.g., generate a dataset for graph plotting). (4) If the data state changes (e.g., new risk information is received), issue an update notification to the display control unit 1030 to prompt a screen redraw. (5) Based on instructions from the user input reception unit 1040 (e.g., setting change), prepare data to send to the server and request the communication unit 1010 to send it. Coordination with other elements: It receives data from the communication unit 1010, provides display data to the display control unit 1030, and requests data updates from the communication unit 1010 based on instructions from the user input reception unit 1040.

[0050] (c) Display control unit 1030 Specific implementation example: A group of software modules built using a mobile OS UI framework, responsible for the logic and rendering of various screens (views). Core function: Based on data received from the data management unit 1020, information such as heatstroke risk level, location information, and history graphs are displayed and updated on the parent terminal's screen as a graphical user interface (GUI) as shown in Figure 6. Internal structure and data retention: View components corresponding to each screen, such as the dashboard screen (Figure 6, 801), detailed history screen (Figure 8, 802), and settings screen (Figure 8, 803). Modules for integration with map display libraries and graph plotting libraries. Specific processing steps: (1) Receive the latest display data and update notifications from the data management unit 1020. (2) Based on the received data, update the display content, color, shape, position, etc. of each UI element on the screen (text labels, icons, map markers, graph lines, etc.). (3) Smoothly redraw the screen with animation and transition effects. (4) Detect user actions (tap, swipe, etc.) and transmit the event information to the user input reception unit 1040. Integration with other elements: Receives display data from the data management unit 1020 and displays it on the screen. Transmits user operation events to the user input reception unit 1040.

[0051] (d) User input receiving unit 1040 Specific implementation examples: These are implemented within the view components of each screen as event listeners and callback mechanisms provided by the UI framework (e.g., onClick listeners for buttons, gesture recognizers). Core function: Detects on-screen operations by parents (button taps, list selections, map zoom / pan, setting changes, etc.) and instructs the data management unit 1020 and the display control unit 1030 (screen transitions, etc.) to perform appropriate processing according to the nature of the operation. Specific processing steps (see Figures 6 and 8): (Example 1: Graph tap operation) (1) The display control unit 1030 (graph 603 on the dashboard screen 801) receives an event indicating that the user has tapped a specific point on the graph. (2) The time and data point corresponding to the tapped point are identified. (3) Detailed historical data around that time is requested from the data management unit 1020. (4) The display control unit 1030 is instructed to transition to the detailed history screen 802. (Example 2: Tap operation of settings icon) (1) The display control unit 1030 (settings icon 604 on dashboard screen 801) receives an event indicating that the icon has been tapped. (2) The display control unit 1030 is instructed to transition to the settings screen 803. (Example 3: Tap operation of save button on settings screen) (1) The display control unit 1030 (settings screen 803) receives an event indicating that the save button has been tapped and the changed setting value. (2) The data management unit 1020 is instructed to send the changed setting value to the server. Coordination with other elements: The display control unit 1030 (UI) receives user operation events and instructs the data management unit 1020 (data processing, server coordination) and the display control unit 1030 (screen transitions) to perform processing.

[0052] 5. Further effects of the invention The present invention also produces the following secondary and derivative effects. Firstly, by repeatedly experiencing objective indicators of danger (such as LED color and vibration), the children themselves, as users, can learn about the relationship between their own perceptions and environmental risks, and it is expected that this will have an educational effect, improving their ability to spontaneously avoid danger, i.e., their self-management skills and health literacy. Secondly, parents are freed from vague anxieties and can confirm their child's safety based on objective data, significantly reducing their psychological burden. Furthermore, even when a danger is reported, they can calmly provide specific instructions and responses according to the level of danger. Thirdly, as this system is used by a large number of users, a vast amount of anonymized environmental and location information can be accumulated on the server as big data. By statistically analyzing this data, it may be possible to construct a highly detailed real-time heat environment map that was previously unavailable, potentially creating social value that contributes to public health (e.g., raising awareness among local residents), urban planning (e.g., heat island countermeasures), event management (e.g., safety management at outdoor events), etc. These effects are realized through the creation of new value through collaboration between computers and humans, where the information provided by the system of the present invention is presented through a user interface and influences human judgment and behavior.

[0053] 6. Variations The present invention is not limited to the embodiments described above. Within the scope of its technical concept, a wide variety of modifications and applications are possible.

[0054] (Variation A: Serverless configuration) The heatstroke risk notification system of the present invention is not limited to a configuration via a server 30. For example, a configuration in which the monitored terminal 10 and the guardian terminal 20 establish a direct communication path using BLE, Wi-Fi Direct, or other short-range wireless communication standards and send and receive information regarding the determined heatstroke risk is also included in the technical concept of the present invention. In this case, the guardian terminal 20 may perform some or all of the functions that the server 30 was responsible for, such as storing a history of received risk information in its own memory.

[0055] (Variation B: Sharing and transfer of notification functions) In the system of the present invention, the notification function to the user is not necessarily limited to the monitored terminal 10. For example, in order to simplify, miniaturize, and reduce the power consumption of the monitored terminal 10, a configuration is conceivable in which the direct notification function to the user (e.g., light-emitting element 151 or vibration motor 152) is omitted. In this case, the monitored terminal 10 is solely dedicated to determining and transmitting the level of danger, and the guardian terminal 20, which receives the level of danger information, issues an alert to the guardian (e.g., push notification, warning sound, full-screen flash display, etc.) according to the received level of danger, thereby realizing a function of notifying danger as a whole system. Alternatively, the server 30 may be configured to simultaneously send emergency notifications not only to the guardian terminal 20 but also to multiple terminals of pre-registered relevant parties according to the received level of danger. In this way, the responsibility for the notification function can be flexibly shared or delegated among the components of the system.

[0056] (Variation C: Server-side implementation of the risk assessment function) In this embodiment, a configuration in which the monitored terminal 10 determines the heatstroke risk level has been mainly described, but the present invention is not limited thereto. For example, the monitored terminal 10 may be configured to focus solely on transmitting acquired location information and environmental information (raw sensor data or primary processed data) to the server 30, while the main determination processes for determining the heatstroke risk level (e.g., threshold comparison, WBGT calculation, classification into grade levels) are performed on the server 30 side. In this case, the server 30 returns the determined risk level information to the monitored terminal 10, and the monitored terminal 10 issues a notification based on the received risk level information. Even with such a configuration, the monitored terminal can be considered to be substantially involved in the risk level determination process in that it treats the risk level information that triggers the final notification as part of the system and executes the notification. Therefore, an architecture in which all or part of such determination functions are shared with an external device such as a server may also be included within the scope of the technical idea of ​​the present invention.

[0057] (Variation D: Diversity of index names and expressions) The term "heatstroke risk" as used herein is not limited to this name. Any index that evaluates the physiological effects of a hot environment on the human body and the degree of impairment to activities resulting therefrom, and shows it in multiple stages, may fall under the "heatstroke risk" of the present invention. For example, even if it has a different name or expression (including positive and neutral expressions), such as "activity comfort index," "exercise performance prediction level," or "outdoor activity recommendation level," if its calculation basis is based on physical and physiological parameters such as temperature, humidity, solar radiation, and activity level, and it presents a staged index that substantially correlates with the risk of heatstroke to the user or their related parties, it falls within the scope of the technical idea of ​​the present invention. In this case, the determination unit 230 determines these alternative indices, and the notification unit 150 can provide notification according to the stage level of the index, for example, green for "activity recommendation level: high," yellow for "activity recommendation level: medium," and red for "activity recommendation level: low."

[0058] (Variation E: External setting of risk assessment criteria) The criteria for determining the risk of heatstroke (for example, a threshold value for WBGT) do not necessarily need to be fixedly stored in the memory unit 120 of the monitored terminal 10. For example, the application on the guardian terminal 20 may allow the guardian to arbitrarily set and change threshold values ​​corresponding to each risk level according to the child's constitution and physical condition on that day. In this case, the set threshold information is transmitted from the guardian terminal 20 to the monitored terminal 10 via the server 30, and the judgment unit 230 uses the received threshold values ​​to perform the risk determination process. Alternatively, the monitored terminal 10 may only transmit environmental index values ​​to the server 30, where the server 30 compares them with the threshold values ​​set by the guardian to determine the risk level and notifies the monitored terminal 10 and the guardian terminal 20 of the result. In this way, even when the judgment criteria for determining the risk level are dynamically set or changed based on external information such as user settings, the system still falls within the scope of the technical idea of ​​the present invention in that it acquires environmental information, compares that information with the dynamically set judgment criteria, and performs a process to derive a stepwise risk level.

[0059] (Variation F: Alternative correction method for the heat-induced effects of stagnation) In this embodiment, a configuration has been described in which the effect of trapped heat is corrected based on the temperature difference between the external temperature sensor 143 and the internal temperature sensor 144. However, the method for correcting or estimating the effect of trapped heat is not limited to this. For example, the monitored terminal 10 may be equipped with only a single temperature sensor and indirectly estimate the effect of trapped heat by combining information from other sensors. Specifically, the determination unit 230 determines that if the solar radiation intensity detected by the illuminance sensor 142 or the ultraviolet sensor 141 is above a predetermined threshold, and the movement of the terminal detected by the acceleration sensor 145 (for example, the variance of acceleration within a predetermined time) is below a predetermined threshold (i.e., if the sunlight is strong and it is estimated that the terminal is stationary, such as inside a bag), then there is a high possibility that the value measured by the single temperature sensor contains a positive bias due to trapped heat. The determination unit then corrects the measured value by subtracting a correction value calculated according to the solar radiation intensity and stationary time, or by multiplying it by a predetermined correction coefficient. Thus, a configuration that combines different types of sensor information to estimate the situation and correct temperature information also solves the technical problem of the present invention, which is to grasp the ambient temperature more accurately and determine the risk of heatstroke, and is therefore included within the scope of the technical concept of the present invention.

[0060] Furthermore, the embodiments and modifications disclosed herein may be combined, omitted, or replaced with other elements or steps as appropriate, without departing from the spirit thereof. [Note]

[0061] [General tasks] This system enables notification of health risks in the environment in which the person being monitored is placed. This system can provide information about the risk of heatstroke in the environment in which the person being monitored is located. This technology enables efficient sharing of information regarding heat stress risks in the user's local environment, not only with the user themselves but also with relevant parties such as guardians, allowing for swift and effective responses tailored to the situation.

[0062] [Issues corresponding to Appendix 1] To provide a system that assesses the localized heat risk of users and allows that information to be shared between the user and their guardian. [Note 1] A monitoring terminal that acquires location information, obtains at least one of the following: illuminance, UV intensity, external temperature, or internal temperature, determines the risk of heatstroke, and issues a notification according to the risk level. A parental device that receives and displays the aforementioned risk level, A server that relays the risk level between the monitored terminal and the guardian terminal, A heatstroke risk notification system equipped with the following features. (Effects of Appendix 1) The monitored device determines and reports the level of risk based on the local environment, and this information is shared with the guardian's device via the server. This allows both the user and the guardian to recognize the heat risk and take coordinated action.

[0063] [Issues corresponding to Appendix 2] To provide a terminal that can assess heat stress risk based on local environmental information and directly notify users. [Note 2] A location acquisition unit that acquires location information, An environmental data acquisition unit that acquires at least one of the following: illuminance, UV intensity, external temperature, and internal temperature. A determination unit that determines the risk of heatstroke based on the location information and the output of the environment acquisition unit, A notification unit that provides notification according to the risk level of heatstroke, A monitoring terminal equipped with the following features. (Effects due to Appendix 2) The monitored device autonomously determines the risk of heatstroke based on the user's current location and surrounding environmental information (illumination, UV, temperature, etc.) and notifies the user directly, thereby encouraging prompt action to avoid danger.

[0064] [Issues corresponding to Appendix 3] To enable parents to easily check the heat risk information assessed by the monitored device on their own device. [Note 3] Computers, A means for receiving the heatstroke risk level transmitted from the monitored device, and A means of displaying the received heatstroke risk level on the display unit of the parent's device. A program designed to function as such. (Effects of Appendix 3) By running this program on the parent's device, risk level information from the monitored device can be received and displayed on the screen, allowing parents to easily understand their child's situation remotely.

[0065] [Issues corresponding to Appendix 4] To provide a server function that efficiently relays heat risk information between the monitored device and the guardian's device. [Note 4] A receiving unit that receives the heatstroke risk level transmitted from the monitored device, A transmitting unit that sends the received heatstroke risk level to the parent's device, A server device equipped with the following features. (Effects of Appendix 4) The server device receives risk level information from the monitored terminal and reliably relays it to the guardian's terminal, improving the reliability and efficiency of information transmission throughout the entire system.

[0066] [Issues corresponding to Appendix 5] To clarify the internal process of "determining the risk level of heatstroke" and stabilize the scope of rights. [Note 5] A heatstroke risk notification system according to claim 1, wherein the determined heatstroke risk includes a plurality of discrete levels. (Effects of Appendix 5) By defining the degree of risk not as a simple continuous value but as being classified into multiple levels, the technical characteristics of the invention are clarified, and infringement is made easier to determine.

[0067] [Issues corresponding to Appendix 6] To objectively identify, from an external perspective, the existence and results of the internal process of determining the level of risk, thereby facilitating proof of infringement. [Note 6] A heatstroke risk notification system according to claim 5, wherein the monitored terminal transmits information indicating the determined stage level to the server. (Effects of Appendix 6) By including the risk level in the communication data, a third party can objectively prove the existence of internal decision-making processes by observing the communication.

[0068] [Issues corresponding to Appendix 7] To compensate for the effects of trapped heat inside bags and other similar items, thereby achieving more accurate risk assessment. [Note 7] The monitoring terminal according to claim 2, wherein the environment acquisition unit acquires external temperature and internal temperature, and the determination unit uses the temperature information corrected based on the difference between these to determine the risk of heatstroke. (Effects of Appendix 7) By using the temperature difference between the inside and outside to correct the temperature, more realistic temperature information can be obtained, improving the accuracy of heatstroke risk assessment.

[0069] [Issues corresponding to Appendix 8] To improve the accuracy of outdoor risk assessments by taking into account the presence and intensity of sunlight in the risk assessment. [Note 8] A monitoring terminal according to claim 2 or 7, wherein the environment acquisition unit acquires illuminance or ultraviolet intensity, and the determination unit uses the conditions of solar radiation to determine the risk of heatstroke. (Effects of Appendix 8) By directly incorporating solar radiation, a major cause of heatstroke, into the assessment process, the level of risk, especially during activities in direct sunlight, can be evaluated more accurately.

[0070] [Issues corresponding to Appendix 9] To further refine the risk assessment by considering various factors such as humidity and the user's activity level. [Note 9] A captured terminal according to any one of claims 2, 7, or 8, wherein the environmental acquisition unit further acquires information indicating at least one of humidity or the user's activity level. (Effects of Appendix 9) By taking humidity and activity levels into account, the accuracy of WBGT calculations can be improved, and more personalized risk assessments tailored to individual circumstances can be made possible.

[0071] [Issues corresponding to Appendix 10] It should be made clear that the monitored terminal has the functionality to interact with other terminals, even in a serverless configuration that does not involve a server. [Note 10] A monitoring terminal according to any one of claims 2, 7, 8, or 9, further comprising a communication processing unit that transmits information indicating the determined risk level of heatstroke to other electronic devices. (Effects of Appendix 10) By defining that the terminal itself has communication capabilities, it becomes possible to assert rights even in system configurations that do not involve a server, such as P2P communication, making it difficult to design circumvention measures.

[0072] [Note G] (Personalization of risk assessment by AI) The present invention can be further developed by applying AI (artificial intelligence), particularly machine learning technology. For example, the server 30 performs machine learning using time-series data of environmental information, location information, and activity levels collected from each user's monitored terminal 10, along with daily health feedback (e.g., "good," "a little tired") optionally entered by the guardian, as training data. This generates a personalized heatstroke risk prediction model optimized for each user's constitution and behavioral patterns. The generated model is applied to the monitored terminal 10 or the risk determination unit 1130 of the server 30, achieving a risk determination that is more accurate and tailored to the individual than threshold-based determination. Such an AI-based configuration is also within the scope of the technical concept of the present invention. This AI-based determination involves the computer generating a new learning model and using it to perform advanced information processing (personally adapted risk prediction) that could not be achieved with conventional technology, substantially improving the computer's capabilities. [Explanation of Symbols]

[0073] 1… Heatstroke risk notification system 10…Monitored device 20…Parental device 30… Server 35…Database 100... cabinet 101... Slit 102... Light Diffusion Guide 103...Strap hole 104…Display 105... Button 110…MCU 120...Storage section 130... Communications Department 140...Sensor group 141… UV sensor 142... Illuminance sensor 143...External temperature sensor 144...Internal temperature sensor 145...Accelerometer 150…Notification department 151…Light-emitting element 152…Vibration motor 160... Distance calculation unit 180...location information acquisition unit 205...Position acquisition unit 210…Environmental Acquisition Department 220... Correction section 230...Judgment section 240...Notification Control Unit 255...Communication Processing Unit 300...bag 400... Notification pattern table 600...Application screen (dashboard screen) 601... Danger level indicator 602…Map display area 603…Time series graph 604…Settings icon 801... Dashboard screen 802...Detailed history screen 803...Settings screen 900…Data Payload 901… Terminal ID 902… Timestamp 903…location information 904... Danger Level 905…Detailed data 1010…(Parental Terminal) Communications Department 1020…(Parental Terminal) Data Management Department 1030…(Parental Terminal) Display Control Unit 1040…(Parent terminal) User input reception section 1110... (Server) Terminal Communications Unit 1120... (Server) Application Communications Department 1130... (Server) Risk Assessment Unit 1140…(Server) Data Storage Unit 1150…(Server) Push Notification Section NW...Network

Claims

1. A monitoring terminal that acquires location information, obtains at least one of the following: illuminance, UV intensity, external temperature, or internal temperature, determines the risk of heatstroke, and issues a notification according to the risk level. A parental device that receives and displays the aforementioned risk level, A server that relays the risk level between the monitored terminal and the guardian terminal, A heatstroke risk notification system equipped with the following features.

2. A location acquisition unit that acquires location information, An environmental data acquisition unit that acquires at least one of the following: illuminance, ultraviolet intensity, external temperature, and internal temperature, A determination unit that determines the risk of heatstroke based on the location information and the output of the environment acquisition unit, A notification unit that provides notification according to the risk level of heatstroke, A monitoring terminal equipped with the following features.

3. Computers, A means for receiving the heatstroke risk level transmitted from the monitored device, and A means of displaying the received heatstroke risk level on the display unit of the parent's device. A program designed to function as such.

4. A receiving unit that receives the heatstroke risk level transmitted from the monitored device, A transmitting unit that sends the received heatstroke risk level to the parent's device, A server device equipped with the following features.

5. The heatstroke risk notification system according to claim 1, characterized in that the determined heatstroke risk includes a plurality of discrete step levels.

6. The heatstroke risk notification system according to claim 5, characterized in that the monitored terminal transmits information indicating the determined stage level to the server.

7. The monitored terminal according to claim 2, characterized in that the environmental acquisition unit acquires external temperature and internal temperature, and the determination unit uses the temperature information corrected based on the difference between these to determine the risk of heatstroke.

8. The monitored terminal according to claim 2, characterized in that the environmental acquisition unit acquires illuminance or ultraviolet intensity, and the determination unit uses the solar radiation conditions to determine the risk of heatstroke.

9. The monitored terminal according to claim 2, characterized in that the environmental acquisition unit further acquires information indicating at least one of humidity or the user's activity level.

10. The monitored terminal according to claim 2, further comprising a communication processing unit that transmits information indicating the determined risk level of heatstroke to other electronic devices.

Images