JP2012155478A - 画像形成装置、装置、画像形成装置の制御方法、およびプログラム - Google Patents

Abstract

【課題】 使用できる機能、ＨＤＤ容量、メモリ容量などが異なる画像形成装置に対して、それぞれの画像形成装置用に上記やアプリケーション名などの宣言値を記載したアプリケーションを宣言値に基づいてインストールできる手段を提供することを目的とする。
【解決手段】 マニフェストファイルの宣言を変更するべきモデルであるかどうかを判別し（Ｓ５０２）、マニフェストファイルの宣言を変更するべきモデル用に追加したマニフェストファイルをデフォルトのマニフェストファイルに上書きする（Ｓ５０４）。
【選択図】 図５

Description

本発明は、フレームワークを具備する画像形成装置、装置、画像形成装置の制御方法、およびプログラムに関する。

アプリケーションの実行開始、停止などアプリケーションのライフサイクルを管理するフレームワークとしてＯＳＧｉ（Ｏｐｅｎ Ｓｅｒｖｉｃｅｓ Ｇａｔｅｗａｙ ｉｎｉｔｉａｔｉｖｅ）ＡｌｌｉａｎｃｅからＯＳＧｉフレームワークが提唱されている。ＯＳＧｉフレームワークでは、アプリケーションの形式をＪａｖａ（登録商標）の圧縮フォーマットであるｊａｒファイルとして規定している。ｊａｒファイルは、複数のクラスファイルをアーカイブとして１つにまとめたものである。内部にＭＡＮＩＦＥＳＴ．ＭＦというマニフェストファイルを１つ持っており、ｊａｒファイルの説明が記載される。このマニフェストファイルにＯＳＧｉ仕様の属性を記載することで、ＯＳＧｉフレームワークは、記載された属性に従ってアプリケーションのライフサイクルを管理する。

例えば、画像形成装置において、アプリケーションを外部からインストールして搭載することが試みられており、上記ＯＳＧｉフレームワークに準拠した仕組みを搭載した画像形成装置も普及している。マニフェストファイルにＯＳＧｉ仕様の属性だけでなく、独自の属性を定義し、拡張したものもみられる。

また、装置のモデルによって使用できる機能の有無、ＨＤＤやメモリの容量に違いがある。作成したアプリケーションがこのような複数の異なるモデルに対してインストール可能であるような仕組みの構築が要望されていた。１つのアプリケーションをインストール先のＨＤＤ残量によってインストール内容を変えることを扱った文献として、特許文献１の方法が開示されている。特許文献１では、ＨＤＤ空き容量が少ない場合、アプリケーションを圧縮して仮インストールし、空き容量が確保された段階で解凍するようなインストール制御をおこなっている。

特開２０００−３０５７５６

しかしながら、従来技術では、使用できる機能の有無、またはＨＤＤ容量、またはメモリ容量などの装置毎に異なる属性に応じて、上述の宣言値、またはアプリケーション名などを変えてインストールすることは考慮されていない。

例えば、ＳＦＰ（Ｓｉｎｇｌｅ Ｆｕｎｃｔｉｏｎ Ｐｒｉｎｔｅｒ）と、ＭＦＰ（Ｍｕｌｔｉ Ｆｕｎｃｔｉｏｎ Ｐｒｉｎｔｅｒ）とでは、搭載しているユニットにも差異がある。また、画像形成装置のリソース量においても、ＭＦＰの方がＳＦＰよりも多い可能性が高い。

そこで本発明では、使用できる機能、またはＨＤＤ容量、またはメモリ容量などが異なる装置に対して、ＯＳＧｉの標準仕様から逸脱することなく、それぞれの装置に適した宣言値に基づきインストールを可能とさせることを目的の１つとする。

