JP6468937B2 - 情報処理装置、制御方法、制御プログラム - Google Patents

Description

本発明は、情報処理装置と周辺装置との間で各種情報を送受信するための情報処理装置、制御方法、制御プログラムに関する。

従来のプリンタドライバ（ｖ３プリンタドライバ）アーキテクチャーにおいて、ランゲージモニターという双方向制御モジュールをベンダーが提供することが可能であった。ランゲージモニターは印刷ジョブの送受信を制御すること、また、各種アプリケーションから印刷装置への情報書込み及び取得要求を制御することも可能であった。情報書込み及び取得要求には、Ｂｉｄｉｒｅｃｔｉｏｎａｌ（Ｂｉｄｉ）スキーマによるランゲージモニターとアプリケーションとのプロセス間通信技術を用いることも可能であった。ｖ３プリンタドライバアーキテクチャーにおけるＢｉｄｉスキーマを用いたプロセス間通信は、ランゲージモニターが処理するため、ベンダーの自由な情報送受信制御が可能であった。

近年、次世代のプリンタドライバ（ｖ４プリンタドライバ）アーキテクチャーによる、Ｂｉｄｉｒｅｃｔｉｏｎａｌ（Ｂｉｄｉ）スキーマを用いた標準的な情報送受信方法が策定された。この次世代のｖ４プリンタドライバのアーキテクチャーではランゲージモニターが存在しないため、自由な情報送受信制御を行うことが難しくなるおそれがあった。特許文献１には、Ｂｉｄｉスキーマを用いた標準的な情報送受信方法が記載されている。特に特許文献は、プリンタドライバに同梱されたＢｉｄｉ拡張ファイル、Ｂｉｄｉ拡張ＪａｖａＳｃｒｉｐｔ（登録商標）（Ｂｉｄｉ拡張ＪＳ）ファイルという外部依存ファイルをＯｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ（ＯＳ）のポートモニターが読み出すことを開示している。この外部依存ファイルにて、プリンタドライバを作成する各社プリンタベンダー毎のユニークな情報送受信仕様が実現される。

ＵＳ公開公報 ２０１３／００６７１２０

しかしながら、特許文献１では、あるソフトウェアがＢｉｄｉスキーマを用いて情報送受信処理を実行している途中で、他のソフトウェアからのＢｉｄｉスキーマを用いた情報送受信の割り込みが行われてしまうという課題について考慮されていなかった。その結果、ユーザーの意図した処理が実行されないおそれがあった。

上述のような課題を解決するため、本願の情報処理装置は、プリンタドライバが印刷設定画面を表示することを制限し、かつ、前記プリンタドライバと関連する印刷アプリケーションが印刷設定画面を表示することを許可するオペレーティングシステムを動作する情報処理装置であって、アプリケーションから占有要求を受信する受信手段と、前記占有要求に基づく占有期間において、前記占有要求を発行したアプリケーションが周辺装置から情報を取得する処理および前記周辺装置へ情報を送信する処理の少なくとも１つを実行でき、かつ、前記占有要求を発行したアプリケーションとは異なるアプリケーションが前記周辺装置から情報を取得する処理および前記周辺装置へ情報を送信する処理を実行できないように占有処理を実行する実行手段と、前記受信手段が占有終了要求を受信した場合、前記占有要求を発行したアプリケーションと前記占有終了要求を発行したアプリケーションが同一であるか否かを判定する判定手段を備え、前記占有要求を発行したアプリケーションと前記占有終了要求を発行したアプリケーションが同一であると判定された場合、前記実行手段は、前記占有処理を解除することを特徴とする。

本発明によれば、ユーザーの意図した処理を実行することが可能となる。

印刷装置と情報処理装置の構成図 プリンタドライバとＯＳのプリントサブシステムの構成を示すブロック図 アプリケーションの情報取得処理を示すフローチャート Ｂｉｄｉ拡張ＪＳの処理を示すフローチャート Ｂｉｄｉ拡張スキーマ定義ファイルを示す図 各種コマンドを示す図 全体的な処理の流れを示すシーケンス図 全体的な処理の流れを示すシーケンス図

以下、添付図面を参照して本発明の好適な実施の形態を詳しく説明する。尚、以下の実施の形態は特許請求の範囲に係る本発明を限定するものでなく、また本実施の形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。

＜実施形態１＞
本実施形態における印刷装置と情報処理装置の構成を、図１を参照して説明する。

情報処理装置１００は入力インタフェース１０２とＣＰＵ１０３、ＲＯＭ１０４、ＲＡＭ１０５、外部記憶装置１０６、出力インタフェース１０８、表示部１０７、キーボード１０１、マウス１０９、ＵＳＢインタフェース１１０を有する。情報処理装置１００は、ＵＳＢインタフェース１１０およびＵＳＢケーブル１９０を介して後述する印刷装置１５０と通信可能である。ＲＯＭ１０４には初期化プログラムが入っており、外部記憶装置１０６にはアプリケーションプログラム群、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）、プリンタドライバやその他各種のデータが保存されている。ＲＡＭ１０５は外部記憶装置１０６に格納される各種プログラムがワークメモリとして使用する。印刷装置１５０はＵＳＢインタフェース１５１とＲＡＭ１５２、プリントエンジン１５３、ＲＯＭ１５４、ＣＰＵ１５５を有する。印刷装置１５０は、ＵＳＢインタフェース１５１およびＵＳＢケーブル１９０を介して情報処理装置１００と通信可能である。ＲＡＭ１５２はＣＰＵ１５５の主メモリとワークメモリとして用いられ、受信した印刷データを一旦保存するための受信バッファーや各種のデータを保存する。プリントエンジン１５３はＲＡＭ１５２に保存されたデータに基づき印刷を行う。ここでは例として情報処理装置１００と印刷装置１５０の処理分担を上記のように示したが、特にこの分担形態限らず他の形態であっても構わない。

図２は外部記憶装置１０６に記憶されたプリンタドライバとＯＳのプリントサブシステム（Ｐｒｉｎｔ Ｓｕｂ Ｓｙｓｔｅｍ）の構成を示すブロック図である。情報処理装置１００（ＰＣ２００）は、印刷装置２５０とＵＳＢケーブルを介して通信可能である。

まず、図２のブロック図を用いて、ＰＣ２００から印刷装置２５０へ印刷データが渡るまでのデータの流れを説明する。印刷アプリケーション２０１は、ＯＳの提供する印刷指示を行うＡＰＩを利用し、ＯＳへ印刷処理の要求を行う。印刷処理の要求に基づいて発行された印刷ジョブはＯＳ内のプリントサブシステム２０２のスプーラ２０３にて処理される。スプーラ２０３はアプリケーション２０１から発行された印刷ジョブをプリントキュー２０４に格納する。スプーラ２０３はＰＣ２００内の複数の印刷アプリケーション２０１からの複数の印刷ジョブをプリントキュー２０４に格納する。スプーラ２０３はプリントキュー２０４に格納した印刷ジョブを順次ｖ４プリンタドライバ２０５（以降、プリンタドライバと称す）へ送信する。ここで、印刷ジョブを印刷装置２５０が解釈可能な印刷データに変換するために、スプーラ２０３が印刷データをプリンタドライバ２０５に送信する処理をデスプール処理と称す。プリンタドライバ２０５は、印刷データを受信すると、各種フィルター２０６に依って、ページ構成処理やコマンド生成処理を行う。前述のページ構成処理とは、アプリケーション２０１から指示された印刷設定情報に基づいて一つの印刷データ内のページの順序を並べ替える処理や、複数ページを用紙の１つの面に相当する物理ページに配置するための処理を指す。前述のコマンド生成処理とは、印刷ジョブを印刷装置２５０が解釈可能な印刷データへ変換する処理を指す。各種フィルター２０６による印刷ジョブを印刷データに変換する処理が完了すると、プリンタドライバ２０５はプリントサブシステム２０２内のＵＳＢポートモニター２０７に印刷データを渡す。その後、ＵＳＢポートモニター２０７は、ＵＳＢデバイスインタフェース２０８、ＵＳＢクラスドライバー２０９を介して、印刷データを印刷装置２５０に転送する。

