JP5606512B2 - Server apparatus and program - Google Patents

Description

The present invention relates to servers instrumentation 置及 beauty program for the sharing of information in such an emergency.

  There is a need for an operation interface that enables smooth information sharing with remote parties (including information terminals) when there is an emergency or when there is not enough room. For example, there are safety confirmation with an acquaintance immediately after the disaster, current location confirmation near the waiting time, status confirmation with the operator at the time of 119 notification immediately after the accident occurrence, and the like.

  However, in the normal state, it is possible to check each other's information while repeating exchanges with the other party, but in an emergency there is no time to check each other's information, They tend to request only the information they want. As a result, there is a problem that the requested partner cannot reply because there is little information related to the self-PROFILE of the requested partner who is required to reply.

  For example, in a safety confirmation system used at the time of a disaster, each person requests the system to return the safety status of an acquaintance, but since each person does not register for safety, there is a problem that safety confirmation cannot be performed even if the safety confirmation system is used. (See Non-Patent Document 1).

Yoshie Hamada, Daisuke Asai, Takehiko Ohno, Yoko Asano, “What information is needed in the event of a disaster? Meeting

  However, in the conventional safety confirmation system with respect to the above problems, the input work takes time and the user's safety is not registered in the safety system unless the user registers his / her safety. Similarly, even when confirming each other's current location, since the current location is not transmitted to the other party while requesting the current location, it is necessary to contact each other for confirming the current location many times. In addition, measures are taken when an accident occurs when 119 is reported after the accident has occurred, but the operator needs to communicate repeatedly in order to grasp the situation of the accident.

The present invention has been made in view of the above circumstances, and its object is to provide a salicylate over server instrumentation 置及 beauty programmable to allow a smooth information shared by a simple operation.

To achieve the above object, according to a first aspect of the present invention, there is provided request data including a request from a request source to a request destination, a request category corresponding to the request, and related information of a request source user related to the request. Receiving means for receiving, registration means for registering related information included in the request data in the database in association with the request category, and sending means for sending the request to the request destination, the sending means comprising : And when the same request category is already requested from the request destination to the request source, the request and related information of the request source user registered in the database are transmitted to the request destination, and the request When the same request is not made from the destination to the request source, only the request is transmitted to the request destination.

According to the first aspect, for example, when confirming each other's current location, the current location of the requesting user can be automatically transmitted to the request destination together with the current location confirmation request to the request destination. By doing so, it is not necessary to contact repeatedly over and over, so it is possible to shorten the communication time for sharing information in an emergency situation where there is no room. In addition, when the request destination and the request source request information of the same request category, it is determined that the registered information may be disclosed to each other, and in the case of other requests, the information is arbitrarily given. Not disclosed. Thereby, privacy can be protected.

According to a second aspect of the present invention, there is provided receiving means for receiving request data including a request from a request source to a request destination and related information of a request source user related to the request, and related information included in the request data. Registration means for registering in the database in association with the request category corresponding to the request, based on whether or not related information of the request destination user corresponding to the request category corresponding to the request is registered in the database, There is provided a server device comprising response means for making a response to the request to the request source.

According to the second aspect, for example, when confirming the safety of each other, if the request has already been received from the request destination, the request destination responds to the request source that the safety has been confirmed. Is possible. Further, when a request is received from the request destination, it is possible to notify the request source that the safety has been confirmed. In this way, it is not necessary to repeatedly contact the user, so that it is possible to share desired information in a short time in a situation where there is no room in an emergency.

That is, according to the present invention, it is possible to provide a salicylate over server instrumentation 置及 beauty programmable to allow a smooth information shared by a simple operation.

The figure which shows the structural example of the information sharing system which concerns on one Embodiment of this invention. The figure which shows the other structural example of the information sharing system which concerns on one Embodiment of this invention. The flowchart which shows the processing content of the request | requirement transmission process part by the side of a terminal. The figure which shows the structural example of terminal DB. The figure which shows an example of the format of the synthesized data. The flowchart which shows the processing content by the side of a cloud server. The flowchart which shows the other example of the processing content by the side of a cloud server. The figure which shows the registration content of cloud DB. The figure which shows the safety confirmation system of Example 1. FIG. 3 is a flowchart illustrating processing contents on the cloud server side according to the first embodiment. 10 is a flowchart illustrating disclosure request processing on the cloud server side according to the second embodiment. 10 is a flowchart illustrating processing contents on the cloud server side according to the third embodiment. 10 is a flowchart illustrating processing contents of a request transmission processing unit on a terminal side according to the fourth embodiment.

