JP2026058391A - System and Program - Google Patents

Abstract

[Challenge] To provide a system that is superior to conventional systems.
[Solution] A user-portable system comprising: a determination function that determines the occurrence of a disaster in the vicinity of the system based on the signal reception status; and a notification function that, when the occurrence of a disaster is determined by the determination function, sends a notification signal to the outside of the system to inform the public that the user may be stationed near the location of the system. With this system, the above-described functions make it easier for a third party to identify the location where the user is stationed, thereby contributing to the effective rescue of the user who has become a victim of a disaster.
[Selection Diagram] Figure 1

Description

This invention relates, for example, to systems and programs.

For example, communication devices that receive emergency alert signals are used to notify users of the occurrence of a disaster (see Patent Document 1).

Japanese Patent Publication No. 2009-116492

However, conventional systems had various problems. Therefore, the present invention aims to provide a system and program, etc., with superior characteristics compared to conventional systems.

The purpose of the present invention is not limited thereto. The applicant intends to obtain rights through divisional applications, amendments, etc., for configurations that aim to achieve the effects derived from the components disclosed in this specification and the drawings. For example, problems described in this specification as "can be achieved" can be reinterpreted as "the problem is..." and are disclosed accordingly. Each problem is described independently, and the applicant intends to obtain rights to the configurations for solving each of these problems individually through divisional applications, amendments, etc. Even if a problem is implicitly understood from the description in the specification, the applicant intends to include a portion of the configuration described in this specification in the claims through amendment or a divisional application. Furthermore, configurations that solve problems combining these independent problems are also disclosed, and the applicant intends to obtain rights to them.

(1) The system should be portable to the user and include a determination function that determines the occurrence of a disaster in the vicinity of the system based on the signal reception status, and a notification function that, when the determination function determines that a disaster has occurred, sends a notification signal to an external party to inform them of the possibility that the user is stationary near the location of the system.

In this way, if a disaster is detected, the system can notify external parties that a user may be stationary near the system's location.

The system in question only needs to consist of at least a portion of portable devices. It may also be configured entirely as a portable device. The system may be configured as a dedicated terminal, or some of its functions may be integrated into other devices.

The system should include, for example, a communication device such as a smartphone, and an accessory device capable of communicating with it. The communication device should have a judgment function, and the accessory device should have a notification function. Here, the communication device transmits the judgment result from its judgment function to the accessory device, which then sends a notification signal. Communication between the communication device and the accessory device should preferably be via a short-range communication standard such as Bluetooth® or NFC (Near-Field Communication). The accessory device should be a wearable terminal, such as a smartwatch or smart glasses. The wearable terminal could also be sewn into clothing, or be in the form of a ring or bracelet.

The detection function should determine the occurrence of a disaster based on at least one of the following signal reception conditions: for example, whether or not an emergency notification signal issued during a disaster is received; whether or not the communication status with specific or multiple relay stations such as mobile communication base stations or wireless LAN routers has changed; or the detection values from various sensors (e.g., acceleration sensors, vibration sensors, etc.) used to detect displacement associated with a disaster. Here, for example, the system should determine the occurrence of a disaster when it receives only an advertisement signal, an emergency notification signal that serves as a warning during a disaster is received, communication with specific or multiple relay stations suddenly ceases or becomes possible again due to a disaster, or various sensors output detection values corresponding to the occurrence of a disaster. In this way, the occurrence of a disaster can be determined based on the signal reception conditions.

For emergency warning signals, it is advisable to use signals broadcast during disasters, similar to public address systems. Specifically, for example, an earthquake early warning system via ETWS (Earthquake and Tsunami Warning System or Service) would be suitable. Earthquake early warnings are effective due to their high speed. This allows for the determination of a disaster occurrence by utilizing a system that widely disseminates information about the disaster. This system may directly receive incoming emergency warning signals or receive them indirectly through another device. This other device could be, for example, a radio receiver capable of detecting earthquake early warnings and emergency alert broadcasts from FM radio stations.

The "sensor for detecting displacement associated with disasters" should ideally be designed to be attached to structures such as windows, and capable of transmitting detected vibration values to the system. The system would then determine whether the detected values from the sensor correspond to vibrations severe enough to cause damage or breakage to the structure during a disaster. This sensor should ideally be housed in a module that generates electricity in response to vibrations and uses the generated power to transmit the detected values as pulse waves or similar signals. This power should be stored in an energy storage device such as a battery or capacitor.

The "disaster occurrence" determined by the detection function should be defined as a disaster of a magnitude that could cause users to be affected and unable to move, such as a major earthquake or fire. "Being affected and unable to move" could refer to situations where users are trapped or immobilized due to the collapse or damage of buildings, natural objects, etc. For example, a disaster of a magnitude that could cause users to be affected and unable to move should be defined as at least one of the following: the scale of the disaster notified by the emergency alert signal exceeds a certain magnitude; communication with a relay station that may experience communication disruption in the event of a disaster exceeding a certain magnitude is interrupted; communication with a predetermined number of relay stations in the vicinity is interrupted; the communication status with a specific relay station changes in conjunction with the disaster; or a large displacement is detected around the system by a "disaster-related displacement detection sensor." However, it is not limited to these examples; the system can also receive external information that indicates a situation requiring rescue, or a situation that is considered to potentially require rescue, and define this as a disaster occurrence. In this way, it is possible to determine the occurrence of a disaster of a magnitude that could cause users to be affected and unable to move.

Regarding the above situation, "communication with a specified number of relay stations in the surrounding area is interrupted" should be interpreted as, for example, a situation where communication with multiple base stations, which was normally possible, is suddenly interrupted due to malfunction or damage to all or more base stations. If communication with multiple base stations is suddenly interrupted, it is highly likely that communication, such as phone calls, becomes impossible in many places. Such widespread occurrences suggest the occurrence of a disaster, such as an earthquake. Regarding the above situation, "communication conditions are changing in conjunction with the disaster" should be interpreted as a relay station, which normally provides paid connection services but is set to be made free of charge during emergencies, being made free of charge.

The "disaster occurrence" determined by the detection function is determined based on the signal reception status. It may refer to the actual situation where a disaster has occurred, or it may refer to the situation where secondary disasters such as building collapse or fires resulting from the initial disaster have occurred. Furthermore, the "disaster occurrence" should also determine the level of the disaster.

The notification signal should be capable of providing information suitable for identifying the user's location. This would make it easier to pinpoint the user's location from the outside.

A suitable notification signal for locating a user's position would be a distress signal that, upon detection, aids in the search for the user. This signal should also be useful for identifying the location of a user who is stranded due to a disaster. For example, if a disaster victim is trapped inside a collapsed building such as their home, the signal should be able to reach roads or other areas surrounding the building. This would allow the system to detect, based on the notification signal, roughly where the user is buried, whether someone is buried, or if they are trapped in an elevator or similar structure.

For a notification signal suitable for identifying a user's location, it should be a signal that can be received directly without going through a communication network. For example, a signal that can be received near the system, or a signal that a person can directly perceive near the system, would be ideal.

A suitable notification signal for locating a user's location would be a sound that can reach within a predetermined range (e.g., a radius of 5 or 10 meters) centered on the system's location, at a signal level above a certain threshold. This makes it easier for a third party to locate the user using the sound as a clue. In other words, the user's location can be found by sound, as the search can be aided by any sound heard from within a hidden area. A suitable sound would be, for example, a voice message such as "I'm here."

This sound should have a volume (e.g., 20 dB or higher) and frequency (20-20 kHz) that is perceptibly noticeable. It is especially important to use a high-pitched sound that is easily perceived. The volume should be louder than other sounds emitted by the system's operating functions and ambient noise, or at the maximum output volume, to ensure it is easily recognizable. The ambient noise level can be determined based on detection values, for example, from a microphone.

Furthermore, the sound used as the notification signal may be of a volume, frequency, and pattern detectable by the sensor. This makes it easier for a third party to pinpoint the user's location using the sensor's detection results as a clue. In other words, the user's location can be tracked using the sensor.

Furthermore, a suitable notification signal for locating a user's location could be, for example, transmitted as light from a light source. This would make it easier for a third party to pinpoint the user's location using the light as a clue. In other words, their location could be found using light.

This light should have a visually recognizable brightness (e.g., 1 cd or more). The brightness should be brighter than the surrounding environment, or set to the maximum output brightness, to make it easier to perceive than the surrounding environment. The brightness of the surrounding environment can be determined based on detection values from, for example, an illuminance sensor.

Furthermore, a suitable notification signal for identifying the user's location would be, for example, a radio wave with a strength that can reach within a predetermined range (e.g., a radius of 30 cm or 5 m) centered on the location of System 1. This makes it easier for a third party to identify the user's location from the outside using the radio wave as a clue. In other words, the user's location can be tracked using radio waves. That is, it becomes possible to know when the user is near the search range where the radio waves can reach.

The radio waves used may have a strength, frequency, and pattern detectable by a receiver such as an antenna. The level of transmission may vary depending on the frequency. For example, a beacon signal with a specified field strength (e.g., 40 dBm or higher, or a specified RSSI (Received Signal Strength Indicator)) should be used. This allows it to be used as a rescue beacon. To transmit the beacon after receiving a disaster warning, a profile such as BLE (Bluetooth® Low Energy) should be used. This profile may be a standard profile or a custom profile. A weak radio wave may be used as the beacon.

Furthermore, a suitable notification signal for locating a user's location could be, for example, transmitted as vibrations of a predetermined pattern. This would make it easier for a third party to pinpoint the user's location using the vibrations as a clue. In other words, the user's location can be found using vibrations.

The notification signal should ideally include user identification information and biometric data. The notification signal should be transmitted in a mode that incorporates this identification and biometric information. Including identification information in the notification signal allows for identification of the sender. Biometric data should be acquired from a biosensor. This biosensor should be acquired via communication using a predetermined wireless communication standard.

The biosensors should ideally be attached to items that users touch or wear on a daily basis. For example, biosensors integrated into wearable devices such as smartwatches or smart glasses are suitable.

The biometric information should include heart rate, body temperature, blood pressure, respiratory status, and other operational status, which can be identified based on the output of biosensors. Respiratory status can be detected, for example, by detecting the presence or absence of breathing and respiratory rate from the displacement of the user's chest using a microwave Doppler sensor, microwave radar sensor, or bio-detection radar. Operational status can be detected, for example, by detecting vibration sounds, proximity status, and acceleration using a vibration microphone, capacitive proximity sensor, vibration sensor, or acceleration sensor.

Thus, this system makes it easier for third parties to pinpoint the user's location through the notification signal, thereby contributing to the effective rescue of users who have become victims of a disaster. In other words, it makes it easy to locate people by finding distress signals from collapsed buildings during a disaster.

Furthermore, the notification signal should be transmitted indirectly to the outside through another device or a nearby machine (hereinafter simply referred to as "device"). The notification signal may also be transmitted continuously from a paired device registered with an external server. This device can receive commands from the system and transmit the notification signal externally via communication using a predetermined wireless communication standard such as Bluetooth® or via cable. This device can serve as a backup in case the system's battery runs out. In this way, the possibility of a user being stationary can be notified through the other device. The transmission of the notification signal may also be relayed through multiple such other devices.

This separate device may actively transmit the notification signal or passively transmit it by receiving an external energy supply. Furthermore, it is preferable that this device continuously transmits the notification signal regardless of the operating status of the system. Ideally, this device should have a battery with a significantly larger capacity than the system's, and consume less power, allowing it to transmit the notification signal for a longer period than the system. This separate device should also have a longer lifespan than the system (in other words, it should operate for a longer time in idle states or under standard operating conditions), for example, by being equipped with a portable power supply.

Another possible device is a passive tag that operates using external power, meaning it receives power from an external source. For example, it could be activated at a predetermined frequency or receive a response even without external power by emitting a strong radio signal. The system should transfer and write the disaster detection result to the passive tag when the system's detection function determines a disaster has occurred, allowing for timely reference of the result. Suitable passive tags include NFC tags and RFID tags with built-in antennas and modules. Alternatively, the passive tag could function as a reflector, reflecting the notification signal. The passive tag could also be integrated into a sheet (or plate) or sticker-like component used as a smartphone accessory. This allows for easy attachment to the system, such as by simply attaching it.

The system should be capable of transmitting signals externally even without external power supply. External power supply could be, for example, from commercial power or AC power.

