JP4916227B2 - デバイスの管理装置及びその管理装置の制御方法 - Google Patents

Description

本発明は、ネットワーク通信を用いたデバイスの管理装置及びその管理装置の制御方法に関する。特に、ネットワークを介して遠隔でデバイスを管理する被管理装置への指示をネットワークを介して処理する管理サーバの制御方法、それを実現するアプリケーションプログラムに関するものである。

従来から、管理サーバからネットワークを介して顧客先のデバイスを管理するメンテナンスシステムが知られている。この従来のメンテナンスシステムでは、例えば、デバイスステータス取得やデバイスの各種設定変更等を行っていた。この場合、まず管理サーバがイニシエーターとなり、例えば、インターネット回線を介しデバイスへアクセスし、上述の各種処理を行っていた。

しかし、インターネット等の普及に伴いセキュリティ技術が強化され、従来の仕組みでは不都合を生じる場合が出てきた。例えば、インターネット上の管理サーバから自発的に顧客のデバイスへアクセスするには、ファイアウォールが障害となってしまう。 該環境下では、充分なメンテナンスを実現できないという問題があった。

かかる問題を解決するため、特許文献１には、管理サーバと被管理装置との間に第三の中継サーバを設けたシステムが開示されている。このシステムでは、管理サーバの発行したコマンドを中継サーバの特定フォルダに格納し、被管理装置は特定フォルダにコマンドが格納されたかを監視して、設定コマンドが準備されていればコマンドを取得して実行する。
特開２００２−０８２７９２公報

しかしながら、上記特許文献１では、中継サーバという余分な設備を準備する必要がある。更に、中継サーバは単にコマンドを受渡するのみであるため、管理サーバからのコマンド発行を無駄無く行なってネットワークへの負担を軽減するなど、管理サーバからの柔軟な動作指示を制御することができない。

本発明は、前記従来の問題点に鑑み、余分な設備を追加すること無しに、ファイアウォールを具備するセキュリティ環境でも充分なメンテナンスを実現できるデバイスの管理装置を提供する。更に、複数の動作指示を扱う際に適切な指示制御を行え、無駄な指示や被管理デバイスの無駄な負荷を抑制できるデイスの管理装置及びその管理装置の制御方法を提供する。

上述した課題を解決するために、本発明の管理装置は、ファイアウォールにより外部からのネットワークを介したアクセスが制限されるネットワーク環境に設置された被管理デバイスと前記ネットワークを介して接続され、前記ファイアウォールの外部のネットワーク環境に設置される管理装置であって、前記被管理デバイスへの、被管理デバイスの監視対象となる複写機の追加、削除及び属性情報の変更のいずれかの指示を入力するための入力手段と、前記入力手段を介して入力された複数の指示を保管する指示保管手段と、前記指示保管手段により保管された複数の指示を、より少ない数の指示に変更する指示変更手段と、前記被管理デバイスから前記ファイアウォールを越えて、前記入力手段を介して入力された指示の有無の問い合わせを受けた際に、前記指示変更手段により削除されずに、変更された指示があれば、前記問い合わせに対して当該入力された指示を前記問い合わせを受けた際に張られたセッションにおいて前記被管理デバイスへ返信する指示返信手段とを有し、前記指示返信手段は、前記被管理デバイスからの前記問い合わせに応じて１つの指示を前記被管理デバイスへ返信すると共に、前記被管理デバイスからの前記返信に対応する応答に応じて、前記セッションを維持しつつ、前記被管理デバイスへの指示の返信を更に行い、前記指示変更手段は、前記指示保管手段により保管された複数の指示の中に削除の指示と、当該削除の指示の前に実行されるべき指示として対象となる複写機の追加の指示があった場合に、当該削除の指示及び当該追加の指示を削除し、前記指示変更手段は、前記指示保管手段により保管された複数の指示の中に同じ複写機に対する属性情報の変更の指示があった場合に、いずれかの指示のみを行うよう変更することを特徴とする。

また、本発明の管理装置の制御方法は、ファイアウォールにより外部からのネットワークを介したアクセスが制限されるネットワーク環境に設置された被管理デバイスと前記ネットワークを介して接続され、前記ファイアウォールの外部のネットワーク環境に設置される管理装置の制御方法であって、前記管理装置の入力手段が、前記被管理デバイスへの、被管理デバイスの監視対象となる複写機の追加、削除及び属性情報の変更のいずれかの指示の入力を取得する取得工程と、前記管理装置の指示保管手段が、前記取得工程にて取得した複数の指示を保管する指示保管工程と、前記管理装置の指示変更手段が、前記指示保管手段により保管された複数の指示を、より少ない数の指示に変更する指示変更工程と、前記管理装置の指示返信手段が、前記被管理デバイスから前記ファイアウォールを越えて、前記取得工程で取得された指示の有無の問い合わせを受けた際に、前記指示変更工程にて削除されずに、変更された指示があれば、前記問い合わせに対して当該取得された指示を前記問い合わせを受けた際に張られたセッションにおいて前記被管理デバイスへ返信する指示返信工程とを有し、前記指示返信工程では、前記被管理デバイスからの前記問い合わせに応じて１つの指示を前記被管理デバイスへ返信すると共に、前記被管理デバイスからの前記返信に対応する応答に応じて、前記セッションを維持しつつ、前記被管理デバイスへの指示の返信を更に行い、前記指示変更工程にて、前記指示保管工程により保管された複数の指示の中に削除の指示と、当該削除の指示の前に実行されるべき指示として対象となる複写機の追加の指示があった場合に、当該削除の指示及び当該追加の指示を削除し、前記指示変更工程にて、前記指示保管工程により保管された複数の指示の中に同じ複写機に対する属性情報の変更の指示があった場合に、いずれかの指示のみを行うよう変更することを特徴とする。

更に、上記管理装置の制御方法の工程をコンピュータに実行させるためのプログラムを提供する。

本発明により、余分な設備を追加すること無しに、ファイアウォールを具備するセキュリティ環境でも充分なメンテナンスを実現できる。また、ファイアウォールを具備する環境でも管理側から被管理側に一連の動作を指示することができる。更に、複数の動作指示を扱う際に適切な指示制御を行え、無駄な指示や被管理デバイスの無駄な負荷を抑制できる。

以下、添付図面を参照して、本発明の実施形態を詳細に説明する。

＜本実施形態のデバイス管理システムの構成例＞
図１は、本実施形態に係るデジタル複写機本体（以下、複写機という）と被管理装置（被管理デバイスとも称す）と管理サーバ（管理装置とも称す）とがインターネットを介して接続したデバイス管理システムの構成例を示す図である。

図１において、101は、複写機である。102は、複写機101の状態を監視し、管理サーバ106とInternet110を介して通信を行う被管理装置である。103は、一般のユーザが業務等で使用するパーソナルコンピュータ（PC）である。104は、複数のユーザがIntranet108からHTTPやHTTPSなどのプロトコルでInternet110に接続しにいくのを支えるProxy Serverである。105は、Intranet108のセキュリティを高めるために設置されたファイアウォールである。これらがLAN100を介して相互に接続されていることを表している。

一般的に社内Intranet上にあるユーザのクライアントPCは、Proxy Server及びファイアウォールを通じて、Internet上のWeb Pageを閲覧する。また、規模の小さなネットワークでは、Proxy Serverやファイアウォールではなく、ネットワークルータのNAT(Network Address Translation)やIP masqueradeを使用している。これにより小規模のネットワークでもIntranet内のネットワークから、任意のクライアントPCとInternetのWeb Serverの接続を行っている。上記セキュリティ環境を構築する理由に、Proxy Serverとファイアウォールの仕組みが、社内からのアクセスを許し、外部Internetに情報を送信する事を許容するからである。また、接続を行ったセッションを一定期間保持する事で、外部からのReplyのみを発信元のクライアントに返すことも理由に挙げられる。このようなセキュリティ環境では、Internetの環境からIntranet内のリソースにアクセスする事ができず、しかも、通信を途中で中継し、改ざんする事も難しくなっている。

又、106は、複写機の稼動状態を一元的に管理する管理サーバである。108は、複写機101と被管理装置102とがLAN100を介して相互に接続されたIntranetの環境を表している。実際には複数のIntranet環境108と管理サーバ106とがInternet110を介して相互に接続されている。

被管理装置102は、LAN100を介して自身の通信スケジュールに従って通信を行い、複写機101の主動作モード設定や、カウンタ値、稼働ログなどの稼働情報、及びハード障害やジャム多発等の障害情報を複写機101から取得する。又、複写機101に対して設定情報の更新やリブートなどのコマンド指示を行う。この際の通信手段としては、SNMP（Simple Network Management Protocol）を介したMIB（Management Information Base）のやり取り等がある。

被管理装置102は、特別なデバイスとして図面に記されている。しかし、被管理装置とは監視プログラムの走るデバイスを指している。従って、PC（パーソナルコンピュータ）上に監視プログラムがインストールされて被管理装置となるケースや、複写機自身に監視プログラムを内蔵して複写機が被管理装置の役割を果たすケースなどがあり、被管理装置の形態に制限はない。