次に、図２のブロック図を用いて、ＰＣ２００内のアプリケーション２１０が、印刷ジョブを用いず、印刷装置２５０に情報を書き込む又は印刷装置２５０から情報を読み出すデータの動きを説明する。アプリケーション２１０は、ＯＳの提供するＡＰＩ（Ｂｉｄｉインタフェース）を利用し、印刷装置２５０にアクセスする。Ｂｉｄｉインタフェースは、ＯＳとアプリケーション２１０とが、ＢｉｄｉスキーマというＸＭＬで構成された設定情報を介して、双方向通信するためのインタフェースである。アプリケーション２１０からＢｉｄｉインタフェースを介してＢｉｄｉスキーマを受領したＯＳ内のＵＳＢポートモニター２０７は、Ｂｉｄｉ拡張スキーマ定義ファイル２１２に従い、プリンタドライバ２０５のＢｉｄｉ拡張ＪＳ２１１の関数を特定し、呼び出す。なお、Ｂｉｄｉ拡張ＪＳは、Ｂｉｄｉ拡張ＪａｖａＳｃｒｉｐｔ（登録商標）の略称である。アプリケーション２１０は、ＢｉｄｉスキーマをＵＳＢポートモニターに送信するためにＢｉｄｉＡＰＩに対して対象となる印刷装置２５０の識別情報を指定する。ＵＳＢポートモニターは、指定された識別情報に対応する印刷装置２５０のプリンタドライバ２０５のＢｉｄｉ拡張スキーマ定義ファイル２１２を用いて処理を進めることが可能となる。ＵＳＢポートモニター２０７が、アプリケーション２１０から受領したＢｉｄｉスキーマを、Ｂｉｄｉ拡張ＪＳ２１１の関数を呼び出す際にＢｉｄｉ拡張ＪＳ２１１に渡す。この際、ＵＳＢポートモニター２０７は、オブジェクトもＢｉｄｉ拡張ＪＳ２１１に渡す。Ｂｉｄｉ拡張ＪＳ２１１は、呼び出された関数、Ｂｉｄｉスキーマ、オブジェクトに基づいて、印刷装置２５０に対する情報の書込み・読出し処理の指示をＵＳＢポートモニター２０７にフィードバックする。ＵＳＢポートモニター２０７は、Ｂｉｄｉ拡張ＪＳ２１１にＢｉｄｉ拡張スキーマ定義ファイル２１２の解釈を依頼することにより、ベンダーユニークなＢｉｄｉスキーマ仕様に対応することができる。ＵＳＢポートモニター２０７は、Ｂｉｄｉ拡張ＪＳ２１１からフィードバックされた指示に従った処理を実行する。具体的には、ＵＳＢポートモニター２０７は、Ｂｉｄｉ拡張ＪＳ２１１からフィードバックされた指示に従ってＵＳＢデバイスインタフェース２０８、ＵＳＢクラスドライバー２０９を介して、印刷装置２５０に対して情報の書込み・読出し処理を行う。なお、本願の特徴の１つである排他処理も、Ｂｉｄｉ拡張ＪＳ２１１からフィードバックされた指示に従ってＵＳＢポートモニター２０７により実行される。

本願の図２は、新規オペレーティングシステム（ＯＳ）上で実現される新規プリントシステムの一例である。新規プリントシステムでは、いくつかの制約がある。例えば、ｖ４プリンタドライバは、印刷設定画面を持つことを許可されていない。ゆえにｖ４プリンタドライバの印刷設定画面はＯＳから呼びだされることは無い。そのため、印刷設定画面はＯＳにより提供される。また、ユーザーが、ＯＳにより提供される印刷設定画面よりも詳細な印刷設定情報を設定する場合、ＯＳの印刷設定画面において詳細設定を指示する。この指示を受けると、選択されたｖ４プリンタドライバに対応する印刷設定アプリケーションが備える印刷設定画面が表示される。なお、印刷設定アプリケーションの印刷設定画面は、ＯＳにより提供される印刷設定画面よりも詳細な印刷設定情報を選択可能である。例えば、印刷設定アプリケーションの印刷設定画面は、ＯＳにより提供される印刷設定画面では設定できない設定項目についても印刷設定情報の設定を受け付ける。また、印刷設定アプリケーションは、ｖ４プリンタドライバのダウンロードに連動して情報処理装置にダウンロードされる。そして、ｖ４プリンタドライバと印刷設定アプリケーションは、識別情報により関連づけられることで、上述した印刷設定画面の表示処理が可能となる。なお、アプリケーション２１０として印刷設定アプリケーションが動作しても構わない。その他の制限としては、新規オペレーティングシステム（ＯＳ）上で実現される新規プリントシステムでは、ランゲージモニターの動作が許可されていない。つまり、ＯＳは、ｖ４プリンタドライバの印刷設定画面を呼び出すことはせず、かつ、プリンタドライバと関連する印刷アプリケーションが印刷設定画面を呼び出す。また、ＯＳは、ランゲージモニターを呼び出さない。図３（ａ）は、管理アプリケーションのメディアリスト編集処理を示すフローチャートである。管理アプリケーションとは、図２で示すアプリケーション２１０のひとつに該当し、印刷装置２５０がサポートする印刷媒体（メディア）の情報を管理するアプリケーションである。なお、本願の情報処理装置において実行されるフローチャートは、ＣＰＵ１０３が、ＲＯＭ、ＲＡＭ、外部記憶装置等のメモリからフローチャートに関係するフローチャートを読み出して実行することで実現される。

管理アプリケーションは、メディアリスト編集処理を開始（Ｓ３０１）すると、Ｂｉｄｉインタフェース利用を開始する（Ｓ３０２）。管理アプリケーションはＢｉｄｉインタフェース利用開始の（Ｓ３０２）処理結果を判定（Ｓ３０３）し、失敗した場合はメディアリスト編集処理を終了（Ｓ３１０）する。判定Ｓ３０３の結果が成功だった場合、管理アプリケーションはメディアリスト取得処理（Ｓ３０４）を実行する。具体的な処理は図７で記載するが、Ｓ３０２では、管理アプリケーションがＵＳＢポートモニターおよびＢｉｄｉ拡張ＪＳ（７６０）を占有して使用することを要求し、その要求に対する回答がエラーであればＳ３０３はＮｏと判定される。一方、その要求に対する回答がエラーでなければＳ３０３はＹｅｓと判定される。その結果、管理アプリケーションが、ＵＳＢポートモニターおよびＢｉｄｉ拡張ＪＳを優先的に利用できるため、本願が想定する課題である他のアプリケーションからの割り込み等を防止できる。

管理アプリケーションは処理Ｓ３０４で得たメディアリストを情報処理装置１００の表示部１０７上に表示（Ｓ３０５）し、ユーザーはその情報を参照しメディアリストの編集作業を行う。管理アプリケーションはユーザーのメディアリスト編集完了を待ち（Ｓ３０６）、ユーザーが編集作業を完了したことを指示したか判定（Ｓ３０７）する。ユーザーが編集作業の完了を指示することで管理アプリケーションが編集完了と判断した場合、管理アプリケーションは編集されたメディアリストを印刷装置２５０へ書込む処理（Ｓ３０８）を実行する。その後、管理アプリケーションは、Ｂｉｄｉインタフェース利用終了処理（Ｓ３０９）を行い、メディアリスト編集処理を終了（Ｓ３１０）する。具体的な処理は図７で記載するが、Ｓ３０９の処理によりＵＳＢポートモニターおよびＢｉｄｉ拡張ＪＳに対する管理アプリケーションの占有期間が解除される。

図３（ｂ）は、監視アプリケーションが印刷装置２５０の状態情報を取得する処理を示すフローチャートである。監視アプリケーションとは、図２で示すアプリケーション２１０の一つに該当し、印刷装置２５０の状態情報を定期的に取得して、その状態を情報処理装置１００の表示部１０７上に表示する。

