(57)【要約】      （修正有）【課題】優先度の高いアプリケーションに優先的にリソースを提供し、滞りなく動作可能とするリソース管理装置及びリソース管理方法、画像形成装置及びプログラムを提供する。【解決手段】複数のアプリケーションが動作する情報処理装置において、アプリケーションからのリソース取得リクエストを受信するとＳ５０１、その送信元アプリケーションを判定し、送信元アプリケーションのリソース使用量の上限値を取得する。その上限値と現在のアプリケーションにより使用されているリソース量との合計値を使用量規定値と比較しＳ５０４、合計値が使用量規定値を超える場合には、リソース取得リクエストを待機キューにて保持するＳ５０５。超えない場合は、リソース取得リクエストに対するリソースの割り当てをおこなってレスポンスを返すＳ５０８。【選択図】図５
2017027367.tif 000002
【特許請求の範囲】
【請求項１】
複数のアプリケーションが使用するリソースを管理するためのリソース管理装置であって、
受信したリソース取得リクエストの送信元アプリケーションを判定し、前記送信元アプリケーションのリソース使用量の上限値を取得する取得手段と、
前記リソース取得リクエストに係るリソースを含めた、アプリケーションの総リソース使用量が、設定された基準値以下であるか否かを判定する判定手段と、
前記アプリケーションの総リソース使用量が前記基準値以下であれば、前記リソース取得リクエストに対して要求されたリソースを割り当て、前記アプリケーションの総リソース使用量が前記基準値を超えていれば、前記リソース取得リクエストを待機させ、前記送信元アプリケーションではないアプリケーションに対してリソースの解放を要求する割り当て手段と
を有することを特徴とするリソース管理装置。
【請求項２】
前記送信元アプリケーションが優先度の高いアプリケーションであるか判定する手段を更に有し、
前記割り当て手段は、前記送信元アプリケーションが優先度の高いアプリケーションであると判定された場合には、前記リソース取得リクエストに対して要求されたリソースを割り当てることを特徴とする請求項１に記載のリソース管理装置。
【請求項３】
前記割り当て手段は、前記送信元アプリケーションが優先度の高いアプリケーションであると判定された場合には、前記リソース取得リクエストに対して要求されたリソースを割り当てた後、前記アプリケーションの総リソース使用量が前記基準値を超えていれば、前記送信元アプリケーションではないアプリケーションに対してリソースの解放を要求することを特徴とする請求項２に記載のリソース管理装置。
【請求項４】
前記優先度の高いアプリケーションは、ユーザーインターフェースを伴うタイプのアプリケーション、および、プリントおよびスキャンの少なくとも何れかを伴うジョブを実行するアプリケーションの少なくとも一方であることを特徴とする請求項２又は３に記載のリソース管理装置。
【請求項５】
前記基準値を設定する設定手段を更に有し、
前記設定手段は、実行可能な状態のアプリケーションのリソース使用量の上限値の総和が、アプリケーションに割り当て可能なリソース量を超えている場合に、前記上限値のうちの最大値を前記基準値として設定することを特徴とする請求項１に記載のリソース管理装置。
【請求項６】
前記基準値を設定する設定手段を更に有し、
前記設定手段は、実行可能な状態のアプリケーションのリソース使用量の上限値の総和が、アプリケーションに割り当て可能なリソース量を超えている場合に、前記優先度の高いアプリケーションの上限値のうちの最大値を前記基準値として設定することを特徴とする請求項２に記載のリソース管理装置。
【請求項７】
前記設定手段は、実行可能な状態のアプリケーションのリソース使用量の上限値の総和が、アプリケーションに割り当て可能なリソース量以下である場合に、前記基準値を設定しないことを特徴とする請求項５又は６に記載のリソース管理装置。
【請求項８】
前記リソースには、ソケットとスレッドとメモリーとを含むことを特徴とする請求項１乃至７のいずれか一項に記載のリソース管理装置。
【請求項９】
複数のアプリケーションを実行可能な画像形成装置であって、
受信したリソース取得リクエストの送信元アプリケーションを判定し、前記送信元アプリケーションのリソース使用量の上限値を取得する取得手段と、
前記リソース取得リクエストに係るリソースを含めた、アプリケーションの総リソース使用量が、設定された基準値以下であるか否かを判定する判定手段と、
前記アプリケーションの総リソース使用量が前記基準値以下であれば、前記リソース取得リクエストに対して要求されたリソースを割り当て、前記アプリケーションの総リソース使用量が前記基準値を超えていれば、前記リソース取得リクエストを待機させ、前記送信元アプリケーションではないアプリケーションに対してリソースの解放を要求する割り当て手段と、
前記割り当て手段により割り当てられたリソースを用いる前記アプリケーションを実行する手段と
を有することを特徴とする画像形成装置。
【請求項１０】
複数のアプリケーションが使用するリソースを管理するためのリソース管理方法であって、
受信したリソース取得リクエストの送信元アプリケーションを判定し、前記送信元アプリケーションのリソース使用量の上限値を取得する取得工程と、
前記リソース取得リクエストに係るリソースを含めた、アプリケーションの総リソース使用量が、設定された基準値以下であるか否かを判定する判定工程と、
前記アプリケーションの総リソース使用量が前記基準値以下であれば、前記リソース取得リクエストに対して要求されたリソースを割り当て、前記アプリケーションの総リソース使用量が前記基準値を超えていれば、前記リソース取得リクエストを待機させ、前記送信元アプリケーションではないアプリケーションに対してリソースの解放を要求する割り当て工程と
を有することを特徴とするリソース管理方法。
【請求項１１】
複数のアプリケーションが使用するリソースを管理させるためのプログラムであって、
受信したリソース取得リクエストの送信元アプリケーションを判定し、前記送信元アプリケーションのリソース使用量の上限値を取得する取得工程と、
前記リソース取得リクエストに係るリソースを含めた、アプリケーションの総リソース使用量が、設定された基準値以下であるか否かを判定する判定工程と、
前記アプリケーションの総リソース使用量が前記基準値以下であれば、前記リソース取得リクエストに対して要求されたリソースを割り当て、前記アプリケーションの総リソース使用量が前記基準値を超えていれば、前記リソース取得リクエストを待機させ、前記送信元アプリケーションではないアプリケーションに対してリソースの解放を要求する割り当て工程と
をコンピュータにより実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、例えば組み込みアプリケーションを複数インストールし、実行するための実行環境においてアプリケーション等が使用するリソースの使用量を管理するリソース管理装置及びリソース管理方法、画像形成装置、プログラムに関する。
【背景技術】
【０００２】
組み込みアプリケーション実行環境において、一般的に、アプリケーションが使用できるリソースの総量には制限があり、情報機器の資源量に依存する。それゆえアプリケーションが使用するリソース量について上限値を定め、該アプリケーションの検査段階で、当該アプリケーションのリソースの使用量がその上限値を越えないことを確認することで、アプリケーションが安定稼働することを保証する。また、このようなアプリケーションを複数稼働させることを想定した組み込みアプリケーション実行環境では、アプリケーション管理フレームワークが存在する。アプリケーション管理フレームワークは、アプリケーションの使用するリソース量の総量が情報機器の資源量を越えないよう、インストールの許可又は不許可を制御する。資源量に応じてインストールできるアプリケーションの数に制限を設ける、このようなリソース管理装置、及びリソース管理方法が一般的に提供されている。
【０００３】
一方で、アプリケーションのインストールは制限せず、アプリケーションの稼働時にリソースの使用量の制御を行う技術も提供されている（例えば特許文献１参照）。この技術では、アプリケーションが競合する状態を検出し、それらを制御することにより、複数アプリケーション間でのリソースの競合を制御する。この場合、情報処理装置の資源量や、システムのリソース量には制限があるため、アプリケーションが、制限を超えるリソースをリクエストした場合には、そのアプリケーションは即時にリソース確保が行えず、エラーとして処理を進めるか、もしくは、他アプリケーションの確保しているリソースの解放を待つ。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００７−３２３３９３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
その結果、アプリケーションは正常の動作を続行出来ず、そのアプリケーションによる処理は遅延して、たとえばユーザーが操作するユーザーインターフェースの反応が鈍くなる、または、ジョブ実行の遅延が発生するといった現象の発生につながる。ユーザー操作に係る処理の遅延は、システム全体の信頼性を失うことにもつながりかねない。すなわち、ユーザビリティの観点などから、優先的な動作が必要なアプリケーションも存在する。このようなアプリケーションであっても、前述のリソース不足により、動作が待たされる等の課題がある。
【０００６】
本発明は、優先的に動作が必要なアプリケーションを、待たされることなく動作させることを目的とする。
【課題を解決するための手段】
【０００７】
上記目的を達成するために本発明は以下の構成を有する。すなわち、
複数のアプリケーションが使用するリソースを管理するためのリソース管理装置であって、
受信したリソース取得リクエストの送信元アプリケーションを判定し、前記送信元アプリケーションのリソース使用量の上限値を取得する取得手段と、
前記リソース取得リクエストに係るリソースを含めた、アプリケーションの総リソース使用量が、設定された基準値以下であるか否かを判定する判定手段と、
前記アプリケーションの総リソース使用量が前記基準値以下であれば、前記リソース取得リクエストに対して要求されたリソースを割り当て、前記アプリケーションの総リソース使用量が前記基準値を超えていれば、前記リソース取得リクエストを待機させ、前記送信元アプリケーションではないアプリケーションに対してリソースの解放を要求する割り当て手段とを有する。
【発明の効果】
【０００８】
本発明により、優先度の高いアプリケーションに優先的にリソースを提供し、滞りなく動作可能とするリソース管理装置及びリソース管理方法、画像形成装置及びプログラムを提供することが可能となる。
【図面の簡単な説明】
【０００９】
【図１】本発明の全体構成の一例を示す図である。
【図２】本発明の画像形成装置のハードウェア構成の一例を示す図である。
【図３】本発明の実施形態のアプリケーションの実行環境の構成の一例を示す図である。
【図４】本発明の実施形態のアプリケーションのファイル構成の一例を示した図である。
【図５】本発明の第一の実施形態の処理フローの一例を示した図である。
【図６】本発明の第一の実施形態における使用量規定値を設定する処理フローの一例を示した図である。
【図７】本発明の第二の実施形態の処理フローの一例を示した図である。
【図８】本発明の第二の実施形態における使用量規定値を設定する処理フローの一例を示した図である。
【図９】本発明の第三の実施形態の処理フローの一例を示した図である。
【発明を実施するための形態】
【００１０】
＜実施形態に共通するシステム構成＞
以下、本発明を実施するための形態について図面を用いて説明する。図１は、本発明の第一乃至第三実施形態に共通する全体構成の一例を示した図である。１００は、本実施形態のリソース管理装置として機能する、たとえば複合機（ＭＦＰ）等の画像形成装置である。リソース管理装置としての機能は、画像形成装置のもつ情報処理装置構成により実現される。１０１はパーソナルコンピュータ等の情報処理装置を示し、１３０はネットワークを示す。画像形成装置１００は、情報処理装置１０１と、ネットワーク１３０を経由して接続する。アプリケーションＡ１１０、アプリケーションＢ１１１、アプリケーションＣ１１２はそれぞれ画像形成装置１００上で動作するアプリケーションプログラム（以下、アプリケーションまたはアプリと呼ぶ。）を示す。画像形成装置１００上では、一つ、あるいは複数のアプリケーションを動作させることが可能である。図１では、アプリケーションを３つ例示している。一般利用者及び管理者には、画像形成装置１００の基本機能、アプリケーション１１０、１１１、１１２、及び、画像形成装置１００やアプリケーションを管理するための手段が提供される。利用者は画像形成装置１００を直接操作することや、もしくはネットワーク１３０を経由して情報処理装置１０１から操作することが可能である。
【００１１】
＜実施形態に共通する画像形成装置の構成＞
図２は画像形成装置１００のハードウェア構成の一例を示した図である。画像形成装置は、プロセッサーおよびメモリー等による情報処理機能を有するコア部２００、表示機能及びキー入力および／またはタッチ入力機能を有するユーザーインターフェース部２０１、ファイルストレージなどの記憶装置部２０２、ネットワークインターフェース部２０３、スキャナー部２０４、プリンター部２０５、フィニッシャー部２０６を有する。インストールされたアプリケーションは記憶装置２０２やコア部２００の有する不揮発性メモリーなどに実行可能な形式で格納され、その実行時にはたとえばコア部２００の有するＲＡＭなどにロードされて、プロセッサー（ＣＰＵ）により直接、あるいはインタープリターを用いて実行される。アプリケーションの実行の際には、各実施形態で説明するように必要に応じてリソースが確保され、円滑な実行が保証される。
【００１２】
＜実施形態に共通するアプリケーションの実行環境＞
図３は画像形成装置において、各アプリケーション１１０、１１１、１１２を実行するための、各実施形態に共通の実行環境の一例を示した図である。３０１はアプリケーション実行基盤であり、例えばＪａｖａ（登録商標）仮想マシン（ＪａｖａＶＭ）等である。アプリケーション実行基盤３０１がＪａｖａＶＭの場合には、アプリケーションはＪａｖａ（登録商標）のプログラムとなる。アプリケーションは基本的にこのアプリケーション実行基盤３０１上で動作する。アプリケーション１１０、１１１、１１２のインストール、アンインストール、実行、停止といった処理は、実行基盤３０１上で動作するアプリケーション管理フレームワーク３０２によって管理されている。一般的に、アプリケーション管理フレームワークは、システムもしくは画像形成装置の管理者によって使用される。アプリケーション管理フレームワークは、インストールなどの処理を行う際に、アプリケーションのアプリケーションリソース上限宣言ファイル４０２（図４参照）を参照し、ファイル中に宣言されているリソース上限値４１4が、現在のアプリケーション実行環境内のリソースの空き容量に収まるか否かを判定する。そして、判定結果により、インストール処理の実行や、エラーを返す（操作者に通知する）といった処理を行う。アプリケーション管理フレームワーク３０２は、たとえばＪａｖａ（登録商標）ベースのＯＳＧｉ（ＯＰＥＮ  Ｓｅｒｖｉｃｅｓ  Ｇａｔｅｗａｙ  ｉｎｉｔｉａｔｉｖｅ）フレームワークなどである。アプリケーション管理フレームワーク３０２がＯＳＧｉの場合、アプリケーションはバンドルと呼ばれるプログラムで実現される。
【００１３】
３０３はアプリケーション１１０、１１１、１１２が画像形成装置１００の様々な機能を利用するためのサポートライブラリである。３０４はアプリケーションが必要とするリソースについて、管理を実現するために利用されるリソースサービスである。リソースサービス３０４の機能として、アプリケーション１１０、１１１、１１２が使用するリソースの管理を行うための機能がある。
【００１４】
リソースサービス３０４によるリソースの管理の機能について説明する。一般的なアプリケーションは、アプリケーションが使用するリソースを確保する際に、アプリケーション実行基盤３０１に対してリソース取得リクエストを送信する。そして、アプリケーション実行基盤３０１からのレスポンスを受信し、処理を行う。確保したリソースを解放する際も同様に、アプリケーションはアプリケーション実行基盤３０１に対してリソース解放リクエストを送信する。
【００１５】
これに対して、リソースサービス３０４は、他のアプリケーションに対して提供するＡＰＩを実装し、リソースサービスに対応するアプリケーションはこれらのＡＰＩを呼び出しリソースの取得や解放、使用をおこなう。リソースサービス３０４に対応するアプリケーション１１０、１１１、１１２は、使用するリソースの確保や、確保したリソースの解放を行う際は、リソースサービス３０４に対して、リソース取得リクエストやリソース解放リクエストを送信する。リクエストを受信したリソースサービス３０４は、各アプリケーションに設定されているリソースの使用量の上限値を取得する。そして、アプリケーションの使用するリソース量が上限値に達していなければ、リソースサービス３０４が、アプリケーション実行基盤３０１に対してリソース取得リクエストを送信する。そして、リソースサービス３０４は、リクエスト送信元のアプリケーション１１０、１１１、１１２に確保したリソースを割り当て、レスポンスを返す。リソースサービス３０４の管理対象のリソースには、たとえばストレージ、通信のリソースとしてソケット、コンピューティングリソースとしてスレッド、メモリー等がある。もちろんこれら以外のリソースも管理対象に含まれる。
【００１６】
リソースサービス３０４は、アプリケーションごとの取得、解放のリクエスト記録していくことで、各アプリケーションが使用するリソース量を管理する。本説明では、アプリケーションからのリクエストに対して、リソースサービス３０４がアプリケーション実行基盤３０１からリソースを確保し、割り当てを行うとした。リソースの実際の確保の処理に関して、アプリケーションからのリクエストに対して、リソースサービス３０４は、リソース確保の許可または拒否のいずれかをレスポンスとして返す。そして、そのレスポンスに従って、アプリケーション自身が、アプリケーション実行基盤３０１からリソースの確保を行うというような処理であってもリソース管理は可能である。
【００１７】
＜アプリケーションの構成＞
図４（ａ）は、本実施例におけるアプリケーション１１０、１１１、１１２を構成する代表的なファイルについて示した図である。アプリケーション１１０、１１１、１１２はいくつかの種類のファイルを抱えている。４００はアプリケーションの実行コード等を含む、アプリケーション実行コードファイルである。４０１はアプリケーションが保持する定数や文字列等の固定データを収めた、アプリケーション固定データファイルを示す。４０２はアプリケーションの使用するリソースの上限値を宣言するためのアプリケーションリソース上限宣言ファイルを示す。アプリケーションリソース上限宣言ファイル４０２は、たとえばＪａｖａ（登録商標）アーカイブファイルのマニフェストヘッダーなどにより実現できる。この場合マニフェストファイルすなわちアプリケーションリソース上限宣言ファイル４０２は、アプリケーションのプログラム本体と共に、記憶装置２０２などに格納されている。
【００１８】
図４（ｂ）は、アプリケーションリソース上限宣言ファイル４０２の内部構成の一例を示した図である。アプリケーションリソース上限宣言ファイル４０２は、アプリケーションの名称やＩＤやタイプといったアプリケーション情報を含む。本図では、一例として装置内の画像のプレビューをユーザーインターフェース部２０１に表示するアプリケーションを示す。アプリケーション名称（ＡｐｐｒｉｃａｔｉｏｎＮａｍｅ）４１２には、"ＰｒｅｖｉｅｗＡｐｐ"のアプリケーション名が記載され、アプリケーションＩＤ（ＡｐｐｒｉｃａｔｉｏｎＩＤ）４１１には、アプリケーション固有ＩＤ"ｍｅａｐ−ａｐｒｉ−ｉｍａｇ−ｖｉｅｗ"の記載があることを示す。アプリケーションタイプ（ＡｐｐｒｉｃａｔｉｏｎＴｙｐｅ）４１３には、アプリケーションの機能に応じて分類分けされるタイプの情報を示すｒ。本図の"Ｔｙｐｅ＿ＵＩ"は、ユーザーインターフェース部２０１にアプリケーションの画面を表示し、ユーザーからの入力操作を受け付けるＵＩタイプを示す。ＵＩタイプ以外のタイプとしては、Ｗｅｂブラウザーを経由するユーザーインターフェースによってアプリケーションの情報を表示するサーブレットタイプや、ユーザーインターフェースを保持せずに動作するサービスタイプが存在する。アプリケーションＩＤ４１１、アプリケーション名称４１２、アプリケーションタイプ４１３をまとめてアプリケーション情報と呼ぶ。
【００１９】
また、アプリケーションリソース上限宣言ファイル４０２には、アプリケーション情報と共に、アプリケーションが使用する各リソースの上限値４１４も保持する。本図では、アプリケーションの使用するストレージ、メモリー、スレッド、ファイルディスクリプター、ソケットといった各種リソースの上限値を、その種類ごとにバイト単位もしくは数値で記載している例を示す。
【００２０】
以上が第一乃至第三実施形態に共通のシステムあるいはデータ構成である。以下に実施形態ごとの例を説明する。
【００２１】
［第一の実施形態］
本実施形態のリソースサービスの動作の一例を図５のフローチャートを用いて説明する。本フローチャートはリソースサービス３０４が、アプリケーションからのリソース取得リクエストを受信するところから始まる。なお以下の説明でいうリソースとは、要求されたそれぞれの種類のリソースを示している。例えばリソース要求に対してリソース割当が可能か否かの判定は、要求されたリソースの種類ごとに行われる。アプリケーションは、要求した全てのリソースが割り当てられたなら実行を開始できる。アプリケーションによるリソースの要求は、その実行前に行ってもよいし、実行中にリソースが必要となったときに行ってもよい。
【００２２】
＜リソース割り当て処理＞
リソースサービス３０４は、アプリケーションからリソース取得リクエストを受信すると（Ｓ５０１）、送信元のアプリケーションのリソース上限値判定を行う（Ｓ５０２）。リソースサービス３０４は、リソース取得リクエストに含まれるアプリケーションＩＤから、リソース取得リクエストの送信元アプリケーションを特定し、該当するアプリケーションリソース上限宣言ファイル４０２を読み込み、リソース上限値４１４を取得する。この値が、リソース要求元アプリケーションによりリソース取得リクエストで要求されるリソース量である。
【００２３】
そして、リソースサービス３０４は、アプリケーションの使用可能なリソースの上限値と、そのうちでリクエスト受信時にアプリケーションが使用しているリソース使用量との差分、すなわちリクエスト受信時に新たに割り当て可能なリソース量を算出し、リソース取得リクエストで要望されるリソース量を受け入れ可能か判定する。新たに割り当て可能なリソース量は、たとえばリソースサービス３０４が管理するリソース総量のうち、アプリケーションに割り当てられていないリソースの量である。リソースサービス３０４はリソースの使用量あるいは新たに割り当て可能なリソース量を、リソースの割り当て及び解放の都度更新し、保持している。
【００２４】
そして、リソース取得リクエストのリソース量の方が割り当て可能なリソース量よりも大きければ、リソースサービスは処理不可能と判定し、エラーレスポンスを返して本処理を終了する（Ｓ５０９）。一方ステップＳ５０２において、リソース取得リクエストのリソース量の方が小さく、リソース取得リクエストを処理可能と判定した場合は、装置の使用可能領域中に設定されている使用量規定値の判定処理（Ｓ５０３）へ進む。なお、本例では、要求されたリソースすべてについてＳ５０２の条件が満たされた場合にＳ５０３へ分岐し、一種類でも条件を満たさないリソースがあればエラーとする。使用量規定値は、リソースサービス３０４の管理下におけるリソース総量に対して、アプリケーションが定常的に使用可能とするリソース使用量を設定する値である。リソースサービス３０４がリソースの管理を行う上で、一つの基準とする値となる。使用量規定値は後述する図６の手順で設定される、割り当て可能なリソース量のマージンを確保するための基準値であり、稼働中のアプリケーションのリソースの上限値の総和が、割り当て可能なリソース量を超える場合に設定される。リソースサービス３０４が管理するリソース総量を第２の基準値、使用量規定値を第１の基準値と呼ぶこともある。
【００２５】
ステップＳ５０３において、リソースサービス３０４が使用量規定値の有無を判定し、使用量規定値が設定されている場合、リソース使用量判定（Ｓ５０４）へ進む。使用量規定値が設定されていない場合とは、装置上で稼働するアプリケーションそれぞれのリソースの上限値の総計が、リソースサービス３０４の管理するリソース総量より少ない場合である。このような場合には、リソース不足に起因して画像形成装置１００の挙動が不安定になることはないと判定できるため、リソースサービス３０４は使用量判定を行うことなく、リクエスト応答処理（Ｓ５０８）を行う。すなわち、リソース要求元のアプリケーションに対して要求された量のリソースを割り当てる。
【００２６】
ステップＳ５０３で使用量規定値が設定されていると判定された場合、リソースサービス３０４はステップＳ５０４において使用量規定値を取得し、稼働中の全アプリケーションが使用中の総リソース量と、リソース取得リクエストの処理に必要なリソース量との合計（総リソース使用量とも呼ぶ）が、使用量規定値を超えるか否かを判定する。使用量規定値を超えないと判定した場合、すなわち総リソース使用量が第１の基準値以下の場合には、ステップＳ５０８へ進み、リソース取得リクエストの応答処理を行う。ステップＳ５０４において合計が該使用量規定値を超えると判定した場合、リソースサービスはリソース取得リクエストを一時的に待機キューにて保持する（Ｓ５０５）。  そして、リソースサービス３０４は、リソース取得リクエストを待機キューに保持すると（Ｓ５０５）、リソースの調整要求の処理を行う（Ｓ５０６）。リソースの調整要求の処理として、リソースサービス３０４は本装置上で動作する各アプリケーションに対してリソース調整リクエストを出す（Ｓ５０６）。リソース調整リクエストを受信した各アプリケーションは、各アプリケーション内で確保しているリソースに関し、解放可能なリソースが存在するか否かを判定する。解放可能なリソースが存在すれば、アプリケーションはリソースサービス３０４に対して、リソース調整リクエストのレスポンスとして、解放可能なリソースのリソース解放リクエストを送信する。そして、リソースサービス３０４はアプリケーションからリソース解放リクエストを受信すると、本装置におけるリソースの解放処理を行う。リソース調整リクエストは、たとえば必要なリソースを指定して発行され、リソース調整リクエストを受信した各アプリケーションは、各アプリケーション内で確保している、調整が要求されたリソースに関し、解放可能であれば解放する。アプリケーションは、割り当てられたリソースを全て解放してもよいが、その一部を解放してもよい。一部のリソースの解放を行う場合には、リソースサービス３０４は、リソース取得リクエストを受けると、要求されるリソース上限値と割り当て済みのリソースとの差分を新たに割り当てることとする。また、ステップＳ５０６のリソース調整リクエストは、全ての稼働中アプリケーションに対して一斉に出してもよいが、個々のアプリケーションに対して順次出してもよい。この場合、リソース調整リクエストの発行先アプリケーションの順序は、例えば、より大量のリソースが割り当てられたアプリケーションを先に（すなわち優先的に）したり、あるいは、予め決めておいた順序としたりするように決められる。
【００２７】
リソースサービス３０４は、リソース解放リクエスト（リソース解放要求）の処理を行った後、ステップＳ５０４と同様に、稼働中の全アプリケーションが使用中の総リソース量と、リソース取得リクエストの処理に必要なリソース量との合計が使用量規定値を超えるか否かの判定を再び行う（Ｓ５０７）。判定の結果、アプリケーションのリソース使用量が、使用量規定値を超える場合は、再びステップＳ５０６のリソースの調整要求の処理に戻る。リソースの調整要求の処理を繰り返し行い、リソース取得リクエストに応答しても使用量規定値を超えない状況になると、リソースサービス３０４はリクエスト応答処理（Ｓ５０８）へ進む。
【００２８】
ステップＳ５０８では、リソースサービス３０４はアプリケーションからのリソース取得リクエストに応答し、アプリケーション実行基盤からリソースを確保したうえで、アプリケーションにレスポンスを返し、本フローチャートを終了する。
【００２９】
＜使用量規定値の設定処理＞  次に、前述したリソースの使用量規定値を算出する処理フローに関し、図６のフローチャートを用いて説明する。装置上のアプリケーションの状況に変更が無ければ、リソースの使用量規定値は変わることは無い。そのため、リソースサービス３０４の初回起動時、もしくは、アプリケーションの追加・変更・削除が行われた場合に、本処理が行われる。
【００３０】
まず、リソースサービス３０４は、各アプリケーションのアプリケーションリソース上限宣言ファイル４０２から、インストールされている実行可能な状態の各アプリケーションのリソース上限値４１４を取得する（Ｓ６０１）。そして、取得したリソース上限値の総和を計算し、画像形成装置１００がアプリケーション用のリソースとして用意している割り当て可能なリソース量（以下、装置のリソース量と呼ぶ。）とどちらが大きいかを判定する（Ｓ６０２）。装置のリソース量がアプリケーションのリソース上限値の総和より大きければ、すなわちリソース上限値の総和が装置のリソース量以下であれば、全てのアプリケーションが同時に動作したとしてもリソースが不足することはない。それゆえ、使用量規定値を設定することなく、むしろ設定済みの値を消去して終了する（Ｓ６０５）。
【００３１】
一方、アプリケーションのリソース上限値の総和が装置のリソース量より大きければ、各アプリケーションの上限値の中から、最も大きい値を取得する（Ｓ６０３）。そして、最も大きい量のリソースを常に確保できることが可能な値、つまり、装置上の全リソースから、取得したリソース上限値の最大値を減算した値を、そのリソースの使用量規定値として設定し（Ｓ６０４）、本処理を終了する。なお全リソースとは、特定の種類のリソースについてその全てという意味である。
【００３２】
本実施形態は、リソースサービス３０４が、装置上のアプリケーションのリソース上限値を取得し、最も大きい上限値を常に確保できる値を、使用量規定値として設定する。そして、装置上でアプリケーションが使用するリソース量が使用量規定値以下に収まるようリソースを管理するリソースサービス３０４すなわちリソース管理装置を提供する。このリソース管理装置によって、アプリケーションが、アプリケーション実行基盤３０１からリソース確保を行う際に、エラーとなることを回避することが可能となる。特に、アプリケーションの使用するリソース上限値の総和が、アプリケーションに対して割り当て可能な量を超えている場合には、リソースサービス３０４により管理されるリソースには、少なくともひとつのアプリケーションが要求するリソース量が空きとして確保されている。そのため、例えばリソースサービス３０４を用いないアプリケーションがアプリケーション実行基盤３０１から直接リソース確保を行う際に、エラーとなることを回避することが可能となる。また、リソースサービス３０４を利用するアプリケーションについても、優先的にリソースを割り当てるためのリソースを確保することができる。この結果、組み込みアプリケーションをインストールし、実行するような環境において、リソース不足に起因して装置が不安定になることを回避する。
【００３３】
［第二の実施形態］
本実施形態のアプリケーションには、図４で前述したように、幾つかのタイプが存在する。ＵＩタイプのアプリケーションは、ユーザーが直接操作するユーザーインターフェースを利用して、情報の表示や入力の受付をする。そのため、ＵＩタイプのアプリケーションの動作不具合は、装置全体の不具合とみなされることにもなる。このような状況を回避すべく、リソースサービスＵＩタイプのアプリケーションを優先的に処理する、リソース管理の例を、図７、及び図８を用いて説明する。
【００３４】
＜使用量規定値の設定処理＞  まず、リソースサービス３０４が、リソース使用量規定値を算出する処理フローについて、図８のフローチャートを用いて説明する。図８のフローチャートは、第一実施形態の図６のフローチャートがベースとなり、図６の手順に代えて用いられる手順であるため、前述のステップについては、説明を割愛する。
【００３５】
リソースサービス３０４は、ステップＳ６０２にて、取得したリソース上限値の総和が、装置上のリソースより大きいと判定した場合に、ステップ８０１へ進む。そして、装置上のアプリケーションからＵＩタイプのアプリケーションを選抜し（Ｓ８０１）、各ＵＩタイプのアプリケーションのリソース上限値の中から、最も大きい値を取得する（Ｓ８０２）。そして、最も大きい値が常に確保できることが可能な値、つまり、装置上の全リソースから、取得したリソース上限値を減算した値を、リソースの使用量規定値として設定し（Ｓ６０４）、本処理を終了する。
【００３６】
＜リソース割り当て処理＞
次に、リソースサービス３０４がリソース管理を行う際の処理を図７のフローチャートを用いて説明する。本フローチャートは、リソースサービス３０４がアプリケーションからリソース取得リクエストを受信するところから始まる（Ｓ５０１）。なお、図７のフローチャートは、図５のフローチャートが基となり、図５の手順に代えて用いられる手順であるため、同等の処理となる箇所の詳細説明は割愛する。
【００３７】
リソースサービス３０４は、リソース取得リクエストを受信すると、アプリケーションのリソース上限値判定すなわちリソース取得リクエストを受け入れ可能かの判定を行い（Ｓ５０２）、リソースの使用量規定値の有無を判定する（Ｓ５０３）。そして、リソースサービス３０４は、使用量規定値が設定されている場合には。リソース取得リクエストに含まれるアプリケーションＩＤから、リソース取得リクエストの送信元アプリケーションを特定し、そのアプリケーションリソース上限宣言ファイル４０２のアプリケーションタイプ４１３から、送信元アプリケーションがＵＩタイプか否かを判定する（Ｓ７０１）。送信元アプリケーションがＵＩタイプでないと判定した場合は、リソース使用量判定（Ｓ５０４）へ進み、ステップ５０５〜ステップＳ５０８の処理を経て、終了する。
【００３８】
一方、送信元アプリケーションがＵＩタイプと判定した場合、リソースサービス３０４は、リソースの使用量判定を行うことなく、リソース取得リクエストに対するリクエスト応答処理を行う（Ｓ７０２）。このときリソースサービス３０４は、リソース取得リクエストに対応するリソースを確保したうえで、アプリケーションへのレスポンスを返す。そして、レスポンスを返した後で、リソースサービス３０４は装置上の使用中のリソース量が使用量規定値以下であるかを判定する（Ｓ７０３）。装置上で使用中のリソース量が、リソース使用量規定値以下であれば、そのまま本リソース管理の処理を終了する。
【００３９】
ステップＳ７０２のリクエスト応答処理によって、装置上の使用中のリソース量が、リソース使用量規定を上回る状況になっていた場合は、ステップＳ５０６と同様にリソースの調整要求の処理を行う（Ｓ７０４）。リソースの解放要求の処理を行った後は、再度ステップＳ７０３に戻り、使用中のリソース量を判定する。
【００４０】
本実施形態では、ＵＩタイプのアプリケーションタイプを優先的に処理することを可能にするリソース管理装置を示した。ＵＩタイプのアプリケーションのリソース最大使用量を確保した使用量規定値を算出し、この使用量規定値によってＵＩタイプのアプリケーションが必要とするリソースを確保しておき、ＵＩタイプのアプリケーションからのリソース取得リクエストを優先的に処理する。この様なリソース管理装置によって、ＵＩタイプのアプリケーションからのリソース取得リクエストにエラーを返すことが無くなる。このためユーザーによるＵＩ操作中のリソース不足に起因する問題発生を防止することが可能となる。
【００４１】
［第三の実施形態］
画像形成装置の基本機能として、プリントやコピーといった機能がある。これらは一般的にジョブとして処理され、順々に実行されるものである。本実施形態のリソースサービス別の例を、図９のフローチャートを用いて説明する。図９のフローチャートは、図７のリソース管理処理に加えてジョブ処理中のリソース取得リクエストを優先する。なお、図９のフローチャートにおいて、図５及び図７と同等の処理を行う箇所の詳細説明は割愛する。本実施形態では、図９の手順が図５又は図７の手順に代えて実行される。なお使用量規定値は例えば図６の手順設定しておけばよい。
【００４２】
＜リソース割り当て処理＞  本フローチャートは、前述の図７のフローチャート同様に、リソースサービス３０４がアプリケーションからリソース取得リクエストを受信するところから始まる（Ｓ５０１）。リソースサービス３０４はリソース取得リクエストを受信すると、アプリケーションの上限値判定すなわちリソース取得リクエストを受け入れ可能かの判定を行い（Ｓ５０２）、装置の使用可能な領域中に設定されている使用量規定値の有無の判定を行う（Ｓ５０３）。
【００４３】
そして、使用量規定値が設定されており、その値を取得できた場合、リソースサービス３０４は装置がジョブを処理中か否かを判定する（Ｓ９０１）。上述のように、ジョブとは例えばコピーやプリント、スキャンなどを含む。またこれらジョブには、データの送信や受信、データの格納、データの読み出しといった付随的な処理を含むことがある。ステップＳ９０１では、リソースサービス３０４は、サポートライブラリ３０３を通して、コア部２００に繋がるスキャナー部２０４、プリンター部２０５、フィニッシャー部２０６の稼働状況を取得する。スキャナー部２０４、プリンター部２０５、フィニッシャー部２０６が稼働していない状況であれば、リソースサービス３０４はジョブの処理中ではないと判定し、ステップＳ７０１へ進む。ステップＳ７０１以降の処理は図７の第二の実施形態と同等のため説明は割愛する。スキャナー部２０４、プリンター部２０５、フィニッシャー部２０６のいずれかが稼働中であった場合は、ジョブの処理中であると判定し、ステップＳ９０２へ進む。なお図９中では、ステップＳ７０１はＵＩタイプのみを判定せず、例えば予め定めておいた優先するアプリケーションタイプに該当するか否かを判定している。もちろん優先するアプリケーションタイプがＵＩタイプであればステップＳの判定は図７のステップＳ７０１と同じ判定となる。該当すればステップＳ７０２に分岐する。なお実行中のジョブのみを優先するのであれば、ステップＳ７０１をスキップしてステップＳ５０４へと分岐してもよい。
【００４４】
そして、リソースサービス３０４は、リソース取得リクエストの送信元アプリケーションに対し、スキャナー部２０４、プリンター部２０５、フィニッシャー部２０６のいずれかのハード部に対して処理要求を投げているか問合せを行う。アプリケーションからの回答により、処理要求をしていると判定される場合は、リソース取得リクエストの送信元アプリケーションがジョブを処理していると判定し、リクエスト応答処理を行う（Ｓ７０２）。これ以降、ステップＳ７０４までは図７で説明した通りである。
【００４５】
本実施形態では、画像形成装置１００がジョブの処理中であるか否かを判定し、ジョブを処理しているアプリケーションからのリソース取得リクエストを優先的に処理するリソース管理装置となる。これらの処理によって、基本的な機能であるプリント、コピーといった処理を止めることなく動作させるリソース管理装置が提供できる。
【００４６】
なお、第二実施形態におけるＵＩタイプのアプリケーション、第三実施形態におけるジョブ実行中のアプリケーションは、滞りなく処理を進める必要性の高い、優先度の高いアプリケーションといえる。したがって、これらのアプリケーションに限らず、優先度の高いアプリケーションがリソースを要求している場合には、使用量規定値を設けることで確保しているリソースをそのアプリケーションに割り当てることができる。このため優先度の高いアプリケーションについてはリソース不足に起因する処理の遅滞を防止できる。
【００４７】
［その他の実施例］
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【符号の説明】
【００４８】
１００  画像形成装置、１０１  情報処理装置、１３０  ネットワーク、３０２  アプリケーション管理フレームワーク、３０４  リソースサービス、４０２  アプリケーションリソース上限宣言ファイル
【図１】
2017027367.tif 000003
【図２】
2017027367.tif 000004
【図３】
2017027367.tif 000005
【図４】
2017027367.tif 000006
【図５】
2017027367.tif 000007
【図６】
2017027367.tif 000008
【図７】
2017027367.tif 000009
【図８】
2017027367.tif 000010
【図９】
2017027367.tif 000011