JP2021184208A - 情報処理装置、情報処理方法、及びプログラム - Google Patents

Abstract

【課題】アプリによるコンピュータ資源の消費を抑えるために、他のアプリに対する影響が生じないように削除候補となるアプリを選択する。【解決手段】情報処理装置にインストールされるべき標準アプリケーションを示す情報を取得する。情報処理装置に格納されているアプリケーションのうち、標準アプリケーションではないアプリケーションを削除候補となる候補アプリケーションとして選択する。格納されているアプリケーションが依存するアプリケーションを示す情報を取得する。候補アプリが依存するアプリケーションに含まれていない場合に、候補アプリを情報処理装置から削除する。【選択図】図６

Description

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

ファームウェアの更新を行う際に、インストールすべきアプリケーション（アプリ）のリストに従ってアプリのインストールを行う場合がある。ファームウェアの開発者に不要と判断されたアプリの情報は、ファームウェアの更新時にリストから削除され、それ以降そのアプリのインストール処理は行われなくなる。

一方で、インストールされたアプリは、ストレージ領域やファイルディスクリプタなどのコンピュータ資源を消費する。そのようなコンピュータ資源の消費を抑えるために、不要と判断されたアプリを削除するための手法が研究されている。特許文献１に開示される技術では、最終利用日時からの経過期間が最も長いアプリから順番に削除対象として選択する手法が記載されている。

特開平１０−２６０８７３号公報

しかしながら、アプリは、動作のために他のアプリが提供する機能を利用する場合がある。特許文献１に記載の手法では、削除対象とするアプリの選択にあたってアプリ間の関係が考慮されておらず、アプリの削除により他のアプリへの影響が発生してしまう可能性があるという課題があった。

本発明は、アプリによるコンピュータ資源の消費を抑えるために、他のアプリに対する影響が生じないように削除候補となるアプリを選択することを目的とする。

本発明の目的を達成するために、例えば、一実施形態に係る情報処理装置は以下の構成を備える。すなわち、前記情報処理装置にインストールされるべき標準アプリケーションを示す情報を取得する第１の取得手段と、前記情報処理装置に格納されているアプリケーションのうち、前記標準アプリケーションではないアプリケーションを削除候補となる候補アプリケーションとして選択する選択手段と、前記格納されているアプリケーションが依存するアプリケーションを示す情報を取得する第２の取得手段と、前記候補アプリが前記依存するアプリケーションに含まれていない場合に、前記候補アプリを前記情報処理装置から削除する削除手段と、を備える。

アプリによるコンピュータ資源の消費を抑えるために、他のアプリに対する影響が生じないように削除候補となるアプリを選択することができる。

実施形態１に係る情報処理装置を含むシステムの構成の一例を示す図。 実施形態１に係る画像形成装置のハードウェア構成の一例を示す図。 実施形態１に係るアプリ実行のシステム構成の一例を示す図。 実施形態１に係るアプリのプログラムファイルを説明するための図。 実施形態１に係る公開サービスと参照サービスとを説明するための図。 実施形態１に係る情報処理方法の処理の一例を示すフローチャート。 実施形態２に係るアプリ実行のシステム構成の一例を示す図。 実施形態２に係るアプリのプログラムファイルを説明するための図。 実施形態２に係る情報処理方法の処理の一例を示すフローチャート。 実施形態３に係るアプリ実行のシステム構成の一例を示す図。 実施形態３に係るアプリのプログラムファイルを説明するための図。 実施形態３に係る情報処理方法の一例を示すフローチャート。 実施形態３に係る情報処理方法の一例を示すフローチャート。 実施形態１に係る情報処理装置の機能構成の一例を示す図。 実施形態１に係る情報処理装置のハードウェア構成の一例を示す図。

以下、添付図面を参照して実施形態を詳しく説明する。なお、以下の実施形態は特許請求の範囲に係る発明を限定するものではない。実施形態には複数の特徴が記載されているが、これらの複数の特徴の全てが発明に必須のものとは限らず、また、複数の特徴は任意に組み合わせられてもよい。さらに、添付図面においては、同一若しくは同様の構成に同一の参照番号を付し、重複した説明は省略する。

［実施形態１］
本実施形態に係る情報処理装置は、インストールされるべき標準アプリケーション（標準アプリ）を示す情報に基づいて、格納しているアプリから削除候補となる候補アプリケーション（候補アプリ）を選択する。次いで、候補アプリが、格納している他のアプリから依存される依存先アプリケーションではない場合に、その候補アプリを削除する。本実施形態においては、標準アプリとして、ファームウェアの開発者が設定する、初期状態でファームウェアに関連付けられているアプリが用いられる。また、アプリが他のアプリから依存されるとは、そのアプリの有する後述する公開サービスが他のアプリによって利用されることを示すものとする。

図１は、本実施形態に係る画像形成装置１００を備えるシステムの一例を示す図である。画像形成装置１００は、組み込み機器であり、後述する管理フレームワーク（ＦＷ）３０２によってインストール処理などのアプリの制御を行う情報処理装置である。本実施形態に係る画像形成装置１００は、記録媒体上に画像を形成する複合機であるものとして説明を行うが、管理ＦＷ３０２によるアプリの制御が行われる装置であれば特にこれに限定されるわけではない。情報処理装置１０１は、例えばパーソナルコンピュータなどであり、画像形成装置１００を利用すること、及び画像形成装置１００上で動作するアプリを管理することができる。画像形成装置１００は、ネットワーク１２０を介して情報処理装置１０１と接続されていてもよい。

