JP5904800B2 - 装置、制御方法、並びにプログラム - Google Patents

Description

本発明は、アプリケーションをインストール・実行可能な装置、制御方法、並びにプログラムに関するものである。

従来、アプリケーションの実行環境を組み込み、アプリケーションをインストール、実行可能なＭＥＡＰ（キヤノン株式会社の商標）に代表されるような画像形成装置が提供されている。また、ＭＥＡＰにおいてインストール可能なアプリケーションには、通常のアプリケーションのほかに、画像形成装置上での認証を行う認証アプリケーションが存在する。このような画像形成装置では、アプリケーションが使用可能な永続記憶領域（ＨＤＤやＦｌａｓｈＲＯＭなどの不揮発性の記憶領域）のサイズを予め決め、決められた範囲内で各アプリケーションが永続記憶領域を使用する。ＭＥＡＰでは、特許文献１が示すように、各々のアプリケーションが使用する永続記憶領域の使用量を、各アプリケーション内の所定の管理ファイルに宣言させている。更に、各アプリケーションが宣言するサイズの総和が、予め画像形成装置で決められた最大使用可能サイズを超えない範囲でのみ、アプリケーションをインストールする仕組みについても開示されている。

一方、資源が枯渇した場合の対処として、資源枯渇情報を通知するような情報処理装置が特許文献２に開示されている。

特開２００６−３３８２６８ 特開２０１０−１３４８７１

しかしながら、特定の条件下において、アプリケーションの動作障害により、宣言した使用量以上の記憶領域をアプリケーションが使用するケースが起こり得る。例えば、アプリケーションの動作ログなどを累積して記憶するような場合、ログ・サイズの上限を超えて記録するようなケースである。このような状況を放置すると、画像形成装置の資源が枯渇し、正常に動作を続けられなくなる可能性がある。また、別の課題として、資源が枯渇してから通知する機能を設けた場合、その状態ではすでに画像形成装置が使用できない状況に陥っている可能性が高く、使用者の業務が長時間停滞するなどの課題がある。

更に、別の課題として次の様な課題も考えられる。画像形成装置にインストール可能なアプリケーションの種類として、通常のアプリケーションに加え、画像形成装置を利用させるためにユーザ認証を行う認証アプリケーションがある。認証アプリケーションは画像形成装置全体を保護する目的で使用されるため、通常のアプリケーションと比較して運用を適正に行わけなればならない。画像形成装置の不正利用を防ぐためにも、認証アプリケーションは通常のアプリケーションと異なる対応が必要になる。

本願発明は、これらの課題の内、少なくとも１つを解決することが可能な画像形成装置を提供することを目的とする。

アプリケーションのライフ・サイクルを管理し、管理対象のアプリケーションに対応するアプリケーション・ファイルに記載された宣言に従い該アプリケーションを管理するフレームワークを備えた装置であって、
インストールの指示を受けたことに応じて、前記フレームワークに対し対象アプリケーションのインストールを指示する指示手段と、
前記対象アプリケーションに対応するアプリケーション・ファイルに記載されたリソースの使用量の最大値の宣言を前記フレームワークから取得する取得手段と、
インストールされることでアプリケーションに対し固有に割り当てられるリソースであって、前記対象アプリケーションが所定のタイミングで使用しているリソースの使用量を確認する確認手段と、を有し、
前記対象アプリケーションがインストールされた後のタイミングにおいて、前記指示手段は、前記確認手段により確認された前記対象アプリケーションが所定のタイミングで使用しているリソースの使用量が、前記取得手段により取得された前記対象アプリケーションに対応するアプリケーション・ファイルに記載されたリソースの使用量の最大値の宣言を超えていた場合、前記フレームワークに対し前記対象アプリケーションを停止するよう指示し、
前記対象アプリケーションが認証アプリケーションであって、前記認証アプリケーションが所定のタイミングで使用しているリソースの使用量が、前記取得手段により取得された前記対象アプリケーションに対応するアプリケーション・ファイルに記載されたリソースの使用量の最大値の宣言を超えていた場合、前記認証アプリケーションを停止することなく前記装置に備えられた操作画面上のステータスラインにエラーメッセージを表示させることを特徴とする。

本発明によれば、何らかの障害により、アプリケーションが宣言する以上の記憶領域を使用したことを確認し、そのアプリケーションを停止することで画像形成装置全体が使用できなくなる状況を防止できる。

本発明のシステム構成図である。 画像形成装置１０１の装置構成を示すブロック図である。 画像形成装置１０１のソフトウェア構造図である。 アプリケーション・ファイル４００の構造図である。 アプリケーション・リスト５００を図示したものである。 アプリケーションの格納状態を図示したものである。 インストーラ・サービス３０８のアプリケーション一覧画面である。 ジョブ・リストを図示したものである。 資源監視条件の設定画面である。 アプリケーション停止処理の設定画面である。 資源監視を行う際のフローチャートである。 資源超過検知時のフローチャートである。 画像形成装置の操作画面である。 画像形成装置のエラー画面である。 第２の実施例のアプリケーションの格納状態を図示したものである。 第２の実施例の資源監視フローチャートである。 第３の実施例の画像形成装置の１０１のソフトウェア構造図である。 第３の実施例のエラーメッセージ表示画面である。

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

［第１の実施例］
第１の実施形態では、図１に示すように、１０４のネットワークに、１０１の画像形成装置と１０２、１０３のＰＣが通信可能に接続されている。

図２は、画像形成装置１０１の装置構成を示すブロック図である。ＣＰＵ２１０を含む制御部２０９は、画像形成装置１０１全体の動作を制御する。ＣＰＵ２１０は、ＲＯＭ２１１に記憶された制御プログラムを読み出して読取制御や送信制御などの各種制御処理を実行する。ＲＡＭ２１２は、ＣＰＵ２１０の主メモリ、ワークエリア等の一時記憶領域として用いられる。ＨＤＤ２０８は、画像データや各種プログラムを記憶する。

