JP2017004114A - 画像形成装置及びアプリケーションの削除方法 - Google Patents

Abstract

【課題】削除対象の選択を簡易化して問題の解決に結びつかないアプリケーションをできるだけ残しつつ、所望のアプリケーションを効果的に削除する画像形成装置を提供する。
【解決手段】ＯＳＧｉ拡張部は、クリア指定ファイルが存在するかどうかをチェックする。クリア指定ファイルが存在しなければＳ１１０１ＮＯ、処理を終了するＳ１１１８。クリア指定ファイルが存在していればＳ１１０１ＹＥＳ、クリア指定ファイルからバンドル指定の値を読みとり、メモリに値を確保するＳ１１０２。ＴａｒｇｅｔＡｐｐの値が、組み込みログインバンドルだった場合Ｓ１１０３ＹＥＳ、クリア指定ファイルからアクション指定の値を読みとるＳ１１０５。バンドル展開領域にインストールされているバンドルリストを取得して、各バンドルを処理対象バンドルとし、処理対象バンドルを順次変更してループ処理を行うＳ１１０６。
【選択図】図１１

Description

本発明は、例えばアプリケーションをインストール可能な画像形成装置およびアプリケーションプログラム（以下「アプリ」と略称する）の展開領域の削除方法等に関するものである。

近年、画像形成装置においては、ＪＡＶＡ（登録商標、以下省略）環境に代表されるようなアプリ動作環境が提供されている。ＪＡＶＡの持つプログラムの可搬性を利用して、拡張可能なアプリを提供する技術が提案されている。画像形成装置の機能やユーザビィリティの向上を図るために、上記ＪＡＶＡ環境などの環境下で動作するアプリを作成し、画像形成装置にインストールすることで、当該アプリにより所望の機能を実現できる。アプリプラットフォームとしては、組み込み機器向けのＪＡＶＡアプリプラットフォームである、ＯＳＧｉ（Ｏｐｅｎ Ｓｅｒｖｉｃｅｓ Ｇａｔｅｗａｙ Ｉｎｉｔｉａｔｉｖｅ）Ｓｅｒｖｉｃｅ Ｐｌａｔｆｏｒｍ（以下、ＯＳＧｉ）がある（非特許文献１）。ＯＳＧｉでは、ソフトウェアモジュールの管理単位としてバンドルを定義しており、インストール／開始／停止／更新／アンインストールからなるライフサイクルを管理するための仕様を定義している。ここで、バンドルとは、ＪＡＶＡモジュールのことを指し、本明細書においては、アプリと同義である。そのため、以後アプリのことをバンドルと表記する。このようなアプリプラットフォームは、コピー、スキャン、プリント等の組み込み機能をバンドルに提供することができる。

この画像形成装置において、バンドルに何かトラブルが発生した場合、サービスマンが記憶装置のバンドル展開領域、及びバンドルが保持しているデータを一旦削除することで、復旧を試みることが対処方法として考えられる。このとき、特許文献１に示すように、削除すべきファイルの選択を容易にして、削除する方法が提案されている。さらに、サービスマンによる削除対象のファイルの選択を不要とするために、バンドル展開領域、及びバンドルが保持しているデータを一括して全て削除する方法が考えられる。

特開平09-034755号公報

「ＯＳＧｉ Ｓｅｒｖｉｃｅ Ｐｌａｔｆｏｒｍ，Ｒｅｌｅａｓｅ４」， ｈｔｔｐ：／／ｗｗｗ．ｏｓｇｉ．ｏｒｇ／Ｄｏｗｎｌｏａｄ／Ｒｅｌｅａｓｅ４Ｖ４０， ２００５年１０月

しかしながら、後者の場合、問題とは明らかに無関係なバンドルのデータを削除してしまう可能性がある。また、後からインストールしたバンドルは、削除後に再インストールする必要があり、ユーザとしては手間が発生する、という課題があった。

本発明は上記従来例に鑑みて成されたもので、削除対象の選択を簡易化して操作性を向上させるとともに、問題の解決に結びつかないアプリケーション（或いはその展開領域）をできるだけ残しつつ、所望のアプリケーションを効果的に削除する画像形成装置及びアプリケーションの削除方法を提供することを目的とする。

上記目的を達成するために本発明は以下の構成を有する。

アプリケーションの追加および削除が可能な画像形成装置であって、
アプリケーションおよび削除するファイルを指定するための指定手段と、
前記指定手段により指定されたアプリケーションに関して、指定されたファイルを削除する削除手段とを備える。

本発明によれば、簡易な操作で効果的にアプリケーション及び削除対象を指定し、指定したアプリケーションに関する削除対象を削除することが可能となる。

画像形成装置のハードウェア構成図である。 画像形成装置のソフトウェアモジュール階層図である。 バンドルのインストールする流れを示したブロック図である。 バンドルのインストールとインストール先のバンドル展開領域について示したブロック図である。 バンドル展開領域の削除時の全体の動きを示したブロック図である。 クリアタイプの指定の為のＵＩを説明した図である。 クリア指定ファイルの記載例を示した図である。 クリア指定ファイルで指定するバンドル指定とアクション指定を説明するための表である。 クリアタイプ番号とクリア指定ファイルに記載する内容についての関連を示した表である。 クリアタイプ番号の指定から、再起動後の削除処理までを示したシーケンス図である。 ＯＳＧｉ拡張部２１１が、起動時にバンドル展開領域を削除するときのフローチャートである。 工場出荷時に行う出荷前クリアの指定の為のＵＩを説明した図である。 出荷前クリア時のクリア指定ファイルの記載例を示した図である。 出荷前クリアの対象外かどうかを指定したマニフェストを説明した図である。 出荷前クリアの指定から、再起動後の削除処理までを示したシーケンス図である。 ＯＳＧｉ拡張部２１１による、出荷前クリア時のバンドル展開領域を削除するときのフローチャートである。 フラグメントバンドルの概念図である。 フラグメントバンドルのクリア指定ファイルの記載例を示した図である。 ＯＳＧｉ拡張部２１１による、フラグメントバンドル指定時のバンドル展開領域を削除するときのフローチャートである。 バンドルＩＤ指定のクリア指定ファイルの記載例を示した図である。 バンドルの状態指定のクリア指定ファイルの記載例を示した図である。

以下、本発明を実施するための形態について図面を用いて説明する。

［実施例１］
＜画像形成装置のハードウェア構成＞
図１は、プリント機能やスキャン機能、ネットワーク通信機能などを備える画像形成装置１３０のハードウェア構成図である。図１において、コントローラ１００は画像形成装置１３０のコントローラである。コントローラ１００はスキャナ部１１３やプリンタ部１１４と電気的に接続され、一方でＬＡＮ１１６を介して外部デバイスと接続される。

ＣＰＵ１０１は、ＲＯＭ１０２に記憶された制御プログラム等に基づいて接続中の各種ハードウェアとのアクセスを統括的に制御し、またコントローラ内部で行われる各種処理についても統括的に制御する。ＲＯＭ１０２は読み出し専用の不揮発記憶領域であり、画像形成装置１３０のブートプログラム、ファームウェアなどが格納されている。ＲＡＭ１０３は、ＣＰＵ１０１が動作するためのシステムワークメモリであり、各種データを一時記憶するためのメモリである。このＲＡＭ１０３は、記憶した内容を電源ｏｆｆ後も保持可能なＦＲＡＭ（登録商標）およびＳＲＡＭ、電源ｏｆｆ後に記憶内容が消去されるＤＲＡＭなどにより構成される。ＨＤＤ１０４は不揮発記憶領域であり、システムバンドルなどを格納する。図３で説明するインストールするバンドルすなわちアプリケーションを含むファームウェアは、ＨＤＤ１０４に格納される。

