JP5022748B2 - クライアント装置及び情報処理方法 - Google Patents

Description

本発明は、クライアント装置及び情報処理方法に関する。

近年、予めサーバ（サーバ装置）にインストールされているデバイスドライバをダウンロードしてインストールを行い、クライアント（クライアント装置）で利用可能にする「ダウンロードインストール」技術が開発されている。

デバイスドライバの中でも、プリンタドライバを例に取ると、Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムにおけるポイントアンドプリント（Ｐｏｉｎｔ＆Ｐｒｉｎｔ）がその一例として良く知られている。

例えば、クライアントでユーザがポイントアンドプリントの指示を行うと、クライアントはポイントアンドプリントの際に、リモートプロシージャコール（ＲＰＣ）の「ｔｒｕｅ ｃｏｎｎｅｃｔ」プリンタ接続を作成する。

ＲＰＣ接続が作成されると、プリントサーバからクライアントへプリンタドライバと、プリンタとの設定がダウンロードされる。更に、クライアントはプリントサーバから自動的にモジュールやデバイス設定の更新を受け取ることができる。

プリンタドライバのモジュールやデバイス設定が更新されると、クライアントは新しい設定を非同期的に受け取り、そのドライバを用いて印刷処理を実行する。

一方、あるベースとなるプログラムに対して付加機能を自由に着脱することができる「プラグイン」と呼ばれる仕組みが広く知られている。

このようなプラグインの仕組みは、一般的なアプリケーションソフトばかりでなく、デバイスドライバであるプリンタドライバにも応用され、開発が行われている。

プリンタドライバは、オペレーティングシステム（ＯＳ）に組み込まれた印刷サービスの制御下で動作するため、プリンタドライバも印刷サービスに対する一種のプラグインとみなすことができる。

しかしながら、このようなインストール済みのプリンタドライバに対して、更にプラグインとしてプログラムファイルやデータファイル等のモジュールを追加したり、削除したりする方法も研究されている。

特許文献１では、これらプリンタドライバの支配下のプラグインモジュールがポイントアンドプリントのようなＯＳ支配下のインストールの系でも正しくインストールするシステムについての提案がなされている。

ところで、Ｗｉｎｄｏｗｓ（登録商標） Ｖｉｓｔａでは、従来のポイントアンドプリントを発展させ、セキュリティを向上させたパッケージポイントアンドプリント（Ｐａｃｋａｇｅ Ｐｏｉｎｔ＆Ｐｒｉｎｔ）というインストール方法が導入されている。

パッケージポイントアンドプリントとは「パッケージ」と呼ばれる予めＯＳに登録されたインストールセットを、クライアントに一旦ダウンロードしてからセットアップするインストール方法である。

パッケージポイントアンドプリントでは、インストール後のプリンタドライバでなく、インストール前のインストールセットであるパッケージを使ってインストールが行われる。

インストール前のインストールセットは電子的に署名されているため、パッケージポイントアンドプリントは、従来のポイントアンドプリントよりも信頼性が高いとされている。

特開２００５−２０８８９５号公報

しかしながら、パッケージポイントアンドプリントでは、予め署名された未インストールのパッケージを使ってインストールが行われる。
そのため、サーバのドライバにプラグインモジュールが付加されていた場合、プラグインモジュールがダウンロードインストールされないという問題がある。

更に、従来のポイントアンドプリントで有効だったクライアントへのプログラムの自動更新機能は、パッケージポイントアンドプリントではセキュリティの強化を理由に無効化されている。
したがって、特許文献１で提案されている方法でサーバと、クライアントとのモジュール構成の整合性をとることもできない。

本発明はこのような問題点に鑑みなされたもので、サーバ装置とクライアント装置との間のモジュール構成の差異を解消することを目的とする。

そこで、本発明は、共有設定されたプリンタを管理するサーバ装置と、ネットワークを介して通信可能なクライアント装置であって、前記共有設定されたプリンタについてのパッケージポイントアンドプリントの処理の完了を示す当該クライアント装置内のスプーラからの通知に応じて、前記パッケージポイントアンドプリントの処理により当該クライアント装置にインストールされているデバイスドライバに関するモジュール構成情報を収集する収集手段と、前記収集手段が収集した前記モジュール構成情報を前記サーバ装置に送信するモジュール構成情報送信手段と、当該クライアント装置にインストールされているデバイスドライバに関するモジュール構成と、前記サーバ装置にインストールされているデバイスドライバに関するモジュール構成と、の差異を補完する補完データを前記サーバ装置より受信する補完データ受信手段と、前記補完データ受信手段が受信した補完データに基づき、前記デバイスドライバに関するモジュール構成を補完する補完手段と、を有することを特徴とする。

本発明によれば、サーバ装置とクライアント装置との間のモジュール構成の差異を解消することができる。

以下、本発明の実施形態について図面に基づいて説明する。

＜実施形態１＞
図１は、プリントサーバシステムの構成の一例を示す図である。
図１に示されるように、プリントサーバシステムは、プリントサーバ１０と、クライアントコンピュータ２０と、プリンタ装置３０と、を含む。また、各装置は、ネットワークを介して通信可能なように接続されている。

プリントサーバ１０は、クライアントコンピュータ２０から入力された印刷データを仲介し、プリンタ装置３０に出力して印刷を実行させる。
このように、プリントサーバ１０には印刷機能を備えたプログラム（アプリケーション又はサービス）が少なくとも一つ組み込まれており、同時に、アプリケーションからプリンタ装置３０への印刷を仲介するプリンタドライバも組み込まれている。また、クライアントコンピュータ２０には、通常、少なくとも一つの印刷機能を備えた、プリントサーバ１０と同様のプログラムが組み込まれている。