以下、本実施形態に係る情報処理装置１０１は、ネットワークを通じて画像形成装置１００上で動作するアプリを管理する、画像形成装置１００とは別個の装置であるものとして説明を行うが、特にそのように限定されるわけではない。例えば、画像形成装置１００と情報処理装置１０１とが同一の装置に含まれていてもよい。また、後述する管理ＦＷ３０２は、画像形成装置１００が有しているものとして説明を行うが、画像形成装置１００とは別個の装置内に存在していてもよく、例えば情報処理装置１０１が有していてもよい。

図２は、画像形成装置１００のハードウェア構成の一例を示すブロック図である。図２に示される画像形成装置１００は一般的な複合機と同様の構成を有するため、詳細な説明は省略する。コア部２００は、スキャナ部２０４、プリンタ部２０５、及びフィニッシャー部２０６などの、画像形成装置１００全体の動作を制御する。ユーザインターフェース２０１は、外部の装置から情報を取得、又は外部の装置へと情報を出力するためのインターフェースである。記憶装置２０２は、詳細は後述するが、インストール用ファイル置き場、インストールリスト、及びインストールアプリ領域内に情報を格納する。ネットワークインターフェース部２０３は、ネットワーク１２０への接続を行う。

スキャナ部２０４は、文書などの画像を読み取って画像データを生成し、コア部２００を介してプリンタ部２０５へと入力する。プリンタ部２０５は、スキャナ部２０４が生成した画像データを画像として記録媒体上に形成し、成果物を生成する。フィニッシャー部２０６は、プリンタ部２０５が生成した成果物を、例えばホチキス留めなどでまとめる。

［アプリ制御］
まず、本実施形態に係る画像形成装置１００上で行われる、アプリの制御処理について説明を行う。本実施形態においては、画像形成装置上の管理ＦＷ３０２が、記憶装置２０２に格納されているインストールリストの記載に従って標準アプリのインストール処理を行っている（後述）。

図３は、本実施形態に係る画像形成装置１００においてアプリが実行されるシステム構成の一例を示すブロック図である。本実施形態においては説明のため、アプリの実行環境としてＪａｖａ（登録商標）が用いられ、各アプリはＪａｖａプログラムで記述されるものとして説明を行うが、同様の処理を行うことができるのであれば特にこれらに限定されるわけではない。なお、本実施形態においては、図３に示される構成はＪａｖａの実行環境として一般的なものが用いられるため、詳細な説明は省略する。

実行環境３０１は、ユーザが画像形成装置１００の電源を入れた場合に動き出し、アプリを実行可能にするために必要な管理ＦＷ３０２を起動する。管理ＦＷ３０２は、アプリのインストール又はアンインストールを管理する。また、管理ＦＷ３０２は、各アプリのマニフェストファイルを参照して、そのアプリが他のアプリにどのプログラムを公開するか、又は他のアプリのどのプログラムを利用するか、を判断することができる。以下、このようにアプリが他のアプリに向けて公開可能であるプログラムを公開サービスと呼び、アプリが利用する他のアプリのプログラムを参照サービスと呼ぶものとして説明を行う。

アプリ３１０、アプリ３１１、及びアプリ３１２は、画像形成装置１００上で動作するアプリである。本実施形態に係るアプリには、公開サービスを有するものと、他のアプリが有する公開サービスを参照サービスとして呼び出して利用するものと、が存在する。アプリ３１０及びアプリ３１２は同じ公開サービスを有し、アプリ３１１はアプリ３１０及び３１２が有する公開サービスを参照サービスとして利用する。以下、他のアプリが有する公開サービスを参照サービスとして利用することを、単に「利用する」と呼ぶものとする。本実施形態においては、画像形成装置１００上で上述の３つのアプリが動作するものとして説明を行うが、特にこれらのアプリに限定されるわけではなく、アプリの数も３つには限定されない。例えば、２種類以上の公開サービス又は参照サービスを有するアプリが動作していてもよく、公開サービスも参照サービスも有さないアプリが動作していてもよい。また、アプリ３１０〜３１２は、それぞれを識別するためのＡｐｐ−ＩＤとしてＡｐｐＡ、ＡｐｐＢ、及びＡｐｐＣを有する。

クラスローダ群３３１は、管理ＦＷ３０２のプログラムの一部であり、各アプリのプログラムをロードするクラスローダを含む。本実施形態においては、クラスローダ群３３１は、画像形成装置上で動作するアプリ（３１０〜３１２）それぞれに対応するクラスローダ（３３１０〜３３１２）を含んでいる。実行環境３０１においては、記憶装置２０２に格納されたプログラムファイルがメモリ内に読み込まれることにより、プログラムが実行される。プログラムファイルとしては、各プログラムをクラス単位で記載したクラスファイルが用いられてもよい。また、複数のクラスファイルを１つのＪａｒファイルとして含むものがプログラムファイルとして用いられてもよい。本実施形態においては、Ｊａｒファイルに含まれるクラスファイルをメモリ内に読み込むことを指して、クラス（プログラム）をロードすると呼ぶ。Ｊａｒファイルは、アプリのプログラムファイル及びマニフェストファイルなどを有している。本実施形態においては、クラスローダが対応するアプリのクラスファイルをロードすることにより、実行環境３０１上でアプリが動作する。

クラスローダは、Ｊａｒファイル又はプログラムを読み込むために、コンピュータ資源であるファイルディスクリプタを消費する。クラスローダは、クラスをロードしている間はファイルディスクリプタを消費し続ける。本実施形態に係るシステムにおいては、管理ＦＷ３０２がプログラムファイルの削除指示を出した場合であっても、そのプログラムに対応するファイルディスクリプタが消費されている間はプログラムの削除が行われない。また、ライブラリ３４０は、アプリが画像形成装置１００の様々な機能を利用するために用いられるサポートライブラリである。

