(57)【要約】【課題】  余分な設備を追加すること無しに、ファイアウォールを具備するセキュリティ環境でも充分なメンテナンスを実現できるデバイス管理システム及びその管理装置の制御方法を提供する。【解決方法】  ネットワークを介して接続される、管理される被管理デバイスと管理する管理装置とからなるデバイス管理システムで、管理装置が、被管理デバイスからのファイアウォール越えの前記指示の有無の問い合わせを受け、入力された指示があれば、問い合わせに対して入力された指示を前記問い合わせを受けた際に張られたセッションにおいて返信する。かかる返信は、問い合わせに対して入力された１つの指示を返信すると共に、前記被管理デバイスからの前記返信に対応する応答に応じて、前記セッションを維持しつつ、更に入力されている指示を行う。【選択図】  図２
2007334612.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して接続される、管理される被管理デバイスと該被管理デバイスを管理する管理装置とからなるデバイス管理システムにおいて、
前記管理装置が、
前記被管理デバイスへの指示を入力するための入力手段と、
前記被管理デバイスからのファイアウォール越えの前記指示の有無の問い合わせを受け、前記入力手段を介して入力された指示があれば、問い合わせに対して入力された指示を前記問い合わせを受けた際に張られたセッションにおいて返信する指示返信手段とを有し、
前記指示返信手段は、問い合わせに対して入力された１つの指示を返信すると共に、前記被管理デバイスからの前記返信に対応する応答に応じて、前記セッションを維持しつつ、更に入力されている指示を行うことを特徴とするデバイス管理システム。
【請求項２】
前記指示返信手段は、前記被管理デバイスへ前記指示の有無の問い合わせを要求し、該要求に応じた前記被管理デバイスからの指示の有無の問い合わせに対して更に入力されている指示を行うことを特徴とする請求項１に記載のデバイス管理システム。
【請求項３】
前記管理装置が、前記入力手段を介して入力された複数の指示を保管する指示保管手段を有することを特徴とする請求項１又は２に記載のデバイス管理システム。
【請求項４】
前記指示返信手段は、
問い合わせに対して返信した指示の数をカウントするカウント手段と、
前記カウント手段のカウント数が前記指示保管手段に保管した指示の数になるまで、問い合わせに対する１つの指示の返信と前記指示の有無の問い合わせの要求とを行なう返信制御手段とを有することを特徴とする請求項３に記載のデバイス管理システム。
【請求項５】
前記管理装置が、前記入力手段を介して入力された複数の指示を、該複数の指示を実現する、より少ない数の指示に変更する指示変更手段を更に有し、
前記指示返信手段は、前記指示変更手段により少なくなった指示を返信することを特徴とする請求項１乃至４のいずれかに記載のデバイス管理システム。
【請求項６】
前記指示変更手段は、
前記複数の指示に基づき変更された被管理デバイスの情報と、前記複数の指示前に保持された被管理デバイスの情報との差異を認識する差異認識手段と、
前記被管理デバイスの情報の差異を実現するように、前記複数の指示より少ない指示を生成する指示生成手段とを有することを特徴とする請求項５に記載のデバイス管理システム。
【請求項７】
前記管理装置が、入力された複数の指示の内から実施する必要の無い指示を削除する指示削除手段を更に有し、
前記指示返信手段は、前記指示削除手段により削減されず残された指示を返信することを特徴とする請求項１乃至６のいずれかに記載のデバイス管理システム。
【請求項８】
前記指示削除手段は、
前記入力された指示と既に入力されている指示とを比較して、同じ被管理デバイスの情報の変更や情報の削除が有るかを判定する判定手段と、
前記判定手段による判定結果に基づき、変更されたあるいは削除された同じ被管理デバイスの情報に関する、前の指示を削除する削除手段とを有することを特徴とする請求項７に記載のデバイス管理システム。
【請求項９】
管理される被管理デバイスとネットワークを介して接続される、該被管理デバイスを管理する管理装置の制御方法であって、
前記被管理デバイスへの指示の入力を取得する取得工程と、
前記被管理デバイスからのファイアウォール越えの前記指示の有無の問い合わせを受け、前記取得工程で取得された指示があれば、問い合わせに対して取得された指示を前記問い合わせを受けた際に張られたセッションにおいて返信する指示返信工程とを有し、
前記指示返信工程では、問い合わせに対して入力された１つの指示を返信すると共に、前記被管理デバイスからの前記返信に対応する応答に応じて、前記セッションを維持しつつ、更に取得されている指示を行うことを特徴とする管理装置の制御方法。
【請求項１０】
前記指示返信工程では、前記被管理デバイスへ前記指示の有無の問い合わせを要求し、該要求に応じた前記被管理デバイスからの指示の有無の問い合わせに対して更に取得されている指示を行うことを特徴とする請求項９に記載の管理装置の制御方法。
【請求項１１】
前記取得工程で取得された複数の指示を保管する指示保管工程を更に有することを特徴とする請求項９又は１０に記載の管理装置の制御方法。
【請求項１２】
前記指示返信工程は、
問い合わせに対して返信した指示の数をカウントするカウント工程と、
前記カウント工程でのカウント数が前記指示保管工程で保管した指示の数になるまで、問い合わせに対する１つの指示の返信と前記指示の有無の問い合わせの要求とを行なう返信制御工程とを有することを特徴とする請求項１１に記載の管理装置の制御方法。
【請求項１３】
前記取得工程で取得された複数の指示を、該複数の指示を実現する、より少ない数の指示に変更する指示変更工程を更に有し、
前記指示返信工程では、前記指示変更工程で少なくなった指示を返信することを特徴とする請求項９乃至１２のいずれかに記載の管理装置の制御方法。
【請求項１４】
前記指示変更工程は、
前記複数の指示に基づき変更された被管理デバイスの情報と、前記複数の指示前に保持された被管理デバイスの情報との差異を認識する差異認識工程と、
前記被管理デバイスの情報の差異を実現するように、前記複数の指示より少ない指示を生成する指示生成工程とを有することを特徴とする請求項１３に記載の管理装置の制御方法。
【請求項１５】
取得された複数の指示の内から実施する必要の無い指示を削除する指示削除工程を更に有し、
前記指示返信工程では、前記指示削除工程で削減されず残された指示を返信することを特徴とする請求項９乃至１４のいずれかに記載の管理装置の制御方法。
【請求項１６】
前記指示削除工程は、
前記取得された指示と既に取得されている指示とを比較して、同じ被管理デバイスの情報の変更や情報の削除が有るかを判定する判定工程と、
前記判定工程での判定結果に基づき、変更されたあるいは削除された同じ被管理デバイスの情報に関する、前の指示を削除する削除工程とを有することを特徴とする請求項１５に記載の管理装置の制御方法。
【請求項１７】
請求項９乃至１６のいずれかに記載の管理装置の制御方法を実現するコンピュータ実行可能なプログラム。
【請求項１８】
請求項１７に記載のプログラムをコンピュータ読み出し可能な形態で記憶する記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク通信を用いたデバイス管理システム及びその管理装置の制御方法に関する。特に、ネットワークを介して遠隔でデバイスを管理する被管理装置への指示をネットワークを介して処理する管理サーバの制御方法、それを実現するアプリケーションプログラムに関するものである。
【背景技術】
【０００２】
従来から、管理サーバからネットワークを介して顧客先のデバイスを管理するメンテナンスシステムが知られている。この従来のメンテナンスシステムでは、例えば、デバイスステータス取得やデバイスの各種設定変更等を行っていた。この場合、まず管理サーバがイニシエーターとなり、例えば、インターネット回線を介しデバイスへアクセスし、上述の各種処理を行っていた。
【０００３】
しかし、インターネット等の普及に伴いセキュリティ技術が強化され、従来の仕組みでは不都合を生じる場合が出てきた。例えば、インターネット上の管理サーバから自発的に顧客のデバイスへアクセスするには、ファイアウォールが障害となってしまう。  該環境下では、充分なメンテナンスを実現できないという問題があった。
【０００４】
かかる問題を解決するため、特許文献１には、管理サーバと被管理装置との間に第三の中継サーバを設けたシステムが開示されている。このシステムでは、管理サーバの発行したコマンドを中継サーバの特定フォルダに格納し、被管理装置は特定フォルダにコマンドが格納されたかを監視して、設定コマンドが準備されていればコマンドを取得して実行する。
【特許文献１】特開２００２−０８２７９２公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記特許文献１では、中継サーバという余分な設備を準備する必要がある。更に、中継サーバは単にコマンドを受渡するのみであるため、管理サーバからのコマンド発行を無駄無く行なってネットワークへの負担を軽減するなど、管理サーバからの柔軟な動作指示を制御することができない。
【０００６】
本発明は、前記従来の問題点に鑑み、余分な設備を追加すること無しに、ファイアウォールを具備するセキュリティ環境でも充分なメンテナンスを実現できるデバイス管理方法及びそのシステム、管理装置を提供する。更に、複数の動作指示を扱う際に適切な指示制御を行え、無駄な指示や被管理デバイスの無駄な負荷を抑制できるデバイス管理システム及びその管理装置の制御方法を提供する。
【課題を解決するための手段】
【０００７】
上述した課題を解決するために、本発明のデバイス管理システムは、ネットワークを介して接続される、管理される被管理デバイスと該被管理デバイスを管理する管理装置とからなるデバイス管理システムにおいて、前記管理装置が、前記被管理デバイスへの指示を入力するための入力手段と、前記被管理デバイスからのファイアウォール越えの前記指示の有無の問い合わせを受け、前記入力手段を介して入力された指示があれば、問い合わせに対して入力された指示を前記問い合わせを受けた際に張られたセッションにおいて返信する指示返信手段とを有し、前記指示返信手段は、問い合わせに対して入力された１つの指示を返信すると共に、前記被管理デバイスからの前記返信に対応する応答に応じて、前記セッションを維持しつつ、更に入力されている指示を行うことを特徴とする。
【０００８】
また、本発明の管理装置の制御方法は、管理される被管理デバイスとネットワークを介して接続される、該被管理デバイスを管理する管理装置の制御方法であって、前記被管理デバイスへの指示の入力を取得する取得工程と、前記被管理デバイスからのファイアウォール越えの前記指示の有無の問い合わせを受け、前記取得工程で取得された指示があれば、問い合わせに対して取得された指示を前記問い合わせを受けた際に張られたセッションにおいて返信する指示返信工程とを有し、前記指示返信工程では、問い合わせに対して入力された１つの指示を返信すると共に、前記被管理デバイスからの前記返信に対応する応答に応じて、前記セッションを維持しつつ、更に取得されている指示を行うことを特徴とする。
【０００９】
更に、上記管理装置の制御方法を実現するコンピュータ実行可能なプログラム、及び該プログラムをコンピュータ読み出し可能な形態で記憶する記憶媒体を提供する。
【発明の効果】
【００１０】
本発明により、余分な設備を追加すること無しに、ファイアウォールを具備するセキュリティ環境でも充分なメンテナンスを実現できる。また、ファイアウォールを具備する環境でも管理側から被管理側に一連の動作を指示することができる。更に、複数の動作指示を扱う際に適切な指示制御を行え、無駄な指示や被管理デバイスの無駄な負荷を抑制できる。
【発明を実施するための最良の形態】
【００１１】
以下、添付図面を参照して、本発明の実施形態を詳細に説明する。
【００１２】
＜本実施形態のデバイス管理システムの構成例＞
図１は、本実施形態に係るデジタル複写機本体（以下、複写機という）と被管理装置（被管理デバイスとも称す）と管理サーバ（管理装置とも称す）とがインターネットを介して接続したデバイス管理システムの構成例を示す図である。
【００１３】
図１において、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に搭載されてもよい。
【０１２３】
又、本実施形態での管理者指示の削減は、デバイスの設定変更について示したが、これに限定されず、他の指示においても被管理装置からのコマンドリクエストが無い間の管理者指示を削減することは可能である。
【０１２４】
又、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システム或いは装置に供給する。そして、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、プログラムコード自体及びそのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【０１２５】
プログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等を用いることができる。
【０１２６】
又、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでない。そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳなどが実際の処理の一部又は全部を行い、その処理によって前述した第１の実施形態や第２の実施の形態の機能が実現される場合も含まれることは言うまでもない。
【０１２７】
更に、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれる。その後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部又は全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【図面の簡単な説明】
【０１２８】
【図１】本実施形態の複写機、被管理装置及び管理サーバとのインターネットを介した接続関係を示す図である。
【図２】本実施形態の被管理装置と管理サーバと管理者との間の通信シーケンス例を表した図である。
【図３Ａ】本実施形態の管理サーバのハードウエア構成例を示すブロック図である。
【図３Ｂ】本実施形態の管理サーバのアプリケーションプログラムの機能ブロック図である。
【図４Ａ】本実施形態の管理サーバの記憶構成例を示す図である。
【図４Ｂ】本実施形態の管理サーバの記憶構成例を示す図である。
【図５】本実施形態の管理サーバから被管理装置へ送信される情報例を表した図である。
【図６】本実施形態の管理者が管理サーバを介して被管理装置へ入力したリクエストの例を表した図である。
【図７】本実施形態の管理サーバが被管理装置に対して送信するコマンドの例を表した図である。
【図８】本実施形態の管理サーバ内で管理している被管理装置の設定情報の例を示す図である。
【図９】動作例１における、管理サーバがユーザリクエストを受け、被管理装置にコマンド送信する処理手順例を表すフローチャートである。
【図１０】本実施形態の管理者のリクエストに基づいて作成した設定情報例の例を表した図である。
【図１１】動作例２における、管理サーバがユーザリクエストを受け、被管理装置にコマンド送信する処理を表すフローチャートである。
【図１２】動作例２及び３における、管理サーバが作成した被管理装置へのコマンドの例を表した図である。
【図１３】動作例２における、被管理装置と管理サーバと管理者との間の通信シーケンス例を表した図である。
【図１４】動作例３における、管理サーバがユーザリクエストを受け、被管理装置にコマンド送信する処理手順例を表すフローチャートである。
【図１５】本実施形態の被管理装置のハードウエア構成例を示すブロック図である。
【図１６】本実施形態の被管理装置の記憶構成例を示す図である。
【図１７】本実施形態の被管理装置から管理サーバへ送信される情報例を表した図である。
【図１８】本実施形態の被管理装置の動作手順例を示したフローチャートである。
【図１】
2007334612.tif 000003
【図２】
2007334612.tif 000004
【図３Ａ】
2007334612.tif 000005
【図３Ｂ】
2007334612.tif 000006
【図４Ａ】
2007334612.tif 000007
【図４Ｂ】
2007334612.tif 000008
【図５】
2007334612.tif 000009
【図６】
2007334612.tif 000010
【図７】
2007334612.tif 000011
【図８】
2007334612.tif 000012
【図９】
2007334612.tif 000013
【図１０】
2007334612.tif 000014
【図１１】
2007334612.tif 000015
【図１２】
2007334612.tif 000016
【図１３】
2007334612.tif 000017
【図１４】
2007334612.tif 000018
【図１５】
2007334612.tif 000019
【図１６】
2007334612.tif 000020
【図１７】
2007334612.tif 000021
【図１８】
2007334612.tif 000022