JP2006235788A - ネットワークに接続されたデバイスの監視制御 - Google Patents

Abstract

【課題】 デバイスからサーバに所定の監視情報を送信するデバイス管理システムにおいて、デバイスからサーバへのアクセス頻度を低減するとともに、監視情報の送信に伴うネットワークトラフィックの急激な増大を防止する。
【解決手段】 ネットワークに接続された複数のプリンタのうちの特定のプリンタ（代理プリンタ）は、自らの監視情報ファイルと、他のプリンタ（被代理プリンタ）から受信した監視情報ファイルとを、一括して管理サーバにアップロードする。被代理プリンタは、イベントが発生して、監視情報ファイルが生成されるごとに、その監視情報ファイルを、代理サーバに順次送信する。
【選択図】 図４

Description

本発明は、ネットワークに接続されたデバイスの監視制御技術に関するものである。

近年、インターネットや、ローカルエリアネットワークなどのネットワーク技術の普及に伴い、ネットワークに接続されたプリンタなどの複数のデバイスを、ネットワークを介して接続された管理サーバによって管理するデバイス管理システムが提案されている（例えば、下記特許文献参照）。このデバイス管理システムでは、ネットワークに接続された各デバイスは、例えば、各デバイスに内蔵されたネットワークボードによって、デバイスの動作状態など、デバイスに関する所定の監視情報を取得し、それぞれ個別に管理サーバに送信する。監視情報としては、例えば、デバイスをプリンタとした場合、印刷枚数、インクやトナーなどの使用量や、残量、エラー情報等が挙げられる。

特開２００４−１８５３５１号公報 特開２００２−１８９６３８号公報

上述したデバイス管理システムにおいて、管理サーバと、デバイスとの間に、ファイアウォールが設置されている場合には、管理サーバが主体となって、管理サーバから各デバイスに監視情報の送信を要求し、各デバイスから監視情報の収集を行うことができない場合があった。また、各デバイスが主体となって、管理サーバからの要求によらずに、管理サーバに監視情報を送信する場合、管理サーバの管理対象となるデバイスの数が膨大になると、多数のデバイスが、管理サーバに一斉にアクセスして、それぞれ監視情報を一斉に送信し、管理サーバにおける監視情報の処理が滞ったり、不能になったりするおそれがあった。このような課題は、プリンタに限らず、ネットワークに接続された種々のデバイスを、管理サーバによって管理するデバイス管理システムにおいて、共通の課題である。

デバイス管理システムにおいて、高性能な管理サーバを用いることによって、上記課題を抑制することは可能であるが、コストが増大するという新たな課題を招く。また、１つのデバイスが、他のデバイスから監視情報をそれぞれ収集し、一括して管理サーバに送信するようにすれば、デバイスから管理サーバへのアクセス頻度を低減することができるので、高性能な管理サーバを用いることなく、上記課題を解決することが可能である。しかし、この場合、１つのデバイスが他のデバイスから一斉に監視情報を収集すると、ネットワークトラフィックが急激に増大し、ネットワークにおける他の通信に支障が生じるおそれがある。

本発明は、上述の課題を解決するためになされたものであり、デバイスから管理サーバに所定の監視情報を送信するデバイス管理システムにおいて、デバイスからサーバへのアクセス頻度を低減するとともに、監視情報の送信に伴うネットワークトラフィックの急激な増大を防止することを目的とする。

上述の課題の少なくとも一部を解決するため、本発明では、以下の構成を採用した。
本発明のデバイス管理システムは、
複数のデバイスと、該複数のデバイスを管理するための管理サーバとを、所定のネットワークを介して、互いに接続することによって構成されたデバイス管理システムであって、
前記複数のデバイスのうちの特定のデバイスは、該特定のデバイスが前記複数のデバイスに関する所定の監視情報を一括して前記管理サーバに送信する旨の通知を、該特定のデバイス以外の他のデバイスに送信し、
該他のデバイスは、前記通知を受信した後に、前記特定のデバイスとは無関係の所定のタイミングで、該他のデバイスに関する前記監視情報を、前記特定のデバイスに順次送信し、
前記特定のデバイスは、予め設定されたタイミングで、該特定のデバイスに関する前記監視情報、および、前記他のデバイスから受信した前記監視情報を、前記管理サーバに送信することを要旨とする。

デバイスには、例えば、プリンタや、スキャナや、プロジェクタや、オーディオ装置や、家電機器や、クライアントコンピュータや、ＰＤＡ（Personal Digital Assistance）など、ネットワークに接続されて利用される種々の装置が含まれる。

本発明では、他のデバイスは、特定のデバイスが複数のデバイスに関する所定の監視情報を一括して管理サーバに送信する旨の通知を受信した後、特定のデバイスとは無関係の所定のタイミングで、監視情報を特定のデバイスに順次送信する。「特定のデバイスとは無関係の所定のタイミング」とは、例えば、特定のデバイスからの働き掛けによらないタイミング、他のデバイス単独で決まるタイミングを意味している。したがって、デバイス管理システムに多数の他のデバイスが接続されている場合であっても、それらが一斉に監視情報を特定のデバイスに送信することはない。この結果、他のデバイスから特定のデバイスへの監視情報の送信に伴うネットワークトラフィックの急激な増大を防止することができる。

さらに、特定のデバイスは、予め設定されたタイミングで、自らに関する監視情報、および、他のデバイスに関する監視情報を、一括して管理サーバに送信する。「予め設定されたタイミング」とは、監視情報をサーバに送信すべく設定されたタイミングである。こうすることによって、複数のデバイスが個別に管理サーバへアクセスすることがないので、デバイスから管理サーバへのアクセス頻度を低減することができる。

つまり、本発明によれば、デバイスから管理サーバに所定の監視情報を送信するデバイス管理システムにおいて、デバイスから管理サーバへのアクセス頻度を低減するとともに、監視情報の送信に伴うネットワークトラフィックの急激な増大を防止することができる。

なお、本発明のデバイス管理システムにおいて、「特定のデバイス」は固定されておらず、複数のデバイスのうちのいずれかが、適宜「特定のデバイス」として機能したり、「他のデバイス」として機能したりする。

上記デバイス管理システムにおいて、前記所定のタイミングとして、種々のタイミングを適用可能であるが、デバイスが、イベントの発生に応じて、そのデバイスに関する監視情報を生成する場合、
前記所定のタイミングは、前記他のデバイスにおけるイベントの発生に基づくタイミングであるものとしてもよい。

こうすることによって、他のデバイスにおいて、イベントが発生するごとに、順次、監視情報を特定のデバイスに送信することができる。なお、「所定のタイミング」として、例えば、他のデバイスにおいて、監視情報が所定数生成されて溜まるごとのタイミングとしてもよい。

本発明のデバイス管理システムにおいて、
前記複数のデバイスには、該複数のデバイスを識別するための識別情報がそれぞれ付与されており、
前記他のデバイスは、該他のデバイスに関する前記監視情報を、該他のデバイスを識別するための識別情報と関連付けて、前記特定のデバイスに送信し、
前記特定のデバイスは、前記各監視情報を、該各監視情報と対応する前記各識別情報と関連付けて、前記管理サーバに送信するようにすることが好ましい。

識別情報としては、例えば、デバイスに付与された名前や、ＭＡＣアドレスや、ＩＰアドレスや、製造番号などを用いることができる。本発明によって、管理サーバは、各監視情報を出力したデバイスを容易に特定することができる。

本発明のデバイス管理システムにおいて、
前記特定のデバイスは、前記複数のデバイスに関する前記監視情報を、前記管理サーバに送信した後に、前記送信済みの前記監視情報を削除すべき削除要求を、前記他のデバイスに送信し、
前記他のデバイスは、前記特定のデバイスから受信した前記削除要求に応じて、前記送信済みの前記監視情報を削除するようにしてもよい。