図４は、記憶装置２０２に格納されている各ファイルを説明するための図である。図４（ａ）は、記憶装置２０２に格納されている各ファイルのイメージ図の一例を示している。記憶装置２０２は、インストール用ファイル置き場、インストールリスト（後述する４１０及び５０２）、並びにインストールアプリ領域を有している。インストール用ファイル置き場は、管理ＦＷ３０２にアプリのインストール指示を行う際に必要となるアプリのＪａｒファイルを格納している。インストールアプリ領域は、過去にインストール済みのアプリ（すなわち、実行環境３０１上で動作するアプリ）を格納している。管理ＦＷ３０２は、アプリのインストール処理の際に、そのアプリ用のディレクトリをインストールアプリ領域内に作成し、そこにアプリのＪａｒファイル内にあるプログラムファイルとマニフェストファイルとを展開する。管理ＦＷ３０２は、インストール済みのアプリのマニフェストファイルを参照する場合にも、インストールアプリ領域内の情報を参照することができる。一方で、管理ＦＷ３０２は、インストール前のアプリのマニフェストファイルを参照する際は、インストール用ファイル置き場のＪａｒファイルからマニフェストファイルの情報を取得してもよい。

図４（ｂ）は、各アプリのマニフェストファイルを模式的に表した図の一例である。図４（ｂ）の例では、マニフェスト４０１〜４０３はそれぞれアプリ３１０〜３１２のマニフェストファイルである。マニフェスト４０１は、管理ＦＷ３０２がアプリを識別するための”Ａｐｐ−ＩＤ”、及びアプリのバージョンを識別するための”Ｖｅｒｓｉｏｎ”の各項目を格納する。マニフェスト４０１内では、”Ａｐｐ−ＩＤ”の項目には”ＡｐｐＡ”の値が格納され、”Ｖｅｒｓｉｏｎ”の項目には”１．０．０”の値が格納されている。

また、マニフェスト４０１は、アプリ３１０が公開する公開サービスを示す”Ｅｘｐｏｒｔ−Ｐａｃｋａｇｅ”、及び参照サービスを示す”Ｉｍｐｏｒｔ−Ｐａｃｋａｇｅ”の各項目も格納する。アプリが公開サービスを有さない場合には”Ｅｘｐｏｒｔ−Ｐａｃｋａｇｅ”の項目は空欄となり、アプリが呼び出す参照サービスがない場合には”Ｉｍｐｏｒｔ−Ｐａｃｋａｇｅ”の項目が空欄となる。マニフェスト４０１内では、”Ｅｘｐｏｒｔ−Ｐａｃｋａｇｅ”の項目に、プログラム名である”ｏｒｇ．ｓｅｒｖｉｃｅ．ＯｐｅｎＳｅｒｖｉｃｅ”が値として格納され、”Ｉｍｐｏｒｔ−Ｐａｃｋａｇｅ”の項目は空欄となっている。なお、このように格納される値は対応するプログラムを指定できるのであればプログラム名に限定されるわけではなく、例えばワイルドカード＊を用いた”ｏｒｇ．ｓｅｒｖｉｃｅ．＊”のように名前空間を指定する値であってもよい。

さらに、マニフェスト４０１は、管理ＦＷ３０２がアプリを実行する際に呼び出す”Ａｃｔｉｖａｔｏｒ”を指定する項目を格納する。また、マニフェスト４０１は、クラスローダがアプリのプログラムをロードするために必要なプログラムファイルを検索する場所を指定する”ＣｌａｓｓＰａｔｈ”の項目も格納する。本実施形態においては、クラスローダは、”ＣｌａｓｓＰａｔｈ”に記載された範囲でプログラムファイルを検索し、プログラムファイルが見つかった場合にロードを行ってもよい。マニフェスト４０１内では、”Ａｃｔｉｖａｔｏｒ”の項目には”ＡｐｐＡＡｃｔ”の値が格納され、”ＣｌａｓｓＰａｔｈ”の項目には”ＡｐｐＡ”の値が格納されている。

なお、マニフェスト４０２及び４０３もマニフェスト４０１と同様の項目を格納し、各項目にそれぞれＡｐｐＢ及びＡｐｐＣに対応する情報を格納する。上述したようにアプリ３１０とアプリ３１２とは同様の公開サービスを有するため、マニフェスト４０３内の項目”Ｅｘｐｏｒｔ−Ｐａｃｋａｇｅ”には”ｏｒｇ．ｓｅｒｖｉｃｅ．ＯｐｅｎＳｅｒｖｉｃｅ”が値として格納されている。また、マニフェスト４０２内の項目”Ｉｍｐｏｒｔ−Ｐａｃｋａｇｅ”には”ｏｒｇ．ｓｅｒｖｉｃｅ．ＯｐｅｎＳｅｒｖｉｃｅ”が値として格納されている。

図４（ｃ）は、インストールリストの一例を示す図である。インストールリストは、標準アプリのＡｐｐ−ＩＤを予めリストとして記載している。管理ＦＷ３０２は、インストールリストに記載されたＡｐｐ−ＩＤに対応する標準アプリをインストールする。本実施形態においては、管理ＦＷ３０２は、ファームウェアの更新後の起動処理時にインストールリストを参照し、記載されているアプリをインストールする。インストールリスト４１０においては、アプリ３１０とアプリ３１１とに対応するＡｐｐ−ＩＤが記載されている。