本発明の一実施系に係る画像形成装置は、マニフェストの情報を基にアプリケーションをインストールするフレームワークを具備し、前記アプリケーションは印刷ユニット、またはスキャナユニットを制御するためのアプリケーションであり、前記フレームワークを使用する際には利用することが定められた規定マニフェストを用いることを特徴とする画像形成装置であって、前記画像形成装置のモデル情報を基に、前記画像形成装置で前記アプリケーションをインストールする際は前記規定マニフェストの他に別のマニフェストの情報も必要であるか否かを判断する判断手段と、前記判断手段により必要であると判断された場合には、前記別のマニフェストの情報を前記フレームワークへ送信する送信手段と、を有し、前記フレームワークは、前記送信手段により送信された前記別のマニフェストの情報を基にインストールすることを特徴とする。

本発明により、使用できる機能、ＨＤＤ容量、メモリ容量などが異なる画像形成装置に対して、それぞれの画像形成装置用に宣言値を変えたインストールが、例えば、１つのアプリケーションの作成で実現できる。

実施例１におけるシステム構成図である。 実施例１における画像形成装置１０１のハードウェア構成図。 （ａ）実施例１における画像形成装置１０１のソフトウェア構成図。（ｂ）ｉｎｓｔａｌｌｅｒ３０５の構成図。 実施例１におけるマニフェストファイルの構成図。 実施例１におけるｉｎｓｔａｌｌｅｒ３０５により実行されるフローチャート。 実施例１における上書き部３１２により実行されるフローチャート。 実施例１におけるＭＡＮＩＦＥＳＴ．ＭＦを示す図。 実施例１におけるＭＡＮＩＦＥＳＴ＿ＥＸ．ＭＦを示す図。 実施例１における再圧縮後ＭＡＮＩＦＥＳＴ．ＭＦを示す図。

本発明の一実施系に係る発明の目的について説明する。ＯＳＧｉフレームワークでは、ｊａｒファイルに含まれるＭＡＮＩＦＥＳＴ．ＭＦという名称のマニフェストファイルを読み込む仕様となっている。モデルによって使用できる機能の有無、ＨＤＤやメモリの容量に違いのある場合、マニフェストファイルのＯＳＧｉ仕様の属性値をモデルごとに設定したいケースがある。その場合、ＯＳＧｉの仕様では、マニフェストファイルを複数用意したアプリケーションを作成したとしても、ＯＳＧｉフレームワークがマニフェストファイルを読み分けすることができない。そのため、マニフェストファイルの記載を変更したアプリケーションをモデルごとに作成する必要があった。よって、１つのアプリケーションであっても、２つのパッケージに分ける必要があり、アプリケーションの管理が煩雑になるというデメリットがある。また、アプリケーション提供者としては、ユーザが所有する画像形成装置のモデルに応じて、同じアプリケーションであっても、提供するアプリケーションを変える必要があった。

本発明は、使用できる機能の有無、またはＨＤＤ容量、またはメモリ容量などの画像形成装置毎に異なる属性に応じて、マニフェストの宣言値、またはアプリケーション名などを変えてインストールすることを１つの目的とする。

以下に、図面を参照して、この発明の好適な実施の形態を例示的に詳しく説明する。ただし、この実施の形態に記載されている構成要素はあくまで例示であり、この発明の範囲をそれらのみに限定する趣旨のものではない。

図１は、本発明の好適な実施の形態に係る情報処理装置を含むネットワークシステムの構成図である。図１の１０１は、一台でプリンタ、スキャナー、コピー機、ＦＡＸなどの機能を兼ね備える画像形成装置１０１である。画像形成装置１０１上には複数のアプリケーションがインストール可能で、画像形成装置１０１は画像形成装置に割り当てられた固有の機器ＩＤを有する。１０２は、情報処理装置１０２であり、画像形成装置１０１の操作をリモートで行うために使用される。１０３はインターネットなどのネットワーク１０３であり、画像形成装置１０１は、ネットワーク１０３を介して情報処理装置１０２と通信を行うことができる。

図２は、情報処理装置１０２を構成するハードウェア構成を示す図である。１０２は、情報処理装置１０２である。２０２は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）であり、各種プログラムを実行し、様々な機能を実現するユニットである。２０４は、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）であり、各種プログラムを記憶するユニットである。２０３は、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）であり、ＣＰＵ２０２は、ＲＯＭ２０４に記憶されているプログラムをＲＡＭ２０３にロードしプログラムを実行する。

