(57)【要約】【課題】  格納領域の増大を抑制しながら、ソフトウェアの更新失敗に対するリカバリ機能を実現する情報処理装置を提供する。【解決手段】  情報処理装置は、複数のソフトウェアで共用される共通モジュールと、前記ソフトウェアそれぞれに固有の固有モジュールとを格納するプログラム格納部と、前記プログラム格納部から、指定されたソフトウェアに必要な共通モジュール及び固有モジュールを読み出すモジュール読出し部とを有する。また、情報処理装置は、自身のリカバリ機能が含まれたソフトウェアを構成する複数のモジュールを、既定のプログラム記録領域に書き込み、前記プログラム記録領域に書き込まれたモジュールのうち、異常がある異常モジュールを特定し、特定された異常モジュールに応じて、互いに異なるリカバリ手順で、リカバリ処理する。【選択図】図３
2019128608.tif 000002
【特許請求の範囲】
【請求項１】
複数のソフトウェアで共用される共通モジュールと、前記ソフトウェアそれぞれに固有の固有モジュールとを格納するプログラム格納部と、
前記プログラム格納部から、指定されたソフトウェアに必要な共通モジュール及び固有モジュールを読み出すモジュール読出し部と
を有する情報処理装置。
【請求項２】
自身のリカバリ機能が含まれたソフトウェアを構成する複数のモジュールを格納するプログラム格納部と、
前記プログラム格納部に格納されているモジュールのうち、異常がある異常モジュールを特定する異常特定部と、
前記異常特定部により特定された異常モジュールに応じて、互いに異なるリカバリ手順で、リカバリ処理するリカバリ処理部と
を有する情報処理装置。
【請求項３】
前記情報処理装置は、スキャナ装置に内蔵されており、
前記ソフトウェアは、前記スキャナ装置のファームウェアである
請求項１又は２に記載の情報処理装置。
【請求項４】
前記複数のソフトウェアは、ソフトウェアのリカバリ機能を実現するソフトウェアと、リカバリ機能とは異なる機能を実現するソフトウェアとを含む
請求項１に記載の情報処理装置。
【請求項５】
前記プログラム格納部は、少なくとも、有線通信のモジュールと、無線通信のモジュールとを格納しており、
前記リカバリ処理部は、前記異常特定部により、有線通信のモジュール及び無線通信のモジュールのいずれか一方が異常モジュールであると判断した場合に、他方のモジュールを用いて、リカバリ処理を実行する
請求項２に記載の情報処理装置。
【請求項６】
複数のソフトウェアで共用される共通モジュールと、前記ソフトウェアそれぞれに固有の固有モジュールとを既定のプログラム記録領域に書き込む書込みステップと、
前記プログラム記録領域から、指定されたソフトウェアに必要な共通モジュール及び固有モジュールを読み出すモジュール読出しステップと
を有する情報処理方法。
【請求項７】
自身のリカバリ機能が含まれたソフトウェアを構成する複数のモジュールを、既定のプログラム記録領域に書き込む書込みステップと、
前記プログラム記録領域に書き込まれたモジュールのうち、異常がある異常モジュールを特定する異常特定ステップと、
前記異常特定ステップにより特定された異常モジュールに応じて、互いに異なるリカバリ手順で、リカバリ処理するリカバリ処理ステップと
を有する情報処理方法。
【請求項８】
複数のソフトウェアで共用される共通モジュールと、前記ソフトウェアそれぞれに固有の固有モジュールとを既定のプログラム記録領域に書き込む書込みステップと、
前記プログラム記録領域から、指定されたソフトウェアに必要な共通モジュール及び固有モジュールを読み出すモジュール読出しステップと
をコンピュータに実行させるプログラム。
【請求項９】
自身のリカバリ機能が含まれたソフトウェアを構成する複数のモジュールを、既定のプログラム記録領域に書き込む書込みステップと、
前記プログラム記録領域に書き込まれたモジュールのうち、異常がある異常モジュールを特定する異常特定ステップと、
前記異常特定ステップにより特定された異常モジュールに応じて、互いに異なるリカバリ手順で、リカバリ処理するリカバリ処理ステップと
をコンピュータに実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、情報処理方法、及びプログラムに関するものである。
【背景技術】
【０００２】
例えば、特許文献１には、応用ファームウェアの更新時における起動・初期化エラー情報を、メモリ内のエラー情報格納領域に格納しておき、応用ファームウェアを更新する都度、基本ファームウェアのみを優先的に起動・初期化した状態で前記エラー情報を参照し、前回更新時のエラー情報があればこれをクリアして応用ファームウェアの再更新を可能にするリカバリ方法が開示されている。
また、特許文献２には、複数のファームウェアを含む情報処理装置であって、前記複数のファームウェアのうち、何れかのファームウェアを用いて情報処理装置を起動する起動手段と、前記起動手段によって前記情報処理装置の起動に用いた前記ファームウェアとは異なるファームウェアを更新する更新手段と、前記ファームウェアの更新中にエラーが発生すると、現在起動しているファームウェアとは異なるファームウェアを用いて前記起動手段によって前記情報処理装置を再起動させ、前記更新手段によって再起動に用いたファームウェアとは異なるファームウェアを更新させる制御手段とを備える情報処理装置が開示されている。
また、特許文献３には、記録媒体に画像を形成する画像形成手段を備えた画像形成装置であって、当該画像形成装置を制御する制御手段が実行するソフトウェアを保存するソフトウェア保存手段と、前記制御手段に前記ソフトウェアのアップデートを実行させるアップデート用ソフトウェアと前記制御手段に前記ソフトウェアのアップデートに失敗した場合に当該画像形成装置を前記アップデートが可能な状態に復帰させる復帰処理を実行させる復帰用ソフトウェアとを含むアップデートソフトウェアを受信する受信手段と、前記アップデート用ソフトウェアを保存するアップデート用ソフトウェア保存手段と、前記復帰用ソフトウェアを保存する復帰用ソフトウェア保存手段と、前記復帰用ソフトウェアのバックアップ用の復帰用ソフトウェアバックアップ保存手段と、前記受信手段によって受信した前記アップデートソフトウェアの前記アップデート用ソフトウェアと前記復帰用ソフトウェアとを判別する判別手段と、前記判別手段によって判別された前記アップデート用ソフトウェアを前記アップデート用ソフトウェア保存手段に保存し、前記判別手段によって判別された前記復帰用ソフトウェアを前記復帰用ソフトウェア保存手段と前記復帰用ソフトウェアバックアップ保存手段にそれぞれ保存する保存制御手段とを有することを特徴とする画像形成装置が開示されている。
また、特許文献４には、通信手段として、論理層を有する通信プロトコルを用いる第１通信手段と、論理層を有しない通信プロトコルを用いる第２通信手段とを備え、第１及び第２検査手段の検査結果に基づき制御プログラムに異常が発見され、第１通信プログラムに異常が発見されなかった場合は、第１ダウンロード手段は、第１通信プログラムの動作に基づいて第１通信手段を介してホストコンピュータから制御プログラムをダウンロードし、第２ダウンロード手段は、制御プログラム及び第１通信プログラムの両方で異常が発見された場合は、第２通信プログラムの動作に基づいて第２通信手段を介してメンテナンスコンピュータから制御プログラム及び第１通信プログラムのうち少なくとも一方をダウンロードすることを特徴とする電子機器が開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００５−２４２４４６
【特許文献２】特開２０１６−０５３８３９
【特許文献３】特開２０１３−１０９４５０
【特許文献４】特開２００７−１１４８８３
【発明の概要】
【発明が解決しようとする課題】
【０００４】
格納領域の増大を抑制しながら、ソフトウェアの更新失敗に対するリカバリ機能を実現する情報処理装置を提供する。
【課題を解決するための手段】
【０００５】
本発明に係る情報処理装置は、複数のソフトウェアで共用される共通モジュールと、前記ソフトウェアそれぞれに固有の固有モジュールとを格納するプログラム格納部と、前記プログラム格納部から、指定されたソフトウェアに必要な共通モジュール及び固有モジュールを読み出すモジュール読出し部とを有する。
【０００６】
また、本発明に係る情報処理装置は、自身のリカバリ機能が含まれたソフトウェアを構成する複数のモジュールを格納するプログラム格納部と、前記プログラム格納部に格納されているモジュールのうち、異常がある異常モジュールを特定する異常特定部と、前記異常特定部により特定された異常モジュールに応じて、互いに異なるリカバリ手順で、リカバリ処理するリカバリ処理部とを有する。
【０００７】
好適には、前記情報処理装置は、スキャナ装置に内蔵されており、前記ソフトウェアは、前記スキャナ装置のファームウェアである。
【０００８】
好適には、前記複数のソフトウェアは、ソフトウェアのリカバリ機能を実現するソフトウェアと、リカバリ機能とは異なる機能を実現するソフトウェアとを含む。
【０００９】
好適には、前記プログラム格納部は、少なくとも、有線通信のモジュールと、無線通信のモジュールとを格納しており、前記リカバリ処理部は、前記異常特定部により、有線通信のモジュール及び無線通信のモジュールのいずれか一方が異常モジュールであると判断した場合に、他方のモジュールを用いて、リカバリ処理を実行する。
【００１０】
また、本発明に係る情報処理方法は、複数のソフトウェアで共用される共通モジュールと、前記ソフトウェアそれぞれに固有の固有モジュールとを既定のプログラム記録領域に書き込む書込みステップと、前記プログラム記録領域から、指定されたソフトウェアに必要な共通モジュール及び固有モジュールを読み出すモジュール読出しステップとを有する。
【００１１】
また、本発明に係る情報処理方法は、自身のリカバリ機能が含まれたソフトウェアを構成する複数のモジュールを、既定のプログラム記録領域に書き込む書込みステップと、前記プログラム記録領域に書き込まれたモジュールのうち、異常がある異常モジュールを特定する異常特定ステップと、前記異常特定ステップにより特定された異常モジュールに応じて、互いに異なるリカバリ手順で、リカバリ処理するリカバリ処理ステップとを有する。
【００１２】
また、本発明に係るプログラムは、複数のソフトウェアで共用される共通モジュールと、前記ソフトウェアそれぞれに固有の固有モジュールとを既定のプログラム記録領域に書き込む書込みステップと、前記プログラム記録領域から、指定されたソフトウェアに必要な共通モジュール及び固有モジュールを読み出すモジュール読出しステップとをコンピュータに実行させる。
【００１３】
また、本発明に係るプログラムは、自身のリカバリ機能が含まれたソフトウェアを構成する複数のモジュールを、既定のプログラム記録領域に書き込む書込みステップと、前記プログラム記録領域に書き込まれたモジュールのうち、異常がある異常モジュールを特定する異常特定ステップと、前記異常特定ステップにより特定された異常モジュールに応じて、互いに異なるリカバリ手順で、リカバリ処理するリカバリ処理ステップとをコンピュータに実行させる。
【発明の効果】
【００１４】
格納領域の増大を抑制しながら、ソフトウェアの更新失敗に対するリカバリ機能を実現する。
【図面の簡単な説明】
【００１５】
【図１】ファームウェアの更新を行う更新処理システム１の全体構成を例示する図である。
【図２】スキャナ装置３００のハードウェア構成及びソフトウェア構成を例示する図である。
【図３】（Ａ）は、ファームウェアのモジュール構成を例示する図であり、（Ｂ）は、フラッシュＲＯＭ上のモジュールサイズと、メモリにロードされた際にモジュールサイズを説明する図である。
【図４】スキャナ装置３００のファーム更新処理（Ｓ１０）を説明するフローチャートである。
【図５】第１のＣＰＵ４００（ＣＰＵ＃１）による処理（Ｓ２０）を説明するフローチャートである。
【図６】第２のＣＰＵ４０２（ＣＰＵ＃２）による処理（Ｓ３０）を説明するフローチャートである。
【図７】（Ａ）は、正常状態におけるファーム更新処理の手順を例示する図であり、（Ｂ）は、異常ファームに対応するリカバリ処理を例示する図である。
【図８】（Ａ）は、ケース１におけるリカバリ処理の手順を例示し、（Ｂ）は、ケース２におけるリカバリ処理の手順を例示する。
【図９】（Ａ）は、ケース３におけるリカバリ処理の手順を例示し、（Ｂ）は、ケース４におけるリカバリ処理の手順を例示する。
【図１０】異常モジュールとリカバリ処理の関係を説明する図である。
【発明を実施するための形態】
【００１６】
（背景と概要）
オペレーティングシステム搭載のスキャナ装置等では、機能拡張や障害修正のためのプログラム更新を行う機能を実装しており、ＵＳＢなどの有線接続でのプログラム更新に加えて、Ｗｉ−Ｆｉなどの無線接続によるプログラム更新も可能である。
しかしながら、無線接続によるプログラム更新は、外部環境の影響を受けやすく、データ転送中の通信切断により更新が失敗するリスクが、有線接続に比べて高い。
このため、無線接続によるプログラム更新が失敗した場合のリカバリ方法として、有線接続によるブートファームでの再実行に切換える方式が考えられる（比較例１）。
また、パーソナルコンピュータ無しでの運用を重視した場合、無線接続でのリカバリを行う必要があり、メインプログラムを２世代分保持する仕組みとすることも考えられる（比較例２）。この場合、プログラム更新は、版数の古い方または、異常検出した方のプログラムを対象に更新処理を実施することとし、世代切り替えも更新処理が正常に完了した後に実施することで、失敗が複数回発生してもプログラム更新を可能とした。
【００１７】
加えて、タッチパネル搭載によるＵＩ（ユーザインタフェース）の充実などにより、プログラムサイズが従来に比べ肥大化している。このプログラムサイズの肥大化は、プログラムを格納するフラッシュＲＯＭなどの格納領域の容量を増加させるとともに、プログラムのロード時間が長くなることで、装置が使用可能状態になるまでの時間が延びることになる。
なお、装置起動時間の短縮方法として、ハイバネーション機能（動作中のメモリ状態をまるごと退避・復元する仕組み）を利用することもできるが、これは通常プログラムとは別の専用の格納域が新たに必要となる。
このように、プログラムを格納するフラッシュＲＯＭなどの容量が増大している。
【００１８】
そこで、本実施形態では、複数のソフトウェアで共用される共通モジュールと、各ソフトウェアに固有の固有モジュールとでソフトウェアを構成することにより、プログラム記録領域の必要容量を抑制する。
また、本実施形態では、異常があるモジュール（以下、異常モジュール）に応じて、互いに異なるリカバリ方法を準備することにより、比較例２のように、プログラムを２世代分保持することなく、ファームウェアの更新失敗のリカバリを実現する。
【００１９】
（実施形態）
図１は、ファームウェアの更新を行う更新処理システム１の全体構成を例示する図である。なお、本実施形態では、ソフトウェアの更新処理の一例として、スキャナ装置３００のファームウェアを更新する場合を具体例として説明する。
図１に例示するように、更新処理システム１は、スキャナ装置３００と、無線ルータ８０２と、コンピュータ８０４と、更新配布サーバ９とを有する。
更新配布サーバ９は、ソフトウェアを更新するための更新ファイルを配布するサーバ装置である。本例の更新配布サーバ９は、ネットワーク８００に接続しており、スキャナ装置３００のファームウェアを更新するための更新ファイルを配布する。
スキャナ装置３００は、無線ルータ８０２を介して、ネットワーク８００に無線通信で接続し、更新配布サーバ９から更新ファイルを受信する。また、スキャナ装置３００は、ネットワーク８００に接続したコンピュータ８０４に対して、ＵＳＢケーブルなどの通信ケーブル８０６を介して有線接続し、コンピュータ８０４を介して、更新配布サーバ９から更新ファイルを受信する。
ネットワーク８００は、インターネットでもよいし、ローカルエリアネットワーク（ＬＡＮ）であってもよい。
【００２０】
図２は、スキャナ装置３００のハードウェア構成及びソフトウェア構成を例示する図である。本図のハードウェア構成は、スキャナ装置３００に内蔵された情報処理装置であり、本発明に係る情報処理装置の一例である。
図２に例示するように、スキャナ装置３００は、第１のＣＰＵ４００（ＣＰＵ＃１）と、第２のＣＰＵ４０２（ＣＰＵ＃２）と、第１のフラッシュＲＯＭ４０４（フラッシュＲＯＭ＃１）と、第２のフラッシュＲＯＭ４０６（フラッシュＲＯＭ＃２）と、メモリ４０８とを有し、これらの構成がバス４１０を介して互いに接続している。
第１のＣＰＵ４００（ＣＰＵ＃１）及び第２のＣＰＵ４０２（ＣＰＵ＃２）は、例えば、中央演算装置である。本例では、第１のＣＰＵ４００（ＣＰＵ＃１）は、スキャナ処理に割り当てられており、第２のＣＰＵ４０２（ＣＰＵ＃２）は、アプリ処理に割り当てられている。
第１のフラッシュＲＯＭ４０４（フラッシュＲＯＭ＃１）及び第２のフラッシュＲＯＭ４０６（フラッシュＲＯＭ＃２）は、不揮発性メモリであり、ファームウェアの格納領域として機能する。第２のフラッシュＲＯＭ４０６は、第１のフラッシュＲＯＭ４０４よりも、高価でアクセス速度が速いパラレルフラッシュＲＯＭであり、第２のフラッシュＲＯＭ４０６に格納されている高速起動用メインファーム６０のメモリロード時間を短縮し、起動時間の高速化が図られている。なお、第１のフラッシュＲＯＭ４０４（フラッシュＲＯＭ＃１）及び第２のフラッシュＲＯＭ４０６（フラッシュＲＯＭ＃２）は、単に「フラッシュＲＯＭ」と総称されることがある。フラッシュＲＯＭは、本発明に係るプログラム格納部の一例である。
メモリ４０８は、例えば、揮発性メモリであり、主記憶装置として機能する。メモリ４０８には、スキャン処理で読み取られた画像データが格納されることに加えて、フラッシュＲＯＭからロードされたファームウェアが格納される。
【００２１】
図２に例示するように、第１のフラッシュＲＯＭ４０４には、リカバリ専用メインファーム５０、アプリ制御メインファーム５２、アプリ制御ブートファーム５４、スキャナ制御メインファーム５６、及びスキャナ制御ブートファーム５８を構成するモジュールが格納されており、第２のフラッシュＲＯＭ４０６には、高速起動用メインファーム６０を構成するモジュールが格納されている。なお、本実施形態では、リカバリ専用メインファーム５０、アプリ制御メインファーム５２、アプリ制御ブートファーム５４、スキャナ制御メインファーム５６、スキャナ制御ブートファーム５８、及び、高速起動用メインファーム６０は、ファームウェアと総称される場合がある。
本実施形態におけるファームウェアの更新処理とは、フラッシュＲＯＭ上のファームウェアが書き換えられることであり、リカバリとは、フラッシュＲＯＭ上でファームウェアが再書き込みされることである。
【００２２】
リカバリ専用メインファーム５０は、Ｗｉ−Ｆｉでリカバリする為に必要な最低限の機能だけに絞り、サイズを小さくしたリカバリ専用のファームウェアであり、Ｗｉ−Ｆｉでのファームウェアの更新機能のみ実装している。
アプリ制御メインファーム５２は、Ｗｉ−Ｆｉ機能及びタッチパネル搭載によるアプリ制御するためのメインファームウェアである。アプリ制御メインファーム５２は、装置を停止している状態から起動され（コールドブート）、Ｗｉ−Ｆｉドライバなど各種ドライバの初期化、Ｗｉ−Ｆｉでのデータ転送やファームウェアの更新、タッチパネル搭載による動作モードの表示や設定などの機能を実現する。
【００２３】
アプリ制御ブートファーム５４は、Ｗｉ−Ｆｉやタッチパネル搭載によるアプリ制御を実現するためのブートファームである。アプリ制御ブートファーム５４は、リカバリ専用メインファーム５０、アプリ制御メインファーム５２、及び、高速起動用メインファーム６０のいずれかをメモリ４０８にロードし起動させる。
スキャナ制御メインファーム５６は、スキャナ装置３００を制御するためのメインファームであり、スキャナ装置３００のモータ制御、及び、スキャンした画像データの取り込みなどの、スキャナ動作を実現させる。
【００２４】
スキャナ制御ブートファーム５８は、スキャナ装置３００を制御するためのブートファームである。具体的には、スキャナ制御ブートファーム５８は、アプリ制御ブートファーム５４及びスキャナ制御メインファーム５６を、メモリ４０８にロードし起動させる。また、スキャナ制御ブートファーム５８は、アプリ制御メインファーム５２のチェックサムを実施する。
スキャナ制御ブートファーム５８は、アプリ制御ブートファーム５４に起動させるメインファームウェア（具体的には、リカバリ専用メインファーム５０、又は、アプリ制御メインファーム５２）を選択し、選択されたメインファームを起動させるための通知を行う。本例のスキャナ制御ブートファーム５８は、アプリ制御メインファーム５２が壊れていない場合に、アプリ制御メインファーム５２を選択して起動させ、アプリ制御メインファーム５２が壊れている場合に、リカバリ専用メインファーム５０を選択し起動させる。
【００２５】
高速起動用メインファーム６０は、Ｗｉ−Ｆｉでスキャナ装置３００を操作する為の高速起動用ファームであり、ハイバネーション機能を用いて起動し、動作中の状態に即時に復帰するため、アプリ制御メインファーム５２よりも高速に起動することができる。
【００２６】
なお、メモリ４０８へのファームロードは、ＤＭＡ転送を用いているが、高速ＤＭＡ転送をリカバリ専用メインファーム５０、アプリ制御メインファーム５２及び高速起動用メインファーム６０の転送に使用することで、ＣＰＵ＃２で動作するファームの起動時間の短縮を図る。
【００２７】
図３（Ａ）は、ファームウェアのモジュール構成を例示する図であり、図３（Ｂ）は、フラッシュＲＯＭ上のデータサイズと、メモリにロードされた際にデータサイズを説明する図である。
図３（Ａ）に例示するように、アプリ制御メインファーム５２は、共通モジュールＡ５００と、共通モジュールＢ５０２とで構成されている。共通モジュールＡ５００は、アプリ制御メインファーム５２及びリカバリ専用メインファーム５０で共用されるプログラムモジュールである。また、共通モジュールＢ５０２は、アプリ制御メインファーム５２及び高速起動用メインファーム６０で共用されるプログラムモジュールである。
リカバリ専用メインファーム５０は、共通モジュールＡと、固有モジュールＡ５０４とで構成されている。固有モジュールＡ５０４は、リカバリ専用メインファームに固有のプログラムモジュールである。
高速起動用メインファーム６０は、固有モジュールＢ５０６と、共通モジュールＢ５０２とで構成されている。固有モジュールＢ５０６は、高速起動用メインファーム６０に固有のプログラムモジュールである。
アプリ制御ブートファーム５４は、アプリ制御メインファーム５２、リカバリ専用メインファーム５０、又は、高速起動用メインファーム６０をメモリ４０８にロードする際に、必要な共通モジュール及び固有モジュールをフラッシュＲＯＭから読み出す。このときのアプリ制御ブートファーム５４は、本発明に係るモジュール読出し部の一例である。
【００２８】
図３（Ｂ）に例示するように、フラッシュＲＯＭから読み出された共通モジュール及び固有モジュールは、メモリ４０８にロードされ、これらを組み合わせて、アプリ制御メインファーム５２、リカバリ専用メインファーム５０、又は、高速起動用メインファーム６０として動作する。
共通モジュールＡ５００は、例えば、Ｌｉｎｕｘ（登録商標）カーネルであり、４ＭＢである。共通モジュールＢ５０２は、例えば、全機能のＲｏｏｔＦＳであり、５４ＭＢである。固有モジュールＡ５０４は、例えば、リカバリのみのＲｏｏｔＦＳであり、１０ＭＢである。固有モジュールＢ５０６は、例えば、Ｌｉｎｕｘ（登録商標）カーネルと、高速起動のみのＲｏｏｔＦＳであり、２１ＭＢである。
アプリ制御メインファーム５２、リカバリ専用メインファーム５０、及び、高速起動用メインファーム６０がメモリ４０８にロードされた場合には、合計で１４７ＭＢとなるが、共通モジュールと固有モジュールに整理することにより、フラッシュＲＯＭ上では８９ＭＢに抑えることができる。
【００２９】
図４は、スキャナ装置３００のファーム更新処理（Ｓ１０）を説明するフローチャートである。
図４に例示するように、ステップ１００（Ｓ１００）において、スキャナ装置３００は、無線ルータ８０２を経由して、更新配布サーバ９にアクセスして、ファームウェアの更新処理を実行する。更新されるファームウェアは、スキャナ制御ブートファーム５８を除く全ファームウェアである。
ステップ１０５（Ｓ１０５）において、スキャナ装置３００は、装置を再起動させる。
【００３０】
ステップ１１０（Ｓ１１０）において、スキャナ装置３００のスキャナ制御ブートファーム５８は、フラッシュＲＯＭの高速起動用メインファーム６０のサムチェックを行い、高速起動用メインファーム６０が正常であるか否かを判断する。このときのスキャナ制御ブートファーム５８は、本発明に係る異常特定部の一例である。
スキャナ装置３００は、高速起動用メインファーム６０が正常であると判断された場合に、Ｓ１１５の処理に移行し、高速起動用メインファーム６０が壊れていると判断された場合に、Ｓ１２０の処理に移行する。
【００３１】
ステップ１１５（Ｓ１１５）において、アプリ制御ブートファーム５４は、高速起動用メインファーム６０をフラッシュＲＯＭからメモリ４０８にロードして、処理を終了する。
ステップ１２０（Ｓ１２０）において、スキャナ制御ブートファーム５８は、フラッシュＲＯＭのアプリ制御メインファーム５２のサムチェックを行い、アプリ制御メインファーム５２が正常であるか否かを判断する。
スキャナ装置３００は、アプリ制御メインファーム５２が正常であると判断された場合に、Ｓ１２５の処理に移行し、アプリ制御メインファーム５２が壊れていると判断された場合に、Ｓ１３０の処理に移行する。
【００３２】
ステップ１２５（Ｓ１２５）において、アプリ制御ブートファーム５４は、アプリ制御メインファーム５２をフラッシュＲＯＭからメモリ４０８にロードして、Ｓ１００の処理に戻る。
【００３３】
ステップ１３０（Ｓ１３０）において、スキャナ制御ブートファーム５８は、フラッシュＲＯＭのリカバリ専用メインファーム５０のサムチェックを行い、リカバリ専用メインファーム５０が正常であるか否かを判断する。
スキャナ装置３００は、リカバリ専用メインファーム５０が正常であると判断された場合に、Ｓ１３５の処理に移行し、リカバリ専用メインファーム５０が壊れていると判断された場合に、Ｓ１４０の処理に移行する。
【００３４】
ステップ１３５（Ｓ１３５）において、アプリ制御ブートファーム５４は、リカバリ専用メインファーム５０をフラッシュＲＯＭからメモリ４０８にロードして、Ｓ１００の処理に戻る。
ステップ１４０（Ｓ１４０）において、スキャナ制御ブートファーム５８は、ＵＳＢ接続でのファーム更新処理を実行し、Ｓ１０５の処理に戻る。
【００３５】
図５は、第１のＣＰＵ４００（ＣＰＵ＃１）による処理（Ｓ２０）を説明するフローチャートである。
図５に示すように、ステップ２００（Ｓ２００）において、スキャナ制御ブートファーム５８は、各ファームウェアが起動可能であるか否かを確認する。
ステップ２０５（Ｓ２０５）において、スキャナ制御ブートファーム５８は、スキャナ制御メインファーム５６及びアプリ制御ブートファーム５４が起動可能であると判断した場合に、Ｓ２１５の処理に移行し、これ以外の場合に、Ｓ２１０の処理に移行する。
ステップ２１０（Ｓ２１０）において、スキャナ制御ブートファーム５８は、ＵＳＢ接続によるファームウェアの更新待ち状態で待機する。
【００３６】
ステップ２１５（Ｓ２１５）において、スキャナ制御ブートファーム５８は、スキャナ制御メインファーム５６と、アプリ制御ブートファーム５４とをメモリ４０８にロードする。
ステップ２２０（Ｓ２２０）において、スキャナ制御ブートファーム５８は、高速起動用メインファーム６０、アプリ制御メインファーム５２、又はリカバリ専用メインファーム５０の中から、起動させるファームを選択し、選択結果をアプリ制御ブートファーム５４に通知する。
【００３７】
ステップ２２５（Ｓ２２５）において、スキャナ制御ブートファーム５８は、ロードしたアプリ制御ブートファーム５４を起動させる。
ステップ２３０（Ｓ２３０）において、スキャナ制御ブートファーム５８は、ロードしたスキャナ制御メインファーム５６を起動させる。
【００３８】
図６は、第２のＣＰＵ４０２（ＣＰＵ＃２）による処理（Ｓ３０）を説明するフローチャートである。
図６に示すように、ステップ３００（Ｓ３００）において、アプリ制御ブートファーム５４は、スキャナ制御ブートファーム５８からの通知に応じて、高速起動用メインファーム６０、アプリ制御メインファーム５２、又はリカバリ専用メインファーム５０をメモリ４０８にロードする。
ステップ３０５（Ｓ３０５）において、アプリ制御ブートファーム５４は、ロードした高速起動用メインファーム６０、アプリ制御メインファーム５２、又はリカバリ専用メインファーム５０を起動する。
【００３９】
図７（Ａ）は、正常状態におけるファーム更新処理の手順を例示する図であり、図７（Ｂ）は、異常ファームに対応するリカバリ処理を例示する図である。
図８（Ａ）は、ケース１におけるリカバリ処理の手順を例示し、図８（Ｂ）は、ケース２におけるリカバリ処理の手順を例示する。
図９（Ａ）は、ケース３におけるリカバリ処理の手順を例示し、図９（Ｂ）は、ケース４におけるリカバリ処理の手順を例示する。
正常状態においては、図７（Ａ）に例示するように、スキャナ制御ブートファーム５８が、スキャナ制御メインファーム５６をメモリ４０８にロードして起動させ、アプリ制御ブートファーム５４をメモリ４０８にロードして起動させる。これに応じて、アプリ制御ブートファーム５４は、高速起動用メインファーム６０をメモリ４０８にロードして起動させる。
【００４０】
アプリ制御メインファーム５２及び高速起動用メインファーム６０、あるいは、スキャナ制御メインファーム５６が異常ファームである場合（ケース１）に、図８（Ａ）に例示するように、スキャナ制御ブートファーム５８は、アプリ制御ブートファーム５４をメモリ４０８にロードして起動させ、アプリ制御ブートファーム５４が、リカバリ専用メインファーム５０をメモリ４０８にロードしてリカバリ処理を実行させる。
スキャナ制御メインファーム５６及びリカバリ専用メインファーム５０、あるいは、アプリ制御ブートファーム５４が異常ファームである場合（ケース２）に、図８（Ｂ）に例示するように、スキャナ制御ブートファーム５８は、ＵＳＢ接続でのリカバリ処理を実行する。
【００４１】
リカバリ専用メインファーム５０又はアプリ制御メインファーム５２が異常ファームである場合（ケース３）に、図９（Ａ）に例示するように、スキャナ制御ブートファーム５８は、スキャナ制御メインファーム５６とアプリ制御ブートファーム５４とをメモリ４０８にロードし、このアプリ制御ブートファーム５４が高速起動用メインファーム６０をメモリ４０８にロードする。スキャナ制御メインファーム５６及び高速起動用メインファーム６０が、Ｗｉ−Ｆｉでのリカバリ処理を実行する。
高速起動用メインファーム６０が異常ファームである場合（ケース４）に、図９（Ｂ）に例示するように、スキャナ制御ブートファーム５８は、スキャナ制御メインファーム５６とアプリ制御ブートファーム５４とをメモリ４０８にロードし、このアプリ制御ブートファーム５４がアプリ制御メインファーム５２をメモリ４０８にロードする。スキャナ制御メインファーム及びアプリ制御メインファーム５２が、Ｗｉ−Ｆｉでのリカバリ処理を実行する。
このように、フラッシュＲＯＭには、互いに異なる方法でリカバリ処理を行う複数のファームウェアと、リカバリ処理以外の処理を行うファームウェアとが書き込まれている。
【００４２】
図１０は、異常モジュールとリカバリ処理の関係を説明する図である。
本実施形態では、ファームウェアを、共通モジュールまたは固有モジュールの組合せで構成しているため、共通モジュールが壊れている場合には、２つ以上のファームウェアが異常ファームとなることもある。したがって、スキャナ制御ブートファーム５８は、図１０に例示するように、ファームウェアを構成するモジュールのうち、いずれのモジュールが異常であるかに応じて、リカバリ処理の方法を切り替えているともいえる。
【００４３】
以上説明したように、本実施形態のスキャナ装置３００は、いずれのファームウェアに異常があるかに応じて、リカバリに用いるファームウェアを切り替える。例えば、アプリ制御ブートファーム５４が異常ファームである場合には、Ｗｉ−Ｆｉ機能を有するアプリ制御メインファーム５２、リカバリ専用メインファーム５０、及び高速起動用メインファーム６０をロードできないため、スキャナ制御ブートファーム５８が、ＵＳＢ接続による更新を実行する。
また、スキャナ装置３００は、共通モジュールまたは固有モジュールの組合せで複数のファームウェアを構成することによって、これらのファームウェアを格納するフラッシュＲＯＭの容量を抑制することができる。
【符号の説明】
【００４４】
１      更新処理システム
３００  スキャナ装置
５０    リカバリ専用メインファーム
５２    アプリ制御メインファーム
５４    アプリ制御ブートファーム
５６    スキャナ制御メインファーム
５８    スキャナ制御ブートファーム
６０    高速起動用メインファーム
【図１】
2019128608.tif 000003
【図２】
2019128608.tif 000004
【図３】
2019128608.tif 000005
【図４】
2019128608.tif 000006
【図５】
2019128608.tif 000007
【図６】
2019128608.tif 000008
【図７】
2019128608.tif 000009
【図８】
2019128608.tif 000010
【図９】
2019128608.tif 000011
【図１０】
2019128608.tif 000012