Program and terminal

Abstract

To achieve smooth evacuation by supporting joining of two terminals even when communication with a server is interrupted in a disaster.SOLUTION: A merging assistance program for a disaster according to the present invention is a merging assistance program for a disaster to be executed by a first terminal, wherein the first terminal receives encrypted user information of a second terminal in advance, detects disaster occurrence information, decrypts the encrypted user information of the second terminal on condition that the first terminal becomes communicable with the second terminal, and performs notification using the decrypted user information of the second terminal.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to merging assistance in the event of a disaster. [Background technology]

[0002] Conventionally, when disasters occur and disaster victims who do not have a means of transportation such as a vehicle need to evacuate, they search for a vehicle heading in the same direction as their own evacuation destination, and get permission to ride with the vehicle to their evacuation destination. Cited document 1 discloses a system using a communication terminal, in which a server transmits the terminal information of a passenger seeking rescue to the terminal of a nearby driver, so that the driver becomes aware of the presence of the passenger, and the driver again informs the passenger via the server that they are available for a ride, and when the passenger selects that they wish to ride, the ride is established. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Laid-Open No. 2017-147579 Summary of the Invention [Problem to be solved by the invention]

[0004] However, this method uses the mobile phone carrier's communication network, so if communication with the server is cut off during a disaster, it is not possible to find the vehicle you are riding in. The purpose of this invention is to support the reunification of two devices even if communication with the server is cut off during a disaster, thereby realizing a smooth evacuation. [Means for solving the problem]

[0005] In order to solve the above-mentioned problems, the disaster rendezvous support program of the present invention is a disaster rendezvous support program executed by a first terminal, wherein the first terminal receives encrypted user information of a second terminal in advance, detects disaster occurrence information, and, on the condition that the first terminal is able to communicate with the second terminal, decrypts the encrypted user information of the second terminal and makes a notification using the decrypted user information of the second terminal. [Effects of the Invention]

[0006] According to the present invention, the first terminal receives the user information of the second terminal that has been encrypted in advance, so that in the event of a disaster, the first terminal can receive the information necessary for decryption and decrypt it, thereby identifying the vehicle or person wishing to ride with them and allowing them to join together. [Brief explanation of the drawings]

[0007] [Figure 1] FIG. 1 is a schematic diagram of the overall configuration of a merging assistance system according to this embodiment. [Figure 2] FIG. 2 is a schematic diagram of the driver's terminal and the terminals of passengers wishing to ride. [Figure 3] FIG. 3 is a schematic diagram of a server. [Figure 4] FIG. 4 is a schematic diagram of data transmitted and received between the driver's terminal, the passenger's terminal, and the server. [Figure 5] FIG. 5 is a flowchart for explaining the processing executed by the server in response to input from the driver's terminal during normal times before the occurrence of a disaster. [Figure 6] FIG. 6 is a flowchart for explaining the processing executed by the server in response to input from the terminal of a passenger wishing to ride during normal times before a disaster occurs. [Figure 7] FIG. 7 is a schematic diagram of a merging support system in the event of a disaster. [Figure 8] FIG. 8 is a diagram showing the communication range of short-distance wireless communication. [Figure 9] FIG. 9 is a flowchart for explaining the process executed by the driver's terminal when a disaster occurs. [Figure 10] FIG. 10 is a diagram showing an example of the display content of the driver's terminal. [Figure 11] FIG. 11 is a flowchart for explaining the process executed by the terminal of the passenger who wishes to ride in the event of a disaster. [Figure 12] FIG. 12 is a diagram showing an example of the display content of the terminal of the passenger wishing to ride with the passenger. DETAILED DESCRIPTION OF THE INVENTION

[0008] The present invention will be described below through embodiments of the invention, but the following embodiments do not limit the scope of the invention. Furthermore, not all of the combinations of features described in the embodiments are necessarily essential to the solution of the invention. In the drawings, the same reference numerals are used to designate the same or similar parts, and redundant explanations may be omitted.

[0009] The merging assistance system 900 will be described with reference to the drawings. Fig. 1 is a schematic diagram of the overall configuration of the merging assistance system 900. The merging assistance system 900 includes a terminal 1 of a driver who uses the merging assistance system 900, a terminal 2 of a passenger who wishes to ride with the driver, and a server 3.

