サービス制御システム、サービス提供サーバ、サービス実行端末
【課題】サービスを享受しようとしていないユーザに対するサービス提供のために割かれるサーバ又はネットワークのリソースを削減することが求められていた。
【解決手段】サービス実行端末は、自端末の状態又は自端末周囲の状態を検出する端末状態検出手段と、検出結果に基づいて端末ユーザがネットワークサービスを利用しているか否かを判断するサービス利用状況判断手段と、判断結果をサービス提供サーバに通知するサービス利用状況通知手段と、を具備する。サービス提供サーバは、通知された判断結果に基づいて配分するリソース量を決定するリソース配分決定手段と、リ決定されたリソース量に基づいてリソースを配分するリソース配分実行手段と、配分されるリソースに基づいてネットワークサービスの提供をサービス実行端末に対して行うサービス提供手段と、を具備する。
【解決手段】サービス実行端末は、自端末の状態又は自端末周囲の状態を検出する端末状態検出手段と、検出結果に基づいて端末ユーザがネットワークサービスを利用しているか否かを判断するサービス利用状況判断手段と、判断結果をサービス提供サーバに通知するサービス利用状況通知手段と、を具備する。サービス提供サーバは、通知された判断結果に基づいて配分するリソース量を決定するリソース配分決定手段と、リ決定されたリソース量に基づいてリソースを配分するリソース配分実行手段と、配分されるリソースに基づいてネットワークサービスの提供をサービス実行端末に対して行うサービス提供手段と、を具備する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークサービスを提供するサーバと複数の端末とを含んで構成されるサービス制御システムに関し、特に、リソースの最適配分機能を有するサービス制御システムに関する。
【背景技術】
【０００２】
通信ネットワークを通じてサービスを提供するシステムにおいて、回線状況に合わせた適切な品質レベルのサービスを提供するために、動的リソース制御技術の開発が進められている。
【０００３】
特許文献１には、動画等のストリームを受信する端末において通信パケットのロス率を観測し、パケットロス率がある閾値を超えた場合は、当該端末へのストリーム配信のデータビットレートを低下させるストリーム配信システムが開示されている。当該技術を用いることにより、端末側における通信ネットワークの状況に応じて通信データ量を調整し、通信ネットワークリソースの有効利用を図ることができる。
【０００４】
また、特許文献２には、無線ネットワークで繋がった通信装置からなるシステムにおけるサービス最適化に関する技術が開示されている。当該技術では、各通信端末装置側で測定したネットワーク指標やネットワークアプリケーション動作性能値をネットワークサーバに集めて分析し、通信に用いる符号化方式割り当てやＱｏＳクラス特性を変更することで、通信端末ユーザの体験を改善することを試みる。すなわち、特許文献２の技術は、各端末での通信ネットワーク状況に応じて、通信方式を調整し、端末全体での通信ネットワークリソースの有効利用を図るものである。
【０００５】
また、特許文献３には、所定のユーザが異なる複数のサービスを同時に受けている場合において、これらの複数のサービスを統括的に制御するサービス制御システムが開示されている。当該技術によれば、ネットワークから取得できる様々なコンテキストから各サービスに対して共通要素となる要求特性を導出し、当該要求特性を用いて異なるサービスを比較して統括的に複数のサービスを制御することで、ユーザ志向なサービス制御が可能となる。
【０００６】
また、特許文献４には、物理計算機を複数の論理区画（ＬＰＡＲ）に分割し、各ＬＰＡＲ上で動作する各ＯＳの負荷に対応して、各ＬＰＡＲにリソースを割り当てる仮想計算機システムが開示されている。当該技術では、リソース配分を決めるにあたってＯＳの負荷だけではなく、ＯＳ上で動作するワークロード(プログラム)の情報も利用してリソースを配分することで、最適なリソース割り当てが可能となる。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００８−１１１７７号公報
【特許文献２】特表２００８−５３９６６３号公報
【特許文献３】特開２００５−１００３２０号公報
【特許文献４】特開２００７−２００３４６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
通信事業者により定額制やそれに近い通信料金プランが提供され、また、端末装置の高機能化と大画面化が進むにつれ、ユーザはいくつものアプリケーションを端末上で起動したまま放置する傾向にある。例えば、動画再生アプリケーションを起動したままユーザが端末のそばを離れたり、端末を鞄にしまったりすると、ユーザは既にそのサービスを享受しなくなっているが、サーバ、ネットワーク、及び端末のリソースは消費され続けている。これは電力消費の観点および通信コストの観点で問題となる。
【０００９】
また、このような無駄なリソース消費が発生することにより、リソース逼迫時に、真にサービスを受けたいと希望しているユーザに対して十分なリソースを割けないという課題が生じている。
【００１０】
このような課題は、通信事業者のサービス提供プランの変化や無線通信規格の高速化などを契機としてここ近年で新たに生じた課題であり、上記従来の技術ではこのような課題に適切に対応することができなかった。
【００１１】
すなわち、特許文献１や特許文献２の技術では、通信品質に応じたリソース制御は行えるものの、ユーザに利用されないサービスに対しても、サーバ及びネットワークのリソースを消費してしまうという課題を解決することはできない。また、特許文献３の技術は、特定のユーザが複数の異なるサービスを同時利用している場合に、これらの各サービスに対するユーザの要求特性に応じた統計的制御は可能となるものの、やはり、複数ユーザが限られたリソースを共用している場合に、ユーザに利用されないサービスにリソースが消費されるという課題を解決することはできない。また、特許文献４の技術を持ってしても、仮想計算機のリソース配分を最適化できるに留まり、上記の課題を解決することはできなかった。
【００１２】
本発明は上記課題を鑑み、サービスを享受しようとしていないユーザに対するサービス提供のために割かれるサーバ又はネットワークのリソースを削減することを目的とする。
【課題を解決するための手段】
【００１３】
本発明のサービス制御システムは、ネットワークサービスの提供を行うサービス提供サーバと、前記ネットワークサービスの提供を受ける複数のサービス実行端末と、を備えるサービス制御システムであって、前記サービス実行端末は、前記サービス提供サーバより提供されるネットワークサービスを実行することで前記ネットワークサービスを端末ユーザに提供するサービス実行手段と、自端末の状態又は自端末周囲の状態を検出する端末状態検出手段と、前記端末状態検出手段における検出結果に基づいて前記端末ユーザが前記ネットワークサービスを利用しているか否かを判断するサービス利用状況判断手段と、前記サービス利用状況判断手段における判断結果を前記サービス提供サーバに通知するサービス利用状況通知手段と、を具備し、前記サービス提供サーバは、前記サービス実行端末より通知された前記判断結果に基づいて前記サービス実行端末に提供するネットワークサービスに対して配分するリソース量を決定するリソース配分決定手段と、前記リソース配分決定手段で決定されたリソース量に基づいて前記サービス実行端末に提供するネットワークサービスに対してリソースを配分するリソース配分実行手段と、前記リソース配分実行手段により配分されるリソースを用いてネットワークサービスの提供を前記サービス実行端末に対して行うサービス提供手段と、を具備する。
【００１４】
また、本発明のサービス実行端末は、サービス提供サーバより提供されるネットワークサービスを実行することで前記ネットワークサービスを端末ユーザに提供するサービス実行手段と、自端末の状態又は自端末周囲の状態を検出する端末状態検出手段と、前記端末状態検出手段における検出結果に基づいて端末ユーザが前記ネットワークサービスを利用しているか否かを判断するサービス利用状況判断手段と、前記サービス利用状況判断手段における判断結果を前記サービス提供サーバに通知するサービス利用状況通知手段と、 を具備する。
【００１５】
また、本発明のサービス提供サーバは、複数のサービス実行端末よりそれぞれ通知される各端末ユーザがネットワークサービスを利用しているか否かについての判断結果に基づいて前記複数のサービス実行端末にそれぞれ提供するネットワークサービスに対して配分するリソース量を決定するリソース配分決定手段と、前記リソース配分決定手段で決定されたリソース量に基づいて前記複数のサービス実行端末にそれぞれ提供するネットワークサービスに対してリソースを配分するリソース配分実行手段と、前記リソース配分実行手段により配分されるリソースを用いて前記ネットワークサービスの提供を前記複数のサービス実行端末に対して行うサービス提供手段と、を具備する。
【発明の効果】
【００１６】
本発明によれば、サービスを享受しようとしていないユーザに対するサービス提供のために割かれるサーバ又はネットワークのリソースを削減することが可能となる。
【図面の簡単な説明】
【００１７】
【図１】本発明の全体構成を示すシステム図である。
【図２】実施の形態１に係る端末及びサーバの具体的構成を示すブロック図である。
【図３】実施の形態２に係る端末及びサーバの具体的構成を示すブロック図である。
【図４】端末からサーバに送られる端末コンテキストメッセージの構造を示す図である。
【図５】サーバから端末に送られるリソース配分決定メッセージの構造を示す図である。
【図６】実施の形態２に係るリソース配分決定部の内部構成を示すプロック図である。
【図７】実施の形態２に係る端末サービス管理テーブル内のテーブルエントリの構造を示す図である。
【図８】実施の形態２に係るモードリソース対応表の構造を示す図である。
【図９】実施の形態２に係るリソース計算手順を示すフローチャート図である。
【図１０】実施の形態２に係るサービス実行端末のサービス享受状態判断処理の流れを示すフローチャート図である。
【図１１】実施の形態２に係るサービス実行端末のユーザ反応調査モード変更処理の流れを示すフローチャート図である。
【図１２】実施の形態２に係るサービス実行端末の不満動作検出処理の流れを示すフローチャート図である。
【図１３】実施の形態２に係るサービス提供サーバの動作を示すフローチャート図である。
【図１４】実施の形態２に係る別のリソース計算手順を示すフローチャート図である。
【図１５】本発明の実施例における端末の具体的構成を示すブロック図である。
【図１６】本発明の実施例におけるサーバの具体的構成を示すブロック図である。
【図１７】本発明の実施例における、サービスアプリケーションのモードリソース対応表である。
【図１８】本発明の実施例における端末サービス管理テーブルの構成と具体内容例を示す図である。
【図１９】本発明の実施例におけるリソース配分計算過程を説明する図である。
【図２０】本発明の実施例におけるリソース配分計算過程を説明する図である。
【図２１】本発明の実施例におけるリソース配分計算過程を説明する図である。
【発明を実施するための形態】
【００１８】
本発明に係るネットワークサービス制御システムは、限られたリソースを用いてネットワークサービスを複数の端末ユーザに提供するシステムであって、実際にネットワークサービスを享受している端末ユーザに対して適切にリソースを割り当てることを可能とするシステムである。
【００１９】
図１は、本発明に係るネットワークサービス制御システムの全体構成を示すシステム図である。本発明に係るネットワークサービス制御システムは、ネットワークサービスを提供するサービス提供サーバ２０と、ネットワークサービスを利用する端末群１０と、これらを相互に接続する有線ないし無線のネットワーク３０と、を含んで構成される。以下、本発明の各実施の形態について図面を参照して詳細に説明する。
（実施の形態１）
【００２０】
図２は、本実施の形態１にかかるネットワークサービス制御システムを構成する端末１００とサービス提供サーバ２００の具体的構成を示すブロック図である。以下、各部の機能について詳細に説明する。
【００２１】
まず、端末１００の構成について説明する。端末１００は、サービス実行部１１０と、端末状態検出部１２０と、サービス利用状況判断部１３０と、サービス利用状況通知部１４０と、ネットワークインタフェース（ＮＷＩ／Ｆ）１５０と、を備える。
【００２２】
サービス実行部１１０は、サービス提供サーバ２００より提供されるネットワークサービスを実行する。具体的には、端末１００が具備するＣＰＵ（Central Processing Unit）及びＯＳ（Operating
System）上で動作する端末側アプリケーションが、サービス提供サーバ２００より提供されるネットワークサービスを実行し、当該ネットワークサービスを端末ユーザに提供する。
【００２３】
端末状態検出部１２０は、自端末の状態をセンシングすることで端末状態を検出する。端末状態検出部１２０は、具体的には、加速度センサ、傾きセンサ、光センサなどで構成され、当該センサで得られる端末状態についての検出結果をサービス利用状況判断部１３０に出力する。なお、ここでいう端末状態には、光センサで検出される自端末周囲の明るさ等、自端末周囲の状態も含まれるものとする。
【００２４】
サービス利用状況判断部１３０は、端末状態検出部１２０より出力された検出結果を基に、端末ユーザのサービス利用状況を判断する。具体的には、サービス利用状況判断部１３０は、端末状態検出部１２０から入力した端末状態の検出結果に基づいてユーザの動作状態などユーザ状況を把握し、所定のアルゴリズムに従って、端末ユーザが自端末１００を通じてネットワークサービスを享受しているか否か、すなわち、ネットワークサービスを利用しているか否かを判断する。サービス利用状況判断部１３０は、ユーザがネットワークサービスを利用しているか否かについての判断結果をコンテキスト情報としてサービス利用状況通知部１４０に出力する。
【００２５】
サービス利用状況通知部１４０は、サービス利用状況判断部１３０より入力した端末ユーザがネットワークサービスを利用しているか否かの判断結果を、必要に応じてサービス提供サーバ２００に通知する。例えば、サービス利用状況通知部１４０は、サービス利用状況判断部１３０から入力した上記端末ユーザがネットワークサービスを利用しているか否かの判断結果に変化が生じている場合は、当該判断結果を含むコンテキスト情報をサービス提供サーバ２００に通知する。
【００２６】
ネットワークインタフェース１５０は、自端末１００がネットワーク３０を介してサービス提供サーバと通信するための通信インタフェースである。端末１００は、ネットワークインタフェース１５０を介してネットワークサービスの提供を受け、また、コンテキスト情報の送信等を行う。
【００２７】
次に、サービス提供サーバ２００の構成について説明する。サービス提供サーバ２００は、サービス提供部２１０と、リソース配分決定部２２０と、リソース配分実行部２３０と、ネットワークインタフェース（ＮＷＩ／Ｆ）２４０と、を備える。
【００２８】
サービス提供部２１０は、リソース配分実行部２３０におけるリソース配分制御に従い、ネットワークインタフェース２４０を介して各端末にネットワークサービスの提供を行う。
【００２９】
リソース配分決定部２２０は、ネットワークサービスを利用している複数の端末から通知される端末ユーザがネットワークサービスを利用しているか否かの判断結果を、ネットワークインタフェース２４０を介して受信し、当該判断結果に基づいてリソースの配分を決定する。
【００３０】
具体的には、リソース配分決定部２２０は、各端末から通知される上記判断結果を含むコンテキスト情報を収集し、サービス享受していない（ネットワークサービスを利用していない）ユーザ向けのネットワークサービスに対して配分しているリソース量を減らし、サービス享受している（ネットワークサービスを利用している）ユーザ向けのネットワークサービスに対して配分しているリソース量を相対的に増やす決定を行う。なお、ここでいうリソースとは、サービス提供サーバのＣＰＵやＯＳといったサーバ内リソースの他、サービスを利用する端末とサービス提供サーバ間の無線通信帯域のリソースなど、ネットワークサービス提供に必要となるリソースを言う。従って、ネットワークサービスに配分されるリソース量が減らされると、一般的に当該サービスの品質レベルが下がることになる。リソース配分決定部２２０は、リソース配分決定結果をリソース配分実行部２３０に通知し、リソース配分の指示を行う。
【００３１】
リソース配分実行部２３０は、リソース配分決定部２２０から指示されたリソース配分に従って、サービス提供部２１０が各端末にそれぞれ提供するネットワークサービスに対してＣＰＵやＯＳと言ったリソースを配分する。具体的には、リソース配分実行部２３０は、リソース配分決定部２２０から指示されたリソース配分に従って、サービス提供部２１０におけるネットワークサービス提供で消費されるリソースの具体的なリソース配分操作を行う。例えば、リソース配分決定部２２０よりサービス享受していないユーザ向けサービスに配分しているリソース量を減らす指示を受けた場合は、リソース配分実行部２３０は、当該サービスに割り当てているリソース量を減らす制御を行う。サービス提供部２１０は、このようにして配分されたリソースを使用して各端末にネットワークサービスを提供する。
【００３２】
以上説明したように、本実施の形態１におけるネットワークサービス制御システムは、ネットワークサービスの提供を行うサービス提供サーバ及びネットワークサービスの提供を受ける複数のサービス実行端末を含んで構成される。そして、サービス実行端末は、サービス提供サーバより提供されるネットワークサービスを実行することでネットワークサービスを端末ユーザに提供するサービス実行手段と、自端末の状態又は自端末周囲の状態を検出する端末状態検出手段と、端末状態検出手段における検出結果に基づいて端末ユーザがネットワークサービスを利用しているか否か、すなわちネットワークサービスを享受しているか否かを判断するサービス利用状況判断手段と、サービス利用状況判断手段における判断結果をサービス提供サーバに通知するサービス利用状況通知手段と、を具備する。一方、サービス提供サーバは、サービス利用端末より通知された判断結果に基づいてリソース配分を決定するリソース配分決定手段と、リソース配分決定手段で決定されたリソース配分に従ってサービス利用端末に提供するネットワークサービスに対してリソースを配分するリソース配分実行手段と、リソース配分実行手段により配分されるリソースを用いてネットワークサービスの提供をサービス実行端末に対して行うサービス提供手段と、を具備する。
【００３３】
このような構成とすることで、各端末は、自ユーザの状況を把握してネットワークサービスを享受しているかどうかの判断を行い、判断結果をサーバ側に通知する。限られたリソースを各端末に配分しながらサービス提供を行うサービス提供サーバは、これらの通知に基づいて、リソースの配分割合を操作し、ネットワークサービスを享受していないユーザに対するリソース割り当てを低下させる一方、ネットワークサービスを享受しているユーザに対して適切なリソース割り当てを行う。
【００３４】
従って、例えば、端末ユーザがネットワークサービスを実行しているアプリケーションを端末上で起動したまま放置し、リソースの消費が発生する場合においても、サーバ側でこのようなユーザに対するリソース配分を下げ、空いたリソースを真にサービスを享受している他のユーザに対して適切に割り当てることが可能となる。
【００３５】
また、このような構成とすることで、無駄なリソース消費を抑えることが可能となるため、サーバ及び端末でそれぞれ消費される電力を削減することができるとともに、ネットワークにおける通信コストの削減も可能となる。
【００３６】
（実施の形態２）
本実施の形態２に係るネットワークサービス制御システムは、実施の形態１に係るネットワークサービス制御システムに加えて、リソース調整に起因して発せられたユーザの不満動作を捉え、リソースの再配分を行う構成を更に備える。以下、本実施の形態２に係るネットワークサービス制御システムについて図面を用いて説明する。
【００３７】
図３は、本実施の形態２に係るネットワークサービス制御システムの具体的構成を示す図である。ネットワークサービス制御システムは、ネットワークサービスの提供を受ける複数の端末３００と、ネットワークサービスの提供を行うサービス提供サーバ４００と含んで構成される。
【００３８】
まず、端末３００の構成について説明する。端末３００は、ＣＰＵ３１０と、センサ群３２０と、コンテキスト認識部３３０と、端末情報収集制御部３４０と、ネットワークインタフェース（ＮＷＩ／Ｆ）３５０と、ユーザ反応検知部３６０と、端末側アプリケーション群３７０と、を備える。
【００３９】
ここで、コンテキスト認識部３３０、ユーザ反応検知部３６０、端末情報収集制御部３４０、端末側アプリケーション群３７０は、端末ＣＰＵ３１０上で動作するソフトウェアを用いて実現することが可能である。これらのソフトウェア動作には通常、主記憶メモリ、不揮発メモリ（Ｆｌａｓｈメモリ等）、ＯＳ等が必要になるが、これらはコンピュータシステム一般に用いられるものであり、ここではあらためて図示しないが、端末３００は当然に備えているものである。
【００４０】
なお、ＣＰＵ３１０上で動作する端末アプリケーション群３７０が、図２のサービス実行部１１０に対応する。また、センサ群３２０、コンテキスト認識部３３０、端末情報収集制御部３４０、ＮＷＩ／Ｆ３５０は、それぞれ図２の端末状態検出部１２０、サービス利用状況判断部１３０、サービス利用状況通知部１４０、ＮＷＩ／Ｆ１５０に対応している。以下、各部の機能について詳細に説明する。但し、図２で説明した部分については一部説明を省略する。
【００４１】
ＣＰＵ３１０は、ネットワークサービスに対応するアプリケーションである端末側アプリケーションを実行することで、サーバより提供されるネットワークサービスを実行し、当該サービスをユーザに提供する。
【００４２】
センサ群３２０は、複数のセンサで構成され、当該センサを用いてセンシングを行い、自端末の状態又は自端末周囲の状態を検出する。センサ群３２０は、具体的には、ＧＰＳを利用して自端末の現在位置を検出する位置センサ、自端末の加速度を検出する加速度センサ、自端末の傾きを検出する傾きセンサ、自端末周囲の明るさを検出する光センサ等の各種センサを一つ又は複数組み合わせて構成される。なお、センサ群３２０を構成するセンサは上記センサに限定されるものではなく、ユーザが自端末に触れていることを検出する触覚センサの他、端末周囲を撮影する端末内蔵カメラ、端末周囲の音声を検出するマイクなども合わせてセンサとして利用することができる。センサ群３２０を構成するこれら各センサにおける端末状態の検出結果は、コンテキスト認識部３３０及びユーザ反応検知部３６０に送られる。
【００４３】
コンテキスト認識部３３０は、前記センサ群３２０から受け取った検出結果に基づいてユーザの状況を把握する。具体的には、コンテキスト認識部３３０は、センサ群３２０を使用してユーザの振る舞いや端末の状況を推測し、ユーザが自端末を通じてサービスを享受している状態であるか否かを判断する。コンテキスト認識部３３０は、当該判断結果をコンテキスト情報として端末情報収集制御部３４０に送る。
【００４４】
端末情報収集制御部３４０は、コンテキスト認識部３３０及びユーザ反応検知部３６０を制御して端末側の情報収集を行う。端末情報収集制御部３４０は、コンテキスト認識部３３０から得たコンテキスト情報を一時蓄積し、ユーザ状態が変化したタイミングで、当該コンテキスト情報とユーザＩＤとをあわせて端末コンテキストメッセージを作成する。端末情報収集制御部３４０は、当該端末コンテキストメッセージをネットワークインタフェース３５０を介してサービス提供サーバ４００へ送信する。
【００４５】
図４に端末コンテキストメッセージ７１０の一例を示す。端末コンテキストメッセージ７１０は、ユーザＩＤ７１１と、ユーザ状態（コンテキスト情報）７１２と、状態変化時刻７１３と、を含む。ここで、ユーザＩＤ７１１には、サービス提供サーバ４００が各端末のユーザにユニークに付与している識別子が設定される。当該ユーザＩＤは通常、ユーザがサービス提供者にサービス提供を申し込む際にサービス事業者が割り当てるものである。ユーザ状態７１２部分には、コンテキスト認識部３３０より送られたコンテキスト情報が格納される。具体的には、ユーザ状態７１２部分には、「活動中」あるいは「非活動中」の値が設定され、それぞれ「ユーザが当該サービスを享受している」「していない」に対応している。また、状態変化時刻７１３には、端末１００が内蔵する時計が刻む日付及び時刻の現在値が、ユーザ状態が変化した時刻として設定される。
【００４６】
また、端末情報収集制御部３４０は、ユーザ反応検知部３６０から、ユーザからの不満動作が認識されたことを示す結果が送られた場合は、当該結果をコンテキスト情報として端末コンテキストメッセージを作成し、サービス提供サーバ４００へ送信する。この場合の端末コンテキストメッセージ内のユーザ状態７１２には、「活動中」の値が記されている。
【００４７】
また、端末情報収集制御部３４０は、後述するリソース配分決定メッセージをサービス提供サーバ４００より受け取った場合は、当該メッセージで示される内容に従って、ユーザ反応検知部３６０に対してユーザが不満動作（反論動作）を行っているかの認識処理の開始を指示する。
【００４８】
ネットワークインタフェース３５０は、端末３００がネットワーク３０を介してサービス提供サーバ４００と通信するための通信インタフェースである。
【００４９】
ユーザ反応検知部３６０は、センサ群３２０を構成する各センサの一部又は全部と接続されており、当該センサ群から入力した端末状態等の検出結果に基づいて、ユーザが特定の反応を行っているかを認識する処理を行う。
【００５０】
具体的には、ユーザ反応検知部３６０は、「ユーザ反応調査中」及び「ユーザ反応調査停止中」の２つの動作状態（ユーザ反応調査モード）を持ち、端末情報収集制御部３４０からの制御に従ってこれらの動作状態を切り替える。すなわち、ユーザ反応検知部３６０は、端末情報収集制御部３４０から「ユーザ反応調査の停止」を指示されると「ユーザ反応調査停止中」状態に遷移し、「ユーザ反応調査の開始」を指示されると「ユーザ反応調査中」状態に遷移する。
【００５１】
ユーザ反応検知部３６０は、その動作状態が「ユーザ反応調査中」である間、ユーザが不満動作（反論動作）を行っているかの認識処理を継続して行う。すなわち、ユーザ反応検知部３６０は、ネットワークサービスの品質レベルの低下に対するユーザの不満動作、反論動作を認識する。ユーザ反応検知部３６０は、これらの不満動作を捉えたタイミングで、「ユーザは当該サービスを享受している」ことを示す情報を端末情報収集制御部３４０に送る。
【００５２】
端末側アプリケーション群３７０は、サービス提供サーバ４００より提供される各種ネットワークサービスに対応したソフトウェアであり、ＣＰＵ３１０及びＯＳ上で動作する。端末側アプリケーション群３７０は、ネットワークサービスを複数の品質レベルで前記端末ユーザに対して提供可能であり、サービス提供サーバが行うリソース制御に基づく品質レベルで提供されるネットワークサービスを実行し、ネットワークサービスを端末ユーザに提供する。
【００５３】
また、端末側アプリケーション群３７０は、ユーザからの入力等をトリガーとしてネットワークサービスの開始を要求するネットワークサービス開始要求メッセージを、ネットワークインタフェース３５０を介してサービス提供サーバ４００に送信する。なお、当該ネットワークサービス開始要求メッセージには、ユーザＩＤ、現在の時刻、要求するネットワークサービスの内容を指定する情報等が含まれる。当該メッセージを受け取ったサービス提供サーバ４００は、当該端末ユーザに対するネットワークサービスの提供を開始する。その後、端末側アプリケーションがサービス提供サーバより提供されるネットワークサービスを実行することにより、当該ネットワークサービスがユーザに提供される。
【００５４】
次に、サービス提供サーバ４００の構成について説明する。サービス提供サーバ４００は、１つ以上のＣＰＵ４１０と、ＯＳ４１５と、リソース配分決定部４２０と、リソース配分実行部４３０と、ネットワークインタフェース（ＮＷＩ／Ｆ）４４０と、サービスアプリケーション群４５０と、を備える。
【００５５】
端末３００と同様、これらの構成要素の一部はソフトウェアとして実現されることが通例であり、サービス提供サーバ４００はそのために必要な主記憶メモリ、不揮発メモリ等を当然に備える。
【００５６】
なお、当該ＣＰＵ４１０及びＯＳ４１５上で動作するサービスアプリケーション群４５０が、図２のサービス提供部２１０に対応する。また、リソース配分決定部４２０及びリソース配分実行部４３０が、それぞれ図２のリソース配分決定部２２０及びリソース配分実行部２３０に対応する。
【００５７】
ＣＰＵ４１０は、サービスアプリケーション群４５０を実行することで、各ユーザより要求されているネットワークサービスを提供する。
【００５８】
ＯＳ４１５は、ＣＰＵ４１０上で動作し、サービスアプリケーション群４５０のタスク管理等を行う。
【００５９】
リソース配分決定部４２０は、各端末から送信されたコンテキスト情報に基づいて各端末へのリソース配分を決定する。すなわち、リソース配分決定部４２０は、各端末からのコンテキスト情報を収集し、サービス享受していないユーザ向けサービスに配分しているリソース量を減らし、サービス享受しているユーザ向けサービスに配分しているリソース量を相対的に増やす決定を行う。リソース配分決定部４２０は、決定したリソース配分決定結果をリソース配分実行部４３０に通知する。また、リソース配分決定部４２０は、前記リソース配分決定結果を、リソース配分決定メッセージとして端末３００に送信する。
【００６０】
図５は、リソース配分決定メッセージ７２０の一例を示している。リソース配分決定メッセージ７２０は、ユーザＩＤ７２１とサーバ側リソース配分決定結果７２２とが含まれる。ここで、ユーザＩＤ７２１は、各ユーザを識別するＩＤであり、サーバ側リソース配分決定結果７２２は、後述するリソース配分決定処理に基づいて決定されたリソース配分の結果を示している。具体的には、サーバ側リソース配分決定結果７２２には、ユーザがサービスを享受しているとして通常の品質レベルに対応するリソース量のリソースが配分されていることを示す「活動中」又は、ユーザがサービスを享受していないとして所定の基準値以下の品質レベルに対応するリソース量のリソースが配分されていることを示す「非活動中」のどちらかの情報が含まれている。サーバ側リソース配分決定結果７２２に「非活動中」の情報が含まれるリソース配分決定メッセージ７２０は、提供するネットワークサービスの品質レベルを下げることを示す通知となる。
【００６１】
リソース配分実行部４３０は、リソース配分決定部４２０より指示されたリソース配分に従ってサーバＣＰＵ４１０、ＯＳ４１５及びサービスアプリケーション群４５０に対する具体的なリソース配分操作を行う。具体的には、リソース配分実行部４３０は、各サービスアプリケーション群４５０やＯＳ４１５に指示して、リソース配分決定部４２０より指示された動作モードでアプリケーションを動作させる。ここでサービスアプリケーションだけでなくＯＳに対しても指示を出すのは、ＣＰＵ優先度、メモリ割り当て、ネットワーク帯域割り当て等において、アプリケーション単独では希望するリソース配分が十分行えない場合に、ＯＳ側からもリソース配分調整を行うためである。
【００６２】
また、リソース配分計算の都合上、全アプリケーションが要求するリソース量の総和がシステム全体リソース量を超えてしまっている場合は、最終調整手段としてＯＳ４１５が備える規定のリソース配分動作に委ねる。即ち、ＯＳ４１５が各アプリケーションタスクに対するリソース配分をベストエフォートで自動調整する。
【００６３】
ネットワークインタフェース４４０は、自サーバ４００がネットワーク３０を介して複数の端末と通信するための通信インタフェースである。
【００６４】
サービスアプリケーション群４５０は、リソース配分実行部４３０により配分されたリソースを用いてサーバ側でネットワークサービスを実行し、ネットワークインタフェース４４０を介して当該ネットワークサービスを各端末に提供する。
【００６５】
次に、リソース配分決定部４２０の具体的構成及びリソース配分決定動作について説明する。図６は、リソース配分決定部４２０の具体的構成を示すブロック図である。リソース配分決定部４２０は、全端末情報管理部４２１と、端末サービス管理テーブル４２２と、端末配分リソース計算部４２３と、タイマ４２４と、モードリソース対応表４２５と、を備える。
【００６６】
全端末情報管理部４２１は、サービス提供先の端末群の現在状況を管理する。具体的には、全端末情報管理部４２１は、各端末から送られてきたネットワークサービス開始要求メッセージや端末コンテキストメッセージをネットワークインタフェース４４０を介して受け取り、端末サービス管理テーブル４２２内にエントリを新規追加ないし既存エントリの更新を行う。
【００６７】
ここで、端末サービス管理テーブル４２２は、各端末ユーザの状態及びサービスレベルの方針が記録されたレコード集合体である。図７に端末サービス管理テーブル４２２の一例を示す。端末サービス管理テーブル４２２には、ユーザに固有に割り当てられたユーザＩＤ４２２１、ユーザの現在の状態を示すユーザ状態４２２２、当該ユーザ向けにサービスを提供しているサービスアプリケーションを示すサービスアプリ識別子４２２３、当該ユーザのユーザ状態が変化した時刻を示す状態変化時刻４２２４、及びサービスアプリケーションの動作モードに関する２種の値即ち目標動作モード４２２５と調整済動作モード４２２６、の各フィールドからなるレコードの集合体が記憶される。
【００６８】
ここで、動作モードとは、異なるいくつかの提供サービスレベルに対し、あるサービスアプリケーションがとる動作の形態の集合である。異なる動作モードでは、サービスレベル（サービスの品質レベル）が異なるため、サービス提供に必要となるリソース消費量も異なる。
【００６９】
一例を挙げると、提供するネットワークサービスが動画配信サービスであれば、アプリケーションは一般に配信ビットレートや解像度、ノイズ低減や色調改善処理の実施程度等をそれぞれ何段階かとることができるが、これらのうち当該サービス実現に対し妥当な組み合わせを当該アプリケーションの動作モードと呼ぶ。
【００７０】
端末サービス管理テーブル４２２に含まれる目標動作モードは端末ごとのサービスレベルの希望値を表すものであり、システム全体リソースが限定される中では必ずしもそれらの希望がすべてかなえられるわけではない。それに対し調整済動作モードはシステム全体リソース量に収まるように各端末サービス間で調整がなされた後のサービスレベルの値である。
【００７１】
モードリソース対応表４２５は、サービスアプリケーション各々の動作モードと必要リソース量との関係を記憶した管理テーブルである。アプリケーションに指示して動作モードを変更すると、当該アプリケーションが使用するリソース（例えばＣＰＵ時間やネットワーク帯域等）の量も変化するのが通例である。システム設計者はサービス運用に先立ち、設計情報及び実システム上での評価を通じて、各動作モードでの動作において当該アプリケーションが使用するリソース量を測定する。モードリソース対応表４２５には、その結果が表にして記載されている。
【００７２】
あるアプリケーションに対する動作モードは一般に複数あるが、そのうち、アプリケーションの通常動作、言い換えれば、設計されたサービスを十分に提供できる動作モードを、通常動作モードと呼ぶ。逆に、最小限の動作、言い換えれば、ユーザにサービスを享受する様子がみられない場合にアプリケーションがとるべき動作モードを、待機時動作モードと呼ぶ。動作モードの集合はサービス運用開始に先立ち、システム設計時にシステム設計者が選定するが、それらのうち、最も多くのリソースを必要とするものが通常動作モード、最もリソースが少なくて済むものが待機時動作モードとなる。
【００７３】
図８にモードリソース対応表の一例を示す。この例ではアプリケーション１において動作モードは５つあり、そのうち動作モード５が通常動作モード（図８にて"ａｃｔｉｖｅ"と表示）、動作モード１が待機時動作モード（"ｉｎａｃｔｉｖｅ"と表示）である。
【００７４】
全端末情報管理部４２１は、端末コンテキストメッセージを新たに受け取ると端末サービス管理テーブル４２２に新規追加又は更新するエントリの各フィールドに次のように値を設定する。全端末情報管理部４２１は、端末コンテキストメッセージに含まれるユーザＩＤ、ユーザ状態、状態変化時刻の値をそれぞれエントリ内のユーザＩＤ、ユーザ状態、状態変化時刻のフィールドに記録する。また、全端末情報管理部４２１は、当該端末に対するサービスを提供しているアプリケーションの識別子をエントリ内のサービスアプリのフィールドに記憶する。次に、全端末情報管理部４２１は、端末コンテキストメッセージに含まれるユーザ状態７１２が「活動中」であれば当該サービスアプリケーションの通常動作モードの値、ユーザ状態７１２が「非活動中」であれば当該サービスアプリケーションの待機時動作モードの値、をそれぞれエントリ内の目標動作モードのフィールドに記録する。なお、調整済動作モードは、リソース調整が行われた後の動作モードの値が記憶されるフィールドであり、後述する端末配分リソース計算部４２３にて値が設定される。
【００７５】
タイマ４２４は、指示されたタイミングでタイマ割込み通知を端末配分リソース計算部４２３に出す。タイマ４２４は予め、サービスレベルの再計算をするのに適した間隔でタイマ割込み通知を発行し続けるよう指示される。この適した間隔とは、ＯＳ４１５がその上のアプリケーションタスクをスケジューリングする時間間隔よりも十分長く、端末ユーザがサービスに対して人間的に知覚し、反応する時間よりも長い時間間隔であり、例えば数秒ないし数十秒程度の範囲から選定するように設定されることが好ましい。
【００７６】
端末配分リソース計算部４２３は、端末サービス管理テーブル４２２を読み込み、各端末に対するリソース配分量を再計算する。具体的には、全端末情報管理部４２１が端末サービス管理テーブル４２２のエントリを追加ないし更新したタイミング、あるいはタイマ４２４からタイマ割込み通知されたタイミングで、後述の手順で各端末向けサービスアプリケーションに対する調整済動作モードを計算する。端末配分リソース計算部４２３は、計算した調整済み動作モードの値を端末サービス管理テーブル４２２の各エントリ内の当該フィールドに設定する。また、端末配分リソース計算部４２３は、端末サービス管理テーブル４２２の各エントリの調整済動作モード４２２６の値をリソース配分実行部４３０に伝える。リソース配分実行部４３０は、当該通知される調整済動作モードの値に従ってリソース配分を実行する。
【００７７】
図９は、端末配分リソース計算部４２３における調整済動作モードの計算手順を示すフローチャートである。
【００７８】
端末配分リソース計算部４２３は、端末サービス管理テーブル４２２内の各エントリのサービスアプリ４２２３の値（以下、ＡＰｉと称す）と目標動作モード４２２５の値（以下、ＭＰｉと称す）をそれぞれ読み取る（ステップＳ１００１）。
【００７９】
次に、端末配分リソース計算部４２３は、端末サービス管理テーブル４２２内の全エントリに対する目標動作モードＭＴｉに必要なリソース量の総和Ｒｔを求める（ステップＳ１００２）。具体的には、端末配分リソース計算部４２３は、ステップＳ１００１で読み取った各端末向けサービスを実行するためのアプリケーションである上記ＡＰｉのモードリソース対応表（図８）を参照し、各エントリの目標動作モードＭＴｉに必要なリソース量Ｒｉを算出する。そして、端末配分リソース計算部４２３は、当該算出処理を全エントリに対して行うことで総和Ｒｔを求める。
【００８０】
次に、端末配分リソース計算部４２３は、リソース配分実行部４３０に問い合わせ、現時点でサーバにて利用可能なリソース量Ｒａを得る（ステップＳ１００３）。
【００８１】
端末配分リソース計算部４２３は、ステップＳ１００２で求めたＲｔの値とステップＳ１００３で得たＲａの値とを比較する（ステップＳ１００４）。
【００８２】
ステップ１００４の比較処理の結果、Ｒｔ≦Ｒａであれば、現時点では全サービス提供に対しシステム全体リソースは足りていることになる。従って、端末配分リソース計算部４２３は、各アプリケーションの目標動作モードの値ＭＰｉをそのまま各アプリケーションの調整済動作モードの値に設定する（ステップＳ１００５）。即ち、端末配分リソース計算部４２３は、端末サービス管理テーブル４２２内の各エントリに対し、目標動作モード４２２５の値を同エントリ内の調整済動作モード４２２６にそのまま設定し、リソース配分計算処理を終了する。
【００８３】
他方、ステップ１００４の比較処理の結果、Ｒｔ＞Ｒａの場合は、現時点では全サービス提供に対しシステム全体リソースは足りていないことを意味する。そこで、端末配分リソース計算部４２３は、サービス提供に必要となるリソースの総和がサーバにて利用可能なリソース量Ｒａ内に収まるように、動作モードの調整を行う。具体的には、端末配分リソース計算部４２３は、第１にリソース削減調整率Ｐｒを算出する（ステップ１００６）。ここで、リソース削減調整率Ｐｒは、システム全体としてどの程度のリソース消費量圧縮が必要かを示す値であり、次のようにして求められる。
（１） Ｐｒ＝Ｒａ÷Ｒｔ
【００８４】
次に、端末配分リソース計算部４２３は、このＰｒを用いてサービスアプリケーション毎の動作モードを修正する（ステップ１００７）。具体的には、端末配分リソース計算部４２３は、端末サービス管理テーブル４２２内の各エントリ（図７）のＡＰｉのモードリソース対応表（図８）を参照し、その表の第２列（必要リソース量）中の値がＲｉ×Ｐｒに最も近い行を選び、その行の第１列から動作モードの値を得る。ここで得た動作モード値を端末サービス管理テーブルエントリの調整済動作モードフィールド４２２６に設定し、本リソース計算手順全体を終了する。
【００８５】
上記リソース配分調整操作は、サービスアプリケーション側が希望するリソース量に対し、リソース削減調整率Ｐｒで割り掛けされたリソース量にもっとも適合する動作モードを調整済動作モードに選定する、という意味を持っている。この選定処理を端末サービス管理テーブル４２２内の全エントリに対して行うことで、本リソース計算手順全体が完了する。
【００８６】
次に、本システムの動作について説明する。まず、端末３００の動作について説明する。本発明の特徴となる端末３００の動作は、大きく分けて、サービス享受状態判断処理、ユーザ反応調査モード変更処理、不満動作検出処理の３つの処理からなる。
【００８７】
図１０は、サービス享受状態判断処理の流れを示すフローチャート図である。端末３００は、図１０に示す処理を繰り返し行うことでユーザのサービス享受状態が変化したかを判断する。具体的には、一定周期（例えば５秒毎）で発生し続けるようなタイマ割り込みを設定しておき、そのタイマ割り込みのハンドラ（割り込み処理ルーチン）として、図１０に示すフローを登録しておくことでサービス享受状態の変化の判断を継続的に行う。以下図１０に示す動作について説明する。
【００８８】
端末情報収集制御部３４０は、タイマ割り込みが入ると、未送信の端末コンテキストメッセージが一時保存されているかどうかを確認する（Ｓ２００１）。未送信の端末コンテキストメッセージが一時保存されている場合は、当該未送信端末コンテキストメッセージを送信する（Ｓ２００２）。
【００８９】
Ｓ２００１において未送信端末コンテキストメッセージが無い場合、又は、ステップ２００２で未送信端末コンテキストメッセージが送信されると、コンテキスト認識部３３０は、センサ群３２０を使ってセンシングを行い、端末の状態又は端末周囲の状態を調査する（Ｓ２００３）。ここで、コンテキスト認識部３３０が調査する端末の状態としては、例えば、位置（ＧＰＳによる）、加速度、傾き（重力加速度による）などがあり、端末周囲の状態としては、端末周囲の明るさ（照度による）やカメラで取得される画像により認識される端末周囲の状態などとすることができる。
【００９０】
コンテキスト認識部３３０は、Ｓ２００３の調査の結果に基づいて、ユーザの現在の状況を推測し、端末ユーザのサービス享受状態が変化しているかどうかを判断する（Ｓ２００４）。
【００９１】
例えば、コンテキスト認識部３３０は、加速度センサで得られる端末の加速度の時系列変化を分析することで、端末を持つユーザの動作状態、例えば走っているか/静止しているかを識別することができる。また、コンテキスト認識部３３０は、位置検出センサで得られる現在位置に関する情報と地図データとを照合することでユーザが自宅にいる/電車に乗っている/職場や学校にいる、といった識別を行うことができる。また、コンテキスト認識部３３０は、傾きセンサで得られる端末の傾きや、光検出センサで得られる端末周囲の明るさ、その他端末内部に設けられた現在時刻を算出する時刻管理部より得られる現在時刻などの情報に基づいて、ユーザが端末を手に持って利用しているかどうかのヒントを得ることができる。更には、コンテキスト認識部３３０は、端末のキーやタッチスクリーン操作頻度を監視し、また、無線ＬＡＮや３Ｇ（第３世代携帯電話）の電波状態を監視し、これらの監視結果からユーザ状態の手掛かりが得られる。また、コンテキスト認識部３３０は、端末が具備する内蔵カメラやマイクにより取得される映像や音声を分析することにより、ユーザ状態の手掛かりを得ることもできる。コンテキスト認識部３３０は、これらの識別手法をいくつか組み合わせてユーザ状態を推測し、そのとき端末３００で起動されてネットワークサービスを実行している端末側アプリケーションの種類とあわせ、端末ユーザがサービスを享受しているか否かを判断する。
【００９２】
コンテキスト認識部３３０は、Ｓ２００４における判断の結果、前回行った判断時と比べて端末ユーザのサービス享受状態が変化していない場合、一連の処理を終了する。一方、端末ユーザのサービス享受状態が変化している場合、コンテキスト認識部３３０は、端末情報収集制御部３４０に、サービス享受状態が変化したこと示すコンテキスト情報を通知し、端末情報収集制御部３４０は、当該コンテキスト情報と、ユーザＩＤと、現在の時刻を示す時刻情報とを含めて、端末コンテキストメッセージを作成する（Ｓ２００５）。
【００９３】
次に、端末情報収集制御部３４０は、サービス提供サーバ４００と通信が可能であるかを調べる（Ｓ２００６）。
【００９４】
サービス提供サーバ４００と通信が不可能な状態であれば、端末情報収集制御部３４０は、作成した端末コンテキストメッセージを一時的に保存して処理を終了する（Ｓ２００７）。
【００９５】
一方、通信が可能な状態であれば、端末情報収集制御部３４０は、ネットワークインタフェース３５０を介して、前記端末コンテキストメッセージをサービス提供サーバ４００に送信し、処理を終了する（Ｓ２００８）。
【００９６】
次に図１１に示すフローチャートを用いてユーザ反応調査モード変更処理の流れについて説明する。
【００９７】
端末情報収集制御部３４０は、サービス提供サーバ４００から自端末宛てのリソース配分決定メッセージの到着を監視する（Ｓ２１０１）。具体的には、端末情報収集制御部３４０は、ネットワークインタフェースを介してリソース配分決定メッセージを受信すると、当該メッセージに含まれるユーザＩＤ７２１の値を確認し、自端末のユーザＩＤに一致しているかどうかを確認することで、自端末宛てのリソース配分決定メッセージであるかどうかを判断する。端末情報収集制御部３４０は、当該メッセージに含まれるユーザＩＤ７２１の値が自端末のユーザＩＤに一致しない場合は、当該メッセージを破棄し、リソース配分決定メッセージの到着の監視を継続する。
【００９８】
端末情報収集制御部３４０は、自端末宛てのリソース配分決定メッセージを受信した場合、自端末に対するリソース割り当ての状況を判断する（Ｓ２１０２）。
【００９９】
具体的には、端末情報収集制御部３４０は、当該メッセージ内のサーバ側リソース配分決定結果７２２の値を確認する。サーバ側リソース配分決定結果７２２の値が「活動中」を示していない場合は、端末情報収集制御部３４０は、ユーザ反応検知部３６０に対し、非活動中ユーザ反応調査の開始を指示し、Ｓ２１０１に戻って自端末宛てのリソース配分決定メッセージの到着を監視する（ステップＳ２１０３）。一方、サーバ側リソース配分決定結果７２２の値が「活動中」を示している場合は、ユーザ反応検知部３６０に対し、非活動中ユーザ反応調査の停止を指示し、Ｓ２１０１に戻って自端末宛てのリソース配分決定メッセージの到着を監視する（ステップＳ２１０４）。
【０１００】
上記処理によりユーザ反応調査部３６０の動作モードであるユーザ反応調査モードの変更を行う。具体的には、端末状態収集制御部３４０は、ステップ２１０３及びステップ２１０４において、大域変数、共有メモリあるいはメッセージ通信等の仕組みにより、非活動中ユーザ反応調査を行うか否かのモード値をユーザ反応検知部３６０に伝える。
【０１０１】
次に図１２に示すフローチャートを用いて不満動作検出処理の流れについて説明する。
【０１０２】
ユーザ反応検知部３６０は、一定間隔ごとのタイマ割り込みで非活動中ユーザ反応調査が指示されているかどうかを判断する（Ｓ２２０１）。具体的には、ユーザ反応検知部３６０は、図１１のＳ２１０３及びＳ２１０４において端末情報収集制御部３４０が大域変数、共有メモリあるいはメッセージ通信等前述した仕組みを用いて通知したモード値を参照することで、非活動中ユーザ反応調査が指示されているか否かを判断する。
【０１０３】
Ｓ２２０１における確認の結果、非活動中ユーザ反応調査の停止が指示されている場合は、そのまま処理を終了する。一方、非活動中ユーザ反応調査の開始が指示されている場合は、非活動中ユーザ反応調査を実施する（Ｓ２２０２）。
【０１０４】
ユーザ反応検知部３６０は、ユーザ反応調査中にネットワークサービスの品質レベル低下に対するユーザの不満動作（反論動作）が発せられたかどうかを判断する（Ｓ２２０３）。例えば、ユーザ反応検知部３６０は、加速度センサを使い、短い時間間隔で加速度が振動することで端末が振られていると認識し、これをユーザの不満動作として捉えるという認識方式を用いることができる。また、ユーザ反応検知部３６０は、加速度センサで急激な加速が検出されることでユーザが端末を叩く動作を認識し、これをユーザの不満動作として捉えるという認識方式を用いることができる。
【０１０５】
ユーザ反応検知部３６０は、ユーザ反応調査中に不満動作を検出しなかった場合は、処理を終了する。一方、ユーザ反応検知部３６０は、ユーザ反応調査中に不満動作が検出された場合は、端末情報収集制御部３４０にユーザの不満動作が検出されたことを通知する。
【０１０６】
端末情報収集制御部３４０は、ユーザ反応検知部３６０より当該通知されたユーザの不満動作に関する情報をコンテキスト情報として、端末コンテキストメッセージを作成してサービス提供サーバ４００に送信し、処理を終了する（Ｓ２２０４）
【０１０７】
次に、サービス提供サーバ４００のサービス制御動作について図１３に示すフローチャートを用いて説明する。
【０１０８】
リソース配分決定部４２０は、図１０に示すＳ２００２又はＳ２００８において送信された端末コンテキストメッセージを受け取ると、内部の端末サービス管理テーブル４２２に記憶している当該端末のエントリを更新する（Ｓ３００１）。具体的には、当該エントリに含まれるユーザ状態４２２２を、端末コンテキストメッセージ７１０に含まれるユーザ状態７１２で示される状態に変更する。すなわち、端末コンテキストメッセージ７１０を受け取り、当該メッセージに含まれるユーザ状態７１２が「非活動中」である場合には、当該エントリに含まれるユーザ状態４２２２を「非活動中」に変更する。そして、当該エントリに含まれる目標動作モード４２２５の値を待機時動作モードの値に変更する。一方、当該メッセージに含まれるユーザ状態７１２が「活動中」である場合には、当該エントリに含まれるユーザ状態４２２２を「活動中」に変更する。そして、当該エントリに含まれる目標動作モード４２２５の値を通常動作モードの値に設定する。
【０１０９】
次に、リソース配分決定部４２０は、図９で説明したフローチャートに従ってリソース配分を計算する（Ｓ３００２）。リソース配分決定部４２０は、計算結果をリソース配分実行部４３０に通知する。
【０１１０】
リソース配分実行部４３０は、通知されたリソース配分に従ってリソースを配分する（Ｓ３００３）。
【０１１１】
各サービスアプリケーション４５０は、リソース配分実行部４３０で実行されるリソース配分に従い、ネットワークサービスを提供する（Ｓ３００４）。
【０１１２】
リソース配分決定部４２０は、Ｓ３００２で決定したリソース配分結果を対応する端末に通知する（Ｓ３００５）。
【０１１３】
以上説明したように、本実施の形態では、端末側のセンサ等を用いてユーザ及び端末の状況を推測・判断し、その情報をサービス提供サーバ側に集めることで、各端末に対するサービスへのリソース配分量を変化させている。特に、サービスを享受していないユーザ向けのサービスに対するリソース配分量を時間的に漸減させ、また、サービスを享受している意思を表明したユーザ向けのサービスに対してはリソース配分量を復元させている。
【０１１４】
上記構成により、サービス提供側のサーバ及びネットワークリソースの消費電力及び通信コストの削減、並びに、サービスを真に享受しようとしているユーザに対するリソース集中配分によるサービス品質向上、という本発明の効果が得られる。
【０１１５】
その理由は、サービス提供サーバ側において、それぞれの端末側で取得された各端末ユーザの状況を受け取ることで当該状況を知り、端末側で最終的に利用されていないサービスに対してサーバ及びネットワークで割り当てているリソースを減らすことができるようになるためである。例えば、サーバのＣＰＵリソースを減らせば消費電力削減につながり、ネットワークを介して配信するデータ量を減らせばサービス提供者がネットワーク運用者に支払う通信費用を低減するとともに、サーバ運用者やネットワーク運用者が保有するネットワーク装置の消費電力抑制に寄与することになる。
【０１１６】
なお、上記説明では、リソース配分決定部４２０が、ネットワークサービスを享受していないことを示す端末コンテキストメッセージを受け取った場合に、エントリ内の目標動作モードの値を待機時動作モードの値に設定し、当該設定後の各エントリを用いてリソース配分を決定する場合について説明したが、これに限るものではない。
【０１１７】
図１４は、リソース配分決定部４２０におけるリソース配分決定の別の処理動作を示すフローチャートである。なお、端末配分リソース計算部４２３が本フローチャートに従ってリソース配分計算を行う場合は、全端末情報管理部４２１は、「非活動中」を示す端末コンテキストメッセージを受け取っても、エントリに含まれるユーザ状態を「非活動中」に設定するに留まり、目標動作モードは通常動作モードのままに設定しておく。
【０１１８】
図１４のＳ４００１〜Ｓ４００５は、図９のＳ１００１〜Ｓ１００５と同一であるため説明を省略する。Ｓ４００４においてＲｔ＞Ｒａである場合は、端末配分リソース計算部４２３は、端末サービス管理テーブル４２２に記録されているエントリのうち、ユーザ状態が「非活動中」であるエントリの目標動作モードの値（ＭＰｉ）を待機時動作モードの値に設定する（Ｓ４００６）。
【０１１９】
端末配分リソース計算部４２３は、Ｓ４００６において全ての「非活動中」のエントリの目標動作モードを待機時動作モードの値に変更した後、必要リソースの総和Ｒｔ′を改めて算出する（Ｓ４００７）。
【０１２０】
端末配分リソース計算部４２３は、Ｓ４００７でユーザ状態を反映させて再計算した必要リソースの総和Ｒｔ′と利用可能なリソース量Ｒａを再度比較する（Ｓ４００８）。
【０１２１】
端末配分リソース計算部４２３は、比較の結果Ｒｔ′≦Ｒａである場合は、Ｓ４００５と同様、ＭＰｉの値を調整済み動作モードフィールドに設定し、計算処理を終了する（Ｓ４００９）。
【０１２２】
一方、比較の結果Ｒｔ′＞Ｒａである場合は、端末配分リソース計算部４２３はＰｒ′を算出する（Ｓ４０１０）。ここでリソース削減調整率Ｐｒ′はＰｒ同様以下の式で求められる。
（２） Ｐｒ′＝Ｒａ÷Ｒｔ′
【０１２３】
次に、端末配分リソース計算部４２３は、図９のＳ１００７同様、リソース削減調整率Ｐｒ′を用いてサービスアプリケーション毎の動作モードを修正する（Ｓ４０１１）。
【０１２４】
次に、端末配分リソース計算部４２３は、修正した動作モードの値を調整済動作モード４２２６に設定し、計算処理を終了する（Ｓ４０１２）。
【０１２５】
上記計算手順に従ってリソース配分を計算することで、リソース逼迫時にユーザ状態を考慮したリソース配分を行うため、リソース逼迫時においてもネットワークサービスを享受しているユーザに適切にリソースを割り当てることができる。また、このような計算方法を用いることにより、端末がユーザ状態を誤って認識し、誤ったサービス利用状況に関する情報を含む端末コンテキストメッセージを送信しても、サーバ側でリソースに余裕がある場合は、このようなユーザに対するネットワークサービスの品質は維持される。従って、端末がユーザ状態を誤って判断し、ネットワークサービスの品質が下げられることでユーザの不満動作が発せられるといった事態を減らすことができる。
【０１２６】
次に、具体的な実施例を用いて本発明を実施するための最良の形態の動作を説明する。
【０１２７】
（実施例１）
本実施例に係るネットワークサービス制御システムは、図１に示したように１台のサービス提供サーバと複数の端末とを含んで構成され、当該サービス提供サーバは、ネットワークサービスとして具体的に動画配信サービスを携帯端末に対して提供する。すなわち、本実施例におけるネットワークサービス制御システムにおいて、サービス提供サーバは動画配信サーバであり、端末は動画配信を視聴可能な携帯端末である。
【０１２８】
図１５は本実施例において動画配信を受ける携帯端末５００の実現形態を示した図である。携帯端末５００は、ハードウェアとして、携帯端末用ＣＰＵ５１０と、ＧＰＳ５２１と、加速度センサ５２２と、時計５２３と、３Ｇ公衆無線サービスと屋内ワイヤレスＬＡＮに対応した無線インタフェース５５０及びそれに付属するアンテナと、を備える。また携帯端末５００は、ソフトウェアとして、携帯端末用ＯＳ５１５と、動画配信サーバから受信した動画ストリームを再生する動画視聴アプリ５７０と、本発明の主たる構成要素のひとつとなる端末制御アプリ５８０と、を備える。本発明の実施の形態２で説明したコンテキスト認識部、及び端末情報収集制御部、ユーザ反応検知部、は、いずれもそれらをソフトウェアとして実現したモジュール（図１５の５８１、５８２、及び５８３）として端末制御アプリ５８０の中に実装される。
【０１２９】
コンテキスト認識モジュール５８１は、ＧＰＳ５２１から得た位置情報と、加速度センサ５２２から得た端末の動きと、及び時計５２３から得た現在日時と、を用いてユーザの状況を判断する。
【０１３０】
例えば、時計５２３から得た現在日時が平日の朝夕の時間帯内であり、ＧＰＳから取得した現在の位置情報が予め登録している自宅及び勤務先との間を示しており、加速度センサから得られる直近１０秒間の加速度が徒歩ないし電車乗車中ないしバス乗車中の加速度波形と高い類似度を示す場合は、非活動中と判断する。また、平日の日中で、位置情報が勤務先にある場合は、非活動中と判断する。また、深夜０時から朝６時までの間で、直近１０秒間の加速度が０の場合は、非活動中と判断する。一方、条件に合致しない場合は、活動中と判断する。いずれの場合も、活動中と非活動中との間で状態変化があった場合、コンテキスト認識モジュール５８１は、端末情報収集制御モジュール５８２にその変化を通知する。
【０１３１】
なお、上述のユーザ状況判断条件は、サービスの種類やユーザの行動特性（会社員か学生か高齢者か）等の情報をあわせて適切なものに変更すべきであることは言うまでもない。すなわち、ユーザの行動特性に関する情報やユーザが設定した設定情報を予め図示せぬ記憶部に記憶しておき、コンテキスト認識モジュール５８１は、ユーザ状況の把握に当該記憶部に記憶されている上記情報を参照してもよい。
【０１３２】
ユーザ反応検知モジュール５８３は、端末情報収集制御モジュール５８２から非活動中ユーザ反応調査の開始を指示された場合、加速度センサ５２２の出力を監視し、急激で大きな加速度変化を観測した場合は、端末情報収集制御モジュール５８２に対し、活動中への状態遷移を通知する。
【０１３３】
端末情報収集制御モジュール５８２は、無線インタフェース５５０から電波状態を調べ、屋内ワイヤレスＬＡＮによる通信が可能であればそれを使い、屋内ワイヤレスＬＡＮが使えなければ３Ｇ公衆無線サービスを使って、ユーザの活動中及び非活動中の状態変化を端末コンテキストメッセージに纏めて動画配信サーバに送る。
【０１３４】
図１６は、動画配信サーバ６００の実現形態を示した図である。動画配信サーバ６００は、ハードウェアとして、サーバ用ＣＰＵ群６１０と、高速イーサネットインタフェース６４０（イーサネットは登録商標。以下省略。）とを備える。高速イーサネットインタフェース６４０は、外部の通信ネットワーク網に接続されており、サービス対象の携帯端末と通信できるようになっている。
【０１３５】
動画配信サーバ６００は、ソフトウェアとして、サーバ用ＯＳ６１５と、サービスを実施する動画配信アプリ群６５０と、本発明の主たる構成要素のひとつとなるサービス制御アプリ６６０と、を備える。本発明の実施の形態２で説明したリソース配分決定部、リソース配分実行部は、いずれも、それらをソフトウェアとして実現したモジュールとしてサービス制御アプリ６６０内部に実装される。具体的には、サービス制御アプリ６６０には、リソース配分決定モジュール６６１、リソース配分実行モジュール６６２、モードリソース対応表６６３、端末サービス管理テーブル６６４がそれぞれ実装されている。
【０１３６】
動画配信アプリ群６５０は、複数の動作モードを有し、リソース配分実行モジュール６６２からの指示によりそのいずれかの動作モードで動作する。サーバ用ＯＳ６１５は、動画配信アプリ群６５０で使われなかったリソースについては時間的に省電力状態にする（例えば使われていない期間は省電力モードに切り替えるか、電源供給を止める）か、あるいは空間的に省電力状態にする（例えば使われていない部分を省電力モードに切り替えるか電源供給を止める）という動的省電力機構を備える。
【０１３７】
リソース配分決定モジュール６６１の構成と動作は、先に説明したリソース配分決定部４２０の構成と動作と機能的に同様であるが、本実施例では、サーバ側のリソース量の計算に際してＣＰＵリソースとネットワークリソース（以下ＮＷリソースと表記）の２種を扱う事例を取りあげる。そこで以下では、このリソース配分決定に関する差異部分について詳しく説明する。
【０１３８】
図１７は、本実施例で使用する２つのサービスアプリケーションＡＰ１及びＡＰ２のモードリソース対応表である。これらのサービスアプリはＣＰＵだけでなくＮＷリソースも必要とするが、それらの使用比率がサービスアプリ間で大きく異なるため、同図のように、両リソースを区別して取り扱う。同図において、各リソースの値は、動画配信サーバが備える全体リソース量を１００としたときの相対量で示されている。
【０１３９】
図１７（ａ）を参照すると、サービスアプリＡＰ１は５つの動作モード（１から５）を有し、そのうち動作モード５が通常動作モード、動作モード１が待機時動作モードである。また、通常動作モードで動作するサービスアプリＡＰ１の１タスク（１つの実体）は、動画配信サーバのＣＰＵリソースの４０％と、同サーバのＮＷリソースの２５％を消費することが示されている。同様に図１７（ｂ）はもう一つのサービスアプリＡＰ２の動作モードとそのときの消費リソース量を示したモードリソース対応表である。これらの図に示した値は、本番サービス開始前にサービスアプリ１タスクをサーバ上で仮実行させ、ＯＳ等を用いてリソース消費量を測定することで得、それに基づいて図１３（ａ）（ｂ）のモードリソース対応表が作成される。
【０１４０】
図１８は本実施例における端末サービス管理テーブル６６３の具体例を示した図である。本実施例では、後述するリソース配分計算の便を図るため、端末サービス管理テーブルの欄として「ＣＰＵリソース」「ＮＷリソース」の２列が追加されている。これらはリソース配分計算過程でのみ使用されるものであり、図１８においてはその中身は特に表示されていない。
【０１４１】
図１８（ａ）は、動画配信サービス中のある時点（１９時）での端末サービス管理テーブルの内容を示したもので、ユーザＵ０００１及びユーザＵ０００２がいずれも活動中状態であることが端末側からの情報として得られており、サーバ側ではこれらのユーザに対していずれもサービスアプリＡＰ１（タスクの実体としてはＡＰ１−１及びＡＰ１−２と表記）を動作モード５即ち通常動作モードにて実行中である。図１８（ａ）はまた、この２ユーザに加え、新たにユーザＵ０００３に対しサービスアプリＡＰ１（タスク実体はＡＰ１−３）を開始することになった状態を示している。ユーザＵ０００３は活動中との情報を得ているため、目標動作モードは５としているが、図１８（ａ）の段階ではまだリソース配分計算が完了しておらず、調整済動作モードの値はまだ更新されていない。
【０１４２】
図１８（ｂ）はサービスアプリＡＰ１−１〜ＡＰ１−３の間でリソース配分計算が完了したときの状態を示しており、調整済動作モードは目標動作モードと異なり、いずれも４となっている。このリソース配分計算のステップについて、図１９を参照しながら以下で具体的に説明する。
【０１４３】
図１９（ａ）はリソース配分計算開始直前の状態を示している。ＡＰ１−１とＡＰ１−２はいずれも動作モード５で動作しており、サーバ内でのＣＰＵ及びＮＷリソースの消費量の合計は各々８０、５０である。
【０１４４】
ここで図１９（ｂ）のようにＡＰ１−３が追加され、これも目標動作モード５であるとする。図９の計算手順のステップＳ１００１及びＳ１００２に従い、図１９（ａ）のモードリソース対応表を元にＣＰＵ及びＮＷの必要リソース量の合計を求めると各々１２０、７５となる。ここでＣＰＵリソース量が１００を超え、不足する見通しであることがわかる（図９のステップＳ１００４）。そこでリソース削減調整率１００÷１２０＝０．８３を各リソース量に乗じると図１９（ｃ）となる。図１７（ａ）のモードリソース対応表からＣＰＵリソース３３、ＮＷリソース２１に最も近いものを選ぶと、動作モード４（ＣＰＵリソース３０、ＮＷリソース１６）がそれに相当する。そこで図１９（ｄ）に示すように、ＡＰ１−１〜ＡＰ１−３の調整済動作モードを４に設定する（図９のステップＳ１００８）。このとき全体必要リソース量はＣＰＵ、ＮＷそれぞれ９０及び４８となり、サーバリソース量でまかなえるようになったことがわかる。
【０１４５】
この後、更に状況が変化してサービスアプリＡＰ２−１が追加になった場合のリソース配分計算過程を図２０に示す。図１７（ｂ）を参照すると、ＡＰ２−１の通常動作モード３ではＣＰＵ及びＮＷリソースを各々２０及び７０消費し、従って図２０（ａ）から読み取れるように、サーバ全体では各々１４０及び１４５のリソースが必要である。ここではＮＷリソース量の上限逸脱がＣＰＵリソース量のそれより大きいので、ＮＷリソース側から調整を図る。即ちリソース削減調整率１００÷１４５＝０．６９を乗じて図２０（ｂ）のようなリソース量に圧縮することを狙い、図１７（ａ）及び（ｂ）から最も近いリソース量となる動作モードを選ぶと、ＡＰ１に対し動作モード４、ＡＰ２に対し動作モード２となる。この状態を図２０（ｃ）に示す。ここで必要ＮＷリソースの合計はサーバ全体のＮＷリソース量内に収まったが、ＣＰＵリソース量の合計は１０５でまだ上限を５％超えている。本実施例ではこのように若干の上限超えを生じることがあるが、これはサーバＯＳ６１５における規定のリソーススケジューリング動作による自動調整に委ねる。通常これが問題になることはないが、こうしたＯＳ自動調節に委ねる割合を少なくするために、モードリソース対応表（図１７）には多段階の動作モードを登録しておくのがよい。
【０１４６】
更にユーザ状態が変化した場合の説明を継続する。図２１（ａ）は２人のユーザが非活動状態となった場合を示している。それらのユーザに対応するＡＰ１−２及びＡＰ１−３の目標動作モードは５から１即ち待機時動作モードとなる。図９のリソース計算手順に沿ってサーバ全体の必要リソース量を求めると、ＣＰＵリソース＝９０、ＮＷリソース＝９９となり、いずれもサーバ全体リソースに収まる。そこで各アプリの調整済動作モード値はいずれも目標動作モード値と同じとしている。
【０１４７】
図２１（ａ）の状態を図２０（ｃ）の状態と比較すると、ＡＰ１−２及びＡＰ１−３に配分されていたリソースが減り、逆にＡＰ１−１及びＡＰ２−１に配分されていたリソースが増えていることがわかる。これは、サービスを享受していないと判断されたユーザからサービスを真に享受しているユーザへリソースが再配分され、後者のユーザに対するサービス品質改善につながっている。
【０１４８】
図２１（ｂ）は更に４人目のユーザが非活動状態となった場合を示しており、ＡＰ２−１の目標動作モードが１即ちＡＰ２の待機時動作モードとなっている。同様にリソース計算手順に沿って計算すると、ＣＰＵもＮＷもサーバ全体リソース量に収まるため、各アプリの調整済動作モード値はいずれも目標動作モード値と同じになる。
【０１４９】
図２１（ｂ）のとき、サーバではＣＰＵリソースのうちの２５％、ＮＷリソースのうちの６１％は不要であり、サーバＯＳ ６１５が備える動的省電力機構によりこれらの不要リソース分の電力消費を削減する。これは、サービスを享受していないと判断されたユーザへのサービスのために割くリソースを減らし、サーバ消費電力を削減できたことを意味する。
【０１５０】
このように、本実施例では、ユーザの携帯端末側から得たコンテキスト情報を元に映像配信サーバ側のリソース配分を調節し、サービスを享受しているユーザに対するサービス品質改善、及び映像配信サーバ側消費電力の削減を実現している。
【０１５１】
以上各実施の形態及び実施例で説明したように、本発明によれば、ネットワークサービスを享受しているユーザに対して適切なリソース割り当てが可能となる。すなわち、サービス配信を受けている複数のユーザそれぞれの状況をサービス提供サーバ側で把握し、サービスを最終的に利用していないユーザに対して割り当てていたサーバ及びネットワークリソースを、サービスを真に享受したいと希望しているユーザ向けに再配分し、限られたリソースを有効に活用することが可能になる。
【０１５２】
なお、上述した動画視聴アプリ、端末制御アプリ、動画配信アプリ、サービス制御アプリの各種プログラムは、コンピュータ・システムがアクセス可能な様々な種類の記憶媒体に格納することが可能である。また、このプログラムは、通信媒体を介して伝達されることが可能である。ここで、記憶媒体には、例えば、フレキシブルディスク、ハードディスク、磁気ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＤＶＤ、ＲＯＭカートリッジ、バッテリバックアップ付きＲＡＭメモリカートリッジ、フラッシュメモリカートリッジ、不揮発性ＲＡＭカートリッジ等が含まれる。また、通信媒体には、電話回線等の有線通信媒体、マイクロ波回線等の無線通信媒体等が含まれ、インターネットも含まれる。
【０１５３】
また、本発明のシステムは多数のコンシューマ端末向けに集中サーバからサービスを提供するサービスシステムに適用できる。例えば、動画配信システム、メッセージ交換システム、サーバクライアント形態をとる音声認識システム、画像認識システム等に適用することができる。
【０１５４】
なお、本発明は上記実施の形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変形・変更することが可能である。本発明の実施の形態としては様々な態様が考えられ、例えば以下のような実施の形態が可能である。
【０１５５】
（１）ネットワークサービスの提供を行うサービス提供サーバと、前記ネットワークサービスの提供を受ける複数のサービス実行端末と、を備えるサービス制御システムであって、前記サービス実行端末は、前記サービス提供サーバより提供されるネットワークサービスを実行することで前記ネットワークサービスを端末ユーザに提供するサービス実行手段と、自端末の状態又は自端末周囲の状態を検出する端末状態検出手段と、前記端末状態検出手段における検出結果に基づいて端末ユーザが前記ネットワークサービスを利用しているか否かを判断するサービス利用状況判断手段と、前記サービス利用状況判断手段における判断結果を前記サービス提供サーバに通知するサービス利用状況通知手段と、を具備し、前記サービス提供サーバは、前記サービス実行端末より通知された前記判断結果に基づいて前記サービス実行端末に提供するネットワークサービスに対して配分するリソース量を決定するリソース配分決定手段と、前記リソース配分決定手段で決定されたリソース量に基づいて前記サービス実行端末に提供するネットワークサービスに対してリソースを配分するリソース配分実行手段と、前記リソース配分実行手段により配分されるリソースを用いてネットワークサービスの提供を前記サービス実行端末に対して行うサービス提供手段と、を具備する、サービス制御システム。
（２）サービス提供サーバより提供されるネットワークサービスを実行することで前記ネットワークサービスを端末ユーザに提供するサービス実行手段と、自端末の状態又は自端末周囲の状態を検出する端末状態検出手段と、前記端末状態検出手段における検出結果に基づいて端末ユーザが前記ネットワークサービスを利用しているか否かを判断するサービス利用状況判断手段と、前記サービス利用状況判断手段における判断結果を前記サービス提供サーバに通知するサービス利用状況通知手段と、を具備するサービス実行端末。
（３）前記サービス実行手段は、前記ネットワークサービスを複数の品質レベルで前記端末ユーザに対して提供可能であることを特徴とする、（２）に記載のサービス実行端末。
（４）前記サービス実行手段が前記ネットワークサービスを所定の基準より低い品質レベルで前記端末ユーザに提供している場合において、前記端末ユーザから発せられる所定の動作を検知するユーザ反応検知手段を更に具備し、前記サービス利用状況通知手段は、前記所定の動作の検知結果を前記サービス提供サーバに通知する、（３）に記載のサービス実行端末。
（５）前記サービス利用状況通知手段は、提供するネットワークサービスの品質レベルを下げることを示す通知を前記サービス提供サーバより受信し、前記ユーザ反応検知手段は、前記通知が受信された場合に前記端末ユーザが前記ネットワークサービスの品質レベルの低下に対する不満を表す動作を発しているかを判断する、（４）に記載のサービス実行端末。
（６）前記サービス利用状況判断手段は、前記サービス実行手段が実行しているネットワークサービスの種類及び前記前記端末状態検出手段における前記検出結果に基づいて端末ユーザが前記ネットワークサービスを利用しているかどうかを判断する、（２）乃至（５）のいずれか１項に記載のサービス実行端末。
（７）前記端末状態検出手段は、自端末に生じる加速度、自端末の位置、自端末の傾き、自端末周囲の明るさ、の少なくとも１つを前記自端末の状態又は自端末周囲の状態として検出する、（２）乃至（６）のいずれか１項に記載のサービス実行端末。
（８）前記サービス実行手段は、動画配信サーバより配信される動画ストリームを前記動画配信サーバより指定されたビットレートで再生する、（３）又は（４）に記載のサービス実行端末。
（９）前記端末状態検出手段は、少なくとも自端末周囲の明るさを検出する光センサ及び自端末に生じる加速度を検出する加速度センサを備え、前記サービス利用状況判断手段は、前記サービス実行手段が前記動画配信サーバより配信される動画ストリームを再生している場合であって、前記光センサで検出される光量が所定の基準値より少なく、かつ、前記加速度センサで検出される加速度の値が所定の期間０である場合に、端末ユーザは動画配信サービスを利用していないと判断する、（８）に記載のサービス実行端末。
（１０）前記端末状態検出手段は、少なくとも自端末周囲の明るさを検出する光センサと、自端末に生じる加速度を検出する加速度センサと、自端末の現在位置を検出する位置センサと、を具備し、前記サービス利用状況判断手段は、前記サービス実行手段が対話型メッセージサービスを実行している場合であって、一定期間キー操作又はタッチスクリーン操作がなく、かつ、前記光センサで検出される光量が所定の基準値より少なく、かつ、前記加速度センサ及び位置センサでそれぞれ検出される加速度及び現在位置に変化がある場合に、端末ユーザは前記対話型メッセージサービスを利用していないと判断する、（３）又は（４）に記載のサービス実行端末。
（１１）端末ユーザの行動特性に関する情報を記憶する記憶手段を更に具備し、前記前記サービス利用状況判断手段は、前記記憶手段に記憶された前記行動特性に関する情報を参照して、前記端末ユーザがネットワークサービスを利用しているか否かを判断する、（２）乃至（１０）のいずれか１項に記載のサービス実行端末。
（１２）前記サービス実行手段は、前記サービス提供サーバより提供されるネットワークサービスを指定された動作モードで実行するアプリケーションタスクである、（２）乃至（１１）のいずれか１項に記載のサービス実行端末。
（１３）複数のサービス実行端末よりそれぞれ通知される各端末ユーザがネットワークサービスを利用しているか否かについての判断結果に基づいて前記複数のサービス実行端末にそれぞれ提供するネットワークサービスに対して配分するリソース量を決定するリソース配分決定手段と、前記リソース配分決定手段で決定されたリソース量に基づいて前記複数のサービス実行端末にそれぞれ提供するネットワークサービスに対してリソースを配分するリソース配分実行手段と、前記リソース配分実行手段により配分されるリソースを用いて前記ネットワークサービスの提供を前記複数のサービス実行端末に対して行うサービス提供手段と、を具備するサービス提供サーバ。
（１４）前記サービス提供手段は、前記ネットワークサービスを複数の品質レベルで前記端末ユーザに対して提供可能であり、前記リソース配分決定手段で決定されるリソース量のリソースを用いて実現可能な品質レベルで前記ネットワークサービスの提供を行う、（１３）に記載のサービス提供サーバ。
（１５）前記リソース配分決定手段は、前記複数のサービス実行端末に対するネットワークサービスの提供に必要なリソースの総量が、前記ネットワークサービス提供に利用可能なリソースの総量を上回る場合に、前記判断結果に基づいて端末ユーザが利用していないネットワークサービスに対して配分するリソース量を削減する決定を行う、（１３）又は（１４）に記載のサービス提供サーバ。
（１６）前記サービス提供手段は、リソース消費量の異なる複数の動作モードを有し、前記複数のサービス実行端末にネットワークサービスを提供するサービスアプリケーションタスクを備え、前記リソース配分決定手段は、前記判断結果に基づいて前記サービスアプリケーションタスクの動作モードを前記複数のサービス実行端末に提供するネットワークサービス毎に決定し、前記リソース配分実行手段は、前記リソース配分決定手段で決定された前記動作モードの指示を前記サービスアプリケーションタスクに対して行い、
前記サービスアプリケーションタスクは、前記指示された動作モードでそれぞれ前記ネットワークサービスを前記サービス実行端末に提供する、（１３）に記載のサービス提供サーバ。
（１７）前記リソース配分決定手段は、前記サービスアプリケーションタスクの各動作モードが必要とするリソース量を示したモードリソース対応表と前記判断結果とに基づいて、前記複数のサービス実行端末に対するネットワークサービスの提供に必要なリソースの総量が、前記ネットワークサービス提供に利用可能なリソースの総量を超えないように、各サービス実行端末にネットワークサービスを提供するサービスアプリケーションタスクの動作モードを決定する、（１６）に記載のサービス提供サーバ。
（１８）前記サービス提供手段は、前記リソース配分実行手段により配分されるリソースに応じた配信ビットレートで前記サービス実行端末に対して動画配信を行う、（１３）乃至（１７）のいずれか１項に記載のサービス提供サーバ。
（１９）自端末の状態又は自端末周囲の状態を検出する端末状態検出手段で得られる検出結果に基づいて端末ユーザがネットワークサービスを利用しているか否かを判断するサービス利用状況判断処理と、ネットワークサービスを所定の基準より低い品質レベルで前記端末ユーザに提供している場合において、前記端末ユーザから発せられる所定の動作を検知するユーザ反応検知処理と、前記サービス利用状況判断処理における判断結果及び前記ユーザ反応計地処理における検知結果をそれぞれサービス提供サーバに通知するサービス利用状況通知処理と、を計算機に実行させるネットワークサービス補助プログラム。
（２０）複数のサービス実行端末よりそれぞれ通知される各端末ユーザがネットワークサービスを利用しているか否かについての判断結果に基づいて前記複数のサービス実行端末にそれぞれ提供するネットワークサービスに対して配分するリソース量を決定するリソース配分決定処理と、前記リソース配分決定処理で決定されたリソース量に基づいて前記複数のサービス実行端末にそれぞれ提供するネットワークサービスに対してリソースを配分するリソース配分実行処理と、前記リソース配分実行処理により配分されるリソースを用いて前記ネットワークサービスの提供を前記複数のサービス実行端末に対して行うサービス提供処理と、を計算機に実行させるネットワークサービス制御プログラム。
（２１）サービス提供サーバより提供されるネットワークサービスを実行することで前記ネットワークサービスを端末ユーザに提供するサービス実行ステップと、自端末の状態又は自端末周囲の状態を検出する端末状態検出ステップと、前記端末状態検出ステップにおける検出結果に基づいて端末ユーザが前記ネットワークサービスを利用しているか否かを判断するサービス利用状況判断ステップと、前記サービス利用状況判断ステップにおける判断結果を前記サービス提供サーバに通知するサービス利用状況通知ステップと、を具備するサービス実行方法。
（２２）複数のサービス実行端末よりそれぞれ通知される各端末ユーザがネットワークサービスを利用しているか否かについての判断結果に基づいて前記複数のサービス実行端末にそれぞれ提供するネットワークサービスに対して配分するリソース量を決定するリソース配分決定ステップと、前記リソース配分決定ステップで決定されたリソース量に基づいて前記複数のサービス実行端末にそれぞれ提供するネットワークサービスに対してリソースを配分するリソース配分実行ステップと、前記リソース配分実行ステップにより配分されるリソースを用いて前記ネットワークサービスの提供を前記複数のサービス実行端末に対して行うサービス提供ステップと、を具備するサービス提供方法。
【符号の説明】
【０１５６】
１０ 端末群 ２０ サービス提供サーバ
３０ ネットワーク １００ 端末
１１０ サービス実行部 １２０ 端末状態検出部
１３０ サービス利用状況判断部 １４０ サービス利用状況通知部
１５０ ネットワークインタフェース ２００ サービス提供サーバ
２１０ サービス提供部 ２２０ リソース配分決定部
２３０ リソース配分実行部 ２４０ ネットワークインタフェース
３００ 端末 ３１０ ＣＰＵ
３２０ センサ群 ３３０ コンテキスト認識部
３４０ 端末情報収集制御部 ３５０ ネットワークインタフェース
３６０ ユーザ反応検知部 ３７０ 端末側アプリケーション群
４００ サービス提供サーバ ４１０ ＣＰＵ
４１５ ＯＳ ４２０ リソース配分決定部
４２１ 全端末情報管理部 ４２２ 端末サービス管理テーブル
４２３ 端末配分リソース計算部 ４２４ タイマ
４２５ モードリソース対応表 ４３０ リソース配分実行部
４４０ ネットワークインタフェース ４５０ サービスアプリケーション群
５００ 携帯端末 ５１０ ＣＰＵ
５１５ 携帯端末ＯＳ ５２１ ＧＰＳ
５２２ 加速度センサ ５２３ 時計
５５０ 無線インタフェース ５７０ 動画視聴アプリ
５８０ 端末制御アプリ ５８１ コンテキスト認識モジュール
５８２ 端末情報収集制御モジュール ５８３ ユーザ反応検知モジュール
６００ 動画配信サーバ ６１０ ＣＰＵ群
６１５ サーバＯＳ ６４０ 高速イーサネットインタフェース
６５０ 動画配信アプリ群 ６６０ サービス制御アプリ
６６１ リソース配分決定モジュール ６６２ リソース配分実行モジュール
６６３ モードリソース対応表 ６６４ 端末サービス管理テーブル
７１０ 端末コンテキストメッセージ ７１１ ユーザＩＤ
７１２ ユーザ状態 ７１３ 状態変化時刻
７２０ リソース配分決定メッセージ ７２１ ユーザＩＤ
７２２ サーバ側リソース配分決定結果 ４２２１ ユーザＩＤ
４２２２ ユーザ状態 ４２２３ サービスアプリ識別子
４２２４ 状態変化時刻 ４２２５ 目標動作モード
４２２６ 調整済動作モード
【技術分野】
【０００１】
本発明は、ネットワークサービスを提供するサーバと複数の端末とを含んで構成されるサービス制御システムに関し、特に、リソースの最適配分機能を有するサービス制御システムに関する。
【背景技術】
【０００２】
通信ネットワークを通じてサービスを提供するシステムにおいて、回線状況に合わせた適切な品質レベルのサービスを提供するために、動的リソース制御技術の開発が進められている。
【０００３】
特許文献１には、動画等のストリームを受信する端末において通信パケットのロス率を観測し、パケットロス率がある閾値を超えた場合は、当該端末へのストリーム配信のデータビットレートを低下させるストリーム配信システムが開示されている。当該技術を用いることにより、端末側における通信ネットワークの状況に応じて通信データ量を調整し、通信ネットワークリソースの有効利用を図ることができる。
【０００４】
また、特許文献２には、無線ネットワークで繋がった通信装置からなるシステムにおけるサービス最適化に関する技術が開示されている。当該技術では、各通信端末装置側で測定したネットワーク指標やネットワークアプリケーション動作性能値をネットワークサーバに集めて分析し、通信に用いる符号化方式割り当てやＱｏＳクラス特性を変更することで、通信端末ユーザの体験を改善することを試みる。すなわち、特許文献２の技術は、各端末での通信ネットワーク状況に応じて、通信方式を調整し、端末全体での通信ネットワークリソースの有効利用を図るものである。
【０００５】
また、特許文献３には、所定のユーザが異なる複数のサービスを同時に受けている場合において、これらの複数のサービスを統括的に制御するサービス制御システムが開示されている。当該技術によれば、ネットワークから取得できる様々なコンテキストから各サービスに対して共通要素となる要求特性を導出し、当該要求特性を用いて異なるサービスを比較して統括的に複数のサービスを制御することで、ユーザ志向なサービス制御が可能となる。
【０００６】
また、特許文献４には、物理計算機を複数の論理区画（ＬＰＡＲ）に分割し、各ＬＰＡＲ上で動作する各ＯＳの負荷に対応して、各ＬＰＡＲにリソースを割り当てる仮想計算機システムが開示されている。当該技術では、リソース配分を決めるにあたってＯＳの負荷だけではなく、ＯＳ上で動作するワークロード(プログラム)の情報も利用してリソースを配分することで、最適なリソース割り当てが可能となる。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００８−１１１７７号公報
【特許文献２】特表２００８−５３９６６３号公報
【特許文献３】特開２００５−１００３２０号公報
【特許文献４】特開２００７−２００３４６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
通信事業者により定額制やそれに近い通信料金プランが提供され、また、端末装置の高機能化と大画面化が進むにつれ、ユーザはいくつものアプリケーションを端末上で起動したまま放置する傾向にある。例えば、動画再生アプリケーションを起動したままユーザが端末のそばを離れたり、端末を鞄にしまったりすると、ユーザは既にそのサービスを享受しなくなっているが、サーバ、ネットワーク、及び端末のリソースは消費され続けている。これは電力消費の観点および通信コストの観点で問題となる。
【０００９】
また、このような無駄なリソース消費が発生することにより、リソース逼迫時に、真にサービスを受けたいと希望しているユーザに対して十分なリソースを割けないという課題が生じている。
【００１０】
このような課題は、通信事業者のサービス提供プランの変化や無線通信規格の高速化などを契機としてここ近年で新たに生じた課題であり、上記従来の技術ではこのような課題に適切に対応することができなかった。
【００１１】
すなわち、特許文献１や特許文献２の技術では、通信品質に応じたリソース制御は行えるものの、ユーザに利用されないサービスに対しても、サーバ及びネットワークのリソースを消費してしまうという課題を解決することはできない。また、特許文献３の技術は、特定のユーザが複数の異なるサービスを同時利用している場合に、これらの各サービスに対するユーザの要求特性に応じた統計的制御は可能となるものの、やはり、複数ユーザが限られたリソースを共用している場合に、ユーザに利用されないサービスにリソースが消費されるという課題を解決することはできない。また、特許文献４の技術を持ってしても、仮想計算機のリソース配分を最適化できるに留まり、上記の課題を解決することはできなかった。
【００１２】
本発明は上記課題を鑑み、サービスを享受しようとしていないユーザに対するサービス提供のために割かれるサーバ又はネットワークのリソースを削減することを目的とする。
【課題を解決するための手段】
【００１３】
本発明のサービス制御システムは、ネットワークサービスの提供を行うサービス提供サーバと、前記ネットワークサービスの提供を受ける複数のサービス実行端末と、を備えるサービス制御システムであって、前記サービス実行端末は、前記サービス提供サーバより提供されるネットワークサービスを実行することで前記ネットワークサービスを端末ユーザに提供するサービス実行手段と、自端末の状態又は自端末周囲の状態を検出する端末状態検出手段と、前記端末状態検出手段における検出結果に基づいて前記端末ユーザが前記ネットワークサービスを利用しているか否かを判断するサービス利用状況判断手段と、前記サービス利用状況判断手段における判断結果を前記サービス提供サーバに通知するサービス利用状況通知手段と、を具備し、前記サービス提供サーバは、前記サービス実行端末より通知された前記判断結果に基づいて前記サービス実行端末に提供するネットワークサービスに対して配分するリソース量を決定するリソース配分決定手段と、前記リソース配分決定手段で決定されたリソース量に基づいて前記サービス実行端末に提供するネットワークサービスに対してリソースを配分するリソース配分実行手段と、前記リソース配分実行手段により配分されるリソースを用いてネットワークサービスの提供を前記サービス実行端末に対して行うサービス提供手段と、を具備する。
【００１４】
また、本発明のサービス実行端末は、サービス提供サーバより提供されるネットワークサービスを実行することで前記ネットワークサービスを端末ユーザに提供するサービス実行手段と、自端末の状態又は自端末周囲の状態を検出する端末状態検出手段と、前記端末状態検出手段における検出結果に基づいて端末ユーザが前記ネットワークサービスを利用しているか否かを判断するサービス利用状況判断手段と、前記サービス利用状況判断手段における判断結果を前記サービス提供サーバに通知するサービス利用状況通知手段と、 を具備する。
【００１５】
また、本発明のサービス提供サーバは、複数のサービス実行端末よりそれぞれ通知される各端末ユーザがネットワークサービスを利用しているか否かについての判断結果に基づいて前記複数のサービス実行端末にそれぞれ提供するネットワークサービスに対して配分するリソース量を決定するリソース配分決定手段と、前記リソース配分決定手段で決定されたリソース量に基づいて前記複数のサービス実行端末にそれぞれ提供するネットワークサービスに対してリソースを配分するリソース配分実行手段と、前記リソース配分実行手段により配分されるリソースを用いて前記ネットワークサービスの提供を前記複数のサービス実行端末に対して行うサービス提供手段と、を具備する。
【発明の効果】
【００１６】
本発明によれば、サービスを享受しようとしていないユーザに対するサービス提供のために割かれるサーバ又はネットワークのリソースを削減することが可能となる。
【図面の簡単な説明】
【００１７】
【図１】本発明の全体構成を示すシステム図である。
【図２】実施の形態１に係る端末及びサーバの具体的構成を示すブロック図である。
【図３】実施の形態２に係る端末及びサーバの具体的構成を示すブロック図である。
【図４】端末からサーバに送られる端末コンテキストメッセージの構造を示す図である。
【図５】サーバから端末に送られるリソース配分決定メッセージの構造を示す図である。
【図６】実施の形態２に係るリソース配分決定部の内部構成を示すプロック図である。
【図７】実施の形態２に係る端末サービス管理テーブル内のテーブルエントリの構造を示す図である。
【図８】実施の形態２に係るモードリソース対応表の構造を示す図である。
【図９】実施の形態２に係るリソース計算手順を示すフローチャート図である。
【図１０】実施の形態２に係るサービス実行端末のサービス享受状態判断処理の流れを示すフローチャート図である。
【図１１】実施の形態２に係るサービス実行端末のユーザ反応調査モード変更処理の流れを示すフローチャート図である。
【図１２】実施の形態２に係るサービス実行端末の不満動作検出処理の流れを示すフローチャート図である。
【図１３】実施の形態２に係るサービス提供サーバの動作を示すフローチャート図である。
【図１４】実施の形態２に係る別のリソース計算手順を示すフローチャート図である。
【図１５】本発明の実施例における端末の具体的構成を示すブロック図である。
【図１６】本発明の実施例におけるサーバの具体的構成を示すブロック図である。
【図１７】本発明の実施例における、サービスアプリケーションのモードリソース対応表である。
【図１８】本発明の実施例における端末サービス管理テーブルの構成と具体内容例を示す図である。
【図１９】本発明の実施例におけるリソース配分計算過程を説明する図である。
【図２０】本発明の実施例におけるリソース配分計算過程を説明する図である。
【図２１】本発明の実施例におけるリソース配分計算過程を説明する図である。
【発明を実施するための形態】
【００１８】
本発明に係るネットワークサービス制御システムは、限られたリソースを用いてネットワークサービスを複数の端末ユーザに提供するシステムであって、実際にネットワークサービスを享受している端末ユーザに対して適切にリソースを割り当てることを可能とするシステムである。
【００１９】
図１は、本発明に係るネットワークサービス制御システムの全体構成を示すシステム図である。本発明に係るネットワークサービス制御システムは、ネットワークサービスを提供するサービス提供サーバ２０と、ネットワークサービスを利用する端末群１０と、これらを相互に接続する有線ないし無線のネットワーク３０と、を含んで構成される。以下、本発明の各実施の形態について図面を参照して詳細に説明する。
（実施の形態１）
【００２０】
図２は、本実施の形態１にかかるネットワークサービス制御システムを構成する端末１００とサービス提供サーバ２００の具体的構成を示すブロック図である。以下、各部の機能について詳細に説明する。
【００２１】
まず、端末１００の構成について説明する。端末１００は、サービス実行部１１０と、端末状態検出部１２０と、サービス利用状況判断部１３０と、サービス利用状況通知部１４０と、ネットワークインタフェース（ＮＷＩ／Ｆ）１５０と、を備える。
【００２２】
サービス実行部１１０は、サービス提供サーバ２００より提供されるネットワークサービスを実行する。具体的には、端末１００が具備するＣＰＵ（Central Processing Unit）及びＯＳ（Operating
System）上で動作する端末側アプリケーションが、サービス提供サーバ２００より提供されるネットワークサービスを実行し、当該ネットワークサービスを端末ユーザに提供する。
【００２３】
端末状態検出部１２０は、自端末の状態をセンシングすることで端末状態を検出する。端末状態検出部１２０は、具体的には、加速度センサ、傾きセンサ、光センサなどで構成され、当該センサで得られる端末状態についての検出結果をサービス利用状況判断部１３０に出力する。なお、ここでいう端末状態には、光センサで検出される自端末周囲の明るさ等、自端末周囲の状態も含まれるものとする。
【００２４】
サービス利用状況判断部１３０は、端末状態検出部１２０より出力された検出結果を基に、端末ユーザのサービス利用状況を判断する。具体的には、サービス利用状況判断部１３０は、端末状態検出部１２０から入力した端末状態の検出結果に基づいてユーザの動作状態などユーザ状況を把握し、所定のアルゴリズムに従って、端末ユーザが自端末１００を通じてネットワークサービスを享受しているか否か、すなわち、ネットワークサービスを利用しているか否かを判断する。サービス利用状況判断部１３０は、ユーザがネットワークサービスを利用しているか否かについての判断結果をコンテキスト情報としてサービス利用状況通知部１４０に出力する。
【００２５】
サービス利用状況通知部１４０は、サービス利用状況判断部１３０より入力した端末ユーザがネットワークサービスを利用しているか否かの判断結果を、必要に応じてサービス提供サーバ２００に通知する。例えば、サービス利用状況通知部１４０は、サービス利用状況判断部１３０から入力した上記端末ユーザがネットワークサービスを利用しているか否かの判断結果に変化が生じている場合は、当該判断結果を含むコンテキスト情報をサービス提供サーバ２００に通知する。
【００２６】
ネットワークインタフェース１５０は、自端末１００がネットワーク３０を介してサービス提供サーバと通信するための通信インタフェースである。端末１００は、ネットワークインタフェース１５０を介してネットワークサービスの提供を受け、また、コンテキスト情報の送信等を行う。
【００２７】
次に、サービス提供サーバ２００の構成について説明する。サービス提供サーバ２００は、サービス提供部２１０と、リソース配分決定部２２０と、リソース配分実行部２３０と、ネットワークインタフェース（ＮＷＩ／Ｆ）２４０と、を備える。
【００２８】
サービス提供部２１０は、リソース配分実行部２３０におけるリソース配分制御に従い、ネットワークインタフェース２４０を介して各端末にネットワークサービスの提供を行う。
【００２９】
リソース配分決定部２２０は、ネットワークサービスを利用している複数の端末から通知される端末ユーザがネットワークサービスを利用しているか否かの判断結果を、ネットワークインタフェース２４０を介して受信し、当該判断結果に基づいてリソースの配分を決定する。
【００３０】
具体的には、リソース配分決定部２２０は、各端末から通知される上記判断結果を含むコンテキスト情報を収集し、サービス享受していない（ネットワークサービスを利用していない）ユーザ向けのネットワークサービスに対して配分しているリソース量を減らし、サービス享受している（ネットワークサービスを利用している）ユーザ向けのネットワークサービスに対して配分しているリソース量を相対的に増やす決定を行う。なお、ここでいうリソースとは、サービス提供サーバのＣＰＵやＯＳといったサーバ内リソースの他、サービスを利用する端末とサービス提供サーバ間の無線通信帯域のリソースなど、ネットワークサービス提供に必要となるリソースを言う。従って、ネットワークサービスに配分されるリソース量が減らされると、一般的に当該サービスの品質レベルが下がることになる。リソース配分決定部２２０は、リソース配分決定結果をリソース配分実行部２３０に通知し、リソース配分の指示を行う。
【００３１】
リソース配分実行部２３０は、リソース配分決定部２２０から指示されたリソース配分に従って、サービス提供部２１０が各端末にそれぞれ提供するネットワークサービスに対してＣＰＵやＯＳと言ったリソースを配分する。具体的には、リソース配分実行部２３０は、リソース配分決定部２２０から指示されたリソース配分に従って、サービス提供部２１０におけるネットワークサービス提供で消費されるリソースの具体的なリソース配分操作を行う。例えば、リソース配分決定部２２０よりサービス享受していないユーザ向けサービスに配分しているリソース量を減らす指示を受けた場合は、リソース配分実行部２３０は、当該サービスに割り当てているリソース量を減らす制御を行う。サービス提供部２１０は、このようにして配分されたリソースを使用して各端末にネットワークサービスを提供する。
【００３２】
以上説明したように、本実施の形態１におけるネットワークサービス制御システムは、ネットワークサービスの提供を行うサービス提供サーバ及びネットワークサービスの提供を受ける複数のサービス実行端末を含んで構成される。そして、サービス実行端末は、サービス提供サーバより提供されるネットワークサービスを実行することでネットワークサービスを端末ユーザに提供するサービス実行手段と、自端末の状態又は自端末周囲の状態を検出する端末状態検出手段と、端末状態検出手段における検出結果に基づいて端末ユーザがネットワークサービスを利用しているか否か、すなわちネットワークサービスを享受しているか否かを判断するサービス利用状況判断手段と、サービス利用状況判断手段における判断結果をサービス提供サーバに通知するサービス利用状況通知手段と、を具備する。一方、サービス提供サーバは、サービス利用端末より通知された判断結果に基づいてリソース配分を決定するリソース配分決定手段と、リソース配分決定手段で決定されたリソース配分に従ってサービス利用端末に提供するネットワークサービスに対してリソースを配分するリソース配分実行手段と、リソース配分実行手段により配分されるリソースを用いてネットワークサービスの提供をサービス実行端末に対して行うサービス提供手段と、を具備する。
【００３３】
このような構成とすることで、各端末は、自ユーザの状況を把握してネットワークサービスを享受しているかどうかの判断を行い、判断結果をサーバ側に通知する。限られたリソースを各端末に配分しながらサービス提供を行うサービス提供サーバは、これらの通知に基づいて、リソースの配分割合を操作し、ネットワークサービスを享受していないユーザに対するリソース割り当てを低下させる一方、ネットワークサービスを享受しているユーザに対して適切なリソース割り当てを行う。
【００３４】
従って、例えば、端末ユーザがネットワークサービスを実行しているアプリケーションを端末上で起動したまま放置し、リソースの消費が発生する場合においても、サーバ側でこのようなユーザに対するリソース配分を下げ、空いたリソースを真にサービスを享受している他のユーザに対して適切に割り当てることが可能となる。
【００３５】
また、このような構成とすることで、無駄なリソース消費を抑えることが可能となるため、サーバ及び端末でそれぞれ消費される電力を削減することができるとともに、ネットワークにおける通信コストの削減も可能となる。
【００３６】
（実施の形態２）
本実施の形態２に係るネットワークサービス制御システムは、実施の形態１に係るネットワークサービス制御システムに加えて、リソース調整に起因して発せられたユーザの不満動作を捉え、リソースの再配分を行う構成を更に備える。以下、本実施の形態２に係るネットワークサービス制御システムについて図面を用いて説明する。
【００３７】
図３は、本実施の形態２に係るネットワークサービス制御システムの具体的構成を示す図である。ネットワークサービス制御システムは、ネットワークサービスの提供を受ける複数の端末３００と、ネットワークサービスの提供を行うサービス提供サーバ４００と含んで構成される。
【００３８】
まず、端末３００の構成について説明する。端末３００は、ＣＰＵ３１０と、センサ群３２０と、コンテキスト認識部３３０と、端末情報収集制御部３４０と、ネットワークインタフェース（ＮＷＩ／Ｆ）３５０と、ユーザ反応検知部３６０と、端末側アプリケーション群３７０と、を備える。
【００３９】
ここで、コンテキスト認識部３３０、ユーザ反応検知部３６０、端末情報収集制御部３４０、端末側アプリケーション群３７０は、端末ＣＰＵ３１０上で動作するソフトウェアを用いて実現することが可能である。これらのソフトウェア動作には通常、主記憶メモリ、不揮発メモリ（Ｆｌａｓｈメモリ等）、ＯＳ等が必要になるが、これらはコンピュータシステム一般に用いられるものであり、ここではあらためて図示しないが、端末３００は当然に備えているものである。
【００４０】
なお、ＣＰＵ３１０上で動作する端末アプリケーション群３７０が、図２のサービス実行部１１０に対応する。また、センサ群３２０、コンテキスト認識部３３０、端末情報収集制御部３４０、ＮＷＩ／Ｆ３５０は、それぞれ図２の端末状態検出部１２０、サービス利用状況判断部１３０、サービス利用状況通知部１４０、ＮＷＩ／Ｆ１５０に対応している。以下、各部の機能について詳細に説明する。但し、図２で説明した部分については一部説明を省略する。
【００４１】
ＣＰＵ３１０は、ネットワークサービスに対応するアプリケーションである端末側アプリケーションを実行することで、サーバより提供されるネットワークサービスを実行し、当該サービスをユーザに提供する。
【００４２】
センサ群３２０は、複数のセンサで構成され、当該センサを用いてセンシングを行い、自端末の状態又は自端末周囲の状態を検出する。センサ群３２０は、具体的には、ＧＰＳを利用して自端末の現在位置を検出する位置センサ、自端末の加速度を検出する加速度センサ、自端末の傾きを検出する傾きセンサ、自端末周囲の明るさを検出する光センサ等の各種センサを一つ又は複数組み合わせて構成される。なお、センサ群３２０を構成するセンサは上記センサに限定されるものではなく、ユーザが自端末に触れていることを検出する触覚センサの他、端末周囲を撮影する端末内蔵カメラ、端末周囲の音声を検出するマイクなども合わせてセンサとして利用することができる。センサ群３２０を構成するこれら各センサにおける端末状態の検出結果は、コンテキスト認識部３３０及びユーザ反応検知部３６０に送られる。
【００４３】
コンテキスト認識部３３０は、前記センサ群３２０から受け取った検出結果に基づいてユーザの状況を把握する。具体的には、コンテキスト認識部３３０は、センサ群３２０を使用してユーザの振る舞いや端末の状況を推測し、ユーザが自端末を通じてサービスを享受している状態であるか否かを判断する。コンテキスト認識部３３０は、当該判断結果をコンテキスト情報として端末情報収集制御部３４０に送る。
【００４４】
端末情報収集制御部３４０は、コンテキスト認識部３３０及びユーザ反応検知部３６０を制御して端末側の情報収集を行う。端末情報収集制御部３４０は、コンテキスト認識部３３０から得たコンテキスト情報を一時蓄積し、ユーザ状態が変化したタイミングで、当該コンテキスト情報とユーザＩＤとをあわせて端末コンテキストメッセージを作成する。端末情報収集制御部３４０は、当該端末コンテキストメッセージをネットワークインタフェース３５０を介してサービス提供サーバ４００へ送信する。
【００４５】
図４に端末コンテキストメッセージ７１０の一例を示す。端末コンテキストメッセージ７１０は、ユーザＩＤ７１１と、ユーザ状態（コンテキスト情報）７１２と、状態変化時刻７１３と、を含む。ここで、ユーザＩＤ７１１には、サービス提供サーバ４００が各端末のユーザにユニークに付与している識別子が設定される。当該ユーザＩＤは通常、ユーザがサービス提供者にサービス提供を申し込む際にサービス事業者が割り当てるものである。ユーザ状態７１２部分には、コンテキスト認識部３３０より送られたコンテキスト情報が格納される。具体的には、ユーザ状態７１２部分には、「活動中」あるいは「非活動中」の値が設定され、それぞれ「ユーザが当該サービスを享受している」「していない」に対応している。また、状態変化時刻７１３には、端末１００が内蔵する時計が刻む日付及び時刻の現在値が、ユーザ状態が変化した時刻として設定される。
【００４６】
また、端末情報収集制御部３４０は、ユーザ反応検知部３６０から、ユーザからの不満動作が認識されたことを示す結果が送られた場合は、当該結果をコンテキスト情報として端末コンテキストメッセージを作成し、サービス提供サーバ４００へ送信する。この場合の端末コンテキストメッセージ内のユーザ状態７１２には、「活動中」の値が記されている。
【００４７】
また、端末情報収集制御部３４０は、後述するリソース配分決定メッセージをサービス提供サーバ４００より受け取った場合は、当該メッセージで示される内容に従って、ユーザ反応検知部３６０に対してユーザが不満動作（反論動作）を行っているかの認識処理の開始を指示する。
【００４８】
ネットワークインタフェース３５０は、端末３００がネットワーク３０を介してサービス提供サーバ４００と通信するための通信インタフェースである。
【００４９】
ユーザ反応検知部３６０は、センサ群３２０を構成する各センサの一部又は全部と接続されており、当該センサ群から入力した端末状態等の検出結果に基づいて、ユーザが特定の反応を行っているかを認識する処理を行う。
【００５０】
具体的には、ユーザ反応検知部３６０は、「ユーザ反応調査中」及び「ユーザ反応調査停止中」の２つの動作状態（ユーザ反応調査モード）を持ち、端末情報収集制御部３４０からの制御に従ってこれらの動作状態を切り替える。すなわち、ユーザ反応検知部３６０は、端末情報収集制御部３４０から「ユーザ反応調査の停止」を指示されると「ユーザ反応調査停止中」状態に遷移し、「ユーザ反応調査の開始」を指示されると「ユーザ反応調査中」状態に遷移する。
【００５１】
ユーザ反応検知部３６０は、その動作状態が「ユーザ反応調査中」である間、ユーザが不満動作（反論動作）を行っているかの認識処理を継続して行う。すなわち、ユーザ反応検知部３６０は、ネットワークサービスの品質レベルの低下に対するユーザの不満動作、反論動作を認識する。ユーザ反応検知部３６０は、これらの不満動作を捉えたタイミングで、「ユーザは当該サービスを享受している」ことを示す情報を端末情報収集制御部３４０に送る。
【００５２】
端末側アプリケーション群３７０は、サービス提供サーバ４００より提供される各種ネットワークサービスに対応したソフトウェアであり、ＣＰＵ３１０及びＯＳ上で動作する。端末側アプリケーション群３７０は、ネットワークサービスを複数の品質レベルで前記端末ユーザに対して提供可能であり、サービス提供サーバが行うリソース制御に基づく品質レベルで提供されるネットワークサービスを実行し、ネットワークサービスを端末ユーザに提供する。
【００５３】
また、端末側アプリケーション群３７０は、ユーザからの入力等をトリガーとしてネットワークサービスの開始を要求するネットワークサービス開始要求メッセージを、ネットワークインタフェース３５０を介してサービス提供サーバ４００に送信する。なお、当該ネットワークサービス開始要求メッセージには、ユーザＩＤ、現在の時刻、要求するネットワークサービスの内容を指定する情報等が含まれる。当該メッセージを受け取ったサービス提供サーバ４００は、当該端末ユーザに対するネットワークサービスの提供を開始する。その後、端末側アプリケーションがサービス提供サーバより提供されるネットワークサービスを実行することにより、当該ネットワークサービスがユーザに提供される。
【００５４】
次に、サービス提供サーバ４００の構成について説明する。サービス提供サーバ４００は、１つ以上のＣＰＵ４１０と、ＯＳ４１５と、リソース配分決定部４２０と、リソース配分実行部４３０と、ネットワークインタフェース（ＮＷＩ／Ｆ）４４０と、サービスアプリケーション群４５０と、を備える。
【００５５】
端末３００と同様、これらの構成要素の一部はソフトウェアとして実現されることが通例であり、サービス提供サーバ４００はそのために必要な主記憶メモリ、不揮発メモリ等を当然に備える。
【００５６】
なお、当該ＣＰＵ４１０及びＯＳ４１５上で動作するサービスアプリケーション群４５０が、図２のサービス提供部２１０に対応する。また、リソース配分決定部４２０及びリソース配分実行部４３０が、それぞれ図２のリソース配分決定部２２０及びリソース配分実行部２３０に対応する。
【００５７】
ＣＰＵ４１０は、サービスアプリケーション群４５０を実行することで、各ユーザより要求されているネットワークサービスを提供する。
【００５８】
ＯＳ４１５は、ＣＰＵ４１０上で動作し、サービスアプリケーション群４５０のタスク管理等を行う。
【００５９】
リソース配分決定部４２０は、各端末から送信されたコンテキスト情報に基づいて各端末へのリソース配分を決定する。すなわち、リソース配分決定部４２０は、各端末からのコンテキスト情報を収集し、サービス享受していないユーザ向けサービスに配分しているリソース量を減らし、サービス享受しているユーザ向けサービスに配分しているリソース量を相対的に増やす決定を行う。リソース配分決定部４２０は、決定したリソース配分決定結果をリソース配分実行部４３０に通知する。また、リソース配分決定部４２０は、前記リソース配分決定結果を、リソース配分決定メッセージとして端末３００に送信する。
【００６０】
図５は、リソース配分決定メッセージ７２０の一例を示している。リソース配分決定メッセージ７２０は、ユーザＩＤ７２１とサーバ側リソース配分決定結果７２２とが含まれる。ここで、ユーザＩＤ７２１は、各ユーザを識別するＩＤであり、サーバ側リソース配分決定結果７２２は、後述するリソース配分決定処理に基づいて決定されたリソース配分の結果を示している。具体的には、サーバ側リソース配分決定結果７２２には、ユーザがサービスを享受しているとして通常の品質レベルに対応するリソース量のリソースが配分されていることを示す「活動中」又は、ユーザがサービスを享受していないとして所定の基準値以下の品質レベルに対応するリソース量のリソースが配分されていることを示す「非活動中」のどちらかの情報が含まれている。サーバ側リソース配分決定結果７２２に「非活動中」の情報が含まれるリソース配分決定メッセージ７２０は、提供するネットワークサービスの品質レベルを下げることを示す通知となる。
【００６１】
リソース配分実行部４３０は、リソース配分決定部４２０より指示されたリソース配分に従ってサーバＣＰＵ４１０、ＯＳ４１５及びサービスアプリケーション群４５０に対する具体的なリソース配分操作を行う。具体的には、リソース配分実行部４３０は、各サービスアプリケーション群４５０やＯＳ４１５に指示して、リソース配分決定部４２０より指示された動作モードでアプリケーションを動作させる。ここでサービスアプリケーションだけでなくＯＳに対しても指示を出すのは、ＣＰＵ優先度、メモリ割り当て、ネットワーク帯域割り当て等において、アプリケーション単独では希望するリソース配分が十分行えない場合に、ＯＳ側からもリソース配分調整を行うためである。
【００６２】
また、リソース配分計算の都合上、全アプリケーションが要求するリソース量の総和がシステム全体リソース量を超えてしまっている場合は、最終調整手段としてＯＳ４１５が備える規定のリソース配分動作に委ねる。即ち、ＯＳ４１５が各アプリケーションタスクに対するリソース配分をベストエフォートで自動調整する。
【００６３】
ネットワークインタフェース４４０は、自サーバ４００がネットワーク３０を介して複数の端末と通信するための通信インタフェースである。
【００６４】
サービスアプリケーション群４５０は、リソース配分実行部４３０により配分されたリソースを用いてサーバ側でネットワークサービスを実行し、ネットワークインタフェース４４０を介して当該ネットワークサービスを各端末に提供する。
【００６５】
次に、リソース配分決定部４２０の具体的構成及びリソース配分決定動作について説明する。図６は、リソース配分決定部４２０の具体的構成を示すブロック図である。リソース配分決定部４２０は、全端末情報管理部４２１と、端末サービス管理テーブル４２２と、端末配分リソース計算部４２３と、タイマ４２４と、モードリソース対応表４２５と、を備える。
【００６６】
全端末情報管理部４２１は、サービス提供先の端末群の現在状況を管理する。具体的には、全端末情報管理部４２１は、各端末から送られてきたネットワークサービス開始要求メッセージや端末コンテキストメッセージをネットワークインタフェース４４０を介して受け取り、端末サービス管理テーブル４２２内にエントリを新規追加ないし既存エントリの更新を行う。
【００６７】
ここで、端末サービス管理テーブル４２２は、各端末ユーザの状態及びサービスレベルの方針が記録されたレコード集合体である。図７に端末サービス管理テーブル４２２の一例を示す。端末サービス管理テーブル４２２には、ユーザに固有に割り当てられたユーザＩＤ４２２１、ユーザの現在の状態を示すユーザ状態４２２２、当該ユーザ向けにサービスを提供しているサービスアプリケーションを示すサービスアプリ識別子４２２３、当該ユーザのユーザ状態が変化した時刻を示す状態変化時刻４２２４、及びサービスアプリケーションの動作モードに関する２種の値即ち目標動作モード４２２５と調整済動作モード４２２６、の各フィールドからなるレコードの集合体が記憶される。
【００６８】
ここで、動作モードとは、異なるいくつかの提供サービスレベルに対し、あるサービスアプリケーションがとる動作の形態の集合である。異なる動作モードでは、サービスレベル（サービスの品質レベル）が異なるため、サービス提供に必要となるリソース消費量も異なる。
【００６９】
一例を挙げると、提供するネットワークサービスが動画配信サービスであれば、アプリケーションは一般に配信ビットレートや解像度、ノイズ低減や色調改善処理の実施程度等をそれぞれ何段階かとることができるが、これらのうち当該サービス実現に対し妥当な組み合わせを当該アプリケーションの動作モードと呼ぶ。
【００７０】
端末サービス管理テーブル４２２に含まれる目標動作モードは端末ごとのサービスレベルの希望値を表すものであり、システム全体リソースが限定される中では必ずしもそれらの希望がすべてかなえられるわけではない。それに対し調整済動作モードはシステム全体リソース量に収まるように各端末サービス間で調整がなされた後のサービスレベルの値である。
【００７１】
モードリソース対応表４２５は、サービスアプリケーション各々の動作モードと必要リソース量との関係を記憶した管理テーブルである。アプリケーションに指示して動作モードを変更すると、当該アプリケーションが使用するリソース（例えばＣＰＵ時間やネットワーク帯域等）の量も変化するのが通例である。システム設計者はサービス運用に先立ち、設計情報及び実システム上での評価を通じて、各動作モードでの動作において当該アプリケーションが使用するリソース量を測定する。モードリソース対応表４２５には、その結果が表にして記載されている。
【００７２】
あるアプリケーションに対する動作モードは一般に複数あるが、そのうち、アプリケーションの通常動作、言い換えれば、設計されたサービスを十分に提供できる動作モードを、通常動作モードと呼ぶ。逆に、最小限の動作、言い換えれば、ユーザにサービスを享受する様子がみられない場合にアプリケーションがとるべき動作モードを、待機時動作モードと呼ぶ。動作モードの集合はサービス運用開始に先立ち、システム設計時にシステム設計者が選定するが、それらのうち、最も多くのリソースを必要とするものが通常動作モード、最もリソースが少なくて済むものが待機時動作モードとなる。
【００７３】
図８にモードリソース対応表の一例を示す。この例ではアプリケーション１において動作モードは５つあり、そのうち動作モード５が通常動作モード（図８にて"ａｃｔｉｖｅ"と表示）、動作モード１が待機時動作モード（"ｉｎａｃｔｉｖｅ"と表示）である。
【００７４】
全端末情報管理部４２１は、端末コンテキストメッセージを新たに受け取ると端末サービス管理テーブル４２２に新規追加又は更新するエントリの各フィールドに次のように値を設定する。全端末情報管理部４２１は、端末コンテキストメッセージに含まれるユーザＩＤ、ユーザ状態、状態変化時刻の値をそれぞれエントリ内のユーザＩＤ、ユーザ状態、状態変化時刻のフィールドに記録する。また、全端末情報管理部４２１は、当該端末に対するサービスを提供しているアプリケーションの識別子をエントリ内のサービスアプリのフィールドに記憶する。次に、全端末情報管理部４２１は、端末コンテキストメッセージに含まれるユーザ状態７１２が「活動中」であれば当該サービスアプリケーションの通常動作モードの値、ユーザ状態７１２が「非活動中」であれば当該サービスアプリケーションの待機時動作モードの値、をそれぞれエントリ内の目標動作モードのフィールドに記録する。なお、調整済動作モードは、リソース調整が行われた後の動作モードの値が記憶されるフィールドであり、後述する端末配分リソース計算部４２３にて値が設定される。
【００７５】
タイマ４２４は、指示されたタイミングでタイマ割込み通知を端末配分リソース計算部４２３に出す。タイマ４２４は予め、サービスレベルの再計算をするのに適した間隔でタイマ割込み通知を発行し続けるよう指示される。この適した間隔とは、ＯＳ４１５がその上のアプリケーションタスクをスケジューリングする時間間隔よりも十分長く、端末ユーザがサービスに対して人間的に知覚し、反応する時間よりも長い時間間隔であり、例えば数秒ないし数十秒程度の範囲から選定するように設定されることが好ましい。
【００７６】
端末配分リソース計算部４２３は、端末サービス管理テーブル４２２を読み込み、各端末に対するリソース配分量を再計算する。具体的には、全端末情報管理部４２１が端末サービス管理テーブル４２２のエントリを追加ないし更新したタイミング、あるいはタイマ４２４からタイマ割込み通知されたタイミングで、後述の手順で各端末向けサービスアプリケーションに対する調整済動作モードを計算する。端末配分リソース計算部４２３は、計算した調整済み動作モードの値を端末サービス管理テーブル４２２の各エントリ内の当該フィールドに設定する。また、端末配分リソース計算部４２３は、端末サービス管理テーブル４２２の各エントリの調整済動作モード４２２６の値をリソース配分実行部４３０に伝える。リソース配分実行部４３０は、当該通知される調整済動作モードの値に従ってリソース配分を実行する。
【００７７】
図９は、端末配分リソース計算部４２３における調整済動作モードの計算手順を示すフローチャートである。
【００７８】
端末配分リソース計算部４２３は、端末サービス管理テーブル４２２内の各エントリのサービスアプリ４２２３の値（以下、ＡＰｉと称す）と目標動作モード４２２５の値（以下、ＭＰｉと称す）をそれぞれ読み取る（ステップＳ１００１）。
【００７９】
次に、端末配分リソース計算部４２３は、端末サービス管理テーブル４２２内の全エントリに対する目標動作モードＭＴｉに必要なリソース量の総和Ｒｔを求める（ステップＳ１００２）。具体的には、端末配分リソース計算部４２３は、ステップＳ１００１で読み取った各端末向けサービスを実行するためのアプリケーションである上記ＡＰｉのモードリソース対応表（図８）を参照し、各エントリの目標動作モードＭＴｉに必要なリソース量Ｒｉを算出する。そして、端末配分リソース計算部４２３は、当該算出処理を全エントリに対して行うことで総和Ｒｔを求める。
【００８０】
次に、端末配分リソース計算部４２３は、リソース配分実行部４３０に問い合わせ、現時点でサーバにて利用可能なリソース量Ｒａを得る（ステップＳ１００３）。
【００８１】
端末配分リソース計算部４２３は、ステップＳ１００２で求めたＲｔの値とステップＳ１００３で得たＲａの値とを比較する（ステップＳ１００４）。
【００８２】
ステップ１００４の比較処理の結果、Ｒｔ≦Ｒａであれば、現時点では全サービス提供に対しシステム全体リソースは足りていることになる。従って、端末配分リソース計算部４２３は、各アプリケーションの目標動作モードの値ＭＰｉをそのまま各アプリケーションの調整済動作モードの値に設定する（ステップＳ１００５）。即ち、端末配分リソース計算部４２３は、端末サービス管理テーブル４２２内の各エントリに対し、目標動作モード４２２５の値を同エントリ内の調整済動作モード４２２６にそのまま設定し、リソース配分計算処理を終了する。
【００８３】
他方、ステップ１００４の比較処理の結果、Ｒｔ＞Ｒａの場合は、現時点では全サービス提供に対しシステム全体リソースは足りていないことを意味する。そこで、端末配分リソース計算部４２３は、サービス提供に必要となるリソースの総和がサーバにて利用可能なリソース量Ｒａ内に収まるように、動作モードの調整を行う。具体的には、端末配分リソース計算部４２３は、第１にリソース削減調整率Ｐｒを算出する（ステップ１００６）。ここで、リソース削減調整率Ｐｒは、システム全体としてどの程度のリソース消費量圧縮が必要かを示す値であり、次のようにして求められる。
（１） Ｐｒ＝Ｒａ÷Ｒｔ
【００８４】
次に、端末配分リソース計算部４２３は、このＰｒを用いてサービスアプリケーション毎の動作モードを修正する（ステップ１００７）。具体的には、端末配分リソース計算部４２３は、端末サービス管理テーブル４２２内の各エントリ（図７）のＡＰｉのモードリソース対応表（図８）を参照し、その表の第２列（必要リソース量）中の値がＲｉ×Ｐｒに最も近い行を選び、その行の第１列から動作モードの値を得る。ここで得た動作モード値を端末サービス管理テーブルエントリの調整済動作モードフィールド４２２６に設定し、本リソース計算手順全体を終了する。
【００８５】
上記リソース配分調整操作は、サービスアプリケーション側が希望するリソース量に対し、リソース削減調整率Ｐｒで割り掛けされたリソース量にもっとも適合する動作モードを調整済動作モードに選定する、という意味を持っている。この選定処理を端末サービス管理テーブル４２２内の全エントリに対して行うことで、本リソース計算手順全体が完了する。
【００８６】
次に、本システムの動作について説明する。まず、端末３００の動作について説明する。本発明の特徴となる端末３００の動作は、大きく分けて、サービス享受状態判断処理、ユーザ反応調査モード変更処理、不満動作検出処理の３つの処理からなる。
【００８７】
図１０は、サービス享受状態判断処理の流れを示すフローチャート図である。端末３００は、図１０に示す処理を繰り返し行うことでユーザのサービス享受状態が変化したかを判断する。具体的には、一定周期（例えば５秒毎）で発生し続けるようなタイマ割り込みを設定しておき、そのタイマ割り込みのハンドラ（割り込み処理ルーチン）として、図１０に示すフローを登録しておくことでサービス享受状態の変化の判断を継続的に行う。以下図１０に示す動作について説明する。
【００８８】
端末情報収集制御部３４０は、タイマ割り込みが入ると、未送信の端末コンテキストメッセージが一時保存されているかどうかを確認する（Ｓ２００１）。未送信の端末コンテキストメッセージが一時保存されている場合は、当該未送信端末コンテキストメッセージを送信する（Ｓ２００２）。
【００８９】
Ｓ２００１において未送信端末コンテキストメッセージが無い場合、又は、ステップ２００２で未送信端末コンテキストメッセージが送信されると、コンテキスト認識部３３０は、センサ群３２０を使ってセンシングを行い、端末の状態又は端末周囲の状態を調査する（Ｓ２００３）。ここで、コンテキスト認識部３３０が調査する端末の状態としては、例えば、位置（ＧＰＳによる）、加速度、傾き（重力加速度による）などがあり、端末周囲の状態としては、端末周囲の明るさ（照度による）やカメラで取得される画像により認識される端末周囲の状態などとすることができる。
【００９０】
コンテキスト認識部３３０は、Ｓ２００３の調査の結果に基づいて、ユーザの現在の状況を推測し、端末ユーザのサービス享受状態が変化しているかどうかを判断する（Ｓ２００４）。
【００９１】
例えば、コンテキスト認識部３３０は、加速度センサで得られる端末の加速度の時系列変化を分析することで、端末を持つユーザの動作状態、例えば走っているか/静止しているかを識別することができる。また、コンテキスト認識部３３０は、位置検出センサで得られる現在位置に関する情報と地図データとを照合することでユーザが自宅にいる/電車に乗っている/職場や学校にいる、といった識別を行うことができる。また、コンテキスト認識部３３０は、傾きセンサで得られる端末の傾きや、光検出センサで得られる端末周囲の明るさ、その他端末内部に設けられた現在時刻を算出する時刻管理部より得られる現在時刻などの情報に基づいて、ユーザが端末を手に持って利用しているかどうかのヒントを得ることができる。更には、コンテキスト認識部３３０は、端末のキーやタッチスクリーン操作頻度を監視し、また、無線ＬＡＮや３Ｇ（第３世代携帯電話）の電波状態を監視し、これらの監視結果からユーザ状態の手掛かりが得られる。また、コンテキスト認識部３３０は、端末が具備する内蔵カメラやマイクにより取得される映像や音声を分析することにより、ユーザ状態の手掛かりを得ることもできる。コンテキスト認識部３３０は、これらの識別手法をいくつか組み合わせてユーザ状態を推測し、そのとき端末３００で起動されてネットワークサービスを実行している端末側アプリケーションの種類とあわせ、端末ユーザがサービスを享受しているか否かを判断する。
【００９２】
コンテキスト認識部３３０は、Ｓ２００４における判断の結果、前回行った判断時と比べて端末ユーザのサービス享受状態が変化していない場合、一連の処理を終了する。一方、端末ユーザのサービス享受状態が変化している場合、コンテキスト認識部３３０は、端末情報収集制御部３４０に、サービス享受状態が変化したこと示すコンテキスト情報を通知し、端末情報収集制御部３４０は、当該コンテキスト情報と、ユーザＩＤと、現在の時刻を示す時刻情報とを含めて、端末コンテキストメッセージを作成する（Ｓ２００５）。
【００９３】
次に、端末情報収集制御部３４０は、サービス提供サーバ４００と通信が可能であるかを調べる（Ｓ２００６）。
【００９４】
サービス提供サーバ４００と通信が不可能な状態であれば、端末情報収集制御部３４０は、作成した端末コンテキストメッセージを一時的に保存して処理を終了する（Ｓ２００７）。
【００９５】
一方、通信が可能な状態であれば、端末情報収集制御部３４０は、ネットワークインタフェース３５０を介して、前記端末コンテキストメッセージをサービス提供サーバ４００に送信し、処理を終了する（Ｓ２００８）。
【００９６】
次に図１１に示すフローチャートを用いてユーザ反応調査モード変更処理の流れについて説明する。
【００９７】
端末情報収集制御部３４０は、サービス提供サーバ４００から自端末宛てのリソース配分決定メッセージの到着を監視する（Ｓ２１０１）。具体的には、端末情報収集制御部３４０は、ネットワークインタフェースを介してリソース配分決定メッセージを受信すると、当該メッセージに含まれるユーザＩＤ７２１の値を確認し、自端末のユーザＩＤに一致しているかどうかを確認することで、自端末宛てのリソース配分決定メッセージであるかどうかを判断する。端末情報収集制御部３４０は、当該メッセージに含まれるユーザＩＤ７２１の値が自端末のユーザＩＤに一致しない場合は、当該メッセージを破棄し、リソース配分決定メッセージの到着の監視を継続する。
【００９８】
端末情報収集制御部３４０は、自端末宛てのリソース配分決定メッセージを受信した場合、自端末に対するリソース割り当ての状況を判断する（Ｓ２１０２）。
【００９９】
具体的には、端末情報収集制御部３４０は、当該メッセージ内のサーバ側リソース配分決定結果７２２の値を確認する。サーバ側リソース配分決定結果７２２の値が「活動中」を示していない場合は、端末情報収集制御部３４０は、ユーザ反応検知部３６０に対し、非活動中ユーザ反応調査の開始を指示し、Ｓ２１０１に戻って自端末宛てのリソース配分決定メッセージの到着を監視する（ステップＳ２１０３）。一方、サーバ側リソース配分決定結果７２２の値が「活動中」を示している場合は、ユーザ反応検知部３６０に対し、非活動中ユーザ反応調査の停止を指示し、Ｓ２１０１に戻って自端末宛てのリソース配分決定メッセージの到着を監視する（ステップＳ２１０４）。
【０１００】
上記処理によりユーザ反応調査部３６０の動作モードであるユーザ反応調査モードの変更を行う。具体的には、端末状態収集制御部３４０は、ステップ２１０３及びステップ２１０４において、大域変数、共有メモリあるいはメッセージ通信等の仕組みにより、非活動中ユーザ反応調査を行うか否かのモード値をユーザ反応検知部３６０に伝える。
【０１０１】
次に図１２に示すフローチャートを用いて不満動作検出処理の流れについて説明する。
【０１０２】
ユーザ反応検知部３６０は、一定間隔ごとのタイマ割り込みで非活動中ユーザ反応調査が指示されているかどうかを判断する（Ｓ２２０１）。具体的には、ユーザ反応検知部３６０は、図１１のＳ２１０３及びＳ２１０４において端末情報収集制御部３４０が大域変数、共有メモリあるいはメッセージ通信等前述した仕組みを用いて通知したモード値を参照することで、非活動中ユーザ反応調査が指示されているか否かを判断する。
【０１０３】
Ｓ２２０１における確認の結果、非活動中ユーザ反応調査の停止が指示されている場合は、そのまま処理を終了する。一方、非活動中ユーザ反応調査の開始が指示されている場合は、非活動中ユーザ反応調査を実施する（Ｓ２２０２）。
【０１０４】
ユーザ反応検知部３６０は、ユーザ反応調査中にネットワークサービスの品質レベル低下に対するユーザの不満動作（反論動作）が発せられたかどうかを判断する（Ｓ２２０３）。例えば、ユーザ反応検知部３６０は、加速度センサを使い、短い時間間隔で加速度が振動することで端末が振られていると認識し、これをユーザの不満動作として捉えるという認識方式を用いることができる。また、ユーザ反応検知部３６０は、加速度センサで急激な加速が検出されることでユーザが端末を叩く動作を認識し、これをユーザの不満動作として捉えるという認識方式を用いることができる。
【０１０５】
ユーザ反応検知部３６０は、ユーザ反応調査中に不満動作を検出しなかった場合は、処理を終了する。一方、ユーザ反応検知部３６０は、ユーザ反応調査中に不満動作が検出された場合は、端末情報収集制御部３４０にユーザの不満動作が検出されたことを通知する。
【０１０６】
端末情報収集制御部３４０は、ユーザ反応検知部３６０より当該通知されたユーザの不満動作に関する情報をコンテキスト情報として、端末コンテキストメッセージを作成してサービス提供サーバ４００に送信し、処理を終了する（Ｓ２２０４）
【０１０７】
次に、サービス提供サーバ４００のサービス制御動作について図１３に示すフローチャートを用いて説明する。
【０１０８】
リソース配分決定部４２０は、図１０に示すＳ２００２又はＳ２００８において送信された端末コンテキストメッセージを受け取ると、内部の端末サービス管理テーブル４２２に記憶している当該端末のエントリを更新する（Ｓ３００１）。具体的には、当該エントリに含まれるユーザ状態４２２２を、端末コンテキストメッセージ７１０に含まれるユーザ状態７１２で示される状態に変更する。すなわち、端末コンテキストメッセージ７１０を受け取り、当該メッセージに含まれるユーザ状態７１２が「非活動中」である場合には、当該エントリに含まれるユーザ状態４２２２を「非活動中」に変更する。そして、当該エントリに含まれる目標動作モード４２２５の値を待機時動作モードの値に変更する。一方、当該メッセージに含まれるユーザ状態７１２が「活動中」である場合には、当該エントリに含まれるユーザ状態４２２２を「活動中」に変更する。そして、当該エントリに含まれる目標動作モード４２２５の値を通常動作モードの値に設定する。
【０１０９】
次に、リソース配分決定部４２０は、図９で説明したフローチャートに従ってリソース配分を計算する（Ｓ３００２）。リソース配分決定部４２０は、計算結果をリソース配分実行部４３０に通知する。
【０１１０】
リソース配分実行部４３０は、通知されたリソース配分に従ってリソースを配分する（Ｓ３００３）。
【０１１１】
各サービスアプリケーション４５０は、リソース配分実行部４３０で実行されるリソース配分に従い、ネットワークサービスを提供する（Ｓ３００４）。
【０１１２】
リソース配分決定部４２０は、Ｓ３００２で決定したリソース配分結果を対応する端末に通知する（Ｓ３００５）。
【０１１３】
以上説明したように、本実施の形態では、端末側のセンサ等を用いてユーザ及び端末の状況を推測・判断し、その情報をサービス提供サーバ側に集めることで、各端末に対するサービスへのリソース配分量を変化させている。特に、サービスを享受していないユーザ向けのサービスに対するリソース配分量を時間的に漸減させ、また、サービスを享受している意思を表明したユーザ向けのサービスに対してはリソース配分量を復元させている。
【０１１４】
上記構成により、サービス提供側のサーバ及びネットワークリソースの消費電力及び通信コストの削減、並びに、サービスを真に享受しようとしているユーザに対するリソース集中配分によるサービス品質向上、という本発明の効果が得られる。
【０１１５】
その理由は、サービス提供サーバ側において、それぞれの端末側で取得された各端末ユーザの状況を受け取ることで当該状況を知り、端末側で最終的に利用されていないサービスに対してサーバ及びネットワークで割り当てているリソースを減らすことができるようになるためである。例えば、サーバのＣＰＵリソースを減らせば消費電力削減につながり、ネットワークを介して配信するデータ量を減らせばサービス提供者がネットワーク運用者に支払う通信費用を低減するとともに、サーバ運用者やネットワーク運用者が保有するネットワーク装置の消費電力抑制に寄与することになる。
【０１１６】
なお、上記説明では、リソース配分決定部４２０が、ネットワークサービスを享受していないことを示す端末コンテキストメッセージを受け取った場合に、エントリ内の目標動作モードの値を待機時動作モードの値に設定し、当該設定後の各エントリを用いてリソース配分を決定する場合について説明したが、これに限るものではない。
【０１１７】
図１４は、リソース配分決定部４２０におけるリソース配分決定の別の処理動作を示すフローチャートである。なお、端末配分リソース計算部４２３が本フローチャートに従ってリソース配分計算を行う場合は、全端末情報管理部４２１は、「非活動中」を示す端末コンテキストメッセージを受け取っても、エントリに含まれるユーザ状態を「非活動中」に設定するに留まり、目標動作モードは通常動作モードのままに設定しておく。
【０１１８】
図１４のＳ４００１〜Ｓ４００５は、図９のＳ１００１〜Ｓ１００５と同一であるため説明を省略する。Ｓ４００４においてＲｔ＞Ｒａである場合は、端末配分リソース計算部４２３は、端末サービス管理テーブル４２２に記録されているエントリのうち、ユーザ状態が「非活動中」であるエントリの目標動作モードの値（ＭＰｉ）を待機時動作モードの値に設定する（Ｓ４００６）。
【０１１９】
端末配分リソース計算部４２３は、Ｓ４００６において全ての「非活動中」のエントリの目標動作モードを待機時動作モードの値に変更した後、必要リソースの総和Ｒｔ′を改めて算出する（Ｓ４００７）。
【０１２０】
端末配分リソース計算部４２３は、Ｓ４００７でユーザ状態を反映させて再計算した必要リソースの総和Ｒｔ′と利用可能なリソース量Ｒａを再度比較する（Ｓ４００８）。
【０１２１】
端末配分リソース計算部４２３は、比較の結果Ｒｔ′≦Ｒａである場合は、Ｓ４００５と同様、ＭＰｉの値を調整済み動作モードフィールドに設定し、計算処理を終了する（Ｓ４００９）。
【０１２２】
一方、比較の結果Ｒｔ′＞Ｒａである場合は、端末配分リソース計算部４２３はＰｒ′を算出する（Ｓ４０１０）。ここでリソース削減調整率Ｐｒ′はＰｒ同様以下の式で求められる。
（２） Ｐｒ′＝Ｒａ÷Ｒｔ′
【０１２３】
次に、端末配分リソース計算部４２３は、図９のＳ１００７同様、リソース削減調整率Ｐｒ′を用いてサービスアプリケーション毎の動作モードを修正する（Ｓ４０１１）。
【０１２４】
次に、端末配分リソース計算部４２３は、修正した動作モードの値を調整済動作モード４２２６に設定し、計算処理を終了する（Ｓ４０１２）。
【０１２５】
上記計算手順に従ってリソース配分を計算することで、リソース逼迫時にユーザ状態を考慮したリソース配分を行うため、リソース逼迫時においてもネットワークサービスを享受しているユーザに適切にリソースを割り当てることができる。また、このような計算方法を用いることにより、端末がユーザ状態を誤って認識し、誤ったサービス利用状況に関する情報を含む端末コンテキストメッセージを送信しても、サーバ側でリソースに余裕がある場合は、このようなユーザに対するネットワークサービスの品質は維持される。従って、端末がユーザ状態を誤って判断し、ネットワークサービスの品質が下げられることでユーザの不満動作が発せられるといった事態を減らすことができる。
【０１２６】
次に、具体的な実施例を用いて本発明を実施するための最良の形態の動作を説明する。
【０１２７】
（実施例１）
本実施例に係るネットワークサービス制御システムは、図１に示したように１台のサービス提供サーバと複数の端末とを含んで構成され、当該サービス提供サーバは、ネットワークサービスとして具体的に動画配信サービスを携帯端末に対して提供する。すなわち、本実施例におけるネットワークサービス制御システムにおいて、サービス提供サーバは動画配信サーバであり、端末は動画配信を視聴可能な携帯端末である。
【０１２８】
図１５は本実施例において動画配信を受ける携帯端末５００の実現形態を示した図である。携帯端末５００は、ハードウェアとして、携帯端末用ＣＰＵ５１０と、ＧＰＳ５２１と、加速度センサ５２２と、時計５２３と、３Ｇ公衆無線サービスと屋内ワイヤレスＬＡＮに対応した無線インタフェース５５０及びそれに付属するアンテナと、を備える。また携帯端末５００は、ソフトウェアとして、携帯端末用ＯＳ５１５と、動画配信サーバから受信した動画ストリームを再生する動画視聴アプリ５７０と、本発明の主たる構成要素のひとつとなる端末制御アプリ５８０と、を備える。本発明の実施の形態２で説明したコンテキスト認識部、及び端末情報収集制御部、ユーザ反応検知部、は、いずれもそれらをソフトウェアとして実現したモジュール（図１５の５８１、５８２、及び５８３）として端末制御アプリ５８０の中に実装される。
【０１２９】
コンテキスト認識モジュール５８１は、ＧＰＳ５２１から得た位置情報と、加速度センサ５２２から得た端末の動きと、及び時計５２３から得た現在日時と、を用いてユーザの状況を判断する。
【０１３０】
例えば、時計５２３から得た現在日時が平日の朝夕の時間帯内であり、ＧＰＳから取得した現在の位置情報が予め登録している自宅及び勤務先との間を示しており、加速度センサから得られる直近１０秒間の加速度が徒歩ないし電車乗車中ないしバス乗車中の加速度波形と高い類似度を示す場合は、非活動中と判断する。また、平日の日中で、位置情報が勤務先にある場合は、非活動中と判断する。また、深夜０時から朝６時までの間で、直近１０秒間の加速度が０の場合は、非活動中と判断する。一方、条件に合致しない場合は、活動中と判断する。いずれの場合も、活動中と非活動中との間で状態変化があった場合、コンテキスト認識モジュール５８１は、端末情報収集制御モジュール５８２にその変化を通知する。
【０１３１】
なお、上述のユーザ状況判断条件は、サービスの種類やユーザの行動特性（会社員か学生か高齢者か）等の情報をあわせて適切なものに変更すべきであることは言うまでもない。すなわち、ユーザの行動特性に関する情報やユーザが設定した設定情報を予め図示せぬ記憶部に記憶しておき、コンテキスト認識モジュール５８１は、ユーザ状況の把握に当該記憶部に記憶されている上記情報を参照してもよい。
【０１３２】
ユーザ反応検知モジュール５８３は、端末情報収集制御モジュール５８２から非活動中ユーザ反応調査の開始を指示された場合、加速度センサ５２２の出力を監視し、急激で大きな加速度変化を観測した場合は、端末情報収集制御モジュール５８２に対し、活動中への状態遷移を通知する。
【０１３３】
端末情報収集制御モジュール５８２は、無線インタフェース５５０から電波状態を調べ、屋内ワイヤレスＬＡＮによる通信が可能であればそれを使い、屋内ワイヤレスＬＡＮが使えなければ３Ｇ公衆無線サービスを使って、ユーザの活動中及び非活動中の状態変化を端末コンテキストメッセージに纏めて動画配信サーバに送る。
【０１３４】
図１６は、動画配信サーバ６００の実現形態を示した図である。動画配信サーバ６００は、ハードウェアとして、サーバ用ＣＰＵ群６１０と、高速イーサネットインタフェース６４０（イーサネットは登録商標。以下省略。）とを備える。高速イーサネットインタフェース６４０は、外部の通信ネットワーク網に接続されており、サービス対象の携帯端末と通信できるようになっている。
【０１３５】
動画配信サーバ６００は、ソフトウェアとして、サーバ用ＯＳ６１５と、サービスを実施する動画配信アプリ群６５０と、本発明の主たる構成要素のひとつとなるサービス制御アプリ６６０と、を備える。本発明の実施の形態２で説明したリソース配分決定部、リソース配分実行部は、いずれも、それらをソフトウェアとして実現したモジュールとしてサービス制御アプリ６６０内部に実装される。具体的には、サービス制御アプリ６６０には、リソース配分決定モジュール６６１、リソース配分実行モジュール６６２、モードリソース対応表６６３、端末サービス管理テーブル６６４がそれぞれ実装されている。
【０１３６】
動画配信アプリ群６５０は、複数の動作モードを有し、リソース配分実行モジュール６６２からの指示によりそのいずれかの動作モードで動作する。サーバ用ＯＳ６１５は、動画配信アプリ群６５０で使われなかったリソースについては時間的に省電力状態にする（例えば使われていない期間は省電力モードに切り替えるか、電源供給を止める）か、あるいは空間的に省電力状態にする（例えば使われていない部分を省電力モードに切り替えるか電源供給を止める）という動的省電力機構を備える。
【０１３７】
リソース配分決定モジュール６６１の構成と動作は、先に説明したリソース配分決定部４２０の構成と動作と機能的に同様であるが、本実施例では、サーバ側のリソース量の計算に際してＣＰＵリソースとネットワークリソース（以下ＮＷリソースと表記）の２種を扱う事例を取りあげる。そこで以下では、このリソース配分決定に関する差異部分について詳しく説明する。
【０１３８】
図１７は、本実施例で使用する２つのサービスアプリケーションＡＰ１及びＡＰ２のモードリソース対応表である。これらのサービスアプリはＣＰＵだけでなくＮＷリソースも必要とするが、それらの使用比率がサービスアプリ間で大きく異なるため、同図のように、両リソースを区別して取り扱う。同図において、各リソースの値は、動画配信サーバが備える全体リソース量を１００としたときの相対量で示されている。
【０１３９】
図１７（ａ）を参照すると、サービスアプリＡＰ１は５つの動作モード（１から５）を有し、そのうち動作モード５が通常動作モード、動作モード１が待機時動作モードである。また、通常動作モードで動作するサービスアプリＡＰ１の１タスク（１つの実体）は、動画配信サーバのＣＰＵリソースの４０％と、同サーバのＮＷリソースの２５％を消費することが示されている。同様に図１７（ｂ）はもう一つのサービスアプリＡＰ２の動作モードとそのときの消費リソース量を示したモードリソース対応表である。これらの図に示した値は、本番サービス開始前にサービスアプリ１タスクをサーバ上で仮実行させ、ＯＳ等を用いてリソース消費量を測定することで得、それに基づいて図１３（ａ）（ｂ）のモードリソース対応表が作成される。
【０１４０】
図１８は本実施例における端末サービス管理テーブル６６３の具体例を示した図である。本実施例では、後述するリソース配分計算の便を図るため、端末サービス管理テーブルの欄として「ＣＰＵリソース」「ＮＷリソース」の２列が追加されている。これらはリソース配分計算過程でのみ使用されるものであり、図１８においてはその中身は特に表示されていない。
【０１４１】
図１８（ａ）は、動画配信サービス中のある時点（１９時）での端末サービス管理テーブルの内容を示したもので、ユーザＵ０００１及びユーザＵ０００２がいずれも活動中状態であることが端末側からの情報として得られており、サーバ側ではこれらのユーザに対していずれもサービスアプリＡＰ１（タスクの実体としてはＡＰ１−１及びＡＰ１−２と表記）を動作モード５即ち通常動作モードにて実行中である。図１８（ａ）はまた、この２ユーザに加え、新たにユーザＵ０００３に対しサービスアプリＡＰ１（タスク実体はＡＰ１−３）を開始することになった状態を示している。ユーザＵ０００３は活動中との情報を得ているため、目標動作モードは５としているが、図１８（ａ）の段階ではまだリソース配分計算が完了しておらず、調整済動作モードの値はまだ更新されていない。
【０１４２】
図１８（ｂ）はサービスアプリＡＰ１−１〜ＡＰ１−３の間でリソース配分計算が完了したときの状態を示しており、調整済動作モードは目標動作モードと異なり、いずれも４となっている。このリソース配分計算のステップについて、図１９を参照しながら以下で具体的に説明する。
【０１４３】
図１９（ａ）はリソース配分計算開始直前の状態を示している。ＡＰ１−１とＡＰ１−２はいずれも動作モード５で動作しており、サーバ内でのＣＰＵ及びＮＷリソースの消費量の合計は各々８０、５０である。
【０１４４】
ここで図１９（ｂ）のようにＡＰ１−３が追加され、これも目標動作モード５であるとする。図９の計算手順のステップＳ１００１及びＳ１００２に従い、図１９（ａ）のモードリソース対応表を元にＣＰＵ及びＮＷの必要リソース量の合計を求めると各々１２０、７５となる。ここでＣＰＵリソース量が１００を超え、不足する見通しであることがわかる（図９のステップＳ１００４）。そこでリソース削減調整率１００÷１２０＝０．８３を各リソース量に乗じると図１９（ｃ）となる。図１７（ａ）のモードリソース対応表からＣＰＵリソース３３、ＮＷリソース２１に最も近いものを選ぶと、動作モード４（ＣＰＵリソース３０、ＮＷリソース１６）がそれに相当する。そこで図１９（ｄ）に示すように、ＡＰ１−１〜ＡＰ１−３の調整済動作モードを４に設定する（図９のステップＳ１００８）。このとき全体必要リソース量はＣＰＵ、ＮＷそれぞれ９０及び４８となり、サーバリソース量でまかなえるようになったことがわかる。
【０１４５】
この後、更に状況が変化してサービスアプリＡＰ２−１が追加になった場合のリソース配分計算過程を図２０に示す。図１７（ｂ）を参照すると、ＡＰ２−１の通常動作モード３ではＣＰＵ及びＮＷリソースを各々２０及び７０消費し、従って図２０（ａ）から読み取れるように、サーバ全体では各々１４０及び１４５のリソースが必要である。ここではＮＷリソース量の上限逸脱がＣＰＵリソース量のそれより大きいので、ＮＷリソース側から調整を図る。即ちリソース削減調整率１００÷１４５＝０．６９を乗じて図２０（ｂ）のようなリソース量に圧縮することを狙い、図１７（ａ）及び（ｂ）から最も近いリソース量となる動作モードを選ぶと、ＡＰ１に対し動作モード４、ＡＰ２に対し動作モード２となる。この状態を図２０（ｃ）に示す。ここで必要ＮＷリソースの合計はサーバ全体のＮＷリソース量内に収まったが、ＣＰＵリソース量の合計は１０５でまだ上限を５％超えている。本実施例ではこのように若干の上限超えを生じることがあるが、これはサーバＯＳ６１５における規定のリソーススケジューリング動作による自動調整に委ねる。通常これが問題になることはないが、こうしたＯＳ自動調節に委ねる割合を少なくするために、モードリソース対応表（図１７）には多段階の動作モードを登録しておくのがよい。
【０１４６】
更にユーザ状態が変化した場合の説明を継続する。図２１（ａ）は２人のユーザが非活動状態となった場合を示している。それらのユーザに対応するＡＰ１−２及びＡＰ１−３の目標動作モードは５から１即ち待機時動作モードとなる。図９のリソース計算手順に沿ってサーバ全体の必要リソース量を求めると、ＣＰＵリソース＝９０、ＮＷリソース＝９９となり、いずれもサーバ全体リソースに収まる。そこで各アプリの調整済動作モード値はいずれも目標動作モード値と同じとしている。
【０１４７】
図２１（ａ）の状態を図２０（ｃ）の状態と比較すると、ＡＰ１−２及びＡＰ１−３に配分されていたリソースが減り、逆にＡＰ１−１及びＡＰ２−１に配分されていたリソースが増えていることがわかる。これは、サービスを享受していないと判断されたユーザからサービスを真に享受しているユーザへリソースが再配分され、後者のユーザに対するサービス品質改善につながっている。
【０１４８】
図２１（ｂ）は更に４人目のユーザが非活動状態となった場合を示しており、ＡＰ２−１の目標動作モードが１即ちＡＰ２の待機時動作モードとなっている。同様にリソース計算手順に沿って計算すると、ＣＰＵもＮＷもサーバ全体リソース量に収まるため、各アプリの調整済動作モード値はいずれも目標動作モード値と同じになる。
【０１４９】
図２１（ｂ）のとき、サーバではＣＰＵリソースのうちの２５％、ＮＷリソースのうちの６１％は不要であり、サーバＯＳ ６１５が備える動的省電力機構によりこれらの不要リソース分の電力消費を削減する。これは、サービスを享受していないと判断されたユーザへのサービスのために割くリソースを減らし、サーバ消費電力を削減できたことを意味する。
【０１５０】
このように、本実施例では、ユーザの携帯端末側から得たコンテキスト情報を元に映像配信サーバ側のリソース配分を調節し、サービスを享受しているユーザに対するサービス品質改善、及び映像配信サーバ側消費電力の削減を実現している。
【０１５１】
以上各実施の形態及び実施例で説明したように、本発明によれば、ネットワークサービスを享受しているユーザに対して適切なリソース割り当てが可能となる。すなわち、サービス配信を受けている複数のユーザそれぞれの状況をサービス提供サーバ側で把握し、サービスを最終的に利用していないユーザに対して割り当てていたサーバ及びネットワークリソースを、サービスを真に享受したいと希望しているユーザ向けに再配分し、限られたリソースを有効に活用することが可能になる。
【０１５２】
なお、上述した動画視聴アプリ、端末制御アプリ、動画配信アプリ、サービス制御アプリの各種プログラムは、コンピュータ・システムがアクセス可能な様々な種類の記憶媒体に格納することが可能である。また、このプログラムは、通信媒体を介して伝達されることが可能である。ここで、記憶媒体には、例えば、フレキシブルディスク、ハードディスク、磁気ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＤＶＤ、ＲＯＭカートリッジ、バッテリバックアップ付きＲＡＭメモリカートリッジ、フラッシュメモリカートリッジ、不揮発性ＲＡＭカートリッジ等が含まれる。また、通信媒体には、電話回線等の有線通信媒体、マイクロ波回線等の無線通信媒体等が含まれ、インターネットも含まれる。
【０１５３】
また、本発明のシステムは多数のコンシューマ端末向けに集中サーバからサービスを提供するサービスシステムに適用できる。例えば、動画配信システム、メッセージ交換システム、サーバクライアント形態をとる音声認識システム、画像認識システム等に適用することができる。
【０１５４】
なお、本発明は上記実施の形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変形・変更することが可能である。本発明の実施の形態としては様々な態様が考えられ、例えば以下のような実施の形態が可能である。
【０１５５】
（１）ネットワークサービスの提供を行うサービス提供サーバと、前記ネットワークサービスの提供を受ける複数のサービス実行端末と、を備えるサービス制御システムであって、前記サービス実行端末は、前記サービス提供サーバより提供されるネットワークサービスを実行することで前記ネットワークサービスを端末ユーザに提供するサービス実行手段と、自端末の状態又は自端末周囲の状態を検出する端末状態検出手段と、前記端末状態検出手段における検出結果に基づいて端末ユーザが前記ネットワークサービスを利用しているか否かを判断するサービス利用状況判断手段と、前記サービス利用状況判断手段における判断結果を前記サービス提供サーバに通知するサービス利用状況通知手段と、を具備し、前記サービス提供サーバは、前記サービス実行端末より通知された前記判断結果に基づいて前記サービス実行端末に提供するネットワークサービスに対して配分するリソース量を決定するリソース配分決定手段と、前記リソース配分決定手段で決定されたリソース量に基づいて前記サービス実行端末に提供するネットワークサービスに対してリソースを配分するリソース配分実行手段と、前記リソース配分実行手段により配分されるリソースを用いてネットワークサービスの提供を前記サービス実行端末に対して行うサービス提供手段と、を具備する、サービス制御システム。
（２）サービス提供サーバより提供されるネットワークサービスを実行することで前記ネットワークサービスを端末ユーザに提供するサービス実行手段と、自端末の状態又は自端末周囲の状態を検出する端末状態検出手段と、前記端末状態検出手段における検出結果に基づいて端末ユーザが前記ネットワークサービスを利用しているか否かを判断するサービス利用状況判断手段と、前記サービス利用状況判断手段における判断結果を前記サービス提供サーバに通知するサービス利用状況通知手段と、を具備するサービス実行端末。
（３）前記サービス実行手段は、前記ネットワークサービスを複数の品質レベルで前記端末ユーザに対して提供可能であることを特徴とする、（２）に記載のサービス実行端末。
（４）前記サービス実行手段が前記ネットワークサービスを所定の基準より低い品質レベルで前記端末ユーザに提供している場合において、前記端末ユーザから発せられる所定の動作を検知するユーザ反応検知手段を更に具備し、前記サービス利用状況通知手段は、前記所定の動作の検知結果を前記サービス提供サーバに通知する、（３）に記載のサービス実行端末。
（５）前記サービス利用状況通知手段は、提供するネットワークサービスの品質レベルを下げることを示す通知を前記サービス提供サーバより受信し、前記ユーザ反応検知手段は、前記通知が受信された場合に前記端末ユーザが前記ネットワークサービスの品質レベルの低下に対する不満を表す動作を発しているかを判断する、（４）に記載のサービス実行端末。
（６）前記サービス利用状況判断手段は、前記サービス実行手段が実行しているネットワークサービスの種類及び前記前記端末状態検出手段における前記検出結果に基づいて端末ユーザが前記ネットワークサービスを利用しているかどうかを判断する、（２）乃至（５）のいずれか１項に記載のサービス実行端末。
（７）前記端末状態検出手段は、自端末に生じる加速度、自端末の位置、自端末の傾き、自端末周囲の明るさ、の少なくとも１つを前記自端末の状態又は自端末周囲の状態として検出する、（２）乃至（６）のいずれか１項に記載のサービス実行端末。
（８）前記サービス実行手段は、動画配信サーバより配信される動画ストリームを前記動画配信サーバより指定されたビットレートで再生する、（３）又は（４）に記載のサービス実行端末。
（９）前記端末状態検出手段は、少なくとも自端末周囲の明るさを検出する光センサ及び自端末に生じる加速度を検出する加速度センサを備え、前記サービス利用状況判断手段は、前記サービス実行手段が前記動画配信サーバより配信される動画ストリームを再生している場合であって、前記光センサで検出される光量が所定の基準値より少なく、かつ、前記加速度センサで検出される加速度の値が所定の期間０である場合に、端末ユーザは動画配信サービスを利用していないと判断する、（８）に記載のサービス実行端末。
（１０）前記端末状態検出手段は、少なくとも自端末周囲の明るさを検出する光センサと、自端末に生じる加速度を検出する加速度センサと、自端末の現在位置を検出する位置センサと、を具備し、前記サービス利用状況判断手段は、前記サービス実行手段が対話型メッセージサービスを実行している場合であって、一定期間キー操作又はタッチスクリーン操作がなく、かつ、前記光センサで検出される光量が所定の基準値より少なく、かつ、前記加速度センサ及び位置センサでそれぞれ検出される加速度及び現在位置に変化がある場合に、端末ユーザは前記対話型メッセージサービスを利用していないと判断する、（３）又は（４）に記載のサービス実行端末。
（１１）端末ユーザの行動特性に関する情報を記憶する記憶手段を更に具備し、前記前記サービス利用状況判断手段は、前記記憶手段に記憶された前記行動特性に関する情報を参照して、前記端末ユーザがネットワークサービスを利用しているか否かを判断する、（２）乃至（１０）のいずれか１項に記載のサービス実行端末。
（１２）前記サービス実行手段は、前記サービス提供サーバより提供されるネットワークサービスを指定された動作モードで実行するアプリケーションタスクである、（２）乃至（１１）のいずれか１項に記載のサービス実行端末。
（１３）複数のサービス実行端末よりそれぞれ通知される各端末ユーザがネットワークサービスを利用しているか否かについての判断結果に基づいて前記複数のサービス実行端末にそれぞれ提供するネットワークサービスに対して配分するリソース量を決定するリソース配分決定手段と、前記リソース配分決定手段で決定されたリソース量に基づいて前記複数のサービス実行端末にそれぞれ提供するネットワークサービスに対してリソースを配分するリソース配分実行手段と、前記リソース配分実行手段により配分されるリソースを用いて前記ネットワークサービスの提供を前記複数のサービス実行端末に対して行うサービス提供手段と、を具備するサービス提供サーバ。
（１４）前記サービス提供手段は、前記ネットワークサービスを複数の品質レベルで前記端末ユーザに対して提供可能であり、前記リソース配分決定手段で決定されるリソース量のリソースを用いて実現可能な品質レベルで前記ネットワークサービスの提供を行う、（１３）に記載のサービス提供サーバ。
（１５）前記リソース配分決定手段は、前記複数のサービス実行端末に対するネットワークサービスの提供に必要なリソースの総量が、前記ネットワークサービス提供に利用可能なリソースの総量を上回る場合に、前記判断結果に基づいて端末ユーザが利用していないネットワークサービスに対して配分するリソース量を削減する決定を行う、（１３）又は（１４）に記載のサービス提供サーバ。
（１６）前記サービス提供手段は、リソース消費量の異なる複数の動作モードを有し、前記複数のサービス実行端末にネットワークサービスを提供するサービスアプリケーションタスクを備え、前記リソース配分決定手段は、前記判断結果に基づいて前記サービスアプリケーションタスクの動作モードを前記複数のサービス実行端末に提供するネットワークサービス毎に決定し、前記リソース配分実行手段は、前記リソース配分決定手段で決定された前記動作モードの指示を前記サービスアプリケーションタスクに対して行い、
前記サービスアプリケーションタスクは、前記指示された動作モードでそれぞれ前記ネットワークサービスを前記サービス実行端末に提供する、（１３）に記載のサービス提供サーバ。
（１７）前記リソース配分決定手段は、前記サービスアプリケーションタスクの各動作モードが必要とするリソース量を示したモードリソース対応表と前記判断結果とに基づいて、前記複数のサービス実行端末に対するネットワークサービスの提供に必要なリソースの総量が、前記ネットワークサービス提供に利用可能なリソースの総量を超えないように、各サービス実行端末にネットワークサービスを提供するサービスアプリケーションタスクの動作モードを決定する、（１６）に記載のサービス提供サーバ。
（１８）前記サービス提供手段は、前記リソース配分実行手段により配分されるリソースに応じた配信ビットレートで前記サービス実行端末に対して動画配信を行う、（１３）乃至（１７）のいずれか１項に記載のサービス提供サーバ。
（１９）自端末の状態又は自端末周囲の状態を検出する端末状態検出手段で得られる検出結果に基づいて端末ユーザがネットワークサービスを利用しているか否かを判断するサービス利用状況判断処理と、ネットワークサービスを所定の基準より低い品質レベルで前記端末ユーザに提供している場合において、前記端末ユーザから発せられる所定の動作を検知するユーザ反応検知処理と、前記サービス利用状況判断処理における判断結果及び前記ユーザ反応計地処理における検知結果をそれぞれサービス提供サーバに通知するサービス利用状況通知処理と、を計算機に実行させるネットワークサービス補助プログラム。
（２０）複数のサービス実行端末よりそれぞれ通知される各端末ユーザがネットワークサービスを利用しているか否かについての判断結果に基づいて前記複数のサービス実行端末にそれぞれ提供するネットワークサービスに対して配分するリソース量を決定するリソース配分決定処理と、前記リソース配分決定処理で決定されたリソース量に基づいて前記複数のサービス実行端末にそれぞれ提供するネットワークサービスに対してリソースを配分するリソース配分実行処理と、前記リソース配分実行処理により配分されるリソースを用いて前記ネットワークサービスの提供を前記複数のサービス実行端末に対して行うサービス提供処理と、を計算機に実行させるネットワークサービス制御プログラム。
（２１）サービス提供サーバより提供されるネットワークサービスを実行することで前記ネットワークサービスを端末ユーザに提供するサービス実行ステップと、自端末の状態又は自端末周囲の状態を検出する端末状態検出ステップと、前記端末状態検出ステップにおける検出結果に基づいて端末ユーザが前記ネットワークサービスを利用しているか否かを判断するサービス利用状況判断ステップと、前記サービス利用状況判断ステップにおける判断結果を前記サービス提供サーバに通知するサービス利用状況通知ステップと、を具備するサービス実行方法。
（２２）複数のサービス実行端末よりそれぞれ通知される各端末ユーザがネットワークサービスを利用しているか否かについての判断結果に基づいて前記複数のサービス実行端末にそれぞれ提供するネットワークサービスに対して配分するリソース量を決定するリソース配分決定ステップと、前記リソース配分決定ステップで決定されたリソース量に基づいて前記複数のサービス実行端末にそれぞれ提供するネットワークサービスに対してリソースを配分するリソース配分実行ステップと、前記リソース配分実行ステップにより配分されるリソースを用いて前記ネットワークサービスの提供を前記複数のサービス実行端末に対して行うサービス提供ステップと、を具備するサービス提供方法。
【符号の説明】
【０１５６】
１０ 端末群 ２０ サービス提供サーバ
３０ ネットワーク １００ 端末
１１０ サービス実行部 １２０ 端末状態検出部
１３０ サービス利用状況判断部 １４０ サービス利用状況通知部
１５０ ネットワークインタフェース ２００ サービス提供サーバ
２１０ サービス提供部 ２２０ リソース配分決定部
２３０ リソース配分実行部 ２４０ ネットワークインタフェース
３００ 端末 ３１０ ＣＰＵ
３２０ センサ群 ３３０ コンテキスト認識部
３４０ 端末情報収集制御部 ３５０ ネットワークインタフェース
３６０ ユーザ反応検知部 ３７０ 端末側アプリケーション群
４００ サービス提供サーバ ４１０ ＣＰＵ
４１５ ＯＳ ４２０ リソース配分決定部
４２１ 全端末情報管理部 ４２２ 端末サービス管理テーブル
４２３ 端末配分リソース計算部 ４２４ タイマ
４２５ モードリソース対応表 ４３０ リソース配分実行部
４４０ ネットワークインタフェース ４５０ サービスアプリケーション群
５００ 携帯端末 ５１０ ＣＰＵ
５１５ 携帯端末ＯＳ ５２１ ＧＰＳ
５２２ 加速度センサ ５２３ 時計
５５０ 無線インタフェース ５７０ 動画視聴アプリ
５８０ 端末制御アプリ ５８１ コンテキスト認識モジュール
５８２ 端末情報収集制御モジュール ５８３ ユーザ反応検知モジュール
６００ 動画配信サーバ ６１０ ＣＰＵ群
６１５ サーバＯＳ ６４０ 高速イーサネットインタフェース
６５０ 動画配信アプリ群 ６６０ サービス制御アプリ
６６１ リソース配分決定モジュール ６６２ リソース配分実行モジュール
６６３ モードリソース対応表 ６６４ 端末サービス管理テーブル
７１０ 端末コンテキストメッセージ ７１１ ユーザＩＤ
７１２ ユーザ状態 ７１３ 状態変化時刻
７２０ リソース配分決定メッセージ ７２１ ユーザＩＤ
７２２ サーバ側リソース配分決定結果 ４２２１ ユーザＩＤ
４２２２ ユーザ状態 ４２２３ サービスアプリ識別子
４２２４ 状態変化時刻 ４２２５ 目標動作モード
４２２６ 調整済動作モード
【特許請求の範囲】
【請求項１】
ネットワークサービスの提供を行うサービス提供サーバと、前記ネットワークサービスの提供を受ける複数のサービス実行端末と、を備えるサービス制御システムであって、
前記サービス実行端末は、
前記サービス提供サーバより提供されるネットワークサービスを実行することで前記ネットワークサービスを端末ユーザに提供するサービス実行手段と、
自端末の状態又は自端末周囲の状態を検出する端末状態検出手段と、
前記端末状態検出手段における検出結果に基づいて前記端末ユーザが前記ネットワークサービスを利用しているか否かを判断するサービス利用状況判断手段と、
前記サービス利用状況判断手段における判断結果を前記サービス提供サーバに通知するサービス利用状況通知手段と、
を具備し、
前記サービス提供サーバは、
前記サービス実行端末より通知された前記判断結果に基づいて前記サービス実行端末に提供するネットワークサービスに対して配分するリソース量を決定するリソース配分決定手段と、
前記リソース配分決定手段で決定されたリソース量に基づいて前記サービス実行端末に提供するネットワークサービスに対してリソースを配分するリソース配分実行手段と、
前記リソース配分実行手段により配分されるリソースを用いてネットワークサービスの提供を前記サービス実行端末に対して行うサービス提供手段と、
を具備する、
サービス制御システム。
【請求項２】
サービス提供サーバより提供されるネットワークサービスを実行することで前記ネットワークサービスを端末ユーザに提供するサービス実行手段と、
自端末の状態又は自端末周囲の状態を検出する端末状態検出手段と、
前記端末状態検出手段における検出結果に基づいて前記端末ユーザが前記ネットワークサービスを利用しているか否かを判断するサービス利用状況判断手段と、
前記サービス利用状況判断手段における判断結果を前記サービス提供サーバに通知するサービス利用状況通知手段と、
を具備するサービス実行端末。
【請求項３】
前記サービス実行手段は、前記ネットワークサービスを複数の品質レベルで前記端末ユーザに対して提供可能であることを特徴とする、
請求項２に記載のサービス実行端末。
【請求項４】
前記サービス実行手段が前記ネットワークサービスを所定の基準より低い品質レベルで前記端末ユーザに提供している場合において、前記端末ユーザから発せられる所定の動作を検知するユーザ反応検知手段を更に具備し、
前記サービス利用状況通知手段は、前記所定の動作の検知結果を前記サービス提供サーバに通知する、
請求項３に記載のサービス実行端末。
【請求項５】
前記サービス利用状況通知手段は、提供するネットワークサービスの品質レベルを下げることを示す通知を前記サービス提供サーバより受信し、
前記ユーザ反応検知手段は、前記通知が受信された場合に前記端末ユーザが前記ネットワークサービスの品質レベルの低下に対する不満を表す動作を発しているか否かを判断する、
請求項４に記載のサービス実行端末。
【請求項６】
前記端末状態検出手段は、自端末に生じる加速度、自端末の位置、自端末の傾き、自端末周囲の明るさ、の少なくとも１つを前記自端末の状態又は自端末周囲の状態として検出する、
請求項２乃至請求項５のいずれか１項に記載のサービス実行端末。
【請求項７】
複数のサービス実行端末よりそれぞれ通知される各端末ユーザがネットワークサービスを利用しているか否かについての判断結果に基づいて前記複数のサービス実行端末にそれぞれ提供するネットワークサービスに対して配分するリソース量を決定するリソース配分決定手段と、
前記リソース配分決定手段で決定されたリソース量に基づいて前記複数のサービス実行端末にそれぞれ提供するネットワークサービスに対してリソースを配分するリソース配分実行手段と、
前記リソース配分実行手段により配分されるリソースを用いて前記ネットワークサービスの提供を前記複数のサービス実行端末に対して行うサービス提供手段と、
を具備するサービス提供サーバ。
【請求項８】
前記サービス提供手段は、前記リソース配分実行手段により配分されるリソースに応じた配信ビットレートで前記サービス実行端末に対して動画配信を行う、
請求項７に記載のサービス提供サーバ。
【請求項９】
前記サービス提供手段は、リソース消費量の異なる複数の動作モードを有するサービスアプリケーションタスクを備え、
前記リソース配分決定手段は、前記判断結果に基づいて前記サービスアプリケーションタスクの動作モードを前記複数のサービス実行端末に提供するネットワークサービス毎に決定し、
前記リソース配分実行手段は、前記リソース配分決定手段で決定された前記動作モードの指示を前記サービスアプリケーションタスクに対して行い、
前記サービスアプリケーションタスクは、前記指示された動作モードでそれぞれ前記ネットワークサービスを各サービス実行端末に提供する、
請求項７又は請求項８に記載のサービス提供サーバ。
【請求項１０】
前記リソース配分決定手段は、前記サービスアプリケーションタスクの各動作モードが必要とするリソース量を示したモードリソース対応表と前記判断結果とに基づいて、前記複数のサービス実行端末に対するネットワークサービスの提供に必要なリソースの総量が、前記ネットワークサービス提供に利用可能なリソースの総量を超えないように、各サービス実行端末にネットワークサービスを提供するサービスアプリケーションタスクの動作モードを決定する、
請求項９に記載のサービス提供サーバ。
【請求項１】
ネットワークサービスの提供を行うサービス提供サーバと、前記ネットワークサービスの提供を受ける複数のサービス実行端末と、を備えるサービス制御システムであって、
前記サービス実行端末は、
前記サービス提供サーバより提供されるネットワークサービスを実行することで前記ネットワークサービスを端末ユーザに提供するサービス実行手段と、
自端末の状態又は自端末周囲の状態を検出する端末状態検出手段と、
前記端末状態検出手段における検出結果に基づいて前記端末ユーザが前記ネットワークサービスを利用しているか否かを判断するサービス利用状況判断手段と、
前記サービス利用状況判断手段における判断結果を前記サービス提供サーバに通知するサービス利用状況通知手段と、
を具備し、
前記サービス提供サーバは、
前記サービス実行端末より通知された前記判断結果に基づいて前記サービス実行端末に提供するネットワークサービスに対して配分するリソース量を決定するリソース配分決定手段と、
前記リソース配分決定手段で決定されたリソース量に基づいて前記サービス実行端末に提供するネットワークサービスに対してリソースを配分するリソース配分実行手段と、
前記リソース配分実行手段により配分されるリソースを用いてネットワークサービスの提供を前記サービス実行端末に対して行うサービス提供手段と、
を具備する、
サービス制御システム。
【請求項２】
サービス提供サーバより提供されるネットワークサービスを実行することで前記ネットワークサービスを端末ユーザに提供するサービス実行手段と、
自端末の状態又は自端末周囲の状態を検出する端末状態検出手段と、
前記端末状態検出手段における検出結果に基づいて前記端末ユーザが前記ネットワークサービスを利用しているか否かを判断するサービス利用状況判断手段と、
前記サービス利用状況判断手段における判断結果を前記サービス提供サーバに通知するサービス利用状況通知手段と、
を具備するサービス実行端末。
【請求項３】
前記サービス実行手段は、前記ネットワークサービスを複数の品質レベルで前記端末ユーザに対して提供可能であることを特徴とする、
請求項２に記載のサービス実行端末。
【請求項４】
前記サービス実行手段が前記ネットワークサービスを所定の基準より低い品質レベルで前記端末ユーザに提供している場合において、前記端末ユーザから発せられる所定の動作を検知するユーザ反応検知手段を更に具備し、
前記サービス利用状況通知手段は、前記所定の動作の検知結果を前記サービス提供サーバに通知する、
請求項３に記載のサービス実行端末。
【請求項５】
前記サービス利用状況通知手段は、提供するネットワークサービスの品質レベルを下げることを示す通知を前記サービス提供サーバより受信し、
前記ユーザ反応検知手段は、前記通知が受信された場合に前記端末ユーザが前記ネットワークサービスの品質レベルの低下に対する不満を表す動作を発しているか否かを判断する、
請求項４に記載のサービス実行端末。
【請求項６】
前記端末状態検出手段は、自端末に生じる加速度、自端末の位置、自端末の傾き、自端末周囲の明るさ、の少なくとも１つを前記自端末の状態又は自端末周囲の状態として検出する、
請求項２乃至請求項５のいずれか１項に記載のサービス実行端末。
【請求項７】
複数のサービス実行端末よりそれぞれ通知される各端末ユーザがネットワークサービスを利用しているか否かについての判断結果に基づいて前記複数のサービス実行端末にそれぞれ提供するネットワークサービスに対して配分するリソース量を決定するリソース配分決定手段と、
前記リソース配分決定手段で決定されたリソース量に基づいて前記複数のサービス実行端末にそれぞれ提供するネットワークサービスに対してリソースを配分するリソース配分実行手段と、
前記リソース配分実行手段により配分されるリソースを用いて前記ネットワークサービスの提供を前記複数のサービス実行端末に対して行うサービス提供手段と、
を具備するサービス提供サーバ。
【請求項８】
前記サービス提供手段は、前記リソース配分実行手段により配分されるリソースに応じた配信ビットレートで前記サービス実行端末に対して動画配信を行う、
請求項７に記載のサービス提供サーバ。
【請求項９】
前記サービス提供手段は、リソース消費量の異なる複数の動作モードを有するサービスアプリケーションタスクを備え、
前記リソース配分決定手段は、前記判断結果に基づいて前記サービスアプリケーションタスクの動作モードを前記複数のサービス実行端末に提供するネットワークサービス毎に決定し、
前記リソース配分実行手段は、前記リソース配分決定手段で決定された前記動作モードの指示を前記サービスアプリケーションタスクに対して行い、
前記サービスアプリケーションタスクは、前記指示された動作モードでそれぞれ前記ネットワークサービスを各サービス実行端末に提供する、
請求項７又は請求項８に記載のサービス提供サーバ。
【請求項１０】
前記リソース配分決定手段は、前記サービスアプリケーションタスクの各動作モードが必要とするリソース量を示したモードリソース対応表と前記判断結果とに基づいて、前記複数のサービス実行端末に対するネットワークサービスの提供に必要なリソースの総量が、前記ネットワークサービス提供に利用可能なリソースの総量を超えないように、各サービス実行端末にネットワークサービスを提供するサービスアプリケーションタスクの動作モードを決定する、
請求項９に記載のサービス提供サーバ。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【公開番号】特開２０１３−１２８９２（Ｐ２０１３−１２８９２Ａ）
【公開日】平成２５年１月１７日（２０１３．１．１７）
【国際特許分類】
【出願番号】特願２０１１−１４４１０８（Ｐ２０１１−１４４１０８）
【出願日】平成２３年６月２９日（２０１１．６．２９）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
【公開日】平成２５年１月１７日（２０１３．１．１７）
【国際特許分類】
【出願日】平成２３年６月２９日（２０１１．６．２９）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
[ Back to top ]