被管理装置102は、複写機101の稼動情報と障害情報とを通信用データに加工し、Internet110を介して管理サーバ106に送信している。通信プロトコルは、HTTPやHTTPSなどのプロトコルを想定しているが、とくに限定するものではない。例えば、図１の例では、被管理装置102はHTTPSを利用してProxy Server104とファイアウォール105を介して、管理サーバ106にデータを送信している。
一般的なクライアントPCは、外部InternetのWeb Serverに接続するときに、すでに顧客のIntranet内でProxy Serverとファイアウォールを利用したセキュリティ環境が整っているケースが多い。従って、被管理装置に対しても同様のProxy Serverに係る通信設定を行う事で、顧客のセキュリティ環境を崩すことなくデバイスのステータス情報を管理サーバに送信する事ができる。なお、このセキュリティ環境は、必ずしもProxy Serverとファイアウォールがなくてはいけないわけではなく、小規模ネットワークのときにProxy Serverとファイアウォールの代わりとなる、ルーターのようなネットワーク機器でもよい。そして、上述の環境では、被管理装置は顧客ネットワークの内部から管理サーバにアクセスすることは可能であり、そのReplyを受信する事も可能だが、管理サーバ側から顧客ネットワーク内に設置されている被管理装置にアクセスする事は難しい。

管理サーバ106は、被管理装置102を制御するために、被管理装置用のコマンドを発行する。被管理装置102からは、定期的に（又はイベント的に）管理サーバ106へコマンドを取得しに来る（以下、コマンドリクエストと呼ぶ）。従って、管理サーバ106で発行したコマンドは、被管理装置102が取得しに来るまで管理サーバ106内に保管される。

コマンド取得の方法は、例えば、被管理装置内に保管してあるSSL証明書を利用して、管理サーバとHTTPSの通信を行う。このとき、特定のSSL証明書を利用し通信を開始することで、通信相手が管理対象の装置であることを管理サーバは認識する。又、被管理装置102には、それぞれ一意に識別するための識別ID（被管理装置IDと呼ぶこともある）が付与されている。HTTPS通信が確立した後に、SOAP等のプロトコルを使用して識別IDを管理サーバに送信することで、管理サーバはどの被管理装置から通信が行われたのか確認することができる。又、このレスポンスに、コマンドを付与することによって、インターネットを介する特定の被管理装置へのコントロールを可能にする。

（本実施形態の通信シーケンスの概略）
図２は、本実施形態に係る被管理装置102と管理サーバ106と管理者間の通信シーケンス例の一部を表した図である。尚、なお、ここでの管理者とは管理サーバ106に操作指示を行うメンテナンスオペレータのことを指し、以下では、単に管理者と呼ぶ。図２では、管理サーバ106から被管理装置102に、「設定情報リクエスト」と「リブートリクエスト」の指示を行なう例を示すが、これは通信シーケンスの概略の説明であってこれに限定されない。

シーケンスS401/S402は、管理者が管理サーバ106を介して、被管理装置102に対して指示するコマンドの入力を表している。シーケンスS401では被管理装置102の設定情報取得、シーケンスS402では被管理装置のリブートを指示している。ここでは、管理者からの連続した指示の入力を例として考えている。この指示結果の一例が図６に示される。

シーケンスS403で、管理サーバ106は管理者からリクエストされたコマンドに対応する。管理サーバ106は、ログイン時の管理者IDから、オペレーションしている管理者が対象としている被管理装置102（被管理装置ID）へのコマンド発行権限があるかを、データベースのアクセスコントロールをベースにして判定する。これは、データベースのアクセスコントロールを使用することに限定しない。アプリケーションプログラムでアクセスコントロールの仕組みが実装されていればよい。シーケンスS404では、管理サーバ106はS403の判定に従って、S401とS402の管理者からのリクエストを正規のリクエストとして、管理サーバ106のデータベース内に保管する。

シーケンスS405は、対象の被管理装置102から管理サーバ106へのコマンドリクエストを表している。このシーケンスS405における被管理装置102によるコマンドリクエスト送信際して、被管理装置102主体で通信セッションが張られる。また、被管理装置102主体の管理サーバ106へのアクセスによる通信セッションの確立により、管理サーバ106は被管理装置102側のファイアウォールを越えて被管理装置102に対して各種指示を行える。これは、被管理装置102から管理サーバ106への、被管理装置102に対するコマンドがないかの問い合わせコマンドである。シーケンスS406で、管理サーバ106はS405での被管理装置102からのコマンドリクエストに対する認証を行う。具体的には、コマンドリクエストとともに送られてくる被管理装置102の識別ID（以下、被管理装置IDと呼ぶ）を認識し、管理サーバ106内のデータベースから被管理装置IDを検索する。この検索結果に基づいて、管理サーバ106は、正規の被管理装置であることを確認した後、受信したデータの種類を確認する。S405で受信したデータはコマンドリクエスト(getOperationList)なので、管理サーバ106は、対象の被管理装置102に対して管理者からコマンドが指示されていないかデータベース内を検索する。シーケンスS407にて、管理サーバ106は対象の被管理装置102に対するコマンドをデータベースから取得する。

シーケンスS408で、管理サーバ106は、S405のコマンドリクエスト（getOperationList）のReplyとして、被管理装置102へコマンドを送信する。ここでのコマンドは被管理装置102への設定情報取得コマンドである。シーケンスS409は、管理サーバ106から被管理装置102へのReply通信を表す。この時のReplyの例が図５の通信サンプル１に相当する。シーケンスS410で、被管理装置102は管理サーバ106から受信したコマンドを実行する。コマンドは被管理装置102への設定情報取得コマンドなので、被管理装置102の設定情報を出力する。

シーケンスS411は、S410で実行したコマンドの結果（被管理装置102の保持する設定情報）を被管理装置102から管理サーバ106へ送信することを表している。シーケンスS412にて、管理サーバ106は被管理装置102の設定情報を受信する。通信にてデータを受信したときには、S406と同様に被管理装置IDによって認証し、コマンド及びデータを解釈する。このときのコマンドは設定情報送信（postConfiguration）であり、データ部は被管理装置102の保持する設定情報である。本例では、管理サーバ106は、コマンドの結果をデータベースに格納した後に、被管理装置102に対して２つめのコマンド（リブート指示）があることを認識する。

この場合、管理サーバ106は、シーケンスS413にて、被管理装置102にコマンドリクエスト(getOperationList)を行うように指示を発行する。シーケンスS414にて、管理サーバ106から被管理装置102に、前回のコマンドが受信成功したと伝えるとともに、コマンドリクエスト(getOperationList)を次に行うよう指示をする。このときのReplyの例が図５の通信サンプル2に相当する。シーケンスS415で、被管理装置102はS414のリクエストより、管理サーバ106に対してコマンドリクエスト(getOperationList)を送信する。

シーケンスS416で、管理サーバ106は、残りのコマンドであるリブートコマンドをデータベースから取得する。シーケンスS417で、管理サーバ106はコマンドリクエスト（getOperationList）のReplyとしてのリブートコマンドを通信用に生成する。

シーケンスS418で、管理サーバ106は次のコマンドであるリブートコマンドを被管理装置102へ送信する。このときのReplyの例は図５の通信サンプル１に相当する。シーケンスS419で、リブートコマンドを管理サーバ106から受信した被管理装置102はリブートを実行する。被管理装置102は、シーケンスS420で、リブートが完了したことを管理サーバ106に通信する。シーケンスS421で、管理サーバ106は、被管理装置102にS420の通信を問題なく受信したことを伝え、次に送信するコマンドがないので、次のコマンドをリクエストせずにReplyのみを返す。そして、管理サーバ106が主体となり維持されていたセッションを切断する。また、維持されたセッションは管理サーバ106が主体とならなくとも、一定時間経過するとタイムアウトで切断される。

以上のように、本実施形態では、被管理装置102から管理サーバ106へのコマンドリクエスト(getOperationList)があると、それをトリガとして管理サーバ106に保持されている管理者からの指示を順次に最後まで実行する。これは、管理サーバ106から被管理装置102に、管理者からの指示の実行が全て終わるまでコマンドリクエスト(getOperationList)を要求することで実現する。

また、図２の通信シーケンス例では、S413乃至S415の処理により、管理サーバ106から被管理装置102に対して、更なるコマンドを指示するよう説明してきたが、この形態に必ずしも限定されない。例えば、S411の被管理装置102からの応答に応じて、更なるコマンドをS418の転送するようにしても良い。また、後述の図１３でも同様とする。このように、被管理装置102からの指示に対する応答（S411）に応じて、確立されたセッションを維持しつつ、更なる指示を行えるので、被管理装置102に対し高度、且つ、確実な指示を、ファイアウォール越えで行える。

また、上の図２のシーケンスでは、管理サーバが被管理装置にコマンドを指示した後には、必ず、被管理装置はコマンドの実行結果を管理サーバに通知する処理を行う。このコマンド実行結果を受けた管理サーバは、さらに実行させたいコマンドがある場合に、このコマンド実行結果のＲｅｐｌｙに、次のコマンドが用意されている事を表す情報を出力する事で、被管理装置に、再度コマンドリクエスト通信を行うよう指示する事ができる。一方、被管理装置に複数のコマンを処理させるために、管理サーバが被管理装置に複数のコマンドを一度に送信する方法も想定される。ここで、１回のコマンドを複数回繰り返して、複数のコマンドを処理する方法と、１度に複数のコマンドセットを送信する方法と比較すると、１回のコマンドを複数回繰り返して複数のコマンドを処理する方法には、次の効果がある。管理サーバが発行したコマンド処理の結果を１コマンドに対して、１回ずつ受信するので確認が容易である。また、1回のコマンドの結果を受信・確認してから、次の送信すべきコマンドを決定する事ができるので、コマンドの柔軟性が高くなる。また、順次コマンドを実行させ結果複数の一連のコマンドを実行させる方式によれば、コマンドを受ける被管理装置に、複数処理を一度に処理するのに必要な規模のハードウェアリソースを必要としない。

