JP5528124B2 - デバイス検索装置、デバイス検索方法並びにプログラム - Google Patents

Description

本発明は、ネットワークを介して画像形成装置等のデバイスを検索するデバイス検索装置、デバイス検索方法並びにプログラムに関する。

従来、クライアントＰＣからネットワークを介して画像形成装置等のデバイスを利用することが可能になっている。その際、クライアントＰＣは、ネットワーク上のデバイスを検索し、検索したデバイスを利用するためのドライバソフトウェアをインストールする必要がある。これら一連の処理を実行するための技術として、マイクロソフト社がＷＳＤ（Web Services on Devices）を提案している。ＷＳＤにおいて、ネットワーク上のデバイスを検索する際に、WS-Discovery仕様が使用されている。

また、クライアントＰＣが、マルチキャストによりＤＰ（Discovery Proxy）サーバに対してデバイス検索を行い、ＤＰサーバが保持しているデバイス情報を検索結果として返すデバイス検索システムが提案されている。また、ＯＡＳＩＳが提唱しているWS-Discovery仕様には、クライアントＰＣからＤＰサーバに対してＤＰサーバ検索を行い、ＤＰサーバが保持しているＤＰサーバ情報を検索結果として返す方法がある（※ＯＡＳＩＳ：Organization for the Advancement of Structured Information Standards）。

ところで、ネットワーク技術の発展に伴い、ネットワーク同士がルータなどの接続機器により相互に接続され、大規模なネットワークを構築することが可能になっている。その中で、ブロードキャストやマルチキャストは、ネットワーク全体のトラフィックに影響を与えるため、一般にルータはこれらを通過させない設定で運用される。ルータによって区切られたそれぞれのネットワークはサブネットと呼ばれ、ブロードキャストやマルチキャストは一般にサブネット内のみで利用されている。

従来のネットワークデバイス検索技術では、マルチキャストを使用しているので、クライアントＰＣが送信した検索要求パケットがルータを通過できない場合が多い。そのため、複数のサブネットがルータによって接続されたネットワーク環境において、クライアントＰＣが異なるサブネットに存在するデバイスを発見することは難しかった。こうした課題を解決するために、サブネットごとにサーバを設置し、サーバ間でデバイス情報や検索要求の交換を行う技術が提案されている（例えば、特許文献１参照）。

特開２００７−９７０５７号公報

しかしながら、上記従来の技術では、サーバが、異なるサブネット上のサーバにクライアントＰＣからのデバイス検索要求を転送する処理が必要である。デバイス検索要求に対する検索応答に対しても同様に、サーバがクライアントＰＣへ異なるサブネットのサーバからの検索応答を転送する処理が必要である。

また、サーバが自動で異なるサブネット上のサーバへ検索要求を転送するため、クライアントＰＣは、デバイスを検索したいサブネットのサーバを選択できないという問題がある。

本発明は、上記問題に鑑みてなされたものであり、その目的は、複数のサブネットがルータにより接続された大規模なネットワーク環境において、ユーザが、デバイス検索したいサブネットに存在するデバイスの情報を容易且つ速やかに入手することを可能とする技術を提供することにある。

上記目的を達成するために、本発明のデバイス検索装置は、マルチキャストによる通信を各サブネット内でのみ可能とするルータを介して接続される、第１のサブネット及び第２のサブネットを含むネットワーク上の、前記第１のサブネット上にあるデバイス検索装置であって、デバイス検索サーバの検索を要求する第１のメッセージを前記第１のサブネット上にある第１のデバイス検索サーバにマルチキャストで送信し、前記第１のデバイス検索サーバから受信した第２のメッセージの中から、前記前記第２のサブネット上にある第２のデバイス検索サーバを含むデバイス検索装置のＵＲＬを抽出し、当該ＵＲＬが抽出されたデバイス検索サーバの名称をユーザ選択可能に表示する第１の制御手段と、前記第１の制御手段により表示された前記複数のデバイス検索サーバの名称の中から前記第２のデバイス検索サーバの名称がユーザ選択された場合、当該第２のデバイス検索サーバのＵＲＬに基づいて、前記第２のサブネット上にあるデバイスの検索を要求する第３のメッセージを前記第２のデバイス検索サーバにユニキャストで送信し、前記第２のデバイス検索サーバから受信した第４のメッセージの中から前記第２のサブネット上にある前記デバイスのＵＲＬを抽出する第２の制御手段と、前記第４のメッセージから抽出したＵＲＬに基づいて、前記第２のサブネット上にある前記デバイスのデバイス情報を要求する第５のメッセージを、当該デバイスにユニキャストで送信し、前記デバイスから返信された返信メッセージから前記デバイスのデバイス情報を取得する第３の制御手段と、を備えることを特徴とする。

本発明によれば、複数のサブネットがルータにより接続されたネットワーク環境において、クライアントＰＣが異なるサブネットに存在するデバイスを容易に検索することを可能となる。

本発明の実施形態に係るデバイス検索システムの構成例を示す図である。 図１におけるデバイスのハードウェア構成を示すブロック図である。 図１におけるＤＰサーバ、クライアントＰＣのハードウェア構成を示すブロック図である。 デバイス、ＤＰサーバ、クライアントＰＣのソフトウェア構成を示すブロック図である。 ＤＰサーバにおける、他のサブネット上のＤＰサーバの情報を登録する際のＵＩの一例を示す図である。 クライアントＰＣにおける、デバイスを検索する際のＵＩの一例を示す図である。 クライアントＰＣにおける、デバイス検索要求を送信するＤＰサーバを選択する際のＵＩの一例を示す図である。 ＤＰサーバ１のデバイス／ＤＰサーバ情報保持部が保持するデバイス／ＤＰサーバ情報の一例を示す図である。 デバイスがマルチキャストで送信するＨｅｌｌｏメッセージの一例を示す図である。 デバイスが送信するＧｅｔＲｅｓｐｏｎｓｅメッセージの一例を示す図である。 （ａ）はクライアントＰＣがマルチキャストで送信するＰｒｏｂｅメッセージの一例を示す図、（ｂ）はＤＰサーバからクライアントＰＣに送信されるＰｒｏｂｅＭａｔｃｈメッセージの一例を示す図である。 （ａ）はクライアントＰＣがユニキャストで送信するＰｒｏｂｅメッセージの一例を示す図、（ｂ）はＤＰサーバからクライアントＰＣに送信されるＰｒｏｂｅＭａｔｃｈメッセージの一例を示す図である。 デバイス検索時にＤＰサーバで実行される処理を示すフローチャートである。 デバイス検索時にクライアントＰＣで実行される処理を示すフローチャートである。 第２の実施形態においてクライアントＰＣからマルチキャストで送信されるＰｒｏｂｅメッセージの一例を示す図である。 ＤＰサーバから送信されるＨｅｌｌｏメッセージの一例を示す図である。 第２の実施形態におけるデバイス検索時のＤＰサーバで実行される処理を示すフローチャートである。 第２の実施形態におけるデバイス検索時のクライアントＰＣで実行される処理を示すフローチャートである。 第３の実施形態において、ＤＰサーバからクライアントＰＣに送信されるＰｒｏｂｅＭａｔｃｈメッセージの一例を示す図である。 第３の実施形態におけるデバイス検索時のクライアントＰＣで実行される処理を示すフローチャートである。 第４の実施形態においてＤＰサーバからクライアントＰＣに送信されるＰｒｏｂｅＭａｔｃｈメッセージの一例を示す図である。 第４の実施形態におけるデバイス検索時のＤＰサーバで実行される処理を示すフローチャートである。 第４の実施形態におけるデバイス検索時のクライアントＰＣで実行される処理を示すフローチャートである。

以下、本発明の実施の形態を図面を参照して詳細に説明する。

［第１の実施形態］
図１は、本発明の実施形態に係るデバイス検索システムの構成例を示す図である。

図１において、デバイス１０１、Discovery Proxy（ＤＰ）サーバ１０２、クライアントＰＣ１０３が接続されたサブネット１は、デバイス１０４、ＤＰサーバ１０５が接続されたサブネット２とルータ１０８を介して相互に接続されている。また、サブネット１は、デバイス１０６、ＤＰサーバ１０７が接続されたサブネット３とルータ１０９を介して相互に接続されている。全てのサブネットに接続された端末は、相互に通信が可能になっている。なお、ルータ１０８，１０９は、一方のサブネットから受信したブロードキャストやマルチキャストを他方のサブネットにそのまま転送することはしない。そのため、ブロードキャストやマルチキャストによる通信は各サブネット内でのみ可能である。

次に、画像形成装置等のデバイス１０１，１０４，１０６、デバイス検索サーバとしてのＤＰサーバ１０２，１０５，１０７、デバイス検索装置としてのクライアントＰＣ１０３のハードウェア及びソフトウェア構成について説明する。なお、デバイス１０１，１０４，１０６は、同一のハードウェア及びソフトウェア構成を有することから、デバイス１０１を用いて説明する。ＤＰサーバ１０２，１０５，１０７は、同一のハードウェア及びソフトウェア構成を有することから、ＤＰサーバ１０２を用いて説明する。

図２は、図１におけるデバイス１０１のハードウェア構成を示すブロック図である。なお、ここでは、ＭＦＰを例にして説明する。

