JP5294892B2 - 画像形成装置、装置、制御方法、及びプログラム - Google Patents

Description

本発明は、周辺装置をアプリケーションによって制御する画像形成装置及び制御方法及びプログラムに関する。特に複数のアプリケーションが共通のデバイスドライバを利用して周辺装置を制御する画像形成装置に関する。

多機能化された複合機は、様々な機能を有する。その１つの機能として、ユーザが複合機を購入した後で、好きなアプリケーションをインストールする仕組みが存在する。この仕組みは、ユーザの環境に合わせて複合機の機能をカスタマイズする目的で利用されることが多い。これらのアプリケーションは、ＵＳＢデバイスのような外付け装置の機能を利用する場合がある。この場合、ＵＳＢデバイスの振る舞いを制御するいくつかの種類のデバイスドライバが存在する。ここでその種類を説明する。但し、これらの用語は、一般に広く知られているものではない。

１つは、汎用クラスドライバである。ここでのクラスとは、ＵＳＢデバイスが提供する機能によってグループ分けされたカテゴリのことである。汎用クラスとは、その中で後述するベンダ固有クラスを除いたクラスのことを指している。汎用クラスドライバとは、汎用クラスに属するＵＳＢデバイスの振る舞いを制御するためのデバイスドライバを示す。この汎用クラスドライバが存在するため、ＵＳＢデバイスを開発するベンダはデバイスドライバの開発効率が良くなるというメリットがある。これに対し、該当する汎用クラスに定義されていない機能を提供したい場合には、ベンダが独自に機能を提供するためのデバイスドライバを開発する必要がある。汎用クラスドライバの具体的な例として、ＨＩＤクラスドライバ、Ｍａｓｓ Ｓｔｏｒａｇｅクラスドライバなどが挙げられる。一般的には、Ｗｉｎｄｏｗｓ（登録商標）やＬｉｎｕｘなどのＯＳが提供する。

もう１つは、ベンダ固有ドライバである。ベンダとは、ＵＳＢデバイスを開発する開発元のことを指す。ベンダ固有のドライバとは、前述の汎用クラスに属さないＵＳＢデバイスの振る舞いを制御するための、ベンダが独自に開発した専用のデバイスドライバを示す。ベンダが提供する機能に対して自由に振る舞いの定義が可能な反面、ＯＳのバージョンが変わるとデバイスドライバもそれに合わせて再作成が必要となるといった欠点もある。

最後は、共通デバイスドライバである。共通デバイスドライバは、Ｗｉｎｄｏｗｓ（登録商標）やＬｉｎｕｘなどの一般的なＯＳには存在しない概念であり、前述のアプリケーションがＵＳＢデバイスの振る舞いを自由に制御するためのデバイスドライバである。前述のベンダ固有ドライバとは異なり、ＵＳＢデバイスの振る舞いを制御するロジックをデバイスドライバではなくアプリケーションに持つ。性能ではベンダ固有ドライバに劣るものの、ＯＳのバージョンに依存しないスケーラビリティを持つことができる。

続いて、これらのデバイスドライバの中から、適切なデバイスドライバを選択する際の簡単な流れを説明する。なお、あるＵＳＢデバイスに対応してデバイスドライバを選択し、その制御を任せることを、デバイスドライバをロードすると表現する。あるＵＳＢドライバが情報機器に接続された場合に、ＯＳが適切なデバイスドライバを探索する。汎用クラスドライバとベンダ固有ドライバは、自らがサポートするＵＳＢデバイスを識別するための識別子をＯＳに登録している。従って、ＯＳは接続されたデバイスの識別子に対応するドライバを選択し、ロードする。これに対し、共通デバイスドライバは自らがサポートするデバイスを特定できないため、何の情報もＯＳに登録しない。ＯＳはＵＳＢドライバの接続を検知すると、ベンダ固有ドライバ、汎用クラスドライバの順に該当するデバイスドライバがあるかチェックする。

一般的なＯＳの代表であるＷｉｎｄｏｗｓ（登録商標）では、共通デバイスドライバを備えていない。そのため、登録された汎用クラスドライバもしくはベンダ固有ドライバの中から該当するデバイスドライバが見つからない場合には、適切なデバイスドライバを新たにインストールするためのウィザード画面を表示する仕様となっている。また、Ｌｉｎｕｘも同様に共通デバイスドライバを備えないため、登録された汎用クラスドライバもしくはベンダ固有ドライバの中から該当するデバイスドライバが見つからない場合には、デバイスドライバが何も選択されない仕組みになっている。

共通デバイスドライバを備えるプラットフォームの例としては、Ｊａｖａ（登録商標）を用いて実装された複合機専用アプリケーションプラットフォームがある。このプラットフォームにおいては、インストールされたデバイスに該当するデバイスドライバが見つからない場合には、必ず共通デバイスドライバがロードされる仕組みになっている。

デバイスドライバ選択の従来技術として、特許文献１がある。特許文献１では、デバイスドライバとデバイス識別子の関係を記述したデバイスドライバ登録情報を持ち、この情報に従ってデバイスに対してデバイスドライバを選択するディスパッチデバイスドライバを備える。特許文献１によれば、デバイスドライバ登録情報への新規ドライバ追加や、関係の変更が可能である。
特開平１０−２７１４９号公報

前述の共通デバイスドライバを介してＵＳＢデバイスを制御するアプリケーションが、汎用クラスのデバイスに対して特殊な制御を行いたいケースがある。例えば、ＨＩＤクラスで実装された磁気カードリーダを認証用デバイスとして利用したい場合に、他のアプリケーションに通信内容が通知されないようにしたい、などの要望が具体的な例として挙げられる。別の例として、Ｍａｓｓ Ｓｔｏｒａｇｅクラスで実装されたメモリデバイスに特別な暗号化領域を設けたい場合が考えられる。これらの要望に対してベンダ固有ドライバを新規に実装する案が考えられる。しかし、ベンダ固有ドライバの実装はＯＳのカーネルへの依存性が高く、可搬性に乏しい。また、ベンダ固有ドライバはカーネルモードで動作することになるため、当該ドライバを入れ替え可能な手段を提供することは装置の利用に伴うセキュリティレベルを低下させる危険性をはらむこととなる。こういった理由により、ベンダ固有ドライバの利用が現実的には解決策となりえない事情がある。

こういった要望を満たすためには、共通デバイスドライバが選択され、利用されることが望ましい。しかし、前述のデバイスドライバ選択のロジックによれば、共通デバイスドライバよりも優先度の高い汎用クラスドライバが新規にインストールされたデバイスに対応するものとして登録されていると、それが優先的に選択され、ロードされてしまうため、アプリケーションで制御することができない。このような問題に対し、単純な解決方法として、汎用クラスドライバを無効化するスイッチを用意する方法が考えられる。しかし、この方法を用いると、他の汎用クラスのＵＳＢデバイスを利用できなくなるため、望ましい解決方法ではない。