＜本実施形態の管理サーバの構成例＞
（管理サーバのハードウェア構成例）
図３Ａは、図１における管理サーバ106のハードウェア構成例を示すブロック図である。

管理サーバ106は汎用のコンピュータ等で構成されてよい。全体を制御するためのCPU202と、システム起動に必要なブートプログラムを記憶するための読み出し専用メモリであるROM203と、CPU202でプログラムを実行する際に必要とされる作業メモリであるRAM204とを含む。又、Network上で通信を行うためのNetwork I/F205と、表示デバイス209に被管理装置との通信内容等を表示するための表示制御部206とを含む。更に、管理サーバ106を管理するオペレータからの入力デバイス210や211、入力を受け付ける入力制御部207と、CPU202で実行するプログラムや被管理装置から送られた各複写機の稼働情報などを格納する磁気ディスク等の記憶装置208を含む。

管理サーバ106は、被管理装置102からの定期的な稼働情報通知や不定期的な異常状態の通知、コマンドリクエストをNetwork I/F205を介して常時受けている。又、管理者から被管理装置102への設定変更や動作要求などのコマンド入力は、入力制御部207を介して常時受け付けている。

定期的に通知される稼働情報には、各種カウンタ値や稼働ログなどが含まれており、管理サーバ106は稼動情報を基に複写機101を所有している顧客に対して毎月請求する定期メンテナンス料を算出する。又、複写機101に使用されているパーツが推奨寿命に対してどのくらい消耗しているのかをレポートの形で出力する。管理サーバ106はこの稼働情報を記憶装置208に逐次格納する。一方、オペレータは格納された稼働情報を適宜参照して顧客への請求額を決定する。

不定期的に通知される複写機101の異常状態を表す情報には、稼働情報に加えて、発生したハード障害やジャムなどのエラー／アラーム情報が含まれている。管理サーバ106はこの情報を受け取ると、情報の緊急度に基づいて処理を決定する。受け取った情報が、複写機の故障など、複写機101が異常状態を表すものであり、すぐに復旧させる必要のある障害情報だった場合には、その対象の複写機101を管理しているオペレータに電子メールを送信する。さらに記憶装置208に逐次格納すると共にディスプレイ209上に表示することで、複写機101が異常状態に陥っている旨をオペレータに通知する。一方、受け取った情報がジャムやアラームのように緊急度が低い場合には、記憶装置208に逐次格納し、電子メールの送信が必要かどうか、ディスプレイ209に表示させる必要があるかどうかを判断する。

オペレータは、ディスプレイ209上の表示内容から複写機101の状態を判断し、必要に応じて障害復旧作業をサービスマンに指示をする。又、トナーなどの消耗品を顧客に送付する。

被管理装置102からのコマンドリクエストは、任意のタイミングで常時受け付ける。管理サーバ106はコマンドリクエストを受ける都度、管理サーバ106内の記憶装置208を確認し、管理者から被管理装置102へのコマンドが設定されていたら、被管理装置102へコマンドを送信する。

（管理サーバのソフトウェア構成例）
図３Ｂは、管理サーバ106における、被管理装置102へのコマンド発行を行うアプリケーションプログラムの機能を示すブロック図である。

アプリケーションプログラムは、管理者からの入力を受け付けるコマンド入力部305を有する。又、コマンド入力部305で受け付けた被管理装置への設定変更コマンドを記憶するための設定変更記憶部302と、被管理装置への設定変更コマンドを設定変更記憶部302に入出力するための設定変更情報入出力部304とを有する。又、被管理装置の現在の設定を記憶するための設定記憶部301と、被管理装置の設定情報を設定記憶部301に入出力するための設定情報入出力部303とを有する。

又、被管理装置との通信を行う通信I/F部306と、被管理装置から受信したデータから識別IDや通信コマンドをデータとして取り出す、又は、被管理装置へ送信するデータを通信用フォーマットへ成型する通信コマンド解釈部309とを有する。又、管理者のリクエストによって設定を変更するための情報と、被管理装置のもともとの設定を比較し、適切なコマンドを発行する設定比較/コマンド発行部307を有する。更に、発行されたコマンドの数と、実行指示したコマンドの数、コマンドの結果など、被管理装置に対するコマンドの制御を行うコマンド制御部310と、被管理装置へのコマンドの結果を記憶するコマンド結果記憶部311を含む。

更に、以下の好適な例では、コマンド入力部305にて管理者から入力されたコマンドを一時的に設定変更記憶部302に保管する。そして、被管理装置からコマンドリクエストを受信したときに、設定変更情報比較/コマンド発行部307にて設定を比較する、又は、コマンド自体を検証して影響しあうコマンドを適切化する。このように、管理者から入力されたコマンドをそのまま被管理装置へ送信するのではなく、適切な形に生成することで余計なオペレーションを排除し、システム障害になる原因を抑制している。

（管理サーバの記憶構成例）
図４Ａは、図３ＡのＲＯＭ203又は記憶装置208に不揮発的に記憶されるプログラム及びデータの構成例を示す図である。尚、図４Ａには、本実施形態に関連深いプログラム及びデータのみを示し、他は省略している。

４０１はＯＳ等の装置の基礎的な制御を行なうシステムプログラムである。４０２は本管理サーバのデバイス管理全体を制御するデバイス管理プログラムである。かかるデバイス管理プログラム４０２の本実施形態に関連する部分は、以下に図９，図１１，図１４を参照して説明される。４０３は管理者からの指示入力あるいはデバイス状態の表示出力などを制御するユーザインタフェース・プログラムである。ユーザインタフェース・プログラム４０３は、管理者からの入力コマンドを解析して被管理装置に送るコマンドを生成するユーザ入力コマンド解析機能を含んでいる。４０４は指示を入力するユーザ又はコマンドリクエストを送信する被管理装置を認証するための、ユーザ／管理デバイス／認証プログラムである。

４０５は、被管理装置との間でInternet110を介してコマンドを含むメッセージ送受信を制御するメッセージ送受信プログラムである。４０６は、被管理装置から受信したメッセージに含まれるコマンドを解析して、それに対応する処理の実行を指示する受信コマンド解析プログラムである。４０７は、受信コマンド解析プログラム４０６の解析結果に対応して実行される各処理プログラムである。例えば、コマンドリクエストと解析すればリクエスト送信処理４０７ａを実行し、設定情報受信と解析すれば設定情報受信処理４０７ｂを実行し、デバイスのステータス受信と解析すればステータス受信処理４０７ｃを実行する。ここには、本実施形態に関連する受信コマンドを示したが。これに限定されない。

４０８は、管理サーバ106の処理に関連するコマンドを記憶するコマンドテーブルである。コマンドテーブル４０８は、本実施形態では管理者の入力する指示に対応する入力コマンド４０８ａ、被管理装置に送信する送信コマンド４０８ｂ、被管理装置から受信する受信コマンド４０８ｃが含まれる。これらのコマンドで、例えば入力コマンド４０８ａと送信コマンド４０８ｂとはそれぞれ関連付けられているのが好ましい。入力コマンド４０８ａの例は以下の図６に、送信コマンド４０８ｂの例は以下の図７に、受信コマンド４０８ｃの例は図２に示されている。

４０９は、被管理装置の設定情報を保持する被管理装置設定情報データベース（ＤＢ）であり、図８にその一例が示されている。４１０は、管理サーバ106が管理している被管理装置を記憶する被管理装置データベース（ＤＢ）である。例えば、被管理装置ＤＢ４０１には、被管理装置認証にも使用される装置１のＩＤ４１１、ユーザ認証に使用されるアクセス可のユーザＩＤ４１１ａが記憶される。又、管理者から指示入力されたコマンドの保管数（Ｎ1）４１１ｂ、管理者から指示入力された各コマンドに対応する送信コマンド１１...（４１１ｃ）が記憶される。装置２については、装置ＩＤ４１２、ユーザＩＤ４１２ａ、保管コマンド数（Ｎ2）４１２ｂ、コマンド２１...（４１２ｃ）が記憶される。

図４Ｂは、図３ＡのＲＡＭ204に一時記憶されるデータの構成例を示す図である。尚、図４Ｂにも、本実施形態に関連深いプログラム及びデータのみを示し、他は省略している。

４５１は、管理者が入力したユーザＩＤの記憶領域である。４５２は、被管理装置から送信された入力装置ＩＤである。４５３は、管理者が指示入力したユーザリクエストコマンドである。４５４は、管理者が入力制御部207を介して入力する各種データである。４５５は、表示制御部206を介して表示される各種データである。４５６は、連続して送信されるコマンドの数をカウントするカウンタＣＮＴである。４５７は、それぞれの被管理装置に対応して保管されているコマンド数（Ｎi）である。