また、ＲＡＭ２０４は、ＣＰＵ２０２の一時的な作業記憶領域としても利用されるユニットである。Ｉｎｐｕｔ／Ｏｕｔｐｕｔインターフェース２０５は、各装置、および各サーバ群に接続されているディスプレイ（不図示）にデータを送信する他、ポインティングデバイス（不図示）からデータを受信するインターフェースユニットである。ＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）２０６は、画像形成装置１０１に接続するためのユニットである。以上説明してきたユニットは、バス２０７を介してデータの送受信を行うことが可能である。

また、画像形成装置１０１は、図２に示す構成の他に、印刷ユニット（不図示）、および／またはスキャナユニット（不図示）を搭載している。なお、ＭＦＰの場合は、印刷ユニット、スキャナユニットの他に、その他ユニットを搭載している。逆にＳＦＰの場合は、スキャナユニットを搭載しておらず、印刷ユニットのみの構成とする。印刷ユニットは、バス２０７を介して各ユニットとデータを送受信することが可能である。なお、印刷ユニットは、ラスタイメージを始めとする各種イメージデータを記録媒体に印刷、または外部装置へ送信することが可能なユニットである。スキャナユニットは、原稿台の上に置かれた原稿を読み取り、イメージデータを生成するユニットである。

図３（ａ）は画像形成装置１０１のソフトウェア構成を示す図である。ここに示されている各構成部を実現するプログラムはＲＯＭ２０４に記憶されている。そして、それらのプログラムはＲＡＭ２０３にロードされ、ＣＰＵ２０２が実行することで、各構成部が実現される。３０２はアプリケーションをインストールするためのＰＣアプリ３０２であり、情報処理装置１０２が具備するものである。ＰＣアプリ３０２は、ＮＩＣ２０６を介し、ＡＰＩ３０４を利用してインストール処理をｉｎｓｔａｌｌｅｒ３０５に依頼する。３０３はアプリケーション管理アプリ３０３であり、ユーザに対して、アプリケーションを指示するための画面を表示する他、ｉｎｓｔａｌｌｅｒ３０５に対してアプリケーションのインストール指示を行う。なお、情報処理装置１０２は、ＮＩＣ２０６を介し、アプリケーション管理アプリケーション３０３にアクセスすることが可能である。アプリケーション管理アプリ３０３は、ｉｎｓｔａｌｌｅｒ３０５を介して、ＯＳＧｉフレームワーク３０６にインストール処理を依頼する。Ｉｎｓｔａｌｌｅｒ３０５の詳細については後述する。

ＯＳＧｉフレームワーク３０６は、ｉｎｓｔａｌｌｅｒ３０５からのインストール依頼を基に、指定されたアプリケーションをインストールする他、アプリケーションの起動、および停止を行う。また、本願発明のＯＳＧｉフレームワーク３０６は、ＯＳＧｉ Ａｌｌｉａｎｃｅで定められた標準フレームワークの仕様に準拠している。そして、本願発明では、ＯＳＧｉフレームワーク３０６の構成を、ＯＳＧｉで定められた標準仕様を逸脱した作りにすることなく目的を達成する。

仮想マシン３０７はアプリケーションを実行するための実行環境であり、例えば、Ｊａｖａ（登録商標）の仮想マシンなどにより実現されるものである。仮想マシン３０７は、第１の実行環境であるＯＳ３０８上で実現される実行環境であり、Ｊａｖａ（登録商標）ベースで記述されたアプリケーションを実行するための第２の実行環境である。このような環境を画像形成装置１０１に具備させることで、画像形成装置１０１が生産された後でも、画像形成装置１０１の印刷ユニット、またはスキャナユニットを制御するためのアプリケーションをインストール、および実行させることが可能になる。ＯＳ３０８は、画像形成装置全体を制御する実行環境である。また、ＯＳ３０８は、複写機の各種機能をリアルタイムに制御可能なリアルタイムＯＳの各モジュール、あるいは、クリティカルに複写機のオプション装置、および拡張カードを含む各機能を制御することが可能なライブラリ群である。そして、その上位で動作するアプリケーションに対して、インタフェースコマンドを提供するモジュール群により実現されるものである。

