JP5558681B2 - デバイス検索装置、デバイス検索装置の制御方法、及びコンピュータプログラム - Google Patents

Description

本発明は、デバイスを検索するデバイス検索装置、デバイス検索装置の制御方法、及びコンピュータプログラムに関する。

従来、ネットワークに接続されたパーソナルコンピュータ等の各クライアントが、ネットワークに接続されたプリンタ等のデバイスを検索し、利用することが可能になっている。デバイスを検索する検索方法として、クライアントが検索要求データをマルチキャストによって送信し、その検索要求に対する応答を各デバイスから受信する方法がある。また、ネットワーク上に各デバイスの情報を保持する検索サーバ（Ｄｉｓｃｏｖｅｒｙ Ｐｒｏｘｙ、以降ＤＰと呼ぶ）を設置し、クライアントは検索サーバから検索結果を受信する方法がある。

通常、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）等によって構築されるネットワークは、複数のサブネットから構成される。各サブネットは、ルータを介して接続されており、ルータは一方のサブネットから受信したブロードキャストやマルチキャストによって送信されたデータを、他方のサブネットにそのまま通過させることを禁止していることが多い。この場合、クライアントからブロードキャストやマルチキャストによって送信された検索要求のデータは、クライアントが存在するサブネット内のみに送信される。従って、上述の検索方法によると、クライアントは、自装置が存在するサブネットに存在するデバイスしか検索できないことになる。

このような問題を解決するため、即ち、他のサブネットに存在するデバイスも検索できるようにするために、以下のような方法が考えられている（例えば、特許文献１参照）。

デバイスからデバイス情報を取得するサーバ装置を設ける。サーバ装置は、自装置が存在するサブネットとは異なる他のサブネット上のデバイスからデバイス情報を取得する。クライアントは、サーバ装置から他のサブネットに存在するデバイスの情報を取得する。

この方法によれば、クライアントは、自装置が存在するサブネット上のデバイスだけでなく、他のサブネット上のデバイスの情報までも取得することができるようになる。
特開２００３−６１３３号公報

しかしながら、上記従来の技術では、サーバ装置が、サーバ装置自身が存在するサブネットだけでなく、他のサブネットに存在するデバイスの情報までも管理する必要があるため、サーバ装置にかかる負荷が増大する。これに対して、サーバ装置の負荷分散を図るために、複数のサーバ装置を用意し、サブネット毎にサーバ装置を設置する方法が考えられる。そして、各サブネットに設置されたサーバ装置は、自装置が存在するサブネット上のデバイス情報のみを管理する。この場合、クライアントは、自装置が存在するサブネットとは異なる他のサブネット上のデバイスを検索するために、他のサブネットに設置されたサーバ装置に対して検索要求を送信することになる。しかし、上述したようにマルチキャストで送信すると他のサブネットに送信されないため、クライアントは、このサーバ装置に対してユニキャストを用いて検索要求を送信しなければならない。従って、クライアントはそのサーバ装置のアドレスを知っている必要があり、予めサーバ装置のアドレスをクライアントに登録しておかなければならない。

各サブネットには、通常、サーバ装置に比べて多数のクライアントが接続されていることから、これら多数のクライアントに対して、サーバ装置のアドレスの登録を行うことはユーザにとって煩雑な作業となる。

本発明は、このような問題を解決し、ルータを介して接続された複数のサブネットを有するネットワークシステムにおいて、クライアントが他のサブネットに存在するデバイスをより効率的に検索できるようにすることを目的とする。

上記問題を解決するために、本発明におけるデバイス検索装置は、デバイスを検索するための検索要求であって、検索要求を転送済みのデバイス検索装置を特定するための特定情報を含む検索要求を受信する受信手段と、前記受信手段が受信した検索要求に含まれる検索条件を満たすデバイスを検索する検索手段と、他のデバイス検索装置を示す情報を記憶する記憶手段と、前記特定情報に基づいて、前記記憶手段が記憶している情報が示す前記他のデバイス検索装置のうち、検索要求が転送されていないデバイス検索装置に前記受信手段が受信した検索要求を転送し、検索要求を転送済みのデバイス検索装置に前記受信手段が受信した検索要求を転送しない転送手段とを備えることを特徴とする。

本発明によれば、ルータを介して接続された複数のサブネットを有するネットワークシステムにおいても、他のサブネットに存在するデバイスを検索できるようになる。

（実施例１）
図１は本発明を適用したデバイス検索システムの構成を示す図である。図１のネットワークシステムは、サブネット１、２、３の３つのサブネットによって構成されている。各サブネットは、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）によって構成されており、図１のネットワークに接続された各装置は、ＴＣＰ／ＩＰに従って通信する。

サブネット１は、Ｄｉｓｃｏｖｅｒｙ Ｐｒｏｘｙ（以下、ＤＰと呼ぶ）１０１が接続されている。ＤＰ１０１のＩＰアドレスは、１９２．１６８．２．１０である。サブネット２は、ＤＰ１０２とクライアントＰＣ１０４と画像形成装置１０８が接続されている。ＤＰ１０２のＩＰアドレスは１９２．１６８．１．１０であり、クライアントＰＣ１０４のＩＰアドレスは１９２．１６８．１．１００であり、画像形成装置１０８のＩＰアドレスは１９２．１６８．１．１である。サブネット３は、ＤＰ１０３とクライアントＰＣ１０９と画像形成装置１０５，１１０が接続されている。ＤＰ１０３のＩＰアドレスは１９２．１６８．０．１０である。クライアントＰＣ１０９のＩＰアドレスは１９２．１６８．０．１００であり、画像形成装置１０５のＩＰアドレスは１９２．１６８．０．１であり、画像形成装置１１０のＩＰアドレスは１９２．１６８．０．２である。

サブネット１とサブネット２はルータ１０６により相互に接続されている。また、サブネット１とサブネット３はルータ１０７により相互に接続されている。結果としてすべてのサブネットにおいて接続された端末は相互に通信が可能になっている。ただし、ルータ１０６、１０７は一方のサブネットからブロードキャストやマルチキャストによって送信されたデータを他方のサブネットにそのまま通過させないように設定されている。そのため、ブロードキャストやマルチキャストによって送信されたデータは各サブネット内でのみ通信される。

次に、図１で示したシステム構成の中で、ＤＰ１０１、ＤＰ１０２、ＤＰ１０３、クライアントＰＣ１０４、１０９、画像形成装置１０５、１０８、１１０のハードウェアおよびソフトウェア構成について説明する。なお、以降では特に断らない限りＤＰに関しては代表して１０２の記号を用い、クライアントＰＣに関しては１０４の記号を用い、画像形成装置に関しては１０５の記号を用いる。

図２は画像形成装置１０５のハードウェア構成を示すブロック図である。

リーダー部（画像入力装置）２０１は、原稿画像を光学的に読み取り、画像データに変換する。リーダー部２０１は、原稿を読み取るための機能を持つスキャナユニット２０２と、原稿用紙を搬送するための機能を持つ原稿給紙ユニット２０３とで構成される。

プリンタ部（画像出力装置）２０４は、記録紙を搬送し、その上に画像データを可視画像として印字して装置外に排紙する。プリンタ部２０４は、複数種類の記録紙カセットを持つ給紙ユニット２０５と、画像データを記録紙に転写、定着させる機能を持つプリントユニット２０６と、印字された記録紙をソート、ステイプルして機外へ出力する機能を持つ排紙ユニット２０７とで構成される。

