JP2006235789A - ネットワークに接続されたサーバからの情報のダウンロード制御 - 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