JP2014178823A - 情報処理装置、プログラム及びシステム - Google Patents

Abstract

【課題】複数のデバイスドライバに関する設定を、簡単な操作で統一感のあるユーザインタフェースで受け付ける機能を、低コストで実現できるようにすること。
【解決手段】情報処理装置に既に登録されているドライバ１のユーザインタフェース（ＵＩ＿１）と、ドライバ１とは異なるドライバ２とを関連付けたドライバＵＩ関連付け情報を登録し（ｃ）、ドライバ２に関する設定を受け付ける場合に、ドライバＵＩ関連付け情報によりドライバ２と関連付けられたＵＩ＿１を呼び出して、ＵＩ＿１よりドライバ２に関する設定を受け付けるようにした。
【選択図】図８

Description

本発明は、情報処理装置、プログラム及びシステムに関する。

従来から、複数のプリンタドライバを備えた情報処理装置において、それらのプリンタドライバに関する設定を、共通のユーザインタフェース（ＵＩ）により受け付けることができるようにすることが試みられている。印刷に用いるプリンタの機種毎にプリンタドライバが異なり、それに応じてＵＩが異なると、ユーザが設定操作の方法を覚えたり、また設定を行ったりするために大きな労力を要するためである。
例えば、特許文献１には、複数のドライバソフトを通じて複数の周辺機器に対する統合的な制御を行う単一のユーザインタフェースを設けることが記載されている。

しかしながら、特許文献１に記載の技術は、各ドライバソフトのユーザインタフェースに追加して、統合的な制御を行うユーザインタフェースを設けるものである。従って、ユーザは、ドライバソフトを利用するに際し、ドライバソフト毎のユーザインタフェースを用いるか、統合的な制御を行うユーザインタフェースを用いるかを選択しなければならない。このため、プリンタの選択に応じてドライバソフト毎のＵＩが表示される場合と比べ、操作感が大きく異なることになる。

また、統合的な制御を行うユーザインタフェースを実装するためには、そのインタフェースを、ドライバとしてのルールに従って設ける必要がある。このため、費用や手間のかかるロゴ取得などが必要になる。
なお、このような問題は、プリンタドライバ以外のデバイスドライバについて共通のＵＩを設けようとする場合にも、同様に発生するものである。
この発明は、このような背景に基づいてなされたものであり、複数のデバイスドライバに関する設定を、簡単な操作で統一感のあるユーザインタフェースで受け付ける機能を、低コストで実現できるようにすることを目的とする。

上記目的を達成するために、この発明の情報処理装置は、この情報処理装置に既に登録されている第１のデバイスドライバのユーザインタフェースと上記第１のデバイスドライバとは異なる第２のデバイスドライバとを関連付けた関連付け情報を登録するＵＩ登録手段と、
上記第２のデバイスドライバに関する設定を受け付ける場合に、上記関連付け情報により上記第２のデバイスドライバと関連付けられた上記第１のデバイスドライバのユーザインタフェースを呼び出して、上記ユーザインタフェースにより上記第２のデバイスドライバに関する設定を受け付けるＵＩ制御手段とを備えたことを特徴とするものである。

以上のような構成の情報処理装置によれば、複数のデバイスドライバに関する設定を、簡単な操作で統一感のあるユーザインタフェースで受け付ける機能を、低コストで実現することができる。

この発明の情報処理装置の一実施形態の機能構成を示すブロック図である。 図１に示したドライバ選択制御部のより詳細な機能ブロック図を示す。 プリンタドライバに付属のＵＩを共通で使用するＵＩへ置換える為の登録時のフローチャートの一例を示すものである。 ドライバ選択画面の表示例を示すものである。 ＵＩの仮想コピーの態様について説明する図である。 ドライバＵＩ関連付け情報の一つの例を示す図である。 ドライバＵＩ登録情報の態様の一例を示す図である。 ＵＩの置き換え処理における各モジュールの関連について説明するための図である。 ドライバＵＩ表示時の処理のフローチャートを示すものである。 図８の別の形態について説明するための図である。 実施形態の効果について説明する図である。 実施形態の第１の変形例について説明するための図である。 実施形態の第２の変形例について説明するための図である。 実施形態の第３の変形例について説明するための図である。 実施形態の第４の変形例について説明するための図である。

以下、この発明を実施するための形態を図面に基づいて具体的に説明する。なお、本実施形態は、複数のデバイスドライバに関する設定を、簡単な操作で統一感のあるユーザインタフェース（以下、「ＵＩ」という）で受け付ける機能を備えた情報処理装置に関するものである。以下、デバイスドライバがプリンタドライバである場合を例として説明するが、本発明は他のデバイスドライバにも同様に適用できることは言うまでもない。

図１は、この発明の情報処理装置の一実施形態の機能構成を示すブロック図である。なお、図１には、本実施形態の特徴に係るデバイスドライバ及びそのＵＩの制御に関連する部分の構成を中心に示す。
図１に示す情報処理装置１０は、例えばＰＣ（パーソナルコンピュータ）として構成でき、入力部２０、表示部３０、記憶部４０、ドライバ選択制御部５０、プリンタドライバ６０、ドライバＵＩ７０及び制御部８０を備えている。

このうち、入力部２０は、ユーザが必要なデータの入力や操作を行うのに使用するものである。入力部２０は、例えば、キーボード、タッチパネル、マウスなどのポインティング装置（デバイス）、音声入力装置などで構成される。

