JP2012185800A - 機器、プログラム管理方法、プログラム管理プログラム、及び記録媒体 - Google Patents

Abstract

【課題】プログラムの起動処理が不正となる状態を適切に回避すること。
【解決手段】プログラムをインストール可能な機器であって、当該機器の起動時において、前記プログラムの起動処理を実行し、該起動処理の進行に応じて該進行状況を示す情報を前記プログラムの識別情報に関連付けて起動状態記憶手段に記録する起動管理手段を有し、前記起動管理手段は、前記起動処理の開始前の状態において、前記起動状態記憶手段に起動が完了していないことを示す情報が記録されている場合、起動対象を一部の前記プログラムに限定する。
【選択図】図３

Description

本発明は、機器、プログラム管理方法、プログラム管理プログラム、及び記録媒体に関する。

従来、画像形成装置等のように、アプリケーションプログラムを実行するためのプラットフォーム（以下、「アプリケーションプラットフォーム」という。）を備え、ユーザの利用環境に適したアプリケーションプログラムをプラグインとしてインストールすることにより、機能強化を図れるものがある（例えば、特許文献１）。以下、このようなアプリケーションプログラムを「プラグインアプリ」という。

プラグインアプリは、通常、画像形成装置の起動過程（主電源の投入時）において、アプリケーションプラットフォームによって自動的に起動される。ＰＣ（Personal Computer）等とは異なり、画像形成装置の各機能は直ちに利用可能であることが要求され、機能の利用のたびにプラグインアプリの起動操作が必要とされるのは、ユーザから敬遠されると考えられるからである。

しかしながら、このような画像形成装置を一例とする機器は、コストアップ抑制の観点等により、搭載しているメモリの容量がＰＣに比較して小さい。また、プラグインアプリ等の性能を確保するため、通常、スワップは抑制される。その結果、画像形成装置は、ＰＣに対して比較的容易にメモリ不足が発生しうる状態にある。

したがって、それまで正常に動作していた画像形成装置に対してプラグインアプリが新たにインストールされ、再起動が実行された場合に、複数のプラグインアプリの起動過程においてメモリ不足が発生し、アプリケーションプラットフォーム自体の起動に失敗してしまう可能性がある。アプリケーションプラットフォームが起動されていない状態の画像形成装置においては、プラグインアプリを利用できないだけでなく、プラグインアプリのアンインストールを実行することもできない。プラグインアプリのアンインストール機能は、アプリケーションプラットフォームに実装されているからである。斯かる状態を解消するべく、画像形成装置を再起動させたとしても、同様の現象が繰り返し発生する可能性が高く、アプリケーションプラットフォームが起動されない状態の解消が困難な状況に陥ることが考えられる。

本発明は、上記の点に鑑みてなされたものであって、プログラムの起動処理が不正となる状態を適切に回避することのできる機器、プログラム管理方法、プログラム管理プログラム、及び記録媒体の提供を目的とする。

そこで上記課題を解決するため、本発明は、プログラムをインストール可能な機器であって、当該機器の起動時において、前記プログラムの起動処理を実行し、該起動処理の進行に応じて該進行状況を示す情報を前記プログラムの識別情報に関連付けて起動状態記憶手段に記録する起動管理手段を有し、前記起動管理手段は、前記起動処理の開始前の状態において、前記起動状態記憶手段に起動が完了していないことを示す情報が記録されている場合、起動対象を一部の前記プログラムに限定する。

このような機器では、プログラムの起動処理が不正となる状態を適切に回避することができる。

本発明によれば、プログラムの起動処理が不正となる状態を適切に回避することができる。

本発明の実施の形態における画像形成装置のハードウェア構成例を示す図である。 本発明の実施の形態における画像形成装置のソフトウェア構成例を示す図である。 ＳＤＫプラットフォームの機能構成例を示す図である。 第一の実施の形態の画像形成装置の起動時に実行される処理手順の一例を説明するためのフローチャートである。 ＳＤＫアプリの起動処理の処理手順の一例を説明するためのフローチャートである。 起動状態記憶部の構成例を示す図である。 起動開始時の起動状態記憶部の状態の一例を示す図である。 第二の実施の形態の画像形成装置の起動時に実行される処理手順の一例を説明するためのフローチャートである。

以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態における画像形成装置のハードウェア構成例を示す図である。同図において、画像形成装置１０は、コントローラ１１、スキャナ１２、プリンタ１３、モデム１４、操作パネル１５、ネットワークインタフェース１６、及びＳＤカードスロット１７等のハードウェアを有する。