制御部２０９は機能部２０１と接続され、操作部２０２、スキャナ部２０３、プリンタ部２０４の動作を制御する。操作部２０２には、タッチパネル機能を有する液晶表示部やキーボードなどが備えられている。制御部２０９は、各ユニットを制御することで、画像形成処理に関するジョブを発行させるためのサービスをユーザに提供する他、ユーザからの指示により画像形成処理に関するジョブを発行し、かつ発行されたジョブを処理することを可能とする。

スキャナ部２０３は、原稿上の画像を読み取って画像データを生成し、制御部２０９に入力する。プリンタ部２０４は制御部２０９から入力された印刷すべき画像データを記録媒体上に印刷する。インターフェース部２０６は、制御部２０９をＬＡＮ１０４に接続し、ネットワーク上のＰＣ１０２や１０３から印刷用の画像データを受信する、あるいは、スキャナ部２０３で読み取った画面データを送信することが可能である。なお、ＰＣ１０２や１０３から受信した印刷画像は画像メモリ２０７に一時的に格納され、制御部２０９を介してプリンタ部２０４で印刷される。

図３は本発明の画像形成装置の一例である画像形成装置１０１のＨＤＤ２０８に記憶されたソフトウェア構造図である。ＣＰＵ２１０によりこれらのプログラムが実行されることにより、各種機能が実現される。

３０１は、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）であり、一般的にはリアルタイムＯＳが使用されるが、昨今ではＬｉｎｕｘ（登録商標）等の汎用ＯＳが使用されることもある。３０２は、Ｊａｖａ（登録商標）に代表される仮想マシンであり、アプリケーションの実行環境を提供するものである。３０３は、ＪａｖａＶＭ３０２上のアプリケーション・フレームワークであり、ＪａｖａＶＭ３０２上で動作する管理対象のアプリケーションのライフ・サイクルを管理する機能とそれを制御するＩ／Ｆを備えている。ライフ・サイクルとは、アプリケーションのインストール、起動、停止、アンインストールを含むアプリケーションの状態を示すものとする。実施例１におけるアプリケーション・フレームワークは、ＯＳＧｉ（Ｏｐｅｎ Ｓｅｒｖｉｃｅｓ Ｇａｔｅｗａｙ ｉｎｉｔｉａｔｉｖｅ）アライアンスで規定されたＯＳＧｉ（登録商標）である。

ライフ・サイクルを管理するとは、上述したアプリケーションの夫々の状態の何れか１つの状態に遷移した場合、遷移した状態に対応した適切な処理をアプリケーションに施すことを指す。例えば、アプリケーションの状態が起動状態に遷移すれば、アプリケーションが起動するように制御し、アプリケーションの状態がアンインストール状態に遷移すれば、アプリケーションのアンインストールを行う。このように、ＪａｖａＶＭに含まれるフレームワークは、アプリケーションのライフ・サイクルを管理する機能を持っている。なお、アプリケーション・フレームワークは、後述するアプリケーション・ファイルに記載された宣言値に基づきアプリケーションの管理を行う。例えば、アプリケーションに固有に割り当てられているアプリケーション名とインストールされているアプリケーションの実体との紐付け管理や、インストールされているアプリケーションのバージョン情報の管理である。

３０４は、ＪａｖａＶＭ３０２上で動作する機器制御ライブラリであり、後述のＮａｔｉｖｅ機能３０７が提供する、印刷やスキャンなどの画像形成処理を後述のアプリケーションＡ，Ｂから利用できるようにするためのＩ／Ｆを備えている。本Ｉ／Ｆでは、画像形成装置が提供する様々な機能を抽象化し、他の異なる画像形成装置においても、同一の手順で同一の機能が実現できるように構成されている。具体的には、画像形成装置が提供する機能をオブジェクト化し、そのオブジェクトにパラメータを設定、あるいはそのオブジェクトからパラメータを取得するＡＰＩを呼び出すことで様々な情報を設定、取得可能である。また、予め決められた手順に従い、ＡＰＩを呼び出すことで、印刷、およびスキャンなどの機能を実行することが可能である。これにより、ＯＳ３０１とは異なる環境で実行されるアプリケーションであっても、画像形成装置を制御するためのＮａｔｉｖｅ機能を利用することが出来る。

３０５は、ＪａｖａＶＭ３０２上で動作する操作部制御ライブラリであり、後述のアプリケーションＡ，Ｂからの指示により操作部２０２の液晶表示部に操作画面を表示する、あるいは、キー入力などを各アプリケーションに伝える機能と、その機能を利用するためのＩ／Ｆを備えている。３０６は、ＪａｖａＶＭ３０２上で動作する通信制御ライブラリであり、インターフェース部２０６を介し、ＬＡＮ１０４上の他の通信機器と通信する機能とＩ／Ｆを備えている。３０７はＮａｔｉｖｅ機能であり、操作部２０２を使用し、原稿のスキャンやコピー、印刷を始め、ＰＣ１０２等への画像送信等を行う画像形成装置本来の機能を提供するソフトウェアの総称である。

Ｎａｔｉｖｅ機能は、画像形成装置を生産する段階で組み込まれているソフトウェア群であり、ユーザの指示によりインストールされるものではないことに注意されたい。一方で、ＪａｖａＶＭ上のアプリケーションは、ユーザの指示によりインストール可能であり、顧客環境でアプリケーションの管理・操作が可能である。図３に示す通り、Ｎａｔｉｖｅ機能３０７はＯＳ上で動作するソフトウェアであり、一方で、その他のインストーラ・サービス３０８、アプリケーションＡ３１０のようなアプリケーションは、ＪａｖａＶＭ３０２上で動作するソフトウェアである。ネイティブ手段は、Ｎａｔｉｖｅ機能３０７に相当する。

