Patent Description:
If a failure occurs at equipment connected to a network or at a network itself, it is necessary to call a candidate who is required to handle the failure and instruct the candidate to appropriately handle the failure. In related art, such calling of a candidate for a person who is to handle a failure is performed via a public telephone network as disclosed in PTL <NUM>.

However, a problem with the method disclosed in PTL <NUM> is that a failure handling candidate is called via a public telephone network, and thus, one line is required to call one person at one time.

The present disclosure has been made in view of the above-described point, and describes the invention in accordance to the appended claims.

Embodiments of the present disclosure will be described below with reference to the drawings. The same or similar reference numerals will be assigned to the same or similar components in the drawings, and overlapping description regarding the same or similar components will be omitted in description of the respective embodiments. Further, features described in each embodiment can be applied to other embodiments unless they are inconsistent with each other. However, the embodiments of the present disclosure are not necessarily limited to such aspects. It would be obvious for a person skilled in the art that the embodiments of the present disclosure can take various aspects incorporated in a scope defined in the claims.

The embodiments of the present disclosure will be specifically described below. <FIG> is a view schematically illustrating a configuration of a calling support system <NUM> according to one embodiment of the present disclosure. The calling support system <NUM> is a system which supports calling of a candidate for handling a failure upon occurrence of a failure. It is assumed in the present disclosure that the failure includes every failure, hamper, interference, trouble, or the like, which requires claims management or other emergency handling as well as a failure, a fault, or the like, of a system which emergently requires to call persons in charge having expertise, knowledge, or the like. Specific examples of a case where emergency handling is required other than a case of a failure of a system can include a case where a senior person who is authorized to judge disaster control measures is to be called upon occurrence of a disaster, and a case where a doctor having expertise in a surgery is to be urgently called when an emergency surgery is performed at a hospital. Note that the embodiments will be described below using an example of a failure of a system. First, outline will be described. The calling support system <NUM> includes a server <NUM> which supports calling, and one or more clients <NUM> which are called by the server <NUM> via the Internet <NUM>. Note that clients 200a, 200b and 200c, which are illustrated as the client <NUM> in <FIG>, will be collectively referred to as the client <NUM> in the following description.

First, a monitoring system <NUM> is a system which generates an emergency calling request of requesting handling of a failure upon detection of the failure at an apparatus under monitoring (not illustrated) which is to be monitored by the monitoring system <NUM> and transmits the emergency calling request to the server <NUM>. This monitoring system <NUM> may include, for example, one or a plurality of monitoring terminals <NUM> as an example. As an example, in a case where the monitoring terminal <NUM> detects that communication with a server under monitoring is disconnected, the monitoring terminal <NUM> creates a message of "communication with an apparatus under monitoring is disconnected" and generates an emergency calling request on the basis of this message. Further, while the monitoring system <NUM> automatically transmits the emergency calling request in the above-described example, this emergency calling request may be manually transmitted. For example, an operator who accepts a failure may operate an operator terminal (not illustrated) to transmit the emergency calling request. As an example, if the operator receives a message of "we have received a request for examination from our customer, please respond to the request" from a customer, the operator generates and transmits a corresponding emergency calling request.

The server <NUM> within the calling support system <NUM> may be provided as cloud or may be provided at a local location such as a building and a site of a system user. Further, the server <NUM> may be constituted with one apparatus or may be constituted with a plurality of apparatuses. The server <NUM> is connected to the monitoring system <NUM> via the Internet <NUM> and receives the above-described emergency calling request from the monitoring system <NUM>. Note that while the monitoring system <NUM> is connected to the calling support server <NUM> via the Internet in this illustrated example, connection is not limited to this, and the monitoring system <NUM> may be connected to the calling support server <NUM> via an Internet protocol (IP) network such as the Internet, a LAN and a WAN or may be directly connected if the monitoring system <NUM> is connected to the calling support server <NUM> so as to be able to perform communication with each other. The server <NUM> determines a call-target person list <NUM> including candidates for a person who is to handle the failure as call-target persons on the basis of information included in the received emergency calling request, selects a specific call-target person from the determined call-target person list <NUM> and calls the client <NUM> of the selected call-target person via the Internet <NUM>.

The client <NUM> can be connected to the Internet <NUM> via a base station of communication carrier or via a wireless LAN access point of Wi-Fi (registered trademark), or the like. The client <NUM> is a mobile terminal including a display on which a touch panel is disposed, and is, for example, a smartphone or a tablet terminal. Application for supporting calling of failure handling candidates is installed at each client <NUM>.

<FIG> is a block diagram illustrating an example of respective functions of the server <NUM> and the client <NUM> for implementing various kinds of processing in the calling support system <NUM> according to one embodiment of the present disclosure. The server <NUM> includes a processor <NUM> and a memory <NUM> as main components.

The processor <NUM> executes a series of commands included in a program stored in the memory <NUM> on the basis of a signal provided to the server <NUM> or on the basis that a condition determined in advance is satisfied. In a certain aspect, the processor <NUM> is implemented as a device such as a central processing unit (CPU) and a micro processor unit (MPU). Components included in the processor <NUM> are merely one example of functions to be executed by the processor <NUM> which are expressed as specific modules. Functions of a plurality of components may be implemented with a single component. The processor <NUM> may execute functions of all the components. <FIG> illustrates functions to be executed by the processor <NUM>. The processor <NUM> includes but not limited to, for example, a notification transmission unit <NUM>, a response reception unit <NUM>, an answer reception unit <NUM>, and a calling control unit <NUM>. Detailed operation of a method to be performed by the response reception unit <NUM>, the answer reception unit <NUM> and the calling control unit <NUM> will be respectively described later using <FIG>, <FIG> and <FIG>. The notification transmission unit <NUM> transmits various push notifications to the client <NUM>. The response reception unit <NUM> receives a response result in response to calling from the client <NUM>. The answer reception unit <NUM> receives an answer result from the client <NUM> with respect to an emergency calling request. The calling control unit <NUM> performs emergency calling processing of selecting a call-target person from the call-target person list <NUM> on the basis of priority and calling the call-target person and determines whether to finish the emergency calling processing. An update data transmission unit <NUM> transmits a status database <NUM> including history, or the like, of a calling result of each client <NUM>, which is updated on the basis of a response result and an answer result transmitted from the client <NUM>, to the client <NUM>.

The memory <NUM> stores a program and data. The memory <NUM> is utilized as a work area which temporarily stores a processing result of the processor. The memory <NUM> may include an arbitrary non-transitory storage medium such as a semiconductor storage medium and a magnetic storage medium. The memory <NUM> may include combination of a portable storage medium such as a memory card, an optical disk or a magnetooptical disk and a reader of the storage medium. The memory <NUM> may include a storage device to be utilized as a temporal storage area such as a random access memory (RAM).

