JP4838564B2 - ネットワークデバイス、その制御方法およびプログラム - Google Patents

Description

本発明は、ネットワークシステムにおけるネットワークデバイスの探索技術に関する。

近年、ネットワーク設備が整備されるに従い、ネットワークデバイス（例えば、ネットワーク対応型のプリンタ、スキャナおよび複写機など）が急速に普及しつつある。

ところで、ＰＣ（パーソナルコンピュータ）などのクライアント装置からネットワークデバイスを使用するには、種々の設定が必要となる。例えば、ＰＣには、ネットワークデバイスのドライバをインストールする必要がある。また、ネットワークデバイスのＩＰアドレス、プリンタポート、使用するプリントプロトコルなどを把握して、ドライバに設定する必要もある。

最近になり、マイクロソフト社の提唱するＵｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ（ＵＰｎＰ）など、ネットワークに接続されているネットワークデバイスやサービスを探索する技術が開発されている。

ＵＰｎＰのバージョン１．０によれば、クラインアント装置は、あて先アドレスとしてマルチキャストアドレスを設定された探索パケットを送信する。ネットワークデバイスは、探索パケットを受信すると、自己のアドレス情報などを含む応答パケットをクラインアント装置に返信する。このようにして、クライアント装置は、ネットワークデバイスの設定情報を取得することができる。

ところで、ネットワークデバイスに関する設定情報を予め検索サーバに蓄積する技術も提案されている（特許文献１）。
特開２０００−３１２２２２号公報

上述したように、探索パケットをマルチキャストパケットとして送信することで、ネットワークデバイスの探索が容易になることはいうまでもない。しかしながら、クライアントやネットワークデバイスが増加すると、探索パケットや応答パケットによってネットワークが輻輳するおそれがある。加えて、クライアントやネットワークデバイスの処理負荷も増加してしまうだろう。

一方で、ネットワークデバイスに代わって応答パケットを送信する代理サーバを設ければ、ネットワークデバイスの処理負荷は軽減される。しかしながら、探索パケットに応答するネットワークデバイスと代理サーバが共存するネットワークシステムでは、マルチキャストによる探索パケットに対して、ネットワークデバイスと代理サーバの双方が応答パケットを送信してしまうおそれがある。これでは、ネットワークの輻輳を軽減できない。

そこで、本発明は、このような課題および他の課題の少なくとも１つを解決することを目的とする。なお、他の課題については明細書の全体を通して理解できよう。

本発明によれば、ネットワークを介して接続されたクライアント装置及び代理サーバと通信するネットワークデバイスであって、前記ネットワークデバイスの設定情報を要求するために前記クライアント装置からマルチキャストにより送信される探索要求に対する応答を抑制するための指示を、前記代理サーバから受信する受信手段と、前記クライアント装置から送信される探索要求に対して前記ネットワークデバイスの代わりに前記代理サーバが前記ネットワークデバイスの設定情報を応答できるように、前記ネットワークデバイスの設定情報を前記代理サーバに送信する送信手段と、前記受信手段によって前記指示を受信した場合、前記クライアント装置から送信される探索要求であって前記ネットワークデバイスは受信し前記代理サーバが受信しないユニキャストによって送信される探索要求に対して前記ネットワークデバイスの設定情報を応答し、前記クライアント装置から送信される探索要求であって前記ネットワークデバイスと前記代理サーバが共に受信するマルチキャストによって送信される探索要求に対する応答を抑制する制御手段とを含むネットワークデバイスが提供される。

本発明によれば、代理サーバが、ネットワークデバイスの設定情報を代理送信可能な場合、ネットワークデバイスが、応答の送信を抑制する。よって、マルチキャストによる検索要求に対して、代理サーバとネットワークデバイスとの双方が応答パケットを送付してしまうことによるトラヒックの増加を緩和することが可能になる。

以下に本発明の上位概念、中位概念および下位概念の理解に役立つ一実施形態を示す。もちろん、以下の具体的な実施形態は単なる例示に過ぎない。

［第１の実施形態］
図１は、本実施形態に係るネットワークデバイスの一例を示す図である。ネットワークシステム１００は、主に、ＬＡＮ１１０を介して接続される１以上のネットワークデバイス１０１、１以上のクライアント装置１０２、および１以上の代理サーバ１０３を含む。

ネットワークデバイス１０１は、ネットワークカード（ＮＩＣ）を有する周辺機器（プリンタ、複写機、コピー機、スキャナ、およびデジタルカメラなど）である。クライアント装置（以下、クライアントと称す。）１０２は、ＰＣ（パーソナルコンピュータ）などの情報処理装置である。代理（プロキシ）サーバ１０３は、ネットワークデバイス１０１から送信された応答パケットに含まれる設定情報をキャッシュし、キャッシュされた設定情報をクライアント１０２に送信する情報処理装置である。ここで、設定情報とは、クライアントがネットワークデバイスと通信する為に必要な情報である。例えば、ネットワークデバイスのＩＰアドレス、プリンタポート、ネットワークデバイスのドライバに係る情報等である。

本実施形態によれば、まず、ネットワークデバイス１０１は、設定情報を代理サーバ１０３に登録する。代理サーバ１０３は、記憶装置に設定情報を記憶し、当該設定情報の代理送信が可能な状態になる。以降、ネットワークデバイス１０１は、クライアントから送信される探索要求（リクエスト）またはマルチキャストによる探索要求への応答を抑制する（応答を完全に禁止してもよい）。なお、設定情報の代理送信が可能な状態には、ネットワークデバイス１０１が代理サーバ１０３から応答の抑制指示を受信した状態も含まれるものとする。なぜなら、抑制指示は、将来的に代理送信が可能となることを暗示しているからである。

図２は、実施形態に係るネットワークデバイスの例示的なブロック図である。以下で説明する各部は、ソフトウエアのみによって実現されてもよいし、ソフトウエアおよびハードウエアの組み合わせによって実現されてもよいし、あるいはハードウエアのみによって実現されてもよい。