図２のデバイス１０１において、ＣＰＵ２０１は、ＲＯＭ２０３に確保されたプログラム用ＲＯＭに記憶された制御プログラムに基づいて、システムバス２０４に接続される各部とのアクセスを総括的に制御する。また、ＣＰＵ２０１は、印刷インターフェース（Ｉ／Ｆ）２０７を介して接続される印刷部（プリンタエンジン）２１０に出力情報としての画像信号を出力したり、読取Ｉ／Ｆ２１２を介して接続される読取部（スキャナ）２１３から入力される画像信号を制御する。

また、ＲＯＭ２０３に確保されたプログラム用ＲＯＭには、ＣＰＵ２０１が実行可能な制御プログラム等が記憶されている。さらに、ＲＯＭ２０３に確保されたフォント用ＲＯＭには、上記出力情報を生成する際に使用するフォントデータ（アウトラインフォントデータを含む）等が記憶されている。ＲＯＭ２０３に確保されたデータ用ＲＯＭには、デバイス１０１上で利用される情報等が記憶されている。ＣＰＵ２０１は、ＬＡＮコントローラ２０６を介してネットワーク上の各装置との通信処理が可能となっている。

ＲＡＭ２０２は、主としてＣＰＵ２０１の主メモリ、ワークエリア等として機能し、図示しない増設ポートに接続されるオプションＲＡＭによりメモリ容量を拡張できるように構成されている。また、ＲＡＭ２０２には、出力情報を展開するための出力情報展開領域や、環境データを格納するための環境データ格納領域等が設けられている。

外部記憶装置２１１は、ハードディスク（ＨＤＤ）、ＩＣカード等から成り、ディスクコントローラ（ＤＫＣ）２０８によりアクセスが制御される。外部記憶装置２１１は、フォントデータ、エミュレーションプログラム、フォームデータ等を記憶したり、プリントジョブを一時的にスプールし、スプールされたジョブを外部から制御するためのジョブ格納領域として使用される。また、外部記憶装置２１１は、スキャナ２１３から読み取った画像データやプリントジョブの画像データをＢＯＸデータとして保持し、ネットワークから参照したり、印刷を行うＢＯＸデータ格納領域としても使用される。なお、外部記憶装置２１１は、１個に限らず、複数個で構成されていてもよい。また、ＤＫＣ２０８には、内蔵フォントに加えてオプションフォントカード、言語系の異なるプリンタ制御言語を解釈するプログラムを格納した外部メモリを複数接続できるように構成されていてもよい。

操作パネル２０５は、ユーザがソフトウェアキーから各種情報を入力することが可能なタッチパネル等から成る。不揮発性メモリ２０９は、操作パネル２０５から設定される各種設定情報を記憶する。

なお、デバイス１０１には、オプションとして、ステープルやソート機能を行うフィニッシャや両面印刷機能を実現するための両面装置など各種拡張装置を装着することが可能となっており、それらの動作はＣＰＵ２０１から制御される。

図３は、図１におけるＤＰサーバ１０２、クライアントＰＣ１０３のハードウェア構成を示すブロック図である。なお、ＤＰサーバ１０２、クライアントＰＣ１０３は、汎用のＰＣ（パーソナルコンピュータ）で構成されていることから、図示例では、ＤＰサーバ１０２を用いて説明する。

図３において、ＣＰＵ３０１は、ＲＯＭ３０２やハードディスク（ＨＤ）３１１に記憶されたプログラムに基づいて、後述する処理を実行する。ＲＡＭ３０３は、ＣＰＵ３０１の主記憶装置として使用される。キーボードコントローラ（ＫＢＣ）３０５は、ポインティングデバイス（ＰＤ）３０９ａ、キーボード（ＫＢ）３０９ｂからの情報などの入力に係る処理を行う。表示制御部（ＣＲＴＣ）３０６は、内部にビデオメモリを有し、ＣＰＵ３０１からの指示に従ってそのビデオメモリに描画すると共に、ビデオメモリに描画されたイメージデータをビデオ信号として表示装置（ＣＲＴ）３１０に出力する。なお、表示装置としてＣＲＴ（Cathode Ray Tube）を例示しているが、液晶モニタであってもよく、表示装置の種類は問わない。

ディスクコントローラ（ＤＫＣ）３０７は、ＨＤ３１１、フロッピー（登録商標）ディスク３１２へのアクセスを行う。なお、ＨＤ３１１には、ＯＳ（Operating System）やＯＳ上で動作する各種アプリケーションプログラム等が格納される。

ネットワークインタフェースカード（ＮＩＣ）３０８は、ネットワークに接続するためのインターフェースであり、ネットワーク上の他の装置との通信を制御する。

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

図４は、デバイス１０１、ＤＰサーバ１０２、クライアントＰＣ１０３のソフトウェア構成を示すブロック図である。

デバイス１０１において、デバイス情報管理部４１１はデバイス１０１自身のデバイス情報を管理する。デバイス情報には、例えば、デバイス名やモデル名等が含まれる。具体的なデバイス情報の例は、図８を用いて後述する。

デバイス情報通知部４１２は、デバイス情報の通知が必要な場合にマルチキャストで参加／離脱通知を送信する。デバイス情報送信部４１３は、ネットワークを介してデバイス情報取得要求を受信し、デバイス情報管理部４１１が管理しているデバイス情報を要求元に送信する。デバイス検索処理部４１４は、マルチキャストでデバイス検索要求を受信し、デバイス検索要求に対する検索応答を送信する。

ＤＰサーバ１０２において、デバイス情報通知受信部４２１はデバイス１０１からマルチキャストで送信される参加／離脱の通知を受信し、その通知の種類に基づきデバイス／ＤＰサーバ情報保持部４２４が保持するデバイス情報の処理を行う。処理の結果、デバイス情報の取得が必要であると判断された場合は、デバイス情報取得部４２２は、デバイス１０１に対してデバイス情報取得要求を送信し、返されたデバイス情報をデバイス／ＤＰサーバ情報保持部４２４に保持する。

デバイス情報検索処理部４２３は、クライアントＰＣ１０３から送信されるデバイス／ＤＰサーバ情報の検索要求を受信し、指定された検索条件に基づきデバイス／ＤＰサーバ情報保持部４２４内のデバイス／ＤＰサーバ情報を検索する。そして、その結果をクライアントＰＣ１０３に送信する。

なお、クライアントＰＣ１０３が送信する検索要求は、自サブネット宛の場合はマルチキャストであり、他のサブネット宛の検索要求はユニキャストである。なお、自サブネットとは、クライアントＰＣ１０３が接続されたネットワークのうち、ルータで区切られた範囲内のネットワークのことである。ＤＰサーバ情報については、ＤＰサーバ登録処理部４２５より手動操作でデバイス／ＤＰサーバ情報保持部４２４に登録される。また、デバイス／ＤＰサーバ情報保持部４２４が保持するデバイス／ＤＰサーバ情報については後述する。

クライアントＰＣ１０３において、デバイス／ＤＰサーバ検索処理部４３１は、検索要求を自サブネット宛の場合はマルチキャストで送信し、他のサブネット宛の場合はユニキャストで送信する。デバイス情報取得部４３３は、デバイス１０１に対してデバイス情報取得要求を送信し、返されたデバイス情報を検索情報表示部４３２に表示する。

図５は、ＤＰサーバ１０２における、他のサブネット上のＤＰサーバの情報を登録する際のＵＩの一例を示す図である。図示のＵＩ画面は、検索情報表示部４３２により表示される。

図５において、領域５０１は、登録するＤＰサーバのＩＰアドレス、名称を入力するための入力欄である。なお、名称の登録は省略可能である。登録ボタン５０２が押下されると、領域５０１に入力された情報がＤＰサーバ登録処理部４２５によりＤＰサーバ１０２に登録される。既にＤＰサーバ１０２に登録されている他のサブネットのＤＰサーバの情報は、領域５０３にリスト表示される。図５に示す領域５０３には、ＤＰサーバ１０５に対応するＤＰサーバ情報５０３ａと、ＤＰサーバ１０７に対応するＤＰサーバ情報５０３ｂが表示されている。登録ボタン５０２が押下されると、ＤＰサーバ１０２は、登録したＤＰサーバに向けてＰｒｏｂｅメッセージをユニキャストで送信し、ＰｒｏｂｅＭａｔｃｈメッセージを受信することでＤＰサーバの情報を取得する。

図６は、クライアントＰＣ１０３における、デバイスを検索する際のＵＩの一例を示す図である。

図６において、領域６０１は、検索するデバイスのタイプを指定するための入力欄である。領域６０１では、「ＭＦＰ」、「Ｐｒｉｎｔｅｒ」などのキーワードが指定可能である。領域６０１に何も入力されていない場合は、全てのデバイスが検索される。検索実行ボタン６０２が押下されると、ＤＰサーバ１０２に対して検索が実行される。検索された結果は領域６０３に表示され、取得した情報から、デバイスのタイプやモデル名、デバイス名が同時に表示される。図６に示す領域６０３には、プリンタ「ＬＢＰＸＸＸＸ」のデバイス情報６０３ａ、プリンタ「ＬＢＰＹＹＹＹ」のデバイス情報６０３ｂ、及びＭＦＰ「ＭＦＰＸＸＸＸ」のデバイス情報６０３ｃが表示されている。

図７は、クライアントＰＣ１０３における、デバイス検索要求を送信するＤＰサーバを選択する際のＵＩの一例を示す図である。