別の解決方法として、共通デバイスドライバをベンダ固有ドライバとして登録する構成も考えられる。しかし、アプリケーションが制御するＵＳＢデバイスの情報が共通デバイスドライバからは不明であるため、共通デバイスドライバはＯＳに自らがサポートするＵＳＢデバイスを識別するための識別子を登録することができない。更に、Ｌｉｎｕｘ ＯＳにおいては、その仕様として、１つのデバイスドライバを、２つ以上の異なる優先度でＯＳに登録できないという制約がある。そのため、共通デバイスドライバをベンダ固有ドライバとして登録すると、該当するデバイスドライバが登録されていない他のＵＳＢデバイスに対して、共通デバイスドライバを選択するための登録ができなくなる。その結果、他のアプリケーションがＵＳＢデバイスを制御できない問題がある。

以上述べてきたように、共通デバイスドライバを介してＵＳＢデバイスを制御するアプリケーションが、汎用クラスのデバイスに対して特殊な制御を行いたいケースを考慮して、共通デバイスドライバを優先的に選択させることが可能な仕組みが求められている。

前述の課題を解決するために、本発明は以下の構成を有する。すなわち、登録されたドライバの情報を管理し、登録されたドライバをロードするオペレーティングシステムと、周辺装置の動作を制御するための汎用クラスドライバと、周辺装置の動作を制御するロジックを有するアプリケーションが当該周辺装置を制御する際に利用する共通デバイスドライバと、を有する画像形成装置であって、前記アプリケーションが制御を行う周辺装置の識別情報を前記共通デバイスドライバに付与する付与手段と、周辺装置が前記画像形成装置に接続された際に当該周辺装置を制御するために利用する共通デバイスドライバであって当該周辺装置の識別情報が付与された共通デバイスドライバが当該周辺装置を制御するための汎用クラスドライバよりも優先的に利用されるように、前記オペレーティングシステムに対しドライバの情報を登録する登録手段とを有する。

本発明によれば、前述の共通デバイスドライバを介してＵＳＢデバイスを制御するアプリケーションが、所望するＵＳＢデバイスを予め指定しておくことにより制御できるようになる。同時に、特定のＵＳＢデバイスが所望するデバイスドライバがＯＳ内に存在しない場合に、従来通り共通デバイスドライバがロードされ、アプリケーションから制御できる。

＜実施形態１＞
以下、本発明を実施するための最良の形態について図面を用いて説明する。本発明を実施するための第一の実施形態について説明する。図１は、本発明における画像形成装置のハードウェア構成の一例を示す図である。本発明が適用可能な装置として、画像形成装置１０１を示す。ＣＰＵ１１０は、プログラムの実行や、様々な処理の制御を行う。不揮発性メモリ１１１は、ＲＯＭから構成され、画像形成装置１０１の起動処理において初期段階に必要なプログラムやデータが格納されている。揮発性メモリ１１２は、ＲＡＭから構成され、プログラム、データの一時的な格納場所として利用される。補助記憶装置１１３は、ハードディスクやＲＡＭドライブ等の大容量記憶装置から構成され、大容量データの保管、プログラムの実行コードの保持を行う。揮発性メモリ１１２と比較して、長時間保持する必要があるデータを記憶する。本実施形態においては、各ソフトウェアを保持する。ディスプレイ１１４は、画像形成装置１０１を利用するユーザに情報を表示して伝えるための装置である。なお、ここでのユーザとは、全て画像形成装置１０１の利用者を示すものとする。入力装置１１５は、ユーザの選択指示を受付け、内部バス１２０を介してプログラムに伝達するための装置である。ＵＳＢホストコントローラ１１６は、後述するＵＳＢケーブル１３０を介してＵＳＢデバイス１４０と通信・制御を行うための装置である。内部バス１２０は、ＣＰＵ１１０、不揮発性メモリ１１１、揮発性メモリ１１２、補助記憶装置１１３、ディスプレイ１１４、入力装置１１５、ＵＳＢホストコントローラ１１６を画像形成装置１０１内で通信可能な状態に接続する通信バスである。ＵＳＢケーブル１３０は、ＵＳＢホストコントローラ１１６と後述するＵＳＢデバイス１４０を物理的につなぎ通信を可能とするためのケーブルである。ＵＳＢデバイス１４０は、画像形成装置１０１と通信を行い、特定の機能を提供するための外付け装置である。例として、キーボードやマウス、ストレージ装置、磁気カード読取装置、ＩＣカード読取装置、生体認証装置などが挙げられるが、これらに限定されるわけではなく、ＵＳＢケーブル１３０にて接続される機器が該当する。

図２は、本発明の実施形態を説明するためのソフトウェア構成図である。図２に登場する各手段は、不揮発性メモリ１１１、揮発性メモリ１１２、補助記憶装置１１３のいずれかの記憶手段に記憶され、ＣＰＵ１１０により実行される。アプリケーション２０１は、ＵＳＢデバイス１４０を制御するためのソフトウェアである。後述する共通インタフェース２１３を介して制御を行う。アプリケーション２０２は、ＵＳＢデバイス１４０を制御するためのソフトウェアである。後述する汎用クラスドライバ２１６を介して制御を行う。アプリケーション２０３は、ＵＳＢデバイス１４０を制御するためのソフトウェアである。後述するベンダ固有ドライバ２１７を介して制御を行う。上述したアプリケーション２０１、２０２、２０３は、それぞれ違う経路でＵＳＢデバイス１４０を制御するため、３つに区分して説明している。なお、アプリケーション２０１、２０２、２０３に共通の特徴を説明する場合には、単純にアプリケーションと表記する。インストーラ２１１は、アプリケーションを画像形成装置１０１にインストールもしくはアンインストールするための手段である。インストールもしくはアンインストールする際に、インストーラ２１１は各アプリケーションが有する特徴を示す設定ファイルをチェックする。