コントローラ１１は、ＣＰＵ１１１、ＲＡＭ１１２、ＲＯＭ１１３、ＨＤＤ１１４、及びＮＶＲＡＭ１１５等を有する。ＲＯＭ１１３には、各種のプログラムやプログラムによって利用されるデータ等が記録されている。ＲＡＭ１１２は、プログラムをロードするための記憶領域や、ロードされたプログラムのワーク領域等として用いられる。ＣＰＵ１１１は、ＲＡＭ１１２にロードされたプログラムを処理することにより、各種の機能を実現する。ＨＤＤ１１４には、プログラムやプログラムが利用する各種のデータ等が記録される。ＮＶＲＡＭ１１５には、各種の設定情報等が記録される。

スキャナ１２は、原稿より画像データを読み取るためのハードウェア（画像読取手段）である。プリンタ１３は、印刷データを印刷用紙に印刷するためのハードウェア（印刷手段）である。モデム１４は、電話回線に接続するためのハードウェアであり、ＦＡＸ通信による画像データの送受信を実行するために用いられる。操作パネル１５は、ユーザからの入力の受け付けを行うためのボタン等の入力手段や、液晶パネル等の表示手段等を備えたハードウェアである。ネットワークインタフェース１６は、ＬＡＮ等のネットワーク（有線又は無線の別は問わない。）に接続するためのハードウェアである。ＳＤカードスロット１７は、ＳＤカード８０に記録されたプログラムを読み取るために利用される。すなわち、画像形成装置１０では、ＲＯＭ１１３に記録されたプログラムだけでなく、ＳＤカード８０に記録されたプログラムもＲＡＭ１１２にロードされ、実行されうる。なお、他の記録媒体（例えば、ＣＤ−ＲＯＭ又はＵＳＢ（Universal Serial Bus）メモリ等）によってＳＤカード８０が代替されてもよい。すなわち、ＳＤカード８０の位置付けに相当する記録媒体の種類は、所定のものに限定されない。この場合、ＳＤカードスロット１７は、記録媒体の種類に応じたハードウェアによって代替されればよい。

図２は、本発明の実施の形態における画像形成装置のソフトウェア構成例を示す図である。同図において、画像形成装置１０は、標準アプリ１５１、ＳＤＫアプリ１５２、ＳＤＫプラットフォーム１５３、コントロールサービス１５４、及びＯＳ１５５等を有する。

標準アプリ１５１は、画像形成装置１０に標準的に（出荷時に予め）実装されているアプリケーションプログラムの集合である。同図では、スキャンアプリ１５１１、印刷アプリ１５１２、コピーアプリ１５１３、及びＦＡＸアプリ１５１４が例示されている。スキャンアプリ１５１１は、スキャンジョブを実行する。印刷アプリ１５１２は印刷ジョブを実行する。コピーアプリ１５１３は、コピージョブを実行する。ＦＡＸアプリ１５１４は、ＦＡＸの送信ジョブ又は受信ジョブを実行する。

コントロールサービス１５４は、各種のハードウェアリソース等を制御するための機能を上位アプリケーションプログラム等に対して提供したり、画像形成装置１０の基盤的な機能等を実行したりするソフトウェアモジュール群である。

ＳＤＫアプリ１５２は、画像形成装置１０の出荷後において、画像形成装置１０の機能拡張等を図るためのプラグインとして追加的にインストールされるアプリケーションプログラムである。したがって、ＳＤＫアプリ１５２の機能は、所定のものに限定されない。例えば、各ＳＤＫアプリ１５２は、ＳＤカード８０から又はネットワークを介して画像形成装置１０にインストールされ、ＳＤＫプラットフォーム１５３上において一つのスレッドとして起動される。

ＳＤＫプラットフォーム１５３は、ＳＤＫアプリ１５２の実行環境を実現する。各ＳＤＫアプリ１５２は、ＳＤＫプラットフォーム１５３が提供するＡＰＩ（Application Program Interface）を利用して開発される。例えば、ＳＤＫプラットフォーム１５３は、スキャン機能を利用させるためのインタフェース、印刷機能を利用させるためのインタフェース、コピー機能を利用させるためのインタフェース等をＳＤＫアプリ１５２に提供する。ＳＤＫプラットフォーム１５３のＡＰＩは公開されており、サードベンダ等によってもＳＤＫアプリ１５２は開発されうる。また、当該ＡＰＩは、異機種間において平滑化されている。したがって、ＳＤＫアプリ１５２に関して、機種に応じて異なる実装が行われる必要性は低い。なお、ＳＤＫプラットフォーム１５３は、それ自体、画像形成装置１０にインストールされるアプリケーションプログラムの一種である。例えば、ＳＤＫプラットフォーム１５３は、ＳＤカード８０から又はネットワークを介して画像形成装置１０にインストールされる。但し、ＳＤＫプラットフォーム１５３は、ＳＤＫアプリ１５２とは異なり、ＯＳ１５５上で一つのプロセスとして動作する。

ＯＳ１５５は、いわゆるＯＳ（Operating System）である。画像形成装置１０上の各ソフトウェアは、ＯＳ１５５上においてプロセス又はスレッドとして動作する。

