JP6784538B2 - 情報処理装置、方法およびプログラム - Google Patents

Description

本発明は、プリンタドライバが実装された情報処理装置、方法およびプログラムに関する。

プリンタドライバにおいては、ユーザインタフェースモジュールの有する機能を外部のアプリケーションから利用するために、ＯＳ標準ではない独自インタフェースが使用されている。プリンタドライバの機能には、「プリンタドライバの印刷設定を変更するための機能」と「直接印刷には関わらない機能」の２種類がある。後者の例として、プリンタを最適な状態に保つためのメンテナンス機能などがある。

昨今、Ｖ４と呼ばれる新しいプリンタドライバのアーキテクチャが定義されている。外部アプリケーションからプリンタドライバの印刷設定を変更する機能が標準機能として搭載される一方で、上記の独自インタフェースの使用や、印刷ジョブとしてメンテナンスコマンドを扱うことが制限されるようになった。このため、従来のＶ３プリンタドライバ（以後、Ｖ３ドライバ）で提供していた機能のうち、「直接印刷には関わらない機能」をアプリケーションから利用することが困難となっている。

上記の課題を解決する方法として、例えばプリンタドライバとは別の、プリンタに直接印刷には関わらない機能を実行させるような専用のアプリケーションを用いることが考えられる。しかしながら、一般的にプリンタのメンテナンス機能は、プリンタの機種毎に、その内部処理やプリンタ本体に送信するコマンドが異なっている。また、コマンドの送信をするにあたり、ＵＳＢやＷｉｆｉ、ＬＡＮなどの複数のＩ／Ｆに対応する必要性がある。そのため、プリンタドライバによる機種毎の差やＩ／Ｆの隠ぺいを利用せずに、上記のような専用アプリケーションを構築しようとすると、特定のプリンタ機種専用のアプリケーションをプリンタの数だけ開発する必要が生じる。その結果、実現のための実装やメンテナンスに極めて工数がかかってしまう。また、プリンタドライバが所有する、コマンドなどのプリンタの機種毎の差を示すプリンタ固有情報には、プリンタドライバ以外からはアクセスできないように制限されている。そのため、アプリケーションは、プリンタドライバを介することなく、プリンタドライバが所有するプリンタ固有情報を利用することができない。

以上の理由から、プリンタドライバを介することなく、プリンタと通信を行う専用のアプリケーションを用意することは実用的ではない。遠隔にあるコンピュータ（以後、サーバ）に接続されたプリンタに対して、アプリケーションがインストールされたサーバとは別のコンピュータ（以後、クライアント）からコマンドを発行するといった、クライアントが間接的にプリンタと接続される場合がある。このような場合において、クライアントのアプリケーションは、サーバ側のプリンタと直接通信を行うことができないため、上記のような専用アプリケーションによってプリンタドライバを経由することなくプリンタにコマンドを発行することができない。

特許文献１では、プリンタドライバと密に対応づけられたアプリケーションとポートモニタを用いて、Ｖ４アーキテクチャにおいても、メンテナンス機能の実行を可能としている。

特開２０１３−１６８０１７号公報

しかしながら、アプリケーションは、プリンタドライバやポートモニタと密に連携する構成とする必要があり、様々なアプリケーションにおける実現は難しい。また、メンテナンス機能の実行といった印刷装置へのコマンドの送信に限られてしまう。

本発明の目的は、このような従来の問題点を解決することにある。上記の点に鑑み、本発明は、プリンタドライバでの多様な機能を実行可能とするとともに、構成の簡易化を実現する情報処理装置、方法およびプログラムを提供することを目的とする。

上記課題を解決するため、本発明に係る情報処理装置は、アプリケーションとプリンタドライバとを有する情報処理装置であって、前記アプリケーションにおいて、前記プリンタドライバに係る印刷とは異なる機能の実行の命令を受信する受信手段と、前記アプリケーションにおいて、前記受信手段により受信した前記命令をプリントチケットに設定し、当該プリントチケットをＯＳに渡す設定手段と、前記アプリケーションにおいて、前記ＯＳを介して前記プリンタドライバを呼び出す呼出手段と、前記呼出手段により呼び出された前記プリンタドライバにおいて、前記設定手段により前記命令が設定されたプリントチケットを前記ＯＳから取得する取得手段と、前記呼出手段により呼び出された前記プリンタドライバにおいて、前記取得手段により取得したプリントチケットに設定されている前記命令に基づいて前記機能を実行する実行手段と、を有し、前記機能は、印刷機能と異なる機能であり、前記呼出手段は、前記プリンタドライバに用意された第１のインタフェースモジュールを呼び出し、前記第１のインタフェースモジュールは、第２のインタフェースモジュールを呼び出し、前記第２のインタフェースモジュールは、前記機能を実行するための情報を記憶する記憶部から、当該情報を取得する、ことを特徴とする。

本発明によれば、プリンタドライバでの多様な機能を実行可能とするとともに、構成の簡易化を実現することができる。

印刷システムのハードウェア構成を示すブロック図。 Ｖ３プリンタドライバを含むモジュール構成を示す図。 Ｖ４プリンタドライバを含むモジュール構成を示す図。 プリンタドライバにおけるメンテナンス処理の流れを示す図。 アプリケーションの処理を示すフローチャート。 メンテナンスＳＤＫ Ｗｒａｐｐｅｒの処理を示すフローチャート。 ＵＩ拡張モジュールの処理を示すフローチャート。 プリントチケットを示す図。 アプリケーションの処理を示すフローチャート。 メンテナンスＳＤＫ Ｗｒａｐｐｅｒの処理を示すフローチャート。 ＵＩ拡張モジュールの処理を示すフローチャート。 アプリケーションの処理を示すフローチャート。 メンテナンスＳＤＫ Ｗｒａｐｐｅｒの処理を示すフローチャート。 ＵＩ拡張モジュールの処理を示すフローチャート。 ＵＩ拡張モジュールの基本設定タブシートを選択した状態を示す図。 ＵＩ拡張モジュールのメンテナンスタブシートを選択した状態を示す図。 アプリケーションの処理を示すフローチャート。 メンテナンスＳＤＫ Ｗｒａｐｐｅｒの処理を示すフローチャート。 ＵＩ拡張モジュールの処理を示すフローチャート。

以下、添付図面を参照して本発明の実施形態を詳しく説明する。尚、以下の実施形態は特許請求の範囲に係る本発明を限定するものでなく、また本実施形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。なお、同一の構成要素には同一の参照番号を付して、説明を省略する。