ＪａｖａＶＭ３０２上で動作するアプリケーションは、機器制御ライブラリ３０４を使用することで、異なる画像形成装置においても同一の機器制御を行うことが可能となり、生産段階後の画像形成装置をカスタマイズすることが可能である。ＪａｖａＶＭ３０２上で動作するアプリケーションは、機器制御ライブラリ３０４を介し、画像処理命令を始め、様々な命令をＮａｔｉｖｅ機能３０７へ送信し、Ｎａｔｉｖｅ機能３０７に所定の処理を実行させることが出来る。これにより、画像形成装置が販売され顧客環境に配備された後であっても、顧客であるユーザがアプリケーションを追加することが可能であり、より高いソリューションを提供する画像処理アプリケーションを利用することができる。画像形成装置はアプリケーションをインストールしていくことで進化し、様々なソリューションをユーザに提供できるようになる。

３０８は、インストーラ・サービスであり、後述のアプリケーションＡ，Ｂなど複数のアプリケーションを、アプリケーション・フレームワーク３０３に登録することでインストール処理を行うものである。なお、アプリケーションの状態遷移の指示は、インストーラ・サービスから送信される。インストーラ・サービスは、ユーザに対してアプリケーションの状態を変更させる指示が出せる管理画面を表示し、ユーザは、その管理画面を介してアプリケーションの状態変更の指示を出す。３０９は、システム・サービス群であり、インストーラ・サービス３０８以外の、さまざまな機能をアプリケーションに提供するものであるが、本実施例では特に詳細については触れない。

なお、インストーラ・サービス３０８、およびシステム・サービス群３０９は、Ｎａｔｉｖｅ機能３０７と同様に、画像形成装置を生産する段階で組み込まれているものとする。３１０，３１１は、インストーラ・サービス３０８によってインストールされたアプリケーションであり、画像形成装置１０１上で様々な機能を提供する。アプリケーション３１０，３１１は操作部制御ライブラリ３０５を使用し、操作部２０２を介してユーザとやり取りを行うことが可能である。また、通信制御ライブラリ３０６を使用して、インターフェース部２０６を介して、ＰＣ１０２などからデータを受信し、機器制御ライブラリ３０３を介し、プリンタ部２０４を使って印刷することも可能である。なお、インストーラ・サービス３０８は、ＰＣ１０２、１０３等のブラウザから、インターフェース部２０６を介してアクセスされ、通信制御ライブラリ３０６を使って所定のアプリケーション・ファイルを受信するものとする。アプリケーションを管理するための画面については、後述の図７において説明する。

図４は、本発明のアプリケーションＡ３０９のアプリケーション・ファイル４００の構造図である。４０１は、管理情報部であり、Ｊａｖａ（登録商標）のプログラム・ファイルであればＭＡＮＩＦＥＳＴ．ＭＦに代表されるものである。４０２は、アプリケーション４００のプログラムの実体であり、Ｊａｖａ（登録商標）のプログラム・ファイルであれば、拡張子がｃｌａｓｓのファイル群を示すものである。４１０は、管理情報部４０１の内部の管理情報であり、アプリケーションの属性、または規定に関する宣言である。４１１はアプリケーションを一意に識別するためのＩＤである。本実施例では、アプリケーション毎に個別のＵＵＩＤを定義している。４１２は、アプリケーション・ファイル４００のアプリケーション名である。４１３は、アプリケーション・ファイル４００が画像形成装置１０１上で使用するＨＤＤ２０８の最大サイズである。アプリケーション・ファイル内の管理情報部をマニフェストと称することにする。アプリケーション・ファイルに記載された宣言を基に、アプリケーション・フレームワーク３０３はアプリケーションを管理する。具体的には、アプリケーションの属性、または規定に関する宣言を保存し、問い合わせに対して宣言に関する情報を提供するような管理である。

４１４は、アプリケーション・ファイル４００の種類を識別するための識別情報であり、本実施例においてインストーラ・サービス３０８によりインストールされるアプリケーションＡ３１０は、“Ｎｏｒｍａｌ Ｓｅｒｖｉｃｅ”という情報を持つものとする。“Ｎｏｒｍａｌ Ｓｅｒｖｉｃｅ”とは、顧客環境でインストール、実行され、操作部２０２、あるいはＰＣ１０２等からブラウザを介して画像形成装置１０１が提供する機能をカスタマイズして使用する、アプリケーションを示す。即ち、“Ｎｏｒｍａｌ Ｓｅｒｖｉｃｅ”アプリケーションは、ユーザ、例えば、顧客環境における管理者が、アプリケーションをインストールする操作を行うことでインストールされると言うことである。これにより、画像形成装置１０１は様々な形のソリューションを提供できるようになる。

これ以外の種別としては、認証アプリケーションを示す“Ｌｏｇｉｎ Ｓｅｒｖｉｃｅ”と、予め画像形成装置に組み込まれたインストーラ・サービス３０８やシステム・サービス群３０９を、“Ｓｙｓｔｅｍ Ｓｅｒｖｉｃｅ”を示すものとする。これらのアプリケーションはユーザからの操作ではなく、それ以外の所定の方法によってインストールされるアプリケーションである。所定の方法とは、例えば、画像形成装置が生産された段階で生産者によりインストールされることもあれば、画像形成装置を販売する販売員によりインストールされることもある。このように、画像形成装置を購入した顧客ユーザではなく、それ以外のユーザによってインストールされるのである。なお、管理情報部４０１に格納されるパラメータは、本実施例に記載の項目に限定されるものでないことはいうまでもない。

図５は、本発明のインストーラ・サービス３０８が、アプリケーション・フレームワーク３０３を介して取得した、アプリケーション・リスト５００を図示したものである。インストーラ・サービス３０８は、インストール時にはアプリケーション・ファイルを利用しアプリケーションをインストールするか否かの判断を含む各種制御処理を実行するが、規定の処理が終了すればアプリケーション・ファイルを破棄してしまう。よって、インストーラ・サービス３０８がアプリケーション・ファイルに記載された宣言を確認するためには、アプリケーション・フレームワークからアプリケーション・リスト５００を取得する必要がある。アプリケーション・リスト５００には、アプリケーション・オブジェクトが配列として格納されている。５０１は、１つ目のアプリケーション・オブジェクトを示しており、本実施例では、アプリケーションＡ３１０の情報が取得できているものとする。５０２は、４１１に相当するアプリケーション識別情報である。５０３は、４１２に相当するアプリケーション名情報である。５０４は、４１３に相当する最大記憶領域サイズである。５０５は、４１４に相当するアプリケーション種別情報である。５０６は、当該アプリケーションが格納されている格納場所を示すパス情報である。インストーラ・サービス３０８はこれらの情報を、アプリケーション・オブジェクトから所定の取得ＡＰＩを使用して取得できるものとする。

