(57)【要約】【課題】同時に提供される異なる複数のサービスを比較し、統括的に制御することで、ユーザのサービスに対する要求の特性を考慮した各サービスの提供方法を動的に決定する。【解決手段】複数のサービスを同時に利用する際のサービス制御システムはコンテキスト解析部とサービス制御内容決定部とを備える。コンテキスト解析部は各サービスの制御方法を決定するプロセスを各サービスに対してネットワークから取得できる様々なコンテキストから各サービスに対して共通要素となる要求特性の導出する手段をもち、サービス制御内容決定部はコンテキスト解析部が導出した各サービスに対する要求特性を用いて異なるサービスを比較し、統括的に扱うことで、各サービスの制御項目内容を決定する手段をもつ。【選択図】        図２
2005100320.tif 000002
【特許請求の範囲】
【請求項１】
複数のサービスを同時に利用する際のサービス制御システムにおいて、
ユーザと各サービスとを取り巻く情報から、各サービスに対して共通要素を導出する手段を備え、
異なるサービスを比較することを可能にし、複数のサービスを統括的に制御することを特徴とするサービス制御システム。
【請求項２】
複数のサービスを同時に利用する際のサービス制御システムにおいて、
各サービスの制御方法を決定するプロセスを各サービスに対してネットワークから取得できる様々なコンテキストから各サービスに対して共通要素となる要求特性を導出する手段をもつコンテキスト解析部と、
前記コンテキスト解析部が導出した各サービスに対する要求特性を用いて異なるサービスを比較し、統括的に扱うことで、各サービスの制御項目内容を決定する手段をもつサービス制御内容決定部と、
を備えることを特徴とするサービス制御システム。
【請求項３】
請求項２に記載のサービス制御システムにおいて、
コンテキスト解析部はサービスに対して、取得できる様々なコンテキストからサービスに対する共通要素となる要求特性を導出してサービス制御を行うことで、コンテキストの抽象化を可能にするため、
様々な複数のコンテキストを同時に扱うことを可能とし、またサービスの違いによって異なるコンテキストや異なる情報源を扱うことも可能とし、必要な全てのコンテキストを収集できなくても、要求特性を導出することで複数のサービスの制御を可能とし、さらには、将来、取得が期待される新規コンテキストに対する拡張性や汎用性を実現することを特徴とするサービス制御システム。
【請求項４】
請求項２または３に記載のサービス制御システムおいて、
サービス制御内容決定部は複数のサービスに対して、要求特性という共通要素を用いることでサービス間の比較を実現し、異なる複数のサービスを統括的に扱うことを可能とすることで、
第２、第３の新規サービスに対する開始の許可の判断、サービスの継続・中断の判断、サービスの提供時刻、サービスを提供するデバイス、サービスの品質というような、よりユーザ指向なダイナミックなサービス制御を実現することを可能とし、さらには新規デバイス、サービスの新規制御項目に対する拡張性や汎用性を高めることを可能にすることを特徴とするサービス制御システム。
【請求項５】
請求項４に記載のサービス制御システムにおいて、
より請求項４に記載したサービス制御への拡張を実現するため、「提供するデバイス」、「使用するユーザ」、「使用する時間」、「使用する場所」といった複数のサービスを使用する際に発生するサービス間の関連性に基づいた「複数のサービスに対する制御ルール」を動的に導出するために、
使用中である他のサービスに関する情報（要求特性を含む）をコンテキストとして利用する手段をもつフィードバック機構を有することを特徴とするサービス制御システム。
【請求項６】
請求項５に記載のサービス制御システムにおいて、
前記フィードバック機構を利用することで、使用中の他のサービス（その要求特性も含む）に関する情報をコンテキストとして扱うことにより、複数のサービスを使用する際に生じる「表示するデバイス」、「使用するユーザ」、「使用する時間」、「使用する場所」といったサービス間の関連性に基づいた「複数のサービスに対する制御ルール」を動的に導出する手段と、
その動的な制御ルールとフィードバックにより得た他のサービスの要求特性によって各サービスに対するユーザ指向なサービス制御を決定する手段と、
を備えることを特徴とするサービス制御システム。
【請求項７】
請求項６に記載のサービス制御システムにおいて、
ユーザのサービスの利用履歴および／または利用パターンを制御ルールに考慮することで、ユーザに対するシステムの柔軟性や利便性を高めるシステムとすることを特徴とするサービス制御システム。
【請求項８】
請求項２ないし７のうちいずれか１項に記載のサービス制御システムにおいて、
サービス制御内容決定部で動的な制御ルールと各サービスに対する要求特性をのみを用いて、複数のサービス制御項目や制御内容を決定した後に、ネットワークリソースやデバイスの割り当てを行うことで、
複数のサービスを同時に利用する際に調停が必要なパラメータ数を減らすことを可能にし、
さらにはリソースの割り当てを行う前に、ユーザがサービスに対して最低要求する品質をサービスが提供できないと判断されるようなサービスヘのリソースの割り当てを事前に回避することで、提供が可能なサービスに対してのリソースの集中的な割り当てを実現することを特徴とするサービス制御システム。
【請求項９】
請求項２ないし８のうちいずれか１項に記載のサービス制御システムにおいて、
コンテキスト解析部で提供される多様なサービスに対して、ネットワークから取得できる様々なコンテキストを用いて導出する各サービスに対する要求特性を、一部の特定相手や特定のサービスプロバイダに対して公開することで、
サービス提供側（サービスプロバイダーおよび／または通信相手を含む）がユーザの状況を把握して、ユーザに必要かつ、ユーザがサービスを受け入れられるタイミングで、サービスを提供することを可能とすることを特徴とするサービス制御システム。
【請求項１０】
複数のサービスを同時に利用する際のサービス制御システムにおけるサービス制御方法において、
前記サービス制御システムはコンテキスト解析部とサービス制御内容決定部を備え、
前記コンテキスト解析部が、各サービスの制御方法を決定するプロセスを各サービスに対してネットワークから取得できる様々なコンテキストから各サービスに対して共通要素となる要求特性の導出するステップと、
前記サービス制御内容決定部が、前記ステップで導出した各サービスに対する要求特性を用いて異なるサービスを比較し、統括的に扱うことで、各サービスの制御項目内容を決定するステップと、
を有することを特徴とするサービス制御方法。
【請求項１１】
請求項１ないし７のうちいずれか１項に記載のサービス制御システムにおいて、
ユーザがサービスを利用する際に必要とする人間の能力を表す資源および／またはサービスを利用する場所を表す資源を含む、実際に割り当てることができず、複数サービスを同時に利用する際の快適性に影響する資源（以下「抽象資源」と呼ぶ）を仮想的に割り当て管理するサービス制御システムであって、
前記複数サービスにおいて提供するサービスの選定および／または各サービスの提供方法を決定するために、状況に応じて動的に求める様々な要求特性を用いて、抽象資源を各サービスに割り当る手段と、
各サービスが、割り当てられた抽象資源に基づいて、割り当てられた抽象資源の種類および／または量に応じて、サービスの提供方法（制御内容）および／または提供形態を決定する手段と、
を備えることを特徴とするサービス制御システム。
【請求項１２】
請求項１１に記載のサービス制御システムにおいて、
要求特性を用いて抽象資源を割り当てる際に、各サービスの要求特性に対して設定された閾値の大きさと比較することで決定される各サービスの優先性により、各サービスに対する抽象資源の割り当て方を決定することを特徴とするサービス制御システム。
【請求項１３】
請求項１２に記載のサービス制御システムにおいて、
サービスの各要求特性に対して設定された閾値よりも高い値となる要求特性を有すサービスが複数存在するときには、抽象資源に関しては、その上限（ある抽象資源に対する各サービスの割当量の総和の上限を１００％と仮定する）を超えても、各サービスが要求する抽象資源を割り当てることで、複数サービスの同時利用を促すことを特徴とするサービス制御システム。
【請求項１４】
請求項１１ないし１３のうちいずれか１項に記載のサービス制御システムにおいて、
全てのサービスの提供方法をモード、リソース、グレードといった３つの側面から決定付け、全てのサービスは通常、多くの抽象資源を必要とするモードで、実資源量を多く必要とし（グレードが高く）、ユーザの近くにある、利用を予定しているというようなユーザとって都合のよいデバイス（リソース）を使用する提供方法をユーザが最も満足できる提供方法であるとみなし、割り当てられた抽象資源、実資源に基づいて提供可能となるサービスの提供方法の順位付けを行い、サービスの提供方法を高順位から順に選択して決定することを特徴とするサービス制御システム。
【請求項１５】
請求項１１ないし１４のうちいずれか１項に記載のサービス制御システムにおいて、
抽象資源と実資源を割り当てる際に、抽象資源を先に割り当て、その後に、選択した提供方法に必要となる実資源を要求し、実資源を割り当てることで、提供方法、提供形態を決定するというように、各資源を２段階に分けて割り当ててサービスの提供方法を決定することを特徴とするサービス制御システム。
【請求項１６】
請求項１１ないし１５のうちいずれか１項に記載のサービス制御システムにおいて、
各サービスが選定したサービスの提供方法に対して実際に割り当てられた抽象資源及び実資源の量について、「要求どおり」、「多い」または「少ない」の判断を行う手段と、
上記判断に基づいて、各サービスにおける優先度を考慮して、全てのサービスの判断が「要求どおり」となるように各サービスに対して抽象資源や実資源の再要求を指示する手段と、
上記指示に基づいて、要求する実資源や選定する提供方法を変更して再度抽象資源及び実資源を要求する手段と、
を備えることを特徴とするサービス制御システム。
【請求項１７】
請求項１１ないし１６のうちいずれか１項に記載のサービス制御システムにおいて、
現在使用しているサービスに対して割り当てられている抽象資源、実資源をサービス提供に公開することで、状況に応じて、サービス提供者が、サービス受信者がサービスを受け入れることが可能となるような提供方法を選んでサービスを提供することを可能とする特徴をもつサービス制御システム。
【請求項１８】
請求項１１ないし１７のうちいずれか１項に記載のサービス制御システムにおいて、
複数のサービスを統括的に制御する際に、サービスに関連性を持たせて連携制御させるかどうかの判断基準として、サービスの属性を表す要求特性を導入することで、抽象資源の割り当てなどの計算において、サービス属性に応じて連携制御内容の方法を決定することを可能とする特徴をもつサービス制御システム。
【請求項１９】
請求項１０に記載のサービス制御方法において、
ユーザがサービスを利用する際に必要とする人間の能力を表す資源および／またはサービスを利用する場所を表す資源を含む、実際に割り当てることができず、複数サービスを同時に利用する際の快適性に影響する資源（以下「抽象資源」と呼ぶ）を仮想的に割り当て管理するサービス制御方法であって、
前記サービス制御内容決定部が、前記複数サービスにおいて提供するサービスの選定および／または各サービスの提供方法を決定するために、状況に応じて動的に求める様々な要求特性を用いて、抽象資源を各サービスに割り当るステップと、
前記サービス制御内容決定部が、各サービスが、割り当てられた抽象資源に基づいて、割り当てられた抽象資源の種類および／または量に応じて、サービスの提供方法（制御内容）および／または提供形態を決定するステップと、
を有することを特徴とするサービス制御方法。
【請求項２０】
請求項１０または１９に記載のサービス制御方法の各ステップを実行させるためのサービス制御プログラム。
【請求項２１】
請求項２０に記載のサービス制御プログラムを記録したコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は全く異なるサービスが同時に複数提供される場合におけるサービス制御システム、方法、プログラムおよび記録媒体に関する。
【背景技術】
【０００２】
これまで、全く異なる複数のサービスを統括的に扱うようなサービス制御システムは提案されていない。本発明はコンテキストを用いて、サービス制御を実現するものであるため、ここでは、従来技術として、『ユーザの状況に適応したサービス（コンテキストアウェアサービス）』、『ユーザの要求に適応したサービス品質制御方式』を挙げる。なお、コンテキストとはユーザとサービスを取り巻く情報のことである。
【０００３】
『ユーザの状況に適応したサービス（コンテキストアウェアサービス）』
多様なアプライアンスが場所や時間を選ばずネットワークヘ接続が可能となり、適材適所に高度で最適なサービスを提供できるユビキタスネットワークによる様々なユーザ適応型サービスの提案（非特許文献１、非特許文献２参照）がされている。これらのサービスは、デバイスの小型化、高機能化に伴うモビリティ性に着目して、ユーザの位置情報に基づいたサービスを提供している。つまり、ユーザの位置によって周辺の情報（環境）が変化することを利用したサービスであり、ユーザの状況の判断にコンテキストとして位置情報を利用していると言える。
【０００４】
家庭においても同様にコンテキストアウェアサービスとして、ユーザの位置情報を利用したサービスが提案（非特許文献３、非特許文献４参照）されている。しかし、家庭においては主なサービスを同一の場所で受ける傾向があり、家の中での行動範囲はそれほど広くないため、位置情報といった偏ったコンテキストからだけではユーザの状況を詳細に判断するのは困難であると考えられる。ＣＡＳＰ（非特許文献５参照）では位置情報以外にユーザの行動に関するコンテキストの取得方法としてＲＦＩＤタグを用いる方法を提案しているが、ユーザは携帯端末等で行動コンテキストの候補から選定する作業を行わなければならない。
【０００５】
『ユーザの要求に適応したサービス品質制御方式』
マルチストリームの制御に対して、各ストリームにユーザがあらかじめ優先度を与えることで、ユーザの要求に適応させたストリーム制御を行う提案（非特許文献６、非特許文献７参照）がいくつもされている。この制御方式では、与えられた優先度に基づいて、システム設計者により設定された各レイヤのＱｏＳ（Ｕｓｅｒ−ＱｏＳ、ＡＰ−ＱｏＳ、ＮＷ−Ｑｏｓ）間のマッピングに基づいて、各ストリームにおけるビットレート、ＱｏＳパラメータ等を協調制御により決定することで、マルチストリームの品質制御を行っている。しかし、この制御方式ではユーザからの明示的なサービスに対する優先度の設定が必要となるため、優先度を変更する際には再設定を行わなければならない。また優先度が一意で固定的であるため、家庭にて提供されるような多様なサービスに対するユーザの複雑な要求には対応できない。
【０００６】
また、エンド−エンドでのサービスの品質制御を実現するシステムとして、やわらかいビデオ会議システム（非特許文献８参照）、ＣＳＣ（非特許文献９参照）等が挙げられる。これらのシステムでは、ユーザのサービス品質における要求に対して、ネットワークリソースの状況の変化に柔軟に対応して、エンド−エンドでの品質制御を行うことで、ユーザの要求や状況に適応したサービスの提供を可能としている。しかし、これらの制御方式やシステムは、そもそも全く異なった複数のサービスを統括的に制御する目的はないため、制御項目に関しても、サービス（ストリーム）における品質制御のみ対象としていて、異なったサービスを比較することで可能となるユーザ指向なサービス制御には新たな機能を追加する必要がある。ここで言う「ユーザ指向なサービス制御」とは、サービスの品質に関する協調制御だけでなく、サービス提供の可否、サービスの提供時間（スケジユーリング）、サービスの提供デバイス（提供場所）等の制御まで指す。
【０００７】
【非特許文献１】A. K. Dey,"Understanding and Using Context,"Personal and Ubiquitous Computing Journal, vol.5 (1), pp.4-7, 2001.
【非特許文献２】B. N. Schilit, et al.,"Context-aware Computing Application,"IEEE Workshop on Mobile Computing Systems and Applications, pp.85-90, Dec. 1994.
【非特許文献３】B. Brumitt, et al.,"Easy Living: Technologies for Intelligent Environments,"Proc. of 2nd International Symp. Of Handled and Ubiquitous Computing, pp.12-27, 2000.
【非特許文献４】C. D. Kidd, et al.,"The Aware Home: A Living Laboratory for Ubiquitous Computing Research,"Proc. of 2nd International Workshop, Oct. 1999.
【非特許文献５】森川他、"ユーザコンテキストを活用したサービスプラットフォームの検討"、信学技報、NS2002−279, pp.115-119、Mar. 2003.
【非特許文献６】T. Yamazaki, et al.,"MARM：An Agent-Base Adaptive QoS Management Framework,"IEICE TRANS. COMMUN., vol. E-84-B, no.1, Jan. 2001.
【非特許文献７】川田、森川、青山、"受信者の要求に基づいたマルチキャストストリーム間レート制御アーキテクチャ"、情報処理学会研究会マルチメディアと分散処理103-13 pp.71-76, Jun. 2001.
【非特許文献８】菅沼他、"マルチエージェントに基づくやわらかいビデオ会議システムの設計と実装"、情処学論、vol.39, no.6, pp.1214-1224, Jun. 1997.
【非特許文献９】H. Maeomichi, et al.,"A User-Side QoS management framework: Communication Service Concierge,"IEEE Communications Quality & Reliability Workshop, 2003.
【発明の開示】
【発明が解決しようとする課題】
【０００８】
ある限られた時間にユーザが複数のサービスを集中（並行）して利用する場面の一つに、家庭にて提供されるサービスの利用が考えられる。そこで、これ以降、家庭にて提供されるサービスに関する例を用いて、本発明について説明していく。
【０００９】
家庭における生活の特徴として、ユーザは複数のサービスを同時に利用する傾向がある。たとえ、ユーザが意図しなくても、突発的なイベントの発生やサービスの着信により、新たな別のサービスの使用を強いられる場面は十分に考えられる。（例えば、ＴＶを視聴中に電話が鳴る、入浴中にインターフォンが鳴る、料理中に監視カメラのアラームが鳴るというように、予期せぬ第２、第３のサービスの使用が必要となる状況は、家庭の日常生活において頻繁に起こると言える。）
また家庭で利用するサービスは多様であることに加え、ユーザの状況や目的とする対象への興味の変化等により、ユーザがサービスに対して要求する特性（サービスに対して求める品質、緊急性、リアルタイム性、精度、セキュリティといった性質や場所、時間、デバイスといった提供方法）は大きく異なる。したがって、全く異なるサービスを同時に複数利用する際に、それらのサービスを単純に比較することは容易ではない。このような状況で、「継続」、「中断」、「拒否」、「協調」といった各サービスヘの対処方法の判断はユーザに委ねられているが、複数のサービスを同時に使用している最中に、各サービスに対する最適な対処は簡単には判断できない。
【００１０】
現在のシステムでは単一サービスのみを対象にしているので、各サービスの特徴やユーザの各サービスに対する要求の特性、サービス間の優先順位等を考慮して対処するようなしくみは組み込まれていない。そのため、同時に複数のサービスが発生すると、入出力デバイスやネットワークリソース等の競合が起こり、全てのサービスがダウンしてしまうことや、たとえ、ダウンしないようにサービスに対して固定的な優先度を与えて相対評価を行うことによる単純なサービスの品質制御がなされた場合でも、ある場面において、あるサービスに対しては、ユーザの期待する品質とはほど遠い処理が行われる結果となることもある。
【００１１】
さらに、複数サービスによっては、デバイスやリンク帯域などの競合が起こらない場合でも複数サービスを同時利用することでユーザにとってサービスが利用しにくくなる場合が考えられる。例えばＴＶ番組を視聴しているときに、電話がかかってきたというような場合において、それぞれのサービスをそのまま利用することが困難となるとき、ユーザはＴＶ番組を消す、音量を下げる、電話を留守番電話に切り替える、着信拒否するという操作を行う。
このように複数サービスを同時利用することによってサービスが利用しにくくなる場合、ユーザは状況に応じて各サービスに対して適切な制御を施すことを必要とされるが、複数サービス間の優先順位が複雑であったり、サービスや状況によって各サービスに対する要求特性が異なるため、ユーザが全てのサービスに対して適切となる制御内容を判断し、「開始、継続、中断、拒否、変更」といった操作をとっさに行うことは容易ではない。
【００１２】
本発明はこのような問題を解決するためのものであり、同時に提供される異なる複数のサービスを比較し、統括的に制御することで、ユーザのサービスに対する要求の特性を考慮した各サービスの提供方法を動的に決定することを目的としている。
さらに本発明では異なるサービスを比較することで、複数のサービスにおける単純な協調制御に加えて、新たに可能となる、よりユーザ指向なダイナミックなサービス制御（サービスの対処方法の判断等）への拡張を図ることを目的としている。
【課題を解決するための手段】
【００１３】
上述した目的を達成するために、本発明にかかるサービス制御システムは、ユーザと各サービスとを取り巻く情報から、各サービスに対して共通要素を導出する手段を備え、異なるサービスを比較することを可能にし、複数のサービスを統括的に制御することを特徴とする。
【００１４】
また、本発明にかかるサービス制御システムは、各サービスの制御方法を決定するプロセスは各サービスに対してネットワークから取得できる様々なコンテキストから、それぞれのサービスに対して共通要素となる要求特性を導出する（取得したコンテキストの抽象化）手段をもつコンテキスト解析部と、導出した各サービスに対する要求特性を用いて、異なるサービスを比較し、統括的に扱うことで、各サービス制御項目の内容を決定する手段をもつサービス制御内容決定部とを備えるものである。
【００１５】
ここで要求特性とは、ユーザが期待するサービスの状態を表す変数と定義し、具体的には、品質、緊急性、リアルタイム性、精度、セキュリティといった性質や場所、時間、デバイス、コストといった具体的なサービスの提供手段までを指す。
さらに要求特性として、そのサービスを利用する際に、ユーザに必要となる能力、つまり「目」で見る、「耳」で聞く、「口」で話す、「手」で操作するというような人間の能力を表す「ユーザ資源」をサービスの提供形態を決定付ける特性として考える。
さらに要求特性として、サービスを提供する際に必要となる「部屋」、「場所」、「領域」などを表す「ロケーション資源」をサービスの提供状態を決定付ける特性として考える。
この「ユーザ資源」、「ロケーション資源」といった定量的に割り当てることができないような仮想的な資源を「抽象資源」と呼び、サービスが必要とする抽象資源をユーザがサービスを利用する際に必要となる共通要素として要求特性として考える。
【００１６】
また、本発明ではコンテキスト解析部で、提供される多様なサービスに対して、ネットワークから取得できる様々なコンテキストから、サービスに対する共通要素となる要求特性を導出することで、様々な複数のコンテキストを同時に扱うことを可能とし、またサービスの違いによって異なるコンテキストや異なる情報源を扱うことを可能とし、必要な全てのコンテキストを収集できなくとも、要求特性を導出することでサービスの制御を可能とし、さらには、将来、取得が期待される新規コンテキストに対する拡張（システムの汎用性）を可能にすることを特徴とする。
【００１７】
また、本発明ではサービス制御内容決定部で各サービスに対する要求特性という共通要素を用いることで、サービス間の比較を容易にし、全く異なる複数のサービスを統括的に扱うことを可能とすることで、新規サービス開始の許可、各サービスの提供時刻、各サービスを提供するデバイス先、各サービスの品質といったような、よりユーザ指向なダイナミックなサービス制御を行うことを可能とし、さらには新規デバイス、サービスの新規制御項目に対する拡張性やシステムの汎用性を可能にすることを特徴とする。
【００１８】
また、本発明では、さらに、「提供するデバイス」、「使用するユーザ」、「使用する時間」、「使用する場所」といった複数のサービスを使用する際に発生するサービス間の関連性に基づいた「複数のサービスに対する制御ルール」を動的に導出するために、使用中である他のサービスに関する情報（要求特性を含む）をコンテキストとして利用する手段をもつフィードバック機構を有する。
【００１９】
また、本発明では前記フィードバック機構を利用することで、使用中の他のサービス（その要求特性も含む）に関する情報をコンテキストとして扱うことにより、複数のサービスを使用する際に生じる「表示するデバイス」、「使用するユーザ」、「使用する時間」、「使用する場所」といったサービス間の関連性に基づいた「複数のサービスに対する制御ルール」を動的に導出する手段と、その動的な制御ルールとフィードバックにより得た他のサービスの要求特性によって各サービスに対するユーザ指向なサービス制御を決定する手段とを備えることを特徴とする。
【００２０】
また、本発明ではユーザのサービスの利用履歴および／または利用パターンを制御ルールに考慮することで、ユーザに対するシステムの柔軟性や利便性を高めるシステムとすることを特徴とする。
【００２１】
また、本発明ではサービス制御内容決定部で動的な制御ルールと各サービスに対する要求特性をのみを用いて、複数のサービス制御項目や制御内容を決定した後に、ネットワークリソースやデバイスの割り当てを行うことで、複数のサービスを同時に利用する際に、調停が必要なパラメータ数を減らすことを可能にし、さらにはリソースの割り当てを行う前に、ユーザがサービスに対して最低要求する品質をサービスが提供をできないと判断されるようなサービスヘのリソースの割り当てを事前に回避することで、提供が可能なサービスに対してのリソースの集中的な割り当てを実行することを特徴とする。
【００２２】
また、本発明ではコンテキスト解析部で提供される多様なサービスに対して、ネットワークから取得できる様々なコンテキストを用いて導出する各サービスに対する要求特性を、一部の特定相手や特定のサービスプロバイダに対して公開することで、サービス提供側（サービスプロバイダーおよび／または通信相手を含む）がユーザの状況を把握して、ユーザに必要かつ、ユーザがサービスを受け入れられるタイミングで、サービスを提供することを可能とすることを特徴とする。
【００２３】
また、本発明にかかるサービス制御方法は、コンテキスト解析部が、各サービスの制御方法を決定するプロセスを各サービスに対してネットワークから取得できる様々なコンテキストから各サービスに対して共通要素となる要求特性の導出するステップと、サービス制御内容決定部が、前記ステップで導出した各サービスに対する要求特性を用いて異なるサービスを比較し、統括的に扱うことで、各サービスの制御項目内容を決定するステップと、を有する。
【００２４】
上記に示した「サービス制御内容決定部」は具体的には複数のサービスを統括的に管理する「サービス制御内容決定部」とサービス内での具体的な制御内容を決定する「サービス制御内容決定部」に分かれる。以下では、前半の「サービス制御内容決定部」を「サービス管理」と呼び、後半の「サービス制御内容決定部」を「サービス」と呼ぶことで区別する。
【００２５】
本発明では、始めにサービス管理で、各サービスに対する要求特性を用いて、各サービスが要求する抽象資源（ユーザ資源など）に関して、競合が起こる場合は、各サービスに仮想的に抽象資源の割り当てを行う。
各サービスは割り当てられた抽象資源に基づいてサービスの提供方法（提供モード）を決定し、その後、その決定した提供モードに基づき、実資源を要求する。そして各サービスに実資源が割り当てられることによって決定した提供方法によって各サービスの制御が実行されることを特徴とする。
このサービスの提供方法の決定方法では、共通要素である要求特性を用いて共通資源である抽象資源の割り当てに基づいてサービスの提供方法を決定するため、全てのサービスに対して汎用な制御方式となる。
【００２６】
各サービスでは、割り当てられた抽象資源に基づいて、「提供開始」、「提供形態変更」、「提供拒否」といったダイナミックな制御内容を決定する。その後、割り当てられた実資源に基づいて、「継続」「一時中断」「停止」「終了」「再提供開始」「提供形態を変更」（各サービスが利用するデバイス、各サービスの品質、提供モード（TV電話から音声電話へ））といったような、より詳細な制御内容を決定する。
このようにサービス内で自律的により具体的な制御内容を決定する方法により、サービス管理では抽象資源，実資源に関するサービス間の調停を行えばよく、新規デバイス、サービスの新規制御項目に対する拡張性（システムの汎用性）を可能にすることを特徴とする。
【００２７】
さらに、本発明では、現在使用しているサービスに対して割り当てられている抽象資源の状況をサービス提供側（特定の相手やサービスプロバイダ）に公開することで、サービス提供側が、状況に応じて、ユーザがサービスを利用可能となる提供方法を選んで、サービスの提供を行うことができることを特徴とする。
また、本発明にかかるサービス制御プログラムおよびそのプログラムは前述のサービス制御システム／方法を実現するプログラムおよび記録媒体である。
【発明の効果】
【００２８】
本発明によって、同時に提供される複数のサービスに対して、コンテキストから導出されるユーザの各サービスに対する要求特性とサービス間の関連性等を考慮した統括的制御を行うことで、よりユーザ指向なサービス制御を可能にする。
また要求特性としてサービスを利用する際に必要となる、全てのサービスに対して共通な抽象資源を割り当て、各サービスは割り当てられた抽象資源の割当量に基づいて自律的にサービスの提供方法を選択して、提供方法を決定するという制御方法により、全く異なる複数サービスを汎用的に統括的制御することを可能にする。
さらに提供方法の決定において、複数サービスの利用の快適性に大きく影響する抽象資源の割り当てに基づいて提供方法を決定した後で、実資源の割り当てを行うようにすることで、ユーザ指向な制御内容を決定すること可能にする。
【発明を実施するための最良の形態】
【００２９】
以下、本発明を実施するための形態を実施例に基づいて説明する。
【実施例１】
【００３０】
図１（１）、（２）は本発明の実施例１のサービス制御システムを用いたシステム全体構成を示す図である。図１（１）は各アプリケーションに変換モジュールを追加する場合であり、図１（２）は各アプリケーションには何もしないで、変換モジュールをシステム側に追加する場合である。
【００３１】
サービス制御システムは、コンテキストを解析し、サービス制御内容を決定する「コア」となる部分と、ユーザにサービス制御システムに対するインターフェースを提示し、コアによって決定された制御命令を変換モジュールに提供する「要求アプリケーション」から構成される。図１において、１０１は、コンテキストを解析し、サービス制御内容を決定するコアであり、１０２は、コアによって決定された制御命令を変換モジュールに提供する要求アプリケーションである。１２１はアプリケーション１（ＶＯＤ（ビデオオンデマンド））であり、１２２はアプリケーション２（ＴＶ電話）であり、１２３はアプリケーション３（監視カメラ）である。１１１、１１２、１１３はそれぞれアプリケーション１、２、３に対応した、要求アプリケーションとの間のラッパーの機能を有する変換モジュールである。
【００３２】
要求アプリケーション１０２、及び、各アプリケーション１２１、１２２、１２３は、ユーザに対する入出力インタフェース機能、及び、制御要求の受付機能を有する。ユーザは、要求アプリケーション１０２、及び各アプリケーションのいずれに制御要求を行っても良い。ここで、制御要求は、後述する初期コンテキスト及び要求する制御内容を含む。ユーザが要求アプリケーション１０２に制御要求を行った場合には、要求アプリケーション１０２は、初期コンテキストに含まれるサービス名に対応するアプリケーションからアプリケーション固有のコンテキストを取得する。ユーザが各アプリケーションに制御要求を行った場合には、制御要求を受けたアプリケーションは、当該制御要求と自アプリケーションに固有のコンテキストを要求アプリケーション１０２に送る。その後、後述するように、制御要求にもとづいてコアによって決定される制御命令により各アプリケーションが統括的に制御される。
【００３３】
図１（１）では各アプリケーション１２１、１２２、１２３に変換モジュール１１１、１１２、１１３を追加することで、サービス制御システムは各アプリケーション１２１、１２２、１２３からコンテキストを取得し、またサービス制御システムから決定された制御命令をプロトコル変換を行い、各アプリケーション１２１、１２２、１２３を制御できる制御命令に変更して、各アプリケーション１２１、１２２、１２３に対して制御を行う。
【００３４】
図１（２）ではサービス制御システムに追加された各アプリケーションに対する変換モジュール１１１、１１２、１１３にてコンテキストを取得し、また決定された制御命令をプロトコル変換を行い、各アプリケーション１２１、１２２、１２３を制御できる制御命令に変更して、各アプリケーション１２１、１２２、１２３に対して制御を行う。
【００３５】
図２は、本発明の実施例１のサービス制御システムの構成図である。図２において、２０１はアプリケーションであり、２０２は変換モジュールであり、２１１は要求アプリケーションである。サービス制御システムに関連する構成要素は、以下のようなものが挙げられる。
【００３６】
『各アプリケーション（サービス）』
アプリケーション（サービス）２０１としては、例えば、ビデオ、電話等であり、サービス制御システムによって制御される対象である。
【００３７】
『変換モジュール』
変換モジュール２０２は以下のような機能を有し、前述のように、各アプリケーションに追加される場合とサービス制御システムに追加される場合とがある。
・要求アプリケーション２１１から提供される制御内容に基づいて、プロトコル変換をして、各アプリケーション２０１に制御命令する機能
・要求アプリケーション２１１から要求される各アプリケーション２０１のコンテキスト情報をプロトコル変換して取得する機能
【００３８】
『要求アプリケーション』
要求アプリケーション２１１は以下のような機能を有す。
・ユーザにシステムに対するインターフェース（入力、表示）を提供する機能
・コアにより決定された制御内容を各アプリケーション２０１の変換モジュール２０２ヘマッピングさせる機能
・ユーザのサービス制御内容の要求と各アプリケーション２０１から初期コンテキスト（ユーザ、使用サービス）を取得し、コア（サービス制御シナリオマネージャー）に提供する機能
初期コンテキストは例えば｛要求サービス名；発生方法；ユーザ名；サービスの緊急性；コンテンツ；要求ＡＰへのアクセス端末｝に関する情報であり、取得された初期コンテストは初期コンテキストＤＢ（図示していない）に保存される。図１０の表１に初期コンテキストＤＢの例を示す。
【００３９】
『コア』
コアは以下のような構成要素から成る。
・サービス制御シナリオマネージャー２２１
・コンテキスト解析部２３１
−コンテキスト解析２３２
−コンテキスト選択ＤＢ２３３
−コンテキスト取得２３４
・コンテキスト２４１
−コンテキストＤＢ２４２
−センサ２４３
・制御内容決定部（サービス制御内容決定部）２６１
−制御内容決定２６２
−制御ルール導出２６３
・要求特性ＤＢ２５１
・プレゼンスマネージャー２７１
【００４０】
またコアの各構成要素は以下のような機能を有す。
「サービス制御シナリオマネージャー２２１」
・要求アプリケーション２１１からサービス制御シナリオ要求を受け付ける機能
・要求アプリケーション２１１から初期コンテキストを受け付ける機能
・コンテキスト解析２３２に要求特性を要求し、取得する機能
・制御内容決定２６２にサービス開始／着信可否及び制御内容を要求し、取得する機能
・要求アプリケーション２１１に対して、決定された制御内容を提供する機能
【００４１】
「コンテキスト解析２３２」
・サービス制御シナリオマネージャー２２１から要求特性を受け付け、提供する機能
・対象サービスに対して必要なコンテキスト群をコンテキスト選択ＤＢ２３３に要求し、取得する機能
・コンテキスト取得２３４に必要となるコンテキストを要求し、取得する機能
・取得したコンテキストからコンテキスト解析アルゴリズムにより要求特性を計算する機能（図３に要求特性導出フローの例を示す。）
・得られた要求特性を要求特性ＤＢ２５１に登録する機能
【００４２】
「コンテキスト選択ＤＢ２３３」
・サービスと要求特性と要求特性導出に必要なコンテキストのデータベース
コンテキスト選択ＤＢ２３３は、例えば、｛サービス；要求特性；必要なコンテキスト群｝に関する情報を保存するＤＢであり、図１１の表２にコンテキスト選択ＤＢの例を示す。
【００４３】
「コンテキスト取得２３４」
・コンテキスト解析２３２から必要なコンテキスト群を受け付け、静的／動的コンテキストを判別する機能
・静的／動的コンテキストをそれぞれ要求し、取得する機能
・静的／動的コンテキストをコンテキスト解析２３２に提供する機能
【００４４】
「コンテキストＤＢ２４２」
・コンテキスト取得２３４からコンテキスト要求を受け付け、提供する機能
・静的コンテキスト、動的コンテキストのデータベース
コンテキストＤＢ２４２は、例えば、｛種類；属性；静的（プロファイル）；動的（センサ情報、更新あり）｝に関する情報を保存するＤＢであり、図１２の表３にコンテキストＤＢの例を示す。
【００４５】
「センサ２４３」
・コンテキスト取得２３４からコンテキスト要求を受け付け、提供する機能
・対象物に対してセンシングする機能
【００４６】
「制御内容決定２６２」
・サービス制御シナリオマネージャー２２１からサービス開始／着信可否及び制御内容を受け付け、提供する機能
・制御ルール導出２６３に着信ルール、制御ルールを要求し、取得する機能
・着信ルール、制御ルールとサービスの要求特性から制御内容を判断し、決定する機能（図４にサービス制御内容決定フローの例を示す。）
・プレゼンスマネージャー２７１にネットワークリソース、デバイスの使用状況を要求し、取得する機能
・決定した制御内容（ＱｏＳパラメータ等の決定）と取得したネットワークリソース、デバイスの使用状況から、（サービス品質割り当てアルゴリズムより）制御内容のいくつか候補をサービス制御シナリオマネージャー２２１に提供する機能
【００４７】
「制御ルール導出２６３」
・制御内容決定２６２から着信ルール、制御ルールの要求を受け付け、提供する機能
・要求特性ＤＢ２５１から利用されている全サービスの要求特性を要求し、取得する機能
・要求特性とサービス制御アルゴリズムにより開始／着信ルールや制御ルールを動的に決定する機能
【００４８】
「要求特性ＤＢ２５１」
・ユーザのサービスに対する要求特性のデータベース
要求特性ＤＢ２５１は、例えば、｛ユーザＡ；提供中／要求；サービス名；要求特性｛Ａ、Ｂ、Ｃ、…｝｝に関する情報を保存するデータベースであり、図１３の表４に要求特性ＤＢの例を示す。
【００４９】
『プレゼンスマネージャー２７１』（このような機能をもつサーバを立てておく）
・ネットワークリソースやデバイスの使用状況を把握する機能
・ネットワークリソースやデバイスの使用状況要求を受け付け、提供する機能
【００５０】
以下、本発明の実施例１の動作を説明する。ここでは、ユーザが要求アプリケーションに対して制御要求を行ったとする。図５は実施例１のサービス制御システムの構成図にコンテキスト解析のフローを示した図であり、図６は実施例１の動作を示すフローチャート（コンテキスト解析のフロー）であり、図７は実施例１のサービス制御システムの構成図にサービス制御内容決定のフローを示した図であり、図８は実施例１の動作を示すフローチャート（サービス制御内容決定のフロー）である。
【００５１】
ユーザが第１のサービスを受けている時に、ユーザが第２のサービスを要求、あるいは第２のサービスが着信すると、「要求アプリケーション２１１」に対して、ユーザ名、要求サービス名等の初期コンテキストの通知が行われる。
【００５２】
以下、コンテキスト解析のフローを図５（１）、図５（２）、図６を参照して説明する。
［１］  「要求アプリケーション２１１」は「サービス制御シナリオマネージャー２２１」に対してサービス制御シナリオの要求と初期コンテキスト（ユーザ、利用するサービス）の通知を行う。
［２］  「サービス制御シナリオマネージャー２１１」は「コンテキスト解析２３２」に対して、サービスに対する要求特性の要求を行う。
［３］  「コンテキスト解析２３２」は「コンテキスト選択ＤＢ２３３」に対して、利用サービスの通知を行う。
［４］  「コンテキスト選択ＤＢ２３３」（図１１の表２参照）にてサービス名からマッチングさせて、取得が必要となるコンテキスト群を取得する。
［５］  「コンテキスト解析２３２」は「コンテキスト取得２３４」に対して、取得が必要となるコンテキスト群を通知する。
（１）「センサ２４３」がある一定時間に動的コンテキスト情報を更新している場合（図５（１）、図６参照）
［６］〜［７］  「コンテキスト取得２３４」は静的コンテキスト、動的コンテキストを判別して、「コンテキストＤＢ２４２」（図１２の表３参照）から取得が必要とされるコンテキストを取得する。
（２）サービスの要求があるたびに「センサ２４３」が動的コンテキスト取得する場合（図５（２）、図６参照）
［６］〜［９］  「コンテキスト取得２３４」は取得が必要とされるコンテキスト群を静的コンテキスト、動的コンテキストに判別して、静的コンテキストは「コンテキストＤＢ２４２」（図１２の表３参照）から、動的コンテキストは「センサ２４３」から取得する。
（１）の場合は図５（１）、図６の［８］、（２）の場合は図５（２）、図６の［１０］  「コンテキスト取得２３４」は取得したコンテキストの内容を「コンテキスト解析２３２」に通知し、「コンテキスト解析２３２」にて、取得コンテキストを数値化し、コンテキスト解析アルゴリズムにて計算を施すことで、利用要求、着信サービスの要求特性を求める。
（１）の場合は図５（１）、図６の［９］、（２）の場合は図５（２）、図６の［１１］  「コンテキスト解析２３２」は「サービス制御シナリオマネージャー２２１」に導出した要求特性を提供する。
（１）の場合は図５（１）、図６の［１０］、（２）の場合は図５（２）、図６の［１２］  また「要求特性ＤＢ２５１」にサービスに対する要求特性を登録する（図１３の表４参照）。
以上のフローにより、サービス制御シナリオマネージャー２２１に要求特性が提供され、また要求特性ＤＢ２５１に要求特性が登録される。
【００５３】
以下、サービス制御内容決定のフローについて図７（１）〜図７（３）、図８（１）〜図８（３）を参照して説明する。
まず、＜サービス開始／着信拒否の場合＞について図７（１）、図８（１）を参照して説明する。
［１］  前述のようにコンテキスト解析２３２から要求特性の通知を受けた後、「サービス制御シナリオマネージャー２２１」は「制御内容決定２６２」に対してサービス開始／着信可否及び制御内容決定の要求を行う。このとき取得した要求特性を引数にもつ。
［２］  「制御内容決定２６２」は「制御ルール導出２６３」に対して開始／着信ルールの要求を行う。
［３］、［４］  「制御ルール導出２６３」は「要求特性ＤＢ２５１」（図１３の表４参照）に対して現在利用されているサービスの要求特性を要求し、取得する。
［５］  「制御ルール導出２６３」は、取得した全てのサービス情報（要求特性を含む）とサービス間に生じる関連性を用いて、開始／着信ルールを決定し、「制御内容決定２６２」に通知する。
［６］  「制御内容決定２６２」は取得した開始／着信ルールと引数として取得したサービスの要求特性から開始／着信の判断を行う。
［７］  「サービス制御シナリオマネージャー２２１」は「要求アプリケーション２１１」ヘサービス開始／着信の拒否の通知とともにサービス制御のタイムシフト制御の選択を要求する。
（Ａ）タイムシフト制御が容認の場合
［８−Ａ］  ユーザから要求アプリケーション２１１を介して、「サービス制御シナリオマネージャー２２１」ヘタイムシフト制御の依頼の通知と選択が行われると、
［９−Ａ］  「サービス制御シナリオマネージャー２２１」から「要求アプリケーション２１１」へ選択されたタイムシフト制御内容、設定項目内容等の通知を行い、「要求アプリケーション２１１」が各サービスに制御を行う。
（Ｂ）タイムシフト制御が否認の場合
［８−Ｂ］  ユーザから要求アプリケーション２１１を介して、「サービス制御シナリオマネージャー２２１」ヘタイムシフト制御の否認が行われると、
［９−Ｂ］  「サービス制御シナリオマネージャー２２１」から「要求アプリケーション２１１」へ選択されたサービス終了の命令を行う。
［１０］  「要求アプリケーション２１１」が各サービスに制御命令を行う。
【００５４】
次に、＜サービス開始／着信許可−リアルタイム制御容認の場合＞について図７（２）、図８（２）を参照して説明する。
（＊）リアルタイム制御が必要な場合（サービス開始／着信の制御以外の制御内容）
［１］〜［５］までは＜サービス開始／着信拒否の場合＞と同じである。
［６］  「制御内容決定２６２」は取得した開始、着信ルールと引数として取得したサービスの要求特性から開始／着信の判断を行う。
「制御内容決定２６２」にて開始／着信の許可が決定されると、
［７］〜［８］  「制御内容決定２６２」は「制御ルール導出２６３」へ制御ルールを要求し、取得する。
［９］〜［１０］  「制御内容決定２６２」は「プレゼンスマネージャー２７１」に対して利用可能なデバイス、ネットワークリソース等を要求して取得する。
［１１］  「制御内容決定２６２」は取得した制御ルール（サービス品質割り当てアルゴリズム）と取得したネットワークリソース、デバイスの使用状況から、デバイス、ネットワークリソースの割り当てを行い、制御内容（ＱｏＳパラメータ等）を決定する。その際に、コンテキスト、利用履歴情報によりユーザに対して最適とされるサービス制御内容の組み合わせのいくつかの候補を順位付けして、いくつか選出し、「制御内容決定２６２」は「サービス制御シナリオマネージャー２２１」に対して、サービスの開始／着信の判断結果と合わせて制御内容の通知を行う。
［１２］  「サービス制御シナリオマネージャー２２１」は「要求アプリケーション２１１」ヘサービス制御がリアルタイム制御の決定を通知する（制御内容選択要求）。
［１３］  ユーザから要求アプリケーション２１１を介して、「サービス制御シナリオマネージャー２２１」ヘリアルタイム制御の依頼の通知と制御内容の選択が行われる。
［１４］  「サービス制御シナリオマネージャー２２１」から「要求アプリケーション２１１」へ選択された制御内容に基づいてリアルタイム制御の通知を行う。
［１５］  「要求アプリケーション２１１」が各サービスに制御命令を行う。
【００５５】
次に、＜サービス開始／着信許可−リアルタイム制御が否認の場合＞について図７（３）、図８（３）を参照して説明する。
［１］〜［１２］  まで＜サービス開始／着信許可−リアルタイム制御容認の場合＞と同じである。
［１３］  ユーザから要求アプリケーション２１１を介して、「サービス制御シナリオマネージャー２２１」ヘリアルタイム制御の否認が行われる。
［１４］  「サービス制御シナリオマネージャー２２１」は「要求アプリケーション２１１」ヘサービス制御のタイムシフト制御の選択を通知する。
（Ａ）タイムシフト制御が容認の場合
［１５−Ａ］  ユーザから要求アプリケーション２１１を介して、「サービス制御シナリオマネージャー２２１」ヘタイムシフト制御の依頼の通知と選択が行われる。
［１６−Ａ］  「サービス制御シナリオマネージャー２２１」から「要求アプリケーション２１１」へ選択されたタイムシフト制御の命令を行い、「要求アプリケーション２１１」が各サービスに制御を行う。
（Ｂ）タイムシフト制御が否認の場合
［１５−Ｂ］  ユーザから要求アプリケーションを介して、「サービス制御シナリオマネージャー２２１」ヘタイムシフト制御の否認が行われる。
［１６−Ｂ］  「サービス制御シナリオマネージャー２２１」から「要求アプリケーション２１１」へ選択されたサービス終了の命令を行い、「要求アプリケーション２１１」が各サービスに制御を行う。
［１７］  「要求アプリケーション２１１」が各サービスに制御命令を行う。
【００５６】
以上のように、同時に提供される複数のサービスに対して、コンテキストから導出されるユーザの各サービスに対する要求特性とサービス間の関連性等を考慮した統括的制御が行われる。
【００５７】
以下、提案システムを用いたサービスの例を示す。
１．映像・通信系サービスにおける複数のサービス
・複数のサービスが電話、ビデオオンデマンド（ＶＯＤ）、赤ちゃん監視用カメラである場合
モニタに赤ちゃん用監視カメラのリアル映像をモニタの端に表示させながら、ＶＯＤサービスで映画を視聴している時に、電話の着信が起こった時、
電話の発信者が非認証者で、緊急性を有していない電話と判断できたため、システムはユーザに対して電話着信通知のみを行い、電話を自動応答モードに切り替えることを提案した。自動応答モードに関しても、発信者に対する信頼度、緊急度に応じた対処を促すような応答が可能になる。
電話の発信者が登録者で緊急性を有しているような場合は、電話を着信モードに切り替え、その際にＶＯＤサービスは自動的にタイムシフト制御（一時停止）を行う。
一方、赤ちゃんが泣き出したのをセンサにより感知することで、ＶＯＤサービスにタイムシフト制御（一時停止、停止、ハードディスクヘダウンロード）を行い、赤ちゃんの映像を全画面に表示するように自動的に切り替わる。
上記は要求特性として、各サービスに対する重要度、緊急度、リアルタイム性、品質等を用いることで複数のサービスの統括的制御を可能としている例である。
【００５８】
・複数のサービスがオンラインゲーム、チャットである場合
オンラインゲームとチャットサービスを同時に利用している際に、通常はオンラインゲームを全画面に表示させてゲームを行うが、ユーザがあらかじめキーワードや特定のチャットの相手等を指定しておくことで、ユーザが希望するチャット（内容、相手）を行うことが可能となったときに、チャット画面を表示させ、場合によってはゲームを一時停止させて、チャットサービスを自動的に促す。
上記は要求特性として、各サービスに対する重要度、緊急度等を用いることで複数のサービスの統括的制御を可能としている例である。
【００５９】
２．制御系（白物家電系）サービスにおける複数のサービス
・複数のサービスが照明機器、カーテン、エアコンの制御である場合
ユーザが時間帯や人の存在、サービスに応じて要求する室温や明るさをあらかじめ設定しておくことで、ユーザの様々な状況に応じて、照明機器、カーテン、エアコン等を制御ルール（ポリシー）に従って自動的に連動させる。さらに制御ルールによっては省エネ効果（コスト削減）やサービスの臨場感を高めることができる。
例えば、部屋の明るさを調節できるものとして、天気、照明機器の照度、カーテンの開閉等が挙げられる。人の存在、時間帯に要求する明るさに対して、コストを最小限にするように、天気に応じて照明機器やカーテンを統括的制御することで明るさを調整したり、また使用しているサービス（コンテンツ）に応じて、臨場感を高めるように推奨照度、温度等を考慮して、それらを統括的制御することが可能となる。
上記は要求特性として、各制御サービスに対する緊急度、精度、コスト等を用いることで複数の制御サービスの統括的制御を可能としている例である。
【００６０】
３．要求特性をユーザの他サービスに対する許容度として利用
図９に本発明の実施例１のサービス制御方法を用いたサービス提供方法のを示す。
現在、ユーザが利用している全サービスの要求特性を用いることで、ユーザの現在の「忙しさ」「使用サービスの重要度（緊急度）」を表すコンテキスト（他サービスの受入許容度）として表すことができる。例えば要求特性から導出される他のサービスの着信許可等に関するルール等を抽象化したユーザ状況コンテキストとして、公開レベルに応じて一部の特定の人に対して公開することで、サービスプロバイダや広告主、電話発信者といったサービス提供者は、リアルタイムにサービス受信者の状況に応じて、ユーザに必要かつ、ユーザがサービスを受け入れられるタイミングで、サービスを提供することを可能とする。
【実施例２】
【００６１】
図１４は本発明の実施例２のサービス制御方式を用いたサービス制御システムのソフトウエア構成例である。サービス制御システムはその機能の面から図１４のような階層構造で表すことができる。各層の役割は以下のようである。
【００６２】
「サービス間制御層」（サービス管理プログラム）
全てのサービスに対して汎用的な存在となる。異なる複数のサービスに対して統括的制御を行うため、ユーザの各サービスに対する要求特性を用いて、要求する抽象資源（ユーザ資源など）、実資源（デバイス、リンク帯域など）に対する割り当て計算を行う。
各サービスが割り当てられた資源に対して行う実行可否等の判断結果に対して、再要求指示及び実行開始指示を行う。
【００６３】
「サービス生成層」（サービスプログラム）
サービスの提供開始（または変更、停止）、及びサービスに関連するコンテキストの変化（イベントの発生など）の際に、サービスに関連するコンテキストを収集する。またサービスにてコンテキストを解析する際には、収集したコンテキストからユーザのサービスに対する要求特性を導出する。
【００６４】
サービスはサービスの提供方法を以下に示すモード、グレード、リソースの３つの側面の組み合わせによって構成する。
・モード：サービスの提供形態を表し、サービスを提供する際に必要となる抽象資源（ユーザ資源）の違いとして見ることができる。ＴＶ電話サービスを例とするとＴＶ電話モードでは「目、耳、口」、音声電話モードでは「耳、口」というユーザ資源を必要とし、留守番電話モードではユーザ資源を必要しなくなるというように、提供モードによって必要とするユーザ資源の種類が異なる。
・リソース：サービスを提供する上で必要となる実資源そのものを表し、サービスは様々なリソースの組み合わせによって提供される。リソースには、カメラ、マイク、ディスプレイ、スピーカといった入出力装置（デバイス）から、ソフトウエアといったアプリケーション資源、またイーサネット、無線ＬＡＮのようなリンクというようにホームネットワーク上に存在するあらゆる装置や機能までを含める。
・グレード：サービスが提供する品質において必要とする実資源量の違いを表す。例えば、ビデオ表示サービスを例とすると、音量の大きさ、画面の大きさ、リンク帯域の容量などが挙げられ、サービスが利用する実資源量の違いによってサービス品質や提供方法のインパクトを変えることができる。
【００６５】
サービスはユーザにとって最適となる提供方法（抽象資源を数多く必要とし、実資源量を多く必要とし、ユーザにとって都合のよいデバイスを利用する）を高順位として、動的に提供可能となる提供方法を順位付けする。最低順位のサービス提供方法として「停止」があり、停止はサービスが全く動作せず、全く資源を使わない提供方法を意味することとする。
【００６６】
映像コミュニケーションサービスを例としたサービスの提供方法の遷移の例を図１５に示す。
割り当てられた抽象資源（ユーザ資源など）に基づいて、サービスは提供可能となる提供方法のうち高順位にあたる提供モードを選択し、その提供モードを実現するために必要な実資源を要求する。そして、割り当てられた実資源量に対して選択した提供方法が実行可能かどうか判断を行う。
サービスの判断結果に対するサービス管理プログラムからの再要求指示及び実行開始指示に対して、再要求指示の場合は、要求特性（提供モード）を変更してサービス管理プログラムに再提示する。あるいは要求する提供モードは変更せず、要求する実資源を変更してサービス管理プログラムに再要求提示を行う。
実行開始指示の場合は、ホームネットワーク（ＨＮＷ）資源管理プログラムから各資源の割当完了通知を取得した後、決定した提供方法を実行する。または、ＨＮＷ資源管理プログラムに割り当てられた各資源の割当量を要求し、取得した後、決定した提供方法を実行する。
【００６７】
「資源管理層」（ホームネットワーク資源管理プログラム、プロファイル管理プログラム）
・ホームネットワーク（ＨＮＷ）資源管理プログラム：
ＨＮＷ上に存在する実資源（デバイス、リンク帯域など）、抽象資源（ユーザ資源、ロケーション資源など）を一元的に管理し、現在、提供されているサービスに対する割当量などを管理している。
サービス管理プログラムが各サービスに対して実行開始指示を行い、サービス管理プログラムからＨＮＷ資源管理プログラムに対して各資源の各サービスに対する割当量の通知が行われた後、ＨＮＷ資源管理プログラムは各資源が各サービスに対して決定された割当量となるように、各資源に対して各サービスへの資源の解放、割り当てを実行する。
・プロファイル管理プログラム：
ユーザの嗜好やスケジュールといったプロファイル情報やユーザの位置情報などのユーザのコンテキストをユーザ毎に管理し、天気、気温、湿度といった一般情報となるコンテキストなどを管理している。サービスが要求特性を導出する際に必要とするコンテキストをサービスに提供する。
【００６８】
「資源層」
サービスを構築する上で必要となる要素となるそのものを指す。端末機器だけでなく、利用するソフトウエア、アプリケーション、ユーザの嗜好情報、ＴＶ番組表、といったものも資源として扱い、さらに電話におけるコネクション、ユーザ資源、ロケーション資源といった抽象資源も仮想的な資源として扱う。
また資源の各サービスへの割り当てについては、離散的な数値で割り当てる資源や連続的な数値で割り当てる資源など、各資源の特徴によって異なる。
各資源はＨＮＷ資源管理プログラムやプロファイル管理プログラムに管理される。
【００６９】
図１６（１）〜図１６（４）は本発明の実施例２のサービス制御システムの構成図である。本発明の実施例２のサービス制御システムにおいて主要となる「サービス管理プログラム」「サービスプログラム」「ＨＮＷ資源管理プログラム」における基本的な構成要素（モジュール）は主に以下のようなものが挙げられる。
【００７０】
『サービス管理プログラム』
サービス管理プログラムの構成図を図１６（１）に示す。サービス管理プログラムは前述したような機能を有し、主に以下のようなモジュール及びＤＢによって構成されている。
・サービス登録モジュール
・登録サービスＩＤＤＢ
・要求抽象資源導出モジュール
・抽象資源割り当てモジュール
・要求特性ＤＢ
・実資源割り当てモジュール
・再要求指示及び実行指示モジュール
『サービス管理プログラム』の各モジュールは主に以下のような機能を有す。
「サービス登録モジュール」
・サービスから登録の要求を受け付ける機能
・登録サービスＩＤＤＢにサービスＩＤの発行を要求し、取得する機能
・登録が完了したらサービスにサービスＩＤを発行する機能
「登録サービスＩＤＤＢ」
・新規に発行するサービスＩＤを保持しているデータベース
「要求抽象資源導出モジュール」
・サービスから通知される要求特性を受け付ける機能
・サービスから取得した要求特性を要求特性ＤＢに登録する機能
・要求特性からサービスが要求する抽象資源を導出する機能
「要求特性ＤＢ」
・各サービスの要求特性の各値を保持しているデータベース
「抽象資源割り当てモジュール」
・要求特性を通知したサービスの要求する抽象資源を受け取る機能
・要求特性ＤＢに対して、各サービスの要求特性の各値を要求し、取得する機能
・ＨＮＷ資源管理プログラムに対して抽象資源の使用状況（各サービスへの割り当て状況）を要求して、取得する機能
・各サービスに対する抽象資源の割当量を計算し、各サービスに通知する機能
「実資源割り当てモジュール」
・ＨＮＷ資源管理プログラムに対して各サービスが要求する実資源の割当量とそれらの実資源の使用状況（各サービスへの割り当て状況）を要求し、取得する機能
・実資源の使用状況から、抽象資源の割当量を通知した以外の関連性のあるサービスを新たに抽出し、それらのサービスに対して、抽象資源の割当量の通知を行う機能
・要求特性の各値から各サービスへの実資源の割当量を計算し、各サービスに通知する機能
「再要求指示及び実行指示モジュール」
・各サービスから実資源の割当量に対するサービスの提供可否の判断結果の通知を受け取る機能
・全てのサービスから通知される判断結果から、各サービスに対して再要求指示または、実行開始指示を行い、ある特定のサービス、あるいは全てのサービス対する指示内容を通知する機能
・全てのサービスからの判断結果が「実行可能」となり、全てのサービスに実行開始指示を通知した後、ＨＮＷ資源管理プログラムに対して決定した各サービスに対する抽象資源、実資源の割当量を通知する機能
【００７１】
『サービスプログラム』
図１６（２）にサービスプログラムの構成図を示す。サービスプログラムは前述したような機能を有し、主に以下のようなモジュール及びＤＢによって構成されている。
・要求特性導出モジュール
・提供モード決定モジュール
・要求実資源導出モジュール
・提供可否判断モジュール
・再要求提示モジュール
・資源割当状況変化検出モジュール
・実行開始モジュール
【００７２】
『サービス管理プログラム』の各モジュールは主に以下のような機能を有す。
「要求特性導出モジュール」
・プロファイル管理プログラムからコンテキストを要求し、取得して、要求特性の各値を導出する機能（サービスにてコンテキストを解析する場合）
・サービス管理プログラムに導出した要求特性を通知する機能
「提供モード決定モジュール」
・サービス管理プログラムから割り当てられた抽象資源に基づいて、提供可能なサービスの提供方法（提供モード）を順位付けし、高順位となる提供方法を選択する機能
「要求実資源導出モジュール」
・選択した提供方法を実現する上で必要となるリソース（デバイスやリンク帯域など）を導出し、ＨＮＷ資源管理プログラムに対して要求する機能
「提供可否判断モジュール」
・ＨＮＷ資源管理プログラムから割り当てられた実資源量の通知を受け取る機能
・割り当てられた実資源量に対して、提供可否の判断を行う機能
・サービス管理プログラムに提供可否の判断結果を通知する機能
「再要求提示モジュール」
（抽象資源の再要求指示を受けた場合）
・サービスは提供モードを低順位に下げた提供モードを変更し、再度、サービス管理プログラムに要求特性を通知する機能
（実資源の再要求指示を受けた場合）
・サービスは提供グレードを低順位に下げた提供グレードを選択、あるいは要求するリソース（デバイスなど）を変更して、再度、ＨＮＷ資源管理プログラムに実資源を要求する機能
「資源割当状況変化検出モジュール」
・実資源、抽象資源の割り当て状況に変化があった際に、ＨＮＷ資源管理プログラムからの通知を受け取る機能
「実行開始モジュール」
・サービス管理プログラムから実行開始指示を受け取り、ＨＮＷ資源管理プログラムに対して、割り当てられた抽象資源、実資源の割り当て通知を受け取った後、決定した提供方法でサービスを実行する機能
【００７３】
『ＨＮＷ資源管理プログラム』
図１６（３）にＨＮＷ資源管理プログラムの構成図を示す。ＨＮＷ資源管理プログラムは前述したような機能を有し、主に以下のようなモジュール及びＤＢによって構成されている。
・資源割当状況通知モジュール
・実資源ＤＢ
・抽象資源ＤＢ
【００７４】
『ＨＮＷ資源管理プログラム』の各モジュールは主に以下のような機能を有す。
「資源割当状況通知モジュール」
・サービス管理プログラムやサービスから、資源の割り当て状況の要求があった際に、実資源ＤＢ、抽象資源ＤＢから各資源割り当て状況を取得し、提供する機能
・サービス管理プログラムから、各サービスの各資源の割当量の更新通知があったときに実資源ＤＢ、抽象資源ＤＢを更新する機能
・実資源、抽象資源の割り当て状況を監視しており、実資源ＤＢ、抽象資源ＤＢを更新するなどして資源の割り当て状況に変化があった際に、サービスに通知を行う機能
「実資源ＤＢ」
・サービスに対する実資源（デバイス、リンク帯域など）の割り当て状況を保持しているデータベース
「抽象資源ＤＢ」
・サービスに対する抽象資源（ユーザ資源、ロケーション資源など）の割り当て状況を保持しているデータベース
【００７５】
『プロファイル管理プログラム』
図１６（４）にプロファイル管理プログラムの構成図を示す。プロファイル管理プログラムは前述したような機能を有し、主に以下のようなモジュール及びＤＢによって構成されている。
・コンテキスト取得モジュール
・コンテキスト選択ＤＢ
・プロファイルＤＢ
・センサ情報取得モジュール
【００７６】
『プロファイル管理プログラム』の各モジュールは主に以下のような機能を有す。
「コンテキスト取得モジュール」
・サービスからコンテキストの要求を受け付け、提供する機能（サービスにてコンテキストを解析し、要求特性の値を導出する場合）
・コンテキスト選択ＤＢに対してコンテキストを要求するサービスにおいて関連対象とするコンテキストの種類を要求し、取得する機能
・プロファイルＤＢやセンサ情報取得モジュールからコンテキスト情報を取得する機能
・コンテキスト情報から各サービスに対応する要求特性の各値を導出する機能（プロファイル管理プログラムにてコンテキストを解析し、要求特性の値を導出する場合）
「コンテキスト選択ＤＢ」
・サービスが対象とするコンテキスト種を保持しているデータベース
「プロファイルＤＢ」
・ユーザの嗜好やスケジュールといったユーザのコンテキストなどプロファイル情報（静的なコンテキスト）を保持しているデータベース
「センサ情報取得モジュール」
・コンテキスト取得モジュールから各センサのセンシング情報（動的なコンテキスト）の要求を受け付け、コンテキスト取得モジュールに提供する機能
・各センサにアクセスしてセンシング情報を取得する機能
【００７７】
以下、本発明の実施例２のサービス制御内容の決定方法を用いたサービス制御システムの動作を説明する。図１７（１）〜図１７（３）は実施例２のサービス制御システムの動作を示すシーケンス図（サービスの提供方法の決定フロー）をサービス管理プログラム、サービスプログラム、ＨＮＷ資源管理プログラム、プロファイル管理プログラムを中心に示したものであり、図１８、図１９（１）〜図１９（４）、図２０はサービス制御システムの一実施例の構成図にサービスの提供方法の決定フローを示した図である。図１７（１）〜図１７（３）、図１８〜図２１における実施例２のサービス制御システムの動作に関しては、要求特性として重要度、抽象資源としてユーザ資源のみを用いてサービスの提供方法の決定するフローである。
ユーザがあるサービスを利用している時に、第２のサービスを要求、あるいは第２のサービスが着信するというようにして、複数サービスを同時に利用する場面を例として、それぞれのサービスの提供方法（制御内容）を決定する動作を説明する。
また図１７（１）〜図１７（３）に関して、サービス管理プログラムとサービスプログラムの関係において、サービスがとりうる状態とその状態遷移を図２２に示す。各状態は主に以下のような状態を示す。
【００７８】
（定常状態）
サービス管理プログラムに対して、何の要求もせず、何の指示も受けていない状態。サービスの登録直後はこの状態となる。
ペンディングになっていたコンテキストに変化が起きたり、ＨＮＷ資源管理プログラムから資源の割り当て状況の変化通知を受け取るなどして、コンテキストが変化すると、コンテキストを収集して、新しい要求特性値を計算し、サービス管理プログラムに対して通知する。そして、抽象資源要求状態に遷移する。重要度などの要求特性の値が再計算されるのは、この時点のみであり、他の場合に要求特性を通知することがあっても、この時点で計算した値を常に通知する。
【００７９】
（抽象資源要求状態）
サービス管理プログラムに対して、抽象資源（ユーザ資源など）の割り当て要求をしている状態である。
この状態では、サービス管理プログラムから、抽象資源の割り当てが通知されるのを待つ。抽象資源の割り当てが通知されると、通知された抽象資源の割当量の範囲内でのサービス提供方法を生成し、それに優先順位をつける。その後、最高位の提供方法を選択し、実資源要求状態に遷移する。
【００８０】
（実資源要求状態）
ＨＮＷ資源管理プログラムに対して、実資源を要求をしている状態である。
現在選択されているサービス提供方法に基づいて、要求する実資源量を導出し、ＨＮＷ資源管理に要求する。そして、割り当てられた実資源量に基づいて、提供可否判断を行い、サービス管理プログラムに判断結果を通知する。通知を行うと直ぐに、指示待機状態に遷移する。
ただし、抽象資源の割り当てに対して割り当てられた抽象資源の割当量が、要求特性としてサービス管理プログラムに通知した必要最低抽象資源量を下回っている場合には、実資源の割り当て要求において、何も要求しないという要求を行い、その後の判断結果にて、モードの変更か、停止をサービス管理プログラムに通知する。
【００８１】
（指示待機状態）
サービス管理プログラムから新しく割り当てられた各資源の割当量から決定した、サービス提供方法を開始するかどうか指示をサービス管理プログラムから待っている状態である。
この状態では、サービス管理プログラムから、抽象資源の再割り当てまたは、再要求指示及び実行指示が通知されるのを待つ。
抽象資源の再割り当てが通知されると、抽象資源要求状態に遷移し、再度、通知された新しい抽象資源の割当量の範囲内でのサービス提供方法を生成し、それに優先順位をつけ、最高位の提供方法を現在の提供方法として選択し、実資源要求状態に遷移する。
再要求指示及び実行指示が通知されると、指示の内容によって、抽象資源要求状態、実資源要求状態、または、通常状態に遷移する。実資源要求状態に遷移する場合は、現在選択しているサービス提供方法（提供モード）を指示の内容に従って変更してから、実資源要求状態に遷移する。
【００８２】
［新規発生サービスの登録］
新規発生サービスの登録について図１８を用いて説明する。
［１］  新規にサービスの要求（着信）が行われると、サービスプログラムはサービス管理プログラムに登録通知を行う。
［２］  サービス管理プログラムは登録サービスＩＤＤＢから発行するサービスＩＤを要求して、取得する。
［３］  サービス管理プログラムはサービスプログラムに対してサービスＩＤを発行する。
【００８３】
［要求特性の導出］
＜ユーザが自らサービスを開始、変更、停止を行う場合＞
図１９（１）を用いて、サービスプログラムがコンテキストを解析することによって要求特性を導出する場合について説明する。
［１］  サービスプログラムは、新規に提供開始（または変更、停止）する際に、プロファイル管理プログラムにサービスプログラムに関連するコンテキストの要求を行う。
［２］  プロファイル管理プログラムは必要なコンテキストをプロファイルＤＢやセンサから収集し、サービスプログラムに提供する。
［３］  サービスプログラムは取得したコンテキストからサービスプログラムにあるコンテキスト解析モジュールにより、要求特性を導出する。要求特性の各値の導出における計算フローは実施例１の図３を参照。そして、サービスプログラムは、導出した要求特性をサービス管理プログラムに通知する。
実施例１（図３）、実施例２におけるコンテキスト解析モジュール（コンテキスト解析アルゴリズム）での要求特性である重要度の計算方法の一例として、ニューラルネットワークを用いた計算モデルや決定木を用いた分類モデルなどを適応させることで、重要度を動的に導出する。
・ニューラルネットワークモデル
重要度が様々なコンテキスト情報を総合評価することで、導出されるという考えのもと、ニューラルネットワークモデルが適応することができる。ニューラルネットワークでは、数値化した初期データを用いた再学習法によって計算モデルを作成する。そして未知データに対して作成された計算モデルに代入して計算することによって重要度を導出する。
・決定木モデル
重要度が様々なコンテキストの中でもユーザが主要とするコンテキストが大きく影響して、導出されるという考えのもと、決定木を構築して事象を分類する決定木モデルを適応することができる。決定木モデルでは、初期データを用いて最も多くのデータを正しく分類するような決定木を構築する。そして未知データに対して作成された決定木で分類することによって重要度を導出する。
【００８４】
図１９（２）を用いて、プロファイル管理プログラムがコンテキストを解析することにより要求特性を導出する場合について説明する。
［１］  サービスプログラムは、新規に提供開始（または変更、停止）する際に、プロファイル管理プログラムに要求特性の要求を行う。
［２］  プロファイル管理プログラムはコンテキスト選択ＤＢに対して、要求のあったサービスに関連のあるコンテキストをマッチングさせて、関連性のあるコンテキストの種類を取得する。
［３］  プロファイル管理プログラムは必要なコンテキストをプロファイルＤＢやセンサから収集し、プロファイル管理プログラムにある各サービスに対応するコンテキスト解析モジュールにより、要求特性の値を導出する。
［４］  プロファイル管理プログラムは導出した要求特性をサービスプログラムに通知し、サービスプログラムはサービス管理プログラムに通知する。
＜サービスに関連のあるコンテキストの変化や資源の割り当ての変化が起きた場合＞
【００８５】
図１９（３）を用いて、サービスプログラムがコンテキストを解析することにより要求特性を導出する場合について説明する。
［１］  コンテキストに変化が起こると、プロファイル管理プログラムはコンテキスト選択ＤＢに対して、コンテキストに関連のあるサービスをマッチングさせ、関連性のあるサービスを取得する。
［２］  関連性のあるサービスプログラムに対してコンテキスト変化の通知を行う。
［３］  サービスプログラムは取得したコンテキストからサービスプログラムにあるコンテキスト解析モジュールにより、要求特性を導出し、サービスプログラムは導出した要求特性をサービス管理プログラムに通知する。
【００８６】
図１９（４）を用いて、プロファイル管理プログラムがコンテキストを解析することにより要求特性値を導出する場合について説明する。
［１］  コンテキストに変化が起こると、プロファイル管理プログラムはコンテキスト選択ＤＢに対して、コンテキストに関連のあるサービスをマッチングさせ、関連性のあるサービスを取得する
［２］  プロファイル管理プログラムは関連性のあるサービスプログラムに対して、プロファイル管理プログラムにある各サービスに対応するコンテキスト解析モジュールにより、要求特性の値を導出する。
［３］  プロファイル管理プログラムは関連性のあるサービスプログラムに対して要求特性を通知し、サービスプログラムは要求特性をサービス管理プログラムに通知する。
［抽象資源の割り当て計算、提供モードの決定］
【００８７】
図２０を用いて、抽象資源の割り当て計算、提供モードの決定について説明する。
［１］  サービス管理プログラムは、取得したサービスの要求特性を要求特性ＤＢに登録する。要求特性ＤＢの例として図２３を参照。また図２３に示すように要求特性の種類として主に以下のようなパラメータがある。
・サービスＩＤ：サービス管理プログラムから発行されたＩＤ
・ユーザ名：サービスを利用する（サービスが着信する場合、利用を要求されている）ユーザ名
・ユーザ位置：ユーザの現在の位置情報
・重要度：各サービスの資源（抽象資源、実資源）の割り当てを決定する度合い。サービスの単独提供を促す度合い。様々なコンテキストから導出する
・リアルタイム：他サービスにより提供が困難となった際のサービスの中断、継続を決定する度合い。サービスの提供形態（ライブ、オンデマンド）に大きく依存する
・重要度閾値：サービス管理プログラムが抽象資源割当アルゴリズムにおいてサービスエリアを決定する際に用いる（図２７を参照）
・上位重要度閾値
・下位重要度閾値
・デフォルトユーザ資源：サービスの提供モードに必要となるユーザ資源の種類と大きさ
・最低必要ユーザ資源：サービスの提供モードに最低限必要となるユーザ資源の種類と大きさ
・サービス属性：サービス間の関連性の判断に用いる。サービスの連携制御を行うか、行わないか判断する。図２６を参照。
［２］  サービス管理プログラムは要求抽象資源導出モジュールにて、要求特性の通知のあったサービスが要求する抽象資源（または変更する抽象資源）を導出する。要求する抽象資源の導出における計算は図２４を参照。
［３］  サービス管理プログラムは要求特性ＤＢに開始要求（変更要求）を行ったユーザが現在、利用しているサービスにおける要求特性の各値を要求し、取得する。
［４］  サービス管理プログラムはＨＮＷ資源管理プログラムに開始要求（変更要求）を行ったユーザが現在、利用しているサービスにおいて、要求特性の通知があったサービスが必要とする抽象資源を利用しているサービスに関して、抽象資源の割り当て状況をＨＮＷ資源管理プログラムから取得する。抽象資源ＤＢは図２５を参照。
［５］  サービス管理プログラムは［３］、［４］で取得した値により、抽象資源割り当てアルゴリズムによる計算により、抽象資源に関して関連性のあるサービスに対する抽象資源の割当量を導出し、関連性のあるサービスに通知する。要求特性として重要度のみを用いた各サービスへの抽象資源の割当量の導出におけるアルゴリズムは図２６を参照。
図２６における抽象資源の割り当てにおけるポリシーでは、各サービスの重要度と重要度閾値によって決定されるサービスエリアによって、サービスに対する抽象資源の割り当て方法を決定している。ただし、上位重要度閾値よりも高い値となる要求特性を有すサービスが複数存在するときには、抽象資源に関しては、その上限（ある抽象資源に対する各サービスの割当量の総和の上限を１００％と仮定する）を超えても、各サービスが要求する抽象資源を割り当てることで、複数サービスの同時利用を促すようなポリシーとなっている。
［６］  抽象資源の割り当て通知を受けた各サービスは割り当てられた抽象資源に基づいて、サービスの提供方法（提供モード）を決定（変更）する。サービスとしてビデオ表示サービスを例にした抽象資源に基づく提供モード決定アルゴリズムを図２８に示す。
【００８８】
「実資源の割り当て計算、提供可否判断」
図２１を用いて、実資源の割り当て計算、提供可否判断について説明する。
［１］  抽象資源の割り当て通知を受けた各サービスは選択した提供モードに基づいて、提供する際に必要となる実資源とその実資源量をＨＮＷ資源管理プログラムに要求する。その際に利用可能な実資源（デバイスなど）が複数存在する際にはユーザに最適と考えられる（ユーザの近くにあるデバイスなど）実資源を優先して要求する。サービスとしてビデオ表示サービスを例にした提供モードに基づいて要求する実資源例を図２９に示す。
［２］  ＨＮＷ資源管理プログラムは、［１］において要求のあった全てのサービスに対して、サービスが要求する実資源量及びその実資源の使用状況（サービスに対する割り当て量の状況）を実資源ＤＢから取得する。実資源ＤＢは図３０を参照。
［３］  ＨＮＷ資源管理プログラムは、［２］で取得したサービスの要求実資源と実資源の割り当て状況を合わせてサービス管理プログラムに通知する。
［４］  サービス管理プログラムは図２０の［５］を実行していないサービスで、通知のあった実資源の使用状況から関連性のあるサービスを新たに抽出し、それらのサービスに対して、現在割り当てられている抽象資源量と同じ抽象資源の割り当て通知を行うことで、図２０の［５］を実行させ、そのサービスにおける実資源の要求通知を受け取る。
［５］  サービス管理プログラムは、抽象資源、実資源に関係する全てのサービスに対する要求する実資源量を受け取り、実資源の割り当てアルゴリズムによる計算により、各サービスに対して実資源の割り当てを行う。要求特性として重要度のみを用いた実資源の割当量の導出における計算アルゴリズムは図３１を参照。
［６］  各サービスはサービス管理プログラムから割り当てられた実資源の割当量に基づいて、提供可否判断プログラムにより、割り当てられた実資源での提供可否を判断する。そして、各サービスは提供可否の判断結果をサービス管理プログラムに通知する。その際にサービスがサービス管理プログラムに通知する判断結果の種類を図３２に示す。またサービスとしてビデオ表示サービスを例にした判断結果の通知例を図３３に示す。
サービス管理プログラムは全てのサービスからの判断結果を受け取り、再要求指示及び実行指示モジュールにて、全てのサービスまたは、特定のサービスに対して、再要求指示、実行指示を行う。各サービスの判断結果に対する再要求指示、実行指示決定アルゴリズムは図３４を参照。図３４においてサービス管理プログラムがサービスに通知する指示の内容は図３５を参照。
サービス管理プログラムは全てのサービスの判断結果が「実行可能」になるまで、図２１の［８］、［９］（点線）に示すように、サービスに対して各資源の再要求指示を行う。全てのサービスからの判断結果が「実行可能」となったとき、サービス管理プログラムは全てのサービスに対して、実行指示を行う。
［７］  サービスはサービス管理プログラムから図３５のように指示を受けると、その指示に従って再要求指示、実行開始を行う。サービス管理プログラムの再要求指示、実行指示に対する指示待機状態からのサービスの状態遷移について図３６に示す。
＜サービスがサービス管理プログラムから、再要求指示を受けた場合＞
（サービスがサービス管理プログラムから、抽象資源の再要求指示を受けた場合）
［８］  要求特性導出プログラムにて、提供モードを低順位となる提供モードに変更し、サービス管理プログラムに再度、要求特性を通知する。
（サービスがサービス管理プログラムから実資源の再要求指示を受けた場合）
［９］  要求実資源導出プログラムにて提供グレードを低順位となる提供グレードを選択、または要求するデバイスを変更し、ＨＮＷ資源管理プログラムに再度実資源を通知する。
＜全てのサービスからの判断結果が「実行可能」となり、サービスがサービス管理プログラムから、抽象資源の実行指示を受けた場合＞
［１０］  サービス管理プログラムはＨＮＷ資源管理プログラムに、抽象資源、実資源の割り当て結果（新たな各資源の使用状況）を通知する。
［１１］  ＨＮＷ資源管理プログラムは抽象資源ＤＢ、実資源ＤＢを更新する。
（ＨＮＷ資源管理プログラムがサービスに対して資源の割り当て完了通知を行う場合）
［１２］  サービスはＨＮＷ資源管理プログラムから資源の割り当て完了通知を受け取る。
［１３］  サービスはサービス管理プログラムから実行指示を受け取り、ＨＮＷ資源管理プログラムから資源の割り当て完了通知を受け取った後、サービスは決定した提供方法でサービスの制御を実行する。
（サービスがＨＮＷ資源管理プログラムに割り当てられた資源を要求する場合）
［１２］  サービスはＨＮＷ資源管理プログラムに対して割り当てられた実資源を要求し、ＨＮＷ資源管理プログラムから資源の割り当て完了通知を受け取る。
［１３］  サービスはサービス管理プログラムから実行指示を受け取り、ＨＮＷ資源管理プログラムから資源の割り当て完了通知を受け取った後、サービスは決定した提供方法でサービスの制御を実行する。
【００８９】
以上説明したように、サービス管理プログラムは、各サービスに対する要求特性を用いて、各サービスが要求する抽象資源（ユーザ資源など）に関して、競合が起こる場合は、各サービスに仮想的に抽象資源の割り当てを行う。また、各サービスプログラムは割り当てられた抽象資源に基づいてサービスの提供方法（提供モード）を決定し、その後、その決定した提供モードに基づき、実資源を要求する。本実施例においては、サービス管理プログラムとサービスプログラムが「サービス制御内容決定部」を構成する。また、本実施例においては、プロファイル管理プログラムが「コンテキスト解析部」を構成する。
【００９０】
［実施例２の変形例］
実施例２においてサービスがサービス管理プログラムに通知する要求特性として、サービスの属性を表す特性を導入することで、本発明におけるサービスの連携制御を行うか、行わないか判断するというように、サービス属性に応じて連携制御内容の方法を決定することが可能となる。
具体的には図２６における抽象資源（ユーザ資源など）の割り当てアルゴリズムにおいてサービスの関連性を判断し、開始、変更が要求されるサービスが関連性のない場合、そのサービスが要求している抽象資源を抽象資源の割り当ての計算対象から外し、要求どおり抽象資源を割り当てるという方法で実現する。抽象資源において関連性ないサービスを割り当ての計算対象から外すことで計算量を減らすことが可能となる。
ただし、実資源（デバイス、リンク帯域など）に関して関連性が生じた場合には、図３１における実資源の割り当てアルゴリズムによって割り当て計算を行い、結果として、実資源が割り当てられないときにはサービスは提供できないと判断することになる。
【００９１】
以下、本発明のサービス制御システムを用いたサービス例を示す。
１．抽象資源（ユーザ資源）を用いた複数サービスの統括的制御の例
ＶＯＤサービスを利用している時に、電話サービスの着信が起こった際、ＶＯＤ、電話の両サービスとも「耳で聞く」必要があるため、「耳」というユーザ資源の競合が起こり、本発明のサービス制御システムは、導出した各サービスの要求特性（重要度等）を用いて「耳」の資源を各サービスに割り当てる。その結果、各サービスに「耳」などのユーザ資源が割り当てられ、電話サービスでは着信許可が実行され、ＶＯＤサービスは割り当てられた「耳」の資源の割当量が、電話の着信時よりも割当量が減少したため、ＶＯＤサービスは自動的に音量を下げるという提供方法を決定して、ＶＯＤサービスの提供が継続され、電話サービスとの同時利用を促した。
またＶＯＤサービスよりも重要な電話サービスの着信が起こった時は、抽象資源の割り当てポリシーによってＶＯＤサービスに対して全てのユーザ資源が割り当てられなくなった（割当量が０となったため）、ＶＯＤサービスは一時停止という提供方法を選定して、自動的に一時停止をした。
上記のように複数サービスを同時に利用する際に、本発明のサービス制御システムにおいてユーザ資源の割り当てに基づいて、ユーザが各サービスを快適に利用できるような提供方法を決定することで、ユーザ指向な統括的制御を自動的に行うことを可能とする。
【００９２】
２．ユーザ資源の使用状況をサービス提供者側に提供するサービス例
図３７に本発明の実施例２のサービス制御方法を用いたサービス提供方法を示す。
ユーザが利用しているサービスが必要とするユーザ資源（利用しているサービスに割り当てられているユーザ資源）を、抽象化されたユーザ状況コンテキストとして、認証レベルに応じてサービス提供者に提供することで、現在、ユーザが利用することが可能となる提供方法をリアルタイムにサービス提供者が選択することができ、ユーザが複数サービスを快適に利用できるようにサービスを提供することができる。
例えばビデオを視聴しているユーザにＴＶ電話をかけようとしたとき、「目」の資源の利用状況を判断して、音声電話で電話するというようなサービスの提供方法を選択をすることが可能になる。
【００９３】
なお、本発明のシステムはコンピュータとプログラムによっても実現でき、プログラムを記録媒体に記録することも、ネットワークを通じて提供することも可能である。
【００９４】
以上、本発明者によってなされた発明を、前記実施例に基づき具体的に説明したが、本発明は、前記実施例に限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能であることは勿論である。
【図面の簡単な説明】
【００９５】
【図１（１）】本発明の実施例１のサービス制御システムを用いたシステム全体構成（各アプリケーションに変換モジュールを追加する場合）を示す図である。
【図１（２）】本発明の実施例１のサービス制御システムを用いたシステム全体構成（各アプリケーションには何もしないで変換モジュールをシステム側に追加する場合）を示す図である。
【図２】本発明の実施例１のサービス制御システムの構成図である。
【図３】要求特性導出のフローの例を示す図である。
【図４】サービス制御内容決定のフローの例（サービス着信／開始時の制御の例）を示す図である。
【図５（１）】本発明の実施例１のサービス制御システムの構成図（コンテキスト解析のフロー（「センサ」がある一定時間に動的コンテキスト情報を更新））である。
【図５（２）】本発明の実施例１のサービス制御システムの構成図（コンテキスト解析のフロー（サービスの要求の際に「センサ」が動的コンテキストを取得））である。
【図６】本発明の実施例１の動作を示すフローチャート（コンテキスト解析のフロー）である。
【図７（１）】本発明の実施例１のサービス制御システムの構成図（サービス制御内容決定のフロー（サービス開始／着信拒否））である。
【図７（２）】本発明の実施例１のサービス制御システムの構成図（サービス制御内容決定のフロー（サービス開始許可−リアルタイム制御容認））である。
【図７（３）】本発明の実施例１のサービス制御システムの構成図（サービス制御内容決定のフロー（サービス開始許可−リアルタイム制御否認））である。
【図８（１）】本発明の実施例１の動作を示すフローチャート（サービス制御内容決定のフロー（サービス開始／着信拒否））である。
【図８（２）】本発明の実施例１の動作を示すフローチャート（サービス制御内容決定のフロー（サービス開始許可−リアルタイム制御容認））である。
【図８（３）】本発明の実施例１の動作を示すフローチャート（サービス制御内容決定のフロー（サービス開始許可−リアルタイム制御否認））である。
【図９】本発明の実施例１のサービス制御方法を用いたサービス提供方法を示す図である。
【図１０】表１：初期コンテキストＤＢの例
【図１１】表２：コンテキスト選択ＤＢの例
【図１２】表３：コンテキストＤＢの例
【図１３】表４：要求特性ＤＢ例
【図１４】本発明の実施例２のサービス制御システムのソフトウエア構成図である。
【図１５】本発明の実施例２におけるサービスの提供方法の遷移の例（映像コミュニケーションサービスの場合）を示す図である。
【図１６（１）】本発明の実施例２のサービス制御システムの構成図（サービス管理プログラム）である。
【図１６（２）】本発明の実施例２のサービス制御システムの構成図（サービスプログラム）である。
【図１６（３）】本発明の実施例２のサービス制御システムの一実施例の構成図（ＨＮＷ資源管理プログラムの構成）である。
【図１６（４）】本発明の実施例２のサービス制御システムの一実施例の構成図（プロファイル管理プログラムの構成）である。
【図１７（１）】本発明の実施例２のサービス制御システムの動きを示すシーケンス図（その１）である。
【図１７（２）】本発明の実施例２のサービス制御システムの動きを示すシーケンス図（その２）である。
【図１７（３）】本発明の実施例２のサービス制御システムの一実施例の動きを示すシーケンス図（その３）である。
【図１８】本発明の実施例２の動作を表すフローチャート（新規発生サービスの登録）である。
【図１９（１）】本発明の実施例２の動作を表すフローチャート（要求特性の導出）（その１）である。
【図１９（２）】本発明の実施例２の動作を表すフローチャート（要求特性の導出）（その２）である。
【図１９（３）】本発明の実施例２の動作を表すフローチャート（要求特性の導出）（その３）である。
【図１９（４）】本発明の実施例２の動作を表すフローチャート（要求特性の導出）（その４）である。
【図２０】本発明の実施例２の動作を表すフローチャート（抽象資源割り当て計算、提供モードの決定）である。
【図２１】本発明の実施例２の動作を表すフローチャート（実資源割り当て計算、提供可否判断）である。
【図２２】本発明の実施例２におけるサービスの状態遷移である。
【図２３】本発明の実施例２におけるサービス管理プログラムの要求特性ＤＢの例である。
【図２４】本発明の実施例２における要求抽象資源導出アルゴリズム（ユーザ資源の導出の場合）である。
【図２５】本発明の実施例２におけるＨＮＷ資源管理プログラムの抽象資源（ユーザ資源）ＤＢの例である。
【図２６（１）】本発明の実施例２における抽象資源割り当てアルゴリズム（その１）である。
【図２６（２）】本発明の実施例２における抽象資源割り当てアルゴリズム（その２）である。
【図２７】本発明の実施例２における重要度を用いたサービスエリア決定アルゴリズムである。
【図２８】本発明の実施例２における提供モード決定プログラムの例（ビデオ再生サービス）である。
【図２９】本発明の実施例２における要求実資源導出の例（ビデオ表示サービス）である。
【図３０】本発明の実施例２におけるＨＮＷ資源管理プログラムの実資源ＤＢの例である。
【図３１】本発明の実施例２における実資源割り当てアルゴリズムである。
【図３２】本発明の実施例２におけるサービス管理に対するサービスの判断結果の種類である。
【図３３】本発明の実施例２におけるサービス管理プログラムに対するサービスの判断結果の通知の例（ビデオ表示サービス）である。
【図３４（１）】本発明の実施例２における再要求提示及び実行指示アルゴリズム（その１）である。
【図３４（２）】本発明の実施例２における再要求提示及び実行指示アルゴリズム（その２）
【図３５】本発明の実施例２のサービス管理プログラムの再要求指示及び実行開始指示の内容を示す図である。
【図３６】本発明の実施例２におけるサービス管理プログラムの再要求指示、実行指示に対する指示待機状態からのサービスの状態遷移を示す図である。
【図３７】本発明の実施例２におけるユーザ資源の使用状況をサービス提供者側に提供するサービス例を示す図である。
【符号の説明】
【００９６】
１０１…コア、１０２…要求アプリケーション、１１１〜１１３…各アプリケーションに対する変換モジュール、１２１〜１２３…アプリケーション１〜３、２０１…アプリケーション、２０２…変換モジュール、２１１…要求アプリケーション、２２１…サービス制御シナリオマネージャー、２３１…コンテキスト解析部、２３２…コンテキスト解析、２３３…コンテキスト選択ＤＢ、２３４…コンテキスト取得、２４１…コンテキスト、２４２…コンテキストＤＢ、２４３…センサ、２５ｌ…要求特性ＤＢ、２６１…制御内容決定部、２６２…制御内容決定、２６３…制御ルール導出、２７１…プレゼンスマネージャー
【図１（１）】
2005100320.tif 000003
【図１（２）】
2005100320.tif 000004
【図２】
2005100320.tif 000005
【図３】
2005100320.tif 000006
【図４】
2005100320.tif 000007
【図５（１）】
2005100320.tif 000008
【図５（２）】
2005100320.tif 000009
【図６】
2005100320.tif 000010
【図７（１）】
2005100320.tif 000011
【図７（２）】
2005100320.tif 000012
【図７（３）】
2005100320.tif 000013
【図８（１）】
2005100320.tif 000014
【図８（２）】
2005100320.tif 000015
【図８（３）】
2005100320.tif 000016
【図９】
2005100320.tif 000017
【図１０】
2005100320.tif 000018
【図１１】
2005100320.tif 000019
【図１２】
2005100320.tif 000020
【図１３】
2005100320.tif 000021
【図１４】
2005100320.tif 000022
【図１５】
2005100320.tif 000023
【図１６（１）】
2005100320.tif 000024
【図１６（２）】
2005100320.tif 000025
【図１６（３）】
2005100320.tif 000026
【図１６（４）】
2005100320.tif 000027
【図１７（１）】
2005100320.tif 000028
【図１７（２）】
2005100320.tif 000029
【図１７（３）】
2005100320.tif 000030
【図１８】
2005100320.tif 000031
【図１９（１）】
2005100320.tif 000032
【図１９（２）】
2005100320.tif 000033
【図１９（３）】
2005100320.tif 000034
【図１９（４）】
2005100320.tif 000035
【図２０】
2005100320.tif 000036
【図２１】
2005100320.tif 000037
【図２２】
2005100320.tif 000038
【図２３】
2005100320.tif 000039
【図２４】
2005100320.tif 000040
【図２５】
2005100320.tif 000041
【図２６（１）】
2005100320.tif 000042
【図２６（２）】
2005100320.tif 000043
【図２７】
2005100320.tif 000044
【図２８】
2005100320.tif 000045
【図２９】
2005100320.tif 000046
【図３０】
2005100320.tif 000047
【図３１】
2005100320.tif 000048
【図３２】
2005100320.tif 000049
【図３３】
2005100320.tif 000050
【図３４（１）】
2005100320.tif 000051
【図３４（２）】
2005100320.tif 000052
【図３５】
2005100320.tif 000053
【図３６】
2005100320.tif 000054
【図３７】
2005100320.tif 000055