具体实施方式

(作为本发明的基础的认识)

例如，考虑对酒店的房间安装电子锁并通过区块链(分布式账本)来进行房间的进出管理的服务。在提供这样的服务的情况下，用户能够利用区块链事前预订房间。并且，当用户到达了酒店时，如果将IC卡等覆盖在安装于房间的电子锁上，则根据在分布式账本上是否具有将该电子锁开锁的权利来进行该用户能否进出的验证。在该用户有将该电子锁开锁的权利的情况下进行开锁。通过这样，使得不正当的用户不能篡改权限或盗取并使用电子钥匙。

但是，如上述那样，在安装于房间的电子锁故障的情况下，有虽然在分布式账本上能进行该房间的预订及开锁等的操作，但实际上不能使用房间即设备的问题。

所以，在本发明中，提出在实际使用设备时检测设备是否故障，在故障的情况下使得不能使用设备的技术。换言之，本发明提供能够使用分布式账本抑制故障的设备的利用的故障监视方法等。

有关本发明的一技术方案的故障监视方法，由故障监视系统中的监视装置执行，上述故障监视系统具备用户使用的终端、作为上述用户的操作对象的设备、上述监视装置、以及分别具有分布式账本的多个认证服务器，上述终端、上述监视装置以及上述多个认证服务器能够经由网络进行通信，其中，从上述多个认证服务器中的第1认证服务器取得表示根据以下请求而生成的事件并且上述多个认证服务器所保存的事件信息，上述请求是上述终端对上述第1认证服务器发送的请求，并且是上述用户经由上述终端生成的包含用于上述用户操作上述设备的处理命令的请求；从上述设备取得表示上述设备是否故障的状态信息；通过生成包含所取得的上述状态信息的第1交易数据并发送给上述第1认证服务器，使上述第1交易数据记录到上述多个认证服务器的上述分布式账本中；在根据上述状态信息确认到上述设备没有故障的情况下，将包含在上述事件信息中的上述处理命令发送给上述设备。

由此，能够使用分布式账本，抑制故障的设备的利用。更具体地讲，使监视装置监视用户的操作对象的设备是否故障，用分布式账本管理表示该设备是否故障的状态信息。由此，不仅使得该设备的状态信息不能篡改，而且能够抑制故障的设备的利用。

进而，由于知道能够进行在区块链上利用的操作的设备是实际能够使用的设备，所以能够消除移动到设备所在的位置才知道实际是否能够使用的状态。因此，移动到处于故障中而不能进行操作的设备的位置所耗费的时间和能量不会成为浪费，能够抑制时间和能量耗费，此外，还能够得到利用区块链的服务的可靠性。

这里，例如也可以是，上述请求还包含能够使上述设备执行上述处理命令的上述设备的权限的移交请求；上述事件信息还包含表示存在上述设备的权限的移交请求的信息；当取得了上述状态信息时，在根据上述状态信息确认到上述设备没有故障的情况下，生成表示认可上述移交请求之意的第2交易数据，并发送给上述第1认证服务器；在根据上述状态信息确认到上述设备故障的情况下，生成表示拒绝上述移交请求之意的第3交易数据，并发送给上述第1认证服务器。

此外，例如也可以是，上述请求还包含能够使上述设备执行上述处理命令的上述设备的权限的移交；上述事件信息还包含表示存在上述设备的权限的移交的信息；当取得了上述状态信息时，在根据上述状态信息确认到上述设备故障的情况下，生成表示将上述移交退回之意的第4交易数据，并发送给上述第1认证服务器。

此外，例如也可以是，还生成上述第1交易数据，并将包含所生成的第1交易数据的区块记录到上述分布式账本中。

此外，例如也可以是，当记录到上述分布式账本中时，仅在根据上述状态信息确认到上述设备故障的情况下，生成包含上述状态信息的上述第1交易数据。

此外，例如也可以是，还在上述第1认证服务器中，将表示包含上述处理命令的请求的第5交易数据记录到上述分布式账本中。

此外，有关本发明的一技术方案的监视装置，是故障监视系统中的监视装置；上述故障监视系统具备用户使用的终端、作为上述用户的操作对象的设备、上述监视装置、以及分别具有分布式账本的多个认证服务器，上述终端、上述监视装置以及上述多个认证服务器能够经由网络进行通信；上述监视装置具备：事件信息监视部，从上述多个认证服务器中的第1认证服务器取得表示根据以下请求而生成的事件并且上述多个认证服务器所保存的事件信息，上述请求是上述终端对上述第1认证服务器发送的请求，并且是上述用户经由上述终端生成的包含用于上述用户操作上述设备的处理命令的请求；故障确认部，从上述设备取得表示上述设备是否故障的状态信息，通过生成包含所取得的上述状态信息的第1交易数据并发送给上述第1认证服务器，使上述第1交易数据记录到上述多个认证服务器的上述分布式账本中；以及处理命令请求部，在根据上述状态信息确认到上述设备没有故障的情况下，将包含在上述事件信息中的上述处理命令发送给上述设备。