Embodiments according to the present invention will be described below with reference to the drawings.
FIG. 1 is a diagram illustrating a configuration example of an information sharing system according to an embodiment of the present invention. This information sharing system configuration is an intermediary between the requesting terminal 1-A, the terminal 1-B that receives a request from the terminal 1-A, and the requesting terminal 1-A and the requesting terminal 1-B. The cloud server 2 is configured. The terminals 1-A and 1-B are configured by, for example, a smartphone that can be connected to the Internet, and the input processing unit 11 that inputs a request through a touch screen, an operation button, or the like, and the request input by the input processing unit 11 A request transmission processing unit 12 on the terminal side that transmits request data including self-PROFILE related to the request to the cloud server 2, a request reception processing unit 13 on the terminal side that receives a response to the request sent from the cloud server 2, And a display processing unit 14 for displaying the received response on the screen. The self-PROFILE indicates a group of information related to the user who owns the terminal.

  The cloud server 2 has an electronic computer (not shown) and a cloud database (cloud DB) 20, and receives a request data sent from a terminal. Self-PROFILE processing unit 22 for registering PROFILE in the cloud DB 20, request response processing unit 23 from the server side that transmits a response to the request to the terminal, and the server side that transmits the received request to the request destination terminal To a request destination terminal.

  Each processing unit is configured by a control program executed by each of the terminals 1-A, 1-B and the cloud server 2, for example. Further, as shown in FIG. 2, the terminal that receives the request and the cloud server 2 may be the same. These configurations are arbitrarily selected depending on the application.

  FIG. 3 is a flowchart showing the processing contents of the request transmission processing unit on the terminal side. The request transmission processing unit 12 on the terminal side of the request source terminal 1-A waits to receive a request sent from the user (processing 200). When the request is received, the self-PROFILE related to the request is extracted from the terminal 1-A (process 201). The extraction method will be described below. As shown in FIG. 4, the terminal 1-A has a terminal DB that stores its own PROFILE corresponding to the request category. For example, the self-PROFILE related to the request category “safety” is “request time, location information obtainable by GPS”. The request transmission processing unit 12 on the terminal side determines the request category from the content of the request, and extracts the self-PROFILE corresponding to the determined request category from the terminal DB. As a method for determining a request category, for example, there is a method in which a request category is set in advance on a button displayed on the screen of the terminal 1-A, and the request category is transmitted when the user presses this button. . Alternatively, there is a method of text mining the content of the request and determining the request category from the extracted words.

  In step 202, the request, the request category (see FIG. 4), and the self-PROFILE corresponding to the request are combined as one data. When combining, a set of data represented in a tag format as shown in FIG. The request is described in the <demand> tag, the request category is described in the <dcategory> tag, and the self-PROFILE is described in the <sprofile> tag. The request transmission processing unit 12 on the terminal side transmits the combined data to the cloud server 2 together with information for specifying the other party (terminal 1-B) (processing 203).

  Next, processing contents on the cloud server side will be described using the flowcharts of FIGS. In the process 300 of FIG. 6, the request reception processing unit 21 on the server side of the cloud server 2 determines whether the request data sent from the request source has been received. When the request data is received, the self-PROFILE processing unit 22 checks in process 301 whether the request data includes the self-PROFILE. The presence / absence of self-PROFILE is determined by the presence / absence of <dcategory>. If there is a self-PROFILE, the self-PROFILE is cut out in processing 302 and the request category and self-PROFILE data are registered in the cloud DB 20 in association with the request time, the requesting telephone number, and the requesting telephone number in processing 303. . FIG. 8 shows the contents registered in the cloud DB 20. In the process 304, the request is transmitted from the server side of the cloud server 2 to the request partner (terminal 1-B) by the request transmission processing unit 24 to the request partner terminal. If the request receiving terminal and the cloud server 2 are the same as shown in FIG. 2, the request response processing unit 23 from the server side to the request sending terminal in step 310 as shown in FIG. A response to the request is transmitted to the terminal 1-A).

  In this way, when transmitting a request to the request destination, the self-PROFILE is transmitted without any additional operation by the requesting user, so that information necessary for communication is automatically stored in the cloud server. The The cloud server presents information using this accumulated information, or discloses the accumulated information, so that emergency communication can be facilitated. Hereinafter, each embodiment in which the information sharing system is applied to a specific system will be described.