操作部Ｉ／Ｆ１０５は、システムバス１１９と操作部１１８とを接続するインタフェース部である。具体的には操作部１１８に表示するデータをシステムバス１１９から受取り表示すると共に、操作部１１８からの入力情報をシステムバス１１９へ出力する。画像形成装置１３０に対するユーザの指示や情報提示は、操作部１１８を介して行う。ネットワークＩ／Ｆ１０６はＬＡＮ１１６、ＷＡＮ１１７及びシステムバス１１９に接続し、外部との情報の入出力を行う。スキャナＩ／Ｆ１０８は、スキャナ部１１３から受取った画像データに対して、補正、加工、及び編集を行う。画像形成部１０９は、画像データの方向変換、画像圧縮、伸張などを行う。プリンタＩ／Ｆ１１０は、画像形成部１０９から送られた画像データを受取り、画像形成後にプリンタ部１１４にて印刷する。

＜画像形成装置のソフトウェアモジュール＞
図２は、本発明に関係する画像形成装置１３０のソフトウェアモジュール階層図である。なお図２以降に示す各ソフトウェアはＲＯＭ１０２、もしくは、ＨＤＤ１０４に保存され、ＣＰＵ１０１にて実行される。また、実行時に使用する各種情報はＲＡＭ１０３もしくはＨＤＤ１０４に保持してソフトウェア機能間での各種情報のやりとりを行う。さらに外部機器との通信は、ネットワークＩ／Ｆ１０６を用いて通信を行う。

次に各ソフトウェアの説明をする。ソフトウェアには、まずオペレーティングシステム（ＯＳ）プラットフォーム２０１を含む。ＵＩ２０２はユーザインタフェースモジュールであり、オペレータが画像形成装置１３０に対する各種操作・設定を行う際に、装置とユーザ操作との仲介を行うモジュールである。このモジュールは、オペレータの操作に従い、後述の各種モジュールに入力情報を転送して処理の依頼、或いはデータの設定変更等を行う。設定データベース２０４は、画像形成装置１３０の設定データを取り扱うデータベースである。後で述べるクリアタイプもこのデータベースに値が保持される。このデータを管理しているのが、設定データ管理部２０３であり、各バンドルは、データの値について、この設定データ管理部２０３に対して問い合わせることで取得可能である。クリア指定ファイル生成部２０５は、メニューからクリアが実行されたときにクリア対象を示すクリア指定ファイルを生成するモジュールである。再起動制御部２０６は、再起動指令があったときに、それに対応して画像形成装置１３０の再起動を行うモジュールである。

次に、ＪＡＶＡ側の構成について述べる。ＪＡＶＡ側のソフトウェアプラットフォームは、ＪａｖａＶＭ２０７のランタイム環境として構成されており、インタプリタとしてのＪａｖａＶＭ２０７、ライブラリ２０８、フレームワーク群２０９で構成される。ライブラリ２０８は、標準のＡＰＩライブラリを含んで構成される。フレームワーク群２０９は、ＯＳＧｉ２１０を含んで構成され、このＯＳＧｉ２１０は、単一のＪａｖａＶＭ２０７に複数のバンドルを動作させる。更に、ＯＳＧｉ拡張部２１１は、このＯＳＧｉ２１０に対し必要に応じて機能を拡張可能であることを示す。このＯＳＧｉ２１０、及びＯＳＧｉ拡張部２１１は、バンドルのライフサイクルの管理やバンドル間通信機能などを提供する。

このＯＳＧｉ２１０上には、複数のシステムサービス２１２、及び組み込みログインサービス２１５がある。これらは、初回起動時に展開先フォルダがないとき、もしくは、アップデートが必要なことを示すアップデートフラグが所定の場所にあるときに、ＯＳＧｉ拡張部２１１によって、格納されているファームウェアからインストールされる。このときのインストールについては、図４で示す。

システムサービス２１２としては、複数のバンドル群を管理し、新たなバンドルの追加、更新、削除をするためのバンドル管理サービス２１４がある。バンドル管理サービス２１４は、インストール制御サービス２１３を利用して、バンドルの追加、更新、削除を行う。

組み込みログインサービス２１５としては、標準の認証として利用可能なログインバンドル２１６がインストールされている。ログインバンドル２１６は、ユーザがログイン中に任意のバンドルから任意のタイミングでログイン情報の問い合わせがあるため、停止できない特性を持つバンドルである。仮にログインバンドル２１６が停止していた場合、ログイン情報の取得ができなくなるため、ログイン情報に紐づくデータを利用しているようなバンドルがあると、データの取得に失敗し動作に支障が生じる。ここで、ログイン情報とは、現在画像形成装置１３０にログインしているユーザのログイン名やメールアドレスなどの情報を指す。前記のように停止できない特性を持つため、画像形成装置１３０が起動中において、このログインバンドル２１６は、必ず１つだけ動作するものとなる。

一方で、後からインストールするタイプの後入れバンドル２１７がある。バンドルのインストールについては、図３で示す。後入れバンドル２１７として、一般バンドル２１９は、画像形成装置１３０において各種処理をユーザに提供する追加的なアプリケーションである。例えば、画像の加工や圧縮バンドル、印刷制限などの部門管理を行うバンドルなどがある。また、標準のログインバンドル２１６にとって代わる、後入れログインバンドル２１８をインストールすることも可能である。

各種機能を実現する一般バンドル２１９、及び後入れのログインバンドル２１８は、このバンドル管理サービス２１４の管理下で動作する。バンドル管理サービス２１４は、管理下に追加されたバンドルのバージョンを含むバンドル情報、ライセンス情報などを保持している。

＜バンドルのインストール＞
図３は、ユーザが、ＰＣ３００から画像形成装置１３０へ、バンドルをインストールする流れを示したブロック図である。ＰＣ３００のＷＥＢブラウザにアプリケーションインストールＵＩ（ユーザインタフェース）３０１を表示し、このアプリケーションインストールＵＩ３０１からインストールしたいバンドルを指定し、インストールを行う。アプリケーションインストールＵＩ３０１で指定されたバンドルを受信したバンドル管理サービス２１４は、それをインストール制御サービス２１３に渡す。バンドルファイルを受信したインストール制御サービス２１３は、ＯＳＧｉ２１０にインストールを依頼し、ＯＳＧｉ２１０は指定されたバンドルのインストールを行う。インストールされたバンドルは、バンドル管理サービス２１４によって管理される。

＜バンドル展開領域の例＞
図４は、画像形成装置１３０における、ＯＳＧｉ拡張部２１１によるファームウェアからバンドル展開領域４０２へのシステムサービス２１２と組み込みログインサービス２１５のインストールの流れと展開後のバンドル展開領域について示したブロック図である。バンドル展開領域４０２には、展開先フォルダ４０３が存在する。ただし、この展開先フォルダ４０３は、通常初回起動時にＯＳＧｉ拡張部２１１によって作成される。ＯＳＧｉ拡張部２１１は、初回起動時で展開先フォルダ４０３が存在しないことや所定の場所にアップデートフラグが存在することを検知した場合、ファームウェア４０１に格納されているシステムサービス２１２、及び組み込みログインサービス２１５をバンドル展開領域４０２にある展開先フォルダ４０３にインストールを行う。これにより、ＯＳＧｉ２１０上でライフサイクルが管理されるようになる。インストールがアップデートの場合、既に同じバンドルＩＤをもつバンドルが展開されているときは、上書きでインストールされる。なおアップデートフラグは、インストールがアップデートの場合に所定の格納場所にセットされる。