登録部２００は、設定情報を代理サーバ１０３に登録するためのユニットである。設定情報は、例えば、クライアント１０２がネットワークデバイス１０１と通信するために必要となる情報などである。例えば、ネットワークデバイスのＩＰアドレス、プリンタポート、ネットワークデバイスのドライバに係る情報等である。登録部２００には、例えば、起動通知送信部２０１が含まれてもよい。この起動通知送信部２０１は、ネットワークデバイス１０１においてエージェントサービスが起動すると、代理サーバ１０３に起動通知を送信するユニットである。また、登録部２００には、応答受信部２０２も含まれてもよい。この応答受信部２０２は、起動通知を受信した代理サーバ１０３から送信される応答を受信するユニットである。なお、この応答には、例えば、クライアント１０２から送信される探索要求またはマルチキャストによる探索要求への応答動作を抑制（例：無効化）するための情報が含まれていてもよい。

探索応答部２０３は、代理サーバ１０３から送信される探索要求や、クライアント１０２から送信される探索要求に対して応答を送信するユニットである。なお、探索応答部２０３の応答動作は、制御部２１０によって制御される。

制御部２１０は、代理サーバ１０３において設定情報の代理送信が可能な状態になると、クライアント１０２から送信される探索要求またはマルチキャストによる探索要求への応答を抑制するユニットである。制御部２１０には、例えば、探索要求に対する応答を抑制するための抑制部２１１を含む。抑制部２１１は、例えば、代理サーバ１０３から応答の抑制指示を受信すると、応答の抑制を開始する。なお、抑制部２１１は、代理サーバ１０３からの探索要求、または、ユニキャストもしくはブロードキャストによる探索要求に対しては応答するよう探索応答部２０３を制御してもよい。

制御部２１０には、判定部２１２や抑制解除部２１３などが含まれてもよい。図２の点線は、判定部２１２や抑制解除部２１３がオプションであることを示している。判定部２１２は、代理サーバ１０３において、ネットワークデバイス１０１に関する設定情報の代理送信が可能な状態になったか否かを判定する。例えば、探索応答部２０３は、代理サーバ１０３から送信された（ユニキャストによる）探索要求を受信すると、設定情報を含む探索応答を送信する。次に、判定部２１２は、探索応答部２０３による探索応答の送信が実行されると、代理送信が可能な状態になったと判定することができる。なお、探索応答の送信が完了していない場合などに、判定部２１２は、代理送信が可能な状態になっていないと判定する。但し、探索応答の送信が完了していない場合であっても、将来的に代理送信が可能となる可能性が高い場合は、判定部２１２が、代理送信が可能な状態になったと判定してもよい。

抑制解除部２１３は、例えば、代理サーバ１０３が無反応の状態になると、クライアント１０２などによる探索要求に対する応答の抑制を解除する。代理サーバ１０３が無反応の状態になるときは、例えば、代理サーバ１０３が正常終了したときや、異常終了したときなどが該当しよう。このように、代理サーバ１０３が無反応となったときは、ネットワークデバイス１０１は、自動的に、クライアント１０２等からの探索要求に応答するよう切り替わる。よって、クライアント１０２から、ネットワークデバイス１０１を検出できなくなってしまうような不測の事態を回避できよう。

図３Ａは、実施形態に係る抑制解除部の例示的な構成を示す図である。抑制解除部２１３は、代理サーバ１０３の存在を確認する存在確認部３０１を備える。存在確認部３０１は、代理サーバ１０３に対して存在確認要求を送信する。存在確認要求は、代理サーバ１０３の存在を問い合わせるための要求である。なお、結果的に、代理サーバ１０３の存在を確認できれば、存在確認要求の形式および内容は問わない。もし代理サーバ１０３が正常に動作している場合、代理サーバ１０３は、存在確認要求に対して存在確認応答を送信する。よって、存在確認部３０１は、存在確認応答を受信すれば、代理サーバ１０３が存在していると判定できる。なお、存在確認部３０１は、他の装置（例：クライアント１０２）から存在確認依頼を受信したときに、存在確認要求を送信してもよい。

計時部３０２は、存在確認要求（存在の問い合せ）を送信してからの経過時間を計時するタイマーユニットである。無反応判定部３０３は、例えば、計時部３０２によって計時された経過時間が所定時間に達すると、代理サーバ１０３が無反応の状態になっていると判定する。無反応の場合、無反応判定部３０３は、抑制部２１１に対して抑制の解除指示を送信する。これによって、抑制部２１１は、抑制を解除するため、探索応答部２０３は、クライアント１０２からの探索要求や、マルチキャストによる探索要求にも応答を送信するようになる。

このように、ネットワークデバイス１０１は、必要に応じて代理サーバの存在を確認するため、存在確認のために送出するパケットも必要最小限にとどめることができよう。

なお、代理サーバ探索部３０４は、例えば、現在の代理サーバ１０３が無反応な状態になった場合に、他の代理サーバ等を検索するユニットである。これにより、ネットワークデバイス１０１は、他の代理サーバに自己の設定情報を登録することができるようになる。

図３Ｂは、実施形態に係る抑制解除部の他の例示的な構成を示す図である。存在明示受信部３１１は、代理サーバ１０３が正常に動作しているときに代理サーバ１０３から送信される存在明示情報（例：キープアライブパケットなど）を受信する。受信タイミング判定部３１２は、存在明示情報を所定タイミングで受信できているか否かを判定する。所定タイミングは、例えば、定期的なタイミングなどである。所定タイミングで存在明示情報を受信できなくなった場合、受信タイミング判定部３１２は、前記代理サーバが無反応の状態になっていると判定し、解除指示を出力する。

このように、ネットワークデバイス１０１は、代理サーバ１０３から所定のタイミングで送信されるはずの存在明示情報が途絶えると、代理サーバ１０３が無反応になったと認識できる。ネットワークデバイス１０１は、存在確認要求（図３Ａ）を送信する必要がなくなるため、処理負荷が軽減される可能性がある。

図３Ｃは、実施形態に係る抑制解除部の他の例示的な構成を示す図である。解除情報受信部３２１は、抑制を解除するための解除情報を受信するユニットである。この解除情報は、例えば、代理サーバ１０３が停止するのに先立って送信する停止情報であってもよい。解除情報を受信すると、解除情報受信部３２１は、解除指示を出力する。