また、表示部３０は、コンピュータの画面を表示する装置であり、例えば、ＬＣＤ（液晶ディスプレイ）やＣＲＴ（陰極線管）などの表示装置で構成される。そのほかに、ＬＥＤ（発光ダイオード）等によるランプを備えていてもよい。
記憶部４０は、ＯＳ（オペレーティングシステム）、アプリケーションソフト及び種々のデータを記憶するためのデバイスであり、例えば、ＨＤＤ（ハードディスクドライブ）やフラッシュメモリなど不揮発性メモリで構成される。

ドライバ選択制御部５０は、情報処理装置１０が備えるプリンタドライバの登録や起動、プリンタドライバに対するデータの受け渡し等の機能を有する。例えば、アプリケーションからの要求に応じてドライバのＵＩを起動したり、ＵＩにおいて受け付けた設定内容を保存したりする機能を有する。また、印刷に用いるプリンタの選択に応じて対応するプリンタドライバやＵＩを選択したり、アプリケーションからの印刷指示に応じて印刷すべき文書のデータを印刷に用いる設定内容と共にプリンタドライバに渡して処理させたりする機能も備える。

また、ドライバ選択制御部５０は、印刷に使用したいドライバを選択するという操作を行うだけでただ一つの統一感のあるＵＩで、複数のプリンタドライバに対して印刷設定を行うことを可能とするための機能も備え、本発明の特徴的な部分である。
これらのドライバ選択制御部５０の機能は、ファームウェアを内蔵した専用のハードウェアで実現してもよいし、後述のＣＰＵ８１に必要なソフトウェアを実行させることにより実現してもよい。

プリンタドライバ６０は、用紙に画像を形成する画像形成装置であるプリンタ９０を制御するためのソフトウェアである。そして、アプリケーションで作成された描画データを、当該プリンタドライバ６０が対応するプリンタに解釈可能又は処理可能な形式（例えば、ＰＤＬ（Page Description Language））の印刷データへ変換する機能を備えている。図では１つしか示していないが、本実施例では、情報処理装置１０は、４種類のプリンタ９０を利用可能になっており、それぞれのプリンタに対応したプリンタドライバがインストールされている。すなわち、プリンタドライバ１〜４（６０ａ〜６０ｄ）である。

また、ＵＩモジュール７０は、ユーザが印刷の設定を行ったり、描画データのプレビューを行わせたりするためのＧＵＩ（Graphical User Interface）を提供するソフトウェアモジュールである。なお、図１において、プリンタドライバ１（６０ａ）に対応するＵＩモジュールを「ＵＩ＿１」（７０ａ）とし、以下同様に名前を付けた。

さらに、制御部８０は、中央演算処理装置（ＣＰＵ）８１、ＲＡＭ８２、ＲＯＭ８３を備えている。ＣＰＵ８１は、ＯＳ（Operating System）や所定のプログラムを記憶部４０からロードして実行することで種々の機能を発揮すると共に、情報処理装置１０が行う処理を統括的に制御する。ＲＡＭ８２は、ＯＳやプログラムを実行する作業領域になり、ＲＯＭ８３はＢＩＯＳ等、ＯＳを起動するためのプログラムや設定ファイルを記憶している。
なお、図１において、説明の都合上、プリンタドライバ６０（６０ａ〜６０ｄ）、ＵＩモジュール７０（７０ａ〜７０ｄ）が記憶部４０の外に描かれているが、記憶部４０の中に格納されていてもよい。

ところで、米国マイクロソフト社製のＯＳであるＷｉｎｄｏｗｓ（登録商標）８からＶｅｒｓｉｏｎ４のドライバ（以下、「Ｖ４ドライバ」という）という新しいアーキテクチャが登場した。このアーキテクチャでは、Ｖ４ドライバのデスクトップモードのＵＩアプリケーション（ＵＩの実行プログラムを指す）は、プリンタドライバのインストール後でもプリンタドライバへの着脱が可能であるということは既に知られている。

Ｖ４ドライバのデスクトップモードのプリンタドライバでは、各メーカーがプリンタドライバに付属して提供するドライバＵＩを利用したい場合はそのドライバＵＩを表示でき、付属のドライバＵＩを用意していない場合には、ＯＳに標準装備されている標準のＵＩが表示されるという仕組みになっている。

ここで、ドライバＵＩを用いて設定を受け付けるためには、ＵＩモジュールは、呼び出し元のプリンタドライバ（ドライバＩＤ）に応じてＯＳへの処理を切り替える必要がある。しかし、ＵＩモジュール（ＵＩの機能を実現するソフトウェア）は、そのままでは、呼び出される際にどのプリンタドライバ（呼び出し元のプリンタドライバ）から呼び出されているのかが分からない。そこで、Ｖ４ドライバというアーキテクチャでは、プリンタドライバ毎にドライバＵＩを関連付けることを前提としている。なお、この関連付け作業はドライバのインストール後にも実施可能である。
本発明の実施例では、かかるＶ４ドライバというアーキテクチャを利用して、プリンタドライバ毎にドライバＵＩを関連付けることにより、上述の統一感のあるＵＩに係る機能を実現している。しかし、このアーキテクチャを利用することとは必須ではない。

図２は、図１に示したドライバ選択制御部５０のより詳細な機能ブロック図を示す。
図２に示すように、ドライバ選択制御部５０は、ＵＩ変更ドライバ選択部５０１、ドライバＩＤ探索部５０２、ドライバＵＩ仮想複製部５０３、ドライバＵＩ関連付け情報保存部５０４、ドライバＵＩ登録部５０５、呼び出し元ドライバ判定部５０６、ドライバイベントハンドラ登録部５０７及びドライバＵＩ表示部５０８を備える。

