ネットワークサービスの提供を行うサービス提供サーバと、前記ネットワークサービスの提供を受ける複数のサービス実行端末と、を備えるサービス制御システムであって、前記サービス実行端末は、前記サービス提供サーバより提供されるネットワークサービスを実行することで前記ネットワークサービスを端末ユーザに提供するサービス実行手段と、自端末の状態又は自端末周囲の状態を検出する端末状態検出手段と、前記端末状態検出手段における検出結果に基づいて前記端末ユーザが前記ネットワークサービスを利用しているか否かを判断するサービス利用状況判断手段と、前記サービス利用状況判断手段における判断結果を前記サービス提供サーバに通知するサービス利用状況通知手段と、を具備し、前記サービス提供サーバは、前記サービス実行端末より通知された前記判断結果に基づいて前記サービス実行端末に提供するネットワークサービスに対して配分するリソース量を決定するリソース配分決定手段と、前記リソース配分決定手段で決定されたリソース量に基づいて前記サービス実行端末に提供するネットワークサービスに対してリソースを配分するリソース配分実行手段と、前記リソース配分実行手段により配分されるリソースを用いてネットワークサービスの提供を前記サービス実行端末に対して行うサービス提供手段と、を具備する、サービス制御システム。サービス提供サーバより提供されるネットワークサービスを実行することで前記ネットワークサービスを端末ユーザに提供するサービス実行手段と、自端末の状態又は自端末周囲の状態を検出する端末状態検出手段と、前記端末状態検出手段における検出結果に基づいて前記端末ユーザが前記ネットワークサービスを利用しているか否かを判断するサービス利用状況判断手段と、前記サービス利用状況判断手段における判断結果を前記サービス提供サーバに通知するサービス利用状況通知手段と、を具備するサービス実行端末。前記サービス実行手段は、前記ネットワークサービスを複数の品質レベルで前記端末ユーザに対して提供可能であることを特徴とする、請求項2に記載のサービス実行端末。前記サービス実行手段が前記ネットワークサービスを所定の基準より低い品質レベルで前記端末ユーザに提供している場合において、前記端末ユーザから発せられる所定の動作を検知するユーザ反応検知手段を更に具備し、前記サービス利用状況通知手段は、前記所定の動作の検知結果を前記サービス提供サーバに通知する、請求項3に記載のサービス実行端末。前記サービス利用状況通知手段は、提供するネットワークサービスの品質レベルを下げることを示す通知を前記サービス提供サーバより受信し、前記ユーザ反応検知手段は、前記通知が受信された場合に前記端末ユーザが前記ネットワークサービスの品質レベルの低下に対する不満を表す動作を発しているか否かを判断する、請求項4に記載のサービス実行端末。前記端末状態検出手段は、自端末に生じる加速度、自端末の位置、自端末の傾き、自端末周囲の明るさ、の少なくとも1つを前記自端末の状態又は自端末周囲の状態として検出する、請求項2乃至請求項5のいずれか1項に記載のサービス実行端末。複数のサービス実行端末よりそれぞれ通知される各端末ユーザがネットワークサービスを利用しているか否かについての判断結果に基づいて前記複数のサービス実行端末にそれぞれ提供するネットワークサービスに対して配分するリソース量を決定するリソース配分決定手段と、前記リソース配分決定手段で決定されたリソース量に基づいて前記複数のサービス実行端末にそれぞれ提供するネットワークサービスに対してリソースを配分するリソース配分実行手段と、前記リソース配分実行手段により配分されるリソースを用いて前記ネットワークサービスの提供を前記複数のサービス実行端末に対して行うサービス提供手段と、を具備するサービス提供サーバ。前記サービス提供手段は、前記リソース配分実行手段により配分されるリソースに応じた配信ビットレートで前記サービス実行端末に対して動画配信を行う、請求項7に記載のサービス提供サーバ。前記サービス提供手段は、リソース消費量の異なる複数の動作モードを有するサービスアプリケーションタスクを備え、前記リソース配分決定手段は、前記判断結果に基づいて前記サービスアプリケーションタスクの動作モードを前記複数のサービス実行端末に提供するネットワークサービス毎に決定し、前記リソース配分実行手段は、前記リソース配分決定手段で決定された前記動作モードの指示を前記サービスアプリケーションタスクに対して行い、前記サービスアプリケーションタスクは、前記指示された動作モードでそれぞれ前記ネットワークサービスを各サービス実行端末に提供する、請求項7又は請求項8に記載のサービス提供サーバ。前記リソース配分決定手段は、前記サービスアプリケーションタスクの各動作モードが必要とするリソース量を示したモードリソース対応表と前記判断結果とに基づいて、前記複数のサービス実行端末に対するネットワークサービスの提供に必要なリソースの総量が、前記ネットワークサービス提供に利用可能なリソースの総量を超えないように、各サービス実行端末にネットワークサービスを提供するサービスアプリケーションタスクの動作モードを決定する、請求項9に記載のサービス提供サーバ。通信事業者により定額制やそれに近い通信料金プランが提供され、また、端末装置の高機能化と大画面化が進むにつれ、ユーザはいくつものアプリケーションを端末上で起動したまま放置する傾向にある。例えば、動画再生アプリケーションを起動したままユーザが端末のそばを離れたり、端末を鞄にしまったりすると、ユーザは既にそのサービスを享受しなくなっているが、サーバ、ネットワーク、及び端末のリソースは消費され続けている。これは電力消費の観点および通信コストの観点で問題となる。また、このような無駄なリソース消費が発生することにより、リソース逼迫時に、真にサービスを受けたいと希望しているユーザに対して十分なリソースを割けないという課題が生じている。このような課題は、通信事業者のサービス提供プランの変化や無線通信規格の高速化などを契機としてここ近年で新たに生じた課題であり、上記従来の技術ではこのような課題に適切に対応することができなかった。すなわち、特許文献1や特許文献2の技術では、通信品質に応じたリソース制御は行えるものの、ユーザに利用されないサービスに対しても、サーバ及びネットワークのリソースを消費してしまうという課題を解決することはできない。また、特許文献3の技術は、特定のユーザが複数の異なるサービスを同時利用している場合に、これらの各サービスに対するユーザの要求特性に応じた統計的制御は可能となるものの、やはり、複数ユーザが限られたリソースを共用している場合に、ユーザに利用されないサービスにリソースが消費されるという課題を解決することはできない。また、特許文献4の技術を持ってしても、仮想計算機のリソース配分を最適化できるに留まり、上記の課題を解決することはできなかった。本発明は上記課題を鑑み、サービスを享受しようとしていないユーザに対するサービス提供のために割かれるサーバ又はネットワークのリソースを削減することを目的とする。本発明のサービス制御システムは、ネットワークサービスの提供を行うサービス提供サーバと、前記ネットワークサービスの提供を受ける複数のサービス実行端末と、を備えるサービス制御システムであって、前記サービス実行端末は、前記サービス提供サーバより提供されるネットワークサービスを実行することで前記ネットワークサービスを端末ユーザに提供するサービス実行手段と、自端末の状態又は自端末周囲の状態を検出する端末状態検出手段と、前記端末状態検出手段における検出結果に基づいて前記端末ユーザが前記ネットワークサービスを利用しているか否かを判断するサービス利用状況判断手段と、前記サービス利用状況判断手段における判断結果を前記サービス提供サーバに通知するサービス利用状況通知手段と、を具備し、前記サービス提供サーバは、前記サービス実行端末より通知された前記判断結果に基づいて前記サービス実行端末に提供するネットワークサービスに対して配分するリソース量を決定するリソース配分決定手段と、前記リソース配分決定手段で決定されたリソース量に基づいて前記サービス実行端末に提供するネットワークサービスに対してリソースを配分するリソース配分実行手段と、前記リソース配分実行手段により配分されるリソースを用いてネットワークサービスの提供を前記サービス実行端末に対して行うサービス提供手段と、を具備する。また、本発明のサービス実行端末は、サービス提供サーバより提供されるネットワークサービスを実行することで前記ネットワークサービスを端末ユーザに提供するサービス実行手段と、自端末の状態又は自端末周囲の状態を検出する端末状態検出手段と、前記端末状態検出手段における検出結果に基づいて端末ユーザが前記ネットワークサービスを利用しているか否かを判断するサービス利用状況判断手段と、前記サービス利用状況判断手段における判断結果を前記サービス提供サーバに通知するサービス利用状況通知手段と、を具備する。また、本発明のサービス提供サーバは、複数のサービス実行端末よりそれぞれ通知される各端末ユーザがネットワークサービスを利用しているか否かについての判断結果に基づいて前記複数のサービス実行端末にそれぞれ提供するネットワークサービスに対して配分するリソース量を決定するリソース配分決定手段と、前記リソース配分決定手段で決定されたリソース量に基づいて前記複数のサービス実行端末にそれぞれ提供するネットワークサービスに対してリソースを配分するリソース配分実行手段と、前記リソース配分実行手段により配分されるリソースを用いて前記ネットワークサービスの提供を前記複数のサービス実行端末に対して行うサービス提供手段と、を具備する。本発明によれば、サービスを享受しようとしていないユーザに対するサービス提供のために割かれるサーバ又はネットワークのリソースを削減することが可能となる。本発明に係るネットワークサービス制御システムは、限られたリソースを用いてネットワークサービスを複数の端末ユーザに提供するシステムであって、実際にネットワークサービスを享受している端末ユーザに対して適切にリソースを割り当てることを可能とするシステムである。図1は、本発明に係るネットワークサービス制御システムの全体構成を示すシステム図である。本発明に係るネットワークサービス制御システムは、ネットワークサービスを提供するサービス提供サーバ20と、ネットワークサービスを利用する端末群10と、これらを相互に接続する有線ないし無線のネットワーク30と、を含んで構成される。以下、本発明の各実施の形態について図面を参照して詳細に説明する。実施の形態1図2は、本実施の形態1にかかるネットワークサービス制御システムを構成する端末100とサービス提供サーバ200の具体的構成を示すブロック図である。以下、各部の機能について詳細に説明する。まず、端末100の構成について説明する。端末100は、サービス実行部110と、端末状態検出部120と、サービス利用状況判断部130と、サービス利用状況通知部140と、ネットワークインタフェースNWI/F150と、を備える。サービス実行部110は、サービス提供サーバ200より提供されるネットワークサービスを実行する。具体的には、端末100が具備するCPUCentralProcessingUnit及びOSOperatingSystem上で動作する端末側アプリケーションが、サービス提供サーバ200より提供されるネットワークサービスを実行し、当該ネットワークサービスを端末ユーザに提供する。端末状態検出部120は、自端末の状態をセンシングすることで端末状態を検出する。端末状態検出部120は、具体的には、加速度センサ、傾きセンサ、光センサなどで構成され、当該センサで得られる端末状態についての検出結果をサービス利用状況判断部130に出力する。なお、ここでいう端末状態には、光センサで検出される自端末周囲の明るさ等、自端末周囲の状態も含まれるものとする。サービス利用状況判断部130は、端末状態検出部120より出力された検出結果を基に、端末ユーザのサービス利用状況を判断する。具体的には、サービス利用状況判断部130は、端末状態検出部120から入力した端末状態の検出結果に基づいてユーザの動作状態などユーザ状況を把握し、所定のアルゴリズムに従って、端末ユーザが自端末100を通じてネットワークサービスを享受しているか否か、すなわち、ネットワークサービスを利用しているか否かを判断する。サービス利用状況判断部130は、ユーザがネットワークサービスを利用しているか否かについての判断結果をコンテキスト情報としてサービス利用状況通知部140に出力する。サービス利用状況通知部140は、サービス利用状況判断部130より入力した端末ユーザがネットワークサービスを利用しているか否かの判断結果を、必要に応じてサービス提供サーバ200に通知する。例えば、サービス利用状況通知部140は、サービス利用状況判断部130から入力した上記端末ユーザがネットワークサービスを利用しているか否かの判断結果に変化が生じている場合は、当該判断結果を含むコンテキスト情報をサービス提供サーバ200に通知する。ネットワークインタフェース150は、自端末100がネットワーク30を介してサービス提供サーバと通信するための通信インタフェースである。端末100は、ネットワークインタフェース150を介してネットワークサービスの提供を受け、また、コンテキスト情報の送信等を行う。次に、サービス提供サーバ200の構成について説明する。サービス提供サーバ200は、サービス提供部210と、リソース配分決定部220と、リソース配分実行部230と、ネットワークインタフェースNWI/F240と、を備える。サービス提供部210は、リソース配分実行部230におけるリソース配分制御に従い、ネットワークインタフェース240を介して各端末にネットワークサービスの提供を行う。リソース配分決定部220は、ネットワークサービスを利用している複数の端末から通知される端末ユーザがネットワークサービスを利用しているか否かの判断結果を、ネットワークインタフェース240を介して受信し、当該判断結果に基づいてリソースの配分を決定する。具体的には、リソース配分決定部220は、各端末から通知される上記判断結果を含むコンテキスト情報を収集し、サービス享受していないネットワークサービスを利用していないユーザ向けのネットワークサービスに対して配分しているリソース量を減らし、サービス享受しているネットワークサービスを利用しているユーザ向けのネットワークサービスに対して配分しているリソース量を相対的に増やす決定を行う。なお、ここでいうリソースとは、サービス提供サーバのCPUやOSといったサーバ内リソースの他、サービスを利用する端末とサービス提供サーバ間の無線通信帯域のリソースなど、ネットワークサービス提供に必要となるリソースを言う。従って、ネットワークサービスに配分されるリソース量が減らされると、一般的に当該サービスの品質レベルが下がることになる。リソース配分決定部220は、リソース配分決定結果をリソース配分実行部230に通知し、リソース配分の指示を行う。リソース配分実行部230は、リソース配分決定部220から指示されたリソース配分に従って、サービス提供部210が各端末にそれぞれ提供するネットワークサービスに対してCPUやOSと言ったリソースを配分する。具体的には、リソース配分実行部230は、リソース配分決定部220から指示されたリソース配分に従って、サービス提供部210におけるネットワークサービス提供で消費されるリソースの具体的なリソース配分操作を行う。例えば、リソース配分決定部220よりサービス享受していないユーザ向けサービスに配分しているリソース量を減らす指示を受けた場合は、リソース配分実行部230は、当該サービスに割り当てているリソース量を減らす制御を行う。サービス提供部210は、このようにして配分されたリソースを使用して各端末にネットワークサービスを提供する。以上説明したように、本実施の形態1におけるネットワークサービス制御システムは、ネットワークサービスの提供を行うサービス提供サーバ及びネットワークサービスの提供を受ける複数のサービス実行端末を含んで構成される。そして、サービス実行端末は、サービス提供サーバより提供されるネットワークサービスを実行することでネットワークサービスを端末ユーザに提供するサービス実行手段と、自端末の状態又は自端末周囲の状態を検出する端末状態検出手段と、端末状態検出手段における検出結果に基づいて端末ユーザがネットワークサービスを利用しているか否か、すなわちネットワークサービスを享受しているか否かを判断するサービス利用状況判断手段と、サービス利用状況判断手段における判断結果をサービス提供サーバに通知するサービス利用状況通知手段と、を具備する。一方、サービス提供サーバは、サービス利用端末より通知された判断結果に基づいてリソース配分を決定するリソース配分決定手段と、リソース配分決定手段で決定されたリソース配分に従ってサービス利用端末に提供するネットワークサービスに対してリソースを配分するリソース配分実行手段と、リソース配分実行手段により配分されるリソースを用いてネットワークサービスの提供をサービス実行端末に対して行うサービス提供手段と、を具備する。このような構成とすることで、各端末は、自ユーザの状況を把握してネットワークサービスを享受しているかどうかの判断を行い、判断結果をサーバ側に通知する。限られたリソースを各端末に配分しながらサービス提供を行うサービス提供サーバは、これらの通知に基づいて、リソースの配分割合を操作し、ネットワークサービスを享受していないユーザに対するリソース割り当てを低下させる一方、ネットワークサービスを享受しているユーザに対して適切なリソース割り当てを行う。従って、例えば、端末ユーザがネットワークサービスを実行しているアプリケーションを端末上で起動したまま放置し、リソースの消費が発生する場合においても、サーバ側でこのようなユーザに対するリソース配分を下げ、空いたリソースを真にサービスを享受している他のユーザに対して適切に割り当てることが可能となる。また、このような構成とすることで、無駄なリソース消費を抑えることが可能となるため、サーバ及び端末でそれぞれ消費される電力を削減することができるとともに、ネットワークにおける通信コストの削減も可能となる。実施の形態2本実施の形態2に係るネットワークサービス制御システムは、実施の形態1に係るネットワークサービス制御システムに加えて、リソース調整に起因して発せられたユーザの不満動作を捉え、リソースの再配分を行う構成を更に備える。以下、本実施の形態2に係るネットワークサービス制御システムについて図面を用いて説明する。図3は、本実施の形態2に係るネットワークサービス制御システムの具体的構成を示す図である。ネットワークサービス制御システムは、ネットワークサービスの提供を受ける複数の端末300と、ネットワークサービスの提供を行うサービス提供サーバ400と含んで構成される。まず、端末300の構成について説明する。端末300は、CPU310と、センサ群320と、コンテキスト認識部330と、端末情報収集制御部340と、ネットワークインタフェースNWI/F350と、ユーザ反応検知部360と、端末側アプリケーション群370と、を備える。ここで、コンテキスト認識部330、ユーザ反応検知部360、端末情報収集制御部340、端末側アプリケーション群370は、端末CPU310上で動作するソフトウェアを用いて実現することが可能である。これらのソフトウェア動作には通常、主記憶メモリ、不揮発メモリFlashメモリ等、OS等が必要になるが、これらはコンピュータシステム一般に用いられるものであり、ここではあらためて図示しないが、端末300は当然に備えているものである。なお、CPU310上で動作する端末アプリケーション群370が、図2のサービス実行部110に対応する。また、センサ群320、コンテキスト認識部330、端末情報収集制御部340、NWI/F350は、それぞれ図2の端末状態検出部120、サービス利用状況判断部130、サービス利用状況通知部140、NWI/F150に対応している。以下、各部の機能について詳細に説明する。但し、図2で説明した部分については一部説明を省略する。CPU310は、ネットワークサービスに対応するアプリケーションである端末側アプリケーションを実行することで、サーバより提供されるネットワークサービスを実行し、当該サービスをユーザに提供する。センサ群320は、複数のセンサで構成され、当該センサを用いてセンシングを行い、自端末の状態又は自端末周囲の状態を検出する。センサ群320は、具体的には、GPSを利用して自端末の現在位置を検出する位置センサ、自端末の加速度を検出する加速度センサ、自端末の傾きを検出する傾きセンサ、自端末周囲の明るさを検出する光センサ等の各種センサを一つ又は複数組み合わせて構成される。なお、センサ群320を構成するセンサは上記センサに限定されるものではなく、ユーザが自端末に触れていることを検出する触覚センサの他、端末周囲を撮影する端末内蔵カメラ、端末周囲の音声を検出するマイクなども合わせてセンサとして利用することができる。センサ群320を構成するこれら各センサにおける端末状態の検出結果は、コンテキスト認識部330及びユーザ反応検知部360に送られる。コンテキスト認識部330は、前記センサ群320から受け取った検出結果に基づいてユーザの状況を把握する。具体的には、コンテキスト認識部330は、センサ群320を使用してユーザの振る舞いや端末の状況を推測し、ユーザが自端末を通じてサービスを享受している状態であるか否かを判断する。コンテキスト認識部330は、当該判断結果をコンテキスト情報として端末情報収集制御部340に送る。端末情報収集制御部340は、コンテキスト認識部330及びユーザ反応検知部360を制御して端末側の情報収集を行う。端末情報収集制御部340は、コンテキスト認識部330から得たコンテキスト情報を一時蓄積し、ユーザ状態が変化したタイミングで、当該コンテキスト情報とユーザIDとをあわせて端末コンテキストメッセージを作成する。端末情報収集制御部340は、当該端末コンテキストメッセージをネットワークインタフェース350を介してサービス提供サーバ400へ送信する。図4に端末コンテキストメッセージ710の一例を示す。端末コンテキストメッセージ710は、ユーザID711と、ユーザ状態コンテキスト情報712と、状態変化時刻713と、を含む。ここで、ユーザID711には、サービス提供サーバ400が各端末のユーザにユニークに付与している識別子が設定される。当該ユーザIDは通常、ユーザがサービス提供者にサービス提供を申し込む際にサービス事業者が割り当てるものである。ユーザ状態712部分には、コンテキスト認識部330より送られたコンテキスト情報が格納される。具体的には、ユーザ状態712部分には、活動中あるいは非活動中の値が設定され、それぞれユーザが当該サービスを享受しているしていないに対応している。また、状態変化時刻713には、端末100が内蔵する時計が刻む日付及び時刻の現在値が、ユーザ状態が変化した時刻として設定される。また、端末情報収集制御部340は、ユーザ反応検知部360から、ユーザからの不満動作が認識されたことを示す結果が送られた場合は、当該結果をコンテキスト情報として端末コンテキストメッセージを作成し、サービス提供サーバ400へ送信する。この場合の端末コンテキストメッセージ内のユーザ状態712には、活動中の値が記されている。また、端末情報収集制御部340は、後述するリソース配分決定メッセージをサービス提供サーバ400より受け取った場合は、当該メッセージで示される内容に従って、ユーザ反応検知部360に対してユーザが不満動作反論動作を行っているかの認識処理の開始を指示する。ネットワークインタフェース350は、端末300がネットワーク30を介してサービス提供サーバ400と通信するための通信インタフェースである。ユーザ反応検知部360は、センサ群320を構成する各センサの一部又は全部と接続されており、当該センサ群から入力した端末状態等の検出結果に基づいて、ユーザが特定の反応を行っているかを認識する処理を行う。具体的には、ユーザ反応検知部360は、ユーザ反応調査中及びユーザ反応調査停止中の2つの動作状態ユーザ反応調査モードを持ち、端末情報収集制御部340からの制御に従ってこれらの動作状態を切り替える。すなわち、ユーザ反応検知部360は、端末情報収集制御部340からユーザ反応調査の停止を指示されるとユーザ反応調査停止中状態に遷移し、ユーザ反応調査の開始を指示されるとユーザ反応調査中状態に遷移する。ユーザ反応検知部360は、その動作状態がユーザ反応調査中である間、ユーザが不満動作反論動作を行っているかの認識処理を継続して行う。すなわち、ユーザ反応検知部360は、ネットワークサービスの品質レベルの低下に対するユーザの不満動作、反論動作を認識する。ユーザ反応検知部360は、これらの不満動作を捉えたタイミングで、ユーザは当該サービスを享受していることを示す情報を端末情報収集制御部340に送る。端末側アプリケーション群370は、サービス提供サーバ400より提供される各種ネットワークサービスに対応したソフトウェアであり、CPU310及びOS上で動作する。端末側アプリケーション群370は、ネットワークサービスを複数の品質レベルで前記端末ユーザに対して提供可能であり、サービス提供サーバが行うリソース制御に基づく品質レベルで提供されるネットワークサービスを実行し、ネットワークサービスを端末ユーザに提供する。また、端末側アプリケーション群370は、ユーザからの入力等をトリガーとしてネットワークサービスの開始を要求するネットワークサービス開始要求メッセージを、ネットワークインタフェース350を介してサービス提供サーバ400に送信する。なお、当該ネットワークサービス開始要求メッセージには、ユーザID、現在の時刻、要求するネットワークサービスの内容を指定する情報等が含まれる。当該メッセージを受け取ったサービス提供サーバ400は、当該端末ユーザに対するネットワークサービスの提供を開始する。その後、端末側アプリケーションがサービス提供サーバより提供されるネットワークサービスを実行することにより、当該ネットワークサービスがユーザに提供される。次に、サービス提供サーバ400の構成について説明する。サービス提供サーバ400は、1つ以上のCPU410と、OS415と、リソース配分決定部420と、リソース配分実行部430と、ネットワークインタフェースNWI/F440と、サービスアプリケーション群450と、を備える。端末300と同様、これらの構成要素の一部はソフトウェアとして実現されることが通例であり、サービス提供サーバ400はそのために必要な主記憶メモリ、不揮発メモリ等を当然に備える。なお、当該CPU410及びOS415上で動作するサービスアプリケーション群450が、図2のサービス提供部210に対応する。また、リソース配分決定部420及びリソース配分実行部430が、それぞれ図2のリソース配分決定部220及びリソース配分実行部230に対応する。CPU410は、サービスアプリケーション群450を実行することで、各ユーザより要求されているネットワークサービスを提供する。OS415は、CPU410上で動作し、サービスアプリケーション群450のタスク管理等を行う。リソース配分決定部420は、各端末から送信されたコンテキスト情報に基づいて各端末へのリソース配分を決定する。すなわち、リソース配分決定部420は、各端末からのコンテキスト情報を収集し、サービス享受していないユーザ向けサービスに配分しているリソース量を減らし、サービス享受しているユーザ向けサービスに配分しているリソース量を相対的に増やす決定を行う。リソース配分決定部420は、決定したリソース配分決定結果をリソース配分実行部430に通知する。また、リソース配分決定部420は、前記リソース配分決定結果を、リソース配分決定メッセージとして端末300に送信する。図5は、リソース配分決定メッセージ720の一例を示している。リソース配分決定メッセージ720は、ユーザID721とサーバ側リソース配分決定結果722とが含まれる。ここで、ユーザID721は、各ユーザを識別するIDであり、サーバ側リソース配分決定結果722は、後述するリソース配分決定処理に基づいて決定されたリソース配分の結果を示している。具体的には、サーバ側リソース配分決定結果722には、ユーザがサービスを享受しているとして通常の品質レベルに対応するリソース量のリソースが配分されていることを示す活動中又は、ユーザがサービスを享受していないとして所定の基準値以下の品質レベルに対応するリソース量のリソースが配分されていることを示す非活動中のどちらかの情報が含まれている。サーバ側リソース配分決定結果722に非活動中の情報が含まれるリソース配分決定メッセージ720は、提供するネットワークサービスの品質レベルを下げることを示す通知となる。リソース配分実行部430は、リソース配分決定部420より指示されたリソース配分に従ってサーバCPU410、OS415及びサービスアプリケーション群450に対する具体的なリソース配分操作を行う。具体的には、リソース配分実行部430は、各サービスアプリケーション群450やOS415に指示して、リソース配分決定部420より指示された動作モードでアプリケーションを動作させる。ここでサービスアプリケーションだけでなくOSに対しても指示を出すのは、CPU優先度、メモリ割り当て、ネットワーク帯域割り当て等において、アプリケーション単独では希望するリソース配分が十分行えない場合に、OS側からもリソース配分調整を行うためである。また、リソース配分計算の都合上、全アプリケーションが要求するリソース量の総和がシステム全体リソース量を超えてしまっている場合は、最終調整手段としてOS415が備える規定のリソース配分動作に委ねる。即ち、OS415が各アプリケーションタスクに対するリソース配分をベストエフォートで自動調整する。ネットワークインタフェース440は、自サーバ400がネットワーク30を介して複数の端末と通信するための通信インタフェースである。サービスアプリケーション群450は、リソース配分実行部430により配分されたリソースを用いてサーバ側でネットワークサービスを実行し、ネットワークインタフェース440を介して当該ネットワークサービスを各端末に提供する。次に、リソース配分決定部420の具体的構成及びリソース配分決定動作について説明する。図6は、リソース配分決定部420の具体的構成を示すブロック図である。リソース配分決定部420は、全端末情報管理部421と、端末サービス管理テーブル422と、端末配分リソース計算部423と、タイマ424と、モードリソース対応表425と、を備える。全端末情報管理部421は、サービス提供先の端末群の現在状況を管理する。具体的には、全端末情報管理部421は、各端末から送られてきたネットワークサービス開始要求メッセージや端末コンテキストメッセージをネットワークインタフェース440を介して受け取り、端末サービス管理テーブル422内にエントリを新規追加ないし既存エントリの更新を行う。ここで、端末サービス管理テーブル422は、各端末ユーザの状態及びサービスレベルの方針が記録されたレコード集合体である。図7に端末サービス管理テーブル422の一例を示す。端末サービス管理テーブル422には、ユーザに固有に割り当てられたユーザID4221、ユーザの現在の状態を示すユーザ状態4222、当該ユーザ向けにサービスを提供しているサービスアプリケーションを示すサービスアプリ識別子4223、当該ユーザのユーザ状態が変化した時刻を示す状態変化時刻4224、及びサービスアプリケーションの動作モードに関する2種の値即ち目標動作モード4225と調整済動作モード4226、の各フィールドからなるレコードの集合体が記憶される。ここで、動作モードとは、異なるいくつかの提供サービスレベルに対し、あるサービスアプリケーションがとる動作の形態の集合である。異なる動作モードでは、サービスレベルサービスの品質レベルが異なるため、サービス提供に必要となるリソース消費量も異なる。一例を挙げると、提供するネットワークサービスが動画配信サービスであれば、アプリケーションは一般に配信ビットレートや解像度、ノイズ低減や色調改善処理の実施程度等をそれぞれ何段階かとることができるが、これらのうち当該サービス実現に対し妥当な組み合わせを当該アプリケーションの動作モードと呼ぶ。端末サービス管理テーブル422に含まれる目標動作モードは端末ごとのサービスレベルの希望値を表すものであり、システム全体リソースが限定される中では必ずしもそれらの希望がすべてかなえられるわけではない。それに対し調整済動作モードはシステム全体リソース量に収まるように各端末サービス間で調整がなされた後のサービスレベルの値である。モードリソース対応表425は、サービスアプリケーション各々の動作モードと必要リソース量との関係を記憶した管理テーブルである。アプリケーションに指示して動作モードを変更すると、当該アプリケーションが使用するリソース例えばCPU時間やネットワーク帯域等の量も変化するのが通例である。システム設計者はサービス運用に先立ち、設計情報及び実システム上での評価を通じて、各動作モードでの動作において当該アプリケーションが使用するリソース量を測定する。モードリソース対応表425には、その結果が表にして記載されている。あるアプリケーションに対する動作モードは一般に複数あるが、そのうち、アプリケーションの通常動作、言い換えれば、設計されたサービスを十分に提供できる動作モードを、通常動作モードと呼ぶ。逆に、最小限の動作、言い換えれば、ユーザにサービスを享受する様子がみられない場合にアプリケーションがとるべき動作モードを、待機時動作モードと呼ぶ。動作モードの集合はサービス運用開始に先立ち、システム設計時にシステム設計者が選定するが、それらのうち、最も多くのリソースを必要とするものが通常動作モード、最もリソースが少なくて済むものが待機時動作モードとなる。図8にモードリソース対応表の一例を示す。この例ではアプリケーション1において動作モードは5つあり、そのうち動作モード5が通常動作モード図8にてactiveと表示、動作モード1が待機時動作モードinactiveと表示である。全端末情報管理部421は、端末コンテキストメッセージを新たに受け取ると端末サービス管理テーブル422に新規追加又は更新するエントリの各フィールドに次のように値を設定する。全端末情報管理部421は、端末コンテキストメッセージに含まれるユーザID、ユーザ状態、状態変化時刻の値をそれぞれエントリ内のユーザID、ユーザ状態、状態変化時刻のフィールドに記録する。また、全端末情報管理部421は、当該端末に対するサービスを提供しているアプリケーションの識別子をエントリ内のサービスアプリのフィールドに記憶する。次に、全端末情報管理部421は、端末コンテキストメッセージに含まれるユーザ状態712が活動中であれば当該サービスアプリケーションの通常動作モードの値、ユーザ状態712が非活動中であれば当該サービスアプリケーションの待機時動作モードの値、をそれぞれエントリ内の目標動作モードのフィールドに記録する。なお、調整済動作モードは、リソース調整が行われた後の動作モードの値が記憶されるフィールドであり、後述する端末配分リソース計算部423にて値が設定される。タイマ424は、指示されたタイミングでタイマ割込み通知を端末配分リソース計算部423に出す。タイマ424は予め、サービスレベルの再計算をするのに適した間隔でタイマ割込み通知を発行し続けるよう指示される。この適した間隔とは、OS415がその上のアプリケーションタスクをスケジューリングする時間間隔よりも十分長く、端末ユーザがサービスに対して人間的に知覚し、反応する時間よりも長い時間間隔であり、例えば数秒ないし数十秒程度の範囲から選定するように設定されることが好ましい。端末配分リソース計算部423は、端末サービス管理テーブル422を読み込み、各端末に対するリソース配分量を再計算する。具体的には、全端末情報管理部421が端末サービス管理テーブル422のエントリを追加ないし更新したタイミング、あるいはタイマ424からタイマ割込み通知されたタイミングで、後述の手順で各端末向けサービスアプリケーションに対する調整済動作モードを計算する。端末配分リソース計算部423は、計算した調整済み動作モードの値を端末サービス管理テーブル422の各エントリ内の当該フィールドに設定する。また、端末配分リソース計算部423は、端末サービス管理テーブル422の各エントリの調整済動作モード4226の値をリソース配分実行部430に伝える。リソース配分実行部430は、当該通知される調整済動作モードの値に従ってリソース配分を実行する。図9は、端末配分リソース計算部423における調整済動作モードの計算手順を示すフローチャートである。端末配分リソース計算部423は、端末サービス管理テーブル422内の各エントリのサービスアプリ4223の値以下、APiと称すと目標動作モード4225の値以下、MPiと称すをそれぞれ読み取るステップS1001。次に、端末配分リソース計算部423は、端末サービス管理テーブル422内の全エントリに対する目標動作モードMTiに必要なリソース量の総和Rtを求めるステップS1002。具体的には、端末配分リソース計算部423は、ステップS1001で読み取った各端末向けサービスを実行するためのアプリケーションである上記APiのモードリソース対応表図8を参照し、各エントリの目標動作モードMTiに必要なリソース量Riを算出する。そして、端末配分リソース計算部423は、当該算出処理を全エントリに対して行うことで総和Rtを求める。次に、端末配分リソース計算部423は、リソース配分実行部430に問い合わせ、現時点でサーバにて利用可能なリソース量Raを得るステップS1003。端末配分リソース計算部423は、ステップS1002で求めたRtの値とステップS1003で得たRaの値とを比較するステップS1004。ステップ1004の比較処理の結果、Rt≦Raであれば、現時点では全サービス提供に対しシステム全体リソースは足りていることになる。従って、端末配分リソース計算部423は、各アプリケーションの目標動作モードの値MPiをそのまま各アプリケーションの調整済動作モードの値に設定するステップS1005。即ち、端末配分リソース計算部423は、端末サービス管理テーブル422内の各エントリに対し、目標動作モード4225の値を同エントリ内の調整済動作モード4226にそのまま設定し、リソース配分計算処理を終了する。他方、ステップ1004の比較処理の結果、Rt>Raの場合は、現時点では全サービス提供に対しシステム全体リソースは足りていないことを意味する。そこで、端末配分リソース計算部423は、サービス提供に必要となるリソースの総和がサーバにて利用可能なリソース量Ra内に収まるように、動作モードの調整を行う。具体的には、端末配分リソース計算部423は、第1にリソース削減調整率Prを算出するステップ1006。ここで、リソース削減調整率Prは、システム全体としてどの程度のリソース消費量圧縮が必要かを示す値であり、次のようにして求められる。1Pr=Ra÷Rt次に、端末配分リソース計算部423は、このPrを用いてサービスアプリケーション毎の動作モードを修正するステップ1007。具体的には、端末配分リソース計算部423は、端末サービス管理テーブル422内の各エントリ図7のAPiのモードリソース対応表図8を参照し、その表の第2列必要リソース量中の値がRi×Prに最も近い行を選び、その行の第1列から動作モードの値を得る。ここで得た動作モード値を端末サービス管理テーブルエントリの調整済動作モードフィールド4226に設定し、本リソース計算手順全体を終了する。上記リソース配分調整操作は、サービスアプリケーション側が希望するリソース量に対し、リソース削減調整率Prで割り掛けされたリソース量にもっとも適合する動作モードを調整済動作モードに選定する、という意味を持っている。この選定処理を端末サービス管理テーブル422内の全エントリに対して行うことで、本リソース計算手順全体が完了する。次に、本システムの動作について説明する。まず、端末300の動作について説明する。本発明の特徴となる端末300の動作は、大きく分けて、サービス享受状態判断処理、ユーザ反応調査モード変更処理、不満動作検出処理の3つの処理からなる。図10は、サービス享受状態判断処理の流れを示すフローチャート図である。端末300は、図10に示す処理を繰り返し行うことでユーザのサービス享受状態が変化したかを判断する。具体的には、一定周期例えば5秒毎で発生し続けるようなタイマ割り込みを設定しておき、そのタイマ割り込みのハンドラ割り込み処理ルーチンとして、図10に示すフローを登録しておくことでサービス享受状態の変化の判断を継続的に行う。以下図10に示す動作について説明する。端末情報収集制御部340は、タイマ割り込みが入ると、未送信の端末コンテキストメッセージが一時保存されているかどうかを確認するS2001。未送信の端末コンテキストメッセージが一時保存されている場合は、当該未送信端末コンテキストメッセージを送信するS2002。S2001において未送信端末コンテキストメッセージが無い場合、又は、ステップ2002で未送信端末コンテキストメッセージが送信されると、コンテキスト認識部330は、センサ群320を使ってセンシングを行い、端末の状態又は端末周囲の状態を調査するS2003。ここで、コンテキスト認識部330が調査する端末の状態としては、例えば、位置GPSによる、加速度、傾き重力加速度によるなどがあり、端末周囲の状態としては、端末周囲の明るさ照度によるやカメラで取得される画像により認識される端末周囲の状態などとすることができる。コンテキスト認識部330は、S2003の調査の結果に基づいて、ユーザの現在の状況を推測し、端末ユーザのサービス享受状態が変化しているかどうかを判断するS2004。例えば、コンテキスト認識部330は、加速度センサで得られる端末の加速度の時系列変化を分析することで、端末を持つユーザの動作状態、例えば走っているか静止しているかを識別することができる。また、コンテキスト認識部330は、位置検出センサで得られる現在位置に関する情報と地図データとを照合することでユーザが自宅にいる電車に乗っている職場や学校にいる、といった識別を行うことができる。また、コンテキスト認識部330は、傾きセンサで得られる端末の傾きや、光検出センサで得られる端末周囲の明るさ、その他端末内部に設けられた現在時刻を算出する時刻管理部より得られる現在時刻などの情報に基づいて、ユーザが端末を手に持って利用しているかどうかのヒントを得ることができる。更には、コンテキスト認識部330は、端末のキーやタッチスクリーン操作頻度を監視し、また、無線LANや3G第3世代携帯電話の電波状態を監視し、これらの監視結果からユーザ状態の手掛かりが得られる。また、コンテキスト認識部330は、端末が具備する内蔵カメラやマイクにより取得される映像や音声を分析することにより、ユーザ状態の手掛かりを得ることもできる。コンテキスト認識部330は、これらの識別手法をいくつか組み合わせてユーザ状態を推測し、そのとき端末300で起動されてネットワークサービスを実行している端末側アプリケーションの種類とあわせ、端末ユーザがサービスを享受しているか否かを判断する。コンテキスト認識部330は、S2004における判断の結果、前回行った判断時と比べて端末ユーザのサービス享受状態が変化していない場合、一連の処理を終了する。一方、端末ユーザのサービス享受状態が変化している場合、コンテキスト認識部330は、端末情報収集制御部340に、サービス享受状態が変化したこと示すコンテキスト情報を通知し、端末情報収集制御部340は、当該コンテキスト情報と、ユーザIDと、現在の時刻を示す時刻情報とを含めて、端末コンテキストメッセージを作成するS2005。次に、端末情報収集制御部340は、サービス提供サーバ400と通信が可能であるかを調べるS2006。サービス提供サーバ400と通信が不可能な状態であれば、端末情報収集制御部340は、作成した端末コンテキストメッセージを一時的に保存して処理を終了するS2007。一方、通信が可能な状態であれば、端末情報収集制御部340は、ネットワークインタフェース350を介して、前記端末コンテキストメッセージをサービス提供サーバ400に送信し、処理を終了するS2008。次に図11に示すフローチャートを用いてユーザ反応調査モード変更処理の流れについて説明する。端末情報収集制御部340は、サービス提供サーバ400から自端末宛てのリソース配分決定メッセージの到着を監視するS2101。具体的には、端末情報収集制御部340は、ネットワークインタフェースを介してリソース配分決定メッセージを受信すると、当該メッセージに含まれるユーザID721の値を確認し、自端末のユーザIDに一致しているかどうかを確認することで、自端末宛てのリソース配分決定メッセージであるかどうかを判断する。端末情報収集制御部340は、当該メッセージに含まれるユーザID721の値が自端末のユーザIDに一致しない場合は、当該メッセージを破棄し、リソース配分決定メッセージの到着の監視を継続する。端末情報収集制御部340は、自端末宛てのリソース配分決定メッセージを受信した場合、自端末に対するリソース割り当ての状況を判断するS2102。具体的には、端末情報収集制御部340は、当該メッセージ内のサーバ側リソース配分決定結果722の値を確認する。サーバ側リソース配分決定結果722の値が活動中を示していない場合は、端末情報収集制御部340は、ユーザ反応検知部360に対し、非活動中ユーザ反応調査の開始を指示し、S2101に戻って自端末宛てのリソース配分決定メッセージの到着を監視するステップS2103。一方、サーバ側リソース配分決定結果722の値が活動中を示している場合は、ユーザ反応検知部360に対し、非活動中ユーザ反応調査の停止を指示し、S2101に戻って自端末宛てのリソース配分決定メッセージの到着を監視するステップS2104。上記処理によりユーザ反応調査部360の動作モードであるユーザ反応調査モードの変更を行う。具体的には、端末状態収集制御部340は、ステップ2103及びステップ2104において、大域変数、共有メモリあるいはメッセージ通信等の仕組みにより、非活動中ユーザ反応調査を行うか否かのモード値をユーザ反応検知部360に伝える。次に図12に示すフローチャートを用いて不満動作検出処理の流れについて説明する。ユーザ反応検知部360は、一定間隔ごとのタイマ割り込みで非活動中ユーザ反応調査が指示されているかどうかを判断するS2201。具体的には、ユーザ反応検知部360は、図11のS2103及びS2104において端末情報収集制御部340が大域変数、共有メモリあるいはメッセージ通信等前述した仕組みを用いて通知したモード値を参照することで、非活動中ユーザ反応調査が指示されているか否かを判断する。S2201における確認の結果、非活動中ユーザ反応調査の停止が指示されている場合は、そのまま処理を終了する。一方、非活動中ユーザ反応調査の開始が指示されている場合は、非活動中ユーザ反応調査を実施するS2202。ユーザ反応検知部360は、ユーザ反応調査中にネットワークサービスの品質レベル低下に対するユーザの不満動作反論動作が発せられたかどうかを判断するS2203。例えば、ユーザ反応検知部360は、加速度センサを使い、短い時間間隔で加速度が振動することで端末が振られていると認識し、これをユーザの不満動作として捉えるという認識方式を用いることができる。また、ユーザ反応検知部360は、加速度センサで急激な加速が検出されることでユーザが端末を叩く動作を認識し、これをユーザの不満動作として捉えるという認識方式を用いることができる。ユーザ反応検知部360は、ユーザ反応調査中に不満動作を検出しなかった場合は、処理を終了する。一方、ユーザ反応検知部360は、ユーザ反応調査中に不満動作が検出された場合は、端末情報収集制御部340にユーザの不満動作が検出されたことを通知する。端末情報収集制御部340は、ユーザ反応検知部360より当該通知されたユーザの不満動作に関する情報をコンテキスト情報として、端末コンテキストメッセージを作成してサービス提供サーバ400に送信し、処理を終了するS2204次に、サービス提供サーバ400のサービス制御動作について図13に示すフローチャートを用いて説明する。リソース配分決定部420は、図10に示すS2002又はS2008において送信された端末コンテキストメッセージを受け取ると、内部の端末サービス管理テーブル422に記憶している当該端末のエントリを更新するS3001。具体的には、当該エントリに含まれるユーザ状態4222を、端末コンテキストメッセージ710に含まれるユーザ状態712で示される状態に変更する。すなわち、端末コンテキストメッセージ710を受け取り、当該メッセージに含まれるユーザ状態712が非活動中である場合には、当該エントリに含まれるユーザ状態4222を非活動中に変更する。そして、当該エントリに含まれる目標動作モード4225の値を待機時動作モードの値に変更する。一方、当該メッセージに含まれるユーザ状態712が活動中である場合には、当該エントリに含まれるユーザ状態4222を活動中に変更する。そして、当該エントリに含まれる目標動作モード4225の値を通常動作モードの値に設定する。次に、リソース配分決定部420は、図9で説明したフローチャートに従ってリソース配分を計算するS3002。リソース配分決定部420は、計算結果をリソース配分実行部430に通知する。リソース配分実行部430は、通知されたリソース配分に従ってリソースを配分するS3003。各サービスアプリケーション450は、リソース配分実行部430で実行されるリソース配分に従い、ネットワークサービスを提供するS3004。リソース配分決定部420は、S3002で決定したリソース配分結果を対応する端末に通知するS3005。以上説明したように、本実施の形態では、端末側のセンサ等を用いてユーザ及び端末の状況を推測判断し、その情報をサービス提供サーバ側に集めることで、各端末に対するサービスへのリソース配分量を変化させている。特に、サービスを享受していないユーザ向けのサービスに対するリソース配分量を時間的に漸減させ、また、サービスを享受している意思を表明したユーザ向けのサービスに対してはリソース配分量を復元させている。上記構成により、サービス提供側のサーバ及びネットワークリソースの消費電力及び通信コストの削減、並びに、サービスを真に享受しようとしているユーザに対するリソース集中配分によるサービス品質向上、という本発明の効果が得られる。その理由は、サービス提供サーバ側において、それぞれの端末側で取得された各端末ユーザの状況を受け取ることで当該状況を知り、端末側で最終的に利用されていないサービスに対してサーバ及びネットワークで割り当てているリソースを減らすことができるようになるためである。例えば、サーバのCPUリソースを減らせば消費電力削減につながり、ネットワークを介して配信するデータ量を減らせばサービス提供者がネットワーク運用者に支払う通信費用を低減するとともに、サーバ運用者やネットワーク運用者が保有するネットワーク装置の消費電力抑制に寄与することになる。なお、上記説明では、リソース配分決定部420が、ネットワークサービスを享受していないことを示す端末コンテキストメッセージを受け取った場合に、エントリ内の目標動作モードの値を待機時動作モードの値に設定し、当該設定後の各エントリを用いてリソース配分を決定する場合について説明したが、これに限るものではない。図14は、リソース配分決定部420におけるリソース配分決定の別の処理動作を示すフローチャートである。なお、端末配分リソース計算部423が本フローチャートに従ってリソース配分計算を行う場合は、全端末情報管理部421は、非活動中を示す端末コンテキストメッセージを受け取っても、エントリに含まれるユーザ状態を非活動中に設定するに留まり、目標動作モードは通常動作モードのままに設定しておく。図14のS4001~S4005は、図9のS1001~S1005と同一であるため説明を省略する。S4004においてRt>Raである場合は、端末配分リソース計算部423は、端末サービス管理テーブル422に記録されているエントリのうち、ユーザ状態が非活動中であるエントリの目標動作モードの値MPiを待機時動作モードの値に設定するS4006。端末配分リソース計算部423は、S4006において全ての非活動中のエントリの目標動作モードを待機時動作モードの値に変更した後、必要リソースの総和Rt′を改めて算出するS4007。端末配分リソース計算部423は、S4007でユーザ状態を反映させて再計算した必要リソースの総和Rt′と利用可能なリソース量Raを再度比較するS4008。端末配分リソース計算部423は、比較の結果Rt′≦Raである場合は、S4005と同様、MPiの値を調整済み動作モードフィールドに設定し、計算処理を終了するS4009。一方、比較の結果Rt′>Raである場合は、端末配分リソース計算部423はPr′を算出するS4010。ここでリソース削減調整率Pr′はPr同様以下の式で求められる。2Pr′=Ra÷Rt′次に、端末配分リソース計算部423は、図9のS1007同様、リソース削減調整率Pr′を用いてサービスアプリケーション毎の動作モードを修正するS4011。次に、端末配分リソース計算部423は、修正した動作モードの値を調整済動作モード4226に設定し、計算処理を終了するS4012。上記計算手順に従ってリソース配分を計算することで、リソース逼迫時にユーザ状態を考慮したリソース配分を行うため、リソース逼迫時においてもネットワークサービスを享受しているユーザに適切にリソースを割り当てることができる。また、このような計算方法を用いることにより、端末がユーザ状態を誤って認識し、誤ったサービス利用状況に関する情報を含む端末コンテキストメッセージを送信しても、サーバ側でリソースに余裕がある場合は、このようなユーザに対するネットワークサービスの品質は維持される。従って、端末がユーザ状態を誤って判断し、ネットワークサービスの品質が下げられることでユーザの不満動作が発せられるといった事態を減らすことができる。次に、具体的な実施例を用いて本発明を実施するための最良の形態の動作を説明する。実施例1本実施例に係るネットワークサービス制御システムは、図1に示したように1台のサービス提供サーバと複数の端末とを含んで構成され、当該サービス提供サーバは、ネットワークサービスとして具体的に動画配信サービスを携帯端末に対して提供する。すなわち、本実施例におけるネットワークサービス制御システムにおいて、サービス提供サーバは動画配信サーバであり、端末は動画配信を視聴可能な携帯端末である。図15は本実施例において動画配信を受ける携帯端末500の実現形態を示した図である。携帯端末500は、ハードウェアとして、携帯端末用CPU510と、GPS521と、加速度センサ522と、時計523と、3G公衆無線サービスと屋内ワイヤレスLANに対応した無線インタフェース550及びそれに付属するアンテナと、を備える。また携帯端末500は、ソフトウェアとして、携帯端末用OS515と、動画配信サーバから受信した動画ストリームを再生する動画視聴アプリ570と、本発明の主たる構成要素のひとつとなる端末制御アプリ580と、を備える。本発明の実施の形態2で説明したコンテキスト認識部、及び端末情報収集制御部、ユーザ反応検知部、は、いずれもそれらをソフトウェアとして実現したモジュール図15の581、582、及び583として端末制御アプリ580の中に実装される。コンテキスト認識モジュール581は、GPS521から得た位置情報と、加速度センサ522から得た端末の動きと、及び時計523から得た現在日時と、を用いてユーザの状況を判断する。例えば、時計523から得た現在日時が平日の朝夕の時間帯内であり、GPSから取得した現在の位置情報が予め登録している自宅及び勤務先との間を示しており、加速度センサから得られる直近10秒間の加速度が徒歩ないし電車乗車中ないしバス乗車中の加速度波形と高い類似度を示す場合は、非活動中と判断する。また、平日の日中で、位置情報が勤務先にある場合は、非活動中と判断する。また、深夜0時から朝6時までの間で、直近10秒間の加速度が0の場合は、非活動中と判断する。一方、条件に合致しない場合は、活動中と判断する。いずれの場合も、活動中と非活動中との間で状態変化があった場合、コンテキスト認識モジュール581は、端末情報収集制御モジュール582にその変化を通知する。なお、上述のユーザ状況判断条件は、サービスの種類やユーザの行動特性会社員か学生か高齢者か等の情報をあわせて適切なものに変更すべきであることは言うまでもない。すなわち、ユーザの行動特性に関する情報やユーザが設定した設定情報を予め図示せぬ記憶部に記憶しておき、コンテキスト認識モジュール581は、ユーザ状況の把握に当該記憶部に記憶されている上記情報を参照してもよい。ユーザ反応検知モジュール583は、端末情報収集制御モジュール582から非活動中ユーザ反応調査の開始を指示された場合、加速度センサ522の出力を監視し、急激で大きな加速度変化を観測した場合は、端末情報収集制御モジュール582に対し、活動中への状態遷移を通知する。端末情報収集制御モジュール582は、無線インタフェース550から電波状態を調べ、屋内ワイヤレスLANによる通信が可能であればそれを使い、屋内ワイヤレスLANが使えなければ3G公衆無線サービスを使って、ユーザの活動中及び非活動中の状態変化を端末コンテキストメッセージに纏めて動画配信サーバに送る。図16は、動画配信サーバ600の実現形態を示した図である。動画配信サーバ600は、ハードウェアとして、サーバ用CPU群610と、高速イーサネットインタフェース640イーサネットは登録商標。以下省略。とを備える。高速イーサネットインタフェース640は、外部の通信ネットワーク網に接続されており、サービス対象の携帯端末と通信できるようになっている。動画配信サーバ600は、ソフトウェアとして、サーバ用OS615と、サービスを実施する動画配信アプリ群650と、本発明の主たる構成要素のひとつとなるサービス制御アプリ660と、を備える。本発明の実施の形態2で説明したリソース配分決定部、リソース配分実行部は、いずれも、それらをソフトウェアとして実現したモジュールとしてサービス制御アプリ660内部に実装される。具体的には、サービス制御アプリ660には、リソース配分決定モジュール661、リソース配分実行モジュール662、モードリソース対応表663、端末サービス管理テーブル664がそれぞれ実装されている。動画配信アプリ群650は、複数の動作モードを有し、リソース配分実行モジュール662からの指示によりそのいずれかの動作モードで動作する。サーバ用OS615は、動画配信アプリ群650で使われなかったリソースについては時間的に省電力状態にする例えば使われていない期間は省電力モードに切り替えるか、電源供給を止めるか、あるいは空間的に省電力状態にする例えば使われていない部分を省電力モードに切り替えるか電源供給を止めるという動的省電力機構を備える。リソース配分決定モジュール661の構成と動作は、先に説明したリソース配分決定部420の構成と動作と機能的に同様であるが、本実施例では、サーバ側のリソース量の計算に際してCPUリソースとネットワークリソース以下NWリソースと表記の2種を扱う事例を取りあげる。そこで以下では、このリソース配分決定に関する差異部分について詳しく説明する。図17は、本実施例で使用する2つのサービスアプリケーションAP1及びAP2のモードリソース対応表である。これらのサービスアプリはCPUだけでなくNWリソースも必要とするが、それらの使用比率がサービスアプリ間で大きく異なるため、同図のように、両リソースを区別して取り扱う。同図において、各リソースの値は、動画配信サーバが備える全体リソース量を100としたときの相対量で示されている。図17aを参照すると、サービスアプリAP1は5つの動作モード1から5を有し、そのうち動作モード5が通常動作モード、動作モード1が待機時動作モードである。また、通常動作モードで動作するサービスアプリAP1の1タスク1つの実体は、動画配信サーバのCPUリソースの40と、同サーバのNWリソースの25を消費することが示されている。同様に図17bはもう一つのサービスアプリAP2の動作モードとそのときの消費リソース量を示したモードリソース対応表である。これらの図に示した値は、本番サービス開始前にサービスアプリ1タスクをサーバ上で仮実行させ、OS等を用いてリソース消費量を測定することで得、それに基づいて図13abのモードリソース対応表が作成される。図18は本実施例における端末サービス管理テーブル663の具体例を示した図である。本実施例では、後述するリソース配分計算の便を図るため、端末サービス管理テーブルの欄としてCPUリソースNWリソースの2列が追加されている。これらはリソース配分計算過程でのみ使用されるものであり、図18においてはその中身は特に表示されていない。図18aは、動画配信サービス中のある時点19時での端末サービス管理テーブルの内容を示したもので、ユーザU0001及びユーザU0002がいずれも活動中状態であることが端末側からの情報として得られており、サーバ側ではこれらのユーザに対していずれもサービスアプリAP1タスクの実体としてはAP1-1及びAP1-2と表記を動作モード5即ち通常動作モードにて実行中である。図18aはまた、この2ユーザに加え、新たにユーザU0003に対しサービスアプリAP1タスク実体はAP1-3を開始することになった状態を示している。ユーザU0003は活動中との情報を得ているため、目標動作モードは5としているが、図18aの段階ではまだリソース配分計算が完了しておらず、調整済動作モードの値はまだ更新されていない。図18bはサービスアプリAP1-1~AP1-3の間でリソース配分計算が完了したときの状態を示しており、調整済動作モードは目標動作モードと異なり、いずれも4となっている。このリソース配分計算のステップについて、図19を参照しながら以下で具体的に説明する。図19aはリソース配分計算開始直前の状態を示している。AP1-1とAP1-2はいずれも動作モード5で動作しており、サーバ内でのCPU及びNWリソースの消費量の合計は各々80、50である。ここで図19bのようにAP1-3が追加され、これも目標動作モード5であるとする。図9の計算手順のステップS1001及びS1002に従い、図19aのモードリソース対応表を元にCPU及びNWの必要リソース量の合計を求めると各々120、75となる。ここでCPUリソース量が100を超え、不足する見通しであることがわかる図9のステップS1004。そこでリソース削減調整率100÷120=0.83を各リソース量に乗じると図19cとなる。図17aのモードリソース対応表からCPUリソース33、NWリソース21に最も近いものを選ぶと、動作モード4CPUリソース30、NWリソース16がそれに相当する。そこで図19dに示すように、AP1-1~AP1-3の調整済動作モードを4に設定する図9のステップS1008。このとき全体必要リソース量はCPU、NWそれぞれ90及び48となり、サーバリソース量でまかなえるようになったことがわかる。この後、更に状況が変化してサービスアプリAP2-1が追加になった場合のリソース配分計算過程を図20に示す。図17bを参照すると、AP2-1の通常動作モード3ではCPU及びNWリソースを各々20及び70消費し、従って図20aから読み取れるように、サーバ全体では各々140及び145のリソースが必要である。ここではNWリソース量の上限逸脱がCPUリソース量のそれより大きいので、NWリソース側から調整を図る。即ちリソース削減調整率100÷145=0.69を乗じて図20bのようなリソース量に圧縮することを狙い、図17a及びbから最も近いリソース量となる動作モードを選ぶと、AP1に対し動作モード4、AP2に対し動作モード2となる。この状態を図20cに示す。ここで必要NWリソースの合計はサーバ全体のNWリソース量内に収まったが、CPUリソース量の合計は105でまだ上限を5超えている。本実施例ではこのように若干の上限超えを生じることがあるが、これはサーバOS615における規定のリソーススケジューリング動作による自動調整に委ねる。通常これが問題になることはないが、こうしたOS自動調節に委ねる割合を少なくするために、モードリソース対応表図17には多段階の動作モードを登録しておくのがよい。更にユーザ状態が変化した場合の説明を継続する。図21aは2人のユーザが非活動状態となった場合を示している。それらのユーザに対応するAP1-2及びAP1-3の目標動作モードは5から1即ち待機時動作モードとなる。図9のリソース計算手順に沿ってサーバ全体の必要リソース量を求めると、CPUリソース=90、NWリソース=99となり、いずれもサーバ全体リソースに収まる。そこで各アプリの調整済動作モード値はいずれも目標動作モード値と同じとしている。図21aの状態を図20cの状態と比較すると、AP1-2及びAP1-3に配分されていたリソースが減り、逆にAP1-1及びAP2-1に配分されていたリソースが増えていることがわかる。これは、サービスを享受していないと判断されたユーザからサービスを真に享受しているユーザへリソースが再配分され、後者のユーザに対するサービス品質改善につながっている。図21bは更に4人目のユーザが非活動状態となった場合を示しており、AP2-1の目標動作モードが1即ちAP2の待機時動作モードとなっている。同様にリソース計算手順に沿って計算すると、CPUもNWもサーバ全体リソース量に収まるため、各アプリの調整済動作モード値はいずれも目標動作モード値と同じになる。図21bのとき、サーバではCPUリソースのうちの25、NWリソースのうちの61は不要であり、サーバOS615が備える動的省電力機構によりこれらの不要リソース分の電力消費を削減する。これは、サービスを享受していないと判断されたユーザへのサービスのために割くリソースを減らし、サーバ消費電力を削減できたことを意味する。このように、本実施例では、ユーザの携帯端末側から得たコンテキスト情報を元に映像配信サーバ側のリソース配分を調節し、サービスを享受しているユーザに対するサービス品質改善、及び映像配信サーバ側消費電力の削減を実現している。以上各実施の形態及び実施例で説明したように、本発明によれば、ネットワークサービスを享受しているユーザに対して適切なリソース割り当てが可能となる。すなわち、サービス配信を受けている複数のユーザそれぞれの状況をサービス提供サーバ側で把握し、サービスを最終的に利用していないユーザに対して割り当てていたサーバ及びネットワークリソースを、サービスを真に享受したいと希望しているユーザ向けに再配分し、限られたリソースを有効に活用することが可能になる。なお、上述した動画視聴アプリ、端末制御アプリ、動画配信アプリ、サービス制御アプリの各種プログラムは、コンピュータシステムがアクセス可能な様々な種類の記憶媒体に格納することが可能である。また、このプログラムは、通信媒体を介して伝達されることが可能である。ここで、記憶媒体には、例えば、フレキシブルディスク、ハードディスク、磁気ディスク、光磁気ディスク、CD-ROM、DVD、ROMカートリッジ、バッテリバックアップ付きRAMメモリカートリッジ、フラッシュメモリカートリッジ、不揮発性RAMカートリッジ等が含まれる。また、通信媒体には、電話回線等の有線通信媒体、マイクロ波回線等の無線通信媒体等が含まれ、インターネットも含まれる。また、本発明のシステムは多数のコンシューマ端末向けに集中サーバからサービスを提供するサービスシステムに適用できる。例えば、動画配信システム、メッセージ交換システム、サーバクライアント形態をとる音声認識システム、画像認識システム等に適用することができる。なお、本発明は上記実施の形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変形変更することが可能である。本発明の実施の形態としては様々な態様が考えられ、例えば以下のような実施の形態が可能である。1ネットワークサービスの提供を行うサービス提供サーバと、前記ネットワークサービスの提供を受ける複数のサービス実行端末と、を備えるサービス制御システムであって、前記サービス実行端末は、前記サービス提供サーバより提供されるネットワークサービスを実行することで前記ネットワークサービスを端末ユーザに提供するサービス実行手段と、自端末の状態又は自端末周囲の状態を検出する端末状態検出手段と、前記端末状態検出手段における検出結果に基づいて端末ユーザが前記ネットワークサービスを利用しているか否かを判断するサービス利用状況判断手段と、前記サービス利用状況判断手段における判断結果を前記サービス提供サーバに通知するサービス利用状況通知手段と、を具備し、前記サービス提供サーバは、前記サービス実行端末より通知された前記判断結果に基づいて前記サービス実行端末に提供するネットワークサービスに対して配分するリソース量を決定するリソース配分決定手段と、前記リソース配分決定手段で決定されたリソース量に基づいて前記サービス実行端末に提供するネットワークサービスに対してリソースを配分するリソース配分実行手段と、前記リソース配分実行手段により配分されるリソースを用いてネットワークサービスの提供を前記サービス実行端末に対して行うサービス提供手段と、を具備する、サービス制御システム。2サービス提供サーバより提供されるネットワークサービスを実行することで前記ネットワークサービスを端末ユーザに提供するサービス実行手段と、自端末の状態又は自端末周囲の状態を検出する端末状態検出手段と、前記端末状態検出手段における検出結果に基づいて端末ユーザが前記ネットワークサービスを利用しているか否かを判断するサービス利用状況判断手段と、前記サービス利用状況判断手段における判断結果を前記サービス提供サーバに通知するサービス利用状況通知手段と、を具備するサービス実行端末。3前記サービス実行手段は、前記ネットワークサービスを複数の品質レベルで前記端末ユーザに対して提供可能であることを特徴とする、2に記載のサービス実行端末。4前記サービス実行手段が前記ネットワークサービスを所定の基準より低い品質レベルで前記端末ユーザに提供している場合において、前記端末ユーザから発せられる所定の動作を検知するユーザ反応検知手段を更に具備し、前記サービス利用状況通知手段は、前記所定の動作の検知結果を前記サービス提供サーバに通知する、3に記載のサービス実行端末。5前記サービス利用状況通知手段は、提供するネットワークサービスの品質レベルを下げることを示す通知を前記サービス提供サーバより受信し、前記ユーザ反応検知手段は、前記通知が受信された場合に前記端末ユーザが前記ネットワークサービスの品質レベルの低下に対する不満を表す動作を発しているかを判断する、4に記載のサービス実行端末。6前記サービス利用状況判断手段は、前記サービス実行手段が実行しているネットワークサービスの種類及び前記前記端末状態検出手段における前記検出結果に基づいて端末ユーザが前記ネットワークサービスを利用しているかどうかを判断する、2乃至5のいずれか1項に記載のサービス実行端末。7前記端末状態検出手段は、自端末に生じる加速度、自端末の位置、自端末の傾き、自端末周囲の明るさ、の少なくとも1つを前記自端末の状態又は自端末周囲の状態として検出する、2乃至6のいずれか1項に記載のサービス実行端末。8前記サービス実行手段は、動画配信サーバより配信される動画ストリームを前記動画配信サーバより指定されたビットレートで再生する、3又は4に記載のサービス実行端末。9前記端末状態検出手段は、少なくとも自端末周囲の明るさを検出する光センサ及び自端末に生じる加速度を検出する加速度センサを備え、前記サービス利用状況判断手段は、前記サービス実行手段が前記動画配信サーバより配信される動画ストリームを再生している場合であって、前記光センサで検出される光量が所定の基準値より少なく、かつ、前記加速度センサで検出される加速度の値が所定の期間0である場合に、端末ユーザは動画配信サービスを利用していないと判断する、8に記載のサービス実行端末。10前記端末状態検出手段は、少なくとも自端末周囲の明るさを検出する光センサと、自端末に生じる加速度を検出する加速度センサと、自端末の現在位置を検出する位置センサと、を具備し、前記サービス利用状況判断手段は、前記サービス実行手段が対話型メッセージサービスを実行している場合であって、一定期間キー操作又はタッチスクリーン操作がなく、かつ、前記光センサで検出される光量が所定の基準値より少なく、かつ、前記加速度センサ及び位置センサでそれぞれ検出される加速度及び現在位置に変化がある場合に、端末ユーザは前記対話型メッセージサービスを利用していないと判断する、3又は4に記載のサービス実行端末。11端末ユーザの行動特性に関する情報を記憶する記憶手段を更に具備し、前記前記サービス利用状況判断手段は、前記記憶手段に記憶された前記行動特性に関する情報を参照して、前記端末ユーザがネットワークサービスを利用しているか否かを判断する、2乃至10のいずれか1項に記載のサービス実行端末。12前記サービス実行手段は、前記サービス提供サーバより提供されるネットワークサービスを指定された動作モードで実行するアプリケーションタスクである、2乃至11のいずれか1項に記載のサービス実行端末。13複数のサービス実行端末よりそれぞれ通知される各端末ユーザがネットワークサービスを利用しているか否かについての判断結果に基づいて前記複数のサービス実行端末にそれぞれ提供するネットワークサービスに対して配分するリソース量を決定するリソース配分決定手段と、前記リソース配分決定手段で決定されたリソース量に基づいて前記複数のサービス実行端末にそれぞれ提供するネットワークサービスに対してリソースを配分するリソース配分実行手段と、前記リソース配分実行手段により配分されるリソースを用いて前記ネットワークサービスの提供を前記複数のサービス実行端末に対して行うサービス提供手段と、を具備するサービス提供サーバ。14前記サービス提供手段は、前記ネットワークサービスを複数の品質レベルで前記端末ユーザに対して提供可能であり、前記リソース配分決定手段で決定されるリソース量のリソースを用いて実現可能な品質レベルで前記ネットワークサービスの提供を行う、13に記載のサービス提供サーバ。15前記リソース配分決定手段は、前記複数のサービス実行端末に対するネットワークサービスの提供に必要なリソースの総量が、前記ネットワークサービス提供に利用可能なリソースの総量を上回る場合に、前記判断結果に基づいて端末ユーザが利用していないネットワークサービスに対して配分するリソース量を削減する決定を行う、13又は14に記載のサービス提供サーバ。16前記サービス提供手段は、リソース消費量の異なる複数の動作モードを有し、前記複数のサービス実行端末にネットワークサービスを提供するサービスアプリケーションタスクを備え、前記リソース配分決定手段は、前記判断結果に基づいて前記サービスアプリケーションタスクの動作モードを前記複数のサービス実行端末に提供するネットワークサービス毎に決定し、前記リソース配分実行手段は、前記リソース配分決定手段で決定された前記動作モードの指示を前記サービスアプリケーションタスクに対して行い、前記サービスアプリケーションタスクは、前記指示された動作モードでそれぞれ前記ネットワークサービスを前記サービス実行端末に提供する、13に記載のサービス提供サーバ。17前記リソース配分決定手段は、前記サービスアプリケーションタスクの各動作モードが必要とするリソース量を示したモードリソース対応表と前記判断結果とに基づいて、前記複数のサービス実行端末に対するネットワークサービスの提供に必要なリソースの総量が、前記ネットワークサービス提供に利用可能なリソースの総量を超えないように、各サービス実行端末にネットワークサービスを提供するサービスアプリケーションタスクの動作モードを決定する、16に記載のサービス提供サーバ。18前記サービス提供手段は、前記リソース配分実行手段により配分されるリソースに応じた配信ビットレートで前記サービス実行端末に対して動画配信を行う、13乃至17のいずれか1項に記載のサービス提供サーバ。19自端末の状態又は自端末周囲の状態を検出する端末状態検出手段で得られる検出結果に基づいて端末ユーザがネットワークサービスを利用しているか否かを判断するサービス利用状況判断処理と、ネットワークサービスを所定の基準より低い品質レベルで前記端末ユーザに提供している場合において、前記端末ユーザから発せられる所定の動作を検知するユーザ反応検知処理と、前記サービス利用状況判断処理における判断結果及び前記ユーザ反応計地処理における検知結果をそれぞれサービス提供サーバに通知するサービス利用状況通知処理と、を計算機に実行させるネットワークサービス補助プログラム。20複数のサービス実行端末よりそれぞれ通知される各端末ユーザがネットワークサービスを利用しているか否かについての判断結果に基づいて前記複数のサービス実行端末にそれぞれ提供するネットワークサービスに対して配分するリソース量を決定するリソース配分決定処理と、前記リソース配分決定処理で決定されたリソース量に基づいて前記複数のサービス実行端末にそれぞれ提供するネットワークサービスに対してリソースを配分するリソース配分実行処理と、前記リソース配分実行処理により配分されるリソースを用いて前記ネットワークサービスの提供を前記複数のサービス実行端末に対して行うサービス提供処理と、を計算機に実行させるネットワークサービス制御プログラム。21サービス提供サーバより提供されるネットワークサービスを実行することで前記ネットワークサービスを端末ユーザに提供するサービス実行ステップと、自端末の状態又は自端末周囲の状態を検出する端末状態検出ステップと、前記端末状態検出ステップにおける検出結果に基づいて端末ユーザが前記ネットワークサービスを利用しているか否かを判断するサービス利用状況判断ステップと、前記サービス利用状況判断ステップにおける判断結果を前記サービス提供サーバに通知するサービス利用状況通知ステップと、を具備するサービス実行方法。22複数のサービス実行端末よりそれぞれ通知される各端末ユーザがネットワークサービスを利用しているか否かについての判断結果に基づいて前記複数のサービス実行端末にそれぞれ提供するネットワークサービスに対して配分するリソース量を決定するリソース配分決定ステップと、前記リソース配分決定ステップで決定されたリソース量に基づいて前記複数のサービス実行端末にそれぞれ提供するネットワークサービスに対してリソースを配分するリソース配分実行ステップと、前記リソース配分実行ステップにより配分されるリソースを用いて前記ネットワークサービスの提供を前記複数のサービス実行端末に対して行うサービス提供ステップと、を具備するサービス提供方法。