このように、代理サーバ１０３が停止する場合は、事前に停止情報がネットワークデバイス１０１に通知されるため、ネットワークデバイス１０１が探索不能に陥ることを防止できよう。

なお、解除情報受信部３２１は、解除情報を受信し、かつ代理サーバ探索部３０４により他の代理サーバを検出できない場合に、解除指示を出力してもよい。すなわち、他の代理サーバが存在すれば、ネットワークデバイス１０１は、他の代理サーバに代理応答を依頼できるからである。もちろん、引き続き、トラヒックの低減効果が得られることはいうまでもない。

図４は、実施形態に係るクライアントの例示的なブロック図である。探索部４０１は、マルチキャストによる探索要求を送信したり、当該探索要求に対する探索応答（設定情報を含む）を受信したりするユニットである。なお、探索部４０１は、代理サーバ１０３に対してユニキャストによる探索要求を送信し、この探索要求に対する応答が代理サーバ１０３から得られない場合に、マルチキャストによる探索要求を送信するようにしてもよい。ユニキャストによる探索要求を優先した方が、トラヒックの増加を抑制できるからである。

なお、代理サーバ１０３から停止情報を受信することもある。この場合、探索部４０１は、他の代理サーバやネットワークデバイス１０１を探索するための探索要求を送信する。

検出部４０２は、存在確認依頼をネットワークデバイス１０１に送信する契機となる所定の送信契機を検出するユニットである。存在確認部４０３は、所定の送信契機が検出されると、ネットワークデバイス１０１に対して代理サーバ１０３の存在を確認するよう依頼するための存在確認依頼を送信する。送信契機は、例えば、代理サーバ１０３からの応答がない場合などである。

図５は、実施形態に係る代理サーバの例示的な機能ブロック図である。探索部５０１は、マルチキャストによる探索要求を送信したり、当該探索要求に対する探索応答（設定情報を含む）を受信したりするユニットである。なお、探索部５０１は、ユニキャストやブロードキャストによる探索要求も送信するように構成されてもよい。また、探索部５０１は、起動通知をネットワークデバイス１０１から受信すると、起動通知に対する応答をネットワークデバイス１０１に送信する。

記憶部５０２は、探索部５０１を通じて受信したネットワークデバイス１０１の設定情報を記憶するユニットである。代理応答部５０３は、マルチキャストによる探索要求を受信すると、記憶部５０２から設定情報を読み出して探索応答を作成し、探索応答を送信するユニットである。停止制御部５０４は、代理サーバ１０３が停止するのに先立って停止情報を送信するユニットである。

図６は、実施形態に係るネットワークデバイスの制御方法を示す例示的なフローチャートである。以下では、上述の探索処理のうち最も基本的なフローについて説明する。

ステップＳ６０１において、登録部２００は、ネットワークデバイス１０１の設定情報を代理サーバ１０３に登録する。ステップＳ６０２において、制御部２１０は、代理サーバ１０３が代理応答可能な状態になると、マルチキャストによる探索要求やクライアントから送信される探索要求に対する応答動作を抑制する。その結果、探索応答部２０３は、これらの探索要求を受信したとしても無視するように動作する。

以上説明したように本実施形態によれば、ネットワークデバイス１０１は、代理サーバ１０３が代理応答可能な状態になると、クライアント１０２からの探索要求やマルチキャストによる探索要求を無視するようになる。これにより、探索要求に対して、クライアント１０２と代理サーバ１０３の双方が応答してしまう事態を抑制できる。ひいては、応答に伴うトラヒックの増加も抑制されよう。

なお、クライアント１０２からの探索要求やマルチキャストによる探索要求への応答動作を抑制するための抑制指示を探索プロトコルに追加してもよい。すなわち、代理サーバ１０３が明示的な抑制指示を送信すれば、ネットワークデバイス１０１は、代理サーバ１０３が代理可能な状態になったか否かをネットワークデバイスで判定する処理が不要となろう。また、より確実に、応答動作を抑制することも可能となるので、明示的な抑制指示は好ましいであろう。

ネットワークデバイス１０１は、代理サーバ１０３からの探索要求やユニキャストによる探索要求については応答することはいうまでもない。これらの探索要求に対して応答したとしても、トラヒックに対する影響は相対的に小さいからである。また、代理サーバ１０３からの応答を無視してしまうと、代理サーバ１０３による代理応答を実現できないおそれもあるからである。

なお、ネットワークデバイス１０１が起動したときの起動通知を契機として、代理サーバ１０３は抑制指示を送信することができる。これによって、起動当初からトラヒックの増加を緩和できる利点がある。即ち、ネットワークデバイス１０１は、起動通知に対する応答を代理サーバ１０３から受信するのに応じて、マルチキャストによる探索要求やクライアントから送信される探索要求に対する応答動作を抑制してもよい。起動通知に対する応答を代理サーバ１０３から受信したことにより、代理サーバ１０３の存在が確認できたためである。

また、ネットワークデバイス１０１は、代理サーバ１０３から送信される探索要求に対して応答を完了すると、代理サーバ１０３が代理可能な状態になったと判断してもよい。すなわち、この応答の完了によって、代理サーバ１０３には設定情報がキャッシュされるため、代理応答が可能になるのである。

ところで、代理サーバ１０３が無反応になると、代理応答機能が停止している可能性がある。よって、代理サーバ１０３が無反応になったときは、ネットワークデバイス１０１は、抑制されていた応答動作を再度活性化することが望ましい。もし、応答動作を抑制したままにすると、ネットワークデバイス１０１をクライアント１０２から探索できなくなってしまうからである。

なお、代理サーバ１０３が存在（正常に動作）していることを確認するために、存在確認処理を行ってもよい。あるいは、代理サーバ１０３から所定タイミングで送信される存在明示情報に基づいて、存在確認処理を実行してもよい。代理サーバ１０３の存在を確認できなければ、代理サーバ１０３が停止または暴走している可能性があるので、ネットワークデバイス１０１は応答動作の抑制を解除することが望ましい。