設定ファイルの具体的な例を図７に示す。設定ファイル７０１には、複数の項目を記述することができる。図７で示した例においては、“Ｂｕｎｄｌｅ−Ｖｅｎｄｏｒ”、“Ｂｕｎｄｌｅ−Ｖｅｒｓｉｏｎ”、“Ｂｕｎｄｌｅ−Ａｃｔｉｖａｔｏｒ”、“Ｂｕｎｄｌｅ−Ｎａｍｅ”、“Ａｐｐｌｉｃａｔｉｏｎ−Ｉｄ”、“ＲｅｓｅｒｖｅｄＵＳＢＤｅｖｉｃｅｓ”の６項目が記述されている。“Ｂｕｎｄｌｅ−Ｖｅｎｄｏｒ”は、アプリケーションの開発元の情報を示す。“Ｂｕｎｄｌｅ−Ｖｅｒｓｉｏｎ”は、アプリケーションのバージョンを示す。“Ｂｕｎｄｌｅ−Ａｃｔｉｖａｔｏｒ”は、アプリケーションの起動クラスを示す。“Ｂｕｎｄｌｅ−Ｎａｍｅ”は、アプリケーションの名称を示す。“Ａｐｐｌｉｃａｔｉｏｎ−Ｉｄ”は、アプリケーション識別子を示す。異なるアプリケーションは、必ず異なる“Ａｐｐｌｉｃａｔｉｏｎ−Ｉｄ”を有する。最後に、“ＲｅｓｅｒｖｅｄＵＳＢＤｅｖｉｃｅｓ”は、アプリケーションが制御するＵＳＢデバイスを識別するための情報を示す。ＵＳＢデバイスを一意に識別可能とするための情報として、２つの識別子の組み合わせを用いている。すなわち、ＵＳＢデバイスの開発ベンダを示す２バイトの数字と、ＵＳＢデバイスのプロダクト識別子を示す２バイトの数字の組み合わせである。ここで、ＵＳＢデバイスの開発ベンダを示す２バイトの数字とは、ＵＳＢデバイスが備えるＤｅｖｉｃｅ Ｄｅｓｃｒｉｐｔｏｒの“ｉｄＶｅｎｄｏｒ”フィールドの値を指している。同様に、ＵＳＢデバイスのプロダクト識別子を示す２バイトの数字とは、ＵＳＢデバイスが備えるＤｅｖｉｃｅ Ｄｅｓｃｒｉｐｔｏｒの“ｉｄＰｒｏｄｕｃｔ”フィールドの値を指している。図７の例では、０ｘ０４Ａ９、０ｘ２６８０、０ｘ０４Ａ９、０ｘ２６８１、０ｘ０４Ａ９、０ｘ２６８２という３つのＵＳＢデバイスを定義している。つまり、０ｘ０４Ａ９のベンダ識別子を有するベンダが開発したＵＳＢデバイス（０ｘ２６８０、０ｘ２６８１、０ｘ２６８２）が定義されている。

インストーラ２１１は、設定ファイルの“Ａｐｐｌｉｃａｔｉｏｎ−Ｉｄ”に記載された“ＲｅｓｅｒｖｅｄＵＳＢＤｅｖｉｃｅｓ”に宣言された識別子を読み取り、前述の共通デバイスドライバ管理２１２に通知する。インストールする際は、通知した情報を後述する対象デバイスリストに追加するよう依頼する。アンインストールする際は、通知した情報を対象デバイスリストから削除するよう依頼する。共通デバイスドライバ管理２１２は、前述のインストーラ２１１から通知された情報を、後述する対象デバイスリスト２２１のファイルに更新する手段である。ここで対象デバイスリスト２２１の例を図６に示す。対象デバイスリスト２２１は、ファイルシステム上のファイルとして構成され、図６に示すような複数のフィールドを持つレコードの集合として実現される。アプリケーションＩＤ６０１は、アプリケーションを一意に識別する識別子を示す。図７で説明した“Ａｐｐｌｉｃａｔｉｏｎ−Ｉｄ”に相当する。ＵＳＢデバイスベンダＩＤ６０２は、ＵＳＢデバイスを製造したベンダを一意に識別する識別子を示す。図７で説明したＲｅｓｅｒｖｅｄＵＳＢＤｅｖｉｃｅｓの前の識別子２バイトに相当する。ＵＳＢデバイスプロダクトＩＤ６０３は、ＵＳＢデバイスの製品をベンダの中で一意に識別する識別子を示す。図７で説明した“ＲｅｓｅｒｖｅｄＵＳＢＤｅｖｉｃｅｓ”の後の識別子２バイトに相当する。デバイスドライバ識別子６０４は、アプリケーションがＵＳＢデバイスを制御するためにロードされるデバイスドライバを一意に識別する識別子を示す。タイムスタンプ６０５は、情報が登録された日時を特定する情報を示す。前記共通デバイスドライバ管理２１２は、情報を登録する際は同じ情報がないかチェックする。同じ情報であるか否かは、アプリケーションＩＤ６０１、ＵＳＢデバイスベンダＩＤ６０２、ＵＳＢデバイスプロダクトＩＤ６０３、デバイスドライバ識別子６０４が全て合致するか否かで判定する。まったく同じ情報が既に登録されていた場合は、情報を登録せずに処理を終了する。同じ情報が登録されていなかった場合は、対象デバイスリストの末尾に情報を追加する。本実施形態においては、２種類のアプリケーションから同じＵＳＢデバイスに対して情報を登録した場合、別々に対象デバイスリスト２２１に情報を追加する。これは、片方のアプリケーションがアンインストールされた場合に、もう片方のアプリケーションがＵＳＢデバイスを制御できなくなることを防止するためである。また、共通デバイスドライバ管理２１２は、情報を削除する際は指定された情報がないかチェックする。同じ情報であるか否かは、情報を登録する際と同じ方法で判定する。指定された情報が既に登録されていた場合は、情報を削除する。指定された情報が登録されていなかった場合は、何もせず処理を終了する。

＜ソフトウェア構成＞
以上で説明したインストーラ２１１と共通デバイスドライバ管理２１２と対象デバイスリスト２２１との３つによって、周辺装置識別情報付与手段８０１が実現される。本発明に対応するソフト構成図を図８に示す。共通インタフェース２１３は、アプリケーションからＵＳＢデバイスに対する通信要求を受けて、その要求を次に述べる利用可能な共通デバイスドライバ２１４と共通デバイスドライバ２１５とに振り分ける制御を行う。通信要求が示す通信先のＵＳＢデバイスに対してロードされているデバイスドライバを判別し、通信要求を振り分ける。共通デバイスドライバ２１４は、アプリケーションがＵＳＢデバイスの振る舞いを制御するためのドライバであって、後述する共通デバイスドライバ２１５と機能的には同じである。共通デバイスドライバ２１４は、後述するＵＳＢ−Ｃｏｒｅドライバへ、他のドライバよりも後に利用可能なデバイスドライバとして後述するデバイスドライバ登録２１８が登録する。ＵＳＢ−Ｃｏｒｅドライバは登録された順序で優先度を決めるため、共通デバイスドライバ２１４は一番低い優先度で認識される。また、共通デバイスドライバ２１４は、デバイスドライバ登録２１８により登録される際に、自らがサポートするＵＳＢデバイスの識別子を、ワイルドカード“＊”で指定する。そうすることで、共通デバイスドライバ２１４以外のドライバがロードされなかったＵＳＢデバイスに対しては、必ず共通デバイスドライバ２１４がロードされるようになる。これにより、ＵＳＢデバイスに対し必ず、汎用クラスドライバ、ベンダ固有ドライバ、共通デバイスドライバのいずれかが提供されることとなる。

共通デバイスドライバ２１５は、アプリケーションがＵＳＢデバイスの振る舞いを制御するためのドライバであって、共通デバイスドライバ２１４と機能的には同じである。共通デバイスドライバ２１４と異なる点としては、ＵＳＢ−Ｃｏｒｅドライバへ登録する際に対象デバイスリスト２２１を付与され識別情報を有することである。共通デバイスドライバ２１５は、後述するＵＳＢ−Ｃｏｒｅドライバへ、後述する汎用クラスドライバ２１６よりは先に、ベンダ固有ドライバ２１７よりは後に利用可能なデバイスドライバとしてデバイスドライバ登録２１８によって登録される。上述の通り、ＵＳＢ−Ｃｏｒｅドライバは登録された順序で優先度を決めるため、共通デバイスドライバ２１５は汎用クラスドライバ２１６よりは優先度高く、またベンダ固有ドライバ２１７よりは優先度が低く設定される。また、共通デバイスドライバ２１５は、自らがサポートするＵＳＢデバイスの識別子を、対象デバイスリスト２２１に基づいて付与し、その後登録される。上述の通り、前記対象デバイスリスト２２１にはアプリケーションが“ＲｅｓｅｒｖｅｄＵＳＢＤｅｖｉｃｅｓ”で定義したＵＳＢデバイスの識別子が記載されている。そのため、この構成をとることで汎用クラスのＵＳＢデバイスであっても共通デバイスドライバ２１５がロードされることになる。すなわち、アプリケーションで振る舞いを制御することが可能となる。つまり、共通デバイスドライバ２１５に識別情報を付与可能な第一の共通デバイスドライバであり、共通デバイスドライバ２１４が第二の共通デバイスドライバである。