４５８は、被管理装置から送信された被管理装置リクエストコマンドである。４５９は被管理装置からの受信メッセージ、４６０は被管理装置への送信メッセージである。４６１は、ユーザコマンドにより変更された被管理装置の設定情報であり、例えば図１０にその一例が示されている。４６２は、被管理装置にリクエストして受信した被管理装置の設定情報である。４６３は、以下の好適な例で使用される上記ユーザコマンドによる被管理装置設定情報４６１とリクエスト／受信した被管理装置設定情報４６２との差分情報である。４６２は、かかる差分情報４６３に基づいて、送信コマンドを削減した更新コマンドである。

４６５は、図４Ａに示したプログラムをＣＰＵ202が実行するためロードする記憶領域である。

（管理サーバからの通信データの構成例）
図５は、管理サーバから被管理装置へ送信されるコマンド及びデータを模式的に表した図である。かかる情報は、図４Ｂの送信メッセージ４６０として生成される。

図５で、801は、管理サーバが被管理装置から受信したコマンドリクエストに対応したReplyの情報を表している。さらに801は、管理サーバから被管理装置へのReplyであることを示すとともに、受信した情報の通信結果や、管理サーバから被管理装置へ指示を行うコマンドが出力される。コマンドとは、図２の設定情報リクエストS409やリブートリクエストS418などが相当する。

802には、管理サーバが被管理装置から受信したコマンドリクエストの通信が成功したか、失敗したかを示すコードが出力される。803には、管理サーバが被管理装置から受信した情報を処理した日時が出力され、処理が失敗した場合には、804に、受信失敗時の詳細説明が出力される。805には、管理サーバが被管理装置に対して送信するコマンド情報が入る。これは、管理サーバが対象となる被管理装置に指示するべきコマンドがある場合に出力される。806には、805のコマンドを補完する情報が出力される。例えば、このサンプルでは、被管理装置に監視デバイスの追加を指示し、管理対象デバイスは、Device Eとしている。実際には、806のデータには、IP Addressや、識別IDなど被管理装置がデバイスを管理するための情報が出力される。

807は、管理サーバが被管理装置に対して、再度コマンド指示を行う必要があるときに被管理装置に対して送信する情報である。管理サーバは被管理装置に対して送信した前回のコマンドの結果を受信し、次のコマンドを被管理装置に対して通信のReplyとして送信する。このReplyの情報は、図２の受信成功／コマンド取得ロクエストS414に相当する。この808には、管理サーバが、再度、被管理装置に対してコマンドリクエストを行うように指示するコマンドが出力される。

（管理サーバへの入力コマンドの例）
図６は、管理者が、管理サーバを介して被管理装置に対して複数のコマンドを入力した例を示す図である。図６には、以下の好適な例を説明するために、図２で示した設定情報リクエストやリブーツリクエストでなく、デバイス設定情報の変更コマンドが示されている。

図６で、1101は、被管理装置の管理するDevice Aの属性情報である、設置場所に関して変更をリクエストしている。1102では、被管理装置に対して、新規デバイスであるDevice Dを監視対象とするようリクエストしている。1103は、先ほど入力したDevice Aに対する設置場所情報に間違いがあり、訂正するコマンドである。ここでは、Device Aの属性情報である、設置場所をさらに更新している。1104では、被管理装置に対して、新規デバイスであるDevice Dを監視対象とするようにリクエストしている。1105では、1102で登録したDevice Dをキャンセルし、監視対象としてDevice Dを削除するようにリクエストをかけている。

管理者は被管理装置にリクエストを発行しても、被管理装置からコマンドの要求がなければ、管理サーバは要求を被管理装置に送信することはできない。従って、管理サーバに入力されたリクエストが、リアルタイムに処理されないと、管理サーバ内にコマンドが溜まる。以下の好適な例では、この５つのコマンドを削減する例を示す。

（管理サーバから被管理装置へのコマンドの例）
図７は、管理サーバ106が、被管理装置102に対して送信するコマンドの例である。この図７に示されるコマンドが、上に説明した図５のコマンド情報８０５に設定される。

管理サーバは、上記管理者からの入力コマンドに対応する送信コマンドを各被管理装置に対応付けて保管する。その場合に、上記図６の入力コマンドであれば、デバイス単位に別個の被管理装置に振り分けられるか、複数のデバイスを管理する被管理装置にはその複数のデバイスに指示が振り分けられる。そして、管理サーバは、これらのコマンドを使用して、各被管理装置をコントロールする。かかるコマンドは例として紹介したものであり、この限りではない。

1001は、被管理装置に対して、新規に新しいデバイスを管理するように依頼をする監視デバイスの追加要求である。1002は、被管理装置の現在管理しているデバイスで、デバイスの属性情報を更新するときに使用する監視デバイスの属性変更要求である。1003は被管理装置で登録されている監視デバイスを削除するときに使用する、監視デバイスの削除要求である。1004は、被管理装置に設定した定期通信のためのスケジュール情報を変更するときに使用する通信スケジュール変更要求である。その他の内容は図７の通りであるので説明は省略する。

（被管理装置設定情報の構成例）
図８は、管理サーバ106の被管理装置設定情報ＤＢ４０９に保持された設定情報の一例である。図８は被管理装置ID毎に保持される設定情報である。1201は対象の被管理装置に関する設定情報であり、図８では３台の監視対象デバイスを管理している。以下では、管理サーバ106が、管理者の指示に応じた複数のコマンドを入力した時、入力されたコマンドを適切化し、適切化されたコマンドを被管理装置102へ送信する動作例を表す。この動作例では、図８で示している構成例に、図６で示している複数コマンドを管理者が管理サーバに入力した時に、管理サーバはコマンドを適切化し、図１２で示されるコマンドに適切化し、適切化されたコマンドを被管理装置へ送信する流れになっている。

尚、被管理装置102が有する後述の設定情報ＤＢ１６０７にも同様の設定情報が保管されている。複数の被管理装置がそれぞれ１台のデバイスを管理していれば、図８は３台の被管理装置から収集された設定情報である。一方、１つの被管理装置が複数のデバイスを管理している場合もある。

1202はデバイスＡの設定情報、1203はデバイスＡの製品名、1204はデバイスＡのＩＰアドレス、1205はデバイスＡの配置場所（川崎ビル３階）、1206は管理者名である。

以下、デバイスＢについては1207〜1211に、デバイスＣについては1212から1216に設定されている。このデバイスＢとＣは同じ建物（東京ビル）内にあるので、１つの被管理装置で管理する構成も考えられる。

＜本実施形態の管理サーバの動作例１＞
上記構成に基づいて、本実施形態の管理サーバの動作例１を説明する。尚、以下の動作例１乃至３では、処理を単純化するために図６の入力コマンドに対するデバイスは同じ被管理装置で管理されているものとして説明する。しかし、実際には、複数の被管理装置がデバイスを管理しており、その場合には各被管理装置に対しては独立の処理となるが、そのための処理手順は明らかである。

本動作例１では、特に管理者からコマンド入力があり、図６のように５つのコマンドが保持された場合に、順次そのコマンドを実行する例を示す。

（動作例１の動作手順例）
図９は、管理サーバが、管理者のリクエストを受け、被管理装置にコマンドを送信する処理を表すフローチャートである。このフローチャートで表す動作例は、管理者から複数のリクエストを受けたときに、複数のコマンドがすべて処理されるように、管理サーバが被管理装置へリクエストすることを特徴とする。すなわち、管理サーバがリクエストを被管理装置へ送信する際に、複数のコマンドの１つ１つのコマンドの結果を確認できるように、コマンドの数だけ被管理装置のコマンドリクエストを被管理装置へ送信する。

ステップS501では、管理サーバの内部処理であるループの開始を表している。ステップS502では、管理サーバは、ユーザインタフェースを通じて管理者からのリクエストを受信する。ここでは、管理者からの他のリクエストの発生、あるいはリクエストが発生しない可能性もあるので、管理サーバとしては、管理者からのリクエストの判断をする。ステップS502で、管理者からの設定変更のリクエストを受けた場合に、ステップS503で、設定変更のリクエストをデータベースに保管する。このデータベースとは、図４で説明した被管理装置DB410に相当する。ステップS502で設定変更のリクエストでない場合は、ステップS502aで、他のリクエスト（例えば、前述の設定情報リクエストやリブートリクエスト等）で有るかを判断し、ステップS503aで、他のリクエストをデータベースに保管する。ここでは、管理者からの連続した指示の入力を想定しており、ステップS501からステップS503の入力結果の一例が図６である。被管理装置へのリクエストで無ければステップS504に進む。

ステップS504でループが終了するが、ループの終了条件は、被管理装置からのコマンドリクエストの有無を判定し、有りと判定しコマンドリクエストを受信した場合に、ループ処理の終了となる。また、S504で被管理装置からコマンドリクエストを受信した場合には、S405と同様にセッションが確立される。従って、被管理装置からコマンドリクエストを受信しない間の管理者からの入力コマンドは、順次図６のように蓄積される。被管理装置からコマンドリクエストを受信した場合に、ステップS505で、通信によって受信した被管理装置IDをデータベースで検索し、被管理装置の認証を行う。ステップS506で、対象被管理装置へのコマンドがデータベースに保管されているかを検索する。ステップS507では、被管理装置への設定変更のコマンドがあるかの判断を行う。ここの判断で、被管理装置への設定変更のコマンドがなかった場合には、ステップS509にて、被管理装置に対して、空のリクエストを送信して、処理を終了する。ステップS507で、1個以上（N個)のリクエストが合った場合には、ステップS507aで、他のリクエストがあるかを判断し、ステップS507aで対応するリクエスト処理を行なう。