制御装置２１０は、リーダー部２０１、プリンタ部２０４と電気的に接続され、さらにネットワーク２２０を介して、クライアントＰＣ１０４と接続されている。制御装置２１０はＣＰＵを備え、ＣＰＵは、ハードディスク２６０やＲＯＭ等の記憶部に記憶されたプログラムを実行することによって、リーダー部２１０やプリンタ部２０４を制御する。これにより制御装置２１０は、以下の機能を提供する。まず、制御装置２１０は、リーダー部２０１を制御して、原稿の画像データを読込み、ハードディスク２６０に画像データを格納し、プリンタ部２０４を制御して画像データを記録用紙に出力してコピー機能を提供する。また、リーダー部２０１から読み取った画像データを、コードデータに変換し、ネットワーク２２０を介してクライアントＰＣ１０４へ送信するスキャナ機能を提供する。また、クライアントＰＣ１０４からネットワーク２２０を介して受信したコードデータ（印刷データ）を画像データに変換し、プリンタ部２０４に出力するプリンタ機能を提供する。

操作部２５０は、制御装置２１０に接続され、液晶タッチパネルで構成され、画像入出力システムを操作するためのユーザＩ／Ｆを提供する。

尚、図２の画像形成装置１０５（デバイス）は、プリンタ機能、スキャナ機能、コピー機能を備えるＭＦＰ（Ｍｕｌｔｉ Ｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）を例に説明した。しかし、本実施例における画像形成装置（デバイス）は、ＭＦＰに限らず、プリンタやスキャナ、コピー機、ファクシミリ装置等の画像形成装置であってもよい。

図３はＤＰ１０２、クライアントＰＣ１０４のハードウェア構成を示すブロック図である。尚、ＤＰ１０２、クライアントＰＣ１０４は汎用のＰＣ（パーソナルコンピュータ）を使用可能であり、以下の説明は共通である。ＤＰ１０１，ＤＰ１０３も同様の構成である。

図３において、３０１はＣＰＵであり、システムバス３０４に接続された各種デバイスの制御を行う。３０２はＢＩＯＳやブートプログラムを記憶するＲＯＭ、３０３はＣＰＵ３０１の主記憶装置として使用されるＲＡＭである。３０５はキーボードコントローラ（ＫＢＣ）であり、マウス（登録商標）等のポインティングデバイス３０９ａ、キーボード３０９ｂからの情報などの入力に係る処理を行う。３０６は表示制御部（ＣＲＴＣ）であり、内部にビデオメモリを有し、ＣＰＵ３０１からの指示に従ってそのビデオメモリに描画すると共に、ビデオメモリに描画されたイメージデータをビデオ信号としてＣＲＴ表示装置３１０に出力する。なお、図３において表示装置としてＣＲＴを例示しているが、液晶表示装置等、その表示装置の種類は問わない。３０７はディスクコントローラ（ＤＫＣ）であり、ハードディスク３１１、フロッピー（登録商標）ディスク３１２へのアクセスを行う。３０８はネットワークインタフェースカード（ＮＩＣ）であって、ネットワークに接続し、ネットワークを介しての情報通信を行うものである。なお、ハードディスク３１１には、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）やＯＳ上で動作する各種アプリケーションプログラム等が格納される。

上記構成において、本装置の電源がＯＮになると、ＣＰＵ３０１はＲＯＭ３０２に格納されたブートプログラムに従って、ハードディスク３１１からＯＳをＲＡＭ３０３に読み込み、情報処理装置として機能するようになる。

図４はＤＰ１０３の表示装置に表示される画面の例である。本実施例において、各ＤＰは、クライアントＰＣから受信した検索要求を、他のＤＰに転送する機能を備える。図４に示す画面は、ＤＰ１０３が検索要求を転送する転送先となるＤＰをユーザが登録するための画面である。４０１の領域は、登録するＤＰにＩＰアドレスが入力される領域である。ユーザは、キーボード等を用いて所望のＤＰのＩＰアドレスを４０１の領域に入力する。そして、４０２に示す登録ボタンを押下すると、４０１に入力されたＩＰアドレスが、検索要求を転送する転送先となるＤＰとして登録される。登録されたＤＰは、４０３の領域に表示される。図４の例では、既にＤＰ１０２が登録されている場合を示している。４０３の領域には、登録されているＤＰの名称やＩＰアドレス、そしてＤＰを示すアイコンが表示されている。表示される情報はこれ以外の情報であってもよい。

ユーザは、図４の画面を用いて、ＤＰ１０３に対して複数のＤＰを登録してもよい。その場合、４０３の領域には、複数のＤＰが表示されることになる。ボタン４０４と４０５は、複数のＤＰが登録された場合に押下することができるようになるボタンである。登録された複数のＤＰのうちの何れかが選択された状態で、４０４のボタン（上矢印のボタン）が押下された場合には、選択されたＤＰの表示順が１つ上に移動する。逆に４０５のボタン（下矢印のボタン）が押下された場合には、選択されたＤＰの表示順が１つ下に移動する。ＤＰ１０３に複数のＤＰが登録されている場合には、ＤＰ１０３は、４０３の領域に表示された表示順に従って、検索要求の転送の順番を決める。即ち、４０３の領域の上位に表示されているＤＰから順に検索要求を転送する。

図５は、ＤＰ１０３、クライアントＰＣ１０９、画像形成装置１０５のソフトウェアモジュールを示すブロック図である。図５に示す各ソフトウェアモジュールは、各装置が備えるＣＰＵによって実行される。

ＤＰ１０３において、デバイス情報通知受信部５１１は画像形成装置１０５から送信されるＨｅｌｌｏメッセージ又はＢｙｅメッセージを受信する。Ｈｅｌｌｏメッセージ及びＢｙｅメッセージの詳細については後述する。そして、デバイス情報通知受信部５１１は、受信したメッセージの種類に基づき、デバイス情報保持部５１４が保持するデバイス情報の処理を行う。例えば、Ｈｅｌｌｏメッセージであった場合には、デバイス情報の取得が必要であると判断する。その場合、デバイス情報取得部５１２はＨｅｌｌｏメッセージを送信した画像形成装置１０５に対してデバイス情報取得要求を送信し、応答されたデバイス情報をデバイス情報保持部５１４に保持する。一方、Ｂｙｅメッセージであった場合には、デバイス情報保持部５１４に保持されたデバイス情報の削除が必要であると判断する。その場合、デバイス情報保持部５１４は、Ｂｙｅメッセージを送信した画像形成装置１０５のデバイス情報を、削除する。

デバイス情報検索処理部５１３はクライアントＰＣ１０９または他のＤＰから送信される検索要求を受信する。検索要求には、検索条件が含まれている。デバイス情報検索処理部５１３は、検索条件を満たすデバイス情報を、デバイス情報保持部５１４によって保持されたデバイス情報の中から検索する。そして、検索結果をクライアントＰＣ１０９に送信する。尚、クライアントＰＣ１０９から送信される検索要求はマルチキャストによって送信される。一方、他のＤＰから送信される検索要求はユニキャストによって送信される。検索要求転送部５１５は、受信した検索要求を一部書き換え、他のＤＰに送信する。また、デバイス情報保持部５１４が保持するデバイス情報の詳細については後述する。

クライアントＰＣ１０９において、デバイス検索要求処理部５２３は、デバイスを検索するための検索要求をマルチキャストで送信する。その後、ＤＰから送信された検索結果を受信すると、検索情報表示部５２４によって、検索結果が表示装置に表示される。