図６は、本実施例のアプリケーション・フレームワーク３０３が、インストーラ・サービス３０８の指示によりインストールしたアプリケーションＡ，Ｂを格納している状態を図示したものである。本実施例では、アプリケーション・フレームワーク３０３にＨＤＤ２０８におけるＷｏｒｋＦｏｌｄｅｒ６０１を割り当て、アプリケーション・フレームワークは、ＷｏｒｋＦｏｌｄｅｒ６０１のフォルダ配下を使用するように構成されている。アプリケーション・フレームワーク３０３に割り当てられるフォルダは、ユーザが決めても良いし、予め決められていても良い。

アプリケーション・フレームワーク３０３は、インストーラ・サービス３０８の指示によりアプリケーションをインストールする。その際、ＨＤＤ２０８のＷｏｒｋ Ｆｏｌｄｅｒ６０１の中に、アプリケーション毎に独立したフォルダ６０２、６０３をＯＳ３０１のＩ／Ｆを使用して作成する。即ち、アプリケーションは、インストールされることでそのアプリケーションに対し固有にリソースが割り当てられる。そして、その中にアプリケーション・ファイル４００等を格納するものとする。

また、本実施例では、各アプリケーションは、それぞれインストールされたフォルダ６０２、６０３の内部にのみ、自由にフォルダ、ファイルを作成できるように構成している。本実施例では、アプリケーションが利用可能なＨＤＤ２０８の最大サイズとは、ＷｏｒｋＦｏｌｄｅｒ６０１内の許容可能サイズとなる。アプリケーションを画像形成装置にインストールする際、インストーラ・サービス３０８は、個々のアプリケーションが宣言する最大使用サイズ４１３の総和が、ＷｏｒｋＦｏｌｄｅｒ６０１に許容されたサイズを超えないようにインストール指示の制御を行う。例えば、アプリケーションをインストールできる永続記憶領域が１ＧＢ、複数のアプリケーションにより現在使用されている永続記憶領域が８００ＭＢと仮定する。この場合、インストーラ・サービス３０８は、インストールされる対象アプリケーションが２００ＭＢを超えていた場合はインストールの指示を行わず、２００ＭＢを超えていない場合はインストールの指示を行う。

インストールされた各アプリケーションは、各アプリケーションに対応するアプリケーション・ファイルで宣言された宣言値の範囲内でリソースを使用することを前提としてインストールされる。例えば、アプリケーションＡのＨＤＤの最大使用量の宣言値が１００ＭＢであれば、１００ＭＢの使用が許可されてインストールされる。即ち、宣言された最大値と、現在アプリケーションが利用しているリソース量の合計が、予めアプリケーション実行環境上で動作するアプリケーション全体に対して割り当てられた最大値よりも低ければインストールが許可される。しかし、特定のアプリケーションが使用するＨＤＤ量が、アプリケーション・ファイルで宣言する最大使用量を超える場合も考えられる。これは、アプリケーション・ファイルのリソースの使用に関する宣言値がインストールの際には利用されるが、アプリケーション・フレームワークがアプリケーションを管理する上で厳格に宣言値を利用していない状況である。アプリケーション・フレームワークは、アプリケーション・ファイル内のアプリケーション名、バージョン情報とインストールされているアプリケーションの実体とが紐付くように管理は行う。しかしながら、アプリケーション・フレームワークは、アプリケーション・ファイル内のリソースの使用に関する宣言値の管理は行うが、その宣言値通りにアプリケーションの動作を制御する機能はない。よって、アプリケーションが使用したＷｏｒｋＦｏｌｄｅｒ６０１の容量が、インストーラ・サービス３０８が許容した宣言値を超えると、画像形成装置１０１の動作が不安定になる可能性がある。更に、画像形成装置１０１の動作が停止する状況も発生し得る。

図７は、本実施例のインストーラ・サービス３０８が提供するアプリケーション一覧画面を、ＰＣ１０２上のブラウザから見た図である。ＰＣ１０２上のブラウザからインストーラ・サービス３０８にアクセスすることにより表示されるのが図７である。７００は、通常状態の画面を示し、インストーラ・サービス３０８は、アプリケーション・フレームワーク３０３を介して得たアプリケーション・リスト５００に従い画面を構成したものである。７０１は、アプリケーションの状態を示すものであり、アプリケーション・フレームワーク３０３のＩ／Ｆにより得られた、アプリケーションのライフ・サイクルにおける現在の状態を示す。７０２は、アプリケーション毎のディスク使用量であり、パス情報５０６、およびＯＳ３０１の機能によりアプリケーションが格納されているフォルダの所定のタイミングにおける使用量を示すものである。

７０３は、ディスク使用上限を示す情報であり、アプリケーション・フレームワーク３０３を介して、アプリケーション情報５０４の情報を取得し、表示しているものである。７０４は、本発明の使用資源超過検知時の、インストーラ・サービス３０８の画面を示す。７０５は、アプリケーションの状態を示すものであり、本実施例では、アプリケーションＡが資源オーバーで停止していることを示す。７０６は、アプリケーション毎のディスク使用量であり、７０２と同様に現在の使用量を示すものである。なお、アプリケーション一覧画面に表示する項目は、本実施例の項目以外が表示されていても構わない。更に、使用リソースが宣言を超えたために停止したことを認識するために、それを認識するためのシンボルを表示する形態であっても良い。