汎用クラスドライバ２１６は、汎用クラスのＵＳＢデバイスの振る舞いを制御するデバイスドライバである。汎用クラスの説明は前述の通りである。汎用クラスは複数種類存在し、汎用クラスドライバ２１６もＯＳがサポートする汎用クラスの数だけ存在する。汎用クラスドライバ２１６は、ＵＳＢ−Ｃｏｒｅドライバに対し、共通デバイスドライバ２１４よりは前に登録され、共通デバイスドライバ２１５や後述するベンダ固有ドライバ２１７よりは後に登録される。上述の通り、ＵＳＢ−Ｃｏｒｅドライバは登録された順序で優先度を決めるため、汎用クラスドライバ２１６は共通デバイスドライバ２１４よりは優先度高く、また共通デバイスドライバ２１５や後述するベンダ固有ドライバ２１７よりは優先度が低く設定される。

ベンダ固有ドライバ２１７は、ＵＳＢデバイスのベンダ固有の振る舞いを制御する専用のデバイスドライバである。ベンダ固有ドライバ２１７は、１つで複数種類のＵＳＢデバイスをサポートすることが可能である。ベンダ固有ドライバ２１７は、他の全てのドライバより前に登録される。上述の通り、ＵＳＢ−Ｃｏｒｅドライバは登録された順序で優先度を決めるため、ベンダ固有ドライバ２１７は他の全てのドライバより優先度が高く設定される。

デバイスドライバ登録２１８は、共通デバイスドライバ２１３、共通デバイスドライバ２１４、汎用クラスドライバ２１６、ベンダ固有ドライバ２１７を含む複数のデバイスドライバをＵＳＢ−Ｃｏｒｅドライバ２１９に登録する処理を行う。その際、登録する順序を制御し、ＵＳＢ−Ｃｏｒｅドライバに設定させるべき優先度を考慮して登録の順序に関する情報を管理する。本発明におけるデバイス識別情報登録手段８０２は、デバイスドライバ登録２１８及びＵＳＢ−Ｃｏｒｅドライバ２１９を有する。上述の通り共通デバイスドライバ２１４、共通デバイスドライバ２１５を内部的に保持することで構成される。また、本実施形態においては、共通デバイスドライバ２１４、２１５の他、汎用クラスドライバ２１６及びベンダ固有ドライバ２１７も併せて内部に保持されることとなる。

ここで、後に述べるＵＳＢ−Ｃｏｒｅドライバ２１９に登録されるデバイスドライバを読み出す際の順番を明確化するため、デバイスドライバの情報とその順序に関する情報とが対応付けられて保持される形式を便宜上、登録リストと呼ぶ。この登録リストに基づいてデバイスドライバ登録２１８は、各デバイスドライバをＵＳＢ−Ｃｏｒｅドライバ２１９へ登録する。ただし、ドライバを登録する際の順番に関する保持形式はこれに限定するものではなく、ＵＳＢ−Ｃｏｒｅドライバ２１９への登録順を制御できればどのようなものでも構わない。ここでの登録リストにはデバイスドライバ毎に優先度を付して、デバイスドライバを登録することとする。以上にも述べたように、後で述べるＵＳＢ−Ｃｏｒｅドライバは、登録された順にデバイスドライバを読み出す順番を認識する。

ＵＳＢ−Ｃｏｒｅドライバ２１９は、Ｌｉｎｕｘ ＯＳのカーネルが備えるＵＳＢ用のサブシステムである。ＵＳＢ−Ｃｏｒｅドライバ２１９の役割は、ＵＳＢコントローラと呼ばれるＵＳＢデバイスを制御するためのハードウェアを抽象化してデバイスドライバにＡＰＩを提供することと、登録されたデバイスドライバとＵＳＢデバイスのリストを管理することである。ここでのリストとは、次に述べる対象デバイスリスト２２１や先に便宜上述べた登録リストとは異なる点に注意されたい。

以上をまとめると、ＵＳＢ−Ｃｏｒｅドライバ２１９において、各ドライバは以下の順番で高い優先度が決定される。
(1) ベンダ固有ドライバ２１７
(2) 共通デバイスドライバ２１５（識別情報有り）
(3) 汎用クラスドライバ２１６
(4) 共通デバイスドライバ２１４（識別情報無し）
図９に併せてＵＳＢ−Ｃｏｒｅデバイスドライバ２１９に登録される便宜的な優先度の順番をデバイスドライバの種別毎に示しておく。

対象デバイスリスト２２１は、共通デバイスドライバ２１５がサポートするＵＳＢデバイスの識別情報を管理したリストである。その詳細については前述の通りである。これまで述べてきたＵＳＢ−Ｃｏｒｅドライバ２１９への登録対象となる各デバイスドライバを登録するまでの概要フローチャートを図１０に示す。ここでの優先度は便宜的に図９で示したものを利用している。図１０の手順は、ＣＰＵ１１０により例えば不揮発性メモリ１１１に記憶したプログラムを実行することで実現する。また、ここでの処理はデバイスドライバ２１８が主に行う処理となる。

Ｓ１００１は図３の説明にて後述するアプリケーションインストール処理（対象デバイスリスト更新）の処理を示す。次にインストールしたアプリケーションに伴って、登録する対象ドライバが共通デバイスドライバか否かを判定する（Ｓ１００２）。共通デバイスドライバであれば、Ｓ１００６へ、それ以外のドライバであればＳ１００３へ進む。Ｓ１００３において、登録する対象デバイスドライバがベンダ固有ドライバか否かを判定する。ベンダ固有ドライバであればＳ１００５へ、そうでなければ（つまり、汎用クラスドライバ）であればＳ１００４へ進む。Ｓ１００４において、対象ドライバ（つまり、汎用クラスドライバ）をＵＳＢ−Ｃｏｒｅドライバ２１９へ登録する際に、優先度“低”となるような順番でデバイスドライバ登録２１８が保持する。ここでは登録リストへの追加とする。Ｓ１００５においては、対象ドライバ（つまり、ベンダ固有ドライバ）をＵＳＢ−Ｃｏｒｅドライバ２１９へ登録する際に、優先度“高”となるような順番でデバイスドライバ登録２１８が保持する。ここでは登録リストへの追加とする。Ｓ１００６においては、対象デバイス（つまり、共通デバイスドライバ）をＵＳＢ−Ｃｏｒｅドライバ２１９へ登録する際に、優先度“最低”となるような順番でデバイスドライバ登録２１８が保持する。ここでは登録リストへの追加とする。続いてＳ１００７へ進む。Ｓ１００７において、対象ドライバに識別情報を付与し、ＵＳＢ−Ｃｏｒｅドライバ２１９へ登録する際に、優先度“中”となるような順番でデバイスドライバ登録２１８が保持する。ここでは登録リストへの追加とする。ここでの識別情報は対象デバイスリスト２２１に基づいて取得することが可能である。ちなみに、Ｓ１００６及びＳ１００７はどちらを先に処理しても構わないものとする。Ｓ１００４、Ｓ１００５、Ｓ１００７（またはＳ１００６）の処理が終了したら、Ｓ１００８へ進む。Ｓ１００８には図４にて述べた処理が対応する。これにより、登録リストにて管理されたデバイスドライバをＵＳＢ−Ｃｏｒｅドライバ２１９へ登録して反映する。