画像形成装置１０５において、デバイス情報管理部５３４は画像形成装置１０５自身のデバイス情報を管理する。デバイス情報通知部５３３はＨｅｌｌｏメッセージ又はＢｙｅメッセージを送信する。デバイス情報送信部５３５はネットワークを介してデバイス情報取得要求を受信した場合に、デバイス情報管理部５３４が管理しているデバイス情報をデバイス情報取得要求の送信元に送信する。デバイス検索処理部５３６は、マルチキャストによって送信された検索要求を受信した場合に、検索応答を送信する。

図６はＤＰ１０３のデバイス情報保持部５１４によって保持されるデバイス情報の例である。このデバイス情報は、ＤＰ１０３が有するＲＯＭ３０２又はＨＤ３１１等の記憶部に記憶される。図６の例では、ＤＰ１０３のデバイス情報保持部５１４によって、画像形成装置１０５、１１０のデバイス情報が保持されている場合を示している。

ＩＤ６０１はＤＰ１０３内でデバイス情報を識別するためのＩＤを示す。ＵＵＩＤ６０２はデバイスをグローバルに識別するＵＵＩＤを示す。バージョン６０３はデバイス情報のバージョンを示す。デバイスタイプ６０４は複合機を意味する「ＭＦＰ」、プリンタを意味する「Ｐｒｉｎｔｅｒ」などのデバイスの種類を示す。モデル名６０５は「ＬＢＰＸＸＸＸ」のようなデバイスのモデル名を示す。デバイス名６０６は管理者（ユーザ）がデバイスに設定した名前を示す。ＵＲＬ６０７はデバイス情報を取得するためのＵＲＬを示す。

次に、画像形成装置１０５のデバイス情報をＤＰ１０３に登録する方法について説明する。登録方法には２通りあり、まず第一の方法について説明する。

画像形成装置１０５は、画像形成装置が起動した場合や自機の設定情報が変更された場合に図７のようなＨｅｌｌｏメッセージを送信する。本実施例においてＨｅｌｌｏメッセージはＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）によって記述されるが、ＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）等その他のマークアップ言語によって記述されてもよい。これは、以下のＸＭＬ形式で記述されるその他のメッセージについても同様である。

図７のＨｅｌｌｏメッセージは、＜Ｈｅａｄｅｒ＞タグで囲まれるｈｅａｄｅｒ部７０１と＜Ｂｏｄｙ＞タグで囲まれるｂｏｄｙ部７０２からなり、全体が＜Ｅｎｖｅｌｏｐｅ＞タグで囲まれる構造になっている。この構造は本実施例において使用するメッセージすべてに共通である。

ｈｅａｄｅｒ部７０１はメッセージの内容に依存しない共通ヘッダとしての役割を果たしており、＜Ａｃｔｉｏｎ＞タグ、＜ＭｅｓｓａｇｅＩＤ＞タグ、＜Ｔｏ＞タグが存在する。＜Ａｃｔｉｏｎ＞タグはメッセージの種類を識別するためのものである。＜ＭｅｓｓａｇｅＩＤ＞タグはメッセージを一意に識別するための識別子である。＜Ｔｏ＞タグはこのメッセージの送信先を識別するためのものである。一方、ｂｏｄｙ部７０２はメッセージの内容に対応して構造が変化する。図７においては、＜Ｂｏｄｙ＞タグの直下に＜Ｈｅｌｌｏ＞タグが存在し、このメッセージがＨｅｌｌｏメッセージであることを示している。＜Ｈｅｌｌｏ＞タグの中には＜ＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅ＞タグ、＜Ｔｙｐｅｓ＞タグ、＜ＸＡｄｄｒｓ＞タグ、＜ＭｅｔａｄａｔａＶｅｒｓｉｏｎ＞タグが存在する。＜ＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅ＞タグの中には＜Ａｄｄｒｅｓｓ＞タグが存在し、デバイスを識別するアドレス情報を持つ。＜Ｔｙｐｅｓ＞タグはデバイスのタイプ情報を持つ。＜ＸＡｄｄｒｓ＞タグはデバイス情報を取得するためのＵＲＬを持つ。＜ＭｅｔａｄａｔａＶｅｒｓｉｏｎ＞タグはデバイス情報のバージョンを持つ。

ＤＰ１０３はＨｅｌｌｏメッセージを受信する。そして、Ｈｅｌｌｏメッセージの中からデバイスをグローバルに識別するＵＵＩＤとしてＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅ／Ａｄｄｒｅｓｓタグの値、デバイスタイプとしてＴｙｐｅｓタグの値を抽出する。また、デバイス情報のバージョンとしてＭｅｔａｄａｔａＶｅｒｓｉｏｎタグの値、デバイス情報を取得するためのＵＲＬとしてＸＡｄｄｒｓタグの値を抽出する。そして、抽出した値を、デバイス情報保持部５１４は記憶部に格納する。

その後ＤＰ１０３はＸＡｄｄｒｓタグで記載されたＵＲＬに対し、図８のようなＸＭＬ形式のＧｅｔメッセージをユニキャストで送信する。図８のＧｅｔメッセージは、ｈｅａｄｅｒ部のみを持つメッセージとなっている。ｈｅａｄｅｒ部の＜Ａｃｔｉｏｎ＞タグにおいて、このメッセージがＧｅｔメッセージであることを示している。

画像形成装置１０５のデバイス情報送信部５３５は、ＤＰ１０３から送信されたＧｅｔメッセージを受信すると、図９のようなＸＭＬ形式のＧｅｔＲｅｓｐｏｎｓｅメッセージを送信する。これによって、画像形成装置１０５の更に詳細なデバイス情報がＤＰ１０３に送信されることになる。

図９のＧｅｔＲｅｓｐｏｎｓｅメッセージにおいては、ｂｏｄｙ部に＜Ｍｅｔａｄａｔａ＞タグで示されるデバイス情報を持つ構造となっている。＜Ｍｅｔａｄａｔａ＞タグの中には＜ＭｅｔａｄａｔａＳｅｃｔｉｏｎ＞タグで示されるＭｅｔａｄａｔａＳｅｃｔｉｏｎ部９０１、９０２、９０３が存在する。各ＭｅｔａｄａｔａＳｅｃｔｉｏｎ部は直下のタグにより、その中に持つ情報の種類が指定される。ＭｅｔａｄａｔａＳｅｃｔｉｏｎ部９０１は＜ＴｈｉｓＤｅｖｉｃｅ＞タグを持っており、デバイスごとに異なる情報が格納される。＜ＦｒｉｅｎｄｌｙＮａｍｅ＞タグはこのデバイスにつけた名前、＜ＦｉｒｍｗａｒｅＶｅｒｓｉｏｎ＞タグはこのデバイスのファームウェアバージョン、＜ＳｅｒｉａｌＮｕｍｂｅｒ＞タグはこのデバイスのシリアル番号を示している。ＭｅｔａｄａｔａＳｅｃｔｉｏｎ部９０２は＜ＴｈｉｓＭｏｄｅｌ＞タグを持っており、デバイスのモデルごとに異なる情報が格納される。＜Ｍａｎｕｆａｃｔｕｒｅｒ＞タグはデバイスの製造会社名、＜Ｍａｎｕｆａｃｔｕｒｅｒ＞タグはデバイス製造会社のＵＲＬ、＜ＰｒｅｓｅｎｔａｔｉｏｎＵＲＬ＞はデバイスの情報を示すＵＲＬ、＜ＭｏｄｅｌＮａｍｅ＞タグはデバイスのモデル名を示している。ＭｅｔａｄａｔａＳｅｃｔｉｏｎ部９０３は＜Ｒｅｌａｔｉｏｎｓｈｉｐ＞タグを持っており、デバイスが持つ内部サービスの情報が格納される。本実施例においては、内部サービスとは画像形成装置が提供するプリントサービスである。＜Ｒｅｌａｔｉｏｎｓｈｉｐ＞タグはさらにその直下に＜Ｈｏｓｔｅｄ＞タグを持ち、その中に＜ＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅ＞タグ、＜Ｔｙｐｅｓ＞タグ、＜ＳｅｒｖｉｃｅＩｄ＞タグが存在する。＜ＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅ＞タグの中には＜Ａｄｄｒｅｓｓ＞タグが存在し、サービスを利用するためのアドレス情報を持つ。＜Ｔｙｐｅｓ＞タグはサービスのタイプ情報を持つ。＜ＳｅｒｖｉｃｅＩｄ＞タグはデバイス内でサービスを識別するための識別子を持つ。