図３は、ＳＤＫプラットフォームの機能構成例を示す図である。同図において、ＳＤＫプラットフォーム１５３は、インストール部１６１、アンインストール部１６２、起動管理部１６３、起動判定部１６４、起動順管理部１６５、メモリ状態管理部１６６、及び起動状態記憶部１６７等を含む。

インストール部１６１は、ＳＤＫアプリ１５２のインストール（追加）を実行する。インストール部１６１は、インストールに成功したＳＤＫアプリ１５２のうち、自動起動の指定がなされたＳＤＫアプリ１５２の識別子（以下、「プロダクトＩＤ」という。）を含むレコード（以下、「起動状態レコード」という。）を起動状態記憶部１６７に生成する。起動状態レコードは、当該ＳＤＫアプリ１５２の起動状態を管理するためのレコードである。インストール部１６１は、自らが生成した起動状態レコードに対して、起動状態の初期値である、「０」を記録する。

起動状態とは、ＳＤＫアプリ１５２の起動処理の進行状況を示す情報の一例である。本実施の形態において、起動状態は、起動処理の進行に応じて以下の値を取り得る。
０：インストール直後
１：初回起動中
２：起動完了
３：２回目以降の起動中
各値（０〜３）の意味については、改めて詳細に説明する。

なお、自動起動とは、画像形成装置１０の起動過程における、起動管理部１６３による自動的なＳＤＫアプリ１５２の起動形態をいう。各ＳＤＫアプリ１５２のインストール時において、起動形態に関して自動起動又は手動起動のいずれかが選択される。手動起動とは、ユーザによって任意のタイミングで操作パネル１５等を介して入力される起動指示に応じて起動される起動形態をいう。通常は、自動起動が選択される。したがって、本実施の形態では、インストールされている全てのＳＤＫアプリ１５２が、自動起動の対象とされていることとする。すなわち、以下において、インストールされている全てのＳＤＫアプリ１５２とは、インストールされており、かつ、自動起動の対象とされている全てのＳＤＫアプリ１５２を意味する。

起動状態記憶部１６７は、例えば、ＮＶＲＡＭ１１５又はＨＤＤ１１４等を用いて、画像形成装置１０にインストールされている各ＳＤＫアプリ１５２の起動状態レコードを記憶する。

アンインストール部１６２は、ＳＤＫアプリ１５２のアンインストール（削除）を実行する。アンインストール部１６２は、アンインストールされたＳＤＫアプリ１５２のプロダクトＩＤを含む起動状態レコードを、起動状態記憶部１６７より削除する。

起動管理部１６３は、画像形成装置１０の電源投入に応じた起動過程において、画像形成装置１０にインストールされている全てのＳＤＫアプリ１５２について起動処理を実行する。起動管理部１６３は、起動処理の進行に応じ、起動処理の対象とされているＳＤＫアプリ１５２の起動状態レコードを更新する。

起動判定部１６４は、起動状態記憶部１６７等を参照して、画像形成装置１０にインストールされている各ＳＤＫアプリ１５２の起動の許否（又は是非若しくは当否）を判定する。

起動順管理部１６５は、所定の場合において、ＳＤＫアプリ１５２の起動順を決定する。

メモリ状態管理部１６６は、ＳＤＫアプリ１５２の起動処理中にメモリ不足が発生した場合に、その旨を示す値（以下、「メモリ不足フラグ」という）を、例えば、ＮＶＲＡＭ１１５又はＨＤＤ１１４等に記録する。

以下、画像形成装置１０の処理手順について説明する。図４は、第一の実施の形態の画像形成装置の起動時に実行される処理手順の一例を説明するためのフローチャートである。

画像形成装置１０に電源が投入されると、画像形成装置１０は、初期化処理を開始する。初期化処理の過程（すなわち、起動時）において、ＯＳ１５５、コントロールサービス１５４、各標準アプリ１５１、ＳＤＫプラットフォーム１５３の順に、各プログラムが起動される。ＳＤＫプラットフォーム１５３は、自らの起動過程において、画像形成装置１０にインストールされている各ＳＤＫアプリ１５２を起動させる。図４は、斯かるタイミングにおける、ＳＤＫプラットフォーム１５３によるＳＤＫアプリ１５２の起動処理を説明するものである。

ステップＳ１０１において、起動管理部１６３は、メモリ不足フラグの記録の有無を確認する。後述より明らかなように、ここで確認されるメモリ不足フラグは、前回の画像形成装置１０の起動時におけるものである。

続いて、起動管理部１６３は、メモリ不足フラグの記録状態を初期化する（Ｓ１０２）。例えば、メモリ不足フラグが記録されている場合、当該メモリ不足フラグが削除される。次回の起動時において、前回（次回から見た場合の前々回）の起動時のメモリ不足フラグが有効とならないようにするためである。