次に、展開先フォルダ４０３であるＡｐｐＦｏｌｄｅｒの配下にある、ファームウェア４０１からの展開バンドル群４０４について説明する。ＯＳＧｉ拡張部２１１は、インストールされたバンドルごとにユニークな名前のフォルダ名でフォルダを作成する。以下、このフォルダのことをバンドルディレクトリと呼ぶ。図４の場合、システムサービス４０５がＳｙｓｔｅｍＡｐｐ１というバンドルディレクトリにインストールされている。バンドルディレクトリ直下には、インストールされたｊａｒ４０６がａｐｐ０．ｊａｒという名前で配置される。更に、各バンドルが、データを格納するために利用するｄａｔａフォルダ４０７が配置される。同様に組み込みログインバンドル４０８もシステムサービス４０５と同様の構成でインストールされる。

一方で、図３で示した方法によりユーザが後からインストールした後入れバンドル群４０９について説明する。後入れログインバンドル４１０もシステムサービス４０５と同様の構成でインストールされる。また、一般バンドル４１１もシステムサービス４０５と同様の構成でインストールされる。

このようにバンドルは、当該バンドルのフォルダ（ディレクトリ）にインストールされる。インストールされるファイルにはｊａｒファイルおよびｄａｔａフォルダ（データフォルダ）が含まれ、これらをまとめてバンドル関連ファイルと呼ぶ。なおｊａｒファイルとは、Ｊａｖａ（登録商標）バイトコード（すなわちプログラムの実体）およびそれが使用するリソースをまとめてアーカイブしたファイルであり、バンドルすなわちアプリケーションのプログラムそのものということもできる。

＜バンドル展開領域の削除フロー＞
図５は、バンドル展開領域４０２の削除時の全体のフローを示したブロック図である。Ｓ５００において、操作部１１８からクリア対象を示すクリアタイプの指定、及びバンドル展開領域クリアの実行が指定される。指定方法のＵＩについては、図６で示す。そのＵＩからの実行指示を受け、Ｓ５０１において、クリア指定ファイル生成部２０５は、指定されたクリアタイプ番号に従って、クリア指定ファイル５５０をＨＤＤ１０４の所定の場所に生成する。クリアタイプ番号とクリア指定ファイル５５０に記載する内容の関係については、図９で示す。その後、Ｓ５０２においてユーザによって、画像形成装置１３０が再起動される。再起動後、Ｓ５０３において、ＯＳＧｉ拡張部２１１がクリア指定ファイル５５０を検知すると、そのクリア指定ファイル５５０に記載された指定に従って、バンドル展開領域４０２の展開先フォルダ４０３内の削除対象を削除する。

その後、Ｓ５０５において、必要な場合、ファームウェア４０１に格納されているシステムサービス２１２、及び、組み込みログインサービス２１５をバンドル展開領域に再展開する。

＜クリアタイプの指定ＵＩ＞
図６は、クリアタイプの指定の為の、操作部１８に表示されるＵＩ（クリア指定ＵＩ）６００を説明した図である。サービスマンメニュー６００は、サービスマンに必要な機能一覧を表示したメニューである。ユーザは、バンドル展開領域４０１を削除しようとした場合、以下の操作を行う。クリアタイプ６０１を選択後、符号たとえばクリアタイプ番号６０２を入力し、ＯＫボタン６０４を押下する。その後、バンドル展開領域クリア６０３を選択後、ＯＫボタン６０４を押下する。この操作によってクリア指定ファイル５５０が作成され、所定の格納場所に格納される。この後、画像形成装置１３０を再起動すると、バンドル展開領域４０２内の、選択に応じた対象バンドルが削除される。このように、図６のユーザインタフェースにより、アプリケーションおよびそのアプリケーションに関する削除対象すなわち削除対象のファイルを指定することができる。後述のように削除対象のファイルにはフォルダを含む。

図７は、クリア指定ファイル５５０の記載例を示した図である。削除の対象となるバンドル指定７０１には、削除対象のバンドルであることを示すキー文字列（ＴａｒｇｅｔＡｐｐ）に続けてバンドルの種類（図７ではｓｙｓｔｅｍ，ｌｏｇｉｎ１）を指定する。アクション指定７０２には、削除対象バンドルに対して実行する内容の指定であることを示すキー文字列（Ａｃｔｉｏｎ）及び内容（図７ではｊａｒ）を指定する。

＜バンドル指定およびアクション指定＞
図８は、クリア指定ファイル５５０で指定するバンドル指定７０１とアクション指定７０２とを説明するための表である。バンドル指定７０１（ＴａｒｇｅｔＡｐｐ）では、削除対象のバンドルを何にするかを指定する。この削除対象の分類方法として、バンドルタイプで指定可能とする。この場合、システムバンドル（ｓｙｓｔｅｍ）、組み込みログインバンドル（ｌｏｇｉｎ１）、後入れログインバンドル（ｌｏｇｉｎ２）、一般バンドル（ｎｏｒｍａｌ）、全てのバンドル（ａｌｌ）のいずれかが選択可能とする。バンドル指定７０１では、複数の対象を指定可能とする。図７の例では、削除対象バンドルとしてｓｙｓｔｅｍとｌｏｇｉｎ１の２種類が指定されている。システムバンドルは、システムの一部ということもでき、バンドルをすべてクリアしても画像形成装置の再起動により再インストールされる。ログインバンドルは例えばログインしているユーザに関する情報を提供するなど、ログインに関するサービスを実現する。一般バンドルはその他のバンドルであり、後付け的にインストールし、またアンインストールすることができる。

一方、アクション指定７０２（Ａｃｔｉｏｎ）では、対象バンドル７０１に対してどんなことを実行するかを指定する。アクション指定７０２で「ｊａｒ」が指定された場合は、各バンドルディレクトリ直下のｊａｒファイル４０６を削除する。この場合、システムバンドルや組み込みバンドルのようなファームウェア４０１にオリジナルのｊａｒが存在している再展開可能バンドル８０２については、それらを再展開する。そのためにアップデートフラグを所定の場所に配置する。一方、後入れログインバンドルや一般バンドルのような再展開不可バンドル８０３については、ｊａｒファイルの再展開はできない。その為、ｄａｔａフォルダだけを残してもそれ以降にこのフォルダの使い道がなく不要ファイルが残ってしまうことが懸念される。そのため、再展開不可バンドル８０３に対して「ｊａｒ」が指定された場合、バンドルディレクトごと削除する。

また、アクション指定７０２で「ｄａｔａ」が指定された場合は、各バンドルディレクトリ直下のｄａｔａフォルダ４０７を削除する。

アクション指定８０１で「ａｌｌ」が指定された場合は、インストール済みの全バンドルについてそのバンドルディレクトリごと削除する。また、「ｊａｒ」指定のときと同様、再展開可能バンドル８０２については、それらを再展開する。そのために所定の場所にアップデートフラグを配置する。以上を踏まえて、具体的なケースについて説明していく。

