JP2014071789A - 情報処理装置およびプログラム - Google Patents

Abstract

【課題】特定のベンダに依存することなく、ベンダ依存の設定情報についても、ユーザが解釈可能な形式で取得して、ログを生成することができる、情報処理装置およびプログラムを提供すること。
【解決手段】情報処理装置１００が処理したデータをプリンタ２１２といった他の装置に使用させるための設定情報を構造情報と共に生成するためのドライバUI２１０と、ドライバUI２１０が生成した設定情報をログとして取得させる固有設定出力部２２６と、生成した設定情報を解析し、生成した設定情報の値を取得するためのドライバUI解析部２２８と、生成した設定情報が修正された場合に修正された設定情報を取得手段に通知するフック関数手段２２２ａと、情報処理装置１００が処理したデータを他の装置に処理依頼した時までに修正された前記設定情報をログ情報として生成する固有設定値情報２３０（５３０）とを含んでいる。
【選択図】 図２

Description

本発明は、他の装置を動作させた履歴を記録する技術に関し、より詳細には、情報処理装置が他の装置に処理を依頼して実行させた処理についてベンダにかかわらず、情報処理装置による他の装置の利用履歴を生成する技術に関する。

パーソナル・コンピュータ（以下、単にPCとして参照する。）などでアプリケーションを操作して作成されたデータを印刷する場合、例えばWindows（登録商標）などのオペレーティング・システム（OS）の場合、GDI(Graphic Device Interface)やDDI(Device Driver Interface)を経由して、データが他の装置であるプリンタドライバへと送付される。プリンタドライバに渡されたデータは、プリントプロセッサなどの処理により印刷データに変換され、OSが管理する所謂スプーラといったバッファ領域に格納される。その後、印刷データが順次スプーラからプリンタへと送信され、印刷が実行される。

多くの場合、スプーラの動作を監視しておけば、PCがプリンタドライバを使用して実行した処理のうち、標準的な印刷設定を使用するログを取得することができる。例えば、上述したWindows（登録商標）系のOSの場合、Devmode構造体のパブリック領域に記録された履歴を取得することでログを生成することができる。

近年では、プリンタの機能が多様化し、例えばユーザの希望により、ウォーターマークの追加、カスタマイズされたトナー色、トナー使用制限など、各種のベンダ依存の機能が利用されるようにされている。このようなベンダ固有の印刷を行う場合、その条件は、Devmode構造体のうち、ベンダが任意に設定できるプライベート領域に設定されている。

プライベート領域の印刷設定で印刷が行われる場合、プライベート領域から情報を取得することが必要になるが、プライベート領域には高いアクセス制限があり、一般に公開されていない。このため、該当するベンダが提供するプリンタドライバなどのプログラムから印刷設定などの履歴を取得しなければならない。

なお、最近では、印刷設定の共有化を行う目的で、PrinterTicket形式で印刷設定を行うプリンタも知られている。PrinterTicket方式では、各種の印刷設定を例えばＸＭＬといった構造化文書で公開するので、ベンダ固有の設定であっても比較的容易に取得し、プリンタドライバのログを生成することができる。しかしながら、PrinterTicket形式を採用しないプリンタも依然として存在するので、PrinterTicket方式だけにターゲットを絞ってログを生成するのでは、ログの利用性や汎用性が失われるので、望ましくない。また、PrinterTicket方式の場合でも、例えばウォーターマークを印刷する設定について、単なるフラグや、隠語が使用される場合もあるので、構造化文書から設定を取得しても有意義なログを生成することができない場合もある。

プリンタの動作に関するログを取得する技術は各種知られており、例えば、特開２００５−１８２４８６号公報（特許文献１）には、プリンタの機種やメーカによらず、印刷ログや印刷制限などを管理する技術が記載されている。特許文献１では、ＯＳの標準コマンドを傍受して、その時点での印刷設定値を取得する。しかしながら特許文献１に記載された技術では、ベンダ固有の設定値や隠語はそのまま取得できるにすぎないため、有意義なログを蓄積できないという問題は依然として未解決であった。さらには、プリンタばかりではなく、外部接続された装置に対してその動作を設定するための設定情報を、ベンダに依存することなく取得することを可能とするという問題も依然として未解決であった。

本発明は、従来技術の上記問題点に鑑みなされたものであって、本発明では、特定のベンダに依存することなく、情報処理装置が処理を依頼する他の装置について、ベンダ依存の設定情報についても、ユーザが解釈可能な形式で取得して、ログを生成することができる、情報処理装置およびプログラムを提供することを目的とする。

本発明は、上述した従来技術の問題点を解決するために、アプリケーションに他の装置を設定するための設定取得手段を構成する。設定取得手段は、設定のために提供されるユーザ・インタフェース（以下、単にUIとして参照する。）の設定情報を解析する解析手段と、設定のために使用するドライバ手段やブラウザ手段などにおいて設定される設定情報を監視する監視手段とを備える。アプリケーションが設定のためのUIが生成されることを検知すると、解析手段は、生成されたUIの内部構造の解析を行ない、監視手段は、ユーザによるUIへの操作入力を検出し、ユーザ入力の結果を、解析手段に渡し、設定情報をログとして保存させる。

さらに、監視手段は、他の装置の動作開始および動作終了を検出し、その間に有効とされた各種設定値を時系列的にログとして保存する。またログは、必要に応じてハードプリントすることもできる。本発明では、設定のためのUIが呼び出されてから、UIを介して設定された各設定値をアプリケーション側が取得するので、ベンダ固有の設定があった場合でもユーザが認識できる形式で、その履歴をログとして生成することができる。

本発明の情報処理装置１００の構成を示した概略図。 本実施形態の情報処理装置１００を含む情報処理システムの機能ブロックを示す図。 本実施形態の印刷システムが実行する処理のシーケンス図。 本実施形態のドライバUI２１０が表示するＧＵＩ４００を示す図。 本実施形態で使用する図２で示した各種情報の実施形態をリスト５００〜５３０の形式として示す図。 本実施形態の情報処理装置１００が実行する監視処理のフローチャート。 固有設定取得部２２０が実行するドライバUI解析処理および固有設定についての初期値を取得する処理のフローチャート。 図３のプロセスｐ９および図７のステップＳ７１２の固有設定値更新処理について詳細に説明する図。 本実施形態の第２の実施形態の固有設定取得部９００の機能ブロックを示す。 ベンダ固有の印刷設定がある場合に、印刷を制限することを可能とする処理のフローチャート。 本実施形態の第３の実施形態について説明する図。