監視アプリケーションは、印刷装置２５０の情報を取得する処理（Ｓ３２１）を開始すると、Ｂｉｄｉインタフェース利用を（Ｓ３２２）する。監視アプリケーションはＢｉｄｉインタフェース利用開始（Ｓ３２２）の処理結果を判定（Ｓ３２３）し、失敗した場合は印刷装置２５０の状態情報を取得する処理を終了（Ｓ３２６）する。判定Ｓ３２３の結果が成功だった場合、監視アプリケーションは、印刷装置２５０の状態情報を取得する処理（Ｓ３２４）を実行する。その後、監視アプリケーションは、Ｂｉｄｉインタフェース利用終了処理（Ｓ３２５）を行い、印刷装置２５０の状態情報を取得する処理を終了（Ｓ３２６）する。

なお、本願では管理アプリケーションと監視アプリケーションを用いて説明を続けるが、上述した印刷設定アプリケーションであっても良い。

ここで図５を用いて、ベンダーユニークなスキーマ仕様を記したＢｉｄｉ拡張スキーマ定義ファイル２１２の詳細について説明する。Ｂｉｄｉ拡張スキーマ定義ファイル２１２は図５で示すとおり、ＸＭＬマークアップ言語で記述されている。図５で示すＢｉｄｉ拡張スキーマ定義ファイルには、ＥｘｃｌｕｓｉｖｅＡｃｃｅｓｓＯＮ、ＥｘｃｌｕｓｉｖｅＡｃｃｅｓｓＯＦＦ、ＳｅｔＤａｔａ、ＧｅｔＤａｔａ、というスキーマがＶａｌｕｅｎａｍｅとして定義されている様子を示す。ＥｘｃｌｕｓｉｖｅＡｃｃｅｓｓＯＮのＢｉｄｉスキーマによって、Ｂｉｄｉ拡張ＪＳ２１１およびＯＳのＵＳＢポートモニター２０７は、ＥｘｃｌｕｓｉｖｅＡｃｃｅｓｓＯＮのＢｉｄｉスキーマを発行したアプリケーションに占有される。そのため、ＥｘｃｌｕｓｉｖｅＡｃｃｅｓｓＯＮのＢｉｄｉスキーマは占有要求と呼ぶこともできる。また、ＥｘｃｌｕｓｉｖｅＡｃｃｅｓｓＯＦＦのＢｉｄｉスキーマによって、Ｂｉｄｉ拡張ＪＳ２１１およびＯＳのＵＳＢポートモニター２０７は、占有処理を終了する。そのため、Ｂｉｄｉ拡張ＪＳ２１１およびＯＳのＵＳＢポートモニター２０７は、占有終了要求と呼ぶこともある。

ＥｘｃｌｕｓｉｖｅＡｃｃｅｓｓＯＮスキーマは、Ｖａｌｕｅ ｔｙｐｅがＢＩＤＩ＿ＳＴＲＩＮＧ型、ａｃｃｅｓｓＴｙｐｅがＳｅｔ、スキーマパスが￥￥Ｐｒｉｎｔｅｒ￥ＢｉｄｉＣｏｎｔｒｏｌ：ＥｘｃｌｕｓｉｖｅＡｃｃｅｓｓＯＮとして定義されている。ＥｘｃｌｕｓｉｖｅＡｃｃｅｓｓＯＮは、Ｂｉｄｉインタフェース利用開始処理（Ｓ３０２・Ｓ３２２）を実行するときに利用するＢｉｄｉインタフェースに指定されるスキーマである。ＥｘｃｌｕｓｉｖｅＡｃｃｅｓｓＯＦＦスキーマは、Ｖａｌｕｅ ｔｙｐｅがＢＩＤＩ＿ＳＴＲＩＮＧ型、ａｃｃｅｓｓＴｙｐｅがＳｅｔ、スキーマパスが￥￥Ｐｒｉｎｔｅｒ￥ＢｉｄｉＣｏｎｔｒｏｌ：ＥｘｃｌｕｓｉｖｅＡｃｃｅｓｓＯＦＦとして定義されている。ＥｘｃｌｕｓｉｖｅＡｃｃｅｓｓＯＦＦは、Ｂｉｄｉインタフェース利用終了処理（Ｓ３０９・Ｓ３２５）を実行するときに利用するＢｉｄｉインタフェースに指定されるスキーマである。ＳｅｔＤａｔａスキーマは、Ｖａｌｕｅ ｔｙｐｅがＢＩＤＩ＿ＳＴＲＩＮＧ型、ａｃｃｅｓｓＴｙｐｅがＳｅｔ、スキーマパスが￥￥Ｐｒｉｎｔｅｒ￥Ｅｘｔｅｎｓｉｏｎ：ＳｅｔＤａｔａとして定義されている。ＳｅｔＤａｔａは、メディアリスト取得処理（Ｓ３０４）、メディアリスト書込み処理（Ｓ３０８）、印刷装置２５０の状態情報取得処理（Ｓ３２４）において、要求情報を印刷装置２５０に書き込むときに利用されるスキーマである。このＳｅｔＤａｔａスキーマが、上記処理のためにＢｉｄｉインタフェースに指定される。ＳｅｔＤａｔａスキーマを用いて、図６に示すようなメディアリスト要求コマンド（図６（ａ））や、印刷装置２５０状態情報要求コマンド（図６（ｂ））、メディア情報設定コマンド（図６（ｃ））を印刷装置２５０に書き込むことができる。ＧｅｔＤａｔａスキーマは、Ｖａｌｕｅ ｔｙｐｅがＢＩＤＩ＿ＳＴＲＩＮＧ型、ａｃｃｅｓｓＴｙｐｅがＧｅｔ、スキーマパスが￥￥Ｐｒｉｎｔｅｒ￥Ｅｘｔｅｎｓｉｏｎ：ＧｅｔＤａｔａとして定義されている。ＧｅｔＤａｔａは、メディアリスト取得処理（Ｓ３０４）、メディアリスト書込み処理（Ｓ３０８）、状態情報取得処理（Ｓ３２４）において、印刷装置２５０から応答情報を取得するときに利用されるスキーマである。このＧｅｔＤａｔａスキーマが、上記処理のためにＢｉｄｉインタフェースに指定される。ＳｅｔＤａｔａスキーマにて図６（ａ）のメディアリスト要求コマンドを印刷装置２５０に書き込んだ後、ＧｅｔＤａｔａスキーマを用いることで図６（ｄ）に示すようなメディアリスト応答情報を印刷装置２５０から取得することができる。ここでは本実施形態の説明に必要なスキーマしか記載していないが、例えば印刷装置の能力情報取得用スキーマ等、その他の機能に応じて定義しておく必要があることはいうまでもない。

図４（ａ）は、Ｂｉｄｉインタフェースによってスキーマを受領したＵＳＢポートモニター２０７により呼び出されたＢｉｄｉ拡張ＪＳ２１１のスキーマ判定処理を示すフローチャートである。ＯＳは、アプリケーションから受信したＢｉｄｉスキーマの内容を理解できない。そのため、ＵＳＢポートモニター２０７が、オブジェクトと、アプリケーション２１０から受領したＢｉｄｉスキーマの両者を、Ｂｉｄｉ拡張ＪＳ２１１の関数を呼び出す際にＢｉｄｉ拡張ＪＳ２１１に渡す。この処理により図４（ａ）−（ｅ）の処理が開始される。