なお、代理サーバ１０３は、停止するのに先立って解除情報をネットワークデバイス１０１に送信してもよい。これにより、ネットワークデバイス１０１は、即座に、応答動作を活性化することが可能となる。

また、ネットワークデバイス１０１は、応答動作を活性化する際に、他の代理サーバ１０３を検索してもよい。もし、他の代理サーバ１０３が存在すれば、当該他の代理サーバ１０３に代理応答を依頼できるからである。できる限り代理サーバを利用した方が、トラヒックの抑制効果が高まることはいうまでもない。

ところで、クライアント１０２は、代理サーバ１０３に対してユニキャストによる探索要求を送信することが望ましい。マルチキャストによる探索要求は、相対的にトラヒックが増大してしまうからである。但し、代理サーバ１０３から応答が得られない場合は、マルチキャストによる探索要求を送信してもよい。これにより、クライアント１０２は、代理サーバ１０３が応答不能に陥っても、ネットワークデバイス１０１を好適に探索することが可能となる。なお、クライアント１０２は、所定の送信契機に応じて、ネットワークデバイス１０１に代理サーバ１０３の存在を確認させてもよい。

［第２の実施形態］
以下では、第１の実施形態で説明した発明の下位概念として第２の実施形態を説明する。本実施形態は、ＵＰｎＰに本発明を適用した事例である。なお、本発明は、ＵＰｎＰにのみ限定されるわけではなく、他の探索プロトコルにも同様に適用できることは言うまでもない。

なお、第１の実施形態と共通する事項については、同一の参照符号を付すことで説明を簡潔化する。

図７は、実施形態に係るクライアントおよび代理サーバの例示的な機能ブロック図である。ここでは、説明の簡略化のため、クライアントおよび代理サーバとも一般的なＰＣとして説明する。なお、さらに説明を簡略化するため、クライアントプログラムと代理サーバプログラムとが同一のＰＣ上で実行されるものとする。現実には、クライアントプログラムと代理サーバプログラムとは、異なるＰＣ上で実行されることはいうまでもない。なお、クライアントプログラムまたは当該プログラムが実行されているネットワークデバイスは、探索エージェントと呼ばれることもある。

クライアント１０２および代理サーバ１０３のハードウエア構成例は、次の通りである。ＣＰＵ８０１は、装置の各部を統括的に制御する制御ユニットである。ＲＡＭ７０２は、ワークエリアとして機能する揮発性の記憶ユニットである。ＲＯＭ７０３は、フォントデータ、プログラムおよび各種データを記憶する不揮発性の記憶ユニットである。７０４は、内部バスである。キーボードコントローラ（ＫＢＣ）７０５は、キーボード７０９やポインティングデバイス等を制御するための制御ユニットである。ＣＲＴコントローラ（ＣＲＴＣ）７０６は、ＣＲＴディスプレイ（ＣＲＴ）７１０を制御するための制御ユニットである。ディスクコントローラ（ＤＫＣ）７０７は、外部メモリ７１１を制御する制御ユニットである。外部メモリ７１１は、フレキシブルディスクドライブやハードディスクドライブなどである。ネットワークカード７０８は、イーサネット（登録商標）カードなど、ＬＡＮ１１０と接続するための通信ユニットである。

なお、ＲＯＭ７０３または外部メモリ７１１には、クライアントプログラム、オペレーティングシステム（ＯＳ）、プリンタドライバなどのコンピュータプログラムが記憶されている。

図８は、実施形態に係るネットワークデバイスの例示的な機能ブロック図である。この例では、ネットワークデバイス１０１としてプリンタを取り上げる。もちろん、他の周辺機器であっても、本発明を適用できることはいうまでもない。

ＣＰＵ８０１は、装置の各部を統括的に制御する制御ユニットである。ＲＡＭ８０２は、ワークエリアとして機能する揮発性の記憶ユニットである。ＲＯＭ８０３は、フォントデータ、プログラムおよび各種データを記憶する不揮発性の記憶ユニットである。８０４は、内部バスである。印刷部インタフェース８０６は、印刷部８１０を制御するための制御ユニットである。印刷部８１０は、レーザプリンタエンジンやインクジェットプリンタエンジンなどの画像形成ユニットである。メモリコントローラ（ＭＣ）８０７は、外部メモリ８１１を制御する制御ユニットである。外部メモリ８１１は、フレキシブルディスクドライブやハードディスクドライブなどである。外部メモリ８１１は、例えば、フォントデータ、エミュレーションプログラム、フォームデータ等を記憶している。ネットワークカード８０８は、イーサネット（登録商標）カードや無線ＬＡＮカードなど、ＬＡＮ１１０と接続するための通信ユニットである。

図９は、実施形態に係る探索応答処理の例示的なフローチャートである。なお、本応答処理（エージェントサービス）は、ネットワークデバイス（例：プリンタ）１０１において実行されるものとする。また、この応答処理を実行するためのコンピュータプログラムは、ＲＯＭ８０３または外部メモリ８１１に記憶されているものとする。

ステップＳ９０１で、ＣＰＵ８０１は、エージェントプログラムが起動すると、デフォルトの応答動作（応答モード）を規定した設定データを取得する。エージェントプログラムは、エージェントサービスを提供するソフトウエアである。デフォルトの設定データは、例えば、ＲＯＭ８０３などに記憶されているものとする。この設定データには、探索リクエストを受信したときの応答動作を決定するための情報が含まれている。応答動作としては、例えば、マルチキャストモードと非マルチキャストモードとがある。マルチキャストモードに設定されている場合、ＣＰＵ８０１は、マルチキャストによるリクエストパケット（探索／ｍｕｌｔｉｃａｓｔパケット）にも応答する。もちろん、ＣＰＵ８０１は、ユニキャストによるリクエストパケットおよびブロードキャストによるリクエストパケットにも応答する。ここで、マルチキャストによるリクエストパケットとは、あて先としてマルチキャストアドレスが設定された探索リクエストパケットを意味する。また、ユニキャストによるリクエストパケットとは、あて先としてユニキャストアドレスが設定された探索リクエストパケットを意味する。また、ブロードキャストによるリクエストパケットとは、あて先としてブロードキャストアドレスが設定された探索リクエストパケットを意味する。