こうすることによって、他のデバイスが保持する監視情報は、全て管理サーバに未送信の監視情報となるので、他のデバイスは、後に、「特定のデバイス」として機能する場合になっても、管理サーバに未送信の監視情報を保持しているか否かを容易に判断することができる。

本発明は、デバイスの発明として構成することもできる。すなわち、
本発明のデバイスは、
複数のデバイスと、該複数のデバイスを管理するための管理サーバとを、所定のネットワークを介して、互いに接続することによって構成されたデバイス管理システムに用いられるデバイスであって、
前記複数のデバイスのうちの特定のデバイスから、前記特定のデバイスが前記複数のデバイスに関する所定の監視情報を一括して前記管理サーバに送信する旨の通知を受信する受信部と、
当該デバイスにおけるイベントの発生に応じて、該デバイスに関する監視情報を生成する監視情報生成部と、
前記イベントの発生に基づくタイミングで、前記通知を受信した前記特定のデバイスに、前記生成された監視情報を送信する送信部と、
を備えることを要旨とする。

こうすることによって、デバイス管理システムに多数の他のデバイスが接続されている場合であっても、それらが一斉に監視情報を特定のデバイスに送信することはない。したがって、特定のデバイスへの監視情報の送信に伴うネットワークトラフィックの急激な増大を防止することができる。

上記デバイスにおいて、
前記送信部は、さらに、前記デバイスを識別するための識別情報を、前記監視情報と関連付けて、前記特定のデバイスに送信するようにすることが好ましい。

識別情報としては、例えば、デバイスに付与された名前や、ＭＡＣアドレスや、ＩＰアドレスや、製造番号などを用いることができる。

本発明のデバイスにおいて、さらに、
前記生成された監視情報を記憶する監視情報記憶部と、
前記特定のデバイスから、前記管理サーバに送信済みの前記監視情報の削除要求を受け付ける削除要求受付部と、
該削除要求に応じて、前記監視情報記憶部に記憶されている、前記他のデバイスに送信済みの監視情報を削除する監視情報削除部と、
を備えるようにしてもよい。

こうすることによって、デバイスは、特定のデバイスから受け付けた削除要求に応じて、特定のデバイスが管理サーバに送信済みの監視情報を削除することができる。

本発明は、上述した種々の特徴を必ずしも全て備えている必要はなく、その一部を省略したり、適宜、組み合わせたりして構成することができる。本発明は、上述のデバイス管理システムや、デバイスとしての構成の他、デバイス管理システムの制御方法や、デバイスの制御方法として構成することもできる。また、これらを実現するコンピュータプログラム、およびそのプログラムを記録した記録媒体、そのプログラムを含み搬送波内に具現化されたデータ信号など種々の態様で実現することが可能である。なお、それぞれの態様において、先に示した種々の付加的要素を適用することが可能である。

本発明をコンピュータプログラムまたはそのプログラムを記録した記録媒体等として構成する場合には、デバイス管理システムや、デバイスの動作を制御するプログラム全体として構成するものとしてもよいし、本発明の機能を果たす部分のみを構成するものとしてもよい。また、記録媒体としては、フレキシブルディスクやＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、光磁気ディスク、ＩＣカード、ＲＯＭカートリッジ、パンチカード、バーコードなどの符号が印刷された印刷物、コンピュータの内部記憶装置（ＲＡＭやＲＯＭなどのメモリ）および外部記憶装置などコンピュータが読み取り可能な種々の媒体を利用できる。

以下、本発明の実施の形態について、実施例に基づき以下の順序で説明する。
Ａ．デバイス管理システムの構成：
Ｂ．第１実施例：
Ｂ１．プリンタの構成：
Ｂ２．プリンタの動作処理：
Ｂ３．ファイル収集処理：
Ｂ４．アップロード処理：
Ｃ．第２実施例：
Ｄ．第３実施例：
Ｅ．第４実施例：
Ｆ．変形例：

Ａ．デバイス管理システムの構成：
図１は、本発明の一実施例としてのデバイス管理システム１０００の概略構成を示す説明図である。このデバイス管理システム１０００は、企業内のローカルエリアネットワークＬＡＮと、管理センタの管理サーバＳＶとを、インターネットＩＮＴを介して接続することによって構成されている。ローカルエリアネットワークＬＡＮと、インターネットＩＮＴとの間には、ファイアウォールＦＷが設置されており、インターネットＩＮＴ側からローカルエリアネットワークＬＡＮへのアクセスは禁止されている。図示した例では、管理サーバＳＶに接続されるローカルエリアネットワークＬＡＮの数は１つとしたが、これに限られず、任意に設定可能である。

企業内のローカルエリアネットワークＬＡＮには、パーソナルコンピュータＰＣや、複数のプリンタＰＲＴ＃１〜ＰＲＴ＃ｎが接続されている（以下、プリンタＰＲＴ＃１〜ＰＲＴ＃ｎを総称して、プリンタＰＲＴとも呼ぶ）。図示した例では、パーソナルコンピュータＰＣの数は１台としたが、これに限られず、任意に設定可能である。

パーソナルコンピュータＰＣには、文書作成プログラム等のアプリケーションプログラムや、プリンタＰＲＴの動作を制御するためのプリンタドライバなどがインストールされており、パーソナルコンピュータＰＣから出力された印刷ジョブは、パーソナルコンピュータＰＣで設定されたいずれかのプリンタＰＲＴに受け渡され、印刷される。

各プリンタＰＲＴ＃１〜ＰＲＴ＃ｎには、それぞれカスタムネットワークボードＣＮＢ＃１〜ＣＮＢ＃ｎが内蔵されている（以下、カスタムネットワークボードＣＮＢ＃１〜ＣＮＢ＃ｎを総称して、カスタムネットワークボードＣＮＢとも呼ぶ）。このカスタムネットワークボードＣＮＢは、ローカルエリアネットワークＬＡＮや、インターネットＩＮＴを介して、印刷ジョブや、後述する監視情報などの各種データをやり取りするためのネットワークインタフェースである。また、カスタムネットワークボードＣＮＢは、後述するように、プリンタＰＲＴの動作を、印刷ジョブごとに監視し、その監視結果である監視情報を、管理サーバＳＶに通知する機能を有している。監視情報には、例えば、印刷枚数や、トナーの使用量や、エラー情報などの種々のログデータが含まれる。

管理センタの管理サーバＳＶは、プリンタＰＲＴに内蔵されたカスタムネットワークボードＣＮＢから通知された監視情報を、図示しないデータベースに格納する。また、管理サーバＳＶには、ディスプレイＤＰや、マウスＭＳや、キーボードＫＢが接続されており、管理担当者がデータベースに格納された監視情報を閲覧したり、プリンタＰＲＴを管理するための各種設定を行ったりすることができる。

本実施例のデバイス管理システム１０００の動作概要は、以下の通りである。各カスタムネットワークボードＣＮＢには、プリンタＰＲＴの監視情報を管理サーバＳＶに送信（アップロード）すべきアップロード時刻が設定されている。本実施例では、各カスタムネットワークボードＣＮＢには、それぞれ異なるアップロード時刻が設定されているものとする。そして、本実施例では、各プリンタＰＲＴに、プリンタＰＲＴの電源が投入されてから、最初にアップロードを行うべき時刻までの待ち時間と、それ以降周期的にアップロードを行う周期とが設定されており、アップロードは周期的に繰り返して行われる。このアップロード時刻の設定は、プリンタＰＲＴに予め設定されていたり、ユーザが手動で行うようにしてもよいし、乱数を用いたり、管理サーバＳＶ側で指定されたアップロード時刻を、管理サーバＳＶからダウンロードしたりして、自動で行うようにしてもよい。