Ｂｉｄｉ拡張ＪＳ２１１はスキーマ判定処理を開始（Ｓ４０１）すると、受領したスキーマのスキーマ名（Ｖａｌｕｅ ｎａｍｅ）を判定する（Ｓ４０２）。Ｂｉｄｉ拡張ＪＳ２１１は、Ｓ４０２において判定されたスキーマ名が排他開始（ＥｘｃｌｕｓｉｖｅＡｃｃｅｓｓＯＮ）か否かを判定（Ｓ４０３）する。判定（Ｓ４０３）の結果がＹｅｓの場合、Ｂｉｄｉ拡張ＪＳ２１１は排他開始処理（Ｓ４０４）を実行した後に処理を終了（Ｓ４１１）する。なお、Ｓ４０４の詳細な説明は図４（ｂ）に記載する。判定（Ｓ４０３）の結果がＮｏの場合、Ｂｉｄｉ拡張ＪＳ２１１はスキーマ名が排他終了（ＥｘｃｌｕｓｉｖｅＡｃｃｅｓｓＯＦＦ）か否かを判定（Ｓ４０５）する。判定（Ｓ４０５）の結果がＹｅｓの場合、Ｂｉｄｉ拡張ＪＳ２１１は排他終了処理（Ｓ４０６）を実行した後に処理を終了（Ｓ４１１）する。なお、Ｓ４０６の詳細な説明は図４（ｃ）に記載する。判定（Ｓ４０５）の結果がＮｏの場合、Ｂｉｄｉ拡張ＪＳ２１１はスキーマ名が情報送信（ＳｅｔＤａｔａ）か否かを判定（Ｓ４０７）する。判定（Ｓ４０７）の結果がＹｅｓの場合、Ｂｉｄｉ拡張ＪＳ２１１は情報送信処理（Ｓ４０８）を実行した後に処理を終了（Ｓ４１１）する。なお、Ｓ４０８の詳細な説明は図４（ｄ）に記載する。判定（Ｓ４０７）の結果がＮｏの場合、Ｂｉｄｉ拡張ＪＳ２１１はスキーマ名が情報受信（ＧｅｔＤａｔａ）か否かを判定（Ｓ４０９）する。判定（Ｓ４０９）の結果がＹｅｓの場合、Ｂｉｄｉ拡張ＪＳ２１１は情報受信処理（Ｓ４１０）を実行した後に処理を終了（Ｓ４１１）する。なお、Ｓ４１０の詳細な説明は図４（ｅ）に記載する。判定（Ｓ４０９）の結果がＮｏの場合、Ｂｉｄｉ拡張ＪＳ２１１は処理を終了（Ｓ４１１）する。

図４（ｂ）は、Ｂｉｄｉ拡張ＪＳ２１１の排他開始処理（Ｓ４０４）の詳細を示すフローチャートである。

Ｂｉｄｉ拡張ＪＳ２１１は排他開始処理を開始（Ｓ４２１）すると記憶領域（Ｓ４２３）を参照し、排他状態を確認（Ｓ４２２）する。処理（Ｓ４２２）は、具体的にはＢｉｄｉ拡張ＪＳがＯＳから渡された情報を参照することにより、実現する。ＯＳから渡された情報とは、ＯＳから渡されるオブジェクトに含まれる排他状態を示すプロパティであってもよいし、オブジェクトに含まれるメソッドを実行した結果で得られる情報であってもよい。

上述したように図４（ｂ）−（ｅ）の処理は、ＵＳＢポートモニター２０７が、オブジェクトと、アプリケーション２１０から受領したＢｉｄｉスキーマの両者を、Ｂｉｄｉ拡張ＪＳ２１１の関数を呼び出す際にＢｉｄｉ拡張ＪＳ２１１に渡すことで実現される。つまり、Ｂｉｄｉ拡張ＪＳ２１１は、ＯＳから渡されたオブジェクトを用いて処理を実行する。

以降、図４（ｂ）−（ｅ）において、ＯＳから渡されたオブジェクトを用いて実行される処理を“ＯＳから渡されたオブジェクトを介した処理”と表現する。

Ｂｉｄｉ拡張ＪＳ２１１は排他開始済みかを判定（Ｓ４２４）し、既に排他されていた場合、処理を終了（Ｓ４２６）する。なお、Ｓ４２４において排他開始済みと判定された判定された場合、既に排他されていることを示す情報がＢｉｄｉ拡張ＪＳ２１１によりフィードバックとしてＯＳに通知される。このフィードバックを受けて、ＯＳはＢｉｄｉスキーマを発行したアプリケーションに既に排他されていることを示す情報を通知する。判定（Ｓ４２４）にて、未だ排他されていないと判断した場合、Ｂｉｄｉ拡張ＪＳ２１１はＯＳを介して記憶領域（Ｓ４２３）に排他状態を設定（Ｓ４２５）し、処理を終了（Ｓ４２６）する。なお、処理（Ｓ４２５）は、ＯＳから渡されたオブジェクトを介した処理である。つまり、Ｓ４２４において排他されていないと判断された場合（Ｓ４２４−Ｎｏ）、Ｂｉｄｉ拡張ＪＳ２１１が、ＯＳの排他処理実行ＡＰＩに実行を指示することでＯＳが排他状態を記憶領域に書き込む。この処理により、ＯＳのＵＳＢポートモニターが、排他要求元のアプリケーションに占有される。なお、記憶領域には、排他開始したプロセスに関する情報（例えば、プロセスＩＤ）も記憶される。

図４（ｃ）は、Ｂｉｄｉ拡張ＪＳ２１１の排他終了処理（Ｓ４０６）の詳細を示すフローチャートである。

Ｂｉｄｉ拡張ＪＳ２１１は排他終了処理を開始（Ｓ４３１）すると、記憶領域（Ｓ４３３）を参照し、排他状態を確認（Ｓ４３２）する。なお、処理（Ｓ４３２）は、ＯＳから渡されたオブジェクトを介した処理である。

Ｂｉｄｉ拡張ＪＳ２１１は、記憶領域（Ｓ４３３）に記録された排他開始したプロセスと、排他終了処理（Ｓ４３１）を実行したプロセスとを比較（Ｓ４３４）し、一致しているかを判定（Ｓ４３５）する。プロセスを識別する方法として、Ｂｉｄｉインタフェースを呼び出したアプリケーションのプロセスＩＤを用いて識別してもよい。また別の識別方法としては、アプリケーションがユニークなＩＤをＢｉｄｉインタフェースのパラメータの一つとして設定し、設定されたＩＤを用いて識別されてもよい。つまり、Ｓ４３５の処理が、占有要求元のアプリケーションと占有終了要求元のアプリケーションが同一であるか否かの判定処理となる。

判定（Ｓ４３５）にてＮｏと判断した場合、Ｂｉｄｉ拡張ＪＳ２１１は処理を終了（Ｓ４３７）する。なお、Ｓ４３５においてＮｏと判定された場合、Ｂｉｄｉ拡張ＪＳ２１１が排他終了処理に失敗した旨をフィードバックとしてＯＳに通知する。このフィードバックを受けて、ＯＳはＢｉｄｉスキーマの発行元に排他終了処理に失敗した旨を通知する。

判定（Ｓ４３５）にてＹｅｓと判断した場合、Ｂｉｄｉ拡張ＪＳ２１１は記憶領域（Ｓ４３３）の排他状態情報を削除するよう設定（Ｓ４３６）した後に処理を終了（Ｓ４３７）する。そしてＯＳが、Ｓ４３６において設定された内容に従って排他状態情報を削除する。なお、処理（Ｓ４３６）は、ＯＳから渡されたオブジェクトを介した処理である。つまり、Ｓ４３５において一致する判断された場合（Ｓ４３５−Ｙｅｓ）、Ｂｉｄｉ拡張ＪＳ２１１が、ＯＳの排他処理実行ＡＰＩに占有状態の終了を指示することでＯＳが排他状態情報を削除する。この処理により、ＯＳのＵＳＢポートモニター２０７の占有状態が解除される。

図４（ｄ）は、Ｂｉｄｉ拡張ＪＳ２１１の情報送信処理（Ｓ４０８）の詳細を示すフローチャートである。

