(57)【特許請求の範囲】
【請求項１】
印刷装置に利用される消耗品の在庫を管理する在庫管理システムであって、
複数種別の消耗品の各々の在庫数を保持する保持手段と、
装置特定情報、及び、消耗品の残量の情報を含む通知を受信する受信手段と、
前記受信した情報を基に印刷装置を特定するとともに、該印刷装置で利用される消耗品の種別を、複数の装置の各々について装置特定情報と消耗品の種別とが対応付けられたデータベースを用いて特定する特定手段と、
前記特定手段により特定された種別の消耗品の在庫数を減算する減算手段と、
前記減算手段により減算された減算後の在庫数を、前記保持手段に保持される保持内容に反映させる反映手段と、
消耗品の種別が含まれた配送指示を行う配送指示手段と、
ユーザの発注指示を示すフラグを記録するフラグ記録手段と、
前記受信手段により前記通知を受信した場合、消耗品の納入が完了しておらず前記フラグが保持されていることに応じて警告処理を行なう警告処理手段とを有することを特徴とする在庫管理システム。
【請求項２】
複数の印刷装置を監視するローカルサーバと通信可能であり、前記受信手段は前記ローカルサーバより前記通知を受信することを特徴とする請求項１に記載の在庫管理システム。
【請求項３】
前記保持手段に保持される消耗品の在庫数を外部装置で閲覧可能であることを特徴とする請求項１又は２に記載の在庫管理システム。
【請求項４】
前記外部装置では消耗品の在庫数をブラウザで閲覧可能であり、前記保持手段は、前記ブラウザで消耗品の在庫数を閲覧するための表示情報を記憶することを特徴とする請求項３に記載の在庫管理システム。
【請求項５】
前記保持手段には、消耗品の種別、及び、種別毎の消耗品の在庫数、及び、前記種別毎の消耗品について発注済であることの履歴の情報が保持されており、前記外部装置で閲覧可能であることを特徴とする請求項３又は４に記載の在庫管理システム。
【請求項６】
外部装置からの前記複数種別の何れかの種別の消耗品の発注を受け付ける発注受付手段を有し、前記外部装置における発注指示画面では各々の種別の消耗品発注指示部が各々の種別の在庫数に応じて無効化されていることを特徴とする請求項１乃至５の何れかに記載の在庫管理システム。
【請求項７】
前記装置特定情報にはＩＰアドレス、或いは、ＭＡＣアドレスが含まれることを特徴とする請求項１乃至６の何れかに記載の在庫管理システム。
【請求項８】
印刷装置に利用される消耗品の在庫を管理する在庫管理方法であって、
装置特定情報、及び、消耗品の残量の情報を含む通知を受け付ける通知受付ステップと、
前記受け付けた情報を基に印刷装置を特定するとともに、該印刷装置で利用される消耗品の種別を、複数の装置の各々について装置特定情報と消耗品の種別とが対応付けられたデータベースを用いて特定する特定ステップと、
前記特定ステップにおいて特定された種別の消耗品の在庫数を減算する減算ステップと、
前記減算ステップにより減算された減算後の在庫数を、複数種別の消耗品の各々の在庫数を保持する保持手段に保持される保持内容に反映させる反映ステップと、
消耗品の種別が含まれた配送指示を行う配送指示ステップと、ユーザの発注指示を示すフラグを記録するフラグ記録ステップと、
前記通知受付ステップにおいて前記通知を受け付けた場合、消耗品の納入が完了しておらず前記フラグが保持されていることに応じて警告処理を行なう警告処理ステップとを有することを特徴とする在庫管理方法。
【請求項９】
複数の印刷装置を監視するローカルサーバと通信可能であり、前記通知受付ステップは前記ローカルサーバより前記通知を受け付けることを特徴とする請求項８に記載の在庫管理方法。
【請求項１０】
前記保持手段に保持される消耗品の在庫数を外部装置で閲覧可能であることを特徴とする請求項８又は９に記載の在庫管理方法。
【請求項１１】
前記外部装置では消耗品の在庫数をブラウザで閲覧可能であり、前記ブラウザで前記消耗品の在庫数を閲覧するための表示情報は前記保持手段に記憶されるものであることを特徴とする請求項１０に記載の在庫管理方法。
【請求項１２】
前記保持手段には、消耗品の種別、及び、種別毎の消耗品の在庫数、及び、前記種別毎の消耗品について発注済であることの履歴の情報が保持されており、前記外部装置で閲覧可能であることを特徴とする請求項１０又は１１に記載の在庫管理方法。
【請求項１３】
外部装置からの前記複数種別の何れかの種別の消耗品の発注を受け付ける発注受付ステップを有し、前記外部装置における発注指示画面では各々の種別の消耗品発注指示部が各々の種別の在庫数に応じて無効化されていることを特徴とする請求項８乃至１２の何れかに記載の在庫管理方法。
【請求項１４】
前記装置特定情報にはＩＰアドレス、或いは、ＭＡＣアドレスが含まれることを特徴とする請求項８乃至１３の何れかに記載の在庫管理方法。
【請求項１５】
請求項８乃至１４の何れかに記載の在庫管理方法をコンピュータに実行させるためのプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、印刷装置で使用される消耗品の在庫管理に係る仕組みに関する。
【０００２】
【従来の技術】
プリンタ装置及び複写機などのＯＡ機器では、記録紙やトナー等の消耗品が所定量消耗されたことを機器側で検知して、その検知情報に基づいて、ネットワーク等を介して自動発注することが行なわれていた。
【０００３】
【発明が解決しようとする課題】
しかしながら、複数種別の機器がオフィス等で使用される場合に、各々の機器に対応した消耗品は異なる種別になることがある。また、その逆の場合も想定され、機器の種別は異なるが、使用され消耗品の種別は同じ場合がある。そのような場合、実際には機器それぞれに対して使用される消耗品毎に、その管理を行なう必要があった。
【０００５】
一方、消耗品の後に伴う物流関連、金融関連、消耗品の回収等の一連の作業はそれぞれリンクされておらず、非効率的に一連の作業が行なわれていた。
【０００６】
また、消耗品の配送指示が成されているにも係らず、その配送がなかなか行われないような場合に、迅速に対応することはできなかった。
【０００７】
本願発明は上記課題に鑑みてなされたものであり、本発明の目的は、複数の種類の印刷装置がオフィス等で使用される場合に、各々の印刷装置に対応した消耗品の種別毎の在庫管理を容易に行えるようにすることである。
【０００８】
【課題を解決するための手段】
上記目的を達成するために本発明は次のような構成からなることを特徴とする。
【０００９】
即ち、印刷装置に利用される消耗品の在庫を管理する在庫管理システムであって、複数種別の消耗品の各々の在庫数を保持する保持手段と、装置特定情報、及び、消耗品の残量の情報を含む通知を受信する受信手段と、前記受信した情報を基に印刷装置を特定するとともに、該印刷装置で利用される消耗品の種別を、複数の装置の各々について装置特定情報と消耗品の種別とが対応付けられたデータベースを用いて特定する特定手段と、前記特定手段により特定された種別の消耗品の在庫数を減算する減算手段と、前記減算手段により減算された減算後の在庫数を、前記保持手段に保持される保持内容に反映させる反映手段と、消耗品の種別が含まれた配送指示を行う配送指示手段と、ユーザの発注指示を示すフラグを記録するフラグ記録手段と、前記受信手段により前記通知を受信した場合、消耗品の納入が完了しておらず前記フラグが保持されていることに応じて警告処理を行なう警告処理手段とを有することを特徴とする。
【００１０】
或いは、印刷装置に利用される消耗品の在庫を管理する在庫管理システムであって、複数種別の消耗品の各々の在庫数を保持する保持手段と、装置特定情報、及び、消耗品の残量の情報を含む通知を受信する受信手段と、前記受信した情報を基に印刷装置を特定するとともに、該印刷装置で利用される消耗品の種別を、複数の装置の各々について装置特定情報と消耗品の種別とが対応付けられた管理情報を用いて特定する特定手段と、前記特定手段により特定された種別の消耗品の在庫数を管理する管理手段と、消耗品の種別が含まれた配送指示を行う配送指示ステップと、ユーザの発注指示を示すフラグを記録するフラグ記録ステップと、前記通知受付ステップにおいて前記通知を受け付けた場合、消耗品の納入が完了しておらず前記フラグが保持されていることに応じて警告処理を行なう警告処理ステップとを有することを特徴とする。
【００１９】
【発明の実施の形態】
［第１の管理システム形態］
図を参照して本発明の管理システムの詳細を説明する。
【００２０】
＜システム構成＞
図１は被管理サイト（図２０のユーザ拠点システム２００１に対応）と管理サイト’図２０のセンタシステム２００３に対応）の構成を示すブロック図である。被管理サイトはＬＡＮで接続された汎用コンピュータであるＰＣ１０３やデバイス監視サーバ２０３ａ（オフィス等のローカルネットワーク上に接続されたデバイス機器を管理する情報機器）、周辺機器である複写機１０１やプリンタ１０５、１０４が含まれている。なお、ここでいう汎用コンピュータとはパーソナルコンピュータ、サーバ、ゲートウエイ、ルータ、ネットワークそのものを含んでおり、周辺機器は複写機やプリンタ、スキャナー、ＦＡＸ、複合機等を含んでいる。ＰＣ１０３においては、後述する汎用コンピュータ管理のためのＰＣ監視クライアントモジュールを実行することができ、オフィス等のローカルネットワーク上に接続された汎用コンピュータ機器等を管理することができる。また、デバイス監視サーバ２０３ａとＰＣ監視クライアントサーバは物理的に別々であっても一つであってもよく、物理的に同一の装置において論理的に別々であってもよい。図１に記載はされてはいないが、本発明を構成するものとして、被管理サイトのＬＡＮ上にはデバイス監視サーバ２０３ａとＰＣ監視クライアントモジュールとの間のデータフォーマット形式を変換／調整する変換装置等が挙げられる。
【００２１】
また、管理サイトには、被管理サイトの機器を一元的に管理するためのセンタサーバ１１０、管理情報等を蓄積するためのインベントリデータベース１０９、被管理サイトにおける周辺機器の管理を専門に行うためのデバイスセンタサーバ２１０が接続されたＬＡＮシステムが構成されている。このシステムには、サーバ／ＰＣ１１１といったその他のコンピュータが接続されている場合もあり、管理情報を用いた管理のためのアプリケーションプログラムはこのコンピュータ１１１により実行されても良い。
【００２２】
また、図１に記載はされてはいないが、本発明を構成するものとして、管理サイトには、被管理サイトから通知されてくる情報を表示させる表示装置、センタサーバ１１０とデバイスセンタサーバとの間でデータフォーマット形式を変換／調整する変換装置等が挙げられる。
【００２３】
また、管理サイトと外部ネットワークまたはＬＡＮを介して接続され、管理サイトを統合的に管理するサービスセンタ（図２のアプリケーションシステム２０５に相当）等も挙げることができる。
【００２４】
これら被管理サイトと管理サイトは、互いにゲートウエイ１０６，１０７で接続されている。この接続は、汎用のルータやモデム等を用いても良い。また、ＰＣ１０３においてＰＣ監視クライアントモジュールを実行している場合には、ＰＣ１０３とセンタサーバ１０９との接続と、デバイス監視サーバ２０３ａとデバイスセンタサーバ２１０との接続をそれぞれ独立させることもできる。
【００２５】
図３は、各ＰＣ、または、サーバであるコンピュータの構成を示すブロック図である。図３において、コンピュータ３０００は、ＲＯＭ３のプログラム用ＲＯＭに記憶された、後述する手順の通信制御プログラム等に基づいて、指定されたデータの外部への送信あるいは外部からのデータ受信を制御する手順等を実行するＣＰＵ１を備え、システムバス４に接続される各デバイスをＣＰＵ１が統括的に制御する。ＲＡＭ２は、ＣＰＵ１の主メモリ、ワークエリア等として機能する。キーボードコントローラ（ＫＢＣ）５は、キーボード９や不図示のポインティングデバイスからのキー入力を制御する。ＣＲＴコントローラ（ＣＲＴＣ）６は、ＣＲＴディスプレイ１０の表示を制御する。メモリコントローラ（ＭＣ）７は、ブートプログラム、種々のアプリケーション、フォントデータ、ユーザファイル、後述する編集ファイル、各種データベース等を記憶するハードディスク（ＨＤ）、フロッピーディスク（ＦＤ）等の外部メモリ１１とのアクセスを制御する。ＬＡＮ制御部８は、ネットワークに接続されて、ネットワークに接続された他の機器との通信制御処理を実行する。
【００２６】
さらに、図３の構成図には図示されていないエラー検知手段を備えており、自装置のメモリ容量フル、ＨＤ容量の不足等、演算処理停止等のエラーを検知することができる。そして、ＬＡＮ制御部８は検知されたエラー情報をデバイス監視サーバ２０３ａ、または、ＰＣ監視クライアントモジュール２０３ｄ等に向けて送信（通知）する機能も備えている。
【００２７】
また、センタサーバ１１０ａに該エラー情報が送信された場合には、インベントリデータベース１０９に該エラー情報が格納され、管理される。
【００２８】
また、デバイス系の機器においても、ＰＣ／サーバ系機器と同様に、エラー検知手段を備えており、消耗品切れ、用紙切れ、感光体の寿命等のエラー情報を検知することができる。また、ＬＡＮ制御部８とも同様の機能を備えており、デバイス監視サーバに該検知された情報を通知することができる。
【００２９】
図２は本遠隔サイト管理システムのソフトウエアモジュールの構成を示すブロック図である。ユーザ拠点システム（被管理サイトを指す）は、デバイス系機器（複写機、プリンタ、複合機、スキャナ、ＦＡＸ等の周辺装置）と、ＰＣ／サーバ系機器（汎用コンピュータ）が混在しているが、デバイス系機器はデバイス監視サーバ２０３ａによって、ＰＣ／サーバ系機器はＰＣ監視クライアント２０３ｄによってそれぞれローカルで管理される。これらを総称して、拠点側管理システム２０３と呼ぶことにする（図２のユーザ拠点システムに相当）。デバイス監視サーバ２０３ａは、管理情報を蓄積するためのデータベース２０３ａ−１を有する。
【００３０】
一方、センターシステム（管理サイトを指す）は、デバイス監視サーバ２０３ａとの間でデータを交換するデバイスセンタサーバ２１０と、ＰＣ監視クライアント２０３ｄとの間でデータを交換するセンタサーバ１１０とを含む。デバイス系機器の管理情報はインベントリデータベース１０９に蓄積される。また、センタサーバによって管理される管理情報もインベントリデータベース１０９に蓄積される。これらインベントリデータベース１０９に蓄積される管理情報はアプリケーションシステム２０５等により利用される。なお、インベントリデータベース１０９はデバイス系とＰＣ／サーバ等の汎用コンピュータ系とで、それぞれ論理的に分かれていればよく、無論、物理的に分かれていてもよい。
【００３１】
デバイス監視サーバ２０３ａとデバイスセンタサーバ２１０とは、データ形式や手順を必要に応じて変換するための拠点プラグインモジュール２０３ｂとサーバプラグインモジュールを介して接続されている。これら拠点プラグインモジュールとサーバプラグインモジュールとによって、拠点側とセンタ側とで使用ＯＳが異なる場合などにもお互いの通信を可能にすることが可能となる。また、電気的には、ルータ２０４を介する。この回線は、ＰＣ監視クライアント２０３ｄとセンタサーバ１１０とを接続する回線と物理的または論理的に共用されている。
【００３２】
デバイスセンタサーバ２１０とデバイス監視サーバ２０３ａを接続する回線は、監視クライアント２０３ｄとセンタサーバ間を接続する回線と共用されない場合も想定され、モデムやルータを介して、管理クライアント２０３ｄ−センタサーバ１１０とは独立した回線で接続されても良い。
【００３３】
センタサーバ１１０には、イベントモニタ１１０ａが含まれており、センタサーバ１１０に対して発行されたイベントを監視し、障害の発生等を伝えるイベントであればモニタ上に表示する。管理者はその表示を見ることで、被管理サイトにおいて発生した障害の状況を知ることができる。センタサーバ１１０に対してイベントを発行するのは、イベントアダプタ２１０ａと、ＰＣ監視クライアント２０３ｄと、アプリケーションシステム２０５である。センタサーバ１１０は、受け取ったイベントを、それが示す内容に従って所定の処理を実行する。イベントとしては例えば、障害通知等がある。
【００３４】
デバイスセンタサーバ２１０には、イベントアダプタモジュール２１０ａが含まれている。イベントアダプタ２１０ａは、デバイス監視サーバ２０３ａからデバイスセンタサーバ２１０に対して送られてきて受信した情報を定期的に検索する機能をもち、その検索された情報の内から、周辺機器において発生した障害に関する情報を判別してより分けて、センタサーバ１１０において処理可能な形式（ファイル形式、プロトコル形式等）に変換してから、センタサーバ１１０に対して障害の発生を示すイベントを発行する。あるいは、イベントアダプタモジュール２１０ａによってセンタサーバに処理可能な形式に変換する機能をセンタサーバ１１０に持たせてもよい。障害関連のイベント（障害イベント）には、障害の起きた装置やその内容、発生時刻等が含まれる。このイベントアダプタ２１０ａを本システム及び装置に設けることによって、デバイス専用に想定されたプロトコル／フォーマットを使用した管理ソフトによって得られたデバイス固有の情報、例えば、紙詰まり、インク／トナー等の消耗品切れ、用紙切れ、感光体（感光体ユニットを含む）の寿命、ステープル機能チェック等を別の種別のシステム／装置（実施例では汎用コンピュータ／サーバ等）を監視するソフトを利用して一元化して管理することが可能となる。
【００３５】
また、このときＰＣ／サーバ系機器において発生される情報でＰＣ監視クライアント２０３ｄによって管理され、センタサーバ１１０に通知される情報としては、例えば、ＣＰＵ使用率、メモリ使用可能バイト数、ページファイル使用パーセント比率、論理ディスク空き領域（ＨＤ空き領域）などの情報が挙げられ、これらの情報はＰＣ／サーバ系機器専用に想定されたプロトコル／フォーマットを使用した管理ソフトによって得られたＰＣ／サーバ系機器固有の情報として管理される。ＰＣ／サーバ系機器においては、例えばＨＤなどが消耗品として管理される。
【００３６】
イベントモニタ１１０ａはそれを受けて、障害の起きた装置やその内容、発生時刻等を、イベントのリストに加えて表示する。表示の方法としては、たとえば、１行に１イベントを表示し、時系列的にイベントのリストを表示する。図２ではイベントモニタ１１０ａはセンタサーバ１１０に含まれる形で記載されているが、このイベントモニタ１１０ａをセンタサーバ１１０からネットワーク等を介して外部に接続することで、例えば、デバイスセンタサーバ２１０側やアプリケーションシステム２０５側でデバース系、ＰＣ／サーバ系を包括管理することが可能となる。
【００３７】
ここで注意すべきなのは、イベントモニタ１１０ａは、イベントの発生元を意識することなく、障害系のイベントであればそれを表示することで、管理者の注意を喚起できる、ということである。すなわち、イベントモニタ１１０ａにおいては、ＰＣ監視クライアント２０３ｄから発行された、汎用コンピュータ系の障害イベントと、デバイスセンタサーバ２１０のイベントアダプタ２１０ａを介してデバイス監視サーバ２０３ａから発行された、周辺機器系の障害イベントとを、同一画面上のイベントリストにたとえば時系列的に表示する。
【００３８】
さらに、図１、２には図示されていないが、ユーザ拠点システムおよびセンタシステム間にはネットワークを介して金融機関、物流機関等の機関（Ｗｅｂサーバ）が存在しており、詳細に関しては後述にて説明をする。
【００３９】
次に、デバイスセンタサーバ２１０と、デバイス監視サーバ２０３ａとの間でなされるデータ交換の手順の例を、図４を参照しつつ、（１）デバイスへの、デバイスセンタサーバ２１０からの設定値のダウンロード、（２）デバイス監視サーバ２０３ａからデバイスセンタサーバ２１０へのログデータのアップロード、（３）デバイスセンタサーバ２１０からデバイス監視サーバ２０３ａへのカウンタデータの要求、という３つのケースで説明する。その前に、データフォーマットについて簡単に説明する。
【００４０】
図８は、デバイスセンタサーバ２１０とデバイス監視サーバ２０３ａとの間で交換されるメッセージフォーマットの一例を示す図である。１つのメッセージは、フラグフィールド，データ種別フィールド，ジョブＩＤフィールド，リターン値フィールド，データ長フィールド，データフィールドを含む。フラグフィールドには、通信手段を示すビット群と、そのメッセージがデータの最終フレームであるか否かを示すビットが含まれる。
【００４１】
データ種別フィールドでは、たとえば認証要求データ（セッションの先頭に送信されるデータ）であることや、ダウンロードされる設定値データであること、後述するデバイス情報要求であること、イベント情報の通知であること、ログデータ処理要求であることなどが示される。たとえば障害の通知などは、イベント情報であることがデータ種別として示され、データフィールドで具体的な内容が示される。
【００４２】
ジョブＩＤは、そのセッションの種類を示すもので、パラメータ設定やデバイス情報の取得、イベント通知などがこれによって示される。データ長には後続するデータの長さが示され、データフィールドには、データ長で示された長さのデータが格納される。設定値のダウンロードやログデータの処理要求には、データフィールドにデータが載せられる。また、カウンタアップロードにおいては、デバイス情報要求に対する応答のデータフィールドに、デバイス情報が載せられる。
【００４３】
以下の手順をはじめ、デバイスセンタサーバ２１０やデバイス監視サーバ２０３ａは、このメッセージを交換しつつ処理を遂行する。なお、以下の説明では、イベントとは、イベントの発生を伝えるためのメッセージという意味で使用している。
【００４４】
＜設定値ダウンロード手順＞
図４は、拠点システムとセンタシステムとの間で行われる、データの交換の手順を説明するためのブロック図である。
【００４５】
設定値のダウンロードは次のようにして行われる。
【００４６】
（１）アプリケーションシステム２０５において、手作業などで、設定対象のデバイスの指定やデバイスのＩＰアドレス、デバイスの拠点デバイスサーバに対するエラー等のアラーム通知の時の閾値の設定値等を入力し、設定値情報ファイル４０１を作成する。
【００４７】
（２）アプリケーションシステム２０５よりデバイスセンタサーバ２１０との間のセッションを確立し、設定値情報ファイル４０１に含まれる設定値データを送信する。
【００４８】
（３）デバイスセンタサーバ２１０は、設定値データを受信すると、デバイス監視サーバ２０３ａとの間でセッションを確立し、デバイス監視サーバ２０３ｂノ対して設定値データを送信する。
【００４９】
（４）デバイス監視サーバ２０３ａは、設定値データを受信するとデバイスに設定値を送りつける。この手順は、デバイスごとに定まった手順で行われる。
【００５０】
（５）デバイスの設定が終了すると、デバイス監視サーバ２０３ａは、デバイスセンタサーバ２１０に対して設定終了を送信する。
【００５１】
（６）デバイスセンタサーバ２１０は、アプリケーションシステム２０５に対して設定終了通知を送信する。
【００５２】
その後、アプリケーションシステム２０５はデバイスセンタサーバ２１０との間のセッションを解放し、デバイスセンタサーバ２１０は、デバイス監視サーバ２０３ａとの間のセッションを解放する。
【００５３】
以上のようにして、デバイス監視サーバ２０３ａとデバイスセンタサーバ２１０とは直接通信することで、デバイスの設定情報をデバイス４０２にダウンロードする事ができる。
【００５４】
なお、障害に関しては次のようになる。
【００５５】
（７）ＰＣ監視クライアント２０３ｄがサーバやＰＣにおいて何らかの障害を検出し、障害イベントを発行する際には、センタサーバ１１０に対して直接イベントを発行する。
【００５６】
（８）また、デバイス監視サーバ２０３ａがデバイス４０２の上述で説明したような障害を検出した場合には、その情報をデバイスセンタサーバ２１０に送信する。
【００５７】
（９）デバイスセンタサーバ２１０は、デバイス４０２における障害の通報を受信すると、それを基に、センタサーバ１１０に対して障害発生を知らせるイベントを発行する。図４のデバイスセンタサーバ２１０には図２のイベントアダプタ２０１ａが含まれる形で記載されおり、イベントアダプタ２０１ａから図４に記載される障害系イベントが発行されることになる。
【００５８】
（１０）イベントモニタ１１０ａは、そのイベントが障害系イベントであるので、イベントコンソールにその障害情報を表示させ、イベントリストを更新する。
【００５９】
このように、障害を通知するイベントは、被管理サイトのどのデバイス系または汎用コンピュータ系で生じても、センタサーバ１１０を通ることになり、管理者は、センタサーバのイベントコンソールを監視するだけで、被管理サイトのすべてのデバイス系の情報または汎用コンピュータ系の情報を監視できる。また、イベントコンソールに表示される情報は、印刷出力されたり、サービスマンの所持する形態端末等に表示されるような処理を施されることも考えられる。印刷された情報は、被管理者宛に郵送で送られたり、サービスマンの形態端末に表示された情報はサービスマンの派遣等に利用することができる。
【００６０】
また、電子メール等の情報通信ツールを使用して、コンソールに表示されたデータを、どのようなエラーが何時、どのくらいの頻度で発生したか等の統計データにして被管理サイト側のサーバ等に送信することも本システムによっては行われることが考えられる。例えば、デバイス監視サーバ２０３ａ内のデータベースに上述で説明したような通信手順で統計データを表すファイルをダウンロード／記憶して、管理者のＰＣ等の表示画面でＷｅｂブラウザ等のアプリケーションを利用し、ＵＲＬを指定して記憶された統計データを閲覧するような形態が考えられる。また、アプリケーションシステム２０５等のサービスセンタからインターネット上に存在する外部サーバ等に前記統計データをアップロードすることにより被管理者サイトの者が閲覧できるようにすることも本発明によって可能である。このようにデバイス系と汎用ＰＣ／サーバ系を一元管理された情報を様々な形態で応用する場面が想定される。
【００６１】
前述の記載では、デバイス系の障害を図４中のイベントモニタ１１０ａを介してイベントコンソール１１０ｂに表示させることについて説明してきたが、本名発明の特徴として、デバイス系で発生した全ての障害情報をイベントコンソール１１０ｂに表示するわけではないことが挙げられる。すなわちデバイス機器の障害のレベルによってデバイスセンタサーバ２１０に情報を送信するか否かの判断処理を行う機能を本システムは有する。
【００６２】
例えば、複写機等におけるドアオープンエラー、デバイス機器のパワーオン／オフ機能によるリセットで回復できるようなエラーに関してはデバイス監視サーバ２０３ａはデバイスセンタサーバ２１０にエラー通知を行わない。一方、センタサーバに通知されてくる情報のうちでも、顧客先で顧客による対応がとれるエラー、例えば、デバイスの温度上昇等の現状動作に支障の無いエラー、ジャムエラー）に関しては、サービスマンの呼び出し等を行わない。
【００６３】
これら、センタサーバへ障害を通知するか否かの判断機能データベースは監視データベース２０３ａ−１、デバイス４０２、等のデバイス側の機器のいずれかに記憶されていれば、デバイス側からセンタ側に情報を通知するか否かの判断を行うことができる。
【００６４】
また、センタサーバ１１０に通知されてきた障害情報をイベントコンソール１１０ｂに表示するか否か、または、サービスマンに連絡するか否かの判断機能データベースはセンタサーバ側のアプリケーションシステム２０９、インベントリデータベース１０９、センタサーバ１１０等の機器のいずれかに記憶されていれば、本発明の機能を達成することはできる。
【００６５】
これらの情報伝達に伴うフィルタリング機能を本システムは有することにより、拠点側−センタ側間のトラフィック量の軽減、また、センタ側で管理する管理者にとって、重大なエラー情報をより明確且つ容易に認識することが可能となる。
【００６６】
＜カウンタアップロード手順＞
カウンタ値のアップロード、すなわちデバイス情報の収集は次のようにして行われる。カウンタ値とは、複写機やプリンタにおいて印刷したページ数を示す値、デバイスの各種モードがどれほど使用されたかを示すモードカウンタ等であり、保守料金算定の基本となる値である。これをセンタシステムからの要求に応じてアップロードすることで、遠隔サイトからのカウンタ値をはじめとするデバイス情報の取り込みを可能とする。カウンタのアップロードはアプリケーションからの要求に応じて行われるために、センタシステム（管理サイト）がイニシエータとなる。
【００６７】
（１）アプリケーションシステム２０５よりセッションを確立し、デバイス情報要求をデバイスセンタサーバ２１０に対して送信する。デバイス情報要求には、拠点システムにおける対象デバイスを指定する情報等が含まれている。
【００６８】
（２）デバイスセンタサーバ２１０は、デバイス情報要求を受信すると、デバイス監視サーバ２０３ａとの間でセッションを確立し、デバイス監視サーバ２０３ａに対してデバイス情報要求を送信する。
【００６９】
（３）デバイス監視サーバ２０３ａは、デバイス情報要求を受信すると、デバイス情報を指定されたデバイスから取得する。この手順は、デバイスごとに定まった手順で行われ、デバイスごとに定まった情報、あるいは指定された情報が取得される。
【００７０】
（４）デバイス情報を取得すると、デバイス監視サーバ２０３ａは、デバイスセンタサーバ２１０に対して取得したデバイス情報を含むデバイス情報応答を送信する。
【００７１】
（５）デバイスセンタサーバ２１０は、アプリケーションシステム２０５に対してデバイス情報応答を送信する。
【００７２】
その後、アプリケーションシステム２０５はデバイスセンタサーバ２１０との間のセッションを解放し、デバイスセンタサーバ２１０は、デバイス監視サーバ２０３ａとの間のセッションを解放する。
【００７３】
以上のようにして、デバイス監視サーバ２０３ａとデバイスセンタサーバ２１０とは直接通信することで、デバイス情報を取得することができる。
【００７４】
なお、障害に関しては設定値のダウンロードと同じ要領で行われる。
【００７５】
＜ログデータアップロード手順＞
ログデータのアップロードは次のようにして行われる。ログデータとは、たとえば周辺装置において発生した警告やリトライの情報などが履歴で、それらの警告が所定回数以上に達するなど、エラーに至らないまでも、何らかの異常事態が発生しつつあることが予想される場合にそれを管理サイトに自発的に送信する。したがって、ログデータのアップロードはカウンタのアップロードとは異なり、被管理サイト（拠点システム）がイニシエータとなる。
【００７６】
（１）デバイス監視サーバ２０３ａがデバイスのログを収集する。その量が所定値を越えたり、警告の発生頻度が所定の率を超えた場合には、デバイス監視サーバ２０３ａはログデータのアップロードを開始する。
【００７７】
（２）まず、デバイス監視サーバ２０３ａよりセッションを確立し、ログデータを含むログデータ処理要求をデバイスセンタサーバ２１０に対して送信する。
【００７８】
（３）デバイス監視サーバ２０３ａは、ログデータ処理要求を受信すると、デバイスセンタサーバ２１０との間でセッションを確立し、デバイスセンタサーバ２１０に対してログ処理要求を送信する。
【００７９】
（４）デバイスセンタサーバ２１０は、ログデータ処理要求を受信すると、アプリケーションシステム２０５との間にセッションを確立し、ログデータ処理要求を、ログデータを処理するアプリケーションシステム２０５に対して送信する。
【００８０】
（５）アプリケーションシステム２０５は、ログデータ処理要求を受信すると、それと共に受信したログデータを処理し、ログデータ処理応答を、デバイスセンタサーバ２１０に対して送信する。
【００８１】
（６）デバイスセンタサーバ２１０は、デバイス監視サーバ２０３ａに対してログデータ処理応答を送信する。
【００８２】
（７）デバイス監視サーバ２０３ａは、デバイスセンタサーバ２１０との間のセッションを解放し、後処理を行う。後処理においては、ログデータ処理応答が、ログデータの処理が正常に完了したことを示すものであれば、ログデータ消去などを行う。
【００８３】
その後、デバイスセンタサーバ２１０はアプリケーションシステム２０５との間のセッションを解放する。
【００８４】
以上のようにして、デバイス監視サーバ２０３ａとデバイスセンタサーバ２１０とは直接通信することで、ログ情報をアップロードすることができる。
【００８５】
なお、障害に関しては設定値のダウンロードと同じ要領で行われる。
【００８６】
＜デバイスセンタサーバによる処理手順＞
次に、デバイスセンタサーバ２１０、デバイス監視サーバ２０３ａそれぞれにおける処理手順を簡単に示す。図５は、デバイスセンタサーバにおけるメッセージ受信時の処理手順を示すフローチャートである。なお、このメッセージはデバイス監視サーバからのものとは限らず、アプリケーションシステム２０５からも受信する。このメッセージのフォーマットは、図８と異なるものでも良い。いずれにしても、メッセージの発信元を識別可能にできているか、あるいは、発信元に応じて異なるプロセスが実行される。本実施形態では、前者を採用する。
【００８７】
メッセージを受信すると、図５の処理が開始される。まず、受信したメッセージを解析し（ステップＳ５０１）、その発行元が判定される（ステップＳ５０２）。発行元は、アドレス等をメッセージに付加しても良いが、その内容によっても識別できる。たとえば、ログ処理要求であれば、その発行元はデバイス監視サーバであり、設定値ダウンロード要求であればアプリケーションシステム（フローチャートではバックエンドと示している）である。
【００８８】
発行元がデバイス監視サーバ２０３ａであれば、それが障害イベントであるか判定し（ステップＳ５０３）、障害イベントであれば、センタサーバ１１０へ処理可能な形式に変換してから転送する（ステップＳ５０４）。センタサーバ１１０においては障害の場所や内容、時刻などがそのメッセージに含まれたデータから読み出され、表示される（ステップＳ５０５）。障害イベントでない場合には、データをバックエンドに渡してメッセージに応じた処理をさせ、メッセージ待ちとなる。バックエンドに渡す処理には、たとえばログデータ処理要求や、収集されたデバイス情報が含まれる。
【００８９】
一方、発行元がバックエンド、すなわちアプリケーションシステムであれば、そのメッセージがデバイス情報の収集要求であるか判定する（ステップＳ５０６）。そうであれば、デバイス情報収集要求をデバイス監視サーバ２０３ａに対して発行し、メッセージ待ちとなる。
【００９０】
デバイス情報収集要求でなければ設定値のダウンロード要求であるかが判定される（ステップＳ５０８）。ダウンロード要求であれば、受信したダウンロード情報を取得し（ステップＳ５０９）、それをデバイス監視サーバ２０３ａに対して発呼する（ステップＳ５１０）。
【００９１】
＜デバイス監視サーバによる処理手順＞
図６は、デバイス監視サーバ２０３ａにおいて発生したイベントに対する処理手順を示すフローチャートである。
【００９２】
何らかのイベントが発生すると、発生したイベントを解析し（ステップＳ６０１）、それがデバイスからの警告であり、所定の閾値を越えていれば（ステップＳ６０２のＹｅｓに対応）、それまでに蓄積したログデータを取得してログデータ処理要求のメッセージを作成し（ステップＳ６０３）デバイスセンタサーバ２１０に対してログ処理要求を発行する。閾値を超えていなければログに蓄積する。
【００９３】
一方、警告でなければ本実施例ではエラーの発生であるとみなして障害イベントを示すメッセージを作成し（ステップＳ６０５）、ステップＳ６０４でデバイスセンタサーバ２１０に送信する。
【００９４】
また、デバイス監視サーバ２０３ａにおける障害イベントには各デバイス装置で使用されているトナー、インク、用紙等の消耗品切れの障害も含まれており、そのような場合には、イベントメッセージを作成したり（ステップＳ６０５）、消耗品切れのログを記憶したりする処理のほかに、在庫監視をするプログラム処理を行うことも本発明では可能である。この処理はＰＣ／サーバ系のＰＣクライアントモジュール２０３ｄへの障害通知、第２の実施の形態での、デバイス装置、デバイス監視サーバ間での障害通知でも同様の処理が行われるものとする。なお、詳細は後述にて説明することにする。
【００９５】
図７は、デバイス監視サーバ２０３ａが、デバイスセンタサーバ２１０から受信したメッセージを受信する手順を示すフローチャートである。
【００９６】
まず、受信したメッセージが設定値のダウンロード要求であるか判定する（ステップＳ７０１）。ダウンロードであれば、受信した設定値データに基づく設定をデバイス監視サーバ２０３ａとデバイス間で行う。（ステップＳ７０２）、拠点プラグイン２０３ｂがそのデータを削除し（ステップＳ７０３）、デバイスセンタサーバ２１０に対してダウンロードが完了した旨の応答メッセージを発行する（ステップＳ７０４）。なお、拠点プラグイン２０３ｂはデバイス監視サーバ２０３ａに論理的に接続されていればよく、接続されていれば物理的に分かれていてもよい。
【００９７】
ダウンロードでなければ、デバイス情報収集要求であるか判定し（ステップＳ７０６）、そうであれば指定されたデバイスから情報を収集して（ステップＳ７０７）、デバイスセンタサーバにそのデバイス情報を送信する（ステップＳ７０８）。
【００９８】
以上の手順により、汎用コンピュータのための管理システムと、周辺装置のための管理システムとによる障害イベントを、管理サイト側においては統合された情報として一元的に管理できる。また、本発明はＰＣ／サーバ系の管理ソフトにデバイス系の管理情報を適合させるものに限定されるものではなく、その逆、即ちデバイス系の管理ソフトにＰＣ／サーバ系の管理情報を適合させるものにすることも可能である。例えば、図２中のイベントアダプタ２１０ａをセンタサーバ１１０に設けて、デバイスサーバで発生したイベントをデバイスセンタサーバ２１０に通知するようにしてもよい。また、更なる別の実施の形態として、デバイスセンタサーバに対応したデバイス系機器用イベントアダプタ２１０aと、センタサーバ１１０に対応したＰＣ／サーバ系機器用イベントアダプタ２１０aとを、夫々に設け、デバイスセンタサーバ２１０で収集されたデバイス系機器固有のフォーマット情報と、センタサーバ１１０で収集されたＰＣ／サーバ系機器固有のフォーマットを夫々、デバイス系機器固有のフォーマット及びＰＣ／サーバ系機器固有のフォーマット以外のフォーマットにして一元管理を実現することも想定される。これにより、デバイス系機器とＰＣ／サーバ系機器を夫々固有のフォーマット（管理システムに対応するフォーマット）で管理することと、その双方を一元的に遠隔で管理することが可能となる。
【００９９】
また、図２に示したように、デバイス監視サーバ２０３ａとデバイスセンタサーバ２０１とを接続する回線と、ＰＣ監視クライアント２０３ｄとセンタサーバ１１０とを接続する回線とを同じ回線とし、ルータ等で共用することで、回線数の節約を図ることもできる。これは回線として専用回線を使用する場合などに有効である。
【０１００】
［第２の管理システム形態］
図を参照して本発明の第２の管理システムを説明する。本実施形態のシステムは、第１の管理システムのそれと比較して、管理サイトと被管理サイトとの間における論理的なチャネルの持ち方において相違する。第１の管理システム形態においては、通信回線を共用することは可能であるものの、デバイス監視サーバ２０３ａとデバイスセンタサーバ２１０とを接続するチャネルと、ＰＣ監視クライアント２０３ｄとセンタサーバ１１０とを接続するチャネルとは、論理的には互いに独立した別個のチャネルである。デバイスセンタサーバ２１０が障害イベントの通知をデバイス監視サーバ２０３ａから受信した場合に、障害の発生を通知するイベントをセンタサーバ１１０に送信することで、イベントモニタにおける障害イベントの一元化が図れられている。
【０１０１】
これに対して本システム形態では、デバイスセンタサーバ２１０も、デバイス監視サーバ２０３ａとデバイスセンタサーバ２０１とを接続するチャネルも存在しない。デバイスセンタサーバの代わりに、デバイス情報処理モジュール９０１がセンタサーバ１１０におかれ（図では別体として示した）、センタサーバ１１０が受信したデバイス系の情報を処理している。この構成においては、市販のＰＣ監視クライアント２０３ｄとセンタサーバ１１０とを用いた場合に、その間に確立されるチャネルに、デバイス系のメッセージも流してしまう。こうすることで、第１実施例で説明したように回線を共通に使用できるメリットの他に、デバイス系の情報のために独立した通信チャネルを用意する必要がなく、デバイスセンタサーバを別途設ける必要もなくなるという効果を得ることができる。
【０１０２】
＜システム構成＞
図９は、本実施形態の管理システムのソフトウエアモジュールの構成を示すブロック図である。ユーザ拠点システム（被管理サイトを指す）は、デバイス系機器（プリンタ、複写機、スキャナー、ＦＡＸ、複合機等の周辺装置）と、ＰＣ／サーバ系機器（汎用コンピュータ）が混在しているが、デバイス系機器はデバイス監視サーバ２０３ａによって、ＰＣ／サーバ系機器はＰＣ監視クライアント２０３ｄによって管理される。この点は第１の管理システム形態と同様である。また、ＰＣ／サーバ系機器、デバイス系機器のそれぞれの構成においても、第１の管理システムで説明したものと同様なものとするので、詳しい説明は省略する。
【０１０３】
センターシステム（管理サイトを指す）は、デバイス監視サーバ２０３ａとの間でデータを交換するデバイス情報処理モジュール９０１と、ＰＣ監視クライアント２０３ｄとの間でデータを交換するセンタサーバ１１０とを含む。デバイス系機器およびＰＣ／サーバ系の管理情報はインベントリデータベース１０９に蓄積される。図９では一つのデータベースとして図示されているが、論理的または物理的にデバイス系とＰＣ／サーバ系のデータベースが分かれていればよい。この情報はアプリケーションシステム２０５、センタサーバ１１０等により利用される。これも第１の管理システム形態と同様である。
【０１０４】
管理サイトと被管理サイトとは、ルータ２０４同士で接続された一本の回線で接続されている。このＰＣ監視クライアント２０３ｄとセンタサーバ１１０とは市販のサイト管理システムで実現できる。すべてのメッセージは、この市販の管理システムにより提供される、ＰＣ監視クライアント２０３ｄとセンタサーバ１１０とで構成されるチャネルを通して送受信される。なお、図９ではデバイス情報処理モジュール９０１が独立してあるものとして（図２のデバイスセンタサーバ２１０に相当）いるが、この機能をセンタサーバ１１０に組み込んで実現することもできる。
【０１０５】
デバイス監視サーバ２０３ａとＰＣ監視クライアント２０３ｄとは、データ形式（フォーマット）や手順（プロトコル）を必要に応じて変換するための拠点プラグインモジュール２０３ｂを介して接続されている。すなわち、デバイス監視サーバの情報をＰＣ監視クライアント２０３ａのフォーマット（またはプロトコル）に変換する機能、その逆の変換の機能を拠点プラグインモジュール２０３ｂは有している。また、センタ側でセンタサーバ１１０とデバイス処理モジュール９０１間でのデータを受け渡しを行うセンタ側のプラグイン（図２のサーバプラグインに相当）に、この拠点プラグインモジュール２０３ｂと同等の機能を持たせることも考えられる。
【０１０６】
この拠点プラグインモジュール２０３ｂは、後述するように、ＰＣ監視クライアント２０３ｄに対してデバイス監視サーバ２０３ａからのメッセージを渡して指定した宛先に送信させると共に、ＰＣ監視クライアント２０３ｄが書き込む所定のデータ領域の内容を定期的にポーリングし検索を行い、デバイス監視サーバ２０３ａ宛のメッセージがあればそれをデバイス監視サーバ２０３ａに渡す役割を有する。
【０１０７】
また、センタサーバ１１０は、受信したメッセージに応じて、そのメッセージの内容がデバイスに係る情報であればデバイス情報処理モジュールに渡して処理をさせるし、イベントの発生を知らせるメッセージであれば、イベントモニタ１１０ａにより発生したイベントをデバイス系のイベントかＰＣ／サーバ系のイベントかを識別可能な表示形態にしてイベントリストとして表示させる。デバイス系のイベントについてはデバイス情報処理モジュール９０１から発生されることになる。
【０１０８】
このように、デバイス系とＰＣ／サーバ系間のフォーマット変換機能を有するプラグインを設ける事により、市販されているＰＣ／サーバ系の管理ソフトの機能を流用することが可能となり、デバイス系の情報を拠点側と管理センタ側で送受信をすることができる。また、市販のＰＣ／サーバ系の管理ソフトでは詳細に管理できないような、デバイス固有の情報に関しても、センタ側で送信されてきたデバイス系のない様に係るデータをＰＣ／サーバ系のフォーマットからデバイス系のフォーマットに変換してからデバイス情報処理モジュールで処理をすればよく、デバイスの情報を詳細に管理したい場合には、デバイス情報処理モジュールのみを独自に開発すればよく、開発／設計の効率を上げる効果を得ることができる。
【０１０９】
次に、拠点システム（被管理サイト）と、センタシステム（管理サイト）との間でなされるメッセージ交換の手順の例を、図１０乃至図１２を参照しつつ、（１）デバイスへの、デバイスセンタサーバ２１０からの設定値のダウンロード、（２）デバイス監視サーバ２０３ａからデバイスセンタサーバ２１０へのログデータのアップロード、（３）デバイスセンタサーバ２１０からデバイス監視サーバ２０３ａへのカウンタデータの要求、という３つのケースで説明する。
【０１１０】
＜設定値ダウンロード手順＞
図１０は、拠点システムとセンタシステムとの間で行われる、デバイスへの設定値のダウンロードの手順を説明するためのブロック図である。設定値のダウンロードは次のようにして行われる。
【０１１１】
まずアプリケーションシステム２０５において、手作業などで、設定対象のデバイスの指定や設定値等を入力し、設定値情報ファイル１００２を作成しておく。
【０１１２】
（１）アプリケーションシステム２０５よりセンタサーバ１１０との間のセッションを確立する。
【０１１３】
（２）センタサーバ１１０において配布モジュール１００１を起動し、設定値情報ファイル１００２から配布用ファイルパッケージ１００１ａを作成する。
【０１１４】
（３）配布モジュール１００１ａは、配布用パッケージファイルをＰＣ監視クライアント２０３ｄに送信し、ワークファイルとして格納させる。
【０１１５】
（４）拠点プラグイン２０３ｂは、ＰＣ監視クライアント２０３ｄが格納するデータファイルを定期的に監視しており、ＰＣ監視クライアントによりワークファイルが作成されたことを検知すると、デバイス監視サーバに設定値の到着を通知すると共に、設定値データをデバイス監視サーバ２０３ａに渡す。デバイス監視サーバ２０３ａは、指定されたデバイスに、設定された値を設定する。
【０１１６】
（４−２）拠点プラグイン２０３ｂは、ＰＣ監視クライアント２０３ｄを介してセンタサーバに設定が終了したことを通知する。
【０１１７】
（５）センタサーバ１１０では、配布モジュール１００１により、配布用パッケージファイル１００１ａを削除させる。
【０１１８】
（６）センタサーバ１１０は、アプリケーションシステム２０５に対して設定の終了を通知する。
【０１１９】
以上のようにして、デバイス監視サーバ２０３ａに設定データを渡すことで、デバイスの設定情報をデバイスにダウンロードすることができる。
【０１２０】
なお、デバイス系で発生した障害に関しては、上記手順（４−２）と同様にして拠点プラグイン２０３ｂからＰＣ監視クライアント２０３ｄを介してセンタサーバ１１０に障害イベントとして送信する。このために、障害を通知するイベントは、センタサーバ１１０のイベントモニタ１１０ａで処理され、イベントのリストに表示される。
【０１２１】
＜カウンタアップロード手順＞
図１１は、拠点システムとセンタシステムとの間で行われる、カウントデータのアップロード、すなわちデバイス情報収集の手順を説明するためのフローチャートである。デバイス情報のアップロードは次のようにして行われる。
【０１２２】
（１）アプリケーションシステム２０５は情報要求コマンドをファイルに格納し、センタサーバ１１０に対して情報収集のきっかけとなるメッセージ（イベント）を発行する。
【０１２３】
（２）アプリケーションシステム２０５からのイベントをイベントモニタが解析し、配布モジュール１００１を起動して、情報要求コマンドの配布用ファイルパッケージ１００１ａを作成する。
【０１２４】
（３）センタサーバ１１０は、作成した情報要求コマンドを含む配布用パッケージをＰＣ監視クライアント２０３ｄに対して送信する。ＰＣ監視サーバ２０３ｄは受信したファイルをワークファイルとして格納する。なお、ワークファイルはＰＣ／サーバ管理システムでの汎用ファイルなるもので、配布用ファイルパッケージ１００１ａの実態に該当するものである。
【０１２５】
（４）拠点プラグイン２０３ｂは、ＰＣ監視サーバ２０３ｄがファイルを格納したことを検知すると、それを呼んでデバイス監視サーバ２０３ａに渡す。デバイス監視サーバ２０３ａは、それを受けて指定されたデバイスから、デバイス情報を収集して拠点プラグイン２０３ｄに渡す。
【０１２６】
（５）拠点プラグイン２０３ｂは、受信したデバイス情報を、所定の形式のファイル２０３ｅとして格納する。本実施例では以下に所定の形式としてＭＩＦ形式を例に説明を進めていくが、ＭＩＦ形式とは情報管理系の一般的なファイル形式を指す。
【０１２７】
（６）拠点プラグイン２０３ｂは、ワークファイルを削除する。
【０１２８】
（７）拠点プラグインは、ＭＩＦファイルを作成した旨のイベントを作成してセンタサーバ１１０に送信する。
【０１２９】
（８）センタサーバ１１０はそのイベントを受け、配布用ファイルパッケージを削除する。
【０１３０】
（９）また、センタサーバ１１０は、拠点プラグイン２０３ｂから受信したイベントが、正常な情報収集の完了を通知するものであれば、共通情報収集モジュール１１０２を起動し、拠点プラグインの作成したＭＩＦファイルを読み込ませてデバイス情報を収集させる。
【０１３１】
（１０）共通情報収集モジュール１１０１は、ＭＩＦファイル２０３ｅを読み、収集したデバイス情報を獲得する。
【０１３２】
（１１）共通情報収集モジュール１１０１は獲得したデバイス情報をインベントリデータベースに格納する。なお、インベントリデータベースは物理的または論理的にデバイス機器系とＰＣ／サーバ機器系のデータベースとをそれぞれ有しており、対象機器に応じて柔軟な処理を行うことができる。
【０１３３】
（１２）センタサーバは拠点側のＭＩＦファイル２０３ｅを削除させる。
【０１３４】
（１３）アプリケーションに完了通知を送信する。
【０１３５】
以上のようにして、デバイス監視サーバ２０３ａが収集したデバイス情報をセンタサーバ１１０に取得することができる。
【０１３６】
＜ログデータアップロード手順＞
図１２は、拠点システムからセンタシステムへのログデータのアップロード手順を説明するためのフローチャートである。ログデータのアップロードは本実施形態では次のようにして行われる。
【０１３７】
（１）デバイス監視サーバ２０３ａは、拠点プラグインに２０３ｂに対して、エラーや警告、それらの回数が閾値を超えたことを検知した旨の通知を発行する。
【０１３８】
（２）デバイス監視サーバ２０３ａは、拠点プラグインに２０３ｄに対して前述した警告のイベントデータ発行する。
【０１３９】
（３）拠点プラグイン２０３ｂは、ログデータを、ＭＩＦ形式のファイル２０３ｅとして格納する。ＭＩＦ形式とは、前述で説明したとおり、情報管理系の一般的なファイル／データ形式である。
【０１４０】
（４）拠点プラグイン２０３ｂは、ＭＩＦファイルを作成した旨のイベントを作成してセンタサーバ１１０に送信する。
【０１４１】
（５）センタサーバ１１０はそのイベントを受け、共通情報収集モジュール１２０１を起動する。
【０１４２】
（６）共通情報収集モジュール１２０１は、拠点プラグイン２０３ｂの作成したＭＩＦファイル２０３ｅを読み込ませてログファイルを読む。
【０１４３】
（７）共通情報収集モジュール１１０１は、獲得したデバイス情報をインベントリデータベース１０９に格納する。
【０１４４】
（８）センタサーバは拠点側のＭＩＦファイル２０３ｅを削除させる。
【０１４５】
（９）アプリケーションに完了通知を送信する。
【０１４６】
以上のようにして、デバイス監視サーバ２０３ａが作成したログデータファイルをセンタサーバ１１０は取得することができる。
【０１４７】
＜デバイスセンタサーバによる処理手順＞
次に、センタサーバ１１０、デバイス情報処理モジュール９０１、拠点プラグイン２０３ｂ、ＰＣ監視クライアント２０３ｄによる処理手順を簡単に示す。図１３は、センタサーバ１１０におけるイベント受信時の処理手順を示すフローチャートである。イベントを受信すると、図１３の処理が開始される。なお、以下の説明において、メッセージとイベントは厳密に区別されていない。イベントとは、イベントの発生を伝えるメッセージ、という意味で使用している。
【０１４８】
まず、受信したイベントを解析し（ステップＳ１３０１）、その発行元が判定される（ステップＳ１３０２）。発行元がＰＣ監視クライアント２０３ｄであれば、イベントモニタにより処理されて、障害イベントであればイベントリストに表示される（ステップＳ１３０３）。
【０１４９】
そのあとで、イベントがデバイス系であるか否か、すなわちそれが拠点プラグイン２０３ｂから発行されたものか否かが判定され（ステップＳ１３０４）、デバイス系であれば、イベントごとに応じてデバイス情報処理モジュールにより処理が行われる。この手順が図１４乃至図１６に示されている。デバイス系でなければ、センタサーバ１１０によりイベントに応じた処理が行われる。
【０１５０】
一方、イベントの発行元がバックエンド、すなわちアプリケーションシステムであれば、そのイベントが情報収集を行わせるためのものかが判定され（ステップＳ１３０５）、そうであれば、情報収集要求を拠点プラグインモジュール２０３ｂに対して発行する（ステップＳ１３０９）。情報収集要求は、その要求を行うための配布モジュール１００１に配布用ファイルパッケージを作成し、それを配布させて行わせる。
【０１５１】
情報収集要求のイベントでなければ、ダウンロードを要求するためのイベントであるか判定する（ステップＳ１３０６）。そのイベントでもなければ、イベントに応じた処理をおこなってイベント待ちとなる。
【０１５２】
ダウンロード要求の場合には、ダウンロードするデータをバックエンドから獲得し（ステップＳ１３０７）、ダウンロードデータを拠点プラグイン２０３ｂに対して配布する（ステップＳ１３０８）。
【０１５３】
＜デバイス情報処理モジュールによる処理手順＞
図１３のステップＳ１３０４でデバイス系と判定されたイベントは、更に詳細に分析されて、（１）ダウンロード終了の通知イベント、（２）デバイス情報収集終了のイベント、（３）ログデータアップロードの要求のイベント、という３種の処理に分岐する。これらの処理は、それぞれ図１４乃至図１６のフローチャートの手順となる。
【０１５４】
（ダウンロード終了）
図１４は、デバイス情報処理モジュール９０１による、ダウンロード終了イベントに対する処理手順を示すフローチャートである。ダウンロードの終了が通知されると、まず配布ファイルパッケージ１００１ａを削除し（ステップＳ１４０１）、ダウンロードが終了したことをバックエンドに通知する（ステップＳ１４０２）。
【０１５５】
（デバイス情報の取得）
図１５は、デバイス情報処理モジュール９０１による、デバイス情報取得（カウンタアップロード）の通知に対する処理手順を示すフローチャートである。
【０１５６】
まず、情報収集要求のために作成した配布用ファイルパッケージ１００１ａを削除する（ステップＳ１５０１）。次に、データの取得が正常に行われていれば、情報収集モジュール１１１０１を起動し（ステップＳ１５０３）、デバイス監視サーバ２０３ａに対してデバイス情報の格納されたＭＩＦファイルを要求し、それに対する応答であるＭＩＦファイルを受信する（ステップＳ１５０４）。
【０１５７】
そして受信したファイルをインベントリデータベース１０９に格納し（ステップＳ１５０５）、デバイス管理サーバ２０３ａに対してＭＩＦファイルの削除を要求する（ステップＳ１５０６）。最後にバックエンドに対してデバイス情報の収集が終了したことを通知する（ステップＳ１５０７）。
【０１５８】
一方、ステップ１５０２で正常でないと判定された場合には、その旨をバックエンドに対して通知する（ステップＳ１５０８）。
【０１５９】
以上のようにして、ＭＩＦファイルとして作成されたデバイス情報をデバイス管理サーバ２０３ａから取得する。
【０１６０】
（ログデータアップロード）
図１６は、デバイス情報処理モジュール９０１による、ログデータアップロードの通知に対する処理手順を示すフローチャートである。
【０１６１】
ログデータをアップロードする通知を受けると、共通情報処理モジュール１２０１を起動し（ステップＳ１６０１）、ログデータを含むＭＩＦファイルの送付要求をデバイス監視モジュール２０３ａに発行する（ステップＳ１６０２）。
【０１６２】
その要求への応答であるＭＩＦファイルを受信し（ステップＳ１６０３）、それをインベントリデータベース１０９へ格納する（ステップＳ１６０４）。ＭＩＦファイルの削除要求をデバイス監視サーバ２０３ａに対して発行し（ステップＳ１６０５）、それらの処理が終了すると処理終了の旨をバックエンドに通知する（ステップＳ１６０６）。
【０１６３】
＜デバイス監視サーバによる処理手順＞
図１７は、拠点プラグイン２０３ｂにおいて、プラグインに対して発行されたメッセージあるいはイベントに対する処理手順を示すフローチャートである。なお、センタサーバ１１０から拠点プラグイン２０３ｂにあって発行されたメッセージは、監視クライアント２０３ｄにより所定の領域に格納されるために、拠点プラグイン２０３ｂはそれを常時あるいは一定時間おきに監視し続けている。
【０１６４】
メッセージがあると、それがデバイス監視サーバ２０３ａからのメッセージであるか判定し（ステップＳ１７０１）、そうであれば、メッセージを解析して（ステップＳ１７０２）、警告や閾値越えであれば、ログデータをＭＩＦファイルとして書き出し、ＰＣ監視クライアント２０３ｄを介して、ログファイルのアップロードを行う旨、センタサーバ１１０にあててイベントを発行する（ステップＳ１７０５）。
【０１６５】
警告や閾値越えではない場合には、エラーであるか判定し（ステップＳ１７０６）、エラーであれば障害イベントを示すメッセージを作成してステップＳ１７０５へ分岐する。（ステップＳ１７０７）。
【０１６６】
デバイス監視サーバ２０３ａからのメッセージでない場合には、センタサーバ１１０からのメッセージであると判定して、ＰＣ監視クライアント２０３ｄにより書き出された所定の領域を読み出し（ステップＳ１７０８）、そのデータを解析して内容に応じた処理を遂行する。この解析した内容に応じた処理の詳細が図１８に示されている。
【０１６７】
図１８は、拠点プラグイン２０３ｂによる、センタサーバ１１０１から受信したメッセ維持に応じた処理の手順を示すフローチャートである。
【０１６８】
まず、それがダウンロードデータであるか判定し（ステップＳ１８０１）、ダウンロードデータであれば、デバイス監視サーバ２０３ａに対してダウンロードデータの受信を通知し（ステップＳ１８０２）そのデータを渡す（ステップＳ１８０３）。そして、渡し終えたデータを削除し（ステップＳ１８０４）、センタサーバにあててダウンロード完了イベントを発行する（ステップＳ１８０５）。
【０１６９】
ダウンロードデータでない場合には、デバイス情報の収集要求であるか判定し（ステップＳ１８０６）、そうであれば、デバイス監視サーバ２０３ａに対してデバイスデバイス情報の収集を要求する（ステップＳ１８０７）。
【０１７０】
それに応えてデバイス監視サーバ２０３ａからデバイス情報を受信すると（ステップＳ１８０８）、それをＭＩＦファイルとして格納し（ステップＳ１８０９）、デバイス情報を収集した旨のメッセージをセンタサーバ１１０にあてて発行する。
【０１７１】
＜ＰＣ監視クライアントによる処理手順＞
図１９は、ＰＣ監視クライアントがメッセージを受信した場合の処理手順を示すフローチャートである。
【０１７２】
図１９において、受信データの宛先がどこであるか判定し（ステップＳ１９０１）、ＰＣ／サーバといった汎用コンピュータにあてたデータであれば、指定されたプロセスへとそのデータを渡し（ステップＳ１９０２）、拠点プラグインであれば、前述した所定の領域へとデータを書き込む。
【０１７３】
以上のように、本実施形態のシステムでは、汎用コンピュータ用の監視システムを用いて、監視対象の汎用コンピュータと同じ被管理サイトに設置された周辺機器をも管理することができる。これにより、管理サイトにおいては、汎用コンピュータと周辺機器とを同様な方法で一元的に監視することができる。さらに、周辺機器に関する情報の収集や、パラメータの設定等を、その監視システムを通して管理サイト側から行える。また、被管理サイト側から、ログを管理サイトに対して送信することができる。
【０１７４】
さらに、汎用コンピュータ用の監視システムに対して、周辺機器を管理するために付加するモジュールは、すべてソフトウエア的に実現できるために、そのためのハードウエアを必要とせず、設置面積や機器の費用、維持作業等、ハードウエア的な規模の増大を防止できる。
【０１７５】
また、本発明は汎用コンピュータ（ＰＣ／サーバ系）の管理ソフトにデバイス系の管理情報を適合させるものに限定されるものではなく、その逆、即ち周辺機器（デバイス系）の管理ソフトにＰＣ／サーバ系の管理情報を適合させるものにすることも可能である。
【０１７６】
[第３の管理システム形態]
以下、上述で説明したような第１、第２の管理システムを応用したサービス形態及び消耗品の管理システムの例を説明する。
【０１７７】
図２０は図２に示される拠点側システムの詳細およびセンタシステムを示したものである。まず、ユーザ拠点システム２００１について説明する。
【０１７８】
複写機Ａ２００４および複写機Ｂ２００７は複写機の機種またはタイプを示す。プリンタ、パーソナルコンピュータ、サーバ等に関してもＡ、Ｂはそれぞれ機種またはタイプを示すものである。また、管理者ＰＣ２０１６はネットワーク２０１７上に接続されたサーバＡやパーソナルコンピュータＡ等のＰＣ／サーバ系機器や、プリンタＡ等のデバイス系機器を管理を行なう装置である。尚、サーバＡ、及び、サーバＢは論理的に夫々の機能を有した装置であれば、物理的に１つの装置でも本願発明の目的は達成される。
【０１７９】
また、管理者ＰＣ２０１６はサーバＡ、サーバＢとの情報の送受信も行う。なお、管理者ＰＣ、パーソナルコンピュータＡ、サーバＡ等の機器の構成の詳細は図３に記載したものとであるが、さらに、ＨＤの容量が一杯になり、さらにＨＤの容量の追加等が必要であることを検知する検知手段等も備えている。
【０１８０】
また、ネットワーク２０１７はＬＡＮ等のネットワーク線を示すものであるが、ＰＣ／サーバ系機器や、その周辺機器であるデバイス系を赤外線、ブルートゥ―ス等の無線通信を介して接続されるような形態も本発明に適応可能であることは言うまでもない。この無線通信を適応する場合は図３４のＬＡＮ制御部８が無線通信制御部の役割を行う機能を有することとなる。また、そのような場合にプリンタＡ等のデバイス系機器も無線機能を備えることになる。
【０１８１】
ここで、ユーザ拠点システム２００１は図２のユーザ拠点システムに、ネットワーク２００２は図２のネットワークに、センタシステム２００３は図２のセンタシステムに、複写機Ａ２００４、プリンタＡ等は図２のデバイス系に、パーソナルコンピュータ、管理者ＰＣ等はＰＣ／サーバ系に、サーバＡ２０１１は図２のデバイス監視サーバ２０３ａに、サーバＢは図２のＰＣ監視クライアントモジュール２０３ｄに、それぞれ対応している。また、図２０に示されていない図２に対応したその他の構成については先に説明を行なったので、省略するが、ここでは、そのような構成をも備えるものと想定して、以下説明を行なう。
【０１８２】
また、ネットワーク２００２に関しても、ネットワーク２０１７で説明したように、ユーザ拠点システム２００１、センタシステム２００３、金融機関２０２３、物流機関２０２４のそれぞれを、有線、無線等の通信方式により接続している。尚、金融機関２０２３、物流機関２０２４とは夫々の機関に設けられた情報処理装置を指すものとする。
【０１８３】
また、図示はされてはいないが、複写機Ａ、ＢやプリンタＢ等のデバイス系機器は、印刷制御部機能、ネットワーク通信部機能、ＨＤ（ハードディスク）、消耗品切れ等のエラー検知センサ部等の機能を備えている。詳細に関しては通常の技術を使用しているので省略することにする。また、パーソナルコンピュータＡ等のＰＣ／サーバ系機器はメモリ（ＲＡＭ、ＨＤ含む）、またノート型ＰＣの場合には、バッテリー等の消耗品のエラーを検知するエラー検知センサ部を有している。
【０１８４】
さらに、デバイス系機器、ＰＣ／サーバ系機器の双方において、エラーが検知され、該情報(消耗品切れを含む)をサーバＡ、サーバＢに通知する際に、エラー情報に加えて、自装置（情報の通知元の装置）を特定するための装置特定情報を付加して通知を行う。この装置特定情報はそれぞれの機器の内部メモリ等に記憶されたものである。機番／シリアル番号、ＭＡＣアドレス、ＩＰアドレスが該情報に相当する。また、消耗品に備え付けられた不揮発性メモリに記憶された消耗品の消耗品型番号も、装置特定情報として挙げられる。この装置特定情報を受信したサーバＡ、または、サーバＢには該装置特定番号、または、消耗品型番号から、装置機器の種類、または、消耗品の品番／タイプを特定することができるデータベースを記憶部に記憶している。該データベースと通知されてきた自装置特定番号、または、消耗品型番号とを比較／参照することにより、デバイス系機器、ＰＣ系機器のうちから、どの装置で使用する消耗品が消費されたかを認識することができる。このデータベースの一例を図２３に示す。詳細は後述にて説明を行なう。また、通信の手順は上述にて説明を行ったので、ここでは省略することとする。
【０１８５】
次にセンタシステム２００３について説明する。このセンタシステム２００３では、ユーザ拠点システムから送信されてくる情報を基に、ユーザのメンテナンス管理等を行なう。デバイスセンタサーバ２０１８はユーザ側のデバイスに関する情報を収集／管理するものである。また、センタサーバ２０２０はユーザ拠点側のＰＣ／サーバ系に関する情報の収集／管理を行なうものである。そしてこれらの情報はインベントリデータベース２０２１に格納／記憶され管理される。
【０１８６】
また、アプリケーションシステム２０２１、基幹システム２０２５ではデバイスセンタサーバ２０１８や、センタサーバ２０２０で収集された情報を基に、サービスマンの派遣等を行なう機能を備えている。
【０１８７】
また、基幹システム２０２５はセンタシステム２００３と金融機関２０２３と物流機関２０２４との情報の窓口の機能を有している。
【０１８８】
尚、図２０では、デバイスセンタサーバ、センタサーバ、インベントリデータベース、アプリケーションシステム、機関システムは同一の拠点にあるように記載されているが、物理的に別々の装置であっても、また、ネットワークで接続されることにより、別々の拠点に設置されたものであっても、論理的に１つとみなせれば、本発明の目的を達成することは可能である。
【０１８９】
ここで、デバイスセンタサーバ２０１８、イベントアダプタ２０１９、センタサーバ２０２０、インベントリデータベース２０２１、アプリケーションシステム２０２２はそれぞれ、図２のデバイセンタサーバ２１０、イベントアダプタ２１０a、センタサーバ１１０、イベントリデータベース１０９、アプリケーションシステム２０５にそれぞれ対応するものとする。
【０１９０】
また、金融機関２０２３はユーザ拠点システム２００１、センタシステム２００３との金銭情報の送受信を行う機能を備える。金銭を表す情報としては、電子マネー等が考えられる。また、物流機関２０２４はユーザ拠点システム２００１、センタシステム２００３との物流の役割を担うものであり、それぞれネットワークを介してユーザ拠点システム２００１、センタシステム２０２４とに双方向に接続されている。
【０１９１】
次に、図２１の説明を行う。ユーザ拠点システム、センタシステム側、金融機関、物流機関は図２０に説明したものと同様なので説明は省略する。
【０１９２】
まず、ステップ２１０１ではユーザ拠点システムに設置されたデバイス機器、ＰＣ／サーバ系の機器によって検知された消耗品切れの信号情報が、ユーザ拠点システム側に設置されたサーバＡまたはサーバＢに通知される。この通知はユーザ拠点システムに設置されたプリンタ等の装置毎によって行なわれる。即ち装置に対応した消耗品毎に関して実行される。また、サーバＡおよびサーバＢは先にも説明したように、図２のデバイス監視サーバ２０３ａ、ＰＣ監視クライアントモジュールにそれぞれ対応している。
【０１９３】
次に、Ｓ２１０２で、該信号を受信したサーバＡまたはサーバＢでは、受信した情報を基に、消耗品切れの信号を通知してきた機器を特定するとともに、該特定された機器に使用されている消耗品の品番／タイプをデータベースを利用して特定する。
【０１９４】
Ｓ２１０３では、特定された消耗品の品番／タイプに対する在庫量を、自装置または他装置のデータベースを参照することによって管理する。具体的には、データベースの在庫情報を参照して参照した在庫量から在庫数を減算して、減算した値を再びデータベースに格納する。なお、消耗品切れの信号が一度特定の機器から出力されると、新しい消耗品に交換されたことがデバイス系機器、ＰＣ／サーバ系機器に備わった消耗品交換検知手段により検知されるまで、重複する消耗品切れ信号は出力しないようになっている。なお、消耗品交換検知手段は、例えば消耗品の残量等の変化を認識することにより、消耗品が交換されたことを認識するよな手段である。更に具体的には、消耗品切れ信号がエンプティー状態（ローレベルと呼ぶ）から十分に消耗品残量が残っている状態（ハイレベルと呼ぶ）になった際に、消耗品交換検知手段は、ローレベルからハイレベルに状態が変化し、ハイレベルの状態が十分長い時間継続したことが認識された際に、新たな消耗品が画像形成装置に装着されものと認識する。無論、消耗品検知手段はこれに限定されることなく、様々な方式の仕組みを採用することが想定される。即ち、ユーザ拠点側のプリンタ等のデバイス系機器で生成されるエラー情報や消耗品切れや印刷枚数等を示す稼動状況を示す情報、或は、パーソナルコンピュータやサーバ等のＰＣ／サーバ系機器で生成される情報をサービスセンタ側で一元的に管理するような形態も想定される。
【０１９５】
Ｓ２１０４では該減算した値が予め設定された在庫量の下限値以下か否かの判断処理が行なわれる。判断結果が所定値以下でないと判断された場合には、再び消耗品切れの情報が通知されてくるまで待機処理に入るか、他の処理を行なうか等の通常処理を行なう（Ｓ２１０５）。
【０１９６】
なお、Ｓ２１０２，Ｓ２１０３、Ｓ２１０４は上述ではユーザ拠点システム側に設置されたサーバＡ、サーバＢ等のサーバ装置で処理されるように説明したが、センタシステム側で処理を行うようにすることも可能である。例えばユーザ拠点側のデバイス機器による消耗品切れ信号をネットワークを介してセンタシステム２００３に送信送信するようにすればこれが実現される。
【０１９７】
また、Ｓ２１０４での判断結果が所定値以下であった場合には、発注情報がセンタシステム２００３に自動的に通知（送信）される（Ｓ２１０６）。また、該発注情報を自動的にセンタシステムに通知する前に、管理者ＰＣの表示画面に自動通知を承認するか否かの確認メールを一旦送信し、管理者ＰＣから発注指示があった際に通知（送信）するようにすることも可能である。さらに、本発明においては、発注指示のトリガーを顧客の判断指示を介して、センタシステムに通知することも可能であり、詳細は後述にて説明を行なうのでここでは省略する。
【０１９８】
なお、この発注情報には、顧客を特定する顧客情報の他にも、消耗品切れが起きた機器を特定する情報、発注する消耗品の個数等の情報も含まれている。
【０１９９】
Ｓ２１０７では、Ｓ２１０６の処理により受信した発注情報に含まれる顧客情報に基づいて、顧客の検索を行う。顧客情報の検索は、図２０のセンタシステム側２００３のデバイスセンタサーバ２０１８、アプリケーションシステム２０２２等に格納された顧客データベース等を参照することによって行なわれる処理である。
【０２００】
Ｓ２１０８では、特定された顧客および消耗品の種類および消耗品の個数に基づく商品の配送指示（配送情報）が物流センタに指示（送信）される。この指示は既存の電子メール等を利用することによりなされる処理である。
【０２０１】
Ｓ２１０９では、物流機関２０２４からの商品の納入が行われ、Ｓ２１１０ではＳ２１０９の納品に対する通知が行われる。このＳ２１１０の通知では、物流機関２０２４側のサービスマンが所持する携帯端末等の機器を利用して、実際に納入した商品の数／種類等を物流機関にその場で通知するものである。また、管理者ＰＣ等の装置からの通知であることも本願発明では想定される。
【０２０２】
Ｓ２１１１ではセンタシステムに、物流機関２０２４からユーザ拠点システム２００１側に実際に納入された商品の種類、数量がユーザ拠点システム２００１側から通知される。これは、Ｓ２１０９で実際に納品された商品の種類、納入数等の情報がユーザ拠点サイドにおいて、サーバＡ２０１１や管理者ＰＣ２０１６のキーボード等の入力部から入力された値に基づいて通知される。これは物流機関２０２４からセンタシステムに２００３に通知された実際に納品した商品の種類と数量等の情報（図２２のＳ２２０１）と、ユーザ拠点システム２００１から通知された情報（図２１のＳ２１１１）との比較の際に利用される。これにより、センタシステム２０２３はより正確な納品情報／ユーザ拠点の在庫情報を管理することができる。
【０２０３】
また、Ｓ２１１２では消耗品の回収依頼が行なわれる。またセンタシステムに一旦回収依頼が行なわれ、その後に物流機関に通知される形態も可能である。そして、物流機関のサービスマンによる使用済みの消耗品の回収が行なわれる。また、Ｓ２１１１のタイミングは納品の際のタイミング、それ以外のタイミングが考えられる。
【０２０４】
次に、図２２の説明を行なう。図２２は図２１の続きの処理を示す。図２２のＡ、Ｂ、Ｃはそれぞれ、図２１のＡ（ユーザ拠点システム）、Ｂ（センタシステム側）、Ｃ（物流機関）、に対応する。
【０２０５】
Ｓ２２０２では、Ｓ２２０１やＳ２１１１で受信した情報等を基に、センタシステム側で生成された電子請求書がユーザ拠点システム側に送信されるものである。サーバＡ、または、サーバＢによって受信され、さらに管理者ＰＣにその到着の電信メールが通知される。
【０２０６】
また、通知のされ方としては、インターネット上に設置されたサーバに電子請求書をアップロードする形態にすることも本発明では可能であり、ユーザ拠点システム側に管理者ＰＣにパスワード等を通知するようにして、インターネット上の電子請求書の内容を閲覧することができる。
【０２０７】
Ｓ２２０３では、通知された電子請求書に対するユーザの承認するか否かの情報が生成される。この承認に関する情報には、ユーザを特定するユーザＩＤ情報、さらに、ユーザ毎に関する管理番号等が含まれている。
【０２０８】
Ｓ２２０４では、Ｓ２２０３での承認を否認した場合には、Ｓ２２０３でのＷｅｂブラウザから、拒絶の旨をセンタシステム側に通知する（Ｓ２２０４）。なお、通知手順は後述にて説明を行なうので、ここでは説明を省略する。
【０２０９】
Ｓ２２０３において、承認の情報が生成された場合には、Ｓ２２０６において、Ｓ２２０５での承認の情報に基づいて、顧客を特定し、該顧客の口座情報の検索を行なう。
【０２１０】
Ｓ２２０７ではＳ２２０６の検索結果によって特定された口座情報に基づいて顧客口座かの引き落とし命令を金融機関に発して送信し、Ｓ２２０８ではセンタシステム側に電子マネーの入金が行なわれる。現金の入金方法には現金による通常の入金も考えられる。
【０２１１】
図２３は、ユーザの所有するデバイス装置、ＰＣ／サーバ系装置、および、それらに使用される消耗品を管理する管理データベースの一例である。これらの情報は、ユーザ拠点システムのサーバＡ２０１１、または、センタシステム側の何れかの装置に記憶／格納された情報である。
【０２１２】
２３０１は設置されている機器の機番／シリアル番号を示している。２３０２はＭＡＣアドレス（Ｍｅｄｉａ  ＡｃｃｅｓｓＣｏｎｔｒｏｌａｄｒｅｓｓ）を示している。２３０３はＩＰアドレス（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌＡｄｄｒｅｓｓ）を示している。２３０４は消耗品のＩＤを示しており、このＩＤによって消耗品の種類が特定できる。２３０５は前々回の消耗品の交換日を示しており、各装置毎にその日付が記録されている。２３０６は前回交換日を示しており、２３０５と同様に装置毎に記録されている。２３０７は次回交換予定日であり、該データは、ユーザの過去の消耗品の交換履歴、現在使用されている消耗品の使用率から計算され、表示される。管理者ＰＣ等にインストールされたプログラム、または、サーバＡに記憶されたプログラムによって処理されるものである。また、２３０７の表示は、”あと何日”という表示で発注予定日までの残り日数を表示するようにすることも考えられる。
【０２１３】
図２４は、図２３と同様にサーバＡ、或は、センタシステム側の何れかの装置に記憶／格納されたデータベースを示している。２４０１は消耗品の種類を示しており、２４０２は消耗品毎の在庫量を示している。２４０３は発注閾値を示しており、この閾値以下になると発注をする必要が生じてくるパラメータとなっている。この閾値はデフォルトでサービス提供者側から設定された値であったり、ユーザがそれぞれの消耗品毎に設定した値であったりする。設定を行う際には、図２４のデータを画面に表示させ、該当する欄にキーボード、マウス等の入力デバイスによって入力を行う。そして、この入力された閾値が設定値として記憶される。
【０２１４】
また、２４０４は発注単位を示しており、一度に発注できる消耗品個数を示している。この発注単位を示す情報も２４０３と同様にユーザの入力により設定することが可能である。２４０５は在庫のステータスを示しており、ユーザはこの部分を確認するだけで、各消耗品毎の在庫状況を認識することができる。記載の中で”十分”は在庫が発注する必要のないほど十分にあることを示し、”次回発注”は、まだ在庫に若干の余裕があることを示している。また”発注”とは発注する必要があることを示している。このように複数段階の在庫レベルを設けることにより、管理者はより詳細な在管理を行なうことができ、照応品の種別毎に異なるタイミングで発注を行なえるので、在庫削減等の効果を得ることができる。またセンタサーバ側２００３側において、ユーザ毎の図２３、２４に示されるような情報をサーバＡから要求して受信して記憶して管理することにより、予め消耗品の需要予測を、ユーザ毎、また複数ユーザ全体としてそれぞれ予測することができる。
【０２１５】
図２５は請求書に関する履歴を示しており、請求書ＮＯ２５０１のそれぞれに対して、請求日（２５０２）、承認／否認履歴（２５０３）、承認日（２５０４）、２５０３の承認／否認において、否認した場合にはその否認理由（２５０５）がそれぞれ表示されている。このデータベースも図２３、図２４と同様にサーバＡに記憶されている。
【０２１６】
図２６は管理者ＰＣの画面に表示される表示例である、消耗品在庫が少なくなったこと通知するためのものである。この画面が表示されるまでの流れを説明する。図２４に示される発注閾値２４０３の値に在庫量が減少すると、図２４のデータベースを備えるサーバＡは、管理者ＰＣ装置に対して、このようなメールを生成して送信する。また２６０４の本文に示される。”消耗品「ＤＤＤ−Ｃ」の在庫が残り１個になりました。”とういう文章は、図２７に示される、消耗品の種類と、その種類に対応する発注閾値に基づいて生成される。
【０２１７】
この画面は消耗品の種類毎に表示され、管理者は消耗品毎の在庫量、在庫切れを把握することができるとともに、それぞれの発注を個々に処理することが可能になる。また２６０４に示されている”ｈｔｔｐ：／／ｒｄｓ／ｄｉａｇ／ｃｏｕｓｕｍａｂａｌｅ．ｈｔｍｌ”は消耗品の発注シートを格納しているＵＲＬを示している。このＵＲＬがキーボード、マウス等のポインティングデバイス等に指示されることにより、管理者ＰＣでは、Ｗｅｂブラウザ等を利用して図２７に示すような画面を見ることができる。このＷｅｂブラウザで閲覧することができる表示情報は、サーバＡ２００１のＨＤ（先述に説明した各種データベース等を記憶するハードディスク（ＨＤ）に対応）等に記憶されている。また、センタシステム２００３の何れかの装置のＨＤ等の記憶手段に記憶しておくことも想定される。
【０２１８】
さらに管理者ＰＣから図２７に示されるような表示画面を閲覧するようにできる、専用のアプリケーションを予めインストールしておき、管理者は該アプリケーションを起動されることにより、例えば該アプリケーションシステムの表示画面に表示される”診断ボタン”に対して指示を行なうことにより、図２７に示すような画面を管理者の所望のタイミングで表示できることも本発明では想定される。
【０２１９】
図２７は、消耗品の発注指示画面を示しており、２７０１は消耗品の種類、２７０２から２７０４は図２４の２４０２から２４０５に対応しているため説明は省略する。２７０６は発注指示をかけるための選択ボタンを示しており、発注済み、または、在庫量が十分にある項目に関しては該選択表示がされない、または表示されたとしてもポインティングデバイスによる指示が無効となるように表示される。
【０２２０】
また、消耗品の各種類に対応する発注指示ボタンが選択されることにより、選択された発注指示ボタンに対応する種類の消耗品の発注が行なわれる。
【０２２１】
また、２７０７は２７０６によって発注するよう選択された消耗品の種類と個数を示している。これは先述の選択された発注指示ボタン入力指示に対応する種類の消耗品が表示される。また、この時の発注数量は、図２４等のデータベースが参照して決定され、自動的に表示される。また、ユーザが使用するキーボード等のポインティングデバイスの入力によるものでもよい。
【０２２２】
また、ＯＫボタン２７０８が押されることにより、発注が確定する。また、２７０９が押された場合は発注がキャンセルされ、２７０７の表示がクリアされる。
【０２２３】
図２７のような表示がされることにより、従来では煩雑な作業であった消耗品種別毎の在庫量を把握することを、管理者は容易に行なうことができる。また、消耗品種別毎に発注を適当なタイミングで行なうことができ、消耗品の在庫量を最小限に抑えることができ、在庫スペースを削減することができる。
【０２２４】
図２８はセンタシステム２００３からユーザ拠点システムのサーバＡに送信された請求書データ（図２９）に基づいてサーバＡで生成されたものである。まず図２９の説明を行なう。
【０２２５】
図２９は２８０４内に示されるＵＲＬを選択した際に、表示される認証画面の表示例である。図２９には請求金額内容のほかに２９０５は承認ボタンを示しており、２９０６は否認ボタンを示している。２９０７は否認する場合に否認理由等を入力するための入力欄である。図２９０５、２９０６の承認、または、否認情報が入力されると、その旨がサーバＡ、または、サーバＢに通知され、その後にサーバＡまたはサーバＢから先Ｔなシステム側２００３に通知される。
【０２２６】
また、この否認情報はセンタサーバ側のオペレータがユーザに否認の確認を取る際に利用される。
【０２２７】
また、この図２９は、図２７の発注ボタン２７０８の押下指示により、サーバＡからセンタシステム側にその旨の情報が通知された際に、センタシステム側で生成されたものであり、センタシステム側からユーザ拠点システム側のサーバＡにこの情報が送信される。該情報はユーザが改竄できないようにサーバＡまたはセンタシステム側の何れかの機器で保管される。
【０２２８】
また、この情報がセンタシステム側からサーバＡに送信される際には図２８に示されるような表示情報をサーバＡから管理者ＰＣに通知するためのメールをサーバＡで生成するためのメール生成用情報が含まれている。このメール生用成情報にはユーザ毎に振り分けられた番号、また、特定のユーザ内で振られたユーザ管理番号等が含まれている。この管理者ＰＣへのメール通知が表示された例が図２８である。
【０２２９】
図２８の２８０４に示される”ｈｔｔｐ：／／ｒｄｓ／ｄｉａｇ／１８７９０００４．ｈｔｍｌ”は承認画面にアクセスするためＵＲＬであり、該ＵＲＬを選択することで、ユーザは承認画面移行することができる。また、この認証画面情報はサーバＡに格納されておいる。
【０２３０】
なお、図２８、図２９の２９０８に示される”Ｎｏ．１８７９−０００４”のうち、”Ｎｏ．１８７９”はユーザを管理するためにユーザ毎に振り分けられた番号であり、”０００４”は特定のユーザの中での管理番号である。
【０２３１】
図３０は図２９において認証ボタン２９０５が選択指示された場合に、管理者ＰＣに表示される請求書画面の一例を示すものである。
【０２３２】
図３１は図２９において否認ボタン２９０６が選択された場合に、管理者ＰＣに確認として表示される否認確認表示画面の一例である。図２９において認証した場合に、本来表示される画面に対して管理者ユーザが否認したことを確認できる画面である。
【０２３３】
なお、図３０、３１はセンタシステム２００３、またはサーバＡで生成され保管されるものである。
【０２３４】
図３２は図２０に示された金融機関２０２３、物流機関２０２４、ユーザ拠点システム２００１、センタシステム２００３の間での情報および商品の流れを説明するための図である。ユーザ拠点システムから発注指示がセンタシステム３２０１（図２０のセンタシステム２００３に相当）に通知されると、センタシステム３２０１に物流機関３２０２（図２の物流機関２０２４に相当）に配送指示が送信される。該配送指示を受信した物流機関３２０２はユーザ拠点システム３２０３（図２の２００１に相当）に商品の配送および納品が行なわれる。納品が完了されると、ユーザ拠点システム３２０３からは物流機関３２０２に向けて完了通知が送信される（Ｓ３２０３）。さらに該完了通知を受けた物流機関は、その旨（完了通知）をセンタシステム３２０１に送信する（Ｓ３２０４）。Ｓ３２０４で完了通知を受信したセンタシステム３２０１はユーザ拠点システムに対してＳ３２０５で在庫更新命令を送信し、また、Ｓ３２０６で請求書発行命令を送信する。Ｓ３２０７ではＳ３２０６の請求書発行命令に基づく承認情報（承認または否認）をセンタシステム３２０１に送信する。Ｓ３２０６において、ユーザ拠点システムから承認情報を受信したセンタシステム３２０１は金融機関３２０４に対して、Ｓ３２０８において金額の回収依頼情報を送信する。ユーザからの電子マネー等の入金指示が行なわれると、Ｓ３２０９において、電子マネー等の電子情報の回収（現金の回収に相当）がされる。
【０２３５】
図３２に示すようなシステムにより、消耗品の在庫切れによる機器のダウンタイムを小さくすることができる。
【０２３６】
[第４の管理システム形態]
第４の形態においては、センタシステム側の更なる詳細を交えて説明を行う。
【０２３７】
図３３は、第４の実施の形態におけるユーザ拠点システムとセンタシステム側と物流機関との間の処理を示す。ここで、ユーザ拠点システムとはデバイス監視サーバ２０３ａ或はＰＣ監視クライアント２０３ｄに、或は、双方の機能を有する情報処理装置に相当するものであり。また、センタシステム側とはデバイスセンタサーバ２１０或はセンタサーバ１１０に、或は、双方の機能を有する情報処理装置に相当する。また、物流機関とは前の実施の形態にて説明した物流機関２０２４に設置された情報処理装置を指すものであり、各ステップの処理は、処理の主体となる情報処理装置によるものであり、ユーザ拠点システム、センタシステム、物流機関の情報処理装置に設けられたＣＰＵ（中央演算処理装置）がＲＯＭ、ハードディス等の不揮発性記憶手段に設けられた制御プログラムを読込むことによって実現されるものとする。
【０２３８】
まず、ステップＳ３３０１では、ユーザ拠点システムにおいて、各保守管理処理が実行される。この各種保守管理処理とは、デバイス系機器、或は、ＰＣ／サーバ系機器からエラーや稼動情報をネットワークを介して受信した際に、該受信に連動してデバイス監視サーバ２０３a或はＰＣ監視クライアントが実行する処理を指し、受信した情報がデバイス系機器に利用される在庫管理に係る処理を実行する為の情報なのか、或は、それ以外の処理を行う為の情報なのかの判断が行われる。
【０２３９】
ステップＳ３３０１においてデバイス系機器、或は、ＰＣ／サーバ系機器から受信した情報が、何に関する情報なのかを認識する。在庫関連の処理に係る情報であると判断された場合においては、ステップＳ３３０２では、デバイス系機器から通知された在庫関連に関する少なくとも消耗品の種別を特定することができる情報を含む消耗品切れ情報を受信し認識する。尚、ステップＳ３３０２は実質的にステップＳ３３０１に含めるようになるが、便宜上理解しやすくする為にステップＳ３３０１とは別に説明した。
【０２４０】
そして、ステップＳ３３０３では、受信した情報に基づいて消耗品切れを発生した消耗品の種別と対応するデバイスの検索及び特定処理を実行する。ここで、デバイス系機器から通知されてくる情報としては例えば図２３にて説明したものと同様のもが想定される。そして消耗品切れを発生した消耗品の種別、及び、消耗品切れを発生した対応するデバイスを特定することができる。
【０２４１】
そして、ステップＳ３３０４で、ステップＳ３３０３にて特定した種別の消耗品の在庫が１つ減ると言うことで、消耗品の在庫数を減算する処理を実行する。更に、ステップＳ３３０５ではステップＳ３３０４の対象となった種別の消耗品の在庫数が閾値以下となったか否かの判定処理が実行される。尚、ステップＳ３３０４、Ｓ３３０５の処理は、少なくとも図２１にて既に説明したステップＳ２１０３、Ｓ２１０４と同様の処理を含むものとする。
【０２４２】
そして、ステップＳ３３０５において、対象となる種別の消耗品の在庫数（在庫量）が閾値以下と判定した場合には、ステップＳ３３０６において、少なくとも在庫切れを発生した消耗品の種別とユーザと特定することができるユーザ情報とを含む発注情報が生成され、該生成された発注情報がセンタシステムに通知される。
【０２４３】
次にステップＳ３３０８の処理についての説明を行う、ステップＳ３３０８の処理はセンタシステムの処理に相当し、まず、ユーザ拠点システム（デバイス監視サーバ２０３ａ及び／又はＰＣ監視クライアント２０３ｄ）から通知されてくる情報を所定の通信回線を介して受信する。
【０２４４】
そして、ステップＳ３３０９ではステップＳ３３０８にて受信した情報がデバイス系機器からの情報なのか、或は、ＰＣ／サーバ系機器からの情報なのかの判断を行う。この判断処理は、例えば、通知された通知情報に含まれるデバイス系機器に関する情報なのか、或は、ＰＣ／サーバ系機器に関する情報なのかを示すビットフラグをセンタシステムが参照することによって実現される。
【０２４５】
ステップＳ３３０９にてＮｏと判断された場合、即ちステップＳ３３０８でＰＣ／サーバ形機器からの情報を受信したと判断した場合には、上述にて説明したＰＣ／サーバ系機器に対応する処理を実行する。
【０２４６】
一方、ステップＳ３３０９にてＹｅｓと判断された場合には、更に、その情報が在庫切れ情報か否かを判断する処理を、受信した在庫切れ情報に割り当てられたビット情報の解析等によりステップＳ３３１１にて実行する。尚、ステップＳ３３０９にて、ステップＳ３３０８にて受信した情報がＰＣ／サーバ系機器に関する情報なのか、或は、消耗品の在庫管理に関する情報なのかを判断するようにすることでも、Ｓ３３１１の機能は実現される。このように本実施の形態によれば、ＰＣ／サーバ系機器に関するメンテナス情報と、デバイス系機器に関するメンテナンス情報とを一元管理することが可能になると共に、更に、その中からデバイス系機器に利用される消耗品の在庫管理を効率良く管理することが実現される。また、ＰＣ／サーバ系機器の消耗品情報なども通知されてくることが想定され、その場合には、ステップＳ３３１１と同様に「ＰＣ／サーバ系機器の消耗品切れ通知か？」なる判断処理をステップＳ３３１１の後に挿入して、それに応じた各種サービス処理が想定される。
【０２４７】
そして、ステップＳ３３１１にてＮｏと判断された場合には、即ち在庫管理以外に関する情報（例えば頻度の高い紙ジャム発生警告情報等）であると判断された場合には、ステップＳ３３１２にてデバイス系機器に対応する他の処理を実行する。他の処理としては、例えば、印刷装置の動作調整の為の設定情報の送信などが挙げられる。  一方、ステップＳ３３１１にてＹｅｓと判断された場合には、ステップＳ３３１３にて、発注情報に含まれる顧客を特定する顧客情報より、さらなる顧客の詳細情報（顧客名称、顧客住所等）を検索して、ステップＳ３３１４にて顧客に対応する消耗品切れに対応する情報を、検索された顧客に関連した情報に対応させて表示部に表示させる。尚、ここでの表示部は、上にて説明したイベントモニタ１１０ａ等に相当する。また、ステップＳ３３１３、Ｓ３３１４の処理はステップＳ３３０８の処理の直後に実行するようにも想定される。図３４にステップＳ３３１４に対応する表示様子を示す。
【０２４８】
図３４はセンタシステム側の監視画面の表示様子を示すものである。複数の機器が一元的に管理されている様子を示している。
【０２４９】
３４０１はユーザ拠点システム側からのイベントがセンタシステム側に通知された日時、或いは、ユーザ拠点側で発生した日時を示している。３４０２は図中の「確認書Ｎｏ」は、後述する発注管理番号に対応する。３４０３の「ｅ−Ｂｏｘ  Ｎｏ」は上に説明したデバイス監視サーバ、及び／又は、ＰＣ監視クライアントモジュールを特定することができるユーザ拠点側に設置された監視サーバ（デバイス監視サーバ、及び／又は、ＰＣ監視クライアントモジュール）の識別情報を示すものである。同じユーザであっても大手の顧客である場合には監視サーバを複数個設置している場合などに、どの監視サーバが監視するデバイスやＰＣに異常が発生したかを特定することができる情報である。３４０４は夫々の在庫切れに対してユーザから発注の指示があった場合（ステップＳ３３２１のＹｅｓに対応）に、新たな消耗品の納入処理のステータスを示すものである。これは、後述するステップＳ３３２２の発注フラグＯＮに対応して変化するのみであり、発注フラグがＯＮになっていない場合には、３４０４に示すように「未処理」と示されるよう表示制御が行われ、発注フラグがＯＮの場合で未だ新たな消耗品の納入が完了していない場合には３４０９に示されるように「未納入」となって表示されるよう表示制御が行われる。このように複数のユーザ、複数の機器に対して在庫切れに対するアフターサービスの処理状況をセンタシステム側で一元的に行うことが可能となる。
【０２５０】
３４０５は後述するＳ３３１６の処理に対応する通知方法であり、ＦＡＸ通知と電子メールを切り替え選択することができる。また、３４０７は３４０５にて選択された通知方法に基づく通知の実行であり後述するステップＳ３３１６の処理に対応する。そして、３４０６はステップＳ３３１６の処理に対応する確認メールの内容を編集するための画面に遷移するための指示ボタンであり、図中に示されるリストから所定の「ｅ−Ｂｏｘ  Ｎｏ」に対応するイベントが選択された状態で、この３４０６に対応する指示信号が入力されると、選択された「ｅ−Ｂｏｘ  Ｎｏ」に対応する顧客情報、消耗品種別、数量、など予めデータベースに記憶された対応するデータが検索され、表示される。その表示様子を図３５に示す。
【０２５１】
３５０２には顧客情報が、３５０３には消耗品の種別及び発注数量を示す情報が表示されている。これらの情報は「e-Box No」の情報を基にした対応する、予めをデータベースに格納された情報を示すが、無論、オペレータからの入力指示に応じて例えば、発注数量を変更することも可能である。そして、３５０１のボタンに対応する指示信号が入力されると図３４の画面に戻る。
【０２５２】
また、３４０８はセンタシステム側にユーザ拠点側から通知された過去のイベントを検索する際などに利用される。また、３４１０は図３４のイベントを何に関するイベントなのかを切りかえるための指示ボタンに対応する。「サービス」が選択された場合には紙ジャムなどの機器障害に関する表示がなされ、「切り分け」が選択された場合にはＰＣ/サーバ系機器に関する監視情報がデバイス系機器とは切り分けられた表示される。また、「消耗品」が選択されているような場合には消耗品在庫に関する情報が図３４に示されるように表示される。
【０２５３】
再び図３３のフローチャートの説明に戻ると、ステップＳ３３１５においては、発注フラグがＯＮであるか否かのセンタシステムによる判断処理が実行される。この発注フラグは、少なくとも発注管理番号（例えば、図３４の確認書Ｎｏや、図３６の３６０２）に対応するものであり、この発注管理番号には、発注する消耗品の種別や発注数量、発注日、顧客に関する顧客情報などが対応しており、シリーズに管理される番号になる。無論個々でいうシリーズとは、その都度管理されている番号において重複が無いように管理が行える番号で良い。
【０２５４】
この発注フラグは後述するステップＳ３３２１にて顧客からの発注確認がセンタシステムで認識された場合に「ＯＮ（発注済み）」されるものであり、配送業者やサービスマン等により商品の納品（例えば、後述するステップＳ３３２４等に相当）が行われ、納品を認識することができる情報をセンタシステム側で認識すると発注管理番号に対応させて、発注フラグを完了を示す情報にするよう制御が実行される。この発注フラグの制御の仕組みをセンタシステムに組み込むことで、発注業務が正常に行われたか否かをより効率良く管理することが可能になる。
【０２５５】
そして、ステップＳ３３１５において、Ｎｏと判断されれば、処理をステップＳ３３２１に移行する。一方、ステップＳ３３１５でＹｅｓと判断されれば、処理をステップＳ３３１８に移行する。
【０２５６】
ここで、ステップＳ３３１５において「Ｙｅｓ」と判断されるような場合としては、一度ステップＳ３３２２を経由して発注管理番号に対応して発注フラグが「ＯＮ」になっているにも係らず、未だ商品の納品が行われていない為に、再び在庫切れの状況が重複して発生した場合に相当する。ここで重複して在庫切れの状態が発生するとは、所定の種別の消耗品に関して、一度在庫閾値を下回って（ステップＳ３３０５）、ユーザ拠点システムからセンタシステム側に通知がいっているにも係らず、更に在庫数が減算されてしまい、重複して在庫閾値が下回ったことがユーザ拠点システムからセンタシステムに通知される処理に対応する。このような状態を示す情報をステップＳ３３１８、３３１９、３３２０を介して担当者（担当サービスマン、或は、担当配送業者）に割り当てられた携帯端末に割り当てられた連絡先（例えば、電子メールアドレス）に通知することにより、サービスマンに商品の納入を促すと共に、更に確実に在庫切れを未然に防止できるサービスをユーザに提供することができる。また、図示はされてはいないが、ステップＳ３３２０の通知が実行されることに応じて、配送に対応する顧客であるユーザ先へ並行して通知されるので、新たな配送されるはずの消耗品がなかなか配送されないような場合にも、ユーザはわざわざサービスセンタなどに問い合わせて、配送を早めてもらうよう指示する必要などがなくなり、従来に比べて負荷が軽減する効果を得ることができる。
【０２５７】
図３６に、ステップＳ３３１８〜２０の処理を介してサービスマンの所持する携帯端末（サービスマンの拠点に設置された情報処理装置であることも想定される。）に通知される警告情報の表示様子を示す。ここで、３６０２は発注管理番号を示しており、一度ステップＳ３３２１、３３２２を介して顧客からの発注の承認が確認された際に、センタシステム側のデータベースに管理される情報に相当する。また３６０３は、顧客の発注内容を示すものであり、顧客毎、或は、発注毎に生成される、センタシステムのデータベースに管理された葉中内容情報を閲覧する為の、ＵＲＬを示す。サービスマンはこのＵＲＬを指示することにより、自分の所持する形態端末にて顧客先の発注内容を確認することができる。また、図３６に発注内容、顧客情報などを初めから含ませるような形態も本発明では想定される。用は、在庫切れが発生したことがセンタシステム側にて検出され、それに応じた発注指示がなされ、新たな在庫切れに対応する消耗品配送指示（納入指示）が処理されたにも係らず、在庫切れに対応した種別の消耗品の更なる在庫減少、或いは、消耗品切れがセンタシステム側も通知された際には、配送（納入）の配送担当者（担当サービスマン、或は、担当配送業者）に、至急在庫切れを発生した種別の消耗品の納品を促す通知が、センタシステムによって実行されることを特徴とする。
【０２５８】
そして、ステップＳ３３１６では、ステップＳ３３１４にて特定された顧客の詳細情報（電子メールアドレス等）に基づく確認メールの送信がセンタシステム側からユーザ拠点システムに送信される。ステップＳ３３１６における確認メールの通知先は、予めセンタシステム側で設定されているものであり、ユーザ拠点システム側における管理者が利用する情報処理装置などに割り当てられた電子メールアドレス、或は、デバイス監視サーバ２３０ａやＰＣ監視クライアント２０３ｄに割り当てられたアドレス情報を相当させることが想定される。なお、デバイス監視サーバ２３０ａやＰＣ監視クライアント２０３ｄのアドレスが割り当てられている場合には、確認メールアドレスの通知を受信したデバイス監視サーバ２３０ａやＰＣ監視クライアント２０３ｄから管理者アドレスとして設定された通知先に確認メールアドレスが転送されるようになっている。
【０２５９】
また、ステップＳ３３１６にてユーザ先に送信される確認メールは、例えば上に説明した図２６のような通知情報を相当させることが可能であるが、ユーザが消耗品の発注を確認でき、且つ、発注を承諾できることができる機能を含めた情報であれば、本発明の目的は達成される。
【０２６０】
そして、ステップＳ３３２１では、ステップＳ３３１６にて送信された確認メール（確認を示す情報の送信履歴）の応答がユーザ拠点システムからあったか否かの判定が行われる。ステップＳ３３１５にて確認メールがあったと判定された場合には、ステップＳ３３２３にて、ステップＳ３３２１にてユーザ拠点システムから通知された情報に含まれる消耗品の種別と数量を配送する指示が物流機関（物流機関に設けられた情報処理装置）と担当者（担当サービスマン、或は、担当配送者）の所持する形態端末に電子メール等を介して送信される。それに応じて、以後ステップＳ３３２４〜ステップＳ３３２７の処理が実行される。尚、ステップＳ３３２４〜ステップＳ３３２７の処理については、図２１にて説明したステップＳ２１０９〜Ｓ２１１２の処理と同様とするので、ここでは詳細な説明は省略する。
【０２６１】
また、更なる好適な形態として、Ｓ３３１５、３３１８、３１９、３３２０の処理をステップＳ３３０５のＹｅｓと判断された後に、ユーザ拠点システム側にも実行させることも想定される。その場合は、ステップＳ３３２２で発注フラグが「ＯＮ」と成ったことを、ユーザ拠点システム側に設けられたサーバ（例えば、図１の２０３に相当）に通知し、ユーザ拠点のサーバ側は通知された発注フラグが「ＯＮ」の情報に基づいてステップＳ３３１５、３３１８、３３１９に相当する処理を実行することとなる。また、ユーザ側のサーバには予め消耗品の納入する担当者、或は、センタシステムへの連絡先（電子メールアドレス等）の情報が格納されているものとする。また、発注フラグが「ＯＮ」の情報には、少なくとも在庫切れを発生した消耗品の種別の情報が含まれているものとする。このようにステップステップＳ３３１５、３３１８、３３１９の処理をユーザ側の拠点に実行させることによりセンタシステム側の処理が軽減される効果が得られる。
【０２６２】
［その他の実施の形態］
なお、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても達成される。
【０２６３】
この場合、記憶媒体から読み出されたプログラムコード自体が本発明の新規な機能を実現することになり、そのプログラムコードに記憶した記憶媒体は本発明を構成することになる。
【０２６４】
また、デバイス情報データは、画像処理装置及び画像データ展開装置に内蔵されているＨＤＤ、外部接続されている記憶媒体、画像データ展開装置からアクセス可能なサーバ等に保持されていても構わない。さらに、デバイス情報データはユーザが任意に設定したものを使用することが可能であっても構わない。
【０２６５】
プログラムコードを供給するための記憶媒体としては、例えば、フロッピーディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＤＶＤ−ＲＯＭ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどを用いることができる。
【０２６６】
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）などが、実際の処理の一部または全部を行い、その処理によって前述した実施の形態の機能が実現される場合も含まれる。
【０２６７】
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるャｃ鰍ノ書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。
【０２６８】
本発明を上記記憶媒体に適用する場合、その記憶媒体には、先に説明したフローチャート及び各画面の表示処理及び各種デーベース処理に対応するプログラムコードが格納されることになる。
【０２６９】
【発明の効果】
以上説明したように、本発明によれば、複数種類の印刷装置がオフィス等で使用される場合に、各々の印刷装置に対応した消耗品の種別毎に、在庫管理等の管理を容易に行なうことができる。
【０２７２】
さらには、本発明によれば、新規消耗品の配送等の発注後のサービスをスムースに行うことが可能になる。
【図面の簡単な説明】
【図１】被管理サイトと管理サイトの構成を示すブロック図である。
【図２】本遠隔サイト管理システムのソフトウエアモジュールの構成を示すブロック図である。
【図３】各ＰＣ及びサーバであるコンピュータの構成を示すブロック図である。
【図４】拠点システムとセンタシステムとの間で行われる、データの交換の手順を説明するためのブロック図である。
【図５】デバイスセンタサーバにおけるメッセージ受信時の処理手順を示すフローチャートである。
【図６】デバイス監視サーバ２０３ａにおいて発生したイベントに対する処理手順を示すフローチャートである。
【図７】デバイス監視サーバ２０３ａが、デバイスセンタサーバ２１０から受信したャbセージを受信する手順を示すフローチャートである。
【図８】デバイスセンタサーバ２１０とデバイス監視サーバ２０３ａとの間で交換されるメッセージフォーマットの一例を示す図である。
【図９】本実施形態の遠隔サイト管理システムのソフトウエアモジュールの構成を示すブロック図である。
【図１０】拠点システムとセンタシステムとの間で行われる、デバイスへの設定値のダウンロードの手順を説明するためのフローチャートである。
【図１１】拠点システムとセンタシステムとの間で行われる、カウントデータのアップロード、すなわちデバイス情報収集の手順を説明するためのフローチャートである。
【図１２】拠点システムからセンタシステムへのログデータのアップロード手順を説明するためのフローチャートである。
【図１３】センタサーバ１１０におけるイベント受信時の処理手順を示すフローチャートである。
【図１４】デバイス情報処理モジュール９０１による、ダウンロード終了イベントに対する処理手順を示すフローチャートである。
【図１５】デバイス情報処理モジュール９０１による、デバイス情報取得（カウンタアップロード）の通知に対する処理手順を示すフローチャートである。
【図１６】デバイス情報処理モジュール９０１による、ログデータアップロードの通知に対する処理手順を示すフローチャートである。
【図１７】拠点プラグイン２０３ｂにおいて、プラグインに対して発行されたメッセージあるいはイベントに対する処理手順を示すフローチャートである。
【図１８】拠点プラグイン２０３ｂによる、センタサーバ１１０１から受信したメッセ維持に応じた処理の手順を示すフローチャート。
【図１９】ＰＣ監視クライアントがメッセージを受信した場合の処理手順を示すフローチャートである。
【図２０】サービスシステム全体図の一例。
【図２１】ユーザ拠点システム及びセンタシステム及び物流機関の間でそれぞれ行われる処理手順を示すフローチャートの一例。
【図２２】ユーザ拠点システム及びセンタシステム及び物流機関及び金融機関の間でそれぞれ行われる処理手順を示すフローチャートの一例。
【図２３】データベースの一例。
【図２４】データベースの一例。
【図２５】データベースの一例。
【図２６】在庫切れ警告及び発注案内メールの表示例。
【図２７】発注画面の表示例。
【図２８】承認依頼の画面表示例。
【図２９】電子請求書に対する承認画面の表示例。
【図３０】電子請求書に対する承認の確認画面の表示例。
【図３１】電子請求書に対する否認の確認画面の表示例。
【図３２】ユーザ拠点システム、センタシステム、物流機関、金融機関の間での情報の流れを示す全体図。
【図３３】ユーザ拠点システム、センタシステム、物流機関、の間での処理の流れを示すフローチャート。
【図３４】センタシステム側にイベントモニタ監視画面の表示例。
【図３５】センタシステム側にイベントモニタ監視画面の表示例。
【図３６】配送担当者に対する新たな消耗品納入の催促通知の端末装置における表示例。
【図１】
0004436445.tif 000002
【図２】
0004436445.tif 000003
【図３】
0004436445.tif 000004
【図４】
0004436445.tif 000005
【図５】
0004436445.tif 000006
【図６】
0004436445.tif 000007
【図７】
0004436445.tif 000008
【図８】
0004436445.tif 000009
【図９】
0004436445.tif 000010
【図１０】
0004436445.tif 000011
【図１１】
0004436445.tif 000012
【図１２】
0004436445.tif 000013
【図１３】
0004436445.tif 000014
【図１４】
0004436445.tif 000015
【図１５】
0004436445.tif 000016
【図１６】
0004436445.tif 000017
【図１７】
0004436445.tif 000018
【図１８】
0004436445.tif 000019
【図１９】
0004436445.tif 000020
【図２０】
0004436445.tif 000021
【図２１】
0004436445.tif 000022
【図２２】
0004436445.tif 000023
【図２３】
0004436445.tif 000024
【図２４】
0004436445.tif 000025
【図２５】
0004436445.tif 000026
【図２６】
0004436445.tif 000027
【図２７】
0004436445.tif 000028
【図２８】
0004436445.tif 000029
【図２９】
0004436445.tif 000030
【図３０】
0004436445.tif 000031
【図３１】
0004436445.tif 000032
【図３２】
0004436445.tif 000033
【図３３】
0004436445.tif 000034
【図３４】
0004436445.tif 000035
【図３５】
0004436445.tif 000036
【図３６】
0004436445.tif 000037