JP2014032652A - 印刷処理システム - Google Patents

Abstract

【課題】クライアントＰＣとプリンタの間の直接の通信が制限されている場合でも、サーバＰＣとプリンタの接続形式によらずに機器情報を取得する。
【解決手段】情報処理装置および画像処理装置と双方向通信を行う双方向通信手段と、前記情報処理装置から前記双方向通信手段が受信したリクエストに基づき、前記画像処理装置の印刷プロトコルに応じて前記画像処理装置に送信するリクエストコマンドを生成するコマンド生成手段と、前記画像処理装置から前記双方向通信手段が受信した前記リクエストコマンドに対応するレスポンスを、前記情報処理装置に送信する、印刷プロトコルに依存しない形式のレスポンスに変換するレスポンス変換手段とを備える。
【選択図】図５

Description

本発明は印刷処理の技術に関する。

クライアントＰＣ（Personal Computer）からサーバＰＣの共有プリンタを指定することで、サーバＰＣからクライアントＰＣにプリンタドライバがコピーされてインストールされ、クライアントＰＣで個別にプリンタドライバをインストールする必要のない、Ｐｏｉｎｔ＆Ｐｒｉｎｔと呼ばれる技術が知られている。

また、一般に、プリンタドライバとプリンタ間で双方向通信を行うことにより、プリンタドライバがプリンタの機器情報を取得する技術が知られている。

図１はＰｏｉｎｔ＆Ｐｒｉｎｔ時の双方向通信の例を示す図である。

図１において、クライアントＰＣ１はネットワーク＃１に配置され、サーバＰＣ２はネットワーク＃２に配置され、プリンタ３はネットワーク＃３に配置されている。また、管理上の要請から、ネットワーク＃１のクライアントＰＣ１とネットワーク＃３のプリンタ３が直接通信できない（直接の通信が制限されている）場合を示している。

このような環境では、ネットワーク＃１のクライアントＰＣ１からはネットワーク＃２のサーバＰＣ２しか見えず、ネットワーク＃３のプリンタ３の存在を知ることができない。

そのため、クライアントＰＣ１から直接にプリンタ３とＳＮＭＰ（Simple Network Management Protocol）等のプロトコルで双方向通信して機器情報を取得することができない。

また、クライアントＰＣ１からサーバＰＣ２を経由してプリンタ３と双方向通信を行う技術がすでに知られているが（特許文献１等を参照）、サーバＰＣ２とプリンタ３との接続形態（ＴＣＰ／ＩＰポート、ＵＳＢポート、ＷＳＤポート等）に依存せずに双方向通信を行うことはできない。すなわち、今までの双方向通信では、Ｐｏｉｎｔ＆Ｐｒｉｎｔ環境においてクライアントＰＣ１とプリンタ３の間の直接の通信が制限されている場合には、接続形態に依存せずにクライアントＰＣ１から直接にプリンタ３の機器情報が取得できないという問題があった。

図２はＰｏｉｎｔ＆Ｐｒｉｎｔ時の双方向通信の他の例を示す図であり、ネットワーク＃１のクライアントＰＣ１とネットワーク＃３のプリンタ３が直接通信できる場合を示している。

この場合、サーバＰＣ２を経由してクライアントＰＣ１とプリンタ３の間で双方向通信を行うと、サーバＰＣ２にネットワーク負荷がかかるため、クライアントＰＣ１とプリンタ３との間で直接に双方向通信ができることが望まれる。

しかし、管理上の要請から、クライアントＰＣ１での設定がサーバＰＣ２を経由するものとなっていることが多く、クライアントＰＣ１のユーザは権限がないと設定を変更することができず、クライアントＰＣ１とプリンタ３の間で直接に双方向通信することは困難であった。

本発明は上記の従来の問題点に鑑み提案されたものであり、その目的とするところは、クライアントＰＣとプリンタの間の直接の通信が制限されている場合でも、サーバＰＣとプリンタの接続形式によらずに機器情報を取得できるようにすることにある。また、他の目的として、クライアントＰＣとプリンタの間の直接の通信が行える場合には、直接に通信を行えるようにする。