［第１の実施形態］
［ハードウェア構成］
図１は、情報処理装置１１０と、情報処理装置１１０に接続された印刷装置１２０とを含んで構成される印刷システムの全体構成を示すブロック図である。情報処理装置１１０は、入力インタフェース（Ｉ／Ｆ）１１１、ＣＰＵ１１２、ＲＯＭ１１３、出力Ｉ／Ｆ１１４、外部記憶装置１１５、ＲＡＭ１１６、入力装置１１７、出力装置１１８、入出力Ｉ／Ｆ１１９を有する。ＲＯＭ１１３は、初期化プログラムを保存し、外部記憶装置１１５は、ＯＳ、プリンタドライバ、アプリケーションといったプログラムやその他各種のデータが保存されている。ＲＡＭ１１６は、外部記憶装置１１５に保存される各種プログラムがワークメモリとして使用される。入力装置１１７は、ポインティングデバイスやキーボードのほかに、タッチパネル等で構成され、データ入力や動作指示に使用され、入力Ｉ／Ｆ１１１に接続されている。出力装置１１８は、データ表示や状態の通知に使用され、出力Ｉ／Ｆ１１４に接続されている。ＣＰＵ１１２は、ＲＯＭ１１３に保存されている制御命令に従い、情報処理装置１１０を制御する。例えば、以下の各実施形態のフローチャートの処理は、例えば、ＣＰＵ１１２がＲＯＭ１１３に記憶されたプログラムをＲＡＭ１１６に読み出して実行することにより実現される。

印刷装置１２０は、ＲＡＭ１２１、ＲＯＭ１２２、プリントエンジン１２３、ＣＰＵ１２４、入出力Ｉ／Ｆ１２５を有する。情報処理装置１１０と印刷装置１２０は、ＵＳＢケーブルやネットワークケーブル等により接続されている。ＲＡＭ１２１は、ＣＰＵ１２４のワーキングメモリとして使用され、受信したデータの一時保存用バッファとしても用いられる。ＲＯＭ１２２は、制御命令などを記憶する。プリントエンジン１２３は、ＲＡＭ１２１に保存されたデータに基づき印刷を行う。ＣＰＵ１２４は、ＲＯＭ１２２に保存されている制御命令に従い、印刷装置１２０を制御する。

情報処理装置１１０と印刷装置１２０は、有線や無線のネットワーク１３０を介して相互に通信可能に接続されている。本実施形態においては、情報処理装置１１０および印刷装置１２０の処理分担を上記のように示したが、処理の分担の形態はこれに限られない。

［メンテナンスＳＤＫ Ｗｒａｐｐｅｒ］
本実施形態では、メンテナンス機能を所望するアプリケーションからメンテナンス機能の実行を代行するメンテナンスＳＤＫ及びその外部インタフェースを備えるメンテナンスＳＤＫ Ｗｒａｐｐｅｒというアプリケーションが用意される。メンテナンス機能には、記録ヘッドのクリーニングや記録ヘッドの位置調整、ノズルチェックパターン印刷、電源のオフなどの実印刷に関わらない機能が含まれる。メンテナンス機能を所望するアプリケーションは、メンテナンスＳＤＫ Ｗｒａｐｐｅｒを介してメンテナンス機能を実行する。これにより、メンテナンス機能を実行したいアプリケーションは、印刷装置及びドライバアーキテクチャの仕様を知らなくとも、ベンダーが定義したＡＰＩを使用するだけで容易にメンテナンス機能の実行が可能となる。

［Ｖ３ドライバでのメンテナンス処理フロー］
ここでは、図２を用いて、印刷システムであるＶ３ドライバ上で実現されるメンテナンス機能の処理のフローについて説明する。プリンタドライバＵＩ部２１０において、メンテナンス機能に関係する構成は、ＵＩモジュール２１２、メンテナンス処理部２１３及びメンテナンス情報データベース２１６である。メンテナンスＡＰＩは、外部アプリケーションからアクセス可能なインタフェースとして定義されており、外部アプリケーションが自由にアクセスできるインタフェースである。メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１が、アプリケーション２００からの命令に応じて、メンテナンスＡＰＩを用いてその命令に対応する命令を発行することで、メンテナンス機能を実行する。メンテナンスＡＰＩ処理部２１１は、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１からのメンテナンスＡＰＩを介して発行された命令に応じたメンテナンスコマンド実行命令をＵＩモジュール２１２に発行する。

ＵＩモジュール２１２は、メンテナンス処理部２１３に対して、メンテナンスコマンド実行命令に対応するメンテナンスコマンドをメンテナンス処理部２１３に発行する。メンテナンス処理部２１３は、発行されたメンテナンスコマンドをメンテナンス情報データベース２１６と照合を行い、印刷装置１２０に対応するメンテナンスコマンドをメンテナンス情報データベース２１６から取得する。

次に、メンテナンス処理部２１３は、印刷装置１２０へ対応するメンテナンスコマンド２１４を送信する。次に、印刷装置１２０によるメンテナンス機能の実行後、メンテナンス処理部２１３は、印刷装置１２０からメンテナンス機能実行結果を示す旨の情報２１５を受け取り、ＵＩモジュール２１２に返す。最後に、ＵＩモジュール２１２は、メンテナンス機能実行結果をメンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１に返す。

以上が、Ｖ３ドライバ上でのメンテナンス機能の処理のフローであり、ドライバＵＩ部２１０に独自のＡＰＩを用意することで、容易にメンテナンス機能の実行を可能としている。

［Ｖ４プリンタドライバの印刷システム］
図３を用いて、情報処理装置１１０のＯＳとしてＭｉｃｒｏｓｏｆｔ社のＷｉｎｄｏｗｓを用いているものとし、ドライバアーキテクチャとしてＶ４アーキテクチャを使用したＶ４プリンタドライバを用いた印刷システムを説明する。

アプリケーション２００には、画像処理、ワードプロセッサ、ウェブブラウザなどのソフトウェアや、他のアプリケーションへのＩ／Ｆを備え、他のアプリケーションからの要求に応じた印刷装置やプリンタドライバへの命令を生成するソフトウェアが含まれる。アプリケーション２００は、描画命令で構成された描画命令群をＯＳに発行する。描画命令には、例えばテキスト描画命令、グラフィクス描画命令、イメージ描画命令が含まれる。

ＯＳは、アプリケーション２００から発行される各種描画命令をＯＳの印刷サポート機能３１１を介してスプールデータに変換する。変換後のスプールデータは、スプーラ３１２のプリントキュー３１３に一時的に蓄えられ、印刷ジョブ３１４としてスプーラ３１２により管理される。印刷ジョブ３１４は、プリンタドライバ３２０によって印刷装置１２０が解析可能な印刷データに変換された後に、印刷装置１２０に提供され、印刷装置１２０で印刷が行われるように構成されている。

