JP4333765B2 - デバイス制御システム - Google Patents

Description

本発明は、デバイス制御システムに関する。

従来、ＵＳＢ（Universal Serial Bus）インターフェースを介して接続可能な複合機（ＭＦＰ；multifunction peripheral）は、既に実用化されている。また、この種の複合機における代表的な構成として、複数ある機能毎にデータ転送用のエンドポイントが用意されているものが知られている。

しかし、複数ある機能毎にエンドポイントを用意すると、多機能になるほどエンドポイント数の多い高価なハードウェアが必要になるため、複合機の製造コストが増大し、低価格な複合機を提供することが困難になる、という問題がある。

こうした問題に対し、下記特許文献１，２においては、複合機に実装されるエンドポイントの数を削減するための技術が提案されている（例えば、特許文献１，２参照。）。
例えば、特許文献１に記載の技術の場合、擬似的に、ある機能を備えたデバイスとの接続断、および別の機能を備えたデバイスとの接続が行われたものと、ホスト装置に認識させることで、同一エンドポイントを介して複数の機能を選択的に利用可能としている。

また、特許文献２に記載の技術の場合、データ転送用のエンドポイントとは別に用意される制御用のエンドポイントを利用してデータ転送をも実施することで、データ転送用のエンドポイントを削減している。
特開２００１−２２２５０３号公報 特開２００５−１７５９３６号公報

しかしながら、上記特許文献１に記載の技術では、複合機が備える様々な機能を利用するたびに、ホスト装置側においてデバイスドライバの切り替え（使用しないドライバの無効化、および使用するドライバのロード・有効化等）が発生する。そのため、デバイスドライバの切り替えに相応の時間を要し、また、２つの機能を同時に利用することはできない、という問題がある。

また、上記特許文献１に記載の技術では、複合機のある機能が作動中の場合、その作動が確実に完了するまでは別の機能に切り替えることができないので、どのようなタイミングで切り替え制御を行うべきか、その判断は容易ではない、という問題もある。

さらに、上記特許文献２に記載の技術では、制御用のエンドポイントがデータ転送に利用されてしまうため、大量にデータが転送されるような状況下では、データ転送に邪魔されて必要な制御を迅速に実施できない状態に陥るおそれがあった。

つまり、上記特許文献１，２に記載の技術によって、エンドポイントを削減することはできても、その結果として、複合機の使い勝手が悪くなったり、適切な制御ができなくなったりするおそれがあった。

本発明は、上記問題を解決するためになされたものであり、その目的は、エンドポイントを削減することができ、しかも、使い勝手が悪化したり適切な制御ができなくなったりすることのない複合機を備えたデバイス制御システムを提供することにある。

以下、本発明において採用した構成について説明する。
請求項１に記載のデバイス制御システムは、コンピュータと、複数種の機能を備えた複合機とを、ＵＳＢインターフェースを介して接続した構造になっており、前記複合機は、前記コンピュータが備えるＯＳには、ＵＳＢ規格に準拠した方式でデータを伝送可能な論理ユニットを少なくとも１つ有するデバイスであると認識され、前記コンピュータが前記論理ユニットとの間で入出力データの伝送を行うことによって、前記複合機が備える前記複数種の機能を利用可能となっているデバイス制御システムであって、前記複合機において、前記論理ユニットの少なくとも１つは、単一の論理ユニットに対して、前記複数種の機能の内、２種以上の特定機能が対応付けられた複合論理ユニットとされており、前記コンピュータと前記複合機との接続を確立する際、前記コンピュータは、前記複合論理ユニットをＵＳＢストレージクラスのデバイスであると認識して、前記ＵＳＢストレージクラスのデバイスと通信可能な状態になる一方、前記複合機は、前記ＵＳＢストレージクラスのデバイスに対応する１組の入力用および出力用のエンドポイントを介して前記コンピュータと通信可能な状態となって、前記コンピュータと前記複合機がＵＳＢ規格に準拠した通信手順で通信可能な接続状態となり、しかも、前記コンピュータが前記複合論理ユニットに対し、ＳＣＳＩコマンドの“Ｉｎｑｕｉｒｙ”を発行すると、前記複合機はＳＣＳＩデバイスの種別としてストレージデバイスである旨の応答を返し、当該応答を受けた前記コンピュータは、前記１組の入力用および出力用のエンドポイントを介して通信可能な接続状態について切断および再接続を行うことなく、前記ストレージデバイスに対応するストレージデバイス用デバイスドライバをロードし、前記コンピュータは、前記コンピュータ上で機能するデータ処理部からの指令に従って、前記２種以上の特定機能のいずれかを制御するために前記コンピュータからの出力データを前記複合機に伝送する場合に、前記２種以上の特定機能のいずれかを制御するための独自規格の情報を、前記出力データ内の実データ部に格納して、当該出力データを前記複合論理ユニットへと伝送し、さらに、前記コンピュータへの入力データが前記複合機から伝送された場合には、前記入力データ内の実データ部に含まれる独自規格の情報に基づいて、前記２種以上の特定機能のいずれによって伝送されてきたデータであるのかを判断して、当該データを指令元である前記データ処理部へと伝送するコンピュータ側制御手段を備え、前記複合機は、前記コンピュータからの出力データが前記複合論理ユニットに伝送された場合には、前記出力データ内の実データ部に含まれる独自規格の情報に基づいて、前記２種以上の特定機能のいずれを制御するためのデータであるのかを判断して、いずれか１種の機能を制御し、さらに、前記１種の機能を制御したことにより、前記コンピュータへの入力データを伝送する場合には、前記２種以上の特定機能のいずれによって伝送されるデータであるのかを示す独自規格の情報を、前記入力データ内の実データ部に格納して、当該入力データを前記複合論理ユニットからのデータとして前記コンピュータへと伝送するデバイス側制御手段を備え、しかも、前記コンピュータ側制御手段は、前記２種以上の特定機能それぞれに対応付けて設けられた２以上の特定機能用デバイスドライバと、前記２以上の特定機能用デバイスドライバと前記ＯＳとの間に介在して一方から他方へデータ伝送を行うデータ管理手段とを備え、前記コンピュータと前記複合機との接続を確立する際、前記コンピュータは、前記２以上の特定機能用デバイスドライバを、前記ストレージデバイス用デバイスドライバとは別に、スタティックドライバとしてロードし、前記コンピュータ上で機能するデータ処理部からの指令に従って、前記２種以上の特定機能のいずれかを制御するために前記コンピュータからの出力データを前記複合機に伝送する場合に、前記特定機能用デバイスドライバは、前記コンピュータ上で機能するデータ処理部からの指令に従って、前記２種以上の特定機能のいずれかを制御するためのデータを作成して、当該データを前記データ管理手段へと伝送し、前記データ管理手段は、前記特定機能用デバイスドライバから伝送されてきたデータに基づき、前記２種以上の特定機能のいずれかを制御するための独自規格の情報を、前記出力データ内の実データ部に格納して、当該出力データを前記複合論理ユニットへと伝送し、さらに、前記コンピュータへの入力データが前記複合機から伝送された場合には、前記データ管理手段は、前記入力データ内の実データ部に含まれる独自規格の情報に基づいて、前記２種以上の特定機能のいずれかによって伝送されてきたデータであるのかを判断して、当該データを当該データに対応する前記特定機能用デバイスドライバへと伝送し、当該データが伝送されてきた特定機能用デバイスドライバは、当該データを指令元である前記データ処理部へと伝送することを特徴とする。

以下の説明において、論理ユニットとは、コンピュータの備えるＯＳが、ＵＳＢ規格に準拠した方式でデータを伝送可能なデータ伝送対象として認識する論理的な構成単位のことである。

より具体的な例を交えて説明すると、一般に、単機能のＵＳＢデバイスであれば、コンピュータの備えるＯＳは単一のデータ伝送対象として認識する。この場合、単機能のＵＳＢデバイスは、ここでいう論理ユニットを１つ有するデバイスであると認識されたことになる。

また、複数機能を備えたＵＳＢ複合デバイスであれば、コンピュータの備えるＯＳは複数機能それぞれに対応する複数のデータ伝送対象をそれぞれ個別に認識する。この場合、ＵＳＢ複合デバイスは、ここでいう論理ユニットを複数有するデバイスであると認識されたことになる。

さらに、ＵＳＢストレージクラスのデバイスは、単一のデバイスで複数のＬＵＮ（Logical Unit Number）を持つことができ、コンピュータの備えるＯＳは複数のＬＵＮそれぞれに対応する複数のデータ伝送対象をそれぞれ個別に認識する。この場合、複数ＬＵＮを持つＵＳＢストレージデバイスは、ここでいう論理ユニットを複数有するデバイスであると認識されたことになる。

上記単機能のＵＳＢデバイスやＵＳＢ複合デバイスの場合、コンピュータと論理ユニットとの間でデータ伝送を実施するため、論理ユニット毎に入力用のエンドポイントと出力用のエンドポイントが用意される。また、複数ＬＵＮを持つＵＳＢストレージデバイスの場合、コンピュータと論理ユニットとの間でデータ伝送を実施するため、複数の論理ユニットで共用する入力用のエンドポイントと出力用のエンドポイントが用意される。

つまり、上記のようなＵＳＢデバイスには、単一の論理ユニットのみが利用するエンドポイントか、複数の論理ユニットで共用するエンドポイントかの違いはあるものの、１つの論理ユニットに対応する入力用および出力用のエンドポイントが１つずつ存在する。なお、入力用および出力用のエンドポイントの他、ＵＳＢデバイスには、制御用のエンドポイントが１つ用意される。

以上のような前提の下、本発明のデバイス制御システムが備える複合機は、コンピュータとＵＳＢインターフェースを介して接続された際、コンピュータが備えるＯＳには、ＵＳＢ規格に準拠した方式でデータを伝送可能な論理ユニットを少なくとも１つ有するデバイスであると認識される。

すなわち、本発明のデバイス制御システムが備える複合機は、論理ユニットを１つ有するデバイスであると認識される構成になっていてもよいし、論理ユニットを複数有するデバイスであると認識される構成になっていてもよい。

ただし、本発明のデバイス制御システムが備える複合機が有する論理ユニットは、少なくとも１つが、単一の論理ユニットに対して、複数種の機能の内、２種以上の特定機能が対応付けられた複合論理ユニットとされている。すなわち、コンピュータの備えるＯＳには、ＵＳＢの規格上、論理ユニットの１つとして認識される複合論理ユニットが、少なくとも１つは存在する構成になっている。

そして、コンピュータからの出力データが上記複合論理ユニットに伝送された場合には、出力データ内の実データ部に含まれる独自規格の情報に基づいて、２種以上の特定機能のいずれを制御するためのデータであるのかを判断し、いずれか１種の機能を制御する。

また、その１種の機能を制御したことに伴い、コンピュータへの入力データを伝送する必要が生じた場合には、２種以上の特定機能のいずれによって伝送されるデータであるのかを示す独自規格の情報を、入力データ内の実データ部に格納し、その入力データを複合論理ユニットからのデータとしてコンピュータへと伝送する。

このように構成されたデバイス制御システムによれば、複合機は、コンピュータとＵＳＢインターフェースを介して接続された際、コンピュータが備えるＯＳには、ＵＳＢ規格に準拠した方式でデータを伝送可能な論理ユニットを少なくとも１つ有するデバイスであると認識される。しかも、複合機が有する論理ユニットは、少なくとも１つが、上述の複合論理ユニットとされている。

したがって、このようなデバイス制御システムであれば、複合機には、１つの複合論理ユニットに対応する入力用および出力用のエンドポイントを１つずつ用意するだけで、ＵＳＢ規格の通信プロトコルに則って、コンピュータと複合論理ユニットとの間で相互にデータ伝送を行うことができる。しかも、このデータ伝送により、コンピュータから２種以上の特定機能を利用することができる。

したがって、１つの機能毎にそれぞれに対応する論理ユニットが構成されることになるＵＳＢ複合デバイスとは異なり、個々の機能毎に入力用および出力用のエンドポイントを１つずつ用意しなくてもよくなるので、その分だけエンドポイント数を削減することができる。

また、２種以上の特定機能のいずれを制御するかは、独自規格の情報として実データ部に格納されているものなので、あるＵＳＢデバイスとの接続を断って、別のＵＳＢデバイスとの接続を確立するといった状況を擬似的に作り出す必要はない。したがって、コンピュータ側で、デバイスドライバの切り替えに時間を要するといった問題はなく、２つの機能を同時に利用することもできる。

さらに、制御用のエンドポイントがデータ転送に利用される構成にはなっていないので、大量にデータが転送されるような状況下でも、データ転送に邪魔されることなく、必要な制御を迅速に実施できるものとなる。
加えて、上記のように構成されたデバイス制御システムによれば、コンピュータには、２種以上の特定機能それぞれに対応付けて設けられた２以上のデバイスドライバと、２以上のデバイスドライバとＯＳとの間に介在して一方から他方へデータ伝送を行うデータ管理手段が設けられる。
そのため、２以上のデバイスドライバについては、単機能のデバイスを制御するためのデバイスドライバと同等なものとすることができる。したがって、２種以上の特定機能すべてを制御可能な特殊なデバイスドライバを用意しなくてもよいので、デバイスドライバの開発コストを抑制することができる。

次に、請求項２に記載のデバイス制御システムは、請求項１に記載のデバイス制御システムにおいて、前記複合機が備える前記デバイス側制御手段は、前記ストレージデバイス用デバイスドライバからのコマンドが到来した場合に、メディアの入っていないドライブ相当の応答を前記コンピュータに対して返すことを特徴とする。