以下，参照附图对实施方式进行说明。另外，以下说明的实施方式都表示本发明的一具体例。在以下的实施方式中表示的数值、形状、材料、构成要素、构成要素的配置位置及连接形态、步骤、步骤的顺序等是一例，不是限定本发明的意思。此外，关于以下的实施方式的构成要素中的、在表示最上位概念的独立权利要求中没有记载的构成要素，设为任意的构成要素进行说明。此外，各图并不一定是严密地图示的。在各图中，对于实质上相同的构成赋予相同的标号，有将重复的说明省略或简化的情况。

此外，只要不脱离本发明的主旨，对实施方式施以本领域技术人员想到的各种变形后的形态、或在全部的实施方式中将各个实施方式的一部分构成要素组合而构建的其他形态也包含在本发明的范围中。

(实施方式)

首先，对本发明的故障监视系统进行说明。

[1.故障监视系统]

本发明的故障监视系统具备用户使用的终端、作为用户的操作对象的设备、监视装置、以及分别具有分布式账本的多个认证服务器。本发明的故障监视系统用分布式账本(区块链)来管理表示作为用户的操作对象的设备是否故障的状态信息，在该设备故障的情况下能够停止利用。

以下，参照附图进行实施方式的故障监视系统等的说明。

[1.1故障监视系统的整体构成]

图1是表示有关实施方式1的故障监视系统的整体构成的一例的图。图1所示的故障监视系统具备终端20、例如3个认证服务器30a、30b、30c、监视装置10和设备40。它们通过有线的因特网、无线通信、专用通信等的网络被连接。另外，这些通信也可以不是实时的。例如，终端20也可以将交易数据某种程度集中后，同时将它们发送给多个认证服务器30a、30b、30c。

另外，在图1中表示了在故障监视系统中1台监视装置10对1台设备40进行故障监视的情况下的例子，但并不限于此。图2A～图2C是表示构成图1所示的故障监视系统的监视装置和设备的另一例的图。即，如图2A所示，也可以是1台监视装置10监视例如设备40a、40b、40c等1台以上的设备40的构成。此外，如图2B所示，如果设备40和监视装置10的台数是相同数量，则也可以分别有多个。更具体地讲，虽然1台监视装置10对1台设备40进行故障监视，但也可以由例如监视装置10a、10b、10c等多台监视装置10和例如设备40a、40b、40c等1台以上设备40构成。此外，如图2C所示，也可以是设备40和监视装置10分别有多台、从1台以上的监视装置10监视1个设备40的构成。

此外，在图1中表示了故障监视系统具备1个终端20和3个认证服务器30的情况下的例子，但并不限于此。故障监视系统也可以具备2个以上的终端20，只要具备1个以上的认证服务器30即可。

[1.2终端]

图3是表示有关实施方式的终端20的构成的一例的图。终端20如图3所示，具备交易数据生成部201和通信部202。终端20例如被安装于具备处理器(微处理器)、存储器、通信接口等的计算机或便携终端。此外，终端20包括接受来自用户的输入的接口而构成。在设备40是房间的门的情况下，接口例如可以是用来打开门的按钮，在设备40是照明的情况下，接口例如可以是使照明点亮的按钮。

[1.2.1交易数据生成部]

交易数据生成部201生成包含通过用户的输入而选择的操作对象的设备40和用户请求的处理命令的交易数据。例如，交易数据生成部201在由用户按下了用来打开门的按钮或使照明点亮的按钮的情况下，生成包含打开门或使照明点亮的处理命令的交易数据。

交易数据生成部201将所生成的交易数据发送给通信部202。

这里，使用图4A～图4F，说明交易数据生成部201生成的交易数据的一例。

图4A～图4F是表示由有关实施方式的交易数据生成部201生成的交易数据中包含的处理命令等的一例的图。