The system should operate by receiving power from an external source via energy harvesting. For example, it should receive power from an external energy-harvesting device that generates electricity based on natural energy sources such as vibration, light, heat, wind, or electromagnetic waves. A solar panel that generates electricity from light would be a suitable external device. Alternatively, another external device could be attached to a window, continuously generating electricity from the window's vibrations and storing it in a battery. Furthermore, if the window is broken, it could emit pulsed signals or radio waves.

The system should be a battery-powered device. The system should be configured to charge its internal battery when powered externally, and to operate using the battery's power when external power is unavailable.

Furthermore, the system may have a function to withhold the transmission of notification signals after communicating with other systems carrying the same system within the same area, while the system detects the transmission of notification signals from these systems. This function would involve the systems exchanging parameters such as battery level, notification signal transmission capability, and system location information, determining which system should transmit the notification signal according to predetermined rules, and withholding the transmission of the notification signal if the system is not the target of the transmission. Here, communication with other users' systems should preferably be conducted using a predetermined wireless communication standard.

This approach allows a system to withhold its own notification signal transmission while other systems that are being targeted are transmitting their own signals. This reduces the power consumption of the system in question, while allowing other systems to handle notification signal transmission within the same area. Each user's portable system within the same area can then transmit its notification signal sequentially according to the above rules, enabling long-term notification signal transmission across the entire area. As a result, this contributes to the effective rescue of users within the same area over an extended period.

In this case, the notification function should collect information such as the location information of other systems that have withheld sending the notification signal, and the number of systems that have detected the transmission of the notification signal, and include this information in the notification signal before sending it.

The notification function should be designed to change the notification content of the notification signal to a predetermined format that makes it easier for a third party to understand. In this way, the notification content of the notification signal can be made easier for the user to understand through a change in format.

The method could involve, for example, increasing the output levels of sound, light, radio waves, or vibrations in accordance with the passage of time or the proximity of other devices to the system; modifying patterns (sound frequency and waveform, light flashing, radio wave frequency and waveform, vibration patterns, etc.) to make them more perceptible to humans; or combining these appropriately. The proximity of another device to the system could be determined by whether it becomes capable of communication using a predetermined wireless communication standard (e.g., a pairing-ready state).

Furthermore, the notification function may continuously send notification signals after a disaster has been detected, or it may send them at regular intervals or intermittently. In the latter case, the notification function should be activated at predetermined intervals (e.g., a few milliseconds to a few minutes) to send notification signals. For example, if notification signals are sent continuously or at short intervals of several tens of milliseconds, power consumption will be high. Therefore, it is better to send notification signals at intervals of once per second, or to sleep for a predetermined period of time, such as one minute. This way, the notification function will be in a sleep state when not sending notification signals, resulting in reduced power consumption of the system and enabling notification signals to be sent for a longer period.

The interval at which this notification signal is transmitted should be adjusted based on external communication. For example, the interval for transmitting the notification signal could be shortened upon detection of identification information (ID) from a search device carried by the search team.

Furthermore, the notification function should ideally send a notification signal immediately after a disaster is detected. In this case, if a user is affected by the disaster and unable to move, the system can immediately send a notification signal upon receiving the initial signal, informing the system of the possibility that the user is stranded. A system that immediately emits a beacon upon disaster increases the chances of rescuing users whose safety cannot be guaranteed, such as those trapped in collapsed buildings.

(2) The notification function should be configured to send the notification signal from the time the occurrence of a disaster is determined by the determination function until the system receives a termination command from the user.

In this way, notification signals can be sent from the time a disaster is detected until a termination command is received from the user.

A termination command should be issued, for example, to indicate that rescue is unnecessary because the user is not affected by the disaster, or is able to evacuate on their own. In this way, by intentionally terminating the transmission of the notification signal with a termination command, the user can effectively prevent a third party receiving the signal from taking unnecessary rescue action.

This allows for more effective rescue by third parties when multiple users in the same area are carrying the system, even if each system sends out a notification signal in the event of a disaster. This is achieved by stopping the notification signal transmission from users who do not require rescue. When a user is safe, they can, for example, issue a termination command (such as "You don't need to transmit anymore. I understand. OK"), thereby stopping the notification signal from healthy users. This ensures that only those truly buried continue to transmit signals, while healthy users are required to stop transmitting.

Furthermore, termination commands should ideally be issued through the system's user interface. This allows the user to directly issue termination commands to the system via the user interface. The system can also manually switch whether or not to continue transmitting the notification signal.

In the notification function, if continuous operation is performed before or after a disaster is detected, regardless of the content of the operation, it is appropriate to consider that a termination command has been issued in response to that operation. This operation includes things like adjusting the volume or touching the touch panel. Since users who are able to evacuate themselves and do not require rescue should be able to continuously operate the system even if they are affected by a disaster, using this operation as a termination command allows for a quick termination of the notification signal transmission.

Whether or not continuous operations were performed should be checked within a predetermined period before and after the determination of a disaster (a few seconds to a few minutes, depending on the disaster determination criteria; more specifically, one minute before and after, or one minute before and five or ten minutes after). Whether or not operations were performed before the determination of a disaster should be checked by examining the existence of an operation history for the system in question.

To determine whether an operation was performed after a disaster was detected, it is advisable to check after a predetermined waiting period (several seconds to several minutes, depending on the disaster detection criteria). For example, since earthquake early warnings are typically sent a predetermined period (several seconds to tens of seconds) before an earthquake occurs, it is advisable to check whether an operation was performed after a corresponding gap period following the detection of a disaster based on this warning. For instance, one could decide not to check the operation history within three minutes of receiving the earthquake early warning, and then check the operation history for ten minutes after three minutes have passed. Furthermore, to determine whether an operation was performed after a disaster was detected, it is advisable to check whether inputs for events occurring in other applications or background services running prior to the disaster were made after the disaster was detected.

Termination commands, which are issued via the user interface, should ideally be performed by, for example, operating physical switches or buttons, or by tapping termination command buttons or switches displayed on the screen using a touch panel. These operations may also be a combination of multiple operations performed sequentially through several steps. This ensures that even if an operation for issuing a termination command is accidentally initiated, the termination command will not ultimately be issued.

Furthermore, the termination command should be issued from another device capable of communicating with the system, accompanied by user or system identification information. This identification information should include the date and time (hours and minutes) the termination command was issued. If the system has a phone number assigned to it, this phone number should also be included in the identification information. Upon receiving the termination command, the system determines, based on the accompanying identification information, that the command originated from its user. In this way, even if a user has evacuated, leaving the system behind—that is, has left the disaster site—they can still terminate the transmission of the alert signal via a command from another device. Even if a user has fled but left their smartphone behind and cannot stop the transmission of the alert signal, if the smartphone is still functional, they can still stop it, for example, by sending an SMS (Short Message Service) based on the phone number assigned to the system, even if the device itself is different. Even users who do not have control of the system, for example, those who left it at home while evacuating, can remotely terminate the transmission of the alert signal.

In this system, after a disaster has been detected by the detection function, it would be beneficial to notify the user that a termination command has been received until a termination command is issued. This notification could be, for example, an audio or display message indicating that a termination command has been received. The notification could include a message stating that a termination command has been received, or a message stating that a termination command should be issued to stop sending the notification signal. In this way, the system can notify the user that a termination command has been received via message. For example, the message could be an audio message such as "Please stop."

Furthermore, the termination command should be a predetermined incoming call based on the telephone number assigned to the system. This predetermined incoming call could be a call following a predetermined pattern (e.g., incoming calls over a predetermined period) or a short message service (SMS) message sent via the telephone number.

Furthermore, the notification function should, upon receiving a termination command, send a notification signal containing time information (for example, the time the user stopped the device), and then terminate the transmission of this notification signal.

(3) The notification function should ideally send the notification signal if it has not received a non-notification command from the user to the system during the predetermined grace period after the occurrence of a disaster has been determined by the determination function.

This approach allows for the transmission of a notification signal only if no notification command is received during the grace period after a disaster is detected. In other words, the transmission of the notification signal can be delayed for a grace period after the disaster is detected. For example, the notification signal can be automatically transmitted after a few minutes have elapsed.

Non-notification commands should be used, for example, to indicate that a user is not affected by the disaster, or is able to evacuate on their own, thus indicating that rescue is unnecessary. In this way, users can effectively prevent third parties from taking unnecessary rescue actions by intentionally sending non-notification signals. This prevents healthy users from sending notification signals.

This allows third parties to more effectively rescue affected users by preventing the transmission of notification signals from the systems of users who do not require rescue, even when multiple users in the same area are carrying the system.

Furthermore, non-notification commands should ideally be issued through the system's user interface. This allows users to directly issue non-notification commands to the system via the user interface.

Non-notification commands, which are issued via the user interface, can be performed, for example, by tapping a button for non-notification commands displayed on the screen using a touch panel. This operation may also be a combination of multiple operations performed sequentially through several steps. In this way, even if an operation for a termination command is accidentally initiated, such as by mistake, the non-notification command will ultimately not be issued.

Furthermore, non-notification commands should be issued from other devices capable of communicating with the system, accompanied by user or system identification information. This identification information should include the date and time (hours and minutes) of the termination command. If the system has a telephone number assigned, this telephone number may be used as the identification information. Alternatively, the user's resident registration number may be used. Upon receiving a non-notification command, the system determines, based on the accompanying identification information, that the command originated from its user. In this way, even if a user evacuates, leaving the system behind—that is, has left the disaster site—the system can prevent notification signals from being sent via commands from other devices.

The "grace period" before sending a notification signal should be longer than the estimated time required for users to recognize that they are not affected by the disaster, or that they are able to evacuate on their own after the disaster occurs. In this way, if no notification command is issued beyond the grace period, the system can use a notification signal to indicate the possibility that the user is affected by the disaster and unable to move.

(4) It is preferable to have a notification function that provides a notification to the user in advance of the transmission of the notification signal before the grace period expires.

In this way, a warning notification can be sent to the user before the grace period expires, informing them that a notification signal will be transmitted.

This advance notification allows the user to be informed in advance that a notification signal will be sent. Therefore, if the user receives the advance notification and realizes that sending a notification signal is unnecessary, they can issue a non-notification command to the system to prevent the notification signal from being sent.

The notification function should, for example, notify the user that a notification signal will be sent via voice or display message. The notification content could include a message stating that a notification signal will be sent, a message stating that the notification should be stopped by a non-notification command before the grace period expires, or a countdown timer until the notification signal is sent. In this way, the user can be notified of the notification signal's transmission via message. The message could be, for example, a voice message such as "Please stop."

(5) The notification function should, within the grace period, change the content of the notification to a form that is easily understood by the user.

In this way, within the grace period, the content of the advance notice can be modified to a format that is easier for users to understand. This makes the advance notice easier for users to understand through this change in format.

The methods defined to make information easily understandable to users include, for example, increasing the volume of audio over time, increasing the brightness of the display over time, making messages stronger over time, and combining these appropriately. More specifically, the volume should initially be at a normal level, like listening to music, not quite an alarm, then increase to a very loud alarm level after about 10 minutes, and then reach maximum volume after about an hour. Furthermore, the warning notification should increase to maximum volume when it is time for rescue to arrive.

(6) When the determination function determines that a disaster has occurred, it is preferable to have a transmission function that sends safety information to a designated server indicating that the user is in a stationary state, and thereafter, when the system receives a termination command from the user, sends safety information to the server indicating that the user has left the stationary state.

In this way, when a disaster is detected, safety information indicating that the user is in a stationary state is sent to the server. Subsequently, upon receiving a termination command from the user, safety information indicating that the user has left the stationary state is sent to the server.

Safety information should be sent to the server along with the system or user's identification information. The identification information should include the date and time (hours and minutes) when the termination command was issued. Furthermore, the server should be able to store the date and time the disaster was determined, the content of the safety information, and the system or user that sent it, in association with each other. This would allow the server to verify the safety of each user based on the stored safety information. This server functionality may be provided within the system itself.

Furthermore, the safety information should include location information within the system. This allows the server to determine the system's location. This location information should ideally be the current location (longitude and latitude) determined based on GPS signals received from GPS (Global Positioning System) satellites.

Furthermore, it would be beneficial to include the user's biometric information in the safety status information. This would allow the server to verify the user's biometric information based on the stored safety status information. Based on this information, it would then be possible to confirm the user's safety.