このように構成されたデバイス制御システムによれば、複合機は、ストレージデバイスへの書き込み要求やストレージデバイスからの読み出し要求などをエミュレートした応答を返さなくても、常にストレージデバイス用のメディアが入っていない旨を応答するだけでよいので、煩雑な擬似応答をしなくても済む。また、常にメディアが入っていない状態をエミュレートすれば、メディア交換ステータスも発生しないので、メディア交換ステータスが発生する場合に比べ、予期しない事態に陥る可能性を低くすることができる。

次に、本発明の実施形態について、より具体的な例を挙げて説明する。
（１）第１実施形態
［デバイス制御システムの構成］
図１は、本発明の一例として例示するデバイス制御システム全体のブロック図である。

このデバイス制御システムは、複合機１１およびＰＣ（Personal Computer）１２を備えてなる。複合機１１およびＰＣ１２は、双方ともＵＳＢインターフェースを有するもので、ＵＳＢ−ＨＵＢ１３を介して接続されて相互間でデータ伝送ができるようになっている。また、ＵＳＢ−ＨＵＢ１３には、他のＵＳＢデバイス１４なども接続されている。

本実施形態において、複合機１１は、プリンタ機能、スキャナ機能、ＰＣ−ＦＡＸ機能、カードリーダ機能などを備える多機能デバイスで、これらの機能をＰＣ１２から制御できるようになっている。

［複合機の内部構成］
図２は、複合機１１の内部構成を示すブロック図である。
複合機１１は、ＵＳＢインターフェースを構成するためのハードウェアとして、ＵＳＢプロトコルエンジン１０１、制御回路１０３、およびカードリーダ系データ入出力回路１０５などを備えている。ＰＣ１２との間でデータ伝送を行う際には、上記ＵＳＢプロトコルエンジン１０１による制御下で、ＵＳＢ規格の通信プロトコルにてデータが伝送される。

これらのハードウェアは、エンドポイントを介してＰＣ１２との間でデータを伝送するように構成されている。具体的には、制御回路１０３は、コントロール転送用のエンドポイント（以下、ＥＰ０と称する。）を介して、ＰＣ１２との間で各種制御データの入出力（双方向通信）を行う。

また、カードリーダ系データ入出力回路１０５は、入力データ用のエンドポイント（以下、ＥＰ１と称する。）を介して、ＰＣ１２への入力データを伝送する。また、カードリーダ系データ入出力回路１０５は、出力データ用のエンドポイント（以下、ＥＰ２と称する。）を介して、ＰＣ１２から伝送されてくる出力データを取得する。

また、複合機１１は、複合機１１内で機能するソフトウェアの１つとして、ＳＣＳＩコマンド解析タスク１１１を備えている。
カードリーダ系データ入出力回路１０５からＳＣＳＩコマンド解析タスク１１１へデータが伝送されてきた場合、ＳＣＳＩコマンド解析タスク１１１は、データ中に含まれる情報に基づいて、ＬＵＮ０側またはＬＵＮ１側のどちらかへデータを振り分ける。

また、ＬＵＮ０側またはＬＵＮ１側のどちらかからＳＣＳＩコマンド解析タスク１１１へデータが伝送されてきた場合、ＳＣＳＩコマンド解析タスク１１１は、そのデータをカードリーダ系データ入出力回路１０５へ伝送する。

ＳＣＳＩコマンド解析タスク１１１がＬＵＮ０側へデータを振り分けた場合、そのデータはメモリスロット入出力制御タスク１２１へと伝送される。メモリスロット入出力制御タスク１２１は、第１メモリスロット１３１、第２メモリスロット１３２、第３メモリスロット１３３、および第４メモリスロット１３４を制御するためのソフトウェアである。

第１メモリスロット１３１、第２メモリスロット１３２、第３メモリスロット１３３、第４メモリスロット１３４は、いずれもメモリカードがマウントされるスロットで、それぞれが他のスロットとは異なる規格のメモリカードをマウントできる構造になっている。

なお、本実施形態において、第１メモリスロット１３１、第２メモリスロット１３２、第３メモリスロット１３３、および第４メモリスロット１３４は、それぞれが排他的に利用可能となるものである。例えば、第１メモリスロット１３１にメモリカードがマウントされた場合、そのメモリカードがアンマウントされるまで、他のスロットは利用不能となる。

一方、ＳＣＳＩコマンド解析タスク１１１がＬＵＮ１側へデータを振り分けた場合、そのデータはリソースマネージャタスク１４１へと伝送される。リソースマネージャタスク１４１は、実データ部に格納された独自規格の情報に基づいて、プリンタ入出力タスク１５１、スキャナ入出力タスク１５３、ＰＣ−ＦＡＸ入出力タスク１５５のいずれかへデータを振り分ける。

また、プリンタ入出力タスク１５１、スキャナ入出力タスク１５３、ＰＣ−ＦＡＸ入出力タスク１５５のいずれかからリソースマネージャタスク１４１へデータが伝送されてきた場合、リソースマネージャタスク１４１は、そのデータをＳＣＳＩコマンド解析タスク１１１へ伝送する。

プリンタ入出力タスク１５１、スキャナ入出力タスク１５３、ＰＣ−ＦＡＸ入出力タスク１５５は、それぞれ印字制御タスク１６１、スキャナ制御タスク１６３、モデム制御タスク１６５を介して、プリンタハードウェア１７１、スキャナハードウェア１７３、モデムハードウェア１７５を制御する。

以上のように構成された複合機１１において、ＰＣ１２のＯＳには、メモリスロット入出力制御タスク１２１の制御下にある構成が、ＬＵＮ０に対応する論理ユニットとして認識される。また、ＰＣ１２のＯＳには、リソースマネージャタスク１４１の制御下にある構成が、ＬＵＮ１に対応する論理ユニットとして認識される。

しかも、リソースマネージャタスク１４１の制御下にある構成は、プリンタ機能、スキャナ機能、ＰＣ−ＦＡＸ機能、以上３機能に対応する構成であり、ＬＵＮ１に対応する論理ユニットは、本発明でいう複合論理ユニットに相当するものである。

図３は、プリンタ入出力タスク１５１、スキャナ入出力タスク１５３、およびＰＣ−ＦＡＸ入出力タスク１５５とリソースマネージャタスク１４１との間のデータ伝送経路を、より詳細に示したブロック図である。

プリンタ入出力タスク１５１、スキャナ入出力タスク１５３、およびＰＣ−ＦＡＸ入出力タスク１５５は、データ伝送用の共有メモリを介して、リソースマネージャタスク１４１との間で各種データをやり取りするように構成されている。

具体的には、共有メモリ上には、プリンタ入出力タスク１５１、スキャナ入出力タスク１５３、およびＰＣ−ＦＡＸ入出力タスク１５５が共用するコントロールエリア１８１が設けられている。このコントロールエリア１８１は、プリンタ入出力タスク１５１、スキャナ入出力タスク１５３、およびＰＣ−ＦＡＸ入出力タスク１５５とリソースマネージャタスク１４１との間で制御データの伝送を行う際に利用される。

また、共有メモリ上には、プリンタ入出力タスク１５１に対応する出力バッファ１８２および入力バッファ１８３が設けられている。これらの出力バッファ１８２および入力バッファ１８３は、プリンタ入出力タスク１５１とリソースマネージャタスク１４１との間でデータの伝送を行う際に利用される。また、プリンタ入出力タスク１５１は、リソースマネージャタスク１４１に対してシグナルを伝達することができるようになっている。

また、共有メモリ上には、スキャナ入出力タスク１５３に対応する出力バッファ１８４および入力バッファ１８５が設けられている。これらの出力バッファ１８４および入力バッファ１８５は、スキャナ入出力タスク１５３とリソースマネージャタスク１４１との間でデータの伝送を行う際に利用される。また、スキャナ入出力タスク１５３は、リソースマネージャタスク１４１に対してシグナルを伝達することができるようになっている。

また、共有メモリ上には、ＰＣ−ＦＡＸ入出力タスク１５５に対応する出力バッファ１８６および入力バッファ１８７が設けられている。これらの出力バッファ１８６および入力バッファ１８７は、ＰＣ−ＦＡＸ入出力タスク１５５とリソースマネージャタスク１４１との間でデータの伝送を行う際に利用される。また、ＰＣ−ＦＡＸ入出力タスク１５５は、リソースマネージャタスク１４１に対してシグナルを伝達することができるようになっている。

さらに、リソースマネージャタスク１４１は、次ＰＣ送信用バッファ１９１に対するデータのリード／ライトができるようになっている。次ＰＣ送信用バッファ１９１は、次にＰＣ１２へ送信するためのデータを、ＰＣ１２への送信前にコントロールエリア１８１、入力バッファ１８３、１８５、１８７から先読みして、一時的に格納しておくために利用されるバッファである。

［ＰＣの内部構成］
図４は、ＰＣ１２の内部構成を示すブロック図である。
ＰＣ１２においては、ＯＳによる標準機能として、ＵＳＢプロトコルスタック２０１、ＵＳＢストレージドライバ２０３、ＳＣＳＩコマンド処理部２１１、２１３、リムーバブルディスクドライバ２２１、２２３、ファイルシステム２３１、２３３などが機能する。

また、ＰＣ１２においては、複合機１１に対応する専用ソフトウェアとして、リソースマネージャ２４１（本発明でいうデータ管理手段の一例に相当）、プリントポートドライバ２５１、スキャナドライバ２５３（本発明でいうデバイスドライバの一例に相当）、ＣＯＭポートドライバ２５５（本発明でいうデバイスドライバの一例に相当）、プリンタドライバ２６１（本発明でいうデバイスドライバの一例に相当）などが機能する。

さらに、ＰＣ１２においては、これらの機能を利用するアプリケーションソフトウェアとして、印刷可能アプリケーション２７１、スキャン可能アプリケーション２７３、ＰＣ−ＦＡＸアプリケーション２７５などが機能する。

加えて、本実施形態において、ＰＣ１２が備えるＯＳとしては、Ｗｉｎｄｏｗｓ（登録商標）が利用されており、ＰＣ１２においては、Ｗｉｎｄｏｗｓ（登録商標）付属のソフトウェアであるエクスプローラ２７７なども機能する。ただし、ＰＣ１２が備えるＯＳは、同等な機能を実現できるものであれば、Ｗｉｎｄｏｗｓ（登録商標）以外のＯＳであってもよい。

なお、ＰＣ１２においては、他のＵＳＢデバイス１４に対応する他のＵＳＢデバイスのドライバ２８１なども機能する。
これらの内、ＵＳＢプロトコルスタック２０１は、ＰＣ１２の起動に伴って機能し、その後は、図５に示すように、ＰＣ１２にＵＳＢデバイスが接続されたかどうかを定期的に監視する。

ここで、複合機１１がＰＣ１２に接続された場合は、複合機１１からの応答がＰＣ１２に返されるので、ＵＳＢプロトコルスタック２０１は、複合機１１に対してデバイスタイプについての応答を要求する。この要求に対し、複合機１１はＵＳＢストレージクラスである旨の応答を返すので（この応答を返す構成（複合機１１が備えるＣＰＵ等）が、本発明でいう応答手段の一例に相当）、ＰＣ１２では、ＵＳＢストレージドライバ２０３がロードされ、その結果、ＵＳＢストレージドライバ２０３が機能する状態に移行する。

ＵＳＢストレージドライバ２０３が機能すると、ＵＳＢストレージドライバ２０３は、複合機１１に対して最大ＬＵＮを要求する。この要求に対し、複合機１１は最大ＬＵＮ（本実施形態の場合はＬＵＮ１）を返すので、ＰＣ１２では、ＬＵＮ０およびＬＵＮ１に対応する２つのＳＣＳＩコマンド処理部２１１、２１３が作られる。これらＳＣＳＩコマンド処理部２１１、２１３は、ＵＳＢストレージドライバ２０３経由で複合機へＳＣＳＩコマンドを伝送するための入口である。

ＳＣＳＩコマンド処理部２１１が作られると、ＳＣＳＩコマンド処理部２１１は、ＬＵＮ０の論理ユニットに対してＳＣＳＩコマンドの“Ｉｎｑｕｉｒｙ”を発行する。これに対し、複合機１１からはリムーバブルＨＤである旨の応答が返されるので、ＰＣ１２では、リムーバブルディスクドライバ２２１がロードされる。

これにより、ＬＵＮ０の論理ユニットがファイルシステム２３１と結合し、その結果、ＬＵＮ０の論理ユニットに対応するドライブレターが割り当てられる。以降、そのドライブレターを指定すれば、ＬＵＮ０の論理ユニットに対するアクセスを行うことができる状態になる。なお、複合機１１において、ＬＵＮ０に対応する論理ユニットは、メモリスロット入出力制御タスク１２１の制御下にある構成である。

ＳＣＳＩコマンド処理部２１３も、ＳＣＳＩコマンド処理部２１１と同等な処理を実行し、ＬＵＮ１の論理ユニットに対してＳＣＳＩコマンドの“Ｉｎｑｕｉｒｙ”を発行する。これに対し、複合機１１からはリムーバブルＨＤである旨の応答が返される（この応答を返す構成（複合機１１が備えるＣＰＵ等）が、本発明でいう応答手段の一例に相当）。

ここで、複合機１１において、ＬＵＮ１に対応する論理ユニットは、リソースマネージャタスク１４１の制御下にある構成であり、具体的には、プリンタ機能、スキャナ機能、ＰＣ−ＦＡＸ機能、以上３機能に対応する構成である。

したがって、これらの構成は、リムーバブルＨＤに相当するものではないが、複合機１１は、リムーバブルＨＤである旨の応答を返すことで、ＰＣ１２のＯＳに対しては、擬似的にリムーバブルＨＤに相当する挙動を示すデバイスとして振る舞う。

そのため、ＰＣ１２では、リムーバブルディスクドライバ２２１がロードされ、これにより、ＬＵＮ１の論理ユニットがファイルシステム２３３と結合し、その結果、ＬＵＮ１の論理ユニットに対応するドライブレターが割り当てられる。

