図面 (/)

技術 情報処理装置、制御方法、制御プログラム

出願人 キヤノン株式会社
発明者 川浦俊典
出願日 2015年5月11日 (5年7ヶ月経過) 出願番号 2015-096533
公開日 2016年9月8日 (4年3ヶ月経過) 公開番号 2016-164767
状態 特許登録済
技術分野 入出力制御 付属装置、全体制御 タイプライター等へのデジタル出力
主要キーワード Read処理 ベンダー毎 Read要求 双方向制 プリントサブシステム 占有期間 占有要求 USBデバイスインタフェース
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2016年9月8日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (9)

課題

あるソフトウェア情報送受信を実行している途中で、他のソフトウェアからBidiスキーマを用いた情報送受信の割り込まれてしまうというおそれがあった。

解決手段

情報処理装置は、占有要求発行したアプリケーション周辺装置から情報を取得する処理および周辺装置へ情報を送信する処理の少なくとも1つを実行でき、かつ、他のアプリケーションが周辺装置から情報を取得する処理および周辺装置へ情報を送信する処理を実行できないように占有処理を実行する。

概要

背景

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

近年、次世代のプリンタドライバ(v4プリンタドライバ)アーキテクチャーによる、Bidirectional(Bidi)スキーマを用いた標準的な情報送受信方法が策定された。この次世代のv4プリンタドライバのアーキテクチャーではランゲージモニターが存在しないため、自由な情報送受信制御を行うことが難しくなるおそれがあった。特許文献1には、Bidiスキーマを用いた標準的な情報送受信方法が記載されている。特に特許文献は、プリンタドライバに同されたBidi拡張ファイル、Bidi拡張JavaScript(登録商標)(Bidi拡張JS)ファイルという外部依存ファイルをOperating System(OS)のポートモニターが読み出すことを開示している。この外部依存ファイルにて、プリンタドライバを作成する各社プリンタベンダー毎ユニークな情報送受信仕様が実現される。

概要

あるソフトウェアが情報送受信を実行している途中で、他のソフトウェアからBidiスキーマを用いた情報送受信の割り込まれてしまうというおそれがあった。情報処理装置は、占有要求発行したアプリケーションが周辺装置から情報を取得する処理および周辺装置へ情報を送信する処理の少なくとも1つを実行でき、かつ、他のアプリケーションが周辺装置から情報を取得する処理および周辺装置へ情報を送信する処理を実行できないように占有処理を実行する。

目的

従来のプリンタドライバ(v3プリンタドライバ)アーキテクチャーにおいて、ランゲージモニターという双方向制御モジュールをベンダーが提供する

効果

実績

技術文献被引用数
1件
牽制数
0件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

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

請求項2

前記実行手段は、前記占有処理の実行をオペレーティングシステムのUSBポートモニターに指示することで、前記占有要求に基づく占有期間において、前記占有要求を発行したアプリケーションが周辺装置から情報を取得する処理および前記周辺装置へ情報を送信する処理の少なくとも1つを実行でき、かつ、前記占有要求を発行したアプリケーションとは異なるアプリケーションが前記周辺装置から情報を取得する処理および前記周辺装置へ情報を送信する処理を実行できなくなることを特徴とする請求項1に記載の情報処理装置。

請求項3

前記実行手段は、前記占有要求を発行したアプリケーションから送信される占有要求に対応するBidiスキーマと前記オペレーティングシステムから送信されるオブジェクトに基づいて前記占有処理を実行することを特徴とする請求項1または2に記載の情報処理装置。

請求項4

前記実行手段は、前記占有期間において前記占有要求を発行したアプリケーションとは異なるアプリケーションから占有要求を受信した場合、前記異なるアプリケーションに対して占有処理エラーを示す情報を送信することを特徴とする請求項1乃至3のいずれか1項に記載の情報処理装置。

請求項5

前記受信手段が占有終了要求を受信した場合、前記占有要求を発行したアプリケーションと前記占有終了要求を発行したアプリケーションが同一であるか否かを判定する判定手段を更に有し、前記占有要求を発行したアプリケーションと前記占有終了要求を発行したアプリケーションが同一であると判定された場合、前記実行手段は、前記占有処理を解除することを特徴とする請求項1乃至4のいずれか1項に記載の情報処理装置。

請求項6

前記実行手段は、前記占有処理を実行してから所定の時間が経過した場合、前記占有終了要求を受信する前に前記占有処理を解除することを特徴とする請求項5に記載の情報処理装置。

請求項7

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

請求項8

前記受信手段は、前記アプリケーションから前記占有要求としてBidiスキーマを受信し、前記プリンタドライバが備えるBidi拡張スキーマ定義ファイルを参照することで前記プリンタドライバが備えるBidi拡張JavaScript(登録商標)の関数が特定されることを特徴とする請求項7に記載の情報処理装置。

請求項9

前記実行手段は、前記占有処理を実行してから所定の時間が経過した場合、占有終了要求を受信する前に前記占有処理を解除することを特徴とする請求項7または8に記載の情報処理装置。

請求項10

前記占有処理の期間中に前記占有要求を発行したアプリケーションとは異なるアプリケーションが印刷ジョブを発行した場合、前記占有処理が解除されるまで前記印刷ジョブを保持しておく保持手段を更に備えることを特徴とする請求項7乃至9のいずれか1項に記載の情報処理装置。

請求項11

プリンタドライバが印刷設定画面を表示することを制限し、かつ、前記プリンタドライバと関連する印刷アプリケーションが印刷設定画面を表示することを許可するオペレーティングシステムが動作する情報処理装置における制御方法であって、アプリケーションから占有要求を受信する受信ステップと、前記占有要求に基づく占有期間において、前記占有要求を発行したアプリケーションが周辺装置から情報を取得する処理および前記周辺装置へ情報を送信する処理の少なくとも1つを実行でき、かつ、前記占有要求を発行したアプリケーションとは異なるアプリケーションが前記周辺装置から情報を取得する処理および前記周辺装置へ情報を送信する処理を実行できないように占有処理を実行する実行ステップを実行することを特徴とする制御方法。

