JP4912093B2 - 情報処理方法、情報処理装置、プログラム及び記憶媒体 - Google Patents

Description

本発明は、ネットワークデバイスが有する全ての能力に対応したデバイスドライバをプラグアンドプレイインストールするための情報処理技術に関する。

特定の情報処理装置やオペレーションシステム（以下「ＯＳ」と略す）上で動作するアプリケーションに依存しないように、印刷装置は独自の描画言語体系であるコマンドインターフェースを有している。描画言語体系には、例えば、ＰＤＬ(Page Description Langauage)が含まれる。

描画言語体系は個々の印刷装置に依存する。よってその依存性をカプセル化するために、ＯＳは、標準的な描画インタフェースを入力とし、その印刷装置依存の描画言語体系のコマンドに変換し出力するプリンタドライバというモジュールを定義している。このプリンタドライバは、一般には、印刷装置の製造元やＯＳ開発者などによって作成され、情報処理装置内に格納される。

情報処理装置内に格納されるプリンタドライバは多数存在する。そのため情報処理装置に存在する全てのプリンタドライバをユーザに示すのは混乱の元である。つまり、ユーザの使用する印刷装置のみだけ効率的に結びつけ、ユーザが使用可能な状態にしたい。よってＯＳの初期状態ではプリンタドライバは情報処理装置内に格納されるだけであり、ユーザは特定の印刷装置にプリンタドライバを結びつける作業であるＯＳへのプリンタドライバのインストールを行う必要がある。

このインストール作業は、従来、ユーザが手動で行っていた。しかし、ユーザは煩雑な印刷装置ドラバのインストール作業を行う必要があり、また異なる描画言語体系のコマンドを、その描画体系をサポートしていない印刷装置に送った場合、印刷エラーとなる。このため、該当の印刷装置に対応したプリンタドライバを正しくインストールする必要があり、初心者には難しい作業であった。

この煩雑なインストール作業を軽減するために、米国セントロニクス社使用のパラレルインタフェースやＵＳＢ（Universal Serial Bus）インタフェースなどの通信媒介を用いることが可能である。情報処理装置と印刷装置とを接続するだけで、ユーザが操作を行わなくても自動的に情報処理装置と印刷装置で双方向通信を行い、その印刷装置に該当するドライバを情報処理装置にインストールする機能をＯＳに導入している。この機能を「プラグアンドプレイ」と呼ぶ（特許文献１）。プラグアンドプレイは直接的な一対一の接続である。

近年、ネットワークのインフラが整備されるに従い、ネットワーク対応型の印刷装置、スキャナ、複写機等のネットワーク周辺デバイスが急速に普及しつつある。ネットワーク上の各種サービスを提供するデバイスを、ネットワークを介して探索する技術が開発されている。例えば、このような技術には米国マイクロソフト社の提唱するＵｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ（以下、「ＵＰｎＰ」と略す）が存在する（特許文献２）。

ネットワーク対応型のネットワークデバイスとしての印刷装置を例に説明する。事前に使用するクライアント、例えば、パーソナルコンピュータ上に、そのクライアント上で稼動するオペレーティングシステム、例えばＷｉｎｄｏｗｓ（登録商標）によりデータベース上に登録管理された該当ドライバをインストールする。あるいは、印刷装置ベンダからフレキシブルディスク、ＣＤ−ＲＯＭ等の記録媒体を介して提供されるドライバソフトウエア（ドライバ）をインストールする。そして、印刷装置に割り当てられたＩＰアドレス、印刷装置ポート、使用するプリントプロトコル、デバイスドライバ等の印刷装置を動作させるための情報を把握する必要がある。

その印刷装置を他のネットワークへ移動させたり、そのネットワークへの新規加入などにより、ネットワークシステムに接続されている装置の構成は刻々と変化している。このことを鑑み、ネットワーク上に存在する印刷装置を管理するためには、印刷装置の情報を把握して管理する技術が開発されつつある。

しかし、ＵＰｎＰなどの既存の管理システムは、印刷装置とコンピュータを接続するための技術仕様であるが、機器同士が通信するためのプロトコルとデータフォーマットについて規定しているだけである。

また、ユーザや各国市場の要求を満たすために、多種多様な印刷装置のための描画言語体系が作られ、市場に送り出されている。それぞれの描画言語体系のために印刷装置を一から開発するのは費用がかさむ。このコストを軽減するために各描画言語体系に依存する部分を拡張ボードやソフトウェアとして分離し、ユーザの要求や各国市場要求に応じて、印刷装置に、その拡張ボードやソフトウェアを搭載し直すことが可能な印刷装置も出てきている。

加えて、ユーザが好む描画言語体系が複数個存在する環境のために、一つの印刷装置で複数個の描画言語体系をサポートする印刷装置も登場している。

描画言語体系が拡張ボードやソフトウェアによって変更可能な印刷装置や、複数個の描画言語体系をサポートする印刷装置は、プラグアンドプレイ搭載時には想定されていないものである。

検出された一つの印刷装置に対して、複数の描画言語体系からいずれかのＰＤＬを選択するなどの、印刷装置に詳しくないユーザが混乱する選択作業を不要するユーザインターフェイスが望まれている。