以下、本発明を図面に示した特定の実施の形態をもって説明するが、本発明は、後述する実施の形態に限定されるものではない。

図１は、本発明の情報処理装置１００の構成を示した概略図である。図１に示す情報処理装置１００は、CPU１０２と、RAM１０６と、ROM１０４を含んでいて、オペレーティング・システムの制御下で、少なくとも１つのアプリを実行させている。CPU１０２は、例えば、PENTIUM（登録商標）ファミリ、６４ビット・アーキテクチャのXEON（登録商標）、POEWRPC（登録商標）などのCISCまたはRISCアーキテクチャの下で、Windows（登録商標）、Windows（登録商標）2000、Windows（登録商標）2000Prpfessional、Windows（登録商標）XP、Windows（登録商標）XP SP2、Windows（登録商標）XP Professional、Windows（登録商標）200X Server、Windows （登録商標）CEなどのオペレーティング・システム（OS）を実行している。

CPU１０２は、オブジェクト指向プログラミングの実行を可能とする資源を使用して、例えば、C#、C++、Java（登録商標）、Javascript（登録商標）などのオブジェクト指向プログラムが実行可能とされている。OSは、種々のシステム・コールまたはシステム・コマンドを使用して、オブジェクト指向プログラムのプロセスを調停しており、同時にハードウェア資源の共有化およびデータの共有化を可能としている。

