JP2010211472A - サービス検索装置及び方法、サービス検索システム、並びにプログラム - Google Patents

Abstract

【課題】本発明は、検索サーバ等によるサービスの集中管理手法を用いることなく、サブネットを超えたサービスの検索が可能となり、検索サーバ等の設置コストや集中管理による管理コストを削減することができるサービス検索装置を提供する。
【解決手段】ＰＣ１１１は、マルチキャストによるサービス検索要求の応答として受信したＰｒｏｂｅＭａｔｃｈメッセージからサービスの重複のない一つのサービスリストを作成する。そして、ユニキャストパケットによるＰｒｏｂｅメッセージを一度も送信していないサービスがある場合、ユニキャストパケットによるサービスリストを要求する。次に、既に保持しているサービスリストと受信したサービスリストを照らし合わせ、重複するサービスを削除し、新たなサービスを保持していたサービスリストに加える。
【選択図】図２１

Description

本発明は、複数のサブネットに分散して存在するサービスを、検索サーバ等を用いることなく検索可能とするサービス検索装置及び方法、サービス検索システム、並びにプログラムに関するものである。

従来のサービス検索手法として、マルチキャスト或いはブロードキャストによる検索手法が用いられている。例えば、ルータを介して接続されたネットワークにおけるプリンタを、ブロードキャストパケットを用いて検索する方法が挙げられる。この検索方法では、検索を行うクライアントＰＣは、ルータからルーティング情報を取得し、ルーティング情報におけるサブネットワークのドメイン名からそのドメインにおけるブロードキャストアドレスを求める。そして、そのブロードキャストアドレスに宛てたプリンタ名を要求するブロードキャストパケットを、ルータを介して送出する。その結果、クライアントＰＣは、ブロードキャストパケットに対する応答パケットを受信することによってプリンタを検索することが可能となる（例えば、特許文献１参照）。

特開２０００−３５３１４３号公報

しかしながら、マルチキャストやブロードキャストによるサービス検索手法は、技術的に容易に実現できる反面、サブネットを超えてのサービス検索には限界がある。例えば、検索用のマルチキャストパケットのＴＴＬ（Time To Live）値を増加させれば、検索パケットはＴＴＬの数だけのサブネットを超えて到達可能であるが、ネットワーク全体にマルチキャストパケットのトラフィックが増加するという弊害がある。そのため、安易にＴＴＬ値を増加させるのは得策ではない。

なお、上述のＴＴＬ値はパケットの有効期間を表す値である。ＴＴＬ値は、最大２５５までの整数値で表され、パケットがルータなどを１回経由する度にその値が１減少する。ＴＴＬ値が０になったパケットはその時点で廃棄され、廃棄通知がパケットの送信元に届くようになっている。

ところで、マルチキャストやブロードキャストによるサービス検索手法とは別に、検索サーバによる検索手法も考えられている。これは、検索サーバに各々のサービスロケーションを登録し、検索者は検索サーバに問い合わせるという手法である。この検索手法を用いると、ネットワークトラフィックの低減とともにサブネットを超えたサービスの検索が可能となるが、必ず検索サーバが必要となり、その設置コストと管理コストが増大するという課題も併せ持っている。

本発明は、検索サーバ等によるサービスの集中管理手法を用いることなく、サブネットを超えたサービスの検索が可能となり、検索サーバ等の設置コストや集中管理による管理コストを削減することができるサービス検索装置及び方法、並びにプログラムを提供する。

上記目的を達成するために、請求項１記載のサービス検索装置は、それぞれ他のサービス提供装置の情報を保持している複数のサービス提供装置とネットワークを介して通信可能なサービス検索装置において、サービスを検索するためのサービス検索要求を送信する送信手段と、前記複数のサービス提供装置のうち、前記サービス検索要求に対して応答したサービス提供装置が保持する他のサービス提供装置の情報を、当該サービス提供装置から受信する受信手段と、前記他のサービス提供装置が保持する当該他のサービス提供装置とは異なるサービス提供装置の情報を、当該他のサービス提供装置から取得する取得手段と、前記受信手段および前記取得手段によって得た情報に基づいて、複数のサービス提供装置の情報を示すサービスリストを作成する作成手段とを備えることを特徴とする。

本発明によれば、検索サーバ等によるサービスの集中管理手法を用いることなく、サブネットを超えたサービスの検索が可能となり、検索サーバ等の設置コストや集中管理による管理コストを削減することができる。