Furthermore, the safety information should include confirmation that the user is alive. This survival status could be determined by a device embedded in accessories, bands, earphones, headphones, wireless earphones, headsets, hats, rings, earmuffs, underwear, or diapers that are in contact with the user's body, detecting changes in capacitance. This device only needs to be in contact with the user's body and could even be part of a medical device such as a pulse oximeter. By attaching the above-mentioned devices to all items worn and touched in daily life, biometric information can be read from them and transmitted to the system.

Furthermore, the transmission function may involve dialing the telephone number for the disaster message service and using the telephone number assigned to the system as a key to send voice messages about the user's safety to a server for voice storage. This allows for the transmission of safety information in conjunction with the disaster message service.

(7) The transmission function should transmit the safety information via a network designated for use in the event of a disaster.

In this way, safety information can be transmitted through a network designated for use during disasters.

When selecting a network for use during a disaster, it is advisable to choose one that is less prone to communication failures. Specifically, it should be a network that is less susceptible to damage during a disaster and configured to prioritize connections during such events. This increases the likelihood of safety information reaching the server. In this case, automatic connection to the disaster-response network is also possible. Such a network may be built within a local area network.

A network configured to prioritize connectivity during a disaster should connect to wireless relay stations (such as wireless LAN routers) that are normally provided as a paid connection service but are configured to be made free of charge during emergencies. This increases the likelihood of connectivity even if trapped somewhere, provided the on-site relay station (such as a local LAN) is operational, provided the relay station is operational, provided the smartphone is equipped with a system. Whether or not a relay station 110 is made free of charge during an emergency can be determined by checking whether its SSID has changed to the emergency SSID (the unified disaster SSID "00000JAPAN (Five Zero Japan)").

(8) The transmission function should transmit the safety information via a network that has been continuously communicating since before the determination of a disaster by the determination function.

This method allows for the transmission of safety information via a network that has maintained continuous communication even before the disaster was detected. This increases the likelihood of the safety information reaching the server.

(9) It is preferable to have a switching function that switches the operating mode of the system to a power-saving mode that suppresses power consumption when the occurrence of a disaster is determined by the aforementioned determination function.

This approach allows the system to switch to power-saving mode (so-called battery-saving mode) when a disaster is detected. This reduces the system's power consumption during a disaster, allowing it to transmit notification signals for a longer period.

The power-saving mode should, for example, suppress the operation of the entire system 1, increase the communication interval with the outside world compared to the normal operating mode, increase the time interval for sending notification signals compared to the normal operating mode, and include a sleep period during which no notification signals are sent. For example, it would be good to send a notification signal for one second, followed by a one-minute sleep period.

The switching function should ideally switch from power-saving mode to normal operating mode upon receiving the aforementioned termination command or non-notification command. This allows the system to return to normal operating mode upon receiving the termination command or non-notification command. Furthermore, the switching function should ideally switch to the power-saving mode implemented in the operating system of system 1 via, for example, an API (Application Programming Interface).

(10) It is preferable to have a switching function that switches the operating mode of the system to a power-saving mode that suppresses power consumption while a notification signal is being transmitted by the notification function.

This method allows the operating mode to be switched to power-saving mode while the notification signal is being transmitted. This reduces the power consumption of the system when transmitting the notification signal, allowing the notification signal to be transmitted for a longer period of time.

The switching function should ideally switch from power-saving mode to normal operation mode upon receiving the aforementioned termination command or non-notification command. This allows the system to return to normal operation mode upon receiving a termination command or non-notification command.

(11) The aforementioned determination function should determine the occurrence of a disaster in the vicinity of the system based on a disaster notification from a disaster prevention application that notifies users of the occurrence of a disaster in the vicinity of the system.

In this way, it is possible to determine the occurrence of a disaster in the vicinity of the system based on notifications from the disaster prevention app.

As a disaster prevention app, it would be suitable to use a system app like those provided by Yahoo! (registered trademark), which broadcasts information such as earthquake early warnings as a disaster alert. This information should ideally be delivered via push notifications detectable by System 1. Furthermore, the disaster prevention app may be launched via communication with an NFC tag attached to a car mount or similar device.

Notifications from the disaster prevention app should ideally be received either directly from the app or indirectly via another relay app that can communicate with it.

Here, it is preferable to configure the system to receive notifications from the disaster prevention app via at least one of the following methods: API notification, callback notification, external communication notification, sound notification, or notification via another relay app that can communicate with the disaster prevention app. It may also be configured to receive notifications via another device that can communicate with the system.

Disaster notifications from disaster prevention apps should be based on earthquake early warnings handled within the app. In this case, the detection function detects the earthquake early warning notification executed by the system's operating system within the app and determines the occurrence of a disaster based on this notification. Alternatively, the detection function could detect a specific control signal on the mobile phone itself within the app and determine the occurrence of a disaster based on the detection of this control signal. Suitable operating systems include, for example, Windows®, macOS®, Android®, and iOS®. Disaster prevention apps should be configured to be downloaded and automatically installed from an application repository that distributes programs and data together.

It would be beneficial to detect earthquake early warnings by sound. The system should include a function to recognize the sound of an earthquake early warning. This function could be implemented, for example, by identifying whether a sound detected by a microphone is the earthquake early warning sound based on its difference from other sounds. This would allow for disaster detection based on earthquake early warnings even in cases where direct detection of earthquake early warnings is not possible due to security or update issues in the operating system. To recognize the sound of an earthquake early warning, it would be beneficial to include a function to distinguish between the high-pitched ringing sound of an earthquake early warning and other similar sounds.

Furthermore, it would be beneficial to have the earthquake early warning notification detected by another device capable of communicating with the system, and for the system to receive the result and determine if a disaster has occurred. The earthquake early warning should be detected when it is sent to the smartphone as part of the system. The earthquake early warning should be received via ETWS (Electronic Telecommunications Warning System) when it is sent to the system.

Furthermore, if multiple types of disaster prevention apps are installed on the system, the detection function should determine the occurrence of a disaster in the system's vicinity when a certain number (e.g., a majority) of the disaster prevention apps have notified the system of a disaster occurring in the same region. Here, since there are various types of disaster prevention apps, the system would consider the presence of notifications from multiple apps, or from a majority of the registered apps, as important information. It would also be possible to classify a situation as a major disaster when notifications arrive from several disaster prevention apps. In this way, the system can more reliably determine the occurrence of a disaster based on notifications from multiple types of disaster prevention apps.

Furthermore, if multiple types of disaster prevention apps are installed on the system, the detection function should determine the occurrence of a disaster in the vicinity of the system based on whether the disaster notification from each app has a high degree of spatial proximity and/or temporal proximity. Notifications from multiple disaster prevention apps will be considered important information if they arrive within a predetermined time frame or within a predetermined area. For spatial proximity, high spatial proximity can be determined if the disaster locations included in the notifications from each app overlap or are within a certain range. For temporal proximity, high temporal proximity can be determined if the notifications from each app arrive within a predetermined period (e.g., within 5 minutes, or within 1 hour). In this way, the system can determine the occurrence of a disaster with greater certainty based on at least one of spatial and temporal proximity.

Furthermore, if the system has both a disaster prevention app specialized in notifying of disasters within a specific region and a disaster prevention app suitable for notifying of disasters across multiple regions, it is advisable to prioritize notifications from the former app when determining the occurrence of a disaster. If push notifications of a disaster occur from both the local disaster prevention app (based on current location information) and the nationwide disaster prevention app, the accuracy is considered very high. For example, if the former app notifies that a disaster should have occurred (e.g., an earthquake of magnitude 5), while the latter app notifies that a disaster should not have occurred (e.g., an earthquake of magnitude 3), the former should be prioritized when determining the occurrence of a disaster. This priority order for each disaster prevention app could be determined by prioritizing the local app based on current location information, or by the accuracy level and other parameters defined for each app. It would also be beneficial to allow users to arbitrarily set the priority order.

(12) It is preferable to have a function that prompts the user to install the disaster prevention application on the system if the application is not already installed.

This method allows users to be prompted to install the disaster prevention app on their system if it is not already installed.

The disaster prevention app that users are encouraged to install should be an app that notifies them of disasters occurring in the system's location area. For example, if the system is located in Aichi Prefecture or Nagoya City, it should be a regionally limited app that notifies users of disasters occurring in Aichi Prefecture or Nagoya City. Whether or not the user is within the system's location area can be determined by the signal received by the GPS receiver.

The timing for prompting installation should be when the system moves and its location changes, or when the installation of the disaster prevention app corresponding to the new location is no longer confirmed due to the system's relocation. This allows for prompting the installation of the disaster prevention app for the new region as the location changes. For example, if a user located in Aichi Prefecture takes System 1 with them on a business trip to Tokyo, they can be prompted to install the disaster prevention app for Tokyo.

Furthermore, the timing for prompting the installation of the disaster prevention app could be the same as the installation of the programs (or software) necessary to implement the various functions mentioned above. This ensures that the app is installed to guarantee the functionality of these features.

To encourage users to install disaster prevention apps, it's effective to use messages, such as voice or visual prompts. This allows you to prompt users to install the app through messaging. It's also good practice to clearly display a link to the download site for the app along with the message. For example, using an interactive wizard function to guide users through the app installation process, you could clearly display a link to the download site (Google Play Store, App Store, etc.) to encourage the installation of the Yahoo! (registered trademark) disaster prevention app. After installation, you could then display links to download other disaster prevention apps, thereby encouraging users to install each app.

The program of the present invention may be a program for realizing the functions of any of the systems described in (1) to (12) above.

According to the present invention, it is possible to provide a system with superior characteristics compared to conventional systems. For example, it is possible to provide a system that makes it easier for a third party to identify the location where a user is parked, thereby contributing to the effective rescue of a user who has become a disaster victim.

The effects of the present invention are not limited thereto. Effects derived from the components disclosed in this specification and the drawings are also disclosed, and the applicant intends to obtain rights to such components through divisional applications, amendments, etc. For example, descriptions in this specification that state "can do..." are intended to clearly indicate the effects that can be achieved. Furthermore, there are components that demonstrate effects even without such descriptions. Moreover, there are effects that can be understood through the components even without such descriptions.

Block diagram illustrating the system outline of one embodiment of the present invention. A flowchart illustrating the processing procedure for disaster notification by the system.

The embodiments of the present invention will be described below with reference to the drawings. These drawings are used to illustrate the technical features that may be adopted in the present invention. The configuration and shape of the described apparatus are merely illustrative examples, and the present invention is not to be construed as being limited thereto. Various changes, modifications, and improvements may be made based on the knowledge of those skilled in the art, without departing from the scope of the present invention.

[Overall structure]
As shown in Figure 1, System 1 according to an embodiment of the present invention comprises a user interface (UI) 10, a communication unit 20, a GPS unit 30, a storage unit 40, a sensor group 50, and a control unit 60.

The user interface 10 handles information exchange with the user. The user interface 10 includes a display 11 for displaying images, an input unit 13 for receiving user input, an audio input/output unit 15 equipped with an audio processing circuit, a vibrator 17 for generating vibrations, and multiple operation buttons 19, each associated with a predetermined input operation. The audio input/output unit 15 includes a speaker 15a and a microphone 15b. The input unit 13 is a touch panel composed of capacitive touch sensors stacked on the display area of the display 11, which detect the user's touch position.

The communication unit 20 communicates with external devices. In this embodiment, the communication unit 20 includes a mobile communication module 21 that controls communication in accordance with mobile communication standards, a wireless communication module 23 that controls communication in accordance with wireless LAN (Local Area Network) communication standards, and a short-range communication module 25 that controls communication in accordance with short-range communication standards. The mobile communication module 21 controls communication in accordance with standards such as LTE (Long Term Evolution), 4G, and 5G. The wireless communication module 23 controls communication with external devices using, for example, Wi-Fi (registered trademark) or other wireless LAN communication standards. The short-range communication module 25 controls communication with, for example, smartphones, tablet computers, and other communication terminals using short-range communication standards such as Bluetooth (registered trademark) and NFC (Near-field communication). System 1 contains these modules.

The GPS unit 30 acquires location information regarding the current location of System 1. The location of System 1 is considered equivalent to the location of the user carrying System 1. The GPS unit 30 acquires location information (latitude and longitude information) of System 1 based, for example, on signals from a GPS (Global Positioning System). The GPS unit 30 may also be configured to acquire location information based on signals from 4G, 5G communication, or other relay stations 110.

The memory unit 40 stores data. For example, the memory unit 40 stores programs for the control unit 60 to perform various controls. The control unit 60 reads and executes programs from the memory unit 40.