ただし、上述の通り、このドライブレターに対応するリムーバブルディスクは、擬似的なものであり、実際には、リムーバブルディスク相当のデバイスが存在する訳ではない。そのため、この擬似的なリムーバブルディスクについては、通常の操作では利用者から存在が見えないように表示設定が変更される。

その結果、擬似的なリムーバブルディスクには、内部的にはドライブレターが割り当てられているものの、例えば、エクスプローラ２７７でＰＣ１２に接続されたデバイスの一覧を表示しても、擬似的なリムーバブルディスクは表示されない設定になる。

以上のような構成において、ＬＵＮ０の論理ユニットに対応するドライブレターを利用すれば、第１メモリスロット１３１、第２メモリスロット１３２、第３メモリスロット１３３、および第４メモリスロット１３４の内、いずれかにマウントされたメモリカードにアクセスすることができる。

例えば、エクスプローラ２７７を利用して、第１メモリスロット１３１にマウントされたメモリカード内のファイルに対する操作が行われると、エクスプローラ２７７からの指令は、ファイルシステム２３１、リムーバブルディスクドライバ２２１、ＳＣＳＩコマンド処理部２１１、ＵＳＢストレージドライバ２０３、ＵＳＢプロトコルスタック２０１経由で、複合機１１へと伝送される。

また、複合機１１からの応答は、ＵＳＢプロトコルスタック２０１、ＵＳＢストレージドライバ２０３、ＳＣＳＩコマンド処理部２１１、リムーバブルディスクドライバ２２１、ファイルシステム２３１経由で、エクスプローラ２７７へと戻される。

一方、印刷可能アプリケーション２７１から出力される印刷データは、プリンタドライバ２６１、プリントポートドライバ２５１経由で、リソースマネージャ２４１へと伝送される。また、スキャン可能アプリケーション２７３から出力されるスキャナ制御データは、スキャナドライバ２５３経由で、リソースマネージャ２４１へと伝送される。また、ＰＣ−ＦＡＸアプリケーション２７５から出力されるＰＣ−ＦＡＸデータは、ＣＯＭポートドライバ２５５経由で、リソースマネージャ２４１へと伝送される。

リソースマネージャ２４１は、これら様々なデータを、複合機１１が備えるリソースマネージャタスク１４１で処理できるような独自規格の情報（ベンダーユニークデータ）として、伝送対象となるデータ中の実データ部に格納する。

そして、そのデータを上述した擬似的なリムーバブルディスクに対して書き込む旨の指令を発行することにより、ＳＣＳＩコマンド処理部２１３、ＵＳＢストレージドライバ２０３、ＵＳＢプロトコルスタック２０１経由で、複合機１１へと伝送する。

また、上記のようなデータ伝送の結果、ＰＣ１２への入力データが複合機１１側から伝送されてくる場合がある。例えば、スキャナ制御データを複合機１１へ伝送した場合であれば、複合機１１においてスキャン機能が作動し、その結果、スキャンデータが複合機１１側から伝送されてくる。

このようなＰＣ１２への入力データは、ＵＳＢプロトコルスタック２０１、ＵＳＢストレージドライバ２０３、ＳＣＳＩコマンド処理部２１３経由で、リソースマネージャ２４１へと伝送されてくる。

リソースマネージャ２４１は、伝送されてきたデータ中に含まれる実データ部から、独自規格の情報（ベンダーユニークデータ）を取り出す。そして、そのデータをプリントポートドライバ２５１、スキャナドライバ２５３、ＣＯＭポートドライバ２５５のいずれに伝送すべきかを判断した上で、いずれかへ伝送する。

その結果、例えば、スキャンデータが複合機１１側から伝送されてきた場合であれば、そのデータは、スキャナドライバ２５３経由で、スキャン可能アプリケーション２７３へと伝送されることになる。

また、プリンタ機能についてのステータスデータ（例えば、印刷エラーに関する情報等）であれば、プリントポートドライバ２５１、プリンタドライバ２６１経由で、印刷可能アプリケーション２７１へと伝送されることになる。

さらに、ＰＣ−ＦＡＸ機能によるファクシミリ受信データであれば、ＣＯＭポートドライバ２５５経由で、ＰＣ−ＦＡＸアプリケーションへと伝送されることになる。
図６は、プリントポートドライバ２５１、スキャナドライバ２５３、およびＣＯＭポートドライバ２５５とリソースマネージャ２４１との間のデータ伝送経路を、より詳細に示したブロック図である。

プリントポートドライバ２５１、スキャナドライバ２５３、およびＣＯＭポートドライバ２５５は、データ伝送用の共有メモリを介して、リソースマネージャ２４１との間で各種データをやり取りするように構成されている。

具体的には、共有メモリ上には、プリントポートドライバ２５１、スキャナドライバ２５３、およびＣＯＭポートドライバ２５５が共用するコントロールエリア２９１が設けられている。このコントロールエリア２９１は、プリントポートドライバ２５１、スキャナドライバ２５３、およびＣＯＭポートドライバ２５５とリソースマネージャ２４１との間で制御データの伝送を行う際に利用される。

また、共有メモリ上には、プリントポートドライバ２５１に対応する出力バッファ２９２および入力バッファ２９３が設けられている。これらの出力バッファ２９２および入力バッファ２９３は、プリントポートドライバ２５１とリソースマネージャ２４１との間でデータの伝送を行う際に利用される。

また、共有メモリ上には、スキャナドライバ２５３に対応する出力バッファ２９４および入力バッファ２９５が設けられている。これらの出力バッファ２９４および入力バッファ２９５は、スキャナドライバ２５３とリソースマネージャ２４１との間でデータの伝送を行う際に利用される。

また、共有メモリ上には、ＣＯＭポートドライバ２５５に対応する出力バッファ２９６および入力バッファ２９７が設けられている。これらの出力バッファ２９６および入力バッファ２９７は、ＣＯＭポートドライバ２５５とリソースマネージャ２４１との間でデータの伝送を行う際に利用される。

ちなみに、以上のように構成された複合機１１およびＰＣ１２において、リソースマネージャ２４１とリソースマネージャタスク１４１との間のデータ伝送に着目すると、両者間では、ＳＣＳＩ規格に準拠したデータ構造を持つデータが伝送される。

このＳＣＳＩ規格に準拠したデータ構造の中には、ベンダーユニークデータと呼ばれるデータを格納することができる。ベンダーユニークデータは、リソースマネージャ２４１とリソースマネージャタスク１４１は、それぞれが認識可能な独自規格の情報であればよく、ＯＳ等は、ベンダーユニークデータの中身については関知しない。

したがって、リソースマネージャ２４１とリソースマネージャタスク１４１との間でやり取りしたい実データについては、上記のようなベンダーユニークデータとして伝送することで、ＳＣＳＩ規格に準拠した方式で任意のデータをやり取りすることができる。また、ＵＳＢ規格ではＳＣＳＩ規格に準拠した方式のデータをやり取りする方式が規定されているので、ＳＣＳＩ規格に準拠した方式で任意のデータをやり取りすることができれば、同じくＵＳＢ規格に準拠した方式でも任意のデータをやり取りできることになる。

［複合機用ソフトウェアのインストール処理］
次に、上記のような複合機１１をＰＣ１２から利用可能とするため、ＰＣ１２において実行される複合機用ソフトウェアのインストール処理について、図７および図８のフローチャートに基づいて説明する。

この処理を開始すると、ＰＣ１２は、図７に示すように、まずインストーラを起動する（Ｓ１０５）。このＳ１０５の処理は、利用者が所定の操作を行うと実行されるようになっていてもよいし、ＣＤ−ＲＯＭなどのメディアをＣＤ−ＲＯＭドライブなどにセットすると、それに連動して自動的に実行されるようになっていてもよい。

インストーラを起動すると、続いて、ＰＣ１２は、該当複合機のリソースマネージャ用ドライブを検索する（Ｓ１１０）。このＳ１１０の処理は、詳しくは図８に示すような処理となる。

すなわち、ＰＣ１２は、ドライブレター“Ａ”〜“Ｚ”を順に検索対象とするため、図８に示すように、まず、初期値としてドライブレター“Ａ”を変数ＣＤＲＶにセットする（Ｓ２０５）。そして、ドライブＣＤＲＶ（すなわち、Ｓ２０５の処理直後はドライブ“Ａ”）に、ＳＣＳＩコマンドの“Ｉｎｑｕｉｒｙ”を発行する（Ｓ２１０）。このコマンドは、デバイスの種類等を照会するために利用されるコマンドである。

Ｓ２１０の処理において、コマンドに対する応答が正常に返された場合は（Ｓ２１０：正常）、応答中に含まれるベンダ名とプロダクト名から、ドライブＣＤＲＶが、対象としている複合機１１に該当するドライブなのか否かを判断する（Ｓ２１５）。

Ｓ２１５の処理による判断の結果、該当ドライブであれば（Ｓ２１５：該当ドライブである）、対象としている複合機１１に該当するドライブが見つかったことになる（ＣＤＲＶが見つかったドライブである）ので、この場合は、図８に示す処理を終了する。

一方、Ｓ２１５の処理による判断の結果、対象としている複合機１１に該当するドライブではなかった場合は（Ｓ２１５：該当ドライブでない）、Ｓ２２０の処理へと進む。また、Ｓ２１０の処理において、コマンドに対する応答としてエラーが返された場合も（Ｓ２１０：エラー）、Ｓ２２０の処理へと進む。Ｓ２２０の処理へ進んだ場合、変数ＣＤＲＶにセットされたドライブレターが“Ｚ”であるか否かを判断する（Ｓ２２０）。

Ｓ２２０の処理において、変数ＣＤＲＶにセットされたドライブレターが“Ｚ”でなければ（Ｓ２２０：いいえ）、次のドライブのドライブレター（例えば、“Ａ”の次であれば“Ｂ”）を変数ＣＤＲＶにセットして（Ｓ２２５）、Ｓ２１０の処理へ戻る。

その結果、変数ＣＤＲＶにセットされたドライブレターが“Ｚ”とならない限り、Ｓ２１０〜Ｓ２２０の処理が繰り返されることになる。そして、その繰り返し処理において、Ｓ２１５の処理による判断の結果、該当ドライブが見つかれば、図８に示す処理を終了することになる。

一方、Ｓ２２０の処理において、変数ＣＤＲＶにセットされたドライブレターが“Ｚ”であれば（Ｓ２２０：はい）、ドライブレター“Ａ”〜“Ｚ”をすべて処理したことになる。したがって、この場合は、対象としている複合機１１に該当するドライブが見つからなかったことになり、その場合も、図８に示す処理を終了する。

以上のようにして図８に示す処理を終了すると、図７に示したＳ１１０の処理を終了したことになる。図７に示すように、Ｓ１１０の処理の結果、リソースマネージャ用ドライブが見つからなかった場合（Ｓ１１０：見つからなかった）、ＰＣ１２は、「複合機１１とＵＳＢ接続を行い暫く待った後にＯＫを押すこと」を利用者に対して指示するダイヤログを表示する（Ｓ１１５）。

このＳ１１５の処理により、ＰＣ１２は利用者からの入力待ち状態になる。ここで、利用者は、ＰＣ１２の表示部に表示されたダイヤログにおいて、「ＯＫ」または「キャンセル」を押す操作（＝例えば、表示部に表示された「ＯＫ」ボタンまたは「キャンセル」ボタンを、ポインティングデバイスでクリックする操作）を行うことができる。

利用者が「キャンセル」を押した場合（Ｓ１１５：キャンセル）、インストール処理は中止される。一方、利用者が「ＯＫ」を押した場合（Ｓ１１５：ＯＫ）、ＰＣ１２は、再びＳ１１０の処理を実行する。

また、Ｓ１１０の処理において、リソースマネージャ用ドライブが見つかった場合（Ｓ１１０：見つかった）、ＰＣ１２は、見つかった「リソースマネージャ用ドライブ」を隠す（Ｓ１２０）。ＰＣ１２において、ドライブレターが割り当てられたデバイスを表示する設定にするか隠す設定にするかは、ドライブレター毎にレジストリ（ＯＳが管理する記憶領域）に登録される。

Ｓ１２０の処理では、Ｓ１１０の処理によって見つかったリソースマネージャ用ドライブのドライブレターを対象にして、デバイスを隠す設定となるようにレジストリを変更する。なお、このＳ１２０の処理を実行する構成（ＰＣ１２の備えるＣＰＵ等）が、本発明でいう表示設定変更手段の一例に相当する。

続いて、ＰＣ１２は、リソースマネージャをインストールし、該当複合機機種名をＩＮＩファイルに設定する（Ｓ１２５）。ＩＮＩファイルは、リソースマネージャに関する各種設定が記録されたテキストファイルである。このＩＮＩファイルに記録された内容は、リソースマネージャが後述する処理を実行した際に、リソースマネージャによって読み込まれることになるものである。Ｓ１２５の処理では、Ｓ２１０の処理において取得された「複合機機種名」がＩＮＩファイルに格納される。

その後、ＰＣ１２は、プリンタドライバ、プリントポートドライバ、スキャナドライバ、ＣＯＭポートドライバ、ＰＣ−ＦＡＸアプリケーションをインストールして（Ｓ１３０）、複合機用ソフトウェアのインストール処理を終了する。

［ＰＣの電源ＯＮから電源ＯＦＦに至るまでに実行される処理の一例］
次に、ＰＣの電源ＯＮから電源ＯＦＦに至るまでに実行される処理の一例について、図９〜図１２に基づいて説明する。なお、以下に説明する処理の一例は、複合機１１の電源スイッチがＯＮにされている状態で、ＰＣ１２の電源スイッチがＯＮにされた場合の例である。