また、本発明によれば、マルチキャストやブロードキャストによる検索を極力少なくすることができ、ネットワーク全体に広がるマルチキャストやブロードキャストのトラフィックを低減することが可能となる。

本発明を適用した実施形態の一例であるサービス検索システムの構成を示す図である。 図１のＭＦＰ１１２のハードウェア構成を示すブロック図である。 ＭＦＰ１１２のソフトウェア構成を示すブロック図である。 ＰＣ１１１のソフトウェア構成を示すブロック図である。 図１の各画像形成装置が定期的にマルチキャスト宛に送信するＰｒｏｂｅメッセージの一例を示す図である。 プリンタ１２１が応答するＰｒｏｂｅＭａｔｃｈメッセージの一例を示す図である。 ＭＦＰ１１２が応答するＰｒｏｂｅＭａｔｃｈメッセージの一例を示す図である。 プリンタ１４１が応答するＰｒｏｂｅＭａｔｃｈメッセージの一例を示す図である。 ＭＦＰ１１２が保持するサービスリストの一例を示す図である。 プリンタ１２１、ＭＦＰ１２２が保持するサービスリストの一例を示す図である。 ＭＦＰ１３１、プリンタ１３２が保持するサービスリストの一例を示す図である。 プリンタ１４１が保持するサービスリストの一例を示す図である。 プリンタ１５１が保持するサービスリストの一例を示す図である。 プリンタ１６１が保持するサービスリストの一例を示す図である。 ＰＣ１１１が送信するＰｒｏｂｅメッセージの一例を示す図である。 ＭＦＰ１１２が応答するＰｒｏｂｅＭａｔｃｈメッセージの一例を示す図である。 ＰＣ１１１が保持するサービスリストの一例を示す図である。 プリンタ１４１が応答するＰｒｏｂｅＭａｔｃｈメッセージの一例を示す図である。 ＰＣ１１１が保持するサービスリストの一例 図１のシステムにおける画像形成装置が定期的に行うサービス検索処理の一例を示すフローチャートである。 ＰＣ１１１が行うサービス検索処理の一例を示すフローチャートである。 ＰＣ１１１が送信するＧｅｔメッセージの一例を示す図である。 ＰＣ１１１が受信するＧｅｔＲｅｓｐｏｎｓｅメッセージの一例を示す図である。 図２１のステップＳ２１０７でＰＣ１１１に表示されるサービスリストの一例を示す図である。

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

図１は、本発明を適用した実施形態の一例であるサービス検索システムの構成を示す図である。

サブネット１には、サービスの検索に利用される情報処理装置としてのクライアントＰＣ（以下、単に「ＰＣ」と称する）１１１と、複写機能や画像形成機能等を備える複合機（以下、「ＭＦＰ」と称する）１１２が接続されている。サブネット２には、画像形成装置としてのプリンタ１２１、ＭＦＰ１２２が接続されている。サブネット３には、画像形成装置としてのＭＦＰ１３１、プリンタ１３２が接続されている。サブネット４には、画像形成装置としてのプリンタ１４１が接続されている。サブネット５には、画像形成装置としてのプリンタ１５１が接続されている。サブネット６には、画像形成装置としてのプリンタ１６１が接続されている。

サブネット１とサブネット２は、ルータ１２により相互に接続される。サブネット２とサブネット３は、ルータ２３により相互に接続される。サブネット１とサブネット４は、ルータ１４により相互に接続される。サブネット４とサブネット５は、ルータ４５により相互に接続される。サブネット５とサブネット６は、ルータ５６により相互に接続される。結果としてすべてのサブネット上の装置は相互に通信可能になっている。

ルータ１２，２３，１４，４５，５６は、一方のサブネットから受信したブロードキャストやマルチキャストを他方のサブネットに転送することが可能な構成となっている。

次に、図１のＭＦＰ１１２のハードウェア構成について説明する。なお、ＭＦＰ１２２，１３１は、ＭＦＰ１１２と同様のハードウェア構成を有するものとして、それらの説明は省略する。また、プリンタ１２１，１３２，１４１，１５１，１６１については、ＭＦＰ１１２のハードウェア構成からスキャナ部やスキャナ画像処理部、モデム等を除くハードウェア構成を有することから、それらの説明についても省略する。

図２は、図１のＭＦＰ１１２のハードウェア構成を示すブロック図である。