各プリンタＰＲＴの電源の投入後、まず、いずれかのプリンタＰＲＴにおいて、アップロード時刻になると、そのプリンタＰＲＴは、監視情報を管理サーバＳＶにアップロードすべきか否かを判断し、アップロードすべきと判断した場合には、他のプリンタＰＲＴに、そのプリンタＰＲＴが保持する監視情報の送信要求を送信する。そして、その応答として、他のプリンタＰＲＴから監視情報を収集して、自ら保持する監視情報と、他のプリンタＰＲＴから収集した監視情報とを、管理サーバＳＶにアップロードする。以下、他のプリンタＰＲＴから監視情報を受信して、管理サーバＳＶに監視情報をアップロードするプリンタＰＲＴを、「代理プリンタ」とも呼び、代理プリンタに監視情報を送信するプリンタＰＲＴを、「被代理プリンタ」とも呼ぶ。図示した例では、プリンタＰＲＴ＃１が代理プリンタとして機能している場合の監視情報の流れを、破線矢印によって示している。

そして、本実施例では、代理プリンタは、管理サーバＳＶに監視情報を送信した後に、今回のアップロードにおいて、自分が代理プリンタであったことを、被代理プリンタに通知する。この通知は、原則として、次回のアップロード時も自らが代理プリンタとなることを表している。被代理プリンタは、この通知を受信した後、イベントが発生して監視情報が生成されるごとに、前回のアップロード時に代理プリンタであり、次回も代理プリンタとなるはずのプリンタＰＲＴに、監視情報を順次送信する。被代理プリンタから順次監視情報を受信した代理プリンタは、次にアップロード時刻になったときに、監視情報の送信要求を被代理プリンタに送信することなく、自ら保持する監視情報と、被代理プリンタから受信した監視情報とを、管理サーバＳＶにアップロードする。

なお、例えば、代理プリンタとなるはずのプリンタＰＲＴの電源がオフされる等によって、管理サーバＳＶへの監視情報の送信が滞った場合や、被代理プリンタであったいずれかのプリンタＰＲＴにおいて、管理サーバＳＶへの通知に緊急性を有する重大なイベントが発生した場合等には、代理プリンタが切り替わることになる。つまり、デバイス管理システム１０００において、代理プリンタ、および、被代理プリンタは、固定されておらず、各プリンタＰＲＴの動作状況に応じて切り替わる。これらの動作の詳細については、後述する。

Ｂ．第１実施例：
Ｂ１．プリンタの構成：
図２は、プリンタＰＲＴの構成を示す説明図である。プリンタＰＲＴは、印刷を実行するプリンタ本体１００と、カスタムネットワークボードＣＮＢとを備えている。そして、プリンタ本体１００は、プリンタエンジン１１０と、プリンタコントローラ１２０とを備えている。

プリンタコントローラ１２０は、図示しないＣＰＵや、ＲＡＭや、ＲＯＭを備えるコンピュータであり、パーソナルコンピュータＰＣから、カスタムネットワークボードＣＮＢを介して印刷ジョブを受け取り、プリンタエンジン１１０を制御して、印刷を実行させる。また、プリンタコントローラ１２０は、監視部１２２を備えおり、プリンタ本体１００に関する種々の監視情報を収集して、ＭＩＢ（Management Information Base）の形式で保存している。ＭＩＢには、プリンタ本体１００に関して予め規格で統一的に規定されている情報や、製造者によって独自に規定されている情報が含まれる。プリンタコントローラ１２０は、本発明における監視情報生成部に相当する。

カスタムネットワークボードＣＮＢは、ＣＰＵ１０と、メモリ２０と、タイマ３０とを備えている。メモリ２０は、揮発性メモリと、不揮発性メモリの両方を含んでいる。ＣＰＵ１０は、メモリ制御部１２と、判断部１４と、アップロードファイル作成部１６と、通信制御部１８とを備えている。これらの機能ブロックは、ＣＰＵ１０が、図示しないＲＯＭに記憶されている所定のコンピュータプログラムを、読み出して実行することによって、ソフトウェア的に構築されている。これらの機能ブロックの少なくとも一部を、ハードウェア的に構成するようにしてもよい。

メモリ制御部１２は、メモリ２０への種々のデータの書き込みや、読み出しや、削除を行う。メモリ２０に記憶されるデータには、後述するように、プリンタコントローラ１２０から取得した自らの監視情報を記録した監視情報ファイルや、各プリンタＰＲＴから受信した監視情報ファイルや、管理サーバＳＶに送信すべきアップロードファイルや、代理プリンタの識別情報を記したファイルなどが含まれる。メモリ２０、および、メモリ制御部１２は、本発明における監視情報記憶部、監視情報削除部に相当する。

判断部１４は、後述する動作処理や、ファイル収集処理や、アップロード処理において、種々の判断を行う。

アップロードファイル作成部１６は、メモリ２０に設定されたスプールディレクトリ２２に保存されている監視情報ファイルと、ｏｔｈｅｒディレクトリ２４に保存されている監視情報ファイルとを合成して、管理サーバＳＶに送信するためのアップロードファイルを作成する。

通信制御部１８は、通信相手に応じて、通信プロトコルを切り換え、ローカルエリアネットワークＬＡＮや、インターネットＩＮＴを介して、パーソナルコンピュータＰＣや、他のプリンタＰＲＴや、管理サーバＳＶと通信を行う。また、通信制御部１８は、プリンタコントローラ１２０とのデータのやり取りも行う。通信制御部１８は、本発明における受信部、送信部、削除要求受付部に相当する。

タイマ３０は、プリンタＰＲＴの電源がオンされてからの時間を計測する。本実施例では、タイマ３０は、プリンタＰＲＴの電源がオンされてからの時間の計測、および、電源の投入回数のカウントを行う。

メモリ２０には、スプールディレクトリ２２と、ｏｔｈｅｒディレクトリ２４と、アップロードディレクトリ２６とが設定されている。スプールディレクトリ２２には、プリンタコントローラ１２０から受け取った監視情報が、ファイル形式で保存される。ｏｔｈｅｒディレクトリ２４には、他のプリンタＰＲＴから受信、あるいは、収集した監視情報ファイルが保存される。アップロードディレクトリ２６には、アップロードファイル作成部１６によって作成されたアップロードファイルが保存される。アップロードファイルは、管理サーバＳＶにアップロードされるファイルである。メモリ２０には、先に説明したように、代理プリンタの識別情報を記したファイルも記録される。

図３は、アップロードファイルの生成について示す説明図である。図示するように、スプールディレクトリ２２には、監視情報ファイルＦａ１、Ｆａ２、Ｆａ３が保存されており、ｏｔｈｅｒディレクトリ２４には、監視情報ファイルＦｂ１、Ｆｂ２、Ｆｂ３、Ｆｃ１、Ｆｃ２、Ｆｃ３、...が保存されているものとする。これら各監視情報ファイルには、監視情報とともに、各プリンタＰＲＴの識別情報も記録されている。この識別情報としては、例えば、各プリンタＰＲＴに付与された名前や、ＭＡＣアドレスや、ＩＰアドレスや、製造番号などを用いることができる。また、各監視情報ファイルには、それぞれ監視情報ファイルが作成され、メモリ２０に記憶された時刻も記録されている。

アップロードファイル作成部１６は、図示するように、監視情報ファイルＦａ１、Ｆａ２、Ｆａ３と、監視情報ファイルＦｂ１、Ｆｂ２、Ｆｂ３、Ｆｃ１、Ｆｃ２、Ｆｃ３、...とを合成して、アップロードファイルＦｕを作成し、アップロードディレクトリ２６に保存する。こうすることによって、複数のプリンタＰＲＴの監視情報を、管理サーバＳＶに一度に送信することができるので、ネットワークトラフィックの増大を抑制することができる。また、各監視情報ファイルには、プリンタＰＲＴの識別情報も含まれているので、アップロードファイルＦｕを受信した管理サーバＳＶは、アップロードファイルＦｕの内容を解析することによって、各監視情報を出力したプリンタＰＲＴを容易に特定することができる。

