所定の関数インタフェースを介してスプーラからの印刷データに関する要求を受け付ける要求受付手段と、前記要求に応じた処理を実行する少なくとも1つの処理実行手段と、前記要求受付手段は、前記要求を受け付ける際に、前記処理実行手段に対して当該受け付けた要求に応じた処理を実行させる情報処理装置。複数の前記処理実行手段と、前記処理実行手段ごとに、前記関数インタフェースの関数名を関連付けて記憶する記憶手段とを有し、前記要求受付手段は、前記要求の受け付けに応じ、当該要求に係る前記関数インタフェースの関数名に関連付けられている前記処理実行手段に当該要求に応じた処理を実行させる請求項1記載の情報処理装置。前記要求受付手段は、前記関数名に関連付けられている前記処理実行手段が複数有る場合は、当該複数の前記処理実行手段に前記要求に応じた処理を実行させる請求項2記載の情報処理装置。前記記憶手段は、前記処理実行手段の有効性を示す情報を記憶し、前記要求受付手段は、複数の前記処理実行手段の中で、前記情報に基づいて有効であると判定される前記処理実行手段に前記要求に応じた処理を実行させる請求項3記載の情報処理装置。所定の関数インタフェースを介してスプーラからの印刷データに関する要求を受け付ける要求受付手順と、少なくとも1つの処理実行手段が前記要求に応じた処理を実行する処理委譲手順とをコンピュータに実行させ、前記処理委譲手順は、前記要求受付手順が前記要求を受け付ける際に、前記処理実行手段に対して当該受け付けた要求に応じた処理を実行させるプログラム。前記処理委譲手順は、複数の前記処理実行手段のそれぞれごとに前記関数インタフェースの関数名を関連付けて記憶する記憶手段を参照して、前記要求に係る前記関数インタフェースの関数名に関連付けられている前記処理実行手段に当該要求に応じた処理を実行させる請求項5記載のプログラム。前記処理委譲手順は、前記関数名に関連付けられている前記処理実行手段が複数有る場合は、当該複数の前記処理実行手段に前記要求に応じた処理を実行させる請求項6記載の情報処理装置。前記記憶手段は、前記処理実行手段の有効性を示す情報を記憶し、前記処理委譲手順は、複数の前記処理実行手段の中で、前記情報に基づいて有効であると判定される前記処理実行手段に前記要求に応じた処理を実行させる請求項7記載のプログラム。しかしながら、ランゲージモニタは、スプーラのプロセスの起動時にロードされ、終了時にアンロードされるDLLDynamicLinkLibraryである。すなわち、スプーラのプロセスが停止されない限り、ランゲージモニタは、OSOperatingSystemの起動直後からシャットダウンまでの間ロードされたままとなる。したがって、新たな機能が実装された新しいランゲージモニタをインストールし、当該ランゲージモニタの機能を有効とするためには、当該ランゲージモニタのインストール後に、スプーラのプロセスを再起動しなければならないという問題があった。スプーラの再起動が実行されると、スプーラに蓄積されていた印刷データが破棄されてしまう可能性がある。特に、多数のクライアントPCからの印刷データを処理するプリントサーバのスプーラに蓄積されていた印刷データの破棄は、多数のユーザに影響が及ぶ。このような理由等から、ランゲージモニタを利用したプリンタドライバの導入すなわち、係るプリンタドライバが対応するプリンタの導入が敬遠されかねない。本発明は、上記の点に鑑みてなされたものであって、スプーラの再起動を回避しつつランゲージモニタの更新を有効化することのできる情報処理装置及びプログラムの提供を目的とする。そこで上記課題を解決するため、情報処理装置は、所定の関数インタフェースを介してスプーラからの印刷データに関する要求を受け付ける要求受付手段と、前記要求に応じた処理を実行する少なくとも1つの処理実行手段と、前記要求受付手段は、前記要求を受け付ける際に、前記処理実行手段に対して当該受け付けた要求に応じた処理を実行させる。本発明によれば、スプーラの再起動を回避しつつランゲージモニタの更新を有効化することができる。以下、図面に基づいて本発明の実施の形態を説明する。図1は、第一の実施の形態における印刷システムの構成例を示す図である。同図において、一以上の情報処理装置10と一以上のプリンタ20とは、LANLocalAreaNetwork等のネットワーク30有線又は無線の別は問わない。を介して通信可能に接続されている。プリンタ20は、いわゆるプリンタである。本実施の形態において、プリンタ20は、情報処理装置10より転送される印刷データに関して印刷を行う。なお、複合機のように、プリンタ以外の機能を有する機器がプリンタ20として用いられてもよい。情報処理装置10は、プリンタ20に対して印刷データを転送する印刷要求を行うコンピュータである。情報処理装置10は、ユーザごとに設置され、ユーザによって直接操作されるPCPersonalComputerであってもよいし、プリントサーバとして機能するコンピュータであってもよい。本実施の形態では、ユーザによって直接操作されるPCであるとする。図2は、第一の実施の形態における情報処理装置のハードウェア構成例を示す図である。図2の情報処理装置10は、それぞれバスBで相互に接続されているドライブ装置100、補助記憶装置102、メモリ装置103、CPU104、インタフェース装置105、表示装置106、及び入力装置107等を有する。情報処理装置10での処理を実現するプログラムは、CD-ROM等の記録媒体101によって提供される。プログラムを記録した記録媒体101がドライブ装置100にセットされると、プログラムが記録媒体101からドライブ装置100を介して補助記憶装置102にインストールされる。但し、プログラムのインストールは必ずしも記録媒体101より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置102は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。メモリ装置103は、プログラムの起動指示があった場合に、補助記憶装置102からプログラムを読み出して格納する。CPU104は、メモリ装置103に格納されたプログラムに従って情報処理装置10に係る機能を実現する。インタフェース装置105は、ネットワークに接続するためのインタフェースとして用いられる。表示装置106はプログラムによるGUIGraphicalUserInterface等を表示する。入力装置107はキーボード及びマウス等で構成され、様々な操作指示を入力させるために用いられる。図3は、第一の実施の形態における情報処理装置のソフトウェア構成例を示す図である。同図において、情報処理装置10は、アプリケーション11、GDI12、プリンタドライバ13、スプーラ14、ランゲージモニタ15、フィルタ構成情報記憶部16、及びポートモニタ17等を有する。アプリケーション11、GDI12、一以上のプリンタドライバ13、スプーラ14、ランゲージモニタ15、及びポートモニタ17は、それぞれに実装された処理をCPU104に実行させることにより、それぞれの機能を実現する。アプリケーション11は、例えば、ユーザによる対話的な操作に応じ、印刷対象とされる文書データを生成するプログラムである。GDI12は、いわゆるGDIGraphicDeviceInterfaceであり、非図示のOS例えば、Windows登録商標によって提供されるグラフィック関数の集合である。アプリケーション11は、印刷指示の入力に応じ、GDI12を介して、プリンタドライバ13への印刷要求を入力する。例えば、GDI12は、プリンタドライバ13が備えるDDIDeviceDriverInterfaceと呼ばれるインタフェースを介して、アプリケーション11からの印刷要求に応じたコマンドをプリンタドライバ13に入力する。プリンタドライバ13は、UIドライバ131、グラフィックドライバ132等を含む。これら各構成要素は、例えば、それぞれが独立したプログラムモジュール例えば、DLLDynamicLinkLibraryであってもよい。UIドライバ131は、印刷設定情報印刷条件又は印刷属性等とも呼ばれるを設定させるための画面等を表示装置106に表示させ、印刷設定情報の設定を受け付ける。グラフィックドライバ132は、DDIを介して入力されるコマンド及びUIドライバ131が受け付けた印刷設定情報に応じた印刷データRAWデータを生成する。グラフィックドライバ132によって生成された印刷データは、スプーラ14に入力される。本実施の形態のプリンタドライバ13は、更に、一以上のフィルタ133を含む。一つのフィルタ133は、DLL等、動的にロード及びアンロードが可能であって、かつ、動的にリンク可能なプログラムモジュールである。フィルタ133には、ランゲージモニタ15に実行させたい処理が実装される。すなわち、本実施の形態において、ランゲージモニタ15に実行させたい処理の実体は、フィルタ133に実装される。具体的には、フィルタ133は、ランゲージモニタ15としての関数インタフェースAPIApplicationProgramInterfaceと同様の関数インタフェースを一以上有し、当該関数インタフェースに対する実装を有する。スプーラ14は、それ自体が一つのプロセスとして起動されるプログラムである。スプーラ14は、グラフィックドライバ132によって生成された印刷データを、補助記憶装置102を用いて一時的に保持する。その後、スプーラ14は、印刷データをランゲージモニタ15に入力する。ランゲージモニタ15は、スプーラ14から利用されるDLLであり、スプーラ14の起動時にロードされる。本実施の形態のランゲージモニタ15は、ランゲージモニタインタフェース151及びフィルタマネージャ152等を含む。ランゲージモニタインタフェース151は、ランゲージモニタとしての関数インタフェースを有し、当該関数インタフェースを介してスプーラ14からの要求を受け付ける。但し、ランゲージモニタインタフェース151自体は、当該要求に応じた処理は実行せずに、当該処理の実行をフィルタ133に委譲する。フィルタマネージャ152は、フィルタ構成情報記憶部16を参照して、スプーラ14から要求された処理の委譲先とするフィルタ133を判定する。フィルタマネージャ152は、また、処理の委譲先として判定されたフィルタ133について、メモリ装置103へのロード及びアンロードを実行する。フィルタ構成情報記憶部16は、関数インタフェースの関数名と、当該関数インタフェースに対する実装を有するフィルタ133との対応情報以下、フィルタ構成情報という。を記憶する。なお、フィルタ構成情報記憶部16は、補助記憶装置102を用いて実現可能である。例えば、Windows登録商標において、各種の設定情報を保持するために利用されるレジストリ内にフィルタ構成情報が記録されてもよい。ポートモニタ17は、ランゲージモニタ15実際には、フィルタ133によって処理された印刷データをプリンタ20に送信する。以下、情報処理装置10の処理手順について説明する。図4は、情報処理装置の起動時に実行される処理手順の一例を説明するためのシーケンス図である。ステップS101において、スプーラ14は、OSよりプロセスとして起動されると、ランゲージモニタインタフェース151が有する関数の一つであるOpenPortExを呼び出すS102。OpenPortExは、スプーラ14が起動時に呼び出すことになっている関数である。スプーラ14は、情報処理装置10において設定されている論理プリンタごとに当該論理プリンタの論理プリンタ名を引数に指定して、OpenPortExを呼び出す。なお、ランゲージモニタ15は、スプーラ14の起動に伴ってロードされ、利用可能呼び出し可能な状態となる。情報処理装置10の起動時以外において、例えば、論理プリンタが新たに追加された場合にも、スプーラ14は、ランゲージモニタインタフェース151のOpenPortExを呼び出す。この際、新たに追加された論理プリンタの論理プリンタ名が、OpenPortExの引数に指定される。続いて、OpenPortExの呼び出しに応じてランゲージモニタインタフェース151が実行する処理すなわち、OpenPortExに関してランゲージモニタインタフェース151に実装されている処理の処理手順の一例について説明する。図5は、OpenPortExの呼び出しに応じてランゲージモニタインタフェースが実行する処理の処理手順の一例を説明するためのフローチャートである。ステップS111において、ランゲージモニタインタフェース151は、論理プリンタ名を格納するための項目メンバ変数を有する構造体をメモリ装置103ヒープ領域に生成する。続いて、ランゲージモニタインタフェース151は、OpenPortExの引数に指定されている論理プリンタ名を、当該構造体において論理プリンタ名を格納するためのメンバ変数にコピーするS102。続いて、ランゲージモニタインタフェース151は、当該構造体の先頭のアドレス値を、ハンドル識別子としてスプーラ14に返却するS103。以後、スプーラ14からのランゲージモニタインタフェース151の関数の呼び出し時には、当該ハンドルが論理プリンタの識別子として指定される。続いて、図4及び図5の初期化処理が行われた後に、スプーラ14からの関数インタフェースの呼び出しに応じてランゲージモニタ15等が実行する処理手順の一例について説明する。図6は、第一の実施の形態においてスプーラからの関数呼び出しに応じてランゲージモニタ等が実行する処理手順の一例を説明するためのシーケンス図である。ステップS201において、スプーラ14は、ランゲージモニタインタフェース151の或る関数を呼び出す。同図では、SendRecvBidiDataFromPortが呼び出された例が示されている。なお、当該関数の引数には、図5のステップS113においてスプーラ14に対して返却されているハンドルが指定される。当該ハンドルは、論理プリンタごとに返却されている。したがって、スプーラ14は、印刷ジョブの対象となっている論理プリンタに対応するハンドルを引数に指定する。続いて、ランゲージモニタインタフェース151は、呼び出された関数以下、呼び出し関数という。の関数名SendRecvBidiDataFromPortを示す文字列を指定して、フィルタマネージャ152に対してフィルタリストの取得要求を行うS202。フィルタリストとは、各フィルタ133における、呼び出し関数のアドレスの一覧情報をいう。当該取得要求には、スプーラ14から指定された引数がそのまま指定される。また、当該取得要求には、論理プリンタ名も引数として指定される。すなわち、ランゲージモニタインタフェース151は、ステップS201において指定されたハンドルに対応する構造体より論理プリンタ名を取得し、当該論理プリンタ名を当該取得要求に指定する。なお、ハンドルに対応する構造体とは、ハンドルが示すアドレスを先頭アドレスとする構造体をいう。当該取得要求に応じ、フィルタマネージャ152は、フィルタ構成情報記憶部16が記憶するフィルタ構成情報を読み込み、呼び出し関数の実装を有するフィルタ133を判定するS203。図7は、第一の実施の形態のフィルタ構成情報の管理形態及びフィルタ構成情報の一例を示す図である。同図において、フィルタ構成情報は、論理プリンタごとに管理されている。具体的には、各フィルタ構成情報は、論理プリンタ名に関連付けられて管理されている。例えば、フィルタ構成情報がレジストリ内に管理される場合、論理プリンタ毎に生成されるレジストリキーの下のPrinterDriverDataキーに対するデータとして、フィルタ構成情報が記録されてもよい。フィルタ構成情報は、論理プリンタの生成時等に、例えば、UIドライバ131が記録する。同図において、フィルタ構成情報D1aは、論理プリンタA用のフィルタ構成情報である。フィルタ構成情報D1aは、JSONJavaScriptObjectNotationに準拠した形式で記述されているが、XMLeXtensibleMarkupLanguage形式等、他の形式によって記述されてもよい。フィルタ構成情報D1aの定義51及び定義52は、論理プリンタAに対応する各フィルタ133に関する定義である。すなわち、フィルタ構成情報D1aには、二つのフィルタ133に関する定義が含まれている。当該定義の数は、論理プリンタAに対応するフィルタ133の数に依存する。定義51内の記述511において、filter=に続く文字列drv1log.dllは、定義51に対応するフィルタ133のパス名を示す。本実施の形態では、プリンタドライバ13のインストールフォルダからの相対パスであるとする。また、記述512において、exports=に続く括弧内に列挙されている文字列は、当該フィルタ133に実装されており、エクスポートされている関数エクスポート関数の関数名を示す。エクスポートとは、DLLの外部から呼び出し可能な状態とされていることをいう。定義52においても、同様の形式によって、もう一つのフィルタ133のパス名及び実装されている関数名等が記述されている。上記したステップS203において、指定された論理プリンタ名に係る論理プリンタが論理プリンタAであるとする。この場合、フィルタマネージャ152は、SendRecvBidiDataFromPortが実装されているフィルタ133のパス名を、フィルタ構成情報D1aの定義51及び定義52を参照して特定する。ここでは、定義51内に、SendRecvBidiDataFromPortが含まれている。したがって、drv1log.dllのパス名が特定される。続いて、フィルタマネージャ152は、ステップS203においてそのパス名が特定されたフィルタ133drv1log.dllをロードし、ロードされたフィルタ133内における、呼び出し関数SendRecvBidiDataFromPortのアドレスを取得するS204。続いて、フィルタマネージャ152は、取得されたアドレスの一覧を、フィルタリストとしてランゲージモニタインタフェース151に返却するS205。但し、ここでは、呼び出し関数が実装されているフィルタ133は一つであるため、フィルタリストに含まれるアドレスは一つである。続いて、ランゲージモニタインタフェース151は、返却されたフィルタリストに含まれているアドレスに基づいて、呼び出し関数を呼び出すS206。その結果、drv1log.dll内の関数SendRecvBidiDataFromPortが呼び出される。すなわち、関数SendRecvBidiDataFromPortの処理の実行がdrv1log.dllに委譲される。drv1log.dllは、呼び出しに応じ、関数SendRecvBidiDataFromPortに実装されている処理を実行する。続いて、ランゲージモニタインタフェース151は、フィルタマネージャ152に対してフィルタ133の解放要求を行うS207。フィルタマネージャ152は、フィルタ133の解放要求に応じ、ステップS204においてロードされたフィルタ133drv1log.dllをアンロード解放するS208。なお、DLLの動的なロード又はアンロード、及びDLL内の関数のアドレスの取得等は、例えば、Windows登録商標APIを用いて行うことができる。ステップS211以降は、スプーラ14が、ランゲージモニタインタフェース151のWritePortという関数を呼び出した場合に実行される処理手順が示されている。当該関数の引数には、図5のステップS113においてスプーラ14に対して返却されているハンドルが指定される。この場合、ランゲージモニタインタフェース151は、呼び出し関数の関数名WritePortを示す文字列を指定して、フィルタマネージャ152に対してフィルタリストの取得要求を行うS212。当該取得要求には、スプーラ14から指定された引数がそのまま指定される。また、当該取得要求には、ハンドルに対応する論理プリンタ名も引数として指定される。続いて、フィルタマネージャ152は、指定された論理プリンタ名に対応するフィルタ構成情報D1aを読み込み、呼び出し関数の実装を有するフィルタ133を判定するS213。ここで、フィルタ構成情報D1a図7参照において、WritePortが実装されているフィルタ133は、drv1log.dllとdrv1compress.dllとの二つである。そこで、フィルタマネージャ152は、drv1log.dll及びdrv1compress.dllをロードしS214a、S214b、ロードされた各フィルタ133における、呼び出し関数WritePortのアドレスを取得する。したがって、ここでは、二つのアドレスが取得される。続いて、フィルタマネージャ152は、取得されたアドレスの一覧を、フィルタリストとしてランゲージモニタインタフェース151に返却するS215。なお、フィルタリストは、フィルタ構成情報D1aにおける定義順が識別可能なように構成される。例えば、drv1log.dllにおけるWritePortのアドレスが先で、drv1compress.dll内のWritePortのアドレスが後となるように、フィルタリストに含められる。続いて、ランゲージモニタインタフェース151は、返却されたフィルタリストに含まれている順に、各アドレスに基づいて、呼び出し関数を呼び出すS216a、S216b。したがって、drv1log.dll内の関数WritePortが呼び出され、続いて、drv1compress.dll内の関数WritePortが呼び出される。このように、複数のフィルタ133に同一の関数が実装されている場合、各フィルタ133の関数は、フィルタ構成情報の定義順に呼び出される。フィルタ構成情報の定義順に呼び出されるのは、呼び出し順によって処理結果が変わる可能性があるからである。換言すれば、フィルタ構成情報には、所望の結果を得るための順番で、各フィルタ133の定義が記述される。なお、同一の関数であっても、各フィルタ133における実装内容は異なりうる。例えば、drv1log.dll内の関数WritePortには、WritePortが呼び出されたことのログ情報の記録処理が実装されており、drv1compress.dll内の関数WritePortには、印刷データの圧縮処理が実装されているといった具合である。斯かる点において、同一の関数に関して各フィルタ133の実装を呼び出す意義が認められる。続いて、ランゲージモニタインタフェース151は、フィルタマネージャ152に対してフィルタ133の解放要求を行うS217。フィルタマネージャ152は、フィルタ133の解放要求に応じ、ステップS214a又はS214bおいてロードされたフィルタ133drv1log.dll、drv1compress.dllをアンロード解放するS218a、S218b。続いて、ステップS202又はステップS212等のフィルタリストの取得要求に応じて、フィルタマネージャ152が実行する処理の詳細について説明する。図8は、第一の実施の形態においてフィルタリストの取得要求に応じてフィルタマネージャが実行する処理手順の一例を説明するためのフローチャートである。ステップS251において、フィルタマネージャ152は、フィルタリストの取得要求に指定された論理プリンタ名に関連付けられているフィルタ構成情報を読み込む。例えば、フィルタ構成情報記憶部16としてレジストリが用いられている場合、フィルタマネージャ152は、当該論理プリンタ名を指定して、OpenPrinterを呼び出して、当該論理プリンタのハンドルを取得する。続いて、当該ハンドルと、レジストリ内におけるフィルタ構成情報に対応するキーの名前とを指定してGetPrinterDataを呼び出すことで、当該論理プリンタのフィルタ構成情報を取得することができる。続いて、フィルタマネージャ152は、読み込まれたフィルタ構成情報をパース解読して、フィルタ133ごとに、パス名とエクスポート関数名の一覧を取得するS252。続いて、ステップS252において取得された情報より、フィルタマネージャ152は、呼び出し関数の関数名フィルタリストの取得要求に指定された関数名をエクスポート関数名として含むフィルタ133のパス名を抽出リストアップするS253。続いて、フィルタマネージャ152は、抽出されたパス名に係るフィルタ133をロードし、ロードされたフィルタ133における、呼び出し関数のアドレスを取得するS254。続いて、フィルタマネージャ152は、アドレスの一覧をフィルタリストとしてランゲージモニタインタフェース151に返却するS255。この際、アドレスの順序は、フィルタ構成情報の定義順に従う。上述したように、第一の実施の形態によれば、スプーラ14よりロードされるランゲーモニタ15は関数インタフェースに応じた処理は実行せず、ランゲージモニタ15からロード及びアンロードされるフィルタ133によって当該処理の実行が代行される。したがって、フィルタ133を置き換えることにより、ランゲージモニタ15の機能を変更することができる。そして、フィルタ133は、ランゲージモニタ15が、スプーラ14より関数呼び出しを受けるたびに動的にロード及びアンロードされる。したがって、フィルタ133が置き換えられたとしても、スプーラ14を再起動せずに、置き換えられたフィルタ133を有効とすることができる。また、処理の委譲先となるフィルタ133は、フィルタ構成情報に基づいて特定される。したがって、フィルタ構成情報を編集することにより、処理の委譲先とするフィルタ133を容易に変更することができる。更に、第一の実施の形態では、同一の関数に対して複数のフィルタ133を対応付けることができる。すなわち、同一の関数に応じた処理を複数のフィルタ133に実行させることができる。したがって、フィルタ133を効果的に部品化することにより、フィルタ133の組み合わせによって多様な機能を効率的に実現することができる。次に、第二の実施の形態について説明する。第二の実施の形態では、第一の実施の形態と異なる点について説明する。したがって、特に言及しない点については、第一の実施の形態と同様でよい。図9は、第二の実施の形態においてフィルタリストの取得要求に応じてフィルタマネージャが実行する処理手順の一例を説明するためのフローチャートである。図9中、図8と同一ステップには、同一ステップ番号を付し、その説明は省略する。図9では、ステップS251がステップS251aに置き換わっている。第二の実施の形態では、読み込まれるフィルタ構成情報の形式の一部が第一の実施の形態と異なるからである。図10は、第二の実施の形態のフィルタ構成情報の一例を示す図である。図10中、図7のフィルタ構成情報D1aと同一部分に同一符号を付し、その説明は省略する。図10のフィルタ構成情報D2aには、フィルタ133ごとに、active=で始まる記述が追加されている。すなわち、定義51には、記述513が追加されている。定義52には、記述521が追加されている。active=で始まる記述は、それに続く値が、trueであれば、当該フィルタ133が有効であることを示し、falseであれば、当該フィルタ133が無効であることを示す。すなわち、当該記述は、フィルタ133の有効性を示す情報の一例である。フィルタ構成情報D2aでは、drv1log.dllは有効であり、drv1compress.dllは無効であることが定義されている。なお、フィルタ133が有効であるとは、当該フィルタ133が利用対象とされていることを意味する。フィルタ133が無効であるとは、当該フィルタ133が利用対象とされていないことを意味する。そこで、図9のステップS253aにおいて、フィルタマネージャ152は、有効なフィルタ133であって、かつ、呼び出し関数の関数名フィルタリストの取得要求に関数名が指定された関数をエクスポート関数名として含むフィルタ133のパス名を抽出する。ステップS254以降は、第一の実施の形態で説明した通りである。フィルタマネージャ152の振る舞いが図9に示されるように変わることにより、第一の実施の形態における図6の処理手順は、第二の実施の形態において図11に示されるように変化する。図11は、第二の実施の形態においてスプーラからの関数呼び出しに応じてランゲージモニタ等が実行する処理手順の一例を説明するためのシーケンス図である。図11中、図6と同一ステップには、同一ステップ番号を付し、その説明は省略する。図11において、スプーラ14より呼び出された関数がSendRecvBidiDataFromPortである場合の処理手順S201~S208は、第一の実施の形態と同様である。SendRecvBidiDataFromPortは、drv1log.dllにしか実装されておらず、第二の実施の形態において、drv1log.dllは、有効なフィルタ133だからである。一方、スプーラ14より呼び出された関数がWritePortである場合、ステップS214b、ステップS216b、及びステップS218bは、実行されない。すなわち、ステップS214b、ステップS216b、及びステップS218bは、drv1compress.dllに関するステップである。また、drv1compress.dllは、第二の実施の形態において無効なフィルタ133である。したがって、drv1compress.dllのWritePortのアドレスは、フィルタリストに含まれないからである。なお、各フィルタ133の有効性は、UIドライバ131が表示させる画面を介して設定可能としてもよい。図12は、フィルタの有効性を設定させる画面の一例を示す図である。同図に示される画面610は、UIドライバ131が表示させる、論理プリンタAのプロパティ画面の一つのタブが選択された状態を示す。画面610には、チェックボタン611及び612が配置されている。チェックボタン611は、drv1log.dllの有効性を設定させるためのチェックボタンである。チェックボタン612は、drv1compress.dllの有効性を設定させるためのチェックボタンである。チェックボタン611又は612のチェック状態が更新され、OKボタン613が押下されると、UIドライバ131は、論理プリンタAのフィルタ構成情報D2aに対して、チェックボタン611及び612の状態に応じた値true又はfalseを書き込む。すなわち、チェックボタン611の状態に応じた値は、記述513図10参照に書き込まれる。チェックボタン612の状態に応じた値は、記述521に書き込まれる。なお、チェックボタン611には、ランゲージモニタのログを収集するという文字列が付加され、チェックボタン612には、印刷データを圧縮するという文字列が付加されている。これは、ユーザの利便性を考慮したものである。すなわち、仮に、チェックボタン611に対してdrv1log.dllという文字列が付加され、チェックボタン612に対してdrv1compress.dllという文字列が付加された場合、ユーザによっては、各チェックボタンをチェックすることによりどのような機能が有効となるのかを容易に知ることができない。そこで、図12では、各フィルタ133の機能の内容を示す文字列が、各チェックボタンに付加されているのである。上述したように、第二の実施の形態によれば、フィルタ構成情報を編集することにより、各フィルタ133の有効性を簡便に変更することができる。その結果、ランゲージモニタ15によって実行される処理内容を容易にカスタマイズすることができる。なお、上記各実施の形態において、ランゲージモニタ15は、要求受付手段の一例である。また、フィルタ133は、処理実行手段の一例である。また、フィルタ構成情報記憶部16は、記憶手段の一例である。以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形変更が可能である。