上記の課題を解決するため、本発明にあっては、情報処理装置および画像処理装置と双方向通信を行う双方向通信手段と、前記情報処理装置から前記双方向通信手段が受信したリクエストに基づき、前記画像処理装置の印刷プロトコルに応じて前記画像処理装置に送信するリクエストコマンドを生成するコマンド生成手段と、前記画像処理装置から前記双方向通信手段が受信した前記リクエストコマンドに対応するレスポンスを、前記情報処理装置に送信する、印刷プロトコルに依存しない形式のレスポンスに変換するレスポンス変換手段とを備える。

本発明の印刷処理システムにあっては、クライアントＰＣとプリンタの間の直接の通信が制限されている場合でも、サーバＰＣとプリンタの接続形式によらずに機器情報を取得することができる。

Ｐｏｉｎｔ＆Ｐｒｉｎｔ時の双方向通信の例を示す図（クライアントＰＣとプリンタが直接通信できない場合）である。 Ｐｏｉｎｔ＆Ｐｒｉｎｔ時の双方向通信の例を示す図（クライアントＰＣとプリンタが直接通信できる場合）である。 第１の実施形態におけるシステムの構成例を示す図である。 Ｐｏｉｎｔ＆Ｐｒｉｎｔ時の印刷アーキテクチャの例を示す図である。 第１の実施形態における双方向通信のための機能構成例を示す図である。 第１の実施形態の処理例を示すフローチャートである。 ランゲージモニタに双方向リクエストを送るために使用する関数の例を示す図である。 双方向リクエストとリクエストコマンドの対応付けの例を示す図である。 双方向リクエストを送ってから機器情報が得られるまでの流れの例を示す図（その１）である。 双方向リクエストを送ってから機器情報が得られるまでの流れの例を示す図（その２）である。 第２の実施形態における双方向通信のための機能構成例を示す図である。 第２の実施形態の処理例を示すフローチャートである。 双方向通信の切り替え設定のユーザインタフェースの例を示す図である。 第３の実施形態における双方向通信のための機能構成例を示す図である。 双方向通信に用いる通信方法の指定のユーザインタフェースの例を示す図である。 第３の実施形態の処理例を示すフローチャートである。

以下、本発明の好適な実施形態につき説明する。

＜第１の実施形態＞
図３は第１の実施形態におけるシステムの構成例を示す図である。

図３において、ネットワーク＃１に配置されたクライアントＰＣ（情報処理装置）１はネットワーク＃２に配置されたサーバＰＣ（情報処理装置）２と接続され、サーバＰＣ２はネットワーク＃３に配置されたプリンタ（画像処理装置）３と接続されている。

図４はＰｏｉｎｔ＆Ｐｒｉｎｔ時の印刷アーキテクチャの例を示す図である。

クライアントＰＣ１上のアプリケーションプロセス１１で、アプリケーション１２から印刷が実行されると、これをグラフィックデバイスインタフェース１３を介してプリンタドライバ１４が受け、プリンタドライバ１４はスプーラ１５を介して印刷データをスプールファイル１６に滞留させつつ、クライアントＰＣ１のスプーラサービス１７（プリントプロバイダ１８）に送る。

クライアントＰＣ１のスプーラサービス１７は、受け取った印刷データをサーバＰＣ２のスプーラサービス２１に送る。

サーバＰＣ２のスプーラサービス２１では、受け取った印刷データをプリントプロバイダ２２、プリントプロセッサ２３、スプーラ２４、プリントプロバイダ２５、ランゲージモニタ２６、ポートモニタ２７を経由し、更にカーネルモードドライバ２８を介してプリンタ３に送る。

上記のランゲージモニタ２６は本来はＷｉｎｄｏｗｓ（登録商標）ＯＳが提供するものであるが、ベンダーがカスタマイズしたランゲージモニタ２６を入れ替えて使用することができる。これにより、ベンダー独自の機能をランゲージモニタ２６に持たせることが可能となる。

図５は第１の実施形態における双方向通信のための機能構成例を示す図である。

図５において、サーバＰＣ２には、ランゲージモニタ２６内に双方向通信部２６１とコマンド生成部２６２とレスポンス変換部２６３とが設けられている。

図６は第１の実施形態の処理例を示すフローチャートである。