図６に示す画面上で検索条件が指定され、ＤＰサーバ１０２に対して検索が実行されると、ＤＰサーバ１０２が接続されたネットワーク以外の他のサブネットのＤＰサーバ情報が図７のように表示される。領域７０１には、図示例のように、ＤＰサーバ情報７０１ａ，７０１ｂ，７０１ｃが表示される。ＤＰサーバ１０２が他のサブネットのＤＰサーバ情報に加えて、自身のＤＰサーバ情報も返す場合は、領域７０１にＤＰサーバ１０２の情報も表示される（７０１ａ）。

次に、領域７０１に表示されている中から任意のＤＰサーバ情報が選択され、検索実行ボタン７０２が押下されると、選択したＤＰサーバに向けてクライアントＰＣ１０３がデバイス検索要求を送信する。なお、領域７０１に表示されているＤＰサーバ情報の中から同時に複数のＤＰサーバ情報を選択することも可能である。

上述したＤＰサーバ選択を行わない場合は、クライアントＰＣ１０３は、ＤＰサーバ１０２が返すＤＰサーバ情報の全てに対してデバイス検索要求を送信する。

図８は、ＤＰサーバ１０２のデバイス／ＤＰサーバ情報保持部４２４が保持するデバイス／ＤＰサーバ情報の一例を示す図である。

それぞれのデバイス／ＤＰサーバ情報８００はレコードとして保持され、レコードはＩＤ８０１、ＵＵＩＤ８０２、バージョン８０３、デバイスタイプ８０４、モデル名８０５、デバイス名８０６、ＵＲＬ８０７、ＩＰアドレス８０８からなる。

ＩＤ８０１は、ＤＰサーバ内でデバイス／ＤＰサーバを識別するためのＩＤを示す。ＵＵＩＤ８０２は、デバイスをグローバルに識別するＵＵＩＤを示す。バージョン８０３は、デバイス情報のバージョンを示す。デバイスタイプ８０４は、複合機を意味する「ＭＦＰ」、プリンタを意味する「Ｐｒｉｎｔｅｒ」、Discovery Proxyを意味する「ＤｉｓｃｏｖｅｒｙＰｒｏｘｙ」などのタイプを示す。モデル名８０５は、「ＬＢＰＸＸＸＸ」のようなデバイスのモデル名を示す。デバイス名８０６は、デバイス管理者がデバイス／ＤＰサーバに設定した名前を示す。ＵＲＬ８０７は、デバイス／ＤＰサーバ情報を取得するためのＵＲＬを示す。ＩＰアドレス８０８は、デバイス／ＤＰサーバのＩＰアドレスを示す。

次に、デバイス１０４のデバイス情報をＤＰサーバ１０５に登録する方法について説明する。

デバイス１０４は、起動時やデバイス情報に変更があった場合に図９に示すようなＸＭＬ形式のＨｅｌｌｏメッセージをマルチキャストで送信することにより存在を通知する。図９に示すＨｅｌｌｏメッセージは、＜Ｈｅａｄｅｒ＞タグで囲まれるｈｅａｄｅｒ部９０１と＜Ｂｏｄｙ＞タグで囲まれるｂｏｄｙ部９０２からなり、全体が＜Ｅｎｖｅｌｏｐｅ＞タグで囲まれる構造になっている。この構造は、本実施形態において使用するメッセージ全てに共通である。

ｈｅａｄｅｒ部９０１は、メッセージの内容に依存しない共通ヘッダとしての役割を果たしており、＜Ａｃｔｉｏｎ＞タグ、＜ＭｅｓｓａｇｅＩＤ＞タグ、＜Ｔｏ＞タグが存在する。＜Ａｃｔｉｏｎ＞タグは、メッセージの種類を識別するためのものである。＜ＭｅｓｓａｇｅＩＤ＞タグは、メッセージを一意に識別するための識別子である。＜Ｔｏ＞タグは、このメッセージの送信先を識別するためのものである。

一方、ｂｏｄｙ部９０２は、メッセージの内容に対応して構造が変化する。図９においては、＜Ｂｏｄｙ＞タグの直下に＜Ｈｅｌｌｏ＞タグが存在し、このメッセージがＨｅｌｌｏメッセージであることを示している。＜Ｈｅｌｌｏ＞タグの中には、＜ＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅ＞タグ、＜Ｔｙｐｅｓ＞タグ、＜ＸＡｄｄｒｓ＞タグ、＜ＭｅｔａｄａｔａＶｅｒｓｉｏｎ＞タグが存在する。＜ＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅ＞タグの中には＜Ａｄｄｒｅｓｓ＞タグが存在し、デバイスを識別するアドレス情報を持つ。＜Ｔｙｐｅｓ＞タグはデバイスのタイプ情報を持つ。＜ＸＡｄｄｒｓ＞タグはデバイス情報を取得するためのＵＲＬを持つ。＜ＭｅｔａｄａｔａＶｅｒｓｉｏｎ＞タグはデバイス情報のバージョンを持つ。

ＤＰサーバ１０５は、Ｈｅｌｌｏメッセージの中からデバイスをグローバルに識別するＵＵＩＤとして、＜ＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅ＞タグの中の＜Ａｄｄｒｅｓｓ＞タグの値を抽出する。また、デバイスタイプとして＜Ｔｙｐｅｓ＞タグの値を抽出する。また、デバイス情報のバージョンとして＜ＭｅｔａｄａｔａＶｅｒｓｉｏｎ＞タグの値を抽出する。また、デバイス情報を取得するためのＵＲＬとして＜ＸＡｄｄｒｓ＞タグの値を抽出する。そして、これら抽出した情報をデバイス／ＤＰサーバ情報保持部４２４に格納する。また同時に、Ｈｅｌｌｏメッセージの送信元ＩＰアドレスもデバイス／ＤＰサーバ情報保持部４２４に格納する。その後、ＤＰサーバ１０５は、＜ＸＡｄｄｒｓ＞タグで記載されたＵＲＬに対し、ＸＭＬ形式のＧｅｔメッセージをユニキャストで送信する。Ｇｅｔメッセージは、ｈｅａｄｅｒ部のみを持つメッセージとなっている。ｈｅａｄｅｒ部の＜Ａｃｔｉｏｎ＞タグにおいて、このメッセージがＧｅｔメッセージであることを示している。

デバイス１０４のデバイス情報送信部４１３は、Ｇｅｔメッセージを受信すると、図１０に示すようなＧｅｔＲｅｓｐｏｎｓｅメッセージを送信する。図１０のＧｅｔＲｅｓｐｏｎｓｅメッセージにおいては、ｂｏｄｙ部に＜Ｍｅｔａｄａｔａ＞タグで示されるデバイス情報を持つ構造となっている。＜Ｍｅｔａｄａｔａ＞タグの中には＜ＭｅｔａｄａｔａＳｅｃｔｉｏｎ＞タグで示されるＭｅｔａｄａｔａＳｅｃｔｉｏｎ部１１０１，１１０２，１１０３が存在する。各ＭｅｔａｄａｔａＳｅｃｔｉｏｎ部は直下のタグにより、その中に持つ情報の種類が指定される。

ＭｅｔａｄａｔａＳｅｃｔｉｏｎ部１１０１は＜ＴｈｉｓＤｅｖｉｃｅ＞タグを持っており、デバイスごとに異なる情報が格納される。＜ＦｒｉｅｎｄｌｙＮａｍｅ＞タグはこのデバイスにつけた名前、＜ＦｉｒｍｗａｒｅＶｅｒｓｉｏｎ＞タグはこのデバイスのファームウェアバージョン、＜ＳｅｒｉａｌＮｕｍｂｅｒ＞タグはこのデバイスのシリアル番号を示している。ＭｅｔａｄａｔａＳｅｃｔｉｏｎ部１１０２は＜ＴｈｉｓＭｏｄｅｌ＞タグを持っており、デバイスのモデルごとに異なる情報が格納される。

＜Ｍａｎｕｆａｃｔｕｒｅｒ＞タグはデバイスの製造会社名、＜Ｍａｎｕｆａｃｔｕｒｅｒ＞タグはデバイス製造会社のＵＲＬ、＜ＰｒｅｓｅｎｔａｔｉｏｎＵＲＬ＞はデバイスの情報を示すＵＲＬ、＜ＭｏｄｅｌＮａｍｅ＞タグはデバイスのモデル名を示している。ＭｅｔａｄａｔａＳｅｃｔｉｏｎ部１１０３は＜Ｒｅｌａｔｉｏｎｓｈｉｐ＞タグを持っており、デバイスが持つ内部サービスの情報が格納される。本実施形態においては、内部サービスとはデバイスが提供するプリントサービスである。＜Ｒｅｌａｔｉｏｎｓｈｉｐ＞タグはさらにその直下に＜Ｈｏｓｔｅｄ＞タグを持ち、その中に＜ＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅ＞タグ、＜Ｔｙｐｅｓ＞タグ、＜ＳｅｒｖｉｃｅＩｄ＞タグが存在する。＜ＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅ＞タグの中には＜Ａｄｄｒｅｓｓ＞タグが存在し、サービスを利用するためのアドレス情報を持つ。＜Ｔｙｐｅｓ＞タグはサービスのタイプ情報を持つ。＜ＳｅｒｖｉｃｅＩｄ＞タグはデバイス内でサービスを識別するための識別子を持つ。