次に、ｉｎｓｔａｌｌｅｒ３０５について図３（ｂ）を用いて説明する。図３（ｂ）は、ｉｎｓｔａｌｌｅｒ３０５の構成図である。３１０はモデル判定部３１０であり、画像形成装置１０１がＭＦＰであるＳＦＰであるかを判別する。なお、画像形成装置１０１には、モデル情報が用意されている。画像形成装置１０１がＭＦＰであるかＳＦＰであるかを基に、夫々異なるモデル情報が用意されており、モデル判定部３１０は、それを基に判別処理を行う。インストール指示部３１１は、ＯＳＧｉフレームワーク３０６に対し、アプリケーションのインストール依頼を行う。

上書き部３１２は、後述する規定マニフェストの一部に、別のマニフェストの宣言値を上書きする処理を行う。解凍部３１３は、アプリケーション管理アプリ３０３、またはＰＣアプリ３０２からインストール指示されたアプリケーションを解凍する。制限判定部３１４は、マニフェストファイルの上書きをする際の制限事項の判定を行う。再圧縮部３１５は、実行ファイル、および上書き部３１２により別のマニフェストの宣言値が上書きされた規定マニフェストを含むファイル形式を再圧縮する。

［アプリケーションの作成］
図４は本発明で提案するアプリケーションのマニフェストファイルのディレクトリ構成である。なお、アプリケーションは、このマニフェストファイル、および実行ファイルを含むファイル形式を圧縮したものを指す。また、マニフェストと、マニフェストファイルは同義である。

ｊａｒコマンドでｊａｒファイルを作成する場合、４０１のＭＥＴＡ−ＩＮＦフォルダに４０２のＭＡＮＩＦＥＳＴ．ＭＦファイルが自動的に生成される。自動的に生成される４０２のＭＡＮＩＦＥＳＴ．ＭＦに加え、本発明ではマニフェストファイルの宣言値を変更したいモデル用に変更したいマニフェスト項目を記載するため、４０３のＭＡＮＩＦＥＳＴ＿ＥＸ．ＭＦを用意する。４０１のＭＥＡＴＡ−ＩＮＦフォルダに上記ファイルを含めて、ｊａｒファイル形式のアプリケーションを作成する。

そして、自動的に生成されるＭＡＮＩＦＥＳＴ．ＭＦを規定マニフェストと呼び、規定マニフェストとは別に用意されたＭＡＮＩＦＥＳＴ＿ＥＸ．ＭＦを別のマニフェストと呼ぶ。なお、ＯＳＧｉの標準に準拠した場合、ＯＳＧｉフレームワーク３０６は規定マニフェストであるＭＡＮＩＦＥＳＴ．ＭＦに記載されている宣言値のみしか読み込まない。そのため、本願発明の画像形成装置１０１は、解凍部３１３、および上書き部３１２、および再圧縮部３１５を具備している。そして、一度アプリケーションを解凍し、規定マニフェストの宣言値を書き換え、圧縮することで、ＯＳＧｉの標準を逸脱することなく、画像形成装置１０１のモデル毎に最適なマニフェストが使用されることになる。

［アプリケーションのインストール処理］
ユーザは、上述のアプリケーションを、３０２のＰＣアプリ、または３０３のアプリケーション管理アプリが提供するＵＩ画面からアプリケーションの指定を行ってインストールを行う。入力されたアプリケーションに対してｉｎｓｔａｌｌｅｒ３０５は、ＯＳＧｉフレームワーク３０６に対してインストール処理の依頼を行う。

図５は、ｉｎｓｔａｌｌｅｒ３０５の処理を示す図であり、インストール処理の指示を受けてから、ＯＳＧｉフレームワーク３０６へインストール処理を依頼するまでの処理を示したフローチャート図である。Ｓ５０１で処理が開始される。Ｓ５０２で、解凍部３１３は、ｊａｒファイル形式のアプリケーションを解凍する。Ｓ５０３で、モデル判別部３１０は、自画像形成装置がマニフェストファイルの宣言値を変更したいモデルかどうかを、モデル情報を基に判断する。マニフェストファイルの宣言値を変更したいモデルでなければ、Ｓ５０７において、インストール指示部３１１は、ＯＳＧｉフレームワーク３０６にインストールを依頼し、Ｓ５０８で処理を終える。この場合、画像形成装置１０１はＭＦＰであり、かつＭＡＮＩＦＥＳＴ．ＭＦもＭＦＰ用に用意されたマニフェストであるため、上書き処理が実行されない。