図６において、クライアントＰＣ１は、プリンタ３の機器情報を取得する必要が生じた場合、サーバＰＣ２のランゲージモニタ２６に双方向リクエストを送る（ステップＳ１０１）。

サーバＰＣ２のランゲージモニタ２６は、双方向リクエストを受け取ると、これを双方向通信部２６１に渡す（ステップＳ１０２）。

双方向通信部２６１は、コマンド生成部２６２に双方向リクエストを渡し、リクエストコマンドの取得要求を行う（ステップＳ１０３）。

コマンド生成部２６２は、サーバＰＣ２とプリンタ３の接続形式を基にリクエストコマンドを生成し、双方向通信部２６１に渡す（ステップＳ１０４）。プリンタ３に送るリクエストコマンドおよび通信方法は、サーバＰＣ２とプリンタ３の接続形式により変わる。例えば、ＴＣＰ／ＩＰポートで接続していればＳＮＭＰプロトコルを利用し、ＵＳＢポートで接続していればＰＪＬを利用する。コマンド生成部２６２は、ポートの種類から適切なリクエストコマンドを生成する。

双方向通信部２６１は、コマンド生成部２６２からリクエストコマンドを受け取り、プリンタ３にリクエストコマンドを送り、双方向通信を開始する（ステップＳ１０５）。

双方向通信部２６１は、プリンタ３からレスポンスを受け取り、レスポンス変換部２６３に渡す（ステップＳ１０６）。

レスポンス変換部２６３は、レスポンスをプロトコルに依存しない機器情報に変換する（ステップＳ１０７）。リクエストコマンドがサーバＰＣ２とプリンタ３の通信プロトコルにより変わるのと同様に、プリンタ３からのレスポンスもプロトコルに依存する。レスポンス変換部２６３は、それをプロトコルに依存しない機器情報に変換する。

双方向通信部２６１は、レスポンス変換部２６３から機器情報を受け取り、クライアントＰＣ１に渡す（ステップＳ１０８）。

図７はランゲージモニタ２６に双方向リクエストを送るために使用する関数の例を示す図である。

ランゲージモニタ２６にはＯＳによって決められたインタフェースが存在する。詳細な説明はＭＳＤＮドキュメント（http://msdn.microsoft.com/en-us/library/ms123401）に記述されている。

ここでは、SendRecvBidiDataFromPort()というインタフェースを利用することにより、ランゲージモニタ２６を呼び出したモジュールはランゲージモニタ２６とのデータのやりとりが可能となる。本実施形態では上記の関数を使用することにより、クライアントＰＣ１からサーバＰＣ２のランゲージモニタ２６とデータのやり取りを行う。

図８は双方向リクエストとリクエストコマンドの対応付けの例を示す図である。

双方向リクエストとして、例えば、プリンタのオプション情報を取得する「ＯＰＴＩＯＮ」と、プリンタのメモリサイズを取得する「ＭＥＭＯＲＹＳＩＺＥ」がある。すなわち、プリンタ３のオプション情報を取得する際には、クライアントＰＣ１からサーバＰＣ２に「ＯＰＴＩＯＮ」リクエストを送り、プリンタ３のメモリサイズを取得する際には、クライアントＰＣ１からサーバＰＣ２に「ＭＥＭＯＲＹＳＩＺＥ」リクエストを送る。

図８（ａ）は、サーバＰＣ２とプリンタ３がＵＳＢポートで接続されており、ＰＪＬで通信する場合の双方向リクエストとリクエストコマンドの対応関係を示している。すなわち、コマンド生成部２６２は、「ＯＰＴＩＯＮ」という双方向リクエストを渡されると、「＠ＰＪＬ ＩＮＦＯ ＣＯＮＦＩＧ」というリクエストコマンドを生成する。また、コマンド生成部２６２は、「ＭＥＭＯＲＹＳＩＺＥ」という双方向リクエストを渡されると、「＠ＰＪＬ ＩＮＦＯ ＭＥＭＯＲＹ」というリクエストコマンドを生成する。