ケース１で示すＴａｒｇｅｔＡｐｐ＝ｓｙｓｔｅｍ、ｌｏｇｉｎ１／Ａｃｔｉｏｎ＝ｊａｒが指定されたときは、システムバンドルと組み込みログインバンドルのｊａｒファイルを削除する。削除されたｊａｒファイルは、その後の起動時処理において、ＯＳＧｉ拡張部２１１によって、ファームウェア４０１から再展開される。

ケース２で示すＴａｒｇｅｔＡｐｐ＝ｓｙｓｔｅｍ、ｌｏｇｉｎ１／Ａｃｔｉｏｎ＝ｄａｔａが指定されたときは、システムバンドルと組み込みログインバンドルのバンドルディレクトリが保持するｄａｔａフォルダが削除される。

ケース３で示すＴａｒｇｅｔＡｐｐ＝ｓｙｓｔｅｍ、ｌｏｇｉｎ１／Ａｃｔｉｏｎ＝ａｌｌが指定されたときは、システムバンドルと組み込みログインバンドルのバンドルディレクトリが、ディレクトリごと削除される。これらは、その後の起動時処理において、ＯＳＧｉ拡張部２１１によって、削除されたバンドルのバンドルディレクトリ及びｊａｒファイルがファームウェア４０１から再展開される。

ケース４で示すＴａｒｇｅｔＡｐｐ＝ｌｏｇｉｎ２、ｎｏｒｍａｌ／Ａｃｔｉｏｎ＝ｊａｒが指定されたときは、後入れログインバンドルと一般バンドルのバンドルディレクトリが、ディレクトリごと削除される。

ケース５で示すＴａｒｇｅｔＡｐｐ＝ｌｏｇｉｎ２、ｎｏｒｍａｌ／Ａｃｔｉｏｎ＝ｄａｔａが指定されたときは、後入れログインバンドルと一般バンドルのバンドルディレクトリが保持するｄａｔａフォルダが削除される。

ケース６で示すＴａｒｇｅｔＡｐｐ＝ｌｏｇｉｎ２、ｎｏｒｍａｌ／Ａｃｔｉｏｎ＝ａｌｌが指定されたときは、後入れログインバンドルと一般バンドルのバンドルディレクトリが、ディレクトリごと削除される。これは、ケース４と同じ動きとなる。

ケース７で示すＴａｒｇｅｔＡｐｐ＝ａｌｌ／Ａｃｔｉｏｎ＝ｊａｒが指定されたときは、再展開可能バンドル８０２については、ｊａｒファイルが削除される。削除された再展開可能バンドルのｊａｒファイルは、その後の起動時処理においてＯＳＧｉ拡張部２１１によって、ファームウェア４０１から再展開される。一方、再展開不可バンドル８０３については、バンドルディレクトリごと削除される。

ケース８で示すＴａｒｇｅｔＡｐｐ＝ａｌｌ／Ａｃｔｉｏｎ＝ｄａｔａが指定されたときは、全てのバンドルのｄａｔａフォルダが削除される。

ケース９で示すＴａｒｇｅｔＡｐｐ＝ａｌｌ／Ａｃｔｉｏｎ＝ａｌｌが指定されたときは、全てのバンドルのバンドルディレクトリごと削除される。再展開可能バンドル８０２については、その後の起動時処理においてＯＳＧｉ拡張部２１１によって、バンドルディレクトリ及びｊａｒファイルがファームウェアから再展開される。

＜クリアタイプ番号＞
図９は、クリア指定ＵＩ６００で指定するクリアタイプ番号とクリア指定ファイルに記載する内容とについての関連を示した表である。例えば、クリアタイプ番号０の場合、クリア指定ファイルには、図８のケース９で示した内容を記載することを示している。このようにクリアタイプを指定できるようにすることで、たとえばｄａｔａを削除せずにｊａｒの再展開だけを試すことが可能となる。このため、画像形成装置１３０にバンドルが原因でトラブルが発生した場合、従来だと全てのバンドル展開領域を削除するしかなかったところを、例えば、クリアタイプ１を選択することで、ｄａｔａを削除せずにｊａｒの再展開だけを試みることができる。これによりトラブルが解消されれば、データを無駄に削除する必要がなくなるメリットがある。また、クリアタイプ３を選択することで、一旦削除すると再インストールすることが必要な再展開不可バンドルに対して、ｄａｔａだけを削除することを試みることが可能となる。 これによりトラブルが解消されれば、バンドルを再インストールする手間を減らすメリットがある。

このように、図８の表に示したケース１からケース９のすべて又は代表的な一部ケースをクリアタイプ番号と関連付けておくことで、クリア指定ＵＩ６００では、削除の対象を簡便なコードで指定することができる。この関連付けは、たとえば図９のように、クリアタイプ番号と、クリア指定ファイル５５０に記載するバンドル指定７０１及びアクション指定７０２の組とを表として登録しておくことができる。もちろん、プログラムへのハードコーディングなど他の方法により関連付けてもよい。そしてこの関連付けに従って、指定されたクリアタイプ番号に応じたバンドル指定７０１及びアクション指定７０２が、クリア指定ファイル５５０に記述される。なおクリアタイプ番号を付与するケースは、図８の例では、ケース１〜５を指定できれば、ケース６〜９をカバーすることができる。ケース６ではケース４と同じ処理が行われ、ケース７〜９は、全バンドルをカバーするためにバンドル指定が異なるクリアタイプ番号を指定して複数回の操作を行うことで実現できるためである。

＜削除処理のシーケンス＞
図１０は、クリアタイプ番号の指定のから、再起動後の削除処理までを示したシーケンス図である。Ｓ１０００において、ユーザが、ＵＩ２０２からクリアタイプ６０１を選択した状態で、クリアタイプ番号６０２を入力しＯＫボタンを押下する。Ｓ１００１において、ＵＩは、設定データ管理部２０３に入力されたクリアタイプ番号を設定データベース２０４に格納するように依頼する。Ｓ１００２において、ユーザが、バンドル展開領域クリアを選択した状態で、ＯＫボタンを押下する。Ｓ１００３において、ＵＩは、クリア指定ファイル生成部２０５に展開領域クリアの実行指示を行う。Ｓ１００４において、クリア指定ファイル生成部２０５は、設定データ管理部２０３に指定されているクリアタイプの値（クリアタイプ番号）を取得しにいく。Ｓ１００５において、クリア指定ファイル生成部２０５は、取得したクリアタイプの値を基に、クリア指定ファイル５５０を生成する。すなわち、クリアタイプ番号に関連付けられたバンドル指定７０１およびアクション指定７０２をクリア指定ファイル５５０に書き込む。Ｓ１００６において、ユーザが、画像形成装置１３０を再起動する。Ｓ１００７において、ＯＳＧｉ拡張部２１１は、クリア指定ファイル５５０を参照する。Ｓ１００８において、ＯＳＧｉ拡張部２１１は、クリア指定ファイル５５０による指定に従ってバンドル展開領域４０２を削除する。このＳ１００７、及び、Ｓ１００８におけるＯＳＧｉ拡張部２１１のフローは、図１１で示す。