The memory <NUM> can be constituted to store various kinds of information. As an example, the memory <NUM> may include a control program <NUM>, a failure handling candidate group table <NUM>, the above-described call-target person list <NUM>, the status database <NUM> and other pieces of data. The control program <NUM> can include an operating system of the server <NUM>, a program, or the like, for transmitting and receiving various kinds of information to and from the client <NUM>. <FIG> illustrates the failure handling candidate group table <NUM> in which all failure handling candidate group IDs and one or more failure handling candidates corresponding to the respective failure handling candidate group IDs are recorded in association with each other. The failure handling candidate may be associated with a plurality of failure handling candidate group IDs. One or more failure handling candidates associated with the failure handling candidate group IDs in the failure handling candidate group table <NUM> are call-target persons, and the call-target person list <NUM> is constituted with extracted one or more call-target persons. The status database <NUM> records a calling state, or the like, of each client <NUM> for the emergency calling request.

The client <NUM> includes a processor <NUM> and a memory <NUM> as main components in a similar manner to the server <NUM>. The client <NUM> is different from the server <NUM> in that the client <NUM> further includes a display unit <NUM>. Hereinafter, description overlapping with description of the configuration of the server <NUM> will be omitted.

As illustrated in <FIG>, the processor <NUM> includes but not limited to a notification reception unit <NUM>, a calling unit <NUM>, an answer acceptance unit <NUM>, a display control unit <NUM> and an update data reception unit <NUM> as an example. Detailed operation of a method to be performed by the notification reception unit <NUM>, the calling unit <NUM>, the answer acceptance unit <NUM> and the update data reception unit <NUM> will be respectively described later using <FIG>, <FIG>, <FIG> and <FIG>. The notification reception unit <NUM> receives various kinds of push notifications from the server <NUM>. The calling unit <NUM> instructs the display control unit <NUM> to display a calling screen and stop display of the calling screen in accordance with calling from the server <NUM>. Further, the calling unit <NUM> accepts operation of selecting response/rejection in response to the calling from the call-target person and transmits a response result to the server <NUM>. The answer acceptance unit <NUM> accepts operation of selecting whether or not the call-target person can respond to the emergency calling request and transmits an answer result to the server. The display control unit <NUM> controls transition of various screens to be displayed at the display unit <NUM> of the client <NUM>. <FIG> illustrates an example of flow of screen transition control to be performed by the display control unit <NUM>. The update data reception unit <NUM> receives various kinds of updated data transmitted from the server <NUM>, for example, the updated status database <NUM>.

The memory <NUM> can be constituted to store various kinds of information. As an example, the memory <NUM> includes the updated status database <NUM> received from the server. The memory <NUM> may further include various kinds of data necessary for computation to provide various kinds of images accepted from the display control unit <NUM> to the display unit <NUM>.

The display unit <NUM> is implemented with a liquid crystal display, an organic electroluminescence (EL) display, or the like, and a touch panel is disposed on the display. The display unit <NUM> displays information such as characters, figures and images in accordance with a signal input from the processor <NUM>. Information to be displayed at the display unit <NUM> includes a screen for making a notification of an emergency calling start message (screen a in <FIG> which will be described later), a calling screen (screen b in <FIG>), a terminal home screen (screen c in <FIG>), an application home screen (screens d1 and d2 in <FIG>), a screen for making a notification of a detailed status such as a calling result of each call-target person in response to the emergency calling request (screens e and f in <FIG>), a screen for making a notification of an emergency calling end message (screen p in <FIG>), or the like.

The embodiments of the present disclosure will be more specifically described below. A case of supporting calling of a target person who maintains a system to handle a failure upon occurrence of the failure of the system is assumed as a specific example to which the embodiments of the present disclosure can be applied. However, the embodiments of the present disclosure are not necessarily limited to such an aspect. It would be obvious for a person skilled in the art that the embodiments of the present disclosure can take various aspects incorporated in the scope defined in the claims.

<FIG> is a view schematically explaining processing of a method <NUM> for supporting calling to be executed at the server <NUM> in the calling support system <NUM> according to one embodiment of the present disclosure. The method <NUM> indicates flow of processing to be performed by the server <NUM>, from when the server <NUM> receives an emergency calling request from the monitoring system <NUM> and registers an emergency calling ID which uniquely identifies the emergency calling request and information of the emergency calling request in the status database until when the server <NUM> makes a notification of start of emergency calling processing of respective clients <NUM> of call-target persons and then makes a notification of end of the emergency calling processing to the respective clients <NUM>. In a case where the number of call-target persons which can handle the failure does not satisfy the required number, the server <NUM> automatically calls clients <NUM> of the call-target persons on the next highest priority from the call-target person list <NUM>. The emergency calling processing of calling the clients <NUM> of the call-target persons on the basis of the priority in this manner is executed by the processing from step <NUM> to <NUM> being repeated until an end condition is satisfied.

The processing is started in step <NUM>. As an example, the control program <NUM> is read out from the memory <NUM> and executed by the processor <NUM>, so that the calling support system <NUM> can be used. Further, various kinds of parameters (such as the current number of persons r who can handle the failure and the current number of times of repetition q which will be described later) are initialized.

In step <NUM>, the server <NUM> receives the emergency calling request from the monitoring system <NUM>. The emergency calling request includes a message indicating details of the failure, and information which can uniquely specify the failure handling candidate group. The server <NUM> specifies the failure handling candidate group ID from the information included in the emergency calling request and reads out failure handling candidates 0000A. json (call-target person list) associated with the failure handling candidate group ID from the failure handling candidate group table <NUM>. <FIG> illustrates a display example of the call-target person list <NUM>. In this example, the call-target person list <NUM> includes five call-target persons. The call-target person list <NUM> is constituted with failure handling candidate group name (in <FIG>, group A), name of one or more call-target persons associated with the failure handling candidate group name (in <FIG>, five people of Ren Sato, Minato Suzuki, Hiroto Takahashi, Yamato Tanaka and Hinato Watanabe) and priority of calling of the respective call-target persons (in <FIG>, Ren Sato has the first priority). The name of the call-target persons is respectively associated with identifiers of the clients <NUM> carried by the respective call-target persons.

In step <NUM>, the server <NUM> (the notification transmission unit <NUM> in <FIG>) makes a notification of emergency calling start by transmitting an emergency calling start message, for example, a message of "emergency calling is being executed in group A", an emergency calling ID corresponding to the emergency calling request, and a notification type to all clients <NUM> of the call-target persons in the call-target person list <NUM> via the Internet <NUM>. Flow of notification of the emergency calling start message will be described in detail using <FIG>. Further, in step <NUM>, the server <NUM> stores time at which the notification of the emergency calling start message is made in the memory <NUM> as emergency calling start time ets.

In step <NUM>, the server <NUM> (the calling control unit <NUM> in <FIG>) selects (one or more) call-target persons to be called at the same time from the call-target person list <NUM> (<FIG>). As an example, the call-target persons to be called at the same time can be selected in descending order or in ascending order of the priority.

In step <NUM>, the server <NUM> (the notification transmission unit <NUM> in <FIG>) calls the clients <NUM> of the selected one or more call-target persons to be called at the same time via the Internet <NUM>. According to the present disclosure, the clients <NUM> are called via the Internet <NUM>, and thus, even if fixed lines corresponding to the number of clients to be called at the same time are not provided, it is possible to call a plurality of clients <NUM> at the same time. Thus, even in a case where a large-scale disaster occurs, a number of candidates for a person who can handle a failure of a social infrastructure can be called at the same time, so that it is possible to promptly handle the failure.