このうち、ＵＩ変更ドライバ選択部５０１は、ＵＩを共通で使用するＵＩへ置換えるプリンタドライバを、ユーザに選択させる機能を有する。
例えば、ＵＩ変更ドライバ選択部５０１は、インストールされているプリンタドライバの中から、ＵＩの置換えが可能なプリンタドライバをリストアップして表示し、その中からどのプリンタドライバに関してＵＩの置換えを行うかをユーザに選択させる画面を提供する。
また、特定のファイルへの置換えを行うプリンタドライバ名を記載するなどの方法により、共通で利用するＵＩへ置換える対象とするプリンタドライバをユーザに選択させることもできる。

ドライバＩＤ探索部５０２は、プリンタドライバにＵＩモジュールを関連付ける際に使用するドライバ固有のＩＤ（ドライバＩＤ）を探索する機能を有する。ドライバＩＤ探索部５０２は例えば、ＯＳにインストールされている各プリンタドライバの構成ファイルからドライバＩＤを探索することができる。

ドライバＵＩ仮想複製部５０３は、各ドライバで共用するＵＩモジュールを仮想的に複製する機能を有する。「仮想的に複製する」とは、ＵＩモジュールを複製する際に、実体は一つなのであるが、Ｗｉｎｄｏｗｓ上のファイルとしては複数の箇所にあるように見えるように複製することである。例えば、ハードリンクの仕組みを利用すれば、実体は一つであるが、Ｗｉｎｄｏｗｓ上は複数のファイルがあるように見えるようにすることができる。これにより、複数のファイルを参照可能としても、実体としては一つであるため、記憶容量は一つのファイル分しか使用せず、記憶部４０を有効に使用することができる。
なお、記憶部の記憶容量に余裕があれば、仮想コピーではなく実体のコピーでも構わない。

ドライバＵＩ関連付け情報保存部５０４は、各ドライバＩＤに対して、利用するＵＩモジュールがインストールされている場所（たとえばファイルパス）を特定するドライバＵＩ関連付け情報を保存する機能を備える。このドライバＵＩ関連付け情報に基づいて、呼出し元ドライバ判定部５０６が、ＵＩモジュールがＯＳから呼び出された際に、どのプリンタドライバから呼び出されているのかを判定することができる。

ドライバＵＩ登録部５０５は、各プリンタドライバがＵＩモジュールとして利用するＵＩモジュールのファイルパスを、ＯＳに対して登録する機能を備える。これにより、ユーザがプリンタドライバを起動すると、それに関連付けられたＵＩモジュールが呼び出され、表示されるようになる。
以上、ＵＩ変更ドライバ選択部５０１からドライバＵＩ登録部５０５までが、制御部８０と協働することにより、全体としてＵＩ登録手段としての機能が実現される。

また、呼び出し元ドライバ判定部５０６は、ドライバＵＩ関連付け情報を読み取り、起動中のＵＩモジュールにつき、そのＵＩモジュール自身のファイルパスから、そのＵＩモジュールがどのドライバＩＤを持つプリンタドライバから呼び出されているのかという判定を行う機能を有する。これにより、ＵＩモジュールがＯＳから呼び出される際に、どのプリンタドライバ（呼び出し元のプリンタドライバ）から呼び出されているのかが分かるようになる。

ドライバイベントハンドラ登録部５０７は、呼び出し元ドライバ判定部５０６で判定されたドライバＩＤを使用して、ＵＩ表示のためのイベントハンドラの登録をＯＳに対して行う機能を有する。

ドライバＵＩ表示部５０８は、ＵＩモジュール７０に基づき、ドライバのＵＩを情報処理装置１０の表示部３０に表示させる機能を有する。ドライバＵＩ関連付け情報保存部５０４及びドライバＵＩ登録部５０５が、複数のドライバについて共通のドライバＵＩを関連付けて登録していれば、ドライバＵＩ表示部５０８が表示するＵＩはこれらについて共通のものとなる。これにより、ユーザは、統一感のあるＵＩを使用して印刷設定等ができるようになる。
以上、呼び出し元ドライバ判定部５０６からドライバＵＩ表示部５０８までが、制御部８０と協働することにより、全体としてＵＩ制御手段としての機能が実現される。

本発明は、大きくわけると、ＵＩの置き換え登録時の処理と、置き換えられたＵＩを使用したＵＩ表示時の処理の２つになる。
これらのうち、まずＵＩの置き換え登録時の処理について説明する。
図３は、プリンタドライバに付属のＵＩを共通で使用するＵＩへ置換える為の登録を行う際にＣＰＵ８１が実行する処理のフローチャートを示す。すなわち、ＵＩ登録手段の機能と対応する処理を示したものである。

図３の処理は、ＣＰＵ８１がプリンタドライバプログラムを実行することにより行うものである。ＣＰＵ８１は、ＵＩの置き換えに関する機能の実行指示を検出すると、図３に示す処理を開始する。
そしてまず、ＣＰＵ８１は、ＵＩの置き換えを行うプリンタドライバの選択をユーザから受け付けるための画面を表示部３０に表示させる（Ｓ１）。これは、ＵＩ変更ドライバ選択部５０１の機能と対応する処理である。