図５は、インストールリストと、インストール済みアプリの公開サービス及び参照サービスと、を説明するための模式図の一例である。図５（ａ）はファームウェアの更新前の情報を示す図であり、図５（ｂ）は更新後の情報を示す図である。インストールリスト４１０は図４（ｃ）に示されたものと同じであり、インストール済みアプリを示す表５０１にはＡｐｐＡとＡｐｐＢとについての情報（ここでは、公開サービスと参照サービスとの情報）が記載されている。

以下、インストールリスト４１０を参照して管理ＦＷ３０２が標準アプリのインストールを行う例について説明を行う。管理ＦＷ３０２は、インストールリスト４１０にＡｐｐＡとＡｐｐＢとが記載されているため、これらをＡｐｐ−ＩＤとして有するアプリがインストール用ファイル置き場に存在するかどうかを確認する。この場合では、インストール用ファイル置き場にＡｐｐＡであるアプリ３１０とＡｐｐＢであるアプリ３１１とのＪａｒファイルが存在するため、管理ＦＷ３０２はこれらのアプリをインストールする。結果として、アプリ３１０とアプリ３１１とがインストール済みとなるため、表５０１にはこれらのアプリがインストール済みアプリとして列挙されている。そのために、例えば、画像形成装置１００に初めからインストールしておくべき標準アプリに関しては、インストール用ファイル置き場に予め対応するＪａｒファイルを格納させておいてもよい。本実施形態においては、管理ＦＷ３０２は、画像形成装置１００の初回起動時にＪａｒファイルを利用して標準アプリのインストール処理を行う。

次いで、ファームウェアの更新を行った後の画像形成装置１００の起動処理において、インストールリスト５０２を参照して管理ＦＷ３０２が標準アプリのインストールを行う例について説明を行う。インストールリスト５０２は、ファームウェアの更新を行った後のインストールリストであり、アプリ３１０とアプリ３１１とに加えてアプリ３１２に対応するＡｐｐ−ＩＤ（ＡｐｐＣ）が記載されている。ここでは、インストール用ファイル置き場にアプリ３１２のＪａｒファイルが格納されているものとする。管理ＦＷ３０２は、インストールリストを確認し、インストールされていないアプリが記載されている場合はそのアプリのインストールを行う。図５（ｂ）の例では、管理ＦＷ３０２は、インストールリスト５１０からＡｐｐＡとＡｐｐＢとの記載を確認するが、これらのアプリは既にインストール済みであるため、インストール処理を行わない。一方で、ＡｐｐＣのインストールは行われていないため、管理ＦＷ３０２はＡｐｐＣに対応するアプリ３１２のインストール処理を行う。表５０３には、アプリ３１０とアプリ３１１とに加えてアプリ３１２がインストール済みアプリとして列挙されている。また、管理ＦＷ３０２は、インストール済みアプリのＪａｒファイルを確認し、バージョンが増えている場合にアプリのアップデートを行ってもよい。

［管理ＦＷ３０２］
上述のように、画像形成装置１００は、インストールされるべき標準アプリを示す情報に基づいて、格納しているアプリから候補アプリを選択し、候補アプリが格納している他のアプリから依存されていない場合に、その候補アプリを削除する。すなわち、上述のようなインストールリストから記載が削除されたアプリを削除候補となる候補アプリとして選択し、候補アプリを削除するべきか否かの判定を行う。以下においては、画像形成装置１００が有する管理ＦＷ３０２が行う処理についての説明を図１０及び図６を参照して行う。

図１０は、本実施形態に係る管理ＦＷ３０２の機能構成の一例を示すブロック図である。管理ＦＷ３０２は、取得部１１０１、選択部１１０２、判定部１１０３、削除部１１０４、及び登録部１１０５を有する。

取得部１１０１は、記憶装置２０２に格納されている（インストール済み）アプリを示す情報を取得する。本実施形態においては、取得部１１０１は、インストール済みアプリを示す情報として、インストールアプリ領域に含まれる各アプリのマニフェストファイルからＡｐｐ−ＩＤを取得する。なお、取得部１１０１は、インストール済みアプリを示す情報として取得したものから、ユーザ指示で後入れした追加アプリケーション（追加アプリ）の情報を除いてもよい。取得部１１０１は、例えば、各アプリのマニフェストファイルに記載されている追加アプリか否かを示す属性を参照し、追加アプリではないアプリ（すなわち、標準アプリ）それぞれについてインストール済みアプリを示す情報を取得することができる。また例えば、取得部１１０１は、追加アプリのインストールを行う際にそのアプリにフラグをセットしておくことにより各アプリが追加アプリか否かの判断を行ってもよく、その判断方法は限定されない。なお、以下、標準アプリと追加アプリとの区別が必要ない場合には、単に「アプリ」と呼ぶものとする。

また、取得部１１０１は、標準アプリを示す情報を取得する。本実施形態においては、取得部１１０１は、標準アプリを示す情報として、インストールリストに記載されている各アプリのＡｐｐ−ＩＤを取得する。

なお、取得部１１０１による情報の取得処理は、ユーザ所望のタイミングで行われてもよいが、本実施形態においては画像形成装置１００のファームウェアの更新を行った後の起動処理の、標準アプリのインストールが完了した後に行われるものとして説明を行う。

選択部１１０２は、取得部１１０１が取得した情報に基づいて、記憶装置２０２に格納されているアプリから削除候補となる候補アプリを選択する。本実施形態においては、選択部１１０２は、インストール済みアプリのＡｐｐ−ＩＤから、標準アプリのＡｐｐ−ＩＤと重複していないものを候補アプリとして選択する。

