(57)【要約】【課題】従来の情報処理装置においては、操作部ユニットに故障が発生した場合、操作部ユニットを構成するタッチパネルと基板ユニットなどのいずれの故障であるかを区別して特定していなかった。このため、操作部ユニットに故障が発生した場合、操作部ユニット全体を交換する必要があったため、運用コストが高くなってしまうという問題があった。【解決手段】操作部ユニットの異常を検知した場合、操作部ユニット内の故障箇所を区別して特定することにより、情報処理装置のダウンタイムを軽減しつつ、運用コストを削減することが可能となる。【選択図】図２
2020066183.tif 000002
【特許請求の範囲】
【請求項１】
タッチパネルと、
前記タッチパネルにおいて入力された情報を受信するコントローラが搭載される基板ユニットと、を有する情報処理装置であって、
前記タッチパネルの故障と前記基板ユニットの故障とを区別して、故障の有無の判断を行う判断手段と、を有する
ことを特徴とする情報処理装置。
【請求項２】
前記判断手段は、前記基板ユニットに搭載され、前記コントローラと制御信号を介して接続された信号処理回路である
ことを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記判断手段は、前記コントローラの動作に基づいて、前記判断を行う
ことを特徴とする請求項１又は２に記載の情報処理装置。
【請求項４】
前記判断手段は、前記コントローラの動作が正常でない場合、基板ユニットの故障であるとの判断を行う
ことを特徴とする請求項３に記載の情報処理装置。
【請求項５】
前記判断手段は、前記タッチパネルへの入力状態の変化が検知されたか否かに基づいて、前記判断を行う
ことを特徴とする請求項１乃至４のいずれか１項に記載の情報処理装置。
【請求項６】
前記タッチパネルへの入力状態の変化が検知されなかった場合、前記判断手段は、前記タッチパネルの故障であるとの判断を行う
ことを特徴とする請求項５に記載の情報処理装置。
【請求項７】
前記タッチパネルへの入力状態の変化が検知された場合、前記判断手段は、故障が誤検知であるとの判断を行う
ことを特徴とする請求項５又は６に記載の情報処理装置。
【請求項８】
前記タッチパネルへの入力状態の変化の有無を検知するために、前記タッチパネルへの操作をユーザに指示をする指示手段を有する
ことを特徴とする請求項１乃至７のいずれか１項に記載の情報処理装置。
【請求項９】
前記指示が、前記タッチパネルに画面を表示することにより行われる
ことを特徴とする請求項８に記載の情報処理装置。
【請求項１０】
前記タッチパネルへの入力が検知されなかった場合、前記画面においてユーザにタッチをするように指示する
ことを特徴とする請求項９に記載の情報処理装置。
【請求項１１】
９
前記タッチパネルへの入力が検知された場合、前記画面においてユーザにタッチを離すように指示する
ことを特徴とする請求項９又は１０に記載の情報処理装置。
【請求項１２】
前記タッチパネルへの入力が検知された場合、前記画面においてユーザにタッチを指示する領域を表示する
ことを特徴とする請求項９又は１０に記載の情報処理装置。
【請求項１３】
前記領域は、誤検知されている場所とタッチされた場所との二点入力によっては検知できない領域の内に設定される
ことを特徴とする請求項１２に記載の情報処理装置。
【請求項１４】
前記判断手段は、前記タッチパネルに表示される前記画面においてタッチされた場所に基づいて、前記判断を行う
ことを特徴とする請求項９乃至１３のいずれか１項に記載の情報処理装置。
【請求項１５】
前記指示が、音の出力により行われる
ことを特徴とする請求項８に記載の情報処理装置。
【請求項１６】
前記指示が、音声により行われる
ことを特徴とする請求項１５に記載の情報処理装置。
【請求項１７】
前記指示が、あらかじめ設定された回数の音の出力により行われる
ことを特徴とする請求項１５に記載の情報処理装置。
【請求項１８】
前記判断手段は、ユーザの操作を受け付けたトリガーとして前記判断を行う
ことを特徴とする請求項１乃至１７のいずれか１項に記載の情報処理装置。
【請求項１９】
タッチパネルと、
前記タッチパネルにおいて入力された情報を受信するコントローラが搭載される基板ユニットと、を有する情報処理装置の制御方法であって、
前記タッチパネルの故障と前記基板ユニットの故障とを区別して、故障の有無の判断を行う判断工程を有する
ことを特徴とする情報処理装置の制御方法。
【請求項２０】
請求項１９に記載の情報処理装置の制御方法をコンピュータにより実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、情報処理装置の制御方法、及びプログラムに関するものであり、特に、操作部ユニット内の故障箇所を特定する手段を有する情報処理装置に関するものである。
【背景技術】
【０００２】
情報処理装置には、複数のユニットから構成され、各ユニットが複数の基板や電子部品から構成されるものがある。このような情報処理装置において、情報処理装置を構成するいずれかのユニットに異常が発生すると、情報処理装置の動作に不具合が発生し、ユーザの作業ができなくなったり、ユーザの作業が限定されてしまったりする。そして、情報処理装置が復旧するまでの間ダウンタイムが発生する。そのため、できるだけ早く、異常が発生したユニットを特定して、情報処理装置を復旧することが求められる。
【０００３】
また、情報処理装置には、専用の操作部ユニットを有するものがある。操作部ユニットは、ユーザの入力を検知するタッチパネルやテンキー、ＬＣＤ（Liquid Crystal Display）等の表示部、これらを制御し情報処理装置の制御部と通信するＣＰＵを搭載した制御基板等から構成される。このような情報処理装置において、タッチパネル自体の故障やＬＣＤの故障、また操作部を制御する制御基板の故障が発生すると、タッチパネルが反応しなかったり、表示部に何も表示されなかったり、といった不具合が発生する場合がある。
【０００４】
そこで、特許文献１には、操作部ユニットの異常を検知した場合、他の情報処理装置の操作部ユニットからネットワークを介してユーザに装置を操作させる方法が提案されている。また、特許文献２には、タッチパネルの故障が発生した場合には、ユーザの入力操作ができなくなってしまうため、臨時入力モードに動作を切り替えて、タッチパネル以外の操作キーによって入力を可能にするものが提案されている。
このように、従来においては、操作部の故障が発生した場合には、代替の入力手段を用いることにより、操作部ユニットが復旧するまでの間、一時的に情報処理装置の使用を可能にしていた。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００９−７３０４５公報
【特許文献２】特許第５６５３１５２号
【発明の概要】
【発明が解決しようとする課題】
【０００６】
上記のとおり、特許文献１及び２の情報処理装置においては、操作部ユニットに故障が発生した場合、代替の入力手段を用いることにより、情報処理装置の継続した使用を可能としている。しかしながら、これらの情報処理装置では、操作部ユニットを構成するタッチパネルと基板ユニットのいずれの故障であるかを区別して特定していない。
このため、操作部ユニットのどこかに故障が発生すると、操作部ユニット全体を交換する必要があった。さらに、操作部ユニットはユーザの入力に応じて動作するため、ユーザによる意図的な操作なのか、故障による入力不良なのかを正確に判定することが困難であり、故障の原因を誤判定する可能性があった。
【課題を解決するための手段】
【０００７】
本発明は、タッチパネルと、前記タッチパネルにおいて入力された情報を受信するコントローラが搭載される基板ユニットと、を有する情報処理装置であって、前記タッチパネルの故障と前記基板ユニットの故障とを区別して、故障の有無の判断を行う判断手段と、を有することを特徴とする。
【発明の効果】
【０００８】
本発明によれば、操作部ユニットに異常が発生した場合、操作部ユニット内の故障箇所を特定することが可能となるため、交換する部品を最小限にとどめることができる。これにより、操作部ユニット全体を交換する必要がなくなるため、運用コストを削減することができる。
【図面の簡単な説明】
【０００９】
【図１】情報処理装置の内部のハードウェア構成のシステムブロックである（実施例１）。
【図２】故障診断モードにおいて情報処理装置により実行される処理のフローチャートである（実施例１）。
【図３】ユーザへ操作を促す診断用画面の表示例である。
【図４】診断用画面における入力領域を決定する手法を説明するための図である。
【図５】故障診断モードにおいて画像形成装置により実行される処理のフローチャートである（実施例２）。
【発明を実施するための形態】
【００１０】
以下、図面を参照して本発明の実施の形態を説明する。
＜情報処理装置の全体構成＞
図１は、本発明の各実施例における、情報処理装置２００内部のハードウェア構成のシステムブロック図を示す。
情報処理装置２００は、制御部２０１と操作部ユニット２１６とを備える。
なお、以下の実施例では、図１のシステムブロック図を用いて、専用の操作部ユニット２１６を備える情報処理装置２００について詳細な説明を行うが、本発明はこれらに限定されるものではない。専用の操作部ユニットを備える情報処理装置として、例えば、自動券売機やＡＴＭ、画像形成装置などの様々な装置がある。ただし、以下では、これらの装置に関する詳細な説明については省略する。
【００１１】
＜制御部の構成＞
制御部２０１に搭載されるメインＣＰＵ２０２は、情報処理装置２００全体を制御するソフトウェアプログラムを実行する。
ＲＡＭ２０４は、メインＣＰＵ２０２に接続され、情報処理装置２００を制御する際の一時的なデータの格納などに使用される。
ＢｏｏｔＲＯＭ２０３は、メインＣＰＵ２０２に接続され、情報処理装置２００の起動プログラムや各種設定値等が格納されている。
【００１２】
メインＣＰＵ２０２には、情報処理装置２００のストレージとして、ＨＤＤ２０５が搭載される。ＨＤＤ２０５は、メインＣＰＵ２０２とシリアルＡＴＡ（以下、ＳＡＴＡという）などで接続され、メインＣＰＵ２０２によってデータの読み書きが実行される。
情報処理装置２００は、ＬＡＮ２１５とＬＡＮＣ（ＬＡＮコントローラ）２１９を経由して接続される。ＬＡＮＣ２１９は、メインＣＰＵ２０２と接続され、メインＣＰＵ２０２がＬＡＮＣ２１９を制御して、情報処理装置２００のネットワーク制御を行う。
【００１３】
＜操作部ユニットの構成＞
操作部ユニット２１６は、操作部基板ユニット２１４、タッチパネル２１１、ＬＣＤユニット２１２、スピーカー２１３、故障診断用プッシュＳＷ２１７を備える。
操作部基板ユニット２１４には、ＵＩ_ＣＰＵ２０８、タッチパネルコントローラ２１０、画像出力ＩＣ２０９などが搭載される。
タッチパネルコントローラ２１０は、タッチパネル２１１から出力されるユーザ入力信号２００１を受信するコントローラ（制御回路）である。また、ＵＩ_ＣＰＵ２０８は、後述する故障箇所特定処理を含む各種処理を行う信号処理回路である。
【００１４】
タッチパネルコントローラ２１０とＵＩ_ＣＰＵ２０８とは、割り込み信号２００２と制御通信信号２００２を介して互いに接続される。タッチパネル２１１において入力された座標やタッチ数（二点タッチなど）などの情報は、ユーザ入力信号２００１として、タッチパネルコントローラ２１０に送信される。
さらに、タッチパネルコントローラ２１０は、タッチパネル２１１から受信したユーザ入力信号２００１を、割り込み信号２００２と制御通信信号２００３を用いて、ＵＩ_ＣＰＵ２０８へ送信する。
【００１５】
ユーザによるタッチパネル２１１における入力の変化があると、タッチパネル２１１は、タッチパネルコントローラ２１０に対して、ユーザ入力信号２００１を出力する。そして、タッチパネルコントローラ２１０は、タッチパネル２１１における入力を、割り込み信号２００２としてＵＩ_ＣＰＵ２０８へ送信する。
このとき、タッチパネルコントローラ２１０は、入力がない場合にはＨｉｇｈ、入力がある場合にはＬｏｗという形で、ＵＩ_ＣＰＵ２０８へユーザ入力の状態を伝える。この時の論理は、入力状態が識別できるものであればどちらでもよいが、以下では、入力がある場合にはＬｏｗ、ない場合にはＨｉｇｈとして説明する。
【００１６】
なお、タッチパネル２１１は、ユーザの入力（タッチ）を、一点入力（一点タッチ）または二点入力（二点タッチ）として認識する。一点タッチを検知した場合、タッチパネル２１１は、ユーザがタッチした点の座標を入力座標として、タッチパネルコントローラ２１０にユーザ入力信号２００１を送信する。また、二点タッチを検知した場合、タッチパネル２１１は、ユーザがタッチした２点の中点となる座標を入力座標として、タッチパネルコントローラ２１０にユーザ入力信号２００１を送信する。
【００１７】
メインＣＰＵ２０２は、画像通信制御信号２００９と画像データ信号２００８を介して、操作部基板ユニット２１４の画像出力ＩＣ２０９と接続される。メインＣＰＵ２０２は画像出力ＩＣ２０９を経由して画像出力信号２００５をＬＣＤユニット２１２に送信し、ＬＣＤユニット２１２は受信した画像出力信号２００５に基づいて画面を表示する。ＬＣＤ２１２の表示の明るさなどの設定は、ＵＩ_ＣＰＵ２０８から制御通信信号２００６を用いて画像出力ＩＣ２０９に設定される。
なお、図１では、タッチパネル２１１とＬＣＤユニット２１２とは別のブロックとして図示されているが、以下の実施例のように、両者を同一の部材（タッチパネル機能を有するＬＣＤユニット）で構成してもよい。
【００１８】
＜スピーカー＞
ＵＩ_ＣＰＵ２０８は、ユーザから受け付けたユーザ入力信号２００１をプッシュ音や操作指示などの音出力信号２００４に変換し、音出力信号２００４に基づいてスピーカー２１３から音出力を行う。
なお、以下の実施例においては、スピーカー２１３の音声出力の制御は、ＵＩ_ＣＰＵ２０８が行う。ただし、ＵＩ_ＣＰＵ２０８に限られず、メインＣＰＵ２０２がスピーカー２１３の音声出力の制御を実施してもよい。
【００１９】
＜故障診断用プッシュＳＷ＞
故障診断用プッシュＳＷ２１７は、ＵＩ＿ＣＰＵ２０８に接続されるスイッチである。ユーザやサービスマンが故障診断用プッシュＳＷ２１７を押下したことを受け付けると、故障診断用プッシュＳＷ２１７は、ユーザ入力信号２００７をＵＩ＿ＣＰＵ２０８へ通知する。ＵＩ_ＣＰＵ２０８は、ユーザ入力信号２００７を受信すると、情報処理装置２００を故障診断モードへ移行させる。
【００２０】
なお、以下の実施例では、故障診断用のプッシュＳＷ２１７を備える情報処理装置２００について説明するが、故障診断モードへ移行するためには診断用のプッシュＳＷ２１７を備えなくてもよい。例えば、テンキーや、パソコンを用いてＦ５ボタンなどの特定のキーを押した状態で起動させるなどが考えられるが、ここでは詳細を記載しない。その他、ＳＷやキーを用いないユーザ操作から、ＵＩ_ＣＰＵ２０８がタッチパネル２１１の故障を予測して故障診断モードへ移行する方法や、ＬＡＮ２１５を経由して、メインＣＰＵ２０２からの指示で故障診断モードへ移行させる方法なども考えられる。
【００２１】
実施例１では、故障診断用のプッシュＳＷ２１７が押下されると、ＵＩ_ＣＰＵ２０８は情報処理装置２００を故障診断モードへ移行させ、故障の有無及び故障の箇所を判断を行う故障個所特定処理を行う。故障診断モードへ移行すると、ＵＩ_ＣＰＵ２０８はタッチパネル２１１の画面表示を切り替える。そして、ＵＩ_ＣＰＵ２０８は、ユーザに操作を促し、入力に応じてタッチパネル２１１が故障しているか、タッチパネルコントローラ２１０が故障しているか、誤検知である（故障なし）かを、判断する。
【００２２】
また、実施例２では、故障診断用のプッシュＳＷ２１７が押下されると、ＵＩ_ＣＰＵ２０８は情報処理装置２００を故障診断モードへ移行させ、故障の有無及び故障の箇所を判断を行う故障個所特定処理を行う。故障診断モードへ移行すると、ＵＩ_ＣＰＵ２０８はスピーカー２１３を制御して音声出力を実行する。そして、ＵＩ_ＣＰＵ２０８は、ユーザに操作を促し、入力に応じてタッチパネル２１１が故障しているか、タッチパネルコントローラ２１０が故障しているか、誤検知である（故障なし）かを、判断する。
【実施例１】
【００２３】
次に、実施例１について説明する。
実施例１では、故障診断モードへ移行すると、ＵＩ_ＣＰＵ２０８は、タッチパネル２１１の画面表示を切り替える。そして、タッチパネル２１１におけるユーザの操作から、タッチパネル２１１の故障、タッチパネルコントローラ２１０の故障、または、誤検知（故障なし）のいずれであるかを判断し、故障の有無及び故障箇所の特定を行う。
図２を用いて、故障診断モードにおける具体的な制御フローについて詳細に説明する。本フローチャートは、情報処理装置１００に電源が入れられることにより、開始する。
【００２４】
Ｓ１０１において、ＵＩ_ＣＰＵ２０８は、故障診断モードに移行する指示を受信したか否かを判定する。具体的には、ＵＩ_ＣＰＵ２０８が、ユーザによる故障診断用プッシュＳＷ２１７の入力を受信したか否かにより、この判定を行う。
ＵＩ_ＣＰＵ２０８が故障診断モードへの移行指示を受信していない場合、Ｓ１０１へ戻り、ＵＩ_ＣＰＵ２０８が故障診断モードへの移行指示を受信するまで繰り返す。
【００２５】
故障診断モードへの移行指示を受信すると、Ｓ１０２において、ＵＩ_ＣＰＵ２０８は、移行指示をトリガーとして故障箇所特定処理を開始する。
まず、Ｓ１０３において、ＵＩ_ＣＰＵ２０８は、タッチパネルコントローラＩＣ２１０が正常に動作しているか否かを、通信状態やコマンドの送受信に基づいて判定を行う。
例えば、ＵＩ_ＣＰＵ２０８は、テストパケットを送信し、タッチパネルコントローラＩＣ２１０からの応答があれば、通信が正常であると判定する。
一方、タッチパネルコントローラＩＣ２１０からの応答がなければ、ＵＩ_ＣＰＵ２０８は、タッチパネルコントローラＩＣ２１０が正常に動作していないと判定する。
【００２６】
タッチパネルコントローラＩＣ２１０が正常に動作していない場合（Ｓ１０３：ＮＯ）、Ｓ１０４において、ＵＩ_ＣＰＵ２０８は操作部基板ユニット２１４の故障であると判定する。そして、ＵＩ_ＣＰＵ２０８は、操作部基板ユニット２１４の故障であることを、メインＣＰＵ２０２に通知し、また、タッチパネル２１１へ表示する。
なお、故障を通知する方法としては、タッチパネル２１１に表示する以外にも、スピーカー２１３を経由して音声出力を行ってもよいし、ＬＡＮ２１５を経由して管理者またはサービスマンなどに通知してもよい。
【００２７】
タッチパネルコントローラＩＣ２１０が正常に動作している場合（Ｓ１０３：ＹＥＳ）、Ｓ１０５において、ＵＩ_ＣＰＵ２０８は、タッチパネル２１１のタッチ検知がＨｉｇｈであるか否かを判定する。この判定は、ユーザの入力があるかないかの判定に相当する。本実施例においては、ユーザによる入力がある場合、タッチパネル２１１のタッチ検知がＬｏｗになるものとして説明する。ただし、ユーザによる入力の有無を認識できるものであれば、検知方法の論理は問わない。
【００２８】
Ｓ１０５においてＨｉｇｈである（タッチが検知されない）と判定された場合（Ｓ１０５：ＹＥＳ）、Ｓ１０６へ移行する。一方、Ｌｏｗである（タッチが検知された）と判定された場合（Ｓ１０５：ＮＯ）、Ｓ１１０へ移行する。
【００２９】
Ｓ１０５においてＨｉｇｈであると判定された場合（Ｓ１０５：ＹＥＳ）、Ｓ１０６において、ＵＩ_ＣＰＵ２０８は、画面入力を診断用画面１に切り替えるようにメインＣＰＵ２０２へ指示を行う。そして、タッチパネル２１１の画面表示を切り替える。
【００３０】
ここで、図３（Ａ）に、診断用画面１の一例を示す。
図３（Ａ）に示すように、ＵＩ_ＣＰＵ２０８は、画面の入力をユーザに促すために、診断用画面１として、「画面をタッチして下さい」というメッセージを表示させる。画面への入力に指示する方法であれば、違う画面表示でももちろんよい。
【００３１】
診断用画面１の表示を行うと、Ｓ１０７において、ＵＩ_ＣＰＵ２０８は、タッチ検知がＨｉｇｈからＬｏｗに変化したか否かを判定する。ここで、ＨｉｇｈからＬｏｗへの変化は、タッチパネル２１１がタッチされていたことを検知したことを意味する。
タッチ検知がＨｉｇｈからＬｏｗに変化した場合（Ｓ１０７：ＹＥＳ）、Ｓ１１４へ移行し、ＵＩ_ＣＰＵ２０８は異常なしと判定し、通常動作へ戻る。
一方、タッチ検知がＨｉｇｈのままでＬｏｗに変化しない場合（Ｓ１０７：ＮＯ）、Ｓ１０８に移行し、ＵＩ_ＣＰＵ２０８は、診断用画面１を表示してから一定時間が経過しているか否かを判定する。
【００３２】
Ｓ１０８において一定時間経過していればＳ１０９へ移行し、経過していなければＳ１０６へ戻る。ここで、タッチ検知がＨｉｇｈのままで一定時間が経過した場合（Ｓ１０８：ＹＥＳ）、タッチパネル２１１に診断用画面を表示させても変化がないのは、タッチパネル２１１が故障したために、入力が受信できないためであると考えられる。
そこで、Ｓ１０９において、ＵＩ_ＣＰＵ２０８は、タッチパネル２１１の故障と判定し、タッチパネル２１１の故障であることをタッチパネル２１１へ表示する。もちろん、通知方法は表示に限定する必要はない。
【００３３】
Ｓ１０５においてタッチパネル２１１のタッチ検知がＨｉｇｈではない（タッチが検知された）と判定されると（Ｓ１０５：ＮＯ）、Ｓ１１０へ移行する。そして、Ｓ１１０において、ＵＩ_ＣＰＵ２０８は、タッチ検知が継続しているのが、ユーザが実際にタッチをしているためであるのか、故障が発生したためであるのかを判定するために、診断用画面２を表示する。具体的には、ＵＩ_ＣＰＵ２０８は、診断用画面２として、画面への入力をユーザに促す表示に切り替えるようにメインＣＰＵ２０２へ指示を行い、タッチパネル２１１の画面表示を切り替える。
【００３４】
ここで、図３（Ｂ）及び（Ｃ）に、診断用画面２の例を示す。
図３（Ｂ）は、タッチの検知状態を変化させるために、画面からタッチを離すように指示する画面表示の例である。
また、図３（Ｃ）は、画面を離すか、あるいは、ユーザが実際にタッチしたことを確認することができるように、指示領域３０１への入力を促すように指示する画面表示の例である。
以下では、図３（Ｃ）の画面表示の例を用いて説明するが、図３（Ｂ）の画面表示の例を用いて、タッチ検知の状態変化のみで判定してもよい。なお、この場合、図２のフローチャートにおいて、Ｓ１１２の処理は省略される。
【００３５】
ここで、図４を用いて、図３（Ｃ）に示した指示領域３０１を設定する方法について、説明する。
ここでは、図４（Ａ）に示されるように、現在、ＵＩ_ＣＰＵ２０８が、タッチパネル２１１の左下がタッチされていると検知している状態を例にして説明する。この状態でＵＩ_ＣＰＵ２０８がタッチを検知している場所を、座標Ａとする。ただし、座標Ａの検知は、ユーザによる実際のタッチを検知している以外に、タッチパネル２１１に故障が発生しているための誤検知である可能性がある。
【００３６】
この時、ユーザがタッチパネル２１１上の座標Ｂをタッチしたとする。
タッチパネル２１１に故障が発生しているために座標Ａを誤検知している場合、座標Ａのタッチの誤検知は継続するため、ユーザによる座標Ｂのタッチにより、ＵＩ_ＣＰＵ２０８は、座標Ａと座標Ｂの二点タッチとして認識する。上述のとおり、二点タッチの場合は、ユーザがタッチした２点の中点となる座標を入力座標として検知するため、ＵＩ_ＣＰＵ２０８は、座標Ａと座標Ｂの中点である座標Ｃを入力座標として検知する。
【００３７】
実際には、ユーザは、座標Ｂに限られず、タッチパネル２１１上の任意の場所をタッチすることができる。そのため、タッチパネル２１１の故障により座標Ａを誤検知している場合、ＵＩ_ＣＰＵ２０８が二点タッチの入力座標として検知することができる領域は、図４（Ｂ）の検知可能領域４０１で示される範囲内となる。
すなわち、ＵＩ_ＣＰＵ２０８が、入力座標として、図４（Ｂ）の検知不能領域４０２を検知した場合であれば、座標Ａの検知は継続していないことになるため、座標Ａの検知は、タッチパネル２１１の誤検知によるものではなかったこととなる。
【００３８】
そこで、ＵＩ_ＣＰＵ２０８は、図４（Ｂ）に示すように、検知不能領域４０２の内に、タッチをユーザに促す指示領域３０１を設定し、図３（Ｃ）に示されるような診断用画面２をタッチパネル２１１に表示する。
そして、指示領域３０１において入力座標を検知したか否かにより、ＵＩ_ＣＰＵ２０８は、タッチパネル２１１の故障の有無を判定する。
なお、上記では、ＵＩ_ＣＰＵ２０８が画面左下の座標Ａをタッチ検知している状況を例にして説明したが、タッチ検知の場所はこれに限られない。したがって、指示領域３０１は、ＵＩ_ＣＰＵ２０８がタッチ検知している座標に応じて設定されることになる。
【００３９】
ここで、図２のフローチャートに戻る。
Ｓ１１０において、ＵＩ_ＣＰＵ２０８が、図３（Ｃ）に示されるような診断用画面２をタッチパネル２１１に表示した後、Ｓ１１１に移行する。
【００４０】
Ｓ１１１において、ＵＩ_ＣＰＵ２０８は、タッチ検知がＬｏｗからＨｉｇｈに変化したか否かを判定する。ＬｏｗからＨｉｇｈへの変化は、ユーザがタッチパネル２１１へのタッチを離したことが検知されたことを意味する。
そこで、タッチ検知がＬｏｗからＨｉｇｈに変化した場合（Ｓ１１１：ＹＥＳ）、Ｓ１１４において、ＵＩ_ＣＰＵ２０８は、タッチパネル２１１に異常がないと判定し、通常動作へ戻る。
【００４１】
一方、タッチ検知がＬｏｗからＨｉｇｈに変化しない、すなわち、タッチパネル２１１へのタッチ検知を継続している場合（Ｓ１１１：ＮＯ）、Ｓ１１２において、ＵＩ_ＣＰＵ２０８は、入力座標が指示領域３０１の範囲内に移動したか否かを判定する。
指示領域３０１に入力座標が移動した場合（Ｓ１１２：ＹＥＳ）、Ｓ１１４へ移行し、ＵＩ_ＣＰＵ２０８は、タッチパネル２１１に異常がないと判定し、通常動作へ戻る。
一方、移動していない場合（Ｓ１１２：ＮＯ）、Ｓ１１３において、ＵＩ_ＣＰＵ２０８は、診断用画面２を表示させてから一定時間経過しているか否かを判定する。
【００４２】
一定時間がまだ経過していなければ（Ｓ１１３：ＮＯ）、Ｓ１１０へ戻る。
一定時間経過したら（Ｓ１１３：ＹＥＳ）、診断用画面２を表示させてもタッチ検知に変化がないのは、タッチパネル２１１が故障し、入力が受信できないためであると考えられる。
そこで、Ｓ１０９において、ＵＩ_ＣＰＵ２０８は、タッチパネル２１１の故障と判定し、タッチパネル２１１の故障であることをタッチパネル２１１へ表示する。
【００４３】
なお、ユーザに故障の有無や故障箇所を通知する方法は、ＬＣＤユニット２１２やタッチパネル２１１に表示する方法には限られない。例えば、スピーカーを用いて音声を出力することによりユーザに通知してもよい。
また、タッチパネル２１１の故障を判断する方法としては、時間経過によるものには限られない。例えば、故障診断モード中において、異常なしと判定されないまま情報処理装置２００の電源のＯＦＦ／ＯＮが実行された場合に、タッチへの入力ができない故障と判定してもよい。
【００４４】
以上のように、実施例１では、故障診断モードへの移行の指示が入力されると、ＵＩ_ＣＰＵ２０８は、画面表示を切り替え、ユーザに対してタッチパネルへの入力の変化を促す。そして、タッチパネルへの入力の変化を用いて、タッチパネル２１１の故障であるか、タッチパネルコントローラ２１０の故障であるかを、区別して故障箇所を判断する。
その結果、操作部ユニットに故障が発生した場合、故障部品を特定することができるため、交換する部品を最小限に抑えることができる。これにより、運用コストの削減を可能とし、また、情報処理装置のダウンタイムを減少させることも可能となる。
【実施例２】
【００４５】
次に、実施例２について説明する。
実施例１では、故障診断モードへ移行した場合、診断用画面を表示することにより、タッチパネル２１１への操作をするようにユーザに指示した。これに対して、実施例２では、故障診断モードへ移行すると、スピーカー２１３から音を出力することにより、タッチパネル２１１への操作をするようにユーザに指示するようにする。なお、ＵＩ_ＣＰＵ２０８が、ユーザ入力からタッチパネル２１１の故障、タッチパネルコントローラ２１０の故障、または、誤検知（故障なし）かを判定し、故障箇所を特定する点は、実施例１と同様である。
図５を用いて、実施例２における故障診断モードにおける具体的な制御フローについて詳細に説明する。本フローチャートは、情報処理装置１００に電源が入れられることにより、開始する。
【００４６】
Ｓ２０１において、ＵＩ_ＣＰＵ２０８は、ユーザから故障診断用プッシュＳＷ２１７の入力を受信したか否かの判定を行う。
ＵＩ_ＣＰＵ２０８が故障診断モードへの移行指示を受信していない場合、Ｓ２０１へ戻り、ＵＩ_ＣＰＵ２０８が故障診断モードへの移行指示を受信するまで繰り返す。
【００４７】
故障診断モードへの移行指示を受信すると、Ｓ２０２において、ＵＩ_ＣＰＵ２０８は、移行指示をトリガーとして故障箇所特定処理を開始する。
まず、Ｓ２０３において、ＵＩ_ＣＰＵ２０８は、タッチパネルコントローラＩＣ２１０が正常に動作しているか否かを、通信状態やコマンドの送受信に基づいて判定を行う。
ＵＩ_ＣＰＵ２０８は、タッチパネルコントローラＩＣ２１０からの応答があれば、通信が正常であると判定する。一方、タッチパネルコントローラＩＣ２１０からの応答がなければ、ＵＩ_ＣＰＵ２０８は、タッチパネルコントローラＩＣ２１０が正常に動作していないと判定する。
【００４８】
タッチパネルコントローラＩＣ２１０が正常に動作していない場合（Ｓ２０３：ＮＯ）、Ｓ２０４において、ＵＩ_ＣＰＵ２０８は操作部基板ユニット２１４の故障であると判定する。そして、ＵＩ_ＣＰＵ２０８は、操作部基板ユニット２１４の故障であることを、メインＣＰＵ２０２に通知し、また、タッチパネル２１１へ表示する。
タッチパネルコントローラＩＣ２１０が正常に動作している場合（Ｓ２０３：ＹＥＳ）、Ｓ２０５において、ＵＩ_ＣＰＵ２０８は、タッチパネル２１１のタッチ検知がＨｉｇｈであるか否かを判定する。実施例２においても、ユーザによる入力がある場合、タッチパネル２１１のタッチ検知がＬｏｗになるものとして説明する。
【００４９】
Ｓ２０５においてＨｉｇｈである（タッチが検知されない）と判定された場合（Ｓ２０５：ＹＥＳ）、Ｓ２００１へ移行する。一方、Ｌｏｗである（タッチが検知された）と判定された場合（Ｓ２０５：ＮＯ）、Ｓ２００２へ移行する。
【００５０】
Ｓ２０５においてＨｉｇｈであると判定された場合（Ｓ２０５：ＹＥＳ）、Ｓ２００１において、ＵＩ_ＣＰＵ２０８は、操作部をタッチするようにユーザに促す音声出力をスピーカー２１３から行う。ここで、音の出力としては、ユーザに画面への入力を促す方法であれば、音声でなくてもよい。例えば、ユーザに画面への入力を促す場合、出力する音の回数をあらかじめ設定しておき、設定されている回数の音を出力するようにしてもよい。
【００５１】
スピーカー２１３から音声出力を行うと、Ｓ２０７において、ＵＩ_ＣＰＵ２０８は、タッチ検知がＨｉｇｈからＬｏｗに変化したか否かを判定する。ここで、ＨｉｇｈからＬｏｗへの変化とは、タッチパネル２１１がタッチされていたことを検知したことを意味する。
タッチ検知がＨｉｇｈからＬｏｗに変化した場合（Ｓ２０７：ＹＥＳ）、Ｓ２１４へ移行し、ＵＩ_ＣＰＵ２０８は、異常なしと判定し、通常動作へ戻る。
一方、タッチ検知がＨｉｇｈのままＬｏｗに変化しない場合（Ｓ２０７：ＮＯ）、Ｓ２０８へ移行し、ＵＩ_ＣＰＵ２０８は、Ｓ２００１において音声出力を行ってから一定時間経過しているか否かを判定する。
【００５２】
Ｓ２０８において一定時間経過していればＳ２０９へ移行し、経過していなければＳ２０７へ戻る。なお、スピーカー２１３から複数回音声出力する場合には、初回の音声出力から一定時間を計測してもよい。
スピーカー２１３から音声出力してから一定時間変化がない場合（Ｓ２０８：ＹＥＳ）、タッチパネル２１１が故障したために、入力が受信できないものと考えられる。
そこで、Ｓ２０９において、ＵＩ_ＣＰＵ２０８は、タッチパネル２１１の故障と判定し、タッチパネル２１１の故障であることをタッチパネル２１１へ表示する。もちろん、通知方法は表示に限定する必要はない。
【００５３】
Ｓ２０５においてタッチパネル２１１のタッチ検知がＨｉｇｈではない（タッチが検知された）と判定されると（Ｓ２０５：ＮＯ）、Ｓ２００２へ移行する。そして、Ｓ２００２において、ＵＩ_ＣＰＵ２０８は、タッチ検知が継続しているのが、ユーザが実際にタッチをしているためであるのか、故障が発生したためであるのかを判定するために、スピーカー２１３から音声出力を行う。具体的には、ＵＩ_ＣＰＵ２０８は、操作部ユニット２１６からタッチを離すようにユーザに促す音声をスピーカー２１３に出力する。
【００５４】
Ｓ２１１において、ＵＩ_ＣＰＵ２０８は、タッチ検知がＬｏｗからＨｉｇｈに変化したか否かを判定する。ＬｏｗからＨｉｇｈへの変化は、ユーザがタッチパネル２１１へのタッチを離したことが検知されたことを意味する。
そこで、タッチ検知がＬｏｗからＨｉｇｈに変化した場合（Ｓ２１１：ＹＥＳ）、Ｓ２１４において、ＵＩ_ＣＰＵ２０８は、タッチパネル２１１に異常がないと判定し、通常動作へ戻る。
【００５５】
一方、タッチ検知がＬｏｗからＨｉｇｈに変化しない、すなわち、タッチパネル２１１へのタッチ検知が継続している場合（Ｓ２１１：ＮＯ）、Ｓ２１３へ移行し、ＵＩ_ＣＰＵ２０８は、Ｓ２００２における音声出力から一定時間経過しているか否かを判定する。
【００５６】
一定時間がまだ経過していなければ（Ｓ２１３：ＮＯ）、Ｓ２１１へ戻る。
一定時間経過したら（Ｓ２１３：ＹＥＳ）、スピーカー２１３から音声を出力してもタッチ検知に変化がないのは、タッチパネル２１１が故障し、入力が受信できないためであると考えられる。
そこで、Ｓ２０９において、ＵＩ_ＣＰＵ２０８はタッチパネル２１１の故障と判定し、タッチパネル２１１の故障であることをタッチパネル２１１へ表示する。
【００５７】
なお、ユーザに故障の有無や故障箇所を通知する方法は、ＬＣＤユニット２１２やタッチパネル２１１に表示する方法には限られない。例えば、スピーカーを用いて音声出力によりユーザに通知してもよい。
また、タッチパネル２１１の故障の判断する方法としては、時間経過によるものには限られない。例えば、故障診断モード中において、異常なしと判定されないまま情報処理装置２００の電源のＯＦＦ／ＯＮが実行された場合に、タッチパネル２１１への入力ができない故障と判定してもよい。
【００５８】
以上のように、実施例２では、故障診断モードへの移行の指示が入力されると、ＵＩ_ＣＰＵ２０８はスピーカー２１３から音声出力を行い、ユーザに対してタッチパネルへの入力の変化を促す。そして、タッチパネルへの入力の変化を用いて、タッチパネル２１１の故障であるか、タッチパネルコントローラ２１０の故障であるかを、区別して故障箇所を判断する。
その結果、操作部ユニットに故障が発生した場合、故障部品を特定することができるため、交換する部品を最小限に抑えることができる。これにより、運用コストの削減を可能とし、また、情報処理装置のダウンタイムを減少させることも可能となる。
【００５９】
（その他の実施例）
本発明は、上述の実施例の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。
本発明は上述の実施例に限定されるものではなく、本発明の趣旨に基づき種々の変形が可能であり、それらを本発明の範囲から除外するものではない。すなわち、上述の実施例及びその変形例を組み合わせた構成もすべて本発明に含まれるものである。
【符号の説明】
【００６０】
２００      情報処理装置
２０８      ＵＩ＿ＣＰＵ
２１１      タッチパネル
２１２      ＬＣＤユニット
２１３      スピーカー
２１４      操作部基板ユニット
２１６      操作部ユニット
２０７      故障診断用プッシュＳＷ
【図１】
2020066183.tif 000003
【図２】
2020066183.tif 000004
【図３】
2020066183.tif 000005
【図４】
2020066183.tif 000006
【図５】
2020066183.tif 000007