The client <NUM> (the calling unit <NUM> in <FIG>) which is called transmits a response result in response to the calling to the server <NUM>. The response result is a result of operation of selecting response or rejection by the call-target person in response to the calling from the server <NUM>. Note that such selection operation may be operation of selecting "response" or "rejection" by speech of the call-target person, operation of selecting "response" through slide operation on the touch panel by the call-target person or operation of selecting a response button or a rejection button displayed on the touch panel.

In step <NUM>, the server <NUM> (the response reception unit <NUM> in <FIG>) stores the response result in response to the calling, received from the client <NUM> (the calling unit <NUM> in <FIG>) in the memory <NUM>. The processing at the server <NUM> corresponding to step <NUM> and step <NUM> will be described in detail in a method 600A in <FIG>, and the processing at the client <NUM> corresponding to step <NUM> and <NUM> will be described in detail in a method 600B in <FIG>.

Thereafter, the client <NUM> (the display unit <NUM> in <FIG>) displays detail information regarding the failure received from the server <NUM>. The client <NUM> (the answer acceptance unit <NUM> in <FIG>) transmits an answer result of the call-target person, which indicates whether or not the call-target person can handle the failure, to the server <NUM>. The answer result includes a result of operation of selecting "available" or "unavailable" by the call-target person with respect to the detail information of the failure from the server <NUM>.

In step <NUM>, the server <NUM> (the answer reception unit <NUM> in <FIG>) stores the answer result received from the client <NUM> (the answer acceptance unit <NUM> in <FIG>) in the memory. The processing at the server <NUM> corresponding to step <NUM> will be described in detail in a method 700A in <FIG>, and the processing at the client <NUM> corresponding to step <NUM> will be described in detail in a method 700B in <FIG>.

In step <NUM>, the server <NUM> (the notification transmission unit <NUM> in <FIG>) transmits an emergency calling end message, for example, a message of "emergency calling in group A is completed", the emergency calling ID, and a notification type to all the clients <NUM> of the call-target persons in the call-target person list <NUM> via the Internet <NUM>. Flow of notification of the emergency calling end message will be described in detail in <FIG>. Further, in step <NUM>, the server <NUM> stores time at which the notification of the emergency calling end message is made in the memory <NUM> as emergency calling end time ete.

The server <NUM> (the calling control unit <NUM> in <FIG>) performs emergency calling processing of repeating the processing from step <NUM> to step <NUM> until the end condition is satisfied. This enables the server <NUM> to secure the required number R of call-target persons who can handle the failure.

Flow of emergency calling processing for securing call-target persons who can handle the failure in accordance with the priority will be described next with reference to <FIG>. The server <NUM> (the calling control unit <NUM>) performs emergency calling processing of calling the clients <NUM> of the call-target persons in accordance with the priority in accordance with the call-target person list <NUM> and finishes the emergency calling processing if the end condition is satisfied. As an example, the end condition of the emergency calling processing is that the number r of target persons who can handle the failure reaches the number R required to be called. Further, as another example, the end condition is that even if all target persons in the call-target person list <NUM> are called over the number of times of repetition Q, the number r of target persons who can handle the failure is less than the number R required to be called. It is assumed in initial setting that the current number r of target persons who can handle the failure is <NUM>, and the current number of times of repetition q is <NUM>.

<FIG> illustrates a table <NUM> indicating various kinds of parameters set in advance in the present disclosure, a table <NUM> indicating name of target persons who are sequentially called, and a table <NUM> indicating calling results of the called target persons.

The table <NUM> includes a maximum calling period S during which the client is continuously called, the number P of target persons to be called at the same time, the number of times of repetition Q which is the number of times of repetition of calling of all the target persons in the call-target person list <NUM>, and the required number R of target persons for handling the failure. By setting the number P of target persons to be called at the same time at equal to or larger than the number of target persons determined in the call-target person list <NUM>, it is also possible to call all the target persons within the list at the same time. Note that it is assumed in the following description that the maximum calling period S is set at <NUM> seconds, the number P of target persons to be called at the same time is set at <NUM>, the number of times of repetition Q is set at <NUM>, and the required number R of target persons for handling the failure is set at <NUM> in advance in the table <NUM>.

The table <NUM> indicates an example of call-target persons to be sequentially called for specific failure handling candidate group name (here, group A). In this example, the number of call-target persons is five. <NUM> enclosed with a dotted line in table <NUM> indicates the call-target person group with the highest priority upon initial calling. <NUM> indicates the first round of calling of all the target persons within the call-target person list <NUM>, and <NUM> indicates the second round of calling of all the target persons within the call-target person list <NUM>.

The table <NUM> indicates a calling period t which is one of a period from when calling of each call-target person is started until when an answer result ("available", "unavailable") is selected by each call-target person, or a maximum calling period S. In a case where operation of responding to or rejecting the calling by the call-target person is not detected even if the client <NUM> is called over the maximum calling period S, the calling period t becomes the maximum calling period S.

The emergency calling processing to be performed by the server <NUM> (the calling control unit <NUM> in <FIG>) will be described in detail below with reference to <FIG>.

The server <NUM> (the calling control unit <NUM>) selects call-target persons corresponding to the number of target persons to be called at the same time (here, three) from the call-target person list <NUM> in descending order of the priority (step <NUM> in <FIG>). The server <NUM> (the response reception unit <NUM>) first calls the selected call-target persons with the highest priority (all target persons in group <NUM>) at the same time (corresponding to step <NUM> in <FIG>). The called clients <NUM> transmit response results in response to the calling to the server <NUM>. The server <NUM> (the response reception unit <NUM>) updates the status database <NUM> on the basis of the received response results and stores the updated status database <NUM> in the memory <NUM> (corresponding to step <NUM> in <FIG>). Further, the clients <NUM> transmit answer results in response to the emergency calling request to the server <NUM>. The server <NUM> (the answer reception unit <NUM>) updates the status database <NUM> on the basis of the received answer results and stores the updated status database <NUM> in the memory <NUM> (corresponding to step <NUM> in <FIG>).

The server <NUM> (the calling control unit <NUM>) selects call-target persons on the basis of information extracted from the status database <NUM> read out from the memory <NUM>. A table <NUM> indicates an example of a table constituted with part of information extracted from a telephone call table 138B illustrated in <FIG> for explanation.

The table <NUM> indicates that the call-target person of "Ren Sato" with the first priority performs operation of "responding" to the calling in calling of the group <NUM> in the first round of calling <NUM> and answers that he is "available" on the failure <NUM> seconds after the calling is started, and the call-target person of "Minato Suzuki" with the second priority does not perform operation ("no operation") in response to the calling over the maximum calling period S seconds (for example, <NUM> seconds), and the call-target person of "Hiroto Takahashi" with the third priority performs operation of "responding" to the calling, but answers that he is "unavailable" on the failure <NUM> seconds after the calling is started. One person of "Ren Sato" answers that he is "available" on the failure, and thus, the server <NUM> (the calling control unit <NUM>) increments the current number r of target persons who can handle the failure by one.

