説明

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

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

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、フレームワークを具備する画像形成装置、装置、画像形成装置の制御方法、およびプログラムに関する。
【背景技術】
【0002】
アプリケーションの実行開始、停止などアプリケーションのライフサイクルを管理するフレームワークとしてOSGi(Open Services Gateway initiative)AllianceからOSGiフレームワークが提唱されている。OSGiフレームワークでは、アプリケーションの形式をJava(登録商標)の圧縮フォーマットであるjarファイルとして規定している。jarファイルは、複数のクラスファイルをアーカイブとして1つにまとめたものである。内部にMANIFEST.MFというマニフェストファイルを1つ持っており、jarファイルの説明が記載される。このマニフェストファイルにOSGi仕様の属性を記載することで、OSGiフレームワークは、記載された属性に従ってアプリケーションのライフサイクルを管理する。
【0003】
例えば、画像形成装置において、アプリケーションを外部からインストールして搭載することが試みられており、上記OSGiフレームワークに準拠した仕組みを搭載した画像形成装置も普及している。マニフェストファイルにOSGi仕様の属性だけでなく、独自の属性を定義し、拡張したものもみられる。
【0004】
また、装置のモデルによって使用できる機能の有無、HDDやメモリの容量に違いがある。作成したアプリケーションがこのような複数の異なるモデルに対してインストール可能であるような仕組みの構築が要望されていた。1つのアプリケーションをインストール先のHDD残量によってインストール内容を変えることを扱った文献として、特許文献1の方法が開示されている。特許文献1では、HDD空き容量が少ない場合、アプリケーションを圧縮して仮インストールし、空き容量が確保された段階で解凍するようなインストール制御をおこなっている。
【先行技術文献】
【特許文献】
【0005】
【特許文献1】特開2000−305756
【発明の概要】
【発明が解決しようとする課題】
【0006】
しかしながら、従来技術では、使用できる機能の有無、またはHDD容量、またはメモリ容量などの装置毎に異なる属性に応じて、上述の宣言値、またはアプリケーション名などを変えてインストールすることは考慮されていない。
【0007】
例えば、SFP(Single Function Printer)と、MFP(Multi Function Printer)とでは、搭載しているユニットにも差異がある。また、画像形成装置のリソース量においても、MFPの方がSFPよりも多い可能性が高い。
【0008】
そこで本発明では、使用できる機能、またはHDD容量、またはメモリ容量などが異なる装置に対して、OSGiの標準仕様から逸脱することなく、それぞれの装置に適した宣言値に基づきインストールを可能とさせることを目的の1つとする。
【課題を解決するための手段】
【0009】
本発明の一実施系に係る画像形成装置は、マニフェストの情報を基にアプリケーションをインストールするフレームワークを具備し、前記アプリケーションは印刷ユニット、またはスキャナユニットを制御するためのアプリケーションであり、前記フレームワークを使用する際には利用することが定められた規定マニフェストを用いることを特徴とする画像形成装置であって、前記画像形成装置のモデル情報を基に、前記画像形成装置で前記アプリケーションをインストールする際は前記規定マニフェストの他に別のマニフェストの情報も必要であるか否かを判断する判断手段と、前記判断手段により必要であると判断された場合には、前記別のマニフェストの情報を前記フレームワークへ送信する送信手段と、を有し、前記フレームワークは、前記送信手段により送信された前記別のマニフェストの情報を基にインストールすることを特徴とする。
【発明の効果】
【0010】
本発明により、使用できる機能、HDD容量、メモリ容量などが異なる画像形成装置に対して、それぞれの画像形成装置用に宣言値を変えたインストールが、例えば、1つのアプリケーションの作成で実現できる。
【図面の簡単な説明】
【0011】
【図1】実施例1におけるシステム構成図である。
【図2】実施例1における画像形成装置101のハードウェア構成図。
【図3】(a)実施例1における画像形成装置101のソフトウェア構成図。(b)installer305の構成図。
【図4】実施例1におけるマニフェストファイルの構成図。
【図5】実施例1におけるinstaller305により実行されるフローチャート。
【図6】実施例1における上書き部312により実行されるフローチャート。
【図7】実施例1におけるMANIFEST.MFを示す図。
【図8】実施例1におけるMANIFEST_EX.MFを示す図。
【図9】実施例1における再圧縮後MANIFEST.MFを示す図。
【発明を実施するための形態】
【0012】
本発明の一実施系に係る発明の目的について説明する。OSGiフレームワークでは、jarファイルに含まれるMANIFEST.MFという名称のマニフェストファイルを読み込む仕様となっている。モデルによって使用できる機能の有無、HDDやメモリの容量に違いのある場合、マニフェストファイルのOSGi仕様の属性値をモデルごとに設定したいケースがある。その場合、OSGiの仕様では、マニフェストファイルを複数用意したアプリケーションを作成したとしても、OSGiフレームワークがマニフェストファイルを読み分けすることができない。そのため、マニフェストファイルの記載を変更したアプリケーションをモデルごとに作成する必要があった。よって、1つのアプリケーションであっても、2つのパッケージに分ける必要があり、アプリケーションの管理が煩雑になるというデメリットがある。また、アプリケーション提供者としては、ユーザが所有する画像形成装置のモデルに応じて、同じアプリケーションであっても、提供するアプリケーションを変える必要があった。
【0013】
本発明は、使用できる機能の有無、またはHDD容量、またはメモリ容量などの画像形成装置毎に異なる属性に応じて、マニフェストの宣言値、またはアプリケーション名などを変えてインストールすることを1つの目的とする。
【0014】
以下に、図面を参照して、この発明の好適な実施の形態を例示的に詳しく説明する。ただし、この実施の形態に記載されている構成要素はあくまで例示であり、この発明の範囲をそれらのみに限定する趣旨のものではない。
【0015】
図1は、本発明の好適な実施の形態に係る情報処理装置を含むネットワークシステムの構成図である。図1の101は、一台でプリンタ、スキャナー、コピー機、FAXなどの機能を兼ね備える画像形成装置101である。画像形成装置101上には複数のアプリケーションがインストール可能で、画像形成装置101は画像形成装置に割り当てられた固有の機器IDを有する。102は、情報処理装置102であり、画像形成装置101の操作をリモートで行うために使用される。103はインターネットなどのネットワーク103であり、画像形成装置101は、ネットワーク103を介して情報処理装置102と通信を行うことができる。
【0016】
図2は、情報処理装置102を構成するハードウェア構成を示す図である。102は、情報処理装置102である。202は、CPU(Central Processing Unit)であり、各種プログラムを実行し、様々な機能を実現するユニットである。204は、ROM(Read Only Memory)であり、各種プログラムを記憶するユニットである。203は、RAM(Random Access Memory)であり、CPU202は、ROM204に記憶されているプログラムをRAM203にロードしプログラムを実行する。
【0017】
また、RAM204は、CPU202の一時的な作業記憶領域としても利用されるユニットである。Input/Outputインターフェース205は、各装置、および各サーバ群に接続されているディスプレイ(不図示)にデータを送信する他、ポインティングデバイス(不図示)からデータを受信するインターフェースユニットである。NIC(Network Interface Card)206は、画像形成装置101に接続するためのユニットである。以上説明してきたユニットは、バス207を介してデータの送受信を行うことが可能である。
【0018】
また、画像形成装置101は、図2に示す構成の他に、印刷ユニット(不図示)、および/またはスキャナユニット(不図示)を搭載している。なお、MFPの場合は、印刷ユニット、スキャナユニットの他に、その他ユニットを搭載している。逆にSFPの場合は、スキャナユニットを搭載しておらず、印刷ユニットのみの構成とする。印刷ユニットは、バス207を介して各ユニットとデータを送受信することが可能である。なお、印刷ユニットは、ラスタイメージを始めとする各種イメージデータを記録媒体に印刷、または外部装置へ送信することが可能なユニットである。スキャナユニットは、原稿台の上に置かれた原稿を読み取り、イメージデータを生成するユニットである。
【0019】
図3(a)は画像形成装置101のソフトウェア構成を示す図である。ここに示されている各構成部を実現するプログラムはROM204に記憶されている。そして、それらのプログラムはRAM203にロードされ、CPU202が実行することで、各構成部が実現される。302はアプリケーションをインストールするためのPCアプリ302であり、情報処理装置102が具備するものである。PCアプリ302は、NIC206を介し、API304を利用してインストール処理をinstaller305に依頼する。303はアプリケーション管理アプリ303であり、ユーザに対して、アプリケーションを指示するための画面を表示する他、installer305に対してアプリケーションのインストール指示を行う。なお、情報処理装置102は、NIC206を介し、アプリケーション管理アプリケーション303にアクセスすることが可能である。アプリケーション管理アプリ303は、installer305を介して、OSGiフレームワーク306にインストール処理を依頼する。Installer305の詳細については後述する。
【0020】
OSGiフレームワーク306は、installer305からのインストール依頼を基に、指定されたアプリケーションをインストールする他、アプリケーションの起動、および停止を行う。また、本願発明のOSGiフレームワーク306は、OSGi Allianceで定められた標準フレームワークの仕様に準拠している。そして、本願発明では、OSGiフレームワーク306の構成を、OSGiで定められた標準仕様を逸脱した作りにすることなく目的を達成する。
【0021】
仮想マシン307はアプリケーションを実行するための実行環境であり、例えば、Java(登録商標)の仮想マシンなどにより実現されるものである。仮想マシン307は、第1の実行環境であるOS308上で実現される実行環境であり、Java(登録商標)ベースで記述されたアプリケーションを実行するための第2の実行環境である。このような環境を画像形成装置101に具備させることで、画像形成装置101が生産された後でも、画像形成装置101の印刷ユニット、またはスキャナユニットを制御するためのアプリケーションをインストール、および実行させることが可能になる。OS308は、画像形成装置全体を制御する実行環境である。また、OS308は、複写機の各種機能をリアルタイムに制御可能なリアルタイムOSの各モジュール、あるいは、クリティカルに複写機のオプション装置、および拡張カードを含む各機能を制御することが可能なライブラリ群である。そして、その上位で動作するアプリケーションに対して、インタフェースコマンドを提供するモジュール群により実現されるものである。
【0022】
次に、installer305について図3(b)を用いて説明する。図3(b)は、installer305の構成図である。310はモデル判定部310であり、画像形成装置101がMFPであるSFPであるかを判別する。なお、画像形成装置101には、モデル情報が用意されている。画像形成装置101がMFPであるかSFPであるかを基に、夫々異なるモデル情報が用意されており、モデル判定部310は、それを基に判別処理を行う。インストール指示部311は、OSGiフレームワーク306に対し、アプリケーションのインストール依頼を行う。
【0023】
上書き部312は、後述する規定マニフェストの一部に、別のマニフェストの宣言値を上書きする処理を行う。解凍部313は、アプリケーション管理アプリ303、またはPCアプリ302からインストール指示されたアプリケーションを解凍する。制限判定部314は、マニフェストファイルの上書きをする際の制限事項の判定を行う。再圧縮部315は、実行ファイル、および上書き部312により別のマニフェストの宣言値が上書きされた規定マニフェストを含むファイル形式を再圧縮する。
【0024】
[アプリケーションの作成]
図4は本発明で提案するアプリケーションのマニフェストファイルのディレクトリ構成である。なお、アプリケーションは、このマニフェストファイル、および実行ファイルを含むファイル形式を圧縮したものを指す。また、マニフェストと、マニフェストファイルは同義である。
【0025】
jarコマンドでjarファイルを作成する場合、401のMETA−INFフォルダに402のMANIFEST.MFファイルが自動的に生成される。自動的に生成される402のMANIFEST.MFに加え、本発明ではマニフェストファイルの宣言値を変更したいモデル用に変更したいマニフェスト項目を記載するため、403のMANIFEST_EX.MFを用意する。401のMEATA−INFフォルダに上記ファイルを含めて、jarファイル形式のアプリケーションを作成する。
【0026】
そして、自動的に生成されるMANIFEST.MFを規定マニフェストと呼び、規定マニフェストとは別に用意されたMANIFEST_EX.MFを別のマニフェストと呼ぶ。なお、OSGiの標準に準拠した場合、OSGiフレームワーク306は規定マニフェストであるMANIFEST.MFに記載されている宣言値のみしか読み込まない。そのため、本願発明の画像形成装置101は、解凍部313、および上書き部312、および再圧縮部315を具備している。そして、一度アプリケーションを解凍し、規定マニフェストの宣言値を書き換え、圧縮することで、OSGiの標準を逸脱することなく、画像形成装置101のモデル毎に最適なマニフェストが使用されることになる。
【0027】
[アプリケーションのインストール処理]
ユーザは、上述のアプリケーションを、302のPCアプリ、または303のアプリケーション管理アプリが提供するUI画面からアプリケーションの指定を行ってインストールを行う。入力されたアプリケーションに対してinstaller305は、OSGiフレームワーク306に対してインストール処理の依頼を行う。
【0028】
図5は、installer305の処理を示す図であり、インストール処理の指示を受けてから、OSGiフレームワーク306へインストール処理を依頼するまでの処理を示したフローチャート図である。S501で処理が開始される。S502で、解凍部313は、jarファイル形式のアプリケーションを解凍する。S503で、モデル判別部310は、自画像形成装置がマニフェストファイルの宣言値を変更したいモデルかどうかを、モデル情報を基に判断する。マニフェストファイルの宣言値を変更したいモデルでなければ、S507において、インストール指示部311は、OSGiフレームワーク306にインストールを依頼し、S508で処理を終える。この場合、画像形成装置101はMFPであり、かつMANIFEST.MFもMFP用に用意されたマニフェストであるため、上書き処理が実行されない。
【0029】
マニフェストファイルの宣言値を変更したいモデルであれば、上書き部312は、S504でアプリケーションに含まれるマニフェストファイルMANIFEST_EX.MFの宣言値を、MANIFEST.MFの一部に上書きする。上書きするロジックは後述の図6で説明する。そして、S505で、上書き部312は、不要になったマニフェストファイルであるMANIFEST_EX.MFを削除する。その後、S506で、再圧縮部315は、実行ファイル、および規定マニフェストから構成されるファイル形式をjarファイル形式で再圧縮し、アプリケーションを保存する。その後、S507で、インストール指示部311は、再圧縮部315により再圧縮されたアプリケーションのインストールの依頼を、OSGiフレームワークに対し行う。そして、S508で処理が終了される。
【0030】
以上の処理により、OSGiフレームワーク306は、モデル情報に応じて、規定マニフェストの情報のみでインストールする処理、または規定マニフェストと別のマニフェストの情報の両方を基にインストールする処理の内、いずれか1つの処理でインストールを行うことになる。このように、インストールしたいアプリケーションに関連づいたマニフェストを用いてインストールが行われる。
【0031】
Installer305に図3(b)に示す構成を具備させ、図5に示す処理を実行させることにより、複数の異なる画像形成装置に対して共通のアプリケーションを作成し、OSGiフレームワークの修正を行わずにOSGiの仕様に従ったインストールを行うことが可能となる。
【0032】
図6は、S504で示す上書きの手順を示したフローチャートである。S601で処理が開始される。S602で、上書き部312は、MANIFEST_EX.MFに記載されている一行目の属性、即ち宣言値を参照する。S603で、上書き部312は、現在参照している属性が、後述する上書き指定可能な属性かどうかを判断する。上書き指定可能な属性だった場合、S604で、参照している属性と一致するMANIFEST.MFの属性値を、MANIFEST_EX.MFの属性値で上書きし、S605でMANIFET_EX.MFの次の行の属性の確認に処理を進める。S603で、上書き指定可能な属性でないと判断された場合、S605でMANIFET_EX.MFの次の行の属性に進み、S606で属性が存在するかどうかを判断する。属性が存在しなければ、S607で処理を終了する。属性が存在していれば、S603へ処理が戻る。
【0033】
図7の701は、402で示すMANIFEST.MFの宣言値を示す。702は、バンドルのベンダ名を示す。703は、バンドルのバージョンを示す。704はバンドルの名称を示す。705は、アプリの最大メモリ使用量を示す。706は、最大スレッド使用量を示す。707は最大ディスクスペースを示す。MANIFEST.MFは、MFP用のマニフェストである。
【0034】
図8の801は、403で示すMANIFEST_EX.MFである。802で「MaximumMemoryUsage」、803で「MaximumFilespaceUsage」を記載しており、マニフェストファイルの宣言値を変更したいモデルでこれら2つの項目を変更したい場合の記述である。夫々、アプリケーションを実行する際に利用するメモリ量、HDD量を宣言した値である。アプリケーション実行時にはこれらの値を参考に実行される。MANIFEST_EX.MFは、MFP用のマニフェストの一部の宣言値を上書きする際に利用される。なお、MFP用のマニフェストは、SFP用のマニフェストと比較し、リソースの使用量の値が大きく設定されている。これは、MFPがSFPと比べて保有しているリソース量が多いためである。MFPでは、アプリケーション実行の際に利用するリソース量が大きく確保されているため、SFPで実行するときと比較し、より高速に処理することが可能になる。
【0035】
図9の901はアプリケーションのインストール先がマニフェストファイルの宣言値を変更したいモデルであった場合にS504で作成される、規定マニフェストであるMANIFEST.MFである。802と同じ属性の705を上書きし、803と同じ属性の707を上書きする。902,903,904,906の項目は701の値と同一であり、905、907の項目が801のMANIFEST_EX.MFの値となっていることが分かる。
【0036】
ここで、図5について補足する。本実施例では示さなかったが、S502と、S503の間に次の様な処理を行っても良い。即ち、従来のアプリケーションを読み込んだ時の処理である。従来のアプリケーションには、規定マニフェストのみしか含まれていない。その場合、上書き処理を行うことができない。そこで、S502の後に、解凍したアプリケーションの中に、規定マニフェストとは異なる別のマニフェストが含まれているか否かの判定を行う。そして、含まれていなかった場合には、S507の処理へ進み、OSGiフレームワーク306によりインストールが行われる。この処理を設けることで、本実施例で示した新しいアプリケーションの他に、既に市場に出回っている従来のアプリケーションにも対応した画像形成装置101を提供できる。
【0037】
以上、画像形成装置のモデル情報に応じて、OSGiフレームワークで定められた第1のマニフェストのみを利用してインストールするか、または規定されていない第2のマニフェストも利用してインストールするかを切り替えるinstallerについて説明した。このinstallerにより、フレームワークの仕様を、OSGiの標準から逸脱することなく作成でき、かつ画像形成装置のモデル毎にアプリケーションを用意する必要がなくなる。結果、アプリケーション提供者は、ユーザが所有する画像形成装置のモデルに関わらず、所定のアプリケーションのみさえ提供すれば良いことになる。
【0038】
[制限事項]
最後に、S603の判断で使用する制限事項について説明する。PCアプリ302、およびアプリケーション管理アプリケーション303は、アプリケーションのインストール指示時に、MANIFEST.MFの一部の属性を参照して属性値を102の画面上に表示している。表示される属性・属性値はPCアプリ302、アプリケーション管理アプリケーション303で異なる。表示される属性の属性値を、MANIFEST_EX.MFに記載して変更を許してしまうと、アプリケーション側でMANIFEST_EX.MFのほうを参照して表示するように修正しなければならない。このような影響を避けるため、MANIFEST_EX.MFに記載可能な属性を限定する。記載可能な属性以外の属性を記載した場合、上書きされず無視されることとする。
【0039】
上書きが可能なマニフェスト属性としては、MaximumMemoryUsage、MaximumFileSpaceUsageなどが挙げられる。また、上書きが不可なマニフェスト属性としては、Bundle−Vender、Bundle−Nameなどが挙げられる。
【0040】
(変化形)
上述の実施例では、Manifest_EX.MFの内容を、Manifest.MFに上書きする方法について開示した。しかしながら、Manifest.MFを削除し、Manifest_EX.MFのファイル名をManifest.MFに書き換えることでも本発明を達成することは可能である。その場合、Manifest_EX.MFには、図9に示すように始めからインストールに必要な情報を全て記載しておく必要がある。なお、実施例1の場合、開発者がManifest_EX.MFを作成するときに、変更点のみ記載すればよいので、変化形と比較し開発者の開発工数は低減している。
【0041】
なお、上述の実施例ではMFP、またはSFPと言った画像形成装置の機種を基に区別を行い、モデル情報の設定を行った。即ち、MFPを示すフラグ、またはSPFを示すフラグが画像形成装置101に保存されていることになる。しかしながら、これに限定される必要はない。例えば、メモリ量、CPU量、搭載しているオプション等の情報を基に区別しても良く、これに応じてモデル情報を設定しても良い。その場合、例えば、ある閾値以上のメモリ量を持つ画像形成装置にフラグ「0」を、また、ある閾値未満のメモリ量しか持たない画像形成装置にフラグ「1」を割り当てれば良い。また、デバイスIDの様に機種、または固有の画像形成装置のIDを基にマニフェストの扱い方を区別し、それに応じてモデル情報を設定しても良い。また、リソース、オプション等を増設したことに応じて、モデル情報を途中から切り替えても良い。これにより、今現在使用している画像形成装置の状況に応じた適切なインストールを行うことが可能になる。
【0042】
上述の実施例ではモデル判別部310を設けたが、モデル判別部310を設けずに、別のマニフェストが必要であるか否かを予め画像形成装置101に設定し、別のマニフェストが必要であるか否かを判別する判別手段を設けておいても良い。
【符号の説明】
【0043】
201 複数の有効期限付きアプリケーションが動作する画像形成装置
202 画像形成装置201におけるScan機能部
203 画像形成装置201におけるPrint機能部
204 画像形成装置201におけるFAX機能部
205 画像形成装置201におけるジョブ制御機能部
206 画像形成装置201におけるネットワーク機能部
207 画像形成装置201におけるUI機能部
208 画像形成装置201におけるユーザ認証機能部
209 画像形成装置201における時間管理機能部
210 画像形成装置201におけるアプリケーション機能部

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

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate

【図9】
image rotate


【公開番号】特開2012−155478(P2012−155478A)
【公開日】平成24年8月16日(2012.8.16)
【国際特許分類】
【出願番号】特願2011−13254(P2011−13254)
【出願日】平成23年1月25日(2011.1.25)
【出願人】(000001007)キヤノン株式会社 (59,756)
【Fターム(参考)】