在图4A及图4B中，表示了包含通过用户的输入而选择的操作对象的设备(表示为对象设备)和用户请求的处理命令的交易数据的例子。更具体地讲，在图4A中示出了表示对象设备为照明1、处理命令为点亮的交易数据，在图4B中示出了表示对象设备是玄关门1、处理命令为开锁的交易数据。另外，在处理命令为自明而不需要记载的情况下，交易数据也可以仅包含对象设备。此外，在对多个设备请求相同的处理命令的情况下，也可以制作对象设备的数量的图4A、图4B所示的交易数据，也可以例如如图4C那样将多个对象设备包含在1个交易数据中。这里，在图4C中示出了表示对象设备为照明1、照明2、照明3，处理命令为点亮的交易数据。

此外，如图4D那样，也可以与图4A相比还附加制作者的签名。由此，能够确认交易数据的制作者和想要操作对象设备的用户是否相同。此外，如图4E那样，也可以与图4A相比还附加交易数据的发布日期时间。由此，能够使得针对对象设备的多个处理命令的执行顺序不变化。此外，图4F那样，也可以与图4A相比还指定作为想要执行处理命令的日期时间的处理日期时间。

[1.2.2通信部]

通信部202经由网络进行与认证服务器30a、30b、30c的通信。在本实施方式中，通信部202将交易数据生成部201生成的交易数据发送给认证服务器30a、30b、30c。

这样，终端20接受来自用户的输入，制作包含用于用户操作设备40的处理命令的请求，对多个认证服务器30中的至少一个认证服务器(例如第1认证服务器)发送。在本实施方式中，终端20生成包含制作出的请求的交易数据，发送给认证服务器30a、30b、30c。

另外，在用户能够操作的设备40有多个的情况下，只要通过用户的输入从多个设备40中选择操作对象的设备40即可。

图5是表示有关实施方式的终端20A的构成的一例的图。对于与图3同样的要素赋予相同的标号，省略详细的说明。图5所示的终端20A是用户能够操作的设备40有多个的情况下的构成，与图3所示的终端20相比，还具备对象设备选择部203。对象设备选择部203通过用户的输入，从多个设备40中选择操作对象的设备40。此外，对象设备选择部203选择通过用户的输入而选择的设备40的处理命令。并且，对象设备选择部203将所选择的设备40和处理命令发送给交易数据生成部201。

[1.3认证服务器]

图1所示的认证服务器30a、30b、30c例如是云服务器。由于认证服务器30a、30b、30c具有同样的构成，所以以下对代表它们的认证服务器30的构成进行说明。另外，认证服务器30具有分布式账本(未图示)。此外，认证服务器30a、30b、30c中的某一个是第1服务器的一例。

图6是表示有关实施方式的认证服务器30的构成的一例的图。认证服务器30具备交易数据保存部301、交易数据验证部302、事件发布部303、事件信息保存部304和通信部305。另外，交易数据验证部302不是必须的。认证服务器30可以通过由处理器使用存储器执行规定的程序来实现。以下，对各构成要素进行说明。

[1.3.1交易数据保存部]

交易数据保存部301保存从终端20或监视装置10接收到的交易数据。另外，交易数据保存部301也可以由暂时保存交易数据的区域和作为分布式账本发挥功能的区域构成。在此情况下，交易数据保存部301将从终端20或监视装置10接收到的交易数据作为分布式账本进行记录(保存)。

[1.3.2交易数据验证部]

交易数据验证部302验证从终端20或监视装置10发送来的交易数据的正当性。具体而言，交易数据验证部302例如验证交易数据是否被赋予了以正确的方法生成的加密签名，或者交易数据中包含的处理命令是否是有意义的内容等。在交易数据验证部302中，在交易数据被验证为正当情况下，向事件发布部303发送而将事件发布。

[1.3.3事件发布部]

事件发布部303发布关于由交易数据验证部302验证了正当性的交易数据的事件。这里，事件是根据用户经由终端20生成的包含用于用户操作设备40的处理命令的请求而生成的。在本实施方式中，事件中包含交易数据中包含的处理命令、对象设备等信息。另外，事件也可以包含交易数据。

事件发布部303将所发布的事件发送给事件信息保存部304。

[1.3.4事件信息保存部]

事件信息保存部304将由事件发布部303发布的事件作为事件信息保存。此外，事件信息保存部304在从监视装置10有事件信息的询问或请求时，对监视装置10发送事件信息。

[1.3.5通信部]

通信部305经由网络与终端20、其他认证服务器30及监视装置10进行通信。在本实施方式中，通信部305将从终端20或监视装置10发送来的交易数据向交易数据保存部301保存。此外，通信部305将从交易数据验证部302发送来的交易数据传送给其他认证服务器30。通信部305在从监视装置10有事件信息的请求或询问的情况下，从事件信息保存部304接受事件信息，发送给监视装置10。

[1.4监视装置]

