JP2007128260A - 情報処理装置及び情報処理方法及びそのプログラム - Google Patents

Abstract

【課題】実際に接続されていないネットワークプリンタのドライバをコンピュータから自動的にアンインストールする。
【解決手段】ネットワークプリンタ２００は、シャットダウン等の操作に応じてＢｙｅメッセージをネットワークに対して送信する。それをクライアント１００は受信して、そのプリンタに対応するプリントキューをオフラインにする（Ｓ２０）。そのコンピュータのユーザがゲストであるか判定し、全ユーザがゲストであれば前記プリンタのプリンタドライバを使用する他のプリンタがないか判定する（Ｓ２３）。なければ、そのプリンタドライバを削除する。
【選択図】図９

Description

本発明はネットワークに対応した周辺装置、および該周辺装置を制御する情報処理装置、情報処理方法及びそのプログラムに関するものである。

従来、ネットワーク上のクライアント装置からのサービス要求に応え、サービスを提供するサービス提供装置及び、サービス提供システムが知られている。例えば、インターネットによる通信の飛躍的な普及に伴い、ネットワーク対応型機器として、従来のパーソナルコンピュータ以外の種類の多様な機器が開発されている。例えば、ＰＤＡ、携帯電話等のユーザインタラクティブなデバイスや、スキャナ、プリンタ、複写機、デジタルカメラ等の画像処理装置や、テレビ、エアコン、冷蔵庫等の家電製品などに至るまでネットワーク対応が急速に進められている。なおＰＤＡとはパーソナルデータアシスタントの略称である。

それに伴い、これまでこれらネットワーク対応型デバイスを利用する上での利便性、簡易性を高めるために、さまざまなプロトコル、アーキテクチャが提案されている(特許文献１，２)。それ提案には、サービスを提供するネットワークデバイスの探索、検索手段、ネットワーク対応型デバイスを制御するためのアプリケーションソフトウエア、ユーティリティソフトウエア、オペレーティングシステム等の自動セットアップ手段などがある。

また、複数の企業、標準化団体が、ローカルI/O接続デバイス対して適用されてきたプラグアンドプレイをネットワークデバイスに対して拡張対応すべく、仕様策定作業を進めている。例えば、Ｍｉｃｒｏｓｏｆｔ社が主体となって策定を進めるＵＰｎＰ（登録商標:非特許文献１）がある。さらに、WSD:Web Services for Devices(WS-Discovery/WS-MetadataExchange 非特許文献２、３)が挙げられる。さらに、Ａｐｐｌｅ社が開発したＯＳ ＸでサポートされるＲｅｎｅｄｚｖｏｕｓなどがその一例である。また、WSDについては、ＢＭＬｉｎｋＳ基本仕様書Ｖｅｒｓｉｏｎ１．２」（ビジネス機械・情報システム産業協会、インターネットURL：http://www.jbmia.or.jp/bmlinks/index.htm）も挙げられる。
特開2004-038956 特開2004-362594 "UPnP(TM) Device Architecture" version1.0、２０００年６月８日（インターネットURL: http://www.upnp.org/download/UPnPDA10_20000613.htm） "Web Service Dynamic Discovery(WS-Discovery)"、２００５年４月（インターネットURL: http://specs.xmlsoap.org/ws/2005/04/discovery/ws-discovery.pdf） "WS-MetadataExchange"、２０００年９月、マイクロソフト社（インターネットURL: http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-metadataexchange.pdf）

このようにネットワークプラグアンドプレイ（ネットワークＰｎＰとも呼ぶ。）が普及することによって利便性が向上する。しかしその一方で、一旦ネットワークプラグアンドプレイによって認識されたネットワークデバイスが、ユーザが使用する際に実際に使えるのかどうか分からないといった問題がある。

言い換えると、ネットワークプラグアンドプレイによって自動的にネットワークデバイスのドライバおよびアプリケーションがインストールされてしまう。そのドライバおよびアプリケーションの自動インストール後にネットワークデバイスが使用不可となった場合、たとえばそのデバイスがネットワークから切り離された場合でも、ユーザはそのデバイスのドライバおよびアプリケーションを選択することはできる。そのため、ユーザには、なぜネットワークデバイスを使えないのかが分からない。

例えば、携帯型パーソナルコンピュータを自宅あるいは勤務先のオフィスから移動し、訪問先オフィス、あるいは公共施設に設けられたホットスポットなど、異なるネットワーク環境を一時的に利用するケースがある。その場合、携帯型パーソナルコンピュータのプラグアンドプレイ機能が、そのネットワーク環境で稼動しているネットワークデバイスを発見するたびに、ネットワークデバイスのドライバやアプリケーションを自動的にインストールする。つまり、携帯型パーソナルコンピュータには、普段使用するプリンタドライバと一時的に利用するプリンタドライバが記憶されている状態となる。そして、携帯型パーソナルコンピュータが、一時的に利用したネットワーク環境から離れた後でも依然としてインストールされたドライバ、アプリケーションは携帯型パーソナルコンピュータに残ったままである。使うことのできないデバイスのドライバやアプリケーションが携帯型パーソナルコンピュータに残ったままでは、その使用上甚だ不便である。これは、使用できないにも関わらず利用者に対しては利用できるように見せられているソフトウエアから、利用者が実際に使用できるものを選択して使用しなければならないためである。また、デバイスからさらには携帯型パーソナルコンピュータのハードウェア資源、特にメモリ資源をいたずらに消費してしまうことにもなる。もちろん携帯型パーソナルコンピュータに限らず、ネットワークＰｎＰ機能を備えたネットワークデバイス一般についてこの問題は生じ得る。つまり、ゲストユーザとしての一時的利用者がログインした後にインストールされたプリンタドライバは、普段使用することがないためアンインストール処理される必要がある。一方、管理者ユーザなどのゲストユーザ以外のユーザがログインした後にインストールされたデバイスドライバは、頻繁に使用される可能性がある。そのため、安易にアンインストール処理されると必要なときに使用することができないといった問題が生じる可能性が高くなる。

本発明は上記従来例に鑑みてなされたもので、インストールされているデバイスドライバの属性に基づいて、アンインストール処理を実行すべきか否かを決定する。これにより、ネットワークプラグアンドプレイ機能により検出できないデバイスのソフトウエアをアンインストールすることができ、利用者の操作性を向上させることを目的とする。

また、使用できないソフトウエアを削除することで、限られた計算資源を有効利用することを目的とする。

本発明は上記従来例に鑑みてなされたもので、以下の構成を備える。すなわち、周辺機器と接続されたコンピュータにより実行されるプログラムであって、
周辺機器からの離脱メッセージを受信する受信手段と、
前記受信手段により離脱メッセージを受信した場合に、前記離脱メッセージの送信元のデバイスに対応するデバイスドライバ情報が所定の条件に一致するか否かを判定する判定手段と、
前記判定手段により前記デバイスドライバ情報が前記所定の条件に一致する場合、該離脱メッセージ送信元の周辺機器に対応するデバイスドライバを削除する削除手段とを備えることを特徴とする。

本発明により、ネットワークプラグアンドプレイ機能により検出できないデバイスの使用のためにインストールされたソフトウエアをアンインストールすることで、利用者の操作性を向上させることができる。

また、使用できないソフトウエアを削除することで、限られた計算資源を有効利用することができる。

［第１実施形態］
以下に、図面を参照して、この発明の好適な実施の形態を例示的に詳しく説明する。ただし、この実施の形態に記載されているプロトコル、ヴァージョン、アドレス、その他の数値等は、特に特定的な記載がない限りは、この発明の範囲をそれらのみに限定する趣旨のものではない。

＜印刷システムのハードウエア構成＞
図１７は、本発明の実施の形態であるネットワーク印刷システムに接続しているひとつのクライアントとひとつのネットワークプリンタに注目したハードウエア構成を示すブロック図である。図１７では、クライアント１０００と印刷装置であるネットワークプリンタ３０００とがネットワーク１７３１を介して接続された構成となっている。クライアント１０００ではコンピュータ本体２０００に対して外部装置であるキーボード１７０９、ＣＲＴ１７１０、ハードディスク１７１１等が接続されている。コンピュータ本体２０００はＣＰＵ１７０１を備え、ＣＰＵ１７０１はＲＯＭ１７０３やハードディスク１７１１に記憶された制御プログラムやアプリケーションをＲＡＭ１７０２に展開して演算を行うことができる。また、外部装置であるキーボード１７０９からの入力を制御しているのがキーボードコントローラ（ＫＢＣ）１７０５である。また、ＣＲＴ１７１０の表示を制御しているのがＣＲＴコントローラ（ＣＲＴＣ）１７０６であり、ハードディスク１７１１に対して入出力の制御を行っているのがハードディスクコントローラ（ＨＤＣ）１７０７である。ＮｅｔＣ１はネットワークコントローラであり、ネットワーク１７３１を介してプリンタ３０００に接続されて、プリンタコントローラ部４０００との間の通信制御を行っている。

これらＣＰＵ１７０１、ＲＡＭ１７０２、ＲＯＭ１７０３、ＫＢＣ１７０５、ＣＲＴＣ１７０６、ＨＤＣ１７０７、ＮｅｔＣ１はそれぞれシステムバス１７０４によって接続され、各デバイスをＣＰＵ１７０１が総括的に制御している。ハードディスク１７１１あるいはＲＡＭ１７０２には、ネットワークデバイス、特に本実施形態ではネットワークプリンタのデバイスドライバのインストール状態を示すインストール済みデバイスリストが保存されている。インストール済みデバイスリストは、コンピュータ１０００にインストールされたオペレーティングシステムにより提供されるＵＰｎＰ機能により認識される、デバイスの名称（識別子）、ＩＰアドレス、ドライバ名、アイコンファイル名等が含まれている。これらの情報は、オペレーティングシステムが管理するシステム情報のデータベースであるレジストリから得ることもできる。そこでレジストリを参照しても、デバイスリストと同様の情報を参照できる。すなわち、本実施形態では、インストール済みデバイスリストを持つものとするが、レジストリを用いれば、インストール済みデバイスリストを特別に用意する必用はない。

なお、本実施形態では、クライアントとしてパーソナルコンピュータ（ＰＣ）を想定している。しかし、本発明を実施可能な形態であれば、クライアントはＰＣに限定するものではなく、ＰＤＡなどの携帯情報端末や携帯電話、デジタル家電等をクライアントとしてもよい。いずれの装置も、特定用途の入出力デバイス等を除けば、図１のコンピュータ１０００と同様の構成を有する。

ネットワークプリンタ３０００において、プリンタＣＰＵ１７２１は、ＲＯＭ１７２３のプログラム用領域に記憶された制御プログラムを実行する。制御プログラムの実行により、バス１７２４に接続される各種のデバイスとのアクセスを総括的に制御し印刷部２２を介して接続される印刷機構部１７２８（プリンタエンジン）に印刷データとしての画像信号が出力される。