プリンタドライバ３２０に渡された印刷ジョブ３１４は、まず、レイアウトフィルター３２２によって処理される。ここで、フィルターとは、入力されたデータをもとに、加工、変換、無変換、生成等の工程を介して、何らかのデータを出力する機能を有するプログラム（モジュール）のことである。各フィルターは、印刷ジョブ３１４のデスプール時に不図示のＯＳのフィルター管理機能から呼び出され、初期化が行なわれる。レイアウトフィルター３２２は、印刷設定情報に従って印刷ジョブ３１４のページを並べ替えたり複数のページを１つのページにまとめたりするページ構成処理を、印刷ジョブ３１４に対して行う。

次に、印刷ジョブ３１４は、レンダーフィルター３２３によって処理される。レンダーフィルター３２３は、印刷設定情報に従って印刷ジョブ３１４を変換し、印刷装置１２０が解釈可能な印刷データを生成する。そして、レンダーフィルター３２３が生成した印刷データは、ポートモニタ３３１を介して印刷装置１２０へ送信される。

アプリケーション２００は、ユーザによる入力デバイスの操作に基づき印刷を開始する指示を行う際、ＯＳの印刷サポート機能３１１を介して、ユーザインタフェース（以後、ＵＩ）モジュール３２１から返却された印刷設定情報を印刷ジョブ３１４に付加する。Ｖ４アーキテクチャでは、印刷設定情報を記述するものとしてプリントチケット（ＰｒｉｎｔＴｉｃｋｅｔ）を使用している。印刷設定情報には、例えば、用紙サイズや用紙の種類、画像処理パラメータ等が含まれる。

ＵＩモジュール３２１は、ＯＳが提供するモジュールであり、Ｖ４アーキテクチャ下では機能が限定されている。このため、Ｖ４アーキテクチャの制限下では、プリンタドライバ３２０は、Ｖ３ドライバで行っていたメンテナンスＡＰＩのような外部インタフェースをドライバＵＩ部に設けることができない。従って、ＵＩモジュール３２１に対して、アプリケーション２００は、印刷設定情報以外の情報を渡すことができない。ＵＩ拡張モジュール３２４は、ベンダーがＵＩの機能を拡張することができるためのモジュールである。

図１の記憶部内のキュープロパティバッグ３１５に対して、ＵＩ拡張モジュール３２４やレンダーフィルター３２３は、ＵＩ拡張モジュールで設定した値の読み込み・書き込みを行い、キュープロパティバッグ３１５は、その値の保存を行う。ドライバプロパティバッグ３１６（以後、ＤＰＢ）は、機種に依存する情報を保存する。ユーザプロパティバッグ３１７は、ＯＳのユーザのアカウントに依存する設定値を保存する。

［Ｖ４プリンタドライバでのメンテナンス処理フロー］
以下、図４を用いて、Ｖ４アーキテクチャの制限下で、本実施形態におけるメンテナンス処理を実現するための構成について説明する。

図４は、本実施形態におけるメンテナンス処理を実現するための構成を示す図である。前述したように、Ｖ４アーキテクチャでは、ＯＳが提供するＵＩモジュール３２１を用いるため、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１は、Ｖ３ドライバのように独自のＡＰＩを使うことができない。そこで、本実施形態では、Ｖ４アーキテクチャにおいて印刷設定情報を記述するものであるＰｒｉｎｔＴｉｃｋｅｔを拡張する。本実施形態では、ＰｒｉｎｔＴｉｃｋｅｔは、印刷設定情報の１つとして、メンテナンス処理を実行する旨を示す情報や、印刷装置１２０が使用可能なメンテナンス機能一覧を取得する旨を示す情報を有する。これにより、印刷設定情報以外の情報をＵＩモジュール３２１及びＵＩ拡張モジュール３２４に渡すことが可能となる。

アプリケーション２００は、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１に指示し、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１は、メンテナンスの実行命令を付加したＰｒｉｎｔ Ｔｉｃｋｅｔを、ＯＳを介して標準ＵＩモジュール３２１に送る。標準ＵＩモジュール３２１は、ＵＩ拡張モジュール３２４を呼出す。ＵＩ拡張モジュール３２４は、ＯＳより取得したＰｒｉｎｔＴｉｃｋｅｔを参照し、メンテナンスの実行命令に対応するメンテナンスコマンド２１４を、印刷装置１２０の能力、コマンドなどの機種依存情報が格納されたＤＰＢ３１６から取得する。ＵＩ拡張モジュール３２４は、メンテナンスコマンド２１４を、印刷装置１２０に送信する。

尚、Ｖ４アーキテクチャにおいては、ＤＰＢ３１６へのアクセス方法は制限されている。つまり、アプリケーション２００やメンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１、及びＯＳを介して呼び出されるＵＩモジュール３２１から起動されていないＵＩ拡張モジュール３２４は、ＤＰＢ３１６へのアクセスは不可とされている。そこで、本実施形態では、ＤＰＢ３１６から印刷装置１２０に依存する情報を取得するために、Ｄｏｃｕｍｅｎｔ Ｐｒｏｐｅｒｔｉｅｓを用いてプリンタドライバ３２０を呼び出す。そして、標準ＵＩモジュール３２１により起動されたＵＩ拡張モジュール３２４からＤＰＢ３１６にアクセスしている。このように、本実施形態では、プリンタドライバを介することにより、ＵＩ拡張モジュール３２４がＤＰＢ３１６を使用して印刷装置１２０へのコマンドを取得、送信する。そのため、アプリケーション２００及びメンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１は、コマンドなどの、プリンタドライバ３２０や印刷装置１２０固有の情報を知ることなく、印刷装置１２０のメンテナンス機能を実行することができる。

印刷装置１２０によるメンテナンス機能の実行後、ＵＩ拡張モジュール３２４は、印刷装置１２０よりメンテナンス機能実行結果を示す旨の情報２１５を受け取り、ＵＩモジュール３２１に返す。

以上により、Ｖ４アーキテクチャの制限下においても、アプリケーション２００からメンテナンス機能の実行が可能となる。以下、フローチャートを用いて、本実施形態の動作の詳細について説明する。

［アプリケーションから見たメンテナンス機能実行時の全体の処理の説明］
図５は、本実施形態におけるアプリケーション２００の処理を示すフローチャートである。図６は、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１がアプリケーション２００からメンテナンスＳＤＫを実行可能であるかを確認された際の、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１の処理を示すフローチャートである。アプリケーション２００からメンテナンス機能を実行する際のアプリケーション２００の処理について説明する。