Ｂｉｄｉ拡張ＪＳ２１１は情報送信処理を開始（Ｓ４４１）すると、記憶領域（Ｓ４４３）を参照し、排他状態を確認（Ｓ４４２）する。なお、処理（Ｓ４４２）は、ＯＳから渡されたオブジェクト介した処理である。Ｂｉｄｉ拡張ＪＳ２１１は、記憶領域（Ｓ４４３）に記録された排他開始したプロセスと、情報送信処理（Ｓ４４１）を実行したプロセスとを比較し、一致しているかを判定（Ｓ４４５）する。なお、判定処理は、図４（ｃ）のＳ４３５と類似しているため詳細な説明は省略する。判定（Ｓ４４５）にてＮｏと判断した場合、Ｂｉｄｉ拡張ＪＳ２１１は処理を終了（Ｓ４４７）する。Ｓ４４５においてＮｏと判定された場合、Ｂｉｄｉ拡張ＪＳ２１１が他のアプリケーションにより占有状態のため情報送信処理できない旨をフィードバックとしてＯＳに通知する。このフィードバックを受けて、ＯＳはＢｉｄｉスキーマの発行元に情報送信処理できない旨を通知する。判定（Ｓ４４５）にてＹｅｓと判断した場合、Ｂｉｄｉ拡張ＪＳ２１１は印刷装置２５０に対する情報送信処理の実施を指示（Ｓ４４６）した後に処理を終了（Ｓ４４７）する。つまり、Ｓ４４５において一致する判断された場合（Ｓ４４５−Ｙｅｓ）、Ｂｉｄｉ拡張ＪＳ２１１が、ＯＳに対して情報送信処理の実行を指示することでＯＳが印刷装置に対して情報の送信を実行する。例えば、管理アプリケーションにより編集されたメディアリストが印刷装置に送信される。なお、処理（Ｓ４４６）は、ＯＳから渡されたオブジェクトを介した処理である。ここで、判定（Ｓ４４５）において記憶領域（Ｓ４４３）に排他開始情報が存在していなかった場合も、Ｂｉｄｉ拡張ＪＳ２１１は情報送信処理（Ｓ４４６）を実行する。これは印刷装置２５０へのアクセス処理において排他状態を維持することが不要なアプリケーションのための措置である。

図４（ｅ）は、Ｂｉｄｉ拡張ＪＳ２１１の情報送信処理（Ｓ４１０）の詳細を示すフローチャートである。

Ｂｉｄｉ拡張ＪＳ２１１は情報送信処理を開始（Ｓ４５１）すると、記憶領域（Ｓ４５３）を参照し、排他状態を確認（Ｓ４５２）する。なお、処理（Ｓ４５２）が、ＯＳから渡されたオブジェクトを介した処理である。Ｂｉｄｉ拡張ＪＳ２１１は、記憶領域（Ｓ４５３）に記録された排他開始したプロセスと、情報受信処理（Ｓ４５１）を実行したプロセスとを比較（Ｓ４５４）し、一致しているかを判定（Ｓ４５５）する。なお、判定処理は、図４（ｃ）のＳ４３５と類似しているため詳細な説明は省略する。

判定（Ｓ４５５）にてＮｏと判断した場合、Ｂｉｄｉ拡張ＪＳ２１１は処理を終了（Ｓ４５７）する。Ｓ４５５においてＮｏと判定された場合、Ｂｉｄｉ拡張ＪＳ２１１が他のアプリケーションにより占有状態のため情報受信処理に失敗した旨をフィードバックとしてＯＳに通知する。このフィードバックを受けて、ＯＳはＢｉｄｉスキーマの発行元に情報受信処理ができない旨を通知する。判定（Ｓ４５５）にてＹｅｓと判断した場合、Ｂｉｄｉ拡張ＪＳ２１１は印刷装置２５０に対し情報受信処理の実行を指示（Ｓ４５６）した後に処理を終了（Ｓ４５７）する。つまり、Ｓ４５５において一致する判断された場合（Ｓ４４５−Ｙｅｓ）、Ｂｉｄｉ拡張ＪＳ２１１が、ＯＳに対して情報受信処理の実行を指示することでＯＳが印刷装置から情報の受信処理（取得処理）を実行する。例えば、印刷装置の機能情報や、印刷装置の状態情報が取得される。なお、処理（Ｓ４５６）は、ＯＳから渡されたオブジェクトを介した処理である。ここで、判定（Ｓ４５５）において記憶領域（Ｓ４５３）に排他開始情報が存在していなかった場合も、Ｂｉｄｉ拡張ＪＳ２１１は情報送信処理（Ｓ４５６）を実行する。これは印刷装置２５０へのアクセス処理において排他状態を維持することが不要なアプリケーションのための措置である。

図４の処理によりＢｉｄｉ拡張ＪＳ２１１が、Ｂｉｄｉスキーマを送信したアプリケーション２１０に占有され、他のアプリケーションの使用が制限されるため、本願の課題を解決することが可能となる。

図７は各種アプリケーションとＯＳと印刷装置の全体的な処理の流れを示すシーケンス図である。図７を以て、アプリケーションＡがＵＳＢを占有する間に、その他のアプリケーションやスプーラがどのような挙動をするか、を説明する。

アプリケーションＡ（７００）とは、例えば図３（ａ）を用いて説明した管理アプリケーションである。管理アプリケーション（７００）は、Ｂｉｄｉ利用開始処理（７０１・Ｓ３０２）を実行する。Ｂｉｄｉ利用開始処理（７０１）によって、ＵＳＢポートモニター（７６０）は、Ｂｉｄｉ拡張ＪＳ（７６０）により実行される図４の処理のフィードバックとして排他開始処理の指示を受ける（Ｓ４２５）。その結果、ＵＳＢポートモニター（７６０）は、排他開始処理（７６１）を実行する。なお、Ｂｉｄｉ拡張ＪＳは、排他処理に成功した旨を管理アプリケーション（７００）に応答する。よって、管理アプリケーションが、占有要求元のアプリケーションとなる。

アプリケーションＢ（７２０）とは、例えば図３（ｂ）を用いて説明した監視アプリケーションである。監視アプリケーション（７２０）は、印刷装置２５０の状態情報を取得しようと、Ｂｉｄｉ利用開始処理（７２１・Ｓ３２２）を実行する。これにより、監視アプリケーションは、印刷装置の状態情報の取得の実行要求を行う。しかし、ＵＳＢポートモニターは、管理アプリケーション（７００）によるＵＳＢポート占有期間中（７６２）となっている。そのため、ＵＳＢポートモニターは、Ｂｉｄｉ拡張ＪＳ（７６０）により実行される図４の処理（排他開始済みである判定（Ｓ４２４−Ｙｅｓ））のフィードバックとして排他されていることを受け付ける。その結果、ＵＳＢポートモニターは、監視アプリケーションに対し占有処理エラーの応答処理（７６３）を行う。なお、エラー応答を受信した監視アプリケーション（７２０）は、占有できなかったことを示すエラー画面を表示しても良い。若しくは、監視アプリケーション（７２０）は、任意の一定時間を置いてＢｉｄｉ利用開始処理（７２１）を再試行してもよい。

アプリケーションＣ（７３０）とは、Ｂｉｄｉに依る情報送受信を実行するアプリケーション（２１０）の一つであるが、Ｂｉｄｉ利用開始宣言を行わないアプリケーションである。アプリケーションＣ（７３０）は、ＢｉｄｉによるＷｒｉｔｅ／Ｒｅａｄ処理（７３１）を実行する。しかし、管理アプリケーションによるＵＳＢポート占有期間（７６２）となっている。そのため、ＵＳＢポートモニターは、Ｂｉｄｉ拡張ＪＳ（７６０）により実行される図４の処理（Ｓ４４５若しくはＳ４５５にて不一致の判定）のフィードバックとして排他されているため情報送受信できないことを受け付ける。その結果、ＵＳＢポートモニターは、アプリケーションＣに対しエラー応答処理（７６４）を行う。なお、このときアプリケーションＣが要求した情報に対する応答情報のキャッシュデータが既に用意されていれば、ＵＳＢポートモニター（７６０）はアプリケーションＣにキャッシュ情報を応答（７６４）してもよい。つまり、ＵＳＢポートモニター（７６０）は、キャッシュ情報が既に保存されているか否かを判断する。さらに、Ｂｉｄｉ拡張ＪＳ（７６０）が、Ｗｒｉｔｅ／Ｒｅａｄ要求を受けたＢｉｄｉスキーマの種別に応じて、キャッシュ情報を応答（７６４）するか否かを判断してもよい。具体的には、能力情報（Ｃａｐａｂｉｌｉｔｙ）の取得要求であれば、Ｂｉｄｉ拡張ＪＳ（７６０）が、キャッシュ情報を応答すると判断し、状態情報（Ｓｔａｔｕｓ）の取得要求であれば、キャッシュ情報を応答しないと判断する。

