(57)【要約】【課題】  プリンタドライバのインストール時に実行される構成情報取得を常に実行するのではなく、前回のインストール時に書き込まれたレジストリのフラグから構成情報取得を実行するかどうかを判断することによって、プリンタドライバのインストール完了時間を最適化する。【解決手段】  プリンタとクライアントコンピュータとサーバコンピュータで構成されるシステムにおいて、サーバコンピュータのプリンタドライバから構成情報取得サービスにプリンタの構成情報取得を指示する手段と、プリンタから取得した構成情報取得の結果をサーバコンピュータのプリンタドライバに通知する手段と、構成情報取得の結果プリンタから正しい構成情報取得結果が得られなかった時にはサーバコンピュータの特定の保存場所（レジストリ）のフラグをＯＦＦにする手段を備える。【選択図】  図７
2009020588.tif 000002
【特許請求の範囲】
【請求項１】
クライアントコンピュータと、プリンタと、そのプリンタのプリンタドライバを有するサーバコンピュータとを含む画像印刷システムで動作し、サーバコンピュータ上のプリンタドライバからプリンタの機器構成情報が設定できない時でも、ユーザーにストレスを与えることなく、ドライバのインストールを行う方法であって、
前記サーバコンピュータのプリンタドライバから前記クライアントコンピュータに存在する構成情報取得サービスにプリンタの構成情報取得を指示する手段と、前記プリンタから取得した構成情報取得の結果を前記サーバコンピュータのプリンタドライバに通知する手段と、前記構成情報取得の結果プリンタから正しい構成情報取得結果が得られなかった時にはサーバコンピュータの特定の保存場所（レジストリ）のフラグをＯＦＦにする手段と、前記構成情報取得の結果プリンタから正しい構成情報取得結果が得られた時にはサーバコンピュータの特定の保存場所（レジストリ）のフラグをＯＮにする手段とを有し、前記フラグがＯＦＦの時には、サーバコンピュータで実行される次回のインストール時に前記クライアントコンピュータに存在する構成情報取得サービスにプリンタの構成情報取得を指示しないことを特徴とするインストール時における構成情報取得の自動実行装置。
【請求項２】
サーバコンピュータに初めてプリンタドライバをインストールする時には、前記特定の保存場所（レジストリ）に、何もフラグが設定されていないことを特徴とする請求項１記載のインストール時における構成情報取得の自動実行装置。
【請求項３】
前記クライアントコンピュータから、前記サーバコンピュータにログインする際に、サーバコンピュータの特定の保存場所（レジストリ）のフラグがＯＦＦの時には、構成情報取得を行わない為、プリンタドライバのインストールが早期に完了することを特徴とする請求項１記載のインストール時における構成情報取得の自動実行装置。
【請求項４】
前記特定の保存場所（レジストリ）に書き込まれているフラグは、他ユーティリティでの書き換えも可能なことを特徴とする請求項１記載のインストール時における構成情報取得の自動実行装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は双方向通信を使って、プリンタドライバのインストール時にデバイスの構成情報を自動的に取得するときの処理に関してであり、その中でも、自動構成情報取得失敗時にリトライ回数を減らすことによって、プリンタドライバのインストール完了時間を大幅に短縮させることを特徴とするものである。
【背景技術】
【０００２】
双方向通信とプラグアンドプレイが普及している昨今では、プリンタドライバの自動構成情報取得機能は必要不可欠なものとなっており、例えば、プリンタドライバのコンフィグレーションシートにある「構成情報取得」のボタンを押下することによって、ターゲットプリンタのステイプル機能や両面機能を取得するというのは、今では一般的な機能になりつつある。
【０００３】
また、最近では、サーバ上にのみアプリケーションプログラムを導入して、クライアント側ではアプリケーションを一切導入しないシステム構成が普及している。
【０００４】
例えば、シトリックス社のメタフレームがこれに該当するのだが、このメタフレーム環境下でプリンタを使用する場合には、例えば、メタフレームサーバにあらかじめプリンタドライバをインストールしておく必要がある。このようにすると、プリンタを使用するクライアントからメタフレームサーバへのログイン時に、論理プリンタがプリンタドライバを使用して自動作成（ＡｕｔｏＣｒｅａｔｅ）される。そして、クライアントから印刷が実行されると、メタフレームサーバにてＡｕｔｏＣｒｅａｔｅされたプリンタドライバを用いて印刷データのラスタライズが行われ、クライアントを経由してプリンタに印刷データが送信され、印刷が行われる。
【０００５】
しかしながら、上記のようなメタフレーム環境下では、クライアント側で設定したオプション設定が、メタフレームサーバにあるプリンタドライバに反映されないという問題があった。さらに、メタフレームサーバ上で自動生成（ＡｕｔｏＣｒｅａｔｅ）されたプリンタドライバのユーザーインターフェイスからでは、構成情報取得の実行を指示できないと問題もあった。
【０００６】
このような問題を解決する従来技術として、例えば、特開２００４−０７８２８１、特開２００４−０７８２８２に記載された技術がある。これらは、サーバ上にのみアプリケーションプログラムを導入する環境（例えばメタフレーム環境）において、プリンタの機器情報をサーバ上のプリンタドライバに反映させる技術に関するものである。
【特許文献１】特開２００４−０７８２８１号公報
【特許文献２】特開２００４−０７８２８２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかしながら、上述した従来技術では、プリンタの機器情報をメタフレームサーバ上のプリンタドライバに反映させる為に別ソフトを用意する必要があり、ユーザーにとって煩わしさが発生する。
【０００８】
この煩わしさを解決する１つの手法として、プリンタドライバのインストール時に自動的に構成情報取得を行うということが提案された。つまり、メタフレーム環境でクライアント側で設定したオプション設定が、メタフレームサーバにあるプリンタドライバに反映されない（あるいは、自動生成されたプリンタドライバのユーザーインターフェイスから構成情報取得の実行を指示できない）という問題は、プリンタドライバのインストール時に自動的に構成情報取得を行うことによって解決されたのである。
【０００９】
もう少し具体的に説明すると、プリンタドライバのインストール時にコールされるＤＤＩ関数のＤｅｖＩｎｓｔａｌｌ（） 内において、構成情報取得モジュールをコールすることによって、情報の取得を行うのである。これにより、メタフレームサーバにログインする毎に、言い換えればメタフレームサーバ上でプリンタドライバが自動生成（ＡｕｔｏＣｒｅａｔｅ）される毎に、構成情報取得が自動的に実行されるので、別ソフトの提供なしで、プリンタの機器情報をサーバ上のプリンタドライバに反映させることが可能になった。
【００１０】
しかしながら、上述した技術だと、メタフレームサーバにログインする毎に構成情報取得が実行されることになるので、構成情報が成功する時は問題ないが、例えば、ある理由から構成情報取得が失敗する時には、ログインにかかる時間が通常より長くなり、これがユーザーのストレスになる場合があった。
【００１１】
また、構成情報の失敗となるまでには、通常数回のリトライを行うので、環境によっては、最悪数十秒、インストール完了までに時間を要し、これがそのままメタフレームサーバへのログイン時間につながった。
【００１２】
本発明は上記問題点を解決することを目的としたもので、プリンタドライバのインストール時に実行される構成情報取得を常に実行するのではなく、レジストリに書き込まれているフラグのＯＮ／ＯＦＦから決定することを特徴とするインストール時における構成情報取得の自動実行についてである。さらに言えば、このフラグは、構成情報取得に失敗した時には、ＯＦＦに書き換えること特徴とするものである。
【００１３】
これにより、構成情報取得失敗時のリトライ回数を減らすことが可能になる為、構成情報取得失敗時のプリンタドライバのインストール完了時間を大幅に短縮させることが可能になる。
【課題を解決するための手段】
【００１４】
上記目的を達成するために本発明のインストール時における構成情報取得の自動実行装置は以下の構成を備える。
【００１５】
つまり、クライアントコンピュータと、プリンタと、そのプリンタのプリンタドライバを有するサーバコンピュータとを含む画像印刷システムで動作し、サーバコンピュータ上のプリンタドライバからプリンタの機器構成情報が設定できない時でも、ユーザーにストレスを与えることなく、ドライバのインストールを行う装置において、
前記サーバコンピュータのプリンタドライバから前記クライアントコンピュータに存在する構成情報取得サービスにプリンタの構成情報取得を指示する手段と、前記プリンタから取得した構成情報取得の結果を前記サーバコンピュータのプリンタドライバに通知する手段と、前記構成情報取得の結果プリンタから正しい構成情報取得結果が得られなかった時にはサーバコンピュータの特定の保存場所（レジストリ）のフラグをＯＦＦにする手段と、前記構成情報取得の結果プリンタから正しい構成情報取得結果が得られた時にはサーバコンピュータの特定の保存場所（レジストリ）のフラグをＯＮにする手段とを備える。
【発明の効果】
【００１６】
プリンタドライバのインストール時に実行される構成情報取得を常に実行するのではなく、前回のインストール時に書き込まれたレジストリのフラグから構成情報取得を実行するかどうかを判断することによって、プリンタドライバのインストール完了時間を最適化することが可能になる。
【発明を実施するための最良の形態】
【００１７】
以下、本発明の実施の形態について図面を参照して説明する。
【００１８】
図１は本発明の一実施例を示す印刷処理システムのブロック構成図である。なお、特に断らない限り、本発明の機能が実行されるのであれば、単体の機能であっても、複数の機器からなるシステムであっても、ＬＡＮ、ＷＡＮ等のネットワークを介して接続がなされ処理が行われるシステムであっても、本発明を適用できることは言うまでもない。
【００１９】
図１においては、特に情報処理装置１００の内部のブロック構成に対して詳細にかかれている。ＣＰＵ１０１はＲＯＭ１０２あるいはＲＡＭ１０３あるいは記憶装置１０５に格納されたプログラムに従って装置全体の制御を行う。ＲＡＭ１０３はＣＰＵ１０１が各種処理を行う際のワークエリアとして使用される。記憶装置１０５はオペレーティングシステム（ＯＳ）１０５５やアプリケーションソフト１０５１等を記録する。キーボードやマウスなどの入力機器は、入力Ｉ／Ｆ１０４を通じて、ユーザがコンピュータに対して各種指示を与えるためのデバイスである。出力Ｉ／Ｆ１０６は、データを外部に出力するためのインターフェースであり、モニタやプリンタに対してデータを出力する。１０７は共通データバスで、それぞれのデータのやりとりを行う。また、ネットワークＩ／Ｆ１０８は、情報処理装置１００よりイントラネットやインターネットなどの通信媒介を通して、サーバ１１０や、その他の情報処理装置１２０や、そしてプリンタ１３０などと情報の授受を行うことが出来る。
【００２０】
図２において印刷処理システムのモジュール構成を示す。ユーザはキーボードやマウスなどといった入力装置１０４を使用して、出力装置１０５のモニタに映し出されたアプリケーションプログラム２０１を使用して作成した文書２０３の印刷処理を実行する。ユーザによって印刷処理が実行されると、アプリケーション２０１はユーザの印刷操作を理解し、文書の印刷設定２０３１と文書内容の描画データ２０３２を元に、印刷を実行するプリンタに対応したプリンタドライバ２０９を選択した後、オペレーティングシステム２０４に印刷処理を通知する。オペレーティングシステム２０４はグラフィックスエンジン２０５を通じて、スプールファイル２０６への描画や、指定されたプリンタドライバ２０９への描画を行い、プリンタドライバはプリンタが理解できるデータ言語に変換し、プリントマネージャ２０７が各アプリケーションからの印刷処理のスケジュール管理を行う。プリントマネージャ２０７は、プリンタが印刷できる状態になったときに、Ｉ／Ｏモジュール２０８を介してプリンタ１３０に印刷ジョブデータを送信する。これにより、印刷が実行される。
【００２１】
文書の印刷設定２０３１はプリンタドライバのコンフィギュレーションモジュール２０９１によって初期値が作成され、その印刷設定をアプリケーションもしくはプリンタドライバのユーザインターフェースを使用してユーザが望む最終印刷結果になるように変更して設定を行う。印刷設定は２種類の形態があり、１つはＤＥＶＭＯＤＥと呼ばれるバイナリデータ形式のデータ構造体であり、これは従来の印刷の系で使われていた。もう１つはジョブチケットと呼ばれるタグを用いたマークアップ言語ＸＭＬ形式のテキストデータであり、テキストデータであるので可読/編集/追加可能であるという利点があり、従来のDEVMODE形式よりジョブチケット形式に移行していくことが予想される。どちらの印刷設定形式を選択するかは、プリンタドライバやオペレーティングシステムの仕様や、そしてアプリケーションの対応状況によって異なる。
【００２２】
従来良く使われていたＤＥＶＭＯＤＥ構造体は大きく分けて２つの設定領域からなる。１つはオペレーティングシステムで定義されている共通の基本情報を設定する領域でパブリック領域と呼ばれる。もうひとつは各プリンタに存在するプリンタドライバ２０９が自由に拡張できる領域でプライベート領域と呼ばれる。パブリック領域はその中に含まれる情報が何を示すのかについては、オペレーティングシステムのフォーマットとして一般に広く公開されており、どのアプリケーションからも設定を変更することができる。これはアプリケーションがもつページ設定ダイアログから指定することができる。しかしプライベート領域は、自由にデータを拡張できるため、プリンタドライバ２０９しか設定することができない。そこでプリンタドライバのコンフィギュレーションモジュール２０９１はユーザインターフェースを持ち、その中で拡張領域の印刷設定をする方法を提供する。
【００２３】
ステイプルなど少し詳細に印刷設定をユーザが望む場合、その設定はプライベート領域に保存されているのでドライバコンフィギュレーションモジュール２０９１無しには変更することが出来ない。よって文書２０３の一部としてDEVMODE構造体がドライバの存在しない環境に運ばれた場合、その環境ではドキュメントに付加されている印刷設定２０３１のプライベート領域に保存されている情報を知るすべがユーザには存在しなかった。よってDEVMODE構造体で情報を保存した従来の文書は、プリンタドライバ２０９が存在する環境のみ印刷設定の編集や機能追加、またヘルプ情報への参照を行うことが前提となっていた。
【００２４】
図３は、本特許が特に有効である、サーバークライアントモデルの構成図の一例である。本システムは、サーバ上にのみアプリケーションプログラムが導入され、クライアント側ではアプリケーションを導入しないケースである。本システムの代表例として、シトリックス社のメタフレームがある。
【００２５】
まず、クライアントコンピュータ３０３からメタフレームサーバ３０２にログイン（３０４）すると、これらのコンピュータ間でセッションがはられ、メタフレームサーバにあらかじめインストールされているプリンタドライバが、論理プリンタとして自動生成（ＡｕｔｏＣｒｅａｔｅ）される。ここで、クライアントコンピュータから印刷指示（３０５）がされると、メタフレームサーバ３０２にてＡｕｔｏＣｒｅａｔｅされたプリンタドライバを用いて印刷ジョブが生成され（３０６）、これはクライアントコンピュータ３０３で設定されている印刷ポートを経由して、プリンタ３０１で印刷が行われる。
【００２６】
印刷ジョブの生成はメタフレームサーバ３０２で行われているにもかかわらず、印刷ポートはクライアントコンピュータ３０３で設定されているものが使われる理由であるが、メタフレームは、サーバにインストールされているアプリケーションをクライアントで共有するコンセプトで作られており、オフィス系のアプリケーションはメタフレームサーバで、その他のアプリケーションはクライアントで管理することを想定しているからである。つまり、オートクリエイトプリンタをすることによって、メタフレームサーバで管理されているアプリケーションと、クライアントコンピュータで管理されているアプリケーションの印刷ポートを一緒にすることが可能になる。
【００２７】
図４は、図３のシステム構成に、プリントサーバを追加したケースである。大規模なシステム構成であればあるほど、負荷分散の為にプリントサーバを別に用意するケースが一般的になる。
【００２８】
クライアントコンピュータ４０３は、プリントサーバ４０２にインストールされているプリンタドライバを、ポイントアンドプリントというウィンドウズ（登録商標）に搭載された機能を用いてダウンロードする。次に、クライアントコンピュータ４０３からメタフレームサーバ４０４にログイン（４０７）すると、これらのコンピュータ間でセッションがはられ、メタフレームサーバにあらかじめインストールされているプリンタドライバが、論理プリンタとして自動生成（ＡｕｔｏＣｒｅａｔｅ）される。ここで、クライアントコンピュータから印刷指示（４０６）がされると、メタフレームサーバ４０４にてＡｕｔｏＣｒｅａｔｅされたプリンタドライバを用いて印刷ジョブが生成され（４０６）、これはプリントサーバ４０２で設定されている印刷ポートを経由して、プリンタ４０１で印刷が行われる。図４のシステム構成が有利な点としては、印刷ポートの設定をプリントサーバにインストールされているプリンタドライバで共有できる為、クライアント毎にプリンタポートの設定、及びプリンタドライバのインストールを行わなくてもすむことである。
【００２９】
しかしながら、シトリックス社が提供しているメタフレームの場合、クライアントコンピュータで設定したコンフィグレーションシートのオプション設定（両面印刷を可能にする両面ユニットが装着されているかや、ステイプル機能を装備したフィニッシャーが装着されているかなど）が、メタフレームサーバに論理プリンタとして自動生成（ＡｕｔｏＣｒｅａｔｅ）されるプリンタドライバに反映されないという問題があった。さらに、メタフレームサーバ上で自動生成（ＡｕｔｏＣｒｅａｔｅ）されたプリンタドライバのユーザーインターフェイスから、構成情報取得の実行を指示できないと問題もあった。
【００３０】
これを解決する手段として、プリンタドライバのインストール時に構成情報取得を自動的に行うということが提案された。具体的には、プリンタドライバのインストール時にコールされるＤＤＩ関数のＤｅｖＩｎｓｔａｌｌ（）内において、構成情報取得モジュールをコールして、情報の取得を行うのである。これにより、メタフレームサーバにログインする毎に、言い換えればメタフレームサーバ上でプリンタドライが論理プリンタとして自動生成（ＡｕｔｏＣｒｅａｔｅ）される毎に、両面機能の有無、ステイプル機能の有無を、プリンタドライバのユーザーインターフェイスに反映させることが可能になった。
【００３１】
次に、図３と図４で説明したシステム構成図の場合、どのようにして構成情報取得を自動的に実行するかを詳細に説明する。
【００３２】
図５は、プリントサーバがないときのケースである。まず、クライアントコンピュータ５０３からメタフレームサーバ５０２にログイン（５０６）すると、これらのコンピュータ間でセッションがはられ、メタフレームサーバにあらかじめインストールされているプリンタドライバが、論理プリンタとして自動生成（ＡｕｔｏＣｒｅａｔｅ）される。ここで、オートクリエイトされる際に、ＤＤＩ関数のＤｅｖＩｎｓｔａｌｌ（）がコールされる為、メタフレームサーバ５０２にインストールされた構成情報取得モジュール５０４が実行される。この構成情報取得モジュールは、クライアントコンピュータ５０３にインストールされている構成情報取得サービス５０５と通信を行い、プリンタ５０１の構成情報を取得して、５０９、５１０の経路でオートクリエイトされたプリンタに構成情報を送付する。
【００３３】
図６は、プリントサーバが存在する時のケースである。クライアントコンピュータ６０３は、プリントサーバ６０２にインストールされているプリンタドライバを、ポイントアンドプリントというウィンドウズ（登録商標）に搭載された機能を用いてダウンロードする。次に、クライアントコンピュータ６０３からメタフレームサーバ６０４にログイン（６０５）すると、これらのコンピュータ間でセッションがはられ、メタフレームサーバにあらかじめインストールされているプリンタドライバが、論理プリンタとして自動生成（ＡｕｔｏＣｒｅａｔｅ）される。ここで、オートクリエイトされる際に、ＤＤＩ関数のＤｅｖＩｎｓｔａｌｌ（）がコールされる為、メタフレームサーバ６０４にインストールされた構成情報取得モジュール６１３が実行される。この構成情報取得モジュールは、クライアントコンピュータ６０３を経由して、プリントサーバ６０２にインストールされている構成情報取得サービス６１２と通信を行い、プリンタ６０１の構成情報を取得して、６０７、６１１の経路でオートクリエイトされたプリンタに構成情報を送付する。図６のシステム構成が図５より有利な点としては、構成情報取得サービスをクライアントコンピュータ毎ではなく、プリントサーバのみにインストールすればよいことがあげられる。
【００３４】
クライアントコンピュータからメタフレームサーバにセッションをはり終える為には、メタフレームサーバにあらかじめインストールされているプリンタドライバが、論理プリンタとして自動生成（ＡｕｔｏＣｒｅａｔｅ）される必要がある。言い換えれば、プリンタドライバのインストールが終わるまでは、メタフレームサーバにセッションをはることが出来ない。構成情報がすぐに取得できる環境はそれほど問題にはならないが、失敗する時には、通常数回のリトライを行うので、環境によっては、最悪数十秒、インストール完了までに時間を要し、これがそのままメタフレームサーバへのログイン時間につながった。
【００３５】
特に、本システムの場合、印刷ポートが設定されているパーソナルコンピュータに構成情報取得サービスを別途インストールする必要がある為、これをインストールしていない人がセッションをはろうとすると、毎回セッションをはるのにストレスを感じることになった。
【００３６】
図７は、本問題を解決することを目的とした、構成情報取得の自動実行についてのフローチャートを示したものである。
【００３７】
まず、７０１でメタフレームサーバにログインすると、論理プリンタの生成が行われる。（７０２）ここで、ＤＤＩ関数のＤｅｖＩｎｓｔａｌｌ（）がコールされると、この関数内で下記レジストリのチェックを行う（７０３）。
【００３８】
HKLM\SYSTEM\CurrentControlSet\Control\Print\autoconfig
このフラグがＯＮの時には、７０５で示すようにＤｅｖＩｎｓｔａｌｌ（）内で構成情報取得モジュールを実行して、プリンタ本体に構成情報の問い合わせを行う。プリンタ本体から正常に情報取得ができた場合には（７０６）、レジストリのフラグをＯＮにしてから（７０８）プリンタドライバのインストール作業を継続し、失敗した時には、上記レジストリをＯＦＦに変更してから、インストール作業を継続する。７０４でレジストリのフラグがＯＦＦと判断された場合には、構成情報取得モジュールをコールしないで、つまり、構成情報取得を行わないで、インストール作業を継続する。
【００３９】
ただ、本システムの場合、上記レジストリがいったんＯＦＦになると、ＯＮに変更する手段がない。つまり、本実施例だと、構成情報取得サービスのインストールを含めた全てが正常にセットアップされていても、何らかの不具合で、例えばネットワークケーブルが外れているという突発事項がいったん発生してしまうと、その後、自動生成（ＡｕｔｏＣｒｅａｔｅ）のタイミングでの構成情報自動取得が実行されないことになってしまう。
【００４０】
本問題の解決方法としては、復旧用のユーティリティを用意することとする。つまり、上記レジストリが何らかの不具合でＯＦＦになってしまったクライアントコンピュータは、レジストリのフラグを書き換えるユーティリティを走らせることによって、レジストリをデフォルトであるＯＮに変更する。図８は、このユーティリティを走らせた時のユーザーインターフェイスの一例である。
【００４１】
上記の通り、プリンタドライバのインストール時に実行される構成情報取得を常に実行するのではなく、レジストリに書き込まれているフラグのＯＮ／ＯＦＦから決定することによって、構成情報取得失敗時のリトライ回数を減らし、構成情報取得失敗時のプリンタドライバのインストール完了時間を大幅に短縮させることが可能となる。
【図面の簡単な説明】
【００４２】
【図１】本発明の一実施例として、システムの構成を説明するブロック図を示す。
【図２】本発明の一実施例として、一般的な印刷システム・印刷データ生成の構成を説明するブロック図を示す。
【図３】プリントサーバが存在しない時のクライアントサーバモデルの一般的な模式図を示す。
【図４】プリントサーバが存在する時のクライアントサーバモデルの一般的な模式図を示す。
【図５】本発明の一実施例として、プリントサーバが存在しない時の構成情報取得の流れを示した模式図である。
【図６】本発明の一実施例として、プリントサーバが存在する時の構成情報取得の流れを示した模式図である。
【図７】同実施の形態における構成情報取得の自動実行全体を示すフローチャートである。
【図８】本発明の一実施例として、強制的に構成情報取得を行わせるユーティリティのＵＩ案である。
【図１】
2009020588.tif 000003
【図２】
2009020588.tif 000004
【図３】
2009020588.tif 000005
【図４】
2009020588.tif 000006
【図５】
2009020588.tif 000007
【図６】
2009020588.tif 000008
【図７】
2009020588.tif 000009
【図８】
2009020588.tif 000010