The storage unit 40 may be an auxiliary storage device implemented using various storage media, such as flash memory (e.g., eMMC, SSD). The storage unit 40 may also be implemented using various storage media, such as optical storage media, magnetic storage media, and semiconductor storage media.

The sensor group 50 comprises various sensors. For example, the sensor group 50 includes an accelerometer 51, a gyroscope 53, a biosensor 55, and an illuminance sensor 57. The accelerometer 51 is, for example, a three-axis accelerometer that detects the forward/backward, left/right, and up/down acceleration of the system 1. The gyroscope 53 is a sensor that detects the tilt of the system 1. The biosensor 55 is, for example, a sensor that detects biological information such as heart rate, body temperature, and blood pressure. The biosensor 55 may be incorporated into accessories, bands, earphones, headphones, wireless earphones, headsets, hats, rings, earmuffs, underwear, or diapers that are in contact with the user's body. This biosensor 55 only needs to be in contact with the user's body and may even be part of a medical device such as a pulse oximeter.

Furthermore, the biosensor 55 may be a sensor capable of detecting the displacement of the user's chest as the presence or absence of breathing and the respiratory rate, such as a microwave Doppler sensor, microwave radar sensor, or bio-detection radar. This would allow the user's breathing status to be detected as biometric information. Based on the detected breathing information, it would also be possible to determine whether or not it is the user's breathing (i.e., the breathing of a survivor). This breathing status should ideally be detected by equipment used for searching for people under rubble. Specifically, this could involve using a drone or a snake-like robot to listen to the voices of victims under the rubble. The drone itself may be battery-powered or powered by external power supplied via cables, etc. The voices of victims should ideally be heard by mounting multiple chocolate-shaped microphones on a scope camera.

The control unit 60 controls each part of the system 1. The control unit 60 is, for example, a computer including a processor and memory.

System 1 only needs to consist of at least a portion of a portable device. Alternatively, the entire system may be configured as a portable device. System 1 may be configured as a dedicated terminal, or some of its functions may be integrated into another device. In this embodiment, System 1 comprises the above-described components and is a portable smartphone. System 1 has a SIM card in its mobile communication module 21, and based on the user identification information stored therein, the user's phone number is assigned to System 1. Furthermore, System 1 may be equipped with a mechanism (so-called eSIM) that achieves the same functionality as a SIM card by writing user information to a chip built into System 1.

System 1 may consist of a single unit or multiple units. System 1 may consist of a single enclosure or multiple enclosures.

[Functions of the control unit 60]
The following describes the various functions of the control unit 60. Each function is realized by various processes that the control unit 60 executes according to the program stored in the storage unit 40.

(1) Judgment function 1
The control unit 60 has a determination function that determines the occurrence of a disaster in the vicinity of the system 1 according to the signal reception status.

The determination function determines the occurrence of a disaster based on the signal reception status from the communication unit 20 and the sensor group 50. The signal reception status should include, for example, at least one of the following: whether or not an emergency notification signal issued during a disaster has been received; whether or not the communication status with specific or multiple relay stations 110, such as mobile communication base stations or wireless LAN routers, has changed; or detection values from various sensors (e.g., acceleration sensor 51) for detecting displacement associated with a disaster. Here, for example, the system should determine the occurrence of a disaster when it receives only an advertisement signal, an emergency notification signal that serves as a warning during a disaster has been received, communication with specific or multiple relay stations 110 has been interrupted or become possible due to the disaster, or various sensors have output detection values corresponding to the occurrence of a disaster. In this way, the occurrence of a disaster can be determined based on the signal reception status.

The emergency notification signal mentioned above should be a signal broadcast during a disaster, similar to a radio broadcast. Specifically, for example, an earthquake early warning via ETWS (Earthquake and Tsunami Warning System or Service) would be suitable. Earthquake early warnings are effective because they are highly timely. In this way, the occurrence of a disaster can be determined by utilizing a system that widely notifies the occurrence of a disaster. System 1 may directly receive incoming emergency notification signals, or it may receive them indirectly through another device. This other device could be, for example, a radio receiver capable of detecting earthquake early warnings or emergency alert broadcasts from an FM radio station. Whether or not it is an earthquake early warning can be determined based on the command ID in the System Information Block (SIB). Specifically, an earthquake early warning can be determined to be an earthquake early warning if it uses SIB10 (System Information Block Type 10), which is used for the first notification in the earthquake early warning system (to notify only the details of the disaster, such as earthquakes and tsunamis, within a short time after the event), or SIB11 (System Information Block Type 11), which is used for the second notification (to notify supplementary information such as seismic intensity and epicenter).

Furthermore, the "sensor for detecting displacement due to disasters" should have a structure capable of detecting impacts and transmitting the detected value to System 1. For example, it could be attached to a structure such as a window, and the detected value due to vibration could be transmitted to System 1. Here, System 1 determines whether the detected value from the sensor corresponds to vibrations severe enough to cause damage or breakage to the structure due to the disaster. This sensor should be built into a module that generates electricity in response to vibrations and uses the generated power to transmit the detected value as a pulse wave or similar. This power should be stored in an energy storage device such as a battery or capacitor.

The "disaster occurrence" determined by the detection function should be defined as a disaster of a magnitude that could cause users to be affected and unable to move, such as a major earthquake or fire. "Being affected and unable to move" could refer to situations where users are trapped or immobilized due to the collapse or damage of buildings, natural objects, etc. For example, a disaster of a magnitude that could cause users to be affected and unable to move should be defined as at least one of the following: the scale of the disaster notified by the emergency alert signal exceeds a certain magnitude; communication with a relay station that may experience communication disruption in the event of a disaster exceeding a certain magnitude is interrupted; communication with a predetermined number of relay stations in the vicinity is interrupted; the communication status with a specific relay station changes in conjunction with the occurrence of a disaster; or a large displacement is detected around System 1 by a "disaster-related displacement detection sensor." However, the system is not limited to these examples; it can also receive external information that indicates a situation requiring rescue, or a situation that is considered to potentially require rescue, and define this as a disaster occurrence. In this way, it is possible to determine the occurrence of a disaster of a magnitude that could cause users to be affected and unable to move.

Regarding the above situation, "communication with a specified number of relay stations in the surrounding area is interrupted" should be interpreted as, for example, a situation where communication with multiple base stations, which was normally possible, is suddenly interrupted due to malfunction or damage to all or more base stations. If communication with multiple base stations is suddenly interrupted, it is highly likely that communication, such as phone calls, becomes impossible in many places. Such widespread occurrences suggest the occurrence of a disaster, such as an earthquake. Regarding the above situation, "communication conditions are changing in conjunction with the disaster" should be interpreted as a relay station, which normally provides paid connection services but is set to be made free of charge during emergencies, being made free of charge.

As described above, in this embodiment, the system receives information indicating that a situation requiring rescue, or a situation potentially requiring rescue, has occurred, and determines that this constitutes a disaster. There are various patterns for this determination, such as receiving an earthquake early warning, a complete loss of communication with base stations, malfunctioning wireless communication, or receiving a push notification from an app (disaster prevention app).

The "disaster occurrence" determined by the detection function is determined based on the signal reception status. It may refer to the actual situation where a disaster has occurred, or it may refer to the situation where secondary disasters such as building collapse or fires resulting from the initial disaster have occurred. Furthermore, the "disaster occurrence" should also determine the level of the disaster.

(2) Notification function 1
The control unit 60 has a notification function that, when the determination function determines that a disaster has occurred, sends a notification signal to the outside of the system 1 to notify the possibility that a user is stationary near the location of the system 1. In this way, a notification signal can be sent in response to the occurrence of a disaster.

The notification signal should be capable of providing a notification suitable for identifying the user's location. This would make it easier to pinpoint the user's location from the outside.

A suitable notification signal for locating a user's position would be a distress signal that, upon detection, aids in the search for the user. This signal should also be useful for identifying the location of a user carrying System 1 who is stranded due to a disaster. For example, if a disaster victim is trapped inside a collapsed building such as their home, the signal should be able to reach roads or other areas surrounding the building. This allows for the detection of the approximate location of the buried person, whether a person is buried, or whether they are trapped in an elevator or similar structure, based on the notification signal.

A suitable notification signal for identifying a user's location should be one that can be received directly without going through a communication network. For example, a signal that can be received near System 1, or a signal that a person can directly perceive near System 1, would be ideal.

Furthermore, in cases where rescue is needed for a user affected by a disaster, there is a high probability that network connectivity will be disrupted around the user's portable system 1. In addition, beyond the user's immediate vicinity, the network may be disrupted or limited over a relatively wide area due to damage or malfunction to, for example, mobile phone base stations and telephone exchanges. Therefore, signals that can be received directly without going through the communication network are preferable for locating users. For example, signals that can be received near the location of system 1 are preferable. Also, signals that can be directly perceived by a person near the location of system 1 are preferable.

A suitable notification signal for locating the user's location would be, for example, a sound transmitted from speaker 15a that can reach within a predetermined range (e.g., a radius of 5 or 10 meters) centered on the location of system 1, at a predetermined signal level or higher. This makes it easier for a third party to locate the user using sound as a clue, as they can rely on any sound heard from within the surrounding area to search for the user. In other words, their location can be found by sound. A suitable specific sound would be, for example, a voice message such as "I'm here."

The sound should have a volume (e.g., 20 dB or higher) and frequency (20-20 kHz) that is perceptibly recognizable by sound. It is especially desirable to use a high-pitched sound that is easily noticed by sound. The volume should be higher than the functional sounds and ambient sounds emitted by other functions operating in System 1, or at the maximum output volume, to ensure it is easily recognizable. The ambient noise level can be determined based on detection values from, for example, microphone 15b.

Furthermore, the sound used as the notification signal may be of a volume, frequency, or pattern detectable by the sensor. This makes it easier for a third party to pinpoint the user's location using the sensor's detection results as a clue. In other words, the sensor can be used to locate the user.

Furthermore, a suitable notification signal for locating the user's location could be transmitted as light from a light source (e.g., display 11, LEDs, or lamps). This would make it easier for a third party to locate the user using the light as a clue. In other words, the user's location can be found using light.

This light should have a visually recognizable brightness (e.g., 1 cd or more). The brightness should be brighter than the surrounding environment, or set to the maximum output brightness, to make it easier to perceive than the environment surrounding System 1. The brightness of the surrounding environment can be determined based on detection values from, for example, an illuminance sensor 57.

Furthermore, a suitable notification signal for identifying the user's location would be, for example, a radio wave with a strength that can reach within a predetermined range (e.g., a radius of 30 cm or 5 m) centered on the location of System 1. This makes it easier for a third party to identify the user's location from the outside using the radio wave as a clue. In other words, the user's location can be tracked using radio waves. That is, it becomes possible to know when the user is near the search range where the radio waves can reach.

The radio waves used may have a strength, frequency, and pattern detectable by a receiver such as an antenna. The level of transmission may vary depending on the frequency. For example, a beacon signal with a specified field strength (e.g., 40 dBm or higher, or a specified RSSI (Received Signal Strength Indicator)) should be used. This allows it to be used as a rescue beacon. To transmit the beacon after receiving a disaster warning, a profile such as BLE (Bluetooth® Low Energy) should be used. This profile may be a standard profile or a custom profile. A weak radio wave may be used as the beacon.

Furthermore, a suitable notification signal for locating the user's location could be, for example, transmitted as vibrations of a predetermined pattern by the vibrator 17. This would make it easier for a third party to locate the user using the vibrations as a clue. In other words, the user's location can be found using vibrations.

Furthermore, the notification signal should be transmitted indirectly to the outside through another device or a nearby machine (hereinafter simply referred to as "device"). The notification signal may also be transmitted continuously from a paired device registered with an external server. This device can receive commands from the system and transmit the notification signal externally via communication using a predetermined wireless communication standard such as Bluetooth® or via cable. This device can serve as a backup in case the battery of system 1 runs out. In this way, the possibility of a user being stationary can be notified through the other device. The transmission of the notification signal may also be relayed through multiple such other devices.

This separate device may actively transmit the notification signal or passively transmit it by receiving an external energy supply. Furthermore, it is preferable that this device continuously transmits the notification signal regardless of the operating status of System 1. Ideally, this device should have a battery with a significantly larger capacity than that of System 1, and consume less power, allowing it to transmit the notification signal for a longer period than System 1. This separate device should also have a longer lifespan than System 1 (in other words, it should continue to operate for a longer time in idle states or under standard operating conditions), for example, by being equipped with a portable power supply.

