JP6996166B2 - 情報処理装置、およびプログラム - Google Patents

Description

本発明は、情報処理装置、およびプログラムに関する。

従来、画像形成装置（情報処理装置）などにおいて、画面表示やキー入力の操作する操作部（操作デバイス)と本体（ホスト装置）とを別々のＯＳ（Operating System）で互いに独立して動作させることで、本体の負荷が高くても、操作レスポンスを低下させない技術が既に知られている。

このような画像形成装置で故障が発生した場合、装置をリブートすることでリカバリを行うことがある。例えば、故障発生時にリカバリを実施する画像形成装置が開示されている（特許文献１参照）。この特許文献１の画像形成装置では、課金やその他の管理上の必要性から設けられる各種カウンタの値に不整合を生じさせないようにリブートを行っている。

しかしながら、特許文献１の画像形成装置では、上述したような本体と操作部とを別々のＯＳで互いに独立して動作させる画像形成装置において本体と操作部の通信に異常が発生した場合、当該画像形成装置を正常な状態にリカバリすることができない。すなわち、特許文献１の画像形成装置では、障害発生時でもシステムコントロールサービス（ＳＣＳ）とアプリとのソフトウェア通信が可能な構成となっているため、リブートを行う場合にＳＣＳからアプリへの動作停止の要求やその応答をソフトウェア通信によって送受信している。しかし、上述のような本体と操作部が独立し、リカバリしたい現象（故障の原因）が「本体と操作部との通信異常」である場合、特許文献１で実施されるリカバリ方法を適用しても装置をリカバリすることができない。

本発明は、上記に鑑みてなされたものであって、本体と操作部とを別々のＯＳで互いに独立して動作させる装置において、本体と操作部の通信に異常が発生した場合にも正常な状態にリカバリできる情報処理装置、およびプログラムを提供することを目的とする。

上述した課題を解決し、目的を達成するために、本発明は、外部装置と第１の通信路、及び前記第１の通信路とは別に設けられる第２の通信路を介して信号を送受信する情報処理装置であって、前記第１の通信路における通信異常を示す異常情報を取得する異常取得部と、前記異常取得部が前記異常情報を取得した場合、前記情報処理装置をリブートするか否かを判断する判断部と、前記判断部が前記情報処理装置をリブートすると判断した場合、シャットダウン指示を前記第２の通信路によって前記外部装置に送信し、さらに前記情報処理装置をリブートするリブート管理部と、を備える。

本発明によれば、本体と操作部とを別々のＯＳで互いに独立して動作させる装置において、本体と操作部の通信に異常が発生した場合にも正常な状態にリカバリできるという効果を奏する。

図１は、第１の実施形態にかかる画像形成装置のハードウェア構成図である。 図２は、第１の実施形態にかかる画像形成装置の機能ブロック図である。 図３は、画像形成装置におけるリブート処理の流れを示すフローチャートである。 図４は、画像形成装置におけるリブート処理の流れを示すシーケンス図である。 図５は、画像形成装置におけるリブート処理の流れを示すフローチャートである。 図６は、画像形成装置におけるリブート処理の流れを示すシーケンス図である。 図７は、第２の実施形態にかかる画像形成装置のハードウェア構成図である。 図８は、第２の実施形態にかかる画像形成装置の機能ブロック図である。 図９は、画像形成装置における通信部の異常発生時の処理の流れを示す概念図である。 図１０は、画像形成装置におけるリブート処理の流れを示すシーケンス図である。 図１１は、第３の実施形態にかかる画像形成装置のハードウェア構成図である。 図１２は、第３の実施形態にかかる画像形成装置の機能ブロック図である。 図１３は、画像形成装置におけるリブート処理の流れを示すシーケンス図である。 図１４は、画像形成装置におけるリブート処理の流れを示すシーケンス図である。 図１５は、第４の実施形態にかかる画像形成装置の機能ブロック図である。 図１６は、画像形成装置におけるリブート処理の流れを示すシーケンス図である。 図１７は、画像形成装置における処理情報の表示処理の流れを示すシーケンス図である。 図１８は、第５の実施形態にかかる車載装置のハードウェア構成図である。 図１９は、第５の実施形態にかかる車載装置の機能ブロック図である。

以下に添付図面を参照して、情報処理装置、およびプログラムの実施の形態を詳細に説明する。以下の実施形態では、情報処理装置を画像形成装置に適用した例について説明するが、他の装置に適用してもよい。画像形成装置としては、例えば、コピー機能、スキャナ機能、ファクス機能、プリンタ機能等のうち、少なくとも二つ以上の機能を実現可能なＭＦＰ（Multi‐Function Peripheral）、複写機、プリンタ装置、スキャナ装置などである。

（第１の実施形態）
図１は、第１の実施形態にかかる画像形成装置のハードウェア構成図である。図１に示すように、画像形成装置１は、外部装置の一例である操作デバイス１００と、情報処理装置の一例であって画像形成を行う本体２００とを備えている。

本実施形態の画像形成装置１では、操作デバイス１００および本体２００の間の接続は、シリアル通信用の信号線で有線接続の場合について説明するが、無線ＬＡＮ（Local Area Network）等の無線接続を用いてもよい。また、接続する際のインターフェースを制限するものではなく、例えば、シリアル通信用の信号線以外に、ＵＳＢ（Universal Serial Bus）、シリアル、有線・無線ＬＡＮ、Bluetooth（登録商標）、ＩｒＤＡ（Infrared Data Association）、ＷｉＦｉ（登録商標：Wireless Fidelity）等を用いてもよい。また、通信方式としては、どのような通信方式を用いても良く、例えばＩ２Ｃ通信を用いることが考えられる。

操作デバイス１００は、ユーザ操作に応じた入力を受け付けるためのものであって、本体２００を操作するための専用デバイスとする。しかしながら、本実施形態は、専用デバイスに制限するものではなく、例えば、ユーザが所持するスマートフォンやタブレット端末であってもよい。操作デバイス１００と本体２００とは、別々のＯＳ（Operating System）で互いに独立して動作する。

また、本実施形態では、操作デバイス１００によって操作可能なホスト装置として、画像形成を行う本体２００を用いた例について説明する。しかしながら、本実施形態は、操作可能なホスト装置は画像形成装置の本体２００に制限するものではなく、操作デバイス１００で操作可能な機器であれば適用可能である。

図１に示すように、操作デバイス１００は、ＣＰＵ（Central Processing Unit）１１と、ＲＯＭ（Read Only Memory）１２と、ＲＡＭ（Random Access Memory）１３と、無線通信Ｉ／Ｆ１４と、接続Ｉ／Ｆ１５と、操作パネル１６とを備えている。そして、上記各構成は、内部バス１０を介して相互に接続されている。

ＣＰＵ１１は、操作デバイス１００の全体的な制御を行う。ＣＰＵ１１は、ＲＡＭ１３を作業領域として、ＲＯＭ１２等に格納されたプログラムを実行する。これにより、ＣＰＵ１１は、ユーザ操作に応じて各種機能を実現する。

無線通信Ｉ／Ｆ１４は、無線による接続のためのインターフェースとし、無線通信ネットワーク５０と接続する。無線通信ネットワーク５０は、無線ＬＡＮ等とする。

接続Ｉ／Ｆ１５は、有線で接続するためのインターフェースであって、通信路６０および通信路７０を介して本体２００と通信を行う。通信路６０および通信路７０は、例えば、ＵＳＢ接続用のケーブルを用いることが考えられるが、他の接続手法を用いてもよい。

通信路６０は、操作デバイス１００と本体２００との間でソフトウェア信号を送受信するものであって、第１の通信路の一例である。通常、画像形成装置１の操作デバイス１００と本体２００は、通信路６０を利用してソフトウェア通信を実施している。なお、ソフトウェア信号とはプロトコルを用いた信号であり、ソフトウェア通信は当該ソフトウェア信号の送受信を行うことを意味する。ソフトウェア通信は、例えば、Ether（Ethernet)通信やＵＳＢ通信などを含む。なお、通信路６０は、信号線によって通信可能に接続されていてもよいし、無線通信によって接続されていてもよい。

通信路７０は、操作デバイス１００と本体２００との間でハードウェア信号を送受信するものであって、第２の通信路の一例である。通信路６０によりソフトウェア通信が実施できないような通信異常が発生した場合、操作デバイス１００と本体２００との間で通信路７０を利用してハードウェア通信を実施する。具体的に例えば、通信路７０は、操作デバイス１００から本体２００に通信異常を検知した旨をハードウェア信号により通知したり、本体２００から操作デバイス１００に対して電源ＯＦＦ（オフ）などの指令等をハードウェア信号により通知する。なお、ハードウェア信号は、電圧のHigh、Lowによって機器の状態を通知する信号であってプロトコルを用いない信号である。ハードウェア通信はハードウェア信号の送受信を行うことを意味する。ハードウェア通信は、例えば、GPIO（General-purpose input／output）通信などを含む。ただし、上述したように通信路７０の通信方式はこれに限定されない。通信路７０は、通信路６０とは別の通信路であればよい。例えば、通信路７０は、ソフトウェア信号を送受信する通信路であってもよい。また、例えば、通信路７０は、複数の信号線によって構成されていてもよく、この場合、通信路７０は、ハードウェア信号を送受信する信号線とソフトウェア信号を送受信する信号線の組み合わせであってもよい。また、通信路７０は、信号線によって通信可能に接続されていてもよいし、無線通信によって接続されていてもよい。

操作パネル１６は、タッチスクリーンやハードウェアキー等を有する。タッチスクリーンは、例えば、タッチパネル機能を搭載した液晶表示装置（ＬＣＤ：Liquid Crystal Display）や有機ＥＬ（Electro Luminescence）表示装置とすることが考えられる。操作パネル１６が表示部の一例である。なお、ユーザによる操作を受け付ける入力部と、ユーザに対して情報を表示する表示部は、別に設けることができる。ここで、入力部としては、キーボード、マウス、音声入力に対応したマイク、ジェスチャー入力に対応したカメラを備えてもよい。さらに、操作パネル１６は、ユーザに対して機器の状態などを通知するためにスピーカを設けてもよい。

また、図１に示すように、本体２００は、ＣＰＵ２１と、ＲＯＭ２２と、ＲＡＭ２３と、ＨＤＤ（Hard Disk Drive）２４と、無線通信Ｉ／Ｆ２５と、接続Ｉ／Ｆ２６と、エンジン部２７と、操作パネル２８と、有線通信Ｉ／Ｆ２９とを備えている。そして、上記各構成は、内部バス２０を介して相互に接続されている。

ＣＰＵ２１は、本体２００の全体的な制御を行う。ＣＰＵ２１は、ＲＡＭ２３を作業領域として、ＲＯＭ２２またはＨＤＤ２４等に格納されたプログラムを実行する。これにより、ＣＰＵ２１は、ユーザ操作や受け付けた命令等に応じて、上述したコピー機能、スキャナ機能、ファクス機能、プリンタ機能等の各種機能や、後述する各種機能を実現する。なお、ＣＰＵ、ＲＯＭ、ＲＡＭは複数設けられていても良く、各種機能を分担して実現する構成であってもよい。

無線通信Ｉ／Ｆ２５は、無線による接続のためのインターフェースとし、無線通信ネットワーク５０と接続する。

接続Ｉ／Ｆ２６は、有線による接続のためのインターフェースであり、通信路６０および通信路７０を介して操作デバイス１００と通信を行う。

機能部２７は、情報処理装置の種類に応じて各種機能を実現する手段である。情報処理装置が画像形成装置である場合には、機能部２７は画像形成エンジン等であり、例えば、白黒プロッタ、ドラムカラープロッタ、スキャナ又はファクスユニット等の機能を実現する。操作パネル２８は、タッチスクリーンやハードウェアキー等を有する。なお、操作パネル２８は、画面を表示するための表示装置であっても良い。

有線通信Ｉ／Ｆ２９は、有線による接続のためのインターフェースとし、ＬＡＮ５０ａと接続する。

図２は、第１の実施形態にかかる画像形成装置の機能ブロック図である。図２に示す操作デバイス１００は、ＣＰＵ１１がＲＯＭ１２に格納されていたプログラムを実行することで、通信制御部１０１と、アプリケーション１０３と、通信異常検知部１１１と、異常発生原因受信部１１２と、電源管理部１１３と、表示制御部１１４とを実現する。ただし、複数ＣＰＵ、ＲＯＭやＲＡＭなどの複数のメモリ、その他ハードウェアが協業することで、各機能ブロックの機能を実現してもよい。

通信制御部１０１は、接続Ｉ／Ｆ１５や、無線通信Ｉ／Ｆ１４を介して、本体２００を含む他の装置との間で、情報の送受信を制御する。

アプリケーション１０３は、ユーザインターフェースを有し、操作パネル１６に対して画面を表示したり、ユーザから操作パネル１６を介して、操作設定などを受け付ける。また、アプリケーション１０３は、本体２００が有する、コピー機能、スキャナ機能、ファクス機能、プリンタ機能等の各種機能を用いたサービスを提供してもよい。また、アプリケーション１０３は、複数備えていてもよく、操作パネル１６のみ利用するアプリケーションや、本体２００を利用するアプリケーション、さらにはこれら両方を利用するアプリケーションであってもよい。

通信異常検知部１１１は、本体２００との間でソフトウェア通信を実施している通信路６０（第１の通信路）で発生した通信異常を検知する。例えば、通信異常検知部１１１は、通信制御部１０１により前回信号を受信してから所定時間以上信号を受信しない場合や、予め定めた信号を送信してから所定時間以上信号を受信しない場合等に、通信異常と判別することで、通信異常を検知する。なお、通信異常の検知方法は、この方法に限られない。

そして、通信異常検知部１１１は、通信路６０での通信異常を検知すると、通信路６０で通信異常が発生した旨の異常通知（異常情報）を、通信路７０（第２の通信路）によってハードウェア信号を用いて本体２００に送信する。

異常発生原因受信部１１２は、通信路６０の通信に対する異常通知が本体２００に送信された後、通信路６０の通信異常の発生原因である異常発生原因、または本体２００をリブートするか否かの判断結果を、通信路７０によって本体２００から受信する。

電源管理部１１３は、操作デバイス１００の電源を管理する。また、電源管理部１１３は、通信路６０の異常発生原因がリブートにより画像形成装置１のリカバリが可能な所定の原因であった場合、または本体２００をリブートする旨の判断結果の場合、シャットダウンする旨のシャットダウン指示を、本体２００から通信路７０によって受信する。シャットダウン指示を受信すると、電源管理部１１３は、操作デバイス１００の動作抑制を行い、シャットダウンする。このとき、電源管理部１１３は、操作デバイス１００において動作する全てのプログラムを終了して電源を完全に切断してもよいし、次回の起動時に高速で起動するために動作状態を保存して、操作デバイス１００内の一部のデバイスの電源は保持してもよい。また、本体２００が操作デバイス１００へシャットダウン指示を送信する場合、通信路７０を構成する複数の信号線のうち、ソフトウェア信号を送受信する信号線を用いてもいい。なお、所定の原因とは、画像形成装置１のリブートにより通信路６０の通信異常のリカバリが可能なものであって、本実施形態では例えばソフトウェア異常による異常発生原因などである。

表示制御部１１４は、ユーザに対する各種情報を操作パネル１６（表示部）に表示するものである。本実施形態では、表示制御部１１４は、本体２００から受信した通信路６０の異常発生原因、または本体２００をリブートするか否かの判断結果を操作パネル１６に表示する。また、表示制御部１１４は、通信路６０の異常発生原因がリブートにより画像形成装置１のリカバリが可能な所定の原因（ソフトウェア異常等）であった場合、画像形成装置１をリブートする旨を操作パネル１６に表示する。また、表示制御部１１４は、画像形成装置１のリブートが実施された場合、リブートした旨を操作パネル１６に表示する。