図４は、ＵＩの置き換えを行うプリンタドライバの選択を受け付けるための画面の表示例を示す図である。
図４に示すドライバ選択画面２００画面は、ドライバ選択部２０１、ＯＫボタン２０２及びキャンセルボタン２０３を備える。このうちドライバ選択部２０１には、情報処理装置１０に既にインストールされているプリンタドライバを列挙する。図４の例では、プリンタドライバ１〜４がインストールされているが、図３の処理に用いているプリンタドライバは、ＵＩの置き換えの対象にならないため選択肢から除外されている。

そして、ユーザが、ドライバ選択部２０１においてＵＩの置き換えを希望するプリンタドライバを示すチェックボックスにチェックマークを入れて、ＯＫボタン２０２を押すと、ＣＰＵ８１はそれを受け付け、次のステップＳ２に移行する。図４の例では、ドライバ２が選択されたことを示している。キャンセルボタン２０３が押された場合、ＣＰＵ８１は図３の処理を終了する。

次に、ＣＰＵ８１は、ステップＳ１で選択されたプリンタドライバのドライバＩＤを、ＯＳにインストール済みのドライバパッケージの中にある構成ファイルの中から探索して取得する（Ｓ２）。これは、ドライバＩＤ探索部５０２の機能と対応する処理である。

次に、ＣＰＵ８１は、ステップＳ１で選択されたドライバと関連付けるための、ドライバＵＩモジュールの仮想コピーを作成する（Ｓ３）。この処理は、ドライバＵＩ仮想複製部５０３の機能と対応するものである。
また、ここでいう仮想コピーとは、Ｗｉｎｄｏｗｓ上に新たにファイルアイコンが作成され、見た目上はファイルのコピーが作成されたように見えるが、実体としては一つしか存在しないものを指す。作成されたコピーはショートカットのようなもの（Ｗｉｎｄｏｗｓでの機能としてはハードリンク等と呼ばれる）を意味している。実体としてはドライバＵＩモジュールは１つであるため、ディスク容量も一つのファイル分しか使用しない。

具体的には、例えば、プリンタドライバ１に付属しているＵＩモジュールである「ui1.exe」の仮想コピーを作り、これをプリンタドライバ２と関連付けるためのＵＩモジュールとして「ui2i.exe」と名前を付けて所定のフォルダ（ファイルパス）に保存することができる。

図５は、ＵＩの仮想コピーの態様について説明する図である。図５では、プリンタドライバ１及びプリンタドライバ２に対して、それぞれＵＩ＿１及びＵＩ＿２を関連付けるケースにおける仮想コピー作成の態様を示している。
図５（Ａ）は、ＵＩ＿１が実体として元々存在していて、ＵＩ＿２は仮想ファイルであり、実体としてのＵＩ＿１を参照している態様を示している。上記の具体例はこの態様によるものである。

図５（Ｂ）は別の態様であり、ＵＩ＿１とＵＩ＿２は両方とも仮想ファイルであり、それぞれが同じＵＩ（実体）を参照している場合である。ＵＩ（実体）は、もともと存在するＵＩ＿１（実体）を利用してもよいし、それとは別のものでもよい。
Ｗｉｎｄｏｗｓでは、シンボリックリンクやハードリンクという機能を利用して、このような実体が一つであるが、それぞれが別の場所にあるという状態を作ることが出来る。

図３の説明に戻ると、ＣＰＵ８１は次に、ステップＳ２で取得したドライバＩＤと、そのドライバＩＤを持つプリンタドライバに利用させるＵＩモジュールのファイルパス情報を関連付けて、ドライバＵＩ関連付け情報として保存する（Ｓ４）。ファイルパスは、そのドライバＩＤを持つプリンタドライバに関連付けられるＵＩモジュールが存在する場所を示す位置情報である。また、保存は、ファイルやレジストリなどの形態で任意の場所に行うことができる。また、ここで関連付けるＵＩモジュールは、ステップＳ３で生成した仮想コピーである。
このステップＳ４は、ドライバＵＩ関連付け情報保存部５０４の機能と対応する処理である。なお、このドライバＵＩ関連付け情報は、ＵＩモジュールのファイルパス情報から対応するドライバＩＤを特定するための情報としても用いることができる。

図６は、ドライバＵＩ関連付け情報の一つの例を示す図である。
図６において、プリンタドライバ２に利用させるＵＩモジュール（ＵＩ＿１の仮想コピー）のファイルパス「c:\driver\ui2i.exe」が、プリンタドライバ２のドライバＩＤである「Driver ID2」と関連付けられて保存されている。他のプリンタドライバ１，３，４についても同様である。

再度図３の説明に戻ると、ＣＰＵ８１は次に、ステップＳ２で特定したドライバＩＤと、ステップＳ３で作成した仮想コピーのファイルパス情報と、ドライバが利用するＵＩモジュールを特定する情報とを関連付けて、ＯＳに対してＵＩの登録処理を行って（Ｓ５）、処理を終了する。これは、ドライバＵＩ登録部５０５の機能と対応する処理である。
この情報をＯＳに登録することによって、プリンタドライバのＵＩが呼び出されたときに、ＯＳが、そのプリンタドライバのドライバＩＤと対応するファイルパス情報が示すＵＩモジュールを起動するようになる。

以上の処理により、ＣＰＵ８１は、情報処理装置１０に既に登録されている第１のデバイスドライバのＵＩとその第１のデバイスドライバとは異なる第２のデバイスドライバとを関連付けた関連付け情報（ドライバＵＩ関連付け情報）を登録することができる。

