(57)【要約】【課題】クライアントサーバシステムにおいて、クライアントからのデータ要求に伴うサーバ側の処理負荷を軽減することを目的とする。【解決手段】プリンタ１は、他の複数のデバイスに対し所定タイミングでＳＮＭＰによるＧＥＴリクエストをブロードキャストして、各デバイスのモデル名，アイドル率及び保持しているイメージファイルに関する情報を得る。そして、Ｗｅｂブラウザ３１からＷｅｂページの要求があったとき（▲１▼）、プリンタ１内のＷｅｂサーバは、上記ブロードキャストにて得た情報を元に、Ｗｅｂページに表示させるイメージファイルの参照（取得）先を、他の複数のプリンタ（そのイメージファイルを持つプリンタ）に分散指定したＨＴＭＬデータを作成して、クライアントＰＣ７へ送信する（▲２▼）。Ｗｅｂブラウザ３１は、このＨＴＭＬデータに基づいて、指定された複数のプリンタへイメージファイルを要求する（▲３▼）。【選択図】　図２
2004005394.tif 000002
【特許請求の範囲】
【請求項１】
クライアントと複数のサーバとが相互にデータ送受信可能に構成され、該クライアントからのデータ要求に応じて前記サーバが該要求されたデータを前記クライアントへ送信するよう構成されたクライアントサーバシステムであって、
前記サーバの少なくとも一つは、
前記データ要求に応じて送信すべきデータを当該サーバ以外の他のサーバが持っているかどうか調査し、前記データ要求に応じたデータ送信を行う際、前記他のサーバの中で該要求されたデータを持つ同データ保持サーバがあれば、該データについては当該サーバから直接送信せず前記同データ保持サーバから送信させるよう構成された、負荷分散サーバである
ことを特徴とするクライアントサーバシステム。
【請求項２】
前記負荷分散サーバは、前記調査を、前記クライアントからのデータ要求の有無に関わらず所定のタイミングで実行することを特徴とする請求項１記載のクライアントサーバシステム。
【請求項３】
前記負荷分散サーバは、当該負荷分散サーバ自身の処理負荷量を示す負荷状況度が、該処理負荷量が多大であるか否かの判断基準となる所定の上位レベルより大きいときに、前記調査を実行することを特徴とする請求項２記載のクライアントサーバシステム。
【請求項４】
前記負荷分散サーバは、当該負荷分散サーバ自身の処理負荷量を示す負荷状況度が、該処理負荷量に余裕があるか否かの判断基準となる所定の下位レベルに満たないとき、若しくは、当該クライアントサーバシステムを構成する前記クライアントと前記複数のサーバ相互間のデータ送受信量を示すトラフィックレベルが、所定の基準レベルに満たないときに、前記調査を実行することを特徴とする請求項２記載のクライアントサーバシステム。
【請求項５】
前記負荷分散サーバは、他のサーバが接続されたネットワークに対して新たに当該負荷分散サーバが参加し、当該負荷分散サーバがネットワークを介して他のサーバと通信可能な状態になったときに、あるいは、当該負荷分散サーバが接続されたネットワークに対して新たに他のサーバが参加し、当該他のサーバがネットワークを介して負荷分散サーバと通信可能な状態になったときに、前記調査を実行することを特徴とする請求項２に記載のクライアントサーバシステム。
【請求項６】
前記負荷分散サーバは、過去に通信可能であった他のサーバについて、現在も通信可能であるか否かを判断して、通信不能であると判断されたときに、前記調査を実行することを特徴とする請求項２に記載のクライアントサーバシステム。
【請求項７】
前記負荷分散サーバは、前記クライアントからデータ要求があったときに前記調査を実行することを特徴とする請求項１記載のクライアントサーバシステム。
【請求項８】
前記負荷分散サーバは、前記クライアントからのデータ要求に応じてデータの送信を行った後、当該データの送信から所定期間内に同一のクライアントから同一のデータを要求されたときに、前記調査を実行することを特徴とする請求項７に記載のクライアントサーバシステム。
【請求項９】
前記負荷分散サーバは、前記調査として更に、前記他のサーバ各々について、該他のサーバの処理負荷量にどの程度の余裕があるかを示す負荷余裕度も調査し、前記同データ保持サーバの前記負荷余裕度が分散可能レベルに満たない場合は、該同データ保持サーバから前記クライアントへのデータ送信をさせないようにする
ことを特徴とする請求項１〜８いずれかに記載のクライアントサーバシステム。
【請求項１０】
前記負荷分散サーバは、前記クライアントから要求されたデータを持つ同データ保持サーバであっても、当該同データ保持サーバがユーザによって利用が許可されていない同データ保持サーバであれば、当該同データ保持サーバにデータを送信させないようにすることを特徴とする請求項１〜９いずれかに記載のクライアントサーバシステム。
【請求項１１】
前記負荷分散サーバは、
前記データ要求に応じて送信すべきデータを送信させるようにした前記同データ保持サーバを、該データに対する送信実行サーバとして記憶しておき、
前記データ要求に応じてデータ送信を行う際に、該要求されたデータを持つ前記同データ保持サーバが複数ある場合、該複数の同データ保持サーバの中に前記送信実行サーバとして記憶された同データ保持サーバがあれば、該同データ保持サーバから前記データを送信させるようにする
ことを特徴とする請求項１〜１０いずれかに記載のクライアントサーバシステム。
【請求項１２】
前記負荷分散サーバは、前記データ要求に応じてデータ送信を行う際に、該要求されたデータに対応した前記同データ保持サーバがある場合は、該データに代えて、該同データ保持サーバから該データを取得すべき旨の取得指令を前記クライアントへ送信し、
前記クライアントは、前記負荷分散サーバから前記取得指令を受信した場合、該取得指令に従って前記同データ保持サーバへデータ要求を行い、
該同データ保持サーバは、該データ要求に基づいて前記クライアントへのデータ送信を行う
ことを特徴とする請求項１〜１１いずれかに記載のクライアントサーバシステム。
【請求項１３】
前記負荷分散サーバは、前記データ要求に応じてデータ送信を行う際に、該要求されたデータに対応した前記同データ保持サーバがある場合は、該同データ保持サーバに対して、該要求されたデータを前記クライアントへ送信すべき旨の送信指令を送信すると共に、前記クライアントに対して、該同データ保持サーバから該データが送信されてくる旨の送信予告を送信し、
前記同データ保持サーバは、前記負荷分散サーバからの前記送信指令を受信したとき、該送信指令に従って前記クライアントへのデータ送信を行い、
前記クライアントは、前記負荷分散サーバから前記送信予告を受信した場合、該送信予告に従って、前記同データ保持サーバから送信されてくるデータを取得する
ことを特徴とする請求項１〜１１いずれかに記載のクライアントサーバシステム。
【請求項１４】
前記負荷分散サーバが実行する前記調査は、前記要求されたデータを持っているか否かを前記他のサーバ全てに対して問い合わせすることにより行われることを特徴とする請求項１〜１３いずれかに記載のクライアントサーバシステム。
【請求項１５】
前記クライアントはＷｅｂブラウザであり、前記サーバはいずれもＷｅｂサーバであることを特徴とする請求項１〜１４いずれかに記載のクライアントサーバシステム。
【請求項１６】
請求項１〜１５いずれかに記載のクライアントサーバシステムで前記負荷分散サーバとして使用されるサーバであって、
前記データ要求に応じて送信すべきデータを、当該サーバ以外の他のサーバが持っているかどうか調査する調査手段と、
前記調査の結果、前記他のサーバの中で前記データを持つサーバがあった場合に、該サーバを、該データに対応した前記同データ保持サーバとして記憶媒体へ記憶する記憶手段と、
前記データ要求に応じて該要求されたデータを前記クライアントへ送信する際、前記記憶媒体の記憶内容に基づいて、該要求されたデータに対応した前記同データ保持サーバがあるか否か判断し、あるならば、該データについては該同データ保持サーバから送信させる送信元分担手段と、
を備えたことを特徴とするサーバ。
【請求項１７】
請求項１６に記載のサーバが内部に組み込まれたサーバ組み込み機器であって、当該サーバ組み込み機器に関する情報を、該組み込まれたサーバを介して前記クライアントへ送信可能である
ことを特徴とするサーバ組み込み機器。
【請求項１８】
請求項１７記載のサーバ組み込み機器であって、
当該サーバ組み込み機器の内部に組み込まれたサーバが備える前記調査手段は、当該サーバ組み込み機器と同じ機器が有るか否かを調査し、
当該サーバ組み込み機器の内部に組み込まれたサーバが備える前記記憶手段は、前記調査手段による調査の結果、当該サーバ組み込み機器と同じ機器があった場合に、該機器を同データ保持機器として前記記憶媒体へ記憶し、
当該サーバ組み込み機器の内部に組み込まれたサーバが備える前記送信元分担手段は、前記データ要求に応じて該要求されたデータを前記クライアントへ送信する際、前記記憶媒体に前記同データ保持機器が記憶されていれば、該要求されたデータを該同データ保持機器から送信させることを特徴とするサーバ組み込み機器。
【請求項１９】
請求項１３記載のクライアントサーバシステムで使用されるクライアントであって、
前記送信予告を受信する受信手段と、
該受信手段にて受信した前記送信予告に従って、前記同データ保持サーバから送信されてくるデータを取得する取得手段と、
を備えたことを特徴とするクライアント。
【請求項２０】
請求項１６に記載のサーバにおける前記各手段としてコンピュータを機能させるためのプログラム。
【請求項２１】
請求項２０記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。
【請求項２２】
クライアントと複数の印刷装置との間で複数のイメージファイルで構成されたメインページデータを送受信可能に構成され、該クライアントからの前記メインページデータの要求に応じて、前記印刷装置から前記メインページデータを前記クライアントへ送信するように構成されたクライアントサーバシステムであって、
前記印刷装置の少なくとも一つは、
前記クライアントからの前記メインページデータの要求に応じて、送信すべきメインページデータを構成する前記イメージファイルが当該印刷装置以外の他の印刷装置に記憶されているか否かを調査する調査手段と、
その調査手段により前記イメージファイルが記憶されている他の印刷装置があることが検出されると、該イメージファイルを前記他の印刷装置から送信させる送信元分担手段とから構成された、負荷分散サーバである
ことを特徴とするクライアントサーバシステム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、クライアントと複数のサーバとが相互にデータ送受信可能に構成されたクライアントサーバシステム、サーバ、サーバ組み込み機器、クライアント、プログラム及び記録媒体に関し、特に、クライアントからのデータ要求に伴うサーバ側の処理負荷を軽減可能なクライアントサーバシステム、サーバ、サーバ組み込み機器、クライアント、プログラム及び記録媒体に関する。
【０００２】
【従来の技術】
近年、ネットワークプリンタやルータなど、コンピュータに接続される各種周辺デバイスでは、組み込み型Ｗｅｂサーバを内蔵するものが主流となってきている（例えば、特許文献１参照）。
【０００３】
図２２は、パーソナルコンピュータ（以下「パソコン」という）に組み込み型Ｗｅｂサーバ内蔵のプリンタが接続されたシステムにおいて、パソコンが備えるＷｅｂブラウザから、プリンタの状態確認や設定等のためにプリンタ内蔵のＷｅｂサーバにアクセスした場合の、パソコン側の表示デバイスに表示される管理設定画面（メインページ）の一例である。
【０００４】
プリンタに内蔵のＷｅｂサーバは、パソコン等のクライアントが備えるＷｅｂブラウザから図２２の管理設定画面の表示要求（ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ　ＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）によるＧＥＴリクエスト）があると、クライアント側でその画面を表示させるためのＨＴＭＬ（Ｈｙｐｅｒｔｅｘｔ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）データを作成して、クライアントへ送信する。そして、ＷｅｂブラウザがこのＨＴＭＬデータを受信・解析することにより、図２２のメインページが表示される。
【０００５】
このメインページを起点として、オペレータが、例えばこの画面内でハイパーリンクの埋め込まれた文字や画像をクリックすることにより、プリンタ内蔵のＷｅｂサーバ経由でプリンタの状態（ステータス情報）や消耗品の残量等を取得して表示したり、各種設定を行ったりすることができる。つまりＷｅｂブラウザによりクライアント側で簡易にプリンタを管理できるのである。
【０００６】
ところで、図２２に示したプリンタ管理設定用のメインページでは、メーカ名７１，プリンタモデル名７２，青ボタン７３，緑ボタン７４，赤ボタン７５，信号機７６〜７８及びプリンタ外観７９、の９種類の画像が表示されているが、これらの各画像を表示させるにあたっては、Ｗｅｂブラウザは各画像毎にＷｅｂサーバへＨＴＴＰ接続する必要がある。
【０００７】
即ち、Ｗｅｂブラウザから図２２のメインページの表示要求があると、Ｗｅｂサーバは、例えば図２３に示すようなＨＴＭＬデータを作成してクライアント側へ送信する。このＨＴＭＬデータ中には、上記各画像のデータそのものは含まれておらず、＜ＩＭＧ　ＳＲＣ＝・・・＞で記述される、画像ファイルの所在を示すタグが含まれる。尚、画像ファイルの所在はＵＲＬ（Ｕｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｌｏｃａｔｏｒ）で記述される。
【０００８】
そして、Ｗｅｂブラウザは、このＨＴＭＬデータを解釈して図２２の管理設定画面を表示させる際、＜ＩＭＧ　ＳＲＣ＝・・・＞のような記述がある度に、ＷｅｂサーバへＨＴＴＰ接続して画像ファイルのＧＥＴリクエスト（指定されたＵＲＬから画像データのダウンロード）を行って、上記タグの代わりに画像ファイルを配置するのである。
【０００９】
そのため、図２２の管理設定画面を表示させるにあたり、図２３に示したメインページのＨＴＭＬデータ取得及び各画像ファイル（９種類）の取得のために、実に１０回ものＷｅｂサーバへのＨＴＴＰ接続が行われ、そのＨＴＴＰ接続がある度に、ＷｅｂサーバではＷｅｂブラウザからの各種要求に応えることになる。
【００１０】
【発明が解決しようとする課題】
しかしながら、特に、Ｗｅｂサーバが組み込まれたプリンタやルータ等の各種組み込み機器は、一般に、ＣＰＵの性能がパソコン（Ｗｅｂサーバ専用コンピュータ）よりも低い場合がほとんどであるため、上記のようにＷｅｂブラウザからのＨＴＴＰ接続要求が多いと、組み込み機器本来の機能に影響を及ぼしてしまうおそれがあった。
【００１１】
つまり、Ｗｅｂブラウザが画像ファイル等のＧＥＴリクエストを多数行うと、その分組み込み機器におけるＷｅｂサーバとしての処理（組み込み機器内のＷｅｂサーバによるＨＴＴＰ処理）の負荷が大きくなり、本来の処理（例えば組み込み機器がプリンタの場合、そのとき実行中の印刷処理など）に多大な影響を与えてしまうのである。
【００１２】
また、上記のようにＷｅｂブラウザからのＨＴＴＰ接続要求が多いと、Ｗｅｂブラウザのページ表示速度にも影響を及ぼしてしまうおそれがあった。
【００１３】
つまり、Ｗｅｂブラウザが画像ファイル等のＧＥＴリクエストを多数行うと、その分組み込み機器におけるＷｅｂサーバとしての処理（組み込み機器内のＷｅｂサーバによるＨＴＴＰ処理）の負荷が大きくなり、ＷｅｂブラウザからのＧＥＴリクエストに素早く対応することができなくなってしまうのである。
【００１４】
本発明は上記課題に鑑みなされたものであり、クライアントと複数のサーバとが相互にデータ送受信可能に構成されたクライアントサーバシステムにおいて、クライアントからのデータ要求に伴うサーバ側の処理負荷を軽減するクライアントサーバシステム、サーバ、サーバ組み込み機器、クライアント、プログラム及び記録媒体を提供することを目的とする。
【００１５】
【特許文献１】
特開平１０−２６９０３６号公報
【００１６】
【課題を解決するための手段及び発明の効果】
上記課題を解決するためになされた請求項１記載のクライアントサーバシステムは、クライアントと複数のサーバとが相互にデータ送受信可能に構成され、該クライアントからのデータ要求に応じてサーバが該要求されたデータをクライアントへ送信するよう構成されたものである。
【００１７】
そして、本発明では、サーバの少なくとも一つが、データ要求に応じて送信すべきデータを当該サーバ以外の他のサーバが持っているかどうか調査し、データ要求に応じたデータ送信を行う際、他のサーバの中で該要求されたデータを持つ同データ保持サーバがあれば、該データについては当該サーバから直接送信せず同データ保持サーバから送信させるよう構成された、負荷分散サーバである。
【００１８】
つまり、クライアントから負荷分散サーバへデータ要求があったとき、要求されたデータを負荷分散サーバ自らがクライアントへ送信するのではなく、送信すべきデータを持つサーバが他にあれば、そのデータについては他のサーバ（同データ保持サーバ）にクライアントへの送信を代理させるのである。このように、クライアントからの要求に応じたデータ送信の処理負荷を他のサーバに分散させることにより、負荷分散サーバの処理負荷を軽減することが可能となる。また、負荷分散サーバの処理負荷が軽減されることによって、クライアントからの要求に素早く対応することが可能となり、結果として、クライアントは要求したデータを早期に取得することが可能となる。
【００１９】
ここで、上記調査のタイミングとしては、例えば請求項２記載のように、クライアントからのデータ要求の有無に関わらず所定のタイミングで実行するようにしてもいいし、また例えば請求項７記載のように、クライアントからデータ要求があったときに調査を実行するようにしてもよい。
【００２０】
前者（請求項２）の場合、同データ保持サーバの有無を予め調べておくことになるため、負荷分散サーバの処理負荷軽減という効果に加え、クライアントからのデータ要求時にその調査結果に基づいて即座に対応でき、クライアント側でデータを迅速に取得することも可能となる。
【００２１】
一方、後者（請求項７）の場合、クライアントからのデータ要求時に調査を行うため、データ要求時点のまさに最新のクライアントサーバシステムにおける同データ保持サーバを探すことになるため、より確実にクライアントへの送信を代理させる（延いては、要求したデータをクライアントが確実に取得する）ことができる。
【００２２】
請求項２に記載したように負荷分散サーバが所定のタイミングで調査を実行する場合は、更に、例えば請求項３に記載のように、当該負荷分散サーバ自身の処理負荷量を示す負荷状況度が、該処理負荷量が多大であるか否かの判断基準となる所定の上位レベルより大きいときに、その調査を実行するようにするとよい。
【００２３】
つまり、負荷分散サーバは、自身の負荷状況度を把握した上で、負荷状況度が小さくて処理負荷量に余裕があるときは、必ずしもクライアントからのデータ要求を他のサーバに代理してもらう必要はなく自身が全て処理してもよい。そのため、負荷状況度が上位レベルより大きい（即ち、処理負荷量が多大である）と判断した場合に限り、同データ保持サーバを調査するのである。そのため、同データ保持サーバの調査を頻繁に実行することがなく非常に効率的である。
【００２４】
また、例えば請求項４に記載のように、負荷分散サーバが所定のタイミングで調査を実行する場合、負荷状況度が、該処理負荷量に余裕があるか否かの判断基準となる所定の下位レベルに満たないとき、若しくは、当該クライアントサーバシステムを構成するクライアントと複数のサーバ相互間のデータ送受信量を示すトラフィックレベルが、所定の基準レベルに満たないときに、その調査を実行するようにしてもよい。
【００２５】
これはつまり、負荷分散サーバ自身の処理負荷量が少ないときは負荷分散サーバの処理能力に余裕があり、システム全体のトラフィックが少ないときは負荷分散サーバと他のサーバとの間の通信経路上を流れるデータ量に余裕があるわけであって、そのような余裕がある状態を上記調査に費やすものである。こうすることによって、サーバにおける他の処理あるいはシステムにおける他の通信に影響を与えずに済む。
【００２６】
また、例えば請求項５に記載のように、負荷分散サーバが所定のタイミングで調査を実行する場合、他のサーバが接続されたネットワークに対して新たに当該負荷分散サーバが参加し、当該負荷分散サーバがネットワークを介して他のサーバと通信可能な状態になったときに、あるいは、当該負荷分散サーバが接続されたネットワークに対して新たに他のサーバが参加し、当該他のサーバがネットワークを介して負荷分散サーバと通信可能な状態になったときに、その調査を実行するようにしてもよい。
【００２７】
つまり、負荷分散サーバあるいは他のサーバが新たにネットワークに接続され、ネットワークの環境に変化が生じたときに調査を行うので、適切なタイミングにて調査を行うことが可能となる。
【００２８】
さらに、例えば請求項６に記載のように、過去に通信可能であった他のサーバについて、現在も通信可能であるか否かを判断して、通信不能であると判断されたときに、その調査を実行するようにしてもよい。
【００２９】
つまり、過去に通信可能であった他のサーバとの通信が不能となった、すなわち、ネットワークの環境に変化が生じたときに調査を行うので、適切なタイミングにて調査を行うことが可能となる。
【００３０】
また、請求項７に記載のように、クライアントからのデータ要求時に調査を行う場合は、更に、例えば請求項８に記載のように、クライアントからのデータ要求に応じてデータの送信を行った後、当該データの送信から所定期間内に同一のクライアントから同一のデータを要求されたときに、その調査を実行するとよい。
【００３１】
つまり、前回のデータ送信から所定期間内に同一のクライアントから同一のデータを要求された状況というのは、同データ保持サーバからクライアントへのデータ送信が正常に行われなかったため、クライアントが再度同一のデータを要求してきたという状況が想定される。そのため、このような状況が想定されるとき、データ要求に応じて送信すべきデータを他のサーバが持っているかどうかを調査することで、極めて必要性の高いときに調査を行うことが可能となる。
【００３２】
また、負荷分散サーバは更に、例えば請求項９に記載のように、上記調査として、他のサーバ各々について該他のサーバの処理負荷量にどの程度の余裕があるかを示す負荷余裕度も調査し、同データ保持サーバの負荷余裕度が分散可能レベルに満たない場合は、該同データ保持サーバからクライアントへのデータ送信をさせないようにするものであるとよい。
【００３３】
即ち、負荷分散サーバの処理負荷量を軽減するために、クライアントへのデータ送信を他の同データ保持サーバに代理させるようにすると、同データ保持サーバの処理負荷量が非常に多大である場合、その同データ保持サーバにて実行中の処理に悪影響を及ぼしてしまうおそれがある。
【００３４】
そのため、無条件に同データ保持サーバに代理してもらうのではなく、同データ保持サーバの負荷余裕度が分散可能レベルに満たない（処理負荷量に余裕がない）ときは、その同データ保持サーバには代理させないようにするのである。そのため、負荷分散サーバの処理負荷を軽減する反面他のサーバが実行中の処理に影響を及ぼしてしまうといった弊害を防止することができる。
【００３５】
また、負荷分散サーバは、例えば請求項１０に記載のように、…ものであるとよい。
【００３６】
更にまた、負荷分散サーバは、例えば請求項１１に記載のように、データ要求に応じて送信すべきデータを送信させるようにした同データ保持サーバを、該データに対する送信実行サーバとして記憶しておき、データ要求に応じてデータ送信を行う際に、該要求されたデータを持つ同データ保持サーバが複数ある場合、該複数の同データ保持サーバの中に送信実行サーバとして記憶された同データ保持サーバがあれば、該同データ保持サーバからデータを送信させるようにするものであるとよい。
【００３７】
つまり、クライアントからのデータ要求に応じたデータ送信を他の同データ保持サーバに代理させる際に、同データ保持サーバが複数ある場合は、その複数ある同データ保持サーバのうち、過去に当該データの送信を代理させたことがあって送信実行サーバとして記憶されている同データ保持サーバに、優先的に代理させるのである。
【００３８】
これによる効果としては、サーバよりもむしろクライアント側にある。即ち、クライアントの種類・構成によっては、一度サーバから受信したデータをメモリ等にキャッシュ（保存）しておくものがあり、そのような場合に、キャッシュされたデータが再び必要となった場合、再度サーバから送ってもらうのではなく、キャッシュされたデータを利用することができる。
【００３９】
ここで、負荷分散サーバが、クライアントから要求されたデータを同データ保持サーバから送信させる具体的方法としては、当該負荷分散サーバからはデータそのものを直接クライアントへ送ることなく結果的にクライアントがそのデータを取得できる限り、種々の方法を取りうるが、例えば請求項１２に記載のように、データ要求に応じてデータ送信を行う際に、該要求されたデータに対応した同データ保持サーバがある場合は、該データに代えて、該同データ保持サーバから該データを取得すべき旨の取得指令をクライアントへ送信し、その取得指令を受信したクライアントが、該取得指令に従って同データ保持サーバへデータ要求を行い、そのデータ要求を受けた同データ保持サーバが、該データ要求に基づいてクライアントへのデータ送信を行うよう構成することができる。
【００４０】
このようにすれば、クライアントからのデータ要求を受けた負荷分散サーバは、クライアントに対し、データの代わりに、例えば「あのサーバ（ある特定の同データ保持サーバ）にデータ要求してそこから取得せよ」といった指示（取得指令）を送信すればよいため、負荷分散サーバの処理負荷軽減が可能となる。
【００４１】
また、上記説明した請求項１２記載のシステム構成以外にも、例えば請求項１３に記載のように、負荷分散サーバは、データ要求に応じてデータ送信を行う際に、該要求されたデータに対応した同データ保持サーバがある場合は、該同データ保持サーバに対して、該要求されたデータをクライアントへ送信すべき旨の送信指令を送信すると共に、クライアントに対して、該同データ保持サーバから該データが送信されてくる旨の送信予告を送信し、同データ保持サーバは、負荷分散サーバからの送信指令を受信したとき、該送信指令に従ってクライアントへのデータ送信を行い、クライアントは、負荷分散サーバから送信予告を受信した場合、該送信予告に従って、同データ保持サーバから送信されてくるデータを取得するよう構成してもよい。
【００４２】
このように構成されたクライアントサーバシステムでは、クライアントへのデータ送信に加えて、同データ保持サーバへ送信指令も送る必要があるため、上記請求項１２の方法に比べると若干負荷分散サーバの処理負荷量が多くなるが、それでも、クライアントから要求されたデータそのものを直接送る場合に比べれば、十分に処理負荷が軽減される。しかもこの構成では、クライアントにとって、同データ保持サーバへ逐一データ要求をする必要がなく、同データ保持サーバからのデータ送信を待つのみでいいため、クライアント側の処理負荷も軽減される。
【００４３】
そして、負荷分散サーバが実行する調査は、例えば請求項１４に記載のように、要求されたデータを持っているか否かを他のサーバ全てに対して問い合わせすることにより行うとよい。具体的手法としては、情報通信ネットワークにおける所定領域内に接続された全ての機器にデータを送信する周知のブロードキャストなどが挙げられる。
【００４４】
また、本発明のクライアントサーバシステムは、例えば請求項１５に記載のように、クライアントがＷｅｂブラウザであり、複数のサーバがいずれもＷｅｂサーバとして構成されたシステムに適用可能である。即ち、従来技術の欄で説明したパソコン（Ｗｅｂブラウザ内蔵）とプリンタ（Ｗｅｂサーバ内蔵）とが接続された構成に対して、本発明を適用することができるのである。
【００４５】
既述の通り、ＷｅｂブラウザにてＨＴＭＬデータを解釈して画像ファイル等を表示させる場合、画像ファイル毎に逐一Ｗｅｂサーバへ接続して取得する必要がある。そのため、Ｗｅｂサーバの処理負荷が増加するという問題が生じていたのだが、本発明によれば、メインページのＨＴＭＬデータを送信したＷｅｂサーバ以外の他のサーバから画像ファイル等を取得させるようにできるため、Ｗｅｂサーバの処理負荷を軽減することが可能となる。
【００４６】
次に、請求項１６記載の発明は、請求項１〜１５いずれかに記載のクライアントサーバシステムで負荷分散サーバとして使用されるサーバであって、調査手段が、データ要求に応じて送信すべきデータを当該サーバ以外の他のサーバが持っているかどうか調査し、その調査の結果、他のサーバの中で前記データを持つサーバがあった場合に、記憶手段が、該サーバを該データに対応した同データ保持サーバとして記憶媒体へ記憶する。
【００４７】
そして、要求されたデータをクライアントへ送信する際、送信元分担手段が、記憶媒体の記憶内容に基づいて該要求されたデータに対応した同データ保持サーバがあるか否かを判断し、あるならば、該データについては該同データ保持サーバから送信させる。
【００４８】
つまり、調査手段による調査結果を記憶媒体へ記憶しておき、実際にクライアントからデータ要求があったとき、記憶媒体の記憶内容に基づいて、どのサーバにデータ送信を代理させるかを決めるものである。サーバをこのように構成することにより、クライアントからのデータ要求時にデータ送信を他のサーバに代理させることができるため、サーバの処理負荷を軽減することが可能となる。
【００４９】
次に、請求項１７記載の発明は、請求項１６に記載のサーバが内部に組み込まれたサーバ組み込み機器であって、当該サーバ組み込み機器に関する情報を、該組み込まれたサーバを介して前記クライアントへ送信可能となるよう構成されたものである。つまり、従来技術の欄で説明した組み込み型Ｗｅｂサーバ内蔵プリンタのように、各種機器に本発明のサーバが内蔵されたものである。
【００５０】
このように、本発明のサーバを各種機器の内部に組み込むことにより、外部（クライアント）へその機器に関するデータを送信することができる。しかも、クライアントへのデータ提供の際、送信すべきデータを持ったサーバ組み込み機器が他にあれば、そのサーバ組み込み機器にそのデータ送信を代理させることができるため、処理負荷を軽減可能なサーバが組み込まれた機器の提供が可能となる。
【００５１】
そして、上記構成のサーバ組み込み機器は、より具体的には、例えば請求項１８に記載のように、組み込まれたサーバが備える調査手段は、当該サーバ組み込み機器と同じ機器が有るか否かを調査し、組み込まれたサーバが備える記憶手段は、調査手段による調査の結果、当該サーバ組み込み機器と同じ機器があった場合に該機器を同データ保持機器として記憶媒体へ記憶し、組み込まれたサーバが備える送信元分担手段は、要求されたデータをクライアントへ送信する際、記憶媒体に同データ保持機器が記憶されてれば、該要求されたデータを該同データ保持機器から送信させるよう構成することができる。
【００５２】
つまり、自身と同じ機器があれば、自身が持つデータをその同じ機器も持っているものと考えられる。そこで、その自身と同じ機器を同データ保持機器とするのである。このように、自身と同じ機器があるか否かを調査するだけで同データ保持機器を探索・記憶できるため、より簡易な構成のサーバ（延いてはより簡易な構成のサーバ組み込み機器）の提供が可能となる。
【００５３】
そして、請求項１９記載の発明は、請求項１３記載のクライアントサーバシステムで使用されるクライアントであって、受信手段にて受信した送信予告に従って、取得手段が、同データ保持サーバから送信されてくるデータを取得するよう構成されたものである。即ち、当該クライアント自らが同データ保持サーバへ逐一データ要求をする必要がなく、同データ保持サーバからのデータ送信を待つのみでいいため、当該クライアントの処理負荷の軽減が可能となる。
【００５４】
また、本発明のサーバ（請求項１６）は、例えば別途ハードウェアにより実現することができるなど、種々の方法により実現可能であるが、請求項２０に記載のように、コンピュータがアプリケーションソフト（プログラム）を実行することにより実現することができる。
【００５５】
即ち、当該サーバにおける各手段としてコンピュータを機能させるためのプログラムを備え、コンピュータがそのプログラムを実行することにより、本発明のサーバを実現するのである。
【００５６】
そして、コンピュータを本発明のサーバとして機能させるためのプログラムは、例えば、請求項２１に記載のように、フロッピー（登録商標）ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ハードディスク等のコンピュータ読み取り可能な記録媒体に記録し、必要に応じてコンピュータにロードして起動することにより用いることができる。この他、ＲＯＭやバックアップＲＡＭをコンピュータ読み取り可能な記録媒体としてプログラムを記録しておき、このＲＯＭあるいはバックアップＲＡＭをコンピュータに組み込んで用いてもよい。
【００５７】
また、請求項２２記載の発明は、クライアントと複数の印刷装置との間で複数のイメージファイルで構成されたメインページデータを送受信可能に構成され、該クライアントからの前記メインページデータの要求に応じて、前記印刷装置から前記メインページデータを前記クライアントへ送信するように構成されたクライアントサーバシステムであって、前記印刷装置の少なくとも一つが、前記クライアントからの前記メインページデータの要求に応じて、送信すべきメインページデータを構成する前記イメージファイルが当該印刷装置以外の他の印刷装置に記憶されているか否かを調査する調査手段と、その調査手段により前記イメージファイルが記憶されている他の印刷装置があることが検出されると、該イメージファイルを前記他の印刷装置から送信させる送信元分担手段とから構成された、負荷分散サーバである。
【００５８】
つまり、クライアントから負荷分散サーバとしての印刷装置へメインページデータの要求があったとき、要求されたメインページデータを構成するイメージファイルの全てを前記印刷装置自らがクライアントへ送信するのではなく、送信すべきイメージファイルが記憶された他の印刷装置があれば、そのイメージファイルについては他の印刷装置にクライアントへの送信を代理させるのである。このように、クライアントからの要求に応じたメインページデータの送信の処理負荷を他の印刷装置に分散させることにより、負荷分散サーバの処理負荷を軽減することが可能となる。また、負荷分散サーバの処理負荷が軽減されることによって、クライアントからの要求に素早く対応することが可能となり、結果として、クライアントは要求したメインページデータを早期に取得することが可能となる。
【００５９】
なお、サーバ以外に、本発明のクライアント（請求項１９）についても、上記同様に、コンピュータがアプリケーションソフト（プログラム）を実行することにより実現することができる。
【００６０】
【発明の実施の形態】
以下に、本発明の好適な実施形態を図面に基づいて説明する。
【００６１】
［第１実施形態］
図１は、本実施形態のネットワークシステムの概略構成を示すブロック図である。図１に示す如く、本実施形態のネットワークシステムは、クライアントとしてのパソコン（以下「クライアントＰＣ」という）７と、サーバ組み込み機器としての複数の印刷装置としてのプリンタ１〜６がそれぞれ、ＬＡＮ等のネットワーク８を介して相互にデータ送受信可能に接続されている。尚、図示は省略したものの、ネットワーク８には、クライアントＰＣ７以外に他の複数のクライアントＰＣが接続されており、各クライアントＰＣにて生成した印刷ジョブを、各プリンタ１〜６にて印刷出力できる。
【００６２】
クライアントＰＣ７は、Ｗｅｂブラウザ３１を内蔵しており、このＷｅｂブラウザ３１を用いて、各プリンタ１〜６の各種管理・設定等を行うことができる。また、各プリンタ１〜６はいずれも、基本的構成は同じであるため、以下の説明においては、プリンタ１について説明する。
【００６３】
プリンタ１は、ＣＰＵ１１，ＲＯＭ１２，ＲＡＭ１３，データベース１４，ユーザＩ／Ｆ１５，出力Ｉ／Ｆ１６，印刷出力部１７及びネットワークＩ／Ｆ１８により構成されている。
【００６４】
ＣＰＵ１１は、ＲＯＭ１２に格納された各種プログラムに基づき、プリンタ１における各種制御を実行するものであるが、本実施形態では特に、Ｗｅｂサーバ２１，ＳＮＭＰマネージャ２２及びＳＮＭＰエージェント２３としての機能を備えたものである。
【００６５】
クライアントＰＣ７が備えるＷｅｂブラウザ３１からは、このＷｅｂサーバ２１へＨＴＴＰ接続することができ、これにより、クライアントＰＣ７が備える図示しない表示装置に、図２２に示すプリンタ管理設定画面（メインページ）が表示される。そのため、クライアントＰＣ７では、Ｗｅｂブラウザ３１により、プリンタ１の状態確認や各種設定等を行うことができる。
【００６６】
一方、ＳＮＭＰ（Ｓｉｍｐｌｅ　Ｎｅｔｗｏｒｋ　Ｍａｎａｇｅｍｅｎｔ　Ｐｒｏｔｏｃｏｌ）は、ネットワークに接続された各種機器をネットワーク経由で監視・制御するための周知のプロトコルであり、本実施形態では、ＳＮＭＰマネージャ２２が他のプリンタ２〜６に対し、ＭＩＢ（Ｍａｎａｇｅｍｅｎｔ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｂａｓｅ）のオブジェクト識別子（ＯＩＤ）を指定して所望の情報を取得することができる。逆に、他のプリンタ２〜６からＯＩＤの指定により情報取得要求があったとき、ＳＮＭＰエージェント２３が、指定されたＭＩＢのデータを返信する。
【００６７】
ＲＡＭ１３には、当該プリンタ１が動作開始したとき、イメージファイル参照管理テーブル２６及びデバイス参照回数管理表２７が生成される。そして、イメージファイル参照管理テーブル２６は、ＳＮＭＰマネージャ２２が他の各プリンタ２〜６に関する各種情報を収集する毎に、その情報に基づいて内容が更新され、デバイス参照回数管理表２７は、イメージファイル参照管理テーブル２６の内容が更新される度にクリアされるものであるが、これらの詳細については後述する。
【００６８】
データベース１４は、例えばハードディスク等の各種ストレージデバイスにより構成され、その内部には、Ｗｅｂブラウザ３１からの要求に応じてＨＴＭＬデータを作成するために必要な各種データが格納されたＷｅｂページ２８と、プリンタ１の各種情報がツリー状に並べられたＭＩＢ２９とが備えられている。
【００６９】
ユーザＩ／Ｆ１５は、当該プリンタ１の状態や操作方法等を表示するための液晶表示装置や、当該プリンタ１にコマンド等を入力するためのキースイッチ等からなるものである。そして、印刷出力部１７は、クライアントＰＣ７にて生成され、ネットワーク８及びネットワークＩ／Ｆ１８を介して入力された印刷ジョブを実際に印刷媒体に印字するための機構（例えばレーザ走査機構，感光体，転写体，現像器など）を備えたものであり、出力Ｉ／Ｆ１６を介して入力される印刷データに基づく印字出力を行う。
【００７０】
このように構成された本実施形態のネットワークシステムにおいてクライアントＰＣ７と各プリンタ１〜６の相互間でやりとりされる各種情報について、図２〜５に基づき、より具体的に説明する。図２は、本実施形態のネットワークシステムにおけるデータの流れの一例を示す説明図であり、図３は、プリンタ１がＳＮＭＰのＧＥＴリクエスト（ＧＥＴ要求）をブロードキャストすることにより他のプリンタの情報を得ることを説明するための説明図であり、図４（ａ）は、プリンタ１にて作成されるイメージファイル参照管理テーブル２６の詳細であり、図４（ｂ）は、プリンタ１にて作成されるデバイス参照回数管理表２７であり、図５は、Ｗｅｂサーバ２１が生成するＨＴＭＬデータの一例を表す説明図である。
【００７１】
図２に示す如く、プリンタ１は、ネットワーク８に接続された他のデバイスに対し、所定のタイミング（例えば１０秒毎）で、ＳＮＭＰによるＧＥＴリクエストをブロードキャストする。このＧＥＴリクエストの内容は、具体的には図３で▲１▼〜▲３▼に示す通りであり、▲１▼デバイスのモデル名（ｈｒＤｅｖｉｃｅＤｅｓｃｒ）、▲２▼デバイスの処理負荷量にどの程度の余裕があるかを示す負荷余裕度としてのアイドル率（ｃｕｒｒｅｎｔ　ＣＰＵ　Ｓｔａｔｕｓ）及び、▲３▼デバイスが持っている画像ファイル（ｅｍｂｅｄｄｅｄ　Ｉｍａｇｅ　Ｓｕｐｐｏｒｔｅｄ：以下「イメージファイル」という）、をブロードキャストにより問い合わせすることになる。尚、このＧＥＴリクエストは、実際には、ＯＩＤを指定することにより行われるものであり、例えばモデル名の場合、対応するＯＩＤである「１．３．６．１．２．１．２５．３．２．１．３．１」を指定する。
【００７２】
そして、プリンタ１からのＧＥＴリクエストのブロードキャストにより、各デバイス（本例ではプリンタ２〜６）から、上記各▲１▼〜▲３▼に対応した情報がＧＥＴレスポンスとして返ってくる。図３に示す如く、例えばＩＰアドレスが１０．１３４．４３．２２であるプリンタ２からは、▲１▼「ＡＢＣ社　○○△△□□」というモデル名と、▲２▼「４０」（単位：％）というアイドル率と、▲３▼「１０１，１０２，１０３，・・・・・・，７９４，８７２，９０２」というそのプリンタが持っているイメージファイルの固有ＩＤと、が返信されてくる。他のプリンタ３〜６についても、図３に示すように、それぞれ上記▲１▼〜▲３▼に対応した情報がプリンタ１へ返送されることになる。
【００７３】
一方、プリンタ１が起動したときは、既述の通りＲＡＭ１３内に、図４（ａ）に示すイメージファイル参照管理テーブル２６と、図４（ｂ）に示すデバイス参照回数管理表２７とが作成される。尚、この起動時は、イメージファイル参照管理テーブル２６の各項目のうち、イメージファイル名及びその固有ＩＤとが予め設定されるものの、その他の項目（「ＩＰ１」〜「ＩＰｎ」及び「Ｌａｔｅｓｔ　ＩＰ」）は未設定のままである。また、デバイス参照回数管理表２７については、表自体は作成されるものの、「ＩＰアドレス」及び「参照回数」のいずれの項目も未設定の状態である。
【００７４】
イメージファイル名としては、「Ｒｅｄ　Ｂｕｔｔｏｎ」（赤ボタン）、「Ｇｒｅｅｎ　Ｂｕｔｔｏｎ」（緑ボタン）、「Ｂｌｕｅ　Ｂｕｔｔｏｎ」（青ボタン）、「○○△△□□　Ｍｏｄｅｌ　Ｌｏｇｏ」（モデル名）など、図２２に示すメインページにて使用されるイメージファイルの種類（本例では既述の通り９種類）だけ設定される。そして、これら各イメージファイルにはそれぞれ、プリンタメーカにて管理している固有ＩＤが与えられており、その固有ＩＤを、イメージファイル毎にイメージファイル参照管理テーブル２６の「固有ＩＤ」の列に設定していく。図２２に示すメインページは、上述したように、複数のイメージファイルから構成されている。
【００７５】
このように起動時に作成されたイメージファイル参照管理テーブル２６における未設定項目を、上記ブロードキャストにより得られた各プリンタ毎の情報▲１▼〜▲３▼に従って埋めていくことになる。具体的には、各プリンタ２〜６からのＧＥＴレスポンス中、▲３▼の情報（プリンタ所有のイメージファイルの固有ＩＤ）に基づいて、各プリンタ２〜６がそれぞれ、イメージファイル参照管理テーブル２６の最左列に設定されている各イメージファイルを所有しているか否かを判断し、所有している場合、そのイメージファイルに対応した「ＩＰ１〜」の欄にそのプリンタのＩＰアドレスを登録する。
【００７６】
本実施形態では、プリンタ２及びプリンタ３は、プリンタ１と全く同じ機種である。そのため、これらプリンタ２，３はいずれも、プリンタ１が持っているイメージファイル（イメージファイル参照管理テーブル２６最左列に設定されたイメージファイル）を全て持っており、これらプリンタ２，３からのＧＥＴレスポンス中の▲３▼の情報には、全てのイメージファイルの固有ＩＤが含まれていることになる。また、他のプリンタ４〜６については、プリンタ１とは同機種ではないものの、一部のイメージファイルについては持っているものもある。
【００７７】
そのため、本実施形態では、イメージファイル参照管理テーブル２６に、図４（ａ）に示す如くＩＰアドレスが書き込まれる。例えば「Ｒｅｄ　Ｂｕｔｔｏｎ」（赤ボタン）の場合、そのイメージファイルをプリンタ２（ＩＰ：１０．１３４．４３．２２），プリンタ３（ＩＰ：１０．１３４．４３．１３），プリンタ４（ＩＰ：１０．１３４．４３．５６）及びプリンタ５（ＩＰ：１０．１３４．４３．１２）がそれぞれ持っているため、「Ｒｅｄ　Ｂｕｔｔｏｎ」の行の「ＩＰ１」〜「ＩＰｎ」の欄にはこれら各プリンタ２〜５のＩＰアドレスが登録される。他のイメージファイルについても同様であり、図４（ａ）に示す如くそれぞれＩＰアドレスが登録される。
【００７８】
尚、本実施形態では、イメージファイルを持っているプリンタのＩＰアドレスを単純に全て登録するのではなく、▲２▼のアイドル率を考慮して、アイドル率が所定レベル（本実施形態では５０％）以上の場合のみ、即ち、プリンタの処理負荷量に余裕があるときにのみ、そのプリンタのＩＰアドレスを書き込むようにしている。尚、この「５０％」は本発明の分散可能レベルに相当するものである。
【００７９】
一方、クライアントＰＣ７のＷｅｂブラウザ３１から、図２２に示したメインページを表示させるべくＨＴＴＰのＧＥＴリクエスト（メインページのＨＴＭＬのリクエスト；図２の▲１▼）があると、プリンタ１内蔵のＷｅｂサーバ２１が、メインページのＨＴＭＬデータを作成する。
【００８０】
このとき、図２３で説明したように、各イメージファイルについては、そのイメージファイルの所在ＵＲＬを＜ＩＭＧ　ＳＲＣ＝・・・＞のタグで指定したＨＴＭＬが作成されるわけだが、本実施形態では、従来のように全て自身のプリンタ内部のＵＲＬを指定するのではなく、イメージファイル毎に、他のプリンタ２〜６のＵＲＬを適宜指定することにより、クライアントＰＣ７がプリンタ２〜６にイメージファイルを要求する（つまりプリンタ１の処理負荷を分散する）ようにしている。
【００８１】
具体的には、図５に示すようなメインページのＨＴＭＬデータが作成され、クライアントＰＣ７へ送信されることになる（図２の▲２▼）。図５と図２３を比較して明らかなように、本実施形態のＨＴＭＬデータ（図５）では、イメージファイルの参照先として、当該プリンタ１以外の他のプリンタを示すＵＲＬを指定している。例えば「モデル名」の参照先として、ＩＰアドレスが１０．１３４．４３．２２であるプリンタ２を指定し、「Ｂｌｕｅ　Ｂｕｔｔｏｎ」（青ボタン）の参照先として、ＩＰアドレスが１０．１３４．４３．１４であるプリンタ６を指定し、「Ｇｒｅｅｎ　Ｂｕｔｔｏｎ」（緑ボタン）の参照先として、ＩＰアドレスが１０．１３４．４３．１３であるプリンタ３を指定している。他のイメージファイルについても、図示は省略したものの、プリンタ２〜６のいずれかを参照先として指定する。
【００８２】
この参照先ＩＰアドレス（プリンタ）の指定は、イメージファイル参照管理テーブル２６に基づいて行われる。即ち、例えば「Ｒｅｄ　Ｂｕｔｔｏｎ」（赤ボタン）の参照先を決める場合、まず最初に「Ｌａｔｅｓｔ　ＩＰ」の列にＩＰアドレスが登録されているか否かをみて、登録されていればそのＩＰアドレスを参照先として指定することになり、登録されていなければ、「ＩＰ１」〜「ＩＰｎ」の列に書き込まれているＩＰアドレスのいずれかを指定することになる。尚、図５のＨＴＭＬデータにおいて、イメージファイルの参照先を指定したタグ（＜ＩＭＧ　ＳＲＣ＝・・・＞）が、本発明の取得指令に相当するものである。
【００８３】
「Ｌａｔｅｓｔ　ＩＰ」は、最新（直前）のＨＴＭＬデータ作成時に実際に参照先として使用したＩＰアドレスであり、本実施形態では、ここに登録されたＩＰアドレスを優先するのである。即ち、参照先を指定するにあたっては、直前に使用（指定）されたＩＰアドレスを優先して指定するのである。
【００８４】
このように「Ｌａｔｅｓｔ　ＩＰ」を優先するのは、クライアントＰＣ７が過去にあるイメージファイルをあるプリンタから取得したことがある場合、そのイメージファイルは、クライアントＰＣ７内の図示しないメモリ等にキャッシュデータとして保存されている。そのため、再び同じイメージファイルを取得する際に、ＨＴＭＬデータにおけるそのイメージデータの参照先として、過去（例えば直前）に指定されていて実際に参照したプリンタが再び指定されれば、クライアントＰＣ７は、そのイメージファイルについては再びプリンタへの参照は行わずにキャッシュデータの中から取得することができるのである。この「Ｌａｔｅｓｔ　ＩＰ」に登録されているプリンタは、本発明の送信実行サーバに相当するものである。
【００８５】
また、「Ｌａｔｅｓｔ　ＩＰ」にＩＰアドレスが登録されていない場合（例えば起動直後でまだ一度もＷｅｂブラウザ３１からのメインページ要求がない場合）に「ＩＰ１」〜「ＩＰｎ」の列に書き込まれているＩＰアドレスのいずれかを指定する際は、図４（ｂ）のデバイス参照回数管理表２７も利用される。プリンタ１がＳＮＭＰのＧＥＴリクエストをブロードキャストすることにより、イメージファイル参照管理テーブル２６に各プリンタのＩＰアドレスが書き込まれたとき、その書き込まれたＩＰアドレス全てが、デバイス参照回数管理表２７の「ＩＰアドレス」の列に列挙される。
【００８６】
そして、「ＩＰ１」〜「ＩＰｎ」の列に書き込まれているＩＰアドレスのいずれかを指定するにあたっては、対応する全てのＩＰアドレスの中からランダムに選んで指定するのではなく、デバイス参照回数管理表２７において「参照回数」の最も少ないＩＰアドレスを指定するのである。
【００８７】
このように個々のイメージファイルに対してそれぞれ参照先のＩＰアドレスを指定する毎に、デバイス参照回数管理表２７におけるそのＩＰアドレスの「参照回数」をインクリメントしていく。これにより、ある特定のＩＰアドレスだけに偏って指定されるといったことを防ぎ、参照可能な全てのプリンタに対して均等に指定することが可能となる。
【００８８】
プリンタ１のＷｅｂサーバ２１にて図５に例示したＨＴＭＬデータが作成され、クライアントＰＣ７へ送信されると、クライアントＰＣ７では、このＨＴＭＬデータを解釈して実際にメインページ（図２２）の表示を行うことになる。このとき、各イメージファイル７１〜７９の参照先は、図５で説明した通り、他の各プリンタ２〜６のいずれかが指定されている。そのため、各イメージファイル毎にそれぞれ指定された参照先プリンタへ、イメージファイルのＧＥＴリクエスト（ＧＥＴ要求）を行う（図２の▲３▼）。
【００８９】
このＧＥＴリクエストを受けたプリンタは、リクエストされたイメージファイルをクライアントＰＣ７へ送信する（図２の▲４▼）。これにより、クライアントＰＣ７では、そのイメージファイルが、図示しない表示装置にて表示されることになる（図２の▲５▼）。
【００９０】
次に、上記説明した本実施形態のネットワークシステムにおいて、プリンタ１にて実行される、イメージファイル参照管理テーブル２６における各イメージファイルに対応したＩＰアドレスを書き込む処理（以下「ＩＰアドレスリスト作成処理」ともいう）について、図６及び図７に基づいて説明する。図６に示す処理は、所定のタイミングで上記ＩＰアドレスリスト作成処理を実行するためのポーリングタスクであり、プリンタ１では、プリンタ１の電源が投入された直後に、ＣＰＵ１１がＲＯＭ１２からこのポーリングタスクプログラムを読み出し、このプログラムに従って処理を実行する。
【００９１】
この処理が開始されると、まずステップ（以下「Ｓ」と略す）１１０にて、当該プリンタ１自身の処理負荷量が多大か否かを判断する。この判断は、例えば、ＣＰＵ１１にて実行される低優先順位タスクの稼働率やアイドルループのヒット率などを同期割り込みによってサンプリングすることにより実現できる。そして、処理負荷量を示す負荷状況度が、予め設定した所定の上位レベルより大きいとき、処理負荷量が多大であると判断する。
【００９２】
処理負荷量が多大である場合は、Ｓ１１０で肯定判定されてＳ１３０に移行するが、多大でない場合は、Ｓ１２０に進んで、当該プリンタ１自身の処理負荷量が少ないか、若しくは、ネットワーク８の負荷が少ないか否かが判断される。プリンタ１自身の処理負荷量の検出は上記同様に実現でき、負荷状況度が、予め設定した所定の下位レベルより小さいとき、処理負荷量が少ないと判断される。また、ネットワーク８の負荷については、例えばネットワーク８上を流れるパケット数（本発明のトラフィックレベルに相当）に基づいて判断することができ、パケット数が所定の基準レベルに満たないとき、ネットワーク８の負荷が少ないと判断される。
【００９３】
そして、処理負荷量が少ないか、若しくはネットワーク８の負荷が少ないかのいずれにも該当しない場合は再びＳ１１０に戻るが、いずれかに該当する場合は、Ｓ１３０に進む。
【００９４】
Ｓ１３０では、上記のＩＰアドレスリスト作成処理が実行される。この処理の詳細は図７に示す通りであり、図７に示す如く、まずＳ２１０にて、イメージファイル参照管理テーブル２６中の「ＩＰ１」〜「ＩＰｎ」のデータを全てクリアする。続くＳ２２０では、ＳＮＭＰのＧＥＴリクエストをブロードキャストすることにより、ネットワーク８に接続されている全てのプリンタ（本実施形態ではプリンタ２〜６）のモデル名（ｈｒＤｅｖｉｃｅＤｅｓｃｒ）、アイドル率（ｃｕｒｒｅｎｔ　ＣＰＵ　Ｓｔａｔｕｓ）及び保持するイメージファイル（ｅｍｂｅｄｄｅｄ　Ｉｍａｇｅ　Ｓｕｐｐｏｒｔｅｄ）を問い合わせる。このＳ２２０の処理は、ＳＮＭＰマネージャ２２の機能として行われるものであり、この結果、図３で説明したように、各プリンタ２〜６からそれぞれＧＥＴレスポンスが返信される。
【００９５】
そして、Ｓ２３０にて時刻ｔをｃ＿ｔｉｍｅ（）（現在時刻）にセットして、Ｓ２４０に進む。Ｓ２４０では、受信パケット（即ち、各プリンタ２〜６からのＧＥＴレスポンス）の有無が判断され、ない場合はＳ２８０に移行するが、パケットを受信した場合は、Ｓ２５０に移行して受信したパケットを１件ずつ（各プリンタ２〜６のＧＥＴレスポンス毎に）みていく。
【００９６】
続くＳ２６０では、受信したパケット（ＧＥＴレスポンス）に含まれる、当該パケットを送信したプリンタのアイドル率が、５０％以上であるか否かが判断され、５０％より少ない場合（処理負荷量が多いとき）はＳ２８０に進むが、５０％以上で比較的処理負荷量が少ない場合は、Ｓ２７０に進む。
【００９７】
Ｓ２７０では、受信したパケットに含まれる、当該パケットを送信したプリンタが保持するイメージファイルの固有ＩＤに基づいて、ＩＰアドレスリストを作成する。即ち、イメージファイル参照管理テーブル２６において、その固有ＩＤに対応した行にそのプリンタのＩＰアドレスを書き込み（登録）するのである。
【００９８】
Ｓ２８０では、時刻ｔからの経過時間が所定期間Ｔ１を越えたか否かが判断され、期間Ｔ１がまだ経過していないときは再びＳ２４０に戻って、他の受信パケットについて上記同様の処理を行うことになるが、期間Ｔ１が経過したときは、Ｓ２９０に移行してデバイス参照回数管理表２７を作成する。尚、この所定期間Ｔ１は、ブロードキャスト後に全てのプリンタ２〜６からのパケットを受信して、それに基づいてＩＰアドレスリスト作成処理を行うのに十分な期間（例えば５秒）が設定される。
【００９９】
そのため、Ｓ２９０に移行したとき、通常は全てのプリンタ２〜６からの受信パケットについて処理済みとなっており、デバイス参照回数管理表２７の「ＩＰアドレス」の列には、図４（ｂ）に示すように各プリンタ２〜６のＩＰアドレスが列挙されることになる。尚このとき、イメージファイル参照管理テーブルについても、図４（ａ）に示すように、各プリンタ２〜６のＩＰアドレスがそれぞれ対応するイメージファイルの行に登録された状態となっている。
【０１００】
Ｓ２９０の処理後は、Ｓ１４０（図６）に移行して、一定時間（本実施形態では１０秒）スリープする。そして、一定時間スリープ後は再びＳ１１０に戻り、以下同様の処理を繰り返すことになる。
【０１０１】
上記のように、本実施形態のポーリングタスクでは、所定タイミング（例えば、１０秒毎）で必ずＳＮＭＰのＧＥＴリクエストをブロードキャストするわけではなく、プリンタ１自身の処理負荷量が多大の場合、及び、プリンタ１自身の処理負荷量が少ないか若しくはネットワーク８の負荷が少ないかのいずれかの場合にのみ、上記ブロードキャストを実行してイメージファイル参照管理テーブル２６のデータ更新（ＩＰアドレスリスト作成）を行うようにしている。これにより、ＩＰアドレスリスト作成処理（換言すれば、同じイメージファイルを持つプリンタの調査）を頻繁に実行することがなく非常に効率的である。
【０１０２】
次に、上記ポーリングタスクと並んで実行される、クライアントＰＣ７のＷｅｂブラウザ３１からのＨＴＴＰによるＧＥＴリクエストに対する処理（ＨＴＴＰタスク）について、図８に基づいて説明する。図８は、プリンタ１のＣＰＵ１１にて実行されるＨＴＴＰタスクを示すフローチャートである。このＨＴＴＰタスクは、Ｗｅｂサーバ２１の機能として実行されるものである。
【０１０３】
この処理が開始されると、まずＳ３１０にて、ＨＴＴＰによる受信データの有無を判断する。受信データがない間は継続してこのＳ３１０の処理が実行されることになるが、受信データがあった場合は、Ｓ３２０に進んで、その受信データがＧＥＴリクエストであるか否かが判断される。
【０１０４】
このとき、受信データが例えば図２２のメインページを要求するＧＥＴリクエストであった場合は、Ｓ３３０に移行して、イメージファイル参照管理テーブル２６に基づいて図５に示したＨＴＭＬデータを作成する。尚このとき、各イメージファイル毎にそれぞれどのプリンタを参照先として指定するかについては、後述する負荷分散アルゴリズム（図９）を実行することにより決定される。
【０１０５】
Ｓ３３０により図５のＨＴＭＬデータが作成されると、続くＳ３４０にて、そのＨＴＭＬデータをクライアントＰＣ７へ送信し、再びＳ３１０に戻ることになる。一方、受信データがＧＥＴリクエストではなくＳ３２０で否定判定された場合は、Ｓ３５０に進み、その受信データに応じた処理を実行し、再びＳ３１０に戻る。ＧＥＴリクエスト以外の受信データとしては、例えばＰＯＳＴ要求などが挙げられる。
【０１０６】
次に、図８のＨＴＴＰタスクにおけるＳ３３０のＨＴＭＬデータ作成時に実行される、負荷分散アルゴリズムについて、図９に基づいて説明する。図９は負荷分散アルゴリズムを示すフローチャートである。この負荷分散アルゴリズムは、ＨＴＭＬデータを作成する過程で各イメージファイルの参照先を指定するために、各イメージファイル毎に実行されるものである。
【０１０７】
この処理が開始されると、まずＳ４１０にて、イメージファイル参照管理テーブル２６における当該イメージファイルの固有ＩＤに対応した行ｊを求める。続くＳ４２０にて、その行ｊにおける「ＩＰ１」〜「ＩＰｎ」に、「Ｌａｔｅｓｔ　ＩＰ」と一致するＩＰアドレスがあるか否かを判断する。例えば図４（ａ）のイメージファイル参照管理テーブル２６において、「Ｒｅｄ　Ｂｕｔｔｏｎ」（赤ボタン）の場合を例に挙げると、「Ｌａｔｅｓｔ　ＩＰ」には１０．１３４．４３．２２のＩＰアドレスが登録されており、一方、そのＩＰアドレスは、表中の「ＩＰ１」の欄にも登録されている。このような場合は、Ｓ４２０で肯定判定され、Ｓ４５０にて、参照先のＩＰアドレスを示すｏｕｔの値を、その行ｊの「Ｌａｔｅｓｔ　ＩＰ」、即ち１０．１３４．４３．２２にセットする。
【０１０８】
続くＳ４６０で、デバイス参照回数管理表２７における当該ｏｕｔに対応するＩＰアドレスの参照回数をインクリメントすることにより、この処理を終了する。一方、Ｓ４２０で否定判定されたときは、Ｓ４３０に進んで、その行ｊに１つでもＩＰアドレスが登録されているか否かを判断する。このとき、行ｊに全くＩＰアドレスが登録されていない場合は、Ｓ４４０に進んでｏｕｔを０．０．０．０に設定し、この処理を終了する。これは、当該イメージファイルを持つプリンタが他に存在しないため他のプリンタを参照してそのイメージファイルを取得することができないことを意味する。
【０１０９】
このように、ｏｕｔとして０．０．０．０がセットされた場合は、そのイメージファイルについては他のプリンタを参照しないようにＨＴＭＬデータが作成されることになる。
【０１１０】
行ｊに１つでもＩＰアドレスが登録されている場合は、Ｓ４３０で肯定判定されてＳ４７０に進み、その登録されているＩＰアドレスのうち、デバイス参照回数管理表２７で参照回数が最も少ないＩＰアドレスを、ｏｕｔとしてセットする。続くＳ４８０では、イメージファイル参照管理テーブル２６中の当該イメージファイルに対応した「Ｌａｔｅｓｔ　ＩＰ」の欄を、そのｏｕｔとしてセットしたＩＰアドレスに更新する。その後はＳ４６０に進んでそのｏｕｔにセットしたＩＰアドレスの参照回数をインクリメントして、この処理を終了する。
【０１１１】
これまでの説明では、プリンタ１を中心にして、プリンタ１内蔵のＷｅｂサーバ２１がＷｅｂブラウザ３１へＨＴＭＬデータを送信する場合を例に挙げて説明してきたが、先に述べた通り、他の各プリンタ２〜６についても、プリンタ１と同様に、Ｗｅｂサーバ，ＳＮＭＰマネージャ及びＳＮＭＰエージェントが組み込まれたものである。そのため、クライアントＰＣ７から各プリンタ２〜６にＨＴＴＰによるＧＥＴリクエストを行った場合も、上記同様の各種処理が行われることになる。
【０１１２】
以上説明したように、本実施形態のネットワークシステムでは、Ｗｅｂブラウザ３１からのメインページのＧＥＴリクエストにより、Ｗｅｂサーバ２１がＨＴＭＬデータを作成する際、メインページに表示されるイメージファイルの参照先を、当該Ｗｅｂサーバ２１（プリンタ１）以外の他のプリンタ２〜６に分散して参照させるようなＨＴＭＬデータを作成する。そして、このように作成されたＨＴＭＬデータをＷｅｂブラウザ３１側で解釈すると、各イメージファイルを指定された参照先から取得するためのＧＥＴリクエストを出すことになる。
【０１１３】
そのため、本実施形態によれば、クライアントＰＣ７側でのＷｅｂページの表示に伴うプリンタ１のＣＰＵ１１の処理負荷量が軽減され、メインページをクライアントＰＣ７にて高速表示させることも可能となる。しかも、イメージファイルを持っているプリンタを無条件に指定するのではなく、アイドル率が低くて処理負荷量が多いプリンタは参照先の対象外とし、さらに、同じイメージファイルを持つプリンタが複数ある場合に、参照回数の最も少ないプリンタを優先的に参照先として指定するようにしている。そのため、プリンタ１以外の他のプリンタにて実行中の処理に悪影響を及ぼすおそれは極めて少ない。また、参照先を指定する際に、最新（直前）のＨＴＭＬデータ作成時に実際に参照先として使用したＩＰアドレス（Ｌａｔｅｓｔ　ＩＰ）を優先するので、クライアントＰＣ７側でも、過去に取得してメモリにキャッシュしているイメージデータを有効に使用できる。
【０１１４】
尚、本実施形態において、Ｗｅｂサーバ２１は本発明の負荷分散サーバに相当し、ＲＡＭ１３は本発明の記憶媒体に相当する。また、各プリンタ１〜６内のＷｅｂサーバはいずれも、本発明の負荷分散サーバ及び同データ保持サーバのいずれにも相当するものである。
【０１１５】
また、図７のＩＰアドレスリスト作成処理において、Ｓ２２０の処理は本発明の調査手段が実行する処理に相当し、Ｓ２７０の処理は本発明の記憶手段が実行する処理に相当する。更に、図９の負荷分散アルゴリズムにおいて、Ｓ４２０，Ｓ４３０，Ｓ４５０及びＳ４７０の処理はいずれも、本発明の送信元分担手段が実行する処理に相当し、このうち特に、Ｓ４２０及びＳ４３０の処理はいずれも本発明の判断手段が実行する処理に相当する。また、Ｓ４８０の処理は本発明の記憶手段が実行する処理に相当する。更にまた、図８のＨＴＴＰタスクにおいて、Ｓ３４０の処理は本発明の取得指令送信手段が実行する処理に相当する。
【０１１６】
［第２実施形態］
図１０は、本実施形態のネットワークシステムにおけるデータの流れの一例を示す説明図である。本実施形態のネットワークシステムは、第１実施形態のネットワークシステムと比較して、システム構成そのものは図１と全く同様である。また、各プリンタ１〜６（以下代表としてプリンタ１）がそれぞれ、図６のポーリングタスクと図７のＩＰアドレスリスト作成処理を実行して、ＳＮＭＰのＧＥＴリクエストをブロードキャストすることにより他のプリンタの情報（図３参照）を得て、その情報を基にＷｅｂサーバがイメージファイルの参照先を指定することも、上記の第１実施形態と全く同様である。そのため、本実施形態においても、図１，図３〜４及び図６〜７を適宜参照しつつ説明する。
【０１１７】
図１０に示す如く、本実施形態のネットワークシステムでは、クライアントＰＣ７のＷｅｂブラウザ３１からプリンタ１内蔵のＷｅｂサーバ２１へメインページ（図２２）のＧＥＴリクエストがあると（▲１▼）、Ｗｅｂサーバ２１は、そのリクエストに応じたＨＴＭＬデータを作成して、クライアントＰＣ７へ送信する（▲２▼）。
【０１１８】
このとき、図５のような、ＩＭＧ要素のタグにてイメージファイルの参照先を指定するのではなく、イメージファイルを持ったプリンタのＩＰアドレスをパラメータとして与えたＪａｖａアプレット（「Ｊａｖａ」は登録商標）のＵＲＬが、ＨＴＭＬデータに含まれる。尚、Ｊａｖａアプレットは、ネットワークを通じてＷｅｂブラウザにダウンロードされ、ブラウザのウィンドウに埋め込まれて実行される周知のＪａｖａプログラムである。また、このＪａｖａアプレットのＵＲＬを含むＨＴＭＬデータは本発明の送信予告に相当するものである。
【０１１９】
このＨＴＭＬデータを受けたクライアントＰＣ７のＷｅｂブラウザ３１（本発明の受信手段）は、ＪａｖａアプレットのＵＲＬをみて、自動的にＪａｖａアプレットのＧＥＴリクエストをプリンタ１へ送信する（▲３▼）。これにより、プリンタ１からはＪａｖａアプレット５１が返信される（▲４▼）。このＪａｖａアプレット５１を受信したクライアントＰＣ７では、Ｊａｖａアプレット５１がポート５２（本発明の取得手段）を開いて、パラメータとして与えられたＩＰアドレスのプリンタからイメージファイルが送信されてくるのを待つ（▲５▼）。
【０１２０】
一方、プリンタ１は、イメージファイルを持った他のプリンタに対して、クライアントＰＣ７のＩＰアドレスを含むＭＩＢ（本発明の送信指令）をＳＮＭＰにより送信する（▲５▼’）。このＭＩＢ送信は、より詳細には、イメージファイルをクライアントＰＣ７へ送信するよう指示するためのＳＮＭＰのＳＥＴリクエストである。そして、このＳＥＴリクエストを受けたプリンタは、ＭＩＢをみることによって、指定された宛先（クライアントＰＣ７）へイメージファイルを送信する（▲６▼）。クライアントＰＣ７は、この送信されたイメージファイルを受信して、そのイメージファイルを表示させる（▲７▼）。
【０１２１】
次に、プリンタ１にて、既述のポーリングタスク（図６参照）と並んで実行される、クライアントＰＣ７のＷｅｂブラウザ３１からのＨＴＴＰによるＧＥＴリクエストに対する処理（ＨＴＴＰタスク）について、図１１に基づいて説明する。図１１のＨＴＴＰタスクにおいて、Ｓ５１０〜Ｓ５５０の処理は、第１実施形態のＨＴＴＰタスク（図８参照）におけるＳ３１０〜Ｓ３５０の処理と同様であるため、ここではその詳細説明を省略する。但し、Ｓ５３０のＨＴＭＬデータ作成処理で作成されるＨＴＭＬデータは、図５のＨＴＭＬデータとは異なり、上述の如く、Ｊａｖａアプレットを含むＨＴＭＬデータである。
【０１２２】
クライアントＰＣ７からの受信データがＨＴＴＰによるＧＥＴリクエストであったとき、イメージファイル参照管理テーブル２６に基づいてＨＴＭＬデータを作成し、その作成したＨＴＭＬデータをクライアントＰＣ７へ返信する（Ｓ５１０〜Ｓ５５０）。そして、Ｓ５６０にて、ＳＮＭＰマネージャ２２によるＳＮＭＰマネージャタスクを起動して、イメージファイルを持ったデバイス（プリンタ）のＩＰアドレスと、そのＩＰアドレスのプリンタからクライアントＰＣ７へ送信して欲しいＭＩＢのＯＩＤと、そのイメージファイルを要求しているクライアントＰＣ７のＩＰアドレスとを渡す。その後は再びＳ５１０に戻ることになる。
【０１２３】
そして、Ｓ５６０にて起動されるＳＮＭＰマネージャタスクは、詳細には図１２に示す通りであり、まずＳ６１０にて、Ｓ５６０で渡された上記３種類の情報を取得する。続くＳ６２０では、その取得した情報に基づいて、ＭＩＢデータを作成する。このＭＩＢには、既述の通り、クライアントＰＣ７のＩＰアドレスが含まれる。そして、Ｓ６３０にて、イメージファイルを持ったプリンタに対して、作成したＭＩＢのＳＮＭＰによるＳＥＴリクエストを行う。
【０１２４】
一方、このＳＥＴリクエストを受けたプリンタは、そのＳＥＴリクエストに従って処理を実行するわけだが、これはＳＮＭＰエージェント２３の機能として実行されるものである。以下、ＳＮＭＰエージェント２３の機能として実行されるＳＮＭＰエージェントタスクについて、図１３に基づいて説明する。
【０１２５】
このＳＮＭＰエージェントタスクが開始されると、まずＳ７１０にて、受信データの有無が判断され、データを受信しない間はこの判断が繰り返されることになるが、データを受信した場合、Ｓ７２０に進み、受信したデータがＳＮＭＰのＳＥＴリクエストであるか否かが判断される。ここで、ＳＥＴリクエストでない場合は、Ｓ７６０に移行してその受信データに応じた処理がなされるが、ＳＥＴリクエストの場合は、Ｓ７３０に移行する。
【０１２６】
Ｓ７３０では、受信したデータ（ＳＮＭＰのＳＥＴリクエスト；ＭＩＢ）に対して更に、そのＭＩＢが、イメージファイルをクライアントＰＣ７へ送信すべき旨の要求（イメージファイルの代理要求）であるか否かが判断される。ここで、イメージファイルの代理要求でなければ、Ｓ７７０に移行してそのＭＩＢに対応した処理を実行することになるが、イメージファイルの代理要求であったならば、Ｓ７４０に移行する。
【０１２７】
Ｓ７４０では、代理として送信すべきイメージファイルを含むＭＩＢデータを作成し、続くＳ７５０にて、そのＭＩＢデータをクライアントＰＣ７へ送信する。その後は、再びＳ７１０に戻ることになる。
【０１２８】
以上説明したように、本実施形態のネットワークシステムでは、Ｗｅｂブラウザ３１からのメインページ要求に対して、プリンタ１は、ＨＴＭＬデータをクライアントＰＣ７に送信するのに加えて、クライアントＰＣ７に送信すべきイメージファイルを持つ他のプリンタへＳＮＭＰのＳＥＴリクエストを送信する必要があるため、第１実施形態に比べると、プリンタ１のＣＰＵ１１の処理負荷は若干多くなる。しかしそれでも、従来のようにプリンタ１が全てのイメージファイルを直接送信する場合に比べれば、十分に処理負荷が軽減される。
【０１２９】
しかも、クライアントＰＣ７にとっては、プリンタ１からのＨＴＭＬデータを受信後、イメージファイルのＧＥＴ要求を逐一行う必要はなく、ポート５２をオープンして他のプリンタからのイメージファイル送信を待つのみでいい。そのため、クライアントＰＣ７の処理負荷も軽減される。
【０１３０】
尚、本実施形態において、図１１のＨＴＴＰタスクにおけるＳ５５０の処理及び図１２のＳＮＭＰマネージャタスクにおけるＳ６３０の処理はいずれも、本発明の分担情報送信手段が実行する処理に相当する。また図１３のＳＮＭＰエージェントタスクにおけるＳ７５０の処理は、本発明のデータ送信手段が実行する処理に相当する。
【０１３１】
［第３実施形態］
図１４は、本実施形態のネットワークシステムにおけるデータの流れの一例を示す説明図である。本実施形態のネットワークシステムでは、第２実施形態のネットワークシステムと比較して、クライアントＰＣ６０が、ＷｅｂブラウザではなくＳＮＭＰを使ったアプリケーションにより各プリンタ１〜６を簡易に管理できるよう構成されている。
【０１３２】
そのため、第１・第２実施形態のクライアントＰＣ７が備えていたＷｅｂブラウザ３１の代わりに、本実施形態のクライアントＰＣ６０は、ＳＮＭＰアプリケーション６１を備えている。そして、このＳＮＭＰアプリケーション６１が、プリンタ１に対してＳＮＭＰによるメインページのＧＥＴリクエストを行い（▲１▼）、これを受けたプリンタ１のＳＮＭＰエージェント２３が、要求されたメインページ中のイメージファイルを持った他のプリンタのＩＰアドレスを含むＭＩＢデータを、クライアントＰＣ６０へ送信するのである（▲２▼）。
【０１３３】
尚、各プリンタ１〜６はいずれも第２実施形態の各プリンタ１〜６と同じである。そして、各プリンタ１〜６（以下代表としてプリンタ１）がそれぞれ、図６のポーリングタスクと図７のＩＰアドレスリスト作成処理を実行して、ＳＮＭＰのＧＥＴリクエストをブロードキャストすることにより他のプリンタの情報（図３参照）を得ることも、上記第１及び第２実施形態と全く同様である。
【０１３４】
プリンタ１からのＭＩＢデータを受信したクライアントＰＣ６０では、ＳＮＭＰアプリケーション６１が、ＭＩＢデータ中に他のプリンタのＩＰアドレスが入っているか否かをみて、入っていたならば、ポート６２を開いてそのプリンタからイメージファイルが送信されてくるのを待つ（▲３▼）。
【０１３５】
一方、プリンタ１は、イメージファイルを持った他のプリンタに対して、クライアントＰＣ６０のＩＰアドレスを含むＭＩＢ（本発明の送信指令）をＳＮＭＰにより送信する（▲３▼’）。このＭＩＢ送信は、より詳細には、イメージファイルをクライアントＰＣ６０へ送信するよう指示するためのＳＮＭＰのＳＥＴリクエストである。そして、このＳＥＴリクエストを受けたプリンタは、ＭＩＢをみることによって、指定された宛先（クライアントＰＣ６０）へイメージファイルを送信する（▲４▼）。クライアントＰＣ６０は、この送信されたイメージファイルをポート６２にて受信し、そのイメージファイルを表示させる（▲５▼）。
【０１３６】
次に、プリンタ１にて、既述のポーリングタスク（図６参照）と並んで実行される、クライアントＰＣ６０のＳＮＭＰアプリケーション６１からのＳＮＭＰによるＧＥＴリクエストに対する処理（ＳＮＭＰタスク）について、図１５に基づいて説明する。
【０１３７】
このＳＮＭＰタスクが開始されると、まずＳ８１０にて、受信データの有無が判断され、データを受信しない間はこのＳ８１０の判断処理が繰り返されることになるが、データを受信した場合は、Ｓ８２０に進み、そのデータがＳＮＭＰによるＧＥＴリクエストであるか否かが判断される。
【０１３８】
ここで、ＧＥＴリクエストでない場合は、Ｓ８６０に移行し、その受信したデータに応じた処理を実行して再びＳ８１０に戻るが、ＧＥＴリクエストであった場合はＳ８３０に進む。Ｓ８３０では、イメージファイル参照管理テーブル２６に基づいて、ＭＩＢデータの作成が行われる。即ち、プリンタ１のＳＮＭＰエージェント２３が、要求されたクライアントＰＣ６０から要求されているイメージファイルを持った他のプリンタのＩＰアドレスを含むＭＩＢデータを作成するのである。
【０１３９】
ＭＩＢデータ作成後は、Ｓ８４０にてそのＭＩＢデータをクライアントＰＣ６０へ送信する。更に、Ｓ８５０にて、第２実施形態で説明した図１１のＨＴＴＰタスクにおけるＳ５６０の処理と全く同様に、ＳＮＭＰマネージャ２２によるＳＮＭＰマネージャタスクを起動して、イメージファイルを持ったデバイス（プリンタ）のＩＰアドレスと、そのＩＰアドレスのプリンタからクライアントＰＣ６０へ送信して欲しいＭＩＢのＯＩＤと、そのイメージファイルを要求しているクライアントＰＣ６０のＩＰアドレスとを渡す。その後は再びＳ８１０に戻ることになる。
【０１４０】
尚、Ｓ８５０で起動されるＳＮＭＰマネージャタスクは、第２実施形態で説明した図１２のＳＮＭＰマネージャタスクと全く同様の処理である。そして、このＳＮＭＰマネージャタスクにより作成・出力されるＭＩＢデータを他のプリンタが受信したときに、そのＭＩＢデータを受信したプリンタが実行するＳＮＭＰエージェント処理も、第２実施形態で説明した図１３のＳＮＭＰエージェントタスクと全く同様である。
【０１４１】
以上説明した本実施形態のネットワークシステムによっても、第２実施形態のネットワークシステムと同様、プリンタの処理負荷を十分に軽減でき、しかもクライアントＰＣ６０の処理負荷も軽減される。尚、本実施形態において、図１５のＳＮＭＰタスクにおけるＳ８４０の処理は、本発明の分担情報送信手段が実行する処理に相当する。
【０１４２】
尚、本発明の実施の形態は、上記実施形態に何ら限定されるものではなく、本発明の技術的範囲に属する限り種々の形態を採り得ることはいうまでもない。
【０１４３】
例えば、上記第１実施形態では、イメージファイル参照管理テーブル２６においてＩＰアドレスリストを作成する処理を、図６で説明したポーリングタスクにより所定のタイミングで行うようにしたが、例えば、Ｗｅｂブラウザ３１からメインページのＧＥＴリクエストがあったときに実行するようにしてもよい。
【０１４４】
この場合、具体的には、ＩＰアドレスリスト作成処理（Ｓ１３０）を実行するために設けられていた図６に示すポーリングタスクを削除するとともに、図１６に示すように、図６のポーリングタスクにて実行していたＳ１３０のＩＰアドレスリスト作成処理を、図８のＨＴＴＰタスクにおけるＳ３２０とＳ３３０との間（Ｓ３２０による肯定判定後）で実行すればよい。
【０１４５】
尚、第２及び第３実施形態においても同様であり、ポーリングタスクにおけるＩＰアドレスリスト作成処理（図示略。図６のＳ１３０と同様）を、第２実施形態の場合には、図１１のＨＴＴＰタスクにおけるＳ５２０とＳ５３０との間（Ｓ５２０による肯定判定後）で実行するようにできるし、第３実施形態の場合には、図１５のＳＮＭＰタスクにおけるＳ８２０とＳ８３０との間（Ｓ８２０による肯定判定後）で実行するようにできる。
【０１４６】
この構成によれば、いずれの場合も、クライアントＰＣからデータ要求があった時点でのまさに最新のネットワークシステムにおける参照先を探すことになるため、例えば、電源が投入されていない参照先のプリンタからイメージファイルを取得しようとすることが無くなり、クライアントＰＣはより確実に、指定された参照先のプリンタからイメージファイルを取得することができる。
【０１４７】
また、Ｗｅｂブラウザ３１からのＧＥＴリクエストがあったときにＩＰアドレスリスト作成処理（Ｓ１３０）を無条件に実行する例を示した図１６について、さらに、そのＧＥＴリクエストを行ったＷｅｂブラウザ３１が、再度、所定期間内に同一のページについてのＧｅｔリクエストを行った場合にのみ、ＩＰアドレスリスト作成処理（Ｓ１３０）を実行するようにしてもよい。
【０１４８】
この場合、具体的には、図１７に示すように、図１６のＨＴＴＰタスクにおけるＳ３２０とＳ１３０との間（Ｓ３２０による肯定判定後）に、Ｓ９１０の判断処理を追加するとともに、Ｓ１３０とＳ３３０との間に、Ｓ９２０の処理を追加すればよい。そして、Ｓ９１０では、Ｓ３２０にて肯定判定されたＧＥＴリクエストのパケットを解析して、ＧＥＴリクエストを送出したクライアントＰＣのＩＰアドレスと、ＧＥＴリクエストの対象となっているページのＵＲＬと、を特定するとともに、当該ＧＥＴリクエストが、過去のＧＥＴリクエストと同一のページを要求するものであり、かつ、その同一のページを要求した過去のＧＥＴリクエストを受信してから所定期間内（例えば、３０秒以内）に同一のクライアントＰＣ（すなわち、同一のＷｅｂブラウザ３１）から受信したものであるのか否かを判断する。尚、この判断を行う際に必要となる過去のＧＥＴリクエストに関する要求ページのＵＲＬ，要求受信時刻，クライアントＰＣのＩＰアドレスについては、後述するＳ９２０にて記憶されたものを用いる。
【０１４９】
そして、Ｓ９１０にて、今回のＧＥＴリクエストが、過去のＧＥＴリクエストと同一のページを要求するものであり、かつ、その同一のページを要求した過去のＧＥＴリクエストを受信してから所定期間内に同一のクライアントＰＣから受信したものであると判断された場合は、前述のＩＰアドレスリスト作成処理（Ｓ１３０）を行った後にＳ９２０へ進む。一方、Ｓ９１０にて、今回のＧＥＴリクエストが、過去のＧＥＴリクエストと同一のページを要求するものであり、かつ、その同一のページを要求した過去のＧＥＴリクエストを受信してから所定期間内に同一のクライアントＰＣから受信したものではない（３つの条件を全て満たしていない）と判断された場合は、そのままＳ９２０へ進む。Ｓ９２０では、Ｓ９１０の判断で用いた今回のＧＥＴリクエストに関する要求ページのＵＲＬ，要求受信時刻，クライアントＰＣのＩＰアドレスをＲＡＭ１３などに記憶させる処理を行って、Ｓ３３０の処理に進む。
【０１５０】
この構成によれば、同一のクライアントＰＣから同一のページを所定期間内に再度要求されたときのみ、最新のネットワークシステムにおける参照先を探すことになる。すなわち、同一のクライアントＰＣから同一のページを所定期間内に再度要求されたという状況は、Ｗｅｂブラウザ３１が、前回のＧＥＴリクエストによって得たＨＴＭＬデータに従って参照先のプリンタからイメージファイルを取得しようとしたが、そのプリンタの電源が投入されていない等の原因でイメージファイルの取得に失敗し、結果としてページを正常に表示できず、それに疑問をもったユーザが再度ページを要求したという状況が想定される。そこで、このような必要性の高いときのみ、最新のネットワークシステムにおける参照先を探すことで、より効率的なシステムを構築することが可能となる。
【０１５１】
また、上記各実施形態では、クライアントＰＣ以外にネットワーク８に接続されるデバイスがプリンタだけの場合を例に挙げて説明したが、プリンタに何ら限定されないことはいうまでもなく、例えばルータやその他各種周辺機器など、ネットワーク８に接続されるあらゆるデバイスに対しても、本発明を適用可能である。また、印刷装置としても、プリンタに限らず、コピー装置や多機能周辺装置など印刷機能を備えたものであれば、本発明を適用可能である。
【０１５２】
更に、上記各実施形態では、プリンタ管理設定画面のメインページ（図２２）にて使用されるイメージファイルの参照先（送信元）を、ＨＴＴＰ或いはＳＮＭＰによって他の複数のプリンタに分散させる例について説明したが、イメージファイルに限らず（延いてはＷｅｂやＳＮＭＰに限らず）、他のあらゆるデータ（或いはプロトコル）の場合であっても、同様に分散させることができる。
【０１５３】
更にまた、上記各実施形態では、図３に示した▲１▼〜▲３▼の情報をブロードキャストにより取得する例について説明したが、これに限らず例えば、プリンタのモデル名だけを問い合わせて、ネットワーク８に接続されたプリンタのうち少なくとも自身と同じモデルがあるか否かを調べるようにしてもよい。
【０１５４】
つまり、同じモデル名であれば、自身が持っているイメージデータ全てを持っているはずであるから、その同じモデル名のプリンタを登録しておく。そして、Ｗｅｂブラウザ（第３実施形態ではＳＮＭＰアプリケーション）からメインページのデータ要求があったとき、イメージファイルの参照先として、登録中の同じモデル名のプリンタを指定すればよい。
【０１５５】
このように、単に自身と同じモデル名のプリンタが有るか否かのみをブロードキャストにより調べるようにすれば、プリンタ１におけるそのブロードキャストに伴う処理負荷が軽減される。
【０１５６】
また、図６のポーリングタスクでは、プリンタ１自身の処理負荷量が多大の場合（Ｓ１１０：ＹＥＳ）、及び、プリンタ１自身の処理負荷量が少ないか若しくはネットワーク８の負荷が少ないかのいずれかの場合（Ｓ１２０：ＹＥＳ）にのみ、Ｓ１３０のＩＰアドレスリスト作成処理を実行するようにしたが、これに限らず、例えばＳ１１０の判断処理及びＳ１２０の判断処理の少なくともいずれか一方を削除するようにしてもいいし、更には、両判断処理（Ｓ１１０，Ｓ１２０）に代えて、図１８に示すような判断処理（Ｓ１０１０，Ｓ１０３０）を行っても良い。
【０１５７】
すなわち、図６のポーリングタスクでは、プリンタ１自身の処理負荷量が多大の場合（Ｓ１１０：ＹＥＳ）、及び、プリンタ１自身の処理負荷量が少ないか若しくはネットワーク８の負荷が少ないかのいずれかの場合（Ｓ１２０：ＹＥＳ）にのみ、Ｓ１３０のＩＰアドレスリスト作成処理を実行するようにしたが、図１８に示すポーリングタスクでは、プリンタ１自身がネットワークに新たに参加した場合（ネットワークに接続された他の機器とは通信できない状態からネットワークに接続された他の機器と通信ができる状態になった場合）、及び、他のプリンタ２〜６からネットワークに参加した旨の通知を受けた場合のみ、Ｓ１３０のＩＰアドレスリスト作成処理を実行するのである。
【０１５８】
つまり、図１８に示すように、Ｓ１０１０にて、プリンタ１自身がネットワーク８に新たに参加したか否か、すなわち、ネットワークに接続された機器との通信ができない状態から、ネットワークに接続された機器との通信が可能な状態になったか否かを判断する。この判断は、例えば、ネットワークを流れるパケットを収集できない状態から、収集できる状態になったか否かを判断することで行う。この判断によって、ネットワーク８に新たに参加したと判断された場合は、Ｓ１０２０に進み、ネットワーク８に接続されたプリンタ２〜６にプリンタ１がネットワーク８に参加した旨の通知を行った後、前述のＩＰアドレスリスト作成処理（Ｓ１３０）を行う。また、Ｓ１０１０の判断によって、ネットワーク８に新たに参加したと判断されない（過去にＳ１０１０で新たにネットワーク８に参加したと判断されてから、継続的にネットワーク８に参加している）場合は、Ｓ１０３０へ進み、プリンタ２〜６から上述のＳ１０２０に基づく通知を受けたか否かを判断する。すなわち、ネットワーク８に新たに参加したプリンタが存在するか否かを判断する。そして、Ｓ１０３０にて、ネットワーク８に新たに参加したプリンタが存在すると判断された場合は、Ｓ１３０に進み、前述のＩＰアドレスリスト作成処理を行う一方、ネットワーク８に新たに参加したプリンタが存在しないと判断された場合は、Ｓ１０１０に戻る。
【０１５９】
この構成によれば、プリンタ１自身がネットワークに新たに参加した場合、及び、プリンタ１以外の他のプリンタがネットワークに新たに参加した場合に、最新のネットワークシステムにおける参照先を探すことになる。そのため、プリンタ１を他のネットワークに新たに参加させた際には、その新たに参加したネットワークに対応した参照先を即座に決定することができ、非常に好適である。また、他のプリンタが新たにネットワークに参加した際には、ネットワークの環境の変化に対応した参照先を即座に決定することができ、非常に好適である。尚、このＳ１０１０の判断処理（及び、Ｓ１０２０の処理）及びＳ１０３０の判断処理の少なくともいずれか一方を削除してもよいことはいうまでもない。
【０１６０】
さらに、上述した本発明の実施の形態では、図６に示すポーリングタスクのみに基づいてＩＰアドレスリスト作成処理（Ｓ１３０）を実行する例を挙げて説明したが、図６（あるいは、図１８）に示したポーリングタスクとは別の図１９に示すような第２ポーリングタスクを並んで実行して、図６（あるいは、図１８）に示したポーリングタスクと、図１９に示した第２ポーリングタスクと、の２つのポーリングタスクに基づいてＩＰアドレスリスト作成処理（Ｓ１３０）を実行しても良い。
【０１６１】
この第２ポーリングタスクに基づいてＩＰアドレスリスト作成処理（Ｓ１３０）を実行する場合は、図１９に示すように、まず、Ｓ１１１０にてイメージファイル参照管理テーブル２６のＬａｔｅｓｔ　ＩＰの欄にあるＩＰアドレスの全てに対して、個々にＰＩＮＧ（Ｐａｃｋｅｔ　ＩｎｔｅｒＮｅｔ　Ｇｒｏｐｅｒ）を実行する。尚、ＰＩＮＧはＴＣＰ／ＩＰ上において、相手ノードの状態を知ることを目的としたコマンドの名称であって、ＩＣＭＰ（Ｉｎｔｅｒｎｅｔ　Ｃｏｎｔｒｏｌ　Ｍｅｓｓａｇｅ　Ｐｒｏｔｏｃｏｌ）を用いてエコー要求を相手ノードに送信し、そのエコー要求に対する応答があるか否かに基づいて相手ノードとの通信が正常に行えるか否かを判断するためのものである。
【０１６２】
そして、Ｓ１１１０にてＰＩＮＧを実行した後は、Ｓ１１２０にて、Ｓ１１１０にて実行した全てのＰＩＮＧに対して応答が確認できたか否かを判断する。その結果、全てのＰＩＮＧに対して応答が確認できた場合は、Ｓ１４０（図６に示すＳ１４０と同等の処理であるため、同一の番号を付して説明）に進み、全てのＰＩＮＧに対して応答が確認できなかった場合は、Ｓ１３０（図６に示すＳ１３０と同一の処理であるため、同一の番号を付して説明）に進む。Ｓ１３０では、上述のＩＰアドレスリスト作成処理を行った後、Ｓ１４０に進み、Ｓ１４０では、一定時間（ここでは、例えば、１０分）スリープした後、Ｓ１１１０に戻る。
【０１６３】
この構成によれば、図９に示す負荷分散アルゴリズムにおいて、イメージデータの参照先として設定されやすいＬａｔｅｓｔ　ＩＰに対してＰＩＮＧを実行する。そして、そのＬａｔｅｓｔ　ＩＰの欄に示されるＩＰアドレスを有するプリンタと正常に通信ができなかった場合に（Ｓ１１２０：ＮＯ）、ＩＰアドレスリスト作成処理（Ｓ１３０）を実行して、最新のイメージファイル参照管理テーブル２６を作成するので（Ｓ２７０）、負荷分散アルゴリズム（図９）を実行する際に、通信不能のプリンタをイメージファイルの参照先として決定してしまうおそれを減らすことができる（Ｓ４２０：ＮＯ）。尚、Ｓ１１１０では、Ｌａｔｅｓｔ　ＩＰの各々に対してＰＩＮＧを行う例を挙げて説明したが、イメージファイル参照管理テーブル２６にあるＩＰアドレス全てに行っても良い。但し、ＰＩＮＧを行う対象が増えると処理負荷が大きくなるので、Ｌａｔｅｓｔ　ＩＰの欄にあるＩＰアドレスを対象としてＰＩＮＧを行う方が好ましい。
【０１６４】
さらに、上述した本発明の実施の形態では、図７に示すＩＰアドレスリスト作成処理において、比較的処理負荷量が少ないプリンタのＩＰアドレスを無条件でイメージファイル参照管理テーブル２６に登録する（Ｓ２６０：ＹＥＳ，Ｓ２７０）例を挙げて説明したが、図２０に示すように、比較的処理負荷量が少ないプリンタであり、かつ、ユーザが予め参照先プリンタとして利用することを許可しているプリンタのＩＰアドレスのみをイメージファイル参照管理テーブル２６に登録する構成としても良い。
【０１６５】
この場合、具体的には、図２０に示すように、図７のＩＰアドレスリスト作成処理におけるＳ２６０とＳ２７０との間（Ｓ２６０による肯定判定後）に、Ｓ１２１０の判断処理を実行すればよい。そして、Ｓ１２１０では、Ｓ２６０にて肯定判定されたプリンタのＩＰアドレスが、ユーザが予め参照先として登録することを許可しているＩＰアドレスであるか否かを判断して、登録が許可されているＩＰアドレスであれば、Ｓ２７０へ進み、登録が許可されていないＩＰアドレスであれば、Ｓ２８０に進むようにすれば良いのである。尚、ユーザが参照先として登録することを許可するＩＰアドレスは、例えば、図２１に示すようなユーザインターフェースを介して登録することが可能である。
【０１６６】
このユーザインターフェースは、ＰＣ７に設けられたＷｅｂブラウザ３１を利用して、プリンタ１のデータベース１４に格納されたＷｅｂページ２８を取得することによって、表示することが可能である。この図２１に示すユーザインターフェースでは、ＰＣ７に設けられたマウスを用いて、チェックボックス欄にカーソルを移動させ、クリック動作を行うことによって、「設定を有効にする」か否か、「定期検索を有効にする」か否か、「参照先サーバの許可対象を設定する」か否かの３項目について、選択することが可能である（図２１では、３項目全てを有効にした例を図示）。そして、「設定を有効にする」のチェックボックスに対して、有効にする旨の選択が行われた場合は、本発明の実施の形態に示した負荷分散システムが実行されることとなる。また、「定期検索を有効にする」のチェックボックスに対して、有効にする旨の選択が行われた場合は、図６，１８，１９に示したポーリングタスクに基づくＩＰアドレスリスト作成処理（Ｓ１３０）とは別に、ユーザによってその右欄に入力された時間が経過する度に、ＩＰアドレスリスト作成処理（Ｓ１３０）が実行されるようになる。さらに、「参照先サーバの許可対象を設定する」のチェックボックスに対して、有効にする旨の選択が行われた場合は、図２０に示したＳ１２１０の判断処理が有効となり、ユーザによってその下欄に入力されたＩＰアドレスが、上述したとおり、Ｓ１２１０の判断に利用されるのである。尚、ユーザのＩＰアドレスの入力については、「１５．１２３．１２．０２−１５．１２３．１２．２４０」のように始点と終点を示した範囲指定と、「１５．１２３．１２．２５４」のようにピンポイント指定とが可能であっても良い。
【０１６７】
また、上記各実施形態では、プリンタ１を本発明のサーバ（負荷分散サーバ）として機能させるための各種プログラムがＲＯＭ１２に格納されたものとして説明したが、これら各種プログラムを、例えばフロッピーディスク（登録商標）、光磁気ディスク、ＣＤ−ＲＯＭ、ハードディスク等の各種ストレージデバイス（コンピュータ読み取り可能な記録媒体）に記録しておくこともできる。
【０１６８】
この場合、記録媒体に記録したプログラムを必要に応じてコンピュータシステムにロードして起動することにより、そのコンピュータシステムにおいて本発明のサーバを実現することができる。
【０１６９】
また、プログラムを通信回線を介してコンピュータにインストールすることもできる。この通信回線により送信されるプログラムも、請求項２０記載のプログラムに該当するものである。
【図面の簡単な説明】
【図１】第１実施形態のネットワークシステムの概略構成を示すブロック図である。
【図２】第１本実施形態のネットワークシステムにおけるデータの流れの一例を示す説明図である。
【図３】プリンタがＳＮＭＰのＧＥＴリクエストをブロードキャストすることにより他のプリンタの情報を得ることを説明するための説明図である。
【図４】プリンタにて作成されるイメージファイル参照管理テーブル及びデバイス参照回数管理表である。
【図５】第１実施形態のＷｅｂサーバが生成するＨＴＭＬデータの一例を表す説明図である。
【図６】第１実施形態のプリンタにて実行されるポーリングタスクを示すフローチャートである。
【図７】図６のポーリングタスクにおける、Ｓ１３０のＩＰアドレスリスト作成処理の詳細を示すフローチャートである。
【図８】第１実施形態のプリンタにて実行されるＨＴＴＰタスクを示すフローチャートである。
【図９】図８のＨＴＴＰタスクにおけるＳ３３０のＨＴＭＬデータ作成時に、実行される、負荷分散アルゴリズムを示すフローチャートである。
【図１０】第２実施形態のネットワークシステムにおけるデータの流れの一例を示す説明図である。
【図１１】第２実施形態のプリンタにて実行されるＨＴＴＰタスクを示すフローチャートである。
【図１２】図１１のＨＴＴＰタスクにおけるＳ５６０の処理よって起動されるＳＮＭＰマネージャタスクを示すフローチャートである。
【図１３】第２実施形態のプリンタにて実行されるＳＮＭＰエージェントタスクを示すフローチャートである。
【図１４】第３実施形態のネットワークシステムにおけるデータの流れの一例を示す説明図である。
【図１５】第３実施形態のプリンタにて実行されるＳＮＭＰタスクを示すフローチャートである。
【図１６】他の実施形態のプリンタにて実行されるＨＴＴＰタスクを示すフローチャートである。
【図１７】他の実施形態のプリンタにて実行されるＨＴＴＰタスクを示すフローチャートである。
【図１８】他の実施形態のプリンタにて実行されるポーリングタスクを示すフローチャートである。
【図１９】他の実施形態のプリンタにて実行される第２ポーリングタスクを示すフローチャートである。
【図２０】他の実施形態のプリンタにて実行されるＩＰアドレスリスト作成処理を示すフローチャートである。
【図２１】ユーザインターフェースの例を示す図である。
【図２２】プリンタ管理設定画面の一例を表す説明図である。
【図２３】ＨＴＭＬデータの一例を表す説明図である。
【符号の説明】
１〜６…プリンタ、７，６０…クライアントＰＣ、８…ネットワーク、１１…ＣＰＵ、１２…ＲＯＭ、１３…ＲＡＭ、１４…データベース、１５…ユーザＩ／Ｆ、１６…出力Ｉ／Ｆ、１７…印刷出力部、１８…ネットワークＩ／Ｆ、２１…Ｗｅｂサーバ、２２…ＳＮＭＰマネージャ、２３…ＳＮＭＰエージェント、２６…イメージファイル参照管理テーブル、２７…デバイス参照回数管理表、２８…Ｗｅｂページ、２９…ＭＩＢ、３１…Ｗｅｂブラウザ、５１…Ｊａｖａアプレット、５２，６２…ポート、６１…ＳＮＭＰアプリケーション
【図１】
2004005394.tif 000003
【図２】
2004005394.tif 000004
【図３】
2004005394.tif 000005
【図４】
2004005394.tif 000006
【図５】
2004005394.tif 000007
【図６】
2004005394.tif 000008
【図７】
2004005394.tif 000009
【図８】
2004005394.tif 000010
【図９】
2004005394.tif 000011
【図１０】
2004005394.tif 000012
【図１１】
2004005394.tif 000013
【図１２】
2004005394.tif 000014
【図１３】
2004005394.tif 000015
【図１４】
2004005394.tif 000016
【図１５】
2004005394.tif 000017
【図１６】
2004005394.tif 000018
【図１７】
2004005394.tif 000019
【図１８】
2004005394.tif 000020
【図１９】
2004005394.tif 000021
【図２０】
2004005394.tif 000022
【図２１】
2004005394.tif 000023
【図２２】
2004005394.tif 000024
【図２３】
2004005394.tif 000025