The server <NUM> (the calling control unit <NUM>) determines whether to further select call-target persons by comparing the current number r of target persons who can handle the failure with the required number R and comparing the current number of times of repetition q with the number of times of repetition Q. In the table <NUM>, only one person of "Ren Sato" with the first priority answers that he is "available" on the failure in the calling of the group <NUM>, which is less than the required number R (two). Further, the current number of times of repetition is one, which is less than the number of times of repetition Q (ten). The current number of times of repetition is equal to or less than the number of times of repetition Q, and the number r of target persons who has answered "available" on the failure in response to calling for handling the failure is less than the required number R, and thus, the server <NUM> (the calling control unit <NUM>) determines call-target persons with the next priority with reference to the call-target person list <NUM>.

Note that the client <NUM> stops calling in a case where no operation is performed even if a period exceeding the maximum calling period S has elapsed, or the like. In a case where calling is stopped, the number of the clients <NUM> who are being called decreases by one. The server <NUM> (the calling control unit <NUM>) sequentially selects the call-target person of "Yamato Tanaka" with the fourth priority and the call-target person of "Hinato Watanabe" with the fifth priority so that the number to be called at the same time becomes the number P of target persons to be called at the same time. The server <NUM> calls the selected call-target persons and receives response results and answer results from the clients <NUM>.

The table <NUM> indicates that the call-target person of "Yamato Tanaka" with the fourth priority does not perform operation although the call-target person is called for the maximum calling period S seconds (<NUM> seconds), and the call-target person of "Hinato Watanabe" with the fifth priority responds to the calling, but answers that he is "unavailable" on the failure <NUM> seconds after the calling is started in the first round of calling <NUM>. At a time point at which the first round of calling <NUM> ends, although all the target persons within the call-target person list <NUM> are called, the number of target persons who have answered "available" on the failure (one) is still less than the required number R (two), and the current number of times of repetition q (one) is less than the number of times of repetition Q (ten). Thus, the server <NUM> performs the second round of calling <NUM>. The server <NUM> (the calling control unit <NUM>) calls all the call-target persons within the call-target person list <NUM>, and thus, increments the current number of times of repetition q by one. Note that the call-target person of "Ren Sato" with the first priority answers that he can handle the failure in the first round of calling, the call-target person of "Ren Sato" is not selected as call-target persons again. Instead of the target person with the first priority being called, the target person with the second priority is selected again.

In the second round of calling <NUM>, the call-target person of "Minato Suzuki" with the second priority selects "response" and answers that he is "available" on the failure. In the second round of calling <NUM>, the number of target persons reaches the required number R of two at a time point at which the target person with the second priority is called, and thus, calling is "successful" and the emergency calling processing is finished.

As described above, the server <NUM> (the calling control unit <NUM>) determines that the call-target persons who can handle the failure are successfully secured in a case where the current number of times of repetition q is equal to or less than a predetermined number of times of repetition Q (here, ten), and the current number of target persons r who can handle the failure is equal to or greater than the required number R, and finishes the emergency calling processing. Meanwhile, in a case where the number of target persons r who have answered "available" is less than the required number R although calling is performed over a predetermined number of times of repetition Q, the server <NUM> (the calling control unit <NUM>) determines that securing call-target persons who can handle the failure is failed, and finishes the emergency calling processing.

Note that in the above description, in a case where it is detected that operation is not performed (no operation) even if a period exceeding the maximum calling period S set in advance has elapsed, calling of the client <NUM> is stopped, and thus, the number of clients <NUM> which are being called decreases by one. Then, the server <NUM> (the calling control unit <NUM>) can immediately sequentially select the call-target persons with the next priority so that the number of target persons to be called at the same time becomes P (three) (as an example, the server <NUM> (the calling control unit <NUM>) selects the call-target person with the next priority in place of the call-target person of "Minato Suzuki" with the second priority immediately after calling is stopped as a result of "no operation" indicated in <NUM> in <FIG> so that the number of target persons to be called at the same time becomes three). However, as another example, in a case where an answer result in response to the calling of the client <NUM> is further received, that is, as an example, in a case where "Ren Sato" with the first priority for whom calling has been stopped as a result of response, selects an answer of "available", as indicated in <NUM> in <FIG>, the call-target person with the next priority is selected. In this manner, the server <NUM> (the calling control unit <NUM>) sequentially calls the call-target persons with the next priority after the calling period S has elapsed or after receiving the answer result ("available", "unavailable") from the client <NUM> so that the number of target persons to be called at the same time (three) is satisfied. In this manner, the server <NUM> can further more promptly secure the call-target persons who can respond to the emergency calling request.

Various kinds of processing to be executed in the calling support system <NUM> according to one embodiment of the present disclosure described above will be described in further detail next with reference to <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, <FIG> and <FIG>. For convenience of description of the respective drawings, screens (screens a to p) to be displayed at the display unit <NUM> of the client <NUM> illustrated from <FIG> will be described. Note that overlapping description regarding <FIG> will be omitted or simplified.

<FIG> is flow of processing of a method <NUM> to be executed at the server <NUM> and all the clients <NUM> in the calling support system <NUM> according to one embodiment of the present disclosure. The method <NUM> indicates flow of so-called push information distribution processing upon notification of a message, or the like, from the server <NUM> to the client <NUM> and corresponds to step <NUM> or step <NUM> in <FIG>. Examples of service which provides push information distribution can include "Google Cloud Messaging (GCM)" and "Apple Push Notification Service (APNS)".

In step <NUM>, the server <NUM> (the notification transmission unit <NUM>) transmits a push notification for making a notification of emergency calling start to all the clients <NUM> within the call-target person list <NUM> without being requested from the clients <NUM>. Note that when the client <NUM> receives a push notification which makes a notification of emergency calling start, in step <NUM>, application for supporting calling installed at the client <NUM> is started in the background (not illustrated).

Then, in step <NUM>, the client <NUM> requests notification content to the server <NUM>. In step <NUM>, the server <NUM> (the notification transmission unit <NUM>) which has received the request for the notification content transmits the notification content to all the clients <NUM> within the call-target person list <NUM>. The client <NUM> (the notification reception unit <NUM> in <FIG>) receives this notification content. The notification content includes a notification type for identifying the notification content, a message, and an emergency calling ID corresponding to the occurred emergency calling request. Upon notification of the emergency calling start, the notification type is, for example, "Notification", and the message is "emergency calling of group A is being executed" indicating emergency calling start. Further, upon notification of emergency calling end, the notification type is, for example, "Notification", and the message is "emergency calling of group A ends" indicating end of calling.

In step <NUM>, the client <NUM> (the display control unit <NUM> in <FIG>) generates an image including the received notification content, outputs the image at the display unit <NUM>, displays this image at the display unit <NUM>, and outputs notification sound or vibrates a terminal for a short period of time (for example, approximately several seconds). <FIG> illustrates an example of a screen a to be displayed by the client <NUM> upon emergency calling start, and <FIG> illustrates an example of a screen p to be displayed upon emergency calling end. As illustrated, the display unit <NUM> displays "emergency calling of group A is being executed" (<FIG>), or "emergency calling of group A is completed" (<FIG>). All the call-target persons of the clients <NUM> can grasp for which failure handling candidate group, emergency calling is started (or ends) by confirming the emergency calling start screen a (or the end screen p), so that the call-target persons can know status of start and end of emergency calling for each failure without performing operation of opening messages.