続いて、起動管理部１６３は、メモリ不足フラグの有無に応じて処理を分岐させる（Ｓ１０３）。すなわち、メモリ不足フラグが記録されていない場合（Ｓ１０３でＮｏ）、起動管理部１６３は、通常の順番でＳＤＫアプリ１５２を一つ選択する（Ｓ１０４）。通常の順番とは、例えば、プロダクトＩＤの昇順である。

続いて、起動管理部１６３は、選択されたＳＤＫアプリに関して起動処理を実行する（Ｓ１０５）。ステップＳ１０４及びＳ１０５は、画像形成装置１０にインストールされている全てのＳＤＫアプリ１５２に関して繰り返し実行される（Ｓ１１０）。なお、フローチャートによれば、ステップＳ１０４及びＳ１０５は、ＳＤＫアプリ１５２ごとに直列的に（シーケンシャルに）実行されるように表現されている。しかし、全てのＳＤＫアプリ１５２の起動処理の処理時間の短縮化等を図るために、起動処理（ここでは、ステップＳ１０４及びＳ１０５をいう）ごとにスレッドが生成されてもよい。すなわち、各ＳＤＫアプリ１５２の起動処理は、並列的に実行されてもよい。

ここで、ステップＳ１０５における、ＳＤＫアプリ１５２の起動処理の詳細について説明する。

図５は、ＳＤＫアプリの起動処理の処理手順の一例を説明するためのフローチャートである。なお、起動処理の対象とされているＳＤＫアプリ１５２を、「対象アプリ」という。

ステップＳ２０１において、起動管理部１６３は、現時点において起動状態記憶部１６７に記録されている、対象アプリの起動状態を確認する。現時点における起動状態とは、対象アプリの起動前の起動状態である。すなわち、画像形成装置１０の前回の起動時等において記録された起動状態である。

図６は、起動状態記憶部の構成例を示す図である。同図において、起動状態記憶部１６７は、画像形成装置１０にインストールされているＳＤＫアプリ１５２ごとに起動状態レコードを記憶する。各起動状態レコードは、対応するＳＤＫアプリ１５２のプロダクトＩＤ及び起動状態を記憶する。同図では、各ＳＤＫアプリ１５２の起動状態は「２」又は「０」である。「２」は、正常に起動が完了したときに起動管理部１６３によって記録される値である。「０」は、正常にインストールが完了したときにインストール部１６１によって起動される値である。図６に示される内容に基づいて、各ＳＤＫアプリ１５２について、次のことが分かる。

プロダクトＩＤが「０ｘ０００５」のＳＤＫアプリ１５２は、前回の起動処理において正常に起動が完了している。プロダクトＩＤが「０ｘ０００ｆ」又は「０ｘ０００１」の二つのＳＤＫアプリ１５２は、画像形成装置１０が前回起動された際に、インストールされたＳＤＫアプリ１５２であり、自動起動は１度も実行されていない。

対象アプリの現時点の起動状態が、「０」又は「１」である場合、起動管理部１６３は、起動状態記憶部１６７における対象アプリの起動状態に、「１」を記録する（Ｓ２０２）。すなわち、この場合、対象アプリは、過去において一度も起動されていない又は起動に成功していないため、初回の起動処理の実行中（初回起動中）を示す「１」が、起動状態とされる。すなわち、「０」又は「１」は、起動実績が無いことを示す情報の一例である。

一方、対象アプリの現時点の起動状態が、「２」又は「３」である場合、起動管理部１６３は、起動状態記憶部１６７における対象アプリの起動状態に、「３」を記録する（Ｓ２０３）。すなわち、この場合、対象アプリは、過去において少なくとも一度は起動されているため、２回目以降の起動処理の実行中（初回起動中）を示す「３」が、起動状態とされる。

図７は、起動開始時の起動状態記憶部の状態の一例を示す図である。同図では、プロダクトＩＤが、「０ｘ０００５」であるＳＤＫアプリ１５２が対象アプリである例が示されている。当該ＳＤＫアプリ１５２の起動状態は、図６において「２」であった。したがって、ステップＳ２０３の実行により、「３」に更新されている。

続いて、起動管理部１６３は、対象アプリに対して起動指示を入力する（Ｓ２０４）。対象アプリは、起動指示に応じ、自らの初期化処理等を実行する。初期化処理等において、対象アプリは、必要に応じてメモリ領域（ヒープ領域）の確保等を行う。対象アプリの起動が完了すると（Ｓ２０５でＹｅｓ）、起動管理部１６３は、起動状態記憶部１６７における対象アプリの起動状態に、「２」を記録する（Ｓ２０６）。すなわち、対象アプリに関して、正常に起動処理が完了したこと（起動完了）が記録される。