まず、アプリケーション２００は、ＯＳ標準のＡＰＩを使用してメンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１のフルパスを取得し、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１を読み込む。そして、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１に問い合わせ、メンテナンスＳＤＫが使用可能であるか否かを判定する（Ｓ５０１）。アプリケーション２００は、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１の図６の処理を経て、判定を行う。

アプリケーション２００からメンテナンスＳＤＫに対する上記のような確認を含む通信方法は、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１に、例えばＡＰＩのような外部インタフェースを設けるようにしても良い。その場合、アプリケーション２００が予め決められた確認要求命令を発行することにより行われる。

Ｓ５０１でメンテナンスＳＤＫが使用可能であると判定された場合、アプリケーション２００は、印刷装置１２０がサポートするメンテナンス機能一覧取得命令をメンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１に発行する（Ｓ５０２）。これにより、Ｖ４プリンタドライバでは独自のＡＰＩを持つことができないという制限を回避することができる。一方、メンテナンスＳＤＫが使用可能でないと判定された場合、図５の処理を終了する。

アプリケーション２００は、メンテナンス機能一覧取得命令を発行後、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１から印刷装置１２０がサポートするメンテナンス機能一覧を受け取る。アプリケーション２００は、メンテナンス機能一覧から任意のメンテナンス機能を選択し、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１に対して、指定のメンテナンス機能を実行する旨の命令を送る（Ｓ５０３）。メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１の処理が完了後、アプリケーション２００は、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１からメンテナンス処理の実行結果を受け取り（Ｓ５０４）、図５の処理を終了する。

［メンテナンスＳＤＫ使用可否の確認時の処理フロー］
次に、図６を用いて、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１がアプリケーション２００からメンテナンスＳＤＫを実行可能であるかを確認された際の、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１の処理について説明する。まず、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１は、ＵＩ拡張モジュール３２４の存在の有無について記述された記憶領域を参照して、ＵＩ拡張モジュール３２４が存在するか否かを確認し判定する（Ｓ６０１、Ｓ６０２）。

Ｓ６０２でＵＩ拡張モジュール３２４が存在すると判定された場合、存在する旨の情報を処理の結果としてアプリケーション２００に返す（Ｓ６０３）。一方、存在しないと判定された場合、存在しない旨の情報を処理の結果としてアプリケーション２００に返し（Ｓ６０４）、図６の処理を終了する。Ｓ５０1の判定は、図６の結果を用いて行われる。

［メンテナンス機能一覧取得時の処理フロー］
アプリケーション２００がメンテナンス機能の一覧取得命令をメンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１に発行する際の、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１の処理フローについて説明する。図７は、アプリケーション２００からメンテナンス機能の一覧取得命令を受け取った際の、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１の処理を示すフローチャートである。図８は、印刷設定以外の情報を記述したＰｒｉｎｔＴｉｃｋｅｔの例を示す図であり、本実施形態では、メンテナンス機能一覧を取得するために使用する。

メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１は、ＯＳからＰｒｉｎｔＴｉｃｋｅｔを取得する。そして、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１からの命令の種類を表すためにタグ８０１を使用し、メンテナンス機能一覧の取得を表す値を値８０２に設定し、ＯＳにＰｒｉｎｔＴｉｃｋｅｔを返却する（Ｓ７０１）。

次に、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１は、ＤｏｃｕｍｅｎｔＰｒｏｐｅｒｔｉｅｓをコールすることにより、ＯＳを介して標準ＵＩモジュール３２１及びＵＩ拡張モジュール３２４を呼び出す（Ｓ７０２）。ＵＩ拡張モジュール３２４での処理後、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１は、ＰｒｉｎｔＴｉｃｋｅｔをＯＳから取得する。メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１は、ＵＩ拡張モジュール３２４によってＰｒｉｎｔＴｉｃｋｅｔに記述された、ＵＩ拡張モジュール３２４の処理結果を表すタグ８０３に含まれる値８０４を参照し、メンテナンス機能一覧を取得する（Ｓ７０３）。

そして、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１は、メンテナンス機能一覧を作成して（Ｓ７０４）、処理の結果として、アプリケーション２００に返し（Ｓ７０５）、図７の処理を終了する。

上記のＤｏｃｕｍｅｎｔＰｒｏｐｅｒｔｉｅｓは、ＯＳ標準のＡＰＩであり、これ以外でドライバＵＩを呼び出すことはできない。また、Ｖ４プリンタドライバの制限により、独自インタフェースを用いることもできない。従って、ＯＳを介してドライバＵＩを呼び出す場合、アプリケーション２００やメンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１は、印刷設定などの既定の情報以外をドライバＵＩに渡すことはできない。そこで、本実施形態では、上記のように、印刷設定情報を記述するためのＰｒｉｎｔＴｉｃｋｅｔに、印刷設定情報以外の情報を含めることにより、ドライバＵＩに対して既定の情報以外の情報を渡すことを可能としている。

尚、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１がＰｒｉｎｔＴｉｃｋｅｔ内の値８０２に設定するメンテナンス機能一覧の取得を表す値は、数字であっても良いし、文字列であっても良い。また、アプリケーション２００に結果として返すメンテナンス機能一覧は、文字列であっても良いし、予め取り決められた値であっても良い。同様に、ＰｒｉｎｔＴｉｃｋｅｔ内の結果を格納するためのタグ及び値は、予め複数種類のタグを用意しておくことも可能である。これにより、任意の数の結果を返せる他、別の手法として、何らかの区切り文字を用いることで１つのタグのみで複数の値を結果として返すようにしても良い。メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１がアプリケーション２００へ結果を返す方法は、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１のモジュールの戻り値であっても良いし、外部ファイルを介しても良い。

次に、図９を用いて、メンテナンス機能一覧を取得する際のＵＩ拡張モジュール３２４の処理フローについて説明する。

ＤｏｃｕｍｅｎｔＰｒｏｐｅｒｔｉｅｓのコールによって起動されたＵＩ拡張モジュール３２４は、ＰｒｉｎｔＴｉｃｋｅｔを参照する（Ｓ９０１）。そして、メンテナンス機能一覧を取得する旨の情報であるタグ８０１が含まれているか否かを確認し、判定する（Ｓ９０２）。メンテナンス機能一覧を取得する旨の情報が含まれていると判定された場合、ＵＩ拡張モジュール３２４を非表示とし（Ｓ９０３）、印刷装置１２０がサポートするメンテナンス機能一覧をＤＰＢ３１６から取得する。