請求項12

プリンタドライバが印刷設定画面を表示することを制限し、かつ、前記プリンタドライバと関連する印刷アプリケーションが印刷設定画面を表示することを許可するオペレーティングシステムが動作する情報処理装置における制御方法であって、アプリケーションから発行される占有要求を受信する受信ステップと、前記占有要求を前記プリンタドライバに送信する送信ステップと、前記プリンタドライバから前記占有要求に基づく指示を受けることにより、前記占有要求を発行したアプリケーションが周辺装置から情報を取得する処理および前記周辺装置へ情報を送信する処理の少なくとも1つを実行でき、かつ、前記占有要求を発行したアプリケーションとは異なるアプリケーションが前記周辺装置から情報を取得する処理および前記周辺装置へ情報を送信する処理を実行できないように占有処理を実行する実行ステップを実行することを特徴とする制御方法。

請求項13

プリンタドライバが印刷設定画面を表示することを制限し、かつ、前記プリンタドライバと関連する印刷アプリケーションが印刷設定画面を表示することを許可するオペレーティングシステムが動作する情報処理装置に、アプリケーションから占有要求を受信する受信ステップと、前記占有要求に基づく占有期間において、前記占有要求を発行したアプリケーションが周辺装置から情報を取得する処理および前記周辺装置へ情報を送信する処理の少なくとも1つを実行でき、かつ、前記占有要求を発行したアプリケーションとは異なるアプリケーションが前記周辺装置から情報を取得する処理および前記周辺装置へ情報を送信する処理を実行できないように占有処理を実行する実行ステップを実行させるための前記情報処理装置が読取可能な制御プログラム

請求項14

前記実行ステップは、前記占有処理の実行をオペレーティングシステムのUSBポートモニターに指示することで、前記占有要求に基づく占有期間において、前記占有要求を発行したアプリケーションが周辺装置から情報を取得する処理および前記周辺装置へ情報を送信する処理の少なくとも1つを実行でき、かつ、前記占有要求を発行したアプリケーションとは異なるアプリケーションが前記周辺装置から情報を取得する処理および前記周辺装置へ情報を送信する処理を実行できなくなることを特徴とする請求項13に記載の制御プログラム。

請求項15

前記実行ステップは、前記占有要求を発行したアプリケーションから送信される占有要求に対応するBidiスキーマと前記オペレーティングシステムから送信されるオブジェクトに基づいて前記占有処理を実行することを特徴とする請求項13または14に記載の制御プログラム。

請求項16

前記実行ステップは、前記占有期間において前記占有要求を発行したアプリケーションとは異なるアプリケーションから占有要求を受信した場合、前記異なるアプリケーションに対して占有処理エラーを示す情報を送信することを特徴とする請求項13乃至15のいずれか1項に記載の制御プログラム。

請求項17

前記受信ステップが占有終了要求を受信した場合、前記占有要求を発行したアプリケーションと前記占有終了要求を発行したアプリケーションが同一であるか否かを判定する判定ステップを更に有し、前記占有要求を発行したアプリケーションと前記占有終了要求を発行したアプリケーションが同一であると判定された場合、前記実行ステップは、前記占有処理を解除することを特徴とする請求項13乃至16のいずれか1項に記載の制御プログラム。

請求項18

前記実行ステップは、前記占有処理を実行してから所定の時間が経過した場合、前記占有終了要求を受信する前に前記占有処理を解除することを特徴とする請求項17に記載の制御プログラム。

請求項19

プリンタドライバが印刷設定画面を表示することを制限し、かつ、前記プリンタドライバと関連する印刷アプリケーションが印刷設定画面を表示することを許可するオペレーティングシステムが動作する情報処理装置に、アプリケーションから発行される占有要求を受信する受信ステップと、前記占有要求を前記プリンタドライバに送信する送信ステップと、前記プリンタドライバから前記占有要求に基づく指示を受けることにより、前記占有要求を発行したアプリケーションが周辺装置から情報を取得する処理および前記周辺装置へ情報を送信する処理の少なくとも1つを実行でき、かつ、前記占有要求を発行したアプリケーションとは異なるアプリケーションが前記周辺装置から情報を取得する処理および前記周辺装置へ情報を送信する処理を実行できないように占有処理を実行する実行ステップを実行させるための前記情報処理装置が読取可能な制御プログラム。

請求項20

前記受信ステップは、前記アプリケーションから前記占有要求としてBidiスキーマを受信し、前記プリンタドライバが備えるBidi拡張スキーマ定義ファイルを参照することで前記プリンタドライバが備えるBidi拡張JavaScript(登録商標)の関数が特定されることを特徴とする請求項19に記載の制御プログラム。

請求項21

前記実行ステップは、前記占有処理を実行してから所定の時間が経過した場合、占有終了要求を受信する前に前記占有処理を解除することを特徴とする請求項19または20に記載の制御プログラム。

請求項22

前記占有処理の期間中に前記占有要求を発行したアプリケーションとは異なるアプリケーションが印刷ジョブを発行した場合、前記占有処理が解除されるまで前記印刷ジョブを保持しておく保持ステップを更に備えることを特徴とする請求項19乃至21のいずれか1項に記載の制御プログラム。

請求項23

プリンタドライバが印刷設定画面を表示することを制限し、かつ、前記プリンタドライバと関連する印刷アプリケーションが印刷設定画面を表示することを許可するオペレーティングシステムが動作する情報処理装置であって、周辺装置の情報を取得する処理および前記周辺装置へ情報を送信する処理の少なくとも1つの実行を要求する実行要求手段と、前記オペレーティングシステムに対して占有要求を発行する占有要求手段と、前記占有要求により占有状態となった場合、実行要求手段は、前記周辺装置の情報を取得する処理および前記周辺装置へ情報を送信する処理の少なくとも1つを実行することを特徴とする情報処理装置。