＜ＯＳＧｉ拡張部によるバンドル展開領域の削除フロー＞
図１１は、ＯＳＧｉ拡張部２１１が、起動時にバンドル展開領域を削除するときのフローチャートである。Ｓ１１００において、バンドル展開領域削除処理が開始される。Ｓ１１０１において、ＯＳＧｉ拡張部２１１は、クリア指定ファイル５５０が存在するかどうかをチェックする。クリア指定ファイル５５０が存在しなければＳ１１１８に進み、処理を終了する。クリア指定ファイル５５０が存在していればＳ１１０２に進む。Ｓ１１０２において、ＯＳＧｉ拡張部２１１は、クリア指定ファイル５５０からバンドル指定（以下、ＴａｒｇｅｔＡｐｐということもある）７０１の値を読みとり、メモリに値を確保して、Ｓ１１０３に進む。Ｓ１１０３において、ＴａｒｇｅｔＡｐｐ７０１の値が、ｓｙｓｔｅｍすなわちシステムバンドル、もしくは、ｌｏｇｉｎ１すなわち組み込みログインバンドルだった場合、Ｓ１１０４に進み、アップデートフラグを生成する。これにより、この後のＯＳＧｉ拡張部２１１による起動処理において、ファームウェア４０１からの再展開処理が走ることとなる。Ｓ１１０５において、ＯＳＧｉ拡張部２１１は、クリア指定ファイル５５０からアクション指定（以下Ａｃｔｉｏｎと呼ぶこともある）７０２の値を読みとり、メモリに値を確保して、Ｓ１１０６に進む。Ｓ１１０６において、ＯＳＧｉ拡張部２１１は、バンドル展開領域にインストールされているバンドルリストを取得して、次にＳ１１０７に進み、各バンドルを処理対象バンドルとし、処理対象バンドルを順次変更してループ処理を行う。

Ｓ１１０７において、処理対象バンドルのバンドルタイプとＴａｒｇｅｔＡｐｐ７０１が一致するかどうかをチェックする。バンドルタイプとは、一般バンドル（ｎｏｒｍａｌ）、ログインバンドル（ｌｏｇｉｎ）、システムバンドル（ｓｙｓｔｅｍ）のいずれかである。ＴａｒｇｅｔＡｐｐ７０１でｎｏｒｍａｌが指定されている場合は、バンドルタイプが一般バンドルであれば一致とみなされる。ＴａｒｇｅｔＡｐｐ７０１でｌｏｇｉｎ１すなわち組み込みログインバンドル、もしくはｌｏｇｉｎ２すなわち後入れログインバンドルが指定されている場合は、処理対象バンドルのバンドルタイプがログインバンドルであれば一致とみなされる。ＴａｒｇｅｔＡｐｐ７０１でｓｙｓｔｅｍすなわちシステムバンドルが指定されている場合は、処理対象バンドルのバンドルタイプがシステムバンドルであれば一致とみなされる。Ｓ１１０７において、いずれとも一致しなければ、Ｓ１１１７に進む。Ｓ１１０７において、一致した場合、Ｓ１１０８に進む。

Ｓ１１０８において、処理対象バンドルのバンドルタイプがｓｙｓｔｅｍすなわちシステムバンドルの場合、Ｓ１１１０に進み、再展開能フラグをＯＮに設定する。Ｓ１１０８において、バンドルタイプがｎｏｒｍａｌすなわち一般バンドルの場合、Ｓ１１１１に進み、再展開能フラグをＯＦＦにする。Ｓ１１０８において、バンドルタイプがｌｏｇｉｎすなわちログインバンドルの場合、Ｓ１１０９に進む。Ｓ１１０９において、ログインバンドルが、組み込みログインバンドルなのか、後入れログインバンドルなのかを判定する。組み込みなのか、後入れなのかは、これらのバンドルのインストール時にＯＳＧｉ２１１がもつ管理情報で保持されているものとする。或いは、処理対象バンドルのフォルダ名で判定してもよい。もし、組み込みログインバンドルであればＳ１１１０に進み、再展開能フラグをＯＮにする。もし、後入れログインバンドルであれば、Ｓ１１１１に進み、再展開能フラグをＯＦＦにする。

Ｓ１１１２において、Ｓ１１０３において読み取ったＡｃｔｉｏｎ７０２の値が何かを判定する。Ｓ１１１２において、Ａｃｔｉｏｎ７０２の値がａｌｌすなわちバンドルディレクトリごとの削除であった場合、Ｓ１１１５に進み、処理対象バンドルのバンドルディレクトリごと削除する。Ｓ１１１２において、Ａｃｔｉｏｎ７０２の値がｄａｔａすなわちデータフォルダの削除であった場合、Ｓ１１１６に進み、処理対象ンドルのバンドルディレクト直下のｄａｔａフォルダ４０７を削除する。Ａｃｔｉｏｎ７０２の値がｊａｒすなわちｊａｒファイルの削除であった場合、Ｓ１１１３に進み、再展開能フラグの値を判定する。Ｓ１１１３において、再展開能フラグがＯＮであった場合、Ｓ１１１４に進み、処理対象バンドルのバンドルディレクトリ直下のｊａｒファイル４０６を削除する。Ｓ１１１３において、再展開能フラグがＯＦＦであった場合、Ｓ１１１５に進み、処理対象バンドルのバンドルディレクトリごと削除する。Ｓ１１１７において、処理対象のバンドルが最後であったかどうかを判定し、最後でなければＳ１１０７に戻り、処理を繰り返す。Ｓ１１１７において、処理対象のバンドルが最後であったと判定された場合、Ｓ１１１８に進み、処理を終了する。

なお図１１には示されていないが、前述のとおり再展開可能なｊａｒファイルは画像形成装置の再起動処理に伴って再展開される。

以上、画像形成装置１３０におけるバンドル展開領域を、指定したクリアタイプによって削除することが可能となる。これにより、バンドルにトラブルが発生した場合、効果的な削除方法を選択可能となる。たとえば、バンドル指定７０１でシステムを指定し、アクション指定７０２としてｊａｒを指定すれば（すなわち図９のクリアタイプ番号＝１）、削除したシステムバンドルのｊａｒファイルは再展開されるので、画像形成装置は、バンドルをクリアした後でもクリアする前と同様に利用できる。これで解消できなければ、例えば次にはバンドル指定７０１によりシステムバンドルを、アクション指定７０２によりｄａｔａを指定してｄａｔａフォルダを削除して、再起動後の画像形成装置が正常に動作するか試す、というように、段階的にクリアする対象を変えつつ、エラーの解消を試みることができる。

［実施例２］
画像形成装置の工場組み立て時に作業用のバンドルをインストールすることがある。そのような場合、工場出荷時には、それらを一旦全てクリアしてバンドルがインストールされていない初期状態に戻す必要が出てくる。そのため、出荷前クリアを出荷前の作業の最後に実行することで、バンドル展開領域を全て削除する必要があった。一方で、設置の手間などを考えて、ユーザによく利用される一般バンドルや売り込みたいバンドルを予め工場でインストールしておくことが考えられる。これをプレインストールバンドルと呼ぶ。しかしながら、前述した出荷前クリアを実行することで、このプレインストールバンドルも削除されてしまうという課題があった。たとえば、画像形成装置の組み立て時に、あらかじめ用意しておいたプレインストールバンドルを含むファームウェアのイメージデータをハードディスク１０４に複製することで、ファームウェアを一括してインストールでき生産性を向上させることができる。そのような生産方法を採用する場合には、プレインストールバンドルのインストール後に出荷前クリアを行うことは避けられない。本実施例２では、この課題に対する、工場出荷時のバンドル展開領域の削除の方法の実施例を示す。