図８（ｂ）は、サーバＰＣ２とプリンタ３がＴＣＰ／ＩＰポートで接続されており、ＳＮＭＰで通信する場合の双方向リクエストとリクエストコマンドの対応関係を示している。すなわち、コマンド生成部２６２は、「ＯＰＴＩＯＮ」という双方向リクエストを渡されると、「１．３．６．１．２．１．４３．１３２５．１」というリクエストコマンドを生成する。また、コマンド生成部２６２は、「ＭＥＭＯＲＹＳＩＺＥ」という双方向リクエストを渡されると、「１．３．６．１．２．１．４３．１３６５４６．０」というリクエストコマンドを生成する。

図９および図１０は双方向リクエストを送ってから機器情報が得られるまでの流れの例を示す図である。

図９は双方向リクエストが「ＯＰＴＩＯＮ」の場合を示しており、（ａ）はＰＪＬで通信する場合、（ｂ）はＳＮＭＰで通信する場合を示している。

図９（ａ）において、双方向リクエスト「ＯＰＴＩＯＮ」がクライアントＰＣ１からサーバＰＣ２に送られると、サーバＰＣ２ではＰＪＬで通信する場合、リクエストコマンド「＠ＰＪＬ ＩＮＦＯ ＣＯＮＦＩＧ」を生成し、プリンタ３に送る。プリンタ３からはレスポンス「＠ＰＪＬ ＩＮＦＯ ＣＯＮＦＩＧ ＤＵＰＬＥＸ ［１ ＥＮＵＭＥＲＡＴＥＤ］ ＤＵＰＬＥＸ」がサーバＰＣ２に送られ、サーバＰＣ２はプロトコルに依存しない機器情報「ＤＵＰＬＥＸ＝ＯＮ」に変換してクライアントＰＣ１に送る。サーバＰＣ２のレスポンス変換部２６３は、例えば、ＰＪＬのレスポンスに「ＤＵＰＬＥＸ」が含まれていれば、機器情報として「ＤＵＰＬＥＸ＝ＯＮ」という情報に変換する。

図９（ｂ）において、双方向リクエスト「ＯＰＴＩＯＮ」がクライアントＰＣ１からサーバＰＣ２に送られると、サーバＰＣ２ではＳＮＭＰで通信する場合、リクエストコマンド「１．３．６．１．２．１．４３．１３２５．１」を生成し、プリンタ３に送る。プリンタ３からはレスポンス「ｄｕｐｌｅｘ」がサーバＰＣ２に送られ、サーバＰＣ２はプロトコルに依存しない機器情報「ＤＵＰＬＥＸ＝ＯＮ」に変換してクライアントＰＣ１に送る。サーバＰＣ２のレスポンス変換部２６３は、例えば、ＳＮＭＰのレスポンスに「ｄｕｐｌｅｘ」が含まれていれば、機器情報として「ＤＵＰＬＥＸ＝ＯＮ」という情報に変換する。

図１０（ａ）において、双方向リクエスト「ＭＥＭＯＲＹＳＩＺＥ」がクライアントＰＣ１からサーバＰＣ２に送られると、サーバＰＣ２ではＰＪＬで通信する場合、リクエストコマンド「＠ＰＪＬ ＩＮＦＯ ＭＥＭＯＲＹ」を生成し、プリンタ３に送る。プリンタ３からはレスポンス「＠ＰＪＬ ＩＮＦＯ ＭＥＭＯＲＹ ＭＥＭＯＲＹ＝１０２４」がサーバＰＣ２に送られ、サーバＰＣ２はプロトコルに依存しない機器情報「ＭＥＭＯＲＹＳＩＺＥ＝１０２４」に変換してクライアントＰＣ１に送る。

図１０（ｂ）において、双方向リクエスト「ＭＥＭＯＲＹＳＩＺＥ」がクライアントＰＣ１からサーバＰＣ２に送られると、サーバＰＣ２ではＳＮＭＰで通信する場合、リクエストコマンド「１．３．６．１．２．１．４３．１３６５４６．０」を生成し、プリンタ３に送る。プリンタ３からはレスポンス「１０２４」がサーバＰＣ２に送られ、サーバＰＣ２はプロトコルに依存しない機器情報「ＭＥＭＯＲＹＳＩＺＥ＝１０２４」に変換してクライアントＰＣ１に送る。

