JP4350565B2 - 情報処理装置および方法 - Google Patents

Description

本発明は、情報処理装置および方法に関し、特に、デバイスドライバに設定される設定値に従って周辺装置を制御する情報処理装置および方法に関する。

ユーザインターフェース（以下、「ＵＩ」ともいう。）を介して、ユーザから複数の設定値の入力を受け付け、それらの設定値に基づき制御される機器は、数多くある。ホストコンピュータに接続され、そのホストコンピュータにおいて設定された情報に基づき画像形成処理を行う画像形成システム（プリンタシステム）はその一例である。プリンタシステムのホストコンピュータは一般に、印刷動作を制御するいわゆるプリンタドライバ、およびユーザからの印刷設定などを受け付けるＵＩを含む印刷関連処理プログラムを有する。

印刷関連処理プログラムは、ＵＩを介してユーザからの設定値の入力を受け付ける度に、それまでに設定された複数の設定値の中で関連する設定値の値との関係を評価し、設定値間の不整合（コンフリクト）がないかどうかを判別する。コンフリクトの例としては、記録媒体としてセットされたＯＨＰシートに対して両面印刷を行わせるような設定などのユーザにとって不都合と予想される設定や、プリンタに不可能な動作を行わせる設定などがある。

したがって、コンフリクトが存在した場合には、それを回避するためのコンフリクト処理が必要になる。

コンフリクト処理の実現にあたっては、コンフリクトの検知および解消処理を設定値の関係に依存した形で専用のプログラムを用いて記述する、もしくはコンフリクト処理が必要となる複数の設定値の条件を一覧としてファイルに保存し、このファイルをコンフリクト処理プログラムに読み込ませることで、コンフリクト処理プログラムが汎用的に利用できるようにしていたかのどちらかであった。

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

ファイルにコンフリクト処理を保存する際の記述に関しては、設定値間の項目に関するルールを記述するに過ぎず、複数のルールが記述されていたときには、コンフリクト処理とは直接関係のない記述順によって順番に処理されていた。また、コンフリクト処理によって変更された設定値がさらにコンフリクト処理によって変更されるときに、どのルールから設定値が定まっていくのかが明確に定義できないため、記述を行っては実行しコンフリクト処理プログラムが解釈する順番を手探りで探していかなければならず、誤判断や工数の増加につながっていた。

そこで、本発明は、開発者のミスや作業工数を減らすことができるよう、ユーザインターフェースのコンフリクト処理ルールの記述構造を改良することを目的とする。

上記した課題は、本発明の情報処理装置および方法によって解決される。本発明の一側面は、デバイスドライバに設定される設定値に従って周辺装置を制御する情報処理装置に係り、前記デバイスドライバの設定値間の不整合を回避するための、複数のコンフリクト処理ルールを保持する保持手段と、前記複数のコンフリクト処理ルールに従って、対応する設定値の状態を制御する制御手段とを有し、前記複数のコンフリクト処理ルールの少なくともいずれかは、他のコンフリクト処理ルールに対する適用優先度の情報を含むことを特徴とする。

また、本発明の別の側面は、デバイスドライバに設定される設定値に従って周辺装置を制御するための情報処理方法に係り、前記デバイスドライバの設定値間の不整合を回避するための、複数のコンフリクト処理ルールを読み込む読み込みステップと、前記複数のコンフリクト処理ルールに従って、対応する設定値の状態を制御する制御ステップとを有し、前記複数のコンフリクト処理ルールの少なくともいずれかは、他のコンフリクト処理ルールに対する適用優先度の情報を含むことを特徴とする。

本発明によれば、ユーザインターフェースのコンフリクト処理ルールの記述構造が改良され、これにより開発者のミスや作業工数の削減に貢献することができる。

以下、図面を参照して本発明の好適な実施形態について詳細に説明する。

図１は本発明の一実施形態における印刷処理システムのブロック構成図である。なお、特に断らない限り、本発明の機能が実行されるのであれば、単体の機能であっても、複数の機器からなるシステムであっても、ＬＡＮ、ＷＡＮ等のネットワークを介して接続がなされ処理が行われるシステムであっても、本発明を適用できることは言うまでもない。