ＰＣ１２の電源スイッチがＯＮにされた場合、ＰＣ１２は、図９に示すように、まず、ＯＳをロードし（Ｓ３０５）、続いて、スタティックドライバをロードする（Ｓ３１０）。Ｓ３１０の処理は、詳しくは図１０に示す処理となる。

すなわち、ＰＣ１２では、図１０に示すように、まず、ＯＳがレジストリ設定を参照して、スタティックドライバを順次ロードする（Ｓ４０５）。そして、本発明の構成に関連する処理としては、プリンタドライバをロードし（Ｓ４１０）、プリントポートドライバをロードし（Ｓ４１５）、スキャナドライバをロードし（Ｓ４２０）、ＣＯＭポートドライバをロード（Ｓ４２５）して、図１０に示す処理を終了する。

図１０に示す処理を終了すると、図９に示すＳ３１０の処理を終了したことになるので、ＰＣ１２は、続いて、ダイナミックドライバをロードする（Ｓ３１５）。Ｓ３１５の処理は、詳しくは図１１に示す処理となる。

すなわち、ＰＣ１２では、図１１に示すように、まず、ＯＳがハードウェア接続状態を参照して、ダイナミックドライバを順次ロードする（Ｓ５０５）。そして、本発明の構成に関連する処理としては、ＵＳＢプロトコルスタック２０１が複合機１１を見つけた場合、複合機１１にデバイスタイプを問い合わせる（Ｓ５１０）。

そして、この問い合わせに対し、複合機１１からＵＳＢストレージデバイスである旨の返答が有った場合、ＰＣ１２は、ＵＳＢストレージドライバ２０３をロードする（Ｓ５１５）。

このＳ５１５の処理により、ＵＳＢストレージドライバ２０３が機能する状態となり、引き続いて、ＵＳＢストレージドライバ２０３が複合機１１にＬＵＮ数を問い合わせる（Ｓ５２０）。より具体的には、Ｓ５２０の処理において、ＵＳＢストレージドライバ２０３は、最大ＬＵＮを問い合わせる。

本実施形態の場合、複合機１１は２つの論理ユニットを備え、それらの論理ユニットに対し、ＬＵＮとして最小ＬＵＮを“０”とする連番を割り当てているので、最大ＬＵＮとしては“１”が返されることになる。

ＰＣ１２は、最大ＬＵＮとして“１”が返されたことをもって、複合機１１からＬＵＮ数が２個であると返答が有ったものと認識し、その場合、ＳＣＳＩコマンド処理の入り口を２個作る（Ｓ５２５）。このＳ５２５の処理により、ＳＣＳＩコマンド処理部２１１、２１３が構成されることになる。

ＳＣＳＩコマンド処理部２１１、２１３が機能する状態になると、ＳＣＳＩコマンド処理部２１１は、ＬＵＮ０の論理ユニットに対して“Ｉｎｑｕｉｒｙ”を発行する（Ｓ５３０）。

これに対し、ＬＵＮ０の論理ユニットからは“リムーバブルＨＤ”と返答が有る。この場合、ＰＣ１２は、リムーバブルディスクドライバ２２１をロードし、ファイルシステム２３１と結合、その結果、ＬＵＮ０の論理ユニットにドライブレターが割り当てられ、ドライブレターが出現することになる（Ｓ５３５）。

また、ＳＣＳＩコマンド処理部２１３は、ＬＵＮ１の論理ユニットに対して“Ｉｎｑｕｉｒｙ”を発行する（Ｓ５４０）。これに対し、ＬＵＮ１の論理ユニットからは“リムーバブルＨＤ”で有る旨の返答が有る。

複合機１１において、ＬＵＮ１の論理ユニットは、プリンタ機能、スキャナ機能、およびＰＣ−ＦＡＸ機能に対応するものであり、実際には、“リムーバブルＨＤ”相当のデバイスとして機能する論理ユニットではない。しかし、複合機１１は、“リムーバブルＨＤ”で有る旨の返答を返すことで、ＰＣ１２のＯＳに対しては、複合機１１を２ドライブの“リムーバブルＨＤ”で有ると認識させる。

ＬＵＮ１の論理ユニットから“リムーバブルＨＤ”である旨の返答が有った場合、ＰＣ１２は、リムーバブルディスクドライバ２２３をロードしてファイルシステム２３３と結合、その結果、ＬＵＮ１の論理ユニットにドライブレターが割り当てられる。

ただし、ＬＵＮ１の論理ユニットに割り当てられるドライブレターは、上述したＳ１２０の処理で、隠す設定にされたドライブに対応するものである。そのため、ドライブレターが内部的には出来るものの、エクスプローラ２７７では表示されないものとなる（Ｓ５４５）。

こうして図１１に示したダイナミックドライバのロード処理を終えると、図９に示したＳ３１５の処理を終えたことになるので、続いて、ＰＣ１２は、サービスプロセスをロードして（Ｓ３２０）、ログイン待ちになる（Ｓ３２５）。

Ｓ３２５の処理は、利用者がログイン操作を行うまで継続される（Ｓ３２５：ログインまだ）。そして、利用者がログイン操作を行った場合（Ｓ３２５：ログインした）、ＰＣ１２は、自動起動プログラムを起動する（Ｓ３３０）。Ｓ３３０の処理は、詳しくは図１２に示す処理となる。

すなわち、ＰＣ１２では、図１２に示すように、まず、ＯＳがスタートメニューのスタートアップを参照して、自動起動プログラムを順次起動する（Ｓ６０５）。そして、本発明の構成に関連する処理としては、リソースマネージャ２４１を起動する（Ｓ６１０）。Ｓ６１０の処理によって起動されたリソースマネージャ２４１が実行する処理の内容については、後から詳しく説明する。

そして、図１２に示した自動起動プログラムの起動処理を終えたら、ＰＣ１２は、通常状態に至る（Ｓ３５５）。この通常状態に至れば、利用者は任意に印刷可能アプリケーション２７１、スキャン可能アプリケーション２７３、ＰＣ−ＦＡＸアプリケーション２７５、エクスプローラ２７７などを利用することができる。

さて、その後、利用者がログアウト操作またはシャットダウン操作を行った場合（Ｓ３５５：ログアウトまたはシャットダウン）、ＰＣ１２は、まず、自動起動プログラムおよび手動起動プログラムを終了させる（Ｓ３４０）。そして、ログアウト操作がなされたのであれば（Ｓ３４０：ログアウトの場合）、Ｓ３２５の処理へ戻る。

一方、シャットダウン操作がなされたのであれば（Ｓ３４０：シャットダウンの場合）、サービスプロセスアンロードし（Ｓ３４５）、ダイナミックドライバをアンロードし（Ｓ３５０）、スタティックドライバをアンロードする（Ｓ３５５）。そして、最後にＯＳをアンロードして（Ｓ３６０）、ＰＣ１２の電源ＯＦＦに至る。Ｓ３４５〜Ｓ３６０の処理では、Ｓ３０５〜Ｓ３２０の処理とは逆の手順で、各ソフトウェアのアンロードが行われることになる。

［リソースマネージャが実行する処理］
次に、上記Ｓ６１０の処理によって起動されるリソースマネージャ２４１が実行する処理について、図１３〜図１５に基づいて説明する。

リソースマネージャ２４１が起動された場合、リソースマネージャ２４１（より厳密には、リソースマネージャ２４１としての処理を実行するＰＣ１２；以下、単にリソースマネージャ２４１と称する。）は、対象とすべき複合機１１の機種名やその他の設定を、ＩＮＩファイルから読み込む（Ｓ７０５）。このＳ７０５の処理では、上述したＳ１２５の処理等により、ＩＮＩファイルに格納された各種情報が読み込まれることになる。

続いて、リソースマネージャ２４１は、該当複合機のリソースマネージャ用ドライブを検索する（Ｓ７１０）。このＳ７１０の処理は、既に説明した図８に示す処理と同等な処理となるので、ここでの説明は省略する。

Ｓ７１０の処理の結果、リソースマネージャ用ドライブが見つからなかった場合（Ｓ７１０：見つからなかった）、ＰＣ１２は、「複合機１１とＵＳＢ接続を行い暫く待った後にＯＫを押すこと」を利用者に対して指示するダイヤログを表示する（Ｓ７１５）。

このＳ７１５の処理により、ＰＣ１２は利用者からの入力待ち状態になる。ここで、利用者は、ＰＣ１２の表示部に表示されたダイヤログにおいて、「ＯＫ」または「キャンセル」を押す操作を行うことができる。

利用者が「キャンセル」を押した場合（Ｓ７１５：キャンセル）、リソースマネージャ２４１による処理は終了する。一方、利用者が「ＯＫ」を押した場合（Ｓ７１５：ＯＫ）、ＰＣ１２は、再びＳ７１０の処理を実行する。

また、Ｓ７１０の処理において、リソースマネージャ用ドライブが見つかった場合（Ｓ７１０：見つかった）、ＰＣ１２は、所定時間だけ待って（Ｓ７２０）、終了要求が有るか否かを判断する（Ｓ７２５）。

ここで、終了要求が無ければ（Ｓ７２５：無し）、リソースマネージャ２４１は、ＲｅａｄＢｕｆｆｅｒ処理（Ｓ７３０）、ＷｒｉｔｅＢｕｆｆｅｒ処理（Ｓ７３５）を実行し、Ｓ７２０へ戻る。以降、終了要求無い限り、Ｓ７２０〜Ｓ７３５の処理が繰り返される。また、終了要求が有れば（Ｓ７２５：有り）、リソースマネージャ２４１による処理は終了する。

Ｓ７２０〜Ｓ７３５の繰り返し処理の中で実行されるＲｅａｄＢｕｆｆｅｒ処理（Ｓ７３０）は、複合機１１からリソースマネージャ２４１へと伝送されてくる入力データを取得するための処理である。また、ＷｒｉｔｅＢｕｆｆｅｒ処理（Ｓ７３５）は、リソースマネージャ２４１から複合機１１へと伝送される出力データを送出するための処理である。

［ＲｅａｄＢｕｆｆｅｒ処理］
次に、上記Ｓ７３０のＲｅａｄＢｕｆｆｅｒ処理の詳細について、図１４に基づいて説明する。

ＲｅａｄＢｕｆｆｅｒ処理を開始すると、リソースマネージャ２４１は、リソースマネージャ用ドライブに対して、ＳＣＳＩコマンドの“ＲｅａｄＢｕｆｆｅｒ”を発行し（Ｓ８０５）、Ｓ８０５の処理によって得られた入力データが有るか否かを判断する（Ｓ８１０）。

ここで、入力データが無い場合は（Ｓ８１０：無し）、そのままＲｅａｄＢｕｆｆｅｒ処理を終了する。一方、入力データが有る場合（Ｓ８１０：有り）、リソースマネージャ２４１は、パケットの種類を判断する（Ｓ８１５）。

“ＲｅａｄＢｕｆｆｅｒ”を発行した際に、複合機１１からどのような入力データが返されるかは、複合機１１の仕様に依存しており、本実施形態の場合、コントロールパケット、プリンタパケット、スキャナパケット、ＣＯＭポートパケットのいずれかが返る。

これらの内のいずれのパケットであるかを示す情報、および、実データとなる情報は、本実施形態の場合、独自規格の情報となっている。そして、その独自規格の情報が、ＳＣＳＩ規格に準拠したデータ構造を持つパケット群の実データ部に、ベンダーユニークデータとして格納されて、複合機１１からＰＣ１２へと伝送されてくる。

そこで、Ｓ８１５の処理においては、ＳＣＳＩ規格のデータとして取得したパケット群の実データ部から、ベンダーユニークデータを抽出し、その中に格納された独自規格の情報に基づいて、パケットの種類が、コントロールパケット、プリンタパケット、スキャナパケット、またはＣＯＭポートパケットのいずれであるのかを判断する。

その判断の結果、パケットの種類がコントロールパケットの場合（Ｓ８１５：コントロールパケット）、リソースマネージャ２４１は、パケットの情報に従い、コントロールエリア２９１（図６参照）を変更し（Ｓ８２０）、ＲｅａｄＢｕｆｆｅｒ処理を終了する。

また、パケットの種類がプリンタパケットの場合（Ｓ８１５：プリンタパケット）、パケットのデータ部をプリンタ用の入力バッファ２９３に追加し（Ｓ８２５）、ＲｅａｄＢｕｆｆｅｒ処理を終了する。なお、Ｓ８２５の処理において、入力バッファ２９３がバッファフルとなっている場合は、入力バッファ２９３が空くまで待って、Ｓ８２５の処理を実行する。

また、パケットの種類がスキャナパケットの場合（Ｓ８１５：スキャナパケット）、パケットのデータ部をスキャナ用の入力バッファ２９５に追加し（Ｓ８３０）、ＲｅａｄＢｕｆｆｅｒ処理を終了する。なお、Ｓ８３０の処理において、入力バッファ２９５がバッファフルとなっている場合は、入力バッファ２９５が空くまで待って、Ｓ８３０の処理を実行する。

さらに、パケットの種類がＣＯＭポートパケットの場合（Ｓ８１５：ＣＯＭポートパケット）、パケットのデータ部をＣＯＭポート用の入力バッファ２９７に追加し（Ｓ８３５）、ＲｅａｄＢｕｆｆｅｒ処理を終了する。なお、Ｓ８３５の処理において、入力バッファ２９７がバッファフルとなっている場合は、入力バッファ２９７が空くまで待って、Ｓ８３５の処理を実行する。

［ＷｒｉｔｅＢｕｆｆｅｒ処理］
次に、上記Ｓ７３５のＷｒｉｔｅＢｕｆｆｅｒ処理の詳細について、図１５に基づいて説明する。

ＷｒｉｔｅＢｕｆｆｅｒ処理を開始すると、リソースマネージャ２４１は、まず、コントロールエリア２９１に、複合機１１に伝える情報が有るか否かを判断する（Ｓ９０５）。