判定部１１０３は、インストールアプリ領域に含まれる各アプリのマニフェストファイルに基づいて、候補アプリが、記憶装置２０２に格納されている他のアプリから依存されているかどうかを判定する。そのために、判定部１１０３は、各アプリのマニフェストファイルを参照し、候補アプリの項目”Ｅｘｐｏｒｔ−Ｐａｃｋａｇｅ”と、他のアプリの項目”Ｉｍｐｏｒｔ−Ｐａｃｋａｇｅ”とに格納されている値を取得する。次いで、”Ｅｘｐｏｒｔ−Ｐａｃｋａｇｅ”に示される公開サービスを”Ｉｍｐｏｒｔ−Ｐａｃｋａｇｅ”に示される参照サービスとして呼び出すアプリがあるか否かを判定することにより、上述の判定を行う。

削除部１１０４は、候補アプリが他のアプリから依存されていない場合に、その候補アプリを記憶装置２０２から削除する。登録部１１０５は、インストール済みのアプリごとにクラスローダを生成し、クラスローダに対応するアプリのクラスファイルをロードする場所を指定する情報を登録する。本実施形態においては、登録部１１０５は、クラスローダごとにＣｌａｓｓＰａｔｈの情報を登録する。このような処理によれば、無用なクラスローダの生成が行われないため、削除されるクラスがロードされることもなくなり、ファイルディスクリプタが消費される又はされ続けることもなくなる。

なお、削除部１１０４は、候補アプリの公開サービスを利用するアプリが存在する場合であっても、共通する公開サービスを有するアプリが他に存在する場合には、その候補アプリを削除してもよい。例えば、図５（ａ）の表５０１に示されるようなアプリのインストール状況では、ＡｐｐＡが候補アプリとなった場合に、ＡｐｐＡの公開サービスがＡｐｐＢの参照サービスとして指定されているため、ＡｐｐＡの削除は行われない。一方で、図５（ｂ）に示されるようなアプリのインストール状況では、ＡｐｐＡが候補アプリとなった場合に、ＡｐｐＡの公開サービスと同じプログラムをＡｐｐＣも公開しているため、ＡｐｐＢはＡｐｐＣの公開サービスを利用することができる。したがって、ＡｐｐＡが削除されたとしてもＡｐｐＢに影響を与えることがないため、削除部１１０４はＡｐｐＡの削除を行うことができる。

本実施形態においては、例えば図１１に示される各処理部は、専用のハードウェアによって実現される。しかしながら、管理ＦＷ３０２の有する一部又は全部の処理部が、コンピュータにより実現されてもよい。本実施形態では、上述の各実施形態に係る処理の少なくとも一部がコンピュータにより実行される。

図１２はコンピュータの基本構成を示す図である。図１２においてプロセッサ１２０１は、例えばＣＰＵであり、コンピュータ全体の動作をコントロールする。メモリ１２０２は、例えばＲＡＭであり、プログラム及びデータ等を一時的に記憶する。コンピュータが読み取り可能な記憶媒体１２０３は、例えばハードディスク又はＣＤ−ＲＯＭ等であり、プログラム及びデータ等を長期的に記憶する。本実施形態においては、記憶媒体１２０３が格納している、各部の機能を実現するプログラムが、メモリ１２０２へと読み出される。そして、プロセッサ１２０１が、メモリ１２０２上のプログラムに従って動作することにより、各部の機能が実現される。

図１２において、入力インターフェース１２０４は外部の装置から情報を取得するためのインターフェースである。また、出力インターフェース１２０５は外部の装置へと情報を出力するためのインターフェースである。バス１２０６は、上述の各部を接続し、データのやりとりを可能とする。

以下、画像形成装置１００のファームウェアの更新を行った後の起動時に行われる、標準アプリをインストールした後の処理を説明する。図６は、標準アプリのインストール処理を完了した管理ＦＷ３０２が行う処理の一例を示すフローチャートである。ステップＳ６０１で取得部１１０１は、インストールアプリ領域に含まれる各アプリのマニフェストファイルからＡｐｐ−ＩＤを取得する。ステップＳ６０２で取得部１１０１は、標準アプリを示す情報として、インストールリストに記載されている各アプリのＡｐｐ−ＩＤを取得する。ステップＳ６０３で選択部１１０２は、ステップＳ６０１及びステップＳ６０２で取得したＡｐｐ−ＩＤに基づいて、候補アプリが存在するかどうかを判定する。候補アプリが存在する場合には処理はステップＳ６０４へと進み、そうでない場合には処理はステップＳ６１０へと進む。

ステップＳ６０４で判定部１１０３は、インストールアプリ領域に含まれる候補アプリのマニフェストファイルを参照し、項目”Ｅｘｐｏｒｔ−Ｐａｃｋａｇｅ”の値を取得する。ステップＳ６０５で判定部１１０３は、ステップＳ６０４で参照した項目が空欄でなかったかどうか、つまりその候補アプリが公開サービスを有しているかどうかを判定する。公開サービスを有している場合には処理はステップＳ６０６へと進み、そうでない場合には処理はステップＳ６０９へと進む。

ステップＳ６０６で判定部１１０３は、インストールアプリ領域に含まれる、候補アプリを除いたアプリのマニフェストファイルを参照し、各アプリの項目”Ｉｍｐｏｒｔ−Ｐａｃｋａｇｅ”の値を取得する。ステップＳ６０７で判定部１１０３は、ステップＳ６０６で取得した値から、ステップＳ６０４で取得した値と重複する値が存在するか否かを判定する。つまり、判定部１１０３は、候補アプリが有する公開サービスを利用するアプリが存在するか否かを判定する。存在する場合には処理はステップＳ６０８へと進み、そうでない場合は処理はステップＳ６０９へと進む。