Ｂ２．プリンタの動作処理：
図４は、プリンタＰＲＴの動作処理の流れを示すフローチャートである。この動作処理は、各プリンタＰＲＴにおいて、電源がオンされると、オフされるまで、カスタムネットワークボードＣＮＢのＣＰＵ１０が継続して実行する処理である。

まず、ＣＰＵ１０は、プリンタ本体１００においてイベントが発生し、監視情報ファイルが生成されたか否かを判断する（ステップＳ１００）。そして、監視情報ファイルが生成された場合には（ステップＳ１００：ＹＥＳ）、ＣＰＵ１０は、その監視情報ファイルをスプールディレクトリ２２に保存し、その監視情報ファイルが重大なイベントの発生を示すファイルか否かを判断する（ステップＳ１１０）。重大なイベントとは、管理サーバＳＶへの通知に緊急性を有するイベントであり、例えば、プリンタエンジン１１０の故障や、プリンタコントローラ１２０において色調整が行えないことなどが挙げられる。

ステップＳ１１０において、監視情報ファイルが重大なイベントの発生を示すファイルでない場合には（ステップＳ１１０：ＮＯ）、ＣＰＵ１０は、前回のアップロード時の代理プリンタの識別情報を記したファイルがメモリ２０に記録されているか否かを判断する（ステップＳ１２０）。プリンタＰＲＴの電源がオンされた初期段階では、このファイルは記録されていない。そして、前回のアップロード時の代理プリンタの識別情報がメモリ２０に記録されている場合には（ステップＳ１２０：ＹＥＳ）、ＣＰＵ１０は、その代理プリンタが自分自身であるか否か、すなわち、当該プリンタＰＲＴであるか否かを判断する（ステップＳ１３０）。前回のアップロード時の代理プリンタが自分自身でない場合には（ステップＳ１３０：ＮＯ）、ＣＰＵ１０は、そのプリンタＰＲＴが次回も被代理プリンタとして機能するものとし、管理サーバＳＶにアップロードすべき監視情報ファイルを、前回のアップロード時の代理プリンタとして記録されているプリンタＰＲＴに転送する（ステップＳ１４０）。

次に、ＣＰＵ１０は、タイマ３０を参照して、アップロード時刻になったか否かを判断する（ステップＳ１５０）。この判断は、ステップＳ１００において、監視情報ファイルが生成されていない場合（ステップＳ１００：ＮＯ）、ステップＳ１２０において、前回のアップロード時の代理プリンタの識別情報がメモリ２０に記録されていない場合（ステップＳ１２０：ＮＯ）、ステップＳ１３０において、前回のアップロード時の代理プリンタが当該プリンタＰＲＴである場合（ステップＳ１３０：ＹＥＳ）にも行われる。

ステップＳ１５０において、アップロード時刻になっていない場合には（ステップＳ１５０：ＮＯ）、ステップＳ１００に戻る。一方、アップロード時刻になった場合には（ステップＳ１５０：ＹＥＳ）、ＣＰＵ１０は、スプールディレクトリ２２に、管理サーバＳＶにアップロードすべき監視情報ファイルが存在するか否かを判断する（ステップＳ１６０）。

ステップＳ１６０において、スプールディレクトリ２２に、管理サーバＳＶにアップロードすべき監視情報ファイルが存在しない場合には（ステップＳ１６０：ＮＯ）、ステップＳ１００に戻る。一方、スプールディレクトリ２２に、管理サーバＳＶにアップロードすべき監視情報ファイルが存在する場合には（ステップＳ１６０：ＹＥＳ）、ＣＰＵ１０は、前回のアップロード時の代理プリンタが自分自身であるか否かを判断する（ステップＳ１７０）。

ステップＳ１７０において、前回のアップロード時の代理プリンタが自分自身である場合には（ステップＳ１７０：ＹＥＳ）、ＣＰＵ１０は、当該プリンタＰＲＴを代理プリンタとして機能させ、アップロード処理を実行する（ステップＳ３００）。一方、前回のアップロード時の代理プリンタが自分自身でない場合には（ステップＳ１７０：ＮＯ）、ＣＰＵ１０は、当該プリンタＰＲＴの機能を被代理プリンタから代理プリンタに切り替え、ファイル収集処理を実行し（ステップＳ２００）、その後、アップロード処理を実行する（ステップＳ３００）。ファイル収集処理、および、アップロード処理については、後述する。

なお、ステップＳ１１０において、監視情報ファイルが重大なイベントの発生を示すファイルである場合には（ステップＳ１１０：ＹＥＳ）、ＣＰＵ１０は、前回のアップロード時の代理プリンタがいずれのプリンタＰＲＴであるかに関わらず、当該プリンタＰＲＴを代理プリンタとして機能させ、ファイル収集処理を実行し（ステップＳ２００）、アップロード処理を実行する（ステップＳ３００）。こうすることによって、管理サーバＳＶへの通知に緊急性を有するイベントが発生したときには、これを速やかに管理サーバＳＶに通知することができる。

アップロード処理が終了した後は、ステップＳ１００に戻り、上述した処理を繰り返し実行する。

Ｂ３．ファイル収集処理：
図５は、図４のステップ２００におけるファイル収集処理の流れを示す説明図である。この処理は、重大なイベントが発生したために、すぐにアップロード処理を行う場合や、電源がオフされる等によって、前回のアップロード時の代理プリンタのアップロード処理が滞ったために、他のプリンタＰＲＴが代理プリンタとして機能する場合の代理プリンタのＣＰＵ１０が実行する処理である。

まず、ＣＰＵ１０は、他のプリンタ、すなわち、ローカルエリアネットワークＬＡＮに接続されている全てのプリンタＰＲＴに対して、存在確認を問い合わせるブロードキャストを送信する（ステップＳ２１０）。そして、ＣＰＵ１０は、いずれかのプリンタＰＲＴから、このブロードキャストに対する応答を受信したか否かを判断する（ステップＳ２２０）。いずれのプリンタＰＲＴからもブロードキャストに対する応答を受信しない場合には（ステップＳ２２０：ＮＯ）、ＣＰＵ１０は、監視情報ファイルの収集を行うべき被代理プリンタが存在しないものと判断して、ファイル収集処理を終了する。

ステップＳ２２０において、いずれかのプリンタＰＲＴから、ブロードキャストに対する応答を受信した場合には（ステップＳ２２０：ＹＥＳ）、そのうちの１つの応答元のプリンタＰＲＴとＦＴＰ接続を行い（ステップＳ２３０）、ＦＴＰ接続したプリンタＰＲＴに、管理サーバＳＶにアップロードすべき監視情報ファイルが存在するか否かを問い合わせて判断する（ステップＳ２４０）。ＣＰＵ１０は、ＦＴＰ接続したプリンタＰＲＴに、管理サーバＳＶにアップロードすべき監視情報ファイルが存在すると判断した場合には（ステップＳ２４０：ＹＥＳ）、その監視情報ファイルの送信要求を送信し、その監視情報ファイルを全てコピーし（ステップＳ２５０）、ｏｔｈｅｒディレクトリ２４に保存する。そして、ＣＰＵ１０は、ＦＴＰ接続を切断する（ステップＳ２６０）。ステップＳ２４０において、ＦＴＰ接続したプリンタＰＲＴに、管理サーバＳＶにアップロードすべき監視情報ファイルが存在しないと判断した場合には（ステップＳ２４０：ＮＯ）、ＣＰＵ１０は、そのままＦＴＰ接続を切断する（ステップＳ２６０）。