ＤＰ１０３は受信したＧｅｔＲｅｓｐｏｎｓｅメッセージの中からデバイス名としてＦｒｉｅｎｄｌｙＮａｍｅタグの値、モデル名としてＭｏｄｅｌＮａｍｅタグの値を抽出する。そして、抽出した値を、デバイス情報保持部５１４は記憶部に格納する。

なお、画像形成装置１０５は、画像形成装置が起動した場合や自機の設定情報が変更された場合にＨｅｌｌｏメッセージをＤＰ１０３に送信する。ＤＰ１０３はＨｅｌｌｏメッセージを受信するたびに上記のようにデバイス情報を取得してもよい。しかし、以前に取得したデバイス情報がデバイス情報保持部５１４に存在している場合には、Ｈｅｌｌｏメッセージに含まれるＭｅｔａｄａｔａのバージョン情報を比較し、変更がなければ、新たにデバイス情報を取得しなおさなくてもよい。

次に第二の登録方法について説明する。

ＤＰ１０３は所定のタイミングで、図１１のようなＸＭＬ形式のＰｒｏｂｅメッセージをマルチキャストで送信する。Ｐｒｏｂｅメッセージは、本実施例において、検索要求の一例である。図１１のＰｒｏｂｅメッセージにおいては、ｂｏｄｙ部に＜Ｐｒｏｂｅ＞タグが存在し、このメッセージがＰｒｏｂｅメッセージであることを示している。＜Ｐｒｏｂｅ＞タグの中には＜Ｔｙｐｅｓ＞タグが設定可能であり、＜Ｔｙｐｅｓ＞タグは検索したいデバイスのタイプを指定するものである。つまり、＜Ｔｙｐｅｓ＞タグに記述される情報は、本実施例における検索条件である。図１１の例ではＴｙｐｅｓとしては空とし、すべてのデバイスを検索対象としている。

画像形成装置１０５はＰｒｏｂｅメッセージを受信すると、図１２のようなＸＭＬ形式のＰｒｏｂｅＭａｔｃｈメッセージをＤＰ１０３に送信する。本実施例においてＰｒｏｂｅＭａｔｃｈメッセージは検索結果を示す情報の一例である。図１２のＰｒｏｂｅＭａｔｃｈメッセージにおいては、ｂｏｄｙ部に＜ＰｒｏｂｅＭａｔｃｈｅｓ＞タグが存在し、このメッセージがＰｒｏｂｅＭａｔｃｈメッセージであることを示している。＜ＰｒｏｂｅＭａｔｃｈｅｓ＞タグの中には＜ＰｒｏｂｅＭａｔｃｈ＞タグで示されるＰｒｏｂｅＭａｔｃｈ部が存在する。それぞれのＰｒｏｂｅＭａｔｃｈ部が検索結果に対応している。つまり、ＰｒｏｂｅＭａｔｃｈ部に含まれる情報が、検索条件を満たしたデバイス情報である。図１２の例においては１個の検索結果が返されていることを示している。ＰｒｏｂｅＭａｔｃｈ部の中の構造は図７のＨｅｌｌｏメッセージにおける＜Ｈｅｌｌｏ＞タグの中と同一である。

ＤＰ１０３はＰｒｏｂｅＭａｔｃｈメッセージを受信する。そして、ＰｒｏｂｅＭａｔｃｈメッセージの中からデバイスをグローバルに識別するＵＵＩＤとしてＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅ／Ａｄｄｒｅｓｓタグの値、デバイスタイプとしてＴｙｐｅｓタグの値を抽出する。また、デバイス情報のバージョンとしてＭｅｔａｄａｔａＶｅｒｓｉｏｎタグの値、デバイス情報を取得するためのＵＲＬとしてＸＡｄｄｒｓタグの値を抽出する。そして、抽出した値を、デバイス情報保持部５１４は記憶部に格納する。

その後ＤＰ１０３はＸＡｄｄｒｓタグで記載されたＵＲＬに対し、図８のようなＸＭＬ形式のＧｅｔメッセージをユニキャストで送信する。画像形成装置１０５のデバイス情報送信部５３５は図９のようなＧｅｔＲｅｓｐｏｎｓｅメッセージを送信する。ＤＰ１０３は受信したＧｅｔＲｅｓｐｏｎｓｅメッセージから、デバイス名としてＦｒｉｅｎｄｌｙＮａｍｅタグの値、モデル名としてＭｏｄｅｌＮａｍｅタグの値を抽出する。そして、抽出した値を、デバイス情報保持部５１４は記憶部に格納する。

なお、ＤＰ１０３は所定のタイミングでＰｒｏｂｅメッセージを送信し、その結果、デバイス情報を画像形成装置１０５から取得する。しかし、以前に取得したデバイス情報がデバイス情報保持部５１４に存在している場合には、ＰｒｏｂｅＭａｔｃｈメッセージに含まれるＭｅｔａｄａｔａのバージョン情報を比較し、変更がなければ、新たにデバイス情報を取得しなおさなくてもよい。

次にＤＰ１０３に登録されたデバイス情報を削除する方法について説明する。画像形成装置１０５は、自機がシャットダウンする場合など、ネットワークに存在するクライアントＰＣに対してサービスの提供を停止する場合には、図１０のようなＸＭＬ形式のＢｙｅメッセージをマルチキャストで送信する。

図１０のＢｙｅメッセージにおいては、ｂｏｄｙ部に＜Ｂｙｅ＞タグが存在し、このメッセージがＢｙｅメッセージであることを示している。＜Ｂｙｅ＞タグの中には＜ＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅ＞タグが存在する。＜ＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅ＞タグの中には＜Ａｄｄｒｅｓｓ＞タグが存在し、デバイスを識別するアドレス情報を持つ。ＤＰ１０３はＢｙｅメッセージを受信すると、Ｂｙｅメッセージに含まれるＵＵＩＤ情報を抽出する。そして、デバイス情報保持部５１４は、抽出したＵＵＩＤ情報に対応するデバイス情報を記憶部から削除する。

次に、クライアントＰＣ１０９がＤＰ１０３を使用して画像形成装置を検索する方法について説明する。

クライアントＰＣ１０４は、図１４のようなＸＭＬ形式のＰｒｏｂｅメッセージをマルチキャストで送信する。Ｐｒｏｂｅメッセージは、本実施例において、検索要求の一例である。図１４のＰｒｏｂｅメッセージにおいては、ｂｏｄｙ部に＜Ｐｒｏｂｅ＞タグが存在し、このメッセージがＰｒｏｂｅメッセージであることを示している。＜Ｐｒｏｂｅ＞タグの中には＜Ｔｙｐｅｓ＞タグが設定可能であり、＜Ｔｙｐｅｓ＞タグは検索したいデバイスのタイプを指定するものである。つまり、＜Ｔｙｐｅｓ＞タグに記述される情報は、本実施例における検索条件である。図１４の例では、画像形成装置を検索する検索条件の一例として、Ｔｙｐｅｓタグにおいて「Ｐｒｉｎｔｅｒ」を指定している。即ち、デバイスの種類がＰｒｉｎｔｅｒである画像形成装置が、検索条件を満たすデバイスとして検索されることになる。