ここで、クライアントコンピュータ２０を利用するユーザがプリンタ装置３０を使用して印刷を実行させるためには、プリントサーバ１０に組み込まれているプリンタドライバと同じプリンタドライバをクライアントコンピュータ２０に組み込まなければならない。

何故ならば、クライアントコンピュータ２０のアプリケーションによって生成される印刷データは、プリンタ装置３０に入力される前にプリントサーバ１０上のプリンタドライバによって仲介される必要があるからである。更にプリントサーバ１０のプリンタドライバに印刷データを仲介させるためには、クライアントコンピュータ２０上で同じプリンタドライバに印刷データを仲介させる必要があるからである。

従って、プリントサーバシステムでは、クライアントコンピュータ２０に、プリントサーバ１０にインストールされているものと同じプリンタドライバをインストールしなければならない。

しかしながら、このようなクライアントコンピュータ２０におけるインストール作業は、そのクライアントコンピュータ２０を利用するユーザにとって負担になってしまうという問題がある。
このような問題を解決する方法として、上述したポイントアンドプリントが知られている。

以下、このポイントアンドプリンタによるインストールの流れを図２及び図３を参照して説明する。

図２Ａは、プリントサーバ１０のハードウェア構成の一例を示すブロック図である。
図２Ａに示されるように、プリントサーバ１０は、ハードウェア構成として、ＣＰＵ１１と、ＲＡＭ１２と、ＨＤ１３と、ネットワークＩ／Ｆ１４と、を含む。また、各構成は、バス１５を介して互いに接続されている。

ＣＰＵ１１は、ＲＡＭ１２にロードされたプログラムに従って、本実施形態のプリントサーバ１０の機能に係る処理等を実行する。ＲＡＭ１２は、各種プログラムを記憶するメモリエリアと、ＣＰＵ１１による処理の実行時にワークエリアとして私用され、各種データを一時的に記憶（保存）するメモリエリアと、を有している。

ハードディスク（ＨＤ）１３には、予めＯＳや各種プログラムがインストールされている。ＨＤ１３にインストールされているプログラムは、プリントサーバ１０の立ち上げ時、或は起動が指示されたときに、ＲＡＭ１２にロードされてＣＰＵ１１の制御の下に実行される。

ネットワークＩ／Ｆ１４は、プリントサーバ１０をネットワークと接続するためのインターフェースユニットである。なお、プリントサーバ１０は、後述するクライアントコンピュータ２０のように、表示部や入力部をハードウェア構成として含んでもよい。

図２Ｂは、クライアントコンピュータ２０のハードウェア構成の一例を示すブロック図である。
図２Ｂに示されるように、クライアントコンピュータ２０は、ハードウェ構成として、ＣＰＵ２１と、ＲＡＭ２２と、ＨＤ２３と、表示部２４と、入力部２５と、ネットワークＩ／Ｆ２６と、を含む。また、各構成は、バス２７を介して互いに接続されている。

ＣＰＵ２１は、ＲＡＭ２２にロードされたプログラムに従って、本実施形態のクライアントコンピュータ２０の機能に係る処理等を実行する。ＲＡＭ２２は、各種プログラムを記憶するメモリエリアと、ＣＰＵ２１による処理の実行時にワークエリアとして私用され、各種データを一時的に記憶（保存）するメモリエリアと、を有している。

ハードディスク（ＨＤ）２３には、予めＯＳや各種プログラムがインストールされている。ＨＤ２３にインストールされているプログラムは、クライアントコンピュータ２０の立ち上げ時、或は起動が指示されたときに、ＲＡＭ２２にロードされてＣＰＵ２１の制御の下に実行される。

表示部２４は、例えばＣＲＴや液晶等のディスプレイであり、ユーザインターフェースを表示する。
入力部２５は、キーボードやマウス等のポインティングデバイスを含み、ユーザの操作に応じてデータを入力する。

ネットワークＩ／Ｆ２６は、クライアントコンピュータ２０をネットワークと接続するためのインターフェースユニットである。

図３は、ポイントアンドプリントにおけるプリンタドライバのインストールに関連するモジュールを説明するための機能ブロック図である。

プリントサーバ１０上の印刷サービス１００は、プリントサーバ１０のＯＳ上で印刷処理や、プリンタドライバのインストールを制御するサービスプログラムである。

Ｗｉｎｄｏｗｓ（登録商標） ＯＳにおいてはスプーラー（Ｓｐｏｏｌｅｒ）サービスがこれに相当する。スプーラーサービスは、プリンタへの印刷データの送信や、プリンタドライバのインストール、ポイントアンドプリント等、様々な機能を利用する手段を提供する。

より具体的に説明すると、スプーラーは、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）という関数インターフェースを公開することにより、プログラム等が上述のような機能を実現する手段を提供している。つまり、アプリケーションやプリンタドライバはこのＡＰＩを通じて処理を実行する。
本実施形態における印刷サービス１００も上述したスプーラーと同様な特徴（機能）を備えているものとする。

ドライバ構成情報１０１は、プリントサーバ１０におけるプリンタドライバ１０２のドライバ構成情報（モジュール構成情報）であり、ＯＳの共有記憶領域に格納されている。ドライバ構成情報１０１により、ＯＳの一部として実装される印刷サービス１００及びプリンタドライバ１０２は、プラグインの着脱を認識することができる。
印刷キュー１０３は、印刷データをプリンタ装置３０へ出力する前に一旦、貯める働きをする仮想的なキューである。