＜アプリケーションインストール処理（デバイスリスト更新）＞
図３は、本発明における実施形態を説明するためのフローチャートである。図３では、アプリケーションをインストールする際に、アプリケーションが制御するＵＳＢデバイスの識別情報を対象デバイスリストへ登録する処理の流れを示す。本発明の各処理は、不揮発性メモリ１１１、揮発性メモリ１１２、補助記憶装置１１３のいずれかの記憶手段に記憶され、ＣＰＵ１１０により実行される。

ステップ３０１では、アプリケーションのインストール指示を受け付ける。アプリケーションのインストールを指示するための手段については特に限定しないが、ディスプレイ１１４と入力装置１１５を用いてユーザの指示により補助記憶装置１１３に予め記憶されたアプリケーションをインストールする方法などが考えられる。ステップ３０２では、インストーラ２１１はアプリケーションが有する設定ファイルを取得する。ステップ３０３では、設定ファイルの中にＵＳＢデバイスの識別情報が含まれているかをチェックする。識別情報が含まれているかの判定は、設定ファイルの中にＲｅｓｅｒｖｅｄＵＳＢＤｅｖｉｃｅｓの定義が含まれており、現在の設定に対し更に利用可能とすべきＵＳＢデバイスの設定が含まれているかで判定する。利用可能な設定か否かについては、前述において図６を用いて述べた通りである。設定ファイルの中にＵＳＢデバイスの識別情報が含まれていた場合、ステップ３０４の処理を行う。また、含まれていなかった場合、ステップ３０６の処理へ進む。ステップ３０４では、インストーラ２１１が共通デバイスドライバ管理２１２にステップ３０２において取得した設定ファイルに定義されたアプリケーションＩＤとＵＳＢデバイスの識別情報を登録する。アプリケーションＩＤは、“Ａｐｐｌｉｃａｔｉｏｎ−Ｉｄ”に記載された文字列を用いる。また、ＵＳＢデバイスの識別情報は、“ＲｅｓｅｒｖｅｄＵＳＢＤｅｖｉｃｅｓ”に２バイトの数字で定義された2つの識別子の組み合わせを用いる。ステップ３０５では、共通デバイスドライバ管理２１２が、ステップ３０４において登録されたアプリケーションＩＤとＵＳＢデバイスの識別情報を対象デバイスリスト２２１に追加登録する。ステップ３０６では、インストーラ２１１が、アプリケーションをインストールする処理を行う。以上の流れで、アプリケーションをインストールする際のアプリケーションが制御するＵＳＢデバイスの識別情報を登録する処理を行う。

＜デバイスドライバ登録処理（画像形成装置起動時）＞
図４は、本発明における実施形態を説明するためのフローチャートである。図４では、画像形成装置１０１を起動した際におけるデバイスドライバの登録処理の流れを示す。図３の説明で記載した通り、本発明の各処理は、不揮発性メモリ１１１、揮発性メモリ１１２、補助記憶装置１１３のいずれかの記憶手段によって記憶され、ＣＰＵ１１０により実行される。

ステップ４０１では、画像形成装置１０１の起動処理が開始される。ステップ４０２では、Ｌｉｎｕｘ ＯＳのカーネルイメージがロードされ、起動処理を行う。ステップ４０３では、画像形成装置１０１に保持されるデバイスドライバに対して順次登録処理を行うために、デバイスドライバ登録２１８は１つずつデバイスドライバを登録リストから処理対象として取り出す処理を行う。すでに述べたように、ＵＳＢ−Ｃｏｒｅドライバ２１９は登録順にて優先度を決定するため、ここでの取り出す処理は図９で述べた順番で処理される。全て処理済みであれば、本フローチャートで説明するデバイスドライバの登録処理を終了する。まだ登録処理が終わっていないデバイスドライバが存在する場合、ステップ４０４へ進む。ステップ４０４では、ステップ４０３において取り出したデバイスドライバをＵＳＢ−Ｃｏｒｅドライバ２１９へ登録する。Ｌｉｎｕｘ ＯＳにおける“ｍｏｄｐｒｏｂｅ”コマンドを用いるなどして登録する。ステップ４０５では、ステップ４０４においてＬｉｎｕｘ ＯＳに登録されたデバイスドライバが、自らがサポートするＵＳＢデバイスの識別情報をＵＳＢ−Ｃｏｒｅドライバ２１９へ登録する。Ｌｉｎｕｘ ＯＳが提供するｕｓｂ＿ｒｅｇｉｓｔｅｒ関数を用いるなどして登録する。詳細に関しては、提供するＬｉｎｕｘ ＯＳの形式等に依存し限定はしない。よって、ここでは割愛する。ステップ４０５の処理が終わると、ステップ４０３に戻り処理を繰り返す。以上の流れで、画像形成装置の起動時におけるデバイスドライバの登録処理を行う。

＜アプリケーションアンインストール処理（デバイスリスト更新）＞
図５は、本発明の実施例を説明するためのフローチャートである。図５では、アプリケーションをアンインストールする処理の流れを示す。図３の説明で記載した通り、本発明の各処理は、不揮発性メモリ１１１、揮発性メモリ１１２、補助記憶装置１１３のいずれかの記憶手段に記憶され、ＣＰＵ１１０により実行される。