ステップＳ６０８で判定部１１０３は、他のアプリから利用される候補アプリが有する公開サービスと同じ公開サービスを有する他のアプリが、インストールアプリ領域に存在していないか否かを判定する。存在していない場合は処理はステップＳ６１０へと進み、そうでない場合は処理はステップＳ６０９へと進む。

ステップＳ６０９で削除部１１０４は、候補アプリのアンインストール処理を行う。削除部１１０４は、インストールアプリ領域から候補アプリの情報を削除することにより、候補アプリのアンインストール処理を行うことができる。アンインストール処理の後、処理はステップＳ６１０へと進む。ステップＳ６１０で登録部１１０５は、インストールアプリ領域に記載されているアプリごとにクラスローダを生成して各クラスローダに対応するアプリのＣｌａｓｓＰａｔｈ情報を登録し、処理を終了する。

このような処理によれば、インストールリストには存在しないがインストール済みである候補アプリを、その候補アプリが他のアプリによって利用されていない場合に削除することができる。したがって、ストレージ領域などのコンピュータ資源の消費を抑えることができる。

［実施形態２］
実施形態１に係る画像形成装置は、インストールされているアプリの状況に応じて候補アプリを選択してアンインストールするか否かの判定処理を行った。しかしながら、例えば、ユーザ指示によって追加アプリがアンインストールされた際に、候補アプリの公開サービスを利用するアプリが存在しなくなる場合がある。そのような場合、公開サービスを利用するアプリが存在しなくなった候補アプリを削除しても他のアプリの動作には影響が出ないため、候補アプリの削除によってコンピュータ資源の消費を抑えることができるようになる。そのような観点から、実施形態２に係る画像形成装置は、追加アプリのアンインストールによって候補アプリの公開サービスを利用するアプリがなくなった場合に、その候補アプリのアンインストール処理を行う。なお、本実施形態に係る画像形成装置及び情報処理装置は、図１、２、及び図１０に示されるものと基本的には同様の構成を有するため、重複する説明は省略する。

図７（ａ）は、本実施形態に係る画像形成装置においてアプリが実行されるシステム構成の一例を示すブロック図である。図７（ａ）に示されるシステム構成は、アプリ３１１及びアプリ３１２の代わりにアプリ７０１（ＡｐｐＸ）が実行されることを除いて図３と同様の構成を有するため、重複する説明は省略する。アプリ７０１は追加アプリであり、詳細な説明は後述する。

図７（ｂ）は、アプリ７０１のマニフェストファイルを模式的に表した図の一例である。マニフェスト７０２は、実施形態１におけるマニフェスト４０１〜４０３と同様の項目を格納し、項目”Ｉｍｐｏｒｔ−Ｐａｃｋａｇｅ”に”ｏｒｇ．ｓｅｒｖｉｃｅ．ＯｐｅｎＳｅｒｖｉｃｅ”の値を格納している。

図７（ｃ）は、インストールリストの一例を示す図である。本実施形態においては元々インストールリストにアプリ３１０が記載されており、アプリ３１０とアプリ７０１とのインストール処理がなされた後に、インストールリストからアプリ３１０の記載が削除されている。インストールリスト７０３においては、元々はアプリ３１０に対応するＡｐｐ−ＩＤであるＡｐｐＡが記載されていたが、ファームウェアの更新によりその記載は削除されている。また、インストール済みアプリを示す表７０４にはＡｐｐＡとＡｐｐＸについての情報が記載されている。

図８（ａ）は、本実施形態に係る画像形成装置が行う処理の一例を示すフローチャートである。図８（ａ）に示される処理は、ステップＳ６０８に後続するステップＳ８０１を有することを除き図６に示されるものと同様の処理を行うため、重複する説明は省略する。ステップＳ８０１で登録部１１０５は、候補アプリが有する公開サービスを利用する記憶装置２０２内のアプリを識別する情報を記憶し、処理をステップＳ６１０へと進める。

本実施形態に係る画像形成装置は、追加アプリのアンインストール処理が行われた場合に、その追加アプリが利用する公開サービスを有する候補アプリを削除することができる。図８（ｂ）は、追加アプリをアンインストールした場合に行われる、本実施形態に係る画像形成装置が有する管理ＦＷ３０２による処理の一例を示すフローチャートである。ステップＳ８０２で管理ＦＷ３０２は、アンインストールされた追加アプリが、ステップＳ８０１で情報を記録されたアプリであるかどうかを判定する。記録されている場合には処理はステップＳ８０３へと進み、そうでない場合は処理が終了する。

ステップＳ８０３で管理ＦＷ３０２は、アンインストールした追加アプリと共通の参照サービスを呼び出すアプリが記憶装置２０２内に存在していないかどうかを判定する。管理ＦＷ３０２は、例えば、アンインストールした追加アプリと共通の参照サービスを呼び出すアプリが全てアンインストールされているかどうかを確認することにより、ステップＳ８０３における判定を行ってもよい。存在していない場合には処理はステップＳ８０３へと進み、そうでない場合は処理が終了する。

ステップＳ８０４で管理ＦＷ３０２は、アンインストールした追加アプリが利用するプログラムを公開サービスとしているアプリを削除し、処理を終了する。図７の例においては、アンインストールしたアプリ７０１による参照サービスをアプリ３１０が公開サービスとして有しており、アプリ３１０のアンインストール処理が行われる。