ランゲージモニター１０４は、印刷サービス１００から送出された印刷データを解析しつつ、プリンタドライバ１０２（又はプリンタ装置３０）へデータを送出したり、プログラムからのプリンタ構成情報やプリントサーバ構成情報の取得要求に応答したりする。
なお、図３において、ランゲージモニター１０４をプリンタドライバ１０２と区別して記載しているが、印刷サービス１００からはあくまでプリンタドライバ１０２の一部として見なされる。

クライアントコンピュータ２０上の印刷サービス２００の働きは、プリントサーバ１０の印刷サービス１００と同様に、クライアントコンピュータ２０のＯＳ上で印刷処理や、プリンタドライバのインストールを制御している。

なお、ポイントアンドプリントの実行前には、プリンタドライバ２０２と、そのドライバ構成情報２０１、印刷キュー２０３は、クライアントコンピュータ２０上に存在していない。

ポイントアンドプリントによって、これらをクライアントコンピュータ２０に組み込むのが目的である。

なお、ランゲージモニター１０４は、その位置付け上、ポイントアンドプリントの対象外であるため、クライアントコンピュータ２０にはダウンロードされない。

図４は、ポイントアンドプリントによるインストールの流れを説明するための図である。
クライアントコンピュータ２０を利用するユーザが、クライアントコンピュータ２０の印刷サービス２００を通じて共有プリンタに接続し、ポイントアンドプリントの要求を出す（Ｓ１０）。

プリントサーバ１０の印刷サービス１００は、この要求に応じてドライバ構成情報１０１を参照してダウンロードすべきインストールセットを決定する（Ｓ１１）。
次に、印刷サービス１００は、クライアントコンピュータ２０の印刷サービス２００と連携しながら、プリントサーバ１０のプリンタドライバ１０２のインストールセットをクライアントコンピュータ２０にコピーする（Ｓ１２）。

次に、クライアントコンピュータ２０の印刷サービス２００は、このコピーされたインストールセットに基づいてプリンタドライバ２０２をクライアントコンピュータ２０のＯＳに登録する。同時に印刷サービス２００は、ドライバ構成情報２０１を登録、更に印刷キュー２０３を作成する（Ｓ１３）。
この結果、クライアントコンピュータ２０のユーザは、プリントサーバ１０を介してプリンタ装置３０に対して印刷を実行させることができる。

図５は、プリントサーバ１０にインストールされたプリンタドライバ１０２のプラグイン１０５を説明するための図である。
プラグイン１０５は、例えばＤＬＬ（Ｄｙｎａｍｉｃ Ｌｉｎｋ Ｌｉｂｒａｒｙ）等のプログラムファイルを含むファイル群である。

プラグイン１０５は、プラグインインストーラ１０６によって追加インストールされることによって、プリンタドライバ１０２の共通拡張インターフェースを用いて通信可能となり、機能拡張を実現する。

即ち、プラグインインストーラ１０６は、プリンタドライバ１０２がインストール済みの状態で実行可能なプログラムである。また、プラグイン１０５は、プリンタドライバ１０２の一部として動作する。

なお、プラグイン１０５による機能拡張のより具体的な例としては、印刷ジョブの履歴を収集したり、印刷データに背景画像を付加したりする機能等が挙げられる。

プラグインインストーラ１０６は、追加インストールの際、ドライバ構成情報１０１にプラグインの情報を追加する。これにより、印刷サービス１００及びプリンタドライバ１０２は、プラグイン１０５がプリンタドライバ１０２の一部であると認識させられる。

したがって、上述したポイントアンドプリントの処理によって、プリンタドライバ１０２と共にその一部であるプラグイン１０５は、それぞれプリンタドライバ２０２、プラグイン２０５としてクライアントコンピュータ２０にダウンロードインストールされる。

その結果、プリントサーバ１０と、クライアントコンピュータ２０とでそれぞれプリンタドライバは同一のモジュール構成となる。よって、後から組み込まれたプラグイン１０５（プラグインモジュール）による機能をクライアントコンピュータ２０のユーザが利用することもできる。

なお、ランゲージモニター１０４は上述したように、例外的にクライアントコンピュータ２０にはダウンロードされない。その代わり、ランゲージモニター１０４はプリントサーバ１０に留まったまま、クライアントコンピュータ２０のプリンタドライバ２０２に対してもプリントサーバ１０上のプリンタドライバ１０２と同様の役割を果たす。

より具体的には、例えばクライアントコンピュータ２０上のプリンタドライバ２０２等が印刷サービス２００に対してランゲージモニター１０４の機能を使用するＡＰＩを呼び出す。すると、印刷サービス２００は、プリントサーバ１０上の印刷サービス１００を通じてランゲージモニター１０４を呼び出す。

図６は、パッケージポイントアンドプリントによるインストールに関連するモジュールを説明するための機能ブロック図である。
プリントサーバ１０上のパッケージ１０７は、プリンタドライバ１０２とその一部であるランゲージモニター１０４をインストールするために使用され、ＯＳに登録されたファイル郡である。

パッケージ１０７は、ＣＤ−ＲＯＭ等のメディアやインターネットを通じて配布されるドライバのインストールセットを使用してインストールが行われた際、バックアップとしてＯＳ内に保存され、登録される。

パッケージを利用する利点は、例えばドライバを誤って消してしまったとき等にもう一度インストール用メディアを探さなくても直ちにインストールができること等がある。
なお、プラグイン１０５は、プラグインインストーラ１０６によってインストールされるものであるため、パッケージ１０７の中には含まれていない。

一方、クライアントコンピュータ２０は、パッケージポイントアンドプリントが行われる前は、プリンタドライバ２０２、印刷キュー２０３、パッケージ２０７は存在しない。

上述したポイントアンドプリントと、パッケージポイントアンドプリントとの違いはクライアントコンピュータ２０へのドライバのインストールにパッケージが使用されることである。
パッケージポイントアンドプリントの処理の流れについては次の図７を用いて説明する。