Flow of, particularly, processing of a method <NUM> to be executed on the server <NUM> side which receives, or the like, the response results from the clients <NUM> of the selected call-target persons and on the client <NUM> side selected for processing on the server <NUM> side among various kinds of processing to be executed on the server <NUM> side and the client <NUM> side of the calling support system <NUM> according to one embodiment of the present disclosure will be described next with reference to <FIG>. The method <NUM> illustrated in <FIG> substantially corresponds to the processing from step <NUM> to step <NUM> in <FIG>. Note that description will be provided below assuming that a failure occurs, and the call-target persons for handling the failure are selected.

In step <NUM>, the server <NUM> (the notification transmission unit <NUM> in <FIG>) transmits a push notification to the selected clients <NUM> and records time at which the push notification is transmitted in the status database <NUM> as the calling start time cts. The client <NUM> (the notification reception unit <NUM> in <FIG>) transmits a request for notification content to the server <NUM> in step <NUM> after receiving the push notification. For example, in a case where the client <NUM> is out of range area, the client <NUM> receives the push notification in step <NUM> when the client <NUM> is within range area.

In step <NUM>, the server <NUM> updates the status database <NUM> by recording information as to whether or not the client <NUM> requests the notification content in step <NUM> within the maximum calling period S seconds, in the status database <NUM>. The status database <NUM>, which is a database including history, or the like, of the calling results of the respective clients <NUM> as described above, records, for example, information of at least part of calling history of respective clients associated with the call-target persons (the calling start time cts, whether or not calling is successful (whether or not out of range area), response results from the clients (rejection/response), answer results from the clients (available/unavailable), the calling end time cte and history of these), time ets at which emergency calling for handling the failure is started, emergency calling end time ete, a status of success/failure of emergency calling, and a period required for emergency calling. <FIG> illustrates an example of the status database <NUM>. The status database <NUM> includes an emergency calling table 138A indicating whether each time of emergency calling has been successful or failed, or the like, and a telephone call table 138B indicating response results, answer results, or the like, in response to calling of the respective call-target persons. The emergency calling table 138A records a user ID of a person who has executed emergency calling, a failure handling record ID allocated to a failure handling record, a status (success, failure) of emergency calling, emergency calling start time ets, emergency calling end time ete, and reason for emergency calling. The telephone call table 138B records an emergency calling ID, a user ID of each call-target person associated with the emergency calling ID, a telephone call status indicating a response result of each call-target person, an answer result, calling start time cts and calling end time cte. Note that the calling start time cts is time at which the server <NUM> transmits a push notification in step <NUM>, and the calling end time cte is one of time at which the maximum calling period S seconds have elapsed since the calling start time cts or time at which the answer result transmitted from the client <NUM> is received in step <NUM> which will be described later.

In step <NUM>, the server <NUM> (the notification transmission unit <NUM> in <FIG>) which has received the request for notification content calls the selected client <NUM> via the Internet <NUM>. Such calling is performed by transmitting the notification content to the client <NUM>. The server <NUM> only requires to transmit the notification content to the selected client <NUM> and does not make a call with the called client <NUM>. Thus, the server <NUM> may perform such calling using voice over Internet protocol (VoIP) service which enables a call by converting speech/image data into IP data packets and transmitting the IP data packets. However, the way of calling is not limited to this. The notification content to be transmitted to the client <NUM> includes a notification type, for example, "StartCall", the maximum calling period S during which the client is continuously called, and the emergency calling ID.

In step <NUM>, the client <NUM> (the notification reception unit <NUM> in <FIG>) receives the notification content, and the client <NUM> (the display control unit <NUM> in <FIG>) generates a calling screen on the basis of the notification content. The client <NUM> (the calling unit <NUM> in <FIG>) can cause the calling screen (the calling screen b in <FIG>) to be displayed at the display unit <NUM> over the maximum calling period S. <FIG> illustrates an example of the calling screen b. As illustrated, a "response" button and a "rejection" button are displayed on the calling screen b, and the call-target person may select one of these buttons or does not have to perform any operation in response to the calling. Further, in step <NUM>, the client <NUM> is caused to ring. Causing the client <NUM> to ring or vibrate over the maximum calling period S can make it more likely for the call-target person of the client <NUM> to notice the calling.

In step <NUM>, the client <NUM> (the calling unit <NUM> in <FIG>) accepts operation for the "response" button or the "rejection" button on the calling screen b. If one of the "response" button or the "rejection" button is selected before the maximum calling period S elapses, the client <NUM> (the calling unit <NUM> in <FIG>) stops calling, and the processing proceeds to step <NUM>. Meanwhile, in a case where selection operation is not accepted during the maximum calling period S, the client <NUM> stops calling and finishes the processing. In a case where selection operation is not accepted, the server <NUM> updates the status database <NUM> by recording time at which the maximum calling period S has elapsed since the calling start time cts in the status database <NUM> as the calling end time cte.

In step <NUM>, the client <NUM> (the calling unit <NUM> in <FIG>) transmits a response result ("response", "rejection") in response to the calling to the server <NUM>.

In step <NUM>, the server <NUM> (the response reception unit <NUM> in <FIG>) updates the status database <NUM> by recording the response result ("response" or "rejection") received from the client <NUM> (the calling unit <NUM> in <FIG>) in the status database <NUM>.

In step <NUM>, the client <NUM> (the display control unit <NUM> in <FIG>) generates a terminal home screen and causes the terminal home screen to be displayed at the display unit <NUM>. The screen c in <FIG> illustrates an example of the terminal home screen, and an icon of application for supporting calling is displayed on the terminal home screen c. In a case where the client <NUM> (the display control unit <NUM> in <FIG>) detects that the icon of application for supporting calling is tapped on the terminal home screen c, the client <NUM> starts the application in the foreground, generates an application home screen and causes the application home screen to be displayed at the display unit <NUM>. The screens d1 and d2 in <FIG> illustrate an example of the application home screen. The screen d1 is an example of the application home screen in a case where emergency calling is being executed, and the screen d2 is an example of the application home screen in a case where emergency calling is not being executed. As illustrated in d1 and d2 in <FIG>, the application home screen includes an "emergency calling history" button, a button of a "list of unsolved failure handling records", a button of "create new failure handling record", and a button of a "list of failure handling records". In a case where emergency calling is being executed, the application home screen further includes a button of "emergency calling is being executed" (screen d1), and in a case where emergency calling is not being executed, a message of "no emergency calling" (screen d2) is displayed.

In a case where the application for supporting calling is started, in step <NUM>, a session between the server <NUM> and the client <NUM> is established. The session is established using remote procedure call (RPC) such as gRPC.

In step <NUM>, the client <NUM> (the update data reception unit <NUM> in <FIG>) requests emergency calling information associated with the emergency calling ID to the server <NUM>.