請求項24

前記実行要求手段を複数回繰り返す場合に前記占有要求を送信することを特徴とする請求項23記載の情報処理装置。

請求項25

前記実行の要求、および、前記占有要求の実行をオペレーティングシステムのUSBポートモニターに指示することを特徴とする請求項23または24に記載の情報処理装置。

請求項26

前記実行の要求および前記占有要求は、対応するBidiスキーマを前記オペレーティングシステムに送信することにより実行されることを特徴とする請求項23乃至25のいずれか1項に記載の情報処理装置。

請求項27

前記占有要求を送信する際に、占有期間の制限時間をアプリケーションが予め指定することを特徴とする請求項23乃至26のいずれか1項に記載の情報処理装置。

請求項28

前記周辺装置から受信した情報がキャッシュ情報として既に情報処理装置内に保持されているかを判断する第1判断手段と、前記キャッシュ情報を応答するべきか否かをBidiスキーマの種別に応じて判断する第2判断手段と、を有し、占有期間において前記占有要求を発行したアプリケーションとは異なるアプリケーションから前記周辺装置の情報を取得する処理の要求を受信し、前記キャッシュ情報が保持されていると判断され、且つ、前記第2判断手段により応答すべきと判断された場合、前記キャッシュ情報を前記異なるアプリケーションに応答することを特徴とする請求項23乃至27のいずれか1項に記載の情報処理装置。

技術分野

0001

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

背景技術

0002

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

0003

近年、次世代のプリンタドライバ(v4プリンタドライバ)アーキテクチャーによる、Bidirectional(Bidi)スキーマを用いた標準的な情報送受信方法が策定された。この次世代のv4プリンタドライバのアーキテクチャーではランゲージモニターが存在しないため、自由な情報送受信制御を行うことが難しくなるおそれがあった。特許文献1には、Bidiスキーマを用いた標準的な情報送受信方法が記載されている。特に特許文献は、プリンタドライバに同されたBidi拡張ファイル、Bidi拡張JavaScript(登録商標)(Bidi拡張JS)ファイルという外部依存ファイルをOperating System(OS)のポートモニターが読み出すことを開示している。この外部依存ファイルにて、プリンタドライバを作成する各社プリンタベンダー毎ユニークな情報送受信仕様が実現される。

先行技術

0004

US公開公報 2013/0067120

発明が解決しようとする課題

0005

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

課題を解決するための手段

0006

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

発明の効果

0007

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

図面の簡単な説明

0008

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

実施例

0009

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

0010

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

0011

情報処理装置100は入力インタフェース102とCPU103、ROM104、RAM105、外部記憶装置106、出力インタフェース108、表示部107、キーボード101、マウス109、USBインタフェース110を有する。情報処理装置100は、USBインタフェース110およびUSBケーブル190を介して後述する印刷装置150と通信可能である。ROM104には初期化プログラムが入っており、外部記憶装置106にはアプリケーションプログラム群、OS(Operating System)、プリンタドライバやその他各種のデータが保存されている。RAM105は外部記憶装置106に格納される各種プログラムワークメモリとして使用する。印刷装置150はUSBインタフェース151とRAM152、プリントエンジン153、ROM154、CPU155を有する。印刷装置150は、USBインタフェース151およびUSBケーブル190を介して情報処理装置100と通信可能である。RAM152はCPU155の主メモリとワークメモリとして用いられ、受信した印刷データを一旦保存するための受信バッファーや各種のデータを保存する。プリントエンジン153はRAM152に保存されたデータに基づき印刷を行う。ここでは例として情報処理装置100と印刷装置150の処理分担を上記のように示したが、特にこの分担形態限らず他の形態であっても構わない。

0012

図2は外部記憶装置106に記憶されたプリンタドライバとOSのプリントサブシステム(Print Sub System)の構成を示すブロック図である。情報処理装置100(PC200)は、印刷装置250とUSBケーブルを介して通信可能である。

0013

まず、図2のブロック図を用いて、PC200から印刷装置250へ印刷データが渡るまでのデータの流れを説明する。印刷アプリケーション201は、OSの提供する印刷指示を行うAPIを利用し、OSへ印刷処理の要求を行う。印刷処理の要求に基づいて発行された印刷ジョブはOS内のプリントサブシステム202のスプーラ203にて処理される。スプーラ203はアプリケーション201から発行された印刷ジョブをプリントキュー204に格納する。スプーラ203はPC200内の複数の印刷アプリケーション201からの複数の印刷ジョブをプリントキュー204に格納する。スプーラ203はプリントキュー204に格納した印刷ジョブを順次v4プリンタドライバ205(以降、プリンタドライバと称す)へ送信する。ここで、印刷ジョブを印刷装置250が解釈可能な印刷データに変換するために、スプーラ203が印刷データをプリンタドライバ205に送信する処理をデスプール処理と称す。プリンタドライバ205は、印刷データを受信すると、各種フィルター206に依って、ページ構成処理コマンド生成処理を行う。前述のページ構成処理とは、アプリケーション201から指示された印刷設定情報に基づいて一つの印刷データ内のページ順序を並べ替える処理や、複数ページを用紙の1つの面に相当する物理ページに配置するための処理を指す。前述のコマンド生成処理とは、印刷ジョブを印刷装置250が解釈可能な印刷データへ変換する処理を指す。各種フィルター206による印刷ジョブを印刷データに変換する処理が完了すると、プリンタドライバ205はプリントサブシステム202内のUSBポートモニター207に印刷データを渡す。その後、USBポートモニター207は、USBデバイスインタフェース208、USBクラスドライバー209を介して、印刷データを印刷装置250に転送する。