図１は、一般的なコンピュータを用いた印刷処理システムの例を示している。ＣＰＵ１００はＲＯＭ１０１あるいはＲＡＭ１０２あるいは外部記憶装置１０７に格納されたプログラムに従って装置全体の制御を行う。ＲＡＭ１０２はＣＰＵ１００が各種処理を行う際のワークエリアとして使用される。

ハードディスク装置などで実現される外部記憶装置１０７は、オペレーティングシステム（ＯＳ）１０７１やアプリケーションソフト１０７２、および印刷関連処理プログラム１０７３を記憶している。ここで、印刷関連処理プログラム１０７３は、デバイスドライバとしてのプリンタドライバ１０７４およびプリンタドライバＵＩ制御モジュール１０７５を含む構造である。

キーボード１０３もしくは非図示のマウスなどの入力機器は、ユーザーが各種指示を与えるためのデバイスである。ネットワークＩ／Ｆ１０４１はＬＡＮ１０４もしくは非図示のネットワークに接続しデータの授受を行うためのインターフェースである。モニタＩ／Ｆ１０５１はモニタ１０５に接続しデータの授受を行うためのインターフェースである。プリンタＩ／Ｆ１０６１は、被制御装置であるプリンタ１０６と接続しデータの授受を行うためのインターフェースである。また、１０８は共通データバスである。なお、プリンタ１０６は被制御装置の一例であり、本発明はスキャナ等を被制御装置としても適用可能である。

図２は、実施形態における印刷関連処理プログラム１０７３のプリンタドライバＵＩ制御モジュール１０７５の機能構成を示している。２０３は、各モジュール間のデータの受け渡しやデータの更新等を管理してコンフリクト処理を統括するコンフリクトマネージャである。２０６が、印刷設定画面の表示制御を行うプリンタドライバＵＩである。２０１は、プリンタドライバＵＩ２０６を介して入力される設定値間の不整合を回避するための、複数のコンフリクト処理ルールを記述したコンフリクト処理ルール記述ファイルである。２０２は、コンフリクト処理ルール記述ファイル２０１をロードして、入力された設定値に対してコンフリクト処理ルールを適用し、各機能の状態を推論する推論エンジン、２０４は、各プリンタ機能の状態をリスト形式で表示する状態変数リストであり、ユーザからの入力およびコンフリクト処理ルール記述ファイル２０１の内容に基づき更新されうる。２０５は、プリンタドライバＵＩ２０６が提供する画面表示の基になる帳票としての内部構造体であり、状態変数リスト２０４と連動して各プリンタ機能の状態を所定の形式で表示する。

プリンタドライバＵＩ２０６を介してユーザからの設定情報を受け取ったコンフリクトマネージャ２０３は、コンフリクト処理ルール記述ファイル２０１を参照する。このことは、図示の如くコンフリクト処理ルール記述ファイル２０１からコンフリクトマネージャ２０３に向かう矢印で、「R(Read)」として表示されている。参照の結果、設定情報がコンフリクト処理ルールに適合する場合、コンフリクト処理が適用される。そうして、コンフリクトマネージャ２０３は、状態変数リスト２０４および内部構造体２０５を更新してプリンタドライバＵＩ２０６に反映させる。この更新作業については、図示の如くコンフリクトマネージャ２０３が、状態変数リスト２０４および内部構造体２０５とそれぞれ双方向矢印で結ばれ、「R/W (Read/Write)」として表示されている。

図３は、図２に示した各モジュールで扱われるデータの関連を説明する模式図である。図３において、コンフリクト処理ルール記述ファイル２０１は、推論エンジン２０２にインクルード（ロード）されたかたちで参照される。このコンフリクト処理ルール記述ファイル２０１は、コンフリクトマネージャ２０３にも参照され、それを受けて状態変数リスト２０４が変更されることになる。また、内部構造体２０５と状態変数リスト２０４とは先に述べたとおり連動表示されるものであるから、互いにマッピングされる関係にある。そしてこの状態がプリンタドライバＵＩ２０６の制御によってユーザに見えるかたちで表現される。

図４は、実施形態におけるコンフリクト処理ルールの適用手順を示すフローチャートである。ここでは一例として、プリンタ１０６を制御するためのプリンタドライバ１０７４によってモニタ１０５に各種設定用に表示されるプリンタドライバＵＩ上で行われるコンフリクト処理を説明する。

