(57)【特許請求の範囲】
【請求項１】
サービス制御サーバ及びネットワーク制御サーバを備えるシステムにおけるネットワーク・サービス制御方法であって、
前記サービス制御サーバは、
ユーザへ通信サービスを提供する際に、
前記ユーザの場所、前記ユーザの所持品、前記ユーザの周囲の状況及び前記ユーザの過去の行動パターンの少なくとも一つから導かれる前記ユーザの知識情報であるユーザコンテキストを取得する工程と、
予め任意のタイミングで前記ユーザにより登録された、通信サービスが提供される際の提供形態についての前記ユーザの希望に関する情報であるユーザプロファイルを取得する工程と、
予め任意のタイミングで前記通信サービスの提供者により登録された、前記通信サービスを提供する際の提供形態についての推奨情報であるサービスプロファイルを取得する工程と、
前記ユーザコンテキストと、前記ユーザプロファイルと、前記サービスプロファイルとに基づいて、前記通信サービスを提供するためのネットワークへの要求条件を決定し、前記ネットワークへの要求条件を前記ネットワーク制御サーバに送信するサービス制御工程と、
を実行し、
前記ネットワーク制御サーバは、
トラヒックの状況やネットワークの性能及び運用経験から得た情報に関する知識情報であるネットワークコンテキストを取得する工程と、
予め任意のタイミングで登録されたネットワークの運用方針に関する情報である運用ポリシを取得する工程と、
前記ネットワークへの要求条件を受信し、前記ネットワークへの要求条件と、前記ネットワークコンテキストと前記運用ポリシとに基づいて、前記通信サービスを前記ユーザへ提供するためのネットワークのリソース割当を行なうネットワーク制御工程と、
を実行することを特徴とするネットワーク・サービス制御方法。
【請求項２】
前記ネットワークコンテキストは、少なくとも、ネットワークの需要の傾向に関する情報か、ネットワークリソースの現在の使用状況に関する情報か、異常が発生した時に出現するネットワークの動作パターンに関する情報か、ネットワークに対する制御に応じて出現するネットワークの動作パターンに関する情報のいずれか１つを含むことを特徴とする請求項１記載のネットワーク・サービス制御方法。
【請求項３】
前記サービス制御サーバは、
前記サービス制御工程において、前記ユーザプロファイルと前記サービスプロファイルとで示す条件が異なる場合に、予め設定されたどちらか一方の条件を優先して前記ネットワークへの要求条件を設定することを特徴とする請求項１記載のネットワーク・サービス制御方法。
【請求項４】
前記サービス制御サーバは、
前記サービス制御工程において、前記ユーザプロファイルと前記サービスプロファイルとで示す条件が異なる場合に、前記両プロファイルに示されるデータの内容を比較して前記ネットワークへの要求条件を設定することを特徴とする請求項１記載のネットワーク・サービス制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク及びサービスを制御する技術に関する。
【背景技術】
【０００２】
従来、ユーザの周辺の状況（時間・場所、持ち物や周辺機器）や過去の行動パターンから導くユーザの意向に関する仮説（以下、ユーザコンテキストとも記す）によって、データの着信先の端末を変更したり、着信する端末を選ぶサービスが存在する（例えば、特許文献１参照）。また、ユビキタスネットワークにおいて、実世界のモノに関する情報をもとにユーザの状況に最も即したサービスや情報の提供を行なうことに関し、研究がなされている（例えば、非特許文献１、非特許文献２、非特許文献３参照）。【０００３】
また、情報を配信する際のネットワーク制御に関し、トラヒックエンジニアリング技術を用いた、通信経路やＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）制御などが行なわれている。この技術によれば、ネットワークの負荷分散とＱｏＳ保証とを同時に実現したネットワークリソースの割当が可能になる。例えば、ＭＰＬＳネットワークにおいて、ベストエフォート型と帯域保証型との二種類のサービスが混在する状況において、帯域保証型用に保留する帯域は、資源の消費ができる限り小さくなるような最短経路を選択し、ベストエフォート型のラベルパスは、動的にトラヒックの流れを変更することで、帯域保証型のパケットが優先処理されることによって起こりうるＱｏＳ劣化をできる限り小さくし、帯域保証型の通信がベストエフォート型の通信に与える影響をネットワーク全体で吸収する技術がある（例えば、特許文献２、非特許文献４参照）。【０００４】
またトラヒックエンジニアリング技術として例えば、ネットワークとアプリケーションサーバの両方の負荷を同時に考慮してＱｏＳを満足し、しかもネットワーク全体の負荷が均等に分散されるようなネットワークとアプリケーションサーバのペアを探索することで、ネットワークの全体最適化を図る技術がある（例えば、特許文献３参照）。【０００５】
また、第一のネットワークと通信している端末を第二のネットワークヘハンドオーバする際に、ユーザコンテキスト、アプリケーションＱｏＳ要件、ネットワークコンテキストを並行して評価する技術が存在する（例えば、特許文献４参照）。
また、ユーザとユーザが携帯するリーダで読み取ったオブジェクトとの関係を管理する技術がある（例えば、特許文献５参照）。
【特許文献１】特開２００４−２０６６７０号公報
【特許文献２】特開２００４−２３６１９８号公報
【特許文献３】ＷＯ０４／０７３２６９号公報
【特許文献４】特開２００３−３３３６３９号公報
【特許文献５】特願ＪＰ０３／０２４９８号公報
【非特許文献１】加藤  正文、“ユビキタスネットワークの展開戦略−ネットワークとミドルウェアによる知識の活用−”、［ｏｎｌｉｎｅ］、平成１６年６月２４日、ユビキタスネットワーキングフォーラム  ユビキタス戦略シンポジウム、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｕｂｉｑｕｉｔｏｕｓ−ｆｏｒｕｍ．ｊｐ／ｄｏｃｕｍｅｎｔｓ／ｓｙｍｐｏ２００４０６２４／ｉｎｄｅｘ．ｈｔｍｌ＞
【非特許文献２】大橋  正良、“コンテキスト＆プロファイリング−Ｓｅｍａｎｔｉｃ  ｗｅｂ活用アプローチ−”、［ｏｎｌｉｎｅ］、平成１６年７月２０日、電子情報通信学会  実時間指向ユビキタスネットワークワークショップ研究会（ＵＲＯＮ）、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｉｅｉｃｅ．ｏｒｇ／ｃｓ／ｕｒｏｎ／ｗｏｒｋｓｈｏｐ２００４．ｈｔｍｌ＞
【非特許文献３】今井  和雄、“第４世代モバイルネットワークとユビキタスへの展開”、［ｏｎｌｉｎｅ］、平成１６年７月２０日、電子情報通信学会  実時間指向ユビキタスネットワークワークショップ研究会（ＵＲＯＮ）、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｉｅｉｃｅ．ｏｒｇ／ｃｓ／ｕｒｏｎ／ｗｏｒｋｓｈｏｐ２００４．ｈｔｍｌ＞
【非特許文献４】加藤  正文、“Ｎｅｘｔ  ｇｅｎｅｒａｔｉｏｎ  ＩＰ  ｎｅｔｗｏｒｋ  ｃｏｎｔｒｏｌ  ｂａｓｅｄ  ｏｎ  ｔｒａｆｆｉｃ  ｅｎｇｉｎｅｅｒｉｎｇ”、［ｏｎｌｉｎｅ］、平成１６年４月７日、Ｔｈｅ  ＡＴＭ  Ｆｏｒｕｍ  ＩＣＢＮ２００４、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ａｔｍｆｏｒｕｍ．ｃｏｍ／ｍｅｅｔｉｎｇｓ／ｉｃｂｎ０４−ｐｒｏｇｒａｍ．ｈｔｍｌ＞
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、これら従来の技術は、ＮＷの状況のみ、もしくはユーザの状況のみに着目して情報配信を行なうもの、すなわちユーザかネットワーク事業者か、どちらか一方の要件だけを考慮したサービスになっており、また、例えばコンテンツ配信を行うようなサービス事業者の要件も考慮されていない。ユーザの状況とネットワーク（以下、ＮＷとも記す）の状況、さらにはサービス事業者の要件である、ユーザへ配信されるコンテンツの配信方法に関する推奨値とを同時に考慮して、ＮＷやサービスの制御を行う技術は、まだ考えられていない。【０００７】
本発明の基本的な狙いは、ユーザ、ネットワーク事業者、サービス事業者の要求を自動的に考慮し、ＮＷを制御することである。また、仮に三者の要求が対立する場合にも、妥協点を自動的に見出すことを狙っている。本発明の目的の１つは、コンテンツ配信などの通信サービス提供の際に、ユーザコンテキストとユーザの嗜好に関する情報とサービス事業者の推奨情報とを用いて、ＮＷへの要求条件を自動的に決定することにある。また、本発明の目的の１つは、決定された要求条件を満足するＮＷ制御を行なう際に、ＮＷコンテキストとＮＷの運用方針とを用いてネットワークリソース割当ての最適化を動的に行う技術を提供することにある。また、本発明の目的の１つは、ユーザやサービス事業者の意向を反映し、同時に、ＮＷリソースの有効利用を図る技術を提供することにある。更に、多様な環境下を動き回るユーザ自身が、その時々の状況に応じてユーザの要求を指定するのは困難であり、そのような状況において、ユーザが要求を指定しなくても、ユーザの要求を解釈しこれを満たす方法によってサービスの提供を行なうことにある。
【課題を解決するための手段】
【０００８】
上記目的を達成するため、本発明のネットワーク・サービス制御方法は、
ユーザへ通信サービスを提供する際に、
前記ユーザの周辺の状況や過去の行動パターンに関する知識情報であるユーザコンテキストを取得する工程と、
予め任意のタイミングで前記ユーザにより登録された該ユーザの嗜好に関する情報であるユーザプロファイルを取得する工程と、
前記ユーザコンテキストと、前記ユーザプロファイルとに基づいて、前記通信サービスを提供するためのネットワークへの要求条件を決定するサービス制御工程とを備えることを特徴とする。【０００９】
また、本発明のネットワーク・サービス制御方法は、
ユーザへ通信サービスを提供する際に、
前記ユーザの周辺の状況や過去の行動パターンに関する知識情報であるユーザコンテキストを取得する工程と、
予め任意のタイミングで前記ユーザにより登録された該ユーザの嗜好に関する情報であるユーザプロファイルを取得する工程と、
予め任意のタイミングで登録された前記通信サービスの提供に関する推奨値であるサービスプロファイルを取得する工程と、
前記ユーザコンテキストと、前記ユーザプロファイルと、前記サービスプロファイルとに基づいて、前記通信サービスを提供するためのネットワークへの要求条件を決定するサービス制御工程とを備えることを特徴とする。【００１０】
また、本発明のネットワーク・サービス制御方法は、
前記ネットワーク・サービス制御方法はさらに、
トラヒックの状況やネットワークの性能及び運用経験から得た情報に関する知識情報であるネットワークコンテキストを取得する工程と、
予め任意のタイミングで登録されたネットワークの運用方針に関する情報である運用ポリシを取得する工程と
前記ネットワークへの要求条件と、前記ネットワークコンテキストと前記運用ポリシとに基づいて、前記通信サービスを前記ユーザへ提供するためのネットワークのリソース割当を行なうネットワーク制御工程とを備えることを特徴とする。【００１１】
また、本発明のネットワーク・サービス制御方法は、
前記ネットワークコンテキストは、少なくとも、ネットワークの需要の傾向に関する情報か、ネットワークリソースの現在の使用状況に関する情報か、異常が発生した時に出現するネットワークの動作パターンに関する情報か、ネットワークに対する制御に応じて出現するネットワークの動作パターンに関する情報のいずれか１つを含むことを特徴とする。【００１２】
また、本発明のネットワーク・サービス制御方法は、
前記サービス制御工程は、前記ユーザプロファイルと前記サービスプロファイルとで示す条件が異なる場合に、予め設定されたどちらか一方の条件を優先して前記ネットワークへの要求条件を設定する第一の設定工程を備えることを特徴とする。【００１３】
また、本発明のネットワーク・サービス制御方法は、
前記サービス制御工程は、前記ユーザプロファイルと前記サービスプロファイルとで示す条件が異なる場合に、前記両プロファイルに示されるデータの内容を比較して前記ネットワークへの要求条件を設定する第二の設定工程を備えることを特徴とする。【００１４】
また、本発明のネットワーク・サービス制御方法は、
前記第二の設定工程は、前記ユーザプロファイルと前記サービスプロファイルに登録されている条件のうち、要求の厳しい方の条件を前記ネットワークへの要求条件に設定することを特徴とする。【００１５】
また、本発明のネットワーク・サービス制御方法は、
前記第二の設定工程は、前記ユーザプロファイルと前記サービスプロファイルに登録されている条件のうち、要求の緩い方の条件を前記ネットワークへの要求条件に設定する工程を備える。【００１６】
また、本発明のネットワーク・サービス制御方法は、
前記第二の設定工程は、
前記設定したネットワークへの要求条件に基づき行なわれた前記ユーザへの前記通信サービスの要求が呼損になった場合に、前記設定した条件を緩めて再度前記ネットワークへの要求条件を設定することを特徴とする。【００１７】
また、本発明のネットワーク・サービス制御方法は、
前記第二の設定工程は、前記ユーザプロファイルと前記サービスプロファイルとに登録されているパラメータのうち、一部のパラメータを参照して前記ネットワークへの要求条件に設定することを特徴とする。【００１８】
また、本発明のネットワーク・サービス制御方法は、
前記一部のパラメータは、前記ユーザプロファイルと前記サービスプロファイルとの両プロファイルに登録されているパラメータの積集合であることを特徴とする。【００１９】
また、本発明のネットワーク・サービス制御方法は、
前記第二の設定工程は、前記ユーザプロファイルと前記サービスプロファイルとの両プロファイルに登録されているパラメータの和集合を前記ネットワークへの要求条件として設定することを特徴とする。【００２０】
また、本発明のネットワーク・サービス制御方法は、
前記ユーザプロファイルと前記サービスプロファイルの両プロファイルで扱うパラメータの種類で一致しているものがあり、そのパラメータの内容のどちらか一方または両者が特定の値でなく範囲で記述されていてしかも異なる範囲を指定している場合、
両者の範囲に共通する範囲があるかをチェックし、該共通範囲があるならば該共通範囲を、該共通範囲が無ければ前記両プロファイルの前記パラメータの範囲で互いに最も近い値を、前記ネットワークへの要求条件として設定する第三の設定工程を備えることを特徴とする。【００２１】
また、本発明のネットワーク・サービス制御方法は、
前記共通範囲のうち、条件が厳しい値を前記ネットワークへの要求条件として設定する工程を備えることを特徴とする。【００２２】
また、本発明のネットワーク・サービス制御方法は、
前記共通範囲のうち、条件が緩い値を前記ネットワークへの要求条件として設定する工程を備えることを特徴とする。【００２３】
また、本発明のネットワーク・サービス制御方法は、
サービスが起動された場合に、
前記ネットワークの要求条件を生成するサービス制御手段が、ユーザコンテキストを管理するユーザコンテキストセンシング・管理手段にユーザコンテキストを要求する工程と、
前記ユーザコンテキストセンシング・管理手段が、前記サービス制御手段に前記要求されたユーザコンテキストを通知する工程とを備える。【００２４】
また、本発明のネットワーク・サービス制御方法は、
所定の条件が成立した場合に、
前記ユーザコンテキストを管理するコンテキスト管理手段が前記ネットワークの要求条件を生成するコンテキストアウェアサービス制御手段にユーザコンテキストを送信する工程を備える。【００２５】
また、本発明のネットワーク・サービス制御方法は、
前記所定の条件の成立のチェックを、
前記ユーザコンテキストに変化が発生した際に行う工程を備える。【００２６】
また、本発明のネットワーク・サービス制御方法は、
前記所定の条件の成立のチェックを、
一定周期の時間間隔毎に行う工程を備える。【００２７】
また、本発明のネットワーク・サービス制御方法は、
前記所定の条件の成立のチェックを行う時刻を決める工程であって、
状況に従って変化する規則に従って前のチェック時刻から次のチェック時刻を決める工程を備える。【００２８】
また、本発明のネットワーク・サービス制御方法は、
前記所定の条件の成立のチェックを行う時刻を決める工程は、
詳細なチェックが必要か否かを判断する工程と、詳細なチェックが必要と判断された際に、前のチェック時刻から時間間隔を短くした次のチェック時刻を決定する工程とを備える。【００２９】
また、本発明のネットワーク・サービス制御方法は、
前記所定の条件の設立のチェックを、
詳細なチェックが不要と判断された際に、前のチェック時刻から時間間隔を長くした次のチェック時刻を決定する工程を備える。【００３０】
また、本発明のネットワーク・サービス制御方法は、
前記所定の条件の成立のチェックを一定の日時に行う工程を備える。【００３１】
また、本発明のネットワーク・サービス制御方法は、
前記ユーザコンテキストを取得する工程は、
電子タグから取得した識別情報と該電子タグを読み込んだ端末の識別情報とを対応付ける工程と、
前記電子タグから取得した識別情報と端末の識別情報との対応付けから導かれる、前記電子タグが付与されたオブジェクトと該オブジェクトの所有者との関係を、前記ユーザコンテキストとする工程とを備える。【００３２】
また、本発明のネットワーク・サービス制御方法は、
前記ユーザコンテキストを取得する工程は、
所定の場所に配置されたリーダが電子タグが付与されたオブジェクトの電子タグから情報を読み取る工程と、
前記電子タグから前記リーダが情報を読み取ることにより、前記電子タグが付与されたオブジェクトが所定の場所を通過したことを認識する工程と、
前記リーダの配置された場所を前記オブジェクトが通過したことをユーザコンテキストとして認識する工程とを備える。【００３３】
また、本発明のネットワーク・サービス制御方法は、
前記ユーザコンテキストを取得する工程は、
Ｇｌｏｂａｌ  Ｐｏｓｉｔｉｏｎｉｎｇ  Ｓｙｓｔｅｍを用いて前記オブジェクトの位置情報をユーザコンテキストとして取得する工程を備える。【００３４】
また、本発明のネットワーク・サービス制御方法は、
前記電子タグに、該電子タグに関する識別情報と、該電子タグが付与されているオブジェクトに関する情報を示す属性情報とが格納されている。【００３５】
また、本発明のネットワーク・サービス制御方法は、
前記ユーザコンテキストを管理するコンテキスト管理手段が、
電子タグが付与されているオブジェクトに関する詳細情報を示す属性情報を格納するサーバから、前記属性情報を読み出す工程を備える。【００３６】
また、本発明のネットワーク・サービス制御方法は、
前記読み出す工程は、
前記コンテキスト管理手段が、
前記電子タグに格納されている識別情報に基づいて、前記サーバにアクセスして前記属性情報を読み出す工程である。【００３７】
また、本発明のネットワーク・サービス制御方法は、
前記読み出す工程は、
前記コンテキスト管理手段が、
電子タグの識別情報に基づいて、該電子タグが付与されたオブジェクトの属性情報が格納されているサーバのアドレスを管理している識別情報−ネットワークアドレス解決サーバに格納されている、属性情報が格納されているサーバのアドレスを取得する工程と、
前記コンテキスト管理手段が、該サーバのアドレスを用いて、該サーバから属性情報を取得する工程とを備える。【００３８】
また、本発明のネットワーク・サービス制御方法は、
前記読み出す工程は、
前記コンテキスト管理手段が、前記電子タグに格納されている識別子から、ドメインネームシステムサーバに格納されている前記属性情報が格納されているサーバのアドレスを取得する工程と、
前記コンテキスト管理手段が、
該取得したアドレスに基づいて、前記サーバから前記属性情報を取得する工程を備える。【００３９】
また、本発明のネットワーク・サービス制御方法は、
前記電子タグに、識別情報と、属性情報が格納されているサーバのネットワークアドレス又は属性情報が格納されているサーバのネットワークアドレスを取得するためにアクセスすべき識別情報−ネットワークアドレス解決サーバのネットワークアドレスとが格納されている。【００４０】
また、本発明のネットワーク・サービス制御方法は、
少なくとも１以上のリーダが前記オブジェクトの電子タグの情報を取得した履歴から、該オブジェクトの動いている方向を認識する工程を備える。【００４１】
また、本発明のネットワーク・サービス制御方法は、
前記オブジェクトと人との動きが同じであることに基づいて、該オブジェクトと人とが一緒に動いていることを認識する工程を備える。【００４２】
また、本発明のネットワーク・サービス制御方法は、
リーダが存在する場所の属性情報をコンテキスト管理手段に送信する工程を備える。【００４３】
また、本発明のネットワーク・サービス制御方法は、
リーダが存在する場所の識別子を、コンテキストを管理するコンテキスト管理手段に送信する工程と、
前記コンテキスト管理手段が、受信した該識別子から場所の属性情報を生成する工程とを備える。【００４４】
また、本発明のネットワーク・サービス制御方法は、
前記ユーザコンテキストを管理するコンテキスト管理手段が、
前記オブジェクトに関する詳細情報を示す属性情報を格納するサーバから、前記属性情報を読み出す工程を備える。【００４５】
また、本発明のネットワーク・サービス制御方法は、
前記読み出す工程は、
前記ユーザコンテキストを管理するコンテキスト管理手段が、
前記電子タグに格納されている識別情報に基づいて、前記サーバにアクセスして前記属性情報を読み出す工程である。【００４６】
また、本発明のネットワーク・サービス制御方法は、
前記読み出す工程は、
前記ユーザコンテキストを管理するコンテキスト管理手段が、
電子タグの識別情報に基づいて、該電子タグが付与されたオブジェクトの属性情報が格納されているサーバのアドレスを管理している識別情報−ネットワークアドレス解決サーバに格納されている、属性情報が格納されているサーバのアドレスを取得する工程と、
前記コンテキスト管理手段が、該サーバのアドレスを用いて、該サーバから属性情報を取得する工程とを備える。【００４７】
また、本発明のネットワーク・サービス制御方法は、
前記読み出す工程は、
前記ユーザコンテキストを管理するコンテキスト管理手段が、前記電子タグに格納されている属性情報の識別子から、ドメインネームシステムサーバに格納されている前記属性情報が格納されているサーバのアドレスを取得する工程と、
前記管理するコンテキスト管理手段が、
該取得したアドレスに基づいて、前記サーバから前記属性情報を取得する工程とを備える。【００４８】
また、本発明のネットワーク・サービス制御方法は、
前記電子タグに、識別情報と、属性情報が格納されているサーバのネットワークアドレス又は該ネットワークアドレスを取得するためにアクセスすべき識別情報−ネットワークアドレス解決サーバのネットワークアドレスとが格納されている。【００４９】
また、本発明のネットワーク・サービス制御方法は、
前記ユーザコンテキストを取得する工程は、
コンテキストを管理するコンテキスト管理手段が、オブジェクト／ユーザ関係管理データベースに格納されているユーザとオブジェクトの関係に関する情報と、該オブジェクト／ユーザ関係管理データベースと独立して存在する、オブジェクト／属性管理データベースに格納されているオブジェクトの属性情報を取得し、ユーザとオブジェクトとその属性情報とからユーザの周辺状況をユーザコンテキストとして管理する工程であることを特徴とする。【００５０】
また、本発明のネットワーク・サービス制御方法は、
前記ユーザコンテキストを取得する工程は、
コンテキストを管理するコンテキスト管理手段が、ユーザがリーダで読み取った、電子タグが付与されたオブジェクトの識別情報とその属性情報とを一つのデータベースに格納し、ユーザとオブジェクトとその属性情報とからユーザの周辺状況をユーザコンテキストとして管理する工程であることを特徴とする。【００５１】
また、本発明のネットワーク・サービス制御方法は、
前記ユーザコンテキストを取得する工程は、コンテキストを管理するコンテキスト管理手段が、リーダが電子タグから情報を読み取った場合に、オブジェクトの属性情報を要求し、ユーザコンテキストとして管理する工程を備えることを特徴とする。【００５２】
また、本発明のネットワーク・サービス制御方法は、
前記ユーザコンテキストを取得する工程は、コンテキストを管理するコンテキスト管理手段が、所定の時に、オブジェクトの属性情報を要求し、ユーザコンテキストとして管理する工程を備える。【００５３】
また、本発明のネットワーク・サービス制御方法は、
前記所定の時とは、サービスが要求された時である。【００５４】
また、本発明のネットワーク・サービス制御方法は、
前記所定の時とは、
ユーザコンテキストに示されるオブジェクトの属性と、予め通知する条件として登録されたオブジェクトの属性とが一致した時である。【００５５】
また、本発明のネットワーク・サービス制御方法は、
ネットワークに対する要求条件を決定するコンテキストアウェアサービス制御手段で決定された要求条件を満足するネットワークリソースの割り当てを行う際に、
ネットワークリソースの割り当てを行うネットワーク制御手段が、送信する情報のメディアを変更する工程を備える。【００５６】
また、本発明のネットワーク・サービス制御方法は、
ネットワークに対する要求条件を決定するコンテキストアウェアサービス制御手段で決定された要求条件を満足するネットワークリソースの割り当てを行う際に、
ネットワークリソースの割り当てを行うネットワーク制御手段が、送信する情報の符号化方式を変更する工程を備える。
【発明の効果】
【００５７】
このように、本発明は、ユーザの状況などを示すユーザコンテキストを利用し、ＮＷ及びサービスの制御を行っているので、ユーザにとって利便性の高いサービスを提供することができる。また、ユーザは、場所や所持品に応じてユーザが予め指定した形態や形式で情報を受信できる。【００５８】
具体的には、通信サービス提供の際に、ユーザの状況、ユーザの好み、サービス提供者の推奨を考慮してネットワークへの要求条件を決め、ネットワークの状況や過去の運用経験を基に、ネットワーク事業者の運用方針を考慮して、動的にネットワークリソースを割り当てることにより、ユーザ、ネットワーク事業者、サービス事業者の意向を反映し、ダイナミックにＮＷリソース割り当てを最適化する。さらには、ユーザの要求を満たすＮＷリソース割り当てを行う際にも、ネットワーク事業者の方針に沿う形で、ネットワークを有効利用し、できるだけ多くのユーザからのサービス要求を受け付けられるという波及的効果を得ることができる。【００５９】
また、本発明は、ネットワークへの要求条件を自動的に決定する。従来の技術では、Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ（以下、ＱｏＳとも記す）を要求する場合、様々なパラメータをユーザが申告する必要があった。しかし、本発明は、複雑な申告が不要で、かつ、ユーザの所在場所や所持品に応じた最適なＱｏＳを提供する。すなわち、状況に応じてユーザ自身でＮＷへの要求を指定するのは困難であるという状況に際し、ユーザが状況にあわせて要求を指定しなくても、ユーザの要求を自動的に見出すことができるという効果を得ることができる。【００６０】
また、本発明は、サービス提供者の推奨値を考慮したＱｏＳを提供することができる。また、本発明は、ネットワークリソースの最適割り当てを行っている。そのため、本発明は、ネットワークリソースが有効利用され、呼損が最小化される。【００６１】
また、本発明は、サービス提供者が推奨する条件と、ユーザプロファイルから導かれる条件とが異なる場合に、ネットワークに対する要求条件を緩い条件に合わせる。あるいは、本発明は、呼損時にネットワークに対する要求条件を緩める。この処理により、本発明は、呼損を最小化することができる。つまり、本発明は、サービス提供者やネットワーク事業者に対して呼損による機会損失が発生することを、最小化できる。また、本発明によれば、ユーザはサービスを受け付けられる可能性が高まるので、ユーザに対して高可用性が実現されるといえる。
【図面の簡単な説明】
【００６２】
【図１】本発明のネットワーク・サービス制御システムの一実施形態の概念図である。
【図２】本発明のネットワーク・サービス制御システムの一実施形態のネットワークアーキテクチャの概念図である。
【図３】本発明のネットワーク・サービス制御システムの一実施形態の構成図である。
【図４】本発明のネットワーク・サービス制御システムの一実施形態において使用するユーザプロファイルの一例の概念図である。
【図５】本発明のネットワーク・サービス制御システムの一実施形態で使用するユーザコンテキストの一例の概念図である。
【図６】本発明のネットワーク・サービス制御システムの一実施形態において使用するサービスプロファイルの一例の概念図である。
【図７】本発明のネットワーク・サービス制御システムの一実施形態で使用するネットワークコンテキストの一例の概念図である。
【図８】本発明のネットワーク・サービス制御システムの一実施形態における、ＮＷ要求条件抽出の動作のフローチャートである。
【図９】本発明のネットワーク・サービス制御システムの一実施形態における、ＮＷ制御サーバの動作のフローチャートである。
【図１０】本発明のネットワーク・サービス制御システムの一実施形態のＮＷ制御の概念図である。
【図１１】本発明のネットワーク・サービス制御システムの一実施形態のコンテキストアウェアサービス制御ロジックの動作のフローチャートである。
【図１２】本発明のネットワーク・サービス制御システムの一実施形態が提供するサービスの第２例である、コンテキストアウェア・ホームセキュリティの概念図である。
【図１３】本発明のネットワーク・サービス制御システムの一実施形態の位置及び所有関係認識方式の概念図である。
【図１４】本発明のネットワーク・サービス制御システムの一実施形態の位置及び所有関係認識方式の概念図である。
【図１５】本発明のネットワーク・サービス制御システムの一実施形態の位置及び所有関係認識方式の概念図である。
【図１６】本発明のネットワーク・サービス制御システムの一実施形態のアドレス解決技術及び追跡制御技術の概念図である。
【図１７】本発明のネットワーク・サービス制御システムの一実施形態の属性情報参照方式の概念図である。
【図１８】本発明のネットワーク・サービス制御システムの一実施形態の属性情報参照方式の概念図である。
【図１９】本発明のネットワーク・サービス制御システムの一実施形態の属性情報参照方式の概念図である。
【図２０】本発明のネットワーク・サービス制御システムの一実施形態の属性情報参照方式の概念図である。
【図２１】本発明のネットワーク・サービス制御システムの一実施形態の属性情報管理方式が使用するＤＢの概念図である。
【図２２】本発明のネットワーク・サービス制御システムの一実施形態の属性情報管理方式が使用するＤＢの概念図である。
【図２３】本発明のネットワーク・サービス制御システムの一実施形態の属性情報登録方式の動作のフローチャートである。
【図２４】本発明のネットワーク・サービス制御システムの一実施形態の属性情報登録方式の動作のフローチャートである。
【図２５】本発明のネットワーク・サービス制御システムの一実施形態のコンテキスト通知方式の概念図である。
【図２６】本発明のネットワーク・サービス制御システムの一実施形態のコンテキスト通知方式の概念図である。
【図２７】本発明のネットワーク・サービス制御システムの一実施形態の条件整合確認方式の動作のフローチャートである。
【図２８】本発明のネットワーク・サービス制御システムの一実施形態の条件整合確認方式の動作のフローチャートである。
【符号の説明】
【００６３】
２０１  コンテンツサーバ
２０２  ＮＷ制御サーバ
２０３  サービス制御サーバ
２０４，２０５  ユーザ端末
２０６  配信用コンテンツＤＢ
２０７  ＮＷ運用ポリシ
２０８  ＮＷコンテキスト
２０９  ユーザコンテキスト
２１０  ユーザプロファイルＤＢ
２１１  サービスプロファイルＤＢ
２１２  ＮＷコンテキストセンシング・管理部
２１３  ＮＷ制御部
２１４  ユーザコンテキストセンシング・管理部
２１５  サービス制御部
【発明を実施するための最良の形態】
【００６４】
本発明のネットワーク・サービス制御システムの一実施形態について、図１を参照して説明する。図１は、本発明のネットワーク・サービス制御システムの一実施形態の概念図である。【００６５】
図１に示されるように、本発明のネットワーク・サービス制御システムの一実施形態は、サービス提供の際に、ユーザコンテキストとユーザプロファイルとサービスプロファイルとネットワークコンテキストと、ネットワーク事業者の運用ポリシ（以下、ネットワークはＮＷと表記する場合あり）とを用いてＮＷリソース割当ての最適化を動的に行う。これにより、本発明のネットワーク・サービス制御システムは、ユーザの意向を反映させつつ、ＮＷ事業者やコンテンツを配信するサービス事業者の方針を反映させたサービスの提供及びＮＷリソースの有効利用を図る。例えばＮＷ事業者がＮＷリソースの有効利用を狙っているならば、ユーザの状況に合ったＱｏＳを満たし、かつＮＷリソースの有効利用を図ることができる。【００６６】
次に、本発明のネットワーク・サービス制御システムの一実施形態のネットワークアーキテクチャについて図２を参照して説明する。図２は、本発明のネットワーク・サービス制御システムの一実施形態のネットワークアーキテクチャの概念図である。【００６７】
図２に示されるように、本システムの一実施形態のネットワークアーキテクチャは、ＮＷ制御とサービス制御との２つの制御プレーンを備える。プレーンとは、ネットワークの機能を区別する単位である。そして、ＮＷ制御とサービス制御の２つの制御プレーンは、それぞれセンシングを行う。センシングとは、何か状況に関する仮説を立てるために、状況を観察・観測し意図や傾向を感知することである。【００６８】
サービス制御プレーンは、ユーザコンテキストを管理する。ユーザコンテキストとは、ユーザの意向に関する仮説を立てるために用いられるものであって、ユーザの場所や所持品や、ユーザの周辺の状況や、ユーザの過去の行動パターンから導かれる知識情報である。サービス制御プレーンは、ユーザコンテキストを基に、ユーザが情報を配信される際の提供形態についての希望に関しユーザから任意のタイミングで登録される情報であるユーザプロファイルに格納された情報と、配信される情報の提供形態の推奨値について情報提供者から登録される情報であるサービスプロファイルに格納された情報とを参照して、ＮＷへの要求条件を決定する。そして、サービス制御プレーンは、決定した要求条件をＮＷ制御プレーンに通知する。【００６９】
ＮＷ制御プレーンは、ＮＷコンテキストを管理する。ＮＷコンテキストとは、ＮＷの振る舞いに関する仮説を立てるために用いられるものであって、現在のトラヒックやＮＷの性能などの状況や、運用状態から導かれる知識情報である。ＮＷ制御プレーンは、受信した要求条件と、ＮＷコンテキストと、ＮＷの運用ポリシとに基づいて、動的にしかも自動的にリソースを割り当てる。ＮＷ制御プレーンへ通知される要求条件としては、例えば、ビデオＸをユーザＡの携帯端末に６Ｍｂｐｓで送信するという条件を挙げることができる。運用ポリシとしては、例えば、ネットワークのＱｏＳのレベルを所定のレベルに保つ、ネットワーク全体の負荷の均一化を図る、リソースを最大限活用するなどを挙げることができる。【００７０】
運用ポリシは、ネットワーク事業者の戦略とみることもできる。従って、例えば、「最も高い品質を提供できるように、大きな帯域を使う」という運用ポリシを設定しても良く、どのような運用ポリシを設定するかは、ネットワーク事業者が適宜設定できるものであっても良い。【００７１】
このように、本システムの一実施形態は、図２に示されるネットワークアーキテクチャによって、ユーザと、サービス事業者と、ネットワーク事業者との要求を同時に満足するＮＷ制御及びサービス制御を実行することができる。【００７２】
次に、本発明のネットワーク・サービス制御システムの一実施形態の構成について図３を参照して説明する。図３は、本発明のネットワーク・サービス制御システムの一実施形態の構成図である。【００７３】
図３に示されるように、本発明のネットワーク・サービス制御システムの一実施形態は、コンテンツサーバ２０１と、ＮＷ制御サーバ２０２と、サービス制御サーバ２０３と、少なくとも１以上のユーザ端末２０４，２０５とを備える。これら、コンテンツサーバ２０１と、ＮＷ制御サーバ２０２と、サービス制御サーバ２０３と、少なくとも１以上のユーザ端末２０４，２０５とは、ネットワークにより互いに接続されている。【００７４】
コンテンツサーバ２０１は、配信用コンテンツデータベース２０６（以下、単にＤＢとも記す）から、配信用のコンテンツをネットワークに送信する。ユーザ端末２０４，２０５は、コンテンツサーバ２０１の配信用コンテンツデータベース２０６からＮＷ制御サーバ２０２が配信したコンテンツを受信する。【００７５】
ＮＷ制御サーバ２０２は、ＮＷコンテキストを格納するＮＷコンテキストＤＢ２０８と、ＮＷ運用ポリシを格納するＮＷ運用ポリシＤＢ２０７とに接続される。ＮＷ制御サーバ２０２は、ＮＷコンテキストセンシング・管理部２１２と、ＮＷ制御部２１３とを備える。【００７６】
ＮＷコンテキストセンシング・管理部２１２は、ＮＷの状況及びＮＷの傾向の情報を収集する。ＮＷの状況の情報とは、例えば各ルータの負荷状況や回線のトラフィックの状況など、ＮＷの現在の状況に関する情報である。また、ＮＷの傾向の情報とは、例えば、平日の午前中は特定のルータの負荷が高いという情報など、過去のＮＷの運用状態を元に予測される状況の情報である。そして、ＮＷコンテキストセンシング・管理部２１２は、この収集した情報をＮＷコンテキストとして管理する。また、ＮＷコンテキストセンシング・管理部２１２は、この収集した情報を更新する。ＮＷ運用ポリシＤＢ２０７には、ＮＷ運用者から適宜登録されるＮＷの運用に関するポリシを表す情報が格納されている。【００７７】
ＮＷ制御部２１３は、サービス制御サーバ２０３から送信されたＮＷ要求条件と、ＮＷコンテキストセンシング・管理部２１２から送信されたＮＷの状況及びＮＷの傾向などのＮＷコンテキストと、ＮＷ運用ポリシＤＢ２０７から参照した運用ポリシとに基づいて、ＮＷリソース割り当てを動的に最適化する。例えば、ＮＷ制御部２１３は、最適経路を決定し、その経路でコンテンツを配信する。【００７８】
サービス制御サーバ２０３は、ユーザコンテキストセンシング・管理部２１４と、サービス制御部２１５とを備える。また、サービス制御サーバ２０３は、ユーザコンテキストＤＢ２０９と、サービスプロファイルＤＢ２１１と接続される。ユーザコンテキストＤＢ２０９は、ユーザプロファイルＤＢ２１０を備える。【００７９】
ユーザコンテキストセンシング・管理部２１４は、ユーザ周辺の状況の情報を収集する。ユーザ周辺の状況には、ユーザの位置や場所、ユーザと物との所有関係、ユーザの話相手などが含まれる。もちろん、これ以外の情報を含んでも構わない。【００８０】
そして、ユーザコンテキストセンシング・管理部２１４は、収集した情報をユーザコンテキストとして管理し、情報を更新する。また、ユーザプロファイルとして、ユーザから登録される情報である、ユーザが情報を配信される際の提供形態についての希望などの情報を管理し、情報を更新する。また、サービス制御サーバ２０３は、配信される情報の提供形態の推奨値について情報提供者から登録される情報をサービスプロファイルとして管理し、情報を更新する。サービス制御部２１５は、ユーザコンテキストと、ユーザプロファイルと、サービスプロファイルとに基づいて、ＮＷへの要求条件を生成する。【００８１】
ユーザプロファイルとユーザコンテキストとサービスプロファイルについて図４、図５及び図６を参照して説明する。【００８２】
図４はユーザプロファイルＤＢ２１０に管理されるユーザプロファイルのデータ例である。コンピュータは、登録されているパラメータの種別とその値に基づいてユーザプロファイルの内容を理解可能である。図４の例ではユーザＡのプロファイルとして、ユーザの現在位置が自宅から会社の間（通勤中）であった場合（条件１）は、２行目に情報の配信先として携帯端末が、３行目に情報配信の帯域として３８４Ｋｂｐｓで送信すべきであることが登録されている。ユーザプロファイルはユーザが適宜設定可能なものであって、一人のユーザに対し、複数の例えばユーザの現在位置の情報に応じてなど、複数のプロファイルが設定可能になっている。【００８３】
図５はユーザコンテキストＤＢ２０９に管理されているユーザコンテキストのデータ例である。図５の例ではユーザＡのコンテキストとして、１行目に現在の所在地は電車の中であり、２行目に利用している端末は携帯端末であるという情報が登録されている。
このようなユーザコンテキストＤＢ２０９のデータを参照することでサービス制御サーバ２０３は、ユーザプロファイルＤＢ２１０に登録されているデータのいずれを参照すべきかを判断することができる。例えば、図５の例では、ユーザＡの現在地は自宅から会社の間であることがわかるため、サービス制御サーバ２０３は、ユーザＡについて登録されている複数のユーザプロファイルのうち、場所の条件がユーザコンテキストのデータと合致する条件１のデータを参照すべきであると判断することができる。【００８４】
図６は、サービスプロファイルＤＢ２１１に管理されているサービスプロファイルのデータ例である。コンピュータは、登録されているパラメータの種別とその値に基づいてサービスプロファイルに記述された内容を理解可能である。図６の例ではコンテンツ１のプロファイルとして、コンテンツの名称は映画１であり、配信時の推奨帯域は３Ｍｂｐｓから６Ｍｂｐｓであり、コンテンツの上映時間は２時間１０分であり、言語は英語であり、字幕データとして日本語と英語のデータがあることが登録されている。サービスプロファイルはコンテンツの提供者が適宜設定可能なものである。【００８５】
このようなサービスプロファイルＤＢ２１１のデータを参照することでサービス制御サーバ２０３は、ユーザから配信を要求されたコンテンツにつき、どのような配信条件で配信すべきかについての情報を得ることができる。図７は、ＮＷコンテキストＤＢ２０８に管理されているネットワークコンテキストのデータ例である。コンピュータは、登録されているパラメータの種別とその値に基づいてサービスプロファイルに記述された内容を理解可能である。【００８６】
図７の例では、１つめのコンテキストとして、ルータＡについて、平日の９時から１０時の間は回避すべきであり、備考としてトラフィックが集中する旨の情報が登録されている。このような情報を参照することで、ＮＷ制御サーバは、コンテンツを配信する際のルートを決定する際に考慮すべき条件を得ることができる。【００８７】
なお、図４から図７に示したデータ例は、この内容に限るものではなく、データ内に登録されるパラメータの種別はここに例示したものに限らない。【００８８】
次に、本システムの一実施形態における、サービス制御サーバ２０３の動作について、図８を参照して説明する。図８は、本発明のネットワーク・サービス制御システムの一実施形態における、ＮＷ要求条件抽出の動作のフローチャートである。このフローチャートでは、ユーザからのコンテンツ配信要求をサービス制御サーバ２０３が受信したことをトリガとして処理が行なわれる。なお、ユーザからのコンテンツ配信要求はサービス制御サーバ２０３が直接受信しても、図３の図示しない他のサーバを経由して受信しても構わない。まず、サービス制御サーバ２０３がユーザからのコンテンツ配信要求を受信する（Ｓ２８０１）。このステップでは、配信すべきコンテンツを特定するための情報と併せて、ユーザを特定するための情報を受信する。【００８９】
次に、サービス制御サーバ２０３のサービス制御部２１５が、Ｓ２８０１で得たユーザに関する情報を元に、該ユーザのコンテキストをユーザコンテキストＤＢ２０９から読み込み、し（Ｓ２８０２）、読み込んだユーザコンテキストの内容に応じてユーザプロファイルＤＢ２１０を、さらにＳ２８０１で得たコンテンツの情報に応じてサービスプロファイルＤＢ２１１を読み込む（Ｓ２８０３）。そして、Ｓ２８０３までに読み込んだ情報を元に、サービス制御部２１５は、でＮＷ要求条件を決定する（Ｓ２８０４）。【００９０】
例えば、Ｓ２８０１でユーザＡから映画Ａの配信要求を受信した場合で、Ｓ２８０２で参照したユーザＡのユーザコンテキストが図５に示す内容であった場合、ユーザＡは現在自宅から会社の間に所在していることが判別できるので、サービス制御部２１５は、Ｓ２８０３では図４に例示したユーザＡのプロファイルのうち、パラメータ種別が「場所」に登録されている値がユーザコンテキストに登録されている値と同じである条件１のユーザコンテキストを読み込む。また、Ｓ２８０１で映画Ａの配信要求を受信しているので、サービス制御部２１５は、図６に例示するサービスプロファイルのうち、コンテンツの名称が配信要求と同じコンテンツであるコンテンツ１のサービスプロファイルを読み込む。【００９１】
そして、Ｓ２８０４で、ユーザプロファイルとサービスコンテンツの内容に基づき、例えば、配信先はユーザＡの携帯端末で、配信は３８４ＫｂｐｓでクラスＡで、音声を字幕へかつ日本語へ変換して、コンテンツＡを配信するというＮＷ要求条件を決定する。【００９２】
また、例えば、Ｓ２８０１でユーザＡから映画Ａの配信要求を受信した場合で、Ｓ２８０２で参照したユーザＡのユーザコンテキストのパラメータ種別「場所」の値としてに自宅にいる旨のデータが登録されていた場合、ユーザＡは現在自宅に所在していることが判別できるので、サービス制御部２１５は、Ｓ２８０３では図４に例示したユーザＡのプロファイルのうち、パラメータ種別「場所」に登録されている値がユーザコンテキストに登録されている値と同じである条件２のユーザコンテキストを読み込む。また、Ｓ２８０１で映画Ａの配信要求を受信しているので、サービス制御部２１５は、図６に例示するサービスプロファイルのうち、コンテンツの名称が配信要求と同じコンテンツであるコンテンツ１のサービスプロファイルを読み込む。【００９３】
そして、Ｓ２８０４で、ユーザプロファイルとサービスコンテンツの内容に基づき、例えば、配信先はユーザＡの自宅のＨＤＴＶ（ハードディスクテレビ）で、配信は６ＭｂｐｓでクラスＡで、字幕を日本語へ変換して、コンテンツＡを配信するというＮＷ要求条件を決定する。【００９４】
なお、ユーザプロファイルとサービスプロファイルとに登録されているデータのパラメータ種別や値が異なる場合にどのようにＮＷ要求条件を決定するかは、様々な決定方法を取ることができる。この決定方法については後述する。【００９５】
次に、本システムの一実施形態のＮＷ制御サーバ２０２の動作について図９を参照して説明する。このフローチャートでは、サービス制御サーバ２０３からのＮＷ要求条件をＮＷ制御サーバ２０２が受信したことをトリガとして処理が行なわれる。まず、ＮＷ制御サーバ２０３がサービス制御サーバ２０３からのＮＷ要求条件を受信する（Ｓ２９０１）。次に、ＮＷ制御サーバ２０２のＮＷ制御部２１３が、Ｓ２９０１で受信したＮＷ要求条件を元に、関連するＮＷコンテキストをＮＷコンテキストＤＢ２０８から読み込み（Ｓ２９０２）、さらにＮＷ運用ポリシＤＢ２０７を読み込む（Ｓ２９０３）。そして、Ｓ２９０３までに読み込んだ情報を元に、ＮＷ制御部２１３は、実際にコンテンツを配信するルートや条件などの配信条件を決定し（Ｓ２９０４）、その配信条件に基づいて、ネットワークリソースの割当を行い、コンテンツを配信する（Ｓ２９０５）。【００９６】
例えば、Ｓ２９０１で「配信先はユーザＡの携帯端末で、配信は３８４ＫｂｐｓでクラスＡで、音声を字幕へかつ日本語へ変換して、コンテンツＡを配信する」という内容を示すＮＷ要求条件を受信した場合であって、ユーザＡからの配信要求の受信は平日の９時３０分であった場合、ＮＷ制御部２１３はＳ２９０２で、関連するネットワークコンテキストとして、図７の条件１に示すコンテキストを読み込む。この内容により、ルータＡを回避した配信ルートを選定すべきであることを判別する。そしてＳ２９０３で、ＮＷ運用ポリシＤＢ２０７から、例えば、「ネットワーク全体の負荷が均等になるように配信ルートを決定する」などの運用ポリシを読み込む。【００９７】
Ｓ２９０３までに得た情報を元に、ＮＷ制御部２１３はＳ２９０４で、コンテンツＡをユーザＡの携帯端末へ向けて、配信は３８４ＫｂｐｓでクラスＡで、音声を字幕へかつ日本語へ変換して、ルータＡを回避したルートのうち、ネットワーク全体の負荷が均等になるようなルートで配信するという配信条件を決定し、Ｓ２９０５で配信を行なう。【００９８】
例えば、図１０で映画Ａのデータを管理するコンテンツサーバＡからユーザＡの携帯端末へ配信を行なう場合、ルータＢ、ルータＣ、ルータＤを経由する第一のルートと、ルータＢ、ルータＡ、ルータＤを経由する第二のルートとがあるが、ＮＷコンテキストとしてルータＡを回避するという条件があるため、ＮＷ制御部２１３は、ルータＡを通らない第一のルートを配信ルートとして決定する。【００９９】
また例えば、Ｓ２９０１で「配信先はユーザＡの自宅のＨＤＴＶ（ハードディスクテレビ）で、配信は６ＭｂｐｓでクラスＡで、字幕を日本語へ変換して、コンテンツＡを配信する」という内容を示すＮＷ要求条件を受信した場合であって、ユーザＡからの配信要求の受信は休日の１９時０分であった場合、ＮＷ制御部２１３はＳ２９０２で、関連するネットワークコンテキストとして、図７の条件２に示すコンテキストを読み込む。なおここでは、ユーザＡからの配信要求は１９時であるが、配信対象となる映画Ａの配信に要する時間は２時間１０分であるので、１９時から、１９時に２時間１０分を加算して得られる２１時１０分までの間に関連するネットワークコンテキストを読み込んでいる。この内容により、コンテンツサーバＡを回避した配信ルートを選定すべきであることを判別する。そしてＳ２９０３で、ＮＷ運用ポリシＤＢ２０７から、例えば、「最短のルートで配信する」などの運用ポリシを読み込む。【０１００】
Ｓ２９０３までに得た情報を元に、ＮＷ制御部２１３はＳ２９０４で、コンテンツＡをユーザＡのＨＤＴＶへ向けて、配信は６ＭｂｐｓでクラスＡで、字幕を日本語へ変換して、コンテンツサーバＡを回避したルートのうち、ネットワーク全体の負荷が均等になるようなルートで配信するという配信条件を決定し、Ｓ２９０５で配信を行なう。【０１０１】
例えば、図１０で映画ＡのデータがコンテンツサーバＡとコンテンツサーバＢとの両方に管理されていて、ユーザＡのＨＤＴＶへコンテンツの配信を行なう場合、サーバＡからルータＢ、ルータＡを経由する第一のルートと、サーバＢからルータＣ、ルータＡを経由する第二のルートなどがあるが、ＮＷコンテキストとしてコンテンツサーバＡを回避するという条件があるため、ＮＷ制御部２１３は、コンテンツサーバＡを通らない第二のルートを配信ルートとして決定する。図１０は、本発明のネットワーク・サービス制御システムの一実施形態のＮＷ制御の概念図である。【０１０２】
なお、ＮＷ制御サーバ２１３が、サービス制御サーバ２０３で決定されたＮＷ要求条件を満足するＮＷリソースの割り当てを行う際には、例えば、音声をテキストに変換するというようにメディアを変換したり、ＭＰＥＧ２をＭＰＥＧ１に変換するというように符号化方式を最適な符号化方式に変換したり、英語を日本語に変換するというように言語の変換をしたりすることができる。これらの変換は、ＮＷ要求条件として受信した条件に合うように行なわれるものであって、従来技術を適用して行なうことができる。【０１０３】
また、Ｓ２９０４決定された配信条件に基づきＳ２９０５で行なう配信処理やネットワークの制御方法については、従来技術を用いて行なうことができる。従来技術としては、例えば、トラヒックエンジニアリングを用いた経路・ＱｏＳ制御などがある。【０１０４】
ところで、前述の特許文献２，３、非特許文献４で述べたトラヒックエンジニアリングを用いた経路・ＱｏＳ制御では、現在のネットワーク及びサーバの状況のみを考慮しているが、本発明のネットワークコンテキストにおいては、これにとどまらず、図７に示したような需要変動の傾向に関するものが挙げられる。季節や曜日、時間帯などの需要変動パターンや、ＴＶのようなスケジュールされた映像配信などのイベントに対する需要変動や、利用者により申告されるネットワークの使用予定などの情報をネットワークコンテキストとして考慮できるため、例えば図７の条件２のコンテキストにより、コンテンツサーバＡを２０時から２２時の間は空けておくことができ、従ってコンテンツサーバＡで２０時から始まるリクエストを呼損にせず、サービスを提供することができる。【０１０５】
また、台風が接近してくると気象情報を持つサーバへの負荷は上がることがわかっている場合は、ネットワークコンテキストとして、気象情報以外の情報アクセスが要求された場合には、気象情報が格納されているサーバを選ばないというコンテキストを登録することも可能である。このように、需要変動に関する情報をネットワークコンテキストに登録しておくことで、予めわかっているネットワークの混雑を見越して配信ルートを決定することができる。【０１０６】
ベストエフォートサービスを提供していると、混雑時間になった際に通信の品質は劣化する。しかし、ＮＷ制御サーバ２０２は、トラフィックが混雑することを見越して経路やサーバを選択することができるので、ネットワークは、混雑が緩和される。よって、ベストエフォートサービスの品質劣化を防止することができる。【０１０７】
なお、上記説明したネットワークコンテキストの例は、ユーザやオペレータが将来のある時間帯の資源予約を行うような予約型サービスのような確定的なものではなく、仮説的なものである。そして、本実施形態の上記の需要変動傾向ＮＷコンテキストは、今までの運用から得た知識を元に仮説を立てるものである。【０１０８】
また、ネットワークコンテキストとしては、需要変動に関する情報だけではなく、現時点でのＮＷやサーバのトラヒックの状況を登録することが可能である。【０１０９】
他のネットワークコンテキストの例として、障害やミスオペレーションが発生した場合のトラヒックのふるまいをネットワークコンテキストとして蓄積しておき、このネットワークコンテキストを、障害やミスオペレーションの検知に利用することもできる。この場合、障害やミスオペレーションの発生箇所を避けて経路を決定したり、障害が発生しているサーバをネットワークから切り離したり、あるいは原因詳細を知るために更なる監視を起動したりするというコンテキストが考えられる。【０１１０】
また、ネットワーク制御を行う場合の制御の強さと効果との関係をネットワークコンテキストとして用いることもできる。例えば、複数のルータで検出した輻輳に対して複数のルータが負荷分散などの制御を同時にかけると過制御になり、振動現象を起す場合がある。【０１１１】
このような場合、制御の強さと制御の結果との関係をネットワークコンテキストとして登録しておき、実際に制御を行なう場合にはこのコンテキストを用いて制御を故意に少量ずつ行う（弱い制御）ことにより、過制御を回避できる。【０１１２】
次に、ユーザプロファイルとサービスプロファイルとに登録されているパラメータの種類及び値が異なる場合のＮＷ要求条件の決定方法について説明する。図１１は、サービス制御部２１５が図８のＳ２８０４で行なうＮＷ要求条件決定の処理を説明するための図である。サービス制御部２１５は、既に読み込んでいるＵＰとＳＰのデータをもとに本処理を行なう。【０１１３】
ＵＰの全てのパラメータを処理し終えていなければ、ＵＰから１つのパラメータとその値を読み込み（Ｓ２３０２）、ＳＰに同じ種別のパラメータがあるか否かを判定する（Ｓ２３０３）。同じパラメータがＳＰになければ（ＮＯ）、ＵＰに設定されていたパラメータとその値を要求条件として採用する（２３０４）。同じパラメータがＳＰにあれば（ＹＥＳ）、次に、そのパラメータに登録されている値が同じか否かを判定する（Ｓ２３０５）。判定の結果が同じであれば（ＹＥＳ）ＵＰ（＝ＳＰ）を要求条件とする（Ｓ２３０４）。なお、パラメータに登録されている値には、値そのものの場合も範囲の場合も帯域などのクラスの場合もある。【０１１４】
一方、Ｓ２３０５の判定の結果、ＵＰとＳＰでパラメータの値が同じでなければ（ＮＯ）、Ｓ２３０６またはＳ２３０７によりＵＰとＳＰのいずれの値を採用すべきかを決定する。Ｓ２３０６とＳ２３０７のいずれの処理を用いるかは、本システムの運用に際し適宜決定されてよい。【０１１５】
Ｓ２３０６は優先事前決定型の決定方法である。Ｓ２３０６の処理においては、ＵＰとＳＰのうち優先付けされた方のパラメータの値をＮＷ要求条件として採用する。いずれを優先させるかについては、例えば、ＵＰもしくはＳＰのいずれか片方を優先させるケースや、ＵＰとＳＰのうち条件の厳しい方を優先させるケースや、ＵＰとＳＰのうち条件の緩い方を優先させるケースなどが考えられる。【０１１６】
例えば、映像データの送信に際し、ＵＰの帯域に関するパラメータの値が３ＭｂｐｓでＳＰの帯域に関するパラメータの値６Ｍｂｐｓであった場合、条件の厳しい方に採用する場合には、ＳＰのパラメータに設定されていた６Ｍｂｐｓという値ををＮＷ要求条件として採用する。また、条件の緩い方に採用する場合には、ＵＰのパラメータに設定されていた３Ｍｂｐｓという値を要求条件として採用する。【０１１７】
また応用例として、まず要求の厳しい方に条件をＮＷ要求条件としてＮＷ制御サーバ２０２はそのＮＷ要求条件をもとに配信を行ない、その配信において呼損が発生したら、ＮＷ制御サーバ２０２からサービス制御サーバ２０３へ呼損が発生した旨を通知し、その通知をうけてサービス制御サーバ２０３では、ＮＷ要求条件の決定方法を先の条件が厳しい方を採用する決定方法から条件が緩い方を採用する決定方法へ変更し、再度ＮＷ要求条件を設定しなおしてＮＷ制御サーバ２０２へＮＷ要求条件を通知し、ＮＷ制御サーバ２０２は更新されたＮＷ要求条件をもとに配信条件を決定しなおすことも可能である。【０１１８】
Ｓ２３０７は内容比較決定型の決定方法である。Ｓ２３０７の処理においては、ＵＰとＳＰのパラメータの値を比較してＮＷ要求条件を決定する。この決定方法は、パラメータの内容が特定の値ではなく範囲で記述されている場合に適用される方式である。両パラメータの値を比較した結果どのようにＮＷ要求条件として採用する値を決定するかについては、様々な方法が考えられる。【０１１９】
例えば、どちらか一方のパラメータが特定値でどちらか一方が範囲を示す値であった場合、特定値が範囲内に入っていればその特定値をＮＷ要求条件とすることができる。また、特定値が範囲内に入っていなければ、その特定値に最も近い範囲の値、つまり範囲の最大値か最小値をＮＷ要求条件とすることができる。例えば、図４のユーザプロファイルの条件１は帯域のパラメータとして「３８４Ｋｂｐｓ」が設定されており、図６のサービスプロファイルのコンテンツ１は帯域のパラメータとして「３Ｍ〜６Ｍｂｐｓ」が設定されている。この決定方法によれば、３Ｍから６Ｍｂｐｓのうち、３８４Ｋｂｐｓに最も近い値として３Ｍｂｐｓが帯域のパラメータの値として採用されることになる。。【０１２０】
また例えば、どちらか一方のパラメータが特定値でどちらか一方が範囲を示す値であった場合、特定値の方を無条件にＮＷ要求条件としてもよい。またこれとは反対に、範囲を示す値を無条件にＮＷ要求条件としてもよい。【０１２１】
また、どちらのパラメータも範囲だけが指定され特定値が示されていない場合、範囲に重なっている部分があるならばその重なっている範囲をＮＷ要求条件とすることができる。範囲を示す値が重ならない場合は、先に述べた何れかの方法によりどちらかのプロファイルの値だけをＮＷ要求条件とすることもできる。また、いずれかもしくは両パラメータの値が範囲を示す値であっても、Ｓ２３０７ではなくＳ２３０６の方法によりいずれか片方のパラメータの値を優先させてもよい。また、両パラメータで同じ種別が存在しなかった場合には、両パラメータの各パラメータ種別、すなわち両パラメータの和集合をＮＷ要求条件とすることもできる。【０１２２】
なお、図１１を用いて、両プロファイルのパラメータ種別や値が異なる場合に、どのようにＮＷ要求条件を決定するかについての説明を行なったが、両プロファイルに登録されたデータを用いてＮＷ要求条件を決定するのであれば、ここに述べた以外の方法により決定されても構わない。例えば、ユーザプロファイルで帯域と遅延クラスについてのパラメータが、サービスプロファイルでパケット損失率と遅延クラスについてのパラメータが、それぞれ設定されていた場合に、帯域とパケット損失率と、遅延クラスの３つのパラメータ、すなわち両プロファイルの和集合をＮＷ要求条件としてもよいし、遅延クラスパラメータ、すなわち両プロファイルの積集合をＮＷ要求条件としてもよいし、帯域のパラメータだけ、もしくはパケット損失率のパラメータだけというように、どれか１つのパラメータをＮＷ要求条件としてもよい。【０１２３】
以上述べたように、本実施形態は、図３に示す構成によって、ユーザへあるコンテンツを配信する際に、ユーザの現在位置、居場所や所持端末などの情報をあらわすユーザコンテキストとコンテンツ提供方法についてのユーザの好みなどの情報をあらわすユーザプロファイル及び、コンテンツに対して設定されているサービスプロファイルとに基づいて、サービス制御サーバ２０３が、ＮＷ要求条件を決定する。そして、ＮＷ制御サーバ２０２が、そのＮＷ要求条件とＮＷコンテキストとＮＷ運用ポリシとに基づき、ＮＷのリソース割り当てが最も有効になるように経路を決定する。【０１２４】
なお、本発明を実施するシステム構成は図３に示す構成でなくても構わない。例えば、ユーザコンテキストセンシング・管理手段２１４をサービス制御サーバ２０３ではなく、別のサーバ上に設けても良い。以上で、本発明の基本的な動作について説明した。【０１２５】
次に、本発明のネットワーク・サービス制御システムの一実施形態の第２例について説明する。第１例では、ユーザからのコンテンツリクエストをトリガとして本システムが動作していたが、第２例では、システムがセンシングした状況に応じて本システムが動作する。また、第一例ではサービス制御部２１５はユーザに関する情報としてユーザコンテキストおよびユーザプロファイルを、コンテンツに関する情報としてサービスプロファイルを、それぞれ参照してＮＷ要求条件を決定していたが、第二例ではユーザコンテキストおよびユーザプロファイルのみによりＮＷ要求条件を決定する。図１２は、本発明をホームセキュリティに応用した第２例の概念図である。【０１２６】
この第２例のホームセキュリティサービスは、泥棒など人が外部から侵入したら、それを住人や警察に通知するサービスである。この例では、ユーザコンテキストとして、ユーザの現在地に関する情報やユーザの住居に人がいるかどうかに関する情報が、また、ユーザプロファイルとして、ユーザの現在地が住居以外である場合に、住居に人が侵入したことを検知したら、その旨を住人や警察に通知するという内容の情報が、それぞれ予め登録されている。【０１２７】
そして、実際に、泥棒などが住居に侵入した状況が発生した場合、ユーザコンテキストセンシング・管理部２１４は、ユーザコンテキストＤＢ２０９の内容を更新し、更新した旨をサービス制御部２１５に通知する。サービス制御部２１５は、更新されたユーザコンテキストを読み込み、ユーザプロファイルＤＢに格納されている情報に従って、ＮＷ要求条件を決定する。ＮＷ要求条件としては、例えばＳＩＰを起動し、警察や住人に電話をかけるというものである。【０１２８】
この第２例のサービスでは、住居に人が侵入したというユーザコンテンツの状況変化に応じ、電話をする以外の処理も考えられる。例えば、監視カメラを起動して録画すること、監視カメラに撮影された情報を警察のＴＶモニタに流すこと等サービスの拡張も考えられる。以上述べたように、本実施形態は、ユーザプロファイル及びユーザコンテキストに基づいて、サービス制御サーバ２０３が、ＮＷ要求条件を決定する。【０１２９】
次に、本発明のネットワーク・サービス制御システムの各処理部に関する応用例を説明する。まず、ユーザコンテキストセンシング・管理部２１４が行なうユーザコンテキスト収集方式について、図１３から図１６を参照して説明する。図１３、図１４及び図１５は、本発明のネットワーク・サービス制御システムの一実施形態の位置及び所有関係認識方式の概念図である。また、図１６は、本発明のネットワーク・サービス制御システムの一実施形態のアドレス解決技術及び追跡制御技術の概念図である。【０１３０】
まず、本発明のネットワーク・サービス制御システムの一実施形態の位置及び所有関係認識方式の第１例について、図１３を参照して説明する。図１３に示される例は、ユーザリーディング方式の位置及び所有関係認識方式である。【０１３１】
図１３に示されるように、この方式は、ユーザがリーダ機能を有する携帯電話、ＰＤＡ、携帯ＰＣ等を持つ。そして、この方式は、オブジェクトや場所に電子タグ（ＲＦＩＤ）を装着させる。そして、この方式は、オブジェクトとその所有者の論理的な関係を把握する。【０１３２】
例えば、この方式は、携帯電話のアドレスと、携帯電話が読み取った電子タグが組み込まれたオブジェクトのアドレスとを対応させて、サーバのテーブルに格納する。よって、本発明のネットワーク・サービス制御システムの一実施形態の位置及び所有関係認識方式の第１例は、このテーブルによって、携帯電話と携帯電話が読み取った電子タグが組み込まれたオブジェクトとの関係を把握する。この関係としては、例えば携帯電話と携帯電話が読み取った電子タグとの位置関係をあげることができる。【０１３３】
次に、位置及び所有関係認識方式の第２例について、図１４を参照して説明する。この第２例は、リーダ埋め込み方式の位置及び所有関係認識方式である。【０１３４】
図１４に示されるように、この第２例の方式では、動き回るオブジェクトや人に電子タグ（ＲＦＩＤ）を付与する。そして、この第２例の方式は、リーダが、あちこちに埋め込まれる。そして、この第２例の方式は、リーダで電子タグの信号を読み取る。そして、この第２例の方式は、そのオブジェクトや人が、リーダのある場所を通過したことを認識する。【０１３５】
次に、位置及び所有関係認識方式の第３例について、図１５を参照して説明する。この第３例は、ＧＰＳを用いた位置関係認識方式である。この第３例の方式では、ＧＰＳを用いて、人やオブジェクトの位置関係を把握する。【０１３６】
ここで、図１６を参照して、本実施形態のアドレス解決技術及び追跡制御技術について説明する。図１６は、本発明のネットワーク・サービス制御システムの一実施形態のアドレス解決技術及び追跡制御技術の概念図である。【０１３７】
（α）、（β）まず、情報を受信するユーザは、ユーザの位置及びオブジェクトの位置をユーザ位置管理サーバに登録する。
（１）図１６に示されるように、情報を発信するユーザは、ＩＤ解決サーバに、意味による問いを発する。図１６に示される例では、モーツァルトＤＶＤ購入者という問いを発する。【０１３８】
（２）そして、ＩＤ解決サーバは、モーツァルトＤＶＤのＩＤをユーザに送信する。【０１３９】
（３）そして、ユーザは、受信したＩＤに基づいて情報を発信する。
（４）、（５）そして、オブジェクト位置管理サーバは、オブジェクトの位置の問い合わせに対して、所有者という返答をする。【０１４０】
（６）、（７）そして、ユーザ位置管理サーバは、所有者の位置の問い合わせに対して、所有者のＮＷアドレスを返答する。
（８）そして、ＧＭＰＬＳシグナリングにより、情報を発信するユーザからの情報が、情報を受信するユーザに送信される。【０１４１】
次に、本発明のネットワーク・サービス制御システムのユーザコンテキストセンシング・管理部２１４が行なう属性情報参照方式について、図１７、図１８、図１９及び図２０を参照して説明する。図１７、図１８、図１９及び図２０は、本発明のネットワーク・サービス制御システムの一実施形態の属性情報参照方式の概念図である。【０１４２】
まず、属性参照方式の第１の方式について説明する。図１７に示されるように、本実施形態の属性参照方式の第１の方式は、前述の位置及び所有関係認識方式において、電子タグにＩＤだけでなく属性情報が書き込まれる方式である。【０１４３】
属性情報は、例えば、この場所は会議室、このデバイスはＰＣなどという情報である。この本実施形態の属性参照方式の第１の方式は、電子タグの中身を読み取った時点で属性がわかる。この本実施形態の属性参照方式の第１の方式は、最もＮＷに負荷がかからない方法である。しかし、本実施形態の属性参照方式の第１の方式は、属性情報に含められる情報量に限りがある。【０１４４】
次に、属性参照方式の第２の方式について説明する。図１８に示されるように、本実施形態の属性参照方式の第２の方式は、前述の位置及び所有関係認識方式において、電子タグにＩＤだけが書き込まれる場合である。また、本実施形態の属性参照方式の第２の方式の場合、属性情報はサーバに格納されている。本実施形態の属性参照方式の第２の方式は、ネットワーク経由でサーバから属性情報を読み出す。【０１４５】
そして、本実施形態の属性参照方式の第２の方式は、サーバから属性情報を読み出す方式として、直接そのサーバにアクセスする方式を備える。【０１４６】
また、本実施形態の属性参照方式の第２の方式は、所定のＩＤを有するオブジェクトの属性情報が書かれているサーバのアドレスを、ＩＤ−ＮＷアドレス解決サーバに問い合わせる。本実施形態の属性参照方式の第２の方式は、属性情報が書かれているサーバへアクセスして属性情報を取得する。また、本実施形態の属性参照方式の第２の方式は、ＩＤと詳細情報のフォーマットを新たに定義できる。【０１４７】
次に、図１９を用いて、属性参照方式の第３の方式について説明する。この方式は、前述の位置及び所有関係認識方式において、図１７に示される方式と図１８に示される方式との第１の中間の方式となる属性参照方式である。【０１４８】
この属性参照方式では、属性情報は電子タグに格納されていない。しかし、この場合の属性参照方式は、ＩＤとこの属性情報の識別子（例えばＵＲＬ）が電子タグに格納されている。そのため、この属性参照方式の第３の方式は、このＵＲＬを元に既存のＤＮＳ（Ｄｏｍａｉｎ  Ｎａｍｅ  Ｓｙｓｔｅｍ）経由でその属性情報が書かれているサーバのＩＰアドレスを特定する。【０１４９】
そして、この第３の方式の属性参照方式は、サーバから属性情報を得る。ＩＤの指す属性情報を、既存のＵＲＬを用いて参照できる場合、この第３の方式の属性参照方式は便利である。【０１５０】
次に、図２０を参照して、属性参照方式の第４の方式について説明する。この第４の方式は、前述の位置及び所有関係認識方式において、図１７に示される方式と図１８に示される方式との第２の中間の方式となる属性参照方式である。【０１５１】
本実施形態の属性参照方式の第４の方式では、属性情報は電子タグに格納されていない。しかし、電子タグは、ＩＤと、ＮＷアドレスとを格納している。このＮＷアドレスは、属性情報が入っているサーバの、例えばＩＰアドレスなどのＮＷアドレスである。【０１５２】
あるいは、本実施形態の属性参照方式の第４の方式では、電子タグに格納されるのは、ＩＤと、ＮＷアドレスを知るためにアクセスすべきＩＤ−ＮＷアドレス解決サーバのＮＷアドレスであっても良い。この電子タグには、中間のサーバのＮＷアドレスを格納しておいても良い。また、この電子タグに格納されている情報は、順番に書き換えていっても良い。【０１５３】
次に、属性参照方式の第５の方式について説明する。この第５の方式は、図１４に示される方式において、数箇所のリーダの通過履歴から、動いている人やオブジェクトの動きの方向を把握する方式である。例えば、本実施形態では、リーダＡ及びリーダＢが、順次通貨履歴を記録した場合、人やオブジェクトがリーダＡからリーダＢの方向に移動していることを認識する。【０１５４】
次に、属性参照方式の第６の方式について説明する。この第６の方式は、図１４に示される方式において、オブジェクトの動きと、リーダの動きとが同じことから、一緒に動いていること、すなわち、所有関係や話相手であるという関係であることを認識する方式である。【０１５５】
次に、属性参照方式の第７の方式について説明する。この第７の方式は、図１４に示される方式において、埋め込まれたリーダからその場所の属性情報が送られてくる方式である。【０１５６】
次に、属性参照方式の第８の方式について説明する。この第８の方式は、図１４に示される方式において、埋め込まれたリーダからその場所の識別子だけが送られる方式である。そして、この第８の方式は、ネットワーク経由でその識別子から場所の属性を特定する。【０１５７】
次に、属性参照方式の第９の方式について説明する。この第９の方式は、図１４に示される方式において、電子タグを持参している人やモノの属性を図１７から図２０に示される場合と同様に参照する。【０１５８】
次に、本発明のネットワーク・サービス制御システムのユーザコンテキストセンシング・管理部２１４が行なう属性情報管理方式について、図２１及び図２２を参照して説明する。図２１及び図２２は、本発明のネットワーク・サービス制御システムの一実施形態の属性情報管理方式が使用するＤＢの概念図である。【０１５９】
まず、本実施形態の属性情報管理方式の第１の方法について図２１を参照して説明する。図２１に示されるように、第１の方法は、ＮＷ制御プレーンにあるＲＦＩＤ（オブジェクト）／リーダ（ユーザ）関係管理ＤＢと、サービス制御プレーンにあるＲＦＩＤ（オブジェクト）／属性管理ＤＢとが独立して存在する。【０１６０】
そして、第１の方法は、必要に応じて、ユーザに関係する（所有する、その場に居合わす、近くに存在する）オブジェクトの属性をＲＦＩＤ（オブジェクト）／属性管理ＤＢに問い合わせる。そして、第１の方法は、ユーザコンテキストを得る。この方法では、例えば、オブジェクト／ユーザ関係管理ＤＢが、ユーザ（ｍａｓａ）がオブジェクト（＃０５５１）に関係していることがわかる。さらに、オブジェクト／属性管理ＤＢから＃０５５１のオブジェクトがＣＤであることがわかる。そして、これらの関係からユーザ（＃ｍａｓａ）がＣＤであるオブジェクトを所有していることがわかる。【０１６１】
次に、本実施形態の属性情報管理方式の第２の方法について図２２を参照して説明する。図２２に示されるように、第２の方法は、リーダ（ユーザ）が読み取ったＲＦＩＤ（オブジェクト）とその属性とを、一つのＤＢで管理する。【０１６２】
次に、本発明のネットワーク・サービス制御システムのユーザコンテキストセンシング・管理部２１４が行なう属性情報登録方式について、図２３及び図２４を参照して説明する。図２３及び図２４は、本発明のネットワーク・サービス制御システムの一実施形態の属性情報登録方式の動作のフローチャートである。なおこの実施例は、ユーザコンテキストセンシング・管理部２１４はサービス制御サーバ２０３とは別のコンテキスト管理サーバ上に設けられている例である。また、関係管理ＤＢや属性管理ＤＢは、コンテキスト管理サーバに設けられている。【０１６３】
まず、図２３及び図２４に示される関係管理の例について説明する。関係管理とは、ユーザとオブジェクトのＩＤとの関係を管理することをいう。関係管理の例としては、例えばＡは＃０５５１を持っているという情報や、Ｂは＃２３８５にいるという情報である。【０１６４】
また、図２３及び図２４に示される属性管理の例について説明する。属性管理とは、オブジェクトの属性を管理することをいう。属性管理の例としては、例えば＃０５５１はＣＤであるという情報や、＃２３８５は会議室であるという情報がある。【０１６５】
また、図２３及び図２４に示されるコンテキスト管理の例について説明する。コンテキスト管理とは、ユーザとオブジェクトとの関係を管理することをいう。コンテキスト管理の例としては、ＡはＣＤを持っているという情報や、Ｂは会議室にいるという情報がある。【０１６６】
図２３に示される属性情報登録方式は、リーダがＲＦＩＤを読み取った時に属性を入力する方式である。図２３に示される例では、リーダから関係管理ＤＢにタグＩＤ及びリーダＩＤが送信される。ここで送信される情報は、例えば＃０５５１の識別情報を有する電子タグがＡのリーダで読み込まれたという情報である。【０１６７】
次に、コンテキスト管理サーバは、関係管理ＤＢからユーザとオブジェクトとの関係を取得する。関係管理ＤＢは、タグＩＤがコンテキスト管理サーバに送信する。コンテキスト管理サーバは、属性管理ＤＢから属性を取得する。属性管理ＤＢは、属性をコンテキスト管理サーバに送信する。ここで送信される属性は、例えば＃０５５１はＣＤであるという情報である。【０１６８】
次に、コンテキストアウェアサービス制御サーバは、コンテキスト要求をコンテキスト管理サーバに送信する。コンテキスト管理サーバは、コンテキストアウェアサービス制御サーバに、コンテキスト回答を送信する。個々で送信されるコンテキスト回答は、例えばＡはＣＤを持っているという情報である。【０１６９】
図２４に示される属性情報登録方式は、リーダがＲＦＩＤを読み取った時には何もしない。しかし、図２４に示される属性情報登録方式は、必要な時に属性を入力する方式である。【０１７０】
図２４に示される例では、リーダが関係管理ＤＢに、タグＩＤ及びリーダＩＤを送信する。ここで送信される情報は、例えば＃２３８５がＢのリーダで読み込まれたという情報である。【０１７１】
次に、コンテキストアウェアサービス制御サーバは、コンテキスト管理サーバにコンテキストを要求する。次に、コンテキスト管理サーバは、関係管理ＤＢからユーザとオブジェクトとの関係を取得する。そして、関係管理ＤＢは、コンテキスト管理サーバにタグＩＤを送信する。次にコンテキスト管理サーバは、属性管理ＤＢからオブジェクトの属性を取得する。そして、属性管理ＤＢは、属性をコンテキスト管理サーバに送信する。この属性は、例えば＃２３８５は会議室という情報である。【０１７２】
そして、コンテキスト管理サーバは、コンテキストアウェアサービス制御サーバに、コンテキストを回答する。個々で回答するコンテキストの内容は、例えばＢは会議室にいるという情報である。【０１７３】
ここで、コンテキスト管理サーバが関係管理ＤＢにユーザとオブジェクトとの関係を尋ねる処理のトリガは、図２４に示されるように、コンテキストが明示的に要求される場合と、整合性のチェック時に自動的に行われる場合とがある。【０１７４】
次に、図２４において述べた必要な時の第１例について図２５を参照して説明する。この必要な時の第１例は、サービスが要求された時、すなわち、オンデマンド型のコンテキスト通知方式である。図２５は、本発明のネットワーク・サービス制御システムの一実施形態のコンテキスト通知方式の概念図である。【０１７５】
オンデマンド型のコンテキスト通知方式においては、図２５に示されるように、サービスが、ユーザ、サービス提供者又はＮＷ運用者などから起動されたときに、サービス制御部２１５は、ユーザコンテキストセンシング・管理部２１４に、もしくはＮＷ制御部２１３はＮＷコンテキストセンシング・管理部２１２にコンテキストを要求する。そして、ユーザコンテキストセンシング・管理部２１４もしくはＮＷコンテキストセンシング・管理部２１２は、サービス制御部２１５もしくはＮＷ制御部２１３にコンテキストを通知する。前述の図２３の場合及び図２４の場合のシーケンスはどちらもこのパターンに属する。【０１７６】
次に、図２４において述べた必要な時の第２例について図２６を参照して説明する。図２６は、本発明のネットワーク・サービス制御システムの一実施形態のコンテキスト通知方式の概念図である。この必要な時の第２例は、コンテキストの整合のチェックを要求された時、すなわち条件整合時自動通知型のコンテキスト通知方式である。コンテキストの整合のチェックとは、ユーザコンテキストに示されるオブジェクトの属性と、登録されたオブジェクトの属性とが一致するか否かをチェックすることをいう。図２６に示されるように、ある条件が成立したときに、ユーザコンテキストセンシング・管理部２１４は、自発的にサービス制御部２１５にコンテキストを通知する。この条件として、例えば所定の人が所定の場所に到達した場合をあげることができる。【０１７７】
上述の図２６の条件整合時自動通知型の場合における、条件の成立のチェックの第１例について図２７を参照して説明する。図２７は、本発明のネットワーク・サービス制御システムの一実施形態の条件整合確認方式の動作のフローチャートである。図２６における条件の成立のチェックの第１例は、関係管理の内容に変化があった時などのコンテキストの変化が生じたことをトリガにチェックを行う。【０１７８】
図２７に示されるように、ユーザ及びサービス提供者などは、コンテキスト管理ＤＢに条件を事前に登録する。ここで登録される条件としては、例えばＢが会議室に到着したら通知するという条件がある。【０１７９】
そして、リーダは、タグＩＤ及びリーダＩＤを関係管理ＤＢに送信する。ここで送信する情報は、例えば＃２３８５がＢのリーダで読まれたという情報である。そして、関係管理ＤＢは、コンテキスト管理ＤＢに関係変更を通知する。【０１８０】
そして、コンテキスト管理ＤＢは、オブジェクトの属性を属性管理ＤＢに尋ねる。属性管理ＤＢは、属性をコンテキスト管理ＤＢに送信する。ここで送信される属性は、例えば＃２３８５は会議室という情報である。【０１８１】
そして、コンテキスト管理ＤＢは、関係管理ＤＢから送信された情報と、ユーザ及びサービス提供者などから送信された情報が一致したか否かを判定する。そして、コンテキスト管理ＤＢは、関係管理ＤＢから送信された情報と、ユーザ及びサービス提供者などから送信された情報が一致した場合、ユーザ及びサービス提供者などにコンテキストを通知する。ここで通知される情報は、例えば、Ｂは会議室にいるという情報である。【０１８２】
次に、上述の図２６の条件整合時自動通知型の場合における、条件の成立のチェックの第２例について図２８を参照して説明する。図２８は、本発明のネットワーク・サービス制御システムの一実施形態の条件整合確認方式の動作のフローチャートである。図２６における条件の成立のチェックの第２例は、時間を用いて条件成立のチェックを行う。例えば、この第２例は、図２６における条件の成立のチェックを、一定周期や前のチェック時刻から少しずつ時間間隔を広げる又は時間間隔を短くするなどして行う。更に、この第２例は、時間のほかに他の要素を用いて条件の成立のチェックを行うこともできる。例えば、この第２例は、電車からの下車をサービスのトリガとする場合、電車に乗っていることがわかっていたなら、電車に乗っていない場合よりもより短い時間間隔で条件の成立、すなわち下車することをチェックする。【０１８３】
図２８に示される例では、ユーザ及びサービス提供者などは、コンテキスト管理ＤＢに条件を事前に登録する。ここで登録される実施形態要件は、例えば、Ｂが会議室に到着したら通知を行うという条件である。【０１８４】
そして、コンテキスト管理ＤＢは、経過時間を越えたか否かを確認する。ここでは、時間間隔ではなく、時刻に着目している。そして、コンテキスト管理部は、経過時間を越えた場合、オブジェクトの属性を属性管理ＤＢに尋ねる。そして、属性管理ＤＢは、オブジェクトの属性をコンテキスト管理ＤＢに送信する。ここで送信される情報は、例えば、＃２３８５は会議室という情報である。ここで、属性管理ＤＢが属性をコンテキスト管理ＤＢに送信する処理は、既に属性が既知であれば不要である。【０１８５】
そして、コンテキスト管理ＤＢは、ユーザ及びサービス提供者などが事前に登録した情報と、属性管理ＤＢから送信された情報とが一致しているか否かを判定する。そして、コンテキスト管理ＤＢは、ユーザ及びサービス提供者などが事前に登録した情報と、属性管理ＤＢから送信された情報とが一致している場合、ユーザ及びサービス提供者などにコンテキストを通知する。ここで通知されるコンテキストは、例えばＢは会議室にいるという情報である。【０１８６】
次に、上述の図２６の条件整合時自動通知型の場合における、条件の成立のチェックの第３例について説明する。この第３例では、図２６における条件の成立のチェックを、設定された所定の日時に行う。
【図１】
0005224689.tif 000002
【図２】
0005224689.tif 000003
【図３】
0005224689.tif 000004
【図４】
0005224689.tif 000005
【図５】
0005224689.tif 000006
【図６】
0005224689.tif 000007
【図７】
0005224689.tif 000008
【図８】
0005224689.tif 000009
【図９】
0005224689.tif 000010
【図１０】
0005224689.tif 000011
【図１１】
0005224689.tif 000012
【図１２】
0005224689.tif 000013
【図１３】
0005224689.tif 000014
【図１４】
0005224689.tif 000015
【図１５】
0005224689.tif 000016
【図１６】
0005224689.tif 000017
【図１７】
0005224689.tif 000018
【図１８】
0005224689.tif 000019
【図１９】
0005224689.tif 000020
【図２０】
0005224689.tif 000021
【図２１】
0005224689.tif 000022
【図２２】
0005224689.tif 000023
【図２３】
0005224689.tif 000024
【図２４】
0005224689.tif 000025
【図２５】
0005224689.tif 000026
【図２６】
0005224689.tif 000027
【図２７】
0005224689.tif 000028
【図２８】
0005224689.tif 000029