(57)【特許請求の範囲】
【請求項１】
複数のサブネットからなるネットワークに存在する情報処理装置であって、
前記複数のサブネットのうちの第１のサブネットに存在するデバイスと前記複数のサブネットのうちの第２のサブネットに存在するデバイスのそれぞれから、デバイスを識別するための識別情報と当該デバイスが存在するサブネットと異なるサブネットに存在する装置からの検索が可能であるか否かを示す属性情報とを少なくとも含むデバイス情報を取得する取得手段と、
前記ネットワークに存在する外部装置から送信された検索要求を受信する受信手段と、
前記検索要求に含まれる検索条件を満たすデバイスを検索する検索手段と、
前記取得手段によって取得されたデバイス情報に含まれる属性情報を用いてデバイスの属性を判断する判断手段と、
前記外部装置が存在するサブネットを特定する特定手段と、
前記検索条件を満たすデバイスが該デバイスが存在するサブネットと異なるサブネットに存在する装置からの検索が可能であることを示す属性であるか、又は前記特定されたサブネットが当該デバイスが存在するサブネットと同じであるかの何れかの場合、前記検索要求に対する検索結果として当該デバイスの情報を前記外部装置に送信し、前記検索条件を満たすデバイスが該デバイスが存在するサブネットと異なるサブネットに存在する装置からの検索が不可能であることを示す属性であり、且つ前記特定されたサブネットが当該デバイスが存在するサブネットと異なる場合、前記検索要求に対する検索結果として当該デバイスの情報を前記外部装置に送信しないように制御する送信制御手段と、
を有することを特徴とする情報処理装置。
【請求項２】
前記特定手段は、前記外部装置のＩＰアドレスに基づいて当該外部装置が存在するサブネットを特定することを特徴とする請求項１記載の情報処理装置。
【請求項３】
前記デバイスは、プリンタ、複写機、複合機、スキャナ、ファクシミリのうちのいずれかであり、前記検索条件は、デバイスの種類を示す情報であることを特徴とする請求項１又は２に記載の情報処理装置。
【請求項４】
複数のサブネットからなるネットワークに存在する情報処理装置の制御方法であって、
前記複数のサブネットのうちの第１のサブネットに存在するデバイスと前記複数のサブネットのうちの第２のサブネットに存在するデバイスのそれぞれから、デバイスを識別するための識別情報と当該デバイスが存在するサブネットと異なるサブネットに存在する装置からの検索が可能であるか否かを示す属性情報とを少なくとも含むデバイス情報を取得する取得ステップと、
前記ネットワークに存在する外部装置から送信された検索要求を受信する受信ステップと、
前記検索要求に含まれる検索条件を満たすデバイスを検索する検索ステップと、
前記取得ステップによって取得されたデバイス情報に含まれる属性情報を用いてデバイスの属性を判断する判断ステップと、
前記外部装置が存在するサブネットを特定する特定ステップと、
前記検索条件を満たすデバイスが該デバイスが存在するサブネットと異なるサブネットに存在する装置からの検索が可能であることを示す属性であるか、又は前記特定されたサブネットが当該デバイスが存在するサブネットと同じであるかの何れかの場合、前記検索要求に対する検索結果として当該デバイスの情報を前記外部装置に送信し、前記検索条件を満たすデバイスが該デバイスが存在するサブネットと異なるサブネットに存在する装置からの検索が不可能であることを示す属性であり、且つ前記特定されたサブネットが当該デバイスが存在するサブネットと異なる場合、前記検索要求に対する検索結果として当該デバイスの情報を前記外部装置に送信しないように制御する送信制御ステップと、
を有することを特徴とする制御方法。
【請求項５】
複数のサブネットからなるネットワークに存在する情報処理装置に以下のステップを実行させるコンピュータプログラムであって、
前記複数のサブネットのうちの第１のサブネットに存在するデバイスと前記複数のサブネットのうちの第２のサブネットに存在するデバイスのそれぞれから、デバイスを識別するための識別情報と当該デバイスが存在するサブネットと異なるサブネットに存在する装置からの検索が可能であるか否かを示す属性情報とを少なくとも含むデバイス情報を取得する取得ステップと、
前記ネットワークに存在する外部装置から送信された検索要求を受信する受信ステップと、
前記検索要求に含まれる検索条件を満たすデバイスを検索する検索ステップと、
前記取得ステップによって取得されたデバイス情報に含まれる属性情報を用いてデバイスの属性を判断する判断ステップと、
前記検索条件を満たすデバイスが該デバイスが存在するサブネットと異なるサブネットに存在する装置からの検索が可能であることを示す属性であるか、又は前記特定されたサブネットが当該デバイスが存在するサブネットと同じであるかの何れかの場合、前記検索要求に対する検索結果として当該デバイスの情報を前記外部装置に送信し、前記検索条件を満たすデバイスが該デバイスが存在するサブネットと異なるサブネットに存在する装置からの検索が不可能であることを示す属性であり、且つ前記特定されたサブネットが当該デバイスが存在するサブネットと異なる場合、前記検索要求に対する検索結果として当該デバイスの情報を前記外部装置に送信しないように制御する送信制御ステップと、
を有することを特徴とするコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、画像形成装置を検索する検索システムにおける情報処理装置、画像形成装置及びその制御方法に関する。
【背景技術】
【０００２】
従来、プリンタ等のデバイスがネットワークに接続され、クライアントＰＣからネットワークを介して利用することが可能になっている。その際、クライアントＰＣはまずネットワーク上のデバイスを発見し、発見したデバイスを利用するためのドライバソフトウェアをインストールする必要がある。ネットワーク上のデバイスを検索するための技術としていくつか考えられているものの中には、ブロードキャストやマルチキャストを用いて検索要求パケットを送信するものがある。ブロードキャストやマルチキャストは、ネットワーク上に存在する複数の装置に対してデータを送信する方法である。これらの技術では、クライアントＰＣは検索要求パケットをブロードキャストやマルチキャストで送信し、検索要求パケットを受信したデバイスが検索応答パケットをクライアントＰＣに送信することにより、デバイスを検索する。
【０００３】
また、ネットワーク同士がルータなどの接続機器により相互に接続され、大規模なネットワークを構築することが可能になっている。その中で、ブロードキャストやマルチキャストはネットワーク全体のトラフィックに影響を与えるため、一般にルータはこれらを通過させない設定で運用されることが多い。ルータによって区切られたそれぞれのネットワークはサブネットと呼ばれ、ブロードキャストやマルチキャストは一般にサブネット内のみで利用されている。このような環境でブロードキャストやマルチキャストを使用したネットワークデバイス検索技術を用いた場合、クライアントＰＣが送信した検索要求パケットはルータを通過できない。そのため、複数のサブネットがルータによって接続されたネットワーク環境において、クライアントＰＣは、異なるサブネットに存在するデバイスを発見することはできなかった。
【０００４】
そこで、サブネットが異なるデバイスとクライアントＰＣとの間であっても検索が行えるような検索システムが考えられている。その一例として、ネットワーク上に検索のためのサーバ（Ｄｉｓｃｏｖｅｒｙ  Ｐｒｏｘｙ：ＤＰ）を配置するものがある。クライアントＰＣからＤＰに対して検索条件を含めた検索要求メッセージを送信し、検索を要求されたＤＰはクライアントＰＣに代行してデバイスを検索する方法である。（例えば特許文献１）
【特許文献１】特開２００１−２１６１０７
【発明の開示】
【発明が解決しようとする課題】
【０００５】
上記従来技術における検索システムによって、クライアントＰＣは異なるサブネットに存在する全てのデバイスを検索することができるようになった。しかしながら、実際は、サブネット内のクライアントＰＣからのみ使用を許可するデバイスや、サブネット外からの使用を許可するデバイスなど、デバイス毎にその使用形態は異なる。例えば、イントラネット内において、部門毎にサブネットが別れており、ある特定の部門でのみ使用が許可されているデバイスや、全ての部門において使用可能なデバイスなどが考えられえる。上記従来技術の方法を用いると、このような状況に関係なく、全てのデバイスがサブネット外から使用（検索）可能になってしまう。
【０００６】
本発明は、このような問題に対してなされたものであり、サーバを配置してデバイスを検索する検索システムにおいて、各デバイスそれぞれの使用形態に応じて、検索対象となるデバイスを制限できるようにすることを目的とする。
【課題を解決するための手段】
【０００７】
上記目的を達成するために本発明における情報処理装置は、複数のサブネットからなるネットワークに存在する情報処理装置であって、前記複数のサブネットのうちの第１のサブネットに存在するデバイスと前記複数のサブネットのうちの第２のサブネットに存在するデバイスのそれぞれから、デバイスを識別するための識別情報と当該デバイスが存在するサブネットと異なるサブネットに存在する装置からの検索が可能であるか否かを示す属性情報とを少なくとも含むデバイス情報を取得する取得手段と、前記ネットワークに存在する外部装置から送信された検索要求を受信する受信手段と、前記検索要求に含まれる検索条件を満たすデバイスを検索する検索手段と、前記取得手段によって取得されたデバイス情報に含まれる属性情報を用いてデバイスの属性を判断する判断手段と、前記外部装置が存在するサブネットを特定する特定手段と、前記検索条件を満たすデバイスが該デバイスが存在するサブネットと異なるサブネットに存在する装置からの検索が可能であることを示す属性であるか、又は前記特定されたサブネットが当該デバイスが存在するサブネットと同じであるかの何れかの場合、前記検索要求に対する検索結果として当該デバイスの情報を前記外部装置に送信し、前記検索条件を満たすデバイスが該デバイスが存在するサブネットと異なるサブネットに存在する装置からの検索が不可能であることを示す属性であり、且つ前記特定されたサブネットが当該デバイスが存在するサブネットと異なる場合、前記検索要求に対する検索結果として当該デバイスの情報を前記外部装置に送信しないように制御する送信制御手段とを有することを特徴とする。
【発明の効果】
【０００９】
本発明によれば、サーバを配置してデバイスを検索する検索システムにおいて、各デバイスそれぞれの使用形態に応じて、検索対象となるデバイスを制限することができるようになる。
【発明を実施するための最良の形態】
【００１０】
（実施例１）
図１は本発明を適用したデバイス検索システムの構成を示す図である。ＤＨＣＰサーバ１０１および検索サーバとしてのＤｉｓｃｏｖｅｒｙ  Ｐｒｏｘｙ（以降ＤＰと呼ぶ）１０２が接続されたサブネット１、クライアントＰＣ１０３、画像形成装置１０４が接続されたサブネット２、クライアントＰＣ１０８、画像形成装置１０５が接続されたサブネット３が存在している。サブネット１とサブネット２はルータ１０６により相互に接続され、サブネット１とサブネット３はルータ１０７により相互に接続されており、これら３つのサブネットによって１つのＬＡＮが形成されている。そして、結果としてすべてのサブネットにおいて接続された端末は相互に通信が可能になっている。ただし、ルータ１０６、１０７は一方のサブネットから受信したブロードキャストやマルチキャストを他方のサブネットにそのまま通過させることはしない。そのため、ブロードキャストやマルチキャストによる通信は各サブネット内でのみ可能である。ここで、本実施例に登場する装置のうち、画像形成装置１０４、１０５は、本発明におけるデバイスの一例であり、プリンタや複写機、スキャナ、複合機、ファクシミリ等である。また、本実施例に登場する装置のうち、ＤＨＣＰサーバ１０１、ＤＰ１０２、クライアントＰＣ１０３、１０８は、本発明における情報処理装置の一例であり、後述するように汎用のＰＣを使用可能である。図１のデバイス検索システムでは、クライアントＰＣ１０３を操作するユーザが所望する画像形成装置を探すために、クライアントＰＣ１０３又は１０８からＤＰ１０２に対して検索要求パケットが送られる。そして、ＤＰ１０２においてデバイスが検索された結果、検索結果がクライアントＰＣ１０３又は１０８に送られる。
【００１１】
次に、ＤＨＣＰ  （Ｄｙｎａｍｉｃ  Ｈｏｓｔ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）を使用しＩＰアドレスなどの設定情報を配布する方法について説明する。ＤＨＣＰは、ネットワークに接続された端末に設定情報を配布する仕組みを規定したプロトコルであり、その詳細はＲＦＣ２１３１で規定されている。ＤＨＣＰはクライアント／サーバ方式をとり、ＤＨＣＰサーバは各種設定情報を一元管理し、ＤＨＣＰクライアントであるネットワーク端末はその情報を受信する。
【００１２】
図２は、ＤＨＣＰサーバとＤＨＣＰクライアントとの間で送受信されるＤＨＣＰメッセージのフローを説明するシーケンス図である。ＤＨＣＰクライアントはＤＨＣＰ  ＤＩＳＣＯＶＥＲメッセージをブロードキャストする（Ｓ２００１）。ＤＨＣＰサーバはＤＨＣＰ  ＤＩＳＣＯＶＥＲメッセージを受信すると、メッセージを送信したＤＨＣＰクライアントにＩＰアドレスを割り当て、その後ＤＨＣＰ  ＯＦＦＥＲメッセージを送信する（Ｓ２００２）。ＤＨＣＰ  ＯＦＦＥＲメッセージには、ＤＨＣＰ  ＤＩＳＣＯＶＥＲ  メッセージを送信したＤＨＣＰクライアントに割り当てられたＩＰアドレスやその他の設定情報が含まれている。
【００１３】
ＤＨＣＰクライアントはＤＨＣＰ  ＯＦＦＥＲメッセージを受信すると、ＤＨＣＰ  ＯＦＦＥＲメッセージに含まれていたＩＰアドレスを使用するためのＤＨＣＰ  ＲＥＱＵＥＳＴメッセージをブロードキャストする（Ｓ２００３）。ＤＨＣＰサーバはＤＨＣＰ  ＲＥＱＵＥＳＴメッセージを受信すると、ＤＨＣＰ  ＡＣＫメッセージを送信する（Ｓ２００４）。ＤＨＣＰクライアントはＤＨＣＰ  ＡＣＫメッセージを受信すると、それ以降は配布されたＩＰアドレスおよび設定情報を使用してネットワーク通信を行う。
【００１４】
また、ＤＨＣＰサーバから配布されたＩＰアドレスには使用可能な期間（リースタイム）が設けられている。ＤＨＣＰクライアントは、取得したＩＰアドレスをリースタイム後も継続して使用したい場合には、リースタイムが切れる期限の前にＤＨＣＰサーバに対してＤＨＣＰ  ＲＥＱＵＥＳＴメッセージを送信する（Ｓ２００５）。ＤＨＣＰサーバは割り当て済のＩＰアドレスからのＤＨＣＰ  ＲＥＱＵＥＳＴを受信すると、リースタイムを更新し、ＤＨＣＰ  ＡＣＫメッセージを送信する（Ｓ２００６）。
【００１５】
また、ＤＨＣＰクライアントがＩＰアドレスの使用を中止する場合、ＤＨＣＰクライアントはＤＨＣＰサーバに対してＤＨＣＰ  ＲＥＬＥＡＳＥメッセージを送信する（Ｓ２００７）。ＤＨＣＰサーバはＤＨＣＰ  ＲＥＬＥＡＳＥメッセージを受信すると、そのＩＰアドレスの割り当てを解除し、別のＤＨＣＰクライアントに対して割り当て可能にする。
【００１６】
また、ＤＨＣＰサーバは、割り当て済のＩＰアドレスからリースタイムが切れる前にＤＨＣＰ  ＲＥＱＵＥＳＴを受信することなく、リースタイムが経過した場合は、そのＩＰアドレスの割り当てを解除する。そして、そのＩＰアドレスを別のＤＨＣＰクライアントに対して割り当て可能にする。
【００１７】
尚、図２のフローにおいて、Ｓ２００１〜Ｓ２００４のメッセージは、ブロードキャストで行われる。この時点では、ＤＨＣＰクライアントにはまだＩＰアドレスが確定していないためである。
【００１８】
一方、図１の構成のように複数のサブネットがルータによって接続されたネットワークにおいて、ルータがブロードキャストを通過させない設定である場合には、これらのＤＨＣＰメッセージはルータにより遮断されてしまう。この問題を解決するためにＲＦＣ２１３１においてはリレーエージェントの仕様も記載されている。リレーエージェントは一般にルータの一機能として実装され、以下に図１の構成の記号を使用して簡単にその動作を説明する。
【００１９】
まずリレーエージェント機能を実装したルータ１０６はあらかじめＤＨＣＰサーバ１０１のＩＰアドレスを記憶しておく。ＤＨＣＰクライアントとなるクライアントＰＣ１０３はＤＨＣＰ  ＤＩＳＣＯＶＥＲやＤＨＣＰ  ＲＥＱＵＥＳＴメッセージをサブネット２にブロードキャストする。ルータ１０６はＤＨＣＰ  ＤＩＳＣＯＶＥＲ／ＤＨＣＰ  ＲＥＱＵＥＳＴメッセージを受信すると、このメッセージをあらかじめ記憶しているＤＨＣＰサーバ１０１に対してユニキャストで転送する。ＤＨＣＰサーバ１０１はルータ１０６からユニキャストでＤＨＣＰ  ＤＩＳＣＯＶＥＲ／ＤＨＣＰ  ＲＥＱＵＥＳＴメッセージを受信すると、ＤＨＣＰ  ＯＦＦＥＲやＤＨＣＰ  ＡＣＫメッセージをルータ１０６に対してユニキャストで送信する。ルータ１０６はＤＨＣＰサーバ１０１からＤＨＣＰ  ＯＦＦＥＲ／ＤＨＣＰ  ＡＣＫメッセージを受信すると、このメッセージをサブネット２にブロードキャストする。
【００２０】
このように、リレーエージェント機能を実装したルータがブロードキャストによるＤＨＣＰメッセージを受信してユニキャストでＤＨＣＰサーバに転送することで、ＤＨＣＰクライアントはＤＨＣＰサーバから情報を受信できるようになる。
【００２１】
図３は、ＤＨＣＰメッセージのフォーマットを示す図である。ｏｐｔｉｏｎｓフィールド３０１は可変長の各種データを設定可能な領域である。この領域は１ｂｙｔｅのタグ、１ｂｙｔｅのデータサイズ、可変長のデータを１個のｏｐｔｉｏｎデータとし、複数のｏｐｔｉｏｎデータを設定可能である。タグの値はあらかじめ標準化されている値とベンダが拡張可能な値があり、一例としてサブネットマスクやＤＮＳサーバのＩＰアドレスといったタグの値は標準化された値として広く使用されている。
【００２２】
本実施例においては、このｏｐｔｉｏｎｓフィールド３０１を拡張して使用する。ＤＰのＩＰアドレスを意味するタグを定義し、データとしてＤＰのＩＰアドレスを設定することで、ＤＨＣＰプロトコルを使用してＤＰのＩＰアドレス情報をクライアントＰＣやデバイス等のＤＨＣＰクライアントに配布することが可能となる。さらに、ネットワーク上に複数のＤＰが存在する場合には、このｏｐｔｉｏｎｓフィールド３０１に複数のＤＰのＩＰアドレスを設定することによりそれらのＩＰアドレス情報を配布することも可能である。
【００２３】
またｇｉａｄｄｒフィールド３０２は、リレーエージェントがＤＨＣＰサーバにＤＨＣＰメッセージを転送する際に、リレーエージェント自身のＩＰアドレスを設定する。それによりＤＨＣＰサーバはＤＨＣＰメッセージを受信した際に、それがリレーエージェントからのものであった場合にはこのｇｉａｄｄｒフィールドを確認することでＤＨＣＰクライアントが属するサブネットを特定することが可能である。またｙｉａｄｄｒフィールド３０３は、ＤＨＣＰサーバがＤＨＣＰクライアントに割り当てるＩＰアドレスが設定される。
【００２４】
次に、図１で示したシステム構成の中で、本発明に関係するＤＨＣＰサーバ１０１、ＤＰ１０２、クライアントＰＣ１０３、１０８、画像形成装置１０４、１０５のハードウェアおよびソフトウェア構成について説明する。なお、以降では特に断らない限り画像形成装置に関しては代表して１０４の記号を用いる。
【００２５】
図４は画像形成装置１０４のハードウェア構成を示すブロック図である。スキャナＩ／Ｆ制御部４０１は、スキャナ４１３を制御する装置である。ＣＰＵ４０２は、印刷装置のソフトウェアプログラムを実行し、装置全体の制御を行う。ＲＯＭ４０３は、リードオンリーメモリであり、装置のブートプログラムや固定パラメータ等が格納されている。ＲＡＭ４０４は、ランダムアクセスメモリであり、ＣＰＵ４０２が装置を制御する際に、一時的なデータの格納などに使用する。ＨＤＤ４０５は、ハードディスクドライブであり、印刷データの格納など、様々なデータの格納に使用する。プリンタＩ／Ｆ制御部４０６は、プリンタ４１２を制御する装置である。ＮＶＲＡＭ４０７は、不揮発性のメモリであり印刷装置の各種設定値を保存するためのものである。パネル制御部４０８は、オペレーションパネル４１４を制御し、各種情報の表示、使用者からの指示入力を行う。ネットワークＩ／Ｆ制御部４０９は、ネットワークとのデータの送信制御や受信制御を行う。バス４１０は、スキャナＩ／Ｆ制御部４０１、ＣＰＵ４０２、ＲＯＭ４０３、ＲＡＭ４０４、ＨＤＤ４０５、プリンタＩ／Ｆ制御部４０６、ＮＶＲＡＭ４０７、パネル制御部４０８、ネットワークＩ／Ｆ制御部４０９が接続され、ＣＰＵ４０２からの制御信号や各装置間のデータ信号が送受信されるシステムバスである。
【００２６】
図１６は、ＤＨＣＰサーバ１０１、ＤＰ１０２、クライアントＰＣ１０３、１０８のハードウェア構成を示すブロック図である。
なお、ＤＨＣＰサーバ１０１、ＤＰ１０２、クライアントＰＣ１０３，１０８は汎用のＰＣ（パーソナルコンピュータ）を使用可能であり、以下の説明は共通である。
【００２７】
図１６において、１６０１はＣＰＵであり、システムバス１６０４に接続された各種デバイスの制御を行う。１６０２はＢＩＯＳやブートプログラムを記憶するＲＯＭ、１６０３はＣＰＵ２６０１の主記憶装置として使用されるＲＡＭである。１６０５はキーボードコントローラ（ＫＢＣ）であり、マウス等のポインティングデバイス１６０９ａ、キーボード１６０９ｂからの情報などの入力に係る処理を行う。１６０６は表示制御部（ＣＲＴＣ）であり、内部にビデオメモリを有し、ＣＰＵ１６０１からの指示に従ってそのビデオメモリに描画すると共に、ビデオメモリに描画されたイメージデータをビデオ信号としてＣＲＴ表示装置１６１０に出力する。なお、図１６において表示装置としてＣＲＴを例示しているが、液晶表示装置等、その表示装置の種類は問わない。１６０７はディスクコントローラ（ＤＫＣ）であり、ハードディスク１６１１、フロッピー（登録商標）ディスク１６１２へのアクセスを行う。１６０８はネットワークインタフェースカード（ＮＩＣ）であって、ネットワークに接続し、ネットワークを介してのデータの送信制御や受信制御を行うものである。
【００２８】
なお、ハードディスク１６１１には、ＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）やＯＳ上で動作する各種アプリケーションプログラム等が格納される。
【００２９】
上記構成において、本装置の電源がＯＮになると、ＣＰＵ１６０１はＲＯＭ１６０２に格納されたブートプログラムに従って、ハードディスク１６１１からＯＳをＲＡＭ１６０３に読み込み、情報処理装置として機能するようになる。
【００３０】
図５は、ＤＨＣＰサーバ１０１、ＤＰ１０２、クライアントＰＣ１０３、１０８、画像形成装置１０４のソフトウェア構成を示すブロック図である。ブロック図において示された各処理部は、プログラムモジュールであり、各装置が備えるＣＰＵによって実行される。
【００３１】
ＤＨＣＰサーバ１０１において、ＤＨＣＰサーバ処理部５０１は前述のＤＨＣＰサーバとしての処理を行う。クライアントに配布するＩＰアドレスのリストや設定情報は配布情報ＤＢ５０３において保持されており、ＤＨＣＰサーバ処理部５０１はクライアントからの要求に基づき配布情報ＤＢ５０３を参照して各種情報を配布する。配布情報設定部５０２は配布情報ＤＢ５０３に保持する情報を設定するものである。設定可能な情報の一例としてＤＰ１０２のＩＰアドレスを設定可能とする。またクライアントが属するサブネットごと、またクライアントごとに配布する情報を設定することも可能である。
【００３２】
ＤＰ１０２において、デバイス情報通知受信部５１１は画像形成装置１０４からデバイス情報の登録／更新／削除要求の通知を受信し、その通知の種類に基づきデバイス情報保持部５１４が保持するデバイス情報の処理を行う。
【００３３】
処理の結果、デバイス情報の取得が必要であると判断された場合は、デバイス情報取得部５１２は画像形成装置１０４に対してデバイス情報取得要求を送信し、返されたデバイス情報をデバイス情報保持部５１４に保持する。デバイス情報保持部５１４にはデバイス属性保持部５１５が付随しており、画像形成装置１０４が送信したデバイス情報に含まれているデバイスの属性値を保存する。デバイス情報検索処理部５１３はクライアントＰＣ１０３からデバイス情報の検索要求を受信し、指定された検索条件に基づきデバイス情報保持部５１４内のデバイス情報を検索し、その結果をクライアントＰＣ１０３に送信する。その際、クライアントのサブネット検知部５１７がクライアントＰＣ１０３のサブネットを特定するアドレス（例えばサブネットマスクやアドレスのプレフィックス）を取得し、デバイス属性判定部５１６が、デバイス属性保持部５１５に保持されている属性値に基づき、前記取得したＰＣ１０３のサブネットからの検索に対して応答してよいデバイスのみを選択し、前記選択したデバイスの情報のみをクライアントＰＣ１０３に送信する。デバイス情報保持部５１４が保持するデバイス情報については後述する。
【００３４】
クライアントＰＣ１０３において、ＤＨＣＰクライアント処理部５２１は前述のＤＨＣＰクライアントとしての処理を行う。ＤＨＣＰサーバから配布されたＩＰアドレスや各種設定情報は設定情報記憶部５２２に保持され、適宜参照して使用することが可能である。デバイス検索要求処理部５２３はＤＰ１０２に対してデバイス検索を行い、その結果は検索情報表示部５２４において表示される。
【００３５】
画像形成装置１０４において、ＤＨＣＰクライアント処理部５３１は前述のＤＨＣＰクライアントとしての処理を行う。ＤＨＣＰサーバから配布されたＩＰアドレスや各種設定情報は設定情報記憶部５３２に保持され、適宜参照して使用することが可能である。デバイス情報管理部５３４は画像形成装置１０４自身のデバイス情報を管理する。デバイス情報通知部５３３はデバイス情報の通知が必要な場合にＤＰ１０２に対してデバイス情報の登録／更新／削除要求を送信する。デバイス情報送信部５３５はネットワークを介してデバイス情報取得要求を受信し、デバイス情報管理部５３４が管理しているデバイス情報を要求元に送信する。デバイス情報管理部５３４に付随してデバイス属性管理部５３６が存在し、オペレーションパネル４１４もしくはネットワーク４０９から設定された属性情報が保持されている。画像形成装置１０４がＤＰ１０２に対してデバイス情報を送信する際には、デバイス属性管理部５３６に保持されている属性情報も通知する。
【００３６】
図６はＤＰ１０２のデバイス情報保持部５１４が保持するデバイス情報テーブルの例である。図６の例では、３つのデバイス情報がデバイス情報テーブルとして登録されている。各デバイス情報には、以下に示すような、デバイス毎の詳細情報が含まれる。
【００３７】
ＩＤ６０１はＤＰ内でデバイスを識別するためのＩＤを示す。ＵＵＩＤ６０２はデバイスをグローバルに識別するＵＵＩＤを示す。バージョン６０３はデバイス情報のバージョンを示す。デバイスタイプ６０４は複合機を意味する「ＭＦＰ」、プリンタを意味する「Ｐｒｉｎｔｅｒ」など、デバイスの種類を示す情報である。モデル名６０５は「ＬＢＰＸＸＸＸ」のようなデバイスのモデル名を示す。デバイス名６０６はデバイス管理者がデバイスに設定した名前を示す。ＵＲＬ６０７はデバイス情報を取得するためのＵＲＬを示す。属性値６０８はデバイスの検索範囲を示す属性値を示す。図６においては属性値の一例として、ｐｕｂｌｉｃとｐｒｉｖａｔｅという２個の属性値を持つことを想定し、ｐｕｂｌｉｃはデバイスが存在するサブネットと異なるサブネットのクライアントＰＣから検索できることを意味し、ｐｒｉｖａｔｅはデバイスが存在するサブネットと同一サブネット内のクライアントＰＣからしか検索できないことを意味している。Ｐｕｂｌｉｃ属性は、第１の属性の一例であり、Ｐｒｉｖａｔｅ属性は、第２の属性の一例である。属性値はデバイスからどのようなタイミングで通知されてもよいし、ユーザによって手動でＤＰ１０２に設定されてもよい。また、図示していないが、デバイス情報の中には、デバイスのＩＰアドレスが登録されている。後述するフロー（図１５）において、ＤＰ１０２は、デバイスのＩＰアドレスとサブネットマスクを用いてデバイスのサブネットアドレスを算出する。これにより、デバイスが存在するサブネットを特定することができる。
【００３８】
尚、図６の例では、ＩＤが１のデバイス情報は画像形成装置１０４の情報を示し、ＩＤが２のデバイス情報は画像形成装置１０５の情報を示している。また、デバイス情報テーブルにデバイス情報として登録される詳細情報は、図６に示した例に限らない。例えば、プリンタや複合機の能力を示す情報（例えば、カラー印刷機能の有無、両面印刷機能の有無等）が含まれていてもよい。
【００３９】
次に、画像形成装置１０４のデバイス情報をＤＰ１０２に登録する処理について説明する。画像形成装置１０４はＤＨＣＰサーバ１０１から、画像形成装置１０４自身のＩＰアドレスに加えＤＰ１０２のＩＰアドレスを受信している。
【００４０】
画像形成装置１０４は、起動時やデバイス情報に変化があった場合にＤＰ１０２に対して図７のようなＸＭＬ形式のＨｅｌｌｏメッセージをユニキャストで送信することにより存在を通知する。
【００４１】
図７のＨｅｌｌｏメッセージは、＜Ｈｅａｄｅｒ＞タグで囲まれるｈｅａｄｅｒ部７０１と＜Ｂｏｄｙ＞タグで囲まれるｂｏｄｙ部７０２からなり、全体が＜Ｅｎｖｅｌｏｐｅ＞タグで囲まれる構造になっている。この構造は本実施例において使用するメッセージすべてに共通である。
【００４２】
ｈｅａｄｅｒ部７０１はメッセージの内容に依存しない共通ヘッダとしての役割を果たしており、＜Ａｃｔｉｏｎ＞タグ、＜ＭｅｓｓａｇｅＩＤ＞タグ、＜Ｔｏ＞タグが存在する。＜Ａｃｔｉｏｎ＞タグはメッセージの種類を識別するためのものである。＜ＭｅｓｓａｇｅＩＤ＞タグはメッセージを一意に識別するための識別子である。＜Ｔｏ＞タグはこのメッセージの送信先を識別するためのものである。一方、ｂｏｄｙ部７０２はメッセージの内容に対応して構造が変化する。図７においては、＜Ｂｏｄｙ＞タグの直下に＜Ｈｅｌｌｏ＞タグが存在し、このメッセージがＨｅｌｌｏメッセージであることを示している。＜Ｈｅｌｌｏ＞タグの中には＜ＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅ＞タグ、＜Ｔｙｐｅｓ＞タグ、＜ＸＡｄｄｒｓ＞タグ、＜ＭｅｔａｄａｔａＶｅｒｓｉｏｎ＞タグが存在する。＜ＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅ＞タグの中には＜Ａｄｄｒｅｓｓ＞タグが存在し、デバイスを識別するアドレス情報を持つ。＜Ｔｙｐｅｓ＞タグはデバイスのタイプ情報を持つ。＜ＸＡｄｄｒｓ＞タグはデバイス情報を取得するためのＵＲＬを持つ。＜ＭｅｔａｄａｔａＶｅｒｓｉｏｎ＞タグはデバイス情報のバージョンを持つ。
【００４３】
ＤＰ１０２はＨｅｌｌｏメッセージの中からデバイスをグローバルに識別するＵＵＩＤとして＜ＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅ＞タグの中の＜Ａｄｄｒｅｓｓ＞タグの値を抽出する。またデバイスタイプとして＜Ｔｙｐｅｓ＞タグの値を抽出する。またデバイス情報のバージョンとして＜ＭｅｔａｄａｔａＶｅｒｓｉｏｎ＞タグの値を抽出する。またデバイス情報を取得するためのＵＲＬとして＜ＸＡｄｄｒｓ＞タグの値を抽出する。そしてこれら抽出した情報をデバイス情報保持部５１４に格納する。また同時に、Ｈｅｌｌｏメッセージの送信元ＩＰアドレスもデバイス情報保持部５１４に格納する。
【００４４】
その後ＤＰ１０２は＜ＸＡｄｄｒｓ＞タグで記載されたＵＲＬに対し、図８のようなＸＭＬ形式のＧｅｔメッセージをユニキャストで送信する。図８のＧｅｔメッセージは、ｈｅａｄｅｒ部のみを持つメッセージとなっている。ｈｅａｄｅｒ部の＜Ａｃｔｉｏｎ＞タグにおいて、このメッセージがＧｅｔメッセージであることを示している。
【００４５】
画像形成装置１０４のデバイス情報送信部５３５はＧｅｔメッセージを受信すると図９のようなＧｅｔＲｅｓｐｏｎｓｅメッセージを送信する。
【００４６】
図９のＧｅｔＲｅｓｐｏｎｓｅメッセージにおいては、ｂｏｄｙ部に＜Ｍｅｔａｄａｔａ＞タグで示されるデバイス情報を持つ構造となっている。＜Ｍｅｔａｄａｔａ＞タグの中には＜ＭｅｔａｄａｔａＳｅｃｔｉｏｎ＞タグで示されるＭｅｔａｄａｔａＳｅｃｔｉｏｎ部９０１、９０２、９０３が存在する。各ＭｅｔａｄａｔａＳｅｃｔｉｏｎ部は直下のタグにより、その中に持つ情報の種類が指定される。ＭｅｔａｄａｔａＳｅｃｔｉｏｎ部９０１は＜ＴｈｉｓＤｅｖｉｃｅ＞タグを持っており、デバイスごとに異なる情報が格納される。＜ＦｒｉｅｎｄｌｙＮａｍｅ＞タグはこのデバイスにつけた名前、＜ＦｉｒｍｗａｒｅＶｅｒｓｉｏｎ＞タグはこのデバイスのファームウェアバージョン、＜ＳｅｒｉａｌＮｕｍｂｅｒ＞タグはこのデバイスのシリアル番号を示している。ＭｅｔａｄａｔａＳｅｃｔｉｏｎ部９０２は＜ＴｈｉｓＭｏｄｅｌ＞タグを持っており、デバイスのモデルごとに異なる情報が格納される。＜Ｍａｎｕｆａｃｔｕｒｅｒ＞タグはデバイスの製造会社名、＜Ｍａｎｕｆａｃｔｕｒｅｒ＞タグはデバイス製造会社のＵＲＬ、＜ＰｒｅｓｅｎｔａｔｉｏｎＵＲＬ＞はデバイスの情報を示すＵＲＬ、＜ＭｏｄｅｌＮａｍｅ＞タグはデバイスのモデル名を示している。ＭｅｔａｄａｔａＳｅｃｔｉｏｎ部９０３は＜Ｒｅｌａｔｉｏｎｓｈｉｐ＞タグを持っており、デバイスが持つ内部サービスの情報が格納される。本実施例においては、内部サービスとは画像形成装置が提供するプリントサービスである。＜Ｒｅｌａｔｉｏｎｓｈｉｐ＞タグはさらにその直下に＜Ｈｏｓｔｅｄ＞タグを持ち、その中に＜ＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅ＞タグ、＜Ｔｙｐｅｓ＞タグ、＜ＳｅｒｖｉｃｅＩｄ＞タグ、＜ＤｅｖｉｃｅＡｔｔｒｉｂｕｔｅ＞タグが存在する。＜ＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅ＞タグの中には＜Ａｄｄｒｅｓｓ＞タグが存在し、サービスを利用するためのアドレス情報を持つ。＜Ｔｙｐｅｓ＞タグはサービスのタイプ情報を持つ。＜ＳｅｒｖｉｃｅＩｄ＞タグはデバイス内でサービスを識別するための識別子を持つ。＜ＤｅｖｉｃｅＡｔｔｒｉｂｕｔｅ＞タグは、デバイスの検索可能範囲を示す属性値である。
【００４７】
ＤＰ１０２は受信したデバイス情報からデバイス名として＜ＦｒｉｅｎｄｌｙＮａｍｅ＞タグの値、モデル名として＜ＭｏｄｅｌＮａｍｅ＞タグの値を抽出し、デバイス情報保持部５１４に格納する。
【００４８】
次にＤＰ１０２に登録されたデバイス情報を画像形成装置１０４が削除する処理について説明する。
【００４９】
画像形成装置１０４は、自機がＳＨＵＴＤＯＷＮする場合など、動作を停止する場合にはＤＰ１０２に対して図１０のようなＢｙｅメッセージをユニキャストで送信する。
【００５０】
図１０のＢｙｅメッセージにおいては、ｂｏｄｙ部に＜Ｂｙｅ＞タグが存在し、このメッセージがＢｙｅメッセージであることを示している。＜Ｂｙｅ＞タグの中には＜ＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅ＞タグが存在する。＜ＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅ＞タグの中には＜Ａｄｄｒｅｓｓ＞タグが存在し、デバイスを識別するアドレス情報を持つ。
【００５１】
ＤＰ１０２はＢｙｅメッセージの中からＵＵＩＤ情報を抽出し、対応するデバイス情報をデバイス情報保持部５１４から削除する。
【００５２】
次に、クライアントＰＣ１０３がＤＰ１０２を使用して画像形成装置を検索する処理について説明する。クライアントＰＣ１０３はＤＨＣＰサーバから、クライアントＰＵ１０３自身のＩＰアドレスに加えて、ＤＰ１０２のＩＰアドレスを受信している。
【００５３】
クライアントＰＣ１０３は、ＤＰ１０２に対して図１１のようなＸＭＬ形式のＰｒｏｂｅメッセージをユニキャストで送信する。図１１のＰｒｏｂｅメッセージにおいては、ｂｏｄｙ部に＜Ｐｒｏｂｅ＞タグが存在し、このメッセージがＰｒｏｂｅメッセージであることを示している。＜Ｐｒｏｂｅ＞タグの中には＜Ｔｙｐｅｓ＞タグが存在する。＜Ｔｙｐｅｓ＞タグは検索したいデバイスのタイプを指定するものである。図１１の例では、デバイスのタイプがプリンタであるデバイスを検索するためのＰｒｏｂｅメッセージを示している。
【００５４】
ＤＰ１０２はＰｒｏｂｅメッセージを受信すると、＜Ｔｙｐｅｓ＞タグを抽出しデバイス情報保持部５１４の中から検索条件に合致するデバイスを探し、図１２のようなＰｒｏｂｅＭａｔｃｈメッセージをクライアントＰＣ１０３に送信する。本実施例において、ＤＰ１０２は、単に、検索条件に合致するデバイスを探すだけではなく、以下の処理を行う。ＤＰ１０２は、Ｐｒｏｂｅメッセージの送信元のＩＰアドレスを取得し、送信元のＩＰアドレスに基づいてクライアントＰＣ１０３が存在するサブネットを検知する。ＤＰ１０２は、図６に示すデバイス情報テーブルに含まれるデバイス情報の中から、ＰｒｏｂｅＭａｔｃｈメッセージとして通知すべきデバイス情報を抽出する。図１１のＰｒｏｂｅメッセージを受信した場合、抽出されるデバイス情報は、デバイスタイプが「Ｐｒｉｎｔｅｒ」であり、属性値がＰｕｂｌｉｃであるもの。又は属性値がＰｒｉｖａｔｅであり且つクライアントＰＣ１０３と同じサブネットに存在するものである。ＤＰ１０２は、このようにして作成されたＰｒｏｂｅＭａｔｃｈメッセージを、クライアントＰＣ１０３に送信する。図１２のＰｒｏｂｅＭａｔｃｈメッセージにおいては、ｂｏｄｙ部に＜ＰｒｏｂｅＭａｔｃｈｅｓ＞タグが存在し、このメッセージがＰｒｏｂｅＭａｔｃｈメッセージであることを示している。＜ＰｒｏｂｅＭａｔｃｈｅｓ＞タグの中には＜ＰｒｏｂｅＭａｔｃｈ＞タグで示されるＰｒｏｂｅＭａｔｃｈ部１２０１、１２０２が存在する。それぞれのＰｒｏｂｅＭａｔｃｈ部が１個の検索結果に対応しており、図１２の例においては２個のデバイスが条件に合致したことを示す検索結果を示している。ＰｒｏｂｅＭａｔｃｈ部の中の構造は図７のＨｅｌｌｏメッセージにおける＜Ｈｅｌｌｏ＞タグの中と同一である。尚、ＤＰ１０２において実行される検索処理については、図１５を用いて詳細に説明する。
【００５５】
クライアントＰＣ１０３はＰｒｏｂｅＭａｔｃｈメッセージの中から＜ＸＡｄｄｒｓ＞タグで記載されたＵＲＬを抽出し、図８のようなＧｅｔメッセージをユニキャストで送信する。本実施例においてＵＲＬは画像形成装置１０４のＩＰアドレスからなっており、ＧｅｔメッセージはＤＰ１０２ではなく画像形成装置１０４に直接送信する。画像形成装置１０４は図９のようなＧｅｔＲｅｓｐｏｎｓｅメッセージを送信し、これを受信したクライアントＰＣ１０３は必要な情報を抽出する。
【００５６】
ＰｒｏｂｅＭａｔｃｈメッセージに複数の検索結果が存在している場合にはクライアントＰＣ１０３はＧｅｔメッセージの送信を繰り返し、すべてのデバイス情報を取得する。
【００５７】
図１３はクライアントＰＣ１０３が画像形成装置を検索する際のＵＩの例を示す図である。図１３の画面は、クライアントＰＣのＣＲＴ３０１０上に表示される画面である。図１３において、領域１３０１は検索するデバイスのタイプを指定するための領域であり、「ＭＦＰ」「Ｐｒｉｎｔｅｒ」などのキーワードが指定可能である。領域１３０１に何も入力しない場合はすべての画像形成装置が検索される。ボタン１３０２を押下すると上述したようにＤＰ１０２に対して検索が実行される。検索された結果は領域１３０３に表示され、取得した情報から、デバイスのタイプやモデル名、デバイス名が同時に表示される。
【００５８】
図１４は、上述した実施例におけるＤＰ１０２のデバイス属性保持部５１５に設定される値を拡張したものである。本属性の構成においては、上述した実施例でｐｕｂｌｉｃとｐｒｉｖａｔｅという２個の属性値しか持たなかったものを、２個より多くの属性値で分類することが可能となっている。例えば本構成例では、ＩＤが１のデバイスはサブネット２のクライアントＰＣからしか検索することができず、ＩＤが２のデバイスはサブネット２とサブネット３から検索することができる。
【００５９】
デバイスがＤＰに存在を登録／削除／更新する方法、クライアントＰＣがデバイスを検索する方法については上述した実施例と同じである。すなわち、クライアントＰＣがデバイスを検索するためのメッセージをＤＰに送信し、ＤＰはクライアントＰＣが送信したメッセージの送信元アドレスを取得してサブネットを検出し、前記検出したサブネットと登録されているデバイスのサブネットを照合し、サブネットが一致しているか、もしくはサブネットが一致せずにクライアントＰＣが存在するサブネットからの検索が許可されているか否かを属性値を基に判定し、検索が可能であればその情報を含めてＰｒｏｂｅＭａｔｃｈを返信する。
【００６０】
本構成例において、属性値に設定できるものとして、クライアントＰＣのネットワーク上の位置を特定する識別子であればサブネット情報でなくてもかまわない。そのような識別子としてサブネットの他に、ＩＰアドレス、ＩＰアドレスの範囲、ＭＡＣアドレス、マルチキャストアドレス、ブロードキャストアドレス、などが考えられる。
【００６１】
図１５は、本実施例におけるＤＰ１０２において実行されるデバイス検索処理を示すフローチャートである。図１５に示す各ステップは、ＤＰ１０２のＣＰＵ２６０１が、ＲＯＭ２６０２又はＨＤ２６１１に格納されたプログラムをＲＡＭ２６０３に展開して実行することによって処理される。
【００６２】
ステップＳ１５０１において、ＤＰ１０２は、外部装置としてのクライアントＰＣから送られた検索要求（Ｐｒｏｂｅメッセージ）を受信する。ステップＳ１５０２において、ＣＰＵは、受信したＰｒｏｂｅメッセージを解釈し、検索条件を抽出する。例えば、ＰｒｏｂｅメッセージのなかのＴｙｐｅｓタグに記述された「Ｐｒｉｎｔｅｒ」を検索条件として抽出する。
【００６３】
ステップＳ１５０３において、ＣＰＵは、デバイス情報保持部５１４によって保持されているデバイス情報テーブルを参照する。そして、ステップＳ１５０４において、ＣＰＵは、デバイス情報テーブルに含まれる複数のデバイス情報と、抽出された検索条件とを比較し、検索条件を満たすデバイスが存在するか否かを判断する。検索条件を満たすデバイスがある場合にはステップＳ１５０５へと進み。ない場合にはステップＳ１５１４へと進む。
【００６４】
ステップＳ１５０５において、ＣＰＵは、検索結果テーブルを作成する。検索結果テーブルは、デバイス情報テーブルに含まれるデバイス情報のうち、受信した検索条件を満たすデバイス情報によって構成される。検索結果テーブルには、少なくとも１つ以上のデバイス情報が登録されることになる。ステップＳ１５０６において、ＣＰＵは、検索要求（Ｐｒｏｂｅメッセージ）を送信したクライアントＰＣが存在するサブネットを取得する。具体的には、ＣＰＵは、ステップＳ１５０１において受信した検索要求を送信した送信元のＩＰアドレスと、サブネットマスクから、ネットワークアドレスを算出し、それによってサブネットを取得する。
【００６５】
その後、ステップＳ１５０７において、ＣＰＵは、作成した検索結果テーブルを参照する。ステップＳ１５０８において、検索結果テーブルに含まれる全てのデバイス情報がチェックされたか判断し、チェックされていない場合にはステップＳ１５０９へと進む。一方、全てのデバイス情報をチェックした場合には、ステップＳ１５１４へと進む。具体的には、チェック済みのデバイス情報には、チェック済みであることを示すフラグを立て、検索結果テーブル内の全てのデバイス情報に、このフラグが立っているかどうかを判断するようにしてもよい。ステップＳ１５０９において、ＣＰＵは、検索結果テーブルから、１つのデバイス情報を抽出する。ステップＳ１５１０において、ＣＰＵは、抽出されたデバイス情報の属性値を参照し、属性値が「Ｐｕｂｌｉｃ」であるか否かを判断する。Ｐｕｂｌｉｃであると判断された場合にはステップＳ１５１１へと進み、このデバイス情報を、検索結果としてクライアントＰＣに送信するために、Ｐｒｏｂｅ  Ｍａｔｃｈに追加する。そして、ステップＳ１５０８へと戻り、処理を続ける。一方、ステップＳ１５１０において、Ｐｕｂｌｉｃでないと判断された場合。即ち、属性値がＰｒｉｖａｔｅであった場合にはステップＳ１５１２へと進む。ステップＳ１５１２において、ＣＰＵは、現在抽出されているデバイス情報に含まれるＩＰアドレスに基づいて、このデバイスのサブネットを取得する。具体的には、デバイス情報に含まれるＩＰアドレスとサブネットマスクから、ネットワークアドレスを算出し、それによってサブネットを取得する。ステップＳ１５１３において、ＣＰＵは、ステップＳ１５０６において取得したサブネットと、ステップＳ１５１２において取得したサブネットとが同じであるか否かを判断する。即ち、検索要求の送信元であるクライアントＰＣとデバイスとが、同一サブネットに存在しているか否かを判断する。その結果、サブネットが同じであると判断された場合にはステップＳ１５１１へと進み、そのデバイス情報をＰｒｏｂｅ  Ｍａｔｃｈについてする。一方、サブネットが異なる場合には、Ｐｒｏｂｅ  Ｍａｔｃｈには追加せずに、ステップＳ１５０８へと戻る。
【００６６】
ステップＳ１５０８において、検索結果テーブルに含まれる全てのデバイス情報をチェックした場合にはステップＳ１５１４へと進む。ステップＳ１５１４において、ＣＰＵは、Ｐｒｏｂｅ  Ｍａｔｃｈを作成する。検索条件を満たし、且つＰｕｂｌｉｃ属性或いは同一サブネットに存在するデバイスが見つかった場合には、Ｐｒｏｂｅ  Ｍａｔｃｈには、そのデバイスのデバイス情報が含まれる。一方、検索条件を満たすデバイスが見つからなかった場合や、Ｐｕｂｌｉｃ属性や同一サブネットに存在するデバイスがなかった場合には、その旨を示すＰｒｏｂｅ  Ｍａｔｃｈが作成される。ステップＳ１５１５において、ＤＰは、作成したＰｒｏｂｅ  Ｍａｔｃｈを、Ｐｒｏｂｅを送信した送信元のクライアントＰＣに送信する。
【００６７】
尚、Ｐｒｏｂｅ  Ｍａｔｃｈの作成方法として、次のようなものであってもよい。検索結果テーブルに含まれるデバイス情報の中から、Ｐｒｉｖａｔｅ属性で且つ検索要求の送信元と同一サブネットに存在しないデバイスを抽出し、これらを検索結果テーブルから削除する。そして、最終的に生成された検索結果テーブルに基づいて、Ｐｒｏｂｅ  Ｍａｔｃｈを作成する。
【００６８】
以上説明したように、本実施例によれば、デバイスの情報をサーバに登録するにあたって、そのデバイスが、特定のグループに属する装置からのみ検索されるように登録することができる。グループの単位としては、サブネットに限らず、物理的な場所に基づく位置情報（同じ部屋、同じ建物等）やその他の情報であっても構わない。
【００６９】
（実施例２）
図１７は第２の実施例におけるネットワーク検索システムを示した図である。
【００７０】
本実施例においては、第１の実施例と異なり、ＤＰが、ネットワーク上に一台のみ存在するのではなく、各サブネットにＤＰを配置する。また、一台のＤＨＣＰサーバによって管理される対象となるネットワーク上に１台、特定のＤＰを配置する。本実施例では、このＤＰを親ＤＰと呼び、各サブネットにそれぞれ配置されたＤＰと区別する。
【００７１】
図１７に示すネットワークシステムには、サブネット１とサブネット２、サブネット３が存在している。サブネット１には、ＤＰ１０１０、ＤＨＣＰサーバ１０１が接続される。ＤＰ１０１０は、本実施例において親ＤＰである。サブネット２には、ＤＰ１０２、クライアントＰＣ１０３、画像形成装置１０４が接続される。サブネット３には、ＤＰ１０９、クライアントＰＣ１０８、画像形成装置１０５が接続される。
【００７２】
サブネット１とサブネット２はルータ１０６により相互に接続され、サブネット１とサブネット３はルータ１０７により相互に接続されており、結果としてすべてのサブネットにおいて接続された端末は相互に通信が可能になっている。ただし、ルータ１０６、１０７は一方のサブネットから受信したブロードキャストやマルチキャストを他方のサブネットにそのまま通過させることはしない。そのため、ブロードキャストやマルチキャストによる通信は各サブネット内でのみ可能である。
【００７３】
尚、特に断らない限り、各ＤＰのハードウェア構成や画像形成装置、クライアントＰＣのハードウェア構成は、実施例１で説明したものと同様である。
【００７４】
図１８は、本実施形態におけるＤＨＣＰサーバ１０１、ＤＰ１０２、クライアントＰＣ１０３、画像形成装置１０４のソフトウェア構成を示すブロック図である。実施例１における図５と異なるのは、ＤＰ１０２にデバイス属性保持部、検索クライアントのサブネット検知部、デバイス属性判定部が存在しない点である。
【００７５】
実施例１では、ＤＰで実行される検索処理において、ＰｒｏｂｅＭａｔｃｈに含むデバイス情報を変えていた。これに対して、実施例２では、各画像形成装置において、自身のデバイス情報を登録するＤＰを切り換えることによって、デバイスが特定のグループのクライアントＰＣのみに検索されるようなシステムを提供する。
【００７６】
次に、本実施例における、ネットワーク上の各ＤＰが保持するデバイス情報テーブルの一例を示す。本実施例では各画像形成装置は、自身が存在するサブネット上のＤＰと、親ＤＰであるＤＰ１０１０に対してのみ、デバイス情報の登録を行う。ただし、親ＤＰ１０１０に対して登録するのはｐｕｂｌｉｃ属性が設定された画像形成装置のみである。本実施例においては画像形成装置１０４の属性をｐｕｂｌｉｃとし、画像形成装置１０５の属性をｐｒｉｖａｔｅとしている。
【００７７】
図１９は親ＤＰであるＤＰ１０１０のデバイス情報保持部５１４が保持するデバイス情報テーブルの例である。実施例１と異なり、本実施例ではＤＰ１０１０は全てのサブネット上のｐｕｂｌｉｃ属性を持ったデバイスのデバイス情報のみを管理する。また、実施例１と異なり、ＤＰはデバイスの属性値を保持していない。図１９の例では、デバイス情報１０５は、画像形成装置１０５のデバイス情報を示している。残りのデバイス情報は、図１７において不図示の画像形成装置のデバイス情報である。この画像形成装置にも、Ｐｕｂｌｉｃ属性が設定されていることになる。
【００７８】
図２０はＤＰ１０２のデバイス情報保持部５１４が保持するデバイス情報テーブルの例である。実施例１と異なり、本実施例では、ＤＰ１０２のデバイス情報テーブルには同一サブネットに存在する画像形成装置１０４のデバイス情報しか登録されていない。図２０の例では、デバイス情報１０４は、画像形成装置１０４のデバイス情報を示している。
【００７９】
図２１はＤＰ１０２のデバイス情報保持部５１４が保持するデバイス情報テーブルの例である。実施例１と異なり、本実施例では、ＤＰ１０９のデバイス情報テーブルには同一サブネットに存在する画像形成装置１０５のデバイス情報しか登録されていない。図２１の例では、デバイス情報１０５は、画像形成装置１０５のデバイス情報を示している。
【００８０】
次に、画像形成装置１０４のデバイス情報をＤＰ１０２、１０１０に登録する方法について説明する。
【００８１】
画像形成装置１０４は、ＤＨＣＰサーバ１０１から、自機のＩＰアドレスに加えＤＰ１０２とＤＰ１０１０のＩＰアドレスを受信している。本実施例では、ＤＨＣＰサーバ１０１は、画像形成装置１０４に対してＩＰアドレスを割り当てるにあたって、画像形成装置１０４のサブネットを認識する。そして、画像形成装置１０４が存在するサブネットと同じサブネットに存在するＤＰ（ＤＰ１０２）と親ＤＰ（ＤＰ１０１０）のＩＰアドレスを、画像形成装置１０４に対して通知する。但し、ＤＨＣＰサーバ１０１が、画像形成装置１０４が存在するサブネットを判断せず、ネットワーク上の全てのＤＰのＩＰアドレスを通知するようにしてもよい。
【００８２】
画像形成装置１０４は、ＤＰ１０２とＤＰ１０１０に対して図７のようなＸＭＬ形式のＨｅｌｌｏメッセージをユニキャストで送信することにより存在を通知する。図７のＨｅｌｌｏメッセージにおいては、ＸＡｄｄｒｓタグにおいて、画像形成装置のデバイス情報を取得可能なＵＲＬが記載されている。
【００８３】
ＤＰ１０２とＤＰ１０１０はＨｅｌｌｏメッセージの中からデバイスをグローバルに識別するＵＵＩＤとしてＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅ／Ａｄｄｒｅｓｓタグの値、デバイスタイプとしてＴｙｐｅｓタグの値、デバイス情報のバージョンとしてＭｅｔａｄａｔａＶｅｒｓｉｏｎタグの値、デバイス情報を取得するためのＵＲＬとしてＸＡｄｄｒｓタグの値を抽出してデバイス情報保持部５１４に格納する。
【００８４】
その後ＤＰ１０２とＤＰ１０１０はＸＡｄｄｒｓタグで記載されたＵＲＬに対し、図８のようなＸＭＬ形式のＧｅｔメッセージをユニキャストで送信する。
【００８５】
画像形成装置１０４のデバイス情報送信部５３５は図９のようなデバイス情報を送信する。しかし、ここで送信されるデバイス情報には、図９に示す＜ＤｅｖｉｃｅＡｔｔｒｉｂｕｔｅ＞タグは含まれていない。即ち、実施例２では、画像形成装置は、ＤＰから送られるＧｅｔメッセージに対する応答として、＜ＤｅｖｉｃｅＡｔｔｒｉｂｕｔｅ＞タグがない、図９の形式の応答を送信する。
【００８６】
ＤＰ１０２は受信したデバイス情報からデバイス名としてＦｒｉｅｎｄｌｙＮａｍｅタグの値、モデル名としてＭｏｄｅｌＮａｍｅタグの値を抽出し、デバイス情報保持部５１４に格納する。
【００８７】
なお、画像形成装置１０４は、画像形成装置が起動した場合や自機の設定情報が変更された場合にＨｅｌｌｏメッセージをＤＰ１０２とＤＰ１０１０にユニキャストで送信する。ＤＰ１０２とＤＰ１０１０はＨｅｌｌｏメッセージを受信するたびに上記のようにデバイス情報を取得してもよいが、以前に取得したデバイス情報がデバイス情報保持部５１４に存在している場合には、Ｈｅｌｌｏメッセージに含まれるバージョン情報を比較し、変更がなければ、あらたにデバイス情報を取得しなおさなくてもよい。
【００８８】
また、画像形成装置１０５についても同様の処理が行われる。すなわち、画像形成装置１０５はＤＰ１０９とＤＰ１０１０に登録する。ＤＰ１０９とＤＰ１０１０における処理は上述の処理と同じである。
【００８９】
ＤＰ１０２、１０９、１０１０に登録された画像形成装置の登録情報を削除する方法については実施例１と同じである。
【００９０】
次に、クライアントＰＣ１０３がＤＰ１０２とＤＰ１０１０を使用して画像形成装置を検索する方法について説明する。
【００９１】
クライアントＰＣ１０３は、ＤＨＣＰサーバ１０１から、自機のＩＰアドレスに加えＤＰ１０２とＤＰ１０１０のＩＰアドレスを受信している。
【００９２】
クライアントＰＣ１０３は、ＤＰ１０２とＤＰ１０１０に対して図１１のようなＸＭＬ形式のＰｒｏｂｅメッセージをユニキャストで送信する。図１１のＰｒｏｂｅメッセージにおいては、画像形成装置を検索する検索条件の一例として、Ｔｙｐｅｓタグにおいて「Ｐｒｉｎｔｅｒ」を指定している。
【００９３】
ＤＰ１０２とＤＰ１０１０はＰｒｏｂｅメッセージを受信すると、Ｔｙｐｅｓタグを抽出しデバイス情報保持部５１４の中から検索条件に合致するデバイスを探し、図１２のようなＰｒｏｂｅＭａｔｃｈメッセージをクライアントＰＣ１０３に送信する。
【００９４】
クライアントＰＣ１０３はＰｒｏｂｅＭａｔｃｈメッセージの中からＸＡｄｄｒｓタグで記載されたＵＲＬを抽出し、図８のようなＧｅｔメッセージをユニキャストで送信する。本実施例において、ＵＲＬは画像形成装置１０４のＩＰアドレスからなっており、ＧｅｔメッセージはＤＰ１０２やＤＰ１０１０ではなく画像形成装置１０４に直接送信する。画像形成装置１０４は図９のようなデバイス情報を送信し、クライアントＰＣ１０３は必要な情報を抽出する。ＰｒｏｂｅＭａｔｃｈメッセージに複数の検索結果が存在している場合にはクライアントＰＣ１０３はＧｅｔメッセージの送信を繰り返し、すべてのデバイス情報を取得する。
【００９５】
本実施例において、クライアントＰＣ１０３が取得できるのはネットワーク上の全ての画像形成装置となる。また、クライアントＰＣ１０８がＤＰ１０９とＤＰ１０１０を使用して画像形成装置を検索する方法も上述した方法と同じであり、この場合は画像形成装置１０４以外の画像形成装置しか検索できない。
【００９６】
図２２は、本実施例における画像形成装置１０３、１０８において実行される処理を示すフローチャートである。具体的には、画像形成装置が、ＤＰからＧｅｔメッセージを受け取り、自身のデバイス情報をＤＰに送信するまでの処理を示している。図２２の各ステップは、画像形成装置のＣＰＵ４０２が、ＲＯＭ４０３やＨＤＤ４０５に格納されたプログラムをＲＡＭ４０４に展開して実行することによって処理される。
【００９７】
ステップＳ２２０１において、画像形成装置は、ＤＰから送信されたＧｅｔメッセージを受信する。画像形成装置は、予め、ＤＨＣＰサーバから自身のＩＰアドレスが割り当てられた際に、同時に、ＤＰのＩＰアドレスを取得している。ここで、予め取得しているＤＰのアドレスには、自身と同一のサブネットに存在するＤＰのＩＰアドレスと、親ＤＰのＩＰアドレスとがある。画像形成装置は、これらのアドレスをＤＰのリストとしてメモリに保持している。ステップＳ２２０２では、メモリから、このＤＰのリストを取得する。
【００９８】
ステップＳ２２０３において、ＣＰＵは、Ｇｅｔメッセージの送信元のＩＰアドレスと、ＤＰのリストとを比較して、Ｇｅｔメッセージを送信したＤＰが親ＤＰであるか否かを判断する。親ＤＰであると判断された場合、ステップＳ２２０４へと進む。一方、親ＤＰでないと判断された場合にステップＳ２２０７へと進む。
【００９９】
ステップＳ２２０４において、ＣＰＵは、画像形成装置自身の属性値をメモリから取得する。そして、ステップＳ２２０５において、取得した属性値が「Ｐｕｂｌｉｃ」であるか否かを判断する。Ｐｕｂｌｉｃであると判断された場合には、ステップＳ２２０６へと進み、Ｇｅｔメッセージに対する応答として、自身のデバイス情報をＤＰへと送信する。
【０１００】
ステップＳ２２０５において、Ｐｕｂｌｉｃ属性であると判断されなかった場合、即ち、Ｐｒｉｖａｔｅ属性であると判断された場合、ステップＳ２２０８へと進む。ステップＳ２２０８では、Ｇｅｔメッセージに対する応答として、エラーを示す情報をＤＰに送信する。これにより、自身がＰｒｉｖａｔｅ属性である場合に、自身のデバイス情報が親ＤＰへ登録されてしまうことを防ぐことができる。
【０１０１】
ステップＳ２２０３において、親ＤＰではないと判断された場合、ステップＳ２２０７へと進む。ステップＳ２２０７において、ＣＰＵは、Ｇｅｔメッセージの送信元のＤＰが、自身と同じサブネットに存在するＤＰであるか否かを判断する。具体的には、ＣＰＵは、Ｇｅｔメッセージの送信元のＤＰのＩＰアドレスが、ステップＳ２２０２で取得したＤＰのリストに含まれており、且つ親ＤＰではないか判断する。リストに含まれており、且つ親ＤＰではない場合には、そのＤＰは、画像形成装置自身と同じサブネットに存在するＤＰである。この場合には、ステップＳ２２０６へと進み、自身のデバイス情報をそのＤＰへ送信する。一方、同じサブネットに存在しないと判断された場合にはステップＳ２２０８へと進む。このように、Ｇｅｔメッセージを送信したＤＰが、自身と同じサブネットに存在する場合には、自身の属性値がＰｕｂｌｉｃであるかＰｒｉｖａｔｅであるかに関わらず、自身のデバイス情報を送信することになる。
【０１０２】
以上説明したように本実施例によれば、第１の実施例と同様に、デバイスの情報をサーバに登録するにあたって、そのデバイスが、特定のグループに属する装置からのみ検索されるように登録することができる。特に、本実施例では、サーバからの情報の要求に対して、デバイス側でデバイス情報を送信する／しないを判断するので、サーバ側で特別な処理を行う必要がない。
【０１０３】
尚、上記実施例では、画像形成装置の属性値がＰｕｂｌｉｃであっても、自身と異なるサブネットに存在するＤＰに対してはデバイス情報を送信していない。Ｐｕｂｌｉｃ属性であった場合には、自身と異なるサブネットに存在するＤＰに対してもデバイス情報を送信するようにしてもよい。
【０１０４】
（その他の実施例）
上記実施例では、画像形成装置とＤＰとして動作する情報処理装置とをそれぞれ別の装置として説明したが、これらが１つの装置として提供されても良い。即ち、例えば図１の例において、ＤＰ１０２の機能を画像形成装置１０４又は画像形成装置１０５が備えていてもよい。同様に、クライアントＰＣが上記実施例におけるＤＰの機能を備えていてもよい。又は、上記実施例における画像形成装置とクライアントＰＣが１つの装置によって提供されてもよい。
【０１０５】
また、本発明は、前述した実施例のフローチャートを実現するソフトウェアのコンピュータプログラムコードを記録した記憶媒体を、システムあるいは装置に供給してもよい。そして、そのシステムあるいは装置のコンピュータ（ＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても達成され得る。
【０１０６】
この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【０１０７】
プログラムコードを供給するための記憶媒体としては、例えば、フロッピディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＤＶＤ−ＲＯＭ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどを用いることができる。
【図面の簡単な説明】
【０１０８】
【図１】本実施例におけるネットワーク検索システムの構成を示す図
【図２】ＤＨＣＰサーバとＤＨＣＰクライアントとの間で送受信されるＤＨＣＰメッセージのフローを説明する図
【図３】ＤＨＣＰメッセージのフォーマットを示す図
【図４】画像形成装置のハードウェア構成を示すブロック図
【図５】ＤＨＣＰサーバ、ＤＰ、クライアントＰＣ、画像形成装置のソフトウェア構成を示すブロック図
【図６】ＤＰのデバイス情報保持部が保持するデバイス情報の例
【図７】本実施例におけるＨｅｌｌｏメッセージの例
【図８】本実施例におけるＧｅｔメッセージの例
【図９】本実施例におけるＧｅｔＲｅｓｐｏｎｓｅメッセージの例
【図１０】本実施例におけるＢｙｅメッセージの例
【図１１】本実施例におけるＰｒｏｂｅメッセージの例
【図１２】本実施例におけるＰｒｏｂｅＭａｔｃｈメッセージの例
【図１３】クライアントＰＣが画像形成装置を検索する際のＵＩの例を示す図
【図１４】ＤＰのデバイス情報保持部が保持するデバイス情報の例
【図１５】ＤＰにおけるデバイス検索処理を示すフローチャート
【図１６】ＤＨＣＰサーバ１０１、ＤＰ１０２、クライアントＰＣ１０３のハードウェア構成を示すブロック図
【図１７】実施例２におけるネットワーク検索システムの構成を示す図
【図１８】実施例２におけるＤＨＣＰサーバ、ＤＰ、クライアントＰＣ、画像形成装置のソフトウェア構成を示すブロック図
【図１９】実施例２における親ＤＰのデバイス情報保持部が保持するデバイス情報の例
【図２０】実施例２におけるＤＰのデバイス情報保持部が保持するデバイス情報の例
【図２１】実施例２におけるＤＰのデバイス情報保持部が保持するデバイス情報の例
【図２２】実施例２における画像形成装置において実行される処理を示すフローチャート
【符号の説明】
【０１０９】
１６０１  ＣＰＵ
１６０２  ＲＯＭ
１６０３  ＲＡＭ
１６０５  ＫＢＣ
１６０６  ＣＲＴＣ
１６０７  ＤＫＣ
１６０８  ＮＩＣ
【図１】
0004542165.tif 000002
【図２】
0004542165.tif 000003
【図３】
0004542165.tif 000004
【図４】
0004542165.tif 000005
【図５】
0004542165.tif 000006
【図６】
0004542165.tif 000007
【図７】
0004542165.tif 000008
【図８】
0004542165.tif 000009
【図９】
0004542165.tif 000010
【図１０】
0004542165.tif 000011
【図１１】
0004542165.tif 000012
【図１２】
0004542165.tif 000013
【図１３】
0004542165.tif 000014
【図１４】
0004542165.tif 000015
【図１５】
0004542165.tif 000016
【図１６】
0004542165.tif 000017
【図１７】
0004542165.tif 000018
【図１８】
0004542165.tif 000019
【図１９】
0004542165.tif 000020
【図２０】
0004542165.tif 000021
【図２１】
0004542165.tif 000022
【図２２】
0004542165.tif 000023