ＤＰサーバ１０５は、受信したデバイス情報からデバイス名として＜ＦｒｉｅｎｄｌｙＮａｍｅ＞タグの値、モデル名として＜ＭｏｄｅｌＮａｍｅ＞タグの値を抽出し、デバイス／ＤＰサーバ情報保持部４２４に格納する。なお、デバイス１０６のデバイス情報をＤＰサーバ１０７に登録する方法についても上述の方法と同様である。

次に、ＤＰサーバ１０５に登録されたデバイス情報をデバイス１０４が削除する方法について説明する。

デバイス１０４は、自機がＳＨＵＴＤＯＷＮする場合など、動作を停止する場合には、Ｂｙｅメッセージをマルチキャストで送信する。Ｂｙｅメッセージにおいては、ｂｏｄｙ部に＜Ｂｙｅ＞タグが存在し、このメッセージがＢｙｅメッセージであることを示している。＜Ｂｙｅ＞タグの中には＜ＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅ＞タグが存在する。＜ＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅ＞タグの中には＜Ａｄｄｒｅｓｓ＞タグが存在し、デバイスを識別するアドレス情報を持つ。ＤＰサーバ１０５はＢｙｅメッセージの中からＵＵＩＤ情報を抽出し、対応するデバイス情報をデバイス／ＤＰサーバ情報保持部４２４から削除する。なお、ＤＰサーバ１０７に登録されたデバイス情報をデバイス１０６が削除する方法についても上述の方法と同様である。

次に、クライアントＰＣ１０３がＤＰサーバ１０２を使用して他のサブネット上のデバイス１０４，１０６を検索する方法について説明する。

クライアントＰＣ１０３は、図１１（ａ）に示すようなＸＭＬ形式のＰｒｏｂｅメッセージをマルチキャストで送信する。図１１（ａ）に示すＰｒｏｂｅメッセージにおいては、ｂｏｄｙ部に＜Ｐｒｏｂｅ＞タグが存在し、このメッセージがＰｒｏｂｅメッセージであることを示している。＜Ｐｒｏｂｅ＞タグの中には＜Ｔｙｐｅｓ＞タグが存在する。＜Ｔｙｐｅｓ＞タグではＤｉｓｃｏｖｅｒｙＰｒｏｘｙを指定する。

ＤＰサーバ１０２は、Ｐｒｏｂｅメッセージを受信すると＜Ｔｙｐｅｓ＞タグを抽出し、デバイス／ＤＰサーバ情報保持部４２４の中からＤＰサーバを探し、図１１（ｂ）に示すようなＰｒｏｂｅＭａｔｃｈメッセージをクライアントＰＣ１０３に送信する。図１１（ｂ）に示すＰｒｏｂｅＭａｔｃｈメッセージにおいては、ｂｏｄｙ部に＜ＰｒｏｂｅＭａｔｃｈｅｓ＞タグが存在し、このメッセージがＰｒｏｂｅＭａｔｃｈメッセージであることを示している。＜ＰｒｏｂｅＭａｔｃｈｅｓ＞タグの中には＜ＰｒｏｂｅＭａｔｃｈ＞タグで示されるＰｒｏｂｅＭａｔｃｈ部１４０１，１４０２，１４０３が存在する。それぞれのＰｒｏｂｅＭａｔｃｈ部が１個の検索結果に対応しており、図１１（ｂ）の例においては３個の検索結果が返されていることを示している。ＰｒｏｂｅＭａｔｃｈ部の中の構造は、図９のＨｅｌｌｏメッセージにおける＜Ｈｅｌｌｏ＞タグの中と同一である。

クライアントＰＣ１０３は、ＰｒｏｂｅＭａｔｃｈメッセージの中から＜ＸＡｄｄｒｓ＞タグで記載されたＵＲＬを抽出し、図７に示すようにＤＰサーバ１０２，１０５，１０７のＩＰアドレスと名称を表示する。例えば、ＤＰサーバ１０５が選択されて検索実行ボタン７０２が押下されると、クライアントＰＣ１０３は、図１２（ａ）に示すようなＰｒｏｂｅメッセージを他のサブネット上のＤＰサーバ１０５にユニキャストで送信する。＜Ｔｙｐｅｓ＞タグでは、図６に示す画面上で入力された検索したいデバイスのタイプを指定する。なお、ＤＰサーバ１０２，１０７が選択された場合も図１２（ａ）のようなＰｒｏｂｅメッセージをＤＰサーバ１０２，１０７に向けて送信する。

他のサブネット上のＤＰサーバ１０５は、Ｐｒｏｂｅメッセージを受信すると、＜Ｔｙｐｅｓ＞タグを抽出する。そして、デバイス／ＤＰサーバ情報保持部４２４の中から検索条件に合致するデバイスを探し、図１２（ｂ）に示すようなＰｒｏｂｅＭａｔｃｈメッセージをクライアントＰＣ１０３に送信する。なお、ＤＰサーバ１０２，１０７がＰｒｏｂｅメッセージを受信した場合も、同様にＰｒｏｂｅＭａｔｃｈメッセージを送信する。

クライアントＰＣ１０３は、ＰｒｏｂｅＭａｔｃｈメッセージの中から＜ＸＡｄｄｒｓ＞タグで記載されたＵＲＬを抽出し、Ｇｅｔメッセージをユニキャストで送信する。本実施形態において、ＵＲＬは他のサブネット上のデバイス１０４のＩＰアドレスからなっており、ＧｅｔメッセージはＤＰサーバ１０５ではなく他のサブネット上のデバイス１０４に直接送信する。

デバイスは、図１０に示すようなＧｅｔＲｅｓｐｏｎｓｅメッセージを送信し、クライアントＰＣ１０３は必要な情報を抽出する。ＰｒｏｂｅＭａｔｃｈメッセージに複数の検索結果が存在している場合には、クライアントＰＣ１０３はＧｅｔメッセージの送信を繰り返し、全てのデバイス情報を取得する。なお、クライアントＰＣ１０３は、ＤＰサーバ１０２，１０７から受信したＰｒｏｂｅＭａｔｃｈメッセージのＵＲＬに対してもＧｅｔメッセージをユニキャストで送信する。

図１３は、上述のデバイス検索時にＤＰサーバ１０２で実行される処理を示すフローチャートである。

まず、ＤＰサーバ１０２は、Ｐｒｏｂｅメッセージを受信する（ステップＳ１７０１）。次に、＜Ｔｙｐｅｓ＞タグを抽出し（ステップＳ１７０２）、デバイス／ＤＰサーバ情報８００のレコードを検索し、抽出された値と同じデバイスタイプを持つかどうかを判定する（ステップＳ１７０３，検索手段）。ステップＳ１７０３の判定の結果、レコードがＤＰサーバで一致した場合には、そのＤＰサーバ情報を設定した応答データを作成する（ステップＳ１７０４）。一方、レコードがＤＰサーバ以外（デバイス検索サーバ以外）のデバイスタイプで一致した場合には、そのデバイス情報を設定した応答データを作成する（ステップＳ１７０５）。レコードがいずれとも一致しなかった場合は、そのままステップＳ１７０６へ進む。

ステップＳ１７０６において、全てのレコードについて確認が終了したかどうかを判定する。全てのレコードの検索が終了するとステップＳ１７０７に進み、それまでに生成された応答データを１個にまとめ、図１１（ｂ）に示すようなＰｒｏｂｅＭａｔｃｈメッセージを送信して、本処理を終了する。

図１４は、上述のデバイス検索時にクライアントＰＣ１０３で実行される処理を示すフローチャートである。

まず、クライアントＰＣ１０３は、＜Ｔｙｐｅｓ＞タグにＤＰサーバが設定されたＰｒｏｂｅメッセージを作成し（ステップＳ１８０１）、Ｐｒｏｂｅメッセージをマルチキャストで送信する（ステップＳ１８０２）。このＰｒｏｂｅメッセージが第１のメッセージの一例である。次に、ＤＰサーバからのＰｒｏｂｅＭａｔｃｈメッセージを受信し（ステップＳ１８０３）、ＰｒｏｂｅＭａｔｃｈメッセージの中から＜ＸＡｄｄｒｓ＞タグで記載された他のサブネット上のＤＰサーバのＵＲＬを抽出する（ステップＳ１８０４）。このＰｒｏｂｅＭａｔｃｈメッセージが第２のメッセージの一例である。ステップＳ１８０１〜Ｓ１８０４が第１の制御工程の一例である。

次に、クライアントＰＣ１０３は、＜Ｔｙｐｅｓ＞タグに検索したいデバイスタイプが設定されたＰｒｏｂｅメッセージを作成し（ステップＳ１８０５）、他のサブネット上のＤＰサーバにＰｒｏｂｅメッセージをユニキャストで送信する（ステップＳ１８０６）。このＰｒｏｂｅメッセージが第３のメッセージの一例である。

次に、クライアントＰＣ１０３は、他のサブネット上のＤＰサーバからのＰｒｏｂｅＭａｔｃｈメッセージを受信する（ステップＳ１８０７）。そして、ＰｒｏｂｅＭａｔｃｈメッセージの中から＜ＸＡｄｄｒｓ＞タグで記載された他のサブネット上のデバイスのＵＲＬを抽出する（ステップＳ１８０８）。このＰｒｏｂｅＭａｔｃｈメッセージが第４のメッセージの一例である。ステップＳ１８０５〜Ｓ１８０８が第２の制御工程の一例である。