マニフェストファイルの宣言値を変更したいモデルであれば、上書き部３１２は、Ｓ５０４でアプリケーションに含まれるマニフェストファイルＭＡＮＩＦＥＳＴ＿ＥＸ．ＭＦの宣言値を、ＭＡＮＩＦＥＳＴ．ＭＦの一部に上書きする。上書きするロジックは後述の図６で説明する。そして、Ｓ５０５で、上書き部３１２は、不要になったマニフェストファイルであるＭＡＮＩＦＥＳＴ＿ＥＸ．ＭＦを削除する。その後、Ｓ５０６で、再圧縮部３１５は、実行ファイル、および規定マニフェストから構成されるファイル形式をｊａｒファイル形式で再圧縮し、アプリケーションを保存する。その後、Ｓ５０７で、インストール指示部３１１は、再圧縮部３１５により再圧縮されたアプリケーションのインストールの依頼を、ＯＳＧｉフレームワークに対し行う。そして、Ｓ５０８で処理が終了される。

以上の処理により、ＯＳＧｉフレームワーク３０６は、モデル情報に応じて、規定マニフェストの情報のみでインストールする処理、または規定マニフェストと別のマニフェストの情報の両方を基にインストールする処理の内、いずれか１つの処理でインストールを行うことになる。このように、インストールしたいアプリケーションに関連づいたマニフェストを用いてインストールが行われる。

Ｉｎｓｔａｌｌｅｒ３０５に図３（ｂ）に示す構成を具備させ、図５に示す処理を実行させることにより、複数の異なる画像形成装置に対して共通のアプリケーションを作成し、ＯＳＧｉフレームワークの修正を行わずにＯＳＧｉの仕様に従ったインストールを行うことが可能となる。

図６は、Ｓ５０４で示す上書きの手順を示したフローチャートである。Ｓ６０１で処理が開始される。Ｓ６０２で、上書き部３１２は、ＭＡＮＩＦＥＳＴ＿ＥＸ．ＭＦに記載されている一行目の属性、即ち宣言値を参照する。Ｓ６０３で、上書き部３１２は、現在参照している属性が、後述する上書き指定可能な属性かどうかを判断する。上書き指定可能な属性だった場合、Ｓ６０４で、参照している属性と一致するＭＡＮＩＦＥＳＴ．ＭＦの属性値を、ＭＡＮＩＦＥＳＴ＿ＥＸ．ＭＦの属性値で上書きし、Ｓ６０５でＭＡＮＩＦＥＴ＿ＥＸ．ＭＦの次の行の属性の確認に処理を進める。Ｓ６０３で、上書き指定可能な属性でないと判断された場合、Ｓ６０５でＭＡＮＩＦＥＴ＿ＥＸ．ＭＦの次の行の属性に進み、Ｓ６０６で属性が存在するかどうかを判断する。属性が存在しなければ、Ｓ６０７で処理を終了する。属性が存在していれば、Ｓ６０３へ処理が戻る。

図７の７０１は、４０２で示すＭＡＮＩＦＥＳＴ．ＭＦの宣言値を示す。７０２は、バンドルのベンダ名を示す。７０３は、バンドルのバージョンを示す。７０４はバンドルの名称を示す。７０５は、アプリの最大メモリ使用量を示す。７０６は、最大スレッド使用量を示す。７０７は最大ディスクスペースを示す。ＭＡＮＩＦＥＳＴ．ＭＦは、ＭＦＰ用のマニフェストである。

