[第1実施形態]
以下に、図面を参照して、この発明の好適な実施の形態を例示的に詳しく説明する。ただし、この実施の形態に記載されているプロトコル、バージョン、アドレス、その他の数値等は、特に特定的な記載がない限りは、この発明の範囲をそれらのみに限定する趣旨のものではない。
<クライアントとデバイスの接続の基本説明>
図1は、本発明の一実施形態としてのネットワークプラグアンドプレイシステムの構成を示すブロック図である。クライアントPC(クライアントデバイスとも言う)100は、通信機能としてEthernet(登録商標)等のLAN,WiFi(登録商標)(IEEE80.11a/b/g)等の無線LAN,Bluetooth(登録商標)に対応している。それぞれの通信機能は、Ethernet(登録商標)コントローラ0101、WiFi(登録商標)コントローラ0102、Bluetooth(登録商標)コントローラ0103により制御される。これらコントローラの上位レイヤには、TCP/UDP/IPプロトコルスタック0104が備えられ、そのプロトコルスタック上にHTTP処理部0105が備えられている。HTTP処理部0105は、HTTPリクエストの解析、およびレスポンス処理を行う。
TCP/UDP/IPプロトコルスタック0104、およびHTTP処理部0105の上位層には、Simple Object Access Protocol(SOAP)プロセッサ0106が備えられている。プラグアンドプレイモード設定ユーティリティ0107は、SOAPプロセッサ0106を介して、eXtensible MarkupLanguage(XML)で記述されたデータの双方向通信を実現する。WSDモジュール0108、およびユーティリティ0114、アプリケーション0115それぞれも同様である。
ネットワークマネージャ0109は、Ethernet(登録商標)コントローラ0101、WiFi(登録商標)コントローラ0102、Bluetooth(登録商標)0103コントローラを管理するモジュールである。ネットワークマネージャ0109は、各コントローラの設定情報、通信状態に関する情報を取得する機能を備える。
WSDモジュール0108は、SOAPプロセッサ0106を介して、ネットワークデバイスから通知されるHelloメッセージに対する応答処理、および、ネットワークデバイス検索のためのProbeメッセージの発行処理を実行する。また、GetMetadataメッセージを発行することで、ネットワークデバイスの属性情報を取得する。属性情報は、デバイスの備えるハードディスク等の記憶部に記憶されている。
ネットワークデバイスの属性情報には、そのデバイスのデバイスIDや、そのデバイスにより提供されるサービスIDが含まれている。サービスとは、デバイスが提供する個々の機能を指す。たとえばデバイスがディジタル複合機であり、印刷機能とスキャン機能をあわせ持っていれば、プリントサービスとスキャンサービスとが利用できることを含んだ情報が提供される。さらに、プリント機能が複数のPDLに対応していれば、各PDLに対して提供されるプリント機能はそれぞれ独立したサービスである。
これらのメッセージ処理により、クライアントPC100がネットワークデバイスを発見した場合、WSDモジュール0108はプラグアンドプレイコントローラ0111に対して、発見したネットワークデバイスの属性情報を通知する。プラグアンドプレイコントローラ0111は該属性情報をもとに該当するドライバ、ユーティリティソフトウエアをメモリコントローラ0110を介してメモリより読み込み、インストールを実行する機能を備える。
アプリケーション0115は、例えばワードプロセッサなどのアプリケーションプログラムである。アプリケーション0115は、編集した文書をネットワークデバイス・プリンタにより印刷するための機能を有する。その際、アプリケーション0115から出力された文書データは、プラグアンドプレイコントローラ0111によりインストールされたドライバ、ユーティリティを介して、ネットワーク対応デバイス200に送信される。
一方、ネットワーク対応デバイス200、すなわち本実施の形態ではネットワーク対応型プリンタは以下の構成を有する。ネットワーク対応デバイス200は、Ethernet(登録商標),WiFi(登録商標)(IEEE80.11a/b/g),Bluetooth(登録商標)に対応した通信機能を持つ。各通信機能は、それぞれEthernet(登録商標)コントローラ0116、WiFi(登録商標)コントローラ0117により制御される。これらコントローラの上位レイヤには、TCP/UDP/IPプロトコルスタック0118が備えられ、そのプロトコルスタック上にHTTP処理部0119が備えられる。HTTP処理部0119は、HTTPリクエストの解析、およびレスポンス処理を行う。
TCP/UDP/IPプロトコルスタック0118、およびHTTP処理部0119上位層にはSimple Object Access Protocol(SOAP)プロセッサ0120を備える。そのため、WSDモジュール0121、およびプリンタコントローラ0122が、それぞれ該処理部を介してeXtensible Markup Language(XML)で記述されたデータの双方向通信を実現可能となる。
ここで、WSDモジュール0121は、SOAPプロセッサ0120を介してネットワークに接続した際に、Helloメッセージの送信、およびクライアントPC100から発行されるProbeメッセージに対する応答処理を実行する。
また、クライアントPC100から発行されたGetMetadataメッセージに応じ、ネットワーク対応デバイスは、属性情報(本実施形態の場合、ネットワーク対応プリンタが持つ属性情報)を返信する。属性情報は、たとえばデバイス自体の情報(デバイス情報)であり、デバイスが提供するサービスの情報(サービス情報)である。
<印刷システムのハードウェア構成>
図16は、本発明の実施の形態である情報処理装置とプリンタのハードウェア構成を示すブロック図である。図16では、プロキシサーバ300とネットワークデバイスであるプリンタ3000とがネットワーク31を介して接続された構成となっている。プロキシサーバ300ではコンピュータ本体2000に対して外部装置であるキーボード9、CRT10、ハードディスク11等が接続されている。コンピュータ本体2000はCPU1を備え、CPU1はROM3やハードディスク11に記憶された制御プログラムやアプリケーションをRAM2に展開して演算を行うことができる。また、外部装置であるキーボード9からの入力を制御しているのがキーボードコントローラ(KBC)5である。また、CRT10の表示を制御しているのがCRTコントローラ(CRTC)6であり、ハードディスク11に対して入出力の制御を行っているのがハードディスクコントローラ(HDC)7である。NetC8はネットワークコントローラであり、ネットワーク31を介してプリンタ3000に接続されて、プリンタコントローラ部4000との間の通信制御を行っている。
これらCPU1、RAM2、ROM3、KBC5、CRTC6、HDC7、NetC8はそれぞれシステムバス4によって接続され、各デバイスをCPU1が総括的に制御している。HDD11には、ネットワークデバイス、特に本実施形態ではネットワークプリンタの利用頻度を順位付けした共有度順位表0901およびデバイス情報やサービス情報のリスト(デバイスリストあるいは機器情報)11aが保存されている。共有度順位表0901は、プロキシサーバ300にネットワークデバイスの名称(識別子)のほか、プロキシサーバ300が収集した情報(図17等で説明する)が含まれている。デバイスリスト11aや共有度順位表0901は、ハードディスク11に保存され、CPU1によりアクセスされる際にRAM2にロードされる。なお、共有度順位表は共有度順位情報ともいう。HDD11やRAM2のデバイスリスト11aは、保存手段として機能する。あるデバイスの共有度とは、端的にはそのデバイスを使用したクライアントの数である。ただし、重複するクライアントは排除される。本実施形態では、共有度とは、図9に例示するように、クライアント数とその他の指標を複合させた複合的な指標である。
本実施形態では、プロキシサーバ300としてパーソナルコンピュータ(PC)を想定している。つまり、プロキシサーバ300は、情報処理装置である。しかし、本発明を実施可能な形態であれば、プロキシサーバ300はPCに限定するものではなく、PDAなどの携帯情報端末や携帯電話、ディジタル家電等をクライアントとしてもよい。いずれの装置も、特定用途の入出力デバイス等を除けば、図1のプロキシサーバ300と同様の構成を有する。
ネットワークプリンタ3000において、プリンタCPU21は、ROM23のプログラム用領域に記憶された制御プログラムを実行する。制御プログラムの実行により、バス24に接続される各種のデバイスとのアクセスを総括的に制御し印刷部26を介して接続される印刷機構部28(プリンタエンジン)に印刷データとしての画像信号が出力される。
プリンタCPU21はネットワークコントローラ(NetC)25を介してプロキシサーバ300及び不図示のクライアントPC100との通信処理が可能である。通信によりネットワークプリンタ3000内の情報等をプロキシサーバ300およびクライアントPC100に通知可能に構成されている。RAM22はプリンタCPU21の主メモリ、ワークエリアなどとして機能する。また、RAM22はクライアントPC100(不図示)より受信した印刷データや画像ビットマップデータを格納しておくための描画メモリ、ビデオ信号情報格納領域、その他としても使用される。ハードディスクコントローラ27にて制御されるハードディスク29は印刷ジョブデータのBOX保存などのために使用される。操作パネル30はユーザがネットワークプリンタ3000を操作する際のユーザインターフェースであり各種スイッチやLED表示機器の他、タッチパネル式の液晶パネルなどで構成される。
ハードディスク29には、プリンタ3000の構成を示す構成情報データベース2901が保存されている。構成情報データベースは、各種のデータを含むデータベースである。構成情報データベース2901には、デバイスタイプ情報、サービス情報、デバイスの使用頻度情報、デバイス機能情報、製造メーカ情報など、デバイス情報やサービス情報の基礎となる情報が含まれている。なお、デバイス機能情報とは、印刷速度情報、カラー印刷機能の有無を示すカラー機能情報、最高解像度情報、両面印刷機能の有無を示す両面機能情報等である。デバイスタイプ情報は、たとえば当該デバイスが単機能プリンタや、複写機などデバイスのタイプを示す。サービス情報は、当該タイプのデバイスにより提供されるサービスを示す。たとえばプリンタであれば、postscript(登録商標)など、対応するPDLの種類を示す情報がサービス情報として登録されている。なお、本例ではPDLの種類はURIで示される。
なお、ネットワークプリンタ3000は本発明の機能を実施できる装置であればシングルファンクションプリンタでもスキャナやコピー、ファクシミリ等の機能も備えたマルチファンクションプリンタでもよい。印刷機構部28としてレーザービームプリンタやインクジェットの印刷機構を用いたプリンタ、サーマルプリンタなどいかなるプリント方式を用いていようが、本発明の機能に制限をするものではない。また、図1に記述したクライアントPCのハードウェア構成も、図16の情報処理装置300と同様である。
<デバイス検索手順>
図2(A)を参照して、クライアントPC100より、ネットワーク上で利用可能な状態にあるネットワーク対応デバイス200を検索する場合の制御の流れフロー形式で説明する。なお、図2(A)、図2(B)と同様のシーケンスは、プロキシサーバ300とネットワーク対応デバイス200との間においても実行される。プロキシサーバ300は、図2(A)、図2(B)のシーケンスを通して、ネットワーク対応デバイス200からデバイス情報及びサービス情報を収集し、デバイスリスト11aとしてたとえばハードディスク11に保存する。
ステップ0201:
クライアントPC100のユーティリティ0114、あるいはアプリケーション0115は、SOAPプロセッサ0106に対してProbeメッセージの送信を要求する。きっかけは例えば電源の投入などである。その要求に応じて、SOAPプロセッサ0106はProbeメッセージを生成し、プロトコルスタック0104を介してマルチキャストアドレス239.255.255.250に対してマルチキャスト送信する。送信されたProbeメッセージに対するネットワーク対応デバイス200からの応答であるProbe Matchメッセージの有無により、ネットワークデバイスの検索処理を実現している。
ステップ0202:
ネットワーク対応デバイス200がProbeメッセージを受信すると、受信したProbeメッセージはTCP/UDP/IPプロトコルスタック0118を介して、SOAPプロセッサ0120に通知される。SOAPプロセッサ0120は、Probeメッセージの内容を解析し、その結果(メッセージの内容)をWSDモジュール0121に通知する。WSDモジュール0121は、通知されたメッセージの内容が、このネットワーク対応デバイス200が提供する機能と一致しているか否かを判断する。一致しないと判断した場合、その情報を無視する。したがって、この場合はネットワーク対応デバイス200からProbe Matchレスポンスが発行されることは無い。一方、一致すると判断した場合、WSDモジュール0121は、SOAPプロセッサ0120に対してProbe Matchメッセージ発行を要求する。SOAPプロセッサ0120は、Probe Matchメッセージを生成し、プロトコルスタック0118を介してクライアントPC100に対してProbe Matchメッセージをユニキャスト送信する。
ステップ0203、0205:
クライアントPC100がProbe Matchメッセージを受信すると、メッセージはTCP/UDP/IPプロトコルスタック0104を介してSOAPプロセッサ0106に通知される。SOAPプロセッサ0106は、Probe Matchメッセージの内容を解析し、その結果をWSDモジュール0108に通知する。WSDモジュール0108は、Probe Matchメッセージに記述されたアドレスを宛先とするGetMetadataメッセージの発行をSOAPプロセッサ0106に対して要求する。GetMetadataメッセージは、Probe Matchメッセージを発行したネットワーク対応デバイス200の属性情報を取得する要求である。SOAPプロセッサ0106は、GetMetadataメッセージを生成し、プロトコルスタックを介してネットワーク対応デバイス200に対してユニキャスト送信する。
なおステップ0205では、クライアントPCが、サービス情報を要求している。すなわち、ステップ0205と0203において異なる点は、デバイス情報を要求するか、サービス情報を要求するかであり、この相違を除いて、メッセージ交換の手順は同一である。
ステップ0204、0206:
ネットワーク対応デバイス200がGetMetadataメッセージを受信すると、そのメッセージはTCP/UDP/IPプロトコルスタック0118を介してSOAPプロセッサ0120に通知される。SOAPプロセッサ0120は、GetMetadataメッセージの内容を解析し、その結果をWSDモジュール0121に通知する。WSDモジュール0121においては、指定された属性情報を、GetMetadataメッセージ送信元のクライアントに対して返信するために、SOAPプロセッサ0120に対してGetMetadataResopnseメッセージの発行を要求する。SOAPプロセッサ0120は、GetMetadataResponseメッセージを生成し、プロトコルスタックを介してクライアントに対してユニキャスト送信する。GetMetadataResponseメッセージとは、デバイス200が送信するデバイス情報およびサービス情報の総称である。
なお、ステップ0204とステップ0206において異なる点は、デバイス200が、デバイス情報を送信するかサービス情報を送信かであり、それ以外のメッセージ処理の手順は同一である。
ステップ0207:
クライアントPC100がGetMetadataResponseを受信すると、受信したGetMetadataResponseメッセージはTCP/UDP/IPプロトコルスタック0104を介して、SOAPプロセッサ0106に通知される。GetMetadataResponseメッセージに記述されたデバイス属性情報は、クライアントPC100のSOAPプロセッサ0106を介してWSDモジュール0108に通知される。
WSDモジュール0108は、プラグアンドプレイコントローラ0111を起動し、デバイス属性情報をプラグアンドプレイコントローラ0111に対し通知する。通知をうけたプラグアンドプレイコントローラ0111はメモリコントローラを介してデバイス属性情報に一致するドライバプログラムを記憶装置より検索し、該当するドライバのインストールを実行する。インストールは、ウィンドウズ(登録商標)OSであれば、インストールする場所等を記述したインストールファイルを用意しておくことで、標準のインストーラで行える。あるいは、ドライバをインストーラと組にして提供しても良い。なお、デバイスドライバがネットワークを介してクライアントPC100と接続されたサーバにより提供されている場合には、ドライバプログラムはサーバ上で検索される。
<デバイスの参加通知手順>
さらに図2(B)を参照して、ネットワーク対応デバイス200が、新規に導入されネットワーク通信を開始する、あるいは、電源オフの状態から電源オンされネットワーク通信を再開する場合の制御の流れをフロー図で説明する。
ステップ0208:
ネットワーク対応デバイス200がネットワーク上で通信を開始、あるいは、再開する際、WSDモジュール0121は、SOAPプロセッサ0120に対してHelloメッセージの送信を要求する。きっかけは、たとえば電源の投入などである。SOAPプロセッサ0120はHelloメッセージを生成し、プロトコルスタックを介してマルチキャストアドレス239.255.255.250に対してマルチキャスト送信する。
ステップ0209:
クライアントPC100がHelloメッセージを受信すると、HelloメッセージはTCP/UDP/IPプロトコルスタック0104を介して、SOAPプロセッサ0106に通知される。SOAPプロセッサ0106は、Helloメッセージの内容を解析し、その結果(メッセージの内容)をWSDモジュール0108に通知する。WSDモジュール0108は、Helloメッセージに記述されたアドレスに対し、該メッセージを発行したネットワークデバイスの属性情報を取得するために、SOAPプロセッサ0106に対してGetMetadataメッセージ発行を要求する。SOAPプロセッサ0106はGetMetadataメッセージを生成し、TCP/UDP/IPプロトコルスタック0104を介してネットワーク対応デバイス200に対してユニキャスト送信する。このあとのフローは、図2(A)のデバイス探索のステップ0204以下と同様であるため、説明は省略する。
なお、図2の手順は、クライアントPC100を図5に示す探索プロキシサーバ300に置換した場合に、探索プロキシサーバ300とデバイス200との間においても行われる。したがって、探索プロキシサーバ300が存在するネットワークでは、探索プロキシサーバ300がネットワークデバイスのデバイス情報及びサービス情報を収集し、デバイスリスト11aとして保存し管理する。またプロキシサーバ300はその他のメッセージをフック(すなわち横取り)して宛先のデバイスやサービス、送信元のクライアントに応じてメッセージをカウントする。そのカウンタに基づいて共有度順位表が作成され保存される。
<Metadataの形式>
図3を参照して、図2(A),図2(B)においてデバイスからクライアントPC(クライアント端末ともいう)100へと送信されるメタデータ(Metadata)の形式を説明する。メタデータはXMLで記述されたデータとする。第1のメタデータはデバイス情報0301である。デバイス情報0301には、デバイスのモデル名0301aやベンダ名などのデバイス情報が記載されている。そのなかにサービス情報へのリンク0301bが記載されている。
第2のメタデータはサービス情報0302である。図3の例では、サービス情報0302はPDL_Aのメタデータである。すなわち、サービス情報0302には、"MFP200.PDL_A(0302a)"と記述されている。この記述は、MFP200というデバイスでは、PDL_Aというサービスが提供されることを示す。つまり、MFP200は、PDL_A(ページ記述言語A)を解釈可能であることが記されている。このようにサービス情報内には、デバイス情報に含まれるデバイスIDとサービスIDとが格納されている。デバイスIDはプラグアンドプレイに利用される。PDL_Bのサービス情報303、PDL_Cのサービス情報0304も同様である。
図3の例では、プリントサービスであるPDL_A〜PDL_Cのメタデータ0302〜0304へのリンクがデバイス情報0301に含まれている。そこで、たとえば図2(A)のステップ0205や図2(B)のステップ0211では、デバイス情報から得られたアドレス(リンク先)を指定して、サービス情報を要求する。
<Probe Matchメッセージの内容>
図4を参照してProbe Matchメッセージ0401の内容を説明する。プローブマッチ0401は、終端のアドレスであるエンドポイントURI401a、サービスタイプ401bやネットワークスコープ401cに関する情報、コミュニケーションに使用するURI401d、メタデータのバージョン情報401eが含まれている。このバージョン情報401eは内容更新にあわせインクリメントされる。メッセージ0402はProbe Matchメッセージの一例である。Probe MatchメッセージはXMLで記述され、Probe Matchメッセージであることを示すタグ0402a、終端アドレス0402b、デバイスタイプ0402cなどを含む。デバイスタイプは、たとえばプリンタなど、デバイスの種類を示す。
<探索プロキシサーバ300の接続>
図2では、クライアントPC100とデバイス200の接続フローを示した。この図2の構成に加えて探索プロキシサーバ300を設置した場合の接続フローを図5を用いて説明する。
前述の通り、探索プロキシサーバ300が接続されたネットワークに参加するデバイス200は、探索プロキシサーバ300からデバイス要求メッセージ等を受信する。そのメッセージには、送信元がクライアントではなく、探索プロキシサーバ300であることを示す情報が含まれる。この情報は、探索プロキシサーバ300に対してあらかじめ与えられたID等の識別情報である。探索プロキシサーバ300から、探索プロキシサーバ300の識別情報を含むデバイス情報要求等のメッセージを受けたネットワークデバイス200は、参加したネットワークに探索プロキシサーバ300が存在すると判断できる。探索プロキシサーバ300がネットワークに存在する場合、デバイスはそのことをメモリ等に記憶しておく。さて、探索プロキシサーバ300が存在することを記憶したデバイス200は、クライアントPC100からデバイス探索のためのProbeメッセージを受信してもそれに対する応答処理を行わない。そして、デバイス探索手順は、以下の通り探索プロキシサーバ300とクライアントPC100との間で進行する。また、デバイス200は、デバイス200のデバイス情報およびサービス情報をプロキシサーバ300に対して送信する。
ステップ0501:
クライアントPC100よりデバイス探索要求メッセージ(Probe)0501が送信される。
ステップ0502:
プロキシサーバ300は、Helloメッセージ0502を発信する。クライアントPC100はプロキシサーバ300からのHelloメッセージ0502を受信する。デバイス200はデバイス探索要求メッセージ0501に対しては応答しない。
ステップ0503〜506:
クライアントPC100は、探索プロキシサーバ300から応答を受信して探索プロキシサーバ300の存在を認識した場合、以降のサービス探索メッセージは探索プロキシサーバ300へ発信する。
まず、クライアントPC100は、GetMetadataメッセージ0503を探索プロキシサーバ300に対して送信する(ステップ0503)。このGetMetadataメッセージには、例えば、「カラープリンタに関する情報」、「プロキシサーバ300が保持している全デバイス情報」、「ネットワーク上のいずれか3つのプリンタ」など、所定の指定情報が含まれている。探索プロキシサーバ300はGetMetadataメッセージ0503を受信したら、GetMetadataResponceメッセージ0504をクライアントに対して送信する(ステップ0504)。GetMetadataResponceメッセージ0504には探索プロキシサーバ300が保持している情報(たとえば共有度順位表)が含まれており、その情報もクライアントPC100へ送信される。このようにステップ0503、0504では、デバイス情報がクライアントに渡され、ステップ0505、0506ではサービス情報がクライアントに渡される。
以上のようにして、デバイスから直接クライアントに対してデバイス情報及びサービス情報は渡されず、探索プロキシサーバ300にキャッシュされたそれらの情報がクライアントに対して与えられる。
ステップ0507:
クライアントPC100は、ステップ0504またはステップ0506にて受信した情報に基づいてデバイスドライバのインストール処理を行う。なお、詳細は図2(A)のステップ207で説明したため省略する。
ステップ0508:
なお、他のメッセージには3者間でやり取りされるものがある。たとえば印刷要求メッセージはクライアントPC100からデバイス(プリンタ)200に直接送信される。デバイス200は印刷命令にしたがって印刷処理を実行する。また、途中でエラー等、処理を中断する事態が生ずれば、その旨のメッセージがデバイス200からクライアントPC100に送信される。プロキシサーバ300は、図6を参照して後で説明するように、クライアントからデバイスに対するメッセージをフックする。プロキシサーバ300はフックしたメッセージを数える。ここで単に数えるのではなく、デバイスごとのクライアントの数、デバイス及びサービスごとのクライアントの数、スコープ毎のクライアント数等、メッセージの属性ごとにメッセージ数を数える。
以上、探索プロキシサーバ300は、クライアントPC100によるサービス探索を容易にする。さらに、問い合わせ先が集約され、ネットワークトラフィックの低減や、デバイス側の処理の軽減が図られる。特にネットワークスコープ内に多数のサービスがある場合には、システムトラフィック低減に有効である。ここまで、クライアントとデバイスの基本接続、プロキシサーバ300が加えられた場合の接続について説明した。また、このようにプロキシサーバ300を用いることにより、クライアントPC100は、デバイス200の電源が切れている状態であっても、デバイス200の情報を受信することが可能である。
<プロキシサーバ300の制御の概要>
次に図6を参照して、本実施形態におけるプロキシサーバ300による制御の概要を説明する。プロキシサーバ300は、クライアントPC100からのメッセージ(例えばデバイス情報要求)に対して、ネットワークにおける共有度の高い(利用頻度の高い)デバイスおよびサービスを応答する。この応答に基づいて、クライアントPC100側には、共有度の高いサービスを利用するためのドライバやアプリケーションがセットアップされる。その結果、クライアントは自動インストールを実行する場合であっても、利用頻度が高く、必要になると予想されるデバイスのデバイスドライバを導入することが可能となる。また、プロキシサーバ300はデバイス200とクライアントPC100の個体識別と記録、識別結果をもとにした経路制御をおこなう。メッセージ交換の手順は図5に示したとおりであり、図6は探索プロキシサーバ300における処理も含めて説明する。
図6において、プロキシサーバ300によるMFP200を含めたデバイスの個体識別と記録について説明する。プロキシサーバ300はデバイスMFP200を対象として、(1)探索信号を送信する。この探索信号を受信したMFP200は、(2)応答信号をプロキシサーバ300に対して返信する(0601)。この0601の処理は、図2(A)のステップ0201とステップ0202に相当する。探索と応答の代わりに、図2(B)のネットワーク参加通知0208であってもよい。
次に図6のプロキシサーバ300は、デバイス情報および、そのサービス情報を取得するため、(3)情報取得要求をMFP200に対して送信する。情報取得要求を受信したMFP200は、デバイス情報およびサービス情報を(5)送付する(0602)。この0602の処理は、図2(A)のステップ0203〜ステップ0206あるいは図2(B)のステップ0209〜0212に相当する。また、情報取得要求を受信したMFP200は、(4)デバイスIDを特定する(0603)。この一連の処理0601から0603が実行されることでプロキシサーバ300は図3のメタデータ0301(デバイス情報)およびメタデータ0302(サービス情報)を参照し、デバイスの個体識別をおこなう。最終的には、プロキシサーバ300は、収集したデバイスIDおよび各デバイスIDに対応するデバイスの種類情報(デバイス情報)や提供サービス(サービス情報)をデバイスリストに保存する。デバイスリスト情報を図20に示す。図20のデバイスリスト情報には、各デバイスのID、アドレス情報、デバイスの種類、サービスとサービスのURIが保持されている。デバイスの個体識別とは、デバイス情報及びサービス情報の保存(登録)である。なお、登録の対象を図3に示したメタデータ全体としておけば、登録されたメタデータを、デバイス情報あるいはサービス情報を要求するクライアントにそのまま渡すことができる。その結果、クライアントは、デバイスから直接受信したメタデータと同様に処理できる。ただし、後述の通り本実施形態では、メタデータのデバイスのアドレス(URI)は、プロキシサーバ300によるフックのために変更されている。
次にプロキシサーバ300によるクライアントPC100の個体識別と記録について説明する。プロキシサーバ300はクライアントPC100に対して(7)探索要求を送信すると、クライアントPC100からの(8)応答信号を受信する(0605)。そして、プロキシサーバ300は、クライアントPC100に対して(9)情報取得要求を送信する。プロキシサーバ300からの情報取得要求に応じて、クライアントPC100は、クライアントPC100に関する情報を(10)送付する(0606)。この一連の処理0605、0606が実行されることでプロキシサーバ300はクライアントPC100の個体識別をおこなう。最終的には、プロキシサーバ300は、収集したクライアントのIDや各クライアントのアドレス等のクライアント情報をデータベース(クライアントリストという)に登録する。なお、クライアントリストの一例を図19に示す。プロキシサーバ300は、図19のように各クライアントのクライアントID、アドレス情報を記憶している。
さらに共有度の判定のために、プロキシサーバ300は、図5のステップ0508で送受信される他メッセージに含まれる情報を収集する。その目的で、プロキシサーバ300はネットワークアドレス変換をおこなう。このネットワークアドレス変換処理について説明する。通常は、GetMetaDataで機器の情報やサービスのアドレス(URI)がクライアントに開示される。以降、クライアントはそのアドレス(URI)に対してアクション(例えば印刷要求)を行う。しかし、後述する図9の共有度順位表0901を作成するためには、どのクライアントがどのデバイス(例えばプリンタ)を使って印刷処理をしているか等の情報をプロキシサーバ300が収集する必要がある。そのため、プロキシサーバ300は、クライアントからデバイスに対する要求メッセージを一旦引き込むためにアドレス(URI)の書き換えを行う。アドレス変換は、一連の処理0601〜0606のフローにおいて、プロキシサーバ300からクライアントPC100に送信するサービス情報等のメタデータに含まれるURIを差し替えることで行われる。アドレス変換処理はプロキシサーバ300により図6の処理0604で行われる。たとえば、プロキシサーバ300は、クライアントPC100からのデバイス情報要求(図5のステップ0503)に応じて、デバイスリストに登録されたデバイス情報を応答する。その際に、デバイス情報に含まれるデバイスのURIの上位に、プロキシサーバ300のURIを付加する。また、サービス情報についても同様に、デバイスのURIの上位にプロキシサーバ300のURIを付加する。図4の例では、サービス情報のURI0402dの上位にプロキシサーバ300のURIが付加される。なお、これらプロキシサーバ300のURIの付加は、クライアントがデバイスのアドレスとして用いるURIに対してのみ行われても良い。
アドレス変換されたメタデータを受信したクライアントは、印刷要求メッセージ等、図5のステップ0508におけるメッセージ送信のために、変換されたアドレス(プロキシサーバ300のURI)を使用する。そのため、クライアントPC100からのメッセージはプロキシサーバ300に到達する。プロキシサーバ300は、クライアントからメッセージ(メタデータ)に含まれたURIのうち、その上位にあるプロキシサーバ300のURIを取り除いてMFP200に転送する。この処理により、クライアントPC100からデバイス200に宛てられたメッセージはすべてプロキシサーバ300を経由することになる。プロキシサーバ300は、こうしてクライアントからデバイスに対するメッセージをフックする。なおアドレス変換は、上述したアドレスの追加および削除による方法以外に、対応表による変換、他の装置が管理しているアドレス変換機能を利用することでも実現できる。つまり、プロキシサーバ300は、端末から周辺機器へのメッセージを横取りする。この横取りしたメッセージ情報を用いてメッセージ数を数え、共有度を計数する。その計数結果を示す共有度情報は図9に後述する。
こうしてプロキシサーバ300は、基本的に0607の経路をとおるメッセージとメタデータ(図5のメッセージ0508)を参照することができる。なお、サーバ400がネットワークに接続されている場合、プロキシサーバ300は、サーバ400により提供されるディレクトリサービス500や管理ユーティリティ600と必要な情報を送受する。プローブマッチのメタデータ内にもスコープ情報があるが、プロキシサーバ300がディレクトリ情報を必要とする場合はディレクトリサービス500と、図6のステップ0610で送受する。管理ユーティリティ600とプロキシサーバ300が情報共有する場合には、管理ユーティリティ600とステップ0611で送受をおこなう。
<プロキシサーバ300の内部構成>
システムの主構成と制御の説明に続き、図7を用いてプロキシサーバ300の内部構成を説明する。プロキシサーバ300は、通信部0701、フロー部0702、管理部0703の3層構造を有する。通信部0701には、クライアント、サーバ、デバイスそれぞれへ接続するためのクライアント接続部0704、サーバ接続部0705、デバイス接続部0706が備えられている。
フロー部0702は、フロー制御を処理するためアドレス変換部0707や入出力部0708を備え、図6で説明したアドレス変換や入出力制御をおこなう。管理部0703は、データを記録するデータ格納部0710、設定操作部0711、通信と制御の具体的な処理を決定する判断部0709等が備えられている。データ格納部0710には、前述のデバイスやクライアントの識別結果(デバイスリスト11aおよびクライアントリストを含む)710aなどが記録されている。このほか、アドレス変換表710b、後述するプロキシ操作設定710c、実績テーブル710d、共有度順位表0901(図7には示さず)などが記録されている。設定操作部0711は、プロキシサーバ300の動作を変更するためのUI(ユーザインターフェース)や、操作結果をデータ格納部0710に反映するための処理を提供する。判断部0709は、プロキシサーバ300設定や、入力、実績を含むデータ格納部0710を基準に、デバイスの共有度等に関する判断をおこなう。判断結果は出力としてフロー部0702、通信部0701を通じ、プロキシサーバ300の外部にも送信される。
また、通信部0701、フロー部0702、管理部0703のそれぞれは、拡張部分0712〜0714をもつ。この拡張部分0712〜0714により、例えば図5の他のメッセージ0508に対応する処理(拡張処理)を行うと、基本処理と拡張処理の独立性が向上し、拡張処理内容の変更や付加、削除が容易となる。この拡張部分0712〜0714へ、処理の内部集約、内部置換(差し替え)、外部接続といった手段が採用できることが理由である。
以上、プロキシサーバ300は図7に記載した内部構成を持つため、通信系と管理系の分離配置が可能となっている。プロキシサーバ300と前述の管理ユーティリティ600との連携動作時は、プロキシサーバ300をフロー部0702と管理部0703間のI/Fで分離し、管理部0703の機能を管理ユーティリティ600
に集約する構成も実施できる。
続いて、図23を用いてプロキシサーバ300の本願における処理の概要を説明する。なお、図23に記載のフローチャートにおける各ステップの処理はプロキシサーバ300のCPUによって処理される。また、プロキシサーバ300は、周辺機器(単にデバイスとも呼ぶ。)および端末(クライアントとも呼ぶ。)と通信可能な情報処理装置ある。
プロキシサーバ300は、ネットワークに対して図6の処理0601および処理0605にて記述したデバイス探索要求を発信し、デバイスまたはクライアントからの応答を待機する。プロキシサーバ300は、クライアントおよびデバイスからの応答を受信すると、応答情報に基づいてデバイス情報を要求する。プロキシサーバ300は、応答されたデバイス情報に基づいてデバイスリストおよびクライアントリストを生成する(S2301)。プロキシサーバ300は、こうしてS2301により周辺機器から周辺機器に関する情報を受信して保存する。
プロキシサーバ300は、クライアントとデバイスの通信情報、または、クライアントとプロキシサーバ300の通信情報に基づいて共有度順位情報を生成する(S2302)。
S2302の処理の一例を簡単に説明すると、プロキシサーバ300は、クライアントおよびデバイス間において送受信されているメッセージ情報をデバイス毎に数える。そして、メッセージ情報を数えることにより得られる周辺機器毎の共有度を計数して、共有度情報を生成する。または、クライアントからプロキシサーバ300に対して送信される情報を用いて計数することもある。なお、S2302の処理は、ネットワークが通常の稼働状態にある間にプロキシサーバ300により実行される。S2302の詳細は、図17および図8を用いて後述する。
プロキシサーバ300は、クライアントからデバイス情報要求を受信したか否かを判定する(S2303)。詳細には、プロキシサーバ300が、クライアントから、プロキシサーバ300のメモリにて保持されている周辺機器に関する情報を要求する要求メッセージを受信したか否かを判定する。プロキシサーバ300は、クライアントからプロキシサーバ300のメモリにて保持されている周辺機器に関する情報を要求する要求メッセージ(デバイス情報要求)を受信する。そのメッセージを受信したプロキシサーバ300は、S2302により計数された周辺機器毎の共有度に従って選択された周辺機器に関する情報を、クライアントに送信する(S2304)。つまり、プロキシサーバ300は、作成された共有度順位情報を用いて送信すべき周辺機器に関する情報を選択する。
プロキシサーバ300には、クライアントに送信すべきデバイスを選択するための条件が設定されている。例えば、共有度情報の上位3つのデバイスに関する情報を送信するなどが挙げられる。このプロキシサーバ300に設定されている条件に基づいて送信すべきデバイス情報を決定する。
なお、クライアントからデバイス要求を受信した場合、プロキシサーバ300は、クライアントから受信したデバイス情報要求に含まれる情報が共有度情報を送信する条件に一致するか否かを判定してもよい。ここで、プロキシサーバ300が共有度情報を送信すると判定する場合の条件について説明する。1つ目は、クライアントのデバイス情報要求に共有度情報を取得したいとの情報が含まれているか否かである。2つ目は、クライアントが、初めてデバイス情報要求を送信したか否かである。プロキシサーバ300は、各クライアントからのデバイス情報要求を管理しているため、例えば、いつ、どのクライアントがどういった内容のデバイス情報要求を送信してきたかを管理している。つまり、プロキシサーバ300が、S2303にて受信したデバイス情報要求の送信元のクライアント情報を管理していなければ、そのクライアントは初めてデバイス情報要求を送信したと判定できる。なお、共有度情報を送信する条件として2つの例を挙げたがこれに限定される必要はない。
図23の処理により、たとえば、利用される可能性が高いデバイスのデバイスドライバあるいはそのデバイスに対応したアプリケーションプログラム等を、選択的にクライアントコンピュータがインストール可能な情報処理装置を提供できる。
<プロキシサーバ300による集計処理>
プロキシサーバ300、詳細にはプロキシサーバ300のCPU1は、受信したメッセージに含まれる情報を集計する。集計は例えば以下の項目を対象として行われる。
(1)各デバイスにアクセスしたクライアント数。つまり、プロキシサーバ300は、端末から周辺機器へのメッセージを受信し、受信したメッセージの宛先および送信元情報に基づいて、周辺機器毎に、送信元となった端末数を数える。端末数は、該当するメッセージの数を数えることでカウントされる。そしてプロキシサーバ300は、周辺機器に対して、数えられた端末数を関連づけ、端末数をキーとして整列した順位を共有度の順位とする共有度順位情報を作成する。
(2)サービス毎のクライアント別のメッセージ数。すなわち、宛先のサービスID(あるいはサービスのURI)と送信元のクライアントID(あるいはアドレス)とを一組の径路情報と考えた場合における、各径路のメッセージ数である。つまり、プロキシサーバ300は、受信したメッセージの宛先情報に基づいて、周辺機器毎にメッセージ数を数える。そして、プロキシサーバ300は、数えられた周辺機器毎のメッセージ数を周辺機器毎に関連づけ、メッセージ数をキーとして整列した順位を共有度の順位とする。
(3)デバイス毎の受信データ量および送信データ量。データ量は、本例ではメッセージの数である。したがって、データ量は、(2)のサービス毎のクライアント別メッセージ数を、着目デバイスについて加算しても得られる。
(4)スコープ毎のメッセージ数。つまりプロキシサーバ300は、受信したメッセージの宛先および送信元情報に基づいて、周辺機器と同一のネットワーク上の範囲に属する送信元の端末の数を数える。スコープはメタデータ中に記述されており、ネットワークにおける範囲を示す。たとえばクライアントIDを列挙したり、あるいは、階層的に記述されたアドレスの一部(特に上位)を記述するなどしてスコープを表すことができる。本例では、デバイスの属するスコープに隣接するスコープのクライアントからも、そのデバイスにアクセスすることができるが、デバイスと同一のスコープに属するクライアントからアクセスされた場合、ローカルユーザ数の項目914をカウントする。デバイスと同一のスコープに属するクライアントをローカルクライアントと呼ぶ。プロキシサーバ300は、同一のネットワーク上の範囲内に属する送信元の端末数を周辺機器毎に関連づけ、該端末数をキーとして整列した順位を共有度の順位とする。なお、以上の項目以外にも必要に応じて種々の情報を集計することができる。
図17に、図23のステップS2302においてプロキシサーバ300が実行する処理の一例を示す。図17は、プロキシサーバ300が、クライアントおよびデバイス間において送受信されているメッセージ情報をデバイス毎に数える手順である。図17においてプロキシサーバ300は、フックしたメッセージを数える。図17の例では、カウントしているのは(1)のデバイス毎のクライアント数と、(2)のデバイス毎のサービスおよびクライアント別メッセージ数と、(4)のスコープ毎のクライアント別メッセージ数である。(3)のデバイス毎のメッセージ数は、デバイスの共有度表を作成する際に、(1)のデバイス毎のクライアント別メッセージ数から算出される。なお、図17の各ステップの処理はプロキシサーバ300が備えるCPUによって実行される。
図17では、プロキシサーバ300は、フックしたメッセージからデバイスIDおよびサービスのURIおよびクライアントのIDを読む(S1701)。次にプロキシサーバ300は、読み取ったデバイスIDおよびサービスURIおよびクライアントIDの組に対応するカウンタ(サービスごとのクライアント別カウンタという。)が登録されているか判定する(S1702)。プロキシサーバ300により登録済みか否かが判定されるカウンタはプロキシサーバ300のRAMに登録されているため、プロキシサーバ300がRAMを参照することによりS1702の処理は可能となる。
プロキシサーバ300は、S1702の判定の結果、カウンタが登録されていればそのデバイスIDおよびサービスURIおよびクライアントIDの組に対応するメッセージカウンタに1を加算する(S1704)。一方、登録されていないと判定された場合、プロキシサーバ300は、読み取ったデバイスIDおよびサービスURIおよびクライアントIDの組に対応するメッセージカウンタを新たに設け、そのメッセージカウンタに1をセットする(S1703)。また、プロキシサーバ300は、デバイスごとのクライアント数のカウンタにも、初めてのクライアントであれば1を加算する(S1705)。そして、そのクライアントのIDを、重複の排除のために記録しておく。
次にプロキシサーバ300は、メッセージからスコープを読み取る(S1706)。読み取ったスコープに対応するメッセージカウンタが登録されているか判定し(S1707)、登録されていればそのメッセージカウンタに1を加算する(S1709)。一方、登録されていなければ、プロキシサーバ300は、読み取ったスコープに対応するメッセージカウンタを新たに設け、そのメッセージカウンタに1をセットする(S1708)。
<共有プリンタの判断>
プロキシサーバ300の管理部0703にある判断部0709により実施される、プリンタ等のネットワークデバイスの共有度の判定について、図8を参照して説明する。図8はデバイスの評価手順を示す概略図であり、具体的にはデバイスの共有度順位表の作成手順を示す。つまり、図8は、図23のステップS2302において、プロキシサーバ300がクライアントPC100からデバイス情報要求を受信した際に、その応答送信前に実行される。また図9(A)に作成される順位表の例を示す。処理手順中、ステップS0801、ステップS0802が主たる判断であり、これにステップS0803が加えられている。ステップS0804はオプション、ステップS0805は補助的な条件である。
まずプロキシサーバ300の判断部は、デバイスリストに登録された各デバイスについてステップS0801〜S0805の評価を行い、最後にステップS0806でデバイス共有度順位表をソートする。これが作成手段に相当する。
ステップS0801では第1の判定基準にしたがって評価を行う。第1の判定基準は、ネットワークで公開されているか否かである。判断部は、デバイス共有度順位表のうち着目デバイス(たとえばMFP200)に対してOSの共有設定がなされているかを判定する。この判定基準は、ステップ0610に示したとおり、ディレクトリサービス0500より得た共有情報に基づく情報である。ディレクトリサービス0500がたとえばアクティブディレクトリであるなら、そこから、ADSI(Active Directory Service Interface)経由でデバイスが共有設定されているか否かを示す共有情報を取得できる。共有設定されていると判断されれば、プロキシサーバ300は、共有設定されているデバイスのデバイスID(図9(A)のデバイスID0911)を、デバイス共有度順位表に登録する。したがって本実施形態では共有設定されていないデバイスは、共有度順位表に登録されず、クライアントによるデバイス探索では見つけられない。これは、一般に共有設定されていないデバイスを、不特定の利用者により利用させるのは適当ではないからである。
なおアクティブディレクトリより、ネットワーク環境のクライアント数、デバイス数など、ネットワークの規模についての情報も得られる。ステップ0801では、ディレクトリサービスからこれらの情報をまず取得する。ネットワークの規模を示す情報は、ネットワークの大小の判断の基準となる。
ステップS0802では、プロキシサーバ300が、第2の判定基準にしたがって評価を行う。第2の判定基準は、サービスが多数のクライアントから接続(アクセス)されているか否かである。プロキシサーバ300は、着目デバイスにより提供されるサービス(着目サービス)に対して、クライアントからの接続数"N"が多い状態を共有度が高いと判断する。着目デバイス(たとえばMFP200)とクライアントPC100は処理0601〜0606を通して個体識別されている。この過程で参照されるメタデータ0401からサービスおよびスコープ情報が得られる。またネットワーク規模(構成)の情報は、ディレクトリサーバからステップ0610において入手できる。着目デバイス(たとえばMFP200)の着目サービスへの接続は、サービスのアドレス(URI)で特定される。したがって、プロキシサーバ300は、着目サービスのURIを指定した接続要求(たとえば印刷要求)メッセージの数を、識別済みである各クライアントの重複を排除してカウントすることで、クライアント数"N"(すなわち接続数)を求めることができる。重複を排除するためには、受信したメッセージに記録された送信元のクライアントの識別情報(IDやアドレス)が記憶されているか否かを判断し、記憶されていなければ記憶する。そして、同時にクライアント数Nに1を加算する。その数Nが、サービスが多数のクライアントから接続されていることの程度を示す値となるので、デバイス毎のNを図9(A)の接続先数0912として順位表に登録する。
なお、クライアント数そのものではなく、ネットワークに接続されたクライアント数のうちの割合を共有度表に登録しても良い。すなわち、ネットワークに接続されたクライアント数を分母とし、着目デバイスの持つ特定のサービスを利用したクライアントの数を分子とした割合を求め、その値に基づいて共有度を計算しても良い。
ステップS0803では、プロキシサーバ300が、第3の判定基準にしたがって評価を行う。第3の判定基準は、サービスの利用総量が多いか否かである。すなわちネットワークで公開されたデバイスであり、かつ、多数のクライアントから利用されている上で、着目デバイスの提供するサービスに対するクライアントからの総アクセス数"n"が多いデバイスほど、共有度の高いデバイスと判断される。着目デバイスの提供サービスに対する総アクセス数は、プロキシサーバ300がフックしたメッセージの数を、デバイスごとにカウントすることで得られる。これは図17のステップS1705でカウントされる値を、着目デバイスについて加算した値に相当する。ステップS0803では、この値をデバイスIDに対応付けてデータ量0913として共有度順位表0901に登録する。
ステップS0804では、プロキシサーバ300が、第4の判定基準にしたがって評価を行う。第4の判定基準(S0804)は、クライアントが指定したデバイスとメッセージ送信元のクライアントが同一スコープ内にあるか否かを判定する処理である。ここで、同一スコープ内のクライアントから宛先指定されたデバイスについて、カウント処理を実行する。ここで、カウント数が多いデバイスは、同一スコープ内のユーザの利用頻度が高いデバイスである。ここで、例えば新規に同一スコープ内に接続したクライアントに対しては、カウント値の高いデバイスを推奨するようにしても構わない。このカウンタ値は、デバイスの共有度順位表901のローカルユーザ数0914として登録される。
ステップS0805では、プロキシサーバ300が、第5の判定基準にしたがって評価を行う。第5の判定基準は、デバイスの能力が高く、搭載しているサービス数が多いというものである。デバイスが高機能であるかは、着目デバイス(たとえばMFP200)のメタデータ、特にデバイス情報に基づいて判断される。このデバイス能力レベルのデータは、最低レベルをあらかじめカットするため、他条件が同点のケースでの最終順位決めといった補助的な目的のために利用される。能力値は例えば、提供するサービスの数であったり、あるいは、着目デバイスがプリンタであれば単位時間あたりの印刷ページ数である。例えば、プロキシサーバ300に10ppm(1分あたりの印刷ページ数)以下のプリンタはカウントしないと設定されていた場合、10ppm以上のプリンタについては能力値0915の項目を更新しない。一方、10ppm以上のプリンタについては能力値0915の項目の値を更新する処理が行われる。この値が共有度順位表0901の能力値0915として登録される。
以上の手順を各デバイスについて実行することで、図9に例示するデバイス共有度順位表が完成する。プロキシサーバ300には、担当するスコープが割り当てられており、プロキシサーバ300は、担当スコープ内の各デバイスについて、上述の図8の手順を実行する。この図9の共有度順位表を、各項目毎に優先順位を付してソートすることで、デバイスIDがその共有度順にソートされる。本例では、図9(A)の項目0912−0915をキーとし、その優先順位をソートする。優先順位を付してソートするとは、第1のキーでソートした後、同順にある項目を第2のキーでソートする、というように、優先順位の高いキーで先後が付かない場合に、優先順位の低いキーで順位を付けることをいう。
なお、共有度順位はその他の項目を用いて作成することもできる。図9(B)は、その一例を示す。図9(B)の例では、デバイスの共有度順位表0901に、接続先数、探索数、情報請求数(デバイス情報要求メッセージの数)、データ量/月(1突き当たりのメッセージ数)、初回接続日時、最終接続日時、サービス数が、この順で登録される。接続先数は、接続先のクライアント数である。そして各項目をキーとして、この優先順位でソートすることで、デバイスIDが共有度順位に応じてソートされる。図8のように優先すべき項目情報に基づいて共有度順位を特定するので、クライアントは、より利便性の高いデバイスを優先的にインストール(導入)することが可能となる。
それでは次に、順位表のどこまでのデバイス、サービスをクライアントPC100に通知するかについて説明する。
<クライアントへの列挙順序>
図10はクライアントPC100が表示するUIの一例である。プロキシサーバ300は、クライアントから受信したデバイス情報要求に対して、ソートしたデバイス共有度順位表のうち、上位の一定数のデバイスについて、それらが共有度順位が高いことを示す情報と共に、デバイス情報をクライアントに返す。なおこの上位の一定数は固定されているとは限らない。デバイス情報応答を受信したクライアントでは、たとえばドライバインストーラが図5のステップS0507において図10のユーザインターフェースを表示する。またはアプリケーションが表示してもよい。
さて、ドライバインストーラは、図5のステップ0507において、図10に示すプリンタのセットアップ開始ダイアログ1001を表示する。その中の機種リスト1002は次の順序で列挙されている。すなわち、図8の手順で作成されたデバイス共有度順位表を、クライアント数、サービスの利用量、ローカルユーザ数、能力値をキーとして、この優先順序でソートした順序で、デバイスIDが列挙される。こうして共有度の高い順にデバイスが列挙される。さらに、新しいデバイスや利用実績のあるデバイスについてもデバイスリストの末尾に列挙する。もちろんこれらデバイスも共有度に応じた順序で列挙しても良い。
以上をまとめると、クライアントPC100は、プロキシサーバ300から受信したデバイス情報要求に基づき、以下の順序でデバイスのリストを表示する。
(a)共有度の高い順。
(b)新しいデバイスや利用実績があるデバイス。これらデバイスは(a)の後クライアントへ返答される。
(c)共有度がある一定の順位よりも低いデバイスはリストに表示されない。
共有度がある一定の順位よりも低いデバイスとは、たとえばプロキシサーバ300が判定する。プロキシサーバ300は、デバイス共有度順位表に基づいて、その下位の一定数のデバイスを共有度が一定の順位よりも低いデバイスであると判定し、これらデバイスのデバイス情報をクライアントに返信しない。
そして、クライアントPC100では、上記(a)(b)の規則にしたがった順序でリストされたデバイスのうち、上位所定数のデバイスについては、あらかじめドライバをインストールする対象として選択しておく。具体的には、デバイス毎にドライバをインストールするか否かを示す選択フラグをRAM等に設け、該当するデバイスに関してはそのフラグをセットしておく。ユーザインターフェースであるダイアログ1001の上では、チェックボックス1003が選択された状態で表示される。図10では上位4つのデバイスが、インストール対象として選択されている。ユーザがダイアログ1001の「次へ」ボタンをおすと、ユーザインターフェースから、プラグアンドプレイコントローラ0111に、選択フラグがセットされたデバイスのデバイス情報が通知される。通知をうけたプラグアンドプレイコントローラ0111は、メモリコントローラを介してデバイス属性情報に一致するドライバを記憶装置上より検索し、該当するドライバのインストールを実行する。
図11がプロキシサーバ300による列挙制御のフロー図である。まずステップ1102でプロキシサーバ300が、デバイス情報要求メッセージの発行元クライアントを特定する。すなわち、プロキシサーバ300が、デバイス要求メッセージの送信元のアドレスあるいはクライアントIDを読み取る。ステップ1103でプロキシサーバ300は、応答の設定(後述)を読み取る。またステップ1104では、プロキシサーバ300が、たとえば共有度順位表のソートを前述のように行って、ステップ1105〜ステップ1110のデバイスの列挙順を確定する。
プロキシサーバ300が、応答の設定に応じて実績データ(すなわち共有度順位表)より順序づけられた共有度の高いデバイスがあると判定した場合(ステップ1105−Y)、ステップ1106にて共有度の高い順にデバイスを列挙する。「列挙する」とは、順序(たとえば共有度順位順)に従ってデバイス情報をクライアントに送信することを意味している。また、共有度の高い低いの判断は上述した通り、予め上位いくつまでのデバイスが共有度が高いと判定するようにプロキシサーバ300に設定されているので、その設定情報を用いて、共有度の高いデバイスを特定できる。デバイスリストにはデバイス情報およびサービス情報がデバイスIDに関連付けられて保存されているから、共有度の高いデバイスのデバイス情報及びサービス情報をデバイスリストから選ぶことは容易である。
次に、プロキシサーバ300が、ネットワーク上に新しいデバイスを発見した場合(ステップ1107―Y)、ステップ1108にて新しい順にデバイスを列挙する。プロキシサーバ300は、Helloメッセージあるいは探索メッセージに対する初めての応答を受信した日時と送信元のデバイスIDとを関連づけて記録しておく。そして、ステップ1107の処理時において、その記録した日時と現在日時とが一定期間内に納まっていれば、関連づけたデバイスを新しいデバイスと判定する。記録した日時と現在日時との時間差が短いほど、より新しいデバイスであると判定できる。つまり、プロキシサーバ300は、周辺機器毎に、接続された日時を関連づけ、日時をキーとして整列した順位を共有度の順位とする。
さらに、プロキシサーバ300は、クライアントによる利用実績が記録されているデバイスがあるか否かを判定し(ステップ1109)、利用実績が記録されたデバイスがあると判定された場合、ステップ1110にて利用実績が新しい順にデバイスを列挙する。なお、ステップ1110では利用実績の高い順にデバイスを列挙してもよい。利用実績は、前述の通りクライアントから通知されるメッセージの数をデバイス毎に数えて利用実績と見なすことができる。
以上の手順で、プロキシサーバ300は、デバイス情報要求メッセージ対して、デバイスの共有度順位等に応じた順序でデバイス情報応答メッセージを返すことができる。また、ステップ1107の処理を実行することにより、新たにネットワークに参加したために利用実績値が少ないデバイスであっても、クライアントに対して推奨することが可能となる。このように、プロキシサーバ300は、共有順位表の情報だけでなく複数の観点から推奨すべきプリンタを選択している。
<クライアントへの応答の設定>
図11のステップ1103では応答レベルの設定を読み込んでいる。プロキシサーバ300、あるいはプロキシサーバ300の管理部0703を集約した管理ユーティリティ600の設定操作部0711よりクライアントへの応答レベルについての設定がおこなえる。応答レベルの設定には次の方法がある。これら方法は、プロキシサーバ300においていずれかを固定的に実施しても良いし、あるいは、利用者によりいずれかの方法を選択させても良い。
(1)段階表現:
共有度1〜3の3段階で表される段階表現を用いて応答レベルを利用者が設定する。なおこの段数は拡張可能である。設定操作部0711は、低、中、高の3段階で移動可能なスライダを含むユーザインターフェースを表示する。利用者はスライダを所望位置に移動して応答レベルを設定する。設定された応答レベルはハードディスクやメモリの所定アドレスに保存される。図11のステップ1103では、設定された応答レベルが読まれ、「低」「中」「高」の何れであるかが判定される。
プロキシサーバ300は図11のステップ1104でスコープ内の各デバイスへのクライアント接続数において上位のデバイスからソートする(これは前述の通り)。そして、応答レベルとして「高」が指定されている場合には、接続数の分布にギャップがみられる箇所をみつける。すなわち、ソートされた共有度順位表において、互いに隣接する順位のデバイスについて、接続数の差を計算する。接続数の差が最大の箇所を「中」と「高」の境界とする。したがって、応答レベルとして「高」が指定されている場合には、この境界より上位にあるデバイスのデバイス情報を、ステップ1106でクライアントに応答する。
また、応答レベルとして「中」が指定されている場合には、クライアント接続数が少ないデバイスをカットする。たとえば、接続数0〜3のデバイスについては、ステップ1106においてデバイス情報として応答しない。
また応答レベルとして「低」が指定されている場合には、共有度順位表に登録されたデバイスすべてについてデバイス情報をクライアントに応答する。この場合には、新しいデバイスや使用実績のあるデバイスのデバイス情報もステップ1106で応答されるので、ステップ1107以下はスキップすることができる。
(2)順位表:
第2の方法では順位表を利用する。設定操作部0711はソートした共有度順位表を表示(たとえばデバイスの名称など)し、クライアントに応答する境界線(ボーダーライン)を利用者に指定させる。図12はプロキシサーバ300により表示される順位表を利用したUIの一例である。プロキシサーバ300は順位表1201を表示し、利用者はスライダ1202を用いて境界線を移動させる。境界線より上にあるデバイスが、デバイス情報要求に対してデバイス情報が応答される対象となるデバイスである。この方法では、いったん指定されたデバイスのデバイスIDを応答レベルとしてプロキシサーバ300が記憶し、応答レベル以上のデバイスのデバイス情報をデバイス情報要求に対して応答する。図12の例では、共有度順位5と認識されたデバイスが境界として指定されたので、このデバイスよりも共有度の高いデバイスのデバイス情報がクライアントに通知される。あるいは、対象として指定されたデバイスの数を応答レベルとして記憶し、最新の共有度順位表の上位から記憶した数のデバイスを選択して、デバイス情報応答の対象とする。つまり、図12の例では、上位5つのデバイス情報がクライアントに対して通知される。あるいは、選択された対象の最下位にあるデバイスIDを応答レベルとして記憶しておき、最新の共有度順位表の上位から記憶したデバイスIDまでを選択して、デバイス情報応答の対象とする。これらのうちいずれかの方法で選択されたデバイス情報がステップ1106でクライアントに送信される。
(3)個数表現:
第3の方法はデバイスの数を直接指定する方法である。設定操作部0711は、スピンボックスを表示する。利用者は表示されたスピンボックスから数値を入力する。その通知がメモリ等に応答レベルとして記憶される。UIは図12のスライダ1202をスピンボックスに変更したものになる。図11のステップ1103では記憶された数値を読み、ステップ1106では共有度順位表の上位から指定された数のデバイスに付いて、デバイス情報を応答する。例えば、通知個数として4を選択した場合、共有度順位において上位4つのデバイス情報がクライアントに通知される。
以上説明した、クライアント、デバイス、プロキシサーバ300の三者によるメッセージ交換の手順の一例を図18にまとめた。図18において、各装置の処理は、それぞれのCPUによりプログラムをじっこうすることで制御されている。
図18において、プロキシサーバ300によるデバイス探索要求1801の送信に対してデバイス200が応答1802を返す。さらにプロキシサーバ300によるデバイス情報要求1803の送信に対してデバイス200はデバイス情報1804を応答する。この際に、デバイスIDが固定されていないのであれば、デバイス情報の送信前にデバイス200はデバイスIDを決定しておく。デバイス探索要求の送信先はクライアントPC100も指定されている。そこでクライアントPC100は応答1822をプロキシサーバ300に返す。プロキシサーバ300は、さらに詳細な情報をクライアントに要求することもできるが、本例ではクライアントについてはその存在とそのアドレスやIDを得られれば十分として、プロキシサーバ300はこれ以上の情報を要求しない。なお、プロキシサーバ300が、クライアントやデバイスからネットワーク参加通知(Hello)メッセージを受信した場合、デバイスに対してはプロキシサーバ300からデバイス情報要求が送信される。
さて、クライアントが発行したデバイス探索要求1805を受信したプロキシサーバ300は、送信元のURIをプロキシサーバ300のURIに差し替えてクライアントPC100に対して応答1806を送信する。そのため、クライアントPC100は、デバイス情報要求を送信する場合、応答1806にて記述されたプロキシサーバ300のURIを用いてデバイス情報要求1807を送信する。プロキシサーバ300はデバイス情報要求1807を受信すると、保持している共有度順位情報に基づきデバイスを検索して推奨すべきデバイスを特定し(1807a)、特定されたデバイス情報1808をクライアントに対して応答する。プロキシサーバ300が、クライアントPC100に対して送信するデバイス情報を図22に示す。図20が、プロキシサーバ300が保持するデバイスリストであり、共有度順位情報を用いてソートした結果が図21である。つまり、プロキシサーバ300はデバイス200から205の6個のデバイスについてのデバイス情報を保持している。この状態において、クライアントからデバイス情報要求を受信した場合、プロキシサーバ300は送信すべきデバイス情報を特定して、クライアントに通知する。例えば、プロキシサーバ300に対して上位3つのデバイス情報を通知することが設定されている場合、プロキシサーバ300は、図22のように上位3つのデバイス情報を通知する。この際、デバイス情報のアドレス情報には、デバイスのアドレス情報に対してプロキシサーバ300のアドレス情報が付加されている。つまり、プロキシサーバ300は、端末および周辺機器間において送受信されるメッセージを横取りして受信する。そのため、端末からの問い合わせメッセージに応じて周辺機器に関する情報を送信する場合、情報処理装置の宛先情報を付加した応答情報を端末に送信する。よって、図22のデバイス情報を受信したクライアントが、例えば印刷処理を実行する場合、印刷データの送信先情報には選択したデバイスのアドレス情報とプロキシサーバ300のアドレス情報が含まれている。そのため、クライアントとデバイス間のメッセージは、プロキシサーバ300を経由するようになる。このとき、デバイス情報は、図11に示した手順でプロキシサーバ300からクライアントPC100に送信される。図18では省略したが、サービス情報要求及び応答も、プロキシサーバ300とクライアントPC100との間で交換される。クライアントでは、受信したデバイス情報を元にデバイスドライバのインストーラが実行される。つまり、クライアントが、インストール処理を実行する場合、図10に例示したユーザインターフェースが表示され、ここで利用者が選択したデバイスについて、デバイスドライバがインストールされて利用可能となる。
デバイス情報及びサービス情報を獲得したクライアントPC100は、アプリケーションプログラムの印刷要求等に応じて、印刷要求(命令)メッセージ1809を送信する。このメッセージの宛先は、応答1806により通知されたアドレスである。すなわち、プロキシサーバ300により差し替えられたプロキシサーバ300のアドレスに対して送信される。それを受信(フック)したプロキシサーバ300は、送信先URIをデバイスのURIに書き替えて(1810)、図8に示す手順でメッセージをカウントして、図9に示す共有度順位情報を更新する(1811)。その後、プロキシサーバ300は、受信したメッセージを本来の受け手であるデバイスに対して転送する(1812)。差し替えられたメッセージの送信先URIには、プロキシサーバ300のURIとデバイスのURIとがセミコロンで区切るなどして記述されているので、本来の送信先は、送信先URIからプロキシサーバ300のURIを削除することで得られる。デバイス200は受信したメッセージに対して応答メッセージ1813を返信する。このようにして印刷等のメッセージがクライアントからデバイスに送信される。
さて、クライアント(これは上記手順に関わったクライアントと異なるものであっても良い。)が、再度デバイス探索要求1814をプロキシサーバ300に送信すると、プロキシサーバ300は図11の手順で応答するデバイスを検索し、検索されたデバイスのデバイス情報1816をクライアントへ返す。これはステップ1807,1808と同様である。
上記手順により本実施形態のネットワークシステムでは、プロキシサーバ300がネットワークデバイスのデバイス情報を管理している。そしてクライアントからのデバイス情報要求に対して、共有度の高いデバイスのデバイス情報を応答する。また、共有度が高くなくとも、新たに接続されたデバイスのデバイス情報を応答する。また、共有度が高くなくとも、利用実績の高いデバイスのデバイス情報を応答する。これにより、クライアントは、ネットワークに接続された多数のネットワークデバイスの全てではなく、利用する可能性の高いデバイスに限定してそのデバイス情報を取得できる。このため、クライアントにインストールされるデバイスドライバの数も絞られるので、クライアントコンピュータの資源を節約できる。また、利用者が使用するデバイスを選択する際に、候補があらかじめ絞られることから選択しやすいという効果が得られる。
また、第1実施例では、クライアントとデバイス間のメッセージをプロキシサーバ300がフックすることにより図9の共有度順位情報を作成していたが、それに限る必要はない。例えば、クライアントは、プロキシサーバ300が接続されていることを認識すると、プロキシサーバ300に対してデバイス情報要求処理(GetMetaData)を実行する。ここで、クライアントが特定のデバイスを指定してデバイス情報を要求することも考えられる。この時、どのクライアントがどのデバイスを特定してデバイス情報要求をしたかをプロキシサーバ300が管理することにより、図9の共有度順位情報を生成しても良い。一例としては、クライアントAがプロキシサーバ300に対して、デバイス200の情報取得要求を行った場合、プロキシサーバ300が保持するデバイス200の情報をクライアントに通知する。それと共に、クライアントAがデバイス200の情報に対して取得要求をしたことをカウントする。このカウント情報を蓄積することで図9のデバイス共有度情報を生成しても良い。
第1実施形態により、プロキシサーバ300はネットワークに接続されている膨大な数のデバイスから利用する可能性の高いデバイスを選択して、クライアントに通知する。よって、クライアントは、多くのデバイスドライバをインストールすることにより発生するメモリの浪費やユーザによる誤操作等を防止することが可能となる。
第1実施形態により、複数のネットワークデバイスが接続されたネットワークにコンピュータを接続した場合でも、コンピュータにインストールされるデバイスドライバ等のプログラムの数を制限することできる。さらに、インストールされるプログラムを、対応するデバイスの共有度にしたがって選択することで、利用される可能性の高いデバイスに絞ることができ、ユーザの利便性を一層向上させることができる。
なお、プロキシサーバ300は、周辺機器に関する機能情報を要求するデバイス情報要求メッセージを数え、その数に応じてデバイスの優先度順位表を作成してもよい。
[第2実施形態]
第1実施形態のとおりプロキシサーバ300、あるいはプロキシサーバ300の管理部0703を集約した管理ユーティリティ600の設定操作部0711でクライアントへの応答が設定できる。この設定方法として、前述したクライアントに表示されるプリンタのセットアップ開始ダイアログ1001と同じUIを使うことも可能である。
図13が、プロキシサーバ300の設定操作部0711により表示されるダイアログ1301である。ITマネージャ(プロキシサーバ300の管理者)は、ダイアログ1301に表示されたデバイス名のリストから、クライアントへデバイス情報を応答するデバイスを選択する(チェックボックスをONにする)。チェックの内容を示す情報はプロキシサーバ300に記憶され、デバイス情報とともにクライアントPC100へと送信される。クライアントがデバイス情報を受信すると、デバイスドライバのインストール時にデバイス名のリストが図10のように表示される。その際、プロキシサーバ300から受信した選択状態を示す情報にしたがって、図13のユーザインターフェースで選択されていたデバイスと同じデバイスが選択された状態で図10のユーザインターフェースが表示される。
この結果、プロキシサーバ300において、ITマネージャが共有度の高いプリンタを固定で設定することができる。また、クライアントの利用者は、ITマネージャによる設定に拘束されずに、インストールするデバイスドライバを選択し直すこともできる。このため、第1実施形態と同等の構成、制御であればITマネージャの共有度判断が省力化される。また、プロキシサーバ300の操作、判断を拡張するなら第1実施形態の方法を「自動モード」とし、第2実施形態の方法を「手動モード」とわけた上で、いずれかのモードをプロキシサーバ300の管理者が選択できるように構成することもできる。この場合には、利用者はプロキシサーバ300においてモードの選択が行える。プロキシサーバ300は選択されたモードに応じ、手動モード時にはITマネージャによる選択デバイスを示す情報をクライアントに送信する。
また、デバイスが手作業で選択されるために、第1実施形態で説明した図8の手順や図11のステップ1104の手順を省略しても良い。こうすることでフック制御および共有順位表作成の負荷を低減することも可能である。
[第3実施形態]
第1実施形態では、図5のステップ0508において他イベント(メッセージ)をプロキシサーバ300によりフックした。メッセージをフックするために、図6の径路0607をとおるメッセージとメタデータとを参照する必要があり、処理0604でURI差し替えをおこなっている。しかし、共有度順位表を作成するためのメッセージ参照の機能を外部システムがもっていればプロキシサーバ300がメッセージをフックする必要性はなく、処理0604は省略してよい。
図14は、メッセージ参照の機能をシステムがもっている場合の一例を示す図である。プロキシサーバ300は必要なイベントをシステムに設定し(11)、イベントが発生したら通知(12)をもらう(処理1407、1408)。システムとは、たとえばクライアントコンピュータ200やサーバコンピュータ400である。イベントとは、メッセージ送信を伴う動作であり、たとえば印刷要求(印刷命令)などがある。プロキシサーバ300は、利用者により入力された、イベントを特定するための情報をクライアントやサーバに送信して登録させる。イベントを特定するための情報を受信したクライアントやサーバは、イベントが生じるとそのイベントがプロキシサーバ300から登録されたイベントであるか判定する。登録されたイベントであれば、クライアントやサーバは、そのイベントに伴って送信されるメッセージの複製をプロキシサーバ300に送信する。たとえばプロキシサーバ300が、クライアントおよびプリンタに対して「印刷要求」をイベントとして登録した場合を想定する。この場合、クライアントは、印刷要求メッセージをデバイス(プリンタ)に送信するとともに、その複製をプロキシサーバ300に送信する。プロキシサーバ300は受信したメッセージに基づいてメッセージをカウントする。受信したメッセージは廃棄される。
こうして、プロキシサーバ300が実行するフック制御を処理1407、1408で代用する。その他は第1実施形態と同じ構成であり、第1実施形態と同様の効果が得られる。また、デバイス共有度順位表(実績テーブルともいう)0901に相当するログをシステムがもっている場合も、同様の代用ができる。
[第4実施形態]
WS−Discovery仕様にもとづき、デバイスがネットワークから離脱する際には、ネットワークに対してByeメッセージを送信(ブロードキャスト)する。前述のHelloメッセージの逆の意味を持つメッセージである。このByeメッセージの受信をきっかけにして、第1実施形態のデバイスドライバあるいはアプリケーションのインストールと対となるアンインストール処理が実施可能である。
共有度が高いMFP200がネットワークからはずされた場合、一定時間待ったのち、クライアントはMFP200のデバイスドライバをアンインストールする。この処理のフローを説明する。待ち時間は固定値であり、たとえば操作UIから入力される値が記憶されて用いられる。このフローを実行すると、短時間のデバイス離脱と復帰に対するインストールやアンインストール処理の実行が抑制される。なお本実施形態では、デバイスはByeメッセージをブロードキャストせず、プロキシサーバ300宛にユニキャストする。
図15は、デバイスからByeメッセージを受信した際、すなわち離脱時のプロキシサーバ300による処理フローチャートを説明する。まずステップ1502では、プロキシサーバ300が、Byeメッセージの送信元デバイスを特定する。すなわち、プロキシサーバ300が、メッセージに含まれる送信元アドレスを読み取る。ステップ1503では、プロキシサーバ300がクライアントとの接続を確認する。接続の確認は、たとえばエコーメッセージの送信などにより行える。ステップ1504では、プロキシサーバ300が待ち時間の設定を確認する。ここでいう確認とは、たとえば待ち時間の設定値を、プロキシサーバ300の記憶領域から読み出すことである。
次に、Byeメッセージの送信元デバイスが、共有度が高いデバイスであるかを、ステップ1504で判定する。この判定は、プロキシサーバ300が持つ共有度順位テーブルを、図11で説明した処理方法でソートし、応答レベルの段階表現で説明したように「高」と「中」の境界を決定する。そして、Byeの送信元デバイスが、「高」の範囲に含まれていれば、共有度が高いと判定される。共有度が高ければ、ステップ1509において、ネットワークに対して、Byeメッセージをブロードキャストする。このByeメッセージの送信元アドレスは、図15の処理のきっかけとなるByeメッセージの送信元デバイスのアドレスが書き込まれる。
共有度が高くないと判定された場合でも、そのサービスに即時性が要求されか否かステップ1505で判定し、即時性が要求される場合にはネットワークにByeメッセージを送信する。この判断は、Byeメッセージの送信元デバイスが提供するサービスに、あらかじめプロキシサーバ300に登録されたサービスが含まれているか否かの判定により実行される。サービスはIDやURIで表される。
いずれにも該当しない場合には待機処理をおこなう。その場合は、Byeメッセージの送信元デバイスのIDを、Bye待ちデバイスのリストに追加登録する(ステップ1506)。そしてステップ1507にて、プロキシサーバ300はBye待ちにしたデバイスのステータスを外部には一次停止扱いに変更する。たとえば、当該デバイスに関してデバイス情報要求があれば、一時停止中である旨の情報を応答する。ステップ1508では、プロキシサーバ300は、当該デバイスに関するByeメッセージの発行時間を、Bye待ちデバイスのリストに、デバイスIDと関連づけて登録する。この時間はたとえば、あらかじめ決めた定数でよい。プロキシサーバ300は、ステップ1511〜1513で時間待ちループする。ステップ1512でデバイスが復旧すれば、ステップ1514にすすみ、復旧あるいは更新(メタデータから判断)処理をおこなう。デバイスの復旧は、たとえばそのデバイスからHelloメッセージを受信したり、あるいは一定時間おきにプローブメッセージを送信し、その応答があれば復旧したと判断できる。ステップ1513でByeの発行時間がきたら、プロキシサーバ300はステップ1515で一時停止にしていたステータスをたとえば「離脱」に変更する。そして、ステップ1516でそのデバイスがネットワークから離脱する旨のByeメッセージを発行(ブロードキャスト)する。Byeメッセージを受信したクライアントは、その送信元デバイスのデバイスドライバをアンインストールする。
以上の手順により、電源断などにより一時的に短期間ネットワークから離脱しているデバイスのデバイスドライバを、ネットワーククライアントがその都度アンインストールする必要がなくなる。このため、クライアントの処理効率が向上する。また、共有度が高いデバイス、あるいは即時性が要求されるサービスを提供するデバイスについては、ネットワークからの離脱後ただちに各クライアントからデバイスドライバをアンインストールさせる。こうすることで、利用頻度が高いデバイスや、即時性サービスのために利用されるデバイスが、離脱して休止状態とされた状態で放置された状態でいることにより、誤って選択されることを防止できる。
また上述した実施形態においては、プラグアンドプレイの一例として、発見したネットワークデバイスに対応したドライバのインストール/アンイストールについて説明している。しかし、ネットワークデバイスを利用、制御するために必要なユーティリティ、アプリケーションなどをクライアントPC100に自動的にインストールする場合においても適用可能である。
また、上述した実施形態ではネットワークデバイスとしてプリンタに対する実装例を示したが、通信媒体を介して利用、制御可能なデバイスであれば、スキャナ、ストレージデバイス等、いずれのデバイスに対しても適用可能である。
また、上述した実施形態においては、クライアントPC100がネットワークデバイスを制御するためのドライバをメモリ上に保持する形態を示したが、ドライバに限らずアプリケーション、ユーティリティソフトウエアに対しても適用可能である。また、これらソフトウエアはネットワークデバイス上に保持されている場合、あるいは第3のサーバ上に保持されている場合にも適用可能である。
また、第1実施形態では共有度順位表のソートを、項目ごとに優先順位を付して行ったが、各項目の値に重みを付けて加算し、その値をキーとしてソートするなど、他の方法を採用することもできる。
また、図9(A)や図9(B)の共有度順位表の各項目のいずれかをキーとして表をソートしても良いし、キーの優先順位を様々に変更することもできる。優先順位の変更は、どの項目を重要視するかにより変更される。
また、デバイスが最初に接続された日時そのものをキーとして表をソートしても良い。またデバイスが最後に接続された日時を共有度順位表に登録し、その日時で表をソートすることもできる。
[第5実施形態]
本実施形態では、クライアントPC100とプロキシサーバ300間で実行されるメッセージのやり取りに従ってプリンタドライバの推奨度を更新する技術について説明する。なお、本実施形態では、推奨すべきデバイスを更新するための処理と、クライアントPC100からの要求に従って推奨デバイスを通知する処理がある。
まず、本実施形態における推奨すべきデバイスを更新するための処理の流れについて図28を参照して説明する。
クライアントPC100は、デバイス探索要求(Probe)をマルチキャストにて発行する(2801)。なお、このProbeには、対象デバイス情報を含むことができる。例えばプリンタの存在を確認するためのProbeであれば、プリンタを特定したProbeが発行される。また、Probeには、カラープリンタ等を指定することも可能とする。
Probeを受信したデバイス200は、Probeに含まれるデバイス情報と一致するか判定する。例えば、Probeにプリンタを特定する情報が含まれている場合、プリンタがProbeに対する返答であるネットワーク参加通知(Hello)信号を返信する(2802)。なお、このHello信号には、Hello信号を発行したデバイスのアドレス情報が含まれている。また、プロキシサーバ300も、例えばプリンタの存在を確認するためのProbeの受信に従って、当該プリンタに関する情報を保持しているか判定する。プロキシサーバ300は、保持していれば当該Probeに対する返答であるHello信号を発行する。ここで、プロキシサーバ300が発行するProbeに対する返答Helloには、プロキシサーバ300からの返答であることを示す識別情報が含まれている。よって、プロキシサーバ300が発行したことを示す識別情報付きのHello信号を受信したクライアントPC100は、ステップ2802以降についてプロキシサーバ300とメッセージ交換処理を実行する。なお、図28では、クライアントPC100が、プロキシサーバ300が発行したことを示す識別情報付きのHello信号を受信したものとして説明する。
クライアントPC100は、ステップ2802においてプロキシサーバ300が発行したことを示す識別情報付きのHelloを受信した場合、デバイス情報要求方法を選択する図24の選択画面2401を表示する(ステップ2803)。デバイス情報要求方法の選択画面2401について説明する。選択画面2401には、通常要求2402と推奨度に従う推奨要求2403のいずれかを選択できる。なお、現段階では、通常要求2402が選択されたものとして処理を進める。また、推奨度に従う推奨要求2403が選択された場合の処理については、後述する。
クライアントPC100は、選択画面2401にて選択されたデバイス情報の要求方法を含むデバイス情報要求信号を発行する(ステップ2804)。具体的にステップ2804にて発行されるデバイス情報要求は、図25および図27にて後述するデバイスリストを要求する信号である。なお、本実施例において、デバイス情報要求を第2メッセージと記載する場合もある。
プロキシサーバ300は、デバイス情報要求信号(デバイスリストの取得要求)の受信に従って、デバイス情報要求方法を解析する。現段階では通常要求が選択されているので、後述する図26の管理情報等は用いずに所定のルール(例えばデバイス名称の昇順等)に基づくデバイスリスト(例えば図25)を作成して、クライアントPC100へ発行する(ステップ2805)。なお、プロキシサーバ300は、ステップ2801のProbeにて指定されたデバイスに関するリストを発行すればよい。例えば、プロキシサーバ300が、プリンタとファクシミリ機の2台のデバイスについての情報を保持している状態で、クライアントPC100からプリンタに関する探索要求を受信した場合を想定する。この場合、2805にて発行されるリストには、プリンタ情報のみが記載され、ファクシミリ機については除かれる。図25は、デバイス情報返答に従ってクライアントPC100に表示されるデバイスリスト2501である。クライアントPC100は、デバイスリスト2501を介してユーザにより選択されたデバイスのサービス情報を要求する処理へと進む。
続いてクライアントPC100は、ステップ2805のデバイス情報返答に従ってデバイスリストを表示する(ステップ2806)。上述したように現段階では通常要求2402が選択されたため、所定のルールの一例であるデバイス名称の昇順に従う図25のデバイスリストが表示される。ここで、ユーザはデバイスリストを介して所望とするデバイスを選択する。図25では、プリンタ1とプリンタ2が選択された様子を示している。
クライアントPC100は、デバイスリストを介して選択されたデバイスのサービス情報を取得するため、サービス情報要求信号を発行する(ステップ2807)。このサービス情報とは、具体的にはデバイスの機能情報であり、機能情報とは、例えばカラー印刷が可能か否か、ステイプル処理が可能か否か等、デバイスが実行可能は機能情報である。なお、本実施例において、サービス情報要求を第1メッセージと記載する場合もある。
そして、プロキシサーバ300は、サービス情報要求時にサービス情報が要求されたデバイスを特定し、デバイスのメッセージ数に基づく優先度を更新し、要求されたデバイスのサービス情報をクライアントPC100に返送する(ステップ2808)。
ここで、図26を用いて、プロキシサーバ300が管理している各デバイスの優先度を更新するためのメッセージ数管理情報を説明する。図26には、プリンタごとにサービス情報が要求された回数を管理している。例えば、図25では、プリンタ1とプリンタ2が選択され、サービス情報要求が発行されたので、プロキシサーバ300は、当該サービス情報要求に従って、プリンタ1とプリンタ2のメッセージ数をインクリメントする。その結果、プロキシサーバ300は、どのデバイスがどれだけサービス情報を要求されたか(デバイスリストを介して選択されたか)をメッセージ数に基づいて管理することができる。そこで、プロキシサーバ300は、メッセージ数の多かったデバイスを多くのユーザが共有しているデバイスであると認識して優先度をあげる。
クライアントPC100は、サービス情報返答に従ってプリンタドライバをインストールする(ステップ2809)。
続いて、図28を用いて本実施形態における、クライアントPC100からの要求に従って推奨デバイスリストを表示する処理について説明する。なお、ステップ2801から2802は上述した処理と同様であるため詳細な説明は省略する。
クライアントPC100は、ステップ2802においてプロキシサーバ300が発行したことを示す識別情報付きのHelloを受信した場合、デバイス情報要求方法を選択する図24の選択画面2401を表示する(ステップ2803)。今回は、推奨度に従う推奨要求2403が選択された場合の処理について説明する。
クライアントPC100は、デバイス情報要求時に表示される図24の画面を介して選択された推奨要求2403に基づくデバイス情報要求を発行する(ステップ2804)。
プロキシサーバ300は、推奨要求2403が選択されたデバイス情報要求を受信した場合、図26にて管理している情報に従って優先度順に並べたデバイスリストを作成してクライアントPC100に応答する(ステップ2805)。
クライアントPC100は、ステップ2805の応答に従って優先度に従うデバイスリストを表示する(ステップ2806)。ここで、図27を用いて優先度に従うデバイスリスト2701を説明する。プロキシサーバ300は、図26に示すような情報を管理しているとする。ここで、プロキシサーバ300は、各デバイスのメッセージ数に基づいて優先度を決定し優先度順に並べたデバイスリストを作成する。その結果、図27に示す優先度順に並べたデバイスリスト2701がクライアントPC100へ応答される。
クライアントPC100は、例えば図27に示すようなデバイスリスト2701を表示するため、ユーザは、優先度の高い(すなわち多くのユーザがインストールしている)プリンタドライバを容易に特定できる。そして、例えばネットワークに新規に参加したユーザは、多くのユーザによって共有されているプリンタドライバをインストールすることが可能となる。
続いて、図29を用いて本実施形態におけるプロキシサーバ300の処理を説明する。
プロキシサーバ300は、デバイス探索要求(Probe)を受信したか否かを判定する(S2901)。
S2901において、デバイス探索要求を受信したと判定された場合、プロキシサーバ300は、Hello信号を、Probe信号の送信元のクライアントPC100に対して発行する(S2902)。そのHello信号には、プロキシサーバ300によって発行されたことを示す識別情報が付いている。なお、受信したProbe信号には、発行元クライアントPC100のアドレス情報が含まれているので、プロキシサーバ300は、当該アドレスに対してHello信号を発行する。
続いて、プロキシサーバ300は、クライアントPC100からデバイス情報要求を受信したか否かを判定する(S2903)。
S2903において、プロキシサーバ300が、デバイス情報要求を受信したと判定した場合、優先度に従うリストを要求する推奨要求か否かを判定する(S2904)。
S2904において推奨要求ではないと判定された場合(S2904−No)、プロキシサーバ300は、例えばプリンタ名称の昇順に従うデバイスリストを作成する(S2906)。
一方、S2904において推奨要求であると判定された場合(S2904−Yes)、プロキシサーバ300は優先度に従うリストを作成する。具体的には、プロキシサーバ300は、クライアントPC100から要求されるサービス情報要求をデバイスごとにカウントしており、デバイスごとにクライアントPC100から受信したメッセージ数を管理している。この管理している情報を示す図が、上述した図26である。つまり、プロキシサーバ300は、サービス情報要求を受信する度に、どのデバイスのサービス情報を要求しているかを解析し、要求されたデバイスのメッセージ数を示すメッセージカウンタを1ずつカウントしている。そして、このカウント値が優先度となる。よって、プロキシサーバ300は、S2905において優先度に従う(メッセージ数に従う)デバイスリストを作成して通知する。
プロキシサーバ300は、サービス情報要求を受信したか否かを判定する(S2907)。そして、サービス情報要求を受信した場合、プロキシサーバ300は、どのデバイスに対するサービス情報が要求されたかを解析し、要求されたデバイスに対応するメッセージカウンタすなわち管理情報を更新する(S2908)。
このように本願では、デバイス情報要求(デバイスリスト要求)時に、通常要求、または、多くのユーザがインストールしている推奨デバイスを特定可能なリストを要求する推奨要求を選択できる。そして、推奨要求が選択された場合、プロキシサーバ300は、多くのユーザがインストールしているデバイス順に並べられた推奨デバイスリストを作成して通知する。そのため、プリンタドライバのインストールを実行するユーザは、例えば新規にネットワークに参加したユーザであっても容易に多くのユーザがインストールしている共有度の高いデバイスドライバに絞ったインストールを実現することが可能となる。
また、優先度の高いデバイスを決定する方法としては、各デバイスの使用履歴に従って決定する方法が挙げられる。この方法の問題点について説明する。例えば、通常はモノクロ印刷を実行するのでモノクロプリンタを頻繁に使用し、数ヶ月に1度の会議用にカラー印刷を実行するためカラープリンタを使用する環境を想定する。この場合、カラープリンタは、ほとんど使用されないため推奨デバイスとして抽出されないおそれがある。これでは、新規にネットワークに参加したユーザが、いざカラー印刷を実行したい場合、カラープリンタのプリンタドライバがインストールされていないため迅速にカラー印刷を実行することができなくなるおそれがある。
しかし、本願では、多くのユーザがインストールしているデバイスを推奨するため、上記のような問題が発生するおそれを低減でき、当該ネットワークにおいて最低限必要なデバイスドライバをインストールすることが可能となる。
<発明のまとめ>
以上、実施形態で説明した本発明に係るプロキシサーバの構成および動作を列記すると以下のようなものとなる。
(1)情報処理装置からのネットワークデバイス(たとえばディジタル複合装置)の共有度順位を判断する。
(2)共有度順に複合装置の情報(デバイス情報)を選択し、選択したデバイス情報を情報処理装置へ応答する。
(3)クライアントでは、選択されたデバイスのデバイスドライバ等のソフトウエアのインストールを誘導する。
(4)クライアント(情報処理装置)およびデバイスの個体識別をおこない、情報処理装置とデバイス間のメッセージを参照するためのアドレス情報(URI)変換と記録機能を持つ。
(5)利用実績表(共有度順位表)を作成する。共有度を判断する条件は以下の通りである。
−デバイス(複合装置)へのクライアント(情報処理装置)の接続数、
−デバイスへのクライアントの利用量(メッセージ量)、
−デバイスとクライアントのネットワークスコープ比較、
−デバイスの提供機能。
(6)共有度、新規追加デバイス、過去に利用実績のあるデバイスに該当するデバイスを列挙し、そのデバイス情報をクライアントに送信する。
(7)列挙範囲を設定により制御する。
(8)初期選択を設定により制御する。
(9)デバイス情報をクライアントへ選択応答する内容が設定できる。
(10)操作UIを表示する。その操作UIは段階表現、順位表、個数のいずれかを設定する形式である。
(11)初期選択とその後ユーザが追加および解除選択したデバイスに対してデバイスドライバ等のソフトウエアのイストールを誘導する。
(12)操作UIを表示し、その操作UIはデバイスを個別に選択できる形式である(第2実施形態)。
(13)クライアントやデバイスがイベント通知機能を持っていれば、情報処理装置と複合装置間のメッセージを参照するためのアドレス情報(URI)変換と記録の手段をイベント通知機能で代用する(図14、第3実施形態)。
(14)クライアントやデバイスがイベントログ機能を持っていれば、利用実績表(共有度順位表)の内容をシステムイベントログから複製する。これは実施形態には記載されていない。しかし、たとえばメッセージをフックしてデバイス別やサービス別にカウントするというプロキシサーバによる機能と同様のログ機能を持つクライアントもある。プロキシサーバは各クライアントにログを要求して受信し、共有度順位表を作成できる。そのタイミングはたとえば定期的あるいはデバイス情報要求を受信したときである。
(15)デバイスのネットワークからの離脱時は、プロキシサーバは、クライアントが保持するデバイスのステータスを一次停止にする。また、待ち時間を設定する。また、デバイスが復旧しないまま待ち時間が経過すれば、クライアントにデバイスの離脱を通知してドライバを削除させる。復旧すれば、その旨をクライアントに通知する。
(16)内部的に階層的な接続部、フロー制御部、管理部の各構造をもつ。
(17)記録、判断、設定を担当する管理機能部は分離できる。
(18)分離された管理機能部をサーバに集約配置可能である。
(19)分離された管理機能部を管理ユーティリティと接合できる。
[実施形態における発明の関連づけ]
実施形態記載の発明は、以下のように記載することもできる。すなわち、本発明は、周辺機器(デバイス200)および端末(クライアントPC100)と通信可能な情報処理装置(プロキシサーバ300)に係るものである。本装置は、保存手段と、係数手段と、受信手段と、応答手段とを有する。本装置において、保存手段はHDD11に保存されたデバイスリスト11aに相当する。保存手段は、前記周辺機器(200)から該周辺機器に関する情報(デバイス情報1804)を受信して保存する。
また、計数手段は、プロキシサーバ300のCPU1によりステップS1701−S1709を実行して共有度順位表0901を作成することに相当する。係数手段は、前記端末(100)および前記周辺機器間(200)において送受信されているメッセージ情報(1809)を周辺機器毎に数えることにより得られる周辺機器毎の共有度を計数する。
また、受信手段は、プロキシサーバ300のCPU1によりデバイス情報要求1807を受信することに相当する。要求メッセージ受手段手段は、前記端末(100)から、前記保存手段(デバイスリスト11a)にて保持されている周辺機器に関する情報を要求する要求メッセージ(デバイス情報要求1807)を受信する。
また、応答手段は、プロキシサーバ300のCPU1によりデバイス検索処理1807aを実行することに相当する。応答手段は、前記受信手段により前記要求メッセージ(デバイス情報要求1807)を受信することに応じて、前記計数手段により得られる周辺機器毎の共有度に従って選択された周辺機器に関する情報を、前記端末に送信する。
さらに、前記計数手段は、前記端末から前記周辺機器へのメッセージを受信し、受信したメッセージの宛先および送信元情報に基づいて、周辺機器毎に、送信元となった端末数を数えて前記共有度を計数し、
また本装置は、前記周辺機器に前記計数手段により得られた共有度を用いて、該端末数をキーとして整列した順位を共有度の順位とする共有度順位情報を作成する作成手段をさらに有する。作成手段は、CPU1が、ステップS0801−S0806を実行して共有度順位表0901を作成することに相当する。
また前記応答手段は、前記作成手段によって作成された共有度順位情報を用いて送信すべき周辺機器に関する情報を選択する。
あるいは、第5実施形態に係る発明については以下のようにも言い得る。すなわち、本発明は、周辺機器(デバイス200)および端末(クライアントPC100)と通信可能な情報処理装置(プロキシサーバ300)に係るものである。本装置は、保存手段と、第1応答手段と、更新手段と、受信手段と、第2応答手段とを有する。本装置において、保存手段は、HDD11:デバイスリスト11aに相当する。保存手段は、前記周辺機器(200)から該周辺機器に関する機能情報(1804)を受信して保存する。
また、第1応答手段は、CPU1によるサービス情報応答2808の送信に相当する。第1応答手段は、前記端末(100)からの、周辺機器(200)に関する機能情報を要求する第1メッセージ(サービス情報要求2807)の受信に従って、前記保存手段(HDD11)によって保存された機能情報(11a)を前記端末(100)に送信する。
また、更新手段は、CPU1が、ステップS2908を実行してメッセージカウンタを更新することに相当する。更新手段は、前記端末(100)からの、周辺機器(200)に関する機能情報(11a)を要求する前記第1メッセージ(サービス情報要求2807)の数に基づいて推奨すべきデバイスの優先度を更新する。
また、受信手段は、CPU1が、デバイス情報要求2804を受信することに相当する。受信手段は、前記端末(100)から、推奨する周辺機器のリスト(リスト2501)を要求する第2メッセージ(デバイス情報要求2804)を受信する。
また、第2応答手段は、CPU1が、ステップS2905を実行することに相当する。第2応答手段は、前記受信手段により前記第2メッセージ(2804)を受信することに応じて、前記更新手段によって更新された優先度に従って決定される周辺機器のリストを、前記端末に送信する。
[他の実施形態]
上述した実施形態におけるクライアントPC100及びネットワーク対応デバイス200における各処理機能は、各処理機能を実現する為のプログラムをメモリから読み出してCPU(中央演算装置)が実行することによりその機能を実現させる。しかしこれに限定さるものではなく、各処理機能の全部または一部の機能を専用のハードウェアにより実現してもよい。また、上述したメモリは、光磁気ディスク装置、フラッシュメモリ等の不揮発性のメモリにより構成されても良い。また、CD−ROM等の読み出しのみが可能な記録媒体、RAM以外の揮発性のメモリ、あるいはこれらの組合せによるコンピュータ読み取り、書き込み可能な記録媒体より構成されてもよい。
また、クライアントPC100またはネットワーク対応デバイス200内の各機能を実現する為のプログラムをコンピュータ読み取り可能な記録媒体に記録しておく。この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより各処理を行っても良い。ここでいう「コンピュータシステム」とは、OSや周辺機器等のハードウェアを含む。具体的には、記憶媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書きこまれる。その後、そのプログラムにしたがって、その機能拡張ボードや機能拡張ユニットに備わるCPUなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含む。
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ROM、CD−ROM等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置を含む。さらに「コンピュータ読み取り可能な記録媒体」とは、通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発メモリ(RAM)のように、一定時間プログラムを保持しているものも含むものとする。
また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク(通信網)や電話回線等の通信回線(通信線)のように情報を伝送する機能を有する媒体のことをいう。
また、上記プログラムは、前述した機能の一部を実現する為のものであっても良い。さらに、前述した機能をコンピュータシステムに既に記録されているプログラムとの組合せで実現できるもの、いわゆる差分ファイル(差分プログラム)であっても良い。