情報処理装置及び情報処理方法及びプログラム
【課題】プラグアンドプレイで認識されたデバイスに対応するデバイスドライバを自動インストールすることで、必要以上のデバイスドライバがインストールされてしまう。
【解決手段】プロキシサーバ３００は、クライアントからデバイスに対するデバイス情報要求メッセージをフックし、デバイスの共有度順位等に応じた順序でデバイス情報応答メッセージをクライアントに返す。この際プロキシサーバ３００は、クライアントＰＣ１００からのデバイス情報要求メッセージに対して、ネットワークにおける共有度の高い（利用頻度の高い）デバイスおよびサービスを応答する。この応答に基づいて、クライアントＰＣ１００側には、共有度の高いサービスを利用するためのドライバやアプリケーションがセットアップされる。
【解決手段】プロキシサーバ３００は、クライアントからデバイスに対するデバイス情報要求メッセージをフックし、デバイスの共有度順位等に応じた順序でデバイス情報応答メッセージをクライアントに返す。この際プロキシサーバ３００は、クライアントＰＣ１００からのデバイス情報要求メッセージに対して、ネットワークにおける共有度の高い（利用頻度の高い）デバイスおよびサービスを応答する。この応答に基づいて、クライアントＰＣ１００側には、共有度の高いサービスを利用するためのドライバやアプリケーションがセットアップされる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、たとえばネットワークに対応した周辺装置に接続される情報処理装置及び情報処理方法及びそのプログラムに関するものである。
【背景技術】
【０００２】
従来、ネットワーク環境における共有プリンタの監視や管理処理は、ＩＴ（情報技術）マネジャとサーバに集約され、ユーザへメールサービスを利用して通知する形態が一般的であった。管理処理の特定プロセスでの手動作業をメールサービスへおきかえ自動化することでＩＴマネジャやユーザの負担軽減をはかった。サーバはインストーラを作成し、それを添付したメールを配布し ユーザが実行することでネットワーク共有プリンタのインストールはおこなわれていた（例えば特許文献１参照）。ネットワーク共有プリンタを監視、削除される際のユーザへの通知はサーバからメールによっておこなわれていた（例えば特許文献２参照）。
【０００３】
一方、インターネットやホームネットワークなど、ネットワークの拡張に伴い、例えば、ＰＤＡや携帯電話等のユーザインタラクティブなデバイス、スキャナ、プリンタ、複写機、デジタルカメラ等の画像処理装置におけるネットワーク対応が進んでいる。また、テレビ、エアコン、冷蔵庫等の家電製品などに至るまで様々なデバイスのネットワーク対応も進んでいる。それに伴い、ネットワーク対応デバイスを利用する上での利便性を高め、また管理の容易性を高めるために、ネットワークデバイスを管理する機能を提供するさまざまなプロトコルやアーキテクチャが提案されている(特許文献３，４)。提供される機能には、たとえばサービスを提供するネットワークデバイスの探索や、ネットワークデバイスを制御するためのアプリケーションソフトウエア、ユーティリティソフトウエア、オペレーティングシステム等の自動セットアップなどがある。
【０００４】
また、ネットワークデバイスの管理を自動化するための試みもある。たとえば、マイクロソフト社が主体となって、ＵＰｎＰ（登録商標）、およびＷＳＤ:Web Services for Devices (WS-Discovery/WS-MetadataExchange）の策定が進められている。これは、デバイスをネットワークに接続するだけでそのデバイスを使用可能とする、いわゆるプラグアンドプレイを実現するためのものである。
【０００５】
さらに、ネットワーク環境における共有プリンタの監視や管理処理は、ＩＴ（情報技術）マネジャとサーバに集約され、ユーザへメールサービスを利用して通知する形態が一般的であった。しかし、ＩＴマネジャやユーザの負担軽減を図るため、管理処理の特定プロセスでの手動作業をメールサービスへおきかえ自動化する技術が開示されている（特許文献４）。特許文献４に記載のサーバはインストーラを作成し、それを添付したメールを配布し ユーザが実行することでネットワーク共有プリンタのインストールがおこなわれていた。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０００−２１５１２８号公報
【特許文献２】特開２００４−２８０２１８号公報
【特許文献３】特開２００４−０３８９５６号公報
【特許文献４】特開２００４−３６２５９４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、ネットワークデバイスにプラグアンドプレイが普及することによってその利便性が向上する一方で、ネットワークに接続されたデバイスのドライバが自動でインストールされてしまうことに起因する弊害も生じる。その弊害のひとつとして、クライアントコンピュータに導入（インストール）されたドライバの数が増大し続ける点が挙げられる。
【０００８】
例えば、デバイスドライバが自動的にインストールされる場合、ユーザが必要としないデバイスドライバまでもインストールされる状況が考えられる。その結果、ユーザが利用したいネットワークデバイスの選択が困難となるだけでなく、利用実績が少なく、過去において好んで選択されないデバイスに対して印刷指示を行ってしまう恐れもある。
【０００９】
本発明は上記課題を解決するために、ネットワークプラグアンドプレイ機能により検出されたネットワークデバイスのうちから、共有度が高いデバイスを選択的に通知することを目的とする。
【課題を解決するための手段】
【００１０】
上記目的を達成するために本発明は以下の構成を備える。すなわち、
端末と通信可能な情報処理装置であって、
端末による利用実績がある周辺機器があるか判定する判定手段と、
前記判定手段によって前記周辺機器があると判定された場合、利用実績が新しい順に列挙された周辺機器の情報を前記端末に通知する通知手段とを有し、
前記利用実績は、印刷処理の利用実績であることを特徴とする。
【発明の効果】
【００１１】
本発明により、複数のネットワークデバイスが接続されたネットワークにコンピュータを接続した場合でも、利用される可能性の高いデバイスに絞って通知できる。
【図面の簡単な説明】
【００１２】
【図１】本発明の一実施形態としてのネットワークプラグアンドプレイシステムの構成を示すブロック図
【図２】クライアントからデバイスへの検索制御フロー図
【図３】メタデータの形式を示した図
【図４】Ｐｒｏｂｅ Ｍａｔｃｈメッセージの内容を示した図
【図５】プロキシサーバ３００をもちいた接続フロー図
【図６】本発明のプロキシサーバ３００制御の概要説明図
【図７】本発明のプロキシサーバ３００の内部構成図
【図８】本発明の共有度判断の概念図
【図９】本発明のデバイス共有度の順位表の図
【図１０】本発明でクライアントに表示されるインストールＵＩ図
【図１１】プロキシサーバ３００からのデバイス列挙制御のフローチャート
【図１２】プロキシサーバ３００の順位表を利用した設定ＵＩの一例を示す図
【図１３】プロキシサーバ３００でデバイス個別選択する場合の設定ＵＩの一例を示す図
【図１４】メッセージ参照機能をプラグアンドプレイシステムがもっている場合のフロー図
【図１５】デバイス離脱時のプロキシサーバ３００制御のフローチャート
【図１６】クライアント及びデバイスのブロック図
【図１７】プロキシサーバ３００がフックしたメッセージを集計する手順のフロー図
【図１８】ネットワークプラグアンドプレイシステムにおけるメッセージシーケンス図
【図１９】プロキシサーバ３００が保持するクライアントリストの一例を示す図
【図２０】プロキシサーバ３００が保持するデバイスリストの一例を示す図
【図２１】共有度順位情報を反映したデバイスリストの一例を示す図
【図２２】クライアントに送信するデバイス情報の一例を示す図
【図２３】プロキシサーバ３００の処理を説明するフロー図
【図２４】デバイス情報要求方法を選択するためのダイアログの一例を示す図
【図２５】デバイス情報要求に従って表示されるデバイスリストの一例を示す図
【図２６】プロキシサーバ３００が管理するメッセージ要求数の一例を示す図
【図２７】デバイス情報要求に従って表示されるデバイスリストの一例を示す図
【図２８】本願第５実施形態のシーケンス図の一例を示す図
【図２９】第５実施形態のプロキシサーバ３００が実行する処理のフローチャート
【発明を実施するための形態】
【００１３】
［第１実施形態］
以下に、図面を参照して、この発明の好適な実施の形態を例示的に詳しく説明する。ただし、この実施の形態に記載されているプロトコル、バージョン、アドレス、その他の数値等は、特に特定的な記載がない限りは、この発明の範囲をそれらのみに限定する趣旨のものではない。
【００１４】
＜クライアントとデバイスの接続の基本説明＞
図１は、本発明の一実施形態としてのネットワークプラグアンドプレイシステムの構成を示すブロック図である。クライアントＰＣ（クライアントデバイスとも言う）１００は、通信機能としてＥｔｈｅｒｎｅｔ（登録商標）等のＬＡＮ，ＷｉＦｉ（登録商標）（ＩＥＥＥ８０．１１ａ／ｂ／ｇ）等の無線ＬＡＮ，Ｂｌｕｅｔｏｏｔｈ（登録商標）に対応している。それぞれの通信機能は、Ｅｔｈｅｒｎｅｔ（登録商標）コントローラ０１０１、ＷｉＦｉ（登録商標）コントローラ０１０２、Ｂｌｕｅｔｏｏｔｈ（登録商標）コントローラ０１０３により制御される。これらコントローラの上位レイヤには、ＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック０１０４が備えられ、そのプロトコルスタック上にＨＴＴＰ処理部０１０５が備えられている。ＨＴＴＰ処理部０１０５は、ＨＴＴＰリクエストの解析、およびレスポンス処理を行う。
【００１５】
ＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック０１０４、およびＨＴＴＰ処理部０１０５の上位層には、Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ（ＳＯＡＰ）プロセッサ０１０６が備えられている。プラグアンドプレイモード設定ユーティリティ０１０７は、ＳＯＡＰプロセッサ０１０６を介して、ｅＸｔｅｎｓｉｂｌｅ ＭａｒｋｕｐＬａｎｇｕａｇｅ（ＸＭＬ）で記述されたデータの双方向通信を実現する。ＷＳＤモジュール０１０８、およびユーティリティ０１１４、アプリケーション０１１５それぞれも同様である。
【００１６】
ネットワークマネージャ０１０９は、Ｅｔｈｅｒｎｅｔ（登録商標）コントローラ０１０１、ＷｉＦｉ（登録商標）コントローラ０１０２、Ｂｌｕｅｔｏｏｔｈ（登録商標）０１０３コントローラを管理するモジュールである。ネットワークマネージャ０１０９は、各コントローラの設定情報、通信状態に関する情報を取得する機能を備える。
【００１７】
ＷＳＤモジュール０１０８は、ＳＯＡＰプロセッサ０１０６を介して、ネットワークデバイスから通知されるＨｅｌｌｏメッセージに対する応答処理、および、ネットワークデバイス検索のためのＰｒｏｂｅメッセージの発行処理を実行する。また、ＧｅｔＭｅｔａｄａｔａメッセージを発行することで、ネットワークデバイスの属性情報を取得する。属性情報は、デバイスの備えるハードディスク等の記憶部に記憶されている。
【００１８】
ネットワークデバイスの属性情報には、そのデバイスのデバイスＩＤや、そのデバイスにより提供されるサービスＩＤが含まれている。サービスとは、デバイスが提供する個々の機能を指す。たとえばデバイスがディジタル複合機であり、印刷機能とスキャン機能をあわせ持っていれば、プリントサービスとスキャンサービスとが利用できることを含んだ情報が提供される。さらに、プリント機能が複数のＰＤＬに対応していれば、各ＰＤＬに対して提供されるプリント機能はそれぞれ独立したサービスである。
【００１９】
これらのメッセージ処理により、クライアントＰＣ１００がネットワークデバイスを発見した場合、ＷＳＤモジュール０１０８はプラグアンドプレイコントローラ０１１１に対して、発見したネットワークデバイスの属性情報を通知する。プラグアンドプレイコントローラ０１１１は該属性情報をもとに該当するドライバ、ユーティリティソフトウエアをメモリコントローラ０１１０を介してメモリより読み込み、インストールを実行する機能を備える。
【００２０】
アプリケーション０１１５は、例えばワードプロセッサなどのアプリケーションプログラムである。アプリケーション０１１５は、編集した文書をネットワークデバイス・プリンタにより印刷するための機能を有する。その際、アプリケーション０１１５から出力された文書データは、プラグアンドプレイコントローラ０１１１によりインストールされたドライバ、ユーティリティを介して、ネットワーク対応デバイス２００に送信される。
【００２１】
一方、ネットワーク対応デバイス２００、すなわち本実施の形態ではネットワーク対応型プリンタは以下の構成を有する。ネットワーク対応デバイス２００は、Ｅｔｈｅｒｎｅｔ（登録商標），ＷｉＦｉ（登録商標）（ＩＥＥＥ８０．１１ａ／ｂ／ｇ），Ｂｌｕｅｔｏｏｔｈ（登録商標）に対応した通信機能を持つ。各通信機能は、それぞれＥｔｈｅｒｎｅｔ（登録商標）コントローラ０１１６、ＷｉＦｉ（登録商標）コントローラ０１１７により制御される。これらコントローラの上位レイヤには、ＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック０１１８が備えられ、そのプロトコルスタック上にＨＴＴＰ処理部０１１９が備えられる。ＨＴＴＰ処理部０１１９は、ＨＴＴＰリクエストの解析、およびレスポンス処理を行う。
【００２２】
ＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック０１１８、およびＨＴＴＰ処理部０１１９上位層にはＳｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ（ＳＯＡＰ）プロセッサ０１２０を備える。そのため、ＷＳＤモジュール０１２１、およびプリンタコントローラ０１２２が、それぞれ該処理部を介してｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（ＸＭＬ）で記述されたデータの双方向通信を実現可能となる。
【００２３】
ここで、ＷＳＤモジュール０１２１は、ＳＯＡＰプロセッサ０１２０を介してネットワークに接続した際に、Ｈｅｌｌｏメッセージの送信、およびクライアントＰＣ１００から発行されるＰｒｏｂｅメッセージに対する応答処理を実行する。
【００２４】
また、クライアントＰＣ１００から発行されたＧｅｔＭｅｔａｄａｔａメッセージに応じ、ネットワーク対応デバイスは、属性情報（本実施形態の場合、ネットワーク対応プリンタが持つ属性情報）を返信する。属性情報は、たとえばデバイス自体の情報（デバイス情報）であり、デバイスが提供するサービスの情報（サービス情報）である。
【００２５】
＜印刷システムのハードウェア構成＞
図１６は、本発明の実施の形態である情報処理装置とプリンタのハードウェア構成を示すブロック図である。図１６では、プロキシサーバ３００とネットワークデバイスであるプリンタ３０００とがネットワーク３１を介して接続された構成となっている。プロキシサーバ３００ではコンピュータ本体２０００に対して外部装置であるキーボード９、ＣＲＴ１０、ハードディスク１１等が接続されている。コンピュータ本体２０００はＣＰＵ１を備え、ＣＰＵ１はＲＯＭ３やハードディスク１１に記憶された制御プログラムやアプリケーションをＲＡＭ２に展開して演算を行うことができる。また、外部装置であるキーボード９からの入力を制御しているのがキーボードコントローラ（ＫＢＣ）５である。また、ＣＲＴ１０の表示を制御しているのがＣＲＴコントローラ（ＣＲＴＣ）６であり、ハードディスク１１に対して入出力の制御を行っているのがハードディスクコントローラ（ＨＤＣ）７である。ＮｅｔＣ８はネットワークコントローラであり、ネットワーク３１を介してプリンタ３０００に接続されて、プリンタコントローラ部４０００との間の通信制御を行っている。
【００２６】
これらＣＰＵ１、ＲＡＭ２、ＲＯＭ３、ＫＢＣ５、ＣＲＴＣ６、ＨＤＣ７、ＮｅｔＣ８はそれぞれシステムバス４によって接続され、各デバイスをＣＰＵ１が総括的に制御している。ＨＤＤ１１には、ネットワークデバイス、特に本実施形態ではネットワークプリンタの利用頻度を順位付けした共有度順位表０９０１およびデバイス情報やサービス情報のリスト（デバイスリストあるいは機器情報）１１ａが保存されている。共有度順位表０９０１は、プロキシサーバ３００にネットワークデバイスの名称（識別子）のほか、プロキシサーバ３００が収集した情報（図１７等で説明する）が含まれている。デバイスリスト１１ａや共有度順位表０９０１は、ハードディスク１１に保存され、ＣＰＵ１によりアクセスされる際にＲＡＭ２にロードされる。なお、共有度順位表は共有度順位情報ともいう。ＨＤＤ１１やＲＡＭ２のデバイスリスト１１ａは、保存手段として機能する。あるデバイスの共有度とは、端的にはそのデバイスを使用したクライアントの数である。ただし、重複するクライアントは排除される。本実施形態では、共有度とは、図９に例示するように、クライアント数とその他の指標を複合させた複合的な指標である。
【００２７】
本実施形態では、プロキシサーバ３００としてパーソナルコンピュータ（ＰＣ）を想定している。つまり、プロキシサーバ３００は、情報処理装置である。しかし、本発明を実施可能な形態であれば、プロキシサーバ３００はＰＣに限定するものではなく、ＰＤＡなどの携帯情報端末や携帯電話、ディジタル家電等をクライアントとしてもよい。いずれの装置も、特定用途の入出力デバイス等を除けば、図１のプロキシサーバ３００と同様の構成を有する。
【００２８】
ネットワークプリンタ３０００において、プリンタＣＰＵ２１は、ＲＯＭ２３のプログラム用領域に記憶された制御プログラムを実行する。制御プログラムの実行により、バス２４に接続される各種のデバイスとのアクセスを総括的に制御し印刷部２６を介して接続される印刷機構部２８（プリンタエンジン）に印刷データとしての画像信号が出力される。
【００２９】
プリンタＣＰＵ２１はネットワークコントローラ（ＮｅｔＣ）２５を介してプロキシサーバ３００及び不図示のクライアントＰＣ１００との通信処理が可能である。通信によりネットワークプリンタ３０００内の情報等をプロキシサーバ３００およびクライアントＰＣ１００に通知可能に構成されている。ＲＡＭ２２はプリンタＣＰＵ２１の主メモリ、ワークエリアなどとして機能する。また、ＲＡＭ２２はクライアントＰＣ１００（不図示）より受信した印刷データや画像ビットマップデータを格納しておくための描画メモリ、ビデオ信号情報格納領域、その他としても使用される。ハードディスクコントローラ２７にて制御されるハードディスク２９は印刷ジョブデータのＢＯＸ保存などのために使用される。操作パネル３０はユーザがネットワークプリンタ３０００を操作する際のユーザインターフェースであり各種スイッチやＬＥＤ表示機器の他、タッチパネル式の液晶パネルなどで構成される。
【００３０】
ハードディスク２９には、プリンタ３０００の構成を示す構成情報データベース２９０１が保存されている。構成情報データベースは、各種のデータを含むデータベースである。構成情報データベース２９０１には、デバイスタイプ情報、サービス情報、デバイスの使用頻度情報、デバイス機能情報、製造メーカ情報など、デバイス情報やサービス情報の基礎となる情報が含まれている。なお、デバイス機能情報とは、印刷速度情報、カラー印刷機能の有無を示すカラー機能情報、最高解像度情報、両面印刷機能の有無を示す両面機能情報等である。デバイスタイプ情報は、たとえば当該デバイスが単機能プリンタや、複写機などデバイスのタイプを示す。サービス情報は、当該タイプのデバイスにより提供されるサービスを示す。たとえばプリンタであれば、ｐｏｓｔｓｃｒｉｐｔ（登録商標）など、対応するＰＤＬの種類を示す情報がサービス情報として登録されている。なお、本例ではＰＤＬの種類はＵＲＩで示される。
【００３１】
なお、ネットワークプリンタ３０００は本発明の機能を実施できる装置であればシングルファンクションプリンタでもスキャナやコピー、ファクシミリ等の機能も備えたマルチファンクションプリンタでもよい。印刷機構部２８としてレーザービームプリンタやインクジェットの印刷機構を用いたプリンタ、サーマルプリンタなどいかなるプリント方式を用いていようが、本発明の機能に制限をするものではない。また、図１に記述したクライアントＰＣのハードウェア構成も、図１６の情報処理装置３００と同様である。
【００３２】
＜デバイス検索手順＞
図２（Ａ）を参照して、クライアントＰＣ１００より、ネットワーク上で利用可能な状態にあるネットワーク対応デバイス２００を検索する場合の制御の流れフロー形式で説明する。なお、図２（Ａ）、図２（Ｂ）と同様のシーケンスは、プロキシサーバ３００とネットワーク対応デバイス２００との間においても実行される。プロキシサーバ３００は、図２（Ａ）、図２（Ｂ）のシーケンスを通して、ネットワーク対応デバイス２００からデバイス情報及びサービス情報を収集し、デバイスリスト１１ａとしてたとえばハードディスク１１に保存する。
【００３３】
ステップ０２０１：
クライアントＰＣ１００のユーティリティ０１１４、あるいはアプリケーション０１１５は、ＳＯＡＰプロセッサ０１０６に対してＰｒｏｂｅメッセージの送信を要求する。きっかけは例えば電源の投入などである。その要求に応じて、ＳＯＡＰプロセッサ０１０６はＰｒｏｂｅメッセージを生成し、プロトコルスタック０１０４を介してマルチキャストアドレス２３９．２５５．２５５．２５０に対してマルチキャスト送信する。送信されたＰｒｏｂｅメッセージに対するネットワーク対応デバイス２００からの応答であるＰｒｏｂｅ Ｍａｔｃｈメッセージの有無により、ネットワークデバイスの検索処理を実現している。
【００３４】
ステップ０２０２：
ネットワーク対応デバイス２００がＰｒｏｂｅメッセージを受信すると、受信したＰｒｏｂｅメッセージはＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック０１１８を介して、ＳＯＡＰプロセッサ０１２０に通知される。ＳＯＡＰプロセッサ０１２０は、Ｐｒｏｂｅメッセージの内容を解析し、その結果（メッセージの内容）をＷＳＤモジュール０１２１に通知する。ＷＳＤモジュール０１２１は、通知されたメッセージの内容が、このネットワーク対応デバイス２００が提供する機能と一致しているか否かを判断する。一致しないと判断した場合、その情報を無視する。したがって、この場合はネットワーク対応デバイス２００からＰｒｏｂｅ Ｍａｔｃｈレスポンスが発行されることは無い。一方、一致すると判断した場合、ＷＳＤモジュール０１２１は、ＳＯＡＰプロセッサ０１２０に対してＰｒｏｂｅ Ｍａｔｃｈメッセージ発行を要求する。ＳＯＡＰプロセッサ０１２０は、Ｐｒｏｂｅ Ｍａｔｃｈメッセージを生成し、プロトコルスタック０１１８を介してクライアントＰＣ１００に対してＰｒｏｂｅ Ｍａｔｃｈメッセージをユニキャスト送信する。
【００３５】
ステップ０２０３、０２０５：
クライアントＰＣ１００がＰｒｏｂｅ Ｍａｔｃｈメッセージを受信すると、メッセージはＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック０１０４を介してＳＯＡＰプロセッサ０１０６に通知される。ＳＯＡＰプロセッサ０１０６は、Ｐｒｏｂｅ Ｍａｔｃｈメッセージの内容を解析し、その結果をＷＳＤモジュール０１０８に通知する。ＷＳＤモジュール０１０８は、Ｐｒｏｂｅ Ｍａｔｃｈメッセージに記述されたアドレスを宛先とするＧｅｔＭｅｔａｄａｔａメッセージの発行をＳＯＡＰプロセッサ０１０６に対して要求する。ＧｅｔＭｅｔａｄａｔａメッセージは、Ｐｒｏｂｅ Ｍａｔｃｈメッセージを発行したネットワーク対応デバイス２００の属性情報を取得する要求である。ＳＯＡＰプロセッサ０１０６は、ＧｅｔＭｅｔａｄａｔａメッセージを生成し、プロトコルスタックを介してネットワーク対応デバイス２００に対してユニキャスト送信する。
【００３６】
なおステップ０２０５では、クライアントＰＣが、サービス情報を要求している。すなわち、ステップ０２０５と０２０３において異なる点は、デバイス情報を要求するか、サービス情報を要求するかであり、この相違を除いて、メッセージ交換の手順は同一である。
【００３７】
ステップ０２０４、０２０６：
ネットワーク対応デバイス２００がＧｅｔＭｅｔａｄａｔａメッセージを受信すると、そのメッセージはＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック０１１８を介してＳＯＡＰプロセッサ０１２０に通知される。ＳＯＡＰプロセッサ０１２０は、ＧｅｔＭｅｔａｄａｔａメッセージの内容を解析し、その結果をＷＳＤモジュール０１２１に通知する。ＷＳＤモジュール０１２１においては、指定された属性情報を、ＧｅｔＭｅｔａｄａｔａメッセージ送信元のクライアントに対して返信するために、ＳＯＡＰプロセッサ０１２０に対してＧｅｔＭｅｔａｄａｔａＲｅｓｏｐｎｓｅメッセージの発行を要求する。ＳＯＡＰプロセッサ０１２０は、ＧｅｔＭｅｔａｄａｔａＲｅｓｐｏｎｓｅメッセージを生成し、プロトコルスタックを介してクライアントに対してユニキャスト送信する。ＧｅｔＭｅｔａｄａｔａＲｅｓｐｏｎｓｅメッセージとは、デバイス２００が送信するデバイス情報およびサービス情報の総称である。
【００３８】
なお、ステップ０２０４とステップ０２０６において異なる点は、デバイス２００が、デバイス情報を送信するかサービス情報を送信かであり、それ以外のメッセージ処理の手順は同一である。
【００３９】
ステップ０２０７：
クライアントＰＣ１００がＧｅｔＭｅｔａｄａｔａＲｅｓｐｏｎｓｅを受信すると、受信したＧｅｔＭｅｔａｄａｔａＲｅｓｐｏｎｓｅメッセージはＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック０１０４を介して、ＳＯＡＰプロセッサ０１０６に通知される。ＧｅｔＭｅｔａｄａｔａＲｅｓｐｏｎｓｅメッセージに記述されたデバイス属性情報は、クライアントＰＣ１００のＳＯＡＰプロセッサ０１０６を介してＷＳＤモジュール０１０８に通知される。
【００４０】
ＷＳＤモジュール０１０８は、プラグアンドプレイコントローラ０１１１を起動し、デバイス属性情報をプラグアンドプレイコントローラ０１１１に対し通知する。通知をうけたプラグアンドプレイコントローラ０１１１はメモリコントローラを介してデバイス属性情報に一致するドライバプログラムを記憶装置より検索し、該当するドライバのインストールを実行する。インストールは、ウィンドウズ（登録商標）ＯＳであれば、インストールする場所等を記述したインストールファイルを用意しておくことで、標準のインストーラで行える。あるいは、ドライバをインストーラと組にして提供しても良い。なお、デバイスドライバがネットワークを介してクライアントＰＣ１００と接続されたサーバにより提供されている場合には、ドライバプログラムはサーバ上で検索される。
【００４１】
＜デバイスの参加通知手順＞
さらに図２（Ｂ）を参照して、ネットワーク対応デバイス２００が、新規に導入されネットワーク通信を開始する、あるいは、電源オフの状態から電源オンされネットワーク通信を再開する場合の制御の流れをフロー図で説明する。
【００４２】
ステップ０２０８：
ネットワーク対応デバイス２００がネットワーク上で通信を開始、あるいは、再開する際、ＷＳＤモジュール０１２１は、ＳＯＡＰプロセッサ０１２０に対してＨｅｌｌｏメッセージの送信を要求する。きっかけは、たとえば電源の投入などである。ＳＯＡＰプロセッサ０１２０はＨｅｌｌｏメッセージを生成し、プロトコルスタックを介してマルチキャストアドレス２３９．２５５．２５５．２５０に対してマルチキャスト送信する。
【００４３】
ステップ０２０９：
クライアントＰＣ１００がＨｅｌｌｏメッセージを受信すると、ＨｅｌｌｏメッセージはＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック０１０４を介して、ＳＯＡＰプロセッサ０１０６に通知される。ＳＯＡＰプロセッサ０１０６は、Ｈｅｌｌｏメッセージの内容を解析し、その結果（メッセージの内容）をＷＳＤモジュール０１０８に通知する。ＷＳＤモジュール０１０８は、Ｈｅｌｌｏメッセージに記述されたアドレスに対し、該メッセージを発行したネットワークデバイスの属性情報を取得するために、ＳＯＡＰプロセッサ０１０６に対してＧｅｔＭｅｔａｄａｔａメッセージ発行を要求する。ＳＯＡＰプロセッサ０１０６はＧｅｔＭｅｔａｄａｔａメッセージを生成し、ＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック０１０４を介してネットワーク対応デバイス２００に対してユニキャスト送信する。このあとのフローは、図２（Ａ）のデバイス探索のステップ０２０４以下と同様であるため、説明は省略する。
【００４４】
なお、図２の手順は、クライアントＰＣ１００を図５に示す探索プロキシサーバ３００に置換した場合に、探索プロキシサーバ３００とデバイス２００との間においても行われる。したがって、探索プロキシサーバ３００が存在するネットワークでは、探索プロキシサーバ３００がネットワークデバイスのデバイス情報及びサービス情報を収集し、デバイスリスト１１ａとして保存し管理する。またプロキシサーバ３００はその他のメッセージをフック（すなわち横取り）して宛先のデバイスやサービス、送信元のクライアントに応じてメッセージをカウントする。そのカウンタに基づいて共有度順位表が作成され保存される。
【００４５】
＜Ｍｅｔａｄａｔａの形式＞
図３を参照して、図２（Ａ），図２（Ｂ）においてデバイスからクライアントＰＣ（クライアント端末ともいう）１００へと送信されるメタデータ（Ｍｅｔａｄａｔａ）の形式を説明する。メタデータはＸＭＬで記述されたデータとする。第１のメタデータはデバイス情報０３０１である。デバイス情報０３０１には、デバイスのモデル名０３０１ａやベンダ名などのデバイス情報が記載されている。そのなかにサービス情報へのリンク０３０１ｂが記載されている。
【００４６】
第２のメタデータはサービス情報０３０２である。図３の例では、サービス情報０３０２はＰＤＬ＿Ａのメタデータである。すなわち、サービス情報０３０２には、"ＭＦＰ２００．ＰＤＬ＿Ａ（０３０２ａ）"と記述されている。この記述は、ＭＦＰ２００というデバイスでは、ＰＤＬ＿Ａというサービスが提供されることを示す。つまり、ＭＦＰ２００は、ＰＤＬ＿Ａ（ページ記述言語Ａ）を解釈可能であることが記されている。このようにサービス情報内には、デバイス情報に含まれるデバイスＩＤとサービスＩＤとが格納されている。デバイスＩＤはプラグアンドプレイに利用される。ＰＤＬ＿Ｂのサービス情報３０３、ＰＤＬ＿Ｃのサービス情報０３０４も同様である。
【００４７】
図３の例では、プリントサービスであるＰＤＬ＿Ａ〜ＰＤＬ＿Ｃのメタデータ０３０２〜０３０４へのリンクがデバイス情報０３０１に含まれている。そこで、たとえば図２（Ａ）のステップ０２０５や図２（Ｂ）のステップ０２１１では、デバイス情報から得られたアドレス（リンク先）を指定して、サービス情報を要求する。
【００４８】
＜Ｐｒｏｂｅ Ｍａｔｃｈメッセージの内容＞
図４を参照してＰｒｏｂｅ Ｍａｔｃｈメッセージ０４０１の内容を説明する。プローブマッチ０４０１は、終端のアドレスであるエンドポイントＵＲＩ４０１ａ、サービスタイプ４０１ｂやネットワークスコープ４０１ｃに関する情報、コミュニケーションに使用するＵＲＩ４０１ｄ、メタデータのバージョン情報４０１ｅが含まれている。このバージョン情報４０１ｅは内容更新にあわせインクリメントされる。メッセージ０４０２はＰｒｏｂｅ Ｍａｔｃｈメッセージの一例である。Ｐｒｏｂｅ ＭａｔｃｈメッセージはＸＭＬで記述され、Ｐｒｏｂｅ Ｍａｔｃｈメッセージであることを示すタグ０４０２ａ、終端アドレス０４０２ｂ、デバイスタイプ０４０２ｃなどを含む。デバイスタイプは、たとえばプリンタなど、デバイスの種類を示す。
【００４９】
＜探索プロキシサーバ３００の接続＞
図２では、クライアントＰＣ１００とデバイス２００の接続フローを示した。この図２の構成に加えて探索プロキシサーバ３００を設置した場合の接続フローを図５を用いて説明する。
【００５０】
前述の通り、探索プロキシサーバ３００が接続されたネットワークに参加するデバイス２００は、探索プロキシサーバ３００からデバイス要求メッセージ等を受信する。そのメッセージには、送信元がクライアントではなく、探索プロキシサーバ３００であることを示す情報が含まれる。この情報は、探索プロキシサーバ３００に対してあらかじめ与えられたＩＤ等の識別情報である。探索プロキシサーバ３００から、探索プロキシサーバ３００の識別情報を含むデバイス情報要求等のメッセージを受けたネットワークデバイス２００は、参加したネットワークに探索プロキシサーバ３００が存在すると判断できる。探索プロキシサーバ３００がネットワークに存在する場合、デバイスはそのことをメモリ等に記憶しておく。さて、探索プロキシサーバ３００が存在することを記憶したデバイス２００は、クライアントＰＣ１００からデバイス探索のためのＰｒｏｂｅメッセージを受信してもそれに対する応答処理を行わない。そして、デバイス探索手順は、以下の通り探索プロキシサーバ３００とクライアントＰＣ１００との間で進行する。また、デバイス２００は、デバイス２００のデバイス情報およびサービス情報をプロキシサーバ３００に対して送信する。
【００５１】
ステップ０５０１：
クライアントＰＣ１００よりデバイス探索要求メッセージ（Ｐｒｏｂｅ）０５０１が送信される。
【００５２】
ステップ０５０２：
プロキシサーバ３００は、Ｈｅｌｌｏメッセージ０５０２を発信する。クライアントＰＣ１００はプロキシサーバ３００からのＨｅｌｌｏメッセージ０５０２を受信する。デバイス２００はデバイス探索要求メッセージ０５０１に対しては応答しない。
【００５３】
ステップ０５０３〜５０６：
クライアントＰＣ１００は、探索プロキシサーバ３００から応答を受信して探索プロキシサーバ３００の存在を認識した場合、以降のサービス探索メッセージは探索プロキシサーバ３００へ発信する。
まず、クライアントＰＣ１００は、ＧｅｔＭｅｔａｄａｔａメッセージ０５０３を探索プロキシサーバ３００に対して送信する（ステップ０５０３）。このＧｅｔＭｅｔａｄａｔａメッセージには、例えば、「カラープリンタに関する情報」、「プロキシサーバ３００が保持している全デバイス情報」、「ネットワーク上のいずれか３つのプリンタ」など、所定の指定情報が含まれている。探索プロキシサーバ３００はＧｅｔＭｅｔａｄａｔａメッセージ０５０３を受信したら、ＧｅｔＭｅｔａｄａｔａＲｅｓｐｏｎｃｅメッセージ０５０４をクライアントに対して送信する（ステップ０５０４）。ＧｅｔＭｅｔａｄａｔａＲｅｓｐｏｎｃｅメッセージ０５０４には探索プロキシサーバ３００が保持している情報（たとえば共有度順位表）が含まれており、その情報もクライアントＰＣ１００へ送信される。このようにステップ０５０３、０５０４では、デバイス情報がクライアントに渡され、ステップ０５０５、０５０６ではサービス情報がクライアントに渡される。
【００５４】
以上のようにして、デバイスから直接クライアントに対してデバイス情報及びサービス情報は渡されず、探索プロキシサーバ３００にキャッシュされたそれらの情報がクライアントに対して与えられる。
【００５５】
ステップ０５０７：
クライアントＰＣ１００は、ステップ０５０４またはステップ０５０６にて受信した情報に基づいてデバイスドライバのインストール処理を行う。なお、詳細は図２（Ａ）のステップ２０７で説明したため省略する。
【００５６】
ステップ０５０８：
なお、他のメッセージには３者間でやり取りされるものがある。たとえば印刷要求メッセージはクライアントＰＣ１００からデバイス（プリンタ）２００に直接送信される。デバイス２００は印刷命令にしたがって印刷処理を実行する。また、途中でエラー等、処理を中断する事態が生ずれば、その旨のメッセージがデバイス２００からクライアントＰＣ１００に送信される。プロキシサーバ３００は、図６を参照して後で説明するように、クライアントからデバイスに対するメッセージをフックする。プロキシサーバ３００はフックしたメッセージを数える。ここで単に数えるのではなく、デバイスごとのクライアントの数、デバイス及びサービスごとのクライアントの数、スコープ毎のクライアント数等、メッセージの属性ごとにメッセージ数を数える。
【００５７】
以上、探索プロキシサーバ３００は、クライアントＰＣ１００によるサービス探索を容易にする。さらに、問い合わせ先が集約され、ネットワークトラフィックの低減や、デバイス側の処理の軽減が図られる。特にネットワークスコープ内に多数のサービスがある場合には、システムトラフィック低減に有効である。ここまで、クライアントとデバイスの基本接続、プロキシサーバ３００が加えられた場合の接続について説明した。また、このようにプロキシサーバ３００を用いることにより、クライアントＰＣ１００は、デバイス２００の電源が切れている状態であっても、デバイス２００の情報を受信することが可能である。
【００５８】
＜プロキシサーバ３００の制御の概要＞
次に図６を参照して、本実施形態におけるプロキシサーバ３００による制御の概要を説明する。プロキシサーバ３００は、クライアントＰＣ１００からのメッセージ（例えばデバイス情報要求）に対して、ネットワークにおける共有度の高い（利用頻度の高い）デバイスおよびサービスを応答する。この応答に基づいて、クライアントＰＣ１００側には、共有度の高いサービスを利用するためのドライバやアプリケーションがセットアップされる。その結果、クライアントは自動インストールを実行する場合であっても、利用頻度が高く、必要になると予想されるデバイスのデバイスドライバを導入することが可能となる。また、プロキシサーバ３００はデバイス２００とクライアントＰＣ１００の個体識別と記録、識別結果をもとにした経路制御をおこなう。メッセージ交換の手順は図５に示したとおりであり、図６は探索プロキシサーバ３００における処理も含めて説明する。
【００５９】
図６において、プロキシサーバ３００によるＭＦＰ２００を含めたデバイスの個体識別と記録について説明する。プロキシサーバ３００はデバイスＭＦＰ２００を対象として、(1)探索信号を送信する。この探索信号を受信したＭＦＰ２００は、(2)応答信号をプロキシサーバ３００に対して返信する（０６０１）。この０６０１の処理は、図２（Ａ）のステップ０２０１とステップ０２０２に相当する。探索と応答の代わりに、図２（Ｂ）のネットワーク参加通知０２０８であってもよい。
【００６０】
次に図６のプロキシサーバ３００は、デバイス情報および、そのサービス情報を取得するため、(3)情報取得要求をＭＦＰ２００に対して送信する。情報取得要求を受信したＭＦＰ２００は、デバイス情報およびサービス情報を(5)送付する（０６０２）。この０６０２の処理は、図２（Ａ）のステップ０２０３〜ステップ０２０６あるいは図２（Ｂ）のステップ０２０９〜０２１２に相当する。また、情報取得要求を受信したＭＦＰ２００は、(4)デバイスＩＤを特定する（０６０３）。この一連の処理０６０１から０６０３が実行されることでプロキシサーバ３００は図３のメタデータ０３０１（デバイス情報）およびメタデータ０３０２（サービス情報）を参照し、デバイスの個体識別をおこなう。最終的には、プロキシサーバ３００は、収集したデバイスＩＤおよび各デバイスＩＤに対応するデバイスの種類情報（デバイス情報）や提供サービス（サービス情報）をデバイスリストに保存する。デバイスリスト情報を図２０に示す。図２０のデバイスリスト情報には、各デバイスのＩＤ、アドレス情報、デバイスの種類、サービスとサービスのＵＲＩが保持されている。デバイスの個体識別とは、デバイス情報及びサービス情報の保存（登録）である。なお、登録の対象を図３に示したメタデータ全体としておけば、登録されたメタデータを、デバイス情報あるいはサービス情報を要求するクライアントにそのまま渡すことができる。その結果、クライアントは、デバイスから直接受信したメタデータと同様に処理できる。ただし、後述の通り本実施形態では、メタデータのデバイスのアドレス（ＵＲＩ）は、プロキシサーバ３００によるフックのために変更されている。
【００６１】
次にプロキシサーバ３００によるクライアントＰＣ１００の個体識別と記録について説明する。プロキシサーバ３００はクライアントＰＣ１００に対して（７）探索要求を送信すると、クライアントＰＣ１００からの（８）応答信号を受信する（０６０５）。そして、プロキシサーバ３００は、クライアントＰＣ１００に対して（９）情報取得要求を送信する。プロキシサーバ３００からの情報取得要求に応じて、クライアントＰＣ１００は、クライアントＰＣ１００に関する情報を(10)送付する（０６０６）。この一連の処理０６０５、０６０６が実行されることでプロキシサーバ３００はクライアントＰＣ１００の個体識別をおこなう。最終的には、プロキシサーバ３００は、収集したクライアントのＩＤや各クライアントのアドレス等のクライアント情報をデータベース（クライアントリストという）に登録する。なお、クライアントリストの一例を図１９に示す。プロキシサーバ３００は、図１９のように各クライアントのクライアントＩＤ、アドレス情報を記憶している。
【００６２】
さらに共有度の判定のために、プロキシサーバ３００は、図５のステップ０５０８で送受信される他メッセージに含まれる情報を収集する。その目的で、プロキシサーバ３００はネットワークアドレス変換をおこなう。このネットワークアドレス変換処理について説明する。通常は、GetMetaDataで機器の情報やサービスのアドレス（ＵＲＩ）がクライアントに開示される。以降、クライアントはそのアドレス（ＵＲＩ）に対してアクション（例えば印刷要求）を行う。しかし、後述する図９の共有度順位表０９０１を作成するためには、どのクライアントがどのデバイス（例えばプリンタ）を使って印刷処理をしているか等の情報をプロキシサーバ３００が収集する必要がある。そのため、プロキシサーバ３００は、クライアントからデバイスに対する要求メッセージを一旦引き込むためにアドレス（ＵＲＩ）の書き換えを行う。アドレス変換は、一連の処理０６０１〜０６０６のフローにおいて、プロキシサーバ３００からクライアントＰＣ１００に送信するサービス情報等のメタデータに含まれるＵＲＩを差し替えることで行われる。アドレス変換処理はプロキシサーバ３００により図６の処理０６０４で行われる。たとえば、プロキシサーバ３００は、クライアントＰＣ１００からのデバイス情報要求（図５のステップ０５０３）に応じて、デバイスリストに登録されたデバイス情報を応答する。その際に、デバイス情報に含まれるデバイスのＵＲＩの上位に、プロキシサーバ３００のＵＲＩを付加する。また、サービス情報についても同様に、デバイスのＵＲＩの上位にプロキシサーバ３００のＵＲＩを付加する。図４の例では、サービス情報のＵＲＩ０４０２ｄの上位にプロキシサーバ３００のＵＲＩが付加される。なお、これらプロキシサーバ３００のＵＲＩの付加は、クライアントがデバイスのアドレスとして用いるＵＲＩに対してのみ行われても良い。
【００６３】
アドレス変換されたメタデータを受信したクライアントは、印刷要求メッセージ等、図５のステップ０５０８におけるメッセージ送信のために、変換されたアドレス（プロキシサーバ３００のＵＲＩ）を使用する。そのため、クライアントＰＣ１００からのメッセージはプロキシサーバ３００に到達する。プロキシサーバ３００は、クライアントからメッセージ（メタデータ）に含まれたＵＲＩのうち、その上位にあるプロキシサーバ３００のＵＲＩを取り除いてＭＦＰ２００に転送する。この処理により、クライアントＰＣ１００からデバイス２００に宛てられたメッセージはすべてプロキシサーバ３００を経由することになる。プロキシサーバ３００は、こうしてクライアントからデバイスに対するメッセージをフックする。なおアドレス変換は、上述したアドレスの追加および削除による方法以外に、対応表による変換、他の装置が管理しているアドレス変換機能を利用することでも実現できる。つまり、プロキシサーバ３００は、端末から周辺機器へのメッセージを横取りする。この横取りしたメッセージ情報を用いてメッセージ数を数え、共有度を計数する。その計数結果を示す共有度情報は図９に後述する。
【００６４】
こうしてプロキシサーバ３００は、基本的に０６０７の経路をとおるメッセージとメタデータ（図５のメッセージ０５０８）を参照することができる。なお、サーバ４００がネットワークに接続されている場合、プロキシサーバ３００は、サーバ４００により提供されるディレクトリサービス５００や管理ユーティリティ６００と必要な情報を送受する。プローブマッチのメタデータ内にもスコープ情報があるが、プロキシサーバ３００がディレクトリ情報を必要とする場合はディレクトリサービス５００と、図６のステップ０６１０で送受する。管理ユーティリティ６００とプロキシサーバ３００が情報共有する場合には、管理ユーティリティ６００とステップ０６１１で送受をおこなう。
【００６５】
＜プロキシサーバ３００の内部構成＞
システムの主構成と制御の説明に続き、図７を用いてプロキシサーバ３００の内部構成を説明する。プロキシサーバ３００は、通信部０７０１、フロー部０７０２、管理部０７０３の３層構造を有する。通信部０７０１には、クライアント、サーバ、デバイスそれぞれへ接続するためのクライアント接続部０７０４、サーバ接続部０７０５、デバイス接続部０７０６が備えられている。
【００６６】
フロー部０７０２は、フロー制御を処理するためアドレス変換部０７０７や入出力部０７０８を備え、図６で説明したアドレス変換や入出力制御をおこなう。管理部０７０３は、データを記録するデータ格納部０７１０、設定操作部０７１１、通信と制御の具体的な処理を決定する判断部０７０９等が備えられている。データ格納部０７１０には、前述のデバイスやクライアントの識別結果（デバイスリスト１１ａおよびクライアントリストを含む）７１０ａなどが記録されている。このほか、アドレス変換表７１０ｂ、後述するプロキシ操作設定７１０ｃ、実績テーブル７１０ｄ、共有度順位表０９０１（図７には示さず）などが記録されている。設定操作部０７１１は、プロキシサーバ３００の動作を変更するためのＵＩ（ユーザインターフェース）や、操作結果をデータ格納部０７１０に反映するための処理を提供する。判断部０７０９は、プロキシサーバ３００設定や、入力、実績を含むデータ格納部０７１０を基準に、デバイスの共有度等に関する判断をおこなう。判断結果は出力としてフロー部０７０２、通信部０７０１を通じ、プロキシサーバ３００の外部にも送信される。
【００６７】
また、通信部０７０１、フロー部０７０２、管理部０７０３のそれぞれは、拡張部分０７１２〜０７１４をもつ。この拡張部分０７１２〜０７１４により、例えば図５の他のメッセージ０５０８に対応する処理（拡張処理）を行うと、基本処理と拡張処理の独立性が向上し、拡張処理内容の変更や付加、削除が容易となる。この拡張部分０７１２〜０７１４へ、処理の内部集約、内部置換（差し替え）、外部接続といった手段が採用できることが理由である。
【００６８】
以上、プロキシサーバ３００は図７に記載した内部構成を持つため、通信系と管理系の分離配置が可能となっている。プロキシサーバ３００と前述の管理ユーティリティ６００との連携動作時は、プロキシサーバ３００をフロー部０７０２と管理部０７０３間のＩ／Ｆで分離し、管理部０７０３の機能を管理ユーティリティ６００
に集約する構成も実施できる。
【００６９】
続いて、図２３を用いてプロキシサーバ３００の本願における処理の概要を説明する。なお、図２３に記載のフローチャートにおける各ステップの処理はプロキシサーバ３００のＣＰＵによって処理される。また、プロキシサーバ３００は、周辺機器（単にデバイスとも呼ぶ。）および端末（クライアントとも呼ぶ。）と通信可能な情報処理装置ある。
【００７０】
プロキシサーバ３００は、ネットワークに対して図６の処理０６０１および処理０６０５にて記述したデバイス探索要求を発信し、デバイスまたはクライアントからの応答を待機する。プロキシサーバ３００は、クライアントおよびデバイスからの応答を受信すると、応答情報に基づいてデバイス情報を要求する。プロキシサーバ３００は、応答されたデバイス情報に基づいてデバイスリストおよびクライアントリストを生成する（Ｓ２３０１）。プロキシサーバ３００は、こうしてＳ２３０１により周辺機器から周辺機器に関する情報を受信して保存する。
【００７１】
プロキシサーバ３００は、クライアントとデバイスの通信情報、または、クライアントとプロキシサーバ３００の通信情報に基づいて共有度順位情報を生成する（Ｓ２３０２）。
【００７２】
Ｓ２３０２の処理の一例を簡単に説明すると、プロキシサーバ３００は、クライアントおよびデバイス間において送受信されているメッセージ情報をデバイス毎に数える。そして、メッセージ情報を数えることにより得られる周辺機器毎の共有度を計数して、共有度情報を生成する。または、クライアントからプロキシサーバ３００に対して送信される情報を用いて計数することもある。なお、Ｓ２３０２の処理は、ネットワークが通常の稼働状態にある間にプロキシサーバ３００により実行される。Ｓ２３０２の詳細は、図１７および図８を用いて後述する。
【００７３】
プロキシサーバ３００は、クライアントからデバイス情報要求を受信したか否かを判定する（Ｓ２３０３）。詳細には、プロキシサーバ３００が、クライアントから、プロキシサーバ３００のメモリにて保持されている周辺機器に関する情報を要求する要求メッセージを受信したか否かを判定する。プロキシサーバ３００は、クライアントからプロキシサーバ３００のメモリにて保持されている周辺機器に関する情報を要求する要求メッセージ（デバイス情報要求）を受信する。そのメッセージを受信したプロキシサーバ３００は、Ｓ２３０２により計数された周辺機器毎の共有度に従って選択された周辺機器に関する情報を、クライアントに送信する（Ｓ２３０４）。つまり、プロキシサーバ３００は、作成された共有度順位情報を用いて送信すべき周辺機器に関する情報を選択する。
【００７４】
プロキシサーバ３００には、クライアントに送信すべきデバイスを選択するための条件が設定されている。例えば、共有度情報の上位３つのデバイスに関する情報を送信するなどが挙げられる。このプロキシサーバ３００に設定されている条件に基づいて送信すべきデバイス情報を決定する。
【００７５】
なお、クライアントからデバイス要求を受信した場合、プロキシサーバ３００は、クライアントから受信したデバイス情報要求に含まれる情報が共有度情報を送信する条件に一致するか否かを判定してもよい。ここで、プロキシサーバ３００が共有度情報を送信すると判定する場合の条件について説明する。１つ目は、クライアントのデバイス情報要求に共有度情報を取得したいとの情報が含まれているか否かである。２つ目は、クライアントが、初めてデバイス情報要求を送信したか否かである。プロキシサーバ３００は、各クライアントからのデバイス情報要求を管理しているため、例えば、いつ、どのクライアントがどういった内容のデバイス情報要求を送信してきたかを管理している。つまり、プロキシサーバ３００が、Ｓ２３０３にて受信したデバイス情報要求の送信元のクライアント情報を管理していなければ、そのクライアントは初めてデバイス情報要求を送信したと判定できる。なお、共有度情報を送信する条件として２つの例を挙げたがこれに限定される必要はない。
【００７６】
図２３の処理により、たとえば、利用される可能性が高いデバイスのデバイスドライバあるいはそのデバイスに対応したアプリケーションプログラム等を、選択的にクライアントコンピュータがインストール可能な情報処理装置を提供できる。
【００７７】
＜プロキシサーバ３００による集計処理＞
プロキシサーバ３００、詳細にはプロキシサーバ３００のＣＰＵ１は、受信したメッセージに含まれる情報を集計する。集計は例えば以下の項目を対象として行われる。
（１）各デバイスにアクセスしたクライアント数。つまり、プロキシサーバ３００は、端末から周辺機器へのメッセージを受信し、受信したメッセージの宛先および送信元情報に基づいて、周辺機器毎に、送信元となった端末数を数える。端末数は、該当するメッセージの数を数えることでカウントされる。そしてプロキシサーバ３００は、周辺機器に対して、数えられた端末数を関連づけ、端末数をキーとして整列した順位を共有度の順位とする共有度順位情報を作成する。
（２）サービス毎のクライアント別のメッセージ数。すなわち、宛先のサービスＩＤ（あるいはサービスのＵＲＩ）と送信元のクライアントＩＤ（あるいはアドレス）とを一組の径路情報と考えた場合における、各径路のメッセージ数である。つまり、プロキシサーバ３００は、受信したメッセージの宛先情報に基づいて、周辺機器毎にメッセージ数を数える。そして、プロキシサーバ３００は、数えられた周辺機器毎のメッセージ数を周辺機器毎に関連づけ、メッセージ数をキーとして整列した順位を共有度の順位とする。
（３）デバイス毎の受信データ量および送信データ量。データ量は、本例ではメッセージの数である。したがって、データ量は、（２）のサービス毎のクライアント別メッセージ数を、着目デバイスについて加算しても得られる。
（４）スコープ毎のメッセージ数。つまりプロキシサーバ３００は、受信したメッセージの宛先および送信元情報に基づいて、周辺機器と同一のネットワーク上の範囲に属する送信元の端末の数を数える。スコープはメタデータ中に記述されており、ネットワークにおける範囲を示す。たとえばクライアントＩＤを列挙したり、あるいは、階層的に記述されたアドレスの一部（特に上位）を記述するなどしてスコープを表すことができる。本例では、デバイスの属するスコープに隣接するスコープのクライアントからも、そのデバイスにアクセスすることができるが、デバイスと同一のスコープに属するクライアントからアクセスされた場合、ローカルユーザ数の項目９１４をカウントする。デバイスと同一のスコープに属するクライアントをローカルクライアントと呼ぶ。プロキシサーバ３００は、同一のネットワーク上の範囲内に属する送信元の端末数を周辺機器毎に関連づけ、該端末数をキーとして整列した順位を共有度の順位とする。なお、以上の項目以外にも必要に応じて種々の情報を集計することができる。
【００７８】
図１７に、図２３のステップＳ２３０２においてプロキシサーバ３００が実行する処理の一例を示す。図１７は、プロキシサーバ３００が、クライアントおよびデバイス間において送受信されているメッセージ情報をデバイス毎に数える手順である。図１７においてプロキシサーバ３００は、フックしたメッセージを数える。図１７の例では、カウントしているのは（１）のデバイス毎のクライアント数と、（２）のデバイス毎のサービスおよびクライアント別メッセージ数と、（４）のスコープ毎のクライアント別メッセージ数である。（３）のデバイス毎のメッセージ数は、デバイスの共有度表を作成する際に、（１）のデバイス毎のクライアント別メッセージ数から算出される。なお、図１７の各ステップの処理はプロキシサーバ３００が備えるＣＰＵによって実行される。
【００７９】
図１７では、プロキシサーバ３００は、フックしたメッセージからデバイスＩＤおよびサービスのＵＲＩおよびクライアントのＩＤを読む（Ｓ１７０１）。次にプロキシサーバ３００は、読み取ったデバイスＩＤおよびサービスＵＲＩおよびクライアントＩＤの組に対応するカウンタ（サービスごとのクライアント別カウンタという。）が登録されているか判定する（Ｓ１７０２）。プロキシサーバ３００により登録済みか否かが判定されるカウンタはプロキシサーバ３００のＲＡＭに登録されているため、プロキシサーバ３００がＲＡＭを参照することによりＳ１７０２の処理は可能となる。
【００８０】
プロキシサーバ３００は、Ｓ１７０２の判定の結果、カウンタが登録されていればそのデバイスＩＤおよびサービスＵＲＩおよびクライアントＩＤの組に対応するメッセージカウンタに１を加算する（Ｓ１７０４）。一方、登録されていないと判定された場合、プロキシサーバ３００は、読み取ったデバイスＩＤおよびサービスＵＲＩおよびクライアントＩＤの組に対応するメッセージカウンタを新たに設け、そのメッセージカウンタに１をセットする（Ｓ１７０３）。また、プロキシサーバ３００は、デバイスごとのクライアント数のカウンタにも、初めてのクライアントであれば１を加算する（Ｓ１７０５）。そして、そのクライアントのＩＤを、重複の排除のために記録しておく。
【００８１】
次にプロキシサーバ３００は、メッセージからスコープを読み取る（Ｓ１７０６）。読み取ったスコープに対応するメッセージカウンタが登録されているか判定し（Ｓ１７０７）、登録されていればそのメッセージカウンタに１を加算する（Ｓ１７０９）。一方、登録されていなければ、プロキシサーバ３００は、読み取ったスコープに対応するメッセージカウンタを新たに設け、そのメッセージカウンタに１をセットする（Ｓ１７０８）。
【００８２】
＜共有プリンタの判断＞
プロキシサーバ３００の管理部０７０３にある判断部０７０９により実施される、プリンタ等のネットワークデバイスの共有度の判定について、図８を参照して説明する。図８はデバイスの評価手順を示す概略図であり、具体的にはデバイスの共有度順位表の作成手順を示す。つまり、図８は、図２３のステップＳ２３０２において、プロキシサーバ３００がクライアントＰＣ１００からデバイス情報要求を受信した際に、その応答送信前に実行される。また図９（Ａ）に作成される順位表の例を示す。処理手順中、ステップＳ０８０１、ステップＳ０８０２が主たる判断であり、これにステップＳ０８０３が加えられている。ステップＳ０８０４はオプション、ステップＳ０８０５は補助的な条件である。
【００８３】
まずプロキシサーバ３００の判断部は、デバイスリストに登録された各デバイスについてステップＳ０８０１〜Ｓ０８０５の評価を行い、最後にステップＳ０８０６でデバイス共有度順位表をソートする。これが作成手段に相当する。
【００８４】
ステップＳ０８０１では第１の判定基準にしたがって評価を行う。第１の判定基準は、ネットワークで公開されているか否かである。判断部は、デバイス共有度順位表のうち着目デバイス（たとえばＭＦＰ２００）に対してＯＳの共有設定がなされているかを判定する。この判定基準は、ステップ０６１０に示したとおり、ディレクトリサービス０５００より得た共有情報に基づく情報である。ディレクトリサービス０５００がたとえばアクティブディレクトリであるなら、そこから、ＡＤＳＩ（Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙ Ｓｅｒｖｉｃｅ Ｉｎｔｅｒｆａｃｅ）経由でデバイスが共有設定されているか否かを示す共有情報を取得できる。共有設定されていると判断されれば、プロキシサーバ３００は、共有設定されているデバイスのデバイスＩＤ（図９（Ａ）のデバイスＩＤ０９１１）を、デバイス共有度順位表に登録する。したがって本実施形態では共有設定されていないデバイスは、共有度順位表に登録されず、クライアントによるデバイス探索では見つけられない。これは、一般に共有設定されていないデバイスを、不特定の利用者により利用させるのは適当ではないからである。
【００８５】
なおアクティブディレクトリより、ネットワーク環境のクライアント数、デバイス数など、ネットワークの規模についての情報も得られる。ステップ０８０１では、ディレクトリサービスからこれらの情報をまず取得する。ネットワークの規模を示す情報は、ネットワークの大小の判断の基準となる。
【００８６】
ステップＳ０８０２では、プロキシサーバ３００が、第２の判定基準にしたがって評価を行う。第２の判定基準は、サービスが多数のクライアントから接続（アクセス）されているか否かである。プロキシサーバ３００は、着目デバイスにより提供されるサービス（着目サービス）に対して、クライアントからの接続数"Ｎ"が多い状態を共有度が高いと判断する。着目デバイス（たとえばＭＦＰ２００）とクライアントＰＣ１００は処理０６０１〜０６０６を通して個体識別されている。この過程で参照されるメタデータ０４０１からサービスおよびスコープ情報が得られる。またネットワーク規模（構成）の情報は、ディレクトリサーバからステップ０６１０において入手できる。着目デバイス（たとえばＭＦＰ２００）の着目サービスへの接続は、サービスのアドレス（ＵＲＩ）で特定される。したがって、プロキシサーバ３００は、着目サービスのＵＲＩを指定した接続要求（たとえば印刷要求）メッセージの数を、識別済みである各クライアントの重複を排除してカウントすることで、クライアント数"Ｎ"（すなわち接続数）を求めることができる。重複を排除するためには、受信したメッセージに記録された送信元のクライアントの識別情報（ＩＤやアドレス）が記憶されているか否かを判断し、記憶されていなければ記憶する。そして、同時にクライアント数Ｎに１を加算する。その数Ｎが、サービスが多数のクライアントから接続されていることの程度を示す値となるので、デバイス毎のＮを図９（Ａ）の接続先数０９１２として順位表に登録する。
【００８７】
なお、クライアント数そのものではなく、ネットワークに接続されたクライアント数のうちの割合を共有度表に登録しても良い。すなわち、ネットワークに接続されたクライアント数を分母とし、着目デバイスの持つ特定のサービスを利用したクライアントの数を分子とした割合を求め、その値に基づいて共有度を計算しても良い。
【００８８】
ステップＳ０８０３では、プロキシサーバ３００が、第３の判定基準にしたがって評価を行う。第３の判定基準は、サービスの利用総量が多いか否かである。すなわちネットワークで公開されたデバイスであり、かつ、多数のクライアントから利用されている上で、着目デバイスの提供するサービスに対するクライアントからの総アクセス数"ｎ"が多いデバイスほど、共有度の高いデバイスと判断される。着目デバイスの提供サービスに対する総アクセス数は、プロキシサーバ３００がフックしたメッセージの数を、デバイスごとにカウントすることで得られる。これは図１７のステップＳ１７０５でカウントされる値を、着目デバイスについて加算した値に相当する。ステップＳ０８０３では、この値をデバイスＩＤに対応付けてデータ量０９１３として共有度順位表０９０１に登録する。
【００８９】
ステップＳ０８０４では、プロキシサーバ３００が、第４の判定基準にしたがって評価を行う。第４の判定基準（Ｓ０８０４）は、クライアントが指定したデバイスとメッセージ送信元のクライアントが同一スコープ内にあるか否かを判定する処理である。ここで、同一スコープ内のクライアントから宛先指定されたデバイスについて、カウント処理を実行する。ここで、カウント数が多いデバイスは、同一スコープ内のユーザの利用頻度が高いデバイスである。ここで、例えば新規に同一スコープ内に接続したクライアントに対しては、カウント値の高いデバイスを推奨するようにしても構わない。このカウンタ値は、デバイスの共有度順位表９０１のローカルユーザ数０９１４として登録される。
【００９０】
ステップＳ０８０５では、プロキシサーバ３００が、第５の判定基準にしたがって評価を行う。第５の判定基準は、デバイスの能力が高く、搭載しているサービス数が多いというものである。デバイスが高機能であるかは、着目デバイス（たとえばＭＦＰ２００）のメタデータ、特にデバイス情報に基づいて判断される。このデバイス能力レベルのデータは、最低レベルをあらかじめカットするため、他条件が同点のケースでの最終順位決めといった補助的な目的のために利用される。能力値は例えば、提供するサービスの数であったり、あるいは、着目デバイスがプリンタであれば単位時間あたりの印刷ページ数である。例えば、プロキシサーバ３００に１０ｐｐｍ（１分あたりの印刷ページ数）以下のプリンタはカウントしないと設定されていた場合、１０ｐｐｍ以上のプリンタについては能力値０９１５の項目を更新しない。一方、１０ｐｐｍ以上のプリンタについては能力値０９１５の項目の値を更新する処理が行われる。この値が共有度順位表０９０１の能力値０９１５として登録される。
【００９１】
以上の手順を各デバイスについて実行することで、図９に例示するデバイス共有度順位表が完成する。プロキシサーバ３００には、担当するスコープが割り当てられており、プロキシサーバ３００は、担当スコープ内の各デバイスについて、上述の図８の手順を実行する。この図９の共有度順位表を、各項目毎に優先順位を付してソートすることで、デバイスＩＤがその共有度順にソートされる。本例では、図９（Ａ）の項目０９１２−０９１５をキーとし、その優先順位をソートする。優先順位を付してソートするとは、第１のキーでソートした後、同順にある項目を第２のキーでソートする、というように、優先順位の高いキーで先後が付かない場合に、優先順位の低いキーで順位を付けることをいう。
【００９２】
なお、共有度順位はその他の項目を用いて作成することもできる。図９（Ｂ）は、その一例を示す。図９（Ｂ）の例では、デバイスの共有度順位表０９０１に、接続先数、探索数、情報請求数（デバイス情報要求メッセージの数）、データ量／月（１突き当たりのメッセージ数）、初回接続日時、最終接続日時、サービス数が、この順で登録される。接続先数は、接続先のクライアント数である。そして各項目をキーとして、この優先順位でソートすることで、デバイスＩＤが共有度順位に応じてソートされる。図８のように優先すべき項目情報に基づいて共有度順位を特定するので、クライアントは、より利便性の高いデバイスを優先的にインストール（導入）することが可能となる。
【００９３】
それでは次に、順位表のどこまでのデバイス、サービスをクライアントＰＣ１００に通知するかについて説明する。
【００９４】
＜クライアントへの列挙順序＞
図１０はクライアントＰＣ１００が表示するＵＩの一例である。プロキシサーバ３００は、クライアントから受信したデバイス情報要求に対して、ソートしたデバイス共有度順位表のうち、上位の一定数のデバイスについて、それらが共有度順位が高いことを示す情報と共に、デバイス情報をクライアントに返す。なおこの上位の一定数は固定されているとは限らない。デバイス情報応答を受信したクライアントでは、たとえばドライバインストーラが図５のステップＳ０５０７において図１０のユーザインターフェースを表示する。またはアプリケーションが表示してもよい。
【００９５】
さて、ドライバインストーラは、図５のステップ０５０７において、図１０に示すプリンタのセットアップ開始ダイアログ１００１を表示する。その中の機種リスト１００２は次の順序で列挙されている。すなわち、図８の手順で作成されたデバイス共有度順位表を、クライアント数、サービスの利用量、ローカルユーザ数、能力値をキーとして、この優先順序でソートした順序で、デバイスＩＤが列挙される。こうして共有度の高い順にデバイスが列挙される。さらに、新しいデバイスや利用実績のあるデバイスについてもデバイスリストの末尾に列挙する。もちろんこれらデバイスも共有度に応じた順序で列挙しても良い。
【００９６】
以上をまとめると、クライアントＰＣ１００は、プロキシサーバ３００から受信したデバイス情報要求に基づき、以下の順序でデバイスのリストを表示する。
（ａ）共有度の高い順。
（ｂ）新しいデバイスや利用実績があるデバイス。これらデバイスは（ａ）の後クライアントへ返答される。
（ｃ）共有度がある一定の順位よりも低いデバイスはリストに表示されない。
【００９７】
共有度がある一定の順位よりも低いデバイスとは、たとえばプロキシサーバ３００が判定する。プロキシサーバ３００は、デバイス共有度順位表に基づいて、その下位の一定数のデバイスを共有度が一定の順位よりも低いデバイスであると判定し、これらデバイスのデバイス情報をクライアントに返信しない。
【００９８】
そして、クライアントＰＣ１００では、上記（ａ）（ｂ）の規則にしたがった順序でリストされたデバイスのうち、上位所定数のデバイスについては、あらかじめドライバをインストールする対象として選択しておく。具体的には、デバイス毎にドライバをインストールするか否かを示す選択フラグをＲＡＭ等に設け、該当するデバイスに関してはそのフラグをセットしておく。ユーザインターフェースであるダイアログ１００１の上では、チェックボックス１００３が選択された状態で表示される。図１０では上位４つのデバイスが、インストール対象として選択されている。ユーザがダイアログ１００１の「次へ」ボタンをおすと、ユーザインターフェースから、プラグアンドプレイコントローラ０１１１に、選択フラグがセットされたデバイスのデバイス情報が通知される。通知をうけたプラグアンドプレイコントローラ０１１１は、メモリコントローラを介してデバイス属性情報に一致するドライバを記憶装置上より検索し、該当するドライバのインストールを実行する。
【００９９】
図１１がプロキシサーバ３００による列挙制御のフロー図である。まずステップ１１０２でプロキシサーバ３００が、デバイス情報要求メッセージの発行元クライアントを特定する。すなわち、プロキシサーバ３００が、デバイス要求メッセージの送信元のアドレスあるいはクライアントＩＤを読み取る。ステップ１１０３でプロキシサーバ３００は、応答の設定（後述）を読み取る。またステップ１１０４では、プロキシサーバ３００が、たとえば共有度順位表のソートを前述のように行って、ステップ１１０５〜ステップ１１１０のデバイスの列挙順を確定する。
【０１００】
プロキシサーバ３００が、応答の設定に応じて実績データ（すなわち共有度順位表）より順序づけられた共有度の高いデバイスがあると判定した場合（ステップ１１０５−Ｙ）、ステップ１１０６にて共有度の高い順にデバイスを列挙する。「列挙する」とは、順序（たとえば共有度順位順）に従ってデバイス情報をクライアントに送信することを意味している。また、共有度の高い低いの判断は上述した通り、予め上位いくつまでのデバイスが共有度が高いと判定するようにプロキシサーバ３００に設定されているので、その設定情報を用いて、共有度の高いデバイスを特定できる。デバイスリストにはデバイス情報およびサービス情報がデバイスＩＤに関連付けられて保存されているから、共有度の高いデバイスのデバイス情報及びサービス情報をデバイスリストから選ぶことは容易である。
【０１０１】
次に、プロキシサーバ３００が、ネットワーク上に新しいデバイスを発見した場合（ステップ１１０７―Ｙ）、ステップ１１０８にて新しい順にデバイスを列挙する。プロキシサーバ３００は、Ｈｅｌｌｏメッセージあるいは探索メッセージに対する初めての応答を受信した日時と送信元のデバイスＩＤとを関連づけて記録しておく。そして、ステップ１１０７の処理時において、その記録した日時と現在日時とが一定期間内に納まっていれば、関連づけたデバイスを新しいデバイスと判定する。記録した日時と現在日時との時間差が短いほど、より新しいデバイスであると判定できる。つまり、プロキシサーバ３００は、周辺機器毎に、接続された日時を関連づけ、日時をキーとして整列した順位を共有度の順位とする。
【０１０２】
さらに、プロキシサーバ３００は、クライアントによる利用実績が記録されているデバイスがあるか否かを判定し（ステップ１１０９）、利用実績が記録されたデバイスがあると判定された場合、ステップ１１１０にて利用実績が新しい順にデバイスを列挙する。なお、ステップ１１１０では利用実績の高い順にデバイスを列挙してもよい。利用実績は、前述の通りクライアントから通知されるメッセージの数をデバイス毎に数えて利用実績と見なすことができる。
【０１０３】
以上の手順で、プロキシサーバ３００は、デバイス情報要求メッセージ対して、デバイスの共有度順位等に応じた順序でデバイス情報応答メッセージを返すことができる。また、ステップ１１０７の処理を実行することにより、新たにネットワークに参加したために利用実績値が少ないデバイスであっても、クライアントに対して推奨することが可能となる。このように、プロキシサーバ３００は、共有順位表の情報だけでなく複数の観点から推奨すべきプリンタを選択している。
【０１０４】
＜クライアントへの応答の設定＞
図１１のステップ１１０３では応答レベルの設定を読み込んでいる。プロキシサーバ３００、あるいはプロキシサーバ３００の管理部０７０３を集約した管理ユーティリティ６００の設定操作部０７１１よりクライアントへの応答レベルについての設定がおこなえる。応答レベルの設定には次の方法がある。これら方法は、プロキシサーバ３００においていずれかを固定的に実施しても良いし、あるいは、利用者によりいずれかの方法を選択させても良い。
【０１０５】
（１）段階表現：
共有度１〜３の３段階で表される段階表現を用いて応答レベルを利用者が設定する。なおこの段数は拡張可能である。設定操作部０７１１は、低、中、高の３段階で移動可能なスライダを含むユーザインターフェースを表示する。利用者はスライダを所望位置に移動して応答レベルを設定する。設定された応答レベルはハードディスクやメモリの所定アドレスに保存される。図１１のステップ１１０３では、設定された応答レベルが読まれ、「低」「中」「高」の何れであるかが判定される。
【０１０６】
プロキシサーバ３００は図１１のステップ１１０４でスコープ内の各デバイスへのクライアント接続数において上位のデバイスからソートする（これは前述の通り）。そして、応答レベルとして「高」が指定されている場合には、接続数の分布にギャップがみられる箇所をみつける。すなわち、ソートされた共有度順位表において、互いに隣接する順位のデバイスについて、接続数の差を計算する。接続数の差が最大の箇所を「中」と「高」の境界とする。したがって、応答レベルとして「高」が指定されている場合には、この境界より上位にあるデバイスのデバイス情報を、ステップ１１０６でクライアントに応答する。
【０１０７】
また、応答レベルとして「中」が指定されている場合には、クライアント接続数が少ないデバイスをカットする。たとえば、接続数０〜３のデバイスについては、ステップ１１０６においてデバイス情報として応答しない。
【０１０８】
また応答レベルとして「低」が指定されている場合には、共有度順位表に登録されたデバイスすべてについてデバイス情報をクライアントに応答する。この場合には、新しいデバイスや使用実績のあるデバイスのデバイス情報もステップ１１０６で応答されるので、ステップ１１０７以下はスキップすることができる。
【０１０９】
（２）順位表：
第２の方法では順位表を利用する。設定操作部０７１１はソートした共有度順位表を表示（たとえばデバイスの名称など）し、クライアントに応答する境界線（ボーダーライン）を利用者に指定させる。図１２はプロキシサーバ３００により表示される順位表を利用したＵＩの一例である。プロキシサーバ３００は順位表１２０１を表示し、利用者はスライダ１２０２を用いて境界線を移動させる。境界線より上にあるデバイスが、デバイス情報要求に対してデバイス情報が応答される対象となるデバイスである。この方法では、いったん指定されたデバイスのデバイスＩＤを応答レベルとしてプロキシサーバ３００が記憶し、応答レベル以上のデバイスのデバイス情報をデバイス情報要求に対して応答する。図１２の例では、共有度順位５と認識されたデバイスが境界として指定されたので、このデバイスよりも共有度の高いデバイスのデバイス情報がクライアントに通知される。あるいは、対象として指定されたデバイスの数を応答レベルとして記憶し、最新の共有度順位表の上位から記憶した数のデバイスを選択して、デバイス情報応答の対象とする。つまり、図１２の例では、上位５つのデバイス情報がクライアントに対して通知される。あるいは、選択された対象の最下位にあるデバイスＩＤを応答レベルとして記憶しておき、最新の共有度順位表の上位から記憶したデバイスＩＤまでを選択して、デバイス情報応答の対象とする。これらのうちいずれかの方法で選択されたデバイス情報がステップ１１０６でクライアントに送信される。
【０１１０】
（３）個数表現：
第３の方法はデバイスの数を直接指定する方法である。設定操作部０７１１は、スピンボックスを表示する。利用者は表示されたスピンボックスから数値を入力する。その通知がメモリ等に応答レベルとして記憶される。ＵＩは図１２のスライダ１２０２をスピンボックスに変更したものになる。図１１のステップ１１０３では記憶された数値を読み、ステップ１１０６では共有度順位表の上位から指定された数のデバイスに付いて、デバイス情報を応答する。例えば、通知個数として４を選択した場合、共有度順位において上位４つのデバイス情報がクライアントに通知される。
【０１１１】
以上説明した、クライアント、デバイス、プロキシサーバ３００の三者によるメッセージ交換の手順の一例を図１８にまとめた。図１８において、各装置の処理は、それぞれのＣＰＵによりプログラムをじっこうすることで制御されている。
【０１１２】
図１８において、プロキシサーバ３００によるデバイス探索要求１８０１の送信に対してデバイス２００が応答１８０２を返す。さらにプロキシサーバ３００によるデバイス情報要求１８０３の送信に対してデバイス２００はデバイス情報１８０４を応答する。この際に、デバイスＩＤが固定されていないのであれば、デバイス情報の送信前にデバイス２００はデバイスＩＤを決定しておく。デバイス探索要求の送信先はクライアントＰＣ１００も指定されている。そこでクライアントＰＣ１００は応答１８２２をプロキシサーバ３００に返す。プロキシサーバ３００は、さらに詳細な情報をクライアントに要求することもできるが、本例ではクライアントについてはその存在とそのアドレスやＩＤを得られれば十分として、プロキシサーバ３００はこれ以上の情報を要求しない。なお、プロキシサーバ３００が、クライアントやデバイスからネットワーク参加通知（Ｈｅｌｌｏ）メッセージを受信した場合、デバイスに対してはプロキシサーバ３００からデバイス情報要求が送信される。
【０１１３】
さて、クライアントが発行したデバイス探索要求１８０５を受信したプロキシサーバ３００は、送信元のＵＲＩをプロキシサーバ３００のＵＲＩに差し替えてクライアントＰＣ１００に対して応答１８０６を送信する。そのため、クライアントＰＣ１００は、デバイス情報要求を送信する場合、応答１８０６にて記述されたプロキシサーバ３００のＵＲＩを用いてデバイス情報要求１８０７を送信する。プロキシサーバ３００はデバイス情報要求１８０７を受信すると、保持している共有度順位情報に基づきデバイスを検索して推奨すべきデバイスを特定し（１８０７ａ）、特定されたデバイス情報１８０８をクライアントに対して応答する。プロキシサーバ３００が、クライアントＰＣ１００に対して送信するデバイス情報を図２２に示す。図２０が、プロキシサーバ３００が保持するデバイスリストであり、共有度順位情報を用いてソートした結果が図２１である。つまり、プロキシサーバ３００はデバイス２００から２０５の６個のデバイスについてのデバイス情報を保持している。この状態において、クライアントからデバイス情報要求を受信した場合、プロキシサーバ３００は送信すべきデバイス情報を特定して、クライアントに通知する。例えば、プロキシサーバ３００に対して上位３つのデバイス情報を通知することが設定されている場合、プロキシサーバ３００は、図２２のように上位３つのデバイス情報を通知する。この際、デバイス情報のアドレス情報には、デバイスのアドレス情報に対してプロキシサーバ３００のアドレス情報が付加されている。つまり、プロキシサーバ３００は、端末および周辺機器間において送受信されるメッセージを横取りして受信する。そのため、端末からの問い合わせメッセージに応じて周辺機器に関する情報を送信する場合、情報処理装置の宛先情報を付加した応答情報を端末に送信する。よって、図２２のデバイス情報を受信したクライアントが、例えば印刷処理を実行する場合、印刷データの送信先情報には選択したデバイスのアドレス情報とプロキシサーバ３００のアドレス情報が含まれている。そのため、クライアントとデバイス間のメッセージは、プロキシサーバ３００を経由するようになる。このとき、デバイス情報は、図１１に示した手順でプロキシサーバ３００からクライアントＰＣ１００に送信される。図１８では省略したが、サービス情報要求及び応答も、プロキシサーバ３００とクライアントＰＣ１００との間で交換される。クライアントでは、受信したデバイス情報を元にデバイスドライバのインストーラが実行される。つまり、クライアントが、インストール処理を実行する場合、図１０に例示したユーザインターフェースが表示され、ここで利用者が選択したデバイスについて、デバイスドライバがインストールされて利用可能となる。
【０１１４】
デバイス情報及びサービス情報を獲得したクライアントＰＣ１００は、アプリケーションプログラムの印刷要求等に応じて、印刷要求（命令）メッセージ１８０９を送信する。このメッセージの宛先は、応答１８０６により通知されたアドレスである。すなわち、プロキシサーバ３００により差し替えられたプロキシサーバ３００のアドレスに対して送信される。それを受信（フック）したプロキシサーバ３００は、送信先ＵＲＩをデバイスのＵＲＩに書き替えて（１８１０）、図８に示す手順でメッセージをカウントして、図９に示す共有度順位情報を更新する（１８１１）。その後、プロキシサーバ３００は、受信したメッセージを本来の受け手であるデバイスに対して転送する（１８１２）。差し替えられたメッセージの送信先ＵＲＩには、プロキシサーバ３００のＵＲＩとデバイスのＵＲＩとがセミコロンで区切るなどして記述されているので、本来の送信先は、送信先ＵＲＩからプロキシサーバ３００のＵＲＩを削除することで得られる。デバイス２００は受信したメッセージに対して応答メッセージ１８１３を返信する。このようにして印刷等のメッセージがクライアントからデバイスに送信される。
【０１１５】
さて、クライアント（これは上記手順に関わったクライアントと異なるものであっても良い。）が、再度デバイス探索要求１８１４をプロキシサーバ３００に送信すると、プロキシサーバ３００は図１１の手順で応答するデバイスを検索し、検索されたデバイスのデバイス情報１８１６をクライアントへ返す。これはステップ１８０７，１８０８と同様である。
【０１１６】
上記手順により本実施形態のネットワークシステムでは、プロキシサーバ３００がネットワークデバイスのデバイス情報を管理している。そしてクライアントからのデバイス情報要求に対して、共有度の高いデバイスのデバイス情報を応答する。また、共有度が高くなくとも、新たに接続されたデバイスのデバイス情報を応答する。また、共有度が高くなくとも、利用実績の高いデバイスのデバイス情報を応答する。これにより、クライアントは、ネットワークに接続された多数のネットワークデバイスの全てではなく、利用する可能性の高いデバイスに限定してそのデバイス情報を取得できる。このため、クライアントにインストールされるデバイスドライバの数も絞られるので、クライアントコンピュータの資源を節約できる。また、利用者が使用するデバイスを選択する際に、候補があらかじめ絞られることから選択しやすいという効果が得られる。
【０１１７】
また、第１実施例では、クライアントとデバイス間のメッセージをプロキシサーバ３００がフックすることにより図９の共有度順位情報を作成していたが、それに限る必要はない。例えば、クライアントは、プロキシサーバ３００が接続されていることを認識すると、プロキシサーバ３００に対してデバイス情報要求処理（GetMetaData）を実行する。ここで、クライアントが特定のデバイスを指定してデバイス情報を要求することも考えられる。この時、どのクライアントがどのデバイスを特定してデバイス情報要求をしたかをプロキシサーバ３００が管理することにより、図９の共有度順位情報を生成しても良い。一例としては、クライアントＡがプロキシサーバ３００に対して、デバイス２００の情報取得要求を行った場合、プロキシサーバ３００が保持するデバイス２００の情報をクライアントに通知する。それと共に、クライアントＡがデバイス２００の情報に対して取得要求をしたことをカウントする。このカウント情報を蓄積することで図９のデバイス共有度情報を生成しても良い。
【０１１８】
第１実施形態により、プロキシサーバ３００はネットワークに接続されている膨大な数のデバイスから利用する可能性の高いデバイスを選択して、クライアントに通知する。よって、クライアントは、多くのデバイスドライバをインストールすることにより発生するメモリの浪費やユーザによる誤操作等を防止することが可能となる。
【０１１９】
第１実施形態により、複数のネットワークデバイスが接続されたネットワークにコンピュータを接続した場合でも、コンピュータにインストールされるデバイスドライバ等のプログラムの数を制限することできる。さらに、インストールされるプログラムを、対応するデバイスの共有度にしたがって選択することで、利用される可能性の高いデバイスに絞ることができ、ユーザの利便性を一層向上させることができる。
【０１２０】
なお、プロキシサーバ３００は、周辺機器に関する機能情報を要求するデバイス情報要求メッセージを数え、その数に応じてデバイスの優先度順位表を作成してもよい。
【０１２１】
［第２実施形態］
第１実施形態のとおりプロキシサーバ３００、あるいはプロキシサーバ３００の管理部０７０３を集約した管理ユーティリティ６００の設定操作部０７１１でクライアントへの応答が設定できる。この設定方法として、前述したクライアントに表示されるプリンタのセットアップ開始ダイアログ１００１と同じＵＩを使うことも可能である。
【０１２２】
図１３が、プロキシサーバ３００の設定操作部０７１１により表示されるダイアログ１３０１である。ＩＴマネージャ（プロキシサーバ３００の管理者）は、ダイアログ１３０１に表示されたデバイス名のリストから、クライアントへデバイス情報を応答するデバイスを選択する（チェックボックスをＯＮにする）。チェックの内容を示す情報はプロキシサーバ３００に記憶され、デバイス情報とともにクライアントＰＣ１００へと送信される。クライアントがデバイス情報を受信すると、デバイスドライバのインストール時にデバイス名のリストが図１０のように表示される。その際、プロキシサーバ３００から受信した選択状態を示す情報にしたがって、図１３のユーザインターフェースで選択されていたデバイスと同じデバイスが選択された状態で図１０のユーザインターフェースが表示される。
【０１２３】
この結果、プロキシサーバ３００において、ＩＴマネージャが共有度の高いプリンタを固定で設定することができる。また、クライアントの利用者は、ＩＴマネージャによる設定に拘束されずに、インストールするデバイスドライバを選択し直すこともできる。このため、第１実施形態と同等の構成、制御であればＩＴマネージャの共有度判断が省力化される。また、プロキシサーバ３００の操作、判断を拡張するなら第１実施形態の方法を「自動モード」とし、第２実施形態の方法を「手動モード」とわけた上で、いずれかのモードをプロキシサーバ３００の管理者が選択できるように構成することもできる。この場合には、利用者はプロキシサーバ３００においてモードの選択が行える。プロキシサーバ３００は選択されたモードに応じ、手動モード時にはＩＴマネージャによる選択デバイスを示す情報をクライアントに送信する。
【０１２４】
また、デバイスが手作業で選択されるために、第１実施形態で説明した図８の手順や図１１のステップ１１０４の手順を省略しても良い。こうすることでフック制御および共有順位表作成の負荷を低減することも可能である。
【０１２５】
［第３実施形態］
第１実施形態では、図５のステップ０５０８において他イベント（メッセージ）をプロキシサーバ３００によりフックした。メッセージをフックするために、図６の径路０６０７をとおるメッセージとメタデータとを参照する必要があり、処理０６０４でＵＲＩ差し替えをおこなっている。しかし、共有度順位表を作成するためのメッセージ参照の機能を外部システムがもっていればプロキシサーバ３００がメッセージをフックする必要性はなく、処理０６０４は省略してよい。
【０１２６】
図１４は、メッセージ参照の機能をシステムがもっている場合の一例を示す図である。プロキシサーバ３００は必要なイベントをシステムに設定し(11)、イベントが発生したら通知(12)をもらう（処理１４０７、１４０８）。システムとは、たとえばクライアントコンピュータ２００やサーバコンピュータ４００である。イベントとは、メッセージ送信を伴う動作であり、たとえば印刷要求（印刷命令）などがある。プロキシサーバ３００は、利用者により入力された、イベントを特定するための情報をクライアントやサーバに送信して登録させる。イベントを特定するための情報を受信したクライアントやサーバは、イベントが生じるとそのイベントがプロキシサーバ３００から登録されたイベントであるか判定する。登録されたイベントであれば、クライアントやサーバは、そのイベントに伴って送信されるメッセージの複製をプロキシサーバ３００に送信する。たとえばプロキシサーバ３００が、クライアントおよびプリンタに対して「印刷要求」をイベントとして登録した場合を想定する。この場合、クライアントは、印刷要求メッセージをデバイス（プリンタ）に送信するとともに、その複製をプロキシサーバ３００に送信する。プロキシサーバ３００は受信したメッセージに基づいてメッセージをカウントする。受信したメッセージは廃棄される。
【０１２７】
こうして、プロキシサーバ３００が実行するフック制御を処理１４０７、１４０８で代用する。その他は第１実施形態と同じ構成であり、第１実施形態と同様の効果が得られる。また、デバイス共有度順位表（実績テーブルともいう）０９０１に相当するログをシステムがもっている場合も、同様の代用ができる。
【０１２８】
［第４実施形態］
ＷＳ−Ｄｉｓｃｏｖｅｒｙ仕様にもとづき、デバイスがネットワークから離脱する際には、ネットワークに対してＢｙｅメッセージを送信（ブロードキャスト）する。前述のＨｅｌｌｏメッセージの逆の意味を持つメッセージである。このＢｙｅメッセージの受信をきっかけにして、第１実施形態のデバイスドライバあるいはアプリケーションのインストールと対となるアンインストール処理が実施可能である。
【０１２９】
共有度が高いＭＦＰ２００がネットワークからはずされた場合、一定時間待ったのち、クライアントはＭＦＰ２００のデバイスドライバをアンインストールする。この処理のフローを説明する。待ち時間は固定値であり、たとえば操作ＵＩから入力される値が記憶されて用いられる。このフローを実行すると、短時間のデバイス離脱と復帰に対するインストールやアンインストール処理の実行が抑制される。なお本実施形態では、デバイスはＢｙｅメッセージをブロードキャストせず、プロキシサーバ３００宛にユニキャストする。
【０１３０】
図１５は、デバイスからＢｙｅメッセージを受信した際、すなわち離脱時のプロキシサーバ３００による処理フローチャートを説明する。まずステップ１５０２では、プロキシサーバ３００が、Ｂｙｅメッセージの送信元デバイスを特定する。すなわち、プロキシサーバ３００が、メッセージに含まれる送信元アドレスを読み取る。ステップ１５０３では、プロキシサーバ３００がクライアントとの接続を確認する。接続の確認は、たとえばエコーメッセージの送信などにより行える。ステップ１５０４では、プロキシサーバ３００が待ち時間の設定を確認する。ここでいう確認とは、たとえば待ち時間の設定値を、プロキシサーバ３００の記憶領域から読み出すことである。
【０１３１】
次に、Ｂｙｅメッセージの送信元デバイスが、共有度が高いデバイスであるかを、ステップ１５０４で判定する。この判定は、プロキシサーバ３００が持つ共有度順位テーブルを、図１１で説明した処理方法でソートし、応答レベルの段階表現で説明したように「高」と「中」の境界を決定する。そして、Ｂｙｅの送信元デバイスが、「高」の範囲に含まれていれば、共有度が高いと判定される。共有度が高ければ、ステップ１５０９において、ネットワークに対して、Ｂｙｅメッセージをブロードキャストする。このＢｙｅメッセージの送信元アドレスは、図１５の処理のきっかけとなるＢｙｅメッセージの送信元デバイスのアドレスが書き込まれる。
【０１３２】
共有度が高くないと判定された場合でも、そのサービスに即時性が要求されか否かステップ１５０５で判定し、即時性が要求される場合にはネットワークにＢｙｅメッセージを送信する。この判断は、Ｂｙｅメッセージの送信元デバイスが提供するサービスに、あらかじめプロキシサーバ３００に登録されたサービスが含まれているか否かの判定により実行される。サービスはＩＤやＵＲＩで表される。
【０１３３】
いずれにも該当しない場合には待機処理をおこなう。その場合は、Ｂｙｅメッセージの送信元デバイスのＩＤを、Ｂｙｅ待ちデバイスのリストに追加登録する（ステップ１５０６）。そしてステップ１５０７にて、プロキシサーバ３００はＢｙｅ待ちにしたデバイスのステータスを外部には一次停止扱いに変更する。たとえば、当該デバイスに関してデバイス情報要求があれば、一時停止中である旨の情報を応答する。ステップ１５０８では、プロキシサーバ３００は、当該デバイスに関するＢｙｅメッセージの発行時間を、Ｂｙｅ待ちデバイスのリストに、デバイスＩＤと関連づけて登録する。この時間はたとえば、あらかじめ決めた定数でよい。プロキシサーバ３００は、ステップ１５１１〜１５１３で時間待ちループする。ステップ１５１２でデバイスが復旧すれば、ステップ１５１４にすすみ、復旧あるいは更新（メタデータから判断）処理をおこなう。デバイスの復旧は、たとえばそのデバイスからＨｅｌｌｏメッセージを受信したり、あるいは一定時間おきにプローブメッセージを送信し、その応答があれば復旧したと判断できる。ステップ１５１３でＢｙｅの発行時間がきたら、プロキシサーバ３００はステップ１５１５で一時停止にしていたステータスをたとえば「離脱」に変更する。そして、ステップ１５１６でそのデバイスがネットワークから離脱する旨のＢｙｅメッセージを発行（ブロードキャスト）する。Ｂｙｅメッセージを受信したクライアントは、その送信元デバイスのデバイスドライバをアンインストールする。
【０１３４】
以上の手順により、電源断などにより一時的に短期間ネットワークから離脱しているデバイスのデバイスドライバを、ネットワーククライアントがその都度アンインストールする必要がなくなる。このため、クライアントの処理効率が向上する。また、共有度が高いデバイス、あるいは即時性が要求されるサービスを提供するデバイスについては、ネットワークからの離脱後ただちに各クライアントからデバイスドライバをアンインストールさせる。こうすることで、利用頻度が高いデバイスや、即時性サービスのために利用されるデバイスが、離脱して休止状態とされた状態で放置された状態でいることにより、誤って選択されることを防止できる。
【０１３５】
また上述した実施形態においては、プラグアンドプレイの一例として、発見したネットワークデバイスに対応したドライバのインストール／アンイストールについて説明している。しかし、ネットワークデバイスを利用、制御するために必要なユーティリティ、アプリケーションなどをクライアントＰＣ１００に自動的にインストールする場合においても適用可能である。
【０１３６】
また、上述した実施形態ではネットワークデバイスとしてプリンタに対する実装例を示したが、通信媒体を介して利用、制御可能なデバイスであれば、スキャナ、ストレージデバイス等、いずれのデバイスに対しても適用可能である。
【０１３７】
また、上述した実施形態においては、クライアントＰＣ１００がネットワークデバイスを制御するためのドライバをメモリ上に保持する形態を示したが、ドライバに限らずアプリケーション、ユーティリティソフトウエアに対しても適用可能である。また、これらソフトウエアはネットワークデバイス上に保持されている場合、あるいは第３のサーバ上に保持されている場合にも適用可能である。
【０１３８】
また、第１実施形態では共有度順位表のソートを、項目ごとに優先順位を付して行ったが、各項目の値に重みを付けて加算し、その値をキーとしてソートするなど、他の方法を採用することもできる。
【０１３９】
また、図９（Ａ）や図９（Ｂ）の共有度順位表の各項目のいずれかをキーとして表をソートしても良いし、キーの優先順位を様々に変更することもできる。優先順位の変更は、どの項目を重要視するかにより変更される。
【０１４０】
また、デバイスが最初に接続された日時そのものをキーとして表をソートしても良い。またデバイスが最後に接続された日時を共有度順位表に登録し、その日時で表をソートすることもできる。
【０１４１】
[第５実施形態]
本実施形態では、クライアントＰＣ１００とプロキシサーバ３００間で実行されるメッセージのやり取りに従ってプリンタドライバの推奨度を更新する技術について説明する。なお、本実施形態では、推奨すべきデバイスを更新するための処理と、クライアントＰＣ１００からの要求に従って推奨デバイスを通知する処理がある。
【０１４２】
まず、本実施形態における推奨すべきデバイスを更新するための処理の流れについて図２８を参照して説明する。
【０１４３】
クライアントＰＣ１００は、デバイス探索要求（Ｐｒｏｂｅ）をマルチキャストにて発行する（２８０１）。なお、このＰｒｏｂｅには、対象デバイス情報を含むことができる。例えばプリンタの存在を確認するためのＰｒｏｂｅであれば、プリンタを特定したＰｒｏｂｅが発行される。また、Ｐｒｏｂｅには、カラープリンタ等を指定することも可能とする。
【０１４４】
Ｐｒｏｂｅを受信したデバイス２００は、Ｐｒｏｂｅに含まれるデバイス情報と一致するか判定する。例えば、Ｐｒｏｂｅにプリンタを特定する情報が含まれている場合、プリンタがＰｒｏｂｅに対する返答であるネットワーク参加通知（Ｈｅｌｌｏ）信号を返信する（２８０２）。なお、このＨｅｌｌｏ信号には、Ｈｅｌｌｏ信号を発行したデバイスのアドレス情報が含まれている。また、プロキシサーバ３００も、例えばプリンタの存在を確認するためのＰｒｏｂｅの受信に従って、当該プリンタに関する情報を保持しているか判定する。プロキシサーバ３００は、保持していれば当該Ｐｒｏｂｅに対する返答であるＨｅｌｌｏ信号を発行する。ここで、プロキシサーバ３００が発行するＰｒｏｂｅに対する返答Ｈｅｌｌｏには、プロキシサーバ３００からの返答であることを示す識別情報が含まれている。よって、プロキシサーバ３００が発行したことを示す識別情報付きのＨｅｌｌｏ信号を受信したクライアントＰＣ１００は、ステップ２８０２以降についてプロキシサーバ３００とメッセージ交換処理を実行する。なお、図２８では、クライアントＰＣ１００が、プロキシサーバ３００が発行したことを示す識別情報付きのＨｅｌｌｏ信号を受信したものとして説明する。
【０１４５】
クライアントＰＣ１００は、ステップ２８０２においてプロキシサーバ３００が発行したことを示す識別情報付きのＨｅｌｌｏを受信した場合、デバイス情報要求方法を選択する図２４の選択画面２４０１を表示する（ステップ２８０３）。デバイス情報要求方法の選択画面２４０１について説明する。選択画面２４０１には、通常要求２４０２と推奨度に従う推奨要求２４０３のいずれかを選択できる。なお、現段階では、通常要求２４０２が選択されたものとして処理を進める。また、推奨度に従う推奨要求２４０３が選択された場合の処理については、後述する。
【０１４６】
クライアントＰＣ１００は、選択画面２４０１にて選択されたデバイス情報の要求方法を含むデバイス情報要求信号を発行する（ステップ２８０４）。具体的にステップ２８０４にて発行されるデバイス情報要求は、図２５および図２７にて後述するデバイスリストを要求する信号である。なお、本実施例において、デバイス情報要求を第２メッセージと記載する場合もある。
【０１４７】
プロキシサーバ３００は、デバイス情報要求信号（デバイスリストの取得要求）の受信に従って、デバイス情報要求方法を解析する。現段階では通常要求が選択されているので、後述する図２６の管理情報等は用いずに所定のルール（例えばデバイス名称の昇順等）に基づくデバイスリスト（例えば図２５）を作成して、クライアントＰＣ１００へ発行する（ステップ２８０５）。なお、プロキシサーバ３００は、ステップ２８０１のＰｒｏｂｅにて指定されたデバイスに関するリストを発行すればよい。例えば、プロキシサーバ３００が、プリンタとファクシミリ機の２台のデバイスについての情報を保持している状態で、クライアントＰＣ１００からプリンタに関する探索要求を受信した場合を想定する。この場合、２８０５にて発行されるリストには、プリンタ情報のみが記載され、ファクシミリ機については除かれる。図２５は、デバイス情報返答に従ってクライアントＰＣ１００に表示されるデバイスリスト２５０１である。クライアントＰＣ１００は、デバイスリスト２５０１を介してユーザにより選択されたデバイスのサービス情報を要求する処理へと進む。
【０１４８】
続いてクライアントＰＣ１００は、ステップ２８０５のデバイス情報返答に従ってデバイスリストを表示する（ステップ２８０６）。上述したように現段階では通常要求２４０２が選択されたため、所定のルールの一例であるデバイス名称の昇順に従う図２５のデバイスリストが表示される。ここで、ユーザはデバイスリストを介して所望とするデバイスを選択する。図２５では、プリンタ１とプリンタ２が選択された様子を示している。
【０１４９】
クライアントＰＣ１００は、デバイスリストを介して選択されたデバイスのサービス情報を取得するため、サービス情報要求信号を発行する（ステップ２８０７）。このサービス情報とは、具体的にはデバイスの機能情報であり、機能情報とは、例えばカラー印刷が可能か否か、ステイプル処理が可能か否か等、デバイスが実行可能は機能情報である。なお、本実施例において、サービス情報要求を第１メッセージと記載する場合もある。
【０１５０】
そして、プロキシサーバ３００は、サービス情報要求時にサービス情報が要求されたデバイスを特定し、デバイスのメッセージ数に基づく優先度を更新し、要求されたデバイスのサービス情報をクライアントＰＣ１００に返送する（ステップ２８０８）。
【０１５１】
ここで、図２６を用いて、プロキシサーバ３００が管理している各デバイスの優先度を更新するためのメッセージ数管理情報を説明する。図２６には、プリンタごとにサービス情報が要求された回数を管理している。例えば、図２５では、プリンタ１とプリンタ２が選択され、サービス情報要求が発行されたので、プロキシサーバ３００は、当該サービス情報要求に従って、プリンタ１とプリンタ２のメッセージ数をインクリメントする。その結果、プロキシサーバ３００は、どのデバイスがどれだけサービス情報を要求されたか（デバイスリストを介して選択されたか）をメッセージ数に基づいて管理することができる。そこで、プロキシサーバ３００は、メッセージ数の多かったデバイスを多くのユーザが共有しているデバイスであると認識して優先度をあげる。
【０１５２】
クライアントＰＣ１００は、サービス情報返答に従ってプリンタドライバをインストールする（ステップ２８０９）。
【０１５３】
続いて、図２８を用いて本実施形態における、クライアントＰＣ１００からの要求に従って推奨デバイスリストを表示する処理について説明する。なお、ステップ２８０１から２８０２は上述した処理と同様であるため詳細な説明は省略する。
【０１５４】
クライアントＰＣ１００は、ステップ２８０２においてプロキシサーバ３００が発行したことを示す識別情報付きのＨｅｌｌｏを受信した場合、デバイス情報要求方法を選択する図２４の選択画面２４０１を表示する（ステップ２８０３）。今回は、推奨度に従う推奨要求２４０３が選択された場合の処理について説明する。
【０１５５】
クライアントＰＣ１００は、デバイス情報要求時に表示される図２４の画面を介して選択された推奨要求２４０３に基づくデバイス情報要求を発行する（ステップ２８０４）。
【０１５６】
プロキシサーバ３００は、推奨要求２４０３が選択されたデバイス情報要求を受信した場合、図２６にて管理している情報に従って優先度順に並べたデバイスリストを作成してクライアントＰＣ１００に応答する（ステップ２８０５）。
【０１５７】
クライアントＰＣ１００は、ステップ２８０５の応答に従って優先度に従うデバイスリストを表示する（ステップ２８０６）。ここで、図２７を用いて優先度に従うデバイスリスト２７０１を説明する。プロキシサーバ３００は、図２６に示すような情報を管理しているとする。ここで、プロキシサーバ３００は、各デバイスのメッセージ数に基づいて優先度を決定し優先度順に並べたデバイスリストを作成する。その結果、図２７に示す優先度順に並べたデバイスリスト２７０１がクライアントＰＣ１００へ応答される。
【０１５８】
クライアントＰＣ１００は、例えば図２７に示すようなデバイスリスト２７０１を表示するため、ユーザは、優先度の高い（すなわち多くのユーザがインストールしている）プリンタドライバを容易に特定できる。そして、例えばネットワークに新規に参加したユーザは、多くのユーザによって共有されているプリンタドライバをインストールすることが可能となる。
【０１５９】
続いて、図２９を用いて本実施形態におけるプロキシサーバ３００の処理を説明する。
【０１６０】
プロキシサーバ３００は、デバイス探索要求（Ｐｒｏｂｅ）を受信したか否かを判定する（Ｓ２９０１）。
【０１６１】
Ｓ２９０１において、デバイス探索要求を受信したと判定された場合、プロキシサーバ３００は、Ｈｅｌｌｏ信号を、Ｐｒｏｂｅ信号の送信元のクライアントＰＣ１００に対して発行する（Ｓ２９０２）。そのＨｅｌｌｏ信号には、プロキシサーバ３００によって発行されたことを示す識別情報が付いている。なお、受信したＰｒｏｂｅ信号には、発行元クライアントＰＣ１００のアドレス情報が含まれているので、プロキシサーバ３００は、当該アドレスに対してＨｅｌｌｏ信号を発行する。
【０１６２】
続いて、プロキシサーバ３００は、クライアントＰＣ１００からデバイス情報要求を受信したか否かを判定する（Ｓ２９０３）。
【０１６３】
Ｓ２９０３において、プロキシサーバ３００が、デバイス情報要求を受信したと判定した場合、優先度に従うリストを要求する推奨要求か否かを判定する（Ｓ２９０４）。
【０１６４】
Ｓ２９０４において推奨要求ではないと判定された場合（Ｓ２９０４−Ｎｏ）、プロキシサーバ３００は、例えばプリンタ名称の昇順に従うデバイスリストを作成する（Ｓ２９０６）。
【０１６５】
一方、Ｓ２９０４において推奨要求であると判定された場合（Ｓ２９０４−Ｙｅｓ）、プロキシサーバ３００は優先度に従うリストを作成する。具体的には、プロキシサーバ３００は、クライアントＰＣ１００から要求されるサービス情報要求をデバイスごとにカウントしており、デバイスごとにクライアントＰＣ１００から受信したメッセージ数を管理している。この管理している情報を示す図が、上述した図２６である。つまり、プロキシサーバ３００は、サービス情報要求を受信する度に、どのデバイスのサービス情報を要求しているかを解析し、要求されたデバイスのメッセージ数を示すメッセージカウンタを１ずつカウントしている。そして、このカウント値が優先度となる。よって、プロキシサーバ３００は、Ｓ２９０５において優先度に従う（メッセージ数に従う）デバイスリストを作成して通知する。
【０１６６】
プロキシサーバ３００は、サービス情報要求を受信したか否かを判定する（Ｓ２９０７）。そして、サービス情報要求を受信した場合、プロキシサーバ３００は、どのデバイスに対するサービス情報が要求されたかを解析し、要求されたデバイスに対応するメッセージカウンタすなわち管理情報を更新する（Ｓ２９０８）。
【０１６７】
このように本願では、デバイス情報要求（デバイスリスト要求）時に、通常要求、または、多くのユーザがインストールしている推奨デバイスを特定可能なリストを要求する推奨要求を選択できる。そして、推奨要求が選択された場合、プロキシサーバ３００は、多くのユーザがインストールしているデバイス順に並べられた推奨デバイスリストを作成して通知する。そのため、プリンタドライバのインストールを実行するユーザは、例えば新規にネットワークに参加したユーザであっても容易に多くのユーザがインストールしている共有度の高いデバイスドライバに絞ったインストールを実現することが可能となる。
また、優先度の高いデバイスを決定する方法としては、各デバイスの使用履歴に従って決定する方法が挙げられる。この方法の問題点について説明する。例えば、通常はモノクロ印刷を実行するのでモノクロプリンタを頻繁に使用し、数ヶ月に１度の会議用にカラー印刷を実行するためカラープリンタを使用する環境を想定する。この場合、カラープリンタは、ほとんど使用されないため推奨デバイスとして抽出されないおそれがある。これでは、新規にネットワークに参加したユーザが、いざカラー印刷を実行したい場合、カラープリンタのプリンタドライバがインストールされていないため迅速にカラー印刷を実行することができなくなるおそれがある。
【０１６８】
しかし、本願では、多くのユーザがインストールしているデバイスを推奨するため、上記のような問題が発生するおそれを低減でき、当該ネットワークにおいて最低限必要なデバイスドライバをインストールすることが可能となる。
【０１６９】
＜発明のまとめ＞
以上、実施形態で説明した本発明に係るプロキシサーバの構成および動作を列記すると以下のようなものとなる。
（１）情報処理装置からのネットワークデバイス（たとえばディジタル複合装置）の共有度順位を判断する。
（２）共有度順に複合装置の情報（デバイス情報）を選択し、選択したデバイス情報を情報処理装置へ応答する。
（３）クライアントでは、選択されたデバイスのデバイスドライバ等のソフトウエアのインストールを誘導する。
（４）クライアント（情報処理装置）およびデバイスの個体識別をおこない、情報処理装置とデバイス間のメッセージを参照するためのアドレス情報（ＵＲＩ）変換と記録機能を持つ。
（５）利用実績表（共有度順位表）を作成する。共有度を判断する条件は以下の通りである。
−デバイス（複合装置）へのクライアント（情報処理装置）の接続数、
−デバイスへのクライアントの利用量（メッセージ量）、
−デバイスとクライアントのネットワークスコープ比較、
−デバイスの提供機能。
（６）共有度、新規追加デバイス、過去に利用実績のあるデバイスに該当するデバイスを列挙し、そのデバイス情報をクライアントに送信する。
（７）列挙範囲を設定により制御する。
（８）初期選択を設定により制御する。
（９）デバイス情報をクライアントへ選択応答する内容が設定できる。
（１０）操作ＵＩを表示する。その操作ＵＩは段階表現、順位表、個数のいずれかを設定する形式である。
（１１）初期選択とその後ユーザが追加および解除選択したデバイスに対してデバイスドライバ等のソフトウエアのイストールを誘導する。
（１２）操作ＵＩを表示し、その操作ＵＩはデバイスを個別に選択できる形式である（第２実施形態）。
（１３）クライアントやデバイスがイベント通知機能を持っていれば、情報処理装置と複合装置間のメッセージを参照するためのアドレス情報（ＵＲＩ）変換と記録の手段をイベント通知機能で代用する（図１４、第３実施形態）。
（１４）クライアントやデバイスがイベントログ機能を持っていれば、利用実績表（共有度順位表）の内容をシステムイベントログから複製する。これは実施形態には記載されていない。しかし、たとえばメッセージをフックしてデバイス別やサービス別にカウントするというプロキシサーバによる機能と同様のログ機能を持つクライアントもある。プロキシサーバは各クライアントにログを要求して受信し、共有度順位表を作成できる。そのタイミングはたとえば定期的あるいはデバイス情報要求を受信したときである。
（１５）デバイスのネットワークからの離脱時は、プロキシサーバは、クライアントが保持するデバイスのステータスを一次停止にする。また、待ち時間を設定する。また、デバイスが復旧しないまま待ち時間が経過すれば、クライアントにデバイスの離脱を通知してドライバを削除させる。復旧すれば、その旨をクライアントに通知する。
（１６）内部的に階層的な接続部、フロー制御部、管理部の各構造をもつ。
（１７）記録、判断、設定を担当する管理機能部は分離できる。
（１８）分離された管理機能部をサーバに集約配置可能である。
（１９）分離された管理機能部を管理ユーティリティと接合できる。
【０１７０】
［実施形態における発明の関連づけ］
実施形態記載の発明は、以下のように記載することもできる。すなわち、本発明は、周辺機器（デバイス２００）および端末（クライアントＰＣ１００）と通信可能な情報処理装置（プロキシサーバ３００）に係るものである。本装置は、保存手段と、係数手段と、受信手段と、応答手段とを有する。本装置において、保存手段はＨＤＤ１１に保存されたデバイスリスト１１ａに相当する。保存手段は、前記周辺機器（２００）から該周辺機器に関する情報（デバイス情報１８０４）を受信して保存する。
【０１７１】
また、計数手段は、プロキシサーバ３００のＣＰＵ１によりステップＳ１７０１−Ｓ１７０９を実行して共有度順位表０９０１を作成することに相当する。係数手段は、前記端末（１００）および前記周辺機器間（２００）において送受信されているメッセージ情報（１８０９）を周辺機器毎に数えることにより得られる周辺機器毎の共有度を計数する。
【０１７２】
また、受信手段は、プロキシサーバ３００のＣＰＵ１によりデバイス情報要求１８０７を受信することに相当する。要求メッセージ受手段手段は、前記端末（１００）から、前記保存手段（デバイスリスト１１ａ）にて保持されている周辺機器に関する情報を要求する要求メッセージ（デバイス情報要求１８０７）を受信する。
【０１７３】
また、応答手段は、プロキシサーバ３００のＣＰＵ１によりデバイス検索処理１８０７ａを実行することに相当する。応答手段は、前記受信手段により前記要求メッセージ（デバイス情報要求１８０７）を受信することに応じて、前記計数手段により得られる周辺機器毎の共有度に従って選択された周辺機器に関する情報を、前記端末に送信する。
【０１７４】
さらに、前記計数手段は、前記端末から前記周辺機器へのメッセージを受信し、受信したメッセージの宛先および送信元情報に基づいて、周辺機器毎に、送信元となった端末数を数えて前記共有度を計数し、
また本装置は、前記周辺機器に前記計数手段により得られた共有度を用いて、該端末数をキーとして整列した順位を共有度の順位とする共有度順位情報を作成する作成手段をさらに有する。作成手段は、ＣＰＵ１が、ステップＳ０８０１−Ｓ０８０６を実行して共有度順位表０９０１を作成することに相当する。
【０１７５】
また前記応答手段は、前記作成手段によって作成された共有度順位情報を用いて送信すべき周辺機器に関する情報を選択する。
【０１７６】
あるいは、第５実施形態に係る発明については以下のようにも言い得る。すなわち、本発明は、周辺機器（デバイス２００）および端末（クライアントＰＣ１００）と通信可能な情報処理装置（プロキシサーバ３００）に係るものである。本装置は、保存手段と、第１応答手段と、更新手段と、受信手段と、第２応答手段とを有する。本装置において、保存手段は、ＨＤＤ１１：デバイスリスト１１ａに相当する。保存手段は、前記周辺機器（２００）から該周辺機器に関する機能情報（１８０４）を受信して保存する。
【０１７７】
また、第１応答手段は、ＣＰＵ１によるサービス情報応答２８０８の送信に相当する。第１応答手段は、前記端末（１００）からの、周辺機器（２００）に関する機能情報を要求する第１メッセージ（サービス情報要求２８０７）の受信に従って、前記保存手段（ＨＤＤ１１）によって保存された機能情報（１１ａ）を前記端末（１００）に送信する。
【０１７８】
また、更新手段は、ＣＰＵ１が、ステップＳ２９０８を実行してメッセージカウンタを更新することに相当する。更新手段は、前記端末（１００）からの、周辺機器（２００）に関する機能情報（１１ａ）を要求する前記第１メッセージ（サービス情報要求２８０７）の数に基づいて推奨すべきデバイスの優先度を更新する。
【０１７９】
また、受信手段は、ＣＰＵ１が、デバイス情報要求２８０４を受信することに相当する。受信手段は、前記端末（１００）から、推奨する周辺機器のリスト（リスト２５０１）を要求する第２メッセージ（デバイス情報要求２８０４）を受信する。
【０１８０】
また、第２応答手段は、ＣＰＵ１が、ステップＳ２９０５を実行することに相当する。第２応答手段は、前記受信手段により前記第２メッセージ（２８０４）を受信することに応じて、前記更新手段によって更新された優先度に従って決定される周辺機器のリストを、前記端末に送信する。
【０１８１】
［他の実施形態］
上述した実施形態におけるクライアントＰＣ１００及びネットワーク対応デバイス２００における各処理機能は、各処理機能を実現する為のプログラムをメモリから読み出してＣＰＵ（中央演算装置）が実行することによりその機能を実現させる。しかしこれに限定さるものではなく、各処理機能の全部または一部の機能を専用のハードウェアにより実現してもよい。また、上述したメモリは、光磁気ディスク装置、フラッシュメモリ等の不揮発性のメモリにより構成されても良い。また、ＣＤ−ＲＯＭ等の読み出しのみが可能な記録媒体、ＲＡＭ以外の揮発性のメモリ、あるいはこれらの組合せによるコンピュータ読み取り、書き込み可能な記録媒体より構成されてもよい。
【０１８２】
また、クライアントＰＣ１００またはネットワーク対応デバイス２００内の各機能を実現する為のプログラムをコンピュータ読み取り可能な記録媒体に記録しておく。この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより各処理を行っても良い。ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含む。具体的には、記憶媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書きこまれる。その後、そのプログラムにしたがって、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含む。
【０１８３】
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置を含む。さらに「コンピュータ読み取り可能な記録媒体」とは、通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発メモリ（ＲＡＭ）のように、一定時間プログラムを保持しているものも含むものとする。
【０１８４】
また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことをいう。
【０１８５】
また、上記プログラムは、前述した機能の一部を実現する為のものであっても良い。さらに、前述した機能をコンピュータシステムに既に記録されているプログラムとの組合せで実現できるもの、いわゆる差分ファイル（差分プログラム）であっても良い。
【技術分野】
【０００１】
本発明は、たとえばネットワークに対応した周辺装置に接続される情報処理装置及び情報処理方法及びそのプログラムに関するものである。
【背景技術】
【０００２】
従来、ネットワーク環境における共有プリンタの監視や管理処理は、ＩＴ（情報技術）マネジャとサーバに集約され、ユーザへメールサービスを利用して通知する形態が一般的であった。管理処理の特定プロセスでの手動作業をメールサービスへおきかえ自動化することでＩＴマネジャやユーザの負担軽減をはかった。サーバはインストーラを作成し、それを添付したメールを配布し ユーザが実行することでネットワーク共有プリンタのインストールはおこなわれていた（例えば特許文献１参照）。ネットワーク共有プリンタを監視、削除される際のユーザへの通知はサーバからメールによっておこなわれていた（例えば特許文献２参照）。
【０００３】
一方、インターネットやホームネットワークなど、ネットワークの拡張に伴い、例えば、ＰＤＡや携帯電話等のユーザインタラクティブなデバイス、スキャナ、プリンタ、複写機、デジタルカメラ等の画像処理装置におけるネットワーク対応が進んでいる。また、テレビ、エアコン、冷蔵庫等の家電製品などに至るまで様々なデバイスのネットワーク対応も進んでいる。それに伴い、ネットワーク対応デバイスを利用する上での利便性を高め、また管理の容易性を高めるために、ネットワークデバイスを管理する機能を提供するさまざまなプロトコルやアーキテクチャが提案されている(特許文献３，４)。提供される機能には、たとえばサービスを提供するネットワークデバイスの探索や、ネットワークデバイスを制御するためのアプリケーションソフトウエア、ユーティリティソフトウエア、オペレーティングシステム等の自動セットアップなどがある。
【０００４】
また、ネットワークデバイスの管理を自動化するための試みもある。たとえば、マイクロソフト社が主体となって、ＵＰｎＰ（登録商標）、およびＷＳＤ:Web Services for Devices (WS-Discovery/WS-MetadataExchange）の策定が進められている。これは、デバイスをネットワークに接続するだけでそのデバイスを使用可能とする、いわゆるプラグアンドプレイを実現するためのものである。
【０００５】
さらに、ネットワーク環境における共有プリンタの監視や管理処理は、ＩＴ（情報技術）マネジャとサーバに集約され、ユーザへメールサービスを利用して通知する形態が一般的であった。しかし、ＩＴマネジャやユーザの負担軽減を図るため、管理処理の特定プロセスでの手動作業をメールサービスへおきかえ自動化する技術が開示されている（特許文献４）。特許文献４に記載のサーバはインストーラを作成し、それを添付したメールを配布し ユーザが実行することでネットワーク共有プリンタのインストールがおこなわれていた。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０００−２１５１２８号公報
【特許文献２】特開２００４−２８０２１８号公報
【特許文献３】特開２００４−０３８９５６号公報
【特許文献４】特開２００４−３６２５９４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、ネットワークデバイスにプラグアンドプレイが普及することによってその利便性が向上する一方で、ネットワークに接続されたデバイスのドライバが自動でインストールされてしまうことに起因する弊害も生じる。その弊害のひとつとして、クライアントコンピュータに導入（インストール）されたドライバの数が増大し続ける点が挙げられる。
【０００８】
例えば、デバイスドライバが自動的にインストールされる場合、ユーザが必要としないデバイスドライバまでもインストールされる状況が考えられる。その結果、ユーザが利用したいネットワークデバイスの選択が困難となるだけでなく、利用実績が少なく、過去において好んで選択されないデバイスに対して印刷指示を行ってしまう恐れもある。
【０００９】
本発明は上記課題を解決するために、ネットワークプラグアンドプレイ機能により検出されたネットワークデバイスのうちから、共有度が高いデバイスを選択的に通知することを目的とする。
【課題を解決するための手段】
【００１０】
上記目的を達成するために本発明は以下の構成を備える。すなわち、
端末と通信可能な情報処理装置であって、
端末による利用実績がある周辺機器があるか判定する判定手段と、
前記判定手段によって前記周辺機器があると判定された場合、利用実績が新しい順に列挙された周辺機器の情報を前記端末に通知する通知手段とを有し、
前記利用実績は、印刷処理の利用実績であることを特徴とする。
【発明の効果】
【００１１】
本発明により、複数のネットワークデバイスが接続されたネットワークにコンピュータを接続した場合でも、利用される可能性の高いデバイスに絞って通知できる。
【図面の簡単な説明】
【００１２】
【図１】本発明の一実施形態としてのネットワークプラグアンドプレイシステムの構成を示すブロック図
【図２】クライアントからデバイスへの検索制御フロー図
【図３】メタデータの形式を示した図
【図４】Ｐｒｏｂｅ Ｍａｔｃｈメッセージの内容を示した図
【図５】プロキシサーバ３００をもちいた接続フロー図
【図６】本発明のプロキシサーバ３００制御の概要説明図
【図７】本発明のプロキシサーバ３００の内部構成図
【図８】本発明の共有度判断の概念図
【図９】本発明のデバイス共有度の順位表の図
【図１０】本発明でクライアントに表示されるインストールＵＩ図
【図１１】プロキシサーバ３００からのデバイス列挙制御のフローチャート
【図１２】プロキシサーバ３００の順位表を利用した設定ＵＩの一例を示す図
【図１３】プロキシサーバ３００でデバイス個別選択する場合の設定ＵＩの一例を示す図
【図１４】メッセージ参照機能をプラグアンドプレイシステムがもっている場合のフロー図
【図１５】デバイス離脱時のプロキシサーバ３００制御のフローチャート
【図１６】クライアント及びデバイスのブロック図
【図１７】プロキシサーバ３００がフックしたメッセージを集計する手順のフロー図
【図１８】ネットワークプラグアンドプレイシステムにおけるメッセージシーケンス図
【図１９】プロキシサーバ３００が保持するクライアントリストの一例を示す図
【図２０】プロキシサーバ３００が保持するデバイスリストの一例を示す図
【図２１】共有度順位情報を反映したデバイスリストの一例を示す図
【図２２】クライアントに送信するデバイス情報の一例を示す図
【図２３】プロキシサーバ３００の処理を説明するフロー図
【図２４】デバイス情報要求方法を選択するためのダイアログの一例を示す図
【図２５】デバイス情報要求に従って表示されるデバイスリストの一例を示す図
【図２６】プロキシサーバ３００が管理するメッセージ要求数の一例を示す図
【図２７】デバイス情報要求に従って表示されるデバイスリストの一例を示す図
【図２８】本願第５実施形態のシーケンス図の一例を示す図
【図２９】第５実施形態のプロキシサーバ３００が実行する処理のフローチャート
【発明を実施するための形態】
【００１３】
［第１実施形態］
以下に、図面を参照して、この発明の好適な実施の形態を例示的に詳しく説明する。ただし、この実施の形態に記載されているプロトコル、バージョン、アドレス、その他の数値等は、特に特定的な記載がない限りは、この発明の範囲をそれらのみに限定する趣旨のものではない。
【００１４】
＜クライアントとデバイスの接続の基本説明＞
図１は、本発明の一実施形態としてのネットワークプラグアンドプレイシステムの構成を示すブロック図である。クライアントＰＣ（クライアントデバイスとも言う）１００は、通信機能としてＥｔｈｅｒｎｅｔ（登録商標）等のＬＡＮ，ＷｉＦｉ（登録商標）（ＩＥＥＥ８０．１１ａ／ｂ／ｇ）等の無線ＬＡＮ，Ｂｌｕｅｔｏｏｔｈ（登録商標）に対応している。それぞれの通信機能は、Ｅｔｈｅｒｎｅｔ（登録商標）コントローラ０１０１、ＷｉＦｉ（登録商標）コントローラ０１０２、Ｂｌｕｅｔｏｏｔｈ（登録商標）コントローラ０１０３により制御される。これらコントローラの上位レイヤには、ＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック０１０４が備えられ、そのプロトコルスタック上にＨＴＴＰ処理部０１０５が備えられている。ＨＴＴＰ処理部０１０５は、ＨＴＴＰリクエストの解析、およびレスポンス処理を行う。
【００１５】
ＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック０１０４、およびＨＴＴＰ処理部０１０５の上位層には、Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ（ＳＯＡＰ）プロセッサ０１０６が備えられている。プラグアンドプレイモード設定ユーティリティ０１０７は、ＳＯＡＰプロセッサ０１０６を介して、ｅＸｔｅｎｓｉｂｌｅ ＭａｒｋｕｐＬａｎｇｕａｇｅ（ＸＭＬ）で記述されたデータの双方向通信を実現する。ＷＳＤモジュール０１０８、およびユーティリティ０１１４、アプリケーション０１１５それぞれも同様である。
【００１６】
ネットワークマネージャ０１０９は、Ｅｔｈｅｒｎｅｔ（登録商標）コントローラ０１０１、ＷｉＦｉ（登録商標）コントローラ０１０２、Ｂｌｕｅｔｏｏｔｈ（登録商標）０１０３コントローラを管理するモジュールである。ネットワークマネージャ０１０９は、各コントローラの設定情報、通信状態に関する情報を取得する機能を備える。
【００１７】
ＷＳＤモジュール０１０８は、ＳＯＡＰプロセッサ０１０６を介して、ネットワークデバイスから通知されるＨｅｌｌｏメッセージに対する応答処理、および、ネットワークデバイス検索のためのＰｒｏｂｅメッセージの発行処理を実行する。また、ＧｅｔＭｅｔａｄａｔａメッセージを発行することで、ネットワークデバイスの属性情報を取得する。属性情報は、デバイスの備えるハードディスク等の記憶部に記憶されている。
【００１８】
ネットワークデバイスの属性情報には、そのデバイスのデバイスＩＤや、そのデバイスにより提供されるサービスＩＤが含まれている。サービスとは、デバイスが提供する個々の機能を指す。たとえばデバイスがディジタル複合機であり、印刷機能とスキャン機能をあわせ持っていれば、プリントサービスとスキャンサービスとが利用できることを含んだ情報が提供される。さらに、プリント機能が複数のＰＤＬに対応していれば、各ＰＤＬに対して提供されるプリント機能はそれぞれ独立したサービスである。
【００１９】
これらのメッセージ処理により、クライアントＰＣ１００がネットワークデバイスを発見した場合、ＷＳＤモジュール０１０８はプラグアンドプレイコントローラ０１１１に対して、発見したネットワークデバイスの属性情報を通知する。プラグアンドプレイコントローラ０１１１は該属性情報をもとに該当するドライバ、ユーティリティソフトウエアをメモリコントローラ０１１０を介してメモリより読み込み、インストールを実行する機能を備える。
【００２０】
アプリケーション０１１５は、例えばワードプロセッサなどのアプリケーションプログラムである。アプリケーション０１１５は、編集した文書をネットワークデバイス・プリンタにより印刷するための機能を有する。その際、アプリケーション０１１５から出力された文書データは、プラグアンドプレイコントローラ０１１１によりインストールされたドライバ、ユーティリティを介して、ネットワーク対応デバイス２００に送信される。
【００２１】
一方、ネットワーク対応デバイス２００、すなわち本実施の形態ではネットワーク対応型プリンタは以下の構成を有する。ネットワーク対応デバイス２００は、Ｅｔｈｅｒｎｅｔ（登録商標），ＷｉＦｉ（登録商標）（ＩＥＥＥ８０．１１ａ／ｂ／ｇ），Ｂｌｕｅｔｏｏｔｈ（登録商標）に対応した通信機能を持つ。各通信機能は、それぞれＥｔｈｅｒｎｅｔ（登録商標）コントローラ０１１６、ＷｉＦｉ（登録商標）コントローラ０１１７により制御される。これらコントローラの上位レイヤには、ＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック０１１８が備えられ、そのプロトコルスタック上にＨＴＴＰ処理部０１１９が備えられる。ＨＴＴＰ処理部０１１９は、ＨＴＴＰリクエストの解析、およびレスポンス処理を行う。
【００２２】
ＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック０１１８、およびＨＴＴＰ処理部０１１９上位層にはＳｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ（ＳＯＡＰ）プロセッサ０１２０を備える。そのため、ＷＳＤモジュール０１２１、およびプリンタコントローラ０１２２が、それぞれ該処理部を介してｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（ＸＭＬ）で記述されたデータの双方向通信を実現可能となる。
【００２３】
ここで、ＷＳＤモジュール０１２１は、ＳＯＡＰプロセッサ０１２０を介してネットワークに接続した際に、Ｈｅｌｌｏメッセージの送信、およびクライアントＰＣ１００から発行されるＰｒｏｂｅメッセージに対する応答処理を実行する。
【００２４】
また、クライアントＰＣ１００から発行されたＧｅｔＭｅｔａｄａｔａメッセージに応じ、ネットワーク対応デバイスは、属性情報（本実施形態の場合、ネットワーク対応プリンタが持つ属性情報）を返信する。属性情報は、たとえばデバイス自体の情報（デバイス情報）であり、デバイスが提供するサービスの情報（サービス情報）である。
【００２５】
＜印刷システムのハードウェア構成＞
図１６は、本発明の実施の形態である情報処理装置とプリンタのハードウェア構成を示すブロック図である。図１６では、プロキシサーバ３００とネットワークデバイスであるプリンタ３０００とがネットワーク３１を介して接続された構成となっている。プロキシサーバ３００ではコンピュータ本体２０００に対して外部装置であるキーボード９、ＣＲＴ１０、ハードディスク１１等が接続されている。コンピュータ本体２０００はＣＰＵ１を備え、ＣＰＵ１はＲＯＭ３やハードディスク１１に記憶された制御プログラムやアプリケーションをＲＡＭ２に展開して演算を行うことができる。また、外部装置であるキーボード９からの入力を制御しているのがキーボードコントローラ（ＫＢＣ）５である。また、ＣＲＴ１０の表示を制御しているのがＣＲＴコントローラ（ＣＲＴＣ）６であり、ハードディスク１１に対して入出力の制御を行っているのがハードディスクコントローラ（ＨＤＣ）７である。ＮｅｔＣ８はネットワークコントローラであり、ネットワーク３１を介してプリンタ３０００に接続されて、プリンタコントローラ部４０００との間の通信制御を行っている。
【００２６】
これらＣＰＵ１、ＲＡＭ２、ＲＯＭ３、ＫＢＣ５、ＣＲＴＣ６、ＨＤＣ７、ＮｅｔＣ８はそれぞれシステムバス４によって接続され、各デバイスをＣＰＵ１が総括的に制御している。ＨＤＤ１１には、ネットワークデバイス、特に本実施形態ではネットワークプリンタの利用頻度を順位付けした共有度順位表０９０１およびデバイス情報やサービス情報のリスト（デバイスリストあるいは機器情報）１１ａが保存されている。共有度順位表０９０１は、プロキシサーバ３００にネットワークデバイスの名称（識別子）のほか、プロキシサーバ３００が収集した情報（図１７等で説明する）が含まれている。デバイスリスト１１ａや共有度順位表０９０１は、ハードディスク１１に保存され、ＣＰＵ１によりアクセスされる際にＲＡＭ２にロードされる。なお、共有度順位表は共有度順位情報ともいう。ＨＤＤ１１やＲＡＭ２のデバイスリスト１１ａは、保存手段として機能する。あるデバイスの共有度とは、端的にはそのデバイスを使用したクライアントの数である。ただし、重複するクライアントは排除される。本実施形態では、共有度とは、図９に例示するように、クライアント数とその他の指標を複合させた複合的な指標である。
【００２７】
本実施形態では、プロキシサーバ３００としてパーソナルコンピュータ（ＰＣ）を想定している。つまり、プロキシサーバ３００は、情報処理装置である。しかし、本発明を実施可能な形態であれば、プロキシサーバ３００はＰＣに限定するものではなく、ＰＤＡなどの携帯情報端末や携帯電話、ディジタル家電等をクライアントとしてもよい。いずれの装置も、特定用途の入出力デバイス等を除けば、図１のプロキシサーバ３００と同様の構成を有する。
【００２８】
ネットワークプリンタ３０００において、プリンタＣＰＵ２１は、ＲＯＭ２３のプログラム用領域に記憶された制御プログラムを実行する。制御プログラムの実行により、バス２４に接続される各種のデバイスとのアクセスを総括的に制御し印刷部２６を介して接続される印刷機構部２８（プリンタエンジン）に印刷データとしての画像信号が出力される。
【００２９】
プリンタＣＰＵ２１はネットワークコントローラ（ＮｅｔＣ）２５を介してプロキシサーバ３００及び不図示のクライアントＰＣ１００との通信処理が可能である。通信によりネットワークプリンタ３０００内の情報等をプロキシサーバ３００およびクライアントＰＣ１００に通知可能に構成されている。ＲＡＭ２２はプリンタＣＰＵ２１の主メモリ、ワークエリアなどとして機能する。また、ＲＡＭ２２はクライアントＰＣ１００（不図示）より受信した印刷データや画像ビットマップデータを格納しておくための描画メモリ、ビデオ信号情報格納領域、その他としても使用される。ハードディスクコントローラ２７にて制御されるハードディスク２９は印刷ジョブデータのＢＯＸ保存などのために使用される。操作パネル３０はユーザがネットワークプリンタ３０００を操作する際のユーザインターフェースであり各種スイッチやＬＥＤ表示機器の他、タッチパネル式の液晶パネルなどで構成される。
【００３０】
ハードディスク２９には、プリンタ３０００の構成を示す構成情報データベース２９０１が保存されている。構成情報データベースは、各種のデータを含むデータベースである。構成情報データベース２９０１には、デバイスタイプ情報、サービス情報、デバイスの使用頻度情報、デバイス機能情報、製造メーカ情報など、デバイス情報やサービス情報の基礎となる情報が含まれている。なお、デバイス機能情報とは、印刷速度情報、カラー印刷機能の有無を示すカラー機能情報、最高解像度情報、両面印刷機能の有無を示す両面機能情報等である。デバイスタイプ情報は、たとえば当該デバイスが単機能プリンタや、複写機などデバイスのタイプを示す。サービス情報は、当該タイプのデバイスにより提供されるサービスを示す。たとえばプリンタであれば、ｐｏｓｔｓｃｒｉｐｔ（登録商標）など、対応するＰＤＬの種類を示す情報がサービス情報として登録されている。なお、本例ではＰＤＬの種類はＵＲＩで示される。
【００３１】
なお、ネットワークプリンタ３０００は本発明の機能を実施できる装置であればシングルファンクションプリンタでもスキャナやコピー、ファクシミリ等の機能も備えたマルチファンクションプリンタでもよい。印刷機構部２８としてレーザービームプリンタやインクジェットの印刷機構を用いたプリンタ、サーマルプリンタなどいかなるプリント方式を用いていようが、本発明の機能に制限をするものではない。また、図１に記述したクライアントＰＣのハードウェア構成も、図１６の情報処理装置３００と同様である。
【００３２】
＜デバイス検索手順＞
図２（Ａ）を参照して、クライアントＰＣ１００より、ネットワーク上で利用可能な状態にあるネットワーク対応デバイス２００を検索する場合の制御の流れフロー形式で説明する。なお、図２（Ａ）、図２（Ｂ）と同様のシーケンスは、プロキシサーバ３００とネットワーク対応デバイス２００との間においても実行される。プロキシサーバ３００は、図２（Ａ）、図２（Ｂ）のシーケンスを通して、ネットワーク対応デバイス２００からデバイス情報及びサービス情報を収集し、デバイスリスト１１ａとしてたとえばハードディスク１１に保存する。
【００３３】
ステップ０２０１：
クライアントＰＣ１００のユーティリティ０１１４、あるいはアプリケーション０１１５は、ＳＯＡＰプロセッサ０１０６に対してＰｒｏｂｅメッセージの送信を要求する。きっかけは例えば電源の投入などである。その要求に応じて、ＳＯＡＰプロセッサ０１０６はＰｒｏｂｅメッセージを生成し、プロトコルスタック０１０４を介してマルチキャストアドレス２３９．２５５．２５５．２５０に対してマルチキャスト送信する。送信されたＰｒｏｂｅメッセージに対するネットワーク対応デバイス２００からの応答であるＰｒｏｂｅ Ｍａｔｃｈメッセージの有無により、ネットワークデバイスの検索処理を実現している。
【００３４】
ステップ０２０２：
ネットワーク対応デバイス２００がＰｒｏｂｅメッセージを受信すると、受信したＰｒｏｂｅメッセージはＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック０１１８を介して、ＳＯＡＰプロセッサ０１２０に通知される。ＳＯＡＰプロセッサ０１２０は、Ｐｒｏｂｅメッセージの内容を解析し、その結果（メッセージの内容）をＷＳＤモジュール０１２１に通知する。ＷＳＤモジュール０１２１は、通知されたメッセージの内容が、このネットワーク対応デバイス２００が提供する機能と一致しているか否かを判断する。一致しないと判断した場合、その情報を無視する。したがって、この場合はネットワーク対応デバイス２００からＰｒｏｂｅ Ｍａｔｃｈレスポンスが発行されることは無い。一方、一致すると判断した場合、ＷＳＤモジュール０１２１は、ＳＯＡＰプロセッサ０１２０に対してＰｒｏｂｅ Ｍａｔｃｈメッセージ発行を要求する。ＳＯＡＰプロセッサ０１２０は、Ｐｒｏｂｅ Ｍａｔｃｈメッセージを生成し、プロトコルスタック０１１８を介してクライアントＰＣ１００に対してＰｒｏｂｅ Ｍａｔｃｈメッセージをユニキャスト送信する。
【００３５】
ステップ０２０３、０２０５：
クライアントＰＣ１００がＰｒｏｂｅ Ｍａｔｃｈメッセージを受信すると、メッセージはＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック０１０４を介してＳＯＡＰプロセッサ０１０６に通知される。ＳＯＡＰプロセッサ０１０６は、Ｐｒｏｂｅ Ｍａｔｃｈメッセージの内容を解析し、その結果をＷＳＤモジュール０１０８に通知する。ＷＳＤモジュール０１０８は、Ｐｒｏｂｅ Ｍａｔｃｈメッセージに記述されたアドレスを宛先とするＧｅｔＭｅｔａｄａｔａメッセージの発行をＳＯＡＰプロセッサ０１０６に対して要求する。ＧｅｔＭｅｔａｄａｔａメッセージは、Ｐｒｏｂｅ Ｍａｔｃｈメッセージを発行したネットワーク対応デバイス２００の属性情報を取得する要求である。ＳＯＡＰプロセッサ０１０６は、ＧｅｔＭｅｔａｄａｔａメッセージを生成し、プロトコルスタックを介してネットワーク対応デバイス２００に対してユニキャスト送信する。
【００３６】
なおステップ０２０５では、クライアントＰＣが、サービス情報を要求している。すなわち、ステップ０２０５と０２０３において異なる点は、デバイス情報を要求するか、サービス情報を要求するかであり、この相違を除いて、メッセージ交換の手順は同一である。
【００３７】
ステップ０２０４、０２０６：
ネットワーク対応デバイス２００がＧｅｔＭｅｔａｄａｔａメッセージを受信すると、そのメッセージはＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック０１１８を介してＳＯＡＰプロセッサ０１２０に通知される。ＳＯＡＰプロセッサ０１２０は、ＧｅｔＭｅｔａｄａｔａメッセージの内容を解析し、その結果をＷＳＤモジュール０１２１に通知する。ＷＳＤモジュール０１２１においては、指定された属性情報を、ＧｅｔＭｅｔａｄａｔａメッセージ送信元のクライアントに対して返信するために、ＳＯＡＰプロセッサ０１２０に対してＧｅｔＭｅｔａｄａｔａＲｅｓｏｐｎｓｅメッセージの発行を要求する。ＳＯＡＰプロセッサ０１２０は、ＧｅｔＭｅｔａｄａｔａＲｅｓｐｏｎｓｅメッセージを生成し、プロトコルスタックを介してクライアントに対してユニキャスト送信する。ＧｅｔＭｅｔａｄａｔａＲｅｓｐｏｎｓｅメッセージとは、デバイス２００が送信するデバイス情報およびサービス情報の総称である。
【００３８】
なお、ステップ０２０４とステップ０２０６において異なる点は、デバイス２００が、デバイス情報を送信するかサービス情報を送信かであり、それ以外のメッセージ処理の手順は同一である。
【００３９】
ステップ０２０７：
クライアントＰＣ１００がＧｅｔＭｅｔａｄａｔａＲｅｓｐｏｎｓｅを受信すると、受信したＧｅｔＭｅｔａｄａｔａＲｅｓｐｏｎｓｅメッセージはＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック０１０４を介して、ＳＯＡＰプロセッサ０１０６に通知される。ＧｅｔＭｅｔａｄａｔａＲｅｓｐｏｎｓｅメッセージに記述されたデバイス属性情報は、クライアントＰＣ１００のＳＯＡＰプロセッサ０１０６を介してＷＳＤモジュール０１０８に通知される。
【００４０】
ＷＳＤモジュール０１０８は、プラグアンドプレイコントローラ０１１１を起動し、デバイス属性情報をプラグアンドプレイコントローラ０１１１に対し通知する。通知をうけたプラグアンドプレイコントローラ０１１１はメモリコントローラを介してデバイス属性情報に一致するドライバプログラムを記憶装置より検索し、該当するドライバのインストールを実行する。インストールは、ウィンドウズ（登録商標）ＯＳであれば、インストールする場所等を記述したインストールファイルを用意しておくことで、標準のインストーラで行える。あるいは、ドライバをインストーラと組にして提供しても良い。なお、デバイスドライバがネットワークを介してクライアントＰＣ１００と接続されたサーバにより提供されている場合には、ドライバプログラムはサーバ上で検索される。
【００４１】
＜デバイスの参加通知手順＞
さらに図２（Ｂ）を参照して、ネットワーク対応デバイス２００が、新規に導入されネットワーク通信を開始する、あるいは、電源オフの状態から電源オンされネットワーク通信を再開する場合の制御の流れをフロー図で説明する。
【００４２】
ステップ０２０８：
ネットワーク対応デバイス２００がネットワーク上で通信を開始、あるいは、再開する際、ＷＳＤモジュール０１２１は、ＳＯＡＰプロセッサ０１２０に対してＨｅｌｌｏメッセージの送信を要求する。きっかけは、たとえば電源の投入などである。ＳＯＡＰプロセッサ０１２０はＨｅｌｌｏメッセージを生成し、プロトコルスタックを介してマルチキャストアドレス２３９．２５５．２５５．２５０に対してマルチキャスト送信する。
【００４３】
ステップ０２０９：
クライアントＰＣ１００がＨｅｌｌｏメッセージを受信すると、ＨｅｌｌｏメッセージはＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック０１０４を介して、ＳＯＡＰプロセッサ０１０６に通知される。ＳＯＡＰプロセッサ０１０６は、Ｈｅｌｌｏメッセージの内容を解析し、その結果（メッセージの内容）をＷＳＤモジュール０１０８に通知する。ＷＳＤモジュール０１０８は、Ｈｅｌｌｏメッセージに記述されたアドレスに対し、該メッセージを発行したネットワークデバイスの属性情報を取得するために、ＳＯＡＰプロセッサ０１０６に対してＧｅｔＭｅｔａｄａｔａメッセージ発行を要求する。ＳＯＡＰプロセッサ０１０６はＧｅｔＭｅｔａｄａｔａメッセージを生成し、ＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック０１０４を介してネットワーク対応デバイス２００に対してユニキャスト送信する。このあとのフローは、図２（Ａ）のデバイス探索のステップ０２０４以下と同様であるため、説明は省略する。
【００４４】
なお、図２の手順は、クライアントＰＣ１００を図５に示す探索プロキシサーバ３００に置換した場合に、探索プロキシサーバ３００とデバイス２００との間においても行われる。したがって、探索プロキシサーバ３００が存在するネットワークでは、探索プロキシサーバ３００がネットワークデバイスのデバイス情報及びサービス情報を収集し、デバイスリスト１１ａとして保存し管理する。またプロキシサーバ３００はその他のメッセージをフック（すなわち横取り）して宛先のデバイスやサービス、送信元のクライアントに応じてメッセージをカウントする。そのカウンタに基づいて共有度順位表が作成され保存される。
【００４５】
＜Ｍｅｔａｄａｔａの形式＞
図３を参照して、図２（Ａ），図２（Ｂ）においてデバイスからクライアントＰＣ（クライアント端末ともいう）１００へと送信されるメタデータ（Ｍｅｔａｄａｔａ）の形式を説明する。メタデータはＸＭＬで記述されたデータとする。第１のメタデータはデバイス情報０３０１である。デバイス情報０３０１には、デバイスのモデル名０３０１ａやベンダ名などのデバイス情報が記載されている。そのなかにサービス情報へのリンク０３０１ｂが記載されている。
【００４６】
第２のメタデータはサービス情報０３０２である。図３の例では、サービス情報０３０２はＰＤＬ＿Ａのメタデータである。すなわち、サービス情報０３０２には、"ＭＦＰ２００．ＰＤＬ＿Ａ（０３０２ａ）"と記述されている。この記述は、ＭＦＰ２００というデバイスでは、ＰＤＬ＿Ａというサービスが提供されることを示す。つまり、ＭＦＰ２００は、ＰＤＬ＿Ａ（ページ記述言語Ａ）を解釈可能であることが記されている。このようにサービス情報内には、デバイス情報に含まれるデバイスＩＤとサービスＩＤとが格納されている。デバイスＩＤはプラグアンドプレイに利用される。ＰＤＬ＿Ｂのサービス情報３０３、ＰＤＬ＿Ｃのサービス情報０３０４も同様である。
【００４７】
図３の例では、プリントサービスであるＰＤＬ＿Ａ〜ＰＤＬ＿Ｃのメタデータ０３０２〜０３０４へのリンクがデバイス情報０３０１に含まれている。そこで、たとえば図２（Ａ）のステップ０２０５や図２（Ｂ）のステップ０２１１では、デバイス情報から得られたアドレス（リンク先）を指定して、サービス情報を要求する。
【００４８】
＜Ｐｒｏｂｅ Ｍａｔｃｈメッセージの内容＞
図４を参照してＰｒｏｂｅ Ｍａｔｃｈメッセージ０４０１の内容を説明する。プローブマッチ０４０１は、終端のアドレスであるエンドポイントＵＲＩ４０１ａ、サービスタイプ４０１ｂやネットワークスコープ４０１ｃに関する情報、コミュニケーションに使用するＵＲＩ４０１ｄ、メタデータのバージョン情報４０１ｅが含まれている。このバージョン情報４０１ｅは内容更新にあわせインクリメントされる。メッセージ０４０２はＰｒｏｂｅ Ｍａｔｃｈメッセージの一例である。Ｐｒｏｂｅ ＭａｔｃｈメッセージはＸＭＬで記述され、Ｐｒｏｂｅ Ｍａｔｃｈメッセージであることを示すタグ０４０２ａ、終端アドレス０４０２ｂ、デバイスタイプ０４０２ｃなどを含む。デバイスタイプは、たとえばプリンタなど、デバイスの種類を示す。
【００４９】
＜探索プロキシサーバ３００の接続＞
図２では、クライアントＰＣ１００とデバイス２００の接続フローを示した。この図２の構成に加えて探索プロキシサーバ３００を設置した場合の接続フローを図５を用いて説明する。
【００５０】
前述の通り、探索プロキシサーバ３００が接続されたネットワークに参加するデバイス２００は、探索プロキシサーバ３００からデバイス要求メッセージ等を受信する。そのメッセージには、送信元がクライアントではなく、探索プロキシサーバ３００であることを示す情報が含まれる。この情報は、探索プロキシサーバ３００に対してあらかじめ与えられたＩＤ等の識別情報である。探索プロキシサーバ３００から、探索プロキシサーバ３００の識別情報を含むデバイス情報要求等のメッセージを受けたネットワークデバイス２００は、参加したネットワークに探索プロキシサーバ３００が存在すると判断できる。探索プロキシサーバ３００がネットワークに存在する場合、デバイスはそのことをメモリ等に記憶しておく。さて、探索プロキシサーバ３００が存在することを記憶したデバイス２００は、クライアントＰＣ１００からデバイス探索のためのＰｒｏｂｅメッセージを受信してもそれに対する応答処理を行わない。そして、デバイス探索手順は、以下の通り探索プロキシサーバ３００とクライアントＰＣ１００との間で進行する。また、デバイス２００は、デバイス２００のデバイス情報およびサービス情報をプロキシサーバ３００に対して送信する。
【００５１】
ステップ０５０１：
クライアントＰＣ１００よりデバイス探索要求メッセージ（Ｐｒｏｂｅ）０５０１が送信される。
【００５２】
ステップ０５０２：
プロキシサーバ３００は、Ｈｅｌｌｏメッセージ０５０２を発信する。クライアントＰＣ１００はプロキシサーバ３００からのＨｅｌｌｏメッセージ０５０２を受信する。デバイス２００はデバイス探索要求メッセージ０５０１に対しては応答しない。
【００５３】
ステップ０５０３〜５０６：
クライアントＰＣ１００は、探索プロキシサーバ３００から応答を受信して探索プロキシサーバ３００の存在を認識した場合、以降のサービス探索メッセージは探索プロキシサーバ３００へ発信する。
まず、クライアントＰＣ１００は、ＧｅｔＭｅｔａｄａｔａメッセージ０５０３を探索プロキシサーバ３００に対して送信する（ステップ０５０３）。このＧｅｔＭｅｔａｄａｔａメッセージには、例えば、「カラープリンタに関する情報」、「プロキシサーバ３００が保持している全デバイス情報」、「ネットワーク上のいずれか３つのプリンタ」など、所定の指定情報が含まれている。探索プロキシサーバ３００はＧｅｔＭｅｔａｄａｔａメッセージ０５０３を受信したら、ＧｅｔＭｅｔａｄａｔａＲｅｓｐｏｎｃｅメッセージ０５０４をクライアントに対して送信する（ステップ０５０４）。ＧｅｔＭｅｔａｄａｔａＲｅｓｐｏｎｃｅメッセージ０５０４には探索プロキシサーバ３００が保持している情報（たとえば共有度順位表）が含まれており、その情報もクライアントＰＣ１００へ送信される。このようにステップ０５０３、０５０４では、デバイス情報がクライアントに渡され、ステップ０５０５、０５０６ではサービス情報がクライアントに渡される。
【００５４】
以上のようにして、デバイスから直接クライアントに対してデバイス情報及びサービス情報は渡されず、探索プロキシサーバ３００にキャッシュされたそれらの情報がクライアントに対して与えられる。
【００５５】
ステップ０５０７：
クライアントＰＣ１００は、ステップ０５０４またはステップ０５０６にて受信した情報に基づいてデバイスドライバのインストール処理を行う。なお、詳細は図２（Ａ）のステップ２０７で説明したため省略する。
【００５６】
ステップ０５０８：
なお、他のメッセージには３者間でやり取りされるものがある。たとえば印刷要求メッセージはクライアントＰＣ１００からデバイス（プリンタ）２００に直接送信される。デバイス２００は印刷命令にしたがって印刷処理を実行する。また、途中でエラー等、処理を中断する事態が生ずれば、その旨のメッセージがデバイス２００からクライアントＰＣ１００に送信される。プロキシサーバ３００は、図６を参照して後で説明するように、クライアントからデバイスに対するメッセージをフックする。プロキシサーバ３００はフックしたメッセージを数える。ここで単に数えるのではなく、デバイスごとのクライアントの数、デバイス及びサービスごとのクライアントの数、スコープ毎のクライアント数等、メッセージの属性ごとにメッセージ数を数える。
【００５７】
以上、探索プロキシサーバ３００は、クライアントＰＣ１００によるサービス探索を容易にする。さらに、問い合わせ先が集約され、ネットワークトラフィックの低減や、デバイス側の処理の軽減が図られる。特にネットワークスコープ内に多数のサービスがある場合には、システムトラフィック低減に有効である。ここまで、クライアントとデバイスの基本接続、プロキシサーバ３００が加えられた場合の接続について説明した。また、このようにプロキシサーバ３００を用いることにより、クライアントＰＣ１００は、デバイス２００の電源が切れている状態であっても、デバイス２００の情報を受信することが可能である。
【００５８】
＜プロキシサーバ３００の制御の概要＞
次に図６を参照して、本実施形態におけるプロキシサーバ３００による制御の概要を説明する。プロキシサーバ３００は、クライアントＰＣ１００からのメッセージ（例えばデバイス情報要求）に対して、ネットワークにおける共有度の高い（利用頻度の高い）デバイスおよびサービスを応答する。この応答に基づいて、クライアントＰＣ１００側には、共有度の高いサービスを利用するためのドライバやアプリケーションがセットアップされる。その結果、クライアントは自動インストールを実行する場合であっても、利用頻度が高く、必要になると予想されるデバイスのデバイスドライバを導入することが可能となる。また、プロキシサーバ３００はデバイス２００とクライアントＰＣ１００の個体識別と記録、識別結果をもとにした経路制御をおこなう。メッセージ交換の手順は図５に示したとおりであり、図６は探索プロキシサーバ３００における処理も含めて説明する。
【００５９】
図６において、プロキシサーバ３００によるＭＦＰ２００を含めたデバイスの個体識別と記録について説明する。プロキシサーバ３００はデバイスＭＦＰ２００を対象として、(1)探索信号を送信する。この探索信号を受信したＭＦＰ２００は、(2)応答信号をプロキシサーバ３００に対して返信する（０６０１）。この０６０１の処理は、図２（Ａ）のステップ０２０１とステップ０２０２に相当する。探索と応答の代わりに、図２（Ｂ）のネットワーク参加通知０２０８であってもよい。
【００６０】
次に図６のプロキシサーバ３００は、デバイス情報および、そのサービス情報を取得するため、(3)情報取得要求をＭＦＰ２００に対して送信する。情報取得要求を受信したＭＦＰ２００は、デバイス情報およびサービス情報を(5)送付する（０６０２）。この０６０２の処理は、図２（Ａ）のステップ０２０３〜ステップ０２０６あるいは図２（Ｂ）のステップ０２０９〜０２１２に相当する。また、情報取得要求を受信したＭＦＰ２００は、(4)デバイスＩＤを特定する（０６０３）。この一連の処理０６０１から０６０３が実行されることでプロキシサーバ３００は図３のメタデータ０３０１（デバイス情報）およびメタデータ０３０２（サービス情報）を参照し、デバイスの個体識別をおこなう。最終的には、プロキシサーバ３００は、収集したデバイスＩＤおよび各デバイスＩＤに対応するデバイスの種類情報（デバイス情報）や提供サービス（サービス情報）をデバイスリストに保存する。デバイスリスト情報を図２０に示す。図２０のデバイスリスト情報には、各デバイスのＩＤ、アドレス情報、デバイスの種類、サービスとサービスのＵＲＩが保持されている。デバイスの個体識別とは、デバイス情報及びサービス情報の保存（登録）である。なお、登録の対象を図３に示したメタデータ全体としておけば、登録されたメタデータを、デバイス情報あるいはサービス情報を要求するクライアントにそのまま渡すことができる。その結果、クライアントは、デバイスから直接受信したメタデータと同様に処理できる。ただし、後述の通り本実施形態では、メタデータのデバイスのアドレス（ＵＲＩ）は、プロキシサーバ３００によるフックのために変更されている。
【００６１】
次にプロキシサーバ３００によるクライアントＰＣ１００の個体識別と記録について説明する。プロキシサーバ３００はクライアントＰＣ１００に対して（７）探索要求を送信すると、クライアントＰＣ１００からの（８）応答信号を受信する（０６０５）。そして、プロキシサーバ３００は、クライアントＰＣ１００に対して（９）情報取得要求を送信する。プロキシサーバ３００からの情報取得要求に応じて、クライアントＰＣ１００は、クライアントＰＣ１００に関する情報を(10)送付する（０６０６）。この一連の処理０６０５、０６０６が実行されることでプロキシサーバ３００はクライアントＰＣ１００の個体識別をおこなう。最終的には、プロキシサーバ３００は、収集したクライアントのＩＤや各クライアントのアドレス等のクライアント情報をデータベース（クライアントリストという）に登録する。なお、クライアントリストの一例を図１９に示す。プロキシサーバ３００は、図１９のように各クライアントのクライアントＩＤ、アドレス情報を記憶している。
【００６２】
さらに共有度の判定のために、プロキシサーバ３００は、図５のステップ０５０８で送受信される他メッセージに含まれる情報を収集する。その目的で、プロキシサーバ３００はネットワークアドレス変換をおこなう。このネットワークアドレス変換処理について説明する。通常は、GetMetaDataで機器の情報やサービスのアドレス（ＵＲＩ）がクライアントに開示される。以降、クライアントはそのアドレス（ＵＲＩ）に対してアクション（例えば印刷要求）を行う。しかし、後述する図９の共有度順位表０９０１を作成するためには、どのクライアントがどのデバイス（例えばプリンタ）を使って印刷処理をしているか等の情報をプロキシサーバ３００が収集する必要がある。そのため、プロキシサーバ３００は、クライアントからデバイスに対する要求メッセージを一旦引き込むためにアドレス（ＵＲＩ）の書き換えを行う。アドレス変換は、一連の処理０６０１〜０６０６のフローにおいて、プロキシサーバ３００からクライアントＰＣ１００に送信するサービス情報等のメタデータに含まれるＵＲＩを差し替えることで行われる。アドレス変換処理はプロキシサーバ３００により図６の処理０６０４で行われる。たとえば、プロキシサーバ３００は、クライアントＰＣ１００からのデバイス情報要求（図５のステップ０５０３）に応じて、デバイスリストに登録されたデバイス情報を応答する。その際に、デバイス情報に含まれるデバイスのＵＲＩの上位に、プロキシサーバ３００のＵＲＩを付加する。また、サービス情報についても同様に、デバイスのＵＲＩの上位にプロキシサーバ３００のＵＲＩを付加する。図４の例では、サービス情報のＵＲＩ０４０２ｄの上位にプロキシサーバ３００のＵＲＩが付加される。なお、これらプロキシサーバ３００のＵＲＩの付加は、クライアントがデバイスのアドレスとして用いるＵＲＩに対してのみ行われても良い。
【００６３】
アドレス変換されたメタデータを受信したクライアントは、印刷要求メッセージ等、図５のステップ０５０８におけるメッセージ送信のために、変換されたアドレス（プロキシサーバ３００のＵＲＩ）を使用する。そのため、クライアントＰＣ１００からのメッセージはプロキシサーバ３００に到達する。プロキシサーバ３００は、クライアントからメッセージ（メタデータ）に含まれたＵＲＩのうち、その上位にあるプロキシサーバ３００のＵＲＩを取り除いてＭＦＰ２００に転送する。この処理により、クライアントＰＣ１００からデバイス２００に宛てられたメッセージはすべてプロキシサーバ３００を経由することになる。プロキシサーバ３００は、こうしてクライアントからデバイスに対するメッセージをフックする。なおアドレス変換は、上述したアドレスの追加および削除による方法以外に、対応表による変換、他の装置が管理しているアドレス変換機能を利用することでも実現できる。つまり、プロキシサーバ３００は、端末から周辺機器へのメッセージを横取りする。この横取りしたメッセージ情報を用いてメッセージ数を数え、共有度を計数する。その計数結果を示す共有度情報は図９に後述する。
【００６４】
こうしてプロキシサーバ３００は、基本的に０６０７の経路をとおるメッセージとメタデータ（図５のメッセージ０５０８）を参照することができる。なお、サーバ４００がネットワークに接続されている場合、プロキシサーバ３００は、サーバ４００により提供されるディレクトリサービス５００や管理ユーティリティ６００と必要な情報を送受する。プローブマッチのメタデータ内にもスコープ情報があるが、プロキシサーバ３００がディレクトリ情報を必要とする場合はディレクトリサービス５００と、図６のステップ０６１０で送受する。管理ユーティリティ６００とプロキシサーバ３００が情報共有する場合には、管理ユーティリティ６００とステップ０６１１で送受をおこなう。
【００６５】
＜プロキシサーバ３００の内部構成＞
システムの主構成と制御の説明に続き、図７を用いてプロキシサーバ３００の内部構成を説明する。プロキシサーバ３００は、通信部０７０１、フロー部０７０２、管理部０７０３の３層構造を有する。通信部０７０１には、クライアント、サーバ、デバイスそれぞれへ接続するためのクライアント接続部０７０４、サーバ接続部０７０５、デバイス接続部０７０６が備えられている。
【００６６】
フロー部０７０２は、フロー制御を処理するためアドレス変換部０７０７や入出力部０７０８を備え、図６で説明したアドレス変換や入出力制御をおこなう。管理部０７０３は、データを記録するデータ格納部０７１０、設定操作部０７１１、通信と制御の具体的な処理を決定する判断部０７０９等が備えられている。データ格納部０７１０には、前述のデバイスやクライアントの識別結果（デバイスリスト１１ａおよびクライアントリストを含む）７１０ａなどが記録されている。このほか、アドレス変換表７１０ｂ、後述するプロキシ操作設定７１０ｃ、実績テーブル７１０ｄ、共有度順位表０９０１（図７には示さず）などが記録されている。設定操作部０７１１は、プロキシサーバ３００の動作を変更するためのＵＩ（ユーザインターフェース）や、操作結果をデータ格納部０７１０に反映するための処理を提供する。判断部０７０９は、プロキシサーバ３００設定や、入力、実績を含むデータ格納部０７１０を基準に、デバイスの共有度等に関する判断をおこなう。判断結果は出力としてフロー部０７０２、通信部０７０１を通じ、プロキシサーバ３００の外部にも送信される。
【００６７】
また、通信部０７０１、フロー部０７０２、管理部０７０３のそれぞれは、拡張部分０７１２〜０７１４をもつ。この拡張部分０７１２〜０７１４により、例えば図５の他のメッセージ０５０８に対応する処理（拡張処理）を行うと、基本処理と拡張処理の独立性が向上し、拡張処理内容の変更や付加、削除が容易となる。この拡張部分０７１２〜０７１４へ、処理の内部集約、内部置換（差し替え）、外部接続といった手段が採用できることが理由である。
【００６８】
以上、プロキシサーバ３００は図７に記載した内部構成を持つため、通信系と管理系の分離配置が可能となっている。プロキシサーバ３００と前述の管理ユーティリティ６００との連携動作時は、プロキシサーバ３００をフロー部０７０２と管理部０７０３間のＩ／Ｆで分離し、管理部０７０３の機能を管理ユーティリティ６００
に集約する構成も実施できる。
【００６９】
続いて、図２３を用いてプロキシサーバ３００の本願における処理の概要を説明する。なお、図２３に記載のフローチャートにおける各ステップの処理はプロキシサーバ３００のＣＰＵによって処理される。また、プロキシサーバ３００は、周辺機器（単にデバイスとも呼ぶ。）および端末（クライアントとも呼ぶ。）と通信可能な情報処理装置ある。
【００７０】
プロキシサーバ３００は、ネットワークに対して図６の処理０６０１および処理０６０５にて記述したデバイス探索要求を発信し、デバイスまたはクライアントからの応答を待機する。プロキシサーバ３００は、クライアントおよびデバイスからの応答を受信すると、応答情報に基づいてデバイス情報を要求する。プロキシサーバ３００は、応答されたデバイス情報に基づいてデバイスリストおよびクライアントリストを生成する（Ｓ２３０１）。プロキシサーバ３００は、こうしてＳ２３０１により周辺機器から周辺機器に関する情報を受信して保存する。
【００７１】
プロキシサーバ３００は、クライアントとデバイスの通信情報、または、クライアントとプロキシサーバ３００の通信情報に基づいて共有度順位情報を生成する（Ｓ２３０２）。
【００７２】
Ｓ２３０２の処理の一例を簡単に説明すると、プロキシサーバ３００は、クライアントおよびデバイス間において送受信されているメッセージ情報をデバイス毎に数える。そして、メッセージ情報を数えることにより得られる周辺機器毎の共有度を計数して、共有度情報を生成する。または、クライアントからプロキシサーバ３００に対して送信される情報を用いて計数することもある。なお、Ｓ２３０２の処理は、ネットワークが通常の稼働状態にある間にプロキシサーバ３００により実行される。Ｓ２３０２の詳細は、図１７および図８を用いて後述する。
【００７３】
プロキシサーバ３００は、クライアントからデバイス情報要求を受信したか否かを判定する（Ｓ２３０３）。詳細には、プロキシサーバ３００が、クライアントから、プロキシサーバ３００のメモリにて保持されている周辺機器に関する情報を要求する要求メッセージを受信したか否かを判定する。プロキシサーバ３００は、クライアントからプロキシサーバ３００のメモリにて保持されている周辺機器に関する情報を要求する要求メッセージ（デバイス情報要求）を受信する。そのメッセージを受信したプロキシサーバ３００は、Ｓ２３０２により計数された周辺機器毎の共有度に従って選択された周辺機器に関する情報を、クライアントに送信する（Ｓ２３０４）。つまり、プロキシサーバ３００は、作成された共有度順位情報を用いて送信すべき周辺機器に関する情報を選択する。
【００７４】
プロキシサーバ３００には、クライアントに送信すべきデバイスを選択するための条件が設定されている。例えば、共有度情報の上位３つのデバイスに関する情報を送信するなどが挙げられる。このプロキシサーバ３００に設定されている条件に基づいて送信すべきデバイス情報を決定する。
【００７５】
なお、クライアントからデバイス要求を受信した場合、プロキシサーバ３００は、クライアントから受信したデバイス情報要求に含まれる情報が共有度情報を送信する条件に一致するか否かを判定してもよい。ここで、プロキシサーバ３００が共有度情報を送信すると判定する場合の条件について説明する。１つ目は、クライアントのデバイス情報要求に共有度情報を取得したいとの情報が含まれているか否かである。２つ目は、クライアントが、初めてデバイス情報要求を送信したか否かである。プロキシサーバ３００は、各クライアントからのデバイス情報要求を管理しているため、例えば、いつ、どのクライアントがどういった内容のデバイス情報要求を送信してきたかを管理している。つまり、プロキシサーバ３００が、Ｓ２３０３にて受信したデバイス情報要求の送信元のクライアント情報を管理していなければ、そのクライアントは初めてデバイス情報要求を送信したと判定できる。なお、共有度情報を送信する条件として２つの例を挙げたがこれに限定される必要はない。
【００７６】
図２３の処理により、たとえば、利用される可能性が高いデバイスのデバイスドライバあるいはそのデバイスに対応したアプリケーションプログラム等を、選択的にクライアントコンピュータがインストール可能な情報処理装置を提供できる。
【００７７】
＜プロキシサーバ３００による集計処理＞
プロキシサーバ３００、詳細にはプロキシサーバ３００のＣＰＵ１は、受信したメッセージに含まれる情報を集計する。集計は例えば以下の項目を対象として行われる。
（１）各デバイスにアクセスしたクライアント数。つまり、プロキシサーバ３００は、端末から周辺機器へのメッセージを受信し、受信したメッセージの宛先および送信元情報に基づいて、周辺機器毎に、送信元となった端末数を数える。端末数は、該当するメッセージの数を数えることでカウントされる。そしてプロキシサーバ３００は、周辺機器に対して、数えられた端末数を関連づけ、端末数をキーとして整列した順位を共有度の順位とする共有度順位情報を作成する。
（２）サービス毎のクライアント別のメッセージ数。すなわち、宛先のサービスＩＤ（あるいはサービスのＵＲＩ）と送信元のクライアントＩＤ（あるいはアドレス）とを一組の径路情報と考えた場合における、各径路のメッセージ数である。つまり、プロキシサーバ３００は、受信したメッセージの宛先情報に基づいて、周辺機器毎にメッセージ数を数える。そして、プロキシサーバ３００は、数えられた周辺機器毎のメッセージ数を周辺機器毎に関連づけ、メッセージ数をキーとして整列した順位を共有度の順位とする。
（３）デバイス毎の受信データ量および送信データ量。データ量は、本例ではメッセージの数である。したがって、データ量は、（２）のサービス毎のクライアント別メッセージ数を、着目デバイスについて加算しても得られる。
（４）スコープ毎のメッセージ数。つまりプロキシサーバ３００は、受信したメッセージの宛先および送信元情報に基づいて、周辺機器と同一のネットワーク上の範囲に属する送信元の端末の数を数える。スコープはメタデータ中に記述されており、ネットワークにおける範囲を示す。たとえばクライアントＩＤを列挙したり、あるいは、階層的に記述されたアドレスの一部（特に上位）を記述するなどしてスコープを表すことができる。本例では、デバイスの属するスコープに隣接するスコープのクライアントからも、そのデバイスにアクセスすることができるが、デバイスと同一のスコープに属するクライアントからアクセスされた場合、ローカルユーザ数の項目９１４をカウントする。デバイスと同一のスコープに属するクライアントをローカルクライアントと呼ぶ。プロキシサーバ３００は、同一のネットワーク上の範囲内に属する送信元の端末数を周辺機器毎に関連づけ、該端末数をキーとして整列した順位を共有度の順位とする。なお、以上の項目以外にも必要に応じて種々の情報を集計することができる。
【００７８】
図１７に、図２３のステップＳ２３０２においてプロキシサーバ３００が実行する処理の一例を示す。図１７は、プロキシサーバ３００が、クライアントおよびデバイス間において送受信されているメッセージ情報をデバイス毎に数える手順である。図１７においてプロキシサーバ３００は、フックしたメッセージを数える。図１７の例では、カウントしているのは（１）のデバイス毎のクライアント数と、（２）のデバイス毎のサービスおよびクライアント別メッセージ数と、（４）のスコープ毎のクライアント別メッセージ数である。（３）のデバイス毎のメッセージ数は、デバイスの共有度表を作成する際に、（１）のデバイス毎のクライアント別メッセージ数から算出される。なお、図１７の各ステップの処理はプロキシサーバ３００が備えるＣＰＵによって実行される。
【００７９】
図１７では、プロキシサーバ３００は、フックしたメッセージからデバイスＩＤおよびサービスのＵＲＩおよびクライアントのＩＤを読む（Ｓ１７０１）。次にプロキシサーバ３００は、読み取ったデバイスＩＤおよびサービスＵＲＩおよびクライアントＩＤの組に対応するカウンタ（サービスごとのクライアント別カウンタという。）が登録されているか判定する（Ｓ１７０２）。プロキシサーバ３００により登録済みか否かが判定されるカウンタはプロキシサーバ３００のＲＡＭに登録されているため、プロキシサーバ３００がＲＡＭを参照することによりＳ１７０２の処理は可能となる。
【００８０】
プロキシサーバ３００は、Ｓ１７０２の判定の結果、カウンタが登録されていればそのデバイスＩＤおよびサービスＵＲＩおよびクライアントＩＤの組に対応するメッセージカウンタに１を加算する（Ｓ１７０４）。一方、登録されていないと判定された場合、プロキシサーバ３００は、読み取ったデバイスＩＤおよびサービスＵＲＩおよびクライアントＩＤの組に対応するメッセージカウンタを新たに設け、そのメッセージカウンタに１をセットする（Ｓ１７０３）。また、プロキシサーバ３００は、デバイスごとのクライアント数のカウンタにも、初めてのクライアントであれば１を加算する（Ｓ１７０５）。そして、そのクライアントのＩＤを、重複の排除のために記録しておく。
【００８１】
次にプロキシサーバ３００は、メッセージからスコープを読み取る（Ｓ１７０６）。読み取ったスコープに対応するメッセージカウンタが登録されているか判定し（Ｓ１７０７）、登録されていればそのメッセージカウンタに１を加算する（Ｓ１７０９）。一方、登録されていなければ、プロキシサーバ３００は、読み取ったスコープに対応するメッセージカウンタを新たに設け、そのメッセージカウンタに１をセットする（Ｓ１７０８）。
【００８２】
＜共有プリンタの判断＞
プロキシサーバ３００の管理部０７０３にある判断部０７０９により実施される、プリンタ等のネットワークデバイスの共有度の判定について、図８を参照して説明する。図８はデバイスの評価手順を示す概略図であり、具体的にはデバイスの共有度順位表の作成手順を示す。つまり、図８は、図２３のステップＳ２３０２において、プロキシサーバ３００がクライアントＰＣ１００からデバイス情報要求を受信した際に、その応答送信前に実行される。また図９（Ａ）に作成される順位表の例を示す。処理手順中、ステップＳ０８０１、ステップＳ０８０２が主たる判断であり、これにステップＳ０８０３が加えられている。ステップＳ０８０４はオプション、ステップＳ０８０５は補助的な条件である。
【００８３】
まずプロキシサーバ３００の判断部は、デバイスリストに登録された各デバイスについてステップＳ０８０１〜Ｓ０８０５の評価を行い、最後にステップＳ０８０６でデバイス共有度順位表をソートする。これが作成手段に相当する。
【００８４】
ステップＳ０８０１では第１の判定基準にしたがって評価を行う。第１の判定基準は、ネットワークで公開されているか否かである。判断部は、デバイス共有度順位表のうち着目デバイス（たとえばＭＦＰ２００）に対してＯＳの共有設定がなされているかを判定する。この判定基準は、ステップ０６１０に示したとおり、ディレクトリサービス０５００より得た共有情報に基づく情報である。ディレクトリサービス０５００がたとえばアクティブディレクトリであるなら、そこから、ＡＤＳＩ（Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙ Ｓｅｒｖｉｃｅ Ｉｎｔｅｒｆａｃｅ）経由でデバイスが共有設定されているか否かを示す共有情報を取得できる。共有設定されていると判断されれば、プロキシサーバ３００は、共有設定されているデバイスのデバイスＩＤ（図９（Ａ）のデバイスＩＤ０９１１）を、デバイス共有度順位表に登録する。したがって本実施形態では共有設定されていないデバイスは、共有度順位表に登録されず、クライアントによるデバイス探索では見つけられない。これは、一般に共有設定されていないデバイスを、不特定の利用者により利用させるのは適当ではないからである。
【００８５】
なおアクティブディレクトリより、ネットワーク環境のクライアント数、デバイス数など、ネットワークの規模についての情報も得られる。ステップ０８０１では、ディレクトリサービスからこれらの情報をまず取得する。ネットワークの規模を示す情報は、ネットワークの大小の判断の基準となる。
【００８６】
ステップＳ０８０２では、プロキシサーバ３００が、第２の判定基準にしたがって評価を行う。第２の判定基準は、サービスが多数のクライアントから接続（アクセス）されているか否かである。プロキシサーバ３００は、着目デバイスにより提供されるサービス（着目サービス）に対して、クライアントからの接続数"Ｎ"が多い状態を共有度が高いと判断する。着目デバイス（たとえばＭＦＰ２００）とクライアントＰＣ１００は処理０６０１〜０６０６を通して個体識別されている。この過程で参照されるメタデータ０４０１からサービスおよびスコープ情報が得られる。またネットワーク規模（構成）の情報は、ディレクトリサーバからステップ０６１０において入手できる。着目デバイス（たとえばＭＦＰ２００）の着目サービスへの接続は、サービスのアドレス（ＵＲＩ）で特定される。したがって、プロキシサーバ３００は、着目サービスのＵＲＩを指定した接続要求（たとえば印刷要求）メッセージの数を、識別済みである各クライアントの重複を排除してカウントすることで、クライアント数"Ｎ"（すなわち接続数）を求めることができる。重複を排除するためには、受信したメッセージに記録された送信元のクライアントの識別情報（ＩＤやアドレス）が記憶されているか否かを判断し、記憶されていなければ記憶する。そして、同時にクライアント数Ｎに１を加算する。その数Ｎが、サービスが多数のクライアントから接続されていることの程度を示す値となるので、デバイス毎のＮを図９（Ａ）の接続先数０９１２として順位表に登録する。
【００８７】
なお、クライアント数そのものではなく、ネットワークに接続されたクライアント数のうちの割合を共有度表に登録しても良い。すなわち、ネットワークに接続されたクライアント数を分母とし、着目デバイスの持つ特定のサービスを利用したクライアントの数を分子とした割合を求め、その値に基づいて共有度を計算しても良い。
【００８８】
ステップＳ０８０３では、プロキシサーバ３００が、第３の判定基準にしたがって評価を行う。第３の判定基準は、サービスの利用総量が多いか否かである。すなわちネットワークで公開されたデバイスであり、かつ、多数のクライアントから利用されている上で、着目デバイスの提供するサービスに対するクライアントからの総アクセス数"ｎ"が多いデバイスほど、共有度の高いデバイスと判断される。着目デバイスの提供サービスに対する総アクセス数は、プロキシサーバ３００がフックしたメッセージの数を、デバイスごとにカウントすることで得られる。これは図１７のステップＳ１７０５でカウントされる値を、着目デバイスについて加算した値に相当する。ステップＳ０８０３では、この値をデバイスＩＤに対応付けてデータ量０９１３として共有度順位表０９０１に登録する。
【００８９】
ステップＳ０８０４では、プロキシサーバ３００が、第４の判定基準にしたがって評価を行う。第４の判定基準（Ｓ０８０４）は、クライアントが指定したデバイスとメッセージ送信元のクライアントが同一スコープ内にあるか否かを判定する処理である。ここで、同一スコープ内のクライアントから宛先指定されたデバイスについて、カウント処理を実行する。ここで、カウント数が多いデバイスは、同一スコープ内のユーザの利用頻度が高いデバイスである。ここで、例えば新規に同一スコープ内に接続したクライアントに対しては、カウント値の高いデバイスを推奨するようにしても構わない。このカウンタ値は、デバイスの共有度順位表９０１のローカルユーザ数０９１４として登録される。
【００９０】
ステップＳ０８０５では、プロキシサーバ３００が、第５の判定基準にしたがって評価を行う。第５の判定基準は、デバイスの能力が高く、搭載しているサービス数が多いというものである。デバイスが高機能であるかは、着目デバイス（たとえばＭＦＰ２００）のメタデータ、特にデバイス情報に基づいて判断される。このデバイス能力レベルのデータは、最低レベルをあらかじめカットするため、他条件が同点のケースでの最終順位決めといった補助的な目的のために利用される。能力値は例えば、提供するサービスの数であったり、あるいは、着目デバイスがプリンタであれば単位時間あたりの印刷ページ数である。例えば、プロキシサーバ３００に１０ｐｐｍ（１分あたりの印刷ページ数）以下のプリンタはカウントしないと設定されていた場合、１０ｐｐｍ以上のプリンタについては能力値０９１５の項目を更新しない。一方、１０ｐｐｍ以上のプリンタについては能力値０９１５の項目の値を更新する処理が行われる。この値が共有度順位表０９０１の能力値０９１５として登録される。
【００９１】
以上の手順を各デバイスについて実行することで、図９に例示するデバイス共有度順位表が完成する。プロキシサーバ３００には、担当するスコープが割り当てられており、プロキシサーバ３００は、担当スコープ内の各デバイスについて、上述の図８の手順を実行する。この図９の共有度順位表を、各項目毎に優先順位を付してソートすることで、デバイスＩＤがその共有度順にソートされる。本例では、図９（Ａ）の項目０９１２−０９１５をキーとし、その優先順位をソートする。優先順位を付してソートするとは、第１のキーでソートした後、同順にある項目を第２のキーでソートする、というように、優先順位の高いキーで先後が付かない場合に、優先順位の低いキーで順位を付けることをいう。
【００９２】
なお、共有度順位はその他の項目を用いて作成することもできる。図９（Ｂ）は、その一例を示す。図９（Ｂ）の例では、デバイスの共有度順位表０９０１に、接続先数、探索数、情報請求数（デバイス情報要求メッセージの数）、データ量／月（１突き当たりのメッセージ数）、初回接続日時、最終接続日時、サービス数が、この順で登録される。接続先数は、接続先のクライアント数である。そして各項目をキーとして、この優先順位でソートすることで、デバイスＩＤが共有度順位に応じてソートされる。図８のように優先すべき項目情報に基づいて共有度順位を特定するので、クライアントは、より利便性の高いデバイスを優先的にインストール（導入）することが可能となる。
【００９３】
それでは次に、順位表のどこまでのデバイス、サービスをクライアントＰＣ１００に通知するかについて説明する。
【００９４】
＜クライアントへの列挙順序＞
図１０はクライアントＰＣ１００が表示するＵＩの一例である。プロキシサーバ３００は、クライアントから受信したデバイス情報要求に対して、ソートしたデバイス共有度順位表のうち、上位の一定数のデバイスについて、それらが共有度順位が高いことを示す情報と共に、デバイス情報をクライアントに返す。なおこの上位の一定数は固定されているとは限らない。デバイス情報応答を受信したクライアントでは、たとえばドライバインストーラが図５のステップＳ０５０７において図１０のユーザインターフェースを表示する。またはアプリケーションが表示してもよい。
【００９５】
さて、ドライバインストーラは、図５のステップ０５０７において、図１０に示すプリンタのセットアップ開始ダイアログ１００１を表示する。その中の機種リスト１００２は次の順序で列挙されている。すなわち、図８の手順で作成されたデバイス共有度順位表を、クライアント数、サービスの利用量、ローカルユーザ数、能力値をキーとして、この優先順序でソートした順序で、デバイスＩＤが列挙される。こうして共有度の高い順にデバイスが列挙される。さらに、新しいデバイスや利用実績のあるデバイスについてもデバイスリストの末尾に列挙する。もちろんこれらデバイスも共有度に応じた順序で列挙しても良い。
【００９６】
以上をまとめると、クライアントＰＣ１００は、プロキシサーバ３００から受信したデバイス情報要求に基づき、以下の順序でデバイスのリストを表示する。
（ａ）共有度の高い順。
（ｂ）新しいデバイスや利用実績があるデバイス。これらデバイスは（ａ）の後クライアントへ返答される。
（ｃ）共有度がある一定の順位よりも低いデバイスはリストに表示されない。
【００９７】
共有度がある一定の順位よりも低いデバイスとは、たとえばプロキシサーバ３００が判定する。プロキシサーバ３００は、デバイス共有度順位表に基づいて、その下位の一定数のデバイスを共有度が一定の順位よりも低いデバイスであると判定し、これらデバイスのデバイス情報をクライアントに返信しない。
【００９８】
そして、クライアントＰＣ１００では、上記（ａ）（ｂ）の規則にしたがった順序でリストされたデバイスのうち、上位所定数のデバイスについては、あらかじめドライバをインストールする対象として選択しておく。具体的には、デバイス毎にドライバをインストールするか否かを示す選択フラグをＲＡＭ等に設け、該当するデバイスに関してはそのフラグをセットしておく。ユーザインターフェースであるダイアログ１００１の上では、チェックボックス１００３が選択された状態で表示される。図１０では上位４つのデバイスが、インストール対象として選択されている。ユーザがダイアログ１００１の「次へ」ボタンをおすと、ユーザインターフェースから、プラグアンドプレイコントローラ０１１１に、選択フラグがセットされたデバイスのデバイス情報が通知される。通知をうけたプラグアンドプレイコントローラ０１１１は、メモリコントローラを介してデバイス属性情報に一致するドライバを記憶装置上より検索し、該当するドライバのインストールを実行する。
【００９９】
図１１がプロキシサーバ３００による列挙制御のフロー図である。まずステップ１１０２でプロキシサーバ３００が、デバイス情報要求メッセージの発行元クライアントを特定する。すなわち、プロキシサーバ３００が、デバイス要求メッセージの送信元のアドレスあるいはクライアントＩＤを読み取る。ステップ１１０３でプロキシサーバ３００は、応答の設定（後述）を読み取る。またステップ１１０４では、プロキシサーバ３００が、たとえば共有度順位表のソートを前述のように行って、ステップ１１０５〜ステップ１１１０のデバイスの列挙順を確定する。
【０１００】
プロキシサーバ３００が、応答の設定に応じて実績データ（すなわち共有度順位表）より順序づけられた共有度の高いデバイスがあると判定した場合（ステップ１１０５−Ｙ）、ステップ１１０６にて共有度の高い順にデバイスを列挙する。「列挙する」とは、順序（たとえば共有度順位順）に従ってデバイス情報をクライアントに送信することを意味している。また、共有度の高い低いの判断は上述した通り、予め上位いくつまでのデバイスが共有度が高いと判定するようにプロキシサーバ３００に設定されているので、その設定情報を用いて、共有度の高いデバイスを特定できる。デバイスリストにはデバイス情報およびサービス情報がデバイスＩＤに関連付けられて保存されているから、共有度の高いデバイスのデバイス情報及びサービス情報をデバイスリストから選ぶことは容易である。
【０１０１】
次に、プロキシサーバ３００が、ネットワーク上に新しいデバイスを発見した場合（ステップ１１０７―Ｙ）、ステップ１１０８にて新しい順にデバイスを列挙する。プロキシサーバ３００は、Ｈｅｌｌｏメッセージあるいは探索メッセージに対する初めての応答を受信した日時と送信元のデバイスＩＤとを関連づけて記録しておく。そして、ステップ１１０７の処理時において、その記録した日時と現在日時とが一定期間内に納まっていれば、関連づけたデバイスを新しいデバイスと判定する。記録した日時と現在日時との時間差が短いほど、より新しいデバイスであると判定できる。つまり、プロキシサーバ３００は、周辺機器毎に、接続された日時を関連づけ、日時をキーとして整列した順位を共有度の順位とする。
【０１０２】
さらに、プロキシサーバ３００は、クライアントによる利用実績が記録されているデバイスがあるか否かを判定し（ステップ１１０９）、利用実績が記録されたデバイスがあると判定された場合、ステップ１１１０にて利用実績が新しい順にデバイスを列挙する。なお、ステップ１１１０では利用実績の高い順にデバイスを列挙してもよい。利用実績は、前述の通りクライアントから通知されるメッセージの数をデバイス毎に数えて利用実績と見なすことができる。
【０１０３】
以上の手順で、プロキシサーバ３００は、デバイス情報要求メッセージ対して、デバイスの共有度順位等に応じた順序でデバイス情報応答メッセージを返すことができる。また、ステップ１１０７の処理を実行することにより、新たにネットワークに参加したために利用実績値が少ないデバイスであっても、クライアントに対して推奨することが可能となる。このように、プロキシサーバ３００は、共有順位表の情報だけでなく複数の観点から推奨すべきプリンタを選択している。
【０１０４】
＜クライアントへの応答の設定＞
図１１のステップ１１０３では応答レベルの設定を読み込んでいる。プロキシサーバ３００、あるいはプロキシサーバ３００の管理部０７０３を集約した管理ユーティリティ６００の設定操作部０７１１よりクライアントへの応答レベルについての設定がおこなえる。応答レベルの設定には次の方法がある。これら方法は、プロキシサーバ３００においていずれかを固定的に実施しても良いし、あるいは、利用者によりいずれかの方法を選択させても良い。
【０１０５】
（１）段階表現：
共有度１〜３の３段階で表される段階表現を用いて応答レベルを利用者が設定する。なおこの段数は拡張可能である。設定操作部０７１１は、低、中、高の３段階で移動可能なスライダを含むユーザインターフェースを表示する。利用者はスライダを所望位置に移動して応答レベルを設定する。設定された応答レベルはハードディスクやメモリの所定アドレスに保存される。図１１のステップ１１０３では、設定された応答レベルが読まれ、「低」「中」「高」の何れであるかが判定される。
【０１０６】
プロキシサーバ３００は図１１のステップ１１０４でスコープ内の各デバイスへのクライアント接続数において上位のデバイスからソートする（これは前述の通り）。そして、応答レベルとして「高」が指定されている場合には、接続数の分布にギャップがみられる箇所をみつける。すなわち、ソートされた共有度順位表において、互いに隣接する順位のデバイスについて、接続数の差を計算する。接続数の差が最大の箇所を「中」と「高」の境界とする。したがって、応答レベルとして「高」が指定されている場合には、この境界より上位にあるデバイスのデバイス情報を、ステップ１１０６でクライアントに応答する。
【０１０７】
また、応答レベルとして「中」が指定されている場合には、クライアント接続数が少ないデバイスをカットする。たとえば、接続数０〜３のデバイスについては、ステップ１１０６においてデバイス情報として応答しない。
【０１０８】
また応答レベルとして「低」が指定されている場合には、共有度順位表に登録されたデバイスすべてについてデバイス情報をクライアントに応答する。この場合には、新しいデバイスや使用実績のあるデバイスのデバイス情報もステップ１１０６で応答されるので、ステップ１１０７以下はスキップすることができる。
【０１０９】
（２）順位表：
第２の方法では順位表を利用する。設定操作部０７１１はソートした共有度順位表を表示（たとえばデバイスの名称など）し、クライアントに応答する境界線（ボーダーライン）を利用者に指定させる。図１２はプロキシサーバ３００により表示される順位表を利用したＵＩの一例である。プロキシサーバ３００は順位表１２０１を表示し、利用者はスライダ１２０２を用いて境界線を移動させる。境界線より上にあるデバイスが、デバイス情報要求に対してデバイス情報が応答される対象となるデバイスである。この方法では、いったん指定されたデバイスのデバイスＩＤを応答レベルとしてプロキシサーバ３００が記憶し、応答レベル以上のデバイスのデバイス情報をデバイス情報要求に対して応答する。図１２の例では、共有度順位５と認識されたデバイスが境界として指定されたので、このデバイスよりも共有度の高いデバイスのデバイス情報がクライアントに通知される。あるいは、対象として指定されたデバイスの数を応答レベルとして記憶し、最新の共有度順位表の上位から記憶した数のデバイスを選択して、デバイス情報応答の対象とする。つまり、図１２の例では、上位５つのデバイス情報がクライアントに対して通知される。あるいは、選択された対象の最下位にあるデバイスＩＤを応答レベルとして記憶しておき、最新の共有度順位表の上位から記憶したデバイスＩＤまでを選択して、デバイス情報応答の対象とする。これらのうちいずれかの方法で選択されたデバイス情報がステップ１１０６でクライアントに送信される。
【０１１０】
（３）個数表現：
第３の方法はデバイスの数を直接指定する方法である。設定操作部０７１１は、スピンボックスを表示する。利用者は表示されたスピンボックスから数値を入力する。その通知がメモリ等に応答レベルとして記憶される。ＵＩは図１２のスライダ１２０２をスピンボックスに変更したものになる。図１１のステップ１１０３では記憶された数値を読み、ステップ１１０６では共有度順位表の上位から指定された数のデバイスに付いて、デバイス情報を応答する。例えば、通知個数として４を選択した場合、共有度順位において上位４つのデバイス情報がクライアントに通知される。
【０１１１】
以上説明した、クライアント、デバイス、プロキシサーバ３００の三者によるメッセージ交換の手順の一例を図１８にまとめた。図１８において、各装置の処理は、それぞれのＣＰＵによりプログラムをじっこうすることで制御されている。
【０１１２】
図１８において、プロキシサーバ３００によるデバイス探索要求１８０１の送信に対してデバイス２００が応答１８０２を返す。さらにプロキシサーバ３００によるデバイス情報要求１８０３の送信に対してデバイス２００はデバイス情報１８０４を応答する。この際に、デバイスＩＤが固定されていないのであれば、デバイス情報の送信前にデバイス２００はデバイスＩＤを決定しておく。デバイス探索要求の送信先はクライアントＰＣ１００も指定されている。そこでクライアントＰＣ１００は応答１８２２をプロキシサーバ３００に返す。プロキシサーバ３００は、さらに詳細な情報をクライアントに要求することもできるが、本例ではクライアントについてはその存在とそのアドレスやＩＤを得られれば十分として、プロキシサーバ３００はこれ以上の情報を要求しない。なお、プロキシサーバ３００が、クライアントやデバイスからネットワーク参加通知（Ｈｅｌｌｏ）メッセージを受信した場合、デバイスに対してはプロキシサーバ３００からデバイス情報要求が送信される。
【０１１３】
さて、クライアントが発行したデバイス探索要求１８０５を受信したプロキシサーバ３００は、送信元のＵＲＩをプロキシサーバ３００のＵＲＩに差し替えてクライアントＰＣ１００に対して応答１８０６を送信する。そのため、クライアントＰＣ１００は、デバイス情報要求を送信する場合、応答１８０６にて記述されたプロキシサーバ３００のＵＲＩを用いてデバイス情報要求１８０７を送信する。プロキシサーバ３００はデバイス情報要求１８０７を受信すると、保持している共有度順位情報に基づきデバイスを検索して推奨すべきデバイスを特定し（１８０７ａ）、特定されたデバイス情報１８０８をクライアントに対して応答する。プロキシサーバ３００が、クライアントＰＣ１００に対して送信するデバイス情報を図２２に示す。図２０が、プロキシサーバ３００が保持するデバイスリストであり、共有度順位情報を用いてソートした結果が図２１である。つまり、プロキシサーバ３００はデバイス２００から２０５の６個のデバイスについてのデバイス情報を保持している。この状態において、クライアントからデバイス情報要求を受信した場合、プロキシサーバ３００は送信すべきデバイス情報を特定して、クライアントに通知する。例えば、プロキシサーバ３００に対して上位３つのデバイス情報を通知することが設定されている場合、プロキシサーバ３００は、図２２のように上位３つのデバイス情報を通知する。この際、デバイス情報のアドレス情報には、デバイスのアドレス情報に対してプロキシサーバ３００のアドレス情報が付加されている。つまり、プロキシサーバ３００は、端末および周辺機器間において送受信されるメッセージを横取りして受信する。そのため、端末からの問い合わせメッセージに応じて周辺機器に関する情報を送信する場合、情報処理装置の宛先情報を付加した応答情報を端末に送信する。よって、図２２のデバイス情報を受信したクライアントが、例えば印刷処理を実行する場合、印刷データの送信先情報には選択したデバイスのアドレス情報とプロキシサーバ３００のアドレス情報が含まれている。そのため、クライアントとデバイス間のメッセージは、プロキシサーバ３００を経由するようになる。このとき、デバイス情報は、図１１に示した手順でプロキシサーバ３００からクライアントＰＣ１００に送信される。図１８では省略したが、サービス情報要求及び応答も、プロキシサーバ３００とクライアントＰＣ１００との間で交換される。クライアントでは、受信したデバイス情報を元にデバイスドライバのインストーラが実行される。つまり、クライアントが、インストール処理を実行する場合、図１０に例示したユーザインターフェースが表示され、ここで利用者が選択したデバイスについて、デバイスドライバがインストールされて利用可能となる。
【０１１４】
デバイス情報及びサービス情報を獲得したクライアントＰＣ１００は、アプリケーションプログラムの印刷要求等に応じて、印刷要求（命令）メッセージ１８０９を送信する。このメッセージの宛先は、応答１８０６により通知されたアドレスである。すなわち、プロキシサーバ３００により差し替えられたプロキシサーバ３００のアドレスに対して送信される。それを受信（フック）したプロキシサーバ３００は、送信先ＵＲＩをデバイスのＵＲＩに書き替えて（１８１０）、図８に示す手順でメッセージをカウントして、図９に示す共有度順位情報を更新する（１８１１）。その後、プロキシサーバ３００は、受信したメッセージを本来の受け手であるデバイスに対して転送する（１８１２）。差し替えられたメッセージの送信先ＵＲＩには、プロキシサーバ３００のＵＲＩとデバイスのＵＲＩとがセミコロンで区切るなどして記述されているので、本来の送信先は、送信先ＵＲＩからプロキシサーバ３００のＵＲＩを削除することで得られる。デバイス２００は受信したメッセージに対して応答メッセージ１８１３を返信する。このようにして印刷等のメッセージがクライアントからデバイスに送信される。
【０１１５】
さて、クライアント（これは上記手順に関わったクライアントと異なるものであっても良い。）が、再度デバイス探索要求１８１４をプロキシサーバ３００に送信すると、プロキシサーバ３００は図１１の手順で応答するデバイスを検索し、検索されたデバイスのデバイス情報１８１６をクライアントへ返す。これはステップ１８０７，１８０８と同様である。
【０１１６】
上記手順により本実施形態のネットワークシステムでは、プロキシサーバ３００がネットワークデバイスのデバイス情報を管理している。そしてクライアントからのデバイス情報要求に対して、共有度の高いデバイスのデバイス情報を応答する。また、共有度が高くなくとも、新たに接続されたデバイスのデバイス情報を応答する。また、共有度が高くなくとも、利用実績の高いデバイスのデバイス情報を応答する。これにより、クライアントは、ネットワークに接続された多数のネットワークデバイスの全てではなく、利用する可能性の高いデバイスに限定してそのデバイス情報を取得できる。このため、クライアントにインストールされるデバイスドライバの数も絞られるので、クライアントコンピュータの資源を節約できる。また、利用者が使用するデバイスを選択する際に、候補があらかじめ絞られることから選択しやすいという効果が得られる。
【０１１７】
また、第１実施例では、クライアントとデバイス間のメッセージをプロキシサーバ３００がフックすることにより図９の共有度順位情報を作成していたが、それに限る必要はない。例えば、クライアントは、プロキシサーバ３００が接続されていることを認識すると、プロキシサーバ３００に対してデバイス情報要求処理（GetMetaData）を実行する。ここで、クライアントが特定のデバイスを指定してデバイス情報を要求することも考えられる。この時、どのクライアントがどのデバイスを特定してデバイス情報要求をしたかをプロキシサーバ３００が管理することにより、図９の共有度順位情報を生成しても良い。一例としては、クライアントＡがプロキシサーバ３００に対して、デバイス２００の情報取得要求を行った場合、プロキシサーバ３００が保持するデバイス２００の情報をクライアントに通知する。それと共に、クライアントＡがデバイス２００の情報に対して取得要求をしたことをカウントする。このカウント情報を蓄積することで図９のデバイス共有度情報を生成しても良い。
【０１１８】
第１実施形態により、プロキシサーバ３００はネットワークに接続されている膨大な数のデバイスから利用する可能性の高いデバイスを選択して、クライアントに通知する。よって、クライアントは、多くのデバイスドライバをインストールすることにより発生するメモリの浪費やユーザによる誤操作等を防止することが可能となる。
【０１１９】
第１実施形態により、複数のネットワークデバイスが接続されたネットワークにコンピュータを接続した場合でも、コンピュータにインストールされるデバイスドライバ等のプログラムの数を制限することできる。さらに、インストールされるプログラムを、対応するデバイスの共有度にしたがって選択することで、利用される可能性の高いデバイスに絞ることができ、ユーザの利便性を一層向上させることができる。
【０１２０】
なお、プロキシサーバ３００は、周辺機器に関する機能情報を要求するデバイス情報要求メッセージを数え、その数に応じてデバイスの優先度順位表を作成してもよい。
【０１２１】
［第２実施形態］
第１実施形態のとおりプロキシサーバ３００、あるいはプロキシサーバ３００の管理部０７０３を集約した管理ユーティリティ６００の設定操作部０７１１でクライアントへの応答が設定できる。この設定方法として、前述したクライアントに表示されるプリンタのセットアップ開始ダイアログ１００１と同じＵＩを使うことも可能である。
【０１２２】
図１３が、プロキシサーバ３００の設定操作部０７１１により表示されるダイアログ１３０１である。ＩＴマネージャ（プロキシサーバ３００の管理者）は、ダイアログ１３０１に表示されたデバイス名のリストから、クライアントへデバイス情報を応答するデバイスを選択する（チェックボックスをＯＮにする）。チェックの内容を示す情報はプロキシサーバ３００に記憶され、デバイス情報とともにクライアントＰＣ１００へと送信される。クライアントがデバイス情報を受信すると、デバイスドライバのインストール時にデバイス名のリストが図１０のように表示される。その際、プロキシサーバ３００から受信した選択状態を示す情報にしたがって、図１３のユーザインターフェースで選択されていたデバイスと同じデバイスが選択された状態で図１０のユーザインターフェースが表示される。
【０１２３】
この結果、プロキシサーバ３００において、ＩＴマネージャが共有度の高いプリンタを固定で設定することができる。また、クライアントの利用者は、ＩＴマネージャによる設定に拘束されずに、インストールするデバイスドライバを選択し直すこともできる。このため、第１実施形態と同等の構成、制御であればＩＴマネージャの共有度判断が省力化される。また、プロキシサーバ３００の操作、判断を拡張するなら第１実施形態の方法を「自動モード」とし、第２実施形態の方法を「手動モード」とわけた上で、いずれかのモードをプロキシサーバ３００の管理者が選択できるように構成することもできる。この場合には、利用者はプロキシサーバ３００においてモードの選択が行える。プロキシサーバ３００は選択されたモードに応じ、手動モード時にはＩＴマネージャによる選択デバイスを示す情報をクライアントに送信する。
【０１２４】
また、デバイスが手作業で選択されるために、第１実施形態で説明した図８の手順や図１１のステップ１１０４の手順を省略しても良い。こうすることでフック制御および共有順位表作成の負荷を低減することも可能である。
【０１２５】
［第３実施形態］
第１実施形態では、図５のステップ０５０８において他イベント（メッセージ）をプロキシサーバ３００によりフックした。メッセージをフックするために、図６の径路０６０７をとおるメッセージとメタデータとを参照する必要があり、処理０６０４でＵＲＩ差し替えをおこなっている。しかし、共有度順位表を作成するためのメッセージ参照の機能を外部システムがもっていればプロキシサーバ３００がメッセージをフックする必要性はなく、処理０６０４は省略してよい。
【０１２６】
図１４は、メッセージ参照の機能をシステムがもっている場合の一例を示す図である。プロキシサーバ３００は必要なイベントをシステムに設定し(11)、イベントが発生したら通知(12)をもらう（処理１４０７、１４０８）。システムとは、たとえばクライアントコンピュータ２００やサーバコンピュータ４００である。イベントとは、メッセージ送信を伴う動作であり、たとえば印刷要求（印刷命令）などがある。プロキシサーバ３００は、利用者により入力された、イベントを特定するための情報をクライアントやサーバに送信して登録させる。イベントを特定するための情報を受信したクライアントやサーバは、イベントが生じるとそのイベントがプロキシサーバ３００から登録されたイベントであるか判定する。登録されたイベントであれば、クライアントやサーバは、そのイベントに伴って送信されるメッセージの複製をプロキシサーバ３００に送信する。たとえばプロキシサーバ３００が、クライアントおよびプリンタに対して「印刷要求」をイベントとして登録した場合を想定する。この場合、クライアントは、印刷要求メッセージをデバイス（プリンタ）に送信するとともに、その複製をプロキシサーバ３００に送信する。プロキシサーバ３００は受信したメッセージに基づいてメッセージをカウントする。受信したメッセージは廃棄される。
【０１２７】
こうして、プロキシサーバ３００が実行するフック制御を処理１４０７、１４０８で代用する。その他は第１実施形態と同じ構成であり、第１実施形態と同様の効果が得られる。また、デバイス共有度順位表（実績テーブルともいう）０９０１に相当するログをシステムがもっている場合も、同様の代用ができる。
【０１２８】
［第４実施形態］
ＷＳ−Ｄｉｓｃｏｖｅｒｙ仕様にもとづき、デバイスがネットワークから離脱する際には、ネットワークに対してＢｙｅメッセージを送信（ブロードキャスト）する。前述のＨｅｌｌｏメッセージの逆の意味を持つメッセージである。このＢｙｅメッセージの受信をきっかけにして、第１実施形態のデバイスドライバあるいはアプリケーションのインストールと対となるアンインストール処理が実施可能である。
【０１２９】
共有度が高いＭＦＰ２００がネットワークからはずされた場合、一定時間待ったのち、クライアントはＭＦＰ２００のデバイスドライバをアンインストールする。この処理のフローを説明する。待ち時間は固定値であり、たとえば操作ＵＩから入力される値が記憶されて用いられる。このフローを実行すると、短時間のデバイス離脱と復帰に対するインストールやアンインストール処理の実行が抑制される。なお本実施形態では、デバイスはＢｙｅメッセージをブロードキャストせず、プロキシサーバ３００宛にユニキャストする。
【０１３０】
図１５は、デバイスからＢｙｅメッセージを受信した際、すなわち離脱時のプロキシサーバ３００による処理フローチャートを説明する。まずステップ１５０２では、プロキシサーバ３００が、Ｂｙｅメッセージの送信元デバイスを特定する。すなわち、プロキシサーバ３００が、メッセージに含まれる送信元アドレスを読み取る。ステップ１５０３では、プロキシサーバ３００がクライアントとの接続を確認する。接続の確認は、たとえばエコーメッセージの送信などにより行える。ステップ１５０４では、プロキシサーバ３００が待ち時間の設定を確認する。ここでいう確認とは、たとえば待ち時間の設定値を、プロキシサーバ３００の記憶領域から読み出すことである。
【０１３１】
次に、Ｂｙｅメッセージの送信元デバイスが、共有度が高いデバイスであるかを、ステップ１５０４で判定する。この判定は、プロキシサーバ３００が持つ共有度順位テーブルを、図１１で説明した処理方法でソートし、応答レベルの段階表現で説明したように「高」と「中」の境界を決定する。そして、Ｂｙｅの送信元デバイスが、「高」の範囲に含まれていれば、共有度が高いと判定される。共有度が高ければ、ステップ１５０９において、ネットワークに対して、Ｂｙｅメッセージをブロードキャストする。このＢｙｅメッセージの送信元アドレスは、図１５の処理のきっかけとなるＢｙｅメッセージの送信元デバイスのアドレスが書き込まれる。
【０１３２】
共有度が高くないと判定された場合でも、そのサービスに即時性が要求されか否かステップ１５０５で判定し、即時性が要求される場合にはネットワークにＢｙｅメッセージを送信する。この判断は、Ｂｙｅメッセージの送信元デバイスが提供するサービスに、あらかじめプロキシサーバ３００に登録されたサービスが含まれているか否かの判定により実行される。サービスはＩＤやＵＲＩで表される。
【０１３３】
いずれにも該当しない場合には待機処理をおこなう。その場合は、Ｂｙｅメッセージの送信元デバイスのＩＤを、Ｂｙｅ待ちデバイスのリストに追加登録する（ステップ１５０６）。そしてステップ１５０７にて、プロキシサーバ３００はＢｙｅ待ちにしたデバイスのステータスを外部には一次停止扱いに変更する。たとえば、当該デバイスに関してデバイス情報要求があれば、一時停止中である旨の情報を応答する。ステップ１５０８では、プロキシサーバ３００は、当該デバイスに関するＢｙｅメッセージの発行時間を、Ｂｙｅ待ちデバイスのリストに、デバイスＩＤと関連づけて登録する。この時間はたとえば、あらかじめ決めた定数でよい。プロキシサーバ３００は、ステップ１５１１〜１５１３で時間待ちループする。ステップ１５１２でデバイスが復旧すれば、ステップ１５１４にすすみ、復旧あるいは更新（メタデータから判断）処理をおこなう。デバイスの復旧は、たとえばそのデバイスからＨｅｌｌｏメッセージを受信したり、あるいは一定時間おきにプローブメッセージを送信し、その応答があれば復旧したと判断できる。ステップ１５１３でＢｙｅの発行時間がきたら、プロキシサーバ３００はステップ１５１５で一時停止にしていたステータスをたとえば「離脱」に変更する。そして、ステップ１５１６でそのデバイスがネットワークから離脱する旨のＢｙｅメッセージを発行（ブロードキャスト）する。Ｂｙｅメッセージを受信したクライアントは、その送信元デバイスのデバイスドライバをアンインストールする。
【０１３４】
以上の手順により、電源断などにより一時的に短期間ネットワークから離脱しているデバイスのデバイスドライバを、ネットワーククライアントがその都度アンインストールする必要がなくなる。このため、クライアントの処理効率が向上する。また、共有度が高いデバイス、あるいは即時性が要求されるサービスを提供するデバイスについては、ネットワークからの離脱後ただちに各クライアントからデバイスドライバをアンインストールさせる。こうすることで、利用頻度が高いデバイスや、即時性サービスのために利用されるデバイスが、離脱して休止状態とされた状態で放置された状態でいることにより、誤って選択されることを防止できる。
【０１３５】
また上述した実施形態においては、プラグアンドプレイの一例として、発見したネットワークデバイスに対応したドライバのインストール／アンイストールについて説明している。しかし、ネットワークデバイスを利用、制御するために必要なユーティリティ、アプリケーションなどをクライアントＰＣ１００に自動的にインストールする場合においても適用可能である。
【０１３６】
また、上述した実施形態ではネットワークデバイスとしてプリンタに対する実装例を示したが、通信媒体を介して利用、制御可能なデバイスであれば、スキャナ、ストレージデバイス等、いずれのデバイスに対しても適用可能である。
【０１３７】
また、上述した実施形態においては、クライアントＰＣ１００がネットワークデバイスを制御するためのドライバをメモリ上に保持する形態を示したが、ドライバに限らずアプリケーション、ユーティリティソフトウエアに対しても適用可能である。また、これらソフトウエアはネットワークデバイス上に保持されている場合、あるいは第３のサーバ上に保持されている場合にも適用可能である。
【０１３８】
また、第１実施形態では共有度順位表のソートを、項目ごとに優先順位を付して行ったが、各項目の値に重みを付けて加算し、その値をキーとしてソートするなど、他の方法を採用することもできる。
【０１３９】
また、図９（Ａ）や図９（Ｂ）の共有度順位表の各項目のいずれかをキーとして表をソートしても良いし、キーの優先順位を様々に変更することもできる。優先順位の変更は、どの項目を重要視するかにより変更される。
【０１４０】
また、デバイスが最初に接続された日時そのものをキーとして表をソートしても良い。またデバイスが最後に接続された日時を共有度順位表に登録し、その日時で表をソートすることもできる。
【０１４１】
[第５実施形態]
本実施形態では、クライアントＰＣ１００とプロキシサーバ３００間で実行されるメッセージのやり取りに従ってプリンタドライバの推奨度を更新する技術について説明する。なお、本実施形態では、推奨すべきデバイスを更新するための処理と、クライアントＰＣ１００からの要求に従って推奨デバイスを通知する処理がある。
【０１４２】
まず、本実施形態における推奨すべきデバイスを更新するための処理の流れについて図２８を参照して説明する。
【０１４３】
クライアントＰＣ１００は、デバイス探索要求（Ｐｒｏｂｅ）をマルチキャストにて発行する（２８０１）。なお、このＰｒｏｂｅには、対象デバイス情報を含むことができる。例えばプリンタの存在を確認するためのＰｒｏｂｅであれば、プリンタを特定したＰｒｏｂｅが発行される。また、Ｐｒｏｂｅには、カラープリンタ等を指定することも可能とする。
【０１４４】
Ｐｒｏｂｅを受信したデバイス２００は、Ｐｒｏｂｅに含まれるデバイス情報と一致するか判定する。例えば、Ｐｒｏｂｅにプリンタを特定する情報が含まれている場合、プリンタがＰｒｏｂｅに対する返答であるネットワーク参加通知（Ｈｅｌｌｏ）信号を返信する（２８０２）。なお、このＨｅｌｌｏ信号には、Ｈｅｌｌｏ信号を発行したデバイスのアドレス情報が含まれている。また、プロキシサーバ３００も、例えばプリンタの存在を確認するためのＰｒｏｂｅの受信に従って、当該プリンタに関する情報を保持しているか判定する。プロキシサーバ３００は、保持していれば当該Ｐｒｏｂｅに対する返答であるＨｅｌｌｏ信号を発行する。ここで、プロキシサーバ３００が発行するＰｒｏｂｅに対する返答Ｈｅｌｌｏには、プロキシサーバ３００からの返答であることを示す識別情報が含まれている。よって、プロキシサーバ３００が発行したことを示す識別情報付きのＨｅｌｌｏ信号を受信したクライアントＰＣ１００は、ステップ２８０２以降についてプロキシサーバ３００とメッセージ交換処理を実行する。なお、図２８では、クライアントＰＣ１００が、プロキシサーバ３００が発行したことを示す識別情報付きのＨｅｌｌｏ信号を受信したものとして説明する。
【０１４５】
クライアントＰＣ１００は、ステップ２８０２においてプロキシサーバ３００が発行したことを示す識別情報付きのＨｅｌｌｏを受信した場合、デバイス情報要求方法を選択する図２４の選択画面２４０１を表示する（ステップ２８０３）。デバイス情報要求方法の選択画面２４０１について説明する。選択画面２４０１には、通常要求２４０２と推奨度に従う推奨要求２４０３のいずれかを選択できる。なお、現段階では、通常要求２４０２が選択されたものとして処理を進める。また、推奨度に従う推奨要求２４０３が選択された場合の処理については、後述する。
【０１４６】
クライアントＰＣ１００は、選択画面２４０１にて選択されたデバイス情報の要求方法を含むデバイス情報要求信号を発行する（ステップ２８０４）。具体的にステップ２８０４にて発行されるデバイス情報要求は、図２５および図２７にて後述するデバイスリストを要求する信号である。なお、本実施例において、デバイス情報要求を第２メッセージと記載する場合もある。
【０１４７】
プロキシサーバ３００は、デバイス情報要求信号（デバイスリストの取得要求）の受信に従って、デバイス情報要求方法を解析する。現段階では通常要求が選択されているので、後述する図２６の管理情報等は用いずに所定のルール（例えばデバイス名称の昇順等）に基づくデバイスリスト（例えば図２５）を作成して、クライアントＰＣ１００へ発行する（ステップ２８０５）。なお、プロキシサーバ３００は、ステップ２８０１のＰｒｏｂｅにて指定されたデバイスに関するリストを発行すればよい。例えば、プロキシサーバ３００が、プリンタとファクシミリ機の２台のデバイスについての情報を保持している状態で、クライアントＰＣ１００からプリンタに関する探索要求を受信した場合を想定する。この場合、２８０５にて発行されるリストには、プリンタ情報のみが記載され、ファクシミリ機については除かれる。図２５は、デバイス情報返答に従ってクライアントＰＣ１００に表示されるデバイスリスト２５０１である。クライアントＰＣ１００は、デバイスリスト２５０１を介してユーザにより選択されたデバイスのサービス情報を要求する処理へと進む。
【０１４８】
続いてクライアントＰＣ１００は、ステップ２８０５のデバイス情報返答に従ってデバイスリストを表示する（ステップ２８０６）。上述したように現段階では通常要求２４０２が選択されたため、所定のルールの一例であるデバイス名称の昇順に従う図２５のデバイスリストが表示される。ここで、ユーザはデバイスリストを介して所望とするデバイスを選択する。図２５では、プリンタ１とプリンタ２が選択された様子を示している。
【０１４９】
クライアントＰＣ１００は、デバイスリストを介して選択されたデバイスのサービス情報を取得するため、サービス情報要求信号を発行する（ステップ２８０７）。このサービス情報とは、具体的にはデバイスの機能情報であり、機能情報とは、例えばカラー印刷が可能か否か、ステイプル処理が可能か否か等、デバイスが実行可能は機能情報である。なお、本実施例において、サービス情報要求を第１メッセージと記載する場合もある。
【０１５０】
そして、プロキシサーバ３００は、サービス情報要求時にサービス情報が要求されたデバイスを特定し、デバイスのメッセージ数に基づく優先度を更新し、要求されたデバイスのサービス情報をクライアントＰＣ１００に返送する（ステップ２８０８）。
【０１５１】
ここで、図２６を用いて、プロキシサーバ３００が管理している各デバイスの優先度を更新するためのメッセージ数管理情報を説明する。図２６には、プリンタごとにサービス情報が要求された回数を管理している。例えば、図２５では、プリンタ１とプリンタ２が選択され、サービス情報要求が発行されたので、プロキシサーバ３００は、当該サービス情報要求に従って、プリンタ１とプリンタ２のメッセージ数をインクリメントする。その結果、プロキシサーバ３００は、どのデバイスがどれだけサービス情報を要求されたか（デバイスリストを介して選択されたか）をメッセージ数に基づいて管理することができる。そこで、プロキシサーバ３００は、メッセージ数の多かったデバイスを多くのユーザが共有しているデバイスであると認識して優先度をあげる。
【０１５２】
クライアントＰＣ１００は、サービス情報返答に従ってプリンタドライバをインストールする（ステップ２８０９）。
【０１５３】
続いて、図２８を用いて本実施形態における、クライアントＰＣ１００からの要求に従って推奨デバイスリストを表示する処理について説明する。なお、ステップ２８０１から２８０２は上述した処理と同様であるため詳細な説明は省略する。
【０１５４】
クライアントＰＣ１００は、ステップ２８０２においてプロキシサーバ３００が発行したことを示す識別情報付きのＨｅｌｌｏを受信した場合、デバイス情報要求方法を選択する図２４の選択画面２４０１を表示する（ステップ２８０３）。今回は、推奨度に従う推奨要求２４０３が選択された場合の処理について説明する。
【０１５５】
クライアントＰＣ１００は、デバイス情報要求時に表示される図２４の画面を介して選択された推奨要求２４０３に基づくデバイス情報要求を発行する（ステップ２８０４）。
【０１５６】
プロキシサーバ３００は、推奨要求２４０３が選択されたデバイス情報要求を受信した場合、図２６にて管理している情報に従って優先度順に並べたデバイスリストを作成してクライアントＰＣ１００に応答する（ステップ２８０５）。
【０１５７】
クライアントＰＣ１００は、ステップ２８０５の応答に従って優先度に従うデバイスリストを表示する（ステップ２８０６）。ここで、図２７を用いて優先度に従うデバイスリスト２７０１を説明する。プロキシサーバ３００は、図２６に示すような情報を管理しているとする。ここで、プロキシサーバ３００は、各デバイスのメッセージ数に基づいて優先度を決定し優先度順に並べたデバイスリストを作成する。その結果、図２７に示す優先度順に並べたデバイスリスト２７０１がクライアントＰＣ１００へ応答される。
【０１５８】
クライアントＰＣ１００は、例えば図２７に示すようなデバイスリスト２７０１を表示するため、ユーザは、優先度の高い（すなわち多くのユーザがインストールしている）プリンタドライバを容易に特定できる。そして、例えばネットワークに新規に参加したユーザは、多くのユーザによって共有されているプリンタドライバをインストールすることが可能となる。
【０１５９】
続いて、図２９を用いて本実施形態におけるプロキシサーバ３００の処理を説明する。
【０１６０】
プロキシサーバ３００は、デバイス探索要求（Ｐｒｏｂｅ）を受信したか否かを判定する（Ｓ２９０１）。
【０１６１】
Ｓ２９０１において、デバイス探索要求を受信したと判定された場合、プロキシサーバ３００は、Ｈｅｌｌｏ信号を、Ｐｒｏｂｅ信号の送信元のクライアントＰＣ１００に対して発行する（Ｓ２９０２）。そのＨｅｌｌｏ信号には、プロキシサーバ３００によって発行されたことを示す識別情報が付いている。なお、受信したＰｒｏｂｅ信号には、発行元クライアントＰＣ１００のアドレス情報が含まれているので、プロキシサーバ３００は、当該アドレスに対してＨｅｌｌｏ信号を発行する。
【０１６２】
続いて、プロキシサーバ３００は、クライアントＰＣ１００からデバイス情報要求を受信したか否かを判定する（Ｓ２９０３）。
【０１６３】
Ｓ２９０３において、プロキシサーバ３００が、デバイス情報要求を受信したと判定した場合、優先度に従うリストを要求する推奨要求か否かを判定する（Ｓ２９０４）。
【０１６４】
Ｓ２９０４において推奨要求ではないと判定された場合（Ｓ２９０４−Ｎｏ）、プロキシサーバ３００は、例えばプリンタ名称の昇順に従うデバイスリストを作成する（Ｓ２９０６）。
【０１６５】
一方、Ｓ２９０４において推奨要求であると判定された場合（Ｓ２９０４−Ｙｅｓ）、プロキシサーバ３００は優先度に従うリストを作成する。具体的には、プロキシサーバ３００は、クライアントＰＣ１００から要求されるサービス情報要求をデバイスごとにカウントしており、デバイスごとにクライアントＰＣ１００から受信したメッセージ数を管理している。この管理している情報を示す図が、上述した図２６である。つまり、プロキシサーバ３００は、サービス情報要求を受信する度に、どのデバイスのサービス情報を要求しているかを解析し、要求されたデバイスのメッセージ数を示すメッセージカウンタを１ずつカウントしている。そして、このカウント値が優先度となる。よって、プロキシサーバ３００は、Ｓ２９０５において優先度に従う（メッセージ数に従う）デバイスリストを作成して通知する。
【０１６６】
プロキシサーバ３００は、サービス情報要求を受信したか否かを判定する（Ｓ２９０７）。そして、サービス情報要求を受信した場合、プロキシサーバ３００は、どのデバイスに対するサービス情報が要求されたかを解析し、要求されたデバイスに対応するメッセージカウンタすなわち管理情報を更新する（Ｓ２９０８）。
【０１６７】
このように本願では、デバイス情報要求（デバイスリスト要求）時に、通常要求、または、多くのユーザがインストールしている推奨デバイスを特定可能なリストを要求する推奨要求を選択できる。そして、推奨要求が選択された場合、プロキシサーバ３００は、多くのユーザがインストールしているデバイス順に並べられた推奨デバイスリストを作成して通知する。そのため、プリンタドライバのインストールを実行するユーザは、例えば新規にネットワークに参加したユーザであっても容易に多くのユーザがインストールしている共有度の高いデバイスドライバに絞ったインストールを実現することが可能となる。
また、優先度の高いデバイスを決定する方法としては、各デバイスの使用履歴に従って決定する方法が挙げられる。この方法の問題点について説明する。例えば、通常はモノクロ印刷を実行するのでモノクロプリンタを頻繁に使用し、数ヶ月に１度の会議用にカラー印刷を実行するためカラープリンタを使用する環境を想定する。この場合、カラープリンタは、ほとんど使用されないため推奨デバイスとして抽出されないおそれがある。これでは、新規にネットワークに参加したユーザが、いざカラー印刷を実行したい場合、カラープリンタのプリンタドライバがインストールされていないため迅速にカラー印刷を実行することができなくなるおそれがある。
【０１６８】
しかし、本願では、多くのユーザがインストールしているデバイスを推奨するため、上記のような問題が発生するおそれを低減でき、当該ネットワークにおいて最低限必要なデバイスドライバをインストールすることが可能となる。
【０１６９】
＜発明のまとめ＞
以上、実施形態で説明した本発明に係るプロキシサーバの構成および動作を列記すると以下のようなものとなる。
（１）情報処理装置からのネットワークデバイス（たとえばディジタル複合装置）の共有度順位を判断する。
（２）共有度順に複合装置の情報（デバイス情報）を選択し、選択したデバイス情報を情報処理装置へ応答する。
（３）クライアントでは、選択されたデバイスのデバイスドライバ等のソフトウエアのインストールを誘導する。
（４）クライアント（情報処理装置）およびデバイスの個体識別をおこない、情報処理装置とデバイス間のメッセージを参照するためのアドレス情報（ＵＲＩ）変換と記録機能を持つ。
（５）利用実績表（共有度順位表）を作成する。共有度を判断する条件は以下の通りである。
−デバイス（複合装置）へのクライアント（情報処理装置）の接続数、
−デバイスへのクライアントの利用量（メッセージ量）、
−デバイスとクライアントのネットワークスコープ比較、
−デバイスの提供機能。
（６）共有度、新規追加デバイス、過去に利用実績のあるデバイスに該当するデバイスを列挙し、そのデバイス情報をクライアントに送信する。
（７）列挙範囲を設定により制御する。
（８）初期選択を設定により制御する。
（９）デバイス情報をクライアントへ選択応答する内容が設定できる。
（１０）操作ＵＩを表示する。その操作ＵＩは段階表現、順位表、個数のいずれかを設定する形式である。
（１１）初期選択とその後ユーザが追加および解除選択したデバイスに対してデバイスドライバ等のソフトウエアのイストールを誘導する。
（１２）操作ＵＩを表示し、その操作ＵＩはデバイスを個別に選択できる形式である（第２実施形態）。
（１３）クライアントやデバイスがイベント通知機能を持っていれば、情報処理装置と複合装置間のメッセージを参照するためのアドレス情報（ＵＲＩ）変換と記録の手段をイベント通知機能で代用する（図１４、第３実施形態）。
（１４）クライアントやデバイスがイベントログ機能を持っていれば、利用実績表（共有度順位表）の内容をシステムイベントログから複製する。これは実施形態には記載されていない。しかし、たとえばメッセージをフックしてデバイス別やサービス別にカウントするというプロキシサーバによる機能と同様のログ機能を持つクライアントもある。プロキシサーバは各クライアントにログを要求して受信し、共有度順位表を作成できる。そのタイミングはたとえば定期的あるいはデバイス情報要求を受信したときである。
（１５）デバイスのネットワークからの離脱時は、プロキシサーバは、クライアントが保持するデバイスのステータスを一次停止にする。また、待ち時間を設定する。また、デバイスが復旧しないまま待ち時間が経過すれば、クライアントにデバイスの離脱を通知してドライバを削除させる。復旧すれば、その旨をクライアントに通知する。
（１６）内部的に階層的な接続部、フロー制御部、管理部の各構造をもつ。
（１７）記録、判断、設定を担当する管理機能部は分離できる。
（１８）分離された管理機能部をサーバに集約配置可能である。
（１９）分離された管理機能部を管理ユーティリティと接合できる。
【０１７０】
［実施形態における発明の関連づけ］
実施形態記載の発明は、以下のように記載することもできる。すなわち、本発明は、周辺機器（デバイス２００）および端末（クライアントＰＣ１００）と通信可能な情報処理装置（プロキシサーバ３００）に係るものである。本装置は、保存手段と、係数手段と、受信手段と、応答手段とを有する。本装置において、保存手段はＨＤＤ１１に保存されたデバイスリスト１１ａに相当する。保存手段は、前記周辺機器（２００）から該周辺機器に関する情報（デバイス情報１８０４）を受信して保存する。
【０１７１】
また、計数手段は、プロキシサーバ３００のＣＰＵ１によりステップＳ１７０１−Ｓ１７０９を実行して共有度順位表０９０１を作成することに相当する。係数手段は、前記端末（１００）および前記周辺機器間（２００）において送受信されているメッセージ情報（１８０９）を周辺機器毎に数えることにより得られる周辺機器毎の共有度を計数する。
【０１７２】
また、受信手段は、プロキシサーバ３００のＣＰＵ１によりデバイス情報要求１８０７を受信することに相当する。要求メッセージ受手段手段は、前記端末（１００）から、前記保存手段（デバイスリスト１１ａ）にて保持されている周辺機器に関する情報を要求する要求メッセージ（デバイス情報要求１８０７）を受信する。
【０１７３】
また、応答手段は、プロキシサーバ３００のＣＰＵ１によりデバイス検索処理１８０７ａを実行することに相当する。応答手段は、前記受信手段により前記要求メッセージ（デバイス情報要求１８０７）を受信することに応じて、前記計数手段により得られる周辺機器毎の共有度に従って選択された周辺機器に関する情報を、前記端末に送信する。
【０１７４】
さらに、前記計数手段は、前記端末から前記周辺機器へのメッセージを受信し、受信したメッセージの宛先および送信元情報に基づいて、周辺機器毎に、送信元となった端末数を数えて前記共有度を計数し、
また本装置は、前記周辺機器に前記計数手段により得られた共有度を用いて、該端末数をキーとして整列した順位を共有度の順位とする共有度順位情報を作成する作成手段をさらに有する。作成手段は、ＣＰＵ１が、ステップＳ０８０１−Ｓ０８０６を実行して共有度順位表０９０１を作成することに相当する。
【０１７５】
また前記応答手段は、前記作成手段によって作成された共有度順位情報を用いて送信すべき周辺機器に関する情報を選択する。
【０１７６】
あるいは、第５実施形態に係る発明については以下のようにも言い得る。すなわち、本発明は、周辺機器（デバイス２００）および端末（クライアントＰＣ１００）と通信可能な情報処理装置（プロキシサーバ３００）に係るものである。本装置は、保存手段と、第１応答手段と、更新手段と、受信手段と、第２応答手段とを有する。本装置において、保存手段は、ＨＤＤ１１：デバイスリスト１１ａに相当する。保存手段は、前記周辺機器（２００）から該周辺機器に関する機能情報（１８０４）を受信して保存する。
【０１７７】
また、第１応答手段は、ＣＰＵ１によるサービス情報応答２８０８の送信に相当する。第１応答手段は、前記端末（１００）からの、周辺機器（２００）に関する機能情報を要求する第１メッセージ（サービス情報要求２８０７）の受信に従って、前記保存手段（ＨＤＤ１１）によって保存された機能情報（１１ａ）を前記端末（１００）に送信する。
【０１７８】
また、更新手段は、ＣＰＵ１が、ステップＳ２９０８を実行してメッセージカウンタを更新することに相当する。更新手段は、前記端末（１００）からの、周辺機器（２００）に関する機能情報（１１ａ）を要求する前記第１メッセージ（サービス情報要求２８０７）の数に基づいて推奨すべきデバイスの優先度を更新する。
【０１７９】
また、受信手段は、ＣＰＵ１が、デバイス情報要求２８０４を受信することに相当する。受信手段は、前記端末（１００）から、推奨する周辺機器のリスト（リスト２５０１）を要求する第２メッセージ（デバイス情報要求２８０４）を受信する。
【０１８０】
また、第２応答手段は、ＣＰＵ１が、ステップＳ２９０５を実行することに相当する。第２応答手段は、前記受信手段により前記第２メッセージ（２８０４）を受信することに応じて、前記更新手段によって更新された優先度に従って決定される周辺機器のリストを、前記端末に送信する。
【０１８１】
［他の実施形態］
上述した実施形態におけるクライアントＰＣ１００及びネットワーク対応デバイス２００における各処理機能は、各処理機能を実現する為のプログラムをメモリから読み出してＣＰＵ（中央演算装置）が実行することによりその機能を実現させる。しかしこれに限定さるものではなく、各処理機能の全部または一部の機能を専用のハードウェアにより実現してもよい。また、上述したメモリは、光磁気ディスク装置、フラッシュメモリ等の不揮発性のメモリにより構成されても良い。また、ＣＤ−ＲＯＭ等の読み出しのみが可能な記録媒体、ＲＡＭ以外の揮発性のメモリ、あるいはこれらの組合せによるコンピュータ読み取り、書き込み可能な記録媒体より構成されてもよい。
【０１８２】
また、クライアントＰＣ１００またはネットワーク対応デバイス２００内の各機能を実現する為のプログラムをコンピュータ読み取り可能な記録媒体に記録しておく。この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより各処理を行っても良い。ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含む。具体的には、記憶媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書きこまれる。その後、そのプログラムにしたがって、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含む。
【０１８３】
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置を含む。さらに「コンピュータ読み取り可能な記録媒体」とは、通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発メモリ（ＲＡＭ）のように、一定時間プログラムを保持しているものも含むものとする。
【０１８４】
また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことをいう。
【０１８５】
また、上記プログラムは、前述した機能の一部を実現する為のものであっても良い。さらに、前述した機能をコンピュータシステムに既に記録されているプログラムとの組合せで実現できるもの、いわゆる差分ファイル（差分プログラム）であっても良い。
【特許請求の範囲】
【請求項１】
端末と通信可能な情報処理装置であって、
端末による利用実績がある周辺機器があるか判定する判定手段と、
前記判定手段によって前記周辺機器があると判定された場合、利用実績が新しい順に列挙された周辺機器の情報を前記端末に通知する通知手段とを有し、
前記利用実績は、印刷処理の利用実績であることを特徴とする情報処理装置。
【請求項２】
前記通知手段は、ユーザにより指定された数の周辺機器の情報を通知することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記通知手段は、前記情報処理装置の宛先情報を付加した周辺機器の情報を通知することを特徴とする請求項１または２に記載の情報処理装置。
【請求項４】
前記通知手段により通知された周辺機器に関する情報には、利用実績が新しい順に列挙された前記周辺機器とは異なる周辺機器の情報も含まれることを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
【請求項５】
複数の周辺機器のアドレス情報、デバイス名を含む情報を記憶する記憶手段を更に有することを特徴とする請求項１乃至４のいずれか１項に記載の情報処理装置。
【請求項６】
前記利用実績の有無は、印刷処理の実行を前記周辺機器に要求する印刷要求に基づいて決定されることを特徴とする請求項１乃至５のいずれか１項に記載の情報処理装置。
【請求項７】
端末と通信可能な情報処理装置による情報処理方法であって、
端末による利用実績がある周辺機器があるか判定する判定工程と、
前記判定工程によって前記周辺機器があると判定された場合、利用実績が新しい順に列挙された周辺機器の情報を前記端末に通知する通知工程とを有し、
前記利用実績は、印刷処理の利用実績であることを特徴とする情報処理方法。
【請求項８】
前記通知工程では、ユーザにより指定された数の周辺機器の情報を通知することを特徴とする請求項７に記載の情報処理方法。
【請求項９】
前記通知工程では、前記情報処理装置の宛先情報を付加した周辺機器の情報を通知することを特徴とする請求項７または８に記載の情報処理方法。
【請求項１０】
前記通知工程により通知された周辺機器に関する情報には、利用実績が新しい順に列挙された前記周辺機器とは異なる周辺機器の情報も含まれることを特徴とする請求項７乃至９のいずれか１項に記載の情報処理方法。
【請求項１１】
複数の周辺機器のアドレス情報、デバイス名を含む情報を記憶手段に記憶する記憶工程を更に有することを特徴とする請求項７乃至１０のいずれか１項に記載の情報処理方法。
【請求項１２】
前記利用実績の有無は、印刷処理の実行を前記周辺機器に要求する印刷要求に基づいて決定されることを特徴とする請求項７乃至１１のいずれか１項に記載の情報処理方法。
【請求項１３】
端末と通信可能なコンピュータを、
端末による利用実績がある周辺機器があるか判定する判定手段と、
前記判定手段によって前記周辺機器があると判定された場合、利用実績が新しい順に列挙された周辺機器の情報を前記端末に通知する通知手段として機能させるためのプログラムであって、
前記利用実績は、印刷処理の利用実績であることを特徴とするプログラム。
【請求項１４】
前記通知手段は、ユーザにより指定された数の周辺機器の情報を通知することを特徴とする請求項１３に記載のプログラム。
【請求項１５】
前記通知手段は、前記情報処理装置の宛先情報を付加した周辺機器の情報を通知することを特徴とする請求項１３または１４に記載のプログラム。
【請求項１６】
前記通知手段により通知された周辺機器に関する情報には、利用実績が新しい順に列挙された前記周辺機器とは異なる周辺機器の情報も含まれることを特徴とする請求項１３乃至１５のいずれか１項に記載のプログラム。
【請求項１７】
複数の周辺機器のアドレス情報、デバイス名を含む情報を記憶する記憶手段としてコンピュータを更に機能させることを特徴とする請求項１３乃至１６のいずれか１項に記載のプログラム。
【請求項１８】
前記利用実績の有無は、印刷処理の実行を前記周辺機器に要求する印刷要求に基づいて決定されることを特徴とする請求項１３乃至１７のいずれか１項に記載のプログラム。
【請求項１】
端末と通信可能な情報処理装置であって、
端末による利用実績がある周辺機器があるか判定する判定手段と、
前記判定手段によって前記周辺機器があると判定された場合、利用実績が新しい順に列挙された周辺機器の情報を前記端末に通知する通知手段とを有し、
前記利用実績は、印刷処理の利用実績であることを特徴とする情報処理装置。
【請求項２】
前記通知手段は、ユーザにより指定された数の周辺機器の情報を通知することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記通知手段は、前記情報処理装置の宛先情報を付加した周辺機器の情報を通知することを特徴とする請求項１または２に記載の情報処理装置。
【請求項４】
前記通知手段により通知された周辺機器に関する情報には、利用実績が新しい順に列挙された前記周辺機器とは異なる周辺機器の情報も含まれることを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
【請求項５】
複数の周辺機器のアドレス情報、デバイス名を含む情報を記憶する記憶手段を更に有することを特徴とする請求項１乃至４のいずれか１項に記載の情報処理装置。
【請求項６】
前記利用実績の有無は、印刷処理の実行を前記周辺機器に要求する印刷要求に基づいて決定されることを特徴とする請求項１乃至５のいずれか１項に記載の情報処理装置。
【請求項７】
端末と通信可能な情報処理装置による情報処理方法であって、
端末による利用実績がある周辺機器があるか判定する判定工程と、
前記判定工程によって前記周辺機器があると判定された場合、利用実績が新しい順に列挙された周辺機器の情報を前記端末に通知する通知工程とを有し、
前記利用実績は、印刷処理の利用実績であることを特徴とする情報処理方法。
【請求項８】
前記通知工程では、ユーザにより指定された数の周辺機器の情報を通知することを特徴とする請求項７に記載の情報処理方法。
【請求項９】
前記通知工程では、前記情報処理装置の宛先情報を付加した周辺機器の情報を通知することを特徴とする請求項７または８に記載の情報処理方法。
【請求項１０】
前記通知工程により通知された周辺機器に関する情報には、利用実績が新しい順に列挙された前記周辺機器とは異なる周辺機器の情報も含まれることを特徴とする請求項７乃至９のいずれか１項に記載の情報処理方法。
【請求項１１】
複数の周辺機器のアドレス情報、デバイス名を含む情報を記憶手段に記憶する記憶工程を更に有することを特徴とする請求項７乃至１０のいずれか１項に記載の情報処理方法。
【請求項１２】
前記利用実績の有無は、印刷処理の実行を前記周辺機器に要求する印刷要求に基づいて決定されることを特徴とする請求項７乃至１１のいずれか１項に記載の情報処理方法。
【請求項１３】
端末と通信可能なコンピュータを、
端末による利用実績がある周辺機器があるか判定する判定手段と、
前記判定手段によって前記周辺機器があると判定された場合、利用実績が新しい順に列挙された周辺機器の情報を前記端末に通知する通知手段として機能させるためのプログラムであって、
前記利用実績は、印刷処理の利用実績であることを特徴とするプログラム。
【請求項１４】
前記通知手段は、ユーザにより指定された数の周辺機器の情報を通知することを特徴とする請求項１３に記載のプログラム。
【請求項１５】
前記通知手段は、前記情報処理装置の宛先情報を付加した周辺機器の情報を通知することを特徴とする請求項１３または１４に記載のプログラム。
【請求項１６】
前記通知手段により通知された周辺機器に関する情報には、利用実績が新しい順に列挙された前記周辺機器とは異なる周辺機器の情報も含まれることを特徴とする請求項１３乃至１５のいずれか１項に記載のプログラム。
【請求項１７】
複数の周辺機器のアドレス情報、デバイス名を含む情報を記憶する記憶手段としてコンピュータを更に機能させることを特徴とする請求項１３乃至１６のいずれか１項に記載のプログラム。
【請求項１８】
前記利用実績の有無は、印刷処理の実行を前記周辺機器に要求する印刷要求に基づいて決定されることを特徴とする請求項１３乃至１７のいずれか１項に記載のプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【公開番号】特開２０１３−８４３０４（Ｐ２０１３−８４３０４Ａ）
【公開日】平成２５年５月９日（２０１３．５．９）
【国際特許分類】
【出願番号】特願２０１３−８８１７（Ｐ２０１３−８８１７）
【出願日】平成２５年１月２１日（２０１３．１．２１）
【分割の表示】特願２００６−３３２６１２（Ｐ２００６−３３２６１２）の分割
【原出願日】平成１８年１２月８日（２００６．１２．８）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
【公開日】平成２５年５月９日（２０１３．５．９）
【国際特許分類】
【出願日】平成２５年１月２１日（２０１３．１．２１）
【分割の表示】特願２００６−３３２６１２（Ｐ２００６−３３２６１２）の分割
【原出願日】平成１８年１２月８日（２００６．１２．８）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
[ Back to top ]