[0010] The driver's terminal 1 and the passenger's terminal 2 are portable terminals such as mobile phones, smartphones, and personal computers, or in-vehicle terminals such as car navigation devices, and unless otherwise specified, they will be commonly referred to as terminal 4 and will be described using the same symbol.

[0011] As shown in Fig. 2, the terminal 4 includes a control unit 40, a memory unit 41, an input unit 42, a display unit 43, and a communication unit 44. In this case, as shown in the schematic diagram of the system in Fig. 7, the driver's terminal 1 includes a control unit 10, a memory unit 11, an input unit 12, a display unit 13, and a communication unit 14, and the passenger's terminal 2 includes a control unit 20, a memory unit 21, an input unit 22, a display unit 23, and a communication unit 24.

[0012] The control unit 40 includes various processing circuits such as a CPU (Central Processing Unit), an ASIC (Application Specific Integrated Circuit), a DSP (Digital Signal Processor), a GPU (Graphics Processing Unit), an AI (Artificial Intelligence) chip, etc. Furthermore, the control unit 40 may include a plurality of the same or different types of control units, and each process may be shared among them.

[0013] The storage unit 41 uses various storage media such as a RAM (Random Access Memory) and a ROM (Read Only Memory).

[0014] The input unit 42 includes a camera, microphone, buttons, a keyboard, a touch panel, etc., and is mainly used by the driver or passengers to input information.

[0015] The display unit 43 uses a display, a liquid crystal panel, an LED, etc., and is mainly used by the driver or passengers to check information.

[0016] The communication unit 44 is connected to the network 5 using cellular communication or the like, and communicates with other devices via the network 5. The communication unit 44 is also capable of communicating using short-range wireless communication 6. The short-range wireless communication 6 is Bluetooth (registered trademark) communication, BLE (registered trademark, Bluetooth Low Energy) communication, Zigbee (registered trademark) communication, UWB (Ultra Wide Band) communication, LPWA (Low Power Wide Area) communication, wireless LAN (Local Area Network) communication, or the like.

[0017] The server 3 includes a control unit 30, a storage unit 31, and a communication unit 32.

[0018] The control unit 30 uses various processing circuits such as a CPU, ASIC, DSP, GPU, AI chip, etc. Furthermore, a plurality of control units of the same type or different types may be provided, and each process may be shared and executed.

[0019] The storage unit 31 may be any of various storage media such as a RAM, a ROM, a flash memory, an EEPROM (Electrically Erasable Programmable Read Only Memory), a hard disk, an SSD (Solid State Drive), or a DVD device.

[0020] The communication unit 32 is connected to the network 5 and communicates with other devices via the network 5.

[0021] 4 and 5, the processing flow executed by the server 3 in response to input from the driver's terminal 1 during normal times before the occurrence of a disaster will be described.

[0022] As shown in FIG. 4, the driver's terminal 1 and the server 3 communicate with each other via a network 5 operated by a provider of cellular communications or the like.

[0023] The driver inputs support information via the input unit 12 of the driver's terminal 1 and transmits it to the server 3 via the communication unit 14. The server 3 then acquires the support information via the communication unit 32 (step S001).

[0024] The support information is user information, such as vehicle information such as the vehicle model, color, license plate number, and vehicle photo, as well as the driver's area, facial photo, evacuation destination, evacuation route, and number of passengers allowed.

[0025] The server 3 determines whether the vehicle information included in the acquired assistance information is already stored in the storage unit 31 (step S002).

[0026] If the server 3 has not yet stored the vehicle information included in the acquired support information in the storage unit 31, the server 3 proceeds to step S004, which will be described later. If the vehicle information is the same as the vehicle information already stored in the storage unit 31 and the support information is different from the support information already stored in the storage unit 31, the server 3 determines that the support information is being added or modified (step S003), and proceeds to the processing of step S006, which will be described later. If the vehicle information is the same as the vehicle information already stored in the storage unit 31 and the support information is the same as the support information already stored in the storage unit 31, the processing ends.

[0027] The server 3 determines a vehicle identifier for each vehicle that can be supported (step S004).

[0028] The vehicle identifier is a unique user identifier that identifies the vehicle and is composed of letters and numbers.