上記の理由により、あるＯＳに搭載されているプラグアンドプレイでは、印刷装置から情報処理装置に受け渡される印刷装置の識別子（DeviceID）のうち、製造者名と印刷装置名でのみプリンタドライバの検索を行うものがある。この検索では、描画言語体系を示す情報を無視して、印刷装置の識別子のうち、製造者名と印刷装置名でのみ、印刷装置に該当するプリンタドライバを情報処理装置内から検索し、最初に検出したものをインストールする。
特開２００３−２１６３７８公報 特開２００３−６１３３公報

しかしながら上記の仕組みでは、印刷装置から同時に取得可能なデバイス識別子は1つしかなく、複数のＰＤＬに対応する複数のプリンタドライバをプラグアンドプレイでインストールすることはできない。

また、印刷機能だけでなく、ＦＡＸ機能も備えた複合装置においても同様に、印刷用ドライバとＦＡＸドライバの両方をプラグアンドプレイでインストールできることが望まれる。しかしながら現状の仕組みでは、デバイスに設定された識別子に依存するドライバだけがインストールされる。

本発明は、複数の機能ドライバをサポートするデバイスからプラグアンドプレイインストール用の識別子を１つしか取得できない場合でも、全ての機能ドライバをインストールすることを可能にする情報処理技術の提供を目的とする。

上記の目的を達成する本発明に係る情報処理方法は、ネットワークに接続されたデバイスから取得した識別情報により、前記デバイスが既に登録されているか否かを判定し、登録されていないデバイスである場合に、前記デバイスが有するコントローラに対応したデバイスドライバを前記デバイスにプラグアンドプレイインストールするインストール手段を有する情報処理装置で実行される情報処理方法であって、
取得手段が、前記デバイスが有する少なくとも１つのコントローラにより少なくとも１つの種類のページ記述言語に対応した処理が可能であることを示すサポートコマンド情報と、前記コントローラに対応したデバイスドライバをプラグアンドプレイによりインストールするための設定であることを示す設定情報と、を含む構成情報を前記デバイスから取得する取得工程と、
認識手段が、前記デバイスから取得した前記構成情報に含まれる前記設定情報を参照して、前記デバイスが有する前記コントローラに対応したデバイスドライバをプラグアンドプレイによりインストールするための設定がされていることを認識する認識工程と、
判定手段が、前記構成情報に含まれる前記サポートコマンド情報を参照して、前記コントローラとは異なる第２のコントローラに関する情報が記述されており、当該第２のコントローラにより前記ページ記述言語とは異なる第２のページ記述言語に対応した処理が可能であるかを判定する判定工程と、
生成手段が、前記判定工程の判定により、前記第２のページ記述言語に対応した処理が可能であると判定された場合、前記構成情報のうち、前記設定情報を前記第２のコントローラに対応したデバイスドライバをプラグアンドプレイによりインストールするための設定であることを示す情報に書き換えた第２構成情報と、前記第２のコントローラに対応したデバイスドライバをプラグアンドプレイインストールする際に前記デバイスを当該デバイスとは異なる仮想デバイスとして前記インストール手段に認識させるための第２の識別情報と、を生成する生成工程と、
送信手段が、前記生成工程により生成された前記第２の識別情報を前記インストール手段に送信し、当該インストール手段からの要求に応じて前記第２構成情報を、前記インストール手段に送信する送信工程と
を有することを特徴とする。

あるいは、本発明に係る情報処理装置は、ネットワークに接続されたデバイスから取得した識別情報により、前記デバイスが既に登録されているか否かを判定し、登録されていないデバイスである場合に、当該デバイスが有するコントローラに対応したデバイスドライバを前記デバイスにプラグアンドプレイインストールするインストール手段を有する情報処理装置であって、
前記デバイスが有する少なくとも１つのコントローラにより少なくとも１つの種類のページ記述言語に対応した処理が可能であることを示すサポートコマンド情報と、前記コントローラに対応したデバイスドライバをプラグアンドプレイによりインストールするための設定であることを示す設定情報と、を含む構成情報を前記デバイスから取得する取得手段と、
前記デバイスから取得した前記構成情報に含まれる前記設定情報を参照して、前記デバイスが有する前記コントローラに対応したデバイスドライバをプラグアンドプレイによりインストールするための設定がされていることを認識する認識手段と、
前記構成情報に含まれる前記サポートコマンド情報を参照して、前記コントローラとは異なる第２のコントローラに関する情報が記述されており、当該第２のコントローラにより前記ページ記述言語とは異なる第２のページ記述言語に対応した処理が可能であるかを判定する判定手段と、
前記判定手段の判定により、前記第２のページ記述言語に対応した処理が可能であると判定された場合、前記構成情報のうち、前記設定情報を前記第２のコントローラに対応したデバイスドライバをプラグアンドプレイによりインストールするための設定であることを示す情報に書き換えた第２構成情報と、前記第２のコントローラに対応したデバイスドライバをプラグアンドプレイインストールする際に前記デバイスを当該デバイスとは異なる仮想デバイスとして前記インストール手段に認識させるための第２の識別情報と、を生成する生成手段と、
前記生成手段により生成された前記第２の識別情報を前記インストール手段に送信し、当該インストール手段からの要求に応じて前記第２構成情報を、前記インストール手段に送信する送信手段と
を備えることを特徴とする。