次に、クライアントＰＣ１０３は、他のサブネット上のデバイスにＧｅｔメッセージをユニキャストで送信し（ステップＳ１８０９）、他のサブネット上のデバイスからのＧｅｔＲｅｓｐｏｎｓｅメッセージを受信して（ステップＳ１８１０）、本処理を終了する。このＧｅｔＲｅｓｐｏｎｓｅメッセージが返信メッセージの一例である。

このように、クライアントＰＣ１０３は、ＧｅｔＲｅｓｐｏｎｓｅメッセージから必要な情報を抽出することで他のサブネット上のデバイスのデバイス情報を取得することができる。上記ステップＳ１８０９〜Ｓ１８０９とデバイス情報の取得が第３の制御工程の一例である。

上記実施形態によれば、複数のサブネットがルータにより接続されたネットワーク環境において、クライアントＰＣが異なるサブネットに存在するデバイスを容易に検索することを可能となる。

［第２の実施形態］
次に、第２の実施形態について説明する。

マイクロソフト社のWS-Discovery仕様には、ＤＰサーバ１０２がクライアントＰＣ１０３からＰｒｏｂｅメッセージをマルチキャストで受信した際、ＤＰサーバ１０２は＜Ｔｙｐｅｓ＞タグにDiscoveryProxyを設定してＨｅｌｌｏメッセージを返す仕様がある。本実施形態は、クライアントＰＣ１０３がＰｒｏｂｅに対してのＨｅｌｌｏメッセージを受信した場合に、他のサブネット上のデバイスを検索する方法である。

第２の実施形態におけるクライアントＰＣ１０３がＤＰサーバ１０２を使用して他のサブネット上のデバイス１０４，１０６を検索する方法について説明する。

クライアントＰＣ１０３は、図１５に示すようなＰｒｏｂｅメッセージをマルチキャストで送信する。図１５に示すＰｒｏｂｅメッセージにおいて、＜Ｔｙｐｅｓ＞タグではＰｒｉｎｔｅｒを指定する。

ＤＰサーバ１０２はＰｒｏｂｅメッセージを受信すると、Ｐｒｏｂｅメッセージがマルチキャストかつ、＜Ｔｙｐｅｓ＞タグがＤＰサーバでないかを判定し、その場合はＨｅｌｌｏメッセージ作成処理を行う。もしＰｒｏｂｅメッセージがユニキャストか、＜Ｔｙｐｅｓ＞タグがＤＰサーバの場合は、上記第１の実施形態のようにＰｒｏｂｅＭａｔｃｈメッセージ作成処理を行う。ＤＰサーバ１０２は、＜Ｔｙｐｅｓ＞タグを抽出し、デバイス／ＤＰサーバ情報保持部４２４の中からＤＰサーバを探し、図１６（ａ），図１６（ｂ），図１６（ｃ）に示すようなＨｅｌｌｏメッセージをクライアントＰＣ１０３に送信する。

図１６（ａ）〜図１６（ｃ）に示すＨｅｌｌｏメッセージには、それぞれのＨｅｌｌｏメッセージが１個の検索結果に対応しており、図示例においては３個の検索結果が返される。なお、一つのＨｅｌｌｏメッセージに３個のＤＰサーバ情報を含めることも可能である。クライアントＰＣ１０３は、Ｈｅｌｌｏメッセージの中から＜ＸＡｄｄｒｓ＞タグで記載されたＵＲＬを抽出する。以降のデバイスの検索処理は、上記第１の実施形態と同じである。

図１７は、第２の実施形態におけるデバイス検索時のＤＰサーバ１０２で実行される処理を示すフローチャートである。

まず、ＤＰサーバ１０２は、Ｐｒｏｂｅメッセージを受信し（ステップＳ２１０１）、Ｐｒｏｂｅメッセージがマルチキャストかどうかを判定する（ステップＳ２１０２）。ステップＳ２１０２は第２の判定手段による判定の一例である。ステップＳ２１０２の判定の結果、マルチキャストでない場合は、ステップＳ２１０３以降のＰｒｏｂｅＭａｔｃｈメッセージ作成処理に入る。一方、Ｐｒｏｂｅメッセージがマルチキャストである判定された場合は、ステップＳ２１０９に進む。

ステップＳ２１０３では、ＤＰサーバ１０２は、＜Ｔｙｐｅｓ＞タグを抽出する。次に、デバイス／ＤＰサーバ情報８００のレコードを検索し、抽出された値と同じデバイスタイプを持つかどうかを判定する（ステップＳ２１０４）。この判定の結果、レコードがＤＰサーバで一致した場合、そのＤＰサーバ情報を設定した応答データを作成する（ステップＳ２１０５）。一方、レコードがＤＰサーバ以外のデバイスタイプで一致した場合には、そのデバイス情報を設定した応答データを作成する（ステップＳ２１０６）。レコードがいずれとも一致しなかった場合は、そのままステップＳ２１０７へ進む。

ステップＳ２１０７では、ＤＰサーバ１０２は、全てのレコードについて確認が終了したかどうかを判定する。全てのレコードの検索が終了するとステップＳ２１０８に進み、それまでに生成された応答データを１個にまとめ、ＰｒｏｂｅＭａｔｃｈメッセージを送信して、本処理を終了する。

ステップＳ２１０９では、ＤＰサーバ１０２は、＜Ｔｙｐｅｓ＞タグを抽出し、＜Ｔｙｐｅｓ＞タグの値がDiscoveryProxyかどうかを判定する（ステップＳ２１１０）。ステップＳ２１１０は第３の判定手段による判定の一例である。ステップＳ２１１０の判定の結果、DiscoveryProxyの場合は、ステップＳ２１０４以降のＰｒｏｂｅＭａｔｃｈメッセージ作成処理に入る。

一方、ステップＳ２１１０において、＜Ｔｙｐｅｓ＞タグの値がDiscoveryProxyでないと判定された場合は、ステップＳ２１１０以降のＨｅｌｌｏメッセージ作成処理に入る。ステップＳ２１１１では、ＤＰサーバ１０２は、デバイス／ＤＰサーバ情報８００のレコードを検索し、デバイスタイプがＤＰサーバかどうかを判定する。レコードのデバイスタイプがＤＰサーバの場合は、ＤＰサーバ１０２は、そのＤＰサーバ情報を設定した応答データを作成し（ステップＳ２１１２）、Ｈｅｌｌｏメッセージを送信する（ステップＳ２１１３）。次に、ステップＳ２１１４では、全てのレコードについて確認が終了したかどうかを判定し、全てのレコードの検索が終了すると、本処理を終了する。

図１８は、第２の実施形態におけるデバイス検索時のクライアントＰＣ１０３で実行される処理を示すフローチャートである。

まず、クライアントＰＣ１０３は、＜Ｔｙｐｅｓ＞タグに検索したいデバイスタイプが設定されたＰｒｏｂｅメッセージを作成し（ステップＳ２２０１）、Ｐｒｏｂｅメッセージをマルチキャストで送信する（ステップＳ２２０２）。次に、ＤＰサーバからのＨｅｌｌｏメッセージを受信し（ステップＳ２２０３）、Ｈｅｌｌｏメッセージの中から＜ＸＡｄｄｒｓ＞タグで記載された他のサブネット上のＤＰサーバのＵＲＬを抽出する（ステップＳ２２０４）。

次に、クライアントＰＣ１０３は、＜Ｔｙｐｅｓ＞タグに検索したいデバイスタイプが設定されたＰｒｏｂｅメッセージを作成し（ステップＳ２２０５）、他のサブネット上のＤＰサーバにＰｒｏｂｅメッセージをユニキャストで送信する（ステップＳ２２０６）。次に、クライアントＰＣ１０３は、他のサブネット上のＤＰサーバからのＰｒｏｂｅＭａｔｃｈメッセージを受信する（ステップＳ２２０７）。そして、ＰｒｏｂｅＭａｔｃｈメッセージの中から＜ＸＡｄｄｒｓ＞タグで記載された他のサブネット上のデバイスのＵＲＬを抽出する（ステップＳ２２０８）。

次に、クライアントＰＣ１０３は、他のサブネット上のデバイスにＧｅｔメッセージをユニキャストで送信し（ステップＳ２２０９）、他のサブネット上のデバイスからのＧｅｔＲｅｓｐｏｎｓｅメッセージを受信して（ステップＳ２２１０）、本処理を終了する。

このように、クライアントＰＣ１０３は、ＧｅｔＲｅｓｐｏｎｓｅメッセージから必要な情報を抽出することで他のサブネット上のデバイスからデバイス情報を取得することができる。

上記実施形態によれば、複数のサブネットがルータにより接続されたネットワーク環境において、クライアントＰＣが異なるサブネットに存在するデバイスを容易に検索することを可能となる。

［第３の実施形態］
次に、第３の実施形態について説明する。