ＵＩ拡張モジュール３２４とメンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１、あるいはＵＩ拡張モジュール３２４とアプリケーション２００の間では、互いに直接アクセスすることができない。従って、ＵＩ拡張モジュール３２４は、取得したメンテナンス機能一覧を、ＵＩ拡張モジュール３２４の結果を示す値をタグ８０３の値８０４に記述して、ＰｒｉｎｔＴｉｃｋｅｔをＯＳに返却する（Ｓ９０４）。

メンテナンス機能一覧を取得する場合は、ドライバＵＩの表示およびユーザの操作は不要である。ＵＩを表示すると、かえってアプリケーション２００が意図しない情報をユーザに表示してしまうことから、ユーザの混乱を招く可能性がある。そこで、本実施形態では、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１がメンテナンス機能一覧を取得する場合を判断してＵＩを非表示にすることで、上記のような問題を回避することができる。また、アプリケーション２００側で、実行するメンテナンス機能に応じて、アプリケーション２００のＵＩの表示を切り替える、といったような構成としても良い。

Ｓ９０２でメンテナンス機能一覧を取得する旨の情報であるタグ８０１が含まれていないと判定された場合、ＵＩ拡張モジュール３２４は、ＰｒｉｎｔＴｉｃｋｅｔにメンテナンス機能実行命令が含まれているか否かを判定する（Ｓ９０５）。メンテナンス機能実行命令が含まれていないと判定された場合、ＵＩ拡張モジュール３２４を表示し（Ｓ９０６）、印刷設定を行う（Ｓ９０７）。その後、図９の処理を終了する。一方、メンテナンス機能実行命令が含まれていると判定された場合、Ｓ９０８に進む。Ｓ９０８以降の処理については後述する。

上記では、ＵＩ拡張モジュール３２４の非表示について説明した。Ｖ４アーキテクチャは、ＤｏｃｕｍｅｎｔＰｒｏｐｅｒｔｉｅｓの呼び出しの際に、関数の引数に非表示フラグを設定することによりＵＩ拡張モジュール３２４を非表示にする機能を標準で有している。しかしながら、その非表示機能は、ＵＩ拡張モジュール３２４の呼び出し自体を行わないという仕様となっている。このため、その非表示機能を使用する場合には、ＵＩ拡張モジュール３２４がＳ９０２の処理を行うことができず、メンテナンス機能一覧を取得する処理を実行することができない。しかしながら、本実施形態では、上記の非表示機能を用いないので、上記の問題を回避しつつ、ＵＩ拡張モジュール３２４を非表示にしてメンテナンス機能一覧を取得することが可能となる。

［メンテナンス機能を実行する際の処理フロー］
アプリケーション２００がメンテナンス機能一覧から指定のメンテナンス機能を実行する際の処理フローについて説明する。図１０は、アプリケーション２００がメンテナンス機能一覧を取得し、その中から指定のメンテナンス機能を実行する際の処理のフローを示す図である。

アプリケーション２００は、印刷装置１２０がサポートするメンテナンス機能一覧をメンテナンスＳＤＫ Ｗｒａｐｐｅｒから取得し（Ｓ１００１）、所望のメンテナンス機能が使用できるか否かを判定する（Ｓ１００２）。メンテナンス機能が存在すると判定された場合は、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１に対してメンテナンス機能の実行命令を発行する（Ｓ１００３）。一方、メンテナンス機能が存在しないと判定された場合には、図１０の処理を終了する。Ｓ１００３の処理後、アプリケーション２００は、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１がメンテナンス機能の処理を行った後に返してきた結果を受け取り、図１０の処理を終了する。

次に、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１がアプリケーション２００からメンテナンス機能を実行する旨の命令を受け取った際の処理を説明する。図１１は、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１がアプリケーション２００からメンテナンス機能を実行する旨の命令を受け取った際のメンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１の処理のフローを示す図である。

まず、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１は、アプリケーション２００からメンテナンス機能を実行する旨の命令を受け取る。次に、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１は、ＯＳからＰｒｉｎｔＴｉｃｋｅｔを取得する（Ｓ１１０１）。メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１は、指定のメンテナンス機能を実行する旨の命令に対応する値を、ＰｒｉｎｔＴｉｃｋｅｔのタグ８０１の値８０２に記述した後、ＰｒｉｎｔＴｉｃｋｅｔをＯＳに返却する（Ｓ１１０２）。

その後、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１は、Ｄｏｃｕｍｅｎｔ Ｐｒｏｐｅｒｔｉｅｓ関数をコールする（Ｓ１１０３）。Ｄｏｃｕｍｅｎｔ Ｐｒｏｐｅｒｔｉｅｓ関数経由で呼び出されたＵＩ拡張モジュール３２４での処理終了後、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１は、ＯＳからＰｒｉｎｔＴｉｃｋｅｔを取得する（Ｓ１１０４）。そして、ＰｒｉｎｔＴｉｃｋｅｔのタグ８０３の値８０４を参照してメンテナンス機能の実行の成否についての情報を取得する（Ｓ１１０５）。メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１は、アプリケーション２００にメンテナンス機能の実行の成否の情報を返し（Ｓ１１０６）、図１１の処理を終了する。

次に、図９を用いてメンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１がメンテナンス機能実行のためにＤｏｃｕｍｅｎｔＰｒｏｐｅｒｔｉｅｓをコールした際の、標準ＵＩモジュール３２１経由で起動されるＵＩ拡張モジュール３２４の処理フローについて説明する。

ＵＩ拡張モジュール３２４は、ＰｒｉｎｔＴｉｃｋｅｔを参照し（Ｓ９０１）、タグ８０１の値８０２を確認し、メンテナンス機能一覧を取得する旨の情報が含まれているか否かを判定する（Ｓ９０２）。ＰｒｉｎｔＴｉｃｋｅｔにメンテナンス機能一覧を取得する旨の情報が含まれていないと判定された場合，ＵＩ拡張モジュール３２４は、メンテナンス機能実行の旨の情報が含まれているか否かを判定する（Ｓ９０５）。

Ｓ９０５でメンテナンス機能実行の旨の情報が含まれていると判定された場合、ＵＩ拡張モジュール３２４は、メンテナンス機能を実行する旨の情報としてタグ８０１の値８０２を参照する。そして、アプリケーション２００が指定するメンテナンス機能の情報をＤＰＢ３１６から取得する（Ｓ９０９）。次に、ＵＩ拡張モジュール３２４は、ＤＰＢ３１６から得たメンテナンス機能の情報に基づき、アプリケーション２００が指定するメンテナンス機能の実行処理を行う（Ｓ９１０）。