クライアントＰＣ１からサーバＰＣ２とプリンタ３の接続形式に依存しない双方向リクエストを送り、プリンタ３からのレスポンスをプロトコルに依存しない機器情報に変換してクライアントＰＣ１に渡すことで、クライアントＰＣ１はサーバＰＣ２とプリンタ３の接続形式を意識することなく機器情報を取得することができる。

＜第２の実施形態＞
図１１は第２の実施形態における双方向通信のための機能構成例を示す図である。

クライアントＰＣ１とプリンタ３の間で直接通信ができる環境においては、サーバＰＣ２を経由して双方向通信を行うとサーバＰＣ２にネットワーク負荷がかかるため、クライアントＰＣ１とプリンタ３の間で直接双方向通信ができることが望まれる。この実施形態では、サーバＰＣ２経由で双方向通信を行うか、クライアントＰＣ１から直接にプリンタ３と双方向通信を行うかを切り替えることができるようにしている。

図１１においては、図５に示した構成に加え、クライアントＰＣ１内のランゲージモニタ１９に切り替え部１９１と双方向通信部１９２とコマンド生成部１９３とレスポンス変換部１９４とが設けられる。なお、クライアントＰＣ１のランゲージモニタ１９は、Ｐｏｉｎｔ＆Ｐｒｉｎｔ環境により、サーバＰＣ２のランゲージモニタ２６と連携して設けられるものである。

図１２は第２の実施形態の処理例を示すフローチャートである。

図１２において、クライアントＰＣ１内でプリンタ３の機器情報を取得する必要が生ずると、クライアントＰＣ１のランゲージモニタ１９の切り替え部１９１は、サーバＰＣ２を経由してプリンタ３と双方向通信を行うか、直接にプリンタ３と双方向通信を行うかを切り替え設定に基づいて判断する（ステップＳ２０１）。

なお、切り替え設定は、図１３に示すようなユーザインタフェースにより、事前にユーザにより設定される。すなわち、「サーバ経由で双方向通信を行う」にチェックを入れると、サーバ経由で双方向通信を行う設定が保存される。チェックを外すと直接にプリンタと双方向通信を行う設定が保存される。切り替え設定は所定のレジストリに保存することができる。

図１２に戻り、サーバＰＣ２を経由する場合（ステップＳ２０２のＹｅｓ）、図６に示したフローチャートと同様になる（ステップＳ２０３）。なお、サーバＰＣ２を経由せずにクライアントＰＣ１とプリンタ３の間で双方向通信を行った結果、それが失敗した場合も、サーバＰＣ２を経由するものとする。

サーバＰＣ２を経由しない場合（ステップＳ２０２のＮｏ）、クライアントＰＣ１の切り替え部１９１は、双方向通信部１９２に双方向リクエストを送る（ステップＳ２０４）。

双方向通信部１９２は、コマンド生成部１９３に双方向リクエストを渡し、リクエストコマンドの取得要求を行う（ステップＳ２０５）。

コマンド生成部１９３は、プリンタ３との接続方式に応じたリクエストコマンドを生成し、双方向通信部１９２に渡す（ステップＳ２０６）。

双方向通信部１９２は、コマンド生成部１９３からリクエストコマンドを受け取り、プリンタ３にリクエストコマンドを送る（ステップＳ２０７）。

双方向通信部１９２は、プリンタ３からレスポンスを受け取り、レスポンス変換部１９４に渡す（ステップＳ２０８）。

レスポンス変換部１９４は、レスポンスをプロトコルに依存しない機器情報に変換し、双方向通信部１９２に渡す（ステップＳ２０９）。

双方向通信部１９２は、レスポンス変換部１９４から機器情報を受けとり、切り替え部１９１に渡し、要求元に渡す（ステップＳ２１０）。

＜第３の実施形態＞
図１４は第３の実施形態における双方向通信のための機能構成例を示す図である。

プリンタとの双方向通信にはいくつかの通信方法（プロトコル）があるが、その通信方法は、通常は印刷ポートごとに決まっている。例えば、ＴＣＰ／ＩＰポートならＳＮＭＰで通信を行い、ＵＳＢポートならＰＪＬで通信を行うなどである。