ＣＰＵ１７２１はネットワークコントローラ（ＮｅｔＣ）１７を介してクライアント１０００との通信処理が可能である。通信によりネットワークプリンタ３０００内の情報等をクライアント１０００に通知可能に構成されている。ＲＡＭ１７２２はＣＰＵ１７２１の主メモリ、ワークエリアなどとして機能する。また、ＲＡＭ１７２２はクライアント１０００より受信した印刷データや画像ビットマップデータを格納しておくための描画メモリ、ビデオ信号情報格納領域、その他としても使用される。ハードディスクコントローラ１７２７にて制御されるハードディスク１７２９は印刷ジョブデータのＢＯＸ保存などのために使用される。操作パネル１７３０はユーザがネットワークプリンタ３０００を操作する際のユーザインタフェースであり各種スイッチやＬＥＤ表示機器の他、タッチパネル式の液晶パネルなどで構成される。この操作パネル１７３０を介して、ユーザはそのプリンタ３０００を、ネットワーク１７３１から切り離して撤去する旨の指示、すなわち永久的に切り離す旨の指示を入力できる。この指示があったことを示す情報はＲＡＭ１７２２に保存されて、プリンタ３０００から送信される。なおここでＲＡＭ１７２２に保存された永久に切り離す旨の情報は、ネットワークからの離脱を示すｂｙｅメッセージ（離脱メッセージとも呼ぶ。）の種類を決定する基礎となる。

ハードディスク１７２９には、プリンタ３０００の構成を示す構成情報データベースが保存されている。構成情報データベースは、各種のデータを含むデータベースである。構成情報データベースには、デバイスタイプ情報、サービス情報、デバイスの使用頻度情報、印刷速度情報、カラー印刷機能の有無を示すカラー機能情報、最高解像度情報、両面印刷機能の有無を示す両面機能情報、製造メーカ情報などが含まれている。

なお、ネットワークプリンタ３０００は本発明の機能を実施できる装置であればシングルファンクションプリンタでもスキャナやコピー、ファクシミリ等の機能も備えたマルチファンクションプリンタでもよい。印刷機構部１７２８としてレーザービームプリンタやインクジェットの印刷機構を用いたプリンタ、サーマルプリンタなどいかなるプリント方式を用いていようが、本発明の機能に制限をするものではない。

＜ＰｎＰシステムの構成＞
図１は本発明の一実施形態としてのネットワークプラグアンドプレイシステムの構成を示すブロック図である。図１の構成は図１７のハードウエアの上に構築される。図１において、イーサネット（登録商標）コントローラ等のハードウエアデバイスよりも上のレイヤは、ＲＡＭ１７０２やＲＡＭ１７２２にロードされたソフトウエアをＣＰＵにより実行することで実現される。

さて、図中、クライアントデバイス１００は、本実施形態においては携帯型パーソナルコンピュータである。しかし、ネットワークプラグアンドプレイ機能を備えたコンピューティングデバイス、たとえばＰＤＡや携帯電話等についても、本発明は適用できる。

クライアントデバイス１００は、通信機能としてＥｔｈｅｒｎｅｔ（登録商標），ＷｉＦｉ（登録商標）（ＩＥＥＥ８０．１１ａ／ｂ／ｇ），Ｂｌｕｅｔｏｏｔｈ（登録商標）に対応している。そのためＥｔｈｅｒｎｅｔ（登録商標）コントローラ１、ＷｉＦｉコントローラ２、Ｂｌｕｅｔｏｏｔｈコントローラ３を備えている。これらコントローラの上位レイヤには、ＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック４を備え、そのプロトコルスタック上にＨＴＴＰ５を備え、ＨＴＴＰリクエストの解析、およびレスポンス処理を行う。

ＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック４、およびＨＴＴＰ５の上位層にはＳｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ（ＳＯＡＰ）プロセッサ６を備える。ＷＳＤモジュール８、およびユーティリティ１４、アプリケーション１５は、それぞれＳＯＡＰプロセッサ２０を介してｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（ＸＭＬ）で記述されたデータの双方向通信を実現する。なおＳＯＡＰとは、ネットワーク経由でオブジェクト間の通信を行うためのプロトコルである。ＳＯＡＰでは、ＸＭＬによって記述されるデータ構造が定義され、転送用のプロトコルとしては、ＨＴＴＰやＳＭＴＰが用いられる。ＳＯＡＰプロセッサ６は、ＳＯＡＰにしたがって記述されたオブジェクトを解析（パース）し、処理を実行する。

ＷＳＤモジュール８は、Ｍｉｃｒｏｓｏｆｔらがその仕様策定を推進するＷＳ−Ｄｉｓｃｏｖｅｒｙ仕様に基づき、ＳＯＡＰプロセッサ６を介してネットワークデバイスから通知されるＨｅｌｌｏメッセージに対する応答処理を行う。さらに、ＷＳＤモジュール８は、ネットワークデバイス検索のためのＰｒｏｂｅメッセージの発行処理を実行する。また、ＷＳＤモジュール８は、ＷＳ−ＭｅｔａｄａｔａＥｘｃｈａｎｇｅ仕様に基づき、ＧｅｔＭｅｔａｄａｔａメッセージを発行することで、ネットワークデバイスの属性情報を取得する。さらに、ＷＳ−Ｄｉｓｃｏｖｅｒｙ仕様に基づき、ネットワークデバイスから通知されるＢｙｅメッセージに対する応答処理を実行する。

これらメッセージ処理により、ネットワークデバイスを発見した場合、ＷＳＤモジュール８はプラグアンドプレイコントローラ１１に対して、発見したネットワークデバイスの属性情報を通知する。プラグアンドプレイコントローラ１１は該属性情報をもとに該当するドライバおよびユーティリティソフトウエア１２を、デバイスドライバマネージャ１０を介してクライアントデバイス１００に対してインストールする機能を備える。

一方、ネットワークデバイスのネットワークからの離脱を発見した場合、ＷＳＤモジュール８はプラグアンドプレイコントローラ１１に対して、離脱を発見したネットワークデバイスのアドレス情報を通知する。プラグアンドプレイコントローラ１１はネットワークアドレス情報をもとに該当するドライバ、ユーティリティソフトウエアをドライバマネージャ１０を介して、クライアントデバイス１００に対してアンインストールを実行する機能を備える。クライアントは、ネットワークデバイスがネットワークに対してブロードキャストする、あるいはホストに対してマルチキャストするＢｙｅメッセージの受信により、ネットワークデバイスのネットワークからの離脱を発見することができる。

アプリケーション１５は、例えばワードプロセッサなどで編集した書類をプリンタにより印刷する。その際、アプリケーション１５は、プラグアンドプレイコントローラ１１によりインストールされたドライバおよびユーティリティを介して、ネットワーク対応デバイス２００に対してジョブデータ、印刷データを送信する。

一方、ネットワーク対応デバイス２００は、本実施の形態ではネットワーク対応型プリンタである。ネットワーク対応デバイス２００は、通信機能としてＥｔｈｅｒｎｅｔ（登録商標），ＷｉＦｉ（登録商標）（ＩＥＥＥ８０．１１ａ／ｂ／ｇ），Ｂｌｕｅｔｏｏｔｈ（登録商標）に対応している。そしてそれぞれＥｔｈｅｒｎｅｔ（登録商標）コントローラ１６、ＷｉＦｉコントローラ１７により制御される。これらコントローラの上位レイヤには、ＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック１８を備え、そのプロトコルスタック上にＨＴＴＰ１９を備え、ＨＴＴＰリクエストの解析、およびレスポンス処理を行う。

ＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック１８、およびＨＴＴＰ１９の上位層には、ＳＯＡＰプロセッサ２０を備えている。そして、ＷＳＤモジュール２１、およびプリンタコントローラ２２が、それぞれＳＯＡＰプロセッサ２０を介してｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（ＸＭＬ）で記述されたデータの双方向通信を実現する。

ここで、ＷＳＤモジュール２１は、ネットワークに接続した際に、ＷＳ−Ｄｉｓｃｏｖｅｒｙ仕様に基づき、ＳＯＡＰプロセッサ２０を介してＨｅｌｌｏメッセージの送信する。さらにＷＳＤモジュール２１はクライアントデバイス１００から発行されるＰｒｏｂｅメッセージに対する応答処理を実行する。

また、ＷＳＤモジュール２１は、ＷＳ−ＭｅｔａｄａｔａＥｘｃｈａｎｇｅ仕様に基づき、クライアントデバイス１００から発行されたＧｅｔＭｅｔａｄａｔａメッセージに応じ、ネットワーク対応デバイス２００が持つ属性情報を返信する。本実施形態の場合、ネットワーク対応デバイス２００はネットワーク対応プリンタである。さらに、ＷＳＤモジュール２１は、ＷＳ−Ｄｉｓｃｏｖｅｒｙ仕様に基づき、ネットワークから離脱する際にＢｙｅメッセージを送信する。

なお、クライアントデバイス１００は、ネットワークに接続されたワイヤレスＬＡＮアクセスポイント２３を介してＥｔｈｅｒｎｅｔ（登録商標）に接続することもできる。

＜ネットワークＰｎＰによるデバイスの認識手順＞
以下に本発明の制御の流れをフローチャートに従い説明する。以下説明するフローチャートにおいて、「クライアントデバイス１００」による処理は主としてＷＳＤモジュール８により実行され、「ネットワーク対応デバイス２００」による処理は、主としてＷＳＤモジュール２１により実行される。ただし「クライアントデバイス１００」による処理には、プラグアンドプレイコントローラ１１やデバイスドライバマネージャ１０による処理も含まれている。ＳＯＡＰプロセッサ以下のレイヤにおける処理は、Ｗ３Ｃによる規定に従うものなので、ここでは説明は省略する。

＜ネットワークプラグアンドプレイ処理１＞
図２は、本実施形態において、ネットワークデバイスに対するプラグアンドプレイ処理をする場合の制御の流れを説明するフローチャートである。また図２に示す手順は、ネットワーク対応デバイスがオンライン状態になった際にイニシアチブをとる手順の例である。

ネットワーク対応デバイス２００のＷＳＤモジュール２１は、ネットワークに接続されたときに、ＳＯＡＰプロセッサ２０に対してＨｅｌｌｏメッセージの送信を要求する。ネットワークに接続されたときとは、たとえば新規なデバイスがネットワークに接続されて通信を開始するとき、あるいは、電源オフの状態から電源オンされてネットワーク上での通信を再開するときなどがある。ＳＯＡＰプロセッサ２０は、ＷＳ−Ｄｉｓｃｏｖｅｒｙ仕様に基づきＨｅｌｌｏメッセージを生成し、プロトコルスタックを介してマルチキャストアドレス２３９．２５５．２５５．２５０に対してマルチキャスト送信する（ステップＳ１）。

ＨｅｌｌｏメッセージはＸＭＬ−ＳＯＡＰで記述されており、図３にそのメッセージ３０１のフォーマットの例を示す。Ｈｅｌｌｏメッセージには、送信元のアドレスＵＲＩ３０３やデバイスのタイプ３０２（本例ではプリンタ）、メタデータのバージョン３０４等の情報を含む。また本実施形態では通信プロトコルはＴＣＰ／ＩＰを用いているので、ＴＣＰやＩＰのパケットヘッダにも、送信元のポート番号やＩＰアドレスが含まれている。これらの情報により、Ｈｅｌｌｏメッセージの受信側装置は、その送信元の装置やそのメッセージの意味を特定できる。

ＨｅｌｌｏメッセージはＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック４を介して、クライアントデバイス１００のＳＯＡＰプロセッサ６に通知される。ＳＯＡＰプロセッサ６は、Ｈｅｌｌｏメッセージを受信するとその内容を解析し、その結果をＷＳＤモジュール８に通知する（ステップＳ２）。ＷＳＤモジュール８は、Ｈｅｌｌｏメッセージを発行したネットワークデバイスの属性情報を取得する。そのために、ＷＳＤモジュール８は、ＳＯＡＰプロセッサ６に対して、Ｈｅｌｌｏメッセージに記述されたアドレスを送信先とするＷＳ−ＭｅｔａｄａｔａＥｘｃｈａｎｇｅで規定されるＧｅｔＭｅｔａｄａｔａメッセージの発行を要求する。ＳＯＡＰプロセッサ６は、ＷＳ−ＭｅｔａｄａｔａＥｘｃｈａｎｇｅ仕様に基づきＧｅｔＭｅｔａｄａｔａメッセージを生成する。そして、ＳＯＡＰプロセッサ６は、生成したメッセージを、ＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック４を介してネットワーク対応デバイス２００に対してユニキャスト送信する（ステップＳ３）。ＧｅｔＭｅｔａｄａｔａメッセージはＸＭＬ−ＳＯＡＰで記述されており、図４にそのメッセージフォーマットの例を示す。