若しくは、Ｂｉｄｉ拡張スキーマ定義ファイルに、キャッシュ情報を応答（７６４）するか否かの定義が記述され、その記述をＵＳＢポートモニター（７３０）が参照してキャッシュ情報を応答（７６４）するか否かを判断してもよい。これにより、例えば、管理アプリケーション（７００）が既にＵＳＢポートモニターを占有している最中に、アプリケーションＣが能力情報の取得要求をＵＳＢポートモニターに発行した場合、アプリケーションＣはキャッシュ情報を取得することが可能となる。

アプリケーションＤ（７４０）とは、印刷アプリケーション（２０１）の一つである。アプリケーションＤが、ユーザーの印刷指示に従って印刷ジョブを発行する（７４１）と、スプーラ及び印刷キュー（７５０）は印刷ジョブを受領（７５１）する。しかし、管理アプリケーション（７００）によるＵＳＢポート占有期間中（７６２）となっているため、スプーラ（７５０）はＵＳＢポートの占有状態が解除されるまで印刷ジョブのデスプールを待ち（７５２）、印刷キューに留めておく。

監視アプリケーション（７２０）、アプリケーションＣ（７３０）、スプーラのデスプール（７５０）によるＵＳＢポート利用の制限を実施している間、管理アプリケーション（７００）は、Ｗｒｉｔｅ／Ｒｅａｄ処理（７０２・Ｓ４４６・Ｓ４５６）を実行する。Ｗｒｉｔｅ／Ｒｅａｄ処理（７０２・Ｓ４４６・Ｓ４５６）とは、メディアリスト取得処理（Ｓ３０４）や、メディアリスト書込み処理（Ｓ３０８）を指す。管理アプリケーション（７００）はＵＳＢポートの利用を占有している状態にあるため、Ｗｒｉｔｅ／Ｒｅａｄ処理（７０２・Ｓ４４６／Ｓ４５６）を複数回繰り返すことが可能である。さらには、印刷ジョブやその他のアプリケーションに割り込まれる懸念はない。なお、管理アプリケーション（７００）は、Ｗｒｉｔｅ／Ｒｅａｄ処理（７０２・Ｓ４４６／Ｓ４５６）を複数回繰り返す場合に、Ｂｉｄｉ利用開始処理（７０１・Ｓ３０２）を実行する。一方、管理アプリケーション（７００）は、Ｗｒｉｔｅ／Ｒｅａｄ処理（７０２・Ｓ４４６／Ｓ４５６）を１回のみ実行する場合、Ｂｉｄｉ利用開始処理（７０１・Ｓ３０２）を実行しなくても良い。

Ｗｒｉｔｅ／Ｒｅａｄ処理（７０２・Ｓ４４６・Ｓ４５６）を受けて（７６５）、ＵＳＢポートモニター及びＢｉｄｉ拡張ＪＳ（７６０）は、印刷装置（７８０・２５０）に対しＷｒｉｔｅ／Ｒｅａｄ処理（７６６）を実施する。印刷装置（７８０・２５０）は、ＵＳＢポートモニター（７６０・２０７）からの、Ｗｒｉｔｅ／Ｒｅａｄ処理（７６６）の要求を受けて、要求に対するデータを応答する（７８１）。ここで、ＵＳＢポートモニター（７６０・２０７）の要求が、図６（ａ）に示すメディアリスト取得要求である場合、応答するデータ（８６１）は図６（ｄ）に示すメディアリスト応答情報である。印刷装置（７８０・２５０）からの応答（７８１）は、ＵＳＢポートモニター及びＢｉｄｉ拡張ＪＳ（７６０）を経由して、管理アプリケーション（７００）に渡る。管理アプリケーション（７００）は、Ｂｉｄｉインタフェースの利用が終わると、Ｂｉｄｉ利用終了処理（７０３・Ｓ３０９）を実行する。Ｂｉｄｉ利用終了処理（７０３）によって、ＵＳＢポートモニターおよびＢｉｄｉ拡張ＪＳ（７６０）は、排他終了処理（７６７・Ｓ４３６）を実行することで管理アプリケーション（７００）によるＵＳＢポート占有期間（７６２）を解除する。そして、ＵＳＢポートモニターおよびＢｉｄｉ拡張ＪＳ（７６０）は、Ｂｉｄｉ利用終了処理（７０３・Ｓ３０９）が成功した旨を管理アプリケーション（７００）に応答する。よって、管理アプリケーションが、占有終了要求元のアプリケーションとなる。

以上示した通り、管理アプリケーション（７００）はＢｉｄｉ利用開始（７０１）を宣言することにより、各種割込み処理（７２１・７３１・７５２）を制限することが可能となる。また、図７の７６７の排他終了処理により、アプリケーションＢのＢｉｄｉ利用開始処理が可能となり、プリントキューに保持されていた印刷ジョブのデスプール処理が、図７の７６７の排他終了処理により開始される。

なお、アプリケーションＡ（７００）がＢｉｄｉ利用終了処理（７０３）を行わないまま、終了してしまうケースも考えられる。上記ケースに備えて、第一の例としては、ＵＳＢポートモニター（７６０・２０７）はアプリケーションＡ（７００）からのＢｉｄｉ利用が一定時間無い場合には、排他状態を解除してもいい。第二の例としては、ＵＳＢポートモニター（７６０・２０７）はアプリケーションＡ（７００）がＰＣ上に存在しないことを確認した場合には、排他状態を解除してもいい。第三の例としては、アプリケーションＡ（７００）がＢｉｄｉ利用開始処理（７０１）を行う際に、タイムアウト時間（占有期間の制限時間）をＵＳＢポートモニタ（７６０）に伝える処理を行ってもよい。その際、アプリケーションＡは、ユーザーの指示に従って占有期間の制限時間の設定を、Ｂｉｄｉ利用開始処理の前に実行する。そして、ＵＳＢポートモニターの排他処理時間がタイムアウト時間（所定の時間）を経過した場合、ＵＳＢポートモニターは、アプリケーションＡから排他終了要求を受ける前であっても、排他処理を終了する。

また、情報処理装置が複数のｖ４プリンタドライバを備えていることも考えられる。その場合、アプリケーションＡが、ｖ４プリンタドライバＡを指定し、アプリケーションＢが、ｖ４プリンタドライバＢを指定することも考えられる。例えば、アプリケーションＡがＵＳＢポートモニターを占有している状況で、アプリケーションＢがｖ４プリンタドライバＢを指定してＢｉｄｉスキーマを発行したとしても、記憶領域にはＵＳＢポートモニターが占有状態であることが記憶されている。その結果、ｖ４プリンタドライバＢは、アプリケーションＢから発行されたＢｉｄｉスキーマのフィードバックとして、排他に失敗した旨をＯＳに通知する。よって、ＵＳＢポートモニターは、アプリケーションＢに対して排他に失敗した旨を通知することになり、結果としてアプリケーションＡは、ＵＳＢポートモニターを占有できる。

＜実施形態２＞
実施形態１はアプリケーションがＢｉｄｉ利用開始を宣言することにより、他のアプリケーションから割り込まれることを防止し、その間にＢｉｄｉインタフェースを利用しＷｒｉｔｅ／Ｒｅａｄする手段を示した。実施形態２においては、アプリケーションがＢｉｄｉ利用開始を宣言することにより、他のアプリケーションから割り込まれることを防止し、その間にＵＳＢデバイスインタフェース２０８に対し直接Ｗｒｉｔｅ／Ｒｅａｄする手段を説明する。

図８はアプリケーションとＯＳと印刷装置の全体的な処理の流れを示すシーケンス図である。図８を以て、アプリケーションがＵＳＢを占有する間に、アプリケーションが直接ＵＳＢデバイスインタフェースを利用する流れを説明する。アプリケーション（８００）とは、例えば図３（ａ）を用いて説明した管理アプリケーションである。