図７は、ドライバＵＩ登録情報の態様の一例を示す図である。
図７において、ＩＤがドライバＩＤ、ＵＩがＵＩモジュールのファイルパス情報、ＡｐｐＩＤがＵＩモジュールの識別情報である。
そして、図７の例では、プリンタドライバ２のＡｐｐＩＤは、プリンタドライバ１のＡｐｐＩＤと同じ（ApplicationID1）になっているので、プリンタドライバ２とプリンタドライバ１は（パスは違っても）同じＵＩモジュールを利用することがわかる。すなわち、プリンタドライバ２が呼び出されると、プリンタドライバ１と同じＵＩが表示されることになる。
このドライバＵＩ登録情報は、ＯＳに対して決められた形式で登録する。

なお、図３の処理は、プリンタドライバのインストール時に、インストーラの機能として実行することもできる。この場合、ステップＳ１で選択画面を表示する必要はなく、インストーラによりインストールしたプリンタドライバを、ＵＩ置き換えの対象として選択すればよい。逆に、インストールしたプリンタドライバを、他のどのプリンタドライバに付属のＵＩモジュールと関連付けるかの選択を受け付けるようにするとよい。

次に、図８に、上述したＵＩの置き換え処理における各モジュールの関連を示す。
ここでは、あらかじめプリンタドライバ１とプリンタドライバ２がインストールされていて、プリンタドライバ１にＵＩ＿１が関連付けられている環境を想定する。
この環境において、ＵＩの置き換えを用いて、プリンタドライバ２でもＵＩ＿１を利用できるようにするという、ドライバＵＩ共通化を実現する場合における各モジュールの関連を図８に示した。
なお、図８及び次の図９の説明は、ＣＰＵ８１が各モジュールのプログラムを実行することにより実現される機能を、説明の便宜のため、各モジュールが主体となって種々の動作を実行するように説明する。

図８において、インストーラはプリンタドライバのインストールを行う機能を備えるものであり、プリンタドライバ２及び付属のＵＩモジュールであるＵＩ＿２を情報処理装置１０にインストールした後、以下の（ａ）〜（ｄ）の動作を行う。これらの動作は、図８に当該符号を付して示した矢印と対応する。
（ａ）インストーラは、プリンタドライバ２の構成ファイルからプリンタドライバ２のドライバＩＤを取得する。
（ｂ）インストーラは、実体はＵＩ＿１と同じであるＵＩ＿２という仮想ファイルを作成する。

（ｃ）インストーラは、（ａ）で取得したドライバＩＤと、（ｂ）で作成した仮想ファイルのパスとを対応付けたドライバＵＩ関連付け情報をファイルやレジストリなどに保存する。すでにドライバＵＩ関連付け情報が保存されている場合、これにプリンタドライバ２に関する情報を追記すればよい。
（ｄ）インストーラは、ＯＳに対して、（ａ）のドライバＩＤと（ｂ）で作成した仮想ファイルのパスの情報を登録する。ＯＳは、この登録情報に従って、各プリンタドライバのＵＩを呼び出す。登録の情報の例は図７に示す通りである。
これらの動作は、図３に示した処理と対応するものである。

そしてＯＳは、（ｄ）の後では、プリンタドライバ１のＵＩが開かれたときにはＵＩ＿１を呼び出し、プリンタドライバ２のＵＩが開かれたときにはＵＩ＿２を呼び出す（ｅ）。ただし、ＵＩ＿２はＵＩ＿１の仮想ファイルとして作成されているため、ＵＩ＿２がＯＳから呼び出された場合でも、実体はＵＩ＿１と同じＵＩモジュールが動作することになる。

また、ＵＩ＿１は、ＯＳにより呼び出されると、以下の（ｆ）及び（ｇ）の処理を行う（ＵＩ＿２の呼び出し時も同様である。）。実体として動作するのは一つであるが、ＵＩはＯＳから呼び出された際に、自分がＵＩ＿１と呼び出されたかＵＩ＿２として呼び出されたかということを判断することができる。

（ｆ）ＵＩ＿１は、ドライバＵＩ関連付け情報を読み取り、自分がＵＩ＿１又はＵＩ＿２のどちらとして呼び出されたかという情報（ＵＩモジュールに係るファイルパスがわかる）に基づいて、これと対応するドライバＩＤを判別する。
（ｇ）ＵＩ＿１は、（ｆ）で判別したドライバＩＤを利用して、ＯＳに対してＵＩ表示のためのイベントハンドラの登録を行う。

このイベントハンドラの登録は、ＵＩモジュールが受け付けた設定内容を、どのドライバに関する設定内容として取り扱うかを登録するものである。すなわち、（ｇ）では、ＵＩ＿１が受け付けた設定内容を、（ｆ）で判別したドライバＩＤのプリンタドライバに関する設定内容として取り扱うべき旨を登録する。
これにより、あらかじめプリンタドライバ１とプリンタドライバ２がインストールされていて、プリンタドライバ１にＵＩ＿１が関連付けられている環境においても、プリンタドライバ２でもＵＩ＿１を利用できるようになる。またこのとき、ユーザは、単にプリンタドライバ２（と対応するプリンタ）を選択して、ＵＩを開くことを指示するだけでよい。

ここで、図９に、図８の（ｆ）及び（ｇ）と対応する、置き換えられたＵＩを使用したＵＩ表示時の処理について説明する。
ＣＰＵ８１は、ＯＳからＵＩモジュールの起動が指示されると、ＵＩモジュールのプログラムを実行することにより、図９に示す処理を開始する。この処理において、ＣＰＵ８１はＵＩ制御手段として機能する。
この処理において、ＣＰＵ８１はまず、図３のステップＳ４で保存されたドライバＵＩ関連付け情報（図６参照）を読み出す（Ｓ１１）。