ネットワーク対応デバイス２００は、クライアントデバイス１００からのＧｅｔＭｅｔａｄａｔａメッセージを受信する（ステップＳ４）。受信したＧｅｔＭｅｔａｄａｔａメッセージは、ＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック１８を介して、ＳＯＡＰプロセッサ２０に通知される。ＳＯＡＰプロセッサ２０は、ＧｅｔＭｅｔａｄａｔａメッセージの内容を解析し、その結果をＷＳＤモジュール２１に通知する。ＷＳＤモジュール２１は、指定された属性情報をクライアントに対して返信するために、ＳＯＡＰプロセッサ２０に対してＷＳ−ＭｅｔａｄａｔａＥｘｃｈａｎｇｅで規定されるＧｅｔＭｅｔａｄａｔａＲｅｓｏｐｎｓｅメッセージ発行を要求する。ＳＯＡＰプロセッサ２０は、ＷＳ−ＭｅｔａｄａｔａＥｘｃｈａｎｇｅ仕様に基づきＧｅｔＭｅｔａｄａｔａＲｅｓｐｏｎｓｅメッセージを生成し、プロトコルスタックを介してクライアントに対してユニキャスト送信する（ステップＳ５）。ＧｅｔＭｅｔａｄａｔａＲｅｓｐｏｎｓｅメッセージはＸＭＬ−ＳＯＡＰで記述されており、図５にそのメッセージフォーマットの例を示す。ＧｅｔＭｅｔａｄａｔａＲｅｓｐｏｎｓｅメッセージ５０１には、デバイスのモデル名（デバイスのＩＤ）５０３、製造会社名５０２などのデバイス属性情報が含まれている。

クライアントデバイス１００は、ネットワーク対応デバイス２００からＧｅｔＭｅｔａｄａｔａＲｅｓｐｏｎｓｅメッセージを受信する（ステップＳ６）。受信したＧｅｔＭｅｔａｄａｔａＲｅｓｐｏｎｓｅメッセージは、ＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック４を介して、ＳＯＡＰプロセッサ６に通知される。ＧｅｔＭｅｔａｄａｔａＲｅｓｐｏｎｓｅメッセージに記述されたデバイスの属性情報は、クライアントデバイス１００のＳＯＡＰプロセッサ６を介して、デバイス属性情報がＷＳＤモジュール８に通知される。ＷＳＤモジュール８は、デバイス属性情報をプラグアンドプレイコントローラ１１に対し通知する。デバイス属性情報の通知をうけたプラグアンドプレイコントローラ１１は、デバイスドライバマネージャを介してデバイス属性情報に一致するドライバを、記憶装置上より検索し、該当するドライバのインストールを実行する（ステップＳ７）。デバイス属性情報には、デバイスの製造者名やデバイス名称が含まれる。そのため、インストールするドライバはそれら属性情報から決定できる。なお、デバイスが複数のサービスをサポートする場合には、ドライバもサービス毎にインストールされる。

デバイスドライバのインストール後は、クライアントデバイス１００においては、そのデバイスドライバに対応するデバイスを用いた処理を実行可能となる。一方、ネットワーク対応デバイス２００も、対応するデバイスドライバがインストールされたクライアントデバイスにより使用可能となる。

＜ネットワークプラグアンドプレイ処理２＞
図６は、本実施形態において、クライアントデバイス１００より、ネットワーク上で利用可能な状態にあるネットワーク対応デバイス２００を検索する場合の制御の流れを説明するフローチャートである。

クライアントデバイス１００のユーティリティ１４、あるいはアプリケーション１５は、ＳＯＡＰプロセッサ６に対してＷＳ−Ｄｉｓｃｏｖｅｒｙ仕様にて規定されるＰｒｏｂｅメッセージの送信を要求する。ＳＯＡＰプロセッサ６は、ＷＳ−Ｄｉｓｃｏｖｅｒｙ仕様に基づきＰｒｏｂｅメッセージを生成し、プロトコルスタックを介してマルチキャストアドレス２３９．２５５．２５５．２５０に対してマルチキャスト送信する。こうして、Ｐｒｏｂｅメッセージに対するネットワーク対応デバイス２００からの応答であるＰｒｏｂｅ Ｍａｔｃｈメッセージの有無により検索処理を実現している。

ＳＯＡＰプロセッサ６は、ＷＳ−Ｄｉｓｃｏｖｅｒｙ仕様で規定されるＰｒｏｂｅメッセージをＴＣＰ／ＵＤＰ／ＩＰプロトコルスタックを介してマルチキャストアドレス２３９．２５５．２５５．２５０に対してマルチキャスト送信する（ステップＳ８）。Ｐｒｏｂｅメッセージは、ＸＭＬ−ＳＯＡＰで記述されており、図７にそのメッセージフォーマットの例を示す。Ｐｒｏｂｅメッセージ７０１には、探索するデバイスのタイプを示すデバイスタイプ７０２が含まれる。本願では一例として、探索の対象はプリンタとしているので、デバイスタイプ７０２には、プリンタを示す「ＰｒｉｎｔＢａｓｉｃ」と記述されている。

ネットワーク対応デバイス２００は、クライアントデバイス１００からＰｒｏｂｅメッセージを受信する（ステップＳ９）。受信したＰｒｏｂｅメッセージはＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック１６を介して、ＳＯＡＰプロセッサ２０に通知される。ＳＯＡＰプロセッサ２０は、Ｐｒｏｂｅメッセージの内容を解析し、その結果をＷＳＤモジュール２１に通知する。ＷＳＤモジュール２１は、通知されたメッセージの内容（すなわち検索対象）が、このネットワーク対応デバイス２００が提供する機能と一致しているか否かを判断する（ステップＳ１０）。一致しないと判断した場合、その情報を無視する。したがって、この場合はネットワーク対応デバイス２００からＰｒｏｂｅ Ｍａｔｃｈレスポンスが発行されることは無い。

一方、Ｐｒｏｂｅメッセージの探索対象が、ネットワーク対応デバイス２００が提供する機能と一致すると判断した場合、ＷＳＤモジュール２１は、ＳＯＡＰプロセッサ２０に対してＰｒｏｂｅ Ｍａｔｃｈメッセージ発行を要求する。ＳＯＡＰプロセッサ６は、ＷＳ−Ｄｉｓｃｏｖｅｒｙ仕様に基づきＰｒｏｂｅ Ｍａｔｃｈメッセージを生成し、プロトコルスタックを介してクライアントに対してユニキャスト送信する（ステップＳ１１）。Ｐｒｏｂｅ ＭａｔｃｈメッセージはＸＭＬ−ＳＯＡＰで記述されており、図８にそのメッセージフォーマットの例を示す。Ｐｒｏｂｅ Ｍａｔｃｈメッセージ８０１には、応答したデバイスのアドレス（たとえばＩＰアドレス）が含まれている。

クライアントデバイス１００がＰｒｏｂｅメッセージを受信すると（ステップＳ１２）、そのメッセージは、ＴＣＰ／ＵＤＰ／ＩＰプロトコルスタックを介して、ＳＯＡＰプロセッサ６に通知される。ＳＯＡＰプロセッサ６は、Ｐｒｏｂｅ Ｍａｔｃｈメッセージの内容を解析し、その結果をＷＳＤモジュール８に通知する。ＷＳＤモジュール８は、Ｐｒｏｂｅ Ｍａｔｃｈメッセージを発行したネットワーク対応デバイス２００の属性情報を取得する。そのために、ＷＳＤモジュール８は、ＳＯＡＰプロセッサ６に対してＷＳ−ＭｅｔａｄａｔａＥｘｃｈａｎｇｅで規定されるＧｅｔＭｅｔａｄａｔａメッセージ発行を要求する。ＧｅｔＭｅｔａｄａｔａメッセージの宛先は、Ｐｒｏｂｅ Ｍａｔｃｈメッセージに記述されたネットワーク対応デバイスのアドレスである。ＳＯＡＰプロセッサ６は、ＷＳ−ＭｅｔａｄａｔａＥｘｃｈａｎｇｅ仕様に基づきＧｅｔＭｅｔａｄａｔａメッセージを生成する。そして、ＳＯＡＰプロセッサ６は、生成したメッセージを、プロトコルスタックを介して、ネットワーク対応デバイス２００に対してユニキャスト送信する（ステップＳ１３）。ＧｅｔＭｅｔａｄａｔａメッセージはＸＭＬ−ＳＯＡＰで記述されており、図２の説明において図４に示したものと同一である。

ネットワーク対応デバイス２００は、クライアントデバイス１００からＧｅｔＭｅｔａｄａｔａメッセージを受信する（ステップＳ１４）。受信したＧｅｔＭｅｔａｄａｔａメッセージは、ＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック１８を介して、ＳＯＡＰプロセッサ２０に通知される。ＳＯＡＰプロセッサ２０は、ＧｅｔＭｅｔａｄａｔａメッセージの内容を解析し、その結果をＷＳＤモジュール２１に通知する。ＷＳＤモジュール２１においては、指定された属性情報をクライアントに対して返信するために、ＳＯＡＰプロセッサ２０に対してＷＳ−ＭｅｔａｄａｔａＥｘｃｈａｎｇｅで規定されるＧｅｔＭｅｔａｄａｔａＲｅｓｏｐｎｓｅメッセージ発行を要求する。ＳＯＡＰプロセッサ２０は、ＷＳ−ＭｅｔａｄａｔａＥｘｃｈａｎｇｅ仕様に基づきＧｅｔＭｅｔａｄａｔａＲｅｓｐｏｎｓｅメッセージを生成し、プロトコルスタックを介してクライアントに対してユニキャスト送信する（ステップＳ１５）。ＧｅｔＭｅｔａｄａｔａＲｅｓｐｏｎｓｅメッセージはＸＭＬ−ＳＯＡＰで記述されており、前述の説明において図５に示したものと同一である。

クライアントデバイス１００は、ネットワーク対応デバイス２００からＧｅｔＭｅｔａｄａｔａＲｅｓｐｏｎｓｅを受信する（ステップＳ１６）。受信したＧｅｔＭｅｔａｄａｔａＲｅｓｐｏｎｓｅメッセージはＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック４を介して、ＳＯＡＰプロセッサ６に通知される。ＧｅｔＭｅｔａｄａｔａＲｅｓｐｏｎｓｅメッセージに記述されたデバイスの属性情報は、クライアントデバイス１００のＳＯＡＰプロセッサ６を介して、デバイス属性情報がＷＳＤモジュール８に通知される。ＷＳＤモジュール８は、デバイス属性情報をプラグアンドプレイコントローラ１１に対し通知する。通知をうけたプラグアンドプレイコントローラ１１は、デバイスドライバマネージャを介してデバイス属性情報に一致するドライバを、記憶装置上より検索し、該当するドライバのインストールを実行する（ステップＳ１７）。この属性の検索は図２で説明した通りである。