図７は、パッケージポイントアンドプリントによるインストールの流れを示すための図である。
ポイントアンドプリントの場合と同様、クライアントコンピュータ２０を利用するユーザが、クライアントコンピュータ２０の印刷サービス２００を通じて共有プリンタに接続し、要求を出す（Ｓ２０）。

プリントサーバ１０の印刷サービス１００は、この要求に応じてクライアントコンピュータ２０との間でパッケージポイントアンドプリントが可能か否かを判定する（Ｓ２１）。

可能と判定した場合、プリントサーバ１０の印刷サービス１００は、クライアントコンピュータ２０の印刷サービス２００と連携しながら、プリントサーバ１０に登録されているパッケージ１０７をクライアントコンピュータ２０にコピーする（Ｓ２２）。

次に、印刷サービス２００は、コピーされたパッケージ２０７をクライアントコンピュータ２０のＯＳにパッケージとして登録する（Ｓ２３）。
最後に、印刷サービス２００は、パッケージ２０７からプリンタドライバ２０２をインストールする（Ｓ２４）。

このとき、パッケージに含まれているランゲージモニターは上述した通りクライアントにはインストールされず、プリントサーバ１０に留まったままその機能を果たす。
こうして、クライアントコンピュータ２０のユーザは、プリントサーバ１０に登録されているプリンタドライバ１０２を利用し、印刷等を行うことができるようになる。

しかしながら、明白な問題として、パッケージ内にはプリントサーバ１０に後からインストールされたプラグイン１０５が含まれていない。そのため、クライアントコンピュータ２０のユーザは、プラグイン１０５によって付加された機能を利用することができない。

また、パッケージポイントアンドプリントではセキュリティの理由によりプリントサーバ１０からのモジュールの更新を受けることができないため、結果としてプラグイン１０５がクライアントコンピュータ２０にダウンロードされることもない。

プラグイン１０５をクラインアントにインストールする方法として、プラグインインストーラ１０６がプラグイン１０５をインストールする際、同時にパッケージ１０７へプラグイン１０５を予め組み入れておく方法が考えられる。

しかし、パッケージは電子的に署名されているため、中に含まれるファイル群の構成が代わったり、ファイルが書き換えられたりするとその改ざんがＯＳによって検知され、結果としてパッケージポイントアンドプリントも行われなくなる。

以下ではこのような課題を解決するための処理、又は方法について具体的に述べる。

図８は、プリントサーバシステムにおけるモジュールのインストール方法に係る処理の流れを示すフローチャートである。
図８に示す処理は、図６及び図７で示したパッケージポイントアンドプリントにより、プリンタドライバ２０２が、プラグイン１０５なしでクライアントコンピュータ２０にインストールされた状態から開始される。

より具体的には、クライアントコンピュータ２０上の印刷サービス２００は、インストールが完了すると、ポイントアンドプリント又はパッケージポイントアンドプリントが完了したことを示す通知を、ＡＰＩを通じてプリンタドライバ２０２に対して送信する。

プリンタドライバ２０２はこの通知を受け取ることにより、以下に示す処理を開始する。
ステップＳ１００において、プリンタドライバ２０２は、プリントサーバ１０とモジュール構成の同期を取るために必要なクライアント側の情報であるクライアントデバイスドライバ構成情報（クライアントコンピュータ２０のドライバ構成情報２０１）を収集する。なお、ステップＳ１００の処理の詳細は、後述する図１０を用いて説明する。

（モジュール構成情報送信）
次に、ステップＳ２００において、プリンタドライバ２０２は、収集したクライアントデバイスドライバ構成情報を、印刷サービス等を介してプリントサーバ１０上のランゲージモニター１０４に対して送信する。
なお、ステップＳ２００において送信されるクライアントデバイスドライバ構成情報のデータ形式の詳細は、後述する図１１に示す。

（モジュール構成情報受信、差異の検出）
次に、ステップＳ３００において、ランゲージモニター１０４（又はプリンタドライバ１０２）は、受信したクライアントデバイスドライバ構成情報に基づき、プリントサーバ１０とクライアントコンピュータ２０とのモジュール構成を比較する。なお、ステップＳ３００の処理の詳細は、後述する図１２を用いて説明する。

（補完データ生成）
次に、ステップＳ４００において、ランゲージモニター１０４（又はプリンタドライバ１０２）は、ステップＳ３００において比較した結果に基づきモジュール構成の差異を補完する補完データを生成する。なお、ステップＳ４００において生成された補完データのデータ形式の詳細は、後述する図１３に示す。

（補完データ送信）
次に、ステップＳ５００において、ランゲージモニター１０４（又はプリンタドライバ１０２）は、生成した補完データを、印刷サービス等を介してクライアントコンピュータ２０のプリンタドライバ２０２に対して返却（又は送信）する。

（補完データ受信、モジュール構成の補完）
最後に、ステップＳ６００において、プリンタドライバ２０２は、返却された補完データに基づき補完セットアップ（モジュール構成の補完）を行う。なお、ステップＳ６００の処理の詳細は、後述する図１４に示す。

なお、ステップＳ２００と、Ｓ５００とにおけるクライアントコンピュータ２０のプリンタドライバ２０２と、ランゲージモニター１０４との間のデータの送受信方法について述べる。

ランゲージモニター１０４は、上述したように、プログラムからのプリンタ構成情報やプリントサーバ構成情報の取得要求に応答する制御を行う。プログラムは印刷サービス１００が公開するＡＰＩを通じて印刷サービス１００が提供する機能を利用することができる。