管理アプリケーション（８００）は、Ｂｉｄｉ利用開始処理（８０１・Ｓ３０２）を実行する。Ｂｉｄｉ利用開始処理（８０１）によって、ＵＳＢポートモニターは、Ｂｉｄｉ拡張ＪＳ（８２０）のフィードバックとして排他開始処理（８２１・Ｓ４２５）に成功した旨を受ける。このフィードバックを受けて、ＵＳＢポートモニターは、管理アプリケーション（８００）に排他に成功した旨を応答する。排他開始処理（８２１）を実行したことにより、管理アプリケーション（８００）はＵＳＢポート占有期間（８２２）を設ける。

その他のアプリケーションやスプーラのデスプールによるＵＳＢポート利用の制限を実施している間、管理アプリケーション（８００）は、Ｗｒｉｔｅ／Ｒｅａｄ処理（８０２）を実行する。Ｗｒｉｔｅ／Ｒｅａｄ処理（８０２）とは、ＵＳＢデバイスインタフェース（８４０・２０８）をＯｐｅｎし、直接データをＷｒｉｔｅ／Ｒｅａｄする処理である。処理（８０２）を受けて（８４１）、ＵＳＢデバイスインタフェース（８４０・２０８）は、印刷装置（８６０・２５０）に対しＷｒｉｔｅ／Ｒｅａｄ処理（８４２）を実施する。印刷装置（８６０・２５０）は、ＵＳＢデバイスインタフェース（８４０・２０８）からの、Ｗｒｉｔｅ／Ｒｅａｄ処理（７６６）の要求を受けて、要求に対するデータを応答する（８６１）。ここで、ＵＳＢデバイスインタフェース（８４０・２０８）の要求が、図６（ａ）に示すメディアリスト取得要求である場合、応答するデータ（８６１）は図６（ｄ）に示すメディアリスト応答情報である。印刷装置（８６０・２５０）からの応答（８６１）は、ＵＳＢデバイスインタフェース（８４０・２０８）を経由して、管理アプリケーション（８００）に渡る。管理アプリケーション（８００）は、Ｂｉｄｉインタフェースの利用が終わると、Ｂｉｄｉ利用終了処理（８０３・Ｓ３０９）を実行する。Ｂｉｄｉ利用終了処理（８０３）によって、Ｂｉｄｉ拡張ＪＳ（８２０）からフィードバックとして排他終了処理の実行がＵＳＢポートモニターに通知される。紺フィードバックを受けて、ＵＳＢポートモニターは、管理アプリケーション（８００）によるＵＳＢポート占有期間（８２２）を解除する。そして、ＵＳＢポートモニター（８２０）は、Ｂｉｄｉ利用終了処理（８０３・Ｓ３０９）が成功した旨を管理アプリケーション（８００）に応答する。

以上示した通り、管理アプリケーション（８００）はＢｉｄｉ利用開始（８０１）を宣言することにより、各種割込み処理を制限している間に、ＵＳＢデバイスインタフェースを利用することが可能となる。その結果、アプリケーション８００とは異なるアプリケーションがＵＳＢポートモニターおよびＢｉｄｉ拡張ＪＳ８２０を介してＵＳＢデバイスインタフェースを用いた処理を実行できなくなるため、本願の課題を解決することができる。

＜その他の実施形態＞
本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステムまたは装置に供給し、そのシステムまたは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。また、プログラムを実行するコンピュータは、１つであってもよいし、複数のコンピュータが協働してプログラムを実行するものであってもよい。さらに、プログラムの一部を実行する回路等のハードウェアを設け、そのハードウェアと、ソフトウェアを実行するコンピュータが協働して、本実施形態で説明した処理を実行する場合であってもよい。なお、本願では、情報処理装置と通信可能な装置として印刷装置を記載したが、デジタルカメラやスキャナ等の周辺装置であっても良い。

Claims (25)

1. プリンタドライバが印刷設定画面を表示することを制限し、かつ、前記プリンタドライバと関連する印刷アプリケーションが印刷設定画面を表示することを許可するオペレーティングシステムが動作する情報処理装置であって、
   アプリケーションから占有要求を受信する受信手段と、
   前記占有要求に基づく占有期間において、前記占有要求を発行したアプリケーションが周辺装置から情報を取得する処理および前記周辺装置へ情報を送信する処理の少なくとも１つを実行でき、かつ、前記占有要求を発行したアプリケーションとは異なるアプリケーションが前記周辺装置から情報を取得する処理および前記周辺装置へ情報を送信する処理を実行できないように占有処理を実行する実行手段と、
   前記受信手段が占有終了要求を受信した場合、前記占有要求を発行したアプリケーションと前記占有終了要求を発行したアプリケーションが同一であるか否かを判定する判定手段を備え、
   前記占有要求を発行したアプリケーションと前記占有終了要求を発行したアプリケーションが同一であると判定された場合、前記実行手段は、前記占有処理を解除することを特徴とする情報処理装置。
2. 前記実行手段は、前記占有処理の実行をオペレーティングシステムのＵＳＢポートモニターに指示することで、前記占有要求に基づく占有期間において、前記占有要求を発行したアプリケーションが周辺装置から情報を取得する処理および前記周辺装置へ情報を送信する処理の少なくとも１つを実行でき、かつ、前記占有要求を発行したアプリケーションとは異なるアプリケーションが前記周辺装置から情報を取得する処理および前記周辺装置へ情報を送信する処理を実行できなくなることを特徴とする請求項１に記載の情報処理装置。
3. 前記実行手段は、前記占有要求を発行したアプリケーションから送信される占有要求に対応するＢｉｄｉスキーマと前記オペレーティングシステムから送信されるオブジェクトに基づいて前記占有処理を実行することを特徴とする請求項１または２に記載の情報処理装置。
4. 前記実行手段は、前記占有期間において前記占有要求を発行したアプリケーションとは異なるアプリケーションから占有要求を受信した場合、前記異なるアプリケーションに対して占有処理エラーを示す情報を送信することを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
5. 前記実行手段は、前記占有処理を実行してから所定の時間が経過した場合、前記占有終了要求を受信する前に前記占有処理を解除することを特徴とする請求項１乃至４のいずれか１項に記載の情報処理装置。
6. プリンタドライバが印刷設定画面を表示することを制限し、かつ、前記プリンタドライバと関連する印刷アプリケーションが印刷設定画面を表示することを許可するオペレーティングシステムが動作する情報処理装置であって、
   アプリケーションから発行される占有要求を受信する受信手段と、
   前記占有要求を前記プリンタドライバに送信する送信手段と、
   前記プリンタドライバから前記占有要求に基づく指示を受けることにより、前記占有要求を発行したアプリケーションが周辺装置から情報を取得する処理および前記周辺装置へ情報を送信する処理の少なくとも１つを実行でき、かつ、前記占有要求を発行したアプリケーションとは異なるアプリケーションが前記周辺装置から情報を取得する処理および前記周辺装置へ情報を送信する処理を実行できないように占有処理を実行する実行手段を備えることを特徴とする情報処理装置。
7. 前記受信手段は、前記アプリケーションから前記占有要求としてＢｉｄｉスキーマを受信し、
   前記プリンタドライバが備えるＢｉｄｉ拡張スキーマ定義ファイルを参照することで前記プリンタドライバが備えるＢｉｄｉ拡張ＪａｖａＳｃｒｉｐｔ（登録商標）の関数が特定されることを特徴とする請求項６に記載の情報処理装置。