接着，对监视装置10进行说明。

图7是表示有关实施方式的监视装置10的构成的一例的图。监视装置10具备事件信息监视部101、故障确认部102、通知部103、处理命令请求部104和通信部105，对设备40进行监视。监视装置10例如被安装于具备处理器、存储器、通信接口等的计算机。

[1.4.1事件信息监视部]

事件信息监视部101对认证服务器30a、30b、30c中的某一个进行事件信息的询问或发送的请求，取得事件信息。事件信息监视部101进行询问等的事件信息既可以是包含目前为止发布的全部事件的事件信息，也可以是仅包含在前次进行了询问等时以后发布的事件的事件信息。

事件信息监视部101在取得事件信息后，向故障确认部102请求在未执行的事件中包含的处理命令的对象设备的故障确认。此时，将未执行的事件发送给故障确认部102。

[1.4.2故障确认部]

故障确认部102从设备40取得表示该设备是否故障的状态信息。在本实施方式中，故障确认部102确认在从事件信息监视部101接受的事件信息中是否有针对监视装置10所监视的设备40的处理命令。如果在事件信息中有针对设备40的处理命令，则故障确认部102确认设备40是否故障。故障确认部102为了确认设备40是否故障，从设备40取得状态信息。故障确认部102根据所取得的状态信息，确认设备40是否故障。另外，确认设备40是否故障的方法没有被限定，例如可以对设备40发送消息并根据有无回送来确认，也可以通过其他的方法确认。

故障确认部102将所取得的状态信息发送给通知部103。

[1.4.3通知部]

通知部103从故障确认部102接受设备40的状态信息，生成包含所取得的状态信息的交易数据，并发送给至少一个认证服务器30。这里，通知部103也可以仅在由故障确认部102根据状态信息确认到设备40故障的情况下生成包含状态信息的交易数据。在本实施方式中，通知部103在由故障确认部102确认到设备40故障的情况下，生成包含状态信息的交易数据，并发送给认证服务器30a、30b、30c。另外，通知部103也可以在由故障确认部102确认到设备40没有故障的情况下，也生成包含状态信息的交易数据，并发送给认证服务器30a、30b、30c。

这里，使用图8及图9，说明通知部103生成的交易数据的一例。

图8及图9是表示由有关实施方式的通知部103生成的交易数据的一例的图。在图8中，示出了包含表示确认日期时间为2019/12/1 17:30、对象设备为照明1、故障状况为故障的状态信息的交易数据。在图9中，示出了包含表示确认日期时间为2019/12/1 17:30、对象设备为照明1、故障状况为正常的状态信息的交易数据。

[1.4.4处理命令请求部]

处理命令请求部104在根据故障确认部102所取得的状态信息确认到设备40没有故障的情况下，将事件信息中包含的处理命令发送给设备40。在本实施方式中，处理命令请求部104在故障确认部102根据状态信息确认到设备40没有故障的情况下，对设备40请求在从故障确认部102接受的事件信息中包含的处理命令的执行。

[1.4.5通信部]

通信部105经由网络与认证服务器30a、30b、30c及设备40进行通信。在本实施方式中，通信部105对认证服务器30a、30b、30c发送询问事件信息或请求事件信息的发送的消息，作为回送而接收事件信息。通信部105将通知部103生成的交易数据发送给认证服务器30a、30b、30c。通信部305对设备40发送处理命令，请求处理命令的执行。

这样，监视装置10基于所取得的事件信息，取得设备40是否故障的状态信息。监视装置10在设备40正常动作的情况下，对设备40请求事件信息中包含的处理命令的执行。在设备40故障的情况下，将包含状态信息的交易数据发送给认证服务器30a、30b、30c，使状态信息登记到分布式账本中。另外，监视装置10也可以在设备40正常动作的情况下，也将包含状态信息的交易数据发送给认证服务器30a、30b、30c而使状态信息登记到分布式账本中。

[1.5设备]

接着，对设备40进行说明。设备40例如也可以是空调、锁柜、配送BOX、e-Bike、e自行车或投币洗衣机，也可以是安装于它们的电子锁。

图10是表示有关实施方式的设备40的构成的一例的图。有关实施方式的设备40具备处理命令执行部401和通信部402。

[1.5.1处理命令执行部]

处理命令执行部401执行从监视装置10发送的处理命令。

[1.5.2通信部]

通信部402经由网络进行与监视装置10的通信。在本实施方式中，通信部402从监视装置10接受处理命令，并发送给处理命令执行部401。

这样，设备40从监视装置10接受处理命令，执行处理。

[2.动作]