図８は、インストーラ・サービス３０８が、本実施例の機器制御ライブラリ３０４を介して取得した、ジョブ・リストを図示したものである。ジョブ・リスト８００には、ジョブ・オブジェクトが配列として格納されている。なお、本実施例ではアプリケーションＡ３１０が印刷ジョブを実行しているものとする。８０１は、１つ目のジョブ・オブジェクトを示しており、ジョブにはジョブを特徴付ける各種パラメータが存在する。８０２は、ジョブ名を示すパラメータである。８０３は、ジョブの受け付け番号であり、Ｎａｔｉｖｅ機能３０７が、各種のジョブを受け付ける度に異なる番号を付与しているものとする。８０４は、印刷ジョブ８０１を実行したアプリケーションを識別するためのアプリケーション識別情報である。８０５は、印刷ジョブ８０１の状態を示すものであり本実施例では、印刷中であることを示す。なお、ジョブのパラメータに関して、本実施例で示すものに限定されるものでなく、用紙サイズや出力方法等のパラメータが存在していても構わない。

図９は、本実施例のインストーラ・サービス３０８の各種設定画面９００の資源監視条件設定画面９０１を、ＰＣ１０２上のブラウザから見た図である。ＰＣ１０２上のブラウザからインストーラ・サービス３０８にアクセスすることにより表示されるのが図９である。９０２は、アプリケーションＡに対する資源超過時の処理を示したものであり、資源超過を検知した場合に即アプリケーションの動作を停止する設定であることを示す。９０３は、アプリケーションＢに対する資源超過時の処理を示したものであり、アプリケーションＡと同じく即アプリケーションの動作を停止する設定であることを示す。９０４は、監視周期を設定する項目であり、本実施例では、１回／日、即ち１日に１回監視を行う設定であることを示す。なお、資源監視条件は、本実施例の内容に限定したものではなく、例えば具体的な容量を指定する、あるいは、監視周期を数値で入力するように構成しても構わない。また、設定された情報は、ＨＤＤ２０８の所定の領域の保存されるものとする。このように、監視日時、監視条件の設定方法に限定はない。

図１０は、本実施例のインストーラ・サービス３０８の各種設定画面１０００の資源超過によるアプリケーション停止時の処理の設定画面１００１を、ＰＣ１０２上のブラウザから見た図である。ＰＣ１０２上のブラウザからインストーラ・サービス３０８にアクセスすることにより表示されるのが図１０である。１００２は、アプリケーションの資源超過検知時にコピー・ジョブをどのように制御するかを設定する項目であり、キャンセルするか、継続するかを設定可能である。１００３は、アプリケーションの資源超過検知時に、プリント・ジョブをどのように制御するかを設定する項目であり、キャンセルするか継続するかを設定可能である。

１００４は、アプリケーションの資源超過検知時に、スキャン・ジョブをどのように制御するかを設定する項目であり、本実施例ではキャンセルされることを示す。本実施例において、コピーとプリントにのみ継続の選択肢が存在する理由は、コピー機能やプリント機能は、アプリケーションが印刷にかかわるデータをＷｏｒｋＦｏｌｄｅｒ６０１内に保存する可能性が低いことがあげられる。一方、スキャン機能では、スキャンした画像を、送信、あるいは画像変換などの処理を行う可能性が高く、ＷｏｒｋＦｏｌｄｅｒ６０１内に保存する可能性が高いためである。既に停止状態に入ったアプリケーションが、これ以上リソースを使用させないようにするため、発行されたジョブの種類によりリソースの仕様を制御する。なお、設定された情報は、ＨＤＤ２０８の所定の領域の保存されるものとする。

図１１は、本実施例のインストーラ・サービス３０８が、監視周期９０４で設定された情報に基づき、資源の監視を行う際のフローチャートである。本処理が、インストール対象となる対象アプリケーションがインストールされた後のタイミングで実行されることはお分かり頂けると思う。また、そのタイミングと言うのは監視周期９０４で設定されたタイミングであることもお分かり頂けると思う。以上から、本願発明は、インストールされたアプリケーションの不正動作を制限し、画像形成装置が不適切な状態になることを未然に防ぐことを目的とすることがより明白になった。

ステップ１１０１は、インストーラ・サービス３０８が、アプリケーション・フレームワーク３０３を介して、ＪａｖａＶＭ上に存在する全てのアプリケーション・リスト５００を取得するステップである。ステップ１１０２は、ステップ１１０１で取得したアプリケーション・リスト５００の全オブジェクトをチェックするためのパラメータＮと図１２のフローチャートの実行回数をチェックするためのパラメータＫの初期化ステップである。ステップ１１０３は、インストーラ・サービス３０８が、アプリケーション・フレームワーク３０３を介して、Ｎ番目のアプリケーションの最大記憶領域サイズ５０４を、取得するステップである。本実施例では、Ｎ＝０番目のアプリケーションとして、アプリケーションＡ３１０の情報を扱うものとする。

ステップ１１０４は、インストーラ・サービス３０８が、アプリケーション・フレームワーク３０３を介して、Ｎ番目のアプリケーション、すなわちアプリケーションＡ３１０のパス情報５０６を取得するステップである。本実施例では、アプリケーション・フォルダ６０２を特定する情報を取得するものである。なお、図６に示すように、本実施例ではアプリケーション毎に格納されるフォルダが異なるため、アプリケーション毎にそれぞれ異なるパス情報が得られる。

ステップ１１０５は、インストーラ・サービス３０８が、アプリケーションＡ３１０の現在のＨＤＤ消費量を得るために、ＯＳ３０１を介して、ステップ１１０４で取得したパス情報５０６で示されるフォルダの現在の使用量を取得するステップである。インストーラ・サービス３０８は、ステップ１１０４で取得したパス情報５０６で示されるフォルダの使用量を取得することで、インストールされた対象アプリケーションが現在使用しているリソースの使用量を確認することが出来る。取得するタイミングは所定のタイミングとするが、監視周期９０４で設定したタイミングと同じであっても良いし、異なっていても良い。そのため、監視周期９０４で設定したタイミングよりも早いタイミングでアプリケーションが利用しているリソースの量を取得することも可能ではある。このように、リソース使用量の取得のタイミングに制限はない。