ＤＰ１０３はＰｒｏｂｅメッセージを受信すると、Ｔｙｐｅｓタグを抽出しデバイス情報保持部５１４によって保持されたデバイス情報の中から検索条件に合致するデバイスを検索する。そして、図１５のようなＸＭＬ形式のＰｒｏｂｅＭａｔｃｈメッセージをクライアントＰＣ１０９に送信する。図１５のＰｒｏｂｅＭａｔｃｈメッセージにおいては、ｂｏｄｙ部に＜ＰｒｏｂｅＭａｔｃｈｅｓ＞タグが存在し、このメッセージがＰｒｏｂｅＭａｔｃｈメッセージであることを示している。＜ＰｒｏｂｅＭａｔｃｈｅｓ＞タグの中には＜ＰｒｏｂｅＭａｔｃｈ＞タグで示されるＰｒｏｂｅＭａｔｃｈ部１５０１、１５０２が存在する。それぞれのＰｒｏｂｅＭａｔｃｈ部が１個の検索結果に対応しており、図１５の例においては２個の検索結果が返されていることを示している。即ち、検索条件であった「デバイスの種類がＰｒｉｎｔｅｒ」を満たす画像形成装置が、２つ検索されたことを示している。ＰｒｏｂｅＭａｔｃｈ部の中の構造は図７のＨｅｌｌｏメッセージにおける＜Ｈｅｌｌｏ＞タグの中と同一である。

その後、ＤＰ１０３は、受信したＰｒｏｂｅメッセージを図１６のように書き換える。そして、図４で説明した登録方法によって登録されてたＤＰ１０２に、書き換えられたＰｒｏｂｅメッセージをユニキャストで送信する。尚、図１６のＲｅｐｌｙＴｏタグには、ＰｒｏｂｅメッセージをＤＰ１０３に送信した送信元のクライアントＰＣ１０９のアドレスが設定されている。

ＤＰ１０２はＤＰ１０３からＰｒｏｂｅメッセージを受信すると、Ｔｙｐｅｓタグを抽出しＤＰ１０２のデバイス情報保持部５１４によって保持されたデバイス情報の中から、検索条件に合致するデバイスを探し、ＰｒｏｂｅＭａｔｃｈメッセージを生成する。そして、ＤＰ１０３から受信したＰｒｏｂｅメッセージに含まれるＲｅｐｌｙＴｏタグを抽出する。ＤＰ１０２は、生成したＰｒｏｂｅＭａｔｃｈメッセージを、抽出したＲｅｐｌｙＴｏの宛先であるクライアントＰＣ１０９に対して送信する。

その結果、クライアントＰＣ１０９は、ＤＰ１０３から、サブネット３に存在する画像形成装置を検索した検索結果を受信すると共に、ＤＰ１０２から、サブネット２に存在する画像形成装置を検索した検索結果を受信することができる。

その後、必要に応じて、クライアントＰＣ１０９は、検索された画像形成装置に対してＧｅｔメッセージを送信して、より詳細なデバイス情報を取得することができる。

図１３はクライアントＰＣ１０９の表示装置に表示される画面の例である。図１３に示す画面は、クライアントＰＣ１０９が画像形成装置を検索する際に表示される画面の例である。

図１３において、領域１３０１は、ユーザが検索条件を入力するための領域である。本実施例では、検索するデバイスの種類を指定する。即ち、「ＭＦＰ」「Ｐｒｉｎｔｅｒ」などのキーワードが指定可能である。入力方法は、キーボード等を用いてユーザが直接入力してもよいし、プルダウンメニューを表示し、予め決められている候補のなかからどれかをユーザが選択するようにしてもよい。領域１３０１に何も入力しない場合はすべての画像形成装置が検索される。ボタン１３０２を押下すると検索要求が送信される。即ち、上述したＰｒｏｂｅメッセージがマルチキャストによって送信される。検索された結果は領域１３０３に表示される。具体的には、検索結果としてのＰｒｏｂｅＭａｔｃｈメッセージを受信すると、デバイスのタイプやモデル名、デバイス名が同時に表示される。図１３の例では、２つの画像形成装置が検索された場合の例を示している。

次に、画像形成装置を検索する際のＤＰの処理内容についてフローチャートを用いて説明する。図１７は、ＤＰにおいて実行される画像形成装置の検索処理を示すフローチャートである。図１７のフローチャートは、ＤＰ１０１，１０２，１０３の何れのＤＰにおいても実行される。図１７の各ステップは、ＤＰが備えるＣＰＵ３０１が、ＲＯＭ３０２やＨＤ３１１に格納されたプログラムを実行することによって処理される。

ステップＳ１７０１において、ＤＰは、ネットワークを介して送信されたＰｒｏｂｅメッセージを受信する。ステップＳ１７０２において、デバイス検索処理部５１３は、受信した受信したＰｒｏｂｅメッセージに含まれるＴｙｐｅｓタグを抽出する。即ち、検索要求に含まれる検索条件を抽出する。ステップＳ１７０３において、デバイス検索処理部５１３は、抽出した検索条件を満たすデバイス情報を、デバイス情報保持部５１４によって保持されたデバイス情報の中から検索する。具体的には、ステップＳ１７０２において抽出されたＴｙｐｅｓタグの情報（デバイスの種類を示す情報）に合致する情報を含むデバイス情報が、デバイス情報保持部５１４によって保持されたデバイス情報の中にあるか否かを判断する。ステップＳ１７０３における判断の結果、条件に合致するデバイス情報が見つかった場合にはステップＳ１７０４へと進む。一方、条件に合致するデバイス情報が見つからなかった場合には、ステップＳ１７０７へと進む。尚、Ｔｙｐｅｓタグが抽出されなかった場合には、デバイス情報保持部５１４によって保持された全てのデバイス情報が検索条件に合致したデバイス情報となる。

ステップＳ１７０４において、デバイス検索処理部５１３は、受信したＰｒｏｂｅメッセージにＲｅｐｌｙＴｏタグが含まれているか否かを判断する。判断の結果、ＲｅｐｌｙＴｏタグが含まれている場合には、ステップＳ１７０５へと進む。一方、ＲｅｐｌｙＴｏタグが含まれていない場合には、ステップＳ１７０７へと進む。ステップＳ１７０５において、デバイス検索処理部５１３は、Ｐｒｏｂｅメッセージに対する応答であるＰｒｏｂｅＭａｔｃｈメッセージを生成する。ＰｒｏｂｅＭａｔｃｈメッセージには、検索条件を満たすデバイス情報が含まれている。ここで、デバイス検索処理部５１３は、ＰｒｏｂｅＭａｔｃｈメッセージの送信先を、Ｐｒｏｂｅメッセージの送信元である装置ではなく、ＲｅｐｌｙＴｏタグに記述された宛先に設定する。ステップＳ１７０６において、デバイス検索処理部５１３は、生成したＰｒｏｂｅＭａｔｃｈメッセージをユニキャストによって送信する。ステップＳ１７０５において宛先が設定されていない場合（ステップＳ１７０４においてＮｏの場合）には、ＰｒｏｂｅＭａｔｃｈメッセージの送信先は、Ｐｒｏｂｅメッセージを送信した送信元になる。