[0029] The server 3 transmits the vehicle identifier to the driver's terminal 1 (step S005).

[0030] The server 3 stores the support information in the storage unit 31 (step S006).

[0031] Here, the processing flow executed by the server 3 in response to input from the terminal 2 of a passenger applicant during normal times before a disaster occurs will be described with reference to FIG.

[0032] The terminal 2 of the passenger wishing to ride and the server 3 communicate with each other via a network 5 operated by a provider of cellular communications or the like.

[0033] The passenger wishing to ride enters passenger information via the input unit 22 of the passenger wishing to ride terminal 2, and transmits the information to the server 3 via the communication unit 24. The server 3 then acquires the passenger information via the communication unit 32 (step S011).

[0034] The passenger information is user information, such as the passenger's area, facial photo, evacuation destination, and evacuation route.

[0035] The server 3 determines whether the acquired passenger information is already stored in the storage unit 31 (step S012).

[0036] If the acquired passenger wishing to ride together information has not yet been stored in the storage unit 31, the server 3 proceeds to step S014, which will be described later. If the passenger wishing to ride together information differs from the passenger wishing to ride together information already stored in the storage unit 31, the server 3 determines that the passenger wishing to ride together information has been added or modified (step S013), and proceeds to the processing of step S016, which will be described later. If the passenger wishing to ride together information is the same as the passenger wishing to ride together information already stored in the storage unit 31, the processing ends.

[0037] The server 3 determines a passenger identifier for each passenger who wishes to ride with the server 3 (step S014).

[0038] The passenger requesting user identifier is a unique user identifier that identifies the passenger requesting user, and is composed of letters and numbers.

[0039] The server 3 transmits the passenger identifier to the terminal 2 of the passenger (step S015).

[0040] The server 3 stores the passenger information in the storage unit 31 (step S016).

[0041] The server 3 determines whether support information for the same area is already stored in the storage unit 31 (step S017).

[0042] If the server 3 already stores support information for the same region in the storage unit 31, the server 3 encrypts the support information using the vehicle identifier corresponding to the support information and transmits the encrypted support information to the terminal 2 of the passenger applicant (step S018).

[0043] With this configuration, the terminal 2 of the passenger wishing to ride cannot decode the assistance information until it receives the vehicle identifier, so the driver's user information can be protected under normal circumstances.

[0044] The server 3 ends the process if the information of a passenger wishing to ride in the same area is not stored in the storage unit 31. At this time, the server 3 notifies the terminal 2 of the passenger wishing to ride that the support information of the same area is not stored.

[0045] Returning to FIG. 5, the server 3 determines whether the storage unit 31 already stores information about passengers wishing to ride in the same area (step S007).

[0046] If the server 3 already stores information about passengers from the same region in the storage unit 31, the server 3 encrypts the passenger information using the passenger identifier corresponding to the passenger information and transmits the encrypted information to the driver's terminal 1 (step S008).

[0047] With this configuration, the driver's terminal 1 cannot decrypt the passenger applicant information until it receives the passenger applicant identifier, so that the user information of passenger applicants can be protected under normal circumstances.

[0048] The server 3 ends the process if the storage unit 31 does not store information on passengers wishing to ride in the same area. At this time, the server 3 notifies the driver's terminal 1 that the server 3 does not store information on passengers wishing to ride in the same area.

[0049] Here, the number of passenger wishing to ride information transmitted in step S008 is not limited to one. The server 3 encrypts the passenger wishing to ride information of multiple passengers using the corresponding passenger wishing to ride identifiers and transmits the encrypted passenger wishing to ride information to the driver's terminal 1, and the driver's terminal 1 can store the encrypted passenger wishing to ride information in the memory unit 11.

[0050] Similarly, the number of pieces of support information transmitted in step S018 is not limited to one. The server 3 can encrypt multiple pieces of support information for multiple drivers using the corresponding vehicle identifiers and transmit the encrypted pieces of support information to the terminal 2 of the passenger wishing to ride with the passenger, and the terminal 2 of the passenger wishing to ride with the passenger can store the encrypted pieces of support information in the storage unit 21.

[0051] Furthermore, multiple pieces of passenger information for a single passenger applicant can be encrypted together, and similarly, multiple pieces of assistance information for a single driver can be encrypted together.

