(57)【要約】  管理サーバと通信可能な電子機器に種々の障害が生じた場合に、効率良く復旧できる情報処理システム及び情報処理方法を提供する。センサボックスＳＢ−１の制御部ＣＰＵが、規定のタイミングで繰り返し管理サーバＳＶから復旧データセットを受信して、メモリＭＲに記憶するようになっており、更に制御部ＣＰＵが自己診断した結果、障害が生じていると判断し、また管理サーバＳＶと通信不能であると判断した場合には、メモリＭＲに記憶された最新の復旧データセットに基づいて、障害からの復旧を試みるようにしているので、管理サーバＳＶに頼ることなくセンサボックスＳＢ−１が自律的に障害から復旧することができる。更に、障害からの復旧に成功した後には，ネットワークＮＷを介して管理サーバＳＶと通信可能となっているので、センサボックスＳＢ−１は、レポートログを管理サーバＳＶに送信し、管理サーバＳＶは、センサボックスＳＢ−１から送信されたレポートログに基づいてデータベースＤＢを更新する。これにより、センサボックスＳＢ−１に生じた障害から復旧させるためのスプリクトの成功率について、常に最新のデータを入手できるから、その復旧データセットを規定のタイミングで繰り返しダウンロードすることで、センサボックスＳＢ−１が自律的に復旧する可能性が高まり、ユーザーやサービスマン等の人手を介して復旧作業を行う手間が省け、コスト削減につながる。
2017135226.tif 000002
【特許請求の範囲】
【請求項１】
障害が発生しているか否か診断の対象となる電子機器と、
前記電子機器と通信可能に接続され、前記電子機器に障害が生じたことを前記電子機器との間の通信を介して認識する管理サーバと、を有する情報処理システムであって、
前記管理サーバは、前記電子機器における障害からの復旧に関する復旧情報を含むデータベースを有しており、
前記電子機器は、規定のタイミングで繰り返し前記管理サーバから前記復旧情報を受信して、メモリに記憶するようになっており、
前記電子機器の診断の結果、障害が生じていると判断した場合、前記電子機器は、前記メモリに記憶された最新の前記復旧情報に基づいて、前記障害からの復旧を試みるようにしており、
前記復旧を試みた後に、前記電子機器は、前記復旧に関する復旧履歴情報を前記管理サーバに送信し、
前記管理サーバは、前記電子機器から送信された前記復旧履歴情報に基づいて、前記データベースを更新する情報処理システム。
【請求項２】
前記電子機器に障害が生じていると判断された場合において、前記電子機器が前記管理サーバと通信不能なときは、前記電子機器は、前記メモリに記憶された最新の前記復旧情報に基づいて、前記障害からの復旧を試み、前記電子機器が前記管理サーバと通信可能なときは、前記電子機器は、前記管理サーバに最新の前記復旧情報を求める通知を送信し、前記管理サーバから送信された最新の前記復旧情報に基づいて、前記障害からの復旧を試みる請求項１に記載の情報処理システム。
【請求項３】
前記復旧履歴情報は、前記電子機器の機器情報、前記電子機器の障害の復旧に用いた前記復旧情報とその成否を示す履歴情報、及び前記電子機器の使用環境情報を含むことを特徴とする請求項１又は２に記載の情報処理システム。
【請求項４】
前記管理サーバは、前記電子機器から送信された前記復旧履歴情報に基づいて、将来起こりえる障害を予測し、前記障害を回避するために推奨される処理に関する推奨情報を前記電子機器に送信し、前記電子機器は、前記推奨情報に基づいて前記推奨される処理を実行する請求項１〜３のいずれかに記載の情報処理システム。
【請求項５】
障害が発生しているか否か診断の対象となる電子機器と、前記電子機器と通信可能に接続され、前記電子機器に障害が生じたことを前記電子機器との間の通信を介して認識する管理サーバとを連係して動作させる情報処理方法であって、
前記管理サーバは、前記電子機器における障害からの復旧に関する復旧情報を含むデータベースを有しており、
前記電子機器に、規定のタイミングで繰り返し前記管理サーバから前記復旧情報を受信させて、メモリに記憶させ、
前記電子機器の診断の結果、障害が生じていると判断した場合には、前記電子機器に、前記メモリに記憶された最新の前記復旧情報に基づいて、前記障害からの復旧を試みるようにさせ、
前記復旧を試みた後に、前記電子機器から、前記復旧に関する復旧履歴情報を前記管理サーバに送信させ、
前記管理サーバに、前記電子機器から送信された前記復旧履歴情報に基づいて、前記データベースを更新させる情報処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電子機器の復旧を効率良く行える情報処理システム及び情報処理方法に関する。
【背景技術】
【０００２】
監視カメラや小売店の電子レジスタなど、種々の電子機器がネットワークを介して管理サーバに接続されて情報のやりとりを行い、情報の集中管理が行われている。このような電子機器の使用中に何らかの障害が生じると、情報の集中管理を行えなくなるため迅速な復旧が望まれる。障害からの復旧の初動としては、電子機器を使用するユーザーが、取扱説明書等に従って復旧作業を行うことが多い。障害が比較的軽度であれば、復旧作業として再起動等を行うことで不具合のあるデータなどがリセットされ、容易に復旧を行うことができることもある。これに対し、障害が比較的重度であると、電子機器の復旧作業に不慣れなユーザーでは、復旧に手間取ることもある。そのような場合、障害の生じた電子機器のある現地にサービスマン等を派遣して復旧作業を行わせる必要があるが、それにより復旧までに多大なコストと時間がかかる。【０００３】
特許文献１には、親機と子機とを接続可能な無線テレメータシステムが開示されている。特許文献１によれば、例えば親機又は子機に対して落雷等のトラブルが発生して、その回路基板等の故障が発生した場合、復旧のために、故障した親機又は子機の回路基板等から必要情報を読み出そうとしても、回路基板自体が動作しないため読み出せないことが多いとされる。かかる場合には、まず、回路基板を部品交換して復旧を行う必要があるが、交換された新たな回路基板等に記憶させるバックアップとしての必要情報を、予め外部機器に記憶しておき、ネットワークを介して親機又は子機に読み出すことはできる。しかしながら、バックアップのための専用の外部機器を設けることはコストがかかり、また常に外部機器と通信可能な状態が確保されるとは限らない。そこで、予め必要情報を親機又は子機の不揮発性メモリに記録しておき、故障が生じた場合、故障した親機又は子機から不揮発性メモリを取り外して、修理した親機又は子機に装着することで、バックアップを確保することなく、また外部機器との通信が不能であっても無線テレメータシステムの復旧を可能とすることが示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００７−２００１２４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、特許文献１の技術により復旧作業が容易になるとしても、復旧に際しては依然として電子機器に対して人手を介した作業を行う必要があり、手間がかかる。又、電子機器によっては、不揮発性メモリの交換だけでは復旧が困難な場合もある。これに対し、例えば管理サーバからネットワークを介して、障害が生じた電子機器を遠隔操作して障害からの復旧を行わせる技術も開発されている。障害の発生は、ネットワークを介してなされる電子機器からの通知によって管理サーバに知らせることができるので、通知を受けた管理サーバは直ちに必要な処理を行えるから、迅速且つ効率良く電子機器の復旧を行える。しかしながら、電子機器の通信に関わる部位に障害が生じた場合、管理サーバに通知することができないから、電子機器の遠隔操作も不可能になる。【０００６】
更に、同種の電子機器であっても、製造時期に応じて異なるバージョンのファームウエア等を搭載していることがあるが、それにより障害の内容が変わってくる恐れがある。障害の内容が変われば復旧の手順なども変わるので、全ての障害に対して画一化した処理により復旧を行うことは困難といえる。従って、電子機器に生じる種々の障害に対して、いかに効率良く且つ自律的に復旧させることができるかが大きな課題となっている。【０００７】
本発明は、上記事情に鑑みなされたものであり、管理サーバと通信可能な電子機器に種々の障害が生じた場合に、効率良く復旧できる情報処理システム及び情報処理方法を提供することを目的とする。
【課題を解決するための手段】
【０００８】
上述した目的のうち少なくとも一つを実現するために、本発明の一側面を反映した情報処理システムは、
障害が発生しているか否か診断の対象となる電子機器と、
前記電子機器と通信可能に接続され、前記電子機器に障害が生じたことを前記電子機器との間の通信を介して認識する管理サーバと、を有する情報処理システムであって、
前記管理サーバは、前記電子機器における障害からの復旧に関する復旧情報を含むデータベースを有しており、
前記電子機器は、規定のタイミングで繰り返し前記管理サーバから前記復旧情報を受信して、メモリに記憶するようになっており、
前記電子機器の診断の結果、障害が生じていると判断した場合、前記電子機器は、前記メモリに記憶された最新の前記復旧情報に基づいて、前記障害からの復旧を試みるようにしており、
前記復旧を試みた後に、前記電子機器は、前記復旧に関する復旧履歴情報を前記管理サーバに送信し、
前記管理サーバは、前記電子機器から送信された前記復旧履歴情報に基づいて、前記データベースを更新するものである。【０００９】
上述した目的のうち少なくとも一つを実現するために、本発明の一側面を反映した情報処理方法は、障害が発生しているか否か診断の対象となる電子機器と、前記電子機器と通信可能に接続され、前記電子機器に障害が生じたことを前記電子機器との間の通信を介して認識する管理サーバとを連係して動作させる情報処理方法であって、
前記管理サーバは、前記電子機器における障害からの復旧に関する復旧情報を含むデータベースを有しており、
前記電子機器に、規定のタイミングで繰り返し前記管理サーバから前記復旧情報を受信させて、メモリに記憶させ、
前記電子機器の診断の結果、障害が生じていると判断した場合には、前記電子機器に、前記メモリに記憶された最新の前記復旧情報に基づいて、前記障害からの復旧を試みるようにさせ、
前記復旧を試みた後に、前記電子機器から、前記復旧に関する復旧履歴情報を前記管理サーバに送信させ、
前記管理サーバに、前記電子機器から送信された前記復旧履歴情報に基づいて、前記データベースを更新させるものである。
【発明の効果】
【００１０】
本発明によれば、管理サーバと通信可能な電子機器に種々の障害が生じた場合に、効率良く復旧できる情報処理システム及び情報処理方法を提供することができる。
【図面の簡単な説明】
【００１１】
【図１】本実施形態における情報処理システム又は情報処理方法を実現する介護支援システムの全体構成を示す図である。
【図２】センサボックスＳＢ−１用のパターンテーブルの一例である。
【図３】センサボックスＳＢのブロック図である。
【図４】センサボックスＳＢ−１が正常に機能しているかを診断し、その結果障害が生じたと判断した場合に行う処理を示す梯子チャートである。
【図５】スプリクトに従って制御部ＣＰＵが行う復旧処理の一例を示すフローチャートである。
【図６】別な実施形態にかかる処理を示す梯子チャートである。
【発明を実施するための形態】
【００１２】
以下、本発明にかかる実施形態を図面に基づいて説明する。図１は、本実施形態における情報処理システム又は情報処理方法を実現する介護支援システムの全体構成を示す図である。本実施形態における介護支援システムは、見守り対象である被監視者（以下、対象者という）Ｏｂの状態を、それぞれ対応するセンサボックスＳＢにより検知することで対象者Ｏｂを見守って、介護を支援する機能を有するものである。尚、センサボックスＳＢは、限られたコンピュータ資源を持つものであると好ましい。
【００１３】
このような介護支援システムＭＳは、例えば、図１に示すように、対象者の居室にそれぞれ備えられたセンサボックスＳＢ（ＳＢ−１〜ＳＢ−４）と、管理サーバＳＶと、固定端末装置ＳＰと、介護士がそれぞれ管理する携帯端末ＴＡ（ＴＡ−１、ＴＡ−２）とを有し、これらは、有線や無線で、ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、電話網およびデータ通信網等の網（ネットワーク、通信回線）ＮＷを介して通信可能に接続されている。ネットワークＮＷには、通信信号を中継する例えばリピーター、ブリッジ、ルーターおよびクロスコネクト等の中継機が備えられても良い。図１に示す例では、これら複数のセンサボックスＳＢ−１〜ＳＢ−４、管理サーバＳＶ、固定端末装置ＳＰおよび複数の携帯端末ＴＡ−１、ＴＡ−２は、アクセスポイントＡＰを含む無線ＬＡＮ（例えばＩＥＥＥ８０２．１１規格に従ったＬＡＮ等）ＮＷによって互いに通信可能に接続されている。センサボックスＳＢは、電子機器の一例に相当する。
【００１４】
対象者Ｏｂは、例えば、病気や怪我等によって看護を必要とする者や、身体能力の低下等によって介護を必要とする者や、一人暮らしの独居者等である。特に、早期発見と早期対処とを可能にする観点から、対象者Ｏｂは、例えば異常状態等の所定の不都合な事象がその者に生じた場合にその発見を必要としている者であることが好ましい。このため、介護支援システムＭＳは、対象者Ｏｂの種類に応じて、病院、老人福祉施設および住戸等の建物に好適に配設される。図１に示す例では、介護支援システムＭＳは、複数の対象者Ｏｂが入居する複数の居室ＲＭや、ナースステーションＳＴ等の複数の部屋を備える介護施設の建物に配設されている。
【００１５】
管理サーバＳＶは、ネットワークＮＷを介してセンサボックスＳＢと、固定端末ＳＰと、携帯端末ＴＡとに独立して通信する通信機能を備えている。管理サーバＳＶは、センサボックスＳＢから通知を受けて、イベントが生じた居室を担当する介護士の持つ携帯端末ＴＡ、及び／又は固定端末装置ＳＰに情報を提供する機能を有すると共に、センサボックスＳＢ−１の障害に際し、センサボックスＳＢに必要な復旧データセット（復旧情報）を提供する機能を有する。
【００１６】
更に管理サーバＳＶは、図１に示すようにデータベースＤＢを有している。データベースＤＢは、センサボックスＳＢ−１の障害に関する情報（センサボックスの機種毎の故障履歴、利用履歴、使用環境に関する情報を含む）を記録している。障害に関する情報は、各センサボックスＳＢからレポートログ（詳細は後述）が管理サーバＳＶに送信される度に更新される。管理サーバＳＶは、データベースＤＢ内から、センサボックスＳＢ毎に最適な復旧データセットを抽出できる。かかる復旧データセットは、センサボックスＳＢに応じたファームウェアとツール、復旧までの手順を示す復旧スクリプト群、復旧パターンテーブルを含んでいる。
【００１７】
図２は、センサボックスＳＢ−１用のパターンテーブルの一例である。パターンテーブルには、図２に示すように、適用する優先順位、スプリクト名、復旧トライ回数、前回復旧結果（成功であればＴＲＵＥ、失敗であればＦＡＬＳＥ）、復旧からの成功率がリストとなって示されている。パターンテーブルの優先順位は、復旧の成功率が高い順に昇順となっている。スプリクト名は、同梱された復旧スクリプト群に対応するものであると好ましい。尚、成功率の括弧内は、同機種であるセンサボックスＳＢ−１，ＳＢ−２の障害から復旧に成功したトータルの成功率である。パターンテーブルの内容は以上に限られず、少なくとも優先順位とスプリクト名とが対応づけられていれば足りる。
【００１８】
図３は、センサボックスＳＢのブロック図である。センサボックスＳＢは、対象者Ｏｂの居室ＲＭの天井や壁等にそれぞれ配置され、ネットワークＮＷを介して管理サーバＳＶ等と通信する通信機能を備えている。より具体的に、センサボックスＳＢは、例えばカメラＣＡと、ファームウェアやツールなどを記憶したメモリＭＲと、通信部ＩＦと、これらを司る制御部ＣＰＵとを備えている。尚、図１で示すセンサボックスＳＢ−１，ＳＢ−２は互いに同機種であって、センサボックスＳＢ−３，ＳＢ−４と異なる機種である。但し、センサボックスＳＢ−１，ＳＢ−２は異なるバージョンのファームウェアを有するものとする。
【００１９】
メモリＭＲに格納されたプログラムを実行することで動作する制御部ＣＰＵは、カメラＣＡで対象者Ｏｂを撮影して、その画像から対象者Ｏｂの起床、離床、転倒、転落等を判別し、それに対応する対象者情報を、通信部ＩＦからネットワークＮＷを介して管理サーバＳＶに送信する機能を有する。又、制御部ＣＰＵは、後述するように規定のタイミングで繰り返し、センサボックスＳＢに障害が生じていないか診断(ヘルスチェックともいう)を行い、障害が生じていた場合、それに対応する障害情報を、同様にネットワークＮＷを介して管理サーバＳＶに送信する機能も有する。
【００２０】
センサボックスＳＢから対象者情報を受信した管理サーバＳＶは、ネットワークＮＷを介して、そのセンサボックスＳＢが備えられた部屋を担当する介護士ＮＳの持つ端末ＴＡに、対象者Ｏｂの起床、離床、転倒、転落等が生じた旨の対象者情報を送信し、かかる端末ＴＡは、対象者情報に応じて画面表示を行うようになっている。かかる画面を見た介護士ＮＳは、担当する対象者Ｏｂに何が生じたのか判断できるので、部屋に駆けつけるなどの対応を迅速に行うことができる。
【００２１】
このように、センサボックスＳＢは、部屋にいる対象者Ｏｂの状態を、昼夜を問わず監視し続けるものであるので、センサボックスＳＢに障害が生じた場合、対象者Ｏｂの状態の把握が困難となる恐れがある。一方、センサボックスＳＢを比較的短期間毎にメンテナンスすれば、障害が生じる恐れを低下させることはできるが、手間とコストがかかる。そこで、規定のタイミングで繰り返し、センサボックスＳＢが正常に機能しているかを診断し、その結果障害が生じたと判断した場合には、直ちに必要な処理を行うことが望ましいといえる。
【００２２】
図４は、センサボックスＳＢ−１が正常に機能しているかを診断し、その結果障害が生じたと判断した場合に行う処理を示す梯子チャートである。ここでは、管理サーバＳＶとセンサボックスＳＢ−１とのデータのやりとりを示しているが、その他のセンサボックスとも同様なデータのやりとりが行われる。
【００２３】
まず図４のステップＳ１０１において、管理サーバＳＶは、データベースＤＢからセンサボックスＳＢ−１用の最新である復旧データセットを読み出す。規定のタイミングで繰り返し、かかる復旧データセットは管理サーバＳＶからセンサボックスＳＢ−１にダウンロードされる（ｃ１１）。センサボックスＳＢ−１の制御部ＣＰＵは、ステップＳ１０２で、ダウンロードした復旧データセットをメモリＭＲに記憶する。メモリＭＲ中で、ダウンロードした復旧データセットは、それ以前の復旧データセットに上書きされても良いし、それ以前の復旧データセットをバックアップ用に残しておいても良い。
【００２４】
更に規定のタイミング（復旧データセットのダウンロードとは異なるタイミングでも良い）で、ステップＳ１０３で、センサボックスＳＢ−１の制御部ＣＰＵは、メモリＭＲから自己診断プログラムを呼び出して診断を実行する。ステップＳ１０４で、制御部ＣＰＵが、その診断結果によりセンサボックスＳＢ−１の各部の機能が正常であると判断した場合、フローはステップＳ１０２へと戻る。
【００２５】
一方、診断結果によりセンサボックスＳＢ−１のいずれかに障害が発生したと判断した場合、制御部ＣＰＵは、続くステップＳ１０５で、通信部ＩＦを介して管理サーバＳＶと通信可能か否かを判断する。通信可能と判断すれば、制御部ＣＰＵは管理サーバＳＶに障害が生じた旨の通知を行う（ｃ１２）。これに応じて管理サーバＳＶは、ステップＳ１０６で、データベースＤＢからセンサボックスＳＢ−１用の最新である復旧データセットを読み出す。読み出された復旧データセットは、管理サーバＳＶからセンサボックスＳＢ−１にダウンロードされる（ｃ１３）。
【００２６】
更に制御部ＣＰＵは、ステップＳ１０７で、ダウンロードした復旧データセットに基づいて、センサボックスＳＢ−１の障害からの復旧処理を試みる。ダウンロードした復旧データセットは最新であり、例えば図２に示すパターンテーブルが含まれているものとする。ここで、制御部ＣＰＵは、パターンテーブルを参照し、最も優先順位が高いスプリクト（図２の例では優先順位０：ｒｅｓ０１８Ａ．ｓｈ）を、復旧データセットに同梱された復旧スプリクト群から選定し、これに従って最初の復旧処理を行う。
【００２７】
図５は、スプリクトに従って制御部ＣＰＵが行う復旧処理の一例を示すフローチャートである。まずステップＳ１０７ａで、制御部ＣＰＵは、クリーンインストールを行う場合には不要なファイルを削除し、ステップＳ１０７ｂで、復旧データセットに同梱されたファームウェア（バージョンｘｘ）の圧縮ファイルを解凍し、ステップＳ１０７ｃで、解凍したファイルをｙｙに配置し、ステップＳ１０７ｄで，新たなファームウェアの書き込みを実行する。尚、スプリクトとしては、例えばセンサボックスの再起動などもあるが、かかる場合、ファームウエアやツールは使用しないこととなる。
【００２８】
その後、図４のステップＳ１０８で、制御部ＣＰＵは，自己診断プログラムを再度実行して、障害から復旧したか否かを判断する。まだ障害から復旧していないと判断した場合、制御部ＣＰＵは、更にステップＳ１１１で、パターンテーブルに示されたスプリクト全てを試みたか否か判断する。全てを試みていないと判断した制御部ＣＰＵは、ステップＳ１０７へとフローを戻し、次の優先順位のスプリクト（図２の例では優先順位１：ｒｅｓ０７４Ａ．ｓｈ）を、復旧データセットに同梱された復旧スプリクト群から選定し、これに従って次の復旧処理を行う。その後、再びステップＳ１０８で、制御部ＣＰＵは障害から復旧したか否かを判断する。
【００２９】
ステップＳ１１１で、全てのスクリプトに従って復旧処理を試みたにもかかわらず、復旧が行われなかったと判断されると（判定Ｙｅｓ）、自力復旧が困難となることを意味するので、制御部ＣＰＵは，ステップＳ１１２で、例えばサービスマンの作業など外部処理による復旧を待つこととなる。外部処理によって復旧した場合、制御部ＣＰＵは、フローをステップＳ１０９へと進めて、後述するレポートログを作成する。
【００３０】
一方、いずれかのスクリプトにて復旧に成功した場合、制御部ＣＰＵはステップＳ１０９で、レポートログを作成する。復旧履歴情報としてのレポートログとは、復旧がなされたセンサボックスＳＢ−１を特定するための機器情報（ここではセンサボックスのメーカー名、機種番号、シリアル番号、ファームウェアのバージョン情報等）と、センサボックスＳＢ−１の履歴情報（どのスプリクトが復旧に失敗し、またどのスクリプトが復旧に成功したかを示す成否データ、前回の障害からの復旧後の稼動時間、前回の再起動後の稼働時間等）と、使用環境情報（センサボックスＳＢ−１に接続されたネットワーク回線の種類や仕様、周囲の温度や湿度、障害が起きた時間等）を含んでいる。
【００３１】
その後、制御部ＣＰＵは管理サーバＳＶに，作成したレポートログをアップロードする（ｃ１４）。管理サーバＳＶは、ステップＳ１１０で、入力したレポートログに基づいてデータベースＤＢを更新する。具体的には、履歴情報中の成否データに基づいて、センサボックスＳＢ−１に対応して、図２に示すパターンテーブルの成功率を計算し直す。その結果、スクリプトの優先順位が変わる場合、優先順位を入れ替えてデータベースＤＢに記憶する。以下、フローはステップＳ１０１へと戻り、このように更新された最新のデータベースＤＢから、管理サーバＳＶは復旧データセットを読み出すこととなる。
【００３２】
次に、センサボックスＳＢ−１の制御部ＣＰＵが、ステップＳ１０５で、通信部ＩＦを介して管理サーバＳＶと通信不能と判断した場合について説明する。この場合、制御部ＣＰＵは、管理サーバＳＶから最新の復旧データセットをダウンロードすることはできない。そこで、制御部ＣＰＵは、ステップＳ１１３で、障害発生直前にダウンロードされメモリＭＲに記憶されていた復旧データセットを読み出して、そのパターンテーブルに基づいて、図５のフローに従ってセンサボックスＳＢ−１の障害からの復旧処理を試みる。
【００３３】
その後、ステップＳ１１４で、制御部ＣＰＵは，自己診断プログラムを再度実行して、障害から復旧したか否かを判断する。まだ障害から復旧していないと判断した場合、制御部ＣＰＵは、更にステップＳ１１５で、パターンテーブルに示されたスプリクト全てを試みたか否か判断する。全てを試みていないと判断した制御部ＣＰＵは、ステップＳ１１３へとフローを戻し、次の優先順位のスプリクトを、メモリＭＲに記憶された復旧データセットの復旧スプリクト群から選定し、これに従って次の復旧処理を行う。その後、再びステップＳ１１４で、制御部ＣＰＵは障害から復旧したか否かを判断する。
【００３４】
ステップＳ１１５で、全てのスクリプトに従って復旧処理を試みたにもかかわらず、復旧が行われなかったと判断されると（判定Ｙｅｓ）、自力復旧が困難となることを意味するので、制御部ＣＰＵは，ステップＳ１１２で、例えばサービスマンの作業など外部処理による復旧を待つこととなる。外部処理によって復旧した場合、制御部ＣＰＵは、フローをステップＳ１０９へと進めて、上述したレポートログを作成する。
【００３５】
本実施形態によれば、センサボックスＳＢ−１の制御部ＣＰＵが、規定のタイミングで繰り返し管理サーバＳＶから復旧データセットを受信して、メモリＭＲに記憶するようになっており、更に制御部ＣＰＵが自己診断した結果、障害が生じていると判断し、また管理サーバＳＶと通信不能であると判断した場合には、メモリＭＲに記憶された最新の復旧データセットに基づいて、障害からの復旧を試みるようにしているので、管理サーバＳＶに頼ることなくセンサボックスＳＢ−１が自律的に障害から復旧することができる。
【００３６】
更に、障害からの復旧に成功した後には，ネットワークＮＷを介して管理サーバＳＶと通信可能となっているので、センサボックスＳＢ−１は、レポートログを管理サーバＳＶに送信し、管理サーバＳＶは、センサボックスＳＢ−１から送信されたレポートログに基づいてデータベースＤＢを更新する。これにより、センサボックスＳＢ−１に生じた障害から復旧させるためのスプリクトの成功率について、常に最新のデータを入手できるから、その復旧データセットを規定のタイミングで繰り返しダウンロードすることで、センサボックスＳＢ−１が自律的に復旧する可能性が高まり、ユーザーやサービスマン等の人手を介して復旧作業を行う手間が省け、コスト削減につながる。
【００３７】
尚、管理サーバＳＶは、センサボックスＳＢ−１から送信されたレポートログに基づいて、将来起こりえる障害を予測することもできる。例えば、管理サーバＳＶがレポートログの履歴情報に基づいて、センサボックスＳＢ−１は再起動後に７２時間以上経過すると障害が生じやすいと認識した場合、センサボックスＳＢ−１の再起動後、６０時間経過した時点でセンサボックスＳＢ−１に強制再起動をかける指示（推奨される処理に関する推奨情報）をセンサボックスＳＢ−１に送信すると好ましい。これに応じてセンサボックスＳＢ−１は、再起動（推奨される処理）を実行することで、障害の発生を未然に抑制できる。以上、管理サーバＳＶとセンサボックスＳＢ−１との間でのデータのやりとりを説明したが、その他のセンサボックスＳＢ−１〜ＳＢ−４でも同様である。
【００３８】
図６は、別な実施形態にかかる処理を示す梯子チャートである。ここでは、管理サーバＳＶとセンサボックスＳＢ−１、ＳＢ−２とのデータのやりとりを示しており、センサボックスＳＢ−２で障害が生じた例を示している。センサボックスＳＢ−２は、センサボックスＳＢ−１と同機種であるから、図３に示すものと同様な構成を有する。尚、その他のセンサボックスとも同様なデータのやりとりが行われる。
【００３９】
まず図６のステップＳ２０１において、管理サーバＳＶは、データベースＤＢからセンサボックスＳＢ−１、ＳＢ−２用の最新である復旧データセットをそれぞれ読み出す。規定のタイミングで繰り返し、かかる復旧データセットは管理サーバＳＶからセンサボックスＳＢ−１、ＳＢ−２にそれぞれダウンロードされる（ｃ２１、ｃ２２）。センサボックスＳＢ−１の制御部ＣＰＵは、ステップＳ２０２で、ダウンロードした復旧データセットをメモリＭＲに記憶すると共に、管理サーバＳＶに確認信号を送信する。これを受信した管理サーバＳＶは、センサボックスＳＢ−１が正常であることが確認できる。
【００４０】
一方、センサボックスＳＢ−２が正常である場合、その制御部ＣＰＵは、ダウンロードした復旧データセットをメモリＭＲに記憶すると共に、管理サーバＳＶに確認信号を送信する。これを受信した管理サーバＳＶは、センサボックスＳＢ−２が正常であることが確認できる。ところが、センサボックスＳＢ−２に障害が生じると、復旧データセットのダウンロードや確認信号の送信を行えなくなる。
【００４１】
より具体的に説明すると、センサボックスＳＢ−２の制御部ＣＰＵは、上述した実施形態と同様に、規定のタイミングで繰り返し自己診断プログラムに従い自身に障害が発生しているか否か診断する。その結果、障害が生じていると判断した場合、管理サーバＳＶに障害が生じた旨の通知を送信するよう試みる（図４のｃ１２）が、通信機能が損なわれていると管理サーバＳＶに通知が届かない（図４のステップＳ１１１の判定Ｙｅｓ）。更に、センサボックスＳＢ−２のメモリＭＲに復旧データセットが記憶されていない、もしくは読み出せない状態にあると、自律復旧が困難となる。
【００４２】
このような場合、センサボックスＳＢ−２から管理サーバＳＶに確認信号も通知も送信されないこととなるので、管理サーバＳＶはセンサボックスＳＢ−２に何らかの障害が生じたと判断できる（すなわち管理サーバＳＶはセンサボックスＳＢ−２に障害が生じたと診断する）。そこで、ステップＳ２０３で、所定時間たっても管理サーバＳＶがセンサボックスＳＢ−２から確認信号を受信しなかったときは、センサボックスＳＢ−２が、管理サーバＳＶとの通信が不能となる無通信状態になっていると判定し、同機種であるセンサボックスＳＢ−１に救援信号を送信する（ｃ２４）。
【００４３】
管理サーバＳＶから救援信号を送信されたセンサボックスＳＢ−１の制御部ＣＰＵは、ステップＳ２０４で、メモリＭＲから最新の復旧データセットを読み出して、救助パックとしてセンサボックスＳＢ−２に送信する。これは、図４のステップＳ１１２における外部からの復旧処理の一例に相当する。センサボックスＳＢ−１、ＳＢ−２間で通信が不能である場合、ユーザーの手でセンサボックスＳＢ−１のメモリＭＲから救助パックを読み出して、センサボックスＳＢ−２のメモリＭＲに入力しても良い。或いは、メモリＭＲが取り外し可能なメモリカード等であれば、センサボックスＳＢ−１から抜き出して、センサボックスＳＢ−２のものと差し替えてもよい。
【００４４】
その救助パックを取得できたとき、センサボックスＳＢ−２の制御部ＣＰＵは、ステップＳ２０５で救助パックから最新の復旧データセットを読み出して、そのパターンテーブルに基づいて、図５のフローに従ってセンサボックスＳＢ−２の障害からの復旧処理を試みる。このとき、復旧データセットのパターンテーブルが図２に示すものであるとき、スプリクトを適用する優先順位としては、括弧内に示すセンサボックスＳＢ−１，ＳＢ−２に共通である成功率が高いスプリクトの順に使用する。センサボックスＳＢ−１，ＳＢ−２は同機種であるものの、ファームウェアのバージョンが異なる場合など、復旧からの成功率がセンサボックスＳＢ−１とセンサボックスＳＢ−２とで異なる可能性がある。従って、センサボックスＳＢ−１単独の成功率が高い順にスプリクトを実行するよりも、共通の成功率が高い順にスプリクトを実行する方が、復旧が早まると推測されるからである。
【００４５】
その後、センサボックスＳＢ−２の制御部ＣＰＵは，ステップＳ２０６で自己診断プログラムに基づいて障害から復旧したか否かを判断する。但し、センサボックスＳＢ−１の制御部ＣＰＵが、センサボックスＳＢ−２にアクセスした上で，自身の自己診断プログラムを用いてネットワークを介してセンサボックスＳＢ−２の障害の有無を判定しても良い。まだ障害から復旧していないと判断された場合、更にステップＳ２０８で、センサボックスＳＢ−２の制御部ＣＰＵは，パターンテーブルに示されたスプリクト全てを試みたか否か判断する。全てを試みていないと判断した制御部ＣＰＵは、ステップＳ２０５へとフローを戻し、次の優先順位のスプリクトを、救助パックにおける復旧データセットの復旧スプリクト群から選定し、これに従って次の復旧処理を行う。その後、再びステップＳ２０６で、制御部ＣＰＵは障害から復旧したか否かを判断する。
【００４６】
ステップＳ２０８で、全てのスクリプトに従って復旧処理を試みたにもかかわらず、復旧が行われなかったと判断されると（判定Ｙｅｓ）、救助パックによる復旧が困難となることを意味するので、制御部ＣＰＵは，ステップＳ２０９で、例えばサービスマンの作業など外部処理による復旧を待つこととなる。これに対し、いずれかのスクリプトにて復旧に成功した場合、制御部ＣＰＵはステップＳ２０７で、レポートログを作成する。
【００４７】
その後、センサボックスＳＢ−２の制御部ＣＰＵは、管理サーバＳＶに，作成したレポートログをアップロードする（ｃ２６）。管理サーバＳＶは、ステップＳ２１０で、入力したレポートログに基づいてデータベースＤＢを更新する。これにより、センサボックスＳＢ−２用の復旧データセット、及びセンサボックスＳＢ−１用の復旧データセットの内容（パターンテーブルの括弧内に示す共通の成功率）が書き換えられて、再び管理サーバＳＶからセンサボックスＳＢ−１、ＳＢ−２にそれぞれダウンロードされる（ｃ２１、ｃ２２）。
【００４８】
本発明は、明細書に記載の実施形態に限定されるものではなく、他の実施形態・変形例を含むことは、本明細書に記載された実施形態や技術思想から本分野の当業者にとって明らかである。明細書の記載及び実施形態は、あくまでも例証を目的としており、本発明の範囲は後述するクレームによって示されている。例えば、電子機器としてはセンサボックスの例を挙げたが、これに限らずネットワークを介して管理サーバに接続された複合機、監視カメラ、スーパーや小売店の電子レジスタ等であっても良い。
【符号の説明】
【００４９】
ＡＰ                アクセスポイント
ＣＡ                カメラ
ＣＰＵ              制御部
ＤＢ                データベース
ＩＦ                通信部
ＭＲ                メモリ
ＭＳ                介護支援システム
ＮＳ                介護士
ＮＷ                ネットワーク
Ｏｂ                対象者
ＲＭ                居室
ＳＢ−１〜ＳＢ−４  センサボックス
ＳＰ                固定端末
ＳＴ                ナースステーション
ＳＶ                管理サーバ
ＴＡ                携帯端末
【図１】
2017135226.tif 000003
【図２】
2017135226.tif 000004
【図３】
2017135226.tif 000005
【図４】
2017135226.tif 000006
【図５】
2017135226.tif 000007
【図６】
2017135226.tif 000008
【国際調査報告】
2017135226.tif 000009
2017135226.tif 000010
2017135226.tif 000011
2017135226.tif 000012