本発明によれば、複数の機能ドライバをサポートするデバイスからプラグアンドプレイインストール用の識別子を１つしか取得できない場合でも、全ての機能ドライバをプラグアンドプレイインストールすることが可能になる。

以下に、図面を参照して、この発明の好適な実施の形態を例示的に詳しく説明する。ただし、この実施の形態に記載されている構成要素はあくまで例示であり、この発明の範囲をそれらのみに限定する趣旨のものではない。

（第１実施形態）
図１は本発明の実施形態に係るプリントシステムの構成をソフトウェア面からみたブロック図である。図７は、第１実施形態に係るプリントシステムにおけるクライアントコンピュータ（以下、単に「クライアント」と呼ぶ）１００、プロキシサーバ３００、ネットワークデバイスの例としてプリンタ２００の通信を簡略的に示す図である。

（クライアント１００）
クライアント１００には、不図示の米国マイクロソフト社が提供するＯＳであるwindows（登録商標）や米国Ａｐｐｌｅ社が提供するＭａｃ ＯＳ（登録商標）等の汎用オペレーティングシステムがインストールされている。更に、クライアント１００には、汎用オペレーティングシステム上で実行可能な汎用アプリケーションがインストールされている。

汎用オペレーティングシステムは、通信機能としてＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック１０７を備え、そのプロトコルスタック上にＨＴＴＰ１０６を備え、ＨＴＴＰリクエストの解析、およびレスポンス処理を行う。ＨＴＴＰ１０６上には、Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ（ＳＯＡＰ）処理部１０３を備え、ＵＰｎＰに関する通信手段を形成している。ＵＰｎＰのためのプラグアンドプレイインストール部１０１は、ネットワーク上のＵＰｎＰ対応プリンタ２００および代理応答装置（プロキシサーバ３００）と通信を行うために、上記通信手段を用いることが可能である。

クライアント１００にＵＰｎＰで検出したプリンタ２００等を表示し、ユーザに選択させるために、プラグアンドプレイインストール部１０１はＧＵＩ部１０２を利用する。

Ｃｏｎｆｉｇｕｒａｔｏｒモジュール部１０４は、ネットワーク７００を介してプリンタ２００より取得した情報に基づいて、予めハードディスクに格納された中から該当するプリンタドライバをＯＳに登録（インストール）する。

詳しくは、ＯＳのアプリケーションプログラムインタフェース（ＡＰＩ）から、システムインストーラ１０８を呼び出す。システムインストーラ１０８は、ハードディスクからプリンタドライバを取得して、ドライバ格納部１１１にインストールする。同時に、システムインストーラ１０８は、自動的にドライバ管理部１１０にデバイスＩＤ（デバイス識別子）に基づいてプリンタドライバを登録するようシステム管理部１０９に登録依頼を行う。以後、ＯＳはプリンタドライバが登録されていることを認識するので、ドライバ格納部１１１に格納されたプリンタドライバを適宜ローディングして印刷に関する各種処理を行う。本実施形態におけるプラグアンドプレイインストール１０１部は、以下のデバイス構成情報を取得する。デバイス構成情報には、デバイス（プリンタ２００）がサポートする能力を特定する情報が含まれる。以下に示すデバイス構成情報の場合、「サポートコマンド・言語」には、ＰＤＬ１,ＰＤＬ２と記述されており、デバイス（プリンタ２００）が複数のＰＤＬに対応した処理能力を有することがわかる。

ＭＡＮＵＦＡＣＴＵＲＥＲ（デバイス製造社）：ＡＢＣ
ＣＯＭＭＡＮＤ ＳＥＴ (サポートコマンド・言語)：ＰＤＬ１,ＰＤＬ２
ＭＯＤＥＬ（プリンタ機種）：Ｐｒｉｎｔｅｒ Ａ ＰＤＬ１
ＣＯＭＭＥＮＴ（コメント）：Ｌｏｃａｔｅｄ Iｎ ＲＯＯＭ３
ＡＣＴＩＶＥ ＣＯＭＭＡＮＤ ＳＥＴ：（アクティブなコマンド・言語）：ＰＤＬ１
プラグアンドプレイインストール部１０１は、上記のデバイス構成情報からデバイス製造社とプリンタ機種との組をデバイスＩＤとして抽出し、システムインストーラ１０８が認識可能なデバイスＩＤに変換してインストールを行う。
予めハードディスクに格納されたデバイスドライバにはドライバインストール時に参照される固有情報を記述したＩＮＦファイルが含まれる。ＩＮＦファイルには、デバイス製造社とプリンタ機種の組から構成されるデバイスＩＤが記述されている。デバイスＩＤは、インストール時に対応するデバイス（プリンタ）とデバイスドライバ（プリンタドライバ）を対応づけるために、デバイス識別子（以下、単に「識別子」ともいう）として用いられる。