In step <NUM>, the server <NUM> (the update data transmission unit <NUM> in <FIG>) transmits emergency calling information corresponding to the emergency calling ID to the client <NUM> (the update data reception unit <NUM> in <FIG>) in response to the request for the emergency calling information. The emergency calling information, which includes information extracted from the updated status database <NUM>, is information for sharing information such as whether or not the call-target persons of other clients <NUM> can handle the failure among the respective clients <NUM>. The emergency calling information includes at least part of calling source information, an emergency calling result, emergency calling start time ets and emergency calling end time ete. The calling source information includes a user ID of a person who has executed emergency calling, an emergency calling ID, and a message associated with the emergency calling ID. The emergency calling result includes information as to whether the emergency calling has been successful or failed. The emergency calling information may further include at least part of a calling status of each call-target person, that is, "no operation" indicating that no operation is performed within the maximum calling period S, a response result ("response", "rejection") of the call-target person in response to the emergency calling request, an answer result ("available", "unavailable") of the call-target person, the calling start time cts, and the calling end time cte.

In step <NUM>, in a case where the client <NUM> (the display control unit <NUM> in <FIG>) detects that the button of "emergency calling is being executed" is tapped on the application home screen d1 (<FIG>), the client <NUM> (the display control unit <NUM> in <FIG>) generates an emergency calling detail screen and causes the emergency calling detail screen to be displayed at the display unit <NUM>. <FIG>, <FIG> and <FIG> respectively illustrate examples of emergency calling detail screens e, f and g. <FIG> illustrates an example of the emergency calling detail screen e in a case where an answer to the emergency calling request is not selected by the call-target person, and <FIG> and <FIG> illustrate examples of the emergency calling detail screens f and g after an answer is selected by the call-target person.

As illustrated in <FIG>, a button of "available" and a button of "unavailable" which can be selected by the call-target person are indicated on the emergency calling detail screen e. Further, the above-described emergency calling information can be further displayed on the emergency calling detail screen e. For example, as illustrated, the displayed emergency calling information includes "Taro Kono" which is name of a person who starts emergency calling, "group A" which is failure handling candidate group name corresponding to the failure handling candidate group ID, "failure occurred at server <NUM>" which is a message associated with the emergency calling ID, "no operation" which is a calling result of the call-target person of "Ren Sato", the calling start time cts and the calling end time cte. A period from when calling is started until when calling ends for the call-target person of "Ren Sato" is the maximum calling period S of <NUM> seconds, and thus, the calling result is "no operation". The call-target person can confirm various kinds of information such as response results, answer results, or the like, of other call-target persons in response to the calling with text through the emergency calling detail screen. Thus, the emergency calling information can be accurately confirmed compared to a case where notifications of content of the failure and statuses of other call-target persons being made through speech.

Further, emergency calling information corresponding to a plurality of last rounds in which all the target persons in the call-target person list <NUM> are called can be displayed on the emergency calling detail screen e in <FIG>. In the illustrated example, information corresponding to only one round is displayed.

Returning to <FIG>, in step <NUM>, the client <NUM> (the answer acceptance unit <NUM> in <FIG>) accepts a selected answer with respect to the button of "available" or the button of "unavailable" displayed on the screen e in <FIG>. In step <NUM>, the client <NUM> (the answer acceptance unit <NUM> in <FIG>) transmits the answer result to the server <NUM>.

According to the present disclosure, the call-target person can grasp details of the latest failure and calling statuses of other call-target persons with reference to the emergency calling information displayed on the screen. Thus, the call-target person can judge whether he/she will handle the failure or cannot handle the failure and answer with respect to the failure after confirming the latest emergency calling information. Further, the call-target person can grasp the details of the failure from character information, and thus can grasp the details of the failure more accurately than in a case where the details of the failure are delivered with speech which may be misheard.

Then, in step <NUM>, the server <NUM> (the answer reception unit <NUM> in <FIG>) receives the answer result in response to the calling from the client <NUM> and updates the status database <NUM> by recording the answer result in the status database <NUM>. Further, the server <NUM> (the answer reception unit <NUM> in <FIG>) updates the status database <NUM> by recording time at which the answer result is received in the status database <NUM> as the calling end time cte.

In step <NUM>, the server <NUM> (the update data transmission unit <NUM> in <FIG>) transmits the updated status database <NUM> to the client <NUM>.

In step <NUM>, the client <NUM> (the update data reception unit <NUM> in <FIG>) receives the updated status database <NUM> from the server <NUM>. The client <NUM> (the display control unit <NUM> in <FIG>) causes the emergency calling detail screen to be displayed at the display unit <NUM> on the basis of the updated status database <NUM>. <FIG> illustrates an example of the emergency calling detail screen f in a case where the button of "available" is selected by the call-target person of "Hiroto Takahashi". <FIG> illustrates an example of the emergency calling detail screen f in a case where the button of "unavailable" is selected by the call-target person.

Note that all the call-target persons within the call-target person list <NUM> can confirm the updated emergency calling detail screen. Thus, according to the present disclosure, the latest status as to whether or not the call-target person can handle the failure, or the like, can be shared with other call-target persons via the updated emergency calling detail screen.

A method 600A to be executed at the server <NUM> in a case where the server <NUM> calls the selected clients <NUM> and receives response results from the selected clients <NUM> will be described in further detail next with reference to <FIG>. Note that in the following description, description regarding the step which has already been described in <FIG> and <FIG> will be omitted.

Step 602a and step 604a illustrated in <FIG> correspond to step <NUM> in <FIG>. Further, step 602a and step 604a illustrated in <FIG> respectively correspond to step <NUM> and step <NUM> illustrated in <FIG>. Thus, description regarding step 602a and step 604a illustrated in <FIG> will be omitted. While step 606a to step 614a illustrated in <FIG> correspond to step <NUM> illustrated in <FIG>, these steps will be described in further detail below.

In step 606a, the server <NUM> (the response reception unit <NUM>) determines whether or not a response result is received, that is, operation is performed in response to the calling within the maximum calling period S seconds since the calling start time cts in step 606a. In a case where operation is not performed within the maximum calling period S (step 606a: No), that is, "no operation" and calling has been failed, the processing proceeds to step 610a. In step 610a, the server <NUM> (the response reception unit <NUM>) records a status of "no operation" in response to the calling of the client <NUM> and time at which the maximum calling period S seconds has elapsed since the calling start time cts as the calling end time cte in the status database <NUM> and finishes the processing.

Meanwhile, in a case where operation is performed during the maximum calling period S (step 606a: Yes), that is, in a case where the received response result is "response" or "rejection", the processing proceeds to step 608a. In step 608a, in a case where the response result is "rejection", the processing proceeds to step 612a, and the server <NUM> (the response reception unit <NUM>) records the response result of "rejection" in the status database <NUM>. Meanwhile, in step 610a, in a case where the response result is "response", the processing proceeds to step 614a, and the server <NUM> records the response result of "response" in the status database <NUM>.

A method 600B to be executed at the client <NUM> in which the selected client <NUM> is called and transmits a response result to the server <NUM> will be described in further detail next with reference to <FIG>. The method 600B corresponds to the processing on the server <NUM> side of the method 600A in <FIG>. Calling of the client <NUM> side, transmission processing of the response result, or the like, according to one embodiment of the present disclosure will be described below with reference to <FIG>.