ステップ５０１では、アプリケーションのアンインストール指示を受け付ける。アプリケーションのアンインストールを指示する手段については特に限定しないが、ディスプレイ１１４と入力装置１１５を用いてユーザがアンインストールを指示する方法などが考えられる。ステップ５０２では、インストーラ２１１はアプリケーションが有する設定ファイルを取得する。アンインストールするアプリケーションは、補助記憶装置１１３に記憶されている。ステップ５０３では、ステップ５０２において取得した設定ファイルの中にＵＳＢデバイスの識別情報が含まれているかをチェックする。識別情報が含まれているかの判定は、設定ファイルの中に“ＲｅｓｅｒｖｅｄＵＳＢＤｅｖｉｃｅｓ”の定義が含まれており、現在の設定に対し更に利用可能な設定が行われているかで判定する。利用可能な設定については、上述の通りである。設定ファイルの中にＵＳＢデバイスの識別情報が含まれていた場合、ステップ５０４へ進む。また、含まれていなかった場合、ステップ５０６へ進む。ステップ５０４では、インストーラ２１１が共通デバイスドライバ管理２１２にステップ５０２にて取得した設定ファイルに記載されたアプリケーションＩＤとＵＳＢデバイスの識別情報を登録解除する。アプリケーションＩＤは、“Ａｐｐｌｉｃａｔｉｏｎ−Ｉｄ”に記載された文字列を用いる。また、ＵＳＢデバイスの識別情報は、“ＲｅｓｅｖｅｄＵＳＢＤｅｖｉｃｅｓ”に２バイトの数字で定義された２つの識別子の組み合わせを用いる。ステップ５０５では、共通デバイスドライバ管理２１２が、ステップ５０４にて登録されたアプリケーションＩＤとＵＳＢデバイスの識別情報を対象デバイスリスト２２１から登録解除し、更新する。登録解除の際は、これらの情報が全て適合した場合のみ削除する。適合する情報が登録されていない場合、更新処理を行わない。ステップ５０６では、アプリケーションのアンインストール処理を行う。以上の流れで、アプリケーションをアンインストールする際のアプリケーションが制御するＵＳＢデバイスの識別情報を登録解除する処理を行う。以上、本発明を実施するための第１の形態について説明した。これにより、共通デバイスドライバを介してＵＳＢデバイスを制御するアプリケーションが、所望するＵＳＢデバイスを制御できるようになる。同時に、特定のＵＳＢデバイスが所望するデバイスドライバがＯＳ内に存在しない場合に、従来通り共通デバイスドライバがロードされ、アプリケーションから制御できる。

＜その他の実施形態＞
本発明を実施するための第一の実施形態において説明した各手段は、それぞれ別の構成によって実現することも可能である。ここでは、他の実施形態として、第一の実施形態で説明した各手段に基づいて別の構成について説明する。

第一の実施形態におけるＵＳＢホストコントローラ１１６は、別の周辺装置を接続するためのハードウェアに置き換えられても良い。例えば、ＳＣＳＩホストコントローラであっても良い。その場合、ＵＳＢケーブル１３０もＳＣＳＩケーブルに置き換えられ、同様にＵＳＢデバイス１４０はＳＣＳＩ接続に対応した周辺装置となる。外付けデバイスは、周辺装置の一例である。画像形成装置をＵＳＢなどのホストとみた場合の周辺装置という位置付けである。画像形成装置に対してＵＳＢなどの通信インタフェースを介して外付けされていることもある。また、画像形成装置のＵＳＢインタフェース１１６等を介して接続され、画像形成装置の筐体内部に内蔵されていてもよい。
また、第一の実施形態におけるアプリケーション２０１が保持する設定ファイルは、ファイルの形式でなくても良い。例えば、インストーラ２１１から呼び出し可能な関数コールの機能を備え、関数コールを介して設定ファイルに保持する情報を受け渡しする構成であっても良い。

また、第一の実施形態におけるインストーラ２１１、共通デバイスドライバ管理２１２、対象デバイスリスト２２１で構成された周辺装置識別情報付与手段８０１は、別の構成でも良い。例えば、インストーラ２１１がなく、アプリケーション２０１が共通デバイスドライバ管理２１２を呼び出す構成であってもよい。更に、共通デバイスドライバ管理２１２がなく、アプリケーション２０１が対象デバイスリスト２２１にＵＳＢデバイスの識別情報を書き込む構成であっても良い。

更に別の例として、対象デバイスリスト２２１がファイルではなく、不揮発性メモリ１１１上の共有メモリに一時的に保持される構造体であっても良い。この場合、アプリケーション２０１は共有メモリにアクセスし、対象デバイスリスト２２１の情報を更新することとなる。または、共通デバイスドライバ２１５が管理するメモリ上に保持される構造体であっても良い。この場合、アプリケーション２０１は共通デバイスドライバ２１５を呼び出して対象デバイスリスト２２１の情報を更新する。

また、第一の実施形態におけるインストーラ２１１は、アプリケーション２０１のインストール時とアンインストール時にそれぞれ共通デバイスドライバ管理２１２に必要な情報を通知していた。しかし、このタイミングはインストール時とアンインストール時でなくても構わない。例えば、アプリケーション２０１の動作開始時と動作停止時にそれぞれ共通デバイスドライバ管理２１２に必要な情報を通知する構成であっても良い。

また、第一の実施形態における共通デバイスドライバ管理２１２における対象デバイスリスト２２１を更新するか否かの判定は、より細かいチェックがあっても良い。例えば、ＵＳＢデバイスベンダＩＤ６０２、ＵＳＢデバイスプロダクトＩＤ６０３が一致していて、デバイスドライバ識別子６０４が一致しない場合は、何らかの異常が発生したとみなしてエラーを返す構成であっても良い。

また、第一の実施形態における共通インタフェース２１３において、対象デバイスリスト２２１にＵＳＢデバイスの識別情報を登録したアプリケーションのみ通信を許可する構成であっても良い。この場合、共通インタフェース２１３は、アプリケーション２０１が有する設定ファイル７０１から“ＲｅｓｅｒｖｅｄＵＳＢＤｅｖｉｃｅｓ”に定義された値を読み取り、通信要求先のＵＳＢデバイスと比較することで通信を許可するか判定する。また、別の実現方法として、共通インタフェース２１３が対象デバイスリスト２２１を参照する実現方法でも良い。その場合、アプリケーションＩＤ６０１、ＵＳＢデバイスベンダＩＤ６０２、ＵＳＢデバイスプロダクトＩＤ６０３の組み合わせチェックの結果で通信を許可するか判断する。

また、第一の実施形態における対象デバイスリスト２２１は、他の情報を保持していても良い。例えば、ＵＳＢデバイスのリリース番号を保持し、あるリリース番号を境にデバイスドライバを切り替えることが可能な構成であっても良い。もしくは、ＵＳＢデバイスのクラスコード、サブクラスコード、プロトコルコードを保持し、これらの情報によってデバイスドライバを切り替えることが可能な構成であっても良い。ここで、ＵＳＢデバイスのリリース番号とは、ＵＳＢデバイスが備えるＤｅｖｉｃｅ Ｄｅｓｃｒｉｐｔｏｒの“ｂｃｄＤｅｖｉｃｅ”フィールドの値を指している。また、ＵＳＢデバイスのクラスコードとは、ＵＳＢデバイスが備えるＤｅｖｉｃｅ Ｄｅｓｃｒｉｐｔｏｒの“ｂＤｅｖｉｃｅＣｌａｓｓ”フィールドの値を指している。また、ＵＳＢデバイスのサブクラスコードとは、ＵＳＢデバイスが備えるＤｅｖｉｃｅ Ｄｅｓｃｒｉｐｔｏｒの“ｂＤｅｖｉｃｅＳｕｂｃｌａｓｓ”フィールドの値を指している。また、ＵＳＢデバイスのプロトコルコードとは、ＵＳＢデバイスが備えるＤｅｖｉｃｅ Ｄｅｓｃｒｉｐｔｏｒの“ｂＤｅｖｉｃｅＰｒｏｔｏｃｏｌ”フィールドの値を指している。もしくは、Ｉｎｔｅｒｆａｃｅ Ｄｅｓｃｒｉｐｔｏｒの“ｂＤｅｖｉｃｅＣｌａｓｓ”、“ｂＤｅｖｉｃｅＳｕｂｃｌａｓｓ”、“ｂＤｅｖｉｃｅＰｒｏｔｏｃｏｌ”フィールドの値であっても良い。