（ネットワーク対応型デバイス）
ネットワーク対応型デバイス（本実施形態ではネットワーク対応型プリンタ２００を例とする）は、通信機能としてＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック２０１を備える。プロトコルスタック２０１上にＨＴＴＰ２０２を備え、ＨＴＴＰリクエストの解析、およびレスポンス処理を行う。ＨＴＴＰ２０２の上位層にはＳｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ（ＳＯＡＰ）処理部２０３を備え、ＳＯＡＰ処理部２０３の上位層にＵＰｎＰプロトコル処理部２０４を備える。

ネットワーク対応型プリンタ（以下、単に「プリンタ」という。）２００は、ＵＰｎＰ Ｆｏｒｕｍで策定されたＰｒｉｎｔＢａｓｉｃサービスを実装しているものとする。ＵＰｎＰプロトコル処理部２０４は、ＰｒｉｎｔＢａｓｉｃサービスで定義されたプリントジョブ、および属性情報を解析し、プリンタコントローラ２０５に対し、そのプリント要求を送出する機能を備える。

プリンタ２００は、複数のＰＤＬに対するプリンタコントローラ２０５を同時に有することが出来る。またプリンタコントローラ２０５を脱着可能にし、ユーザの要求に応じて差し替えて、プリンタ２００がサポートするＰＤＬを変更することも可能である。本実施形態におけるプリンタ２００は、ＰＤＬ１、ＰＤＬ２の２つのＰＤＬのためのプリンタコントローラ（ＰＤＬ１、ＰＤＬ２）２０５a、２０５ｂを搭載しているものとする。

（プロキシサーバ）
実施形態において特徴となるネットワークデバイス管理装置として機能するプロキシサーバ（代理サーバ）３００も同様に、通信機能としてＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック３０１を備える。プロトコルスタック３０１上にＨＴＴＰ３０２を備え、ＨＴＴＰリクエストの解析、およびレスポンス処理を行う。

ＨＴＴＰ３０２の上位層にはＳｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ（ＳＯＡＰ）処理部３０３が設けられている。ＵＰｎＰプロトコル処理部３０４、およびデバイス管理部３０６がそれぞれ、クライアント２００、およびプロキシサーバ３００が複数ネットワーク上に存在する場合、ＸＭＬで記述されたデータの双方向通信を実現する。

デバイス管理部３０６は、ＳＯＡＰ処理部３０３、ＵＰｎＰプロトコル処理部３０４、及び記憶装置制御部３０５の上位層に設けられている。デバイス管理部３０６は、ＵＰｎＰプロトコルスタック３０１で受信した各種ＸＭＬドキュメントを解析・変換、デバイス識別子の生成などを行う。記憶装置制御部３０５は、記憶装置を制御して、受信データ、解析結果、変換結果、送信データ等の読み書きを行う。また、ＵＰｎＰプロトコル処理部３０４にデータを送信するなどの処理を実行する。

デバイス管理部３０６は、プロキシサーバ３００が管理する管理テーブルを、記憶装置制御部３０５を介して記憶装置制御部３０５が制御する記憶装置に対し書き込み、読み出し処理を行う。また、同様に、デバイス管理部３０６は、ネットワーク７００上に存在する他のプロキシサーバが管理する管理テーブルを取得した場合、記憶装置制御部３０５を介して、記憶装置制御部３０５が制御する記憶装置に対し書き込み、読み出し処理を行う。

以上は、各装置のプリントに関する実装されるコンピュータプログラムの構成であるが、クライアント１００、プロキシサーバ３００は、通常のパーソナルコンピュータ等の情報処理装置で実現することが可能である。ハードウェアとしての構成は、例えば、図２のようになる。

図２において、ＣＰＵ１００１は装置全体の制御を司り、ＲＯＭ１００２はＢＩＯＳやブートプログラムを記憶する。ＲＡＭ１００３はＣＰＵ１００１のワークエリアとして使用することが可能である。ハードディスク装置（ＨＤＤ）１００４には、ＯＳ、アプリケーションや各種プログラム、並びに、データファイル等が格納される。ネットワークインタフェース（Ｉ／Ｆ）１００５は、ネットワーク７００と接続するために、イーサネット（登録商標）カードや無線ＬＡＮカードを用いることができる。表示制御部１００６は、ビデオメモリ及びＣＰＵ１００１の制御により描画を行うと共にビデオメモリに記憶された画像データをビデオ信号として出力するビデオコントローラが内蔵される。

表示装置１００７は、液晶表示器やＣＲＴに代表されるものである。入力装置１００８にはキーボードやマウス等が含まれる。

上記構成において、装置の電源がＯＮになると、ＣＰＵ１００１はＲＯＭ１００２のブートプログラムに従って、ハードディスク１００４からＯＳをＲＡＭ１００３にロードし、各種デバイスドライバをロードする。上記の装置がクライアント１００である場合、図１に示す構成のプログラムをＲＡＭ１００３にロードし、実行することになる。これはプロキシサーバ３００でも同様である。プロキシサーバ３００の場合、ＯＳがロードされた後、図１に示す構成のプログラムをＲＡＭ１００３にロードし、且つ、後述する処理を行うことになる。