なお、起動管理部１６３は、対象アプリの起動が完了したことを、例えば、起動指示に対する応答により検知することができる。起動指示に対する応答とは、対象アプリが同期的な関数又はメソッド等を介して起動指示を受け付ける場合、当該関数又はメソッド等の呼び出しからの復帰に相当する。一方、対象アプリが非同期な関数又はメソッド等を介して起動指示を受け付ける場合、対象アプリは、起動が完了し、定常状態となったタイミングにおいて、起動の完了通知を起動管理部１６３に入力すればよい。

一方、対象アプリの起動指示後であって起動完了前（つまり、対象アプリの起動中）において、メモリ不足の例外が発生した場合（Ｓ２０７でＹｅｓ）、メモリ状態管理部１６６は、メモリ不足フラグをＮＶＲＡＭ１１５又はＨＤＤ１１４等に記録する（Ｓ２０８）。

この場合、対象アプリは起動されず、図４の処理も中断される。したがって、既に起動されているＳＤＫアプリ１５２以外は起動されない。また、場合によっては、ＳＤＫプラットフォーム１５３のプロセスも終了してしまう。その場合、ＳＤＫプラットフォーム１５３上においてスレッドとして起動されている各ＳＤＫアプリ１５２も終了してしまう。いずれにおいても、ユーザは、ＳＤＫアプリ１５２を利用することはできない。なお、例外発生時において、対象アプリに関して起動状態記憶部１６７が記憶している起動状態は、「１」又は「３」である。すなわち、「１」又は「３」は、起動が完了していないことを示す一例である。

メモリ不足が発生した後に、画像形成装置１０の再起動等が実行された場合に、図４のステップＳ１０１において、メモリ不足フラグが記録されていることが確認される。

なお、メモリ状態管理部１６６がメモリ不足フラグを記録するのは、図４及び図５の処理の実行中における、強制的な電源断（停電等）による起動処理の中断と区別するためのである。すなわち、起動状態記憶部１６７を参照することにより、前回の起動時において起動処理に失敗したＳＤＫアプリ１５２の有無は確認することができる。しかし、起動状態記憶部１６７のみでは、起動処理の失敗の原因が、メモリ不足によるものなのか強制的な電源断によるものなのかは分からない。

但し、メモリ不足が発生した場合、メモリ状態管理部１６６によるメモリ不足フラグの記録もできない可能性もある。このような可能性が高い場合は、メモリ不足フラグは利用されなくてもよい。この場合、ステップＳ１０１では、起動状態記憶部１６７を参照して、前回の起動処理に失敗している（すなわち、起動状態の値が「１」又は「３」である）ＳＤＫアプリ１５２の有無を確認すればよい。該当するＳＤＫアプリ１５２が存在しない場合は、ステップＳ１０４及びＳ１０５が実行され、該当するＳＤＫアプリ１５２が存在する場合は、ステップＳ１０６〜Ｓ１０９が実行されるようにすればよい。

メモリ不足フラグが記録されていた場合（図４：Ｓ１０３でＹｅｓ）、起動順管理部１６５は、起動対象とするＳＤＫアプリ１５２を選択する（Ｓ１０６）。例えば、起動順管理部１６５は、メモリ（ヒープ）の消費量の多いＳＤＫアプリ１５２から順に起動対象を選択する。すなわち、起動時において一時的に多くのメモリを消費し、起動完了時のメモリ消費量は小さくなる（つまり、メモリの消費に関して起動時に山の有る）ＳＤＫアプリ１５２の存在も考えられる。仮に、このようなＳＤＫアプリ１５２が、既に多数のＳＤＫアプリ１５２の起動が完了し、メモリの残量が少なくなっているときに起動された場合、一時的なメモリ消費量の山を許容できるだけのメモリ残量が無いために、メモリ不足が発生することも考えられる。そこで、一時的なメモリの大量消費を許容可能な、メモリの残量が多いときに、メモリ消費量の多いＳＤＫアプリ１５２を起動させることで、メモリ不足発生回避し、全てのＳＤＫアプリ１５２を起動できる可能性を高めようというわけである。なお、起動時のメモリ消費量については、ＳＤＫアプリ１５２の開発ベンダからの申請値が、ＳＤＫアプリ１５２の属性情報として、ＳＤＫアプリ１５２のインストール時にＮＶＲＡＭ１１５又はＨＤＤ１１５に記録されればよい。又は、インストール部１６１は、インストール時等において、ＳＤＫアプリ１５２の試行的な起動（仮起動）を実行し、その際にメモリの消費量を測定し、測定結果をＮＶＲＡＭ１１５又はＨＤＤ１１５に記録してもよい。

または、起動順管理部１６５は、メモリ不足が発生した後の起動時におけるＳＤＫアプリ１５２の優先順位をＮＶＲＡＭ１１５又はＨＤＤ１１４等を用いて管理していてもよい。この場合、起動順管理部１６５は、当該優先順位の上位から順に一つのＳＤＫアプリ１５２を起動対象として選択する。