ここで、伝える情報が有る場合（Ｓ９０５：有り）、伝える情報に従ってコントロールパケットを作成する（Ｓ９１０）。そして、リソースマネージャ用ドライブにＳＣＳＩコマンドの“ＷｒｉｔｅＢｕｆｆｅｒ”を発行して（Ｓ９１５）、ＷｒｉｔｅＢｕｆｆｅｒ処理を終了する。

“ＷｒｉｔｅＢｕｆｆｅｒ”を発行した際に、ＰＣ１２から複合機１１へ伝送される出力データが複合機１１においてどのように扱われるかは、複合機１１の仕様に依存している。本実施形態の場合、Ｓ９１０の処理では、独自規格に準拠してコントロールパケットである旨の情報と実データとなる情報が用意され、それら独自規格の情報が、ＳＣＳＩ規格に準拠したデータ構造を持つパケット群の実データ部に、ベンダーユニークデータとして格納される。そして、そのデータが、Ｓ９１５の処理により、ＰＣ１２から複合機１１へと伝送される。

一方、Ｓ９０５の処理において、コントロールエリア２９１に、複合機１１に伝える情報が無い場合（Ｓ９０５：無し）、後述する処理を実行するの先だって、前回パケット化したデバイスの、次のデバイスを処理対象として選択する際の起点にする（Ｓ９２０）。

Ｓ９２０の処理において、前回パケット化したデバイスとは、前回のＷｒｉｔｅＢｕｆｆｅｒ処理においてパケットの送信対象となったデバイスのことである。そして、その送信対象となり得るデバイスは、本実施形態の場合、プリンタ、スキャナ、モデム（ＰＣ−ＦＡＸ）のいずれかである。

より具体的には、前回パケット化したデバイスがプリンタの場合、Ｓ９２０の処理では、次のデバイスであるスキャナを起点にして処理対象を選択する。また、前回パケット化したデバイスがスキャナの場合、Ｓ９２０の処理では、次のデバイスであるモデム（ＰＣ−ＦＡＸ）を起点にして処理対象を選択する。また、前回パケット化したデバイスがモデム（ＰＣ−ＦＡＸ）の場合、Ｓ９２０の処理では、次のデバイスであるプリンタを起点にして処理対象を選択する。

そして、処理対象を選択したら、リソースマネージャ２４１は、その処理対象となるデバイス（プリンタ、スキャナ、モデムのいずれか）がフローＯＦＦ状態か否かを判断する（Ｓ９２５）。

ここで、処理対象となるデバイスにおいて十分にデータ処理が進んでいれば、そのデバイスについてはフローＯＦＦ状態にはないと判断される（Ｓ９２５：いいえ）。その場合、リソースマネージャ２４１は、出力バッファにデータが有るか否かを判断する（Ｓ９３０）。

より具体的には、Ｓ９３０の処理において、処理対象となるデバイスがプリンタである場合は、プリンタに対応する出力バッファ２９２にデータが有るか否かを判断する。同様に、処理対象となるデバイスがスキャナである場合は、スキャナに対応する出力バッファ２９４にデータが有るか否かを判断し、処理対象となるデバイスがモデムである場合は、モデムに対応する出力バッファ２９６にデータが有るか否かを判断する。

Ｓ９３０の処理において、出力バッファにデータが有れば（Ｓ９３０：有り）、出力バッファからデータを取り出してパケット化する（Ｓ９３５）。
このＳ９３５の処理においても、上述のＳ９１０の処理同様、独自規格に準拠して、どのデバイスに対応するパケットであるのかを示す情報と実データとなる情報が用意される。そして、それら独自規格の情報が、ＳＣＳＩ規格に準拠したデータ構造を持つパケット群の実データ部に、ベンダーユニークデータとして格納される。

このようなＳ９３５の処理を終えたら、上述したＳ９１５の処理へと進む。その結果、Ｓ９３５の処理で作成されたデータが、ＰＣ１２から複合機１１へと伝送されることになる。

一方、Ｓ９３０の処理において、出力バッファにデータが無かった場合（Ｓ９３０：無し）、あるいは、Ｓ９２５の処理において、デバイスがフローＯＦＦ状態であった場合（Ｓ９２５：はい）、Ｓ９４０の処理へと進む。

Ｓ９４０の処理では、今回の「ＷｒｉｔｅＢｕｆｆｅｒ処理」で、処理対象となり得るデバイスを一周調べたか否かを判断する（Ｓ９４０）。より具体的には、Ｓ９４０の処理では、処理対象となり得るデバイス（プリンタ、スキャナ、モデム）すべてについて、Ｓ９２５以降の処理が１度は実行されたか否かが判断される。

その結果、Ｓ９２５以降の処理が１度も実行されていないデバイスが残っていれば、まだ一周していないと判断される一方、Ｓ９２５以降の処理が１度も実行されていないデバイスが残っていなければ、一周調べたと判断される。

Ｓ９４０の処理において、まだ一周していないと判断された場合は（Ｓ９４０：まだ一周していない）、次のデバイスを処理対象として選択して（Ｓ９４０）、Ｓ９２５の処理へ戻る。また、Ｓ９４０の処理において、一周調べたと判断された場合は（Ｓ９４０：一周調べた）、ＷｒｉｔｅＢｕｆｆｅｒ処理を終了する。

なお、以上説明したＷｒｉｔｅＢｕｆｆｅｒ処理においては、先にＳ９０５の処理を行った後、その後で、Ｓ９３０処理を行っている。このような手順で処理を行えば、常に、コントロールエリア２９１に複合機１１に伝える情報が有るか否かが先に判断される。そして、その様な情報が無かった場合に、出力バッファ２９２、２９４、２９６のいずれかにデータが有るか否かが判断される。

したがって、コントロールエリア２９１に複合機１１に伝える情報が有る場合は、出力バッファ２９２、２９４、２９６のいずれかにデータが有るか否かを問わず、優先的にコントロールエリア２９１の情報を複合機１１に伝えることができる。よって、複合機１１に対して迅速に制御情報を伝達でき、出力バッファ２９２、２９４、２９６にあるデータの伝送に邪魔されることなく、適切な制御を実施することができる。

［ＳＣＳＩコマンド解析タスクにおいて実行される処理］
次に、複合機１１が備えるＳＣＳＩコマンド解析タスク１１１において実行される処理について、図１６に基づいて説明する。

この処理を開始すると、複合機１１は、まず、ＳＣＳＩコマンド待ちになる（Ｓ１００５）。ここで、ＰＣ１２からＳＣＳＩコマンドが伝送されてこなければ（Ｓ１００５：なし）、Ｓ１００５の処理へ戻る。

一方、ＰＣ１２からＳＣＳＩコマンドが伝送されて来たら（Ｓ１００５：あり）、そのＳＣＳＩコマンド中で指定されたＬＵＮが“０”か“１”かを判断する（Ｓ１０１０）。
Ｓ１０１０の処理による判断の結果、ＬＵＮが“０”の場合（Ｓ１０１０：ＬＵＮ＝０）、複合機１１は、ＳＣＳＩコマンドをメモリスロット入出力制御タスク１２１へ伝送して（Ｓ１０１５）、Ｓ１００５の処理へと戻る。

また、Ｓ１０１０の処理による判断の結果、ＬＵＮが“１”の場合（Ｓ１０１０：ＬＵＮ＝１）、ＳＣＳＩコマンドをリソースマネージャタスク１４１へ伝送して（Ｓ１０２０）、Ｓ１００５の処理へと戻る。

以上のような処理が、ＳＣＳＩコマンド解析タスク１１１において実行される結果、ＰＣ１２から伝送されてくるＳＣＳＩコマンドは、ＬＵＮに基づいてメモリスロット入出力制御タスク１２１またはリソースマネージャタスク１４１のいずれかに振り分けられる。以降、メモリスロット入出力制御タスク１２１またはリソースマネージャタスク１４１のそれぞれにおいてデータ処理が行われることになる。

なお、メモリスロット入出力制御タスク１２１で行われるデータ処理は、カードリーダ機能を有する周知のＵＳＢデバイスが実行している処理と同等な処理であり、この処理自体は周知の処理と差異がないので、詳細な説明については省略する。

一方、リソースマネージャタスク１４１で行われるデータ処理は、カードリーダ機能を有する周知のＵＳＢデバイスが実行している処理とは、全く異なる処理となる。具体的には、リソースマネージャ２４１から伝送されてくる独自規格のデータを解析し、さらにプリンタ機能、スキャナ機能、ＰＣ−ＦＡＸ機能のいずれかにデータを振り分ける処理が実行される。

すなわち、複合機１１は、ＰＣ１２のＯＳには、２ドライブのカードリーダ系デバイスとして認識され、ＰＣ１２がいずれのドライブにアクセスするかは、ＬＵＮによって指定している。しかし、ＬＵＮ１を指定した場合、リソースマネージャタスク１４１では、カードリーダ機能を有するＵＳＢデバイス相当の処理は実行されないのである。

そこで、以下、複合機１１が備えるリソースマネージャタスク１４１においてどのような処理が実行されるのかを、さらに詳細に説明する。
［リソースマネージャタスクにおいて実行される処理］
図１７は、複合機１１が備えるリソースマネージャタスク１４１において実行される処理のフローチャートである。

この処理を開始すると、複合機１１は、図１７に示すように、まず、ＳＣＳＩコマンドとシグナル待ちになる（Ｓ１１０５）。ここで、ＳＣＳＩコマンドとシグナル、いずれも到来しない場合は（Ｓ１１０５：どちらも無し）、Ｓ１１０５の処理へと戻ることにより、ＳＣＳＩコマンドまたはシグナルの到来を待ち受ける。

この状態において、ＰＣ１２からはＳＣＳＩコマンドが伝送されてくることがある。例えば、ＰＣ１２において、上述したＳ９１５の処理が実行され、リソースマネージャ用ドライブにＳＣＳＩコマンドの“ＷｒｉｔｅＢｕｆｆｅｒ”が発行された場合、ＰＣ１２からＳＣＳＩコマンドが伝送されてくる。

ＳＣＳＩコマンドが伝送されてきた場合（Ｓ１１０５：ＳＣＳＩコマンド）、複合機１１は、そのＳＣＳＩコマンドが“ＲｅａｄＢｕｆｆｅｒ”、“ＷｒｉｔｅＢｕｆｆｅｒ”、その他のいずれであるのかを判断する（Ｓ１１１０）。

ここで、上述したＳ９１５の処理が実行された場合であれば、ＳＣＳＩコマンドは“ＷｒｉｔｅＢｕｆｆｅｒ”なので（Ｓ１１１０：ＷｒｉｔｅＢｕｆｆｅｒ）、複合機１１は、パケットの種類を判断する（Ｓ１１１５）。

このＳ１１１５の処理による判断の結果、パケットの種類がコントロールパケットであった場合（Ｓ１１１５：コントロールパケット）、複合機１１は、パケットの情報に従い、コントロールエリア１８１を変更し（Ｓ１１２０）、Ｓ１１０５の処理へと戻る。

一方、パケットの種類がプリンタパケット、スキャナパケット、ＣＯＭポートパケットのいずれかであった場合（Ｓ１１１５：プリンタ、スキャナ、ＣＯＭポート）、パケットのデータ部を指定デバイスの出力バッファに追加する（Ｓ１１２５）。

具体的には、パケットの種類がプリンタパケットであれば、パケットのデータ部をプリンタの出力バッファ１８２に追加する。その結果、出力バッファ１８２を介してプリンタ入出力タスク１５１へ出力データが伝送される。なお、この出力データは、さらに印字制御タスク１６１へと伝送され、プリンタハードウェア１７１の制御が行われるが、この制御自体は周知のプリンタと同等な制御なので、ここでの説明は省略する。

また、パケットの種類がスキャナパケットであれば、パケットのデータ部をスキャナの出力バッファ１８４に追加する。その結果、出力バッファ１８４を介してスキャナ入出力タスク１５３へ出力データが伝送される。なお、この出力データは、さらにスキャナ制御タスク１６３へと伝送され、スキャナハードウェア１７３の制御が行われるが、この制御自体は周知のスキャナと同等な制御なので、ここでの説明は省略する。

さらに、パケットの種類がＣＯＭポートパケットであれば、パケットのデータ部をＣＯＭポートの出力バッファ１８６に追加する。その結果、出力バッファ１８６を介してＰＣ−ＦＡＸ入出力タスク１５５へ出力データが伝送される。なお、この出力データは、さらにモデム制御タスク１６５へと伝送され、モデムハードウェア１７５の制御が行われるが、この制御自体は周知のＦＡＸモデムと同等な制御なので、ここでの説明は省略する。

さて、以上のようなＳ１１１０〜Ｓ１１２５の処理により、ＰＣ１２からの出力データが複合機１１に到来した場合、複合機１１では、プリンタ機能、スキャナ機能、あるいは、ＰＣ−ＦＡＸ機能が作動する。そして、それらが作動した結果、ＰＣ１２への入力データが発生する場合がある。

具体例を挙げれば、スキャナ機能の利用を指令するコマンドがＰＣ１２から到来していた場合、複合機１１では、スキャナ機能が作動し、その結果、ＰＣ１２への入力データとしてスキャンデータが生成される。また、この他、ＰＣ−ＦＡＸ機能による受信データがある場合、プリンタ機能を利用したときのエラー情報がある場合など、様々な場合にＰＣ１２への入力データが発生する。

こうした入力データが発生した場合、プリンタ入出力タスク１５１、スキャナ入出力タスク１５３、ＰＣ−ＦＡＸ入出力タスク１５５は、その入力データを入力バッファ１８３、１８５、１８７に格納する。その上で、リソースマネージャタスク１４１に対してシグナルを送信する。