このような処理によれば、追加アプリのアンインストール処理の結果として公開サービスを利用するアプリがなくなった候補アプリが存在する場合に、その候補アプリを削除することができる。したがって、ストレージ領域などのコンピュータ資源の消費を抑えることができる。

［実施形態３］
画像形成装置１００の起動処理後に追加アプリをインストールした場合に、インストールしたアプリが候補アプリと同一の公開サービスを有している場合がある。そのような場合には、候補アプリを削除しても他のアプリの動作に影響を及ぼすことがないため、候補アプリの削除によってコンピュータ資源の消費を抑えることができる。本実施形態に係る画像形成装置は、追加アプリの有する公開サービスを特定し、特定した公開サービスが候補アプリの有する公開サービスと同一である場合に、その候補アプリを削除する。以下、そのように同一となる公開サービスを指して、共通サービスと呼ぶものとする。なお、本実施形態に係る画像形成装置及び情報処理装置は、図１、２、及び図１０に示されるものと基本的には同様の構成を有するため、重複する説明は省略する。

図９（ａ）は、本実施形態に係る画像形成装置においてアプリが実行されるシステム構成の一例を示すブロック図である。図９（ａ）に示されるシステム構成は、アプリ３１２の代わりにアプリ９０１（ＡｐｐＹ）が実行されることを除いて図３と同様の構成を有するため、重複する説明は省略する。アプリ９０１は追加アプリであり、詳細な説明は後述する。

図９（ｂ）は、アプリ９０１のマニフェストファイルを模式的に表した図の一例である。マニフェスト９０２は、実施形態１におけるマニフェスト４０１〜４０３と同様の項目を格納し、項目”Ｅｘｐｏｒｔ−Ｐａｃｋａｇｅ”に”ｏｒｇ．ｓｅｒｖｉｃｅ．ＯｐｅｎＳｅｒｖｉｃｅ”の値を格納している。

図９（ｃ）は、インストールリストの一例を示す図である。本実施形態においては元々インストールリストにアプリ３１０とアプリ３１１とが記載されていたが、ファームウェアの更新によりアプリ３１０の記載が削除されている。インストールリスト９０３においては、元々はアプリ３１０とアプリ３１１とに対応するＡｐｐ−ＩＤであるＡｐｐＡとＡｐｐＢとが記載されていたが、ファームウェアの更新によりＡｐｐＡの記載は削除されている。また、インストール済みアプリを表す表９０４にはＡｐｐＡとＡｐｐＢとについての情報が記載されている。

図１０（ａ）は、本実施形態に係る画像形成装置が有する管理ＦＷ３０２が行う処理の一例を示すフローチャートである。図１０（ａ）に示される処理は、ステップＳ６０８に後続するステップＳ１００８を有することを除き図６に示されるものと同様の処理を行うため、重複する説明は省略する。ステップＳ１００８で登録部１１０５は、候補アプリが有する公開サービスの情報を記憶装置２０２に格納し、処理をステップＳ６１０へと進める。

本実施形態に係る画像形成装置は、追加アプリのインストール処理が行われた場合に、その追加アプリと同一の公開サービスを有する候補アプリを削除することができる。図１０（ｂ）は、追加アプリをインストールした場合に行われる、本実施形態に係る画像形成装置が有する管理ＦＷ３０２による処理の一例を示すフローチャートである。ステップＳ１００２で管理ＦＷ３０２は、インストールした追加アプリの有する公開サービスが、ステップＳ１００１で情報を格納した公開サービスであるかどうか、すなわち共通サービスであるかどうかを判定する。そうである場合には処理がステップＳ１００３へと進み、そうでない場合は処理は終了する。

ステップＳ１００３で管理ＦＷ３０２は、インストールアプリ領域を参照して、インストール済みアプリそれぞれの参照サービスを示す情報を取得する。ステップＳ１００４で管理ＦＷ３０２は、共通サービスを利用するアプリの動作を停止する。ステップＳ１００４の処理は、共通サービスを利用するアプリの数だけ繰り返される。

ステップＳ１００５で管理ＦＷ３０２は、公開サービスとして共通サービスを有する候補アプリのアンインストール処理を行う。管理ＦＷ３０２は、インストールアプリ領域から候補アプリの情報を削除することにより、候補アプリのアンインストール処理を行うことができる。ステップＳ１００６で管理ＦＷ３０２は、ステップＳ１００４で動作を停止させた、共通サービスを利用するアプリの動作を再開させる。ステップＳ１００６の処理は、共通サービスを利用するアプリの数だけ繰り返され、完了した時点で処理を終了する。図９に示される例においては、アプリ３１０とアプリ９０１とが共通サービスを有するため、アプリ３１０のアンインストール処理が行われる。

このような処理によれば、追加アプリのインストール処理の結果として共通サービスを有する候補アプリが発生した場合に、その候補アプリを削除することができる。したがって、ストレージ領域などのコンピュータ資源の消費を抑えることができる。

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

発明は上記実施形態に制限されるものではなく、発明の精神及び範囲から離脱することなく、様々な変更及び変形が可能である。従って、発明の範囲を公にするために請求項を添付する。

１１０１：取得部、１１０２：選択部、１１０３：判定部、１１０４：削除部、１１０５：登録部

Claims (18)