一方、非マルチキャストモードに設定されている場合、ＣＰＵ８０１は、ユニキャストによるリクエストパケット、および、ブロードキャストによるリクエストパケットにのみ応答する。すなわち、非マルチキャストモードで、ＣＰＵ８０１は、マルチキャストによるリクエストパケットについては応答を抑制する。

ステップＳ９０２で、ＣＰＵ８０１は、取得した設定データに基づき、マルチキャストによるリクエストパケットに応答するか否かを判定する。設定データが、マルチキャストによるリクエストパケットに対する応答動作を無効としている場合（非マルチキャストモードの場合）、ステップＳ９０３に進む。

ステップＳ９０３で、ＣＰＵ８０１は、マルチキャストによるリクエストパケットに対する応答動作を無効とするように設定する。例えば、ＣＰＵ８０１は、ＲＡＭ８０２に記憶されている有効／無効フラグを１（無効）に設定する。

一方、応答動作が有効の場合（マルチキャストモードの場合）、ステップＳ９０４に進む。ステップＳ９０４において、ＣＰＵ８０１は、マルチキャストによるリクエストパケットに対する応答動作を有効とするように設定する。例えば、ＣＰＵ８０１は、ＲＡＭ８０２に記憶されている有効／無効フラグを０（有効）に設定する。

ステップＳ９０５で、ＣＰＵ８０２は、ネットワークカード８０８を通じて、クライアント１０２、代理サーバ１０３および他の探索エージェントなどに、起動通知パケットを送信する。起動通知パケットは、エージェントプログラムが起動したことを表すパケットである。

ステップＳ９０６で、ＣＰＵ８０１が、起動通知に対する代理サーバ１０３からの応答パケットを受信するまで待機する。この際に、ＣＰＵ８０１は、内部タイマーによる計時を開始する。代理サーバ１０３は、起動通知パケットを受信すると、ユニキャストにより応答パケットをネットワークデバイス１０１に送信する。

ステップＳ９０７で、ＣＰＵ８０１は、タイマーがタイムアウトしたか否かを判定する。すなわち、待機時間が所定時間を超えると「タイムアウト」となる。タイムアウトしていなければ、ステップＳ９０８に進む。タイムアウトしていれば、ステップＳ９１４に進む。

ステップＳ９０８で、ＣＰＵ８０１は、受信した応答パケットが探索サービスの応答動作を無効化するための設定パケットであるか否かを判定する。無効化するためのパケットであれば、ステップＳ９０９に進む。有効化するためのパケットであれば、ステップＳ９１４に進む。

ステップＳ９０９で、ＣＰＵ８０１は、エージェントサービスの内部ステータスが終了を意味するステータス（以下、終了ステータス）になっているかどうかを判定する。例えば、受信した応答パケットが、エージェントサービスの終了指示パケットであった場合は、終了ステータスとなる。終了ステータスであれば、ＣＰＵ８０１は、本フローチャートに係るエージェントサービスをシャットダウンする。

一方、終了ステータスでなければ、ステップＳ９１０で、ＣＰＵ８０１は、リクエストパケットの受信を試行する。

ステップＳ９１１で、ＣＰＵ８０１は、受信したリクエストパケットが、マルチキャストによるリクエストパケットであった場合は、これを無視してステップＳ９０９に進む。これによって、応答動作が好適に抑制される。

一方、マルチキャストによるリクエストパケットでなければ、すなわち、ユニキャストまたはブロードキャストによるリクエストパケットであれば、ステップＳ９１２に進む。

ステップＳ９１２で、ＣＰＵ８０１は、受信したリクエストパケットに対する応答パケットを作成して、ネットワークカード８０８を通じて送信する。

ところで、ステップＳ９０７でタイムアウトした場合、または、ステップＳ９０８で明示的な有効化を示すパケットを受信した場合は、ステップＳ９１４に進む。すなわち、起動通知パケットを送信しても、応答パケットを受信できなければ、代理サーバ１０３がネットワーク上に存在しないことになる。この場合、通常どおり、マルチキャストによるリクエストパケットに応答する必要がある。

ステップＳ９１４で、ＣＰＵ８０１は、エージェントプログラムの応答動作をマルチキャストモードに変更する。すなわち、マルチキャストによるリクエストパケットへの応答動作を有効化する。

ステップＳ９１５で、ＣＰＵ８０１は、リクエストパケットの受信待ちを行う。ステップＳ９１６で、ＣＰＵ８０１は、受信したリクエストパケットに対して応答パケットを作成し、送信する。

ステップＳ９１７で、ＣＰＵ８０１は、受信したパケットが、応答動作の再設定を指示するパケット（以下、再設定パケット）か、否かを判定する。再設定パケットの場合は、ステップＳ９０８に戻る。一方、再設定パケットでなければ、ステップＳ９１８で、終了ステータスか否かを判定する。終了ステータスであれば、ＣＰＵ８０１は、本フローチャートに係るエージェントサービスをシャットダウンする。一方、終了ステータスでなければ、ステップＳ９１５に戻り、ＣＰＵ８０１は、リクエストパケットの受信を試行する。

図１０は、実施形態に係る探索プロトコルの例示的なシーケンス図である。まず、探索エージェントとして動作しているネットワークデバイス１０１は、起動通知パケットを（マルチキャスト）送信する（Ｓ９０５）。代理サーバ１０３やクライアント１０２のＣＰＵ７０１は、ネットワークカード７０８を通じて起動通知パケットを受信する。Ｓ１００２で、代理サーバ１０３のＣＰＵ７０１は、ネットワークデバイス１０１に対し起動通知に対する応答パケットを（ユニキャスト）送信する。