次に、ＣＰＵ８１は、実行中のＵＩモジュール自身のファイルパスを手がかりとして、ステップＳ１１で読み取ったドライバＵＩ関連付け情報のファイルパス情報を参照して、対応するドライバＩＤを取得する（Ｓ１２）。これは、呼び出し元ドライバ判定部５０６の機能と対応する処理である。

例えば、ＵＩ関連付け情報が図６に示した内容であってファイルパスが「c:\driver\ui2i.exe」であれば、対応するドライバＩＤは「Driver ID2」であるとわかる。このドライバＩＤは、ＵＩモジュールの起動を指示したプリンタドライバのＩＤである。また、この特定は、１つのドライバＩＤについて複数のファイルパスが登録されている場合でも可能である。

次に、ＣＰＵ８１は、ステップＳ１２で取得したドライバＩＤを利用して、ＯＳに対してＵＩ表示のためのイベントハンドラの登録を行う（Ｓ１３）。これはドライバイベントハンドラ登録部５０７の機能と対応する処理である。
このイベントハンドラの登録時には、実際に呼び出し元となっているプリンタドライバのドライバＩＤを利用する必要がある。そして、ＯＳは、図３のステップＳ５で登録した情報に基づいてドライバＩＤからファイルパスを特定してＵＩモジュールを起動する。しかし、ドライバＵＩ関連付け情報には、ＯＳへの登録内容と同じ（正確にはこれを包含する）対応関係が記録されているから、ドライバＵＩ関連付け情報を参照することにより、正しいドライバＩＤを利用したイベントハンドラの登録が可能である。

次に、ＣＰＵ８１は、実際のＵＩの画面を表示部３０に表示させて（Ｓ１５）、処理を終了する。このステップＳ１５は、ドライバＵＩ表示部５０８の機能と対応する処理である。
以上の処理により、ＣＰＵ８１は、デバイスドライバに関する設定を受け付ける場合に、関連付け情報によりそのデバイスドライバと関連付けられたＵＩを呼び出して、該ＵＩによりそのデバイスドライバに関する設定を受け付けることができる。

なお、図１０に、ＵＩの置き換え処理における各モジュールの関連の図８と別の形態を示す。
図８では、インストーラがＵＩの置き換えに係る処理を行っているが、図１０の例では、この置き換えに係る処理をプリンタドライバ１行う。図１０の動作においては（ａ）〜（ｄ）の動作を行う主体がプリンタドライバ１である点が図８の例と異なるのみであるので、詳細な説明は省略する。

次に、以上説明してきた実施形態の効果について説明する。
図１１は、以上説明してきた実施形態の効果について説明するための図である。
図１１で、（Ａ）はプリンタドライバ１に付属のＵＩ（ＵＩ＿１）の印刷設定画面であり、（Ｂ）はプリンタドライバ２に付属のＵＩの印刷設定画面である。

両者とも実質的には同じ内容の印刷設定内容であるが、（Ａ）はラジオボタンで選択するのに対し、（Ｂ）は□の中にチェックを入れる方法である。（Ａ）の方法に慣れているユーザにとっては（Ｂ）の画面には違和感を覚えるおそれがある。また、用語も一部異なるため、慣れないユーザにとっては設定内容が理解しづらい可能性がある。

一方、上述した図３等の処理により、プリンタドライバ２をプリンタドライバ１に付属のＵＩと関連付けると、（Ｃ）に示すように、プリンタドライバ２に関する設定の受付を、プリンタドライバ１に付属のＵＩにより行うことができる。その結果、ユーザは統一感のある操作感を得ることができる。またこのとき、関連付けの前と比べて、ＵＩを開くための操作が変わることもない。

なお、各プリンタドライバが制御するプリンタがどのような機能に対応しているかは、そのプリンタの機能を示す機能情報であるPrintCapabilities()を参照する等により、把握可能である。そして、プリンタドライバに付属のＵＩは、制御対象のプリンタが備える機能に係る設定を受け付ける機能を備えていると考えられる。したがって、PrintCapabilities()においてどのような項目についてどのような選択肢があるかを見れば、付属ＵＩにおいて受付可能な設定項目や、その選択肢を把握することができる。

したがって、例えばプリンタドライバ２をプリンタドライバ１に付属のＵＩに関連づける場合、各ドライバの制御対象に関するPrintCapabilities()を比較するとよい。この比較結果から、ＵＩの置き換えにより過剰となる項目、不足となる項目、プリンタドライバ２に適用するに当たり設定内容の変換が必要となる項目等を把握することができる。
プリンタドライバ１に付属のＵＩにより受け付けた設定をプリンタドライバ２で利用するに当たっては、この点を考慮した設定結果の変換を行うようにするとよい。

なお、同様な考え方に基づき、プリンタドライバ１に付属のＵＩを、プリンタドライバ２に関する設定を受け付けるために用いるに際し、ＵＩを加工したり、警告を行ったりすることが考えられる。これらに関する変形例を、図１２乃至図１５に示す。

図１２は、第１の変形例を示す図である。
例えば、置き換え先ＵＩとしてのＵＩ＿１が、両面、集約及びステープルの各機能をサポートしているが（Ａ）、置換え元ドライバ（プリンタドライバ２）では、両面及び集約の機能のみをサポートし（Ｂ）、ステープル機能はサポートしていない場合を想定する。
そうすると、ＵＩ＿１をそのままプリンタドライバ２のＵＩとして共用した場合、プリンタドライバ２がサポートしていないステープル機能に関する設定受付部までが表示されてしまうという不都合が生じる。