コントローラユニット２０００は、画像入力デバイスのスキャナ部２０７０や画像出力デバイスのプリンタ部２０９５に接続し、スキャナ部２０７０で読み取られた画像データをプリンタ部２０９５により印刷出力するコピー機能を実現するための制御を行う。また、コントローラユニット２０００は、ＬＡＮ１０６に接続することによって、画像情報やデバイス情報の入出力を行うための制御を行う。

また、コントローラユニット２０００は、具体的には、ＣＰＵ２００１を有し、ＣＰＵ２００１は、ＲＯＭ２００３に格納されているブートプログラムによりオペレーションシステム（ＯＳ）を立ち上げる。そしてこのＯＳ上でＨＤＤ（ハードディスクドライブ）２００４に格納されているアプリケーションプログラムを実行することによって各種処理を実行する。

ＣＰＵ２００１の作業領域としてはＲＡＭ２００２が用いられる。ＲＡＭ２００２は、作業領域とともに、画像データを一時記憶するための画像メモリ領域を提供する。ＨＤＤ２００４は、上記アプリケーションプログラムとともに、画像データを格納する。ＣＰＵ２００１には、システムバス２００７を介して、操作部ＩＦ（操作部インターフェイス）２００６、ネットワークＩＦ（ネットワークインターフェイス）２０１０、モデム２０５０及びイメージバスＩＦ（イメージインターフェイス）２００５が接続されている。操作部ＩＦ２００６は、タッチパネルを有する操作部２０１２とのインターフェイスであり、操作部２０１２に表示する画像データを操作部２０１２に対して出力する。また、操作部ＩＦ２００６は、操作部２０１２においてユーザにより入力された情報をＣＰＵ２００１に送出する。

ネットワークＩＦ２０１０は、ＬＡＮ１０６に接続され、ＬＡＮ１０６を介してＬＡＮ１０６上の各装置との間で情報の入出力を行う。モデム２０５０は、公衆回線（図示せず）に接続され、情報の入出力を行う。イメージバスＩＦ２００５は、システムバス２００７と画像データを高速で転送する画像バス２００８を接続し、データ構造を変換するためのバスブリッジである。

画像バス２００８は、ＰＣＩバスまたはＩＥＥＥ１３９４から構成される。画像バス２００８上には、ラスタイメージプロセッサ（以下、ＲＩＰという）２０６０、デバイスＩＦ２０２０、スキャナ画像処理部２０８０、プリンタ画像処理部２０９０、画像回転部２０３０、サムネイル作成部２０３５及び画像圧縮部２０４０が備わる。ＲＩＰ２０６０は、ＰＤＬコードをビットマップイメージに展開するプロセッサである。デバイスＩＦ２０２０には、スキャナ部２０７０及びプリンタ部２０９５が接続され、デバイスＩＦ２０２０は、画像データの同期系／非同期系の変換を行う。スキャナ画像処理部２０８０は、入力画像データに対し補正、加工、編集を行う。プリンタ画像処理部２０９０は、プリント出力画像データに対してプリンタ部２０９５の補正、解像度変換などを行う。

画像回転部２０３０は、画像データの回転を行う。画像圧縮部２０４０は、多値画像データをＪＰＥＧデータに、２値画像データをＪＢＩＧ、ＭＭＲ、ＭＨなどのデータに圧縮するとともに、その伸張処理を行う。

なお、ＰＣ１１１は、ＣＰＵ、ＲＡＭ、ＲＯＭ、ハードディスク、キーボード、及びディスプレイ等を備える汎用のパーソナルコンピュータであり、それらのハードウェア構成の説明については省略する。

図３は、ＭＦＰ１１２のソフトウェア構成を示すブロック図である。なお、ＭＦＰ１２２，１３１、プリンタ１２１，１３２，１４１，１５１，１６１については、ＭＦＰ１１２と同様のソフトウェア構成を有することから、それらの説明は省略する。また、図示例は、本発明に関連するソフトウェア構成のみを表し、他のソフトウェア構成については省略されている。

ＭＦＰ１１２は、サービス検索処理部３０１と、サービス情報送信部３０２と、サービス情報記憶部３０３と、情報管理部３０４とを備える。

サービス検索処理部３０１は、定期的にマルチキャストパケットを用いてサービス検索要求を発行し、他のサービスからの一つ以上の応答を受信する処理を行う。受信したサービスの情報は、ＩＰアドレスや各種情報とともにサービス情報記憶部３０３に保持され、適宜参照して使用することが可能である。

サービス情報送信部３０２は、ＰＣ１１１からのサービス検索要求に対してサービス情報記憶部３０３及び情報管理部３０４が保持するサービスの情報を送信する処理を行う。情報管理部３０４は、ＭＦＰ１１２自身のデバイス情報を管理する。