デバイスドライバのインストール後は、クライアントデバイス１００においては、そのデバイスドライバに対応するデバイスを用いた処理を実行可能となる。一方、ネットワーク対応デバイス２００も、対応するデバイスドライバがインストールされたクライアントデバイスにより使用可能となる。

＜デバイスドライバのアンインストール＞
ここまでは、標準的なネットワークプラグアンドプレイの手順だが、次に本実施形態において重要なデバイスドライバのアンインストールまでの手順を述べる。その前にまずプリントキュー及びユーザ情報について簡単に説明する。

（プリントキュー）
プリントキューとは、スプールされた印刷データを先入先出順で取り出してプリンタに送信するソフトウエアモジュールである。プリントキューはオペレーティングシステムにより提供される。プリントキューはクライアントにインストールされたプリンタドライバに対応付けられている。ひとつのプリンタドライバに対応付けられるプリントキューはひとつまたは複数である。これは、ひとつのプリントキューはひとつのプリンタに対応しているのに対して、ひとつのプリンタドライバはひとつ又は複数の機種のプリンタに対応しているためである。たとえば複数のプリンタ使用可能であっても、その全てが同一機種であればクライアントにインストールされるドライバはひとつである。

さて、プリンタドライバによるデータ処理を経てスプールされた印刷データは、そのプリンタドライバに対応するプリントキューにより先入先出順でプリンタに対して送信される。プリンタドライバとプリントキューとの対応付けは、本実施形態では、プリンタ（すなわちネットワーク対応デバイス）のアドレスを、プリンタドライバとプリントキューとにそれぞれ対応づけることで実現できる。したがって、たとえばプリンタのアドレスが特定できれば、対応するプリントキューおよびプリンタドライバを特定できる。逆に、プリントキューを特定すれば、対応するプリンタのアドレスから対応するプリンタドライバを特定できる。

さらにプリントキューはデバイスドライバ毎の状態情報を持つ。状態情報には、オフライン状態であることを示すオフライン状態情報が含まれている。その値を「オフライン」に設定することで、そのプリントキューから対応するプリンタに対する印刷ジョブの発行は停止する。再度オフライン状態情報の値を「オンライン」に戻すことで、印刷ジョブの出力を再開する。これらの制御はオペレーティングシステムにより行われているために、オンラインとオフラインの切り替えは、オフライン状態情報の書き替えにより実現される。

図１８にプリントキューと状態情報およびプリンタドライバを対応付けるためのプリントキュー情報１８０１の一例を示す。もちろん図１８の様な形式とは限らず、対応付けが可能であればどのような形式であっても良い。関連づけ情報１８０１はオペレーティングシステムにより管理されるが、オペレーティングシステムがこのようなデータを持たない場合には、ＷＳＤモジュール８により管理しても良い。図１８においては、プリントキューＩＤ１８１１と、状態情報１８１２（図ではオフライン状態情報のみ示す。）と、対応するプリンタドライバ識別子１８１３と、プリンタのアドレス１８１４とが対応付けられている。

（ユーザ情報）
ユーザ情報もまたオペレーティングシステムにより管理される情報である。図１９にその一例を示す。ユーザ情報１９０１には、ログインしているユーザＩＤ１９１１とその権限情報１９１２とが関連づけて保存されている。図１９の例では、ユーザＡは「ゲスト」であり、それぞれ別途指定された権限を有する。権限とは、たとえばファイルへのアクセス権限や、プリンタ等の周辺装置の利用権限等を含む。特に「ゲスト」権限は、あらかじめユーザとして登録されていないユーザによるログインを許可する場合に、そのユーザに対して既定値として割り当てられるユーザ権限である。すなわち、「ゲスト」権限は、一時的な利用者に対して割り当てられることが想定されている。あらかじめユーザ登録されていないユーザがログイン操作を行うと、そのユーザにはゲスト権限が付与され、図１９のユーザ情報に、ログインしたユーザＩＤと「ゲスト」権限であることが登録される。

（アンインストール処理）
さて、クライアントデバイス１００がプリントキュー情報及びユーザ情報を持つことを前提として、プリンタドライバをアンインストールする処理の説明を行う。本願ではゲストユーザとしてログインしている状態でインストールしたデバイスドライバが後述のアンインストール対象となる。

デバイスドライバマネージャ１０は、ログイン時のユーザ情報を取得する（Ｓ２００１）。このログインがクライアントデバイス１００に対するログインを指す場合は、クライアントデバイス１００のオペレーションシステムから現在ログインしているユーザ情報を取得する。つまり、オペレーションシステムは、ユーザごとにゲストかゲストでないかというユーザ管理情報を図２１のように保持している。そして、ログイン時に入力されたユーザＩＤからユーザ属性を判定できる。例えば、現在ログインしたユーザがユーザＡであれば、図２１よりユーザＡはゲストユーザと判定でき、図１９のようなユーザ情報が生成される。また、このログインが、普段使用しないネットワーク環境に接続された状態を指すのであれば次のようにユーザ情報を取得する方法が考えられる。例えば、外部システムに一般ユーザ（つまり、ゲスト以外のユーザ）となるＭＡＣアドレスを登録しておく。そして、クライアントデバイスがネットワークに接続されると、この外部システムに自分のＭＡＣアドレスの有無を問い合わせる。ここで、自分のＭＡＣアドレスが外部システムに登録されていれば、現在のネットワークは普段使用しているネットワークと判定し、登録されていなければ、現在のネットワークは一時的に利用しているネットワークと判定できる。

以上の処理を踏まえることで、デバイスマネージャは、ログインしているユーザがゲストユーザであるか否かを判定する（Ｓ２００２）。つまり、クライアントデバイス１００は、ログインしている利用者が一時的利用者であるか否かを判定する。

ここで、ゲストユーザでログインしていないと判定された場合（Ｓ２００２−Ｎｏ）、クライアントデバイス１００は、現在ログインしているユーザを通常ユーザ（ゲスト以外のユーザ）として管理する（Ｓ２００４）。また、Ｓ２００２にてゲストユーザでログインしていると判定された場合（Ｓ２００２−Ｙｅｓ）、クライアントデバイス１００は、現在ログインしているユーザをゲストユーザとして管理する（Ｓ２００３）。

クライアントデバイス１００は、ＷＳＤモジュール８およびプラグアンドプレイコントローラ１１を用いてデバイスドライバのインストールが実行されたか否かを判定する（Ｓ２００５）。詳細には、現在インストールされているデバイスドライバは図２２のように管理している。この図２２の情報に新たなデバイスドライバが追加された場合、インストールが実行されたと判定できる。

Ｓ２００５にてデバイスドライバのインストールが実行されたと判定された場合、クライアントデバイス１００は、現在ログインしているユーザがゲストユーザであるか否かを判定する（Ｓ２００６）。Ｓ２００６の処理は、Ｓ２００２の処理結果に基づいて判定することができる。Ｓ２００６の判定の結果、現在ログインしているユーザがゲストでないと判定された場合、クライアントデバイス１００は、Ｓ２００５にてインストールされたデバイスドライバを通常ドライバとして管理する（Ｓ２００８）。また、Ｓ２００６の判定の結果、現在ログインしているユーザがゲストであると判定された場合、クライアントデバイス１００は、Ｓ２００５にてインストールされたデバイスドライバをゲスト用のデバイスドライバとして管理する（Ｓ２００７）。具体的には、クライアントデバイス１００のＲＡＭ１７０２に図２２のような形式でデバイスドライバ情報が管理される。なお、Ｓ２００７にてゲストドライバとしてインストールされたデバイスドライバを管理する場合、次に実行される処理は、図９のＳ１９、図１１のＳ１１１１、図１４のＳ１３１１の処理前となる。

ここで、図９について説明する。図９は、本実施形態において、ネットワークデバイスがネットワークから離脱する際の制御の流れを説明するフローチャートである。この手順においては上述したプリントキュー情報１８０１およびユーザ情報１９０１が参照される。なお、ステップＳ１９〜ステップＳ２５は、クライアントデバイス１００のＣＰＵ１７０１によって実行され、ステップＳ１８およびステップＳ２６はネットワーク対応デバイス２０００のＣＰＵ１７２１によって実行される。なお、ステップＳ１９〜ステップＳ２４の処理を実行するクライアントデバイス１００は、周辺機器と接続されたコンピュータにより実行されるプログラムを保持する。

ネットワーク対応デバイス２００をネットワークから離脱させるために、ユーザはネットワーク対応デバイス２００の操作パネル等からシャットダウン操作を行う。その操作をトリガとしてＷＳＤモジュール２１は、ＳＯＡＰプロセッサ２０に対してＢｙｅメッセージの送信を要求する。ＳＯＡＰプロセッサ２０は、ＷＳ−Ｄｉｓｃｏｖｅｒｙ仕様に基づきＢｙｅメッセージを生成し、プロトコルスタックを介してマルチキャストアドレス２３９．２５５．２５５．２５０に対してマルチキャスト送信する（ステップＳ１８）。ＢｙｅメッセージはＸＭＬ−ＳＯＡＰで記述されており、図１０にそのメッセージフォーマットの例を示す。Ｂｙｅメッセージ１００１にはＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅタグに埋め込まれたアドレス情報１００２が含まれる。

クライアントデバイス１００はネットワーク対応デバイス２００からＢｙｅメッセージを受信する。受信したＢｙｅメッセージは、ＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック４を介して、ＳＯＡＰプロセッサ６に通知される。ＳＯＡＰプロセッサ６は、Ｂｙｅメッセージの内容を解析し、その結果をＷＳＤモジュール８に通知する（ステップＳ１９）。クライアントデバイス１００は、ステップＳ１９において周辺機器からの離脱メッセージ受信する。

ＷＳＤモジュール８は、デバイスのアドレスをプラグアンドプレイコントローラ１１に対し通知する。通知をうけたプラグアンドプレイコントローラ１１は、デバイスドライバマネージャ１０を介してデバイスのアドレスと関連のあるプリントキューを記憶装置上より検索する。この検索は、たとえば図１８のプリント情報を参照して行う。通知されたプリンタのアドレスを図１８のプリントキュー情報から検索し、発見されたアドレスに対応するプリントキュー識別子（ＩＤ）が、目的のプリントキュー識別子（ＩＤ）である。

そして、プラグアンドプレイコントローラ１１は、該当するプリントキューをオフラインにする（ステップＳ２０）。すなわち、クライアントデバイス１００は、発見されたプリントキューのオフライン状態情報１８０２を「オフライン」とする。なお、このオフライン時の視覚的効果としてプリントキューのアイコンをグレーや半透明にしてユーザーにオフライン状態であることを明確に伝えることも可能である。

さらに、デバイスドライバマネージャ１０は、クライアントデバイス１００の全ユーザーアカウント情報を探索して、全てのユーザーアカウントがゲストユーザーかどうか調べる（ステップＳ２１）。この調査は、オペレーションシステムから図１９のユーザ情報の権限欄１９１２を取得して参照し、すべてが「ゲスト」であるか判定することで行われる。なお、図１９の場合、ログインユーザがユーザＡのみであり、ユーザＡの属性はゲストとなっている。よって、デバイスドライバマネージャ１０は、ステップＳ２１において全てのユーザアカウントがゲストユーザであると判定する。