次に、ＣＰＵ１０は、全てのブロードキャストの応答元のプリンタＰＲＴに対して、ステップＳ２３０〜Ｓ２６０の処理を行ったか否かを判断する（ステップＳ２７０）。ステップＳ２３０〜Ｓ２６０の処理を行っていないプリンタＰＲＴが残っている場合には（ステップＳ２７０：ＮＯ）、ステップＳ２３０に戻る。ステップ２７０において、全てのブロードキャストの応答元のプリンタＰＲＴに対して、ステップＳ２３０〜Ｓ２６０の処理を行った場合には（ステップＳ２７０：ＹＥＳ）、ＣＰＵ１０は、ファイル収集処理を終了する。

Ｂ４．アップロード処理：
図６、および、図７は、図４のステップ３００におけるアップロード処理の流れを示すフローチャートである。この処理は、代理プリンタのＣＰＵ１０が実行する処理である。

まず、ＣＰＵ１０は、スプールディレクトリ２２に保存されている監視情報ファイルと、ｏｔｈｅｒディレクトリ２４に保存されている監視情報ファイルとを合成して、アップロードファイルＦｕを作成し（ステップＳ３１０）、アップロードディレクトリ２６に保存する。そして、ＣＰＵ１０は、このアップロードファイルＦｕを圧縮して、管理サーバＳＶにアップロードする（ステップＳ３２０）。管理サーバＳＶへのアップロードファイルＦｕのアップロードは、セキュリティの確保のため、ＳＳＬ（Secure Socket Layer）を用いて行う。

次に、ＣＰＵ１０は、アップロードに成功したか否かを判断する（ステップＳ３３０）。この判断は、管理サーバＳＶから、アップロードに対する受信完了応答を受信したか否かに基づいて行われる。ＣＰＵ１０は、管理サーバＳＶから、アップロードに対する受信完了応答を受信した場合には、アップロードが成功したと判断し、受信完了応答を受信しない場合には、アップロードが失敗したと判断する。

ステップＳ３３０において、アップロードに成功した場合には、他のプリンタ、すなわち、ローカルエリアネットワークＬＡＮに接続されている全てのプリンタＰＲＴに対して、存在確認を問い合わせるブロードキャストを送信する（ステップＳ３４０）。そして、ＣＰＵ１０は、いずれかのプリンタＰＲＴから、このブロードキャストに対する応答を受信したか否かを判断する（ステップＳ３５０）。

ステップＳ３５０において、いずれかのプリンタＰＲＴから、ブロードキャストに対する応答を受信した場合には（ステップＳ３５０：ＹＥＳ）、ＣＰＵ１０は、そのうちの１つの応答元のプリンタＰＲＴとＦＴＰ接続を行い（ステップＳ３６０）、そのプリンタＰＲＴに対して、アップロード済みの監視情報ファイルの削除要求を送信する（ステップＳ３６２）。このとき、１つのアップロード済みの監視情報ファイルに対して、１つの削除要求が送信される。新たに電源がオンされた等の理由によって、ＦＴＰ接続したプリンタＰＲＴにアップロード済みの監視情報ファイルが保持されていない場合には、この削除要求の送信は行わない。この削除要求を受信したプリンタＰＲＴは、代理プリンタからの削除要求に応じて、監視情報ファイルを削除する。こうすることによって、削除要求を受信したプリンタＰＲＴのスプールディレクトリ２２には、管理サーバＳＶに未送信の監視情報ファイルのみが残されるので、ＣＰＵ１０は、後に、スプールディレクトリ２２に未送信の監視情報ファイルが存在しているか否かを容易に判断することができる。

次に、ＣＰＵ１０は、ＦＴＰ接続を行っているプリンタＰＲＴについて、全てのアップロード済みの監視情報ファイルについての削除要求を送信したか否かを判断する（ステップＳ３６４）。アップロード済みの監視情報ファイルについて、削除要求を送信していない監視情報ファイルが残っている場合には（ステップＳ３６４：ＮＯ）、ステップＳ３６２に戻る。一方、全てのアップロード済みの監視情報ファイルについての削除要求を送信した場合には（ステップＳ３６４：ＹＥＳ）、ＣＰＵ１０は、今回、自分が代理プリンタであったことを示す、当該プリンタＰＲＴの識別情報を記したファイルを送信して（ステップＳ３６６）、送信先のプリンタＰＲＴのメモリ２０に保存させ、ＦＴＰ接続を切断する（ステップＳ３６８）。

次に、ＣＰＵ１０は、ステップＳ３４０におけるブロードキャストに対する全ての応答元のプリンタＰＲＴに対して、ステップＳ３６０〜Ｓ３６８の処理を行ったか否かを判断する（ステップＳ３７０）。ステップＳ３６０〜Ｓ３６８の処理を行っていないプリンタＰＲＴが残っている場合には（ステップＳ３７０：ＮＯ）、ステップＳ３６０に戻る。一方、全ての応答元のプリンタＰＲＴに対してステップＳ３６０〜Ｓ３６８の処理を行った場合には（ステップＳ３７０：ＹＥＳ）、ＣＰＵ１０は、自身のスプールディレクトリ２２に保存されているアップロード済みの監視情報ファイルを削除する（ステップＳ３８０）。そして、ＣＰＵ１０は、今回、自分が代理プリンタであったことを示すファイルを作成してメモリ２０に記録する（ステップＳ３８２）。さらに、ＣＰＵ１０は、アップロードディレクトリ２６に保存されているアップロードファイルＦｕ、および、ｏｔｈｅｒディレクトリ２４に保存されている被代理プリンタから取得した監視情報ファイルを削除する（ステップＳ３９０）。そして、アップロード処理を終了する。

なお、ステップＳ３５０において、いずれのプリンタＰＲＴからもブロードキャストに対する応答を受信しない場合には（ステップＳ３５０：ＮＯ）、動作中のプリンタＰＲＴがないものと判断して、ステップＳ３８０に進む。

ステップ３３０において、アップロードに失敗した場合には（ステップＳ３３０：ＮＯ）、ＣＰＵ１０は、アップロードディレクトリ２６に保存されているアップロードファイルＦｕ、および、ｏｔｈｅｒディレクトリ２４に保存されている被代理プリンタから取得した監視情報ファイルを削除し（ステップＳ３９０）、スプールディレクトリ２２に保存されている監視情報ファイルは、いずれかのプリンタＰＲＴが、ファイル収集処理、アップロード処理を実行するときまで保持する。そして、アップロード処理を終了する。

以上説明した第１実施例のデバイス管理システム１０００では、代理プリンタが、自らの監視情報と、被代理プリンタから受信した監視情報とを、一括して管理サーバＳＶにアップロードするので、各プリンタＰＲＴから管理サーバＳＶへのアクセス頻度を低減することができる。さらに、被代理プリンタは、イベントが発生するごとに、監視情報ファイルを代理プリンタに順次送信するので、デバイス管理システム１０００に多数のプリンタＰＲＴが接続されている場合であっても、多数の被代理プリンタが一斉に監視情報ファイルを代理プリンタに送信することはない。この結果、被代理プリンタから代理プリンタへの監視情報ファイルの送信に伴うネットワークトラフィックの急激な増大を防止することができる。つまり、本実施例のデバイス管理システム１０００によれば、プリンタＰＲＴから管理サーバへのアクセス頻度を低減するとともに、監視情報ファイルの送信に伴うネットワークトラフィックの急激な増大を防止することができる。

Ｃ．第２実施例：
第２実施例のデバイス管理システム１０００の構成は、第１実施例のデバイス管理システム１０００と同じである。また、第２実施例のプリンタＰＲＴの構成も、第１実施例のプリンタＰＲＴと同じである。ただし、第２実施例のプリンタＰＲＴは、カスタムネットワークボードＣＮＢのＣＰＵ１０によって行われる処理が、第１実施例のプリンタＰＲＴと一部異なる。以下、第１実施例と異なる点について説明する。