更に、起動順管理部１６５は、インストールされた順番に起動対象を選択してもよい。インストール順に起動対象が選択されることで、新たなＳＤＫアプリ１５２の起動時期を最後にすることができる。そうすることで、後述される、起動判定部１６４による判定との組合せにより、より多くのＳＤＫアプリ１５２を起動できる可能性を高めることができる。

インストールされた順番は、例えば、起動状態記憶部１６７におけるレコード順によって判定されてもよいし、ＳＤＫアプリ１５２のインストール時に、インストール部１６１によって別途インストール順を示す情報が記録され、当該情報に基づいて判定されてもよい。

なお、メモリ不足フラグが記録されていた場合（Ｓ１０３でＹｅｓ）でも、通常の起動順によってＳＤＫアプリ１５２が起動されてもよい。

続いて、起動判定部１６４は、起動順管理部１６５によって起動対象とされたＳＤＫアプリ１５２（以下「対象アプリ」という。）について、起動状態記憶部１６７を参照して、起動の許否を判定する（Ｓ１０７）。例えば、起動判定部１６４は、前回の起動処理において起動に失敗しているＳＤＫアプリ１５２については起動を許可せず、それ以外のＳＤＫアプリ１５２については起動を許可する。具体的には、対象アプリの起動状態が、「１」又は「３」である場合、起動は許可されず、それ以外の場合、起動は許可される。起動状態が「１」又は「３」であるＳＤＫアプリ１５２は、前回の起動処理において、起動中にメモリ不足が発生したＳＤＫアプリ１５２である。したがって、当該ＳＤＫアプリ１５２が起動されると再度メモリ不足が発生する可能性があるからである。

または、起動判定部１６４は、最後にインストールされたＳＤＫアプリ１５２については起動を許可せず、それ以外のＳＤＫアプリ１５２については起動を許可する。具体的には、対象アプリの起動状態が、「０」又は「１」である場合、起動は許可されず、それ以外の場合、起動は許可される。このような判定は、全てのＳＤＫアプリ１５２の起動に成功していた状態を再現しようという考えに基づく。すなわち、新たなＳＤＫアプリ１５２のインストールによってメモリ不足が発生したのであるから、当該新たなＳＤＫアプリ１５２の起動を抑止しようというものである。

起動判定部１６４によって対象アプリの起動が許可された場合（Ｓ１０８でＹｅｓ）、起動管理部１６３は、対象アプリに関して起動処理を実行する（Ｓ１０９）。当該起動処理の内容は、図５において説明した通りである。

但し、ステップＳ１０９における起動処理では、起動管理部１６３は、各ＳＤＫアプリ１５２の起動のタイミングが直列的になるように制御してもよい。すなわち、起動管理部１６３は、起動処理を実行するスレッドを並列的に動作させるのではなく、一つのＳＤＫアプリ１５２の起動処理が完了するのを待機して、次のＳＤＫアプリ１５２の起動処理を実行するようにしてもよい。起動時に多量のメモリを消費するＳＤＫアプリ１５２が複数存在した場合に各ＳＤＫアプリ１５２が並列的に起動されると、メモリの消費量のピークが重なることによるメモリ不足が発生することが考えられる。起動処理を直列的にすることにより、このような現象を回避することができる。

一方、起動判定部１６４によって対象アプリの起動が許可されない場合（Ｓ１０８でＮｏ）、対象アプリの起動処理は実行されない。

上記したステップＳ１０６からＳ１０９は、画像形成装置１０にインストールされている全てのＳＤＫアプリ１５２に関して実行される（Ｓ１１０）。なお、ステップＳ１０６からＳ１０９は、通常、前回の画像形成装置１０の起動時において、メモリ不足が発生した場合に実行される処理である。当該処理においては、上述したように、起動判定部１６４によって、メモリ不足の発生が出来るだけ回避されるように、起動対象とするＳＤＫアプリ１５２が一部のＳＤＫアプリ１５２に限定される。したがって、前回に続いてメモリ不足が発生する可能性を低減させることができる。すなわち、ＳＤＫアプリ１５２の起動処理が不正となる状態を適切に回避することができる。その結果、ＳＤＫプラットフォーム１５３が正常に起動される可能性を高めることができる。ＳＤＫプラットフォーム１５３が正常に起動されれば、ユーザ等は、アンインストール部１６２を介して、不要な又は優先度の低いＳＤＫアプリ１５２をアンインストールすることができる。そうすれば、以降においてメモリ不足が発生する可能性を低減させることができる。

なお、ステップＳ１０３でＹｅｓの場合に、起動管理部１６３は、全てのＳＤＫアプリ１５２について自動起動を行わないようにしてもよい。この場合、起動管理部１６３は、例えば、操作パネル１５に、メモリ不足が発生したことを表示し、起動対象とするＳＤＫアプリ１５２をユーザに選択させるようにしてもよい。