以上、本発明を実施するためのその他の実施形態にについて説明した。これにより、第一の実施形態と同様に共通デバイスドライバを介してＵＳＢデバイスを制御するアプリケーションが、所望するＵＳＢデバイスを制御できるようになる。同時に、特定のＵＳＢデバイスが所望するデバイスドライバがＯＳ内に存在しない場合に、従来通り共通デバイスドライバがロードされ、アプリケーションから制御できる。

＜備考＞
なお本発明は、複数の機器（例えばホストコンピュータ、インタフェース機器、リーダ、プリンタなど）から構成されるシステムに適用しても、一つの機器からなる装置（例えば、複写機、ファクシミリ装置など）に適用してもよい。

また本発明の目的は、前述の実施形態の機能を実現するプログラムを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータが記憶媒体に格納されたプログラムを読み出し実行することによっても達成される。この場合、記憶媒体から読み出された実行可能なプログラム自体が前述した実施形態の機能を実現することになり、そのプログラム自体およびプログラムを記憶した記憶媒体は本発明を構成することになる。

ちなみに、プログラムを供給するための記憶媒体としては、例えば、フロッピディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＤＶＤ−ＲＯＭ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどを用いることができる。また、本発明には、プログラムの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム（ＯＳ）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。さらに、記憶媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた場合についても、本発明は適用される。その場合、書き込まれたプログラムの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される。

また、発明の実施の形態は、本発明を中核として構成される装置又は方法を説明している。このため本実施形態には本発明の本質的部分を加えて付加的な構成要件も記載されている。すなわち発明の実施の形態において説明した装置又は方法の構成要件を備えることは、本発明を成立させるための十分条件ではあるものの、必要条件ではない。

本発明における第一の実施形態を説明するためのハードウェア構成図の例である。 本発明における第一の実施形態を説明するためのソフトウェア構成図の例である。 本発明における第一の実施形態を説明するための、アプリケーションをインストールする際に、アプリケーションが制御するＵＳＢデバイスの識別情報を登録する処理の流れを示すフローチャートである。 本発明における第一の実施形態を説明するための、画像形成装置を起動した際においてデバイスドライバの登録処理の流れを示すフローチャートである。 本発明における第一の実施形態を説明するための、アプリケーションをアンインストールする際においてアプリケーションが制御するＵＳＢデバイスの識別情報を登録解除する処理の流れを示すフローチャートである。 本発明において第一の実施形態を説明するための対象デバイスリストの例である。 本発明において第一の実施形態を説明するためのアプリケーションが有する設定ファイルの例である。 本発明において特徴を説明するためのソフトウェア構成図の例である。 本発明においてデバイスドライバの登録における優先度を便宜的に示したものである。 本発明においてデバイスドライバを画像形成装置に登録するまでの処理の流れを便宜的に示したフローチャートの図である。

１０１ 画像形成装置
１１０ ＣＰＵ
１１１ 不揮発性メモリ
１１２ 揮発性メモリ
１１３ 補助記憶装置
１１４ ディスプレイ
１１５ 入力装置
１１６ ＵＳＢホストコントローラ
１３０ ＵＳＢケーブル
１４０ ＵＳＢデバイス
２０１ アプリケーション
２１１ インストーラ
２１２ 共通デバイスドライバ管理
２１３ 共通インタフェース
２１４ 共通デバイスドライバ
２１６ 汎用クラスドライバ
２１７ ベンダ固有ドライバ
２１８ デバイスドライバ登録
２１９ ＵＳＢ−Ｃｏｒｅドライバ
２２１ 対象デバイスリスト

Claims (18)

1. 登録されたドライバの情報を管理し、登録されたドライバをロードするオペレーティングシステムと、周辺装置の動作を制御するための汎用クラスドライバと、周辺装置の動作を制御するロジックを有するアプリケーションが当該周辺装置を制御する際に利用する共通デバイスドライバと、を有する画像形成装置であって、
   前記アプリケーションが制御を行う周辺装置の識別情報を前記共通デバイスドライバに付与する付与手段と、
   周辺装置が前記画像形成装置に接続された際に当該周辺装置を制御するために利用する共通デバイスドライバであって当該周辺装置の識別情報が付与された共通デバイスドライバが当該周辺装置を制御するための汎用クラスドライバよりも優先的に利用されるように、前記オペレーティングシステムに対しドライバの情報を登録する登録手段と
   を有することを特徴とする画像形成装置。
2. 前記識別情報が付与された共通デバイスドライバは、第一の共通デバイスドライバであり、
   前記登録手段は、前記識別情報が付与されていない第二の共通デバイスドライバを、前記第一の共通デバイスドライバとは別に、前記アプリケーションにより利用可能なデバイスドライバとして前記オペレーティングシステムへ登録し、
   前記オペレーティングシステムは、周辺装置が前記画像形成装置に接続された際に、当該周辺装置を制御するための前記第一の共通デバイスドライバ、および当該周辺装置を制御するための汎用クラスドライバの両方が存在しない場合には、前記識別情報が付与されていない第二の共通デバイスドライバを利用することを特徴とする請求項１に記載の画像形成装置。
3. 前記オペレーティングシステムは、前記画像形成装置に接続された周辺装置に対応する、ベンダ固有のドライバを他のドライバよりも優先的に利用することを特徴とする請求項１または２に記載の画像形成装置。
4. 登録されたドライバの情報を管理し、登録されたドライバをロードするオペレーティングシステムと、周辺装置の動作を制御するための汎用クラスドライバと、周辺装置の動作を制御するロジックを有するアプリケーションが当該周辺装置を制御する際に利用する共通デバイスドライバと、を有する装置であって、
   周辺装置が前記装置に接続された際に当該周辺装置を制御するために利用する共通デバイスドライバであって当該周辺装置の識別情報が付与された共通デバイスドライバが当該周辺装置を制御するための汎用クラスドライバよりも優先的に利用されるように、前記オペレーティングシステムに対しドライバの情報を登録する登録手段と
   を有することを特徴とする装置。
5. 前記識別情報が付与された共通デバイスドライバは、第一の共通デバイスドライバであり、
   前記登録手段は、前記識別情報が付与されていない第二の共通デバイスドライバを、前記第一の共通デバイスドライバとは別に、前記アプリケーションにより利用可能なデバイスドライバとして前記オペレーティングシステムへ登録し、
   前記オペレーティングシステムは、周辺装置が前記装置に接続された際に、当該周辺装置を制御するための前記第一の共通デバイスドライバ、および当該周辺装置を制御するための汎用クラスドライバの両方が存在しない場合には、前記識別情報が付与されていない第二の共通デバイスドライバを利用することを特徴とする請求項４に記載の装置。