デバイスドライバマネージャ１０が、全てのユーザーアカウントがゲストユーザーであると判定した場合、Ｂｙｅメッセージの送信元プリンタに対応するデバイスドライバがゲスト用のデバイスドライバであるか否かを判定する（ステップＳ２２）。つまりクライアント１００は、受信した離脱メッセージの送信元の周辺機器に対応するデバイスドライバが所定の条件に一致するか否かを判定する。詳細には、図１８を用いてＢｙｅメッセージの送信元デバイスのアドレスからプリントキューＩＤを特定する。そして、デバイスドライバマネージャ１０は、特定されたプリントキューＩＤおよび図２２の情報を用いて、ゲストユーザによってインストールされたデバイスドライバであるか否かを判定することができる。Ｓ２２の判定処理により、Ｂｙｅメッセージの送信元デバイスに対応するデバイスドライバがゲストドライバでない場合、アンインストール対象ではないため通常操作へと処理を移す。一方、Ｓ２２においてＢｙｅメッセージの送信元デバイスに対応するプリンタドライバがゲストドライバであると判定された場合、該プリンタドライバを利用する別のプリンタの有無を判定する（ステップＳ２３）。つまり、ステップＳ２３においてクライアントデバイス１００は、Ｂｙｅ要求（離脱メッセージ）を受信した場合に、離脱メッセージ送信元の周辺機器に対応するデバイスドライバが、他の周辺機器のために利用されているかを判定する。そして、ステップＳ２３により、ステップＳ１９にて受信したＢｙｅ要求の送信元の周辺機器に対応するデバイスドライバが他の周辺機器のために利用されていないと判定された場合、クライアントデバイス１００は、デバイスドライバを削除する。具体的には、Ｂｙｅメッセージの送信元デバイスのアドレスをプリントキュー情報１８０１から検索する。そして、そのアドレスに対応するプリンタドライバ識別子を読み、そのプリンタドライバ識別子をプリントキュー情報１８０１から検索する。複数の検索結果が得られれば、そのプリンタと同じデバイスドライバを使用する別のプリントキューが存在すると判定できる（Ｓ２３−Ｎｏ）。この場合には、そのデバイスドライバは、Ｂｙｅメッセージの送信元デバイス以外のデバイス用にも利用されている。したがって、そのデバイスドライバは削除してはならない。逆に、Ｂｙｅメッセージの送信元デバイスに対応するデバイスドライバが、そのＢｙｅメッセージの送信元デバイスのみのために使用されており、他のデバイスのために利用されていない場合には、そのドライバはもはや使用されることはないと判定できる。例えば、図１８の場合、プリントキュー１のプリンタドライバ識別子は対応プリンタドライバ１である。また、プリントキュー３のプリンタドライバ識別子は対応プリンタドライバ１である。よって、プリントキュー１に対応するアドレスからＢｙｅ情報を取得した場合、プリントキュー１に対応する対応プリンタドライバ１はプリントキュー３でも使用されているので、プリンタドライバ識別子「対応プリンタドライバ１」に対応するプリンタドライバはアンインストールされない。

デバイスドライバマネージャ１０が、前記デバイスのアドレスと関連のあるプリントキューに対応するデバイスドライバを使用する別のプリントキューが存在しないと判定する（ステップＳ２３−ＹＥＳ）。その場合、プラグアンドプレイコントローラ１１は、ステップＳ１８にてＢｙｅメッセージを送信してきたデバイスに対応するデバイスドライバをアンインストールする（ステップＳ２４）。つまり、クライアントデバイス１００は、ステップＳ２２においてデバイスドライバ情報が所定の条件に一致すると判定した場合、離脱メッセージ送信元の周辺機器に対応するデバイスドライバを削除する。

以上説明したステップ１８から２５までを、ネットワーク対応デバイスがＢｙｅメッセージを発行するごとに繰り返し実行する。これにより、クライアントデバイス１００は、全ユーザーアカウントがゲストであり、かつデバイスドライバが別のプリントキューで使用されていない場合には、デバイスドライバの自動アンインストールを実行できる。つまり、クライアントデバイス１００は、一時的利用者がログインした後にインストールされたデバイスドライバをゲスト用デバイスドライバとして識別可能に記憶する記憶手段を有している。そしてクライアント１００は、Ｂｙｅ要求を受信した後、記憶手段の情報に基づいて離脱メッセージの送信元の周辺機器に対応するデバイスドライバが、一時的利用者がログインした後にインストールされたゲスト用デバイスドライバと対応するかを判定する。そしてクライアントデバイス１００は、離脱メッセージの送信元の周辺機器に対応するドライバが、一時的利用者がログインした後にインストールされたゲスト用ドライバと対応すると判定した場合、離脱メッセージ送信元の周辺機器に対応するドライバを削除する。なお、本願において一時的利用者とはゲストユーザと同義である。

なお、ステップＳ２１におけるユーザ権限の判定は、そのクライアントの利用方法を判定するために行われる。たとえばウインドウズ（登録商標）オペレーティングシステムの下では、クライアントは通常、特定のユーザに割り当てられ、そのユーザにより専有的に利用される。そのようなユーザはあらかじめクライアントに登録され、「ユーザ」や「パワーユーザ」あるいは「アドミニストレータ（管理者）」権限が付与されている。これに対して、携帯して利用する携帯型クライアントは不特定のユーザに共有されることが多い。このようなクライアントでは、ユーザは「ゲスト」権限でログインしてそのクライアントを利用する。そこで本実施形態では、ログインユーザが「ゲスト」権限を持つ場合、そのクライアントは共用のクライアントであると推定している。そして携帯型共用クライアントは、不特定のネットワークに接続されるために、使用するネットワークデバイスもネットワーク毎に異なる。そこで、本実施形態では、ステップＳ２１の判定の結果、ユーザ権限が「ゲスト」ある場合には、Ｂｙｅメッセージの送信元デバイスは当該ネットワークにおいて一時的に利用されたデバイスであると判定しても良い。そして、プラグアンドプレイコントローラ１１は、Ｂｙｅメッセージを送信したデバイスに対応するデバイスドライバを削除する。

以上の通り本実施形態のクライアントデバイスは、デバイスからネットワークの離脱メッセージ（Ｂｙｅメッセージ）を受けると、Ｂｙｅメッセージを送信したデバイスに対応するデバイスドライバがゲストユーザによってインストールされたか否かを判定する。そして、ゲストユーザによってインストールされたデバイスドライバを自動的に削除する。このため、デバイスドライバの管理の労力を節約することができる。また、クライアント端末の資源の浪費を防止できる。また、ユーザに提示するデバイスの候補から使用できないデバイスドライバを削除できるので、ユーザの操作性を向上させることができる。さらに、ゲストユーザによってインストールされたデバイスドライバを削除するためクライアントの構成を不用意に変更してしまうことがない。さらに、図９のＳ２４では、「他のプリントキューで同じドライバを使用しているか否か」を判定しているため、ユーザが必要とするデバイスドライバを残して、適切なアンインストール処理を実行することができる。

［第２実施形態］
本実施形態では、ネットワーク対応デバイス２００の検索機能、およびＨｅｌｌｏメッセージ応答に対する具体的手段、およびプラグアンドプレイ処理は第１の実施形態と同様である。クライアントデバイス１００は、それぞれフローチャート図２、６に示す手順で処理を実行する。ここまでは、標準的なネットワークプラグアンドプレイの手順だが、次に本実施形態において重要なデバイスドライバのアンインストールまでの手順を述べる。

図１１は、本実施形態において、ネットワークデバイスがネットワークから離脱する際の制御の流れを説明するフローチャートである。図１１において、図９と同じ内容のステップは同じ参照番号で示す。なお、ステップＳ１１１１からステップＳ１１１５までの処理はクライアントデバイス１００のＣＰＵ１７０１によって実行され、ステップＳ１１０１およびステップＳ１１１６の処理は、ネットワーク対応デバイス２００のＣＰＵ１７２１によって実行される。

ネットワーク対応デバイス２００をネットワークから離脱させる際に、ユーザはシャットダウン等の操作を行う。その操作によってネットワーク対応デバイス２００がネットワークから離脱する際、ＷＳＤモジュール２１は、ＳＯＡＰプロセッサ２０に対してＢｙｅメッセージの送信を要求する。ＳＯＡＰプロセッサ２０は、ＷＳ−Ｄｉｓｃｏｖｅｒｙ仕様に基づきＢｙｅメッセージを生成し、プロトコルスタックを介してマルチキャストアドレス２３９．２５５．２５５．２５０に対してマルチキャスト送信する（ステップＳ１１０１）。この処理は図９のステップＳ１８と同じである。ＢｙｅメッセージはＸＭＬ−ＳＯＡＰで記述されており、前述の説明において図１０に示したものと同一である。

クライアントデバイス１００はＢｙｅメッセージを受信する。受信されたＢｙｅメッセージはＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック４を介して、ＳＯＡＰプロセッサ６に通知される。ＳＯＡＰプロセッサ６は、Ｂｙｅメッセージの内容を解析し、その結果をＷＳＤモジュール８に通知する（ｓｔｅ１１１１１）。この処理はステップＳ１９で示したものと同一である。ＷＳＤモジュール８は、デバイスのアドレスをプラグアンドプレイコントローラ１１に対し通知する。通知をうけたプラグアンドプレイコントローラ１１はデバイスドライバマネージャ１０を介してデバイスのアドレスと関連のあるプリントキューを、記憶装置上より検索し、該当するプリントキューをオフラインにする（ステップＳ１１１２）。この検索やオフライン処理はステップＳ２０で示したものと同一である。なお、このオフライン時の視覚的効果としてプリントキューのアイコンをグレーや半透明にしてユーザーにオフライン状態であることを明確に伝えることも可能である。

さらに、デバイスドライバマネージャ１０は、Ｂｙｅメッセージの送信元プリンタに対応するデバイスドライバがゲスト用のデバイスドライバであるか否かを判定する（Ｓ１１１３）。なお、Ｓ１１１３の処理は、図９のＳ２２の処理と同様の処理である。Ｂｙｅメッセージの送信元プリンタに対応するドライバがゲスト用である場合、デバイスドライバマネージャ１０は、オフラインになった各プリントキューに対しドライバのアンインストール確認ダイアログ１５０１（図１５）を表示する（ステップＳ１１１４）。ここで、表示中に、Ｂｙｅメッセージの送信元デバイスのデバイス名を表示すると、ユーザがデバイスを識別でき、一層操作性が向上する。ダイアログボックス１５０１に対してユーザが「はい」ボタン１５０２を押すことで、デバイスドライバのアンインストールが続行される。「いいえ」１５０３が押されるとデバイスドライバのアンインストールは中止される。

クライアントデバイス１００は、ユーザによってドライバのアンインストールが許可された場合（「はい」が押されたら）、プラグアンドプレイコントローラ１１は、Ｂｙｅメッセージを送信してきたデバイスに対応するドライバがゲスト用であるか判定する。そして、ゲスト用であると判定された場合、プラグアンドプレイコントローラ１１は、Ｂｙｅメッセージの送信元デバイスのデバイスドライバのアンインストールを実行する（ステップＳ１１１６）。

つまり、クライアントデバイス１００は、Ｂｙｅ要求（離脱メッセージ）を受信することに応じて、離脱メッセージ送信元の周辺機器に対応するデバイスドライバを削除するかを問い合わせる。そして、クライアントデバイス１００は、問い合わせに対して削除が指示された場合に、Ｂｙｅ要求の送信元の周辺機器のデバイスドライバを削除する。
Ｂｙｅメッセージが発行される毎にステップ１１１１から１１１５まで繰り返し実行する。これにより、クライアントデバイス１００は、デバイスドライバのアンインストールをユーザが許可したときに限り、デバイスドライバの自動アンインストールが実行される。本実施形態では第１実施形態と異なり、アンインストールの継続のために必ずユーザの介入が必要なために、削除するドライバについてユーザの確認を受けることができる。