ステップＳ１７０７において、デバイス検索処理部５１３は、自装置に検索要求の転送先として他のＤＰが登録されているか否かを判断する。他のＤＰの登録は、前述した図４の方法によって行われる。他のＤＰが登録されていると判断された場合には、ステップＳ１７０８へと進む。一方、他のＤＰが登録されていないと判断された場合には、処理を終了する。

ステップＳ１７０８において、検索要求転送部５１５は、自装置に登録されている他のＤＰに対して、Ｐｒｏｂｅメッセージを転送するために、転送用のＰｒｏｂｅメッセージを生成する。具体的には、ＰｒｏｂｅメッセージにＲｅｐｌｙＴｏタグを追加する。ＲｅｐｌｙＴｏタグには、Ｐｒｏｂｅメッセージの送信元の装置（この場合は、クライアントＰＣ）のアドレスが設定される。尚、既にＰｒｏｂｅメッセージにＲｅｐｌｙＴｏタグが含まれていた場合には、転送用の新たなＰｒｏｂｅメッセージを生成することはない。ステップＳ１７０９において、検索要求転送部５１５は、生成した転送用のＰｒｏｂｅメッセージ（又はステップＳ１７０１で受信したＰｒｏｂｅメッセージ）を、登録されている他のＤＰに対してユニキャストで送信する。もし、複数の他のＤＰが登録されていた場合には、これら複数の他のＤＰに対してＰｒｏｂｅメッセージが送信される。

次に、ＤＰの検索要求転送部５１５が、検索要求を他のＤＰに転送する際の条件について説明する。

図１７の例では、もしＤＰに検索要求の転送先となる他のＤＰが登録されていれば、無条件にその登録されている他のＤＰに対して検索要求を転送していた。そのため、転送先の他のＤＰにおいて、転送先となるまた別のＤＰが登録されていれば、検索要求が次々と転送され続けることになる。従って、１つの検索要求が、制限なく次々と転送され続けてしまう可能性がある。

このような状況を防ぐ為に、本実施例では、ＤＰの検索要求転送部５１５が検索要求を他のＤＰに転送する際の条件を、検索要求転送部５１５に設定する。以下、そのいくつかの方法について具体的に説明する。

ＤＰの検索要求転送部５１５が、検索要求を他のＤＰに転送する第１の方法は、検索要求を受信したＤＰが存在するサブネットよりも上位の階層（又は下位の階層）に存在するＤＰのみに検索要求を転送する方法である。

本実施例におけるシステムは、図１に示すように複数のサブネットによって構成されている。第１の方法においては、これら複数のサブネットそれぞれについて階層構造が設定されているとする。ここでは、図１におけるサブネット２の上位階層のサブネットとしてサブネット１が設定されており、サブネット３の上位階層のサブネットとしてサブネット１が設定されているとする。そして、サブネット２とサブネット３とは、同じ階層とする。そして、各サブネットに存在するＤＰには、各サブネットの階層関係が予め登録されている。

第１の方法について、このように設定された図１の例を元に説明する。まず、クライアントＰＣ１０９は、Ｐｒｏｂｅメッセージをマルチキャストで送信する。図１８は、クライアントＰＣ１０９が送信するＰｒｏｂｅメッセージの例である。図１８のＰｒｏｂｅメッセージは、Ｃｏｎｄｉｔｉｏｎタグを含み、Ｃｏｎｄｉｔｉｏｎタグには「ＵｐｐｅｒＬａｙｅｒ」が指定されている。Ｃｏｎｄｉｔｉｏｎタグは、検索要求転送部がＰｒｏｂｅメッセージを転送する際の転送条件を示している。図１８の例では、上位階層に存在するＤＰに対してのみＰｒｏｂｅメッセージを転送するように指定されている。

ＤＰ１０３は、図１８に示すＰｒｏｂｅメッセージを受信する。すると、ＤＰ１０３の検索要求転送部５１５は、Ｃｏｎｄｉｔｉｏｎタグを参照し、自身が存在するサブネットよりも上位の階層のサブネットに存在するＤＰに対してＰｒｏｂｅメッセージを転送すべきであることを認識する。そして、予め検索要求転送部５１５に設定されている情報を参照して、自身の上位の階層のサブネットがサブネット１であることを認識する。そして、図４の方法に従って、予め転送先のＤＰとして登録されているＤＰの中から、上位の階層のサブネットであるサブネット１に存在するＤＰを抽出する。例えば、ＤＰ１０１とＤＰ１０２が登録されていた場合には、サブネット１に存在するＤＰ１０１が抽出されることになる。そして、ＤＰ１０３の検索要求転送部５１５は、サブネット１に存在するＤＰ１０１に対して、Ｐｒｏｂｅメッセージを転送する。この時、図１７のＳ１７０８で説明したように、検索要求転送部５１５は、転送用のＰｒｏｂｅメッセージ即ちＲｅｐｌｙＴｏタグにクライアントＰＣ１０９のアドレス（１９２．１６８．０．１００）を設定したＰｒｏｂｅメッセージを生成し、送信する。

以上説明したように、第１の方法によれば、クライアントＰＣから送信されたＰｒｏｂｅメッセージが制限なく次々とＤＰに転送されつづけてしまうことを防ぐことができる。

ＤＰの検索要求転送部５１５が、検索要求を他のＤＰに転送する第２の方法は、指定された回数に従って、検索要求を転送する方法である。

第２の方法の具体例を、図１のシステムに基づいて説明する。クライアントＰＣ１０９は、図１９に示すＰｒｏｂｅメッセージをマルチキャストで送信する。図１９のＰｒｏｂｅメッセージは、Ｔｔｌタグを含み、Ｔｔｌタグには、「１」が指定されている。Ｔｔｌタグは、Ｐｒｏｂｅメッセージの転送回数の制限値を示す値である。１であれば、１回のみ転送可能であることを示している。１０であれば、１０回転送可能であることを示している。即ち、Ｔｔｌタグに「１」が指定されているＰｒｏｂｅメッセージは、１つのサブネットに１つのＤＰが存在するシステムであれば、最高で２つのＤＰに送信されることになる。

ＤＰ１０３は、図１９に示すＰｒｏｂｅメッセージを受信する。そして、ＤＰ１０３の検索要求転送部は、Ｐｒｏｂｅメッセージに含まれるＴｔｌタグを参照し、その値が「１」であることを認識する。そして、転送先の他のＤＰが登録されているか否かを判断する。登録されている場合には、検索要求転送部５１５は、転送用のＰｒｏｂｅメッセージを生成する。図２０は、検索要求転送部５１５によって生成された転送用のＰｒｏｂｅメッセージの例である。図１９のＰｒｏｂｅメッセージと異なり、まず、ＲｅｐｌｙＴｏタグが付加されている。ＲｅｐｌｙＴｏには、Ｐｒｏｂｅメッセージの送信元であるクライアントＰＣ１０９のアドレス（１９２．１６８．０．１００）が設定されている。また、Ｔｔｌタグの値が、「０」に設定されている。即ち、検索要求転送部５１５は、受信したＰｒｏｂｅメッセージのＴｔｌの値から、１を引いた値をＴｔｌの値として設定する。尚、ＤＰ１０３に複数の転送先のＤＰが登録されており、複数の転送先のＤＰにＰｒｏｂｅメッセージを転送する場合には、その数だけＴｔｌの値を引くことになる。また、複数の転送先のＤＰが登録されているにも関わらず、受信したＰｒｏｂｅメッセージのＴｔｌの値が１であった場合には、最も優先順位の高い１つの転送先のＤＰを選択し、そのＤＰのみにＰｒｏｂｅメッセージを転送する。ここで、優先順位は、図４によって説明したように、図４の登録順序に従って決めることができる。