図１２は、工場出荷時に行う出荷前クリアの指定の為のＵＩ１２００を説明した図である。工場メニューＵＩ１２００は、工場内での作業用に必要な機能のメニューである。出荷前クリア１２０１を選択した状態で、ＯＫボタン１２０２を押下すると、出荷前のクリアが実行される。

図１３は、出荷前クリア時のクリア指定ファイル１３００の記載例を示した図である。ＴａｒｇｅｔＡｐｐ１３０１には、出荷前クリアを意味するＳｈｉｐｐｉｎｇ＿Ｃｌｅａｒを指定する。この場合アクション指定は参照しないので、どのような内容であってもよいし、なくともよい。出荷前クリアが指定されると、クリア指定ファイル生成部２０５が図１３に示すクリア指定ファイルを生成して所定箇所に格納する。

図１４は、バンドルにおけるマニフェストファイル１４００を示した図である。マニフェストファイルはバンドルごとに存在する。マニフェストファイルには、バージョンや、ＪＡＶＡバンドルのｊａｒファイルのプロパティ値が記述される。その内容はマニフェスト項目とそれに対する値という形式で記述される。出荷前クリアの対象外バンドルかどうかを示す対象外バンドル（ＯｕｔＯｆＳｈｉｐｐｉｎｇＣｌｅａｒ）１４０１は、マニフェスト項目の中の一つであり、その値がｔｒｕｅにセットされている場合、出荷前クリアの削除対象外バンドルであることを示す。一方で、ｆａｌｓｅ、もしくは、ＯｕｔＯｆＳｈｉｐｐｉｎｇＣｌｅａｒの記載がない場合、出荷前クリアの削除対象バンドルであることを示す。プレインストールバンドルは、このＯｕｔＯｆＳｈｉｐｐｉｎｇＣｌｅａｒをｔｒｕｅにしておくことで、出荷前クリアの対象外とすることができる。

ＯＳＧｉ２１０は、バンドルマニフェストに記述された値を管理情報としてメモリ上に保持している。これらは、対象とするバンドル名と、マニフェストに書かれた項目値などをキーとし、キーを指定することでそれに紐づいた値を取得できる。よって、ＯｕｔＯｆＳｈｉｐｐｉｎｇＣｌｅａｒをキーとすれば、この値を管理情報から取得可能である。

＜出荷前クリア時の削除処理シーケンス＞
図１５は、出荷前クリア時のＵＩの指定から、再起動後の削除処理までを示したシーケンス図である。Ｓ１５００において、ユーザが、出荷前クリア１２０１を選択した状態で、ＯＫボタンを押下する。Ｓ１５０１において、ＵＩは、クリア指定ファイル生成部２０５に出荷前クリア時のバンドル展開領域クリアの実行指示を行う。Ｓ１５０２において、クリア指定ファイル生成部２０５は、その指示に従い、クリア指定ファイル１３００を生成する。Ｓ１５０３において、ユーザが、画像形成装置１３０を再起動する。Ｓ１５０４において、ＯＳＧｉ拡張部２１１は、クリア指定ファイル１３００を参照する。Ｓ１５０５において、ＯＳＧｉ拡張部２１１は、ＯｕｔＯｆＳｈｉｐｐｉｎｇＣｌｅａｒがセットされているバンドルを対象として出荷前クリア時のバンドル展開領域削除を実行する。このＳ１５０４、及び、Ｓ１５０５におけるＯＳＧｉ拡張部２１１のフローは、図１６で示す。

図１６は、ＯＳＧｉ拡張部２１１による、出荷前クリア時のバンドル展開領域を削除するときのフローチャートである。Ｓ１６００〜Ｓ１６０２までは、図１１のＳ１１００〜Ｓ１１０２と同じ処理となる。Ｓ１６００において、バンドル展開領域削除処理が開始される。Ｓ１６０１において、ＯＳＧｉ拡張部２１１は、クリア指定ファイル１３００が存在するかどうかをチェックする。クリア指定ファイル１３００が存在しなければＳ１６１０に進み、処理を終了する。クリア指定ファイル１３００が存在していればＳ１６０２に進む。Ｓ１６０２において、ＯＳＧｉ拡張部２１１は、ＴａｒｇｅｔＡｐｐ１３０１の値を読みとり、メモリに値を確保して、Ｓ１６０３に進む。Ｓ１６０３において、ＴａｒｇｅｔＡｐｐ１３０１の値がｓｈｉｐｐｉｎｇ＿ｃｌｅａｒだった場合、Ｓ１６０５に進み、アップデートフラグを生成する。これにより、この後のＯＳＧｉ拡張部２１１による起動処理において、ファームウェア４０１からの再展開処理が走ることとなる。Ｓ１６０３において、ＴａｒｇｅｔＡｐｐ１３０１の値が、ｓｈｉｐｐｉｎｇ＿ｃｌｅａｒでなかった場合、Ｓ１６０４に進む。これ以降は、図１１で示した通常起動時のフローに戻り、Ｓ１１０３からフローが処理される。

Ｓ１６０６において、ＯＳＧｉ拡張部２１１は、バンドル展開領域にインストールされているバンドルリストを取得して、次にＳ１６０７に進み、各バンドルを処理対象のバンドルとして順次着目してループ処理を行う。Ｓ１６０７において、最初のバンドルのマニフェストＯｕｔＯｆＳｈｉｐｐｉｎｇＣｌｅａｒの値がｔｒｕｅであるかどうかをチェックする。この値がｆａｌｓｅ、あるいは、ＯｕｔＯｆＳｈｉｐｐｉｎｇＣｌｅａｒの定義がない場合は、Ｓ１６０８に進み、そのバンドルのバンドルディレクトリごと削除する。ＯｕｔＯｆＳｈｉｐｐｉｎｇＣｌｅａｒの値がｔｒｕｅであった場合、Ｓ１６０９に進み、そのバンドルについては、何も削除をしない。Ｓ１６０９において、処理対象のバンドルが最後だったかどうかを判定し、最後でなければ、Ｓ１６０７に戻り、処理を繰り返す。Ｓ１６０９において、ループが最後であると判定された場合、Ｓ１６１０に進み、処理を終了する。

以上、本実施例２にて示したように、特定のバンドルだけを残してバンドル展開領域を削除することが可能となる。この例では、たとえばプレインストールバンドルについてはそのマニフェストファイルのＯｕｔＯｆＳｈｉｐｐｉｎｇＣｌｅａｒ項目をセット、すなわちｔｒｕｅとしておく。このようにすれば、プレインストールバンドルは削除されることなく、システムバンドルは削除後に再展開されて、出荷時クリアを実現できる。

