(57)【要約】  パラメータ決定部１１０は、複数のアプリケーション毎に、推奨リソース量と該推奨リソース量に対応する体感品質、及び、最低リソース量と該最低リソース量に対応する体感品質を、リソース量Ｒと体感品質Ｑとの関係を示す式（１）の品質関数ｆに代入してパラメータａとｂを決定する。リソース量決定部１２０は、パラメータａとｂが決定されたアプリケーション毎の品質関数ｆを用いて、該複数のアプリケーションに配分するリソース量を決定する。品質関数ｆ（ｘ）は、逆関数f−１を有する単調増加関数であり、（−∞，０）と（＋∞，１）をつなぎ、ｘ＝０で点対称するものである。これにより、複数のアプリケーションに対してリソースを配分するために必要な、リソース量とユーザの体感品質との関係を示す品質関数を効率良く作成する。              Ｑ＝ｆ（ｘ）＝ｆ（（Ｒ−ａ）／ｂ）                （１）
2011111141.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータ上で動作する複数のアプリケーションに対してリソース量の配分を行うリソース配分装置であって、
前記複数のアプリケーション毎に、使用するリソース量とユーザの体感品質との関係を示す式（１）の品質関数ｆにおける第１のパラメータａと第２のパラメータｂを決定するパラメータ決定手段と、
該パラメータ決定手段により前記第１のパラメータａと第２のパラメータｂが決定された前記複数のアプリケーション毎の品質関数ｆを用いて、該複数のアプリケーションに配分するリソース量を決定するリソース量決定手段とを備え、
前記パラメータ決定手段は、当該アプリケーションに対して、推奨リソース量と該推奨リソース量に対応する体感品質、及び、最低リソース量と該最低リソース量に対応する体感品質を式（１）に代入することにより式（１）における第１のパラメータａと第２のパラメータｂを算出し、
品質関数ｆ（ｘ）は、逆関数f−１を有する単調増加関数であり、（−∞，０）と（＋∞，１）をつなぎ、ｘ＝０で点対称するものであることを特徴とするリソース配分装置。
Q＝f(x)＝f((R-a)/b)        (1)
但し，
Ｑ：体感品質
ｆ：品質関数
Ｒ：リソース量
ａ：第１のパラメータ
ｂ：第２のパラメータ
【請求項２】
前記複数のアプリケーションのうちの任意のアプリケーションについて、リソース量の増減要求を受け付ける受付手段と、
該任意のアプリケーションに対して前記パラメータ決定手段により決定された前記第１のパラメータａと第２のパラメータｂに、前記受付手段により受け付けられた増減要求が示す増加量に応じて増加する１より大きい倍数乗算し、前記受付手段により受け付けられた増減要求が示す減少量に応じて減少する１より小さい倍数を乗算するパラメータ調整手段をさらに有し、
前記リソース量決定手段は、前記任意のアプリケーションに対して、前記パラメータ調整手段により前記第１のパラメータａと第２のパラメータｂが調整された品質関数ｆを用いて、該アプリケーションに配分するリソース量を決定することを特徴とする請求項１に記載のリソース配分装置。
【請求項３】
前記リソース量決定手段は、
前記複数のアプリケーションに配分するリソース量の総和が所定量になり、かつ各アプリケーションの体感品質が同値の均一体感品質になるように、該複数のアプリケーションに配分するリソース量を決定することを特徴とする請求項１または２に記載のリソース配分装置。
【請求項４】
同種の複数のリソースが存在する際に、前記均一体感品質が予め定められた所定の閾値以上であることを条件に、前記複数のアプリケーションに配分されるリソースの個数が最少個になるように制御を行うリソース数制御手段をさらに備えることを特徴とする請求項３に記載のリソース配分装置。
【請求項５】
前記品質関数ｆ（ｘ）は、式（２）または式（３）であることを特徴とする請求項１から４のいずれか１項に記載のリソース配分装置。
f(x)=1/(1+e^(-x))            (2)
f(x)=(1/π)×arctan(x)+1/2    (3)
【請求項６】
コンピュータ上で動作する複数のアプリケーションに対してリソース量の配分を行うリソース配分方法において、
前記複数のアプリケーション毎に、推奨リソース量と該推奨リソース量に対応する体感品質、及び、最低リソース量と該最低リソース量に対応する体感品質を、使用するリソース量Ｒとユーザの体感品質Ｑとの関係を示す式（４）の品質関数ｆに代入することにより第１のパラメータａと第２のパラメータｂを決定し、
前記第１のパラメータａと第２のパラメータｂが決定された前記複数のアプリケーション毎の品質関数ｆを用いて、該複数のアプリケーションに配分するリソース量を決定し、
前記品質関数ｆ（ｘ）は、逆関数f−１を有する単調増加関数であり、（−∞，０）と（＋∞，１）をつなぎ、ｘ＝０で点対称するものであることを特徴とするリソース配分方法。
Q＝f(x)＝f((R-a)/b)        (4)
但し，
Ｑ：体感品質
ｆ：品質関数
Ｒ：リソース量
ａ：第１のパラメータ
ｂ：第２のパラメータ
【請求項７】
コンピュータ上で動作する複数のアプリケーションに対してリソース量の配分を行う際に、
前記複数のアプリケーション毎に、推奨リソース量と該推奨リソース量に対応する体感品質、及び、最低リソース量と該最低リソース量に対応する体感品質を、使用するリソース量Ｒとユーザの体感品質Ｑとの関係を示す式（５）の品質関数ｆに代入することにより第１のパラメータａと第２のパラメータｂを決定し、
前記第１のパラメータａと第２のパラメータｂが決定された前記複数のアプリケーション毎の品質関数ｆを用いて、該複数のアプリケーションに配分するリソース量を決定する処理をコンピュータに実行させ、
前記品質関数ｆ（ｘ）は、逆関数f−１を有する単調増加関数であり、（−∞，０）と（＋∞，１）をつなぎ、ｘ＝０で点対称するものであることを特徴とするプログラムを記録した非一時的なコンピュータ可読媒体。
Q＝f(x)＝f((R-a)/b)        (5)
但し，
Ｑ：体感品質
ｆ：品質関数
Ｒ：リソース量
ａ：第１のパラメータ
ｂ：第２のパラメータ
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータ上で動作する複数のアプリケーションへのリソースを配分する技術に関する。
【背景技術】
【０００２】
コンピュータシステムにおけるリソースの配分について、様々な技術が提案されている。【０００３】
例えば、特許文献１に開示されたＱｏＳ制御装置は、割当て量登録手段により、起動しているタスクについて予め定められた、ＱｏＳの等級に対応する資源の割当量をテーブルとして登録しておき、テーブルに基づいて各タスクへのリソース配分量を決定する。【０００４】
また、特許文献２に開示された分散資源管理システムは、複数のアプリケーションで共有される資源を配分する際に、該複数のアプリケーションについて必要な注目資源の要求度を示す需要関数を作成し、これらの需要関数に基づいて資源の配分を行う。【０００５】
携帯電話やＰＮＤ（Ｐｏｒｔａｂｌｅ  Ｎａｖｉｇａｔｉｏｎ  Ｄｅｖｉｃｅ）、ＤＰＦ（Ｄｉｇｉｔａｌ  Ｐｈｏｔｏ  Ｆｒａｍｅ）などの小型デバイスは、ＣＰＵの演算能力やメモリ容量などからなるリソースが限られているため、アプリケーションへのリソースの配分が特に重要である。これらの小型デバイスにおいて、起動されているアプリケーションの数が多いと、これらのアプリケーションは、期待通りに動作できない場合がある。これは、これらのアプリケーションが、限られたリソースを取り合うため、単体で動作するときに達成できる品質を得ることができないためである。【０００６】
リソースが限られたデバイスで複数のアプリケーションを快適に動作させるには，リソースをこれらのアプリケーションに適切に配分する必要がある。起動されているアプリケーションの個数や種類によってリソースの適切な配分が異なるので、均等配分やベストエフォートで配分するなどの手法は好ましくない。【０００７】
起動されている複数のアプリケーション毎の、該アプリケーションが使用するリソース量とユーザの体感品質との関係に基づいて、それぞれのアプリケーションに配分するリソース量を計算する手法が知られている。ユーザの体感品質とはユーザが感じる満足度の度合いであり、これを指標にリソース配分を行うことでユーザの満足度を高めることができる。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２０００−１５５６９５号公報
【特許文献２】特開平１１−６６０１８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
例えば、特許文献１に開示された技術を適用し、各アプリケーションについて、該アプリケーションが使用するリソース量と体感品質との関係を示すテーブルを予め登録しておき、起動された各アプリケーションの上記テーブルに基づいて、これらのアプリケーションに対してリソースの配分を行うことが考えられる。【００１０】
また、アプリケーションが使用するリソース量と体感品質の関係を示すテーブルは、例えば、アプリケーションの製作者や、デバイスの設計者により予め作成することができる。【００１１】
しかし、昨今の携帯電話機などは、小型デバイスといえども、数十個にもなるアプリケーションが実装されている場合がある。このように多数のアプリケーションが実装されたデバイスに対して、アプリケーション毎に、使用するリソース量と体感品質との関係を事前に調べることは、大変労力のかかる作業である。【００１２】
本発明は、上記事情に鑑みてなされものであり、デバイス上で動作する複数のアプリケーションに対してリソース量の配分をする際に、夫々のアプリケーションが使用するリソース量と体感品質の関係を効率良く取得する技術を提供する。
【課題を解決するための手段】
【００１３】
本発明の１つの態様は、コンピュータ上で動作する複数のアプリケーションに対してリソース量の配分を行うリソース配分装置である。このリソース配分装置は、パラメータ決定部と、リソース量決定部を有する。【００１４】
パラメータ決定部は、上記複数のアプリケーション毎に、使用するリソース量とユーザの体感品質との関係を示す式（１）の品質関数ｆにおける第１のパラメータａと第２のパラメータｂを決定する。具体的には、当該アプリケーションに対して、推奨リソース量と該推奨リソース量に対応する体感品質、及び、最低リソース量と該最低リソース量に対応する体感品質を式（１）に代入することにより式（１）における第１のパラメータａと第２のパラメータｂを算出する。なお、品質関数ｆ（ｘ）は、逆関数f−１を有する単調増加関数であり、（−∞，０）と（＋∞，１）をつなぎ、ｘ＝０で点対称するものである。【００１５】
Q＝f(x)＝f((R-a)/b)        (1)
但し，
Ｑ：体感品質
ｆ：品質関数
Ｒ：リソース量
ａ：第１のパラメータ
ｂ：第２のパラメータ【００１６】
リソース量決定部は、パラメータ決定部により第１のパラメータａと第２のパラメータｂが決定された上記複数のアプリケーション毎の品質関数ｆを用いて、該複数のアプリケーションに配分するリソース量を決定する。【００１７】
なお、上記態様のリソース配分装置を方法やシステムに置き換えて表現したもの、該リソース配分装置の動作をコンピュータに実行せしめるプログラム、該プログラムを記録したコンピュータ読取可能な記録媒体なども、本発明の態様としては有効である。
【発明の効果】
【００１８】
本発明にかかる技術によれば、複数のアプリケーションに対してリソースを配分するために必要な、使用するリソース量とユーザの体感品質との関係を示す品質関数を効率良く作成することができる。
【図面の簡単な説明】
【００１９】
【図１】本発明の第１の実施の形態にかかるリソース配分装置を示す図である。
【図２】品質関数ｆを示す図である。
【図３】品質関数ｆの２つの具体例を示す図である。
【図４】図１に示すリソース配分装置における処理の流れを示すフローチャートである。
【図５】アプリケーションの性能とリソース量の関係の例を示す図である。
【図６】図５に示す３つのアプリケーションに対して作成された品質関数を示す図である。
【図７】図５に示す３つのアプリケーションに対するリソース量の決定を説明するための図である。
【図８】本発明の第２の実施の形態にかかるリソース配分装置を示す図である。
【図９】図８に示すリソース配分装置における受付部の例を示す図である（その１）。
【図１０】図８に示すリソース配分装置における受付部の例を示す図である（その２）。
【図１１】図８に示すリソース配分装置における処理の流れを示すフローチャートである。
【図１２】図８に示すリソース配分装置によるリソース量の配分の例を説明するための図である。
【図１３】本発明の第３の実施の形態にかかるリソース配分装置を示す図である。
【図１４】図１３に示すリソース配分装置によるリソース量の配分の例を説明するための図である。
【図１５】図１３に示すリソース配分装置における処理の流れを示すフローチャートである。
【発明を実施するための形態】
【００２０】
以下、図面を参照して本発明の実施の形態について説明する。説明の明確化のため、以下の記載及び図面は、適宜、省略、及び簡略化がなされている。また、様々な処理を行う機能ブロックとして図面に記載される各要素は、ハードウェア的には、ＣＰＵ、メモリ、その他の回路で構成することができ、ソフトウェア的には、メモリにロードされたプログラムなどによって実現される。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組合せによっていろいろな形で実現できることは当業者には理解されるところであり、いずれかに限定されるものではない。なお、各図面において、同一の要素には同一の符号が付されており、必要に応じて重複説明は省略されている。
【００２１】
また、上述したプログラムは、様々なタイプの非一時的なコンピュータ可読媒体（ｎｏｎ−ｔｒａｎｓｉｔｏｒｙ  ｃｏｍｐｕｔｅｒ  ｒｅａｄａｂｌｅ  ｍｅｄｉｕｍ）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（ｔａｎｇｉｂｌｅ  ｓｔｏｒａｇｅ  ｍｅｄｉｕｍ）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、ＣＤ−ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）ＣＤ−Ｒ、ＣＤ−Ｒ／Ｗ、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ（Ｐｒｏｇｒａｍｍａｂｌｅ  ＲＯＭ）、ＥＰＲＯＭ（Ｅｒａｓａｂｌｅ  ＰＲＯＭ）、フラッシュＲＯＭ、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（ｔｒａｎｓｉｔｏｒｙ  ｃｏｍｐｕｔｅｒ  ｒｅａｄａｂｌｅ  ｍｅｄｉｕｍ）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。
【００２２】
＜第１の実施の形態＞
図１は、本発明の第１の実施の形態にかかるリソース配分装置１００を示す。このリソース配分装置１００は、携帯電話機などの小型デバイスに実装されており、該小型デバイス上で動作するアプリケーションのリソース配分を行う。
【００２３】
リソース配分装置１００は、パラメータ決定部１１０とリソース量決定部１２０を備える。
【００２４】
パラメータ決定部１１０は、該小型デバイスにて起動されている複数のアプリケーション毎に、使用するリソース量とユーザの体感品質との関係を示す式（２）の品質関数ｆにおける第１のパラメータａiと第２のパラメータｂiを決定する。
【００２５】
Ｑi＝ｆ（ｘ）＝ｆ（（Ｒi−ａi）／ｂi）    （２）
但し，
ｉ：アプリケーションの番号
Ｑｉ：体感品質
ｆ：品質関数
Ｒｉ：リソース量
ａｉ：第１のパラメータ
ｂｉ：第２のパラメータ
【００２６】
図２に示すように、品質関数ｆ（ｘ）は、逆関数f−１を有する単調増加関数であり、（−∞，０）と（＋∞，１）をつなぎ、ｘ＝０で点対称するものである。
【００２７】
単調増加関数である品質関数ｆ（ｘ）として、（−∞，０）からなだらかに立ち上がり、ｘ＝０に近づくにつれ傾きが大きくなり、ｘ＝０を過ぎると次第に傾きが小さくなり、（＋∞，１）になだらかに近づいていく関数採用する。品質関数としてこの性質を持つ単調増加関数ｆ（ｘ）を用いるのは、仮定するユーザの体感品質の性質を再現できるからである。この仮定とは、ユーザは、性能が十分達成されている場合それ以上多少性能が上がったとしてもより品質が良くなったとは感じない一方、性能がほとんど達成されていない場合にさらに性能が下がってもより品質が悪くなったとは感じないというものである。なお、品質関数ｆ（ｘ）は連続的で滑らかであることが好ましいが、近似的に連続的で滑らかであっても良い。
【００２８】
図３は、品質関数ｆ（ｘ）の２つの具体例を示す。実線と点線は、式（３）と式（４）のｆ（ｘ）をそれぞれ示す。式（３）と式（４）における「ｘ」は、「（Ｒ−ａ）／ｂ」である。
【数１】
2011111141.tif 000003
【００２９】
以下において、ｆ（ｘ）の例として、式（３）が示すものを用いるが、品質関数は、式（３）に示す関数に限られることがない。
【００３０】
アプリケーション毎に、該アプリケーションの推奨リソース量Ｒｉｈｉｇｈと該推奨リソース量Ｒｉｈｉｇｈに対応する体感品質Ｑｉｈｉｇｈ、及び、最低リソース量Ｒｉｌｏｗと該最低リソース量Ｒｉｌｏｗに対応する体感品質Ｑｉｌｏｗを式（３）に代入すると下記の式（５）と式（６）を得ることができる。なお、Ｒｉｈｉｇｈ、Ｑｉｈｉｇｈ、Ｒｉｌｏｗ、Ｑｉｌｏｗは、アプリケーションの製作者又はデバイスの設計者により決定され、パラメータ決定部１１０に入力される。
【００３１】
【数２】
2011111141.tif 000004
【００３２】
そして、式（５）と式（６）を連立方程式としてａｉとｂｉについて解くと、式（７）と式（８）に示すように、第１のパラメータａｉと第２のパラメータｂｉを算出することができる。
【００３３】
【数３】
2011111141.tif 000005
【００３４】
パラメータ決定部１１０は、式（７）と式（８）に従って、アプリケーション毎に、第１のパラメータａｉと第２のパラメータｂｉを算出してリソース量決定部１２０に供する。
【００３５】
なお、ＱｉｈｉｇｈとＱｉｌｏｗが下記の式（９）を満たす場合に、第１のパラメータａｉと第２のパラメータｂｉの算出は式（１０）と図（１１）が示すように簡単になる。
【００３６】
Ｑｉｈｉｇｈ＋Ｑｉｌｏｗ＝１              （９）
【数４】
2011111141.tif 000006
【００３７】
ＱｉｈｉｇｈとＱｉｌｏｗが式（９）を満たす場合に、式（９）に示す第１のパラメータａｉは、推奨リソース量Ｒｉｈｉｇｈと最低リソース量Ｒｉｌｏｗの平均値になる。これは、式（３）に示す品質関数ｆ（ｘ）に限らず、逆関数f−１を有し、（−∞，０）と（＋∞，１）をつなぎ、ｘ＝０で点対称するものである如何なる単調増加関数の場合も成り立つ。この平均値は、品質Ｑが０．５である場合のリソース量を表す。
【００３８】
リソース量決定部１２０は、パラメータ決定部１１０により決定された各アプリケーションの第１のパラメータａと第２のパラメータｂを用いて、これらのアプリケーションに配分するリソース量を決定する。
【００３９】
本実施の形態において、リソース量決定部１２０は、各アプリケーションに配分するリソース量の総和が所定量ＴＲになり、かつ各アプリケーションの体感品質が同一になるように、夫々のアプリケーションに配分するリソース量を決定する。この体感品質を、以下均一体感品質ＡＱという。
【００４０】
具体的には、リソース量決定部１２０は、式（１２）と（１３）に従ってアプリケーション毎のリソース量Ｒｉを決定する。
【００４１】
【数５】
2011111141.tif 000007
【００４２】
Ｒｉ＝ｂｉｆ−１（ＡＱ）＋ａｉ  （13）
但し，
ＡＱ：均一体感品質
【００４３】
なお、上記所定量ＴＲは、例えばデバイスの設計者によって設定される。具体的には、例えば、該小型デバイスのリソース量のうちの、アプリケーションの実行に使用可能なリソース量が決定できる。
【００４４】
図４は、図１に示すリソース配分装置１００における処理の流れを示すフローチャートである。
まず、パラメータ決定部１１０は、アプリケーション毎に、推奨リソース量Ｒｉｈｉｇｈとそれに対応する体感品質Ｑｉｈｉｇｈ、最低リソース量Ｒｉｌｏｗとそれに対応する体感品質Ｑｉｌｏｗを上述した式（５）と式（６）で示す連立方程式に代入して第１のパラメータａｉと第２のパラメータｂｉを算出する（Ｓ１００）。
【００４５】
リソース量決定部１２０は、パラメータ決定部１１０により算出された各アプリケーションの第１のパラメータａｉと第２のパラメータｂｉを式（１２）に代入して均一体感品質ＡＱを算出する（Ｓ１０２）。
【００４６】
そして、リソース量決定部１２０は、アプリケーション毎に、該アプリケーションの第１のパラメータａｉ及び第２のパラメータｂｉと、ステップＳ１０２で算出した均一体感品質ＡＱを式（１３）に代入して該アプリケーションに配分するリソース量Ｒｉを算出する（Ｓ１０４）。
【００４７】
ここで下記の具体例を用いて図１に示すリソース配分装置１００をより詳細に説明する。
例えば、配分の対象となるリソースがデバイスのＣＰＵ演算能力であり、アプリケーションに割り当て可能なリソース量（上述した所定量ＴＲ）が１００％である。起動されるアプリケーションは、Ｈ．２６４に準拠したデコーダ（以下Ｈ．２６４デコーダという）と、顔認識するアプリケーション（以下顔認識ＡＰという）と、ニュース閲覧のためのアプリケーション（以下ニュース閲覧ＡＰという）の３種類である。
【００４８】
Ｈ．２６４デコーダは，動画コーデックであるＨ．２６４フォーマットのファイルを復号するアプリケーションであり、顔認識ＡＰは、デバイスに備わっているカメラからの入力画像を解析し、顔が映っているか判断するアプリケーションである。ニュース閲覧ＡＰは、一定間隔でニュースを取得し表示するアプリケーションである。
【００４９】
また、上記３つのアプリケーションについて、使用するリソース量と性能の関係は、図５に示すように得られていたとする。図示の例では、Ｈ．２６４デコーダの性能は３０個のフレームの復号に所要する時間、顔認識ＡＰの性能は１フレームの解析に所要する時間、ニュース閲覧ＡＰの性能はニュースの取得間隔で表されている。
【００５０】
また、各アプリケーションについて、推奨リソース量Ｒｉｈｉｇｈに対応する体感品質Ｑｉｈｉｇｈが０．８、最低リソース量Ｒｉｌｏｗがに対応する体感品質Ｑｉｌｏｗが０．２であるとする。
【００５１】
パラメータ決定部１１０は、図５に示す性能とアプリケーションの関係を基に、推奨リソース量Ｒｉｈｉｇｈと最低リソース量Ｒｉｌｏｗを決定する。推奨リソース量Ｒｉｈｉｇｈと最低リソース量Ｒｉｌｏｗの決定は、例えば、Ｈ．２６４デコーダについては１秒に３０フレームを復号できれば十分、顔認識ＡＰについては０．５秒〜１秒程度で１フレームを解析したい、ニュース閲覧ＡＰについては１秒間隔でニュースを取得したいなどの基準に基づいてなされる。
【００５２】
このようにして、例えば、Ｈ．２６４デコーダについて、ＲｉｈｉｇｈとＲｉｌｏｗはそれぞれ７０％、６０％、顔認識ＡＰについて、ＲｉｈｉｇｈとＲｉｌｏｗはそれぞれ８０％、４０％であり、ニュース閲覧ＡＰについて、ＲｉｈｉｇｈとＲｉｌｏｗはそれぞれ３０％、１０％に決定される。
【００５３】
パラメータ決定部１１０は、アプリケーション毎に、Ｑｉｈｉｇｈ（ここでは０．８）、Ｒｉｈｉｇｈ、Ｑｉｌｏｗ（ここでは０．２）、Ｒｉｌｏｗを式（５）と式（６）に代入して第１のパラメータａｉと第２のパラメータｂｉを解く。この例では、Ｈ．２６４デコーダについて、第１のパラメータａｉと第２のパラメータｂｉはそれぞれ６５と３．６になり、顔認識ＡＰについて、第１のパラメータａｉと第２のパラメータｂｉはそれぞれ６０と１４．４になり、第１のパラメータａｉと第２のパラメータｂｉはそれぞれ２０と７．２になる
【００５４】
そのため、Ｈ．２６４デコーダ、顔認識ＡＰ、ニュース閲覧ＡＰの品質関数は、図６に示すようになる。
【００５５】
そして、リソース量決定部１２０は、図６に示す各品質関数を用いて、夫々のアプリケーションに配分するリソース量を決定する。具体的には、まず、式（１２）に従って均一体感品質ＡＱを算出し、そして式（１３）により各アプリケーションへ配分するリソース量Ｒｉを算出する。なお、各アプリケーションへ配分するリソース量の総和が１００％である。
【００５６】
この例において、図７に示すように、均一体感品質ＡＱは０．１４になる。また、Ｈ．２６４デコーダ、顔認識ＡＰ、ニュース閲覧ＡＰには、それぞれ５９％、３４％、７％のリソース量が配分される。
【００５７】
このように、本実施の形態のリソース配分装置１００によれば、アプリケーションへリソース量を配分する際に、品質関数として上述した単調増加関数ｆ（ｘ）を用いるため、品質関数のパラメータを決定するために、１つのアプリケーションについて予め用意する必要のあるデータは、推奨リソース量Ｒｉｈｉｇｈとそれに対応する体感品質Ｑｉｈｉｇｈ、最低リソース量Ｒｉｌｏｗとそれに対応する体感品質Ｑｉｌｏｗのみである。そのため、品質関数の作成効率が向上し、アプリケーションの開発者やデバイスの設計者の負担と大幅に軽減することができる。なお、上記において図５に示すような、アプリケーションの性能とリソース量の関係に基づいてＲｉｈｉｇｈとＲｉｌｏｗを決定しているが、ＲｉｈｉｇｈとＲｉｌｏｗそのものを直接パラメータ決定部１１０に供するようにしてもよい。
【００５８】
また、品質関数ｆ（ｘ）は、体感品質が最低リソース量付近で立ち上がり、推奨リソース量付近で立ち終わる特性を有するため、ユーザの直感に合わせたリソース配分ができる。
【００５９】
さらに、第１のパラメータａと第２のパラメータｂが決定された品質関数を用いてリソース量の配分を決定する際に、全ての組み合わせを探索せずに解析的に導くことができるため、計算コストを抑制することができる。そのため、リアルタイムに配分計算をしても、リソース量の配分にかかる計算オーバーヘッドを少なくすることができる。
【００６０】
＜第２の実施の形態＞
図８は、本発明の第２の実施の形態にかかるリソース配分装置２００を示す。リソース配分装置２００も、例えば携帯電話機などの小型デバイスに実装されており、該小型デバイス上で動作するアプリケーションのリソース配分を行う。
【００６１】
リソース配分装置２００は、パラメータ決定部２１０、受付部２２０、パラメータ調整部２３０、リソース量決定部２４０を備える。
【００６２】
パラメータ決定部２１０は、図１に示すリソース配分装置１００におけるパラメータ決定部１１０と同様の処理を行う。すなわち、パラメータ決定部２１０は、該小型デバイスにて起動されている複数のアプリケーション毎に、使用するリソース量とユーザの体感品質との関係を示す式（２）の品質関数ｆにおける第１のパラメータａiと第２のパラメータｂiを算出する。
【００６３】
パラメータ決定部２１０により算出された各アプリケーションの第１のパラメータａiと第２のパラメータｂiは、パラメータ決定部２１０からパラメータ調整部２３０に出力される。
【００６４】
受付部２２０は、アプリケーション毎に増減要求を入力可能なユーザインタフェースである。このユーザインタフェースは、夫々のアプリケーションに対して、ユーザがリソース量を増やしたいか減らしたいか、及び増減量を示す上記増減要求を入力するためのものである。
【００６５】
パラメータ調整部２３０は、パラメータ決定部２１０からの第１のパラメータａiと第２のパラメータｂiを調整し、調整後の第１のパラメータａiと第２のパラメータｂiをリソース量決定部２４０に出力する。パラメータ決定部２１０が得た第１のパラメータａiと第２のパラメータｂiと区別するために、パラメータ調整部２３０により調整後の第１のパラメータａiと第２のパラメータｂiをａi'とｂi'で表記する。
【００６６】
パラメータ調整部２３０は、受付部２２０を介してユーザが力した増減要求に応じて調整係数ｃiを決定すると共に、決定した調整係数ｃiを用いて式（１４）と式（１５）に示すように調整を行う。
ａi'＝ｃi×ａi        （１４）
ｂi'＝ｃi×ｂi        （１５）
【００６７】
調整係数ｃiは、全てのアプリケーションについて、デフォルト値が１である。ユーザにより増減要求の入力が無い場合に、パラメータ調整部２３０は、調整係数ｃiのデフォルト値を用いる。
【００６８】
すなわち、ユーザにより増減要求が無い場合に、ａi'とａiが同様であり、ｂi'とｂiが同様である。
【００６９】
パラメータ調整部２３０は、増減要求がリソース量の増加要求である場合に、１より大きく、かつ増加したい量が大きいほど大きい調整係数ｃiを第１のパラメータａｉと第２のパラメータｂｉに乗算し、増減要求がリソース量の減少要求である場合に、１より小さく、かつ減少したい量が大きいほど小さい調整係数ｃiを第１のパラメータａｉと第２のパラメータｂｉに乗算する。
【００７０】
図９は、増減要求を入力するための受付部２２０の一例を示す。図示のように、受付部２２０は、各アプリケーション（ＡＰ１、ＡＰ２、ＡＰ３、・・・）毎に、２つの調整ボタン（調整ボタン２２２と調整ボタン２２４）が設けられている。
【００７１】
調整ボタン２２２は、リソース量を増やしたい場合に押下するためのボタンであり、押下回数と増やしたい量とは正比例する。以下、調整ボタン２２２を増加ボタンという。
【００７２】
調整ボタン２２４は、リソース量を減らしたい場合に押下するためのボタンであり、押下回数と減らしたい量とは正比例する。以下、調整ボタン２２４を減少ボタンという。
【００７３】
パラメータ調整部２３０は、例えば、式（１６）と式（１７）に示すように、増加ボタン２２２の押下回数ｍiと減少ボタン２２４の押下回数ｎiに応じて調整係数ｃiを決定する。
【００７４】
ｃi＝１＋０．１×ｍi        （１６）
但し、
ｍi：増加ボタン２２２の押下回数
【００７５】
ｃi＝１−０．１×ｎi        （１７）
但し、
ｎi：減少ボタン２２４の押下回数
【００７６】
図１０は、受付部２２０の別の一例を示す。図示のように、各アプリケーション（ＡＰ１、ＡＰ２、ＡＰ３、・・・）毎に、調整バー２２６が設けられている。
【００７７】
パラメータ調整部２３０は、調整バー２２６がデフォルトの位置から上方に移動された場合に、移動された距離に応じた大きさの値を１に加算して調整係数ｃiを得、調整バー２２６がデフォルトの位置から下方に移動された場合に、移動された距離に応じた大きさの値を１から減算して調整係数ｃiを得る。
【００７８】
パラメータ調整部２３０は、アプリケーション毎に、第１のパラメータａｉと第２のパラメータｂｉに調整係数ｃiを乗算して得た第１のパラメータａi'と第２のパラメータｂi'をリソース量決定部２４０に出力する。増減要求が入力されていないアプリケーションについては、ａi'とａiが同様であり、ｂi'とｂiが同様である。
【００７９】
リソース量決定部２４０は、第１のパラメータと第２のパラメータとして調整後の第１のパラメータと調整後のパラメータを用いる点以外に、リソース配分装置１００における（１８）に従って各アプリケーションへ配分するリソース量を決定する。１３０と同様な演算により各アプリケーションへ配分するリソース量を決定する。
【００８０】
すなわち、本実施の形態において、品質関数は式（１８）に示すようになる。
Ｑi＝ｆ（ｘ）＝ｆ（（Ｒi−ａi'）／ｂi'）    （１８）
＝ｆ（（Ｒi−ｃi×ａi）／ｃi×ｂi）
但し，
ｉ：アプリケーションの番号
Ｑｉ：体感品質
ｆ：品質関数
Ｒｉ：リソース量
ａi：調整前の第１のパラメータ
ｂi：調整前の第２のパラメータ
ａi'：調整後の第１のパラメータ
ｂi'：調整後の第２のパラメータ
【００８１】
なお、式（１８）は、下記式（１９）と同価である。
Ｑi＝ｆ（ｘ）＝ｆ（（Ｒi／ｃi−ａi）／ｂi）    （１９）
【００８２】
式（１９）から分かるように、第１のパラメータａiと第２のパラメータｂiの値を調整した場合に得られる品質関数は、当初の推奨リソース量Ｒｉｈｉｇｈ及び最低リソース量Ｒｉｌｏｗにｃiを乗算した値で求めた品質関数と等価であり、ｃiは、推奨リソース量Ｒｉｈｉｇｈ及び最低リソース量Ｒｉｌｏｗをｃi倍するパラメータという意味を持つ。つまりｃiは、ある状況において当該アプリケーションがユーザにとってより重要である、または、重要ではない場合に、当初のリソース量配分量をその比率に応じ変更したい場合に設定するパラメータといえる。
【００８３】
図１１は、リソース配分装置２００における処理の流れを示すフローチャートである。まず、パラメータ決定部２１０は、アプリケーション毎に、推奨リソース量Ｒｉｈｉｇｈとそれに対応する体感品質Ｑｉｈｉｇｈ、最低リソース量Ｒｉｌｏｗとそれに対応する体感品質Ｑｉｌｏｗを上述した式（５）と式（６）で示す連立方程式に代入して第１のパラメータａｉと第２のパラメータｂｉを算出する（Ｓ１１０）。これらの第１のパラメータａｉと第２のパラメータｂｉは、パラメータ調整部２３０に入力される。
【００８４】
パラメータ調整部２３０は、受付部２２０を介してリソース量の増減が要求されていないアプリケーションに対して（Ｓ１１２：Ｎｏ）、その第１のパラメータａｉと第２のパラメータｂｉを調整せずにリソース量決定部２４０に出力する。
【００８５】
一方、受付部２２０を介してリソース量の増減が要求されたアプリケーションに対して（Ｓ１１２：Ｙｅｓ）、パラメータ調整部２３０は、該アプリケーションの第１のパラメータａｉと第２のパラメータｂｉに、増減要求に応じた調整係数を乗算して得た値をリソース量決定部２４０に出力する（Ｓ１１４）。
【００８６】
リソース量決定部２４０は、パラメータ調整部２３０からの調整後の第１のパラメータと第２のパラメータを用いて均一体感品質ＡＱを算出すると共に、各アプリケーションに対して、該均一体感品質ＡＱに対応するリソース量を該アプリケーションに配分するリソース量Ｒｉとして算出する（Ｓ１１６、Ｓ１１８）。
【００８７】
例えば、図５に示す３つのアプリケーション（Ｈ．２６４デコーダ、顔認識ＡＰ、ニュース閲覧ＡＰ）の場合、Ｈ．２６４デコーダに対して、ｃiが０．５になる増減要求が入力され、他の２つのアプリケーションに対して増減要求が入力されていないとする。
【００８８】
この場合、この３つのアプリケーションに対応する品質関数は、図１２に示すようになる。また、均一体感品質ＡＱは０．３７になり、Ｈ．２６４デコーダ、顔認識ＡＰ、ニュース閲覧ＡＰに配分されたリソース量は、それぞれ３２％、５２％、１６％になる。
【００８９】
この場合は、ある状況ではデコーダが重要ではなく、その性能は通常の半分である１５ｆｒａｍｅ／ｓｅｃで復号できれば十分である場合に相当する。リソース配分装置２００によれば、この場合におけるＨ．２６４デコーダへ配分するリソース量をリソース配分装置１００のときの５９％から３２％に減少し、減少分のリソースを他のアプリケーションに回すことができている。
【００９０】
すなわち、本実施の形態のリソース配分装置２００によれば、第１の実施の形態にかかるリソース配分装置１００と同様の効果を得ることができると共に、リソース量の配分にユーザの意図を反映させることができる。
【００９１】
＜第３の実施の形態＞
図１３は、本発明の第３の実施の形態にかかるリソース配分装置３００を示す。このリソース配分装置３００は、パラメータ決定部３１０と、リソース数制御部３２０と、リソース量決定部３３０を備える。
【００９２】
本実施の形態のリソース配分装置３００は、同種のリソースが複数存在する場合にアプリケーションに配分するリソースの個数を制御することができる。例えば、ＣＰＵコアが複数搭載されたデバイスにおいて、「ＣＰＵ演算能力」であるリソースがＣＰＵコアの数分存在することになる。
【００９３】
パラメータ決定部３１０は、リソース配分装置１００におけるパラメータ決定部１１０と同様の動作をし、各アプリケーションについて、第１のパラメータａｉと第２のパラメータｂｉを算出してリソース量決定部３３０に出力する。
【００９４】
リソース量決定部３３０は、パラメータ決定部３１０からの第１のパラメータａｉと第２のパラメータｂｉを用いて均一体感品質ＡＱを算出してリソース数制御部３２０に出力する。均一体感品質ＡＱの算出方法は、リソース配分装置１００における算出１３０の手法と同様であるが、この算出に際して用いられる、アプリケーションに配分するリソース量の総和となる所定量ＴＲは、リソース数制御部３２０から供給される。
【００９５】
リソース数制御部３２０は、同種の複数のリソースが存在する際に、均一体感品質ＡＱが予め定められた所定の閾値以上であることを条件に、アプリケーションに配分されるリソースの個数が最少個になるように制御を行うものである。分かりやすいように、図５に示す３つのアプリケーション（Ｈ．２６４デコーダ、顔認識ＡＰ、ニュース閲覧ＡＰ）が実装された場合を例に説明する。また、均一体感品質ＡＱの閾値が０．５に設定されているとする。
【００９６】
リソース数制御部３２０は、まず、１個のＣＰＵコアの演算能力（１００％）を所定量ＴＲとしてリソース量決定部３３０に供給する。
【００９７】
図１４に示すように、所定量ＴＲが１００％である場合に、リソース量決定部３３０が算出した均一体感品質ＡＱは、第１の実施の形態のリソース配分装置１００のときと同様に、０．１４である。それに対応して、Ｈ．２６４デコーダ、顔認識ＡＰ、ニュース閲覧ＡＰに配分されるリソース量Ｒｉも、第１の実施の形態のリソース配分装置１００のときと同様に、それぞれ５９％、３４％、７％である。
【００９８】
リソース数制御部３２０は、リソース量決定部３３０が算出した均一体感品質ＡＱと閾値（ここでは０．５）とを比較する。現在の均一体感品質ＡＱが０．１４であり、閾値より小さいため、リソース数制御部３２０は、所定量ＴＲを、ＣＰＵコアが２つである場合に対応する値（例えば２００％）に変更してリソース量決定部３３０に出力し、均一体感品質ＡＱの再計算を行わせる。
【００９９】
リソース量決定部３３０は、変更された所定量ＴＲを用いて均一体感品質ＡＱを再計算してリソース数制御部３２０に出力する。このときの均一体感品質ＡＱは、図１４に示すように、０．９になる。
【０１００】
均一体感品質ＡＱが閾値の０．５を超えたため、リソース数制御部３２０は、ＣＰＵコアの数を２つに決定して、リソース量決定部３３０にリソース量の配分決定を行わせる。図１４に示すように、０．９である均一体感品質ＡＱに対応して、Ｈ．２６４デコーダ、顔認識ＡＰ、ニュース閲覧ＡＰに配分されるリソース量Ｒｉは、７３％、９１％、３６％になる。
【０１０１】
ところで、上記において算出されたリソース量Ｒｉ通りの配分は実際にできない場合がある。例えば、アプリケーションは並列化されておらずＣＰＵをまたいで実行できない場合に、２００％のリソース量を７３％、９１％、３６％の配分で配分することができない。
【０１０２】
本実施の形態において、リソース量決定部３３０は、決定したリソース量をさらに配分可能に調整する機能を有する。例えば、各アプリケーションに対して、体感品質が閾値以上である前提下でリソース量を調整する。上記の例では、例えば、決定されたリソース量が最も大きい顔認識ＡＰに対してリソース量を１００％に変更し、Ｈ．２６４デコーダとニュース閲覧ＡＰについては、残りの１００％分を再配分する。これにより、調整後、Ｈ．２６４デコーダ、顔認識ＡＰ、ニュース閲覧ＡＰのリソース量は、７０％、１００％、３０％になる。
【０１０３】
図１５は、リソース配分装置３００における処理の流れを示すフローチャートである。まず、パラメータ決定部３１０は、アプリケーション毎に、推奨リソース量Ｒｉｈｉｇｈとそれに対応する体感品質Ｑｉｈｉｇｈ、最低リソース量Ｒｉｌｏｗとそれに対応する体感品質ＱｉｌｏｗＱＬを上述した式（５）と式（６）で示す連立方程式に代入して第１のパラメータａｉと第２のパラメータｂｉを算出する（Ｓ１５０）。これらの第１のパラメータａｉと第２のパラメータｂｉは、リソース量決定部３３０に出力される。
【０１０４】
リソース量決定部３３０は、各アプリケーションに配分するリソース量の総和が、１つのＣＰＵコアを使用する場合の所定量ＴＲになりように、均一体感品質ＡＱを算出してリソース数制御部３２０に出力する（Ｓ１５２）。
【０１０５】
リソース数制御部３２０は、リソース量決定部３３０からの均一体感品質ＡＱが予め定められた閾値より小さい場合に（Ｓ１５４：Ｎｏ）、リソース数を１つ増やして、対応する所定量ＴＲをリソース量決定部３３０に出力する（Ｓ１５６）。
【０１０６】
リソース量決定部３３０は、リソース数制御部３２０により再設定された所定量ＴＲを用いて均一体感品質ＡＱを再計算する（Ｓ１５２〜）。
【０１０７】
ステップＳ１５２からの処理は、均一体感品質ＡＱが閾値以上になるまで繰り返される（Ｓ１５４：Ｎｏ、Ｓ１５６、Ｓ１５２〜）。
【０１０８】
リソース量決定部３３０からの均一体感品質ＡＱが閾値以上になると（Ｓ１５４：Ｙｅｓ）、リソース数制御部３２０は、現在のリソース数を使用するリソース数として決定し、リソース量決定部３３０は、現在の均一体感品質ＡＱに対応する各アプリケーションのリソース量を決定する（Ｓ１６０）。
【０１０９】
そして、決定されたリソース量通りの配分が可能な場合には（Ｓ１６２：Ｙｅｓ）、リソース量決定部３３０は、決定されたリソース量で配分を行う。一方、決定されたリソース量通りの配分ができない場合には（Ｓ１６２：Ｎｏ）、リソース量決定部３３０は、決定されたリソース量を配分可能に調整する（Ｓ１６４）。
【０１１０】
本実施の形態のリソース配分装置３００によれば、リソース配分装置１００の効果を得ることができると共に、同種のリソースが複数存在する場合に、均一体感品質ＡＱが閾値以上である条件下で、リソースの数を最少にすることで、必要以上のリソース消費を抑えひいては消費電力の削減ができる。
【０１１１】
以上、実施の形態をもとに本発明を説明した。実施の形態は例示であり、本発明の主旨から逸脱しない限り、上述各実施の形態に対して、さまざまな変更、増減、組合せを加えてもよい。これらの変更、増減、組合せが加えられた変形例も本発明の範囲にあることは当業者に理解されるところである。
【０１１２】
この出願は、２０１０年３月１１日に出願された日本出願特願２０１０−０５４２８３を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【産業上の利用可能性】
【０１１３】
本発明は、コンピュータ上で動作する複数のアプリケーションへのリソースの配分に利用できる。
【符号の説明】
【０１１４】
１００  リソース配分装置  １１０  パラメータ決定部
１２０  リソース量決定部  ２００  リソース配分装置
２１０  パラメータ決定部  ２２０  受付部
２２２  増加ボタン  ２２４  減少ボタン
２３０  パラメータ調整部  ２２６  調整バー
２４０  リソース量決定部  ２２２  増ボタン
２２４  減ボタン  ２２６  調整バー
３００  リソース配分装置  ３１０  パラメータ決定部
３２０  リソース数制御部  ３３０  リソース量決定部
ＡＱ  均一体感品質  ａ  第１のパラメータ
ｂ  第２のパラメータ  ＴＲ  所定量
【図１】
2011111141.tif 000008
【図２】
2011111141.tif 000009
【図３】
2011111141.tif 000010
【図４】
2011111141.tif 000011
【図５】
2011111141.tif 000012
【図６】
2011111141.tif 000013
【図７】
2011111141.tif 000014
【図８】
2011111141.tif 000015
【図９】
2011111141.tif 000016
【図１０】
2011111141.tif 000017
【図１１】
2011111141.tif 000018
【図１２】
2011111141.tif 000019
【図１３】
2011111141.tif 000020
【図１４】
2011111141.tif 000021
【図１５】
2011111141.tif 000022
【手続補正書】
【提出日】平成24年8月15日(2012.8.15)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
コンピュータ上で動作する複数のアプリケーションに対してリソース量の配分を行うリソース配分装置であって、
前記複数のアプリケーション毎に、使用するリソース量とユーザの体感品質との関係を示す式（１）の品質関数ｆにおける第１のパラメータａと第２のパラメータｂを決定するパラメータ決定手段と、
該パラメータ決定手段により前記第１のパラメータａと第２のパラメータｂが決定された前記複数のアプリケーション毎の品質関数ｆを用いて、該複数のアプリケーションに配分するリソース量を決定するリソース量決定手段とを備え、
前記パラメータ決定手段は、当該アプリケーションに対して、推奨リソース量と該推奨リソース量に対応する体感品質、及び、最低リソース量と該最低リソース量に対応する体感品質を式（１）に代入することにより式（１）における第１のパラメータａと第２のパラメータｂを算出し、
品質関数ｆ（ｘ）は、逆関数f−１を有する単調増加関数であり、（−∞，０）と（＋∞，１）をつなぎ、ｘ＝０で点対称するものであることを特徴とするリソース配分装置。
Q＝f(x)＝f((R-a)/b)        (1)
但し，
Ｑ：体感品質
ｆ：品質関数
Ｒ：リソース量
ａ：第１のパラメータ
ｂ：第２のパラメータ
【請求項２】
前記複数のアプリケーションのうちの任意のアプリケーションについて、リソース量の増減要求を受け付ける受付手段と、
該任意のアプリケーションに対して前記パラメータ決定手段により決定された前記第１のパラメータａと第２のパラメータｂに、前記受付手段により受け付けられた増減要求が示す増加量に応じて増加する１より大きい倍数乗算し、前記受付手段により受け付けられた増減要求が示す減少量に応じて減少する１より小さい倍数を乗算するパラメータ調整手段をさらに有し、
前記リソース量決定手段は、前記任意のアプリケーションに対して、前記パラメータ調整手段により前記第１のパラメータａと第２のパラメータｂが調整された品質関数ｆを用いて、該アプリケーションに配分するリソース量を決定することを特徴とする請求項１に記載のリソース配分装置。
【請求項３】
前記リソース量決定手段は、
前記複数のアプリケーションに配分するリソース量の総和が所定量になり、かつ各アプリケーションの体感品質が同値の均一体感品質になるように、該複数のアプリケーションに配分するリソース量を決定することを特徴とする請求項１または２に記載のリソース配分装置。
【請求項４】
同種の複数のリソースが存在する際に、前記均一体感品質が予め定められた所定の閾値以上であることを条件に、前記複数のアプリケーションに配分されるリソースの個数が最少個になるように制御を行うリソース数制御手段をさらに備えることを特徴とする請求項３に記載のリソース配分装置。
【請求項５】
前記品質関数ｆ（ｘ）は、式（２）または式（３）であることを特徴とする請求項１から４のいずれか１項に記載のリソース配分装置。
f(x)=1/(1+e^(-x))            (2)
f(x)=(1/π)×arctan(x)+1/2    (3)
【請求項６】
コンピュータ上で動作する複数のアプリケーションに対してリソース量の配分を行うリソース配分方法において、
前記複数のアプリケーション毎に、推奨リソース量と該推奨リソース量に対応する体感品質、及び、最低リソース量と該最低リソース量に対応する体感品質を、使用するリソース量Ｒとユーザの体感品質Ｑとの関係を示す式（４）の品質関数ｆに代入することにより第１のパラメータａと第２のパラメータｂを決定し、
前記第１のパラメータａと第２のパラメータｂが決定された前記複数のアプリケーション毎の品質関数ｆを用いて、該複数のアプリケーションに配分するリソース量を決定し、
前記品質関数ｆ（ｘ）は、逆関数f−１を有する単調増加関数であり、（−∞，０）と（＋∞，１）をつなぎ、ｘ＝０で点対称するものであることを特徴とするリソース配分方法。
Q＝f(x)＝f((R-a)/b)        (4)
但し，
Ｑ：体感品質
ｆ：品質関数
Ｒ：リソース量
ａ：第１のパラメータ
ｂ：第２のパラメータ
【請求項７】
コンピュータ上で動作する複数のアプリケーションに対してリソース量の配分を行う際に、
前記複数のアプリケーション毎に、推奨リソース量と該推奨リソース量に対応する体感品質、及び、最低リソース量と該最低リソース量に対応する体感品質を、使用するリソース量Ｒとユーザの体感品質Ｑとの関係を示す式（５）の品質関数ｆに代入することにより第１のパラメータａと第２のパラメータｂを決定し、
前記第１のパラメータａと第２のパラメータｂが決定された前記複数のアプリケーション毎の品質関数ｆを用いて、該複数のアプリケーションに配分するリソース量を決定する処理をコンピュータに実行させ、
前記品質関数ｆ（ｘ）は、逆関数f−１を有する単調増加関数であり、（−∞，０）と（＋∞，１）をつなぎ、ｘ＝０で点対称するものであることを特徴とするプログラム。
Q＝f(x)＝f((R-a)/b)        (5)
但し，
Ｑ：体感品質
ｆ：品質関数
Ｒ：リソース量
ａ：第１のパラメータ
ｂ：第２のパラメータ
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】００３５
【補正方法】変更
【補正の内容】
【００３５】
なお、ＱｉｈｉｇｈとＱｉｌｏｗが下記の式（９）を満たす場合に、第１のパラメータａｉと第２のパラメータｂｉの算出は式（１０）と式（１１）が示すように簡単になる。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】００５３
【補正方法】変更
【補正の内容】
【００５３】
パラメータ決定部１１０は、アプリケーション毎に、Ｑｉｈｉｇｈ（ここでは０．８）、Ｒｉｈｉｇｈ、Ｑｉｌｏｗ（ここでは０．２）、Ｒｉｌｏｗを式（５）と式（６）に代入して第１のパラメータａｉと第２のパラメータｂｉを解く。この例では、Ｈ．２６４デコーダについて、第１のパラメータａｉと第２のパラメータｂｉはそれぞれ６５と３．６になり、顔認識ＡＰについて、第１のパラメータａｉと第２のパラメータｂｉはそれぞれ６０と１４．４になり、ニュース閲覧ＡＰについて、第１のパラメータａｉと第２のパラメータｂｉはそれぞれ２０と７．２になる。
【手続補正５】
【補正対象書類名】明細書
【補正対象項目名】００７９
【補正方法】変更
【補正の内容】
【００７９】
リソース量決定部２４０は、第１のパラメータと第２のパラメータとして調整後の第１のパラメータと調整後の第２のパラメータを用いて、リソース量決定部１２０と同様な演算により各アプリケーションへ配分するリソース量を決定する。
【手続補正６】
【補正対象書類名】明細書
【補正対象項目名】００９４
【補正方法】変更
【補正の内容】
【００９４】
リソース量決定部３３０は、パラメータ決定部３１０からの第１のパラメータａｉと第２のパラメータｂｉを用いて均一体感品質ＡＱを算出してリソース数制御部３２０に出力する。均一体感品質ＡＱの算出方法は、リソース配分装置１００におけるリソース量決定部１２０の手法と同様であるが、この算出に際して用いられる、アプリケーションに配分するリソース量の総和となる所定量ＴＲは、リソース数制御部３２０から供給される。
【手続補正７】
【補正対象書類名】明細書
【補正対象項目名】０１１４
【補正方法】変更
【補正の内容】
【０１１４】
１００  リソース配分装置  １１０  パラメータ決定部
１２０  リソース量決定部  ２００  リソース配分装置
２１０  パラメータ決定部  ２２０  受付部
２２２  増加ボタン  ２２４  減少ボタン
２２６  調整バー  ２３０  パラメータ調整部
２４０  リソース量決定部  ３００  リソース配分装置
３１０  パラメータ決定部  ３２０  リソース数制御部
３３０  リソース量決定部  ＡＱ  均一体感品質
ａ  第１のパラメータ  ｂ  第２のパラメータ
ＴＲ  所定量
【国際調査報告】
2011111141.tif 000023
2011111141.tif 000024
2011111141.tif 000025