Alternatively, a passive tag powered by an external source could be used as another device. For example, a passive tag could be activated at a predetermined frequency or receive a response even without external power by emitting a strong radio signal. System 1, when a disaster is detected by its detection function, should transfer and write the detection result to the passive tag, allowing for timely reference of the result. The passive tag could be an NFC tag or RFID tag with a built-in antenna and module. Alternatively, the passive tag could be a reflector type that functions as a reflector to reflect the notification signal. The passive tag could also be integrated into a sheet (or plate) or sticker-like component used as a smartphone accessory. This allows for easy attachment, such as by sticking it to System 1 or attaching it to a smartphone case.

The notification function should be designed to change the notification content of the notification signal to a predetermined format that makes it easier for a third party to understand. In this way, the notification content of the notification signal can be made easier for the user to understand through a change in format.

The implementation could involve, for example, increasing the output levels of sound, light, radio waves, or vibrations in accordance with the passage of time or the proximity of another device to System 1; modifying patterns (such as sound frequency and waveform, light flashing, radio wave frequency and waveform, and vibration patterns) to make them more perceptible to humans; or combining these appropriately. The proximity of another device to System 1 could be determined by whether it becomes possible to communicate using a predetermined wireless communication standard (e.g., a state where pairing is possible).

Furthermore, the notification function may continuously transmit notification signals after a disaster has been detected, or it may transmit them at regular intervals or intermittently. In the latter case, the notification function should be activated and transmit notification signals at predetermined intervals (e.g., a few milliseconds to a few minutes). For example, if notification signals are transmitted continuously or at short intervals of several tens of milliseconds, power consumption will be high. Therefore, it is better to transmit notifications at intervals of once per second, or to sleep for a predetermined period of time, such as one minute. This way, the notification function will be in a sleep state when not transmitting notification signals, resulting in reduced power consumption of System 1 and enabling the transmission of notification signals for a longer period. The interval at which these notification signals are transmitted should be changed through communication with an external source. For example, the interval at which notification signals are transmitted could be shortened upon detection of identification information (ID) from a search device carried by a search team.

Furthermore, the notification function should ideally send a notification signal immediately after a disaster is detected. This allows for immediate notification of the possibility of a user being stranded, even if the user is affected by the disaster and unable to move. A system that immediately emits a beacon upon disaster increases the chances of rescuing users whose safety is compromised, such as those trapped in collapsed buildings.

The notification signal should ideally include user identification information and biometric information. The notification signal should be transmitted in a mode that incorporates this identification and biometric information. Including identification information in the notification signal allows for identification of the sender. Biometric information should be acquired from a biosensor 55. This biosensor 55 should be acquired via communication using a predetermined wireless communication standard.

The biosensor 55 should be attached to something that the user touches or wears on a daily basis. For example, the biosensor 55 could be one built into a wearable device such as a smartwatch or smart glasses. The wearable device could be a smartwatch, something sewn into clothing, a ring, or a bracelet.

The biometric information should include heart rate, body temperature, blood pressure, respiratory status, and other operational status, which can be identified based on the output of the biosensor 55. Respiratory status can be detected, for example, by detecting the presence or absence of breathing and respiratory rate from the displacement of the user's chest using a microwave Doppler sensor, microwave radar sensor, or bio-detection radar. Operational status can be detected, for example, by detecting vibration sounds, proximity status, and acceleration using a vibration microphone, capacitive proximity sensor, vibration sensor, or acceleration sensor.

The notification signal should include information indicating the battery status in System 1. If the notification signal is a beacon signal, the battery life extension within the beacon frame, which serves as the framework for containing the information, should include this status information.

(3) Notification function 2: Control by termination command The notification function sends out notification signals from the time the occurrence of a disaster is determined by the judgment function until it receives a termination command from the user to system 1.

In this way, notification signals can be sent from the time a disaster is detected until a termination command is received from the user.

A termination command should be issued, for example, to indicate that rescue is unnecessary because the user is not affected by the disaster, or is able to evacuate on their own. In this way, by intentionally terminating the transmission of the notification signal with a termination command, the user can effectively prevent a third party receiving the signal from taking unnecessary rescue action.

This allows for more effective rescue by third parties when multiple users in the same area are carrying System 1, and each System 1 sends out a notification signal in the event of a disaster. By stopping the notification signal transmission from System 1 of users who do not require rescue, the system can be activated. When a user is safe, they can issue a termination command (such as "You don't need to transmit anymore. I understand. OK"), thereby stopping the notification signal from healthy users. This ensures that only those truly buried continue to transmit signals, while healthy users are required to stop transmitting.

Furthermore, termination commands should ideally be issued via the user interface 10 (in this embodiment, the operation input unit 13 and operation buttons 19). This allows the user to directly issue termination commands to the system 1 via the user interface 10. The system can also manually switch whether or not to continue sending the notification signal.

In the notification function, if continuous operation is performed on the user interface 10 before or after a disaster is detected, regardless of the content of the operation, it is preferable to consider that a termination command has been issued in response to that operation. Such operations include adjusting the volume or touching the touch panel. If a user is able to evacuate on their own and does not require rescue, even if affected by a disaster, they should be able to continuously operate the system 1. Therefore, by using this operation as a termination command, the transmission of the notification signal can be stopped as quickly as possible. Furthermore, when the termination command is received, the notification function should send a notification signal including time information (for example, at what time the user stopped using the system) before terminating the transmission of this notification signal.

Whether or not continuous operations were performed should be checked within a predetermined period before and after the determination of a disaster (a few seconds to a few minutes, depending on the disaster determination criteria; more specifically, one minute before and after, or one minute before and five or ten minutes after). Whether or not operations were performed before the determination of a disaster should be checked by examining the existence of an operation history for system 1.

To determine whether an operation was performed after a disaster was detected, it is advisable to check after a predetermined waiting period (several seconds to several minutes, depending on the disaster detection criteria). For example, since earthquake early warnings are typically sent a predetermined period (several seconds to tens of seconds) before an earthquake occurs, it is advisable to check whether an operation was performed after determining the occurrence of a disaster based on this warning, following a corresponding period of inactivity. For instance, one could decide not to check the operation history within three minutes of receiving the earthquake early warning, and then check the operation history for ten minutes after three minutes have passed. Furthermore, since disaster prevention apps, as described later, may send notifications later than the actual occurrence of a disaster, it is advisable to check for the existence of operation history after determining the occurrence of a disaster based on this notification, using a point in time prior to the notification (taking into account the delay) as a baseline. Additionally, whether an operation was performed after a disaster was detected can be checked by examining whether inputs for events occurring in other apps or background services running prior to the disaster were made after the disaster was detected.

The termination command, which is issued via the user interface 10, can be performed, for example, by operating a physical switch or button, or by tapping a termination command button or switch displayed on the display 11 using the touch panel. These operations may be a combination of multiple operations performed sequentially through several steps. This way, even if an operation for issuing a termination command is started by accident, such as by mistake, the termination command will not ultimately be issued.

Furthermore, the termination command should be issued from another device capable of communicating with System 1, accompanied by user or System 1 identification information. This identification information should include the date and time (hours and minutes) the termination command was issued. If System 1 has a phone number assigned to it, this phone number should also be included. Alternatively, the user's resident registration number may be used as identification information. Upon receiving the termination command, System 1 determines, based on the accompanying identification information, that the command originated from the user of System 1. In this way, even if a user has evacuated, leaving System 1 behind—that is, has left the disaster site—the transmission of the alert signal can be terminated via a command from another device. Even if a user has fled but left their smartphone behind and cannot stop the transmission of the alert signal, if the smartphone is still functional, it can be stopped, for example, by an SMS (Short Message Service) based on the phone number assigned to System 1, even if the device itself is different. Even a user who does not have control over System 1, for example, who left it at home while fleeing, can remotely terminate the transmission of the alert signal.

Here, after the disaster has been detected by the detection function, and before the termination command is received, it would be good to notify the user that the termination command has been received. This notification could be, for example, an audio or display message indicating that the termination command has been received. The notification content could be a message stating that the termination command has been received, or a message stating that a termination command should be issued to stop sending the notification signal. In this way, the notification that the termination command has been received can be conveyed through a message. The message could be, for example, an audio message such as "Please stop."

Furthermore, the termination command may be a predetermined incoming call based on the telephone number assigned to System 1. This predetermined incoming call may be an incoming call following a predetermined pattern (e.g., an incoming call over a predetermined period) or a short message service (SMS) message sent via telephone number.

Furthermore, the notification function should, upon receiving a termination command, send a notification signal containing time information (for example, the time the user stopped the device), and then terminate the transmission of this notification signal.

(4) Notification function 3: Control by non-notification command The notification function sends a notification signal if no non-notification command is received from the user to the system 1 during the period from when the occurrence of a disaster is determined by the judgment function until a predetermined grace period has elapsed.

This approach allows for the transmission of a notification signal only if no notification command is received during the grace period after a disaster is detected. In other words, the transmission of the notification signal can be delayed for a grace period after the disaster is detected. For example, the notification signal can be automatically transmitted after a few minutes have elapsed.

Non-notification commands should be used, for example, to indicate that a user is not affected by the disaster, or is able to evacuate on their own, thus indicating that rescue is unnecessary. In this way, users can effectively prevent third parties from taking unnecessary rescue actions by intentionally sending non-notification signals. This prevents healthy users from sending notification signals.

This prevents the transmission of notification signals from System 1 by users who do not require rescue, in situations where multiple users in the same area are each carrying System 1. This allows third parties to more effectively rescue affected users.

Furthermore, non-notification commands should ideally be issued via the user interface 10 (in this embodiment, the operation input unit 13 and operation buttons 19). This allows the user to directly issue non-notification commands to the system 1 via the user interface 10.

Non-notification commands, which are issued via the user interface 10, can be performed, for example, by tapping a non-notification command button displayed on the display 11 using the touch panel. This operation may be a combination of multiple operations performed sequentially through several steps. In this way, even if an operation for a termination command is accidentally initiated, such as by mistake, the non-notification command will ultimately not be issued.

Furthermore, non-notification commands should be issued from other devices capable of communicating with System 1, accompanied by user or System 1 identification information. This identification information should include the date and time (hours and minutes) of the termination command. If System 1 has a telephone number assigned to it, this telephone number may be used as the identification information. Alternatively, the user's resident registration number may be used as the identification information. Upon receiving a non-notification command, System 1 determines, based on the identification information associated with the command, that it originates from the user of System 1. In this way, even if the user has evacuated, leaving System 1 behind—that is, has left the disaster site—it is possible to prevent notification signals from being sent via commands from other devices.

The "grace period" before sending a notification signal should be longer than the estimated time required for users to recognize that they are not affected by the disaster, or that they are able to evacuate on their own after the disaster occurs. In this way, if no notification command is issued beyond the grace period, the system can use a notification signal to indicate the possibility that the user is affected by the disaster and unable to move.

(5) Warning function The control unit 60 has a warning function that provides a warning notification to the user in order to inform them that a notification signal will be sent before the above-mentioned grace period has elapsed.

In this way, a warning notification can be sent to the user before the grace period expires, informing them that a notification signal will be transmitted.

This advance notification allows the user to be informed in advance that a notification signal will be sent. Therefore, if the user receives the advance notification and realizes that sending a notification signal is unnecessary, they can issue a non-notification command to System 1 to prevent the notification signal from being sent.

The notification function should, for example, notify the user that a notification signal will be sent via voice from speaker 15a or a message displayed on display 11. The notification content could include a message stating that a notification signal will be sent, a message instructing the user to stop the notification with a non-notification command before the grace period expires, or a countdown timer until the notification signal is sent. In this way, the user can be notified of the upcoming notification signal via message. The message could be, for example, a voice message such as "Please stop."

Furthermore, in the notification function of this embodiment, within the aforementioned grace period, the content of the notification is changed to a predetermined form that makes it easier for the user to understand.

In this way, within the grace period, the content of the advance notice can be modified to a format that is easier for users to understand. This makes the advance notice easier for users to understand through changes in its format.

The methods defined to make information easily understandable to users include, for example, increasing the volume of audio over time, increasing the brightness of the display over time, making messages stronger over time, and combining these appropriately. More specifically, the volume should initially be at a normal level, like listening to music, not quite an alarm, then increase to a very loud alarm level after about 10 minutes, and then reach maximum volume after about an hour. Furthermore, the warning notification should increase to maximum volume when it is time for rescue to arrive.