なお、例えばクライアントコンピュータ２０上のプリンタドライバ２０２等が印刷サービス２００に対してランゲージモニター１０４の機能を使用するＡＰＩを呼び出す。すると、印刷サービス２００は、プリントサーバ１０上の印刷サービス１００を通じてランゲージモニター１０４を呼び出す。

ランゲージモニター１０４のＡＰＩによって提供される機能の一つに、ランゲージモニター１０４に対して問い合わせの情報を送信し、この問い合わせの情報に対する応答の情報を受信する機能がある。

問い合わせる情報の典型的な例としては、両面ユニットやフィニッシャーの着脱状況等のプリンタの構成情報がある。また、他の例としては、プリンタドライバが保持する設定情報等もある。

本実施形態においては、自身がプリンタドライバでもあるクライアントコンピュータ２０のプリンタドライバ２０２が、モジュール構成の同期を取るために、この問い合わせＡＰＩの機能を使って、（印刷サービスを介して）情報の送受信を行っている。

ランゲージモニター１０４のＡＰＩを使う利点は、通信のプロトコルやタイミング等の通信に特化した処理を全てクライアントコンピュータ２０と、プリントサーバ１０とのそれぞれの印刷サービスに任せられるため処理を簡素化できる所にある。

もちろん、ＨＴＴＰや独自の通信プロトコルを用いてプリントサーバ１０上の通信サービスと通信を行うことでも同様の目的は達成することができる。

次に、プリントサーバ１０と、クライアントコンピュータ２０とのモジュール構成の差異について説明する。
図９Ａ、図９Ｂ、図９Ｃは、モジュール間（モジュール構成）の差異を表す図である。

図９Ａは、あるモジュールがサーバ側（プリントサーバ１０側）には存在しているが、クライアント側（クライアントコンピュータ２０側）には存在していない場合の一例を示す図である。
図９Ａでは、より具体的には、クライアント側には、ＤｒｖＰｌｕｇＩｎ１．ｄｌｌと、ＤｒｖＰｌｕｇＩｎ２．ｄｌｌという２つのファイルが不足している状態を例示している。

このような状態は、サーバ側に後から追加インストールされたプラグインがパッケージポイントアンドプリントではクライアント側にはダウンロードインストールされないことで生じるものであり、解消されるべき差異である。

次に、図９Ｂは、あるサーバ側のモジュールの方が、クライアント側のモジュールよりも更新時刻が新しい場合の一例を示す図である。
図９Ｂでは、より具体的には、ＤｒｖＢａｓｅＣ．ｄｌｌと、ＤｒｖＰｌｕｇＩｎ１．ｄｌｌという２つのファイルが、それぞれサーバ側にあるファイルの方がクライアント側にあるファイルより更新時刻が新しい状態を例示している。

このような状態は、クライアント側にダウンロードインストールが行われた後に、サーバ側のドライバのモジュールの一部が更新された場合等に生じるものであり、これも解消されるべき差異である。

次に、図９Ｃは、あるクライアント側のあるモジュールがサーバ側にはもはや存在していない場合の一例を示す図である。
図９Ｃでは、より具体的には、ＤｒｖＢａｓｅＣ．ｄｌｌというファイルがサーバ側にはもはや存在していない状態を例示している。

このような状態は、クライアント側にダウンロードインストールが行われた後に、サーバ側のプラグインモジュールがアンインストールされ、外された場合等に生じるものであり、これも解消されるべき差異である。

図１０は、図８に示したステップＳ１００のクライアントデバイスドライバ構成情報を収集する処理の詳細を説明するためのフローチャートである。

Ｓ１０１において、プリンタドライバ２０２は、クライアントコンピュータ２０のアーキテクチャ情報を取得する。ここで、アーキテクチャ情報とは、例えばＩｎｔｅｌ（登録商標） ３２ｂｉｔやＡＭＤ（登録商標） ６４ｂｉｔといったハードウェアの種類に関する情報である。

サーバ側とクライアント側とが異なるアーキテクチャである場合、ポイントアンドプリントの接続要求があると、サーバ側の印刷サービス１００は、クライアント側に適合したアーキテクチャのプリンタドライバ又はそのパッケージをコピーする。

何故ならＤＬＬ等のプログラムモジュールは、通常はＯＳが動作するハードウェアのアーキテクチャ間での互換性がないためである。
したがって、ＤＬＬのようなプログラムモジュールであるプラグインも、ダウンロードされ、その一部となるクライアント側のプリンタドライバ２０２と同じアーキテクチャである必要がある。そのため、プリンタドライバ２０２は、サーバ側に送信する情報の一つとしてアーキテクチャ情報を収集する。

次に、Ｓ１０２において、プリンタドライバ２０２は、ドライバ構成情報２０１にアクセスし、モジュールの名称と、更新時刻との一覧を取得する。なお、プリンタドライバ２０２は、印刷サービス２００の提供するＡＰＩを通じてドライバ構成情報２０１を取得することができる。

図１０に示す処理によって、クライアントのプリンタドライバ２０２を構成するモジュール名称の一覧を得ることができる。また、更に各々のモジュールの更新時刻をＯＳのＡＰＩ等を用いて得ることができる。

図１１は、クライアントデバイスドライバ構成情報のデータ形式の一例を示す図である。
ステップＳ１０１と、ステップＳ１０２とで得た情報は、ランゲージモニター１０４へ問い合わせる情報としてプリンタドライバ２０２によって一つのデータ形式としてまとめられる。データ形式は、ランゲージモニター１０４のＡＰＩによって定められる。図１１の例では、情報はＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）形式でデータ内に記述されている。