次に本体２００について説明する。図２に示す本体２００は、ＣＰＵ２１がＲＯＭ２２に格納されていたプログラムを実行することで、通信制御部２０１と、画像入力部２０３と、画像出力部２０４と、通信異常受信部２１１と、異常発生原因特定部２１２と、リブート管理部２１３と、を実現する。ただし、複数のＣＰＵ、ＲＯＭやＲＡＭなどの複数のメモリ、その他ハードウェアが協業することで、各機能ブロックの機能を実現してもよい。

通信制御部２０１は、接続Ｉ／Ｆ２６、無線通信Ｉ／Ｆ２５、及び有線通信Ｉ／Ｆ２９を介して、操作デバイス１００を含む他の装置との間で、情報の送受信を制御する。

画像入力部２０３は、本体２００に対する画像データの入力処理を行う。画像出力部２０４は、本体２００から画像データの出力や、画像の印刷処理を行う。画像入力部２０３および画像出力部２０４は、機能部２７によって実現される。

通信異常受信部２１１は、操作デバイス１００により通信路６０において通信異常の発生が検知された場合、操作デバイス１００から通信路７０を用いてハードウェア信号により送信された異常通知（異常情報）を受信する。なお、通信異常受信部２１１が異常取得部に相当する。また、通信異常受信部２１１が通信路６０における通信異常の発生を検知してもよい。この場合、通信異常受信部２１１は、例えば、通信制御部２０１により前回信号を受信してから所定時間以上信号を受信しない場合や、予め定めた信号を送信してから所定時間以上信号を受信しない場合等に、通信異常が発生したと判別する。なお、通信異常の検知方法は、この方法に限られない。

異常発生原因特定部２１２は、操作デバイス１００から異常通知を受信した場合、または通信異常受信部２１１が通信路６０における通信異常の発生を検知した場合、この通知をトリガとして通信路６０の異常発生原因を判断し特定する。ここで、通信路６０の異常発生原因には、例えば、ハードウェア異常、ケーブル異常、またはソフトウェア異常が挙げられる。そして、異常発生原因がハードウェア異常またはケーブル異常の場合は、画像形成装置１をリブートしても通信異常は解消しないためリブートは実施しない。一方、異常発生原因がソフトウェア異常の場合は、画像形成装置１をリブートすることにより通信異常が解消する可能性があるためリブートを実施する。つまり、異常発生原因特定部２１２は、通信異常の原因に基づいて、本体２００をリブートするか否かを判断する。

通信路６０の異常発生原因を特定する方法の例を説明する。例えば、異常発生原因特定部２１２は、ＢＩＯＳ（Basic Input／Output System）が格納されている不揮発領域に委譲があるかに否かを確認する。ＢＩＯＳが正常起動するとＬＥＤが点滅するため、異常発生原因特定部２１２は、ＬＥＤの点滅状態を確認する。そして、異常発生原因特定部２１２は、ＬＥＤが点滅していない場合、不揮発領域の異常と判断してハードウェア異常と特定する。

また、例えば、異常発生原因特定部２１２は、接続Ｉ／Ｆ２６であるＵＳＢのポートの状態（Current Connect Status）を確認して、接続デバイスが存在しているかどうかを判断する。そして、異常発生原因特定部２１２は、接続デバイスが存在しない場合、ケーブル異常と特定する。つまり、異常発生原因特定部２１２は、ケーブルの接続状態を判定し、ケーブル抜けやケーブルの故障又は断線などにより接続状態に異常がある場合は、ケーブル異常と特定する。

また、例えば、異常発生原因特定部２１２は、ハードウェア異常およびケーブル異常でないと判断した場合、ソフトウェア異常（ソフトウェア障害）と特定する。

そして、異常発生原因特定部２１２は、特定した通信路６０の異常発生原因を、通信路７０によって操作デバイス１００に送信する。また、異常発生原因特定部２１２は、異常発生原因を送信する代わりに、本体２００をリブートするか否かの判断結果を、通信路７０によって操作デバイス１００に送信してもよい。なお、異常発生原因特定部２１２が判断部に相当する。

リブート管理部２１３は、通信路６０の異常発生原因がソフトウェア異常（所定の原因の一例）であった場合、操作デバイス１００に、通信路７０を用いてハードウェア信号によってシャットダウンを行う旨のシャットダウン指示を送信する。そして、リブート管理部２１３は、操作デバイス１００のシャットダウンを検知すると、本体２００の動作抑制を行い、本体２００をリブートする。つまり、リブート管理部２１３は、異常発生原因特定部２１２が本体２００をリブートすると判断した場合、シャットダウン指示を通信路７０によって操作デバイス１００に送信し、さらに本体２００をリブートする。このとき、リブート管理部２１３は、本体２００において動作する全てのプログラムを終了して本体２００内の全デバイスの電源を完全に切断してから起動し直すことができるが、本体２００内の一部のデバイスの電源は保持してもよいし、本体２００において動作する一部または全部のソフトウェアのみを終了してから起動し直してもよい。

次に、本実施形態の画像形成装置１におけるリブート処理についてフローチャートを用いて説明する。図３は、画像形成装置におけるリブート処理の流れを示すフローチャートである。

操作デバイス１００は、通信路６０の通信異常を検知すると（ステップＳ１０）、異常発生原因を判断中である旨を操作パネル１６に表示する（ステップＳ１１）。そして、操作デバイス１００は、通信路６０において通信異常が発生した旨の異常通知を、通信路７０により本体２００に送信する（ステップＳ１２）。

本体２００は、異常通知を受信すると、異常発生原因を判断して特定する（ステップＳ１３）。そして、本体２００は、特定された異常発生原因から、画像形成装置１のリブートによってリカバリ可能か否かを判断する（ステップＳ１４）。

そして、本体２００は、リブートによるリカバリが不可能と判断した場合（ステップＳ１４：Ｎｏ）、リカバリ不可能である旨と特定された異常発生原因を、通信路７０により操作デバイス１００に送信する（ステップＳ１５）。

操作デバイス１００は、リブートによるリカバリが不可能な旨と異常発生原因を受信すると、異常発生原因とリカバリ不可能である旨を表示して処理を終了する（ステップＳ１６）。この場合の異常発生原因としては、ハードウェア異常やケーブル異常などである。

一方、本体２００は、リブートによるリカバリが可能と判断した場合（ステップＳ１４：Ｙｅｓ）、リカバリ可能である旨と特定された異常発生原因を、通信路７０により操作デバイス１００に送信する（ステップＳ１７）。なお、異常発生原因に代えて、本体２００をリブートさせる旨の判断結果を通信路７０により操作デバイス１００に送信してもよい。操作デバイス１００は、リブートによるリカバリが可能な異常発生原因を受信すると、リブートする旨を表示する（ステップＳ１８）。

本体２００は、操作デバイス１００にシャットダウン指示を送信し（ステップＳ１９）、当該指示を受信すると、操作デバイス１００はシャットダウンする（ステップＳ２０）。操作デバイス１００がシャットダウンすると、本体２００はリブートを実施する（ステップＳ２１）。

本体２００が通信路６０によりリブートした旨を操作デバイス１００に送信すると、操作デバイス１００は画像形成装置１をリブートした旨を表示する(ステップＳ２２)。そして、通信路６０による通信が可能となり、通常の処理を行う。なお、本実施形態では、操作デバイス１００をシャットダウンさせた後に本体１００をリブートしているが、操作デバイス１００をシャットダウンさせるタイミングと本体２００をリブートさせるタイミングとは同時であってもよいし、本体２００をリブートさせた後に操作デバイス１００をシャットダウンさせてもよい。

次に、本実施形態の画像形成装置１におけるリブート処理の詳細についてシーケンス図を用いて説明する。図４は、画像形成装置におけるリブート処理の流れを示すシーケンス図である。なお、図４における操作デバイス１００と本体２００との通信は、通信制御部１０１と通信制御部２０１とを介して行われている（図２参照）。

まず、操作デバイス１００の通信異常検知部１１１は、通信路６０で発生した通信異常を検知すると（ステップＳ３０）、表示制御部１１４は、通信路６０の異常発生原因を判断中である旨を操作パネル１６に表示する（ステップＳ３１）。

そして、通信異常検知部１１１は、通信路６０で通信異常が発生した旨の異常通知を、通信路７０を用いてハードウェア信号により本体２００に送信する（ステップＳ３２）。

次に、本体２００の通信異常受信部２１１は、操作デバイス１００から異常通知を受信すると、異常発生原因特定部２１２に当該異常通知を送出する（ステップＳ３３）。異常発生原因特定部２１２は、異常通知を受け取ると、通信路６０の異常発生原因（例えば、ハードウェア異常、ケーブル異常、またはソフトウェア異常）を判断し特定する（ステップＳ３４）。

ここで、まず通信路６０の異常発生原因がリブートにより画像形成装置１のリカバリができない場合（リカバリ不可）について説明する。異常発生原因が、例えばケーブル異常であった場合、異常発生原因特定部２１２は、リカバリ不可能である旨とケーブル異常である旨の異常発生原因を、通信路７０を用いてハードウェア信号により、操作デバイス１００に送信する（ステップＳ３５）。また、異常発生原因特定部２１２は、異常発生原因をリブート管理部２１３に送出する（ステップＳ３６）。

操作デバイス１００の異常発生原因受信部１１２は、本体２００から送信されたリカバリ不可能である旨と異常発生原因を受信すると、受信した異常発生原因とリブートによるリカバリが不可能である旨を操作パネル１６に表示し（ステップＳ３７）、ユーザに知らせる。具体的には、例えば、「ケーブルが切断されています。装置のリブートではリカバリできないため、サービスへ連絡してください。」等を表示すれば、ユーザは迅速に対応できる。そして、本体２００のリブート管理部２１３は、リブートを行うことなく処理を終了する。

一方、通信路６０の異常発生原因がリブートによりリカバリできる場合（リカバリ可）について説明する。異常発生原因が、例えばリブートによるリカバリが可能なソフトウェア異常であった場合、異常発生原因特定部２１２は、リカバリ可能である旨とソフトウェア異常である旨の異常発生原因を、通信路７０を用いてハードウェア信号により、操作デバイス１００に送信する（ステップＳ３８）。また、異常発生原因特定部２１２は、異常発生原因をリブート管理部２１３に送出する（ステップＳ３９）。

操作デバイス１００の異常発生原因受信部１１２は、本体２００から送信されたリカバリ可能である旨と異常発生原因を受信すると、画像形成装置１をリブートする旨を操作パネル１６に表示し（ステップＳ４０）、ユーザに知らせる。

次に、本体２００のリブート管理部２１３は、通信路７０を用いてハードウェア信号により、操作デバイス１００にシャットダウン指示を送信する（ステップＳ４１）。シャットダウン指示を受信した電源管理部１１３は、操作デバイス１００の動作抑制を行い（ステップＳ４２）、シャットダウンを行う（ステップＳ４３）。

一方、リブート管理部２１３は、本体２００の動作抑制を行い（ステップＳ４４）、操作デバイス１００のシャットダウンを検知すると（ステップＳ４５）、本体２００のリブートを実施する（ステップＳ４６）。

その後、画像形成装置１が起動されると、操作デバイス１００と本体２００とは正常に通信が可能、すなわち、通信路６０によるソフトウェア通信が可能となる。従って、リブート管理部２１３は、通信路６０を用いてソフトウェア信号により、リブートした旨を操作デバイス１００に送信し、表示制御部１１４は、リブートした旨を操作パネル１６に表示する（ステップＳ４７）。その後、画像形成装置１において画像形成等の各種処理が実行できる。

このように、第１の実施形態の画像形成装置１では、操作デバイス１００と本体２００との間でソフトウェア信号を用いて通信を行う通信路６０で通信異常が発生した場合、通信路７０によりハードウェア信号を用いて、操作デバイス１００から通信異常が発生した旨の異常通知を本体２００に送信する。本体２００は、異常発生原因を特定して、通信路７０により操作デバイス１００に送信する。当該異常発生原因が、画像形成装置１のリブートによりリカバリが可能である場合、本体２００は操作デバイス１００をシャットダウンさせ、本体２００のリブートを実施する。このように、本体２００と操作デバイス１００が独立した画像形成装置１において、本体２００と操作デバイス１００との間で通信異常が発生した場合であっても、正常な状態にリカバリできる。

（第１の実施形態の変形例）
第１の実施形態の画像形成装置では、通信路の異常発生原因がソフトウェア異常などのリカバリ可能な原因であった場合は、操作デバイスをシャットダウンして、本体のリブートを実施していた。これに対し、本変形例では、通信路の異常発生原因がソフトウェア異常などのリカバリ可能な原因であった場合、かつ所定の条件を満たしている場合に操作デバイスをシャットダウンして、本体のリブートを実施するものである。

これは、例えば、本来リブートによりリカバリ可能な異常発生原因であっても、画像形成装置をリブートしてもリカバリできない場合がある。このような場合でも、異常発生原因から判断すると画像形成装置のリブートを実施してしまう。そうすると、画像形成装置１を連続してリブートさせてしまい、ユーザに対して不信感を与えてしまうことがある。これに対して、異常発生原因が発生した際に、リブートを行う条件（例えば、前回のリブートの実施から所定期間経過後であればリブートを実施可能等）を追加することで当該問題を解決することができる。

本実施形態の画像形成装置１のハードウェア構成は、第１の実施形態と同様である（図１参照）。以下では、画像形成装置１の機能構成について、追加する機能のみを図２を参照して説明する。

操作デバイス１００の電源管理部１１３は、第１の実施形態の機能に加え、異常発生原因受信部１１２によって異常発生原因を受信するとタイマによる計時を開始する。そして、電源管理部１１３は、通信路６０の異常発生原因がソフトウェア異常などのリカバリが可能な所定の原因であった場合でも、異常発生原因を受信した後、予め定めた所定時間（例えば、１分）が経過してもシャットダウン指示を受信しなかった場合、操作デバイス１００をシャットダウンしない。この所定時間が第１の所定時間に相当する。

操作デバイス１００の表示制御部１１４は、第１の実施形態の機能に加え、リブートによりリカバリが可能な通信路６０の異常発生原因を受信した場合、リブートを試みる旨を表示する。表示制御部１１４は、異常発生原因を受信した後所定時間が経過し、電源管理部１１３によって操作デバイス１００がシャットダウンされなかった場合、画像形成装置１がリブートを実施できる条件（リブート条件）を満たしていない旨を操作パネル１６に表示する。

本体２００のリブート管理部２１３は、通信路６０の異常発生原因がソフトウェア異常などのリカバリ可能な異常発生原因であった場合でも、前回のリブートの実施から所定期間内（例えば２４時間以内）であった場合は、操作デバイス１００にシャットダウン指示を送信せず、本体２００のリブートを実施しない。

次に、本変形例の画像形成装置１におけるリブート処理についてフローチャートを用いて説明する。図５は、画像形成装置におけるリブート処理の流れを示すフローチャートである。

通信異常の検知から、異常発生原因の表示までの処理（ステップＳ６０～６６）は、第１の実施形態と同様であるため説明を省略する（ステップＳ１０～１６参照）。

一方、本体２００は、リブートによるリカバリが可能と判断した場合（ステップＳ６４：Ｙｅｓ）、リカバリ可能である旨と特定された異常発生原因を、通信路７０により操作デバイス１００に送信する（ステップＳ６７）。なお、異常発生原因に代えて、本体２００をリブートさせる旨の判断結果を通信路７０により操作デバイスに送信してもよい。操作デバイス１００は、リブートによるリカバリが可能な異常発生原因を受信すると、リブートを試みる旨を表示する（ステップＳ６８）。

本体２００は、前回のリブートの実施から２４時間（所定期間）以内のリブートの実施か否かを判断する（ステップＳ６９）。２４時間以内のリブートの実施でない場合、つまり前回のリブートの実施から２４時間経過した場合（ステップＳ６９：Ｎｏ）、本体２００は、操作デバイス１００にシャットダウン指示を送信し（ステップＳ７０）、当該指示を受信した操作デバイス１００はシャットダウンする（ステップＳ７１）。操作デバイス１００がシャットダウンすると、本体２００は、リブートを実施する（ステップＳ７２）。