[0052] Furthermore, the same information regarding passenger information and support information can be stored in multiple terminals 4 .

[0053] The server 3 can perform steps S007 and S008, and steps S017 and S018 multiple times at any timing, not just once. For example, the server 3 may perform steps S007 and S008 when new passenger wishing to ride information is stored in the storage unit 31, or may perform steps S007 and S008 when the driver's terminal 1 and the server 3 communicate with each other. Furthermore, when the server 3 stores new passenger wishing to ride information in the storage unit 31, it can notify the driver's terminal 1 that the new passenger wishing to ride information has been stored.

[0054] Similarly, the server 3 may perform steps S017 and S018 when new support information is stored in the storage unit 31, or may perform steps S017 and S018 when communication is established between the terminal 2 of the person wishing to ride with the server 3. Furthermore, when new support information is stored in the storage unit 31, the server 3 may notify the terminal 2 of the person wishing to ride that the new support information has been stored.

[0055] This allows the driver's terminal 1 to receive in advance the encrypted user information of the passenger wishing to ride with the passenger's terminal 2. Similarly, the passenger wishing to ride with the passenger's terminal 2 can receive in advance the encrypted user information of the driver's terminal 1.

[0056] Next, a merging support system 901 in the event of a disaster will be described with reference to FIG.

[0057] Unlike normal times, the rendezvous support system 901 during a disaster does not require the configuration of the network 5. This is because, during a disaster, the network 5 may be physically disconnected, or even if it is not physically disconnected, communication may be interrupted due to an increase in communication traffic.

[0058] However, if the terminal 4 cannot communicate, it cannot send or receive the vehicle identifier or the passenger wishing to ride with the vehicle or passenger wishing to ride with the passenger. Since the user information is encrypted with the vehicle identifier or the passenger wishing to ride with the passenger identifier, the terminal 4 cannot decrypt the user information if it cannot receive the vehicle identifier or the passenger wishing to ride with the passenger identifier.

[0059] Therefore, short-range wireless communication 6 is used for communication with terminal 4. As shown in Fig. 8, although the communication range of short-range wireless communication 6 is limited, direct communication is possible even if network 5 is down. By transmitting and receiving a vehicle identifier or a passenger wishing to ride with another person identifier using direct communication, terminal 4 can decode user information. Details will be described later.

[0060] Next, the processing flow of the driver's terminal 1 when a disaster occurs will be described with reference to FIG.

[0061] The driver's terminal 1 acquires disaster occurrence information (step S101). Disaster occurrence information is acquired by receiving emergency earthquake alerts, tsunami and weather information, evacuation instructions and forecasts via the communication unit 14, or by analyzing disaster prevention radio and human voices acquired by the input unit 12 with the control unit 10, but it can also be input by the driver to the input unit 12.

[0062] The driver's terminal 1 determines whether the number of passengers in the vehicle driven by the driver is less than the passenger capacity (step S102). If the number of passengers is not less than the passenger capacity, the process ends.

[0063] The number of passengers can be estimated by analyzing images captured by a camera capturing images of the interior of the vehicle, or by the driver inputting the information into the driver's terminal 1. The driver's terminal 1 can also estimate the number of passengers by acquiring the number of times that doors that provide access to seats other than the driver's seat are opened. The driver's terminal 1 can also acquire and analyze voices emitted within the vehicle, and estimate the number of passengers from the content of conversations, tone of voice, etc.

[0064] Furthermore, when the short-range wireless communication 6 is continuously established between the driver's terminal 1 and a terminal other than the driver's terminal while the vehicle is traveling, the number of passengers in the vehicle may be counted up.

[0065] If the number of passengers in the vehicle driven by the driver is less than the passenger capacity, the driver's terminal 1 transmits the vehicle identifier to the surrounding area using short-range wireless communication 6 (step S103).

[0066] Here, since the driver's terminal 1 normally receives the vehicle identifier from the server 3 in step S005 described above, it can transmit the vehicle identifier to the surrounding area even if communication with the server 3 is not possible in the event of a disaster.

[0067] In addition, the ability to communicate using short-range wireless communication 6 means that the terminal 2 of the person wishing to ride with the driver is present within the communication range, and decryption is only possible when such merging is necessary, thereby protecting the driver's user information.