使用流程图对如以上这样构成的故障监视系统的监视装置10的故障监视方法进行说明。

图11是表示有关实施方式的故障监视方法的流程图。

首先，如图11所示，监视装置10从第1认证服务器取得多个认证服务器30保存的事件信息(S11)。这里，事件信息如上述那样包含根据以下请求生成的事件，上述请求是终端20对多个认证服务器30中的第1服务器发送的请求，并且是用户经由终端20生成的包含用于用户对设备40进行操作的处理命令的请求。

接着，监视装置10从设备40取得表示该设备是否故障的状态信息(S12)。

接着，监视装置10生成包含步骤S12中取得的状态信息的第1交易数据，发送给第1认证服务器(S13)。由此，能够使第1交易数据记录到多个认证服务器30的分布式账本中。

接着，监视装置10在根据步骤S12中取得的状态信息确认到设备40没有故障的情况下，将事件信息中包含的处理命令发送给设备40(S14)。

接着，使用顺序图对如以上那样构成的故障监视系统的动作进行说明。作为故障监视系统的动作，分为用户请求发送动作和故障监视动作这两个阶段进行说明。

[2.1用户请求发送动作]

以下，对故障监视系统的用户请求发送动作进行说明。

图12是表示有关实施方式的故障监视系统的用户请求发送动作的一例的顺序图。

首先，终端20接受用户的输入，选择操作对象的设备(在图中是对象设备)和对该设备的处理命令(S101)。

接着，终端20生成包含步骤S101中选择的设备的信息和处理命令的交易数据(以下称作第5交易数据)并发送(S102)。这里，第5交易数据如上述那样，除了处理命令以外也可以还包含对象设备的信息、交易数据的制作日期时间或用户的签名。在图12所示的例子中，终端20将所生成的第5交易数据发送给认证服务器30a、30b、30c。另外，终端20也可以将所生成的第5交易数据仅发送给认证服务器30a、30b、30c中的某一个。在此情况下，认证服务器30a、30b、30c中的某一个向其他的认证服务器传送第5交易数据。

接着，在认证服务器30a、30b、30c中，接收在步骤S101中发送的第5交易数据，暂时向交易数据保存部301保存(S103)。

接着，认证服务器30a、30b、30c执行共识(consensus)算法(S104)。更详细地讲，首先，认证服务器30a、30b、30c读取保存在交易数据保存部301中的第5交易数据，进行第5交易数据的正当性的验证。正当性的验证例如通过确认第5交易数据中包含的处理命令的整合性、发布日期时间及名称等来进行。认证服务器30a、认证服务器30b和认证服务器30c如果验证了接收到的第5交易数据的正当性，则分别生成包含第5交易数据的区块。并且，认证服务器30a、30b、30c将包含第5交易数据的区块记录到交易数据保存部301的作为分布式账本发挥功能的区域。这样，表示包含处理命令的请求的第5交易数据被记录到分布式账本即区块链中。

接着，认证服务器30a、30b、30c发布关于第5交易数据的事件(S105)。关于第5交易数据的事件，如上述那样，是根据包含用于用户对设备进行操作的处理命令的请求而生成的事件，例如包含发布日期时间和第5交易数据。

[2.2故障监视动作]

接着，对故障监视系统的故障监视动作进行说明。

图13是表示有关实施方式的故障监视系统的故障监视动作的一例的顺序图。

首先，监视装置10对于认证服务器30a、30b、30c中的1个认证服务器(在图中是认证服务器30c)确认是否发布了事件(S201)。在本实施方式中，监视装置10对认证服务器30c进行事件信息的询问。

接着，接受到询问的认证服务器30c将保存在事件信息保存部304中的事件信息向监视装置10回送(S202)。

接着，监视装置10确认在所取得的事件信息中是否有对监视装置10所监视的设备40的处理命令(S203)。另外，在步骤S203中，如果在所取得的事件信息中没有对设备40的处理命令(S203中为否)，则监视装置10向步骤S201返回。

在步骤S203中，如果在所取得的事件信息中有对设备40的处理命令(S203中为是)，则监视装置10取得设备40的状态信息(S204)。这里，作为取得状态信息的方法，例如有通过对设备40发送消息，并根据有无回送而进行故障确认，来取得表示设备是否故障的状态信息的方法。

接着，监视装置10生成包含步骤S204中取得的状态信息的交易数据(以下称作第1交易数据)，并发送给认证服务器30a、30b、30c(S205)。另外，监视装置10也可以将所生成的第1交易数据仅发送给认证服务器30a、30b、30c中的某一个。在此情况下，认证服务器30a、30b、30c中的某一个向其他的认证服务器传送第1交易数据。