図４は、ＰＣ１１１のソフトウェア構成を示すブロック図である。なお、図示例は、本発明に関連するソフトウェア構成のみを表し、他のソフトウェア構成については省略されている。

サービス検索要求処理部４０１は、後述するサービス検索処理を行い、その結果を検索情報表示部４０２に表示する。

次に、図１のシステムにおけるＭＦＰ１１２やプリンタ１２１等の画像形成装置が定期的にマルチキャスト宛に送信するＸＭＬ形式のＰｒｏｂｅメッセージについて説明する。

図５は、図１の各画像形成装置が定期的にマルチキャスト宛に送信するＸＭＬ形式のＰｒｏｂｅメッセージの一例を示す図である。

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

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

一方、ｂｏｄｙ部はメッセージの内容に対応して構造が変化する。

Ｐｒｏｂｅメッセージにおいては、ｂｏｄｙ部に＜Ｐｒｏｂｅ＞タグが存在し、このメッセージがＰｒｏｂｅメッセージであることを示している。＜Ｐｒｏｂｅ＞タグの中には＜Ｔｙｐｅｓ＞タグが存在する場合があるが図５には存在しない。＜Ｔｙｐｅｓ＞タグは検索したいデバイスのタイプを指定するものである。

Ｐｒｏｂｅメッセージはサービス検索要求メッセージである。本実施形態では、このＰｒｏｂｅメッセージの、予め定められたパケットの有効期間を表すＴＴＬ値は２とする。ＴＴＬ値が２である場合は、隣接する隣のサブネットまでＰｒｏｂｅメッセージが到達することを意味する。例えば、図１におけるサブネット１に存在するＭＦＰ１１２が図５に示すＰｒｏｂｅメッセージを送信した場合、図１におけるサブネット２及びサブネット４までＰｒｏｂｅメッセージが到達する。

図６、図７及び図８は、サブネット２，４上のプリンタ１２１，１４１、ＭＦＰ１２２がサブネット１上のＭＦＰ１１２からのＰｒｏｂｅメッセージを受信した場合、その応答として返信するＸＭＬ形式のＰｒｏｂｅＭａｔｃｈメッセージの一例を示す図である。

ＰｒｏｂｅＭａｔｃｈメッセージにおいては、ｂｏｄｙ部に＜ＰｒｏｂｅＭａｔｃｈｅｓ＞タグが存在し、このメッセージがＰｒｏｂｅＭａｔｃｈメッセージであることを示している。＜ＰｒｏｂｅＭａｔｃｈｅｓ＞タグの中には＜ＰｒｏｂｅＭａｔｃｈ＞タグで示されるＰｒｏｂｅＭａｔｃｈ部が存在する。ＰｒｏｂｅＭａｔｃｈ部は複数存在することができ、それぞれのＰｒｏｂｅＭａｔｃｈ部が１個の検索結果に対応している。

ＰｒｏｂｅＭａｔｃｈ部の中の構造は、＜ＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅ＞タグ、＜Ｔｙｐｅｓ＞タグ、＜ＸＡｄｄｒｓ＞タグ、及び＜ＭｅｔａｄａｔａＶｅｒｓｉｏｎ＞タグが存在する。＜ＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅ＞タグの中には＜Ａｄｄｒｅｓｓ＞タグが存在し、デバイスを識別するアドレス情報を持つ。＜Ｔｙｐｅｓ＞タグはデバイスのタイプ情報を持つ。＜ＸＡｄｄｒｓ＞タグはデバイス情報を取得するためのＵＲＬを持つ。＜ＭｅｔａｄａｔａＶｅｒｓｉｏｎ＞タグはデバイス情報のバージョンを持つ。

図６〜図８に示すＰｒｏｂｅＭａｔｃｈメッセージには、プリンタ１２１、ＭＦＰ１２２、プリンタ１４１のそれぞれが提供するサービス情報のみが含まれる。しかしながら、プリンタ１２１，１４１、ＭＦＰ１２２がそれぞれ定期的にＰｒｏｂｅメッセージによってサービス検索を行った後には、自分自身が提供するサービス以外の、検索されたサービスも含まれることになる。