1. 情報処理装置であって、
   前記情報処理装置にインストールされるべき標準アプリケーションを示す第１の情報を取得する第１の取得手段と、
   前記第１の情報に基づいて、前記情報処理装置に格納されているアプリケーションのうち、前記標準アプリケーションではないアプリケーションを、削除候補となる候補アプリケーションとして選択する選択手段と、
   前記情報処理装置に格納されているアプリケーションが依存する依存先アプリケーションを示す第２の情報を取得する第２の取得手段と、
   前記候補アプリケーションが前記依存先アプリケーションに含まれていない場合に、前記候補アプリケーションを前記情報処理装置から削除する削除手段と、
   を備える、情報処理装置。
2. 前記アプリケーションは、他のアプリケーションに利用させるためにプログラムを公開可能であり、
   前記依存先アプリケーションは、他のアプリケーションが利用しているプログラムを公開していることを特徴とする、請求項１に記載の情報処理装置。
3. 前記第１の情報は、前記情報処理装置のファームウェアに関連付けられていることを特徴とする、請求項１又は２に記載の情報処理装置。
4. 前記選択手段は、前記ファームウェアの更新に応じて前記候補アプリケーションを選択することを特徴とする、請求項３に記載の情報処理装置。
5. 前記選択手段は、過去に標準アプリケーションとしてインストールされたアプリケーションを前記候補アプリケーションとして選択することを特徴とする、請求項１乃至４の何れか一項に記載の情報処理装置。
6. 前記削除手段は、前記候補アプリケーションに依存するアプリケーションが全て削除された場合に、前記候補アプリケーションを削除することを特徴とする、請求項１乃至５の何れか一項に記載の情報処理装置。
7. 前記削除手段は、ユーザ指示によって前記情報処理装置からアプリケーションが削除されたことに応じて、前記候補アプリケーションに依存するアプリケーションが全て削除されているかどうかを判定し、前記候補アプリケーションに依存するアプリケーションが全て削除されている場合に、前記候補アプリケーションを削除することを特徴とする、請求項６に記載の情報処理装置。
8. 前記削除手段は、前記候補アプリケーションが前記依存先アプリケーションであると判定した場合、前記候補アプリケーションに依存するアプリケーションを識別する情報を記録し、前記候補アプリケーションに依存するアプリケーションが削除されたことに応じて、前記候補アプリケーションを削除することを特徴とする、請求項１乃至７の何れか一項に記載の情報処理装置。
9. 前記削除手段は、前記候補アプリケーションに依存するアプリケーションが依存できるアプリケーションがインストールされた場合に、前記候補アプリケーションを削除することを特徴とする、請求項１乃至８の何れか一項に記載の情報処理装置。
10. 前記削除手段は、新しいアプリケーションがインストールされたことに応じて、前記情報処理装置に格納されているアプリケーションが前記候補アプリケーションの代わりに新しいアプリケーションに依存できるかどうかを判定し、前記情報処理装置に格納されているアプリケーションが前記新しいアプリケーションに依存できる場合に、前記候補アプリケーションを削除することを特徴とする、請求項１乃至８の何れか一項に記載の情報処理装置。
11. 前記削除手段は、
    前記候補アプリケーションが前記依存先アプリケーションであると判定した場合、前記候補アプリケーションが公開し、前記情報処理装置に格納されているアプリケーションが利用しているプログラムを特定する情報を記録し、
    前記新しいアプリケーションが前記記録されたプログラムを公開している場合に、前記情報処理装置に格納されているアプリケーションが前記新しいアプリケーションに依存できると判定することを特徴とする、請求項１０に記載の情報処理装置。
12. 前記情報処理装置に格納されているアプリケーションが他のアプリケーションに利用させるために公開するプログラムを示す情報と、前記情報処理装置に格納されているアプリケーションが利用する、他のアプリケーションが公開するプログラムを示す情報と、を取得する第３の取得手段をさらに備え、
    前記第２の取得手段は、前記第３の取得手段が取得する情報に基づいて、前記依存先アプリケーションを示す情報を取得することを特徴とする、請求項１乃至１１の何れか一項に記載の情報処理装置。
13. 前記削除手段は、前記候補アプリケーションが前記依存先アプリケーションであっても、前記候補アプリケーションが他のアプリケーションに利用させるために公開するプログラムと同一のプログラムを公開する、前記情報処理装置に格納されているアプリケーションが存在する場合に、前記候補アプリケーションを削除することを特徴とする、請求項１乃至１２の何れか一項に記載の情報処理装置。
14. 前記候補アプリケーションを前記情報処理装置から削除した後に、前記情報処理装置に格納されているアプリケーションを実行する際に読み込むプログラムの場所を示す情報を登録する登録手段をさらに備えることを特徴とする、請求項１乃至１３の何れか一項に記載の情報処理装置。
15. 前記情報処理装置に格納されているアプリケーションは、Ｊａｖａ（登録商標）環境で動作するアプリケーションであることを特徴とする、請求項１乃至１４の何れか一項に記載の情報処理装置。
16. 前記情報処理装置は組み込み機器であることを特徴とする、請求項１乃至１５の何れか一項に記載の情報処理装置。
17. 情報処理装置が行う情報処理方法であって、
    前記情報処理装置にインストールされるべき標準アプリケーションを示す情報を取得する工程と、
    前記情報処理装置に格納されているアプリケーションのうち、前記標準アプリケーションではないアプリケーションを削除候補となる候補アプリケーションとして選択する工程と、
    前記情報処理装置に格納されているアプリケーションが依存するアプリケーションを示す情報を取得する工程と、
    前記候補アプリケーションが前記依存するアプリケーションに含まれていない場合に、前記候補アプリケーションを前記情報処理装置から削除する工程と、
    を備える、情報処理方法。
18. コンピュータを、請求項１乃至１６の何れか一項に記載の情報処理装置の各手段として機能させるためのプログラム。

Images