0014

次に、図2のブロック図を用いて、PC200内のアプリケーション210が、印刷ジョブを用いず、印刷装置250に情報を書き込む又は印刷装置250から情報を読み出すデータの動きを説明する。アプリケーション210は、OSの提供するAPI(Bidiインタフェース)を利用し、印刷装置250にアクセスする。Bidiインタフェースは、OSとアプリケーション210とが、BidiスキーマというXMLで構成された設定情報を介して、双方向通信するためのインタフェースである。アプリケーション210からBidiインタフェースを介してBidiスキーマを受領したOS内のUSBポートモニター207は、Bidi拡張スキーマ定義ファイル212に従い、プリンタドライバ205のBidi拡張JS211の関数を特定し、呼び出す。なお、Bidi拡張JSは、Bidi拡張JavaScript(登録商標)の略称である。アプリケーション210は、BidiスキーマをUSBポートモニターに送信するためにBidiAPIに対して対象となる印刷装置250の識別情報を指定する。USBポートモニターは、指定された識別情報に対応する印刷装置250のプリンタドライバ205のBidi拡張スキーマ定義ファイル212を用いて処理を進めることが可能となる。USBポートモニター207が、アプリケーション210から受領したBidiスキーマを、Bidi拡張JS211の関数を呼び出す際にBidi拡張JS211に渡す。この際、USBポートモニター207は、オブジェクトもBidi拡張JS211に渡す。Bidi拡張JS211は、呼び出された関数、Bidiスキーマ、オブジェクトに基づいて、印刷装置250に対する情報の書込み・読出し処理の指示をUSBポートモニター207にフィードバックする。USBポートモニター207は、Bidi拡張JS211にBidi拡張スキーマ定義ファイル212の解釈を依頼することにより、ベンダーユニークなBidiスキーマ仕様に対応することができる。USBポートモニター207は、Bidi拡張JS211からフィードバックされた指示に従った処理を実行する。具体的には、USBポートモニター207は、Bidi拡張JS211からフィードバックされた指示に従ってUSBデバイスインタフェース208、USBクラスドライバー209を介して、印刷装置250に対して情報の書込み・読出し処理を行う。なお、本願の特徴の1つである排他処理も、Bidi拡張JS211からフィードバックされた指示に従ってUSBポートモニター207により実行される。

0015

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

0016

管理アプリケーションは、メディアリスト編集処理を開始(S301)すると、Bidiインタフェース利用を開始する(S302)。管理アプリケーションはBidiインタフェース利用開始の(S302)処理結果を判定(S303)し、失敗した場合はメディアリスト編集処理を終了(S310)する。判定S303の結果が成功だった場合、管理アプリケーションはメディアリスト取得処理(S304)を実行する。具体的な処理は図7で記載するが、S302では、管理アプリケーションがUSBポートモニターおよびBidi拡張JS(760)を占有して使用することを要求し、その要求に対する回答エラーであればS303はNoと判定される。一方、その要求に対する回答がエラーでなければS303はYesと判定される。その結果、管理アプリケーションが、USBポートモニターおよびBidi拡張JSを優先的に利用できるため、本願が想定する課題である他のアプリケーションからの割り込み等を防止できる。

0017

管理アプリケーションは処理S304で得たメディアリストを情報処理装置100の表示部107上に表示(S305)し、ユーザーはその情報を参照しメディアリストの編集作業を行う。管理アプリケーションはユーザーのメディアリスト編集完了を待ち(S306)、ユーザーが編集作業を完了したことを指示したか判定(S307)する。ユーザーが編集作業の完了を指示することで管理アプリケーションが編集完了と判断した場合、管理アプリケーションは編集されたメディアリストを印刷装置250へ書込む処理(S308)を実行する。その後、管理アプリケーションは、Bidiインタフェース利用終了処理(S309)を行い、メディアリスト編集処理を終了(S310)する。具体的な処理は図7で記載するが、S309の処理によりUSBポートモニターおよびBidi拡張JSに対する管理アプリケーションの占有期間が解除される。

0018

図3(b)は、監視アプリケーションが印刷装置250の状態情報を取得する処理を示すフローチャートである。監視アプリケーションとは、図2で示すアプリケーション210の一つに該当し、印刷装置250の状態情報を定期的に取得して、その状態を情報処理装置100の表示部107上に表示する。

0019

監視アプリケーションは、印刷装置250の情報を取得する処理(S321)を開始すると、Bidiインタフェース利用を(S322)する。監視アプリケーションはBidiインタフェース利用開始(S322)の処理結果を判定(S323)し、失敗した場合は印刷装置250の状態情報を取得する処理を終了(S326)する。判定S323の結果が成功だった場合、監視アプリケーションは、印刷装置250の状態情報を取得する処理(S324)を実行する。その後、監視アプリケーションは、Bidiインタフェース利用終了処理(S325)を行い、印刷装置250の状態情報を取得する処理を終了(S326)する。

0020

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

0021

ここで図5を用いて、ベンダーユニークなスキーマ仕様を記したBidi拡張スキーマ定義ファイル212の詳細について説明する。Bidi拡張スキーマ定義ファイル212は図5で示すとおり、XMLマークアップ言語記述されている。図5で示すBidi拡張スキーマ定義ファイルには、ExclusiveAccessON、ExclusiveAccessOFF、SetData、GetData、というスキーマがValuenameとして定義されている様子を示す。ExclusiveAccessONのBidiスキーマによって、Bidi拡張JS211およびOSのUSBポートモニター207は、ExclusiveAccessONのBidiスキーマを発行したアプリケーションに占有される。そのため、ExclusiveAccessONのBidiスキーマは占有要求と呼ぶこともできる。また、ExclusiveAccessOFFのBidiスキーマによって、Bidi拡張JS211およびOSのUSBポートモニター207は、占有処理を終了する。そのため、Bidi拡張JS211およびOSのUSBポートモニター207は、占有終了要求と呼ぶこともある。