しかし、ユーザによっては、セキュリティの懸念などから、特定のプロトコルを遮断しておきたい場合がある。例えば、ＳＮＭＰは禁止といったような要望である。

そこで、この第３の実施形態では、機器情報を取得する際の通信方法をユーザが指定できるようにすることで、ユーザの要望に沿えるようにしている。

図１４においては、図５に示した構成に加え、サーバＰＣ２のランゲージモニタ２６に、ユーザの指定した通信方法を保持する通信方法保持部２６４が設けられ、双方向通信部２６１は双方向通信を行うに先立って通信方法保持部２６４から通信方法を取得するようになっている。

図１５は双方向通信に用いる通信方法の指定のユーザインタフェースの例を示す図であり、事前にユーザにより双方向通信に用いる通信方法にチェックが入れられることで通信方法の指定が行われる。通信方法は複数選択することができ、通信方法に優先度を設定することができる。図の例ではＳＮＭＰとＰＪＬが選択されており、上にあるＳＮＭＰの優先度がＰＪＬよりも高くなっている。この場合、優先度の高いＳＮＭＰにより双方向通信を行ない、通信が失敗した場合は次の優先度のＰＪＬにより通信を行う。

図１６は第３の実施形態の処理例を示すフローチャートである。

図１６において、クライアントＰＣ１は、プリンタ３の機器情報を取得する必要が生じた場合、サーバＰＣ２のランゲージモニタ２６に双方向リクエストを送る（ステップＳ３０１）。

サーバＰＣ２のランゲージモニタ２６は、双方向リクエストを受け取ると、これを双方向通信部２６１に渡す（ステップＳ３０２）。

双方向通信部２６１は、通信方法保持部２６４から通信方法を取得する（ステップＳ３０３）。

双方向通信部２６１は、コマンド生成部２６２に双方向リクエストを渡し、リクエストコマンドの取得要求を行う（ステップＳ３０４）。この際、双方向通信部２６１は、通信方法保持部２６４から取得した通信方法を併せて渡す。

コマンド生成部２６２は、双方向通信部２６１から受け取った通信方法を基にリクエストコマンドを生成し、双方向通信部２６１に渡す（ステップＳ３０５）。

双方向通信部２６１は、コマンド生成部２６２からリクエストコマンドを受け取り、プリンタ３にリクエストコマンドを送り、双方向通信を開始する（ステップＳ３０６）。

双方向通信部２６１は、プリンタ３からレスポンスを受け取り、レスポンス変換部２６３に渡す（ステップＳ３０７）。

レスポンス変換部２６３は、レスポンスをプロトコルに依存しない機器情報に変換する（ステップＳ３０８）。リクエストコマンドは通信方法保持部２６４から取得した通信方法により変わるのと同様に、プリンタ３からのレスポンスもプロトコルに依存する。レスポンス変換部２６３は、それをプロトコルに依存しない機器情報に変換する。

双方向通信部２６１は、レスポンス変換部２６３から機器情報を受け取り、クライアントＰＣ１に渡す（ステップＳ３０９）。

＜総括＞
以上説明したように、本実施形態によれば、次のような利点がある。
（１）クライアントＰＣとプリンタの間の直接の通信が制限されている場合でも、サーバＰＣとプリンタの接続形式によらずに機器情報を取得することができる。
（２）ユーザにより通信方法が指定されている場合には、指定された通信方法によりサーバＰＣとプリンタの双方向通信が行われるようにすることができ、セキュリティを考慮した運用を行うことができる。
（３）クライアントＰＣとプリンタの間の直接の通信が行える場合には、直接に通信を行うことができる。

以上、本発明の好適な実施の形態により本発明を説明した。ここでは特定の具体例を示して本発明を説明したが、特許請求の範囲に定義された本発明の広範な趣旨および範囲から逸脱することなく、これら具体例に様々な修正および変更を加えることができることは明らかである。すなわち、具体例の詳細および添付の図面により本発明が限定されるものと解釈してはならない。