(6) Transmission function The control unit 60 has a transmission function which, when the determination function determines that a disaster has occurred, transmits safety information to a predetermined server 120 indicating that the user is in a stationary state, and thereafter, when the system 1 receives a termination command from the user, transmits safety information to the server 120 indicating that the user has left the stationary state.

In this way, when a disaster is detected, safety information indicating that the user is in a stationary state is sent to the server 120. Subsequently, when a termination command is received from the user, safety information indicating that the user has left the stationary state is sent to the server 120.

The safety information should be transmitted to the server 120 by the communication unit 20, along with the identification information of the system 1 or the user. The identification information should include the date and time (hours and minutes) when the termination command was issued. Furthermore, the server 120 should be able to store the date and time when the disaster was determined, the content of the safety information, and the system 1 or user that sent it, in association with each other. In this way, the server 120 can confirm the safety of each user based on the stored safety information. This server 120 functionality may also be provided within the system itself.

Furthermore, the safety information should include location information from System 1. This allows Server 120 to determine the location of System 1. This location information should be the current location (longitude and latitude) information obtained by the GPS unit 30.

Furthermore, the safety information should include the user's biometric information. This would allow the server 120 to verify the user's biometric information based on the stored safety information. This would then enable the server to confirm the user's safety. The safety information should also include confirmation that the user is alive. Survival can be determined by a change in capacitance in devices embedded in accessories, bands, earphones, headphones, wireless earphones, headsets, hats, rings, earmuffs, underwear, or diapers that are in contact with the user's body. These devices only need to be in contact with the user's body and could be part of a medical device such as a pulse oximeter. By attaching these devices to items worn in daily life, biometric information can be read and transmitted to system 1. The headset device mentioned above should be wirelessly connected using the Bluetooth® profiles "HSP (Headset Profile)" or "HFP (Hands-Free Profile)".

Furthermore, biometric information may be acquired via short-range communication methods such as RFID tags from biosensors attached to items that users touch or wear on a daily basis.

Furthermore, the transmission function may also be configured to dial the telephone number of the disaster message service and use the telephone number assigned to System 1 as a key to transmit safety information via voice to the voice storage server 120. This allows for the transmission of safety information in conjunction with the disaster message service.

Furthermore, the transmission function of this embodiment transmits safety information via a network 100 designated for use in the event of a disaster.

In this way, safety information can be transmitted through the network 100 designated for use in the event of a disaster.

The network 100 designated for use during a disaster should be one that is less likely to experience communication failures during such an event. Specifically, it should be a network 100 that is less susceptible to damage during a disaster and configured to be prioritized for connection during such an event. In the transmission function, the communication module of the communication unit 20 is selectively used to route communications through this designated network 100. This increases the likelihood of safety information reaching the server 120. Here, automatic connection to the disaster-use network 100 is also possible. Such a network 100 should be constructed within the local area network, and the communication unit 20 should connect to it in a communication-enabled manner.

The network 100 configured to be prioritized for connection during a disaster should be a network 100 that connects to a relay station 110, which is normally a paid connection service but is configured to be made free of charge during emergencies. This way, if you have a smartphone (System 1), even if you are trapped somewhere, the chances of connecting increase as long as the on-site relay station (e.g., on-site LAN) is operational. Whether or not a relay station 110 is made free of charge during an emergency can be determined by checking whether its SSID has changed to an emergency SSID (the unified disaster SSID "00000JAPAN (Five Zero Japan)").

Furthermore, the transmission function of this embodiment may be configured to transmit safety information via the network 100, which has been continuously communicating since before the determination of a disaster.

In this way, safety information can be transmitted through the network 100, which has been continuously communicating since before the disaster was detected. This increases the likelihood that the safety information will reach the server 120.

(7) Switching function The control unit 60 has a switching function that switches the operating mode of the system 1 to an energy-saving mode in which power consumption is suppressed when the determination function determines that a disaster has occurred.

This allows the system to switch to power-saving mode (so-called battery-saving mode) when a disaster is detected. This reduces the power consumption of System 1 during a disaster, enabling the system to provide stationary vehicle alerts for a longer period.

The power-saving mode can be implemented, for example, by reducing the overall operation of System 1, increasing the communication interval with the outside world compared to the normal operating mode, increasing the time interval for sending notification signals compared to the normal operating mode, or by introducing a sleep period during which no notification signals are sent. For example, it could be implemented by sending a notification signal for one second, followed by a one-minute sleep period. The power-saving mode can also be implemented as a battery saver or airplane mode in communication terminals such as smartphones.

The switching function should ideally switch from power-saving mode to normal operating mode upon receiving the aforementioned termination command or non-notification command. This allows the system to return to normal operating mode upon receiving the termination command or non-notification command. Furthermore, the switching function should ideally switch to the power-saving mode implemented in the operating system of system 1 via, for example, an API (Application Programming Interface).

Furthermore, the switching function of this embodiment switches the operating mode of the system 1 to a power-saving mode that suppresses power consumption while a notification signal is being transmitted by the notification function. In this way, the operating mode can be switched to power-saving mode while a notification signal is being transmitted. This reduces the power consumption of the system 1 when transmitting a notification signal, allowing the notification signal to be transmitted for a longer period of time.

The switching function should ideally switch from power-saving mode to normal operation mode upon receiving the aforementioned termination command or non-notification command. This allows the system to return to normal operation mode upon receiving a termination command or non-notification command.

(8) Judgment function 2
Furthermore, the determination function determines the occurrence of a disaster in the vicinity of System 1 based on disaster occurrence notifications from the disaster prevention app, which notifies users of disaster occurrences in the vicinity of System 1.

In this way, it is possible to determine the occurrence of a disaster in the vicinity of System 1 based on notifications from the disaster prevention app.

As a disaster prevention app, it would be suitable to use a system app like those provided by Yahoo! (registered trademark), which broadcasts information such as earthquake early warnings as a disaster alert. This information should ideally be delivered via push notifications detectable by System 1. Furthermore, the disaster prevention app may be launched via communication with an NFC tag attached to a car mount or similar device.

Notifications from the disaster prevention app should be received either directly from the app or indirectly via another relay app that can communicate with it.

Here, it is preferable to configure the system to receive notifications from the disaster prevention application via at least one of the following methods: notification via API, notification via callback, notification via the external communication unit 20, notification via sound, or notification via another relay application capable of communicating with the disaster prevention application. It is also preferable to configure the system to receive notifications via another device capable of communicating with the system 1.

Disaster notifications from the disaster prevention app should be based on earthquake early warnings handled within the app. If the app can handle or receive earthquake early warnings, the detection function will detect the earthquake early warning notification executed by the operating system of System 1 within the app and determine the occurrence of a disaster based on this notification. Alternatively, the detection function may detect a specific control signal from the mobile phone itself within the app and determine the occurrence of a disaster based on the detection of this control signal. Suitable operating systems include, for example, Windows®, macOS®, Android®, and iOS®. The disaster prevention app should be configured to be downloaded and automatically installed from an application repository that distributes the program and data together.

The notification of the earthquake early warning should be detected by sound. The configuration for acquiring sound notifications should include a function to recognize the sound of the earthquake early warning. This function could be performed, for example, by identifying whether the sound detected by microphone 15b is the earthquake early warning notification sound based on its difference from other sounds. This way, even in cases where the notification of the earthquake early warning cannot be directly detected due to security or update issues in the operating system (such as strict OS security), it will be possible to determine the occurrence of a disaster based on the earthquake early warning. To recognize the sound of the earthquake early warning, it would be good to include a function to recognize whether or not a sound is the high-pitched, ringing sound of the earthquake early warning notification.

Furthermore, it would be preferable for the notification of the Earthquake Early Warning to be detected by another device capable of communicating with System 1, and for System 1 to receive the result and determine the occurrence of a disaster. The Earthquake Early Warning should be detected when it is sent to the smartphone acting as System 1. The Earthquake Early Warning should be received via ETWS (Electronic Telecommunications Warning System) when it is sent to System 1.

Furthermore, if multiple types of disaster prevention apps are installed on System 1, the detection function should determine the occurrence of a disaster in the vicinity of System 1 when a certain number (e.g., a majority) of the disaster prevention apps have notified the system of a disaster in the same area. Here, since there are various types of disaster prevention apps, the system will consider the presence of notifications from multiple apps, or from a majority of the registered apps, as important information. It will also be possible to classify a situation as a major disaster when notifications are received from several disaster prevention apps. In this way, the system can more reliably determine the occurrence of a disaster based on notifications from multiple types of disaster prevention apps.

Furthermore, if multiple types of disaster prevention applications are installed on System 1, the determination function should determine the occurrence of a disaster in the vicinity of System 1 based on whether the disaster notification from each application has a high degree of spatial proximity and temporal proximity. Notifications from multiple disaster prevention applications will be considered important information if they arrive within a predetermined time frame or within a predetermined area. For spatial proximity, high spatial proximity can be determined if the disaster locations included in each notification from the disaster prevention applications overlap or are within a certain range. For temporal proximity, high temporal proximity can be determined if the notifications from each disaster prevention application are made within a predetermined period (e.g., within 5 minutes, or within 1 hour). In this way, the occurrence of a disaster can be determined with greater certainty based on at least one of spatial and temporal proximity.

Furthermore, if System 1 has not only a disaster prevention app specifically designed to notify of disasters within a particular region, but also a disaster prevention app suitable for notifying of disasters across multiple regions, it is advisable to prioritize notifications from the former app when determining the occurrence of a disaster. If push notifications of a disaster occur from both the local disaster prevention app (based on current location information) and the nationwide disaster prevention app, the accuracy of the notification is considered very high. For example, if the former app notifies that a disaster should have occurred (e.g., an earthquake of magnitude 5), while the latter app notifies that a disaster should not have occurred (e.g., an earthquake of magnitude 3), the former notification should be prioritized when determining the occurrence of a disaster. This priority order for each disaster prevention app could be determined by prioritizing the local app based on current location information, or by determining the accuracy level and other parameters defined for each app. It is also advisable to allow users to arbitrarily set the priority order.

(9) Facilitation function The control unit 60 has a facilitation function that prompts the user to install the disaster prevention application on system 1 if the disaster prevention application is not installed on system 1.

This method allows users to be prompted to install the disaster prevention app on system 1 if it is not already installed.

The disaster prevention app that users are encouraged to install should be a regional app that notifies them of disasters occurring in the area where System 1 is located. For example, if the system is located in Aichi Prefecture or Nagoya City, the app should notify users of disasters occurring in Aichi Prefecture or Nagoya City. Whether or not the system is located within the system's area can be determined by the current location obtained by the GPS unit 30.

The timing for prompting installation should be when System 1 moves and its location changes, or when the installation of the disaster prevention app corresponding to the new location is no longer confirmed due to System 1's relocation. This way, the installation of the disaster prevention app for the new region can be prompted as the location changes. For example, if a user located in Aichi Prefecture takes System 1 with them on a business trip to Tokyo, they can be prompted to install the disaster prevention app for Tokyo.

Furthermore, the timing for prompting the installation of the disaster prevention app could be the same as the installation of the programs (or software) necessary to implement the various functions mentioned above. This ensures that the app is installed to guarantee the functionality of these features.

To encourage users to install disaster prevention apps, for example, voice prompts from speaker 15a or messages from display 11 can be used. This allows users to be prompted to install disaster prevention apps through messages. It is advisable to clearly display a link to the download site for the disaster prevention app along with the message. For example, a wizard function that guides users through the installation process interactively could clearly display a link to the download site (Google Play Store, App Store, etc.) to encourage the installation of the Yahoo! (registered trademark) disaster prevention app. After installation, links to download other disaster prevention apps could be displayed to encourage installation of other apps, thereby encouraging users to install each disaster prevention app.

[Disaster notification processing by the control unit 60]
Next, the processing procedure for the disaster notification process executed by the control unit 60 according to the program stored in the memory unit 40 will be explained with reference to Figure 2. This disaster notification process is executed repeatedly after the system 1 is started. This disaster notification process is executed in the background.

When this disaster prevention notification process is activated, first, a determination is made as to whether or not a disaster has occurred based on the signal reception status by the communication unit 20 (s110). This s110 then realizes the determination function 1 described above.

If it is determined in s110 that no disaster has occurred (s120: NO), the process returns to s110. On the other hand, if it is determined in s110 that a disaster has occurred (i.e., a disaster has occurred) (s120: YES), a warning notification is initiated to inform the system that a warning signal will be sent (s130). From s130, the aforementioned warning function is implemented via s170, which will be described later.