本体２００が通信路６０によりリブートした旨を操作デバイス１００に送信すると、操作デバイス１００は画像形成装置１をリブートした旨を表示する(ステップＳ７３)。そして、通信路６０による通信が可能となり、通常の処理を行う。

また、ステップＳ６９において、２４時間以内のリブートの実施である場合、つまり前回のリブートの実施から２４時間経過していない場合（ステップＳ６９：Ｙｅｓ）、本体２００は、連続リブートを回避するためリブートを実施しない。そして、操作デバイス１００は、異常発生原因を受信した後所定時間が経過してもシャットダウンされなかった場合、画像形成装置１がリブート条件を満たしていない旨を操作パネル１６に表示する（ステップＳ７４）。

次に、本実施形態の画像形成装置１におけるリブート処理の詳細についてシーケンス図を用いて説明する。図６は、画像形成装置におけるリブート処理の流れを示すシーケンス図である。図６では、通信異常に対するリブートによるリカバリ処理（図４のステップＳ３０～３４、ステップＳ３８～４７）の後、２４時間以内に通信異常を検知した場合の流れであって、リブートを実施しない場合について示している。なお、図６における操作デバイス１００と本体２００との通信は、通信制御部１０１と通信制御部２０１とを介して行われている（図２参照）。

通信路６０の通信異常の検知から、異常発生原因の特定までの処理（ステップＳ８０～８４）は、第１の実施形態と同様であるため説明を省略する（ステップＳ３０～３４参照）。

通信路６０の異常発生原因が例えばソフトウェア異常であった場合、異常発生原因特定部２１２は、ソフトウェア異常である旨の異常発生原因を、通信路７０を用いてハードウェア信号により、操作デバイス１００に送信する（ステップＳ８５）。また、異常発生原因特定部２１２は、異常発生原因をリブート管理部２１３に送出する（ステップＳ８６）。リブート管理部２１３は、前回のリブートの実施から２４時間以内（所定期間内）であった場合は、操作デバイス１００にシャットダウン指示を送信せず、本体２００のリブートを実施しない。

操作デバイス１００の異常発生原因受信部１１２は、本体２００から送信された異常発生原因を受信すると、表示制御部１１４は、画像形成装置１のリブートを試みる旨を操作パネル１６に表示し（ステップＳ８７）、ユーザに知らせる。

そして、異常発生原因受信部１１２は、異常発生原因を電源管理部１１３に送出する（ステップＳ８８）。異常発生原因を受け取った電源管理部１１３は、タイマによる計時を開始する（ステップＳ８９）。

電源管理部１１３は、通信路６０の異常発生原因がソフトウェア異常などのリカバリが可能な所定の原因であった場合でも、異常発生原因を受信した後、所定時間（例えば１分）が経過して計時が完了してもシャットダウン指示を受信しなかった場合（ステップＳ９０）、操作デバイス１００をシャットダウンしない。そうすると、表示制御部１１４は、画像形成装置１がリブート条件を満たしていない旨を操作パネル１６に表示する（ステップＳ９１）。

このように、第１の実施形態の変形例の画像形成装置１では、操作デバイス１００と本体２００との間でソフトウェア信号を用いて通信を行う通信路６０で通信異常が発生した場合、通信路７０によりハードウェア信号を用いて、操作デバイス１００から通信異常が発生した旨の異常通知を本体２００に送信する。本体２００は、通信路６０の異常発生原因を特定して、通信路７０により操作デバイス１００に送信する。当該異常発生原因が、画像形成装置１のリブートによりリカバリが可能である場合で、かつ前回のリブートの実施から所定期間（例えば２４時間）以内でない場合、本体２００は操作デバイス１００をシャットダウンさせ、本体２００のリブートを実施する。このように、本体２００と操作デバイス１００が独立した画像形成装置１において、本体２００と操作デバイス１００との間で通信異常が発生した場合であっても、正常な状態にリカバリできる。また、前回のリブートの実施から所定期間内である場合にはリブートを実施しないため、リブートしてもリカバリできなかった場合でも連続してリブートを実施してしまうことを回避することができる。

（第２の実施形態）
第１の実施形態の画像形成装置は、操作デバイスおよび本体を備えた構成となっていた。これに対して、本実施形態の画像形成装置では、操作デバイスおよび本体に加え、操作デバイスと本体とに接続されたマイコンを備えた構成となっている。なお、マイコンが管理装置の一例である。

図７は、第２の実施形態にかかる画像形成装置のハードウェア構成図である。図７に示すように、画像形成装置２は、外部装置の一例である操作デバイス３００と、本体４００と、マイコン５００とを備えている。

図７に示すように、操作デバイス３００は、ＣＰＵ１１と、ＲＯＭ１２と、ＲＡＭ１３と、無線通信Ｉ／Ｆ１４と、接続Ｉ／Ｆ３５と、操作パネル１６とを備えている。そして、上記各構成は、内部バス１０を介して相互に接続されている。ここで、ＣＰＵ１１、ＲＯＭ１２、ＲＡＭ１３、無線通信Ｉ／Ｆ１４、および操作パネル１６の機能および構成は第１の実施形態と同様である。

接続Ｉ／Ｆ３５は、有線で接続するためのインターフェースであって、通信路６０および通信路７０を介して本体４００と通信を行い、通信路８０ａおよび通信路８０ｂを介してマイコン５００経由で本体４００と通信を行う。通信路６０および通信路７０は、第１の実施形態と同様である。

通信路８０ａは、操作デバイス３００とマイコン５００との間でハードウェア信号を送受信するものである。通信路８０ｂは、マイコン５００と本体４００との間でハードウェア信号を送受信するものである。通信路８０ａ、８０ｂが第２の通信路の一例である。通信路６０によりソフトウェア通信が実施できないような通信異常が発生した場合、操作デバイス３００と本体４００との間で、通信路８０ａ、８０ｂによりマイコン５００を経由してハードウェア通信を実施する。

また、図７に示すように、本体４００は、ＣＰＵ２１と、ＲＯＭ２２と、ＲＡＭ２３と、ＨＤＤ２４と、無線通信Ｉ／Ｆ２５と、接続Ｉ／Ｆ４６と、エンジン部２７と、操作パネル２８と、有線通信Ｉ／Ｆ２９とを備えている。そして、上記各構成は、内部バス２０を介して相互に接続されている。ここで、ＣＰＵ２１、ＲＯＭ２２、ＲＡＭ２３、ＨＤＤ２４、無線通信Ｉ／Ｆ２５、エンジン部２７、操作パネル２８、および有線通信Ｉ／Ｆ２９の機能および構成は第１の実施形態と同様である。

接続Ｉ／Ｆ４６は、有線による接続のためのインターフェースであり、通信路６０および通信路７０を介して操作デバイス３００と通信を行い、通信路８０ａおよび通信路８０ｂを介してマイコン５００経由で操作デバイス３００と通信を行う。

また、図７に示すように、マイコン５００は、ＣＰＵ５１と、ＲＯＭ５２と、ＲＡＭ５３と、接続Ｉ／Ｆ５５とを備えており、内部バスを介して相互に接続されている。

ＣＰＵ５１は、マイコン５００の全体的な制御を行う。ＣＰＵ５１は、ＲＡＭ５３を作業領域として、ＲＯＭ５２等に格納されたプログラムを実行する。接続Ｉ／Ｆ５５は、有線で接続するためのインターフェースであって、通信路８０ａを用いて操作デバイス３００とハードウェア通信を行い、通信路８０ｂを用いて本体４００とハードウェア通信を行う。これにより、マイコン５００は、操作デバイス３００と本体４００との通信を仲介することになる。

図８は、第２の実施形態にかかる画像形成装置の機能ブロック図である。図８に示す操作デバイス３００は、ＣＰＵ１１がＲＯＭ１２に格納されていたプログラムを実行することで、通信制御部１０１と、アプリケーション１０３と、通信異常検知部３１１と、異常発生原因受信部３１２と、電源管理部３１３と、表示制御部１１４とを実現する。ここで、通信制御部１０１、アプリケーション１０３、および表示制御部１１４の機能および構成は、第１の実施形態と同様であるため説明を省略する。

通信異常検知部３１１は、本体４００との間でソフトウェア通信を実施している通信路６０（第１の通信路）で発生した通信異常を検知する。検知方法は第１の実施形態と同様である。

そして、通信異常検知部３１１は、通信路６０での通信異常を検知すると、通信路６０で通信異常が発生した旨の異常通知を、通信路８０ａ（第２の通信路）によってハードウェア信号を用いてマイコン５００に送信する。その後、マイコン５００により異常通知が本体４００に送信される。

異常発生原因受信部３１２は、通信路６０の通信に対する異常通知がマイコン５００経由で本体４００に送信された後、通信路８０ｂによって本体４００からマイコン５００に送信され、通信路８０ａによってマイコン５００から送信された異常発生原因を受信する。また、異常発生原因受信部３１２は、通信路８０ｂによって本体４００からマイコン５００に送信され、通信路８０aによってマイコン５００から送信された、本体４００をリブートするか否かの判断結果を受信してもよい。

電源管理部３１３は、操作デバイス３００の電源を管理する。また、電源管理部３１３は、通信路６０の異常発生原因がリブートにより画像形成装置２のリカバリが可能な所定の原因であった場合、または本体４００をリブートする旨の判断結果の場合、シャットダウンする旨のシャットダウン指示を、本体４００から通信路８０ａ、８０ｂによってマイコン５００経由で受信する。そして、シャットダウン指示を受信すると、電源管理部３１３は、操作デバイス３００の動作抑制を行い、シャットダウンする。所定の原因については、第１の実施形態と同様である。

次に本体４００について説明する。図８に示す本体４００は、ＣＰＵ２１がＲＯＭ２２に格納されていたプログラムを実行することで、通信制御部２０１と、画像入力部２０３と、画像出力部２０４と、通信異常受信部４１１と、異常発生原因特定部４１２と、リブート管理部２１３と、を実現する。ここで、通信制御部２０１、画像入力部２０３、画像出力部２０４、リブート管理部２１３の機能および構成は、第１の実施形態と同様であるため説明を省略する。

通信異常受信部４１１は、操作デバイス３００により通信路６０において通信異常の発生が検知された場合、操作デバイス３００から通信路８０ａ、８０ｂを用いてマイコン５００経由でハードウェア信号により送信された異常通知を受信する。なお、通信異常受信部４１１が異常取得部に相当する。

異常発生原因特定部４１２は、操作デバイス３００から異常通知を受信した場合、この通知をトリガとして通信路６０の異常発生原因を判断し特定する。異常発生原因の特定方法は、第１の実施形態と同様である。

そして、異常発生原因特定部４１２は、特定した通信路６０の異常発生原因を、通信路８０ａ、８０ｂによってマイコン５００経由で操作デバイス３００に送信する。なお、異常発生原因特定部４１２が判断部に相当する。

また、図８に示すマイコン５００は、ＣＰＵ５１がＲＯＭ５２に格納されていたプログラムを実行することで、異常通知通信部５１１と、異常発生原因通信部５１２と、代替リブート管理部５１３と、を実現する。

異常通知通信部５１１は、通信路８０ａを利用したハードウェア通信によって、操作デバイス３００から異常通知を受信する。異常通知を受信した場合、異常通知通信部５１１は、通信路８０ｂを利用したハードウェア通信によって、本体４００に受信した異常通知を送信する。また、異常通知を送信した場合、異常通知通信部５１１は、異常通知を代替リブート管理部５１３に送出する。なお、異常通知通信部５１１が異常情報通信部に相当する。

異常発生原因通信部５１２は、通信路８０ｂを利用したハードウェア通信によって、本体４００から異常発生原因を受信する。異常発生原因を受信した場合、異常発生原因通信部５１２は、通信路８０ａを利用したハードウェア通信によって、操作デバイス３００に受信した異常発生原因を送信する。また、異常発生原因を送信した場合、異常発生原因通信部５１２は、異常発生原因を代替リブート管理部５１３に送出する。また、異常発生原因通信部５１２は、異常発生原因に代えて、本体４００をリブートさせる旨の判断結果を受信および送信してもよい。なお、異常発生原因通信部５１２が判断結果通信部に相当する。

代替リブート管理部５１３は、異常通知通信部５１１により異常通知を受け取るとタイマによる計時を開始する。そして、代替リブート管理部５１３は、異常通知を本体４００に通知した後、予め定めた所定時間（例えば、１分）以内に本体４００から異常発生原因を受信した場合は、タイマによる計時を完了（終了）する。その後、代替リブート管理部５１３は、通信路８０ｂを利用したハードウェア通信によって本体４００からシャットダウン指示を受信した場合は、通信路８０ａを利用したハードウェア通信によって、操作デバイス３００にシャットダウン指示を送信する。

一方、代替リブート管理部５１３は、異常通知を本体４００に送信した後、所定時間が経過しても、本体４００から異常発生原因を受信しなかった場合、本体４００自体に異常が発生していると判断する。そして、代替リブート管理部５１３は、通信路８０ａによってハードウェア信号を用いて操作デバイス３００にシャットダウン指示を送信する。そして、代替リブート管理部５１３は、操作デバイス３００がシャットダウンしたことを検知すると、本体４００の電源をオフした後オンにすることで、本体４００をリブートする。

次に、本実施形態の画像形成装置２の通信路６０における異常発生時の処理の流れについて説明する。図９は、画像形成装置における通信部の異常発生時の処理の流れを示す概念図である。

操作デバイス３００と本体４００との間で、ソフトウェア通信の異常が発生すると（ステップＳ１００）、操作デバイス３００は、通信異常を検知する（ステップＳ１０１）。通信異常を検知した操作デバイス３００は、通信異常が発生した旨の異常通知をマイコン５００にハードウェア通信により送信する（ステップＳ１０２）。

操作デバイス３００から異常通知を受信したマイコン５００は、受信した異常通知を本体４００にハードウェア通信により送信する（ステップＳ１０３）。異常通知を受信した本体４００は、異常発生原因を特定する（ステップＳ１０４）。

ここで、リブートにより画像形成装置２のリカバリが可能でも、本体４００自体に異常が発生していた場合、シャットダウン指示を送信できない。従って、一定条件下で、マイコン５００が代替でシャットダウン指示を操作デバイス３００に送信する（ステップＳ１０５）。そして、マイコン５００は、本体４００をリブートさせることで、画像形成装置２のリブートを実施することができる（ステップＳ１０６）。

次に、本実施形態の画像形成装置２におけるリブート処理の詳細についてシーケンス図を用いて説明する。図１０は、画像形成装置におけるリブート処理の流れを示すシーケンス図である。なお、図１０における操作デバイス３００と本体４００との通信は、通信制御部１０１と通信制御部２０１とを介して行われている（図８参照）。

まず、操作デバイス３００の通信異常検知部３１１が通信路６０で発生した通信異常を検知すると（ステップＳ１１０）、表示制御部１１４は、通信路６０の異常発生原因を判断中である旨を操作パネル１６に表示する（ステップＳ１１１）。

そして、通信異常検知部３１１は、通信路６０で通信異常が発生した旨の異常通知を、通信路８０ａを用いてハードウェア信号によりマイコン５００に送信する（ステップＳ１１２）。マイコン５００の異常通知通信部５１１は、異常通知を受信すると、通信路８０ｂを用いてハードウェア信号により本体４００に異常通知を送信する（ステップＳ１１３）。

また、異常通知通信部５１１は、異常通知を代替リブート管理部５１３に送出し（ステップＳ１１４）、代替リブート管理部５１３は、異常通知を受け取るとタイマによる計時を開始する（ステップＳ１１５）。

次に、本体４００の通信異常受信部４１１は、マイコン５００から異常通知を受信すると、異常発生原因特定部４１２に当該異常通知を送出する（ステップＳ１１６）。異常発生原因特定部４１２は、異常通知を受け取ると、通信路６０の異常発生原因（例えば、ハードウェア異常、ケーブル異常、またはソフトウェア異常）を判断し特定する（ステップＳ１１７）。