このようなシグナルがリソースマネージャタスク１４１に対して送信された場合（Ｓ１１０５：シグナル）、複合機１１は、次ＰＣ送信用バッファ１９１にデータが有るか否かを判断する（Ｓ１１３０）。

ここで、次ＰＣ送信用バッファにデータが無い場合（Ｓ１１３０：無し）、コントロールエリア１８１に、ＰＣ１２に伝える情報が有るか否かを判断する（Ｓ１１３５）。
Ｓ１１３５の処理において、コントロールエリア１８１に、ＰＣ１２に伝える情報が有る場合は（Ｓ１１３５：有り）、伝える情報に従ってコントロールパケットを作成して、そのパケットを次ＰＣ送信用バッファ１９１に置く（Ｓ１１４０）。そして、Ｓ１１０５の処理へと戻る。

一方、Ｓ１１３５の処理において、コントロールエリア１８１に、ＰＣ１２に伝える情報が無い場合は（Ｓ１１３５：無し）、前回パケット化したデバイスの、次のデバイスを処理対象として選択する際の起点にする（Ｓ１１４５）。

Ｓ１１４５の処理において、前回パケット化したデバイスとは、前回のＳ１１４５以降の処理において処理対象となったデバイスのことである。そして、その処理対象となり得るデバイスは、本実施形態の場合、プリンタ、スキャナ、モデム（ＰＣ−ＦＡＸ）のいずれかである。

より具体的には、前回パケット化したデバイスがプリンタの場合、Ｓ１１４５の処理では、次のデバイスであるスキャナを起点にして処理対象を選択する。また、前回パケット化したデバイスがスキャナの場合、Ｓ１１４５の処理では、次のデバイスであるモデム（ＰＣ−ＦＡＸ）を起点にして処理対象を選択する。また、前回パケット化したデバイスがモデム（ＰＣ−ＦＡＸ）の場合、Ｓ１１４５の処理では、次のデバイスであるプリンタを起点にして処理対象を選択する。

Ｓ１１４５の処理によって処理対象が選択されたら、続いて、その処理対象となるデバイスに対応する入力バッファにデータが有るか否かを判断する（Ｓ１１５０）。具体的には、処理対象となるデバイスがプリンタであれば、入力バッファ１８３にデータが有るか否かを判断する。また、処理対象となるデバイスがスキャナであれば、入力バッファ１８５にデータが有るか否かを判断する。また、処理対象となるデバイスがモデム（ＰＣ−ＦＡＸ）であれば、入力バッファ１８７にデータが有るか否かを判断する。

処理対象となるデバイスに対応する入力バッファにデータが有る場合（Ｓ１１５０：有り）、複合機１１は、入力バッファからデータを取り出してパケット化し、そのパケットを次ＰＣ送信用バッファに置いて（Ｓ１１５５）、Ｓ１１０５の処理へと戻る。

一方、処理対象となるデバイスに対応する入力バッファにデータが無い場合（Ｓ１１５０：無し）、今回のＳ１１４５以降の処理で、処理対象となり得るデバイスを一周調べたか否かを判断する（Ｓ１１６０）。より具体的には、Ｓ１１６０の処理では、処理対象となり得るデバイス（プリンタ、スキャナ、モデム）すべてについて、Ｓ１１５０以降の処理が１度は実行されたか否かが判断される。

その結果、Ｓ１１５０以降の処理が１度も実行されていないデバイスが残っていれば、まだ一周していないと判断される一方、Ｓ１１５０以降の処理が１度も実行されていないデバイスが残っていなければ、一周調べたと判断される。

Ｓ１１６０の処理において、まだ一周していないと判断された場合は（Ｓ１１６０：まだ一周していない）、次のデバイスを処理対象として選択して（Ｓ１１６５）、Ｓ１１５０の処理へ戻る。また、Ｓ１１６０の処理において、一周調べたと判断された場合は（Ｓ１１６０：一周調べた）、Ｓ１１０５の処理へと戻る。

以上説明したように、シグナルがリソースマネージャタスク１４１に対して送信された場合、Ｓ１１３５以降の処理が実行されれば、次ＰＣ送信用バッファ１９１にデータが格納されることになる。この次ＰＣ送信用バッファ１９１に格納されたデータは、ＰＣ１２において、上述したＳ８０５の処理が実行された際に、ＰＣ１２へと伝送されることになる。

より詳しくは、ＰＣ１２において上述したＳ８０５の処理が実行された場合、リソースマネージャ用ドライブにＳＣＳＩコマンドの“ＲｅａｄＢｕｆｆｅｒ”が発行され、その結果、複合機１１には、ＰＣ１２からＳＣＳＩコマンドが伝送されてくる。

伝送されてきたＳＣＳＩコマンドが“ＲｅａｄＢｕｆｆｅｒ”の場合（Ｓ１１１０：ＲｅａｄＢｕｆｆｅｒ）、複合機１１は、次ＰＣ送信用バッファ１９１の内容をＰＣ１２側に送信して、次ＰＣ送信用バッファ１９１をクリアする（Ｓ１１７０）。この時点で、次ＰＣ送信用バッファ１９１は空になる。その後は、上述したＳ１１３５の処理へと進む。

以下、先に説明したＳ１１３５の処理が実行されるため、Ｓ１１５５の処理へ移行すれば、入力バッファからデータが取り出されてパケット化され、そのパケットが次ＰＣ送信用バッファ１９１に置かれることになる。

ちなみに、リソースマネージャタスク１４１に対してシグナルが送信された場合でも、次ＰＣ送信用バッファ１９１にデータが有る場合は（Ｓ１１３０：有り）、入力バッファ等にあるデータを次ＰＣ送信用バッファ１９１に格納することはできない。そのため、そのような場合は、そのままＳ１１０５の処理へと戻る。この場合、入力バッファ等には入力データが残されることになる。

ただし、上述の通り、次ＰＣ送信用バッファ１９１の内容をＰＣ１２側に送信して、次ＰＣ送信用バッファ１９１をクリアしたら（Ｓ１１７０）、その後は、上述したＳ１１３５の処理へと進む。したがって、この時点で、シグナルを受けたときに次ＰＣ送信用バッファ１９１に格納できなかった入力データは、次ＰＣ送信用バッファ１９１へと移されることになる。

また、リソースマネージャタスク１４１に到来するＳＣＳＩコマンドは、ＰＣ１２のリソースマネージャ２４１から到来するコマンドである限り、“ＲｅａｄＢｕｆｆｅｒ”、“ＷｒｉｔｅＢｕｆｆｅｒ”のいずれかとなる。ただし、ファイルシステム２３３やリムーバブルディスクドライバ２２３経由でＳＣＳＩコマンドが到来する可能性もある。

そこで、そのようなＳＣＳＩコマンドが到来した場合（Ｓ１１１０：その他）、複合機１１は、メディアの入っていないドライブ相当の応答を返し（Ｓ１１７５）、Ｓ１１０５の処理へと戻る。

このような応答を返せば、メディアへの書き込み要求やメディアからの読み出し要求などをエミュレートした応答を返さなくても、常にメディアが入っていない旨を応答するだけでよいので、煩雑な擬似応答をしなくても済む。また、常にメディアが入っていない状態をエミュレートすれば、メディア交換ステータスも発生しないので、メディア交換ステータスが発生する場合に比べ、予期しない事態に陥る可能性を低くすることができる。

なお、以上説明した処理においては、先にＳ１１３５の処理を行った後、その後で、Ｓ１１５０処理を行っている。このような手順で処理を行えば、常に、コントロールエリア１８１にＰＣ１２に伝える情報が有るか否かが先に判断される。そして、その様な情報が無かった場合に、入力バッファ１８３、１８５、１８７のいずれかにデータが有るか否かが判断される。

したがって、コントロールエリア１８１にＰＣ１２に伝える情報が有る場合は、入力バッファ１８３、１８５、１８７のいずれかにデータが有るか否かを問わず、優先的にコントロールエリア１８１の情報をＰＣ１２に伝えることができる。よって、ＰＣ１２に対して迅速に制御情報を伝達でき、入力バッファ１８３、１８５、１８７にあるデータの伝送に邪魔されることなく、適切な制御を実施することができる。

［第１実施形態の効果］
以上説明した通り、上記複合機１１によれば、プリンタ機能、スキャン機能、およびＰＣ−ＦＡＸ機能のすべてを、ＰＣ１２のＯＳには、ＵＳＢストレージデバイスのリムーバブルＨＤに相当する論理ユニットとして認識させる。

したがって、この論理ユニットに対応する入力用および出力用のエンドポイントを１つずつ用意するだけで、ＵＳＢ規格の通信プロトコルに則って、ＰＣ１２と論理ユニットとの間で相互にデータ伝送を行うことができる。しかも、このデータ伝送により、ＰＣ１２からプリンタ機能、スキャン機能、およびＰＣ−ＦＡＸ機能のすべてを利用することができる。

したがって、プリンタ機能、スキャン機能、およびＰＣ−ＦＡＸ機能それぞれに対応する論理ユニットが構成されることになるＵＳＢ複合デバイスとは異なり、個々の機能毎に入力用および出力用のエンドポイントを１つずつ用意しなくてもよくなるので、その分だけエンドポイント数を削減することができる。

また、プリンタ機能、スキャン機能、およびＰＣ−ＦＡＸ機能のいずれを制御するかは、ＵＳＢ規格に則って伝送可能なデータの実データ部に、独自規格の情報として格納されているものである。したがって、あるＵＳＢデバイスとの接続を断って、別のＵＳＢデバイスとの接続を確立するといった状況を擬似的に作り出す必要はなく、ＰＣ１２のＯＳは、常にリムーバブルＨＤに相当する論理ユニットにアクセスすればよい。したがって、ＰＣ１２のＯＳが、デバイスドライバの切り替えに時間を要するといった問題はなく、複数の機能を同時に利用することもできる。

さらに、コントロール転送用のエンドポイント（ＥＰ０）が、その他のデータ転送にも利用される構成にはなっていないので、大量にデータが転送されるような状況下でも、データ転送に邪魔されることなく、必要な制御を迅速に実施できるものとなる。

加えて、上記複合機１１の場合、ＰＣ１２のＯＳには、複数ＬＵＮを持つＵＳＢデバイスとして認識され、その内の１つの論理ユニットがプリンタ機能、スキャン機能、およびＰＣ−ＦＡＸ機能に対応し、もう１つの論理ユニットがカードリーダ機能に対応している。

したがって、カードリーダ機能については、プリンタ機能、スキャン機能、およびＰＣ−ＦＡＸ機能を持つ論理ユニットの一部に組み込まなくてもよく、ＯＳ標準のデバイスドライバ等により、カードリーダ機能の制御を実施できる。しかも、カードリーダ機能の実装に当たって、エンドポイントを増設する必要はないので、エンドポイントの削減という当初の目的を阻害することもない。
（２）第２実施形態
次に、第２実施形態について説明する。なお、第２実施形態以降の実施形態は、一部の構成が上記第１実施形態とは相違するものの、共通部分も多いので、以下の説明においては、第１実施形態との相違点を中心に詳述し、共通部分については詳細な説明を省略する。

［複合機用ソフトウェアのインストール処理］
以下、第２実施形態において、ＰＣ１２において実行される複合機用ソフトウェアのインストール処理について、図１８のフローチャートに基づいて説明する。この処理は、図７に示した処理の代わりに実行されるものである。

以下に説明する処理の内、まず、Ｓ１２０５〜Ｓ１２２２０の処理は、第１実施形態におけるＳ１０５〜Ｓ１２０と同等な処理になるので、簡潔に説明する。
すなわち、この処理を開始すると、ＰＣ１２は、図１８に示すように、まずインストーラを起動する（Ｓ１２０５）。そして、該当複合機のリソースマネージャ用ドライブを検索する（Ｓ１２１０）。このＳ１２１０の処理は、第１実施形態同様、詳しくは図８に示すような処理となるが、第２実施形態では、図８に基づく詳細な説明は省略する。

Ｓ１２１０の処理の結果、リソースマネージャ用ドライブが見つからなかった場合（Ｓ１２１０：見つからなかった）、ＰＣ１２は、「複合機１１とＵＳＢ接続を行い暫く待った後にＯＫを押すこと」を利用者に対して指示するダイヤログを表示する（Ｓ１２１５）。

ここで、利用者が「キャンセル」を押した場合（Ｓ１２１５：キャンセル）、インストール処理は中止される。一方、利用者が「ＯＫ」を押した場合（Ｓ１２１５：ＯＫ）、ＰＣ１２は、再びＳ１２１０の処理を実行する。

また、Ｓ１２１０の処理において、リソースマネージャ用ドライブが見つかった場合（Ｓ１２１０：見つかった）、ＰＣ１２は、見つかった「リソースマネージャ用ドライブ」を隠す（Ｓ１２２０）。

続いて、ＰＣ１２は、リソースマネージャをインストールし、見つかった「リソースマネージャ用ドライブ」をＩＮＩファイルに設定する（Ｓ１２２５）。すなわち、第１実施形態では、Ｓ２１０（図８参照）の処理において取得された「複合機機種名」をＩＮＩファイルに設定していたところ、第２実施形態では、変数ＣＤＲＶ（図８参照）に格納された「リソースマネージャ用ドライブ」のドライブレターをＩＮＩファイルに設定する。

その後、ＰＣ１２は、プリンタドライバ、プリントポートドライバ、スキャナドライバ、ＣＯＭポートドライバ、ＰＣ−ＦＡＸアプリケーションをインストールして（Ｓ１２３０）、複合機用ソフトウェアのインストール処理を終了する。なお、このＳ１２３０の処理は、第１実施形態におけるＳ１３０と同等な処理である。