最終的に図１に示す複数の画像形成装置がそれぞれ図５のようなＰｒｏｂｅメッセージを定期的に送信することによりお互いにサービスリストを交換した後は、各画像形成装置は２ホップ先までのサービス情報のリストを保持することができるようになる。ＴＴＬ＝２のマルチキャスト検索により隣接するサブネットのサービスを検索し、検索されたサービスは、そのサービスが存在するサブネットのさらに隣接したサブネットまでのサービスリストを返信するからである。

次に、図１のシステムにおける各画像形成装置が最終的に保持するサービスリストの一例を図９〜図１４を参照して説明する。

図９は、ＭＦＰ１１２が最終的に保持するサービスリストの一例を示す図である。このリストには、２ホップ先のサブネット３及びサブネット５までのサービス情報が含まれる。

ＩＤ９０１は、それぞれの画像形成装置がサービスを一意に管理するために付加される識別子である。ＵＵＩＤ９０２はＡｄｄｒｅｓｓタグの値であり、サービスが持つ固有のＩＤ情報である。バージョン９０３はＭｅｔａｄａｔａＶｅｒｓｉｏｎタグの値である。ＩＰアドレス９０５はＵＲＬ９０６からＩＰアドレス部を抽出した値である。ＵＲＬ９０６はＸａｄｄｒｓタグの値である。

図１０は、プリンタ１２１及びＭＦＰ１２２が最終的に保持するサービスリストである。このリストには、図９と同様に、２ホップ先のサブネット４までのサービス情報が含まれる。

以下、同様に、図１１はＭＦＰ１３１及びプリンタ１３２、図１２はプリンタ１４１、図１３はプリンタ１５１、図１４はプリンタ１６１がそれぞれ最終的に保持するサービスリストを示している。

次に、図１のシステムにおけるＭＦＰ１１２やプリンタ１２１等の画像形成装置が定期的に隣接するサービスを検索する場合の処理について図２０を参照して説明する。

図２０は、図１のシステムにおける画像形成装置が定期的に行うサービス検索処理の一例を示すフローチャートである。

画像形成装置は、定期検索が開始されると、定期タイムアップが発生したか否かを判断する（ステップＳ２００１）。定期タイムアップが発生すると（ステップＳ２００１でＹＥＳ）、画像形成装置は、ＴＴＬ値により到達可能なネットワークに存在するサービスを検索するための検索パケットを、マルチキャストパケットで送信する（ステップＳ２００２）（定期サービス検索）。例えば、画像形成装置は、ＴＴＬ＝２のマルチキャストサービス検索パケットを送信する。送信されるマルチキャストサービス検索パケットは図５に示すようなＰｒｏｂｅメッセージである。

次に、画像形成装置は、一定時間中、応答パケットを受信する（ステップＳ２００３）。受信する応答パケットは図６〜図８に示すようなＰｒｏｂｅＭａｔｃｈメッセージである。画像形成装置は、一定時間が経過した後、受信したＰｒｏｂｅＭａｔｃｈメッセージから図９〜図１４に示すようなサービスリストを作成する（ステップＳ２００４）。受信した複数のＰｒｏｂｅＭａｔｃｈメッセージには重複するサービスが含まれる。そのため、ＵＵＩＤ等の情報により、サービスが重複しないようにサービスリストが作成される（サービスリスト保持）。以上の処理が終わると再び定期タイムアップ待ちに戻る（ステップＳ２００１）。

以上で説明したように、本発明の実施形態における画像形成装置は定期的にサービスリストを更新しながら保持する。なお、上述したＴＴＬ値については、その値が変更可能なように画像形成装置を構成するようにしてもよい。

次に、ＰＣ１１１がサービスを検索する方法について説明する。

図１５は、ＰＣ１１１が検索を開始した場合に送信するＰｒｏｂｅメッセージの一例を示す図である。

図示例のメッセージには、Ｔｙｐｅｓタグに「Ｐｒｉｎｔｅｒ」が指定されている。このような指定がなされると、タイプがプリンタにマッチするサービスがＰｒｏｂｅＭａｔｃｈメッセージで応答することを意味する。本実施形態では、このメッセージはＴＴＬ＝１のマルチキャストパケットとして送信されるため自サブネットの範囲のみに送信される。

図１６は、図１５に示すＰｒｏｂｅメッセージを受信したＭＦＰ１１２が応答として返信するＰｒｏｂｅＭａｔｃｈメッセージの一例を示す図である。

ＭＦＰ１１２は、サービスリストにおけるタイプが「ＭＦＰ」であるが、図９に示す通りタイプが「Ｐｒｉｎｔｅｒ」であるサービスのリストを保持しているため、ＰｒｏｂｅＭａｔｃｈメッセージで応答する。ＰｒｏｂｅＭａｔｃｈメッセージに含まれるのは、プリンタ１２１、プリンタ１３２、プリンタ１４１、及びプリンタ１５１の情報である。