図４に示す処理は、ＯＳもしくはアプリケーション上で、ユーザーがキーボード１０３などによりプリンタドライバＵＩを開く指示をすることで始まる。ユーザーによるプリンタドライバＵＩを開く指示により、ＯＳ１０７１の管理の下、ＲＡＭ１０２に印刷関連処理プログラム１０７３がロードされる。印刷関連処理プログラムがＲＡＭ１０２にロードされると、まずプリンタドライバＵＩを開くための初期化処理が行われる。推論エンジン２０２は、図６に例示するような表記のコンフリクト処理ルールを記述したファイル２０１をコンフリクトマネージャ２０３を介して、ＲＡＭ１０２の中に読み込む（ステップＳ４０１）。

コンフリクト処理ルール記述ファイル２０１に記述される各ルールは、論理（ロジック）を用いて数学的に形式化される。述語は、「プリンタ機能名（引数）」の形で記述される。引数としては、ON/OFFの他、数値が入る場合もある（例えば、印刷部数等）。本明細書では、このような引数の内容によって現在の状態が表現されうる機能を「状態変数」とよぶ。つまり、各ルールは「状態変数」を用いた論理式で記述される。具体的には、左辺には「プリンタ機能名（引数）」を、右辺には左辺が成り立つための論理条件を記述し、記号「:-」で関係づける。例えば、
A(ON) :- B(ON).
は、「プリンタ機能Bの状態がONのときは、プリンタ機能Aの状態をONとする」という意味のルールになる。

また、式中の記号「,」は「かつ（AND）」の意味で用いられる。例えば、「プリンタ機能Bの状態がON、かつ、プリンタ機能Cの状態がOFFのとき、プリンタ機能Aの状態をONとする」というルールは、
A(ON) :- B(ON), C(OFF).
と記述される。

ここで例えば、コンフリクト処理ルール記述ファイル２０１に、次のようなコンフリクト処理ルールが記述されていたとする。
A(ON) :- B(ON), C(OFF).

状態変数リスト２０４には、図３に示すように、コンフリクト処理ルール記述ファイル２０１に記述されたプリンタの機能名Ａ，Ｂ，Ｃがそれぞれ同名の状態変数として同図中の「キー」欄に記述される。また、各状態変数の現在値（ＯＮ／ＯＦＦなど）が、「値」欄に記述される。ここでは、プリンタ機能名Ａ，Ｂ，Ｃに対応するプリンタドライバＵＩの内部構造体２０５のメンバをそれぞれ ａ，ｂ，ｃで表現する。内部構造体２０５は内部もしくは外部に初期値をもっており、状態変数の値は対応する内部構造体２０５のメンバの初期値に依存する。ａの初期値は０なので、対応する状態変数Ａの値はＯＦＦとなっている。

また、状態変数リスト２０４は、図３に示すように、後述する各ルールの適用順序に関する遅延フラグと遅延情報を持ち、これらによってそれぞれ自分自身が遅延情報を持つかどうか、他の遅延情報を持つかどうかが保存される。詳細は後述する。

推論エンジン２０２はコンフリクトマネージャ２０３からコンフリクト処理ルール記述ファイル２０１を渡され、状態変数の推論を行ってコンフリクト処理ルールの評価を行う。状態変数Ｂの値がＯＮであり、かつ、状態変数ＣがＯＦＦであったときは上記のコンフリクト処理ルールの右辺の評価が成立し、左辺の状態変数Ａの値をＯＮに変更する。コンフリクト処理ルールの推論が終了すると、コンフリクトマネージャ２０３は変更された状態変数の値をプリンタドライバＵＩの内部構造体２０５の対応するメンバａに反映させる。つまり、状態変数Ａの値がＯＦＦからＯＮになったことで、内部構造体２０５のメンバａは上記のコンフリクト処理ルールが成立したことによって、０から１に変更される。

コンフリクト処理ルールでは、プリンタの機能と結び付けられた状態変数のほかに、一時的に値を記憶しておくための状態変数を記述することもできる。一時的に値を記憶しておくための状態変数は推論エンジン２０２がコンフリクト処理ルールに従いコンフリクト処理を行い始めてから、コンフリクト処理を終了するまで、推論エンジン２０２の内部に値が保存される。一時的な状態変数なので、コンフリクト処理が終了すれば消える揮発性のデータとなる。