［リソースマネージャが実行する処理］
次に、第２実施形態において、リソースマネージャ２４１が実行する処理について、図１９に基づいて説明する。この処理は、図１３に示した処理の代わりに実行されるものである。

リソースマネージャ２４１が起動された場合、リソースマネージャ２４１は、対象とすべき「リソースマネージャ用ドライブ」の設定を、ＩＮＩファイルから読み込む（Ｓ１３０５）。このＳ１３０５の処理では、上述したＳ１２２５の処理等により、ＩＮＩファイルに格納された各種情報が読み込まれることになる。

続いて、リソースマネージャ２４１は、ＩＮＩファイルから読み込んだ「リソースマネージャ用ドライブ」のドライブレターについて、そのドライブレターが割り当てられたドライブが、リソースマネージャ用かどうかを確認する（Ｓ１３１０）。

このＳ１３１０の処理を実行するのは、ＩＮＩファイルの作成後にドライブレターの割り当てが変更された場合、ＩＮＩファイルに登録されたドライブレターと実際のドライブレターとの間に不整合が生じている可能性があるからである。

Ｓ１３１０の処理において、ＩＮＩファイルに登録されたドライブレターに対応するドライブが、「リソースマネージャ用ドライブ」ではなかった場合（Ｓ１３１０：ちがう）、ＰＣ１２は、「複合機１１とＵＳＢ接続を行い暫く待った後にＯＫを押すこと」を利用者に対して指示するダイヤログを表示する（Ｓ１３１５）。

このＳ１３１５の処理により、ＰＣ１２は利用者からの入力待ち状態になる。ここで、利用者は、ＰＣ１２の表示部に表示されたダイヤログにおいて、「ＯＫ」、「キャンセル」、または「リスキャン」を押す操作を行うことができる。

利用者が「キャンセル」を押した場合（Ｓ１３１５：キャンセル）、リソースマネージャ２４１による処理は終了する。また、利用者が「ＯＫ」を押した場合（Ｓ７１５：ＯＫ）、ＰＣ１２は、再びＳ１３１０の処理を実行する。また、利用者が「リスキャン」を押した場合（Ｓ１３１５：ＯＫ）、リソースマネージャ２４１は、該当複合機のリソースマネージャ用ドライブを検索する（Ｓ１３２０）。

このＳ１３２０の処理は、既に説明した図８に示す処理と同等な処理となるので、ここでの説明は省略する。Ｓ１３２０の処理の結果、リソースマネージャ用ドライブが見つからなかった場合（Ｓ１３２０：見つからない）、ＰＣ１２は、再びＳ１３１５へと戻って入力待ちになる。

また、Ｓ１３２０の処理の結果、リソースマネージャ用ドライブが見つかった場合（Ｓ１３２０：見つかった）、ＰＣ１２は、リソースマネージャ用ドライブの設定を変更する（Ｓ１３２５）。Ｓ１３２５の処理では、新たに見つかったリソースマネージャ用ドライブのドライブレターがＩＮＩファイルに書き込まれる。なお、Ｓ１３２５の処理を終えたら、Ｓ１３０５の処理へと戻ることにより、リソースマネージャ２４１としての処理を最初からやり直す。

さて、以上のようなＳ１３０５〜Ｓ１３２５の処理を実行する中で、Ｓ１３１０の処理において、リソースマネージャ用ドライブが見つかった場合（Ｓ１３１０：そうだ）、ＰＣ１２は、所定時間だけ待って（Ｓ１３３０）、終了要求が有るか否かを判断する（Ｓ１３３５）。

ここで、終了要求が無ければ（Ｓ１３３５：無し）、リソースマネージャ２４１は、ＲｅａｄＢｕｆｆｅｒ処理（Ｓ１３４０）、ＷｒｉｔｅＢｕｆｆｅｒ処理（Ｓ１３４５）を実行し、Ｓ１３３０へ戻る。以降、終了要求無い限り、Ｓ１３３０〜Ｓ１３４５の処理が繰り返される。

このＳ１３３０〜Ｓ１３４５の処理は、第１実施形態において、図１３に示したＳ７２０〜Ｓ７３５の処理と同等な処理になる。また、Ｓ１３４０の処理は、詳しくは図１４に示すような処理となり、Ｓ１３４５の処理は、詳しくは図１５に示すような処理となるが、これらも第１実施形態と同等な処理となるので、第２実施形態においては、図１４、図１５に基づく詳細な説明を省略する。

［第２実施形態の効果］
以上説明した第２実施形態の複合機１１でも、第１実施形態の複合機１１と同様の作用、効果を奏する。すなわち、プリンタ機能、スキャン機能、およびＰＣ−ＦＡＸ機能のすべてを、ＰＣ１２のＯＳには、ＵＳＢストレージデバイスのリムーバブルＨＤに相当する論理ユニットとして認識させるので、個々の機能毎に入力用および出力用のエンドポイントを１つずつ用意しなくてもよく、エンドポイント数を削減することができる。

また、あるＵＳＢデバイスとの接続を断って、別のＵＳＢデバイスとの接続を確立するといった状況を擬似的に作り出す必要はないので、ＰＣ１２のＯＳが、デバイスドライバの切り替えに時間を要することはなく、複数機能を同時利用もできる。

さらに、コントロール転送用のエンドポイント（ＥＰ０）が、その他のデータ転送にも利用される構成にはなっていないので、大量にデータが転送されるような状況下でも、データ転送に邪魔されることなく、必要な制御を迅速に実施できるものとなる。

また、カードリーダ機能については、プリンタ機能、スキャン機能、およびＰＣ−ＦＡＸ機能を持つ論理ユニットの一部に組み込まなくてもよく、ＯＳ標準のデバイスドライバ等により、カードリーダ機能の制御を実施できる点も、第１実施形態と同様である。

加えて、第２実施形態においては、Ｓ１２２５の処理でＩＮＩファイルにドライブレターを登録し、Ｓ１３１０の処理ではＩＮＩファイルに登録されたドライブレターに基づいて、リソースマネージャ用ドライブにアクセスを試みる。

したがって、ＩＮＩファイルに登録されたドライブレターとリソースマネージャ用ドライブに実際に割り当てられたドライブレターとの間に不整合が無ければ、Ｓ７１０の処理による検索を行う場合よりも、リソースマネージャ用ドライブを迅速に発見できる。

さらに、万一、Ｓ１３１０の処理で、正しいリソースマネージャ用ドライブを直ちに確認できなかったとしても、Ｓ１３２０の処理により、リソースマネージャ用ドライブを検索できるので、第１実施形態と同等なこともできる。つまり、ＩＮＩファイルのドライブレターが正しい場合は、処理の迅速性を向上させることができ、且つ、ＩＮＩファイルのドライブレターが正しくない場合でも、処理の信頼性を確保することができる。
（３）第３実施形態
第３実施形態は、ＰＣの内部構成が、第１実施形態とは異なる構成となる例である。以下、第３実施形態におけるＰＣの内部構成について説明する。

［ＰＣの内部構成］
図２０は、第３実施形態におけるＰＣ３２の内部構成を示すブロック図である。
第１実施形態のＰＣ１２では、複合機１１がＬＵＮ１の論理ユニットについて「リムーバブルＨＤ」である旨の応答を返す結果、リムーバブルディスクドライバ２２３がロードされていたが、この点について、第３実施形態のＰＣ３２は異なる構成となっている。

具体的には、第３実施形態において、複合機１１がＬＵＮ１の論理ユニットについて「ＣＤ−ＲＯＭ」である旨の応答を返す。そして、この応答を受けたＰＣ３２では、リムーバブルディスクドライバ２２３の代わりに、ＣＤ−ＲＯＭドライバ２２５がロードされる。

このような構成を採用しても、ＰＣ３２のＯＳは、複合機１１が備えるＬＵＮ１の論理ユニットについて、ＣＤ−ＲＯＭ相当のデバイスとして認識する。したがって、プリンタ機能、スキャナ機能、ＰＣ−ＦＡＸ機能のそれぞれについて個別にエンドポイントを用意しなくてもよい点で、第１実施形態等と全く同様の作用、効果を奏する。

さらに、第３実施形態では、ＰＣ３２のＯＳにＣＤ−ＲＯＭ相当のデバイスとして認識される論理ユニットについて、第１実施形態とは別の手法で、その存在を隠すことができる。

具体的には、第１実施形態では、ＰＣ１２に認識されたリムーバブルＨＤ相当のデバイスについて、ドライブレターが割り当てられた後に、レジストリの内容を書き換えることで、そのドライブレターに対応する表示設定を「ドライブを隠す設定」にしていた。

これに対し、第３実施形態では、ＣＤ−ＲＯＭ相当のデバイスとして認識される論理ユニットについて、単にドライブレターの割り当て（アサイン）を解除することにより、その存在を隠すことができる。

また、ドライブレターの割り当て（アサイン）を解除した場合、ＰＣ３２では、ドライブレターを利用してＬＵＮ１の論理ユニットにアクセスすることはできなくなる。しかし、ＰＣ３２のＯＳがＬＵＮ１の論理ユニットをＣＤ−ＲＯＭ相当のデバイスとして認識している場合、ドライブレターを利用しなくてもＬＵＮ１の論理ユニットにアクセスできる。

具体的には、ドライブレターとは別のデバイスストリング（例えば、“￥￥．￥ｃｄｒｏｍ１”、“￥￥．￥ｃｄｒｏｍ２”等）に対してコマンドを発行することができ、これにより、ＬＵＮ１の論理ユニットにアクセスすることができる。したがって、リソースマネージャ２４１は、上記のような「ドライブレターとは別のデバイスストリング」を指定してＳＣＳＩコマンドを発行し、第１実施形態と同様の処理を行えばよい。

なお、第１実施形態において、図８に示した処理では、ドライブレター“Ａ”〜“Ｚ”を対象にして、リソースマネージャ用ドライブを検索していたが、第３実施形態の場合は、例えば“￥￥．￥ｃｄｒｏｍ１”〜“￥￥．￥ｃｄｒｏｍ１６”に対してリソースマネージャ用ドライブを検索するなど、検索対象をドライブレターから「ドライブレターとは別のデバイスストリング」に変更すればよい。

ちなみに、この例は、“￥￥．￥ｃｄｒｏｍ１”から“￥￥．￥ｃｄｒｏｍ１６”まで１６個のデバイスストリングを検索対象とする例であるが、これらのデバイスストリングをいくつまで検索対象とするかは任意である。

また、第２実施形態において、図１８に示したＳ１２２５の処理では、ドライブレターをＩＮＩファイルに登録し、図１９に示したＳ１３１０の処理で利用していたが、第３実施形態の場合は、「ドライブレターとは別のデバイスストリング」をＩＮＩファイルに登録し、図１９に示したＳ１３１０の処理で利用する構成にすればよい。

［第３実施形態の効果］
以上説明した第３実施形態でも、第１実施形態や第２実施形態と同様の作用、効果を奏する。すなわち、プリンタ機能、スキャン機能、およびＰＣ−ＦＡＸ機能のすべてを、ＰＣ３２のＯＳには、ＵＳＢストレージデバイスのＣＤ−ＲＯＭに相当する論理ユニットとして認識させるので、個々の機能毎に入力用および出力用のエンドポイントを１つずつ用意しなくてもよく、エンドポイント数を削減することができる。

また、あるＵＳＢデバイスとの接続を断って、別のＵＳＢデバイスとの接続を確立するといった状況を擬似的に作り出す必要はないので、ＰＣ３２のＯＳが、デバイスドライバの切り替えに時間を要することはなく、複数機能を同時利用もできる。

さらに、コントロール転送用のエンドポイント（ＥＰ０）が、その他のデータ転送にも利用される構成にはなっていないので、大量にデータが転送されるような状況下でも、データ転送に邪魔されることなく、必要な制御を迅速に実施できるものとなる。

また、カードリーダ機能については、プリンタ機能、スキャン機能、およびＰＣ−ＦＡＸ機能を持つ論理ユニットの一部に組み込まなくてもよく、ＯＳ標準のデバイスドライバ等により、カードリーダ機能の制御を実施できる点も、第１実施形態と同様である。

加えて、第３実施形態においては、第１、第２実施形態とは異なり、プリンタ機能、スキャン機能、およびＰＣ−ＦＡＸ機能に対応する論理ユニットを、ＣＤ−ＲＯＭ相当のデバイスとして認識させるので、ＯＳに認識された擬似的なＣＤ−ＲＯＭ相当のデバイスの存在を、ドライブレターのアサインを解除するだけで、簡単に隠すことができる。
（４）第４実施形態
第４実施形態は、ＰＣの内部構成が、第１実施形態や第３実施形態とは異なる構成となる例である。以下、第４実施形態におけるＰＣの内部構成について説明する。

［ＰＣの内部構成］
図２１は、第４実施形態におけるＰＣ４２の内部構成を示すブロック図である。
第４実施形態においては、複合機１１がＬＵＮ１の論理ユニットについて「ハードディスク」である旨の応答を返す。そして、この応答を受けたＰＣ４２では、リムーバブルディスクドライバ２２３の代わりに、ハードディスクドライバ２２７がロードされる。

また、ＬＵＮ１の論理ユニットについて、ＰＣ４２からの応答要求があった場合には、「パーティションの存在しないハードディスク」としての応答がエミュレートされる。
このような構成を採用しても、ＰＣ４２のＯＳは、複合機１１が備えるＬＵＮ１の論理ユニットについて、ハードディスク相当のデバイスとして認識する。したがって、プリンタ機能、スキャナ機能、ＰＣ−ＦＡＸ機能のそれぞれについて個別にエンドポイントを用意しなくてもよい点で、第１実施形態〜第３実施形態等と全く同様の作用、効果を奏する。