ここで、まず本体４００自体には異常はなく、正常である場合について説明する。異常発生原因が、例えばソフトウェア異常であった場合、異常発生原因特定部４１２は、リカバリ可能である旨とソフトウェア異常である旨の異常発生原因を、通信路８０ｂを用いてハードウェア信号によりマイコン５００に送信する（ステップＳ１１８）。また、異常発生原因特定部４１２は、異常発生原因をリブート管理部２１３に送出する（ステップＳ１１９）。

マイコン５００の異常発生原因通信部５１２は、本体４００から送信されたリカバリ可能である旨と異常発生原因を受信すると、受信したリカバリ可能である旨と異常発生原因を操作デバイス３００に送信する（ステップＳ１２０）。また、異常発生原因通信部５１２は、異常発生原因を代替リブート管理部５１３に送出する（ステップＳ１２１）。

操作デバイス３００の異常発生原因受信部１１２は、マイコン５００から送信されたリカバリ可能である旨と異常発生原因を受信すると、画像形成装置２をリブートする旨を操作パネル１６に表示し（ステップＳ１２２）、ユーザに知らせる。

次に、本体４００のリブート管理部２１３は、通信路８０ｂを用いてハードウェア信号により、マイコン５００にシャットダウン指示を送信する（ステップＳ１２３）。マイコン５００の代替リブート管理部５１３は、シャットダウン指示を受信すると、通信路８０ａを用いてハードウェア通信により、操作デバイス３００にシャットダウン指示を送信する（ステップＳ１２４）。シャットダウン指示を受信した電源管理部３１３は、操作デバイス３００の動作抑制を行い（ステップＳ１２５）、シャットダウンを行う（ステップＳ１２６）。

一方、リブート管理部２１３は、本体４００の動作抑制を行い（ステップＳ１２７）、操作デバイス３００のシャットダウンを検知すると（ステップＳ１２８）、本体４００のリブートを実施する（ステップＳ１２９）。

その後、画像形成装置２が起動されると、操作デバイス３００と本体４００とは正常に通信が可能、すなわち、通信路６０によるソフトウェア通信が可能となる。従って、リブート管理部２１３は、通信路６０を用いてソフトウェア信号により、リブートした旨を操作デバイス３００に送信し、表示制御部１１４は、リブートした旨を操作パネル１６に表示する（ステップＳ１３０）。その後、画像形成装置２において画像形成等の各種処理が実行できる。

一方、本体４００自体に異常が発生していることで、通信異常が発生した場合について説明する。この場合、例えば異常発生原因は、本体の異常となる。代替リブート管理部５１３は、タイマによる計時が完了し（ステップＳ１３１）、所定時間が経過しても本体４００から異常発生原因を受信しなかった場合、本体４００に異常が発生している旨の異常発生原因を異常発生原因通信部５１２に送出する（ステップＳ１３２）。

異常発生原因通信部５１２は、本体４００に異常が発生している旨の異常発生原因を受け取ると、受け取った異常発生原因を操作デバイス３００に送信する（ステップＳ１３３）。操作デバイス３００の異常発生原因受信部３１２は、マイコン５００から送信された異常発生原因を受信すると、画像形成装置２をリブートする旨を操作パネル１６に表示し（ステップＳ１３４）、ユーザに知らせる。

次に、マイコン５００の代替リブート管理部５１３は、通信路８０ａを用いてハードウェア信号により、操作デバイス３００にシャットダウン指示を送信する（ステップＳ１３５）。シャットダウン指示を受信した電源管理部３１３は、操作デバイス３００の動作抑制を行い（ステップＳ１３６）、シャットダウンを行う（ステップＳ１３７）。

一方、代替リブート管理部５１３は、操作デバイス３００のシャットダウンを検知すると（ステップＳ１３８）、本体４００の電源をオフ（ＯＦＦ）にした後（ステップＳ１３９）、本体４００の電源をオン（ＯＮ）にすることにより（ステップＳ１４０）、本体４００のリブートを実施する。その後、画像形成装置２が起動される。

このように、第２の実施形態の画像形成装置２では、操作デバイス３００と本体４００との間でソフトウェア信号を用いて通信を行う通信路６０で通信異常が発生した場合、通信路８０ａ、８０ｂによりハードウェア信号を用いて、操作デバイス３００からマイコン５００を経由して異常通知を本体４００に送信する。本体４００は、異常発生原因を特定して、通信路８０ａ、８０ｂによりマイコン５００を経由して操作デバイス３００に送信する。当該異常発生原因が、本体４００の異常ではなく、画像形成装置２のリブートによりリカバリが可能である場合、本体４００はマイコン５００経由で操作デバイス３００をシャットダウンさせ、本体４００のリブートを実施する。このように、本体４００と操作デバイス３００が独立した画像形成装置２において、本体４００と操作デバイス３００との間で通信異常が発生した場合であっても、正常な状態にリカバリできる。

また、異常発生原因が本体４００の異常であって、異常通知を送信しても本体４００からマイコン５００に異常発生原因が送信されなかった場合、一定条件下でマイコン５００が操作デバイス３００をシャットダウンさせ、本体４００のリブートを実施する。これにより、本体４００自体に異常があった場合でも、画像形成装置２のリブートを実施できる。従って、本体４００と操作デバイス３００との間で通信異常が発生した場合であっても、正常な状態にリカバリできる。

なお、第２の実施形態の画像形成装置２においても、本来リブートによりリカバリ可能な異常発生原因でも、リブートによりリカバリできない場合がある。このような場合の連続リブートを回避するため、第１の実施形態の変形例と同様に、代替リブート管理部５１３も時間経過等のリブート条件を備えた構成としてもよい。

すなわち、代替リブート管理部５１３は、通信路６０の異常発生原因がソフトウェア異常などのリカバリ可能な異常発生原因であった場合でも、前回のリブートの実施から所定期間内（例えば２４時間以内）であった場合は、操作デバイス３００にシャットダウン指示を送信せず、本体４００のリブートを実施しない。

これにより、前回のリブートの実施から所定期間内である場合にはリブートを実施しないため、リブートしてもリカバリできなかった場合でも連続してリブートを実施してしまうことを回避することができる。

（第３の実施形態）
第１の実施形態の画像形成装置は、操作デバイスと本体との間でソフトウェア信号を送受信する通信、およびハードウェア信号を送受信する通信を用いる構成となっていた。これに対して、本実施形態の画像形成装置では、操作デバイスと本体との間でソフトウェア信号を送受信する通信、および近距離無線通信を用いる構成となっている。なお、本実施形態では、近距離無線通信として、例えば、ＮＦＣ（Near Field Communication）を用いた例を挙げて説明する。

図１１は、第３の実施形態にかかる画像形成装置のハードウェア構成図である。図１１に示すように、画像形成装置３は、外部装置の一例である操作デバイス７００と、本体８００とを備えている。

図１１に示すように、操作デバイス７００は、ＣＰＵ１１と、ＲＯＭ１２と、ＲＡＭ１３と、無線通信Ｉ／Ｆ１４と、接続Ｉ／Ｆ１５と、操作パネル１６と、ＮＦＣＩ／Ｆ１７とを備えている。そして、上記各構成は、内部バス１０を介して相互に接続されている。ここで、ＣＰＵ１１、ＲＯＭ１２、ＲＡＭ１３、無線通信Ｉ／Ｆ１４、接続Ｉ／Ｆ１５、および操作パネル１６の機能および構成は第１の実施形態と同様である。

ＮＦＣＩ／Ｆ１７は、近距離無線通信の一例であるＮＦＣによる接続のための通信インターフェースであり、通信路９０を介して本体８００と通信を行う。

通信路９０は、操作デバイス７００と本体８００との間でＮＦＣなどの近距離無線通信を行うものである。通信路９０が第２の通信路の一例である。通信路６０によりソフトウェア通信が実施できないような通信異常が発生した場合、操作デバイス７００と本体８００との間で、通信路９０ＮＦＣを介して通信を実施する。

また、図１１に示すように、本体８００は、ＣＰＵ２１と、ＲＯＭ２２と、ＲＡＭ２３と、ＨＤＤ２４と、無線通信Ｉ／Ｆ２５と、接続Ｉ／Ｆ２６と、エンジン部２７と、操作パネル２８と、有線通信Ｉ／Ｆ２９と、ＮＦＣＩ／Ｆ３０とを備えている。そして、上記各構成は、内部バス２０を介して相互に接続されている。ここで、ＣＰＵ２１、ＲＯＭ２２、ＲＡＭ２３、ＨＤＤ２４、無線通信Ｉ／Ｆ２５、接続Ｉ／Ｆ２６、エンジン部２７、操作パネル２８、および有線通信Ｉ／Ｆ２９の機能および構成は第１の実施形態と同様である。

ＮＦＣＩ／Ｆ３０は、近距離無線通信の一例であるＮＦＣによる接続ための通信インターフェースであり、通信路９０を介して操作デバイス７００と通信を行う。

図１２は、第３の実施形態にかかる画像形成装置の機能ブロック図である。図１２に示す操作デバイス７００は、ＣＰＵ１１がＲＯＭ１２に格納されていたプログラムを実行することで、通信制御部７０１と、アプリケーション１０３と、通信異常検知部７１１と、異常発生原因受信部７１２と、電源管理部７１３と、表示制御部１１４とを実現する。ここで、アプリケーション１０３、および表示制御部１１４の機能および構成は、第１の実施形態と同様であるため説明を省略する。

通信制御部７０１は、接続Ｉ／Ｆ１５や、無線通信Ｉ／Ｆ１４、ＮＦＣＩ／Ｆ１７を介して、本体８００を含む他の装置との間で、情報の送受信を制御する。

通信異常検知部７１１は、本体８００との間でソフトウェア通信を実施している通信路６０（第１の通信路）で発生した通信異常を検知する。検知方法は第１の実施形態と同様である。

そして、通信異常検知部７１１は、通信路６０での通信異常を検知すると、通信路６０で通信異常が発生した旨の異常通知（異常情報）を、通信路９０（第２の通信路）によってＮＦＣを用いて本体８００に送信する。

異常発生原因受信部７１２は、通信路６０の通信に対する異常通知が本体８００に送信された後、通信路９０によって本体８００から送信された異常発生原因、または本体８００をリブートするか否かの判断結果を受信する。

電源管理部７１３は、操作デバイス７００の電源を管理する。また、電源管理部７１３は、通信路６０の異常発生原因がリブートにより画像形成装置３のリカバリが可能な所定の原因であった場合、または本体８００をリブートする旨の判断結果の場合、シャットダウンする旨のシャットダウン指示を、本体８００から通信路９０により受信する。そして、シャットダウン指示を受信すると、電源管理部７１３は、操作デバイス７００の動作抑制を行い、シャットダウンする。所定の原因については、第１の実施形態と同様である。

次に本体８００について説明する。図１２に示す本体８００は、ＣＰＵ２１がＲＯＭ２２に格納されていたプログラムを実行することで、通信制御部８０１と、画像入力部２０３と、画像出力部２０４と、通信異常受信部８１１と、異常発生原因特定部８１２と、リブート管理部８１３と、を実現する。ここで、画像入力部２０３、および画像出力部２０４の機能および構成は、第１の実施形態と同様であるため説明を省略する。

通信制御部８０１は、接続Ｉ／Ｆ２６、無線通信Ｉ／Ｆ２５、有線通信Ｉ／Ｆ２９、およびＮＦＣＩ／Ｆ３０を介して、操作デバイス７００を含む他の装置との間で、情報の送受信を制御する。

通信異常受信部８１１は、操作デバイス７００により通信路６０において通信異常の発生が検知された場合、操作デバイス７００から通信路９０を用いてＮＦＣにより送信された異常通知を受信する。なお、通信異常受信部８１１が異常取得部に相当する。

異常発生原因特定部８１２は、操作デバイス７００から異常通知を受信した場合、または通信異常受信部８１１が通信路６０における通信異常の発生を検知した場合、この通知をトリガとして通信路６０の異常発生原因を判断し特定する。異常発生原因の特定方法は、第１の実施形態と同様である。

そして、異常発生原因特定部８１２は、特定した通信路６０の異常発生原因を、通信路９０によって操作デバイス７００に送信する。また、異常発生原因特定部８１２は、異常発生原因を送信する代わりに、本体８００をリブートするか否かの判断結果を、通信路７０によって操作デバイス７００に送信してもよい。なお、異常発生原因特定部８１２が判断部に相当する。

リブート管理部８１３は、通信路６０の異常発生原因がソフトウェア異常（所定の原因の一例）であった場合、操作デバイス７００に、通信路９０を用いて近距離無線通信によってシャットダウンを行う旨のシャットダウン指示を送信する。そして、リブート管理部８１３は、操作デバイス７００のシャットダウンを検知すると、本体８００の動作抑制を行い、本体８００をリブートする。

次に、本実施形態の画像形成装置３におけるリブート処理の詳細についてシーケンス図を用いて説明する。図１３は、画像形成装置におけるリブート処理の流れを示すシーケンス図である。なお、図１３における操作デバイス７００と本体８００との通信は、通信制御部７０１と通信制御部８０１とを介して行われている（図１２参照）。

まず、操作デバイス７００の通信異常検知部７１１は、通信路６０で発生した通信異常を検知すると（ステップＳ１５０）、表示制御部１１４は、通信路６０の異常発生原因を判断中である旨を操作パネル１６に表示する（ステップＳ１５１）。

そして、通信異常検知部７１１は、通信路６０で通信異常が発生した旨の異常通知をＮＦＣＩ／Ｆ１７に送出し（ステップＳ１５２）、ＮＦＣＩ／Ｆ１７から通信路９０を用いてＮＦＣにより本体８００に送信する（ステップＳ１５３）。

次に、本体８００のＮＦＣＩ／Ｆ３０は、操作デバイス７００から異常通知を受信すると、通信異常受信部８１１に送出し（ステップＳ１５４）、通信異常受信部８１１は、異常発生原因特定部８１２に当該異常通知を送出する（ステップＳ１５５）。異常発生原因特定部８１２は、異常通知を受け取ると、通信路６０の異常発生原因（例えば、ハードウェア異常、ケーブル異常、またはソフトウェア異常）を判断し特定する（ステップＳ１５６)。

ここで、まず通信路６０の異常発生原因がリブートにより画像形成装置３のリカバリができない場合（リカバリ不可）について説明する。

異常発生原因が、例えばケーブル異常であった場合、異常発生原因特定部８１２は、リカバリ不可能である旨とケーブル異常である旨の異常発生原因をＮＦＣＩ／Ｆ３０に送出し（ステップＳ１５７）、ＮＦＣＩ／Ｆ３０から通信路９０を用いてＮＦＣにより、操作デバイス７００に送信する（ステップＳ１５８）。また、異常発生原因特定部８１２は、異常発生原因をリブート管理部８１３に送出する（ステップＳ１５９）。

操作デバイス７００のＮＦＣＩ／Ｆ１７は、本体８００から送信されたリカバリ不可能である旨と異常発生原因を受信すると、異常発生原因受信部７１２に当該異常発生原因を送出する（ステップＳ１６０）。

異常発生原因受信部７１２は、受け取った異常発生原因とリブートによるリカバリが不可能である旨を表示制御部１１４に送出すると、表示制御部１１４が操作パネル１６に表示し（ステップＳ１６１）、ユーザに知らせる。具体的には、例えば、「ケーブルが切断されています。装置のリブートではリカバリできないため、サービスへ連絡してください。」等を表示する。これによりユーザは迅速に対応できる。そして、本体８００のリブート管理部８１３は、リブートを行うことなく処理を終了する。

一方、通信路６０の異常発生原因がリブートによりリカバリできる場合（リカバリ可）について説明する。

異常発生原因が、例えばリブートによるリカバリが可能なソフトウェア異常であった場合、異常発生原因特定部８１２は、リカバリ可能である旨とソフトウェア異常である旨の異常発生原因をＮＦＣＩ／Ｆ３０に送出し（ステップＳ１６２）、ＮＦＣＩ／Ｆ３０から通信路９０を用いてＮＦＣにより、操作デバイス７００に送信する（ステップＳ１６３）。また、異常発生原因特定部８１２は、異常発生原因をリブート管理部８１３に送出する（ステップＳ１６４）。