RAM１０６は、CPU１０２によるオブジェクト指向プログラムの実行に伴って生成されるインスタンスを提供する実行空間を提供しており、CPU１０２による処理を可能としている。さらに、ROM１０４は、BIOS(Basic Input Output System）などのマイクロ・コードやデータなどを格納していて、情報処理装置１００の起動に際してOSの起動に先立って、情報処理装置の検査を行い、また起動後の入出力装置の管理を実行する。

情報処理装置１００には、USBやIEEE1284などのシリアルまたはパラレル・バスを介してキーボード、マウス、またはプリンタなどの入出力装置１０８に接続されており、適切なインタフェース１１０を介してCPU１０２へとユーザ入力を渡している。また、情報処理装置１００には、ATA、シリアルATA、ウルトラATA、ATAPIなどの規格のIDE、またはSCSI、SCSI-2、SCSI-3といったインタフェース１２０を介して、記憶装置１２２が接続されている。記憶装置１２２は、ハードディスク装置または半導体メモリ装置などから選択することができ、情報処理装置１００に内蔵されていてもよく、またカード型ハードディスクや、随時読み書き可能な半導体メモリとされていてもよい。

CPU１０２は、ユーザからの指令に基づき、実行形式のプログラムを読み出して実行し、その実行結果を、内部バス１２４を介してRAM１０４や記憶装置１２２へと書き込みを行い、また記憶装置１２２に格納されたデータを取得して処理に使用している。図１に示した情報処理装置１００は、内部バス１２４を介してVRAM１２６およびグラフィック・チップ１２８と通信し、処理の結果などを適切なGUI(Graphical User Interface)を介してユーザに提供している。情報処理装置１００は、内部バス１２４を介してイーサネット（登録商標）などのネットワーク・インタフェース１３２と通信して、LAN(Local Area Network)、WAN(Wide Area Network)またはインターネットといったネットワーク１３４と接続されて、Webサーバなどとの通信を可能としている。

図２は、本実施形態の情報処理装置１００を含む情報処理システムの機能ブロックを示す。なお、以下の実施形態では、情報処理装置１００と、他の装置としてのプリンタ２１２とを含む印刷システムにおいて、情報処理装置１００による設定をログとして取得することを例示的に説明するが、本発明は、情報処理装置１００が他の装置を制御するために設定する設定情報を、ベンダに依存することなくログとして取得する情報処理システムであれば、特に制限なく適用できるものである。

例えば、情報処理装置１００が接続する装置としてはプリンタ２１２以外にも、プロジェクタ、電子情報ボード、VGA設定、ネットワーク設定、暗号方法および暗号強度の情報、その他、外部接続される周辺装置を挙げることができ、そのための設定を生成する手段としては、ドライバソフトウェア手段、ブラウザ手段など、情報処理装置１００のデスクトップ画面上にユーザ・インタフェースを提供できるいかなる手段でも、情報処理装置１００の設定を他の装置に反映させることができれば制限されるものではない。

以下、本実施形態では、説明をさらに具体的に行うことを目的とし、OSとしてWindows（登録商標）系のOSを使用するものとして説明する。しかしながら、OSとしては、LINUX（登録商標）やUNIX（登録商標）、MacOS（登録商標）などを使用することができる。情報処理装置１００は、印刷を行うためのデータを生成するためのアプリケーション２００と、GDI２０２と、ドライバ２０４と、ドライバUI２１０とを含んでいる。ドライバUI２１０は、本実施形態における設定情報を生成する生成手段として機能する。

GDI２０２は、OSが提供する画像処理の汎用インタフェースであり、説明する実施形態では、Devmode構造体、データ、アプリケーション２００、ドライバUI２１０、ドライバ２０４などの各機能部とOSと間のインタフェースを提供する。なお、ドライバUI２１０は、プリンタドライバといったドライバ２０４の設定を行うためのUIであり、アプリケーション２００から呼び出されてそのインスタンスを生成し、ユーザの操作に応じてグラフィカルにDevmode構造体の設定を行う。

また、ドライバ２０４は、GDI２０２から渡された設定などを使用してアプリケーション２００が作成したデータからプリンタ２１２のための印刷データを生成したり、OSのスプーラ２０６に処理を依頼したり、プリンタ２１２に対してネットワークやバスラインなどの通信ライン２０８を介して印刷データを送付させて、印刷処理を可能とさせている。スプーラ２０６は、ドライバ２０４が生成した印刷データを、プリンタ２１２に送付されるまで一時的に保持する機能を有する。

プリンタ２１２は、ローカルプリンタでもネットワークプリンタであっても良く、電子写真方式、インクジェット方式、感熱転写方式などの印刷方式を使用して印刷データを上質紙などの受像体に可視像としてハードプリントする。また、プリンタ２１２は、プリント専用機、複写機、複写機、ファクシミリ、イメージリーダ、ネットワークアクセス機能などを含む多機能複写機として実装することができる。

さらに本実施形態の情報処理装置１００は、固有設定取得部２２０を備えている。なお、本実施形態で固有設定とは、ドライバUI２１０によりユーザが設定することができる設定のうち、ベンダが提供するOSなどが標準的にサポートしてはいないベンダ固有の印刷に関する設定を意味し、以下、単に固有設定として参照する。固有設定としては、例えばスタンプ印刷、ウォーターマーク印刷、省エネ印刷など、ベンダが印刷の利便性や機能を改善する目的で、ドライバ２０４に追加する印刷条件のための設定を挙げることができるがこれらに限定されるものではない。

固有設定取得部２２０は、さらにドライバUI監視部２２２と、ドライバUI解析部２２８と、固有設定出力部２２６とを含んでいる。ドライバUI監視部２２２は、ユーザが操作を行うドライバUI２１０を監視し、ドライバUI２１０の生成、フック関数といった通知手段の追加処理、およびユーザが入力した設定情報への変更を記録する処理を担当する。また、固有設定出力部２２６は、ドライバUI解析部２２８がドライバUI２１０のUIコンポーネントを解析して得た固有設定値の位置を参照して、ドライバUI 監視部２２２が検出した設定情報への変更を、固有設定値をフック関数手段２２２ａなどの通知手段を使用して取得して、固有設定値情報２３０として記憶装置１２２に格納させログ情報を生成させる機能を提供している。

また、ドライバUI解析部２２８は、取得する必要のある固有設定値を保有するドライバUI２１０上のUIコンポーネントを、ドライバUI２１０上から割り出し、UIコンポーネント識別情報２３４としてハードディスクなどの記憶装置１２２に登録し、管理する。また、固有設定取得部２２０は、ドライバUI名リスト２２４を含んでおり、ドライバUIリストは、本実施形態において監視対象とするドライバUI２１０を、ユーザ指定または本実施形態の固有設定取得部２２０が設定する。

固有設定取得部２２０は、また、固有設定値情報２３０、固有設定名情報２３２、およびコンポーネント識別情報２３４を記憶装置１２２などに管理している。固有設定値情報２３０は、現在ドライバUIなどにおいて設定されている固有設定値を固有設定値名に対応づけて登録する。なお、本実施形態の好ましい実施形態では、固有設定値情報２３０は、情報処理装置１００の動作において他の装置に対する設定情報を生成した時点で作成され、これを時系列的に蓄積するログ記録手段としても機能する。さらに他の実施形態では、別のデータやファイルとして固有設定情報を時系列的にコピーして蓄積するデータベースなどを設けても良い。固有設定名情報２３２は、ドライバUI２１０に対し、設定される固有設定の値を取得するため、固有設定の名称を管理している。また、コンポーネント識別情報２３４は、取得するべき固有設定に関連づけられるドライバUI２１０のコンポーネントと、当該コンポーネントの固有設定の名称とを対応付けて管理する情報である。

図３は、本実施形態の印刷システムが実行する処理のシーケンス図である。本実施形態の印刷システムは、ユーザが情報処理装置１００に対してアプリケーション２００または固有設定取得部２２０の機能を提供するためのアプリケーションを起動させ、プロセスｐ１で固有設定取得部２２０を呼び出して開始される。なお、固有設定取得部２２０は、アプリケーション２００のプラグイン・プログラムとして構成することもできるし、アプリケーションから独立したプログラムとして構成することができる。

取得機能が起動されると、プロセスｐ２で印刷を行う可能性のあるアプリケーションに対して、ドライバUI２１０を呼び出すための関数、印刷要求開始関数、印刷要件終了関数に対してフック関数を設定する。なお、フック関数とは、アプリケーション２００から呼び出される関数について、当該関数の呼び出し要求がアプリケーション２００から発行されると、当該関数が実行される前に当該関数を取得し、所定の処理を実行する関数でありOSまたはアプリケーション２００自身から呼び出される関数のことである。

なお、フック関数を設定するOS関数としては、ドライバUI２１０を生成させるためのPrintProperties関数や、PrintDlg関数を挙げることができ、また印刷要求開始関数としてはGDI２０２のStartDoc関数やEndDoc関数を挙げることができる。

以下、これら３つの関数について設定するフック関数をそれぞれ、印刷設定エントリフック関数、印刷要求開始フック関数、印刷要求終了フック関数として参照する。フック関数は、OSに関しては、SetWindowsHookEx関数や、アプリケーション２００内のインポートセクション書き換えなど、既知の手法が多数存在する。なお、本実施形態では、フック関数は、すべてのアプリケーション２００に対してシステムが設定するシステムフックとして実装することができるが、アプリケーション２００を指定し、指定したアプリケーション２００についてのみフック関数を適用するローカルフックとして設定することが、情報処理装置１００の全体の処理に対する影響を軽減できるため好ましい。

プロセスｐ３でユーザがフック関数を設定したアプリケーション２００に対してドライバUI２１０を開くよう指示すると、プロセスｐ４でOSまたはアプリケーション２００が、まずプロセスｐ４で印刷設定エントリフック関数を呼び出す。呼び出された印刷設定エントリフック関数は、プロセスｐ５でその後に呼び出されるドライバUI２１０の監視を始める。なお、監視プロセスの詳細は、図６を使用して後述する。

プロセスｐ６では、印刷設定エントリフック関数が呼び出された後、アプリケーション２００は、ドライバUI２１０を生成するが、このとき、ドライバUI２１０が生成されると、アプリケーション２００は、ドライバUI２１０への参照をOSから検索し、プロセスｐ５からの破線で示すように、ドライバUI２１０の固有設定の初期値を取得する。また、ドライバUI２１０に対し、ユーザ操作を通知させるための、他のフック関数、例えばWH_JOURNALPLAYBACK、WH_MOUSE、WH_MSGFILTERなどを設定する。これらの関数は、本実施形態における通知手段に相当する。

ドライバUI２１０に対してこの段階でフック関数を設定することにより、生成されるドライバUI２１０に対するGUIやキーボード入力されたユーザ設定が、プロセスｐ５で設定したフック関数を通じてプロセスｐ７およびプロセスｐ８で固有設定取得部２２０に通知される。

固有設定取得部２２０は、プロセスｐ８で通知を受け取ると、プロセスp９に処理を渡し、ドライバUI２１０から取得した初期値を、プロセスｐ８で通知された新しい値へと変更していく。この処理は、ユーザがプロセスｐ１０でドライバUI２１０をクローズするまで継続される。ドライバUI２１０のクローズは、プロセスｐ５で設定したフック関数を通じてプロセスｐ１１で固有設定取得部２２０に通知される。

固有設定取得部２２０は、プロセスｐ１１で通知を受けると、プロセスｐ６で追加されたドライバUI２１０へのフック関数を破棄し、プロセスｐ１２で、その監視プロセスを終了する。その後、ユーザが印刷開始を指令すると、説明する実施形態では、アプリケーション２００は、直接印刷要求開始関数を呼び出すのではなく、プロセスｐ７で固有設定取得部２２０が設定した印刷要求開始フック関数をプロセスｐ１４で呼び出す。

固有設定取得部２２０は、プロセスｐ１５で印刷要求開始フック関数内でドライバUI２１０から取得していた固有設定値を確定させ、その後、プロセスｐ１６で本来の印刷要求開始関数を呼び出す。本来の印刷要求開始関数が呼び出されると、GDI２０２は、プロセスｐ１７でドライバ２０４へ印刷要求開始を通知する。アプリケーション２００がGDI２０２を通じ印刷要求を送り終えると、プロセスｐ１８で印刷要求終了フック関数を呼び出す。

この関数の実行時も説明する実施形態では、アプリケーション２００は、本来の印刷要求終了関数ではなく印刷要求終了フック関数を呼び出す。固有設定取得部２２０は、プロセスｐ１９で印刷要求終了フック関数内でプロセスｐ１５にて確定した固有設定値を保存する。その後、固有設定取得部２２０は、プロセスｐ２０で本来の印刷要求終了関数を呼び出し、それを受け、プロセスｐ２１でGDI２０２は、プロセスｐ２１でドライバ２０４に対し、印刷要求終了を通知する。

ドライバ２０４は、それを受けプロセスｐ２２でスプーラ２０６へ印刷するべきデータを渡し、印刷の開始を要求する。その後、スプーラ２０６は、プリンタ２１２へデータを渡し、プロセスｐ２３でプリンタ２１２へと印刷を要求する。以上のシーケンスを使用することによってドライバUI２１０においてユーザが設定を変更した値を、ドライバUI２１０のコンポーネント単位で固有設定取得部２２０が取得できるようになる。

図４は、本実施形態のドライバUI２１０が表示するＧＵＩ４００を示す。図示したドライバUI２１０は、固有設定として“スタンプ印字”４０６および“印字文字列”４０８の設定を行う入力部であるチェックボックス４０４および４１０を含んでいる。なお、図４では、その他、OSがサポートするべき標準の印刷設定については簡略化のため省略して示している。

GUI４００には、タイトルバー４０２が表示されており、タイトルバーには、「MFP ２００１のプロパティ」として当該ドライバUI２１０の名前が表示されている。また、各種の入力を受け付けるための入力部として、図４では、チェックボックス４０４と、テキストボックス４１０とが設けられている。チェックボックス４０４は、スタンプ印字の有効・無効を設定する機能を提供しており、スタンプ印字が有効である場合にスタンプとして印字する文字列を設定する機能を提供している。図４中、チェックボックス４０４と、その説明である“スタンプ印字”４０６は、１つのUIコンポーネントとして定義されているが、“印字文字列”４０８およびテキストボックス４１０は、それぞれ別のUIコンポーネントとして定義される。また、ボタン４１２も別のコンポーネントを構成しており、ユーザがこのボタン４１２をクリックするか、特定のキー入力を行うことで、ドライバUIをクローズすることができる。

本実施形態では、各UIコンポーネントは、アプリケーション２００が一意に識別するために識別子を設定することで対応付けを行う。例えば、Windows（登録商標）をOSとする場合、コントロールIDがUIコンポーネントごとに設定されており、コントロールIDを使用することにより、多くの場合、UIコンポーネントを一意に特定することができる。

ただし、コントロールIDは、実装条件や実行環境によりドライバUI２１０の生成毎に変化する場合も想定されるので、コンポーネントとの相対位置や、キャプション、名称など様々な属性を組み合わせてUIコンポーネントを識別することができる。

図５には、本実施形態で使用する図２で示した各種情報の実施形態をリスト５００〜５３０の形式として示す。ドライバUI名リスト５００は、固有設定の取得対象となるドライバUI２１０を定義したものである。当該ドライバUI名リスト５００は、ユーザがGUIから設定することもできるし、固有設定取得部２２０やアプリケーション２００自体、またはそのためのプラグイン・プログラムなど、他のアプリケーションが自動で生成することができる。

なお、ドライバUI名リスト５００のドライバUIIDは、固有設定取得部２２０がドライバUI２１０を一意に識別するために、たとえは設定された順または発見された順など、自動で生成する識別子である。また、ドライバUI名は、ドライバUI２１０のGUI４００にタイトルバーなどとして表示されるタイトルを使用することができる。本実施形態で、アプリケーション２００が提供する全てのドライバUI２１０に対して固有設定を取得するなど、取得対象を選ばない場合などは、このドライバUI名リスト５００は、必ずしも作成されずとも良い。

また、図５中、固有設定名リスト５１０は、ドライバUIIDで指定されるドライバUIから取得する固有設定名を定義したものである。当該固有設定名リスト５１０は、ドライバUI名リスト５００と同様に、ユーザが作成しても良いし、固有設定取得部２２０やアプリケーション２００、または当該機能を提供する他のアプリケーションが自動で生成しても良い。

固有設定名リスト５１０のカラムを構成する固有設定名は、固有設定取得部２２０がドライバUI２１０から取得する固有設定の名称である。この名称は、説明“スタンプ印字”４０６および“印字文字列”４０８に対応する機能を有するが、完全一致する必要はなく、部分一致としても良い。例えば、“印字文字列”４０８という設定を取得する際、実際のドライバUI２１０には“印字文字列：”として、「コロン」などが追加されて表示されている場合があるからである。

図５のコンポーネント識別情報リスト５２０は、固有設定とその固有設定の実際の値を持つコンポーネントを紐付けるための情報である。例えば、チェックボックス４０４とその説明“スタンプ印字”４０６のように、説明ラベルと、入力部とが同一のUIコンポーネントとして登録されている場合は、固有設定の名称からUIコンポーネントを特定することができる。しかしながら、説明“印字文字列：”４０８と、テキストボックス４１０のように説明ラベルと、入力部とが異なるUIコンポーネントとして与えられる場合は固有設定の名称からUIコンポーネントを一意的に特定することができない。

例えば、コンポーネントIDを使用して具体的に説明すると、“スタンプ印字”４０６であれば、コンポーネントID“12034450”で参照される。また、“印字文字列”４０８の場合、実際の入力値は別のUIコンポーネントであるテキストボックス４１０が保持しているため、コンポーネントIDは、テキストボックス４１０を参照する“12034458”としなければならない。この情報は、ドライバUI解析部２２８によってアプリケーション毎にドライバUI２１０の構造を解析することにいって一時的情報として生成される。

さらに図５に示す固有設定値情報リスト５３０は、コンポーネント識別情報リスト５２０内の固有設定名に対応し、対応する識別子は、コンポーネントIDに対応する。また固有設定値情報リスト５３０は、固有設定取得部２２０がドライバUI解析部２２８の解析によって実際に取得することができた設定値である。固有設定値情報リスト５３０中の固有設定名は、コンポーネント識別情報リスト５２０、固有設定名リスト５１０内の固有設定名にそれぞれ対応し、対応づけられた値は、ユーザがドライバUI２１０を介して実際に設定した情報を反映した現時点での固有設定値である。なお、固有設定値情報リスト５３０もドライバUI解析部２２８によってアプリケーション毎に生成されるが、固有設定情報リスト５３０の内容自体は、時系列的に他の情報と共に、記憶装置１２２内でテキストファイルやデータベースとして保管され、ログ情報として使用されるデータ内容を提供している。

図６は、本実施形態の情報処理装置１００が実行する監視処理のフローチャートである。図６の処理は、ステップＳ６００から開始し、ステップＳ６０１でアプリケーション２００のプロセスおよびメインウィンドウのそれぞれプロセスIDおよびウィンドウ名などを取得する。ステップＳ６０２では、メインウィンドウに紐づけられた子、孫などのウィンドウ名を累代的に取得してゆく。

ステップＳ６０３では、取得したウィンドウ名がドライバUI名リスト５００に登録してある名前を有するか否かを判断し、ない場合（ｎｏ）、処理をステップＳ６０７に分岐させてタイムアウトが経過したか否かを判断する。タイムアウトが満了していない場合（ｎｏ）、処理をステップＳ６０２に分岐させ、さらに生成したウィンドウ名の取得を継続する。一方、一定時間経過しても有意なドライバUI名が検出されない場合（ｙｅｓ）、プロセスの異常として処理をステップＳ６０６に進め、処理を終了させ、以後のアプリケーション２００の起動まで処理を停止させる。

一方、ステップＳ６０３の判断で、ドライバUI名リスト５００に登録されたドライバUI名が見出された場合（ｙｅｓ）、ステップＳ６０４で、ドライバUI解析部２２８を呼び出してドライバUIのUIコンポーネントを解析し、説明する本実施形態では、固有設定名リスト５１０に登録された名称のコンポーネントが存在するか否かを検査し、固有設定名リスト５１０に設定された名称を有するUIコンポーネントを取得し、コンポーネント識別情報リスト５２０に該当するコンポーネントIDを固有設定名に対応づけて登録する。

さらにステップＳ６０５では、当該ドライバUIに対して固有設定値を固有設定取得部２２０に通知させるためのフック関数を追加し、以下、当該ドライバUIが終了するまで、固有設定値を取得可能な状態とさせておき、ドライバUIが終了した時に、ステップＳ６０６で処理を終了させる。ドライバUIに追加されるフック関数は、ローカルフックとして設定されるので、ステップＳ６０６で処理を終了させる時にはフック関数も解放され、無駄なリソースの消費は発生しない。なお、ステップＳ６０５で追加できるフック関数としては、Windows（登録商標）をOSとして使用する場合、SetWindowsHookEx()といったAPI関数を使用し、ShellProc関数や、CallWndProc関数、CallWndProcRet関数を追加することを挙げることができるがこれらに限定されるものではない。ユーザ操作を通知させるための、他のフック関数、例えばWH_JOURNALPLAYBACK、WH_MOUSE、また、WH_MSGFILTERなどを設定する。これらの関数は、いずれも本実施形態における通知手段に相当する。

なお、ドライバUIに対してフック関数を追加するためにはフッククラスなどを固有設定取得部２２０のモジュールとして構成しておき、フック関数を設定するべきドライバUI名の検出に応じて、フッククラスのメンバ関数を呼び出す構成とすることができるし、また動作環境が許可する場合、DLL(Dynamic Link Library)や、パブリック・ライブラリなどとして追加しておき、追加するとの判断に応答して所定のフック関数を呼び出す構成とすることができる。

図７は、固有設定取得部２２０が実行するドライバUI解析処理および固有設定についての初期値を取得する処理のフローチャートを示す。なお、ドライバUI解析処理は、ドライバUI解析部２２８が実行し、固有設定の初期値の取得は、ドライバUIに追加されたフック関数によって実行される。この処理は、図５のコンポーネント識別情報リスト５２０の作成および固有設定値情報リスト５３０の初期化および更新を行う処理に相当する。

処理は、ステップＳ７００から開始し、ドライバUI監視部２２２からドライバUI２１０への、例えばハンドルといった参照値およびドライバUIIDが渡される。その後、ステップＳ７０１でドライバUI監視部２２２から渡されたドライバUIIDで指定されるドライバUI中のUIコンポーネントを全て列挙し、その後、ステップＳ７０２で、列挙したコンポーネントを配列Xを定義し、この配列Xに格納する。このとき、配列Xには、コンポーネントIDが格納される。

ステップＳ７０３では、固有設定名リスト５１０からドライバUIに対応する固有設定名を取得し、ステップＳ７０４では、配列Yを定義して取得した固有設定名を配列Yに格納する。ステップＳ７０４が終了した時点で、配列Yには、例えば、ドライバUIID“２”に対応する“スタンプ印字”４０６および“印字文字列”４０８が格納される。

その後、ステップＳ７０５でコンポーネント識別情報リスト５２０を初期化し、具体的には、配列Yに格納された固有設定名毎に識別情報（コンポーネントID）を対応づけて記憶する領域を確保し、識別情報をクリアする。さらにステップS７０６では、固有設定値情報リスト５３０の初期化を行うが、ステップＳ７０６でも固有設定名毎に、固有設定値を記憶するための領域を確保し、確保した領域をクリアする。

ステップＳ７０７〜ステップＳ７１６では、現在処理対象とされているドライバUIの全ての固有設定名について初期値およびコンポーネントIDを取得する。ステップＳ７０７では、カウンタを初期設定し、ステップＳ７０８で配列Xの中から固有設定名を文字列として含むUIコンポーネントを検索し、見出された場合（ｙｅｓ）、見出された固有設定名を取得する。

例えば、UIコンポーネントとして“スタンプ印字”４０６、“印字文字列”４０８が取得される。なお、ステップＳ７０８で、抽出される固有設定名が存在しない場合（ｎｏ）、固有設定名リスト５１０の設定ミスまたはドライバUIのバージョンアップなどにより固有設定名が変更されたことが考えられるので、見出されなかった固有設定については処理をスキップして処理をステップＳ７１５に分岐させる。

固有設定名が取得できた場合、ステップＳ７０９で当該UIコンポーネントの表示ラベルと、入力部が同一か否かの確認を行う。例えば、Windows（登録商標）では、UIコンポーネントのチェックボックスやボタンは、表示ラベルと対となったUIコンポーネントであり、取得するべき値はチェックボックス４０４の間として一義的に決定できる。これらが一致するUIコンポーネントの場合(ｙｅｓ)には、識別したUIコンポーネントに設定された値を直接取得すれば正しい設定値が取得できるので、ステップＳ７１０でそのUIコンポーネントを一意に識別できるコンポーネントIDなどを、ステップＳ７１１でコンポーネント識別情報リスト５２０に設定する。なお、同一のドライバUI２１０を繰り返して呼び出す場合には、バージョン情報などを識別して同一のUIコンポーネントについての冗長的な構造解析を省略することもできる。

ステップＳ７１２では、当該コンポーネントについて更新されたことを検出するとフック関数が呼び出され、そのたびに更新された固有設定値を取得し、固有設定値情報リスト５３０の対応する行に格納することで、最新の設定値を取得できる。具体的には、チェックボックス４０４を指定するコンポーネントID“12034450”を“スタンプ印字”４０６の固有設定名に対応づけて登録する。なお、テキストボックス４１０の場合には、“印字文字列”４０８に対応づけてコンポーネントID“12034458”を登録する。

ところで、コンポーネントの表示ラベルと、入力部が同一でない場合、例えば“印刷文字列”４０８といった表示ラベルを伴うテキストボックス４１０の場合、取得するべき値は、表示ラベルではなく、テキストボックス４１０の値である。このため、ステップＳ７０９の判断で、表示ラベルと、UIコンポーネントの入力部が一致していない種類のUIコンポーネントであと判断した場合（ｎｏ）、ステップＳ７１３で対応づけられる実設定値を与えるUIコンポーネントの探索を行い、ステップＳ７１４で固有設定値を与えるべきUIコンポーネントが見出された場合、処理をステップＳ７１０に戻して固有設定値の更新を行う。一方、対応する入力部を与えるUIコンポーネントの探索に失敗した場合には、固有設定値を更新せず、ステップＳ７１５でさらに次のUIコンポーネントの処理を実行させる。なお、ステップＳ７１３およびステップＳ７１４の処理については、より詳細に後述する。

ステップＳ７１５では、カウンタのインクリメントを行い、ステップＳ７１６で、カウント値が配列Yのサイズ以上となった場合（ｙｅｓ）、ステップＳ７１７で処理を終了させ、カウント値が配列Yのサイズ未満の場合（ｎｏ）、処理をステップＳ７０８に戻し、さらに他のUIコンポーネントの探索を繰り返す。

以下、ステップＳ７１３およびＳ７１４で固有設定名の文字列を含むUIコンポーネントから入力部となるUIコンポーネントの取得を行う方法について説明する。このための方法は、OSの種類やアプリケーションによりいくつか方法がある。例えば、入力部と、当該入力部のラベルを表示させるためのUIコンポーネントとを対応させたリストを予め作成したり、入力部がラベルを表示させるためのUIコンポーネントの参照を持っていたりするような実装やOSであれば、単にラベルを表示させるUIコンポーネントに紐付いている入力部のコンポーネントIDを判断し、その値を固有設定値として取得すればよい。

これ以外にも、ラベルを表示させるUIコンポーネントとの距離、上下関係、左右関係などを判断し、ドライバUI上で最も近くに配置されたUIコンポーネントを入力部として選択する実施形態を採用することもできる。さらに、UIを生成させる手段が、Internet Exploler（登録商標）、Chrome（登録商標）、FireFox（登録商標）などのブラウザ手段の場合、ドライバUI監視部２２２の代わりに、またはドライバUI監視部２２２の並列モジュールとして適すとパーサやＸＭＬパーサを実装させ、タグの属性やタグの配置を参照して、UIコンポーネントとその入力部の位置関係を判断することもできる。

図８は、図３のプロセスｐ９および図７のステップＳ７１２の固有設定値更新処理について詳細に説明する。以下の実施形態で、ドライバUI２１０からユーザがテキストボックス４１０の内容を、デフォルト設定の“DRAFT”から“TEST”に変更した場合を例として説明する。

プロセスｐ６でドライバUI２１０へのフック関数追加により、ドライバUIを介してユーザが操作を行った場合、ドライバUI監視部２２２に、更新されたUIコンポーネントであるテキストボックス４１０と、その内容とが時系列的に通知されることになる。

図８の処理は、ステップＳ８００から開始し、ドライバUI監視部２２２がドライバUIの変更を検出するとステップＳ８０１で、UIコンポーネントのコンポーネントIDが、コンポーネント識別情報リスト５２０に登録されているか否かを判断する。ステップS８０１で、コンポーネント識別情報リスト５２０に含まれておらず、監視対象ではないと判断した場合（ｎｏ）、処理をステップＳ８０４に分岐させて処理を終了させる。一方、ステップＳ８０１で、UIコンポーネントのコンポーネントIDが、コンポーネント識別情報リスト５２０に登録されている場合（ｙｅｓ）、監視対象の固有設定値が修正されたのでステップＳ８０２で、当該UIコンポーネントの値を、固有設定値として取得し、ステップＳ８０３で、固有設定値を固有設定値情報リスト５３０に登録し、ユーザによるドライバUI２１０の修正により、固有設定値情報リスト５３０の内容を更新し、処理をステップＳ８０４で終了させる。

なお、ステップＳ８０１の処理は、ドライバUI監視部２２２がドライバUI２１０の修正を検出すると、ドライバUI解析部２２８に通知し、通知されたコンポーネントID、例えば“12034458”を取得し、当該値が、コンポーネント識別情報リスト５２０に含まれているか確認することにより行われる。コンポーネントIDが“12034458”であれば、固有設定名である“印字文字列”４０８と共に登録されている。コンポーネントID＝“12034458”が登録されていれば、当該UIコンポーネントについての固有設定値を取得し、固有設定値情報リスト５３０の対応する固有設定名の行の値“DRAFT”を、取得した修正後の固有設定値“TEST”で上書き保存することで更新処理が終了する。

以下、さらに本発明の他の実施形態について説明する。図９は、第２の実施形態の固有設定取得部９００の機能ブロックを示す。第２の実施形態では、図２で示した機能手段と同一の機能を提供する機能手段については、同一の参照符号を使用して示す。図２で示した固有設定取得部２２０に対してさらに、印刷許可部９０２と、印刷制限情報９０４と、クライアント環境取得部９０６とが追加されている。

印刷許可部９０２は、印刷制限情報９０４を用いてユーザが印刷を行うことが出来るか否かの判定を行う。また、クライアント環境取得部９０６は、アプリケーション２００が動作する環境の任意のパラメータを取得し、アプリケーション２００の固有設定として、固有設定値情報２３０に登録する。印刷制限情報９０４は、ユーザが印刷を行う場合の制限事項を、ユーザやアプリケーションが設定した情報であり、固有設定の一部としてとらえることができる。例えばこれらの情報としては、スタンプ印刷可否、フルカラー印刷可否、集約印刷の可否、両面印刷の可否などを挙げることができる。

図９に示した実施形態では、これらの任意設定される設定情報についても固有設定値情報として、固有設定値情報２３０に印刷制限も同時に固有設定値として取得することを可能とする。なお、図９には、印刷制限情報９０４の実施形態を、印刷制限情報リスト９１０として示す。上述した印刷制限情報のうち、ドライバUIによらずに設定されてしまう固有設定も想定でき、このようなドライバUIIDが存在しないものは、ドライバUIによらない固有設定を表す。例えば、いかなるドライバUIでも制限の及ぶものや、クライアント環境から取得した固有設定値を、固有設定名として例えば“アプリケーション名”とし、クライアント環境から取得した値を、固有設定値として登録することができる。

図１０は、ベンダ固有の印刷設定がある場合に、印刷を制限することを可能とする処理のフローチャートを示す。処理は、ステップＳ１０００から開始し、ステップＳ１００１で図３のプロセスｐ１５の設定値確定時に、ドライバUI監視部２２２が、印刷許可部９０２に対して、現在の固有設定値情報が、印刷制限情報リスト９１０を満たしているか確認する。印刷許可部９０２は、現在の固有設定値情報と印刷制限情報リスト９１０に共に登録されている固有設定すべてについて、その値が等しいことを確認する。

ステップＳ１００１で印刷許可部９０２が固有設定値情報の全てが等しいことを確認すると（ｙｅｓ）、ドライバUI監視部２２２は、ステップＳ１００２で印刷要求開始処理を実行させる。

一方、固有設定値情報において1つでも異なる値があった場合、ドライバUI監視部２２２は、印刷要求開始処理を依頼せず、印刷を実行させず、処理をステップＳ１００３で終了させるので、印刷は行われない。さらに他の実施形態では、ステップＳ１００１の処理を、図３のプロセスｐ８およびｐ９のステージで実行させ、固有設定値情報が一致していない場合に、OSが強制的にドライバUI上のUIコンポーネントの設定値を変更することにより、ユーザに特定の設定を強制する様に印刷制限を行うことができる。

さらに以下、図１１を使用して第３の実施形態について説明する。第３の実施形態は、印刷実行時のクライアント環境も同時に固有設定として取得することを可能とする処理である。この様な処理を適用する具体的用途は、印刷を実行したアプリケーションの名称や、印刷時その印刷を実行したアプリケーションと同時に実行されていたアプリケーションの名称、その他システム起動時間やハードウェア情報などをログとして取得することが有効な場合に追加的な処理として実装することができる。

図１１の処理は、ステップＳ１１００から開始し、ステップS１１０１で、クライアント環境から固有設定値を取得する。この処理は、図３のプロセスｐ１５の設定値確定処理時にドライバUI監視部２２２がクライアント環境取得部９０６に、クライアント環境からの固有設定値を取得するよう指示を行う。それを受け、クライアント環境取得部９０６は、事前に実装されていた処理に基づき、クライアント環境から固有設定値を取得する。その後、事前に実装されていた固有設定名と共に取得したクライアント情報を固有設定値情報２３０に追加する。ステップＳ１１０２では、固有設定値情報が印刷制限情報を満たしているか否かを、図１０のステップＳ１１０２と同様にして判断し、満たしている場合（ｙｅｓ）ステップＳ１１０３で印刷要求を開始させ、満たしていない場合（ｎｏ）ステップＳ１１０４で処理を終了させることで印刷制限を行ない、クライアント環境に応じた印刷制限を可能としながらログを取得することが可能とされている。

さらに他の実施形態では、クライアント環境取得部９０６が取得したOS環境を固有設定値情報として使用し、印刷制限情報リスト９１０と比較して、OS環境が異なる場合に、印刷実行を要求せず、OS環境が一致する場合に印刷実行を要求することで、印刷実行時のクライアントのOS環境に応じて印刷を制限することができると共にその状況をログとして記録させることができる。

さらに、他の実施形態では、設定手段としてはドライバUIではなく、ブラウザ手段を使用することができる。この場合、ブラウザ手段のUIコンポーネントについてもドライバUIと同様の方法によりUIコンポーネントおよび固有設定情報を取得でき、その際にもフック関数を構成しておき、ブラウザ手段の起動時に拡張機能として追加するなどすることにより、ブラウザ手段を使用した他の装置の設定に関してもログを取得することが可能となる。

以上のように、本発明によれば、特定のベンダに依存することなく、ベンダ依存の設定情報についても、ユーザが解釈可能な形式で取得して、ログを生成することができる、情報処理装置およびプログラムを提供することができる。

これまで本発明を実施形態をもって説明してきたが、本発明は、説明した実施形態に限定されるものではなく、他の実施形態、追加、変更、削除など、当業者が想到することができる範囲内で変更することができ、いずれの態様においても本発明の作用・効果を奏する限り、本発明の範囲に含まれるものである。

１００ 情報処理装置
１０８ 入出力装置
１１０ インタフェース
１２０ インタフェース
１２２ 記憶装置
１２４ 内部バス
１２８ グラフィック・チップ
１３２ ネットワーク・インタフェース
１３４ ネットワーク
２００ アプリケーション
２０４ ドライバ
２０６ スプーラ
２０８ 通信ライン
２１２ プリンタ
２２０ 固有設定取得部
２２２ 監視部
２２６ 固有設定出力部
２２８ 解析部
２３０ 固有設定値情報
２３２ 固有設定名リスト
２３４ コンポーネント識別情報
４００ ＧＵＩ
４０２ タイトルバー
４０４ チェックボックス
４０６ 表示ラベル
４０８ 表示ラベル
４１０ テキストボックス
４１２ ボタン

特開２００５−１８２４８６号公報

Claims (11)

1. 情報処理装置が処理したデータを他の装置に使用させるための設定情報を構造情報と共に生成する生成手段と、
   生成した前記設定情報を解析し、生成した前記設定情報の値を取得するための構造情報を与える解析手段と、
   前記生成手段が生成した設定情報をログとして取得するための取得手段と、
   生成した前記設定情報の修正を監視し、前記設定情報が修正されたことを検出した場合に修正された設定情報を前記取得手段に登録する監視手段と、
   前記情報処理装置が処理したデータを他の装置に処理依頼した時までに修正された前記設定情報をログ情報として生成するログ記憶手段と
   を含む、情報処理装置。
2. 前記監視手段は、ユーザ入力により設定情報が修正された場合に当該修正の内容を前記取得手段に通知する通知手段を含む、請求項１に記載の情報処理装置。
3. 前記監視手段は、前記構造情報を使用してユーザ入力に対応した修正に関わる前記設定情報を登録する、請求項１または２に記載の情報処理装置。
4. 前記ログ記憶手段は、前記生成手段の初期設定とは異なり、前記生成手段からのユーザ入力を使用して修正された前記設定情報を前記ログ情報として記憶する、請求項１〜３のいずれか１項に記載の情報処理装置。
5. 前記生成手段は、情報処理装置上にユーザ・インタフェースを表示させ、前記解析手段は、前記ユーザ・インタフェースの構造情報を解析して前記設定情報を取得するべき前記ユーザ・インタフェースの構造を取得して、前記設定情報と前記ユーザ・インタフェースの構造とを対応づけて記憶手段に登録させる、請求項１〜４のいずれか１項に記載の情報処理装置。
6. 前記監視手段は、前記設定情報が修正されるときに、修正された構造に対応づけて修正後の設定情報を前記取得手段に通知する、請求項１〜５のいずれか１項に記載の情報処理装置。
7. 前記生成手段が生成する構造情報は、ユーザ・インタフェースを構成するためのコンポーネントの属性および位置情報を含む、請求項１〜６のいずれか１項に記載の情報処理装置。
8. 前記生成手段が生成する構造情報は、タグで指定される入力属性およびタグの配置位置を含む、請求項１〜７のいずれか１項に記載の情報処理装置。
9. 前記生成手段は、プリンタドライバ手段またはブラウザ手段であり、前記監視手段は、通知手段としてフック関数手段を備える、請求項１〜８のいずれか１項に記載の情報処理装置。
10. 前記解析手段はさらに、前記取得手段から前記情報処理装置が処理したデータを作成するためのアプリケーション手段に前記生成手段の生成および終了を通知する第２の通知手段を含む、請求項１〜９のいずれか１項に記載の情報処理装置。
11. 情報処理装置を、請求項１〜１０のいずれか１項に記載の各手段として機能させるための情報処理装置実行可能なプログラム。