図３は、プリンタ２００のブロック構成図である。図３において、ＣＰＵ２００１はプリンタ全体の制御を司り、ＲＯＭ２００２はＣＰＵ２００１が実行する印刷処理プログラムやフォントデータを格納する。ＲＡＭ２００３はＣＰＵ２００１のワークエリア、受信バッファ、画像描画に使用することが可能である。操作パネル２００４は各種スイッチやボタン、並びに、メッセージ表示用の液晶表示部で構成される。ネットワークインタフェース（Ｉ／Ｆ）２００５を介して、プリンタ２００はネットワーク７００に接続することが可能である。レンダリング部２００６は描画処理を実行し、プリンタエンジン２００７は、レンダリング部２００６により描画処理されたデータに基づいて、実際に記録紙に印刷処理を実行する。

本実施形態では、プリンタ２００、プロキシサーバ３００、クライアント１００は、マイクロソフト社の提唱する仕様に準拠したプロトコルで通信することが可能である。例えば、Web Services Dynamic Discovery (WS-Discovery)の仕様に準拠したプロトコルにより通信を行うことも可能である。Web Services MetadataExchange (WS-MetadataExchange)の仕様に準拠したプロトコルにより通信を行うことも可能である。あるいは、Web Services Eventing (WS-Eventing)の仕様に準拠したプロトコルにより通信を行うことも可能である。

本実施形態に係る処理の流れを図４のフローチャートを参照して説明する。

図４は、本実施形態に係るプロキシサーバ３００がデバイス（プリンタ２００）からHelloメッセージを受信した時の動作を表したフローチャートである。図７に示すように、デバイス（プリンタ２００）は、起動時にHelloメッセージをマルチキャストでネットワーク７００に送信する。

ステップＳ４０１において、プロキシサーバ３００は、デバイス（プリンタ２００）からのHelloメッセージを常にリッスンしており、デバイス（プリンタ２００）からのHelloメッセージを受信する。

ステップＳ４０２において、プロキシサーバ３００は、Helloメッセージに含まれる識別子ＵＵＩＤ（Universally Unique Identifier）から、例えば、デバイス（プリンタ２００）を一意に特定するために判定を行う。プロキシサーバ３００は、識別子ＵＵＩＤに基づいて、プロキシサーバの管理テーブルに登録されているデバイス（プリンタ２００）があるか否かを判断する。

既にデバイス（プリンタ２００）が登録済みの場合は（Ｓ４０２−ＹＥＳ）、処理をステップＳ４０８に進め、管理テーブルに記録しているデバイス（プリンタ２００）のステイタスを編集して処理を終了する。

未登録の場合は（Ｓ４０２−Ｎｏ）、デバイス（プリンタ２００）から更に詳細な情報を得るため、プロキシサーバ３００は、デバイス（プリンタ２００）に対してGetMetaDataメッセージを送信する。GetMetaDataメッセージを受信したデバイス（プリンタ２００）は、GetMetaDataResponceメッセージを返信する。デバイス（プリンタ２００）が返信するGetMetaDataResponceメッセージは、例えば、デバイス構成情報（プリンタ構成情報）の参照（ＵＲＩ）を含む。

次に、プロキシサーバ３００は、Getメッセージをデバイス（プリンタ２００）に送信する。Getメッセージには、プリンタ構成情報の参照URIを含み、これを受信したデバイス（プリンタ２００）は、GetResponceメッセージを返信する。GetResponceメッセージには、図５に示すような、プリンタ構成情報５００が含まれているものとする。ここで、プリンタ構成情報５００には、デバイス製造社５０１、サポートコマンド・言語５０２、プリンタ機種５０３、コメント５０４、アクティブなコマンド・言語５０５、ＩＰアドレス５０６が含まれる。

ステップＳ４０３において、上記の処理によりプロキシサーバは、デバイス（プリンタ２００）からプリンタ構成情報５００を取得する。

ステップＳ４０４において、プロキシサーバ３００は、プリンタ機種５０３の情報（Printer A ＰＤＬ１）から取得したプリンタ構成情報をＰＤＬ１用のプリンタドライバインストール用の情報であることを認識する。そして、プロキシサーバ３００は、他のＰＤＬをサポートしているか判定する。プロキシサーバ３００は、サポートコマンド・言語５０２の情報から、ＰＤＬ１の他、ＰＤＬ２もサポートしていると判定する。

ステップＳ４０４の判定で、プロキシサーバ３００が、他のＰＤＬもデバイスはサポートしていると判定した場合（Ｓ４０４−ＹＥＳ）、処理をステップＳ４０５に進める。ステップＳ４０４の判定で、他のＰＤＬをサポートしていないとプロキシサーバ３００が判定した場合（Ｓ４０４−ＮＯ）、処理をステップＳ４０６に進める。

Ｓ４０５において、プロキシサーバ３００は、図６に示すようなプリンタ機種６０３の情報を「Printer A ＰＤＬ２」に、アクティブなコマンド・言語６０５の情報を「ＰＤＬ２」と書き換えたプリンタ構成情報を生成する。

