WO2023074192A1 - プログラム、情報処理方法、端末、サーバ - Google Patents

プログラム、情報処理方法、端末、サーバ Download PDF

Info

Publication number
WO2023074192A1
WO2023074192A1 PCT/JP2022/034991 JP2022034991W WO2023074192A1 WO 2023074192 A1 WO2023074192 A1 WO 2023074192A1 JP 2022034991 W JP2022034991 W JP 2022034991W WO 2023074192 A1 WO2023074192 A1 WO 2023074192A1
Authority
WO
WIPO (PCT)
Prior art keywords
terminal
information
user
safety
server
Prior art date
Application number
PCT/JP2022/034991
Other languages
English (en)
French (fr)
Inventor
俊介 岩本
亮介 濱窄
Original Assignee
Ｌｉｎｅ株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from JP2021176907A external-priority patent/JP7354207B2/ja
Priority claimed from JP2021176908A external-priority patent/JP7273124B1/ja
Application filed by Ｌｉｎｅ株式会社 filed Critical Ｌｉｎｅ株式会社
Publication of WO2023074192A1 publication Critical patent/WO2023074192A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • G06Q50/26—Government or public services
    • G—PHYSICS
    • G08—SIGNALLING
    • G08B—SIGNALLING OR CALLING SYSTEMS; ORDER TELEGRAPHS; ALARM SYSTEMS
    • G08B21/00—Alarms responsive to a single specified undesired or abnormal condition and not otherwise provided for
    • G08B21/02—Alarms for ensuring the safety of persons
    • G08B21/10—Alarms for ensuring the safety of persons responsive to calamitous events, e.g. tornados or earthquakes
    • G—PHYSICS
    • G08—SIGNALLING
    • G08B—SIGNALLING OR CALLING SYSTEMS; ORDER TELEGRAPHS; ALARM SYSTEMS
    • G08B25/00—Alarm systems in which the location of the alarm condition is signalled to a central station, e.g. fire or police telegraphic systems
    • G08B25/01—Alarm systems in which the location of the alarm condition is signalled to a central station, e.g. fire or police telegraphic systems characterised by the transmission medium
    • G08B25/04—Alarm systems in which the location of the alarm condition is signalled to a central station, e.g. fire or police telegraphic systems characterised by the transmission medium using a single signalling line, e.g. in a closed loop
    • G—PHYSICS
    • G08—SIGNALLING
    • G08B—SIGNALLING OR CALLING SYSTEMS; ORDER TELEGRAPHS; ALARM SYSTEMS
    • G08B25/00—Alarm systems in which the location of the alarm condition is signalled to a central station, e.g. fire or police telegraphic systems
    • G08B25/01—Alarm systems in which the location of the alarm condition is signalled to a central station, e.g. fire or police telegraphic systems characterised by the transmission medium
    • G08B25/10—Alarm systems in which the location of the alarm condition is signalled to a central station, e.g. fire or police telegraphic systems characterised by the transmission medium using wireless transmission systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/04—Real-time or near real-time messaging, e.g. instant messaging [IM]
    • H04L51/046—Interoperability with other network applications or services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M11/00—Telephonic communication systems specially adapted for combination with other electrical systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M11/00—Telephonic communication systems specially adapted for combination with other electrical systems
    • H04M11/04—Telephonic communication systems specially adapted for combination with other electrical systems with alarm systems, e.g. fire, police or burglar alarm systems

Definitions

  • the present disclosure relates to programs, information processing methods, terminals, servers, and the like.
  • Patent Document 1 There is a technology to issue an alarm using a mobile terminal when a disaster occurs (for example, Patent Document 1).
  • a program executed by a terminal that performs processing related to chatting with a user of a first terminal, based on an input to the first terminal by a user of the first terminal, receiving, by the communication unit of the terminal, first information regarding the safety of the user of the first terminal; and displaying, on the display unit of the terminal, the first information associated with chat information related to the user of the first terminal executed.
  • an information processing method for a terminal that performs processing related to chatting with a user of a first terminal, based on an input to the first terminal by a user of the first terminal, Receiving first information about the user's safety by a communication unit of the terminal, and displaying the first information associated with chat information related to the user of the first terminal on a display unit of the terminal.
  • a terminal that performs processing related to a chat with a user of a first terminal is configured to provide information regarding the safety of the user of the first terminal based on an input to the first terminal by the user of the first terminal.
  • a terminal that performs processing related to chatting with a user of a first terminal comprises a processor that reads a program stored in a memory and executes processing based on the program, the processor comprising: Receiving, by the communication unit of the terminal, first information regarding the safety of the user of the first terminal based on an input to the first terminal by the user of the first terminal, and associating it with chat information related to the user of the first terminal. and displaying the received first information on the display unit of the terminal.
  • a program executed by a server that communicates with a terminal receives, from the first terminal, first information regarding a safety confirmation request for a user of the terminal by a communication unit of the server; Based on the first information and the set condition, the server transmits the second information regarding safety confirmation to the terminal by the communication unit.
  • an information processing method for a server that communicates with a terminal includes receiving, from the first terminal, a first information regarding a safety confirmation request for a user of the terminal by a communication unit of the server; transmitting second information regarding safety confirmation to the terminal by the communication unit based on the information and the set condition.
  • a server that communicates with a terminal receives from the first terminal first information relating to a safety confirmation request to a user of the terminal, and based on the first information and the set condition, confirms safety.
  • a communication unit is provided for transmitting second information regarding confirmation to the terminal.
  • a server that communicates with a terminal includes a processor that reads a program stored in a memory and executes processing based on the program, and the processor includes: 1 information is received from the first terminal by the communication unit of the server, and second information regarding safety confirmation is transmitted to the terminal by the communication unit based on the first information and the set conditions.
  • a program executed by a server that communicates with a terminal receives, from the first terminal, a communication unit of the server first information regarding a request for content transmission to a user of the terminal; transmitting, based on the first information, second information about the content to the terminal by the communication unit; receiving, from the second terminal, the first information for the user of the terminal by the communication unit of the server; and transmitting the second information to the terminal by the communication unit based on the condition.
  • FIG. 4 is a diagram showing an example of functions realized by a control unit of the server according to the first embodiment
  • FIG. 5 is a diagram showing an example of information and the like stored in a storage unit of the server according to the first embodiment
  • FIG. 4 is a diagram showing an example of functions realized by a control unit of the terminal according to the first embodiment;
  • FIG. 5 is a diagram showing an example of functions realized by a control unit of the server according to the first embodiment
  • FIG. 5 is a diagram showing an example of information and the like stored in a storage unit of the server according to the first embodiment
  • the figure which shows an example of the account registration data based on 1st Example The figure which shows an example of the account management database based on 1st Example.
  • FIG. 4 is a diagram showing an example of functions realized by a control unit of the terminal according to the first embodiment;
  • FIG. 4 is a diagram showing an example of information and the like stored in a storage unit of the terminal according to the first embodiment;
  • 4 is a flowchart showing an example of the flow of processing executed by each device according to the first embodiment;
  • FIG 10 is a flowchart showing an example of the flow of processing executed by each device according to the first modified example;
  • the figure which shows an example of the information etc. which are memorize
  • the figure which shows an example of the group management database which concerns on a 1st modification.
  • the figure which shows an example of the screen displayed on the display part of the terminal which concerns on a 1st modification.
  • FIG. 9 is a flowchart showing an example of the flow of processing executed by each device according to the second embodiment
  • FIG. 11 is a flowchart showing an example of the flow of safety confirmation processing according to the second embodiment
  • FIG. FIG. 11 is a diagram showing an example of timing of processing executed by each device according to the second embodiment
  • the figure which shows an example of the screen displayed on the display part of the terminal which concerns on a 2nd modification The figure which shows an example of the screen displayed on the display part of the terminal which concerns on 3rd Example.
  • FIG. 11 is a flow chart showing an example of the flow of processing executed by each device according to the third embodiment; FIG. The figure which shows an example of the screen displayed on the display part of the terminal which concerns on 4th Example. The figure which shows an example of the screen displayed on the display part of the terminal which concerns on 4th Example.
  • FIG. 11 is a diagram showing an example of timing of processing executed by each device according to the fourth embodiment; The figure which shows an example of the screen displayed on the display part of the terminal which concerns on a 4th modification. The figure which shows an example of the timing of the process which each apparatus based on a 4th modification performs.
  • the figure which shows an example of the screen displayed on the display part of the terminal which concerns on 5th Example The figure which shows an example of the screen displayed on the display part of the terminal which concerns on 5th Example.
  • 14 is a flow chart showing an example of the flow of processing executed by each device according to the fifth embodiment;
  • FIG. 11 is a diagram showing an example of timing of processing executed by each device according to the fifth embodiment;
  • the figure which shows an example of the screen displayed on the display part of the terminal which concerns on a 5th modification The figure which shows an example of the screen displayed on the display part of the terminal which concerns on a 5th modification.
  • FIG. 14 is a flowchart showing an example of the flow of processing executed by each device according to the fifth modification
  • FIG. 14 is a flowchart showing an example of the flow of safety registration request processing according to the fifth modification
  • FIG. 12 is a diagram showing an example of timing of processing executed by each device according to the fifth modification
  • FIG. 14 is a flowchart showing an example of the flow of processing executed by each device according to the fifth modification
  • FIG. 14 is a flowchart showing an example of the flow of safety registration request processing according to the fifth modification
  • FIG. 12 is a diagram showing an example of timing of processing executed by each device according to the fifth modification
  • the figure which shows an example of the screen displayed on the display part of the terminal which concerns on a 5th modification The figure which shows an example of the screen displayed on the display part of
  • FIG. 12 is a diagram showing an example of timing of processing executed by each device according to the fifth modification; The figure which shows an example of the screen displayed on the display part of the terminal which concerns on 6th Example.
  • FIG. 11 is a diagram showing an example of timing of processing executed by each device according to the sixth embodiment; The figure which shows an example of the screen displayed on the display part of the terminal which concerns on a 6th modification. The figure which shows an example of the screen displayed on the display part of the terminal which concerns on 7th Example.
  • FIG. 14 is a diagram showing an example of timing of processing executed by each device according to the seventh embodiment; The figure which shows an example of the account management database which concerns on a 7th modification. The figure which shows an example of the screen displayed on the display part of the terminal which concerns on a 7th modification.
  • FIG. 11 is a diagram showing an example of timing of processing executed by each device according to the sixth embodiment; The figure which shows an example of the screen displayed on the display part of the terminal which concerns on a 6th modification. The figure which shows an example
  • FIG. 14 is a diagram showing an example of timing of processing executed by each device according to the seventh modification; The figure which shows an example of the screen displayed on the display part of the terminal which concerns on a 7th modification. The figure which shows an example of the screen displayed on the display part of the terminal which concerns on 8th Example.
  • FIG. 12 is a diagram showing an example of timing of processing executed by each device according to the eighth embodiment; The figure which shows the combination of the 1st safety information and 2nd safety information which concern on 8th Example. The figure which shows an example of the screen displayed on the display part of the terminal which concerns on 9th Example. The figure which shows an example of the screen displayed on the display part of the terminal which concerns on a 9th modification.
  • a system may be configured with a plurality of devices.
  • the plurality of devices may be a combination of devices of the same type, a combination of devices of different types, or a combination of devices of the same type and devices of different types. It should be noted that, by way of example and not limitation, a system can also be considered as a plurality of devices working together to perform some processing.
  • a system involving a client (client device) and a server can be considered, by way of example and not limitation, to be at least one of the following.
  • client device client device
  • server server
  • (1) is a system including, by way of example and not limitation, at least one terminal and at least one server.
  • An example of this is a client-server system.
  • the server is composed of the following devices, for example and not limitation, and may be a single device or a combination of multiple devices.
  • the server includes, by way of example and not limitation, at least one processor (examples and not limitation include: CPU: Central Processing Unit, GPU: Graphics Processing Unit, APU: Accelerated Processing Unit, DSP: Digital Signal Processor (not limited to Instead, as an example, ASIC: Application Specific Integrated Circuit, FPGA: Field Programmable Gate Array), etc.), computer device (processor + memory), control device, arithmetic device, processing device, etc.
  • processor Central Processing Unit
  • GPU Graphics Processing Unit
  • APU Accelerated Processing Unit
  • DSP Digital Signal Processor
  • ASIC Application Specific Integrated Circuit
  • FPGA Field Programmable Gate Array
  • a configuration with a plurality of the same type of one device (as a non-limiting example, CPU + CPU, homogeneous multi-core processor, etc.), or a configuration with a plurality of different types of any one device (as a non-limiting example, CPU + DSP, heterogeneous multi-core processor etc.), or a combination of a plurality of devices (as non-limiting examples, a processor + computer device, a processor + arithmetic device, a plurality of heterogeneous devices, etc.).
  • the processor may be a virtual processor.
  • the processing described in the embodiments is executed by the single device.
  • it may be configured such that one device executes a part of the processing and the other device executes the other processing.
  • the processor when configured with a processor and an arithmetic device, the processor may be configured to perform the first process and the arithmetic device may be configured to perform the second process.
  • each device when a plurality of devices are used, each device may be arranged at a position physically separated from each other.
  • the functions of the server may be provided in the form of PaaS, IaaS, or SaaS in cloud computing as an example and not as a limitation.
  • control unit of the system can be at least one of the control unit of the terminal and the control unit of the server. That is, as an example and not a limitation, any one of (1A) only the control unit of the terminal, (1B) only the control unit of the server, or (1C) both the control unit of the terminal and the control unit of the server may be used in the system. can be a control unit.
  • control and processing performed by the control unit of the system may be performed only by (1A) the control unit of the terminal, or (1B) the control of the server (1C) It may be performed by both the control unit of the terminal and the control unit of the server.
  • (1C) as an example and not a limitation, part of the control performed by the control unit of the system is performed by the control unit of the terminal, and the rest of the control is performed by the control unit of the server. You may do so.
  • the allocation (allocation) of control and the like may be equally divided, or may be allocated at different ratios instead of equally divided.
  • the communication unit of the server when the server is composed of a single device, the communication unit itself provided in the single device may be used. Further, when the server is configured to have a plurality of devices, the communication section of the server may be configured to include each communication section provided in each device.
  • the communication portion of the server may include: It is good also as a concept containing a 1st communication part and a 2nd communication part.
  • (2) can be a system configured by a plurality of servers (hereinafter referred to as a "server system”) as an example and not as a limitation.
  • server system a system configured by a plurality of servers
  • the configuration described above can be similarly applied as the configuration of each server.
  • the control or the like performed by the server system may be performed by (2A) only one server, (2B) only another server, or (2C) one of the plurality of servers. server and another server. Also, in (2C), as an example and not a limitation, one server may perform part of the control performed by the server system, and the remaining control may be performed by another server. good. In this case, the allocation (allocation) of control and the like may be equally divided, or may be allocated at different ratios instead of equally divided.
  • (3) can be, by way of example and not limitation, a system composed of a plurality of terminals.
  • the system may be, by way of example and not limitation, a system such as the following.
  • ⁇ A system in which terminals have server functions (distributed system). This can be accomplished using blockchain technology, by way of example and not limitation.
  • control unit not limited to the control unit, and the same applies to each functional unit such as an input/output unit, a communication unit, a storage unit, and a clock unit that can be components of the system.
  • a system including a terminal and a server (by way of example and not by way of limitation, a client-server system) is illustrated. It is also possible to apply the server system of (2) above as the server.
  • a system including a terminal and a server
  • a system that does not include a server, such as the system of (3) above as an example and not as a limitation.
  • An embodiment in this case can be configured based on the above-described blockchain technology or the like. Specifically, as an example and not a limitation, data stored and managed in a server described in the following embodiments is saved (stored) on a blockchain. The terminal can then generate a transaction to the blockchain, and when the transaction is approved on the blockchain, the data stored on the blockchain can be updated.
  • terminal is not limited to the meaning of a terminal as a client device in a client server. That is, a terminal may include the concept of a device that is not in a client server.
  • the expression "by communication I/F” is used as appropriate. This indicates that, as an example and not a limitation, the device transmits and receives various types of information and data via a communication I/F (via a communication unit) under the control of a control unit (processor or the like). It shall be acceptable.
  • chat service an application for realizing a chat service
  • messages application an application for realizing a messaging service
  • a chat application may, by way of example and not limitation, allow users to chat in a chat room. Chat applications may also, by way of example and not limitation, allow users to make phone calls (eg, voice calls, video calls, etc.).
  • messaging service: MS including instant message service: IMS
  • social networking service SNS.
  • messaging services and social networking services may or may not be distinguished.
  • social networking services may include messaging services.
  • an instant messaging service as an example of a messaging service, an instant messaging service: IMS (Instant Messaging Service).
  • IMS Intelligent Messaging Service
  • An instant messaging application by way of example and not limitation, may allow users to talk in a talk room.
  • instant messaging applications by way of example and not limitation, may allow users to make calls (such as voice or video calls) between users.
  • a chat room (as an example, not a limitation, a talk room) can be a UI (User Interface) or a GUI (Graphical User Interface) that allows each user to view content sent and received between terminals of multiple users. .
  • UI User Interface
  • GUI Graphic User Interface
  • Talk rooms include one-to-one user talk rooms (hereinafter referred to as “one-to-one talk rooms”), group talk rooms including a plurality of users (hereinafter referred to as “group talk rooms”), Talk rooms with users of official accounts (hereinafter referred to as “OA talk rooms”) and the like can be included.
  • the one-on-one chat room may be managed as a chat room for one-to-one users or one-to-one accounts, or managed as a group chat room consisting of two users or two accounts. You may
  • An official account is not a general user's account but a business operator's account (business user's account), and users of this official account also use a terminal similar to a general user's terminal as an example and not a limitation.
  • the server it is possible to send and receive content (messages) to and from other devices.
  • content may be information transmitted from a source to a destination. Also, the content may be one or more pieces of content.
  • Content includes, by way of example and not limitation, text content in the form of text, image content in the form of images (including at least one of still images and moving images), sound content in the form of sound (including voice), etc. shall be included.
  • operation contents such as buttons and icons for user operation, and link contents such as link information (including URI (Uniform Resource Identifier) etc. as an example without limitation) may be included.
  • link information including URI (Uniform Resource Identifier) etc. as an example without limitation
  • Text may include, by way of example and not limitation, at least one of national characters represented by character codes, extended characters, machine-dependent characters, numerals, symbols, graphics and symbols. Note that the text may not include at least one of the characters, extended characters, machine-dependent characters, numerals, symbols, graphics, and symbols described above, and may include other text.
  • An image can include at least one of various types of image information, such as icons, buttons, stamps, pictograms, and banner images, for example and not limitation.
  • a safety confirming service will be exemplified as an example of a service for users to confirm their safety when a disaster (large-scale disaster, etc.) occurs.
  • An application for realizing the safety confirmation service is called a "safety confirmation application”.
  • the safety confirmation application allows users to register information regarding their own safety and to refer to information regarding the safety of other users.
  • a configuration in which a safety confirmation service function is provided as one function of a messaging application (B) A configuration in which an application (integrated application) having a safety confirmation service function and a messaging service function is configured (C) Safety confirmation Form in which the messaging application is configured as an application separate from the application (D) Form in which the safety confirmation application is configured as a single application
  • the safety confirmation service provider can be the same provider as the messaging service provider.
  • the user's account in the messaging application and the user's account in the safety confirmation application can be used as a common account.
  • the user's account in the messaging application and the user's account in the music application can be automatically associated (coordinated).
  • the safety confirmation service provider can be a different provider than the messaging service provider. Further, in the form (C), a process of associating (coordinating) the user's account in the messaging application and the user's account in the safety confirmation application can be performed.
  • first user when a disaster such as a large-scale disaster occurs, one terminal 20 (hereinafter referred to as “terminal” as appropriate) is connected to another terminal 20 (hereinafter, as appropriate “second 1 Terminal”.)
  • Terminal hereinafter, as appropriate "second 1 Terminal”.
  • first user registered safety confirmation information
  • safety confirmation information hereinafter referred to as “safety confirmation information”.
  • Safety confirmation information can be broadly classified into the following three types of information as an example and not as a limitation.
  • the safety status information registered by the user is classified into two classes, "safe” and "dangerous."
  • Safety status information is not limited to two classes.
  • the safety status information may include a class of "unknown” indicating that the safety is unknown and a class of "outside area” indicating that the person is outside the affected area of the disaster.
  • Safety comment information Content information, such as a message regarding safety, for communicating the user's safety.
  • the safety comment information is text.
  • the safety comment information may be audio, video, icons, or the like, for example, not limitation.
  • Safety location information Information about the location of the user who registers safety confirmation information is defined as an area defined by an address (as an example, not as a limitation, a municipality).
  • the safety location information may be, for example and not limitation, location coordinates defined by latitude and longitude, or areas connected by location coordinates defined by latitude and longitude. Also, the safety location information may include information about altitude.
  • the safety confirmation information preferably includes at least safety status information or safety comment information. However, it is not limited to this.
  • the safety confirmation information on the display screen may be displayed in Japanese, or may be displayed in another language (English, etc.).
  • “safe” may be displayed as “Safe”, danger (unsafe) as “Danger” or “Not Safe”, out of area as “Not IN Area”, and the like.
  • safety confirmation account a user account that registers safety confirmation information
  • safety reference account a user account that refers to "safety information” based on the registered safety confirmation information
  • one user account can serve as both a safety registration account and a safety reference account.
  • a business operator that provides a messaging service using a messaging application is referred to as a “messaging service provider”.
  • the messaging service provider can also be expressed as a provider of messaging applications or a provider of the server 10 . It can also be expressed as a messaging service provider in the sense of a provider of messaging services.
  • the messaging application can be configured so that one-to-one talk can be conducted between accounts registered on the server 10 as friends.
  • a group including two or more accounts may be configured so that group talk can be conducted between the accounts included in the group.
  • the messaging application can be configured so that, for example and not limitation, a list of messages sent to one user account can be checked as a talk list.
  • safety information As a format for displaying information for confirming safety confirmation information registered by the user (hereinafter referred to as "safety information" as appropriate) on each terminal 20, the following configuration in the messaging application is an example, not a limitation: There is a format to be displayed in the requirements. (B1) Show in friend list (B2) Show in talk list (B3) Show in talk room
  • association between users "accounts”
  • friends in the messaging service will be mainly exemplified below, but the association is not limited to this.
  • SNS “follow” indicating other users (accounts) that you have registered because you are interested in yourself, or other users (accounts) that you have registered because you are interested in yourself Relationships such as "followers” that indicate are associated with users (accounts) can also be included.
  • a list of users in a "follow” relationship and a list of users in a “follower” relationship can be associated with the configuration requirement (B1).
  • a list of posts by users in a “following” relationship (“timeline” as an example, not a limitation) can be associated with the configuration requirement (B2).
  • a post to a specific user (“direct message” as an example, not a limitation) on an SNS can be associated with the configuration requirement (B3).
  • FIG. 1-1 is a diagram showing an example of a system configuration of a communication system 1 according to an embodiment of the present disclosure.
  • a server 10 and a plurality of terminals 20 are connected via a network 30 as an example and not a limitation.
  • the server 10 has a function of providing a predetermined service (eg, without limitation, a messaging service, a safety confirmation service, etc.) to the terminal 20 owned by the user via the network 30 .
  • Server 10 may also be referred to as a messaging server, a safety confirmation server, and the like, by way of example and not limitation.
  • users of the server 10 are messaging service providers (operators) and safety confirmation service providers (operators).
  • the number of servers 10 and the number of terminals 20 connected to the network 30 are not limited.
  • the terminal 20 may be any information processing terminal capable of realizing the functions described in each embodiment.
  • Terminal 20 includes, by way of example and not limitation, smart phones, mobile phones (feature phones), computers (including but not limited to desktops, laptops, tablets, etc.), media computer platforms (including but not limited to cable, satellite set top boxes, digital video recorders), handheld computer devices (as non-limiting examples include PDA (personal digital assistant), email clients, etc.), wearable terminals (glasses-type devices, watch-type devices, etc.), VR (Virtual Reality) Including terminals, smart speakers (devices for voice recognition), or other types of computers or communication platforms.
  • the terminal 20 may be expressed as an information processing terminal.
  • terminal 20A, terminal 20B and terminal 20C may be identical, by way of example and not by way of limitation. Further, if necessary, the terminal used by the user X may be expressed as the terminal 20X, and the user information in a predetermined service associated with the user X or the terminal 20X may be expressed as the user information X. It doesn't have to be.
  • the user information is user information associated with an account used by the user in a predetermined service.
  • User information includes, by way of example and not limitation, user's name, user's icon image, user's age, user's gender, user's address, user's hobbies, entered by the user or provided by a given service It may include information associated with the user, such as preferences, user identifiers, etc., and may or may not be any one or combination of these.
  • the network 30 serves to connect one or more terminals 20 and one or more servers 10 . That is, the network 30 means a communication network that provides a connection path so that the various devices can transmit and receive data after being connected.
  • Network 30 may include, by way of example and not limitation, an ad hoc network, an intranet, an extranet, a virtual private network (VPN), a local area network (LAN), a wireless LAN (WLAN), wide area network (WAN), wireless WAN (WWAN), metropolitan area network (MAN), part of the Internet, Public Switched Telephone Network (Public) Switched Telephone Network (PSTN), mobile phone network, ISDN (integrated service digital networks), wireless LAN, LTE (long term evolution), CDMA (code division multiple access), Bluetooth (registered trademark), satellite communication, etc., or a combination of two or more thereof.
  • Network 30 may include one or more networks 30 .
  • the server 10 (not limited to, but an example of a server, an information processing device, or an information management device) has a function of providing a predetermined service to the terminal 20 .
  • the server 10 may be any information processing device capable of realizing the functions described in each embodiment.
  • Server 10 includes, by way of example and not limitation, server devices, computers (including but not limited to desktops, laptops, tablets, etc.), media computer platforms (including but not limited to cable, satellite set-top boxes, digital video recorders, etc.). ), handheld computing devices (by way of example and not limitation, PDAs, email clients, etc.), or other types of computers or communication platforms.
  • the server 10 may be expressed as an information processing device. If there is no need to distinguish between the server 10 and the terminal 20, the server 10 and the terminal 20 may or may not be represented as information processing devices.
  • FIG. 1-1 shows an example of the HW configuration of the terminal 20.
  • the terminal 20 includes a control unit 21 (CPU: central processing unit (central processing unit)), a storage unit 28, a communication I/F 22 (interface), an input/output unit 23, a clock unit 29A, and a position calculation information detection unit 29B.
  • Each component of the HW of terminal 20 is interconnected via bus B, by way of example and not limitation.
  • bus B by way of example and not limitation.
  • the HW configuration of the terminal 20 does not necessarily include all the components.
  • terminal 20 may or may not be configured for individual or multiple components to be removed.
  • the communication I/F 22 transmits and receives various data via the network 30. Communication may be performed by wire or wirelessly, and any communication protocol may be used as long as mutual communication can be performed.
  • the communication I/F 22 has a function of executing communication with various devices such as the server 10 via the network 30 . Communication I/F 22 transmits various data to various devices such as server 10 according to instructions from control unit 21 . The communication I/F 22 also receives various data transmitted from various devices such as the server 10 and transmits the data to the control unit 21 . Also, the communication I/F 22 may be simply referred to as a communication section. Moreover, when the communication I/F 22 is configured by a physically structured circuit, it may be expressed as a communication circuit.
  • the input/output unit 23 includes a device for inputting various operations to the terminal 20, a device for outputting processing results processed by the terminal 20, and the like.
  • the input unit and the output unit may be integrated, the input unit and the output unit may be separated, or not.
  • the input unit is realized by any one or a combination of all types of devices that can receive input from the user and transmit information related to the input to the control unit 21 .
  • the input unit includes, but is not limited to, hardware keys such as a touch panel, a touch display, and a keyboard, a pointing device such as a mouse, a camera (operation input via moving images), and a microphone (operation input by voice).
  • the output unit is realized by any one or a combination of all types of devices capable of outputting the processing results processed by the control unit 21.
  • the output unit includes, as non-limiting examples, a touch panel, a touch display, a speaker (audio output), a lens (as non-limiting examples, 3D (three dimensions) output and hologram output), a printer, and the like.
  • the input/output unit 23 includes a display unit 24, a sound input unit 25, a sound output unit 26, and an imaging unit 27 as an example and not a limitation.
  • the display unit 24 is realized by any one or a combination of all kinds of devices capable of displaying according to the display data written in the frame buffer.
  • the display unit 24 includes a touch panel, a touch display, a monitor (as a non-limiting example, a liquid crystal display and an OELD (organic electroluminescence display)), a head mounted display (HDM: Head Mounted Display), projection mapping, and a hologram. , including devices capable of displaying images, text information, etc. in air (which may or may not be a vacuum). Note that these display units 24 may or may not be capable of displaying display data in 3D.
  • the sound input unit 25 is used to input sound data (including voice data; the same applies hereinafter). Sound input unit 25 includes a microphone and the like.
  • the sound output unit 26 is used for outputting sound data. Sound output unit 26 includes a speaker and the like.
  • the imaging unit 27 is used to acquire image data (including still image data and moving image data; the same applies hereinafter). The imaging unit 27 includes a camera and the like.
  • the input/output unit 23 is a touch panel
  • the input/output unit 23 and the display unit 24 may be arranged facing each other with substantially the same size and shape.
  • the clock unit 29A is a built-in clock of the terminal 20 and outputs time information (timekeeping information).
  • the clock unit 29A is configured with a clock using a crystal oscillator or the like, for example and not limitation.
  • the clock unit 29A can also be expressed as a clock unit or a time information detection unit as an example and not as a limitation.
  • the clock unit 29A may or may not have a clock to which the NITZ (Network Identity and Time Zone) standard or the like is applied.
  • NITZ Network Identity and Time Zone
  • the position calculation information detection unit 29B has a function of detecting (measuring) information necessary for the control unit 21 to calculate (measure) the position of its own terminal 20 (hereinafter referred to as “position calculation information”). Department.
  • the position calculation information detection section 29B can also be expressed as a position calculation sensor section as an example and not as a limitation.
  • the position calculation information detection unit 29B includes, as a non-limiting example, a satellite positioning sensor (satellite positioning sensor) which is a sensor or unit for calculating the position of the terminal 20 using a satellite positioning system such as GPS (Global Positioning System). unit), an inertial measurement sensor (inertial measurement unit (IMU (Inertial Measurement Unit))), which is a sensor or unit for calculating the position of the terminal 20 using an inertial navigation system, UWB (ultra wideband radio: Ultra Wide A UWB positioning sensor (UWB positioning unit), etc., which is a sensor or unit for calculating the position of the terminal 20 using a band).
  • satellite positioning sensor satellite positioning sensor
  • IMU Inertial Measurement Unit
  • UWB ultra wideband radio: Ultra Wide A UWB positioning sensor (UWB positioning unit)
  • the satellite positioning unit includes, as a non-limiting example, an RF receiving circuit that converts RF (Radio Frequency) signals including positioning satellite signals transmitted from positioning satellites received by an antenna (not shown) into digital signals, Positioning satellite signals are acquired by performing correlation calculation processing, etc. on the digital signals output from the RF receiving circuit, and information such as satellite orbit data and time data extracted from the positioning satellite signals is used as position calculation information. It has a baseband processing circuit for output.
  • RF Radio Frequency
  • the inertial measurement unit has an inertial sensor that detects information necessary to calculate the position of the terminal 20 by inertial navigation calculation.
  • inertial sensors include, but are not limited to, triaxial acceleration sensors and triaxial gyro sensors. The acceleration detected by the acceleration sensor and the angular velocity detected by the gyro sensor are used as position calculation information. Output.
  • the UWB positioning unit converts an ultra-wideband RF (Radio Frequency) signal including an ultra-wideband pulse signal for positioning transmitted from a positioning beacon received by an antenna (not shown) into a digital signal. It has a wideband RF receiving circuit, a relative position calculation processing circuit that calculates the relative position between the terminal 20 and the positioning beacon based on the digital signal output from the ultra-wideband RF receiving circuit, and the like.
  • the UWB positioning unit may cause the terminal 20 to function as a positioning beacon by transmitting an ultra-wideband RF signal including a positioning ultra-wideband pulse signal from an antenna (not shown), You don't have to.
  • control unit 21 calculates the position of its own terminal 20 at regular timings or specific timings based on the position calculation information detected by the position calculation information detection unit 29B.
  • the position of the terminal is called “terminal position”
  • the calculated terminal position is called “calculated terminal position”.
  • the control unit 21 may or may not associate the calculated terminal position with the date and time when the calculated terminal position was calculated and store it in the storage unit 28 as calculated terminal position history data.
  • the control unit 21 comprises, by way of example and not limitation, a hardware built-in data processing device comprising physically structured circuitry for carrying out the functions implemented by the code or instructions contained within the program. It is realized by Therefore, the control unit 21 may or may not be expressed as a control circuit.
  • Control unit 21 includes, by way of example and not limitation, a central processing unit (CPU), microprocessor, processor core, multiprocessor, ASIC (application-specific integrated circuit), FPGA (field programmable gate array).
  • CPU central processing unit
  • microprocessor processor core
  • multiprocessor multiprocessor
  • ASIC application-specific integrated circuit
  • FPGA field programmable gate array
  • the storage unit 28 has a function of storing various programs and various data required for the terminal 20 to operate.
  • the storage unit 28 includes, as non-limiting examples, various storage media such as HDD (hard disk drive), SSD (solid state drive), flash memory, RAM (random access memory), ROM (read only memory). Also, the storage unit 28 may or may not be expressed as a memory.
  • the terminal 20 stores the program P in the storage unit 28, and by executing this program P, the control unit 21 executes processing as each unit included in the control unit 21. That is, the program P stored in the storage unit 28 causes the terminal 20 to implement each function executed by the control unit 21 . Also, this program P may or may not be expressed as a program module.
  • FIG. 1-1 shows an example of the HW configuration of the server 10.
  • the server 10 includes a control section 11 (CPU), a storage section 15 , a communication I/F 14 (interface), an input/output section 12 and a clock section 19 .
  • Each component of the HW of server 10 is interconnected via bus B, by way of example and not limitation.
  • bus B bus B
  • the HW of the server 10 does not have to include all components as the HW configuration of the server 10 .
  • the HW of server 10 may or may not be configured to remove individual components or multiple components.
  • the control unit 11 comprises, by way of example and not limitation, a hardware built-in data processing device comprising physically structured circuitry for carrying out the functions implemented by the code or instructions contained within the program. It is realized by
  • the control unit 11 is typically a central processing unit (CPU), and may or may not be a microprocessor, processor core, multiprocessor, ASIC, or FPGA. In the present disclosure, the controller 11 is not limited to these.
  • the storage unit 15 has a function of storing various programs and various data required for the server 10 to operate.
  • the storage unit 15 is realized by various storage media such as HDD, SSD, and flash memory. However, in the present disclosure, the storage unit 15 is not limited to these. Also, the storage unit 15 may or may not be expressed as a memory.
  • the communication I/F 14 transmits and receives various data via the network 30. Communication may be performed by wire or wirelessly, and any communication protocol may be used as long as mutual communication can be performed.
  • the communication I/F 14 has a function of executing communication with various devices such as the terminal 20 via the network 30 . Communication I/F 14 transmits various data to various devices such as terminal 20 according to instructions from control unit 11 . The communication I/F 14 also receives various data transmitted from various devices such as the terminal 20 and transmits the data to the control unit 11 . Also, the communication I/F 14 may be simply referred to as a communication unit. Moreover, when the communication I/F 14 is configured by a physically structured circuit, it may be expressed as a communication circuit.
  • the input/output unit 12 includes a device for inputting various operations to the server 10, a device for outputting processing results processed by the server 10, and the like.
  • the input unit and the output unit may be integrated, the input unit and the output unit may be separated, or not.
  • the input unit is realized by any one or a combination of all types of devices that can receive input from the user and transmit information related to the input to the control unit 11.
  • the input unit is realized by hardware keys typically represented by a keyboard and a pointing device such as a mouse. Note that the input unit may or may not include a touch panel, a camera (operation input via a moving image), and a microphone (operation input by voice) as examples, not limitation.
  • the output unit is realized by any one or a combination of all types of devices capable of outputting the processing results processed by the control unit 11.
  • the output unit includes, as non-limiting examples, a touch panel, a touch display, a speaker (sound output), a lens (as non-limiting examples, 3D (three dimensions) output and hologram output), a printer, and the like.
  • the input/output unit 12 includes the display unit 13 as an example and not as a limitation.
  • the display unit 13 is realized by a display or the like.
  • the display is typically implemented by a monitor (for example, but not by way of limitation, a liquid crystal display or an organic electroluminescence display (OELD)).
  • OELD organic electroluminescence display
  • the display may or may not be a head mounted display (HDM) or the like. These displays may or may not be capable of displaying display data in 3D. In the present disclosure, displays are not limited to these.
  • the clock unit 19 is an internal clock of the server 10 and outputs time information (timekeeping information).
  • the clock unit 19 includes, for example and not limitation, an RTC (Real Time Clock) as a hardware clock, a system clock, and the like.
  • the clock unit 19 can also be expressed as a clock unit or a time information detection unit as an example and not as a limitation.
  • (3) Others The server 10 stores the program P in the storage unit 15 and executes the program P so that the control unit 11 executes processing as each unit included in the control unit 11 . That is, the program P stored in the storage unit 15 causes the server 10 to implement each function executed by the control unit 11 .
  • This program P may or may not be expressed as a program module. The same is true for other devices.
  • control unit 21 of the terminal 20 and/or the control unit 11 of the server 10 is not only a CPU having a control circuit, but also an integrated circuit (IC (Integrated Circuit) chip, LSI (Large Scale Integration)) or the like. Each process may or may not be implemented by a logic circuit (hardware) or a dedicated circuit. Also, these circuits may be realized by one or more integrated circuits, and the plurality of processes shown in each embodiment may or may not be realized by one integrated circuit. LSIs are also called VLSIs, super LSIs, ultra LSIs, etc., depending on the degree of integration. Therefore, the control unit 21 may or may not be expressed as a control circuit.
  • IC Integrated Circuit
  • LSI Large Scale Integration
  • the program P of each embodiment of the present disclosure may be provided in a state stored in a computer-readable storage medium, It does not have to be.
  • the storage medium can store the program P in a "non-transitory tangible medium".
  • the program P may or may not be for realizing part of the functions of each embodiment of the present disclosure.
  • the function of each embodiment of the present disclosure may or may not be a so-called difference file (difference program) that can be realized in combination with a program P already recorded on a storage medium.
  • the program of the system mentioned above is a program that can be executed by the entire system.
  • This program may be composed of a program for each device that constitutes the system. Programs stored in individual devices may be different. In other words, the programs do not have to be common to the individual devices that make up the system.
  • the system consists of a terminal and a server, let the program of the system be P1.
  • P2 and P3 are for executing system programs, and may be different programs.
  • the program P2 stored in the terminal is a program that performs a first process and sends the results of the first process to the server
  • the program P3 that is stored in the server is a program that receives
  • the program may be a program that performs a second process on the result of the first process and transmits the result of the second process to the terminal.
  • the storage medium may include one or more semiconductor-based or other integrated circuits (ICs) (such as, by way of example and without limitation, field programmable gate arrays (FPGAs) or application specific ICs (ASICs)), hard Disk drive (HDD), hybrid hard drive (HHD), optical disk, optical disk drive (ODD), magneto-optical disk, magneto-optical drive, floppy diskette, floppy disk drive (FDD), magnetic tape, solid state It may include a drive (SSD), RAM drive, secure digital card or drive, any other suitable storage medium, or any suitable combination of two or more thereof.
  • Storage media may, where appropriate, be volatile, nonvolatile, or a combination of volatile and nonvolatile. Note that the storage medium is not limited to these examples, and any device or medium that can store the program P may be used. Also, the storage medium may or may not be expressed as memory.
  • the server 10 and/or the terminal 20 can implement the functions of the plurality of functional units shown in each embodiment.
  • the program P of the present disclosure may or may not be provided to the server 10 and/or the terminal 20 via any transmission medium (communication network, broadcast wave, etc.) capable of transmitting the program.
  • the server 10 and/or the terminal 20 implement the functions of the plurality of functional units shown in each embodiment by executing a program P downloaded via the Internet or the like.
  • Each embodiment of the present disclosure can also be implemented in the form of a data signal in which the program P is embodied by electronic transmission.
  • At least part of the processing in the server 10 and/or the terminal 20 may or may not be realized by cloud computing configured by one or more computers.
  • At least part or all of the processing in the terminal 20 may or may not be performed by the server 10 .
  • the server 10 may or may not perform at least some or all of the processing of the functional units of the control unit 21 of the terminal 20 .
  • At least part or all of the processing in the server 10 may or may not be performed by the terminal 20 .
  • the terminal 20 may or may not perform at least some or all of the processing of the functional units of the control unit 11 of the server 10 .
  • the configuration of determination in the embodiments of the present disclosure is not essential, and predetermined processing is performed when the determination condition is satisfied, or predetermined processing is performed when the determination condition is not satisfied. may or may not.
  • script languages such as ActionScript and JavaScript (registered trademark), compiler languages such as Objective-C and Java (registered trademark), markup languages such as HTML Living Standard, and the like, for example and not limitation. implemented using script languages such as ActionScript and JavaScript (registered trademark), compiler languages such as Objective-C and Java (registered trademark), markup languages such as HTML Living Standard, and the like, for example and not limitation. implemented using script languages such as ActionScript and JavaScript (registered trademark), compiler languages such as Objective-C and Java (registered trademark), markup languages such as HTML Living Standard, and the like, for example and not limitation. implemented using script languages such as ActionScript and JavaScript (registered trademark), compiler languages such as Objective-C and Java (registered trademark), markup languages such as HTML Living Standard, and the like, for example and not limitation. implemented using script languages such as ActionScript and JavaScript (registered trademark), compiler languages such as Objective-C and Java (registered trademark), markup languages such as HTML Living Standard, and the like, for example and not limitation. implemented
  • FIG. 1-2 is a diagram showing an example of functions realized by the control unit 11 of the server 10 in this embodiment.
  • the control unit 11 includes, as a functional unit, an application management processing unit 111 for executing application management processing according to an application management processing program 151 stored in the storage unit 15 as an example and not limitation.
  • FIG. 1-3 is a diagram showing an example of information stored in the storage unit 15 of the server 10 in this embodiment.
  • the storage unit 15 stores an application management processing program 151 to be executed as application management processing, account registration data 153, and an account management database 155 as an example and not limitation.
  • the account registration data 153 is registration data relating to the account of the application (messaging application in this embodiment), and an example of the data configuration is shown in FIG. 1-4.
  • the account registration data 153 stores, for example and not limitation, a user name, an application ID, and other registration information in association with each other.
  • the user name is the name of the account of the terminal 20 that uses this application, and as an example, not as a limitation, the name that the user of the terminal 20 registers when using the application is stored.
  • the application ID is information used to identify the account of the application, or the account itself. This application ID is preferably a unique value for each account, and as an example and not a limitation, the server 10 sets and stores a unique value (unique value) for each account.
  • the application ID is information associated with the terminal 20 or the user of the terminal 20, and is an example of information about the terminal or information about the user of the terminal.
  • the other registration information includes, for example and not limitation, identification information for identifying the terminal 20, the telephone number of the terminal 20 (terminal telephone number), the e-mail address (terminal e-mail address), and the Various information such as authentication information such as a password (login password, authentication password, etc.) can be included.
  • the identification information for identifying the terminal 20 may be, by way of example and not by way of limitation, a terminal ID (by way of example and not by way of limitation, IMEI (International Mobile Equipment Identity)).
  • the identification information for identifying the user of the terminal 20 can be an application ID for general users or an application ID for official users, for example and not limitation.
  • one application ID may be used as an identification (login) target, and applications may be activated simultaneously on a plurality of terminals 20, or may not be so.
  • information such as a terminal telephone number can be stored in the account registration data 153 instead of storing ID information such as an application ID in the account registration data 153 .
  • ID information such as the application ID may be associated with the information such as the terminal telephone number on a one-to-one basis. It doesn't have to be.
  • the term may be substantially synonymous with "account terminal”.
  • the account management database 155 is a database for managing information relating to accounts registered in the account registration data 153, and an example data configuration of the account management database 155A is shown in FIG. 1-5.
  • Account management data is stored in the account management database 155A as management data for each account.
  • Each account management data stores an application ID, friend management data, and safety registration data, for example and not limitation.
  • the application ID is information for identifying the account managed by the account management data, and as an example, not limitation, the application ID registered in the account registration data 153 is stored.
  • the friend management data is data for storing the account of this application ID and the application IDs of the accounts that are friends.
  • the server manages the name of the user who registered as a friend.
  • Application IDs are added and updated.
  • Safety registration data is data for storing safety-related registration associated with the account of this application ID, and safety status information is stored as an example, not as a limitation.
  • Safety registration data for each account may be changeable based on user input such as user operations on the terminal 20, for example and not limitation.
  • As an initial value (default) of the safety registration data as an example, not a limitation, information indicating that the server 10 has not received the safety confirmation information (as an example, not a limitation, ""Unknown” flag) can be preset.
  • safety registration data any combination of safety status information, safety comment information, and safety location information among the safety confirmation information registered by the terminal 20 of this account may be associated and stored. .
  • FIG. 1-6 is a diagram showing an example of functions realized by the control unit 21 of the terminal 20 in this embodiment.
  • the control unit 21 includes, as a functional unit, an application processing unit 211 for executing application processing according to an application processing program 281 stored in the storage unit 28, for example and not limitation.
  • FIG. 1-7 is a diagram showing an example of data and the like stored in the storage unit 28 of the terminal 20 in this embodiment.
  • the storage unit 28 stores an application processing program 281 to be executed as application processing and an application ID 283 corresponding to the terminal 20 or the account of the user of the terminal 20, as an example and not a limitation.
  • the friend management data of the account management database 155A may be synchronized and stored in the storage unit 28 of the terminal 20 .
  • the display screen in this embodiment illustrates an example of registering only safety status information as safety confirmation information.
  • the terminal 20 is a smart phone having a vertically long display unit 24 will be illustrated.
  • the smartphone has a touch panel that functions as an input unit facing the display, and this constitutes a touch screen.
  • a touch panel that functions as an input unit facing the display, and this constitutes a touch screen.
  • transition of display screens described below is merely an example of the transition of display screens for realizing the method of the present disclosure.
  • the display of a part of the display screens may be omitted, or another display screen may be added.
  • 1-8 to 1-10 are diagrams showing an example of screen transitions displayed on the display unit 24 of the terminal 20 in this embodiment.
  • ⁇ Safety registration account User Y. of terminal 20Y.
  • Account of Y an example of a user of the first terminal, not limited
  • Safety reference account user X.Y of terminal 20X
  • An example of a display screen for account X an example of a terminal user, not a limitation
  • Fig. 1-8 The left side of Fig. 1-8 is the home screen of a messaging application (not limited to, but an example of a chat application), and in the top center of the screen, the text "Messaging App" is displayed as the name of the messaging application.
  • An icon image and a user name (“user Y.Y” in this example) of the messaging application of the user of the terminal 20Y are displayed on the right part of the top of the screen.
  • an area indicating the current position, page, etc. within the messaging application (hereinafter collectively referred to as “in-app location display area”) is configured.
  • the home screen the characters "home” are displayed.
  • Beneath the in-app location display area is a disaster information display area that displays disaster information to notify that a disaster has occurred.
  • Disaster information (as a non-limiting example, map information indicating the epicenter, the characters “disaster occurrence", the characters “20XX/08/04 09:39 announcement”, and the characters “maximum seismic intensity: 5 upper” , "Hypocenter: Off Ibaraki Prefecture” and "Magnitude: 6.5") are displayed.
  • a safety registration button BT1 indicated by an icon containing characters of "safety registration” for performing safety registration (registration of safety confirmation information) for each account of the messaging application. is displayed.
  • the friend/group list display area displays a list of friends and groups in the messaging application.
  • the friend/group list display area includes a friend list for displaying a list of friends of the account of this terminal 20 ("User Y.Y" in this example) and the account of this terminal 20 as a member.
  • a group list for displaying a list of groups is configured to be displayed.
  • the friends list is tapped and displayed in an expanded state.
  • the group list contains, by way of example and not limitation, the word "group” and the user Y.
  • the number of groups to which Y belongs (“8” in this example) is displayed.
  • the friends list below it, the characters “friends” and the user Y.Y.
  • the number of users (accounts) Y has registered as friends (“4" in this example) is displayed.
  • the group list or friend list When the user taps the group list or friend list, those lists are expanded and displayed. Specifically, by way of example and not limitation, below the group list, the group icon, group name, and number of members belonging to the group are listed as group list items. Also, by way of example and not limitation, below the friends list, the friends' icons and user names are listed as items in the friends list.
  • user X. is displayed as an item in the friend list.
  • a list of icons, user names, etc. corresponding to D is displayed.
  • a display such as that shown in the center of FIG. 1-8 is provided as a non-limiting example.
  • a safety registration area R1 for registering (setting) one's own safety information is superimposed on the home screen on the left side of FIG. 1-8.
  • a message in this example, the characters "Register Safety” and the characters “Let's inform everyone about your safety" is displayed to prompt the user to register (set) safety information.
  • a safety button SBT in this example, a button with a smile icon and the word "safe” for setting safety as safety information, and setting unsafe as safety information.
  • a button indicated by an icon of a non-smiling face and the letters "danger” and a registration button BT3 for setting the selected safety information are displayed.
  • a user X.Y who is friends with Y. X's terminal 20X displays, by way of example and not limitation, a screen such as that shown on the right side of FIG. 1-8.
  • FIG. 1-8 An example of the home screen displayed on the display unit 24 of the terminal 20X is shown on the right side of FIG. 1-8.
  • a list of icons, user names, etc. corresponding to B is displayed.
  • Y If Y has set "safety” as safety information, user Y.Y.
  • An icon SIC1 indicating safety is superimposed on the Y icon.
  • FIG. 1-9 shows the same user Y.S. It is an example of the home screen in Y's terminal 20Y.
  • the user X.D As an example and not a limitation, a screen as shown in the center of FIG. 1-9 is displayed on the display unit 24 of the terminal 20X of X.
  • the display transitions to the talk list screen on the right side of FIG. 1-9 as an example and not a limitation. do.
  • the talk list screen can be a screen that enables confirmation of a list of talk rooms to which messages have been sent to the terminal 20X, for example and not limitation.
  • the words "talk” and a return button indicated by the character " ⁇ " for returning to the previous screen are displayed based on the fact that it is the talk list screen. ing.
  • Each talk room and its corresponding talk room list item include the icon of the talk room (hereinafter referred to as "talk room icon"), the name of the talk room, and the name of the talk room. If it is, the number of members is associated and displayed.
  • the talk room icon can be the icon of the user to talk with. It can be an icon (group icon).
  • the name of the chat partner can be used as an example without limitation, and in the case of a group talk room, the name of the group can be used as an example without limitation. .
  • the chat room list item is user Y.
  • a talk room list item corresponding to the talk room with user A.Y hereinafter referred to as a talk room list item of "user Y.Y" and user A.Y.
  • A's talk room list entry and user B.A. B's talk room list items and the like are displayed.
  • each talk room list item is configured to be associated with, by way of example and not limitation, the number of messages that are in an unread state.
  • user Y.Y In the talk room of terminal 20X, the user X.Y. Based on the fact that there is one message for which user X is unread (not viewed by user X), user Y. The Y talk room list item is displayed in association with the number "1".
  • the talk room icon is ⁇ icon DIC2 indicating danger> (in this example, an icon showing the word “danger”, hereinafter referred to as a "second danger icon” as appropriate). ) are superimposed.
  • the talk room icon is ⁇ icon indicating safety SIC2> (in this example, an icon indicating the word “safety”, hereinafter referred to as a "second safety icon” as appropriate). ) is superimposed on the display.
  • the user X By checking the ⁇ icon indicating that it is dangerous> or ⁇ icon indicating that it is safe> displayed in each talk room list item of the talk list, the user X. X can confirm the safety information of the user who sent the message to the terminal 20X.
  • a "blue” icon is displayed for "safety” and a “red” icon is displayed for "dangerous”. may be displayed.
  • the name of the talk room may be displayed in a different color or typeface. It should be noted that these methods of changing the display mode can be similarly applied to the friend list and the group list.
  • the talk list screen of X's terminal 20X is displayed. This talk list screen differs from the talk list screen shown on the right side of FIG. Y has set "dangerous" as safety information, but user Y.Y. In the Y talk room list item, the second danger icon DIC2 is not superimposed on the talk room icon.
  • the center talk room screen of FIGS. 1-10 is displayed.
  • any page within the messaging application (talk room in this example) is currently displayed below the area where the name of the messaging application, etc. is displayed at the top of the screen.
  • a talk room name display area including the name of the talk room (hereinafter referred to as "talk room name") is provided as a type of area indicating whether the talk room is connected.
  • the talk room name display area can also be said to be an area indicating the page (talk room in this example) within the messaging application where the user is currently located.
  • the talk room name display area includes, by way of example and not limitation, a back button of " ⁇ " for returning to the previous screen, and user X.
  • X is user Y.X. Characters ("YY" in this example) indicating that this is a talk room for talking with Y as a partner, and a safety information display icon IC1 for displaying the safety information of users belonging to this talk room. is displayed.
  • YY the safety information display icon IC1
  • a talk area is configured for interactive talk with user Y.Y. Y's message is displayed on the right side of the screen with the message of user X.Y. It is configured to display X messages.
  • user Y. Safety information in the chat room for notifying the safety information set by Y in the chat room (in this example, the characters "Y.Y has responded to the safety confirmation", the user's icon on the terminal, and the safety information
  • a user status icon ICYD icon for user Y.Y, letters "danger", icon without a smile
  • the user status icon is appropriately referred to as "user status icon (icon of user name (icon of), safe or dangerous (character and face icon corresponding to))”.
  • the user status icon is an icon that combines the icon of the user, characters (safe/danger) corresponding to the safety status information, and an icon corresponding to the safety status information.
  • Safety information for each user for displaying the safety information of each user included in this talk room is displayed in a form expanded under the area.
  • a user-by-user safety information display area for displaying user-by-user safety information including safety information of users belonging to the talk room is configured.
  • the user X.Y icon and the second safety icon SIC2 are displayed superimposed.
  • An X icon is displayed.
  • FIG. 1-11 is a flow chart showing an example of the flow of processing executed by each device in this embodiment.
  • FIG. 1-11 an example of processing executed by the control unit 21 of the terminal 20X, processing executed by the control unit 21 of the terminal 20Y, and processing executed by the control unit 11 of the server 10 is shown in order from the left.
  • processing described below is merely an example of processing for realizing the technique of the present disclosure, and is not limited to these. Another step may be added to the processing described below, or some steps may be omitted (deleted) from the processing described below.
  • ⁇ Safety registration account User Y. of terminal 20Y.
  • Account of Y an example of a user of the first terminal, not limited
  • Safety reference account user X.Y of terminal 20X
  • the control unit 21 of the terminal 20X, the control unit 21 of the terminal 20Y, and the control unit 11 of the server 10 execute chat processing (X110, Y110, S110) as an example and not a limitation.
  • chat processing X110, Y110, S110
  • input to the input/output unit 23 of each terminal 20 (as a non-limiting example, user input (user operation input, sound input, etc.) The same applies hereinafter)
  • the control unit 21 executes transmission/reception processing and display processing of contents in the messaging service.
  • the control unit 11 of the server 10 performs relay processing of content transmitted from each terminal 20 as an example and not as a limitation.
  • chat processing may be executed between arbitrary steps during processing. Also, chat processing does not have to be executed in this system.
  • the control unit 11 of the server 10 is based on an input to the input/output unit 12 of the server 10 (as a non-limiting example, user input (operation input by the user of the server 10, sound input, etc.))
  • disaster information including the fact that a disaster has occurred and a request to register the safety of the user of each terminal 20 in this disaster is transmitted to each terminal 20 via the communication I/F 14 (S120).
  • the disaster information may be configured to include any combination of the following disaster elements A to H and requesting the user to register their safety.
  • ⁇ Disaster element A The occurrence of a disaster.
  • - Disaster element B type of disaster (not limited to but examples include earthquakes, floods, large-scale fires, etc.).
  • ⁇ Disaster element C Scale of disaster (not limited but examples include seismic intensity, magnitude, river water level, fire spread range, etc.).
  • ⁇ Disaster element D Date and time when the disaster occurred.
  • ⁇ Disaster element E The place where the disaster occurred.
  • ⁇ Disaster element F secondary effects of disasters (not limited to but examples include power outages, water outages, operation status of transportation systems, etc.).
  • ⁇ Disaster element G How to deal with a disaster (not limited to, but an example of an evacuation site, an evacuation route, etc.).
  • - Disaster element H Information related to other disasters. The disaster information may include information on the safety registration period and time limit for the disaster.
  • the control unit 11 of the server 10 controls the disaster situation information, which is information about the disaster that occurred from the disaster information providing server (not shown) (as an example without limitation, the above disaster elements A to D receive information consisting of Then, based on the disaster situation information, the control unit 11 of the server 10 determines that the scale of the disaster that has occurred is greater than or equal to a predetermined scale (for example, a maximum seismic intensity of 5 or heavy rain). In this case, the disaster information may be automatically transmitted to each terminal 20.
  • a predetermined scale for example, a maximum seismic intensity of 5 or heavy rain.
  • the control unit 11 of the server 10 upon receiving disaster situation information from the disaster information providing server, causes the display unit 13 to display a display screen for selecting whether or not to transmit the disaster information. You may do so. Then, the control unit 11 of the server 10 may transmit the disaster information to each terminal 20 based on the user's input on the selection display screen.
  • the control unit 21 of each terminal 20 Upon receiving the disaster information from the server 10 via the communication I/F 22, the control unit 21 of each terminal 20 displays the received disaster information on the display unit 24 (X120, Y120).
  • the control unit 21 of the terminal 20Y when safety confirmation information is input based on an input to the input/output unit 23 of the terminal 20Y of the safety registration account, the control unit 21 of the terminal 20Y, as an example and not a limitation, confirms the input safety information.
  • the safety confirmation registration information including the confirmation information and the application ID of the safety registration account is transmitted to the server 10 via the communication I/F 22 (Y140).
  • the control unit 11 of the server 10 When the safety confirmation registration information is received from the terminal 20Y of the safety registration account via the communication I/F 14, the control unit 11 of the server 10 generates safety information based on the received safety confirmation registration information.
  • the safety information can include, by way of example and not limitation, the application ID of the safety registration account sent in the safety confirmation registration information and safety confirmation information.
  • control unit 11 of the server 10 may include in the safety information the user name linked to the application ID of the safety registration account transmitted in the safety confirmation registration information.
  • control unit 11 of the server 10 adds any combination of the safety status information, the safety comment information, and the safety location information in the safety confirmation information transmitted in the safety confirmation registration information to the safety information. (for example, not limitation, only safety status information when safety status information and safety location information are included in safety confirmation information) may be included.
  • control unit 11 of the server 10 searches the account management database 155A and refers to the account registered as a friend in the friend management data of the safety registration account. Then, safety information is transmitted via the communication I/F 14 to the terminal 20 of each account registered as a friend (S140).
  • control unit 11 of the server 10 may transmit the safety information to all the terminals 20 in step S140.
  • the control unit 21 of the terminal 20X causes the display unit 24 to display the received safety information (X160).
  • the determination conditions for displaying the safety information on the display unit 24 are not limited but include any combination of the following cases. ⁇ Unconditionally displayed (push notification, etc.) ⁇ Browsing the friend list (group list) will be displayed in association with the safety registration account ⁇ Browsing the talk list will be displayed in association with the safety registration account ⁇ Browsing one-on-one chat rooms between the safety reference account and the safety registration account ⁇ Displayed when browsing the group chat room of the group that includes the safety registration account
  • step S140 when the server 10 transmits safety information to all the terminals 20, the control unit 21 of the terminal 20 of the safety reference account, for example and not limitation, stores the friend management data stored in the storage unit 28. See Then, if the application ID of the safety registration account is included in the friend management data, the safety information may be displayed on the display unit 24 .
  • the present embodiment is a process related to a chat (an example of a chat, not a limitation) with a user of a safety registration account (an example of a user of the first terminal, not a limitation) (a process related to a chat, not a limitation).
  • the terminal 20 of the user of the safety reference account (not a limitation, but an example of the terminal user) who performs the (Not a limitation, but an example of the first information regarding the safety of the user of the first terminal) is received by the communication I/F 22 .
  • the terminal 20 of the user of the safety reference account displays on the display unit 24 the safety information associated with the chat information (not limited, but an example of the chat information) related to the user of the safety registration account.
  • the first information associated with the chat information associated with the user of the terminal can be displayed on the display of the terminal to inform the user of the terminal. It is possible to realize a display that is easy for the user of the terminal to understand in a form associated with the chat information.
  • receiving the first information regarding the safety of the user of the first terminal based on the input to the first terminal by the user of the first terminal may be performed by way of example, not limitation, when the first information is sent from the first terminal to the server. and based on the fact that the server has received the first information, the first information is transmitted from the server to the terminal and the terminal receives the first information, and from the first terminal to the terminal without going through the server The first information is directly transmitted and received by the terminal.
  • chat-related processing includes, but is not limited to, various types of processing for chatting, such as processing for transmitting and receiving information for chatting, processing for displaying content related to chatting, and chatting It can be a concept including various processing etc. for realizing.
  • chat information in the messaging application is not limited, but is a concept that includes "friend list”, “talk list”, “talk room”, etc. corresponding to (B1) to (B3) described above. be able to. The same applies to the aforementioned “follow”, “follower”, and the like.
  • the terminal 20 of the user of the safety reference account can receive safety information (or safety confirmation registration information) via the communication I/F 22 via the server 10 .
  • safety information or safety confirmation registration information
  • the first information can be properly received via the server.
  • the above chat information (not limited, but an example of chat information) is a chat (not limited, but an example of chat information) in a messaging application, and a list of users associated with the user of the safety reference account (example, non-limiting list of users).
  • chat not limited, but an example of chat information
  • a list of users associated with the user of the safety reference account example, non-limiting list of users.
  • chat information (not limited, but an example of chat information) is the user of the safety registration account (not limited, but an example of the user of the first terminal) and the user of the safety reference account (not limited, (an example of the user of the terminal) (not limited to, but an example of the first chat room).
  • the first information associated with the information about the first chat room including the user of the terminal and the user of the terminal can be displayed on the display of the terminal to inform the user of the terminal. It is possible to realize a display that is easy for the user of the terminal to understand in a form associated with the information about the first chat room including the user of the first terminal and the user of the terminal.
  • the above chat information is the icon of the one-to-one chat room (talk partner) included in the talk list of the chat room that includes the user of the safety reference account (not limited, but an example of the list of chat rooms) Information such as images (not a limitation, but an example of information about the first chat room included in the list of chat rooms that include the terminal user), and included in the group list of the group chat room that includes the user of the safety reference account Information such as an icon image of a group talk room (group) (example, non-limiting example of information about the first chat room included in the list of chat rooms in which the user of the terminal is included) may be included.
  • Information such as images (not a limitation, but an example of information about the first chat room included in the list of chat rooms that include the terminal user), and included in the group list of the group chat room that includes the user of the safety reference account
  • Information such as an icon image of a group talk room (group) (example, non-limiting example of information about the first chat room included in the list of chat rooms in which
  • the user of the terminal After receiving the first information regarding the safety of the user of the first terminal based on the input to the first terminal by the user of the first terminal, the user of the terminal The first information associated with the information about the first chat room included in the list of chat rooms including is displayed on the display of the terminal to inform the user of the terminal.
  • the terminal 20 of the user of the safety reference account can perform control to change the display mode of the above-described icon images, etc., by the control unit 21 based on the safety information.
  • the terminal 20 of the user of the safety reference account can perform control to change the display mode of the above-described icon images, etc., by the control unit 21 based on the safety information.
  • the safety information (not limited, but an example of the first information) is the user of the safety registration account (not limited, but an example of the user of the first terminal) and the user of the safety reference account (not limited, but an example of the terminal (an example of the first chat room, not limited).
  • the user of the first terminal is displayed in an easy-to-understand manner by displaying the first information in the first chat room including the user of the first terminal and the user of the terminal. It is possible to inform the user of the terminal of the safety.
  • the safety information (not limited, but an example of the first information) is an image ( It can be displayed in the above-mentioned talk room in association with the first image (example without limitation).
  • the first information is displayed in the first chat room in association with the first image set by the user of the first terminal, the user of the first terminal It is possible to make it easier for the user of the terminal to recognize that the information is related to the safety of the person.
  • FIG. 1-12 shows user A.
  • An example of the home screen displayed on the display unit 24 of A's terminal 20A is shown.
  • the user Y.1 shown on the left side of FIG. 1-8 is displayed.
  • user A.Y of terminal 20A is displayed on the right side of the top of the screen.
  • An icon image and user name ("A.A" in this example) in A's messaging application are displayed.
  • group list items icons and group names (number of members) corresponding to tennis circles, icons and group names (number of members) corresponding to seminar friends, and the like are listed.
  • friend list user B. is displayed as an item of the friend list.
  • icon and user name corresponding to user C.B. icon and user name corresponding to user D.C.
  • a list of icons, user names, etc. corresponding to D is displayed.
  • a display such as that shown in the center of FIG. 1-12 is provided as a non-limiting example.
  • a safety message input area for inputting a safety message is configured below the safety button SBT and the danger button DBT in the safety registration area R1.
  • an area for inputting a safety message (an area where the input safety message is displayed) is configured together with the characters "safety message”. Further, below that, an area for selecting a standard message for the safety message is configured.
  • the text "I was injured”, the text "I was trapped”, the text "I was caught in a fire", and the text "Evacuation”. are prepared in advance, and each is displayed as an icon that can be selected by tapping.
  • a current location input area for entering the current location which is a type of safety location information.
  • the characters "current location”, the area for inputting the current location (the area for displaying the input current location), and the current location acquisition button for acquiring the current location are displayed.
  • a registration button BT3 for setting the selected/inputted safety information.
  • the safety registration area R1 may be configured to register only one of the safety comment information and the safety location information.
  • registration button BT3 is registered to user A.A.
  • User A when tapped by A.
  • An example of the home screen displayed on A's terminal 20A is shown on the right side of FIG. 1-12.
  • the display of the safety registration button BT1 is erased, and the user status icon is displayed instead.
  • the user A A user status icon ICAS indicating the status of A (in this example, user A.A, safe) is displayed.
  • a first danger icon DIC1 is superimposed on the icon corresponding to B.
  • User C.I Based on the fact that C.C has set “dangerous” as safety information, user C.C.
  • a first danger icon DIC1 is superimposed on the icon corresponding to C.
  • User D Based on the fact that D.D has set “safety” as safety information, user D.D.
  • a first safety icon SIC1 is superimposed on the icon corresponding to D.
  • the left side of Figure 1-13 shows user A.
  • the talk list screen of A's terminal 20A is displayed. Unlike the talk list screen on the right side of FIG. 1-9, this talk list screen is below the in-app location display area and displays a list of information about talk rooms to which messages have been sent to this terminal 20A.
  • a second disaster information display area which is an area showing second disaster information for notifying that a disaster has occurred on the talk list screen, is configured above the area where the user is.
  • the second disaster information (for example, but not limited to, the text "20XX/08/04 09:39 announced” and the text "maximum seismic intensity: 5 upper")
  • the user status icon ICAS (user A.A.) is displayed to indicate that fact. A, safety)) is displayed in the second disaster information display area.
  • the talk room list items are the talk room list items of the tennis circle, user D. D's talk room list entry for user B.D. B's talk room list items, seminar mate's talk room list items, user C.B. Talk room list entry for user E.C. E's talk room list items and the like are displayed.
  • the unread number "13" is displayed in association with the tennis circle talk room list item, and user D.
  • the unread number "2" is displayed in association with the talk room list item of user B.D.
  • the unread number "1" is displayed in association with the talk room list item of user C.B
  • the unread number "2" is displayed in association with the seminar fellow talk room list item
  • user C.B's talk room list item is displayed.
  • the unread number "2" is displayed in association with the talk room list item of user E.C.
  • the unread number "1" is displayed in association with E's talk room list item.
  • user D Based on the fact that D.D has set "safety” as safety information, user D.D. A second safety icon SIC2 is superimposed on the icon corresponding to the D talk room list item.
  • User B Based on the fact that user B has set "dangerous" as safety information, user B.B.
  • a second danger icon DIC2 is superimposed on the icon corresponding to the B talk room list item.
  • User C.I Based on the fact that C.C has set “dangerous” as safety information, user C.C.
  • a second danger icon DIC2 is superimposed on the icon corresponding to the C talk room list item.
  • User E Based on the fact that user E.E has set "safety” as safety information, user E.E.
  • a second safety icon SIC2 is superimposed on the icon corresponding to the E talk room list item.
  • the icon corresponding to the group talk room is not overlaid with the icon based on the safety information.
  • the icon corresponding to the talk room list item of the tennis circle will have the second safety icon SIC2 and None of the second danger icons DIC2 are superimposed.
  • the icons corresponding to the talk room list items of the seminar mates have the second safety icon SIC2 and the second danger icon. None of the icons DIC2 are superimposed.
  • safety location information entered and registered by the user in the above-mentioned current location input area and safety message input area described above are displayed.
  • Information based on the input and registered safety comment information is displayed.
  • user B Under the letters “B.B” corresponding to B, the user B.B.
  • Composite safety information "Tsukuba/I was injured” is displayed as information combined (combined) with the safety message "I was injured” registered by B.
  • User C.I. C and user E.C. For E the registered information is similarly displayed.
  • composite safety information is displayed under the user name in the talk room list item, but the present invention is not limited to this.
  • composite safety information may be displayed to the right of the user name.
  • information based on the latest content (message) in the talk room may or may not be displayed under the user name of the talk room list item.
  • an icon based on the safety status information superimposed on the user's icon may be displayed by tapping a balloon, bubble, or the like.
  • Composite safety information may be displayed.
  • the composite safety information may be displayed on the screen (home screen, etc.) on which the friend list is displayed.
  • either one of the safety location information and the safety comment information may be displayed on the screen (home screen, etc.) on which the friend list is displayed.
  • the talk room screen on the left side of FIG. 1-13 user B.
  • the talk room screen on the right side of FIGS. 1-13 is displayed.
  • this screen does not display safety information in the talk room in the talk area, but displays safety information by user in the safety information display area by user.
  • the talk room name display area includes, by way of example and not limitation, user A.
  • A is user B.A. Characters (“B.B” in this example) indicating that the room is for talking with B as the other party are displayed.
  • B.B Characters
  • user B.2 is superimposed and displayed with a second danger icon DIC2 as user-by-user safety information.
  • User A.B superimposed on the second safety icon SIC2.
  • An icon of A is displayed.
  • FIG. 1-14 is a flow chart showing an example of the flow of processing executed by each device in this modified example.
  • an example of processing executed by the control unit 21 of the terminal 20X, processing executed by the control unit 21 of the terminal 20Y, and processing executed by the control unit 11 of the server 10 is shown in order from the left.
  • ⁇ Safety registration account and safety reference account User X. of terminal 20X X (user A.A of terminal 20A on display screen)
  • ⁇ Safety registration account User Y. of terminal 20Y. Y (users of terminals 20B to 20E on the display screen)
  • the processing in the case of is exemplified.
  • the control unit 21 of the terminal 20X causes the display unit 24 to display the disaster information (X120). , determines whether or not to input safety confirmation information (X130). If it is determined to input safety confirmation information (X130: YES), the control unit 21 of the terminal 20X accepts the safety confirmation information and transmits safety confirmation registration information to the server 10 (X140). If it is determined not to input the safety confirmation information (X130: NO), the control unit 21 of the terminal 20X skips step X140.
  • the control unit 21 of the terminal 20Y similarly executes steps Y110 to Y140.
  • the control unit 11 of the server 10 When safety confirmation registration information is received from the terminal 20X via the communication I/F 14 (S130), the control unit 11 of the server 10 generates safety information based on the received safety confirmation registration information and transmits it to each terminal 20. (S140). The same applies to the case of receiving safety confirmation registration information from another terminal (terminal 20Y as an example, not limitation).
  • the control unit 21 of the terminal 20X displays the received safety information on the display unit 24 (X160). If it is determined that the safety information has been received multiple times, the control unit 21 of the terminal 20X may display the received safety information on the display unit 24 each time it is received, or if the safety registration account is different. The safety information received only from the user may be displayed on the display unit 24 .
  • the control unit 21 of the terminal 20Y similarly executes steps Y150 to Y160.
  • the terminal 20 of the user of the safety reference account based on the input to the own terminal 20 by the user of the own terminal 20, safety information (or safety confirmation registration information) regarding the safety of the user of the own terminal 20
  • a configuration for transmitting (not limited to but an example of the third information regarding the safety of the user of the terminal) by the communication I/F 122 is shown.
  • the third information regarding the safety of the user of the terminal is transmitted to notify others of the safety of the user of the terminal. be able to.
  • FIG. 1-15 is a diagram showing an example of information stored in the storage unit 15 of the server 10 in this modification.
  • the storage unit 15 stores an application management processing program 151 executed as application management processing, account registration data 153 , an account management database 155 , and a group management database 157 as an example and not limitation.
  • the group management database 157 is a database for managing information about groups, and an example of the data configuration of the group management database 157 is shown in FIG. 1-16.
  • Group management data is stored in the group management database 157 as management data for each group.
  • Each group management data stores a group ID, a group name, and group member data as an example and not limitation.
  • a group ID is information for identifying a group managed by group management data. This group ID is preferably a unique value for each group, and as an example and not a limitation, the server 10 sets and stores a unique value (unique value) for each group.
  • the group name is the name of this group, and as an example and not as a limitation, the name registered when the user of the terminal 20 creates a group is stored.
  • Group member data is data for storing application IDs of accounts that are members of this group (belonging to the group).
  • the server registers group participation.
  • the application ID of the user who performed is added and updated.
  • the group management data may be stored in association with the application ID of the account representing the group.
  • the left side of Figure 1-17 shows user A.
  • the talk list screen of A's terminal 20A is displayed.
  • B Based on the fact that the talk room with B.B has been browsed, B.B.
  • the number of unread messages with B is "0" (hidden).
  • the talk room screen on the right side of FIG. 1-17 is displayed by way of example and not limitation. be.
  • This screen differs from the display screen on the right side of FIG. 1-13 in that the talk room name display area includes, by way of example and not limitation, the user A.S. Characters indicating that A is a talk room for talking with a group of seminar friends (in this example, "seminar friends (4)" (the number is the number of members)) are displayed.
  • user B. is superimposed on the second danger icon DIC2 as user-by-user safety information.
  • User A.B superimposed on the second safety icon SIC2.
  • User D.A superimposed on the second safety icon SIC2.
  • the icon of user F.D and the second danger icon DIC2 are displayed superimposed.
  • An icon F is displayed.
  • user D As content transmitted from user B.D. A text content confirming that B is scheduled to give a presentation at an academic conference in Tsukuba today is displayed.
  • the content sent from User B.F is that an earthquake with a seismic intensity of lower 5 occurred in Tsukuba. Text content that worries B is displayed.
  • FIG. 4 is a diagram showing an example in which images (icons, etc.) based on information are associated and displayed.
  • effect safety information based on the safety information is additionally displayed on the icon corresponding to the group talk room.
  • the safety information of all members belonging to the group chat room is set to "safe”
  • the first effect information SFA white object as an example, not a limitation
  • the second effect information DFA (a red object as an example, not a limitation) is displayed in the group chat room. is added to the corresponding icon.
  • the first effect information SFA is displayed on the icon corresponding to the group talk room of the tennis circle. additionally displayed.
  • the icon corresponding to the seminar group talk room 2 effect information DFA is additionally displayed.
  • the talk room screen on the right side of FIG. 1-18 is displayed as an example and not by way of limitation. be done. Since this screen is the same as the talk room screen on the right side of FIG. 1-17, the explanation is omitted.
  • the method of changing the display mode is not limited to the above.
  • the safety information of all members belonging to the group talk room is set to "safe”
  • the icon corresponding to the group talk room is displayed in "blue” and one person belonging to the group talk room is displayed.
  • an icon corresponding to the group chat room may be displayed in "red”. Further subdividing it, based on the number (or percentage) of the members who belong to the group chat room and set it as “dangerous", the icons corresponding to the group chat room are displayed in "yellow” and "red”. , the above effect display may be performed.
  • the name of the group talk room is not limited to these, and may be displayed by changing the color or typeface of the characters indicating the name of the group talk room.
  • the control unit 11 of the server 10 upon receiving the safety confirmation registration information, refers to the group management database 157 and searches for the group to which the safety registration account belongs. Then, for each group to which the safety registration account belongs, the safety registration data of each application ID registered in the group member data is referred to.
  • the safety registration data of all application IDs registered in a certain group member data is "safe”
  • the control unit 11 of the server 10 generates safety information for the group (hereinafter referred to as "group safety information"). is generated in a first manner indicating that all members are "safe”.
  • control unit 11 of the server 10 When safety registration data of all application IDs are not "safe", the control unit 11 of the server 10 generates group safety information for the group in a second mode indicating that all members are not "safe”. Then, the control unit 11 of the server 10 transmits the group safety information to the terminals 20 of all accounts registered in the group member data through the communication I/F 14 .
  • the terminal 20 of the user of the safety reference account is connected to a chat room such as a one-to-one chat room or a group chat room (not limited to, but an example of the first chat room) containing safety information.
  • a chat room such as a one-to-one chat room or a group chat room (not limited to, but an example of the first chat room) containing safety information.
  • the control unit 21 performs control to change the display mode of the information on the talk room based on the included information on the safety of the user.
  • the control unit 21 performs control to change the display mode of the information on the talk room based on the included information on the safety of the user.
  • the display mode of information about the first chat room based on information about the safety of users included in the first chat room including the user of the first terminal and the user of the terminal, including the first information. can.
  • the safety status information has two classes of "safe” and “dangerous”, but it is not limited to this. Other safety status information may be included. As an example and not as a limitation, the safety information may be set in three classes of "safe", “dangerous", and "outside area”.
  • FIG. 1-19 The left side of Figure 1-19 shows user A.
  • the home screen of A's terminal 20A is displayed. This screen is different from the home screen in the center of FIG. 1-12.
  • this screen has a safety button SBT for setting safety as safety information and a safety button SBT for setting safety as unsafe.
  • an out-of-area button ABT for setting out-of-area as safety information is a diagram showing an example of display. be.
  • Out of area is, by way of example and not limitation, when the user is located in a location that is not affected by the currently occurring disaster, and by way of example and not limitation, the disaster is an earthquake.
  • the current location indicated by the terminal 20 of the user is located at a distance of a set distance (200 km as an example, not a limitation) from the epicenter.
  • registration button BT3 is registered to user A.A. It is tapped by A, and the display transitions to the home screen (not shown). Then, when the user taps the talk item at the bottom of the screen on the home screen, the talk list screen shown on the right side of FIG. 1-19 is displayed on the display unit 24 of the terminal 20A as an example without limitation.
  • the safety status information may include information such as "not feeling well” indicating that the person is not.
  • the server 10 generates safety information based on safety confirmation registration information, but the present invention is not limited to this.
  • the terminal 20 may generate the safety information.
  • control unit 21 of the terminal 20Y of the safety registration account generates safety information upon receiving the safety confirmation registration information. Then, the control unit 21 of the terminal 20Y of the safety registration account refers to the friend management data of the safety registration account, and for example, not limitation, transmits the safety information to each terminal 20 of the safety registration account and the account that has already been registered as a friend. do.
  • control unit 21 of the terminal 20Y of the safety registration account may transmit safety information to each terminal 20 via the server 10 as an example and not as a limitation. Further, the control unit 21 of the terminal 20Y of the safety registration account may transmit the safety information to all the terminals 20 using broadcast communication as an example and not limitation.
  • ⁇ Second embodiment> In the first embodiment, an example in which safety registration is performed only once at the terminal 20 of the safety registration account was exemplified.
  • the second embodiment is an embodiment in which the safety information is updated in the terminal 20 of the safety reference account by repeatedly performing safety registration by the user of the terminal 20 of the safety registration account.
  • the display screen in this embodiment illustrates an example of registering only safety status information as safety confirmation information. Also, a case where the safety information is displayed only in the talk room on the terminal 20 of the safety reference account will be exemplified.
  • the user status icon ICYD (user YY, dangerous) is displayed based on Y setting "dangerous" as safety information.
  • the safety registration area R1 is displayed in a raised manner superimposed on the home screen of Y's terminal 20Y. This safety registration area R1 is used to change the safety information in this embodiment.
  • a message prompting the user to set safety information (in this example, the characters "Confirm safety” and the characters "Let's inform everyone about your safety") are displayed.
  • a safety button SBT and a danger button DBT are provided.
  • a change button BT5 for changing the safety information to the selected safety information is displayed at the bottom of the screen.
  • the talk room screen in the center of FIG. When the talk room list item corresponding to Y is tapped by the user, by way of example and not limitation, the talk room screen on the right side of FIG. 2-1 is displayed.
  • the first notification information NI1 for notifying the safety information set by Y in the chat room (in this example, the characters "Mr. Y.Y responded to the safety confirmation" and the user status icon ICYD (user Y. Y, danger)) is displayed.
  • user Y As content from Y, a text content ("Is the earthquake okay?") is displayed.
  • the second notification information NI2 in which the safety has been changed to safe (in this example, "Mr. Y confirms safety has been answered” and a user status icon ICYS (user Y. Y, safe)) are displayed.
  • user Y As the content from Y, text content ("Evacuated!) is displayed.
  • FIG. 2B is a flow chart showing an example of the flow of processing executed by each device in this embodiment.
  • FIG. 2B is a flow chart showing an example of the flow of processing executed by each device in this embodiment.
  • an example of processing executed by the control unit 21 of the terminal 20X, processing executed by the control unit 21 of the terminal 20Y, and processing executed by the control unit 11 of the server 10 is shown in order from the left.
  • safety confirmation processing is executed (X210, Y210, S210).
  • FIG. 2-3 is a flowchart showing an example of the flow of safety confirmation processing.
  • the view of the figure is the same as in FIG. 2-2.
  • the control unit 21 of the terminal 20X performs steps X2130 to X2160 in the same manner as steps X130 to X160 in FIG. 1-14, for example and not limitation. Further, as an example and not limitation, the control unit 21 of the terminal 20Y executes steps Y2130 to Y2160 in the same manner as steps Y130 to Y160 in FIG. 1-14.
  • the control unit 11 of the server 10 performs steps S2130 to S2140, for example and not limitation, in the same manner as steps S130 to S140 in FIG. 1-14.
  • the control unit 21 of the terminal 20X, the control unit 21 of the terminal 20Y, and the control unit 11 of the server 10 determine whether or not to end the process. (X220, Y220, S220).
  • a judgment condition for terminating the process as an example, not a limitation, a case where a specific period (one week as an example, not a limitation) has passed since the date and time of the disaster, or based on the user input of the server 10 For example, when it is selected that the confirmation service is suspended.
  • the control unit 21 of each terminal 20 and the control unit 11 of the server 10 end the process. If it is determined not to end the process (X220: NO, Y220: NO, S220: NO), the control unit 21 of each terminal 20 and the control unit 11 of the server 10 cause the safety confirmation process to be executed again (X210, Y210 , S210).
  • control unit 21 of each terminal 20 and the control unit 11 of the server 10 may execute chat processing at any timing before or after the safety confirmation processing.
  • FIG. 2-4 is a timing chart showing an example of the timing of processing executed by each device in this embodiment.
  • ⁇ Safety registration account User Y. of terminal 20Y.
  • Account of Y an example of a user of the first terminal, not limited
  • Safety reference account user X.Y of terminal 20X
  • the following is an example of the processing for X (an example of a terminal user, not a limitation) as an account.
  • the safety confirmation process is executed, and when the terminal 20Y receives the input (operation input, etc.) of the safety confirmation registration information (Y2130), the first safety confirmation registration information is transmitted to the server 10 ( Y2140) (timing "TM110"). Then, the server 10 receives the first safety confirmation registration information (S2130: YES). The control unit 11 of the server 10 generates first safety information based on the first safety confirmation registration information, and transmits it to each terminal 20 (S2140) (timing "TM120"). Upon receiving the first safety information, the terminal 20X executes display processing (X2160) (timing "TM130").
  • the safety confirmation process is executed again, and when the terminal 20Y accepts the input of the safety confirmation registration information (Y2130), the first safety confirmation registration information is transmitted to the server 10 (Y2140) (timing "TM140"). Then, the server 10 receives the second safety confirmation registration information (S2130: YES). The control unit 11 of the server 10 generates second safety information based on the second safety confirmation registration information, and transmits it to each terminal 20 (S2140) (timing "TM150"). Upon receiving the second safety information, the terminal 20X executes display processing (X2160) (timing "TM160”).
  • control unit 11 of the server 10 may perform safety comparison processing between the first safety confirmation registration information and the second safety confirmation registration information. Then, if there is no difference between the first registered safety confirmation information and the second registered safety confirmation information, the second safety confirmation information may not be transmitted to each terminal 20 .
  • the control unit 11 of the server 10 changes the safety status of the safety registration account. You may make it transmit to each terminal 20 the safety change information which shows that it was.
  • This timing chart illustrates an example in which the safety confirmation registration information is input twice on the terminal 20Y of the safety registration account, but the same process can be executed in the case where the safety confirmation registration information is input three times or more. can.
  • the terminal 20 of the user of the safety reference account receives the first safety information (not limited but an example of the first information) by the user of the safety registration account (not limited but an example of the user of the first terminal). ) is changed to second safety information (not a limitation, but an example of the second information), the second safety information is received by the communication I/F 22 .
  • the terminal can 2 information can be reliably acquired.
  • the second safety information includes the user of the safety registration account (not limited, but an example of the user of the first terminal) and the user of the safety reference account (not limited, but an example of the user of the terminal) It can be made to be displayed in a talk room (an example of a first chat room, not a limitation).
  • a talk room an example of a first chat room, not a limitation.
  • the terminal user is notified of the second information in an easy-to-understand manner by displaying it in the first chat room including the user of the first terminal and the user of the terminal. can be done.
  • the terminal 20 of the safety reference account automatically receives the second safety information. It is not limited to this.
  • the second safety information may be received when a set condition is met, such as when a specific display element is displayed on the terminal 20 of the safety reference account.
  • the display screen in this modified example illustrates an example in which only safety status information is registered as safety confirmation information. Also, a case where the safety information is displayed on the friend list and the user's profile screen on the terminal 20 of the safety reference account will be illustrated. The safety information may be displayed on the talk list screen or the talk room screen.
  • FIG. 2-5 shows user Y.
  • a safety information change area for changing the safety information that has already been set is superimposed on the home screen of Y's terminal 20Y and displayed. Since this home screen is the same as the display screen on the left side of FIG. 2-1, the description thereof is omitted.
  • a list of icons, user names, etc. corresponding to B is displayed.
  • user Y. Based on the fact that Y has set "dangerous" as safety information, user Y.Y.
  • a first danger icon DIC1 is superimposed and displayed in association with the icon of user A.Y.
  • a first safety icon SIC1 is displayed superimposed in association with the icon of user B.A.
  • B.B has set "dangerous” as safety information
  • user B.B in the friend list is displayed.
  • a first danger icon DIC1 is superimposed in association with the B icon.
  • a profile screen can be, by way of example and not limitation, a screen that displays information about a selected user's profile.
  • the profile screen includes an icon image, a user name, information about the safety of each user in the messaging application, a button for talking with the user, and a voice message with the user.
  • a button for making a call, a button for making a video call with this user, and the like can be displayed.
  • a push notification PN1 is shown that is displayed in a push format, including:
  • a second safety icon SIC2 is displayed. More specifically, on the home screen in the center of FIG. 2-5, user Y. in the friend list is displayed. A first danger icon DIC1 was displayed in association with the Y icon. User Y. Y changes the first information about safety (danger) to the second information (safety), and user Y.Y shown on the right side of FIG. Based on the user Y's profile screen being displayed, user Y.Y's profile screen is displayed. A second safety icon SIC2 is displayed in association with the Y icon.
  • the control unit 21 of the terminal 20X displays the user Y.Y on the right side of FIG. Display the profile screen corresponding to Y. Then, the control unit 21 of the terminal 20X transmits the safety update request information to the server 10 via the communication I/F 22, and based on this, the information to be displayed in the push notification is transmitted from the server 10 to the terminal 20X. be done. Then, based on the received information, the control unit 21 of the terminal 20X displays the above-described push notification, and based on the received information, an icon corresponding to the changed safety information (in this example, safety to display the second safety icon SIC2).
  • the control unit 21 of the terminal 20X displays the above-described push notification, and based on the received information, an icon corresponding to the changed safety information (in this example, safety to display the second safety icon SIC2).
  • the control unit 21 of the terminal 20X transmits the safety update request information to the server 10, based on this, the changed safety information (in this example, safety) is transmitted from the server 10 to the terminal 20X. . Then, based on the received information, the control unit 21 of the terminal 20X displays the icon corresponding to the safety information after the change (in this example, the second safety icon SIC2 corresponding to safety). In addition, the control unit 21 of the terminal 20X combines the previously received safety information before change (“dangerous” in this example) with the newly received safety information after change (“safety” in this example). Based on this, information for displaying the push notification may be generated and the push notification may be displayed.
  • the previously received safety information before change (“dangerous” in this example)
  • safety information after change (“safety” in this example
  • first safety icon SIC1 or first danger icon DIC1 is not displayed in association with users included in the list, but the right side of FIG.
  • the above push notification may be displayed when the profile screen of is displayed.
  • the control unit 21 of the terminal 20X displays the user Y.Y on the right side of FIG.
  • the profile screen corresponding to Y is displayed, but the icon corresponding to the safety information before change (in this example, the second danger icon DIC2 corresponding to danger) is displayed.
  • the control unit 21 of the terminal 20X transmits the safety update request information to the server 10, and based on this, the changed safety information (in this example, safety) is transmitted from the server 10 to the terminal 20X. do.
  • control unit 21 of the terminal 20X changes the display of the icon corresponding to the safety information before the change (the second danger icon DIC2 corresponding to danger in this example) to the icon corresponding to the safety information after the change (in this example Then, control may be performed to change to the second safety icon SIC2) corresponding to safety.
  • the user's profile screen may be displayed.
  • second danger icon DIC2 displayed superimposed on the icon corresponding to B's talk room list item
  • user B .
  • B's profile screen may be displayed.
  • user B A second danger icon DIC2 can be displayed on B's profile screen.
  • the terminal 20 of the safety reference account displays the talk room list items of the user of the safety registration account (for example, without limitation, icons corresponding to the user's talk room list items). (icons based on safety status information) may be displayed in a luminous manner. Then, when the illuminated item is tapped, the user's profile screen may be displayed.
  • the safety location information and the safety comment information may be displayed on separate screens. may be displayed on the profile screen.
  • the composite safety information may be displayed on the profile screen.
  • either one of the safety location information and the safety comment information may be displayed on the profile screen.
  • safety information may not be displayed on the above profile screen.
  • the safety information may be displayed on the home screen described above, but may not be displayed on the profile screen described above.
  • a dedicated screen for displaying safety information may be displayed.
  • FIG. 2-6 is a timing chart showing an example of the timing of processing executed by each device in this modified example.
  • ⁇ Safety registration account User Y. of terminal 20Y.
  • Account of Y an example of a user of the first terminal, not limited
  • Safety reference account user X.Y of terminal 20X
  • the following is an example of the processing for X (an example of a terminal user, not a limitation) as an account.
  • safety confirmation processing is executed, and when terminal 20Y receives input of safety confirmation registration information (Y2130), the first safety confirmation registration information is transmitted to server 10 (Y2140) (timing "TM210"). Then, the server 10 receives the first safety confirmation registration information (S2130: YES). The control unit 11 of the server 10 generates first safety information based on the first safety confirmation registration information, and transmits it to each terminal 20 (S2140) (timing "TM220"). Upon receiving the first safety information, the terminal 20X executes display processing (X2160) (timing "TM230").
  • the safety confirmation process is executed again, and when the terminal 20Y accepts input of the safety confirmation registration information (Y2130), the first safety confirmation registration information is transmitted to the server 10 (Y2140) (timing "TM240"). Then, the server 10 receives the second safety confirmation registration information (S2130: YES). The control unit 11 of the server 10 generates second safety information based on the second safety confirmation registration information.
  • specific display elements include, by way of example and not limitation, the following display elements.
  • ⁇ Profile screen of user of safety registration account ⁇ One-to-one chat room between safety registration account and safety reference account ⁇ Group chat room including safety registration account ⁇ Talk list screen including safety registration account ⁇ Official account profile screen of safety confirmation service ⁇ Talk room between the official account of the safety confirmation service and the safety reference account ⁇ The talk list screen including the official account of the safety confirmation service It may be excluded from the elements.
  • control unit 21 of the terminal 20X transmits safety update request information for requesting safety information of a predetermined safety registration account to the server 10 via the communication I/F 22 (timing "TM260").
  • the control unit 11 of the server 10 When receiving the safety update request information, the control unit 11 of the server 10 transmits the second safety information to the terminal 20X of the safety reference account (S2140) (timing "TM270"). If there is no difference between the first registered safety confirmation information and the second registered safety confirmation information as a result of the safety comparison process, the control unit 11 of the server 10 transmits the second safety information to the terminal 20X. You can choose not to. In this case, information indicating that there is no change in safety may be transmitted to the terminal 20X. In addition, if a difference occurs between the first safety confirmation registration information and the second safety confirmation registration information as a result of the safety comparison processing, the control unit 11 of the server 10 changes the safety status of the safety registration account. You may make it transmit the safety change information which shows that it was the terminal 20X to the terminal 20X.
  • the terminal 20X Upon receiving the second safety information, the terminal 20X executes display processing (X2160) (timing "TM280").
  • This timing chart illustrates an example in which the safety confirmation registration information is input twice on the terminal 20Y of the safety registration account, but the same process can be executed in the case where the safety confirmation registration information is input three times or more. can.
  • the terminal 20 of the user of the safety reference account receives the first safety information (not limited but an example of the first information) via the communication I/F 22
  • the user of the safety registration account (not limited to , an example of the user of the first terminal) and the user of the safety reference account (not limited, but an example of the user of the terminal).
  • the communication I/F 22 receives the second safety information (not a limitation, but an example of the second information).
  • the terminal is triggered by displaying the first chat room including the user of the first terminal and the user of the terminal. can obtain the second information. In addition, by doing so, it is possible to prevent the user of the terminal from receiving the second information unnecessarily and to avoid annoyance.
  • the terminal 20 of the user of the safety reference account displays information of the user of the safety registration account such as profile information of the user of the safety registration account (not limited, but an example of information of the user of the first terminal) on the display unit 24.
  • the second safety information may be received by the communication I/F 22 .
  • the terminal can acquire the second information when the terminal displays the information of the user of the first terminal. In addition, by doing so, it is possible to prevent the user of the terminal from receiving the second information unnecessarily and to avoid annoyance.
  • the information on the user of the safety registration account may include information on the status of the user of the safety registration account, including information related to the safety of the user of the safety registration account (safety, danger, etc.).
  • the terminal displays information about the status of the user of the first terminal, including the first information related to the safety of the user of the first terminal, The terminal can be enabled to obtain the second information. In addition, by doing so, it is possible to prevent the user of the terminal from receiving the second information unnecessarily and to avoid annoyance.
  • the terminal 20 of the safety reference account automatically receives the second safety information. It is not limited to this. As an example and not a limitation, the second safety information may be received based on the relationship between the safety reference account and the safety registration account.
  • the control unit 11 of the server 10 sends the second safety information to the safety information. You may make it transmit to the terminal 20 of a reference account.
  • the terminal 20 of the safety reference account transmits the safety update request information to the server 10 at set time intervals (for example, not limited to "5 minutes"). do. Then, when receiving the safety update request information, the control unit 11 of the server 10 may transmit the second safety information to the terminal 20 of the safety reference account.
  • This modification shows a configuration in which the second safety information (an example of the second information, not a limitation) is transmitted based on the relationship between the user of the safety reference account and the user of the safety registration account.
  • the second safety information an example of the second information, not a limitation
  • FIG. 2-7 The left side of Figure 2-7 shows user A.
  • An example of the talk list screen of A's terminal 20A is shown. This talk list screen is similar to the display screen on the left side of FIG.
  • Information including a user status icon (user A.A, safe) indicating this is displayed in the second disaster information display area based on A setting that he is "safe". .
  • user A. A's account functions as a safety registration account.
  • the center talk room screen of FIGS. 2-7 is displayed. This screen is different from the talk room screen shown on the right side of FIG. A is user C. Characters ("C.C" in this example) indicating that the room is for talking with C as the other party are displayed.
  • C.C Characters
  • user C.2 is displayed superimposed with the second danger icon DIC2 as user-by-user safety information.
  • the icon of user A.C and the second safety icon SIC2 are superimposed and displayed.
  • An icon of A is displayed.
  • user C Content from user A.C (as a non-limiting example text content "Earthquake! Shaking is great", text content "Elevator stopped”) and user A.C. Content originated by A (as an example, but not as a limitation, text content of "Is earthquake okay? Are you with someone?") is displayed.
  • user C.I. User A.C changes the safety information by user A.C.
  • An example of the talk room screen displayed on A's terminal 20A is shown on the right side of FIG. 2-7.
  • user C.I. Based on user C.C changing his safety information from "dangerous" to "safe", by way of example and not limitation, at the top of the screen, user C.C.
  • a push notification PN3 including an icon and a text indicating that C has changed the safety information (C.'s status has changed) is displayed.
  • a new user C is displayed.
  • the content from C (as a non-limiting example, the text content of ⁇ The elevator has stopped'', the text content of ⁇ I'm alone, I'm scared, the elevator has moved! is displayed.
  • A's account also functions as a safety reference account.
  • the third embodiment is an embodiment in which connection control is performed based on registered safety status information as an example, not as a limitation, when a call is made between terminals 20 of two or more safety registration accounts.
  • the user account of the caller who is the person making the call
  • the user account of the recipient who is the person who receives the call
  • the source account is user A. of terminal 20A.
  • the destination account is transferred to the user B. of the terminal 20B.
  • the source account and the destination account are exemplified as safety registration accounts for which safety registration has been completed.
  • Figure 3-1 shows user A.
  • the talk room screen of A's terminal 20A is displayed. Since this screen is the same as the display screen shown on the right side of FIG. 1-13, the explanation is omitted.
  • a call status display area that shows the call status (state of the call) is provided below the area where the name of the messaging application, etc. is displayed at the top of the screen, as an example and not as a limitation.
  • Call statuses include, by way of example and not limitation, user A.A.
  • A is user B.A.
  • "Calling" indicating that user A.B is calling.
  • A is user B.A.
  • "During a call” or the like is provided to indicate that a call is being made with B.
  • a microphone off button to turn off the microphone (in this example, an image of a microphone and the words "Turn off the microphone”).
  • a video call button to make a video call with that user (in this example, a video camera-type image and the words "start video call")
  • a speaker on button to turn on the speaker (in this example , a speaker-shaped image and the words "speaker on")
  • a call end button for ending a call, and the like
  • the characters "in call” are displayed, and below it is the user B.
  • An icon image of B, the letters “BB”, the number “1:47” as the call time, a microphone off button, a video call button, a speaker on button, and a call end button are displayed.
  • the left side of Figure 3-2 shows user A.
  • the talk room screen of A's terminal 20A is displayed.
  • the talk room name display area includes, by way of example and not limitation, a " ⁇ " back button for returning to the previous screen, a user A.
  • A is user C. Characters (in this example, "C.C") indicating that this is a talk room for talking with C, a call button, etc. are displayed.
  • call refrain request information CRI1 is displayed superimposed on the talk room screen on the left side of Fig. 3-2 to discourage unnecessary and non-urgent calls in the event of a disaster.
  • the call refrain request information CRI1 includes a message (in this example, "Unnecessary due to large-scale disaster occurrence Please refrain from making non-urgent calls.”, a character image), a cancel button for canceling the outgoing call (in this example, a button containing the word “cancel”), and a second button for making a call. 2 Call buttons (in this example, a button containing the characters "call by all means”) are displayed.
  • the characters "in call” are displayed, and below it is the user C.
  • An icon image of C, letters “C.C”, numbers “0:12" as call time, a microphone off button, a video call button, a speaker on button, and a call end button are displayed.
  • FIG. 3C is a flow chart showing an example of the flow of processing executed by each device in this embodiment.
  • FIG. 3C is a flow chart showing an example of the flow of processing executed by each device in this embodiment.
  • FIG. 3C shows an example of the flow of processing executed by each device in this embodiment.
  • FIG. 3C shows an example of processing executed by the control unit 21 of the terminal 20X of the source account, processing executed by the control unit 21 of the terminal 20Y of the destination account, and processing executed by the control unit 11 of the server 10 is shown.
  • call request information including the application ID of the destination account is transmitted to the server 10 via the communication I/F 22 (X310).
  • the control unit 11 of the server 10 executes safety status determination processing (S310).
  • the control unit 11 of the server 10 refers to the account management database 155A and compares the safety status information in the safety registration data of the sender account (hereinafter referred to as "sender status") and the recipient account. safety status information in the safety registration data (hereinafter referred to as "destination status"). Then, the control unit 11 of the server 10 determines whether or not the originator status is "safe” and the destination status is "safe” as an example and not a limitation.
  • the control unit 11 of the server 10 requests that the call be refrained from making calls. Refusal request information is sent to the terminal 20X of the originator account via the communication I/F 14 (S320).
  • control unit 11 of the server 10 skips step S320. .
  • the control unit 21 of the terminal 20X displays the received call refrain request information on the display unit 24 (X330). . If it is determined that the call refrain request information has not been received (X320: NO), the control unit 21 of the terminal 20X skips step X330.
  • the control unit 11 of the server 10 starts call processing (S340). Also, the control units 21 of the terminals 20X and 20Y start call processing (X340, Y340). In the call processing, the control unit 21 of the terminal 20Y causes the sound output unit 26 to output a call ringtone indicating that a call has been received, for example and not limitation. This allows user X. Have X hear a ring tone to indicate that a call is being requested. Further, the control unit 21 of the terminal 20Y causes the display unit 24 to display an incoming call display including the information of the caller account (user name as an example, not a limitation) as an example and not a limitation. As the information of the source account, information including the source status may be displayed on the display unit 24 of the terminal 20 of the destination account.
  • the information of the source account information including the source status may be displayed on the display unit 24 of the terminal 20 of the destination account.
  • the control unit 21 of the terminal 20X and the control unit 21 of the terminal 20Y communicate with the server 10 as an example and not a limitation. perform VoIP processing in calls between users via. Note that when the call is accepted, the control unit 21 of the terminal 20X and the control unit 21 of the terminal 20Y may perform peer-to-peer communication and execute VoIP processing in the call.
  • the control unit 11 of the server 10 terminates the process. Also, the control units 21 of the terminals 20X and 20Y terminate the process.
  • the call refrain request information may include a display for selection as to whether or not to cancel the outgoing call.
  • the call refrain request information is displayed on the terminal 20X of the originator account, and as an example and not as a limitation, if it is selected to cancel the call based on the input to the call refrain request information, the terminal of the originator account
  • the control unit 21 of 20X transmits to the server 10 via the communication I/F 22 call termination information indicating that the call is to be cancelled.
  • the control unit 11 of the server 10 may not start the call processing between the terminal 20X and the terminal 20Y. . If it is selected to continue the outgoing call based on the input operation for the call refrain request information, the control unit 11 of the server 10 may start call processing between the terminal 20X and the terminal 20Y.
  • Call connection refusal information indicating that the call will not be connected may be transmitted to the terminal 20X of the caller account via the communication I/F 14 .
  • the control unit 21 of the terminal 20X may cause the display unit 24 to display it. Then, the control unit 11 of the server 10 may not start the call processing. In other words, when it is determined in the safety status determination process that the originator status is "safe” and the destination status is "safe", the call is forcibly terminated.
  • the terminal 20 of the user of the originating account performs processing related to the call by the control unit 21 based on the information regarding the safety of the user of the originating account and the information regarding the safety of the user of the destination account. is shown.
  • the control unit 21 performs processing related to the call by the control unit 21 based on the information regarding the safety of the user of the originating account and the information regarding the safety of the user of the destination account.
  • the call is suppressed (prohibited) when both the information regarding the safety of the user of the originating account and the information regarding the safety of the user of the destination account are "safe".
  • processing can be included.
  • the call is suppressed ( prohibited).
  • ⁇ Third modification (1)> it is determined whether or not to suppress calls based on the safety status determination process, but the present invention is not limited to this.
  • the control unit 11 of the server 10 increases the connection priority of the call and executes call processing. good too.
  • the originator status is "dangerous"
  • the call origination by the user of the originator account is considered to be highly urgent. Therefore, when the caller status is determined to be "dangerous", the connection priority of the call is increased, thereby facilitating the connection of a call with a high possibility of urgency.
  • the call ringtone on the terminal 20Y of the callee account may be output as a more conspicuous ringtone.
  • the call display on the terminal 20Y of the callee account may be displayed as an incoming call display in a more conspicuous manner. This allows the user of the originating account to more easily distinguish incoming calls from originating accounts that are likely to be taking actions such as asking for help.
  • the call connection priority may be increased.
  • the server 10 executes the safety status determination process, but the present invention is not limited to this.
  • the terminal 20X of the originator account may execute the safety status determination process.
  • control unit 21 of the terminal 20X of the caller account executes the safety confirmation process, as a non-limiting example, based on an input (user operation, etc.) to the input/output unit 23 of the terminal 20X, the call is performed. Accept the destination account.
  • control unit 21 of terminal 20X then transmits safety information request information including the application ID of the source account and the application ID of the destination account to server 10 via communication I/F 22 .
  • the control unit 11 of the server 10 Upon receiving the safety information request information from the terminal 20X through the communication I/F 14, the control unit 11 of the server 10 refers to the account management database 155A to obtain the caller status and callee status. Then, the safety information including the caller status and the callee status is transmitted to the terminal 20X through the communication I/F 14 .
  • the control unit 21 of the terminal 20X Upon receiving safety information from the server 10 via the communication I/F 22, the control unit 21 of the terminal 20X executes safety status determination processing based on the received safety information. Then, when it is determined that the caller status is “safe” and the callee status is “safe”, the control unit 21 of the terminal 20X causes the display unit 24 to display call refrain request information.
  • the control unit 21 of the terminal 20X does not transmit the safety information request information to the server 10, and the outgoing call stored in the storage unit 28
  • the safety status determination process may be executed based on the source status and the destination status.
  • the fourth embodiment is an embodiment in which, when the safety confirmation registration information is registered in the terminal 20 of the safety registration account, a response is automatically sent to the subsequent messages sent to the safety registration account.
  • FIG. 4-1 The left side of FIG. 4-1 shows user A.
  • the home screen of A's terminal 20A is displayed. Unlike the home screen in the center of FIG. 1-12, this screen displays a safety message input by the user (in this example, "Moving by bicycle") in the safety message input area.
  • a safety message input by the user in this example, "Moving by bicycle”
  • the current location in the current location input area below it, the current location (“Mitaka City” in this example) input by the user is displayed.
  • the display transitions to the safety registration area R1 in the center of FIG. 4-1.
  • the displays of the safety button SBT, the danger button DBT, the safety message input area, the current location input area, etc. are erased, and a safety information confirmation area for confirming the set safety information is formed.
  • the safety information confirmation area as a non-limiting example, the characters "Registered with the following contents", the characters “safety message”, the user status icon ICAS (user A.A, safe), "Mitaka/By bicycle Moving" is displayed.
  • an automatic response setting area for setting the automatic response mode is configured.
  • the characters "Do you want to switch to the auto-response mode?" and a "No" button BT12 (in this example, a button indicated by "No" characters) for not setting the automatic response mode.
  • FIG. 3 shows an example of a talk list screen displayed on the display unit 24 of A's terminal 20A. Unlike the talk list screen on the left side of Figure 1-13, this screen is different from the talk list screen on the left side of Fig. 1-13. If you have set the automatic answer mode, this screen will show that messages from other users are sent to the talk room list items after the automatic answer mode is set. The auto-answered information is displayed to indicate that the chat room has been sent (replied by auto-response).
  • the message when the automatic response mode is set, the message is sent at the oldest time among the chat room list items of the chat room to which other users sent messages after the automatic response mode was set. From the talk room list item corresponding to the talk room (user B.B's talk room) to the talk room list item corresponding to the talk room (tennis circle group talk room) in which the message was sent at the most recent time , automatic response completed information (in this example, a telop indicating the characters "automatic response completed”) is superimposed and displayed.
  • automatic response completed information in this example, a telop indicating the characters "automatic response completed
  • FIG. 4-2 shows user D.
  • the talk room screen of D's terminal 20D is displayed. This screen is different from the talk room screen shown on the right side of FIG. D is user A.D. Characters (“A.A” in this example) indicating that this is a talk room for talking with A as a partner are displayed.
  • Characters (“A.A” in this example) indicating that this is a talk room for talking with A as a partner are displayed.
  • user A.2 is superimposed and displayed with a second safety icon SIC2 as user-by-user safety information.
  • User D.A superimposed on the second safety icon SIC2. D icon is displayed.
  • user A Content from user D.A (as an example, but not limitation, text content of "Well then, good night!) and user D.A.
  • the content sent by D (as a non-limiting example, the text content of "See you tomorrow ⁇ ", the text content of "Shattering ⁇ Earthquake?”, The text content of "Are you okay? Have you left home yet?") are displayed.
  • the automatic response confirmation information ARI originating from the OA account (in this example, the safety confirmation response service) (as an example, not as a limitation, "This is the safety confirmation service 20XX/08/049: Information including the text "A. Mr. A's safety has been confirmed in the 39th disaster" is displayed.
  • read can be defined as the opposite term to "unread".
  • a condition for a message (content) to be read hereinafter referred to as a "read condition"
  • one of the following conditions can be applied as an example, not as a limitation.
  • D A reply was made to the message after it was displayed.
  • E If the message is a moving image message, the moving image has been reproduced.
  • F If the message is a moving image message, a certain period of time (not limited, but about several seconds to 10 seconds) has elapsed since the moving image was played.
  • the "unread” state may be defined, by way of example and not limitation, as a state in which the above read conditions are not met.
  • the "unread” state is a kind of state in which the user has not read the message (content).
  • user D As a non-limiting example, among the contents transmitted by D, based on the fact that the text content "see you tomorrow" has been read, the text "read” is displayed at the lower left of the balloon of this text content. is displayed, and based on the fact that the text content of "Shocking ⁇ Earthquake?" "Read” is not displayed.
  • An example of the talk room screen displayed on A's terminal 20A is shown on the right side of FIG. 4-2.
  • This screen differs from the talk room screen shown on the left side of FIG. A is user D. Characters (“D.D” in this example) indicating that the room is a talk room for talking with D as the other party are displayed.
  • user A Content sent by A (as a non-limiting example, the text content of ⁇ Well then, good night ⁇ '', the text content of ⁇ I'm sorry for the late reply, B. I was helping Mr. B because he injured his leg;'') and , user D. Contents from D (as a non-limiting example, the text content of "See you tomorrow ⁇ ", the text content of "Shattering ⁇ earthquake?", and the text content of "Are you okay? Have you left home yet?") are displayed.
  • user D By way of example and not limitation, of the content from user A.D, the timing after the text content "Are you okay? Are you out of the house yet?" As a non-limiting example of the content from A, the user A. Based on the fact that the automatic response mode has been canceled by A, the automatic response cancellation information ARRI with the characters "Automatic response mode canceled" is displayed between these text contents.
  • FIG. 4C is a timing chart showing an example of the timing of processing executed by each device in this embodiment.
  • An example of the process for setting Y (an example of the user of the first terminal, not limiting) as an account will be described.
  • safety confirmation processing is executed, and when terminal 20Y receives an input operation for safety confirmation registration information (Y2130), the first safety confirmation registration information is transmitted to server 10 (Y2140) (timing "TM310"). Then, the server 10 receives the first safety confirmation registration information (S2130: YES). The control unit 11 of the server 10 generates first safety information based on the first safety confirmation registration information, and transmits it to each terminal 20 (S2140) (timing "TM315"). Upon receiving the first safety information, the terminal 20X executes display processing (X2160) (timing "TM320").
  • the second safety confirmation registration information is transmitted to the server 10 (X2140) (timing "TM325"). Then, the server 10 receives the second safety confirmation registration information (S2130: YES). The control unit 11 of the server 10 generates second safety information based on the second safety confirmation registration information, and transmits it to each terminal 20 (S2140) (timing "TM330"). Upon receiving the second safety information, the terminal 20Y executes display processing (Y2160) (timing "TM335").
  • the control unit 21 of the terminal 20X causes the display unit 24 to display a judgment display indicating whether to start the automatic response (timing "TM340").
  • a judgment display indicating whether to start the automatic response (timing "TM340").
  • the control unit 21 of the terminal 20X requests to start the automatic response. Automatic response start request information for doing so is transmitted to the server 10 via the communication I/F 22 (timing "TM345").
  • the control unit 11 of the server 10 starts message automatic response processing for the terminal 20 that has transmitted the automatic response start request information (timing "TM350").
  • the control unit 21 of the terminal 20Y stores the input message, the application ID of the terminal 20Y that is the source of the message, and the application of the terminal 20X that is the destination of the message.
  • message transmission request information including the ID is transmitted to the server 10 via the communication I/F 22 (timing "TM355").
  • the control unit 11 of the server 10 determines whether or not the automatic response process for the account of the message transmission destination is being executed based on the message transmission request information. do.
  • the automatic message response process for the terminal 20X is executed between timings "TM350" to "TM375". Therefore, when it is determined that the timing at which the message transmission request information is received is after the timing "TM350" and before the timing "TM375", the control unit 11 of the server 10 receives the message automatic response information is transmitted to the terminal 20Y through the communication I/F 14 (timing "TM360").
  • the control unit 21 of the terminal 20Y displays the received automatic message response information on the display unit 24 (timing "TM365").
  • the control unit 21 of the terminal 20X issues an automatic response termination request for requesting termination of the automatic response.
  • the information is transmitted to the server 10 via the communication I/F 22 (timing "TM370").
  • the control unit 11 of the server 10 terminates the message automatic response processing for the terminal 20X (timing "TM375"). Then, the control unit 11 of the server 10 retrieves the message automatic response history information including the messages transmitted to the terminal 20X during the message automatic response processing period (in this case, between the timings "TM350" to "TM375"). It is transmitted to the terminal 20X through the communication I/F 14 (timing "TM380").
  • the control unit 21 of the terminal 20X Upon receiving the message automatic response history information from the server 10 via the communication I/F 22, the control unit 21 of the terminal 20X displays the received message automatic response history information on the display unit 24 (timing "TM385").
  • the control unit 11 of the server 10 When the control unit 11 of the server 10 receives the message transmission request information again from the terminal 20Y within the message automatic response processing period (in this case, between the timings "TM350" to "TM375"), the message automatic response information is It may not be transmitted to the terminal 20Y.
  • control unit 11 of the server 10 receives the message transmission request information for the group chat room in which the account of the terminal 20X is included within the message automatic response processing period, the control unit 11 sends the message automatic response information to each terminal 20 of the member belonging to the group. You may choose not to send to
  • the display unit 24 displays a display for determining whether or not to start the automatic response, and the automatic response start request information is transmitted to the server 10. You may do so.
  • the terminal 20 receives safety information (or safety confirmation registration information) (not limited to, terminal (an example of the third information regarding the safety of the user) is transmitted by the communication I/F 22.
  • safety information or safety confirmation registration information
  • terminal an example of the third information regarding the safety of the user
  • FIG. As an example of the effect of the embodiment obtained by such a configuration, based on the input to the terminal by the user of the terminal, the third information regarding the safety of the user of the terminal is transmitted to notify others of the safety of the user of the terminal. be able to.
  • the terminal 20 based on the transmission of the safety information, information for determining whether or not to start an automatic response to a talk (not limited, but an example of a chat) (not limited, but a chat An example of information about automatic response) is displayed on the display unit 24 . Then, the terminal 20 performs a process of transmitting automatic response start request information for requesting the start of an automatic response based on the input by the user of the own terminal 20 with respect to the information for determination, and performs an automatic response.
  • the control unit 21 can perform processing related to an automatic response to a talk (chat), such as processing to display information about the start.
  • the information related to the automatic chat response is displayed on the display unit based on the transmission of the third information, and the terminal is notified that the automatic chat response is possible. Users can be notified.
  • control unit 21 of the terminal 20X may automatically transmit automatic response start request information to the server 10 upon receiving disaster information from the server 10 .
  • the control unit 21 of the terminal 20X when receiving disaster information from the server 10, acquires the current position via the position calculation information detecting unit 29B as a non-limiting example. Then, the control unit 21 of the terminal 20X automatically responds to the server 10 when it is determined that the current location is close to the disaster occurrence location included in the disaster information (as an example, not limited, but within 10 km from the observation point of the maximum seismic intensity).
  • the start request information may be automatically transmitted.
  • the control unit 21 of the terminal 20X automatically sends automatic response start request information to the server 10. You may make it transmit.
  • the state (situation) of use of the application executed on the terminal 20X (as an example, not limitation, in use in the background), the state (situation) of position calculation by the position calculation information detection unit 29B (not limited to As an example, the terminal 20X is in a state where it is difficult to acquire a positioning satellite such as a so-called indoor environment (indoor environment), a state in which the signal strength when receiving a satellite signal from a positioning satellite is equal to or less than a set value, etc.).
  • the control unit 21 may automatically transmit the automatic response start request information to the server 10 .
  • the terminal 20 determines whether or not to start an automatic response to a talk (not a limitation, but an example of a chat) based on the state of its own terminal 20 such as the remaining battery level of its own terminal 20. (not limited to, but an example of information relating to chat automatic response) is displayed on the display unit 24 . Then, the terminal 20 performs a process of transmitting automatic response start request information for requesting the start of an automatic response based on the input by the user of the own terminal 20 with respect to the information for determination, and performs an automatic response. It shows a configuration in which the control unit 21 performs a process related to an automatic response to a talk (chat), such as a process of displaying information about the start.
  • chat a process related to an automatic response to a talk
  • information regarding automatic chat response is displayed on the display unit based on the state of the terminal, and the user of the terminal is informed that automatic chat response is possible. be able to.
  • the automatic response is terminated based on the input to the terminal 20X that initiates the automatic response, but the present invention is not limited to this.
  • the control unit 11 of the server 10 receives message transmission request information for the terminal 20X N times ("N" is a predetermined natural number) within the message automatic response processing period, the message automatic response processing is terminated. Then, the message automatic response response history information may be transmitted to the terminal 20X.
  • the message Automatic response termination suggestion information may be transmitted to suggest termination of the automatic response process.
  • the control unit 21 of the terminal 20X upon receiving the automatic response end suggestion information, causes the display unit 24 to display the received automatic response end suggestion information.
  • the control unit 21 of the terminal 20X sends the automatic response termination request information to the server when termination of the automatic response is selected based on the input operation for the displayed automatic response termination suggestion information. 10.
  • FIG. 4-4 shows an example of the talk list screen displayed on the display unit 24A of the terminal 20A of A.
  • FIG. This screen differs from the talk list screen on the right side of FIG. 4-1 in that, by way of example and not limitation, the talk room list items of the tennis circle are displayed above the talk room list items of the user F.F. F's talk room list item is displayed. Also, user F. The unread number "4" is displayed in association with F's talk room list item. Also, user F. Based on the fact that user F.F has set "safety" as safety information, user F.F. A second safety icon SIC2 is superimposed on the icon corresponding to the F talk room list item.
  • the message is sent at the oldest time among the chat room list items of the chat rooms to which other users have sent messages after being set to the auto-response mode.
  • the talk room list items corresponding to the sent chat room user B.B's talk room
  • the talk room list item corresponding to the talk room to which the message was most recently sent user FF's talk room
  • the auto-answered information in this example, a telop indicating the characters "automatically answered" is superimposed and displayed.
  • user A Based on the fact that A has received a set number of messages (10) since he turned on auto-answer mode, by way of example and not limitation, at the top of the screen, user A .
  • a push notification PN5 containing is displayed.
  • a display such as the right side of FIG. 4-4 is made.
  • This display screen is configured so that the safety registration area R1 is displayed in a raised manner by being superimposed on the talk list screen on the left side of FIG. 4-4.
  • the safety registration area R1 constitutes a safety information confirmation area for confirming the set safety information.
  • the safety information confirmation area as a non-limiting example, the text "Registered with the following contents", the text "safety message”, the user status icon ICAS (user A.A, safe), "Mitaka/bicycle "Moving with” is displayed.
  • An automatic response cancellation area for canceling the automatic response mode is configured below it.
  • the characters "Are you sure you want to release the auto-response mode?" A button indicated by letters) and a "No" button BT14 for not canceling the automatic response mode (in this example, a button indicated by letters "No") are displayed.
  • the automatic message response process is executed in the server 10, but the present invention is not limited to this.
  • the terminal 20X selected to initiate the automatic response may execute the message automatic response process.
  • FIG. 4-5 is a timing chart showing an example of the timing of processing executed by each device in this modified example.
  • the control unit 21 of the terminal 20X starts the message automatic response process ( Timing "TM410").
  • the control unit 11 of the server 10 Upon receiving the message transmission request information from the terminal 20Y through the communication I/F 14, the control unit 11 of the server 10 transmits message information to the terminal 20X based on the message transmission request information (timing "TM420").
  • the control unit 21 of the terminal 20X determines whether automatic response processing is being performed.
  • the automatic message response process in the terminal 20X is executed between timings "TM410" to "TM440". Therefore, when it is determined that the timing at which the message information is received is after the timing "TM410" and before the timing "TM440", the control unit 21 of the terminal 20X communicates the message automatic response information. It is transmitted to the terminal 20Y through the I/F 22 (timing "TM430").
  • the control unit 21 of the terminal 20X may transmit the automatic message response information to the terminal 20Y via the server 10.
  • the control unit 21 of the terminal 20X does not cause the display unit 24 to display the received message information.
  • the control unit 21 of the terminal 20X terminates the automatic response process. Then, based on the message information received during the message automatic response processing period, message automatic response response history information is generated (timing "TM440").
  • the control unit 21 of the terminal 20X displays the generated message automatic response history information on the display unit 24 (timing "TM450").
  • ⁇ Fifth embodiment> when a disaster such as a large-scale disaster occurs, one terminal 20 (hereinafter referred to as a "terminal” as appropriate) performs safety confirmation registration (as an example, not as a limitation). (input and transmission of confirmation information) is requested by the user of another terminal 20 (hereinafter referred to as a "first terminal"), an embodiment in which a safety confirmation registration request is made to the terminal based on the setting conditions. is.
  • the safety confirmation service provider can also be expressed as a provider of a safety confirmation application or a provider of the server 10 . It can also be expressed as a safety confirmation service provider in the sense of a provider that provides a safety confirmation service.
  • the safety confirmation application can be configured so that, as an example and not a limitation, requests for safety confirmation registration can be made between accounts registered in the server 10 as safety confirmation targets.
  • requests for safety confirmation registration can be made between accounts registered in the server 10 as safety confirmation targets.
  • the other accounts can refer to the registered safety confirmation information.
  • safety confirmation request account the user account that requests safety confirmation registration
  • safety confirmation request account the user account that requests safety confirmation registration for the safety confirmation request account
  • safety confirmation request account the user account that requests safety confirmation registration for the safety confirmation request account
  • one user account can serve as both a safety registration request account and a safety status registration request account.
  • the method of safety confirmation registration is not limited to the method of inputting and registering safety confirmation information using the safety confirmation application or the aforementioned messaging application.
  • a method of transmitting safety confirmation information by means of telephone, FAX, etc. without using a safety confirmation application or a messaging application or a method of transmitting safety confirmation information as a message in a messaging application. good too.
  • FIG. 5-1 The left side of FIG. 5-1 is the main menu screen of the safety confirmation application, and at the center of the top of the screen, the characters "Safety Confirmation App" are displayed as the name of the safety confirmation application.
  • An icon image and a user name (“user Y.Y” in this example) of the messaging application of the user of the terminal 20Y are displayed on the right part of the top of the screen.
  • the in-app location display area for the safety confirmation application is configured, and in this example, the characters "main menu" are displayed based on the fact that it is the main menu screen.
  • Beneath the in-app location display area is a disaster information display area that displays disaster information to notify that a disaster has occurred.
  • Disaster information is displayed.
  • user Y.Y Based on the fact that Y has set "safety" as safety information, the characters "my status" and the user status icon (user A.A, safe) are displayed.
  • a member list display area is configured in which a list of users associated with Y (hereinafter illustrated and described as “members”) is displayed.
  • safety confirmation service when an organization uses a safety confirmation application (safety confirmation service), as a non-limiting example, a user such as a representative of the organization registers members with the server 10. can be By doing so, a person belonging to the organization can be associated as a member in the safety confirmation application.
  • safety confirmation service safety confirmation service
  • the members are not by the organization but by individuals.
  • the user of the individual terminal 20 registers a member by using a phone number, an application ID, or the like, for example and not limitation. be able to.
  • the member list display area is configured to display a member list for listing members associated with the account of this terminal 20Y ("user Y.Y" in this example). .
  • the member list is user Y. Tapping with Y expands and displays those lists. Specifically, by way of example and not limitation, member icons and usernames are listed as items in the member list. In this example, by way of example and not limitation, the member list is tapped and displayed in an expanded state.
  • user X. is displayed as an item in the member list. Icon and user name corresponding to user C.X. icon and user name corresponding to user D.C. A list of icons, user names, etc. corresponding to D is displayed. Also, user X. Based on the fact that user X has not set safety information, user X. A second unknown icon UIC2 (in this example, an icon showing the characters "unknown") is superimposed on the icon corresponding to X. As shown in FIG. User C.I. Based on the fact that C.C has set the safety information to "safe", user C.C. The icon corresponding to C is superimposed with the second safety icon SIC2. User D. User D.D. A second danger icon DIC2 is superimposed on the icon corresponding to D.
  • UIC2 in this example, an icon showing the characters "unknown"
  • the display transitions to the member screen on the right side of FIG. 5-1 as an example and not as a limitation.
  • the member screen can be, for example and not limitation, a screen that displays information about the safety status of the selected user.
  • the member screen displays an icon image, a user name, information regarding safety in the safety confirmation application of each member (in this example, characters of "safety status", second unknown icon UIC2), A safety registration request button BT2a or the like for prompting the user to register safety information can be displayed.
  • the safety registration request button BT2a for user Y.X is the user Y.X.
  • the safety registration request confirmation information SRI1 shown on the left side of FIG. 5-2 is superimposed on the member screen.
  • the safety registration request confirmation information SRI1 includes, as a non-limiting example, an image related to the icon image of the safety confirmation application, the characters "A request for safety registration has been made to XX", and a request for safety registration. and an OK button indicated by an icon containing characters "OK" for confirming that the request has been made and ending the display of the safety registration request confirmation information SRI1.
  • the OK button is tapped and user Y.E. User X.Y by user X.Y. Assume that a safety registration request is made to X. In this case, user X.
  • On the terminal 20X of X by way of example and not limitation, a screen as shown on the right side of FIG. 5-2 is displayed.
  • a safety registration request confirmation area R2 is superimposed on the main menu screen displayed on the display unit 24X of the terminal 20X to notify that the safety information is requested to be set. It is displayed as raised.
  • This main menu screen differs from the main menu screen shown on the left side of FIG. 5-1 in that the icon image and user name (in this example, " User X.X”) is displayed.
  • user Y.Y A list of icons, user names, etc. corresponding to Y is displayed. Also, user Y.Y. Based on the fact that Y has set the safety information to "safe”, user Y.Y. The icon corresponding to Y is superimposed with the second safety icon SIC2.
  • FIG. 5-3 The left side of Figure 5-3 shows user Y.
  • the user Y.Y. User X.Y by user X.Y.
  • a safety registration request confirmation area is displayed on the member screen of the safety confirmation application based on the second safety registration request made to X. Since this display screen is the same as the display screen on the left side of FIG. 5-2, the description thereof is omitted.
  • a second safety registration request (which may be regarded as a safety registration reminder) is made to X.
  • user X On the terminal 20X of X, by way of example and not limitation, a screen such as that shown on the right side of FIG. 5-3 is displayed.
  • the main menu screen is displayed on the display section 24X of the terminal 20X.
  • This main menu screen corresponds to the display screen on the right side of FIG. 5-3, but the safety registration request confirmation area R2 is not displayed superimposed on the main menu screen even though the safety registration request has been made.
  • FIG. 5-4 is a flow chart showing an example of the flow of processing executed by each device in this embodiment.
  • an example of processing executed by the control unit 21 of the terminal 20X, processing executed by the control unit 21 of the terminal 20Y, and processing executed by the control unit 11 of the server 10 is shown in order from the left.
  • Safety status registration request account User X.Y of terminal 20X
  • X an example of a terminal user, not a limitation
  • control unit 21 of the terminal 20Y displays the disaster information (Y120). is displayed on the display unit 24 (Y410).
  • the control unit 21 of the terminal 20Y when it is determined that a safety registration request has been selected based on the input operation on the determination screen (Y410: YES), the control unit 21 of the terminal 20Y, as a non-limiting example, The safety registration request request information including the application ID of the safety registration request account is transmitted to the server 10 via the communication I/F 22 (Y420). If it is determined that making a safety registration request is not selected (Y410: NO), the control unit 21 of the terminal 20Y skips step Y420.
  • the control unit 11 of the server 10 transmits disaster information (S120), and determines whether or not the communication I/F 14 has received safety registration request information for the safety registration request account (S410). ). When determining that the safety registration request request information has been received (S410: YES), the control unit 11 of the server 10 determines whether or not the setting conditions regarding the safety registration request account are satisfied (S420). Setting conditions will be described later.
  • the control unit 11 of the server 10 When determining that the setting condition is satisfied (S420: YES), the control unit 11 of the server 10 transmits safety confirmation request information for requesting safety confirmation registration to the terminal 20X of the safety confirmation request account ( S430).
  • the safety registration request information may or may not include information on the safety registration request account (application ID as an example, not limitation). Further, the safety registration request information may be transmitted by directly relaying the received safety registration request information.
  • control unit 11 of the server 10 When determining that the safety registration request request information has not been received (S410: NO), the control unit 11 of the server 10 skips steps S420 to S430.
  • the control unit 21 of the terminal 20X causes the disaster information to be displayed (X120), and determines whether or not the safety registration request information has been received by the communication I/F 22 (X430).
  • the control unit 21 of the terminal 20X causes the display unit 24 to display the received safety registration request information (X440).
  • the control unit 21 of the terminal 20X skips step X440.
  • the control unit 21 of the terminal 20X, the control unit 21 of the terminal 20Y, and the control unit 11 of the server 10 determine whether or not to end the processing (X450, Y450, S450).
  • a judgment condition for terminating the process as an example, not a limitation, a case where a specific period (one week as an example, not a limitation) has passed since the date and time of the disaster, or based on the user input of the server 10 For example, when it is selected that the confirmation service is suspended.
  • control unit 21 of the terminal 20X returns the process to step X430 as an example and not as a limitation. Further, the control unit 21 of the terminal 20Y returns the process to step Y410 as an example and not as a limitation. Also, the control unit 11 of the server 10 returns the process to step S410 as an example and not as a limitation.
  • the processing of S120, X120, and Y120 may be omitted so that the server 10 does not transmit the disaster information and the terminals 20 do not display the disaster information.
  • steps X430 to X440 in the terminal 20X are not essential. This is because the terminal 20X of the safety status registration request account may be offline due to a disaster.
  • FIG. 5-5 is a timing chart showing an example of the timing of processing executed by each device in this embodiment. An example of the aforementioned setting conditions will be described using this timing chart. Here, it is assumed that the setting condition is "when the safety registration request is made for the first time to the safety registration request account".
  • the terminal 20Y performs a safety registration request operation for the terminal 20X (Y410: YES)
  • the first safety registration request information is transmitted to the server 10 (Y420) (timing "TM510").
  • the control unit 11 of the server 10 determines that the setting condition is satisfied (420: YES), and transmits the first safety registration request information to the terminal 20X (S430) (timing "TM520").
  • the control unit 11 of the terminal 20X Upon receiving the first safety registration request information, the control unit 11 of the terminal 20X displays the first safety registration request information on the display unit 24 (X440) (timing "TM530").
  • second safety registration request information is transmitted to the server 10 (Y420) (timing "TM540"). Then, the control unit 11 of the server 10 determines that the setting condition is not satisfied (S420: NO), and does not transmit the second safety registration request information to the terminal 20X.
  • the third safety registration request information is transmitted to the server 10 (Y420) (timing "TM550 ”). Then, the control unit 11 of the server 10 determines that the setting condition is not satisfied (S420: NO), and does not transmit the third safety registration request information to the terminal 20X.
  • the setting condition may be "when the N-th ("N" is a natural number) safety registration request is made to the safety registration request account".
  • the control unit 11 of the server 10 sends the safety registration request information to the safety registration request account for the first time. is transmitted to the terminal 20 of
  • the server 10 (not limited, but an example of a server that communicates with a terminal) sends first safety registration request request information ( An example of the first information, not limitation) is received by the communication I/F 14 from the terminal 20 of the user of the safety registration request account (an example of the first terminal, not limitation). Based on the received first safety registration request information and the set conditions, the server 10 communicates the first safety registration request information (not a limitation, but an example of second information regarding safety confirmation). /F14 is used to transmit to the terminal 20 of the user of the safety status registration request account.
  • Second safety confirmation information can be sent to the terminal to inquire about the safety of the user of the terminal.
  • the server 10 transmits the safety registration request information only once to the safety registration request account based on the setting conditions, but the present invention is not limited to this. As an example and not a limitation, the server 10 may transmit the safety registration request information multiple times based on the setting conditions. Also, in the above embodiment, the safety registration request account and the safety registration request account are different accounts, but the present invention is not limited to this.
  • FIG. 5-6 shows user A.A when the technique of this embodiment is applied to a messaging application.
  • An example of the home screen of the messaging application displayed on the display unit 24 of A's terminal 20A is shown.
  • the friend list includes user B. icon and user name corresponding to user C.B. icon and user name corresponding to user D.C. icon and user name corresponding to user E.D. Icon and user name corresponding to user F.E.
  • a list of icons, user names, etc. corresponding to F is displayed.
  • user B Based on the fact that B has not set safety information, user B.
  • the icon corresponding to B is superimposed with a first unknown icon UIC1 (in this example, an icon with a character “?”).
  • User C.I Based on the fact that C.C has set "dangerous" as safety information, user C.C.
  • a first danger icon DIC1 is superimposed on the icon corresponding to C.
  • User D Based on the fact that D.D has set "safety” as safety information, user D.D.
  • a first safety icon SIC1 is superimposed on the icon corresponding to D.
  • User E Based on the fact that user E.E has set "safety” as safety information, user E.E.
  • a first safety icon SIC1 is superimposed on the icon corresponding to E.
  • User F Based on the fact that user F.F has set "safety” as safety information, user F.F.
  • a first safety icon SIC1 is superimposed on the icon corresponding to F.
  • This profile screen differs from the example shown on the right side of FIG. Under the icon and user name representing B.B's profile, user B.B.
  • a second unknown icon UIC2 is displayed as information about B's safety.
  • the button for making a talk with the user the button for making a voice call with the user
  • the button for making a video call with the user the A safety registration request button BT2b similar to the safety registration request button BT2a described above is displayed to prompt the user to set safety information.
  • safety registration request confirmation information SRI2 is displayed superimposed on the profile screen as shown on the right side of FIG. 5-6, for example and not limitation.
  • the safety registration request confirmation information SRI2 includes, as a non-limiting example, an image related to the icon image of the safety confirmation application, characters "A request for safety registration has been made to BB", and a safety registration request. and an OK button indicated by an icon including characters "OK” for confirming that the request has been made and ending the display of the safety registration request confirmation information SRI2.
  • FIG. 5-7 shows user B. 3 shows an example of a talk room screen displayed on the display unit 24 of B's terminal 20B.
  • the talk room name display area includes, as an example and not as a limitation, user B.
  • Characters (“safety confirmation service" in this example) indicating that B is a talk room for talking with an OA account of a safety confirmation service registered in the messaging application as an official account are displayed. .
  • Safety registration request content RCT1 including an icon image of A, a user name, and an answer button BT4b for answering the request is displayed.
  • safety registration request confirmation information SRI3 is superimposed and displayed on the profile screen as shown in the center of FIG. 5-7 as an example and not limitation.
  • an icon image and user name (in this example, "user C.C. ”) is displayed.
  • the safety registration request confirmation information SRI3 includes, as a non-limiting example, an image related to the icon image of the safety confirmation application, characters "A request for safety registration has been made to BB", and a safety registration request.
  • An OK button indicated by an icon including characters "OK” is displayed for confirming that the request has been made and ending the display of the safety registration request confirmation information SRI3.
  • FIG. 5-8 shows user B. 3 shows an example of a talk room screen displayed on the display unit 24 of B's terminal 20B. Since this talk room screen is the same as the display screen on the left side of FIG. 5-7, the description thereof is omitted.
  • other users in this example, user D.D and user F.F
  • user B. B's terminal 20B displays, by way of example and not limitation, a talk room screen as shown on the right side of FIG. 5-8.
  • Information such as safety registration request content may be displayed on another screen, instead of being displayed on the screen of the talk room of the OA account of the safety confirmation service as described above.
  • the content of the safety registration request from A is sent to user A.A. It may be displayed on the talk room screen for talking with A, may be displayed on the friend list screen, or may be displayed on the talk list screen.
  • FIG. 5-9 is a flow chart showing an example of the flow of processing executed by each device in this modified example.
  • an example of processing executed by the control unit 21 of the terminal 20X, processing executed by the control unit 21 of the terminal 20Y, and processing executed by the control unit 11 of the server 10 is shown in order from the left.
  • control unit of each device executes safety confirmation processing (X210, Y210, S210) and then executes safety registration request processing (X480, Y480, S480).
  • FIG. 5-10 is a flowchart showing an example of safety registration request processing.
  • the view of the figure is the same as that of FIG. 5-9.
  • the control unit 21 of the terminal 20X controls, as an example and not a limitation, the user Y. of the terminal 20Y. It is determined whether or not to issue a safety registration request to the terminal 20Y by, for example, displaying on the display unit 24 a screen for determining whether or not to issue a safety registration request for requesting safety confirmation registration to the terminal 20Y. (Y4410y).
  • the control unit 21 of the terminal 20X when it is determined that making a safety registration request has been selected based on the input operation on the determination screen (X4410y: YES), the control unit 21 of the terminal 20X, as an example and not a limitation,
  • the safety registration request request information including the application ID of the terminal 20Y is transmitted to the server 10 via the communication I/F 22 (X4420y). If it is determined that making a safety registration request is not selected (X4410y: NO), the control unit 21 of the terminal 20X skips step X4420y.
  • the control unit 11 of the server 10 determines whether or not the safety registration request request information with the account of the terminal 20Y as the safety registration request account is received via the communication I/F 14 (S4410y). If it is determined that the safety status registration request request information for terminal 20Y has been received (S4410y: YES), the control unit 11 of the server 10 satisfies the composite setting condition regarding the terminal 20 (terminal 20Y in this case) of the safety status registration request account. It is determined whether or not (S4420y). Composite setting conditions will be described later.
  • the control unit 11 of the server 10 sends the safety registration request information for requesting safety confirmation registration to the terminal 20Y of the safety registration request account. (S4430y).
  • the safety registration request information may or may not include information on the safety registration request account (application ID as an example, not limitation).
  • the control unit 11 of the server 10 skips steps S4420y to S4430y.
  • the control unit 21 of the terminal 20Y controls the user X. of the terminal 20X.
  • safety registration request request information is transmitted to the server 10 (Y4410x, Y4420x). Each step can be performed similarly to X4410y and X4420y by way of example and not limitation.
  • the control unit 11 of the server 10 executes steps S4410x to S4430x using the safety status registration request account as the account of the terminal 20X.
  • Each step can be performed in the same manner as S4410y-S4430y.
  • control unit 21 of the terminal 20X executes the same processes as X4410y and X4420y using the account of the other terminal 20 as the safety status registration request account.
  • the control unit 11 of the server 10 executes the same processing as steps S4410x to S4430x while changing the safety status registration request account.
  • the control unit 21 of the terminal 20Y determines whether or not the safety registration request information has been received via the communication I/F 22 (Y4430). When determining that the safety registration request information has been received (Y4430: YES), the control unit 21 of the terminal 20Y causes the display unit 24 to display the received safety registration request information (Y4440). When determining that the safety registration request information has not been received (Y4430: NO), the control unit 21 of the terminal 20Y skips step Y4440.
  • control unit 21 of the terminal 20X, the control unit 21 of the terminal 20Y, and the control unit 11 of the server 10 determine whether to end the processing (X490, Y490, S490).
  • a judgment condition for terminating the process as an example, not a limitation, a case where a specific period (one week as an example, not a limitation) has passed since the date and time of the disaster, or based on the user input of the server 10 For example, when it is selected that the confirmation service is suspended.
  • transmission of disaster information to each terminal 20 in the server 10 and display processing of disaster information in each terminal 20 need not be executed.
  • the chat process may be executed at any timing.
  • a composite setting condition for each terminal 20 is defined as a combination of the following two conditions.
  • “Initial transmission setting conditions” Conditions for transmitting safety registration request information for the first time to the terminal 20 of the safety registration request account.
  • “Retransmission setting condition” A condition for retransmitting the safety registration request information after transmitting the safety registration request information to the terminal 20 of the safety registration request account.
  • initial transmission setting conditions include the following examples.
  • (X1) When the server 10 receives for the first time the safety registration request information for the terminal 20 of one safety registration request account.
  • (X2) When the server 10 receives the safety registration request request information for the terminal 20 of one safety registration request account L times (“L” is a natural number).
  • (X3) When the server 10 first receives the safety registration request information for the terminal 20 of one safety registration request account from the terminal 20 of one safety registration request account.
  • (X4) When the server 10 receives the safety registration request request information for the terminal 20 of one safety registration request account from the terminal 20 of one safety registration request account M times (“M” is a natural number).
  • M M times
  • the first set time (not limited to, but as an example, "every hour 0 minutes 0 seconds").
  • a first set time (not limited to, but as an example, "five minutes") has passed.
  • X7 When the server 10 receives the safety registration request request information for the terminal 20 of one safety registration request account for the first time, and then transmits the disaster information again.
  • X8 Any combination of (X1) to (X7) above.
  • the retransmission setting conditions include the following examples, not as a limitation.
  • (Y1) When the server 10 receives the safety registration request request information for the terminal 20 of one safety registration request account P times (“P” is a natural number). Note that the P times may or may not include the number of times the server 10 receives the safety registration request information until the initial transmission setting conditions are satisfied.
  • (Y2) The server 10 receives safety registration request request information for the terminal 20 of one safety registration request account for the first time from the terminal 20 of the safety registration request account different from the terminal 20 of the safety registration request account that satisfies the initial transmission setting conditions. if you did this. (Y3).
  • safety registration request information is sent Q times to the terminal 20 with one safety registration request account.
  • Q is a natural number
  • the Q times may or may not include the number of times the server 10 receives the safety registration request request information until the initial transmission setting conditions are met.
  • Y4 When the server 10 receives R times ("R" is a natural number) of safety registration request information for the terminal 20 of one safety registration request account from the terminal 20 of one safety registration request account that satisfies the initial transmission setting conditions. .
  • the R times may or may not include the number of times the server 10 receives the safety registration request information until the initial transmission setting conditions are satisfied.
  • the second set time (not limited to, but for example, "0:00:00 when the date changes" or "disaster occurrence time") +T hours later"("T" is a natural number)).
  • the second set time (not limited to, but as an example, "60 minutes") has elapsed.
  • the server 10 transmits the disaster information again after transmitting the safety registration request information to the terminal 20 of one safety registration request account.
  • (Y8) Any combination of (Y1) to (Y7) above.
  • the examples in FIGS. 5-6 to 5-8 are examples when the composite setting condition is (X1)+(Y6).
  • FIG. 5-11 is a timing chart showing an example of timing of processing executed by each device when the composite setting condition is (X1)+(Y1) as an example and not a limitation.
  • the first safety registration request request information is transmitted to the server 10 (timing "TM610"). Then, the control unit 11 of the server 10 determines that the initial transmission setting condition (X1) is satisfied, and transmits the first safety registration request information to the terminal 20X (timing "TM620"). Upon receiving the first safety registration request information, the control unit 21 of the terminal 20X causes the display unit 24 to display the first safety registration request information (timing "TM630").
  • second safety registration request information is transmitted to the server 10 (timing "TM640"). Then, the control unit 11 of the server 10 determines that the retransmission setting condition (Y1) is not satisfied, and does not transmit the second safety registration request information to the terminal 20X (timing "TM650").
  • a safety registration request request operation for the terminal 20X is executed in each terminal 20, and the server 10 receives the P+1th safety registration request request information (timing "TM660"). Then, the control unit 11 of the server 10 determines that the retransmission setting condition (Y1) is satisfied, and transmits the second safety registration request information to the terminal 20X (timing "TM670"). Upon receiving the second safety registration request information, the control unit 21 of the terminal 20X causes the display unit 24 to display the second safety registration request information (timing "TM680").
  • the initial transmission setting conditions and the retransmission setting conditions can be set according to the following concept, not as a limitation, but as an example.
  • the safety registration request information is immediately transmitted. After that, even if the retransmission setting condition is satisfied, the safety registration request information is immediately transmitted. This makes it possible to control the frequency with which the server 10 transmits the safety registration request information to the terminal 20 of the safety registration request account. can be released.
  • the composite setting condition may be a condition of only the initial transmission setting condition. In this case, the safety registration request information is not resent.
  • a condition regarding the number of retransmissions may be added to the retransmission setting condition.
  • a condition regarding the number of retransmissions as an example and not as a limitation, an upper limit number of retransmissions of the safety registration request information to the terminal 20 of the safety registration request account may be determined.
  • the setting conditions described above are based on the initial transmission setting conditions (not limited, but an example of conditions for transmitting the second information to the terminal when the server first receives the first information for the user of the terminal) and based on a retransmission setting condition (not a limitation, but an example of a first setting condition to send the second information to the terminal after first receiving the first information for the user of the terminal). showing configuration.
  • a retransmission setting condition not a limitation, but an example of a first setting condition to send the second information to the terminal after first receiving the first information for the user of the terminal.
  • the retransmission setting condition is based on the set time or the set time (time interval), and the safety registration request information (not a limitation, but an example of the second information) is sent to the safety confirmation request account. It is possible to include conditions for transmission to the user's terminal 20 . As an example of the effect of the embodiment obtained by such a configuration, based on the first information and the set time or the condition for transmitting the second information to the terminal based on the set time, the first 2 information can be sent to a terminal to inquire about the safety of the user of that terminal.
  • the retransmission setting condition is the safety registration request information received by the server 10 after the server 10 first receives the safety registration request request information (not a limitation, but an example of the first information).
  • a condition for transmitting safety registration request information (an example of second information, not limitation) to the terminal 20 of the user of the safety registration request account based on the number of safety confirmation request information (an example of the first information).
  • the second information is transmitted to the terminal based on the number of the first information received by the server. Based on the conditions, second safety confirmation information can be sent to the terminal to inquire about the safety of the user of the terminal.
  • the retransmission setting condition is based on information such as information indicating that a disaster has occurred again (not a limitation, but an example of disaster-related information) based on the safety registration request information (not a limitation, but a second information example) to the terminal 20 of the user of the safety status registration request account.
  • the second information regarding safety confirmation is transmitted to the terminal based on the first information and the condition for transmitting the second information to the terminal based on the information regarding the disaster. to inquire about the safety of the terminal user.
  • the safety registration request information (not limited, but an example of the second information) is a chat room (not limited, but a chat example of a room).
  • the second information regarding safety confirmation is displayed in a chat room that includes the terminal user, so that the terminal user can easily understand the safety information. can ask
  • the server 10 transmits the safety registration request information to the terminal 20 of the safety registration request account when the composite setting condition is satisfied, but the present invention is not limited to this. As an example and not a limitation, the server 10 does not transmit the safety registration request information to the terminal 20 of the safety registration request account even if the initial transmission setting condition and the retransmission setting condition are satisfied when the transmission stop setting condition described later is satisfied. You may do so.
  • FIG. 3 shows an example of a talk room screen displayed on the display unit 24 of B's terminal 20B. Since this talk room screen is the same as the display screen on the left side of FIG. 5-7, the description thereof is omitted.
  • the home screen shown in the center of FIG. The display transitions to the screen.
  • an icon image and user name (in this example, "user B.B. ”) is displayed.
  • the safety registration area R1 in the center of FIG. User B is tapped by user B, and the text "I am injured" is displayed as a template for the safety message.
  • the register button BT3 is activated by user B.B.
  • User A.B when tapped by user A.B.
  • An example of the talk list screen displayed on A's terminal 20A is shown on the right side of FIG. 5-12. This talk list screen is the same as the talk list screen on the right side of FIG. 1-19, so the description is omitted.
  • the icon image and user name (“User A.A" in this example) of the messaging application of the user of this terminal 20B are displayed on the right part of the top of the screen. ) is displayed. Also, user B. Below the icon and username representing B.B's profile is the user B.B. A second danger icon DIC2 is displayed as information about B's safety.
  • safety registration request confirmation information SRI4 shown in the center of FIG.
  • This safety registration request confirmation information SRI4 is the same as the safety registration request confirmation information SRI2 on the right side of FIG. 5-6, so a description thereof will be omitted.
  • user B After B has answered the safety registration request, user A.
  • User B.A Assume that a safety registration request is made to B.
  • user B. B's terminal 20B displays, by way of example and not limitation, a talk room screen as shown on the right side of FIG. 5-13.
  • the transmission stop setting conditions include the following examples, not as a limitation.
  • (Z1) When the server 10 receives the safety confirmation registration information from the terminal 20 of one safety registration request account.
  • (Z2) When the server 10 receives the safety registration request request information for the terminal 20 of one safety registration request account U times (“U” is a natural number).
  • (Z3) When the server 10 receives safety registration request information V times ("V" is a natural number) for the terminal 20 of one safety registration request account from the terminal 20 of a specific safety registration request account.
  • (Z4) When the third set time (as an example, not as a limitation, when it is "time of disaster + 72 hours later"). (Z5).
  • the third set time (not limited to, but as an example, "36 hours") has passed.
  • (Z6) When the server 10 transmits the disaster information again.
  • (Z7) Any combination of (Z1) to (Z6) above.
  • the examples in FIGS. 5-12 and 5-13 are examples when the transmission stop setting condition is (Z1).
  • FIG. 5-14 is a timing chart showing an example of the timing of processing executed by each device when the composite setting condition is (X1)+arbitrary retransmission setting condition+(Z1) as an example and not limitation. .
  • the first safety registration request request information is transmitted to the server 10 (timing "TM710"). Then, the control unit 11 of the server 10 determines that the initial transmission setting condition (X1) is satisfied, and transmits the first safety registration request information to the terminal 20X (timing "TM720"). Upon receiving the first safety registration request information, the control unit 21 of the terminal 20X causes the display unit 24 to display the first safety registration request information (timing "TM730").
  • safety confirmation processing is executed, and when an input operation of the safety confirmation registration information is received at the terminal 20X, the first safety confirmation registration information is transmitted to the server 10 (timing "TM740"). . Then, the server 10 receives the first safety confirmation registration information. The control unit 11 of the server 10 generates first safety information based on the first safety confirmation registration information, and transmits it to each terminal 20 (timing "TM750"). When the terminal 20Y receives the first safety information, the terminal 20Y executes display processing (timing "TM760").
  • second safety registration request information is transmitted to the server 10 (timing "TM770"). Then, the control unit 11 of the server 10 determines that the transmission stop setting condition (Z1) is satisfied, and does not transmit the second safety registration request information to the terminal 20X (timing "TM780").
  • control unit 21 of the terminal 20Y when the control unit 21 of the terminal 20Y receives the safety information regarding the account of the terminal 20X, it may not accept the safety registration request operation for the account of the terminal 20X thereafter.
  • the server 10 based on the transmission of safety registration request information (not limited, but an example of second information), safety confirmation registration information (not limited, third information including information on the safety of the user of the terminal) ) is received by the communication I/F 14 . Then, based on the reception of this safety confirmation registration information, the server 10 receives safety confirmation request request information (not a limitation, but an example of third information) for the safety confirmation request account after receiving this safety confirmation registration information. In this case, the control unit 11 controls not to transmit the safety registration request information based on the safety registration request information.
  • the safety of the terminal user is temporarily confirmed by not transmitting the second information based on the first information.
  • the terminal user does not have to check again, and the user of the terminal does not feel annoyed.
  • unnecessary communication can be avoided, and the amount of communication can be reduced.
  • the setting conditions are determined in the server 10, but the present invention is not limited to this.
  • the setting condition may be determined by the terminal 20 of the safety status registration request account.
  • the control unit 11 of the server 10 receives the safety registration request information for the terminal 20X of the safety registration request account from the terminal 20Y of the safety registration request account, it transmits the safety registration request information to the terminal 20X.
  • the control unit 21 of the terminal 20X determines whether or not the setting condition (composite setting condition) is satisfied. Then, when determining that the setting condition (composite setting condition) is established, the control unit 21 of the terminal 20X causes the display unit 24 to display the received safety registration request information. When determining that the setting condition (composite setting condition) is not satisfied, the control unit 21 of the terminal 20X does not display the received safety registration request information on the display unit 24 .
  • the setting conditions are determined in the server 10, but the present invention is not limited to this.
  • the setting condition may be determined by the terminal 20 of the safety registration request account.
  • the control unit 21 of the terminal 20Y of the safety registration request account determines whether or not the setting condition (composite setting condition) is satisfied when the safety registration request request operation is performed on the terminal 20X of the safety registration request account. do. Then, when determining that the setting condition (composite setting condition) is established, the control unit 21 of the terminal 20Y transmits the safety registration request information to the server 10 . When the control unit 11 of the server 10 receives the safety registration request information for the terminal 20X from the terminal 20Y, it transmits the safety registration request information to the terminal 20X. Upon receiving the safety registration request information, the control unit 21 of the terminal 20X causes the display unit 24 to display it.
  • the control unit 21 of the terminal 20Y When determining that the setting condition (composite setting condition) is not satisfied, the control unit 21 of the terminal 20Y does not transmit the safety registration request information to the server 10.
  • the setting conditions are the number of safety registration request operations on the own terminal, the time, the time after accepting the safety registration request operation on the own terminal, whether the disaster information was received again, etc. Limited to
  • the sixth embodiment is an embodiment in which the terminal 20 of the safety confirmation request account can confirm the safety confirmation request account that requested the safety confirmation request to the safety confirmation registration request account.
  • FIG. 6-1 is a diagram showing an example of a messaging application screen displayed on the display unit 24 of the terminal 20B.
  • the safety registration request content RCT6 indicated as "safety registration request" in the talk area in addition to the answer button BT4b, the safety information that requested the user (user B.B) to make a safety registration request is displayed.
  • a "friend confirmation" button BT6 is provided for confirming the registration request account (friend). When this "friend confirmation" button BT6 is tapped, a display as shown on the right side of FIG. 6-1 is made.
  • a safety registration request requesting user list area SRR including information on a safety registration requesting account that requested a safety registration request to itself (user B.B) is displayed so as to rise from the bottom of the screen.
  • the user A. A, user C. C, user D.C. D, user F. Icons and user names are displayed for four users of F, respectively.
  • An icon based on the safety status information registered by the user is superimposed on the icon of each user.
  • FIG. 6-2 is a timing chart showing, by way of example and not limitation, one example of the timing of the processing performed by each device in this embodiment.
  • FIG. 6-2 an example of processing executed by the control unit 21 of the terminal 20X, processing executed by the control unit 21 of the terminal 20Y, and processing executed by the control unit 11 of the server 10 is shown in order from the left.
  • ⁇ Safety registration request account User Y. of terminal 20Y.
  • Y's account Users of terminal 20A and terminals 20C to 20F on the display screen
  • Safety status registration request account User of terminal 20X.
  • X's account user B.X of terminal 20B on display screen. B. The processing in the case of is exemplified.
  • the first safety registration request request information is transmitted to the server 10 (timing "TM810"). Then, the control unit 11 of the server 10 determines that the initial transmission setting condition (X1) is satisfied, and transmits the first safety registration request information to the terminal 20X (timing "TM820"). Upon receiving the first safety registration request information, the control unit 21 of the terminal 20X causes the display unit 24 to display the first safety registration request information (timing "TM830").
  • the second safety registration request request information is transmitted to the server 10 .
  • the control unit 11 of the server 10 determines that the retransmission setting condition (Y1) is not satisfied, and does not transmit the second safety registration request information to the terminal 20X (timing "TM840").
  • the control unit 21 of the terminal 20X executes a safety registration request request user information request operation (timing "TM850").
  • the safety registration request request user information request operation the control unit 21 of the terminal 20X transmits the safety registration request information to the terminal 20X based on the user operation for the first safety registration request information, as an example and not a limitation. Determine whether confirmation of the registration request account has been selected.
  • the control unit 21 of the terminal 20X transmits safety registration request user information request information to the server 10 via the communication I/F 22 .
  • safety registration request user information request information When safety registration request user information request information is received from terminal 20X via communication I/F 14 (timing "TM860"), control unit 11 of server 10 sends safety registration request user list information to terminal 20X via communication I/F 14. transmit (timing "TM870").
  • the safety registration request user list information includes, as a non-limiting example, information related to the safety registration request account in the safety registration request information for the terminal 20X received before the timing "TM860" (as an example, not a limitation). (including application IDs, user names, etc.).
  • the control unit 21 of the terminal 20X Upon receiving the safety registration requesting user list information from the server 10 via the communication I/F 22, the control unit 21 of the terminal 20X displays the received safety registration requesting user list information on the display unit 24 (timing "TM880").
  • ⁇ Effects of the sixth embodiment> on the terminal 20 of the safety registration request account, based on the reception of the safety registration request information (not a limitation, but an example of the second information), the safety registration request information is displayed and the safety registration request account is displayed.
  • the display unit 24 displays a display related to the safety registration requesting account that requested the safety registration request to .
  • the server 10 transmits the safety registration request information (not limited but an example of the first information) based on the input by the user of the safety registration request account to the display.
  • a configuration is shown in which the information of the transmitted safety registration request account (not limited but an example of the information of the user who transmitted the first information) is transmitted to the terminal 20 of the safety registration request account via the communication I/F 14 .
  • a first display regarding safety confirmation is displayed on the display unit on the terminal based on the reception of the second information, and input by the user of the terminal to the first display is performed.
  • the server 10 based on the reception of the safety registration request information for the safety registration request account transmitted from the terminal 20 of one safety registration request account (an example of the first terminal, not limited),
  • the registration request information (not a limitation, but an example of the second information) is transmitted to the terminal 20 of the safety status registration request account via the communication I/F 14 .
  • the server 10 sends the safety registration request request information for the safety registration request account to another safety registration request account. terminal 20 (not limited, but an example of a second terminal) through the communication I/F 14 .
  • the server 10 sends safety registration request information based on the safety registration request information received from the terminal 20 (second terminal) of another safety registration request account to the safety registration request account.
  • the control unit 11 controls not to transmit to the terminal 20 .
  • the server 10 based on the input by the user of the safety registration request account in response to the above display, is the one safety registration request account that transmitted the safety registration request information (not a limitation, but an example of the first information).
  • information not limited, but an example of information of the user of the first terminal
  • information of another safety registration request account (not limited, but an example of information of the user of the second terminal) are received by the communication I / F 14
  • the configuration for transmission to the terminal 20 of the safety registration request account is shown.
  • the second information based on the first information received from the second terminal is not transmitted to the terminal, thereby preventing the user of the terminal from feeling annoyed.
  • the first display regarding safety confirmation is displayed on the display unit, and the first information is transmitted based on the input by the user of the terminal to the first display.
  • FIG. 6-3 is a diagram showing an example of a display screen in this modified example.
  • the left side and center of FIG. 6-3 are the same as the left side and center of FIG. 5-7, respectively.
  • the safety registration request user list information is transmitted from the server 10 to the terminal 20B at the timing described later.
  • the display on the display unit 24 of the terminal 20B is displayed as shown on the right side of FIG. 6-3. This screen corresponds to the screen on the left side of FIG. 6-3.
  • B is user A.B.
  • Safety registration request content RCT7 indicating that safety registration is requested from C and C is shown.
  • control unit 11 of the server 10 determines that the safety registration request user list information transmission condition is satisfied at any timing, it can transmit the safety registration request user list information to the terminal 20X.
  • the conditions for transmitting the safety registration request user list information are not limited to the following examples.
  • a set period of time eg, not limited to "30 minutes" has passed since the safety registration request information was last received from any one terminal 20 .
  • the set time (noon" as an example, not as a limitation) has arrived after the last safety registration request information was received from any one terminal 20;
  • safety registration request information is received from any one terminal 20 for a set number of times or more, or more than the set number of times.
  • a set period of time (“30 minutes” as an example, not a limitation) has passed since the last safety registration request information was received from each terminal 20; - When the set time (“noon” as an example, not as a limitation) has come after the last safety registration request information was received from each terminal 20; - When safety registration request information is received from each terminal 20 more than a set number of times or more than the set number of times. - When the safety confirmation registration information is received from the terminal 20X. - When transmitting the safety registration request information to the terminal 20X.
  • the processing in this modified example may be performed as follows.
  • the control unit 11 of the server 10 receives the safety registration request request information from the terminal 20 of the safety registration request account, the terminal Send information about the received safety registration request account to 20X.
  • safety registration request user information information related to a safety registration request account corresponding to individual safety registration request request information.
  • the control unit 21 of the terminal 20X when receiving the safety registration request requesting user information from the server 10, stores it in the storage unit 28 as an example and not as a limitation.
  • the control unit 21 of the terminal 20X determines that the safety registration request user display condition is satisfied, the control unit 21 causes the display unit 24 to display the safety registration request user information stored in the storage unit 28 .
  • the seventh embodiment is an embodiment in which, in the safety confirmation service, safety confirmation registration is not accepted when the safety registration period for one disaster has expired.
  • the content described in the seventh embodiment can be applied to each of the other embodiments and each of the other modifications. Moreover, the same code
  • FIG. 7-1 is a diagram showing an example of a messaging application screen displayed on the display unit 24 of the terminal 20B in this embodiment.
  • user A.A. A user C. C, user D.C. D, user F.
  • safety registration request content RCT8 indicating that safety confirmation registration is being requested by four users of F
  • safety registration due to the earthquake that occurred at "09:39 on August 4, 20XX" from the OA account is displayed.
  • Safety registration stop confirmation content SCT1 indicating that the safety registration is stopped is displayed.
  • a display as shown on the right side of FIG. 7-1 is made.
  • FIG. 7-2 is, by way of example and not limitation, a timing chart showing an example of the timing of the processing performed by each device in this embodiment.
  • FIG. 7-2 an example of processing executed by the control unit 21 of the terminal 20X, processing executed by the control unit 21 of the terminal 20Y, and processing executed by the control unit 11 of the server 10 is shown in order from the left.
  • ⁇ Safety registration request account User Y. of terminal 20Y.
  • Y's account Users of terminal 20A and terminals 20C to 20F on the display screen
  • Safety status registration request account User of terminal 20X.
  • X's account user B.X of terminal 20B on display screen. B. The processing in the case of is exemplified.
  • the first safety registration request request information is transmitted to the server 10 (timing "TM910"). Then, the control unit 11 of the server 10 determines that the initial transmission setting condition (X1) is satisfied, and transmits the first safety registration request information to the terminal 20X (timing "TM920"). Upon receiving the first safety registration request information, the control unit 21 of the terminal 20X causes the display unit 24 to display the first safety registration request information (timing "TM930").
  • control unit 11 of the server 10 executes safety confirmation registration acceptance period end processing (timing "TM940").
  • the control unit 11 of the server 10 determines whether or not to terminate the safety confirmation process and the safety registration request process based on an input operation by the user of the server 10, for example and not limitation. I do.
  • the control unit 11 of the server 10 transmits the safety information in response to the reception of the safety confirmation registration information and the safety registration request information in response to the reception of the safety registration request information. to stop sending
  • the control unit 11 of the server 10 performs the safety confirmation process and the safety registration process based on whether or not a set period has passed since the disaster occurrence date and time. It may be determined whether or not to end the request processing. Further, as an example, not limitation, the control unit 11 of the server 10 may determine whether or not to end the safety confirmation process and the safety registration request process based on the safety confirmation reception end date and time in the disaster information. good.
  • the terminal 20X accepts the safety confirmation registration information based on the input operation for the first safety registration request information
  • the first safety confirmation registration information is transmitted to the server 10 (timing "TM950”).
  • the server 10 receives the first safety confirmation registration information (timing "TM960”).
  • the terminal 20Y executes the safety registration request operation and the terminal 20X receives the safety registration request information.
  • control unit 11 of the server 10 determines to terminate the safety confirmation process and the safety registration request process at the timing "TM940", and the safety confirmation registration information is received after the timing "TM940" (as an example, not as a limitation, the timing "TM960"), and transmits safety confirmation registration acceptance period end information indicating that acceptance of safety confirmation registration has ended to the terminal 20X of the safety registration account via the communication I/F 14 (timing "TM970").
  • the control unit 21 of the terminal 20X Upon receiving the safety confirmation registration acceptance period end information from the server 10, the control unit 21 of the terminal 20X displays the received safety confirmation registration acceptance period end information on the display unit 24 (timing "TM980").
  • control unit 11 of the server 10 determines to end the safety confirmation process and the safety registration request process at the timing "TM940", and when the safety registration request request information is received after the timing "TM940", the safety confirmation registration acceptance is performed.
  • the period end information may be transmitted to the terminal 20 of the safety registration request account.
  • the control unit 11 of the server 10 when the control unit 11 of the server 10 receives the above-described safety registration request request user information request information from the terminal 20X after the timing “TM940”, the safety confirmation registration acceptance period end information is sent to the terminal 20X. 20X.
  • the above-described first display is displayed on the display unit 24 based on the reception of the safety registration request information (not a limitation, but an example of the second information) at the terminal 20 of the safety registration request account. Then, when the safety confirmation registration acceptance period (not a limitation, but an example of acceptance of safety confirmation) has ended, the server 10, based on the input by the user of the safety registration request account for the first display, Shows a configuration for transmitting safety confirmation registration acceptance period end information (not a limitation, but an example of information regarding the completion of acceptance of safety confirmation) to the terminal 20 of the user of the account requesting safety confirmation via the communication I/F 14.
  • FIG. 7-3 is a data configuration example of an account management database 155B, which is an example of the account management database 155 in this modification.
  • Account management data is stored in the account management database 155B as management data for each account.
  • Each account management data stores an application ID, friend management data, and safety registration data, for example and not limitation.
  • the application ID and friend management data can be configured in the same manner as the account management database 155A, for example and not limitation.
  • the safety registration data is data for storing registration regarding safety associated with the account of this application ID. are stored in association with each other.
  • a disaster ID is information for identifying a disaster that has occurred or disaster information that corresponds to a disaster that has occurred.
  • This disaster ID is preferably a unique value for each disaster (disaster information), and as an example and not a limitation, the server 10 sets and stores a unique value (unique value) for each disaster (disaster information). be.
  • the safety status information, safety comment information, and safety location information are set and stored as an example, not limitation, based on the safety confirmation registration information entered by the terminal 20 of the safety registration account. Arbitrary elements of the safety status information, the safety comment information, and the safety location information may be omitted.
  • FIG. 7-4 is a diagram showing an example of a messaging application screen displayed on the display unit 24 of the terminal 20B in this embodiment.
  • the screen on the left side of Figure 7-4 shows that the safety status registration will be suspended due to the earthquake that occurred at 9:39 on August 4, 20XX from the OA account (not a limitation, but an example of the first disaster).
  • Below the registration stop confirmation content SCT1 disaster occurrence content DCT2 indicating that an earthquake (not a limitation, but an example of a second disaster) occurred at "19:23 on August 14, 20XX" from the OA account is displayed.
  • the answer button BT4b in the safety registration request content RCT8 is tapped, a display such as that shown in the center of FIG. 7-4 is displayed.
  • Safety registration confirmation information RCI1 is displayed in a pop-up format in the center of the screen.
  • the "OK" button included in this information is tapped to return the display to the home screen, the display shown on the right side of FIG. 7-4 is displayed.
  • a safety registration area R1 for performing safety registration is displayed so as to rise from the bottom of the home screen.
  • An example of the configuration of the safety registration area R1 is as described above, so description thereof will be omitted.
  • FIG. 7-5 is a timing chart showing, by way of example and not limitation, one example of the timing of the processing performed by each device in this embodiment.
  • the control unit 11 of the server 10 performs first disaster safety confirmation registration for starting safety confirmation processing and safety registration request processing in the first disaster based on an input operation by the user of the server 10. Acceptance processing is executed (timing "TM1005").
  • the control unit 11 of the server 10 generates a disaster ID for linking with the first disaster.
  • the control unit 11 of the server 10 may transmit the first disaster information to each terminal 20 along with the first disaster safety confirmation registration acceptance process.
  • the first disaster information may include the disaster ID associated with the first disaster.
  • control unit 11 of the server 10 may execute the first disaster safety confirmation registration acceptance process based on the disaster situation information received from the disaster information server (not shown).
  • the first safety registration request request information is transmitted to the server 10 (timing "TM1010"). Then, the control unit 11 of the server 10 determines that the initial transmission setting condition is satisfied, and transmits the first safety registration request information to the terminal 20X (timing "TM1015"). Upon receiving the first safety registration request information, the control unit 21 of the terminal 20X causes the display unit 24 to display the first safety registration request information (timing "TM1020").
  • control unit 11 of the server 10 executes safety confirmation registration acceptance period end processing for the first disaster (timing "TM1025"). After that, the control unit 11 of the server 10 executes the second disaster safety confirmation registration acceptance process for starting the safety confirmation process and the safety registration request process in the second disaster (timing "TM1030"). Note that the control unit 11 of the server 10 may transmit the second disaster information to each terminal 20 along with the second disaster safety confirmation registration acceptance process. Also, the second disaster information may include the disaster ID associated with the second disaster.
  • the terminal 20X accepts the safety confirmation registration information based on the input operation for the first safety registration request information
  • the first safety confirmation registration information is transmitted to the server 10 (timing "TM1035").
  • the server 10 receives the first safety confirmation registration information (timing "TM1040").
  • the first safety confirmation registration information may include the disaster ID associated with the first disaster.
  • the terminal 20Y executes the safety registration request operation and the terminal 20X receives the first safety registration request information.
  • the control unit 11 of the server 10 determines to end the safety confirmation process and the safety registration request process for the first disaster at the timing "TM1025", and includes the disaster ID linked to the first disaster after the timing "TM1025".
  • the safety confirmation registration information is received (as an example, not as a limitation, timing "TM1040")
  • the first disaster safety confirmation registration reception period end information indicating that the reception of safety confirmation registration for the first disaster has been completed It is transmitted to the terminal 20X of the safety registration account by F14 (timing "TM1045").
  • the control unit 11 of the server 10 transmits the first disaster safety confirmation registration acceptance period end information
  • the safety confirmation for the second disaster is transmitted to the terminal 20X of the safety registration account (timing "TM1050").
  • the second disaster safety confirmation registration acceptance start information may include the disaster ID associated with the second disaster.
  • the control unit 21 of the terminal 20X Upon receiving the first disaster safety confirmation registration acceptance period end information from the server 10, the control unit 21 of the terminal 20X displays the received first disaster safety confirmation registration acceptance period end information on the display unit 24 (timing "TM1055"). . Further, when receiving the second disaster safety confirmation registration reception start information from the server 10, the control unit 21 of the terminal 20X displays the received second disaster safety confirmation registration reception start information on the display unit 24 (TM1050).
  • the second disaster safety confirmation registration reception start information may be information indicating that a new safety confirmation registration different from the first disaster has started, or information indicating that safety confirmation registration for the second disaster including the second disaster information has started. It may be information related to acceptance display.
  • control unit 11 of the server 10 determines to end the safety confirmation process and the safety registration request process for the first disaster at the timing "TM1025", and after the timing "TM1025", the safety registration associated with the first disaster is completed.
  • the request request information is received, the first disaster safety confirmation registration acceptance period end information may be transmitted to the terminal 20 of the safety registration request account.
  • control unit 11 of the server 10 may transmit the safety registration request request for the second disaster to the terminal 20 of the victim's safety registration request account. good.
  • the safety confirmation registration information is sent from the terminal 20.
  • the first disaster safety confirmation registration acceptance period end information may be transmitted to each terminal 20 without receiving it.
  • the control unit 21 of the terminal 20X may perform control so as not to accept the safety confirmation registration for the first disaster upon receiving the first disaster safety confirmation registration acceptance period end information.
  • the control unit 11 of the server 10 determines that the timing at which the first safety confirmation registration information is received is after the timing "TM1025" and before the timing "TM1030". , the first disaster safety confirmation registration acceptance period end information may be transmitted to the terminal 20X of the safety registration account. Further, when the disaster ID is not included in the first safety confirmation registration information and the timing at which the first safety confirmation registration information is received is after the timing "TM1025" and after the timing "TM1030", the control unit 11 of the server 10 , based on the received first safety confirmation registration information, safety information for the second disaster may be generated and transmitted to each terminal 20 .
  • the control unit 11 of the server 10 when the control unit 11 of the server 10 receives the safety registration request user information request information for the first disaster from the terminal 20X after the timing "TM1030", the first disaster safety confirmation registration acceptance The period end information and the second disaster safety confirmation registration acceptance start information may be transmitted to the terminal 20X.
  • This modified example is a safety registration request based on the safety registration request information (not limited, but an example of the first information) for one disaster (not limited, but an example of the first disaster) on the terminal 20 of the safety registration account.
  • the first display described above is displayed on the display unit 24 for the one disaster.
  • the server 10 starts the safety confirmation registration acceptance period for one disaster (not a limitation, but an example of acceptance of a safety confirmation for the first disaster) ends, and another disaster (not a limitation, but an example of a second disaster).
  • the safety confirmation registration acceptance period (not a limitation, but an example of acceptance of safety confirmation for the second disaster) has started, based on the input by the user of the safety registration request account for the first display, the first Disaster safety confirmation registration acceptance period end information (not limited, but an example of information about the end of acceptance of safety confirmation for the first disaster) and second disaster safety confirmation registration acceptance start information (not limited, second An example of information about the start of acceptance of disaster safety confirmation) is transmitted to the terminal 20 of the user of the safety confirmation request account via the communication I/F 14.
  • the terminal displays a first display regarding safety confirmation on the display unit based on the reception of the second information based on the first information of the first disaster,
  • the acceptance of the safety confirmation for the first disaster ends based on the input by the terminal user for the first display. and information about the start of acceptance of safety confirmation for the second disaster to the terminal.
  • the above-described first display is displayed on the display unit 24 based on the reception of the safety registration request information (not limited, but an example of the second information) at the terminal 20 of the safety registration request account. .
  • the server 10 receives information, through the communication I/F 14, indicating that the input to the first display is not accepted.
  • the configuration for transmission to the terminal 20 of the safety registration request account is shown.
  • the safety registration request information may include information regarding a safety registration period (a period during which safety registration is possible) and a safety registration time limit (end of safety registration).
  • these pieces of information may be information on the display period for displaying the above-described first display on the display unit 24 (information on the display time limit). Further, it may be information (information on an input deadline) regarding an input period in which an input for answering a safety confirmation (safety registration) can be made from the first display described above.
  • FIG. 7-6 shows an example of a messaging application screen displayed on the display unit 24 of the terminal 20B in this modification.
  • the safety registration request content RCT9 in the talk area includes a reply button BT4c including information on the remaining time until the reply deadline as information on the reply period during which the safety confirmation reply can be made.
  • the safety registration stop confirmation content SCT1 indicating that the safety registration will be stopped due to the earthquake that occurred at "9:39 on August 4, 20XX" from the OA account is displayed. It is In addition, the display of the information about the reply period in the reply button BT4c of the safety registration request content RCT9 is erased, and the reply button BT4c is grayed out. I can't do it.
  • the control unit 21 of the terminal 20X prompts the user to input the safety confirmation registration information based on the input to the safety registration request information, as an example, not as a limitation. You can choose not to accept it.
  • the safety registration request information includes information regarding the safety registration period, the safety registration deadline, and the like. Then, on the terminal 20 of the safety registration request account, the first display described above is displayed on the display unit 24 based on the reception of this safety registration request information (not a limitation, but an example of the second information).
  • this safety registration request information not a limitation, but an example of the second information.
  • information on the expiration date for which the first display is displayed on the display unit of the terminal, or information on the expiration date that can be input to the first display is displayed.
  • a first indication regarding safety confirmation may be displayed to allow the user of the terminal to confirm the first indication.
  • the server 10 determines whether or not to accept safety confirmation registration for one disaster, but the present invention is not limited to this.
  • each terminal 20 may be configured to be able to determine whether or not to accept safety confirmation registration and safety registration request requests.
  • the control unit 11 of the server 10 transmits the disaster information to each terminal 20 including information regarding the acceptance deadline for safety confirmation registration for the disaster. Then, the control unit 21 of each terminal 20 determines whether or not to accept the safety confirmation registration information or the safety registration request request at the time of the safety confirmation registration operation or the safety registration request request operation based on the received information about the safety confirmation registration acceptance deadline. can be determined. As an example and not a limitation, the control unit 21 of each terminal 20 can be configured not to accept transmission of safety confirmation registration information or a safety registration request request when the acceptance deadline has passed.
  • the registered safety information may be displayed on the terminal 20 of the safety reference account, or may not be displayed.
  • the eighth embodiment relates to blocking of members in the safety confirmation service or friends in the messaging application.
  • a user account to be blocked is referred to as a "blocked account”
  • a user account that blocks content sent from a blocked account is referred to as a "block execution account”.
  • FIG. 8-1 is a diagram showing an example of a messaging application screen displayed on the display unit 24 of the terminal 20 in this embodiment.
  • the left side of FIG. 8-1 is the home screen of the messaging application displayed on the display unit 24 of the terminal 20B.
  • the danger button DBT is tapped in the safety registration area R1
  • the safety message "I am injured” and the current location are displayed.
  • a state in which "Tsukuba City” is input and the registration button BT3 is tapped is shown.
  • the center of FIG. 8-1 is the talk list screen of the messaging application displayed on the display unit 24 of the terminal 20A in this case.
  • User A. A is user B. B and not blocked by user B.B on the talk list.
  • the aforementioned composite safety information "Tsukuba/I was injured" is displayed.
  • FIG. 8-1 is the talk list screen of the messaging application displayed on the display unit 24 of the terminal 20G in this case.
  • User G. G is user B.G. 8-1, and unlike the screen of terminal 20A in the center of FIG. 8-1, user B.B on the talk list User B.B on which the second danger icon DIC2 is superimposed. Only the icon image of B and the user name are displayed. In other words, the composite safety information "Tsukuba/I'm injured" is not displayed, and although it is known that it is "dangerous", the safety message and whereabouts are unknown.
  • the safety location information or the safety comment information may be displayed instead of not being displayed.
  • FIG. 8-2 is a timing chart showing, by way of example and not limitation, one example of the timing of the processing performed by each device in this embodiment.
  • FIG. 8-2 an example of processing executed by the control unit 21 of the terminal 20X, processing executed by the control unit 21 of the terminal 20Y, and processing executed by the control unit 11 of the server 10 is shown in order from the left.
  • the control unit 21 of the terminal 20X sends block request information for blocking content from the block target account (in this case, the account of the terminal 20Y) to the server through the communication I/F 22 based on the user's operation. 10 (timing "TM1105").
  • the block request information may include the application ID of the terminal 20Y.
  • the control unit 11 of the server 10 Upon receiving the block request information from the terminal 20X through the communication I/F 14, the control unit 11 of the server 10 executes block processing (timing "TM1110"). After executing the block process, as an example and not as a limitation, in the chat process, if the control unit 11 of the server 10 receives message transmission request information from the terminal 20Y to the terminal 20X, the control unit 11 sends message information based on the message transmission request information to the terminal 20X. do not send
  • the first safety registration request request information is transmitted to the server 10 (timing "TM1115"). Then, the control unit 11 of the server 10 determines that the initial transmission setting condition is satisfied, and transmits the first safety registration request information to the terminal 20X (timing "TM1120"). Upon receiving the first safety registration request information, the control unit 21 of the terminal 20X causes the display unit 24 to display the first safety registration request information (timing "TM1125").
  • the control unit 11 of the server 10 When receiving safety registration request information from the terminal 20Y of the blocked account to the terminal 20X of the block execution account, the control unit 11 of the server 10 does not transmit the safety registration request information to the terminal 20X of the block execution account.
  • the control unit 21 of the terminal 20X receives safety status information based on an input operation on the second display in the first safety registration request information, and receives the received first safety status information.
  • the status information is transmitted to the server 10 through the communication I/F 22 (timing "TM1130").
  • the control unit 21 of the terminal 20X accepts safety comment information based on an input operation on the third display in the first safety registration request information, and receives the received first safety comment information.
  • safety comment information is sent to the server 10 via the communication I/F 22 (timing "TM1135").
  • the second display and the third display are not limited to being included in the same display screen as illustrated in the screen diagrams.
  • the control unit 21 of the terminal 20X may display the third display on the display unit 24 and accept the input operation for the third display when the input operation for the second display is performed.
  • the control unit 11 of the server 10 receives the first safety status information and the first safety comment information from the terminal 20X. Then, the control unit 11 of the server 10 transmits the first safety information including only the first safety status information to the terminal 20Y of the blocked account (timing "TM1140"). In addition, the control unit 11 of the server 10 transmits the first safety information including the first safety status information and the first safety comment information to each terminal 20 other than the blocked account (timing "TM1150"). .
  • the control unit 21 of the terminal 20Y Upon receiving the first safety information including only the first safety status information from the server 10, the control unit 21 of the terminal 20Y displays the received first safety information on the display unit 24 (timing "TM1145").
  • the combinations of safety confirmation registration information received in the second display and the third display are not limited to the above combinations.
  • the safety registration information input to the second display is referred to as "first safety information”
  • the safety registration information input to the third display is referred to as "second safety information”.
  • first safety information and the second safety information are input to the terminal 20 of the blocked account
  • safety information including only the first safety information is transmitted to the terminal 20 of the blocked account.
  • safety information including the first safety information and the second safety information is transmitted to each terminal 20 other than the blocked account.
  • Safety information including the first safety information and the second safety information may be transmitted to the terminal 20 of the blocked account.
  • FIG. 8-3 is a table showing combinations of first safety information and second safety information.
  • safety status information, safety comment information, and safety location information are used as components of the safety registration information.
  • safety location information can be defined.
  • the example of FIG. 8-1 corresponds to the case of pattern (C).
  • patterns (A) to (C) safety status information is displayed on the terminal 20 of the blocked account, but safety comment information and safety location information are not displayed.
  • safety confirmation registration inputting safety comment information and safety location information is more time-consuming than inputting safety status information. It is highly conceivable to omit the entry of location information. Therefore, when only safety status information is displayed on the terminal 20 of the blocked account, it is possible to distinguish whether safety comment information and safety location information are not displayed or input by the user of the blocked account. Can not do it. Therefore, it is difficult for the user of the account to be blocked to recognize that the user of the block execution account has blocked it.
  • the control unit 11 of the server 10 When receiving safety confirmation registration information from the terminal 20X of the block execution account, the control unit 11 of the server 10 does not transmit the safety confirmation information based on the received safety confirmation registration information to the terminal 20Y of the block target account. good too.
  • the first display described above is displayed on the display unit 24 based on the reception of the safety registration request information (not a limitation, but an example of the second information) at the terminal 20 of the safety registration request account.
  • a second display and a third display different from the second display are displayed on the display unit 24 based on an input for one display.
  • the server 10 Based on the input to the second display displayed on the terminal 20 of the safety confirmation request account, the server 10 receives the first safety information (not limited to, the first (an example of safety information) is received by the communication I/F 14, and based on the input to the third display, another safety information (not limited to, the second safety information ) is received by the communication I/F 14 .
  • the server 10 identifies a user associated with the user of the safety status registration request account, such as being registered as a friend by the user of the safety status registration request account (not limited, but an example of a user associated with the user of the terminal).
  • first safety information first safety information
  • second safety information other safety information
  • the first safety information regarding the safety input by the user of the terminal is received from the terminal, and based on the input for the third display, the second safety information regarding the safety input by the user of the terminal is received.
  • Safety information can be received.
  • the first safety information can be transmitted to a user associated with the user of the terminal to notify the user of the terminal of the safety of the terminal.
  • the second safety information can be sent to a user set by the user of the terminal to inform the safety of the user of the terminal.
  • the user set by the user of the safety status registration request account is the user who is associated with the user of the safety status registration request account, such as being registered as a friend by the user of the safety It is possible to include users other than users blocked by the user of the safety registration request account.
  • the users set by the terminal user include users other than the users blocked by the terminal user among the users associated with the terminal user.
  • the second safety information can be transmitted to users other than users blocked by the user of the terminal.
  • safety information including only the first safety information is transmitted to the terminals 20 of the blocked accounts, and the first safety information and the second safety information are transmitted to the terminals 20 other than the blocked accounts.
  • the safety information is transmitted, the present invention is not limited to this.
  • safety information including first safety information and second safety information is transmitted to each terminal 20, but only the first safety information is displayed on the terminal 20 of the blocked account. can be
  • the control unit 11 of the server 10 when the control unit 11 of the server 10 receives the block request information from the block execution account terminal 20X, the block execution account information (as an example, not a limitation) is sent to the block target account terminal 20Y. , application ID).
  • the control unit 21 of the terminal 20Y of the blocked account after receiving the safety display block request information, sets the block execution account as the safety registration account, and sends the safety information including the first safety information and the second safety information.
  • only the first safety information is displayed on the display unit 24 .
  • the ninth embodiment is an embodiment in which it is possible to easily view the safety confirmation registration status of members in the safety confirmation service or friends in the messaging application.
  • FIG. 9-1 is a diagram showing an example of a messaging application screen displayed on the display unit 24 of the terminal 20B in this embodiment.
  • the left side of FIG. 9-1 is the chat screen with the OA account of the messaging application described above, and in this example, a state in which the safety registration request content RCT1 from the OA is tapped is shown. In this case, the home screen on the right side of FIG. 9-1 is displayed.
  • This home screen is the home screen of the messaging application, and user A. Icon and user name corresponding to user D.A. icon and user name corresponding to user F.D. icon and user name corresponding to user G.F. An icon corresponding to G, a user name, etc. are displayed. Further, each user's icon is associated with the first safety icon, the first danger icon, and the first unknown icon as icons indicating the safety information registered by the user. That is, the list screen of the safety confirmation registration status is displayed.
  • the safety registration button BT1 is highlighted (blinking as an example, not a limitation) based on the fact that B has not yet registered his safety.
  • the screen transitions to the safety confirmation registration status list screen based on the user's operation on the safety registration request information, but the present invention is not limited to this.
  • the screen may transition to the safety confirmation registration screen based on a user operation on the push notification of the safety confirmation application or messaging application.
  • FIG. 9B is a diagram showing an example of a screen displayed on the display unit 24 of the terminal 20B in this modified example.
  • the left side of FIG. 9-2 shows a message list screen of the messaging application displayed on the display unit 24 of the terminal 20B.
  • the safety registration button BT1 is displayed because B has not yet registered his safety. Under it, user B.
  • a list of icons and user names of users who have made a safety registration request to B is displayed.
  • a lock screen like the one shown in the center of Figure 9-2 is displayed.
  • a push notification PN7 of safety registration request information originating from a messaging application is displayed on the lock screen as an application push.
  • this push notification PN7 is tapped, by way of example and not limitation, the home screen of the messaging application on the right side of FIG. 9-2 is displayed.
  • the safety registration area R1 is displayed so as to rise from the bottom of the screen, and is configured so that safety registration can be performed immediately.
  • safety registration request information may be displayed at the top of any chat room screen. Then, based on the user's operation on the safety registration request information displayed at the top, the screen may be changed to the safety confirmation registration screen.
  • the safety confirmation registration information entered by the safety registration account is used for transmitting safety information to the user of the safety confirmation application or messaging application, but the present invention is not limited to this.
  • the control unit 11 of the server 10 may aggregate safety confirmation registration information received from each terminal 20 and use the aggregation result as big data for rescue activities.
  • control unit 11 of the server 10 aggregates the safety status information and the safety location information received from each terminal 20, and determines the bias in areas where the safety status information is "dangerous". Then, the control unit 11 of the server 10 calculates the rescue target area information, which is the position information regarding the area where "dangerous" is frequently input. The control unit 11 of the server 10 may cause the display unit 13 to display the calculated rescue target area information.
  • control unit 11 of the server 10 may transmit the calculated rescue target area information to the disaster response headquarters server (not shown) via the communication I/F 14 .
  • request information As an example and not a limitation, an example of a request to prompt repayment of a debt (hereinafter referred to as a “request”) will be illustrated as request information. Further, hereinafter, the account of the user who is forced to repay the debt is referred to as “requested request account”, and the account of the user who requests repayment of the debt to the requested request account is referred to as “requested request account”.
  • the desired request account is a plurality of accounts, which are referred to as a "first desired request account” and a "second desired request account” as an example and not as a limitation.
  • the terminal 20 of the first demand request account transmits to the server 10 first demand request information for conveying a demand to the demand request account based on the user's operation.
  • the control unit 11 of the server 10 determines whether or not the setting condition (composite setting condition) is satisfied. Then, when determining that the setting condition (composite setting condition) is established, the control unit 11 of the server 10 receives the first request information (in this example, prompting repayment of the debt) based on the first request request information. information) to the terminal 20 of the requested request account.
  • the control unit 21 of the terminal 20 of the requested request account causes the display unit 24 to display the received first request information.
  • the terminal 20 of the second demand requesting account transmits to the server 10 the second demand request information for conveying the demand to the requested requesting account based on the user's operation as an example and not limitation.
  • the control unit 11 of the server 10 determines whether or not the setting condition (composite setting condition) is satisfied. When determining that the setting condition (composite setting condition) is satisfied, the control unit 11 of the server 10 transmits the second request information based on the second request request information to the terminal 20 of the requested request account. do.
  • the control unit 21 of the terminal 20 of the requested request account causes the display unit 24 to display the received second request information.
  • the control unit 11 of the server 10 does not transmit the second request information based on the second request request information to the terminal 20 of the requested request account.
  • the presence or absence of request information transmission based on the request information at an arbitrary timing can be controlled in the same manner as the control based on the composite setting conditions in the fifth embodiment, as an example and not as a limitation. That is, considering the above embodiment, when receiving the safety registration request request information for one requested request account for the first time, the server 10 transmits the request information to the terminal 20 of the requested request account. Then, when the server 10 receives the safety registration request request information for the requested request account after that, it is possible to implement control such that the request information is not transmitted to the terminal 20 of the requested request account again.
  • the server 10 when the server 10 receives the safety registration request request information for the requested request account and satisfies a predetermined condition, the server 10 can perform control such that, as a reminder, the request information is sent again to the terminal 20 of the requested request account. .
  • the terminal 20 of the request requesting account may transmit to the server 10 a transmission request for any content (referred to as “content transmission request information") to the terminal 20 of the requested request account.
  • content transmission request information any content
  • the control unit 11 of the server 10 controls whether or not to transmit the content information based on the content transmission request information to the terminal 20 of the request request account based on the composite setting condition.
  • the server 10 communicating with the terminal 20 of the requested request account sends information (not limited to, An example of first information relating to a request to transmit content) is received from the terminal 20 (not limited to, but an example of a first terminal) of one demand request account. Then, the server 10 transmits the information regarding the content to the terminal 20 of the requested request account via the communication I/F 14 based on the received information regarding the content transmission request. In addition, the server 10 sends information (not a limitation, but an example of first information relating to a content transmission request) to the user of the terminal 20 of the requested request account to the terminal 20 of the other demand request account. (an example, but not a limitation, of a second terminal).
  • the server 10 is configured to transmit the information about the content to the terminal 20 of the requested request account via the communication I/F 14 based on the received information about the content transmission request and the set conditions.
  • second information regarding the content is generated based on the first information.
  • to the terminal may prompt, by way of example and not limitation, the user of the terminal to send the content.
  • second information about the content is transmitted to the terminal. , by way of example and not limitation, the user of the terminal may be prompted to send content.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Signal Processing (AREA)
  • Emergency Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Tourism & Hospitality (AREA)
  • Educational Administration (AREA)
  • Economics (AREA)
  • General Life Sciences & Earth Sciences (AREA)
  • Development Economics (AREA)
  • Environmental & Geological Engineering (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Geology (AREA)
  • General Health & Medical Sciences (AREA)
  • Human Resources & Organizations (AREA)
  • Marketing (AREA)
  • Primary Health Care (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Telephonic Communication Services (AREA)

Abstract

安否確認に関する利便性等を向上させる。 第１端末のユーザとのチャットに関連する処理を行う端末によって実行されるプログラムは、第１端末のユーザによる第１端末に対する入力に基づいて、第１端末のユーザの安否に関する第１情報を端末の通信部によって受信することと、第１端末のユーザに関連するチャットの情報に関連付けられた第１情報を端末の表示部に表示することとが端末によって実行される。

Description

プログラム、情報処理方法、端末、サーバ
　本開示は、プログラム、情報処理方法、端末、サーバ等に関する。
　災害発生時に携帯端末を用いて警報を報知する技術がある（例えば、特許文献１）。
特開２０１６－１５１７９９号公報
　本発明の第１の態様によると、第１端末のユーザとのチャットに関連する処理を行う端末によって実行されるプログラムは、第１端末のユーザによる第１端末に対する入力に基づいて、第１端末のユーザの安否に関する第１情報を端末の通信部によって受信することと、第１端末のユーザに関連するチャットの情報に関連付けられた第１情報を端末の表示部に表示することとが端末によって実行される。
　本発明の第２の態様によると、第１端末のユーザとのチャットに関連する処理を行う端末の情報処理方法は、第１端末のユーザによる第１端末に対する入力に基づいて、第１端末のユーザの安否に関する第１情報を端末の通信部によって受信することと、第１端末のユーザに関連するチャットの情報に関連付けられた第１情報を端末の表示部に表示することとを含む。
　本発明の第３の態様によると、第１端末のユーザとのチャットに関連する処理を行う端末は、第１端末のユーザによる第１端末に対する入力に基づいて、第１端末のユーザの安否に関する第１情報を受信する通信部と、第１端末のユーザに関連するチャットの情報に関連付けられた第１情報を表示する表示部とを備える。
　本発明の第４の態様によると、第１端末のユーザとのチャットに関連する処理を行う端末は、メモリに記憶されたプログラムを読み出し、プログラムに基づく処理を実行するプロセッサーを備え、プロセッサーは、第１端末のユーザによる第１端末に対する入力に基づいて、第１端末のユーザの安否に関する第１情報を端末の通信部によって受信することと、第１端末のユーザに関連するチャットの情報に関連付けられた第１情報を端末の表示部に表示することとを実行する。
　本発明の第５の態様によると、端末と通信するサーバによって実行されるプログラムは、端末のユーザに対する安否確認の依頼に関する第１情報をサーバの通信部によって第１端末から受信することと、第１情報と設定された条件とに基づき、安否確認に関する第２情報を通信部によって端末に送信することとがサーバによって実行される。
　本発明の第６の態様によると、端末と通信するサーバの情報処理方法は、端末のユーザに対する安否確認の依頼に関する第１情報をサーバの通信部によって第１端末から受信することと、第１情報と設定された条件とに基づき、安否確認に関する第２情報を通信部によって端末に送信することとを含む。
　本発明の第７の態様によると、端末と通信するサーバは、端末のユーザに対する安否確認の依頼に関する第１情報を第１端末から受信し、第１情報と設定された条件とに基づき、安否確認に関する第２情報を端末に送信する通信部を備える。
　本発明の第８の態様によると、端末と通信するサーバは、メモリに記憶されたプログラムを読み出し、プログラムに基づく処理を実行するプロセッサーを備え、プロセッサーは、端末のユーザに対する安否確認の依頼に関する第１情報をサーバの通信部によって第１端末から受信することと、第１情報と設定された条件とに基づき、安否確認に関する第２情報を通信部によって端末に送信することとを実行する。
　本発明の第９の態様によると、端末と通信するサーバによって実行されるプログラムは、端末のユーザに対するコンテンツの送信の依頼に関する第１情報を第１端末からサーバの通信部によって受信することと、第１情報に基づき、コンテンツに関する第２情報を端末に通信部によって送信することと、端末のユーザに対する第１情報を第２端末からサーバの通信部によって受信することと、第１情報と設定された条件とに基づき、第２情報を端末に通信部によって送信することとがサーバによって実行される。
実施形態に係る通信システムのシステム構成の一例を示す図。 第１実施例に係るサーバの制御部によって実現される機能の一例を示す図。 第１実施例に係るサーバの記憶部に記憶される情報等の一例を示す図。 第１実施例に係るアカウント登録データの一例を示す図。 第１実施例に係るアカウント管理データベースの一例を示す図。 第１実施例に係る端末の制御部によって実現される機能の一例を示す図。 第１実施例に係る端末の記憶部に記憶される情報等の一例を示す図。 第１実施例に係る端末の表示部に表示される画面の一例を示す図。 第１実施例に係る端末の表示部に表示される画面の一例を示す図。 第１実施例に係る端末の表示部に表示される画面の一例を示す図。 第１実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第１変形例に係る端末の表示部に表示される画面の一例を示す図。 第１変形例に係る端末の表示部に表示される画面の一例を示す図。 第１変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第１変形例に係るサーバの記憶部に記憶される情報等の一例を示す図。 第１変形例に係るグループ管理データベースの一例を示す図。 第１変形例に係る端末の表示部に表示される画面の一例を示す図。 第１変形例に係る端末の表示部に表示される画面の一例を示す図。 第１変形例に係る端末の表示部に表示される画面の一例を示す図。 第２実施例に係る端末の表示部に表示される画面の一例を示す図。 第２実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第２実施例に係る安否確認処理の流れの一例を示すフローチャート。 第２実施例に係る各装置が実行する処理のタイミングの一例を示す図。 第２変形例に係る端末の表示部に表示される画面の一例を示す図。 第２変形例に係る各装置が実行する処理のタイミングの一例を示す図。 第２変形例に係る端末の表示部に表示される画面の一例を示す図。 第３実施例に係る端末の表示部に表示される画面の一例を示す図。 第３実施例に係る端末の表示部に表示される画面の一例を示す図。 第３実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第４実施例に係る端末の表示部に表示される画面の一例を示す図。 第４実施例に係る端末の表示部に表示される画面の一例を示す図。 第４実施例に係る各装置が実行する処理のタイミングの一例を示す図。 第４変形例に係る端末の表示部に表示される画面の一例を示す図。 第４変形例に係る各装置が実行する処理のタイミングの一例を示す図。 第５実施例に係る端末の表示部に表示される画面の一例を示す図。 第５実施例に係る端末の表示部に表示される画面の一例を示す図。 第５実施例に係る端末の表示部に表示される画面の一例を示す図。 第５実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第５実施例に係る各装置が実行する処理のタイミングの一例を示す図。 第５変形例に係る端末の表示部に表示される画面の一例を示す図。 第５変形例に係る端末の表示部に表示される画面の一例を示す図。 第５変形例に係る端末の表示部に表示される画面の一例を示す図。 第５変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第５変形例に係る安否登録リクエスト処理の流れの一例を示すフローチャート。 第５変形例に係る各装置が実行する処理のタイミングの一例を示す図。 第５変形例に係る端末の表示部に表示される画面の一例を示す図。 第５変形例に係る端末の表示部に表示される画面の一例を示す図。 第５変形例に係る各装置が実行する処理のタイミングの一例を示す図。 第６実施例に係る端末の表示部に表示される画面の一例を示す図。 第６実施例に係る各装置が実行する処理のタイミングの一例を示す図。 第６変形例に係る端末の表示部に表示される画面の一例を示す図。 第７実施例に係る端末の表示部に表示される画面の一例を示す図。 第７実施例に係る各装置が実行する処理のタイミングの一例を示す図。 第７変形例に係るアカウント管理データベースの一例を示す図。 第７変形例に係る端末の表示部に表示される画面の一例を示す図。 第７変形例に係る各装置が実行する処理のタイミングの一例を示す図。 第７変形例に係る端末の表示部に表示される画面の一例を示す図。 第８実施例に係る端末の表示部に表示される画面の一例を示す図。 第８実施例に係る各装置が実行する処理のタイミングの一例を示す図。 第８実施例に係る第１安否情報と第２安否情報との組み合わせを示す図。 第９実施例に係る端末の表示部に表示される画面の一例を示す図。 第９変形例に係る端末の表示部に表示される画面の一例を示す図。
＜法的事項の遵守＞
　本明細書に記載の開示は、通信の秘密など、本開示の実施に必要な実施国の法的事項遵守を前提とすることに留意されたい。
＜実施形態＞
　本明細書では、分かり易いように「限定ではなく例として」と記載する箇所があるが、該当箇所ばかりでなく、以下説明する実施形態の全体について、その記載内容に限定されるものではないことに留意されたい。
　本開示に係るプログラム等を実施するための実施形態について、図面を参照して説明する。
　システムとは、限定ではなく例として、複数の装置を有して構成されるものとすることができる。
　複数の装置は、同じ種類の装置の組合せとしてもよいし、異なる種類の装置の組合せとしてもよいし、同じ種類の装置と異なる種類の装置との組合せとしてもよい。
　なお、システムとは、限定ではなく例として、複数の装置が協働して何らかの処理を行うもの、と考えることもできる。
　また、クライアント（クライアント装置）とサーバとに関するシステムとは、限定ではなく例として、少なくとも以下のいずれかと考えることができる。
　（１）端末＆サーバ
　（２）サーバ
　（３）端末
　（１）は、限定ではなく例として、少なくとも１つの端末と、少なくとも１つのサーバとを含むシステムである。この一例は、クライアントサーバシステムである。
　サーバは、限定ではなく例として、以下の装置によって構成されており、単独の装置であってもよいし、複数の装置の組合せであってもよいものとする。
　具体的には、サーバは、限定ではなく例として、少なくとも１つのプロセッサー（限定ではなく例として、ＣＰＵ：Central Processing Unit、ＧＰＵ：Graphics Processing Unit、ＡＰＵ：Accelerated Processing Unit、ＤＳＰ：Digital Signal Processor（限定ではなく例として、ＡＳＩＣ：Application Specific Integrated Circuit、ＦＰＧＡ：Field Programmable Gate Array）等）、コンピュータ装置（プロセッサー＋メモリ）、制御装置、演算装置、処理装置等のいずれかを有して構成され、いずれか１つの装置の同種を複数備える構成（限定ではなく例として、ＣＰＵ＋ＣＰＵ、ホモジニアスマルチコアプロセッサー等）や、いずれか１つの装置の異種を複数備える構成（限定ではなく例として、ＣＰＵ＋ＤＳＰ、ヘテロジニアスマルチコアプロセッサー等）としてもよいし、複数の装置の組み合わせ（限定ではなく例として、プロセッサー＋コンピュータ装置、プロセッサー＋演算装置、複数の装置をヘテロジニアス化したもの等）であってもよい。
　なお、プロセッサーは、仮想プロセッサーとしてもよい。
　また、サーバによって何らかの処理を実行する場合に、単一の装置で構成される場合は、単一の装置によって実施例に記載されている処理が実行される。また、複数の装置を有して構成されている場合には、一部の処理を一方の装置が実行し、その他の処理を他方の装置が実行するように構成されていてもよい。限定ではなく例として、プロセッサーと、演算装置とを有して構成される場合、第１処理をプロセッサーが実行し、第２処理を演算装置が実行するように構成されていてもよい。
　また、複数の装置で構成する場合には、各々の装置が互いに物理的に離れた位置に配置されて構成されてもよい。
　また、サーバの機能は、限定ではなく例として、クラウドコンピューティングにおけるＰａａＳやＩａａＳ、ＳａａＳの形態で提供されるようにしてもよい。
　また、システムの制御部は、端末の制御部とサーバの制御部とのうちの少なくともいずれか一方とすることができる。つまり、限定ではなく例として、（１Ａ）端末の制御部のみ、（１Ｂ）サーバの制御部のみ、（１Ｃ）端末の制御部とサーバの制御部との両方、のうちのいずれかを、システムの制御部とすることができる。
　また、システムの制御部が行う制御や処理（以下、包括的に「制御等」と称する。）は、（１Ａ）端末の制御部のみによって行うようにしてもよいし、（１Ｂ）サーバの制御部のみによって行うようにしてもよいし、（１Ｃ）端末の制御部とサーバの制御部との両方によって行うようにしてもよい。
　また、（１Ｃ）では、限定ではなく例として、システムが制御部によって行う制御等のうちの一部の制御等を端末の制御部によって行うようにし、残りの制御等をサーバの制御部によって行うようにしてもよい。この場合、制御等の割り当て（割り振り）は、等分であってもよいし、等分ではなく異なる割合で割り当ててもよい。
　また、サーバの通信部という場合、サーバが単一の装置によって構成されている場合には、単一の装置が備える通信部そのものであってもよい。また、サーバが複数の装置を有して構成されている場合には、サーバの通信部は、各々の装置が備える各々の通信部を含む構成であってもよい。
　限定ではなく例として、サーバは、第１装置と第２装置とを備え、第１装置は第１通信部を有し、第２装置は第２通信部を有する場合、サーバの通信部は、第１通信部と第２通信部とを含む概念としてもよい。
　（２）は、限定ではなく例として、複数のサーバによって構成されるシステム（以下、「サーバシステム」と称する。）とすることができる。この場合、各々のサーバの構成としては、前述した構成を同様に適用することができる。
　サーバシステムが行う制御等は、複数のサーバのうち、（２Ａ）一のサーバのみによって行うようにしてもよいし、（２Ｂ）他のサーバのみによって行うようにしてもよいし、（２Ｃ）一のサーバと他のサーバとが行うようにしてもよい。
　また、（２Ｃ）では、限定ではなく例として、サーバシステムが行う制御等のうちの一部の制御等を一のサーバが行うようにし、残りの制御等を他のサーバが行うようにしてもよい。この場合、制御等の割り当て（割り振り）は、等分であってもよいし、等分ではなく異なる割合で割り当ててもよい。
　（３）は、限定ではなく例として、複数の端末によって構成されるシステムとすることができる。
　このシステムは、限定ではなく例として、以下のようなシステムとすることができる。
　・サーバの機能を端末に持たせるシステム（分散システム）。これは、限定ではなく例として、ブロックチェーンの技術を用いて実現することが可能である。
　・端末同士が無線通信を行うシステム。これは、限定ではなく例として、ブルートゥース（登録商標）等の近距離無線通信技術を用いてＰ２Ｐ（ピアツーピア）方式等で通信を行うことで実現可能である。
　なお、上記は、制御部に限らず、システムの構成要素となり得る入出力部、通信部、記憶部、時計部等の各機能部についても同様である。
　以下の実施形態では、限定ではなく例として、端末とサーバとを含むシステム（限定ではなく例として、クライアントサーバシステム）を例示する。
　なお、サーバとして、上記（２）のサーバシステムを適用することも可能である。
　また、端末とサーバとを含むシステムに代えて、サーバを含まないシステム、限定ではなく例として、上記（３）のシステムを適用することも可能である。
　この場合の実施形態は、前述したブロックチェーンの技術等に基づいて構成することが可能である。具体的には、限定ではなく例として、以下の実施形態で説明するサーバに記憶されて管理されるデータを、ブロックチェーン上に保管（格納）する。そして、端末が、ブロックチェーンへのトランザクションを生成し、トランザクションがブロックチェーン上で承認されると、ブロックチェーン上に保管されたデータが更新されるようにすることができる。
　なお、端末と表現した場合でも、これは、クライアントサーバにおけるクライアントの装置としての端末の意味に限定されるものではない。
　つまり、端末は、クライアントサーバにおけるものではない装置の概念を含むこともあり得る。
　また、本明細書では、適宜「通信Ｉ／Ｆによって」という表現を用いる。これは、限定ではなく例として、装置が、制御部（プロセッサー等）の制御に基づいて、通信Ｉ／Ｆを介して（通信部を介して）、各種の情報やデータを送受信することを示してもよいものとする。
　また、本明細書において「関する」、「関連する」と記載された用語について、「Ａに関するＢ」や「Ａに関連するＢ」という場合、限定ではなく例として、「Ａ」と何らかの関係性を有する「Ｂ」を意味してよいものとする。この具体例については後述する。
　また、本明細書において、「ＡとＢとを送信する」、「ＡとＢとを受信する」といったように、装置が２以上のものを対象として処理を行うことには、「Ａ」と「Ｂ」とをタイミングを合わせて行うもの（以下、「同時」という。）と、「Ａ」と「Ｂ」とをタイミングをずらして行うもの（以下、「非同時」という。）とを含めてよいものとする。
　限定ではなく例として、第１情報と第２情報とを送信するという場合、第１情報と第２情報とをタイミングを合わせて送信するものと、第１情報と第２情報とをタイミングをずらして送信するものとの両方の概念を含めてよいものとする。
　なお、ラグ（タイムラグ）を考慮し、「同時」には「ほぼ同時」を含めてよいものとする。
　なお、「Ａ」と「Ｂ」とをタイミングをずらして行うといっても、これはあくまでも「Ａ」と「Ｂ」とを対象として処理を行うものであればよく、その目的は必ずしも同じでなくてもよいものとする。
　限定ではなく例として、上記のように第１情報と第２情報とを送信するという場合、第１情報と第２情報とを送信しさえすればよく、同じ目的で第１情報と第２情報とを送信する場合の他、異なる目的で第１情報と第２情報とを送信する場合も含めてよいものとする。
　以下の実施例では、ユーザがチャットを行うためのサービス（以下、「チャットサービス」と称する。）の一例として、メッセージングサービス（Messaging Service）を例示する。また、チャットサービスを実現するためのアプリケーションを「チャットアプリケーション」と称し、メッセージングサービスを実現するためのアプリケーションを「メッセージングアプリケーション」と称する。
　チャットアプリケーションでは、限定ではなく例として、ユーザがチャットルームでチャットを行うことができるようにすることができる。また、チャットアプリケーションでは、限定ではなく例として、ユーザ間における通話（音声通話やビデオ通話等）を行うことができるようにすることができる。
　なお、メッセージングサービス：ＭＳ（インスタントメッセージサービス：ＩＭＳを含む。）は、ソーシャルネットワーキングサービス：ＳＮＳの１つの形態（一形態）と考えることもできる。このため、メッセージンサービスとソーシャルネットワーキングサービスとを区別してもよいし、区別しなくてもよい。つまり、ソーシャルネットワーキングサービスにメッセージングサービスを含めてもよいものとする。
　また、以下の実施例では、メッセージングサービスの一例として、サーバを介して複数の装置（限定ではなく例として、端末）間で、コンテンツを簡単なメッセージの形式で送受するインスタントメッセージングサービス：ＩＭＳ（Instant Messaging Service）を例示する。
　インスタントメッセージングアプリケーションでは、限定ではなく例として、ユーザがトークルームでトークを行うようにすることができる。また、インスタントメッセージングアプリケーションでは、限定ではなく例として、ユーザ間における通話（音声通話やビデオ通話等）を行うことができるようにすることができる。
　チャットルーム（限定ではなく例として、トークルーム）とは、複数のユーザの端末間で送受信されるコンテンツを各々のユーザが閲覧できるＵＩ（User Interface）やＧＵＩ（Graphical User Interface）とすることができる。
　また、トークルームには、一対一のユーザのトークルーム（以下、「一対一トークルーム」と称する。）、複数のユーザを含むグループのトークルーム（以下、「グループトークルーム」と称する。）、公式アカウントのユーザとのトークルーム（以下、「ＯＡトークルーム」と称する。）等を含めることができる。
　なお、一対一トークルームは、データ管理上、一対一のユーザや一対一のアカウントのトークルームとして管理してもよいし、２名のユーザや２つのアカウントで構成されるグループのトークルームとして管理してもよい。
　公式アカウントは、一般のユーザではなく事業者のアカウント（事業者のユーザのアカウント）であり、この公式アカウントのユーザも、限定ではなく例として、一般のユーザの端末と同様の端末を利用して、サーバを介して、他の装置との間でコンテンツ（メッセージ）の送受信を行うことができるようにすることができる。
　本明細書において、コンテンツとは、送信元から送信先に送信される情報であってもよい。また、コンテンツは、１または複数のコンテンツであってもよい。
　コンテンツには、限定ではなく例として、テキスト形式のテキストコンテンツ、画像（静止画像、動画像の少なくともいずれか一方を含む。）形式の画像コンテンツ、音（音声を含む。）形式の音コンテンツなどを含めてよいものとする。
　なお、この他にも、ユーザの操作に供するボタンやアイコン等の操作コンテンツや、リンク情報（限定ではなく例として、ＵＲＩ（Uniform Resource Identifier）等を含む。）などのリンクコンテンツを含めてもよいものとする。
　テキストには、限定ではなく例として、文字コードで表される各国の文字、拡張文字、機種依存文字、数字、記号、図形及び符号の少なくともいずれか１つを含めてよいものとする。
　なお、テキストは、上記の文字、拡張文字、機種依存文字、数字、記号、図形及び符号の少なくとも１つを含まなくてもよく、その他のテキストを含んでもよい。
　画像には、限定ではなく例として、アイコン、ボタン、スタンプ、絵文字、バナー画像といった各種の画像の情報のうちの少なくともいずれか１つを含めることができる。
　また、以下の実施例では、災害（大規模災害等）発生時、ユーザが安否確認を行うためのサービスの一例として、安否確認サービス（Safety confirming Service）を例示する。また、安否確認サービスを実現するためのアプリケーションを「安否確認アプリケーション」と称する。
　安否確認アプリケーションでは、限定ではなく例として、ユーザが自身の安否に関する情報を登録し、他のユーザの安否に関する情報を参照することができる。
　安否確認サービス（安否確認アプリケーション）を実現するための形態としては、限定ではなく例として、以下のいずれかの形態を適用することができる。
（Ａ）メッセージングアプリケーションの一機能として安否確認サービスの機能を持たせる形態
（Ｂ）安否確認サービスの機能とメッセージングサービスの機能とを有するアプリケーション（統合的なアプリケーション）を構成する形態
（Ｃ）安否確認アプリケーションとは別のアプリケーションとしてメッセージングアプリケーションを構成する形態
（Ｄ）安否確認アプリケーションを単体のアプリケーションとして構成する形態
　（Ａ）や（Ｂ）の形態では、限定ではなく例として、安否確認サービス事業者を、メッセージングサービス事業者と同じ事業者とすることができる。
　また、この場合、１つの方法として、メッセージングアプリケーションにおけるユーザのアカウントと、安否確認アプリケーションにおけるユーザのアカウントとを共通のアカウントとすることができる。
　また、この場合、別の方法として、メッセージングアプリケーションにおけるユーザのアカウントと、音楽アプリケーションにおけるユーザのアカウントとが自動的に関連付けられる（連携される）ようにすることができる。
　（Ｃ）の形態では、限定ではなく例として、安否確認サービス事業者を、メッセージングサービス事業者とは異なる事業者とすることができる。
　また、（Ｃ）の形態では、メッセージングアプリケーションにおけるユーザのアカウントと、安否確認アプリケーションにおけるユーザのアカウントとを関連付ける処理（連携する処理）を行うようにすることができる。
　なお、上記とは異なり、安否確認アプリケーションの一機能としてメッセージングサービスの機能を持たせるようにすることも可能である。
＜第１実施例＞
　第１実施例は、限定ではなく例として、大規模災害等の災害が発生した場合、一の端末２０（以下、適宜「端末」と称する。）に、他の端末２０（以下、適宜「第１端末」と称する。）のユーザ（以下、適宜「第１ユーザ」と称する。）が登録した安否確認に関する情報（以下、「安否確認情報」と称する。）を表示する実施例である。
　ここで、「安否確認情報」は、限定ではなく例として、以下の３種類の情報に大別することができる。
（Ａ１）安否ステータス情報
　ユーザの置かれる状況を示す安全レベルに関するクラス情報。
　本実施形態では、限定ではなく例として、ユーザによって登録される安否ステータス情報を「安全」と「危険」の２クラスとする。
　なお、安否ステータス情報は、２クラスに限定されない。限定ではなく例として、安否ステータス情報に安否不明であることを示す「不明」のクラスや、災害の被災範囲外であることを示す「エリア外」等のクラスを設けるようにしてもよい。
（Ａ２）安否コメント情報
　ユーザの安否を伝えるための、安否に関するメッセージ等のコンテンツ情報。
　本実施形態では、限定ではなく例として、安否コメント情報をテキストとする。
　なお、安否コメント情報は、限定ではなく例として、音声や映像、アイコン等としてもよい。
（Ａ３）安否位置情報
　安否確認情報を登録するユーザの位置に関する情報。
　本実施形態では、限定ではなく例として、安否位置情報を住所で規定されるエリア（限定ではなく例として、市区町村）とする。
　なお、安否位置情報は、限定ではなく例として、緯度と経度とで規定される位置座標や、緯度と経度とで規定される位置座標で結ばれるエリアとしてもよい。また、安否位置情報に、高度に関する情報を含めるようにしてもよい。
　安否確認情報には、安否ステータス情報と、安否コメント情報と、安否位置情報との任意の組み合わせを用いることができる。
　なお、安否確認情報には、少なくとも、安否ステータス情報または安否コメント情報が含まれることが望ましい。ただし、これに限定されるわけではない。
　また、表示画面における安否確認情報は、日本語で表示されてもよいし、他の言語（英語等）で表示されてもよい。
　限定ではなく例として、「安全」を「Ｓａｆｅ」、危険（安全ではない）を「Ｄａｎｇｅｒ」や「Ｎｏｔ　Ｓａｆｅ」、エリア外を「Ｎｏｔ　ＩＮ　Ａｒｅａ」等のように表示してもよい。
　また、以下では、安否確認情報を登録するユーザアカウントを「安否登録アカウント」、登録された安否確認情報に基づく「安否情報」を参照するユーザアカウントを「安否参照アカウント」と称する。
　なお、一般に、一のユーザアカウントは安否登録アカウントと安否参照アカウントとを兼ねることができる。
　また、以下では、前述したように、メッセージングアプリケーションによるメッセージングサービスを提供する事業者のことを「メッセージングサービス事業者」と称する。
　なお、メッセージングサービス事業者は、メッセージングアプリケーションを提供する事業者や、サーバ１０の事業者と表現することもできる。
　また、メッセージングサービスを提供する事業者という意味で、メッセージングサービスの事業者と表現することもできる。
　また、以下では、メッセージングアプリケーションの名称を、適宜「Ｍｅｓｓａｇｉｎｇ　Ａｐｐ」と称して図示・説明する。
　メッセージングアプリケーションでは、限定ではなく例として、友だちとしてサーバ１０に登録しているアカウント同士で、一対一トークを行うことができるように構成することができる。また、限定ではなく例として、２以上のアカウントを含むグループを構成し、グループに含まれるアカウント同士で、グループトークを行うことができるように構成することができる。
　また、メッセージングアプリケーションでは、限定ではなく例として、一のユーザアカウントに対して送信されたメッセージ一覧をトークリストとして確認できるように構成することができる。
　ユーザによって登録された安否確認情報を確認するための情報（以下、適宜「安否情報」と称する。）を各々の端末２０において表示する形式としては、限定ではなく例として、メッセージングアプリケーションにおける以下の構成要件に表示させる形式が挙げられる。
（Ｂ１）友だちリストに表示
（Ｂ２）トークリストに表示
（Ｂ３）トークルームに表示
　なお、ユーザ同士（アカウント同士）が関連付けられていることの一例として、以下ではメッセージングサービスにおける「友だち」を主に例示するが、これに限定されない。
　限定ではなく例として、ＳＮＳにおいて、自分が興味を持つなどして登録した他のユーザ（アカウント）を示す「フォロー」や、自分に興味を持つなどして自分を登録した他のユーザ（アカウント）を示す「フォロワー」のような関係も、ユーザ同士（アカウント同士）が関連付けられていることに含めることができる。
　限定ではなく例として、ＳＮＳにおいて、「フォロー」関係にあるユーザや、「フォロワー」関係にあるユーザの一覧は、上記構成要件（Ｂ１）と対応させることができる。
　また、限定ではなく例として、ＳＮＳにおいて、「フォロー」関係にあるユーザの投稿一覧（限定ではなく例として、「タイムライン」）は、上記構成要件（Ｂ２）と対応させることができる。
　また、限定ではなく例として、ＳＮＳにおいて、特定のユーザに対する投稿（限定ではなく例として、「ダイレクトメッセージ」）は、上記構成要件（Ｂ３）と対応させることができる。
　第１実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
　また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
＜システム構成＞
　図１－１は、本開示の実施形態における通信システム１のシステム構成の一例を示す図である。
　通信システム１では、限定ではなく例として、ネットワーク３０を介して、サーバ１０と、複数の端末２０（端末２０Ａ，端末２０Ｂ，端末２０Ｃ，・・・）とが接続される。
　サーバ１０は、ネットワーク３０を介して、ユーザが所有する端末２０に、所定のサービス（限定ではなく例として、メッセージングサービス、安否確認サービス等）を提供する機能を有する。サーバ１０は、限定ではなく例として、メッセージングサーバ、安否確認サーバ等のように表現することもできる。
　本実施形態では、メッセージングサービス事業者（運営者）や安否確認サービス事業者（運営者）をサーバ１０のユーザとする。
　なお、ネットワーク３０に接続されるサーバ１０の数や端末２０の数は限定されない。
　端末２０（端末２０Ａ，端末２０Ｂ，端末２０Ｃ、・・・）は、各実施例において記載する機能を実現できる情報処理端末であればどのような端末であってもよい。端末２０は、限定ではなく例として、スマートフォン、携帯電話（フィーチャーフォン）、コンピュータ（限定でなく例として、デスクトップ、ラップトップ、タブレットなど）、メディアコンピュータプラットホーム（限定でなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダ）、ハンドヘルドコンピュータデバイス（限定でなく例として、ＰＤＡ・（personal digital assistant）、電子メールクライアントなど）、ウェアラブル端末（メガネ型デバイス、時計型デバイスなど）、ＶＲ（Virtual Reality）端末、スマートスピーカ（音声認識用デバイス）、または他種のコンピュータ、またはコミュニケーションプラットホームを含む。また、端末２０は情報処理端末と表現されてもよい。
　端末２０Ａ、端末２０Ｂおよび端末２０Ｃの構成は、限定ではなく例として、同一とすることができる。また、必要に応じて、ユーザＸが利用する端末を端末２０Ｘと表現し、ユーザＸまたは端末２０Ｘに対応づけられた、所定のサービスにおけるユーザ情報をユーザ情報Ｘと表現してもよいし、しなくてもよい。
　なお、ユーザ情報とは、所定のサービスにおいてユーザが利用するアカウントに対応付けられたユーザの情報である。ユーザ情報は、限定でなく例として、ユーザにより入力される、または、所定のサービスにより付与される、ユーザの名前、ユーザのアイコン画像、ユーザの年齢、ユーザの性別、ユーザの住所、ユーザの趣味趣向、ユーザの識別子などのユーザに対応づけられた情報を含み、これらのいずれか一つまたは、組み合わせであってもよいし、そうでなくてもよい。
　ネットワーク３０は、１以上の端末２０と、１以上のサーバ１０とを接続する役割を担う。すなわち、ネットワーク３０は、上記の各種の装置が接続した後、データを送受信することができるように接続経路を提供する通信網を意味する。
　ネットワーク３０のうちの１つまたは複数の部分は、有線ネットワークや無線ネットワークであってもよいし、そうでなくてもよい。ネットワーク３０は、限定ではなく例として、アドホック・ネットワーク（ad hoc network）、イントラネット、エクストラネット、仮想プライベート・ネットワーク（virtual private network：ＶＰＮ）、ローカル・エリア・ネットワーク（local area network：ＬＡＮ）、ワイヤレスＬＡＮ（wireless LAN：ＷＬＡＮ）、広域ネットワーク（wide area network：ＷＡＮ）、ワイヤレスＷＡＮ（wireless WAN：ＷＷＡＮ）、大都市圏ネットワーク（metropolitan area network：ＭＡＮ）、インターネットの一部、公衆交換電話網（Public Switched Telephone Network：ＰＳＴＮ）の一部、携帯電話網、ＩＳＤＮ（integrated service digital networks）、無線ＬＡＮ、ＬＴＥ（long term evolution）、ＣＤＭＡ（code division multiple access）、ブルートゥース（Bluetooth（登録商標））、衛星通信など、または、これらの２つ以上の組合せを含むことができる。ネットワーク３０は、１つまたは複数のネットワーク３０を含むことができる。
　サーバ１０（限定ではなく、サーバ、情報処理装置、情報管理装置の一例）は、端末２０に対して、所定のサービスを提供する機能を備える。サーバ１０は、各実施形態において記載する機能を実現できる情報処理装置であればどのような装置であってもよい。サーバ１０は、限定ではなく例として、サーバ装置、コンピュータ（限定ではなく例として、デスクトップ、ラップトップ、タブレットなど）、メディアコンピュータプラットホーム（限定ではなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダ）、ハンドヘルドコンピュータデバイス（限定ではなく例として、ＰＤＡ、電子メールクライアントなど）、あるいは他種のコンピュータ、またはコミュニケーションプラットホームを含む。また、サーバ１０は情報処理装置と表現されてもよい。サーバ１０と端末２０とを区別する必要がない場合は、サーバ１０と端末２０とは、それぞれ情報処理装置と表現されてもよいし、されなくてもよい。
［各装置のハードウェア（ＨＷ）構成］
　通信システム１に含まれる各装置のＨＷ構成について説明する。
（１）端末のＨＷ構成
　図１－１には、端末２０のＨＷ構成の一例を示している。
　端末２０は、制御部２１（ＣＰＵ：central processing unit（中央処理装置））、記憶部２８、通信Ｉ／Ｆ２２（インタフェース）、入出力部２３、時計部２９Ａ、位置算出用情報検出部２９Ｂを備える。端末２０のＨＷの各構成要素は、限定ではなく例として、バスＢを介して相互に接続される。なお、端末２０のＨＷ構成として、すべての構成要素を含むことは必須ではない。限定ではなく例として、端末２０は、個々の構成要素、または複数の構成要素を取り外すような構成であってもよいし、そうでなくてもよい。
　通信Ｉ／Ｆ２２は、ネットワーク３０を介して各種データの送受信を行う。通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信Ｉ／Ｆ２２は、ネットワーク３０を介して、サーバ１０等の各種装置との通信を実行する機能を有する。通信Ｉ／Ｆ２２は、各種データを制御部２１からの指示に従って、サーバ１０等の各種装置に送信する。また、通信Ｉ／Ｆ２２は、サーバ１０等の各種装置から送信された各種データを受信し、制御部２１に伝達する。また、通信Ｉ／Ｆ２２を単に通信部と表現する場合もある。また、通信Ｉ／Ｆ２２が物理的に構造化された回路で構成される場合には、通信回路と表現する場合もある。
　入出力部２３は、端末２０に対する各種操作を入力する装置や、端末２０で処理された処理結果を出力する装置等を含む。入出力部２３は、入力部と出力部が一体化していてもよいし、入力部と出力部に分離していてもよいし、そうでなくてもよい。
　入力部は、ユーザからの入力を受け付けて、入力に係る情報を制御部２１に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入力部は、限定ではなく例として、タッチパネル、タッチディスプレイ、キーボード等のハードウェアキーや、マウス等のポインティングデバイス、カメラ（動画像を介した操作入力）、マイク（音声による操作入力）を含む。
　出力部は、制御部２１で処理された処理結果を出力することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。出力部は、限定ではなく例として、タッチパネル、タッチディスプレイ、スピーカ（音声出力）、レンズ（限定ではなく例として３Ｄ（three dimensions）出力や、ホログラム出力）、プリンターなどを含む。
　あくまでも一例であるが、入出力部２３は、限定ではなく例として、表示部２４、音入力部２５、音出力部２６、撮像部２７を備える。
　表示部２４は、フレームバッファに書き込まれた表示データに従って、表示することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。表示部２４は、限定ではなく例として、タッチパネル、タッチディスプレイ、モニタ（限定ではなく例として、液晶ディスプレイやＯＥＬＤ（organic electroluminescence display））、ヘッドマウントディスプレイ（ＨＤＭ：Head Mounted Display）、プロジェクションマッピング、ホログラム、空気中など（真空であってもよいし、そうでなくてもよい）に画像やテキスト情報等を表示可能な装置を含む。なお、これらの表示部２４は、３Ｄで表示データを表示可能であってもよいし、そうでなくてもよい。
　音入力部２５は、音データ（音声データを含む。以下同様。）の入力に利用される。音入力部２５は、マイクなどを含む。
　音出力部２６は、音データの出力に利用される。音出力部２６は、スピーカなどを含む。
　撮像部２７は、画像データ（静止画像データ、動画像データを含む。以下同様。）の取得に利用される。撮像部２７は、カメラなどを含む。
　入出力部２３がタッチパネルの場合、入出力部２３と表示部２４とは、略同一の大きさおよび形状で対向して配置されていてもよい。
　時計部２９Ａは、端末２０の内蔵時計であり、時刻情報（計時情報）を出力する。時計部２９Ａは、限定ではなく例として、水晶発振器を利用したクロック等を有して構成される。時計部２９Ａは、限定ではなく例として、計時部や時刻情報検出部と表現することもできる。
　なお、時計部２９Ａは、ＮＩＴＺ（Network Identity and Time Zone）規格等を適用したクロックを有していてもよいし、有していなくてもよい。
　位置算出用情報検出部２９Ｂは、制御部２１が自己の端末２０の位置を算出（測定）するために必要な情報（以下、「位置算出用情報」と称する。）を検出（計測）する機能部である。位置算出用情報検出部２９Ｂは、限定ではなく例として、位置算出用センサ部と表現することもできる。
　位置算出用情報検出部２９Ｂは、限定ではなく例として、ＧＰＳ（Global Positioning System）等の衛星測位システムを利用して端末２０の位置を算出するためのセンサやユニットである衛星測位センサ（衛星測位ユニット）や、慣性航法システムを利用して端末２０の位置を算出するためのセンサやユニットである慣性計測センサ（慣性計測ユニット（ＩＭＵ（Inertial Measurement Unit）））、ＵＷＢ（超広帯域無線：Ultra Wide Band）を利用して端末２０の位置を算出するためのセンサやユニットであるＵＷＢ測位センサ（ＵＷＢ測位ユニット）等を含む。
　衛星測位ユニットは、限定ではなく例として、不図示のアンテナで受信される測位用衛星から発信されている測位用衛星信号を含むＲＦ（Radio Frequency）信号をデジタル信号に変換するＲＦ受信回路や、ＲＦ受信回路から出力されるデジタル信号に対して相関演算処理等を行って測位用衛星信号を捕捉し、測位用衛星信号から取り出した衛星軌道データや時刻データ等の情報を、位置算出用情報として出力するベースバンド処理回路等を有する。
　慣性計測ユニットは、慣性航法演算によって端末２０の位置を算出するために必要な情報を検出するセンサである慣性センサを有する。慣性センサには、限定ではなく例として、３軸の加速度センサや３軸のジャイロセンサが含まれ、加速度センサによって検出された加速度と、ジャイロセンサによって検出された角速度とを、位置算出用情報として出力する。
　ＵＷＢ測位ユニットは、限定ではなく例として、不図示のアンテナで受信される測位用ビーコンから発信されている測位用超広帯域パルス信号を含む超広帯域ＲＦ（Radio Frequency）信号をデジタル信号に変換する超広帯域ＲＦ受信回路や、超広帯域ＲＦ受信回路から出力されるデジタル信号に基づいて端末２０と測位用ビーコンとの相対位置を算出する相対位置算出処理回路等を有する。
　なお、限定ではなく例として、ＵＷＢ測位ユニットは、不図示のアンテナから測位用超広帯域パルス信号を含む超広帯域ＲＦ信号を送信することで、端末２０を測位用ビーコンとして機能させてもよいし、そうしなくてもよい。
　制御部２１は、限定ではなく例として、位置算出用情報検出部２９Ｂによって検出された位置算出用情報に基づいて、定期的なタイミングや特定のタイミングで、自己の端末２０の位置を算出する。端末の位置を「端末位置」と称し、算出された端末位置を「算出端末位置」と称する。制御部２１は、算出端末位置を、その算出端末位置を算出した日時と関連付けて、算出端末位置履歴データとして記憶部２８に記憶させるようにしてもよいし、そうしなくてもよい。
　制御部２１は、プログラム内に含まれたコードまたは命令によって実現する機能を実行するために物理的に構造化された回路を有し、限定ではなく例として、ハードウェアに内蔵されたデータ処理装置により実現される。そのため、制御部２１は、制御回路と表現されてもよいし、されなくてもよい。
　制御部２１は、限定ではなく例として、中央処理装置（ＣＰＵ）、マイクロプロセッサ（microprocessor）、プロセッサコア（processor core）、マルチプロセッサ（multiprocessor）、ＡＳＩＣ（application-specific integrated circuit）、ＦＰＧＡ（field programmable gate array）を含む。
　記憶部２８は、端末２０が動作するうえで必要とする各種プログラムや各種データを記憶する機能を有する。記憶部２８は、限定ではなく例として、ＨＤＤ（hard disk drive）、ＳＳＤ（solid state drive）、フラッシュメモリ、ＲＡＭ（random access memory）、ＲＯＭ（read only memory）など各種の記憶媒体を含む。また、記憶部２８は、メモリ(memory)と表現されてもよいし、されなくてもよい。
　端末２０は、プログラムＰを記憶部２８に記憶し、このプログラムＰを実行することで、制御部２１が、制御部２１に含まれる各部としての処理を実行する。つまり、記憶部２８に記憶されるプログラムＰは、端末２０に、制御部２１が実行する各機能を実現させる。また、このプログラムＰは、プログラムモジュールと表現されてもよいし、されなくてもよい。
（２）サーバのＨＷ構成
　図１－１には、サーバ１０のＨＷ構成の一例を示している。
　サーバ１０は、制御部１１（ＣＰＵ）、記憶部１５、通信Ｉ／Ｆ１４（インタフェース）、入出力部１２、時計部１９を備える。サーバ１０のＨＷの各構成要素は、限定ではなく例として、バスＢを介して相互に接続される。なお、サーバ１０のＨＷは、サーバ１０のＨＷの構成として、全ての構成要素を含むことは必須ではない。限定ではなく例として、サーバ１０のＨＷは、個々の構成要素、または複数の構成要素を取り外すような構成であってもよいし、そうでなくてもよい。
　制御部１１は、プログラム内に含まれたコードまたは命令によって実現する機能を実行するために物理的に構造化された回路を有し、限定ではなく例として、ハードウェアに内蔵されたデータ処理装置により実現される。
　制御部１１は、代表的には中央処理装置（ＣＰＵ）、であり、その他にマイクロプロセッサ、プロセッサコア、マルチプロセッサ、ＡＳＩＣ、ＦＰＧＡであってもよいし、そうでなくてもよい。本開示において、制御部１１は、これらに限定されない。
　記憶部１５は、サーバ１０が動作するうえで必要とする各種プログラムや各種データを記憶する機能を有する。記憶部１５は、ＨＤＤ、ＳＳＤ、フラッシュメモリなど各種の記憶媒体により実現される。ただし、本開示において、記憶部１５は、これらに限定されない。また、記憶部１５は、メモリ(memory)と表現されてもよいし、されなくてもよい。
　通信Ｉ／Ｆ１４は、ネットワーク３０を介して各種データの送受信を行う。通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信Ｉ／Ｆ１４は、ネットワーク３０を介して、端末２０等の各種装置との通信を実行する機能を有する。通信Ｉ／Ｆ１４は、各種データを制御部１１からの指示に従って、端末２０等の各種装置に送信する。また、通信Ｉ／Ｆ１４は、端末２０等の各種装置から送信された各種データを受信し、制御部１１に伝達する。また、通信Ｉ／Ｆ１４を単に通信部と表現する場合もある。また、通信Ｉ／Ｆ１４が物理的に構造化された回路で構成される場合には、通信回路と表現する場合もある。
　入出力部１２は、サーバ１０に対する各種操作を入力する装置や、サーバ１０で処理された処理結果を出力する装置等を含む。入出力部１２は、入力部と出力部が一体化していてもよいし、入力部と出力部に分離していてもよいし、そうでなくてもよい。
　入力部は、ユーザからの入力を受け付けて、入力に係る情報を制御部１１に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入力部は、代表的にはキーボード等に代表されるハードウェアキーや、マウス等のポインティングデバイスで実現される。なお、入力部は、限定ではなく例として、タッチパネルやカメラ（動画像を介した操作入力）、マイク（音声による操作入力）を含んでいてもよいし、そうでなくてもよい。
　出力部は、制御部１１で処理された処理結果を出力することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。出力部は、限定ではなく例として、 タッチパネル、タッチディスプレイ、スピーカ（音出力）、レンズ（限定ではなく例として３Ｄ（three dimensions）出力や、ホログラム出力）、プリンターなどを含む。
　あくまでも一例であるが、入出力部１２は、限定ではなく例として、表示部１３を備える。
　表示部１３は、ディスプレイ等で実現される。ディスプレイは、代表的にはモニタ（限定ではなく例として、液晶ディスプレイやＯＥＬＤ（organic electroluminescence display））で実現される。なお、ディスプレイは、ヘッドマウントディスプレイ（ＨＤＭ）などであってもよいし、そうでなくてもよい。なお、これらのディスプレイは、３Ｄで表示データを表示可能であってもよいし、そうでなくてもよい。本開示において、ディスプレイは、これらに限定されない。
　時計部１９は、サーバ１０の内蔵時計であり、時刻情報（計時情報）を出力する。時計部１９は、限定ではなく例として、ハードウェアクロックとしてのＲＴＣ（Real Time Clock）やシステムクロック等を有して構成される。時計部１９は、限定ではなく例として、計時部や時刻情報検出部と表現することもできる。
（３）その他
　サーバ１０は、プログラムＰを記憶部１５に記憶し、このプログラムＰを実行することで、制御部１１が、制御部１１に含まれる各部としての処理を実行する。つまり、記憶部１５に記憶されるプログラムＰは、サーバ１０に、制御部１１が実行する各機能を実現させる。このプログラムＰは、プログラムモジュールと表現されてもよいし、されなくてもよい。
　他の装置についても同様である。
　本開示の各実施形態においては、端末２０および／またはサーバ１０のＣＰＵがプログラムＰを実行することにより、実現するものとして説明する。
　なお、端末２０の制御部２１、および／または、サーバ１０の制御部１１は、制御回路を有するＣＰＵだけでなく、集積回路（ＩＣ（Integrated Circuit）チップ、ＬＳＩ（Large Scale Integration））等に形成された論理回路（ハードウェア）や専用回路によって各処理を実現してもよいし、そうでなくてもよい。また、これらの回路は、１または複数の集積回路により実現されてよく、各実施形態に示す複数の処理を１つの集積回路により実現されることとしてもよいし、そうでなくてもよい。また、ＬＳＩは、集積度の違いにより、ＶＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩなどと呼称されることもある。そのため、制御部２１は、制御回路と表現されてもよいし、されなくてもよい。
　また、本開示の各実施形態のプログラムＰ(限定ではなく例として、ソフトウェアプログラム、コンピュータプログラム、またはプログラムモジュール)は、コンピュータに読み取り可能な記憶媒体に記憶された状態で提供されてもよいし、されなくてもよい。記憶媒体は、「一時的でない有形の媒体」に、プログラムＰを記憶可能である。また、プログラムＰは、本開示の各実施形態の機能の一部を実現するためのものであってもよいし、そうでなくてもよい。さらに、本開示の各実施形態の機能を記憶媒体にすでに記録されているプログラムＰとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であってもよいし、そうでなくてもよい。
　また、システムのプログラム（システムによって実行されるプログラム）という場合、システムについては前述した通りである。そして、前述したシステムのプログラムとは、システム全体で実行可能なプログラムであって、このプログラムは、限定ではなく例として、システムを構成する装置個々のプログラムで構成されてもよく、システムを構成する個々の装置に保存されるプログラムは、各々異なっていてもよいものとする。つまり、システムを構成する個々の装置で共通のプログラムでなくてもよいものとする。
　限定ではなく例として、システムが端末とサーバとで構成されている場合、システムのプログラムをＰ１とすると、システムのプログラムＰ１は、端末に保存されたプログラムＰ２と、サーバに保存されたプログラムＰ３とで構成され、Ｐ２とＰ３とは、システムのプログラムを実行するためのものであり、それぞれ異なるプログラムとなっていてもよい。限定ではなく例として、端末に保存されたプログラムＰ２は、第１の処理を実行し、第１の処理をした結果をサーバに送信するプログラムであり、サーバに保存されたプログラムＰ３は、受信した第１の処理をした結果に対して第２の処理を行い、第２の処理を行った結果を端末に送信するプログラムであってもよい。
　記憶媒体は、１つまたは複数の半導体ベースの、または他の集積回路（ＩＣ）（限定ではなく例として、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）または特定用途向けＩＣ（ＡＳＩＣ）など）、ハード・ディスク・ドライブ（ＨＤＤ）、ハイブリッド・ハード・ドライブ（ＨＨＤ）、光ディスク、光ディスクドライブ（ＯＤＤ）、光磁気ディスク、光磁気ドライブ、フロッピィ・ディスケット、フロッピィ・ディスク・ドライブ（ＦＤＤ）、磁気テープ、固体ドライブ（ＳＳＤ）、ＲＡＭドライブ、セキュア・デジタル・カード、またはドライブ、任意の他の適切な記憶媒体、またはこれらの２つ以上の適切な組合せを含むことができる。記憶媒体は、適切な場合、揮発性、不揮発性、または揮発性と不揮発性の組合せでよい。なお、記憶媒体はこれらの例に限られず、プログラムＰを記憶可能であれば、どのようなデバイスまたは媒体であってもよい。また、記憶媒体をメモリ（memory）と表現されてもよいし、されなくてもよい。
　サーバ１０および／または端末２０は、記憶媒体に記憶されたプログラムＰを読み出し、読み出したプログラムＰを実行することによって、各実施形態に示す複数の機能部の機能を実現することができる。
　また、本開示のプログラムＰは、プログラムを伝送可能な任意の伝送媒体(通信ネットワークや放送波等)を介して、サーバ１０および／または端末２０に提供されてもよいし、されなくてもよい。サーバ１０および／または端末２０は、限定ではなく例として、インターネット等を介してダウンロードしたプログラムＰを実行することにより、各実施形態に示す複数の機能部の機能を実現する。
　また、本開示の各実施形態は、プログラムＰが電子的な伝送によって具現化されたデータ信号の形態でも実現され得る。
　サーバ１０および／または端末２０における処理の少なくとも一部は、１以上のコンピュータにより構成されるクラウドコンピューティングにより実現されていてもよいし、そうでなくてもよい。
　端末２０における処理の少なくとも一部、または全部を、サーバ１０により行う構成としてもよいし、そうでなくてもよい。この場合、端末２０の制御部２１の各機能部の処理のうち少なくとも一部の処理、または全部の処理を、サーバ１０で行う構成としてもよいし、そうでなくてもよい。
　サーバ１０における処理の少なくとも一部、または全部を、端末２０により行う構成としてもよいし、そうでなくてもよい。この場合、サーバ１０の制御部１１の各機能部の処理のうち少なくとも一部の処理、または全部の処理を、端末２０で行う構成としてもよいし、そうでなくてもよい。
　明示的な言及のない限り、本開示の実施形態における判定の構成は必須でなく、判定条件を満たした場合に所定の処理が動作されたり、判定条件を満たさない場合に所定の処理がされたりしてもよいし、そうでなくてもよい。
　なお、本開示のプログラムは、限定ではなく例として、ActionScript、JavaScript(登録商標)などのスクリプト言語、Objective-C、Java(登録商標)などのコンパイラ言語、HTML Living Standardなどのマークアップ言語などを用いて実装される。
＜機能構成＞
（１）サーバの機能構成
　図１－２は、本実施例においてサーバ１０の制御部１１によって実現される機能の一例を示す図である。
　制御部１１は、限定ではなく例として、記憶部１５に記憶されたアプリケーション管理処理プログラム１５１に従ってアプリケーション管理処理を実行するためのアプリケーション管理処理部１１１を機能部として含む。
　図１－３は、本実施例においてサーバ１０の記憶部１５に記憶される情報の一例を示す図である。
　記憶部１５には、限定ではなく例として、アプリケーション管理処理として実行されるアプリケーション管理処理プログラム１５１と、アカウント登録データ１５３と、アカウント管理データベース１５５とが記憶される。
　アカウント登録データ１５３は、アプリケーション（本実施例では、メッセージングアプリケーション）のアカウントに関する登録データであり、そのデータ構成の一例を図１－４に示す。
　アカウント登録データ１５３には、限定ではなく例として、ユーザ名と、アプリケーションＩＤと、その他登録情報とが関連付けて記憶される。
　ユーザ名は、このアプリケーションを利用する端末２０のアカウントの名称であり、限定ではなく例として、端末２０のユーザがアプリケーションを利用する際に登録する名称が記憶される。
　アプリケーションＩＤは、アプリケーションのアカウントを識別するために用いられる情報、またはアカウントそのものである。
　このアプリケーションＩＤは、好ましくはアカウントごとに一意な値であり、限定ではなく例として、サーバ１０によってアカウントごとに一意な値（固有の値）が設定されて記憶される。
　アプリケーションＩＤは、端末２０、またはその端末２０のユーザに関連付けられた情報であり、端末に関する情報、または端末のユーザに関する情報の一例である。
　その他登録情報には、限定ではなく例として、端末２０を識別するための識別情報、端末２０の電話番号（端末電話番号）、メールアドレス（端末メールアドレス）、アプリケーションにおける各種の認証に利用されるパスワード（ログインパスワード、認証パスワード等）等の認証情報といった各種の情報を含めるようにすることができる。
　端末２０を識別するための識別情報は、限定ではなく例として、端末ＩＤ（限定ではなく例として、ＩＭＥＩ（International Mobile Equipment Identity））とすることができる。
　また、端末２０のユーザを識別するための識別情報は、限定ではなく例として、一般ユーザ用のアプリケーションＩＤや公式ユーザ用のアプリケーションＩＤとすることができる。
　なお、アプリケーションＩＤに代えて「ユーザＩＤ」としてもよいし、しなくてもよい。
　また、１つの端末２０につき１つのアカウントしか登録することのできないアプリケーションであれば、限定ではなく例として、「端末２０を識別するための識別情報＝端末２０のユーザを識別するための識別情報＝アプリケーションＩＤ」とすることができる。
　また、限定ではなく例として、１つのアプリケーションＩＤに、複数の端末ＩＤを割り当てることを可能としてもよいし、そのようにしなくてもよい。この場合、１つのアプリケーションＩＤを識別（ログイン）対象として、複数の端末２０においてアプリケーションを同時に起動できるようにしてもよいし、そのようにしなくてもよい。
　また、アプリケーションＩＤ等の各種のＩＤに代えて、端末電話番号等の情報によってアカウントを管理する手法を適用することも可能である。
　この場合、アプリケーションＩＤ等のＩＤの情報をアカウント登録データ１５３に記憶させるのに代えて、端末電話番号等の情報をアカウント登録データ１５３に記憶させるようにすることができる。なお、アプリケーションＩＤ等のＩＤの情報を端末電話番号等の情報に代えず、アプリケーションＩＤ等のＩＤの情報を端末電話番号等の情報と一対一に対応させるようにしてもよいし、そのようにしなくてもよい。
　なお、以下の各種の実施例では、説明の簡明化のため、１つの端末２０につき１つのアカウントが登録されていることとして説明する。
　また、この場合、上記のように「端末２０を識別するための識別情報＝端末２０のユーザを識別するための識別情報＝アプリケーションＩＤ」であるため、以下の説明で用いる「アカウントのユーザ」の用語は、「アカウントの端末」と実質的に同義としてよいものとする。
　アカウント管理データベース１５５は、アカウント登録データ１５３に登録されたアカウントに関する情報を管理するためのデータベースであり、その一例であるアカウント管理データベース１５５Ａのデータ構成例を図１－５に示す。
　アカウント管理データベース１５５Ａには、アカウントごとの管理データとして、アカウント管理データが記憶される。
　各々のアカウント管理データには、限定ではなく例として、アプリケーションＩＤと、友だち管理データと、安否登録データとが記憶される。
　アプリケーションＩＤは、アカウント管理データで管理されるアカウントを識別するための情報であり、限定ではなく例として、アカウント登録データ１５３に登録されたアプリケーションＩＤが記憶される。
　友だち管理データは、このアプリケーションＩＤのアカウントと友だちであるアカウントのアプリケーションＩＤを記憶させるためのデータであり、限定ではなく例として、ユーザが友だち登録を行うと、サーバによって友だち登録を行ったユーザのアプリケーションＩＤが追加され更新される。
　安否登録データは、このアプリケーションＩＤのアカウントに関連付けられた、安否に関する登録を記憶させるためのデータであり、限定ではなく例として、安否ステータス情報が記憶される。
　アカウントごとの安否登録データは、限定ではなく例として、端末２０に対するユーザ操作等のユーザ入力に基づいて変更可能とすることができる。
　なお、安否登録データの初期値（デフォルト）としては、限定ではなく例として、サーバ１０が安否確認情報を受信していないことを示す情報（限定ではなく例として、安否不明であることを示す「不明」フラグ）が予め設定されるようにすることができる。
　また、安否登録データとして、このアカウントの端末２０によって登録された安否確認情報のうち、安否ステータス情報と、安否コメント情報と、安否位置情報との任意の組み合わせを関連付けて記憶させるようにしてもよい。
（２）端末の機能構成
　図１－６は、本実施例において端末２０の制御部２１によって実現される機能の一例を示す図である。
　制御部２１は、限定ではなく例として、記憶部２８に記憶されたアプリケーション処理プログラム２８１に従ってアプリケーション処理を実行するためのアプリケーション処理部２１１を機能部として含む。
　図１－７は、本実施例において端末２０の記憶部２８に記憶されるデータ等の一例を示す図である。
　記憶部２８には、限定ではなく例として、アプリケーション処理として実行されるアプリケーション処理プログラム２８１と、この端末２０、または端末２０のユーザのアカウントに対応するアプリケーションＩＤ２８３とが記憶される。
　なお、端末２０の記憶部２８に、アカウント管理データベース１５５Ａの友だち管理データを同期させて記憶させるようにしてもよい。
＜表示画面＞
　本実施例における表示画面では、安否確認情報として、安否ステータス情報のみを登録する例について例示する。
　以下では、限定ではなく例として、端末２０が、縦長のディスプレイの表示部２４を備えるスマートフォンである場合を例示する。
　スマートフォンには、限定ではなく例として、入力部として機能するタッチパネルが、そのディスプレイと対向して配置され、これによってタッチスクリーンが構成される。アイコン、ボタン、アイテムまたは入力領域などの要素がディスプレイに表示された場合において、タッチパネルの一部の領域であって、その要素が表示された領域と対向する領域がユーザによって操作された場合、その要素と関連付けられたプログラムまたはそのプログラムのサブルーチンが実行される。
　なお、以下説明する表示画面の遷移は、本開示の手法を実現するための表示画面の遷移の一例に過ぎない。以下に例示する表示画面の遷移について、一部の表示画面の表示を省略してもよいし、別の表示画面を追加してもよい。
　図１－８～図１－１０は、本実施例において端末２０の表示部２４に表示される画面の遷移の一例を示す図である。
　ここでは、
　・安否登録アカウント＝端末２０ＹのユーザＹ．Ｙ（限定ではなく、第１端末のユーザの一例）のアカウント
　・安否参照アカウント＝端末２０ＸのユーザＸ．Ｘ（限定ではなく、端末のユーザの一例）のアカウント
　とする場合の表示画面例を説明する。
　図１－８左側は、メッセージングアプリケーション（限定ではなく、チャットアプリケーションの一例）のホーム画面であり、画面最上部中央には、メッセージングアプリケーションの名称として「Ｍｅｓｓａｇｉｎｇ　Ａｐｐ」の文字が表示されている。また、画面最上部の右部には、この端末２０Ｙのユーザのメッセージングアプリケーションにおけるアイコン画像およびユーザ名（この例では「ユーザＹ．Ｙ」）が表示されている。
　また、その下には、メッセージングアプリケーション内での現在の位置やページ等を示す領域（以下、包括的に「アプリ内位置表示領域」と称する。）が構成されており、この例では、ホーム画面であることに基づいて、「ホーム」の文字が表示されている。
　アプリ内位置表示領域の下には、災害が発生したことを報知するための災害情報を示す領域である災害情報表示領域が構成されており、この例では、地震が発生したことに基づいて、災害情報（限定ではなく例として、震源地を示す地図情報と、「災害発生」の文字と、「２０ＸＸ／０８／０４　０９：３９発表」の文字と、「最大震度：５強」の文字と、「震源地：茨城県沖」の文字と、「マグニチュード：６．５」の文字）が表示されている。また、災害情報表示領域の内部の右下には、メッセージングアプリケーションのアカウントごとの安否登録（安否確認情報の登録）を行うための「安否登録」の文字を含むアイコンで示される安否登録ボタンＢＴ１が表示されている。
　災害情報表示領域の下には、メッセージングアプリケーションにおける友だちやグループのリストが表示される友だち・グループリスト表示領域が構成されている。
　この例では、友だち・グループリスト表示領域には、この端末２０のアカウント（この例では「ユーザＹ．Ｙ」）の友だちを一覧表示させるための友だちリストと、この端末２０のアカウントをメンバーとして含むグループを一覧表示させるためのグループリストとが表示されるように構成されている。この例では、限定ではなく例として、友だちリストがタップされて展開された状態で表示されている。
　グループリストには、限定ではなく例として、「グループ」の文字と、ユーザＹ．Ｙが属するグループの数（本例では「８」）とが表示されている。
　その下の友だちリストには、「友だち」の文字と、ユーザＹ．Ｙが友だちとして登録しているユーザ（アカウント）の数（本例では「４」）とが表示されている。
　グループリストや友だちリストがユーザによってタップされると、それらのリストが展開され表示される。具体的には、限定ではなく例として、グループリストの下に、グループのアイコンと、グループ名と、そのグループに属するメンバー数とが、グループリストの項目として一覧表示される。また、限定ではなく例として、友だちリストの下に、友だちのアイコンと、ユーザ名とが、友だちリストの項目として一覧表示される。
　この画面では、友だちリストの項目として、ユーザＸ．Ｘに対応したアイコンおよびユーザ名、ユーザＣ．Ｃに対応したアイコンおよびユーザ名、ユーザＤ．Ｄに対応したアイコンおよびユーザ名等が一覧表示されている。
　限定ではなく例として、安否登録ボタンＢＴ１がユーザによってタップされると、限定ではなく例として、図１－８中央のような表示がなされる。
　このホーム画面では、図１－８左側のホーム画面に重畳して、自身の安否情報を登録（設定）するための安否登録領域Ｒ１がせり上がり表示されるように構成されている。
　安否登録領域Ｒ１には、ユーザに安否情報を登録（設定）することを促す旨のメッセージ（本例では、「安否登録」の文字と、「みんなに安否を伝えよう」の文字）が表示されている。その下には、安否情報として安全であることを設定するための安全ボタンＳＢＴ（本例では、笑顔のアイコンと「安全」の文字とで示されるボタン）と、安否情報として安全でないことを設定するための危険ボタンＤＢＴ（本例では、笑顔でない顔のアイコンと「危険」の文字とで示されるボタン）と、選択した安否情報を設定するための登録ボタンＢＴ３とが表示されている。
　限定ではなく例として、図１－８中央の安否登録領域Ｒ１において、危険ボタンＤＢＴがユーザによってタップされ、登録ボタンＢＴ３がユーザによってタップされたとする。
　この場合、ユーザＹ．Ｙと友だちであるユーザＸ．Ｘの端末２０Ｘには、限定ではなく例として、図１－８右側に示すような画面が表示される。
　図１－８右側には、端末２０Ｘの表示部２４に表示されるホーム画面の一例を示しており、友だちリストの項目として、ユーザＹ．Ｙに対応したアイコンおよびユーザ名、ユーザＡ．Ａに対応したアイコンおよびユーザ名、ユーザＢ．Ｂに対応したアイコンおよびユーザ名等が一覧表示されている。
　この場合、上記のようにユーザＹ．Ｙが安否情報として「危険」を設定（登録）したことに基づいて、この例では、友だちリストのユーザＹ．Ｙのアイコンと関連付けて、危険であることを示すアイコンＤＩＣ１（本例では、笑顔でない顔のアイコン、以下、適宜「第１危険アイコン」と称する。）が重畳表示されている。
　なお、ユーザＹ．Ｙが安否情報として「安全」を設定している場合、友だちリストのユーザＹ．Ｙのアイコンには、安全であることを示すアイコンＳＩＣ１（本例では、笑顔アイコン、以下、適宜「第１安全アイコン」と称する。）が重畳表示される。
　友だちリストの各ユーザの項目に表示される＜危険であることを示す第１危険アイコンＤＩＣ１＞または＜安全であることを示す第１安全アイコンＳＩＣ１＞を確認することにより、端末２０ＸのユーザＸ．Ｘは、友だち登録しているユーザの安否情報を確認することができる。
　図１－９左側は、図１－８中央の表示画面と同様のユーザＹ．Ｙの端末２０Ｙにおけるホーム画面の一例である。
　本例では、図１－９左側の安否登録領域Ｒ１において、限定ではなく例として、危険ボタンＤＢＴがユーザによってタップされ、登録ボタンＢＴ３がユーザによってタップされると、ユーザＸ．Ｘの端末２０Ｘの表示部２４に、限定ではなく例として、図１－９中央に示すような画面が表示される。
　この端末２０Ｘの表示部２４に表示されるホーム画面では、ユーザＹ．Ｙが安否情報として「危険」を設定したものの、図１－８右側に示した例とは異なり、友だちリストのユーザＹ．Ｙのアイコンに、危険であることを示すアイコンが重畳表示されていない。
　限定ではなく例として、図１－９中央のホーム画面において、画面最下部のトークの項目がユーザによってタップされると、限定ではなく例として、図１－９右側のトークリスト画面に表示が遷移する。
　トークリスト画面は、限定ではなく例として、この端末２０Ｘに対してメッセージが送信されたトークルームを一覧で確認可能とする画面とすることができる。
　このトークリスト画面のアプリ内位置表示領域では、トークリスト画面であることに基づいて、「トーク」の文字と、前の画面に戻るための「＜」の文字で示される戻るボタンとが表示されている。
　アプリ内位置表示領域の下には、この端末２０Ｘに対してメッセージが送信されたトークルームに関する情報が一覧表示されている。各々のトークルームと対応するトークルームリスト項目（トークリスト項目）には、そのトークルームのアイコン（以下、「トークルームアイコン」と称する。）と、トークルーム名と、そのトークルームがグループトークルームであった場合にはメンバー数とが関連付けて表示されている。
　ここで、トークルームアイコンは、一対一トークルームの場合、限定ではなく例として、トーク相手のユーザのアイコンとすることができ、グループトークルームの場合、限定ではなく例として、グループに設定されたアイコン（グループアイコン）とすることができる。
　また、トークルーム名は、一対一トークルームの場合、限定ではなく例として、トーク相手のユーザ名とすることができ、グループトークルームの場合、限定ではなく例として、グループ名とすることができる。
　本例では、限定ではなく例として、トークルームリスト項目として、ユーザＹ．Ｙとのトークルームに対応したトークルームリスト項目（以下、「ユーザＹ．Ｙ」のトークルームリスト項目と称する。）と、ユーザＡ．Ａのトークルームリスト項目と、ユーザＢ．Ｂのトークルームリスト項目等とが表示されている。
　この例では、各々のトークルームリスト項目には、限定ではなく例として、未読状態であるメッセージ数が関連付けて表示されるように構成されている。
　限定ではなく例として、ユーザＹ．Ｙのトークルームにおいて、端末２０ＸのユーザＸ．Ｘが未読状態である（ユーザＸ．Ｘによって閲覧されていない）メッセージが１件あることに基づいて、ユーザＹ．Ｙのトークルームリスト項目には「１」の数字が関連付けて表示されている。
　この場合、ユーザＹ．Ｙが安否情報として「危険」を設定していることに基づいて、トークリスト画面におけるユーザＹ．Ｙのトークルームリスト項目では、トークルームアイコンに＜危険であることを示すアイコンＤＩＣ２＞（本例では、「危険」の文字が示されているアイコン、以下、適宜「第２危険アイコン」と称する。）が重畳表示されている。
　なお、ユーザＹ．Ｙが安否情報として「安全」を設定している場合、トークリスト画面におけるユーザＹ．Ｙのトークルームリスト項目では、トークルームアイコンに＜安全であることを示すアイコンＳＩＣ２＞（本例では、「安全」の文字が示されているアイコン、以下、適宜「第２安全アイコン」と称する。）が重畳表示される。
　トークリストの各トークルームリスト項目に表示される＜危険であることを示すアイコン＞または＜安全であることを示すアイコン＞を確認することにより、端末２０ＸのユーザＸ．Ｘは、メッセージを端末２０Ｘに対して送信したユーザの安否情報を確認することができる。
　なお、トークルームアイコンに第２安全アイコンＳＩＣ２や第２危険アイコンＤＩＣ２を表示させるのではなく、「安全」の場合は「青色」のアイコンを表示させ、「危険」の場合は「赤色」のアイコンを表示させるなどしてもよい。また、トークルームの名称を示す文字の色や書体を変えて表示させるなどしてもよい。
　なお、これらの表示態様の変更の手法は、友だちリストやグループリストにも同様に適用可能である。
　図１－１０左側には、ユーザＸ．Ｘの端末２０Ｘのトークリスト画面が表示されている。このトークリスト画面は、図１－９右側で示したトークリスト画面とは異なり、ユーザＹ．Ｙが安否情報として「危険」を設定しているものの、トークリスト画面におけるユーザＹ．Ｙのトークルームリスト項目では、トークルームアイコンに第２危険アイコンＤＩＣ２が重畳表示されていない。
　限定ではなく例として、図１－１０左側のトークリスト画面において、ユーザＹ．Ｙに対応したトークルームリスト項目がユーザによってタップされると、限定ではなく例として、図１－１０中央のトークルーム画面が表示される。
　このトークルーム画面には、画面最上部のメッセージングアプリケーションの名称等が表示される領域の下に、限定ではなく例として、メッセージングアプリケーション内のいずれのページ（この例では、トークルーム）が現在表示されているかを示す領域の一種として、トークルームの名称（以下、「トークルーム名」と称する。）を含むトークルーム名表示領域が設けられている。トークルーム名表示領域は、現在ユーザが位置しているメッセージングアプリケーション内のページ（この例では、トークルーム）を示す領域とも言える。
　本例では、トークルーム名表示領域には、限定ではなく例として、前の画面に戻るための「＜」の戻るボタンと、ユーザＸ．ＸがユーザＹ．Ｙを相手としてトークを行うためのトークルームであることを示す文字（本例では「Ｙ．Ｙ」）と、このトークルームに属するユーザの安否情報を表示するための安否情報表示アイコンＩＣ１とが表示されている。
　また、その下には、ユーザＸ．ＸとユーザＹ．Ｙとが対話形式でトークを行うためのトーク領域が構成されており、画面向かって左側には相手であるユーザＹ．Ｙのメッセージが、画面向かって右側には自分であるユーザＸ．Ｘのメッセージが表示されるように構成されている。
　トーク領域の上部には、限定ではなく例として、ユーザＹ．Ｙが設定した安否情報をトークルーム内で報知するためのトークルーム内安否情報（本例では、「Ｙ．Ｙさんが安否確認に回答しました」の文字と、端末のユーザのアイコンと安否に関する情報とを含むユーザ状態アイコンＩＣＹＤ（ユーザＹ．Ｙのアイコン、「危険」の文字、笑顔でないアイコン））が表示されている。以下、ユーザ状態アイコンを、適宜「ユーザ状態アイコン（ユーザ名（のアイコン）、安全または危険（に対応した文字および顔のアイコン））」と称する。
　なお、この表示画面例では、ユーザ状態アイコンを、そのユーザのアイコンと、安否ステータス情報に対応する文字（安全／危険）と、安否ステータス情報に対応するアイコンとを組み合わせたアイコンとしているが、これに限定されない。
　限定ではなく例として、そのユーザのアイコンと、安否ステータス情報に対応する文字（安全／危険）とを組み合わせたアイコンとしたり、そのユーザのアイコンと、安否ステータス情報に対応するアイコンとを組み合わせたアイコンとするなどしてもよい。
　限定ではなく例として、図１－１０中央のトークルーム画面において、安否情報表示アイコンＩＣ１がユーザによってタップされると、限定ではなく例として、図１－１０右側に示すように、トークルーム名表示領域の下に展開する形式で、このトークルームに含まれる各々のユーザの安否情報を表示するためのユーザ別安否情報が表示される。
　この例では、トークルームに属するユーザの安否情報を含むユーザ別安否情報を表示するためのユーザ別安否情報表示領域が構成されており、本例では、安否情報表示アイコンＩＣ１とともに、ユーザ別安否情報として、第２危険アイコンＤＩＣ２が重畳表示されたユーザＹ．Ｙのアイコンと、第２安全アイコンＳＩＣ２が重畳表示されたユーザＸ．Ｘのアイコンとが表示されている。
＜処理＞
　図１－１１は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
　この図では、左側から順に、端末２０Ｘの制御部２１が実行する処理、端末２０Ｙの制御部２１が実行する処理、サーバ１０の制御部１１が実行する処理の一例を示している。
　なお、以下説明する処理は、本開示の手法を実現するための処理の一例に過ぎず、これらに限定されるものではない。
　以下説明する処理に別のステップを追加してもよいし、以下説明する処理から一部のステップを省略（削除）してもよい。
　ここでは、表示画面と同様に、
　・安否登録アカウント＝端末２０ＹのユーザＹ．Ｙ（限定ではなく、第１端末のユーザの一例）のアカウント
　・安否参照アカウント＝端末２０ＸのユーザＸ．Ｘ（限定ではなく、端末のユーザの一例）のアカウント
　とする場合の処理を例示する。
　最初に、端末２０Ｘの制御部２１と、端末２０Ｙの制御部２１と、サーバ１０の制御部１１とは、限定ではなく例として、チャット処理を実行する（Ｘ１１０、Ｙ１１０、Ｓ１１０）。
　チャット処理では、限定ではなく例として、各端末２０の入出力部２３に対する入力（限定ではなく例として、ユーザ入力（ユーザによる操作入力や音入力等）以下同様。）に基づいて、各端末２０の制御部２１は、メッセージングサービスにおけるコンテンツの送受信処理と表示処理とを実行する。また、サーバ１０の制御部１１は、限定ではなく例として、各端末２０から送信されたコンテンツの中継処理を実行する。
　なお、チャット処理は、処理中の任意のステップ間で実行されるようにしてもよい。また、本システムにおいて、チャット処理は実行されなくてもよい。
　次いで、サーバ１０の制御部１１は、限定ではなく例として、サーバ１０の入出力部１２に対する入力（限定ではなく例として、ユーザ入力（サーバ１０のユーザによる操作入力や音入力等））に基づいて、災害が発生したことと、この災害における各端末２０のユーザの安否登録を依頼することとを含む災害情報を、通信Ｉ／Ｆ１４によって各端末２０に送信する（Ｓ１２０）。
　ここで、災害情報は、限定ではなく例として、以下の災害要素Ａ～災害要素Ｈの任意の組み合わせと、ユーザに安否登録を依頼することとを含むように構成するようにしてもよい。
・災害要素Ａ：災害が発生したこと。
・災害要素Ｂ：災害の種類（限定ではなく例として、地震や洪水、大規模火災等）。
・災害要素Ｃ：災害の規模（限定ではなく例として、震度やマグニチュード、河川水位、延焼範囲等）。
・災害要素Ｄ：災害の発生日時。
・災害要素Ｅ：災害の発生場所。
・災害要素Ｆ：災害による副次的な影響（限定ではなく例として、停電や断水の状況や交通機関の運行状況等）。
・災害要素Ｇ：災害に対する対処方法（限定ではなく例として、避難場所や避難経路等）。
・災害要素Ｈ：その他災害に関連する情報。
　なお、災害情報に、その災害における安否登録の期間や期限に関する情報を含めるようにしてもよい。
　なお、サーバ１０の制御部１１は、任意の災害が発生した場合、不図示の災害情報提供サーバから発生した災害に関する情報である災害状況情報（限定ではなく例として、上記の災害要素Ａ～Ｄにより構成される情報）を受信する。すると、サーバ１０の制御部１１は、災害状況情報に基づいて、発生した災害が所定の規模（限定ではなく例として、最大震度５や、大雨）より大きい、または所定の規模以上であると判定する場合、自動的に災害情報を各端末２０に送信するようにしてもよい。
　また、サーバ１０の制御部１１は、任意の災害が発生した場合、災害情報提供サーバから災害状況情報を受信すると、表示部１３に災害情報を送信するか否かの選択用表示画面を表示させるようにしてもよい。そして、サーバ１０の制御部１１は、選択用表示画面に対するユーザ入力に基づいて、災害情報を各端末２０に送信するようにしてもよい。
　通信Ｉ／Ｆ２２によってサーバ１０から災害情報を受信すると、各端末２０の制御部２１は、受信した災害情報を表示部２４に表示させる（Ｘ１２０、Ｙ１２０）。
　限定ではなく例として、安否登録アカウントの端末２０Ｙの入出力部２３に対する入力に基づいて、安否確認情報が入力されると、端末２０Ｙの制御部２１は、限定ではなく例として、入力された安否確認情報と、安否登録アカウントのアプリケーションＩＤとを含む安否確認登録情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ｙ１４０）。
　通信Ｉ／Ｆ１４によって安否登録アカウントの端末２０Ｙから安否確認登録情報を受信すると、サーバ１０の制御部１１は、受信した安否確認登録情報に基づいて、安否情報を生成する。
　安否情報には、限定ではなく例として、安否確認登録情報において送信された安否登録アカウントのアプリケーションＩＤと、安否確認情報とを含めることができる。
　なお、サーバ１０の制御部１１は、安否情報に、安否確認登録情報において送信された安否登録アカウントのアプリケーションＩＤに紐付けられたユーザ名を含めるようにしてもよい。また、サーバ１０の制御部１１は、安否情報に、安否確認登録情報において送信された安否確認情報における安否ステータス情報と、安否コメント情報と、安否位置情報との任意の組み合わせのうち、任意の情報の組み合わせのみ（限定ではなく例として、安否ステータス情報と安否位置情報とが安否確認情報に含まれる場合、安否ステータス情報のみ）を含めるようにしてもよい。
　すると、サーバ１０の制御部１１は、限定ではなく例として、アカウント管理データベース１５５Ａを検索し、安否登録アカウントの友だち管理データに友だち登録されているアカウントを参照する。そして、友だち登録されている各アカウントの端末２０に対して通信Ｉ／Ｆ１４によって安否情報を送信する（Ｓ１４０）。
　なお、サーバ１０の制御部１１は、Ｓ１４０のステップにおいて全ての端末２０に安否情報を送信するようにしてもよい。
　通信Ｉ／Ｆ２２によってサーバ１０から安否情報を受信すると、端末２０Ｘの制御部２１は、受信した安否情報を表示部２４に表示させる（Ｘ１６０）。
　なお、安否参照アカウントの端末２０において、安否情報を表示部２４に表示させる判定条件としては、限定ではなく例として、以下の場合における任意の組み合わせが挙げられる。
・無条件に表示（プッシュ通知等）
・友だちリスト（グループリスト）の閲覧を行うと安否登録アカウントと関連付けて表示
・トークリストの閲覧を行うと安否登録アカウントと関連付けて表示
・安否参照アカウントと安否登録アカウントとの一対一トークルームの閲覧を行うと表示
・安否登録アカウントを含むグループのグループトークルームの閲覧を行うと表示
　また、Ｓ１４０のステップにおいて、サーバ１０が全ての端末２０に安否情報を送信する場合、安否参照アカウントの端末２０の制御部２１は、限定ではなく例として、記憶部２８に記憶される友だち管理データを参照する。そして、友だち管理データに安否登録アカウントのアプリケーションＩＤが含まれる場合、安否情報を表示部２４に表示させるようにしてもよい。
＜第１実施例の効果＞
　本実施例は、安否登録アカウントのユーザ（限定ではなく、第１端末のユーザの一例）とのトーク（限定ではなく、チャットの一例）に関連する処理（限定ではなく、チャットに関連する処理の一例）を行う安否参照アカウントのユーザ（限定ではなく、端末のユーザの一例）の端末２０は、安否登録アカウントのユーザによる自己の端末２０に対する入力に基づいて、安否情報（または安否確認登録情報）（限定ではなく、第１端末のユーザの安否に関する第１情報の一例）を通信Ｉ／Ｆ２２によって受信する。そして、安否参照アカウントのユーザの端末２０は、安否登録アカウントのユーザに関連するトークの情報（限定ではなく、チャットの情報の一例）に関連付けられた安否情報を表示部２４に表示する構成を示している。
　このような構成により得られる実施例の効果の一例として、第１端末のユーザによる第１端末に対する入力に基づいて、第１端末のユーザの安否に関する第１情報を受信した上で、第１端末のユーザに関連するチャットの情報に関連付けられた第１情報を端末の表示部に表示して、端末のユーザに知らせることができる。チャットの情報に関連付けられた形で端末のユーザにとって分かり易い表示を実現することができる。
　なお、第１端末のユーザによる第１端末に対する入力に基づいて、第１端末のユーザの安否に関する第１情報を受信することには、限定ではなく例として、第１端末から第１情報がサーバに送信され、サーバが第１情報を受信したことに基づいて、サーバから端末に第１情報が送信されて端末が第１情報を受信することと、サーバを介さずに第１端末から端末に第１情報が直接的に送信され、それを端末が受信することとを含めることができる。
　また、チャットに関連する処理とは、限定ではなく例として、チャットを行うための情報を送受信する処理や、チャットに関連するコンテンツを表示する処理などの、チャットを行うための各種の処理やチャットを実現するための各種の処理等を含む概念とすることができる。
　また、チャットの情報とは、メッセージングアプリケーションでは、限定ではなく例として、前述した（Ｂ１）～（Ｂ３）に対応する「友だちリスト」、「トークリスト」、「トークルーム」等を含む概念とすることができる。なお、前述した「フォロー」、「フォロワー」等についても同様である。
　また、この場合、安否参照アカウントのユーザの端末２０は、安否情報（または安否確認登録情報）を、サーバ１０を介して通信Ｉ／Ｆ２２によって受信するようにすることができる。
　このような構成により得られる実施例の効果の一例として、サーバを介して、第１情報を適切に受信することができる。
　また、この場合、上記のトークの情報（限定ではなく、チャットの情報の一例）は、メッセージングアプリケーションにおけるトーク（限定ではなく、チャットの一例）で、安否参照アカウントのユーザに関連付けられたユーザのリスト（限定ではなく、ユーザのリストの一例）に含まれるようにすることができる。
　このような構成により得られる実施例の効果の一例として、第１端末のユーザによる第１端末に対する入力に基づいて、第１端末のユーザの安否に関する第１情報を受信した上で、端末のユーザに関連付けられたユーザのリストに含まれるチャットの情報に関連付けられた第１情報を端末の表示部に表示して、端末のユーザに知らせることができる。
　また、この場合、上記のトークの情報（限定ではなく、チャットの情報の一例）は、安否登録アカウントのユーザ（限定ではなく、第１端末のユーザの一例）と安否参照アカウントのユーザ（限定ではなく、端末のユーザの一例）とを含むトークルーム（限定ではなく、第１チャットルームの一例）に関する情報を含むようにすることができる。
　このような構成により得られる実施例の効果の一例として、第１端末のユーザによる第１端末に対する入力に基づいて、第１端末のユーザの安否に関する第１情報を受信した上で、第１端末のユーザと端末のユーザとを含む第１チャットルームに関する情報に関連付けられた第１情報を端末の表示部に表示して、端末のユーザに知らせることができる。第１端末のユーザと端末のユーザとを含む第１チャットルームに関する情報に関連付けられた形で端末のユーザにとって分かり易い表示を実現することができる。
　また、この場合、上記のトークの情報は、安否参照アカウントのユーザが含まれるトークルームのトークリスト（限定ではなく、チャットルームのリストの一例）に含まれる一対一トークルーム（トーク相手）のアイコン画像等の情報（限定ではなく、端末のユーザが含まれるチャットルームのリストに含まれる第１チャットルームに関する情報の一例）や、安否参照アカウントのユーザが含まれるグループトークルームのグループリストに含まれるグループトークルーム（グループ）のアイコン画像等の情報（限定ではなく、端末のユーザが含まれるチャットルームのリストに含まれる第１チャットルームに関する情報の一例）を含むようにすることができる。
　このような構成により得られる実施例の効果の一例として、第１端末のユーザによる第１端末に対する入力に基づいて、第１端末のユーザの安否に関する第１情報を受信した上で、端末のユーザが含まれるチャットルームのリストに含まれる第１チャットルームに関する情報に関連付けられた第１情報を端末の表示部に表示して、端末のユーザに知らせることができる。
　また、この場合、安否参照アカウントのユーザの端末２０は、安否情報に基づいて、上記のアイコン画像等の表示態様を変更する制御を制御部２１によって行うようにすることができる。
　このような構成により得られる実施例の効果の一例として、第１情報に基づいて、第１端末のユーザと端末のユーザとを含む第１チャットルームに関する情報の表示態様を変更することで、端末のユーザにとって分かり易い表示を実現することができる。
　また、この場合、安否情報（限定ではなく、第１情報の一例）は、安否登録アカウントのユーザ（限定ではなく、第１端末のユーザの一例）と安否参照アカウントのユーザ（限定ではなく、端末のユーザの一例）とを含むトークルーム（限定ではなく、第１チャットルームの一例）に表示されるようにすることができる。
　このような構成により得られる実施例の効果の一例として、第１端末のユーザと端末のユーザとを含む第１チャットルームへの第１情報の表示という分かり易い形で、第１端末のユーザの安否を端末のユーザに知らせることができる。
　また、この場合、安否情報（限定ではなく、第１情報の一例）は、安否登録アカウントのユーザ（限定ではなく、第１端末のユーザの一例）によって設定された自身のアイコン画像等の画像（限定ではなく、第１画像の一例）と関連付けられて、上記のトークルームに表示されるようにすることができる。
　このような構成により得られる実施例の効果の一例として、第１端末のユーザによって設定された第１画像と関連づけられて第１チャットルームに第１情報が表示されるため、第１端末のユーザの安否に関する情報であることを端末のユーザが認識し易くなるようにすることができる。
＜第１変形例（１）＞
　上記の実施例では、安否確認情報として、安否ステータス情報のみを登録する例について例示したが、これに限定されない。また、上記の実施例では、安否登録アカウントと安否参照アカウントとが異なる例について例示したが、これに限定されない。
　図１－１２左側は、ユーザＡ．Ａの端末２０Ａの表示部２４に表示されるホーム画面の一例を示している。
　このホーム画面では、図１－８左側に示したユーザＹ．Ｙの端末２０Ｙのホーム画面とは異なり、画面最上部の右側には、この端末２０ＡのユーザＡ．Ａのメッセージングアプリケーションにおけるアイコン画像およびユーザ名（この例では「Ａ．Ａ」）が表示されている。
　グループリストには、グループリストの項目として、テニスサークルに対応したアイコンおよびグループ名（メンバー数）、ゼミ仲間に対応したアイコンおよびグループ名（メンバー数）等が一覧表示されている。
　また、友だちリストには、友だちリストの項目として、ユーザＢ．Ｂに対応したアイコンおよびユーザ名、ユーザＣ．Ｃに対応したアイコンおよびユーザ名、ユーザＤ．Ｄに対応したアイコンおよびユーザ名等が一覧表示されている。
　限定ではなく例として、安否登録ボタンＢＴ１がユーザによってタップされると、限定ではなく例として、図１－１２中央のような表示がなされる。
　この例では、安否登録領域Ｒ１における安全ボタンＳＢＴおよび危険ボタンＤＢＴの下に、安否コメント情報の一種である安否メッセージを入力するための安否メッセージ入力領域が構成されている。
　安否メッセージ入力領域には、「安否メッセージ」の文字とともに、安否メッセージを入力するための領域（入力された安否メッセージが表示される領域）が構成されている。
　また、その下には、安否メッセージの定型文を選択するための領域が構成されている。この例では、安否メッセージの定型文として、限定ではなく例として、「怪我をした」のテキストと、「閉じ込められた」のテキストと、「火災に巻き込まれた」のテキストと、「避難中」のテキストとがあらかじめ用意されており、各々がタップによって選択可能なアイコンとして表示されている。
　また、その下には、安否位置情報の一種である現在の居場所を入力するための現在地入力領域が構成されている。現在地入力領域には、「現在の居場所」の文字と、現在の居場所を入力するための領域（入力された現在の居場所を表示する領域）と、現在地を取得するための現在地取得ボタンとが表示されている。
　そして、画面の最下部には、選択／入力した安否情報を設定するための登録ボタンＢＴ３が設けられている。
　なお、安否コメント情報と安否位置情報とのいずれか一方のみを登録するように安否登録領域Ｒ１を構成してもよい。
　限定ではなく例として、図１－１２中央の安否登録領域Ｒ１において、安全ボタンＳＢＴがユーザＡ．Ａによってタップされた後、登録ボタンＢＴ３がユーザＡ．Ａによってタップされた場合における、ユーザＡ．Ａの端末２０Ａに表示されるホーム画面の一例を図１－１２右側に示す。
　災害情報表示領域では、安否登録ボタンＢＴ１の表示が消去され、これに代えて、ユーザ状態アイコンが表示されている。本例では、ユーザＡ．Ａの状態を示すユーザ状態アイコンＩＣＡＳ（この例では、ユーザＡ．Ａ、安全）が表示されている。
　また、ユーザＢ．Ｂが安否情報として「危険」を設定していることに基づいて、友だちリストのユーザＢ．Ｂに対応したアイコンには、第１危険アイコンＤＩＣ１が重畳表示されている。ユーザＣ．Ｃが安否情報として「危険」を設定していることに基づいて、友だちリストのユーザＣ．Ｃに対応したアイコンには、第１危険アイコンＤＩＣ１が重畳表示されている。ユーザＤ．Ｄが安否情報として「安全」を設定していることに基づいて、ユーザＤ．Ｄに対応したアイコンに、第１安全アイコンＳＩＣ１が重畳表示されている。
　図１－１３左側は、ユーザＡ．Ａの端末２０Ａのトークリスト画面が表示されている。このトークリスト画面は、図１－９右側のトークリスト画面とは異なり、アプリ内位置表示領域の下であって、この端末２０Ａに対してメッセージが送信されたトークルームに関する情報が一覧表示されている領域の上には、災害が発生したことをトークリスト画面において報知するための第２災害情報を示す領域である第２災害情報表示領域が構成されている。そして、この例では、地震が発生したことに基づいて、第２災害情報（限定ではなく例として、「２０ＸＸ／０８／０４　０９：３９発表」の文字と、「最大震度：５強」の文字と、「地震発生」の文字とが表示されている。また、ユーザＡ．Ａが、自身は「安全」であることを設定したことに基づき、その旨を示すユーザ状態アイコンＩＣＡＳ（ユーザＡ．Ａ、安全））が第２災害情報表示領域に表示されている。
　本例では、限定ではなく例として、トークルームリスト項目として、テニスサークルのトークルームリスト項目、ユーザＤ．Ｄのトークルームリスト項目、ユーザＢ．Ｂのトークルームリスト項目、ゼミ仲間のトークルームリスト項目、ユーザＣ．Ｃのトークルームリスト項目、ユーザＥ．Ｅのトークルームリスト項目等が表示されている。
　本例では、テニスサークルのトークルームリスト項目に関連付けて未読数「１３」の数字が表示され、ユーザＤ．Ｄのトークルームリスト項目に関連付けて未読数「２」の数字が表示され、ユーザＢ．Ｂのトークルームリスト項目に関連付けて未読数「１」の数字が表示され、ゼミ仲間のトークルームリスト項目に関連付けて未読数「２」の数字が表示され、ユーザＣ．Ｃのトークルームリスト項目に関連付けて未読数「２」の数字が表示され、ユーザＥ．Ｅのトークルームリスト項目に関連付けて未読数「１」の数字が表示されている。
　また、ユーザＤ．Ｄが安否情報として「安全」を設定していることに基づいて、ユーザＤ．Ｄのトークルームリスト項目に対応したアイコンには、第２安全アイコンＳＩＣ２が重畳表示されている。ユーザＢ．Ｂが安否情報として「危険」を設定していることに基づいて、ユーザＢ．Ｂのトークルームリスト項目に対応したアイコンには、第２危険アイコンＤＩＣ２が重畳表示されている。ユーザＣ．Ｃが安否情報として「危険」を設定していることに基づいて、ユーザＣ．Ｃのトークルームリスト項目に対応したアイコンには、第２危険アイコンＤＩＣ２が重畳表示されている。ユーザＥ．Ｅが安否情報として「安全」を設定していることに基づいて、ユーザＥ．Ｅのトークルームリスト項目に対応したアイコンには、第２安全アイコンＳＩＣ２が重畳表示されている。
　本例では、グループトークルームに属するいずれかのメンバーが安否情報の設定を行っている場合であっても、グループトークルームに対応したアイコンには、安否情報に基づくアイコンが重畳表示されていない。
　この場合、テニスサークルのグループトークルームに属するいずれかのメンバーが安否情報の設定を行っている場合であっても、テニスサークルのトークルームリスト項目に対応したアイコンには、第２安全アイコンＳＩＣ２および第２危険アイコンＤＩＣ２のいずれも重畳表示されていない。ゼミ仲間のグループトークルームに属するいずれかのメンバーが安否情報の設定を行っている場合であっても、ゼミ仲間のトークルームリスト項目に対応したアイコンには、第２安全アイコンＳＩＣ２および第２危険アイコンＤＩＣ２のいずれも重畳表示されていない。
　また、このトークリスト画面において、トークルームリスト項目に対応したユーザ名の下には、そのユーザによって、前述した現在地入力領域に入力されて登録された安否位置情報と、前述した安否メッセージ入力領域に入力されて登録された安否コメント情報とに基づく情報が表示されている。
　この例では、限定ではなく例として、ユーザＢ．Ｂに対応する「Ｂ．Ｂ」の文字の下に、ユーザＢ．Ｂによって登録された現在地「つくば市」と、ユーザＢ．Ｂによって登録された安否メッセージ「怪我しちゃった」とを複合した（組み合わせた）情報として複合安否情報「つくば／怪我しちゃった」が表示されている。
　ユーザＣ．ＣやユーザＥ．Ｅについても、登録された情報が同様に表示されている。
　なお、この表示画面例では、トークルームリスト項目のユーザ名の下に複合安否情報を表示させているが、これに限定されない。
　限定ではなく例として、ユーザ名の右に複合安否情報を表示させるようにしてもよい。また、この場合、トークルームリスト項目のユーザ名の下には、そのトークルームにおける最新のコンテンツ（メッセージ）に基づく情報を表示させるようにしてもよいし、表示させなくてもよい。
　また、限定ではなく例として、ユーザのアイコンに重畳して表示される安否ステータス情報に基づくアイコン（第２安全アイコンＳＩＣ２または第２危険アイコンＤＩＣ２がタップされたことに基づいて、吹き出しやバブル等によって複合安否情報が表示されるようにしてもよい。
　また、安否位置情報と安否コメント情報との両方をトークリストに表示させることは必須ではなく、これらを別の画面に表示させてもよい。
　また、複合安否情報を、前述した友だちリストが表示される画面（ホーム画面等）に表示させるようにしてもよい。
　また、安否位置情報と安否コメント情報とのいずれか一方の情報を、前述した友だちリストが表示される画面（ホーム画面等）に表示させるようにしてもよい。
　限定ではなく例として、図１－１３左側のトークリスト画面において、ユーザＢ．Ｂのトークルームリスト項目がユーザによってタップされると、限定ではなく例として、図１－１３右側のトークルーム画面が表示される。この画面は、図１－１０中央で示したトークルーム画面とは異なり、トーク領域にトークルーム内安否情報が表示されていない一方で、ユーザ別安否情報表示領域にユーザ別安否情報が表示されている。
　本例では、トークルーム名表示領域には、限定ではなく例として、ユーザＡ．ＡがユーザＢ．Ｂを相手としてトークを行うためのトークルームであることを示す文字（本例では「Ｂ．Ｂ」）が表示されている。
　また、その下のユーザ別安否情報表示領域には、限定ではなく例として、ユーザ別安否情報として、第２危険アイコンＤＩＣ２が重畳表示されたユーザＢ．Ｂのアイコンと、第２安全アイコンＳＩＣ２が重畳表示されたユーザＡ．Ａのアイコンとが表示されている。
　また、ユーザＢ．Ｂから発信されたテキストコンテンツとして、地震で足を怪我してしまい動けなくなっていることを伝えるテキストコンテンツが、トーク領域の左側に表示されている。
　図１－１４は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。
　この図では、左側から順に、端末２０Ｘの制御部２１が実行する処理、端末２０Ｙの制御部２１が実行する処理、サーバ１０の制御部１１が実行する処理の一例を示している。
　ここでは、表示画面とは異なり、
　・安否登録アカウント　兼　安否参照アカウント＝端末２０ＸのユーザＸ．Ｘ（表示画面における端末２０ＡのユーザＡ．Ａ）
　・安否登録アカウント＝端末２０ＹのユーザＹ．Ｙ（表示画面における端末２０Ｂ～端末２０Ｅのユーザ）
　とする場合の処理を例示する。
　端末２０Ｘの制御部２１は、限定ではなく例として、災害情報を表示部２４に表示させると（Ｘ１２０）、限定ではなく例として、安否登録アカウントの端末２０Ｘの入出力部２３に対する入力に基づいて、安否確認情報を入力するか否かを判定する（Ｘ１３０）。安否確認情報を入力すると判定された場合（Ｘ１３０：ＹＥＳ）、端末２０Ｘの制御部２１は、安否確認情報を受け付け、安否確認登録情報をサーバ１０に送信する（Ｘ１４０）。安否確認情報を入力しないと判定された場合（Ｘ１３０：ＮＯ）、端末２０Ｘの制御部２１は、Ｘ１４０のステップをスキップする。
　端末２０Ｙの制御部２１においても同様に、Ｙ１１０～Ｙ１４０の各ステップを実行する。
　通信Ｉ／Ｆ１４によって端末２０Ｘから安否確認登録情報を受信する場合（Ｓ１３０）、サーバ１０の制御部１１は、受信した安否確認登録情報に基づいて、安否情報を生成し、各端末２０に送信する（Ｓ１４０）。他の端末（限定ではなく例として、端末２０Ｙ）から安否確認登録情報を受信する場合についても同様である。
　通信Ｉ／Ｆ２２によってサーバ１０から安否情報を受信したと判定される場合（Ｘ１５０：ＹＥＳ）、端末２０Ｘの制御部２１は、受信した安否情報を表示部２４に表示させる（Ｘ１６０）。
　なお、複数回安否情報を受信したと判定される場合、端末２０Ｘの制御部２１は受信するたびに受信した安否情報を表示部２４に表示させるようにしてもよいし、安否登録アカウントが異なる場合のみ受信した安否情報を表示部２４に表示させるようにしてもよい。
　端末２０Ｙの制御部２１においても同様に、Ｙ１５０～Ｙ１６０の各ステップを実行する。
　本変形例は、安否参照アカウントのユーザの端末２０が、自己の端末２０のユーザによる自己の端末２０に対する入力に基づいて、自己の端末２０のユーザの安否に関する安否情報（または安否確認登録情報）（限定ではなく、端末のユーザの安否に関する第３情報の一例）を通信Ｉ／Ｆ１２２によって送信する構成を示している。
　このような構成により得られる変形例の効果の一例として、端末のユーザによる端末に対する入力に基づいて、端末のユーザの安否に関する第３情報を送信して、端末のユーザの安否を他者に知らせることができる。
＜第１変形例（２）＞
　上記の実施例では、安否情報をユーザアカウントと関連付けて表示させる例について例示したが、これに限定されない。限定ではなく例として、安否情報を安否登録アカウントが属するグループアカウントと関連付けて表示させるようにしてもよい。
　図１－１５は、本変形例においてサーバ１０の記憶部１５に記憶される情報の一例を示す図である。
　記憶部１５には、限定ではなく例として、アプリケーション管理処理として実行されるアプリケーション管理処理プログラム１５１と、アカウント登録データ１５３と、アカウント管理データベース１５５とに加えて、グループ管理データベース１５７が記憶される。
　グループ管理データベース１５７は、グループに関する情報を管理するためのデータベースであり、その一例であるグループ管理データベース１５７のデータ構成例を図１－１６に示す。
　グループ管理データベース１５７には、グループごとの管理データとして、グループ管理データが記憶される。
　各々のグループ管理データには、限定ではなく例として、グループＩＤと、グループ名と、グループメンバーデータとが記憶される。
　グループＩＤは、グループ管理データで管理されるグループを識別するための情報である。
　このグループＩＤは、好ましくはグループごとに一意な値であり、限定ではなく例として、サーバ１０によってグループごとに一意な値（固有の値）が設定されて記憶される。
　グループ名は、このグループの名称であり、限定ではなく例として、端末２０のユーザがグループを作成する際に登録する名称が記憶される。
　グループメンバーデータは、このグループのメンバーである（グループに属する）アカウントのアプリケーションＩＤを記憶させるためのデータであり、限定ではなく例として、ユーザがグループ参加登録を行うと、サーバによってグループ参加登録を行ったユーザのアプリケーションＩＤが追加され更新される。
　なお、グループ管理データに、グループの代表であるアカウントのアプリケーションＩＤを関連付けて記憶させるようにしてもよい。
　図１－１７左側は、ユーザＡ．Ａの端末２０Ａのトークリスト画面が表示されている。このトークリスト画面では、図１－１３左側の表示画面から、Ｂ．Ｂとのトークルームが閲覧されたことに基づいて、Ｂ．Ｂとの間でのメッセージ未読数が「０」（非表示）となっている。
　限定ではなく例として、図１－１７左側のトークリスト画面において、ゼミ仲間のトークルームリスト項目がユーザによってタップされると、限定ではなく例として、図１－１７右側のトークルーム画面が表示される。
　この画面は、図１－１３右側の表示画面と異なり、トークルーム名表示領域には、限定ではなく例として、ユーザＡ．Ａがゼミ仲間のグループを相手としてトークを行うためのトークルームであることを示す文字（本例では「ゼミ仲間（４）」（数字はメンバー数））が表示されている。
　ユーザ別安否情報表示領域には、ユーザ別安否情報として、第２危険アイコンＤＩＣ２が重畳表示されたユーザＢ．Ｂのアイコンと、第２安全アイコンＳＩＣ２が重畳表示されたユーザＡ．Ａのアイコンと、第２安全アイコンＳＩＣ２が重畳表示されたユーザＤ．Ｄのアイコンと、第２危険アイコンＤＩＣ２が重畳表示されたユーザＦ．Ｆのアイコンとが表示されている。
　また、トーク領域には、ユーザＤ．Ｄから送信されたコンテンツとして、ユーザＢ．Ｂが今日つくばで学会発表する予定であることを確認するテキストコンテンツが表示され、その下には、ユーザＦ．Ｆから送信されたコンテンツとして、つくばで震度５弱の地震が発生したことでユーザＢ．Ｂを心配するテキストコンテンツが表示されている。
　図１－１８左側には、ユーザＡ．Ａの端末２０Ａのトークリスト画面を示している。
　このトークリスト画面は、図１－１３左側のトークリスト画面とは異なり、グループトークルームに属するいずれかのメンバーが安否情報の設定を行っている場合に、グループトークルームに対応したアイコンに、安否情報に基づく画像（アイコン等）が関連付けて表示される一例を示す図である。
　本例では、グループトークルームに属するメンバーが安否情報の設定を行っている場合に、グループトークルームに対応したアイコンに、安否情報に基づくエフェクト安否情報が付加表示される。
　限定ではなく例として、グループトークルームに属する全てのメンバーの安否情報が「安全」を設定している場合、第１エフェクト情報ＳＦＡ（限定ではなく例として、白色のオブジェクト）がグループトークルームに対応したアイコンに付加表示される。
　限定ではなく例として、グループトークルームに属する１名以上のメンバーの安否情報が「危険」を設定している場合、第２エフェクト情報ＤＦＡ（限定ではなく例として、赤色のオブジェクト）がグループトークルームに対応したアイコンに付加表示される。
　この例では、テニスサークルのグループトークルームに属するメンバー全員が、安否情報として「安全」を設定していることに基づいて、テニスサークルのグループトークルームに対応したアイコンに、第１エフェクト情報ＳＦＡが付加表示されている。
　また、この例では、ゼミ仲間のグループトークルームに属するメンバーのうち１名が、安否情報として「危険」を設定していることに基づいて、ゼミ仲間のグループトークルームに対応したアイコンに、第２エフェクト情報ＤＦＡが付加表示されている。
　限定ではなく例として、図１－１８左側のトークルームリスト画面において、ゼミ仲間のトークルームリスト項目がユーザによってタップされると、限定ではなく例として、図１－１８右側のトークルーム画面が表示される。
　この画面は、図１－１７右側のトークルーム画面と同様であるので説明を省略する。
　なお、表示態様を変更する手法は上記に限られない。
　限定ではなく例として、グループトークルームに属する全てのメンバーの安否情報が「安全」を設定している場合は「青色」でグループトークルームに対応したアイコンを表示させ、グループトークルームに属する１名以上のメンバーの安否情報が「危険」を設定している場合は「赤色」でグループトークルームに対応したアイコンを表示させるなどしてもよい。
　さらに細分化して、グループトークルームに属するメンバーのうちの「危険」を設定している人数（または割合）に基づいて、「黄色」、「赤色」でグループトークルームに対応したアイコンを表示させたり、上記のエフェクト表示を行うようにしてもよい。
　また、これらに限定されるわけではなく、グループトークルームの名称を示す文字の色や書体を変えて表示させるなどしてもよい。
　トークリスト内に表示させる場合、限定ではなく例として、サーバ１０の制御部１１は、安否確認登録情報を受信すると、グループ管理データベース１５７を参照し、安否登録アカウントが属するグループを検索する。そして、安否登録アカウントが属する各々のグループについて、グループメンバーデータに登録されている各アプリケーションＩＤの安否登録データを参照する。
　あるグループメンバーデータに登録されている全てのアプリケーションＩＤの安否登録データが「安全」である場合、サーバ１０の制御部１１は、そのグループに対する安否情報（以下、「グループ安否情報」と称する。）をメンバー全員が「安全」であることを示す第１態様で生成する。全てのアプリケーションＩＤの安否登録データが「安全」でない場合には、サーバ１０の制御部１１は、そのグループに対するグループ安否情報をメンバー全員が「安全」ではないことを示す第２態様で生成する。
　そして、サーバ１０の制御部１１は、グループ安否情報を通信Ｉ／Ｆ１４によってそのグループメンバーデータに登録されている全てのアカウントの端末２０に送信する。
　上記の実施例および本変形例は、安否参照アカウントのユーザの端末２０は、安否情報を含む、一対一トークルームやグループトークルーム等のトークルーム（限定ではなく、第１チャットルームの一例）に含まれるユーザの安否に関する情報に基づいて、そのトークルームに関する情報の表示態様を変更する制御を制御部２１によって行う構成を示している。
　このような構成により得られる実施例の効果の一例として。第１情報を含む、第１端末のユーザと端末のユーザとを含む第１チャットルームに含まれるユーザの安否に関する情報に基づいて、第１チャットルームに関する情報の表示態様を適切に変更することができる。
＜第１変形例（３）＞
　上記の実施例では、安否ステータス情報を「安全」と「危険」の２クラスとしたが、これに限定されない。他の安否ステータス情報を含めるようにしてもよい。
　限定ではなく例として、安否情報を「安全」と「危険」と「エリア外」の３クラスで設定可能であるようにしてもよい。
　図１－１９左側は、ユーザＡ．Ａの端末２０Ａのホーム画面が表示されている。この画面は、図１－１２中央のホーム画面とは異なり、安否登録領域Ｒ１において、安否情報として安全であることを設定するための安全ボタンＳＢＴと、安否情報として安全でないことを設定するための危険ボタンＤＢＴとに加えて、安否情報としてエリア外であることを設定するためのエリア外ボタンＡＢＴ（本例では、「エリア外」の文字で示されるボタン）が表示される一例を示す図である。
　「エリア外」である場合とは、限定ではなく例として、現在発生している災害の影響を受けない位置にユーザが位置している場合であり、限定ではなく例として、災害が地震である場合、ユーザの端末２０が示す現在地が震源地から設定距離（限定ではなく例として２００ｋｍ）以上離れた位置に位置している場合等である。
　限定ではなく例として、図１－１９左側の安否登録領域Ｒ１において、安全ボタンＳＢＴがユーザＡ．Ａによってタップされた後、登録ボタンＢＴ３がユーザＡ．Ａによってタップされ、ホーム画面に表示が遷移する（不図示）。そして、このホーム画面において、画面最下部のトークの項目がユーザによってタップされると、限定ではなく例として、図１－１９右側に示すトークリスト画面が端末２０Ａの表示部２４に表示される。
　このトークリスト画面では、図１－１３左側のトークリスト画面とは異なり、ユーザＥ．Ｅが安否情報として「エリア外」を設定していることに基づいて、ユーザＥ．Ｅに対応したアイコンに、エリア外であることを示すエリア外アイコンＡＩＣ（本例では、「エリア外」の文字を含むアイコン）が重畳表示されている。
　なお、これら以外にも、限定ではなく例として、元気であることを示す「元気」、少し元気であることを示す「少し元気」、あまり元気ではないことを示す「あまり元気ない」、元気がないことを示す「元気ない」等の情報を安否ステータス情報に含めるようにしてもよい。
＜第１変形例（４）＞
　上記の実施例では、サーバ１０において、安否確認登録情報に基づく安否情報を生成したが、これに限定されない。限定ではなく例として、端末２０において安否情報を生成するようにしてもよい。
　この場合、限定ではなく例として、安否登録アカウントの端末２０Ｙの制御部２１は、安否確認登録情報を受け付けると、安否情報を生成する。すると、安否登録アカウントの端末２０Ｙの制御部２１は、安否登録アカウントの友だち管理データを参照し、限定ではなく例として、安否登録アカウントと友だち登録済みであるアカウントの各端末２０に安否情報を送信する。
　なお、安否登録アカウントの端末２０Ｙの制御部２１は、限定ではなく例として、サーバ１０を介して安否情報を各端末２０に送信するようにしてもよい。また、安否登録アカウントの端末２０Ｙの制御部２１は、限定ではなく例として、ブロードキャスト通信を利用して、全ての端末２０に安否情報を送信するようにしてもよい。
＜第２実施例＞
　第１実施例では、安否登録アカウントの端末２０において、一度だけ安否登録を行う例を例示した。第２実施例は、安否登録アカウントの端末２０のユーザが繰り返し安否登録を行うことで、安否参照アカウントの端末２０において安否情報が更新される実施例である。
　第２実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
　また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
＜表示画面＞
　本実施例における表示画面では、安否確認情報として、安否ステータス情報のみを登録する例について例示する。また、安否参照アカウントの端末２０において、安否情報をトークルーム内にのみ表示する場合について例示する。
　図２－１左側のホーム画面では、限定ではなく例として、ユーザＹ．Ｙが安否情報として「危険」を設定していることに基づいて、ユーザ状態アイコンＩＣＹＤ（ユーザＹ．Ｙ、危険）が表示されている。
　また、ユーザＹ．Ｙの端末２０Ｙのホーム画面に重畳して、安否登録領域Ｒ１がせり上がり表示されている。この安否登録領域Ｒ１は、本実施例では、安否情報を変更するために用いられる。
　安否登録領域Ｒ１には、ユーザに安否情報を設定することを促す旨のメッセージ（本例では、「安否確認」の文字と、「みんなに安否を伝えよう」の文字）が表示されている。その下には、安全ボタンＳＢＴと危険ボタンＤＢＴとが設けられている。また、画面下部には、安否情報を、選択された安否情報に変更するための変更ボタンＢＴ５が表示されている。
　限定ではなく例として、図２－１左側の安否情報変更領域において、安全ボタンＳＢＴがユーザによってタップされた後、変更ボタンＢＴ５がユーザによってタップされた場合における、ユーザＸ．Ｘの端末２０Ｘに表示されるトークリスト画面の一例を図２－１中央に示す。このトークリスト画面は、図１－１０左側の表示画面と同様であるので説明を省略する。
　限定ではなく例として、図２－１中央のトークリスト画面において、ユーザＹ．Ｙに対応したトークルームリスト項目がユーザによってタップされると、限定ではなく例として、図２－１右側のトークルーム画面が表示される。
　このトークルーム画面のトーク領域の上部には、限定ではなく例として、ユーザＹ．Ｙが設定した安否情報をトークルーム内で通知するための第１通知情報ＮＩ１（本例では、「Ｙ．Ｙさんが安否確認に回答しました」の文字と、ユーザ状態アイコンＩＣＹＤ（ユーザＹ．Ｙ、危険））が表示されている。
　その下には、限定ではなく例として、ユーザＹ．Ｙからのコンテンツとして、テキストコンテンツ（「地震　大丈夫だった？」）が表示されている。
　また、その下には、ユーザＹ．Ｙが安否情報を「危険」から「安全」に変更したことに基づき、限定ではなく例として、安否が安全に変更された第２通知情報ＮＩ２（本例では、「Ｙ．Ｙさんが安否確認に回答しました」の文字と、ユーザ状態アイコンＩＣＹＳ（ユーザＹ．Ｙ、安全））が表示されている。
　その下には、限定ではなく例として、ユーザＹ．Ｙからのコンテンツとして、テキストコンテンツ（「避難しました！」）が表示されている。
＜処理＞
　図２－２は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
　この図では、左側から順に、端末２０Ｘの制御部２１が実行する処理、端末２０Ｙの制御部２１が実行する処理、サーバ１０の制御部１１が実行する処理の一例を示している。
　限定ではなく例として、Ｓ１２０とＸ１２０とＹ１２０とのステップが実行されると、安否確認処理が実行される（Ｘ２１０、Ｙ２１０、Ｓ２１０）。
　図２－３は、安否確認処理の流れの一例を示すフローチャートである。図の見方は、図２－２と同様である。
　端末２０Ｘの制御部２１は、限定ではなく例として、図１－１４におけるＸ１３０～Ｘ１６０のステップと同様に、Ｘ２１３０～Ｘ２１６０のステップを実行する。また、端末２０Ｙの制御部２１は、限定ではなく例として、図１－１４におけるＹ１３０～Ｙ１６０のステップと同様に、Ｙ２１３０～Ｙ２１６０のステップを実行する。サーバ１０の制御部１１は、限定ではなく例として、図１－１４におけるＳ１３０～Ｓ１４０のステップと同様に、Ｓ２１３０～Ｓ２１４０のステップを実行する。
　図２－２に戻り、安否確認処理が実行されると、端末２０Ｘの制御部２１と、端末２０Ｙの制御部２１と、サーバ１０の制御部１１とは、処理を終了させるか否かを判定する（Ｘ２２０、Ｙ２２０、Ｓ２２０）。ここで、処理を終了させる判定条件としては、限定ではなく例として、災害発生日時から特定期間（限定ではなく例として、一週間）が経過した場合や、サーバ１０のユーザ入力に基づいて、安否確認サービスが停止されることが選択された場合等が挙げられる。
　処理を終了させると判定された場合（Ｘ２２０：ＹＥＳ、Ｙ２２０：ＹＥＳ、Ｓ２２０：ＹＥＳ）、各端末２０の制御部２１およびサーバ１０の制御部１１は、処理を終了させる。
　処理を終了させないと判定された場合（Ｘ２２０：ＮＯ、Ｙ２２０：ＮＯ、Ｓ２２０：ＮＯ）、各端末２０の制御部２１およびサーバ１０の制御部１１は、再度安否確認処理を実行させる（Ｘ２１０、Ｙ２１０、Ｓ２１０）。
　なお、各端末２０の制御部２１およびサーバ１０の制御部１１は、安否確認処理の前後の任意のタイミングにおいてチャット処理を実行するようにしてもよい。
　図２－４は、本実施例において各装置が実行する処理のタイミングの一例を示すタイミングチャートである。
　ここでは、表示画面と同様に、
　・安否登録アカウント＝端末２０ＹのユーザＹ．Ｙ（限定ではなく、第１端末のユーザの一例）のアカウント
　・安否参照アカウント＝端末２０ＸのユーザＸ．Ｘ（限定ではなく、端末のユーザの一例）のアカウント
　とする場合の処理を例示する。
　限定ではなく例として、安否確認処理が実行され、端末２０Ｙにおいて、安否確認登録情報の入力（操作入力等）を受け付ける（Ｙ２１３０）と、第１の安否確認登録情報がサーバ１０に送信される（Ｙ２１４０）（タイミング「ＴＭ１１０」）。そして、サーバ１０は第１の安否確認登録情報を受信する（Ｓ２１３０：ＹＥＳ）。
　サーバ１０の制御部１１は、第１の安否確認登録情報に基づいて、第１の安否情報を生成し、各端末２０に送信する（Ｓ２１４０）（タイミング「ＴＭ１２０」）。
　端末２０Ｘは第１の安否情報を受信すると表示処理を実行する（Ｘ２１６０）（タイミング「ＴＭ１３０」）。
　再度安否確認処理が実行され、端末２０Ｙにおいて、安否確認登録情報の入力を受け付ける（Ｙ２１３０）と、第１の安否確認登録情報がサーバ１０に送信される（Ｙ２１４０）（タイミング「ＴＭ１４０」）。そして、サーバ１０は第２の安否確認登録情報を受信する（Ｓ２１３０：ＹＥＳ）。
　サーバ１０の制御部１１は、第２の安否確認登録情報に基づいて、第２の安否情報を生成し、各端末２０に送信する（Ｓ２１４０）（タイミング「ＴＭ１５０」）。
　端末２０Ｘは第２の安否情報を受信すると表示処理を実行する（Ｘ２１６０）（タイミング「ＴＭ１６０」）。
　なお、サーバ１０の制御部１１は、第２の安否確認登録情報を受信した場合、第１の安否確認登録情報と第２の安否確認登録情報との安否比較処理を行うようにしてもよい。そして、第１の安否確認登録情報と第２の安否確認登録情報とに差異が生じていない場合、第２の安否情報を各端末２０に送信しないようにしてもよい。
　また、サーバ１０の制御部１１は、安否比較処理の結果、第１の安否確認登録情報と第２の安否確認登録情報とに差異が生じている場合、安否登録アカウントの安否状況に変化が生じたことを示す安否変化情報を各端末２０に送信するようにしてもよい。
　本タイミングチャートでは、安否登録アカウントの端末２０Ｙにおいて２回安否確認登録情報が入力される例を例示したが、３回以上安否確認登録情報が入力される場合についても同様に処理を実行することができる。
＜第２実施例の効果＞
　本実施例は、安否参照アカウントのユーザの端末２０が、安否登録アカウントのユーザ（限定ではなく、第１端末のユーザの一例）によって、第１の安否情報（限定ではなく、第１情報の一例）が第２の安否情報（限定ではなく、第２情報の一例）に変更された場合、第２の安否情報を通信Ｉ／Ｆ２２によって受信する構成を示している。
　このような構成により得られる実施例の効果の一例として、第１端末のユーザによって、第１端末のユーザの安否に関する第１情報が第２情報に変更された場合であっても、端末が第２情報を確実に取得可能となる。
　また、この場合、第２の安否情報は、安否登録アカウントのユーザ（限定ではなく、第１端末のユーザの一例）と安否参照アカウントのユーザ（限定ではなく、端末のユーザの一例）とを含むトークルーム（限定ではなく、第１チャットルームの一例）に表示されるようにすることができる。
　このような構成により得られる実施例の効果の一例として、第１端末のユーザと端末のユーザとを含む第１チャットルームへの表示という分かり易い形で、第２情報を端末のユーザに知らせることができる。
＜第２変形例（１）＞
　上記の実施例では、安否登録アカウントの端末２０において第２の安否確認登録情報が登録されると、安否参照アカウントの端末２０は自動的に第２の安否情報を受信する例を例示したが、これに限定されない。
　限定ではなく例として、安否参照アカウントの端末２０において、特定の表示要素を表示させた場合など、設定された条件が成立した場合に、第２の安否情報を受信するようにしてもよい。
　本変形例における表示画面では、安否確認情報として、安否ステータス情報のみを登録する例について例示する。また、安否参照アカウントの端末２０において、安否情報を友だちリストと、ユーザのプロフィール画面とに表示させる場合について例示する。なお、安否情報をトークリスト画面やトークルーム画面に表示させるようにしてもよい。
　図２－５左側は、ユーザＹ．Ｙの端末２０Ｙのホーム画面に重畳して、設定済みの安否情報を変更するための安否情報変更領域がせり上がり表示されている。このホーム画面は、図２－１左側の表示画面と同様であるので説明を省略する。
　限定ではなく例として、図２－５左側の安否情報変更領域において、安全ボタンＳＢＴがユーザによってタップされた後、変更ボタンＢＴ５がユーザによってタップされた場合における、ユーザＸ．Ｘの端末２０Ｘに表示されるホーム画面の一例を図２－５中央に示す。
　このホーム画面では、友だちリストの項目として、ユーザＹ．Ｙに対応したアイコンおよびユーザ名、ユーザＡ．Ａに対応したアイコンおよびユーザ名、ユーザＢ．Ｂに対応したアイコンおよびユーザ名等が一覧表示されている。そして、この例では、ユーザＹ．Ｙが安否情報として「危険」を設定していることに基づいて、友だちリストのユーザＹ．Ｙのアイコンと関連付けて第１危険アイコンＤＩＣ１が重畳表示され、ユーザＡ．Ａが安否情報として「安全」を設定していることに基づいて、友だちリストのユーザＡ．Ａのアイコンと関連付けて第１安全アイコンＳＩＣ１が重畳表示され、ユーザＢ．Ｂが安否情報として「危険」を設定していることに基づいて、友だちリストのユーザＢ．Ｂのアイコンと関連付けて第１危険アイコンＤＩＣ１が重畳表示されている。
　限定ではなく例として、図２－５中央のホーム画面において、ユーザＹ．Ｙに対応した友だちリストの項目がユーザによってタップされると、限定ではなく例として、図２－５右側のユーザＹ．Ｙに対応したプロフィール画面に表示が遷移する。
　プロフィール画面は、限定ではなく例として、選択されたユーザのプロフィールに関する情報を表示する画面とすることができる。そして、このプロフィール画面には、限定ではなく例として、各ユーザのメッセージングアプリケーションにおけるアイコン画像、ユーザ名、安否に関する情報、そのユーザを相手としたトークを行うためのボタン、そのユーザを相手とした音声通話を行うためのボタン、このユーザを相手としたビデオ通話を行うためのボタン等を表示させるようにすることができる。
　この例では、ユーザＹ．Ｙが安否情報を「危険」から「安全」に変更したことに基づいて、限定ではなく例として、画面上部に、メッセージングアプリケーション（サーバ１０）を発信元とする、ユーザＹ．Ｙが安否情報を変更したことを示すテキスト（Ｙ．Ｙさんのステータス（ステイタス）が変わりました）やアイコン（ユーザＹ．Ｙのアイコンおよび第２危険アイコンＤＩＣ２→第２安全アイコンＳＩＣ２）等を含む、プッシュ形式で表示されるプッシュ通知ＰＮ１が表示されている。
　また、ユーザＹ．Ｙのプロフィールを示すアイコンおよびユーザ名の下には、ユーザＹ．Ｙの安否に関する情報として、第２安全アイコンＳＩＣ２が表示されている。
　より具体的には、図２－５中央のホーム画面では、友だちリストのユーザＹ．Ｙのアイコンと関連付けて第１危険アイコンＤＩＣ１が表示されていた。ユーザＹ．Ｙによって安否に関する第１情報（危険）が第２情報（安全）に変更され、図２－５右側に示すユーザＹ．Ｙのプロフィール画面が表示されたことに基づき、ユーザＹ．Ｙのアイコンと関連付けて第２安全アイコンＳＩＣ２が表示されている。
　この例では、図２－５中央のホーム画面において、ユーザＹ．Ｙに対応した友だちリストの項目がユーザによってタップされると、端末２０Ｘの制御部２１は、図２－５右側のユーザＹ．Ｙに対応したプロフィール画面を表示させる。そして、端末２０Ｘの制御部２１は、安否更新要求情報を通信Ｉ／Ｆ２２によってサーバ１０に送信し、これに基づいて、上記のプッシュ通知で表示するための情報が、サーバ１０から端末２０Ｘに送信される。そして、端末２０Ｘの制御部２１は、受信した情報に基づいて、上記のプッシュ通知を表示させるとともに、受信した情報に基づいて、変更後の安否情報に対応するアイコン（この例では、安全に対応する第２安全アイコンＳＩＣ２）を表示させる。
　なお、端末２０Ｘの制御部２１が安否更新要求情報をサーバ１０に送信すると、これに基づいて、変更後の安否情報（この例では、安全）がサーバ１０から端末２０Ｘに送信されるようにする。そして、端末２０Ｘの制御部２１は、受信した情報に基づいて、変更後の安否情報に対応するアイコン（この例では、安全に対応する第２安全アイコンＳＩＣ２）を表示させる。また、端末２０Ｘの制御部２１は、先に受信していた変更前の安否情報（この例では「危険」）と、新たに受信した変更後の安否情報（この例では「安全」）とに基づいて、上記のプッシュ通知を表示するための情報を生成して、上記のプッシュ通知を表示させるようにしてもよい。
　なお、図２－５右側のプロフィール画面が表示された場合であっても、上記のプッシュ通知を表示させないようにしてもよい。
　また、図２－５中央のホーム画面の友だちリストにおいて、そのリストに含まれるユーザに関連付けて安否に関する情報（第１安全アイコンＳＩＣ１または第１危険アイコンＤＩＣ１）を表示させないが、図２－５右側のプロフィール画面が表示された場合に、上記のプッシュ通知を表示させるようにしてもよい。
　また、図２－５中央のホーム画面において、ユーザＹ．Ｙに対応した友だちリストの項目がユーザによってタップされると、端末２０Ｘの制御部２１は、図２－５右側のユーザＹ．Ｙに対応したプロフィール画面を表示させるが、変更前の安否情報に対応するアイコン（この例では、危険に対応する第２危険アイコンＤＩＣ２）を表示させるようにする。そして、端末２０Ｘの制御部２１は、安否更新要求情報をサーバ１０に送信し、これに基づいて、変更後の安否情報（この例では、安全）がサーバ１０から端末２０Ｘに送信されるようにする。そして、端末２０Ｘの制御部２１が、変更前の安否情報に対応するアイコン（この例では、危険に対応する第２危険アイコンＤＩＣ２）の表示を、変更後の安否情報に対応するアイコン（この例では、安全に対応する第２安全アイコンＳＩＣ２）に変更する制御を行うようにしてもよい。
　また、限定ではなく例として、前述したトークリスト画面において、ユーザのトークルームリスト項目に対応したアイコンに重畳して表示される安否ステータス情報に基づくアイコン（第２安全アイコンＳＩＣ２または第２危険アイコンＤＩＣ２）がタップされると、そのユーザのプロフィール画面が表示されるようにしてもよい。
　限定ではなく例として、図１－１３左側の画面においてユーザＢ．Ｂのトークルームリスト項目に対応したアイコンに重畳して表示されている第２危険アイコンＤＩＣ２がタップされると、限定ではなく例として図２－５右側のプロフィール画面と同様の態様で、ユーザＢ．Ｂのプロフィール画面が表示されるようにしてもよい。この場合、ユーザＢ．Ｂのプロフィール画面には、第２危険アイコンＤＩＣ２が表示されるようにすることができる。
　また、安否登録アカウントによって安否情報が登録されると、安否参照アカウントの端末２０において、安否登録アカウントのユーザのトークルームリスト項目（限定ではなく例として、ユーザのトークルームリスト項目に対応したアイコンや安否ステータス情報に基づくアイコン）を光らせて表示させるなどしてもよい。そして、光っている項目がタップされると、そのユーザのプロフィール画面が表示されるようにしてもよい。
　また、前述したように、安否位置情報と安否コメント情報とを別の画面に表示させてもよく、限定ではなく例として、これらのうちの一方の情報をトークリスト画面に表示させ、他方の情報をプロフィール画面に表示させてもよい。
　また、複合安否情報を、上記のプロフィール画面に表示させるようにしてもよい。
　また、安否位置情報と安否コメント情報とのいずれか一方の情報を、上記のプロフィール画面に表示させるようにしてもよい。
　また、上記の例とは異なるが、安否情報を上記のプロフィール画面には表示させないようにしてもよい。一例として、安否情報を前述したホーム画面に表示させるが、上記のプロフィール画面には表示させないようにしてもよい。
　また、上記のプロフィール画面に代えて、安否情報を表示する専用の画面を表示させるなどしてもよい。
　図２－６は、本変形例において各装置が実行する処理のタイミングの一例を示すタイミングチャートである。
　ここでは、表示画面と同様に、
　・安否登録アカウント＝端末２０ＹのユーザＹ．Ｙ（限定ではなく、第１端末のユーザの一例）のアカウント
　・安否参照アカウント＝端末２０ＸのユーザＸ．Ｘ（限定ではなく、端末のユーザの一例）のアカウント
　とする場合の処理を例示する。
　限定ではなく例として、安否確認処理が実行され、端末２０Ｙにおいて、安否確認登録情報の入力を受け付ける（Ｙ２１３０）と、第１の安否確認登録情報がサーバ１０に送信される（Ｙ２１４０）（タイミング「ＴＭ２１０」）。そして、サーバ１０は第１の安否確認登録情報を受信する（Ｓ２１３０：ＹＥＳ）。
　サーバ１０の制御部１１は、第１の安否確認登録情報に基づいて、第１の安否情報を生成し、各端末２０に送信する（Ｓ２１４０）（タイミング「ＴＭ２２０」）。
　端末２０Ｘは第１の安否情報を受信すると表示処理を実行する（Ｘ２１６０）（タイミング「ＴＭ２３０」）。
　再度安否確認処理が実行され、端末２０Ｙにおいて、安否確認登録情報の入力を受け付ける（Ｙ２１３０）と、第１の安否確認登録情報がサーバ１０に送信される（Ｙ２１４０）（タイミング「ＴＭ２４０」）。そして、サーバ１０は第２の安否確認登録情報を受信する（Ｓ２１３０：ＹＥＳ）。サーバ１０の制御部１１は、第２の安否確認登録情報に基づいて、第２の安否情報を生成する。
　端末２０Ｘにおいて、限定ではなく例として、ユーザＸ．Ｘの端末２０に対するユーザ操作に基づいて、メッセージングアプリケーションにおける特定表示要素を表示させる表示処理が実行される（タイミング「ＴＭ２５０」）。
　ここで、特定表示要素としては、限定ではなく例として、以下の表示要素が挙げられる。
・安否登録アカウントのユーザのプロフィール画面
・安否登録アカウントと安否参照アカウントとの一対一トークルーム
・安否登録アカウントを含むグループトークルーム
・安否登録アカウントを含むトークリスト画面
・安否確認サービスの公式アカウントプロフィール画面
・安否確認サービスの公式アカウントと安否参照アカウントとのトークルーム
・安否確認サービスの公式アカウントを含むトークリスト画面
　なお、トークリスト画面については、過剰に安否情報が表示されることを防ぐために、特定表示要素から除外するようにしてもよい。
　すると、端末２０Ｘの制御部２１は、所定の安否登録アカウントの安否情報を要求するための安否更新要求情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する（タイミング「ＴＭ２６０」）。
　サーバ１０の制御部１１は、安否更新要求情報を受信する場合、第２の安否情報を安否参照アカウントの端末２０Ｘに送信する（Ｓ２１４０）（タイミング「ＴＭ２７０」）。
　なお、サーバ１０の制御部１１は、安否比較処理の結果、第１の安否確認登録情報と第２の安否確認登録情報とに差異が生じていない場合、第２の安否情報を端末２０Ｘに送信しないようにしてもよい。この場合、安否に変更がないことを示す情報を端末２０Ｘに送信するようにしてもよい。
　また、サーバ１０の制御部１１は、安否比較処理の結果、第１の安否確認登録情報と第２の安否確認登録情報とに差異が生じている場合、安否登録アカウントの安否状況に変化が生じたことを示す安否変化情報を端末２０Ｘに送信するようにしてもよい。
　端末２０Ｘは第２の安否情報を受信すると、表示処理を実行する（Ｘ２１６０）（タイミング「ＴＭ２８０」）。
　本タイミングチャートでは、安否登録アカウントの端末２０Ｙにおいて２回安否確認登録情報が入力される例を例示したが、３回以上安否確認登録情報が入力される場合についても同様に処理を実行することができる。
　本変形例は、安否参照アカウントのユーザの端末２０が、第１の安否情報（限定ではなく、第１情報の一例）を通信Ｉ／Ｆ２２によって受信した後、安否登録アカウントのユーザ（限定ではなく、第１端末のユーザの一例）と安否参照アカウントのユーザ（限定ではなく、端末のユーザの一例）とを含むトークルーム（限定ではなく、第１チャットルームの一例）を表示部２４に表示した場合、第２の安否情報（限定ではなく、第２情報の一例）を通信Ｉ／Ｆ２２によって受信する構成を示している。
　このような構成により得られる実施例の効果の一例として、端末が第１情報を受信した後、第１端末のユーザと端末のユーザとを含む第１チャットルームを表示することを契機として、端末が第２情報を取得できるようにすることができる。また、このようにすることで、むやみに第２情報を受信せずに済み、端末のユーザが煩わしさを感じないようにすることができる。
　また、安否参照アカウントのユーザの端末２０は、安否登録アカウントのユーザのプロフィール情報などの安否登録アカウントのユーザの情報（限定ではなく、第１端末のユーザの情報の一例）を表示部２４に表示した場合、第２の安否情報を通信Ｉ／Ｆ２２によって受信する構成としてもよい。
　このような構成により得られる実施例の効果の一例として、端末が第１端末のユーザの情報を表示することを契機として、端末が第２情報を取得できるようにすることができる。また、このようにすることで、むやみに第２情報を受信せずに済み、端末のユーザが煩わしさを感じないようにすることができる。
　また、この場合、安否登録アカウントのユーザの情報は、安否登録アカウントのユーザの安否に関連する情報（安全、危険など）を含む、安否登録アカウントのユーザのステータスに関する情報を含むようにすることができる。
　このような構成により得られる変形例の効果の一例として、端末が第１端末のユーザの安否に関連する第１情報を含む、第１端末のユーザのステータスに関する情報を表示することを契機として、端末が第２情報を取得できるようにすることができる。また、このようにすることで、むやみに第２情報を受信せずに済み、端末のユーザが煩わしさを感じないようにすることができる。
＜第２変形例（２）＞
　上記の実施例では、安否登録アカウントの端末２０において第２の安否確認登録情報が登録されると、安否参照アカウントの端末２０は自動的に第２の安否情報を受信する例を例示したが、これに限定されない。
　限定ではなく例として、安否参照アカウントと安否登録アカウントとの関係性に基づいて、第２の安否情報を受信するようにしてもよい。
　限定ではなく例として、以下のように安否参照アカウントと安否登録アカウントとの親密度を定義する。
　親密度（安否参照アカウント，安否登録アカウント）＝安否参照アカウントと安否登録アカウントとにおける１日当たりの平均メッセージ送受信回数
　この場合、限定ではなく例として、親密度が設定値（限定ではなく例として、「１０」通）以上、または設定値より大きい場合、サーバ１０の制御部１１は、第２の安否情報を安否参照アカウントの端末２０に送信するようにしてもよい。
　なお、親密度が設定値以上、または設定値より大きい場合、安否参照アカウントの端末２０は、安否更新要求情報を設定時間間隔（限定ではなく例として、「５分間」）ごとにサーバ１０に送信する。そして、サーバ１０の制御部１１は、安否更新要求情報を受信する場合、第２の安否情報を安否参照アカウントの端末２０に送信するようにしてもよい。
　本変形例は、第２の安否情報（限定ではなく、第２情報の一例）は、安否参照アカウントのユーザと安否登録アカウントのユーザとの関係に基づいて送信される構成を示している。
　このような構成により得られる実施例の効果の一例として、第１端末のユーザと、端末のユーザとの関係に基づいて適切に送信された第２情報を、端末が受信できるようにすることができる。
＜第２変形例（３）＞
　上記の実施例では、安否登録アカウントと安否参照アカウントとが異なる例について例示したが、これに限定されない。ここでは、
　・安否登録アカウント　兼　安否参照アカウント＝端末２０ＡのユーザＡ．Ａのアカウントとする場合を例示する。
　図２－７左側は、ユーザＡ．Ａの端末２０Ａのトークリスト画面の一例を示している。このトークリスト画面は、図１－１３左側の表示画面と同様であり、ユーザＡ．Ａが、自身は「安全」であることを設定したことに基づき、その旨を示すユーザ状態アイコン（ユーザＡ．Ａ、安全））を含む情報が、第２災害情報表示領域に表示されている。つまり、この例では、ユーザＡ．Ａのアカウントは、安否登録アカウントとして機能している。
　限定ではなく例として、図２－７左側のトークリスト画面において、ユーザＣ．Ｃのトークルームリスト項目がユーザによってタップされると、限定ではなく例として、図２－７中央のトークルーム画面が表示される。この画面は、図１－１３右側で示したトークルーム画面とは異なり、トークルーム名表示領域には、限定ではなく例として、ユーザＡ．ＡがユーザＣ．Ｃを相手としてトークを行うためのトークルームであることを示す文字（本例では「Ｃ．Ｃ」）が表示されている。
　また、その下のユーザ別安否情報表示領域には、限定ではなく例として、ユーザ別安否情報として、第２危険アイコンＤＩＣ２が重畳表示されたユーザＣ．Ｃのアイコンと、第２安全アイコンＳＩＣ２が重畳表示されたユーザＡ．Ａのアイコンとが表示されている。
　トーク領域には、限定ではなく例として、ユーザＣ．Ｃからのコンテンツ（限定ではなく例として「地震だ～揺れがすごい」のテキストコンテンツ、「エレベーター止まった」のテキストコンテンツ）と、ユーザＡ．Ａによって発信されたコンテンツ（限定ではなく例として「地震大丈夫？誰かと一緒にいる？」のテキストコンテンツ）とが表示されている。
　限定ではなく例として、ユーザＣ．Ｃによって安否情報が変更された場合における、ユーザＡ．Ａの端末２０Ａに表示されるトークルーム画面の一例を図２－７右側に示す。
　この例では、ユーザＣ．Ｃが安否情報を「危険」から「安全」に変更したことに基づいて、限定ではなく例として、画面上部に、メッセージングアプリケーション（サーバ１０）を発信元とする、ユーザＣ．Ｃが安否情報を変更したことを示すテキスト（Ｃ．Ｃさんのステータス（ステイタス）が変わりました）やアイコンを含むプッシュ通知ＰＮ３が表示されている。
　また、トーク領域には、限定ではなく例として、新たなユーザＣ．Ｃからのコンテンツ（限定ではなく例として「エレベーター止まった」のテキストコンテンツ、「１人だよー怖いよー　あ、エレベーター動いた！」のテキストコンテンツ、「出られた～～！」のテキストコンテンツ）が表示されている。
　また、この表示画面例では、ユーザＣ．Ｃのテキストコンテンツ「出られた～～！）の下に、ユーザＹ．Ｙが変更した安否情報をトークルーム内で通知する通知情報として、限定ではなく例として、「Ｃ．Ｃさんのステイタスが変わりました」の文字と、ユーザ状態アイコンＩＣＣＤ（ユーザＣ．Ｃ、危険）→ユーザ状態アイコンＩＣＣＳ（ユーザＣ．Ｃ、安全）とを含む第３通知情報ＮＩ３が表示されている。
　また、この第３通知情報ＮＩ３の下には、ユーザＡ．Ａによって発信されたコンテンツ（限定ではなく例として「よかったーー」のテキストコンテンツ）が表示されている。
　つまり、この例では、ユーザＡ．Ａのアカウントは、安否参照アカウントとしても機能している。
＜第３実施例＞
　第３実施例は、２以上の安否登録アカウントの端末２０間で通話を行う場合、限定ではなく例として、登録された安否ステータス情報に基づいて、接続制御を行う実施例である。
　以下では、通話を行うために発信する者である発信元のユーザアカウントを「発信元アカウント」、発信された通話を受ける者である着信先のユーザアカウントを「発信先アカウント」と称する。
　第３実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
　また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
＜表示画面＞
　本実施例における表示画面では、発信元アカウントを端末２０ＡのユーザＡ．Ａ、発信先アカウントを、端末２０ＢのユーザＢ．Ｂおよび端末２０ＣのユーザＣ．Ｃとする。また、発信元アカウントおよび発信先アカウントは、安否登録を済ませた安否登録アカウントとして例示する。
　図３－１左側は、ユーザＡ．Ａの端末２０Ａのトークルーム画面が表示されている。この画面は、図１－１３右側で示した表示画面と同様であるので説明を省略する。
　限定ではなく例として、図３－１左側のトークルーム画面において、トークルーム名表示領域の右部の通話を行うための通話ボタンＢＴ７がユーザによってタップされた場合における、ユーザＡ．Ａの端末２０Ａに表示される通話画面の一例を図３－１右側に示す。
　通話画面には、画面最上部のメッセージングアプリケーションの名称等が表示される領域の下に、限定ではなく例として、通話ステータス（通話の状態）を示す通話ステータス表示領域が設けられている。通話ステータスとしては、限定ではなく例として、ユーザＡ．ＡがユーザＢ．Ｂに発信していることを示す「発信中」、ユーザＡ．ＡがユーザＢ．Ｂと通話していることを示す「通話中」等が設けられている。
　その下には、通話相手となるユーザのメッセージングアプリケーションにおけるアイコン画像、ユーザ名、通話時間、マイクをオフにするためのマイクオフボタン（本例では、マイク型の画像と「マイクをオフ」の文字）、そのユーザを相手としたビデオ通話を行うためのビデオ通話ボタン（本例では、ビデオカメラ型の画像と「ビデオ通話を開始」の文字）、スピーカをオンにするためのスピーカオンボタン（本例では、スピーカ型の画像と「スピーカをオン」の文字）、および、通話を終了するための通話終了ボタン等が表示されている。
　本例では、通話ステータス表示領域には、「通話中」の文字が表示されており、その下には、ユーザＢ．Ｂのアイコン画像、「Ｂ．Ｂ」の文字、通話時間として「１：４７」の数字、マイクオフボタン、ビデオ通話ボタン、スピーカオンボタン、および、通話終了ボタンが表示されている。
　図３－２左側は、ユーザＡ．Ａの端末２０Ａのトークルーム画面が表示されている。この画面は、図２－７右側で示したトークルーム画面と同様であるものの、トークルーム名表示領域には、限定ではなく例として、前の画面に戻るための「＜」の戻るボタン、ユーザＡ．ＡがユーザＣ．Ｃを相手としてトークを行うためのトークルームであることを示す文字（本例では「Ｃ．Ｃ」）、および通話ボタン等が表示されている。
　限定ではなく例として、図３－２左側のトークルーム画面において、トークルーム名表示領域の右部の通話ボタンＢＴ７がユーザによってタップされると、図３－２中央のような表示がなされる。
　このトークルーム画面では、ユーザＡ．ＡとユーザＢ．Ｂの安否ステータスがともに「安全」であることに基づき、図３－２左側のトークルーム画面に重畳して、災害発生時に不要不急の通話を控えさせるための通話遠慮要請情報ＣＲＩ１が表示されている。
　この例では、通話遠慮要請情報ＣＲＩ１には、災害が発生している場合に不要不急の通話を控えるよう促す（注意喚起する）旨のメッセージ（本例では、「大規模災害発生のため不要不急の通話はお控えください」の文字、キャラクタの画像）とともに、発信をキャンセルするためのキャンセルボタン（本例では、「キャンセル」の文字が含まれたボタン）、および、通話を行うための第２通話ボタン（本例では、「どうしても発信」の文字が含まれたボタン）が表示されている。
　限定ではなく例として、図３－２中央のトークルーム画面において、第２通話ボタンがユーザによってタップされた場合における、ユーザＡ．Ａの端末２０Ａに表示される通話画面の一例を図３－２右側に示す。
　本例では、通話ステータス表示領域には、「通話中」の文字が表示されており、その下には、ユーザＣ．Ｃのアイコン画像、「Ｃ．Ｃ」の文字、通話時間として「０：１２」の数字、マイクオフボタン、ビデオ通話ボタン、スピーカオンボタン、および、通話終了ボタンが表示されている。
＜処理＞
　図３－３は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
　この図では、左側から順に、発信元アカウントの端末２０Ｘの制御部２１が実行する処理、発信先アカウントの端末２０Ｙの制御部２１が実行する処理、サーバ１０の制御部１１が実行する処理の一例を示している。
　限定ではなく例として、端末２０Ｘの制御部２１は、安否確認処理を実行すると（Ｘ２１０）、限定ではなく例として、端末２０Ｘの入出力部２３に対する入力（ユーザ操作等）に基づいて、限定ではなく例として、発信先アカウントのアプリケーションＩＤを含む通話要求情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ｘ３１０）。
　通信Ｉ／Ｆ１４によって発信元アカウントの端末２０Ｘから通話要求情報を受信したと判定する場合、サーバ１０の制御部１１は、安否ステータス判定処理を実行する（Ｓ３１０）。
　安否ステータス判定処理において、サーバ１０の制御部１１は、アカウント管理データベース１５５Ａを参照し、発信元アカウントの安否登録データにおける安否ステータス情報（以下、「発信元ステータス」と称する。）と、発信先アカウントの安否登録データにおける安否ステータス情報（「以下、「発信先ステータス」と称する。）とを取得する。
　そして、サーバ１０の制御部１１は、限定ではなく例として、発信元ステータスが「安全」かつ発信先ステータスが「安全」であるか否かを判定する。
　発信元ステータスが「安全」かつ発信先ステータスが「安全」であると判定される場合（Ｓ３１０：「安全」－「安全」）、サーバ１０の制御部１１は、通話の発信を控えることを要請するための通話遠慮要請情報を、通信Ｉ／Ｆ１４によって発信元アカウントの端末２０Ｘに送信する（Ｓ３２０）。
　発信元ステータスが「安全」かつ発信先ステータスが「安全」以外であると判定される場合（Ｓ３１０：「安全」－「安全」以外）、サーバ１０の制御部１１は、Ｓ３２０のステップをスキップさせる。
　通信Ｉ／Ｆ２２によってサーバ１０から通話遠慮要請情報を受信したと判定される場合（Ｘ３２０：ＹＥＳ）、端末２０Ｘの制御部２１は、受信した通話遠慮要請情報を表示部２４に表示させる（Ｘ３３０）。
　通話遠慮要請情報を受信しないと判定される場合（Ｘ３２０：ＮＯ）、端末２０Ｘの制御部２１は、Ｘ３３０のステップをスキップさせる。
　その後、サーバ１０の制御部１１は、通話処理を開始する（Ｓ３４０）。また、端末２０Ｘおよび端末２０Ｙの制御部２１は、通話処理を開始する（Ｘ３４０、Ｙ３４０）。
　通話処理において、端末２０Ｙの制御部２１は、限定ではなく例として、通話が着信したことを示す通話着信音を音出力部２６から着信音を音出力させる。これにより、ユーザＸ．Ｘに着信音を聞かせ、通話が要求されていることを報知させる。また、端末２０Ｙの制御部２１は、限定ではなく例として、発信元アカウントの情報（限定ではなく例として、ユーザ名）を含む着信表示を表示部２４に表示させる。
　なお、発信元アカウントの情報として、発信元ステータスを含む情報を発信先アカウントの端末２０の表示部２４に表示させるようにしてもよい。
　限定ではなく例として、端末２０Ｙの入出力部２３に対する入力に基づいて、通話が受け入れられると、端末２０Ｘの制御部２１と、端末２０Ｙの制御部２１とは、限定ではなく例として、サーバ１０を介してユーザ間の通話におけるＶｏＩＰ処理を実行する。なお、通話が受け入れられると、端末２０Ｘの制御部２１と、端末２０Ｙの制御部２１とは、ピアツーピア通信を行い、通話におけるＶｏＩＰ処理を実行するようにしてもよい。
　限定ではなく例として、端末２０Ｘまたは端末２０Ｙの入出力部２３に対する入力に基づいて、通話が終了し切断されると、サーバ１０の制御部１１は、処理を終了させる。また、端末２０Ｘおよび端末２０Ｙの制御部２１は、処理を終了させる。
　なお、通話遠慮要請情報に、通話の発信を取りやめるか否かの選択用表示を含めるようにしてもよい。この場合、発信元アカウントの端末２０Ｘに通話遠慮要請情報が表示され、限定ではなく例として、通話遠慮要請情報に対する入力に基づいて通話の発信を取りやめることが選択された場合、発信元アカウントの端末２０Ｘの制御部２１は、通話の発信を取りやめることを示す通話発信解消情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する。通信Ｉ／Ｆ１４によって発信元アカウントの端末２０Ｘから通話発信解消情報を受信したと判定される場合、サーバ１０の制御部１１は、端末２０Ｘと端末２０Ｙとの通話処理を開始しないようにしてもよい。通話遠慮要請情報に対する入力操作に基づいて通話の発信を続けることが選択された場合、サーバ１０の制御部１１は、端末２０Ｘと端末２０Ｙとの通話処理を開始するようにしてもよい。
　また、サーバ１０の制御部１１は、安否ステータス判定処理において、発信元ステータスが「安全」かつ発信先ステータスが「安全」であると判定される場合（Ｓ３１０：「安全」－「安全」）、通話を接続しないことを示す通話接続拒否情報を通信Ｉ／Ｆ１４によって発信元アカウントの端末２０Ｘに送信するようにしてもよい。端末２０Ｘの制御部２１は、通話接続拒否情報を受信すると、表示部２４に表示させるようにしてもよい。そして、サーバ１０の制御部１１は、通話処理を開始しないようにしてもよい。
　すなわち、安否ステータス判定処理において、発信元ステータスが「安全」かつ発信先ステータスが「安全」であると判定される場合には、通話は強制的に解消される。
＜第３実施例の効果＞
　本実施例は、発信元アカウントのユーザの端末２０が、発信元アカウントのユーザの安否に関する情報と、発信先アカウントのユーザの安否に関する情報とに基づいて、通話に関する処理を制御部２１によって行う構成を示している。
　このような構成により得られる実施例の効果の一例として、通話に関連するユーザの安否に関する情報に基づいて、通話に関する処理を適切に行うことができる。
　また、この場合、通話に関する処理は、発信元アカウントのユーザの安否に関する情報と、発信先アカウントのユーザの安否に関する情報とがともに「安全」であるような場合に、通話を抑制（禁止）する処理を含むようにすることができる。
　このような構成により得られる実施例の効果の一例として、発信元アカウントのユーザの安否に関する情報と、発信先アカウントのユーザの安否に関する情報とが設定された条件を満たす場合に、通話を抑制（禁止）することができる。
＜第３変形例（１）＞
　上記の実施例では、安否ステータス判定処理に基づいて、通話を抑制させるか否かを判定したが、これに限定されない。限定ではなく例として、安否ステータス判定において、発信元ステータスが「危険」であると判定される場合、サーバ１０の制御部１１は、通話の接続優先度を上げて通話処理を実行するようにしてもよい。
　発信元ステータスが「危険」である場合、発信元アカウントのユーザによる通話発信は緊急性が高いと考えられる。そのため、発信元ステータスが「危険」であると判定される場合、通話の接続優先度を上げることにより、緊急性の高い可能性が高い通話を接続し易くすることができる。
　なお、発信元ステータスが「危険」である場合、通話処理において、限定ではなく例として、発信先アカウントの端末２０Ｙにおける通話着信音をより目立つ態様の着信音として音出力させるようにしてもよい。また、発信元ステータスが「危険」である場合、通話処理において、限定ではなく例として、発信先アカウントの端末２０Ｙにおける通話表示をより目立つ態様の着信表示として表示させるようにしてもよい。
　これにより、発信元アカウントのユーザは、助けを求める等の行動を取っている可能性が高い発信元アカウントからの通話着信をより容易に区別することができる。
　なお、安否ステータス判定において、発信先ステータスが「危険」であると判定される場合、通話の接続優先度を上げるようにしてもよい。
＜第３変形例（２）＞
　上記の実施例では、サーバ１０において安否ステータス判定処理を実行することとしたが、これに限定されない。限定ではなく例として、発信元アカウントの端末２０Ｘにおいて安否ステータス判定処理を実行するようにしてもよい。
　限定ではなく例として、発信元アカウントの端末２０Ｘの制御部２１は、安否確認処理を実行すると、限定ではなく例として、端末２０Ｘの入出力部２３に対する入力（ユーザ操作等）に基づいて、通話発信先アカウントを受け付ける。すると、端末２０Ｘの制御部２１は、限定ではなく例として、発信元アカウントのアプリケーションＩＤと、発信先アカウントのアプリケーションＩＤとを含む安否情報要求情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する。
　通信Ｉ／Ｆ１４によって端末２０Ｘから安否情報要求情報を受信すると、サーバ１０の制御部１１は、アカウント管理データベース１５５Ａを参照し、発信元ステータスと、発信先ステータスとを取得する。そして、発信元ステータスと、発信先ステータスとを含む安否情報を通信Ｉ／Ｆ１４によって端末２０Ｘに送信する。
　通信Ｉ／Ｆ２２によってサーバ１０から安否情報を受信すると、端末２０Ｘの制御部２１は、受信した安否情報に基づいて、安否ステータス判定処理を実行する。そして、発信元ステータスが「安全」かつ発信先ステータスが「安全」であると判定される場合、端末２０Ｘの制御部２１は、通話遠慮要請情報を表示部２４に表示させる。
　なお、端末２０Ｘが通話開始に先立ち安否情報として発信先ステータスを取得している場合、端末２０Ｘの制御部２１は、安否情報要求情報をサーバ１０に送信せず、記憶部２８に記憶される発信元ステータスと発信先ステータスとに基づいて安否ステータス判定処理を実行するようにしてもよい。
＜第４実施例＞
　第４実施例は、安否登録アカウントの端末２０において安否確認登録情報が登録されると、その後の安否登録アカウントに対して送信されるメッセージに対して自動的に応答を行う実施例である。
　第４実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
　また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
＜表示画面＞
　図４－１左側は、ユーザＡ．Ａの端末２０Ａのホーム画面が表示されている。この画面は、図１－１２中央のホーム画面と異なり、安否メッセージ入力領域には、ユーザによって入力された安否メッセージ（本例では、「自転車で移動中です」）が表示されている。また、その下の現在地入力領域には、ユーザによって入力された現在の居場所（本例では「三鷹市」）が表示されている。
　限定ではなく例として、図４－１左側の安否登録領域Ｒ１において、登録ボタンＢＴ３がユーザＡ．Ａによってタップされると図４－１中央の安否登録領域Ｒ１に表示が遷移する。
　この場合、安否登録領域Ｒ１では、安全ボタンＳＢＴ、危険ボタンＤＢＴ、安否メッセージ入力領域、現在地入力領域等の表示が消去され、設定された安否情報を確認するための安否情報確認領域が構成されている。安否情報確認領域には、限定ではなく例として、「以下の内容で登録しました」の文字、「安否メッセージ」の文字、ユーザ状態アイコンＩＣＡＳ（ユーザＡ．Ａ、安全）、「三鷹／自転車で移動中です」の文字が表示されている。
　また、その下には、自動応答モードに設定するための自動応答設定領域が構成されている。自動応答設定領域には、限定ではなく例として、「自動応答モードに切り替えますか？」の文字と、自動応答モードに設定する（モードを自動応答モードに切り替える）ための「はい」ボタンＢＴ１１と、自動応答モードに設定しないための「いいえ」ボタンＢＴ１２（本例では、「いいえ」の文字で示されるボタン）とが表示されている。
　限定ではなく例として、図４－１中央の安否登録領域Ｒ１において、「はい」ボタンＢＴ１１がユーザＡ．Ａによってタップされたとする。この場合、図４－１右側に示すような画面が表示される。
　図４－１右側は、ユーザＡ．Ａの端末２０Ａの表示部２４に表示されるトークリスト画面の一例を示している。この画面は、図１－１３左側のトークリスト画面とは異なり、自動応答モードの設定を行っている場合に、トークルームリスト項目に、自動応答モードに設定された後に他のユーザからメッセージが送信された（自動応答で返信された）トークルームであることを示す自動応答済み情報が表示されている。
　本例では、自動応答モードの設定を行っている場合に、自動応答モードに設定された後に他のユーザからメッセージが送信されたトークルームのトークルームリスト項目のうち最も古い時間にメッセージが送信されたトークルーム（ユーザＢ．Ｂのトークルーム）に対応したトークルームリスト項目から、最も新しい時間にメッセージが送信されたトークルーム（テニスサークルのグループトークルーム）に対応したトークルームリスト項目に亘って、自動応答済み情報（本例では、「自動応答済み」の文字が示されたテロップ）が重畳表示されている。
　図４－２左側は、ユーザＤ．Ｄの端末２０Ｄのトークルーム画面が表示されている。この画面は、図１－１３右側で示したトークルーム画面とは異なり、トークルーム名表示領域には、限定ではなく例として、ユーザＤ．ＤがユーザＡ．Ａを相手としてトークを行うためのトークルームであることを示す文字（本例では「Ａ．Ａ」）が表示されている。
　また、その下のユーザ別安否情報表示領域には、限定ではなく例として、ユーザ別安否情報として、第２安全アイコンＳＩＣ２が重畳表示されたユーザＡ．Ａのアイコンと、第２安全アイコンＳＩＣ２が重畳表示されたユーザＤ．Ｄのアイコンとが表示されている。
　トーク領域には、限定ではなく例として、ユーザＡ．Ａからのコンテンツ（限定ではなく例として、「じゃあ、おやすみ～」のテキストコンテンツ）と、ユーザＤ．Ｄによって発信されたコンテンツ（限定ではなく例として、「また明日～」のテキストコンテンツ、「揺れてる～地震？」のテキストコンテンツ、「大丈夫？もう家出た？」のテキストコンテンツ）とが表示されている。
　また、その下には、ＯＡアカウント（本例では、安否確認応答サービス）を発信元とする自動応答確認情報ＡＲＩ（限定ではなく例として、「こちらは安否確認サービスです　２０ＸＸ／０８／０４　９：３９発生の災害においてＡ．Ａさんの無事が確認されています　現在、電池節約等のため自動応答に設定されています」の文字を含む情報）が表示されている。
　ここで、「未読」に相対する用語として「既読」を定義することができる。
　メッセージ（コンテンツ）が既読となる条件（以下、「既読条件」と称する。）としては、限定ではなく例として、以下のいずれかの条件を適用することができる。
（Ａ）メッセージが表示されたこと。
（Ｂ）メッセージが表示されてから一定時間（限定ではなく、数秒～１０秒程度の時間）が経過したこと。
（Ｃ）メッセージが表示された後、表示されたメッセージがタップ（クリック）されたこと。
（Ｄ）メッセージが表示された後、そのメッセージに対して返信がされたこと。
（Ｅ）メッセージが動画像のメッセージである場合に、その動画像が再生されたこと。
（Ｆ）メッセージが動画像のメッセージである場合に、その動画像を再生してから一定時間（限定ではなく、数秒～１０秒程度の時間）が経過したこと。
　この場合、「未読」の状態は、限定ではなく例として、上記の既読条件を満たしていない状態と定義することができる。
　「未読」の状態は、ユーザがメッセージ（コンテンツ）を未閲覧の状態であることの一種である。
　本例では、ユーザＤ．Ｄによって発信されたコンテンツのうち、限定ではなく例として「また明日～」のテキストコンテンツが既読状態となっていることに基づいて、このテキストコンテンツの吹き出しの左下方に「既読」の文字が表示されており、「揺れてる～　地震？」のテキストコンテンツおよび「大丈夫？もう家出た？」のテキストコンテンツが未読状態となっていることに基づいて、これらのテキストコンテンツの吹き出しの左下方に「既読」の文字が表示されていない。
　限定ではなく例として、ユーザＡ．Ａによって自動応答モードに設定された場合における、ユーザＡ．Ａの端末２０Ａに表示されるトークルーム画面の一例を図４－２右側に示す。
　この画面は、図４－２左側で示したトークルーム画面とは異なり、トークルーム名表示領域には、限定ではなく例として、ユーザＡ．ＡがユーザＤ．Ｄを相手としてトークを行うためのトークルームであることを示す文字（本例では「Ｄ．Ｄ」）が表示されている。
　トーク領域には、限定ではなく例として、ユーザＡ．Ａによって発信されたコンテンツ（限定ではなく例として、「じゃあ、おやすみ～」のテキストコンテンツ、「返信遅くなってごめん　Ｂ．Ｂさんが足ケガしたみたいでヘルプしてた；」のテキストコンテンツ）と、ユーザＤ．Ｄからのコンテンツ（限定ではなく例として、「また明日～」のテキストコンテンツ、「揺れてる～地震？」のテキストコンテンツ、「大丈夫？もう家出た？」のテキストコンテンツ）とが表示されている。
　また、ユーザＤ．Ｄからのコンテンツのうち、限定ではなく例として、「揺れてる～　地震？」のテキストコンテンツが送信された後であって、「大丈夫？もう家出た？」のテキストコンテンツが送信されるよりも前のタイミングで、ユーザＡ．Ａによって自動応答モードに設定されたことに基づいて、これらのテキストコンテンツの間に「自動応答モードを設定しました」の文字を含む自動応答設定情報ＡＲＳＩが表示されている。
　また、ユーザＤ．Ｄからのコンテンツのうち、限定ではなく例として、「大丈夫？もう家出た？」のテキストコンテンツが送信された後のタイミングであって、ユーザＡ．Ａからのコンテンツのうち、限定ではなく例として、「返信遅くなってごめん　Ｂ．Ｂさんが足ケガしたみたいでヘルプしてた；」のテキストコンテンツが送信されるよりも前のタイミングで、ユーザＡ．Ａによって自動応答モードが解除されたことに基づいて、これらのテキストコンテンツの間に「自動応答モードを解除しました」の文字が示された自動応答解除情報ＡＲＲＩが表示されている。
＜処理＞
　本実施例において各装置が実行する処理については、限定ではなく例として、図２－２～図２－３に従って実行することができる。
　図４－３は、本実施例において各装置が実行する処理のタイミングの一例を示すタイミングチャートである。
　ここでは、
　・自動応答を行う安否登録アカウント＝端末２０ＸのユーザＸ．Ｘ（限定ではなく、端末のユーザの一例）のアカウント
　・自動応答を行った安否登録アカウントにメッセージ送信を行うアカウント＝端末２０ＹのユーザＹ．Ｙ（限定ではなく、第１端末のユーザの一例）のアカウント
　とする場合の処理を例示する。
　限定ではなく例として、安否確認処理が実行され、端末２０Ｙにおいて、安否確認登録情報の入力操作を受け付ける（Ｙ２１３０）と、第１の安否確認登録情報がサーバ１０に送信される（Ｙ２１４０）（タイミング「ＴＭ３１０」）。そして、サーバ１０は第１の安否確認登録情報を受信する（Ｓ２１３０：ＹＥＳ）。
　サーバ１０の制御部１１は、第１の安否確認登録情報に基づいて、第１の安否情報を生成し、各端末２０に送信する（Ｓ２１４０）（タイミング「ＴＭ３１５」）。
　端末２０Ｘは第１の安否情報を受信すると表示処理を実行する（Ｘ２１６０）（タイミング「ＴＭ３２０」）。
　端末２０Ｘにおいて、安否確認登録情報の入力操作を受け付ける（Ｘ２１３０）と、第２の安否確認登録情報がサーバ１０に送信される（Ｘ２１４０）（タイミング「ＴＭ３２５」）。そして、サーバ１０は第２の安否確認登録情報を受信する（Ｓ２１３０：ＹＥＳ）。
　サーバ１０の制御部１１は、第２の安否確認登録情報に基づいて、第２の安否情報を生成し、各端末２０に送信する（Ｓ２１４０）（タイミング「ＴＭ３３０」）。
　端末２０Ｙは第２の安否情報を受信すると表示処理を実行する（Ｙ２１６０）（タイミング「ＴＭ３３５」）。
　端末２０Ｘの制御部２１は、自動応答を開始するか否かの判定用表示を表示部２４に表示させる（タイミング「ＴＭ３４０」）。
　限定ではなく例として、端末２０Ｘに表示された判定用表示に対する入力操作に基づいて、自動応答を開始することが選択された場合、端末２０Ｘの制御部２１は、自動応答を開始させることを要請するための自動応答開始要請情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する（タイミング「ＴＭ３４５」）。
　通信Ｉ／Ｆ１４によって端末２０Ｘから自動応答開始要請情報を受信したと判定される場合、サーバ１０の制御部１１は、自動応答開始要請情報を送信した端末２０に対するメッセージ自動応答処理を開始する（タイミング「ＴＭ３５０」）。
　チャット処理において、限定ではなく例として、端末２０Ｙに対する入力操作に基づいて、端末２０ＸのユーザＸ．Ｘに対するメッセージが入力されると、端末２０Ｙの制御部２１は、限定ではなく例として、入力されたメッセージと、メッセージ送信元である端末２０ＹのアプリケーションＩＤと、メッセージ送信先である端末２０ＸのアプリケーションＩＤとを含むメッセージ送信依頼情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（タイミング「ＴＭ３５５」）。
　通信Ｉ／Ｆ１４によって端末２０Ｙからメッセージ送信依頼情報を受信すると、サーバ１０の制御部１１は、メッセージ送信依頼情報に基づいて、メッセージ送信先のアカウントに対する自動応答処理が実行されているか否かを判定する。この例では、端末２０Ｘに対するメッセージ自動応答処理はタイミング「ＴＭ３５０」～「ＴＭ３７５」の間である場合に実行されている。
　従って、メッセージ送信依頼情報を受信したタイミングがタイミング「ＴＭ３５０」よりも後であり、かつ、タイミング「ＴＭ３７５」よりも前であると判定される場合、サーバ１０の制御部１１は、メッセージ自動応答情報を通信Ｉ／Ｆ１４によって端末２０Ｙに送信する（タイミング「ＴＭ３６０」）。
　通信Ｉ／Ｆ２２によってサーバ１０からメッセージ自動応答情報を受信すると、端末２０Ｙの制御部２１は、受信したメッセージ自動応答情報を表示部２４に表示させる（タイミング「ＴＭ３６５」）。
　限定ではなく例として、端末２０Ｘに対する入力操作に基づいて、自動応答を終了させることが選択された場合、端末２０Ｘの制御部２１は、自動応答を終了させることを要請するための自動応答終了要請情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する（タイミング「ＴＭ３７０」）。
　通信Ｉ／Ｆ１４によって端末２０Ｘから自動応答終了要請情報を受信すると、サーバ１０の制御部１１は、端末２０Ｘに対するメッセージ自動応答処理を終了する（タイミング「ＴＭ３７５」）。
　そして、サーバ１０の制御部１１は、メッセージ自動応答処理期間内（この場合、タイミング「ＴＭ３５０」～「ＴＭ３７５」の間）に端末２０Ｘに対して送信されたメッセージを含むメッセージ自動応答対応履歴情報を通信Ｉ／Ｆ１４によって端末２０Ｘに送信する（タイミング「ＴＭ３８０」）。
　通信Ｉ／Ｆ２２によってサーバ１０からメッセージ自動応答対応履歴情報を受信すると、端末２０Ｘの制御部２１は、受信したメッセージ自動応答対応履歴情報を表示部２４に表示させる（タイミング「ＴＭ３８５」）。
　なお、本タイミングチャートでは、サーバ１０はメッセージ自動応答処理期間内に端末２０Ｘに対するメッセージ送信依頼情報を１回受信する例を例示したが、２回以上メッセージ送信依頼情報を受信する場合についても同様に処理を実行することができる。また、サーバ１０が、メッセージ自動応答処理期間内に複数の端末２０から端末２０Ｘに対するメッセージ送信依頼情報を受信する場合においても同様である。
　なお、サーバ１０の制御部１１は、メッセージ自動応答処理期間内（この場合、タイミング「ＴＭ３５０」～「ＴＭ３７５」の間）に再度端末２０Ｙからメッセージ送信依頼情報を受信する場合、メッセージ自動応答情報を端末２０Ｙに送信しないようにしてもよい。
　また、サーバ１０の制御部１１は、メッセージ自動応答処理期間内に端末２０Ｘのアカウントが含まれるグループトークルームに対するメッセージ送信依頼情報を受信する場合、メッセージ自動応答情報をグループに属するメンバーの各端末２０に送信しないようにしてもよい。
　また、端末２０Ｘにおいて、タイミング「ＴＭ３２０」やタイミング「ＴＭ３２５」に先んじて、自動応答を開始するか否かの判定用表示を表示部２４に表示させ、自動応答開始要請情報をサーバ１０に送信するようにしてもよい。
＜第４実施例の効果＞
　本実施例は、端末２０が、自己の端末２０のユーザによる自己の端末２０に対する入力に基づいて、自己の端末２０のユーザの安否に関する安否情報（または安否確認登録情報）（限定ではなく、端末のユーザの安否に関する第３情報の一例）を通信Ｉ／Ｆ２２によって送信する構成を示している。
　このような構成により得られる実施例の効果の一例として、端末のユーザによる端末に対する入力に基づいて、端末のユーザの安否に関する第３情報を送信して、端末のユーザの安否を他者に知らせることができる。
　また、この場合、端末２０は、上記の安否情報の送信に基づいて、トーク（限定ではなく、チャットの一例）の自動応答を開始するか否かの判定用の情報（限定ではなく、チャットの自動応答に関する情報の一例）を表示部２４に表示する。そして、端末２０は、この判定用の情報に対する、自己の端末２０のユーザによる入力に基づいて、自動応答を開始させることを要請するための自動応答開始要請情報を送信する処理や、自動応答を開始したことに関する情報を表示する処理といった、トーク（チャット）の自動応答に関する処理を制御部２１によって行うようにすることができる。
　このような構成により得られる実施例の効果の一例として、上記の第３情報の送信に基づいてチャットの自動応答に関する情報を表示部に表示して、チャットの自動応答が可能であることを端末のユーザに知らせることができる。また、表示した自動応答に関する情報に対する端末のユーザによる入力に基づいて、チャットの自動応答に関連する処理が適切に行われるようにすることができる。
＜第４変形例（１）＞
　上記の実施例では、自動応答を開始する端末２０Ｘに対する入力操作に基づいて、自動応答開始要請情報が送信される例を例示したが、これに限定されない。
　限定ではなく例として、端末２０Ｘのバッテリー残量が設定値（限定ではなく例として、「２０％」）以下である場合、端末２０Ｘの制御部２１は、サーバ１０に自動応答開始要請情報を自動的に送信するようにしてもよい。
　また、端末２０Ｘの制御部２１は、限定ではなく例として、サーバ１０から災害情報を受信すると、サーバ１０に自動応答開始要請情報を自動的に送信するようにしてもよい。
　また、端末２０Ｘの制御部２１は、限定ではなく例として、サーバ１０から災害情報を受信すると、限定ではなく例として、位置算出用情報検出部２９Ｂを介して現在位置を取得する。そして、端末２０Ｘの制御部２１は、現在位置が災害情報に含まれる災害発生場所と近しい（限定ではなく例として、最大震度の観測地点から１０ｋｍ以内）と判定される場合、サーバ１０に自動応答開始要請情報を自動的に送信するようにしてもよい。
　また、端末２０Ｘの通信状態が不良である場合（限定ではなく例として、電波強度が設定値以下である場合）、端末２０Ｘの制御部２１は、サーバ１０に自動応答開始要請情報を自動的に送信するようにしてもよい。
　また、端末２０Ｘで実行されるアプリケーションの使用の状態（状況）（限定ではなく例として、バックグラウンドで使用中）や、位置算出用情報検出部２９Ｂによる位置算出の状態（状況）（限定ではなく例として、いわゆる屋内環境（インドア環境）などの測位用衛星の捕捉が困難な状態、測位用衛星から衛星信号を受信する場合の信号強度が設定値以下である状態等）に基づいて、端末２０Ｘの制御部２１は、サーバ１０に自動応答開始要請情報を自動的に送信するようにしてもよい。
　本変形例は、端末２０が、自己の端末２０のバッテリー残量などの自己の端末２０の状態に基づいて、トーク（限定ではなく、チャットの一例）の自動応答を開始するか否かの判定用の情報（限定ではなく、チャットの自動応答に関する情報の一例）を表示部２４に表示する。そして、端末２０は、この判定用の情報に対する、自己の端末２０のユーザによる入力に基づいて、自動応答を開始させることを要請するための自動応答開始要請情報を送信する処理や、自動応答を開始したことに関する情報を表示する処理といった、トーク（チャット）の自動応答に関する処理を制御部２１によって行う構成を示している。
　このような構成により得られる実施例の効果の一例として、端末の状態に基づいてチャットの自動応答に関する情報を表示部に表示して、チャットの自動応答が可能であることを端末のユーザに知らせることができる。また、表示した自動応答に関する情報に対する端末のユーザによる入力に基づいて、チャットの自動応答に関連する処理が適切に行われるようにすることができる。
＜第４変形例（２）＞
　上記の実施例では、自動応答を開始する端末２０Ｘに対する入力に基づいて、自動応答を終了させることとしたが、これに限定されない。
　限定ではなく例として、サーバ１０の制御部１１は、メッセージ自動応答処理期間内に端末２０Ｘに対するメッセージ送信依頼情報をＮ回（「Ｎ」は所定の自然数）受信した場合、メッセージ自動応答処理を終了させ、端末２０Ｘにメッセージ自動応答応対履歴情報を送信するようにしてもよい。
　なお、限定ではなく例として、サーバ１０の制御部１１は、メッセージ自動応答処理期間内に端末２０Ｘに対するメッセージ送信依頼情報をＮ回（「Ｎ」は所定の自然数）受信した場合、端末２０Ｘにメッセージ自動応答処理を終了させることを示唆するための自動応答終了示唆情報を送信するようにしてもよい。
　この場合、端末２０Ｘの制御部２１は、自動応答終了示唆情報を受信すると、受信した自動応答終了示唆情報を表示部２４に表示させる。そして、限定ではなく例として、端末２０Ｘの制御部２１は、表示された自動応答終了示唆情報に対する入力操作に基づいて、自動応答を終了させることが選択された場合、自動応答終了要請情報をサーバ１０に送信するようにしてもよい。
　図４－４左側は、ユーザＡ．Ａの端末２０Ａの表示部２４Ａに表示されるトークリスト画面の一例を示している。
　この画面は、図４－１右側のトークリスト画面とは異なり、限定ではなく例として、トークルームリスト項目として、テニスサークルのトークルームリスト項目の上に、ユーザＦ．Ｆのトークルームリスト項目が表示されている。また、ユーザＦ．Ｆのトークルームリスト項目に関連付けて未読数「４」の数字が表示されている。また、ユーザＦ．Ｆが安否情報として「安全」を設定していることに基づいて、ユーザＦ．Ｆのトークルームリスト項目に対応したアイコンには、第２安全アイコンＳＩＣ２が重畳表示されている。
　本例では、自動応答モードの設定を行っていることに基づいて、自動応答モードに設定された後に他のユーザからメッセージが送信されたトークルームのトークルームリスト項目のうち最も古い時間にメッセージが送信されたトークルーム（ユーザＢ．Ｂのトークルーム）に対応したトークルームリスト項目から、最も新しい時間にメッセージが送信されたトークルーム（ユーザＦ．Ｆのトークルーム）に対応したトークルームリスト項目に亘って、自動応答済み情報（本例では、「自動応答済み」の文字が示されたテロップ）が重畳表示されている。
　この例では、ユーザＡ．Ａが自動応答モードに設定してから設定数（１０件）のメッセージを受信したことに基づいて、限定ではなく例として、画面上部に、メッセージングアプリケーション（サーバ１０）を発信元とする、ユーザＡ．Ａが自動応答モードに設定してから設定数（限定ではなく例として１０件）のメッセージを受信したことを示すテキスト（自動応答中にメッセージが１０件届きました　自動応答を続けますか？）を含むプッシュ通知ＰＮ５が表示されている。
　限定ではなく例として、図４－４左側の表示画面において、プッシュ通知ＰＮ５がユーザＡ．Ａによってタップされると、限定ではなく例として、図４－４右側のような表示がなされる。
　この表示画面では、図４－４左側のトークリスト画面に重畳して、安否登録領域Ｒ１がせり上がり表示されるように構成されている。
　この場合、安否登録領域Ｒ１では、設定された安否情報を確認するための安否情報確認領域が構成されている。安否情報確認領域には、限定ではなく例として、「以下の内容で登録しています」の文字、「安否メッセージ」の文字、ユーザ状態アイコンＩＣＡＳ（ユーザＡ．Ａ、安全）、「三鷹／自転車で移動中です」の文字が表示されている。
　また、その下には、自動応答モードを解除するための自動応答解除領域が構成されている。自動応答解除領域には、限定ではなく例として、「自動応答モードを解除しますか？」の文字と、自動応答モードを解除するための「はい」ボタンＢＴ１３（本例では、「はい」の文字で示されるボタン）と、自動応答モードを解除しないための「いいえ」ボタンＢＴ１４（本例では、「いいえ」の文字で示されるボタン）とが表示されている。
＜第４変形例（３）＞
　上記の実施例では、メッセージ自動応答処理をサーバ１０において実行することとしたが、これに限定されない。限定ではなく例として、自動応答を開始することが選択された端末２０Ｘにおいてメッセージ自動応答処理を実行するようにしてもよい。
　図４－５は、本変形例において各装置が実行する処理のタイミングの一例を示すタイミングチャートである。
　限定ではなく例として、端末２０Ｘに表示された判定用表示に対する入力操作に基づいて、自動応答を開始することが選択された場合、端末２０Ｘの制御部２１は、メッセージ自動応答処理を開始する（タイミング「ＴＭ４１０」）。
　通信Ｉ／Ｆ１４によって端末２０Ｙからメッセージ送信依頼情報を受信すると、サーバ１０の制御部１１は、メッセージ送信依頼情報に基づいて、端末２０Ｘにメッセージ情報を送信する（タイミング「ＴＭ４２０」）。
　通信Ｉ／Ｆ２２によってサーバ１０からメッセージ情報を受信すると、端末２０Ｘの制御部２１は、自動応答処理が実行されているか否かを判定する。この例では、端末２０Ｘにおけるメッセージ自動応答処理はタイミング「ＴＭ４１０」～「ＴＭ４４０」の間である場合に実行されている。
　従って、メッセージ情報を受信したタイミングがタイミング「ＴＭ４１０」よりも後であり、かつ、タイミング「ＴＭ４４０」よりも前であると判定される場合、端末２０Ｘの制御部２１は、メッセージ自動応答情報を通信Ｉ／Ｆ２２によって端末２０Ｙに送信する（タイミング「ＴＭ４３０」）。なお、端末２０Ｘの制御部２１は、メッセージ自動応答情報を、サーバ１０を介して端末２０Ｙに送信するようにしてもよい。
　また、端末２０Ｘの制御部２１は、受信したメッセージ情報を表示部２４に表示させない。
　限定ではなく例として、端末２０Ｘに対する入力操作に基づいて、自動応答を終了させることが選択された場合、端末２０Ｘの制御部２１は、自動応答処理を終了させる。そして、メッセージ自動応答処理期間中に受信したメッセージ情報に基づいて、メッセージ自動応答応対履歴情報を生成する（タイミング「ＴＭ４４０」）。
　端末２０Ｘの制御部２１は、生成したメッセージ自動応答対応履歴情報を表示部２４に表示させる（タイミング「ＴＭ４５０」）。
＜第５実施例＞
　第５実施例は、限定ではなく例として、大規模災害等の災害が発生した場合、一の端末２０（以下、適宜「端末」と称する。）による安否確認登録（限定ではなく例として、安否確認情報の入力と送信）を、他の端末２０（以下、適宜「第１端末」と称する。）のユーザが要求する場合、設定条件に基づいて、端末に対する安否確認登録の要求を行う実施例である。
　以下では、前述したように、安否確認アプリケーションによる安否確認サービスを提供する事業者のことを「安否確認サービス事業者」と称する。
　なお、安否確認サービス事業者は、安否確認アプリケーションを提供する事業者や、サーバ１０の事業者と表現することもできる。
　また、安否確認サービスを提供する事業者という意味で、安否確認サービスの事業者と表現することもできる。
　また、以下では、安否確認アプリケーションの名称を、適宜「Ｓａｆｅｔｙ　Ｃｏｎｆｉｒｍａｔｉｏｎ　Ａｐｐ」と称して図示・説明する。
　安否確認アプリケーションでは、限定ではなく例として、安否確認対象としてサーバ１０に登録しているアカウント同士で、安否確認登録の要求を行うことができるように構成することができる。また、限定ではなく例として、安否確認対象としてサーバ１０に登録している一のアカウントが安否確認登録を行うと、他のアカウントは登録された安否確認情報を参照することができる。
　以下では、安否確認登録を要求されるユーザアカウントを「被安否登録要求アカウント」、被安否登録要求アカウントに対して安否確認登録を要求するユーザアカウントを「安否登録要求アカウント」と称する。なお、一般に、一のユーザアカウントは安否登録要求アカウントと被安否登録要求アカウントとを兼ねることができる。
　なお、安否確認登録の方法は、安否確認アプリケーションや前述のメッセージングアプリケーションを用いて安否確認情報を入力し登録する方法に限定されない。限定ではなく例として、安否確認アプリケーションやメッセージングアプリケーションを用いずに、電話やＦＡＸ等の手段により安否確認情報を伝達する方法や、メッセージングアプリケーションにおけるメッセージとして安否確認情報を伝達する方法を用いるようにしてもよい。
　第５実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
　また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
＜表示画面＞
　図５－１左側は、安否確認アプリケーションのメインメニュー画面であり、画面最上部中央には、安否確認アプリケーションの名称として「Ｓａｆｅｔｙ　Ｃｏｎｆｉｒｍａｔｉｏｎ　Ａｐｐ」の文字が表示されている。また、画面最上部の右部には、この端末２０Ｙのユーザのメッセージングアプリケーションにおけるアイコン画像およびユーザ名（この例では「ユーザＹ．Ｙ」）が表示されている。
　また、その下には、安否確認アプリケーションにおけるアプリ内位置表示領域が構成されており、この例では、メインメニュー画面であることに基づいて、「メインメニュー」の文字が表示されている。
　アプリ内位置表示領域の下には、災害が発生したことを報知するための災害情報を示す領域である災害情報表示領域が構成されており、この例では、地震が発生したことに基づいて、災害情報が表示されている。また、災害情報表示領域の内部の右下には、ユーザＹ．Ｙが安否情報として「安全」を設定していることに基づいて、「自分のステイタス」の文字と、ユーザ状態アイコン（ユーザＡ．Ａ、安全）とが表示されている。
　災害情報表示領域の下には、安否確認アプリケーションにおいてユーザＹ．Ｙと関連付けられているユーザ（以下、「メンバー」として図示・説明する。）のリストが表示されるメンバーリスト表示領域が構成されている。
　限定ではなく例として、ある組織で安否確認アプリケーション（安否確認サービス）を利用するような場合、限定ではなく例として、その組織の代表者等のユーザが、サーバ１０に対してメンバーを登録するようにすることができる。このようにすることで、その組織に属する人が、安否確認アプリケーションにおいてメンバーとして関連付けられるようにすることができる。
　なお、組織ではなく個人でメンバーを設定するようにすることも可能である。
　この場合は、前述したメッセージングアプリケーションにおいて友だちを登録するのと同様に、限定ではなく例として、電話番号やアプリケーションＩＤ等を利用して、個人個人の端末２０のユーザがメンバーを登録するようにすることができる。
　この例では、メンバーリスト表示領域には、この端末２０Ｙのアカウント（この例では「ユーザＹ．Ｙ」）と関連付けられたメンバーを一覧表示させるためのメンバーリストが表示されるように構成されている。
　メンバーリストがユーザＹ．Ｙによってタップされると、それらのリストが展開され表示される。具体的には、限定ではなく例として、メンバーのアイコンと、ユーザ名とが、メンバーリストの項目として一覧表示される。この例では、限定ではなく例として、メンバーリストがタップされて展開された状態で表示されている。
　この画面では、メンバーリストの項目として、ユーザＸ．Ｘに対応したアイコンおよびユーザ名、ユーザＣ．Ｃに対応したアイコンおよびユーザ名、ユーザＤ．Ｄに対応したアイコンおよびユーザ名等が一覧表示されている。
　また、ユーザＸ．Ｘが安否情報を設定していないことに基づいて、ユーザＸ．Ｘに対応したアイコンには、第２不明アイコンＵＩＣ２（本例では、「不明」の文字が示されているアイコン）が重畳表示されている。ユーザＣ．Ｃが安否情報を「安全」に設定していることに基づいて、ユーザＣ．Ｃに対応したアイコンには、第２安全アイコンＳＩＣ２が重畳表示されている。ユーザＤ．Ｄが安否情報を「危険」に設定していることに基づいて、ユーザＤ．Ｄに対応したアイコンには、第２危険アイコンＤＩＣ２が重畳表示されている。
　限定ではなく例として、図５－１左側のメインメニュー画面において、ユーザＸ．Ｘに対応したメンバーリストの項目がユーザによってタップされると、限定ではなく例として、図５－１右側のメンバー画面に表示が遷移する。
　メンバー画面は、限定ではなく例として、選択されたユーザの安否状況に関する情報を表示する画面とすることができる。そして、このメンバー画面には、限定ではなく例として、各々のメンバーの安否確認アプリケーションにおけるアイコン画像、ユーザ名、安否に関する情報（本例では、「安否状況」の文字、第２不明アイコンＵＩＣ２）、そのユーザに安否情報を登録するように促すための安否登録リクエストボタンＢＴ２ａ等を表示させるようにすることができる。
　限定ではなく例として、図５－１右側のメンバー画面において、ユーザＸ．Ｘを相手とする安否登録リクエストボタンＢＴ２ａがユーザＹ．Ｙによってタップされると、限定ではなく例として、図５－２左側に示す安否登録リクエスト確認情報ＳＲＩ１がメンバー画面に重畳表示される。
　安否登録リクエスト確認情報ＳＲＩ１には、限定ではなく例として、安否確認アプリケーションのアイコン画像に関連した画像と、「Ｘ．Ｘに安否登録のリクエストを行いました」の文字と、安否登録のリクエストが行われたことを確認し、安否登録リクエスト確認情報ＳＲＩ１の表示を終了するための「ＯＫ」の文字を含むアイコンで示されるＯＫボタンとが含まれる。
　ＯＫボタンがタップされ、ユーザＹ．ＹによってユーザＸ．Ｘを相手とする安否登録リクエストが行われたとする。
　この場合、ユーザＸ．Ｘの端末２０Ｘには、限定ではなく例として、図５－２右側に示すような画面が表示される。
　図５－２右側は、端末２０Ｘの表示部２４Ｘに表示されるメインメニュー画面に重畳して、安否情報を設定するようにリクエストされていることを報知するための安否登録リクエスト確認領域Ｒ２がせり上がり表示されている。
　このメインメニュー画面は、図５－１左側で示したメインメニュー画面とは異なり、画面最上部の右部には、この端末２０Ｘのユーザの安否確認アプリケーションにおけるアイコン画像およびユーザ名（この例では「ユーザＸ．Ｘ」）が表示されている。
　また、災害情報表示領域の内部の右下には、ユーザＸ．Ｘが安否情報を設定していないことに基づいて、「自分のステイタスを登録」の文字と、前述した安否登録ボタンＢＴ１と同様の安否登録ボタンＢＴ２とが表示されている。
　また、メンバーリストの項目として、ユーザＹ．Ｙに対応したアイコンおよびユーザ名等が一覧表示されている。
　また、ユーザＹ．Ｙが安否情報を「安全」に設定していることに基づいて、ユーザＹ．Ｙに対応したアイコンには、第２安全アイコンＳＩＣ２が重畳表示されている。
　安否登録リクエスト確認領域Ｒ２には、安否情報を設定していないユーザＸ．Ｘに対してユーザＹ．Ｙから安否情報を設定するように促されている旨のメッセージ（本例では、「安否登録リクエスト」の文字と、「Ｙ．Ｙから安否登録を求められています」の文字、ユーザＹ．Ｙのアイコン→ユーザＸ．Ｘのアイコン）が表示されている。その下には、安否情報を設定するための回答ボタンＢＴ４ａが表示されている。
　図５－３左側は、ユーザＹ．Ｙの端末２０Ｙの表示部２４Ｙにおいて、ユーザＹ．ＹによってユーザＸ．Ｘを相手とする２回目の安否登録リクエストを行ったことに基づいて、安否確認アプリケーションのメンバー画面に安否登録リクエスト確認領域が表示されている。この表示画面は、図５－２左側の表示画面と同様であるので説明を省略する。
　限定ではなく例として、ユーザＹ．ＹによってユーザＸ．Ｘを相手とする２回目の安否登録リクエスト（安否登録リマインドと捉えてもよい。）が行われたとする。
　この場合、ユーザＸ．Ｘの端末２０Ｘには、限定ではなく例として、図５－３右側に示すような画面が表示される。
　図５－３右側は、端末２０Ｘの表示部２４Ｘにメインメニュー画面が表示されている。このメインメニュー画面は、図５－３右側の表示画面に対応するが、安否登録リクエストが行われたにも関わらず、メインメニュー画面に重畳して安否登録リクエスト確認領域Ｒ２が表示されていない。
＜処理＞
　図５－４は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
　この図では、左側から順に、端末２０Ｘの制御部２１が実行する処理、端末２０Ｙの制御部２１が実行する処理、サーバ１０の制御部１１が実行する処理の一例を示している。
　ここでは、表示画面と同様に、
　・安否登録要求アカウント＝端末２０ＹのユーザＹ．Ｙ（限定ではなく、第１端末のユーザの一例）のアカウント
　・被安否登録要求アカウント＝端末２０ＸのユーザＸ．Ｘ（限定ではなく、端末のユーザの一例）のアカウント
　とする場合の処理を例示する。
　端末２０Ｙの制御部２１は、限定ではなく例として、災害情報を表示させると（Ｙ１２０）、被安否登録要求アカウントにおける安否確認登録を要求するための安否登録リクエストを行うか否かの判定用画面を表示部２４に表示させる（Ｙ４１０）。
　限定ではなく例として、判定用画面に対する入力操作に基づいて、安否登録リクエストを行うことが選択されたと判定される場合（Ｙ４１０：ＹＥＳ）、端末２０Ｙの制御部２１は、限定ではなく例として、被安否登録要求アカウントのアプリケーションＩＤを含む安否登録リクエスト要求情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ｙ４２０）。
　安否登録リクエストを行うことが選択されないと判定される場合（Ｙ４１０：ＮＯ）、端末２０Ｙの制御部２１は、Ｙ４２０のステップをスキップさせる。
　サーバ１０の制御部１１は、限定ではなく例として、災害情報を送信すると（Ｓ１２０）、通信Ｉ／Ｆ１４によって被安否登録要求アカウントに対する安否登録リクエスト要求情報を受信したか否かを判定する（Ｓ４１０）。
　安否登録リクエスト要求情報を受信したと判定する場合（Ｓ４１０：ＹＥＳ）、サーバ１０の制御部１１は、被安否登録要求アカウントに関する設定条件が成立しているか否かを判定する（Ｓ４２０）。設定条件については後述する。
　設定条件が成立していると判定する場合（Ｓ４２０：ＹＥＳ）、サーバ１０の制御部１１は、安否確認登録を要求するための安否登録リクエスト情報を被安否登録要求アカウントの端末２０Ｘに送信する（Ｓ４３０）。
　なお、安否登録リクエスト情報に、安否登録要求アカウントに関する情報（限定ではなく例として、アプリケーションＩＤ）を含めるようにしてもよいし、そうしなくてもよい。
　また、安否登録リクエスト情報は、受信した安否登録リクエスト要求情報をそのまま中継して送信するようにしてもよい。
　設定条件が成立していない判定する場合（Ｓ４２０：ＮＯ）、サーバ１０の制御部１１は、Ｓ４３０のステップをスキップさせる。
　安否登録リクエスト要求情報を受信しないと判定する場合（Ｓ４１０：ＮＯ）、サーバ１０の制御部１１は、Ｓ４２０～Ｓ４３０のステップをスキップさせる。
　端末２０Ｘの制御部２１は、限定ではなく例として、災害情報を表示させると（Ｘ１２０）、通信Ｉ／Ｆ２２によって安否登録リクエスト情報を受信したか否かを判定する（Ｘ４３０）。
　安否登録リクエスト情報を受信したと判定する場合（Ｘ４３０：ＹＥＳ）、端末２０Ｘの制御部２１は、受信した安否登録リクエスト情報を表示部２４に表示させる（Ｘ４４０）。
　安否登録リクエスト情報を受信していないと判定する場合（Ｘ４３０：ＮＯ）、端末２０Ｘの制御部２１は、Ｘ４４０のステップをスキップさせる。
　端末２０Ｘの制御部２１と、端末２０Ｙの制御部２１と、サーバ１０の制御部１１とは、処理を終了させるか否かを判定する（Ｘ４５０、Ｙ４５０、Ｓ４５０）。ここで、処理を終了させる判定条件としては、限定ではなく例として、災害発生日時から特定期間（限定ではなく例として、一週間）が経過した場合や、サーバ１０のユーザ入力に基づいて、安否確認サービスが停止されることが選択された場合等が挙げられる。
　処理を終了させると判定された場合（Ｘ４５０：ＹＥＳ、Ｙ４５０：ＹＥＳ、Ｓ４５０：ＹＥＳ）、各端末２０の制御部２１およびサーバ１０の制御部１１は、処理を終了させる。
　処理を終了させないと判定された場合（Ｘ４５０：ＮＯ、Ｙ４５０：ＮＯ、Ｓ４５０：ＮＯ）、端末２０Ｘの制御部２１は、限定ではなく例として、Ｘ４３０のステップに処理を戻す。また、端末２０Ｙの制御部２１は、限定ではなく例として、Ｙ４１０のステップに処理を戻す。また、サーバ１０の制御部１１は、限定ではなく例として、Ｓ４１０のステップに処理を戻す。
　なお、本フローチャートにおいて、Ｓ１２０・Ｘ１２０・Ｙ１２０の処理を省略し、サーバ１０における災害情報の送信と各端末２０における災害情報の表示とは行わないようにしてもよい。
　また、端末２０ＸにおけるＸ４３０～Ｘ４４０のステップは必須ではない。これは、災害により被安否登録要求アカウントの端末２０Ｘがオフライン状態となっている可能性が生じるためである。
　図５－５は、本実施例において各装置が実行する処理のタイミングの一例を示すタイミングチャートである。本タイミングチャートを用いて前述の設定条件の一例について説明する。ここでは、設定条件を、「被安否登録要求アカウントに対して１回目の安否登録リクエスト要求が行われた場合」とする。
　限定ではなく例として、端末２０Ｙにおいて端末２０Ｘに対する安否登録リクエスト要求操作が行われる（Ｙ４１０：ＹＥＳ）と、第１の安否登録リクエスト要求情報がサーバ１０に送信される（Ｙ４２０）（タイミング「ＴＭ５１０」）。
　すると、サーバ１０の制御部１１は、設定条件が成立していると判定し（４２０：ＹＥＳ）、第１の安否登録リクエスト情報を端末２０Ｘに送信する（Ｓ４３０）（タイミング「ＴＭ５２０」）。
　端末２０Ｘの制御部１１は、第１の安否登録リクエスト情報を受信すると、第１の安否登録リクエスト情報を表示部２４に表示させる（Ｘ４４０）（タイミング「ＴＭ５３０」）。
　その後、限定ではなく例として、再度端末２０Ｙにおいて端末２０Ｘに対する安否登録リクエスト要求操作が行われる（Ｙ４１０：ＹＥＳ）と、第２の安否登録リクエスト要求情報がサーバ１０に送信される（Ｙ４２０）（タイミング「ＴＭ５４０」）。
　すると、サーバ１０の制御部１１は、設定条件が成立していないと判定し（Ｓ４２０：ＮＯ）、第２の安否登録リクエスト情報を端末２０Ｘに送信しない。
　限定ではなく例として、再度端末２０Ｙにおいて端末２０Ｘに対する安否登録リクエスト要求操作が行われる（Ｙ４１０：ＹＥＳ）と、第３の安否登録リクエスト要求情報がサーバ１０に送信される（Ｙ４２０）（タイミング「ＴＭ５５０」）。
　すると、サーバ１０の制御部１１は、設定条件が成立していないと判定し（Ｓ４２０：ＮＯ）、第３の安否登録リクエスト情報を端末２０Ｘに送信しない。
　本設定条件では、安否登録要求アカウントから一の被安否登録要求アカウントに対して複数回の安否登録リクエスト要求が行われる場合、初めの一回目のみ被安否登録要求アカウントの端末２０に対して安否登録リクエストが行われる例を示している。このように設定条件を定めることで、非常時に被安否登録要求アカウントのユーザが繰り返し安否登録を求められる煩わしさから解放することができる。
　なお、上記の設定条件とは異なり、設定条件を「被安否登録要求アカウントに対してＮ回目（「Ｎ」は自然数）の安否登録リクエスト要求が行われた場合」としてもよい。この場合、安否登録要求アカウントから一の被安否登録要求アカウントに対してＮ回の安否登録リクエスト要求が行われると、サーバ１０の制御部１１は、初めて安否登録リクエスト要求情報を被安否登録要求アカウントの端末２０に送信する。
＜第５実施例の効果＞
　本実施例は、サーバ１０（限定ではなく、端末と通信するサーバの一例）は、被安否登録要求アカウントのユーザ（限定ではなく、端末のユーザの一例）に対する第１の安否登録リクエスト要求情報（限定ではなく、第１情報の一例）を通信Ｉ／Ｆ１４によって安否登録要求アカウントのユーザの端末２０（限定ではなく、第１端末の一例）から受信する。そして、サーバ１０は、受信した第１の安否登録リクエスト要求情報と、設定された条件とに基づき、第１の安否登録リクエスト情報（限定ではなく、安否確認に関する第２情報の一例）を通信Ｉ／Ｆ１４によって被安否登録要求アカウントのユーザの端末２０に送信する構成を示している。
　このような構成により得られる実施例の効果の一例として、端末のユーザに対する安否確認の依頼に関する第１情報を第１端末から受信した上で、その第１情報と設定された条件とに基づき、安否確認に関する第２情報を端末に送信して、その端末のユーザの安否を尋ねることができる。
＜第５変形例（１）＞
　上記の実施例では、設定条件に基づいて、サーバ１０は被安否登録要求アカウントに対して１回のみ安否登録リクエスト情報を送信することとしたが、これに限定されない。限定ではなく例として、サーバ１０は、設定条件に基づいて、複数回安否登録リクエスト情報を送信するようにしてもよい。
　また、上記の実施例では、安否登録要求アカウントと被安否登録要求アカウントとは異なるアカウントとして説明したが、これに限定されない。
　以下説明する画面図では、メッセージングアプリケーションにおける実装例を例示する。
　図５－６は、本実施例の手法をメッセージングアプリケーションに適用した場合のユーザＡ．Ａの端末２０Ａの表示部２４に表示されるメッセージングアプリケーションのホーム画面の一例を示している。
　このホーム画面では、図１－１２左側に示したホーム画面とは異なり、友だちリストには、友だちリストの項目として、 ユーザＢ．Ｂに対応したアイコンおよびユーザ名、ユーザＣ．Ｃに対応したアイコンおよびユーザ名、ユーザＤ．Ｄに対応したアイコンおよびユーザ名、ユーザＥ．Ｅに対応したアイコンおよびユーザ名、ユーザＦ．Ｆに対応したアイコンおよびユーザ名等が一覧表示されている。
　また、ユーザＢ．Ｂが安否情報を設定していないことに基づいて、友だちリストのユーザＢ．Ｂに対応したアイコンには、第１不明アイコンＵＩＣ１（本例では、「？」の文字が示されているアイコン）が重畳表示されている。ユーザＣ．Ｃが安否情報として「危険」を設定していることに基づいて、友だちリストのユーザＣ．Ｃに対応したアイコンには、第１危険アイコンＤＩＣ１が重畳表示されている。ユーザＤ．Ｄが安否情報として「安全」を設定していることに基づいて、ユーザＤ．Ｄに対応したアイコンに、第１安全アイコンＳＩＣ１が重畳表示されている。ユーザＥ．Ｅが安否情報として「安全」を設定していることに基づいて、ユーザＥ．Ｅに対応したアイコンに、第１安全アイコンＳＩＣ１が重畳表示されている。ユーザＦ．Ｆが安否情報として「安全」を設定していることに基づいて、ユーザＦ．Ｆに対応したアイコンに、第１安全アイコンＳＩＣ１が重畳表示されている。
　限定ではなく例として、図５－６左側のホーム画面において、ユーザＢ．Ｂに対応した友だちリストの項目がユーザによってタップされると、限定ではなく例として、図５－６中央のユーザＢ．Ｂのプロフィール画面に表示が遷移する。
　このプロフィール画面は、図２－５右側に示した例とは異なり、ユーザＢ．Ｂのプロフィールを示すアイコンおよびユーザ名の下に、ユーザＢ．Ｂの安否に関する情報として、第２不明アイコンＵＩＣ２が表示されている。また、そのユーザを相手としたトークを行うためのボタン、そのユーザを相手とした音声通話を行うためのボタン、および、そのユーザを相手としたビデオ通話を行うためのボタンの下には、そのユーザに安否情報を設定するように促すための、前述した安否登録リクエストボタンＢＴ２ａと同様の安否登録リクエストボタンＢＴ２ｂが表示されている。
　限定ではなく例として、図５－６中央のプロフィール画面において、ユーザＢ．Ｂを相手とする安否登録リクエストボタンＢＴ２ｂがユーザによってタップされると、限定ではなく例として、図５－６右側に示すように、安否登録リクエスト確認情報ＳＲＩ２がプロフィール画面に重畳表示される。
　安否登録リクエスト確認情報ＳＲＩ２には、限定ではなく例として、安否確認アプリケーションのアイコン画像に関連した画像と、「Ｂ．Ｂに安否登録のリクエストを行いました」の文字と、安否登録のリクエストが行われたことを確認し、安否登録リクエスト確認情報ＳＲＩ２の表示を終了するための「ＯＫ」の文字を含むアイコンで示されるＯＫボタンとが含まれる。
　図５－７左側は、ユーザＢ．Ｂの端末２０Ｂの表示部２４に表示されるトークルーム画面の一例を示している。
　このトークルーム画面では、図１－１０中央に示したトークルーム画面とは異なり、トークルーム名表示領域には、限定ではなく例として、ユーザＢ．Ｂが、公式アカウントとしてメッセージングアプリケーションに登録されている安否確認サービスのＯＡアカウントを相手としてトークを行うためのトークルームであることを示す文字（本例では「安否確認サービス」）が表示されている。
　トーク領域には、限定ではなく例として、ＯＡアカウントからのコンテンツとして、「こちらは安否確認応答サービスです　２０ＸＸ／０８／０４　９：３９　茨城県沖を震源とする地震が発生しました」の文字を含む災害発生コンテンツＤＣＴ１が表示されている。
　また、その下には、ＯＡアカウントからのコンテンツとして、「安否登録リクエスト　以下の友だちから安否登録を求められています」、ユーザＡ．Ａのアイコン画像とユーザ名、およびそのリクエストに回答するための回答ボタンＢＴ４ｂを含む安否登録リクエストコンテンツＲＣＴ１が表示されている。
　限定ではなく例として、ユーザＡ．ＡによってユーザＢ．Ｂを相手とする安否登録リクエストが行われた後、ユーザＣ．ＣによってユーザＢ．Ｂを相手とする安否登録リクエストが行われたとする。
　この場合、ユーザＣ．Ｃの端末２０Ｃには、限定ではなく例として、図５－７中央に示すようなプロフィール画面に安否登録リクエスト確認情報ＳＲＩ３が重畳表示される。
　このプロフィール画面では、図５－６右側に示したプロフィール画面とは異なり、画面最上部の右側には、この端末２０Ｃのユーザのメッセージングアプリケーションにおけるアイコン画像およびユーザ名（この例では「ユーザＣ．Ｃ」）が表示されている。
　安否登録リクエスト確認情報ＳＲＩ３には、限定ではなく例として、安否確認アプリケーションのアイコン画像に関連した画像と、「Ｂ．Ｂに安否登録のリクエストを行いました」の文字と、安否登録のリクエストが行われたことを確認し、安否登録リクエスト確認情報ＳＲＩ３の表示を終了するための「ＯＫ」の文字を含むアイコンで示されるＯＫボタンとが表示されている。
　限定ではなく例として、ユーザＡ．ＡによってユーザＢ．Ｂを相手とする安否登録リクエストが行われた後、ユーザＣ．ＣによってユーザＢ．Ｂを相手とする安否登録リクエストが行われたとする。
　この場合、ユーザＢ．Ｂの端末２０Ｂには、限定ではなく例として、図５－７右側に示すようなトークルーム画面が表示される。
　このトークルーム画面の表示例では、ユーザＣ．ＣによってユーザＢ．Ｂを相手とする安否登録リクエストが行われたにも関わらず、トーク領域に新たな安否登録リクエストコンテンツが表示されておらず、図５－７左側と同様の表示画面となっている。
　図５－８左側は、ユーザＢ．Ｂの端末２０Ｂの表示部２４に表示されるトークルーム画面の一例を示している。このトークルーム画面は、図５－７左側の表示画面と同様であるので説明を省略する。
　限定ではなく例として、ユーザＡ．ＡによってユーザＢ．Ｂを相手とする安否登録リクエストが行われた後、上記のようにユーザＣ．ＣによってユーザＢ．Ｂを相手とする安否登録リクエストが行われたとする。さらに、他のユーザ（この例では、ユーザＤ．Ｄ、ユーザＦ．Ｆ）によってユーザＢ．Ｂを相手とする安否登録リクエストが行われたとする。
　この場合、ユーザＢ．Ｂの端末２０Ｂには、限定ではなく例として、図５－８右側に示すようなトークルーム画面が表示される。
　このトークルーム画面の表示例では、図５－７右側に示したトークルーム画面とは異なり、トーク領域には、限定ではなく例として、「９：４３」の安否登録リクエストコンテンツＲＣＴ１の下に、ＯＡアカウントからのコンテンツとして、「安否登録リクエスト　以下の友だちから安否登録を求められています」、ユーザＡ．Ａのアイコン画像とユーザ名、ユーザＣ．Ｃのアイコン画像とユーザ名、ユーザＤ．Ｄのアイコン画像とユーザ名、ユーザＦ．Ｆのアイコン画像とユーザ名、およびそのリクエストに回答するための回答ボタンＢＴ４ｂを含む、上記の「９：４３」から６０分後の「１０：４３」の新たな安否登録リクエストコンテンツＲＣＴ２が表示されている。
　なお、安否登録リクエストコンテンツ等の情報を、上記のように安否確認サービスのＯＡアカウントのトークルームの画面に表示させるのではなく、他の画面に表示させてもよい。
　限定ではなく例として、図５－７の表示画面例において、ユーザＡ．Ａからの安否登録リクエストコンテンツを、ユーザＡ．Ａとトークを行うためのトークルーム画面に表示させてもよいし、友だちリスト画面に表示させてもよいし、トークリスト画面に表示させてもよい。
　図５－９は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。
　この図では、左側から順に、端末２０Ｘの制御部２１が実行する処理、端末２０Ｙの制御部２１が実行する処理、サーバ１０の制御部１１が実行する処理の一例を示している。
　ここでは、表示画面とは異なり、
　・端末２０ＸのユーザＸ．Ｘ＝表示画面における端末２０ＡのユーザＡ．Ａ
　・端末２０ＹのユーザＹ．Ｙ＝表示画面における端末２０ＢのユーザＢ．Ｂ
　とする場合の処理を例示する。
　なお、他の端末２０Ｃ等についても端末２０Ｘや端末２０Ｙと同様に処理を実行することが可能である。
　各装置の制御部は、限定ではなく例として、安否確認処理を実行すると（Ｘ２１０・Ｙ２１０・Ｓ２１０）、安否登録リクエスト処理を実行する（Ｘ４８０・Ｙ４８０・Ｓ４８０）。
　図５－１０は、安否登録リクエスト処理の一例を示すフローチャートである。図の見方は、図５－９と同様である。
　端末２０Ｘの制御部２１は、限定ではなく例として、端末２０ＹのユーザＹ．Ｙに対して安否確認登録を要求するための安否登録リクエストを行うか否かの判定用画面を表示部２４に表示させるなどして、端末２０Ｙに対して安否登録リクエストを行うか否かを判定する（Ｙ４４１０ｙ）。
　限定ではなく例として、判定用画面に対する入力操作に基づいて、安否登録リクエストを行うことが選択されたと判定される場合（Ｘ４４１０ｙ：ＹＥＳ）、端末２０Ｘの制御部２１は、限定ではなく例として、端末２０ＹのアプリケーションＩＤを含む安否登録リクエスト要求情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ｘ４４２０ｙ）。
　安否登録リクエストを行うことが選択されないと判定される場合（Ｘ４４１０ｙ：ＮＯ）、端末２０Ｘの制御部２１は、Ｘ４４２０ｙのステップをスキップさせる。
　サーバ１０の制御部１１は、通信Ｉ／Ｆ１４によって端末２０Ｙのアカウントを被安否登録要求アカウントとする安否登録リクエスト要求情報を受信したか否かを判定する（Ｓ４４１０ｙ）。
　端末２０Ｙに対する安否登録リクエスト要求情報を受信したと判定する場合（Ｓ４４１０ｙ：ＹＥＳ）、サーバ１０の制御部１１は、被安否登録要求アカウントの端末２０（この場合、端末２０Ｙ）に関する複合設定条件が成立しているか否かを判定する（Ｓ４４２０ｙ）。複合設定条件については後述する。
　端末２０Ｙに対する複合設定条件が成立していると判定する場合（Ｓ４４２０ｙ：ＹＥＳ）、サーバ１０の制御部１１は、安否確認登録を要求するための安否登録リクエスト情報を被安否登録要求アカウントの端末２０Ｙに送信する（Ｓ４４３０ｙ）。なお、安否登録リクエスト情報に、安否登録要求アカウントに関する情報（限定ではなく例として、アプリケーションＩＤ）を含めるようにしてもよいし、そうしなくてもよい。
　端末２０Ｙに対する複合設定条件が成立していない判定する場合（Ｓ４４２０ｙ：ＮＯ）、サーバ１０の制御部１１は、Ｓ４４３０ｙのステップをスキップさせる。
　何れの端末２０からも端末２０Ｙに対する安否登録リクエスト要求情報を受信しないと判定する場合（Ｓ４４１０ｙ：ＮＯ）、サーバ１０の制御部１１は、Ｓ４４２０ｙ～Ｓ４４３０ｙのステップをスキップさせる。
　端末２０Ｙの制御部２１は、限定ではなく例として、端末２０ＸのユーザＸ．Ｘに対する安否登録リクエストを行う場合、安否登録リクエスト要求情報をサーバ１０に送信する（Ｙ４４１０ｘ・Ｙ４４２０ｘ）。各ステップは、限定ではなく例として、Ｘ４４１０ｙ・Ｘ４４２０ｙと同様に実行することができる。
　サーバ１０の制御部１１は、被安否登録要求アカウントを端末２０ＸのアカウントとしてＳ４４１０ｘ～Ｓ４４３０ｘの各ステップを実行する。各ステップは、限定ではなく例として、Ｓ４４１０ｙ～Ｓ４４３０ｙと同様に実行することができる。
　また、端末２０Ｘの制御部２１は、他の端末２０のアカウントを被安否登録要求アカウントとして、Ｘ４４１０ｙ・Ｘ４４２０ｙと同様の処理を実行する。サーバ１０の制御部１１は、被安否登録要求アカウントを変えながらＳ４４１０ｘ～Ｓ４４３０ｘの各ステップと同様の処理を実行する。
　他の端末２０においても同様である。
　端末２０Ｙの制御部２１は、通信Ｉ／Ｆ２２によって安否登録リクエスト情報を受信したか否かを判定する（Ｙ４４３０）。
　安否登録リクエスト情報を受信したと判定する場合（Ｙ４４３０：ＹＥＳ）、端末２０Ｙの制御部２１は、受信した安否登録リクエスト情報を表示部２４に表示させる（Ｙ４４４０）。
　安否登録リクエスト情報を受信していないと判定する場合（Ｙ４４３０：ＮＯ）、端末２０Ｙの制御部２１は、Ｙ４４４０のステップをスキップさせる。
　他の端末２０においても同様である。
　図５－９に戻り、端末２０Ｘの制御部２１と、端末２０Ｙの制御部２１と、サーバ１０の制御部１１とは、処理を終了させるか否かを判定する（Ｘ４９０、Ｙ４９０、Ｓ４９０）。ここで、処理を終了させる判定条件としては、限定ではなく例として、災害発生日時から特定期間（限定ではなく例として、一週間）が経過した場合や、サーバ１０のユーザ入力に基づいて、安否確認サービスが停止されることが選択された場合等が挙げられる。
　処理を終了させると判定された場合（Ｘ４９０：ＹＥＳ、Ｙ４９０：ＹＥＳ、Ｓ４９０：ＹＥＳ）、各端末２０の制御部２１およびサーバ１０の制御部１１は、処理を終了させる。
　処理を終了させないと判定された場合（Ｘ４９０：ＮＯ、Ｙ４９０：ＮＯ、Ｓ４９０：ＮＯ）、各端末２０の制御部２１およびサーバ１０の制御部１１は、限定ではなく例として、再度安否確認処理を実行する（Ｘ２１０、Ｙ２１０、Ｓ２１０）。
　他の端末２０においても同様である。
　なお、図５－９において、サーバ１０における災害情報の各端末２０への送信と、各端末２０における災害情報の表示処理とは実行されなくてもよい。
　また、任意のタイミングにおいてチャット処理が実行されるようにしてもよい。
　ここで、限定ではなく例として、各端末２０に対する複合設定条件を以下の２つの条件の組み合わせとして定義する。
　・「初期送信設定条件」：被安否登録要求アカウントの端末２０に対して安否登録リクエスト情報を始めて送信する条件。
　・「再送信設定条件」：被安否登録要求アカウントの端末２０に対して安否登録リクエスト情報を送信後、再度安否登録リクエスト要求情報を送信する条件。
　初期送信設定条件としては、限定ではなく例として、以下の例が挙げられる。
　（Ｘ１）．サーバ１０が一の被安否登録要求アカウントの端末２０に対する安否登録リクエスト要求情報を初めて受信した場合。
　（Ｘ２）．サーバ１０が一の被安否登録要求アカウントの端末２０に対する安否登録リクエスト要求情報をＬ回（「Ｌ」は自然数）受信した場合。
　（Ｘ３）．サーバ１０が一の安否登録要求アカウントの端末２０から一の被安否登録要求アカウントの端末２０に対する安否登録リクエスト要求情報を初めて受信した場合。
　（Ｘ４）．サーバ１０が一の安否登録要求アカウントの端末２０から一の被安否登録要求アカウントの端末２０に対する安否登録リクエスト要求情報をＭ回（「Ｍ」は自然数）受信した場合。
　（Ｘ５）．サーバ１０が一の被安否登録要求アカウントの端末２０に対する安否登録リクエスト要求情報を初めて受信した後、第１設定時刻（限定ではなく例として、「毎時０分０秒」）となった場合。
　（Ｘ６）．サーバ１０が一の被安否登録要求アカウントの端末２０に対する安否登録リクエスト要求情報を初めて受信した後、第１設定時間（限定ではなく例として、「５分間」）が経過した場合。
　（Ｘ７）．サーバ１０が一の被安否登録要求アカウントの端末２０に対する安否登録リクエスト要求情報を初めて受信した後、再度災害情報を送信する場合。
　（Ｘ８）．上記の（Ｘ１）～（Ｘ７）の任意の組み合わせ。
　また、再送信設定条件としては、限定ではなく例として、以下の例が挙げられる。
　（Ｙ１）．サーバ１０が一の被安否登録要求アカウントの端末２０に対する安否登録リクエスト要求情報をＰ回（「Ｐ」は自然数）受信した場合。なお、Ｐ回には、初期送信設定条件成立までにサーバ１０が安否登録リクエスト要求情報を受信した回数を含めるようにしてもよいし、そうしなくてもよい。
　（Ｙ２）．サーバ１０が初期送信設定条件を満たした一の安否登録要求アカウントの端末２０とは異なる安否登録要求アカウントの端末２０から、一の被安否登録要求アカウントの端末２０に対する安否登録リクエスト要求情報を初めて受信した場合。
　（Ｙ３）．サーバ１０が初期送信設定条件を満たした一の安否登録要求アカウントの端末２０とは異なる安否登録要求アカウントの端末２０から、一の被安否登録要求アカウントの端末２０に対する安否登録リクエスト要求情報をＱ回（「Ｑ」は自然数）受信した場合。なお、Ｑ回には、初期送信設定条件成立までにサーバ１０が安否登録リクエスト要求情報を受信した回数を含めるようにしてもよいし、そうしなくてもよい。
　（Ｙ４）．サーバ１０が初期送信設定条件を満たした一の安否登録要求アカウントの端末２０から、一の被安否登録要求アカウントの端末２０に対する安否登録リクエスト要求情報をＲ回（「Ｒ」は自然数）受信した場合。なお、Ｒ回には、初期送信設定条件成立までにサーバ１０が安否登録リクエスト要求情報を受信した回数を含めるようにしてもよいし、そうしなくてもよい。
　（Ｙ５）．サーバ１０が一の被安否登録要求アカウントの端末２０に安否登録リクエスト情報を送信した後、第２設定時刻（限定ではなく例として、「日付が変わる０時０分０秒」や「災害発生時刻＋Ｔ時間後」（「Ｔ」は自然数））となった場合。
　（Ｙ６）．サーバ１０が一の被安否登録要求アカウントの端末２０に安否登録リクエスト情報を送信した後、第２設定時間（限定ではなく例として、「６０分間」）が経過した場合。
　（Ｙ７）．サーバ１０が一の被安否登録要求アカウントの端末２０に安否登録リクエスト情報を送信した後、再度災害情報を送信する場合。
　（Ｙ８）．上記の（Ｙ１）～（Ｙ７）の任意の組み合わせ。
　限定ではなく例として、図５－６～図５－８の例は、複合設定条件を（Ｘ１）＋（Ｙ６）とした場合の一例である。
　図５－１１は、限定ではなく例として、複合設定条件を（Ｘ１）＋（Ｙ１）とした場合、各装置が実行する処理のタイミングの一例を示すタイミングチャートである。
　限定ではなく例として、端末２０Ｙにおいて端末２０Ｘに対する安否登録リクエスト要求操作が行われると、第１の安否登録リクエスト要求情報がサーバ１０に送信される（タイミング「ＴＭ６１０」）。
　すると、サーバ１０の制御部１１は、初期送信設定条件（Ｘ１）が成立していると判定し、第１の安否登録リクエスト情報を端末２０Ｘに送信する（タイミング「ＴＭ６２０」）。
　端末２０Ｘの制御部２１は、第１の安否登録リクエスト情報を受信すると、第１の安否登録リクエスト情報を表示部２４に表示させる（タイミング「ＴＭ６３０」）。
　その後、限定ではなく例として、再度端末２０Ｙにおいて端末２０Ｘに対する安否登録リクエスト要求操作が行われると、第２の安否登録リクエスト要求情報がサーバ１０に送信される（タイミング「ＴＭ６４０」）。
　すると、サーバ１０の制御部１１は、再送信設定条件（Ｙ１）が成立していないと判定し、第２の安否登録リクエスト情報を端末２０Ｘに送信しない（タイミング「ＴＭ６５０」）。
　端末２０Ｘに対する安否登録リクエスト要求操作が各端末２０において実行され、第Ｐ＋１の安否登録リクエスト要求情報をサーバ１０が受信する（タイミング「ＴＭ６６０」）。すると、サーバ１０の制御部１１は、再送信設定条件（Ｙ１）が成立したと判定し、第２の安否登録リクエスト情報を端末２０Ｘに送信する（タイミング「ＴＭ６７０」）。
　端末２０Ｘの制御部２１は、第２の安否登録リクエスト情報を受信すると、第２の安否登録リクエスト情報を表示部２４に表示させる（タイミング「ＴＭ６８０」）。
　初期送信設定条件と再送信設定条件とは、限定ではなく例として、以下の考え方に従って設定することができる。
・第１の考え方
　一の被安否登録要求アカウントにおいて初期送信設定条件を満たし、一度安否登録リクエスト情報を送信した後は基本的には再送しない。これにより、通信帯域が切迫し、端末２０の動作時間にも限りが生じる可能性が高い非常時において、被安否登録要求アカウントの端末２０に対して、繰り返し同じ種類の情報を送信することを防ぐことができる。しかしながら、安否確認登録を行うことを被安否登録要求アカウントのユーザが忘れている可能性があるため、再送信設定条件を満たす場合、リマインダーとして再度安否登録リクエスト情報を送信する。
・第２の考え方
　一の被安否登録要求アカウントにおいて初期送信設定条件を満たす場合は即座に安否登録リクエスト情報を送信する。その後、再送信設定条件を満たす場合においても、即座に安否登録リクエスト情報を送信する。これにより、サーバ１０が被安否登録要求アカウントの端末２０に対して安否登録リクエスト情報を送信する頻度を制御することができ、端末２０において頻繁に安否登録リクエスト情報が表示される煩わしさからユーザを解放することができる。
　なお、複合設定条件を初期送信設定条件のみの条件としてもよい。この場合、安否登録リクエスト情報の再送は実行されない。
　また、限定ではなく例として、再送信設定条件に、再送信回数に関する条件を付加するようにしてもよい。再送信回数に関する条件として、限定ではなく例として、安否登録リクエスト情報を被安否登録要求アカウントの端末２０に再送信する上限回数を定めるようにしてもよい。
　本変形例は、前述した設定条件は、初期送信設定条件（限定ではなく、端末のユーザに対する第１情報をサーバが最初に受信した場合、第２情報を端末に送信する条件の一例）に基づいて送信し、再送信設定条件（限定ではなく、端末のユーザに対する第１情報を最初に受信した後、第２情報を端末に送信する第１設定条件の一例）に基づいて送信する条件を含む構成を示している。
　このような構成により得られる実施例の効果の一例として、第１情報と、端末のユーザに対する第１情報をサーバが最初に受信した場合、第２情報を端末に送信し、端末のユーザに対する第１情報を最初に受信した後、第１設定条件に基づいて第２情報を端末に送信する条件とに基づき、安否確認に関する第２情報を端末に送信して、その端末のユーザの安否を尋ねることができる
　また、この場合、再送信設定条件は、設定された時刻、または設定された時間（時間間隔）に基づいて安否登録リクエスト情報（限定ではなく、第２情報の一例）を被安否登録要求アカウントのユーザの端末２０に送信する条件を含むようにすることができる。
　このような構成により得られる実施例の効果の一例として、第１情報と、設定された時刻、または設定された時間に基づいて第２情報を端末に送信する条件とに基づき、安否確認に関する第２情報を端末に送信して、その端末のユーザの安否を尋ねることができる。
　また、この場合、再送信設定条件は、最初にサーバ１０が安否登録リクエスト要求情報（限定ではなく、第１情報の一例）を受信した後、サーバ１０が受信した安否登録リクエスト要求情報（限定ではなく、第１情報の一例）の数に基づいて安否登録リクエスト情報（限定ではなく、第２情報の一例）を被安否登録要求アカウントのユーザの端末２０に送信する条件を含むようにすることができる。
　このような構成により得られる実施例の効果の一例として、第１情報と、最初に第１情報を受信した後、サーバが受信した第１情報の数に基づいて第２情報を端末に送信する条件とに基づき、安否確認に関する第２情報を端末に送信して、その端末のユーザの安否を尋ねることができる。
　また、この場合、再送信設定条件は、再度災害が発生したことを示す情報等の情報（限定ではなく、災害に関する情報の一例）に基づいて安否登録リクエスト情報（限定ではなく、第２情報の一例）を被安否登録要求アカウントのユーザの端末２０に送信する条件を含むようにすることができる。
　このような構成により得られる実施例の効果の一例として、第１情報と、災害に関する情報に基づいて第２情報を端末に送信する条件とに基づき、安否確認に関する第２情報を端末に送信して、その端末のユーザの安否を尋ねることができる。
　また、この場合、安否登録リクエスト情報（限定ではなく、第２情報の一例）は、被安否登録要求アカウントのユーザ（限定ではなく、端末のユーザの一例）を含むトークルーム（限定ではなく、チャットルームの一例）に表示されるようにすることができる。
　このような構成により得られる実施例の効果の一例として、安否確認に関する第２情報が、端末のユーザを含むチャットルームに表示されるようにすることで、分かり易い形で、端末のユーザに安否を尋ねることができる。
＜第５変形例（２）＞
　上記の変形例では、サーバ１０は、複合設定条件が成立する場合、安否登録リクエスト情報を被安否登録要求アカウントの端末２０に送信することとしたが、これに限定されない。限定ではなく例として、サーバ１０は、後述する送信停止設定条件を満たす場合、初期送信設定条件や再送信設定条件が成立しても安否登録リクエスト情報を被安否登録要求アカウントの端末２０に送信しないようにしてもよい。
　図５－１２左側は、ユーザＢ．Ｂの端末２０Ｂの表示部２４に表示されるトークルーム画面の一例を示している。このトークルーム画面は、図５－７左側の表示画面と同様であるので説明を省略する。
　限定ではなく例として、図５－１２左側のトークルーム画面において、安否登録リクエストコンテンツＲＣＴ１に含まれる回答ボタンＢＴ４ｂがユーザによってタップされると、限定ではなく例として、図５－１２中央に示すホーム画面に表示が遷移する。
　このホーム画面では、図４－１左側に示すホーム画面とは異なり、画面最上部の右部には、この端末２０Ｂのユーザのメッセージングアプリケーションにおけるアイコン画像およびユーザ名（この例では「ユーザＢ．Ｂ」）が表示されている。
　限定ではなく例として、図５－１２中央の安否登録領域Ｒ１において、危険ボタンＤＢＴがユーザＢ．Ｂによってタップされ、安否メッセージの定型文として「怪我をした」のテキストがユーザＢ．Ｂによって選択された後、登録ボタンＢＴ３がユーザＢ．Ｂによってタップされた場合における、ユーザＡ．Ａの端末２０Ａに表示されるトークリスト画面の一例を図５－１２右側に示す。このトークリスト画面は、図１－１９右側のトークリスト画面と同様であるので説明を省略する。
　限定ではなく例として、図５－１２右側のトークリスト画面において、ユーザＢ．Ｂのトークルームリスト項目のうちアイコン画像がユーザによってタップされると、限定ではなく例として、図５－１３左側のユーザＢ．Ｂに対応したプロフィール画面に表示が遷移する。
　このプロフィール画面では、図５－６中央に示した例とは異なり、画面最上部の右部に、この端末２０Ｂのユーザのメッセージングアプリケーションにおけるアイコン画像およびユーザ名（この例では「ユーザＡ．Ａ」）が表示されている。また、ユーザＢ．Ｂのプロフィールを示すアイコンおよびユーザ名の下には、ユーザＢ．Ｂの安否に関する情報として、第２危険アイコンＤＩＣ２が表示されている。
　限定ではなく例として、図５－１３左側のプロフィール画面において、ユーザＢ．Ｂを相手とする安否登録リクエストボタンＢＴ２ｂがユーザによってタップされると、限定ではなく例として、図５－１３中央に示す安否登録リクエスト確認情報ＳＲＩ４がプロフィール画面に重畳表示される。
　この安否登録リクエスト確認情報ＳＲＩ４は、図５－６右側の安否登録リクエスト確認情報ＳＲＩ２と同様であるので説明を省略する。
　限定ではなく例として、ユーザＢ．Ｂが安否登録リクエストに回答した後、ユーザＡ．ＡによってユーザＢ．Ｂを相手とする安否登録リクエストが行われたとする。
　この場合、ユーザＢ．Ｂの端末２０Ｂには、限定ではなく例として、図５－１３右側に示すようなトークルーム画面が表示される。
　このトークルーム画面では、ユーザＡ．ＡによってユーザＢ．Ｂを相手とする安否登録リクエストが行われたにも関わらず、トーク領域に新たな安否登録リクエストに対応したＯＡアカウントからの安否登録リクエストコンテンツが表示されておらず、図５－１２左側と同様の表示画面となっている。
　本変形例において、送信停止設定条件としては、限定ではなく例として、以下の例が挙げられる。
　（Ｚ１）．サーバ１０が一の被安否登録要求アカウントの端末２０から安否確認登録情報を受信した場合。
　（Ｚ２）．サーバ１０が一の被安否登録要求アカウントの端末２０に対する安否登録リクエスト要求情報をＵ回（「Ｕ」は自然数）受信した場合。
　（Ｚ３）．サーバ１０が特定の安否登録要求アカウントの端末２０から、一の被安否登録要求アカウントの端末２０に対する安否登録リクエスト要求情報をＶ回（「Ｖ」は自然数）受信した場合。
　（Ｚ４）．第３設定時刻（限定ではなく例として、「災害発生時刻＋７２時間後」となった場合）となった場合。
　（Ｚ５）．サーバ１０が一の被安否登録要求アカウントの端末２０に安否登録リクエスト情報を送信した後、第３設定時間（限定ではなく例として、「３６時間」）が経過した場合。
　（Ｚ６）．サーバ１０が再度災害情報を送信する場合。
　（Ｚ７）．上記の（Ｚ１）～（Ｚ６）の任意の組み合わせ。
　限定ではなく例として、図５－１２・図５－１３の例は、送信停止設定条件を（Ｚ１）とした場合の一例である。
　図５－１４は、限定ではなく例として、複合設定条件を（Ｘ１）＋任意の再送信設定条件＋（Ｚ１）とした場合、各装置が実行する処理のタイミングの一例を示すタイミングチャートである。
　限定ではなく例として、端末２０Ｙにおいて端末２０Ｘに対する安否登録リクエスト要求操作が行われると、第１の安否登録リクエスト要求情報がサーバ１０に送信される（タイミング「ＴＭ７１０」）。
　すると、サーバ１０の制御部１１は、初期送信設定条件（Ｘ１）が成立していると判定し、第１の安否登録リクエスト情報を端末２０Ｘに送信する（タイミング「ＴＭ７２０」）。
　端末２０Ｘの制御部２１は、第１の安否登録リクエスト情報を受信すると、第１の安否登録リクエスト情報を表示部２４に表示させる（タイミング「ＴＭ７３０」）。
　その後、限定ではなく例として、安否確認処理が実行され、端末２０Ｘにおいて、安否確認登録情報の入力操作を受け付けると、第１の安否確認登録情報がサーバ１０に送信される（タイミング「ＴＭ７４０」）。そして、サーバ１０は第１の安否確認登録情報を受信する。
　サーバ１０の制御部１１は、第１の安否確認登録情報に基づいて、第１の安否情報を生成し、各端末２０に送信する（タイミング「ＴＭ７５０」）。
　端末２０Ｙは第１の安否情報を受信すると表示処理を実行する（タイミング「ＴＭ７６０」）。
　その後、限定ではなく例として、端末２０Ｙにおいて端末２０Ｘに対する安否登録リクエスト要求操作が行われると、第２の安否登録リクエスト要求情報がサーバ１０に送信される（タイミング「ＴＭ７７０」）。
　すると、サーバ１０の制御部１１は、送信停止設定条件（Ｚ１）が成立していると判定し、第２の安否登録リクエスト情報を端末２０Ｘに送信しない（タイミング「ＴＭ７８０」）。
　なお、端末２０Ｙの制御部２１は、端末２０Ｘのアカウントに関する安否情報を受信した場合、それ以降に端末２０Ｘのアカウントに対する安否登録リクエスト要求操作を受け付けないようにしてもよい。
　本変形例は、サーバ１０が、安否登録リクエスト情報（限定ではなく、第２情報の一例）の送信に基づき、安否確認登録情報（限定ではなく、端末のユーザの安否に関する情報を含む第３情報の一例）を通信Ｉ／Ｆ１４によって受信する。そして、サーバ１０は、この安否確認登録情報の受信に基づき、この安否確認登録情報の受信の後に、被安否登録要求アカウントに対する安否登録リクエスト要求情報（限定ではなく、第３情報の一例）を受信した場合、その安否登録リクエスト要求情報に基づく安否登録リクエスト情報の送信を行わない制御を制御部１１によって行う構成を示している。
　このような構成により得られる実施例の効果の一例として、第２情報の送信に基づき、端末のユーザの安否に関する情報を含む第３情報を端末から受信した上で、この第３情報の受信に基づいて、第３情報の受信の後に端末のユーザに対する第１情報を受信した場合、第１情報に基づく第２情報の送信を行わないようにすることで、端末のユーザの安否を一旦確認した場合は再度確認せずに済み、端末のユーザが煩わしさを感じないようにすることができる。また、不要な通信をせずに済み、通信量を削減することができる
＜第５変形例（３）＞
　上記の実施例では、サーバ１０において設定条件（複合設定条件）の判定を実行することとしたが、これに限定されない。限定ではなく例として、設定条件（複合設定条件）の判定を被安否登録要求アカウントの端末２０で判定するようにしてもよい。
　この場合、サーバ１０の制御部１１は、安否登録要求アカウントの端末２０Ｙから被安否登録要求アカウントの端末２０Ｘに対する安否登録リクエスト要求情報を受信すると、安否登録リクエスト情報を端末２０Ｘに送信する。
　端末２０Ｘの制御部２１は、安否登録リクエスト情報を受信すると、設定条件（複合設定条件）が成立するか否かを判定する。そして、端末２０Ｘの制御部２１は、設定条件（複合設定条件）が成立すると判定する場合、受信した安否登録リクエスト情報を表示部２４に表示させる。
　設定条件（複合設定条件）が成立しないと判定する場合、端末２０Ｘの制御部２１は、受信した安否登録リクエスト情報を表示部２４に表示させない。
＜第５変形例（４）＞
　上記の実施例では、サーバ１０において設定条件（複合設定条件）の判定を実行することとしたが、これに限定されない。限定ではなく例として、設定条件（複合設定条件）の判定を安否登録要求アカウントの端末２０で判定するようにしてもよい。
　この場合、安否登録要求アカウントの端末２０Ｙの制御部２１は、被安否登録要求アカウントの端末２０Ｘに対する安否登録リクエスト要求操作が行われると、設定条件（複合設定条件）が成立するか否かを判定する。そして、端末２０Ｙの制御部２１は、設定条件（複合設定条件）が成立すると判定する場合、サーバ１０に安否登録リクエスト情報を送信する。
　サーバ１０の制御部１１は、端末２０Ｙから端末２０Ｘに対する安否登録リクエスト要求情報を受信すると、安否登録リクエスト情報を端末２０Ｘに送信する。
　端末２０Ｘの制御部２１は、安否登録リクエスト情報を受信すると、表示部２４に表示させる。
　設定条件（複合設定条件）が成立しないと判定する場合、端末２０Ｙの制御部２１は、サーバ１０に安否登録リクエスト情報を送信しない。
　なお、安否登録要求アカウントの端末２０において設定条件（複合設定条件）を判定させる場合、他の端末２０が被安否登録要求アカウントの端末２０に対する安否登録リクエスト要求情報を送信したか否かは判定できない。そのため、この場合、設定条件（複合設定条件）は自端末における安否登録リクエスト要求操作の回数や、時刻や自端末における安否登録リクエスト要求操作を受け付けてからの時間、災害情報を再度受信したか等に限られる。
＜第６実施例＞
　第６実施例は、被安否登録要求アカウントの端末２０において、被安否登録要求アカウントに対して安否登録リクエストを要求した安否登録要求アカウントを確認可能とする実施例である。
　第６実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
　また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
＜表示画面＞
　図６－１は、端末２０Ｂの表示部２４に表示されるメッセージングアプリケーションの画面の一例を示す図である。
　図６－１左側では、トーク領域の「安否登録リクエスト」と示された安否登録リクエストコンテンツＲＣＴ６内に、回答ボタンＢＴ４ｂの他、自分（ユーザＢ．Ｂ）に対して安否登録リクエストを要求した安否登録要求アカウント（友だち）を確認するための「友だち確認」ボタンＢＴ６が設けられている。この「友だち確認」ボタンＢＴ６がタップされると、図６－１右側のような表示がなされる。
　具体的には、画面下部からせり上がるように、自分（ユーザＢ．Ｂ）に対して安否登録リクエストを要求した安否登録要求アカウントに関する情報を含む安否登録リクエスト要求ユーザ一覧領域ＳＲＲが表示されている。この例では、「以下の友だちから安否登録を求められています」の文字とともに、この例では、ユーザＡ．Ａ、ユーザＣ．Ｃ、ユーザＤ．Ｄ、ユーザＦ．Ｆの４名のユーザについて、それぞれアイコンおよびユーザ名が表示されている。また、各々のユーザのアイコンには、そのユーザによって登録された安否ステータス情報に基づくアイコンが重畳して表示されている。
＜処理＞
　図６－２は、限定ではなく例として、本実施例において各装置が実行する処理のタイミングの一例を示すタイミングチャートである。
　この図では、左側から順に、端末２０Ｘの制御部２１が実行する処理、端末２０Ｙの制御部２１が実行する処理、サーバ１０の制御部１１が実行する処理の一例を示している。
　ここでは、表示画面とは異なり、
　・安否登録要求アカウント＝端末２０ＹのユーザＹ．Ｙのアカウント＝表示画面における端末２０Ａおよび端末２０Ｃ～端末２０Ｆのユーザ
　・被安否登録要求アカウント＝端末２０ＸのユーザＸ．Ｘのアカウント＝表示画面における端末２０ＢのユーザＢ．Ｂ
　とする場合の処理を例示する。
　また、複合設定条件を上記の（Ｘ１）＋（Ｙ１）とした場合について例示する。
　限定ではなく例として、端末２０Ｙにおいて端末２０Ｘに対する安否登録リクエスト要求操作が行われると、第１の安否登録リクエスト要求情報がサーバ１０に送信される（タイミング「ＴＭ８１０」）。
　すると、サーバ１０の制御部１１は、初期送信設定条件（Ｘ１）が成立していると判定し、第１の安否登録リクエスト情報を端末２０Ｘに送信する（タイミング「ＴＭ８２０」）。
　端末２０Ｘの制御部２１は、第１の安否登録リクエスト情報を受信すると、第１の安否登録リクエスト情報を表示部２４に表示させる（タイミング「ＴＭ８３０」）。
その後、限定ではなく例として、他の端末２０において端末２０Ｘに対する安否登録リクエスト要求操作が行われると、第２の安否登録リクエスト要求情報がサーバ１０に送信される。
　すると、サーバ１０の制御部１１は、再送信設定条件（Ｙ１）が成立していないと判定し、第２の安否登録リクエスト情報を端末２０Ｘに送信しない（タイミング「ＴＭ８４０」）。
　他の端末２０からサーバ１０に送信された安否登録リクエスト要求情報についても同様である。
　そして、限定ではなく例として、端末２０Ｘの制御部２１は、安否登録リクエスト要求ユーザ情報要求操作を実行する（タイミング「ＴＭ８５０」）。安否登録リクエスト要求ユーザ情報要求操作において、端末２０Ｘの制御部２１は、限定ではなく例として、第１の安否登録リクエスト情報に対するユーザ操作に基づいて、端末２０Ｘに対する安否登録リクエスト要求情報を送信した安否登録要求アカウントを確認することが選択されたか否かを判定する。そして、安否登録要求アカウントを確認することが選択されたと判定した場合、端末２０Ｘの制御部２１は、安否登録リクエスト要求ユーザ情報要求情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する。
　通信Ｉ／Ｆ１４によって端末２０Ｘから安否登録リクエスト要求ユーザ情報要求情報を受信すると（タイミング「ＴＭ８６０」）、サーバ１０の制御部１１は、安否登録リクエスト要求ユーザ一覧情報を通信Ｉ／Ｆ１４によって端末２０Ｘに送信する（タイミング「ＴＭ８７０」）。
　ここで、安否登録リクエスト要求ユーザ一覧情報には、限定ではなく例として、タイミング「ＴＭ８６０」以前に受信した端末２０Ｘに対する安否登録リクエスト要求情報における、安否登録要求アカウントに関する情報（限定ではなく例として、アプリケーションＩＤやユーザ名等を含む）の一覧が含まれる。
　通信Ｉ／Ｆ２２によってサーバ１０から安否登録リクエスト要求ユーザ一覧情報を受信すると、端末２０Ｘの制御部２１は、受信した安否登録リクエスト要求ユーザ一覧情報を表示部２４に表示させる（タイミング「ＴＭ８８０」）。
＜第６実施例の効果＞
　本実施例は、被安否登録要求アカウントの端末２０において、安否登録リクエスト情報（限定ではなく、第２情報の一例）の受信に基づき、その安否登録リクエスト情報の表示や、その被安否登録要求アカウントに対して安否登録リクエストを要求した安否登録要求アカウントに関する表示（限定ではなく、安否確認に関する第１表示の一例）が表示部２４に表示される。そして、サーバ１０は、被安否登録要求アカウントの端末２０において、その表示に対するその被安否登録要求アカウントのユーザによる入力に基づいて、安否登録リクエスト要求情報（限定ではなく、第１情報の一例）を送信した安否登録要求アカウントの情報（限定ではなく、第１情報を送信したユーザの情報の一例）を通信Ｉ／Ｆ１４によって被安否登録要求アカウントの端末２０に送信する構成を示している。
　このような構成により得られる実施例の効果の一例として、端末で、第２情報の受信に基づき、安否確認に関する第１表示が表示部に表示され、その第１表示に対する、端末のユーザによる入力に基づいて、第１情報を送信したユーザの情報を端末に送信することで、第１情報を送信したユーザの情報を端末のユーザに知らせることができる。
　また、この場合、サーバ１０は、一の安否登録要求アカウントの端末２０（限定ではなく、第１端末の一例）から送信された被安否登録要求アカウントに対する安否登録リクエスト要求情報の受信に基づき、安否登録リクエスト情報（限定ではなく、第２情報の一例）を通信Ｉ／Ｆ１４によって被安否登録要求アカウントの端末２０に送信する。また、サーバ１０は、被安否登録要求アカウントに対する安否登録リクエスト要求情報を一の安否登録要求アカウントの端末２０から受信した後、被安否登録要求アカウントに対する安否登録リクエスト要求情報を他の安否登録要求アカウントの端末２０（限定ではなく、第２端末の一例）から通信Ｉ／Ｆ１４によって受信する。また、サーバ１０は、設定された条件を満たさない場合、他の安否登録要求アカウントの端末２０（第２端末）から受信した安否登録リクエスト要求情報に基づく安否登録リクエスト情報を被安否登録要求アカウントの端末２０に送信しない制御を制御部１１によって行う。この場合、サーバ１０は、上記の表示に対する被安否登録要求アカウントのユーザによる入力に基づいて、安否登録リクエスト要求情報（限定ではなく、第１情報の一例）を送信した、一の安否登録要求アカウントの情報（限定ではなく、第１端末のユーザの情報の一例）と、他の安否登録要求アカウントの情報（限定ではなく、第２端末のユーザの情報の一例）とを通信Ｉ／Ｆ１４によって被安否登録要求アカウントの端末２０に送信する構成を示している。
　このような構成により得られる実施例の効果の一例として、端末のユーザに対する第１情報を第１端末から受信した後、端末のユーザに対する第１情報を第２端末から受信し、設定された条件を満たさない場合、第２端末から受信した第１情報に基づく第２情報を端末に送信しないようにすることで、端末のユーザが煩わしさを感じないようにすることができる。また、端末で、第２情報の受信に基づき、安否確認に関する第１表示が表示部に表示され、その第１表示に対する、端末のユーザによる入力に基づいて、第１情報を送信した、第１端末のユーザの情報と、第２端末のユーザの情報とを含むユーザの情報を端末に送信することで、第１情報を送信した、第１端末のユーザの情報と、第２端末のユーザの情報とを端末のユーザに知らせることができる。
＜第６変形例（１）＞
　上記の実施例では、被安否登録要求アカウントの端末２０Ｘにおいて安否登録リクエスト要求ユーザ情報要求操作が実行されると、サーバ１０から端末２０Ｘに安否登録リクエスト要求ユーザ情報が送信されることとしたが、これに限定されない。
　図６－３は、本変形例における表示画面の一例を示す図である。
　図６－３左側、中央は、それぞれ図５－７左側、中央と同様である。
　本変形例では、後述するタイミングで、安否登録リクエスト要求ユーザ一覧情報が、サーバ１０から端末２０Ｂに送信される。その結果、端末２０Ｂの表示部２４には、図６－３右側のような表示がなされる。この画面は、図６－３左側に対応する画面であるが、ＯＡからのコンテンツとして、ユーザＢ．ＢがユーザＡ．ＡとユーザＣ．Ｃとから安否登録を要求されていることを示す安否登録リクエストコンテンツＲＣＴ７が示されている。
　サーバ１０の制御部１１は、任意のタイミングにおいて、安否登録リクエスト要求ユーザ一覧情報送信条件が成立すると判定した場合、端末２０Ｘに安否登録リクエスト要求ユーザ一覧情報を送信するようにすることができる。
　ここで、安否登録リクエスト要求ユーザ一覧情報送信条件としては、限定ではなく例として、以下の例が挙げられる。
　・任意の一の端末２０から安否登録リクエスト要求情報を最後に受信した後、設定期間（限定ではなく例として、「３０分」）が経過した場合。
　・任意の一の端末２０から安否登録リクエスト要求情報を最後に受信した後、設定時刻（限定ではなく例として、「正午」）となった場合。
・任意の一の端末２０から安否登録リクエスト要求情報を設定回数以上、または設定回数より多く受信した場合。
　・各端末２０から安否登録リクエスト要求情報を最後に受信した後、設定期間（限定ではなく例として、「３０分」）が経過した場合。
　・各端末２０から安否登録リクエスト要求情報を最後に受信した後、設定時刻（限定ではなく例として、「正午」）となった場合。
・各端末２０から安否登録リクエスト要求情報を設定回数以上、または設定回数より多く受信した場合。
　・端末２０Ｘから安否確認登録情報を受信した場合。
　・端末２０Ｘに安否登録リクエスト情報を送信する場合。
　なお、本変形例における処理は以下のようにしてもよい。
　限定ではなく例として、サーバ１０の制御部１１は、安否登録要求アカウントの端末２０から安否登録リクエスト要求情報を受信すると、安否登録リクエスト情報を送信するか否かの複合設定条件に関わらず、端末２０Ｘに受信した安否登録要求アカウントに関する情報を送信する。以下では、限定ではなく例として、個別の安否登録リクエスト要求情報に対応する安否登録要求アカウントに関する情報を、「安否登録リクエスト要求ユーザ情報」と称する。
　この場合、端末２０Ｘの制御部２１は、サーバ１０から安否登録リクエスト要求ユーザ情報を受信すると、限定ではなく例として、記憶部２８に記憶させる。
　そして、端末２０Ｘの制御部２１は、安否登録リクエスト要求ユーザ表示条件が成立すると判定した場合、記憶部２８に記憶された安否登録リクエスト要求ユーザ情報を表示部２４に表示させる。
　ここで、安否登録リクエスト要求ユーザ表示条件としては、限定ではなく例として、以下の例が挙げられる。
　・安否登録リクエスト要求ユーザ情報要求操作が実行され、端末２０Ｘに対する安否登録リクエスト要求情報を送信した安否登録要求アカウントを確認することが選択された場合。
　・サーバ１０から安否登録リクエスト情報を最後に受信後、設定期間（限定ではなく例として、「３０分」）が経過した場合。
　・サーバ１０から安否登録リクエスト情報を最後に受信後、設定時刻（限定ではなく例として、「正午」）となった場合。
・サーバ１０から安否登録リクエスト要求ユーザ情報を設定回数以上、または設定回数より多く受信した場合。
　・端末２０Ｘにおいて安否確認登録情報の入力が行われた場合。
＜第７実施例＞
　第７実施例は、安否確認サービスにおいて、一の災害における安否登録の期間が終了した場合、安否確認登録を受け付けない実施例である。
　第７実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
　また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
＜表示画面＞
　図７－１は、本実施例において端末２０Ｂの表示部２４に表示されるメッセージングアプリケーションの画面の一例を示す図である。
　この例では、前述したユーザＡ．Ａ、ユーザＣ．Ｃ、ユーザＤ．Ｄ、ユーザＦ．Ｆの４名のユーザから安否確認登録を要求されていることが示す安否登録リクエストコンテンツＲＣＴ８の下に、ＯＡアカウントからの「２０ＸＸ年８月４日９時３９分」に発生した地震による安否登録を停止することを示す安否登録停止確認コンテンツＳＣＴ１が表示されている。この状態で、安否登録リクエストコンテンツＲＣＴ８内の回答ボタンＢＴ４ｂがタップされると、図７－１右側のような表示がなされる。
　この例では、既に安否登録が可能な期間が経過していることに基づいて、図７－１左側の画面の中央部に、「安否登録期間が終了しています」の文字と、キャラクタの画像と、「ＯＫ」ボタンとを含む安否確認登録受付期間終了情報ＥＰＩ１が表示されている。「ＯＫ」ボタンがタップされると、安否確認登録受付期間終了情報ＥＰＩ１の表示は消去されるが、安否確認登録は受け付けられず、ユーザＢ．Ｂは安否確認登録をすることができないように構成されている。
＜処理＞
　図７－２は、限定ではなく例として、本実施例において各装置が実行する処理のタイミングの一例を示すタイミングチャートである。
　この図では、左側から順に、端末２０Ｘの制御部２１が実行する処理、端末２０Ｙの制御部２１が実行する処理、サーバ１０の制御部１１が実行する処理の一例を示している。
　ここでは、表示画面とは異なり、
　・安否登録要求アカウント＝端末２０ＹのユーザＹ．Ｙのアカウント＝表示画面における端末２０Ａおよび端末２０Ｃ～端末２０Ｆのユーザ
　・被安否登録要求アカウント＝端末２０ＸのユーザＸ．Ｘのアカウント＝表示画面における端末２０ＢのユーザＢ．Ｂ
　とする場合の処理を例示する。
　限定ではなく例として、端末２０Ｙにおいて端末２０Ｘに対する安否登録リクエスト要求操作が行われると、第１の安否登録リクエスト要求情報がサーバ１０に送信される（タイミング「ＴＭ９１０」）。
　すると、サーバ１０の制御部１１は、初期送信設定条件（Ｘ１）が成立していると判定し、第１の安否登録リクエスト情報を端末２０Ｘに送信する（タイミング「ＴＭ９２０」）。
　端末２０Ｘの制御部２１は、第１の安否登録リクエスト情報を受信すると、第１の安否登録リクエスト情報を表示部２４に表示させる（タイミング「ＴＭ９３０」）。
　次いで、サーバ１０の制御部１１は、安否確認登録受付期間終了処理を実行する（タイミング「ＴＭ９４０」）。
　安否確認登録受付期間終了処理において、サーバ１０の制御部１１は、限定ではなく例として、サーバ１０のユーザによる入力操作に基づいて、安否確認処理や安否登録リクエスト処理を終了させるか否かの判定を行う。安否確認処理や安否登録リクエスト処理を終了させると判定された場合、サーバ１０の制御部１１は、安否確認登録情報の受信に対する安否情報の送信と、安否登録リクエスト要求情報の受信に対する安否登録リクエスト情報の送信とを停止させる。
　なお、安否確認登録受付期間終了処理において、サーバ１０の制御部１１は、限定ではなく例として、災害情報の災害発生日時から設定期間が経過したか否かに基づいて、安否確認処理や安否登録リクエスト処理を終了させるか否かの判定を行うようにしてもよい。また、サーバ１０の制御部１１は、限定ではなく例として、災害情報における安否確認受付終了日時に基づいて、安否確認処理や安否登録リクエスト処理を終了させるか否かの判定を行うようにしてもよい。
　その後、端末２０Ｘにおいて、限定ではなく例として、第１の安否登録リクエスト情報に対する入力操作に基づいて、安否確認登録情報を受け付けると、第１の安否確認登録情報がサーバ１０に送信される（タイミング「ＴＭ９５０」）。そして、サーバ１０は第１の安否確認登録情報を受信する（タイミング「ＴＭ９６０」）。
　なお、端末２０Ｙにおいて安否登録リクエスト要求操作が実行され、端末２０Ｘが安否登録リクエスト情報を受信することは必須ではない。
　サーバ１０の制御部１１は、タイミング「ＴＭ９４０」において安否確認処理や安否登録リクエスト処理を終了させると判定し、タイミング「ＴＭ９４０」以降に安否確認登録情報を受信した場合（限定ではなく例として、タイミング「ＴＭ９６０」）、安否確認登録の受け付けを終了したことを示す安否確認登録受付期間終了情報を通信Ｉ／Ｆ１４によって安否登録アカウントの端末２０Ｘに送信する（タイミング「ＴＭ９７０」）。
　端末２０Ｘの制御部２１は、サーバ１０から安否確認登録受付期間終了情報を受信すると、受信した安否確認登録受付期間終了情報を表示部２４に表示させる（タイミング「ＴＭ９８０」）。
　なお、サーバ１０の制御部１１は、タイミング「ＴＭ９４０」において安否確認処理や安否登録リクエスト処理を終了させると判定し、タイミング「ＴＭ９４０」以降に安否登録リクエスト要求情報を受信した場合、安否確認登録受付期間終了情報を安否登録要求アカウントの端末２０に送信するようにしてもよい。
　また、サーバ１０の制御部１１は、限定ではなく例として、タイミング「ＴＭ９４０」以降に、端末２０Ｘから前述した安否登録リクエスト要求ユーザ情報要求情報を受信する場合、安否確認登録受付期間終了情報を端末２０Ｘに送信するようにしてもよい。
＜第７実施例の効果＞
　本実施例は、被安否登録要求アカウントの端末２０において、安否登録リクエスト情報（限定ではなく、第２情報の一例）の受信に基づき、前述した第１表示が表示部２４に表示される。そして、サーバ１０は、安否確認登録受付期間（限定ではなく、安否確認の受付の一例）が終了している場合、その第１表示に対する、その被安否登録要求アカウントのユーザによる入力に基づいて、安否確認登録受付期間終了情報（限定ではなく、安否確認の受付が終了していることに関する情報の一例）を通信Ｉ／Ｆ１４によって被安否登録要求アカウントのユーザの端末２０に送信する構成を示している。
　このような構成により得られる実施例の効果の一例として、端末で、第２情報の受信に基づき、安否確認に関する第１表示が表示部に表示され、安否確認の受付が終了している場合、その第１表示に対する、端末のユーザによる入力に基づいて、安否確認の受付が終了していることに関する情報を端末に送信することで、安否確認の受付が終了していることを端末のユーザに知らせることができる。
＜第７変形例（１）＞
　上記の実施例では、安否確認登録受付期間終了処理において安否確認処理や安否登録リクエスト処理を終了させると判定した場合、サーバ１０の制御部１１は、それ以後に安否確認登録情報や安否登録リクエスト要求情報を受信すると、安否確認登録受付期間終了情報を返信する例を例示したが、これに限定されない。
　限定ではなく例として、サーバ１０の制御部１１は、第１の災害情報に対する安否確認登録受付期間が終了している場合、第２の災害情報が送信する場合には、第２の災害情報に対する安否確認登録を受け付けるようにしてもよい。
　図７－３は、本変形におけるアカウント管理データベース１５５の一例であるアカウント管理データベース１５５Ｂのデータ構成例である。
　アカウント管理データベース１５５Ｂには、アカウントごとの管理データとして、アカウント管理データが記憶される。
　各々のアカウント管理データには、限定ではなく例として、アプリケーションＩＤと、友だち管理データと、安否登録データとが記憶される。
　アプリケーションＩＤと、友だち管理データとは、限定ではなく例として、アカウント管理データベース１５５Ａと同様に構成することができる。
　安否登録データは、このアプリケーションＩＤのアカウントに関連付けられた、安否に関する登録を記憶させるためのデータであり、限定ではなく例として、災害ＩＤと、安否ステータス情報と、安否コメント情報と、安否位置情報とが関連付けて記憶される。
　災害ＩＤは、発生した災害、あるいは発生した災害と対応する災害情報を識別するための情報である。この災害ＩＤは、好ましくは災害（災害情報）ごとに一意な値であり、限定ではなく例として、サーバ１０によって災害（災害情報）ごとに一意な値（固有の値）が設定されて記憶される。
　安否ステータス情報と、安否コメント情報と、安否位置情報とは、限定ではなく例として、安否登録アカウントの端末２０によって入力される安否確認登録情報に基づいて、設定され、記憶される。なお、安否ステータス情報と、安否コメント情報と、安否位置情報とのうち、任意の要素を省略するようにしてもよい。
　図７－４は、本実施例において端末２０Ｂの表示部２４に表示されるメッセージングアプリケーションの画面の一例を示す図である。
　図７－４左側の画面では、ＯＡアカウントからの「２０ＸＸ年８月４日９時３９分」に発生した地震（限定ではなく、第１災害の一例）による安否登録を停止することを示す安否登録停止確認コンテンツＳＣＴ１の下に、ＯＡアカウントからの「２０ＸＸ年８月１４日１９時２３分」に地震（限定ではなく、第２災害の一例）が発生したことを示す災害発生コンテンツＤＣＴ２が表示されている。限定ではなく例として、安否登録リクエストコンテンツＲＣＴ８内の回答ボタンＢＴ４ｂがタップされると、図７－４中央のような表示がなされる。
　具体的には、第１災害について安否確認登録受付期間（安否登録期間）は終了しているが、第２災害について安否登録を行うことは可能であり、安否登録を行うか否かを確認するための安否登録確認情報ＲＣＩ１が、画面中央部にポップアップ形式で表示されている。この情報に含まれる「ＯＫ」ボタンがタップされ、ホーム画面に表示を戻すと、図７－４右側のような表示がなされる。
　このホーム画面では、第２災害の発生に関する情報が表示されている。
　また、安否登録を行うための安否登録領域Ｒ１がホーム画面の下部からせり上がるように表示されている。この安否登録領域Ｒ１の構成例については、前述した通りであるため、説明を省略する。
　図７－５は、限定ではなく例として、本実施例における各装置が実行する処理のタイミングの一例を示すタイミングチャートである。
　まず、サーバ１０の制御部１１は、限定ではなく例として、サーバ１０のユーザによる入力操作に基づいて、第１災害における安否確認処理や安否登録リクエスト処理を開始させるための第１災害安否確認登録受付処理を実行する（タイミング「ＴＭ１００５」）。第１災害安否確認登録受付処理において、サーバ１０の制御部１１は、第１災害と紐付けるための災害ＩＤを生成する。なお、第１災害安否確認登録受付処理に伴い、サーバ１０の制御部１１は、各端末２０に第１の災害情報を送信するようにしてもよい。また、第１の災害情報に第１災害と紐付けられた災害ＩＤを含めるようにしてもよい。
　なお、サーバ１０の制御部１１は、不図示の災害情報サーバから受信した災害状況情報に基づいて、第１災害安否確認登録受付処理を実行するようにしてもよい。
　次いで、限定ではなく例として、端末２０Ｙにおいて端末２０Ｘに対する安否登録リクエスト要求操作が行われると、第１の安否登録リクエスト要求情報がサーバ１０に送信される（タイミング「ＴＭ１０１０」）。
　すると、サーバ１０の制御部１１は、初期送信設定条件が成立していると判定し、第１の安否登録リクエスト情報を端末２０Ｘに送信する（タイミング「ＴＭ１０１５」）。
　端末２０Ｘの制御部２１は、第１の安否登録リクエスト情報を受信すると、第１の安否登録リクエスト情報を表示部２４に表示させる（タイミング「ＴＭ１０２０」）。
　次いで、サーバ１０の制御部１１は、第１災害における安否確認登録受付期間終了処理を実行する（タイミング「ＴＭ１０２５」）。
　その後、サーバ１０の制御部１１は、第２災害における安否確認処理や安否登録リクエスト処理を開始させるための第２災害安否確認登録受付処理を実行する（タイミング「ＴＭ１０３０」）。なお、第２災害安否確認登録受付処理に伴い、サーバ１０の制御部１１は、各端末２０に第２の災害情報を送信するようにしてもよい。また、第２の災害情報に第２災害と紐付けられた災害ＩＤを含めるようにしてもよい。
　その後、端末２０Ｘにおいて、限定ではなく例として、第１の安否登録リクエスト情報に対する入力操作に基づいて、安否確認登録情報を受け付けると、第１の安否確認登録情報がサーバ１０に送信される（タイミング「ＴＭ１０３５」）。そして、サーバ１０は第１の安否確認登録情報を受信する（タイミング「ＴＭ１０４０」）。なお、第１の安否確認登録情報に、第１災害と紐付けられた災害ＩＤを含めるようにしてもよい。
　なお、端末２０Ｙにおいて安否登録リクエスト要求操作が実行され、端末２０Ｘが第１の安否登録リクエスト情報を受信することは必須ではない。
　サーバ１０の制御部１１は、タイミング「ＴＭ１０２５」において第１災害における安否確認処理や安否登録リクエスト処理を終了させると判定し、タイミング「ＴＭ１０２５」以降に第１災害と紐付けられた災害ＩＤを含む安否確認登録情報を受信した場合（限定ではなく例として、タイミング「ＴＭ１０４０」）、第１災害における安否確認登録の受け付けを終了したことを示す第１災害安否確認登録受付期間終了情報を通信Ｉ／Ｆ１４によって安否登録アカウントの端末２０Ｘに送信する（タイミング「ＴＭ１０４５」）。
　また、サーバ１０の制御部１１は、限定ではなく例として、第１災害安否確認登録受付期間終了情報を送信すると、第２災害安否確認登録受付処理が実行されている場合、第２災害に対する安否確認登録を受け付けていることを示す第２災害安否確認登録受付開始情報を安否登録アカウントの端末２０Ｘに送信する（タイミング「ＴＭ１０５０」）。なお、第２災害安否確認登録受付開始情報に、第２災害と紐付けられた災害ＩＤを含めるようにしてもよい。
　端末２０Ｘの制御部２１は、サーバ１０から第１災害安否確認登録受付期間終了情報を受信すると、受信した第１災害安否確認登録受付期間終了情報を表示部２４に表示させる（タイミング「ＴＭ１０５５」）。
　また、端末２０Ｘの制御部２１は、サーバ１０から第２災害安否確認登録受付開始情報を受信すると、受信した第２災害安否確認登録受付開始情報を表示部２４に表示させる（ＴＭ１０５０）。
　ここで、第２災害安否確認登録受付開始情報は、第１災害とは異なる新たな安否確認登録が始まったことを示す情報でもよいし、第２災害情報を含む第２災害に対する安否確認登録の受け付け表示に関する情報でもよい。
　なお、サーバ１０の制御部１１は、タイミング「ＴＭ１０２５」において第１災害における安否確認処理や安否登録リクエスト処理を終了させると判定し、タイミング「ＴＭ１０２５」以降に第１災害と紐付けられた安否登録リクエスト要求情報を受信した場合、第１災害安否確認登録受付期間終了情報を安否登録要求アカウントの端末２０に送信するようにしてもよい。
　また、サーバ１０の制御部１１は、タイミング「ＴＭ１０３０」以降に安否登録リクエスト要求情報を受信した場合、第２災害に対する安否登録リクエスト要求を被安否登録要求アカウントの端末２０に送信するようにしてもよい。
　なお、サーバ１０の制御部１１は、第１災害における安否確認登録受付期間終了処理において第１災害における安否確認処理や安否登録リクエスト処理を終了させると判定する場合、端末２０から安否確認登録情報を受信せずとも、各端末２０に第１災害安否確認登録受付期間終了情報を送信するようにしてもよい。
　この場合、端末２０Ｘの制御部２１は、第１災害安否確認登録受付期間終了情報を受信すると、第１災害に対する安否確認登録を受け付けないように制御するようにしてもよい。
　なお、サーバ１０の制御部１１は、第１の安否確認登録情報に災害ＩＤが含まれていない場合、第１の安否確認登録情報を受信したタイミングがタイミング「ＴＭ１０２５」以降かつタイミング「ＴＭ１０３０」以前である場合、第１災害安否確認登録受付期間終了情報を安否登録アカウントの端末２０Ｘに送信するようにしてもよい。
　また、第１の安否確認登録情報に災害ＩＤが含まれず、第１の安否確認登録情報を受信したタイミングがタイミング「ＴＭ１０２５」以降かつタイミング「ＴＭ１０３０」以降である場合、サーバ１０の制御部１１は、受信した第１の安否確認登録情報に基づいて、第２災害に対する安否情報を生成し、各端末２０に送信するようにしてもよい。
　なお、サーバ１０の制御部１１は、限定ではなく例として、タイミング「ＴＭ１０３０」以降に、端末２０Ｘから第１災害における安否登録リクエスト要求ユーザ情報要求情報を受信する場合、第１災害安否確認登録受付期間終了情報と第２災害安否確認登録受付開始情報とを端末２０Ｘに送信するようにしてもよい。
　本変形例は、被安否登録アカウントの端末２０において、一の災害（限定ではなく、第１災害の一例）の安否登録リクエスト要求情報（限定ではなく、第１情報の一例）に基づく安否登録リクエスト情報（限定ではなく、第２情報の一例）の受信に基づき、その一の災害について、前述した第１表示が表示部２４に表示される。そして、サーバ１０は、一の災害の安否確認登録受付期間（限定ではなく、第１災害の安否確認の受付の一例）が終了し、別の災害（限定ではなく、第２災害の一例）の安否確認登録受付期間（限定ではなく、第２災害の安否確認の受付の一例）が開始されている場合、その第１表示に対する、その被安否登録要求アカウントのユーザによる入力に基づいて、第１災害安否確認登録受付期間終了情報（限定ではなく、第１災害の安否確認の受付が終了していることに関する情報の一例）と、第２災害安否確認登録受付開始情報（限定ではなく、第２災害の安否確認の受付が開始されていることに関する情報の一例）とを通信Ｉ／Ｆ１４によって被安否登録要求アカウントのユーザの端末２０に送信する構成を示している。
　このような構成により得られる実施例の効果の一例として、端末で、第１災害の第１情報に基づく第２情報の受信に基づき、安否確認に関する第１表示が表示部に表示され、第１災害の安否確認の受付が終了し、第２災害の安否確認の受付が開始されている場合、その第１表示に対する、端末のユーザによる入力に基づいて、第１災害の安否確認の受付が終了していることに関する情報と、第２災害の安否確認の受付が開始されていることに関する情報とを端末に送信することで、第１災害の安否確認の受付が終了していることと、第２災害の安否確認の受付が開始されていることとを端末のユーザに知らせることができる。
　また、本変形例は、被安否登録要求アカウントの端末２０において、安否登録リクエスト情報（限定ではなく、第２情報の一例）の受信に基づき、前述した第１表示が表示部２４に表示される。そして、サーバ１０は、安否確認登録受付期間（限定ではなく、安否確認の受付の一例）が終了している場合、その第１表示に対する入力を受け付けないことを示す情報を通信Ｉ／Ｆ１４によって被安否登録要求アカウントの端末２０に送信する構成を示している。
　このような構成により得られる実施例の効果の一例として、端末で、第２情報の受信に基づき、安否確認に関する第１表示が表示部に表示され、安否確認の受付が終了している場合、その第１表示に対する入力を不可にするための情報を端末に送信することで、第１表示に対する入力を受け付けないようにすることができる。
＜第７変形例（２）＞
　上記の実施例では、端末２０Ｘのユーザは、安否確認登録情報を送信する前に安否確認登録受付期間が終了しているか否かを知ることができなかったが、これに限定されない。限定ではなく例として、安否登録リクエスト情報に安否登録期間（安否登録が可能な期間）や安否登録期限（安否登録の終期））に関する情報を含めるようにしてもよい。
　なお、これらの情報は、前述した第１表示を表示部２４に表示する表示期間に関する情報（表示期限に関する情報）としてもよい。また、前述した第１表示から安否確認の回答（安否登録）を行うための入力が可能な入力期間に関する情報（入力期限に関する情報）としてもよい。
　図７－６左側は、本変形例において端末２０Ｂの表示部２４に表示されるメッセージングアプリケーションの画面の一例を示す図である。
　この画面では、トーク領域における安否登録リクエストコンテンツＲＣＴ９内に、安否確認の回答を行うことが可能な回答期間に関する情報として、回答期限までの残り時間の情報を含む回答ボタンＢＴ４ｃが設けられている。
　この例では、「９時４１分」に安否登録が停止されることとしている。そして、その時刻までの残り時間が表示されている。安否の回答をせずに「９：４１」になると、図７－６右側のような表示がなされる。
　この例では、安否登録リクエストコンテンツＲＣＴ９の下に、ＯＡアカウントからの「２０ＸＸ年８月４日９時３９分」に発生した地震による安否登録を停止することを示す安否登録停止確認コンテンツＳＣＴ１が表示されている。また、安否登録リクエストコンテンツＲＣＴ９の回答ボタンＢＴ４ｃの中の回答期間に関する情報の表示が消去されるとともに、回答ボタンＢＴ４ｃがグレーアウトして表示されており、回答ボタンＢＴ４ｃをタップしても安否を回答することができないようになっている。
　端末２０Ｘの制御部２１は、安否登録リクエスト情報に含まれる安否登録期間や安否登録期限が過ぎた場合、限定ではなく例として、安否登録リクエスト情報に対する入力に基づいて、安否確認登録情報の入力を受け付けないようにすることができる。
　本変形例は、安否登録リクエスト情報（限定ではなく、第２情報の一例）は、安否登録期間や安否登録期限等に関する情報を含む。そして、被安否登録要求アカウントの端末２０では、この安否登録リクエスト情報（限定ではなく、第２情報の一例）の受信に基づき、前述した第１表示が表示部２４に表示される構成を示している。
　このような構成により得られる実施例の効果の一例として、端末で、第１表示が端末の表示部に表示される有効期限に関する情報、または、第１表示に対する入力が可能な有効期限に関する情報を含む第２情報の受信に基づき、安否確認に関する第１表示が表示されて、端末のユーザがその第１表示を確認できるようにすることができる。
＜第７変形例（３）＞
　上記の実施例では、サーバ１０において一の災害に対する安否確認登録の受付是非を判定したが、これに限定されない。限定ではなく例として、各端末２０において、安否確認登録や安否登録リクエスト要求の受付是非を判定できるようにしてもよい。
　この場合、限定ではなく例として、サーバ１０の制御部１１は、災害情報にその災害に対する安否確認登録の受付期限に関する情報を含め、各端末２０に送信する。そして、各端末２０の制御部２１は、受信した安否確認登録の受付期限に関する情報に基づいて、安否確認登録操作または安否登録リクエスト要求操作時に、安否確認登録情報または安否登録リクエスト要求を受け付けるか否かを判定するようにできる。
　限定ではなく例として、各端末２０の制御部２１は、受付期限を過ぎている場合、安否確認登録情報または安否登録リクエスト要求の送信を受け付けないようにすることができる。
＜第７変形例（４）＞
　安否登録期間や安否登録期限が経過しても、登録済みの安否情報が、安否参照アカウントの端末２０に表示されるようにしてもよいし、表示されないようにしてもよい。
＜第８実施例＞
　第８実施例は、安否確認サービスにおけるメンバーまたはメッセージングアプリケーションにおける友だちのブロックに関する実施例である。
　以下では、ブロック対象とされるユーザアカウントを「ブロック対象アカウント」、ブロック対象アカウントから送信されるコンテンツをブロックするユーザアカウントを「ブロック実行アカウント」と称する。
　第８実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
　また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
＜表示画面＞
　図８－１は、本実施例における端末２０の表示部２４に表示されるメッセージングアプリケーションの画面の一例を示す図である。
　図８－１左側は、端末２０Ｂの表示部２４に表示されるメッセージングアプリケーションのホーム画面であり、安否登録領域Ｒ１において危険ボタンＤＢＴがタップされ、安否メッセージ「怪我しちゃった」と、現在の居場所「つくば市」とが入力されて、登録ボタンＢＴ３がタップされた状態が示されている。
　図８－１中央は、この場合に端末２０Ａの表示部２４に表示されるメッセージングアプリケーションのトークリスト画面である。ユーザＡ．ＡはユーザＢ．Ｂにブロックされておらず、トークリストのユーザＢ．Ｂの項目には、第２危険アイコンＤＩＣ２が重畳されたユーザＢ．Ｂのアイコン画像、ユーザ名に加えて、前述した複合安否情報「つくば／怪我しちゃった」が表示されている。
　一方、図８－１右側は、この場合に端末２０Ｇの表示部２４に表示されるメッセージングアプリケーションのトークリスト画面である。ユーザＧ．ＧはユーザＢ．Ｂにブロックされており、図８－１中央の端末２０Ａの画面とは異なり、トークリストのユーザＢ．Ｂの項目には、第２危険アイコンＤＩＣ２が重畳されたユーザＢ．Ｂのアイコン画像、ユーザ名しか表示されていない。つまり、前述した複合安否情報「つくば／怪我しちゃった」は表示されておらず、「危険」であることはわかるが、安否メッセージや居場所はわからないようになっている。
　なお、ブロックされたユーザの端末２０において、安否位置情報と安否コメント情報とを両方とも表示させないようにするのではなく、いずれか一方の情報は表示させるようにしてもよい。
＜処理＞
　図８－２は、限定ではなく例として、本実施例において各装置が実行する処理のタイミングの一例を示すタイミングチャートである。
　この図では、左側から順に、端末２０Ｘの制御部２１が実行する処理、端末２０Ｙの制御部２１が実行する処理、サーバ１０の制御部１１が実行する処理の一例を示している。
　ここでは、表示画面とは異なり、
　・ブロック対象アカウント＝端末２０ＹのユーザＹ．Ｙのアカウント＝表示画面における端末２０ＡのユーザＡ．Ａ
　・ブロック実行アカウント＝端末２０ＸのユーザＸ．Ｘのアカウント＝表示画面における端末２０ＢのユーザＢ．Ｂ
　とする場合の処理を例示する。
　限定ではなく例として、端末２０Ｘの制御部２１は、ユーザ操作に基づいて、ブロック対象アカウント（この場合、端末２０Ｙのアカウント）からのコンテンツをブロックさせるためのブロック要求情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する（タイミング「ＴＭ１１０５」）。ブロック要求情報には、端末２０ＹのアプリケーションＩＤを含めるようにしてもよい。
　通信Ｉ／Ｆ１４によって端末２０Ｘからブロック要求情報を受信すると、サーバ１０の制御部１１は、ブロック処理を実行する（タイミング「ＴＭ１１１０」）。サーバ１０の制御部１１は、ブロック処理の実行後、限定ではなく例として、チャット処理において、端末２０Ｙから端末２０Ｘに対するメッセージ送信依頼情報を受信する場合、端末２０Ｘにメッセージ送信依頼情報に基づくメッセージ情報を送信しない。
　次いで、限定ではなく例として、端末２０Ｙにおいて端末２０Ｘに対する安否登録リクエスト要求操作が行われると、第１の安否登録リクエスト要求情報がサーバ１０に送信される（タイミング「ＴＭ１１１５」）。
　すると、サーバ１０の制御部１１は、初期送信設定条件が成立していると判定し、第１の安否登録リクエスト情報を端末２０Ｘに送信する（タイミング「ＴＭ１１２０」）。
　端末２０Ｘの制御部２１は、第１の安否登録リクエスト情報を受信すると、第１の安否登録リクエスト情報を表示部２４に表示させる（タイミング「ＴＭ１１２５」）。
　なお、サーバ１０の制御部１１は、ブロック対象アカウントの端末２０Ｙからブロック実行アカウントの端末２０Ｘへの安否登録リクエスト要求情報を受信する場合、安否登録リクエスト情報をブロック実行アカウントの端末２０Ｘに送信しないようにしてもよい。
　端末２０Ｘの制御部２１は、限定ではなく例として、第１の安否登録リクエスト情報における第２表示に対する入力操作に基づいて、限定ではなく例として、安否ステータス情報を受け付け、受け付けた第１の安否ステータス情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する（タイミング「ＴＭ１１３０」）。
　また、端末２０Ｘの制御部２１は、限定ではなく例として、第１の安否登録リクエスト情報における第３表示に対する入力操作に基づいて、限定ではなく例として、安否コメント情報を受け付け、受け付けた第１の安否コメント情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する（タイミング「ＴＭ１１３５」）。
　なお、画面図で例示したように、第２表示と第３表示とを同じ表示画面内に含むことに限定されない。限定ではなく例として、端末２０Ｘの制御部２１は、第２表示に対する入力操作を実行すると、第３表示を表示部２４に表示させ、第３表示に対する入力操作を受け付けるようにしてもよい。
　サーバ１０の制御部１１は、端末２０Ｘから第１の安否ステータス情報と、第１の安否コメント情報とを受信する。そして、サーバ１０の制御部１１は、第１の安否ステータス情報のみを含む第１の安否情報をブロック対象アカウントの端末２０Ｙに送信する（タイミング「ＴＭ１１４０」）。
　また、サーバ１０の制御部１１は、第１の安否ステータス情報と、第１の安否コメント情報とを含む第１の安否情報をブロック対象アカウント以外の各端末２０に送信する（タイミング「ＴＭ１１５０」）。
　端末２０Ｙの制御部２１は、サーバ１０から第１の安否ステータス情報のみを含む第１の安否情報を受信すると、受信した第１の安否情報を表示部２４に表示させる（タイミング「ＴＭ１１４５」）。
　なお、第２表示と第３表示とにおいて受け付ける安否確認登録情報の組み合わせは、上記の組み合わせに限定されない。
　ここで、第２表示に対して入力される安否登録情報を「第１安否情報」、第３表示に対して入力される安否登録情報を「第２安否情報」と称する。ブロック実行アカウントの端末２０において、第１安否情報と第２安否情報とが入力されると、ブロック対象アカウントの端末２０には、第１安否情報のみを含む安否情報が送信される。また、ブロック対象アカウント以外の各端末２０には、第１安否情報と第２安否情報とを含む安否情報が送信される。
　なお、ブロック対象アカウントの端末２０に、第１安否情報と第２安否情報とを含む安否情報が送信されるようにしてもよい。
　図８－３は、第１安否情報と第２安否情報との組み合わせを示す表である。
　ここでは、限定ではなく例として、安否登録情報の構成要素を安否ステータス情報と安否コメント情報と安否位置情報として例示するが、他の構成要素が加わる場合にも同様にして第１安否情報と第２安否情報とを定めることができる。
　限定ではなく例として、図８－１の例は、パターン（Ｃ）の場合に相当する。
　パターン（Ａ）～（Ｃ）では、ブロック対象アカウントの端末２０において、安否ステータス情報は表示されるが、安否コメント情報と安否位置情報とは表示されない。しかし、安否確認登録入力において、安否コメント情報や安否位置情報の入力は安否ステータス情報の入力に比べて手間がかかるため、安否登録アカウントのユーザは安否ステータス情報のみを入力し、安否コメント情報や安否位置情報の入力を省略することが大いに考え得る。そのため、ブロック対象アカウントの端末２０において、安否ステータス情報のみが表示される場合、ブロック対象アカウントのユーザからは安否コメント情報や安否位置情報が表示されていないのか、それともそもそも入力されていないのかを区別することができない。従って、ブロック対象アカウントのユーザは、ブロック実行アカウントのユーザからブロックされていることを認知することが困難である。
　なお、サーバ１０の制御部１１は、ブロック実行アカウントの端末２０Ｘから安否確認登録情報を受信する場合、受信した安否確認登録情報に基づく安否確認情報をブロック対象アカウントの端末２０Ｙに送信しないようにしてもよい。
＜第８実施例の効果＞
　本実施例は、被安否登録要求アカウントの端末２０において、安否登録リクエスト情報（限定ではなく、第２情報の一例）の受信に基づき、前述した第１表示が表示部２４に表示され、この第１表示に対する入力に基づいて、第２表示と、第２表示とは異なる第３表示とが表示部２４に表示される。サーバ１０は、被安否登録要求アカウントの端末２０に表示された第２表示に対する入力に基づいて、被安否登録要求アカウントの端末２０のユーザによって入力された一の安否情報（限定ではなく、第１安否情報の一例）を通信Ｉ／Ｆ１４によって受信し、第３表示に対する入力に基づいて、被安否登録要求アカウントの端末２０のユーザによって入力された別の安否情報（限定ではなく、第２安否情報の一例）を通信Ｉ／Ｆ１４によって受信する。そして、サーバ１０は、被安否登録要求アカウントのユーザによって友だち登録されているなどの被安否登録要求アカウントのユーザに関連付けられたユーザ（限定ではなく、端末のユーザに関連付けられたユーザの一例）の端末２０に一の安否情報（第１安否情報）を送信する一方、被安否登録要求アカウントのユーザによって設定されたユーザの端末２０に他の安否情報（第２安否情報）を送信する構成を示している。
　このような構成により得られる実施例の効果の一例として、端末で、第２情報の受信に基づき、安否確認に関する第１表示が表示され、その第１表示に対する入力に基づいて、第２表示と、第２表示とは異なる第３表示とが表示される。そして、第２表示に対する入力に基づいて、端末のユーザによって入力された安否に関する第１安否情報を端末から受信し、第３表示に対する入力に基づいて、端末のユーザによって入力された安否に関する第２安否情報を受信することができる。また、端末のユーザに関連付けられたユーザに第１安否情報を送信して、端末のユーザの安否を知らせることができる。また、端末のユーザによって設定されたユーザに第２安否情報を送信して、端末のユーザの安否を知らせることができる。
　また、この場合、被安否登録要求アカウントのユーザによって設定されたユーザは、被安否登録要求アカウントのユーザによって友だち登録されているなどの被安否登録要求アカウントのユーザに関連付けられたユーザのうち、被安否登録要求アカウントのユーザによってブロックされたユーザ以外のユーザを含むようにすることができる。
　このような構成により得られる実施例の効果の一例として、上記の端末のユーザによって設定されたユーザに、端末のユーザに関連付けられたユーザのうち端末のユーザによってブロックされたユーザ以外のユーザが含まれるようにすることで、端末のユーザによってブロックされたユーザ以外のユーザには第２安否情報を送信するようにすることができる。
＜第８変形例（１）＞
　上記の実施例では、ブロック対象アカウントの端末２０には、第１安否情報のみを含む安否情報が送信され、ブロック対象アカウント以外の各端末２０には、第１安否情報と第２安否情報とを含む安否情報が送信されることとしたが、これに限定されない。限定ではなく例として、各端末２０には、第１安否情報と第２安否情報とを含む安否情報が送信されるが、ブロック対象アカウントの端末２０では、第１安否情報のみが表示されるようにしてもよい。
　この場合、限定ではなく例として、サーバ１０の制御部１１は、ブロック実行アカウントの端末２０Ｘからブロック要求情報を受信すると、ブロック対象アカウントの端末２０Ｙに、ブロック実行アカウントの情報（限定ではなく例として、アプリケーションＩＤ）を含む安否表示ブロック要請情報を送信する。
　ブロック対象アカウントの端末２０Ｙの制御部２１は限定ではなく例として、安否表示ブロック要請情報を受信した後にブロック実行アカウントを安否登録アカウントとし、第１安否情報と第２安否情報とを含む安否情報を受信する場合、第１安否情報のみを表示部２４に表示させる。
＜第９実施例＞
　第９実施例は、安否確認サービスにおけるメンバーまたはメッセージングアプリケーションにおける友だちの安否確認登録状況を簡易に閲覧可能とする実施例である。
　第９実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
　また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
＜表示画面＞
　図９－１は、本実施例において端末２０Ｂの表示部２４に表示されるメッセージングアプリケーションの画面の一例を示す図である。
　図９－１左側は、前述したメッセージングアプリケーションのＯＡアカウントとのトーク画面であり、この例では、ＯＡからの安否登録リクエストコンテンツＲＣＴ１がタップされた状態が示されている。この場合、図９－１右側のホーム画面が表示される。
　このホーム画面は、メッセージングアプリケーションのホーム画面であり、友だちリストの項目として、ユーザＡ．Ａに対応したアイコンおよびユーザ名、ユーザＤ．Ｄに対応したアイコンおよびユーザ名、ユーザＦ．Ｆに対応したアイコンおよびユーザ名、ユーザＧ．Ｇに対応したアイコンおよびユーザ名等が表示されている。また、各々のユーザのアイコンには、そのユーザによって登録された安否情報を示すアイコンとして、前述した第１安全アイコン、第１危険アイコン、第１不明アイコンが関連付けて表示されている。つまり、安否確認登録状況の一覧画面が表示されている。
　さらに、この例では、ユーザＢ．Ｂが安否登録を未だ行っていないことに基づいて、安否登録ボタンＢＴ１が強調表示（限定ではなく例として、点滅表示）されている。
　なお、上記のように友だちリストの画面に遷移させるのではなく、トークリスト画面に遷移させてもよく、安否確認登録状況の一覧が表示される画面に遷移させればよい。
＜第９変形例（１）＞
　上記の実施例では、安否登録リクエスト情報に対するユーザ操作に基づいて、安否確認登録状況の一覧画面に遷移したが、これに限定されない。限定ではなく例として、安否確認アプリケーションまたはメッセージングアプリケーションのプッシュ通知に対するユーザ操作に基づいて、安否確認登録画面に遷移するようにしてもよい。
・スマートチャット領域内に安否登録リクエスト情報を表示（タップで安否確認登録画面に遷移可能）
・アプリプッシュで安否登録リクエスト情報から安否確認登録画面に遷移
　図９－２は、本変形例において端末２０Ｂの表示部２４に表示される画面の一例を示す図である。
　図９－２左側は、端末２０Ｂの表示部２４に表示されるメッセージングアプリケーションのトークリスト画面であり、アプリ内位置表示領域の下の、災害が発生したことをトークリスト画面において報知するための災害情報表示領域の内部の右下には、ユーザＢ．Ｂが未だ安否登録を行っていないため安否登録ボタンＢＴ１が表示されている。
　また、その下には、ユーザＢ．Ｂに対して安否登録リクエストを行ったユーザのアイコンおよびユーザ名が一覧表示されている。
　端末２０Ｂが操作されずに一定時間が経過すると、図９－２中央のようなロック画面が表示される。この例では、ロック画面にアプリプッシュとして、メッセージングアプリケーションを発信元とする安否登録リクエスト情報のプッシュ通知ＰＮ７が表示されている。このプッシュ通知ＰＮ７がタップされると、限定ではなく例として、図９－２右側のメッセージングアプリケーションのホーム画面が表示される。
　このホーム画面では、画面下部からせり上がるように安否登録領域Ｒ１が表示されており、安否登録をそのまますぐに行うことができるように構成されている。
　なお、図９－２左側の画面における、安否登録リクエストを行っているユーザの一覧が表示される領域（この例では４名のユーザ）がタップされると、図９－２右側のホーム画面が表示されるようにしてもよい。
　また、限定ではなく例として、安否登録リクエスト情報を、任意のトークルーム画面の最上部に表示させるようにしてもよい。そして、最上部に表示される安否登録リクエスト情報に対するユーザ操作に基づいて、安否確認登録画面に遷移できるようにしてもよい。
＜他の実施例＞
＜他の実施例（１）＞
　上記の実施例では、安否登録アカウントにより入力される安否確認登録情報を、安否確認アプリケーションまたはメッセージングアプリケーションのユーザに対する安否情報の送信のために使用したが、これに限定されない。限定ではなく例として、サーバ１０の制御部１１は、各端末２０より受信した安否確認登録情報を集計処理し、集計結果を救援活動のためのビッグデータとして用いるようにしてもよい。
　限定ではなく例として、サーバ１０の制御部１１は、各端末２０より受信した安否ステータス情報と安否位置情報とを集計し、安否ステータス情報が「危険」と入力された地域の偏りを求める。そして、サーバ１０の制御部１１は、「危険」と入力された頻度が高い地域に関する位置情報である救助対象エリア情報を算出する。サーバ１０の制御部１１は、算出された救助対象エリア情報を表示部１３に表示させるようにしてもよい。
　なお、サーバ１０の制御部１１は、算出された救助対象エリア情報を通信Ｉ／Ｆ１４によって不図示の災害対策本部サーバに送信するようにしてもよい。
＜他の実施例（２）＞
　上記の実施例では、被安否登録要求アカウントの端末２０に対して安否確認登録情報の入力と送信とを促すために安否登録リクエスト要求情報を送信する例について例示したが、これに限定されない。より一般的に、サーバ１０の制御部１１は、任意の情報の入力と送信とを促すためのリクエスト情報を送信するようにしてもよい。
　限定ではなく例として、リクエスト情報として、借金の返済を促す要求例（以下、「要望」と称する。）について例示する。
　また、以下では、借金の返済を迫られるユーザのアカウントを「被要望要求アカウント」、被要望要求アカウントに対して借金の返済を求めるユーザのアカウントを「要望要求アカウント」と称する。ここで、要望要求アカウントは複数のアカウントとし、限定ではなく例として、「第１の要望要求アカウント」と「第２の要望要求アカウント」と称する。
　第１の要望要求アカウントの端末２０は、限定ではなく例として、ユーザ操作に基づいて、被要望要求アカウントに対して要望を伝えるための第１の要望要求情報をサーバ１０に送信する。
　サーバ１０の制御部１１は、第１の要望要求アカウントの端末２０から第１の要望要求情報を受信すると、設定条件（複合設定条件）が成立しているか否かを判定する。そして、設定条件（複合設定条件）が成立していると判定する場合、サーバ１０の制御部１１は、第１の要望要求情報に基づく第１の要望情報（この例では借金の返済を促すことに関する情報）を被要望要求アカウントの端末２０に送信する。
　被要望要求アカウントの端末２０の制御部２１は、受信した第１の要望情報を表示部２４に表示させる。
　次いで、第２の要望要求アカウントの端末２０は、限定ではなく例として、ユーザ操作に基づいて、被要望要求アカウントに対して要望を伝えるための第２の要望要求情報をサーバ１０に送信する。
　サーバ１０の制御部１１は、第２の要望要求アカウントの端末２０から第２の要望要求情報を受信すると、設定条件（複合設定条件）が成立しているか否かを判定する。そして、設定条件（複合設定条件）が成立していると判定する場合、サーバ１０の制御部１１は、第２の要望要求情報に基づく第２の要望情報を被要望要求アカウントの端末２０に送信する。被要望要求アカウントの端末２０の制御部２１は、受信した第２の要望情報を表示部２４に表示させる。
　設定条件（複合設定条件）が成立しているないと判定する場合、サーバ１０の制御部１１は、第２の要望要求情報に基づく第２の要望情報を被要望要求アカウントの端末２０に送信しない。
　すなわち、複数のアカウントを含む要望要求アカウントが一の被要望要求アカウントに対して任意の要望を通達する場合、限定ではなく例として、以下の対応関係を当てはめることができる。
・「安否登録リクエスト要求情報」＝「要望要求情報」
・「安否登録リクエスト情報」＝「要望情報」
・「被安否登録要求アカウント」＝「被要望要求アカウント」
・「安否登録要求アカウント」＝「要望要求アカウント」
　この場合、任意のタイミングにおける要望要求情報に基づく要望情報送信の有無は、限定ではなく例として、第５実施例の複合設定条件による制御と同様に制御することができる。すなわち、上記の実施例を参酌すると、初めて一の被要望要求アカウントに対する安否登録リクエスト要求情報を受信する場合、サーバ１０は被要望要求アカウントの端末２０に要望情報を送信する。そしてサーバ１０はそれ以後にその被要望要求アカウントに対する安否登録リクエスト要求情報を受信する場合、再度被要望要求アカウントの端末２０に要望情報を送信しないといった制御が実現可能である。また、サーバ１０は、被要望要求アカウントに対する安否登録リクエスト要求情報を受信する場合、所定の条件を満たす場合、リマインドとして再度被要望要求アカウントの端末２０に要望情報を送信するといった制御も可能である。
　なお、要望要求アカウントの端末２０は、被要望要求アカウントの端末２０に対する任意のコンテンツの送信要求（「コンテンツ送信要求情報」と称する。）をサーバ１０に送信するようにしてもよい。サーバ１０の制御部１１は、コンテンツ送信要求情報を受信すると、複合設定条件に基づいて、要望要求アカウントの端末２０にコンテンツ送信要求情報に基づくコンテンツ情報を送信するか否かの制御を実行するようにしてもよい。
　本実施例は、被要望要求アカウントの端末２０（限定ではなく、端末の一例）と通信するサーバ１０が、被要望要求アカウントの端末２０のユーザに対するコンテンツの送信の依頼に関する情報（限定ではなく、コンテンツの送信の依頼に関する第１情報の一例）を、一の要望要求アカウントの端末２０（限定ではなく、第１端末の一例）から受信する。そして、サーバ１０は、受信したコンテンツの送信の依頼に関する情報に基づき、コンテンツに関する情報を、通信I／F１４によって被要望要求アカウントの端末２０に送信する。
　また、サーバ１０は、被要望要求アカウントの端末２０のユーザに対するコンテンツの送信の依頼に関する情報（限定ではなく、コンテンツの送信の依頼に関する第１情報の一例）を、他の要望要求アカウントの端末２０（限定ではなく、第２端末の一例）から受信する。そして、サーバ１０は、受信したコンテンツの送信の依頼に関する情報と、設定された条件とに基づき、コンテンツに関する情報を、通信I／Ｆ１４によって被要望要求アカウントの端末２０に送信する構成を示している。
　このような構成により得られる実施例の効果の一例として、端末のユーザに対するコンテンツの送信の依頼に関する第１情報を第１端末から受信した上で、その第１情報に基づき、コンテンツに関する第２情報を端末に送信することで、限定ではなく例として、コンテンツを送信するように端末のユーザに促すことができる。また、端末のユーザに対するコンテンツの送信の依頼に関する第１情報を第２端末から受信した上で、その第１情報と設定された条件とに基づき、コンテンツに関する第２情報を端末に送信することで、限定ではなく例として、コンテンツを送信するように端末のユーザに促すことができる。
＜その他＞
　上記の実施例や変形例で説明した、メッセージングアプリケーション（メッセージングサービス）で実現した内容は、基本的に、第５実施例で説明した安否確認アプリケーション（安否確認サービス）についても同様に適用可能である。
１　　　　　　　通信システム
　１０　　　　　サーバ
　２０　　　　　端末
　３０　　　　　ネットワーク

Claims (40)

  1. 　第１端末のユーザとのチャットに関連する処理を行う端末によって実行されるプログラムであって、
    　前記第１端末のユーザによる前記第１端末に対する入力に基づいて、前記第１端末のユーザの安否に関する第１情報を前記端末の通信部によって受信することと、
    　前記第１端末のユーザに関連する前記チャットの情報に関連付けられた前記第１情報を前記端末の表示部に表示することとが前記端末によって実行される。
  2. 　請求項１に記載のプログラムであって、
    　前記第１端末のユーザによって、前記第１端末のユーザの安否に関する前記第１情報が第２情報に変更された場合、前記第２情報を前記通信部によって受信することが前記端末によって実行される。
  3. 　請求項２に記載のプログラムであって、
    　前記第２情報は、前記第１端末のユーザと前記端末のユーザとを含む第１チャットルームに表示される。
  4. 　請求項３に記載のプログラムであって、
    　前記第１情報を前記通信部によって受信した後、前記第１チャットルームを前記表示部に表示した場合、前記第２情報を前記通信部によって受信することが前記端末によって実行される。
  5. 　請求項２または請求項３に記載のプログラムであって、
    　前記第１端末のユーザの情報を前記表示部に表示した場合、前記第２情報を前記通信部によって受信することが前記端末によって実行される。
  6. 　請求項５に記載のプログラムであって、
    　前記第１端末のユーザの情報は、前記第１端末のユーザの安否に関連する前記第１情報を含む、前記第１端末のユーザのステータスに関する情報を含む。
  7. 　請求項２または請求項３に記載のプログラムであって、
    　前記第２情報は、前記第１端末のユーザと、前記端末のユーザとの関係に基づいて送信される。
  8. 　請求項１から請求項７のいずれか一項に記載のプログラムであって、
    　前記チャットの情報は、前記第１端末のユーザと前記端末のユーザとを含む第１チャットルームに関する情報を含む。
  9. 　請求項８に記載のプログラムであって、
    　前記チャットの情報は、前記端末のユーザが含まれるチャットルームのリストに含まれる前記第１チャットルームに関する情報を含む。
  10. 　請求項９に記載のプログラムであって、
    　前記第１情報に基づいて、前記第１チャットルームに関する情報の表示態様を変更する制御を前記端末の制御部によって行うことが前記端末によって実行される。
  11. 　請求項１０に記載のプログラムであって、
    　前記第１情報を含む、前記第１チャットルームに含まれるユーザの安否に関する情報に基づいて、前記第１チャットルームに関する情報の表示態様を変更する制御を前記制御部によって行うことが前記端末によって実行される。
  12. 　請求項８に記載のプログラムであって、
    　前記第１情報は、前記第１チャットルームに表示される。
  13. 　請求項１２に記載のプログラムであって、
    　前記第１情報は、前記第１端末のユーザによって設定された第１画像と関連づけられて前記第１チャットルームに表示される。
  14. 　請求項１から請求項７のいずれか一項に記載のプログラムであって、
    　前記チャットの情報は、前記チャットで、前記端末のユーザに関連付けられたユーザのリストに含まれる。
  15. 　請求項１から請求項１４のいずれか一項に記載のプログラムであって、
    　前記端末のユーザによる前記端末に対する入力に基づいて、前記端末のユーザの安否に関する第３情報を前記通信部によって送信することが前記端末によって実行される。
  16. 　請求項１５に記載のプログラムであって、
    　前記第３情報の送信に基づいて、前記チャットの自動応答に関する情報を前記表示部に表示することと、
    　前記自動応答に関する情報に対する、前記端末のユーザによる入力に基づいて、前記チャットの自動応答に関する処理を前記端末の制御部によって行うことが前記端末によって実行される。
  17. 　請求項１から請求項１６のいずれか一項に記載のプログラムであって、
    　前記端末の状態に基づいて、前記チャットの自動応答に関する情報を前記表示部に表示することと、
    　前記自動応答に関する情報に対する、前記端末のユーザによる入力に基づいて、前記チャットの自動応答に関する処理を前記端末の制御部によって行うことが前記端末によって実行される。
  18. 　請求項１から請求項１７のいずれか一項に記載のプログラムであって、
    　前記第１情報をサーバを介して前記通信部によって受信することが前記端末によって実行される。
  19. 　第１端末のユーザとのチャットに関連する処理を行う端末の情報処理方法であって、
    　前記第１端末のユーザによる前記第１端末に対する入力に基づいて、前記第１端末のユーザの安否に関する第１情報を前記端末の通信部によって受信することと、
    　前記第１端末のユーザに関連する前記チャットの情報に関連付けられた前記第１情報を前記端末の表示部に表示することとを含む。
  20. 　第１端末のユーザとのチャットに関連する処理を行う端末であって、
    　前記第１端末のユーザによる前記第１端末に対する入力に基づいて、前記第１端末のユーザの安否に関する第１情報を受信する通信部と、
    　前記第１端末のユーザに関連する前記チャットの情報に関連付けられた前記第１情報を表示する表示部とを備える。
  21. 　第１端末のユーザとのチャットに関連する処理を行う端末であって、
    　メモリに記憶されたプログラムを読み出し、前記プログラムに基づく処理を実行するプロセッサーを備え、
    　前記プロセッサーは、
    　前記第１端末のユーザによる前記第１端末に対する入力に基づいて、前記第１端末のユーザの安否に関する第１情報を前記端末の通信部によって受信することと、
    　前記第１端末のユーザに関連する前記チャットの情報に関連付けられた前記第１情報を前記端末の表示部に表示することとを実行する。
  22. 　端末と通信するサーバによって実行されるプログラムであって、
    　前記端末のユーザに対する安否確認の依頼に関する第１情報を前記サーバの通信部によって第１端末から受信することと、
    　前記第１情報と設定された条件とに基づき、前記安否確認に関する第２情報を前記通信部によって前記端末に送信することとが前記サーバによって実行される。
  23. 　請求項２２に記載のプログラムであって、
    　前記設定された条件は、前記端末のユーザに対する前記第１情報を前記サーバが最初に受信した場合、前記第２情報を前記端末に送信し、前記端末のユーザに対する前記第１情報を最初に受信した後、第１設定条件に基づいて前記第２情報を前記端末に送信する条件を含む。
  24. 　請求項２３に記載のプログラムであって、
    　前記第１設定条件は、設定された時刻、または設定された時間に基づいて前記第２情報を前記端末に送信する条件を含む。
  25. 　請求項２３または請求項２４に記載のプログラムであって、
    　前記第１設定条件は、最初に前記第１情報を受信した後、前記サーバが受信した第１情報の数に基づいて前記第２情報を前記端末に送信する条件を含む。
  26. 　請求項２３から請求項２５のいずれか一項に記載のプログラムであって、
    　前記第１設定条件は、災害に関する情報に基づいて前記第２情報を前記端末に送信する条件を含む。
  27. 　請求項２３から請求項２６のいずれか一項に記載のプログラムであって、
    　前記第２情報の送信に基づき、前記端末のユーザの安否に関する情報を含む第３情報を前記端末から前記通信部によって受信することと、
    　前記第３情報の受信に基づいて、前記第３情報の受信の後に前記端末のユーザに対する前記第１情報を受信した場合、前記第１情報に基づく前記第２情報の送信を行わない制御を前記サーバの制御部によって行うこととが前記サーバによって実行される。
  28. 　請求項２２から請求項２７のいずれか一項に記載のプログラムであって、
    　前記端末は、前記第２情報の受信に基づき、前記安否確認に関する第１表示を前記端末の表示部に表示し、
    　前記第１表示に対する、前記端末のユーザによる入力に基づいて、前記第１情報を送信したユーザの情報を前記端末に前記通信部によって送信することが前記サーバによって実行される。
  29. 　請求項２８に記載のプログラムであって、
    　前記第１端末から送信された前記端末のユーザに対する前記第１情報の受信に基づき、前記第２情報を前記通信部によって前記端末に送信することと、
    　前記端末のユーザに対する前記第１情報を前記第１端末から受信した後、前記端末のユーザに対する前記第１情報を第２端末から前記サーバの通信部によって受信することと、
    　前記設定された条件を満たさない場合、前記第２端末から受信した前記第１情報に基づく前記第２情報を前記端末に送信しない制御を前記サーバの制御部によって行うことと、
    　前記第１表示に対する、前記端末のユーザによる入力に基づいて、前記第１情報を送信した、前記第１端末のユーザの情報と、前記第２端末のユーザの情報とを含む前記ユーザの情報を前記通信部によって前記端末に送信することとが前記サーバによって実行される。
  30. 　請求項２２から請求項２９のいずれか一項に記載のプログラムであって、
    　前記端末は、前記第２情報の受信に基づき、前記安否確認に関する第１表示を前記端末の表示部に表示し、
    　前記安否確認の受付が終了している場合、前記第１表示に対する、前記端末のユーザによる入力に基づいて、前記安否確認の受付が終了していることに関する情報を前記通信部によって前記端末に送信することが前記サーバによって実行される。
  31. 　請求項３０に記載のプログラムであって、
    　前記端末は、第１災害の前記第１情報に基づく前記第２情報の受信に基づき、前記安否確認に関する第１表示を前記端末の表示部に表示し、
    　前記第１災害の前記安否確認の受付が終了し、第２災害の前記安否確認の受付が開始されている場合、前記第１表示に対する、前記端末のユーザによる入力に基づいて、前記第１災害の前記安否確認の受付が終了していることに関する情報と、前記第２災害の前記安否確認の受付が開始されていることに関する情報とを前記通信部によって前記端末に送信することが前記サーバによって実行される。
  32. 　請求項２２から請求項２９のいずれか一項に記載のプログラムであって、
    　前記端末は、前記第２情報の受信に基づき、前記安否確認に関する第１表示を前記端末の表示部に表示し、
    　前記安否確認の受付が終了している場合、前記第１表示に対する入力を不可にするための情報を前記通信部によって前記端末に送信することが前記サーバによって実行される。
  33. 　請求項２２から請求項２９のいずれか一項に記載のプログラムであって、
    　前記端末は、前記第２情報の受信に基づき、前記安否確認に関する第１表示を前記端末の表示部に表示し、
    　前記第２情報は、前記第１表示が前記端末の表示部に表示される有効期限に関する情報、または、前記第１表示に対する入力が可能な有効期限に関する情報を含み、
    　前記端末は、前記第２情報の受信に基づき、前記安否確認に関する第１表示を前記端末の表示部に表示する。
  34. 　請求項２２から請求項３３のいずれか一項に記載のプログラムであって、
    　前記端末は、前記第２情報の受信に基づき、前記安否確認に関する第１表示を前記端末の表示部に表示し、前記第１表示に対する入力に基づいて、第２表示と、前記第２表示とは異なる第３表示とが前記端末の表示部に表示され、
    　前記第２表示に対する入力に基づいて、前記端末のユーザによって入力された第１安否情報を前記通信部によって前記端末から受信し、前記第３表示に対する入力に基づいて、前記端末のユーザによって入力された安否に関する第２安否情報を前記通信部によって前記端末から受信することと、
    　前記端末のユーザに関連付けられたユーザに前記第１安否情報を前記通信部によって送信し、前記端末のユーザによって設定されたユーザに前記第２安否情報を前記通信部によって送信することとが前記サーバによって実行される。
  35. 　請求項３４に記載のプログラムであって、
    　前記設定されたユーザは、前記端末のユーザに関連付けられたユーザのうち、前記端末のユーザによってブロックされたユーザ以外のユーザを含む。
  36. 　請求項２２から請求項３５のいずれか一項に記載のプログラムであって、
    　前記第２情報は、前記端末のユーザを含むチャットルームに表示される。
  37. 　端末と通信するサーバの情報処理方法であって、
    　前記端末のユーザに対する安否確認の依頼に関する第１情報を前記サーバの通信部によって第１端末から受信することと、
    　前記第１情報と設定された条件とに基づき、前記安否確認に関する第２情報を前記通信部によって前記端末に送信することとを含む。
  38. 　端末と通信するサーバであって、
    　前記端末のユーザに対する安否確認の依頼に関する第１情報を第１端末から受信し、前記第１情報と設定された条件とに基づき、前記安否確認に関する第２情報を前記端末に送信する通信部を備える。
  39. 　端末と通信するサーバであって、
    　メモリに記憶されたプログラムを読み出し、前記プログラムに基づく処理を実行するプロセッサーを備え、
    　前記プロセッサーは、
    　前記端末のユーザに対する安否確認の依頼に関する第１情報を前記サーバの通信部によって第１端末から受信することと、
    　前記第１情報と設定された条件とに基づき、前記安否確認に関する第２情報を前記通信部によって前記端末に送信することとを実行する。
  40. 　端末と通信するサーバによって実行されるプログラムであって、
    　前記端末のユーザに対するコンテンツの送信の依頼に関する第１情報を第１端末から前記サーバの通信部によって受信することと、
    　前記第１情報に基づき、前記コンテンツに関する第２情報を前記端末に前記通信部によって送信することと、
    　前記端末のユーザに対する前記第１情報を第２端末から前記サーバの通信部によって受信することと、
    　前記第１情報と前記設定された条件とに基づき、前記第２情報を前記端末に前記通信部によって送信することとが前記サーバによって実行される。
PCT/JP2022/034991 2021-10-28 2022-09-20 プログラム、情報処理方法、端末、サーバ WO2023074192A1 (ja)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
JP2021176907A JP7354207B2 (ja) 2021-10-28 2021-10-28 プログラム、情報処理方法、端末
JP2021176908A JP7273124B1 (ja) 2021-10-28 2021-10-28 プログラム、情報処理方法、サーバ
JP2021-176907 2021-10-28
JP2021-176908 2021-10-28

Publications (1)

Publication Number Publication Date
WO2023074192A1 true WO2023074192A1 (ja) 2023-05-04

Family

ID=86159752

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/034991 WO2023074192A1 (ja) 2021-10-28 2022-09-20 プログラム、情報処理方法、端末、サーバ

Country Status (1)

Country Link
WO (1) WO2023074192A1 (ja)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003331090A (ja) * 2002-05-10 2003-11-21 Dai-Ichi Life Information System Co Ltd 情報収集システム及び情報収集方法
JP2016153979A (ja) * 2015-02-20 2016-08-25 株式会社日立国際八木ソリューションズ 安否確認システム
JP2016192800A (ja) * 2016-07-13 2016-11-10 日本アイラック株式会社 安否確認アプリケーション
JP2018151724A (ja) * 2017-03-10 2018-09-27 株式会社サテライトオフィス チャットシステム、プログラム
JP2020048093A (ja) * 2018-09-20 2020-03-26 株式会社 ゼネテック 情報送信システム、及び位置情報サーバー

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003331090A (ja) * 2002-05-10 2003-11-21 Dai-Ichi Life Information System Co Ltd 情報収集システム及び情報収集方法
JP2016153979A (ja) * 2015-02-20 2016-08-25 株式会社日立国際八木ソリューションズ 安否確認システム
JP2016192800A (ja) * 2016-07-13 2016-11-10 日本アイラック株式会社 安否確認アプリケーション
JP2018151724A (ja) * 2017-03-10 2018-09-27 株式会社サテライトオフィス チャットシステム、プログラム
JP2020048093A (ja) * 2018-09-20 2020-03-26 株式会社 ゼネテック 情報送信システム、及び位置情報サーバー

Similar Documents

Publication Publication Date Title
US10341838B2 (en) Method to provide ad hoc and password protected digital and voice networks
US10171390B2 (en) System and method for alerting a list of multiple recipients of a user's request for assistance
JP4981931B2 (ja) ロケーションベースの緊急通報
US20170150335A1 (en) Text message sender location and psap determination systems and methods
US8611935B2 (en) System and method for providing alerts to members of defined local geographical groups
US8364129B1 (en) Method to provide ad hoc and password protected digital and voice networks
US20210352461A1 (en) Method to provide ad hoc and password protected digital and voice networks
US9432810B2 (en) Opt-in and time limited bi-directional real-time location sharing
KR20160147546A (ko) 산업용 통신 장치를 제어하는 전자 장치, 방법, 및 그 산업용 통신 장치
US20170280304A1 (en) Terminal, Server, System, Management Method And Medium
KR102207713B1 (ko) 사용자의 상태 정보 공유 방법 및 이를 위한 장치
JP5397720B1 (ja) プログラム、情報処理端末、及び情報処理方法
KR102052735B1 (ko) 사용자의 상태 정보 공유 방법 및 이를 위한 장치
KR20170038807A (ko) 인스턴트 메시징 그룹 설문 기법
JP7273124B1 (ja) プログラム、情報処理方法、サーバ
WO2023074192A1 (ja) プログラム、情報処理方法、端末、サーバ
JP7354207B2 (ja) プログラム、情報処理方法、端末
US20220150682A1 (en) Method to provide ad hoc and password protected digital and voice networks
KR20170070679A (ko) 일대일 프로필을 설정하는 방법 및 시스템
KR102252755B1 (ko) 안심만남 서비스 제공방법 및 이를 수행하는 안심만남 서비스 제공서버
JP2019029918A (ja) 緊急通報システム
TWI524723B (zh) Methods and systems for emergency self - help notification
KR20220091209A (ko) 그룹 액티비티 서비스 제공 방법 및 장치
TW200845714A (en) Automatic help-seeking method by mobile communication device
WO2018144907A1 (en) Text message sender location and psap determination systems and methods

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22886526

Country of ref document: EP

Kind code of ref document: A1