JP2010102500A - 印刷システム、情報処理装置及びその制御方法、並びにプログラム - Google Patents

Abstract

【課題】情報処理装置と印刷装置をＵＳＢを用いて接続する構成において、プラグ・アンド・プレイ実行時に、デバイスドライバのインストールに失敗せず、不明な論理デバイスも発生しないようにする。
【解決手段】印刷装置が持つ正規のデバイス名称／構成とは異なるデバイス名称／構成として、前記情報処理装置上で稼動するオペレーティングシステムに標準で搭載されているデバイスドライバが適用可能なデバイス名称／構成を設定する偽名宣言手段と、前記情報処理装置が発行した変更指示に従って、前記印刷装置に搭載されている論理デバイスのうち利用可能な論理デバイスを用いた構成となるように前記ＵＳＢ上の論理デバイスの組み合わせを変更し、前記偽名宣言手段で設定されたデバイス名称／構成を前記正規のデバイス名称／構成に変更する名称変更手段とを備える。
【選択図】図１２

Description

本発明は、情報処理装置や印刷装置等から構成される印刷システム、前記情報処理装置及びその制御方法、並びに前記制御方法を実現するためのプログラムに関する。

複数種類のＰＤＬ（Ｐａｇｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）を備えて外部のコンピュータからの印刷データを印刷するための印刷機能を備える他に、画像を読み取るスキャナ機能を搭載した複合印刷装置は、従来より知られている。ＰＤＬは、プリンタが解釈できる印刷データ用の言語である。

この種の複合印刷装置では、外部のコンピュータとの接続形態として、Ｃｏｍｐｏｓｉｔｅ ＵＳＢ（Ｃｏｍｐｏｓｉｔｅ Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ、以下、複合ＵＳＢと記す）を採用するものがある。この複合ＵＳＢは、複合印刷装置においてＵＳＢハブを用いないで複数の機能を搭載することができる点に特徴がある。

複合ＵＳＢを採用した製品は、外部のコンピュータとＵＳＢケーブルで接続してプラグ・アンド・プレイ機能を実行すると、複合印刷装置内部に各種機能を実現するために定義されている全ての論理デバイス（Ｌｏｇｉｃａｌ Ｄｅｖｉｃｅ）が順次出現してくる。したがって、接続するコンピュータに、前記各論理デバイスを制御する全てのデバイスドライバをインストールしないと、次のような問題が生ずる。即ち、インストール処理の最後でインストールが失敗した旨のメッセージがコンピュータのオペレーティングシステム（以下、ＯＳと記す）上に表示され、更に不明な論理デバイスが認識されてしまう。

近年のコンピュータ技術の発達は目覚ましく、次々と新しいＯＳが登場してきている。このような新旧のＯＳが混在する環境においては、今まで使用されてきた旧ＯＳ上では利用できないデバイスドライバが存在する場合も出てきている。例えば、ＯＳ１が古くから存在するＯＳであり、このＯＳ１ではＰＤＬ１デバイス用のデバイスドライバが利用できるが、もうじきその製品寿命に達すると見込まれているとする。このような場合に、ＰＤＬデバイスとしてＰＤＬ２デバイスが新しく登場してきたときには、ＰＤＬ２デバイス用のデバイスドライバをＯＳ１向けには作成しないなどのことが考えられる。

その結果、プラグ・アンド・プレイ実行時に必要となるデバイスドライバのうち、接続するコンピュータ上で稼動しているＯＳに対応しないデバイスドライバはインストールすることができず、上記のような問題が生ずることが危惧されている。

このような問題を解決するために、使用するＯＳの種類に応じて、複合ＵＳＢを構成する論理デバイスの構成をダイナミックに変更できるような技術の登場が待望されていた。

論理デバイスの構成を変更する技術として、ＵＳＢを使用してコンピュータに接続される複合機において、コンピュータからの指示により複合機のファンクションの構成を変更する技術が例えば特許文献１に開示されている。
特開２００１−２２２５０３号公報

しかしながら、上記特許文献１の技術では、ＯＳの種類に応じて、論理デバイスの構成を変更するということが考慮されていない。そのため、上述したように、プラグ・アンド・プレイ実行時には、接続するコンピュータ上で稼動しているＯＳに対応しないデバイスドライバをインストールすることができないケースが発生し、上記の問題は依然として未解決であった。

本発明は上記従来の問題点に鑑み、次のような、印刷システム、情報処理装置及びその制御方法、並びにプログラムを提供することを目的とする。即ち、情報処理装置と印刷装置をＵＳＢ等のローカルインターフェースを用いて接続する構成において、使用するＯＳの種類に応じて、論理デバイスの構成をダイナミックに変更することができるようにする。

また、プラグ・アンド・プレイ実行時に、デバイスドライバのインストールに失敗せず、不明な論理デバイスも発生しないようにする。

上記目的を達成するため、本発明は、ローカルインターフェースを用いて情報処理装置と印刷装置が接続される印刷システムにおいて、前記印刷装置が持つ正規のデバイス名称／構成とは異なるデバイス名称／構成として、前記情報処理装置で稼動するオペレーティングシステムに標準で搭載されているデバイスドライバが適用可能なデバイス名称／構成を設定する設定手段と、前記情報処理装置が発行した変更指示に従って、前記印刷装置に搭載されている論理デバイスのうち前記情報処理装置が利用可能な論理デバイスを用いた構成となるように論理デバイスの組み合わせを変更し、前記設定手段で設定されたデバイス名称／構成を前記正規のデバイス名称／構成に変更する名称変更手段とを備えたことを特徴とする。

また、本発明は、ローカルインターフェースを用いて印刷装置に接続される情報処理装置において、当該情報処理装置で稼動するオペレーティングシステムの種類を判別する判別手段と、前記判別手段の判別の結果に応じて論理デバイスの組み合わせを変更させてデバイス名称／構成を正規のデバイス名称／構成に変更するための変更指示を前記印刷装置に対して発行する指示手段とを備えたことを特徴とする。

また、本発明は、ローカルインターフェースを用いて印刷装置に接続される情報処理装置において、当該情報処理装置で稼動するオペレーティングシステムの種類を判別する判別手段と、論理デバイスの組み合わせを変更させるための変更指示と共に、前記組み合わせの変更を前記判別手段の判別の結果に応じて実施させるための該判別の結果の通知を、前記印刷装置に対して発行する指示手段とを備えたことを特徴とする。

また、本発明は、ローカルインターフェースを用いて印刷装置に接続される情報処理装置の制御方法であって、前記情報処理装置で稼動するオペレーティングシステムの種類を判別する判別工程と、前記判別工程の判別の結果に応じて論理デバイスの組み合わせを変更させてデバイス名称／構成を正規のデバイス名称／構成に変更するための変更指示を前記印刷装置に対して発行する指示工程とを有することを特徴とする。

また、本発明は、ローカルインターフェースを用いて印刷装置に接続される情報処理装置の制御方法であって、前記情報処理装置で稼動するオペレーティングシステムの種類を判別する判別工程と、論理デバイスの組み合わせを変更させるための変更指示と共に、前記組み合わせの変更を前記判別工程の判別の結果に応じて実施させるための該判別の結果の通知を、前記印刷装置に対して発行する指示工程とを有することを特徴とする。

また、本発明は、ローカルインターフェースを用いて印刷装置に接続される情報処理装置の制御方法を実行するための、コンピュータで読み取り可能なプログラムであって、前記情報処理装置で稼動するオペレーティングシステムの種類を判別する判別ステップと、前記判別ステップの判別の結果に応じて論理デバイスの組み合わせを変更させてデバイス名称／構成を正規のデバイス名称／構成に変更するための変更指示を前記印刷装置に対して発行する指示ステップとを有することを特徴とする。

また、本発明は、ローカルインターフェースを用いて印刷装置に接続される情報処理装置の制御方法を実行するための、コンピュータで読み取り可能なプログラムであって、前記情報処理装置で稼動するオペレーティングシステムの種類を判別する判別ステップと、論理デバイスの組み合わせを変更させるための変更指示と共に、前記組み合わせの変更を前記判別ステップの判別の結果に応じて実施させるための判別の結果の通知を、前記印刷装置に対して発行する指示ステップとを有することを特徴とする。

本発明によれば、使用するＯＳの種類に応じて、論理デバイスの構成をダイナミックに変更することが可能になる。これにより、プラグ・アンド・プレイ実行時に、デバイスドライバのインストールに失敗せず、不明な論理デバイスの発生を防ぐことができる。

以下、本発明の実施の形態について、図面を参照しながら説明する。

［第１の実施の形態］
＜印刷システムの構成＞
図１は、本発明の実施の形態に係る印刷システムの構成を示すブロック図である。

図１に示すように、この印刷システムは、実施の形態に係る情報処理装置であるクラインアントコンピュータ（以下、単にコンピュータと記す）４０００と複合印刷装置５０００とを備えている。

まず、コンピュータ４０００の構成について説明する。コンピュータ４０００の制御部４１００は、システムバス４に接続される各構成デバイスを総括的に制御するＣＰＵ１を備えている。上記構成デバイスとして、ＲＡＭ２、ＲＯＭ３、キーボードＩ／Ｆ（インターフェース）５、ディプレイＩ／Ｆ６、外部メモリＩ／Ｆ７、及びプリンタＩ／Ｆ８が配設されている。また、ＣＰＵ１は、ＲＯＭ３のプログラム用ＲＯＭ、或いは外部メモリ１１に記憶された文書処理プログラム等に基づいて、図形やイメージ、文字、表（表計算等を含む）等が混在した文書処理を実行する。

ＲＯＭ３のプログラム用ＲＯＭ或いは外部メモリ１１は、ＣＰＵ１の制御プログラムであるオペレーティングシステム（ＯＳ）プログラム等を記憶し、ＲＯＭ３のフォント用ＲＯＭ或いは外部メモリ１１は、上記文書処理の際に使用するフォントデータ等を記憶する。ＲＯＭ３のデータ用ＲＯＭ或いは外部メモリ１１は、上記文書処理等を行う際に使用する各種データを記憶する。

ＲＡＭ２は、ＣＰＵ１の主メモリ、ワークエリア等として機能する。キーボードＩ／Ｆ５は、キーボード９や不図示のポインティングデバイスからのキー入力を制御する。ディプレイＩ／Ｆ６は、ディスプレイ１０の表示を制御する。外部メモリＩ／Ｆ７は、外部メモリ１１とのアクセスを制御する。

外部メモリ１１は、ブートプログラムや、各種のアプリケーション、フォントデータ、ユーザファイル、編集ファイル、プリンタドライバ等を記憶するメモリである。これは、例えばハードディスク（ＨＤ）や、フロッピー（登録商標）ディスク（ＦＤ）、コンパクトディスク（ＣＤ）等から構成されている。プリンタＩ／Ｆ８は、ＵＳＢケーブル３０００を介して複合印刷装置５０００に接続されて、複合印刷装置５０００との通信制御処理を実行する。尚、プリンタＩ／Ｆ８に接続されるケーブルは、ＵＳＢケーブルに限らず、その他のローカルインターフェースケーブルであっても構わないが、本実施例では、ＵＳＢケーブルを例に説明する。