第１の実施形態においては、クライアントＰＣ１０３は、＜Ｔｙｐｅｓ＞タグにＤＰサーバを設定してＰｒｏｂｅメッセージを送信した後、ＰｒｏｂｅＭａｔｃｈメッセージを受信する。しかし、ＰｒｏｂｅＭａｔｃｈメッセージに含まれるＤＰサーバ情報が自サブネットのＤＰサーバであるか他のサブネット上のＤＰサーバであるか判断することはできない。クライアントＰＣ１０３にとっては、自サブネットのＤＰサーバ情報はＤＰサーバが接続されたときのＨｅｌｌｏメッセージで取得することができるため、他のサブネットのＤＰサーバ情報のみを取得することができればよい。そこで、本実施形態では、クライアントＰＣ１０３は、自サブネットのＤＰサーバと他のサブネット上のＤＰサーバを区別して、他のサブネット上のＤＰサーバにのみデバイス検索のＰｒｏｂｅメッセージを送信する。

第３の実施形態におけるクライアントＰＣ１０３がＤＰサーバ１０２を使用して他のサブネット上のデバイス１０４，１０６を検索する方法について説明する。

クライアントＰＣ１０３は、図１１（ａ）に示すようなＰｒｏｂｅメッセージをマルチキャストで送信する。図１１（ａ）に示すＰｒｏｂｅメッセージにおいて、＜Ｔｙｐｅｓ＞タグではDiscoveryProxyを指定する。

ＤＰサーバ１０２はＰｒｏｂｅメッセージを受信すると、＜Ｔｙｐｅｓ＞タグを抽出しデバイス／ＤＰサーバ情報保持部４２４の中からＤＰサーバを探し、図１９に示すようなＰｒｏｂｅＭａｔｃｈメッセージをクライアントＰＣ１０３に送信する。＜ＰｒｏｂｅＭａｔｃｈｅｓ＞タグの中には、＜ＰｒｏｂｅＭａｔｃｈ＞タグで示されるＰｒｏｂｅＭａｔｃｈ部２３０１，２３０２，２３０３が存在する。それぞれのＰｒｏｂｅＭａｔｃｈ部が１個の検索結果に対応しており、図１９の例においては３個の検索結果が返されていることを示している。

ＤＰサーバ１０２は、＜ＰｒｏｂｅＭａｔｃｈ＞タグの中で、自サブネットのＤＰサーバの場合は＜Ｓｕｂｎｅｔ＞タグにＩｎｓｉｄｅを指定し、他のサブネット上のＤＰサーバの場合は＜Ｓｕｂｎｅｔ＞タグにＯｕｔｓｉｄｅを指定する。図１９では、ＰｒｏｂｅＭａｔｃｈ部２３０１が自身のＤＰサーバ情報を示しており、＜Ｓｕｂｎｅｔ＞タグにＩｎｓｉｄｅを指定している。

クライアントＰＣ１０３は、ＰｒｏｂｅＭａｔｃｈメッセージの中から＜ＸＡｄｄｒｓ＞タグで記載されたＵＲＬを抽出する。また、＜Ｓｕｂｎｅｔ＞タグで記載されたサブネット情報（Ｉｎｓｉｄｅ／Ｏｕｔｓｉｄｅ）から他のサブネット上のＤＰサーバを判断し、他のサブネット上のＤＰサーバに対してのみ図１２（ａ）のようなＰｒｏｂｅメッセージを送信する。つまり、＜Ｓｕｂｎｅｔ＞タグにＯｕｔｓｉｄｅが記載されたＰｒｏｂｅＭａｔｃｈ部に対応するＤＰサーバに対してのみ、図１２（ａ）のようなＰｒｏｂｅメッセージを送信する。

なお、クライアントＰＣ１０３は、＜Ｓｕｂｎｅｔ＞タグのサブネット情報をＵＩ画面に表示してＤＰサーバの選択をさせてもよい。以降のデバイスの検索処理は第１の実施形態と同じである。

上述のデバイス検索の流れについて、ＤＰサーバ１０２の処理を示すフローチャートは上記第１の実施形態と同じである。

図２０は、第３の実施形態におけるデバイス検索時のクライアントＰＣ１０３で実行される処理を示すフローチャートである。

まず、クライアントＰＣ１０３は、＜Ｔｙｐｅｓ＞タグにＤＰサーバを設定したＰｒｏｂｅメッセージを作成し（ステップＳ２４０１）、Ｐｒｏｂｅメッセージをマルチキャストで送信する（ステップＳ２４０２）。次に、クライアントＰＣ１０３は、ＤＰサーバからのＰｒｏｂｅＭａｔｃｈメッセージを受信する（ステップＳ２４０３）。

クライアントＰＣ１０３は、ＤＰサーバから受信したＰｒｏｂｅＭａｔｃｈメッセージの中から＜Ｓｕｂｎｅｔ＞タグで記載されたサブネット情報を抽出し（ステップＳ２４０４）、他のサブネットのＤＰサーバ情報かどうかを判定する（ステップＳ２４０５）。この判定の結果、他のサブネットのＤＰサーバ情報である場合は、ステップＳ２４０６に進み、クライアントＰＣ１０３は、ＰｒｏｂｅＭａｔｃｈメッセージの中から＜ＸＡｄｄｒｓ＞タグで記載された他のサブネット上のＤＰサーバのＵＲＬを抽出する。

次に、クライアントＰＣ１０３は、＜Ｔｙｐｅｓ＞タグに検索したいデバイスタイプを設定したＰｒｏｂｅメッセージを作成し（ステップＳ２４０７）、他のサブネット上のＤＰサーバにＰｒｏｂｅメッセージをユニキャストで送信する（ステップＳ２４０８）。一方、ステップＳ２４０５において自サブネットのＤＰサーバ情報であると判断した場合は、クライアントＰＣ１０３は、Ｐｒｏｂｅメッセージの送信を行わずにステップＳ２４０９に進む。

ステップＳ２４０９では、クライアントＰＣ１０３は、ＰｒｏｂｅＭａｔｃｈメッセージの中にまだＤＰサーバ情報が存在するかを判定し、まだＤＰサーバ情報が存在する場合は、ステップＳ２４０４に戻る。一方、ステップＳ２４０９において、ＤＰサーバ情報が存在しないと判断した場合は、ステップＳ２４１０に進む。

ステップＳ２４１０では、クライアントＰＣ１０３は、他のサブネット上のＤＰサーバからのＰｒｏｂｅＭａｔｃｈメッセージを受信する。つづいて、ステップＳ２４１１では、クライアントＰＣ１０３は、ＰｒｏｂｅＭａｔｃｈメッセージの中から＜ＸＡｄｄｒｓ＞タグで記載された他のサブネット上のデバイスのＵＲＬを抽出する。

次に、クライアントＰＣ１０３は、他のサブネット上のデバイスにＧｅｔメッセージをユニキャストで送信し（ステップＳ２４１２）、他のサブネット上のデバイスからのＧｅｔＲｅｓｐｏｎｓｅメッセージを受信し（ステップＳ２４１３）、本処理を終了する。

クライアントＰＣ１０３は、ＧｅｔＲｅｓｐｏｎｓｅメッセージから必要な情報を抽出することで他のサブネット上のデバイスのデバイス情報を取得することができる。

なお、本第３の実施形態では、＜Ｓｕｂｎｅｔ＞タグにより、自サブネットのＤＰサーバ情報か他のサブネットのＤＰサーバ情報かの判断を行ったが、＜Ｘａｄｄｒｓ＞タグによる判断を行ってもよい。クライアントＰＣ１０３は、＜Ｘａｄｄｒｓ＞タグからＤＰサーバのＩＰアドレスを抽出し、そのＩＰアドレスが自身の所属するサブネットの範囲に含まれるかを判断する。含まれる場合は自サブネットのＤＰサーバであると判断し、含まれない場合は他のサブネット上のＤＰサーバであると判断する。

また、第２の実施形態のように、ＤＰサーバ１０２がＨｅｌｌｏメッセージを送信する場合でも、Ｈｅｌｌｏメッセージに＜Ｓｕｂｎｅｔ＞タグを付与することで、自サブネットのＤＰサーバ情報か他のサブネットのＤＰサーバ情報かの判断をさせてもよい。

上記実施形態によれば、複数のサブネットがルータにより接続されたネットワーク環境において、クライアントＰＣが異なるサブネットに存在するデバイスを容易に検索することを可能となる。

［第４の実施形態］
次に、第４の実施形態について説明する。

上記第３の実施形態では、クライアントＰＣ１０３がタグの解析やＩＰアドレスの解析処理を行わなければならず、クライアントＰＣ１０３の処理負荷が増えてしまうという問題がある。

そこで、第４の実施形態では、ＤＰサーバ１０２がＰｒｏｂｅメッセージに対する応答方法を変更することで、クライアントＰＣ１０３の処理負荷を減らす。

ＤＰサーバ１０２は、クライアントＰＣ１０３からの＜Ｔｙｐｅｓ＞タグにＤＰサーバを設定したＰｒｏｂｅメッセージを受信する。すると、自サブネットのＤＰサーバ情報はＨｅｌｌｏメッセージで、他のサブネットのＤＰサーバ情報はＰｒｏｂｅＭａｔｃｈメッセージで応答される。

第４の実施形態におけるクライアントＰＣ１０３がＤＰサーバ１０２を使用して他のサブネット上のデバイス１０４，１０６を検索する方法について説明する。