操作デバイス７００のＮＦＣＩ／Ｆ１７は、本体８００から送信されたリカバリ可能である旨と異常発生原因を受信すると、異常発生原因受信部７１２に当該異常発生原因を送出する（ステップＳ１６５）。異常発生原因受信部７１２は、画像形成装置１をリブートする旨を操作パネル１６に表示し（ステップＳ１６６）、ユーザに知らせる。

次に、本体８００のリブート管理部８１３は、ＮＦＣＩ／Ｆ３０にシャットダウン指示を送出し（ステップＳ１６７）、ＮＦＣＩ／Ｆ３０から通信路９０を用いてＮＦＣにより、操作デバイス７００にシャットダウン指示を送信する（ステップＳ１６８）。

シャットダウン指示を受信したＮＦＣＩ／Ｆ１７は、当該シャットダウン指示を電源管理部７１３に送出し（ステップＳ１６９）、電源管理部７１３は、操作デバイス７００の動作抑制を行い（ステップＳ１７０）、シャットダウンを行う（ステップＳ１７１）。

一方、リブート管理部８１３は、本体８００の動作抑制を行い（ステップＳ１７２）、操作デバイス７００のシャットダウンを検知すると（ステップＳ１７３）、本体８００のリブートを実施する（ステップＳ１７４）。

その後、画像形成装置３が起動されると、操作デバイス７００と本体８００とは正常に通信が可能、すなわち、通信路６０によるソフトウェア通信が可能となる。従って、リブート管理部８１３は、通信路６０を用いてソフトウェア信号により、リブートした旨を操作デバイス７００に送信し、表示制御部１１４は、リブートした旨を操作パネル１６に表示する（ステップＳ１７５）。その後、画像形成装置１において画像形成等の各種処理が実行できる。

このように、第３の実施形態の画像形成装置３では、操作デバイス７００と本体８００との間でソフトウェア信号を用いて通信を行う通信路６０で通信異常が発生した場合、通信路９０によりＮＦＣ（近距離無線通信）を用いて、操作デバイス７００から通信異常が発生した旨の異常通知を本体８００に送信する。本体８００は、異常発生原因を特定して、通信路９０により操作デバイス７００に送信する。当該異常発生原因が、画像形成装置３のリブートによりリカバリが可能である場合、本体８００は操作デバイス７００をシャットダウンさせ、本体８００のリブートを実施する。このように、本体８００と操作デバイス７００が独立した画像形成装置３において、本体８００と操作デバイス７００との間で通信異常が発生した場合であっても、正常な状態にリカバリできる。また、ＮＦＣなどの近距離無線通信により通信を行うことで、送受信する種別が増加しても、ハードウェア信号による通信のようにバラ線を追加する必要がないため、利便性が向上する。

（第３の実施形態の変形例）
第３の実施形態の画像形成装置では、通信路の異常発生原因がソフトウェア異常などのリカバリ可能な原因であった場合は、操作デバイスをシャットダウンして、本体のリブートを実施していた。これに対し、本変形例では、通信路の異常発生原因がソフトウェア異常などのリカバリ可能な原因であった場合、かつ所定の条件を満たしている場合に操作デバイスをシャットダウンして、本体のリブートを実施するものである。

本実施形態の画像形成装置３のハードウェア構成は、第３の実施形態と同様である（図１１参照）。以下では、画像形成装置３の機能構成について、追加する機能のみを図１２を参照して説明する。

操作デバイス７００の電源管理部７１３は、第３の実施形態の機能に加え、異常発生原因受信部７１２によって異常発生原因を受信するとタイマによる計時を開始する。そして、電源管理部７１３は、通信路６０の異常発生原因がソフトウェア異常などのリカバリが可能な所定の原因であった場合でも、異常発生原因を受信した後、予め定めた所定時間（例えば、１分）が経過してもシャットダウン指示を受信しなかった場合、操作デバイス７００をシャットダウンしない。この所定時間が第１の所定時間に相当する。

操作デバイス７００の表示制御部１１４は、第３の実施形態の機能に加え、リブートによりリカバリが可能な通信路６０の異常発生原因を受信した場合、リブートを試みる旨を表示する。表示制御部１１４は、異常発生原因を受信した後所定時間が経過し、電源管理部７１３によって操作デバイス７００がシャットダウンされなかった場合、画像形成装置３がリブートを実施できる条件（リブート条件）を満たしていない旨を操作パネル１６に表示する。

本体８００のリブート管理部８１３は、通信路６０の異常発生原因がソフトウェア異常などのリカバリ可能な異常発生原因であった場合でも、前回のリブートの実施から所定期間内（例えば２４時間以内）であった場合は、操作デバイス７００にシャットダウン指示を送信せず、本体８００のリブートを実施しない。

次に、本実施形態の画像形成装置３におけるリブート処理の詳細についてシーケンス図を用いて説明する。図１４は、画像形成装置におけるリブート処理の流れを示すシーケンス図である。図１４では、通信異常に対するリブートによるリカバリ処理（図１３のステップＳ１４０～１４６、ステップＳ１５２～１６５）の後、２４時間以内に通信異常を検知した場合の流れであって、リブートを実施しない場合について示している。なお、図１４における操作デバイス７００と本体８００との通信は、通信制御部７０１と通信制御部８０１とを介して行われている（図１２参照）。

通信路６０の通信異常の検知から、異常発生原因の特定までの処理（ステップＳ１８０～１８６）は、第３の実施形態と同様であるため説明を省略する（ステップＳ１４０～１４６参照）。

通信路６０の異常発生原因が例えばソフトウェア異常であった場合、異常発生原因特定部８１２は、ソフトウェア異常である旨の異常発生原因をＮＦＣＩ／Ｆ３０に送出し（ステップＳ１８７）、ＮＦＣＩ／Ｆ３０から通信路９０を用いてＮＦＣにより、操作デバイス７００に送信する（ステップＳ１８８）。また、異常発生原因特定部８１２は、異常発生原因をリブート管理部８１３に送出する（ステップＳ１８９）。リブート管理部８１３は、前回のリブートの実施から２４時間以内（所定期間内）であった場合は、操作デバイス７００にシャットダウン指示を送信せず、本体８００のリブートを実施しない。

操作デバイス７００のＮＦＣＩ／Ｆ１７は、本体８００から送信された異常発生原因を受信すると、異常発生原因受信部７１２に当該異常発生原因を送出する（ステップＳ１９０）。表示制御部１１４は、画像形成装置３のリブートを試みる旨を操作パネル１６に表示し（ステップＳ１９１）、ユーザに知らせる。

そして、異常発生原因受信部７１２は、異常発生原因を電源管理部７１３に送出する（ステップＳ１９２）。異常発生原因を受け取った電源管理部７１３は、タイマによる計時を開始する（ステップＳ１９３）。

電源管理部７１３は、通信路６０の異常発生原因がソフトウェア異常などのリカバリが可能な所定の原因であった場合でも、異常発生原因を受信した後、所定時間（例えば１分）が経過して計時が完了してもシャットダウン指示を受信しなかった場合（ステップＳ１９４）、操作デバイス７００をシャットダウンしない。

そうすると、表示制御部１１４は、画像形成装置３がリブート条件を満たしていない旨を操作パネル１６に表示する（ステップＳ１９５）。このとき、表示制御部１１４は、「手動での電源ＯＦＦの実施してください」等の表示をしてもよい。これにより、画像形成装置３がユーザの意に反してシャットダウンしてしまうという不信感を与えることを回避できる。

このように、第３の実施形態の変形例の画像形成装置３では、操作デバイス７００と本体８００との間でソフトウェア信号を用いて通信を行う通信路６０で通信異常が発生した場合、通信路９０によりＮＦＣを用いて、操作デバイス７００から通信異常が発生した旨の異常通知を本体８００に送信する。本体８００は、通信路６０の異常発生原因を特定して、通信路９０により操作デバイス７００に送信する。当該異常発生原因が、画像形成装置３のリブートによりリカバリが可能である場合で、かつ前回のリブートの実施から所定期間（例えば２４時間）以内でない場合、本体８００は操作デバイス７００をシャットダウンさせ、本体８００のリブートを実施する。このように、本体８００と操作デバイス７００が独立した画像形成装置３において、本体８００と操作デバイス７００との間で通信異常が発生した場合であっても、正常な状態にリカバリできる。また、前回のリブートの実施から所定期間内である場合にはリブートを実施しないため、リブートしてもリカバリできなかった場合でも連続してリブートを実施してしまうことを回避することができる。

（第４の実施形態）
第１の実施形態の画像形成装置は、操作デバイスと本体との間でソフトウェア信号を送受信する通信、およびハードウェア信号を送受信する通信を用いる構成となっていた。これに対して、本実施形態の画像形成装置では、操作デバイスと本体との間でソフトウェア信号を送受信する通信、および近距離無線通信を用いる構成となっている。

さらに、第１の実施形態の画像形成装置では、バラ線によるハードウェア信号を用いているため、異常発生原因の種別が増えてしまうと、画像形成装置と操作デバイスを接続するバラ線の本数が増えてしまう。しかし、近距離無線通信を用いた場合、通信の種別が増えてもバラ線の追加が不要である。そこで、本実施形態の画像形成装置では、操作デバイスと本体との間で通信を行う際の情報量を増加させた例を示す。以下では、一例として、本体の機種およびバージョンが、操作デバイスによるサポート可能な機種およびバージョンであるかを判断した上でリブート処理を行うか否かを判断する。

第４の実施形態にかかる画像形成装置のハードウェア構成図は、第３の実施形態と同様である（図１１参照）。

図１５は、第４の実施形態にかかる画像形成装置の機能ブロック図である。図１５に示す操作デバイス９００は、ＣＰＵ１１がＲＯＭ１２に格納されていたプログラムを実行することで、通信制御部７０１と、アプリケーション１０３と、通信異常検知部９１１と、異常発生原因受信部９１２と、電源管理部７１３と、表示制御部１１４とを実現する。また、操作デバイス９００は、対応情報記憶部９０１を備えている。ここで、アプリケーション１０３、表示制御部１１４の機能および構成は第１の実施形態と同様であり、通信制御部７０１、電源管理部７１３の機能および構成は第３の実施形態と同様であるため説明を省略する。

対応情報記憶部９０１は、例えばＲＯＭ１２などで実現され、操作デバイス９００がサポート対応可能な装置の機種およびバージョンを示す対応情報を保存している。なお、対応情報とは、例えば、表１に示すテーブルデータである。

通信異常検知部９１１は、本体１０００との間でソフトウェア通信を実施している通信路６０（第１の通信路）で発生した通信異常を検知する。検知方法は第１の実施形態と同様である。

そして、通信異常検知部９１１は、通信路６０での通信異常を検知すると、対応情報記憶部９０１から対応情報を取得し、通信路６０で異常が発生した旨の異常通知と取得した対応情報とを通信路９０によってＮＦＣを用いて本体１０００に送信する。

異常発生原因受信部９１２は、通信路６０の通信に対する異常通知が本体１０００に送信された後、通信路９０によって本体１０００から送信された異常発生原因を受信する。このとき、上述の対応情報に保存された操作デバイス９００がサポート対応可能な装置の機種およびバージョンに本体１０００が含まれていない場合、その旨も異常発生原因に含まれる。

次に本体１０００について説明する。図１５に示す本体１０００は、ＣＰＵ２１がＲＯＭ２２に格納されていたプログラムを実行することで、通信制御部８０１と、画像入力部２０３と、画像出力部２０４と、通信異常受信部１０１１と、異常発生原因特定部１０１２と、リブート管理部１０１３とを実現する。また、本体１０００は、本体情報記憶部１００１を備えている。ここで、画像入力部２０３、および画像出力部２０４の機能および構成は第１の実施形態と同様であり、通信制御部８０１は第３の実施形態と同様であるため説明を省略する。

本体情報記憶部１００１は、例えばＲＯＭ２２やＨＤＤ２４などで実現され、本体１０００の機種およびバージョンである本体情報を保存している。本体情報記憶部１００１が記憶部に相当する。なお、本体情報とは、例えば表２に示すテーブルデータである。

通信異常受信部１０１１は、操作デバイス９００により通信路６０において通信異常の発生が検知された場合、操作デバイス９００から通信路９０を用いてＮＦＣにより送信された異常通知および対応情報を受信する。なお、通信異常受信部１０１１が異常取得部および対応情報取得部に相当する。

異常発生原因特定部１０１２は、操作デバイス９００から異常通知および対応情報を受信した場合、この通知をトリガとして通信路６０の異常発生原因を判断し特定する。異常発生原因の特定方法は、第１の実施形態における方法に加え、以下の特定方法がある。

異常発生原因特定部１０１２は、異常通知と対応情報を受信した場合、本体情報記憶部１００１から本体情報を取得し、受信した対応情報と取得した本体情報とから、操作デバイス９００がサポート対応可能な装置に本体１０００が含まれているか否かによって、異常発生原因を特定する。すなわち、サポート対応可能な装置に本体１０００が含まれていない場合は、本体１０００が非サポート機種、バージョン（非サポート機種および非サポートバージョン）である旨の異常発生原因となり、サポート対応可能な装置に本体１０００が含まれていない場合は異常発生原因とはならない。

そして、異常発生原因特定部１０１２は、特定した異常発生原因を、通信路９０によって操作デバイス７００に送信する。なお、異常発生原因特定部１０１２が判断部に相当する。

リブート管理部１０１３は、通信路６０の異常発生原因がソフトウェア異常（所定の原因の一例）であった場合、操作デバイス９００に、通信路９０を用いて近距離無線通信によってシャットダウンを行う旨のシャットダウン指示を送信する。そして、リブート管理部１０１３は、操作デバイス９００のシャットダウンを検知すると、本体１０００の動作抑制を行い、本体１０００をリブートする。

リブート管理部１０１３は、異常発生原因が、操作デバイス９００がサポート対応可能な装置に本体１０００が含まれていない旨である場合、シャットダウン指示を送信せず、本体１０００をリブートしない。

次に、本実施形態の画像形成装置４におけるリブート処理の詳細についてシーケンス図を用いて説明する。図１６は、画像形成装置におけるリブート処理の流れを示すシーケンス図である。なお、図１６における操作デバイス９００と本体１０００との通信は、通信制御部７０１と通信制御部８０１とを介して行われている（図１５参照）。

まず、操作デバイス９００の通信異常検知部９１１は、通信路６０で発生した通信異常を検知すると（ステップＳ２１０）、対応情報記憶部９０１から対応情報を取得する（ステップＳ２１１）。表示制御部１１４は、通信路６０の異常発生原因を判断中である旨を操作パネル１６に表示する（ステップＳ２１２）。

そして、通信異常検知部９１１は、通信路６０で通信異常が発生した旨の異常通知および取得した対応情報をＮＦＣＩ／Ｆ１７に送出し（ステップＳ２１３）、ＮＦＣＩ／Ｆ１７から通信路９０を用いてＮＦＣにより本体１０００に送信する（ステップＳ２１４）。

次に、本体１０００のＮＦＣＩ／Ｆ３０は、操作デバイス９００から異常通知および対応情報を受信すると、通信異常受信部１０１１に送出し（ステップＳ２１５）、通信異常受信部１０１１は、異常発生原因特定部１０１２に当該異常通知および対応情報を送出する（ステップＳ２１６）。

異常発生原因特定部１０１２は、異常通知および対応情報を受け取ると、本体情報記憶部１００１から本体１０００の本体情報を取得する（ステップＳ２１７）。異常発生原因特定部１０１２は、通信路６０の異常発生原因（例えば、ハードウェア異常、ケーブル異常、ソフトウェア異常、または操作デバイス９００によるサポート対応可能な装置に本体１０００が含まれていない旨）を判断し特定する（ステップＳ２１８）。

ここで、まず通信路６０の異常発生原因が操作デバイス９００によるサポート対応可能な装置に本体１０００が含まれていない場合、すなわち、本体１０００が非サポート機種、バージョンである場合（リカバリ不可）について説明する。