ステップ１１０６は、インストーラ・サービス３０８が、ステップ１１０３とステップ１１０５で取得したサイズを比較するステップである。ただし、当該アプリケーションの資源監視条件９０２、あるいは９０３の設定に従い、比較するデータを調整するものとする。ステップ１１０７は、ステップ１１０６の比較の結果を評価するステップであり、資源が超過していると判定された場合は、ステップ１１０８に進み、そうでなければステップ１１０９に進む。ステップ１１０８は、資源超過検知時のインストーラ・サービス３０８の処理であり、図１２において当該アプリケーションに対する処理を詳細に説明する。ステップ１１０９は、インストーラ・サービス３０８が、ステップ１１０１で取得したアプリケーション・リスト５００の次のアプリケーションをチェックするためのパラメータＮを加算するステップである。ステップ１１１０は、ステップ１１０１で取得したアプリケーション・リスト５００のすべてについてチェックが完了したかを判定するステップであり、完了したと判定されると、本フローチャートを終了する。完了していなければ、ステップ１１０３に戻り、次のアプリケーションの資源監視を行う。

図１２は、ステップ１１０８の詳細を示すフローチャートである。ステップ１２０１は、本フローチャートを実行した回数を確認するステップであり、ステップ１１０２で初期化されたパラメータＫをチェックするステップである。本ステップにおいて、１回目と判断された場合はステップ１２０２に進み、そうでなければステップ１２０３に進む。ステップ１２０２は、パラメータＫを加算するステップである。ステップ１２０３は、インストーラ・サービス３０８が、図１３のメッセージ１３０１に示すメッセージを、操作部制御ライブラリ３０５を介して操作部２０２の液晶パネルに出力するステップである。

ステップ１２０４は、インストーラ・サービス３０８が、当該アプリケーションの種別情報５０５を判定するステップである。アプリケーション・フレームワーク３０３を介して取得した内容が、“Ｎｏｒｍａｌ Ｓｅｒｖｉｃｅ”と一致するかを判定する。判定の結果、一致する場合はステップ１２０５に進み、そうでなければステップ１２０６に進む。ステップ１２０５は、インストーラ・サービス３０８が、当該アプリケーションがすでに開始しているか、すなわち実行中であるかを判定するステップである。開始中と判定されればステップ１２０７に進み、そうでなければステップ１２１４に進む。

ステップ１２０６は、インストーラ・サービス３０８が、操作部制御ライブラリ３０５を介し、操作部２０２の液晶表示部に、図１４のエラー画面を表示するステップである。図１４のエラー・コード１４０１は、アプリケーション種別情報５０５の内容によって番号を切り替えるものとする。エラー画面は、画像形成装置を修理する修理会社（修理ベンダー）に対し告知すべきエラー・コードが表示される。この番号を聞いた修理会社の修理者は、顧客ユーザが所有する画像形成装置の状況を把握し、適切に修理することが可能になる。ステップ１２０７は、インストーラ・サービス３０８が、アプリケーション・フレームワーク３０３を介して、当該アプリケーションを停止するステップである。具体的には、インストーラ・サービス３０８は、アプリケーション・フレームワーク３０３に対して停止するよう指示を行い、アプリケーション・フレームワーク３０３は、アプリケーションの状態が停止に遷移することに応じて、停止状態に対応する処理を行う。

ステップ１２０８は、インストーラ・サービス３０８が、機器制御ライブラリ３０４を介し、Ｎａｔｉｖｅ機能３０７から、実行中のジョブ・リスト８００を取得するステップである。ステップ１２０９は、ステップ１２０８で取得したジョブ・リスト８００を確認するためのパラメータを初期化するステップである。ステップ１２１０は、インストーラ・サービス３０８が、ステップ１２０８で取得したジョブ・リストのＭ番目のジョブから、アプリケーション識別情報８０４が当該アプリケーションと一致するかを判定するステップである。具体的には、ステップ１１０３と同様に、アプリケーションＡ３１０のアプリケーション識別情報５０２と、ジョブ・オブジェクト８０１のアプリケーション識別情報８０４を比較するステップである。一致する場合はステップ１２１１に進み、そうでなければステップ１２１３に進む。即ち、この処理は、Ｓ１２０７で停止するよう指示された対象アプリケーションにより発行されたジョブが存在するか否かを確認するステップである。

ステップ１２１１は、インストーラ・サービス３０８が、当該ジョブをキャンセルするかを判定するステップであり、ＨＤＤ２０８の所定の領域に格納された、設定項目１００２の設定内容を判定する。その結果、キャンセルすると判定した場合はステップ１２１２に進み、そうでなければステップ１２１３に進む。ステップ１２１２は、インストーラ・サービス３０８が、機器制御ライブラリ３０４を介し、当該ジョブのキャンセルを行うステップである。具体的には、インストーラ・サービス３０８は、Ｓ１２１０においてアプリケーション識別情報８０４が当該アプリケーションと一致すると判断された場合、停止するよう指示された対象アプリケーションにより発行されたジョブの処理を中断するように指示する。

ステップ１２１３は、ステップ１２０８で取得したジョブ・リストの次のジョブを処理するためにパラメータＭを加算するステップである。ステップ１２１４は、インストーラ・サービス３０８が、ステップ１２０８で取得したすべてのジョブの確認が完了したかを判定するステップである。すべてのジョブの確認が完了したと判定した場合はステップ１２１５に進み、そうでなければステップ１２１０に戻り、次のジョブを処理する。ステップ１２１５は、インストーラ・サービス３０８が、アプリケーション一覧７０４の当該アプリケーションの状態欄に資源Ｏｖｅｒによりジョブを停止したメッセージを設定するステップである。