［第３実施形態］
ネットワーク対応デバイス２００の検索機能、およびＨｅｌｌｏメッセージ応答に対する具体的手段、およびプラグアンドプレイ処理は第１の実施形態と同様である。ネットワーク対応デバイス２００は、フローチャート図２のステップＳ１，４，５、または図６のステップＳ９−１１，１４，１５に示す手順で処理を実行する。クライアントデバイス１００は、図２のステップＳ７またはステップＳ１７に続けて、図１２の処理を行う。

図１２は、本実施形態において、クライアントデバイス１００による、ネットワークデバイスに対するプラグアンドプレイ処理直後の制御の流れを説明するフローチャートである。

図２と同一のネットワーク対応デバイス２００に対するプラグアンドプレイ処理、もしくは図６と同一のネットワーク対応デバイス２００に対する検索処理によって、クライアント１００はデバイスドライバをインストールする。

デバイスドライバのインストール後、プラグアンドプレイコントローラ１１は、デバイスドライバマネージャ１０を介してユーザインターフェースとしてダイアログボックス１６０１（図１６）を表示する（ステップＳ１２０１）。このダイアログボックスは、デバイスが不要になった際に、デバイスドライバのアンインストールを自動実行するかどうかを、あらかじめ確認しておくためのユーザインターフェースである。そして、クライアントデバイス１００は、どのボタンが押されたか判定する（ステップＳ１２０２）。「はい」ボタン１６０２が押されたと判定した場合、自動アンインストール情報１７１１ａがｔｒｕｅ（真）にセットされて保存される。本例では、ＣＰＵ２７０１が、ハードディスク１７１１に、インストールされたドライバに対応するデバイスのデバイスアドレスと対応付けて保存する（ステップＳ１２０３）。たとえば自動アンインストール情報１７１１ａを、図１８のプリントキュー情報の１項目として追加しても良い。「いいえ」ボタン１６０３が押されたと判定した場合、自動アンインストール情報１７１１ａがｆａｌｓｅ（偽）にセットされ、保存される。本例では、ＣＰＵ２７０１が、ハードディスクにインストールされたドライバに対応するデバイスのデバイスアドレスと対応透けて保存する（ステップＳ１２０４）。ステップＳ１２０３およびステップＳ１２０４にて保存される情報は、もちろんデバイスアドレスと対応付けて保存される。この情報（フラグ）は、デバイスが不要になった際にデバイスドライバのアンインストールを自動実行するかどうか確認するために参照される。このように、デバイスドライバの自動削除を行うか否かを、当該デバイスドライバがインストールされた時点でユーザが選択して、選択結果を保存しておく。

図１３は、本実施形態において、ネットワークデバイスがネットワークから離脱する際の制御の流れを説明するフローチャートである。

ネットワーク対応デバイス２００をネットワークから離脱させる際に、ユーザはシャットダウン等の操作を行う。その操作によってネットワーク対応デバイス２００がネットワークから離脱する際、ＷＳＤモジュール２１は、ＳＯＡＰプロセッサ２０に対してＢｙｅメッセージの送信を要求する。ＳＯＡＰプロセッサ２０は、ＷＳ−Ｄｉｓｃｏｖｅｒｙ仕様に基づきＢｙｅメッセージを生成し、プロトコルスタックを介してマルチキャストアドレス２３９．２５５．２５５．２５０に対してマルチキャスト送信する（ステップＳ１３０１）。この処理はステップＳ１８で示したものと同一である。ＢｙｅメッセージはＸＭＬ−ＳＯＡＰで記述されており、前述の説明において図１０に示したものと同一である。

クライアントデバイス１００はＢｙｅメッセージを受信する。受信されたＢｙｅメッセージはＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック４を介して、ＳＯＡＰプロセッサ６に通知される。ＳＯＡＰプロセッサ６は、Ｂｙｅメッセージの内容を解析し、その結果をＷＳＤモジュール８に通知する（ステップＳ１３１１）。この処理はステップＳ１９で示したものと同一である。ＷＳＤモジュール８は、デバイスのアドレスをプラグアンドプレイコントローラ１１に対し通知する。通知をうけたプラグアンドプレイコントローラ１１は、デバイスドライバマネージャ１０を介してデバイスのアドレスと関連のあるプリントキューを記憶装置上より検索し、該当するプリントキューをオフラインにする（ステップＳ１３１２）。この処理はステップＳ２０で示したものと同一である。なお、このオフライン時の視覚的効果としてプリントキューのアイコンをグレーや半透明にしてユーザーにオフライン状態であることを明確に伝えることも可能である。

さらに、デバイスドライバマネージャ１０は、Ｂｙｅメッセージの送信元プリンタに対応するデバイスドライバがゲスト用のデバイスドライバであるか否かを判定する（Ｓ１３１３）。なお、Ｓ１３１３の処理は、図９のＳ２２の処理と同様の処理である。Ｂｙｅメッセージの送信元プリンタに対応するドライバがゲスト用であると判定された場合、デバイスドライバマネージャ１０は、ステップＳ１２０３またはステップＳ１２０４で設定された自動アンインストール情報１７１１ａを参照する（ステップＳ１３１４）。デバイスイドライバマネージャ１０は、Ｂｙｅメッセージの送信元デバイスのアドレスに関連づけられている自動アンインストール情報１７１１ａを参照して、その値を判定する（ステップＳ１３１５）。デバイスドライバマネージャ１０が、自動アンインストール情報１７１１ａの値がＴＲＵＥであると判定した場合、プラグアンドプレイコントローラ１１は、Ｓ１２０１のＢｙｅメッセージの送信元デバイスに対応するドライバがゲスト用であるか否かを判定する。そして、ゲスト用であると判定された場合、プラグアンドプレイコントローラ１１は、当該デバイスドライバのアンインストールを実行する（ステップＳ１３１６）。

以上説明した制御をステップ１３１１から１３１５まで繰り返し実行する。こうすることで、クライアントデバイス１００は、ユーザーがデバイスドライバの自動アンインストールを許可している場合に、デバイスドライバの自動アンインストールを実行できる。しかもその自動アンインストールの許可はデバイス毎に設定可能である。つまり、クライアントデバイス１００は、周辺機器に対応するデバイスドライバのインストールの際に、デバイスドライバの自動削除を示す自動削除情報を登録する。そして、クライアントデバイス１００は、離脱メッセージを受信した場合に、登録された自動削除情報を参照する。そして、自動削除が可である旨が登録されていた場合に、クライアントデバイス１００は、Ｂｙｅ要求の送信元の周辺機器に対応するデバイスドライバを削除する。このため、ゲストユーザがインストールしたデバイスドライバであっても重要なデバイスであり、必要に応じて残しておくべきデバイスドライバを自動アンインストールの対象とせず、それ以外のデバイスは自動アンインストールする、といった設定が可能となる。すなわち、デバイス毎に、そのデバイスのＢｙｅメッセージをトリガとする自動アンインストールの可否を設定可能となる。

［第４実施形態］
上述した第１，２，３実施形態において、クライアントデバイス１００がデバイスドライバをアンインストールする際の処理の起点は、ネットワーク対応デバイス２００が送信するＢｙｅメッセージの受信にあった。ところが、クライアントデバイス１００が一時的にサスペンドやシャットダウンなどの状態にあってＢｙｅメッセージを受信できない場合もある。そのような場合に、ネットワーク対応デバイス２００がＢｙｅメッセージを送信してきたら、第１，２，３実施形態のクライアントは自動アンインストール処理を実施できない。そこで、クライアントデバイス１００がＢｙｅメッセージを受信できなかった場合の実施形態を以下に示す。

ネットワーク対応デバイス２００の検索機能、およびＨｅｌｌｏメッセージ応答に対する具体的手段、およびプラグアンドプレイ処理は第１の実施形態と同様である。クライアントデバイス１００は、それぞれフローチャート図２、６に示す手順で処理を実行する。ここまでで、クライアントデバイス１００にデバイスドライバのインストールが完了する。またクライアントがネットワーク対応デバイス（プリンタ）からＢｙｅメッセージを受信した場合の手順は、第１乃至第３実施形態のいずれかである。すなわち本実施形態は、第１乃至第３実施形態のいずれかに組み合わされてクライアントデバイスに適用される。

次に、クライアントデバイス１００はデバイスからのＢｙｅメッセージを受信できなかった状態を仮定する。例えば、クライアントデバイス１００が一時的にサスペンドしたり、あるいはシャットダウンしたりして、Ｂｙｅメッセージを受信できない状態に移行する。そしてその後、クライアントデバイス１００は再びＢｙｅメッセージを受信可能な正常な状態に復帰する。このような状況において、図１４は、クライアントデバイス１００が、Ｂｙｅメッセージを受信可能な状態に復帰した直後に、ネットワーク上で利用可能な状態にあるネットワーク対応デバイス２００を検索する処理の流れを説明するフローチャートである。

クライアントデバイス１００は、サスペンド状態から復帰したり、電源を投入されたりして、Ｂｙｅメッセージを受信可能な状態に復帰する。その直後、クライアント１００のユーティリティ１４、あるいはアプリケーション１５は、ＳＯＡＰプロセッサ６に対しＷＳ−Ｄｉｓｃｏｖｅｒｙ仕様にて規定されるＰｒｏｂｅメッセージの送信を要求する。ＳＯＡＰプロセッサ６は、ＷＳ−Ｄｉｓｃｏｖｅｒｙ仕様に基づきＰｒｏｂｅメッセージを生成し、ＴＣＰ／ＵＤＰ／ＩＰプロトコルスタックを介してマルチキャストアドレス２３９．２５５．２５５．２５０に対してマルチキャスト送信する（Ｓ１４０１）。Ｐｒｏｂｅメッセージで探索するデバイスは本例ではプリンタである。

ネットワーク対応デバイス２００がＰｒｏｂｅメッセージを受信すると（ステップＳ１４１１）、受信したＰｒｏｂｅメッセージはＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック１６を介して、ＳＯＡＰプロセッサ２０に通知される。ＳＯＡＰプロセッサ２０は、Ｐｒｏｂｅメッセージの内容を解析し、その結果をＷＳＤモジュール２１に通知する。ＷＳＤモジュール２１は、通知されたメッセージの内容（デバイスタイプ）とこのネットワーク対応デバイス２００が提供する機能が一致しているか否かを判断する（ステップＳ１４１２）。ＷＳＤモジュール２１が、一致しないと判断した場合、その情報を無視する（ステップＳ１４１２−ＮＯ）。ステップＳ１４１２によって一致しないと判断された場合、ネットワーク対応デバイス２００からＰｒｏｂｅ Ｍａｔｃｈレスポンスが発行されることは無い。

一方、一致すると判断した場合、ＷＳＤモジュール２１は、ＳＯＡＰプロセッサ２０に対してＰｒｏｂｅ Ｍａｔｃｈメッセージ発行を要求する。ＳＯＡＰプロセッサ６は、ＷＳ−Ｄｉｓｃｏｖｅｒｙ仕様に基づきＰｒｏｂｅ Ｍａｔｃｈメッセージを生成し、プロトコルスタックを介してクライアントに対してユニキャスト送信する（ステップＳ１４１３）。Ｐｒｏｂｅ Ｍａｔｃｈメッセージ８０１はＸＭＬ−ＳＯＡＰで記述されており、前述の説明において図８に示したものと同一である。