一時的な状態変数の記述の方法は、状態変数リスト２０４に持たないキー名称をコンフリクト処理ルール内で状態変数として記述しておくと、推論エンジン２０２はこれを一時的な状態変数とみなして処理を行う。一時的な状態変数は初期の値を定めることができないので、作成された段階での初期の値は不定値となる。

一時的な状態変数は、複雑なコンフリクト処理の最中で、途中のコンフリクト処理の状態を覚えておきたいときや、１対多のコンフリクト処理ルールの対応付けをとるのに利用することができる。

ここで、コンフリクト処理ルール記述ファイル２０１に、図６のようなコンフリクト処理ルールが記述されており、これをコンフリクトマネージャ２０３が推論エンジン２０２に渡すとする。推論エンジン２０２はコンフリクト処理ルール記述ファイル２０１を、記述された順に従って自身の持つ待ち行列に追加し、図９のフローチャートに従って評価を開始する。

推論エンジン２０２は自身の待ち行列の先頭から、コンフリクト処理ルールを取り出す（ステップＳ９０１）。すなわち、まず図６の６０１で示されるルール
A(ON) :- B(OFF), wait([C]).
が取り出される。

次に、取り出したルールの右辺に制御記号「wait」が含まれているか否かを判断する（ステップＳ９０２）。この制御記号「wait」は、この制御記号が記述されているコンフリクト処理ルールの、他のコンフリクト処理ルールに対する適用優先度の情報を表す。６０１のルールにはこの「wait」が含まれている。このように右辺に「wait」の記号があったときは、図３に示すように、「wait」で指定された状態変数Ｃに対し状態変数リスト２０４における遅延フラグを「TRUE」とするとともに、左辺に対応する状態変数Ａに対し遅延情報として「Ｃ」を記述する（ステップＳ９０３）。これにより状態変数Ａは状態変数Ｃが先に評価されるのを待っていることが示される。

次に、右辺から「wait」を取り除いたルールを生成する（ステップＳ９０４）。すなわち、６０１のルールから、
A(ON) :- B(OFF). （603）
が生成される。そして、この６０３のルールを待ち行列の最後に挿入する（ステップＳ９０５）。

その後、ステップＳ９０１に戻って、次のコンフリクト処理ルール、すなわち、６０２で示されるコンフリクト処理ルール
B(OFF) :- C(ON).
を待ち行列から取り出し、ステップＳ９０２で、右辺に「wait」の記号が含まれているか否かを判断する。この場合には右辺に「wait」は存在しないので、ステップＳ９０６に進み、右辺の評価を行う。推論エンジン２０２は、左辺の状態変数Ｂにおける遅延情報が状態変数Ｃに結び付けられているかどうかを判定する（ステップＳ９０７）。しかしこの例では、６０２のルールの左辺にある状態変数Ｂには状態変数Ｃに関する遅延情報はないので、そのままステップＳ９１０に進み、式の評価を行う。推論エンジン２０２は式を評価し、６０２のルールに従い、状態変数Ｃの値をコンフリクトマネージャ２０３に問い合わせた後、状態変数Ｃの値がＯＮであれば状態変数Ｂの値をＯＦＦにする。そして、状態変数Ｃの遅延フラグを「FALSE」に変更し、状態変数Ｃに関する処理が終わったことを示す。

ステップＳ９１１では、待ち行列にルールがあるかどうかをチェックする。ここで待ち行列にルールがなくなればこの処理を終了することになるが、この例では、ステップＳ９０５で、６０１のルールから「wait」を取り除いたルール６０３が待ち行列の最後に挿入されたので、処理はステップＳ９０１に戻り、ルール６０３を取り出す。この場合、ルール６０３の右辺に「wait」は存在しないので、ステップＳ９０２からステップＳ９０６に進み、右辺の評価を開始する。ステップＳ９０７では、左辺の状態変数Ａにおける遅延情報が状態変数Ｃに結び付けられているかどうかを判定する。この例では、先ほどのステップＳ９０３でルール６０１の左辺にある状態変数Ａの遅延情報が状態変数Ｃに結び付けられているので、処理はステップＳ９０８に進む。

ステップＳ９０８では、「wait」が付いた状態変数のルールをすべて評価したかどうかを検査する。すなわち、状態変数Ａに結び付けられた遅延情報の状態変数Ｃが評価されたかどうかを確認する。ここで、すべて評価されていないときはステップＳ９０５に進むが、この例では、ルール６０２を評価したステップＳ９１０で状態変数Ｃから遅延フラグが下りていることから、すべて評価されていると判断され、ステップＳ９０９に進む。ステップＳ９０９では、状態変数Ａの遅延情報を削除し、その後、ステップＳ９１０で、式を評価する。