また、ＣＰＵ１は、ＣＲＴ１０上の不図示のマウスカーソル等で指示されたコマンドに基づいて登録された種々のウインドウを開き、種々のデータ処理を実行する。ユーザは印刷を実行する際、印刷の設定に関するウインドウを開き、プリンタの設定や印刷モードの選択を含むプリンタドライバに対する印刷処理方法の設定を行える。

次に、複合印刷装置５０００の構成について説明する。複合印刷装置５０００の制御部５１００は、システムバス５４に接続される各構成デバイスを総括的に制御するＣＰＵ５１を備えている。上記構成デバイスとして、ＲＡＭ５２、ＲＯＭ５３、入出力部５５、印刷部Ｉ／Ｆ５６、外部メモリＩ／Ｆ５７、及びスキャナＩ／Ｆ５８が配設されている。

ＣＰＵ５１は、ＲＯＭ５３のプログラム用ＲＯＭに記憶された制御プログラム等或いは外部メモリ６０に記憶された制御プログラム等に基づいて、印刷部Ｉ／Ｆ５６に接続されている印刷部５９に出力情報としての画像信号を出力する。印刷部５９は、プリンタ機能を実現するための印刷機構である。

また、ＲＯＭ５３のプログラムＲＯＭには、ＣＰＵ５１の制御プログラム等を記憶する。ＲＯＭ５３のフォント用ＲＯＭは、上記出力情報を生成する際に使用するフォントデータ等を記憶し、ＲＯＭ５３のデータ用ＲＯＭは、外部メモリ６０を設けない印刷装置の場合には、コンピュータ４０００上で利用される情報等を記憶している。

ＣＰＵ５１は、入出力部５５を介してコンピュータ４０００との通信処理が可能となっており、複合印刷装置５０００の情報等をコンピュータ４０００に通知可能に構成されている。ＲＡＭ５２は、ＣＰＵ５１の主メモリ、ワークエリア等として機能する。外部メモリ６０は、ハードディスク（ＨＤ）、ＩＣカード等から成り、外部メモリＩ／Ｆ５７によりアクセスを制御される。

また、操作部６１は、操作のためのスイッチ及びＬＥＤ表示器等が配され、大型液晶表示装置を備えたタッチパネルになっている。読み取り部６２は、スキャナ機能を実現する原稿読み取り装置であり、スキャナＩ／Ｆ５８を介して、システムバス５４に読み込んだデータを転送する。

＜本実施の形態の特徴を成す構成＞
図２は、本発明の実施の形態に係る特徴的な処理を示す基本構成図である。

複合印刷装置５０００は、偽名宣言部２０２、デバイス名称／構成２０３、及びデバイス名称変更部２０４を備えていることを特徴とし、それらは図１のＲＯＭ５３の内部に存在する。偽名宣言部２０２は、正規のデバイス名称（つまり製品本来の名称）とは異なるデバイス名称／構成を名乗り、それをデバイス名称／構成２０３とする処理を行う。

ここに述べる製品とは、ＵＳＢによってコンピュータ４０００に接続されるデバイス（装置:印刷デバイスや印刷デバイス以外のデバイス）、つまり図２の例では印刷デバイスである複合印刷装置５０００ということになる。また、デバイス名称／構成とは、コンピュータ４０００上で稼動するＯＳから複合印刷装置５０００を認識することのできる名称のことであり、ＤｅｖｉｃｅＩＤとも言う。以下特に断りのない限り、デバイス名称／構成（或いはＤｅｖｉｃｅＩＤ）と示されるものは、ＵＳＢのインターフェース上での事項となる。

デバイス名称変更部２０４は、コンピュータ４０００から複合印刷装置５０００へ送られてきた名称変更指示に従いデバイス名称／構成２０３を変更する処理を行う。

一方、コンピュータ４０００は、名称変更指示部２１１を備えていることを特徴とし、それは図１のＲＯＭ３の内部に存在する。名称変更指示部２１１は、コンピュータ４０００で稼動しているＯＳの種類に応じて前記名称変更指示を作成して、複合印刷装置５０００へ送信する処理を行う。

複合印刷装置５０００をＵＳＢを使ってコンピュータ４０００に接続すると、コンピュータ４０００は、複合印刷装置５０００に対してデバイス名称／構成を返答するように要求する。その結果、複合印刷装置５０００からこの製品のデバイス名称／構成がコンピュータ４０００に返信される。そして、このデバイス名称／構成に従ってプラグ・アンド・プレイ機能が実行され、コンピュータ４０００上でデバイスドライバのインストール処理が行われる。

＜プラグ・アンド・プレイの仕組み＞
次に、プラグ・アンド・プレイ機能の仕組みについて、図３を参照して説明する。

図３（ａ），（ｂ）は、プラグ・アンド・プレイの仕組みを説明するためのデータ類を示す表形式図であり、同図（ａ）はＩＥＥＥ１２８４で規定されているデバイス情報を示し、同図（ｂ）はドライバプログラムの一例を示している。

図３（ａ）に示すように、ＩＥＥＥ１２８４で規定されているデバイス情報は、Ｃｌａｓｓ９０２、ＭＦＣ（製造者名）９０３、ＭＤＬ（製品モデル）９０４、及びＣＭＤ（コマンド）９０５で構成される。

コンピュータ４０００の外部メモリ１１の一時領域などに格納されているドライバプログラムは、図３（ｂ）に示すように、ドライバインストール時に参照される固有情報を記述したｉｎｆファイルと、各種実行モジュールと、リソースによって構成される。

プリンタドライバのＩｎｆファイルの中には、プラグ・アンド・プレイ時に参照されるデバイス名称／構成が記述されている。このデバイス名称／構成は、図３のＭＦＣ９０３とＭＤＬ９０４を組み合わせて構成されるものと一致する値が記載されている。スキャナドライバのｉｎｆファイルの中には、ＵＳＢの構成として複合印刷装置５０００のプログラムＲＯＭ５３上に定義されているＶｅｎｄｏｒＩＤ（製造者ＩＤ）とＰｒｏｄｕｃｔＩＤ（製品ＩＤ）とインターフェース番号とが一致する値が記述されている。ＶｅｎｄｏｒＩＤ（製造者ＩＤ）とＰｒｏｄｕｃｔＩＤ（製品ＩＤ）については後述する。

複合印刷装置５０００のＵＳＢケーブル２１をコンピュータ４０００に接続すると、コンピュータ４０００は複合印刷装置５０００に対して、後述する図４の各種インターフェースの情報を要求し、複合印刷装置５０００はそれを返答する。

コンピュータ４０００は、その受け取ったインターフェースの情報がスキャナ機能である場合にはＶｅｎｄｏｒＩＤ（製造者ＩＤ）とＰｒｏｄｕｃｔＩＤ（製品ＩＤ）とインターフェース番号を複合印刷装置５０００から入手する。そして、これら情報に一致する情報が記載されているｉｎｆファイルを外部メモリ１１の一時領域に格納されているｉｎｆの中から探索する。なお、ＶｅｎｄｏｒＩＤ（製造者ＩＤ）とＰｒｏｄｕｃｔＩＤ（製品ＩＤ）は、製品単位に付くものなので、後述する図４の３０３から３０５で示す全てのインターフェース間で共通の値となる。

複合印刷装置５０００から受け取ったインターフェースの情報がプリンタ機能である場合は、ＩＥＥＥ１２８４に準拠したデバイス名称／構成を複合印刷装置５０００から入手する。そして、これに一致する情報が記載されているｉｎｆファイルを同じ外部メモリ１１の一時領域に格納されているｉｎｆの中から探索する。このようにして、スキャナ機能やプリンタ機能などの論理デバイスに対応したドライバを正確に対応付けてインストールすることが可能となっている。

＜ＵＳＢの構成＞
図４は、複合ＵＳＢの構成の一例を示す概念図である。

図４の３０１が複合印刷装置５０００全体の複合ＵＳＢを示している。その中にコンフィギュレーション３０２が１つ存在し、更にその中に複数のインターフェース３０３、３０４、３０５が存在する。そして、この個々のインターフェース３０３〜３０５が複合印刷装置５０００が搭載する複合的な機能（例えば、スキャナ機能やプリント機能）を構成する個々の要素になっている。図４の３０３がスキャナ機能を実現するための論理デバイス、３０４がプリンタ機能を実現するためのＰＤＬ１の論理デバイス、３０５がＰＤＬ２の論理デバイスを示している。

複合ＵＳＢを採用した複合印刷装置５０００をコンピュータ４０００にＵＳＢケーブル２１で接続すると、インターフェース３０３〜３０５が１ずつコンピュータ４０００に通知される。その個々のインターフェース３０３〜３０５についてプラグ・アンド・プレイが発生し、その都度ドライバのインストール処理が実施されることとなる。

図５は、複合ＵＳＢの構成の他の例を示す概念図である。

図５の８０１が複合印刷装置５０００全体の複合ＵＳＢを示している。その中にコンフィギュレーション８０２が１つ存在し、更にその中にインターフェース８０３が１つだけ存在している。この例は、複合ＵＳＢのインターフェースが、ＰＤＬとして単一のＰＤＬ１という論理デバイスだけを備えた状態の単機能プリンタの構成と同じである。

図４のＵＳＢ構成が正規のデバイス名称／構成を示し、図５のＵＳＢ構成が偽名宣言部２０２でデバイス名称／構成２０３として設定するデバイス名称／構成として捉えることもできる。

図２の偽名宣言部２０２は、正規の（製品本来の）デバイス名称／構成とは異なるデバイス名称／構成を名乗り、それをデバイス名称／構成２０３とすることを示している。この時、正規のデバイス名称／構成と異なるデバイス名称／構成というのは、どんな名称／構成でも良いわけではなく、コンピュータ４０００上で稼動するＯＳが標準で保持しているデバイスドライバが適用可能なデバイス名称／構成のうちのいずれかを名乗る。そうすることによりプラグ・アンド・プレイ機能の結果、ドライバソフトを提供せずとも、ＯＳが標準で保持しているデバイスドライバが自動的に利用されてコンピュータ４０００にインストールされることになる。

偽名宣言部２０２は、これを目的としており、デバイスドライバが自動的にコンピュータ４０００にインストールされることにより、コンピュータ４０００と複合印刷装置５０００がデータのやり取りをする経路を確保することが可能となる。

＜実施の形態の背景的な概念＞
上述したように、コンピュータ４０００における名称変更指示部２１１は、コンピュータ４０００で稼動しているＯＳの種類に応じて名称変更指示を作成して、複合印刷装置５０００に送信する。ここで、ＯＳの種類に応じて複合印刷装置５０００に名称変更指示を送る理由について、図６を参照して説明する。