そこで、プリンタドライバ２が（ＯＳを介して）ＵＩ＿１を呼び出す場合、ＵＩ＿１が設定受付可能な項目のうち、プリンタドライバ２がサポートしていない機能（ここではステープル機能）に関する項目を無効にして表示させないようにするとよい（Ｃ）。
このようにすれば、実際には使えない機能に関する設定受付部を表示することがなく、ＵＩの統一感を保ったまま、ユーザに無用な混乱を生じさせないようにすることができる。
なお、ＵＩモジュールにおいて、画面データが構造化言語で記載されていれば、該当項目についての記載を削除することにより、容易に項目の無効化（非表示化）を行うことができる。プリンタドライバをＵＩモジュールに関連付ける際に、ＵＩモジュールの実体をコピーするとともに、ＵＩモジュールに含まれる画面データにこのような加工を施すとよい。

図１３は、第２の変形例を示す図である。
例えば、置き換え先ＵＩとしてのＵＩ＿１が、両面、集約及びステープルの各機能をサポートしているが（Ａ）、置換え元ドライバ（プリンタドライバ２）では、両面、集約、ステープル及びウォーターマークの各機能をサポートしている場合（Ｂ）を想定する。
そうすると、ウォーターマーク機能は置き換え先ＵＩがサポートしていないため、置換え後のＵＩではウォーターマーク機能に関する設定を受け付けることができないという不都合が生じる（Ｃ）。

そこで、このような場合、プリンタドライバ２にＵＩ＿１を関連付けるときに、プリンタドライバ２が対応している機能のうち、置き換え先ＵＩが設定を受け付けることができない機能（ここではウォーターマーク機能）につき、その機能が利用できないことをユーザに通知するようにするとよい。この通知には、（Ｄ）に示すようなダイアログを用いることができる。

このようにすれば、ＵＩ置き換え前のプリンタドライバが対応していた機能が知らないうちに使えなくなるということを防止し、ＵＩの統一感を保ったまま、ユーザに無用な混乱を生じさせないようにすることができる。
上記ダイアログの表示は、例えば図３に示した処理の間に行うことが考えられる。しかし、プリンタドライバをＵＩモジュールに関連付ける際に、ＵＩモジュールの実体をコピーするとともに、ＵＩモジュールにダイアログ表示機能を追加し、ＵＩモジュールを起動するたびにダイアログが表示されるようにしてもよい。

図１４は、第３の変形例を示す図である。
この第３の変形例は、表示するダイアログが第２の変形例と異なるのみである。
ここでは、図３に示した処理の間に、（Ｄ）に示すダイアログにおいて、ＵＩの置き換えを行うか否かの指示を受け付けるようにしている。そして、キャンセル（行わない）の指示があった場合、図３に示す処理を中止し、プリンタドライバ２にＵＩ＿１を関連付ける関連付け情報の登録を中止するようにしている。
このようにすれば、プリンタドライバ２の一部の機能が使えなくなることを嫌うユーザが、誤ってＵＩの切り換えを行ってしまうことを防止できる。

図１５は、第４の変形例を示す図である。
この第４の変形例も、機能の想定は第２及び第３の変形例と同じである。
しかし、第４の変形例では、プリンタドライバ２が対応している機能のうち、置き換え先ＵＩが設定を受け付けることができない機能（ここではウォーターマーク機能）につき、その機能に関する設定を受け付けるための項目を、置き換え先ＵＩに追加する。

追加すべき機能が特定されれば、その機能に関するPrintCapabilities()を参照することにより、該機能で受け付けるべき選択肢や適切な操作部の構成（チェックボックスかラジオボタンか等）を把握できる。そして、予めPrintCapabilities()からＵＩを生成するスタイルシートを用意しておけば、これに従って、追加すべき機能に係るＵＩを自動生成することができる。

そして、例えば、（Ｃ）及び（Ｄ）に示すように、ＵＩ＿１の機能に係る画面を標準画面、追加すべき機能に係る画面を追加画面として、これらをタブで切り替えられるようにすればよい。
プリンタドライバをＵＩモジュールに関連付ける際に、ＵＩモジュールの実体をコピーするとともに、ＵＩモジュールに含まれる画面データにこのような加工を施すとよい。
この加工を行う場合に、ＣＰＵ８１は追加手段として機能する。
このようにすれば、ＵＩの統一感をある程度維持しつつ、置き換え先のＵＩが対応していない機能に関する設定も受け付けることができる。

以上で実施形態の説明を終了するが、この発明において、各装置の具体的な構成、処理の内容、データの構成、画面の表示内容等は、実施形態で説明したものに限るものではない。
また、上述した実施形態の情報処理装置と、該情報処理装置が備えるデバイスドライバにより制御されるデバイスとで、情報処理システムを構成すると捉えることができる。さらに、そのデバイスドライバと制御対象のデバイスとでも、これらの相互作用により、統一感のあるＵＩによるデバイスの制御という有用な効果を発揮し、情報処理システムを構成すると捉えることができる。
また、上述の実施形態におけるデバイスドライバによる制御の対象に特に制約はなく、任意のデバイスでよい。

また、情報処理装置１０の機能を、複数の装置に分散して設け、これらの装置に協働してその機能を実現させるようにしてもよい。逆に、情報処理装置１０が、デバイスドライバによる制御対象のデバイスを内蔵していてもよい。
さらに、以上説明した各実施形態、動作及び変形例の構成は、相互に矛盾しない限り任意に組み合わせて実施可能であることはもちろんである。