ＤＰ１０３の検索要求転送部５１５は、生成した転送用のＰｒｏｂｅメッセージを他のＤＰに送信する。その後、転送されたＰｒｏｂｅメッセージを受信したＤＰは、Ｐｒｏｂｅメッセージに含まれるＴｔｌの値が０であることを認識すると、それ以降Ｐｒｏｂｅメッセージを転送しないように制御される。

このように、第２の方法によれば、クライアントＰＣから送信されたＰｒｏｂｅメッセージが制限なく次々とＤＰに転送されつづけてしまうことを防ぐことができる。それだけでなく、いくつのＤＰに転送すべきかをＰｒｏｂｅメッセージにおいて指定することができる。

尚、上記第２の方法では、Ｔｔｌの値を、ＤＰの数としてカウントしていた。しかし、Ｔｔｌの値を、サブネットの数としてカウントしてもよい。即ち、Ｐｒｏｂｅメッセージを送信するにあたって通過するルータの数をカウントし、その値をＴｔｌから引くことによって、Ｔｔｌの値を計算してもよい。

ＤＰの検索要求転送部５１５が、検索要求を他のＤＰに転送する第３の方法は、既に転送済みのＤＰを通知し、まだ転送していないＤＰに対してのみ検索要求を転送していく方法である。

第３の方法の具体例を、図２１のフローチャートを用いて説明する。図２１は、クライアントＰＣからＰｒｏｂｅメッセージを受信するＤＰの動作を示すフローチャートであり、図１７と同じ処理に関しては同じ符号をつけてあり、詳細な説明は省略する。

図２１のフローチャートは、図１に示すシステムにおけるＤＰ１０２の処理を示すフローチャートである。尚、図１のクライアントＰＣ１０９から送信されたＰｒｏｂｅメッセージをＤＰ１０３が転送し、その転送されたＰｒｏｂｅメッセージをＤＰ１０２が受信した場合を例に説明する。ＤＰ１０２が受信したＰｒｏｂｅメッセージの例を図２２に示す。前提として、ＤＰ１０３には、転送先のＤＰとして、ＤＰ１０２（１９２．１６８．１．１０）が登録されているとする。また、ＤＰ１０２には、転送先のＤＰとして、ＤＰ１０１（１９２．１６８．２．１０）と、ＤＰ１０３（１９２．１６８．０．１０）が登録されているとする。転送先のＤＰの登録は、前述の図４の方法を用いて実行される。

図２２のＰｒｏｂｅメッセージには、ＤｐＬｉｓｔタグが含まれている。このＤｐＬｉｓｔタグは、既にＰｒｏｂｅメッセージを送信済みのＤＰを示している。図２２の例では、既にＤＰ１０３とＤＰ１０２に送信済みであることから、これら２つのＤＰそれぞれのアドレスが記述されている。

ＤＰ１０２は、ステップＳ１７０１において、図２２に示すＰｒｏｂｅメッセージをＤＰ１０３から受信する。ステップＳ１７０２からＳ１７０７までの処理は、図１７で説明したものと同じであるためここでは説明を省略する。

ステップＳ２１０１において、ＤＰ１０２の検索要求転送部５１５は、受信したＰｒｏｂｅメッセージにＤｐＬｉｓｔタグが含まれているか否かを判断する。含まれている場合にはステップＳ２１０２へと進み、含まれていない場合にはステップＳ２１０５へと進む。ステップＳ２１０２において、検索要求転送部５１５は、転送先のＤＰとして登録されているＤＰの中に、ＤｐＬｉｓｔに記述されていないＤＰがあるか否かを判断する。本例では、ＤＰ１０２には、転送先のＤＰとして、ＤＰ１０１（１９２．１６８．２．１０）と、ＤＰ１０３（１９２．１６８．０．１０）が登録されている。一方、受信したＰｒｏｂｅメッセージのＤｐＬｉｓｔには、ＤＰ１０２（１９２．１６８．１．１０）とＤＰ１０３（１９２．１６８．０．１０）が記述されている。これらを比較すると、ＤＰ１０１が、ＤｐＬｉｓｔに記述されていないことになる。

ステップＳ２１０３において、検索要求転送部５１５は、転送先のＤＰとして登録されているＤＰの中で、ＤｐＬｉｓｔに記述されていないＤＰを抽出し、そのアドレスをＤｐＬｉｓｔに記述する。図２１の例の場合、ＤＰ１０２は、ＤｐＬｉｓｔに記述されていないＤＰ１０１のアドレス（１９２．１６８．２．１０）をＤｐＬｉｓｔに追記する。そして、ステップＳ２１０４において、検索要求転送部５１５は、ステップＳ２１０３においてＤｐＬｉｓｔに追記したアドレスを、Ｐｒｏｂｅメッセージの送信先のアドレスとして設定する。図２１の例の場合にはＤＰ１０１のアドレス（１９２．１６８．２．１０）を、Ｐｒｏｂｅメッセージの送信先アドレスとして設定する。

ステップＳ１７０８は、図１７におけるステップＳ１７０８の処理と同様である。即ち、受信したＰｒｏｂｅメッセージに、ＲｅｐｌｙＴｏタグが含まれていなければ、ＲｅｐｌｙＴｏタグを追加し、Ｐｒｏｂｅメッセージの送信元のクライアントＰＣのアドレスをＲｅｐｌｙＴｏタグに記述する。図２２の例のように、既にＲｅｐｌｙＴｏタグがある場合には、ステップＳ１７０８の処理は省略される。ステップＳ１７０９において、検索要求転送部５１５は、生成したＰｒｏｂｅメッセージを送信する。

また、ステップＳ２１０５は、受信したＰｒｏｂｅメッセージに、ＤｐＬｉｓｔタグが含まれていない場合に行われる処理である。ステップＳ２１０５において、検索要求転送部５１５は、転送先のＤＰとして予め登録されている他のＤＰを、Ｐｒｏｂｅメッセージの送信先のアドレスとして設定する。

尚、ステップＳ２１０２では、検索要求転送部５１５は、自身のアドレスが、ＤｐＬｉｓｔに記述されているか否かも同時に判断される。図２１の例では、自身のアドレス（１９２．１６８．１．１０）がＤｐＬｉｓｔに記述されている。その場合には、改めて自身のアドレスをＤｐＬｉｓｔに記述することはしない。しかし、もし、自身のアドレスがＤｐＬｉｓｔに記述されていない場合には、検索要求転送部５１５は、ステップＳ２１０３において、自身のアドレスをＤｐＬｉｓｔに記述する。

このように、第３の方法によれば、クライアントＰＣから送信されたＰｒｏｂｅメッセージが制限なく次々とＤＰに転送されつづけてしまうことを防ぐことができる。それだけでなく、同じＤＰに対して同じＰｒｏｂｅメッセージが重複して送信されてしまうことがなくなる。

その他の方法として、Ｐｒｏｂｅメッセージの送信元のクライアントＰＣのＩＰアドレスを基準としてＰｒｏｂｅメッセージを転送するか否かを決める方法も考えられる。例えば、図１に示したシステムにおいて、ＩＰアドレスに応じて仮想的なグループを設定するＶＬＡＮ（Ｖｉｒｔｕａｌ ＬＡＮ）が利用されている環境が考えられる。このような環境において、例えば部門毎にＶＬＡＮを設けてネットワークを分割し、アクセス制限を行っている場合、他のＶＬＡＮに属するクライアントＰＣからの検索を行わせないように制御する必要がある。