図６（ａ），（ｂ）は、実施の形態の背景的な概念を説明するための説明図であり、同図（ａ）は複合印刷装置の複合ＵＳＢの一構成例を示し、同図（ｂ）はコンピュータのＯＳと対応するデバイスドライバの一例を示している。

図６（ａ）の４１０は複合印刷装置を示しており、図１の複合印刷装置５０００と同じものである。複合印刷装置４１０の中には、１つのコンフィギュレーション４１１が存在し、さらにその中には、３つの論理デバイス４１２、４１３、４１４が存在している。即ち、それは、インターフェース０であるＳｃａｎｎｅｒという論理デバイスと、インターフェース１であるＰＤＬ１という論理デバイスと、インターフェース２であるＰＤＬ２という論理デバイスである。

また、図６（ａ）の４０１はコンピュータＡであり、図１のコンピュータ４０００と同じものである。このコンピュータＡのＲＡＭ２上では、ＯＳ１が稼動している。図６（ａ）の４２０はコンピュータＢであり、図１のコンピュータ４０００と同じものである。このコンピュータＢのＲＡＭ２上では、ＯＳ２が稼動している。

本例では、図６（ｂ）で示すように、Ｓｃａｎｎｅｒという論理デバイス用のデバイスドライバは、ＯＳ１とＯＳ２のいずれにも用意されている。同じく、ＰＤＬ１という論理デバイス用のデバイスドライバもＯＳ１とＯＳのいずれにも用意されている。しかし、ＰＤＬ２という論理デバイス用のデバイスドライバはＯＳ１には用意されず、ＯＳ２にのみ用意されている。

したがって、この図６（ｂ）の例に従うと、コンピュータＡと接続する場合においては、複合印刷装置４１０は、複合ＵＳＢを構成する論理デバイスとして、次のような構成であることが望ましい。即ち、Ｓｃａｎｎｅｒという論理デバイスを備えるほか、ＰＤＬに関してＰＤＬ１という論理デバイスだけを備えた状態になっている複合印刷装置であることが望ましい。つまり、スキャナ装置と、ＰＤＬ１だけが適用可能な印刷装置とを搭載した複合印刷装置であることが望ましい。

また、コンピュータＢと接続する場合においては、複合印刷装置４１０は、複合ＵＳＢを構成する論理デバイスとして、次のような構成であることが望ましい。即ち、Ｓｃａｎｎｅｒという論理デバイスを備えるほか、ＰＤＬに関してＰＤＬ１及びＰＤＬ２という論理デバイスを備えた状態になっている複合印刷装置であることが望ましい。つまり、スキャナ装置と、ＰＤＬ１及びＰＤＬ２が適用可能な印刷装置とを搭載した複合印刷装置であることが望ましい。

このような点を考慮して、本発明の実施の形態では、コンピュータ４０００がＯＳの種類に応じて複合印刷装置５０００に名称変更指示を送るように構成したものである。

・本発明を適用していない複合印刷装置の例１
次に、複合印刷装置４１０は当発明を適用していない複合印刷装置であるとして、その場合の問題点を明確にするための処理フローについて、図７を参照して説明する。

図７は、本発明を適用していない複合印刷装置の処理フローの第１の例を示すフローチャートである。即ち、複合ＵＳＢのインターフェースが、Ｓｃａｎｎｅｒという論理デバイスと、ＰＤＬとしてＰＤＬ１及びＰＤＬ２という論理デバイスを備えた状態になっている複合印刷装置４１０を、コンピュータＡに接続する場合の処理フローの例を示している。

本例の複合印刷装置４１０は、本発明を適用していないので、そのデバイス名称／構成は、正規のデバイス名称／構成である。コンピュータＡは、ＲＡＭ２上でＯＳ１が稼動している。

まず図７のステップＳ５０４で、ＣＰＵ１が外部メモリ１１に格納されているドライバセットアッププログラム（複合印刷装置４１０に対応したもの）を起動する。次のステップＳ５０５において、ＣＰＵ１は、ドライバセットアッププログラムがＯＳ１上で起動されたのか否かを判断する。Ｙｅｓの場合つまりＯＳ１上で起動された場合はステップＳ５０６へ進み、Ｎｏの場合はステップＳ５０７へ進む。

ステップＳ５０６では、ドライバセットアッププログラムを起動したＯＳがＯＳ１であることが明らかになったので、ＣＰＵ１は次の処理を実行する。即ち、Ｓｃａｎｎｅｒという論理デバイスとＰＤＬ１という論理デバイスのドライバモジュール類をコンピュータＡの外部メモリ１１上に展開する。そして、ＣＰＵ１の処理はステップＳ５０８へ進む。

なお、ステップＳ５０７は、ドライバセットアッププログラムを起動したＯＳがＯＳ２であることが明らかになった場合の処理である。この場合には、ＣＰＵ１は、Ｓｃａｎｎｅｒという論理デバイスと、ＰＤＬ１及びＰＤＬ２という論理デバイスのドライバモジュール類をコンピュータＡの外部メモリ１１上に展開し、ステップＳ５０８へ進む。本例では、コンピュータＡのＲＡＭ２上でＯＳ１のみが稼動しているとしているので、ステップＳ５０７は実施されない。

ステップＳ５０８では、複合印刷装置４１０をＵＳＢケーブルにてコンピュータＡに接続した後、コンピュータＡから、デバイス名称／構成等の返答要求が出され、その要求に複合印刷装置４１０のＣＰＵ５１が返答する。その後、コンピュータＡのＣＰＵ１の処理はステップＳ５０９へ進む。

ステップＳ５０９では、プラグ・アンド・プレイが発生し、複合印刷装置４１０から、Ｓｃａｎｎｅｒという論理デバイスと、ＰＤＬ１及びＰＤＬ２という論理デバイスが存在することが通知される。そして、前記ステップＳ５０６で外部メモリ１１上に展開した、ＳｃａｎｎｅｒとＰＤＬ１という論理デバイスのドライバモジュール類がＯＳ１により発見されてインストールされる。但し、ステップＳ５０９では、ＰＤＬ２という論理デバイスのドライバモジュールが無いので、このドライバモジュールはインストールされない。

次のステップＳ５１０では、コンピュータＡのＣＰＵ１は、ステップＳ５０９でドライバモジュールがインストールされなかったＰＤＬ２という論理デバイスのデバイスドライバをＯＳ１から要求する。この要求は、図１のＣＲＴ１０上にメッセージという形で表示され通知される。

続くステップＳ５１１では、ＯＳ１に対応したＰＤＬ２のデバイスドライバというものがコンピュータＡに存在しないので、ＣＰＵ１は対処できない。この場合、ＣＲＴ１０上に表示されるメッセージに対して、処理を先へ進める。

次のステップＳ５１２において、ＣＲＴ１０上に表示されるメッセージに対して、デバイスドライバを提供せずに処理を先へ進めた結果、最後には“インストールに失敗しました”というメッセージがＣＲＴ１０上に表示される。

その後のステップＳ５１３では、最終的に、ＰＤＬ２という論理デバイスがＯＳ１にとって不明な論理デバイスとして認識されてしまう。

この一連のフローの中で、ステップＳ５１１、Ｓ５１２、Ｓ５１３が問題点であり、複合印刷装置５０００が保持している機能である、ＰＤＬ２を利用した印刷機能がＯＳ１上で利用できないことが明確になっている。ＯＳ１で利用可能なＰＤＬ２という論理デバイスのデバイスドライバが存在しないので、本来ならば始めからＯＳ１に対しては、ＰＤＬ２による機能が無いように振る舞っていれば、このような問題は発生しないのである。

・本発明を適用していない複合印刷装置の例２
複合印刷装置４１０は当発明を適用していない複合印刷装置であるとして、この複合印刷装置４１０を、ＯＳ１が稼動しているコンピュータＡにＵＳＢによって接続する場合には、次のことが必要となる。即ち、複合印刷装置４１０の複合ＵＳＢのインターフェースが、Ｓｃａｎｎｅｒという論理デバイスを備えると共に、ＰＤＬとしてＰＤＬ１という論理デバイスだけを備えた状態になっている必要がある。この点について、図８を参照して説明する。

図８は、本発明を適用していない複合印刷装置の処理フローの第２の例を示すフローチャートである。即ち、複合ＵＳＢのインターフェースが、Ｓｃａｎｎｅｒという論理デバイスと、ＰＤＬとしてＰＤＬ１という論理デバイスだけを備えた状態になっている複合印刷装置６０１を、コンピュータＡに接続する場合の処理フローの例を示している。

複合印刷装置６０１は、当発明を適用していないので、デバイス名称／構成は、正規（製品本来）の名称／構成であり、図１の複合印刷装置５０００と同じものである。コンピュータＡは、ＲＡＭ２上でＯＳ１が稼動している。

本例において、ステップＳ６０４からステップＳ６０８までの処理は、それぞれ前述した図７のステップＳ５０４からステップＳ６０８までの処理と同じである。

ステップＳ６０８の処理後のステップＳ６０９では、プラグ・アンド・プレイ機能が発生する。その結果、複合印刷装置６０１から、複合ＵＳＢのインターフェースとして、Ｓｃａｎｎｅｒという論理デバイスが存在すると共に、ＰＤＬに関してＰＤＬ１という論理デバイスだけが存在することが通知される。そして、外部メモリ１１上に展開した、Ｓｃａｎｎｅｒという論理デバイスとＰＤＬ１という論理デバイスのドライバモジュール類が、ＯＳ１により発見されてインストールされる。本例の場合、これで処理が正常に終了しており、何のエラーも発生していない。

したがって、複合印刷装置を、ＯＳ１が稼動するコンピュータＡに接続する場合には、上記のような処理から次のことが分かる。即ち、複合印刷装置の複合ＵＳＢのインターフェースが、Ｓｃａｎｎｅｒという論理デバイスを備え、ＰＤＬに関してはＰＤＬ１という論理デバイスだけの構成になっていれば、正常に処理が完了することが分かる。

・本発明を適用していない複合印刷装置の例３
複合印刷装置７０１は当発明を適用していない複合印刷装置５０００であるとして、この複合印刷装置７０１を、ＯＳ２が稼動しているコンピュータＢにＵＳＢによって接続する場合には、次のことが必要となる。即ち、複合印刷装置７０１の複合ＵＳＢのインターフェースが、Ｓｃａｎｎｅｒという論理デバイスを備えると共に、ＰＤＬとしてＰＤＬ１及びＰＤＬ２という論理デバイスを備えた状態になっている必要がある。この点について、図９を参照して説明する。

図９は、本発明を適用していない複合印刷装置の処理フローの第３の例を示すフローチャートである。即ち、複合ＵＳＢのインターフェースが、Ｓｃａｎｎｅｒという論理デバイスと、ＰＤＬとしてＰＤＬ１及びＰＤＬ２という論理デバイスを備えた状態になっている複合印刷装置７０１を、コンピュータＢに接続する場合の処理フローの例を示している。