図１７は、図１６に示すＰｒｏｂｅＭａｔｃｈメッセージを受信した結果としてＰＣ１１１が保持するサービスリストの一例を示す図である。

図１８は、ＰＣ１１１がプリンタ１４１に向けてユニキャストで図１５に示すＰｒｏｂｅメッセージを送信した場合にプリンタ１４１が応答するＰｒｏｂｅＭａｔｃｈメッセージの一例を示す図である。

プリンタ１４１は、図１２に示す通りタイプが「Ｐｒｉｎｔｅｒ」であるサービスのリストを保持しているため、ＰｒｏｂｅＭａｔｃｈメッセージで応答する。ＰｒｏｂｅＭａｔｃｈメッセージに含まれるのは、プリンタ１２１、プリンタ１４１、プリンタ１５１、及びプリンタ１６１の情報である。

図１９は、図１８に示すＰｒｏｂｅＭａｔｃｈメッセージを受信した結果としてＰＣ１１１が保持するサービスリストの一例を示す図である。

次に、ＰＣ１１１がサービス検索を開始した場合の処理について図２１を参照して説明する。

図２１は、ＰＣ１１１が行うサービス検索処理の一例を示すフローチャートである。

ＰＣ１１１は、サービス検索処理が開始されると、ＴＴＬ＝１のマルチキャストパケットによるサービス検索要求をネットワーク（サブネット１等）に送信する（ステップＳ２１０１）。送信されるサービス検索要求は、例えば図１５に示すＰｒｏｂｅメッセージである。ＴＴＬ＝１であるので、このパケットは同一サブネット内のみに送信される。

次に、ＰＣ１１１は、一定時間中、応答パケットを受信する（ステップＳ２１０２）。受信する応答パケットは図１６に示すようなＭＦＰ１１２から送信されるＰｒｏｂｅＭａｔｃｈメッセージである。ＰＣ１１１からのサービス検索要求に対する応答として、保持しているサービスリストを送信する（サービスリスト送信）機能は、ＭＦＰ１１２だけでなく、図１に示す各画像形成装置が備えるものとする。

ＰＣ１１１は、一定時間が経過した後、受信したＰｒｏｂｅＭａｔｃｈメッセージからサービスの重複のない一つのサービスリストを作成する（ステップＳ２１０３）。

次に、ＰＣ１１１は、ユニキャストパケットによるＰｒｏｂｅメッセージを一度も送信していないサービスがあるか否かを判断する（ステップＳ２１０４）。この結果、新たなサービスは無い場合は（ステップＳ２１０４でＮＯ）、検索の結果としてサービスリストを表示（ステップＳ２１０７）して、本処理を終了する。一方、新たなサービスがある場合は（ステップＳ２１０４でＹＥＳ）、ユニキャストパケットによりサービスリストを要求する（ステップＳ２１０５）。このサービスリストの要求も、例えば図１５に示すＰｒｏｂｅメッセージである。つまり、ステップＳ２１０１で送信したサービス検索要求と同じパケットが今度はマルチキャストではなくユニキャストで送信されることになる。

次に、ＰＣ１１１は、サービスリストの要求に対する応答としてサービスリストを受信する（ステップＳ２１０６）。受信したサービスリストは、例えば、図１９に示すＰｒｏｂｅＭａｔｃｈメッセージである。このメッセージで受信したサービスにはプリンタ１６１が新たに含まれるが、その他のサービスの情報は既に保持している情報である。

ＰＣ１１１は、サービスリストを受信すると、再度、既に保持しているサービスリストと受信したサービスリストを照らし合わせ、重複するサービスを削除し、新たなサービスを保持していたサービスリストに加える（ステップＳ２１０３）。そして、再び新たなサービスが発見されたか否かを判断する（ステップＳ２１０４）。この場合、プリンタ１６１が新たに発見されたサービスである。以後、ステップＳ２１０３〜Ｓ２１０６の処理を繰り返し、新たなサービスが発見されなかった時点で結果としてのサービスリストを表示して（ステップＳ２１０７）、本処理を終了する。