プロキシサーバ３００は、プリンタ構成情報を書き換えたデバイス（プリンタ２００）と異なるデバイス（プリンタ）として、クライアント１００に認識させる為、プリンタ構成情報を書き換えたデバイス用の識別子を生成する。

ステップＳ４０６において、プロキシサーバ３００は、生成したプリンタ構成情報と識別子を管理テーブルに登録する。

次に、ステップＳ４０７において、プロキシサーバ３００は、仮想的なデバイス（プリンタ）として、プリンタ構成情報が書き換えられたプリンタの代わりにＨｅｌｌｏメッセージをマルチキャストで送信する。Ｈｅｌｌｏメッセージには、先のステップＳ４０５で生成した識別子が含まれる。識別子のアドレスは、プリンタのアドレスではなく、プロキシサーバ３００のアドレスにマッピングする。

Ｈｅｌｌｏメッセージを受信したクライアント１００は、プロキシサーバ３００、デバイス（プリンタ２００）間の通信と同様に、ＧｅｔＭｅｔａＤａｔａメッセージ、Ｇeｔメッセージを、プロキシサーバ３００に送信し、プリンタ構成情報を取得する。クライアント１００は、プロキシサーバ３００との通信により、図６に示すデバイス構成情報の取得が可能である。

複数の機能をサポートするデバイス（プリンタ２００）からプラグアンドプレイインストール用のデバイス識別子を１つしか取得できない場合、プロキシサーバ３００は、プリンタ構成情報を書き換えた識別子を生成する。識別子がプロキシサーバ３００により生成されたデバイスは、識別子に基づいて判断した場合、デバイス（プリンタ２００）と異なる仮想的なデバイスとなる。

プリンタ構成情報の書き換えにおいて、ＩＰアドレスは変更されないため、全ての機能ドライバをプラグアンドプレイインストールするインストール先はデバイス（プリンタ２００）となる。

クライアント１００は取得したプリンタ構成情報のうちデバイス製造社５０１とプリンタ機種の情報から、ネットワーク７００上のデバイスを識別するためのデバイスＩＤを生成し、プラグアンドプレイを実行する。これにより、Ｐｒｉｎｔｅｒ ＡのＰＤＬ２用のドライバがデバイス（プリンタ２００）インストールされる。

ＰＤＬ１用のドライバは図５に示すプリンタ構成情報に基づいて通常のプラグアンドプレイインストールによりインストールされるので、クライアント１００は、全ての機能ドライバをプラグアンドプレイインストールできる。

以上の処理により、Helloメッセージパケットの受信を終了する（Ｓ４０８）。

本実施形態に拠れば、複数の機能ドライバをサポートするデバイスからプラグアンドプレイインストール用の識別子を１つしか取得できない場合でも、全ての機能ドライバをプラグアンドプレイインストールすることが可能になる。

（第２実施形態）
第１実施形態では、プロキシサーバ３００がデバイス（プリンタ２００）からＨｅｌｌｏメッセージを受信した場合の動作を説明したが、プロキシサーバ３００が能動的にデバイス（２００）にアクセスして情報を取得してもよい。例えば、プロキシサーバ３００がネットワーク７００上のデバイス（プリンタ２００）を探索し、探索の結果、検出したデバイス（プリンタ２００）からデバイス構成情報（プリンタ構成情報）を取得しても良い。

図８は、第２実施形態におけるクライアント１００、プロキシサーバ３００、デバイス（プリンタ２００）間の通信を概略的に示す図である。図８において、Ｐｒｏｂはデバイス探索用のメッセージであり、ＰｒｏｂＭａｔｃｈは、デバイスから返信されるＰｒｏｂに対する応答メッセージである。

図９は、第２実施形態におけるクライアント１００、プロキシサーバ３００、デバイス（プリンタ２００）間の通信を概略的に示す図であり、プロキシサーバ３００がデバイス探索用サーバとして機能する場合を例示する図である。

Ｓｕｂｓｃｒｉｂｅメッセージを受け、プロキシサーバ３００がデバイス探索用サーバとしてクライアント１００から利用される場合、クライアント１００に対してＨｅｌｌｏメッセージを送信する必要は無い。この場合、クライアント１００からデバイス構成情報（プリンタ構成情報）の問い合わせがあった場合に、プリンタ構成情報を通知する。若しくは、クライアント１００がプロキシサーバ３００にイベント通知の登録を行い、プロキシサーバ３００が未登録のデバイスを検出した場合に、プロキシサーバ３００はデバイス構成情報をクライアントに通知する。

プロキシサーバ３００は、Ｎｏｔｉｆｉｃａｔｉｏｎメッセージによりプリンタ２００から取得したプリンタ構成情報５００と、プリンタ構成情報５００に基づいて生成したプリンタ構成情報６００をクライアント１００に通知する。

尚、プロキシサーバ３００が代理する対象は、プリンタ２００に限らず、他のデバイスでも構わない。プリンタ以外のネットワーク対応型デバイスとしてはハードディスク等のストレージデバイス、スキャナ、複写機、ＦＡＸ及びそれら複合機能を備えるデバイス（複合装置）でもよい。デバイスが備える通信機能を介してプロキシサーバ３００と属性情報の交換、ジョブの送受信が可能な装置であればいずれの場合においても実現可能である。また、この場合、プロキシサーバ３００とネットワーク対応型デバイス間の通信プロトコルは標準化された、あるいは汎用プロトコルであっても、ベンダ固有のプロトコルであっても同様に実現可能である。