複合印刷装置７０１は、当発明を適用していないので、デバイス名称／構成は、正規の名称／構成であり、図１の複合印刷装置５０００と同じものである。コンピュータＢは、ＲＡＭ２上でＯＳ２が稼動している。

本例において、ステップＳ７０４からステップＳ７０８までの処理は、それぞれ前述した図７のステップＳ５０４からステップＳ６０８までの処理と同じである。但し、本例では、コンピュータＢで稼動するＯＳ２上で動作させているので、ステップＳ７０６は実施されず、ステップＳ７０７が実施される。

ステップＳ７０８の処理後のステップＳ７０９では、プラグ・アンド・プレイ機能が発生する。その結果、複合印刷装置５０００から、複合ＵＳＢのインターフェースとして、Ｓｃａｎｎｅｒという論理デバイスが存在すると共に、ＰＤＬに関してＰＤＬ１及びＰＤＬ２という論理デバイスが存在することが通知される。そして、外部メモリ１１上に展開した、Ｓｃａｎｎｅｒという論理デバイスとＰＤＬ１及びＰＤＬ２という論理デバイスのドライバモジュール類が、ＯＳ２により発見されてインストールされることになる。本例の場合、これで処理が正常に終了しており、何のエラーも発生していない。

したがって、複合印刷装置をＯＳ２が稼動するコンピュータＢに接続する場合には、上記のような処理から次のことが分かる。即ち、複合印刷装置の複合ＵＳＢのインターフェースが、Ｓｃａｎｎｅｒという論理デバイスを備え、ＰＤＬに関してはＰＤＬ１及びＰＤＬ２という論理デバイスを備えた構成になっていれば、正常に処理が完了することが分かる。

以上説明したように、ＯＳ１かＯＳ２のどちらかへの対応を主な使い方とすると決めて、複合印刷装置における複合ＵＳＢのインターフェースのデバイス名称／構成を決める場合、次のような問題が発生する。即ち、決めた方と異なるＯＳへの接続を行う場合には、不明な論理デバイスが発生するか、本来利用可能な論理デバイスが使えないといった問題が発生することになる。

＜ＵＳＢのデバイスディスクリプタ＞
次に、図１０を参照して、ＵＳＢのデバイスディスクリプタについて説明する。

図１０は、ＵＳＢのデバイスディスクリプタの一例を示した表形式図である。

ＵＳＢでは、デバイス（装置）の情報をコンピュータに伝えるために、５つのディスクリプタと呼ばれる情報を持っている。図１０に示すものは、そのうちのデバイスディスクリプタを示している。

このデバイスディスクリプタの内の「ｂＤｅｖｉｃｅＣｌａｓｓ」がクラスコードと呼ばれ、ＵＳＢ上のどういう種類のデバイスであるかを示すコードとなっている。マウスやキーボードなどの人とのインターフェースを司るデバイスはＨＩＤデバイスと呼ばれ、「０ｘ０３」という値を持つ。印刷装置の場合は「０ｘ０７」という値を持ち、ハードディスクやメモリなどの場合は「０ｘ０８」という値を持つ。

プラグ・アンド・プレイのときに、この値により印刷装置であると分かった場合、コンピュータは、デバイスに対してデバイスＩＤを返答するように要求を出す。その結果として、デバイスは、図３のＭＦＣ９０３とＭＤＬ９０４を結合したデバイスＩＤという文字列をコンピュータに対して返答する。なお、ここで言うデバイスＩＤとは、これまでに述べてきたデバイス名称／構成と同じものである。

図１０の「ＩＤＶｅｎｄｏｒ」は、デバイスの製造者のＩＤであり、この値はＵＳＢの規定で各製造者毎に一意に決まっている。なおこれは、ＶｅｎｄｏｒＩＤ（製造者ＩＤ）として前述している。「ｉｄＰｒｏｄｕｃｔ」はプロダクトＩＤと呼び、デバイスの製造者が独自に決めてよい値である。なおこれも、ＰｒｏｄｕｃｔＩＤ（製品ＩＤ）として前述している。この値は、デバイスの製造者がその製造者の中で一意となるように値を管理して、製品毎に一意の値になるように設定する。この２つの値をまとめるとＵＳＢ機器を一意に特定することができる。

＜第１の実施の形態の特徴を成す処理＞
次に、第１の実施の形態の特徴を成す処理として、偽名宣言部２０２、デバイス名称変更部２０４、及び名称変更指示部２１１を用いた処理について、図１１及び図１２を参照して説明を行う。なお、処理を簡略化するために、対象となるＯＳをＯＳ１とＯＳ２しか記載していないが、本発明はＯＳ１とＯＳ２に限定するものではない。

本処理で使用する複合印刷装置５０００は、複合ＵＳＢのインターフェースが、Ｓｃａｎｎｅｒという論理デバイスを備えると共に、ＰＤＬとしてＰＤＬ１及びＰＤＬ２という論理デバイスを備えた状態となっている複合印刷装置である。

偽名宣言部２０２により、デバイス名称／構成２０３は、正規のデバイスの名称ではなく、コンピュータ４０００上で稼動しているＯＳが標準でドライバを持っているデバイス名称／構成が適用可能なデバイス（旧製品）の名称が設定されている。この旧製品であるデバイスは印刷装置でも良いし、ストレージ装置でも、マウスなどの装置でも良い。但し、図１０に示した「ＩＤＶｅｎｄｏｒ」と「ＩＤＰｒｏｄｕｃｔ」は、正規のデバイス（複合印刷装置５０００）が持つ値をそのまま持たせておく。また、この場合のＯＳというのは、この実施の形態で言うとＯＳ１とＯＳ２の両方ということになるが、本発明はＯＳ１とＯＳ２に限定するものではない。また、コンピュータ４０００のＲＡＭ２上ではＯＳ１もしくはＯＳ２が稼動しているものとする。

図１１及び図１２は、第１の実施の形態の特徴を成す処理を示すフローチャートである。

まず、ステップＳ１００４では、コンピュータ４０００のＣＰＵ１が外部メモリ１１に格納されているドライバセットアッププログラム（複合印刷装置５０００に対応したもの）を起動する。次のステップＳ１００５では、ＣＰＵ１がＲＡＭ２上にて、ドライバセットアッププログラムがＯＳ１上で起動されたのか否かを判断する。Ｙｅｓの場合はステップＳ１００６へ進み、Ｎｏの場合はステップＳ１００７へ進む。

ステップＳ１００６では、ドライバセットアッププログラムを起動したＯＳがＯＳ１であることが明らかになったので、ＣＰＵ１は次のような処理を行う。即ち、Ｓｃａｎｎｅｒという論理デバイスとＰＤＬ１という論理デバイスのドライバモジュール類をコンピュータ４０００上の外部メモリ１１上に展開し、ステップＳ１００８へ進む。

ステップＳ１００７では、ドライバセットアッププログラムを起動したＯＳがＯＳ２であることが明らかになったので、ＣＰＵ１は、次のような処理を行う。即ち、Ｓｃａｎｎｅｒという論理デバイスと、ＰＤＬ１という論理デバイスと、ＰＤＬ２という論理デバイスのドライバモジュール類をコンピュータ４０００上の外部メモリ１１上に展開し、ステップＳ１００８へ進む。

ステップＳ１００８では、ＣＰＵ１がＲＡＭ２上においてドライバセットアッププログラムに包含される旧製品監視処理を起動する。その結果、旧製品監視処理という別の処理がＲＡＭ２上でスタートする（ステップＳ１０１０）。この旧製品監視処理は、次回以降はＯＳの起動時に自動的に起動されるようにＯＳのサービスとして登録するか、もしくはスタートアッププログラムとして登録しておく。

ここで、旧製品監視処理の意義について説明する。ステップＳ１００６またはステップＳ１００７の後、コンピュータ４０００が即座に複合印刷装置５０００とＵＳＢによる接続の確認がとれる保障はどこにもない。本発明が処理を完結させるためには、ステップＳ１００６またはステップＳ１００７の後、ＯＳが標準でドライバを持っているデバイス名称／構成の装置がＵＳＢにて接続される必要がある。そして、プラグ・アンド・プレイ機能でＯＳが標準で持っているデバイスドライバ、つまり旧製品のデバイスドライバがインストールされる必要があるので、別処理として旧製品監視処理を起動している。

ステップＳ１００９では、複合印刷装置５０００をＵＳＢケーブル３０００にて、コンピュータ４０００に接続した後、コンピュータ４０００から、デバイス名称／構成等の返答要求が出され、その要求にＣＰＵ５１が返答する。その後ステップＳ１０１１へ進む。

ステップＳ１０１１では、複合印刷装置５０００からデバイス名称／構成等が返信され、その情報に従ってプラグ・アンド・プレイ機能が発生する。これによって、コンピュータ４０００に接続された装置（複合印刷装置５０００）が、ＯＳが標準でドライバを持っているデバイス名称／構成の装置であると認識され、旧製品のデバイスドライバが自動でインストールされる。

例えば複合印刷装置５０００が、ＯＳが標準でドライバを持っている印刷装置を名乗っている場合には、図３のＭＦＣ９０３とＭＤＬ９０４から作成されるデバイス名称／構成をキーにして、ＯＳのデバイスドライバを外部メモリ１１上から探索する。そして、対象となるデバイスドライバをインストールする。また、複合印刷装置５０００が、ＯＳが標準でドライバを持っているストレージ装置を名乗っている場合には、ＵＳＢのクラスコードをキーにして、Ｇｅｎｅｒｉｃドライバを探索し、対象となるデバイスドライバをインストールする。

ここで重要なことは、この時点では、ステップＳ１００６やステップＳ１００７でコンピュータ４０００の外部メモリ１１上に展開されたドライバモジュールは利用されないという点である。ここで利用されるのは、ＯＳが標準で持っているドライバ（ＩｎＢｏｘ Ｄｒｉｖｅｒ）である。ここで、上記した 旧製品とは、ＯＳがＩｎＢｏｘ Ｄｒｉｖｅｒ用意している機種である。

このＩｎＢｏｘ Ｄｒｉｖｅｒが自動でインストールされることにより、複合印刷装置５０００とコンピュータ４０００との間にデータのやり取りをする経路を作成することが可能となる。その結果、複合印刷装置５０００は、コンピュータ４０００上のＯＳから指示を受けることができるようになる。

次に、ステップＳ１００８によって起動された旧製品監視処理はステップＳ１０１２に処理を移す。ステップＳ１０１２においてＣＰＵ１は、旧製品監視処理により、図１０の「ｉｄＶｅｎｄｏｒ」と「ｉｄＰｒｏｄｕｃｔ」が製品本来が持つ値のままとなっている装置がコンピュータ４０００に接続されているか否かを監視する。つまり、本実施の形態では複合印刷装置５０００がコンピュータ４０００に接続されているか否かを監視する。接続されていなければ、再度ステップＳ１０１２に戻り、接続されるまで待ち続ける。接続された場合にはステップＳ１０１３に処理を移す。