より具体的に説明すると、Ｑｕｅｒｙ要素のＳｃｈｅｍａ属性に書かれている文字列は、ランゲージモニター１０４に対して問い合わせる情報を表している。
図１１の例では、
ＬａｃｋｉｎｇＭｏｄｕｌｅ（クライアント側に不足している不足モジュール）、
ＵｐｄａｔｅｄＭｏｄｕｌｅ（サーバ側が新しいものに更新されている更新モジュール）、
ＳｕｒｐｌｕｓＭｏｄｕｌｅ（サーバ側で使用されなくなった余剰モジュール）
の３つが記述されている。

また、Ｈｉｎｔ要素は、ランゲージモニター１０４が応答を行うために使用する情報をまとめており、ｎａｍｅ属性は、情報の項目名を、ｖａｌｕｅ属性は、情報に関する値を表している。

図１１の例では、Ａｒｃｈｉｔｅｃｔｕｒｅ（アーキテクチャ情報）という項目に対して３２ｂｉｔが文字列値として記述されている。
また、図１１の例では、Ｍｏｄｕｌｅｓ（モジュール）という項目に対して「，」（カンマ）で区切られたモジュール名称の一覧が文字列値として記述されている。
なお、各々の名称に続く括弧内の数値はそのモジュールの最終更新時刻を表現したものである。

プリンタドライバ２０２は、図１１の例に示すようなＸＭＬデータをランゲージモニター１０４へ問い合わせるためのＡＰＩに対する入力とする。

図１２は、図８に示したステップＳ３００のモジュール構成を比較する処理の詳細を説明したフローチャートである。

ランゲージモニター１０４は、ステップＳ２００において、印刷サービス１００から問い合わせのＡＰＩを通じて呼び出され、クライアントデバイスドライバ構成情報のデータを受信すると、以下の処理を開始する。
ステップＳ３０１において、ランゲージモニター１０４は、クライアントデバイスドライバ構成情報に含まれるアーキテクチャ情報に適合するドライバ構成情報１０１を取得する。

プリンタドライバは、上述したように、サーバ側とクライアント側とが異なるアーキテクチャであったとしてもポイントアンドプリントが可能である。そのため、複数のアーキテクチャのプリンタドライバが装置に登録（又はインストール）されている場合がある。このような場合、クライアント側のアーキテクチャに適合するプリンタドライバのモジュール構成と同期を取る必要がある。したがって、ランゲージモニター１０４は、クライアント側のアーキテクチャに適合するドライバ構成情報１０１を取得しなければならない。

次に、ステップＳ３０２において、ランゲージモニター１０４は、クライアントデバイスドライバ構成情報に含まれるモジュール構成の全モジュールに関してステップＳ３０３からＳ３０６までの処理を繰り返す。

ステップＳ３０３において、ランゲージモニター１０４は、クライアントコンピュータ２０の各モジュールの名称がプリントサーバ１０のドライバ構成情報１０１のモジュール名称の一覧に含まれているか否かを判定する。

ここでもし含まれていなければ、ランゲージモニター１０４は、このモジュールはプリントサーバ１０にはもはや存在しない余剰なモジュール（余剰モジュール）と判定し、Ｓ３０４へ進む。一方、含まれていれば、ランゲージモニター１０４は、Ｓ３０５へ進む。

ステップＳ３０４において、ランゲージモニター１０４は、該当するモジュールの名称を余剰モジュールとして記憶し、再びステップＳ３０２へ戻る。余剰モジュールは、プラグインがインストール後に不要となったためにアンインストールされた場合等に出現するモジュールである。

ステップＳ３０５において、ランゲージモニター１０４は、クライアントコンピュータ２０の各モジュール更新時刻と、プリントサーバ１０の各モジュール更新時刻とを比較する。プリントサーバ１０のモジュールの更新時刻の方がクライアントコンピュータ２０の対応するモジュールの更新時刻より新しい場合、ランゲージモニター１０４は、プリントサーバ１０の前記モジュールを更新モジュールと判定し、ステップＳ３０６へ進む。一方、そうでなければ、ランゲージモニター１０４は、Ｓ３０２へ戻る。

ステップＳ３０６において、ランゲージモニター１０４は、該当するモジュールの名称を更新モジュールとして記憶し、再びステップＳ３０２へ戻る。更新モジュールは、プラグインの更新がサーバ側で行われた場合等に出現するモジュールである。

以上の処理を繰り返し、全てのクライアントのモジュールについて処理が終わった場合、ランゲージモニター１０４は、ステップＳ３０７に進む。

ステップＳ３０７において、ランゲージモニター１０４は、クライアント側の構成に含まれていないサーバ側のモジュールを、クライアントに不足している不足モジュールとして記憶する。不足モジュールは、パッケージポイントアンドプリントでダウンロードインストールを行った際にプラグインがダウンロードされない場合等に出現するモジュールである。

上述した処理において記憶された余剰モジュール、更新モジュール、不足モジュールの各モジュールのリストはステップＳ４００における補完データの生成の際に利用される。

図１３は、補完データのデータ形式の一例を示す図である。
補完データのデータ形式も、ランゲージモニター１０４のＡＰＩによって定められる。図１３の例では、情報はＸＭＬ形式でデータ内に記述されている。

より具体的に説明すると、Ｑｕｅｒｙ要素下のＳｃｈｅｍａ要素のｎａｍｅ属性は問い合わせに使用した情報を表しており、その中には返却された情報のデータが格納されている。

ＬａｃｋｉｎｇＭｏｄｕｌｅ（不足モジュール）と、ＵｐｄａｔｅｄＭｏｄｕｌｅ（更新モジュール）とは、それぞれバイナリ形式のデータが格納されており、ＳｕｒｐｌｕｓＭｏｄｕｌｅ（余剰モジュール）は文字列形式のデータが格納されている。