接着，认证服务器30a、30b、30c如果接收到从监视装置10发送的第1交易数据，则暂时保存到交易数据保存部301中，执行共识算法(S206)。更详细地讲，首先，认证服务器30a、30b、30c读取保存在交易数据保存部301中的第1交易数据，进行第1交易数据的正当性的验证。认证服务器30a、认证服务器30b和认证服务器30c如果验证接收到的第1交易数据的正当性，则分别生成包含第1交易数据的区块。并且，认证服务器30a、30b、30c将包含第1交易数据的区块记录到交易数据保存部301的作为分布式账本发挥功能的区域。这样，包含状态信息的第1交易数据被记录到分布式账本即区块链。

此外，监视装置10在设备40没有故障的情况下，将事件信息中包含的处理命令发送给设备40(S207)。

最后，设备40执行接受到的处理命令(S208)。

另外，步骤S207和步骤S206的处理顺序没有限定。

[3.效果等]

这样，在本实施方式的故障监视系统中，用户为了对作为对象的设备进行处理，使终端20对认证服务器30发送包含处理命令的第5交易数据。认证服务器30对从终端20接收到的第5交易数据的正当性进行验证，如果正当，则发布与处理命令对应的事件。监视装置10确认有事件被发布，取得表示作为用户的处理命令的对象的设备40是否故障的状态信息。监视装置10在确认到该设备40故障的情况下，通过将包含状态信息的第1交易数据发送给认证服务器30，使状态信息登录到分布式账本中。如果该设备40没有故障，则监视装置10使设备40执行用户要求的处理。

如以上这样，根据本实施方式的故障监视系统，使监视装置监视用户的操作对象的设备是否故障，通过分布式账本即区块链对表示该设备是否故障的状态信息进行管理。由此，不仅使得该设备的状态信息不能篡改，而且能够抑制故障的设备的利用。即，根据本实施方式的故障监视系统，能够使用分布式账本抑制故障的设备的利用。

进而，由于知道能够进行区块链上的操作的设备是实际能够使用的设备，所以能够消除移动到设备所在的位置才知道实际是否能够使用的状态。因此，移动到处于故障中而不能进行操作的设备的位置所耗费的时间和能量不会成为浪费，能够抑制时间和能量耗费，此外，还能够得到利用区块链的服务的可靠性。

(实施例1)

另外，在区块链上对设备进行操作的情况下，在区块链上管理设备的权限。例如在设备是安装于酒店的房间的电子锁的情况下，通过用区块链来管理电子锁的开锁或上锁的权限，能够通过区块链进行房间的进出管理。

在实施例1中，对在确认到操作对象的设备没有故障之后在区块链上移交设备的权限的情况进行说明。在此情况下，由终端20生成的第5交易数据中，在包含用于用户对设备40进行操作的处理命令的请求中，包含能够使设备40执行处理命令的设备40的权限的移交请求。因此，事件信息还包含表示有设备40的权限的移交请求的信息。

以下，使用图14对有关实施例1的故障监视动作进行说明。

图14是表示有关实施方式的实施例1的故障监视系统的故障监视动作的一例的顺序图。

首先，监视装置10对于认证服务器30a、30b、30c中的1个认证服务器(在图中是认证服务器30c)确认是否发布了事件(S301)。在本实施例中，监视装置10也对认证服务器30c进行事件信息的询问。

接着，接受到询问的认证服务器30c将保存在事件信息保存部304中的事件信息回送给监视装置10(S302)。在本实施例中，在事件信息中还包含表示存在设备40的权限的移交请求的信息。

接着，监视装置10确认在所取得的事件信息中是否有监视装置10所监视的设备40的权限的移交请求(S303)。另外，在步骤S303中，如果在所取得的事件信息中没有设备40的权限的移交请求(S303中为否)，则监视装置10回到步骤S301。

在步骤S303中，如果在所取得的事件信息中有设备40的权限的移交请求(S303中为是)，则监视装置10取得设备40的状态信息(S304)。另外，作为取得状态信息的方法，如在步骤S204中说明的那样，所以省略说明。

接着，监视装置10生成包含步骤S304中取得的状态信息的第1交易数据，发送给认证服务器30a、30b、30c(S305)。

接着，认证服务器30a、30b、30c如果接收到从监视装置10发送的第1交易数据，则暂时保存到交易数据保存部301中，执行共识算法(S306)。详细情况如在步骤S206中说明的那样，所以省略说明。执行了共识算法的结果是，包含状态信息的第1交易数据被记录到分布式账本即区块链中。