[0068] The driver's terminal 1 determines whether or not the passenger applicant identifier has been received (step S104), and if the passenger applicant identifier has not been received, the process returns to step S103.

[0069] Upon receiving the passenger applicant identifier, the driver's terminal 1 decodes the passenger applicant information using the passenger applicant identifier (step S105).

[0070] By receiving the passenger identifier, the user information can be decoded, thereby preventing unnecessary disclosure of the user information.

[0071] The driver's terminal 1 notifies the driver of the decrypted passenger information (step S106).

[0072] Here, the notification to the driver means a notification by display, audio, vibration, or the like using the terminal 1 of the driver.

[0073] As shown in Fig. 10, the notification by display displays the passenger information on the display unit 13 of the driver's terminal 1. That is, the passenger's face photo, evacuation destination, evacuation route, etc. are displayed. This allows the driver to check the passenger information without operating the terminal 1.

[0074] The audio notification may be made by outputting an evacuation route for the passenger from the driver's terminal 1, or by outputting an audio message indicating that communication with the passenger's terminal 2 has been established. The audio may be an electronic sound such as a beep, or a generated or recorded human voice. This allows the driver to know that communication with the passenger's terminal 2 has been established while driving the car and checking the surroundings in the event of a disaster, without having to check the display unit 13.

[0075] The vibration notification is performed by outputting a vibration from the driver's terminal 1 to indicate that communication with the passenger's terminal 2 has been established. While communication with the passenger's terminal 2 is established, a vibration is output, for example, every two seconds. If the driver's terminal 1 is an in-vehicle device, a command to vibrate an object that is in contact with the driver's body, such as the steering wheel or seat, is output to vibrate. This allows the driver to know that communication with the passenger's terminal 2 has been established without having to check the display unit 13 while driving the car and checking the surroundings in the event of a disaster.

[0076] These notifications are not limited to one, and multiple notifications can be combined.

[0077] The processing flow of the terminal of a passenger who wishes to ride in the event of a disaster will be described using FIG.

[0078] The terminal 2 of the passenger requesting the ride acquires the disaster occurrence information (step S111).

[0079] Acquisition 2 of disaster occurrence information is obtained by receiving emergency earthquake alerts, tsunami and weather information, evacuation instructions and forecasts thereof via the communication unit 24, or by analyzing disaster prevention radio and human voices acquired by the input unit 22 with the control unit 20, but it can also be input into the input unit 22 by people wishing to ride along.

[0080] The terminal 2 of the passenger requesting the ride determines whether the passenger is in the vehicle (step S112).

[0081] If the user is not in the vehicle, the process of step 113 described below is executed, whereas if the user is in the vehicle, the process is terminated.

[0082] If you are in a vehicle when a disaster occurs, you will be considered to have been able to head to the evacuation site, and if you get in a vehicle after the disaster occurs, you will be considered to have been able to head to the evacuation site. If you are not in a vehicle, you will be required to meet up with the driver.

[0083] The terminal 2 of the passenger seeking companion transmits the passenger seeking companion identifier to the surrounding area using short-range wireless communication 6 (step S113).

[0084] Here, since the terminal 2 of the person wishing to ride receives the identifier of the person wishing to ride from the server 3 under normal circumstances in the aforementioned step S015, the terminal 2 can transmit the identifier of the person wishing to ride to the surrounding area even if communication with the server 3 is not possible when a disaster occurs.

[0085] In addition, the ability to communicate using short-range wireless communication 6 means that the driver's terminal 1 is present within the communication range, and decryption is only possible when such merging is necessary, so the driver's user information can be protected.

[0086] The terminal 2 of the passenger wishing to ride with the passenger determines whether or not the vehicle identifier has been received (step S114), and if the vehicle identifier has not been received, the process returns to step S113.

[0087] When the terminal 2 of the passenger seeking companion receives the vehicle identifier, it decodes the support information using the vehicle identifier (step S115).

[0088] By receiving the vehicle identifier, the user information can be decoded, thereby preventing unnecessary disclosure of the user information.

[0089] The terminal 2 of the passenger applicant notifies the passenger applicant of the decrypted support information (step S116).