そこで、ＤＰが検索要求を他のサブネットのＤＰへ転送する際に、クライアントＰＣのＩＰアドレスを基準として同一ＶＬＡＮに属しているＤＰに対しては検索要求を転送し、同一ＶＬＡＮに属していない場合は転送しないように制御する。また特定のＶＬＡＮに属しているクライアントＰＣからの検索要求のみ他のサブネットのＤＰへ転送を可能とする制御も可能である。

尚、ＶＬＡＮによって設定されるグループの単位は、適宜決めることができる。例えば、オフィス内の部門毎や建物毎や、フロア毎などにＶＬＡＮのグループを設定することができる。

また、ＤＰに、検索要求の転送先として複数の他のＤＰが登録されている場合、検索要求を転送する順序を制御することも可能である。例えば、検索要求の転送先ＤＰとして、ＤＰ−Ａ、ＤＰ−Ｂ、ＤＰ−Ｃの３つのＤＰがこの順序で登録されたＤＰ−Ｘが存在したとする。ＤＰ−Ｘは転送要求を転送先ＤＰの登録順序に従い、まずＤＰ−Ａへ転送、続いてＤＰ−Ｂへ転送、最後にＤＰ−Ｃへ転送といった制御を行う。こうした制御では、ＤＰ−Ｃがさらに転送先ＤＰを持ち、尚且つ転送先ＤＰの個数が多い場合、ＤＰ−Ｃにて多くの転送要求が発生して、全ての検索結果をクライアントＰＣが取得するまでには時間がかかってしまう。そこで、転送先ＤＰの登録順序を変更することを可能とする。これにより、転送先ＤＰを多く保持するＤＰは登録順序の上位へ変更することで、転送順序を早め、検索結果にかかる応答を少しでも早くすることが可能となる。

（その他の実施例）
上記実施例では、画像形成装置とＤＰとして動作する情報処理装置とをそれぞれ別の装置として説明したが、これらが１つの装置として提供されても良い。即ち、例えば図１の例において、ＤＰ１０２の機能を画像形成装置１０８が備えていてもよい。同様に、クライアントＰＣが上記実施例におけるＤＰの機能を備えていてもよい。又は、上記実施例における画像形成装置とクライアントＰＣが１つの装置によって提供されてもよい。

また、本発明は、前述した実施例のフローチャートを実現するソフトウェアのコンピュータプログラムコードを記録した記憶媒体を、システムあるいは装置に供給してもよい。そして、そのシステムあるいは装置のコンピュータ（ＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても達成され得る。

この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。

プログラムコードを供給するための記憶媒体としては、例えば、フロッピディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＤＶＤ−ＲＯＭ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどを用いることができる。

本実施例におけるネットワーク検索システムの構成を示す図である。 本実施例における画像形成装置のハードウェア構成を示すブロック図である。 本実施例におけるＤＰ、クライアントＰＣのハードウェア構成を示すブロック図である。 本実施例におけるＤＰの表示装置に表示される画面の例である。 本実施例におけるソフトウェアモジュールを示す図である。 本実施例におけるデバイス情報保持部が保持するデバイス情報の例である。 本実施例におけるＨｅｌｌｏメッセージの例である。 本実施例におけるＧｅｔメッセージの例である。 本実施例におけるＧｅｔＲｅｓｐｏｎｓｅメッセージの例である。 本実施例におけるＢｙｅメッセージ例である。 本実施例におけるＰｒｏｂｅメッセージ例である。 本実施例におけるＰｒｏｂｅＭａｔｃｈメッセージ例である。 本実施例におけるクライアントＰＣが画像形成装置を検索する際のＵＩの例を示す図である。 本実施例におけるＰｒｏｂｅメッセージ例である。 本実施例におけるＰｒｏｂｅＭａｔｃｈメッセージ例である。 本実施例におけるＰｒｏｂｅメッセージ例である。 本実施例におけるＤＰの処理を示すフローチャートである。 本実施例におけるＰｒｏｂｅメッセージ例である。 本実施例におけるＰｒｏｂｅメッセージ例である。 本実施例におけるＰｒｏｂｅメッセージ例である。 本実施例におけるＤＰの処理を示すフローチャートである。 本実施例におけるＰｒｏｂｅメッセージ例である。

符号の説明

３０１ ＣＰＵ
３０２ ＲＯＭ
３０３ ＲＡＭ
３０４ システムバス
３０５ ＫＢＣ
３０６ ＣＲＴＣ
３０７ ＤＫＣ
３０８ ＮＩＣ
３０９ａ ＰＤ
３０９ｂ ＫＢ
３１０ ＣＲＴ
３１１ ＨＤ
３１２ ＦＤ

Claims (7)

1. デバイス検索装置であって、
   デバイスを検索するための検索要求であって、検索要求を転送済みのデバイス検索装置を特定するための特定情報を含む検索要求を受信する受信手段と、
   前記受信手段が受信した検索要求に含まれる検索条件を満たすデバイスを検索する検索手段と、
   他のデバイス検索装置を示す情報を記憶する記憶手段と、
   前記特定情報に基づいて、前記記憶手段が記憶している情報が示す前記他のデバイス検索装置のうち、検索要求が転送されていないデバイス検索装置に前記受信手段が受信した検索要求を転送し、検索要求を転送済みのデバイス検索装置に前記受信手段が受信した検索要求を転送しない転送手段とを備えることを特徴とするデバイス検索装置。
2. 前記特定情報に基づいて、前記記憶手段が記憶している情報が示す前記他のデバイス検索装置の中から検索要求が転送されていないデバイス検索装置を選択する選択手段と、
   前記選択手段によって選択されたデバイス検索装置を示す情報を、前記特定情報に追加する追加手段とを更に備え、
   前記転送手段は、前記追加手段によって情報が追加された前記特定情報を含む検索要求を、前記選択手段によって選択されたデバイス検索装置に転送することを特徴とする請求項１に記載のデバイス検索装置。
3. 前記記憶手段は、ユーザによって指定されたデバイス検索装置を示す情報を記憶することを特徴とする請求項１又は２に記載のデバイス検索装置。
4. 前記検索手段による検索の結果を前記検索要求の送信元である情報処理装置に送信する送信手段を更に備えることを特徴とする請求項１乃至３のいずれか１項に記載のデバイス検索装置。
5. 前記デバイス検索装置は、複数のサブネットによって構成されたネットワークに接続されており、前記デバイス検索装置と前記他のデバイス検索装置はそれぞれ異なるサブネットに接続されていることを特徴とする請求項１乃至４の何れか１項に記載のデバイス検索装置。
6. デバイス検索装置の制御方法であって、
   デバイスを検索するための検索要求であって、検索要求を転送済みのデバイス検索装置を特定するための特定情報を含む検索要求を受信する受信ステップと、
   前記受信ステップによって受信された検索要求に含まれる検索条件を満たすデバイスを検索する検索ステップと、
   他のデバイス検索装置を示す情報を記憶手段に記憶する記憶ステップと、
   前記特定情報に基づいて、前記記憶手段が記憶している情報が示す前記他のデバイス検索装置のうち、検索要求が転送されていないデバイス検索装置に前記受信ステップで受信した検索要求を転送し、検索要求を転送済みのデバイス検索装置に前記受信手段が受信した検索要求を転送しない転送ステップとを有することを特徴とするデバイス検索装置の制御方法。
7. 請求項６に記載のデバイス検索装置の制御方法をコンピュータに実行させるためのコンピュータプログラム。

Images