次に本発明を実施するための最良の形態について図面を参照して説明する。
<システム構成の説明>
図1は、本発明の一実施形態を示す情報処理装置及び周辺装置を適用可能な印刷システムの構成を説明するブロック図であり、ネットワークNETを介して、本発明の情報処理装置の好適な一例であるクライアントPC(以下、単にクライアントともいう)と周辺装置としてのプリンタPRとが通信可能な印刷システムの例に対応する。周辺装置としては、プリンタ、複写機、ファクシミリ若しくはこれらの複合機などの画像形成装置、又はデジタルカメラを含む。なお、本発明はクライアント側で実行されるアプリケーションとネットワークプリンタに実装されるサービスから構成され、各機能モジュールより構成される。
図1において、1は本発明の特徴的な構成の一つであるクライアントPCに提供されるアプリケーション部で、クライアントが動作しているオペレーティングシステム環境上で動作するソフトウエアであり、通信機能としてTCP,UDP,IPプロトコルスタック部2を備え、そのプロトコルスタック上でHTTP1.1 に準ずるHyper Text Transfer Protocol部3を備え、後述のSOAP(Simple Object Access Protocol)リクエストの発行処理部4、およびレスポンスの解析を実行する解析処理部5を備える。
なお、アプリケーション部1には、後述するようなAutomatic Driver Downloader、Configurator、SOAPレスポンス発行処理部、SOAPパーサ等のアプリケーションモジュールが該当するものとする。
6はGUIモジュール部(GUI)で、ユーザに対しインタラクティブに要求の受付、アプリケーション部1の制御に応じて、および処理結果の表示処理を実行する。7はConfiguratorモジュール部(Configurator)で、ネットワークを介してプリンタより取得したドライバを、あわせてプリンタより取得したネットワーク情報をもとに、クライアントが保持する記録装置に対しイントール処理を実行するとともに、オペレーティングシステムに対し、ドライバ情報の登録を実行する。
なお、イントール実行の際には、Memory Controller部(Memory Controller)8を介してメモリスペースの有無、およびイントール先の管理制御を実行する。100はドライバ自動ダウンロード・設定モジュール部である。
一方、ネットワークサービス、本実施形態ではネットワーク対応型プリンタPRには、通信機能としてTCP/UDP/IPプロトコルスタック部9を備え、そのプロトコルスタック部(TCP/UDP/IPIPProtocol Stack)9上でHTTP1.1 に準ずるHyper Text Transfer Protocol部10を備え、後述のSOAP (Simple Object Access Protocol)リクエストの解析処理部11、およびレスポンスの発行を実行する発行処理部12を備える。
また、プロトコルスタック部9上にはPrint Protocolモジュール部(Print Protocol)13が実装され、クライアントPCから発行されるプリンタ要求を解析しPrinter Controller部(Print Controller)14に対し該要求を送出する機能を備える。
15はMemory Controller部で、レスポンスを生成する際にドライバが格納されているディレクトリ情報の管理、データサイズ情報の管理機能を備えるとともに、ドライバ送信時において記録装置から読み出したドライバをHyper Text Transfer Protocol部10に対し送出処理を実行する機能を備える。
図2は、本発明の情報処理装置並びに周辺装置並びに代理応答装置に好適なハードウェア構成の一例を示す図であり、情報処理装置の好適な一例であるクライアントPCは、標準的なPCで構成される。なお、クライアントPC(ClientPC)は、図2に示すハードウェア構成を含む。クライアントPCは、バス1206を介して、ランダムアクセスメモリ部(RAM1201),記憶部であるハードディスクドライブ部(HDD1202)、入力部の一例であるキーボード部(KBD1203)、制御部の一例であるCPU1204、表示部の一例である表示用ディスプレイ(LCD1205)、通信制御部の一例であるネットワークボード(NB1207)を含む。HDDや可搬性CD−ROM又は内部据付のROMなどの他の記憶手段であってもよいことは言うまでも無い。
図1に示した1乃至8の各モジュールは、HDD1202に記憶され、必要に応じてRAM1201に読み出されてCPU1204により実行される。これにより、CPU1204が、図3の処理を行い、図1の各モジュールが果たす機能を実現する。
また、図1のプリンタ側も同様に図2に示すハードウェア構成を採る。異なるのは、印刷処理を行うプリンタコントローラ(図示省略)を有する点である。図1に示す9乃至15の各モジュールも、プリンタのHDD又はROMに記憶され、必要に応じてRAMに読み出されCPUにて実行される。
図3は、本発明に係るネットワークシステムの構成を説明するブロック図であり、クライアントPC(ClientPC)851,プリンタ(Printer)852,代理サーバ(Proxy Sever)853がネットワークを介して通信可能なシステムに対応する。
なお、図3に示す本発明の代理応答装置の好適な一例である代理サーバ853に記憶されたSOAPレスポンス発行処理部815、SOAPリクエスト解析処理部(SOAPParser)816、Simple Network Management Protocol処理部(SNMP)817、Hyper Text Transfer Protocol部814、TCP/UDP/IPプロトコルスタック部813の各モジュールも、また、同様に図2に示すハードウェアにおいて実行される。自動ドライバ設定部801、TCP/UDP/IPプロトコルスタック部(TCP/UDP/IPProtocol Stack)802、GUIモジュール部(GUI)806、SOAPリクエスト発行処理部(SOAPGenerator)804、SOAPリクエスト解析処理部(SOAPParser)805、コンフィギュレータモジュール部(Configuator)807、HTTP部(HTTP)803も同様に図2に示すハードウェアで実行される。メモリコントローラ部808は、基本的に独立なハードウェアで構成されることが多い。
また、図3のプリンタ852側も、図2に示すハードウェア構成をしている。周辺装置の好適な一例であるプリンタであれば、プリンタコントローラ(図示省略)もバスに接続される。TCP/UDP/IPプロトコルスタック部809、Simple Network Management Protocol処理部810、プリントプロトコルモジュール部811の各モジュールも、HDDからRAMに読み出され、CPUにより実行される。プリンタコントローラ部812は独立のCPUを用いても良い。ただし、図3のプリンタ852は図1のプリンタと異なり、UPnPに関連するアプリケーション部は無い。
図4は、本発明に係る情報処理装置と印刷装置とを適用可能な印刷システムにおけるデータ処理手順の一例を示すフローチャートである。なお、S1〜S24は各ステップを示す。
図5は、図1に示したクライアントPC上に表示される印刷設定画面の一例を示す図であり、プリンタ選択画面中に、選択可能なプリンタ名と新規プリンタの検索と追加を指示できる項目が表示されている状態に対応する。
ネットワーク接続されたクライアント、例えばパーソナルコンピュータ(クライアントPC)上で動作するアプリケーション、例えばワードプロセッサアプリケーションで作成ドキュメントを印刷する場合、メニューより「印刷」を選択すると(S1)、図5に示すように現在クライアントPCの表示装置に登録済みのプリンタがリスト表示される。
次に、ステップS2で、リスト上に現れているプリンタでの印字を実行するかどうかを判断して、リスト上に現れているプリンタでの印字を実行すると判断した場合は、いずれかのプリンタをユーザがポインティングデバイスやカーソル指示キーを操作指示により選択することで、作成したドキュメントは該当するドライバにより印字可能データに変換された後に、ネットワークを介して指定したプリンタに送信されて通常印刷処理される(S3)。
一方、ステップ(S2)で、リスト上に登録されているプリンタ以外での印字をユーザが希望する場合、すなわち、ネットワーク上に新規に追加されたプリンタを使用する場合、あるいは、ユーザが移動先のオフィス等のネットワーク環境上において利用可能なプリンタを使用する必要が生じた場合、図5に示したリスト上の新規プリンタの検索・追加を選択する。
この選択を実行すると、本発明であるアプリケーションAutomaticDriver Downloader/Configurator(自動ドライバダウンロード設定モジュール部)100が起動される(S4)。
このようにして自動ドライバダウンロード設定モジュール部が起動すると、アプリケーション部1に含まれるドライバ自動ダウンロード設定モジュール部100は、ネットワークNET上に利用可能なプリンタが存在するか探索するために検索処理を行う(S5)。その際、検索に使用されるプロトコルは、本実施形態では、所定の探索要求の好適な一例である例えばUniversal Plugand Play Architecture1.0 にて規定されるSimple Service Discovery Protocolを使用する。ドライバ自動ダウンロード設定モジュール部(発行手段)は、マルチキャストアドレス「239.255.255.250 」、ポート番号「1900」に対し図6に示すフォーマットのHTTPパケットを発行する。なお、所定の探索要求はUPnPの探索要求に限るものではない。
図6は、図1に示したクライアントPCからプリンタPRに対して発行されるHTTPリクエストの一例を示す図である。
本実施形態においては、その際、HTTPリクエストのエンティティボディとしてSimple Object Access Protocolを使用し、検索パケット発行時にクライアントPCの使用しているオペレーティングシステム(OS)の情報を通知する。
その際の書式は、図6に示すフォーマット中のEnvelopeタグ内に記述され、GetDriverInformationリクエスト(ドライバ情報取得要求)の引数としてSupportedOS,OSVersionが通知される。
ここでSupportedOSはオペレーティングシステム名称(本実施形態では、図4に示すように、Windows(登録商標)98であり、OSVersionはそのバージョン(本実施形態では、図6に示すように「4.10.2222A」の場合を示す。
次に、本発明が適用されるネットワーク対応プリンタPRは、上記HTTPリクエスト(SSDPリクエスト)を受信した後(S6)、そのリクエストのST(Service Type)ヘッダを解析し、プリンタPRに対するリクエスト要求に一致する(ヘッダ内容がPrint)かどうかを判断して(S7)、NO、例えばPrint以外のST指定であった場合、あるいはパケット内容に不正があった場合は処理を中断し、リクエストに対してレスポンスを発行せず、無視するようにステップS6へ戻る。
また、ステップS2では、ネットワークに接続された所定のサービスを表示してもよい。また、ホストが発行するSTヘッダにおいては、もちろん複数のプリンタを含むサービスを指定可能である。ここで、装置単位ではなく、STヘッダに対して、特定のサービス、例えば、スキャンサービス、デジタルカメラのサービス、プリントサービス単位で指定することも考え得る。例えば、ホストの表示画面でプリントサービスを指定すると、STヘッダにプリントサービスを含ませたUPnPに基づく探索要求をプリンタに対して送信する。そして、プリンタ側のSOAPリクエスト解析処理部は、該要求を認識し、STヘッダにプリンタサービスが指定されていることを認識するのに応じて、デバイスIDを返信する。プリントサービスを提供できる装置は、ホストにおいて、プリントサービスを提供可能な、各装置のデバイスIDを抽出して図8と同様に表示される。そして、ユーザが、サービス探索に対して応答してきたプリントサービスを提供可能であると判断された印刷装置を複数指定して前述のインストール処理を行うこともできる。
また、ステップS7で、該ヘッダ内容がPrintであったと判断した場合、引き続き、HTTPリクエストエンティティボディの解析を実行する。そして、HTTPリクエストエンティティSOAPメッセージをSOAPリクエスト解析処理部にて解析し、GetDriverInformationリクエストの引数であるSupportedOS,OSVersionの内容をチェックし、ネットワーク対応プリンタ内の記録装置内に該当するドライバが記録されていない場合、該リクエストに対するレスポンスは発行せず、要求を無視して、ステップS6へ戻る。
一方、ステップS7で、該当するドライバが記録されていると判断した場合、クライアントPCに対しユニキャストでHTTPレスポンスを発行する(S8)。
本実施形態においては、その際、HTTPレスポンスのエンティティボディとしてSimple Object Access Protocolを使用し、プリンタ内記録装置内に記録されているドライバに関する以下の情報をクライアントに対し通知する。ドライバ自動ダウンロード設定モジュール部100(取得手段)は、これらの情報をTCP/UDP/IPモジュール部を介して取得する。
これら情報は、図5に示すデバイス構成情報としてEnvelopeタグ内に記述され、クライアントPCがプリンタPRに要求したGetDriverInformationリクエストに対する戻り値として以下のレスポンスがクライアントPCに通知される。SOAPリクエスト解析処理部5(取得手段)は、TCP/UDP/IPモジュールを介してデバイス構成情報を取得する。
図7は、図1に示したプリンタPRからクライアントPCに通知されるHTTPレスポンスの一例を示す図である。
図7に示すデバイス構成情報は、ドライバ情報取得要求の応答における所定の領域にプリンタのSOAPレスポンス発行処理部12又は、後述する代理サーバ853のSOAPレスポンス発行処理部815(付加手段)が挿入して付加する。つまり、SOAPレスポンス発行処理部12は、Envelopeタグ内のGetDriverInformationリクエストに対する戻り値を記述するための領域に挿入して付加する。そして、SOAPレスポンス発行処理部12は、クライアントPCに向けて送信するようHyper Text Transfer Protocol部10を制御し、応答処理を行う。図7に示すように、元々のUPnP1.0の拡張領域にデバイス構成情報として、該プリンタのプリンタドライバを格納した記憶領域を示すURL、プリンタ製造者名、機種名、プリンタの有する能力を示す情報を挿入する。
例えば、PrinterMakeAndModelはプリンタ製造者名・機種名を示し、PrinterNameはプリンタ名を示し、PrinterPDLはプリンタがサポートするページ記述言語を示し、PrinterLocationはプリンタ設置場所を示し、IPAddressはプリンタIPアドレスを示し、DriverVersionはドライババージョンを示し、DriverDataSizeはドライバデータサイズを示し、DriverRequiredMemorySizeはドライバ必要メモリサイズを示し、DriverURLはドライバ格納URLを示す。DriverURLの代わりに、プリンタドライバの格納された記憶領域を示す情報としては、マイクロソフト社の提唱するUNCパス名を指定して、ネットワーク上のサーバが有する記憶手段の所定の記憶領域からドライバを取得するようにしてもよい。
これらのデバイス構成情報は、SOAPレスポンス解析処理部5(認識手段)により解析される。そして、SOAPレスポンス解析処理部5は、デバイス構成情報から、プリンタの識別情報の好適な一例であるデバイスIDを抽出し、認識する。ここで、デバイスIDは、プリンタを一意に識別できるものであればよいが、以下では、前述の図7に示すデバイス構成情報のうち,プリンタ製造者名と機種名のペアをデバイスIDとして、プリンタを特定する例を考えている。
以下、UPnPのようなネットワークに接続された機器がネットワーク越しにネゴシエーションを行う際に授受される情報をデバイス構成情報という。アプリケーション部1が、デバイス構成情報から抽出する情報であって、プリンタを特定可能な識別情報をデバイスIDという。本実施形態では、デバイスIDとして、機種とプリンタ製造者名の組を用いる。そして、ローカル接続に用いられるインタフェース(例えばUSBやIEEE1284など)においては、デバイスIDは、特定の番号に対応付けられて管理されている。
次に、ステップS9で、あらかじめ規定された時間内にレスポンスが受信されたかどうかを判断し、あらかじめ規定された時間内にレスポンスが受信されなかったと判断した場合は、GUI モジュール部6を介してクライアントPCの表示装置上を介してユーザに対し、その旨を示すメッセージを表示して(S10)、処理を終了する(S22)。
一方、ステップS9で、あらかじめ規定された時間内にレスポンスを受信したと判断した場合は、応答の結果に基づいて、受け取ったクライアントPCのアプリケーション部1はGUIモジュール部6を制御して、後述するデバイス構成情報を含むレスポンスのあったネットワークプリンタのプリンタ名をクライアントPCの表示装置上に図8に示すとおりリスト表示する(S11)。
図8は、図1に示したクライアントPC上に表示される新規に検索されたプリンタ一覧を表示した画面の一例を示す図である。
次に、ユーザは該リストをもとに希望するプリンタ名を選択指示すると、選択指示がGUIを介してアプリケーション部1(指示手段)に入力される(S12)。アプリケーション部1は、該プリンタの選択指示の入力に応答して、以下のデバイスIDの変換処理を行う。
まず、アプリケーション部1(判断手段)は、クライアント側オペレーティングシステムが管理するドライバデータベースを検索し、該当ドライバがクライアントPC側記録装置(例えばハードディスク)上に格納されているか否か(Driver有りか否か)をチェックして判断する(S13)。そして、アプリケーション部1(インストール制御手段)は、格納されていると判断した場合は、そのドライバのイントール処理に移行する(S14)。
その際、アプリケーション部1は、該ドライバに対し、プリンタから取得したプリンタIPアドレスを設定すると共に、デバイス構成情報からプラグアンドプレイインストーラが認識可能なデバイス番号を抽出して認識する処理を行って、プラグアンドプレインストーラに入力し、インストール処理を開始するようプラグアンドプレイインストーラを制御する。デバイスIDを受け取ったプラグアンドプレイインストーラは、OSのAPIを呼び出して、システムインストーラにインストール処理を開始し、ドライバインストールを完了する(S15)。
上記のデバイスIDを用いて、アプリケーション部1は、IEEE1284−2000に対応した本発明のインストーラであるプラグアンドプレイインストーラは、インストール処理するようプラグアンドプレイインストーラを制御する。ここでは、IEEE1284−2000を用いたが、通信インタフェースとしては、接続された機器を特定することができるデバイス番号を授受可能なインタフェースであれば、どんなものでもよい。
なお、Microsoft社が提供するWindows(登録商標)に代表されるように、クライアント側オペレーティングシステム自身がドライバインストールを実施するためのPlug and Play関連API (Application Program Interface)を活用するため、以下の仕組みを検討する。
例えば、USBに対応したプラグアンドプレイインストーラにおいて、インストーラの好適な一例であるプラグアンドプレイインストーラを動作させることもできる。以下、USB形式のデバイス番号を用いたステップS13〜S15のプラグアンドプレイインストール処理の詳細を示す。USBのデバイス番号を用いる場合は、製造メーカと機種名の組合せを用いて、所定の形式でデバイス番号を構成する。ここで、アプリケーション部1は、図7のデバイス構成情報からデバイスIDを抽出することができる。そして、USBで規定された所定の形式でデバイスIDを16進表示で示したデバイス番号は、以下のようになる。
例えば、04a9番に対しては、ある複数メーカのうち製造メーカKaisha Incが対応付けられ、該04a9番の階層の下に構成される複数の番号の一つである1051番に対して、Printer330が対応付けられるというように考えることが出来る。アプリケーション部1は、デバイス番号である04a9番と1051番のペアをプラグアンドプレイインストーラに入力して、プラグアンドプレイインストーラに、後述するインストール処理を行わせる。
上述の場合は、ステップS13からステップS15までのプロセスは、プアグアンドプレイインストーラと、システムインストーラがインストール処理を実行することになる。プアグアンドプレイ機能が提供されないオペレーティングシステムにおいてはアプリケーション部1が全プロセスを実行する。
図9は、本発明の実施形態におけるホストコンピュータ(PC)内のソフトウエア構成を示す図である。ホストコンピュータPCは基本的には、図1に示すホストコンピュータPCと同様のものである。アプリケーション部1も、図1に示すアプリケーション部と同様のものである。
また、図9に示す四角形で囲まれたブロック1、2,3,6,システム管理部1001,ドライバ管理部1002,デバイスID・ドライバパスリスト1003,ドライバ格納部1004,プラグアンドプレイインストーラ1005、システムインストーラ1009は、プログラムモジュールで構成されており、ホストコンピュータ内の外部メモリに記憶されており、必要に応じてRAMに読み出されてCPUによって制御される。デバイス番号は、周辺装置(例えば、プリンタPR)を識別するための情報である。なお、図1と同一のものには同一の符号を付してある。
図9において、デバイスID・ドライバパスリスト1003は、デバイス番号並びにドライバパスリストの組からなるデータベースであるデバイス番号・ドライバパスリストのデータベースである。ここでいう、ドライバパスとは、デバイスドライバ(ここではプリンタドライバ例を挙げている)のホストコンピュータに備えられた外部メモリ、或いは、ホストコンピュータとネットワークを介して接続されたファイルサーバ1010内の外部メモリにおける格納場所(パス)のことである。プラグアンドプレイインストーラ1005は、デバイス番号をキーにドライバパスを検索して認識し、該ドライバパスに配置されているプリンタドライバを取得する。そして、プリンタドライバインストーラとして機能するシステムインストーラ1009は、該取得したプリンタドライバをドライバ格納部1004にインストールする。なお、1010はネットワーク3000を介して通信可能なファイルサーバである。
図10は、図1に示したアプリケーション部1のテーブルを説明する図であり、本テーブルは、デバイスID,USBデバイス番号、ドライバが格納されたパスが記憶されている。
図10において、1301はデバイス構成情報の一部として製造者名、機種名の組であるデバイスID1305とUSBデバイス番号1304を対応付けるアプリケーション部1内のテーブルである。1003は前記USBデバイス番号1304をドライバが格納されたパスと対応付けるデバイスID・ドライバパスリストである。
次に、インストール処理の詳細をプラグアンドプレイに対応したプラグアンドプレイインストーラ1005を例として説明する。
プリンタ(PR)は、図7に示すデバイス構成情報をクライアントPCに対して送信する。プリンタPRからデバイス構成情報を取得したクライアントPCは、クライアントPC内のHDD等にデバイス構成情報を記憶する。図7に示すデバイス構成情報の元になる、下記に示すような、プリンタのデバイスIDをHDDに記憶されたデバイス構成情報の中から、アプリケーション部1(取得手段)が抽出して取得する。
「<PrinerMakeAndModel>ABC Printer Series 123</PrinerMakeAndModel>」
アプリケーション部1は、製造者がABC社で、機種Printer Series 123であることを文字列処理により認識する。そして、アプリケーション部1は、プリンタ製造メーカとプリンタ機種名の組合せであるデバイスID1305を、デバイスIDに対応付け可能なデバイス番号を対応付けるアプリケーション部1内のテーブル1301を持っている。そして、アプリケーション部1(変換手段)は、取得したデバイスIDを、USBに対応したプラグアンドプレイインストーラ1005(インストール手段)が認識可能なデバイス番号1304(上述の例では、04a9と、1051の組)に変換する。
プラグアンドプレイインストーラ1005は、アプリケーション部1によって変換されたデバイス番号1304をアプリケーション部1から取得する。プラグアンドプレイインストーラがデバイス番号・ドライバパスリスト1003を検索し、デバイス番号に対応するプリンタドライバが格納されたパス1303を認識して特定する。
次に、プラグアンドプレイインストーラ1005(インストール手段)は、OSのAPIから、システムインストーラ1009を呼び出す。そして、システムインストーラ1009は、ファイルサーバ1010又はクライアントPCの有する外部メモリに記憶されたプリンタドライバを取得して、ドライバ格納部1004にインストールする。同時に、システムインストーラは、自動的にドライバ管理部1002にデバイス番号に基づいてプリンタを登録するようシステム管理部1001に登録依頼を行う。以後、OSはドライバが登録されていることを認識するので、ドライバ格納部に格納されたプリンタドライバを適宜ローディングして印刷に関する各種処理を行う。なお、本実施形態では機器の識別情報を送受信するための方法の一例として、USBを用いているが、IEEE1284―2000など、他のデバイス番号に対応したインタフェースを用いてもよい。これにより、UPnPの管理方式で管理される情報を活用し、システムの大幅な変更を行うことなく、既存のプラグアンドプレイインストーラを活用することができる。
なお、インタフェースがIEEE1284−2000である場合は以下のようになる。まず、アプリケーション部1(変換手段)は、プリンタPRから通知されたHTTPレスポンス、プリンタ製造者名並びにプリンタ機種名を示すPrinterMakerAndModel,プリンタ名を示すPrinterName,プリンタが対応する言語を示すPrinterPDLを含むデバイス構成情報から、IEEE1284−2000で利用可能なデバイス構成情報を抽出する。IEEE1284−2000においては、以下のデバイス構成情報を、IEEE1284−2000のインタフェースに入力可能である。
「MANUFACTURER(デバイス製造者):ABC;
COMMAND SET(サポートコマンド・言語):LIPS;
MODEL(プリンタ機種):Printer Series 123;
COMMENT(コメント):Located in Room33;
ACTIVE COMMAND SET(アクティブなコマンド・言語):LIPS;」
ここでは、アプリケーション部1は、上記のデバイス構成情報から,MANUFACTURERと、MODELの値の組をデバイスIDとして抽出する。そして、アプリケーション部1は、IEEE1284−2000に対応のインストーラが認識可能なデバイス番号の形式で、プラグアンドプレイインストーラに入力する。アプリケーション部1は、上記のデバイス番号と、IPアドレスを、オペレーティングシステムに対しAPIを介してプラグアンドプレイを行うインストールモジュールに通知する。IEEE1284−2000に対応したプラグアンドプレイインストーラは、上記の構成情報から、デバイス番号を利用してインストールする。
また、IEEE1394においても、アプリケーション部1は、同様に製造者名と機種名の組からのデバイスIDを構成し、デバイスIDをIEEE1394の形式のデバイス番号に変換する。そして、プラグアンドプレイインストーラは、ドライバパスを認識し、処理を行う。また、上記では、単にデバイス番号と述べているが、デバイスを認識できる情報であれば、デバイス番号の代わりにローマ字や装置に付与可能なアドレスの形式としてもよい。
ここでは、プリンタからデバイスIDを含むデバイス構成情報を受信したクライアントPCは、クライアントPCのアプリケーション部1において変換処理を行う例を示した。しかし、周辺装置側において、アプリケーション部1内のテーブル1301と同様のテーブルを持たせ、周辺装置側で製造者名と機種名であるデバイスIDに基づいてデバイス番号を発行してもよい。そして、USBデバイス番号をそのままの形式でクライアントPCが受信して、プラグアンドプレイインストーラは変換処理を行うことなく、該USBデバイス番号を使ってインストールしてもよい。
一方、ステップS13において、アプリケーション部1(判断手段)が、クライアントPC側記録装置上に該ドライバが格納されていなかったと判断した場合、先にプリンタから取得したドライバ必要メモリサイズとユーザが指定したクライアントPC側の記録装置の空き容量をチェックしてダウンロード可能かどうかを判断し(S16)、必要なメモリサイズが確保できないと判断した場合(ダウンロードできないと判断した場合)は、クライアントPCの表示装置上にエラーメッセージによりその旨をユーザに通知して(S17)、処理を終了する(S23)。
一方、ステップS16で、必要なメモリサイズが確保できる場合(ダウンロードできると判断した場合)には、クライアントPCはドライバ格納URLに対してHTTP GET リクエストを発行し(S18)、アプリケーション部1(制御プログラム取得手段)は、ネットワークプリンタ記録装置に記録されているドライバのダウンロードを実行する(S19)。
そして、ドライバのダウンロードが完了した時点で、クライアントPC側記憶装置上でドライバは自己解凍が実行され、自己インストール処理(自動インストール処理)を実行する(S20)。その際、アプリケーションは該ドライバに対し、プリンタから取得したプリンタIPアドレスを設定しドライバインストールを完了する(S21)。以上の処理が完了した時点で、新規プリンタのクライアントシステムへの登録が完了し、アプリケーションからの利用が可能な状態となる。なお、ドライバ格納URLはネットワーク上のプリンタ等の周辺装置や他の情報処理装置のアドレスも含まれる。
以上説明したように上記実施形態によれば、該当するプリンタドライバが入手できない場合、すなわちオペレーティングシステムの管理するデータベース上にプリンタドライバが存在しない場合、あるいは外部記録媒体の形でユーザがその場に所持していない場合であっても、外部から周辺装置に適したデバイスドライバを取得することができ、異なるネットワーク環境に移動した場合であっても、プリンタを使用することが可能になる。
さらに、デバイス構成情報を用いて各周辺装置並びにホストコンピュータはネゴシエーションするので、それまで使用していたネットワーク環境と異なる環境に、例えばビルA内のオフィスのネットワーク環境から、異なるビルB内のオフィスに移動し、その移動先においてクライアントが保持するドキュメントをプリントする必要が生じた場合において、移動先ネットワーク上に存在するプリンタのドライバのインストール、およびネットワーク情報の設定等の作業を改めて実行する必要がなくなる。
また、選択される特定のサービスに基づき、該特定のサービスを実行可能な登録済みの周辺装置情報および新規利用可能な周辺装置の検索および追加を指示する項目を表示装置に表示した状態で、検索および追加を指示する項目が選択された場合に、ネットワーク上に存在する利用可能な周辺装置を検索する検索要求を発行し、該発行された前記検索要求に応じて利用可能な周辺装置から応答されるデバイス構成情報を取得し、該取得された周辺装置の一覧を表示装置に表示するので、情報処理装置のネットワーク接続環境が物理的に変動した場合であっても、簡単な操作でアプリケーションからの周辺装置を選択した際に、登録されている周辺装置以外に新たにネットワーク接続されている周辺装置候補を容易に確認することができる。
また、取得された周辺装置の一覧が表示装置に表示された状態で、該周辺装置の一覧から特定のサービスの提供を受ける周辺装置が選択されると、該選択された周辺装置を動作させるためのドライバソフトウエアが既に登録されているかどうかを判断した際に、周辺装置が既に登録されていると判断した場合には、登録されているドライバソフトウエアに対して前記デバイス構成情報に基づくネットワーク設定を組み込んで前記周辺装置を動作可能状態に設定し、周辺装置が既に登録されていないと判断した場合には、選択された周辺装置に記憶されるドライバソフトウエアを前記デバイス構成情報に基づくドライバダウンロード先から取得して、該取得されたドライバソフトウエアに対してネットワーク設定を組み込んで前記周辺装置を動作可能状態に設定するので、情報処理装置のネットワーク環境が物理的に変動した場合であっても、新規接続されている周辺装置を動作させるためのやっかいなドライバインストールおよびその設定操作を自動化して、ユーザによるネットワーク接続操作処理負担を大幅に軽減して、新たなネットワーク環境下で自在に周辺装置を選択して意図するサービス処理を正常に動作させることができる。
さらに、情報処理装置から発行されるデバイス検索条件が前記所定のサービス要求に一致しているかどうかを判断した際に、所定のサービス要求に一致していると判断した場合に、ネットワーク環境下におけるデバイス構成情報を情報処理装置に返信することにより、既存のネットワークに新たに情報処理装置が接続されるようなネットワーク環境仕様が変動した場合に、該情報処理装置からの要求に応じて適時に周辺装置を正常に動作させるまでに必要なデバイス構成情報を情報処理装置に提示することができ、ユーザによるネットワーク設定操作負担を大幅に軽減することができる等の効果を奏する。
上記の実施形態では、ネットワークサービスとしてネットワーク対応型プリンタがSOAP処理部を実装し、クライアントから発行されるGetDriverInormationリクエスト(ドライバ情報を取得する要求)をプリンタ自身が解析し、クライアントに対し直接、デバイスIDを含むプリンタ識別情報を含むプリンタデバイス構成情報をレスポンスとして返送していたが、本発明は代理サーバを設けることでも実現可能である。代理サーバは、図1に示すプリンタPRと対応する各モジュールを有している。以下、前述の例と異なる部分を中心に説明する。
この場合、図3に示すように、本発明の代理応答装置の好適な一例である代理サーバ853は通信機能としてTCP/UDP/IPプロトコルスタック部813を備え、そのプロトコルスタック上にHTTP1.1に準拠するモジュールであるHyper Text Transfer Protocol部814を備えHTTPリクエストの解析、およびレスポンス処理を行う。クライアントPC851は、図1に示すクライアントPCと同様のコンピュータである。
本実施形態においては、クライアントからのリクエストにおいて、HTTPリクエストのエンティティボディ部においてSOAP(Simple Object Access Protocol)を使用しており、該処理モジュールSOAPレスポンスの発行処理部815,SOAPリクエストの解析処理部816がHypert Text Transfer Protocol部814の上位層に実装される。さらに代理サーバ853は、Simple NetworkManagement Protocol(SNMP)処理部817を備え、ネットワーク上に存在するネットワーク対応プリンタの検索、およびデバイス構成情報を取得する。
なお、代理サーバに接続されるプリンタが複数ある場合には、代理サーバ内のSNMP処理部817(認識手段)は、複数のプリンタからSNMPを用いて、デバイス構成情報を単にSNMPのデータ形式にしただけであるデバイス情報を取得して認識する。そして、クライアントPCから、SOAPリクエスト解析処理部816が、複数のプリンタの一部であって、複数の特定のプリンタを探索する要求をTCP/UDP/IPプロトコルスタック部813を介して取得した場合には、SOAPリクエスト解析処理部816(抽出手段)は、該特定のプリンタのデバイスIDを、先に取得した複数のプリンタのデバイス構成情報から抽出する。そして、SOAPレスポンスの発行処理部815(付加手段)が、SNMPを用いて取得したデバイス情報からデバイスIDを生成する。
そして、前述のプリンタPR時の応答と同様に、SOAPレスポンスの発行処理部815(応答手段)が、ドライバ情報取得要求の応答の所定の領域、つまり、Envelopeタグ内のGetDriverInformationリクエストに対する戻り値を記述する領域に挿入して付加して、Hyper TextTransfer Protocolスタック部813を制御して応答する処理を制御するようにしてもよい。
一方、周辺装置の好適な一例であるネットワーク対応型のプリンタPR852は、通信機能としてTCP/UDP/IPプロトコルスタック部809、およびPrint Protocolモジュール部811、Print Controller部812を備える点は前述の例と同様であるが、ここでは、TCP/UDP/IPプロトコルスタック部809上にはSimple NetworkManagement Protocol810が実装されており、本発明の代理サーバから発行されるリクエストの解析、およびレスポンスの発行を実行する処理部をさらに備える。
代理サーバ853は代理サーバの起動後、予め定められたインターバルに基づいてSNMP部817より、以下のMIB(マネジメントインフォーメーションベース)オブジェクトに対してSNMP部817からGetリクエストをブロードキャストすることで、ネットワーク上に存在するデバイス構成情報を取得する。SNMP(Simple Network Management Protocol)とは、周辺装置を設定・管理するためのプロトコルである。MIBとは、RFC1213,1759等に定義されており、SNMPにおいて管理できる項目を保持管理するためのデータベース形式である。
前述のSNMPを実装したネットワーク対応プリンタは、該リクエストに対し、各オブジェクトに該当する情報を生成した後に、SNMPレスポンスとして代理サーバ853に対し、ユニキャストで応答を送信する。
ここで、代理サーバは、UPnPにおいて周辺装置とするための識別情報の生成に必要となる情報の項目のリストを有している。例えば、該項目とは、プリンタ製造者名、機種名(製品名称)、プリンタ名、プリンタ設置場所、IPアドレス、サポートするページ記述言語、サポートするプリントプロトコルである。SNMPレスポンスが含むMIB情報から、UPnPにおいて周辺装置とするための識別情報の生成に必要となる情報の項目のリストに従って、必要な情報を抽出し、UPnPに好適なXMLの形式に変換する。ここでは、下記のようなデータが抽出されるものとする。
「PrinterMakeAndModel : プリンタベンダ・製品名称PrinterName: プリンタ名
PrinterLocation: プリンタ設置場所
IPAddress: プリンタ IP アドレス
PrinterPDL: サポートするページ記述言語
SupportedPrintProtocol: サポートするプリントプロトコル」
抽出された上記SNMPのMIB情報は、SOAPレスポンス発行処理部815により、図11に示すようなXML形式に変換され、外部のクライアントPCに送信される。
以降、各ネットワーク対応プリンタからレスポンスを受け取った代理サーバ853は、クライアントPCからリクエストがあると、前述の実施形態、図1のプリンタPRと同一の処理を実行する。即ち、図4に示すステップS6乃至S8と同一の処理を実行する。具体的には、代理サーバ853内のサーバモジュールは、代理サーバ853内に記憶した図7に示すデバイス構成情報(プリンタ製造者名、プリンタ機種名、言語名等を含む)を、クライアントからの要求に応じて、クライアントに送信するよう代理サーバ内のOSの一部である送信モジュールを制御して送信処理を行う。
なお、この場合、代理サーバからクライアントPC851に通知されるレスポンスは図11に示すとおり、代理サーバがSNMPによりMIBオブジェクトの形態で取得した全プリンタのデバイス構成情報及び識別情報を、XMLで記述して、図7に示すスキーマに変換した上で、HTTPを利用して一括して情報処理装置の好適な一例であるクライアントPCに送信する。
これにより、例えば、HTTPに対応するウェルノウンポートである80番を利用することにより、SNMPの使用するポートをファイアウォールが許可していない場合でも、SNMPにしか対応していない旧式のプリンタ(legacy printer)をファイアウォール越しにHTTPを用いて把握することも出来る。
該レスポンスを受け取ったクライアントPCは前述の例と同様、代理サーバからのレスポンスに記述された全プリンタのプリンタ名をクライアントPCの表示装置上に、図12に示すようにリスト表示する。
本実施形態では、図12に示した通り、これまで考えられなかった、旧式のSMNP対応ではあるがUPnP対応ではない旧式のプリンタ(図5に示す代理サーバ内のアプリケーション部が、識別情報内に含まれる情報から抽出したABC社の 機種Printer Series 123、及びABC社の 機種Printer Series 222)と、UPnP対応の新式のプリンタが同じ画面にUPnPの管理ソフトウエアでブラウジング可能となっている。
また、レスポンスを受け取ったクライアントは、クライアント内のアプリケーション部1にてデバイスIDを生成し、アプリケーション部1は、入力されたデバイスIDをプラグアンドプレイインストーラが認識可能なデバイス番号の形式に変換する。そして、プラグアンドプレイインストーラは、デバイス番号に基づいて、インストール処理を行うこともできる。これにより、従来から存在するSNMPなどの旧来からあるデバイス管理方式には対応しているが、ネットワークを介したプリンタデバイス構成情報の取得方式(例えばUPnP)に対応していない場合であっても、代理サーバが仲介役を行うので、クライアントPCはネットワークを介したデバイス構成情報管理方式に従ってプリンタを代理サーバを介して、機種名、プリンタメーカ名などを取得するなどして管理できる。
上記の実施形態では、プリンタを画像処理装置とした実施形態を示しているが、画像装置としてはスキャナ、FAX、複写機、およびそれら複合機能を備える画像処理装置であって、それら画像処理装置を制御するソフトウエアをネットワークを介して供給可能な装置であればいずれの場合においても実現可能である。
また、上記の実施形態においては、プリンタの検索時においてSSDPで策定されたプロトコルを採用しているが、この他にSLP(Service Location Protocol)のように、本実施形態の特徴である、オペレーティングシステム名称、およびそのバージョンを検索条件としうる検索プロトコルであれば実現可能である。
さらに、上記の実施形態では、HTTPエンティティの表記方法はSOAPを使用しているが、独自スキーマによる記述によっても実現可能である。
また、上記の実施形態では、ネットワークプリンタ記録装置にドライバが記録されている。デバイスドライバが記憶された記憶領域の好適な一例であるドライバ格納URLには、そのネットワークプリンタ記録装置のURLが設定される例を示しているが、このDriverURLは、ネットワーク上に存在する第3のファイルサーバ1010上に格納されているドライバのURLを示すものであっても実現可能である。
上記実施形態によれば、既存の開発資源に大幅な変更を加えることなく、制御プログラムをコンピュータにインストールする際の煩雑な操作を不要とする仕組みを実現する方策として、コンピュータ内ローカルの既存のプラグアンドプレイに対応するインストーラを活用する仕組みを提供することができる。
さらに、プラグアンドプレイに対応するインストーラを利用する際、該プラグアンドプレイインストーラが、UPnPなどの所定の管理方式にて管理されている情報を利用して自動的にインストールできるための仕組みを提供することができる。
さらに、ネットワークに接続された周辺装置が所定の管理方式に対応していない場合であっても、周辺装置とコンピュータの仲介を行う代替サーバが、該所定の管理方式に対応していない周辺装置の識別情報を把握して該周辺装置の識別情報を該所定の管理方式に対応した形式で送信し、送信された識別情報を、既存のプラグアンドプレイに対応したインストーラに活用させる仕組みを提供することができる。
以下、図13に示すメモリマップを参照して本発明に係る情報処理装置および印刷装置を適用可能なネットワークシステムで読み出し可能なデータ処理プログラムの構成について説明する。
図13は、本発明に係る情報処理装置および印刷装置を適用可能なネットワークシステムで読み出し可能な各種データ処理プログラムを格納する記憶媒体のメモリマップを説明する図である。
なお、特に図示しないが、記憶媒体に記憶されるプログラム群を管理する情報、例えばバージョン情報,作成者等も記憶され、かつ、プログラム読み出し側のOS等に依存する情報、例えばプログラムを識別表示するアイコン等も記憶される場合もある。
さらに、各種プログラムに従属するデータも上記ディレクトリに管理されている。また、各種プログラムをコンピュータにインストールするためのプログラムや、インストールするプログラムが圧縮されている場合に、解凍するプログラム等も記憶される場合もある。
本実施形態における図4に示す機能が外部からインストールされるプログラムによって、ホストコンピュータにより遂行されていてもよい。そして、その場合、CD−ROMやフラッシュメモリやFD等の記憶媒体により、あるいはネットワークを介して外部の記憶媒体から、プログラムを含む情報群を出力装置に供給される場合でも本発明は適用されるものである。
以上のように、前述した実施形態の機能を実現するソフトウエアのプログラムコードを記録した記憶媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ(またはCPUやMPU)が記憶媒体に格納されたプログラムコードを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。
この場合、記憶媒体から読み出されたプログラムコード自体が本発明の新規な機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
プログラムコードを供給するための記憶媒体としては、例えば、フロッピー(登録商標)ディスク,ハードディスク,光ディスク,光磁気ディスク,CD−ROM,CD−R,磁気テープ,不揮発性のメモリカード,ROM,EEPROM等を用いることができる。
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているOS(オペレーティングシステム)等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
また、ネットワーク対応型デバイスを使用するにあたり、該デバイスを制御するためのドライバソフトウエアを、クライアントデバイス内の記録装置内に予め記録しておく必要、あるいは利用者が外部記録メディアの形態で持ち歩く必要がなくなった。
また、クライアントがネットワーク対応型デバイスを使用するにあたり、クライアントがジョブ要求ネットワーク上に新規に利用可能な状態となったネットワーク対応型デバイスの発見が可能となる。
さらに、周辺装置の既存のネットワーク管理プロトコル、例えば、UPnPの,探索要求における応答の所定の拡張領域に周辺装置の識別情報を挿入し、付加したので、既存の周辺装置管理システムを大幅に変更することなく、周辺装置の識別情報をやり取りする仕組みを提供することができ、ひいては、プラグアンドプレイなどに該周辺装置の情報を活用することが出来る。
なお、上記実施形態に示した各構成を、適宜有効に組み合わせることは、本発明の適用範囲である。
これにより、本実施形態によれば、ネットワーク上の周辺装置を管理するための情報を容易に把握して活用することができる。
また、インストール対象となるコンピュータ内のプラグアンドプレイインストーラが、ネットワーク上の周辺装置を認識してインストールを行うことができ、周辺装置をネットワークに接続するだけで、クライアント装置におけるインストール完了までのトータルなインストール処理を、煩雑な操作無しに行うことができる。
さらに、周辺装置の識別情報の管理を行う代理サーバを設けるので、複数のネットワーク上の周辺装置を管理する方式がネットワーク上に並存している場合であっても、特定の管理方式に対応した管理システムから、該特定の管理方式に対応していないネットワーク上の周辺装置を認識できる。
さらに、ユーザ又は管理者が、ネットワークを介して接続された周辺装置を制御するための制御プログラムをコンピュータにインストールする際に、既存の開発資源に大幅な変更を加えることなく、煩雑な操作を不要とするための仕組みを提供することができる。
また、既存の開発資源に大幅な変更を加えることなく、制御プログラムをコンピュータにインストールする際の煩雑な操作を不要とする仕組みを実現する方策として、コンピュータ内ローカルの既存のプラグアンドプレイに対応するインストーラを活用する仕組みを提供することができる。
さらに、プラグアンドプレイに対応するインストーラを利用する際、該プラグアンドプレイインストーラが、UPnPなどの所定の管理方式にて管理されている情報を利用して自動的にインストールできるための仕組みを提供することができる。
さらに、ネットワークに接続された周辺装置が所定の管理方式に対応していない場合であっても、周辺装置とコンピュータの仲介を行う代替サーバが、該所定の管理方式に対応していない周辺装置の識別情報を把握して該周辺装置の識別情報を該所定の管理方式に対応した形式で送信し、送信された識別情報を、既存のプラグアンドプレイに対応したインストーラに活用させる仕組みを提供することができる。