After the start of the advance notification in s130, it is checked whether the grace period has elapsed (s140). If the grace period has not elapsed in s140 (s140: NO), it is checked whether a non-notification command was received during this grace period (s150).

If no notification command is received in s150 (s150: NO), the process returns to s140. However, if a notification command is received (s150: YES), after the advance notification initiated in s130 has ended (s160), the process returns to s110.

Furthermore, if the grace period has elapsed in s140 (s140: YES), after the advance notification initiated in s130 has ended (s170), the transmission of the notification signal begins (s180). From s180, the notification function described above is realized via s230, which will be explained later.

After the notification signal transmission begins as described in s180, safety information indicating that the user is stationary is transmitted to the server 120 (s190). This s190 and the s220 described later realize the transmission function described above.

Next, after the operating mode of System 1 is switched to power-saving mode (s200), it enters a standby state until it is determined that a termination command has been received (s210: NO). This s210 and the s240 described later realize the switching function described above.

If a termination command is received in s210 (s210: YES), safety information indicating that the user has exited the stagnant state is sent to server 120 (s220).

Then, after the transmission of the notification signal initiated in s180 ends (s230), and the operating mode of System 1 switches to the normal operating mode (normal mode) (s240), the process returns to s110.

[effect]
According to the above embodiment, it is possible to provide a system that is superior to conventional systems.

System 1 can receive signals inferred from the reception status, determine that a disaster has occurred, and then emit a notification signal such as a beacon. For example, it can send a notification signal triggered by the reception of an earthquake early warning.

System 1, through the functions described above, makes it easier for third parties to pinpoint the user's location, thereby contributing to the effective rescue of users who have become victims of a disaster. In other words, searchers can easily locate distress signals in the general location or approximate area of collapsed buildings or other structures during a disaster and search for people. For example, by having System 1 emit a beacon, the RSSI (Received Signal Strength Indicator) of that beacon can be easily scanned to determine the approximate location of a buried person, enabling rescue efforts.

For example, in a large-scale disaster where houses collapse everywhere and people with cell phones are lying on the ground and unable to stop emitting beacons, a blind scan would be necessary. However, with System 1 described above, the transmission of the notification signal can be stopped with a termination command, thus contributing to the effective rescue of users who have become victims. While it would be impossible to find someone if every house is emitting a beacon, it is still possible to find them if only a few houses are emitting them, making stopping the transmission crucial. System 1 above has a mechanism implemented to stop the transmission in this way.

In cases where people are buried under rubble after an earthquake and their whereabouts are unknown, it becomes necessary to dig everywhere, meaning that all the rubble in the area where the surviving residents were likely to have lived must be cleared away indiscriminately. Especially depending on the disaster situation, heavy machinery may be unavailable, requiring manual labor. In such situations, if the person being searched is wearing or possessing a device that emits radio waves, such as System 1, it becomes possible to pinpoint the search area. While the goal is to rescue residents as quickly as possible while they are still alive, such physical work often requires searching based on vague information and in the absence of rescue teams or personnel, making it easy to end up not finding them at all. This system helps prevent situations where a person might actually be in a slightly different location, and could have been saved if rescued immediately, but was unable to be helped because their exact location was unknown.

In the above embodiment, in a situation where multiple users in the same area are each carrying the system 1, all of them can be notified via a notification signal, using a human-perceptible display, light, vibration, or sound, that they are in a situation requiring rescue. On the other hand, most living people and users who are conscious and do not require rescue can consciously choose not to send the notification signal or to stop sending the notification signal. This ability to retrospectively stop and cancel the notification signal is important in that it reflects the user's intentions.

For example, if a person is alive or does not require rescue, even if they are not carrying System 1, they are likely to stop transmitting the alert signal within a short time, such as one minute, even if it is ringing in an adjacent room. Considering scenarios where rescue cannot be carried out quickly due to the disaster situation, after a long period of time, such as one hour, the alert signals from each user in System 1 should have stopped transmitting. This would contribute to effective rescue efforts based on the remaining alert signals.

[Other Embodiments]
The present invention is not limited to the embodiments described above, and the following embodiments can also be constructed.

The above system 1 may be capable of transmitting signals externally even without external power supply. External power supply could, for example, be from a commercial power source or an AC power source.

The above system 1 may be configured to operate by receiving power from an external source via energy harvesting. For example, it could receive power from an external energy-harvesting device that generates electricity based on natural energy sources such as vibration, light, heat, wind, or electromagnetic waves. A solar panel that generates electricity from light would be a suitable external device. Alternatively, another external device could be attached to a window, continuously generating electricity from the window's vibrations and storing it in a battery, while simultaneously emitting pulsed signals or radio waves when the window is broken.

The above-described system 1 should be a device that can operate on battery power. System 1 should be configured to charge its internal battery when power is supplied from an external source, and to operate using the battery's power when external power is unavailable.

Furthermore, the above-mentioned system 1 may have a function to suspend the transmission of notification signals after communicating with other systems 1 while the transmission of notification signals from other systems 1 carried by other users within the same area is detected. In this function, for example, the systems exchange parameters such as battery level, notification signal transmission capacity, and location information of system 1, and then determine which system 1 should transmit the notification signal according to a predetermined rule. If the system 1 is not the target of transmission, it will suspend the transmission of the notification signal. Here, the communication with systems 1 carried by other users should be conducted using a predetermined wireless communication standard. In this way, while other systems 1 that are the target of transmission are transmitting notification signals, system 1 can suspend the transmission of its own notification signal. This makes it possible to reduce the power consumption of individual systems 1 while leaving the transmission of notification signals within the same area to other systems 1. Each system 1 carried by each user within the same area can transmit notification signals sequentially according to the above rule, enabling the transmission of notification signals for the entire area over a long period of time. As a result, it will contribute to the effective rescue of users within the same area over a long period of time.

Furthermore, in the above embodiment, it is preferable to recognize, via Bluetooth® or similar means, that multiple systems 1 are operating (sending out notification signals) in the vicinity, and to delegate the transmission of notification signals to only one of the systems 1, preventing other systems 1 from sending out notifications. For example, system 1 may only send out a notification signal if it recognizes the presence of another system 1 nearby and that system 1 has not yet sent out a notification signal. In this way, if another system 1 is nearby and sending out notification signals, the transmission of the notification signal can be delegated to this system 1. When the transmission of notification signals from the delegated system 1 stops, it is preferable to delegate the transmission of notification signals to only one of the other systems 1. This approach reduces the overall power consumption of each of the multiple systems 1 while still transmitting notification signals to contribute to the effective rescue of the user.

The presence of another system 1 can be determined, for example, through communication using a short-range communication standard such as Bluetooth® with the other system 1. If multiple systems 1 exist within the same area, each system 1 should communicate via P2P (Peer-to-Peer). This allows for the transmission of notification signals within the same area to be delegated to other systems 1, while reducing the power consumption of system 1. Each system 1 carried by a user within the same area can sequentially transmit notification signals, enabling long-term transmission of notification signals across the entire area. As a result, this contributes to the effective rescue of users within the same area over a long period.

In this case, the notification function should collect information such as the location information of other systems 1 that have withheld sending the notification signal, and the number of systems 1 that have detected the transmission of the notification signal, and include this information in the notification signal before sending it.

Furthermore, in the above embodiment, a biosensor 55 is provided as part of the sensor group 50, and it is configured to acquire biological information from this sensor. This biological information may be acquired from a biosensor attached to an object that the user touches or wears on a daily basis. It is preferable to acquire this information from the biosensor via communication using a predetermined wireless communication standard.

System 1 should consist of a main communication device, such as a smartphone, and an auxiliary device capable of communicating with it. The auxiliary device could be a wearable device, such as a smartwatch or smart glasses. In this case, the auxiliary device should be paired with System 1 (the smartphone). Smartwatches are effective because they are widely used, even by children. An example of a smartwatch would be the Apple Watch (registered trademark). This auxiliary device should have a notification function. Here, the main communication device transmits the disaster occurrence determination result to the auxiliary device, which then sends a notification signal. Communication between the communication device and the auxiliary device should be based on a predetermined short-range communication standard. Wearable devices could be sewn into clothing, ring-shaped, or bracelet-shaped.

Furthermore, the system 1 should ideally have a function to automatically send a notification signal to the outside immediately (for example, as quickly as possible with minimal delay) without user intervention, when it determines, based on disaster-related information received from an external source, that a disaster has occurred and a signal should be sent to the outside. Specifically, in the disaster notification processing, it is preferable to configure the system to immediately proceed to s180 when a disaster is determined to have occurred in s120. Regarding "without user intervention," the system 1, in a configuration that receives user input and implements predetermined functions corresponding to that input, should ideally have a function to automatically send a notification signal to the outside without user intervention, when it determines, based on disaster-related information received from an external source, that a disaster has occurred.

Furthermore, in the above embodiment, the disaster notification process is configured to switch to power-saving mode while the notification signal is being transmitted (s180-s230). However, the operation mode may also be configured to switch to power-saving mode only when a disaster is determined to have occurred. Specifically, in the disaster notification process, it is preferable to configure the system so that the switch to power-saving mode (s200) occurs immediately after a disaster is determined to have occurred in s120 (s120: YES).

System 1 should be configured to be carried in contact with the user's body. System 1 should be a device worn by the user. System 1 should have a wearable part for the user to wear. The wearable part could be, for example, a plastic band. This eliminates the constraint that the user must wear it properly. System 1 should be equipped with a sensor that acquires biometric information by contacting the user's body. For example, it could be configured as a smartwatch capable of acquiring at least one of heart rate, body temperature, and blood pressure. As for the sensor, for example, the picofala value should change when the return is inside and in contact with the person's body.

The disaster occurrence determination function should ideally be based on multiple types of information obtained from one or more sources. This allows for a disaster occurrence determination based on multiple types of information from one or more sources, thereby making the determination of disaster occurrence more likely.

Furthermore, System 1 may be configured to passively transmit a notification signal in response to a strong radio wave received from an external source after the disaster has been detected by the detection function. This allows a response to be sent even if the source has no power. This also allows System 1 to function as a reflector even if the battery is depleted. In this case, some form of modulation may be applied to the radio wave before it is returned.

Furthermore, System 1 may be configured to return unique identification information (such as a telephone number) when it receives a predetermined signal from an external source.

Furthermore, the location information from each system 1 may be configured to be received by another device (hereinafter referred to as the "search device"). This search device should be configured to display the location of each system 1, indicated by the location information, on a map along with the search device's current location, and to show the distance and direction to that location, or to display a list of each system 1 in order of proximity. Similarly, another device that receives the notification signals from each of the above systems 1 as radio waves should be configured to display the location of the system 1, determined based on the electric field strength of the radio waves, on a map along with the current location of the other device, and to show the distance and direction to that location. The distance to system 1 may be represented by shades of color or brightness.

The maps used in these systems may be online maps or offline maps. These maps should ideally map the current location of each system 1 and its surroundings in two or three dimensions. Here, like a car navigation app, the system may display the location on the map and provide directions to that location. Furthermore, it would be beneficial to allow for selective hiding of each system 1 location displayed on the map (so-called "hiding"). This hiding feature allows for the identification of situations where, for example, only a specific house is likely to be buried.

When indicating the location of System 1, information related to each System 1 (specifically, a telephone number as identification information, information indicating that the transmission of notification signals has stopped due to a termination command, and the status indicated by the safety information) may be displayed. Furthermore, when indicating System 1, a function may be provided to change the information to identify the person possessing System 1, or a function to filter System 1 displayed under predetermined conditions. For example, this condition could be to filter out the display of healthy individuals, in other words, people who do not require rescue.

Furthermore, the map displayed online should be stored on a server, allowing each user to access and view it from their own System 1 or search device. This would allow users and search teams to selectively mark off locations on System 1. Ideally, users and search teams should be able to individually select System 1 and switch the display of the user's safety status on that System 1. This would allow the server to inform each user and search team that their safety status has been confirmed (e.g., that they are OK).

The search device described above should ideally have a background process that, upon approaching each system 1 (which acts as a smartphone emitting a beacon), pairs with the smartphone to indicate the location of each system 1. This pairing process should involve a predetermined personal authentication process. This would enable effective searches by search teams, each individually equipped with a search device.

