(57)【特許請求の範囲】
【請求項１】
アプリケーションが動作可能な情報処理装置であって、
前記アプリケーションは、
周辺装置との通信を占有するための制御ジョブを生成して、ジョブキューに投入する生成手段と、
前記ジョブキューに投入されている前記制御ジョブを削除させる削除手段と、
を有し、
前記ジョブキューに投入されている前記制御ジョブのステータスが処理中である場合、通信手段を介した前記周辺装置との通信は、前記制御ジョブを作成したアプリケーションに占有され、
前記削除手段は、前記アプリケーションのための通信が完了した後、前記ジョブキューに投入されている前記制御ジョブを削除させることを特徴とする情報処理装置。
【請求項２】
前記情報処理装置は、前記ジョブキューに投入されているジョブを処理する処理手段を更に有し、
前記処理手段は、前記ジョブキューに投入されているジョブのうち、処理対象のジョブが前記制御ジョブであるか否かを判定し、前記制御ジョブである場合は、前記削除手段により当該制御ジョブが削除されるまでステータスが処理中となるように制御することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記制御ジョブは、自身が制御ジョブであることを示す情報と、当該制御ジョブを生成したアプリケーションを一意に識別するための情報とが付加されることを特徴とする請求項１または２に記載の情報処理装置。
【請求項４】
前記付加された情報は、前記制御ジョブのジョブ名として付加されることを特徴とする請求項３に記載の情報処理装置。
【請求項５】
前記ジョブキューに投入されている前記制御ジョブのステータスを監視する監視手段を更に有し、
前記監視手段は、前記制御ジョブのジョブ名に基づき、当該アプリケーションが生成した制御ジョブを監視対象として特定することを特徴とする請求項４に記載の情報処理装置。
【請求項６】
前記処理手段は、ｖ４プリンタドライバに備えられるＢｉｄｉ拡張ＪａｖａＳｃｒｉｐｔにより実行されることを特徴とする請求項２に記載の情報処理装置。
【請求項７】
アプリケーションが動作可能な情報処理装置の制御方法であって、
前記アプリケーションにおいて、
周辺装置との通信を占有するための制御ジョブを生成して、ジョブキューに投入する生成工程と、
前記ジョブキューに投入されている前記制御ジョブを削除させる削除工程と、
を有し、
前記ジョブキューに投入されている前記制御ジョブのステータスが処理中である場合、通信手段を介した前記周辺装置との通信は、前記制御ジョブを作成したアプリケーションに占有され、
前記削除工程において、前記アプリケーションのための通信が完了した後、前記ジョブキューに投入されている前記制御ジョブを削除させることを特徴とする情報処理装置の制御方法。
【請求項８】
コンピューターを、
周辺装置との通信を占有するための制御ジョブを生成して、ジョブキューに投入する生成手段、
前記ジョブキューに投入されている前記制御ジョブを削除させる削除手段、
として機能させるプログラムであって、
前記ジョブキューに投入されている前記制御ジョブのステータスが処理中である場合、通信手段を介した前記周辺装置との通信は、前記制御ジョブを作成したアプリケーションに占有され、
前記削除手段は、前記プログラムのための通信が完了した後、前記ジョブキューに投入されている前記制御ジョブを削除させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置およびその制御方法、並びにプログラムに関する。
【背景技術】
【０００２】
Ｗｉｎｄｏｗｓ（登録商標）環境では、従来のプリンタドライバ（ｖ３プリンタドライバ）アーキテクチャーにおいて、ランゲージモニターという双方向制御モジュールをベンダーが提供することが可能であった。ランゲージモニターは印刷ジョブの送受信を制御すること、また、各種アプリケーションから印刷装置への情報の書込み及び取得要求を制御することも可能であった。  
【０００３】
近年、次世代のプリンタドライバ（ｖ４プリンタドライバ）アーキテクチャーによる、Ｂｉｄｉｒｅｃｔｉｏｎａｌ（Ｂｉｄｉ）スキーマを用いた標準的な情報送受信方法が策定された。この次世代のｖ４プリンタドライバのアーキテクチャーではランゲージモニターが存在しないため、自由な情報送受信制御を行うことが難しくなるおそれがあった。特許文献１では、Ｂｉｄｉスキーマを用いた標準的な情報送受信方法が記載されている。特に、特許文献１は、プリンタドライバに同梱されたＢｉｄｉ拡張ファイル、Ｂｉｄｉ拡張ＪａｖａＳｃｒｉｐｔ（Ｂｉｄｉ拡張ＪＳ）ファイルという外部依存ファイルを、ＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）のポートモニターが読み出すことを開示している。この外部依存ファイルにて、プリンタドライバを作成する各社プリンタベンダー毎のユニークな情報送受信仕様が実現される。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】米国特許出願公開第２０１３／００６７１２０号明細書
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、特許文献１では、あるソフトウェアがＢｉｄｉスキーマを用いて情報送受信処理を実行している途中で、他のソフトウェアからのＢｉｄｉスキーマを用いた情報送受信の割り込みが行われてしまうという課題について考慮されていない。その結果、例えば、あるソフトウェアが取得すべき情報が、他のソフトウェアに送信されてしまうなど、ユーザーの意図した処理が実行されないおそれがあった。
【０００６】
本発明はこうした課題を解決すべく、ＯＳ標準技術と共存可能な排他制御を提供することを目的とする。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、本願発明は以下の構成を有する。すなわち、アプリケーションが動作可能な情報処理装置であって、前記アプリケーションは、周辺装置との通信を占有するための制御ジョブを生成して、ジョブキューに投入する生成手段と、前記ジョブキューに投入されている前記制御ジョブを削除させる削除手段と、を有し、前記ジョブキューに投入されている前記制御ジョブのステータスが処理中である場合、通信手段を介した前記周辺装置との通信は、前記制御ジョブを作成したアプリケーションに占有され、前記削除手段は、前記アプリケーションのための通信が完了した後、前記ジョブキューに投入されている前記制御ジョブを削除させる。
【発明の効果】
【０００８】
本発明によれば、ＯＳ標準技術と共存可能な排他制御を提供し、ユーザーの意図した処理を実行することが可能となる。
【図面の簡単な説明】
【０００９】
【図１】印刷装置と情報処理装置のハードウェア構成の例を示す図。
【図２】プリンタドライバとＯＳのプリントサブシステムの構成例を示す図。
【図３】アプリケーションの情報取得処理を示すフローチャート。
【図４】Ｂｉｄｉ拡張ＪＳの処理を示すフローチャート。
【図５】Ｂｉｄｉ拡張スキーマ定義ファイルの記述例を示す図。
【図６】各種コマンドの記述例を示す図。
【図７】第一の実施形態に係る全体的な処理の流れを示すシーケンス図。
【図８】第二の実施形態に係る全体的な処理の流れを示すシーケンス図。
【図９】プリントキューのＧＵＩを示す図。
【発明を実施するための形態】
【００１０】
以下、添付図面を参照して本発明の好適な実施の形態を詳しく説明する。なお、以下の実施の形態は特許請求の範囲に係る本発明を限定するものでなく、また本実施の形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。  
【００１１】
＜第一の実施形態＞
［装置構成］
本実施形態における印刷装置と情報処理装置のハードウェア構成の例を、図１を参照して説明する。
【００１２】
情報処理装置１００は、入力インタフェース１０２、ＣＰＵ１０３、ＲＯＭ１０４、ＲＡＭ１０５、外部記憶装置１０６、出力インタフェース１０８、および、ＵＳＢインタフェース１１０を有する。情報処理装置１００は、ＵＳＢインタフェース１１０およびＵＳＢケーブル１９０を介して印刷装置１５０と通信可能である。ＲＯＭ１０４には初期化プログラムが格納されており、外部記憶装置１０６にはアプリケーションプログラム群、ＯＳ、プリンタドライバやその他の各種のデータが保存されている。ＲＡＭ１０５は、外部記憶装置１０６に格納される各種プログラムによりワークメモリとして使用される。入力インタフェース１０２は、キーボード１０１およびマウス１０９に接続され、これらを介してユーザーからの入力を受け付ける。出力インタフェース１０８は、表示部１０７と接続され、表示部１０７に表示する各種データを送受信する。
【００１３】
印刷装置１５０は、ＵＳＢインタフェース１５１、ＲＡＭ１５２、プリントエンジン１５３、ＲＯＭ１５４、およびＣＰＵ１５５を有する。印刷装置１５０は、ＵＳＢインタフェース１５１およびＵＳＢケーブル１９０を介して情報処理装置１００と通信可能である。ＲＡＭ１５２は、ＣＰＵ１５５の主メモリもしくはワークメモリとして用いられ、受信した印刷データを一旦保存するための受信バッファーや各種のデータを保存する。プリントエンジン１５３は、ＲＡＭ１５２に保存されたデータに基づき印刷を行う。ここでは例として情報処理装置１００と印刷装置１５０の処理分担を上記のように示したが、特にこの分担形態に限らず他の形態であっても構わない。
【００１４】
図２は、ＰＣ２００に備えられたプリンタドライバとＯＳのプリントサブシステムの構成例を示す図である。ＰＣ２００は、印刷装置２５０とＵＳＢケーブルを介して通信可能である。なお、ＰＣ２００は、図１の情報処理装置１００に対応し、印刷装置２５０は、図１の印刷装置１５０に対応する。
【００１５】
まず、図２を用いて、ＰＣ２００から印刷装置２５０へ印刷データが渡るまでのデータの流れを説明する。印刷アプリケーション２０１は、ＯＳが提供する印刷指示を行うＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ）を利用し、ＯＳへ印刷処理の要求を行う。本実施形態に係るＰＣ２００では、１または複数の印刷アプリケーション２０１が動作可能であるとする。印刷処理の要求に基づいて発行された印刷ジョブは、ＯＳ内のプリントサブシステム２０２のスプーラ２０３にて処理される。スプーラ２０３は、印刷アプリケーション２０１から発行された印刷ジョブを、ジョブキューであるプリントキュー２０４に格納する。スプーラ２０３は、ＰＣ２００内の複数の印刷アプリケーション２０１からの複数の印刷ジョブをプリントキュー２０４に格納する。スプーラ２０３は、プリントキュー２０４に格納した印刷ジョブを、ｖ４のプリンタドライバ２０５（以降、単に「プリンタドライバ」と称す）へ順次送信する。ここで、スプーラ２０３が印刷ジョブをプリンタドライバ２０５に送信する処理をデスプール処理と称す。プリンタドライバ２０５は、印刷ジョブを受信すると、フィルター２０６を用いてページ構成処理やコマンド生成処理を行い、印刷装置２５０が解釈可能な印刷データを生成する。
【００１６】
ここでのページ構成処理とは、印刷アプリケーション２０１から指示された印刷設定情報に基づいてページの順序を並べ替える処理や、複数ページを用紙の１つの面に相当する物理ページに配置するための処理を指す。また、コマンド生成処理とは、印刷ジョブを印刷装置２５０が解釈可能な印刷データへ変換する処理を指す。フィルター２０６による印刷ジョブを印刷データに変換する処理が完了すると、プリンタドライバ２０５はプリントサブシステム２０２内のＵＳＢポートモニター２０７に印刷データを渡す。その後、ＵＳＢポートモニター２０７は、ＵＳＢデバイスインタフェース２０８、ＵＳＢクラスドライバー２０９を介して、印刷データを印刷装置２５０に転送する。
【００１７】
次に、図２を用いて、ＰＣ２００内のアプリケーション２１０が、印刷ジョブを用いず、印刷装置２５０に情報を書き込む（送信する）又は印刷装置２５０から情報を読み出すデータの動きを説明する。なお、本実施形態に係るＰＣ２００では、１または複数のアプリケーション２１０が動作可能であるとする。アプリケーション２１０は、ＯＳの提供するＡＰＩ（Ｂｉｄｉインタフェース）を利用し、印刷装置２５０にアクセスする。Ｂｉｄｉインタフェースは、ＯＳとアプリケーション２１０とが、ＢｉｄｉスキーマというＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）で構成された設定情報を介して、双方向通信するためのインタフェースである。ＯＳ内のＵＳＢポートモニター２０７は、アプリケーション２１０からＢｉｄｉインタフェースを介してＢｉｄｉスキーマを受領する。そして、ＵＳＢポートモニター２０７は、Ｂｉｄｉ拡張スキーマ定義ファイル２１２に従い、プリンタドライバ２０５のＢｉｄｉ拡張ＪＳ２１１の関数を特定し、その特定した関数を呼び出す。なお、Ｂｉｄｉ拡張ＪＳは、Ｂｉｄｉ拡張ＪａｖａＳｃｒｉｐｔの略称である。
【００１８】
アプリケーション２１０は、ＢｉｄｉスキーマをＵＳＢポートモニター２０７に送信するためにＢｉｄｉＡＰＩに対して対象となる印刷装置２５０の識別情報を指定する。これにより、ＵＳＢポートモニター２０７は、指定された識別情報に対応する印刷装置２５０のプリンタドライバ２０５のＢｉｄｉ拡張スキーマ定義ファイル２１２を用いて処理を進めることが可能となる。ＵＳＢポートモニター２０７が、アプリケーション２１０から受領したＢｉｄｉスキーマを、Ｂｉｄｉ拡張ＪＳ２１１の関数を呼び出す際にＢｉｄｉ拡張ＪＳ２１１に渡す。この際、ＵＳＢポートモニター２０７は、オブジェクトもＢｉｄｉ拡張ＪＳ２１１に渡す。
【００１９】
Ｂｉｄｉ拡張ＪＳ２１１は、呼び出された関数、Ｂｉｄｉスキーマ、オブジェクトに基づいて、指定された印刷装置２５０に対する情報の書込み、読出し処理の指示をＵＳＢポートモニター２０７にフィードバックする。ＵＳＢポートモニター２０７は、Ｂｉｄｉ拡張ＪＳ２１１にＢｉｄｉ拡張スキーマ定義ファイル２１２の解釈を依頼することにより、ベンダーユニークなＢｉｄｉスキーマ仕様に対応することができる。ＵＳＢポートモニター２０７は、Ｂｉｄｉ拡張ＪＳ２１１からフィードバックされた指示に従った処理を実行する。具体的には、ＵＳＢポートモニター２０７は、Ｂｉｄｉ拡張ＪＳ２１１からフィードバックされた指示に従ってＵＳＢデバイスインタフェース２０８、ＵＳＢクラスドライバー２０９を介して、印刷装置２５０に対して情報の書込み、読出し処理を行う。なお、本願の特徴の１つである排他処理も、Ｂｉｄｉ拡張ＪＳ２１１からフィードバックされた指示に従ってＵＳＢポートモニター２０７により実行される。
【００２０】
図２は、新規のＯＳ上で実現される新規プリントシステムの一例である。なお、この新規ＯＳは、従来のＯＳと同様に、プリントキューに複数の印刷ジョブが存在する場合には、順番に印刷ジョブが処理されるものとする。つまり、ＦＩＦＯ（Ｆｉｒｓｔ  Ｉｎ  Ｆｉｒｓｔ  Ｏｕｔ）の処理となる。新規プリントシステムでは、いくつかの制約がある。例えば、ｖ４プリンタドライバは、印刷設定画面を持つことを許可されていない。ゆえにｖ４プリンタドライバの印刷設定画面はＯＳから呼びだされることは無い。そのため、印刷設定画面はＯＳにより提供される。
【００２１】
また、ユーザーが、ＯＳにより提供される印刷設定画面よりも詳細な印刷設定情報を設定する場合、ＯＳの印刷設定画面において詳細設定を指示する。この指示を受けると、選択されたｖ４プリンタドライバに対応する印刷設定アプリケーションが備える印刷設定画面が表示される。なお、印刷設定アプリケーションの印刷設定画面は、ＯＳにより提供される印刷設定画面よりも詳細な印刷設定情報を選択可能である。例えば、印刷設定アプリケーションの印刷設定画面は、ＯＳにより提供される印刷設定画面では設定できない設定項目についても印刷設定情報の設定を受け付ける。また、印刷設定アプリケーションは、ｖ４プリンタドライバのダウンロードに連動して情報処理装置にダウンロードされる。そして、ｖ４プリンタドライバと印刷設定アプリケーションは、識別情報により関連づけられることで、上述した印刷設定画面の表示処理が可能となる。なお、印刷設定アプリケーションは、アプリケーション２１０として動作しても構わない。
【００２２】
その他の制限としては、新規ＯＳ上で実現される新規プリントシステムでは、ランゲージモニターの動作が許可されていない。つまり、ＯＳは、ｖ４プリンタドライバの印刷設定画面を呼び出すことはせず、かつ、プリンタドライバと関連する印刷アプリケーションが印刷設定画面を呼び出す。また、ＯＳは、ランゲージモニターを呼び出さない。
【００２３】
［アプリケーションによる処理］
図３（ａ）は、管理アプリケーションのメディアリスト編集処理を示すフローチャートである。管理アプリケーションは、図２で示すアプリケーション２１０のひとつに該当し、印刷装置２５０がサポートする印刷媒体（メディア）の情報を管理するアプリケーションである。また、管理アプリケーションは、情報処理装置１００のＣＰＵ１０３が外部記憶装置１０６等に格納されたプログラムを読み出して実行することにより実現される。
【００２４】
なお、本実施形態において、情報処理装置１００にインストールされている全てのアプリケーションは、印刷装置と通信する場合、後述する制御ジョブを作成するものとする。その結果、アプリケーションは、制御ジョブを作成することなく印刷装置と通信することはできない。
【００２５】
管理アプリケーションのＵＩにてメディアリスト編集指示（ユーザー指示）が入力されることで図３（ａ）の処理が開始される。メディアリスト編集処理が開始されると、Ｓ３０１にて、管理アプリケーションは、印刷装置２５０との通信を占有することを目的とした通信占有用制御ジョブ（以降、制御ジョブ）を作成する。なお、本実施形態では、制御ジョブと区別するために、印刷装置に対して印刷処理を要求するジョブを印刷ジョブと称する。また、プリントキュー２０４に投入される制御ジョブおよび印刷ジョブをまとめてジョブと称する。
【００２６】
図９は、プリントキュー２０４のＧＵＩ（Ｇｒａｐｈｉｃａｌ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）９００の構成例を示す。制御ジョブには、印刷装置２５０との通信を占有することを目的としたジョブであることを示す情報９０１、ジョブを作成したアプリケーションが「自身が作成したジョブである」ことを一意に識別するための情報９０２が目印として付加される。情報９０２は、言い換えると、アプリケーションが制御ジョブの生成元を識別するための情報である。例えば、これらの情報をジョブ名に付加し、制御ジョブであることを示す“Ｃｏｎｔｒｏｌ＿”と、ジョブを一意に特定するためのＧＵＩＤ（Ｇｌｏｂａｌｌｙ  Ｕｎｉｑｕｅ  Ｉｄｅｎｔｉｆｉｅｒ）を組み合わせた文字列をジョブ名とする方法が考えられる。ステータス９０３は、ジョブの処理状況を示す情報である。ステータス９０３としては、“印刷中”や“スプール待ち”などが挙げられる。
【００２７】
Ｓ３０２にて、管理アプリケーションは、作成した制御ジョブをスプーラ２０３に投入する。プリントキュー２０４に先行するジョブが存在する場合は、先行するジョブの処理が完了するまでＳ３０２で投入された制御ジョブはプリントキュー２０４に保持される。つまり、上述したように、キューの処理待ち状態となる。
【００２８】
Ｓ３０３にて、管理アプリケーションは、ジョブ名に付与された、先述の制御ジョブか否かを識別するための情報９０１と、ジョブを一意に特定するための情報９０２とに基づき、自身がプリントキュー２０４の投入した制御ジョブを監視対象として特定する。そして、管理アプリケーションは、その特定した監視対象の制御ジョブのステータスを監視する。
【００２９】
Ｓ３０４にて、管理アプリケーションは、自身が投入した制御ジョブのステータス９０３が“印刷中”であるか否かを判定する。ステータスが“印刷中”である場合（Ｓ３０４にてＹＥＳ）、Ｓ３０５へ進む。ステータスが“印刷中”でない場合（Ｓ３０４にてＮＯ）、管理アプリケーションは、Ｓ３０３へ戻り、制御ジョブのステータスの監視を継続する。なお、監視については、予め定義された時間間隔にてステータスの監視を行うようにしてもよい。ジョブの種類を問わず、プリントキュー２０４に先行するジョブが存在する場合には、管理アプリケーションが投入した制御ジョブのステータスが“印刷中”とならないため、Ｓ３０４ではＮｏと判定される。一方、先行するジョブがない場合、もしくは先行するジョブの処理が完了した場合には、Ｓ３０４ではＹｅｓと判定される。
【００３０】
なお、管理アプリケーションは、ＵＳＢポートモニター２０７およびＢｉｄｉ拡張ＪＳ２１１を使用して印刷装置２５０と通信を行う。ＰＣに備えられた他のアプリケーションも制御ジョブを使用して同様の判定を行うことにより、ＵＳＢポートモニター２０７およびＢｉｄｉ拡張ＪＳ２１１を使用した印刷装置２５０との通信を行うアプリケーションを一つに限定することができる。その結果、本願が想定する課題である他のアプリケーションからの割り込み等を防止できる。また、プリントキュー２０４に複数のジョブが存在する場合、処理されるジョブは先頭の一つのみであることから、制御ジョブが処理されている間は、ジョブの種類を問わず、後発のジョブの割り込みを防止できる。
【００３１】
なお、異なるプロセスで動作する複数のソフトウェア間の処理を排他する方法として、一般的にセマフォなどの手法が用いられることがある。しかし、Ｂｉｄｉ拡張ＪＳはプロセス間通信を行うことができないため、こうした手法を用いて処理を排他することはできない。
【００３２】
Ｓ３０５にて、管理アプリケーションは、制御ジョブが処理されることにより実現されている通信占有中に、メディアリスト取得処理を実行する。具体的には、管理アプリケーションは、メディアリスト取得処理を実行することで、印刷装置２５０からメディアリストを取得する。
【００３３】
Ｓ３０６にて、管理アプリケーションは、Ｓ３０５で得たメディアリストを情報処理装置１００の表示部１０７上に表示する。ユーザーは、その表示された情報を参照し、メディアリストの編集作業を行う。
【００３４】
Ｓ３０７にて、管理アプリケーションは、ユーザーによるメディアリスト編集が完了するまで待機する。
【００３５】
Ｓ３０８にて、管理アプリケーションは、ユーザーから編集作業が完了した旨の指示を受け付けたか否かを判定する。ユーザーから編集作業が完了した旨の指示を受け付けた場合（Ｓ３０８にてＹＥＳ）、Ｓ３０９へ進み、編集作業が完了した旨を受け付けていない場合は、Ｓ３０７へ戻り、完了するまで待機する。
【００３６】
Ｓ３０９にて、管理アプリケーションは、編集されたメディアリストを印刷装置２５０へ書込む処理を実行する。
【００３７】
Ｓ３１０にて、管理アプリケーションは、制御ジョブを識別するための情報９０１と、ジョブを一意に特定するための情報９０２に基づき、自身がＳ３０２にて投入したプリントキュー２０４上の制御ジョブを特定し、削除する。そして、本処理フローを終了する。
【００３８】
なお、具体的な処理は図７を用いて後述するが、Ｓ３１０の処理によりＵＳＢポートモニター２０７およびＢｉｄｉ拡張ＪＳ２１１に対する管理アプリケーションの通信占有が解除される。
【００３９】
図３（ｂ）は、監視アプリケーションが印刷装置２５０の状態情報を取得する処理を示すフローチャートである。監視アプリケーションは、図２で示すアプリケーション２１０の一つに該当し、印刷装置２５０の状態情報を定期的に取得して、その状態を情報処理装置１００の表示部１０７上に表示する。また、監視アプリケーションは、情報処理装置１００のＣＰＵ１０３が外部記憶装置１０６等に格納されたプログラムを読み出して実行することにより実現される。
【００４０】
印刷装置２５０の情報を取得する処理が開始されると、Ｓ３３１にて、監視アプリケーションは、制御ジョブを作成する。この制御ジョブが、図３（ａ）と同様に、ＵＳＢポートモニター２０７およびＢｉｄｉ拡張ＪＳ２１１を使用して印刷装置２５０と通信を行う他のアプリケーション、プリンタドライバによる処理の割り込みを防止するために用いられる。
【００４１】
Ｓ３３２にて、監視アプリケーションは、作成した制御ジョブを、スプーラ２０３に投入する。プリントキュー２０４に先行するジョブが存在する場合は、先行するジョブの処理が完了するまでＳ３３２で投入された制御ジョブはプリントキュー２０４に保持される。つまり、図３（ａ）と同様に、キューの処理待ち状態となる。
【００４２】
Ｓ３３３にて、監視アプリケーションは、ジョブ名に付与された、制御ジョブを識別するための情報９０１と、ジョブを一意に特定するための情報９０２に基づき、スプーラ２０３上の制御ジョブのステータスを監視する。
【００４３】
Ｓ３３４にて、監視アプリケーションは、制御ジョブのステータスが“印刷中”であるか否かを判定する。制御ジョブのステータスが“印刷中”でない場合には（Ｓ３３４にてＮＯ）、Ｓ３３３へ戻り、継続して制御ジョブのステータスを監視する。一方、制御ジョブのステータスが“印刷中”の場合には（Ｓ３３４にてＹＥＳ）、Ｓ３３５へ進む。
【００４４】
Ｓ３３５にて、監視アプリケーションは、印刷装置２５０の状態情報を取得する処理を実行する。このとき、監視アプリケーションにより、印刷装置２５０との通信は占有されていることとなる。取得処理が完了した後、Ｓ３３６の処理へ進む。
【００４５】
Ｓ３３６にて、監視アプリケーションは、Ｓ３３２にて自ら投入した制御ジョブを削除する。そして、本処理フローを終了する。
【００４６】
なお、本実施形態では、管理アプリケーションと監視アプリケーションを用いて説明を続けるが、前述した印刷設定アプリケーションなど、印刷装置との通信を必要とするその他のアプリケーションであっても良い。
【００４７】
［Ｂｉｄｉ拡張スキーマ定義ファイル］
ここで図５を用いて、ベンダーユニークなスキーマ仕様を記したＢｉｄｉ拡張スキーマ定義ファイル２１２の詳細について説明する。Ｂｉｄｉ拡張スキーマ定義ファイル２１２は、図５で示すように、ＸＭＬで記述される。図５で示すＢｉｄｉ拡張スキーマ定義ファイル２１２には、ＳｅｎｄＰｒｉｎｔＤａｔａ、ＳｅｔＤａｔａ、ＧｅｔＤａｔａ、というスキーマがＶａｌｕｅｎａｍｅとして定義されている様子を示す。
【００４８】
ＳｅｎｄＰｒｉｎｔＤａｔａスキーマは、Ｖａｌｕｅ  ｔｙｐｅがＢＩＤＩ＿ＳＴＲＩＮＧ型、ａｃｃｅｓｓＴｙｐｅが“Ｓｅｔ”、スキーマパスが“￥￥Ｐｒｉｎｔｅｒ￥Ｅｘｔｅｎｓｉｏｎ：ＳｅｎｄＰｒｉｎｔＤａｔａ”として定義されている。ＳｅｎｄＰｒｉｎｔＤａｔａは、印刷データを印刷装置２５０に書き込むときに利用されるスキーマである。このＳｅｎｄＰｒｉｎｔＤａｔａスキーマが、印刷処理のためにＢｉｄｉインタフェースに指定される。ＳｅｎｄＰｒｉｎｔＤａｔａスキーマを用いて、スプーラ２０３に投入された印刷ジョブに基づいて生成された印刷データを印刷装置２５０に書き込むことができる。
【００４９】
ＳｅｔＤａｔａスキーマは、Ｖａｌｕｅ  ｔｙｐｅがＢＩＤＩ＿ＳＴＲＩＮＧ型、ａｃｃｅｓｓＴｙｐｅが“Ｓｅｔ”、スキーマパスが“￥￥Ｐｒｉｎｔｅｒ￥Ｅｘｔｅｎｓｉｏｎ：ＳｅｔＤａｔａ”として定義されている。ＳｅｔＤａｔａは、メディアリスト取得処理（Ｓ３０５）、メディアリスト書込み処理（Ｓ３０９）、印刷装置２５０の状態情報取得処理（Ｓ３３５）において、要求情報を印刷装置２５０に書き込む際に利用されるスキーマである。このＳｅｔＤａｔａスキーマが、上記処理のためにＢｉｄｉインタフェースに指定される。ＳｅｔＤａｔａスキーマを用いて、図６に示すようなメディアリスト要求コマンド（図６（ａ））や、印刷装置２５０の状態情報要求コマンド（図６（ｂ））、メディア情報設定コマンド（図６（ｃ））を印刷装置２５０に書き込むことができる。
【００５０】
ＧｅｔＤａｔａスキーマは、Ｖａｌｕｅ  ｔｙｐｅがＢＩＤＩ＿ＳＴＲＩＮＧ型、ａｃｃｅｓｓＴｙｐｅが“Ｇｅｔ”、スキーマパスが“￥￥Ｐｒｉｎｔｅｒ￥Ｅｘｔｅｎｓｉｏｎ：ＧｅｔＤａｔａ”として定義されている。ＧｅｔＤａｔａは、メディアリスト取得処理（Ｓ３０５）、メディアリスト書込み処理（Ｓ３０９）、状態情報取得処理（Ｓ３３５）において、印刷装置２５０から応答情報を取得するときに利用されるスキーマである。このＧｅｔＤａｔａスキーマが、上記処理のためにＢｉｄｉインタフェースに指定される。ＳｅｔＤａｔａスキーマにて図６（ａ）のメディアリスト要求コマンドを印刷装置２５０に書き込んだ後、ＧｅｔＤａｔａスキーマを用いることで図６（ｄ）に示すようなメディアリスト応答情報を印刷装置２５０から取得することができる。
【００５１】
なお、ここでは本実施形態の説明に必要なスキーマしか記載していないが、例えば印刷装置の能力情報取得用スキーマ等、その他の機能に応じて定義しておく必要があることはいうまでもない。つまり、上記のスキーマに限定するものではなく、他のスキーマを定義しておいてもよい。
【００５２】
［Ｂｉｄｉ拡張ＪＳによる処理］
図４（ａ）は、Ｂｉｄｉインタフェースによってスキーマを受領したＵＳＢポートモニター２０７により呼び出されたＢｉｄｉ拡張ＪＳ２１１のスキーマ判定処理を示すフローチャートである。ＯＳは、アプリケーション２１０（例えば、上述した、管理アプリケーションや監視アプリケーション）から受信したＢｉｄｉスキーマの内容を理解できない。そのため、ＵＳＢポートモニター２０７が、オブジェクトと、アプリケーション２１０から受領したＢｉｄｉスキーマの両者を、Ｂｉｄｉ拡張ＪＳ２１１の関数を呼び出す際にＢｉｄｉ拡張ＪＳ２１１に渡す。この処理により図４の処理が実行される。
【００５３】
スキーマ判定処理が開始されると、Ｓ４０１にて、Ｂｉｄｉ拡張ＪＳ２１１は、受領したスキーマのスキーマ名（Ｖａｌｕｅ  ｎａｍｅ）を判定する。
【００５４】
Ｓ４０２にて、Ｂｉｄｉ拡張ＪＳ２１１は、Ｓ４０１の判定により、スキーマ名が印刷データ送信（ＳｅｎｄＰｒｉｎｔＤａｔａ）か否かを判定する。印刷データ送信であった場合（Ｓ４０２にてＹＥＳ）、Ｓ４０３にて、Ｂｉｄｉ拡張ＪＳ２１１は、印刷データ送信処理を実行する。なお、Ｓ４０３の詳細な説明は図４（ｂ）に示す。
【００５５】
Ｓ４０４にて、Ｂｉｄｉ拡張ＪＳ２１１は、Ｓ４０１の判定により、スキーマ名が情報送信（ＳｅｔＤａｔａ）か否かを判定する。情報送信であった場合（Ｓ４０４にてＹＥＳ）、Ｓ４０５にて、Ｂｉｄｉ拡張ＪＳ２１１は、情報送信処理を実行する。
【００５６】
Ｓ４０６にて、Ｂｉｄｉ拡張ＪＳ２１１は、Ｓ４０１の判定により、スキーマ名が情報受信（ＧｅｔＤａｔａ）か否かを判定する。情報受信であった場合（Ｓ４０６にてＹＥＳ）、Ｓ４０７にて、Ｂｉｄｉ拡張ＪＳ２１１は、情報受信処理を実行する。
【００５７】
印刷データ送信処理（Ｓ４０３）、情報送信処理（Ｓ４０５）、および、情報受信処理（Ｓ４０７）の完了後、もしくは、スキーマ名が上記の何れでもなかった場合には、本処理フローを終了する。
【００５８】
図４（ｂ）は、Ｂｉｄｉ拡張ＪＳ２１１の印刷データ送信処理（図４（ａ）のＳ４０３）の詳細を示すフローチャートである。なお、ここでは図９を用いて前述した例に基づき、制御ジョブであることを示す目印（情報９０１）はジョブ名に付与されているものとする。
【００５９】
印刷データ送信処理が開始されると、Ｓ４１１にて、Ｂｉｄｉ拡張ＪＳ２１１は、処理対象の印刷ジョブの名称を確認する。
【００６０】
Ｓ４１２にて、Ｂｉｄｉ拡張ＪＳ２１１は、処理対象のジョブが制御ジョブであるか否かを判定する。制御ジョブである場合（Ｓ４１２にてＹＥＳ）、Ｓ４１３へ進み、制御ジョブでない場合（Ｓ４１２にてＮＯ）、Ｓ４１４へ進む。
【００６１】
Ｓ４１３にて、Ｂｉｄｉ拡張ＪＳ２１１は、ＵＳＢポートモニター２０７に対して印刷データ送信処理の再試行が必要なことを示す印刷データ送信リトライ応答を返却する。Ｂｉｄｉ拡張ＪＳ２１１が、Ｓ４１３の処理を実行することで、制御ジョブがプリントキューから削除されるまで、“印刷中”のステータスとして維持されることとなる。そして、本処理フローを終了する。
【００６２】
Ｓ４１４にて、Ｂｉｄｉ拡張ＪＳ２１１は、ＵＳＢポートモニター２０７に対して印刷データの書込み指示と、印刷データ送信成功応答を返却する。そして、本処理フローを終了する。印刷データ送信リトライ応答が返却されている間は、処理対象のジョブはプリントキュー２０４に残り続け、図４（ａ）の処理が実行される。
【００６３】
図４の処理により、制御ジョブを投入したアプリケーションがその制御ジョブを削除するまで、プリントキュー２０４上に制御ジョブが残り続けるため、後続のジョブが処理されることはない。これは、プリントキュー２０４に複数のジョブが存在する場合、順番にジョブが処理されるという従来のＯＳの仕組みを利用したものである。つまり、その間、Ｂｉｄｉ拡張ＪＳ２１１が、Ｂｉｄｉスキーマを送信したアプリケーション２１０に占有され、他のアプリケーションからの使用が制限される。この構成により、本願発明は、上述した課題を解決することが可能となる。
【００６４】
［処理シーケンス］
図７は、各種アプリケーションとＯＳと印刷装置の全体的な処理の流れを示すシーケンス図である。図７を用いて、アプリケーションＡがＵＳＢを占有する間に、その他のアプリケーションやスプーラがどのように挙動をするかについて説明する。
【００６５】
アプリケーションＡ７００は、例えば、図３（ａ）を用いて説明した管理アプリケーション（アプリケーション２１０の１つ）である。アプリケーションＡ７００は、印刷装置７６０との通信を占有することを目的とした制御ジョブＡを作成し、スプーラ７２０のプリントキューに投入する（７０１、Ｓ３０２）。
【００６６】
スプーラ７２０は、制御ジョブＡを受け付ける（７２１）。このとき、スプーラ７２０のプリントキューには他のジョブが投入されていないため、制御ジョブＡのステータスは、“印刷中”となる。更に、スプーラ７２０は、ＵＳＢポートモニター７３０に対して印刷データの書込みを指示する（７２２）。
【００６７】
印刷データの書込みの指示を受けたＵＳＢポートモニター７３０は、Ｂｉｄｉ拡張スキーマ定義ファイルを参照してＢｉｄｉ拡張ＪＳ７５０の関数を特定し、その特定した関数を呼び出す（７３１）。
【００６８】
Ｂｉｄｉ拡張ＪＳ７５０は、処理中のジョブが制御ジョブであることを識別し、ＵＳＢポートモニター７３０に対して、印刷データ送信リトライ応答を返却する（７５１）。つまり、図４（ｂ）に示すように、Ｂｉｄｉ拡張ＪＳ７５０は、処理要求が行われた際に、その処理中のジョブが制御ジョブか否かを判定し、制御ジョブであると判定した場合はそのステータスが“印刷中”として継続されるようにリトライ応答を繰り返す。この印刷データ送信リトライ応答が返却されている間は、プリントキュー上の制御ジョブＡは“印刷中”ステータスとして残り続け、上記の７２２、７３１、７５１の処理が繰り返される。その間に他のアプリケーションやプリンタドライバが、プリントキューに制御ジョブもしくは印刷ジョブを投入しても、そうした後発のジョブは処理されない。つまり、プリントキューの先頭にあるジョブを発行したアプリケーションのみがプリンタとの通信が許可されるため、結果として、図７の例では、アプリケーションＡ７００は、印刷装置７６０との通信を占有することができる。
【００６９】
アプリケーションＡ７００は、プリントキュー上の制御ジョブＡのステータスを監視する（７０２）。ここでの監視は、予め定義された時間間隔にて定期的に行われるようにしてよい。そして、ステータスが“印刷中”となったことを受けて、アプリケーションＡ７００は、Ｂｉｄｉスキーマを利用してＵＳＢポートモニター７３０に対してＷｒｉｔｅ／Ｒｅａｄ処理を指示する（７０３）。
【００７０】
Ｗｒｉｔｅ／Ｒｅａｄ処理の指示を受けたＵＳＢポートモニター７３０は、Ｂｉｄｉ拡張スキーマ定義ファイルを参照してＢｉｄｉ拡張ＪＳ７５０の関数を特定し、その特定した関数を呼び出す（７３２）。
【００７１】
Ｂｉｄｉ拡張ＪＳ７５０は、ＵＳＢポートモニター７３０に対してＧｅｔＤａｔａ／ＲｅａｄＤａｔａスキーマに応じた処理を指示する（７５２）。
【００７２】
ＵＳＢポートモニター７３０は、Ｂｉｄｉ拡張ＪＳ７５０からの指示を受けて印刷装置７６０へのＷｒｉｔｅ／Ｒｅａｄ処理を要求する（７３３）。
【００７３】
印刷装置７６０は、ＵＳＢポートモニター７３０からの、Ｗｒｉｔｅ／Ｒｅａｄ処理（７３３）の要求を受けて、要求に対するデータを応答する（７６１）。ここでＵＳＢポートモニター７３０の要求が、図６（ａ）に示すメディアリスト取得要求である場合、印刷装置７６０が応答するデータは、図６（ｄ）に示すメディアリスト応答情報である。印刷装置７６０が応答したデータは、ＵＳＢポートモニター７３０及びＢｉｄｉ拡張ＪＳ７５０を経由して、アプリケーションＡ７００に渡る。なお、アプリケーションＡ７００は、ＵＳＢポートの利用を占有している状態にあるため、Ｗｒｉｔｅ／Ｒｅａｄ処理（７０３、Ｓ３０５、Ｓ３３５）を複数回繰り返すことが可能である。
【００７４】
アプリケーションＡ７００は、Ｂｉｄｉインタフェースの利用が終わると、自身がスプーラ７２０のプリントキューに投入した制御ジョブＡを削除する（７０４）。プリントキュー上の制御ジョブＡが削除されることによって、アプリケーションＡ７００によるＵＳＢポート占有期間７２３が終了する。
【００７５】
続いて、アプリケーションＡ７００が印刷装置７６０と通信処理を行っている間に、他のアプリケーションＢ７１０が印刷装置７６０との通信を試みた場合の処理について説明する。アプリケーションＢ７１０は、例えば、図３（ｂ）を用いて説明した監視アプリケーション（アプリケーション２１０の１つ）である。アプリケーションＢ７１０は、印刷装置７６０との通信を占有することを目的とした制御ジョブＢを作成し、スプーラ７２０のプリントキューに投入する（７１１）。
【００７６】
スプーラ７２０は、制御ジョブＢを受け付ける（７２４）。なお、スプーラ７２０は先にアプリケーションＡ７００が投入した制御ジョブＡを処理しているため、この時点での制御ジョブＢのステータスは“スプール待ち”となる。アプリケーションＢ７１０は、制御ジョブＢのステータスを監視する（７１２）。ここで、制御ジョブＡの処理が完了するまでの間、制御ジョブＢのステータスは“印刷中”とならないため、アプリケーションＢ７１０は、ステータス監視を継続する。アプリケーションＡ７００が制御ジョブＡを削除したことを受け（７０４）、スプーラ７２０は、制御ジョブＢの処理を開始する。つまり、制御ジョブＢのステータスが“印刷中”となる。スプーラ７２０は、制御ジョブＢについて、ＵＳＢポートモニター７３０に対して印刷データの書込みを指示する（７２５）。
【００７７】
印刷データの書き込みの指示を受けたＵＳＢポートモニター７３０は、Ｂｉｄｉ拡張スキーマ定義ファイルを参照してＢｉｄｉ拡張ＪＳ７５０の関数を特定し、その特定した関数を呼び出す（７３４）。
【００７８】
Ｂｉｄｉ拡張ＪＳ７５０は、処理中のジョブが制御ジョブであることを識別し、ＵＳＢポートモニター７３０に対して、印刷データ送信リトライ応答を返却する（７５３）。この印刷データ送信リトライ応答が返却されている間は、スプーラ７２０のプリントキュー上の制御ジョブＢは“印刷中”ステータスとして残り続け、上記の７２５、７３４、７５３の処理が繰り返される。その間にプリントキューに他のアプリケーションやプリンタドライバがプリントキューに制御ジョブ、または印刷ジョブを投入しても、そうした後発の印刷ジョブは処理されない。その結果、アプリケーションＢ７１０は、印刷装置７６０との通信を占有することができる。
【００７９】
アプリケーションＢ７１０は、プリントキュー上の制御ジョブＢのステータスを監視する（７１３）。そして、制御ジョブＢのステータスが“印刷中”となったことを受けて、アプリケーションＢ７１０は、Ｂｉｄｉスキーマを利用してＵＳＢポートモニター７３０に対してＷｒｉｔｅ／Ｒｅａｄ処理を指示する（７１４）。
【００８０】
Ｗｒｉｔｅ／Ｒｅａｄ処理の指示を受けたＵＳＢポートモニター７３０は、Ｂｉｄｉ拡張スキーマ定義ファイルを参照してＢｉｄｉ拡張ＪＳ７５０の関数を特定し、その特定した関数を呼び出す（７３５）。
【００８１】
Ｂｉｄｉ拡張ＪＳ７５０は、ＵＳＢポートモニター７３０に対してＧｅｔＤａｔａ／ＲｅａｄＤａｔａスキーマに応じた処理を指示する（７５４）。
【００８２】
ＵＳＢポートモニター７３０は、Ｂｉｄｉ拡張ＪＳ７５０からの指示を受けて印刷装置７６０へのＷｒｉｔｅ／Ｒｅａｄ処理を要求する（７３６）。
【００８３】
印刷装置７６０は、ＵＳＢポートモニター７３０からの、Ｗｒｉｔｅ／Ｒｅａｄ処理の要求を受けて（７３６）、要求に対するデータを応答する（７６２）。ここでＵＳＢポートモニター７３０の要求が、図６（ｂ）に示す印刷装置２５０の状態情報取得要求である場合、応答するデータは、印刷装置２５０の状態に関する情報である。印刷装置７６０が応答したデータは、ＵＳＢポートモニター７３０及びＢｉｄｉ拡張ＪＳ７５０を経由して、アプリケーションＢ７１０に渡る。なお、アプリケーションＢ７１０は、ＵＳＢポートの利用を占有している状態にあるため、Ｗｒｉｔｅ／Ｒｅａｄ処理（７１４、Ｓ３０５、Ｓ３３５）を複数回繰り返すことが可能である。
【００８４】
アプリケーションＢ７１０は、Ｂｉｄｉインタフェースの利用が終わると、自身がスプーラ７２０のプリントキューに投入した制御ジョブＢを削除する（７１５）。プリントキュー上の制御ジョブＢが削除されることによって、アプリケーションＢ７１０によるＵＳＢポート占有期間７２６が終了する。
【００８５】
以上示した通り、各アプリケーションは印刷装置との通信を占有することを目的とした制御ジョブを作成し、スプーラのプリントキューに投入することにより、他のアプリケーションからの割り込み処理を制限することが可能となる。また、制御ジョブＡの削除処理（図７の７０４）により、アプリケーションＢ７１０がスプーラのプリントキューに投入した制御ジョブＢの処理が開始される。ここでは、プリンタドライバ以外のソフトウェアであるアプリケーションを例にとり、複数のアプリケーションと印刷装置との排他処理を説明した。しかし、スプーラのプリントキュー上のジョブが順次処理されるＯＳの仕組みを利用することから、プリンタドライバがプリントキューに投入する印刷ジョブとの間の排他も可能となる。
【００８６】
なお、アプリケーションＡ７００が制御ジョブＡの削除処理（７０４）を行わないまま、終了してしまうケースも考えられる。このような場合に対し、例えば、アプリケーションがプリントキューに投入する制御ジョブのジョブ名にジョブの生存期間を示す情報を付加しておく。そして、Ｂｉｄｉ拡張ＪＳ７５０は、処理中の制御ジョブがプリントキューに投入された時間、ジョブ名に付加された生存期間の情報、現在の時間から、ＵＳＢポートモニター７３０に対して印刷データ送信リトライ応答を返却するか否かを判定してもよい。その判定の結果、ジョブ名に付加された生存期間を超えてなおジョブが生存している場合には、ＵＳＢポートモニター７３０に対して印刷データ送信成功応答を指示することで、プリントキューから対象の制御ジョブが削除される。
【００８７】
なお、本願では、情報処理装置と通信可能な装置として印刷装置を記載したが、デジタルカメラやスキャナ等の他の周辺装置であってもよい。
【００８８】
＜第二の実施形態＞
第一の実施形態は、アプリケーションが制御ジョブを利用することにより、他のアプリケーションから割り込まれることを防止し、その間にＢｉｄｉインタフェースを利用してＷｒｉｔｅ／Ｒｅａｄ処理を要求する形態を示した。本実施形態では、アプリケーションが制御ジョブを利用することにより、他のアプリケーションから割り込まれることを防止し、その間にＵＳＢデバイスインタフェース２０８に対し直接、Ｗｒｉｔｅ／Ｒｅａｄ処理を要求する形態について説明する。
【００８９】
図８は、本実施形態に係るアプリケーション、ＯＳ、および印刷装置の全体的な流れを示すシーケンス図である。図８を用いて、アプリケーションがＵＳＢを占有する間に、アプリケーションがＵＳＢデバイスインタフェースを直接利用する流れを説明する。アプリケーション８００は、例えば、図３（ａ）を用いて説明した管理アプリケーション（アプリケーション２１０の１つ）である。
【００９０】
アプリケーション８００は、印刷装置８５０との通信を占有することを目的とした制御ジョブを作成し、スプーラ８１０のプリントキューに投入する（８０１）。スプーラ８１０は、制御ジョブを受け付ける（８１１）。このとき、スプーラ８１０のプリントキューには他のジョブが投入されていないため、制御ジョブのステータスは、“印刷中”となる。スプーラ８１０は、ＵＳＢポートモニター８２０に対して印刷データの書込みを指示する（８１２）。印刷データの書き込みの指示を受けたＵＳＢポートモニター８２０は、Ｂｉｄｉ拡張スキーマ定義ファイルを参照してＢｉｄｉ拡張ＪＳ８３０の関数を特定し、その特定した関数を呼び出す（８２２）。
【００９１】
Ｂｉｄｉ拡張ＪＳ８３０は、処理中のジョブが制御ジョブであることを識別し、ＵＳＢポートモニター８２０に対して、印刷データ送信リトライ応答を返却する（８３１）。この印刷データ送信リトライ応答が返却されている間は、スプーラ８１０のプリントキュー上の制御ジョブは“印刷中”ステータスとして残り続け、上記の８１２、８２２、８３１の処理が繰り返される。その間に他のアプリケーションやプリンタドライバがスプーラ８１０のプリントキューに印刷ジョブを投入しても、そうした後発の印刷ジョブは処理されないため、アプリケーション８００は、印刷装置８５０との通信を占有することができる。
【００９２】
アプリケーション８００は、スプーラ８１０のプリントキュー上の制御ジョブのステータスを監視する（８０２）。ここでの監視は、予め定義された時間間隔にて定期的に行われるようにしてよい。そして、ステータスが“印刷中”となったことを受けて、アプリケーション８００は、Ｗｒｉｔｅ／Ｒｅａｄ処理を要求する（８０３）。ここでのＷｒｉｔｅ／Ｒｅａｄ処理は、ＵＳＢデバイスインタフェース８４０をＯｐｅｎし、データを直接Ｗｒｉｔｅ／Ｒｅａｄする処理である。
【００９３】
ＵＳＢデバイスインタフェース８４０は、アプリケーション８００から処理の要求を受けて（８４１）、印刷装置８５０に対し、Ｗｒｉｔｅ／Ｒｅａｄ処理を要求する（８４２）。
【００９４】
印刷装置８５０は、ＵＳＢデバイスインタフェース８４０からの、Ｗｒｉｔｅ／Ｒｅａｄ処理の要求を受けて（８４２）、要求に対するデータを応答する（８５１）。ここでＵＳＢデバイスインタフェース８４０の要求が、図６（ａ）に示すメディアリスト取得要求である場合、印刷装置８５０が応答するデータは、図６（ｄ）に示すメディアリスト応答情報である。印刷装置８５０が応答するデータは、ＵＳＢデバイスインタフェース８４０を経由して、アプリケーション８００に渡る。なお、アプリケーション２１０は、ＵＳＢポートの利用を占有している状態にあるため、Ｗｒｉｔｅ／Ｒｅａｄ処理を複数回繰り返すことが可能である。
【００９５】
アプリケーション８００は、Ｂｉｄｉインタフェースの利用が終わると、自身がスプーラ８１０のプリントキューに投入した制御ジョブを削除する（８０４）。プリントキュー上の制御ジョブが削除されることによって、アプリケーション８００によるＵＳＢポート占有期間（８１３）が終了する。
【００９６】
以上示した通り、アプリケーション８００は印刷装置８５０との通信を占有することを目的とした制御ジョブを作成し、プリントキューに投入することにより、他のアプリケーションからの割り込み処理を制限することが可能となる。また、制御ジョブ削除処理により、プリントキュー上の後続の印刷ジョブの処理が開始される。
【００９７】
＜その他の実施形態＞
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピューターにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【符号の説明】
【００９８】
２００…ＰＣ、２０１…印刷アプリケーション、２１０…アプリケーション、２０２…プリントサブシステム、２０３…スプーラ、２０４…プリントキュー、２０５…プリンタドライバ、２０６…フィルター、２０７…ＵＳＢポートモニター、２０８…ＵＳＢデバイスインタフェース、２０９…ＵＳＢクラスドライバー、２１１…Ｂｉｄｉ拡張ＪａｖａＳｃｒｉｐｔ、２１２…Ｂｉｄｉ拡張スキーマ、２５０…印刷装置
【図１】
0006723025.tif 000002
【図２】
0006723025.tif 000003
【図３】
0006723025.tif 000004
【図４】
0006723025.tif 000005
【図５】
0006723025.tif 000006
【図６】
0006723025.tif 000007
【図７】
0006723025.tif 000008
【図８】
0006723025.tif 000009
【図９】
0006723025.tif 000010