8. 前記実行手段は、前記占有処理を実行してから所定の時間が経過した場合、占有終了要求を受信する前に前記占有処理を解除することを特徴とする請求項６または７に記載の情報処理装置。
9. 前記占有処理の期間中に前記占有要求を発行したアプリケーションとは異なるアプリケーションが印刷ジョブを発行した場合、前記占有処理が解除されるまで前記印刷ジョブを保持しておく保持手段を更に備えることを特徴とする請求項６乃至８のいずれか１項に記載の情報処理装置。
10. プリンタドライバが印刷設定画面を表示することを制限し、かつ、前記プリンタドライバと関連する印刷アプリケーションが印刷設定画面を表示することを許可するオペレーティングシステムが動作する情報処理装置における制御方法であって、
    アプリケーションから占有要求を受信する受信ステップと、
    前記占有要求に基づく占有期間において、前記占有要求を発行したアプリケーションが周辺装置から情報を取得する処理および前記周辺装置へ情報を送信する処理の少なくとも１つを実行でき、かつ、前記占有要求を発行したアプリケーションとは異なるアプリケーションが前記周辺装置から情報を取得する処理および前記周辺装置へ情報を送信する処理を実行できないように占有処理を実行する実行ステップと、
    前記受信ステップが占有終了要求を受信した場合、前記占有要求を発行したアプリケーションと前記占有終了要求を発行したアプリケーションが同一であるか否かを判定する判定ステップを実行し、
    前記占有要求を発行したアプリケーションと前記占有終了要求を発行したアプリケーションが同一であると判定された場合、前記実行ステップは、前記占有処理を解除することを特徴とする制御方法。
11. プリンタドライバが印刷設定画面を表示することを制限し、かつ、前記プリンタドライバと関連する印刷アプリケーションが印刷設定画面を表示することを許可するオペレーティングシステムが動作する情報処理装置における制御方法であって、
    アプリケーションから発行される占有要求を受信する受信ステップと、
    前記占有要求を前記プリンタドライバに送信する送信ステップと、
    前記プリンタドライバから前記占有要求に基づく指示を受けることにより、前記占有要求を発行したアプリケーションが周辺装置から情報を取得する処理および前記周辺装置へ情報を送信する処理の少なくとも１つを実行でき、かつ、前記占有要求を発行したアプリケーションとは異なるアプリケーションが前記周辺装置から情報を取得する処理および前記周辺装置へ情報を送信する処理を実行できないように占有処理を実行する実行ステップを実行することを特徴とする制御方法。
12. プリンタドライバが印刷設定画面を表示することを制限し、かつ、前記プリンタドライバと関連する印刷アプリケーションが印刷設定画面を表示することを許可するオペレーティングシステムが動作する情報処理装置に、
    アプリケーションから占有要求を受信する受信ステップと、
    前記占有要求に基づく占有期間において、前記占有要求を発行したアプリケーションが周辺装置から情報を取得する処理および前記周辺装置へ情報を送信する処理の少なくとも１つを実行でき、かつ、前記占有要求を発行したアプリケーションとは異なるアプリケーションが前記周辺装置から情報を取得する処理および前記周辺装置へ情報を送信する処理を実行できないように占有処理を実行する実行ステップと、
    前記受信ステップが占有終了要求を受信した場合、前記占有要求を発行したアプリケーションと前記占有終了要求を発行したアプリケーションが同一であるか否かを判定する判定ステップを実行し、
    前記占有要求を発行したアプリケーションと前記占有終了要求を発行したアプリケーションが同一であると判定された場合、前記実行ステップは、前記占有処理を解除するための前記情報処理装置が読取可能な制御プログラム。
13. 前記実行ステップは、前記占有処理の実行をオペレーティングシステムのＵＳＢポートモニターに指示することで、前記占有要求に基づく占有期間において、前記占有要求を発行したアプリケーションが周辺装置から情報を取得する処理および前記周辺装置へ情報を送信する処理の少なくとも１つを実行でき、かつ、前記占有要求を発行したアプリケーションとは異なるアプリケーションが前記周辺装置から情報を取得する処理および前記周辺装置へ情報を送信する処理を実行できなくなることを特徴とする請求項１２に記載の制御プログラム。
14. 前記実行ステップは、前記占有要求を発行したアプリケーションから送信される占有要求に対応するＢｉｄｉスキーマと前記オペレーティングシステムから送信されるオブジェクトに基づいて前記占有処理を実行することを特徴とする請求項１２または１３に記載の制御プログラム。
15. 前記実行ステップは、前記占有期間において前記占有要求を発行したアプリケーションとは異なるアプリケーションから占有要求を受信した場合、前記異なるアプリケーションに対して占有処理エラーを示す情報を送信することを特徴とする請求項１２乃至１４のいずれか１項に記載の制御プログラム。
16. 前記実行ステップは、前記占有処理を実行してから所定の時間が経過した場合、前記占有終了要求を受信する前に前記占有処理を解除することを特徴とする請求項１２乃至１５のいずれか１項に記載の制御プログラム。
17. プリンタドライバが印刷設定画面を表示することを制限し、かつ、前記プリンタドライバと関連する印刷アプリケーションが印刷設定画面を表示することを許可するオペレーティングシステムが動作する情報処理装置に、
    アプリケーションから発行される占有要求を受信する受信ステップと、
    前記占有要求を前記プリンタドライバに送信する送信ステップと、
    前記プリンタドライバから前記占有要求に基づく指示を受けることにより、前記占有要求を発行したアプリケーションが周辺装置から情報を取得する処理および前記周辺装置へ情報を送信する処理の少なくとも１つを実行でき、かつ、前記占有要求を発行したアプリケーションとは異なるアプリケーションが前記周辺装置から情報を取得する処理および前記周辺装置へ情報を送信する処理を実行できないように占有処理を実行する実行ステップを実行させるための前記情報処理装置が読取可能な制御プログラム。
18. 前記受信ステップは、前記アプリケーションから前記占有要求としてＢｉｄｉスキーマを受信し、
    前記プリンタドライバが備えるＢｉｄｉ拡張スキーマ定義ファイルを参照することで前記プリンタドライバが備えるＢｉｄｉ拡張ＪａｖａＳｃｒｉｐｔ（登録商標）の関数が特定されることを特徴とする請求項１７に記載の制御プログラム。
19. 前記実行ステップは、前記占有処理を実行してから所定の時間が経過した場合、占有終了要求を受信する前に前記占有処理を解除することを特徴とする請求項１７または１８に記載の制御プログラム。
20. 前記占有処理の期間中に前記占有要求を発行したアプリケーションとは異なるアプリケーションが印刷ジョブを発行した場合、前記占有処理が解除されるまで前記印刷ジョブを保持しておく保持ステップを更に備えることを特徴とする請求項１７乃至１９のいずれか１項に記載の制御プログラム。
21. プリンタドライバが印刷設定画面を表示することを制限し、かつ、前記プリンタドライバと関連する印刷アプリケーションが印刷設定画面を表示することを許可するオペレーティングシステムが動作する情報処理装置であって、
    周辺装置の情報を取得する処理および前記周辺装置へ情報を送信する処理の少なくとも１つの実行を要求する実行要求手段と、
    前記オペレーティングシステムに対して占有要求を発行する占有要求手段と、
    前記占有要求により占有状態となった場合、実行要求手段は、前記周辺装置の情報を取得する処理および前記周辺装置へ情報を送信する処理の少なくとも１つを実行し、
    前記占有要求を送信する際に、占有期間の制限時間をアプリケーションが予め指定することを特徴とする情報処理装置。
22. 前記実行要求手段を複数回繰り返す場合に前記占有要求を送信することを特徴とする請求項２１記載の情報処理装置。
23. 前記実行の要求、および、前記占有要求の実行をオペレーティングシステムのＵＳＢポートモニターに指示することを特徴とする請求項２１または２２に記載の情報処理装置。
24. 前記実行の要求および前記占有要求は、対応するＢｉｄｉスキーマを前記オペレーティングシステムに送信することにより実行されることを特徴とする請求項２１乃至２３のいずれか１項に記載の情報処理装置。
25. 前記周辺装置から受信した情報がキャッシュ情報として既に情報処理装置内に保持されているかを判断する第１判断手段と、
    前記キャッシュ情報を応答するべきか否かをＢｉｄｉスキーマの種別に応じて判断する第２判断手段と、を有し、
    占有期間において前記占有要求を発行したアプリケーションとは異なるアプリケーションから前記周辺装置の情報を取得する処理の要求を受信し、前記キャッシュ情報が保持されていると判断され、且つ、前記第２判断手段により応答すべきと判断された場合、前記キャッシュ情報を前記異なるアプリケーションに応答することを特徴とする請求項２１乃至２４のいずれか１項に記載の情報処理装置。

Images