(57)【要約】【課題】デバイスにエラーが発生した場合、情報処理装置に接続されている他のデバイスの動作に与える影響を抑えつつ、エラーが発生したデバイスをリセットすることができるようにすることを目的とする。【解決手段】情報処理装置は、通信インタフェースを介して接続されているデバイスのエラーが連続して閾値以上の回数発生したか否かを検出するエラー検出手段と、前記エラーが連続して閾値以上の回数発生した場合には、複数の通信インタフェースのうち、前記エラーが発生したデバイスが接続されている通信インタフェースをリセットするリセット手段とを有する。【選択図】図７
2019101972.tif 000002
【特許請求の範囲】
【請求項１】
通信インタフェースを介して接続されているデバイスのエラーが連続して閾値以上の回数発生したか否かを検出するエラー検出手段と、
前記エラーが連続して閾値以上の回数発生した場合には、複数の通信インタフェースのうち、前記エラーが発生したデバイスが接続されている通信インタフェースをリセットするリセット手段と
を有することを特徴とする情報処理装置。
【請求項２】
前記リセット手段は、前記エラーが連続して閾値以上の回数発生した場合には、前記エラーが発生したデバイスが接続されていない通信インタフェースをリセットしないことを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記リセット手段は、前記エラーが発生したデバイスが接続されている通信インタフェースの電力供給を一定時間停止した後に前記電力供給を再開することにより、前記リセットを行うことを特徴とする請求項１又は２に記載の情報処理装置。
【請求項４】
前記通信インタフェースを介して前記デバイスに要求を送信し、前記要求に対する処理結果を前記通信インタフェースを介して前記デバイスから受信する要求手段をさらに有し、
前記エラー検出手段は、前記処理結果を基にエラーを検出することを特徴とする請求項１〜３のいずれか１項に記載の情報処理装置。
【請求項５】
前記リセット手段は、複数の通信インタフェースと前記複数の通信インタフェースにそれぞれ接続されているデバイスとの対応関係を示すテーブルを基に、前記エラーが発生したデバイスが接続されている通信インタフェースを特定することを特徴とする請求項１〜４のいずれか１項に記載の情報処理装置。
【請求項６】
前記リセット手段は、前記エラーが連続して閾値以上の回数発生し、かつ、前記エラーが発生したデバイスが接続されている通信インタフェースに複数のデバイスが接続されている場合には、ログアウト後に、複数の通信インタフェースのうち、前記エラーが発生したデバイスが接続されている通信インタフェースをリセットすることを特徴とする請求項１〜５のいずれか１項に記載の情報処理装置。
【請求項７】
前記通信インタフェースは、ＵＳＢインタフェースであることを特徴とする請求項１〜６のいずれか１項に記載の情報処理装置。
【請求項８】
通信インタフェースを介して接続されているデバイスのエラーが連続して閾値以上の回数発生したか否かを検出するエラー検出ステップと、
前記エラーが連続して閾値以上の回数発生した場合には、複数の通信インタフェースのうち、前記エラーが発生したデバイスが接続されている通信インタフェースをリセットするリセットステップと
を有することを特徴とする情報処理装置の制御方法。
【請求項９】
コンピュータを、請求項１〜７のいずれか１項に記載された情報処理装置の各手段として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、情報処理装置の制御方法及びプログラムに関するものである。
【背景技術】
【０００２】
ＵＳＢデバイスは、パーソナルコンピュータ、プリンタ、スキャナ、複合機等のホストコンピュータに接続可能である。ホストコンピュータは、自身の持つＵＳＢホストコントローラを介して、ＵＳＢインタフェースにより接続されたＵＳＢデバイスと通信を行う。ＵＳＢは、Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓの略称である。ホストコンピュータは、自身のＣＰＵで動作するプログラムとして、前述のＵＳＢホストコントローラを制御するドライバ部分及びアプリケーション部分を有し、これらのプログラムに基づいて動作する。さらに、ホストコンピュータは、自身のシステムを制御するオペレーションシステムを有し、各種処理を行う。
【０００３】
一方、ＵＳＢデバイスは、ＵＳＢデバイスコントローラを有する。ＵＳＢデバイスは、ＵＳＢデバイス上に存在するＣＰＵで動作するプログラムとして、ＵＳＢデバイスコントローラを制御するドライバ部分及びアプリケーション部分を持ち、これらのプログラムに基づいて動作する。なお、ＵＳＢデバイスは、システムの規模に応じでオペレーションシステムを持つもの、持たないものがある。
【０００４】
前述のように、ホストコンピュータとＵＳＢデバイスは、それぞれのＣＰＵを有し、個々のプログラムで動作する。しかし、ＵＳＢインタフェースの通信上では、ホストコンピュータがマスタとなり、ＵＳＢデバイスがスレーブの関係で動作し、通信の主導権はホストコンピュータが握っている。
【０００５】
ＵＳＢ２．０インタフェースでは、ホストコンピュータとＵＳＢデバイスが４本の信号線で接続される。１本はグランド（ＧＮＤ）であり、もう１本はＵＳＢデバイスにホストコンピュータから提供される５Ｖの電力のＶＢＵＳと呼ばれる信号線であり、残りの２本はデータが流れるＤ＋とＤ−の計４本の信号線である。ＵＳＢデバイスは、ホストコンピュータから供給されるＶＢＵＳの５Ｖがなくなると、自身のシステムを停止させる。ホストコンピュータは、ＶＢＵＳの５Ｖのオン／オフを制御することにより、ＵＳＢデバイスのシステム停止とシステム再起動を制御することが可能である。
【０００６】
また、ＵＳＢデバイスを接続した際に接続不良が発生することがあり、それを自動検知して自動復旧する技術が知られている（例えば特許文献１参照）。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特許第４８７２５５３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、特許文献１では、複数のＵＳＢデバイスが接続されていた場合が考慮されておらず、他の正常に動作しているＵＳＢデバイスも一緒にリセットされてしまう可能性がある。
【０００９】
そこで本発明は、デバイスにエラーが発生した場合、情報処理装置に接続されている他のデバイスの動作に与える影響を抑えつつ、エラーが発生したデバイスをリセットすることができるようにすることを目的とする。
【課題を解決するための手段】
【００１０】
本発明の情報処理装置は、通信インタフェースを介して接続されているデバイスのエラーが連続して閾値以上の回数発生したか否かを検出するエラー検出手段と、前記エラーが連続して閾値以上の回数発生した場合には、複数の通信インタフェースのうち、前記エラーが発生したデバイスが接続されている通信インタフェースをリセットするリセット手段とを有する。
【発明の効果】
【００１１】
本発明によれば、デバイスにエラーが発生した場合、情報処理装置に接続されている他のデバイスの動作に与える影響を抑えつつ、エラーが発生したデバイスをリセットすることができる。
【図面の簡単な説明】
【００１２】
【図１】情報処理システムの構成例を示す図である。
【図２】画像形成装置のハードウェア構成を例示する図である。
【図３】ＶＢＵＳ信号のオン／オフを実現する回路構成図である。
【図４】画像形成装置上で動作するソフトウェアモジュールの構成を示す図である。
【図５】管理テーブルの例を示す図である。
【図６】ディスプレイに表示されるアプリケーションの画面の例を示す図である。
【図７】ＵＳＢ制御ライブラリの処理の流れを示すフローチャートである。
【図８】ＵＳＢ制御モジュールの処理の流れを示すフローチャートである。
【図９】アプリケーションのＵＳＢ制御処理の概要を示すフローチャートである。
【図１０】ＵＳＢ制御ライブラリの処理の流れを示すフローチャートである。
【図１１】ＵＳＢ制御モジュールの処理の流れを示すフローチャートである。
【発明を実施するための形態】
【００１３】
（第１の実施形態）
図１は、本発明の第１の実施形態による情報処理システムの構成例を示す図である。情報処理システムは、画像形成装置１と、ＵＳＢデバイス２と、ＵＳＢデバイス３とを有する。画像形成装置１は、情報処理装置の一例であり、ＵＳＢホストコントローラ２０７（図２）を有する。ＵＳＢは、Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓの略称である。ＵＳＢデバイス２は、ＵＳＢデバイスコントローラ３０６（図３）を有する。ＵＳＢデバイス３は、ＵＳＢデバイスコントローラ３１３（図３）を有する。ＵＳＢデバイス２は、ＵＳＢケーブル４を介して、画像形成装置１に接続されている。ＵＳＢデバイス３は、ＵＳＢケーブル５を介して、画像形成装置１に接続されている。例えば、ＵＳＢデバイス２はＩＣカードリーダであり、ＵＳＢデバイス３はＵＳＢメモリであるが、これに限定されるものではなく、どのような種類のデバイスであってもよい。
【００１４】
画像形成装置１は、後からアプリケーションを追加でインストールすることにより、機能を拡張することが可能になっている。アプリケーションは、ＵＳＢデバイス２及び３を制御することも可能である。ＵＳＢデバイス２及び３を制御するアプリケーションの例としては、ＩＣカードを使った認証を行うＩＣカード認証アプリや、ＵＳＢメモリに格納された文書データを印刷するメディアプリントアプリなどが挙げられる。
【００１５】
なお、図１では、画像形成装置１とＵＳＢデバイス２，３とが１対２で接続されている例を示しているが、これに限定されるものではなく、ＵＳＢの規格上、接続可能な１対１２７までの接続が可能である。
【００１６】
図２は、画像形成装置１のハードウェア構成を例示する図である。中央処理演算装置（ＣＰＵ）２０１は、画像形成装置１を稼働させるためのソフトウェアを実行する。システムバス２０２は、ＣＰＵ２０１が他のユニットにアクセスするため、及び、他のユニット同士がアクセスするための通路である。ハードディスクユニット（ＨＤＤ）２０３は、画像形成装置１のソフトウェア、画像形成装置１が動作するために必要なデータベース、及び一次保存ファイル等を格納する。ＨＤＤ２０３は、Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ（ＳＳＤ）等の他の大容量不揮発メモリでも構わない。Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ（ＲＡＭ）２０４は、画像形成装置１のプログラム、プログラム動作時の変数、及び各ユニットからＤＭＡ（ダイレクトメモリアクセス）で転送されるデータ等を格納する。
【００１７】
ネットワークコントローラインタフェース（Ｉ／Ｆ）２０６は、画像形成装置１とネットワーク上の他の機器と通信を行う。ネットワークコントローラ２０５は、ネットワークコントローラＩ／Ｆ２０６を制御する。ＵＳＢホストインタフェース（Ｉ／Ｆ）２０８及び２２０は、ＵＳＢインタフェースであり、画像形成装置１とＵＳＢデバイス２，３との通信を行うための通信インタフェースである。ＵＳＢホストＩ／Ｆ２０８は、ＵＳＢケーブル４を介して、ＵＳＢデバイス２に接続される。ＵＳＢホストＩ／Ｆ２２０は、ＵＳＢケーブル５を介して、ＵＳＢデバイス３に接続される。ＵＳＢホストコントローラ２０７は、ＵＳＢホストＩ／Ｆ２０８及び２２０を制御する。
【００１８】
ディスプレイ２１０は、画像形成装置１の動作状況をユーザ等が確認できるように表示する。ディスプレイコントローラ２０９は、ディスプレイ２１０の表示制御を行う。入力部２１２は、画像形成装置１へのユーザからの指示を受け付ける。入力部コントローラ２１１は、入力部２１２を制御する。入力部２１２は、具体的には、タッチパネル、１０キー、又はキーボード等の操作部である。入力部２１２がタッチパネルである場合、入力部２１２は物理的にはディスプレイ２１０の表面に装着された形態になる。
【００１９】
リアルタイムクロック（ＲＴＣ）２１３は、画像形成装置１の時計機能、アラーム機能、タイマー機能等を提供する。不揮発メモリ２１４は、書き換え可能な不揮発な記録メディアである。なお、不揮発メモリ２１４は、例えば、Ｓｔａｔｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ（ＳＲＡＭ）であってもよい。また、不揮発メモリ２１４は、Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ（ＥＥＰＲＯＭ）等であってもよい。
【００２０】
Ｇｅｎｅｒａｌ Ｐｕｒｐｏｓｅ Ｉｎｐｕｔ Ｏｕｔｐｕｔ（ＧＰＩＯ）２１５は、ＣＰＵ２０１が基板回路上の信号線のローレベル／ハイレベルの状況を読み取る、又は信号線のローレベル／ハイレベルの状況の設定を変更可能にするユニットである。スキャナ制御部２１６は、スキャナ２１７を制御する。スキャナ２１７は、原稿を読み取る装置である。プリンタ制御部２１８は、プリンタ２１９を制御する。プリンタ２１９は、画像データを用紙に出力するための装置である。
【００２１】
図３は、画像形成装置１及びＵＳＢデバイス２，３の構成例を示す図である。画像形成装置１は、ＵＳＢホストＩ／Ｆ２０８及び２２０毎にＶＢＵＳ３０２及び３０９をオン／オフ制御することができる。
【００２２】
ＵＳＢデバイス２は、ＵＳＢデバイスコントローラ３０６と、ＵＳＢホストコントローラ２０７と通信するためのＵＳＢデバイスインタフェース（Ｉ／Ｆ）３０１とを有する。画像形成装置１とＵＳＢデバイス２とが通信するために、画像形成装置１のＵＳＢホストＩ／Ｆ２０８と、ＵＳＢデバイス２のＵＳＢデバイスＩ／Ｆ３０１との間が４本の信号線３０２〜３０５で接続がされている。なお、信号線３０２〜３０５は、ＵＳＢケーブル４に内包されている。ＶＢＵＳ３０２は、画像形成装置１からＵＳＢデバイス２に５Ｖの電力を供給するための電力線である。Ｄ＋（３０３）とＤ−（３０４）は、画像形成装置１とＵＳＢデバイス２との間を通信する実データを差動信号によって通信させる信号線である。ＧＮＤ３０５は、他の信号線のローレベル／ハイレベルの基準を決める電気回路には必須であるグランド信号線である。
【００２３】
ＵＳＢデバイス３は、ＵＳＢデバイスコントローラ３１３と、ＵＳＢホストコントローラ２０７と通信するためのＵＳＢデバイスインタフェース（Ｉ／Ｆ）３０８とを有する。画像形成装置１とＵＳＢデバイス３とが通信するために、画像形成装置１のＵＳＢホストＩ／Ｆ２２０と、ＵＳＢデバイス３のＵＳＢデバイスＩ／Ｆ３０８との間が４本の信号線３０９〜３１２で接続がされている。なお、信号線３０９〜３１２は、ＵＳＢケーブル５に内包されている。ＶＢＵＳ３０９は、画像形成装置１からＵＳＢデバイス３に５Ｖの電力を供給するための電力線である。Ｄ＋（３１０）とＤ−（３１１）は、画像形成装置１とＵＳＢデバイス３との間を通信する実データを差動信号によって通信させる信号線である。ＧＮＤ３１２は、他の信号線のローレベル／ハイレベルの基準を決める電気回路には必須であるグランド信号線である。
【００２４】
ＧＰＩＯ２１５は、少なくとも、ＶＢＵＳ３０２のオン／オフを制御する第１のレジスタビットと、ＶＢＵＳ３０９のオン／オフを制御する第２のレジスタビットを有する。ＧＰＩＯ２１５は、ＣＰＵ２０１の指示により、第１のレジスタビットの値をＡＮＤ回路３０６に出力し、第２のレジスタビットの値をＡＮＤ回路３１４に出力する。
【００２５】
ＡＮＤ回路３０６は、ＧＰＩＯ２１５が出力する第１のレジスタビットと、ＵＳＢホストＩ／Ｆ２０８から出力されるＶＢＵＳの出力値との論理積（ＡＮＤ）を取り、論理積値をＶＢＵＳ３０２に出力する。この構成により、ＣＰＵ２０１は、ＵＳＢデバイス２に与えるＶＢＵＳ３０２のオン／オフを制御する。即ち、ＡＮＤ回路３０６は、ＧＰＩＯ２１５から出力される第１のレジスタビットに基づいて、ＶＢＵＳ３０２を介したＵＳＢデバイス２への電力供給を遮断可能である。ＵＳＢレセクタプル３０７は、ＵＳＢケーブル４の先端に設けられたＵＳＢプラグを接続する部分（差し込み口）である。ＡＮＤ回路３０６は、ＵＳＢホストＩ／Ｆ２０８とＵＳＢレセクタプル３０７の間のＶＢＵＳ上（即ち、ＵＳＢインタフェースの電力線上）に設けられる。
【００２６】
ＡＮＤ回路３１４は、ＧＰＩＯ２１５が出力する第２のレジスタビットと、ＵＳＢホストＩ／Ｆ２２０から出力されるＶＢＵＳの出力値との論理積（ＡＮＤ）を取り、論理積値をＶＢＵＳ３０９に出力する。この構成により、ＣＰＵ２０１は、ＵＳＢデバイス３に与えるＶＢＵＳ３０９のオン／オフを制御する。即ち、ＡＮＤ回路３１４は、ＧＰＩＯ２１５から出力される第２のレジスタビットに基づいて、ＶＢＵＳ３０９を介したＵＳＢデバイス３への電力供給を遮断可能である。ＵＳＢレセクタプル３１５は、ＵＳＢケーブル５の先端に設けられたＵＳＢプラグを接続する部分（差し込み口）である。ＡＮＤ回路３１４は、ＵＳＢホストＩ／Ｆ２２０とＵＳＢレセクタプル３１５の間のＶＢＵＳ上（即ち、ＵＳＢインタフェースの電力線上）に設けられる。
【００２７】
なお、本実施形態では、ＡＮＤ回路３０６及び３１４を用いてＶＢＵＳ３０２及び３０９のオン／オフを制御する場合を説明したが、ハイサイドスイッチとＯＲ回路を用いてＶＢＵＳ３０２及び３０９のオン／オフを制御することも可能である。また、ＶＢＵＳ３０２及び３０９のオン／オフを切り替え可能な構成であれば、他の構成であってもよい。
【００２８】
図４は、画像形成装置１のＣＰＵ２０１が実行するソフトウェアモジュールの構成例を示す図である。アプリ管理モジュール４０１は、画像形成装置１上で動作する各種アプリケーションの管理を行う。具体的には、アプリ管理モジュール４０１は、アプリケーションのインストール、アンインストール、開始、停止などのライフサイクル管理機能とアプリケーション間の連携のためのフレームワーク機能を持つ。ＳＤＫライブラリ４０２は、アプリケーションから画像形成装置１上の機能を利用するためのライブラリ群である。認証アプリ４０３は、ユーザ認証を行うためのアプリケーションであり、ユーザが認証されると、アプリ管理モジュール４０１のフレームワーク機能を利用して他のソフトウェアモジュールにイベントを通知する。各ソフトウェアモジュールは、認証アプリ４０３からこのイベントを受け取ることで、ユーザがログイン中であるか否かを判断できる。複数のアプリ４０４は、画像形成装置１の機能をユーザに使わせるためのアプリケーションである。認証アプリ４０３及び複数のアプリ４０４は、ＳＤＫライブラリ４０２を利用して所望の機能を実現する。
【００２９】
ＵＳＢ制御ライブラリ４０５は、アプリケーション４１３がＵＳＢデバイス２又は３の制御を行うためのＡＰＩを提供するライブラリである。ＵＳＢ制御ライブラリ４０５は、ｏｐｅｎ／ｒｅａｄ／ｗｒｉｔｅ／ｉｏｃｔｌ／ｃｌｏｓｅなどの低レベルのＡＰＩを提供している。アプリケーション４１３がＵＳＢデバイス２又は３を制御したい場合は、通常のファイルＩ／ＯのＡＰＩと同様に、所望のデバイスをオープンして制御のための識別子（図５の制御識別子５０５）を取得し、取得した識別子を指定して各種制御ＡＰＩを呼び出す。
【００３０】
ジョブ制御ライブラリ４０６は、画像形成装置１が備えるコピー／スキャン／プリントなどの各種ジョブの実行制御を行うためのＡＰＩを提供するライブラリである。入力ライブラリ４０７は、アプリケーション４１３が入力部２１２からの入力を受信するためのＡＰＩを提供するライブラリである。描画ライブラリ４０８は、ディスプレイ２１０に画面を描画するためのＡＰＩを提供するライブラリである。
【００３１】
ＵＳＢ制御モジュール４０９は、ＵＳＢ制御ライブラリ４０５からの要求に従って、ＵＳＢホストコントローラ２０７の制御を行うためのソフトウェアモジュールである。ＵＳＢ制御モジュール４０９は、接続されたＵＳＢデバイス２又は３がどのＵＳＢホストＩ／Ｆ２０８又は２２０に接続されているかについて管理テーブル（図５）を用いて管理する。
【００３２】
ジョブ制御モジュール４１０は、ジョブ制御ライブラリ４０６からの要求に従って、スキャナ制御部２１６やプリンタ制御部２１８を制御してジョブを実行したり、ジョブ状況の管理をしたりする。入力制御モジュール４１１は、入力ライブラリ４０７からの要求に従って、入力部コントローラ２１１からの入力を受けてデータを転送する。描画制御モジュール４１２は、描画ライブラリ４０８からの要求に従って、ディスプレイコントローラ２０９を制御してディスプレイ２１０に描画を行う。
【００３３】
アプリケーション４１３及びＳＤＫライブラリ４０２は、Ｊａｖａ（登録商標）言語で記述されたソフトウェアモジュールである。各制御モジュール４０９〜４１２は、Ｃ言語で記述されたソフトウェアモジュールである。ＳＤＫライブラリ４０２及び各制御モジュール４０９〜４１２の間は、ＪＮＩ（ＪａｖａＮａｔｉｖｅＩｎｔｅｒｆａｃｅ）を使って呼び出しを行う。
【００３４】
図５は、画像形成装置１に接続されているＵＳＢデバイス２及び３等の情報を管理するために利用する管理テーブルの例である。この管理テーブルは、ＵＳＢ制御モジュール４０９により管理される。図５では、説明を簡単にするために、管理テーブルは、最低限の情報を示しているが、接続形態をより詳細に識別するために階層情報や親デバイス情報などを合わせて管理してもよい。
【００３５】
デバイス番号５０１は、接続されたＵＳＢデバイスの番号を示すものであり、ＵＳＢデバイスを接続するたびにＩＤをインクリメントして常に一意のＩＤが割り振られる。同種のＵＳＢデバイスが接続された場合でも、異なるデバイス番号が割り振られるため、アプリケーション４１３から同種のＵＳＢデバイスでも区別して制御可能である。ＵＳＢホストＩ／Ｆの情報５０２は、ＵＳＢデバイスがどのＵＳＢホストＩ／Ｆに接続されているかを示す情報である。ハブ経由で接続されたＵＳＢデバイスは、同一のＵＳＢホストＩ／Ｆの情報を持つことになる。ベンダＩＤ５０３は、接続されたＵＳＢデバイスのベンダ識別情報である。プロダクトＩＤ５０４は、接続されたＵＳＢデバイスの製品識別情報である。制御識別子５０５は、アプリケーション４１３がＵＳＢデバイスをオープンした際に割り振る識別子であり、オープンされていない状態（初期状態やクローズされた場合）では「−１」が設定される。ＵＳＢデバイスのオープン要求を受けた場合、制御識別子５０５が「−１」であれば、新たな制御識別子を割り振って、要求元アプリケーション４１３に制御識別子５０５を返す。アプリケーション４１３は、オープン時に取得した制御識別子５０５を指定して、ＵＳＢ制御ライブラリ４０５の各種ＡＰＩ（ｒｅａｄ／ｗｒｉｔｅ／ｉｏｃｔｌ／ｃｌｏｓｅ）を呼び出す。なお、ＵＳＢデバイスの制御は、排他的になっているため、既に他のアプリケーション４１３がオープンしているＵＳＢデバイスは他のアプリケーション４１３からオープンできないようになっている。
【００３６】
図６（ａ）及び（ｂ）は、ディスプレイ２１０に表示されるアプリケーション４１３の画面の例である。図６（ａ）は、ＩＣカード認証アプリ４０３の画面の例である。画像形成装置１の電源を入れると、最初に、図６（ａ）の認証アプリ４０３の画面が表示される。ユーザは、認証を行った後でないと、画像形成装置１の機能が利用できないようになっている。この例では、認証アプリ４０３は、ＵＳＢ制御ライブラリ４０５を利用してＩＣカードリーダ２を制御し、カード情報を読み取り、認証処理を行う。認証が成功すると、画像形成装置１で利用可能なアプリケーション４１３の一覧画面が表示される。アプリケーション一覧画面の中から利用したいアプリケーションを選択すると、対応するアプリケーションの操作画面が表示され、ユーザは画像形成装置１の各種機能を利用できる。
【００３７】
図６（ｂ）は、メディアプリントアプリの画面例である。メディアプリントアプリは、ＵＳＢ制御ライブラリ４０５を利用して、ＵＳＢメモリ３からデータを読み込んで、印刷を行うアプリケーションである。ファイルリスト６０１は、ＵＳＢメモリ３に格納されている印刷可能なファイルの一覧を表示する領域である。このリストの中から、ユーザが印刷したい文書を選択し、プリントボタン６０２を押下すると、選択された文書が印刷される。ユーザは、所望の機能を利用し終わると、入力部２１２に存在する認証ボタンを押下することで、ログアウトできる。ログアウトすると、再び、図６（ａ）の画面が表示され、認証待ち（ログイン待ち）状態になり、本体機能を利用できない状態になる。
【００３８】
図７は、アプリケーション４１３からＵＳＢデバイスへの要求を受けた時のＵＳＢ制御ライブラリ４０５の処理の流れを示すフローチャートである。このフローチャートの処理は、全て画像形成装置１のＣＰＵ２０１がＵＳＢ制御ライブラリ４０５を用いて実行する処理である。
【００３９】
ステップＳ７０１では、ＣＰＵ２０１は、アプリケーション４１３からＵＳＢデバイスへの要求を受けると、ＵＳＢ制御ライブラリ４０５を用いて、受信した要求をＵＳＢ制御モジュール４０９に送信する。要求の種類としては、ｏｐｅｎ／ｒｅａｄ／ｗｒｉｔｅ／ｉｏｃｔｌ／ｃｌｏｓｅなどがある。ＣＰＵ２０１は、ＵＳＢ制御ライブラリ４０５を用いて、ＵＳＢ制御モジュール４０９に要求を送信する際に、アプリケーション４１３から受け取った制御識別子５０５も一緒に送信する。ＣＰＵ２０１は、ＵＳＢ制御モジュール４０９を用いて、ＵＳＢホストＩ／Ｆを介してＵＳＢデバイスに要求を送信する。
【００４０】
次に、ステップＳ７０２では、ＣＰＵ２０１は、ＵＳＢ制御ライブラリ４０５を用いて、ＵＳＢ制御モジュール４０９から要求に対する処理結果を受信する。なお、ＣＰＵ２０１は、ＵＳＢ制御モジュール４０９を用いて、要求に対する処理結果をＵＳＢホストＩ／Ｆを介してＵＳＢデバイスから受信し、その処理結果をＵＳＢ制御ライブラリ４０５に送信する。
【００４１】
次に、ステップＳ７０３では、ＣＰＵ２０１は、ＵＳＢ制御ライブラリ４０５を用いて、ステップＳ７０２にて受信した処理結果が所定のエラーであったか否かを判定する。例えば、所定のエラーは、ＥＳＨＵＴ（通信相手がシャットダウンされて送信できない）であるものとする。このエラーが返ってきた場合、画像形成装置１は、ＵＳＢデバイスと正常に通信ができない状態になっていると考えられる。ステップＳ７０３において、ＣＰＵ２０１は、所定のエラーであると判定した場合にはステップＳ７０４に処理を進め、所定のエラーでないと判定した場合にはステップＳ７０７に処理を進める。
【００４２】
ステップＳ７０４では、ＣＰＵ２０１は、ＵＳＢ制御ライブラリ４０５を用いて、所定のエラーの連続発生回数を記憶するためのカウンタをカウントアップする。次に、ステップＳ７０５では、ＣＰＵ２０１は、ＵＳＢ制御ライブラリ４０５を用いて、所定のエラーの発生回数が所定回数（閾値）に達したか否かを判定する。ＵＳＢデバイスは、障害がある場合、画像形成装置１からの要求に対してエラーを連続して返し続ける。ＣＰＵ２０１は、所定回数に達したと判定した場合にはステップＳ７０６に処理を進め、所定回数に達していないと判定した場合にはステップＳ７０８に処理を進める。すなわち、ＣＰＵ２０１は、エラー検出処理により、ＵＳＢホストＩ／Ｆを介して接続されているＵＳＢデバイスのエラーが連続して閾値以上の回数発生したことを検出した場合には、ステップＳ７０６に処理を進める。
【００４３】
ステップＳ７０６では、ＣＰＵ２０１は、ＵＳＢ制御ライブラリ４０５を用いて、ＵＳＢ制御モジュール４０９に対してＶＢＵＳリセット要求を送信する。この際に、ＣＰＵ２０１は、アプリケーション４１３から受信した制御識別子５０５も要求と一緒に送信する。ステップＳ７０６の処理の詳細は、図８を用いて後述する。次に、ステップＳ７０７では、ＣＰＵ２０１は、ＵＳＢ制御ライブラリ４０５を用いて、所定のエラーの連続発生回数を記憶するためのカウンタをクリアする。次に、ステップＳ７０８では、ＣＰＵ２０１は、ＵＳＢ制御ライブラリ４０５を用いて、ステップＳ７０２で受信した処理結果をアプリケーション４１３に返し、処理を終了する。
【００４４】
以上説明したように、ＣＰＵ２０１は、所定のエラーが発生した場合に直ちにリセット要求を行わずに、エラーの連続発生を検知した時にのみリセット要求を行うことで、アプリケーション４１３やその他の復旧処理による復旧が行える余地を残している。
【００４５】
図８は、ＵＳＢ制御ライブラリ４０５からＶＢＵＳリセット要求を受けた時のＵＳＢ制御モジュール４０９の処理の流れを示すフローチャートであり、図７のステップＳ７０６の処理の詳細を示す。図８の処理は、全て画像形成装置１のＣＰＵ２０１がＵＳＢ制御モジュール４０９を用いて実行する処理である。
【００４６】
ステップＳ８０１では、ＣＰＵ２０１は、ＵＳＢ制御モジュール４０９がＵＳＢ制御ライブラリ４０５からＶＢＵＳリセット要求を受けると、ＵＳＢ制御モジュール４０９を用いて、ＶＢＵＳリセット要求の対象のＵＳＢホストＩ／Ｆを特定する。具体的には、ＣＰＵ２０１は、ＵＳＢ制御ライブラリ４０５から渡された制御識別子５０５を基に、図５で示した管理テーブルから対象となるＵＳＢホストＩ／Ｆを特定する。管理テーブルは、図５に示すように、複数のＵＳＢホストＩ／Ｆと複数のＵＳＢホストＩ／Ｆにそれぞれ接続されているＵＳＢデバイスとの対応関係を示す。
【００４７】
次に、ステップＳ８０２では、ＣＰＵ２０１は、ＵＳＢ制御モジュール４０９を用いて、ＧＰＩＯ２１５に対して、ステップＳ８０１で特定したＵＳＢホストＩ／Ｆに対応するＶＢＵＳのオン／オフを制御するレジスタビットを「オフ」にするように設定する。すると、図３に示すＡＮＤ回路３０６又は３１４は、ＧＰＩＯ２１５から入力する信号レベルが「ローレベル」になる。これにより、ＵＳＢホストＩ／Ｆ２０８又は２２０からのＶＢＵＳ出力が「ハイレベル」であった場合でも、ＵＳＢデバイス２又は３に入力されるＶＢＵＳ３０２又は３０９が「ローレベル」になる。
【００４８】
次に、ステップＳ８０３では、ＣＰＵ２０１は、ＵＳＢ制御モジュール４０９を用いて、一定時間（例えば５秒間）待機し、一定時間経過後（ステップＳ８０３でＹｅｓ）、ステップＳ８０４に処理を進める。このステップＳ８０３の処理により、一定時間ＶＢＵＳ３０２又は３０９が「ローレベル」に保持される。
【００４９】
次に、ステップＳ８０４では、ＣＰＵ２０１は、ＵＳＢ制御モジュール４０９を用いて、ＧＰＩＯ２１５に対して、ステップＳ８０１で特定したＵＳＢホストＩ／Ｆに対応するＶＢＵＳのオン／オフを制御するレジスタビットを「オン」にするように設定する。このステップＳ８０４の処理により、図３で示したＡＮＤ回路３０６又は３１４は、ＧＰＩＯ２１５から入力する信号レベルが「ハイレベル」になる。これにより、ＵＳＢホストＩ／Ｆ２０８又は２２０からのＶＢＵＳ出力が「ハイレベル」であった場合、ＵＳＢデバイス２又は３に入力されるＶＢＵＳ３０２又は３０９が「ハイレベル」になる。
【００５０】
以上示したように、ＣＰＵ２０１は、図８では、複数のＵＳＢホストＩ／Ｆのうち、エラーが発生したＵＳＢデバイスが接続されているＵＳＢホストＩ／Ｆをリセットし、エラーが発生したＵＳＢデバイスが接続されていないＵＳＢホストＩ／Ｆをリセットしない。具体的には、ＣＰＵ２０１は、図８では、エラーが発生したＵＳＢデバイスが接続されているＵＳＢホストＩ／ＦのＶＢＵＳの電力供給を一定時間停止した後に電力供給を再開することにより、リセットを行う。なお、ＣＰＵ２０１は、図８では、エラーが発生したＵＳＢデバイスが接続されていないＵＳＢホストＩ／ＦのＶＢＵＳの電力供給を停止しない。ＵＳＢデバイス２又は３は、ＶＢＵＳ３０２又は３０９の電力が一定時間供給されないことで、ＵＳＢデバイス２又は３を抜き差ししたことと同様の効果を得ることができる。
【００５１】
図９（ａ）及び（ｂ）は、ＵＳＢデバイス２又は３の制御を行うアプリケーション４１３のＵＳＢ制御処理の流れを示すフローチャートである。図９（ａ）は、アプリケーション４１３がエラーリカバリ処理を実装していない場合のアプリケーション４１３の処理を示すフローチャートである。ステップＳ９０１では、ＣＰＵ２０１は、アプリケーション４１３を用いて、ＵＳＢ制御処理を行う。次に、ステップＳ９０２では、ＣＰＵ２０１は、アプリケーション４１３を用いて、アプリ管理部モジュール４０１からアプリケーション４１３の終了を指示されたか否かを判定する。ＣＰＵ２０１は、アプリケーション４１３の終了を指示されていないと判定した場合にはステップＳ９０１に処理を戻し、アプリケーション４１３の終了が指示されたと判定した場合には処理を終了する。
【００５２】
以上示したように、図９（ａ）では、ＣＰＵ２０１は、エラーが発生した場合にも、同じＵＳＢ制御処理を繰り返すことになるため、要求に対して同じエラーが返り続ける状態となる。よって、図７で説明した処理により、ＣＰＵ２０１が、ＵＳＢ制御ライブラリ４０５を用いて、所定のエラーの連続発生を検知し、ＶＢＵＳリセット要求を送信することで、自動復旧ができる。
【００５３】
図９（ｂ）は、アプリケーション４１３がエラーリカバリ処理を実装している場合のＵＳＢ制御処理の概要を示すフローチャートである。ステップＳ９１０では、ＣＰＵ２０１は、アプリケーション４１３を用いて、ＵＳＢ制御処理を行う。次に、ステップＳ９１１では、ＣＰＵ２０１は、アプリケーション４１３を用いて、ＵＳＢ制御処理にてエラーが発生したか否かを判定する。ＣＰＵ２０１は、エラーが発生したと判定した場合にはステップＳ９１２に処理を進め、エラーが発生していないと判定した場合にはステップＳ９１３に処理を進める。ステップＳ９１２では、ＣＰＵ２０１は、アプリケーション４１３を用いて、リカバリ処理を実行し、ステップＳ９１３に処理を進める。ステップＳ９１３では、ＣＰＵ２０１は、アプリケーション４１３を用いて、アプリ管理部モジュール４０１からアプリケーション４１３の終了を指示されたか否かを判定する。ＣＰＵ２０１は、アプリケーション４１３の終了を指示されていないと判定した場合にはステップＳ９１０に処理を戻し、アプリケーション４１３の終了が指示されたと判定した場合には処理を終了する。
【００５４】
以上示したように、図９（ｂ）では、ＣＰＵ２０１は、エラーが発生した場合に、エラーのリカバリ処理が行える状況であれば、アプリケーション４１３のリカバリ処理によって自動復旧ができる。アプリケーション４１３の想定外のエラーが発生し、ＣＰＵ２０１がエラー発生を検知できなかったり、リカバリ処理にてリカバリができなかったりした場合、エラーが発生し続けることになる。この場合、ＣＰＵ２０１は、図７で説明したＵＳＢ制御ライブラリ４０５の処理により、エラーの連続発生を検知し、ＶＢＵＳリセット要求を送信し、自動復旧される。
【００５５】
以上説明したように、ＣＰＵ２０１は、エラーが発生した場合、図９（ｂ）のアプリケーション４１３の処理でリカバリできる場合には、アプリケーション４１３の処理により自動復旧できる。そして、ＣＰＵ２０１は、アプリケーション４１３の処理でリカバリできない場合には、図７のＵＳＢ制御ライブラリ４０５の処理により、エラーの連続発生を検知し、ＶＢＵＳリセット要求を送信し、自動復旧される。また、ＣＰＵ２０１は、ＶＢＵＳリセットを行う際、エラーが発生したＵＳＢデバイスが接続されているＵＳＢホストＩ／Ｆのみをリセットするため、他のＵＳＢデバイスに影響を与えずに、自動復旧できる可能性が高くなる。
【００５６】
（第２の実施形態）
第１の実施形態では、ＣＰＵ２０１は、図７のＵＳＢ制御ライブラリ４０５の処理により、所定のエラーの連続発生を検知すると、すぐにＶＢＵＳリセット要求を送信する場合の例を説明した。第１の実施形態では、上記の検知後、すぐにＶＢＵＳリセット要求を送信するため、同じＵＳＢホストＩ／Ｆに接続された正常動作しているＵＳＢデバイスに影響を与える可能性がある。そこで、第２の実施形態では、ユーザが利用中の正常動作しているＵＳＢデバイスへ影響を与える可能性をより低く抑えることが可能な画像形成装置１を説明する。図１〜６及び図８〜９は、第１の実施形態と共通であるため、説明を省略する。
【００５７】
図１０は、アプリケーション４１３からＵＳＢの制御要求を受けた時のＵＳＢ制御ライブラリ４０５の処理の流れを示すフローチャートである。このフローチャートの処理は、全てＣＰＵ２０１がＵＳＢ制御ライブラリ４０５を用いて実行する処理である。
【００５８】
ステップＳ１００１では、ＣＰＵ２０１は、ＵＳＢ制御ライブラリ４０５がアプリケーション４１３からＵＳＢデバイスへの制御要求を受信すると、ＵＳＢ制御ライブラリ４０５を用いて、受信した要求をＵＳＢ制御モジュール４０９に送信する。次に、ステップＳ１００２では、ＣＰＵ２０１は、ＵＳＢ制御ライブラリ４０５を用いて、ＵＳＢ制御モジュール４０９から要求の処理結果を受信する。
【００５９】
次に、ステップＳ１００３では、ＣＰＵ２０１は、ＵＳＢ制御ライブラリ４０５を用いて、ステップＳ１００２にて受信した結果が所定のエラーであるか否かを判定する。ＣＰＵ２０１は、所定のエラーであると判定した場合にはステップＳ１００４に処理を進め、所定のエラーでないと判定した場合にはステップＳ１０１１に処理を進める。
【００６０】
ステップＳ１００４では、ＣＰＵ２０１は、ＵＳＢ制御ライブラリ４０５を用いて、所定のエラーの連続発生回数を記憶するためのカウンタをカウントアップする。次に、ステップＳ１００５では、ＣＰＵ２０１は、ＵＳＢ制御ライブラリ４０５を用いて、所定のエラーの発生回数が所定回数に達したか否かを判定する。ＣＰＵ２０１は、所定回数に達したと判定した場合にはステップＳ１００６に処理を進め、所定回数に達していないと判定した場合にはステップＳ１０１２に処理を進める。
【００６１】
ステップＳ１００６では、ＣＰＵ２０１は、ＵＳＢ制御ライブラリ４０５を用いて、ＵＳＢ制御モジュール４０９から処理対象のＵＳＢデバイスと同じＵＳＢホストＩ／Ｆに接続されているＵＳＢデバイス数を取得する。ここで、ＣＰＵ２０１は、ＵＳＢ制御モジュール４０９を用いて、図５で示した管理テーブルから接続されているＵＳＢデバイス数を判断してＵＳＢ制御ライブラリ４０５にそのＵＳＢデバイス数の情報を返す。
【００６２】
次に、ステップＳ１００７では、ＣＰＵ２０１は、ＵＳＢ制御ライブラリ４０５を用いて、接続されているＵＳＢデバイス数が２以上か（他にＵＳＢデバイスが接続されているか）否かを判定する。ＣＰＵ２０１は、接続されているＵＳＢデバイス数が２以上であると判定した場合にはステップＳ１００８に処理を進め、接続されているＵＳＢデバイス数が２以上でないと判定した場合はステップＳ１００９に処理を進める。ＣＰＵ２０１は、エラーが発生したＵＳＢデバイスが接続されているＵＳＢホストＩ／Ｆに複数のＵＳＢデバイスが接続されていると判定した場合には、ステップＳ１００８に処理を進める。
【００６３】
ステップＳ１００８では、ＣＰＵ２０１は、ＵＳＢ制御ライブラリ４０５を用いて、ユーザがログイン中であるか否かの情報を認証アプリ４０１から取得し、ユーザがログイン中であるか否かを判定する。ＣＰＵ２０１は、ユーザがログイン中でないと判定した場合にはステップＳ１００９に処理を進め、ユーザがログイン中であると判定した場合にはステップＳ１０１０に処理を進める。
【００６４】
ステップＳ１００９では、ＣＰＵ２０１は、ＵＳＢ制御ライブラリ４０５を用いて、ＵＳＢ制御モジュール４０９に対してＶＢＵＳリセット要求を送信し、ステップＳ１０１１に処理を進める。このステップＳ１００９の処理の詳細は、図８と同様である。
【００６５】
ステップＳ１０１０では、ＣＰＵ２０１は、ＵＳＢ制御ライブラリ４０５を用いて、リセットフラグを「オン」に設定し、エラーが発生したＵＳＢデバイスの情報（制御識別子５０５）を記憶し、ステップＳ１０１１に進む。ここで、ＣＰＵ２０１は、ＵＳＢ制御ライブラリ４０５を用いて、ＲＡＭ２０４上に静的に保存領域を確保し、その保存領域にリセットフラグ及びＵＳＢデバイスの情報を記憶する。
【００６６】
ステップＳ１０１１では、ＣＰＵ２０１は、ＵＳＢ制御ライブラリ４０５を用いて、所定のエラーの連続発生回数を示すカウンタをクリアし、ステップＳ１０１２に処理を進める。ステップＳ１０１２では、ＣＰＵ２０１は、ＵＳＢ制御ライブラリ４０５を用いて、ステップＳ１００２で取得した処理結果をアプリケーション４１３に返し、処理を終了する。
【００６７】
図１１は、ユーザのログアウトを検出した際のＵＳＢ制御モジュール４０９の処理の流れを示すフローチャートである。このフローチャートの処理は、全てＣＰＵ２０１がＵＳＢ制御モジュール４０９を用いて実行する処理である。
【００６８】
ステップＳ１１０１では、ＣＰＵ２０１は、ＵＳＢ制御モジュール４０９を用いて、認証アプリ４０３からログアウト通知を受けてログアウトを検出すると、リセットフラグが「オン」であるか否かを判定する。ＣＰＵ２０１は、リセットフラグが「オン」でないと判定した場合には処理を終了し、リセットフラグが「オン」であると判定した場合にはステップＳ１１０２に処理を進める。
【００６９】
ステップＳ１１０２では、ＣＰＵ２０１は、ＵＳＢ制御モジュール４０９を用いて、ステップＳ１０１０で記憶していたエラー発生のＵＳＢデバイスの情報を取得する。次に、ステップＳ１１０３では、ＣＰＵ２０１は、ＵＳＢ制御モジュール４０９を用いて、リセットフラグを「オフ」にする。次に、ステップＳ１１０４では、ＣＰＵ２０１は、ＵＳＢ制御モジュール４０９を用いて、ステップＳ１１０２で取得したＵＳＢデバイス情報に基づいて、ＵＳＢ制御モジュール４０９にＶＢＵＳリセット要求を送信し、処理を終了する。このステップＳ１１０４の処理の詳細は、図８と同様である。
【００７０】
以上のように、ＣＰＵ２０１は、エラーが発生したＵＳＢデバイスが接続されているＵＳＢホストＩ／Ｆに他のＵＳＢデバイスが接続されており、かつユーザが画像形成装置１にログイン中である場合には、ユーザのログアウト後に、ＶＢＵＳをリセットする。これにより、正常動作しているＵＳＢデバイスをユーザが使用中にリセットされることを防ぐことができるため、ユーザの利便性低下を防ぐことができる。
【００７１】
第１及び第２の実施形態では、説明を簡単にするため、ＥＳＨＵＴ（通信相手がシャットダウンされて送信できない）が連続発生した場合のみＶＢＵＳのリセットを行うようにしていた。しかしながら、第１及び第２の実施形態は、これに限られるものではない。エラーの種類は、ＥＰＲＯＴＯ（プロトコルエラー）やＥＰＩＰＥ（パイプが壊れている）など他のエラーを対象としてもよい。また、ＣＰＵ２０１は、これらの複数のエラーが連続発生したことを検出してＶＢＵＳリセット要求を送信するようにしてもよいし、複数のエラーが所定の順番で発生したことを検出してＶＢＵＳリセット要求を送信するようにしてもよい。
【００７２】
第１及び第２の実施形態によれば、ＵＳＢデバイスのエラーが発生した場合でも、画像形成装置１に接続されている他のＵＳＢデバイスの動作に与える影響を最小限に抑えつつ、エラーが発生したＵＳＢデバイスを自動復旧させることができる。
【００７３】
（その他の実施形態）
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読み出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【００７４】
なお、上記実施形態は、何れも本発明を実施するにあたっての具体化の例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。すなわち、本発明はその技術思想、又はその主要な特徴から逸脱することなく、様々な形で実施することができる。
【符号の説明】
【００７５】
１  画像形成装置、２０７  ＵＳＢホストコントローラ、２０８  ＵＳＢホストＩ／Ｆ、４０３  認証アプリ、４０５  ＵＳＢ制御ライブラリ、４０９  ＵＳＢ制御モジュール
【図１】
2019101972.tif 000003
【図２】
2019101972.tif 000004
【図３】
2019101972.tif 000005
【図４】
2019101972.tif 000006
【図５】
2019101972.tif 000007
【図６】
2019101972.tif 000008
【図７】
2019101972.tif 000009
【図８】
2019101972.tif 000010
【図９】
2019101972.tif 000011
【図１０】
2019101972.tif 000012
【図１１】
2019101972.tif 000013