0022

ExclusiveAccessONスキーマは、Value typeがBIDI_STRING型、accessTypeがSet、スキーマパスが¥¥Printer¥BidiControl:ExclusiveAccessONとして定義されている。ExclusiveAccessONは、Bidiインタフェース利用開始処理(S302・S322)を実行するときに利用するBidiインタフェースに指定されるスキーマである。ExclusiveAccessOFFスキーマは、Value typeがBIDI_STRING型、accessTypeがSet、スキーマパスが¥¥Printer¥BidiControl:ExclusiveAccessOFFとして定義されている。ExclusiveAccessOFFは、Bidiインタフェース利用終了処理(S309・S325)を実行するときに利用するBidiインタフェースに指定されるスキーマである。SetDataスキーマは、Value typeがBIDI_STRING型、accessTypeがSet、スキーマパスが¥¥Printer¥Extension:SetDataとして定義されている。SetDataは、メディアリスト取得処理(S304)、メディアリスト書込み処理(S308)、印刷装置250の状態情報取得処理(S324)において、要求情報を印刷装置250に書き込むときに利用されるスキーマである。このSetDataスキーマが、上記処理のためにBidiインタフェースに指定される。SetDataスキーマを用いて、図6に示すようなメディアリスト要求コマンド(図6(a))や、印刷装置250状態情報要求コマンド(図6(b))、メディア情報設定コマンド(図6(c))を印刷装置250に書き込むことができる。GetDataスキーマは、Value typeがBIDI_STRING型、accessTypeがGet、スキーマパスが¥¥Printer¥Extension:GetDataとして定義されている。GetDataは、メディアリスト取得処理(S304)、メディアリスト書込み処理(S308)、状態情報取得処理(S324)において、印刷装置250から応答情報を取得するときに利用されるスキーマである。このGetDataスキーマが、上記処理のためにBidiインタフェースに指定される。SetDataスキーマにて図6(a)のメディアリスト要求コマンドを印刷装置250に書き込んだ後、GetDataスキーマを用いることで図6(d)に示すようなメディアリスト応答情報を印刷装置250から取得することができる。ここでは本実施形態の説明に必要なスキーマしか記載していないが、例えば印刷装置の能力情報取得用スキーマ等、その他の機能に応じて定義しておく必要があることはいうまでもない。

0023

図4(a)は、Bidiインタフェースによってスキーマを受領したUSBポートモニター207により呼び出されたBidi拡張JS211のスキーマ判定処理を示すフローチャートである。OSは、アプリケーションから受信したBidiスキーマの内容を理解できない。そのため、USBポートモニター207が、オブジェクトと、アプリケーション210から受領したBidiスキーマの両者を、Bidi拡張JS211の関数を呼び出す際にBidi拡張JS211に渡す。この処理により図4(a)−(e)の処理が開始される。

0024

Bidi拡張JS211はスキーマ判定処理を開始(S401)すると、受領したスキーマのスキーマ名(Value name)を判定する(S402)。Bidi拡張JS211は、S402において判定されたスキーマ名が排他開始(ExclusiveAccessON)か否かを判定(S403)する。判定(S403)の結果がYesの場合、Bidi拡張JS211は排他開始処理(S404)を実行した後に処理を終了(S411)する。なお、S404の詳細な説明は図4(b)に記載する。判定(S403)の結果がNoの場合、Bidi拡張JS211はスキーマ名が排他終了(ExclusiveAccessOFF)か否かを判定(S405)する。判定(S405)の結果がYesの場合、Bidi拡張JS211は排他終了処理(S406)を実行した後に処理を終了(S411)する。なお、S406の詳細な説明は図4(c)に記載する。判定(S405)の結果がNoの場合、Bidi拡張JS211はスキーマ名が情報送信(SetData)か否かを判定(S407)する。判定(S407)の結果がYesの場合、Bidi拡張JS211は情報送信処理(S408)を実行した後に処理を終了(S411)する。なお、S408の詳細な説明は図4(d)に記載する。判定(S407)の結果がNoの場合、Bidi拡張JS211はスキーマ名が情報受信(GetData)か否かを判定(S409)する。判定(S409)の結果がYesの場合、Bidi拡張JS211は情報受信処理(S410)を実行した後に処理を終了(S411)する。なお、S410の詳細な説明は図4(e)に記載する。判定(S409)の結果がNoの場合、Bidi拡張JS211は処理を終了(S411)する。

0025

図4(b)は、Bidi拡張JS211の排他開始処理(S404)の詳細を示すフローチャートである。

0026

Bidi拡張JS211は排他開始処理を開始(S421)すると記憶領域(S423)を参照し、排他状態を確認(S422)する。処理(S422)は、具体的にはBidi拡張JSがOSから渡された情報を参照することにより、実現する。OSから渡された情報とは、OSから渡されるオブジェクトに含まれる排他状態を示すプロパティであってもよいし、オブジェクトに含まれるメソッドを実行した結果で得られる情報であってもよい。

0027

上述したように図4(b)−(e)の処理は、USBポートモニター207が、オブジェクトと、アプリケーション210から受領したBidiスキーマの両者を、Bidi拡張JS211の関数を呼び出す際にBidi拡張JS211に渡すことで実現される。つまり、Bidi拡張JS211は、OSから渡されたオブジェクトを用いて処理を実行する。

0028

以降、図4(b)−(e)において、OSから渡されたオブジェクトを用いて実行される処理を“OSから渡されたオブジェクトを介した処理”と表現する。

0029