なお、コンフリクト処理ルールの記述順や評価を行う過程によっては、ステップＳ９０８において、「wait」のない状態変数Ｃの評価がすべて終了したことを判定できない場合があり得る。そのような場合には無限ループに陥ってしまい処理を終了できないことになる。そこで、ステップＳ９１０が行われずにステップＳ９０１に戻った回数をカウントしておき、そのカウント値が所定回数を超えると、待ち処理をあきらめステップＳ９０７からステップＳ９１０に強制的に進めるようにすることで、無限ループに陥ることを防止することが好ましい。

さて、図５に示したコンフリクト処理ルールの例と図６のコンフリクト処理ルールの例とを比較すると、図５のコンフリクト処理ルールでは、記述順にルールが評価される場合には、状態変数ＢがＯＮだったときとＯＦＦだったときで、状態変数Ａの値が異なってしまうが、図６に示したような「wait」の記述によりルールの適用順序を制御することで、状態変数Ａが不定になることを防止できる。

以上のような処理によって他に適用されるコンフリクト処理ルールがなくなった時点で、図７に例示するようなプリンタドライバＵＩをオープンする（ステップ４０２）。

プリンタドライバＵＩがオープンされた後は、ＯＳより送られてくるイベントの取得とその処理を繰り返す（ステップＳ４０３）。ステップＳ４０４では、ステップＳ４０３にて取得したイベントが、ユーザーがプリンタドライバＵＩ上の設定項目を変更したイベントであるかどうかの判断を行う。ここで、イベントがユーザーの設定項目変更要求であった場合には、その設定項目に対する内部構造体のメンバがコンフリクトマネージャによって変更され、同じくコンフリクトマネージャによって対応づけられた状態変数が変更され、推論エンジンがコンフリクト処理ルールをもとに、上記のコンフリクト処理を行う（ステップＳ４０５）。

他に適用されるコンフリクト処理ルールがなくなった時点で、コンフリクトマネージャがコンフリクト処理によって変更があったすべての状態変数を、対応する内部構造体のメンバに適用する（ステップＳ４０６）。コンフリクトマネージャは変更された内部構造体のメンバから、ＵＩの更新が必要かどうかの判別を行う（ステップ４０７）。ＵＩの更新が必要ない場合はそのままステップＳ４０３に戻るが、更新が必要な場合は、ＵＩの更新処理を行い（ステップＳ４０８）、その後ステップＳ４０３に戻る。

また、ステップＳ４０４において、取得したイベントがユーザーの設定項目変更要求でなかった場合には、ステップＳ４０９に進み、そのイベントがユーザーによってプリンタドライバＵＩのクローズ要求かどうかを判別する。ここで、そのイベントがクローズ要求だった場合には、プリンタドライバＵＩをクローズし終了処理を行って（ステップＳ４１０）、本処理を終了し（ステップＳ４１１）、そうでなければ、ステップＳ４０３に戻って処理を繰り返す。

以上の処理は、ユーザーによってプリンタドライバＵＩがクローズされるまで繰り返し実行される。プリンタドライバＵＩがクローズされると処理はすべて終了し、本実施形態における印刷関連処理プログラムの処理も終了し、ＲＡＭ１０３からはＯＳ１０７１の機能により消去される。プリンタドライバＵＩで使用されていた内部構造体２０５は、プリンタ１０６もしくはＯＳ１０７１に反映され、ユーザーがプリンタ１０６に対して印刷を行う指示をするときに使用される。

なお本実施形態においては、本印刷関連処理プログラムを記録する媒体を外部記憶装置１０７としているが、外部記憶装置は、ＦＤ、ＨＤＤ、光ディスク媒体、ＩＣメモリーカードなどであってもよい。さらに、本印刷関連処理プログラム単独、もしくはＯＳそのほかコンピュータ上で動作するプログラムとともにＲＯＭ１０１に記録しておき、これをメモリマップの一部としてなすように構成し、直接ＣＰＵ１００で実行することも可能である。