なお、ステップ１２０４において、アプリケーション種別情報５０５が“Ｌｏｇｉｎ Ｓｅｒｖｉｃｅ”の場合であっても、“Ｓｙｓｔｅｍ Ｓｅｒｉｖｃｅ”と同じ処理を行う理由は、認証アプリケーションが画像形成装置の保護を目的とするためである。具体的には、“Ｌｏｇｉｎ Ｓｅｒｖｉｃｅ”を“Ｎｏｒｍａｌ Ｓｅｒｖｉｃｅ”と同一に扱い、アプリケーションを停止してしまうと、ユーザを認証できなくなり、セキュリティ上の問題になる可能性があるためである。この処理により認証アプリケーションにおいて問題が発生した場合であっても、画像形成装置のセキュリティを維持することが可能となる。

図１３は、本実施例の画像形成装置の操作画面１３００である。１３０１は、ステップ１２０２によりメッセージ表示が行われていることを示す。図１４は、本実施例の画像形成装置の操作画面に表示されたエラー画面であり、ステップ１２０５において、アプリケーション種別情報５０５が“Ｎｏｒｍａｌ Ｓｅｒｖｉｃｅ”以外のアプリケーションにおいて資源超過を検知したことを示している。

［第２の実施例］
第１の実施形態では、アプリケーションが使用資源を、宣言より超過した場合、即停止するように構成したが、アプリケーションを停止することでオフィス業務が停滞する可能性がある。そこで、第２の実施形態では、アプリケーションを極力停止せずに、画像形成装置を利用できるように構成したものである。第２の実施形態では、図１５に示すように、インストーラ・サービス３０８によってアプリケーションがインストールされた際、予め決められた名前のテンポラリ・フォルダ１５０１、１５０２を作成するように構成する。そして、アプリケーションは一時的に使用するファイルを、このテンポラリ・フォルダ１５０１、１５０２に格納するように構成しておく。

図１６は、図１１のフローチャートに第２の実施例で開示する方法を加筆したものであり、ステップ１１０７で資源超過と判定された以降の処理を変更している。１６０１は、インストーラ・サービス３０８が、当該アプリケーションのテンポラリ・フォルダ１５０１、あるいは１５０２の中のファイルデータを削除するステップである。１６０２は、インストーラ・サービス３０８が、ステップ１１０６と同じ処理を行い、新たに取得した使用量と宣言値の比較を行うステップである。１６０３は、ステップ１６０２の比較の結果を評価するステップであり、資源が超過していると判定された場合は、ステップ１１０８に進み、そうでなければステップ１１０９に進む。

第２の実施例により、アプリケーションが意図せずに資源超過をおこしたような場合で、且つそれがテンポラリ・フォルダ内のファイルで発生している場合、自動的に復旧することが可能となる。

［第３の実施例］
第１の実施例では、予め画像形成装置に組み込まれたインストーラ・サービス３０８によって機能を提供していた。しかしながら、インストーラ・サービス３０８を更新することなく本願発明の課題を解決するための構成を第３の実施例で説明する。第３の実施例では、第１の実施例でインストーラ・サービス３０８において実現した機能を、通常のアプリケーションとして提供するように構成する。具体的には、実施例３で開示するアプリケーションが、図７のアプリケーション一覧機能、図９の資源監視条件設定機能と監視周期設定機能、および図１０のジョブ制御設定を持つ。また、インストーラ・サービス３０８の代わりに図１１のフローチャート、および図１８のフローチャートを実行する。

図１７は、すでに市場に存在する画像形成装置と、第３の実施例のアプリケーションＫの関係を示したものである。１７０１は、本発明の実施例１、２の機能を持たない、従来仕様のインストーラ・サービス１７０１である。１７０２は、第３の実施例の資源監視アプリケーション１７０２である。

実施例３では、図１２におけるステップ１２０６の代わりに、ステップ１８０１を導入する。ステップ１８０１は、アプリケーションＫ１７０２が操作部制御ライブラリを介し、ステータスラインに図１８の１９０１に示すエラーメッセージを表示するステップである。第３の実施例により、画像形成装置にあらかじめ組み込まれているインストーラ・サービス１７０１を変更することなく、同等の資源監視機能が実現できる。そのため、すでに販売済みの画像形成装置においても、通常のアプリケーションとしてインストール・実行することにより、実施例１と同等の効果を得ることができるようになる。

［その他の実施例］
本願発明の各実施例において、アプリケーションが使用する永続記憶領域の使用量を対象に本願発明を説明した。その他の実施例では、アプリケーションが使用する永続記憶領域の使用量以外であっても本願発明を適用できることを説明する。アプリケーション・ファイル４００の４１０には、ＣＰＵの使用量、メモリの使用量と言った画像形成装置のリソースの使用量を宣言することが可能である。また、インストーラ・サービス３０８は、インストール指示に応じてインストールされた対象アプリケーションの情報を、アプリケーションが使用している永続記憶領域の使用量以外にも、アプリケーション・フレームワーク３０３から取得することが出来る。例えば、アプリケーションが使用しているＣＰＵの使用量、メモリの使用量である。これら取得した情報を基に、図１２で説明した超過処理のフローを実行することで、永続記憶領域の使用量のみならず、ＣＰＵの使用量、メモリの使用量と言った、画像形成装置全般のリソースの使用量に対応することが出来る。結果、より的確なアプリケーション制御が行える。また、これらの情報を組み合わせることも可能である。即ち、永続記憶領域の使用量と、メモリの使用量の両方を確認するという処理である。この場合、何れか１つの使用量が超えた時点でアプリケーションの動作を停止させると言った高度な制御が行え、より高度なアプリケーション制御が行える。

本願発明の各実施例において、本願発明を実施する装置として画像形成装置を対象に説明してきた。画像形成装置は、図２に示すように、スキャナ部、およびプリンタ部の両方を有し、それらの内何れか１つ、または両方の画像形成部を使用し画像形成処理に関するジョブを処理する装置である。しかしながら、何れか１つの画像処理部を有した装置、またはそれ以外の画像処理部を有した装置も画像形成装置である。このような装置も、保有する画像処理部を利用し、画像形成処理に関するジョブを処理する。更に、本願発明は画像形成装置以外の装置にも適用は可能である。例えば、スマートフォンや、パーソナルコンピュータ、それ以外の装置にも適用可能である。このような装置の場合は、ジョブが必ずしも画像形成処理に関するものとは限らない。よって、本願発明は、装置が処理するジョブの種類に関わらず実施可能な発明である。