ステップＳ２１０７にて、サービス検索の結果リストを表示する場合、ＰＣ１１１は、発見された全てのサービスのＵＲＬ宛てに図２２に示すＸＭＬ形式のＧｅｔメッセージを送信する。そして、ＰＣ１１１は、その応答として、図２３に示すＸＭＬ形式のＧｅｔＲｅｓｐｏｎｓｅメッセージを受信し、サービスのより詳細な情報を取得した後、検索情報表示部４０２により図２４に示すサービス検索結果リストを表示する。

図２２に示すＧｅｔメッセージは、ｈｅａｄｅｒ部のみを持つメッセージとなっている。ｈｅａｄｅｒ部の＜Ａｃｔｉｏｎ＞タグにおいて、このメッセージがＧｅｔメッセージであることを示している。

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

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

ＭｅｔａｄａｔａＳｅｃｔｉｏｎ部は＜ＴｈｉｓＭｏｄｅｌ＞タグを持っており、デバイスのモデルごとに異なる情報が格納される。＜Ｍａｎｕｆａｃｔｕｒｅｒ＞タグはデバイスの製造会社名、＜Ｍａｎｕｆａｃｔｕｒｅｒ＞タグはデバイス製造会社のＵＲＬ、＜ＰｒｅｓｅｎｔａｔｉｏｎＵＲＬ＞はデバイスの情報を示すＵＲＬ、＜ＭｏｄｅｌＮａｍｅ＞タグはデバイスのモデル名を示している。

ＭｅｔａｄａｔａＳｅｃｔｉｏｎ部は＜Ｒｅｌａｔｉｏｎｓｈｉｐ＞タグを持っており、デバイスが持つ内部サービスの情報が格納される。本実施形態では、内部サービスとは画像形成装置が提供するプリントサービスである。

＜Ｒｅｌａｔｉｏｎｓｈｉｐ＞タグはさらにその直下に＜Ｈｏｓｔｅｄ＞タグを持ち、その中に＜ＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅ＞タグ、＜Ｔｙｐｅｓ＞タグ、＜ＳｅｒｖｉｃｅＩｄ＞タグが存在する。＜ＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅ＞タグの中には＜Ａｄｄｒｅｓｓ＞タグが存在し、サービスを利用するためのアドレス情報を持つ。＜Ｔｙｐｅｓ＞タグはサービスのタイプ情報を持つ。＜ＳｅｒｖｉｃｅＩｄ＞タグはデバイス内でサービスを識別するための識別子を持つ。

図２４は、図２１のステップＳ２１０７でＰＣ１１１に表示されるサービスリストの一例を示す図である。

図２４において、入力フィールド２４０１は、検索条件を入力するフィールドである。また、検索実行ボタン２４０２は、検索を開始を指示するボタンである。検索開始ボタンの押下をトリガとして、図２１に示した処理を実行し、結果として検索結果フィールド２４０３に検索結果が表示される。

上記実施形態によれば、マルチキャストによるサービス検索要求の応答として受信したＰｒｏｂｅＭａｔｃｈメッセージからサービスの重複のない一つのサービスリストを作成する。そして、ユニキャストパケットによるＰｒｏｂｅメッセージを一度も送信していないサービスがある場合、ユニキャストパケットによるサービスリストを要求する。次に、既に保持しているサービスリストと受信したサービスリストを照らし合わせ、重複するサービスを削除し、新たなサービスを保持していたサービスリストに加える。これらを繰り返して重複のないサービスリストを作成する。このような方法を用いてサービス検索を行うことにより、検索サーバ等によるサービスの集中管理手法を用いることなく、サブネットを超えたサービスの検索が可能となり、検索サーバ等の設置コストや集中管理による管理コストを削減することができる。

また、マルチキャストやブロードキャストによる検索を極力少なくすることができ、ネットワーク全体に広がるマルチキャストやブロードキャストのトラフィックを低減することが可能となる。

上記実施形態では、図２１に示す処理において、新たなサービスが発見されなくなるまでステップＳ２１０３〜Ｓ２１０６を繰り返し行うように構成されているが、繰り返す回数の上限を設定可能に構成してもよい。

なお、上記実施形態では、サービスを提供するサービス提供装置の一例としてプリンタやＭＦＰ等の画像形成装置を用いて説明した。この場合、サービス提供装置によって提供されるサービスは、プリントサービスやスキャンサービス、ファックス送受信サービス等である。しかし、サービス提供装置は画像形成装置に限らずその他の装置であってもよい。例えば、ネットワークを介してPCに所望のアプリケーションソフトや計算処理等を提供する装置であってもよい。