メンテナンス機能の実行処理では、ＵＩ拡張モジュール３２４は、印刷装置１２０にメンテナンス機能実行を示す旨のコマンドを送信する。ここでの印刷装置１２０へのメンテナンス機能実行を示す旨のコマンドの送信は、ジョブとして情報を送信しても良いし、ポートモニタ３３１に直接コマンドを送信しても良い。ここで、メンテナンス機能実行を示す旨のコマンドは、ＵＩ拡張モジュール３２４内に直接所持しても良いし、ＵＩ拡張モジュール３２４の外部にデータベースとして保持して、メンテナンス機能実行の旨の情報と照合することで得ても良い。

このようにＰｒｉｎｔＴｉｃｋｅｔとＵＩ拡張モジュール３２４を組み合わせることによりＶ４アーキテクチャにおける制限下でも、アプリケーション２００とメンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１から実印刷以外の任意の処理を実行させることができる。また、メンテナンス機能を他の機能の実行に変更すれば、様々なアプリケーションから印刷機能以外の任意の処理の実行させることも可能となる。

Ｓ９１０の処理後、ＵＩ拡張モジュール３２４は、メンテナンス機能実行の結果を印刷装置１２０から取得して（Ｓ９１１）、ＰｒｉｎｔＴｉｃｋｅｔに記述した後、ＯＳにＰｒｉｎｔＴｉｃｋｅｔを返却する（Ｓ９１２）。その後、図９の処理を終了する。

［第２の実施形態］
以下、第２の実施形態について第１の実施形態と異なる点について説明する。アプリケーション２００は、ユーザにドライバＵＩ上での操作を要求する場合がある。Ｖ４プリンタドライバの制限下では、ＵＩモジュール３２１に独自のインタフェースを設けることができないことから、常に通常起動時に表示されるタブシートを選択した状態でドライバＵＩが表示される。その場合、ユーザはタブシートの切り替えやメニュー階層をたどるという操作手順を避けることができない。従って、アプリケーション２００が指定する機能を起動させるための操作がユーザにとって煩わしいものとなる。

本実施形態では、ＰｒｉｎｔＴｉｃｋｅｔとＵＩ拡張モジュール３２４を組み合わせることで、Ｖ４プリンタドライバの制限下であっても任意のタブシートを開いた状態でユーザにドライバＵＩを提示することを可能とする。

以下、アプリケーション２００が任意のタブシートを開いた状態でドライバＵＩを起動する処理のフローについて説明する。図１２は、アプリケーション２００の処理のフローを示す図である。また、本実施形態において、アプリケーション２００は、Ｓ５０１のメンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１の読み込みを完了しているものとして説明する。

アプリケーション２００は、メンテナンスＳＤＫが使用可能であるか否かをメンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１に確認し、判定する（Ｓ１２０１）。メンテナンスＳＤＫが使用できないと判定された場合、図１２の処理を終了する。また、その場合、アプリケーション２００がエラー処理を行うようにしても良い。

メンテナンスＳＤＫが使用可能であると判定された場合、アプリケーション２００は、ＵＩ拡張モジュール３２４の任意のタブシートを選択した状態で表示する命令を、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１に発行する（Ｓ１２０２）。アプリケーション２００は、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１での処理の完了を待機する（Ｓ１２０３）。メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１での処理の終了後、図１２の処理を終了する。尚、この処理のフローにおいて、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１に対して予めＵＩ拡張モジュール３２４の指定のタブシートが存在するか否かを判定するようにしても良い。そして、存在しないと判定した場合、アプリケーション２００側、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１側でエラー処理を行うようにしても良い。

次に、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１がアプリケーション２００から任意のタブシートを選択した状態で表示する命令を受け取った場合の処理のフローについて図１３を用いて説明する。図１３は、以下の内容について図１１と異なる。即ち、ＰｒｉｎｔＴｉｃｋｅｔへの命令の書き込みの内容を変更しＰｒｉｎｔＴｉｃｋｅｔを介してＵＩ拡張モジュール３２４から受け取る結果の内容と、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１がアプリケーション２００に返す結果の内容で図１１と異なる。

メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１がアプリケーション２００から表示命令を受け取った後、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１は、ＯＳからＰｒｉｎｔＴｉｃｋｅｔを取得する（図１３のＳ１１０１）。メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１は、アプリケーション２００からの命令に対応する指定のタブシートを開く旨の情報として、値を図８のタグ８０１に、指定のタブシートを開く値８０２を設定してＰｒｉｎｔＴｉｃｋｅｔに書き込む（Ｓ１３０１）。そして、ＰｒｉｎｔＴｉｃｋｅｔをＯＳに返却する。

その後、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１は、ＤｏｃｕｍｅｎｔＰｒｏｐｅｒｔｉｅｓをコールしてＵＩ拡張モジュール３２４を起動する（図１３のＳ１１０３）。ＵＩ拡張モジュール３２４の処理終了後に、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１は、ＯＳからＰｒｉｎｔＴｉｃｋｅｔを取得する（図１３のＳ１１０４）。そして、ＰｒｉｎｔＴｉｃｋｅｔを参照して、処理の結果としてタグ８０３の値８０４を取得し（Ｓ１３０２）、アプリケーション２００に返却し（Ｓ１３０３）、図１３の処理を終了する。

図１４、図１５、図１６を用いて、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１からＤｏｃｕｍｅｎｔ Ｐｒｏｐｅｒｔｉｅｓがコールされた時のＵＩ拡張モジュール３２４の処理のフローについて説明する。図１４は、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１からＤｏｃｕｍｅｎｔ Ｐｒｏｐｅｒｔｉｅｓがコールされた場合のＵＩ拡張モジュール３２４の処理のフローを示す図である。図１５は、通常起動時のＵＩ拡張モジュール３２４による設定画面の表示を示す図である。タブシート１５０１は、通常起動時に最初に選択されているタブシートである。図１６は、通常起動時とは異なるタブシートを選択した状態でのＵＩ拡張モジュール３２４による設定画面の表示を示す図である。タブシート１６０１は、メンテナンス機能を表示するタブシートであり、ＵＩ拡張モジュール３２４を通常起動した場合にはタブシート１６０１が選択された状態で表示されることはない。