異常発生原因が、例えば本体１０００が操作デバイス９００によるサポート対応可能な装置でない場合、異常発生原因特定部１０１２は、リカバリ不可能である旨と、本体１０００が非サポート機種、バージョンである旨の異常発生原因をＮＦＣＩ／Ｆ３０に送出し（ステップＳ２１９）、ＮＦＣＩ／Ｆ３０から通信路９０を用いてＮＦＣにより、操作デバイス９００に送信する（ステップＳ２２０）。また、異常発生原因特定部１０１２は、異常発生原因をリブート管理部１０１３に送出する（ステップＳ２２１）。

操作デバイス９００のＮＦＣＩ／Ｆ１７は、本体１０００から送信されたリカバリ不可能である旨と異常発生原因を受信すると、異常発生原因受信部９１２に当該異常発生原因を送出する（ステップＳ２２２）。

異常発生原因受信部９１２は、受け取った異常発生原因とリブートによるリカバリが不可能である旨を表示制御部１１４に送出すると、表示制御部１１４が操作パネル１６に表示し（ステップＳ２２３）、ユーザに知らせる。具体的には、例えば、「本体がサポート要件を満たしていないため、装置のリブートではリカバリできません。」等のエラー情報を表示すれば、ユーザは迅速に対応できる。例えば、エラー情報を見たユーザは、すぐに操作デバイスを本体向けの機種およびバージョンに更新することができる。そして、本体１０００のリブート管理部１０１３は、リブートを行うことなく処理を終了する。

一方、通信路６０の異常発生原因がリブートによりリカバリできる場合（リカバリ可）について（ステップＳ２２４～２３７）の処理は、第３の実施形態と同様である（図１３のステップＳ１５２～１６５）。

また、上述した図１６の処理では、本体が操作デバイスによるサポート対応可能な装置であるか否かによっても異常発生原因を特定する構成となっていたが、これは、本体１０００および操作デバイス９００に電源が入っていることが前提である。以下では、画像形成装置の本体電源が入っていない場合でも、ＮＦＣタグから所定情報を読み取ることで、操作デバイス９００側で本体１０００の状態を判断するものである。

具体的には、リブート管理部１０１３が、本体１０００で実行された処理に関する情報である処理情報を、ＮＦＣＩ／Ｆ３０のＮＦＣタグに書き込む。処理情報には、異常発生原因も含まれている。ここで、処理情報として含まれる異常発生原因とは、例えば、本体１０００において発生した異常の原因であって本体１０００が緊急シャットダウンすることになった原因である。そして、通信異常検知部９１１は、通信異常を検知した後に本体１０００からシャットダウン指示を受信しない場合、ＮＦＣタグから処理情報を取得する。すなわち、異常検知部９１１が、処理情報取得部の一例である。そして、表示制御部１１４は、取得した処理情報を操作パネル１６に表示することで、ユーザに画像形成装置４の状態を知らせる。

図１７は、画像形成装置における処理情報の表示処理の流れを示すシーケンス図である。なお、図１７における操作デバイス９００と本体１０００との通信は、通信制御部７０１と通信制御部８０１とを介して行われている（図１５参照）。

リブート管理部１０１３は、本体１０００側の異常により緊急シャットダウン（異常発生原因）を検知すると（ステップＳ２６０）、ＮＦＣＩ／Ｆ３０のＮＦＣタグに、緊急シャットダウンした旨の処理情報を書き込む（ステップＳ２６１）。そしてリブート管理部１０１３は、本体１０００をシャットダウンする（ステップＳ２６２）。

そして、操作デバイス９００側の通信異常検知部９１１は、通信路６０の通信異常を検知した場合（ステップＳ２６３）、表示制御部１１４は、通信路６０の異常発生原因を判断中である旨を操作パネル１６に表示する（ステップＳ２６４）。

操作デバイス９００は本体１０００の電源信号であるハードウェア信号等により本体１０００の電源が入っていないことを検知すると、通信異常検知部９１１は、ＮＦＣＩ／Ｆ１７を介して本体１０００のＮＦＣタグ読み込みを実施し、処理情報として、本体がシャットダウンしている旨を取得する（ステップＳ２６５、２６６）。

通信異常検知部９１１は、取得した処理情報を表示制御部１１４に送出すると、表示制御部１１４は、処理情報を操作パネル１６に表示する（ステップＳ２６７）。この後、操作デバイス９００は自動でシャットダウンしてもよいし、ユーザに操作デバイス９００のシャットダウンを促すダイアログを表示してもよい。

図１７の処理が適用されるケースとしては、本体１０００が緊急シャットダウンの処理すら実施できないような場合である。例えば、本体１０００の処理が突然止まってしまうようなケースにも対応するためには、本体１０００にて処理の開始と処理の終わりに、ＮＦＣタグを更新するようにしておく。例えば、ＨＷ割り込みの開始時にＮＦＣタグを「ＨＷ割り込み処理中」と書き込みをしておき、ＨＷ割り込み処理の終わりに「操作デバイスからの通信異常判断受付中」と更新しておく。このようにしておくと、操作デバイス９００にて通信異常が発生したときに、本体１０００のＮＦＣタグから取得する情報で、処理を変更することができる。すなわち、操作デバイス９００側で通信異常発生を検知した際に、本体１０００の電源が入っていない場合でも、本体１０００のＮＦＣタグより「ＨＷ割り込み処理中」等の情報が得られる可能性がある。

このように、第４の実施形態の画像形成装置４では、操作デバイス９００と本体１０００との間でソフトウェア信号を用いて通信を行う通信路６０で通信異常が発生した場合、通信路９０によりＮＦＣ（近距離無線通信）を用いて、操作デバイス９００から通信異常が発生した旨の異常通知と、操作デバイス９００がサポート対応可能な装置の情報である対応情報とを本体１０００に送信する。本体１０００は、異常発生原因を特定して、通信路９０により操作デバイス９００に送信する。このとき、本体１０００は、対応情報と、記憶されている本体情報とからも異常発生原因を特定する。当該異常発生原因が、画像形成装置４のリブートによりリカバリが可能である場合、本体１０００は操作デバイス９００をシャットダウンさせ、本体１０００のリブートを実施する。一方、本体１０００は、対応情報が示すサポート対応可能な装置に本体１０００が含まれていない場合は、リカバリ不可である異常発生原因として特定し、リブートを実施しない。このように、本体１０００と操作デバイス９００が独立した画像形成装置３において、本体１０００と操作デバイス９００との間で通信異常が発生した場合であっても、正常な状態にリカバリできる。

また、第４の実施形態の画像形成装置４では、なんらかの異常が発生したことによって本体１０００の電源が入っていない場合でも、ＮＦＣタグに書き込まれた本体１０００の処理情報を取得することで、操作デバイス９００側で本体１０００側の状態（異常等）を把握することができる。

以上により、本発明の好ましい情報処理装置にかかる実施の形態について説明したが、本発明は、上述した実施の形態に制限されるものではない。また、本発明は、特許請求の範囲に照らし、種々に変形または変更することが可能である。

例えば、上記の実施形態では、異常発生原因特定部２１２がハードウェア異常、ケーブル異常、ソフトウェア異常のいずれが異常発生原因であるかを判断し特定する場合について説明したが、これに限定されない。例えば、異常発生原因特定部２１２は、ハードウェア異常とケーブル異常のいずれかのみを特定してもよい。すなわち、ハードウェア異常が発生していないと判断した場合、ケーブル異常が発生しているか否かを判定せずに、ソフトウェア異常が異常発生原因であると判断して画像形成装置１をリブートさせてもよい。また、ケーブル異常が発生していないと判断した場合、ハードウェア異常が発生しているか否かを判定せずに、ソフトウェア異常が異常発生原因であると判断して画像形成装置１をリブートさせてもよい。これにより、異常発生原因の特定を簡略化させることができる。

また、上記の実施形態では、通信異常検知部、異常発生原因受信部、電源管理部、表示制御部、通信制御部を備える装置を外部装置として、通信異常受信部、異常発生原因特定部、リブート管理部を備える装置を情報処理装置とした。このとき、操作デバイス１００を外部装置とした場合には、本体２００を情報処理装置とすることができる。ただし、情報処理装置と外部装置の組み合わせはこれに限定されず、操作デバイス１００を情報処理装置として、本体２００を外部装置とすることができる。

また、上記の実施形態では、本発明の一実施形態にかかる情報処理装置として、画像形成装置１を例にして説明したが、これに限定されない。つまり、それぞれが独立したＯＳを備えた２以上のデバイスを備えた装置またはシステムであれば、どのような情報処理装置および情報処理システムであってもよい。以下では、本実施形態にかかる情報処理装置として、画像形成装置以外の装置へ適用した場合について説明する。

（第５の実施形態）
図１８は、第５の実施形態にかかる車載装置２０００のハードウェア構成図である。本実施形態にかかる情報処理装置は、車両に搭載された車載装置２０００である。ここで、車両とは、駆動輪と内燃機関を備えた自動車である。図１８に示すように、車載装置２０００は、ナビゲーション装置１１００と、オーディオ装置１２００、ゲートウェイＥＣＵ１３００（Electronic Control Unit）、ゲートウェイＥＣＵ１３００に接続されるＥＣＵ群１４００を備えている。また、ナビゲーション装置１１００は、携帯端末１５００と通信路８０００及び通信路７０００を介して接続されてもよい。なお、ナビゲーション装置１１００、オーディオ装置１２００、ゲートウェイＥＣＵ１３００、携帯端末１５００は、それぞれ別々のＯＳで互いに独立して動作する。

ナビゲーション装置１１００は、車両の走行案内を行う装置であり、例えばＧＰＳ（Global Positiong System）機能を備え、地図データを用いて車両の走行案内を行うことができる。また、ナビゲーション装置１１００としては、ナビゲーションソフトウェアを導入することにより作動するものが用いられる。更に、ナビゲーション装置１１００は、各種アプリケーションをインストールすることで、種々の機能を提供することができる。

ナビゲーション装置１１００は、ユーザの操作に応じた入力を受け付けることができ、オーディオ装置１２００、ゲートウェイＥＣＵ１３００、ＥＣＵ群１４００、携帯端末１５００などの操作又はこれらから取得した情報の表示を行うための専用デバイスとする。しかしながら、本実施形態は、専用デバイスに制限するものではなく、例えば、ユーザが所有するスマートフォンやタブレット端末であっても良い。

図１８に示すように、ナビゲーション装置１１００は、ＣＰＵ１１０２と、ＲＯＭ１１０３と、ＲＡＭ１１０４と、無線通信Ｉ／Ｆ１１０５と、操作パネル１１０６と、ＧＰＳ受信機１１０７と、第１接続Ｉ／Ｆ１１０８と、第２接続Ｉ／Ｆ１１０９とを備えている。そして、上記各構成は、内部バス１１０１を介して相互に接続されている。

ＣＰＵ１１０２は、ナビゲーション装置１１００の全体的な制御を行う。ＣＰＵ１１０２は、ＲＡＭ１１０４を作業領域として、ＲＯＭ１１０３等に格納されたプログラムを実行する。これにより、ＣＰＵ１１０２は、ユーザ操作に応じて各種機能を実現する。なお、ＲＯＭ１１０３に加えて、ＨＤＤなどの記憶手段を更に備えてもよい。ＲＯＭ１１０３又はＨＤＤなどの記憶手段には、地図などの車両の走行に必要な情報が記憶することができ、ＣＰＵ１１０２は地図などの情報を参照することができる。

無線通信Ｉ／Ｆ１１０５は、無線による接続のためのインターフェースとし、無線通信ネットワーク５０と接続する。無線通信ネットワーク５０は、無線ＬＡＮ等とする。

第１接続Ｉ／Ｆ１１０８は、例えば、有線で接続するためのインターフェースであって、通信路６０００および通信路７０００を介してオーディオ装置１２００及びゲートウェイＥＣＵ１３００と通信を行う。通信路６０００および通信路７０００は、例えば、ＣＡＮなどの車載ＬＡＮにより電気的に接続されるが、Ether通信など、他の接続手法を用いてもよい。

通信路６０００は、ナビゲーション装置１１００とオーディオ装置１２００及びゲートウェイＥＣＵ１３００との間でソフトウェア信号を送受信するものであって、第１の通信路の一例である。通常、ナビゲーション装置１１００とオーディオ装置１２００及びゲートウェイＥＣＵ１３００は、通信路６０００を利用してソフトウェア通信を実施している。なお、通信路６０００は、信号線によって通信可能に接続されていても良いし、無線通信によって接続されていても良い。

通信路７０００は、ナビゲーション装置１１００とオーディオ装置１２００及びゲートウェイＥＣＵ１３００との間でハードウェア信号を送受信するものであって、第２の通信路の一例である。通信路６０００によりソフトウェア通信が実施できないような通信異常が発生した場合、ナビゲーション装置１１００とオーディオ装置１２００及びゲートウェイＥＣＵ１３００との間で通信路７０００を利用してハードウェア通信を実施する。具体的に例えば、通信路７０００は、ナビゲーション装置１１００からオーディオ装置１２００又はゲートウェイＥＣＵ１３００に通信異常を検知した旨をハードウェア信号により通知したり、オーディオ装置１２００又はゲートウェイＥＣＵ１３００からナビゲーション装置１１００に対して電源ＯＦＦ（オフ）などの指令等をハードウェア信号により通知する。ただし、通信路７０００の通信方式はこれに限定されず、通信路６０００とは別の通信路であれば良い。例えば、ソフトウェア信号を送受信する信号線であっても良いし、複数の信号線によって構成されていても良い。更に、ハードウェア信号を送受信する信号線と、ソフトウェア信号線を送受信する信号線を組み合わせて構成されても良い。また、通信路７０００は、信号線によって通信可能に接続されていても良いし、無線通信によって接続されていても良い。

第２接続Ｉ／Ｆ１１０９は、例えば、有線で接続するインターフェースであって、通信路８０００および通信路７０００を介して携帯端末１５００と通信を行う。通信路８０００および通信路７０００は、例えば、ＵＳＢ接続用のケーブルを用いることが考えられるが、他の接続手法を用いてもよい。

通信路８０００は、ナビゲーション装置１１００と携帯端末１５００との間でソフトウェア信号を送受信するものであって、第１の通信路の一例である。通常、ナビゲーション装置１１００と携帯端末１５００は、通信路８０００を利用してソフトウェア通信を実施している。なお、通信路８０００は、信号線によって通信可能に接続されていても良いし、無線通信によって接続されていても良い。

操作パネル１１０６は、タッチスクリーンやハードウェアキー等を有する。タッチスクリーンは、例えば、タッチパネル機能を搭載した液晶表示装置（ＬＣＤ：Liquid Crystal Display）や有機ＥＬ（Electro Luminescence）表示装置とすることが考えられる。操作パネル１１０６が表示部の一例である。なお、ユーザによる操作を受け付ける入力部と、ユーザに対して情報を表示する表示部は、別に設けることができる。ここで、入力部としては、キーボード、マウス、音声入力に対応したマイク、ジェスチャー入力に対応したカメラを備えても良い。更に、操作パネルは、ユーザに対して機器の状態などを通知するためにスピーカを設けても良い。

ＧＰＳ受信機１１０７は、ＧＰＳ衛星からの信号を受信することで、車両の現在位置を検出することができる。なお、地磁気センサ、距離センサ、ビーコンセンサ、及びジャイロセンサなどを備えてもよい。

オーディオ装置１２００は、携帯端末１５００からナビゲーション装置１１００又はゲートウェイＥＣＵ１３００を介して送信された音楽データなどの再生や、車両の状態情報や各種情報をユーザに対して音声で出力する装置である。

図１８に示すように、オーディオ装置１２００は、ＣＰＵ１２０２と、ＲＯＭ１２０３と、ＲＡＭ１２０３と、スピーカ１２０５、外部Ｉ／Ｆ１２０６、第１接続Ｉ／Ｆ１２０７とを備えている。そして、上記各構成は、内部バス１２０１を介して相互に接続されている。