図８の８０１は、４０３で示すＭＡＮＩＦＥＳＴ＿ＥＸ．ＭＦである。８０２で「ＭａｘｉｍｕｍＭｅｍｏｒｙＵｓａｇｅ」、８０３で「ＭａｘｉｍｕｍＦｉｌｅｓｐａｃｅＵｓａｇｅ」を記載しており、マニフェストファイルの宣言値を変更したいモデルでこれら２つの項目を変更したい場合の記述である。夫々、アプリケーションを実行する際に利用するメモリ量、ＨＤＤ量を宣言した値である。アプリケーション実行時にはこれらの値を参考に実行される。ＭＡＮＩＦＥＳＴ＿ＥＸ．ＭＦは、ＭＦＰ用のマニフェストの一部の宣言値を上書きする際に利用される。なお、ＭＦＰ用のマニフェストは、ＳＦＰ用のマニフェストと比較し、リソースの使用量の値が大きく設定されている。これは、ＭＦＰがＳＦＰと比べて保有しているリソース量が多いためである。ＭＦＰでは、アプリケーション実行の際に利用するリソース量が大きく確保されているため、ＳＦＰで実行するときと比較し、より高速に処理することが可能になる。

図９の９０１はアプリケーションのインストール先がマニフェストファイルの宣言値を変更したいモデルであった場合にＳ５０４で作成される、規定マニフェストであるＭＡＮＩＦＥＳＴ．ＭＦである。８０２と同じ属性の７０５を上書きし、８０３と同じ属性の７０７を上書きする。９０２，９０３，９０４，９０６の項目は７０１の値と同一であり、９０５、９０７の項目が８０１のＭＡＮＩＦＥＳＴ＿ＥＸ．ＭＦの値となっていることが分かる。

ここで、図５について補足する。本実施例では示さなかったが、Ｓ５０２と、Ｓ５０３の間に次の様な処理を行っても良い。即ち、従来のアプリケーションを読み込んだ時の処理である。従来のアプリケーションには、規定マニフェストのみしか含まれていない。その場合、上書き処理を行うことができない。そこで、Ｓ５０２の後に、解凍したアプリケーションの中に、規定マニフェストとは異なる別のマニフェストが含まれているか否かの判定を行う。そして、含まれていなかった場合には、Ｓ５０７の処理へ進み、ＯＳＧｉフレームワーク３０６によりインストールが行われる。この処理を設けることで、本実施例で示した新しいアプリケーションの他に、既に市場に出回っている従来のアプリケーションにも対応した画像形成装置１０１を提供できる。

以上、画像形成装置のモデル情報に応じて、ＯＳＧｉフレームワークで定められた第１のマニフェストのみを利用してインストールするか、または規定されていない第２のマニフェストも利用してインストールするかを切り替えるｉｎｓｔａｌｌｅｒについて説明した。このｉｎｓｔａｌｌｅｒにより、フレームワークの仕様を、ＯＳＧｉの標準から逸脱することなく作成でき、かつ画像形成装置のモデル毎にアプリケーションを用意する必要がなくなる。結果、アプリケーション提供者は、ユーザが所有する画像形成装置のモデルに関わらず、所定のアプリケーションのみさえ提供すれば良いことになる。

［制限事項］
最後に、Ｓ６０３の判断で使用する制限事項について説明する。ＰＣアプリ３０２、およびアプリケーション管理アプリケーション３０３は、アプリケーションのインストール指示時に、ＭＡＮＩＦＥＳＴ．ＭＦの一部の属性を参照して属性値を１０２の画面上に表示している。表示される属性・属性値はＰＣアプリ３０２、アプリケーション管理アプリケーション３０３で異なる。表示される属性の属性値を、ＭＡＮＩＦＥＳＴ＿ＥＸ．ＭＦに記載して変更を許してしまうと、アプリケーション側でＭＡＮＩＦＥＳＴ＿ＥＸ．ＭＦのほうを参照して表示するように修正しなければならない。このような影響を避けるため、ＭＡＮＩＦＥＳＴ＿ＥＸ．ＭＦに記載可能な属性を限定する。記載可能な属性以外の属性を記載した場合、上書きされず無視されることとする。