被管理装置への設定変更のコマンドがあれば、ステップS508で、カウンタCNTをリセットしてCNT = 1をセットする。ステップS510にて、カウンタCNTの値が、コマンドの数Ｎ未満だった場合に、ステップS511で、被管理装置に対して、CNT番目のコマンドを送信する。ステップS512にて、ステップS511で被管理装置に送信したCNT番目のコマンドの結果を受信する。そして、ステップS519で、管理サーバ106は、S512で受信した実行結果から、次のコマンド送信を行うための準備を行うか、その他の処理を行うかを決定する。ここでは、コマンド結果が成功していた場合に、次のコマンド送信を準備するためにステップS513へ進む。また、被管理装置へ送信した前回コマンドが失敗していた場合には、再度、同じコマンドを送信するようにステップS511へ進む。このS519の判定処理により、より確実に被管理装置に対して一連のコマンドを指示することができる。ステップS513にて、次のコマンドのために、被管理装置へコマンドリクエストの要求を送信する。ステップS514にて、ステップS513の指示結果として、被管理装置からコマンドリクエストを受信する。この被管理装置からのコマンドリクエストは、getOperationListのメソッドに相当する。ステップS515にて、カウンタCNTの値を１つインクリメントする。

ステップS510にて、カウンタCNTの値がコマンドの数Ｎに達した場合は、ステップS516にて、被管理装置へCNT（Ｎ）番目のコマンドを送信する。ステップS517にて、ステップS516で、被管理装置に送信したコマンドの結果を受信する。ステップS518にて、ステップS517での通信成功の結果を被管理装置へ送信する。そして、管理サーバ106が主体となり、又は、タイムアウトにより、維持されていたセッションが切断される。

なお、図9の通信シーケンス例では、S513及びS514の処理により、管理サーバ106から被管理装置102に対して、更なるコマンドを指示するよう説明してきたが、この形態に必ずしも限定されない。例えば、S519の被管理装置102からの応答に応じて、更なるコマンドを送信すべく、S510に処理を移行するようにしても良い。また、後述の図11、14でも同様とする。このように、被管理装置102からの指示に対する応答（S512）に応じて（S519）、確立されたセッションを維持しつつ、更なる指示を行えるので、被管理装置102に対し高度、且つ、確実な指示を、ファイアウォール越えで行える。

（図６の入力コマンドの実行結果）
図１０は、図６の５つの入力コマンドを実行した結果の設定情報を示す図である。

図１０の1217から1232は、図８の1201から1216に対応する。但し、図６の入力コマンドの1101及び1103でデバイスＡの配置場所が変更されているので、1221に示すように、配置位置は川崎ビル３階→川崎ビル４階→川崎ビル２階と変更されている。

又、破線で示すデバイスＤの設定情報1233は、一旦作成されるが図６のデバイス削除1105に従い削除されるので、実際には残っていない。デバイスＥの設定情報1238〜1242は図６の追加コマンド1104に従って追加されたデバイスである。

この図１０は、図４Ｂのリクエスト状態を保管する被管理装置の設定情報461にも対応する。図６で示されたコマンドを図８の設定情報1201に反映すると、図１０のようになる。管理者からコマンドを受け付けるのと同時に、設定情報を更新していくと、上書きされても監視対象デバイスが削除されても、図１０のような変更設定情報1217だけに反映される。変更設定情報1217の右端にあるチェックボックスはフラグを表しており、設定変更のあった場所に関してフラグを設定しておけば、以下の動作例２における差分の情報を算出するときに、効率よく差分を抜き出せる。しかし、差分を抜き出すためにフラグ情報は必須の情報ではない。

＜本実施形態の管理サーバの動作例２＞
上記構成に基づいて、本実施形態の管理サーバの動作例２を説明する。本動作例は以下のような特徴を有する。

図６のように溜まったコマンドに、それぞれキャンセルをかけるようなコマンドや、上書きを指示するようなコマンドが存在した場合がある。その場合に、そのまま管理サーバが被管理装置にコマンドを渡した場合に、通信上のトラフィックや無駄なコマンド処理等で、非効率が生じるとともに、障害の原因になる可能性がある。ここで、管理サーバ内での振舞いとして、２種類の設定情報を管理する。１つは対象の被管理装置に関する設定情報（図８参照）である。もう１つは1217で表されている設定情報で、リクエスト状態を保管する被管理装置の設定情報（図１０参照）である。すなわち、管理者からコマンドを受け付けるのと同時に設定情報を更新していくと、上書きされても監視対象デバイスが削除されても、変更設定情報だけが反映される。

管理サーバが、被管理装置からコマンドリクエストを受信したときに、管理サーバは、図８の設定情報1202と、図１０の設定情報1217との差分情報から、ユーザリクエストに基づくコマンドを発行する。この差分から管理サーバの生成するコマンドは、図１２に示す表のように２つのコマンドになる。コマンド1301は最後にアップデートの発生した、Device Aの属性情報である設置場所の更新であり、コマンド1302は被管理装置に新規に監視デバイスＥを登録するコマンドである。本動作例２では、被管理装置からコマンドリクエストを受けた管理サーバは、この２つのコマンドを生成して、順々に被管理装置へ送信する。

（動作例２の動作手順例）
図１１は、管理サーバが、管理者のリクエストを受け、被管理装置にコマンドを送信する処理を表すフローチャートである。このフローチャートで表す動作例２は、管理者から複数のリクエストを受けたときに、管理サーバの管理する設定情報461に反映させ、コマンド自体はデータベースに保管しない。被管理装置からコマンドリクエストを受け付けた時に、被管理装置に設定情報をリクエストし、管理サーバの保管している設定情報461と、被管理装置から受信した設定情報462を比較し、その差分463から管理装置が被管理装置に発行すべきコマンドを作成することを特徴とする。この図１１のフローチャートに示される処理により、結果、図１２に示される適切化された変更後のコマンドが生成される。

ステップS601では、管理サーバの内部処理であるループの開始を表している。ステップS602では、管理サーバは、ユーザインタフェースを通じて管理者からのリクエストを受信する。ここでは、管理者からの他のリクエスト、あるいはリクエストが発生しない可能性もあるので、管理サーバとしては、管理者からのリクエストの判断をする。ステップS602で、管理者からの設定変更のリクエストを受けた場合には、処理はステップS603へ進み、リクエストコマンドがはじめて行われたのか、過去に同じリクエストを受けているのかを示す変更フラグを確認する判断処理を行う。ステップS603の変更フラグ確認の判断処理で変更フラグがセットされていなかった場合には、ステップS605へ進む。そして、リクエストに対する変更フラグをセットし、管理サーバで管理をしている対象の被管理装置の設定情報を、リクエストの通りに反映してデータベースへ保管する。

又、ステップS603の変更フラグを確認する処理にて、すでに変更フラグがセットされていた場合には、ステップS604へ進む。ステップS604では、管理サーバの管理する対象被管理装置の設定情報をリクエスト通りに反映し、再びデータベースに保管する。

一方、ステップS602で、管理者からの他のリクエスト（設定情報リクエストやレブートリクエスト等）を受けた場合には、処理はステップS602aからS604aへ進む。ステップS604aでは管理サーバのＤＢにリクエストを保存する。

次に、ステップS606へ行くが、ステップS602で、管理者からリクエストを受けなかった場合にも、ステップS602aからこのステップS606へいく。ステップS606では、ループが終了するが、ループの終了条件は、被管理装置からコマンドリクエストを受信した場合に、ループ処理の終了となる。また、S606で被管理装置からコマンドリクエストを受信した場合には、S405と同様にセッションが確立される。

ステップS607では、被管理装置からの識別IDから認証処理を行う。ステップS608にて、データベース内に変更フラグがセットされているか確認する。ステップS609にて、変更フラグがセットされているかの判断処理を行う。ステップS609の判断処理で、変更フラグがセットされていなかった場合には、ステップS609aで他のリクエストが有るかを判断する。有ればステップS609bに進んで他のリクエストを処理する。他のリクエストが無い、あるいは他のリクエストの処理が終了すると、ステップS610へ処理は進み、被管理装置に空のコマンドリクエストを送信して、処理を終了する。

ステップS609にて、変更フラグがセットされていた場合には、ステップS611の処理に進み、被管理装置へ現在の設定情報のリクエストを行い、被管理装置の設定情報の受信まで行う。ステップS612にて、被管理装置から受信した現在の設定情報462（本例では図８に対応）と、管理サーバの管理する管理者のリクエストを反映した設定情報461（本例では図１０に対応）とを比較する。ステップS613にて、設定情報の比較に関する結果（差分）463を判断する。ステップS613にて、それぞれの設定情報に差がなかった場合には、ステップS610に処理を進め、終了する。ステップS613にて、設定情報に差分が存在した場合には、ステップS614へ処理を進める。