6. 前記オペレーティングシステムは、前記装置に接続された周辺装置に対応する、ベンダ固有のドライバを他のドライバよりも優先的に利用することを特徴とする請求項４または５に記載の装置。
7. 登録されたドライバの情報を管理し、登録されたドライバをロードするオペレーティングシステムと、周辺装置の動作を制御するための汎用クラスドライバと、周辺装置の動作を制御するロジックを有するアプリケーションが当該周辺装置を制御する際に利用する共通デバイスドライバと、を有する画像形成装置の制御方法であって、
   付与手段が、前記アプリケーションが制御を行う周辺装置の識別情報を前記共通デバイスドライバに付与する付与工程と、
   登録手段が、周辺装置が前記画像形成装置に接続された際に当該周辺装置を制御するために利用する共通デバイスドライバであって当該周辺装置の識別情報が付与された共通デバイスドライバが当該周辺装置を制御するための汎用クラスドライバよりも優先的に利用されるように、前記オペレーティングシステムに対しドライバの情報を登録する登録工程と
   を有することを特徴とする制御方法。
8. 前記識別情報が付与された共通デバイスドライバは、第一の共通デバイスドライバであり、
   前記登録工程にて、前記識別情報が付与されていない第二の共通デバイスドライバを、前記第一の共通デバイスドライバとは別に、前記アプリケーションにより利用可能なデバイスドライバとして前記オペレーティングシステムへ登録し、
   前記オペレーティングシステムは、周辺装置が前記画像形成装置に接続された際に、当該周辺装置を制御するための前記第一の共通デバイスドライバ、および当該周辺装置を制御するための汎用クラスドライバの両方が存在しない場合には、前記識別情報が付与されていない第二の共通デバイスドライバを利用することを特徴とする請求項７に記載の制御方法。
9. 前記オペレーティングシステムは、前記画像形成装置に接続された周辺装置に対応する、ベンダ固有のドライバを他のドライバよりも優先的に利用することを特徴とする請求項７または８に記載の画像形成装置。
10. 登録されたドライバの情報を管理し、登録されたドライバをロードするオペレーティングシステムと、周辺装置の動作を制御するための汎用クラスドライバと、周辺装置の動作を制御するロジックを有するアプリケーションが当該周辺装置を制御する際に利用する共通デバイスドライバと、を有する装置の制御方法であって、
    登録手段が、周辺装置が前記装置に接続された際に当該周辺装置を制御するために利用する共通デバイスドライバであって当該周辺装置の識別情報が付与された共通デバイスドライバが当該周辺装置を制御するための汎用クラスドライバよりも優先的に利用されるように、前記オペレーティングシステムに対しドライバの情報を登録する登録工程と
    を有することを特徴とする制御方法。
11. 前記識別情報が付与された共通デバイスドライバは、第一の共通デバイスドライバであり、
    前記登録手段は、前記識別情報が付与されていない第二の共通デバイスドライバを、前記第一の共通デバイスドライバとは別に、前記アプリケーションにより利用可能なデバイスドライバとして前記オペレーティングシステムへ登録し、
    前記オペレーティングシステムは、周辺装置が前記装置に接続された際に、当該周辺装置を制御するための前記第一の共通デバイスドライバ、および当該周辺装置を制御するための汎用クラスドライバの両方が存在しない場合には、前記識別情報が付与されていない第二の共通デバイスドライバを利用することを特徴とする請求項１０に記載の制御方法。
12. 前記オペレーティングシステムは、前記装置に接続された周辺装置に対応する、ベンダ固有のドライバを他のドライバよりも優先的に利用することを特徴とする請求項１０または１１に記載の制御方法。
13. 登録されたドライバの情報を管理し、登録されたドライバをロードするオペレーティングシステムと、周辺装置の動作を制御するための汎用クラスドライバと、周辺装置の動作を制御するロジックを有するアプリケーションが当該周辺装置を制御する際に利用する共通デバイスドライバと、を有するコンピュータを、
    前記アプリケーションが制御を行う周辺装置の識別情報を前記共通デバイスドライバに付与する付与手段、
    周辺装置が前記コンピュータに接続された際に当該周辺装置を制御するために利用する共通デバイスドライバであって当該周辺装置の識別情報が付与された共通デバイスドライバが当該周辺装置を制御するための汎用クラスドライバよりも優先的に利用されるように、前記オペレーティングシステムに対しドライバの情報を登録する登録手段
    として機能させるためのプログラム。
14. 前記識別情報が付与された共通デバイスドライバは、第一の共通デバイスドライバであり、
    前記登録手段は、前記識別情報が付与されていない第二の共通デバイスドライバを、前記第一の共通デバイスドライバとは別に、前記アプリケーションにより利用可能なデバイスドライバとして前記オペレーティングシステムへ登録し、
    前記オペレーティングシステムは、周辺装置が前記コンピュータに接続された際に、当該周辺装置を制御するための前記第一の共通デバイスドライバ、および当該周辺装置を制御するための汎用クラスドライバの両方が存在しない場合には、前記識別情報が付与されていない第二の共通デバイスドライバを利用することを特徴とする請求項１３に記載のプログラム。
15. 前記オペレーティングシステムは、前記コンピュータに接続された周辺装置に対応する、ベンダ固有のドライバを他のドライバよりも優先的に利用することを特徴とする請求項１３または１４に記載のプログラム。
16. 登録されたドライバの情報を管理し、登録されたドライバをロードするオペレーティングシステムと、周辺装置の動作を制御するための汎用クラスドライバと、周辺装置の動作を制御するロジックを有するアプリケーションが当該周辺装置を制御する際に利用する共通デバイスドライバと、を有するコンピュータを、
    周辺装置が前記コンピュータに接続された際に当該周辺装置を制御するために利用する共通デバイスドライバであって当該周辺装置の識別情報が付与された共通デバイスドライバが当該周辺装置を制御するための汎用クラスドライバよりも優先的に利用されるように、前記オペレーティングシステムに対しドライバの情報を登録する登録手段
    として機能させるためのプログラム。
17. 前記識別情報が付与された共通デバイスドライバは、第一の共通デバイスドライバであり、
    前記登録手段は、前記識別情報が付与されていない第二の共通デバイスドライバを、前記第一の共通デバイスドライバとは別に、前記アプリケーションにより利用可能なデバイスドライバとして前記オペレーティングシステムへ登録し、
    前記オペレーティングシステムは、周辺装置が前記コンピュータに接続された際に、当該周辺装置を制御するための前記第一の共通デバイスドライバ、および当該周辺装置を制御するための汎用クラスドライバの両方が存在しない場合には、前記識別情報が付与されていない第二の共通デバイスドライバを利用することを特徴とする請求項１６に記載のプログラム。
18. 前記オペレーティングシステムは、前記コンピュータに接続された周辺装置に対応する、ベンダ固有のドライバを他のドライバよりも優先的に利用することを特徴とする請求項１６または１７に記載のプログラム。

Images