Furthermore, the search device function described above may be implemented in the device via an application. Alternatively, the search device function may be implemented in System 1 by installing the application. In this case, System 1 should be configured to allow the user to arbitrarily switch between a rescue mode, where various functions based on the program stored in the memory unit 40 are realized, and a search mode, where the search device function is realized. This allows any user possessing System 1 to participate in a search as part of a search team.

When showing the location of each system 1 on a map, it is advisable to color-code each system 1 (or use different colors for each system 1's location) and indicate the intensity of the color according to the distance to the current location. For example, on a 100m x 100m map that can be zoomed in and out, the locations of each system 1 could be displayed along with hatching in colors corresponding to the distance on the plane. In this case, the location of each system 1 should be displayed in a color corresponding to the user's status, such as user safety information (whether the user is stationary or not). Such a map display may be on a display built into the search device, or it may be on an external display such as digital signage.

Furthermore, in System 1, it is advisable to switch the content of the notification signal to information that is easier for the searcher to detect as the search device approaches. For example, it is conceivable to initially transmit a beacon signal, and then change it to sound, then to light, as the search device gets closer. Also, System 1 should transmit a notification signal with low power consumption until the search device approaches a predetermined distance. Furthermore, System 1 may pair with the search device once it has approached to a certain extent, and then switch the content of the notification signal in response to commands from this search device. Additionally, System 1 may be configured to switch its operating mode to power-saving mode once the search device has approached to a certain extent.

Furthermore, in the above embodiment, if each of the multiple systems 1 transmits a notification signal such as a beacon, it is preferable to enable system 1 to determine the position of the other systems 1 based on these beacons. The position of the other systems 1 should be determined as the distance to that point.

System 1 may also use a detection function to determine that a disaster has occurred when a communication-enabled relay station 110 changes its SSID to an emergency SSID (00000JAPAN).

In the above embodiment, it is preferable to enable external detection of the radio waves emitted by System 1, which functions as a mobile phone, for connecting to a base station. This allows for searching for a base station by picking up the radio waves emitted when the base station is not visible.

The system 1 described above may be configured to relay radio waves from other systems 1, that is, to function as a base station.

In the above embodiment, it is preferable to enable external detection of the user's operating state using sensors such as a vibration microphone or vibration sensor. The vibration microphone should be capable of detecting the user's operating state within a predetermined angle range (e.g., plus or minus 60 degrees) that forms a fan shape. In this case, the user's operating state can be detected if there are no reflective objects between the user and the sensor.

The above system 1 should ideally be designed so that functions such as sending notification signals can be transferred to a system that can acquire information even without a battery. At this time, it would also be desirable to be able to transfer information such as the user's biometric data and whether or not they were touching (operating) the device immediately beforehand.

The system described above could be configured to immediately emit a beacon when an earthquake early warning is issued.

For example, System 1 may have the following functions. Alternatively, the overall system shown in Figure 1 may have the following functions.

1. Safety confirmation system during disasters: It is advisable to have a system in place that collects and processes user safety information and provides safety confirmation information.
2. Beacon transmission control function: It would be desirable to have a function that controls beacon transmission during disasters based on operations by the user or search and rescue team.
3. User operation recognition function: It would be good to have a function that generates safety information based on terminal operations and sends it to the system.
4. Search and rescue team operation recognition function: It would be beneficial to have a function that recognizes the safety confirmation operation performed by the search and rescue team and generates corresponding safety information.
5. Free Wi-Fi connection promotion function: It would be good to have a function that automatically promotes connection to a free Wi-Fi network in the event of a disaster.
6. Automatic safety information transmission function: It would be good to have a function that automatically transmits safety information using free Wi-Fi in the event of a disaster.
7. Information sharing function with external devices: It would be beneficial to have a function that allows safety information to be transferred to external devices, enabling long-term information retention.
8. Automatic information transmission destination selection function: It would be beneficial to have a function that automatically selects the optimal safety confirmation system for receiving safety information.
9. Safety Information Generation Function: It would be beneficial to have a function that generates safety information based on user actions or confirmation by the search and rescue team.
10. Battery saving function for communication devices: It would be good to have a function to minimize battery consumption when transmitting beacons.
11. Safety Information Priority Determination Function: It would be beneficial to have a function that determines the priority of beacon transmission based on information from multiple safety information sources.
12. Information integration function from multiple safety information sources: It would be beneficial to have a function that integrates information obtained from multiple safety information sources and provides consistent safety information.
13. Automatic Wi-Fi network connection function for disasters: It would be beneficial to have a function that automatically connects to a Wi-Fi network with a specific SSID in the event of a disaster.
14. Function to link with public safety confirmation systems: It would be good to have a function that enables information linkage with public safety confirmation systems.
15. Manual update function for user safety information: It would be good to have a function that allows users to manually update their own safety information.
16. Disaster Information Gathering and Provision System: It is advisable to have a system in place to collect and provide information to users in the event of a disaster.
17. Automatic communication mode switching function: It would be good to have a function that automatically switches the communication mode in response to changes in the communication environment.
18. Function to utilize multiple safety information sources: It would be beneficial to have a function that generates more accurate safety information by utilizing multiple information sources.
19. Automatic notification system in the event of a disaster: It would be beneficial to have a system that detects the occurrence of a disaster and automatically notifies users of relevant information.
20. Remote update function for safety confirmation information: It would be beneficial to have a function that allows a third party, such as a search and rescue team, to remotely update safety confirmation information.
21. Function to reduce communication load during disasters: It would be good to have an information transmission function to reduce the load on the communication network.
22. Communication devices with energy harvesting capabilities: It is desirable to have communication devices that supply power using renewable energy.
23. Function to link safety information with geographical location information: It would be good to have a function to link safety information with geographical location information.
24. Multiplex communication function for information transmission during disasters: It is desirable to have a function that enhances the reliability of information transmission by using multiple communication functions in combination.
25. Safety estimation function based on user operation history: It would be good to have a function that analyzes the user's operation history and estimates their safety.
26. Automatic information gathering function during disasters: It would be beneficial to have a function that automatically collects relevant information during disasters.
27. Automatic update function for user safety information: It would be good to have a function that automatically updates safety information in response to changes in the user's status.
28. Automatic warning system based on disaster information: It is advisable to have a system that automatically issues warnings based on received disaster information.
29. Power supply system during disasters: It is advisable to have a system in place to maintain power supply during disasters.
30. Disaster Information Sharing Platform: It would be beneficial to have a platform in place to facilitate information sharing in the event of a disaster.

This system should ideally be portable and have a function to determine the occurrence of a disaster in the vicinity of the system based on the signal reception status, and a function to send a signal to external parties to inform them that a user may be stationary near the system's location if a disaster is detected.

The system described above makes it easier for third parties to identify the location of a user, which can contribute to the effective rescue of users who have become victims of a disaster. This system contributes to several SDGs (Sustainable Development Goals). For example, it is related to the following goals:
1. Goal 11: Sustainable Cities and Communities - Target 11.5: Reduce disaster risk and impact This system will streamline rescue operations in disaster-stricken areas by quickly and accurately notifying users of their location during a disaster. This will reduce the number of casualties from disasters, enable rapid rescue, and contribute to mitigating disaster risk and impact.
2. Goal 3: Good Health and Well-being - Target 3.d: Disaster Preparedness. Rapid response during disasters leads to faster rescue of injured people and faster provision of medical care. This system makes it easier to locate victims, enabling earlier rescue efforts and contributing to minimizing health damage.
3. Goal 9: Build resilient infrastructure, foster inclusive and sustainable industrialization and promote innovation. Target 9.4: Technological innovation for disaster response. This system utilizes new technologies in disaster response and contributes to infrastructure resilience and the promotion of sustainable technological development. In particular, as a portable system, it is an example of technological innovation that ensures user safety.
4. Goal 17: Partnerships for the Goals - Target 17.8: Expand Science and Technology Such disaster response technologies are particularly expected to be introduced in developing countries. Through global technical cooperation and information sharing, the use of technologies will be promoted among multiple countries, contributing to the dissemination of knowledge and technologies related to disaster relief and disaster risk management.

This system is a technology that enables rapid response during disasters and supports effective rescue of victims. This technology contributes to reducing disaster risk, improving health and well-being, and promoting technological innovation, thereby contributing to multiple Sustainable Development Goals (SDGs).

Furthermore, the scope of this invention is not limited to the configurations explicitly described in the specification, but also includes combinations of various aspects of the invention disclosed herein. While the configurations for which patent protection is sought are specified in the appended claims, we intend to include configurations not currently specified in the claims, as disclosed herein, within the scope of future claims.

The present invention is not limited to the configurations described in the embodiments above. The components of each embodiment and modification described above can be arbitrarily selected and combined. Furthermore, any component of each embodiment and modification can be arbitrarily combined with any component described in the means for solving the invention, or any component that embodies any component described in the means for solving the invention. We intend to obtain rights to these combinations as well, through amendments or divisional applications of this application. Even if there are descriptions such as "in the case of..." or "when...", the configuration is not limited to those specific cases or times. Configurations that do not fall under these cases or times are also disclosed, and we intend to obtain rights to them. Also, even if there is a specific order of descriptions, it is not limited to that order. Configurations with some parts deleted or the order rearranged are also disclosed, and we intend to obtain rights to them.

Furthermore, we intend to acquire rights to the overall design or partial design by converting the application to a design registration application. While the drawing depicts the entire device with solid lines, it encompasses not only the overall design but also partial designs claimed for specific parts of the device. For example, it includes not only partial designs for specific components of the device, but also partial designs for parts of the device unrelated to specific components. These parts could be components of the device, or parts of those components. We intend to acquire rights to the overall design, as well as to any partial design where a portion of the solid lines in the drawing is represented by dashed lines. Similarly, we intend to acquire rights to the modules, components, and parts inside the device's casing, as these are all independently traded items as shown in the drawing, by converting the application to a design registration application.

1…System, 10…User Interface, 11…Display, 13…Operation Input Unit, 15…Audio Input/Output Unit, 15a…Speaker, 15b…Microphone, 17…Vibrator, 19…Operation Buttons, 20…Communication Unit, 21…Mobile Communication Module, 23…Wireless Communication Module, 25…Short-Range Communication Module, 30…GPS Unit, 40…Memory Unit, 50…Sensor Group, 51…Accelerometer, 53…Gyro Sensor, 55…Biometric Sensor, 57…Illuminance Sensor, 60…Control Unit, 100…Network, 110…Relay Station, 120…Server.

Claims (13)

A system that is portable to the user,
A determination function that determines the occurrence of a disaster in the vicinity of the system based on the signal reception status,
The system has a notification function that, when the aforementioned determination function determines that a disaster has occurred, sends a notification signal to an external party to inform them of the possibility that a user is stationary near the location of the system.
system. The notification function transmits the notification signal from the time the occurrence of a disaster is determined by the determination function until it receives a termination command from the user to the system.
The system according to claim 1. The notification function sends the notification signal if it does not receive a non-notification command from the user to the system during the period from when the occurrence of a disaster is determined by the determination function until a predetermined grace period has elapsed.
The system according to claim 1. The system has a notification function that provides a notification to the user in advance of the transmission of the notification signal before the aforementioned grace period has elapsed.
The system according to claim 3. The aforementioned notification function changes the content of the notification within the grace period to a form determined to be easily understood by the user.
The system according to claim 4. The system has a transmission function that, when a disaster is determined by the aforementioned determination function, sends safety information to a designated server indicating that the user is in a stationary state, and thereafter, when the system receives a termination command from the user, sends safety information to the server indicating that the user has left the stationary state.
The system according to claim 1. The aforementioned transmission function transmits the safety information through a network designated for use in the event of a disaster.
The system according to claim 6. The transmission function, when the occurrence of a disaster is determined by the determination function, transmits the safety information via a network that has been continuously able to communicate since before the determination.
The system according to claim 6. The system has a switching function that, when the aforementioned determination function determines that a disaster has occurred, switches the operating mode of the system to a power-saving mode that reduces power consumption.
The system according to claim 1. The system has a switching function that switches the operating mode to a power-saving mode that suppresses power consumption while a notification signal is being sent by the aforementioned notification function.
The system according to claim 1. The aforementioned determination function determines the occurrence of a disaster in the vicinity of the system based on a disaster occurrence notification from a disaster prevention application that notifies users of the occurrence of a disaster in the vicinity of the system.
The system according to claim 1. The system according to claim 11, further comprising a function that prompts the user to install the disaster prevention application on the system if the disaster prevention application is not installed on the system. A program for a computer to implement the functions of the system described in any one of claims 1 to 12.