１ クライアントＰＣ
１１ アプリケーションプロセス
１２ アプリケーション
１３ グラフィックデバイスインタフェース
１４ プリンタドライバ
１５ スプーラ
１６ スプールファイル
１７ スプーラサービス
１８ プリントプロバイダ
１９ ランゲージモニタ
１９１ 切り替え部
１９２ 双方向通信部
１９３ コマンド生成部
１９４ レスポンス変換部
２ サーバＰＣ
２１ スプーラサービス
２２ プリントプロバイダ
２３ プリントプロセッサ
２４ スプーラ
２５ プリントプロバイダ
２６ ランゲージモニタ
２６１ 双方向通信部
２６２ コマンド生成部
２６３ レスポンス変換部
２６４ 通信方法保持部
２７ ポートモニタ
２８ カーネルモードドライバ
３ プリンタ

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

Claims (7)

1. 情報処理装置および画像処理装置と双方向通信を行う双方向通信手段と、
   前記情報処理装置から前記双方向通信手段が受信したリクエストに基づき、前記画像処理装置の印刷プロトコルに応じて前記画像処理装置に送信するリクエストコマンドを生成するコマンド生成手段と、
   前記画像処理装置から前記双方向通信手段が受信した前記リクエストコマンドに対応するレスポンスを、前記情報処理装置に送信する、印刷プロトコルに依存しない形式のレスポンスに変換するレスポンス変換手段と
   を備えたことを特徴とする印刷処理システム。
2. 請求項１に記載の印刷処理システムにおいて、
   前記画像処理装置の印刷プロトコルに対応する通信方法をユーザに指定させるユーザインタフェース
   を備えたことを特徴とする印刷処理システム。
3. 請求項２に記載の印刷処理システムにおいて、
   前記ユーザインタフェースは、複数の通信方法が指定可能であるとともに、通信方法に優先度が設定可能であり、
   優先度の高い通信方法から双方向通信を行ない、双方向通信が失敗した場合は次の優先度の通信方法に基づいて双方向通信を行う
   ことを特徴とする印刷処理システム。
4. 請求項１乃至３のいずれか一項に記載の印刷処理システムにおいて、
   前記画像処理装置と双方向通信を行う第２の双方向通信手段と、
   前記第２の双方向通信手段が受信したリクエストに基づき、前記画像処理装置の印刷プロトコルに応じて前記画像処理装置に送信するリクエストコマンドを生成する第２のコマンド生成手段と、
   前記画像処理装置から前記第２の双方向通信手段が受信した前記リクエストコマンドに対応するレスポンスを、前記情報処理装置に送信する、印刷プロトコルに依存しない形式のレスポンスに変換する第２のレスポンス変換手段と、
   切り替え設定に従い、前記双方向通信手段と前記第２の双方向通信手段のいずれかに要求元との接続経路を切り替える切り替え手段と
   を更に備えたことを特徴とする印刷処理システム。
5. 請求項４に記載の印刷処理システムにおいて、
   前記切り替え設定をユーザに設定させるユーザインタフェース
   を備えたことを特徴とする印刷処理システム。
6. 他の情報処理装置および画像処理装置と双方向通信を行う双方向通信手段と、
   前記他の情報処理装置から前記双方向通信手段が受信したリクエストに基づき、前記画像処理装置の印刷プロトコルに応じて前記画像処理装置に送信するリクエストコマンドを生成するコマンド生成手段と、
   前記画像処理装置から前記双方向通信手段が受信した前記リクエストコマンドに対応するレスポンスを、前記他の情報処理装置に送信する、印刷プロトコルに依存しない形式のレスポンスに変換するレスポンス変換手段と
   を備えたことを特徴とする情報処理装置。
7. コンピュータを、
   他の情報処理装置および画像処理装置と双方向通信を行う双方向通信手段、
   前記他の情報処理装置から前記双方向通信手段が受信したリクエストに基づき、前記画像処理装置の印刷プロトコルに応じて前記画像処理装置に送信するリクエストコマンドを生成するコマンド生成手段、
   前記画像処理装置から前記双方向通信手段が受信した前記リクエストコマンドに対応するレスポンスを、前記他の情報処理装置に送信する、印刷プロトコルに依存しない形式のレスポンスに変換するレスポンス変換手段
   として機能させるドライバプログラム。

Images