Bidi拡張JS211は排他開始済みかを判定(S424)し、既に排他されていた場合、処理を終了(S426)する。なお、S424において排他開始済みと判定された判定された場合、既に排他されていることを示す情報がBidi拡張JS211によりフィードバックとしてOSに通知される。このフィードバックを受けて、OSはBidiスキーマを発行したアプリケーションに既に排他されていることを示す情報を通知する。判定(S424)にて、未だ排他されていないと判断した場合、Bidi拡張JS211はOSを介して記憶領域(S423)に排他状態を設定(S425)し、処理を終了(S426)する。なお、処理(S425)は、OSから渡されたオブジェクトを介した処理である。つまり、S424において排他されていないと判断された場合(S424−No)、Bidi拡張JS211が、OSの排他処理実行APIに実行を指示することでOSが排他状態を記憶領域に書き込む。この処理により、OSのUSBポートモニターが、排他要求元のアプリケーションに占有される。なお、記憶領域には、排他開始したプロセスに関する情報(例えば、プロセスID)も記憶される。

0030

図4(c)は、Bidi拡張JS211の排他終了処理(S406)の詳細を示すフローチャートである。

0031

Bidi拡張JS211は排他終了処理を開始(S431)すると、記憶領域(S433)を参照し、排他状態を確認(S432)する。なお、処理(S432)は、OSから渡されたオブジェクトを介した処理である。

0032

Bidi拡張JS211は、記憶領域(S433)に記録された排他開始したプロセスと、排他終了処理(S431)を実行したプロセスとを比較(S434)し、一致しているかを判定(S435)する。プロセスを識別する方法として、Bidiインタフェースを呼び出したアプリケーションのプロセスIDを用いて識別してもよい。また別の識別方法としては、アプリケーションがユニークなIDをBidiインタフェースのパラメータの一つとして設定し、設定されたIDを用いて識別されてもよい。つまり、S435の処理が、占有要求元のアプリケーションと占有終了要求元のアプリケーションが同一であるか否かの判定処理となる。

0033

判定(S435)にてNoと判断した場合、Bidi拡張JS211は処理を終了(S437)する。なお、S435においてNoと判定された場合、Bidi拡張JS211が排他終了処理に失敗した旨をフィードバックとしてOSに通知する。このフィードバックを受けて、OSはBidiスキーマの発行元に排他終了処理に失敗した旨を通知する。

0034

判定(S435)にてYesと判断した場合、Bidi拡張JS211は記憶領域(S433)の排他状態情報を削除するよう設定(S436)した後に処理を終了(S437)する。そしてOSが、S436において設定された内容に従って排他状態情報を削除する。なお、処理(S436)は、OSから渡されたオブジェクトを介した処理である。つまり、S435において一致する判断された場合(S435−Yes)、Bidi拡張JS211が、OSの排他処理実行APIに占有状態の終了を指示することでOSが排他状態情報を削除する。この処理により、OSのUSBポートモニター207の占有状態が解除される。

0035

図4(d)は、Bidi拡張JS211の情報送信処理(S408)の詳細を示すフローチャートである。

0036

Bidi拡張JS211は情報送信処理を開始(S441)すると、記憶領域(S443)を参照し、排他状態を確認(S442)する。なお、処理(S442)は、OSから渡されたオブジェクト介した処理である。Bidi拡張JS211は、記憶領域(S443)に記録された排他開始したプロセスと、情報送信処理(S441)を実行したプロセスとを比較し、一致しているかを判定(S445)する。なお、判定処理は、図4(c)のS435と類似しているため詳細な説明は省略する。判定(S445)にてNoと判断した場合、Bidi拡張JS211は処理を終了(S447)する。S445においてNoと判定された場合、Bidi拡張JS211が他のアプリケーションにより占有状態のため情報送信処理できない旨をフィードバックとしてOSに通知する。このフィードバックを受けて、OSはBidiスキーマの発行元に情報送信処理できない旨を通知する。判定(S445)にてYesと判断した場合、Bidi拡張JS211は印刷装置250に対する情報送信処理の実施を指示(S446)した後に処理を終了(S447)する。つまり、S445において一致する判断された場合(S445−Yes)、Bidi拡張JS211が、OSに対して情報送信処理の実行を指示することでOSが印刷装置に対して情報の送信を実行する。例えば、管理アプリケーションにより編集されたメディアリストが印刷装置に送信される。なお、処理(S446)は、OSから渡されたオブジェクトを介した処理である。ここで、判定(S445)において記憶領域(S443)に排他開始情報が存在していなかった場合も、Bidi拡張JS211は情報送信処理(S446)を実行する。これは印刷装置250へのアクセス処理において排他状態を維持することが不要なアプリケーションのための措置である。

0037

図4(e)は、Bidi拡張JS211の情報送信処理(S410)の詳細を示すフローチャートである。

0038

Bidi拡張JS211は情報送信処理を開始(S451)すると、記憶領域(S453)を参照し、排他状態を確認(S452)する。なお、処理(S452)が、OSから渡されたオブジェクトを介した処理である。Bidi拡張JS211は、記憶領域(S453)に記録された排他開始したプロセスと、情報受信処理(S451)を実行したプロセスとを比較(S454)し、一致しているかを判定(S455)する。なお、判定処理は、図4(c)のS435と類似しているため詳細な説明は省略する。

0039

判定(S455)にてNoと判断した場合、Bidi拡張JS211は処理を終了(S457)する。S455においてNoと判定された場合、Bidi拡張JS211が他のアプリケーションにより占有状態のため情報受信処理に失敗した旨をフィードバックとしてOSに通知する。このフィードバックを受けて、OSはBidiスキーマの発行元に情報受信処理ができない旨を通知する。判定(S455)にてYesと判断した場合、Bidi拡張JS211は印刷装置250に対し情報受信処理の実行を指示(S456)した後に処理を終了(S457)する。つまり、S455において一致する判断された場合(S445−Yes)、Bidi拡張JS211が、OSに対して情報受信処理の実行を指示することでOSが印刷装置から情報の受信処理(取得処理)を実行する。例えば、印刷装置の機能情報や、印刷装置の状態情報が取得される。なお、処理(S456)は、OSから渡されたオブジェクトを介した処理である。ここで、判定(S455)において記憶領域(S453)に排他開始情報が存在していなかった場合も、Bidi拡張JS211は情報送信処理(S456)を実行する。これは印刷装置250へのアクセス処理において排他状態を維持することが不要なアプリケーションのための措置である。