さらに、Ｓ１００３で、代理サーバ１０３のＣＰＵ７０１は、ネットワークデバイス１０１に、マルチキャストによるリクエストパケットに対する応答動作を無効化するための指示パケットを送信する。これにより、Ｓ１００４で、ネットワークデバイス１０１は、非マルチキャストモードに移行する（Ｓ９０６ないしＳ９１２）。

さらに、Ｓ１００５で、代理サーバ１０３のＣＰＵ７０１は、ネットワークデバイス１０１に対し、ユニキャストによるリクエストパケットを送信する。ネットワークデバイス１０１は、当該パケットを受信すると、代理サーバ１０３に登録するための設定情報を含む応答パケット（ユニキャスト）を作成し、返信する（Ｓ９１０ないしＳ９１２）。

Ｓ１００６で、代理サーバ１０３のＣＰＵ７０１は、応答パケット（ユニキャスト）を受信する。Ｓ１００７で、代理サーバ１０３のＣＰＵ７０１は、受信した応答パケットに含まれている設定情報を外部メモリ７１１に記憶する。

その後、Ｓ１００８で、クライアント１０２のＣＰＵ７０１は、ネットワークカード７０８を通じて、マルチキャストによるリクエストパケットを送信する。Ｓ１００９で、ネットワークデバイス１０１は、応答動作が無効化されているため、当該パケットを無視する（Ｓ９１１でＹｅｓ）。

Ｓ１０１０で、代理サーバ１０３のＣＰＵ７０１は、外部メモリ６１１に記憶している設定情報を検索する。リクエストパケットに含まれる検索条件に合致する設定情報が含まれていれば、ＣＰＵ７０１は、当該設定情報を読み出して、応答パケットを送信する。一方、設定情報が見つかれない場合、ＣＰＵ７０１は、探索の対象となっているネットワークデバイス１０１に対して、リクエストパケット（ユニキャスト）を送信する。ネットワークデバイス１０１は、当該パケットを受信すると、代理サーバ１０３に登録するための設定情報を含む応答パケット（ユニキャスト）を作成し、返信する（Ｓ９１０ないしＳ９１２）。代理サーバ１０３は、当該設定情報を外部メモリ７１１に記憶する。その後、Ｓ１０１１で、代理サーバ１０３のＣＰＵ７０１は、読み出した設定情報を含む探索応答パケットを作成し、当該応答パケットにクライアントのアドレスを設定し、ユニキャストで送信する。クライアント１０２のＣＰＵ７０１は、ネットワークデバイス１０１の設定情報を受信し、ネットワークデバイス１０１で通信できるように設定処理を実行する。

以上説明したように本実施形態に係る発明によれば、代理サーバ１０３による代理応答が可能なると、ネットワークデバイス１０１は、マルチキャストによるリクエストパケットへの応答動作を抑制する。そのため、従来のように、当該パケットに、ネットワークデバイス１０１と代理サーバ１０３の双方が応答してしまうことを抑制できる。また、探索プロトコルによるトラヒックを軽減できるであろう。なお、他の効果については、第１の実施形態において説明したので、省略する。

［第３の実施形態］
代理サーバ１０３は、種々の事情で停止することがある。もし、ネットワークデバイス１０１が非マルチキャストモードで動作している最中に、代理サーバ１０３が停止してしまうと、クラインアント装置１０２は、ネットワークデバイス１０１を半永久的に探索できなくなってしまうおそれがある。

そこで、本実施形態では、代理サーバ１０３が停止する場合は、ネットワークデバイス１０１に停止を通知することで、マルチキャストモードに移行させる発明を説明する。

図１１は、実施形態に係る代理サーバの停止を考慮した探索応答処理の例示的なフローチャートである。なお、本フローチャートに係る処理は、図９のステップＳ９１２をサブルーチン化したものである。よって、既に説明した個所には、同一の参照符号を付すことで、説明を簡潔にする。

ステップＳ１１０１で、ネットワークデバイス１０１のＣＰＵ８０１は、受信したパケットが代理サーバ１０３の停止を意味する停止通知パケットであるか否かを判定する。停止通知パケットであれば、ステップＳ１１０２に進み、ＣＰＵ８０１は、他の代理サーバを探索する。ＣＰＵ８０１は、例えば、ＲＦＣ２１６５において標準化されたＳＬＰ（Ｓｅｒｖｉｃｅ Ｌｏｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）や、本願の出願人他が提案したＷＳ−Ｄｉｓｃｏｖｅｒｙなどの探索プロトコルを用いて他の代理サーバを検索する。もちろん、他の探索プロトコルを採用してもよい。

ステップＳ１１０３において、ＣＰＵ８０１は、他の代理サーバが存在するか否かを判定する。他の代理サーバが存在しない場合は、ステップＳ９１４に進み、ＣＰＵ８０１は、マルチキャストモードに移行する。これにより、クライアント１０２から送信されるマルチキャスによるリクエストパケットにも応答できるようになる。

他の代理サーバが存在する場合は、Ｓ９０９に戻り、当該代理サーバからのリクエストパケットを待つ。なお、見つかった他の代理サーバに設定情報の登録が済んでいない場合、ＣＰＵ８０１は、設定情報を当該他の代理サーバに登録する。

一方、Ｓ１１０１で停止通知パケットでないと判定した場合、ＣＰＵ８０１は、ステップＳ１１０４に進み、受信したパケットの種類に応じた応答処理を実行する。

以上説明したように本実施形態に係る発明によれば、第１の実施形態の効果に加え、代理サーバの停止に伴う課題を解決できる効果がある。すなわち、代理サーバ１０３から停止通知パケットを送信することで、ネットワークワーデバイス１０１は、マルチキャストモードに復帰することができる。すなわち、クライアント１０２は、ネットワークデバイス１０１を探索できるようになる。

なお、他の代理サーバが存在する場合、ネットワークデバイス１０１を継続して非マルチキャストモードで動作させてもよい。このようにすれば、探索処理に伴うトラヒックの増加を引き続き軽減できるからである。