次のステップＳ１０１３では、ＣＰＵ１は、接続の確認のとれた複合印刷装置５０００の現在のデバイス名称／構成を問い合わせる。その際にＵＳＢのベンダーリクエストを用いて問い合わせを行う。

ここで、図１３及び図１４を参照して、ＵＳＢのリクエストについて説明する。

図１３及び図１４は、ＵＳＢのデバイスリクエストの構成を示した表形式図である。

図１３の１１０１は、デバイスリクエストの構成を示し、「ｂｍＲｅｑｕｅｓｔＴｙｐｅ」から「ｗＬｅｎｇｔｈ」までの合計８Ｂｙｔｅで１つのリクエストを構成している。デバイスリクエストには、標準のリクエストと、ＵＳＢクラスに応じたリクエストと、デバイスの製造者が独自に仕様を決めることのできるベンダーリクエストがある。「ｂｍＲｅｑｕｅｓｔＴｙｐｅ」に与える値で、この種類を切り替えることができる。

図１３の１１０２は、現在のデバイス名称／構成をデバイスに問い合わせる（デバイスに返答させる）ためのリクエストの一例である。「ｂｍＲｅｑｕｅｓｔＴｙｐｅ」の０ｘＤ１がデバイスに返答させるベンダーリクエストを示している。「ｂＲｅｑｕｅｓｔ」の０ｘ１０は現在のデバイス名称／構成を問い合わせていることを示す一例である。この値は一例であり、現在のデバイス名称／構成の問い合わせを示す値はこれに限るものではない。「ｗＬｅｎｇｈｔ」の０ｘ０１がデバイスが戻す値のサイズを示した一例である。なお、このサイズも０ｘ０１に限るものではない。

この図１３の１１０２で示したＵＳＢベンダーリクエストをコンピュータ４０００から複合印刷装置５０００に送信することで、現在のデバイスのデバイス名称／構成の問い合わせを行っている。

図１３の１１０３がデバイスからコンピュータ４０００に返信する返答を示した一例である。この例では１バイトを８つのビット（ビット７からビット０）に区切って、それぞれに意味を持たせた例を示している。ビット０と１の２桁で偽名を宣言中なのか或いは正規デバイスの名称／構成を宣言中なのかを表す。ビット２が１の場合、ＰＤＬ１がＡｃｔｉｖｅで０の場合Ｉｎａｃｔｉｖｅであることを示している。以下同様にビット２から５もそれぞれＰＤＬ２からＰＤＬ４の状態を示している。なお、本実施の形態ではＰＤＬ１とＰＤＬ２しか取り上げていないが、本発明がこれ以外のＰＤＬへも対応できることの一例を示している。ビット６でスキャナの状態を示しており、１の場合スキャナがＡｃｔｉｖｅ、０の場合スキャナがＩｎａｃｔｉｖｅであることを示す。そしてビット７は予備であり、通常その値は不定である。

なお本発明は、ここで示したビットの意味合いを使って各ＰＤＬの状態を示すという方式にとらわれるものではない。例えば１１０２の「ｗＬｅｎｇｔｈ」をもっと長く設定して、もっと長いデータ列が返答されるようにしても良い。その場合にはこの１１０３の構造もその長いデータ列に合わせて変更すれば良い。

例えばデバイスが偽名宣言中である場合は、００００００００Ｂ＝０ｘ００ という値がデバイスから返答される。また、正規デバイス宣言中であり且つＳｃａｎｎｅｒとＰＤＬ１がＡｃｔｉｖｅである場合は、０１０００１０１Ｂ＝０ｘ４５ という値が返答される。更に正規デバイス宣言中であり且つＳｃａｎｎｅｒとＰＤＬ１とＰＤＬ２がＡｃｔｉｖｅである場合は、０１００１１０１Ｂ＝０ｘ４Ｄ という値が返答される。

図１２に戻り、ステップＳ１０１４では、コンピュータ４０００がＵＳＢのベンダーリクエストを用いて問い合わせてきた現在のデバイス名称／構成を複合印刷装置５０００のＣＰＵ５１が返答する。

次のステップＳ１０１５において、ＣＰＵ１は、旧製品監視処理がＯＳ１上で稼動しているか否かを確認する。Ｙｅｓの場合はステップＳ１０１６、Ｎｏの場合はステップＳ１０１７へ進む。

ステップＳ１０１６では、ステップＳ１０１４で返答された複合印刷装置５０００からの回答が、正規デバイスを宣言中であり且つＳｃａｎｎｅｒとＰＤＬ１がＡｃｔｉｖｅであることを示しているか否かを確認する。Ｙｅｓの場合では、ｉｄＶｅｎｄｏｒとｉｄＰｒｏｄｕｃｔの値がその製品本来が持つ値となっている複合印刷装置５０００が、正規のデバイス名称を宣言中であり且つＳｃａｎｎｅｒとＰＤＬ１がＡｃｔｉｖｅになっているということである。

したがって、複合ＵＳＢのインターフェースの状態は、複合印刷装置５０００を、ＯＳ１が稼動するコンピュータ４０００に接続する場合の目的の状態になっているということが言える。このような状態は、デバイス名称／構成を製品本来の正規なものに変更した後で、ＯＳの再起動などを行った場合に発生し得る。この場合、何もすることがないのでステップＳ１０２４へ進んで処理を終了させる。ステップＳ１０１６でＮｏの場合は、ステップＳ１０１８へ進む。

ステップＳ１０１７では、ステップＳ１０１４で返答された複合印刷装置５０００からの回答が正規のデバイス宣言中で且つＳｃａｎｎｅｒとＰＤＬ１とＰＤＬ２であるか否かを確認する。Ｙｅｓの場合は、ｉｄＶｅｎｄｏｒとｉｄＰｒｏｄｕｃｔの値がその製品本来が持つ値の複合印刷装置５０００が、正規のデバイス名称を宣言中であり且つＳｃａｎｎｅｒとＰＤＬ１とＰＤＬ２がＡｃｔｉｖｅになっているということである。

したがって、複合ＵＳＢのインターフェースの状態は、複合印刷装置５０００を、ＯＳ２が稼動するコンピュータ４０００に接続する場合の目的の状態になっているということが言える。このような状態は、デバイス名称／構成を製品本来の正規なものに変更した後で、ＯＳの再起動などを行った場合に発生し得る。この場合、何もすることがないのでステップＳ１０２４へ進んで処理を終了させる。ステップＳ１０１７でＮｏの場合、ステップＳ１０１９へ進む。

ステップＳ１０１８では、ＣＰＵ１は、複合印刷装置５０００に対して、製品本来の正規なデバイス名称を宣言させて更に複合ＵＳＢのインターフェースの構成を次のように変更させるための名称変更指示を作成し発行する。即ち、複合印刷装置５０００の複合ＵＳＢのインターフェースが、Ｓｃａｎｎｅｒという論理デバイスを備えると共に、ＰＤＬとしてＰＤＬ１という論理デバイスだけを備えた構成になるように指示を発行する。

この名称変更指示の発行の方法には次の２通りの方法がある。

１つは、ＵＳＢベンダーリクエストによる方法である。図１４を参照して説明する。図１４の１１０４は、ＵＳＢベンダーリクエストにより、製品本来の正規なデバイス名称を宣言して更に複合ＵＳＢのインターフェースの構成が上述したＳｃａｎｎｅｒとＰＤＬ１の構成に切り替わるように名称変更指示を示した一例である。

図１４の１１０４に示す例において、「ｂｍＲｅｑｕｅｓｔＴｙｐｅ」の０ｘ４１が、デバイスに対する指示であるベンダーリクエストであることを示している。「ｂＲｅｑｕｅｓｔ」の０ｘ２０が、製品本来の正規なデバイス名称を宣言して更に複合ＵＳＢのインターフェースがＳｃａｎｎｅｒとＰＤＬ１の構成の複合印刷装置５０００に切り替わる指示を示した一例である。

ＵＳＢベンダーリクエストは、複合印刷装置において、コンピュータ上で稼動しているＯＳが標準でドライバを持っているデバイスを名乗る場合に、ストレージ装置とか、マウスなどの印刷装置以外のデバイスとして名乗った場合に利用すると良い。もちろん印刷装置として名乗った場合にも利用可能である。

このように、ＵＳＢベンダーリクエストによる方法によれば、偽名宣言部２０２によりどのような種類の装置を名乗っていても、名称変更指示を出すことが可能となる利点がある。

もう一つの方法として次のような方法がある。即ち、複合印刷装置がコンピュータ上で稼動しているＯＳが標準で持っているドライバを適用できるデバイスである場合には、印刷データに名称変更指示を埋め込んで複合印刷装置へ転送する方法もある。この方法について、図１５を参照して説明する。図１５は、名称変更指示に関するリクエスト例を示すデータ構成図である。

図１５の１２０１に示す例が本方法の一例を示している。図１５の１２０１は、データの先頭が、０ｘ００，０ｘ０１，０ｘ０３，０ｘ０４，０ｘ０５，０ｘ０６，０ｘ０７，ｘ０８，０ｘ０９で始まるデータを示している。なお、この先頭のデータは、一意に印刷データの開始ではなく名称変更指示を示すデータの開始であることが示せれば、これに限定されない。

図１５の１２０１に示す例では、その次の行に ｂＲｅｑｕｅｓｔ＝０ｘ２０ と記述されており、これが製品本来の正規なデバイス名称を宣言して更にＳｃａｎｎｅｒとＰＤＬ１の構成の複合印刷装置に切り替える指示の一例を示している。

複合印刷装置５０００は、図１５の１２０１に示すデータを印刷データとして受け取った場合に、先頭行のデータを読み込んだ時点で、これを印刷データとしては扱わず、それに続いて名称変更指示が来るものとして振る舞う。なお、図１５の１２０１に示す例の先頭行はこの例に限ったものではなく、印刷データとは確実に区別することができるデータであれば良く、予め複合印刷装置５０００側とドライバセットアッププログラム側でその値を合わせておく。

図１２に戻り、前記ステップＳ１０１８において、ＣＰＵ１から複合印刷装置５０００に対して名称変更指示が発行されると、ステップＳ１０２０へ進む。

前記ステップＳ１０１７でＮｏの場合に実行されるステップＳ１０１９では、ＣＰＵ１は、次のような処理を実行する。複合印刷装置５０００に対して、製品本来の正規なデバイス名称を宣言させて更に複合ＵＳＢのインターフェースの構成を次のように変更させるための名称変更指示を発行する。即ち、複合印刷装置５０００の複合ＵＳＢのインターフェースが、Ｓｃａｎｎｅｒという論理デバイスを備えると共に、ＰＤＬとしてＰＤＬ１とＰＤＬ２という論理デバイスを備えた構成になるように指示を発行する。