Step 602b, step 604b and step 606b illustrated in <FIG> respectively correspond to step <NUM>, step <NUM> and step <NUM> illustrated in <FIG>. Thus, description regarding step 602b, step 604b and step 606b illustrated in <FIG> will be omitted. While step 608b and step 610b illustrated in <FIG> correspond to step <NUM> illustrated in <FIG>, these steps will be described in further detail below.

In step 608b, the client <NUM> (the calling unit <NUM> in <FIG>) determines whether operation of selecting one of the button of "response" or the button of "rejection" displayed on the calling screen b in <FIG> is performed within the maximum calling period S since the client has been called from the server <NUM>.

In a case where a determination result in step 608b is "Yes", that is, in a case where selection operation is performed within the maximum calling period S, the processing proceeds to step 610b, the client <NUM> (the calling unit <NUM> in <FIG>) stops calling, and the processing proceeds to step 612b.

Step 612b is processing on the client <NUM> side corresponding to the processing in step 606a on the server <NUM> side. In step 612b, the client <NUM> (the calling unit <NUM> in <FIG>) transmits a response result in response to the calling to the server <NUM> (the response reception unit <NUM> in <FIG>) without opening a voice channel with the server <NUM>. The response result includes information indicating that the button of "response" or the button of "rejection" is selected at the client <NUM> within the maximum calling period S. According to the present disclosure, even in a case where the client <NUM> responds to the calling, the client <NUM> simply stops calling without opening a voice channel with the server. Note that the response result transmitted in step 612b is received by the server <NUM> in the above-described processing in step 606a on the server <NUM> side.

Meanwhile, in a case where the determination result in step 608b is "No", that is, in a case where operation of selecting the button of "response" or the button of "rejection" by the target person is not accepted within the maximum calling period S, the processing proceeds to step 614b, and the client <NUM> (the calling unit <NUM> in <FIG>) stops calling and finishes the processing.

Processing of a method 700A to be executed at the server <NUM> in a case where the server <NUM> receives answers from all the clients <NUM> within the call-target person list <NUM> will be described next with reference to <FIG>. <FIG> is processing on the client <NUM> side corresponding to the processing on the server <NUM> side in <FIG>. Note that in the following description, description regarding the steps which have already been described in <FIG> will be omitted.

Step 702a and step 704a in <FIG> respectively correspond to step <NUM> and step <NUM> in <FIG>. Thus, description regarding these steps will be omitted. It is assumed that, in step 702a, the server <NUM> transmits an emergency calling start notification to all the clients <NUM> through the processing in step <NUM> described using <FIG>. Further, while step 706a to step 710a in <FIG> correspond to step <NUM> in <FIG>, these steps will be described in further detail below.

In step 706a, the server <NUM> (the answer reception unit <NUM> in <FIG>) determines whether the answer result received from the client is "available", and in a case where the answer result is "available", the processing proceeds to step 708a. In step 708a, the server <NUM> increments the number r of target persons who can handle the failure stored in the status database <NUM> by one, the processing proceeds to step 710a, and the server <NUM> stores time at which "available" is received in the status database <NUM> as the calling end time cte along with the answer result.

Meanwhile, in a case where the answer result received from the client is "unavailable" in step 706a, the server <NUM> stores time at which "unavailable" is received in the status database <NUM> as the calling end time cte along with the answer result in step 710a without incrementing the number r of target persons who can handle the failure.

Processing flow in a case where all the clients <NUM> within the call-target person list <NUM> transmit answers to the server <NUM> will be described next on the basis of <FIG>. It is assumed that all the clients <NUM> receive the emergency calling start notification from the server <NUM> through the processing in step <NUM> described using <FIG> prior to the flow of the method 700B. Processing in step 704b and processing in step 708b on the client <NUM> side in <FIG> respectively correspond to the processing in step 702a and the processing in step 704a on the server <NUM> side in <FIG>.

In step 702b, in a case where the client <NUM> (the display control unit <NUM> in <FIG>) detects that the icon for the application for supporting calling (the icon on the terminal home screen c illustrated in <FIG>) is tapped, the application for supporting calling is started in the foreground. The client <NUM> (the display control unit <NUM>) causes the application home screen (the screen d1 illustrated in <FIG>) to be displayed at the display unit <NUM>. Note that the call-target person of the client <NUM> can start the application from the terminal home screen c even if the client <NUM> is not called from the server <NUM>.

In step 704b, after a session between the server <NUM> and the client <NUM> is established, the client <NUM> (the update data reception unit <NUM> in <FIG>) receives emergency calling information from the server <NUM> (the update data transmission unit <NUM> in <FIG>).

In step 706b, the client <NUM> (the display control unit <NUM>) accepts operation with respect to the application home screen d1 from the call-target person and displays the emergency calling detail screen (the screen e illustrated in <FIG>) indicating the received emergency calling information. The emergency calling detail screen e includes the button of "available" and the button of "unavailable" which are selectable.

In step 708b, the client <NUM> (the answer acceptance unit <NUM> in <FIG>) accepts an answer which selects the button of "available" or the button of "unavailable" displayed on the screen e in <FIG> and transmits the answer result to the server <NUM> (the answer reception unit <NUM> in <FIG>). According to the present disclosure, any call-target person can transmit the answer result to the server <NUM> by starting the application for supporting calling even if the client <NUM> is not called from the server <NUM>. In other words, all the clients <NUM> can perform processing of transmitting an answer result of "available" without depending on processing of calling (step <NUM> in <FIG>) by the server <NUM>. By this means, if someone of the call-target persons notices emergency calling at a time point of emergency calling start notification (step <NUM> in <FIG>) and can make an answer of "available", it is possible to reduce the number of times of emergency calling, so that it is possible to reduce load on other call-target persons particularly in emergency calling on holidays or at night. Further, all the clients <NUM> can repeatedly transmit the answer results to the server <NUM> by repeating the processing illustrated in the method 700B if before the emergency calling end notification (step <NUM> in <FIG>) by the server <NUM>.

Processing of updating various kinds of databases in a case where selection operation or input operation is performed for a certain client <NUM> in this calling support system <NUM> will be described next using <FIG> illustrates flow of processing to be performed among a client 200a which updates data for which selection operation or input operation is performed, the server <NUM>, and all clients 200n at which application is running other than the client 200a which updates the data. Note that it is assumed in the following description that selection operation and input operation for updating the database from the call-target person has already been accepted at the client 200a which updates the data.

The selection operation is operation of selecting various kinds of buttons displayed at the display unit <NUM>, to be performed by the call-target person. Examples of the selection operation include operation of selecting the button of "response" or the button of "rejection" (the calling screen b in <FIG>) or operation of selecting the button of "available" or the button of "unavailable" (the screen e in <FIG>, or the like) described above.

The input operation is operation for inputting text, to be performed by the call-target person. The call-target person can input a title ("failure at server <NUM>" in <FIG>) of the failure handling record or details of the failure handling record ("Hardware failure occurred at server <NUM>. Contacted maintenance service and repaired the failure. " in <FIG>) as illustrated on a screen m in <FIG> as an example. Further, as another example, the call-target person can input comment on the failure handling record as illustrated on a screen l in <FIG>.