ここで、ＬａｃｋｉｎｇＭｏｄｕｌｅ（不足モジュール）と、ＵｐｄａｔｅｄＭｏｄｕｌｅ（更新モジュール）とのバイナリデータは、各々のファイル群を一つの書庫としてまとめたＺＩＰアーカイブを表現したエンコード文字列である。

また、ＳｕｒｐｌｕｓＭｏｄｕｌｅ（余剰モジュール）の文字列形式のデータは、プリントサーバ１０において既に使われなくなったモジュール名称の一覧を「，」（カンマ）区切りで表現されている。

図１４は、図８に示したステップＳ６００の補完データに基づき補完セットアップを行う処理の詳細を説明したフローチャートである。

クライアントコンピュータ２０上のプリンタドライバ２０２は、ステップＳ５００において、図１３に例示した補完データを、印刷サービス２００を通じてランゲージモニター１０４から受信すると、以下に示す処理を開始する。

ステップＳ６０１において、プリンタドライバ２０２は、補完データに含まれている不足モジュールと、更新モジュールとのファイル群がまとめられたＺＩＰアーカイブのエンコード文字列を解読する。

文字列のエンコード形式はｂａｓｅ６４エンコード等一般的なものであるため、その解読の方法も標準的な手続きに基づき行われる。
次に、ステップＳ６０２において、プリンタドライバ２０２は、前記ＺＩＰアーカイブに含まれるデータをファイルとして展開し、ドライバのインストールディレクトリにコピーする。

このとき、更新モジュールのファイル群は既にクライアントコンピュータ２０のインストールディレクトリに存在しているが、プリントサーバ１０に合わせて更新することが目的なので、プリンタドライバ２０２は、上書きでコピーを行う。

不足モジュールは、クライアントコンピュータ２０に存在しないので、上書きは発生せず、そのままコピーされる。
次に、ステップＳ６０３において、プリンタドライバ２０２は、補完データに含まれている余剰モジュールの情報を読み取り、ドライバのインストールディレクトリから余剰となっているモジュールのファイルを削除する。

最後に、ステップＳ６０４において、プリンタドライバ２０２は、ドライバ構成情報２０１に、不足モジュールとしてコピーしたモジュールの情報（名称や更新時刻）を追加し、また余剰モジュールとして削除したモジュールの情報を削除する。

また、プリンタドライバ２０２は、ドライバ構成情報２０１に記述されている、更新モジュールとして上書きしたモジュールの更新時刻を新しくする。
以上の処理により、サーバ側のプリンタドライバ１０２と、クライアント側のプリンタドライバ２０２とが互いに同じモジュール構成となる。

＜実施形態２＞
上述した実施形態では、プリンタドライバ２０２がクライアントコンピュータ２０にインストールされたことをきっかけに処理を開始し、プリントサーバ１０とのモジュール構成の不整合を解消する例を示した。しかしながら、不整合を開始する処理のきっかけは他のタイミングであってもよい。

例えば、ユーザが、プリンタドライバ２０２の印刷設定を行うユーザインターフェースを開いたタイミングや、プリンタドライバ２０２がアプリケーション等の指示により印刷処理を開始するタイミングでもよい。

また、図１５に示すようなユーザインターフェースにおいて、ユーザが更新ボタンを押したタイミングでクライアントコンピュータ２０は、プリントサーバ１０との同期処理を開始してもよい。図１５は、モジュール構成の同期を開始するためのユーザインターフェース（ＵＩ）の一例を示す図である。

＜その他の実施形態＞
また、本発明の目的は、以下のようにすることによって達成される。即ち、上述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体（又は記録媒体）を、システム或いは装置に供給する。そして、そのシステム或いは装置の中央演算処理手段（ＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出し実行する。この場合、記憶媒体から読み出されたプログラムコード自体が上述した実施形態の機能を実現することになり、そのプログラムコードを記録した記憶媒体は本発明を構成することになる。

また、システム或いは装置の前記中央演算処理手段が読み出したプログラムコードを実行することにより、そのプログラムコードの指示に基づき、システム或いは装置上で稼働しているオペレーティングシステム（ＯＳ）等が実際の処理の一部又は全部を行う。その処理によって上述した実施形態の機能が実現される場合も含まれる。

更に、記憶媒体から読み出されたプログラムコードが、前記システム或いは装置に挿入された機能拡張カードや、接続された機能拡張ユニットに備わるメモリに書込まれたとする。その後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部又は全部を行い、その処理によって上述した実施形態の機能が実現される場合も含まれる。

本発明を前記記憶媒体に適用する場合、その記憶媒体には、先に説明したフローチャートに対応するプログラムコードが格納されることになる。

以上、上述した実施形態によれば、サーバ側のドライバと、パッケージポイントアンドプリントでダウンロードインストールされたクライアント側のドライバとの間でモジュール構成の整合性を取ることができる。

これによって、サーバ側にインストールされたドライバにプラグインモジュールが付加されている場合でも、このプラグインモジュールをクライアント側にダウンロードし、セットアップすることができる。つまり、サーバ側と、クライアント側とのモジュール構成を同一にすることができる。

また、予めパッケージポイントアンドプリントによってクライアント側にインストール済みのドライバであってもＵＩが開かれたり、ＵＩで指示されたり、印刷が開始されたりするタイミングでサーバ側のドライバとの整合性を取ることができる。

以上、本発明の好ましい実施形態について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