ＣＰＵ１２０２は、オーディオ装置１２００の全体的な制御を行う。ＣＰＵ１２０２は、ＲＡＭ１２０４を作業領域として、ＲＯＭ１２０３等に格納されたプログラムを実行する。これにより、ＣＰＵ１２０２は、ユーザ操作や受け付けた命令等に応じて、オーディオ機能等の各種機能を実現する。

第１接続Ｉ／Ｆ１２０７は、例えば、有線による接続のためのインターフェースであり、通信路６０００および通信路７０００を介してナビゲーション装置１１００及びゲートウェイＥＣＵ１３００と通信を行う。

外部Ｉ／Ｆ１２０６は、ＣＤ、ＤＶＤ、ＳＤカード、ＵＳＢメモリなどの音楽データを記憶した媒体を読み込む手段である。外部Ｉ／Ｆ１２０６は、携帯端末１５００から有線又は無線通信する手段であってもよい。スピーカ１２０５は、外部Ｉ／Ｆ１２０６が取得した音楽データや、ナビゲーション装置１１００から受信した情報、ゲートウェイＥＣＵ１３００を介してＥＣＵ群１４００から取得した情報などを音声として出力する手段である。

ゲートウェイＥＣＵ１３００は、車載装置２０００が備えるナビゲーション装置１１００、オーディオ装置１２００、ＥＣＵ群１４００との間の通信を調停する手段である。

図１８に示すように、ゲートウェイＥＣＵ１３００は、ＣＰＵ１３０２と、ＲＯＭ１３０３と、ＲＡＭ１３０４と、第１接続Ｉ／Ｆ１３０５と、第２接続Ｉ／Ｆ１３０６と、無線通信Ｉ／Ｆ１３０７と、第３接続Ｉ／Ｆ１３０８とを備えている。そして、上記各構成は、内部バスを介して相互に接続されている。

ＣＰＵ１３０２は、ゲートウェイＥＣＵ１３００の全体的な制御を行う。ＣＰＵ１３０２は、ＲＡＭ１３０４を作業領域として、ＲＯＭ１３０３等に格納されたプログラムを実行する。これにより、ＣＰＵ１３０２は、ユーザ操作や受け付けた命令等に応じて、ゲートウェイ機能等の各種機能を実現する。

第１接続Ｉ／Ｆ１３０５は、例えば、有線による接続のためのインターフェースであり、通信路６０００および通信路７０００を介してナビゲーション装置１１００及びオーディオ装置１２００と通信を行う。

第２接続Ｉ／Ｆ１３０６は、例えば、有線で接続するインターフェースであって、通信路８０００および通信路７０００を介して携帯端末１５００と通信を行う。通信路８０００および通信路７０００は、例えば、ＵＳＢ接続用のケーブルを用いることが考えられるが、他の接続手法を用いてもよい。

無線通信Ｉ／Ｆ１３０７は、無線による接続のためのインターフェースとし、無線通信ネットワーク５０と接続する。無線通信ネットワーク５０は、無線ＬＡＮ等とする。

第３接続Ｉ／Ｆ１３０８は、例えば、有線による接続のためのインターフェースであり、通信路６０００および通信路７０００を介してＥＣＵ群１４００と通信を行う。なお、第３接続Ｉ／Ｆ１３０８は、ＥＣＵ群１４００に応じて複数設けられてもよい。

ここで、ＥＣＵ群１４００とは、車両の制御を行う電子制御ユニットである。例えば、エンジンや操舵、ブレーキ等を制御するＥＣＵや、車両の各種状態を表示するメータやエアコン等を制御するＥＣＵなどである。これらのＥＣＵ群１４００と、ナビゲーション装置１１００及びオーディオ装置１２００は、ゲートウェイＥＣＵ１３００を介して電気的に接続されている。ＥＣＵ群１４００は、速度やアクセル開度など、車両の各部から取得した車両の状態情報をゲートウェイＥＣＵ１３００へ送信する。

ナビゲーション装置１１００は、必要に応じてゲートウェイＥＣＵ１３００を介して車両の状態情報を取得して、状態情報に基づいてユーザであるドライバに対して各種表示支援などを行うことができる。更に、ナビゲーション装置１１００は、ゲートウェイＥＣＵ１３００を介してＥＣＵ群１４００に対して制御情報を送信することで、ＥＣＵ群１４００を構成する各ＥＣＵを制御することができる。なお、ナビゲーション装置１１００は、オーディオ装置１２００に対してはゲートウェイＥＣＵ１３００を介さずに接続されているが、ゲートウェイＥＣＵ１３００を介して接続されてもよい。

携帯端末１５００は、ユーザの操作に応じた入力を受け付けることができ、ナビゲーション装置１１００、又はゲートウェイＥＣＵ１３００を介して、ナビゲーション装置１１００、オーディオ装置１２００、ＥＣＵ群１４００の操作又はこれらから取得した情報の表示を行うことができる。携帯端末１５００は、例えば、ユーザが所有するスマートフォンやタブレット端末、ノートパソコンなどである。

図１８に示すように、携帯端末１５００は、ＣＰＵ１５０２と、ＲＯＭ１５０３と、ＲＡＭ１５０４と、第２接続Ｉ／Ｆ１５０５と、操作パネル１５０６と、無線接続Ｉ／Ｆ１５０７とを備えている。そして、上記各構成は、内部バス１５０１を介して相互に接続されている。

ＣＰＵ１５０２は、外部端末の全体的な制御を行う。ＣＰＵ１５０２は、ＲＡＭ１５０４を作業領域として、ＲＯＭ１５０３等に格納されたプログラムを実行する。これにより、ＣＰＵ１５０２は、ユーザ操作や受け付けた命令等に応じて、各種機能を実現する。

第２接続Ｉ／Ｆ１５０５は、例えば、有線による接続のためのインターフェースであり、通信路６０００および通信路７０００を介してナビゲーション装置１１００と通信を行う。また、第２接続Ｉ／Ｆは、通信路６０００および通信路７０００を介してゲートウェイＥＣＵ１３００と通信を行ってもよい。

操作パネル１５０６は、タッチスクリーンやハードウェアキー等を有する。タッチスクリーンは、例えば、タッチパネル機能を搭載した液晶表示装置（ＬＣＤ：Liquid Crystal Display）や有機ＥＬ（Electro Luminescence）表示装置とすることが考えられる。操作パネル１５０６が表示部の一例である。なおユーザによる操作を受け付ける入力部と、ユーザに対して情報を表示する表示部は、別に設けることができる。ここで、入力部としては、キーボード、マウス、音声入力に対応したマイク、ジェスチャー入力に対応したカメラを備えても良い。更に、操作パネルは、ユーザに対して機器の状態などを通知するためにスピーカを設けても良い。

無線通信Ｉ／Ｆ１５０７は、無線による接続のためのインターフェースとし、無線通信ネットワーク５０と接続する。

図１８では、ナビゲーション装置１１００と、オーディオ装置１２００と、ゲートウェイ装置とを接続する通信路６０００及び通信路７０００は共通の信号経路として図示したが、通信路６０００及び通信路７０００の接続構成はこれに限定されない。例えば、通信路６０００及び通信路７０００は、デバイス毎に専用の通信路として設けてもよい。つまり、ナビゲーション装置１１００とオーディオ装置１２００とを接続する通信路６０００及び通信路７０００と、ナビゲーション装置１１００とゲートウェイＥＣＵ１３００とを接続する通信路６０００及び通信路７０００とを設けてもよい。また、通信路７０００は、一部のデバイスの間にのみ設けられてもよい。

図１９は、第４の実施形態にかかる車載装置２０００の機能ブロック図である。以下では、ナビゲーション装置１１００を外部装置の一例として、ゲートウェイＥＣＵ１３００を情報処理装置の一例として説明する。図１９に示すナビゲーション装置１１００は、ＣＰＵ１１２０がＲＯＭ１１０３に格納されたプログラムを実行することで、通信制御部１１１０と、アプリケーション１１１１と、通信異常検知部１１１２と、異常発生原因受信部１１１３と、電源管理部１１１４と、表示制御部１１１５とを実現する。ただし、複数ＣＰＵ、ＲＯＭやＲＡＭなどの複数のメモリ、その他ハードウェアが協業することで、各機能ブロックの機能を実現してもよい。

通信制御部１１１０は、第１接続Ｉ／Ｆ１１０８や、無線通信Ｉ／Ｆ１１０５を介して、オーディオ装置１２００を含む他の装置との間で、情報の送受信を制御する。

アプリケーション１１１１は、ユーザインターフェースを有し、操作パネル１１０６に対して画面の表示や、ユーザから操作パネル１１０６を介して、操作設定などを受け付ける。また、アプリケーション１１１１は、カーナビゲーション機能や、オーディオ装置１２００が有する音声再生機能等の機能を用いたサービスを提供してもよい。また、アプリケーション１１１１は、複数備えていてもよく、操作パネル１１０６のみ利用するアプリケーションや、オーディオ装置１２００やゲートウェイＥＣＵ１３００やＥＣＵ群１４００を利用するアプリケーション、さらにはこれら両方を利用するアプリケーションであってもよい。

例えば、ナビゲーション装置１１００には、ソフトウェアとして、現在位置計算プログラムや地図探索プログラム等の各種アプリケーションプログラムが搭載されており、例えば、車両の位置を検出し、検出した位置情報をユーザへ通知することができる。なお、アプリケーション１１１１は、オーディオ装置１２００、ゲートウェイＥＣＵ１３００、外部端末、ＥＣＵ群１４００などから収集された情報を参照することができる。

通信異常検知部１１１２は、ゲートウェイＥＣＵ１３００との間でソフトウェア通信を実施している通信路６０００（第１の通信路）で発生した通信異常を検知する。例えば、通信異常検知部１１１２は、通信制御部１１１０により前回信号を受信してから所定時間以上信号を受信しない場合や、予め定めた信号を送信してから所定時間以上信号を受信しない場合等に、通信異常と判別することで、通信異常を検知する。なお、通信異常の検知方法は、この方法に限られない。

そして、通信異常検知部１１１２は、通信路６０００での通信異常を検知すると、通信路６０００で通信異常が発生した旨の異常通知（異常情報）を、通信路７０００（第２の通信路）によってハードウェア信号を用いてゲートウェイＥＣＵ１３００に送信する。

異常発生原因受信部１１１３は、通信路６０００の通信に対する異常通知がゲートウェイＥＣＵ１３００に送信された後、通信路６０００の通信異常の発生原因である異常発生原因、又はゲートウェイＥＣＵ１３００をリブートするか否かの判断結果を、通信路７０００によってゲートウェイＥＣＵ１３００から受信する。

電源管理部１１１４は、ナビゲーション装置１１００の電源を管理する。また、電源管理部は、通信路６０００の異常発生原因がリブートによりゲートウェイＥＣＵ１３００のリカバリが可能な所定の原因であった場合、シャットダウンする旨のシャットダウン指示を、ゲートウェイＥＣＵ１３００から通信路７０００によって受信する。シャットダウン指示を受信すると、電源管理部１１１４は、ナビゲーション装置１１００の動作抑制を行い、シャットダウンする。このとき、電源管理部１１１４は、ナビゲーション装置１１００において動作する全てのプログラムを終了して電源を完全に切断してもよいし、次回の起動時に高速で起動するために動作状態を保存してナビゲーション装置１１００内の一部のデバイスの電源は保持してもよい。また、ゲートウェイＥＣＵ１３００がナビゲーション装置１１００へシャットダウン指示を送る場合、通信路７０００を構成する複数の信号線のうち、ソフトウェア信号を送受信する信号線を用いてもいい。なお、所定の原因とは、ゲートウェイＥＣＵ１３００のリブートにより通信路６０００の通信異常のリカバリが可能なものであって、本実施形態では例えばソフトウェア異常による異常発生原因などである。

表示制御部１１１５は、ユーザに対する各種情報を操作パネル１１０６（表示部）に表示するものである。本実施形態では、表示制御部１１１５は、ゲートウェイＥＣＵ１３００から受信した通信路６０００の異常発生原因、又は画像形成装置１をリブートするか否かの判断結果を操作パネル１１０６に表示する。また、表示制御部１１１５は、通信路６０００の異常発生原因がリブートによりゲートウェイＥＣＵ１３００のリカバリが可能な所定の原因（ソフトウェア異常等）であった場合、又はゲートウェイＥＣＵ１３００をリブートする旨の判断結果を取得した場合、ゲートウェイＥＣＵ１３００をリブートする旨を操作パネル１１０６に表示する。また、表示制御部１１１５は、ゲートウェイＥＣＵ１３００のリブートが実施された場合、リブートした旨を操作パネル１１０６に表示する。

次にゲートウェイＥＣＵ１３００について説明する。図１９に示すゲートウェイＥＣＵ１３００は、ＣＰＵ１３０２がＲＯＭ１３０３に格納されていたプログラムを実行することで、通信制御部１３１０と、通信異常受信部１３１１と、異常発生原因特定部１３１２と、リブート管理部１３１３と、を実現する。ただし、複数ＣＰＵ、ＲＯＭやＲＡＭなどの複数のメモリ、その他ハードウェアが協業することで、各機能ブロックの機能を実現してもよい。

通信制御部１３１０は、第１接続Ｉ／Ｆ１３０５を介して、ナビゲーション装置１１００を含む他の装置との間で、情報の送受信を制御する。

通信異常受信部１３１１は、ナビゲーション装置１１００により通信路６０００において通信異常の発生が検知された場合、ナビゲーション装置１１００から通信路７０００を用いてハードウェア信号により送信された異常通知（異常情報）を受信する。なお、通信異常受信部１３１１が異常取得部に相当する。なお、通信異常受信部１３１１が通信路６０００における通信異常の発生を検知してもよい。この場合、通信異常受信部１３１１は、例えば、通信制御部１３１０により前回信号を受信してから所定時間以上信号を受信しない場合や、予め定めた信号を送信してから所定時間以上信号を受信しない場合等に、通信異常が発生したと判別する。なお、通信異常の検知方法は、この方法に限られない。

異常発生原因特定部１３１２、ナビゲーション装置１１００から異常通知を受信した場合、又は、通信異常受信部１３１１が通信路６０００における通信異常の発生を検知した場合、この通知をトリガとして通信路６０００の異常発生原因を判断し特定する。ここで、通信路６０００の異常発生原因には、例えば、ハードウェア異常、ケーブル異常、またはソフトウェア異常が挙げられる。そして、異常発生原因がハードウェア異常またはケーブル異常の場合は、ゲートウェイＥＣＵ１３００をリブートしても通信異常は解消しないためリブートは実施しない。一方、異常発生原因がソフトウェア異常の場合は、ゲートウェイＥＣＵ１３００をリブートすることにより通信異常が解消する可能性があるためリブートを実施する。つまり、異常発生原因特定部１３１２は、通信異常の原因に基づいて、ゲートウェイＥＣＵ１３００をリブートするか否かを判断する。

通信路６０００の異常発生原因を特定する方法の例を説明する。例えば、異常発生原因特定部１３１２は、ＢＩＯＳ（Basic Input／Output System）が格納されている不揮発領域に委譲があるかに否かを確認する。ＢＩＯＳが正常起動するとＬＥＤが点滅するため、異常発生原因特定部１３１２は、ＬＥＤの点滅状態を確認する。そして、異常発生原因特定部１３１２は、ＬＥＤが点滅していない場合、不揮発領域の異常と判断してハードウェア異常と特定する。

また、例えば、異常発生原因特定部１３１２は、第１接続Ｉ／Ｆ１３０５である信号線の接続状態を確認して、接続デバイスが存在しているかどうかを判断する。そして、異常発生原因特定部１３１２は、接続デバイスが存在しない場合、ケーブル異常と特定する。

また、例えば、異常発生原因特定部１３１２は、ハードウェア異常およびケーブル異常でないと判断した場合、ソフトウェア異常（ソフトウェア障害）と特定する。

そして、異常発生原因特定部１３１２は、特定した通信路６０００の異常発生原因を、通信路７０００によってナビゲーション装置１１００に送信する。なお、異常発生原因特定部１３１２が判断部に相当する。なお、異常発生原因特定部１３１２は、異常発生原因を送信する代わりに、情報処理装置をリブートするか否かの判断結果を、通信路７０００によってナビゲーション装置１１００に送信してもよい。