ステップS614では、設定情報の比較によって、出力される差分より、管理サーバは被管理装置に対するＭ個の設定コマンドを発行する。本例では、図１０より明らかなように、設定情報の変更はデバイスＡの配置場所1221の変更とデバイスＥ1238〜1242の追加である。従って、図１２に示す２つの設定コマンドが発行される（Ｍ＝２）。ステップS615では、カウンタCNTをリセットし、CNT = 1をセットする。ステップS616にて、カウンタCNTの値が、コマンドの数Ｍ未満だった場合に、ステップS617で、被管理装置に対して、CNT番目のコマンドを送信する。ステップS618にて、ステップS617で被管理装置に送信したコマンドの結果を受信する。ステップS619にて、次のコマンドのために、被管理装置へコマンドリクエストを送信する。ステップS620にて、ステップS619の指示結果をして、被管理装置からコマンドリクエストを受信する。ステップS621にて、カウンタCNTの値を１つインクリメントする。ステップS622では、被管理装置へCNT（Ｍ）番目のコマンドを送信する。ステップS623にて、ステップS622で、被管理装置に送信したコマンドの結果を受信する。ステップS624にて、ステップS623での通信結果を被管理装置へ送信する。そして、管理サーバ106が主体となり、又は、タイムアウトにより、維持されていたセッションが切断される。

（動作例２で作成され送信されるコマンド例）
図１２は、動作例２の図１１のフロー処理により作成され送信されるコマンド例を示す図である。

図１２では、図６の５つの入力コマンドが重複や削除などの結果を削除した２つのコマンドとなる。コマンド1301は最後にアップデートの発生した、Device Aの属性情報である設置場所の更新であり、コマンド1302は被管理装置に新規に監視デバイスＥを登録するコマンドである。

尚、図１２のコマンド1301, 1302は、以下の動作例３においても残されて実行されるコマンドである。

（動作例２の動作シーケンス例）
図１３は、本動作例２に係る被管理装置102と、管理サーバ106と管理者間の通信シーケンスの一部を詳細に表した図である。ここでは、管理者から入力された複数のコマンドを、被管理装置の設定情報の差分情報として蓄積を行う。そして、被管理装置からコマンドリクエストを受信した場合に、設定の差分情報から適切化されたコマンドを新規に作成し、作成した複数のコマンドを被管理装置に対して送信する。具体的には、管理サーバ内で被管理装置の設定情報を2つ管理する。ひとつは、その時点で動いている被管理装置の設定情報と、もう一つは管理者からのコマンドを反映させた新しい設定情報である。新規指示が管理者から入力されていく都度、コマンドを反映させた設定情報を更新していき、被管理装置からコマンドリクエストを受信したときに、２つの設定情報の差分から管理サーバがコマンドを自動的に発行する。そして、この発行した複数のコマンドを被管理装置へ送信する。

シーケンスS901/902/903/904/905は、それぞれ違う意味を持ったコマンドを管理者が管理サーバを介して入力することを表している。シーケンスS906で、管理サーバはログイン時のユーザIDから、オペレーションをしている管理者が対象としている被管理装置（被管理装置ID）へのコマンド発行権限があるかを、データベースのアクセスコントロールをベースに判定する。シーケンスS907では、S906の判定に従って、管理者の指示したコマンドを、管理サーバで管理している設定情報へ直接反映を行う。このとき、オリジナルの被管理装置の設定情報と、変更を行った被管理装置の設定情報と２つのバージョンの設定情報を管理する。これは、コマンドを発行する際に、２つのバージョンの設定情報から差分を抽出するためである。しかし、２つのバージョンの設定情報を管理するのは、実施する例を示しただけであり、実際には、管理せずに被管理装置から現在の設定を受信しても可能であり、設定情報がどこで管理されているかは、ここでは、特定しない。

シーケンスS908は、対象の被管理装置からのコマンドリクエストを表している。これは、被管理装置に対するコマンドがないかの問い合わせコマンドである。このシーケンスS908における被管理装置102によるコマンドリクエスト送信際して、被管理装置102主体で通信セッションが張られる。また、被管理装置102主体の管理サーバ106へのアクセスによる通信セッションの確立により、管理サーバ106は被管理装置102側のファイアウォールを越えて被管理装置102に対して各種指示を行える。シーケンスS909で、管理サーバはS908の被管理装置からのコマンドリクエストに対する返事の準備を行う。具体的には、コマンドリクエストとともに送られてくる被管理装置IDを認識し、管理サーバ内データベースから被管理装置IDを検索する。この検索結果に基づいて、正規の被管理装置であることが確認した後、受信したデータの種類を確認する。S908の通信で、被管理装置から受信したコマンドがコマンドリクエスト(getOperationList)なので、シーケンスS910では、対象の被管理装置に対して、設定情報に更新情報がないかを確認する。シーケンスS911で、更新情報があれば、オリジナルの設定情報と、更新のあった設定情報を比較し、その差分から適切なコマンドを発行する。シーケンスS912で、S908のコマンドリクエスト（getOperationList）のReplyとして、被管理装置へコマンドを送信する。ここでの、コマンドは被管理装置の設定情報取得コマンドである。

シーケンスS913は、管理サーバから、被管理装置へのReply通信を表す。シーケンスS914で、被管理装置は、受信したコマンドを実行する。シーケンスS915は、S914で出力したコマンドの結果を管理サーバへ送信することを表している。シーケンスS916にて、管理サーバは再度、認証を行ない、コマンドを確認する。コマンドには、前回のコマンドの結果が出力されている。まだ、被管理装置へのコマンドが残っている場合には、被管理装置にコマンドリクエスト(getOperationList)を行うように指示を発行する。

シーケンスS917にて、前回のコマンドが受信成功したと、伝えるとともに、コマンドリクエスト(getOperationList)を次に行うよう指示をする。シーケンスS918で、被管理装置はS917のリクエストより、管理サーバに対して、コマンドリクエスト(getOperationList)を送信する。シーケンスS919で、被管理装置は、残りのコマンドを被管理装置へ送信する準備を行う。

シーケンスS920で、管理サーバはコマンドリクエスト（getOperationList）のReplyとしてコマンドを被管理装置へ送信する。シーケンスS921で、コマンドを受信した被管理装置はコマンドを実行する。シーケンスS922で、コマンドが完了したことを管理サーバに通信する。シーケンスS923で、管理サーバは922の通信が問題なく受信したとこを伝え、次に送信するコマンドもないので、次のコマンドをリクエストせず、Replyを返す。そして、管理サーバ106が主体となり、又は、タイムアウトにより、維持されていたセッションが切断される。

＜本実施形態の管理サーバの動作例３＞
上記構成に基づいて、本実施形態の管理サーバの動作例３を説明する。

（動作例３の動作手順例）
図１４は、管理サーバが被管理装置に送信するコマンドの適切化を行ううえで、他の実施の形態を表したフローチャートである。このフローチャートで表す動作例３は、管理者から複数のリクエストを受けたときに、管理サーバの中でコマンドキューの中にコマンドを保管する。そして、次から、コマンドを受けるたびに、コマンド同士で影響しあうコマンドがないかを確認し、常にコマンドの最適化を行い、コマンドキュー内を管理することを特徴とする。尚、動作例３における最適化後のコマンドは、動作例２と同様に図１２の２つに削減される。この例も、管理者から入力された複数の指示を適切化し被管理装置へ送信するという点では変わらないが、図１１との違いは、適切なコマンドの作成方法に違いがある。図１１では、被管理装置の設定情報と、管理サーバの管理する被管理装置の設定情報の差分を抽出する事により、適切化された複数のコマンドを管理サーバが作成していた。この図１４では、管理者から指示が入力される毎に、管理サーバはコマンドキューから過去に入力されたコマンドを確認して、影響を及ぼしあうコマンドに関して、適切化を行う。つまり、新たにコマンドが入力されるタイミングにリアルタイムでコマンドキューに適切化されたコマンドが準備され、被管理装置からのコマンドリクエストを待つ。

ステップS1401では、管理サーバの内部処理であるループの開始を表している。ステップS1402では、管理サーバは、ユーザインタフェースを通じて管理者からのリクエストを受信する。ここでは、管理者からの他のリクエスト、あるいはリクエストが発生しない可能性もあるので、管理サーバとしては、管理者からのリクエストの判断をする。ステップS1402で、管理者からの設定変更のリクエストを受けた場合には、処理はステップS1403へ進む。そして、設定変更のリクエストコマンドがはじめて行われたのか、過去に同じ設定変更のリクエストを受けているのかを示す変更フラグを確認する判断処理を行う。ステップS1403の変更フラグ確認の判断処理で、変更フラグがなかった場合には、ステップS1405へ進み、リクエストに対する変更フラグをセットし、管理サーバで管理をしているコマンドキューの中にリクエストを保管する。又、ステップS1403の変更フラグを確認する処理にて、すでに変更フラグがセットされていた場合には、ステップS1404へ進む。

ステップS1404では、管理サーバの管理するコマンドキュー内のコマンドと、新規に発行されたコマンドを比較し、影響しあうコマンドがなければ、新規にリクエストをキュー内に保管する。影響しあうコマンドがあった場合には、先に入れられているコマンドを削除するなど、適切な処理を行い、新規リクエストをキュー内に保管する。ここで、管理者が入力したコマンド数をＮ、新規リクエストのコマンド数をＭとする。

