(57)【特許請求の範囲】
【請求項１】
監視対象のプリンターを制御するためのデバイス制御部と、
前記プリンターとの通信を実行するための通信リソースを有する通信リソース保持部と、を有し、
前記デバイス制御部は、前記プリンターへ印刷ジョブを送信した後、前記プリンターのアイドル状態から駆動状態への変化を示すトリガーが前記プリンターから入力されると、オペレーティングシステムが実行する一つのプロセスを起動し、当該プロセスにおいて、前記通信リソースを呼び出し、当該通信リソースを用いた前記プリンターとの通信により前記プリンターを監視する、ことを特徴とする通信制御装置。
【請求項２】
前記プロセスは、前記通信リソースの呼び出しを実現させたドライバーの情報を保持し、前記プリンターの監視結果に基づく外部への通知処理を、当該保持した情報に対応するドライバーに実行させる、ことを特徴とする請求項１に記載の通信制御装置。
【請求項３】
監視対象のプリンターとの通信をコンピューターに実現させる通信制御ドライバーであって、
前記プリンターへ印刷ジョブを送信した後、前記プリンターのアイドル状態から駆動状態への変化を示すトリガーが前記プリンターから入力されると、オペレーティングシステムが実行する一つのプロセスを起動し、当該プロセスにおいて、前記コンピューターにインストールされたアプリケーションが有する前記プリンターとの通信を実行するための通信リソースを呼び出し、当該通信リソースを用いた前記プリンターとの通信により前記プリンターを監視する機能、を実現させることを特徴とする通信制御ドライバー。
【請求項４】
監視対象のプリンターとの通信をコンピューターに実現させる通信制御方法であって、
前記プリンターへ印刷ジョブを送信した後、前記プリンターのアイドル状態から駆動状態への変化を示すトリガーが前記プリンターから入力されると、オペレーティングシステムが実行する一つのプロセスを起動し、当該プロセスにおいて、前記コンピューターにインストールされたアプリケーションが有する前記プリンターとの通信を実行するための通信リソースを呼び出し、当該通信リソースを用いた前記プリンターとの通信により前記プリンターを監視する、ことを特徴とする通信制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信制御装置、通信制御ドライバーおよび通信制御方法に関する。
【背景技術】
【０００２】
オペレーティングシステム（以下、ＯＳ）としての、Ｍｉｃｒｏｓｏｆｔ社（登録商標）が提供するＷｉｎｄｏｗｓ（登録商標）、において動作するＶｅｒｓｉｏｎ４プリンタードライバー（以下、Ｖ４プリンタードライバー）が知られている。Ｖ４プリンタードライバーにおいては、印刷中に発生したプリンターのエラー等、プリンターの特定の状態を監視してユーザーへ通知する仕組みに関し、Bidirectional communication（以下、Ｂｉｄｉ）と称される双方向通信技術が用いられている。Ｖ４プリンタドライバーは、ＢｉｄｉスキーマおよびDriver Event XMLファイルと呼ばれる、ＸＭＬ形式のファイルを有している。
【０００３】
Ｂｉｄｉスキーマは、プリンターとＶ４プリンタードライバーを搭載した制御装置との間で採用される各接続形式（ＴＣＰ/ＩＰ接続、ＷＳＤ接続、等）に応じて、プリンターからの応答値（ＭＩＢ（Management Information Base）値等)とＢｉｄｉで扱う値（Ｂｉｄｉ値）とを関連付けて記述している。また、Driver Event XMLファイルは、Ｂｉｄｉスキーマで定義されたＢｉｄｉで扱う値とイベント発生の条件等を関連付けて記述している。このような構成により、Ｂｉｄｉでは、プリンターの状態によって変化する応答値に応じてイベント（Driver Event）を発生させる仕組みを構築している。イベントが発生すると、制御装置においては、特定のアプリケーションを実行するためのバックグラウンドタスクが発生し、このバックグラウンドタスクで、前記イベントの種類に応じた通知（トースト、バッジ、タイルテキスト、等と呼ばれる表示形式での通知）を実行することができる。
【０００４】
また、Ｖ４プリンタードライバーが有するプリンター監視処理の機能を利用してプリンターの監視を行う印刷制御装置が知られている（特許文献１参照）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１４‐７１５７３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
上述のＢｉｄｉスキーマおよびDriver Event XMLファイルは、いずれもテキストベースのファイルであるため、それらに記述できる条件式や値は、テキストで表現できるものに限られる。また、Driver Event XMLファイルにおいては、値の基本的な比較演算式は記述可能ではあるが、複合的なデータに含まれる値の解析や、各ビット値の違いに応じた条件判断に必要な条件式を記述することができない。そのため、プリンターからの応答値が、ＢｉｄｉスキーマやDriver Event XMLファイルに記述できない形式の情報（Ｂｉｄｉで扱えない情報）である場合、上述した仕組みの下では、プリンターの状態をユーザーへ通知することができないという課題が生じる。また、前記文献は、このような課題を解決するものではない。
【０００７】
本発明は上述の課題に鑑みてなされたものであり、ある通信形態によるデバイスの監視には限界がある状況においても当該デバイスに対する監視を的確に実行することが可能な通信制御装置、通信制御ドライバーおよび通信制御方法を提供する。
【課題を解決するための手段】
【０００８】
本発明の態様の一つは、通信制御装置は、監視対象のデバイスを制御するためのデバイス制御部と、前記デバイスとの通信を実行するための通信リソースを有する通信リソース保持部と、を有し、前記デバイス制御部は、前記デバイスの監視を開始するためのトリガーが入力されると、前記通信リソースを呼び出し、当該通信リソースを用いた前記デバイスとの通信により前記デバイスを監視する。
【０００９】
当該構成によれば、デバイス制御部は、デバイスの監視を開始するためのトリガーが入力されたことに応じて前記通信リソースを呼び出し、当該通信リソースを用いた前記デバイスとの通信により前記デバイスを監視する。これにより、ある通信形態（例えば、前記Ｂｉｄｉ）を介したデバイスの監視には限界がある状況においても、前記通信リソースを用いることにより、デバイスに対する監視を的確に実行することができる。
【００１０】
本発明の態様の一つは、前記デバイス制御部は、前記デバイスのアイドル状態から駆動状態への変化を示す前記トリガーの入力されると、オペレーティングシステムが実行する一つのプロセスを起動し、当該プロセスにおいて前記通信リソースを用いた前記デバイスとの通信を行う、としてもよい。
当該構成によれば、監視対象のデバイスが駆動状態へ切り替わったタイミングで、前記通信リソースを用いたデバイスとの通信を実行するためのプロセスが起動し、当該プロセスにおいてデバイスの監視が実現する。
【００１１】
本発明の態様の一つは、前記プロセスは、前記通信リソースの呼び出しを実現させたドライバーの情報を保持し、前記デバイスの監視結果に基づく外部への通知処理を、当該保持した情報に対応するドライバーに実行させる、としてもよい。
当該構成によれば、プロセスと前記通信リソースの呼び出しを実現させたドライバーとが紐づいてることで、当該ドライバーに通知処理を容易かつ確実に実行させることができる。
【００１２】
本発明の技術的思想は、通信制御装置という物以外によっても実現される。例えば、本発明として、監視対象のデバイスとの通信をコンピューターに実現させる通信制御ドライバーであって、前記デバイスの監視を開始するためのトリガーが入力されると、前記コンピューターにインストールされたアプリケーションが有する前記デバイスとの通信を実行するための通信リソースを呼び出し、当該通信リソースを用いた前記デバイスとの通信により前記デバイスを監視する機能、を実現させる構成が挙げられる。また、本発明は、通信制御ドライバーによって実現される工程を含んだ方法（通信制御方法）や、通信制御ドライバーを記憶したコンピューター読み取り可能な記憶媒体、といった各種カテゴリーにて実現されてもよい。
【図面の簡単な説明】
【００１３】
【図１】通信制御装置の構成を例示するブロック図。
【図２】デバイスの監視処理を示すフローチャート。
【図３】Ｂｉｄｉスキーマの記述例の一部を示す図。
【発明を実施するための形態】
【００１４】
以下、図面を参照しながら本発明の実施形態を説明する。
１．通信制御装置の概略：
図１は、本実施形態にかかる通信制御装置の構成を例示するブロック図である。印刷制御装置１０は、通信制御装置の一例である。印刷制御装置１０は、例えば、ＲＡＭ、ＲＯＭ、ＣＰＵ等を備えるＩＣやその他の記憶媒体等による制御部２０を備える。制御部２０は、ＲＯＭやその他の記憶媒体に記録されたプログラム（例えば、プリンタードライバー１２、ＷＳＤＡ１３、アプリケーション１４等）に従った処理をＯＳ１１の下で実行することができる。ＯＳ１１が管理する環境下に、Ｖ４プリンタードライバーの一種であるプリンタードライバー（以下、ドライバー）１２を始めとしたこれらプログラムがインストールされている。ドライバー１２（ドライバー１２の少なくとも一部の機能）は、本発明にかかる通信制御ドライバーに該当する。ＯＳ１１は、Ｖ４プリンタードライバーが動作可能なＯＳを指しており、一例として、Ｗｉｎｄｏｗｓ８が挙げられる。ＷＳＤＡとは、Windows Store Device appの略であり、一種のアプリケーションである。
【００１５】
印刷制御装置１０は、図示しないインターフェースを備えており、印刷制御装置１０には当該インターフェースを介して入力部５０と表示部５１とプリンター５２とが接続される。入力部５０はユーザーの入力操作を受け付けるための入力装置であり、マウス、キーボード、タッチパネル、各種入力キー等が該当し得る。表示部５１は、制御部２０が出力する信号に応じて任意の画像を表示するディスプレイである。プリンター５２は制御部２０が出力する印刷データに基づいて印刷データが示す画像を印刷する印刷装置であり、制御部２０が出力するレンダリング後の印刷データに基づいて印刷を実行する。プリンター５２は、本実施形態における監視対象のデバイスの一例である。
【００１６】
印刷制御装置１０は、例えば、ＰＣ（パーソナルコンピューター）、タブレット型端末、スマートフォン等といった、プリンター５２に対する制御装置となり得る様々な装置によって実現される。また、印刷制御装置１０に含まれる構成の一部（少なくとも制御部２０を含む構成）を指して、本発明にかかる通信制御装置と把握してもよい。印刷制御装置１０、入力部５０および表示部５１は、それぞれが独立した製品であってもよいし、一体的に構成された一製品であってもよい。
【００１７】
２．デバイスの監視処理：
図２は、本実施形態にかかるデバイスの監視処理をフローチャートにより示している。当該フローチャートは、主に、制御部２０が、ＯＳ１１、ドライバー１２およびＷＳＤＡ１３と協働することにより実現する。当該フローチャートは、説明の便宜上、監視対象となるプリンター５２側の処理も含んでいる。当該フローチャートの少なくとも一部は、本発明の通信制御方法を表現している。図２では、フローチャートの各ステップと、各ステップを実現させるプリンター５２、ＯＳ１１、ドライバー１２およびＷＳＤＡ１３のいずれかとの対応関係を例示している。ただし、当該対応関係は厳密に解されなくてもよい。また、ここでは、プリンター５２と印刷制御装置１０とを接続するインターフェースは、ＴＣＰ/ＩＰ（Transmission Control Protocol/Internet Protocol）を用いて接続していると仮定する。
【００１８】
ステップＳ１００では、制御部２０は、印刷対象についての印刷指示を、プリンター５２へ送信する。具体的には、制御部２０は、印刷対象を示す画像ファイルをアプリケーション１４から入力し、当該入力した画像ファイルに対して所定のレンダリングを実行することによりプリンター５２が印刷可能な形式の印刷データを生成する。そして、当該印刷データを含んだ印刷指示（印刷ジョブ）をプリンター５２へ送信する。なお、アプリケーション１４から入力する画像ファイルは、例えば、ＸＰＳ（XML Paper Specfication）仕様で記述されたＸＰＳファイルである。
【００１９】
プリンター５２は、アイドル状態で前記印刷指示（印刷ジョブ）を受信すると（ステップＳ３００）、受信した印刷ジョブの処理を開始する（ステップＳ３１０）。つまり、プリンター５２による印刷データに基づく印刷が開始する。併せてステップＳ３１０では、プリンター５２は、現在の自身の状態を示すＭＩＢ値を印刷制御装置１０へ送信する。プリンター５２は、印刷ジョブの処理を開始したことにより、状態がアイドル状態（Ｉdle）から駆動状態（Printing）へ変化するため、当該Printingを示す所定のＭＩＢ値を印刷制御装置１０へ送信する。
【００２０】
制御部２０は、Printingを示す所定のＭＩＢ値をプリンター５２から入力すると（ステップＳ１１０）、当該入力に応じて、特定のDriver Eventを発生させる（ステップＳ１２０）。具体的には、制御部２０は、ＴＣＰ/ＩＰ接続に対応させて予め保持しているＢｉｄｉスキーマ１５（図１）を参照することにより、Printingを示す所定のＭＩＢ値をＢｉｄｉ値へ変換する。さらに、制御部２０は、予め保持しているDriver Event XMLファイル１６（図１）を参照することにより、当該Ｂｉｄｉ値に関連付けられている前記特定のDriver Eventを発生させる。つまり本実施形態では、プリンター５２の状態がPrintingとなった場合に、前記特定のDriver Eventを発生させるように、予めＢｉｄｉスキーマ１５およびDriver Event XMLファイル１６を記述しておく。
【００２１】
図３は、Ｂｉｄｉスキーマ１５の記述例の一部である。当該例において、符号ｄが指し示す記述におけるComversion mibValue="4" bidiValue="Printing"は、プリンター５２から入力されたＭＩＢ値が"4"であれば、これを、Ｂｉｄｉ値"Printing"へ変換することを意味している。このようなステップＳ１００，Ｓ３００，Ｓ３１０，Ｓ１１０，Ｓ１２０の流れはＢｉｄｉの仕組みを利用したものであると言える。
【００２２】
制御部２０は、前記特定のDriver Eventの発生を契機として、ＯＳ１１が実行する一つのBackgroundプロセスを起動させる（ステップＳ１３０）。ここでは、ドライバー１２によるプリンター５２に対する通常の印刷制御処理とは別にバックグラウンドで処理されるタスクあるいはプロセスという意味で、Backgroundプロセスと呼ぶ。
【００２３】
制御部２０は、前記起動したBackgroundプロセスにおいて、ＷＳＤＡ１３が有する特定の関数を呼び出す（ステップＳ１４０）。当該関数は、監視対象のデバイス（プリンター５２）との通信を実行するための通信リソースの一例である。当該関数は、コンピュータープログラムの一種であり、以下に述べるプリンター５２の監視に必要な通信手続きや判定基準等を記述している。
【００２４】
制御部２０は、前記Backgroundプロセスにおいて、前記呼び出した関数に従ってポーリングによるプリンター５２の監視を開始する（ステップＳ１５０）。当該監視は、ステップＳ１６０等の処理を、例えば、数秒あるいは数十秒毎に繰り返すことにより実現する。
【００２５】
制御部２０は、プリンター５２との通信により、プリンター５２に対して状態の通知をリクエストし、当該リクエストへの応答として、プリンター５２から状態通知を取得する（ステップＳ１６０）。プリンター５２側では、当該リクエストに応じて制御部２０との通信ネゴシエーションを実行し、制御部２０へ自身の現在の状態を通知する（ステップＳ３２０）。前記呼び出した関数に従って制御部２０がプリンター５２との間で実行する通信（ステップＳ１６０，Ｓ３２０）は、基本的にはＶ４プリンタードライバーにおける前記Ｂｉｄｉの仕組みは利用せず、例えば、汎用性の高いＳＮＭＰ (Simple Network Management Protocol)によるＭＩＢ値の送受信により実現する。あるいは、当該通信は、いわゆるＣ♯等のプログラミング言語で開発された前記関数に従って実行するとしてもよい。
【００２６】
制御部２０は、ステップＳ１６０で取得したプリンター５２の状態に応じて、ユーザーへの通知が必要であるか否か判定し（ステップＳ１７０）、通知が必要であればステップＳ１８０の処理を実行し、通知が不要であればステップＳ１９０の判定に進む。ステップＳ１７０における判定基準も、ＷＳＤＡ１３が有する前記通信リソースに記述されている。例えば、制御部２０は、取得したプリンター５２の状態が、当該判定基準に照らして所定のエラー（インク切れ、用紙切れ、紙ジャム、等）に該当する場合に、通知が必要と判定する。
【００２７】
ステップＳ１８０では、制御部２０は、ステップＳ１７０で必要と判定した通知を実行する。ここでいう通知は、知られているようなトースト、バッジ、タイルテキスト等の表示形式による表示部５１を介した視覚的な通知である。例えば、制御部２０は、ステップＳ１７０でインク切れによるエラーを理由に通知の必要有りと判定した場合には、インク切れの旨を表示部５１にトースト表示（一種のポップアップ表示）させる（ステップＳ１８０）。
【００２８】
一方、ステップＳ１９０では、制御部２０は、プリンター５２が開始した印刷が終了したか否か判定する。例えば、制御部２０は、プリンター５２の状態がPrintingからIdleへ切り替わったことを検知した場合に、印刷が終了したと判定する。プリンター５２の状態のPrintingからIdleへの切り替わりは、前記Ｂｉｄｉの仕組みに従って検知することができる。あるいは、制御部２０は、印刷が通常終了するために十分な時間等に相当する時間（タイムアウト時間）というものを予め定めておき、ステップＳ１５０から当該タイムアウト時間が経過した場合に印刷完了と判定してもよい。
【００２９】
制御部２０は、ステップＳ１９０で印刷完了と判定しなかった場合はステップＳ２００へ進み、印刷完了と判定した場合はステップＳ２１０へ進む。ステップＳ２００では、制御部２０は、予め定めたポーリング間隔（例えば、数秒あるいは数十秒）の時間だけ待機した後、ステップＳ１６０以下を繰り返す。一方、ステップＳ２１０では、制御部２０は、ステップＳ１５０で開始したプリンター５２の監視を終了させ、ステップ２２０では、ステップＳ１３０以来継続している前記Backgroundプロセスを終了させる。
【００３０】
ここで、制御部２０は、ＯＳ１１の管理下でドライバー１２を実行することによりプリンター５２の駆動（印刷動作）を制御する点で、監視対象のデバイス（プリンター５２）を制御するためのデバイス制御部として機能すると言える。また、制御部２０は、ＷＳＤＡ１３を有する点で、デバイス（プリンター５２）との通信を実行するための通信リソースを有する通信リソース保持部としても機能すると言える。また、ステップＳ３１０，Ｓ１１０〜Ｓ１６０等の説明によれば、制御部２０は、デバイス（プリンター５２）の監視を開始するためのトリガーが入力されると前記通信リソースを呼び出し、当該通信リソースを用いたデバイス（プリンター５２）との通信によりデバイス（プリンター５２）を監視する、と言える。ここでいうトリガーの概念には、ステップＳ１１０で入力する前記Printingを示す所定のＭＩＢ値や、あるいはステップＳ１２０で発生する特定のDriver Eventが該当する。
【００３１】
また、ステップＳ３１０，Ｓ１１０〜Ｓ１６０等の説明によれば、制御部２０は、前記トリガーが入力されると、ＯＳ１１が実行する一つのプロセス（Backgroundプロセス）を起動し、当該プロセスにおいて前記通信リソースを用いたデバイス（プリンター５２）との通信を行う、と言える。なお図２によれば、ステップＳ１３０で起動したBackgroundプロセスにおいて、ステップＳ１４０でドライバー１２がＷＳＤＡ１３の関数を呼び出した後は、ステップＳ１５０〜Ｓ１７０，Ｓ１９０〜Ｓ２１０の処理をＷＳＤＡ１３が実行しているように解釈できるが、実際には当該Backgroundプロセスにおいて、主としてドライバー１２が、ＷＳＤＡ１３が有する前記関数に従ってステップＳ１５０〜Ｓ１７０，Ｓ１９０〜Ｓ２１０の処理を実現させている。
【００３２】
３．効果等の説明：
このように本実施形態によれば、制御部２０は、制御対象とするプリンター５２の監視を開始するためのトリガーが入力されたことに応じて、ＷＳＤＡ１３が有する前記通信リソースを呼び出し、当該通信リソースを用いたプリンター５２との通信によりプリンター５２を監視する。これまで通常実行されてきたＢｉｄｉの仕組みを利用したデバイスの監視においては、デバイスからの応答値がＢｉｄｉスキーマやDriver Event XMLファイルに記述できない形式の情報（Ｂｉｄｉで扱えない情報）である場合には、当該デバイスの状態を取得してユーザーへ通知することができないという制約があった。しかし本実施形態によれば、前記通信リソース（ＷＳＤＡ１３から呼び出す前記関数）に従って実行するプリンター５２との間の通信は、このような制約とは無関係であるため、プリンター５２との間で確実な通信を実行し、プリンター５２の状態を的確に監視し、ユーザーへ通知することができる。例えば、前記通信リソースをＣ♯等のプログラミング言語を用いて作成することで、プリンター５２からの応答値が、複雑に構造化されたデータやビット値等であっても、制御部２０は、それらを解析、評価し、デバイスの状態を取得することができるようになる。
【００３３】
また本実施形態によれば、図２の説明から判るように、ステップＳ１３０で起動したBackgroundプロセスにおいて実行されるプリンター５２の監視は、プリンター５２による印刷の終了とともに終了し、当該Backgroundプロセスも終了する。つまり、このような監視処理を、ＯＳ１１に常駐させるのではなく、監視対象のデバイスが駆動中のみ実行することで、制御部２０の負担を軽減することができる。なお、ステップＳ１３０で起動したBackgroundプロセス（当該プロセスを管理するＯＳ１１）は、ドライバー１２（当該BackgroundプロセスにおいてステップＳ１４０でＷＳＤＡ１３の前記通信リソースの呼び出しを実現させたドライバー）の情報を自動的に保持する。そのため、当該Backgroundプロセス（当該プロセスを管理するＯＳ１１）は、プリンター５２の監視結果に基づく外部への通知処理（ステップＳ１８０）を、当該保持した情報に対応するドライバー１２に実行させることができる。つまり、Backgroundプロセスと前記通信リソースの呼び出しを実現させたドライバー１２とが紐づいてることで、当該ドライバー１２に通知処理を容易かつ確実に実行させることができる。
【００３４】
ここで、ＢｉｄｉスキーマやDriver Event XMLファイルに記述できる形式の情報だけを応答値として返す仕様に改変したファームウェアをプリンター５２に搭載することができれば、上述したような制約は実質的に無くなると言える。しかし、市場に大量に流通しているプリンター５２が搭載する様々な仕様のファームウェアをこのように改変することは、無数のユーザーに多くの労力とコストを要求することとなり現実的ではない。本実施形態では、ＢｉｄｉスキーマやDriver Event XMLファイルに記述できる形式以外の形式の応答値も返し得るプリンター５２との通信を、別途開発したＷＳＤＡ１３の通信リソースを利用して実現する仕組みとする。そのため、上述したようなプリンター５２側でのファームウェアの改変は不要となり、かつ、プリンター５２が返し得る様々な形態の応答値を十分に活用する自由度の高い通信（監視のための通信）を実現することができる。
【００３５】
図２の説明では、プリンター５２と印刷制御装置１０とを接続するインターフェースは、ＴＣＰ/ＩＰ接続であるとしたが、本実施形態は、ＵＳＢ（Universal Serial Bus）接続や、ＷＳＤ（Web Service for Devices）接続といった様々な接続方式に適用可能である。また本実施形態が想定する通信制御装置による監視対象のデバイスは、プリンターに限定されず、Ｂｉｄｉに対応したドライバーを実装する通信制御装置によって駆動制御される様々なデバイスが該当し得る。
【符号の説明】
【００３６】
１０…印刷制御装置（通信制御装置）、１１…ＯＳ、１２…プリンタードライバー、１３…ＷＳＤＡ、１４…アプリケーション、２０…制御部、５０…入力部、５１…表示部、５２…プリンター
【図１】
0006547462.tif 000002
【図２】
0006547462.tif 000003
【図３】
0006547462.tif 000004