リブート管理部１３１３は、通信路６０００の異常発生原因がソフトウェア異常（所定の原因の一例）であった場合、ナビゲーション装置１１００に、通信路７０００を用いてハードウェア信号によってシャットダウンを行う旨のシャットダウン指示を送信する。そして、リブート管理部１３１３は、ナビゲーション装置１１００のシャットダウンを検知すると、ゲートウェイＥＣＵ１３００の動作抑制を行い、ゲートウェイＥＣＵ１３００をリブートする。つまり、リブート管理部１３１３は、異常発生原因特定部１３１２がゲートウェイＥＣＵ１３００をリブートすると判断した場合、シャットダウン指示を通信路７０００によってナビゲーション装置１１００に送信し、更にゲートウェイＥＣＵ１３００をリブートする。このとき、リブート管理部１３１３は、ゲートウェイＥＣＵ１３００において動作する全てのプログラムを終了してゲートウェイＥＣＵ１３００内の全デバイスの電源を完全に切断してから起動し直すことができるが、ゲートウェイＥＣＵ１３００内の一部のデバイスの電源は保持してもよいし、ゲートウェイＥＣＵ１３００において動作する一部又は全部のソフトウェアのみを終了してから起動し直してもよい。

なお、ゲートウェイＥＣＵ１３００に対して通信路６０００及び通信路７０００を介して複数のデバイスが外部装置として接続されている場合、異常発生原因特定部１３１２は、所定の順序でデバイス毎に異常発生原因の特定を行ってもよいし、同時に行ってもよい。

また、第５の実施形態にかかる車載装置２０００におけるナビゲーション装置１１００とゲートウェイＥＣＵ１３００の処理は、第１の実施形態本にかかる操作デバイス１００と本体２００の処理と同様である。また、第５の実施形態にかかる車載装置２０００は、他の実施形態と組み合わせることができる。例えば、第２の実施形態と同様に、ナビゲーション装置１１００とゲートウェイＥＣＵ１３００との間にマイコンを設けることによって、第２の実施形態において説明した効果と同様の効果を得ることができる。また、第３及び第４の実施形態と同様に、ナビゲーション装置１１００とゲートウェイＥＣＵ１３００とにＮＦＣＩ／Ｆを設けることで、第３及び第４の実施形態において説明した効果と同様の効果を得ることができる。

以上では、通信制御部１１１０、通信異常検知部１１１２、異常発生原因受信部１１１３、電源管理部１１１４、表示制御部１１１５を備える装置を外部装置として、通信制御部１３１０、通信異常受信部１３１１、異常発生原因特定部１３１２、リブート管理部１３１３を備える装置を情報処理装置とした。このとき、ナビゲーション装置１１００を外部装置とした場合には、ゲートウェイＥＣＵ１３００、オーディオ装置１２００、携帯端末１５００を情報処理装置とすることができる。また、携帯端末１５００を外部装置とした場合には、ナビゲーション装置１１００、ゲートウェイＥＣＵ１３００を情報処理装置とすることができる。また、ＥＣＵ群１４００を構成するいずれかのＥＣＵを外部端末とした場合には、ゲートウェイＥＣＵ１３００を情報処理装置とすることができる。ただし、情報処理装置と外部装置の組み合わせはこれに限定されない。

また、本実施形態にかかる車載装置２０００において、ナビゲーション装置１１００、オーディオ装置１２００、ゲートウェイＥＣＵ１３００、ＥＣＵ群１４００を備えるものとして説明したが、車載装置２０００の構成はこれに限定されない。例えば、ナビゲーション装置１１００にオーディオ装置１２００、又はゲートウェイＥＣＵ１３００の機能の一部、又は全部を統合してもよい。また、ナビゲーション装置１１００に接続されるデバイスとして、ＤＶＤやビデオなどに記録された動画像を再生する再生装置、インターネットなどへのアクセスを制御する通信装置、他車や路側インフラや管理センタ等の車外通信設備と通信するための通信装置などを搭載してもよい。この場合、上記のデバイスのいずれかを外部装、又は情報処理装置とすることができる。

（第６の実施形態）
また、本発明にかかる実施形態は、家電機器にも適用することができる。ここで、家電機器とは、例えば、冷蔵庫、エアコン、洗濯機、電子レンジ、テレビなどである。

図１は、第１の実施形態にかかる画像形成装置１のハードウェア構成図として説明したが、第６の実施形態にかかる家電機器のハードウェア構成についても、図１を用いて説明することができる。よって、以下では図１を参照し、第６の実施形態にかかる家電機器のハードウェア構成について説明する。家電機器は、外部装置の一例である操作デバイス１００と、情報処理装置の一例である本体２００とを備えている。本発明にかかる情報処理装置は機能部２７を変更することにより、種々の家電機器に適用することができる。

例えば、情報処理装置が冷蔵庫である場合、機能部２７は、各貯蔵室内を冷却する冷却機能を実現する手段であり、例えば、圧縮機、送風ファン、ダンパなどで構成される。
また、情報処理装置が洗濯機である場合は、機能部２７は、室内空気の温度または湿度を目標値である温度および湿度に接近するように調和する空気調和機能を実現する手段であり、例えば、圧縮機、熱交換器、送風ファンなどで構成される。
また、情報処理装置が洗濯機である場合は、機能部２７は、洗い、すすぎ等の洗濯機能を実現する手段であり、例えば回転ドラム、モータなどで構成される。
また、情報処理装置が電子レンジである場合は、機能部２７は、対象物を加熱する加熱機能を実現する手段であり、例えばマグネトロン、冷却ファン、モータなどで構成される。
また、情報処理装置がテレビである場合は、機能部２７は、外部から受信した映像や音声を出力する機能を実現する手段であり、例えば、チューナ、復調装置、ディスプレイ、スピーカなどで構成される。

また、図２は、第１の実施形態にかかる画像形成装置１の機能ブロック構成図として説明したが、第６の実施形態にかかる家電機器のハードウェア構成についても、図２を用いて説明することができる。つまり、家電機器が備える操作デバイス１００は、ＣＰＵ１１がＲＯＭ１２に格納されていたプログラムを実行することで、通信制御部１０１と、アプリケーション１０３と、通信異常検知部１１１と、異常発生原因受信部１１２と、電源管理部１１３と、表示制御部１１４とを実現する。また、家電機器が備える本体２００は、ＣＰＵ２１がＲＯＭ２２に格納されていたプログラムを実行することで、通信制御部２０１と、画像入力部２０３と、画像出力部２０４と、通信異常受信部２１１と、異常発生原因特定部２１２と、リブート管理部２１３と、を実現する。各機能ブロックが実現する機能、及び処理は、第１の実施形態と同様であるため説明を省略する。ここで、第６の実施形態にかかる家電機器は、他の実施形態と組み合わせることができる。例えば、第２の実施形態と同様に、操作デバイス１００と本体２００の間にマイコンを設けることによって、第２の実施形態において説明した効果と同様の効果を得ることができる。また、第３及び第４の実施形態と同様に、操作デバイス１００と本体２００にＮＦＣＩ／Ｆを設けることで、第３及び第４の実施形態において説明した効果と同様の効果を得ることができる。

本実施形態にかかる家電機器は、上述した例に限定されず、電気炊飯器、オーブン、ＤＶＤプレイヤー、オーディオ機器、電子フォトフレームなどのような家電機器全般に適用することができる。

なお、本実施形態の画像形成装置で実行されるプログラムは、ＲＯＭ等に予め組み込まれて提供される。本実施形態の画像形成装置で実行されるプログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ－ＲＯＭ、フレキシブルディスク（ＦＤ）、ＣＤ－Ｒ、ＤＶＤ（Digital Versatile Disk）等のコンピュータで読み取り可能な記録媒体に記録して提供するように構成してもよい。

さらに、本実施形態の画像形成装置で実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、本実施形態の画像形成装置で実行されるプログラムをインターネット等のネットワーク経由で提供または配布するように構成してもよい。

本実施形態の画像形成装置で実行されるプログラムは、上述した各部（通信制御部、画像入力部、画像出力部、通信異常受信部、異常発生原因特定部、リブート管理部）を含むモジュール構成となっており、実際のハードウェアとしてはＣＰＵ（プロセッサ）が上記ＲＯＭからプログラムを読み出して実行することにより上記各部が主記憶装置上にロードされ、上記各部が主記憶装置上に生成されるようになっている。また、例えば、上述した各部の機能のうちの一部または全部が専用のハードウェア回路で実現されてもよい。

１、２、３、４ 画像形成装置
１７、３０ ＮＦＣＩ／Ｆ
５０ 無線通信ネットワーク
６０、７０、８０ａ、８０ｂ、９０、６０００、７０００、８０００ 通信路
１００、３００、７００、９００ 操作デバイス
１０１、７０１、１１１０ 通信制御部
１０３、１１１１ アプリケーション
１１１、３１１、７１１、９１１、１１１２ 通信異常検知部
１１２、３１２、７１２、９１２、１１１３ 異常発生原因受信部
１１３、３１３、７１３、１１１４ 電源管理部
１１４、１１１５ 表示制御部
２００、４００、８００、１０００ 本体
２０１、８０１、１３１０ 通信制御部
２０３ 画像入力部
２０４ 画像出力部
２１１、４１１、８１１、１０１１、１３１１ 通信異常受信部
２１２、４１２、８１２、１０１２、１３１２ 異常発生原因特定部
２１３、８１３、１０１３、１３１３ リブート管理部
５００ マイコン
５１１ 異常通知通信部
５１２ 異常発生原因通信部
５１３ 代替リブート管理部
９０１ 対応情報記憶部
１００１ 本体情報記憶部
１１００ ナビゲーション装置
１２００ オーディオ装置
１４００ ＥＣＵ群
１５００ 携帯端末
２０００ 車載装置

特許第４１８７６６８号公報

Claims (17)

1. 外部装置と第１の通信路、及び前記第１の通信路とは別に設けられる第２の通信路を介して信号を送受信する情報処理装置であって、
   前記第１の通信路における通信異常を示す異常情報を取得する異常取得部と、
   前記異常取得部が前記異常情報を取得した場合、前記情報処理装置をリブートするか否かを判断する判断部と、
   前記判断部が前記情報処理装置をリブートすると判断した場合、シャットダウン指示を前記第２の通信路によって前記外部装置に送信し、さらに前記情報処理装置をリブートするリブート管理部と、を備える、情報処理装置。
2. 前記異常取得部は、前記異常情報を前記第２の通信路を介して前記外部装置から取得する、請求項１に記載の情報処理装置。
3. 前記判断部は、前記情報処理装置をリブートするか否かを判断した場合、判断結果を前記第２の通信路を介して前記外部装置へ送信する、請求項１または２に記載の情報処理装置。
4. 前記リブート管理部は、前記判断部が前記情報処理装置をリブートすると判断した場合でも、前回のリブートの実施から所定期間内であった場合は、前記シャットダウン指示を送信せず、前記情報処理装置をリブートしない、請求項３に記載の情報処理装置。
5. 前記情報処理装置は、前記外部装置を備え、
   前記外部装置は、
   前記外部装置に設けられた表示部の表示を制御する表示制御部と、
   前記シャットダウン指示を前記第２の通信路によって前記情報処理装置から受信した場合、前記外部装置をシャットダウンする電源管理部と、を備え、
   前記電源管理部は、前記判断部が前記情報処理装置をリブートすると判断した場合でも、前記判断結果を受信した後、予め定めた第１の所定時間が経過しても前記シャットダウン指示を受信しなかった場合、前記外部装置をシャットダウンせず、
   前記表示制御部は、前記第１の所定時間が経過し、前記外部装置がシャットダウンされなかった場合、前記情報処理装置がリブートを実施できる条件を満たしていない旨を前記表示部に表示することを特徴とする、請求項３に記載の情報処理装置。
6. 前記第２の通信路は、前記情報処理装置と前記外部装置との間でハードウェア信号を送受信する通信路を少なくとも含む、請求項１～５のいずれか一つに記載の情報処理装置。
7. 前記情報処理装置は、さらに管理装置を備え、
   前記第２の通信路は、前記管理装置を経由して前記情報処理装置と前記外部装置との間で信号を送受信し、
   前記管理装置は、
   前記第２の通信路によって、前記外部装置から前記異常情報を受信した場合、前記情報処理装置に受信した前記異常情報を送信する異常情報通信部と、
   前記第２の通信路によって、前記情報処理装置から前記判断結果を受信した場合、前記外部装置に受信した前記判断結果を送信する判断結果通信部と、を備える請求項１～６のいずれか一つに記載の情報処理装置。
8. 前記管理装置は、
   前記異常情報を前記情報処理装置に送信した後、予め定めた第２の所定時間が経過しても前記判断結果を前記情報処理装置から受信しなかった場合、前記第２の通信路によって前記外部装置に前記シャットダウン指示を送信し、さらに前記情報処理装置をリブートする代替リブート管理部をさらに備える、請求項７に記載の情報処理装置。
9. 前記第２の通信路は、前記情報処理装置と前記外部装置との間で近距離無線通信を行う、請求項１～５のいずれか一つに記載の情報処理装置。
10. 前記情報処理装置は、
    前記第１の通信路において前記通信異常が発生した場合、前記外部装置が対応可能な装置の情報を示す対応情報を前記外部装置から前記第２の通信路によって取得する対応情報取得部と、
    前記情報処理装置の情報を示す装置情報を記憶する記憶部と、をさらに備え、
    前記判断部は、前記対応情報取得部が前記対応情報を取得した場合、前記対応情報と前記装置情報とから前記外部装置が対応可能な装置に前記情報処理装置が含まれているか否かを判断し、
    前記リブート管理部は、前記外部装置が対応可能な装置に前記情報処理装置が含まれていない場合、前記シャットダウン指示を送信せず、前記情報処理装置をリブートしない、請求項９に記載の情報処理装置。
11. 前記対応情報は、前記外部装置が対応可能な装置の機種およびバージョンであって、
    前記装置情報は、前記情報処理装置の機種およびバージョンである、請求項１０に記載の情報処理装置。
12. 前記情報処理装置は、
    前記第２の通信路を用いて前記近距離無線通信を行う通信インターフェースをさらに備え、
    前記リブート管理部は、前記情報処理装置で実行された処理に関する情報である処理情報を、前記通信インターフェースが有するタグに書き込む、請求項１１に記載の情報処理装置。
13. 前記情報処理装置は、前記外部装置を備え、
    前記外部装置は、
    前記通信異常を検知した後に前記シャットダウン指示を受信しない場合、前記タグから前記処理情報を取得する処理情報取得部を備える、請求項１２に記載の情報処理装置。
14. 前記タグは、ＮＦＣ（Near Field Communication）タグであって、
    前記処理情報は、前記情報処理装置で発生した異常発生原因を含む、請求項１２に記載の情報処理装置。
15. 前記判断部は、前記第１の通信路における前記通信異常の原因が、ソフトウェア異常であると判断した場合に、前記情報処理装置をリブートすると判断する、請求項１～１４のいずれか一つに記載の情報処理装置。
16. 前記第１の通信路は、信号を送受信する通信線を含み、
    前記判断部は、前記異常取得部が前記異常情報を取得した場合、前記判断部は前記通信線の接続状態を判定し、前記接続状態に異常がなければ、前記情報処理装置をリブートすると判断する、請求項１～１５のいずれか一つに記載の情報処理装置。
17. 外部装置と第１の通信路を介して信号を送受信し、前記第１の通信路とは別に設けられた第２の通信路によって前記外部装置との間で信号を送受信するコンピュータに、
    前記第１の通信路における通信異常を示す異常情報を取得する異常取得ステップと、
    前記異常情報を取得した場合、前記コンピュータをリブートするか否かを判断する判断ステップと、
    前記コンピュータをリブートすると判断した場合、シャットダウン指示を前記第２の通信路によって前記外部装置に送信し、さらに前記コンピュータをリブートするリブート管理ステップと、を実行させるためのプログラム。

Images