［第４の実施形態］
第３の実施形態では、代理サーバ１０３が正常に停止または終了することを前提として説明した。しかしながら、現実の動作環境下では、代理サーバ１０３が異常終了してしまうこともある。異常終了のとき、代理サーバ１０３は、停止通知を送信できない可能性が高い。そのため、第３の実施形態では、代理サーバ１０３が異常停止したときに問題が生じる。すなわち、非マルチキャストモードで動作しているネットワークデバイス１０１を、クライアント１０２が探索できなくなってしまう。なお、異常停止以外であっても、例えば、代理サーバ１０３とＬＡＮ１１０との接続が切断され場合も同様の問題が生じる。

そこで、本実施形態では、エージェントプログラムに、代理サーバの存在確認機能を追加する。もし、存在を確認できない場合にはマルチキャストモードに復帰することはいうまでもない。なお、クライアント１０２等から非マルチキャストモードの解除情報を受信したときも、マルチキャストモードに復帰するようにしてもよい。

図１２は、実施形態に係る代理サーバの異常停止を考慮した探索応答処理の例示的なフローチャートである。なお、本フローチャートに係る処理は、図９のＳ９１２または図１１のＳ１１０４に相当するサブルーチンである。よって、既に説明した個所には、同一の参照符号を付すことで、説明を簡潔にする。また、本実施形態は、第２の実施形態だけでなく、第３の実施形態と組み合わせてもよい。

ステップＳ１２０１で、ネットワークデバイスのＣＰＵ８０１は、受信したパケットが代理サーバ１０３の存在確認を依頼するパケットであるか否かを判定する。存在確認依頼パケットは、例えば、クライアント１０２などから送信される。存在確認依頼パケットでなければ、ステップＳ１２０４に進む。存在確認依頼パケットであれば、ステップＳ１２０２に進む。

ステップＳ１２０２で、ＣＰＵ８０１は、代理サーバ１０３の存在確認を実行する。例えば、ＣＰＵ８０１は、ネットワークデバイス１０１自身を探索するためのリクエストパケット（存在の問い合せ）を作成し、代理サーバ１０３に送信する。代理サーバ１０３のＣＰＵ７０１は、当該リクエストパケットを受信すると、応答パケットを返信する。

ステップＳ１２０３で、ＣＰＵ８０１は、代理サーバ１０３からの応答を所定時間内に受信できたか否かを判定する。応答がなければ、代理サーバ１０３が存在しないことになるので、ステップＳ９１４に進む。すなわち、ＣＰＵ８０１は、マルチキャストモードに復帰する。一方、応答があれば、ステップＳ１２０４に進む。

ステップＳ１２０４で、ＣＰＵ８０１は、受信したパケットが、代理サーバ１０３により定期的に送信されることになっている存在明示（キープアライブ）パケットであるか否かを判定する。存在明示パケットを定期的なタイミングで受信できなかった場合、ステップＳ９１４に戻る。すなわち、ＣＰＵ８０１は、マルチキャストモードに復帰する。一方、定期的なタイミングで存在明示パケットを受信できていれば、ステップＳ１２０５に進む。なお、代理サーバ１０３のＣＰＵ７０１は、内部タイマーにて定期的なタイミングを検出し、存在明示パケットをネットワークデバイス１０１に送信するものとする。

ステップＳ１２０５で、ＣＰＵ８０１は、受信パケットが、非マルチキャストモードを強制解除するための指示パケット（強制解除パケット）であるか否かを判定する。このパケットは、マルチキャストによるリクエストパケットへの応答動作を有効化するためのパケットと観念することもできる。強制解除パケットであれば、ステップＳ９１４に進む。一方、強制解除パケットでなければ、ＣＰＵ８０１は、受信したパケットの種類に応じて応答処理を実行し、ステップＳ９０９に戻る。

以上説明したように本実施形態に係る発明によれば、代理サーバ１０３が異常停止等した場合には、ネットワークデバイス１０１は、マルチキャストモードへと復帰する。よって、ネットワークデバイス１０１を検索できなくなってしまう問題を解決できよう。

なお、図１２において、Ｓ１２０１ないしＳ１２０３と、Ｓ１２０４は、少なくとも一方が本サブルーチンに含まれていればよい。いずれか一方が含まれていれば、代理サーバ１０３の非常停止を検出できるからである。なお、Ｓ１２０１ないしＳ１２０３を実行する場合は、クライアント１０２または他の代理サーバのＣＰＵ８０１等が存在確認要求をネットワークデバイス１０１に送信できることが前提である。

［他の実施形態］
以上、様々な実施形態を詳述したが、本発明は、複数の機器から構成されるシステムに適用してもよい。また、本発明は、一つの機器からなる装置に適用してもよい。例えば、スキャナ、プリンタ、ＰＣ、複写機、複合機及びファクシミリ装置の如くである。すなわち、ネットワークに接続する機能を備えている装置であれば本発明を適用できることは言うまでもない。

また、ＬＡＮに限らず、ＷＡＮや無線ＬＡＮなどの他のネットワークであっても本発明を適用できることは言うまでもない。

本発明は、前述した実施形態の各機能を実現するソフトウェアプログラムを、システム若しくは装置に対して直接または遠隔から供給し、そのシステム等に含まれるコンピュータが該供給されたプログラムコードを読み出して実行することによっても達成される。

従って、本発明の機能・処理をコンピュータで実現するために、該コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、上記機能・処理を実現するためのコンピュータプログラム自体も本発明の一つである。

その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。

プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷなどがある。また、記録媒体としては、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などもある。

また、プログラムは、クライアントコンピュータのブラウザを用いてインターネットのホームページからダウンロードしてもよい。すなわち、該ホームページから本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードしてもよいのである。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明の構成要件となる場合がある。

また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布してもよい。この場合、所定条件をクリアしたユーザにのみ、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報で暗号化されたプログラムを復号して実行し、プログラムをコンピュータにインストールしてもよい。

また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現されてもよい。なお、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行ってもよい。もちろん、この場合も、前述した実施形態の機能が実現され得る。

さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれてもよい。そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行ってもよい。このようにして、前述した実施形態の機能が実現されることもある。