此外，监视装置10根据状态信息确认设备40是否故障(S307)。

在步骤S307中，监视装置10在根据所取得的状态信息确认到设备40没有故障的情况下(S307中为否)，生成表示认可设备40的权限的移交请求之意的交易数据(以下称作第2交易数据)，发送给认证服务器30a、30b、30c(S308)。

接着，监视装置10将事件信息中包含的对设备40的处理命令发送给设备40(S309)。

接着，设备40执行接受到的处理命令(S310)。

另一方面，在步骤S307中，监视装置10在根据所取得的状态信息确认到设备40故障的情况下(S307中为是)，生成表示拒绝设备40的权限的移交请求之意的交易数据(以下称作第3交易数据)，发送给认证服务器30a、30b、30c(S311)。

接着，认证服务器30a、30b、30c如果接收到从监视装置10发送的第2或第3交易数据，则暂时保存到交易数据保存部301中，执行共识算法(S312)。更详细地讲，首先，认证服务器30a、30b、30c读取保存在交易数据保存部301中的第2或第3交易数据，进行第2或第3交易数据的正当性的验证。认证服务器30a、认证服务器30b和认证服务器30c如果验证了接收到的第2或第3交易数据的正当性，则分别生成包含第2或第3交易数据的区块。并且，认证服务器30a、30b、30c将包含第2或第3交易数据的区块记录到交易数据保存部301的作为分布式账本发挥功能的区域。这样，第2或第3交易数据被记录到分布式账本即区块链中。

另外，步骤S310和步骤S312的处理顺序没有限制。此外，步骤S312的执行不是必须的。

(实施例2)

在实施例2中，对在确认操作对象的设备的状态信息之前，在区块链上移交设备的权限，在该设备故障的情况下退回该权限的情况进行说明。在此情况下，由终端20生成的第5交易数据中，在包含用于用户对设备40进行操作的处理命令的请求中，包含能够使设备40执行处理命令的设备40的权限的移交。因而，事件信息还包含表示存在设备40的权限的移交的信息。

以下，使用图15对有关实施例2的故障监视动作进行说明。

图15是表示有关实施方式的实施例2的故障监视系统的故障监视动作的一例的顺序图。

首先，监视装置10对于认证服务器30a、30b、30c中的1个认证服务器(在图中是认证服务器30c)确认是否发布了事件(S401)。在本实施例中，监视装置10也对认证服务器30c进行事件信息的询问。

接着，接受到询问的认证服务器30c将保存在事件信息保存部304中的事件信息回送给监视装置10(S402)。在本实施例中，在事件信息中还包含表示存在设备40的权限的移交的信息。

接着，监视装置10确认在所取得的事件信息中是否有监视装置10监视的设备40的权限的移交(S403)。另外，在步骤S403中，如果所取得的事件信息没有表示出有设备40的权限的移交(S403中为否)，则监视装置10回到步骤S401。

在步骤S403中，如果所取得的事件信息表示出有设备40的权限的移交(S403中为是)，则监视装置10取得设备40的状态信息(S404)。另外，作为取得状态信息的方法，如在步骤S204中说明的那样，所以省略说明。

接着，监视装置10生成包含步骤S404中取得的状态信息的第1交易数据，发送给认证服务器30a、30b、30c(S405)。

接着，认证服务器30a、30b、30c如果接收到从监视装置10发送的第1交易数据，则暂时保存到交易数据保存部301中，执行共识算法(S406)。详细情况是如在步骤S206中说明的那样，所以省略说明。执行共识算法的结果是，包含状态信息的第1交易数据被记录到分布式账本即区块链中。

此外，监视装置10根据状态信息确认设备40是否故障(S407)。

在步骤S407中，在监视装置10根据所取得的状态信息确认到设备40没有故障的情况下(S407中为否)，将事件信息中包含的对设备40的处理命令发送给设备40(S408)。

接着，设备40执行接受到的处理命令(S409)。

另一方面，在步骤S407中，监视装置10在根据所取得的状态信息确认到设备40故障的情况下(S407中为是)，生成表示退回设备40的权限的移交之意的交易数据(以下称作第4交易数据)，发送给认证服务器30a、30b、30c(S410)。

接着，认证服务器30a、30b、30c如果接收到从监视装置10发送的第4交易数据，则暂时保存到交易数据保存部301中，执行共识算法(S411)。更详细地讲，首先，认证服务器30a、30b、30c读取保存在交易数据保存部301中的第4交易数据，进行第4交易数据的正当性的验证。认证服务器30a、认证服务器30b和认证服务器30c如果验证了接收到的第4交易数据的正当性，则分别生成包含第4交易数据的区块。并且，认证服务器30a、30b、30c将包含第4交易数据的区块记录到交易数据保存部301的作为分布式账本发挥功能的区域。这样，第4交易数据被记录到分布式账本即区块链中。