図８は、第２実施例におけるプリンタＰＲＴの動作処理の流れを示すフローチャートである。図示したフローチャートは、第１実施例における動作処理（図４参照）において、ステップＳ１５０の代わりに行う処理である。なお、第２実施例では、代理プリンタは、後述するように、アップロードファイルＦｕの管理サーバＳＶへのアップロードが成功したときに、被代理プリンタに対して、アップロード延期要求を送信する。

ＣＰＵ１０は、他のプリンタ、すなわち、代理プリンタからアップロード延期要求を受信したか否かを判断する（ステップＳ１５０ａ）。アップロード延期要求を受信した場合には（ステップＳ１５０ａ：ＹＥＳ）、ＣＰＵ１０は、タイマ３０を参照して、アップロード延期要求の受信時刻Ｔｒを、メモリ２０に保存する（ステップＳ１５２ａ）。

次に、ＣＰＵ１０は、タイマ３０を参照して、アップロード時刻になったか否かを判断する（ステップＳ１５４ａ）。アップロード時刻になっていない場合には（ステップＳ１５４ａ：ＮＯ）、図４のステップＳ１００に戻る。一方、アップロード時刻になった場合には（ステップＳ１５４ａ：ＹＥＳ）、ＣＰＵ１０は、現在時刻Ｔｐがアップロード延期要求を受信した受信時刻Ｔｒから所定時間Ｔｃを経過しているか否かを判断する（ステップＳ１５６ａ）。所定時間Ｔｃは、任意に設定可能である。現在時刻Ｔｐがアップロード延期要求を受信した受信時刻Ｔｒから所定時間Ｔｃを経過していない場合には（ステップＳ１５６ａ：ＮＯ）、図４のステップＳ１００に戻る。一方、現在時刻Ｔｐがアップロード延期要求を受信した受信時刻Ｔｒから所定時間Ｔｃを経過している場合には（ステップＳ１５６ａ：ＹＥＳ）、図４のステップＳ１６０に進む。

また、ステップＳ１５０ａにおいて、代理プリンタからアップロード延期要求を受信していない場合には（ステップＳ１５０ａ：ＮＯ）、タイマ３０を参照して、アップロード時刻になったか否かを判断する（ステップＳ１５８ａ）。アップロード時刻になっていない場合には（ステップＳ１５８ａ：ＮＯ）、図４のステップＳ１００に戻る。一方、アップロード時刻になった場合には（ステップＳ１５８ａ：ＹＥＳ）、図４のステップＳ１６０に進む。

図９は、第２実施例におけるアップロード処理の流れを示すフローチャートである。第２実施例におけるアップロード処理は、第１実施例におけるアップロード処理（図６、図７参照）のステップＳ３３０以降の処理が、第１実施例におけるアップロード処理と一部異なっている。すなわち、図７におけるステップＳ３６６の代わりに、ステップＳ３６６ａの処理を実行する。他の処理は、第１実施例におけるアップロード処理と同じである。

ステップＳ３６４において、全てのアップロード済みの監視情報ファイルについての削除要求を送信した場合には（ステップＳ３６４：ＹＥＳ）、ＣＰＵ１０は、今回、自分が代理プリンタであったことを示す、当該プリンタＰＲＴの識別情報を記したファイル、および、アップロード延期要求を送信して（ステップＳ３６６ａ）、このファイル、および、アップロード延期要求の受信時刻を、送信先のプリンタＰＲＴのメモリ２０に保存させ、ＦＴＰ接続を切断する（ステップＳ３６８）。

以上説明した第２実施例のデバイス管理システム１０００では、各プリンタＰＲＴは、アップロード時刻になったときに、代理プリンタから収集延期要求を受け付けてから所定時間Ｔｃが経過していない場合には、スプールディレクトリ２２に、管理サーバＳＶに未送信の監視情報ファイルが存在する場合であっても、まだ、他のプリンタＰＲＴから監視情報ファイルを収集して、管理サーバＳＶにアップロードする必要はないと判断して、代理プリンタとして機能せず、他のプリンタＰＲＴからの監視情報ファイルの収集、および、アップロードファイルの管理サーバＳＶへのアップロードを、次回のアップロード時刻になるまで延期する。つまり、第２実施例のデバイス管理システム１０００では、なるべく１つのプリンタＰＲＴを、代理プリンタとして機能させ、複数のプリンタＰＲＴが個別にアップロード処理を行うことを回避する。こうすることによって、各プリンタＰＲＴから管理サーバＳＶへのアクセス頻度を、第１実施例のデバイス管理システム１０００よりも低減することができる。

Ｄ．第３実施例：
第３実施例のデバイス管理システム１０００の構成は、第１実施例のデバイス管理システム１０００と同じである。また、第３実施例のプリンタＰＲＴの構成も、第１実施例のプリンタＰＲＴと同じである。ただし、第３実施例のプリンタＰＲＴは、カスタムネットワークボードＣＮＢのＣＰＵ１０によって行われる処理が、第１実施例のプリンタＰＲＴと一部異なる。以下、第１実施例と異なる点について説明する。

図１０は、第３実施例におけるプリンタＰＲＴの動作処理の流れを示すフローチャートである。図示したフローチャートは、第１実施例における動作処理（図４参照）において、ステップＳ１５０の代わりに行う処理である。なお、第３実施例では、各被代理プリンタは、先に説明した削除要求に応じて、監視情報ファイルの削除を行ったときに、その削除時刻Ｔｄを、メモリ２０に保存する。

ＣＰＵ１０は、メモリ２０に、削除時刻Ｔｄが保存されているか否かを判断する（ステップＳ１５０ｂ）。メモリ２０に、削除時刻Ｔｄが保存されている場合には（ステップＳ１５０ｂ：ＹＥＳ）、ＣＰＵ１０は、タイマ３０を参照して、アップロード時刻になったか否かを判断する（ステップＳ１５２ｂ）。アップロード時刻になっていない場合には（ステップＳ１５２ｂ：ＮＯ）、図４のステップＳ１００に戻る。一方、アップロード時刻になった場合には（ステップＳ１５２ｂ：ＹＥＳ）、ＣＰＵ１０は、現在時刻Ｔｐが削除時刻Ｔｄから所定時間Ｔｃを経過しているか否かを判断する（ステップＳ１５４ｂ）。所定時間Ｔｃは、任意に設定可能である。現在時刻Ｔｐが削除時刻Ｔｄから所定時間Ｔｃを経過していない場合には（ステップＳ１５４ｂ：ＮＯ）、図４のステップＳ１００に戻る。一方、現在時刻Ｔｐが削除時刻Ｔｄから所定時間Ｔｃを経過している場合には（ステップＳ１５４ｂ：ＹＥＳ）、図４のステップＳ１６０に進む。

また、ステップＳ１５０ｂにおいて、メモリ２０に、削除時刻Ｔｄが保存されていない場合には（ステップＳ１５０ｂ：ＮＯ）、アップロード時刻になったか否かを判断する（ステップＳ１５６ｂ）。アップロード時刻になっていない場合には（ステップＳ１５６ｂ：ＮＯ）、図４のステップＳ１００に戻る。一方、アップロード時刻になった場合には（ステップＳ１５６ｂ：ＹＥＳ）、図４のステップＳ１６０に進む。

以上説明した第３実施例のデバイス管理システム１０００では、各プリンタＰＲＴは、アップロード時刻になったときに、前回、監視情報ファイルを送信し、その送信済みの監視情報ファイルを削除してから所定時間Ｔｃが経過していない場合には、スプールディレクトリ２２に、管理サーバＳＶに未送信の監視情報ファイルが存在する場合であっても、まだ、他のプリンタＰＲＴから監視情報ファイルを収集して、管理サーバＳＶにアップロードする必要はないと判断して、代理プリンタとして機能せず、他のプリンタＰＲＴからの監視情報ファイルの収集、および、アップロードファイルの管理サーバＳＶへのアップロードを、次回のアップロード時刻になるまで延期する。こうすることによっても、各プリンタＰＲＴから管理サーバＳＶへのアクセス頻度を、第１実施例のデバイス管理システム１０００よりも低減することができる。