この名称変更指示の発行の方法には次の２通りの方法がある。前記ステップＳ１０１８で説明した内容と、扱うデータが異なるだけで基本的には同じであり、異なる部分のみ説明する。

１つは、ＵＳＢベンダーリクエストによる方法である。図１４を参照して説明する。図１４の１１０５は、ＵＳＢベンダーリクエストにより、製品本来の正規なデバイス名称を宣言して更に複合ＵＳＢのインターフェースの構成が上述したＳｃａｎｎｅｒとＰＤＬ１及びＰＤＬ２の構成に切り替わるように名称変更指示を示した一例である。

図１４の１１０５に示す例において、「ｂｍＲｅｑｕｅｓｔＴｙｐｅ」の０ｘ４１が、デバイスに対する指示であるベンダーリクエストであることを示している。「ｂＲｅｑｕｅｓｔ」の０ｘ３０が、製品本来の正規なデバイス名称を宣言して更に複合ＵＳＢのインターフェースがＳｃａｎｎｅｒとＰＤＬ１及びＰＤＬ２の構成の複合印刷装置に切り替わる指示を示した一例である。

もう一つの方法として次のような方法がある。即ち、複合印刷装置がコンピュータ上で稼動しているＯＳが標準で持っているドライバを適用できるデバイスである場合には、印刷データに名称変更指示を埋め込んで複合印刷装置へ転送する方法もある。この方法について、図１５を参照して説明する。

図１５の１２０２に示す例が本方法の一例を示している。図１５の１２０２は、データの先頭が、０ｘ００，０ｘ０１，０ｘ０３，０ｘ０４，０ｘ０５，０ｘ０６，０ｘ０７，ｘ０８，０ｘ０９で始まるデータを示している。

図１５の１２０２に示す例では、その次の行に ｂＲｅｑｕｅｓｔ＝０ｘ３０ と記述されており、これが製品本来の正規なデバイス名称を宣言して更にＳｃａｎｎｅｒとＰＤＬ１及びＰＤＬ２の構成の複合印刷装置に切り替える指示の一例を示している。

複合印刷装置５０００は、図１５の１２０２に示すデータを印刷データとして受け取った場合に、先頭行のデータを読み込んだ時点で、これを印刷データとしては扱わず、それに続いて名称変更指示が来るものとして振る舞う。なお、図１５の１２０２に示す例の先頭行はこの例に限ったものではないことは、前述した図１５の１２０１に示す例と同じである。

図１２に戻り、ステップＳ１０１９でＣＰＵ１から複合印刷装置５０００に対して名称変更指示を発行すると、ステップＳ１０２０へ進む。

前記ステップＳ１０１８またはステップＳ１０１９の処理後のステップＳ１０２０では、名称変更指示を受けた複合印刷装置５０００のＣＰＵ５１が次のような処理を実施する。即ち、ＣＰＵ５１がその名称変更指示に従って、製品本来の正規なデバイス名称を宣言すると共に、複合印刷装置５０００における複合ＵＳＢのインターフェースの構成を変更する。即ち、複合ＵＳＢのインターフェースの構成が、Ｓｃａｎｎｅｒという論理デバイスとＰＤＬとしてＰＤＬ１という論理デバイスのみの構成、もしくはＳｃａｎｎｅｒという論理デバイスとＰＤＬとしてＰＤＬ１及びＰＤＬ２という論理デバイスの構成に変更する。その上で、複合印刷装置５０００をリブートする。なお、リブートする目的は、コンピュータ４０００で稼動しているＯＳに複合印刷装置５０００の存在を再認識させ、プラグ・アンド・プレイ機能を再び発生させるためである。

その後のステップＳ１０２１は、リブートした複合印刷装置５０００が立ち上がり、コンピュータ４０００との間でプラグ・アンド・プレイ機能が発生する。その結果、前記ステップＳ１００６もしくは前記ステップＳ１００７でコンピュータ４０００上の外部メモリ１１上に展開したドライバソフトがインストールされる。ドライバセットアッププログラムが、ＯＳ１上で起動された場合にはＳｃａｎｎｅｒとＰＤＬ１のデバイスドライバがインストールされ、ＯＳ２上で起動された場合にはＳｃａｎｎｅｒとＰＤＬ１及びＰＤＬ２のデバイスドライバがインストールされる。

以下、上述した第１の実施の形態の特徴を成す処理を要約して説明する。

複合印刷装置５０００は、偽名宣言部２０２により、製品本来の正規なデバイス名称を名乗らず、コンピュータ４０００上で稼動しているＯＳに標準で搭載されているデバイスドライバのいずれかが適用可能なデバイス名称／構成を名乗る。その結果、複合印刷装置５０００をＯＳにＵＳＢを用いて接続した場合、まず始めにＯＳに標準で搭載されているデバイスドライバが適用できる装置であると認識され、デバイスドライバも自動でインストールされる。この作業により、複合印刷装置５０００はＯＳからの指示を受けることができるようになる。

一方、複合印刷装置５０００はＯＳに標準で搭載されているデバイスドライバのいずれかと一致する名称／構成を名乗っていても、内部的には、コンピュータ４０００からの指示に従って名称／構成変更することのできるデバイス名称変更部２０４を備える。複合印刷装置５０００に対応するデバイスドライバソフトウェアはコンピュータ４０００上でまず、ＯＳの種類を判別する。そして複合印刷装置５０００に搭載されている論理デバイスのうち、どのデバイスドライバがそのＯＳ用に用意されているか判別して利用可能な論理デバイスのみの組み合わせとなるような指示を複合印刷装置５０００に対して行う（名称変更指示部２１１）。

それを受けた複合印刷装置５０００はその指示に従ってＵＳＢ上の論理デバイスの組み合わせを変更し、更に、製品本来の正規なデバイス名称／構成を名乗る。その結果、ＵＳＢで接続するＯＳで利用可能なデバイスドライバがＯＳにインストールされて利用可能となる。

＜第１の実施の形態に係る利点＞
上述したように第１の実施の形態によれば、スキャナ装置や複数のＰＤＬ印刷装置を搭載した複合印刷装置５０００が複合ＵＳＢを採用する場合に、接続するコンピュータ４０００上で稼動するＯＳの種類に応じて、自動的に最適な構成を採ることが可能となる。即ち、複合ＵＳＢのインターフェースを、コンピュータ４０００で稼動しているＯＳに対応するデバイスドライバが用意されている論理デバイスのみの構成にすることができる。これにより、プラグ・アンド・プレイ機能により全ての論理デバイスのドライバをインストールすることが可能となる。また、デバイスドライバのインストール処理が失敗することもなく、不明なデバイスが発生することも防止することが可能となる。

［第２の実施の形態］
第２の実施の形態では、複合印刷装置５０００がＯＳの種類を判断し、複合ＵＳＢのインターフェースの構成について、変更すべき目的の構成を自分で決めて変更している点に特徴がある。上記第１の実施の形態と異なる点について説明する。

＜第２の実施の形態の特徴を成す処理＞
図１６は、第２の実施の形態の特徴を成す処理を示すフローチャートであり、図１１で説明したステップＳ１００４からステップＳ１０１２までの処理と同じ処理を行った後に実行される。なお、本実施の形態においても、処理を簡略化するために対象ＯＳはＯＳ１とＯＳ２しかないものとしているが、本発明はＯＳ１とＯＳ２に限定するものではない。

図１１で説明したように、旧製品監視処理が起動され、複合印刷装置５０００がコンピュータ４０００に接続されているか否かを監視し、接続された場合にはステップＳ１３１３に処理を移す。

次のステップＳ１３１３では、ＣＰＵ１は、接続の確認のとれた装置の現在のデバイス名称／構成を複合印刷装置５０００に問い合わせる。その際にＵＳＢのベンダーリクエストを用いて問い合わせを行う。そして、次のステップＳ１３１４では、コンピュータ４０００が問い合わせてきた現在のデバイス名称／構成を複合印刷装置５０００のＣＰＵ５１が返答する。

続くステップＳ１３１５では、ＣＰＵ１がステップＳ１３１４で返答された複合印刷装置５０００からの回答が正規のデバイス宣言中であるか否かを確認する。正規のデバイス宣言中であればステップＳ１３２０へ進み、正規のデバイス宣言中でなければステップＳ１３１６へ進む。

ステップＳ１３１６では、複合印刷装置５０００が正規のデバイス宣言中でないので、複合印刷装置５０００に対してＣＰＵ１から名称変更指示を発行する。このとき、旧製品監視処理が稼動しているＯＳの種類も一緒に通知する。

図１７は、この名称変更指示のデータ内容の一例を示す例示図である。

図１７の１４０１は、ＵＳＢベンダーリクエストにより、名称変更指示と旧製品監視処理がＯＳ１上で稼動していることを通知する一例を示している。旧製品監視処理が稼動しているＯＳは、複合印刷装置５０００と接続するコンピュータ４０００上で稼動しているＯＳと等しいものである。「ｂｍＲｅｑｕｅｓｔＴｙｐｅ」の０ｘ４１がデバイスに対する指示であるベンダーリクエストであることを示している。「ｂＲｅｑｕｅｓｔ」の０ｘＦ０が旧製品監視処理が稼動しているＯＳの種類をデバイスに通知することを示しており、「ｂＶａｌｕｅ」の０ｘ００１０がＯＳがＯＳ１であることを示している。

図１７の１４０２は、ＵＳＢベンダーリクエストにより、名称変更指示と旧製品監視処理がＯＳ２上で稼動していることを通知する一例を示している。「ｂｍＲｅｑｕｅｓｔＴｙｐｅ」の０ｘ４１がデバイスに対する指示であるベンダーリクエストであることを示している。「ｂＲｅｑｕｅｓｔ」の０ｘＦ０が旧製品監視処理が稼動しているＯＳの種類をデバイスに通知することを示しており、「ｂＶａｌｕｅ」の０ｘ００２０がＯＳがＯＳ２であることを示している。

一方、複合印刷装置５０００が図１６及び図１７のコンピュータ４０００上で稼動しているＯＳが標準で持っているドライバを適用できるデバイスである場合には、更に印刷データに切り替えリクエストを埋め込んで印刷装置に流す方法もある。図１７の１４０３がその一例を示している。

図１７の１４０３は、そのデータの先頭が０ｘ００，０ｘ０１，０ｘ０３，０ｘ０４，０ｘ０５，０ｘ０６，０ｘ０７，ｘ０８，０ｘ０９で始まるデータを示している。この先頭のデータは、一意に印刷データの開始を示すものではなく名称変更指示を示すデータの開始であることが示せれば、これに限定するものではない。

図１７の１４０３では、２行目に「ｂＲｅｑｕｅｓｔ＝０ｘＦ０」と記述されており、これが名称変更指示であり、その次のデータとして旧製品監視処理が稼動しているＯＳの種類をデバイスに通知することを示している。その次の行には「ｗＶａｌｕｅ＝０ｘ００１０」と記述されており、旧製品監視処理が稼動しているＯＳがＯＳ１であることを示している。