［実施例３］
本実施例３からは、インストールされたバンドルの削除のユースケースを鑑み、削除単位のバリエーションとして効率の良い削除方法についての実施例を示す。まず、フラグメントバンドルを対象とした削除について述べる。バンドルには、フラグメントバンドルと呼ばれるタイプのバンドルがある。図１７は、そのフラグメントバンドルの概念を説明する図である。ここでは、ホストバンドル１７００に対して、言語ローカライズリソースをもつフラグメントバンドル１７０１と１７０２がインストールされる例を示している。ホストバンドルにフラグメントバンドルをインストールするためには、ＯＳＧｉ２１０の規定上、以下のマニフェスト、及びバンドルパーミッションの指定が必要となる。フラグメントバンドルとは、簡単に説明するなら、ホストバンドルに関連づけれてホストバンドルと協働するバンドル（アプリケーション）である。フラグメントバンドルは、フラグメントバンドル単体でインストールおよびアンインストールが可能である。
−ホストバンドルのマニフェスト１７０３
Bundle-ManifestVersionに2と指定する。Bundle-SymbolicNameには、フレームワーク内で一意な名前を付ける。
−フラグメントバンドルのマニフェスト１７０５
Bundle-ManifestVersionに2と指定する。Fragment-Hostには、ホストバンドルのマニフェスト１７０３に記載の＜ホストのバンドルシンボリック名＞を指定する。本値が一致することでホストバンドルとフラグメントバンドルが同一バンドルの構成要素であることを示すものとなる。
−ホストバンドルのパーミッション１７０４
BundlePermission[バンドルシンボリック名, ＨＯＳＴ]
−フラグメントバンドルのパーミッション１７０６
BundlePermission[バンドルシンボリック名, ＦＲＡＧＭＥＮＴ]。

上記条件を満足する状態で、フラグメントバンドルをインストールすると、ＯＳＧｉ２１０がフラグメントバンドルのマニフェスト情報からホストバンドルを特定し、ホストバンドルのクラスパスにフラグメントバンドル自身のクラスパスの追加を行う。ここで「クラスパス」とは、ＪＡＶＡバンドルを実行するときに、ＪａｖａＶＭがどの場所からクラスファイルを読み込めばよいかを、指定するためのものである。更に、ホストバンドルのクラスローダによって、フラグメントバンドル内の全てのクラスとリソースがロードされる。ここで、「クラスローダ」とは、クラスのロードやリソースの検索を担当するオブジェクトであり、全てのクラスはクラスローダによってＪａｖａＶＭにロードされバンドルから利用可能となる。

本例では、フラグメントバンドルとして日本語リソース１７０１、中国語リソース１７０２が本体であるホストバンドル１７００にインストールされ、その後、ホストバンドル１７００が、これらの日本語、中国語リソースを利用して、リソースの言語切り替えが可能となる。つまり、ホストバンドルのＵＩ上の表示は英語であるが、ホストバンドルのＵＩ上でリソース切り替え指定をすることで、日本語表示や中国語表示にするようにホストバンドルを作ることが可能である。リソースとしては、ここで示したような言語リソースだけでなくて、イメージリソースの切り替えも可能である。よって、標準では英語表示のイメージを利用していたが、前記ホストバンドルのＵＩ上でリソース切り替え指定をすることで、日本語、または中国語表示のイメージに切り替えることが可能である。このようなリソースの切り替えの目的でフラグメントバンドルが利用されることが多い。

この例で示したようにフラグメントバンドルは、言語リソースを多数保持していることが多く、これらを一度に削除して、リソースの影響を考えないでバンドルの評価をしたいことがある。その場合、ひとつずつフラグメントバンドルをアンインストールしてもよいが、図１８に示すように、クリア指定ファイルに記載することで一度に削除することが可能となる。図１８は、フラグメントバンドル削除を指定したクリア指定ファイル１８００の記載例を示した図である。バンドル指定であるＴａｒｇｅｔＡｐｐ１８０１には、フラグメントバンドルを削除対象とすることを示すｆｒａｇｍｅｎｔＢｕｎｄｌｅを指定する。ここでは省略したが、このバンドル指定は直接記載せず、たとえば実施例１のようにユーザインタフェースを介してクリアタイプ番号を指定させ、特定の番号が指定されたならクリア指定ファイルのバンドル指定１８０１にｆｒａｇｍｅｎｔＢｕｎｄｌｅを書き込んでもよい。

＜フラグメントバンドルの削除フロー＞
図１９は、ＯＳＧｉ拡張部２１１による、フラグメントバンドルを削除対象としたバンドル展開領域を削除するときのフローチャートである。Ｓ１９００〜Ｓ１９０２までは、図１６のＳ１６００〜Ｓ１６０２と同じ処理となるため説明を省略する。Ｓ１９０３において、ＴａｒｇｅｔＡｐｐ１８０１の値が、ｆｒａｇｍｅｎｔＢｕｎｄｌｅだった場合、Ｓ１９０５に進み、アップデートフラグを生成する。これにより、この後のＯＳＧｉ拡張部２１１による起動処理において、ファームウェア４０１からの再展開処理が走ることとなる。Ｓ１９０３において、ＴａｒｇｅｔＡｐｐ１３０１の値が、ｆｒａｇｍｅｎｔＢｕｎｄｌｅでなかった場合、Ｓ１９０４に進む。これ以降は、図１１で示した通常起動時のフローに戻り、Ｓ１１０３からフローが処理される。なおＳ１９０４では図１６のＳ１６０３に分岐してもよい。

Ｓ１９０５において、ＯＳＧｉ拡張部２１１は、バンドル展開領域にインストールされているバンドルリストを取得して、次にＳ１９０６に進み、各バンドルに対してループ処理を行う。Ｓ１９０６において、最初のバンドルがフラグメントバンドルかどうかをチェックする。例えばマニフェストファイルにfragment host項目があるか或いはバンドルパーミッション１７０６が「fragment」であれば、フラグメントバンドルであると判定できる。処理対象のバンドルが、フラグメントバンドルであった場合、そのバンドルのバンドルディレクトリごと削除する。処理対象のバンドルがフラグメントバンドルでなかった場合、Ｓ１９０８に進み、そのバンドルについては、何も削除をしない。Ｓ１９０８において、処理対象のバンドルが最後のバンドルであったかどうかを判定し、最後でなければＳ１９０６に戻り、処理を繰り返す。Ｓ１９０８において、ループが最後であったと判定された場合、Ｓ１９０９に進み、処理を終了する。

以上、本実施例３にて示したように、フラグメントバンドルのみを削除対象としてバンドル展開領域を削除することが可能となる。なおこの例ではフラグメントバンドルを対象としたが、他の種類のバンドルを削除対象とすることももちろん可能である。

［実施例４］
実施例３に引き続き、バンドルの削除のユースケースを鑑み、削除単位のバリエーションとして効率の良い削除方法についての実施例を示す。本実施例では、バンドルＩＤを指定した削除方法について述べる。バンドルにおけるマニフェストファイルは、必ずユニークなバンドルＩＤを持つ。よって、そのバンドルのバンドルＩＤを知っていれば、バンドルを特定することができる。よって、あるバンドルのデータフォルダを削除したいときなどは、図７で示したアクション指定（Ａｃｔｉｏｎ）７０２＝ｄａｔａの指定と、バンドルＩＤの組み合わせにより、ある特定のバンドルのデータだけを削除することが可能となる。バンドルＩＤは、例えば図６のユーザインタフェースにおいて、バンドルＩＤを入力するためのクリアタイプ番号を決めておく。その番号が指定された場合に、バンドルＩＤの入力欄によりＩＤを受け付け、入力されたＩＤをクリア指定ファイルに書き込むように構成すればよい。