0040

図4の処理によりBidi拡張JS211が、Bidiスキーマを送信したアプリケーション210に占有され、他のアプリケーションの使用が制限されるため、本願の課題を解決することが可能となる。

0041

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

0042

アプリケーションA(700)とは、例えば図3(a)を用いて説明した管理アプリケーションである。管理アプリケーション(700)は、Bidi利用開始処理(701・S302)を実行する。Bidi利用開始処理(701)によって、USBポートモニター(760)は、Bidi拡張JS(760)により実行される図4の処理のフィードバックとして排他開始処理の指示を受ける(S425)。その結果、USBポートモニター(760)は、排他開始処理(761)を実行する。なお、Bidi拡張JSは、排他処理に成功した旨を管理アプリケーション(700)に応答する。よって、管理アプリケーションが、占有要求元のアプリケーションとなる。

0043

アプリケーションB(720)とは、例えば図3(b)を用いて説明した監視アプリケーションである。監視アプリケーション(720)は、印刷装置250の状態情報を取得しようと、Bidi利用開始処理(721・S322)を実行する。これにより、監視アプリケーションは、印刷装置の状態情報の取得の実行要求を行う。しかし、USBポートモニターは、管理アプリケーション(700)によるUSBポート占有期間中(762)となっている。そのため、USBポートモニターは、Bidi拡張JS(760)により実行される図4の処理(排他開始済みである判定(S424−Yes))のフィードバックとして排他されていることを受け付ける。その結果、USBポートモニターは、監視アプリケーションに対し占有処理エラー応答処理(763)を行う。なお、エラー応答を受信した監視アプリケーション(720)は、占有できなかったことを示すエラー画面を表示しても良い。若しくは、監視アプリケーション(720)は、任意の一定時間を置いてBidi利用開始処理(721)を再試行してもよい。

0044

アプリケーションC(730)とは、Bidiに依る情報送受信を実行するアプリケーション(210)の一つであるが、Bidi利用開始宣言を行わないアプリケーションである。アプリケーションC(730)は、BidiによるWrite/Read処理(731)を実行する。しかし、管理アプリケーションによるUSBポート占有期間(762)となっている。そのため、USBポートモニターは、Bidi拡張JS(760)により実行される図4の処理(S445若しくはS455にて不一致の判定)のフィードバックとして排他されているため情報送受信できないことを受け付ける。その結果、USBポートモニターは、アプリケーションCに対しエラー応答処理(764)を行う。なお、このときアプリケーションCが要求した情報に対する応答情報のキャッシュデータが既に用意されていれば、USBポートモニター(760)はアプリケーションCにキャッシュ情報を応答(764)してもよい。つまり、USBポートモニター(760)は、キャッシュ情報が既に保存されているか否かを判断する。さらに、Bidi拡張JS(760)が、Write/Read要求を受けたBidiスキーマの種別に応じて、キャッシュ情報を応答(764)するか否かを判断してもよい。具体的には、能力情報(Capability)の取得要求であれば、Bidi拡張JS(760)が、キャッシュ情報を応答すると判断し、状態情報(Status)の取得要求であれば、キャッシュ情報を応答しないと判断する。

0045

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

0046

アプリケーションD(740)とは、印刷アプリケーション(201)の一つである。アプリケーションDが、ユーザーの印刷指示に従って印刷ジョブを発行する(741)と、スプーラ及び印刷キュー(750)は印刷ジョブを受領(751)する。しかし、管理アプリケーション(700)によるUSBポート占有期間中(762)となっているため、スプーラ(750)はUSBポートの占有状態が解除されるまで印刷ジョブのデスプールを待ち(752)、印刷キューに留めておく。

0047

監視アプリケーション(720)、アプリケーションC(730)、スプーラのデスプール(750)によるUSBポート利用の制限を実施している間、管理アプリケーション(700)は、Write/Read処理(702・S446・S456)を実行する。Write/Read処理(702・S446・S456)とは、メディアリスト取得処理(S304)や、メディアリスト書込み処理(S308)を指す。管理アプリケーション(700)はUSBポートの利用を占有している状態にあるため、Write/Read処理(702・S446/S456)を複数回繰り返すことが可能である。さらには、印刷ジョブやその他のアプリケーションに割り込まれる懸念はない。なお、管理アプリケーション(700)は、Write/Read処理(702・S446/S456)を複数回繰り返す場合に、Bidi利用開始処理(701・S302)を実行する。一方、管理アプリケーション(700)は、Write/Read処理(702・S446/S456)を1回のみ実行する場合、Bidi利用開始処理(701・S302)を実行しなくても良い。

0048

Write/Read処理(702・S446・S456)を受けて(765)、USBポートモニター及びBidi拡張JS(760)は、印刷装置(780・250)に対しWrite/Read処理(766)を実施する。印刷装置(780・250)は、USBポートモニター(760・207)からの、Write/Read処理(766)の要求を受けて、要求に対するデータを応答する(781)。ここで、USBポートモニター(760・207)の要求が、図6(a)に示すメディアリスト取得要求である場合、応答するデータ(861)は図6(d)に示すメディアリスト応答情報である。印刷装置(780・250)からの応答(781)は、USBポートモニター及びBidi拡張JS(760)を経由して、管理アプリケーション(700)に渡る。管理アプリケーション(700)は、Bidiインタフェースの利用が終わると、Bidi利用終了処理(703・S309)を実行する。Bidi利用終了処理(703)によって、USBポートモニターおよびBidi拡張JS(760)は、排他終了処理(767・S436)を実行することで管理アプリケーション(700)によるUSBポート占有期間(762)を解除する。そして、USBポートモニターおよびBidi拡張JS(760)は、Bidi利用終了処理(703・S309)が成功した旨を管理アプリケーション(700)に応答する。よって、管理アプリケーションが、占有終了要求元のアプリケーションとなる。