(Example 1: Safety confirmation system)
The safety confirmation system according to the first embodiment has the system configuration shown in FIG. In the first embodiment, as illustrated in FIG. 9, a scene is assumed in which the user A and the user B are acquainted and confirm each other's safety. When the occurrence time of the disaster is 16:00, the user A makes a response request for the safety status of the user B at 17:00. As a method for transmitting the response request, there is a safety button in the item of the user C in the address book displayed on the smartphone or the like, and the user presses the button.

  When the safety button is pressed, the process of FIG. 3 operates on the terminal 1-A of the user A. In process 200, the presence or absence of a request is confirmed. If there is a request, the process proceeds to process 201. Process 201 analyzes the request and extracts the self-PROFILE associated with the request. Here, the request category of user A and self-PROFILE (here, current position and time at the time of request) are extracted with respect to “Is user C safe?” As a request for safety. The current location at the time of request is grasped by a GPS sensor or the like. The terminal 1-A combines the request and the extracted self-PROFILE in the process 202, and transmits the request to the cloud server 2 for safety confirmation in the process 203.

  FIG. 10 is a flowchart illustrating the processing contents on the cloud server side according to the first embodiment. FIG. 10 shows details of processing of replying to the request source terminal in processing 310 of FIG. In the process 300 of FIG. 10, when the cloud server 2 receives the request data, the process 301 checks whether or not the self-PROFILE exists in the request data. If there is a self-PROFILE, the self-PROFILE added to the request in the process 302 is cut off, and the self-PROFILE is registered in the cloud DB 20 corresponding to the request source telephone number and the request destination telephone number (process 303). In step 311, a response is transmitted to the request source (user A) based on whether or not the safety confirmation destination (user C) 's own PROFILE is registered in the cloud DB 20. In this case, since the user C's own PROFILE is not yet registered in the cloud DB 20, the reply message to the request source (user A) in this case is “unknown safety of user C” (processing 312).

  Next, it is assumed that the user C transmits a safety confirmation message of the user A to the cloud server 2 at time 18. As in the case of the user A, the cloud server 2 registers the request category and request data of the user C in association with the request source telephone number and the request destination telephone number (process 303). At this time, in the process 311, information when the user A requests safety confirmation from the user C to the cloud server 2 is registered in the cloud server 2. Therefore, the cloud server determines the safety information of the user A based on the registered information. And the message “User A has confirmed safety at 17:00” is transmitted to the user C from the safety confirmation cloud server 2 (process 313).

Further, in FIG. 10, when the cloud server 2 has already transmitted the safety status of the user C to the safety confirmation destination user A in the processes 314 and 315, the safety status of the user C is indicated. Add a function to send a message “Safety Confirmed” to notify you that the confirmation was successful. Since the safety confirmation partner (user C) is registered in the cloud DB 20 at the time of the safety request of the user A, the request response processing unit 23 from the server side to the request transmission terminal responds to the user C in the process 313 and the request partner The request transmission processing unit 24 to the destination terminal creates the safety information of the user C based on the information registered in the cloud DB 20 when confirming the safety from the user C to the user A, and notifies the user A that the safety confirmation has been taken. (Process 315).
From the above, according to the first embodiment, it is possible to realize a system that can collect information functioning as a safety confirmation system without the effort of each user and achieve the purpose of each user confirming safety in a short time.

(Example 2: Health check system between a shelter person and a distant doctor)
The health confirmation system according to the second embodiment uses the system configuration shown in FIG. 1. For example, a person in an evacuation center uses the terminal 1 -A, and a distant doctor uses the terminal 1 -B. There is a self-assessment sheet for grasping one's health condition in evacuation shelter life at the time of a disaster, and the health condition can be grasped daily by using the self-assessment sheet. In addition, a medical history and medical condition can be estimated based on the history of medicines dispensed by a medical institution or pharmacy from a medicine notebook. When a person who has lost physical condition in the evacuation center communicates with a distant doctor, it is preferable that the doctor can advise the countermeasures accurately in a short time. At this time, the request from the person who has lost his / her physical condition to the doctor is, for example, “You are feeling sick. How should you respond?” In response to this request, the terminal 1-A registers a self-assessment sheet, a medicine notebook, etc. (hereinafter referred to as a health life log) in which daily health conditions are recorded in the cloud DB 20 of the cloud server 2 simultaneously with the request. From the terminal 1-B on the doctor side, disclosure of the health life log in the cloud server 2 can be requested to a person who has lost physical condition, and only when the person who has lost physical condition has approved the disclosure, The information of the cloud DB 20 can be browsed.

  The flowchart in FIG. 11 shows disclosure request processing on the cloud server side. In process 400, for example, when there is a disclosure request from the terminal 1-B, the cloud server 2 transmits a disclosure permission application request to the disclosure request destination (terminal 1-A) in process 401. If there is a disclosure permission response from the terminal 1-A in the process 402, and if the response is a disclosure permission in the process 403, the self-assessment sheet registered in the cloud DB 20 in the disclosure request destination (terminal 1-B). Information is disclosed (process 404). On the other hand, if the response is a disclosure non-permission in step 403, a rejection response is sent to the disclosure request destination (terminal 1-B) (step 405).