クライアントＰＣ１０３は、図１１（ａ）に示すようなＰｒｏｂｅメッセージをマルチキャストで送信する。図１１（ａ）のＰｒｏｂｅメッセージにおいて、＜Ｔｙｐｅｓ＞タグではDiscoveryProxyを指定する。ＤＰサーバ１０２は、Ｐｒｏｂｅメッセージを受信すると、＜Ｔｙｐｅｓ＞タグを抽出しデバイス／ＤＰサーバ情報保持部４２４の中からＤＰサーバを探す。そして、図２１（ａ）に示すようなＨｅｌｌｏメッセージと図２１（ｂ）、図２１（ｃ）に示すようなＰｒｏｂｅＭａｔｃｈメッセージをクライアントＰＣ１０３に送信する。ＤＰサーバ１０２は、自サブネットのＤＰサーバ情報であればＤＰサーバ情報をＨｅｌｌｏメッセージで送信し、他のサブネットのＤＰサーバ情報であればＤＰサーバ情報をＰｒｏｂｅＭａｔｃｈメッセージで送信する。図２１（ａ）に示すＨｅｌｌｏメッセージがＤＰサーバ１０２自身のＤＰサーバ情報を示しており、Ｈｅｌｌｏメッセージで自サブネット情報であることを示している。

クライアントＰＣ１０３は、受信したＨｅｌｌｏメッセージとＰｒｏｂｅＭａｔｃｈメッセージの＜Ａｃｔｉｏｎ＞タグからＨｅｌｌｏメッセージかＰｒｏｂｅＭａｔｃｈメッセージかを判断する。Ｈｅｌｌｏメッセージの場合はメッセージを破棄し、ＰｒｏｂｅＭａｔｃｈメッセージの場合はＰｒｏｂｅＭａｔｃｈメッセージの中から＜ＸＡｄｄｒｓ＞タグで記載されたＵＲＬを抽出する。

クライアントＰＣ１０３は、図１２（ａ）のようなＰｒｏｂｅメッセージを他のサブネット上のＤＰサーバ１０５にユニキャストで送信する。なお、クライアントＰＣ１０３は、自サブネットのＤＰサーバか他のサブネット上のＤＰサーバかを示すサブネット情報をＵＩ画面に表示してＤＰサーバの選択をさせてもよい。以降のデバイスの検索処理は第１の実施形態と同じである。

図２２は、第４の実施形態におけるデバイス検索時のＤＰサーバ１０２で実行される処理を示すフローチャートである。

まず、ＤＰサーバ１０２は、Ｐｒｏｂｅメッセージを受信する（ステップＳ２６０１）。次に、＜Ｔｙｐｅｓ＞タグを抽出し（ステップＳ２６０２）、＜Ｔｙｐｅｓ＞タグの値がDiscoveryProxyかを判定する（ステップＳ２６０３）。ステップＳ２６０３は第４の判定手段による判定の一例である。

ステップＳ２６０３の判定の結果、DiscoveryProxyでない場合はステップＳ２６０４に進み、ＤＰサーバ１０２は、デバイス／ＤＰサーバ情報８００のレコードを検索し、抽出された値と同じデバイスタイプを持つかどうかを判定する。この判定の結果、レコードが一致した場合、ＤＰサーバ１０２は、そのデバイス情報を設定した応答データを作成する（ステップＳ２６０５）。次に、ステップＳ２６０６において、ＤＰサーバ１０２は、全てのレコードについて確認が終了したかどうかを判定する。この判定の結果、全てのレコードの検索が終了するとステップＳ２６０７に進み、それまでに生成された応答データを１個にまとめ、ＰｒｏｂｅＭａｔｃｈメッセージを送信して本処理を終了する。

一方、ステップＳ２６０３で＜Ｔｙｐｅｓ＞タグの値がDiscoveryProxyであると判定した場合、ＤＰサーバ１０２は、デバイス／ＤＰサーバ情報８００のレコードを検索し、抽出された値と同じデバイスタイプを持つかどうかを判定する（ステップＳ２６０８）。この判定の結果、レコードが一致した場合には、ＤＰサーバ１０２は、自サブネットのＤＰサーバ情報かどうかを判定する（ステップＳ２６０９）。ステップＳ２６０９は第５の判定手段による判定の一例である。自サブネットのＤＰサーバ情報であると判断した場合は、ＤＰサーバ１０２は、そのＤＰサーバ情報を設定した応答データ（第２の応答データ）を作成し（ステップＳ２６１０）、Ｈｅｌｌｏメッセージを送信する（ステップＳ２６１１）。

一方、ステップＳ２６０９で他のサブネットのＤＰサーバ情報であると判断した場合、ＤＰサーバ１０２は、そのＤＰサーバ情報を設定した応答データ（第１の応答データ）を作成する（ステップＳ２６１２）。そして、ＰｒｏｂｅＭａｔｃｈメッセージを送信する（ステップＳ２６１３）。

ステップＳ２６１４では、ＤＰサーバ１０２は、全てのレコードについて確認が終了したかどうかを判定し、全てのレコードの検索が終了すると本処理を終了する。

図２３は、第４の実施形態におけるデバイス検索時のクライアントＰＣ１０３で実行される処理を示すフローチャートである。

まず、クライアントＰＣ１０３は、＜Ｔｙｐｅｓ＞タグにＤＰサーバを設定したＰｒｏｂｅメッセージを作成し（ステップＳ２７０１）、Ｐｒｏｂｅメッセージをマルチキャストで送信する（ステップＳ２７０２）。

次に、クライアントＰＣ１０３は、ＤＰサーバからメッセージを受信し（ステップＳ２７０３）、＜Ａｃｔｉｏｎ＞タグからメッセージ種別を判定する（ステップＳ２７０４）。この判定の結果、メッセージ種別がＰｒｏｂｅＭａｔｃｈの場合はステップＳ２７０５に進み、クライアントＰＣ１０３は、ＰｒｏｂｅＭａｔｃｈメッセージの中から＜ＸＡｄｄｒｓ＞タグで記載された他のサブネット上のＤＰサーバのＵＲＬを抽出する。一方、ステップＳ２７０４において、メッセージ種別がＨｅｌｌｏの場合はステップＳ２７０６に進み、クライアントＰＣ１０３は、Ｈｅｌｌｏメッセージを破棄する。

ステップＳ２７０７の判定により、まだ受信メッセージが残っていると判定した場合はステップＳ２７０４に戻る一方、受信メッセージを全て処理したと判定した場合はステップＳ２７０８に進む。ステップＳ２７０８では、クライアントＰＣ１０３は、＜Ｔｙｐｅｓ＞タグに検索したいデバイスタイプを設定したＰｒｏｂｅメッセージを作成する。そして、クライアントＰＣ１０３は、他のサブネット上のＤＰサーバにＰｒｏｂｅメッセージをユニキャストで送信する（ステップＳ２７０９）。

次に、クライアントＰＣ１０３は、他のサブネット上のＤＰサーバからのＰｒｏｂｅＭａｔｃｈメッセージを受信する（ステップＳ２７１０）。そして、ＰｒｏｂｅＭａｔｃｈメッセージの中から＜ＸＡｄｄｒｓ＞タグで記載された他のサブネット上のデバイスのＵＲＬを抽出する（ステップＳ２７１１）。次に、クライアントＰＣ１０３は、他のサブネット上のデバイスにＧｅｔメッセージをユニキャストで送信し（ステップＳ２７１２）、他のサブネット上のデバイスからのＧｅｔＲｅｓｐｏｎｓｅメッセージを受信する（ステップＳ２７１３）。

このように、クライアントＰＣ１０３はＧｅｔＲｅｓｐｏｎｓｅメッセージから必要な情報を抽出することで他のサブネット上のデバイスのデバイス情報を取得することができる。

上記実施形態によれば、複数のサブネットがルータにより接続されたネットワーク環境において、クライアントＰＣが異なるサブネットに存在するデバイスを容易に検索することを可能となる。

また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

１０１，１０４，１０６ デバイス
１０２，１０５，１０７ ＤＰサーバ
１０３ クライアントＰＣ
４３１ デバイス／ＤＰサーバ検索処理部
４３３ デバイス情報取得部
４２１ デバイス情報通知受信部
４２２ デバイス情報取得部
４２３ デバイス情報検索処理部
４２４ デバイス／ＤＰサーバ情報保持部
４２５ ＤＰサーバ登録処理部

Claims (14)

1. マルチキャストによる通信を各サブネット内でのみ可能とするルータを介して接続される、第１のサブネット及び第２のサブネットを含むネットワーク上の、前記第１のサブネット上にあるデバイス検索装置であって、
   デバイス検索サーバの検索を要求する第１のメッセージを前記第１のサブネット上にある第１のデバイス検索サーバにマルチキャストで送信し、前記第１のデバイス検索サーバから受信した第２のメッセージの中から、前記第２のサブネット上にある第２のデバイス検索サーバを含むデバイス検索サーバのＵＲＬを抽出し、当該ＵＲＬが抽出されたデバイス検索サーバの名称をユーザ選択可能に表示する第１の制御手段と、
   前記第１の制御手段により表示されたデバイス検索サーバの名称の中から前記第２のデバイス検索サーバの名称がユーザ選択された場合、当該第２のデバイス検索サーバのＵＲＬに基づいて、前記第２のサブネット上にあるデバイスの検索を要求する第３のメッセージを前記第２のデバイス検索サーバにユニキャストで送信し、前記第２のデバイス検索サーバから受信した第４のメッセージの中から前記第２のサブネット上にあるデバイスのＵＲＬを抽出する第２の制御手段と、
   前記第４のメッセージから抽出したＵＲＬに基づいて、前記第２のサブネット上にある前記デバイスのデバイス情報を要求する第５のメッセージを、当該デバイスにユニキャストで送信し、前記デバイスから返信された返信メッセージから前記デバイスのデバイス情報を取得する第３の制御手段と、
   を備えることを特徴とするデバイス検索装置。