0049

以上示した通り、管理アプリケーション(700)はBidi利用開始(701)を宣言することにより、各種割込み処理(721・731・752)を制限することが可能となる。また、図7の767の排他終了処理により、アプリケーションBのBidi利用開始処理が可能となり、プリントキューに保持されていた印刷ジョブのデスプール処理が、図7の767の排他終了処理により開始される。

0050

なお、アプリケーションA(700)がBidi利用終了処理(703)を行わないまま、終了してしまうケースも考えられる。上記ケースに備えて、第一の例としては、USBポートモニター(760・207)はアプリケーションA(700)からのBidi利用が一定時間無い場合には、排他状態を解除してもいい。第二の例としては、USBポートモニター(760・207)はアプリケーションA(700)がPC上に存在しないことを確認した場合には、排他状態を解除してもいい。第三の例としては、アプリケーションA(700)がBidi利用開始処理(701)を行う際に、タイムアウト時間(占有期間の制限時間)をUSBポートモニタ(760)に伝える処理を行ってもよい。その際、アプリケーションAは、ユーザーの指示に従って占有期間の制限時間の設定を、Bidi利用開始処理の前に実行する。そして、USBポートモニターの排他処理時間がタイムアウト時間(所定の時間)を経過した場合、USBポートモニターは、アプリケーションAから排他終了要求を受ける前であっても、排他処理を終了する。

0051

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

0052

<実施形態2>
実施形態1はアプリケーションがBidi利用開始を宣言することにより、他のアプリケーションから割り込まれることを防止し、その間にBidiインタフェースを利用しWrite/Readする手段を示した。実施形態2においては、アプリケーションがBidi利用開始を宣言することにより、他のアプリケーションから割り込まれることを防止し、その間にUSBデバイスインタフェース208に対し直接Write/Readする手段を説明する。

0053

図8はアプリケーションとOSと印刷装置の全体的な処理の流れを示すシーケンス図である。図8を以て、アプリケーションがUSBを占有する間に、アプリケーションが直接USBデバイスインタフェースを利用する流れを説明する。アプリケーション(800)とは、例えば図3(a)を用いて説明した管理アプリケーションである。

0054

管理アプリケーション(800)は、Bidi利用開始処理(801・S302)を実行する。Bidi利用開始処理(801)によって、USBポートモニターは、Bidi拡張JS(820)のフィードバックとして排他開始処理(821・S425)に成功した旨を受ける。このフィードバックを受けて、USBポートモニターは、管理アプリケーション(800)に排他に成功した旨を応答する。排他開始処理(821)を実行したことにより、管理アプリケーション(800)はUSBポート占有期間(822)を設ける。

0055

その他のアプリケーションやスプーラのデスプールによるUSBポート利用の制限を実施している間、管理アプリケーション(800)は、Write/Read処理(802)を実行する。Write/Read処理(802)とは、USBデバイスインタフェース(840・208)をOpenし、直接データをWrite/Readする処理である。処理(802)を受けて(841)、USBデバイスインタフェース(840・208)は、印刷装置(860・250)に対しWrite/Read処理(842)を実施する。印刷装置(860・250)は、USBデバイスインタフェース(840・208)からの、Write/Read処理(766)の要求を受けて、要求に対するデータを応答する(861)。ここで、USBデバイスインタフェース(840・208)の要求が、図6(a)に示すメディアリスト取得要求である場合、応答するデータ(861)は図6(d)に示すメディアリスト応答情報である。印刷装置(860・250)からの応答(861)は、USBデバイスインタフェース(840・208)を経由して、管理アプリケーション(800)に渡る。管理アプリケーション(800)は、Bidiインタフェースの利用が終わると、Bidi利用終了処理(803・S309)を実行する。Bidi利用終了処理(803)によって、Bidi拡張JS(820)からフィードバックとして排他終了処理の実行がUSBポートモニターに通知される。紺フィードバックを受けて、USBポートモニターは、管理アプリケーション(800)によるUSBポート占有期間(822)を解除する。そして、USBポートモニター(820)は、Bidi利用終了処理(803・S309)が成功した旨を管理アプリケーション(800)に応答する。

0056

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

0057

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

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

  • 富士通クライアントコンピューティング株式会社の「 情報処理システムおよび中継装置」が 公開されました。( 2020/10/29)

    【課題】情報処理システムの正常性を確保する。【解決手段】第1情報処理装置2Aの更新制御部40Aは、中継装置3に設けられた電源制御マイコン302のファームウェアを更新する。第1情報処理装置2Aの再起動通... 詳細

  • セイコーエプソン株式会社の「 印刷装置」が 公開されました。( 2020/10/29)

    【課題】筐体部の内側に異物が侵入することを抑制する。【解決手段】印刷領域に位置する媒体に印刷を行う印刷部6と、印刷部6を収容し、印刷領域を覆う筐体部32と、媒体を支持可能であり、筐体部32の外側の位置... 詳細

  • 紫光華山信息技術有限公司の「 オペレーティングシステムのインストール」が 公開されました。( 2020/10/29)

    【課題・解決手段】本発明は、オペレーティングシステムをインストールするための方法及び装置を提供する。当該方法の一例示によると、仮システムにおいて、磁気ディスクアレイRAIDをユーザが指定する操作に応じ... 詳細

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