(Example 3: Current position confirmation system close to waiting time)
The current position confirmation system near the waiting time in the third embodiment has the system configuration shown in FIG. A scene is assumed in which user A and user B confirm each other's current positions in the near-waiting time. For example, a request from the user A to the user B is “Where is the user B?”. As the self-PROFILE for this request, the request time and current position of the user A are extracted and transmitted to the cloud server simultaneously with the request.

  The processing content on the cloud server side of the third embodiment is shown in the flowchart of FIG. In the process 300 of FIG. 12, when the cloud server 2 receives the request data from the terminal 1-A of the user A in the process 300, the cloud server 2 cuts out its own PROFILE (request time, current position) included in the request data (process 301, 302), the request time and the current position are registered in the cloud DB 20 in association with the request category (here, the current position) in association with the request source telephone number and the request destination telephone number of the user A (processing 303). At this time, since the same request is not made from the terminal 1-B of the request destination (user B) to the request source (user A), the cloud server 2 only requests the terminal 1-B of the request destination (user B). Is transmitted (process 322).

  On the other hand, when the user B who has received this request requests the information of the same request category from the user A as a reply, the request destination (user A) has already made the same request to the request source (user B) in the process 321. Therefore, the request and information related to the request (current position of user B) are transmitted to the request destination (user A) (process 323).

  That is, in the third embodiment, when the cloud servers request information of the same request category, the cloud server determines that the registered information may be disclosed to each other, and in the case of other requests, Do not disclose information. Thereby, privacy can be protected.

(Example 4: Self-PROFILE processing using a container)
When the terminal cannot be used due to loss of its own terminal, battery exhaustion, forgetting to take out, etc. at the time of a disaster, and it is desired to carry out the above-mentioned embodiment using another person's terminal, etc. Is used. This card is equipped with NFC (Near Field Communication). By holding the card over another person's terminal, the self-PROFILE registered in the card by wireless communication can be used. The fourth embodiment has the system configuration shown in FIG. The container is not limited to the NFC card, but may be a portable storage medium such as a memory card that can be attached to and detached from the terminal or a USB memory.

  FIG. 13 is a flowchart illustrating request transmission processing on the terminal side according to the fourth embodiment. FIG. 13 is obtained by adding processing 211 and processing 212 to the flowchart of FIG. 3. If there is a request from the user in process 200, the presence or absence of the container is confirmed in process 211. If there is a container in the process 211, the self-PROFILE related to the request is extracted from the container (process 212). Then, the self-PROFILE related to the request and the request extracted from the container is synthesized (process 202), and the synthesized data is transmitted to the cloud server 2 (process 203).

  Note that the present invention is not limited to the above-described embodiment as it is, and can be embodied by modifying the constituent elements without departing from the scope of the invention in the implementation stage. Further, various inventions can be formed by appropriately combining a plurality of constituent elements disclosed in the embodiment. For example, some components may be deleted from all the components shown in the embodiment. Furthermore, you may combine suitably the component covering different embodiment.

  DESCRIPTION OF SYMBOLS 1-A, 1-B ... Terminal, 2 ... Cloud server, 20 ... Cloud DB, 11 ... Input processing part, 12 ... Request transmission processing part on the terminal side, 13 ... Request reception processing part on the terminal side, 14 ... Display processing A request reception processing unit on the server side, 22 a self-PROFILE processing unit, a request response processing unit from the server side to the request transmission terminal, and a request transmission processing unit from the server side to the request destination terminal.

Claims (3)

Receiving means for receiving request data including a request from a request source to a request destination, a request category corresponding to the request, and related information of a request source user related to the request;
Registration means for registering related information included in the request data in a database in association with the request category;
Transmission means for transmitting the request to the request destination ,
The transmission means transmits the request and related information of the request source user registered in the database to the request destination when a request of the same request category has already been made from the request destination to the request source. When the same request is not made from the request destination to the request source, only the request is transmitted to the request destination .   Receiving means for receiving request data including a request from a request source to a request destination and related information of a request source user related to the request;
  Registration means for registering related information included in the request data in a database in association with a request category corresponding to the request;
  A response means for sending a response to the request to the request source based on whether or not related information of the request destination user corresponding to the request category corresponding to the request is registered in the database;
  A server device comprising:   A program for causing a computer to function as each means constituting the server device according to claim 1.

Images