デバイスとプロキシサーバ３００との間は、ＵＳＢ、ＩＥＥＥ１３９４、パラレル通信などのローカル接続による通信によっても実現可能であるし、ネットワークは有線、無線を問わない。

また、上述の実施形態において、プロキシサーバ３００は独立に存在していたが、プロキシサーバ３００の機能はネットワーク対応型デバイスの内部もしくはクライアントの内部に物理的に、あるいは論理的に組み込まれている場合においても実現可能である。

この場合、ネットワークデバイスが有する能力に対応したデバイスドライバをプラグアンドプレイインストールするインストール部を有する情報処理装置は以下各部の構成を備えることになる。各部の処理は、例えば、クライアント１００の場合、ＣＰＵ１００１の制御の基に実行されることになる。

認識部は、ネットワークデバイスから取得した第１デバイス構成情報に基づき、ネットワークデバイスが有する第１の能力を認識する。判定部は、第１デバイス構成情報に基づき、ネットワークデバイスが他の能力を有するか判定する。また、生成部は、判定部の判定により、ネットワークデバイスが他の能力を有する場合、他の能力を第１の能力として書き換えた第２デバイス構成情報を生成し、第２デバイス構成情報に対応する仮想デバイス用の識別子を生成する。そして、送信部は、生成部により生成された識別子を、プラグアンドプレイインストールを実行するインストール部に送信する。

ここで、インストール部は、情報処理装置内に構成することも可能であり、他の情報処理装置内に構成することも可能である。

また、第１及び第２実施形態では、プロキシサーバ３００が提供するプロトコル変換の組み合わせとしてマイクロソフト社が主体となって提唱、策定しているＵｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙの例を示している。しかしながら、本発明の趣旨は、この例に限定されるものではなく、例えば、Ａｐｐｌｅ社の提案するＲｅｎｄｅｚｖｏｕｓに対しても実現可能である。また、ビジネス機械・情報システム産業教会（ＪＢＭＩＡ）が提案するＢＭＬｉｎｋＳなどのプロトコルに対しても実現可能である。

また、これらデバイスの検索、デバイスの制御が統合化されたプロトコルの適用に本発明の趣旨は限定されるものではない。例えば、Ｓｅｒｖｉｃｅ Ｌｏｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＬＰ）、Ｍｕｌｔｉｃａｓｔ ＤＮＳ Ｓｅｒｖｉｃｅ Ｄｉｓｃｏｖｅｒｙ等のデバイスが提供するサービスを検索するためのプロトコルへの利用も可能である。更に、Ｗｅｂ ＳｅｒｖｉｃｅのようにＸＭＬ／ＳＯＡＰをベースとしたＲｅｍｏｔｅ Ｐｒｏｃｅｄｕｒｅ Ｃａｌｌ（ＲＰＣ）形式によるデバイスの制御を、従来の制御プロトコルに変換するために利用することも可能である。

本発明に係る第１及び第２実施形態において、プロキシサーバ間の情報通知プロトコルとしてＨＴＴＰ／ＴＣＰ／ＵＤＰ／ＩＰプロトコルを使用した例を示しているが、本発明はトランスポート手段に依存するものではない。例えば、双方向の通信が可能であれば他の汎用プロトコル、あるいは独自プロトコルを使用した場合でも実現可能である。

本実施形態に拠れば、複数の機能ドライバをサポートするデバイスからインストール用の識別子を１つしか取得できない場合でも、全ての機能ドライバをネットワークプロトコルに従ってインストールすることが可能になる。

（他の実施形態）
第１及び第２実施形態の特徴的な処理は、プロキシサーバ３００の処理にある。プロキシサーバ３００は、先に説明したように、ハードディスク等の記憶装置を必要とするものの、パーソナルコンピュータ等の情報処理装置上で動作させるサーバアプリケーションプログラムで実現している。従って、本発明は、プロキシサーバ３００の処理を実行するためのコンピュータプログラムをその範疇とすることが可能である。

本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システムあるいは装置に供給することによっても、達成されることは言うまでもない。また、システムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによっても、達成されることは言うまでもない。

この場合、記憶媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。

プログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、不揮発性のメモリカード、ＲＯＭなどを用いることができる。

また、コンピュータが読出したプログラムコードを実行することにより、前述した実施形態の機能が実現される。また、プログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態が実現される場合も含まれることは言うまでもない。

第１及び第２実施形態に係る情報処理システムを構成する各デバイスのソフトウェアの構成を示す図である。 第１及び第２実施形態に係るクライアント及びプロキシサーバのハードウェア構成を示す図である。 第１及び第２実施形態に係るプリンタ２００のハードウェア構成を示す図である。 第１実施形態に係るプロキシサーバ３００がプリンタからＨｅｌｌｏメッセージを受信した時の動作を示すフローチャートである。 第１実施形態に係るプロキシサーバ３００がプリンタ２００から取得するプリンタ構成情報を示す図である。 第１実施形態に係るプロキシサーバ３００が生成する仮想的なプリンタ構成情報を示す図である。 第１実施形態に係るクライアント１００、プロキシサーバ３００、プリンタ２００間の通信を概略的に示す図である。 第２実施形態に係るクライアント１００、プロキシサーバ３００、プリンタ２００間の通信を概略的に示す図である。 第２実施形態に係るクライアント１００、プロキシサーバ３００、プリンタ２００間の通信を概略的に示す図である。