[0090] Here, the notification to the passenger applicant means a notification by display, audio, vibration, etc. on the terminal 2 of the passenger applicant.

[0091] As shown in Fig. 12, the notification by display displays support information on the display unit 23 of the terminal 2 of the passenger applicant. That is, a photo of the driver's face, vehicle information, evacuation destination, evacuation route, etc. are displayed. This allows the passenger applicant to check the driver's evacuation route, and therefore to know where the vehicle is scheduled to travel without having to thoroughly search the communication range.

[0092] The audio notification may be made from the passenger's terminal 2 by outputting the driver's evacuation route by audio, or by outputting audio indicating that communication with the driver's terminal 1 has been established. The audio may be an electronic sound such as a beep, or a generated or recorded human voice. This allows the passenger to know that communication with the driver's terminal 1 has been established while walking and checking their surroundings in the event of a disaster, without having to check the display unit 23.

[0093] The notification by vibration is made by outputting a vibration from the passenger's terminal 2 indicating that communication with the driver's terminal 1 has been established. While communication with the driver's terminal 1 is established, a vibration is output, for example, every two seconds. This allows the passenger wishing to ride to know that communication with the driver's terminal 1 has been established while walking and checking their surroundings in the event of a disaster, without having to check the display unit 23.

[0094] These notifications are not limited to one, and multiple notifications can be combined.

[0095] As described above, when the driver's terminal 1 is the first terminal and the passenger requesting terminal 2 is the second terminal, the first terminal receives the encrypted user information of the second terminal in advance, detects disaster occurrence information, and, on the condition that the first terminal is able to communicate with the second terminal, decrypts the encrypted user information of the second terminal and makes a notification using the decrypted user information of the second terminal. This is the same even when the passenger requesting terminal 2 is the first terminal and the driver's terminal 1 is the second terminal.

[0096] Furthermore, as described above, multiple terminals 4 can store the same assistance information or passenger information, and therefore, by having multiple terminals receive the passenger identifier or vehicle identifier transmitted by the processing of steps S103 and S113, it is possible to simultaneously provide merging assistance to multiple drivers and passengers.

[0097] In addition, in step S103, the driver's terminal 1 transmits the vehicle identifier to the surrounding area if the number of passengers is below the passenger capacity, so that the processing of step S115 can be executed by the terminals 2 of multiple passengers, and support can be provided for merging with passengers until the passenger capacity is reached.

[0098] The programs and terminals provided by the present invention do not limit the inventions according to the claims, and not all of the combinations of features described in the embodiments are necessarily essential to the solutions of the invention. In addition, details of the embodiments, such as the types of terminals and information, may be changed, added, or omitted as necessary. [Explanation of symbols]

[0099] 1 Driver's terminal 2. Device of passenger wishing to ride 3 Server 4. Terminal 5. Network 6 Near field communication 10, 20, 30, 40 Control section 11, 21, 31, 41 storage section 12, 22, 42 Input section 13, 23, 43 Display section 14, 24, 32, 44 Communications Department 900 Merge Assist System 901 Disaster Merge Support System

Claims

1. A rendezvous support program in the event of a disaster to be executed by a first terminal, the first terminal receives encrypted user information of the second terminal in advance; detecting disaster occurrence information, and decrypting the encrypted user information of the second terminal on the condition that the first terminal is able to communicate with the second terminal; performing a notification using the decrypted user information of the second terminal; A program to support reunification in the event of a disaster.

2. The communication is short-range wireless communication. The meeting support program in the event of a disaster according to claim 1.

3. The decryption uses a second user identifier received from the second terminal. The meeting support program in the event of a disaster according to claim 2.

4. receiving user information encrypted with the second user identifier from the server; The meeting support program in the event of a disaster according to claim 3.

5. The notification displays the decrypted user information of the second terminal on the first terminal. The meeting support program in the event of a disaster according to claim 4.

6. 6. The first terminal that executes the disaster meeting support program according to claim 1.

7. A rendezvous support program in the event of a disaster to be executed by a second terminal, the second terminal transmits user information of the second terminal to a server; receiving a second user identifier from the server; Detecting disaster occurrence information and transmitting the second user identifier to the surrounding area; A program to support reunification in the event of a disaster.

8. The second terminal executes the disaster meeting support program according to claim 7.

Images