ＵＩ拡張モジュール３２４がＤｏｃｕｍｅｎｔＰｒｏｐｅｒｔｉｅｓのコールによって起動した場合、ＵＩ拡張モジュール３２４は、ＰｒｉｎｔＴｉｃｋｅｔを参照する（Ｓ１４０１）。ＵＩ拡張モジュール３２４は、ＰｒｉｎｔＴｉｃｋｅｔ内のタグ８０１の値８０２に、指定のタブシートを選択した状態でＵＩ拡張モジュール３２４を表示する命令(以後、表示命令)が含まれているか否かを判定する（Ｓ１４０２）。表示命令が含まれていると判定された場合、表示命令に対応する指定のタブシート、例えばメンテナンスに関する機能をまとめたタブシート１６０１を選択する（Ｓ１４０３）。表示命令が含まれていないと判定された場合、通常の起動時に選択されるタブシート１５０１が選択された状態となる。その後、いずれの場合でも、ＵＩを表示するようＵＩ拡張モジュール３２４が起動され、通常の印刷設定が行われる（Ｓ１４０４）。ＵＩ拡張モジュール３２４のＵＩを閉じる際に、ＵＩ拡張モジュール３２４は、ＰｒｉｎｔＴｉｃｋｅｔのタグ８０３の値８０４に処理の結果を書き込み、ＯＳにＰｒｉｎｔＴｉｃｋｅｔを返却し、図１４の処理を終了する。

以上のように、ＰｒｉｎｔＴｉｃｋｅｔとＵＩ拡張モジュール３２４を組み合わせることにより、Ｖ４アーキテクチャにおける制限下でも、任意のタブシートを選択した状態でドライバＵＩを開くことができる。このため、ユーザはタブシートの切り替えやメニュー階層をたどるという操作手順を避け、アプリケーションが指定するタブシートや情報に容易にアクセスすることができる。

［第３の実施形態］
次に、第３の実施形態について第１及び第２の実施形態と異なる点について説明する。印刷装置１２０には、セキュリティ対策などにより予め登録されたユーザにのみ印刷を許可する機能が備わっている場合がある。しかしながら、Ｖ４アーキテクチャの制限下では独自のＡＰＩを用意することができないため、ユーザにドライバＵＩ上での認証処理を要求する必要がある。このような場合においても、本実施形態によれば、ＰｒｉｎｔＴｉｃｋｅｔを介してメンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１とＵＩ拡張モジュール３２４が通信を行う。その結果、アプリケーション２００は、ドライバＵＩ上での操作を行うことなく、印刷装置１２０からユーザ認証の情報を取得や照合・登録を容易に行うことができる。

以下、アプリケーション２００がドライバＵＩを表示することなく印刷装置１２０に対してユーザ認証機能を実行させる処理のフローについて説明する。図１７は、アプリケーション２００の処理のフローを示す図である。また、本実施形態では、アプリケーション２００は、Ｓ５０１のメンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１の読み込みを完了しているものとして説明する。

アプリケーション２００は、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１に対してメンテナンスＳＤＫが使用可能であるか否かを判定する(図１７のＳ５０１)。メンテナンスＳＤＫが使用可能であると判定された場合、Ｓ１７０１に進み、メンテナンスＳＤＫが使用可能でないと判定された場合、図１７の処理を終了する。

アプリケーション２００は、ユーザＩＤとパスワードなどの認証情報とともにメンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１にユーザ認証実行命令を発行する（Ｓ１７０１）。その後、アプリケーション２００は、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１から、ユーザ認証実行処理の結果を受け取る（Ｓ１７０２）。アプリケーション２００は、処理の結果を確認し、処理が成功であるか失敗であるかを判定する（Ｓ１７０３）。処理が成功であると判定された場合は、アプリケーション２００の表示を切り替えるなどの成功の処理を行う（Ｓ１７０４）。一方、処理が失敗であると判定された場合は、失敗のメッセージを表示するなどのエラー処理を行う（Ｓ１７０５）。Ｓ１７０４若しくはＳ１７０５の処理後、図１７の処理を終了する。

次に、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１がアプリケーション２００からユーザ認証実行命令を発行された際の、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１の処理のフローについて図１８を用いて説明する。

メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１は、ユーザ認証実行命令をアプリケーション２００から取得する（Ｓ１８０１）。次に、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１は、ＯＳからＰｒｉｎｔＴｉｃｋｅｔを取得し、ユーザ認証情報の取得を示す情報をＰｒｉｎｔＴｉｃｋｅｔのタグ８０１の値８０２に記述した後、ＰｒｉｎｔＴｉｃｋｅｔをＯＳに返却する（Ｓ１８０２）。

メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１は、ＤｏｃｕｍｅｎｔＰｒｏｐｅｒｔｉｅｓをコールしてＵＩ拡張モジュール３２４を起動する（Ｓ１８０３）。メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１は、ＵＩ拡張モジュール３２４の処理の終了を待機した後（Ｓ１８０４）、ＯＳから取得したＰｒｉｎｔＴｉｃｋｅｔを参照し、タグ８０３の値８０４から処理結果を取得する（Ｓ１８０５）。最後に、メンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１は、アプリケーション２００に処理結果を返し（Ｓ１８０６）、図１８の処理を終了する。

次に、ＵＩ拡張モジュール３２４がＤｏｃｕｍｅｎｔ Ｐｒｏｐｅｒｔｉｅｓのコールにより起動された際の処理のフローについて図１９を用いて説明する。図１９は、命令確認の分岐とＤＰＢ３１６からの命令取得、印刷装置１２０への命令送信、印刷装置１２０からの結果の取得、結果をＰｒｉｎｔＴｉｃｋｅｔに記述する処理について図９と異なる。

ＵＩ拡張モジュール３２４は、ＯＳから取得したＰｒｉｎｔＴｉｃｋｅｔのタグ８０１の値８０２を参照し（図１９のＳ９０１）、ＰｒｉｎｔＴｉｃｋｅｔ内に認証情報取得命令を表す値が含まれているか否かを判定する（Ｓ１９０１）。認証情報取得命令が含まれていないと判定された場合は、ＵＩを表示して通常の印刷設定を行う（図１９のＳ９０６、Ｓ９０７）。

取得命令が含まれていると判定された場合、ＵＩ拡張モジュール３２４は、ＵＩを非表示とし（図１９のＳ９０３）、ＤＰＢ３１６から印刷装置１２０に対応する指定の認証情報取得の命令を得る（Ｓ１９０２）。ＵＩ拡張モジュール３２４は、ＤＰＢ３１６から得られた認証情報取得命令を印刷装置１２０に送信し（Ｓ１９０３）、印刷装置１２０からその結果としてユーザ認証情報を取得する（Ｓ１９０４）。ＵＩ拡張モジュール３２４は、取得した結果をＰｒｉｎｔＴｉｃｋｅｔのタグ８０３の値８０４に記述してＯＳに返却し（Ｓ１９０５）、図１９の処理を終了する。