Claims (6)

1. ネットワークに接続されたデバイスから取得した識別情報により、前記デバイスが既に登録されているか否かを判定し、登録されていないデバイスである場合に、前記デバイスが有するコントローラに対応したデバイスドライバを前記デバイスにプラグアンドプレイインストールするインストール手段を有する情報処理装置で実行される情報処理方法であって、
   取得手段が、前記デバイスが有する少なくとも１つのコントローラにより少なくとも１つの種類のページ記述言語に対応した処理が可能であることを示すサポートコマンド情報と、前記コントローラに対応したデバイスドライバをプラグアンドプレイによりインストールするための設定であることを示す設定情報と、を含む構成情報を前記デバイスから取得する取得工程と、
   認識手段が、前記デバイスから取得した前記構成情報に含まれる前記設定情報を参照して、前記デバイスが有する前記コントローラに対応したデバイスドライバをプラグアンドプレイによりインストールするための設定がされていることを認識する認識工程と、
   判定手段が、前記構成情報に含まれる前記サポートコマンド情報を参照して、前記コントローラとは異なる第２のコントローラに関する情報が記述されており、当該第２のコントローラにより前記ページ記述言語とは異なる第２のページ記述言語に対応した処理が可能であるかを判定する判定工程と、
   生成手段が、前記判定工程の判定により、前記第２のページ記述言語に対応した処理が可能であると判定された場合、前記構成情報のうち、前記設定情報を前記第２のコントローラに対応したデバイスドライバをプラグアンドプレイによりインストールするための設定であることを示す情報に書き換えた第２構成情報と、前記第２のコントローラに対応したデバイスドライバをプラグアンドプレイインストールする際に前記デバイスを当該デバイスとは異なる仮想デバイスとして前記インストール手段に認識させるための第２の識別情報と、を生成する生成工程と、
   送信手段が、前記生成工程により生成された前記第２の識別情報を前記インストール手段に送信し、当該インストール手段からの要求に応じて前記第２構成情報を、前記インストール手段に送信する送信工程と
   を有することを特徴とする情報処理方法。
2. 前記ネットワークに接続された前記デバイスには、印刷機能およびＦＡＸ機能を有するネットワーク対応型の複合装置が含まれることを特徴とする請求項１に記載の情報処理方法。
3. ネットワークに接続されたデバイスから取得した識別情報により、前記デバイスが既に登録されているか否かを判定し、登録されていないデバイスである場合に、当該デバイスが有するコントローラに対応したデバイスドライバを前記デバイスにプラグアンドプレイインストールするインストール手段を有する情報処理装置であって、
   前記デバイスが有する少なくとも１つのコントローラにより少なくとも１つの種類のページ記述言語に対応した処理が可能であることを示すサポートコマンド情報と、前記コントローラに対応したデバイスドライバをプラグアンドプレイによりインストールするための設定であることを示す設定情報と、を含む構成情報を前記デバイスから取得する取得手段と、
   前記デバイスから取得した前記構成情報に含まれる前記設定情報を参照して、前記デバイスが有する前記コントローラに対応したデバイスドライバをプラグアンドプレイによりインストールするための設定がされていることを認識する認識手段と、
   前記構成情報に含まれる前記サポートコマンド情報を参照して、前記コントローラとは異なる第２のコントローラに関する情報が記述されており、当該第２のコントローラにより前記ページ記述言語とは異なる第２のページ記述言語に対応した処理が可能であるかを判定する判定手段と、
   前記判定手段の判定により、前記第２のページ記述言語に対応した処理が可能であると判定された場合、前記構成情報のうち、前記設定情報を前記第２のコントローラに対応したデバイスドライバをプラグアンドプレイによりインストールするための設定であることを示す情報に書き換えた第２構成情報と、前記第２のコントローラに対応したデバイスドライバをプラグアンドプレイインストールする際に前記デバイスを当該デバイスとは異なる仮想デバイスとして前記インストール手段に認識させるための第２の識別情報と、を生成する生成手段と、
   前記生成手段により生成された前記第２の識別情報を前記インストール手段に送信し、当該インストール手段からの要求に応じて前記第２構成情報を、前記インストール手段に送信する送信手段と
   を備えることを特徴とする情報処理装置。
4. 前記ネットワークに接続された前記デバイスには、印刷機能およびＦＡＸ機能を有するネットワーク対応型の複合装置が含まれることを特徴とする請求項３に記載の情報処理装置。
5. 請求項１または２に記載の情報処理方法をコンピュータに実行させることを特徴とするプログラム。
6. 請求項５に記載のプログラムを格納したことを特徴とするコンピュータ可読の記憶媒体。

Images