另外，步骤S409和步骤S411的处理顺序没有限制。

(其他实施方式)

以上，基于实施方式对有关本发明的故障监视系统进行了说明，但本发明并不限定于上述的实施方式。只要不脱离本发明的主旨，对实施方式施以本领域技术人员想到的各种变形后的形态、或将实施方式的一部分构成要素组合而构成的其他形态也包含在本发明的范围中。例如，以下这样的情况也包含在本发明中。

(1)在1台监视装置监视多台设备的情况下，当监视装置取得设备的状态信息时，也可以仅取得在所取得的事件信息中表示的作为新发布的事件的对象的设备的状态信息。此外，当监视装置取得设备的状态信息时，不仅取得所取得的事件信息中表示的新发布的事件为发布的对象的设备的状态信息，也可以取得监视装置监视的全部设备的状态信息。

(2)在上述的实施方式中，在有关本发明的故障监视系统中，当由认证服务器30发布了新的事件时，监视装置对于设备取得状态信息而确认是否故障后请求处理命令的执行，但并不限于此。也可以在由认证服务器30发布了新的事件时，监视装置对设备请求处理命令的执行，根据从设备发送的执行结果取得状态信息。例如假设设备是锁柜，在锁柜上带有检测门打开的传感器。在此情况下，监视装置也可以通过在尽管对锁柜发出了开门的命令但没有检测到门打开的情况下判断为故障，来取得表示锁柜故障的状态信息。

(3)上述的装置具体而言是由微处理器、ROM、RAM、硬盘单元、显示器单元、键盘、鼠标等构成的计算机系统。在上述RAM或硬盘单元中存储有计算机程序。通过由上述微处理器按照上述计算机程序动作，各装置实现其功能。这里，计算机程序是为了实现规定的功能，将多个表示对于计算机的指令的命令代码进行组合而构成的。

(4)构成上述装置的构成要素的一部分或全部也可以由1个系统LSI(Large ScaleIntegration：大规模集成电路)构成。系统LSI是将多个构成部集成到1个芯片上而制造的超多功能LSI，具体而言，是包括微处理器、ROM、RAM等而构成的计算机系统。在上述RAM中存储有计算机程序。通过由上述微处理器按照上述计算机程序动作，系统LSI实现其功能。

(5)构成上述装置的构成要素的一部分或全部也可以由相对于各装置可拆装的IC卡或单体的模块构成。上述IC卡或上述模块是由微处理器、ROM、RAM等构成的计算机系统。上述IC卡或上述模块也可以包括上述超多功能LSI。通过由上述微处理器按照上述计算机程序动作，上述IC卡或上述模块实现其功能。该IC卡或该模块也可以具有耐篡改性。

(6)此外，本发明也可以是上述所示的方法。此外，也可以是将这些方法通过计算机实现的计算机程序，也可以是由上述计算机程序构成的数字信号。

(7)此外，本发明也可以将上述计算机程序或上述数字信号记录到能够由计算机读取的记录介质，例如软盘、硬盘、CD－ROM、MO、DVD、DVD－ROM、DVD－RAM、BD(Blu－ray(注册商标)Disc)、半导体存储器等中。此外，也可以是记录在这些记录介质中的上述数字信号。

此外，本发明也可以将上述计算机程序或上述数字信号经由电通信线路、无线或有线通信线路、以因特网为代表的网络、数据广播等传送。

此外，本发明也可以是具备微处理器和存储器的计算机系统，上述存储器存储有上述计算机程序，上述微处理器按照上述计算机程序动作。

此外，也可以通过将上述程序或上述数字信号记录到上述记录介质中并移送，或通过将上述程序或上述数字信号经由上述网络等移送，来由独立的其他计算机系统实施。

产业上的可利用性

本发明能够应用于与设备独立的监视装置监视设备的故障、用区块链管理表示设备是否故障的状态状况的系统等。

标号说明

10、10a、10b、10c 监视装置

20 终端

30、30a、30b、30c 认证服务器

40、40a、40b、40c 设备

101 事件信息监视部

102 故障确认部

103 通知部

104 处理命令请求部

105、202、305 通信部

201 交易数据生成部

301 交易数据保存部

302 交易数据验证部

303 事件发布部

304 事件信息保存部

401 处理命令执行部

402 通信部