クライアント１００は、Ｐｒｏｂｅメッセージの送信後、そのＰｒｏｂｅメッセージに対するＰｒｏｂｅ Ｍａｔｃｈメッセージを一定時間待つ（ステップＳ１４０２）。一定時間内にＰｒｏｂｅ Ｍａｔｃｈメッセージを受信した場合、その送信元のデバイスはネットワークに接続されていると判断できる。すなわち、受信したＰｒｏｂｅ Ｍａｔｃｈメッセージの有無によりネットワーク対応デバイス２００がネットワークから離脱しているかどうか判断する。

すなわち、クライアントデバイス１００は、Ｐｒｏｂｅ Ｍａｔｃｈメッセージを受信すると（ステップＳ１４０２−Ｙｅｓ）、ＴＣＰ／ＵＤＰ／ＩＰプロトコルスタックを介して、そのメッセージはＳＯＡＰプロセッサ６に通知される。ＳＯＡＰプロセッサ６は、受信したＰｒｏｂｅ Ｍａｔｃｈメッセージの内容を解析し、その結果をＷＳＤモジュール８に通知する。

クライアントデバイス１００が所定時間内に受信したＰｒｏｂｅ Ｍａｔｃｈメッセージの送信元デバイスの識別情報（たとえばアドレス）は、ＷＳＤモジュール８からプラグアンドプレイコントローラ１１に対し通知される。デバイスのアドレスの通知をうけたプラグアンドプレイコントローラ１１は、デバイスドライバマネージャ１０を介して、通知されたアドレスに該当しないプリントキューを、プリントキュー情報１８０１から検索する（ステップＳ１４０２）。プラグアンドプレイコントローラ１１は、検索の結果発見されたプリントキューをオフラインにする（ステップＳ１４０３）。つまり、プラグアンドプレイコントローラ１１は、Ｐｒｏｂｅ Ｍａｔｃｈメッセージを送信してこなかったネットワーク対応デバイスを特定して、対応するプリントキューをオフラインにする。このオフライン時の視覚的効果としてプリントキューのアイコンをグレーや半透明にしてユーザーにオフライン状態であることを明確に伝えることも可能である。

デバイスドライバマネージャ１０は、Ｂｙｅメッセージの送信元プリンタに対応するデバイスドライバがゲスト用のデバイスドライバであるか否かを判定する（Ｓ１４０４）。なお、Ｓ１４０４の処理は、図９のＳ２２の処理と同様の処理である。Ｂｙｅメッセージの送信元プリンタに対応するドライバがゲスト用であると判定された場合、プラグアンドプレイコントローラ１１は、ステップ１４０３でオフラインにしたプリントキューに対応するドライバをアンインストールする（Ｓ１４０４）。なお、ステップＳ１４０４においてドライバがアンインストールされてしまうので、ステップＳ１４０３は省略可能である。

以上のようにして、ステップＳ１４０１からステップＳ１４０４までを実行する。こうしてクライアントデバイス１００は、ネットワーク対応デバイス２００が送信したＢｙｅメッセージを受信できない場合であっても、接続されていないデバイスに対応するデバイスドライバの自動アンインストールが実行可能となる。つまり、クライアントデバイス１００が、ネットワークに接続された際に、ネットワーク上の所定条件に該当する周辺機器の存在を問い合わせるプローブメッセージを送信する。そして、クライアントデバイス１００は、プローブメッセージに対する応答を受信する。ここで、クライアントデバイス１００は、既にインストールされており、かつ、プローブメッセージに対する応答がない周辺機器に対応するデバイスドライバを削除する。

以上のとおり、ゲストユーザーが利用するノートパソコン、ＰＤＡ、携帯電話といった情報処理装置にネットワークＰｎＰ機能でインストールされたソフトウエアを、それが不要な場合には自動的に削除することができる。その結果、実際に使うことのでるドライバ、ユーティリティ、アプリケーションなどのソフトウエアが残されることになり、使用上の利便性が大いに向上する。また、ユーザーにとって利用不可能なドライバ、ユーティリティ、アプリケーション等のソフトウエアにより、情報処理装置のメモリ等のハードウェア資源が消費されることを防止することが可能となる。

［その他の実施形態］
上述した実施形態においては、ネットワークデバイスの検索手段、およびネットワークデバイスがネットワークに参加したことを通知する手段としてＷＳ−Ｄｉｓｃｏｖｅｒｙで定義されるプロトコルを採用している。しかし、この限りではなく例えばＵＰｎＰ（ｔｍ） ｖ１で規定されるＳＳＤＰ（Ｓｉｍｐｌｅ Ｓｅｒｖｉｃｅ Ｄｉｓｃｏｖｅｒｙ Ｐｒｏｔｏｃｏｌ）。さらに、ＧＥＮＡ（Ｇｅｎｅｒａｌ Ｅｖｅｎｔ Ｎｏｔｉｆｉｃａｔｉｏｎ Ａｒｃｈｉｔｅｃｔｕｒｅ）などを利用することでも実現可能である。ネットワークデバイスの検索プロトコルとしては、ネットワークデバイスの属性情報を取得するためのアドレスネットワークデバイスを制御するための送信先を取得することが可能であるプロトコルであれば、いずれのプロトコルであっても適用可能である。

また上述した実施形態においては、通信媒体としてＥｔｈｅｒｎｅｔ（登録商標），ＷｉＦｉ（登録商標）（ワイヤレス通信 ＩＥＥＥ８０２．１ａ／ｂ／ｇ）、およびＢｌｕｅｔｏｏｔｈ（登録商標）を利用して実現している。これに対して、本発明は、デバイスの発見、およびデバイスが機能実行を開始したことを通知することが可能な通信媒体であれば、ローカルＩ／Ｏ、ネットワークのいずれの場合も適用可能である。

また上述した実施形態においては、プラグアンドプレイの一例として、発見したネットワークデバイスに対応したドライバのインストールおよびアンインストールを説明している。これに加えて、ネットワークデバイスを利用、制御するために必要なユーティリティ、アプリケーションなどをクライアントデバイス１００への自動的なインストールおよびアンインストールにも適用可能である。

また、上述した実施形態においてネットワークデバイスとしてプリンタに対する実装例を示したが、通信媒体を介して利用、制御可能なデバイスであれば、スキャナ、ストレージデバイス等、いずれのデバイスに対しても適用可能である。

また、上述した実施形態においては、各実施形態を単独で実施することはもちろん、複数の実施形態を組み合わせて実施してもかまわない。

また、上述した実施形態においては、ネットワークデバイスがプリンタの場合、デバイスドライバをアンインストールしている。これに対して、文字通りプリンタドライバをアンインストールするだけでなく、プリントキューを削除するがプリンタドライバはアンインストールしなくともよい。このようにすれば処理負担を軽減できるし、また、再度同じドライバをインストールする必要がなくなる。

また、上述した実施形態においては、クライアントデバイス１００によりネットワークデバイスを制御するためのドライバ、アプリケーション、ユーティリティなどのソフトウエアは、メモリやハードディスク上に保持する場合が多い。しかし、その他にもネットワークデバイス上に保持されている場合、あるいは第３のサーバー上に保持されている場合などにも適用可能である。

また、上述した実施形態においては、ネットワーク環境を識別するための情報として、ＤＨＣＰ Ｅｎａｂｌｅｄ、ＩＰ Ａｄｄｒｅｓｓ、Ｓｕｂｎｅｔ Ｍａｓｋ、Ｄｅｆａｕｌｔ Ｇａｔｅｗａｙ、ＤＮＳ Ｓｅｒｖｅｒ、ＤＨＣＰ Ｓｅｒｖｅｒ
を利用したＴＣＰ／ＩＰネットワークにおける実施形態を示した。これに限らず、一義的に他のネットワーク環境と識別することが可能ないずれの情報に対しても、本発明を適用することが可能である。

また、上述した実施形態におけるクライアントデバイス１００及びネットワーク対応デバイス２００における各処理機能は、各処理機能を実現する為のプログラムをメモリから読み出してＣＰＵ（中央演算装置）が実行することによりその機能を実現させる。しかしこれに限定さるものではなく、各処理機能の全部または一部の機能を専用のハードウェアにより実現してもよい。また、上述したメモリは、光磁気ディスク装置、フラッシュメモリ等の不揮発性のメモリである。さらに、メモリは、ＣＤ−ＲＯＭ等の読み出しのみが可能な記録媒体、ＲＡＭ以外の揮発性のメモリ、あるいはこれらの組合せによるコンピュータ読み取り、書き込み可能な記録媒体より構成されてもよい。

また、クライアントデバイス１００及びネットワーク対応デバイス２００内の各機能を実現する為のプログラムをコンピュータ読み取り可能な記録媒体に記録して、記録されたプログラムをコンピュータに読み込ませて実行することにより各処理を行っても良い。なお、ここでいう「コンピュータ」とは、ＯＳや周辺機器等のハードウェアを含むものとする。具体的には、記憶媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書きこまれる。その後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含む。

また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバーやクライアントとなるコンピュータシステム内部の揮発メモリ（ＲＡＭ）である。このように、一定時間プログラムを保持しているものも含むものとする。

また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことをいう。

また、上記プログラムは、前述した機能の一部を実現する為のものであっても良い。さらに、前述した機能をコンピュータシステムに既に記録されているプログラムとの組合せで実現できるもの、いわゆる差分ファイル（差分プログラム）であっても良い。

また、上記のプログラムを記録したコンピュータ読み取り可能な記録媒体等のプログラムプロダクトも本発明の実施形態として適用することができる。上記のプログラム、記録媒体、伝送媒体およびプログラムプロダクトは、本発明の範疇に含まれる。

以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。

本発明の一実施形態におけるネットワークプラグアンドプレイシステムの概略構成を示すブロック図である。 ネットワークデバイスに対するプラグアンドプレイ処理の流れを示すフローチャートである。 ＷＳ−Ｄｉｓｃｏｖｅｒｙ仕様で定義されるＨｅｌｌｏメッセージフォーマットを示す図 ＷＳ−ＭｅｔａｄａｔａＥｘｃｈａｎｇｅ仕様で定義されるＧｅｔＭｅｔａｄａｔａメッセージフォーマットを示す図である。 ＷＳ−ＭｅｔａｄａｔａＥｘｃｈａｎｇｅ仕様で定義されるＧｅｔＭｅｔａｄａｔａＲｅｓｐｏｎｓｅメッセージフォーマットを示す図である。 ネットワーク対応デバイスを検索、発見する制御の流れを示すフローチャートである。 ＷＳ−Ｄｉｓｃｏｖｅｒｙ仕様で定義されるＰｒｏｂｅメッセージフォーマットを示す図である。 ＷＳ−Ｄｉｓｃｏｖｅｒｙ仕様で定義されるＰｒｏｂｅ Ｍａｔｃｈｅｓメッセージフォーマットを示す図である。 第一の実施形態にける、ネットワーク対応デバイスがネットワークから離脱する際の制御の流れを示すフローチャートである。 ＷＳ−Ｄｉｓｃｏｖｅｒｙ仕様で定義されるＢｙｅメッセージフォーマットを示す図である。 第二の実施形態にける、ネットワーク対応デバイスがネットワークから離脱する際の制御の流れを示すフローチャートである。 第三の実施形態にける、ネットワークデバイスに対するプラグアンドプレイ処理後の流れを示すフローチャートである。 第三の実施形態にける、ネットワーク対応デバイスがネットワークから離脱する際の制御の流れを示すフローチャートである。 第四の実施形態にける、クライアントデバイスがＢｙｅメッセージを受信可能な状態に復帰直後の制御の流れを示すフローチャートである。 デバイスドライバの削除の実行を確認するダイアログボックスの一例を示す図である。 デバイスが不要になったときにデバイスドライバを自動削除するかどうか確認するダイアログボックスの一例を示す図である。 プリントシステムのハードウエアブロック図である。 プリントキュー情報の一例を示す図である。 ユーザ情報の一例を示す図である。 クライアントデバイスにおける処理フローチャートを示す図である。 本願におけるユーザを管理するための情報の一例を示す図である。 本願におけるクライアントデバイスにインストールされているデバイスドライバを管理する一例を示す図である。