図２０は、クリア指定ファイル２０００の記載例を示した図である。バンドル指定（ＴａｒｇｅｔＡｐｐ）２００１には、削除対象バンドルのバンドルＩＤを指定する。ここにあるように、例えば文字列「ｂｕｎｄｌｅＩＤ＝」の後にバンドルＩＤを指定する。アクション指定（Ａｃｔｉｏｎ）２００２には、削除対象バンドルに対して実行する内容を指定する。ＯＳＧｉ拡張部２１１が、起動時にバンドル展開領域を削除するときのフローは、図１１、及び図１９と同義の為、詳細は省略する。ＴａｒｇｅｔＡｐｐ２００１の指定に対する処理としては、Ｓ１９０６のタイミングにおいて、バンドルが持つバンドルＩＤとＴａｒｇｅｔＡｐｐ２００１で指定されたバンドルＩＤとが一致すれば、そのバンドルを削除対象とする。また、Ａｃｔｉｏｎ２００２の指定に対する処理としては、Ｓ１１１２〜Ｓ１１１６と同じ処理を行う。すなわち、本実施例は、実施例１においてはバンドルを種類で指定しているところを、それに代えてバンドルＩＤで指定したものということができる。

以上、本実施例４にて示したように、特定のバンドルＩＤをもつバンドルを削除対象としてバンドル展開領域内のそのバンドルがもつｄａｔａフォルダを削除することが可能となる。

［実施例５］
実施例３、及び実施例４に引き続き、バンドルの削除のユースケースを鑑み、削除単位のバリエーションとして効率の良い削除方法についての実施例を示す。本実施例では、バンドルの状態を指定した削除方法について述べる。インストールされたバンドルは、開始／停止などの状態を持つ。この状態は、ＯＳＧｉ２１０によって管理されており、その状態はＯＧＧｉ拡張部２１１から取得可能である。停止しているバンドルは、利用していないバンドルとみなすことができるので、利用していないバンドルのデータを削除して、ストレージを空けるなどのユースケースが考えられる。

図２１は、バンドルの状態指定のクリア指定ファイル２１００の記載例を示した図である。ＴａｒｇｅｔＡｐｐ２１０１には、ステータスを示す値を指定する。ここでは、文字列「ｓｔａｔｕｓ＝」の後に状態としてｓｔｏｐを指定しているので、停止しているバンドルを表す。Ａｃｔｉｏｎ２１０２には、削除対象バンドルに対して実行する内容を指定する。

ＯＳＧｉ拡張部２１１が、起動時にバンドル展開領域を削除するときのフローは、図１１、及び図１９と同義の為、詳細は省略する。ＴａｒｇｅｔＡｐｐ２００１の指定に対する処理としては、Ｓ１９０６のタイミングにおいて、バンドルの状態を判定し、ＴａｒｇｅｔＡｐｐ２００１で指定された状態とが一致すれば、そのバンドルを削除対象とする。また、Ａｃｔｉｏｎ２００２の指定に対する処理としては、Ｓ１１１２〜Ｓ１１１６と同じ処理を行う。

以上、本実施例５にて示したように、特定の状態をもつバンドルを削除対象としてバンドル展開領域内のそのバンドルがもつｄａｔａフォルダを削除することが可能となる。

［その他の実施例］
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

２１３：インストール制御サービス、２１４：バンドル管理サービス、２１５：組込ログインサービス、２１６：ログインバンドル、２１７:後入れバンドル、２１８：ログインバンドル、２１９：一般バンドル

Claims (17)

1. アプリケーションの追加および削除が可能な画像形成装置であって、
   アプリケーションおよび削除するファイルを指定するための指定手段と、
   前記指定手段により指定されたアプリケーションに関して、指定されたファイルを削除する削除手段と
   を備えることを特徴とする画像形成装置。
2. 前記指定手段は、アプリケーションをその種類で指定することを特徴とする請求項１に記載の画像形成装置。
3. 前記指定手段は、前記アプリケーションの種類とファイルの種類とを組み合わせた符号を指定することにより前記アプリケーションおよび前記ファイルを指定することを特徴とする請求項１又は２に記載の画像形成装置。
4. 前記指定手段は、前記符号を入力するためのユーザインタフェースを有することを特徴とする請求項３に記載の画像形成装置。
5. 前記指定手段により指定できる前記アプリケーションの種類は、システムに組み込まれたアプリケーションであるシステム、ログインの際に実行されるアプリケーションであるログイン、その他のアプリケーションである一般、のうち少なくともいずれかを含み、
   前記指定手段により指定できる前記ファイルの種類は、アプリケーションの実体であるプログラム、またはデータの少なくともいずれかを含むことを特徴とする請求項１乃至４のいずれか一項に記載の画像形成装置。
6. 前記指定手段により前記アプリケーションの種類として再展開可能なシステムまたはログインが指定されている場合、前記ファイルの種類としてプログラムが指定されていれば、前記削除手段は該当するプログラムを削除し、
   前記指定手段により前記アプリケーションの種類として再展開不可の一般またはログインが指定されている場合、前記ファイルの種類としてプログラムが指定されていれば、前記削除手段は、該当するプログラムと該プログラムのデータとを含むフォルダを削除することを特徴とする請求項５に記載の画像形成装置。
7. 前記指定手段により前記ファイルの種類としてデータが指定されている場合には、前記削除手段は、指定された前記アプリケーションのデータを削除することを特徴とする請求項５又は６に記載の画像形成装置。
8. 前記指定手段により前記アプリケーションの種類として再展開可能なシステムまたはログインが指定されている場合、前記ファイルの種類としてプログラム及びデータが指定されていれば、前記削除手段は、該当するプログラムと該プログラムのデータとを含むフォルダを削除することを特徴とする請求項５乃至７のいずれか一項に記載の画像形成装置。
9. 前記削除手段により、再展開可能な前記システムまたは前記ログインの種類のアプリケーションのプログラムが削除された場合には、削除された前記プログラムを再起動後にインストールし直す手段を更に有することを特徴とする請求項６又は８に記載の画像形成装置。
10. 前記指定手段は、予め定められた特定のアプリケーションを指定でき、
    前記削除手段は、前記予め定められた特定のアプリケーションが指定された場合には、前記特定のアプリケーションのプログラムとデータとを含むフォルダを削除することを特徴とする請求項１に記載の画像形成装置。
11. 前記特定のアプリケーションは、前記特定のアプリケーションであることを示す情報を関連付けられており、前記削除手段は、前記情報に基づいて前記特定のアプリケーションを特定することを特徴とする請求項１０に記載の画像形成装置。
12. 前記特定のアプリケーションは、他のアプリケーションと協働するフラグメントバンドルであることを特徴とする請求項１１に記載の画像形成装置。
13. 前記指定手段は、アプリケーションをアプリケーションのＩＤで指定でき、
    前記削除手段は、該当するアプリケーションについて、指定されたファイルを削除することを特徴とする請求項１に記載の画像形成装置。
14. 前記指定手段は、アプリケーションをアプリケーションの状態で指定でき、
    前記削除手段は、該当するアプリケーションについて、指定されたファイルを削除することを特徴とする請求項１に記載の画像形成装置。
15. 前記アプリケーションを実行するためのプラットフォームと、
    前記画像形成装置の提供する機能を前記アプリケーションにより利用するためのライブラリと
    を更に有することを特徴とする請求項１乃至１４のいずれか一項に記載の画像形成装置。
16. アプリケーションの追加および削除が可能な画像形成装置におけるアプリケーションの削除方法であって、
    アプリケーションおよび削除するファイルを指定するための指定工程と、
    前記指定工程により指定されたアプリケーションに関して、指定されたファイルを削除する削除工程と
    を有することを特徴とするアプリケーションの削除方法。
17. 請求項１乃至１５のいずれか一項に記載の画像形成装置としてコンピュータを機能させるためのプログラム。

Images