また、上述した実施形態では、コンフリクト処理ルールの順番待ちを１つのルールを加えることで実現しているが、かわりに、図８に示すように、一連の複数のコンフリクト処理ルールをまとめて、そのひとまとまりの中でのみ互いのルールおよび状態変数が干渉し、それ以外は一切評価を行わないといった意味の、スコープ「｛」、「｝」で表現することも可能である。たとえば、推論エンジン２０２はスコープの始まりを検知すると、いったんスコープ内に記述されたコンフリクト処理ルールを、スコープが現れる順にスコープ番号を添付して順番待ち行列に入れ込む。スコープ内のコンフリクト処理ルールを評価するためには、互いのスコープの順序を記述したコンフリクト処理ルールがあればその順番に従い、存在しないときはスコープの記述順に評価する。コンフリクト処理ルールは、それぞれスコープ番号をもっており、ひとつコンフリクト処理ルールを評価すると、他のスコープ番号のルールが待ち行列から取り出されても、推論エンジンは評価を行わない。これによって、互いに優先順位をつけることができる。

以上説明した実施形態によれば、プログラム開発者などが用意するコンフリクト処理ルールで作成されるコンフリクト条件を、推論エンジンに規則的な順序を守って評価をさせることができるので、推論エンジンの動作による結果を表現しやすく、品質の高いコンフリクト処理を実現できるようになる。

また、コンフリクト処理ルールの評価が始まる順番によって、結果が変化してしまう従来の問題を防ぐことができる。例えば、図１０と図１１に示したコンフリクト処理ルールを比べると、両者は同様の内容であるが、図１１の第１，３行のルールには適用順序に係る制御記号「wait」が記述されている。図１０の場合、状態変数ＣもＤもＯＮだったときは、状態変数Ｂが先にＯＮになるかＯＦＦかは評価次第になってしまい、その結果、第１，３行のルールによってＢの状態に依存する状態変数Ａも先にＯＮになるかＯＦＦになるかはこれだけでは判定することができない。これはプログラム開発者としては意図した方向にコンフリクト処理を割り振ることができない一例である。一方、図１１の記述であれば、第１行のルールは状態変数Ｃのルールに結びつけられていることが確認でき、また、第３行のルールは状態変数Ｄのルールに結びつけられていることが確認できるため、意図した順に状態変数Ａ，Ｂを変化させることができる。

制御記号「wait」の使用によって、コンフリクト処理ルールの評価が始まる順番により結果が変化してしまう従来の問題が防止される例を以下に示す。コンフリクト処理ルールとして以下のようなルールを作成したとする。

$TEMP(OFF) :- Layout$Printing(BOOKLET). (1)
$TEMP2(OFF) :- $TEMP(OFF). (2)
$TEMP3(OFF) :- $TEMP2(OFF). (3)
Layout$Scaling(OFF) :- Layout$Printing(TWOSIDED). (4)
Layout$Scaling(OFF) :- $TEMP3(OFF). (5)

これは、印刷の方法（Printing）として製本印刷（BOOKLET）を選択したとき、もしくは両面印刷（TWOSIDED）を選択したときには、印刷データのスケーリング機能（Scaling）をOFFにする、という仕様に基づき作成されたコンフリクト処理ルールである。

この例において、“$”で始まる状態変数は一時的な状態変数、“Layout$”で始まる状態変数は実際のプリンタ機能に結びついた状態変数であるとする。製本印刷も両面印刷もどちらも同じことを行おうとしているが、製本印刷においては一時的な状態変数を用いる点が異なっている。

ここでユーザの操作により、製本印刷が選択されたとしてコンフリクト処理を開始する。仕様から判断すると、(1)→(2)→(3)→(4)→(5)の順番でコンフリクト処理ルールが評価されることを期待して記述したコンフリクト処理ルールであることから、順を追って処理を見ていく。まず、製本印刷が選択されると、(1)のルールが成立し、一時的な状態変数$TEMPがOFFになる。次に、$TEMPがOFFであることから(2)のルールが成立し、$TEMP2がOFFになる。そして、$TEMP2がOFFであることから(3)のルールが成立し$TEMP3がOFFになる。次に(4)のルールが評価されるが、印刷の方法は製本印刷であるため、(4)のルールは成立しない。そして(5)のルールが評価され、印刷データのスケーリング機能（Scaling）がOFFになる。