また、本発明の各工程は、ネットワーク又は各種記憶媒体を介して取得したソフトウエア（プログラム）を画像形成装置や情報処理装置等の処理装置（CPU、プロセッサ）にて実行することでも実現できる。

１１１ ＰＣ
１１２，１２２，１３１ ＭＦＰ
１２１，１３２，１４１，１５１，１６１ プリンタ
３０１ サービス検索処理部
３０２ サービス情報送信部
３０３ サービス情報記憶部
３０４ 情報管理部
４０１ サービス検索要求処理部
４０２ 検索情報表示部
２０００ コントローラユニット

Claims (11)

1. それぞれ他のサービス提供装置の情報を保持している複数のサービス提供装置とネットワークを介して通信可能なサービス検索装置において、
   サービスを検索するためのサービス検索要求を送信する送信手段と、
   前記複数のサービス提供装置のうち、前記サービス検索要求に対して応答したサービス提供装置が保持する他のサービス提供装置の情報を、当該サービス提供装置から受信する受信手段と、
   前記他のサービス提供装置が保持する当該他のサービス提供装置とは異なるサービス提供装置の情報を、当該他のサービス提供装置から取得する取得手段と、
   前記受信手段および前記取得手段によって得た情報に基づいて、複数のサービス提供装置の情報を示すサービスリストを作成する作成手段とを備えることを特徴とするサービス検索装置。
2. 前記送信手段は、前記サービス検索要求をマルチキャストによって送信し、前記取得手段は、前記他のサービス提供装置に対してユニキャストによって情報を取得する要求を送信することによって当該情報を取得することを特徴とする請求項１記載のサービス検索装置。
3. 前記送信手段は、ＴＴＬの値が１であるマルチキャストパケットを用いて前記サービス検索要求を送信することを特徴とする請求項１または２記載のサービス検索装置。
4. 前記サービス検索要求に対して応答したサービス提供装置は、前記サービス検索装置と同じサブネットに存在するサービス提供装置であって、前記他のサービス提供装置は、前記サービス検索装置と異なるサブネットに存在するサービス提供装置であることを特徴とする請求項１乃至３のいずれかに記載のサービス検索装置。
5. それぞれ他のサービス提供装置の情報を保持している複数のサービス提供装置とネットワークを介して通信可能なサービス検索装置のサービス検索方法において、
   サービスを検索するためのサービス検索要求を送信する送信工程と、
   前記複数のサービス提供装置のうち、前記サービス検索要求に対して応答したサービス提供装置が保持する他のサービス提供装置の情報を、当該サービス提供装置から受信する受信工程と、
   前記他のサービス提供装置が保持する当該他のサービス提供装置とは異なるサービス提供装置の情報を、当該他のサービス提供装置から取得する取得工程と、
   前記受信工程および前記取得工程にて得た情報に基づいて、複数のサービス提供装置の情報を示すサービスリストを作成する作成工程とを備えることを特徴とするサービス検索方法。
6. 前記送信工程は、前記サービス検索要求をマルチキャストによって送信し、前記取得工程は、前記他のサービス提供装置に対してユニキャストによって情報を取得する要求を送信することによって当該情報を取得することを特徴とする請求項５記載のサービス検索方法。
7. 前記送信工程は、ＴＴＬの値が１であるマルチキャストパケットを用いて前記サービス検索要求を送信することを特徴とする請求項５または６記載のサービス検索方法。
8. 前記サービス検索要求に対して応答したサービス提供装置は、前記サービス検索装置と同じサブネットに存在するサービス提供装置であって、前記他のサービス提供装置は、前記サービス検索装置と異なるサブネットに存在するサービス提供装置であることを特徴とする請求項５乃至７のいずれかに記載のサービス検索方法。
9. 請求項５乃至８のいずれか１項に記載のサービス検索方法をコンピュータに実行させるためのコンピュータに読み取り可能なプログラム。
10. 予め定められたパケットの有効期間を表す値により到達可能なネットワークに存在するサービスをマルチキャストパケットを使用して定期的に検索する定期サービス検索手段と、
    前記定期サービス検索手段により検索された少なくとも一つのサービスを重複することなくリストとして保持するサービスリスト保持手段と、
    情報処理装置からのサービス検索要求に対する応答として、前記サービスリスト保持手段により保持しているサービスリストを送信するサービスリスト送信手段とを備えることを特徴とするサービス提供装置。
11. 前記定期サービス検索手段において、予め定められるＴＴＬ値を変更可能とする変更手段をさらに備えることを特徴とする請求項１０記載のサービス提供装置。