図１７の１４０４では、データの先頭が、０ｘ００，０ｘ０１，０ｘ０３，０ｘ０４，０ｘ０５，０ｘ０６，０ｘ０７，０ｘ０８，０ｘ０９で始まるデータを示している。この先頭のデータは、一意に印刷データの開始を示すものではなく名称変更指示を示すデータの開始であることが示せれば、これに限定されない。

図１７の１４０４では、２行目に「ｂＲｅｑｕｅｓｔ＝０ｘＦ０」と記述されており、これが名称変更指示であり、その次のデータとして旧製品監視処理が稼動しているＯＳの種類をデバイスに通知することを示している。その次の行には「ｗＶａｌｕｅ＝０ｘ００２０」と記述されており、旧製品監視処理が稼動しているＯＳがＯＳ２であることを示している。

複合印刷装置５０００は、図１７の１４０３や１４０４を印刷データとして受け取った場合に、先頭行のデータを読み込んだ時点で、これを印刷データとしては扱わず、それに続いて名称変更指示が来るものとして振る舞う。そしてその名称変更指示が次に旧製品監視処理が稼動しているＯＳの種類をデバイスに通知することを示している場合には、続いてＯＳの種類の通知が来るものとして振る舞う。なお、図１７の１４０３や１４０４の先頭行はこの例に限ったものではなく、印刷データとは確実に区別することの可能データをしていれば良く、予め複合印刷装置５０００側とドライバセットアッププログラム側でその値を合わせておく。

図１６に戻り、ステップＳ１３１７において、複合印刷装置５０００のＣＰＵ５１は、名称変更指示で通知された旧製品監視処理が稼動しているＯＳがＯＳ１か否かを判断する。ＯＳ１の場合はステップＳ１３１８へ進み、ＯＳ１でない場合はステップＳ１３１９へ進む。

ステップＳ１３１８では、ＯＳ１に適合するデバイス名称／構成に変更すべきことが明らかになったので、ＣＰＵ５１が製品本来の正規なデバイス名称を宣言する。そして複合ＵＳＢのインターフェースの構成を、Ｓｃａｎｎｅｒと、ＰＤＬとしてＰＤＬ１のみの構成に変更してリブートする。

また、ステップＳ１３１９では、ＯＳ２に適合するデバイス名称／構成に変更すべきことが明らかになったので、ＣＰＵ５１が製品本来の正規なデバイス名称を宣言する。そして、複合ＵＳＢのインターフェースの構成を、Ｓｃａｎｎｅｒと、ＰＤＬとしてＰＤＬ１とＰＤＬ２の構成に複合印刷装置５０００を変更してリブートする。

なお、リブートする目的はコンピュータ１３０２で稼動しているＯＳに複合印刷装置５０００の存在を再認識させ、プラグ・アンド・プレイ機能を再び発生させるためである。

ステップＳ１３１８とステップＳ１３１９の後は、ステップＳ１３２４へ進む。

一方、前記ステップＳ１３１５において、ＣＰＵ１が正規のデバイス宣言中であると判断した後で実行されるステップＳ１３２０では、次のような処理が行われる。即ち、ステップＳ１３１４で返答された複合印刷装置５０００からの回答が正規のデバイス宣言中であった場合にＣＰＵ１が旧製品監視処理がＯＳ１上で稼動しているか否かを確認する。Ｙｅｓの場合はステップＳ１３２１へ進み、Ｎｏの場合はステップＳ１３２２へ進む。

ステップＳ１３２１では、複合印刷装置５０００からの返答がＳｃａｎｎｅｒとＰＤＬ１であるか否かを確認する。この処理に来た時点でＳｃａｎｎｅｒとＰＤＬ１であれば、それは複合ＵＳＢのインターフェースの構成が目的の構成であるので、何もせずにステップＳ１３２３へ進み処理を終了する。つまり、ＣＰＵ１は一連のドライバセットアッププログラムの処理を終了する。ＳｃａｎｎｅｒとＰＤＬ１でなければ、目的とする構成ではないことが明らかなのでデバイス構成を変更するためにステップＳ１３１６へ進む。

このような状態になるケースは、一度複合印刷装置５０００をＯＳ２が稼動しているコンピュータ４０００に接続して、ＳｃａｎｎｅｒとＰＤＬ１とＰＤＬ２の構成にした後で、その複合印刷装置をＯＳ１の稼動しているコンピュータに接続した場合などが考えられる。

一方、ステップＳ１３２２では、複合印刷装置５０００からの返答がＳｃａｎｎｅｒとＰＤＬ１とＰＤＬ２であるか否かを確認する。この処理に来た時点でＳｃａｎｎｅｒとＰＤＬ１とＰＬＤ２であれば、それは複合ＵＳＢのインターフェースの構成が目的の構成であるので、何もせずにステップＳ１３２３へ進み処理を終了する。ＳｃａｎｅｒとＰＤＬとＰＤＬ２でなければ、目的とする構成ではないことが明らかなのでデバイス構成を変更するためにステップＳ１３１６へ進む。

このような状態になるケースは、一度複合印刷装置５０００をＯＳ１が稼動しているコンピュータ４０００に接続して、ＳｃａｎｎｅｒとＰＤＬ１の構成にした後で、その複合印刷装置をＯＳ２の稼動しているコンピュータに接続した場合などが考えられる。

ステップＳ１３２４では、リブートした複合印刷装置５０００が立ち上がり、コンピュータ１３０２とプラグ・アンド・プレイ機能が発生する。その結果１３０６もしくは１３０７でコンピュータ４０００上の外部メモリ１１上に展開したドライバソフトがインストールされることを示している。

結果として、ドライバセットアッププログラムがＯＳ１上で稼動している場合スキャナ／ＰＤＬ１、ＯＳ２上で稼動している場合はスキャナ／ＰＤＬ１／ＰＤＬ２のドライバがインストールされる。

＜第２の実施の形態に係る利点＞
第２の実施の形態では、スキャナ装置や複数のＰＤＬ印刷装置を搭載した複合印刷装置５０００が複合ＵＳＢを採用する場合に、接続するコンピュータ４０００上で稼動するＯＳの種類に応じて、自動的に最適な構成を採ることが可能となる。その際、複合印刷装置５０００がＯＳの種類を判断して自分で変更すべき目的の構成を判断して構成を変更する。

その結果、複合印刷装置５０００を、コンピュータ４０００で稼動しているＯＳに対応するデバイスドライバが用意されている論理デバイスのみの構成にすることができる。これにより、プラグ・アンド・プレイ機能の結果、全ての論理デバイスに対応したデバイスドライバをインストールすることが可能となる。また、デバイスドライバのインストール処理が失敗することもなく、不明なデバイスが発生することも防止することが可能となる。

［第３の実施の形態］
第１及び第２の実施の形態では、複合印刷装置５０００が、接続するコンピュータ４０００上で稼動するＯＳの種類に応じて、自動的に最適な構成を採るようにした。第３の実施の形態では、構成が変更された複合印刷装置５０００の状態を元に戻すときの処理について説明する。つまり、第１または第２の実施の形態適用後の複合印刷装置５０００の構成を、第１または第２の実施の形態適用前の状態に戻す処理について説明する。

＜第３の実施の形態に係る処理＞
図１８は、第３の実施の形態の特徴を成す処理を示すフローチャートである。なお、本実施の形態においても、処理を簡略化するために対象ＯＳはＯＳ１とＯＳ２しかないものとしているが、本発明はＯＳ１とＯＳ２に限定するものではない。

本実施の形態における複合印刷装置５０００は、複合ＵＳＢのインターフェースとして、Ｓｃａｎｎｅｒという論理デバイスと、ＰＤＬとしてＰＤＬ１とＰＤＬ２という論理デバイスを搭載した装置である。さらに、上記第１の実施の形態もしくは第２の実施の形態適用後の製品本来の正規なデバイス名称／構成を名乗っている装置である。また、図１０に示した、ＵＳＢのデバイスディスクリプタにおけるＩＤＶｅｎｄｏｒとＩＤＰｒｏｄｕｃｔは、もちろんその製品本来が持つ値をそのまま持っている。そして、本実施の形態におけるコンピュータ４０００のＲＡＭ２上には、ＯＳ１もしくはＯＳ２が稼動しているものとする。

まず図１８のステップＳ１５０４において、ＣＰＵ１は、第１及び第２の実施の形態で起動した旧製品監視処理（ステップＳ１０１０もしくはＳ１３１０）がＲＡＭ２上で実行中か否かを確認する。実行中であればステップＳ１５０５へ進む。実行中でなければステップＳ１５０６へ進む。

ステップＳ１５０５では、ＣＰＵ１は、ＲＡＭ２上にて旧製品監視処理の停止を行い、ステップＳ１５０６へ進む。旧製品監視処理を停止するのは次のような理由による。即ち、停旧製品監視処理は、ＵＳＢのデバイスディスクリプタにおけるＩＤＶｅｎｄｏｒとＩＤＰｒｏｄｕｃｔがその製品本来が持つ値のままとなっている製品が接続されるのを待つ。接続を確認したら、その接続されたデバイスの名称／構成を問い合わせて、デバイスを製品本来のデバイス名称／構成に変更するべく動作する。つまり、旧製品監視処理は本実施の形態とは逆の処理を行うものであるため、ここでその処理を停止しておくのである。

ステップＳ１５０６においては、ＣＰＵ１は、図１０に示した、ＵＳＢのデバイスディスクリプタにおけるＩＤＶｅｎｄｏｒとｉｄＰｒｏｄｕｃｔが製品本来が持つ値のままとなっている装置が接続されているか否かを監視する。接続されていなければ、再度ステップＳ１５０６に戻り、接続されるまで待ち続ける。接続された場合にはステップＳ１５０７に処理を移す。

ステップＳ１５０７では、接続確認のとれた複合印刷装置５０００に対して、旧製品のデバイス名称／構成を宣言するようにＣＰＵ１から名称変更指示を発行する。この時、名称変更指示の出し方には２通りの方法がある。

１つは、ＵＳＢベンダーリクエストによる方法である。ここで図１４を用いてＵＳＢのリクエストについて説明する。

図１４の１１０６は、ＵＳＢベンダーリクエストにより、旧製品のデバイス名称／構成に切り替わるような名称変更指示を示した一例である。「ｂｍＲｅｑｕｅｓｔＴｙｐｅ」の０ｘ４１がデバイスに対する指示であるベンダーリクエストであることを示している。「ｂＲｅｑｕｅｓｔ」の０ｘＦＦが旧製品のデバイス名称／構成を宣言して旧製品に切り替わる指示を示した一例である。

もう一つの方法としては、印刷データに切り替えリクエストを埋め込んで印刷装置に流す方法もある。