以上のように、プリンタドライバに独自ＡＰＩを設けることができないといったＶ４アーキテクチャの制限下であっても、ＰｒｉｎｔＴｉｃｋｅｔを介してメンテナンスＳＤＫ Ｗｒａｐｐｅｒ２０１とＵＩ拡張モジュール３２４が通信を行う。その結果、アプリケーション２００は、ドライバＵＩ上での操作を行うことなく、印刷装置１２０からユーザ認証の情報を取得や照合・登録を容易に行うことができる。

上述のユーザ認証処理と同様に、ＰｒｉｎｔＴｉｃｋｅｔに印刷設定以外の情報を書き込む方法を用いることで、アプリケーション２００は、例えば、印刷装置１２０本体のアドレス帳に登録されたＦＡＸの連絡先を取得することも可能である。このように、ＰｒｉｎｔＴｉｃｋｅｔに印刷設定以外の情報を記述することで、独自のインタフェースを設けることができないＶ４アーキテクチャの制限下であっても、プリンタドライバを介して印刷装置１２０から各種情報を取得可能となる。

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

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

また、コンピュータが読み出したプログラムコードを実行することにより、各実施形態の機能が実現されるばかりではない。例えば、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳなどが実際の処理の一部または全部を行い、その処理によって各実施形態の機能が実現される場合も含まれる。

さらには、以下のような構成も含まれる。即ち、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれる。その後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって各実施形態の機能が実現される。

以上、メンテナンス等のコマンド発行、タブ表示切り替え，印刷装置１２０との認証，印刷装置１２０からの情報取得について説明してきた。本発明を用いれば、メンテナンス以外のコマンド実行や、アプリケーションからドライバに対し、その他多くの任意の機能を実行させることが可能である。また、ＭｉｃｒｏｓｏｆｔのＶ４アーキテクチャのドライバについて、主に説明してきたが、他のＯＳやアーキテクチャにおいて各実施形態の機能が実現される場合も含まれる。

（その他の実施例）
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

１１０ 情報処理装置： １１２ ＣＰＵ： １１３ ＲＯＭ： １１６ ＲＡＭ： １２０ 印刷装置

Claims (12)

1. アプリケーションとプリンタドライバとを有する情報処理装置であって、
   前記アプリケーションにおいて、前記プリンタドライバに係る印刷とは異なる機能の実行の命令を受信する受信手段と、
   前記アプリケーションにおいて、前記受信手段により受信した前記命令をプリントチケットに設定し、当該プリントチケットをＯＳに渡す設定手段と、
   前記アプリケーションにおいて、前記ＯＳを介して前記プリンタドライバを呼び出す呼出手段と、
   前記呼出手段により呼び出された前記プリンタドライバにおいて、前記設定手段により前記命令が設定されたプリントチケットを前記ＯＳから取得する取得手段と、
   前記呼出手段により呼び出された前記プリンタドライバにおいて、前記取得手段により取得したプリントチケットに設定されている前記命令に基づいて前記機能を実行する実行手段と、を有し、
   前記機能は、印刷機能と異なる機能であり、
   前記呼出手段は、前記プリンタドライバに用意された第１のインタフェースモジュールを呼び出し、
   前記第１のインタフェースモジュールは、第２のインタフェースモジュールを呼び出し、
   前記第２のインタフェースモジュールは、前記機能を実行するための情報を記憶する記憶部から、当該情報を取得する、
   ことを特徴とする情報処理装置。
2. 前記アプリケーションから前記記憶部へのアクセスは不可とされていることを特徴とする請求項１に記載の情報処理装置。
3. 前記第１のインタフェースモジュールから呼び出された前記第２のインタフェースモジュールから前記記憶部へのアクセスは許可されていることを特徴とする請求項１又は２に記載の情報処理装置。
4. 前記記憶部は、ドライバプロパティバッグを含むことを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
5. 前記実行手段は、前記取得手段により取得したプリントチケットに設定されている前記命令と、前記第２のインタフェースモジュールが取得した前記機能を実行するための情報とに基づいて、前記機能を実行することを特徴とする請求項１乃至４のいずれか１項に記載の情報処理装置。
6. 前記プリンタドライバは、Ｖ４アーキテクチャのプリンタドライバであり、
   前記第１のインタフェースモジュールは、標準ＵＩモジュールであり、前記第２のインタフェースモジュールは、ＵＩ拡張モジュールである、
   ことを特徴とする請求項１乃至５のいずれか１項に記載の情報処理装置。
7. 前記機能を実行するための情報は、前記プリンタドライバに対応する印刷装置に関する情報であることを特徴とする請求項１乃至６のいずれか１項に記載の情報処理装置。
8. 前記実行手段による実行の結果を前記ＯＳを介して前記アプリケーションに送信する送信手段、をさらに有することを特徴とする請求項１乃至７のいずれか１項に記載の情報処理装置。
9. 前記呼出手段は、前記ＯＳに標準に用意されたＡＰＩにより、前記プリンタドライバを呼び出すことを特徴とする請求項１乃至８のいずれか１項に記載の情報処理装置。
10. 前記機能は、前記プリンタドライバに対応する印刷装置のメンテナンス機能、設定画面の表示機能、認証機能の少なくともいずれかを含むことを特徴とする請求項１乃至９のいずれか１項に記載の情報処理装置。
11. アプリケーションとプリンタドライバとを有する情報処理装置において実行される方法であって、
    前記アプリケーションにおいて、前記プリンタドライバに係る印刷とは異なる機能の実行の命令を受信する受信工程と、
    前記アプリケーションにおいて、前記受信工程において受信した前記命令をプリントチケットに設定し、当該プリントチケットをＯＳに渡す設定工程と、
    前記アプリケーションにおいて、前記ＯＳを介して前記プリンタドライバを呼び出す呼出工程と、
    前記呼出工程において呼び出された前記プリンタドライバにおいて、前記設定工程において前記命令が設定されたプリントチケットを前記ＯＳから取得する取得工程と、
    前記呼出工程において呼び出された前記プリンタドライバにおいて、前記取得工程において取得したプリントチケットに設定されている前記命令に基づいて前記機能を実行する実行工程と、を有し、
    前記機能は、印刷機能と異なる機能であり、
    前記呼出工程では、前記プリンタドライバに用意された第１のインタフェースモジュールを呼び出し、
    前記第１のインタフェースモジュールは、第２のインタフェースモジュールを呼び出し、
    前記第２のインタフェースモジュールは、前記機能を実行するための情報を記憶する記憶部から、当該情報を取得する、
    ことを特徴とする方法。
12. 請求項１乃至１０のいずれか１項に記載の情報処理装置の各手段として、コンピュータを機能させるためのプログラム。

Images