３０１ ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）
３０２ ＪａｖａＶＭ
３０３ アプリケーション・フレームワーク
３０４ 機器制御ライブラリ
３０５ 操作制御ライブラリ
３０６ 通信制御ライブラリ
３０７ Ｎａｔｉｖｅ機能
３０８ インストーラ・サービス
３０９ システム・サービス群
３１０ アプリケーションＡ
３１１ アプリケーションＢ

Claims (8)

1. アプリケーションのライフ・サイクルを管理し、管理対象のアプリケーションに対応するアプリケーション・ファイルに記載された宣言に従い該アプリケーションを管理するフレームワークを備えた装置であって、
   インストールの指示を受けたことに応じて、前記フレームワークに対し対象アプリケーションのインストールを指示する指示手段と、
   前記対象アプリケーションに対応するアプリケーション・ファイルに記載されたリソースの使用量の最大値の宣言を前記フレームワークから取得する取得手段と、
   インストールされることでアプリケーションに対し固有に割り当てられるリソースであって、前記対象アプリケーションが所定のタイミングで使用しているリソースの使用量を確認する確認手段と、を有し、
   前記対象アプリケーションがインストールされた後のタイミングにおいて、前記指示手段は、前記確認手段により確認された前記対象アプリケーションが所定のタイミングで使用しているリソースの使用量が、前記取得手段により取得された前記対象アプリケーションに対応するアプリケーション・ファイルに記載されたリソースの使用量の最大値の宣言を超えていた場合、前記フレームワークに対し前記対象アプリケーションを停止するよう指示し、
   前記対象アプリケーションが認証アプリケーションであって、前記認証アプリケーションが所定のタイミングで使用しているリソースの使用量が、前記取得手段により取得された前記対象アプリケーションに対応するアプリケーション・ファイルに記載されたリソースの使用量の最大値の宣言を超えていた場合、前記認証アプリケーションを停止することなく前記装置に備えられた操作画面上のステータスラインにエラーメッセージを表示させることを特徴とする装置。
2. 前記リソースの使用量とは、フォルダの使用量であって、
   前記取得手段は、前記対象アプリケーションに対応するアプリケーション・ファイルに記載されたフォルダの使用量の最大値の宣言を取得し、
   前記確認手段は、前記対象アプリケーションが処理を実行し保存することで消費したフォルダの使用量を確認することを特徴とする請求項１に記載の装置。
3. 前記装置は、スキャナ部、またはプリンタ部を有し、画像形成処理に関するジョブを処理する画像形成装置であって、
   前記取得手段は、機器制御ライブラリを介し、前記装置のＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）上で動作するネイティブ手段から実行中の画像形成処理に関するジョブ・リストを取得し、
   前記指示手段は、取得された実行中の画像形成処理に関するジョブ・リストの中に、停止するよう指示された前記対象アプリケーションにより発行された画像処理に関するジョブが含まれていた場合、前記機器制御ライブラリを介し、前記ネイティブ手段へ当該画像処理に関するジョブの処理を中断するように指示することを特徴とする請求項１または２に記載の装置。
4. 前記指示手段は、前記フレームワークに対し前記対象アプリケーションを停止するよう指示する場合、前記対象アプリケーションがユーザからの操作によってインストールされたアプリケーションであれば、前記フレームワークに対し前記対象アプリケーションを停止するよう指示し、前記対象アプリケーションがユーザからの操作ではなく所定の方法によってインストールされたアプリケーションであれば、前記フレームワークに対し前記対象アプリケーションを停止するよう指示を行うことなく、エラー画面を表示するように指示をすることを特徴とする請求項１乃至３の何れか１項に記載の装置。
5. 前記エラー画面は、装置を修理するベンダーに告知すべきエラー・コードが表示されることを特徴とする請求項４に記載の装置。
6. 前記フレームワークは、前記アプリケーション・ファイルに記載されたリソースに関する宣言の管理は行うが、当該宣言を基にアプリケーションの制御を行うことができないフレームワークであることを特徴とする請求項１乃至５の何れか１項に記載の装置。
7. アプリケーションのライフ・サイクルを管理し、管理対象のアプリケーションに対応するアプリケーション・ファイルに記載された宣言に従い該アプリケーションを管理するフレームワークを備えた装置を制御する制御方法であって、
   指示手段は、インストールの指示を受けたことに応じて、前記フレームワークに対し対象アプリケーションのインストールを指示し、
   取得手段は、前記対象アプリケーションに対応するアプリケーション・ファイルに記載されたリソースの使用量の最大値の宣言を前記フレームワークから取得し、
   確認手段は、インストールされることでアプリケーションに対し固有に割り当てられるリソースであって、前記対象アプリケーションが所定のタイミングで使用しているリソースの使用量を確認し、
   前記対象アプリケーションがインストールされた後のタイミングにおいて、前記指示手段は、前記確認手段により確認された前記対象アプリケーションが所定のタイミングで使用しているリソースの使用量が、前記取得手段により取得された前記対象アプリケーションに対応するアプリケーション・ファイルに記載されたリソースの使用量の最大値の宣言を超えていた場合、前記フレームワークに対し前記対象アプリケーションを停止するよう指示し、
   前記対象アプリケーションが認証アプリケーションであって、前記認証アプリケーションが所定のタイミングで使用しているリソースの使用量が、前記取得手段により取得された前記対象アプリケーションに対応するアプリケーション・ファイルに記載されたリソースの使用量の最大値の宣言を超えていた場合、前記認証アプリケーションを停止することなく前記装置に備えられた操作画面上のステータスラインにエラーメッセージを表示させることを特徴とする制御方法。
8. 請求項７に記載の制御方法を装置に実行させるためのプログラム。

Images