一方、ステップS1402で、管理者からの他のリクエスト（設定情報リクエストやレブートリクエスト等）を受けた場合には、処理はステップS1402aからS1404aへ進み、管理サーバのＤＢに保管される。次に、ステップS1406へ行くが、ステップS1402で、管理者からリクエストを受けなかった場合にも、ステップS1402aからこのステップS1406へいく。ここで、ループが終了するが、ループの終了条件は、被管理装置からコマンドリクエストを受信した場合に、ループ処理の終了となる。

ステップS1407では、被管理装置からの識別IDから認証処理を行う。ステップS1408にて、データベース内に変更フラグがセットされているか確認する。ステップS1409にて、変更フラグがセットされているかの判断処理を行う。ステップS1409の判断処理で、変更フラグがセットされていなかった場合には、ステップS1409aに進む。ステップS1409aでは他のリクエストか否かを判定し、ステップS1409bで他のリクエストを処理する。他のリクエストが無い、あるいは処理が終了した場合にはステップS1410へ処理は進み、被管理装置に空のコマンドリクエストを送信して、処理を終了する。

ステップS1409にて、変更フラグがセットされていて、Ｍ個のコマンドがキュー内にあることが確認できた場合には、ステップS1411の処理に進み、カウンタCNTをリセットし、CNT = 1をセットする。ステップS1412にて、カウンタCNTの値が、コマンドの数Ｍ未満だった場合に、ステップS1413で、被管理装置に対して、CNT番目のコマンドを送信する。ステップS1414にて、ステップS1413で被管理装置に送信したコマンドの結果を受信する。ステップS1415にて、次のコマンドのために、被管理装置へコマンドリクエストを送信する。ステップS1416にて、ステップS1415の指示結果をして、被管理装置からコマンドリクエストを受信する。ステップS1417にて、カウンタCNTの値を１つインクリメントする。ステップS1418では、被管理装置へCNT（Ｍ）番目のコマンドを送信する。ステップS1419にて、ステップS1418で、被管理装置に送信したコマンドの結果を受信する。ステップS1420にて、ステップS1419での通信結果を被管理装置へ送信する。

＜本実施形態の被管理装置の構成例＞
（被管理装置のハードウェア構成例）
図１５は、本実施形態の被管理装置のハードウェア構成例を示す図である。尚、図１５には、図１に示したようなデバイス管理用の独立した被管理装置の構成例を示すが、上述のようにこの被管理装置はクライアントＰＣ103や複写機101に搭載されていてもよく、その場合にはそれぞれのデバイスを処理するための構成要素が付加される。

被管理装置102は汎用のコンピュータ等で構成されてよい。全体を制御するためのCPU222と、システム起動に必要なブートプログラムを記憶するための読み出し専用メモリであるROM223と、CPU222でプログラムを実行する際に必要とされる作業メモリであるRAM224とを含む。又、Network上で通信を行うためのNetwork I/F225と、CPU222で実行するプログラムや各複写機から送られた稼働情報などを格納する磁気ディスク等の記憶装置228を含む。

被管理装置102は、管理サーバ106への定期的な稼働情報通知や不定期的な異常状態の通知、コマンドリクエストをNetwork I/F225を介して定期的に、あるいは管理サーバ106からのリクエストに応じて送信している。定期的に通知する稼働情報には、各種カウンタ値や稼働ログなどが含まれている。又、複写機101に使用されているパーツが推奨寿命に対してどのくらい消耗しているのかをレポートの形で送信する。不定期的に通知する複写機101の異常状態を表す情報には、稼働情報に加えて、発生したハード障害やジャムなどのエラー／アラーム情報が含まれている。

（被管理装置の記憶構成例）
図１６は、図１５のＲＯＭ223又は記憶装置228に不揮発的に記憶されるプログラム及びデータの構成例、ＲＡＭ224に一時記憶されるデータの構成例を示す図である。尚、図１６には、本実施形態に関連深いプログラム及びデータのみを示し、他は省略している。

１６０１はＯＳ等の装置の基礎的な制御を行なうシステムプログラムである。１６０２は本被管理装置のデバイス管理全体を制御するデバイス管理プログラムである。かかるデバイス管理プログラム１６０２の本実施形態に関連する部分は、以下に図１８を参照して説明される。１６０３はデバイスの設定情報を管理する設定情報管理プログラムである。１６０４は、管理サーバから受信したメッセージに含まれるリクエストを解析して、それに対応する処理の実行を指示するリクエスト解析プログラムである。１６０５は、リクエスト解析プログラム１６０４の解析結果に対応して実行される各処理プログラムである。例えば、設定情報リクエストと解析すれば設定情報返信処理１６０５ａを実行し、リブートリクエストと解析すればリブート処理１６０５ｂを実行し、設定情報変更ロクエストと解析すれば設定情報変更処理１６０５ｃを実行する。ここには、本実施形態に関連する受信リクエストを示したが。これに限定されない。

１６０６は、管理サーバの識別ＩＤである。１６０７は、本被管理装置が管理するデバイスの設定情報データベース（ＤＢ）である。１６０８は、本被管理装置が管理するデバイスのステータスデータベース（ＤＢ）であり、設定情報ＤＢと関連付けて記憶されている。

１６０９は、管理サーバから受信したメッセージが含む識別ＩＤである。１６１０は、管理サーバからの受信メッセージに含まれるリクエスト情報である。１６１１は管理サーバへ送信される送信メッセージ、１６１２は管理サーバから受信される受信メッセージである。

１６１３は、プログラムをＣＰＵ222が実行するためロードする記憶領域である。

（被管理装置からの通信データの構成例）
図１７は、被管理装置から管理サーバへ送信されるコマンド及びデータを模式的に表した図である。これは、図１６の送信メッセージ１６１２に相当する。

701は、データ送信日時であり、被管理装置から管理サーバへ送信を始めるときの被管理装置の内部時刻であり、通信種別702は、この通知が定期的なものなのか、或いは不定期的なものなのかを表す識別子である。703には、被管理装置情報が出力される。管理サーバ内で被管理装置を一意に特定するための情報や、被管理装置の種類を特定するための情報が出力される。704は被管理装置の識別IDである被管理装置IDが出力され、705は被管理装置Typeが入る。これは、被管理装置が、複写機上で走る監視プログラムなのか、PC上で走るプログラムなのか、特定デバイスで動く監視装置なのかの、種別を表すコードである。706は、被管理装置のプログラムに関するバージョン情報である。707には、コマンド情報が入る。

707の例では、コマンドリクエストが出力されており、管理サーバ上に保管されているコマンド情報をリクエストするコマンドである。708の例では、コンフィグレーション要求が出力されており、被管理装置をすべて設定しなおすときに、管理サーバの持つ設定情報を要求するコマンドの例である。709の例では、管理装置の設定情報を通知するコマンドが出力されており、コマンドとともにデータを管理サーバに送信している。710で被管理装置のアクセスするURL先を出力し、711で、被管理装置が設定されている通信スケジュールを出力し、712で、被管理装置の管理するデバイスリスト情報を出力する。713から715では各デバイス固有の情報である。

＜本実施形態の被管理装置の動作例＞
（被管理装置の動作手順例）
図１８は、本実施形態の被管理装置の動作手順例を示すフローチャートである。

ステップS1801で管理サーバからのリクエスト受信を待つ。リクエストが無ければ、ステップS1802で管理サーバからのリクエストの無い時間が予め決められた時間だけ経過したかを判定する。経過したならば、ステップS1803で被管理装置はコマンドリクエストを管理サーバに送信する。

管理サーバからのリクエスト受信があると、ステップS1804で識別ＩＤが当該被管理装置を管理する管理サーバのものであることで管理サーバを認証する。月に、ステップS1805で受信したリクエストの内容を解析する。ステップS1606,S1808,S1810,S1811,S1813で解析したコマンドに対応して分岐して処理を実行する。

設定情報要求のコマンドであれば、ステップS1807に進んで設定情報をＤＢ１６０７から読出して、ステップS1815で管理サーバに送る。リブートコマンドであれば、ステップS1809に進んでリブートを実行して、ステップS1815でリブートの処理結果を管理サーバに送る。コマンドリクエスト要求のコマンドであれば、ステップS1803に進んでコマンドリクエストを管理サーバに送信する。設定情報変更のコマンドであれば、ステップS1812に進んで設定情報ＤＢ１６０７の設定情報を変更して、ステップS1815で処理結果を管理サーバに送る。他のリクエストのコマンドであれば、ステップS1814に進んで他のリクエストを処理して、ステップS1815で処理結果を管理サーバに送る。

尚、本実施形態では、管理サーバと１台の被管理装置との通信シーケンスを例に説明した。しかし、保管した入力コマンドが複数の被管理装置にわたる場合には以下のような制御をしてもよい。例えば図２の通信シーケンスのS414で、管理サーバは、先のリクエストに対するRelayを返した被管理装置には受信成功の応答をし、次の入力コマンドの対象である他の被管理装置にはコマンド取得リクエストを送信するように制御する。

