(57)【特許請求の範囲】
【請求項１】
外部ネットワークを介して通信可能なサービス提供装置に処理を依頼する画像処理装置であって、
内部ネットワークを介して通信可能な情報処理装置で取得されている前記処理の状態を確認する確認手段を起動する起動手段と、
前記起動手段で起動された前記確認手段において前記処理の状態が停止状態でないと確認された場合、前記確認手段を停止する停止手段と、
前記確認手段が停止している場合、前記サービス提供装置に前記処理を依頼する依頼手段と、
を有することを特徴とする画像処理装置。
【請求項２】
前記起動手段は、前記サービス提供装置で行われる前記処理が停止しているか否かを判断し、前記サービス提供装置からの前記処理を停止した旨の通知に基づいて、前記処理が停止していると判断した場合、前記確認手段を起動することを特徴とする請求項１に記載の画像処理装置。
【請求項３】
前記起動手段は、前記処理の設定を変更した場合に前記処理が行われるか否かを更に判断し、前記通知に含まれる前記処理を停止した事由を表す情報に基づいて前記処理が行われないと判断した場合、前記確認手段を起動することを特徴とする請求項２に記載の画像処理装置。
【請求項４】
前記起動手段は、前記サービス提供装置で行われる前記処理が停止しているか否かを判断し、前記サービス提供装置から前記処理の状態を取得して前記処理が停止されたことを認識した前記情報処理装置からの前記処理が停止された旨の通知に基づいて、前記処理が停止していると判断した場合、前記確認手段を起動することを特徴とする請求項１に記載の画像処理装置。
【請求項５】
外部ネットワークを介して通信可能なサービス提供装置に処理を依頼する画像処理装置における通信制御方法であって、
内部ネットワークを介して通信可能な情報処理装置で取得されている前記処理の状態を確認する確認手段を起動する起動工程と、
前記起動工程で起動された前記確認手段において前記処理の状態が停止状態でないと確認された場合、前記確認手段を停止する停止工程と、
前記確認手段が停止している場合、前記サービス提供装置に前記処理を依頼する依頼工程と、
を有することを特徴とする通信制御方法。
【請求項６】
請求項１乃至４の何れか１項に記載の手段としてコンピュータを機能させるためのプログラム。
【請求項７】
複数の画像処理装置と内部ネットワークを介して通信可能であり、前記複数の画像処理装置から外部ネットワークを介して依頼された処理を行うサービス提供装置と前記外部ネットワークを介して通信可能な情報処理装置であって、
前記サービス提供装置から前記処理の状態を取得する取得手段と、
前記複数の画像処理装置の何れかの画像処理装置より前記処理の状態の確認があった場合、前記取得手段で取得された前記処理の状態を表す情報を前記画像処理装置に返信する返信手段と、
前記サービス提供装置から前記処理を停止した旨の通知を受信した前記画像処理装置からの前記処理が停止された旨の通知に基づいて、前記処理が停止されたと判断した場合、前記処理が停止された旨を前記複数の画像処理装置のうち前記画像処理装置とは異なる画像処理装置に通知する通知手段と、
を有することを特徴とする情報処理装置。
【請求項８】
前記サービス提供装置で行われる処理の状態を定期的に確認することで、前記処理が停止されたと判断した場合、前記処理が停止された旨を前記複数の画像処理装置に通知する通知手段を更に有することを特徴とする請求項７に記載の情報処理装置。
【請求項９】
前記通知手段は、前記処理の設定を変更した場合に前記処理が行われるか否かを更に判断し、前記通知に含まれる前記処理を停止した事由を表す情報に基づいて前記処理が行われないと判断した場合、前記処理が停止された旨を前記複数の画像処理装置に通知することを特徴とする請求項８に記載の情報処理装置。
【請求項１０】
複数の画像処理装置と内部ネットワークを介して通信可能であり、前記複数の画像処理装置から外部ネットワークを介して依頼された処理を行うサービス提供装置と前記外部ネットワークを介して通信可能な情報処理装置における通信制御方法であって、
前記サービス提供装置から前記処理の状態を取得する取得工程と、
前記複数の画像処理装置の何れかの画像処理装置より前記処理の状態の確認があった場合、前記取得工程で取得された前記処理の状態を表す情報を前記画像処理装置に返信する返信工程と、
前記サービス提供装置から前記処理を停止した旨の通知を受信した前記画像処理装置からの前記処理が停止された旨の通知に基づいて、前記処理が停止されたと判断した場合、前記処理が停止された旨を前記複数の画像処理装置のうち前記画像処理装置とは異なる画像処理装置に通知する通知工程と、
を有することを特徴とする通信制御方法。
【請求項１１】
請求項７乃至９の何れか１項に記載の手段としてコンピュータを機能させるためのプログラム。
【請求項１２】
外部ネットワークを介して通信可能なサービス提供装置に処理を依頼する複数の画像処理装置と、前記複数の画像処理装置と内部ネットワークを介して通信可能であり、前記サービス提供装置と前記外部ネットワークを介して通信可能な情報処理装置と、を有する通信制御システムであって、
前記複数の画像処理装置は、
前記情報処理装置で取得されている前記処理の状態を確認する確認手段を起動する起動手段と、
前記起動手段で起動された前記確認手段において前記処理の状態が停止状態でないと確認された場合、前記確認手段を停止する停止手段と、
前記確認手段が停止している場合、前記サービス提供装置に前記処理を依頼する依頼手段と、
を有し、
前記情報処理装置は、
前記サービス提供装置から前記処理の状態を取得する取得手段と、
前記複数の画像処理装置の何れかの画像処理装置より前記処理の状態の確認があった場合、前記取得手段で取得された前記処理の状態を表す情報を前記画像処理装置に返信する返信手段と、
を有することを特徴とする通信制御システム。
【請求項１３】
外部ネットワークを介して通信可能なサービス提供装置に処理を依頼する複数の画像処理装置と、前記複数の画像処理装置と内部ネットワークを介して通信可能であり、前記サービス提供装置と前記外部ネットワークを介して通信可能な情報処理装置と、を有する通信制御システムにおける通信制御方法であって、
前記複数の画像処理装置が、
前記情報処理装置で取得されている前記処理の状態を確認する確認手段を起動する起動工程と、
前記起動工程で起動された前記確認手段において前記処理の状態が停止状態でないと確認された場合、前記確認手段を停止する停止工程と、
前記確認手段が停止している場合、前記サービス提供装置に前記処理を依頼する依頼工程と、
を有し、
前記情報処理装置が、
前記サービス提供装置から前記処理の状態を取得する取得工程と、
前記複数の画像処理装置の何れかの画像処理装置より前記処理の状態の確認があった場合、前記取得工程で取得された前記処理の状態を表す情報を前記画像処理装置に返信する返信工程と、
を有することを特徴とする通信制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、外部ネットワーク上のサービス提供装置と、内部ネットワーク上の画像処理装置との通信を制御する技術などに関する。
【背景技術】
【０００２】
近年、多機能複合機（ＭＦＰ）などのデバイスについて多機能化が進み、画像処理などのソフトウェア的な処理もデバイス内で行われるようになってきている。しかしながら、ソフトウェア的な処理は、デバイスが有する他の機能のパフォーマンスへの影響が大きく、また、ソフトウェアを使用するためのインストール作業や設定作業にも手間がかかってしまう。そこで、インターネット上のアプリケーションサービスサーバ（以下、サービスサーバ）によって提供されるアプリケーションサービス（以下、アプリサービス）に、負荷のかかる処理やデバイスが有さない機能の処理などを依頼可能なシステムが提案されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００４−０８８５７０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ここで、デバイスは、デバイスが各々利用しているサービスサーバ上のアプリサービスに対して処理を依頼する。また、デバイスは、障害が発生した後、いつ復旧するのか、既に復旧しているのかなどの問い合わせをサービスサーバやアプリサービスに対して行う。この場合、個々のデバイスがインターネット上のアプリサービスにリクエストを送信する。そのため、アプリサービスもリクエストを送信してきたデバイスそれぞれに対して障害が発生した旨のエラーメッセージを返さなければならない。そのため、インターネットへの過剰なアクセスや通信が発生する問題が生じる。
【０００５】
本発明はこのような問題点に鑑みなされたもので、外部ネットワークへの通信をより低減することを目的とする。
【課題を解決するための手段】
【０００６】
そこで、本発明に係る画像処理装置は、外部ネットワークを介して通信可能なサービス提供装置に処理を依頼する画像処理装置であって、内部ネットワークを介して通信可能な情報処理装置で取得されている前記処理の状態を確認する確認手段を起動する起動手段と、前記起動手段で起動された前記確認手段において前記処理の状態が停止状態でないと確認された場合、前記確認手段を停止する停止手段と、前記確認手段が停止している場合、前記サービス提供装置に前記処理を依頼する依頼手段と、を有することを特徴とする。
【発明の効果】
【０００７】
本発明によれば、外部ネットワークへの通信をより低減することができる。
【図面の簡単な説明】
【０００８】
【図１】障害監視システムの構成の一例を示す図である。
【図２】サーバのハードウェア構成の一例を示す図である。
【図３】デバイスのハードウェア構成の一例を示す図である。
【図４】サーバ及びデバイスの機能構成の一例を示す図である。
【図５】障害発生時処理に係るフローチャートの一例を示す図である。
【図６】監視処理に係るフローチャートの一例を示す図である。
【図７】復旧チェックアプリ制御処理に係るフローチャートの一例を示す図である。
【図８】テーブルの構成の一例を示す図である。
【図９】テーブルの構成の一例を示す図である。
【図１０】テーブルの構成の一例を示す図である。
【図１１】各機器間で行われる一連の処理の流れの一例を示す図である。
【発明を実施するための形態】
【０００９】
以下、本発明の実施形態について図面に基づいて説明する。
【００１０】
＜第１の実施形態＞
図１は、第１の実施形態に係る障害監視システムの構成の一例を示す図である。障害監視システムは、通信制御システムの一例であり、サービスサーバ１０３（１）、・・・、１０３（Ｎ）、デバイス管理サーバ１０４、及びデバイス１０５（１）、・・・、１０５（Ｎ）を含んで構成される。なお、本実施形態では、サービスサーバ１０３（１）、・・・、１０３（Ｎ）は、説明の便宜上、不特定のサービスサーバを表す場合（全体を表す場合も含む。）は、単にサービスサーバ１０３と表記する。他方、特定のサービスサーバを示す場合は、サービスサーバ１０３（Ｘ）、サービスサーバ１０３（Ｙ）等と表記する。また、デバイス１０５（１）、・・・、１０５（Ｎ）は、説明の便宜上、不特定のデバイスを表す場合（全体を表す場合も含む。）は、単にデバイス１０５と表記する。他方、特定のデバイスを示す場合は、デバイス１０５（Ｘ）、デバイス１０５（Ｙ）等と表記する。
デバイス管理サーバ１０４及びデバイス１０５は、内部ネットワークの一例であるローカルエリアネットワーク（以下、ＬＡＮ）１０１を介して互いに通信可能に接続されている。また、デバイス管理サーバ１０４及びデバイス１０５は、外部ネットワークの一例であるインターネット１０２を介してサービスサーバ１０３に通信可能に接続されている。
【００１１】
サービスサーバ１０３は、情報処理装置（コンピュータ）の一例であり、デバイス管理サーバ１０４及びデバイス１０５と通信し、デバイス管理サーバ１０４及びデバイス１０５からインターネット１０２を介して送信される各種の要求（リクエスト）を受信する。また、サービスサーバ１０３は、各種の要求に従って処理を行う。
デバイス管理サーバ１０４は、情報処理装置（コンピュータ）の一例であり、デバイス１０５の使用可否状態、設置場所などの情報を管理し、サービスサーバ１０３で障害が発生している旨の通知（障害発生通知）をデバイス１０５から受信する。また、デバイス管理サーバ１０４は、障害発生通知を受信後に、障害発生通知を送信したデバイス１０５（Ｘ）以外の他のデバイス１０５（Ｙ）などに対して後述の復旧チェックアプリケーション（復旧チェックアプリ）の起動を指示する。
【００１２】
デバイス１０５は、画像処理装置の一例であり、スキャン送信機能、印刷機能、インターネット１０２への接続機能などを備えるプリンタ、ＦＡＸ、多機能複合機などである。
本実施形態では、インターネット１０２（いわゆるクラウド）上のアプリサービスで障害が発生したとき、ＬＡＮ１０１内のデバイス管理サーバ１０４が代表して監視を行う。これにより、アプリサービスを利用する複数のデバイス１０５がアプリサービスを監視しないで済むようになる。また、デバイス管理サーバ１０４が管理下のデバイス１０５に対して、復旧チェックアプリ（アプリサービスへの直接の問い合わせをさせないためのチェックアプリケーション）の起動を指示する。
【００１３】
図２は、サーバ２００（サービスサーバ１０３及びデバイス管理サーバ１０４）のハードウェア構成の一例を示す図である。なお、サーバ２００のハードウェア構成には、一般的な情報処理装置のハードウェア構成を採用することができる。
ＣＰＵ２０１は、サーバ２００の演算／制御を司る。ＲＡＭ２０２は、ＣＰＵ２０１の主メモリとして機能し、例えば、各種のプログラムの実行エリア、データエリアとして機能する。各種のプログラムは、ＣＰＵ２０１により、外部メモリ２１３からＲＡＭ２０２に読み出されて実行される。
プログラムＲＯＭ２０３は、サーバ２００の機器の制御を行う基本ソフト（ＯＳ：Operating System）のプログラム等を格納する。例えば、サービスサーバ１０３においては、プログラムＲＯＭ２０３は、デバイス１０５から依頼された処理を行うサービスを提供するサービスアプリケーション（サービスアプリ）に係るプログラムを格納する。データＲＯＭ２０４は、サーバ２００を稼動させるために必要な情報などを格納する。サーバ２００を稼動させるために必要な情報としては、例えば、デバイス管理サーバ１０４においては、管理するデバイス１０５の使用可否状態、設置場所などの情報がある。なお、データＲＯＭ２０４に代えて、外部メモリ２１３を用いてもよい。
【００１４】
ネットワークコントローラ（以下、ＮＣ）２０５は、ネットワーク（ＬＡＮ１０１など）に接続され、他のネットワークに接続された機器との通信制御処理を実行する。キーボードコントローラ２０６は、キーボード２１１からのキー入力を制御する。ディスプレイコントローラ２０７は、サーバ２００内の情報をディスプレイ２１２の画面に表示するために画像データを展開し、その表示の制御を行う。ディスクコントローラ２０８は、例えば、デバイス管理サーバ１０４においては、管理するデバイス１０５の使用可否状態、設置場所などの情報の外部メモリ２１３における入出力を制御する。
キーボード２１１は、サーバ２００を管理する管理者が入力操作を行うための機器である。例えば、サービスサーバ１０３で障害が発生した場合、管理者は、復旧作業を行うために、ディスプレイ２１２に表示される情報を見ながらキーボード２１１を操作する。ディスプレイ２１２は、ＬＣＤなどの表示装置である。外部メモリ（ＨＤ：Hard Disk、ＦＤ：Flexible Disk）２１３は、アプリケーションに係るプログラムなどの各種データを格納する。
【００１５】
本実施形態では、サービスサーバ１０３のＣＰＵ２０１が、外部メモリ２１３に格納されたプログラムの手順に従って処理を行うことによって、サービスサーバ１０３における機能及び後述するフローチャートに係る処理が実現される。また、デバイス管理サーバ１０４のＣＰＵ２０１が、外部メモリ２１３に格納されたプログラムの手順に従って処理を行うことによって、デバイス管理サーバ１０４における機能及び後述するフローチャートに係る処理が実現される。
なお、サーバ２００のハードウェア構成は、上述したハードウェア構成に限られるものではなく、適宜の構成を採用することができる。例えば、デバイス管理サーバ１０４は、キーボード２１１及びディスプレイ２１２を備えていなくてもよい。
【００１６】
図３は、デバイス１０５のハードウェア構成の一例を示す図である。なお、図２に示す構成と同様の構成については、説明を適宜省略する。ＣＰＵ３０１は、ＣＰＵ２０１と同様であり、ＲＡＭ３０２は、ＲＡＭ２０２と同様であり、プログラムＲＯＭ３０３は、プログラムＲＯＭ２０３と同様である。ただし、プログラムＲＯＭ３０３には、例えば、サービスサーバ１０３への処理の依頼を行うアプリケーションに係るプログラムが格納されている。また、例えば、プログラムＲＯＭ３０３には、サービスサーバ１０３で障害が発生したときに、デバイス管理サーバ１０４にサービスサーバ１０３のステータスを確認するための復旧チェックアプリケーションに係るプログラムが格納されている。データＲＯＭ３０４は、データＲＯＭ２０４と同様であり、ＮＣ３０５は、ＮＣ２０５と同様であり、キーボードコントローラ３０６は、キーボードコントローラ２０６と同様である。ディスプレイコントローラ３０７は、ディスプレイコントローラ２０７と同様であり、ディスクコントローラ３０８は、ディスクコントローラ２０８と同様である。
【００１７】
スキャナコントローラ３０９は、スキャナ部３１４で紙文書がスキャンされて生成される画像データの制御を行う。プリンタコントローラ３１０は、デバイス１０５内の情報、ＬＡＮ１０１やインターネット１０２を介して受信した情報を印刷用画像データに展開し、プリンタ部３１５によって紙に出力するための制御を行う。キーボード３１１は、キーボード２１１と同様であり、ディスプレイ３１２は、ディスプレイ２１２と同様であり、外部メモリ３１３は、外部メモリ２１３と同様である。
スキャナ部３１４は、デバイス１０５の利用者が紙文書をスキャンするためのスキャナ装置である。プリンタ部３１５は、デバイス１０５の利用者がデバイス１０５内の情報、ＬＡＮ１０１やインターネット１０２を介して受信した情報を印刷するためのプリンタ装置である。
なお、デバイス１０５のハードウェア構成は、上述したハードウェア構成に限られるものではなく、適宜の構成を採用することができる。例えば、デバイス１０５は、プリンタ部３１５を備えていなくてもよい。
【００１８】
図４は、サービスサーバ１０３、デバイス管理サーバ１０４、及びデバイス１０５の機能構成の一例を示す図である。
デバイス管理部４０１は、デバイス管理サーバ１０４の管理下にある全てのデバイス１０５の使用可否状態、設置場所などの情報を管理（例えば、図１０に示すようなデバイス管理テーブル１０００でデータを管理）する。アプリケーション制御部（以下、アプリ制御部）４０２は、デバイス管理部４０１で管理するデバイス１０５に対して復旧チェックアプリの起動や終了を指示する。サービス監視部４０３は、サービスアプリが障害などから復旧しているか否かを判断などする際に、サービスサーバ１０３のステータスを確認する。送受信部４０４は、ＬＡＮ１０１やインターネット１０２を介して、ネットワーク上の機器と通信を行う。
【００１９】
スキャン処理部４１１は、スキャナ部３１４を用いて紙をスキャンし、画像データを生成する処理を行う。なお、スキャン処理部４１１は、デバイス１０５がスキャン機能を有する場合に設けられる。印刷処理部４１２は、デバイス１０５内の情報、ＬＡＮ１０１やインターネット１０２を介して受信した情報を、プリンタ部３１５で印刷するための印刷用画像データに展開し、プリンタ部３１５にデータを渡す処理を行う。なお、印刷処理部４１２は、デバイス１０５が印刷機能を有する場合に設けられる。復旧チェック部４１３は、復旧チェックアプリにより実現される機能の一例である。復旧チェックアプリは、デバイス管理サーバ１０４で管理される全てのデバイス１０５にインストールされている。また、復旧チェックアプリは、サービスサーバ１０３のサービス提供部４２１に処理を依頼して障害が発生したときに起動され、或いはデバイス管理サーバ１０４からの起動の指示を受信したときに起動され、デバイス１０５上で常に起動しているものではない。送受信部４１４は、ＬＡＮ１０１やインターネット１０２を介して、ネットワーク上の機器と通信を行う。
【００２０】
ここで、本実施形態では、説明の便宜上、デバイス管理サーバ１０４が管理するデバイス１０５は、全てが復旧チェックアプリを有しているが、この構成に限られるものではない。例えば、デバイス管理サーバ１０４が管理するデバイスに本実施形態に適応していない（例えば、復旧チェックアプリの機能を実現できない）デバイスが含まれていてもよい。
また、例えば、デバイス１０５としては、組込みプログラムとして復旧チェックアプリの機能を備えるデバイスを採用してもよい。例えば、デバイス管理サーバ１０４は、デバイス構成情報（タイプ、ネットワーク情報、ファーム情報、搭載オプションなど）を管理し、デバイス構成情報を参照して、デバイス１０５に相当するデバイスを特定できる。
【００２１】
サービス提供部４２１（１）、・・・、４２１（Ｎ）は、サービスアプリにより実現される機能（サービス）の一例であり、各種のサービスを提供する。サービス提供部４２１（１）、・・・、４２１（Ｎ）は、説明の便宜上、不特定のサービス提供部４２１を表す場合（全体を表す場合も含む。）は、単にサービス提供部４２１と表記する。他方、特定のサービス提供部４２１を示す場合は、サービス提供部４２１（Ａ）、サービス提供部４２１（Ｂ）等と表記する。
エラー処理部４２２は、サービス提供部４２１がデバイス１０５から依頼された処理を行っているときに障害が発生した場合に、デバイス１０５に対して障害が発生したことを知らせるためにエラーコードやエラーメッセージを返す処理を行う。
【００２２】
復旧時刻管理部４２３は、サービス提供部４２１によるサービスの提供（アプリサービス）の復旧予定に関する情報を、例えば、図８に示すようなステータス管理テーブル８００で管理する。例えば、サービス提供部４２１がデバイス１０５から依頼された処理を行っているときに障害が発生し、以降の処理が不可能になった場合、サービスサーバ１０３の管理者により復旧作業が行われる。また、障害によるアプリサービスの提供の停止の他に、定期的なメンテナンス作業などでアプリサービスが停止させられることもある。このとき、管理者は、復旧作業やメンテナンスを行う際に復旧の予定時刻が予めわかれば、キーボード２１１等を操作して、復旧の予定に関する情報を図８に示すようなステータス管理テーブル８００に設定する。
認証処理部４２４は、デバイス１０５から処理の依頼を受けるときに、デバイス１０５の利用者がアプリサービスを利用できるユーザであるかの認証処理を行う。送受信部４２５は、インターネット１０２を介して、例えば、デバイス管理サーバ１０４やデバイス１０５と通信を行う。
【００２３】
図５は、デバイス１０５における障害発生時処理に係るフローチャートの一例を示す図である。ここでは、デバイス１０５（Ｘ）が、サービス提供部４２１（Ａ）に対して処理を依頼し、サービス提供部４２１（Ａ）で障害が発生した場合を例に挙げて説明する。なお、デバイス１０５（Ｘ）は、デバイス管理サーバ１０４に対してサービス提供部４２１（Ａ）で障害が発生したことを第１通報者として通知する。
Ｓ５０１では、デバイス１０５（Ｘ）は、利用者によるユーザ操作に応答し、送受信部４１４を介してサービス提供部４２１（Ａ）にアクセスする。例えば、デバイス１０５（Ｘ）は、自己ではできない処理をサービス提供部４２１（Ａ）に依頼する。
Ｓ５０２では、デバイス１０５（Ｘ）は、サービス提供部４２１（Ａ）での処理中に障害が発生すると、送受信部４１４を介して、サービスサーバ１０３からエラーコードを受信する。エラーコードは、サービス提供部４２１（Ａ）が処理を停止した事由を表す情報の一例であり、サービス提供部４２１（Ａ）での障害がどのような障害であるかを識別可能なコードである。デバイス１０５（Ｘ）の利用者は、エラーコードを把握することで依頼した処理が正常に終了しなかったことを認識できる。障害には、例えば、デバイス１０５（Ｘ）の利用者の設定ミスなどでエラーが発生するもの（単に設定を修正すれば解決するもの）や、サービスサーバ１０３の管理者が作業をしないと正常に動作しないものがある。
【００２４】
Ｓ５０３では、デバイス１０５（Ｘ）は、復旧チェックアプリを起動する（復旧チェック部４１３を機能させる）。より詳細に説明すると、デバイス１０５（Ｘ）は、デバイス１０５では回避できない障害であると判断した場合、換言するならば、管理者による復旧作業が必要となる障害であると判断した場合、Ｓ５０３の処理を行う。なお、デバイス１０５（Ｘ）は、エラーコードに基づいて、管理者による復旧作業が不要な障害であると判断した場合、例えば利用者の設定ミスなどでエラーが発生した場合は再設定を促す旨の情報を利用者に提示し、処理を終了する。
Ｓ５０４では、復旧チェック部４１３は、送受信部４１４を介して、デバイス管理サーバ１０４に対してサービス提供部４２１（Ａ）で障害が発生した旨を通知（障害発生通知）する。デバイス管理サーバ１０４は、障害発生通知を契機に、サービス監視部４０３によってサービス提供部４２１（Ａ）での処理の状態（ステータス）を監視する処理を開始する。
以上のように、デバイス１０５（Ｘ）は、サービスサーバ１０３のサービス提供部４２１（Ａ）での障害を検知し、復旧チェックアプリを起動してデバイス管理サーバ１０４に障害発生通知を行う。
【００２５】
図６は、デバイス管理サーバ１０４における監視処理に係るフローチャートの一例を示す図である。図６に示す監視処理は、Ｓ５０４でデバイス１０５（Ｘ）からサービス提供部４２１（Ａ）で障害が発生した旨の通知を受けてからサービス提供部４２１（Ａ）での障害が復旧するまでのデバイス管理サーバ１０４における処理の一例である。
Ｓ６０１では、デバイス管理サーバ１０４は、デバイス１０５（Ｘ）からサービス提供部４２１（Ａ）で障害が発生した旨の通知（障害発生通知）を受信したか否かを判断する。サービス提供部４２１（Ａ）で障害が発生した旨の通知を受信したと判断した場合、Ｓ６０２の処理の処理を行い、サービス提供部４２１（Ａ）で障害が発生した旨の通知を受信していないと判断した場合、再び、Ｓ６０１の処理を行う。
【００２６】
Ｓ６０２では、デバイス管理サーバ１０４は、サービス監視部４０３を介してサービス提供部４２１（Ａ）のステータスを確認する。サービス提供部４２１（Ａ）のステータスは、図８に示すようなステータス管理テーブル８００でサービスサーバ１０３により管理されている。
Ｓ６０３では、デバイス管理サーバ１０４は、サービスサーバ１０３から返答されたステータス（確認結果）に基づいて、サービス提供部４２１（Ａ）が正常に動作（稼働）している状態（正常状態）であるか否かを判断する。デバイス管理サーバ１０４は、サービス提供部４２１（Ａ）が正常に動作している状態であると判断した場合、サービス提供部４２１（Ａ）に問題はないので、本処理を終了する。この場合、デバイス１０５（Ｘ）から障害発生通知を受けてから、Ｓ６０２でデバイス管理サーバ１０４がサービス提供部４２１（Ａ）のステータスを確認するまでの間にサービス提供部４２１（Ａ）は、障害から復帰したものと考えられる。他方、デバイス管理サーバ１０４は、サービス提供部４２１（Ａ）が正常に動作している状態でない（処理が停止している停止状態の一例である、障害状態、メンテナンス状態等）と判断した場合、Ｓ６０４の処理を行う。この場合、デバイス管理サーバ１０４は、Ｓ６０２の処理において後述のＳ６０５の処理のために、サービスサーバ１０３から、サービス提供部４２１（Ａ）が障害などから復旧する予定の時刻（復旧予定時刻）もあわせて取得する。
【００２７】
Ｓ６０４では、デバイス管理サーバ１０４は、デバイス管理部４０１で管理しているデバイス１０５に対して、夫々のデバイス１０５内の復旧チェックアプリを起動するように、アプリ制御部４０２を介して指示する。
Ｓ６０５では、デバイス管理サーバ１０４は、Ｓ６０２において復旧予定時刻を取得できたか否かを判断する。復旧予定時刻が取得できなかったと判断した場合は、デバイス管理サーバ１０４は、復旧予定時刻が未定であるので、Ｓ６０６の処理を行う。他方、復旧予定時刻を取得できたと判断した場合は、デバイス管理サーバ１０４は、Ｓ６０８の処理を行う。
【００２８】
Ｓ６０６では、デバイス管理サーバ１０４は、図９に示すようなステータス管理テーブル９００で復旧予定時刻を未定として管理し、ステップＳ６０７の処理を行う。
Ｓ６０７では、デバイス管理サーバ１０４は、サービスサーバ１０３への定期的なステータスの確認を行った結果、サービス提供部４２１（Ａ）が復旧したか否かを判断する。なお、デバイス管理サーバ１０４は、復旧予定時刻が未定であると判断したので、ある一定間隔でサービス提供部４２１（Ａ）のステータスを確認している。このとき、デバイス管理サーバ１０４は、サービス提供部４２１（Ａ）が復旧したと判断した場合、Ｓ６１１の処理を行う。他方、デバイス管理サーバ１０４は、サービス提供部４２１（Ａ）が復旧しないままの状態であると判断した場合、再び、Ｓ６０７の処理を行う。
【００２９】
Ｓ６０８では、デバイス管理サーバ１０４は、図９に示すようなステータス管理テーブル９００にサービスサーバ１０３から取得した復旧予定時刻を設定して管理する。
Ｓ６０９では、デバイス管理サーバ１０４は、復旧予定時刻に行うサービスサーバ１０３へのステータスの確認の結果、サービス提供部４２１（Ａ）が復旧したか否かを判断する。このとき、デバイス管理サーバ１０４は、サービス提供部４２１（Ａ）が復旧したと判断した場合、Ｓ６１１の処理の処理を行う。他方、デバイス管理サーバ１０４は、サービス提供部４２１（Ａ）が復旧しないままの状態であると判断した場合、Ｓ６１０の処理を行う。
Ｓ６１０では、デバイス管理サーバ１０４は、サービスサーバ１０３に対して復旧予定時刻に変更があったか否かを確認し、新たな復旧予定時刻が設定されていたと判断した場合、新たな復旧予定時刻をステータス管理テーブル９００に設定する（Ｓ６０８）。他方、新たな復旧予定時刻が設定されていないと判断した場合、デバイス管理サーバ１０４は、Ｓ６０７の処理を行う。
【００３０】
Ｓ６１１では、デバイス管理サーバ１０４は、サービス提供部４２１（Ａ）が正常状態になったので、ステータス管理テーブル９００に正常状態を表すステータスを設定する。
Ｓ６１２では、デバイス管理サーバ１０４は、デバイス１０５（Ｘ）の復旧チェック部４１３からサービス提供部４２１（Ａ）が復旧したかどうかの問い合わせ要求（復旧チェック要求）を受信したか否かを判断する。デバイス１０５（Ｘ）からの問い合わせ要求を受信したと判断した場合、デバイス管理サーバ１０４は、Ｓ６１３の処理を行う。この場合、デバイス管理サーバ１０４は、デバイス１０５（Ｘ）がサービス提供部４２１（Ａ）に処理を依頼しようとしたことを表す。デバイス１０５（Ｘ）からの問い合わせ要求を受信しないと判断した場合は、引き続き問い合わせ要求を待つ。この場合、デバイス１０５（Ｘ）は、サービス提供部４２１（Ａ）への処理の依頼がないことを表す。
【００３１】
Ｓ６１３では、デバイス管理サーバ１０４は、サービス提供部４２１（Ａ）が復旧したので、アプリ制御部４０２を介してデバイス１０５（Ｘ）に対して復旧チェックアプリを終了するように指示する。この指示に応答して、デバイス１０５（Ｘ）は、復旧チェックアプリを終了し、サービス提供部４２１（Ａ）にアクセスすることができるようになる。なお、デバイス１０５（Ｘ）以外のデバイス１０５については、サービス提供部４２１（Ａ）へのアクセスはできないままの状態である。デバイス１０５（Ｘ）以外のデバイス１０５については、サービス提供部４２１（Ａ）にアクセスしようとしたときに、サービス提供部４２１（Ａ）にアクセス可能となり得る（例えば図７参照）。
【００３２】
図７は、デバイス１０５（Ｘ）以外のデバイス１０５（Ｙ）が、デバイス管理サーバ１０４から復旧チェックアプリの起動を指示されてから復旧チェックアプリを終了するまでの処理（復旧チェックアプリ制御処理）に係るフローチャートの一例を示す図である。
Ｓ７０１では、デバイス１０５（Ｙ）は、デバイス管理サーバ１０４による復旧チェックアプリの起動を指示する旨の起動指示を受信する。
Ｓ７０２では、デバイス１０５（Ｙ）は、デバイス管理サーバ１０４からの起動指示に基づいて、復旧チェックアプリを起動する（復旧チェック部４１３を機能させる）。
【００３３】
Ｓ７０３では、デバイス１０５（Ｙ）の復旧チェック部４１３は、デバイス１０５（Ｙ）の利用者がキーボード３１１等の入力装置を介してデバイス１０５（Ｙ）ではできない処理をサービスサーバ１０３に依頼したか否かを判断する。すなわち、デバイス１０５（Ｙ）の利用者がサービス提供部４２１（Ａ）にアクセスしようとしたと判断した場合、復旧チェック部４１３は、Ｓ７０４の処理の処理を行う。他方、デバイス１０５（Ｙ）の利用者がサービス提供部４２１（Ａ）にアクセスしようとしていないと判断した場合、復旧チェック部４１３は、本処理を終了する。したがって、障害によって利用できないサービス提供部４２１（Ａ）へのアクセスが制限され、無駄なインターネット１０２への通信が行われなくなる。
Ｓ７０４では、復旧チェック部４１３は、デバイス管理サーバ１０４に対してサービス提供部４２１（Ａ）のステータスを確認する。
【００３４】
Ｓ７０５では、復旧チェック部４１３は、デバイス管理サーバ１０４からサービス提供部４２１（Ａ）のステータスを受け取り、サービス提供部４２１（Ａ）が障害から復旧したか否か（即ち、サービス提供部４２１が停止状態であるか否か）を判断する。サービス提供部４２１（Ａ）が障害から復旧していたと判断された場合、デバイス１０５（Ｙ）は、Ｓ７０６の処理を行う。他方、サービス提供部４２１（Ａ）が障害から復旧していなかったと判断された場合、デバイス１０５（Ｙ）は、デバイス１０５（Ｙ）の利用者に対して、サービス提供部４２１（Ａ）が利用できない旨を通知する。そして、デバイス１０５（Ｙ）は、サービス提供部４２１（Ａ）へのアクセスを許可せずに、本処理を終了する。
【００３５】
Ｓ７０６では、デバイス１０５（Ｙ）は、サービス提供部４２１（Ａ）が障害から復旧しているので、復旧チェックアプリを終了する。
Ｓ７０７では、デバイス１０５（Ｙ）は、デバイス１０５（Ｙ）の利用者がサービス提供部４２１（Ａ）にアクセスしようとしているので、復旧したサービス提供部４２１（Ａ）に処理の実行を依頼する。このように、デバイス１０５（Ｙ）は、障害から復旧したサービス提供部４２１（Ａ）に対して正常にアクセスできるようになる。
【００３６】
図８は、サービスサーバ１０３の復旧時刻管理部４２３で管理されるサービス提供部４２１に関する情報を格納するテーブルの構成の一例（ステータス管理テーブル８００）を示す図である。
ステータス管理テーブル８００には、サービスサーバ１０３上で動作する１つのサービスアプリ（サービス提供部４２１）に対して１つのレコードが格納される。このレコードは、サービス提供部４２１が現在どのような状態にあるか、障害状態などにある場合にはいつ復旧するのかなどの情報を含んで構成される。なお、ステータス管理テーブル８００には、アプリＩＤ８０１、アプリ名８０２、ステータス８０３、及び復旧予定時刻８０４の各項目の情報が格納されるが、これらの項目は障害監視システムの作りによって異なり得るので、明示した項目に限られるものではない。
【００３７】
アプリＩＤ８０１の情報は、サービスサーバ１０３に複数のサービスアプリが存在する場合、それぞれのサービスアプリを識別可能な一意な値である。アプリ名８０２の情報は、サービスアプリの名称を表す情報である。ステータス８０３の情報は、サービスアプリのステータスを表す情報である。デバイス管理サーバ１０４は、ステータス８０３の情報を取得することで、サービス提供部４２１が正常に動作しているかどうか、サービス提供部４２１が停止している場合はどのようなステータスであるかなどを判別できる。復旧予定時刻８０４の情報は、サービス提供部４２１が正常に動作していない場合などにおいて、サービス提供部４２１が復旧する予定の時刻を表す情報である。例えば、復旧が未定である場合、復旧未定の情報が設定される。
【００３８】
図９は、デバイス管理サーバ１０４のサービス監視部４０３で監視されるサービス提供部４２１に関する情報を格納するテーブルの構成の一例（ステータス管理テーブル９００）を示す図である。
ステータス管理テーブル９００には、デバイス管理サーバ１０４で管理するサービスサーバ１０３の１つのサービスアプリ（サービス提供部４２１）に対して１つのレコードが格納される。また、ステータス管理テーブル９００は、ステータス管理テーブル８００から取得された、サービス提供部４２１が現在どのような状態にあるか、障害状態などにある場合にはいつ復旧するのかなどの情報を格納する。なお、ステータス管理テーブル９００には、サービスサーバＩＤ９０１、アプリＩＤ９０２、アプリ名９０３、ステータス９０４、復旧予定時刻９０５、ＵＲＬ９０６、認証ＩＤ９０７、及びパスワード９０８の各項目の情報が格納される。なお、これらの項目は障害監視システムの作りによって異なり得るので、明示した項目に限られるものではない。
【００３９】
サービスサーバＩＤ９０１の情報は、インターネット１０２上に複数のサービスサーバ１０３が存在する場合、それぞれのサービスサーバ１０３を識別可能な一意な値である。アプリＩＤ９０２の情報は、アプリＩＤ８０１の情報と同様の情報である。なお、デバイス管理サーバ１０４は、インターネット１０２上に複数のサービスアプリを有する複数のサービスサーバ１０３が存在する場合、サービスサーバＩＤ９０１とアプリＩＤ９０２との組み合わせによって、サービスアプリを一意に識別する。アプリ名９０３の情報は、アプリ名８０２の情報の情報と同様の情報である。
【００４０】
ステータス９０４の情報は、ステータス８０３の情報と同様の情報である。デバイス１０５の復旧チェック部４１３は、ステータス９０４の情報を確認することで、サービス提供部４２１が正常に動作しているかどうか、サービス提供部４２１が停止している場合はどのようなステータスであるかなどを判別する。復旧予定時刻９０５の情報は、復旧予定時刻８０４の情報と同様の情報である。ＵＲＬ９０６の情報は、サービスサーバ１０３のサービス提供部４２１のステータスを確認するためのＵＲＬの情報を表す。ＵＲＬの情報は、例えば、予めサービスサーバ１０３内のステータス管理テーブル８００の情報を取得するアプリケーションの実行要求をサービスサーバ１０３に送信する際に用いられる。認証ＩＤ９０７及びパスワード９０８の情報は、ステータス管理テーブル８００の情報を取得するために、サービスサーバ１０３に対して認証処理を行う必要がある場合に用いられる。
【００４１】
図１０は、デバイス管理サーバ１０４のデバイス管理部４０１で管理されるデバイス１０５の情報を格納するテーブルの構成の一例（デバイス管理テーブル１０００）を示す図である。
デバイス管理テーブル１０００には、デバイス管理サーバ１０４で管理される１つのデバイス１０５に対して１つのレコードが格納される。このレコードは、デバイス１０５が現在どのような状態にあるのか、どの場所に設置されているのか、復旧チェック部４１３が作動している状態であるのかなどの情報を含んで構成される。デバイス管理テーブル１０００には、デバイスＩＤ１００１、機種名１００２、使用可否状態１００３、設置場所１００４、復旧チェックアプリステータス１００５の各項目の情報が格納される。なお、これらの項目は障害監視システムの作りによって異なり得るので、明示した項目に限られるものではない。
【００４２】
デバイスＩＤ１００１の情報は、デバイス管理サーバ１０４が管理するＬＡＮ１０１上のデバイス１０５を識別可能な一意な値である。機種名１００２の情報は、デバイス管理サーバ１０４が管理するデバイス１０５の機種の名称を表す情報である。使用可否状態１００３の情報は、デバイス１０５がオンラインの状態にあるのか、使用可能な状態にあるのかなどを表す情報である。設置場所１００４の情報は、デバイス１０５が物理的にどこに設置されているかを表す情報である。復旧チェックアプリステータス１００５は、デバイス１０５の復旧チェックアプリが起動（復旧チェック部４１３が動作）しているのかどうかを表す情報である。
【００４３】
図１１は、デバイス１０５（Ｘ）からの処理の依頼に対して、サービスサーバ１０３のサービス提供部４２１で障害が発生してから復旧するまでに各機器間で行われる一連の処理の流れの一例を示す図である。
Ｓ１１０１では、デバイス１０５（Ｘ）は、サービスサーバ１０３のサービス提供部４２１に対して処理を依頼する。Ｓ１１０１では、デバイス１０５（Ｘ）は、例えば、デバイス１０５（Ｘ）上ではできないような処理や、デバイス１０５（Ｘ）よりもサービス提供部４２１に依頼した方が効率的にできる処理を依頼する。Ｓ１１０２では、サービスサーバ１０３のサービス提供部４２１は、デバイス１０５（Ｘ）から処理の依頼を受け、処理を実行する。Ｓ１１０３では、サービスサーバ１０３は、Ｓ１１０２での処理の結果をデバイス１０５（Ｘ）に返却（返信）する。この例では、Ｓ１１０２の処理で障害が発生したものとし、サービスサーバ１０３は、エラーコードなどのサービス提供部４２１で障害が発生した旨の通知を返却する。なお、サービスサーバ１０３は、サービス提供部４２１で処理が正常に完了された場合は、その結果を返却する。
【００４４】
Ｓ１１０４では、デバイス１０５（Ｘ）は、自身で管理する復旧チェックアプリを起動する。Ｓ１１０５では、復旧チェックアプリの起動により作動する復旧チェック部４１３は、デバイス管理サーバ１０４に対してサービス提供部４２１で障害が発生した旨の通知（障害発生通知）をする。Ｓ１１０６では、送受信部４０４を介してデバイス１０５（Ｘ）から障害発生通知が受信されると、サービス監視部４０３は、サービスサーバ１０３のサービス提供部４２１のステータスを確認する。Ｓ１１０７では、サービスサーバ１０３は、ステータスの確認処理の結果をデバイス管理サーバ１０４に返却する。Ｓ１１０８では、デバイス管理サーバ１０４は、返却されたサービス提供部４２１のステータスをステータス管理テーブル９００に格納（保存）する。
【００４５】
Ｓ１１０９では、デバイス管理サーバ１０４は、デバイス１０５（Ｘ）以外の復旧チェックアプリが未起動のデバイス１０５の情報をデバイス管理テーブル１０００の復旧チェックアプリステータス１００５から取得してデバイス１０５（Ｙ）を特定する。そして、デバイス管理サーバ１０４は、特定したデバイス１０５（Ｙ）に対して復旧チェックアプリの起動を指示する。このようにして、デバイス管理サーバ１０４が管理する全てのデバイス１０５の復旧チェックアプリが起動されることになる。Ｓ１１１０では、デバイス１０５（Ｙ）は、復旧チェックアプリを起動する。
【００４６】
Ｓ１１１１では、デバイス管理サーバ１０４は、サービス提供部４２１が障害状態である間、定期的に、又は復旧予定時刻になったときに、サービス提供部４２１が復旧しているか否かをサービスサーバ１０３に問い合わせる（ステータスを確認する）。Ｓ１１１２では、サービスサーバ１０３は、問い合わせの結果（ステータス）をデバイス管理サーバ１０４に返却する。
ここで、Ｓ１１１３及びＳ１１１４の処理は、サービス提供部４２１が障害から復旧していないときのデバイス１０５における処理である。本図では、Ｓ１１１３及びＳ１１１４の処理については、便宜的に、デバイス１０５（Ｘ）だけが行っている処理として示しているが、デバイス１０５（Ｘ）に限らず全てのデバイス１０５が行い得る処理である。Ｓ１１１３では、復旧チェック部４１３は、サービス提供部４２１に処理を依頼しようとしたとき、デバイス管理サーバ１０４にサービス提供部４２１が復旧しているかどうかを問い合わせる（ステータスを確認する）。Ｓ１１１４では、デバイス管理サーバ１０４は、サービス提供部４２１のステータスを返却する。この例では、ステータス９０４の情報が「障害復旧作業中」であるので、サービス提供部４２１が障害状態である旨のステータス「障害復旧作業中」を返却する。
【００４７】
ここで、Ｓ１１１５からＳ１１２０までの処理は、サービス提供部４２１が障害などから復旧していたときのデバイス１０５の処理である。本図では、これらの処理については、便宜的に、デバイス１０５（Ｘ）だけが行っている処理として示しているが、デバイス１０５（Ｘ）に限らず全てのデバイス１０５が行い得る処理である。Ｓ１１１５では、復旧チェック部４１３は、サービス提供部４２１に処理を依頼しようとしたとき、デバイス管理サーバ１０４にサービス提供部４２１が復旧しているか否かを問い合わせる（ステータスを確認する）。Ｓ１１１６では、デバイス管理サーバ１０４は、サービス提供部４２１のステータスを返却する。この例では、ステータス９０４の情報が「正常」であるので、サービス提供部４２１が復旧した旨のステータス「正常」を返却する。Ｓ１１１７では、デバイス１０５（Ｘ）は、サービス提供部４２１が復旧していたので、復旧チェック部４１３を終了する。
【００４８】
Ｓ１１１８では、復旧チェック部４１３が終了することにより、デバイス１０５（Ｘ）は、サービス提供部４２１にアクセスすることが可能になるので、デバイス１０５（Ｘ）は、サービスサーバ１０３のサービス提供部４２１に処理を依頼する。Ｓ１１１９では、サービス提供部４２１は、デバイス１０５（Ｘ）から依頼された処理を実行する。Ｓ１１２０は、サービスサーバ１０３は、処理の結果をデバイス１０５（Ｘ）に返却する。
ここで、ＬＡＮ１０１内のデバイスとインターネット１０２上のサービス提供部４２１との間には、一般的に、ファイヤーウォールがある。そのため、デバイスがサービス提供部４２１に問い合わせない限り、デバイスは、サービス提供部４２１が復旧したことを知ることができない。
しかしながら、本実施形態のデバイス１０５は、復旧チェックアプリを有し、復旧チェックアプリは、ＬＡＮ１０１上のデバイス管理サーバ１０４にサービス提供部４２１の状態を確認する。よって、デバイス１０５は、サービス提供部４２１に直接アクセスすることなくサービス提供部４２１の状態を確認することが可能となり、サービス提供部４２１が復旧したことを知ることができる。
【００４９】
＜第２の実施形態＞
第１の実施形態では、デバイス１０５（Ｘ）がサービス提供部４２１の障害を検知し、デバイス管理サーバ１０４に対してサービス提供部４２１で障害が発生したことを通知する例を示した。第２の実施形態では、デバイス管理サーバ１０４が定期的にサービス提供部４２１のステータスをチェックし、デバイス管理サーバ１０４がサービス提供部４２１の障害を検知する例を示す。
より具体的には、第１の実施形態との主な違いは、図１１のＳ１１０５でデバイス１０５（Ｘ）からの障害発生通知を受けることなく、Ｓ１１０６以降の処理を行い、Ｓ１１０６及びＳ１１０７の処理を定期的に行うことである。
この構成によれば、デバイス管理サーバ１０４は、デバイス１０５からの障害発生通知を受けることなく、自身がサービス提供部４２１の障害に気付いた場合にデバイス１０５へ復旧チェックアプリの起動を指示することが可能となる。付言するならば、デバイス管理サーバ１０４は、サービス提供部４２１の障害を検知したとき、管理者による復旧作業が必要となる障害であると判断した場合、復旧チェックアプリを起動する旨を指示する。なお、第１の実施形態及び第２の実施形態に限られるものではなく、第１の実施形態の構成と第２の実施形態の構成とを組み合わせてもよい。
【００５０】
＜その他の実施形態＞
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【００５１】
上述した実施形態の構成によれば、外部ネットワークへの通信をより低減することができる。
【００５２】
以上、本発明の好ましい実施形態について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【図１】
0005606155.tif 000002
【図２】
0005606155.tif 000003
【図３】
0005606155.tif 000004
【図４】
0005606155.tif 000005
【図５】
0005606155.tif 000006
【図６】
0005606155.tif 000007
【図７】
0005606155.tif 000008
【図８】
0005606155.tif 000009
【図９】
0005606155.tif 000010
【図１０】
0005606155.tif 000011
【図１１】
0005606155.tif 000012