次に、第二の実施の形態について説明する。図８は、第二の実施の形態の画像形成装置の起動時に実行される処理手順の一例を説明するためのフローチャートである。図８の開始時点における画像形成装置１０の状態は、図４の開始時点における画像形成装置１０の状態と同様である。すなわち、図８は、ＳＤＫプラットフォーム１５３の起動過程における、ＳＤＫプラットフォーム１５３によるＳＤＫアプリ１５２の起動処理を説明するものである。

ステップＳ３０１において、起動管理部１６３は、メモリ容量の残量（ヒープ領域の残量）が、閾値以上であるか否かを判定する。閾値は、例えば、予め設定され、ＨＤＤ１１４又はＮＶＲＡＭ１１５等に記憶されていてもよい。または、ＳＤＫアプリ１５２ごとに、起動時のメモリ消費量が、ＳＤＫアプリ１５２の属性情報として、ＮＶＲＡＭ１１５又はＨＤＤ１１５に記録されている場合は、全てのＳＤＫアプリ１５２のメモリ消費量の中の最大値＋α、又は次に起動対象とされるＳＤＫアプリ１５２のメモリ消費量＋αが、閾値として、起動管理部１６３によって動的に（例えば、ステップＳ３０１の実行時において）決定されてもよい。αは、例えば、ＳＤＫプラットフォーム１５３の正常な起動に必要なメモリ容量である。各ＳＤＫアプリ１５２の起動時のメモリ消費量は、第一の実施の形態と同様に、ＳＤＫアプリ１５２の開発ベンダからの申請値であってもよいし、ＳＤＫアプリ１５２の試行的な起動（仮起動）の際の測定値であってもよい。

続いて、メモリ容量の残量が、閾値以上である場合（Ｓ３０１でＹｅｓ）、起動管理部１６３は、通常の順番でＳＤＫアプリ１５２を一つ選択する（Ｓ３０２）。通常の順番とは、例えば、プロダクトＩＤの昇順である。続いて、起動管理部１６３は、選択されたＳＤＫアプリに対して起動指示を入力する（Ｓ３０３）。

インストールされている全てのＳＤＫアプリ１５２に関して起動指示が入力されると（Ｓ３０４でＹｅｓ）、全てのＳＤＫアプリ１５２が利用可能な状態で、画像形成装置１０が起動される。

一方、各ＳＤＫアプリ１５２の起動の過程において、メモリ容量の残量が、閾値未満になったことが検出されると（Ｓ３０１でＮｏ）、起動管理部１６３は、これまでに起動された全てのＳＤＫアプリ１５２のスレッドを終了させる。その結果、これまでに起動されたＳＤＫアプリ１５２によって消費されたメモリ容量は解放され、ＳＤＫプラットフォーム１５３は、正常に起動される。続いて、起動管理部１５３は、ＳＤＫアプリ１５２を終了させたことをユーザに通知する（Ｓ３０６）。例えば、起動管理部１５３は、メモリ不足のためＳＤＫアプリ１５２の起動を行わなかったことを示すメッセージを操作パネル１５に表示させる。ユーザは、当該メッセージを参照することで、ＳＤＫアプリ１５２は起動されなかったことを確認することができる。

ＳＤＫプラットフォーム１５３が正常に起動された状態で画像形成装置１０が起動されることで、ユーザは、不要なＳＤＫアプリ１５２のアンインストールをＳＤＫプラットフォーム１５３に指示したり、自動起動の対象とされている一部のＳＤＫアプリ１５２に関して自動起動を解除するようにＳＤＫプラットフォーム１５３に指示したりすることができる。その結果、全てのＳＤＫアプリ１５２が利用できない状態で、画像形成装置１０が起動されるといった事態の再発を回避することができる。

なお、ステップＳ３０５が実行されないようにしてもよい。すなわち、それまでに起動されたＳＤＫアプリ１５２は起動されたままとされてもよい。但し、全てのＳＤＫアプリ１５２を終了させた方が、ＳＤＫプラットフォーム１５３が正常に起動される可能性を高めることができる。

また、メモリ容量の残量が閾値未満であることが検知された場合、未だ起動されていないＳＤＫアプリ１５２のうち、起動時のメモリの消費量が、閾値未満であるＳＤＫアプリ１５２に関して、起動処理が継続されてもよい。すなわち、起動時のメモリの消費量が、閾値以上であるＳＤＫアプリ１５２に関して、起動が行われないようにしてもよい。

上述したように、第二の実施の形態によれば、画像形成装置１０の再起動を行わずとも、ＳＤＫプラットフォーム１５３が正常に起動させることができる。

なお、上記各実施の形態は、プログラムをインストール可能な機器であれば、例えば、プロジェクタ、スマートフォン、携帯電話、又はデジタルカメラ等、画像形成装置１０以外の機器に適用されてもよい。