上書きが可能なマニフェスト属性としては、ＭａｘｉｍｕｍＭｅｍｏｒｙＵｓａｇｅ、ＭａｘｉｍｕｍＦｉｌｅＳｐａｃｅＵｓａｇｅなどが挙げられる。また、上書きが不可なマニフェスト属性としては、Ｂｕｎｄｌｅ−Ｖｅｎｄｅｒ、Ｂｕｎｄｌｅ−Ｎａｍｅなどが挙げられる。

（変化形）
上述の実施例では、Ｍａｎｉｆｅｓｔ＿ＥＸ．ＭＦの内容を、Ｍａｎｉｆｅｓｔ．ＭＦに上書きする方法について開示した。しかしながら、Ｍａｎｉｆｅｓｔ．ＭＦを削除し、Ｍａｎｉｆｅｓｔ＿ＥＸ．ＭＦのファイル名をＭａｎｉｆｅｓｔ．ＭＦに書き換えることでも本発明を達成することは可能である。その場合、Ｍａｎｉｆｅｓｔ＿ＥＸ．ＭＦには、図９に示すように始めからインストールに必要な情報を全て記載しておく必要がある。なお、実施例１の場合、開発者がＭａｎｉｆｅｓｔ＿ＥＸ．ＭＦを作成するときに、変更点のみ記載すればよいので、変化形と比較し開発者の開発工数は低減している。

なお、上述の実施例ではＭＦＰ、またはＳＦＰと言った画像形成装置の機種を基に区別を行い、モデル情報の設定を行った。即ち、ＭＦＰを示すフラグ、またはＳＰＦを示すフラグが画像形成装置１０１に保存されていることになる。しかしながら、これに限定される必要はない。例えば、メモリ量、ＣＰＵ量、搭載しているオプション等の情報を基に区別しても良く、これに応じてモデル情報を設定しても良い。その場合、例えば、ある閾値以上のメモリ量を持つ画像形成装置にフラグ「０」を、また、ある閾値未満のメモリ量しか持たない画像形成装置にフラグ「１」を割り当てれば良い。また、デバイスＩＤの様に機種、または固有の画像形成装置のＩＤを基にマニフェストの扱い方を区別し、それに応じてモデル情報を設定しても良い。また、リソース、オプション等を増設したことに応じて、モデル情報を途中から切り替えても良い。これにより、今現在使用している画像形成装置の状況に応じた適切なインストールを行うことが可能になる。

上述の実施例ではモデル判別部３１０を設けたが、モデル判別部３１０を設けずに、別のマニフェストが必要であるか否かを予め画像形成装置１０１に設定し、別のマニフェストが必要であるか否かを判別する判別手段を設けておいても良い。

２０１ 複数の有効期限付きアプリケーションが動作する画像形成装置
２０２ 画像形成装置２０１におけるＳｃａｎ機能部
２０３ 画像形成装置２０１におけるＰｒｉｎｔ機能部
２０４ 画像形成装置２０１におけるＦＡＸ機能部
２０５ 画像形成装置２０１におけるジョブ制御機能部
２０６ 画像形成装置２０１におけるネットワーク機能部
２０７ 画像形成装置２０１におけるＵＩ機能部
２０８ 画像形成装置２０１におけるユーザ認証機能部
２０９ 画像形成装置２０１における時間管理機能部
２１０ 画像形成装置２０１におけるアプリケーション機能部

Claims (9)

1. マニフェストの情報を基にアプリケーションをインストールするフレームワークを具備し、前記アプリケーションは印刷ユニット、またはスキャナユニットを制御するためのアプリケーションであり、前記フレームワークを使用する際には利用することが定められた規定マニフェストを用いることを特徴とする画像形成装置であって、
   前記画像形成装置のモデル情報を基に、前記画像形成装置で前記アプリケーションをインストールする際は前記規定マニフェストの他に別のマニフェストの情報も必要であるか否かを判断する判断手段と、
   前記判断手段により必要であると判断された場合には、前記別のマニフェストの情報を前記フレームワークへ送信する送信手段と、を有し、
   前記フレームワークは、前記送信手段により送信された前記別のマニフェストの情報を基にインストールすることを特徴とする画像形成装置。