符号の説明

１ Ｅｔｈｅｎｅｔコントローラ
２ Ｗｉ−Ｆｉコントローラ
３ Ｂｌｕｅｔｏｏｔｈ（登録商標）コントローラ
４ ＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック
５ ＨＴＴＰ
６ ＳＯＡＰプロセッサ
８ ＷＳＤモジュール
１０ デバイスドライバマネージャ
１１ プラグアンドプレイコントローラ
１２ デバイスドライバ・ユーティリティ
１４ ユーティリティ
１５ アプリケーション
１６ Ｂｌｕｅｔｏｏｔｈ（登録商標）コントローラ
１７ Ｅｔｈｅｎｅｔコントローラ
１８ ＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック
１９ ＨＴＴＰ
２０ ＳＯＡＰプロセッサ
２１ ＷＳＤモジュール
２２ プリンタコントローラ

Claims (21)

1. 周辺機器と接続されたコンピュータにより実行されるプログラムであって、
   周辺機器からの離脱メッセージを受信する受信手段と、
   前記受信手段により受信した離脱メッセージの送信元の周辺機器に対応するデバイスドライバが所定の条件に一致するか否かを判定する判定手段と、
   前記判定手段により前記デバイスドライバ情報が前記所定の条件に一致すると判定された場合、該離脱メッセージ送信元の周辺機器に対応するデバイスドライバを削除する削除手段と
   を備えることを特徴とするプログラム。
2. 前記コンピュータは、一時的利用者がログインした後にインストールされたデバイスドライバをゲスト用デバイスドライバとして識別可能に記憶する記憶手段を有しており、
   前記判定手段は、前記受信手段により離脱メッセージを受信した場合に、前記記憶手段に記憶されている情報に基づいて、前記離脱メッセージの送信元の周辺機器に対応するデバイスドライバが、前記一時的利用者がログインした後にインストールされたゲスト用のデバイスドライバと対応するか否かを判定し、
   前記削除手段は、前記判定手段によって離脱メッセージの送信元の周辺機器に対応するデバイスドライバが、前記一時的利用者がログインした後にインストールされたゲスト用のデバイスドライバと対応すると判定された場合、前記離脱メッセージ送信元の周辺機器に対応するデバイスドライバを削除することを特徴とする請求項１に記載のプログラム。
3. 前記コンピュータにログインしている利用者が一時的利用者であるか否かを判定する利用者判定手段を更に有することを特徴とする請求項２に記載のプログラム。
4. 前記受信手段により離脱メッセージを受信した場合に、前記離脱メッセージ送信元の周辺機器に対応するデバイスドライバが、他の周辺機器のために利用されているかを判定する利用状況判定手段を更に有し、
   前記削除手段は、前記利用状況判定手段により前記デバイスドライバが他の周辺機器のために利用されていないと判定された場合に前記デバイスドライバを削除することを特徴とする請求項１乃至３のいずれか１項に記載のプログラム。
5. 前記受信手段により離脱メッセージを受信することに応じて、前記離脱メッセージ送信元の周辺機器に対応するデバイスドライバを削除するかを問い合わせる問い合わせ手段を更に有し、
   前記削除手段は、前記問い合わせ手段の問い合わせに対して削除が指示された場合に、前記デバイスドライバを削除することを特徴とする請求項１乃至４のいずれか１項に記載のプログラム。
6. 周辺機器に対応するデバイスドライバのインストールの際に、該デバイスドライバの自動削除を示す自動削除情報を登録する登録手段をさらに備え、
   前記削除手段は、前記受信手段により離脱メッセージを受信した場合に、前記登録手段により登録された自動削除情報を参照し、自動削除が可である旨が登録されていた場合に、前記デバイスドライバを削除することを特徴とする請求項１乃至５のいずれか１項に記載のプログラム。
7. 前記コンピュータがネットワークに接続された際に、該ネットワーク上の所定条件に該当する周辺機器の存在を問い合わせるプローブメッセージを送信する手段と、
   前記プローブメッセージに対する応答を受信する手段を有し、
   前記削除手段は、前記コンピュータに既にインストールされており、かつ、前記プローブメッセージに対する応答がない周辺機器に対応するデバイスドライバを削除すことを特徴とする請求項１乃至６のいずれか１項に記載のプログラム。
8. 周辺機器と接続された情報処理装置であって、
   周辺機器からの離脱メッセージを受信する受信手段と、
   前記受信手段により受信した離脱メッセージの送信元の周辺機器に対応するデバイスドライバが所定の条件に一致するか否かを判定する判定手段と、
   前記判定手段により前記デバイスドライバ情報が前記所定の条件に一致すると判定された場合、該離脱メッセージ送信元の周辺機器に対応するデバイスドライバを削除する削除手段と
   を備えることを特徴とする情報処理装置。
9. 一時的利用者がログインした後にインストールされたデバイスドライバをゲスト用デバイスドライバとして識別可能に記憶する記憶手段を更に備え、
   前記判定手段は、前記受信手段により離脱メッセージを受信した場合に、前記記憶手段に記憶されている情報に基づいて、前記離脱メッセージの送信元の周辺機器に対応するデバイスドライバが、前記一時的利用者がログインした後にインストールされたゲスト用のデバイスドライバと対応するか否かを判定し、
   前記削除手段は、前記判定手段によって離脱メッセージの送信元の周辺機器に対応するデバイスドライバが、前記一時的利用者がログインした後にインストールされたゲスト用のデバイスドライバと対応すると判定された場合、前記離脱メッセージ送信元の周辺機器に対応するデバイスドライバを削除することを特徴とする請求項８に記載の情報処理装置。
10. ログインしている利用者が一時的利用者であるか否かを判定する利用者判定手段を更に有することを特徴とする請求項９に記載の情報処理装置。
11. 前記受信手段により離脱メッセージを受信した場合に、前記離脱メッセージ送信元の周辺機器に対応するデバイスドライバが、他の周辺機器のために利用されているかを判定する利用状況判定手段を更に有し、
    前記削除手段は、前記利用状況判定手段により前記デバイスドライバが他の周辺機器のために利用されていないと判定された場合に前記デバイスドライバを削除することを特徴とする請求項８乃至１０のいずれか１項に記載の情報処理装置。
12. 前記受信手段により離脱メッセージを受信することに応じて、前記離脱メッセージ送信元の周辺機器に対応するデバイスドライバを削除するかを問い合わせる問い合わせ手段を更に有し、
    前記削除手段は、前記問い合わせ手段の問い合わせに対して削除が指示された場合に、前記デバイスドライバを削除することを特徴とする請求項８乃至１１のいずれか１項に記載の情報処理装置。
13. 周辺機器に対応するデバイスドライバのインストールの際に、該デバイスドライバの自動削除を示す自動削除情報を登録する登録手段をさらに備え、
    前記削除手段は、前記受信手段により離脱メッセージを受信した場合に、前記登録手段により登録された自動削除情報を参照し、自動削除が可である旨が登録されていた場合に、前記デバイスドライバを削除することを特徴とする請求項８乃至１２のいずれか１項に記載の情報処理装置。
14. 前記コンピュータがネットワークに接続された際に、該ネットワーク上の所定条件に該当する周辺機器の存在を問い合わせるプローブメッセージを送信する手段と、
    前記プローブメッセージに対する応答を受信する手段を有し、
    前記削除手段は、前記コンピュータに既にインストールされており、かつ、前記プローブメッセージに対する応答がない周辺機器に対応するデバイスドライバを削除すことを特徴とする請求項８乃至１３のいずれか１項に記載の情報処理装置。
15. 周辺機器と接続された情報処理装置の制御方法であって、
    周辺機器からの離脱メッセージを受信する受信工程と、
    前記受信工程により受信した離脱メッセージの送信元の周辺機器に対応するデバイスドライバが所定の条件に一致するか否かを判定する判定工程と、
    前記判定工程により前記デバイスドライバ情報が前記所定の条件に一致すると判定された場合、該離脱メッセージ送信元の周辺機器に対応するデバイスドライバを削除する削除工程と
    を備えることを特徴とする情報処理装置の制御方法。
16. 一時的利用者がログインした後にインストールされたデバイスドライバをゲスト用デバイスドライバとして識別可能に記憶する記憶工程を更に備え、
    前記判定工程は、前記受信工程により離脱メッセージを受信した場合に、前記記憶工程に記憶されている情報に基づいて、前記離脱メッセージの送信元の周辺機器に対応するデバイスドライバが、前記一時的利用者がログインした後にインストールされたゲスト用のデバイスドライバと対応するか否かを判定し、
    前記削除工程は、前記判定工程によって離脱メッセージの送信元の周辺機器に対応するデバイスドライバが、前記一時的利用者がログインした後にインストールされたゲスト用のデバイスドライバと対応すると判定された場合、前記離脱メッセージ送信元の周辺機器に対応するデバイスドライバを削除することを特徴とする請求項１５に記載の情報処理装置の制御方法。
17. ログインしている利用者が一時的利用者であるか否かを判定する利用者判定工程を更に有することを特徴とする請求項１６に記載の情報処理装置の制御方法。
18. 前記受信工程により離脱メッセージを受信した場合に、前記離脱メッセージ送信元の周辺機器に対応するデバイスドライバが、他の周辺機器のために利用されているかを判定する利用状況判定工程を更に有し、
    前記削除工程は、前記利用状況判定工程により前記デバイスドライバが他の周辺機器のために利用されていないと判定された場合に前記デバイスドライバを削除することを特徴とする請求項１５乃至１７のいずれか１項に記載の情報処理装置の制御方法。
19. 前記受信工程により離脱メッセージを受信することに応じて、前記離脱メッセージ送信元の周辺機器に対応するデバイスドライバを削除するかを問い合わせる問い合わせ工程を更に有し、
    前記削除工程は、前記問い合わせ工程の問い合わせに対して削除が指示された場合に、前記デバイスドライバを削除することを特徴とする請求項１５乃至１８のいずれか１項に記載の情報処理装置の制御方法。
20. 周辺機器に対応するデバイスドライバのインストールの際に、該デバイスドライバの自動削除を示す自動削除情報を登録する登録工程をさらに備え、
    前記削除工程は、前記受信工程により離脱メッセージを受信した場合に、前記登録工程により登録された自動削除情報を参照し、自動削除が可である旨が登録されていた場合に、前記デバイスドライバを削除することを特徴とする請求項１５乃至１９のいずれか１項に記載の情報処理装置の制御方法。
21. 前記コンピュータがネットワークに接続された際に、該ネットワーク上の所定条件に該当する周辺機器の存在を問い合わせるプローブメッセージを送信する工程と、
    前記プローブメッセージに対する応答を受信する工程を有し、
    前記削除工程は、前記コンピュータに既にインストールされており、かつ、前記プローブメッセージに対する応答がない周辺機器に対応するデバイスドライバを削除すことを特徴とする請求項１５乃至２０のいずれか１項に記載の情報処理装置の制御方法。

Images