しかし、実際の動作は推論エンジンによる状態変数の推論が行われるため、必ずしも上から順にルールが評価されるわけではない。状態変数の推論は、状態変数の値が変化したことに関連する状態変数のコンフリクトルールを全体のルールから導き出し、関連するコンフリクトルールを先行して評価することで、すべてのコンフリクト処理ルールを値が変化することに評価するような処理のオーダ（手間）を省き、無限ループに陥ることを防止するように動作する。

したがって、このルールにおいては製本印刷が選択されたときに(1)→(2)→(4)→(5)→(3)と評価することも起こりうる。この場合、(5)の評価が行われるタイミングでは、$TEMP3の値はOFFになっておらず、一時的な状態変数の初期値である不定値状態のままである。したがって、(5)の評価は失敗してしまい、倍率がOFFにならなくなってしまう。

このようなときに「wait」の機能を使用する。(5)のルールを以下のように書き換える。

Layout$Scaling(OFF) :- $TEMP3(OFF), wait([$TEMP3]). (5’)

これにより、$TEMP3に関連するコンフリクト処理ルール（ここでは(3)を指す）が評価される前に(5’)の評価が行われても、$TEMP3に関連するコンフリクト処理ルールが評価されていない間は待ち行列の最後に挿入されるため、(3)の評価が行われる前に実際に評価されることはない。

このように、コンフリクト処理ルール同士に順序がつけられることによって、現在あるコンフリクト処理ルールに対して、ルールの追加・削除が容易に行うことができる。

また、ユーザインターフェースの更新処理、メッセージ処理もコンフリクト処理ルールに加えることで、開発者にとって可読性の高く、メンテナンスも容易なコーディングを実現することができる。さらには、ドライバのコンフリクト処理を一部だけカスタマイズするときに、ユーザインターフェース制御部のコーディングをまったく変更することなくカスタマイズが可能という効果ももたらす。その際に本発明と組み合わせれば、推論エンジンの動作を詳細に理解することなく、コンフリクト処理ルールを容易に記述し、期待した結果が得られる効果がある。

（他の実施形態）
以上、本発明の実施形態を詳述したが、本発明は、例えばシステム、装置、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能である。また、本発明は、複数の機器から構成されるシステムに適用してもよいし、また、一つの機器からなる装置に適用してもよい。

なお、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラムを、システムあるいは装置に直接あるいは遠隔から供給し、そのシステムあるいは装置のコンピュータがその供給されたプログラムコードを読み出して実行することによっても実現される。その場合、プログラムの機能を有していれば、その形態はプログラムである必要はない。

従って、本発明の機能処理をコンピュータで実現するために、そのコンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明の特許請求の範囲には、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。

その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。

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

その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続し、そのホームページから本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。

また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。

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

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

実施形態における印刷処理システムのブロック構成図である。 実施形態におけるプリンタドライバＵＩ制御モジュールの機能構成を示す図である。 実施形態におけるコンフリクト処理に係るデータの関連を示す例である。 実施形態におけるコンフリクト処理ルールの適用手順を示すフローチャートである。 ルールの適用順序に係る制御コマンドを含まないコンフリクト処理ルールの記述例を示す図である。 ルールの適用順序に係る制御コマンドを含んだコンフリクト処理ルールの記述例を示す図である。 実施形態におけるプリンタドライバＵＩの一例を示す図である。 スコープを適用したコンフリクト処理ルールの記述例を示す図である。 実施形態におけるコンフリクト処理ルール記述ファイルの読み込み処理を示すフローチャートである。 ルールの適用順序に係る制御記号の効果を説明するための図である。 ルールの適用順序に係る制御記号の効果を説明するための図である。

Claims (12)

1. デバイスドライバに設定される設定値に従って周辺装置を制御する情報処理装置であって、
   前記デバイスドライバの設定値間の不整合を回避するための、複数のコンフリクト処理ルールを保持する保持手段と、
   前記複数のコンフリクト処理ルールに従って、対応する設定値の状態を制御する制御手段と、
   を有し、
   前記複数のコンフリクト処理ルールの少なくともいずれかは、他のコンフリクト処理ルールに対する適用優先度の情報を含むことを特徴とする情報処理装置。