１０：情報処理装置、２０：入力部、３０：表示部、４０：記憶部、５０：ドライバ選択制御部、６０：プリンタドライバ、７０：ドライバＵＩ、８０：制御部、９０：プリンタ、５０１：ＵＩ変更ドライバ選択部、５０２：ドライバＩＤ探索部、５０３：ドライバＵＩ仮想複製部、５０４：ドライバＵＩ関連付け情報保存部、５０５：ドライバＵＩ登録部、５０６：呼び出し元ドライバ判定部、５０７：ドライバイベントハンドラ登録部、５０８：ドライバＵＩ表示部

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

Claims (9)

1. 情報処理装置であって、
   前記情報処理装置に既に登録されている第１のデバイスドライバのユーザインタフェースと前記第１のデバイスドライバとは異なる第２のデバイスドライバとを関連付けた関連付け情報を登録するＵＩ登録手段と、
   前記第２のデバイスドライバに関する設定を受け付ける場合に、前記関連付け情報により該第２のデバイスドライバと関連付けられた前記第１のデバイスドライバのユーザインタフェースを呼び出して、該ユーザインタフェースにより前記第２のデバイスドライバに関する設定を受け付けるＵＩ制御手段と、
   を備えたことを特徴とする情報処理装置。
2. 請求項１に記載の情報処理装置であって、
   前記ＵＩ登録手段が、前記第１のデバイスドライバのユーザインタフェースの仮想コピーを生成し、前記関連付け情報において、該仮想コピーと前記第２のデバイスドライバとを関連付けることを特徴とする情報処理装置。
3. 請求項１又は２に記載の情報処理装置であって、
   前記第１のデバイスドライバのユーザインタフェースが呼び出された場合に、
   前記ＵＩ制御手段が、前記関連付け情報に基づき、どのデバイスドライバに関する設定を受け付けるために呼び出されたかを特定し、前記受け付けた設定内容を、前記特定されたデバイスドライバに関する設定内容として取り扱うことを特徴とする情報処理装置。
4. 請求項１乃至３のいずれか一項に記載の情報処理装置であって、
   前記第１のデバイスドライバのユーザインタフェースが設定を受け付ける項目を示す情報と、前記第２のデバイスドライバが対応している機能を示す情報とに基づき、前記第１のデバイスドライバのユーザインタフェースのうち、前記第２のデバイスドライバが対応していない機能に関する項目を無効にする手段を備えることを特徴とする情報処理装置。
5. 請求項１乃至４のいずれか一項に記載の情報処理装置であって、
   前記第１のデバイスドライバのユーザインタフェースが設定を受け付ける項目を示す情報と、前記第２のデバイスドライバが対応している機能を示す情報とに基づき、前記第２のデバイスドライバが対応している機能のうち、前記第１のデバイスドライバのユーザインタフェースが設定を受け付けることができない機能がある場合に、その機能が利用できない旨をユーザに通知する通知手段を備えることを特徴とする情報処理装置。
6. 請求項１乃至４のいずれか一項に記載の情報処理装置であって、
   前記第１のデバイスドライバのユーザインタフェースが設定を受け付ける項目を示す情報と、前記第２のデバイスドライバが対応している機能を示す情報とに基づき、前記第２のデバイスドライバが対応している機能のうち、前記第１のデバイスドライバのユーザインタフェースが設定を受け付けることができない機能がある場合に、ユーザから前記関連付け情報の登録を中止するか否かの選択を受け付ける手段を備えることを特徴とする情報処理装置。
7. 請求項１乃至４のいずれか一項に記載の情報処理装置であって、
   前記第１のデバイスドライバのユーザインタフェースが設定を受け付ける項目を示す情報と、前記第２のデバイスドライバが対応している機能を示す機能情報とに基づき、前記第２のデバイスドライバが対応している機能のうち、前記第１のデバイスドライバのユーザインタフェースが設定を受け付けることができない機能がある場合に、前記機能情報に基づき、その機能に関する設定を受け付けるための項目を、前記ユーザインタフェースに追加する追加手段を備えることを特徴とする情報処理装置。
8. 情報処理装置にデバイスを制御する第１のデバイスドライバの機能を実現させるためのプログラムであって、
   前記コンピュータを、
   前記情報処理装置に既に登録されている前記第１のデバイスドライバのユーザインタフェースと前記第１のデバイスドライバとは異なる第２のデバイスドライバとを関連付けた関連付け情報を登録するＵＩ登録手段と、
   前記第１のデバイスドライバのユーザインタフェースが起動された場合に、前記関連付け情報に基づき、どのデバイスドライバに関する設定を受け付けるために呼び出されたかを特定し、前記受け付けた設定内容を、前記特定されたデバイスドライバに関する設定内容として取り扱うＵＩ制御手段として機能させるためのプログラム。
9. コンピュータを、
   既に該コンピュータに登録されている第１のデバイスドライバのユーザインタフェースと、前記第１のデバイスドライバと異なる第２のデバイスドライバとを関連付けた関連付け情報を登録するＵＩ登録手段と、
   前記第２のデバイスドライバに関する設定を受け付ける場合に、前記関連付け情報により該第２のデバイスドライバと関連付けられた前記第１のデバイスドライバのユーザインタフェースを呼び出して該ユーザインタフェースにより前記第２のデバイスドライバに関する設定を受け付けるＵＩ制御手段として機能させるためのプログラムと、
   前記第２のデバイスドライバにより制御されるデバイスと、
   を備えたシステム。

Images