2. 前記第２のメッセージはＰｒｏｂｅＭａｔｃｈメッセージであることを特徴とする請求項１記載のデバイス検索装置。
3. 前記第２のメッセージはＨｅｌｌｏメッセージであることを特徴とする請求項１記載のデバイス検索装置。
4. 前記第１の制御手段は、前記第１のデバイス検索サーバから前記第２のメッセージとして受信したＰｒｏｂｅＭａｔｃｈメッセージの中からサブネット情報を抽出し、前記抽出したサブネット情報が前記第１のサブネット以外のサブネットを表すか否かを判定する判定手段と、
   前記判定手段により前記抽出されたサブネット情報が前記第１のサブネット以外のサブネットの情報を表す場合には、前記ＰｒｏｂｅＭａｔｃｈメッセージの中から前記第１のサブネット以外のサブネット上のデバイス検索サーバのＵＲＬを抽出する抽出手段と、
   を備えることを特徴とする請求項１記載のデバイス検索装置。
5. 前記第１の制御手段は、前記第１のデバイス検索サーバから受信した前記第２のメッセージの種別を判定する判定手段と、
   前記判定手段により前記第２のメッセージがＰｒｏｂｅＭａｔｃｈメッセージであると判定された場合、前記ＰｒｏｂｅＭａｔｃｈメッセージの中から前記第１のサブネット以外ののサブネット上のデバイス検索サーバのＵＲＬを抽出する抽出手段と、
   を備えることを特徴とする請求項１記載のデバイス検索装置。
6. 前記第１の制御手段は、前記第１のデバイス検索サーバから受信した前記第２のメッセージに基づき、デバイス検索サーバの名称をリストとして表示する表示手段と、
   前記表示手段に表示されたリストから所望のデバイス検索サーバをユーザに選択させるための選択手段と、
   をさらに備えることを特徴とする請求項１乃至５のいずれか１項に記載のデバイス検索装置。
7. マルチキャストによる通信を各サブネット内でのみ可能とするルータを介して接続される、第１のサブネット及び第２のサブネットを含むネットワーク上の、前記第１のサブネット上にあるデバイス検索サーバであって、
   前記第１のサブネット上のデバイスのデバイス／サーバタイプ及びＵＲＬ、並びに前記ネットワーク上のデバイス検索サーバのデバイス／サーバタイプ及びＵＲＬを登録する登録手段と、
   前記第１のサブネット上にある第１のデバイス検索装置または前記第２のサブネット上にある第２のデバイス検索装置のいずれかを送信先とする検索要求を受信する受信手段と、
   前記受信手段により前記検索要求が受信されたとき、前記登録手段により登録された情報から、前記検索要求が表すデバイス／サーバタイプに合致する情報を検索する検索手段と、
   前記検索手段による検索結果に応じて応答データを作成する作成手段と、
   前記作成された応答データを、前記送信先に送信する送信手段と、
   を備えることを特徴とするデバイス検索サーバ。
8. 前記検索要求が表すデバイス／サーバタイプがデバイス検索サーバであるとき、前記検索手段は、前記登録手段に登録された情報のうち、デバイス／サーバタイプがデバイス検索サーバのＵＲＬを検索し、前記作成手段は、当該検索されたＵＲＬを含むデータを前記応答データとして作成し、
   前記検索要求が表すデバイス／サーバタイプがデバイス検索サーバ以外のデバイスであるとき、前記検索手段は、前記登録手段に登録された情報のうち、デバイス／サーバタイプがデバイス検索サーバ以外のデバイスのＵＲＬを検索し、前記作成手段は、前記検索されたＵＲＬを含むデータを前記応答データとして作成し、
   前記送信手段は、当該作成された応答データをＰｒｏｂｅＭａｔｃｈメッセージとして送信することを特徴とする請求項７記載のデバイス検索サーバ。
9. 前記受信した検索要求がマルチキャストで送信されたか否かを判定する第２の判定手段と、
   前記第２の判定手段により前記検索要求がマルチキャストで送信されたと判定された場合、前記検索要求にＤｉｓｃｏｖｅｒｙＰｒｏｘｙが指定されているか否かを判定する第３の判定手段と、をさらに備え、
   前記第３の判定手段により前記検索要求にＤｉｓｃｏｖｅｒｙＰｒｏｘｙが指定されていないと判定された場合、記検索手段は、前記登録手段に登録された情報のうち、デバイス／サーバタイプがデバイス検索サーバのＵＲＬを検索し、前記作成手段は、当該検索されたＵＲＬを含むデータを前記応答データとして作成し、前記送信手段は、当該作成された応答データをＨｅｌｌｏメッセージとして送信することを特徴とする請求項７記載のデバイス検索サーバ。
10. 前記受信した検索要求にＤｉｓｃｏｖｅｒｙＰｒｏｘｙが指定されているか否かを判定する第４の判定手段と、
    前記第４の判定手段により前記デバイス検索要求にＤｉｓｃｏｖｅｒｙＰｒｏｘｙが指定されていると判定された場合、前記検索要求で指定されている情報が前記デバイス検索サーバ自身の情報のみであるか否かを判定する第５の判定手段と、をさらに備え、
    前記第５の判定手段により、前記検索要求で指定されている情報が前記デバイス検索サーバ自身の情報のみでないと判定された場合、前記検索手段は、前記登録手段に登録された情報のうち、デバイス／サーバタイプがデバイス検索サーバのＵＲＬを検索し、前記作成手段は、当該検索されたＵＲＬを含むデータを前記応答データとして作成し、
    前記第５の判定手段により、前記検索要求で指定されている情報が前記デバイス検索サーバ自身の情報のみであると判定された場合、前記作成手段は、前記デバイス検索サーバ自身の情報に基づいて他の応答データを作成し、
    前記送信手段は、前記応答データについてはＰｒｏｂｅＭａｔｃｈメッセージで送信し、前記他の応答データについてはＨｅｌｌｏメッセージで送信することを特徴とする請求項７記載のデバイス検索サーバ（第３の実施形態）。
11. 請求項１乃至６のいずれか１項の記載のデバイス検索装置と、請求項７乃至１０のいずれか１項に記載のデバイス検索サーバとを備えることを特徴とするデバイス検索システム。
12. マルチキャストによる通信を各サブネット内でのみ可能とするルータを介して接続される、第１のサブネット及び第２のサブネットを含むネットワーク上の、前記第１のサブネット上にあるデバイス検索装置のデバイス検索方法であって、
    デバイス検索サーバの検索を要求する第１のメッセージを前記第１のサブネット上にある第１のデバイス検索サーバにマルチキャストで送信し、前記第１のデバイス検索サーバから受信した第２のメッセージの中から、前記第２のサブネット上にある第２のデバイス検索サーバを含むデバイス検索装置のＵＲＬを抽出し、当該ＵＲＬが抽出されたデバイス検索サーバの名称をユーザ選択可能に表示する第１の制御工程と、
    前記第１の制御手段により表示されたデバイス検索サーバの名称の中から前記第２のデバイス検索サーバの名称がユーザ選択された場合、当該第２のデバイス検索サーバのＵＲＬに基づいて、前記第２のサブネット上にあるデバイスの検索を要求する第３のメッセージを前記第２のサブネット上のデバイス検索サーバにユニキャストで送信し、前記第２のデバイス検索サーバから受信した第４のメッセージの中から前記第２のサブネット上にあるデバイスのＵＲＬを抽出する第２の制御工程と、
    前記第４のメッセージから抽出したＵＲＬに基づいて、前記第２のサブネット上にある前記デバイスのデバイス情報を要求する第５のメッセージを、当該デバイスにユニキャストで送信し、前記デバイスから返信された返信メッセージから前記デバイスのデバイス情報を取得する第３の制御工程と、を備えることを特徴とするデバイス検索方法。
13. マルチキャストによる通信を各サブネット内でのみ可能とするルータを介して接続される、第１のサブネット及び第２のサブネットを含むネットワーク上の、前記第１のサブネット上にあるデバイス検索サーバのデバイス検索方法であって、
    前記第１のサブネット上のデバイスのデバイス／サーバタイプ及びＵＲＬ、並びに前記ネットワーク上のデバイス検索サーバのデバイス／サーバタイプ及びＵＲＬを登録する登録工程と、
    前記第１のサブネット上にある第１のデバイス検索装置または前記第２のサブネット上にある第２のデバイス検索装置のいずれかを送信先とする検索要求を受信する受信工程と、
    前記受信工程で前記検索要求が受信されたとき、前記登録工程で登録された情報から、前記検索要求が表すデバイス／サーバタイプに合致する情報を検索する検索工程と、
    前記検索工程における検索結果に応じて応答データを作成する作成工程と、
    前記作成された応答データを、前記送信先に送信する送信工程と、
    を備えることを特徴とするデバイス検索方法。
14. 請求項１２または１３記載のデバイス検索方法をコンピュータに実行させるためのコンピュータに読み取り可能なプログラム。

Images