支持呼叫的方法、服务器、客户端以及程序与流程

1.本公开涉及一种用于在故障发生时，支持呼叫有望应对该故障的候补者作为呼叫对象以应对该故障的方法、服务器、客户端以及程序。


背景技术：

2.当与网络连接的设备或网络自身发生故障时，需要呼叫有望应对该故障的候补者，指示适当应对该故障。以往，对于这样的故障应对候补者的呼叫，如专利文献1所公开的那样，是经由公共电话网进行的。
3.现有技术文献
4.专利文献
5.专利文献1：日本特开2002
‑
247036号公报


技术实现要素：

6.发明要解决的问题
7.但是，在专利文献1所公开的方法中，存在以下问题：为了经由公共电话网对故障应对候补者进行呼叫，在一次呼叫一个人时，需要一条线路。
8.用于解决问题的手段
9.本公开是鉴于上述问题点而完成的，本公开的一个方面是一种由服务器执行的方法，所述方法在故障发生时，支持对列表中的呼叫对象进行呼叫，所述列表将故障应对候补者定义为呼叫对象，所述方法包括以下步骤：通过互联网向从所述列表中选择的呼叫对象的客户端进行呼叫；以及从所述选择的呼叫对象的客户端接收表示针对所述呼叫的操作的结果的应答结果。另外，故障应对候补者是应对故障的候补者，包括对已发生的故障具有应对能力的人、或对已发生的故障负有应对责任的人。
10.另外，本公开的另一个方面是一种服务器，所述服务器在故障发生时，支持对列表中的呼叫对象进行呼叫，所述列表将故障应对的候补者定义为呼叫对象，所述服务器包括：
11.通知发送部，其通过互联网向从所述列表中选择的呼叫对象的客户端进行呼叫；以及应答接收部，其从所述选择的呼叫对象的客户端接收表示针对所述呼叫的操作的结果的应答结果。
12.此外，本公开的另一个方面是一种由与服务器通信的客户端执行的方法，所述服务器在故障发生时，支持对列表中的呼叫对象进行呼叫，所述列表将故障应对候补者定义为呼叫对象，所述方法包括以下步骤：当通过互联网接收到来自所述服务器的呼叫时，显示呼叫画面；以及接受所述呼叫对象对所述呼叫画面的应答的选择操作。
13.另外，本公开的另一方面是一种与服务器通信的客户端，所述服务器在故障发生时，支持对列表中的呼叫对象进行呼叫，所述列表将故障应对候补者定义为呼叫对象，所述客户端包括：显示控制部，当通过互联网接收到来自所述服务器的呼叫时，其显示呼叫画面；以及呼叫部，其接受所述呼叫对象对所述呼叫画面的应答的选择操作。
附图说明
14.图1示意性地示出根据本公开的一个实施方式的呼叫支持系统的构成。
15.图2是示出用于实现根据本公开的一个实施方式的呼叫支持系统中的各种处理的服务器和客户端的功能的示例的框图。
16.图3示意性地说明在根据本公开的一个实施方式的呼叫支持系统的服务器上执行的方法300的用于呼叫支持的处理。
17.图4是在根据本公开的一个实施方式的呼叫支持系统的服务器上执行的方法400的处理的流程图。
18.图5示出根据本公开的一个实施方式的在接收应答结果等的服务器侧和针对该服务器的处理所选择的客户端处执行的方法500的处理流程。
19.图6a是根据本公开的一个实施方式的在服务器上执行的方法600a的流程图。
20.图6b是根据本公开的一个实施方式的在客户端执行的方法600b的流程图。
21.图7a是根据本公开的一个实施方式的在服务器上执行的方法700a的流程图。
22.图7b是与图7a的服务器100侧的处理相对应地在客户端200执行的方法700b的流程图。
23.图8是在更新数据的客户端、服务器与更新数据的客户端以外的客户端之间进行的数据更新处理的流程图。
24.图9示出在根据本公开的一个实施方式的显示部上显示的画面的转变流程的示例。
25.图10a示出根据本公开的一个实施方式的紧急呼叫开始通知画面的示例。
26.图10b示出根据本公开的一个实施方式的呼叫画面的示例。
27.图10c示出根据本公开的一个实施方式的终端主页画面的示例。
28.图10d示出根据本公开的一个实施方式的用于呼叫支持的应用的主页画面的示例。
29.图10e示出根据本公开的一个实施方式的用于呼叫支持的应用的详情画面的示例。
30.图10f示出根据本公开的一个实施方式的用于呼叫支持的应用的详情画面的示例。
31.图10g示出根据本公开的一个实施方式的用于呼叫支持的应用的详情画面的示例。
32.图10h示出根据本公开的一个实施方式的致电历史画面的示例。
33.图10i示出根据本公开的一个实施方式的紧急呼叫历史画面的示例。
34.图10j示出根据本公开的一个实施方式的新故障应对记录的创建画面的示例。
35.图10k示出根据本公开的一个实施方式的故障应对记录的详情画面的示例。
36.图10l示出根据本公开的一个实施方式的故障应对记录的详情画面的示例。
37.图10m示出根据本公开的一个实施方式的故障应对记录的详情画面的示例。
38.图10n示出根据本公开的一个实施方式的未解决故障应对记录一览画面的示例。
39.图10o示出根据本公开的一个实施方式的故障应对记录的一览画面的示例。
40.图10p示出根据本公开的一个实施方式的紧急呼叫结束通知画面的示例。
41.图11示出根据本公开的一个实施方式的呼叫对象列表的示例。
42.图12例示了根据本公开的一个实施方式的表示预先设置的各种参数的表、表示依次被呼叫的对象的姓名的表、以及表示被呼叫的对象的呼叫结果的表。
43.图13a示出根据本公开的一个实施方式的故障应对候补者组表的示例。
44.图13b示出根据本公开的一个实施方式的状态数据库的示例。
具体实施方式
45.[对本公开的实施方式的说明]
[0046]
首先，将列出和说明本公开的实施方式的内容。本公开的一个实施方式包括以下配置。
[0047]
(项目1)根据项目1，提供一种由服务器执行的方法，所述方法支持在故障发生时对列表中的呼叫对象进行呼叫，所述列表将故障应对的候补者定义为呼叫对象，所述方法包括以下步骤：
[0048]
通过互联网向从所述列表中选择的呼叫对象的客户端进行呼叫；以及
[0049]
从所述选择的呼叫对象的客户端接收表示针对所述呼叫的操作的结果的应答结果。
[0050]
(项目2)根据项目2，提供根据项目1所述的方法，其特征在于，当所接收到的所述应答结果表示有对所述呼叫的操作时，不打开所述客户端和所述服务器之间的语音通道。
[0051]
(项目3)根据项目3，提供根据项目2所述的方法，还包括以下步骤：根据所述应答结果，对记录所述呼叫对象的用于所述故障的应对的呼叫相关的状态的状态数据库进行更新。
[0052]
(项目4)根据项目4，提供根据项目3所述的方法，还包括以下步骤：接收表示针对应对所述故障的请求的能否应对的回答的回答结果；以及
[0053]
根据所述回答结果，对根据所述应答结果进行了更新的状态数据库进行更新。
[0054]
(项目5)根据项目5，提供根据项目4所述的方法，还包括以下步骤：将根据所述回答结果进行了更新的状态数据库发送到所述列表中的所有呼叫对象的客户端。
[0055]
(项目6)根据项目6，提供根据项目2所述的方法，还包括以下步骤：当接收到所述回答结果时，对所述列表中下一个选择的呼叫对象的客户端进行呼叫。
[0056]
(项目7)根据项目7，提供根据项目1至6中任一项所述的方法，还包括以下步骤：
[0057]
当接收到来自监视所述故障发生的监视系统的请求时，向所述列表中的所有呼叫对象的客户端发送表示所述故障发生的通知信息。
[0058]
(项目8)根据项目8，提供根据项目7所述的方法，还包括以下步骤：
[0059]
根据从所述列表中的所有客户端中的至少一台客户端接收到的、表示能否应对所述故障的回答的回答结果，对所述状态数据库进行更新；以及
[0060]
向所述列表中的所有客户端发送根据从所述至少一台客户端接收到的回答结果而进行了更新的所述状态数据库。
[0061]
(项目9)根据项目9，提供根据项目1至8中任一项所述的方法，其中，
[0062]
在所述列表中，从所述列表中选择的呼叫对象是多个，
[0063]
对所述客户端的呼叫是同时对多个呼叫对象的客户端进行。
[0064]
(项目10)根据项目10，提供一种用于使所述服务器执行根据项目1至9中任一项所述的方法的程序。
[0065]
(项目11)根据项目11，提供一种服务器，所述服务器在故障发生时，支持对列表中的呼叫对象进行呼叫，所述列表将故障应对的候补者定义为呼叫对象，所述服务器包括：
[0066]
通知发送部，其通过互联网向从所述列表中选择的呼叫对象的客户端进行呼叫；以及
[0067]
应答接收部，其从所述选择的呼叫对象的客户端接收表示针对所述呼叫的操作的结果的应答结果。
[0068]
(项目12)根据项目12，提供根据项目11所述的服务器，其特征在于，当所接收到的所述应答结果表示有对所述呼叫的操作时，不打开所述客户端和所述服务器之间的语音通道。
[0069]
(项目13)根据项目13，提供根据项目12所述的服务器，其中，所述应答接收部进一步根据所述应答结果，对记录所述呼叫对象的用于所述故障的应对的呼叫相关的状态的状态数据库进行更新。
[0070]
(项目14)根据项目14，提供根据项目13所述的服务器，所述服务器还包括：回答接收部，其接收表示针对应对所述故障的请求的能否应对的回答的回答结果，并根据所述回答结果，对根据所述应答结果进行了更新的状态数据库进行更新。
[0071]
(项目15)根据项目15，提供根据项目14所述的服务器，所述服务器还包括：更新数据发送部，其将根据所述回答结果进行了更新的状态数据库发送到所述列表中的所有呼叫对象的客户端。
[0072]
(项目16)根据项目16，提供根据项目11所述的服务器，其中，当接收到所述回答结果时，所述通知发送部进一步对所述列表中下一个选择的呼叫对象的客户端进行呼叫。
[0073]
(项目17)根据项目17，提供根据项目11至16中任一项所述的服务器，其中，当接收到来自监视所述故障发生的监视系统的请求时，所述通知发送部进一步向所述列表中的所有呼叫对象的客户端发送表示所述故障发生的通知信息。
[0074]
(项目18)根据项目18，提供根据项目17所述的服务器，其中，所述回答接收部进一步根据从所述列表中的所有客户端中的至少一台客户端接收到的、表示能否应对所述故障的回答的回答结果，对所述状态数据库进行更新，
[0075]
向所述列表中的所有客户端发送根据从所述至少一台客户端接收到的回答结果而进行了更新的所述状态数据库。
[0076]
(项目19)根据项目19，提供根据项目1至18中任一项所述的服务器，其中，
[0077]
在所述列表中，从所述列表中选择的呼叫对象是多个，
[0078]
对所述客户端的呼叫同时对多个呼叫对象的客户端进行。
[0079]
(项目20)根据项目20，提供一种由与服务器通信的客户端执行的方法，所述服务器在故障发生时，支持对列表中的呼叫对象进行呼叫，所述列表将故障应对的候补者定义为呼叫对象，所述方法包括以下步骤：
[0080]
当通过互联网从所述服务器接收到呼叫时，显示呼叫画面；
[0081]
接受所述呼叫对象对所述呼叫画面的应答的选择操作。
[0082]
(项目21)根据项目21，其特征在于，提供根据项目20所述的方法，还包括当接受所
述呼叫对象对所述呼叫画面的应答的选择操作时，停止呼叫所述客户端的步骤，
[0083]
在接受了所述应答的选择操作的情况下，不打开所述客户端和所述服务器之间的语音通道。
[0084]
(项目22)根据项目22，提供根据项目21所述的方法，还包括以下步骤：在从所述服务器接收到表示所述故障发生的通知信息时，显示包含所述通知信息的第一画面(紧急呼叫开始通知画面)。
[0085]
(项目23)根据项目23，提供根据项目22所述的方法，还包括显示安装在所述客户端上的用于呼叫支持的应用的第二画面(用于呼叫支持的应用的紧急呼叫详情画面)的步骤，所述第二画面包括与所述故障相对应的消息或与所述故障相对应的其他客户端的呼叫结果中的至少一个。
[0086]
(项目24)根据项目24，提供根据项目23所述的方法，其中，所述第二画面还包括用于回答所述客户端的呼叫对象能够应对所述故障的能够选择的按钮。
[0087]
(项目25)根据项目25，提供根据项目24所述的方法，还包括显示安装在所述客户端上的用于呼叫支持的应用的第三画面(故障应对记录的详情画面)的步骤，所述第三画面包括用于所述客户端的呼叫对象与所述列表中的其它呼叫对象的客户端进行聊天的输入画面。
[0088]
(项目26)根据项目26，提供一种用于使所述客户端执行根据项目20至25中任一项所述的方法的程序。
[0089]
(项目27)根据项目27，提供一种与服务器通信的客户端，所述服务器在故障发生时，支持对列表中的呼叫对象进行呼叫，所述列表将故障应对的候补者定义为呼叫对象，所述客户端包括：
[0090]
显示控制部，当通过互联网接收到来自所述服务器的呼叫时，其显示呼叫画面；以及
[0091]
呼叫部，其接受所述呼叫对象对所述呼叫画面的应答的选择操作。
[0092]
(项目28)根据项目28，提供根据项目27所述的客户端，其特征在于，当接受所述呼叫对象对所述呼叫画面的应答的选择操作时，所述呼叫部进一步停止呼叫所述客户端；
[0093]
在接受了所述应答的选择操作的情况下，不打开所述客户端和所述服务器之间的语音通道。
[0094]
(项目29)根据项目29，提供根据项目28所述的客户端，其中，
[0095]
当从所述服务器接收到表示所述故障发生的通知信息时，所述显示控制部进一步显示包含所述通知信息的第一画面。
[0096]
(项目30)根据项目30，提供根据项目29所述的客户端，其中，所述显示控制部进一步
[0097]
显示安装在所述客户端上的用于呼叫支持的应用的第二画面，所述第二画面包括与所述故障相对应的消息或与所述故障相对应的其它客户端的呼叫结果中的至少一个。
[0098]
(项目31)根据项目31，提供根据项目30所述的客户端，其中，所述第二画面还包括用于回答所述客户端的呼叫对象能够应对所述故障的能够选择的按钮。
[0099]
(项目32)根据项目32，提供根据项目31所述的客户端，其中，所述显示控制部进一步显示安装在所述客户端上的用于呼叫支持的应用的第三画面，所述第三画面包括用于所
述客户端的呼叫对象与所述列表中的其他呼叫对象的客户端进行聊天的输入画面。
[0100]
[本公开的实施方式的详细]
[0101]
以下，参照附图对本公开的实施方式进行说明。在附图中，相同或相似的元件由相同或相似的附图标记表示，并且在每个实施方式的说明中，有时省略对相同或类似元件的重复描述。另外，只要不相互矛盾，各实施方式所示的特征也能够适用于其他实施方式。然而，本公开的实施方式未必限定于此。对于本领域技术人员来说显而易见的是，本公开的实施方式可采取包括在权利要求书所限定的范围内的各种方面。
[0102]
以下，对本公开的实施方式进行具体说明。图1是示意性地示出根据本公开的一个实施方式的呼叫支持系统1000的构成的图。呼叫支持系统1000是支持故障发生时用于故障应对的候补者的呼叫的系统。在本公开中，所谓故障，不仅是指系统的故障或障碍等需要紧急召集具有技术或知识等的负责人的故障，还包括要求投诉处理、其他紧急应对的所有故障、妨碍、障碍、事故等。作为系统故障以外的其他具体示例，所谓需要紧急应对的情况，例如在灾害发生时呼叫具有灾害对策的判断权限的上级负责人的情况、在医院进行紧急手术时紧急呼叫具有与手术相关的技术的医生的情况等。另外，在以下说明的实施方式中，以系统故障的示例进行说明。首先，对整体进行说明，呼叫支持系统1000包括进行呼叫支持的服务器100以及该服务器100通过互联网20呼叫的一台以上的客户端200。另外，客户端200在图1中是200a、200b、200c，以下有时统称为客户端200。
[0103]
首先，监视系统10是在检测出作为监视对象的监视对象装置(未图示)中发生了故障时，生成要求应对该故障的紧急呼叫请求，并发送给服务器100的系统。作为示例，监视系统10可以包括一台以上的例如多个监视终端12。作为一例，监视终端12在检测到与监视对象服务器的通信被切断时，生成消息“与监视对象装置的通信被切断了。”并生成基于此的紧急呼叫要求。另外，在上述示例中，监视系统10自动发送紧急呼叫请求，但也可以手动发送该紧急呼叫请求。例如，也可以由进行故障接受的操作员操作操作员终端(未图示)进行发送。作为一个示例，当操作员收到来自顾客的消息“有来自顾客的调查委托，请给予应对”时，操作员生成并发送对应的紧急呼叫请求。
[0104]
呼叫支持系统1000中的服务器100可以由云端提供，或者可以由诸如系统用户的大楼或场地之类的本地场所提供。另外，服务器100可以由一台构成，也可以由多台构成。服务器100通过互联网20与监视系统10连接，接收来自监视系统10的上述紧急呼叫请求。另外，在该图示例中，监视系统10和呼叫支持服务器100通过互联网连接，但并不限于此，只要能够通信地连接即可，因此，既可以通过互联网、lan、wan等ip(internet protocol)网络连接，也可以直接连接。服务器100根据接收到的紧急呼叫请求中包含的信息，确定将针对该故障应对的候补者作为呼叫对象而包含的呼叫对象列表136，从该确定的呼叫对象列表136中选择特定的呼叫对象，并通过互联网20呼叫该选择的呼叫对象所持有的客户端200。
[0105]
客户端200可经由通信载波的基站或经由例如wi
‑
fi(注册商标)等无线lan接入点连接到互联网20。客户端200是具有其上有触摸面板的显示器的移动终端，例如是智能电话或平板终端。在各客户端200中安装有用于支持呼叫故障应对候补者的应用。
[0106]
图2是示出用于实现根据本公开的实施方式的呼叫支持系统1000中的各种处理的服务器100和客户端200的各种功能的示例的框图。服务器100包括处理器110和存储器130作为主要构件。
[0107]
处理器110根据提供给服务器100的信号或者根据预定条件成立来执行存储在存储器130中的程序中包括的一系列指令。在某些实施例中，处理器110被实现为诸如中央处理部(cpu)、微处理器部(mpu)等设备。包含在处理器110中的组件只不过是将处理器110执行的功能表示为具体模块的一个示例。多个组件的功能可以由单个组件来实现。处理器110可配置成执行所有组件的功能。图2示出由处理器110执行的功能。处理器110例如包括但不限于通知发送部112、应答接收部114、回答接收部116和呼叫控制部118。应答接收部114、回答接收部116以及呼叫控制部118执行的方法的详细动作分别在图6a、图7a、图12中进行后述。通知发送部112向客户端200发送各种推送通知。应答接收部114从客户端200接收对呼叫的应答结果。回答接收部116接收来自客户端200的对紧急呼叫请求的回答结果。呼叫控制部118进行从呼叫对象列表136中根据优先顺序选择呼叫对象并进行呼叫的紧急呼叫处理、该紧急呼叫处理的结束判定。更新数据发送部120将根据从客户端200发送的应答结果、回答结果而更新的、包括各客户端200的呼叫结果的历史等的状态数据库138发送到客户端200。
[0108]
存储器130存储程序和数据。存储器130还用作临时存储处理器的处理结果的工作区域。存储器130可包括半导体存储介质和磁存储介质等任意非瞬时(non
‑
transitory)存储介质。存储器130可包括便携式存储介质(例如存储卡、光盘或磁光盘)与存储介质的读取器的组合。存储器130可包括随机存取存储器(random access memory)等用作临时存储区域的存储装置。
[0109]
存储器130可配置成存储各种信息。在一个示例中，存储器130可包含控制程序132、故障应对候补者组表134、上述呼叫对象列表136、状态数据库138和其它数据。控制程序132可以包括用于与服务器100的操作系统、客户端200之间发送和接收各种信息的程序等。图13a例示了故障应对候补者组表134，故障候补者组表134将所有的故障应对候补者组id与对应于各个故障应对候补者组id的一个以上的故障应对候补者关联起来进行记录。故障应对候补者也可以与多个故障应对候补者组id相对应。故障应对候补者组表134的与故障应对候补者组id对应的一个以上的故障应对候补者是呼叫对象，呼叫对象列表136由提取出的一个以上的呼叫对象构成。状态数据库138记录针对紧急呼叫请求的各客户端200的呼叫状态等。
[0110]
类似于服务器100，客户端200包括作为主要构件的处理器210和存储器230。客户端200与服务器100的不同之处在于，客户端200还包括显示部250。以下，对与在服务器100的结构中说明的内容重复的内容省略说明。
[0111]
如图2所示，在一个示例中，处理器210包括通知接收部212、呼叫部214、回答接受部216、显示控制部218和更新数据接收部220，但不限于此。通知接收部212、呼叫部214、回答接受部216、更新数据接收部220执行的方法的详细动作分别在图4、图6b、图7b、图8中进行后述。通知接收部212从服务器100接收各种推送通知。呼叫部214根据来自服务器100的呼叫，进行使显示控制部218显示呼叫画面以及停止显示呼叫画面指示。另外，呼叫部214接受来自呼叫对象对呼叫的应答/拒绝的选择操作，并将应答结果发送到服务器100。回答接受部216接受来自呼叫对象的针对紧急呼叫请求的能应对/不能应对的选择操作，并将回答结果发送给服务器。显示控制部218进行在客户端200的显示部250上显示的各种画面的转变控制。图9表示显示控制部218进行的画面转变控制的流程的示例。更新数据接收部220接
收从服务器100发送的各种更新数据，例如更新后的状态数据库232。
[0112]
存储器230可配置成存储各种信息。在一个示例中，存储器230包含从服务器接收到的更新后的状态数据库232。存储器230还可以包含用于将从显示控制部218接收的各种图像提供给显示部250的计算所需的各种数据。
[0113]
显示部250由液晶显示器(liquid crystal display)、有机el显示器(organic electro
‑
luminescence display)等实现，触摸面板配置在该显示器上。显示部250根据从处理器210输入的信号，显示文字、图形、图像等信息。显示部250显示的信息包括用于通知紧急呼叫开始消息的画面(后述的图10a的画面a)、呼叫画面(图10b的画面b)、终端主页画面(图10c的画面c)、应用主页画面(图10d的d1以及d2)、用于通知针对紧急呼叫请求的各呼叫对象的呼叫结果等详细情况的画面(图10e的画面e、f)、用于通知紧急呼叫结束消息的画面(图10p的画面p)等。
[0114]
下面将更具体地说明本公开的实施方式。作为可以应用本公开的实施方式的具体示例，假设在发生系统故障时，为了应对故障，支持呼叫维护系统的对象的情况。然而，本公开的实施方式不一定限于这些方面。对于本领域技术人员来说显而易见的是，本公开的实施方式可采取包括在权利要求书所限定的范围内的各种方面。
[0115]
图3是示意性地示出在根据本公开的一个实施方式的呼叫支持系统1000的服务器100中执行的呼叫支持方法300的处理的图。方法300示出服务器100进行的以下处理流程：从监视系统10接收紧急呼叫请求，并将唯一标识紧急呼叫请求的紧急呼叫id和紧急呼叫请求信息登记到状态数据库，然后通知呼叫对象的各客户端200的紧急呼叫处理开始，之后进行到向各客户端200通知紧急呼叫处理的结束为止。在能够应对故障的呼叫对象不满足所需人数的情况下，服务器100从呼叫对象列表136自动呼叫下一顺位的呼叫对象的客户端200。这样，通过重复步骤308至314的处理直到满足结束条件，从而执行根据优先顺序对呼叫对象进行呼叫的客户端200的紧急呼叫处理。
[0116]
处理在步骤302开始。作为示例，从存储器130读取控制程序132并由处理器110执行以使呼叫支持系统1000成可用状态。另外，初始设定各种参数(后述的当前能应对的人数r以及当前的重复次数q等)。
[0117]
在步骤304，服务器100接收来自监视系统10的紧急呼叫请求。紧急呼叫请求包括表示故障的内容的消息、以及能够唯一确定故障应对候补者组的信息。服务器100根据紧急呼叫请求中包含的信息，确定故障应对候补组id，并从故障应对候补者组表134中读取与故障应对候补者组id对应的故障应对候补者0000a.json(呼叫对象列表)。图11表示呼叫对象列表136的显示例。在这个示例中包含呼叫对象5人。呼叫对象列表136由故障应对候补者组名(在图11中为组a)、与该故障应对候补者组名相对应的1人以上的呼叫对象的姓名(图11中为佐藤莲、铃木湊、高桥大翔、田中大和、渡边阳翔5名)、呼叫各呼叫对象的优先顺序(在图11中佐藤莲的优先顺序为1)构成。这些呼叫对象的姓名分别与各呼叫对象携带的客户端200的识别符相对应。
[0118]
在步骤306中，服务器100(图2的通知发送部112)通过互联网20向呼叫对象列表136的呼叫对象的所有客户端200发送紧急呼叫开始消息，例如“在组a中紧急呼叫正在执行中。”这样的消息、与紧急呼叫请求对应的紧急呼叫id和通知类别等，通知紧急呼叫开始。关于紧急呼叫开始消息的通知流程的详细内容，在图4中进行说明。另外，在步骤306中，服务
器100将通知了紧急呼叫开始消息的时刻作为紧急呼叫开始时刻ets保存在存储器130中。
[0119]
在步骤308中，服务器100(图2的呼叫控制部118)从呼叫对象列表136(图11)中选择同时呼叫的呼叫对象(一人以上)。作为一个示例，同时呼叫对象可以从优先顺序高的一方开始依次选择，或者从低的一方开始依次选择。
[0120]
在步骤310中，服务器100(图2的通知发送部112)通过互联网20对所选择的1人以上的同时呼叫对象的客户端200进行呼叫。根据本公开，由于通过互联网20进行客户端200的呼叫，所以即使没有同时呼叫的客户端量的固定线路，也能够同时呼叫多个客户端200。因此，即使在发生大规模灾害时，也能够同时呼叫多个能够应对社会基础设施故障的候补者，而能够迅速地应对故障。
[0121]
接收到呼叫的客户端200(图2的呼叫部214)向服务器100发送针对呼叫的应答结果。所谓应答结果，是指针对来自服务器100的呼叫的、呼叫对象对呼叫应答或拒绝的选择操作的结果。另外，这样的选择操作可以是根据呼叫对象发出的语音的“应答”、或者“拒绝”的选择操作，也可以是根据呼叫对象在触摸面板上进行的触摸面板上的滑动操作的“应答”的选择操作、或者在触摸面板上显示的应答按钮、拒绝按钮的选择操作。
[0122]
在步骤312中，服务器100(图2的应答接收部114)将从客户端200(图2的呼叫部214)接收到的针对呼叫的应答结果保存在存储器130中。在图6a的方法600a中详细描述与步骤310和步骤312相对应的服务器100中的处理，并且在图6b的方法600b中详细描述与这些步骤310和312相对应的客户端200中的处理。
[0123]
然后，客户端200(图2中的显示部250)显示从服务器100接收到的故障相关的详细信息。客户端200(图2的回答接受部216)向服务器100发送呼叫对象的回答结果，该回答结果表示是能应对故障还是不能应对故障。回答结果包括呼叫对象对来自服务器100的故障的详细信息的“能应对”、“不能应对”的选择操作的结果。
[0124]
在步骤314中，服务器100(图2的回答接收部116)将从客户端200(图2的回答接受部216)接收到的回答结果保存在存储器中。在图7a的方法700a中详细说明与步骤314对应的服务器100中的处理，在图7b的方法700b中详细说明与该步骤314对应的客户端200中的处理。
[0125]
在步骤316中，服务器100(图2的通知发送部112)通过互联网20向呼叫对象列表136的呼叫对象的所有客户端200发送紧急呼叫结束消息，例如“组a的紧急呼叫已完成”、紧急呼叫id和通知类别。关于紧急呼叫结束消息的通知流程的详细内容，在图4中进行说明。另外，在步骤316中，服务器100将通知了紧急呼叫结束消息的时刻作为紧急呼叫结束时刻ete保存在存储器130中。
[0126]
服务器100(图2的呼叫控制部118)进行紧急呼叫处理，该紧急呼叫处理重复从步骤308到步骤314的处理，直到满足结束条件为止。由此，服务器100能够将可以应对故障的呼叫对象仅确保为应对故障的必要人数r。
[0127]
接着，参照图12，对用于按照优先顺序确保能够应对故障的呼叫对象的紧急呼叫处理的流程进行说明。服务器100(呼叫控制部118)按照呼叫对象列表136，进行依照优先顺序对呼叫对象的客户端200进行呼叫的紧急呼叫处理，当满足结束条件时结束紧急呼叫处理。作为一个示例，紧急呼叫处理的结束条件为：能应对故障的对象的人数r为呼叫所需人数r。另外，其他的示例是，即使在重复次数q内进行呼叫对象列表136的所有对象的呼叫，能
应对的对象的人数r小于呼叫所需人数r。在初始设定中，当前能够应对故障的人数r为0，当前的重复次数q为0。
[0128]
图12例示了表示本公开预设的各种参数的表1210、表示按顺序呼叫的对象的姓名的表1220、以及表示被呼叫对象的呼叫结果的表1230。
[0129]
表1210包含持续呼叫客户端的最大呼叫时间s、同时呼叫的同时呼叫人数p、重复对呼叫对象列表136内的所有人进行呼叫的重复次数q、以及故障应对的所需人数r。通过将同时呼叫人数p设定为呼叫对象列表136中规定的人数以上，也能够同时呼叫列表中的全部人。另外，在以下的说明中，在表1210中，预先设定了最大呼叫时间s＝60秒、同时呼叫人数p＝3人、重复次数q＝10次、应对故障的所需人数r＝2人。
[0130]
表1220表示针对特定的故障应对候补者组名(在此为组a)按顺序呼出的呼叫对象的示例。在这个示例中，呼叫对象人数为5人。表1220的虚线所包围的1222表示最初呼叫时优先度最高的呼叫对象组。1224表示呼叫对象列表136内的所有人的呼叫的第一次重复，1226表示呼叫对象列表136内的全部人的呼叫的第二次重复。
[0131]
表1230表示从各呼叫对象的呼叫开始到各呼叫对象的选择回答结果(“能应对”、“不能应对”)为止的时间、或者最大呼叫时间s之中的任一呼叫时间t。即使客户端200在最大呼叫时间s内进行呼叫，在未检测出呼叫对象的应答或拒绝操作的情况下，呼叫时间t为最大呼叫时间s。
[0132]
以下，参照图12，详细说明服务器100(图2的呼叫控制部118)进行的紧急呼叫处理。
[0133]
服务器100(呼叫控制部118)从呼叫对象列表136中按照优先顺序高的顺序选择同时呼叫人数(在此为3人)、呼叫对象(图3的步骤308)。服务器100(应答接收部114)首先同时呼叫所选择的最优先的呼叫对象(组1222的全员)(与图3的步骤310对应)。被呼叫的客户端200向服务器100发送针对呼叫的应答结果。服务器100(应答接收部114)根据接收到的应答结果来更新状态数据库138并将其存储在存储器130中(对应于图3的步骤312)。另外，客户端200向服务器100发送针对紧急呼叫请求的回答结果。服务器100(回答接收部116)根据接收到的回答结果，更新状态数据库138并将其存储在存储器130中(对应于图3的步骤314)。
[0134]
服务器100(呼叫控制部118)根据提取自从存储器130读取的状态数据库138的信息，选择呼叫对象。为了便于说明，表1230示出由从图13b所示的致电表138b中提取出的一部分信息构成的表的示例。
[0135]
表1230表示，在第一次呼叫1224的组1222的呼叫中，优先顺序1的呼叫对象“佐藤莲”进行针对呼叫的“应答”操作，并且在呼叫开始25秒后回答为“能应对”，优先顺序2的呼叫对象“铃木湊”没有对经过最大呼叫时间s秒(例如60秒)的呼叫进行操作(“无操作”)，优先顺序3的呼叫对象“高桥大翔”虽然进行了针对呼叫的“应答”操作，但是呼叫开始30秒后，回答为“不能应对”。服务器100(呼叫控制部118)由于“佐藤莲”1人回答为“能应对”，所以将当前的能应对人数r递增1。
[0136]
服务器100(呼叫控制部118)对当前的能应对人数r和所需人数r进行比较，并且比较当前的重复次数q和重复次数q，判定是否应该进一步选择呼叫对象。在表1230中，在组1222的呼叫中，回答“能应对”的人只有优先顺序1的“佐藤莲”1人，比所需人数r(2人)少。另外，当前的重复次数为1，比重复次数q(10)少。由于在重复次数q以下，并且对于应对故障的
呼叫回答为“能应对”的人数r小于所需人数r，所以服务器100(呼叫控制部118)参照呼叫对象列表136，确定下一优先的呼叫对象。
[0137]
另外，客户端200在即使超过最大呼叫时间s也不进行操作时等，停止呼叫。当停止呼叫时，正在呼叫的客户端200减少一个。服务器100(呼叫控制部118)进一步依次选择优先顺序4的呼叫对象“田中大和”、优先顺序5的呼叫对象“渡边阳翔”，使得同时呼叫的人数成为同时呼叫人数p。服务器100呼叫所选择的呼叫对象，从客户端200接收应答结果、回答结果。
[0138]
表1230表示在第一次呼叫1224中，优先顺序4的呼叫对象“田中大和”即使呼叫最大呼叫时间s秒(60秒)也无操作，优先顺序5的呼叫对象“渡边阳翔”虽然对呼叫作出了应答，但在呼叫开始35秒后回答为“不能应对”。在第一次呼叫1224结束的时刻，虽然呼叫了呼叫对象列表136内的全员，但对于所需人数r(2人)，回答“能应对”的人数(1人)依然少，并且当前的重复次数q(1次)比重复次数q(10次)少。因此，服务器100执行第二次呼叫1226。服务器100(呼叫控制部118)由于呼叫了呼叫对象列表136内的所有呼叫对象，所以将当前的重复次数q递增1。另外，优先顺序1的呼叫对象“佐藤莲”在第一次呼叫中回答为能应对，因此不被再次选择为呼叫对象。代替呼叫优先顺序1的对象，再次选择优先顺序2的对象。
[0139]
在第二次呼叫1226中，优先顺序2的呼叫对象“铃木凑”选择“应答”，并且回答为“能应对”。在第二次呼叫1226中，在优先顺序2的呼叫对象的时刻，由于达到了所需人数r的2人，所以作为呼叫“成功”，结束紧急呼叫处理。
[0140]
如上所述，服务器100(呼叫控制部118)在当前的重复次数q为规定的重复次数q(在此为10次)以下、当前能够应对故障的人数r为所需人数r以上的情况下，判定为能够应对故障的呼叫对象确保成功，结束紧急呼叫处理。另一方面，服务器100(呼叫控制部118)即使在规定的重复次数q内进行呼叫，在回答为“能应对”的人数r小于所需人数r的情况下，判定为能够应对故障的呼叫对象确保失败，结束紧急呼叫处理。
[0141]
另外，在上述说明中，如果检测出即使超过预设的最大呼叫时间s也没有进行操作(无操作)，则该客户端200停止呼叫，因此，呼叫中的客户端200减少一个。然后，服务器100(呼叫控制部118)能够立即依次选择下一优先的呼叫对象，以使同时呼叫人数为p(3人)(作为一例，服务器100(呼叫控制部118)在以图12的1232所示的“无操作”呼叫停止之后，马上选择下一优先的呼叫对象来代替优先顺序2的呼叫对象“铃木凑”，以使同时呼叫人数成为3人)。但是，作为另一个示例，进一步地，服务器100在接收到针对呼叫的回答结果时，即，作为一例，当应答而停止呼叫的优先顺序1的“佐藤莲”选择图12的1232所示的“能应对”的回答时，对客户端200选择下一优先的呼叫对象。这样，服务器100(呼叫控制部118)为了满足同时呼叫人数(3人)，在经过呼叫时间s后，或者在接收到来自客户端200的回答结果(“能应对”、“不能应对”)后，依次呼叫下一优先的呼叫对象。这样，服务器100还能够更迅速地确保能够应对紧急呼叫请求的呼叫对象。
[0142]
下面，参照图4、图5、图6a、图6b、图7a、图7b以及图8，更详细地说明上述根据本公开的一个实施方式的在呼叫支持系统1000中执行的各种处理。为了便于说明各图，有时进行在图10a至图10p所例示的客户端200的显示部250上显示的画面(画面a至p)的说明。另外，关于图4至图8的说明，有时省略或简化重复说明。
[0143]
图4是在根据本公开的一个实施方式的呼叫支持系统1000的服务器100和所有客
户端200上执行的方法400的处理流程图。方法400示出当从服务器100向客户端200通知消息等时的所谓的推送型信息分发处理的流程，并且对应于图3的步骤306或316。作为提供推送型信息分发的服务，例如可以举出“google cloud messaging(gcm)”或“apple push notification service(apns)”。
[0144]
在步骤402中，服务器100(通知发送部112)向呼叫对象列表136内的所有客户端200发送用于通知紧急呼叫开始的推送通知，而不需要来自客户端200的请求。另外，客户端200在接收到通知紧急呼叫开始的推送通知时，在步骤402中，在后台启动安装在客户端200上的用于呼叫支持的应用(未图示)。
[0145]
接着，在步骤404中，客户端200向服务器100请求通知内容。在步骤406中，接收到通知内容的请求的服务器100(通知发送部112)向呼叫对象列表136内的所有客户端200发送通知内容。客户端200(图2中的通知接收部212)接收通知内容。通知内容包括用于识别通知内容的通知类别、消息和与发生的紧急呼叫请求对应的紧急呼叫id。在紧急呼叫开始通知时，通知类别例如为“notification”，消息为表示紧急呼叫开始的“组a的紧急呼叫正在执行中。”。另外，在紧急呼叫结束通知时，通知类别例如是“notification”，消息是表示呼叫结束的“组a的紧急呼叫已结束。”。
[0146]
在步骤408中，客户端200(图2的显示控制部218)生成包含接收到的通知内容的图像，输出到显示部250，显示部250显示该图像，并且进行短时间(例如数秒左右)的通知音输出、终端的振动。图10a例示了紧急呼叫开始时客户端200显示的画面a，图10p例示了紧急呼叫结束时显示的画面p。如图所示，显示部250显示“组a中紧急呼叫正在执行中”(图10a)或“已完成组a的紧急呼叫”(图10p)。客户端200的所有呼叫对象通过确认紧急呼叫开始画面a(或结束画面p)，能够掌握对哪个故障应对候补者组开始(或结束)了紧急呼叫，因此呼叫对象即使不进行消息的开封动作，也能够知道针对各故障的紧急呼叫的开始、结束的状态。
[0147]
接着，参考图5，示出在根据本公开的实施方式的呼叫支持系统1000的服务器100侧和客户端200侧执行的各种处理中、特别是在接收来自所选择的呼叫对象的客户端200的应答结果等的服务器100侧和针对该服务器100侧的处理的所选择的客户端200侧执行的方法500的处理流程。图5所示的方法500大致对应于图3的步骤310至314的处理。另外，以下，对发生了故障、选择用于应对故障的呼叫对象的情况进行说明。
[0148]
在步骤502中，服务器100(图2中的通知发送部112)向所选择的客户端200发送推送通知，并且将推送通知的发送时刻设置为呼叫开始时间cts，并记录在状态数据库138中。客户端200(图2的通知接收部212)在接收到推送通知后，在步骤504中，客户端200向服务器100发送通知内容的请求。例如，如果客户端200在信号范围之外，则当客户端200在信号范围内时，客户端200在步骤502接收推送通知。
[0149]
在步骤506中，服务器100将客户端200是否在最大呼叫时间s秒内请求了步骤504的通知内容的信息记录在数据库138中，更新状态数据库138。如上所述，状态数据库138是包含各客户端200的呼叫结果的历史等的数据库，例如，记录与呼叫对象相关联的各客户端的呼叫历史(呼叫开始时刻cts、呼叫成功的可否(是否在信号范围外)、来自客户端的应答结果(拒绝/应答)、来自客户端的回答结果(能应对/不能应对)、呼叫结束时刻cte、以及这些历史)、针对故障应对的紧急呼叫的开始时刻ets、紧急呼叫结束时刻ete、紧急呼叫成功/失败的状态、紧急呼叫所需时间中的至少一部分信息。图13b示出状态数据库138的示例。状
态数据库138包括表示各紧急呼叫是否成功或失败等的紧急呼叫表138a、和表示对各呼叫对象的呼叫的应答结果或回答结果等的致电表138b。紧急呼叫表138a记录紧急呼叫执行者的用户id、分配给故障应对记录的故障应对记录id、紧急呼叫的状态(成功、失败)、紧急呼叫开始时刻ets、紧急呼叫结束时刻ete、紧急呼叫理由。致电表138b记录紧急呼叫id、与紧急呼叫id对应的各呼叫对象的用户id、表示各呼叫对象的应答结果的致电状态、回答结果、呼叫开始时刻cts、呼叫结束时刻te。另外，呼叫开始时刻cts是指在步骤502中服务器100发送了推送通知的时刻，呼叫结束时刻cte是指距呼叫开始时刻cts最大呼叫时间s秒后的时刻、或者在后述的步骤530中接收到从客户端200发送的回答结果的时刻中的任一个。
[0150]
在步骤508中，接收到通知内容的请求的服务器100(图2的通知发送部112)通过互联网20向所选择的客户端200进行呼叫。这样的呼叫通过向客户端200发送通知内容来进行。服务器100只要能够向所选择的客户端200发送通知内容即可，不进行与呼叫的客户端200的通话。因此，服务器100也可以使用voip(voice over internet protocol)服务来进行这样的呼叫，该voip(voice over internet protocol)服务能够通过将语音/影像数据转换为ip数据包并进行传递来进行通话，但不限于此。向客户端200发送的通知内容包括通知类别、例如“startcall”、持续呼叫客户端的最大呼叫时间s、以及紧急呼叫id。
[0151]
在步骤510中，客户端200(图2的通知接收部212)接收通知内容，客户端200(图2的显示控制部218)根据通知内容生成呼叫画面。客户端200(图2的呼叫部214)可以在最大呼叫时间s内在显示部250上显示呼叫画面(图10b的呼叫画面b)。图10b示出呼叫画面b的示例。如图所示，在呼叫画面b上显示有“应答”按钮以及“拒绝”按钮，呼叫对象可以选择这些按钮中的一个按钮，也可以不对呼叫进行任何操作。另外，在步骤510中，使客户端200鸣响。通过在最大呼叫时间s内使客户端200鸣响或振动，能够提高客户端200的呼叫对象注意到呼叫的可能性。
[0152]
在步骤512中，客户端200(图2的呼叫部214)接受对呼叫画面b的“应答”按钮或“拒绝”按钮的操作。如果在经过最大呼叫时间s之前选择了“应答”按钮或“拒绝”按钮中的一个，则客户端200(图2的呼叫部214)呼叫停止，并进入步骤514。另一方面，在最大呼叫时间s期间未接受选择操作的情况下，客户端200呼叫停止并结束处理。在未接受选择操作的情况下，服务器100将从呼叫开始时刻cts经过最大呼叫时间s后的时刻作为呼叫结束时刻cte记录在状态数据库138中，更新状态表138。
[0153]
在步骤514中，客户端200(图2的呼叫部214)向服务器100发送对呼叫的应答结果(“应答”、“拒绝”)。
[0154]
在步骤516中，服务器100(图2中的应答接收部114)将从客户端200(图2中的呼叫部214)接收到的应答结果(“应答”或“拒绝”)记录在状态数据库138中，并更新状态数据库138。
[0155]
在步骤518中，客户端200(图2中的显示控制部218)生成终端的主页画面，并将其显示在显示部250上。图10c的画面c表示终端的主页画面的示例，在终端主页画面c中显示有用于呼叫支持的应用的图标。当检测到在终端主页画面c上点击了用于呼叫支持的应用的图标时，客户端200(图2中的显示控制部218)在前台启动应用，并且生成应用的主页画面，并在显示部250上显示应用的主页画面。图10d中的画面d1和d2示出应用的主页画面的示例。画面d1是执行紧急呼叫时的应用的主页画面的示例，画面d2是未执行紧急呼叫时的
应用的主页画面的示例。如图10d的d1以及d2所示，应用的主页画面包括“紧急呼叫历史”按钮、“未解决故障应对记录一览”按钮、“创建新故障应对记录”按钮、“故障应对记录一览”按钮。在正在执行紧急呼叫的情况下，应用的主页画面还包含“紧急呼叫正在执行中”按钮(画面d1)，在未执行紧急呼叫的情况下，显示“无紧急呼叫”消息(画面d2)。
[0156]
当用于呼叫支持的应用启动时，在步骤520，在服务器100和客户端200之间建立会话。会话是使用诸如grpc的rpc(remote procedure call)来建立的。
[0157]
在步骤522中，客户端200(图2的更新数据接收部220)向服务器100请求与紧急呼叫id相对应的紧急呼叫的信息。
[0158]
在步骤524中，服务器100(图2的更新数据发送部120)根据该紧急呼叫信息的请求，向客户端200(图2的更新数据接收部220)发送与紧急呼叫id对应的紧急呼叫信息。紧急呼叫信息由从更新后的状态数据库138提取的信息构成，是用于在各客户端200之间共享其他客户端200的呼叫对象是否能够应对等的信息。紧急呼叫信息包含呼叫源信息、紧急呼叫结果、紧急呼叫开始时刻ets、紧急呼叫结束时刻ete中的至少一部分。呼叫源信息包括执行紧急呼叫的人的用户id、紧急呼叫id和与紧急呼叫id相对应的消息。紧急呼叫结果包括紧急呼叫是成功还是失败的信息。紧急呼叫信息还可以包含各呼叫对象的呼叫状况、即表示在最大呼叫时间s以内无操作的“无操作”、呼叫对象对紧急呼叫请求的应答结果(“应答”、“拒绝”)、呼叫对象的回答结果(“能应对”、“不能应对”)、呼叫开始时刻cts、呼叫结束时刻cte的至少一部分。
[0159]
在步骤526中，当客户端200(图2的显示控制部218)检测到在应用的主页画面d1(图10d)中点击了“紧急呼叫正在执行中”按钮时，客户端200(图2的显示控制部218)生成紧急呼叫详情画面，并显示在显示部250上。图10e、图10f和图10g分别表示紧急呼叫详情画面e、f、g的示例。图10e表示呼叫对象没有选择针对紧急呼叫请求的回答时的紧急呼叫详情画面e的示例，图10f以及g表示呼叫对象选择了回答后的紧急呼叫详情画面f、g的示例。
[0160]
如图10e所示，紧急呼叫详情画面e表示能够由呼叫对象选择的“能应对”按钮、“不能应对”按钮。另外，紧急呼叫详情画面e还能够显示上述紧急呼叫信息。所显示的紧急呼叫信息例如如图所示，是开始紧急呼叫的人的姓名“河野太郎”、与故障应对候补者组id对应的故障应对候补者组名“组a”、以及与紧急呼叫id对应的消息“在服务器1中发生了故障”、呼叫对象“佐藤莲”的呼叫结果“无操作”、呼叫开始时刻cts、呼叫结束时刻cte。呼叫对象“佐藤莲”由于从呼叫开始到呼叫结束的时间是最大呼叫时间s的60秒，所以是“无操作”。呼叫对象可以通过紧急呼叫详情画面，用文本确认其他呼叫对象对呼叫的应答结果、回答结果等各种信息。因此，与通过语音通知故障的内容或其他呼叫对象的状况的情况相比，能够正确地确认紧急呼叫的信息。
[0161]
此外，图10e的紧急呼叫详情画面e还能够显示呼叫了呼叫对象列表136全员的最近几周的紧急呼叫信息。在图示例中，仅显示1周的对应部分。
[0162]
返回图5，在步骤528中，客户端200(图2的回答接受部2166)接受对图10e的画面e中显示的“能应对”按钮或“不能应对”按钮的选择回答。在步骤530中，客户端200(图2中的回答接受部216)向服务器100发送回答结果。
[0163]
根据本公开，呼叫对象能够参照画面上显示的紧急呼叫信息，掌握最新的故障的内容以及其他呼叫对象的呼叫状况。因此，呼叫对象在确认了最新的紧急呼叫信息之后，能
够判断自身应对故障还是不能应对故障，做出对于故障的回答。另外，呼叫对象由于能够根据文字信息把握故障的内容，所以与用会听错的语音传达的情况相比，能够正确地把握故障的内容。
[0164]
接着，在步骤532中，服务器100(图2中的回答接收部116)接收客户端200对于呼叫的回答结果，将回答结果记录在状态数据库138中，并更新状态数据库138。另外，服务器100(图2中的回答接收部116)将接收到回答结果的时刻作为呼叫结束时刻cte，记录在状态数据库138，并更新状态数据库138。
[0165]
在步骤534中，服务器100(图2中的更新数据发送部120)将更新后的状态数据库138发送到客户端200。
[0166]
在步骤536中，客户端200(图2中的更新数据接收部220)接收由服务器100更新后的状态数据库138。客户端200(图2中的显示控制部218)根据更新后的状态数据库138，在显示部250上显示紧急呼叫详情画面。图10f表示由作为呼叫对象的“高桥大翔”选择了“能应对”按钮时的紧急呼叫详情画面f的示例。图10g表示呼叫对象选择了“不能应对”按钮时的紧急呼叫详情画面f的示例。
[0167]
另外，更新后的紧急呼叫详情画面可以由呼叫对象列表136内的所有呼叫对象确认。因此，根据本公开，能够经由更新后的紧急呼叫详情画面，与其他呼叫对象共享能否应对自身的最新故障的状况等。
[0168]
接下来参考图6a，将更详细地说明当服务器100呼叫所选择的客户端200并从所选择的客户端200接收应答结果时在服务器100上执行的方法600a。另外，以下，有时对在图3和图4中已经说明的步骤省略说明。
[0169]
图6a所示的步骤602a和步骤604a对应于图3的步骤310。另外，图6a所示的步骤602a、步骤604a分别与图5所示的步骤502、步骤508对应。因此，省略对图6a所示的步骤602a和步骤604a的说明。图6a所示的步骤606a至步骤614a对应于图5所示的步骤516，以下将更详情地描述这些步骤。
[0170]
在步骤606a中，服务器100(应答接收部114)在步骤606a中判定在从呼叫开始时刻cts起最大呼叫时间s秒以内是否接收到应答结果，即是否有针对呼叫的操作。在最大呼叫时间s期间无操作的情况下(在步骤606a中为“否”的情况)，即在“无操作”下呼叫失败的情况下，进入步骤610a。在步骤610a中，服务器100(应答接收部114)将针对客户端200的呼叫的状态“无操作”、和从呼叫开始时刻cts经过最大呼叫时间s秒后的时刻作为呼叫结束时刻cte记录在状态数据库138中，结束处理。
[0171]
另一方面，在最大呼叫时间s期间进行了操作的情况下(在步骤606a中为“是”的情况)，即接收到的应答结果为“应答”或“拒绝”的任一个的情况下，进入步骤608a。在步骤608a中，服务器100(应答接收部114)在应答结果为“拒绝”的情况下，进入步骤612a，将应答结果“拒绝”记录在状态数据库138中。另一方面，在步骤610a中，在应答结果为“应答”的情况下，进入步骤614a，服务器100将应答结果“应答”记录在状态数据库138中。
[0172]
接下来，参考图6b，对在客户端200处执行的方法600b进行更详细地说明，其中所选择的客户端200进行呼叫并向服务器100发送应答结果。方法600b对应于图6a的方法600a的服务器100侧的处理。下面，参考图6b描述根据本公开的实施方式的客户端200侧的呼叫、应答结果的发送处理等。
[0173]
图6b所示的步骤602b、步骤604b和步骤606b分别对应于图5所示的步骤502、步骤508和步骤510。因此，省略对图6b所示的步骤602b、步骤604b、步骤606b的说明。图6b中所示的步骤608b和610b对应于图5所示的步骤512，下面将更详细地说明这些步骤。
[0174]
在步骤608b中，客户端200(图2的呼叫部214)在从接收到来自服务器100的呼叫起的最大呼叫时间s期间，判定是否有针对图10b的呼叫画面b中显示的“应答”按钮或“拒绝”按钮中的任一个的选择操作。
[0175]
在步骤608b中为“是”的情况下，即在最大呼叫时间s以内有选择操作的情况下，进入步骤610b，客户端200(图2的呼叫部214)呼叫停止，进入步骤612b。
[0176]
步骤612b是与服务器100侧的步骤606a的处理对应的客户端200侧的处理。在步骤612b中，客户端200(图2的呼叫部214)向服务器100(图2的应答接收部114)发送对呼叫的应答结果，而不打开与服务器100之间的语音通道。应答结果包括表示在最大呼叫时间s以内在客户端200中选择了“应答”按钮或“拒绝”按钮的信息。根据本公开，即使在客户端200对呼叫应答了的情况下，客户端200也仅停止呼叫，而不打开与服务器的语音通道。另外，在上述服务器100侧的步骤606a的处理中，服务器100接收在步骤612b中发送的应答结果。
[0177]
另一方面，在步骤608b中为“否”的情况下，即在最大呼叫时间s以内没有接受到对象对“应答”按钮或“拒绝”按钮的选择操作的情况下，进入步骤614b，客户端200(图2的呼叫部214)停止呼叫，结束处理。
[0178]
接着，参考图7a，对服务器100从呼叫对象列表136中的所有客户端200接收回答时的在服务器100执行的方法700a的处理进行说明。图7b是与图7a的服务器100侧的处理对应的客户端200侧的处理。另外，以下，有时对在图5中已经说明的步骤省略说明。
[0179]
图7a的步骤702a、步骤704a分别对应于图5的步骤524和步骤530。因此，省略对这些步骤的说明。在步骤702a中，假设服务器100通过图3中说明的步骤306的处理向所有客户端200发送紧急呼叫开始通知。另外，图7a的步骤706a至步骤710a对应于图5的步骤532，下面将更详细地进行说明。
[0180]
在步骤706a中，服务器100(图2的回答接收部116)判定从客户端接收到的回答结果是否为“能应对”，在回答结果为“能应对”的情况下，进入步骤708a。在步骤708a中，服务器100将存储在状态数据库138中的能应对人数r增加1，进入步骤710a，将接收到“能应对”的时刻作为呼叫结束时刻cte与回答结果一起保存至状态数据库138。
[0181]
另一方面，在步骤706a中，在从客户端接收到的回答结果为“不能应对”的情况下，服务器100不增加能应对人数r，在步骤710a中，与回答结果一起，将接收到“不能应对”的时刻作为呼叫结束时刻cte保存至状态数据库138。
[0182]
接着，根据图7b，说明呼叫对象列表136内的所有客户端者200向服务器100发送回答时的处理流程。假设在方法700b的流程之前，通过图3中说明的步骤306的处理，所有客户端200都从服务器100接收紧急呼叫开始通知。图7b的客户端200侧的步骤704b和步骤708b中的处理分别对应于图7a的服务器100侧的步骤702a和步骤704a中的处理。
[0183]
在步骤702b中，当客户端200(图2的显示控制部218)检测到用于呼叫支持的应用的图标(图10c所示的终端主页画面c的图标)被点击时，用于呼叫支持的应用在前台启动。客户端200(显示控制部218)在显示部250上显示应用的主页画面(图10d中所示的d1画面)。另外，客户端200的呼叫对象即使没有接收到来自服务器100的呼叫，也能够从终端主页画
面c启动应用。
[0184]
在步骤704b中，在建立服务器100和客户端200之间的会话之后，客户端200(图2的更新数据接收部220)从服务器100(图2的更新数据发送部120)接收紧急呼叫信息。
[0185]
在步骤706b中，客户端200(显示控制部218)接受来自呼叫对象的对应用主页画面d1的操作，并显示表示接收到的紧急呼叫信息的紧急呼叫详情画面(图10e所示的e的画面)。紧急呼叫详情画面e包括可选择的“能应对”按钮以及“不能应对”按钮。
[0186]
在步骤708b中，客户端200(图2的回答接受部216)接受对图10e的画面e中显示的“能应对”按钮或“不能应对”按钮的选择回答，并将回答结果发送给服务器100(图2的回答接收部116)。根据本公开，客户端200即使没有接收到来自服务器100的呼叫，通过启动用于呼叫支持的应用，呼叫对象的任何人都能够向服务器100发送回答结果。即，所有的客户端200能够不依赖于服务器100的呼叫(图3的步骤310)的处理，进行“能应对”的回答结果的发送处理。由此，如果在紧急呼叫开始通知(图3的步骤306)时刻呼叫对象的某人能够注意到紧急呼叫而回答“能应对”，则能够减少紧急呼叫的次数，因此，特别是在休息日或夜间的紧急呼叫中，能够减少其他呼叫对象的负担。此外，如果是在服务器100的紧急呼叫结束通知(图3的步骤316)之前，则所有客户端200可以通过重复方法700b中所示的处理来重复地向服务器100发送回答结果。
[0187]
接着，使用图8对在该呼叫支持系统1000中进行了对某个客户端200的选择操作或输入操作时更新各种数据库的处理进行说明。图8表示在对进行了选择操作或输入操作后的数据进行更新的客户端200a、服务器100、与更新数据的客户端200a以外的、应用启动中的所有客户端200n之间进行的处理的流程。另外，以下，假设在更新数据的客户端200a中，已经接受了来自呼叫对象的用于数据库更新的选择操作以及输入操作。
[0188]
选择操作是由呼叫对象进行的对显示在显示部250上的各种按钮的选择操作。作为一例，可以举出上述的“应答”按钮、“拒绝”按钮(图10b的呼叫画面b)的选择操作、或者选择“能应对”、“不能应对”按钮(图10e的画面e等)的操作。
[0189]
输入操作是由呼叫对象进行的、用于输入文本的操作。呼叫对象作为一例如图10m的画面m所示，可以输入故障应对记录的标题(在图10m中为“服务器1故障”)、故障应对记录的详细内容(在图10m中为“服务器1发生了硬件故障。已联系维修窗口修理了。”)。另外，作为其他示例，如图10l的画面l所示，呼叫对象能够输入针对故障应对记录的注释。
[0190]
当在客户端200中启动用于呼叫支持的应用时，在步骤802中，在更新了数据的客户端200a与服务器100之间、以及正在启动该数据更新后的客户端200a以外的应用的所有客户端200n与服务器100之间建立会话。
[0191]
在步骤804中，数据更新后的客户端200a向服务器发送更新数据。更新数据不限于应答结果、回答结果，还包括其他各种数据，例如故障应对记录等。
[0192]
在步骤806中，服务器100(图2的更新数据发送部120)根据从进行了数据更新的客户端200a接收到的更新数据来更新各种数据库。各种数据库不限于状态数据库138，包括记录了各呼叫对象的故障应对记录的数据库等。
[0193]
在步骤808中，服务器100(图2的更新数据发送部120)向客户端200a发送更新后的数据库。
[0194]
在步骤810中，数据更新后的客户端200a(图2的显示控制部218)根据更新后的数
据库，使显示部250更新显示画面。
[0195]
另外，在步骤812中，服务器100(图2的更新数据发送部120)向数据更新后的客户端200a以外的所有客户端200n发送更新后的数据库。
[0196]
在步骤8144中，客户端200n(图2的显示控制部218)根据更新后的数据库，使显示部250更新显示画面。
[0197]
图9示出客户端200在显示部250上显示的画面的转变图。该图中所示的a至p的符号对应于图10的a至p所示的画面a至p的编号。图10a至图10p例示了显示控制部218使显示部250显示的画面。在下文中，将参考图9和图10a至图10p说明在客户端200上显示的画面的转变。另外，有时省略与关于图10a至图10p已经说明的内容重复的说明。
[0198]
图10d示出用于呼叫支持的应用的主页画面。图10d的画面d1表示故障应对候补者组名是组a，紧急呼叫正在执行中。另一方面，图10d的画面d2表示故障应对候补者组名是组a，以及未执行紧急呼叫。图10d的应用主页画面d1以及d2所示的“紧急呼叫历史”按钮、“未解决故障应对记录一览”按钮、“创建新故障应对记录”按钮、“故障应对记录一览”按钮被客户端200的呼叫对象选择时，按照图9的画面转变图进行转变。
[0199]
更具体而言，如果在图10d的应用主页画面d1中选择了“紧急呼叫正在执行中”按钮，则显示图10e的紧急呼叫详情画面e。该紧急呼叫详情画面e包含“故障应对记录的创建”按钮和“致电历史”按钮。
[0200]
在紧急呼叫详情画面e中，当选择“故障应对记录的创建”按钮时，显示图10j的新故障应对记录的创建画面j。客户端200的呼叫对象能够在新故障应对记录的创建画面j中输入应对新故障的故障应对记录(标题以及详细内容)。另一方面，在紧急呼叫详情画面e中，如果选择了“致电历史”按钮，则显示图10h的致电历史画面h。致电历史画面h包括与故障应对候补者组id相对应的所有呼叫对象的呼叫开始时间cts、呼叫结束时间cte和呼叫结果。
[0201]
另外，如果在图10d的应用主页画面d1、d2中选择了“紧急呼叫历史”按钮，则显示图10i的紧急呼叫历史画面i。紧急呼叫历史画面i包括所有紧急呼叫id的历史。紧急呼叫历史画面i按每个紧急呼叫id设定有显示紧急呼叫的结果(成功、失败)、与紧急呼叫id对应的消息的内容、紧急呼叫开始时间ets、紧急呼叫结束时间ete的按钮。当接受对这些按钮之一的选择操作时，显示上述紧急呼叫详情画面e。
[0202]
另外，当在图10d的应用主页画面d1、d2中选择“未解决故障应对记录一览”按钮时，显示图10n的未解决故障应对记录一览画面n。未解决故障应对记录一览画面n包括分别显示与一个故障应对候补者组id对应的故障应对记录的多个按钮(在图10n中为一个)。当在未解决故障应对记录一览画面n中接受对这些按钮之一的选择操作时，显示图10k的故障应对记录的详情画面(未解决)k。故障应对记录的详情画面k显示与故障应对候补者组id对应的各呼叫对象的对应历史、对应时间等。
[0203]
另外，在图10d的应用主页画面d1、d2或图10e的紧急呼叫详情画面e中，如果选择了“创建新故障应对记录”按钮，则显示图10j的新故障应对记录的创建画面j。客户端200的呼叫对象能够在新故障应对记录的创建画面j中输入故障应对记录的标题和故障应对记录的详细内容。另外，在图10j的新故障应对记录的创建画面j中，若选择“故障应对记录的创建”按钮，则生成未解决故障应对记录。之后，在对故障应对记录的应对完成的情况下，呼叫
应对者能够将故障应对记录的状态变更为解决完毕。
[0204]
进而，在图10d的画面d1以及d2中，当选择“故障应对记录一览”按钮时，显示图10o的故障应对记录的一览画面o。故障应对记录的一览画面o包含分别显示与一个故障应对候补者组id对应的故障应对记录的多个按钮(在图10o中为3个)，当接受对这些按钮之一的选择操作时，显示图10k的故障应对记录的详情画面k(未解决)或图10l的故障应对记录的详情画面l(解决完毕)。客户端200的呼叫对象能够在故障应对记录的详情画面k、l中分别输入针对故障应对记录的注释。客户端200的呼叫对象通过在故障应对记录的详情画面k、l中向“追加注释”的栏中输入注释并按下“发送”按钮，能够使注释反映在故障应对记录的详情画面k、l中，并与其他呼叫对象进行聊天。故障应对记录的详情画面k、l例示了客户端200的呼叫对象和其他呼叫对象进行的聊天的历史。聊天的历史包括输入了注释的呼叫对象的姓名、由呼叫对象输入的注释、输入日期时间、输入时刻。
[0205]
另外，在图10k或图10l的故障应对记录的详情画面k、l中，如果选择了“编辑故障应对记录”按钮，则显示图10m的故障应对记录的详情(编辑)画面m。在图10m的故障应对记录的详情(编辑)画面m中，客户端200的呼叫对象能够输入针对故障应对候补者组id的故障应对记录的标题(例如服务器1故障)、故障应对记录的详细内容(例如，服务器1发生了硬件故障)。当选择图10m的故障应对记录的详情(编辑)画面m的更新按钮时，更新故障应对记录。
[0206]
以上，对本公开的实施方式进行了说明，但上述发明的实施方式是为了容易理解本公开，并不限定本公开。当然，在不脱离其主旨的情况下，可以对本公开进行变更、改良，并且在本公开中包含其等同物。另外，在能够解决上述课题的至少一部分的范围、或者起到效果的至少一部分的范围内，能够进行实施方式和变形例的任意组合，能够进行权利要求书和说明书中记载的各构成要素的任意组合或省略。
[0207]
符号说明
[0208]
10...监视系统
[0209]
12...监视终端
[0210]
20...互联网
[0211]
100...呼叫支持服务器
[0212]
110...处理器
[0213]
112...通知发送部
[0214]
114...应答接收部
[0215]
116...回答接收部
[0216]
118...呼叫控制部
[0217]
120...更新数据发送部
[0218]
130...存储器
[0219]
132...控制程序
[0220]
134...故障应对候补者组表
[0221]
136...呼叫对象列表
[0222]
138...状态数据库
[0223]
138a...紧急呼叫表
[0224]
138b...致电表
[0225]
200...客户端
[0226]
210...处理器
[0227]
212...通知接收部
[0228]
214...呼叫部
[0229]
216...回答接受部
[0230]
218...显示控制部
[0231]
220...更新数据接收部
[0232]
230...存储器
[0233]
232...更新的状态数据库
[0234]
250...显示部。