本実施形態に係るネットワークデバイスの一例を示す図である。 実施形態に係るネットワークデバイスの例示的なブロック図である。 実施形態に係る抑制解除部の例示的な構成を示す図である。 実施形態に係る抑制解除部の他の例示的な構成を示す図である。 実施形態に係る抑制解除部のさらに他の例示的な構成を示す図である。 実施形態に係るクライアント装置の例示的なブロック図である。 実施形態に係る代理サーバの例示的な機能ブロック図である。 実施形態に係るネットワークデバイスの制御方法を示す例示的なフローチャートである。 実施形態に係るクライアント装置および代理サーバの例示的な機能ブロック図である。 実施形態に係るネットワークデバイスの例示的な機能ブロック図である。 実施形態に係る探索応答処理の例示的なフローチャートである。 実施形態に係る探索プロトコルの例示的なシーケンス図である。 実施形態に係る代理サーバの正常停止を考慮した探索応答処理の例示的なフローチャートである。 実施形態に係る代理サーバの異常停止を考慮した探索応答処理の例示的なフローチャートである。

Claims (12)

1. ネットワークを介して接続されたクライアント装置及び代理サーバと通信するネットワークデバイスであって、
   前記ネットワークデバイスの設定情報を要求するために前記クライアント装置からマルチキャストにより送信される探索要求に対する応答を抑制するための指示を、前記代理サーバから受信する受信手段と、
   前記クライアント装置から送信される探索要求に対して前記ネットワークデバイスの代わりに前記代理サーバが前記ネットワークデバイスの設定情報を応答できるように、前記ネットワークデバイスの設定情報を前記代理サーバに送信する送信手段と、
   前記受信手段によって前記指示を受信した場合、前記クライアント装置から送信される探索要求であって前記ネットワークデバイスは受信し前記代理サーバが受信しないユニキャストによって送信される探索要求に対して前記ネットワークデバイスの設定情報を応答し、前記クライアント装置から送信される探索要求であって前記ネットワークデバイスと前記代理サーバが共に受信するマルチキャストによって送信される探索要求に対する応答を抑制する制御手段とを含む、ネットワークデバイス。
2. 前記送信手段は、前記代理サーバから送信される探索要求に応答して、前記ネットワークデバイスの設定情報を送信する請求項１に記載のネットワークデバイス。
3. 前記ネットワークデバイスが起動したことを表す起動通知を前記代理サーバに送信する手段と、
   前記代理サーバから前記起動通知に対する応答を受信する手段と、
   前記起動通知を送信した後に所定時間が経過するまでに前記起動通知に対する応答を受信したか否かを判断する判断手段と
   をさらに含み、
   前記制御手段は、前記起動通知を送信した後に所定時間が経過するまでに前記起動通知に対する応答を受信したと前記判断手段が判断したことに応じて、前記クライアント装置から送信されるマルチキャストによって送信される探索要求に対する応答を抑制する、請求項１又は２に記載のネットワークデバイス。
4. 前記制御手段による、前記マルチキャストによって送信される探索要求への応答の抑制を解除する手段をさらに含む、請求項１ないし３の何れか１項に記載のネットワークデバイス。
5. 前記マルチキャストによって送信される探索要求への応答の抑制を解除する手段は、
   前記代理サーバに対して問い合せを送信する手段と、
   前記問い合せに対する応答を受信するまでの時間を計時する手段と、
   前記時間が予め定められた時間に達すると、前記マルチキャストによって送信される探索要求への応答の抑制を解除すると判定する手段と
   を含む、請求項４に記載のネットワークデバイス。
6. 前記マルチキャストによって送信される探索要求への応答の抑制を解除する手段は、
   前記代理サーバから予め定められたタイミングで送信される存在明示情報を受信する手段と、
   前記存在明示情報を前記予め定められたタイミングで受信できなくなると、前記マルチキャストによって送信される探索要求への応答の抑制を解除すると判定する手段と
   を含む、請求項４に記載のネットワークデバイス。
7. 前記マルチキャストによって送信される探索要求への応答の抑制を解除するための解除情報を受信する手段と、
   前記解除情報を受信すると、前記マルチキャストによって送信される探索要求への応答の抑制を解除する手段と
   をさらに含む、請求項１ないし３の何れか１項に記載のネットワークデバイス。
8. 前記解除情報は、前記代理サーバが停止するのに先立って送信される停止情報である、請求項７に記載のネットワークデバイス。
9. 前記マルチキャストによって送信される探索要求への応答の抑制を解除する手段は、
   前記解除情報を受信し、かつ他の代理サーバと通信できない場合に、前記マルチキャストによって送信される探索要求への応答の抑制を解除する、請求項７または８に記載のネットワークデバイス。
10. 前記送信手段によって送信される設定情報は、前記ネットワークデバイスのＩＰアドレス又はプリンタポート又は当該ネットワークデバイスのドライバに係る情報であることを特徴とする請求項１ないし９の何れか１項に記載のネットワークデバイス。
11. ネットワークを介して接続されたクライアント装置及び代理サーバと通信するネットワークデバイスの制御方法であって、
    受信手段が、前記ネットワークデバイスの設定情報を要求するために前記クライアント装置からマルチキャストにより送信される探索要求に対する応答を抑制するための指示を、前記代理サーバから受信する受信工程と、
    送信手段が、前記クライアント装置から送信される探索要求に対して前記ネットワークデバイスの代わりに前記代理サーバが前記ネットワークデバイスの設定情報を応答できるように、前記ネットワークデバイスの設定情報を前記代理サーバに送信する送信工程と、
    制御手段が、前記受信手段によって前記指示を受信した場合、前記クライアント装置から送信される探索要求であって前記ネットワークデバイスは受信し前記代理サーバが受信しないユニキャストによって送信される探索要求に対して前記ネットワークデバイスの設定情報を応答し、前記クライアント装置から送信される探索要求であって前記ネットワークデバイスと前記代理サーバが共に受信するマルチキャストによって送信される探索要求に対する応答を抑制する制御工程と
    を含む、ネットワークデバイスの制御方法。
12. 請求項１に記載のネットワークデバイスが備える各手段としてコンピュータを機能させることを特徴とするプログラム。

Images