Ｅ．第４実施例：
第４実施例のデバイス管理システム１０００の構成は、第１実施例のデバイス管理システム１０００と同じである。また、第４実施例のプリンタＰＲＴの構成も、第１実施例のプリンタＰＲＴと同じである。ただし、第４実施例のプリンタＰＲＴは、カスタムネットワークボードＣＮＢのＣＰＵ１０によって行われる処理が、第１実施例のプリンタＰＲＴと一部異なる。以下、第１実施例と異なる点について説明する。

図１１は、第４実施例におけるプリンタＰＲＴの動作処理の流れを示すフローチャートである。図示したフローチャートは、第１実施例における動作処理（図４参照）において、ステップＳ１５０、および、ステップＳ１６０の代わりに行う処理である。なお、第４実施例では、各プリンタＰＲＴは、この動作処理において、スプールディレクトリ２２に保存されている各監視情報ファイルの保存時刻を利用する。

ＣＰＵ１０は、タイマ３０を参照して、アップロード時刻になったか否かを判断する（ステップＳ１５０ｃ）。アップロード時刻になっていない場合には（ステップＳ１５０ｃ：ＮＯ）、図４のステップＳ１００に戻る。一方、アップロード時刻になった場合には（ステップＳ１５０ｃ：ＹＥＳ）、ＣＰＵ１０は、スプールディレクトリ２２に、所定時間Ｔｃ以上前に保存された監視情報ファイルが存在するか否かを判断する（ステップＳ１６０ｃ）。所定時間Ｔｃは、任意に設定可能である。スプールディレクトリ２２に、所定時間Ｔｃ以上前に保存された監視情報ファイルが存在しない場合には（ステップＳ１６０ｃ：ＮＯ）、すぐに管理サーバＳＶに送信すべき監視情報ファイルはないものと判断し、このプリンタＰＲＴを代理プリンタとして機能させずに、図４のステップＳ１００に戻る。一方、スプールディレクトリ２２に、所定時間Ｔｃ以上前に保存された監視情報ファイルが存在する場合には（ステップＳ１６０ｃ：ＹＥＳ）、ＣＰＵ１０は、この監視情報ファイルは、すぐに管理サーバＳＶに送信すべき監視情報ファイルであると判断し、このプリンタＰＲＴを代理プリンタとして機能させて、図４のステップＳ１７０に進む。

以上説明した第４実施例のデバイス管理システム１０００では、各プリンタＰＲＴは、アップロード時刻になったときに、スプールディレクトリ２２に、所定時間Ｔｃ以上前に保存された未送信の監視情報ファイルが存在していない場合には、未送信の監視情報ファイルが存在する場合であっても、まだ、他のプリンタＰＲＴから監視情報ファイルを収集して、管理サーバＳＶにアップロードする必要はないと判断して、代理プリンタとして機能せず、他のプリンタＰＲＴからの監視情報ファイルの収集、および、アップロードファイルの管理サーバＳＶへのアップロードを、次回のアップロード時刻になるまで延期する。つまり、第４実施例のデバイス管理システム１０００では、いずれかのプリンタＰＲＴが代理プリンタとしてアップロード処理を行った後の所定時間は、他のプリンタＰＲＴはアップロード処理を行わない。こうすることによっても、各プリンタＰＲＴから管理サーバＳＶへのアクセス頻度を低減することができる。

Ｆ．変形例：
以上、本発明のいくつかの実施の形態について説明したが、本発明はこのような実施の形態になんら限定されるものではなく、その要旨を逸脱しない範囲内において種々なる態様での実施が可能である。例えば、以下のような変形例が可能である。

Ｆ１．変形例１：
上記実施例では、図４に示したプリンタＰＲＴの動作処理において、電源がオンされた初期段階では、前回のアップロード時の代理プリンタの識別情報を記したファイルは記録されていなかった。そこで、プリンタＰＲＴに新たに電源がオンされたときに、以下に示す起動設定処理を行うようにしてもよい。

図１２は、起動設定処理の流れを示すフローチャートである。この処理は、ステップＳ１００に先立って、カスタムネットワークボードＣＮＢのＣＰＵ１０が実行する処理である。

まず、ＣＰＵ１０は、他のプリンタＰＲＴ、すなわち、ローカルエリアネットワークＬＡＮに接続されている全てのプリンタＰＲＴに対して、そのプリンタＰＲＴが代理プリンタであるか、被代理プリンタであるかを問い合わせるブロードキャストを送信する（ステップＳ１０）。そして、ＣＰＵ１０は、いずれかのプリンタＰＲＴから、このブロードキャストに対する応答を受信したか否かを判断する（ステップＳ２０）。

ステップＳ２０において、いずれかのプリンタＰＲＴから、ブロードキャストに対する応答を受信した場合には（ステップＳ２０：ＹＥＳ）、代理プリンタである旨の応答を受信したか否かを判断する（ステップＳ３０）。いずれかのプリンタＰＲＴから、代理プリンタである旨の応答を受信した場合には（ステップＳ３０：ＹＥＳ）、そのプリンタＰＲＴを代理プリンタとして記録し（ステップＳ４０）、起動設定処理を終了する。

ステップＳ３０において、いずれのプリンタＰＲＴからも代理プリンタである旨の応答を受信しなかった場合には（ステップＳ３０：ＮＯ）、ＣＰＵ１０は、ブロードキャストの応答元の他のプリンタＰＲＴに、自らの識別情報を記したファイルを送信することによって、自分が代理プリンタになることを通知し（ステップＳ５０）、自分が代理プリンタであることを記録して（ステップＳ６０）、起動設定処理を終了する。また、ステップ２０において、いずれのプリンタＰＲＴからもブロードキャストに対する応答を受信しなかった場合には（ステップＳ２０：ＮＯ）、ＣＰＵ１０は、自分が代理プリンタであることを記録し（ステップＳ６０）、起動設定処理を終了する。

この起動設定処理によって、プリンタＰＲＴに新たに電源がオンされたときに、いずれのプリンタＰＲＴが代理プリンタであるかを確認してから、ＣＰＵ１０は、図４に示した動作処理を実行することができる。

Ｆ２．変形例２：
上記実施例では、図７に示したアップロード処理において、ステップＳ３４０、およびステップＳ３５０の処理を行うものとしたが、これらを省略してもよい。この場合、ステップＳ３６０等において、ブロードキャストの応答元のプリンタＰＲＴと通信を行う代わりに、監視情報ファイルの送信元のプリンタＰＲＴと通信を行うようにすればよい。ただし、上記実施例によれば、新たに電源がオンされたプリンタＰＲＴを検出することができるという利点がある。

Ｆ３．変形例３：
上記実施例では、被代理プリンタは、イベントが発生するごとに、監視情報ファイルを代理プリンタに送信するものとしたが、これに限られない。被代理プリンタは、代理プリンタとは無関係なタイミングで、監視情報ファイルの送信を行えばよい。例えば、代理プリンタに未送信の監視情報ファイルが所定数溜まるごとに、それらを一括して代理プリンタに送信するようにしてもよい。

Ｆ４．変形例４：
上記実施例では、各プリンタＰＲＴは、タイマ３０を備えるものとしたが、時計を備えるようにしてもよい。また、各プリンタＰＲＴは、インターネットＩＮＴ上に設置されたいわゆるＮＴＰサーバから、必要に応じて時刻を取得するようにしてもよい。