また、ＰＣ４２のＯＳは、「パーティションの存在しないハードディスク」に対してはドライブレターを割り当てないので、その存在を隠すことができる。
［第４実施形態の効果］
以上説明した第４実施形態でも、第１実施形態〜第３実施形態と同様の作用、効果を奏する。すなわち、プリンタ機能、スキャン機能、およびＰＣ−ＦＡＸ機能のすべてを、ＰＣ４２のＯＳには、ＵＳＢストレージデバイスのハードディスクに相当する論理ユニットとして認識させるので、個々の機能毎に入力用および出力用のエンドポイントを１つずつ用意しなくてもよく、エンドポイント数を削減することができる。

また、あるＵＳＢデバイスとの接続を断って、別のＵＳＢデバイスとの接続を確立するといった状況を擬似的に作り出す必要はないので、ＰＣ４２のＯＳが、デバイスドライバの切り替えに時間を要することはなく、複数機能を同時利用もできる。

さらに、コントロール転送用のエンドポイント（ＥＰ０）が、その他のデータ転送にも利用される構成にはなっていないので、大量にデータが転送されるような状況下でも、データ転送に邪魔されることなく、必要な制御を迅速に実施できるものとなる。

また、カードリーダ機能については、プリンタ機能、スキャン機能、およびＰＣ−ＦＡＸ機能を持つ論理ユニットの一部に組み込まなくてもよく、ＯＳ標準のデバイスドライバ等により、カードリーダ機能の制御を実施できる点も、第１実施形態と同様である。

加えて、第４実施形態においては、第１〜第３実施形態とは異なり、プリンタ機能、スキャン機能、およびＰＣ−ＦＡＸ機能に対応する論理ユニットを、パーティションの存在しないハードディスク相当のデバイスとして認識させるので、ＯＳがドライブレターを割り当てることはなく、その存在を簡単に隠すことができる。

［変形例等］
以上、本発明の実施形態について説明したが、本発明は上記の具体的な一実施形態に限定されず、この他にも種々の形態で実施することができる。

例えば、第１実施形態においては、リソースマネージャ２４１以外の経路から複合機１１が備えるＬＵＮ１の論理ユニットに対するアクセスがあった場合に、Ｓ１１７５の処理により、常にメディアの入っていないドライブ相当の応答を返すようにしていたが、常にメディアが入っているドライブ相当の応答を返すようにしてもよい。

この場合でも、メディア交換ステータスは発生しないので、メディア交換ステータスが発生する場合に比べ、予期しない事態に陥る可能性を低くすることができる。
つまり、メディア交換ステータスを発生させない方法としては、「常にメディアが入っていないドライブ」、「常にメディアが入っているドライブ」、いずれをエミュレートしてもよい。

また、上記各実施形態において、複合機１１は、複数ＬＵＮを持つＵＳＢデバイスであったが、本発明において、複数ＬＵＮを持つか否かは任意である。具体的には、上記各実施形態においては、カードリーダ機能を有するＵＳＢデバイス相当の部分が、ＬＵＮ０の論理ユニットとして機能していたが、例えば、カードリーダ機能が不要な場合であれば、プリンタ機能、スキャナ機能、およびＰＣ−ＦＡＸ機能を有するＵＳＢデバイス相当の部分だけが、単一論理ユニットとして機能する構成になっていてもよい。この場合、ＰＣ側には、複数ＬＵＮを持つＵＳＢデバイスとして認識されなくてもよい。

さらに、上記各実施形態においては、複合機がＰＣのＯＳから複数ＬＵＮを持つＵＳＢデバイスであると認識されるようにするため、複合機がＵＳＢストレージクラスのデバイスとして機能するようにしてあったが、複数ＬＵＮを持つＵＳＢデバイスであると認識されなくてもよい場合、複合機は、ＵＳＢストレージクラス以外のＵＳＢデバイスとして機能するものであってもよい。

例えば、複合機は、ＵＳＢ複合デバイスとして機能するものであってもよい。この場合、ＵＳＢ複合デバイスとして認識される複数の機能は、それぞれエンドポイントを使用することになる。

しかし、この場合でも、ＵＳＢ複合デバイスとして認識される複数の機能の内、少なくとも１つ（正確には、エンドポイントを１組使用する１つの機能）が、上記実施形態で示したような複合論理ユニットとして機能すれば、単一のエンドポイントで複数機能を制御できる。したがって、複合機が備える機能の総数に対し、使用するエンドポイント数を削減することができる。

また、上記実施形態では、複合論理ユニットに対応するＵＳＢデバイスとして、リムーバブルディスク、ＣＤ−ＲＯＭ、ハードディスクをエミュレートする例を示したが、これら以外のＵＳＢデバイスをエミュレートしてもよく、例えば、ＦＤ（フレキシブルディスク）、光磁気ディスクなどをエミュレートする構成としてもよい。

本発明の一例として例示する第１実施形態のデバイス制御システム全体のブロック図。 第１実施形態の複合機の内部構成を示すブロック図。 第１実施形態の複合機の内部構成の一部をより詳細に示したブロック図。 第１実施形態のＰＣの内部構成を示すブロック図 第１実施形態のＰＣと複合機が接続を確立するときのやり取りを示す説明図。 第１実施形態のＰＣの内部構成の一部をより詳細に示したブロック図。 第１実施形態のＰＣにおいて実行される複合機用ソフトウェアのインストール処理のフローチャート。 第１実施形態のＰＣにおいて実行される複合機用ソフトウェアのインストール処理の一部をより詳細に示したフローチャート。 第１実施形態のＰＣにおいて実行されるＰＣの電源ＯＮから電源ＯＦＦに至るまでに実行される処理のフローチャート。 第１実施形態のＰＣにおいて実行されるスタティックドライバをロードする処理のフローチャート。 第１実施形態のＰＣにおいて実行されるダイナミックドライバをロードする処理のフローチャート。 第１実施形態のＰＣにおいて実行される自動起動プログラムを起動する処理のフローチャート。 第１実施形態のＰＣにおいて実行されるリソースマネージャが実行する処理のフローチャート。 第１実施形態のＰＣにおいて実行されるＲｅａｄＢｕｆｆｅｒ処理のフローチャート。 第１実施形態のＰＣにおいて実行されるＷｒｉｔｅＢｕｆｆｅｒ処理のフローチャート。 第１実施形態の複合機において実行されるＳＣＳＩコマンド解析タスクにおいて実行される処理のフローチャート。 第１実施形態の複合機において実行されるリソースマネージャタスクにおいて実行される処理のフローチャート。 第２実施形態のＰＣにおいて実行される複合機用ソフトウェアのインストール処理のフローチャート。 第２実施形態のＰＣにおいて実行されるリソースマネージャが実行する処理のフローチャート。 第３実施形態のＰＣの内部構成を示すブロック図。 第４実施形態のＰＣの内部構成を示すブロック図。

１１・・・複合機、１２・・・ＰＣ、１３・・・ＵＳＢ−ＨＵＢ、１４・・・他のＵＳＢデバイス、１０１・・・ＵＳＢプロトコルエンジン、１０３・・・制御回路、１０５・・・カードリーダ系データ入出力回路、１１１・・・ＳＣＳＩコマンド解析タスク、１２１・・・メモリスロット入出力制御タスク、１３１・・・第１メモリスロット、１３２・・・第２メモリスロット、１３３・・・第３メモリスロット、１３４・・・第４メモリスロット、１４１・・・リソースマネージャタスク、１５１・・・プリンタ入出力タスク、１５３・・・スキャナ入出力タスク、１５５・・・ＰＣ−ＦＡＸ入出力タスク、１６１・・・印字制御タスク、１６３・・・スキャナ制御タスク、１６５・・・モデム制御タスク、１７１・・・プリンタハードウェア、１７３・・・スキャナハードウェア、１７５・・・モデムハードウェア、１８１，２９１・・・コントロールエリア、１８２，１８４，１８６，２９２，２９４，２９６・・・出力バッファ、１８３，１８５，１８７，２９３，２９５，２９７・・・入力バッファ、１９１・・・次ＰＣ送信用バッファ、２０１・・・ＵＳＢプロトコルスタック、２０３・・・ＵＳＢストレージドライバ、２１１，２１３・・・ＳＣＳＩコマンド処理部、２２１，２２３・・・リムーバブルディスクドライバ、２２５・・・ＣＤ−ＲＯＭドライバ、２２７・・・ハードディスクドライバ、２３１，２３３・・・ファイルシステム、２４１・・・リソースマネージャ、２５１・・・プリントポートドライバ、２５３・・・スキャナドライバ、２５５・・・ＣＯＭポートドライバ、２６１・・・プリンタドライバ、２７１・・・印刷可能アプリケーション、２７３・・・スキャン可能アプリケーション、２７５・・・ＰＣ−ＦＡＸアプリケーション、２７７・・・エクスプローラ、２８１・・・他のＵＳＢデバイスのドライバ。

Claims (2)

1. コンピュータと、複数種の機能を備えた複合機とを、ＵＳＢインターフェースを介して接続した構造になっており、前記複合機は、前記コンピュータが備えるＯＳには、ＵＳＢ規格に準拠した方式でデータを伝送可能な論理ユニットを少なくとも１つ有するデバイスであると認識され、前記コンピュータが前記論理ユニットとの間で入出力データの伝送を行うことによって、前記複合機が備える前記複数種の機能を利用可能となっているデバイス制御システムであって、
   前記複合機において、前記論理ユニットの少なくとも１つは、単一の論理ユニットに対して、前記複数種の機能の内、２種以上の特定機能が対応付けられた複合論理ユニットとされており、
   前記コンピュータと前記複合機との接続を確立する際、前記コンピュータは、前記複合論理ユニットをＵＳＢストレージクラスのデバイスであると認識して、前記ＵＳＢストレージクラスのデバイスと通信可能な状態になる一方、前記複合機は、前記ＵＳＢストレージクラスのデバイスに対応する１組の入力用および出力用のエンドポイントを介して前記コンピュータと通信可能な状態となって、前記コンピュータと前記複合機がＵＳＢ規格に準拠した通信手順で通信可能な接続状態となり、
   しかも、前記コンピュータが前記複合論理ユニットに対し、ＳＣＳＩコマンドの“Ｉｎｑｕｉｒｙ”を発行すると、前記複合機はＳＣＳＩデバイスの種別としてストレージデバイスである旨の応答を返し、当該応答を受けた前記コンピュータは、前記１組の入力用および出力用のエンドポイントを介して通信可能な接続状態について切断および再接続を行うことなく、前記ストレージデバイスに対応するストレージデバイス用デバイスドライバをロードし、
   前記コンピュータは、
   前記コンピュータ上で機能するデータ処理部からの指令に従って、前記２種以上の特定機能のいずれかを制御するために前記コンピュータからの出力データを前記複合機に伝送する場合に、前記２種以上の特定機能のいずれかを制御するための独自規格の情報を、前記出力データ内の実データ部に格納して、当該出力データを前記複合論理ユニットへと伝送し、さらに、前記コンピュータへの入力データが前記複合機から伝送された場合には、前記入力データ内の実データ部に含まれる独自規格の情報に基づいて、前記２種以上の特定機能のいずれによって伝送されてきたデータであるのかを判断して、当該データを指令元である前記データ処理部へと伝送するコンピュータ側制御手段
   を備え、
   前記複合機は、
   前記コンピュータからの出力データが前記複合論理ユニットに伝送された場合には、前記出力データ内の実データ部に含まれる独自規格の情報に基づいて、前記２種以上の特定機能のいずれを制御するためのデータであるのかを判断して、いずれか１種の機能を制御し、さらに、前記１種の機能を制御したことにより、前記コンピュータへの入力データを伝送する場合には、前記２種以上の特定機能のいずれによって伝送されるデータであるのかを示す独自規格の情報を、前記入力データ内の実データ部に格納して、当該入力データを前記複合論理ユニットからのデータとして前記コンピュータへと伝送するデバイス側制御手段
   を備え、しかも、
   前記コンピュータ側制御手段は、
   前記２種以上の特定機能それぞれに対応付けて設けられた２以上の特定機能用デバイスドライバと、
   前記２以上の特定機能用デバイスドライバと前記ＯＳとの間に介在して一方から他方へデータ伝送を行うデータ管理手段と
   を備え、
   前記コンピュータと前記複合機との接続を確立する際、前記コンピュータは、前記２以上の特定機能用デバイスドライバを、前記ストレージデバイス用デバイスドライバとは別に、スタティックドライバとしてロードし、
   前記コンピュータ上で機能するデータ処理部からの指令に従って、前記２種以上の特定機能のいずれかを制御するために前記コンピュータからの出力データを前記複合機に伝送する場合に、前記特定機能用デバイスドライバは、前記コンピュータ上で機能するデータ処理部からの指令に従って、前記２種以上の特定機能のいずれかを制御するためのデータを作成して、当該データを前記データ管理手段へと伝送し、前記データ管理手段は、前記特定機能用デバイスドライバから伝送されてきたデータに基づき、前記２種以上の特定機能のいずれかを制御するための独自規格の情報を、前記出力データ内の実データ部に格納して、当該出力データを前記複合論理ユニットへと伝送し、さらに、前記コンピュータへの入力データが前記複合機から伝送された場合には、前記データ管理手段は、前記入力データ内の実データ部に含まれる独自規格の情報に基づいて、前記２種以上の特定機能のいずれかによって伝送されてきたデータであるのかを判断して、当該データを当該データに対応する前記特定機能用デバイスドライバへと伝送し、当該データが伝送されてきた特定機能用デバイスドライバは、当該データを指令元である前記データ処理部へと伝送する
   ことを特徴とするデバイス制御システム。
2. 前記複合機が備える前記デバイス側制御手段は、前記ストレージデバイス用デバイスドライバからのコマンドが到来した場合に、メディアの入っていないドライブ相当の応答を前記コンピュータに対して返す
   ことを特徴とする請求項１に記載のデバイス制御システム。

Images