又、本実施形態では、被管理装置102として複写機などのデバイスと独立した装置を例に説明したが、被管理装置102の機能はクライアントＰＣ103や複写機101に搭載されてもよい。

又、本実施形態での管理者指示の削減は、デバイスの設定変更について示したが、これに限定されず、他の指示においても被管理装置からのコマンドリクエストが無い間の管理者指示を削減することは可能である。

又、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システム或いは装置に供給する。そして、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、プログラムコード自体及びそのプログラムコードを記憶した記憶媒体は本発明を構成することになる。

プログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等を用いることができる。

又、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでない。そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳなどが実際の処理の一部又は全部を行い、その処理によって前述した第１の実施形態や第２の実施の形態の機能が実現される場合も含まれることは言うまでもない。

更に、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれる。その後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部又は全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

本実施形態の複写機、被管理装置及び管理サーバとのインターネットを介した接続関係を示す図である。 本実施形態の被管理装置と管理サーバと管理者との間の通信シーケンス例を表した図である。 本実施形態の管理サーバのハードウエア構成例を示すブロック図である。 本実施形態の管理サーバのアプリケーションプログラムの機能ブロック図である。 本実施形態の管理サーバの記憶構成例を示す図である。 本実施形態の管理サーバの記憶構成例を示す図である。 本実施形態の管理サーバから被管理装置へ送信される情報例を表した図である。 本実施形態の管理者が管理サーバを介して被管理装置へ入力したリクエストの例を表した図である。 本実施形態の管理サーバが被管理装置に対して送信するコマンドの例を表した図である。 本実施形態の管理サーバ内で管理している被管理装置の設定情報の例を示す図である。 動作例１における、管理サーバがユーザリクエストを受け、被管理装置にコマンド送信する処理手順例を表すフローチャートである。 本実施形態の管理者のリクエストに基づいて作成した設定情報例の例を表した図である。 動作例２における、管理サーバがユーザリクエストを受け、被管理装置にコマンド送信する処理を表すフローチャートである。 動作例２及び３における、管理サーバが作成した被管理装置へのコマンドの例を表した図である。 動作例２における、被管理装置と管理サーバと管理者との間の通信シーケンス例を表した図である。 動作例３における、管理サーバがユーザリクエストを受け、被管理装置にコマンド送信する処理手順例を表すフローチャートである。 本実施形態の被管理装置のハードウエア構成例を示すブロック図である。 本実施形態の被管理装置の記憶構成例を示す図である。 本実施形態の被管理装置から管理サーバへ送信される情報例を表した図である。 本実施形態の被管理装置の動作手順例を示したフローチャートである。

Claims (11)

1. ファイアウォールにより外部からのネットワークを介したアクセスが制限されるネットワーク環境に設置された被管理デバイスと前記ネットワークを介して接続され、前記ファイアウォールの外部のネットワーク環境に設置される管理装置であって、
   前記被管理デバイスへの、被管理デバイスの監視対象となる複写機の追加、削除及び属性情報の変更のいずれかの指示を入力するための入力手段と、
   前記入力手段を介して入力された複数の指示を保管する指示保管手段と、
   前記指示保管手段により保管された複数の指示を、より少ない数の指示に変更する指示変更手段と、
   前記被管理デバイスから前記ファイアウォールを越えて、前記入力手段を介して入力された指示の有無の問い合わせを受けた際に、前記指示変更手段により削除されずに、変更された指示があれば、前記問い合わせに対して当該入力された指示を前記問い合わせを受けた際に張られたセッションにおいて前記被管理デバイスへ返信する指示返信手段と
   を有し、
   前記指示返信手段は、前記被管理デバイスからの前記問い合わせに応じて１つの指示を前記被管理デバイスへ返信すると共に、前記被管理デバイスからの前記返信に対応する応答に応じて、前記セッションを維持しつつ、前記被管理デバイスへの指示の返信を更に行い、
   前記指示変更手段は、前記指示保管手段により保管された複数の指示の中に削除の指示と、当該削除の指示の前に実行されるべき指示として対象となる複写機の追加の指示があった場合に、当該削除の指示及び当該追加の指示を削除し、
   前記指示変更手段は、前記指示保管手段により保管された複数の指示の中に同じ複写機に対する属性情報の変更の指示があった場合に、いずれかの指示のみを行うよう変更することを特徴とする管理装置。
2. 前記指示返信手段は、前記入力手段を介して入力された指示の有無の問い合わせをするように前記被管理デバイスに対して要求し、該要求に応じた前記被管理デバイスからの前記問い合わせに応じて前記入力手段を介して入力されている指示の前記被管理デバイスへの返信を更に行うことを特徴とする請求項１に記載の管理装置。
3. 前記指示返信手段は、
   前記被管理デバイスからの前記入力手段を介して入力された指示の有無の問い合わせに応じて返信した、指示の数をカウントするカウント手段と、
   前記カウント手段でカウントされた指示の数が前記指示保管手段に保管した指示の数になるまで、前記被管理デバイスに対して、前記問い合わせに応じた１つの指示の返信と当該管理装置へ前記問い合わせをする要求とを行う返信制御手段とを有することを特徴とする請求項１に記載の管理装置。
4. 前記指示変更手段は、
   前記複数の指示に基づき変更された場合の被管理デバイスの情報と、前記複数の指示前に保持された被管理デバイスの情報との差異を認識する差異認識手段を有し、
   前記差異認識手段により差異が認識された際に前記指示の変更を行うことを特徴とする請求項１に記載の管理装置。
5. 前記指示変更手段は、前記入力手段を介して指示が入力された際、当該入力された指示により、当該指示前に保持されている複数の指示の内容に変更が生じる場合、当該指示が入力された時点で、前記指示前に保持されている複数の指示を、当該入力された指示を反映させた指示に変更することを特徴とする請求項１に記載の管理装置。
6. ファイアウォールにより外部からのネットワークを介したアクセスが制限されるネットワーク環境に設置された被管理デバイスと前記ネットワークを介して接続され、前記ファイアウォールの外部のネットワーク環境に設置される管理装置の制御方法であって、
   前記管理装置の入力手段が、前記被管理デバイスへの、被管理デバイスの監視対象となる複写機の追加、削除及び属性情報の変更のいずれかの指示の入力を取得する取得工程と、
   前記管理装置の指示保管手段が、前記取得工程にて取得した複数の指示を保管する指示保管工程と、
   前記管理装置の指示変更手段が、前記指示保管手段により保管された複数の指示を、より少ない数の指示に変更する指示変更工程と、
   前記管理装置の指示返信手段が、前記被管理デバイスから前記ファイアウォールを越えて、前記取得工程で取得された指示の有無の問い合わせを受けた際に、前記指示変更工程にて削除されずに、変更された指示があれば、前記問い合わせに対して当該取得された指示を前記問い合わせを受けた際に張られたセッションにおいて前記被管理デバイスへ返信する指示返信工程とを有し、
   前記指示返信工程では、前記被管理デバイスからの前記問い合わせに応じて１つの指示を前記被管理デバイスへ返信すると共に、前記被管理デバイスからの前記返信に対応する応答に応じて、前記セッションを維持しつつ、前記被管理デバイスへの指示の返信を更に行い、
   前記指示変更工程にて、前記指示保管工程により保管された複数の指示の中に削除の指示と、当該削除の指示の前に実行されるべき指示として対象となる複写機の追加の指示があった場合に、当該削除の指示及び当該追加の指示を削除し、
   前記指示変更工程にて、前記指示保管工程により保管された複数の指示の中に同じ複写機に対する属性情報の変更の指示があった場合に、いずれかの指示のみを行うよう変更することを特徴とする管理装置の制御方法。
7. 前記指示返信工程では、前記取得工程で取得された指示の有無の問い合わせを前記被管理デバイスに対して要求し、該要求に応じた前記被管理デバイスからの前記問い合わせに応じて前記取得工程で取得されている指示の前記被管理デバイスへの返信を更に行うことを特徴とする請求項６に記載の管理装置の制御方法。
8. 前記指示返信工程は、
   前記被管理デバイスからの前記取得工程で取得された指示の有無の問い合わせに応じて返信した、指示の数をカウントするカウント工程と、
   前記カウント工程でカウントされた指示の数が前記指示保管工程で前記指示保管手段に保管した指示の数になるまで、前記被管理デバイスに対して、前記問い合わせに応じた１つの指示の返信と当該管理装置へ前記問い合わせをする要求とを行う返信制御工程とを有することを特徴とする請求項６に記載の管理装置の制御方法。
9. 前記指示変更工程は、
   前記複数の指示に基づき変更された場合の被管理デバイスの情報と、前記複数の指示前に保持された被管理デバイスの情報との差異を認識する差異認識工程を有し、
   前記差異認識工程で差異が認識された際に前記指示の変更を行うことを特徴とする請求項６に記載の管理装置の制御方法。
10. 前記指示変更工程は、前記取得工程にて指示が取得された際、当該取得された指示により、当該指示前に保持されている複数の指示の内容に変更が生じる場合、当該指示が取得された時点で、前記指示前に保持されている複数の指示を、当該取得された指示を反映させた指示に変更することを特徴とする請求項６に記載の管理装置の制御方法。
11. 請求項６乃至１０のいずれか１項に記載の管理装置の制御方法の工程をコンピュータに実行させるためのプログラム。

Images