Ｆ５．変形例５：
上記実施例では、全てのプリンタＰＲＴが、カスタムネットワークボードＣＮＢを備え、代理プリンタとして機能しうるものとしたが、少なくとも２台のプリンタＰＲＴが、このＰＲＴを代理プリンタとして機能させるカスタムネットワークボードＣＮＢを備えるようにすればよい。この場合、プリンタを代理プリンタとして機能させるカスタムネットワークボードＣＮＢを備えない他のプリンタは、代理プリンタからの要求に応じて、監視情報ファイルの転送や、削除等を行う機能を備えるようにすればよい。

Ｆ６．変形例６：
上記実施例では、被代理プリンタは、代理プリンタからの削除要求に応じて、送信済みの監視情報ファイルの削除を行うものとしたが、受信完了応答に応じて、送信済みの監視情報ファイルを削除するようにしてもよい。

Ｆ７．変形例７：
上記第３実施例では、各プリンタＰＲＴは、監視情報ファイルの削除時刻Ｔｄを、メモリ２０に記憶し、この削除時刻Ｔｄに基づいて、アップロード処理を行うか否かの判断を行ったが、これに限られない。削除時刻Ｔｄの代わりに、例えば、監視情報ファイルを代理プリンタに送信した時刻や、代理プリンタから、監視情報ファイルの受信応答を受信した時刻や、削除要求を受信した時刻に基づいて、アップロード処理を行うか否かを判断するようにしてもよい。

Ｆ８．変形例８：
上記第２ないし第４実施例では、プリンタＰＲＴの動作処理において、スプールディレクトリ２２に、管理サーバＳＶに未送信の監視情報ファイルが存在するか否かを判断したが、この判断を行わないようにしてもよい。

Ｆ９．変形例９：
上記実施例では、ネットワークに接続されるプリンタＰＲＴに、本発明のデバイスを適用した例を示したが、これに限られない。例えば、スキャナや、プロジェクタや、オーディオ装置や、家電機器や、クライアントコンピュータや、ＰＤＡ（Personal Digital Assistance）など、ネットワークに接続されて利用される種々のデバイスに、本発明のデバイスを適用するようしにてもよい。

本発明の一実施例としてのデバイス管理システム１０００の概略構成を示す説明図である。 プリンタＰＲＴの構成を示す説明図である。 アップロードファイルの生成について示す説明図である。 プリンタＰＲＴの動作処理の流れを示すフローチャートである。 ファイル収集処理の流れを示す説明図である。 アップロード処理の流れを示すフローチャートである。 アップロード処理の流れを示すフローチャートである。 第２実施例におけるプリンタＰＲＴの動作処理の流れを示すフローチャートである。 第２実施例におけるアップロード処理の流れを示すフローチャートである。 第３実施例におけるプリンタＰＲＴの動作処理の流れを示すフローチャートである。 第４実施例におけるプリンタＰＲＴの動作処理の流れを示すフローチャートである。 起動設定処理の流れを示すフローチャートである。

符号の説明

１０００...デバイス管理システム
１０...ＣＰＵ
１２...メモリ制御部
１４...判断部
１６...アップロードファイル作成部
１８...通信制御部
２０...メモリ
２２...スプールディレクトリ
２４...ｏｔｈｅｒディレクトリ
２６...アップロードディレクトリ
３０...タイマ
１００...プリンタ本体
１１０...プリンタエンジン
１２０...プリンタコントローラ
１２２...監視部
ＰＣ...パーソナルコンピュータ
ＰＲＴ...プリンタ
ＣＮＢ...カスタムネットワークボード
ＳＶ...管理サーバ
ＤＰ...ディスプレイ
ＫＢ...キーボード
ＭＳ...マウス
ＩＮＴ...インターネット
ＬＡＮ...ローカルエリアネットワーク
ＦＷ...ファイアウォール

Claims (8)

1. 複数のデバイスと、該複数のデバイスを管理するための管理サーバとを、所定のネットワークを介して、互いに接続することによって構成されたデバイス管理システムであって、
   前記複数のデバイスのうちの特定のデバイスは、該特定のデバイスが前記複数のデバイスに関する所定の監視情報を一括して前記管理サーバに送信する旨の通知を、該特定のデバイス以外の他のデバイスに送信し、
   該他のデバイスは、前記通知を受信した後に、前記特定のデバイスとは無関係の所定のタイミングで、該他のデバイスに関する前記監視情報を、前記特定のデバイスに順次送信し、
   前記特定のデバイスは、予め設定されたタイミングで、該特定のデバイスに関する前記監視情報、および、前記他のデバイスから受信した前記監視情報を、前記管理サーバに送信する、
   デバイス管理システム。
2. 請求項１記載のデバイス管理システムであって、
   前記所定のタイミングは、前記他のデバイスにおけるイベントの発生に基づくタイミングである、
   デバイス管理システム。
3. 請求項１記載のデバイス管理システムであって、
   前記複数のデバイスには、該複数のデバイスを識別するための識別情報がそれぞれ付与されており、
   前記他のデバイスは、該他のデバイスに関する前記監視情報を、該他のデバイスを識別するための識別情報と関連付けて、前記特定のデバイスに送信し、
   前記特定のデバイスは、前記各監視情報を、該各監視情報と対応する前記各識別情報と関連付けて、前記管理サーバに送信する、
   デバイス管理システム。
4. 請求項１記載のデバイス管理システムであって、
   前記特定のデバイスは、前記複数のデバイスに関する前記監視情報を、前記管理サーバに送信した後に、前記送信済みの前記監視情報を削除すべき削除要求を、前記他のデバイスに送信し、
   前記他のデバイスは、前記特定のデバイスから受信した前記削除要求に応じて、前記送信済みの前記監視情報を削除する、
   デバイス管理システム。
5. 複数のデバイスと、該複数のデバイスを管理するための管理サーバとを、所定のネットワークを介して、互いに接続することによって構成されたデバイス管理システムに用いられるデバイスであって、
   前記複数のデバイスのうちの特定のデバイスから、前記特定のデバイスが前記複数のデバイスに関する所定の監視情報を一括して前記管理サーバに送信する旨の通知を受信する受信部と、
   当該デバイスにおけるイベントの発生に応じて、該デバイスに関する監視情報を生成する監視情報生成部と、
   前記イベントの発生に基づくタイミングで、前記通知を受信した前記特定のデバイスに、前記生成された監視情報を送信する送信部と、
   を備えるデバイス。
6. 請求項５記載のデバイスであって、
   前記送信部は、さらに、前記デバイスを識別するための識別情報を、前記監視情報と関連付けて、前記特定のデバイスに送信する、
   デバイス。
7. 請求項５記載のデバイスであって、さらに、
   前記生成された監視情報を記憶する監視情報記憶部と、
   前記特定のデバイスから、前記管理サーバに送信済みの前記監視情報の削除要求を受け付ける削除要求受付部と、
   該削除要求に応じて、前記監視情報記憶部に記憶されている、前記他のデバイスに送信済みの監視情報を削除する監視情報削除部と、
   を備えるデバイス。
8. 複数のデバイスと、該複数のデバイスを管理するための管理サーバとを、所定のネットワークを介して、互いに接続することによって構成されたデバイス管理システムの制御方法であって、
   前記複数のデバイスのうちの特定のデバイスにおいて、該特定のデバイスが前記複数のデバイスに関する所定の監視情報を一括して前記管理サーバに送信する旨の通知を、該特定のデバイス以外の他のデバイスに送信する工程と、
   前記他のデバイスにおいて、前記通知を受信した後に、前記特定のデバイスとは無関係の所定のタイミングで、該他のデバイスに関する前記監視情報を、前記特定のデバイスに順次送信する工程と、
   前記特定のデバイスにおいて、予め設定されたタイミングで、該特定のデバイスに関する前記監視情報、および、前記他のデバイスから受信した前記監視情報を、前記管理サーバに送信する工程と、
   を備える制御方法。

Images