以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

１０ 画像形成装置
１１ コントローラ
１２ スキャナ
１３ プリンタ
１４ モデム
１５ 操作パネル
１６ ネットワークインタフェース
１７ ＳＤカードスロット
８０ ＳＤカード
１１１ ＣＰＵ
１１２ ＲＡＭ
１１３ ＲＯＭ
１１４ ＨＤＤ
１１５ ＮＶＲＡＭ
１５１ 標準アプリ
１５２ ＳＤＫアプリ
１５２ａ 起動状態記憶部１６７
１５３ ＳＤＫプラットフォーム
１５４ コントロールサービス
１５５ ＯＳ
１６１ インストール部
１６２ アンインストール部
１６３ 起動管理部
１６４ 起動判定部
１６５ 起動順管理部
１６６ メモリ状態管理部
１６７ 起動状態記憶部
１５１１ スキャンアプリ
１５１２ 印刷アプリ
１５１３ コピーアプリ
１５１４ ＦＡＸアプリ

特開２００８−８４３０４号公報

Claims (13)

1. プログラムをインストール可能な機器であって、
   当該機器の起動時において、前記プログラムの起動処理を実行し、該起動処理の進行に応じて該進行状況を示す情報を前記プログラムの識別情報に関連付けて起動状態記憶手段に記録する起動管理手段を有し、
   前記起動管理手段は、前記起動処理の開始前の状態において、前記起動状態記憶手段に起動が完了していないことを示す情報が記録されている場合、起動対象を一部の前記プログラムに限定する機器。
2. 前記起動管理手段は、前記起動状態記憶手段において前記起動が完了していないことを示す情報が関連付けられている前記識別情報に係る前記プログラムを起動しない請求項１記載の機器。
3. 前記起動状態記憶手段は、インストール後、前記起動管理手段によって起動されていない前記プログラムについては、起動実績が無いことを示す情報を記憶し、
   前記起動管理手段は、前記起動状態記憶手段において前記起動実績が無いことを示す情報が関連付けられている前記識別情報に係る前記プログラムを起動しない請求項１記載の機器。
4. 前記起動管理手段は、メモリ消費量の多い前記プログラムから順に起動する請求項１乃至３いずれか一項記載の機器。
5. プログラムをインストール可能な機器が、
   当該機器の起動時において、前記プログラムの起動処理を実行し、該起動処理の進行に応じて該進行状況を示す情報を前記プログラムの識別情報に関連付けて起動状態記憶手段に記録する起動手順を実行し、
   前記起動手順は、前記起動処理の開始前の状態において、前記起動状態記憶手段に起動が完了していないことを示す情報が記録されている場合、起動対象を一部の前記プログラムに限定するプログラム管理方法。
6. 前記起動手順は、前記起動状態記憶手段において前記起動が完了していないことを示す情報が関連付けられている前記識別情報に係る前記プログラムを起動しない請求項５記載のプログラム管理方法。
7. 前記起動状態記憶手段は、インストール後、前記起動手順によって起動されていない前記プログラムについては、起動実績が無いことを示す情報を記憶し、
   前記起動手順は、前記起動状態記憶手段において前記起動実績が無いことを示す情報が関連付けられている前記識別情報に係る前記プログラムを起動しない請求項５記載のプログラム管理方法。
8. 前記起動手順は、メモリ消費量の多い前記プログラムから順に起動する請求項５乃至７いずれか一項記載のプログラム管理方法。
9. プログラムをインストール可能な機器に、
   当該機器の起動時において、前記プログラムの起動処理を実行し、該起動処理の進行に応じて該進行状況を示す情報を前記プログラムの識別情報に関連付けて起動状態記憶手段に記録する起動手順を実行させ、
   前記起動手順は、前記起動処理の開始前の状態において、前記起動状態記憶手段に起動が完了していないことを示す情報が記録されている場合、起動対象を一部の前記プログラムに限定するプログラム管理プログラム。
10. 前記起動手順は、前記起動状態記憶手段において前記起動が完了していないことを示す情報が関連付けられている前記識別情報に係る前記プログラムを起動しない請求項９記載のプログラム管理プログラム。
11. 前記起動状態記憶手段は、インストール後、前記起動手順によって起動されていない前記プログラムについては、起動実績が無いことを示す情報を記憶し、
    前記起動手順は、前記起動状態記憶手段において前記起動実績が無いことを示す情報が関連付けられている前記識別情報に係る前記プログラムを起動しない請求項９記載のプログラム管理プログラム。
12. 前記起動手順は、メモリ消費量の多い前記プログラムから順に起動する請求項９乃至１１いずれか一項記載のプログラム管理プログラム。
13. 請求項９乃至１２いずれか一項記載のプログラム管理プログラムを記録したコンピュータ読み取り可能な記録媒体。

Images