図１５の１２０３に示す例が本方法の一例を示している。図１５の１２０３は、データの先頭が、０ｘ００，０ｘ０１，０ｘ０３，０ｘ０４，０ｘ０５，０ｘ０６，０ｘ０７，ｘ０８，０ｘ０９で始まるデータを示している。なお、この先頭のデータは、一意に印刷データの開始ではなく名称変更指示を示すデータの開始であることが示せれば、これに限定されない。

図１５の１２０３に示す例では、その次の行に ｂＲｅｑｕｅｓｔ＝０ｘＦＦ と記述されており、これが旧製品のデバイス名称を宣言して旧製品の構成に切り替える指示の一例を示している。

複合印刷装置５０００は、図１５の１２０３を印刷データとして受け取った場合に、先頭行のデータを読み込んだ時点で、これを印刷データとしては扱わず、それに続いて名称変更指示が来るものとして振る舞う。なお、図１５の１２０３の先頭行はこの例に限ったものではなく、印刷データとは確実に区別することの可能なデータをしていれば良く、予め複合印刷装置５０００側とドライバセットアッププログラム側でその値を合わせておく。

ステップＳ１５０７で名称変更指示を発行すると、ステップＳ１５０８へ進む。ステップＳ１５０８では、名称変更指示を受けた複合印刷装置５０００のＣＰＵ５１が、その名称変更指示に従って、旧製品のデバイス名称を宣言する。つまりコンピュータ４０００のＯＳに標準で搭載されているデバイスドライバのいずれかと一致する名称を宣言することになる。そして旧製品の構成に変更した上で、複合印刷装置５０００をリブートする。

その後のステップＳ１５０９は、リブートした複合印刷装置５０００が立ち上がり、コンピュータ１５０２との間でプラグ・アンド・プレイ機能が発生し、その結果、ＯＳが標準で持っているドライバ（ＩｎｂｏｘＤｒｉｖｅｒ）がインストールされる。

上記本実施の形態の処理（元に戻す処理）は、独立した個別のユーティリティとして存在していても良いし、ドライバのＵｎインストール処理の一環として行っても良く、本発明ではその実施時期については特に定めない。

＜第３の実施の形態に係る利点＞
第３の実施の形態によれば、コンピュータ４０００で稼動しているＯＳに対応するデバイスドライバが用意されている論理デバイスのみの構成になっているデバイスの名称／構成を、旧製品を示すデバイスの名称／構成に戻すことが可能となる。この処理により、デバイスの状態を初期状態に戻すことが可能となる。

＜その他の実施形態＞
なお、本発明の目的は、以下の処理を実行することによっても達成される。即ち、上述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）が記憶媒体に格納されたプログラムコードを読み出す処理である。

この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施の形態の機能を実現することになり、そのプログラムコード及び該プログラムコードを記憶した記憶媒体は本発明を構成することになる。

また、プログラムコードを供給するための記憶媒体としては、次のものを用いることができる。例えば、フロッピー（登録商標）ディスク、ハードディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＤＶＤ−ＲＷ、ＤＶＤ＋ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等である。または、プログラムコードをネットワークを介してダウンロードしても良い。

また、コンピュータが読み出したプログラムコードを実行することにより、上記実施の形態の機能が実現される場合も本発明に含まれる。加えて、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（ＯＳ）等が実際の処理の一部または全部を行い、その処理によって前述した実施の形態の機能が実現される場合も含まれる。

更に、前述した実施の形態の機能が以下の処理によって実現される場合も本発明に含まれる。即ち、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれる。その後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行う場合である。

実施の形態に係る印刷システムの構成を示すブロック図である。 実施の形態に係る特徴的な処理を示す基本構成図である。 プラグ・アンド・プレイの仕組みを説明するためのデータ類を示す表形式図である。 複合ＵＳＢの構成の一例を示す概念図である。 複合ＵＳＢの構成の他の例を示す概念図である。 実施の形態の背景的な概念を説明するための説明図である。 本発明を適用していない複合印刷装置の処理フローの第１の例を示すフローチャートである。 本発明を適用していない複合印刷装置の処理フローの第２の例を示すフローチャートである。 本発明を適用していない複合印刷装置の処理フローの第３の例を示すフローチャートである。 ＵＳＢのデバイスディスクリプタの一例を示した表形式図である。 第１の実施の形態の特徴を成す処理を示すフローチャートである。 図１１の続きのフローチャートである。 ＵＳＢのデバイスリクエストの構成を示した表形式図である。 ＵＳＢのデバイスリクエストの構成を示した表形式図である。 名称変更指示に関するリクエスト例を示すデータ構成図である。 第２の実施の形態の特徴を成す処理を示すフローチャートである。 名称変更指示のデータ内容の一例を示す例示図である。 第３の実施の形態の特徴を成す処理を示すフローチャートである。

符号の説明

１，５１ ＣＰＵ
２，５２ ＲＡＭ
３，５３ＲＯＭ
１１，６０ 外部メモリ
５１ ＣＰＵ
５３ ＲＯＭ
２１１ 名称変更指示部
２０２ 偽名宣言部
２０３ デバイス名称／構成
２０４ デバイス名称変更部
４０００ コンピュータ
５０００ 複合印刷装置

Claims (15)

1. ローカルインターフェースを用いて情報処理装置と印刷装置が接続される印刷システムにおいて、
   前記印刷装置が持つ正規のデバイス名称／構成とは異なるデバイス名称／構成として、前記情報処理装置で稼動するオペレーティングシステムに標準で搭載されているデバイスドライバが適用可能なデバイス名称／構成を設定する設定手段と、
   前記情報処理装置が発行した変更指示に従って、前記印刷装置に搭載されている論理デバイスのうち前記情報処理装置が利用可能な論理デバイスを用いた構成となるように論理デバイスの組み合わせを変更し、前記設定手段で設定されたデバイス名称／構成を前記正規のデバイス名称／構成に変更する名称変更手段とを備えたことを特徴とする印刷システム。
2. 前記設定手段は、前記印刷装置が持つ正規のデバイス名称／構成とは異なるデバイス名称／構成として、印刷デバイスまたは印刷デバイス以外のデバイスの名称／構成を設定することを特徴とする請求項１に記載の印刷システム。
3. 前記ローカルインターフェースはＵＳＢであり、前記名称変更手段は、ＵＳＢのベンダーリクエストに従って処理を行うことを特徴とする請求項１または２に記載の印刷システム。
4. 前記名称変更手段は、前記情報処理装置から前記印刷装置に送られる印刷データの中に含まれた前記変更指示に従って処理することを特徴とする請求項１乃至３のいずれか一項に記載の印刷システム。
5. 前記情報処理装置で稼動するオペレーティングシステムの種類を判別する判別手段と、
   前記判別手段の判別の結果に応じて前記正規のデバイス名称／構成を判断して前記変更指示を作成し発行する指示手段とを備えたことを特徴とする請求項１乃至４のいずれか一項に記載の印刷システム。
6. 前記情報処理装置で稼動するオペレーティングシステムの種類を判別する判別手段と、
   前記名称変更手段に対して、前記判別手段の判別の結果を通知すると共に前記変更指示を発行する指示手段とを備え、
   前記名称変更手段は、前記指示手段から通知された前記判別手段の判別の結果に応じて前記正規のデバイス名称／構成を判断し、前記設定手段で設定されたデバイス名称／構成を前記正規のデバイス名称／構成に変更することを特徴とする請求項１乃至４のいずれか一項に記載の印刷システム。
7. 前記印刷装置に対して、デバイス名称／構成を問い合わせる問い合わせ手段を有し、
   前記指示手段は、前記問い合わせ手段の問い合わせ結果を参照して、前記変更指示を発行することを特徴とする請求項５または６に記載の印刷システム。
8. 前記名称変更手段によって前記正規のデバイス名称／構成として変更されたデバイス名称／構成を、前記情報処理装置の指示に従って、該正規のデバイス名称／構成とは異なる元のデバイス名称／構成に変更する手段を備えたことを特徴とする請求項１乃至７のいずれか一項に記載の印刷システム。
9. ローカルインターフェースを用いて印刷装置に接続される情報処理装置において、
   当該情報処理装置で稼動するオペレーティングシステムの種類を判別する判別手段と、
   前記判別手段の判別の結果に応じて論理デバイスの組み合わせを変更させてデバイス名称／構成を正規のデバイス名称／構成に変更するための変更指示を前記印刷装置に対して発行する指示手段とを備えたことを特徴とする情報処理装置。
10. ローカルインターフェースを用いて印刷装置に接続される情報処理装置において、
    当該情報処理装置で稼動するオペレーティングシステムの種類を判別する判別手段と、
    論理デバイスの組み合わせを変更させるための変更指示と共に、前記組み合わせの変更を前記判別手段の判別の結果に応じて実施させるための該判別の結果の通知を、前記印刷装置に対して発行する指示手段とを備えたことを特徴とする情報処理装置。
11. 前記印刷装置に対してデバイス名称／構成を問い合わせる問い合わせ手段を有し、
    前記指示手段は、前記問い合わせ手段の問い合わせ結果を参照して、前記変更指示を発行することを特徴とする請求項９または１０に記載の情報処理装置。
12. ローカルインターフェースを用いて印刷装置に接続される情報処理装置の制御方法であって、
    前記情報処理装置で稼動するオペレーティングシステムの種類を判別する判別工程と、
    前記判別工程の判別の結果に応じて論理デバイスの組み合わせを変更させてデバイス名称／構成を正規のデバイス名称／構成に変更するための変更指示を前記印刷装置に対して発行する指示工程とを有することを特徴とする情報処理装置の制御方法。
13. ローカルインターフェースを用いて印刷装置に接続される情報処理装置の制御方法であって、
    前記情報処理装置で稼動するオペレーティングシステムの種類を判別する判別工程と、
    論理デバイスの組み合わせを変更させるための変更指示と共に、前記組み合わせの変更を前記判別工程の判別の結果に応じて実施させるための該判別の結果の通知を、前記印刷装置に対して発行する指示工程とを有することを特徴とする情報処理装置の制御方法。
14. ローカルインターフェースを用いて印刷装置に接続される情報処理装置の制御方法を実行するための、コンピュータで読み取り可能なプログラムであって、
    前記情報処理装置で稼動するオペレーティングシステムの種類を判別する判別ステップと、
    前記判別ステップの判別の結果に応じて論理デバイスの組み合わせを変更させてデバイス名称／構成を正規のデバイス名称／構成に変更するための変更指示を前記印刷装置に対して発行する指示ステップとを有することを特徴とするプログラム。
15. ローカルインターフェースを用いて印刷装置に接続される情報処理装置の制御方法を実行するための、コンピュータで読み取り可能なプログラムであって、
    前記情報処理装置で稼動するオペレーティングシステムの種類を判別する判別ステップと、
    論理デバイスの組み合わせを変更させるための変更指示と共に、前記組み合わせの変更を前記判別ステップの判別の結果に応じて実施させるための判別の結果の通知を、前記印刷装置に対して発行する指示ステップとを有することを特徴とするプログラム。

Images