2. 前記制御手段は、前記適用優先度の情報に応じた順序で各コンフリクト処理ルールを適用することを特徴とする請求項１に記載の情報処理装置。
3. 前記適用優先度の情報は、特定の状態変数に係る後続のコンフリクト処理ルールを優先適用するよう指示する制御情報として記述され、
   前記制御手段は、読み出したコンフリクト処理ルールから前記制御情報を抽出し、当該制御情報に基づき優先適用すべき他のコンフリクト処理ルールを読み出し、該他のコンフリクト処理ルールを評価することを特徴とする請求項２に記載の情報処理装置。
4. 前記デバイスドライバの設定値は、印刷方法として両面印刷又は製本印刷の指定情報、および、印刷データのスケーリング機能の有効／無効を示すＯＮ／ＯＦＦの情報を含み、
   前記複数のコンフリクト処理ルールは、印刷方法として両面印刷又は製本印刷が指定されている場合は印刷データのスケーリング機能をＯＦＦに設定する、という論理を含む
   ことを特徴とする請求項１から３までのいずれか１項に記載の情報処理装置。
5. 前記優先適用度の情報は、印刷方法の指定に係るコンフリクト処理ルールを優先して適用するよう指示する制御情報として、印刷データのスケーリング機能に係るコンフリクト処理ルール中に記述されることを特徴とする請求項４に記載の情報処理装置。
6. デバイスドライバに設定される設定値に従って周辺装置を制御するための情報処理方法であって、
   前記デバイスドライバの設定値間の不整合を回避するための、複数のコンフリクト処理ルールを読み込む読み込みステップと、
   読み込んだ前記複数のコンフリクト処理ルールに従って、対応する設定値の状態を制御する制御ステップと、
   を有し、
   前記複数のコンフリクト処理ルールの少なくともいずれかは、他のコンフリクト処理ルールに対する適用優先度の情報を含むことを特徴とする情報処理方法。
7. 前記制御ステップは、前記適用優先度の情報に応じた順序で各コンフリクト処理ルールを適用することを特徴とする請求項６に記載の情報処理方法。
8. 前記適用優先度の情報は、特定の状態変数に係る後続のコンフリクト処理ルールを優先適用するよう指示する制御情報として記述され、
   前記制御ステップは、読み出したコンフリクト処理ルールから前記制御情報を抽出し、当該制御情報に基づき優先適用すべき他のコンフリクト処理ルールを読み出し、該他のコンフリクト処理ルールを評価することを特徴とする請求項７に記載の情報処理方法。
9. 前記デバイスドライバの設定値は、印刷方法として両面印刷又は製本印刷の指定情報、および、印刷データのスケーリング機能の有効／無効を示すＯＮ／ＯＦＦの情報を含み、
   前記複数のコンフリクト処理ルールは、印刷方法として両面印刷又は製本印刷が指定されている場合は印刷データのスケーリング機能をＯＦＦに設定する、という論理を含む
   ことを特徴とする請求項６から８までのいずれか１項に記載の情報処理方法。
10. 前記優先適用度の情報は、印刷方法の指定に係るコンフリクト処理ルールを優先して適用するよう指示する制御情報として、印刷データのスケーリング機能に係るコンフリクト処理ルール中に記述されることを特徴とする請求項９に記載の情報処理方法。
11. デバイスドライバに設定される設定値に従って周辺装置を制御するための、コンピュータによって実行されるプログラムであって、
    前記デバイスドライバの設定値間の不整合を回避するための、複数のコンフリクト処理ルールを読み込んでメモリに格納するためのコードと、
    読み込んだ前記複数のコンフリクト処理ルールに従って、対応する設定値の状態を制御するためのコードと、
    を含み、
    前記複数のコンフリクト処理ルールの少なくともいずれかは、他のコンフリクト処理ルールに対する適用優先度の情報を含む
    ことを特徴とするプログラム。
12. デバイスドライバに設定される設定値に従って周辺装置を制御するための、コンピュータによって実行されるプログラムを格納した記憶媒体であって、前記プログラムは、
    前記デバイスドライバの設定値間の不整合を回避するための、複数のコンフリクト処理ルールを読み込んでメモリに格納するためのコードと、
    読み込んだ前記複数のコンフリクト処理ルールに従って、対応する設定値の状態を制御するためのコードと、
    を含み、
    前記複数のコンフリクト処理ルールの少なくともいずれかは、他のコンフリクト処理ルールに対する適用優先度の情報を含む
    ことを特徴とする記憶媒体。

Images