If the application for supporting calling is started at the client <NUM>, in step <NUM>, sessions are established between the client 200a which has updated the data and the server <NUM> and between all the clients 200n at which application is running other than the client 200a which has updated the data and the server <NUM>.

In step <NUM>, the client 200a which has updated the data transmits the updated data to the server. The updated data is not limited to the response results and the answer results and includes other various kinds of data such as, for example, the failure handling records.

In step <NUM>, the server <NUM> (the update data transmission unit <NUM> in <FIG>) updates various kinds of databases on the basis of the updated data received from the client 200a which has updated the data. The various kinds of databases are not limited to the status database <NUM> and include a database, or the like, which records the failure handling records of the respective call-target persons.

In step <NUM>, the server <NUM> (the update data transmission unit <NUM> in <FIG>) transmits the updated database to the client 200a.

In step <NUM>, the client 200a (the display control unit <NUM> in <FIG>) which has updated the data causes the screen to be updated and displayed at the display unit <NUM> on the basis of the updated database.

Further, in step <NUM>, the server <NUM> (the update data transmission unit <NUM> in <FIG>) transmits the updated database to all the clients 200n other than the client 200a which has updated the data.

In step <NUM>, the client 200n (the display control unit <NUM> in <FIG>) causes the screen to be updated and displayed at the display unit <NUM> on the basis of the updated database.

<FIG> illustrates a transition diagram of the screens to be displayed at the display unit <NUM> by the client <NUM>. Reference numerals a to p in this drawing correspond to the screens a to p illustrated in a to p in <FIG> illustrate screens to be displayed at the display unit <NUM> by the display control unit <NUM>. Transition of the screens to be displayed at the client <NUM> will be described below with reference to <FIG> and <FIG> to <FIG>. Note that description overlapping with the description which has already been provided regarding <FIG> will be omitted.

<FIG> illustrates the application home screen of the application for supporting calling. The screen d1 in <FIG> indicates that name of the failure handling candidate group is group A and emergency calling is being executed. Meanwhile, the screen d2 in <FIG> indicates that name of the failure handling candidate group is group A and emergency calling is not being executed. In a case where the button of "emergency calling history", the button of a "list of unsolved failure handling records", the button of "create new failure handling record", or the button of a "list of failure handling records" indicated in the application home screens d1 and d2 in <FIG> are selected by the call-target person of the client <NUM>, the screen transitions in accordance with the screen transition diagram in <FIG>.

More specifically, in a case where the button of "emergency calling is being executed" is selected on the application home screen d1 in <FIG>, the emergency calling detail screen e in <FIG> is displayed. This emergency calling detail screen e includes the button of "create failure handling record" and the button of "telephone call history".

In a case where the button of "create failure handling record" is selected on the emergency calling detail screen e, a new failure handling record creation screen j in <FIG> is displayed. The call-target person of the client <NUM> can input a failure handling record (a title and details) corresponding to a new failure on the new failure handling record creation screen j. Meanwhile, in a case where the button of "telephone call history" is selected on the emergency calling detail screen e, a telephone call history screen h in <FIG> is displayed. The telephone call history screen h includes calling start time cts, calling end time cte and calling results of all the call-target persons associated with the failure handling candidate group ID.

Further, in a case where the button of "emergency calling history" is selected on the application home screen d1 or d2 in <FIG>, an emergency calling history screen i in <FIG> is displayed. The emergency calling history screen i includes history of all the emergency calling IDs. On the emergency calling history screen i, buttons for displaying a result (success, failure) of emergency calling for each emergency calling ID, content of a message associated with the emergency calling ID, emergency calling start time ets and emergency calling end time ete are set. In a case where operation of selecting one of the buttons is accepted, the above-described emergency calling detail screen e is displayed.

Further, in a case where the button of a "list of unsolved failure handling records" is selected on the application home screen d1 or d2 in <FIG>, an unsolved failure handling record list screen n in <FIG> is displayed. The unsolved failure handling record list screen n includes a plurality of buttons (one in <FIG>) which respectively display failure handling records corresponding to one failure handling candidate group ID. In a case where operation of selecting one of these buttons is accepted on the unsolved failure handling record list screen n, a failure handling record detail screen (unsolved) k in <FIG> is displayed. History of handling, handling periods, or the like, of the respective call-target persons associated with the failure handling candidate group ID are displayed on the failure handling record detail screen k.

Further, in a case where the button of "create new failure handling record" is selected on the application home screen d1 or d2 in <FIG> or the emergency calling detail screen e in <FIG>, a new failure handling record creation screen j in <FIG> is displayed. The call-target person of the client <NUM> can input a title of the failure handling record and details of the failure handling record on the new failure handling record creation screen j. Further, in a case where the button of "create failure handling record" is selected on the new failure handling record creation screen j in <FIG>, an unsolved failure handling record is created. Thereafter, in a case where handling of the failure handling record is completed, the call-target person can change a status of the failure handling record to "solved".

Further, in a case where the button of a "list of failure handling records" is selected on the screens d1 and d2 in <FIG>, a failure handling record list screen o in <FIG> is displayed. The failure handling record list screen o includes a plurality of buttons (three in <FIG>) for respectively displaying failure handling records corresponding to one failure handling candidate group ID, and in a case where operation of selecting one of these buttons is accepted, a failure handling record detail screen k (unsolved) in <FIG> or a failure handling record detail screen l (solved) in <FIG> is displayed. The call-target person of the client <NUM> can input comment on the respective failure handling records on the failure handling record detail screens k and l. The call-target person of the client <NUM> can have chats with other call-target persons by reflecting comment in the failure handling record detail screens k and l by inputting comment in a field of "add comment" on the failure handling record detail screens k and l and depressing a button of "transmit". The failure handling record detail screens k and l illustrate examples of history of chats between the call-target person of the client <NUM> and other call-target persons. The history of the chats includes name of the call-target persons who input comment, comment input by the call-target persons, input date and time, and input time.

In a case where a button of "edit failure handling record" is selected on the failure handling record detail screens k or l in <FIG> or <FIG>, a failure handling record detail (editing) screen m in <FIG> is displayed. The call-target person of the client <NUM> can input a title (for example, "failure at server <NUM> ") of the failure handling record for the failure handling candidate group ID, or details of the failure handling record (for example, "Hardware failure occurred at server <NUM>") on the failure handling record detail (editing) screen m in <FIG>. In a case where an update button is selected on the failure handling record detail (editing) screen m in <FIG>, the failure handling record is updated.

Claim 1:
A method to be executed by a server (<NUM>), for supporting calling of call-target persons within a list (<NUM>) in which candidates for a person who is to handle a failure are defined as call-target persons, upon occurrence of a failure, the method comprising:
a step (<NUM>) of transmitting notification content to a client (<NUM>) of a call-target person selected from the list (<NUM>) via the Internet to call the client (<NUM>), the notification content including a maximum calling period during which the client (<NUM>) is caused to continuously ring or vibrate; and
a step (<NUM>) of receiving a response result indicating a result of operation in response to the calling from the client (<NUM>) of the selected call-target person.