2. マニフェストの情報を基にアプリケーションをインストールするフレームワークを具備し、前記フレームワークを使用する際には利用することが定められた規定マニフェストを用いることを特徴とする装置であって、
   前記装置のモデル情報を基に、前記装置で前記アプリケーションをインストールする際は前記規定マニフェストの他に別のマニフェストの情報も必要であるか否かを判断する判断手段と、
   前記判断手段により必要ないと判断された場合には、前記別のマニフェストの情報は送信せずに前記規定マニフェストの情報を前記フレームワークへ送信し、必要であると判断された場合には、前記規定マニフェストの情報のみならず前記別のマニフェストの情報も前記フレームワークへ送信する送信手段と、を有し、
   前記フレームワークは、前記送信手段により前記規定マニフェストの情報、および前記別のマニフェストの情報が送信された場合は、両方の情報を基に前記アプリケーションをインストーすることを特徴とする装置。
3. 前記規定マニフェストの一部に、前記別のマニフェストの情報を上書きする上書き手段を更に有し、
   前記送信手段は、前記上書き手段により前記規定マニフェストの一部に別のマニフェストの情報が上書きされた規定マニフェストを送信することで、前記規定マニフェストの情報、および前記別のマニフェストの情報を送信することを特徴とする請求項２に記載の装置。
4. 前記規定マニフェスト、および前記別のマニフェストには、前記アプリケーションに割り当てられるメモリ量を宣言した宣言値が記載されており、
   前記上書き手段は、前記アプリケーションに割り当てられるメモリ量を宣言した宣言値を上書きすることを特徴とする請求項３に記載の装置。
5. 前記アプリケーションは、実行ファイル、およびマニフェストを含むファイル形式を圧縮した形式であって、
   前記アプリケーションを解凍する解凍手段と、
   前記解凍手段により解凍された後に、前記実行ファイル、および前記上書き手段により前記規定マニフェストの一部に別のマニフェストの情報が上書きされた規定マニフェストを含むファイル形式を再び圧縮する圧縮手段と、を有すことを特徴とする請求項３、または４に記載の装置。
6. 前記アプリケーションは、印刷ユニット、またはスキャナユニットを制御するためのアプリケーションであり、前記装置は画像形成装置であることを特徴とする請求項２乃至５のいずれか１項に記載の装置。
7. アプリケーションをインストールする際に用いられるマニフェストの情報を基に前記アプリケーションをインストールするフレームワークを具備し、前記アプリケーションは印刷ユニット、またはスキャナユニットを制御するためのアプリケーションであることを特徴とする画像形成装置であって、
   少なくとも第１のマニフェスト、および第２のマニフェストの両方と関連づいたアプリケーションのインストール依頼を受ける受信手段と、
   前記フレームワークは、前記受信手段により依頼が受け付けられた際に、前記画像形成装置のモデル情報に応じて、前記第１のマニフェストの情報を用いて前記アプリケーションをインストールする方法、または前記第１のマニフェストの情報、および前記第２のマニフェストの情報の両方のマニフェストの情報を用いて前記アプリケーションをインストールする方法の内、いずれか１つの方法で前記アプリケーションをインストールする画像形成装置。
8. マニフェストの情報を基にアプリケーションをインストールするフレームワークを具備し、前記アプリケーションは印刷ユニット、またはスキャナユニットを制御するためのアプリケーションであり、前記フレームワークを使用する際には利用することが定められた規定マニフェストを用いることを特徴とする画像形成装置を制御する制御方法であって、
   判断手段は、前記画像形成装置のモデル情報を基に、前記画像形成装置で前記アプリケーションをインストールする際は前記規定マニフェストの他に別のマニフェストの情報も必要であるか否かを判断し、
   送信手段は、前記判断手段により必要であると判断された場合には、前記別のマニフェストの情報を前記フレームワークへ送信し、
   前記フレームワークは、前記送信手段により送信された前記別のマニフェストの情報を基にインストールすることを特徴とする画像形成装置を制御する制御方法。
9. 請求項８に記載の制御方法を画像形成装置に実行させるためのプログラム。

Images