(57)【要約】【課題】クライアントＰＣとプリンタの間の直接の通信が制限されている場合でも、サーバＰＣとプリンタの接続形式によらずに機器情報を取得する。【解決手段】情報処理装置および画像処理装置と双方向通信を行う双方向通信手段と、前記情報処理装置から前記双方向通信手段が受信したリクエストに基づき、前記画像処理装置の印刷プロトコルに応じて前記画像処理装置に送信するリクエストコマンドを生成するコマンド生成手段と、前記画像処理装置から前記双方向通信手段が受信した前記リクエストコマンドに対応するレスポンスを、前記情報処理装置に送信する、印刷プロトコルに依存しない形式のレスポンスに変換するレスポンス変換手段とを備える。【選択図】図５
2014032652.tif 000002
【特許請求の範囲】
【請求項１】
情報処理装置および画像処理装置と双方向通信を行う双方向通信手段と、
前記情報処理装置から前記双方向通信手段が受信したリクエストに基づき、前記画像処理装置の印刷プロトコルに応じて前記画像処理装置に送信するリクエストコマンドを生成するコマンド生成手段と、
前記画像処理装置から前記双方向通信手段が受信した前記リクエストコマンドに対応するレスポンスを、前記情報処理装置に送信する、印刷プロトコルに依存しない形式のレスポンスに変換するレスポンス変換手段と
を備えたことを特徴とする印刷処理システム。
【請求項２】
請求項１に記載の印刷処理システムにおいて、
前記画像処理装置の印刷プロトコルに対応する通信方法をユーザに指定させるユーザインタフェース
を備えたことを特徴とする印刷処理システム。
【請求項３】
請求項２に記載の印刷処理システムにおいて、
前記ユーザインタフェースは、複数の通信方法が指定可能であるとともに、通信方法に優先度が設定可能であり、
優先度の高い通信方法から双方向通信を行ない、双方向通信が失敗した場合は次の優先度の通信方法に基づいて双方向通信を行う
ことを特徴とする印刷処理システム。
【請求項４】
請求項１乃至３のいずれか一項に記載の印刷処理システムにおいて、
前記画像処理装置と双方向通信を行う第２の双方向通信手段と、
前記第２の双方向通信手段が受信したリクエストに基づき、前記画像処理装置の印刷プロトコルに応じて前記画像処理装置に送信するリクエストコマンドを生成する第２のコマンド生成手段と、
前記画像処理装置から前記第２の双方向通信手段が受信した前記リクエストコマンドに対応するレスポンスを、前記情報処理装置に送信する、印刷プロトコルに依存しない形式のレスポンスに変換する第２のレスポンス変換手段と、
切り替え設定に従い、前記双方向通信手段と前記第２の双方向通信手段のいずれかに要求元との接続経路を切り替える切り替え手段と
を更に備えたことを特徴とする印刷処理システム。
【請求項５】
請求項４に記載の印刷処理システムにおいて、
前記切り替え設定をユーザに設定させるユーザインタフェース
を備えたことを特徴とする印刷処理システム。
【請求項６】
他の情報処理装置および画像処理装置と双方向通信を行う双方向通信手段と、
前記他の情報処理装置から前記双方向通信手段が受信したリクエストに基づき、前記画像処理装置の印刷プロトコルに応じて前記画像処理装置に送信するリクエストコマンドを生成するコマンド生成手段と、
前記画像処理装置から前記双方向通信手段が受信した前記リクエストコマンドに対応するレスポンスを、前記他の情報処理装置に送信する、印刷プロトコルに依存しない形式のレスポンスに変換するレスポンス変換手段と
を備えたことを特徴とする情報処理装置。
【請求項７】
コンピュータを、
他の情報処理装置および画像処理装置と双方向通信を行う双方向通信手段、
前記他の情報処理装置から前記双方向通信手段が受信したリクエストに基づき、前記画像処理装置の印刷プロトコルに応じて前記画像処理装置に送信するリクエストコマンドを生成するコマンド生成手段、
前記画像処理装置から前記双方向通信手段が受信した前記リクエストコマンドに対応するレスポンスを、前記他の情報処理装置に送信する、印刷プロトコルに依存しない形式のレスポンスに変換するレスポンス変換手段
として機能させるドライバプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は印刷処理の技術に関する。
【背景技術】
【０００２】
クライアントＰＣ（Personal Computer）からサーバＰＣの共有プリンタを指定することで、サーバＰＣからクライアントＰＣにプリンタドライバがコピーされてインストールされ、クライアントＰＣで個別にプリンタドライバをインストールする必要のない、Ｐｏｉｎｔ＆Ｐｒｉｎｔと呼ばれる技術が知られている。
【０００３】
また、一般に、プリンタドライバとプリンタ間で双方向通信を行うことにより、プリンタドライバがプリンタの機器情報を取得する技術が知られている。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
図１はＰｏｉｎｔ＆Ｐｒｉｎｔ時の双方向通信の例を示す図である。
【０００５】
図１において、クライアントＰＣ１はネットワーク＃１に配置され、サーバＰＣ２はネットワーク＃２に配置され、プリンタ３はネットワーク＃３に配置されている。また、管理上の要請から、ネットワーク＃１のクライアントＰＣ１とネットワーク＃３のプリンタ３が直接通信できない（直接の通信が制限されている）場合を示している。
【０００６】
このような環境では、ネットワーク＃１のクライアントＰＣ１からはネットワーク＃２のサーバＰＣ２しか見えず、ネットワーク＃３のプリンタ３の存在を知ることができない。
【０００７】
そのため、クライアントＰＣ１から直接にプリンタ３とＳＮＭＰ（Simple Network Management Protocol）等のプロトコルで双方向通信して機器情報を取得することができない。
【０００８】
また、クライアントＰＣ１からサーバＰＣ２を経由してプリンタ３と双方向通信を行う技術がすでに知られているが（特許文献１等を参照）、サーバＰＣ２とプリンタ３との接続形態（ＴＣＰ／ＩＰポート、ＵＳＢポート、ＷＳＤポート等）に依存せずに双方向通信を行うことはできない。すなわち、今までの双方向通信では、Ｐｏｉｎｔ＆Ｐｒｉｎｔ環境においてクライアントＰＣ１とプリンタ３の間の直接の通信が制限されている場合には、接続形態に依存せずにクライアントＰＣ１から直接にプリンタ３の機器情報が取得できないという問題があった。
【０００９】
図２はＰｏｉｎｔ＆Ｐｒｉｎｔ時の双方向通信の他の例を示す図であり、ネットワーク＃１のクライアントＰＣ１とネットワーク＃３のプリンタ３が直接通信できる場合を示している。
【００１０】
この場合、サーバＰＣ２を経由してクライアントＰＣ１とプリンタ３の間で双方向通信を行うと、サーバＰＣ２にネットワーク負荷がかかるため、クライアントＰＣ１とプリンタ３との間で直接に双方向通信ができることが望まれる。
【００１１】
しかし、管理上の要請から、クライアントＰＣ１での設定がサーバＰＣ２を経由するものとなっていることが多く、クライアントＰＣ１のユーザは権限がないと設定を変更することができず、クライアントＰＣ１とプリンタ３の間で直接に双方向通信することは困難であった。
【００１２】
本発明は上記の従来の問題点に鑑み提案されたものであり、その目的とするところは、クライアントＰＣとプリンタの間の直接の通信が制限されている場合でも、サーバＰＣとプリンタの接続形式によらずに機器情報を取得できるようにすることにある。また、他の目的として、クライアントＰＣとプリンタの間の直接の通信が行える場合には、直接に通信を行えるようにする。
【課題を解決するための手段】
【００１３】
上記の課題を解決するため、本発明にあっては、情報処理装置および画像処理装置と双方向通信を行う双方向通信手段と、前記情報処理装置から前記双方向通信手段が受信したリクエストに基づき、前記画像処理装置の印刷プロトコルに応じて前記画像処理装置に送信するリクエストコマンドを生成するコマンド生成手段と、前記画像処理装置から前記双方向通信手段が受信した前記リクエストコマンドに対応するレスポンスを、前記情報処理装置に送信する、印刷プロトコルに依存しない形式のレスポンスに変換するレスポンス変換手段とを備える。
【発明の効果】
【００１４】
本発明の印刷処理システムにあっては、クライアントＰＣとプリンタの間の直接の通信が制限されている場合でも、サーバＰＣとプリンタの接続形式によらずに機器情報を取得することができる。
【図面の簡単な説明】
【００１５】
【図１】Ｐｏｉｎｔ＆Ｐｒｉｎｔ時の双方向通信の例を示す図（クライアントＰＣとプリンタが直接通信できない場合）である。
【図２】Ｐｏｉｎｔ＆Ｐｒｉｎｔ時の双方向通信の例を示す図（クライアントＰＣとプリンタが直接通信できる場合）である。
【図３】第１の実施形態におけるシステムの構成例を示す図である。
【図４】Ｐｏｉｎｔ＆Ｐｒｉｎｔ時の印刷アーキテクチャの例を示す図である。
【図５】第１の実施形態における双方向通信のための機能構成例を示す図である。
【図６】第１の実施形態の処理例を示すフローチャートである。
【図７】ランゲージモニタに双方向リクエストを送るために使用する関数の例を示す図である。
【図８】双方向リクエストとリクエストコマンドの対応付けの例を示す図である。
【図９】双方向リクエストを送ってから機器情報が得られるまでの流れの例を示す図（その１）である。
【図１０】双方向リクエストを送ってから機器情報が得られるまでの流れの例を示す図（その２）である。
【図１１】第２の実施形態における双方向通信のための機能構成例を示す図である。
【図１２】第２の実施形態の処理例を示すフローチャートである。
【図１３】双方向通信の切り替え設定のユーザインタフェースの例を示す図である。
【図１４】第３の実施形態における双方向通信のための機能構成例を示す図である。
【図１５】双方向通信に用いる通信方法の指定のユーザインタフェースの例を示す図である。
【図１６】第３の実施形態の処理例を示すフローチャートである。
【発明を実施するための形態】
【００１６】
以下、本発明の好適な実施形態につき説明する。
【００１７】
＜第１の実施形態＞
図３は第１の実施形態におけるシステムの構成例を示す図である。
【００１８】
図３において、ネットワーク＃１に配置されたクライアントＰＣ（情報処理装置）１はネットワーク＃２に配置されたサーバＰＣ（情報処理装置）２と接続され、サーバＰＣ２はネットワーク＃３に配置されたプリンタ（画像処理装置）３と接続されている。
【００１９】
図４はＰｏｉｎｔ＆Ｐｒｉｎｔ時の印刷アーキテクチャの例を示す図である。
【００２０】
クライアントＰＣ１上のアプリケーションプロセス１１で、アプリケーション１２から印刷が実行されると、これをグラフィックデバイスインタフェース１３を介してプリンタドライバ１４が受け、プリンタドライバ１４はスプーラ１５を介して印刷データをスプールファイル１６に滞留させつつ、クライアントＰＣ１のスプーラサービス１７（プリントプロバイダ１８）に送る。
【００２１】
クライアントＰＣ１のスプーラサービス１７は、受け取った印刷データをサーバＰＣ２のスプーラサービス２１に送る。
【００２２】
サーバＰＣ２のスプーラサービス２１では、受け取った印刷データをプリントプロバイダ２２、プリントプロセッサ２３、スプーラ２４、プリントプロバイダ２５、ランゲージモニタ２６、ポートモニタ２７を経由し、更にカーネルモードドライバ２８を介してプリンタ３に送る。
【００２３】
上記のランゲージモニタ２６は本来はＷｉｎｄｏｗｓ（登録商標）ＯＳが提供するものであるが、ベンダーがカスタマイズしたランゲージモニタ２６を入れ替えて使用することができる。これにより、ベンダー独自の機能をランゲージモニタ２６に持たせることが可能となる。
【００２４】
図５は第１の実施形態における双方向通信のための機能構成例を示す図である。
【００２５】
図５において、サーバＰＣ２には、ランゲージモニタ２６内に双方向通信部２６１とコマンド生成部２６２とレスポンス変換部２６３とが設けられている。
【００２６】
図６は第１の実施形態の処理例を示すフローチャートである。
【００２７】
図６において、クライアントＰＣ１は、プリンタ３の機器情報を取得する必要が生じた場合、サーバＰＣ２のランゲージモニタ２６に双方向リクエストを送る（ステップＳ１０１）。
【００２８】
サーバＰＣ２のランゲージモニタ２６は、双方向リクエストを受け取ると、これを双方向通信部２６１に渡す（ステップＳ１０２）。
【００２９】
双方向通信部２６１は、コマンド生成部２６２に双方向リクエストを渡し、リクエストコマンドの取得要求を行う（ステップＳ１０３）。
【００３０】
コマンド生成部２６２は、サーバＰＣ２とプリンタ３の接続形式を基にリクエストコマンドを生成し、双方向通信部２６１に渡す（ステップＳ１０４）。プリンタ３に送るリクエストコマンドおよび通信方法は、サーバＰＣ２とプリンタ３の接続形式により変わる。例えば、ＴＣＰ／ＩＰポートで接続していればＳＮＭＰプロトコルを利用し、ＵＳＢポートで接続していればＰＪＬを利用する。コマンド生成部２６２は、ポートの種類から適切なリクエストコマンドを生成する。
【００３１】
双方向通信部２６１は、コマンド生成部２６２からリクエストコマンドを受け取り、プリンタ３にリクエストコマンドを送り、双方向通信を開始する（ステップＳ１０５）。
【００３２】
双方向通信部２６１は、プリンタ３からレスポンスを受け取り、レスポンス変換部２６３に渡す（ステップＳ１０６）。
【００３３】
レスポンス変換部２６３は、レスポンスをプロトコルに依存しない機器情報に変換する（ステップＳ１０７）。リクエストコマンドがサーバＰＣ２とプリンタ３の通信プロトコルにより変わるのと同様に、プリンタ３からのレスポンスもプロトコルに依存する。レスポンス変換部２６３は、それをプロトコルに依存しない機器情報に変換する。
【００３４】
双方向通信部２６１は、レスポンス変換部２６３から機器情報を受け取り、クライアントＰＣ１に渡す（ステップＳ１０８）。
【００３５】
図７はランゲージモニタ２６に双方向リクエストを送るために使用する関数の例を示す図である。
【００３６】
ランゲージモニタ２６にはＯＳによって決められたインタフェースが存在する。詳細な説明はＭＳＤＮドキュメント（http://msdn.microsoft.com/en-us/library/ms123401）に記述されている。
【００３７】
ここでは、SendRecvBidiDataFromPort()というインタフェースを利用することにより、ランゲージモニタ２６を呼び出したモジュールはランゲージモニタ２６とのデータのやりとりが可能となる。本実施形態では上記の関数を使用することにより、クライアントＰＣ１からサーバＰＣ２のランゲージモニタ２６とデータのやり取りを行う。
【００３８】
図８は双方向リクエストとリクエストコマンドの対応付けの例を示す図である。
【００３９】
双方向リクエストとして、例えば、プリンタのオプション情報を取得する「ＯＰＴＩＯＮ」と、プリンタのメモリサイズを取得する「ＭＥＭＯＲＹＳＩＺＥ」がある。すなわち、プリンタ３のオプション情報を取得する際には、クライアントＰＣ１からサーバＰＣ２に「ＯＰＴＩＯＮ」リクエストを送り、プリンタ３のメモリサイズを取得する際には、クライアントＰＣ１からサーバＰＣ２に「ＭＥＭＯＲＹＳＩＺＥ」リクエストを送る。
【００４０】
図８（ａ）は、サーバＰＣ２とプリンタ３がＵＳＢポートで接続されており、ＰＪＬで通信する場合の双方向リクエストとリクエストコマンドの対応関係を示している。すなわち、コマンド生成部２６２は、「ＯＰＴＩＯＮ」という双方向リクエストを渡されると、「＠ＰＪＬ  ＩＮＦＯ  ＣＯＮＦＩＧ」というリクエストコマンドを生成する。また、コマンド生成部２６２は、「ＭＥＭＯＲＹＳＩＺＥ」という双方向リクエストを渡されると、「＠ＰＪＬ  ＩＮＦＯ  ＭＥＭＯＲＹ」というリクエストコマンドを生成する。
【００４１】
図８（ｂ）は、サーバＰＣ２とプリンタ３がＴＣＰ／ＩＰポートで接続されており、ＳＮＭＰで通信する場合の双方向リクエストとリクエストコマンドの対応関係を示している。すなわち、コマンド生成部２６２は、「ＯＰＴＩＯＮ」という双方向リクエストを渡されると、「１．３．６．１．２．１．４３．１３２５．１」というリクエストコマンドを生成する。また、コマンド生成部２６２は、「ＭＥＭＯＲＹＳＩＺＥ」という双方向リクエストを渡されると、「１．３．６．１．２．１．４３．１３６５４６．０」というリクエストコマンドを生成する。
【００４２】
図９および図１０は双方向リクエストを送ってから機器情報が得られるまでの流れの例を示す図である。
【００４３】
図９は双方向リクエストが「ＯＰＴＩＯＮ」の場合を示しており、（ａ）はＰＪＬで通信する場合、（ｂ）はＳＮＭＰで通信する場合を示している。
【００４４】
図９（ａ）において、双方向リクエスト「ＯＰＴＩＯＮ」がクライアントＰＣ１からサーバＰＣ２に送られると、サーバＰＣ２ではＰＪＬで通信する場合、リクエストコマンド「＠ＰＪＬ  ＩＮＦＯ  ＣＯＮＦＩＧ」を生成し、プリンタ３に送る。プリンタ３からはレスポンス「＠ＰＪＬ  ＩＮＦＯ  ＣＯＮＦＩＧ  ＤＵＰＬＥＸ  ［１  ＥＮＵＭＥＲＡＴＥＤ］  ＤＵＰＬＥＸ」がサーバＰＣ２に送られ、サーバＰＣ２はプロトコルに依存しない機器情報「ＤＵＰＬＥＸ＝ＯＮ」に変換してクライアントＰＣ１に送る。サーバＰＣ２のレスポンス変換部２６３は、例えば、ＰＪＬのレスポンスに「ＤＵＰＬＥＸ」が含まれていれば、機器情報として「ＤＵＰＬＥＸ＝ＯＮ」という情報に変換する。
【００４５】
図９（ｂ）において、双方向リクエスト「ＯＰＴＩＯＮ」がクライアントＰＣ１からサーバＰＣ２に送られると、サーバＰＣ２ではＳＮＭＰで通信する場合、リクエストコマンド「１．３．６．１．２．１．４３．１３２５．１」を生成し、プリンタ３に送る。プリンタ３からはレスポンス「ｄｕｐｌｅｘ」がサーバＰＣ２に送られ、サーバＰＣ２はプロトコルに依存しない機器情報「ＤＵＰＬＥＸ＝ＯＮ」に変換してクライアントＰＣ１に送る。サーバＰＣ２のレスポンス変換部２６３は、例えば、ＳＮＭＰのレスポンスに「ｄｕｐｌｅｘ」が含まれていれば、機器情報として「ＤＵＰＬＥＸ＝ＯＮ」という情報に変換する。
【００４６】
図１０（ａ）において、双方向リクエスト「ＭＥＭＯＲＹＳＩＺＥ」がクライアントＰＣ１からサーバＰＣ２に送られると、サーバＰＣ２ではＰＪＬで通信する場合、リクエストコマンド「＠ＰＪＬ  ＩＮＦＯ  ＭＥＭＯＲＹ」を生成し、プリンタ３に送る。プリンタ３からはレスポンス「＠ＰＪＬ  ＩＮＦＯ  ＭＥＭＯＲＹ  ＭＥＭＯＲＹ＝１０２４」がサーバＰＣ２に送られ、サーバＰＣ２はプロトコルに依存しない機器情報「ＭＥＭＯＲＹＳＩＺＥ＝１０２４」に変換してクライアントＰＣ１に送る。
【００４７】
図１０（ｂ）において、双方向リクエスト「ＭＥＭＯＲＹＳＩＺＥ」がクライアントＰＣ１からサーバＰＣ２に送られると、サーバＰＣ２ではＳＮＭＰで通信する場合、リクエストコマンド「１．３．６．１．２．１．４３．１３６５４６．０」を生成し、プリンタ３に送る。プリンタ３からはレスポンス「１０２４」がサーバＰＣ２に送られ、サーバＰＣ２はプロトコルに依存しない機器情報「ＭＥＭＯＲＹＳＩＺＥ＝１０２４」に変換してクライアントＰＣ１に送る。
【００４８】
クライアントＰＣ１からサーバＰＣ２とプリンタ３の接続形式に依存しない双方向リクエストを送り、プリンタ３からのレスポンスをプロトコルに依存しない機器情報に変換してクライアントＰＣ１に渡すことで、クライアントＰＣ１はサーバＰＣ２とプリンタ３の接続形式を意識することなく機器情報を取得することができる。
【００４９】
＜第２の実施形態＞
図１１は第２の実施形態における双方向通信のための機能構成例を示す図である。
【００５０】
クライアントＰＣ１とプリンタ３の間で直接通信ができる環境においては、サーバＰＣ２を経由して双方向通信を行うとサーバＰＣ２にネットワーク負荷がかかるため、クライアントＰＣ１とプリンタ３の間で直接双方向通信ができることが望まれる。この実施形態では、サーバＰＣ２経由で双方向通信を行うか、クライアントＰＣ１から直接にプリンタ３と双方向通信を行うかを切り替えることができるようにしている。
【００５１】
図１１においては、図５に示した構成に加え、クライアントＰＣ１内のランゲージモニタ１９に切り替え部１９１と双方向通信部１９２とコマンド生成部１９３とレスポンス変換部１９４とが設けられる。なお、クライアントＰＣ１のランゲージモニタ１９は、Ｐｏｉｎｔ＆Ｐｒｉｎｔ環境により、サーバＰＣ２のランゲージモニタ２６と連携して設けられるものである。
【００５２】
図１２は第２の実施形態の処理例を示すフローチャートである。
【００５３】
図１２において、クライアントＰＣ１内でプリンタ３の機器情報を取得する必要が生ずると、クライアントＰＣ１のランゲージモニタ１９の切り替え部１９１は、サーバＰＣ２を経由してプリンタ３と双方向通信を行うか、直接にプリンタ３と双方向通信を行うかを切り替え設定に基づいて判断する（ステップＳ２０１）。
【００５４】
なお、切り替え設定は、図１３に示すようなユーザインタフェースにより、事前にユーザにより設定される。すなわち、「サーバ経由で双方向通信を行う」にチェックを入れると、サーバ経由で双方向通信を行う設定が保存される。チェックを外すと直接にプリンタと双方向通信を行う設定が保存される。切り替え設定は所定のレジストリに保存することができる。
【００５５】
図１２に戻り、サーバＰＣ２を経由する場合（ステップＳ２０２のＹｅｓ）、図６に示したフローチャートと同様になる（ステップＳ２０３）。なお、サーバＰＣ２を経由せずにクライアントＰＣ１とプリンタ３の間で双方向通信を行った結果、それが失敗した場合も、サーバＰＣ２を経由するものとする。
【００５６】
サーバＰＣ２を経由しない場合（ステップＳ２０２のＮｏ）、クライアントＰＣ１の切り替え部１９１は、双方向通信部１９２に双方向リクエストを送る（ステップＳ２０４）。
【００５７】
双方向通信部１９２は、コマンド生成部１９３に双方向リクエストを渡し、リクエストコマンドの取得要求を行う（ステップＳ２０５）。
【００５８】
コマンド生成部１９３は、プリンタ３との接続方式に応じたリクエストコマンドを生成し、双方向通信部１９２に渡す（ステップＳ２０６）。
【００５９】
双方向通信部１９２は、コマンド生成部１９３からリクエストコマンドを受け取り、プリンタ３にリクエストコマンドを送る（ステップＳ２０７）。
【００６０】
双方向通信部１９２は、プリンタ３からレスポンスを受け取り、レスポンス変換部１９４に渡す（ステップＳ２０８）。
【００６１】
レスポンス変換部１９４は、レスポンスをプロトコルに依存しない機器情報に変換し、双方向通信部１９２に渡す（ステップＳ２０９）。
【００６２】
双方向通信部１９２は、レスポンス変換部１９４から機器情報を受けとり、切り替え部１９１に渡し、要求元に渡す（ステップＳ２１０）。
【００６３】
＜第３の実施形態＞
図１４は第３の実施形態における双方向通信のための機能構成例を示す図である。
【００６４】
プリンタとの双方向通信にはいくつかの通信方法（プロトコル）があるが、その通信方法は、通常は印刷ポートごとに決まっている。例えば、ＴＣＰ／ＩＰポートならＳＮＭＰで通信を行い、ＵＳＢポートならＰＪＬで通信を行うなどである。
【００６５】
しかし、ユーザによっては、セキュリティの懸念などから、特定のプロトコルを遮断しておきたい場合がある。例えば、ＳＮＭＰは禁止といったような要望である。
【００６６】
そこで、この第３の実施形態では、機器情報を取得する際の通信方法をユーザが指定できるようにすることで、ユーザの要望に沿えるようにしている。
【００６７】
図１４においては、図５に示した構成に加え、サーバＰＣ２のランゲージモニタ２６に、ユーザの指定した通信方法を保持する通信方法保持部２６４が設けられ、双方向通信部２６１は双方向通信を行うに先立って通信方法保持部２６４から通信方法を取得するようになっている。
【００６８】
図１５は双方向通信に用いる通信方法の指定のユーザインタフェースの例を示す図であり、事前にユーザにより双方向通信に用いる通信方法にチェックが入れられることで通信方法の指定が行われる。通信方法は複数選択することができ、通信方法に優先度を設定することができる。図の例ではＳＮＭＰとＰＪＬが選択されており、上にあるＳＮＭＰの優先度がＰＪＬよりも高くなっている。この場合、優先度の高いＳＮＭＰにより双方向通信を行ない、通信が失敗した場合は次の優先度のＰＪＬにより通信を行う。
【００６９】
図１６は第３の実施形態の処理例を示すフローチャートである。
【００７０】
図１６において、クライアントＰＣ１は、プリンタ３の機器情報を取得する必要が生じた場合、サーバＰＣ２のランゲージモニタ２６に双方向リクエストを送る（ステップＳ３０１）。
【００７１】
サーバＰＣ２のランゲージモニタ２６は、双方向リクエストを受け取ると、これを双方向通信部２６１に渡す（ステップＳ３０２）。
【００７２】
双方向通信部２６１は、通信方法保持部２６４から通信方法を取得する（ステップＳ３０３）。
【００７３】
双方向通信部２６１は、コマンド生成部２６２に双方向リクエストを渡し、リクエストコマンドの取得要求を行う（ステップＳ３０４）。この際、双方向通信部２６１は、通信方法保持部２６４から取得した通信方法を併せて渡す。
【００７４】
コマンド生成部２６２は、双方向通信部２６１から受け取った通信方法を基にリクエストコマンドを生成し、双方向通信部２６１に渡す（ステップＳ３０５）。
【００７５】
双方向通信部２６１は、コマンド生成部２６２からリクエストコマンドを受け取り、プリンタ３にリクエストコマンドを送り、双方向通信を開始する（ステップＳ３０６）。
【００７６】
双方向通信部２６１は、プリンタ３からレスポンスを受け取り、レスポンス変換部２６３に渡す（ステップＳ３０７）。
【００７７】
レスポンス変換部２６３は、レスポンスをプロトコルに依存しない機器情報に変換する（ステップＳ３０８）。リクエストコマンドは通信方法保持部２６４から取得した通信方法により変わるのと同様に、プリンタ３からのレスポンスもプロトコルに依存する。レスポンス変換部２６３は、それをプロトコルに依存しない機器情報に変換する。
【００７８】
双方向通信部２６１は、レスポンス変換部２６３から機器情報を受け取り、クライアントＰＣ１に渡す（ステップＳ３０９）。
【００７９】
＜総括＞
以上説明したように、本実施形態によれば、次のような利点がある。
（１）クライアントＰＣとプリンタの間の直接の通信が制限されている場合でも、サーバＰＣとプリンタの接続形式によらずに機器情報を取得することができる。
（２）ユーザにより通信方法が指定されている場合には、指定された通信方法によりサーバＰＣとプリンタの双方向通信が行われるようにすることができ、セキュリティを考慮した運用を行うことができる。
（３）クライアントＰＣとプリンタの間の直接の通信が行える場合には、直接に通信を行うことができる。
【００８０】
以上、本発明の好適な実施の形態により本発明を説明した。ここでは特定の具体例を示して本発明を説明したが、特許請求の範囲に定義された本発明の広範な趣旨および範囲から逸脱することなく、これら具体例に様々な修正および変更を加えることができることは明らかである。すなわち、具体例の詳細および添付の図面により本発明が限定されるものと解釈してはならない。
【符号の説明】
【００８１】
１          クライアントＰＣ
１１        アプリケーションプロセス
１２        アプリケーション
１３        グラフィックデバイスインタフェース
１４        プリンタドライバ
１５        スプーラ
１６        スプールファイル
１７        スプーラサービス
１８        プリントプロバイダ
１９        ランゲージモニタ
１９１      切り替え部
１９２      双方向通信部
１９３      コマンド生成部
１９４      レスポンス変換部
２          サーバＰＣ
２１        スプーラサービス
２２        プリントプロバイダ
２３        プリントプロセッサ
２４        スプーラ
２５        プリントプロバイダ
２６        ランゲージモニタ
２６１      双方向通信部
２６２      コマンド生成部
２６３      レスポンス変換部
２６４      通信方法保持部
２７        ポートモニタ
２８        カーネルモードドライバ
３          プリンタ
【先行技術文献】
【特許文献】
【００８２】
【特許文献１】特開２００６‐０７９１３８号公報
【図１】
2014032652.tif 000003
【図２】
2014032652.tif 000004
【図３】
2014032652.tif 000005
【図４】
2014032652.tif 000006
【図５】
2014032652.tif 000007
【図６】
2014032652.tif 000008
【図７】
2014032652.tif 000009
【図８】
2014032652.tif 000010
【図９】
2014032652.tif 000011
【図１０】
2014032652.tif 000012
【図１１】
2014032652.tif 000013
【図１２】
2014032652.tif 000014
【図１３】
2014032652.tif 000015
【図１４】
2014032652.tif 000016
【図１５】
2014032652.tif 000017
【図１６】
2014032652.tif 000018