プリントサーバシステムの構成の一例を示す図である。 プリントサーバ１０のハードウェア構成の一例を示すブロック図である。 クライアントコンピュータ２０のハードウェア構成の一例を示すブロック図である。 ポイントアンドプリントにおけるプリンタドライバのインストールに関連するモジュールを説明するための機能ブロック図である。 ポイントアンドプリントによるインストールの流れを説明するための図である。 プリントサーバ１０にインストールされたプリンタドライバ１０２のプラグイン１０５を説明するための図である。 パッケージポイントアンドプリントによるインストールに関連するモジュールを説明するための機能ブロック図である。 パッケージポイントアンドプリントによるインストールの流れを示すための図である。 プリントサーバシステムにおけるモジュールのインストール方法に係る処理の流れを示すフローチャートである。 モジュール間（モジュール構成）の差異を表す図（その１）である。 モジュール間（モジュール構成）の差異を表す図（その２）である。 モジュール間（モジュール構成）の差異を表す図（その３）である。 図８に示したステップＳ１００のクライアントデバイスドライバ構成情報を収集する処理の詳細を説明するためのフローチャートである。 クライアントデバイスドライバ構成情報のデータ形式の一例を示す図である。 図８に示したステップＳ３００のモジュール構成を比較する処理の詳細を説明したフローチャートである。 補完データのデータ形式の一例を示す図である。 図８に示したステップＳ６００の補完データに基づき補完セットアップを行う処理の詳細を説明したフローチャートである。 モジュール構成の同期を開始するためのユーザインターフェース（ＵＩ）の一例を示す図である。

符号の説明

１０ プリントサーバ
２０ クライアントコンピュータ
３０ プリンタ装置

Claims (8)

1. 共有設定されたプリンタを管理するサーバ装置と、ネットワークを介して通信可能なクライアント装置であって、
   前記共有設定されたプリンタについてのパッケージポイントアンドプリントの処理の完了を示す当該クライアント装置内のスプーラからの通知に応じて、前記パッケージポイントアンドプリントの処理により当該クライアント装置にインストールされているデバイスドライバに関するモジュール構成情報を収集する収集手段と、
   前記収集手段が収集した前記モジュール構成情報を前記サーバ装置に送信するモジュール構成情報送信手段と、
   当該クライアント装置にインストールされているデバイスドライバに関するモジュール構成と、前記サーバ装置にインストールされているデバイスドライバに関するモジュール構成と、の差異を補完する補完データを前記サーバ装置より受信する補完データ受信手段と、
   前記補完データ受信手段が受信した補完データに基づき、前記デバイスドライバに関するモジュール構成を補完する補完手段と、
   を有することを特徴とするクライアント装置。
2. 前記補完手段は、前記補完データに基づき、
   前記サーバ装置にインストールされているデバイスドライバにしかない不足モジュールをインストールする、又は
   当該クライアント装置にインストールされているデバイスドライバのモジュールを、前記モジュールより更新時刻が新しい更新モジュールで上書きする
   ことを特徴とする請求項１に記載のクライアント装置。
3. 前記サーバ装置から受け取ったデータに基づきクライアント装置のモジュール構成情報に存在する少なくとも１つの余剰モジュールをアンインストールするアンインストール手段を更に有することを特徴とする請求項１又は２に記載のクライアント装置。
4. 共有設定されたプリンタを管理するサーバ装置と、ネットワークを介して通信可能なクライアント装置における情報処理方法であって、
   前記共有設定されたプリンタについてのパッケージポイントアンドプリントの処理の完了を示す前記クライアント装置内のスプーラからの通知に応じて、前記パッケージポイントアンドプリントの処理により前記クライアント装置にインストールされているデバイスドライバに関するモジュール構成情報を収集する収集ステップと、
   前記収集ステップが収集した前記モジュール構成情報を前記サーバ装置に送信するモジュール構成情報送信ステップと、
   前記クライアント装置にインストールされているデバイスドライバに関するモジュール構成と、前記サーバ装置にインストールされているデバイスドライバに関するモジュール構成と、の差異を補完する補完データを前記サーバ装置より受信する補完データ受信ステップと、
   前記補完データ受信ステップが受信した補完データに基づき、前記デバイスドライバに関するモジュール構成を補完する補完ステップと、
   を含むことを特徴とする情報処理方法。
5. 前記補完ステップでは、前記補完データに基づき、
   前記サーバ装置にインストールされているデバイスドライバにしかない不足モジュールをインストールする、又は
   前記クライアント装置にインストールされているデバイスドライバのモジュールを、前記モジュールより更新時刻が新しい更新モジュールで上書きする
   ことを特徴とする請求項４に記載の情報処理方法。
6. 前記サーバ装置から受け取ったデータに基づきクライアント装置のモジュール構成情報に存在する少なくとも１つの余剰モジュールをアンインストールするアンインストールステップを更に含むことを特徴とする請求項４又は５に記載の情報処理方法。
7. 共有設定されたプリンタを管理するサーバ装置と、ネットワークを介して通信可能なコンピュータに、
   前記共有設定されたプリンタについてのパッケージポイントアンドプリントの処理の完了を示す前記コンピュータ内のスプーラからの通知に応じて、前記パッケージポイントアンドプリントの処理により前記コンピュータにインストールされているデバイスドライバに関するモジュール構成情報を収集する収集ステップと、
   前記収集ステップが収集した前記モジュール構成情報を前記サーバ装置に送信するモジュール構成情報送信ステップと、
   前記コンピュータにインストールされているデバイスドライバに関するモジュール構成と、前記サーバ装置にインストールされているデバイスドライバに関するモジュール構成と、の差異を補完する補完データを前記サーバ装置より受信する補完データ受信ステップと、
   前記補完データ受信ステップが受信した補完データに基づき、前記デバイスドライバに関するモジュール構成を補完する補完ステップと、
   を実行させることを特徴とするプログラム。
8. 請求項７に記載のプログラムを記憶したコンピュータ読み取り可能な記憶媒体。

Images