通信システムにおいて個人化サービスを提供及び管理するための装置及び方法
【課題】データの多様な表現を通じて装備の特性、ユーザの要求、所望のサービスを表すことができる政策基盤、状況認識、選好度及びプロファイルモデルを具現することで、通信システムにおいて個人化サービスを提供及び管理するための装置及び方法を提供する。
【解決手段】ベンダー及び装置に従属的なセンサデータを正規化された形態に変換してセンサデータを生成する前処理部１００と、前記センサデータに基づいて現在管理中のエンティティの現在の状態を決定し、状態関連状況データを生成し、ユーザに割り当てられた現在のサービス及びリソースが満足されるかを決定する分析部２００と、前記分析部２００での前記状態関連状況データを調べて要求されるサービス及びリソースと関連して前記ユーザの要求を満足するかを決定し、満足しなければ、前記要求されるサービス及びリソースを前記ユーザに提供するために取るべき措置を決定する個人化サーバ３００を含む。
【解決手段】ベンダー及び装置に従属的なセンサデータを正規化された形態に変換してセンサデータを生成する前処理部１００と、前記センサデータに基づいて現在管理中のエンティティの現在の状態を決定し、状態関連状況データを生成し、ユーザに割り当てられた現在のサービス及びリソースが満足されるかを決定する分析部２００と、前記分析部２００での前記状態関連状況データを調べて要求されるサービス及びリソースと関連して前記ユーザの要求を満足するかを決定し、満足しなければ、前記要求されるサービス及びリソースを前記ユーザに提供するために取るべき措置を決定する個人化サーバ３００を含む。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザとユーザのグループのための個人化されたサービスの領域に関し、特に、通信用装備のための政策基盤、状況認識、選好度及びプロファイルモデルを具現することによって、通信システムにおいて個人化サービスを提供し管理するための装置及び方法に関する。
【背景技術】
【０００２】
一般に、ルータ、ハブなどの多様な装備が混在するネットワークは、それぞれ装備が他の形態の機能とこのような機能を動作するための命令やデータを提供する方法がそれぞれ異なり、ひいては同一の会社で生産された製品であっても多様なバージョンに応じて異なる情報を有している。
【０００３】
現在の管理システムは、このような異なる装備を管理するために、あらゆる形態の装備毎にそれぞれ異なるソフトウェアを作って提供しており、これにより、類似する形態の命令であってもそれぞれ異なるソフトウェアが必要になった。
【０００４】
前記のような多様な装備の効率的な管理のためには、共通した管理情報を定義する必要があり、特に、個人化されたサービスを提供するためには、プロファイルモデル、選好度モデル、特性モデルを定義する必要がある。
【０００５】
[プロファイル（Ｐｒｏｆｉｌｅ）モデル]
まず、プロファイルモデルは、ユーザの個人情報、選好度及び個人的な要求事項及び経験情報を格納する１つのエンティティとして定義される。このような技術としては、Ｗ３Ｃにより定義されたＣｏｍｐｏｓｉｔｅ Ｃａｐａｂｉｌｉｔｉｅｓ Ｐｒｅｆｅｒｅｎｃｅｓ Ｐｒｏｆｉｌｅ（ＣＣ／ＰＰ）とＷＡＰ Ｆｏｒｕｍにより定義されたＵｓｅｒ Ａｇｅｎｔ Ｐｒｏｆｉｌｅ（ＵＡＰｒｏｆ）が挙げられる。ＵＡＰｒｏｆは、ＣＣ／ＰＰを基盤とする特殊な形態である。ＣＣ／ＰＰは、Ｒｅｓｏｕｒｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｆｒａｍｅｗｏｒｋ（ＲＤＦ）を用いて表現され、装備の特性とユーザの選好度を記述する。これらの２つの組み合わせは、プロファイルとして定義され、コンテンツが装備に十分に適応するようにガイドするために用いられる。
【０００６】
３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ（３ＧＰＰ）は、収集したユーザ関連データを標準化するＧｅｎｅｒｉｃ Ｕｓｅｒ Ｐｒｏｆｉｌｅ（ＧＵＰ）を定義した。これは、ユーザがいかなるサービスに加入されているか、いかなる権限を持っているか、ユーザの設定情報（例えば、名前、電話番号）及び選好度情報、モバイルネットワーク情報、選好するネットワーク技術及びＧＰＲＳ設定、他のサービスのプライバシー設定、端末関連データ及び料金体系と関連したデータを定義している。
【０００７】
[選好度（Ｐｒｅｆｅｒｅｎｃｅ）モデル]
次に、選好度モデルは、ユーザの選択を示すことができる値を定義したものであって、前述したＣＣ／ＰＰとＰｌａｔｆｏｒｍ ｆｏｒ Ｐｒｉｖａｃｙ Ｐｒｅｆｅｒｅｎｃｅｓ Ｐｒｏｊｅｃｔ（Ｐ３Ｐ）を含んで多くの選好度モデルが定義されている。Ｐ３Ｐは、エンティティがプライバシー政策を通じてユーザについて収集した情報の計画された使用を申告することを可能にするプロトコルである。ユーザがあるエンティティと交流することを決定するとき、ユーザは自身の政策を定義し、自分が交流するエンティティにより公開されることを許容する個人情報を明示する。そうすると、Ｐ３Ｐは政策を比較し、政策処理手順が同意されなければ、ユーザにいかなる措置を取るかを決定するようにする。
【０００８】
[特性（Ｃａｐａｂｉｌｉｔｙ）モデル]
前記で定義されたＣＣ／ＰＰに加えて、特許文献１の“Ｍｅｔｈｏｄ ｏｆ ｐｒｏｖｉｄｉｎｇ ｃｏｎｔｅｎｔ ｔｏ ａ ｔａｒｇｅｔ ｄｅｖｉｃｅ ｉｎ ａ ｎｅｔｗｏｒｋ”で特性モデルを定義している。この特許は、サーバが特定の装備に最適のコンテンツを提供する方法を決定することを可能にする方法を提示している。これは制約事項（ｃｏｎｓｔｒａｉｎｔｓ）を評価して対象となる装備が１つ以上の特性クラスに属するかを判断することによって可能になる。しかし、前記のようなプロファイルモデル、選好度モデル、特性モデルを用いてネットワークに用いられる多様な装備を効率的に管理しようとする本分野の従来技術においては、政策基盤の管理技術を通じて状況認識基盤の個人化されたサービスのための効率的な方法を提示していない。具体的に、従来技術は、次のような重要な限界を有している。即ち、ユーザの要求と業務の目的及び環境条件が変化するのを考慮して該当装備の構成を変更することが不可能であり、状況データの変化する関係を説明するために装備の構成を調整することが不可能であり、ユーザの要求に適した特定の動作を行うようにシステムの動作を組織することが不可能であり、制約事項（例えば、業務により定義された限界、サービス状況に起因する誘発）を所望のサービスと関連付けることが不可能であり、他のユーザの要求を満足させる他のドメインからサービスとリソースを連合することが不可能である。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】米国特許第７,５１６,０４５Ｂ２号明細書
【発明の概要】
【発明が解決しようとする課題】
【００１０】
そこで、本発明は上記事情に鑑みてなされたものであって、その目的は、データの多様な表現を通じて装備の特性、ユーザの要求、所望のサービスを表すことができる政策基盤、状況認識、選好度及びプロファイルモデルを具現することによって、通信システムにおいて個人化サービスを提供及び管理するための装置及び方法を提供することにある。
【００１１】
また、本発明の他の目的は、変化する状況要求を、提供されるリソースとサービスを再構成するために使用され得る形態に変換させることができる政策基盤、状況認識、選好度及びプロファイルモデルを具現することによって、通信システムにおいて個人化サービスを提供及び管理するための装置及び方法を提供することにある。
【課題を解決するための手段】
【００１２】
本発明の第１の観点による通信システムにおける個人化サービスの提供及び管理のための装置は、ベンダー（ｖｅｎｄｏｒ）及び装置に従属的なセンサデータを正規化された形態に変換して正規化されたセンサデータを生成する前処理部と、前記正規化されたセンサデータに基づいて現在管理中のエンティティの現在の状態を決定し、状態関連状況データを生成して、それにより、ユーザに割り当てられた現在のサービス及びリソースが満足されるかを決定する分析部と、前記分析部からの前記状態関連状況データを調べて要求されるサービス及びリソースと関連して前記ユーザの要求が満たされるかを決定し、満たされなければ、前記要求されるサービス及びリソースを前記ユーザに提供するためにいかなる措置を取らなければならないかを決定する個人化サーバとを含む。
【００１３】
本発明の第２の観点による通信システムにおける個人化サービスの提供及び管理のための方法は、ベンダー及び装置に従属的なセンサデータを正規化された形態に変換して正規化されたセンサデータを生成する前処理を行う段階と、前記正規化されたセンサデータを分析し、管理されるエンティティの現在の状態を決定し、状態関連状況データを生成して、それにより、ユーザに割り当てられた現在のサービス及びリソースが満足されるかを決定する段階と、前記状態関連状況データを調べて、前記ユーザにより要求される状況従属的なサービス及びリソースが提供されるように保障するために、いかなる措置を取らなければならないかを決定する段階とを含む。
【発明の効果】
【００１４】
本発明は、ＲＤＦのような特定の技術に依存しないので、いかなる具現にも適用可能であるという利点がある。
【００１５】
また、本発明によれば、特性、プロファイル及び選好度に対する別途の客体及びモデルを定義することによって、拡張性と柔軟性を提供し、ＤＥＮ-ｎｇ情報モデルを用いて有用性と拡張性を更に向上させるという効果を奏する。
【００１６】
更に、本発明は、データの多様な表現が装置、ユーザの要求及び所望のサービスを表すことができるようにして、いかなる通信装置であっても、順調な管理が可能にすると共に、変化する状況要求が提供されるリソースとサービスを再構成できる形態に変換され得るようにする。
【図面の簡単な説明】
【００１７】
【図１】発明の実施形態による個人化サービスを提供及び管理するための装置の特徴を示す概念図である。
【図２】図１に示した前処理部の詳細概念図である。
【図３】ＤＥＮ-ｎｇモデルの簡単な概念的な構造を示す図である。
【図４】図１に示した個人化部における個人化過程のフローチャートである。
【図５】ＤＥＮ-ｎｇ加入モデルを示す図である。
【図６】加入を制御し管理するために政策規則がどのように使用され得るかを示す図である。
【図７】選好度を管理する簡単なモデルを示す図である。
【図８】ＤＥＮ-ｎｇ情報モデルの最も上位レベルを示す図である。
【図９】制約をメタデータとしてエンコードすることを示す図である。
【図１０】ＤＥＮ-ｎｇドメインモデルを示す図である。
【図１１】状況（Ｃｏｎｔｅｘｔ）を連邦化するための新たなモデルを示す図である。
【図１２】状況情報の連邦を管理するために状況情報基盤政策規則を適用する概念を示す図である。
【図１３】ＤＥＮ-ｎｇ状況認識政策モデルを簡単に示す図である。
【図１４】特定状況のための関連関数の例を示す図である。
【発明を実施するための形態】
【００１８】
以下、添付する図面を参照して本発明の動作原理を詳細に説明する。下記で本発明を説明するにおいて公知となった又は構成についての具体的な説明が本発明の要旨を不要に曖昧にするおそれがあると判断される場合には、その詳細な説明を省略する。そして、後述する用語は、本発明における機能を考慮して定義された用語であって、これは、ユーザ、運用者の意図又は慣例などによって変わり得る。従って、その定義は、本明細書全般に渡る内容に基づいてなされるべきである。
【００１９】
図１は、本発明の実施形態による通信システムにおいて個人化サービスを提供し管理するための装置の特徴を示す概念的な構造図を示すものである。前記個人化サービスを提供し管理するための装置は、前処理部（ｐｒｅ-ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ）１００、分析部（ａｎａｌｙｓｉｓ ｕｎｉｔ）２００、個人化部（ｐｅｒｓｏｎａｌｉｚａｔｉｏｎ ｕｎｉｔ）３００を含む。
【００２０】
ネットワークで発生するデータは、本質的に多様な形態を有しており、これを統合することは容易ではない。その上、状況情報は、複数のドメインからの複数のデータからなる。従って、互いに異なるデータを互いに関連付けられなければ、現在のシステムが現在の状況情報を決定できなくなる。現在は、多様な形態の管理及び運用データを状況データと関連付けられるように標準化されたマッピングがないため、状況情報が変わるとき、提供されるリソースやサービスを標準化された方法で変更することは不可能である。
【００２１】
本発明では、前記のような問題点を３つの過程、即ち、前処理部１００における前処理過程、分析部２００における分析過程、個人化部３００における個人化サービス過程を通じて解決する。多様な形態の管理及び運用データを状況データと関連付ける際の複雑性により、本発明は、これらのデータの組み合わせが最終のユーザのための個人化されたサービスを提供するために、どのように使用されるかを定義する政策規則を用いる。具体的に、本発明は、状況情報が多様な形態の運用データを分析するために用いられる政策規則を選択することと、そのようなデータを用いて決定することを可能とする。
【００２２】
前処理部１００は、特定のベンダーや装置に従属的なセンサデータを正規化された（ｎｏｒｍａｌｉｚｅｄ）形態に変更する。同様に、特定のベンダーや装置に独立的な正規化された命令語を、それと同等なベンダーや装置に従属的な命令語に変更する。
【００２３】
分析部２００は、正規化されたセンサデータに基づいて現在管理されるエンティティ（Ｅｎｔｉｔｙ）の現在の状態を決定する。その後、管理される要素の現在の状態をそのエンティティの意図する状態と比較して、仮に現在の状態と意図された状態とが同一であれば、分析部２００は正規化されたセンサデータを監視し続けるよう決定を下す。しかし、前記２つの状態が同一でなければ、分析部２００は、この情報を用いて現在のユーザに割り当てられたサービスやリソースがいかなる方法であれ、脅威されているか否かを決定し、ユーザのサービスとリソースが脅威されていないことを保障するために取られなければならない勧告措置を定義する。
【００２４】
個人化部３００は、分析部２００から勧告措置、即ち、推薦命令語を受信して、提案された命令を具現したり、センサデータが割り当てられたサービスやリソースが脅威されていることを表せば、モニタリングする新しいデータを提案したり、問題を解決できる命令語を定義する。
【００２５】
以下、前処理過程、分析過程、個人化サービス過程について更に詳細に説明する。
【００２６】
[前処理過程]
まず、前処理過程について詳察すると、前処理部１００で前処理機能を行うために使用され得る方法は多数ある。そのうち、最も選好する具現は、変換過程をガイドするために、ＤＥＮ-ｎｇ（Ｄｉｒｅｃｔｏｒｙ Ｅｎａｂｌｅｄ Ｎｅｔｗｏｒｋｓ-ｎｅｘｔ ｇｅｎｅｒａｔｉｏｎ）モデルを用いることである。
【００２７】
図２は、図１に示した前処理部１００の詳細ブロックを示すものである。前処理部１００は、装置１０６、情報モデル１０２、データモデル（ｄａｔａ ｍｏｄｅｌ）１０４、装置変換器（ｄｅｖｉｃｅ ｃｏｎｖｅｒｔｅｒ）１０８、客体生成ロジックモジュール１１０を含む。
【００２８】
他のセンサから作られた原始データ（ｒａｗ ｄａｔａ）を他の形態や言語に変更できる。これは、各装置が自身の管理データを表すために、特定の言語を用いるためである。事実上、各装置（ｄｅｖｉｃｅ）１０６は、ＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）やＣＬＩ（Ｃｏｍｍａｎｄ Ｌｉｎｅ Ｉｎｔｅｒｆａｃｅ）などの異なる言語を用いて異なるデータを作ることができる。これは、装置、データモデル１０４、装置変換器１０８の数が同一になることもできるという理由となる。
【００２９】
選好する接近方法は、ソフトウェアパターンの使用を基盤として各装置１０６からの管理データだけでなく、本発明の核心概念、即ち、特性、状況情報、選好度、プロファイル、加入情報、及びユーザ情報を表すために同一の情報モデル（Ｉｎｆｏｒｍａｔｉｏｎ ｍｏｄｅｌ）１０２を用いることである。これは、装置管理データが本発明の概念と関連があるということを保証する。この接近方法において、情報モデル１０２は、分析テンプレート（ｔｅｍｐｌａｔｅ）及びランタイム（ｒｕｎｔｉｍｅ）テンプレートとして用いられる。分析テンプレートのために、情報モデル１０２は、システムを設計するために、管理及び運用データをどのように活用するかを叙述する。ランタイム管理のために、情報モデル１０２は、データモデル１０４で表し、データモデル１０４はその客体と属性及び関係情報を測定されたデータで表現する。
【００３０】
情報モデル１０２は、技術、ベンダー及び装置に中立的な形態で知識を定義する。概念的に、このモデルの目的は、管理される要素の特徴や行為を定義し、いかにこのような要素が与えられた環境内で互いに異なる要素と関連付けられるかを表す。データモデル１０４は、この上位レベルの知識を与えられたアプリケーション（ａｐｐｌｉｃａｔｉｏｎ）に特殊化された形態に変更する。各データモデルエンティティは、１つ以上の装置１０６を支援するが、これは与えられた装置の製造会社が多様なバージョンの管理データを有する多くの他の装置を生産するためである。装置変換器１０８は、ベンダーや装置に従属的なデータを認識するために、構造やパターン一致の組み合わせを用いる。そして、このようなデータを後続する作業のために正規化された形態に変更する。正規化された形態が用いられるプラットホームに独立するようにするとき、好む方法は、正規化された形態のために、ＸＭＬ（ｅｘｔｅｎｓｉｂｌｅ ｍａｒｋｕｐ ｌａｎｇｕａｇｅ）を用いることである。これは２つの段階からなる。
【００３１】
最初の段階では、情報モデル１０２をモニタリング（ｍｏｎｉｔｏｒｉｎｇ）される装置１０６で生成された管理及び運用データを表現する１つ以上のデータモデル１０４で表す。生成された各データモデル１０４は、属性（ａｔｔｒｉｂｕｔｅｓ）と関係（ｒｅｌａｔｉｏｎｓｈｉｐｓ）を有する客体の集合を含む。客体の属性は、その客体の固有の特性を表し、各管理される客体のための属性と値（ａｔｔｒｉｂｕｔｅ-ｖａｌｕｅ）の対を用いて定義される。例えば、装置インターフェースは、属性を有するクラス（ｃｌａｓｓ）で表現されることができ、センサデータは、この各属性に対する値を含むことができる。互いに異なる客体間の関係は、モニタリングされるエンティティ間の依存度と連関性を表す。
【００３２】
２番目の段階では、各データ値を適当な属性とマッチング（ｍａｔｃｈｉｎｇ）できるように与えられたデータをパーシング（ｐａｒｓｉｎｇ）する。各データモデル１０４は、事実上、ＤＥＮ-ｎｇ客体指向情報モデルを若干拡張したものであるので、データモデル１０４の間で類似する概念を再使用して装置の該当部分を効率的に具現するために、ソフトウェアパターンを利用できる。従って、ソフトウェアパターンを用いて与えられたコンピュータシステムの機能が要求するデータモデルに拡張できる。
【００３３】
「特性（ｃａｐａｂｉｌｉｔｙ）」の概念は、特定の装置における機能を定義する柔軟なテンプルリートとして使用され得る。これは、交渉（ｎｅｇｏｔｉａｔｉｏｎ）のような特徴の調整（ｏｒｃｈｅｓｔｒａｔｉｏｎ）を可能とする。例えば、各装置１０６は、暗号化の多様な強みのような特定の機能を行うための多様なオプションを有する。特性は、システムが装置の核心的な機能を速やかに探知するようにして、現在状況情報の要求を支援できるか否かに関する迅速な選択を容易にする。
【００３４】
装置変換器１０８の結果物は、客体生成ロジックモジュール（ｏｂｊｅｃｔ ｃｏｎｓｔｒｕｃｔｉｏｎ ｌｏｇｉｃ ｍｏｄｕｌｅ）１１０に送られる。客体生成ロジックモジュール１１０は、各装置変換器１０８により生成されたそれぞれのＸＭＬデータを受信して特定の状況に対して管理されるシステムの特性と動作を描写する１つの凝集力のある状況情報モデルに結合する。そのために、客体生成ロジックモジュール１１０は、情報モデル１０２と１つ以上の適切なデータモデル１０４の組み合わせを用いて、他のセンサデータが状況情報にいかに関連付けられているかを決定する。
【００３５】
図３は、ＤＥＮ-ｎｇモデルの簡単な概念的構造を示すものである。図３を参照すれば、Ｃｏｎｔｅｘｔ客体モデルは、完全な状況情報をモデリングし、全体状況情報の独特の側面を示すＣｏｎｔｅｘｔＤａｔａ客体からなることができる。
【００３６】
ＣｏｎｔｅｘｔとＣｏｎｔｅｘｔＤａｔａ客体は、知能的なコンテナ（ｃｏｎｔａｉｎｅｒ）で具現され、それらの情報を表現するコンテンツ（ｃｏｎｔｅｎｔ）だけでなく、メタデータも含む。コンポジットパターン（Ｃｏｍｐｏｓｉｔｅ ｐａｔｔｅｒｎ）がＣｏｎｔｅｘｔとＣｏｎｔｅｘｔＤａｔａ客体の階層を一貫した方法で作るために用いられる。この方法では、ＣｏｎｔｅｘｔＡｔｏｍｉｃ（又はＣｏｎｔｅｘｔＤａｔａＡｔｏｍｉｃ）客体が、それが１つの独立した客体でモデリングされ得るとき、Ｃｏｎｔｅｘｔ（又はＣｏｎｔｅｘｔの様相）を表す。対照的に、ＣｏｎｔｅｘｔＣｏｍｐｏｓｉｔｅ（又はＣｏｎｔｅｘｔＤａｔａＣｏｍｐｏｓｉｔｅ）客体は、別途に管理され得る多数の区別されるＣｏｎｔｅｘｔ（又はＣｏｎｔｅｘｔＤａｔａ）客体からなる客体を表す。
【００３７】
例えば、２つの他のネットワーク技術間でのハンドオーバ（ｈａｎｄ ｏｖｅｒ）を伴う電話通話をモデリングするとき、特定のネットワーク技術に従属的なＣｏｎｔｅｘｔＤａｔａ客体の集合からなる２つの互いに異なる状況が現れる。これは、２つの技術が根本的に異なるため、電話通話が更によく管理されるようにする。
【００３８】
センサデータは、装置変換器１０８から得ることができ、装置変換器１０８は、装置従属的なデータを正規化された形態に変換する。各センサデータの正規化された形態を分析して、それが有効なＣｏｎｔｅｘｔ客体又はＣｏｎｔｅｘｔＤａｔａ客体であるかを決定する。これは、多くの方法で行われることができるが、その１つとして、データモデルをテンプレートとして用い、正規化されたデータをテンプレートに含まれたデータにマッチさせる方法がある。正規化されたデータがテンプレートに含まれたデータにマッチしなければ、正規化されたデータを廃棄し、マッチすれば、正規化されたデータを客体インスタンスとして適したデータモデルに追加させる。その後、管理されるエンティティの現在の状態を決定するために、ＣｏｎｔｅｘｔＤａｔａ客体を分析して、次のモジュールに伝達する。
【００３９】
[分析段階]
分析部２００は、ユーザに割り当てられた契約されたサービスやリソースが満足されるか否かを決定する。また、サービスやリソースを伝達する契約条件に違反するか否かを決定するために、センサデータを分析する。
【００４０】
センサデータの分析は、管理されるエンティティの現在の状態をそれの所望する状態と比較することによってなされる。仮に２つの状態が同一であれば、センサデータのモニタリングを続けるが、２つの状態が同一でなければ、１つ以上の措置が取られる必要がある。このような措置は、問題が何か決定を手助けする追加のデータをモニタリングすること、管理者に構成の変更を推薦すること、１つ以上の構成変更を実行することを含むことができる。本発明は、前記３つの措置をいずれも含んでおり、これにより、管理者に応用プログラムに応じた要求に合うように、本発明の実施形態を修正するための選択権を提供できる。
【００４１】
最初の措置は、ＦＯＣＡＬＥオートノミック構造のような多くのシステムが問題の根本的な理由を探すための仮設を作るので、重要視される。この措置は、システムが追加的な分析のために、特定のデータを持って来ることを可能にする。２番目と３番目の措置と関連して、人はシステムが自動で装置を再構成することについて信頼しない傾向があり、特に、その装置がネットワークにおいて重要な機能を行えば、管理者がソフトウェアの動作に異常がないことを直接確認するようにする。一旦、管理者がソフトウェアを信頼すれば、自動再構成を用いて運営費用（ＯＰＥＸ、ｏｐｅｒａｔｉｏｎａｌ ｅｘｐｅｎｄｉｔｕｒｅｓ）の減少をもたらし得る。
【００４２】
[個人化段階]
個人化部３００の目的は、分析部２００からの状態関連状況データを調べて、必要であれば、いかなる措置を取らなければならないかを決定することにある。
【００４３】
図４は、図１に示した個人化部３００における個人化過程のフローチャートを示すものである。
【００４４】
図４を参照すれば、まず、段階４０２で状況データを収集し、段階４０４で収集された状況データを用いてシステムの現在状況を算出する。一般に、システムは多くの政策規則を含むが、大部分の政策規則は現在状況に適用できるものではない。従って、段階４０６で現在状況を用いて現在状況に適用できる政策規則を選択する。
【００４５】
次に、段階４０８で、この特定状況に対するユーザの要求事項が樹立されれば、該当要求事項が定義されていたか、又は変更されたかをチェックする。システムが初期化されるとき、ユーザの要求事項は樹立されていないので、段階４１０に進む。段階４１０、４１２、４１４でユーザ要求事項、即ち、特定のユーザ又はユーザ集団に対する加入、プロファイル、選好度情報をそれぞれ読み出す。段階４１６で読み出されたユーザ要求事項を統合して、特定の状況に対してユーザ又はユーザ集団で要求するサービス及びリソースに対する１つの定義を形成する。この定義は、システムにより成就され、管理される目標として機能する。即ち、状況が変わらない限り、システムはユーザ要求事項に明示されたサービス及びリソースを提供しようと努力するはずである。
【００４６】
その後、段階４１８で、センサデータが収集され、正規化される。本実施形態は、ＸＭＬを用いて正規化されたデータを生成する。段階４２０で、正規化されたデータに基づいて管理されるエンティティの現在の状態を決定する。次に、段階４２２で、管理されるエンティティの決定された現在の状態とそれの所望する状態とが同一であるかをチェックする。仮に、段階４２２で、エンティティの現在の状態とそれの所望する状態とが同一であれば、段階４２４に進み、状況に変化があるかをチェックする。段階４２４で、状況に変化がなければ、ユーザ要求事項は依然として有効であり、従って、システムは管理されるエンティティの状態をモニタリングすることを続け、段階４１８に戻る。（ユーザ要求事項が変更されたら、これは状況での変化をもたらしただろう。）
反面、段階４２４で、状況に変化があれば、システムは新しい方針を提示するために段階４０２に戻る。次に、段階４０４で、新しい状況が算出され、段階４０６で、潜在的に新しい政策規則が算出される。そうすると、段階４０８で、システムはユーザ要求事項も変更されたか決定する。前述したように、段階４０８で、ユーザ要求事項が変更されたら、段階４１０に進み、新しいユーザ要求事項を決定する。しかし、段階４０８で、ユーザ要求事項が変更されなかった場合には、段階４１８に進み、新しいセンサデータを収集し正規化させる。
【００４７】
段階４２２で、仮に正規化されたデータに基づいて決定されたエンティティの現在の状態とそれの所望する状態とが同一でなければ、段階４２６で、システムは有効な状況の関数として現在の状態と所望する状態間の不一致を決定する。本実施形態は、状態マシン（Ｓｔａｔｅ ｍａｃｈｉｎｅ）上に現在の状態と所望する状態をマッピングする。これは、段階４２８で、与えられたユーザ要求事項を満足させることができる最適の状態変化が決定されるようにする。次に、段階４３０で、システムは状況の関数として問題点を直すための最適の再構成命令を定義する。定義された命令は、段階４３２で実行される。本実施形態において、これは現在の状態（次善の状態）を最適の状態に変化させる最適の状況遷移を計算することで行われる。その後、制御は段階４０２に戻る。
【００４８】
[加入管理]
図４の段階４１０で定義されるユーザ加入情報は、ユーザに提供されるサービス及びリソースを決定するのに重要な役割を果たすものであって、図５と図６を参照して、このような加入情報の管理について説明する。
【００４９】
図５は、ＤＥＮ-ｎｇ加入モデルを示す図である。図５を参照すれば、加入情報は、柔軟性と拡張性のために、コンポジットパターンを用いてモデリングされる。ＳｕｂｓｃｒｉｐｔｉｏｎＡｔｏｍｉｃは、独立型の加入を表すのに対し、ＳｕｂｓｃｒｉｐｔｉｏｎＣｏｍｐｏｓｉｔｅは、上下体系を形成しながら、総合される複数個の加入を表す。
【００５０】
図５に示すモデルは、他の役割（Ｒｏｌｅ）の形態として３つの異なるタイプの最終のユーザ（顧客（Ｃｕｓｔｏｍｅｒ）、加入者（Ｓｕｂｓｃｒｉｂｅｒ）、ユーザ（Ｕｓｅｒ））を表す。ＤＥＮ-ｎｇモデルは、エンティティが受け入れられる機能を表すためにＲｏｌｅ-ｏｂｊｅｃｔパターンを用いる。これは、より明確、且つ、拡張性のある設計のために、エンティティが行う機能のモデリングからエンティティのモデリングを分離する。
【００５１】
図５において、Ｐｅｒｓｏｎモデルは、人を人ではないエンティティ（ｎｏｎ-ｈｕｍａｎ Ｅｎｔｉｔｙ）から区別するために、人の最も基本的な特性と行為をモデリングする。ＰｅｒｓｏｎＲｏｌｅは、Ｐｅｒｓｏｎが持つ他の作業機能と行為をモデリングするために用いられる。ＣｏｎｓｕｍｅｒＲｏｌｅは、ユーザがどのように製品、リソース及びサービスを消費するかをモデリングする。ＣｏｎｓｕｍｅｒＲｏｌｅＨａｓＳｕｂｓｃｒｉｐｔｉｏｎ組み合わせは、与えられたＣｏｎｓｕｍｅｒＲｏｌｅが持つＳｕｂｓｃｒｉｐｔｉｏｎを定義する。この組み合わせの意味は、ＣｏｎｓｕｍｅｒＲｏｌｅＳｕｂｓｃｒｉｐｔｉｏｎＤｅｔａｉｌｓと関連するクラスで定義される。
【００５２】
ＣｏｎｓｕｍｅｒＲｏｌｅの３つのサブクラス（Ｓｕｂｃｌａｓｓ）は、いずれもこの組み合わせの相続を受ける。その上、サブクラスのそれぞれは、１つ以上のＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒｓとの関係を定義する。ＤＥＮ-ｎｇモデル１０６でＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒは、製品、リソース及びサービスを提供する組織により行われる役割である。従って、これらの関係は、いかに顧客、加入者及びユーザがＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒと相互作用するかを定義する。
【００５３】
図６は、加入を制御し管理するために、政策規則がどのように使用され得るかを示す。ここでは簡単な例題のみを示している。追加の関係は、図６に示す方法で応用プログラムの必要性に合うように定義され得る。
【００５４】
まず、ＣｏｎｓｕｍｅｒＲｏｌｅＳｕｂｓｃｒｉｐｔｉｏｎＤｅｔａｉｌｓと関連したクラスは、ＣｏｎｓｕｍｅｒＲｏｌｅＨａｓＳｕｂｓｃｒｉｐｔｉｏｎ組み合わせの意味を表すために用いられる。最も簡単な例題として、ＶａｌｉｄＳｕｓｂｓｃｒｉｐｔｉｏｎＰｅｒｉｏｄ ａｔｔｒｉｂｕｔｅは、このＣｏｎｓｕｍｅｒＲｏｌｅのＳｕｂｓｃｒｉｐｔｉｏｎの開始と終了する日付と時間を定義する。ＣｏｎｓｕｍｅｒＲｏｌｅのＳｕｂｓｃｒｉｐｔｉｏｎを管理するために使用される政策規則は、ＰｏｌｉｃｙＧｏｖｅｒｎｓＳｕｂｓｃｒｉｐｔｉｏｎの関連により示される。
【００５５】
他の政策規則が他のＣｏｎｓｕｍｅｒＲｏｌｅの他のＳｕｂｓｃｒｉｐｔｉｏｎを管理するのに使用されるため、政策規則をＣｏｎｓｕｍｅｒＲｏｌｅのＳｕｂｓｃｒｉｐｔｉｏｎの意味を定義する関連クラスと関連付けるとき、図６で示す方法が用いられる。このような特定ＣｏｎｓｕｍｅｒＲｏｌｅのＳｕｂｓｃｒｉｐｔｉｏｎがいかに管理されるかは、政策規則により制御される。例えば、政策規則のアクション（ａｃｔｉｏｎ）がＣｏｎｓｕｍｅｒＲｏｌｅＳｕｂｓｃｒｉｐｔｉｏｎＤｅｔａｉｌｓと関連したクラスの属性を変更させることができ、それが結果的にＳｕｂｓｃｒｉｐｔｉｏｎとＣｏｎｓｕｍｅｒＲｏｌｅ間の関係に影響を及ぼす。同様に、他の形態の政策規則は、ＳｕｂｓｃｒｉｂｅｓＴｏＤｅｔａｉｌｓと関連したクラスに含まれた属性を変更することで、ＳｕｂｓｃｒｉｂｅｒとＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒによりＳｕｂｓｃｒｉｂｅｒに提供される製品、サービス及びリソース間の関係を管理できる。
【００５６】
簡単に表現するために、図６は、たった２つの簡単な例題を示したが、追加の制御も可能である。例えば、政策規則は、正確に同一の方法で顧客とユーザの製品、リソース及びサービスを管理できる。関連クラスがＣｕｓｔｏｍｅｒＯｆＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒとＵｓｅｒＯｆＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒと関連してそれぞれ定義され、前記関連したクラスの属性と行為を制御する政策規則が定義される。政策規則は、自らメタ政策（ｍｅｔａ-Ｐｏｌｉｃｙ）を用いて調整され得る。
【００５７】
[プロファイル及び選好度管理]
次に、プロファイル及び選好度管理について図７を参照して説明する。これは、図４における段階４１２に該当する。
【００５８】
図５と図６で見られるように、プロファイルと選好度は、いずれもＰｅｒｓｏｎＲｏｌｅと関連がある。図７は、選好度を管理する簡単なモデルを示す図である。選好度は、ＰｒｅｆｅｒｅｎｃｅｓＳｅｌｅｃｔＰｒｏｆｉｌｅとＰｒｅｆｅｒｅｎｃｅｓＳｅｌｅｃｔｓｕｂｓｃｒｉｐｔｉｏｎを通じてプロファイルや加入を選択するように使用され得る。加入管理で説明したのと同じ方法がこの場合にも適用される。即ち、選好度がプロファイルと加入を選択するために、どのように用いられるかを政策規則が管理するようにするものである。これは、ＰｅｒｓｏｎＲｏｌｅにより選択された選好度が、人がどの加入をより選好するかと各加入に関連したプロファイルを順に決定することを可能にする。
【００５９】
[制約（ｃｏｎｓｔｒａｉｎｔ）管理]
制約管理は、図８を参照して説明する。
【００６０】
政策階層（ＰｏｌｉｃｙＣｏｎｔｉｎｕｕｍ）は、１つの団体のために特定の文法で書かれた政策を他の文法を用いる他の団体が使用できるように変換する手段を提供する。これは、ビジネス用語で機能に関する制約を定義し、定義された制約をユーザに提供されるサービスとリソースに対する同等な制約に変換する便利な手段を提供する。
【００６１】
図８は、ＤＥＮ-ｎｇ情報モデルの最も上位レベルを示す図である。このモデルのＲｏｏｔは、ＲｏｏｔＥｎｔｉｔｙクラスである。これは、Ｅｎｔｉｔｙ、Ｖａｌｕｅ、ＭｅｔａＤａｔａという３つのサブクラスを有している。Ｅｎｔｉｔｙクラスは、別途の存在で管理される環境に重要な客体を表す。サブクラスのうち１つは、１つ以上のビジネス機能を行い、反面、もう１つは、前記環境でエンティティの特性と行為を表すために要求される。
【００６２】
Ｖａｌｕｅクラスは、明確な関連アイデンティティ（ｉｄｅｎｔｉｔｙ）を有さず、存在するあるものの概念を具体化するために用いる客体を表す。ＭｅｔａＤａｔａクラスは、どのようにデータ要素や属性が定義されるかとそれらが物理的にどこに位置しているかを叙述する概念及び客体を表す。ＭｅｔａＤａｔａは、状況情報、品質と条件、又はデータの特性に関する叙述的な情報を含む。
【００６３】
制約は、Ｅｎｔｉｔｙの属性、Ｖａｌｕｅクラスのサブクラスのインスタンス、及びＭｅｔａＤａｔａのサブクラスとして直接的に定義され得る。制約をＥｎｔｉｔｙの属性として定義した最初の方法は、最も簡単であるが、直接的に制約を客体にエンコードして再使用性に制限をもたらす。制約をＶａｌｕｅクラスのサブクラスのインスタンスとして定義した２番目とＭｅｔａＤａｔａのサブクラスとして定義した３番目の方法は、制約が適用されるＥｎｔｉｔｙから制約を分離して制約の再使用性を増加させる。２番目の方法は、観察されたり、測定され得る特定の客体として制約を定義することに焦点を当てる。反面、３番目の方法は、制約を受けているＥｎｔｉｔｙと関連した客体として制約を記述する。ＤＥＮ-ｎｇモデルにより十分に柔軟性を提供するため、他の応用プログラム特有の行為をモデリングできる。
【００６４】
本発明は、個人化されたサービスをモデリングするのに適用される制約を表現するために、前記で言及したＤＥＮ-ｎｇモデルの特性を用いる。例えば、図６に示すＣｏｎｓｕｍｅｒＲｏｌｅＳｕｂｓｃｒｉｐｔｉｏｎＤｅｔａｉｌｓと関連したクラスは、ＣｏｎｓｕｍｅｒＲｏｌｅのＳｕｂｓｃｒｉｐｔｉｏｎに位置する制約をモデリングするのに使用され得る。即ち、図６において制約は、ＣｏｎｓｕｍｅｒＲｏｌｅＳｕｂｓｃｒｉｐｔｉｏｎＤｅｔａｉｌｓクラスに直接入るか、分離されたＶａｌｕｅサブクラスと関連付けられるか、追加のＭｅｔａＤａｔａサブクラスと関連付けられる。
【００６５】
制約をＭｅｔａＤａｔａのサブクラスとして定義した３番目の方法の例が図９に示される。図９は、制約をメタデータとしてエンコードすることを示す。
【００６６】
図９を参照すれば、ＬｏｃａｔｉｏｎＳｕｂｓｃｒｉｐｔｉｏｎＤｅｔａｉｌｓと関連したクラスは、それがこの特定のＬｏｃａｔｉｏｎＲｏｌｅと関連付けられるとき、特定のＳｕｂｓｃｒｉｐｔｉｏｎの行為を制約するために使用される。例えば、これは、保安のようなＬｏｃａｔｉｏｎＲｏｌｅの特徴が特定のＣｏｎｓｕｍｅｒＲｏｌｅに利用可能なサービスとリソースに影響を与えることを可能にする。
【００６７】
ＰｏｌｉｃｙＣｏｎｓｔｒａｉｎｓＬｏｃａｔｉｏｎＳｕｂｓｃｒｉｐｔｉｏｎＳｅｒｖｉｃｅｓは、特定のＬｏｃａｔｉｏｎＲｏｌｅで、ＣｏｎｓｕｍｅｒＲｏｌｅに伝達されたサービスとリソース上に位置する制約を決定するために使用される政策を定義する。
【００６８】
[連邦（ｆｅｄｅｒａｔｉｏｎ）管理]
連邦管理は、図１０〜図１２を参照して説明する。
【００６９】
図１０は、ＤＥＮ-ｎｇドメインモデルを示すものである。図４では明示していないが、多数の管理ドメインを連合する能力は拡張可能な実施形態において重要な部分である。コンポジットパターンを用いてドメイン（ＤｏｍａｉｎＣｏｍｐｏｓｉｔｅ）の階層だけでなく、独立型のドメイン（ＤｏｍａｉｎＡｔｏｍｉｃ）をモデリングできる。これらの２つとも状況情報を合わせるのに使用される。
【００７０】
ＭａｎａｇｅｍｅｎｔＰｏｌｉｃｙは、使用されているＰｏｌｉｃｙＲｕｌｅの実際の構造から独立した、義務や承認のような義務と関連した行為を具体化する。ＭａｎａｇｅｍｅｎｔＰｏｌｉｃｙは、システムを管理するＰｏｌｉｃｙＲｕｌｅｓのためのスーパークラス（ｓｕｐｅｒｃｌａｓｓ）である。
【００７１】
ＧｏｖｅｒｎｉｎｇＡｕｔｈｏｒｉｔｙは、管理運用の隨行の責任を取るＭａｎａｇｅｄＥｎｔｉｔｉｅｓの個別又はＭａｎａｇｅｄＥｎｔｉｔｉｅｓの集合を表す。ＧｏｖｅｒｎｉｎｇＡｕｔｈｏｒｉｔｙは、人（ｈｕｍａｎ）であるか、人ではない（ｎｏｎ-ｈｕｍａｎ）形態になり得る。
【００７２】
ＭａｎａｇｅｍｅｎｔＤｏｍａｉｎは、Ｄｏｍａｉｎに含まれたＭａｎａｇｅｄＥｎｔｉｔｉｅｓの論理集合を表す反面、ＧｏｖｅｒｎｉｎｇＡｕｔｈｏｒｉｔｙは、Ｄｏｍａｉｎの管理それ自体だけでなく、ＤｏｍａｉｎでのＭａｎａｇｅｄＥｎｔｉｔｉｅｓを管理するために適切なＭａｎａｇｅｍｅｎｔＰｏｌｉｃｉｅｓを用いる。即ち、Ｄｏｍａｉｎは、それ自ら管理されることはできない。管理行為は、ＧｏｖｅｒｎｉｎｇＡｕｔｈｏｒｉｔｙにより行われ、管理行為のためにＭａｎａｇｅｍｅｎｔＰｏｌｉｃｙインスタンスを用いる。他の形態の政策行為のためには、ＰｏｌｉｃｙＲｕｌｅＳｔｒｕｃｔｕｒｅから相続を受けた他の形態の政策規則を用いる。
【００７３】
ＧｏｖｅｒｎｉｎｇＡｕｔｈｏｒｉｔｙＦｏｒＭａｎａｇｅｍｅｎｔＤｏｍａｉｎは、このＭａｎａｇｅｍｅｎｔＤｏｍａｉｎを管理するためのＧｏｖｅｒｎｉｎｇＡｕｔｈｏｒｉｔｉｅｓを定義する。
【００７４】
ＧｏｖｅｒｎｓＭｇｍｔＤｏｍａｉｎＵｓｉｎｇＭｇｍｔＰｏｌｉｃｉｅｓ集合は、ＭａｎａｇｅｍｅｎｔＤｏｍａｉｎそれ自体だけでなく、特定のＭａｎａｇｅｍｅｎｔＤｏｍａｉｎにあるＭａｎａｇｅｄＥｎｔｉｔｉｅｓを管理するために使用されるＭａｎａｇｅｍｅｎｔＰｏｌｉｃｉｅｓを定義する。これは、関連クラスであり、ＧｏｖｅｒｎｉｎｇＡｕｔｈｏｒｉｔｙＦｏｒＭｇｍｔＤｏｍａｉｎの意味を表す。これらの２つの関係は、それらの意味を定義するために関連クラスを用いる。
【００７５】
図１０で見られるように、連邦は中心権威者により管理されるエンティティとして定義されるが、内部関心事について制限されたパワーを有する。この連邦は、管理方法の階層に従って１つの中央集中機関又は複数の分散された管理機関（Ａｕｔｈｏｒｉｔｙ）を用いることができる。
【００７６】
図１１は、Ｃｏｎｔｅｘｔを連邦化するための新たなモデルを示すものである。図１１を参照すれば、ＦｅｄｅｒａｔｅｄＣｏｎｔｅｘｔは、ＦｅｄｅｒａｔｅｄＤｏｍａｉｎのための総合状況情報を示す。ＦｅｄｅｒａｔｅｄＣｏｎｔｅｘｔは、地域的なＣｏｎｔｅｘｔデータを連邦内の各地域Ｄｏｍａｉｎから収集した後、状況情報基盤政策規則に従って状況情報をフィルタリングする。これは、ＦｅｄｅｒａｔｅｓＣｏｎｔｅｘｔＩｎｆｏのＦｅｄｅｒａｔｅｄＣｏｎｔｅｘｔＤｅｔａｉｌｓと関連したクラスを用いて具現でき、状況情報の使用を管理する規則が施行され得るようにする。同様に、ＦｅｄｅｒａｔｅｄＣｏｎｔｅｘｔＤａｔａは、連邦内の個々のＤｏｍａｉｎのための総合状況情報を表す。各ＣｏｎｔｅｘｔＤａｔａ客体が異なる状況情報を表すため、各ＣｏｎｔｅｘｔＤａｔａ客体は、互いに異なる可視性、接近性を有し、自身の使用を管理する他の規則を有する。従って、ＦｅｄｅｒａｔｅｄＣｏｎｔｅｘｔＤａｔａ客体は、地域的なＣｏｎｔｅｘｔＤａｔａ情報を連邦内の地域ドメインから収集し、その後、状況情報基盤政策規則に従って状況情報をフィルタリングする。これは、ＦｅｄｅｒａｔｅｓＣｏｎｔｅｘｔＩｎｆｏのＦｅｄｅｒａｔｅｄＣｏｎｔｅｘｔＤｅｔａｉｌｓと関連したクラスを用いて具現でき、状況情報の使用を管理する規則が施行されるようにする。これは、ＦｅｄｅｒａｔｅｓＣｏｎｔｅｘｔＩｎｆｏのＦｅｄｅｒａｔｅｄＣｏｎｔｅｘｔＤｅｔａｉｌｓと関連したクラスを用いて具現でき、状況情報の使用を管理する規則が施行され得るようにする。
【００７７】
ＦｅｄｅｒａｔｅｄＤｏｍａｉｎは、ＭａｎａｇｅｄＥｎｔｉｔｉｅｓの運用を管理するために、１つ以上の全域政策規則や０以上の地域政策規則を用いることに同意する連邦内の各Ｄｏｍａｉｎの集合で定義される。連邦は、それ自体がＭａｎａｇｅｄＥｎｔｉｔｙであり、典型的に論理上、中央集中的であるが、物理的には分散されている。しかし、ＤＥＮ-ｎｇモデルは、論理的な分散も許容する。
【００７８】
基本的に、連邦は社会的であり、政治的であり、地理的であり、相互関心がある行為を管理するために、あらゆる構成ドメインに適用されなければならない管理メカニズムを含む。これは、適切な政策規則により表される。しかし、各構成ドメインは、自律的に連邦の管理規定から逸脱して行動できる。連邦で、自律的な又は半自律的な構成ドメインを管理モデルが許容すれば、そのようなドメインの自身管理状態は、ドメインを受け入れるＦｅｄｅｒａｔｅｄＤｏｍａｉｎにより変更されることができない。
【００７９】
図１２は、状況情報の連邦を管理するために、状況情報基盤政策規則を適用する概念を示すものである。
【００８０】
図１２を参照すれば、ＭａｎａｇｅｍｅｎｔＰｏｌｉｃｙが規則の構造とは独立的な義務規則を提供するため、実際の政策規則の内容は、イベント-条件-行為（ｅｖｅｎｔ-ｃｏｎｄｉｔｉｏｎ-ａｃｔｉｏｎ）、目的（ｇｏａｌ）又は有用性（ｕｔｉｌｉｔｙ）関数基盤の政策規則で表現され得る。３つの関連クラス（ＦｅｄｅｒａｔｅｄＣｏｎｔｅｘｔＤａｔａＤｅｔａｉｌｓ、ＦｅｄｅｒａｔｅｄＣｏｎｔｅｘｔＤｅｔａｉｌｓ、ＦｅｄｅｒａｔｅｄＡｇｇｒｅｇａｔｅＣｏｎｔｅｘｔＤｅｔａｉｌｓ）は、それ自体とＭａｎａｇｅｍｅｎｔＰｏｌｉｃｙとの間で集合（ａｇｇｒｅｇａｔｉｏｎ）を有しており、これは、それぞれの関連クラスの属性と行為を管理するために用いられるＭａｎａｇｅｍｅｎｔＰｏｌｉｃｙを定義する。これは、各関連クラスが意味を表す構成要素又は集合の行為を間接的に管理する。従って、外部の応用プログラムは、状況情報が連邦化される行為を管理するために指定されたＭａｎａｇｅｍｅｎｔＰｏｌｉｃｙを用いることができる。
【００８１】
[装置構成の状況情報変化]
図１３は、ＤＥＮ-ｎｇ状況認識政策モデルを簡単に示すものである。図１３を参照すれば、ＣｏｎｔｅｘｔＳｅｌｅｃｔｓＰｏｌｉｃｉｅｓとＣｏｎｔｅｘｔＤａｔａＳｅｌｅｃｔｓＰｏｌｉｃｉｅｓは、それぞれ特定のＣｏｎｔｅｘｔ又はＣｏｎｔｅｘｔＤａｔａに使用され得る政策規則を定義する。ＰｏｌｉｃｙＲｕｌｅＳｔｒｕｃｔｕｒｅは、イベント-条件-行為規則、目的、有用性機能のような政策規則クラスの他の形態のための父母となる抽象スーパークラス（ａｂｓｔｒａｃｔ ｓｕｐｅｒｃｌａｓｓ）である。
【００８２】
ＰｏｌｉｃｙＤｅｔｅｒｍｉｎｅｓＣｏｎｔｅｘｔＤａｔａＳｔａｔｅＤｅｔａｉｌｓは、ＣｏｎｔｅｘｔＤａｔａＨａｓＳｔａｔｅ集合の意味を定義する。この集合は、与えられたＣｏｎｔｅｘｔＤａｔａと関連した特定の状態を定義する。ＰｏｌｉｃｙＤｅｔｅｒｍｉｎｅｓＣｏｎｔｅｘｔＤａｔａＳｔａｔｅ集合は、特定の状況に対する状態が決定される方法の意味を制御する政策を定義する。
【００８３】
装置に対する構成命令語は、特定の状態と関連付けられたタプル（ｔｕｐｌｅ）として見られ得る。ＤＥＮ-ｎｇモデルの属性とクラスは、装置命令語の集合だけでなく、個別の装置命令語もモデリングでき、従って、管理されるエンティティの状態を表すことができる。そして、装置に対する命令語を変更させることは、装置の状態を変更させることに対応する。
【００８４】
[状況情報データ変更の反映]
状況情報は、事実（ｆａｃｔｓ）の集合として概念化され得る。本発明では、与えられた事実の関係を関数でモデリングするが、ある与えられた時間でのこの関数の値は、現在状況に対する事実の適用可能性を表す。これは、メタデータとしてエンコードされるが、メタデータが状況情報データと関連したデータの測定値であり、状況情報データの実際のコンテンツではないためである。図１４は、この関数のグラフを例示するものである。
【００８５】
前述したように、本発明は、特性、プロファイル及び選好度のための別個の客体とモデルを定義することで、拡張性と柔軟性を提供する。また、ＤＥＮ-ｎｇ情報モデルを用いて本発明の有用性と拡張性を向上させる。
【００８６】
また、本発明は、データの多様な表現が装置、ユーザの要求及び所望のサービスを表すことができるようにして、いかなる通信装置であっても順調な管理が可能にすると共に、変化する状況要求が提供されるリソースとサービスを再構成できる形態に変換され得るようにする。
【００８７】
一方、上述した本発明の説明では、具体的な実施形態について説明したが、様々な変形が本発明の範囲から逸脱することなく、実施され得る。従って、発明の範囲は、説明された実施形態によって定めるものではなく、特許請求の範囲により定められなければならない。
【符号の説明】
【００８８】
１００…前処理部、２００…分析部、３００…個人化部。
【技術分野】
【０００１】
本発明は、ユーザとユーザのグループのための個人化されたサービスの領域に関し、特に、通信用装備のための政策基盤、状況認識、選好度及びプロファイルモデルを具現することによって、通信システムにおいて個人化サービスを提供し管理するための装置及び方法に関する。
【背景技術】
【０００２】
一般に、ルータ、ハブなどの多様な装備が混在するネットワークは、それぞれ装備が他の形態の機能とこのような機能を動作するための命令やデータを提供する方法がそれぞれ異なり、ひいては同一の会社で生産された製品であっても多様なバージョンに応じて異なる情報を有している。
【０００３】
現在の管理システムは、このような異なる装備を管理するために、あらゆる形態の装備毎にそれぞれ異なるソフトウェアを作って提供しており、これにより、類似する形態の命令であってもそれぞれ異なるソフトウェアが必要になった。
【０００４】
前記のような多様な装備の効率的な管理のためには、共通した管理情報を定義する必要があり、特に、個人化されたサービスを提供するためには、プロファイルモデル、選好度モデル、特性モデルを定義する必要がある。
【０００５】
[プロファイル（Ｐｒｏｆｉｌｅ）モデル]
まず、プロファイルモデルは、ユーザの個人情報、選好度及び個人的な要求事項及び経験情報を格納する１つのエンティティとして定義される。このような技術としては、Ｗ３Ｃにより定義されたＣｏｍｐｏｓｉｔｅ Ｃａｐａｂｉｌｉｔｉｅｓ Ｐｒｅｆｅｒｅｎｃｅｓ Ｐｒｏｆｉｌｅ（ＣＣ／ＰＰ）とＷＡＰ Ｆｏｒｕｍにより定義されたＵｓｅｒ Ａｇｅｎｔ Ｐｒｏｆｉｌｅ（ＵＡＰｒｏｆ）が挙げられる。ＵＡＰｒｏｆは、ＣＣ／ＰＰを基盤とする特殊な形態である。ＣＣ／ＰＰは、Ｒｅｓｏｕｒｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｆｒａｍｅｗｏｒｋ（ＲＤＦ）を用いて表現され、装備の特性とユーザの選好度を記述する。これらの２つの組み合わせは、プロファイルとして定義され、コンテンツが装備に十分に適応するようにガイドするために用いられる。
【０００６】
３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ（３ＧＰＰ）は、収集したユーザ関連データを標準化するＧｅｎｅｒｉｃ Ｕｓｅｒ Ｐｒｏｆｉｌｅ（ＧＵＰ）を定義した。これは、ユーザがいかなるサービスに加入されているか、いかなる権限を持っているか、ユーザの設定情報（例えば、名前、電話番号）及び選好度情報、モバイルネットワーク情報、選好するネットワーク技術及びＧＰＲＳ設定、他のサービスのプライバシー設定、端末関連データ及び料金体系と関連したデータを定義している。
【０００７】
[選好度（Ｐｒｅｆｅｒｅｎｃｅ）モデル]
次に、選好度モデルは、ユーザの選択を示すことができる値を定義したものであって、前述したＣＣ／ＰＰとＰｌａｔｆｏｒｍ ｆｏｒ Ｐｒｉｖａｃｙ Ｐｒｅｆｅｒｅｎｃｅｓ Ｐｒｏｊｅｃｔ（Ｐ３Ｐ）を含んで多くの選好度モデルが定義されている。Ｐ３Ｐは、エンティティがプライバシー政策を通じてユーザについて収集した情報の計画された使用を申告することを可能にするプロトコルである。ユーザがあるエンティティと交流することを決定するとき、ユーザは自身の政策を定義し、自分が交流するエンティティにより公開されることを許容する個人情報を明示する。そうすると、Ｐ３Ｐは政策を比較し、政策処理手順が同意されなければ、ユーザにいかなる措置を取るかを決定するようにする。
【０００８】
[特性（Ｃａｐａｂｉｌｉｔｙ）モデル]
前記で定義されたＣＣ／ＰＰに加えて、特許文献１の“Ｍｅｔｈｏｄ ｏｆ ｐｒｏｖｉｄｉｎｇ ｃｏｎｔｅｎｔ ｔｏ ａ ｔａｒｇｅｔ ｄｅｖｉｃｅ ｉｎ ａ ｎｅｔｗｏｒｋ”で特性モデルを定義している。この特許は、サーバが特定の装備に最適のコンテンツを提供する方法を決定することを可能にする方法を提示している。これは制約事項（ｃｏｎｓｔｒａｉｎｔｓ）を評価して対象となる装備が１つ以上の特性クラスに属するかを判断することによって可能になる。しかし、前記のようなプロファイルモデル、選好度モデル、特性モデルを用いてネットワークに用いられる多様な装備を効率的に管理しようとする本分野の従来技術においては、政策基盤の管理技術を通じて状況認識基盤の個人化されたサービスのための効率的な方法を提示していない。具体的に、従来技術は、次のような重要な限界を有している。即ち、ユーザの要求と業務の目的及び環境条件が変化するのを考慮して該当装備の構成を変更することが不可能であり、状況データの変化する関係を説明するために装備の構成を調整することが不可能であり、ユーザの要求に適した特定の動作を行うようにシステムの動作を組織することが不可能であり、制約事項（例えば、業務により定義された限界、サービス状況に起因する誘発）を所望のサービスと関連付けることが不可能であり、他のユーザの要求を満足させる他のドメインからサービスとリソースを連合することが不可能である。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】米国特許第７,５１６,０４５Ｂ２号明細書
【発明の概要】
【発明が解決しようとする課題】
【００１０】
そこで、本発明は上記事情に鑑みてなされたものであって、その目的は、データの多様な表現を通じて装備の特性、ユーザの要求、所望のサービスを表すことができる政策基盤、状況認識、選好度及びプロファイルモデルを具現することによって、通信システムにおいて個人化サービスを提供及び管理するための装置及び方法を提供することにある。
【００１１】
また、本発明の他の目的は、変化する状況要求を、提供されるリソースとサービスを再構成するために使用され得る形態に変換させることができる政策基盤、状況認識、選好度及びプロファイルモデルを具現することによって、通信システムにおいて個人化サービスを提供及び管理するための装置及び方法を提供することにある。
【課題を解決するための手段】
【００１２】
本発明の第１の観点による通信システムにおける個人化サービスの提供及び管理のための装置は、ベンダー（ｖｅｎｄｏｒ）及び装置に従属的なセンサデータを正規化された形態に変換して正規化されたセンサデータを生成する前処理部と、前記正規化されたセンサデータに基づいて現在管理中のエンティティの現在の状態を決定し、状態関連状況データを生成して、それにより、ユーザに割り当てられた現在のサービス及びリソースが満足されるかを決定する分析部と、前記分析部からの前記状態関連状況データを調べて要求されるサービス及びリソースと関連して前記ユーザの要求が満たされるかを決定し、満たされなければ、前記要求されるサービス及びリソースを前記ユーザに提供するためにいかなる措置を取らなければならないかを決定する個人化サーバとを含む。
【００１３】
本発明の第２の観点による通信システムにおける個人化サービスの提供及び管理のための方法は、ベンダー及び装置に従属的なセンサデータを正規化された形態に変換して正規化されたセンサデータを生成する前処理を行う段階と、前記正規化されたセンサデータを分析し、管理されるエンティティの現在の状態を決定し、状態関連状況データを生成して、それにより、ユーザに割り当てられた現在のサービス及びリソースが満足されるかを決定する段階と、前記状態関連状況データを調べて、前記ユーザにより要求される状況従属的なサービス及びリソースが提供されるように保障するために、いかなる措置を取らなければならないかを決定する段階とを含む。
【発明の効果】
【００１４】
本発明は、ＲＤＦのような特定の技術に依存しないので、いかなる具現にも適用可能であるという利点がある。
【００１５】
また、本発明によれば、特性、プロファイル及び選好度に対する別途の客体及びモデルを定義することによって、拡張性と柔軟性を提供し、ＤＥＮ-ｎｇ情報モデルを用いて有用性と拡張性を更に向上させるという効果を奏する。
【００１６】
更に、本発明は、データの多様な表現が装置、ユーザの要求及び所望のサービスを表すことができるようにして、いかなる通信装置であっても、順調な管理が可能にすると共に、変化する状況要求が提供されるリソースとサービスを再構成できる形態に変換され得るようにする。
【図面の簡単な説明】
【００１７】
【図１】発明の実施形態による個人化サービスを提供及び管理するための装置の特徴を示す概念図である。
【図２】図１に示した前処理部の詳細概念図である。
【図３】ＤＥＮ-ｎｇモデルの簡単な概念的な構造を示す図である。
【図４】図１に示した個人化部における個人化過程のフローチャートである。
【図５】ＤＥＮ-ｎｇ加入モデルを示す図である。
【図６】加入を制御し管理するために政策規則がどのように使用され得るかを示す図である。
【図７】選好度を管理する簡単なモデルを示す図である。
【図８】ＤＥＮ-ｎｇ情報モデルの最も上位レベルを示す図である。
【図９】制約をメタデータとしてエンコードすることを示す図である。
【図１０】ＤＥＮ-ｎｇドメインモデルを示す図である。
【図１１】状況（Ｃｏｎｔｅｘｔ）を連邦化するための新たなモデルを示す図である。
【図１２】状況情報の連邦を管理するために状況情報基盤政策規則を適用する概念を示す図である。
【図１３】ＤＥＮ-ｎｇ状況認識政策モデルを簡単に示す図である。
【図１４】特定状況のための関連関数の例を示す図である。
【発明を実施するための形態】
【００１８】
以下、添付する図面を参照して本発明の動作原理を詳細に説明する。下記で本発明を説明するにおいて公知となった又は構成についての具体的な説明が本発明の要旨を不要に曖昧にするおそれがあると判断される場合には、その詳細な説明を省略する。そして、後述する用語は、本発明における機能を考慮して定義された用語であって、これは、ユーザ、運用者の意図又は慣例などによって変わり得る。従って、その定義は、本明細書全般に渡る内容に基づいてなされるべきである。
【００１９】
図１は、本発明の実施形態による通信システムにおいて個人化サービスを提供し管理するための装置の特徴を示す概念的な構造図を示すものである。前記個人化サービスを提供し管理するための装置は、前処理部（ｐｒｅ-ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ）１００、分析部（ａｎａｌｙｓｉｓ ｕｎｉｔ）２００、個人化部（ｐｅｒｓｏｎａｌｉｚａｔｉｏｎ ｕｎｉｔ）３００を含む。
【００２０】
ネットワークで発生するデータは、本質的に多様な形態を有しており、これを統合することは容易ではない。その上、状況情報は、複数のドメインからの複数のデータからなる。従って、互いに異なるデータを互いに関連付けられなければ、現在のシステムが現在の状況情報を決定できなくなる。現在は、多様な形態の管理及び運用データを状況データと関連付けられるように標準化されたマッピングがないため、状況情報が変わるとき、提供されるリソースやサービスを標準化された方法で変更することは不可能である。
【００２１】
本発明では、前記のような問題点を３つの過程、即ち、前処理部１００における前処理過程、分析部２００における分析過程、個人化部３００における個人化サービス過程を通じて解決する。多様な形態の管理及び運用データを状況データと関連付ける際の複雑性により、本発明は、これらのデータの組み合わせが最終のユーザのための個人化されたサービスを提供するために、どのように使用されるかを定義する政策規則を用いる。具体的に、本発明は、状況情報が多様な形態の運用データを分析するために用いられる政策規則を選択することと、そのようなデータを用いて決定することを可能とする。
【００２２】
前処理部１００は、特定のベンダーや装置に従属的なセンサデータを正規化された（ｎｏｒｍａｌｉｚｅｄ）形態に変更する。同様に、特定のベンダーや装置に独立的な正規化された命令語を、それと同等なベンダーや装置に従属的な命令語に変更する。
【００２３】
分析部２００は、正規化されたセンサデータに基づいて現在管理されるエンティティ（Ｅｎｔｉｔｙ）の現在の状態を決定する。その後、管理される要素の現在の状態をそのエンティティの意図する状態と比較して、仮に現在の状態と意図された状態とが同一であれば、分析部２００は正規化されたセンサデータを監視し続けるよう決定を下す。しかし、前記２つの状態が同一でなければ、分析部２００は、この情報を用いて現在のユーザに割り当てられたサービスやリソースがいかなる方法であれ、脅威されているか否かを決定し、ユーザのサービスとリソースが脅威されていないことを保障するために取られなければならない勧告措置を定義する。
【００２４】
個人化部３００は、分析部２００から勧告措置、即ち、推薦命令語を受信して、提案された命令を具現したり、センサデータが割り当てられたサービスやリソースが脅威されていることを表せば、モニタリングする新しいデータを提案したり、問題を解決できる命令語を定義する。
【００２５】
以下、前処理過程、分析過程、個人化サービス過程について更に詳細に説明する。
【００２６】
[前処理過程]
まず、前処理過程について詳察すると、前処理部１００で前処理機能を行うために使用され得る方法は多数ある。そのうち、最も選好する具現は、変換過程をガイドするために、ＤＥＮ-ｎｇ（Ｄｉｒｅｃｔｏｒｙ Ｅｎａｂｌｅｄ Ｎｅｔｗｏｒｋｓ-ｎｅｘｔ ｇｅｎｅｒａｔｉｏｎ）モデルを用いることである。
【００２７】
図２は、図１に示した前処理部１００の詳細ブロックを示すものである。前処理部１００は、装置１０６、情報モデル１０２、データモデル（ｄａｔａ ｍｏｄｅｌ）１０４、装置変換器（ｄｅｖｉｃｅ ｃｏｎｖｅｒｔｅｒ）１０８、客体生成ロジックモジュール１１０を含む。
【００２８】
他のセンサから作られた原始データ（ｒａｗ ｄａｔａ）を他の形態や言語に変更できる。これは、各装置が自身の管理データを表すために、特定の言語を用いるためである。事実上、各装置（ｄｅｖｉｃｅ）１０６は、ＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）やＣＬＩ（Ｃｏｍｍａｎｄ Ｌｉｎｅ Ｉｎｔｅｒｆａｃｅ）などの異なる言語を用いて異なるデータを作ることができる。これは、装置、データモデル１０４、装置変換器１０８の数が同一になることもできるという理由となる。
【００２９】
選好する接近方法は、ソフトウェアパターンの使用を基盤として各装置１０６からの管理データだけでなく、本発明の核心概念、即ち、特性、状況情報、選好度、プロファイル、加入情報、及びユーザ情報を表すために同一の情報モデル（Ｉｎｆｏｒｍａｔｉｏｎ ｍｏｄｅｌ）１０２を用いることである。これは、装置管理データが本発明の概念と関連があるということを保証する。この接近方法において、情報モデル１０２は、分析テンプレート（ｔｅｍｐｌａｔｅ）及びランタイム（ｒｕｎｔｉｍｅ）テンプレートとして用いられる。分析テンプレートのために、情報モデル１０２は、システムを設計するために、管理及び運用データをどのように活用するかを叙述する。ランタイム管理のために、情報モデル１０２は、データモデル１０４で表し、データモデル１０４はその客体と属性及び関係情報を測定されたデータで表現する。
【００３０】
情報モデル１０２は、技術、ベンダー及び装置に中立的な形態で知識を定義する。概念的に、このモデルの目的は、管理される要素の特徴や行為を定義し、いかにこのような要素が与えられた環境内で互いに異なる要素と関連付けられるかを表す。データモデル１０４は、この上位レベルの知識を与えられたアプリケーション（ａｐｐｌｉｃａｔｉｏｎ）に特殊化された形態に変更する。各データモデルエンティティは、１つ以上の装置１０６を支援するが、これは与えられた装置の製造会社が多様なバージョンの管理データを有する多くの他の装置を生産するためである。装置変換器１０８は、ベンダーや装置に従属的なデータを認識するために、構造やパターン一致の組み合わせを用いる。そして、このようなデータを後続する作業のために正規化された形態に変更する。正規化された形態が用いられるプラットホームに独立するようにするとき、好む方法は、正規化された形態のために、ＸＭＬ（ｅｘｔｅｎｓｉｂｌｅ ｍａｒｋｕｐ ｌａｎｇｕａｇｅ）を用いることである。これは２つの段階からなる。
【００３１】
最初の段階では、情報モデル１０２をモニタリング（ｍｏｎｉｔｏｒｉｎｇ）される装置１０６で生成された管理及び運用データを表現する１つ以上のデータモデル１０４で表す。生成された各データモデル１０４は、属性（ａｔｔｒｉｂｕｔｅｓ）と関係（ｒｅｌａｔｉｏｎｓｈｉｐｓ）を有する客体の集合を含む。客体の属性は、その客体の固有の特性を表し、各管理される客体のための属性と値（ａｔｔｒｉｂｕｔｅ-ｖａｌｕｅ）の対を用いて定義される。例えば、装置インターフェースは、属性を有するクラス（ｃｌａｓｓ）で表現されることができ、センサデータは、この各属性に対する値を含むことができる。互いに異なる客体間の関係は、モニタリングされるエンティティ間の依存度と連関性を表す。
【００３２】
２番目の段階では、各データ値を適当な属性とマッチング（ｍａｔｃｈｉｎｇ）できるように与えられたデータをパーシング（ｐａｒｓｉｎｇ）する。各データモデル１０４は、事実上、ＤＥＮ-ｎｇ客体指向情報モデルを若干拡張したものであるので、データモデル１０４の間で類似する概念を再使用して装置の該当部分を効率的に具現するために、ソフトウェアパターンを利用できる。従って、ソフトウェアパターンを用いて与えられたコンピュータシステムの機能が要求するデータモデルに拡張できる。
【００３３】
「特性（ｃａｐａｂｉｌｉｔｙ）」の概念は、特定の装置における機能を定義する柔軟なテンプルリートとして使用され得る。これは、交渉（ｎｅｇｏｔｉａｔｉｏｎ）のような特徴の調整（ｏｒｃｈｅｓｔｒａｔｉｏｎ）を可能とする。例えば、各装置１０６は、暗号化の多様な強みのような特定の機能を行うための多様なオプションを有する。特性は、システムが装置の核心的な機能を速やかに探知するようにして、現在状況情報の要求を支援できるか否かに関する迅速な選択を容易にする。
【００３４】
装置変換器１０８の結果物は、客体生成ロジックモジュール（ｏｂｊｅｃｔ ｃｏｎｓｔｒｕｃｔｉｏｎ ｌｏｇｉｃ ｍｏｄｕｌｅ）１１０に送られる。客体生成ロジックモジュール１１０は、各装置変換器１０８により生成されたそれぞれのＸＭＬデータを受信して特定の状況に対して管理されるシステムの特性と動作を描写する１つの凝集力のある状況情報モデルに結合する。そのために、客体生成ロジックモジュール１１０は、情報モデル１０２と１つ以上の適切なデータモデル１０４の組み合わせを用いて、他のセンサデータが状況情報にいかに関連付けられているかを決定する。
【００３５】
図３は、ＤＥＮ-ｎｇモデルの簡単な概念的構造を示すものである。図３を参照すれば、Ｃｏｎｔｅｘｔ客体モデルは、完全な状況情報をモデリングし、全体状況情報の独特の側面を示すＣｏｎｔｅｘｔＤａｔａ客体からなることができる。
【００３６】
ＣｏｎｔｅｘｔとＣｏｎｔｅｘｔＤａｔａ客体は、知能的なコンテナ（ｃｏｎｔａｉｎｅｒ）で具現され、それらの情報を表現するコンテンツ（ｃｏｎｔｅｎｔ）だけでなく、メタデータも含む。コンポジットパターン（Ｃｏｍｐｏｓｉｔｅ ｐａｔｔｅｒｎ）がＣｏｎｔｅｘｔとＣｏｎｔｅｘｔＤａｔａ客体の階層を一貫した方法で作るために用いられる。この方法では、ＣｏｎｔｅｘｔＡｔｏｍｉｃ（又はＣｏｎｔｅｘｔＤａｔａＡｔｏｍｉｃ）客体が、それが１つの独立した客体でモデリングされ得るとき、Ｃｏｎｔｅｘｔ（又はＣｏｎｔｅｘｔの様相）を表す。対照的に、ＣｏｎｔｅｘｔＣｏｍｐｏｓｉｔｅ（又はＣｏｎｔｅｘｔＤａｔａＣｏｍｐｏｓｉｔｅ）客体は、別途に管理され得る多数の区別されるＣｏｎｔｅｘｔ（又はＣｏｎｔｅｘｔＤａｔａ）客体からなる客体を表す。
【００３７】
例えば、２つの他のネットワーク技術間でのハンドオーバ（ｈａｎｄ ｏｖｅｒ）を伴う電話通話をモデリングするとき、特定のネットワーク技術に従属的なＣｏｎｔｅｘｔＤａｔａ客体の集合からなる２つの互いに異なる状況が現れる。これは、２つの技術が根本的に異なるため、電話通話が更によく管理されるようにする。
【００３８】
センサデータは、装置変換器１０８から得ることができ、装置変換器１０８は、装置従属的なデータを正規化された形態に変換する。各センサデータの正規化された形態を分析して、それが有効なＣｏｎｔｅｘｔ客体又はＣｏｎｔｅｘｔＤａｔａ客体であるかを決定する。これは、多くの方法で行われることができるが、その１つとして、データモデルをテンプレートとして用い、正規化されたデータをテンプレートに含まれたデータにマッチさせる方法がある。正規化されたデータがテンプレートに含まれたデータにマッチしなければ、正規化されたデータを廃棄し、マッチすれば、正規化されたデータを客体インスタンスとして適したデータモデルに追加させる。その後、管理されるエンティティの現在の状態を決定するために、ＣｏｎｔｅｘｔＤａｔａ客体を分析して、次のモジュールに伝達する。
【００３９】
[分析段階]
分析部２００は、ユーザに割り当てられた契約されたサービスやリソースが満足されるか否かを決定する。また、サービスやリソースを伝達する契約条件に違反するか否かを決定するために、センサデータを分析する。
【００４０】
センサデータの分析は、管理されるエンティティの現在の状態をそれの所望する状態と比較することによってなされる。仮に２つの状態が同一であれば、センサデータのモニタリングを続けるが、２つの状態が同一でなければ、１つ以上の措置が取られる必要がある。このような措置は、問題が何か決定を手助けする追加のデータをモニタリングすること、管理者に構成の変更を推薦すること、１つ以上の構成変更を実行することを含むことができる。本発明は、前記３つの措置をいずれも含んでおり、これにより、管理者に応用プログラムに応じた要求に合うように、本発明の実施形態を修正するための選択権を提供できる。
【００４１】
最初の措置は、ＦＯＣＡＬＥオートノミック構造のような多くのシステムが問題の根本的な理由を探すための仮設を作るので、重要視される。この措置は、システムが追加的な分析のために、特定のデータを持って来ることを可能にする。２番目と３番目の措置と関連して、人はシステムが自動で装置を再構成することについて信頼しない傾向があり、特に、その装置がネットワークにおいて重要な機能を行えば、管理者がソフトウェアの動作に異常がないことを直接確認するようにする。一旦、管理者がソフトウェアを信頼すれば、自動再構成を用いて運営費用（ＯＰＥＸ、ｏｐｅｒａｔｉｏｎａｌ ｅｘｐｅｎｄｉｔｕｒｅｓ）の減少をもたらし得る。
【００４２】
[個人化段階]
個人化部３００の目的は、分析部２００からの状態関連状況データを調べて、必要であれば、いかなる措置を取らなければならないかを決定することにある。
【００４３】
図４は、図１に示した個人化部３００における個人化過程のフローチャートを示すものである。
【００４４】
図４を参照すれば、まず、段階４０２で状況データを収集し、段階４０４で収集された状況データを用いてシステムの現在状況を算出する。一般に、システムは多くの政策規則を含むが、大部分の政策規則は現在状況に適用できるものではない。従って、段階４０６で現在状況を用いて現在状況に適用できる政策規則を選択する。
【００４５】
次に、段階４０８で、この特定状況に対するユーザの要求事項が樹立されれば、該当要求事項が定義されていたか、又は変更されたかをチェックする。システムが初期化されるとき、ユーザの要求事項は樹立されていないので、段階４１０に進む。段階４１０、４１２、４１４でユーザ要求事項、即ち、特定のユーザ又はユーザ集団に対する加入、プロファイル、選好度情報をそれぞれ読み出す。段階４１６で読み出されたユーザ要求事項を統合して、特定の状況に対してユーザ又はユーザ集団で要求するサービス及びリソースに対する１つの定義を形成する。この定義は、システムにより成就され、管理される目標として機能する。即ち、状況が変わらない限り、システムはユーザ要求事項に明示されたサービス及びリソースを提供しようと努力するはずである。
【００４６】
その後、段階４１８で、センサデータが収集され、正規化される。本実施形態は、ＸＭＬを用いて正規化されたデータを生成する。段階４２０で、正規化されたデータに基づいて管理されるエンティティの現在の状態を決定する。次に、段階４２２で、管理されるエンティティの決定された現在の状態とそれの所望する状態とが同一であるかをチェックする。仮に、段階４２２で、エンティティの現在の状態とそれの所望する状態とが同一であれば、段階４２４に進み、状況に変化があるかをチェックする。段階４２４で、状況に変化がなければ、ユーザ要求事項は依然として有効であり、従って、システムは管理されるエンティティの状態をモニタリングすることを続け、段階４１８に戻る。（ユーザ要求事項が変更されたら、これは状況での変化をもたらしただろう。）
反面、段階４２４で、状況に変化があれば、システムは新しい方針を提示するために段階４０２に戻る。次に、段階４０４で、新しい状況が算出され、段階４０６で、潜在的に新しい政策規則が算出される。そうすると、段階４０８で、システムはユーザ要求事項も変更されたか決定する。前述したように、段階４０８で、ユーザ要求事項が変更されたら、段階４１０に進み、新しいユーザ要求事項を決定する。しかし、段階４０８で、ユーザ要求事項が変更されなかった場合には、段階４１８に進み、新しいセンサデータを収集し正規化させる。
【００４７】
段階４２２で、仮に正規化されたデータに基づいて決定されたエンティティの現在の状態とそれの所望する状態とが同一でなければ、段階４２６で、システムは有効な状況の関数として現在の状態と所望する状態間の不一致を決定する。本実施形態は、状態マシン（Ｓｔａｔｅ ｍａｃｈｉｎｅ）上に現在の状態と所望する状態をマッピングする。これは、段階４２８で、与えられたユーザ要求事項を満足させることができる最適の状態変化が決定されるようにする。次に、段階４３０で、システムは状況の関数として問題点を直すための最適の再構成命令を定義する。定義された命令は、段階４３２で実行される。本実施形態において、これは現在の状態（次善の状態）を最適の状態に変化させる最適の状況遷移を計算することで行われる。その後、制御は段階４０２に戻る。
【００４８】
[加入管理]
図４の段階４１０で定義されるユーザ加入情報は、ユーザに提供されるサービス及びリソースを決定するのに重要な役割を果たすものであって、図５と図６を参照して、このような加入情報の管理について説明する。
【００４９】
図５は、ＤＥＮ-ｎｇ加入モデルを示す図である。図５を参照すれば、加入情報は、柔軟性と拡張性のために、コンポジットパターンを用いてモデリングされる。ＳｕｂｓｃｒｉｐｔｉｏｎＡｔｏｍｉｃは、独立型の加入を表すのに対し、ＳｕｂｓｃｒｉｐｔｉｏｎＣｏｍｐｏｓｉｔｅは、上下体系を形成しながら、総合される複数個の加入を表す。
【００５０】
図５に示すモデルは、他の役割（Ｒｏｌｅ）の形態として３つの異なるタイプの最終のユーザ（顧客（Ｃｕｓｔｏｍｅｒ）、加入者（Ｓｕｂｓｃｒｉｂｅｒ）、ユーザ（Ｕｓｅｒ））を表す。ＤＥＮ-ｎｇモデルは、エンティティが受け入れられる機能を表すためにＲｏｌｅ-ｏｂｊｅｃｔパターンを用いる。これは、より明確、且つ、拡張性のある設計のために、エンティティが行う機能のモデリングからエンティティのモデリングを分離する。
【００５１】
図５において、Ｐｅｒｓｏｎモデルは、人を人ではないエンティティ（ｎｏｎ-ｈｕｍａｎ Ｅｎｔｉｔｙ）から区別するために、人の最も基本的な特性と行為をモデリングする。ＰｅｒｓｏｎＲｏｌｅは、Ｐｅｒｓｏｎが持つ他の作業機能と行為をモデリングするために用いられる。ＣｏｎｓｕｍｅｒＲｏｌｅは、ユーザがどのように製品、リソース及びサービスを消費するかをモデリングする。ＣｏｎｓｕｍｅｒＲｏｌｅＨａｓＳｕｂｓｃｒｉｐｔｉｏｎ組み合わせは、与えられたＣｏｎｓｕｍｅｒＲｏｌｅが持つＳｕｂｓｃｒｉｐｔｉｏｎを定義する。この組み合わせの意味は、ＣｏｎｓｕｍｅｒＲｏｌｅＳｕｂｓｃｒｉｐｔｉｏｎＤｅｔａｉｌｓと関連するクラスで定義される。
【００５２】
ＣｏｎｓｕｍｅｒＲｏｌｅの３つのサブクラス（Ｓｕｂｃｌａｓｓ）は、いずれもこの組み合わせの相続を受ける。その上、サブクラスのそれぞれは、１つ以上のＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒｓとの関係を定義する。ＤＥＮ-ｎｇモデル１０６でＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒは、製品、リソース及びサービスを提供する組織により行われる役割である。従って、これらの関係は、いかに顧客、加入者及びユーザがＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒと相互作用するかを定義する。
【００５３】
図６は、加入を制御し管理するために、政策規則がどのように使用され得るかを示す。ここでは簡単な例題のみを示している。追加の関係は、図６に示す方法で応用プログラムの必要性に合うように定義され得る。
【００５４】
まず、ＣｏｎｓｕｍｅｒＲｏｌｅＳｕｂｓｃｒｉｐｔｉｏｎＤｅｔａｉｌｓと関連したクラスは、ＣｏｎｓｕｍｅｒＲｏｌｅＨａｓＳｕｂｓｃｒｉｐｔｉｏｎ組み合わせの意味を表すために用いられる。最も簡単な例題として、ＶａｌｉｄＳｕｓｂｓｃｒｉｐｔｉｏｎＰｅｒｉｏｄ ａｔｔｒｉｂｕｔｅは、このＣｏｎｓｕｍｅｒＲｏｌｅのＳｕｂｓｃｒｉｐｔｉｏｎの開始と終了する日付と時間を定義する。ＣｏｎｓｕｍｅｒＲｏｌｅのＳｕｂｓｃｒｉｐｔｉｏｎを管理するために使用される政策規則は、ＰｏｌｉｃｙＧｏｖｅｒｎｓＳｕｂｓｃｒｉｐｔｉｏｎの関連により示される。
【００５５】
他の政策規則が他のＣｏｎｓｕｍｅｒＲｏｌｅの他のＳｕｂｓｃｒｉｐｔｉｏｎを管理するのに使用されるため、政策規則をＣｏｎｓｕｍｅｒＲｏｌｅのＳｕｂｓｃｒｉｐｔｉｏｎの意味を定義する関連クラスと関連付けるとき、図６で示す方法が用いられる。このような特定ＣｏｎｓｕｍｅｒＲｏｌｅのＳｕｂｓｃｒｉｐｔｉｏｎがいかに管理されるかは、政策規則により制御される。例えば、政策規則のアクション（ａｃｔｉｏｎ）がＣｏｎｓｕｍｅｒＲｏｌｅＳｕｂｓｃｒｉｐｔｉｏｎＤｅｔａｉｌｓと関連したクラスの属性を変更させることができ、それが結果的にＳｕｂｓｃｒｉｐｔｉｏｎとＣｏｎｓｕｍｅｒＲｏｌｅ間の関係に影響を及ぼす。同様に、他の形態の政策規則は、ＳｕｂｓｃｒｉｂｅｓＴｏＤｅｔａｉｌｓと関連したクラスに含まれた属性を変更することで、ＳｕｂｓｃｒｉｂｅｒとＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒによりＳｕｂｓｃｒｉｂｅｒに提供される製品、サービス及びリソース間の関係を管理できる。
【００５６】
簡単に表現するために、図６は、たった２つの簡単な例題を示したが、追加の制御も可能である。例えば、政策規則は、正確に同一の方法で顧客とユーザの製品、リソース及びサービスを管理できる。関連クラスがＣｕｓｔｏｍｅｒＯｆＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒとＵｓｅｒＯｆＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒと関連してそれぞれ定義され、前記関連したクラスの属性と行為を制御する政策規則が定義される。政策規則は、自らメタ政策（ｍｅｔａ-Ｐｏｌｉｃｙ）を用いて調整され得る。
【００５７】
[プロファイル及び選好度管理]
次に、プロファイル及び選好度管理について図７を参照して説明する。これは、図４における段階４１２に該当する。
【００５８】
図５と図６で見られるように、プロファイルと選好度は、いずれもＰｅｒｓｏｎＲｏｌｅと関連がある。図７は、選好度を管理する簡単なモデルを示す図である。選好度は、ＰｒｅｆｅｒｅｎｃｅｓＳｅｌｅｃｔＰｒｏｆｉｌｅとＰｒｅｆｅｒｅｎｃｅｓＳｅｌｅｃｔｓｕｂｓｃｒｉｐｔｉｏｎを通じてプロファイルや加入を選択するように使用され得る。加入管理で説明したのと同じ方法がこの場合にも適用される。即ち、選好度がプロファイルと加入を選択するために、どのように用いられるかを政策規則が管理するようにするものである。これは、ＰｅｒｓｏｎＲｏｌｅにより選択された選好度が、人がどの加入をより選好するかと各加入に関連したプロファイルを順に決定することを可能にする。
【００５９】
[制約（ｃｏｎｓｔｒａｉｎｔ）管理]
制約管理は、図８を参照して説明する。
【００６０】
政策階層（ＰｏｌｉｃｙＣｏｎｔｉｎｕｕｍ）は、１つの団体のために特定の文法で書かれた政策を他の文法を用いる他の団体が使用できるように変換する手段を提供する。これは、ビジネス用語で機能に関する制約を定義し、定義された制約をユーザに提供されるサービスとリソースに対する同等な制約に変換する便利な手段を提供する。
【００６１】
図８は、ＤＥＮ-ｎｇ情報モデルの最も上位レベルを示す図である。このモデルのＲｏｏｔは、ＲｏｏｔＥｎｔｉｔｙクラスである。これは、Ｅｎｔｉｔｙ、Ｖａｌｕｅ、ＭｅｔａＤａｔａという３つのサブクラスを有している。Ｅｎｔｉｔｙクラスは、別途の存在で管理される環境に重要な客体を表す。サブクラスのうち１つは、１つ以上のビジネス機能を行い、反面、もう１つは、前記環境でエンティティの特性と行為を表すために要求される。
【００６２】
Ｖａｌｕｅクラスは、明確な関連アイデンティティ（ｉｄｅｎｔｉｔｙ）を有さず、存在するあるものの概念を具体化するために用いる客体を表す。ＭｅｔａＤａｔａクラスは、どのようにデータ要素や属性が定義されるかとそれらが物理的にどこに位置しているかを叙述する概念及び客体を表す。ＭｅｔａＤａｔａは、状況情報、品質と条件、又はデータの特性に関する叙述的な情報を含む。
【００６３】
制約は、Ｅｎｔｉｔｙの属性、Ｖａｌｕｅクラスのサブクラスのインスタンス、及びＭｅｔａＤａｔａのサブクラスとして直接的に定義され得る。制約をＥｎｔｉｔｙの属性として定義した最初の方法は、最も簡単であるが、直接的に制約を客体にエンコードして再使用性に制限をもたらす。制約をＶａｌｕｅクラスのサブクラスのインスタンスとして定義した２番目とＭｅｔａＤａｔａのサブクラスとして定義した３番目の方法は、制約が適用されるＥｎｔｉｔｙから制約を分離して制約の再使用性を増加させる。２番目の方法は、観察されたり、測定され得る特定の客体として制約を定義することに焦点を当てる。反面、３番目の方法は、制約を受けているＥｎｔｉｔｙと関連した客体として制約を記述する。ＤＥＮ-ｎｇモデルにより十分に柔軟性を提供するため、他の応用プログラム特有の行為をモデリングできる。
【００６４】
本発明は、個人化されたサービスをモデリングするのに適用される制約を表現するために、前記で言及したＤＥＮ-ｎｇモデルの特性を用いる。例えば、図６に示すＣｏｎｓｕｍｅｒＲｏｌｅＳｕｂｓｃｒｉｐｔｉｏｎＤｅｔａｉｌｓと関連したクラスは、ＣｏｎｓｕｍｅｒＲｏｌｅのＳｕｂｓｃｒｉｐｔｉｏｎに位置する制約をモデリングするのに使用され得る。即ち、図６において制約は、ＣｏｎｓｕｍｅｒＲｏｌｅＳｕｂｓｃｒｉｐｔｉｏｎＤｅｔａｉｌｓクラスに直接入るか、分離されたＶａｌｕｅサブクラスと関連付けられるか、追加のＭｅｔａＤａｔａサブクラスと関連付けられる。
【００６５】
制約をＭｅｔａＤａｔａのサブクラスとして定義した３番目の方法の例が図９に示される。図９は、制約をメタデータとしてエンコードすることを示す。
【００６６】
図９を参照すれば、ＬｏｃａｔｉｏｎＳｕｂｓｃｒｉｐｔｉｏｎＤｅｔａｉｌｓと関連したクラスは、それがこの特定のＬｏｃａｔｉｏｎＲｏｌｅと関連付けられるとき、特定のＳｕｂｓｃｒｉｐｔｉｏｎの行為を制約するために使用される。例えば、これは、保安のようなＬｏｃａｔｉｏｎＲｏｌｅの特徴が特定のＣｏｎｓｕｍｅｒＲｏｌｅに利用可能なサービスとリソースに影響を与えることを可能にする。
【００６７】
ＰｏｌｉｃｙＣｏｎｓｔｒａｉｎｓＬｏｃａｔｉｏｎＳｕｂｓｃｒｉｐｔｉｏｎＳｅｒｖｉｃｅｓは、特定のＬｏｃａｔｉｏｎＲｏｌｅで、ＣｏｎｓｕｍｅｒＲｏｌｅに伝達されたサービスとリソース上に位置する制約を決定するために使用される政策を定義する。
【００６８】
[連邦（ｆｅｄｅｒａｔｉｏｎ）管理]
連邦管理は、図１０〜図１２を参照して説明する。
【００６９】
図１０は、ＤＥＮ-ｎｇドメインモデルを示すものである。図４では明示していないが、多数の管理ドメインを連合する能力は拡張可能な実施形態において重要な部分である。コンポジットパターンを用いてドメイン（ＤｏｍａｉｎＣｏｍｐｏｓｉｔｅ）の階層だけでなく、独立型のドメイン（ＤｏｍａｉｎＡｔｏｍｉｃ）をモデリングできる。これらの２つとも状況情報を合わせるのに使用される。
【００７０】
ＭａｎａｇｅｍｅｎｔＰｏｌｉｃｙは、使用されているＰｏｌｉｃｙＲｕｌｅの実際の構造から独立した、義務や承認のような義務と関連した行為を具体化する。ＭａｎａｇｅｍｅｎｔＰｏｌｉｃｙは、システムを管理するＰｏｌｉｃｙＲｕｌｅｓのためのスーパークラス（ｓｕｐｅｒｃｌａｓｓ）である。
【００７１】
ＧｏｖｅｒｎｉｎｇＡｕｔｈｏｒｉｔｙは、管理運用の隨行の責任を取るＭａｎａｇｅｄＥｎｔｉｔｉｅｓの個別又はＭａｎａｇｅｄＥｎｔｉｔｉｅｓの集合を表す。ＧｏｖｅｒｎｉｎｇＡｕｔｈｏｒｉｔｙは、人（ｈｕｍａｎ）であるか、人ではない（ｎｏｎ-ｈｕｍａｎ）形態になり得る。
【００７２】
ＭａｎａｇｅｍｅｎｔＤｏｍａｉｎは、Ｄｏｍａｉｎに含まれたＭａｎａｇｅｄＥｎｔｉｔｉｅｓの論理集合を表す反面、ＧｏｖｅｒｎｉｎｇＡｕｔｈｏｒｉｔｙは、Ｄｏｍａｉｎの管理それ自体だけでなく、ＤｏｍａｉｎでのＭａｎａｇｅｄＥｎｔｉｔｉｅｓを管理するために適切なＭａｎａｇｅｍｅｎｔＰｏｌｉｃｉｅｓを用いる。即ち、Ｄｏｍａｉｎは、それ自ら管理されることはできない。管理行為は、ＧｏｖｅｒｎｉｎｇＡｕｔｈｏｒｉｔｙにより行われ、管理行為のためにＭａｎａｇｅｍｅｎｔＰｏｌｉｃｙインスタンスを用いる。他の形態の政策行為のためには、ＰｏｌｉｃｙＲｕｌｅＳｔｒｕｃｔｕｒｅから相続を受けた他の形態の政策規則を用いる。
【００７３】
ＧｏｖｅｒｎｉｎｇＡｕｔｈｏｒｉｔｙＦｏｒＭａｎａｇｅｍｅｎｔＤｏｍａｉｎは、このＭａｎａｇｅｍｅｎｔＤｏｍａｉｎを管理するためのＧｏｖｅｒｎｉｎｇＡｕｔｈｏｒｉｔｉｅｓを定義する。
【００７４】
ＧｏｖｅｒｎｓＭｇｍｔＤｏｍａｉｎＵｓｉｎｇＭｇｍｔＰｏｌｉｃｉｅｓ集合は、ＭａｎａｇｅｍｅｎｔＤｏｍａｉｎそれ自体だけでなく、特定のＭａｎａｇｅｍｅｎｔＤｏｍａｉｎにあるＭａｎａｇｅｄＥｎｔｉｔｉｅｓを管理するために使用されるＭａｎａｇｅｍｅｎｔＰｏｌｉｃｉｅｓを定義する。これは、関連クラスであり、ＧｏｖｅｒｎｉｎｇＡｕｔｈｏｒｉｔｙＦｏｒＭｇｍｔＤｏｍａｉｎの意味を表す。これらの２つの関係は、それらの意味を定義するために関連クラスを用いる。
【００７５】
図１０で見られるように、連邦は中心権威者により管理されるエンティティとして定義されるが、内部関心事について制限されたパワーを有する。この連邦は、管理方法の階層に従って１つの中央集中機関又は複数の分散された管理機関（Ａｕｔｈｏｒｉｔｙ）を用いることができる。
【００７６】
図１１は、Ｃｏｎｔｅｘｔを連邦化するための新たなモデルを示すものである。図１１を参照すれば、ＦｅｄｅｒａｔｅｄＣｏｎｔｅｘｔは、ＦｅｄｅｒａｔｅｄＤｏｍａｉｎのための総合状況情報を示す。ＦｅｄｅｒａｔｅｄＣｏｎｔｅｘｔは、地域的なＣｏｎｔｅｘｔデータを連邦内の各地域Ｄｏｍａｉｎから収集した後、状況情報基盤政策規則に従って状況情報をフィルタリングする。これは、ＦｅｄｅｒａｔｅｓＣｏｎｔｅｘｔＩｎｆｏのＦｅｄｅｒａｔｅｄＣｏｎｔｅｘｔＤｅｔａｉｌｓと関連したクラスを用いて具現でき、状況情報の使用を管理する規則が施行され得るようにする。同様に、ＦｅｄｅｒａｔｅｄＣｏｎｔｅｘｔＤａｔａは、連邦内の個々のＤｏｍａｉｎのための総合状況情報を表す。各ＣｏｎｔｅｘｔＤａｔａ客体が異なる状況情報を表すため、各ＣｏｎｔｅｘｔＤａｔａ客体は、互いに異なる可視性、接近性を有し、自身の使用を管理する他の規則を有する。従って、ＦｅｄｅｒａｔｅｄＣｏｎｔｅｘｔＤａｔａ客体は、地域的なＣｏｎｔｅｘｔＤａｔａ情報を連邦内の地域ドメインから収集し、その後、状況情報基盤政策規則に従って状況情報をフィルタリングする。これは、ＦｅｄｅｒａｔｅｓＣｏｎｔｅｘｔＩｎｆｏのＦｅｄｅｒａｔｅｄＣｏｎｔｅｘｔＤｅｔａｉｌｓと関連したクラスを用いて具現でき、状況情報の使用を管理する規則が施行されるようにする。これは、ＦｅｄｅｒａｔｅｓＣｏｎｔｅｘｔＩｎｆｏのＦｅｄｅｒａｔｅｄＣｏｎｔｅｘｔＤｅｔａｉｌｓと関連したクラスを用いて具現でき、状況情報の使用を管理する規則が施行され得るようにする。
【００７７】
ＦｅｄｅｒａｔｅｄＤｏｍａｉｎは、ＭａｎａｇｅｄＥｎｔｉｔｉｅｓの運用を管理するために、１つ以上の全域政策規則や０以上の地域政策規則を用いることに同意する連邦内の各Ｄｏｍａｉｎの集合で定義される。連邦は、それ自体がＭａｎａｇｅｄＥｎｔｉｔｙであり、典型的に論理上、中央集中的であるが、物理的には分散されている。しかし、ＤＥＮ-ｎｇモデルは、論理的な分散も許容する。
【００７８】
基本的に、連邦は社会的であり、政治的であり、地理的であり、相互関心がある行為を管理するために、あらゆる構成ドメインに適用されなければならない管理メカニズムを含む。これは、適切な政策規則により表される。しかし、各構成ドメインは、自律的に連邦の管理規定から逸脱して行動できる。連邦で、自律的な又は半自律的な構成ドメインを管理モデルが許容すれば、そのようなドメインの自身管理状態は、ドメインを受け入れるＦｅｄｅｒａｔｅｄＤｏｍａｉｎにより変更されることができない。
【００７９】
図１２は、状況情報の連邦を管理するために、状況情報基盤政策規則を適用する概念を示すものである。
【００８０】
図１２を参照すれば、ＭａｎａｇｅｍｅｎｔＰｏｌｉｃｙが規則の構造とは独立的な義務規則を提供するため、実際の政策規則の内容は、イベント-条件-行為（ｅｖｅｎｔ-ｃｏｎｄｉｔｉｏｎ-ａｃｔｉｏｎ）、目的（ｇｏａｌ）又は有用性（ｕｔｉｌｉｔｙ）関数基盤の政策規則で表現され得る。３つの関連クラス（ＦｅｄｅｒａｔｅｄＣｏｎｔｅｘｔＤａｔａＤｅｔａｉｌｓ、ＦｅｄｅｒａｔｅｄＣｏｎｔｅｘｔＤｅｔａｉｌｓ、ＦｅｄｅｒａｔｅｄＡｇｇｒｅｇａｔｅＣｏｎｔｅｘｔＤｅｔａｉｌｓ）は、それ自体とＭａｎａｇｅｍｅｎｔＰｏｌｉｃｙとの間で集合（ａｇｇｒｅｇａｔｉｏｎ）を有しており、これは、それぞれの関連クラスの属性と行為を管理するために用いられるＭａｎａｇｅｍｅｎｔＰｏｌｉｃｙを定義する。これは、各関連クラスが意味を表す構成要素又は集合の行為を間接的に管理する。従って、外部の応用プログラムは、状況情報が連邦化される行為を管理するために指定されたＭａｎａｇｅｍｅｎｔＰｏｌｉｃｙを用いることができる。
【００８１】
[装置構成の状況情報変化]
図１３は、ＤＥＮ-ｎｇ状況認識政策モデルを簡単に示すものである。図１３を参照すれば、ＣｏｎｔｅｘｔＳｅｌｅｃｔｓＰｏｌｉｃｉｅｓとＣｏｎｔｅｘｔＤａｔａＳｅｌｅｃｔｓＰｏｌｉｃｉｅｓは、それぞれ特定のＣｏｎｔｅｘｔ又はＣｏｎｔｅｘｔＤａｔａに使用され得る政策規則を定義する。ＰｏｌｉｃｙＲｕｌｅＳｔｒｕｃｔｕｒｅは、イベント-条件-行為規則、目的、有用性機能のような政策規則クラスの他の形態のための父母となる抽象スーパークラス（ａｂｓｔｒａｃｔ ｓｕｐｅｒｃｌａｓｓ）である。
【００８２】
ＰｏｌｉｃｙＤｅｔｅｒｍｉｎｅｓＣｏｎｔｅｘｔＤａｔａＳｔａｔｅＤｅｔａｉｌｓは、ＣｏｎｔｅｘｔＤａｔａＨａｓＳｔａｔｅ集合の意味を定義する。この集合は、与えられたＣｏｎｔｅｘｔＤａｔａと関連した特定の状態を定義する。ＰｏｌｉｃｙＤｅｔｅｒｍｉｎｅｓＣｏｎｔｅｘｔＤａｔａＳｔａｔｅ集合は、特定の状況に対する状態が決定される方法の意味を制御する政策を定義する。
【００８３】
装置に対する構成命令語は、特定の状態と関連付けられたタプル（ｔｕｐｌｅ）として見られ得る。ＤＥＮ-ｎｇモデルの属性とクラスは、装置命令語の集合だけでなく、個別の装置命令語もモデリングでき、従って、管理されるエンティティの状態を表すことができる。そして、装置に対する命令語を変更させることは、装置の状態を変更させることに対応する。
【００８４】
[状況情報データ変更の反映]
状況情報は、事実（ｆａｃｔｓ）の集合として概念化され得る。本発明では、与えられた事実の関係を関数でモデリングするが、ある与えられた時間でのこの関数の値は、現在状況に対する事実の適用可能性を表す。これは、メタデータとしてエンコードされるが、メタデータが状況情報データと関連したデータの測定値であり、状況情報データの実際のコンテンツではないためである。図１４は、この関数のグラフを例示するものである。
【００８５】
前述したように、本発明は、特性、プロファイル及び選好度のための別個の客体とモデルを定義することで、拡張性と柔軟性を提供する。また、ＤＥＮ-ｎｇ情報モデルを用いて本発明の有用性と拡張性を向上させる。
【００８６】
また、本発明は、データの多様な表現が装置、ユーザの要求及び所望のサービスを表すことができるようにして、いかなる通信装置であっても順調な管理が可能にすると共に、変化する状況要求が提供されるリソースとサービスを再構成できる形態に変換され得るようにする。
【００８７】
一方、上述した本発明の説明では、具体的な実施形態について説明したが、様々な変形が本発明の範囲から逸脱することなく、実施され得る。従って、発明の範囲は、説明された実施形態によって定めるものではなく、特許請求の範囲により定められなければならない。
【符号の説明】
【００８８】
１００…前処理部、２００…分析部、３００…個人化部。
【特許請求の範囲】
【請求項１】
ベンダー及び装置に従属的なセンサデータを正規化された形態に変換して正規化されたセンサデータを生成する前処理部と、
前記正規化されたセンサデータに基づいて現在管理中のエンティティの現在の状態を決定し、状態関連状況データを生成して、それにより、ユーザに割り当てられた現在のサービス及びリソースが満足されるかを決定する分析部と、
前記分析部からの前記状態関連状況データを調べて、要求されるサービス及びリソースと関連して前記ユーザの要求が満たされるかを決定し、満たされなければ、前記要求されるサービス及びリソースを前記ユーザに提供するためにいかなる措置を取らなければならないかを決定する個人化サーバと
を含む通信システムにおける個人化サービスの提供及び管理のための装置。
【請求項２】
前記前処理部は、
多数の通信用装置と、
上位レベル（ｈｉｇｈ-ｌｅｖｅｌ）の知識を技術、ベンダー及び装置に中立的な形態で定義する情報モデルと、
前記上位レベルの知識を前記通信用装置に従属的な形態に変換させるデータモデルと、
前記ベンダー及び装置に従属的なデータを識別して正規化された形態に変換させて、正規化されたセンサデータ、即ち、プラットホーム、技術及びベンダーに独立的なデータを生成する装置変換器と、
前記装置変換器により生成された前記正規化されたセンサデータを受信して１つの結合モデルで組み合わせる客体生成ロジックモジュールと
を含むことを特徴とする請求項１に記載の通信システムにおける個人化サービスの提供及び管理のための装置。
【請求項３】
前記前処理部は、
前記前処理部における変換過程をガイドするために、情報又はデータモデルを用いることを特徴とする請求項１に記載の通信システムにおける個人化サービスの提供及び管理のための装置。
【請求項４】
前記分析部は、
前記正規化されたセンサデータを分析して、前記サービスとリソースを提供することに対する契約条件が特定の状況に対して違反する危険にさらされているかを決定することを更に含むことを特徴とする請求項１に記載の通信システムにおける個人化サービスの提供及び管理のための装置。
【請求項５】
前記分析部は、
前記システムにより把握されたり、類推された現在の状況情報に応じて選択された政策規則を用いて分析することを特徴とする請求項４に記載の通信システムにおける個人化サービスの提供及び管理のための装置。
【請求項６】
前記分析部は、
前記管理されるエンティティの前記現在の状態と所望の状態とを比較することによって、前記ユーザに割り当てられた前記現在のサービスとリソースが満足されるかを決定することを特徴とする請求項４に記載の通信システムにおける個人化サービスの提供及び管理のための装置。
【請求項７】
前記分析部は、
前記比較の結果として、前記管理されるエンティティの前記現在の状態が前記所望の状態と同一であれば、前記正規化されたセンサデータをモニタリングすることを続け、
前記比較の結果として、前記管理されるエンティティの前記現在の状態が前記所望の状態と同一でなければ、適切な追加の措置を取り、ここで、前記追加の措置は、問題がどこにあるかを決定することを手助けするようにモニタリングするための追加のデータを定義することと、管理人に構成の変更を推薦することと、１つ以上の構成変更を実行することを含むことを特徴とする請求項６に記載の通信システムにおける個人化サービスの提供及び管理のための装置。
【請求項８】
前記個人化部は、
前記状態関連状況データを調べて前記状態関連状況データが状況の変更を指示するかを把握し、仮に状況の変更が存在すれば、既存の政策規則が依然として変更された状況に適切であるかを分析することを特徴とする請求項１に記載の通信システムにおける個人化サービスの提供及び管理のための装置。
【請求項９】
前記個人化部は、
前記分析の結果として、前記既存の政策規則がこれ以上前記変更された状況に適切でないと判断されれば、前記変更された状況に適切な新しい政策規則を選択することを特徴とする請求項８に記載の通信システムにおける個人化サービスの提供及び管理のための装置。
【請求項１０】
前記個人化部は、
仮に状況の変更が存在しなければ、前記ユーザの前記要求が依然として満足されるかを点検することを特徴とする請求項８に記載の通信システムにおける個人化サービスの提供及び管理のための装置。
【請求項１１】
前記個人化部は、
前記ユーザの前記要求が依然として満足すれば、前記状態関連状況データをモニタリングすることを続けることを特徴とする請求項１０に記載の通信システムにおける個人化サービスの提供及び管理のための装置。
【請求項１２】
前記ユーザの前記要求が満足されなければ、前記ユーザの要求を再び算出して特定の状況に対して新しいサービス及びリソースが前記ユーザに提供されるかを決定することを特徴とする請求項１０に記載の通信システムにおける個人化サービスの提供及び管理のための装置。
【請求項１３】
ベンダー及び装置に従属的なセンサデータを正規化された形態に変換して正規化されたセンサデータを生成する前処理を行う段階と、
前記正規化されたセンサデータを分析し、管理されるエンティティの現在の状態を決定し、状態関連状況データを生成して、それにより、ユーザに割り当てられた現在のサービス及びリソースが満足されるかを決定する段階と、
前記状態関連状況データを調べて、前記ユーザにより要求される状況従属的なサービス及びリソースが提供されるように保障するために、いかなる措置を取らなければならないかを決定する段階と
を含む通信システムにおける個人化サービスの提供及び管理のための方法。
【請求項１４】
前記前処理を行う段階における変換過程をガイドするために、情報モデル又はデータモデルを用いることを特徴とする請求項１３に記載の通信システムにおける個人化サービスの提供及び管理のための方法。
【請求項１５】
前記ユーザに割り当てられた現在のサービス及びリソースが満足されるかを決定する段階で、前記サービスとリソースを提供することに対する契約条件が特定の状況に対して違反する危険にさらされているかを決定することを特徴とする請求項１３に記載の通信システムにおける個人化サービスの提供及び管理のための方法。
【請求項１６】
前記ユーザに割り当てられた前記現在のサービス及びリソースが満足されるかを決定することは、前記管理されるエンティティの前記現在の状態と所望の状態とを比較することによりなされることを特徴とする請求項１３に記載の通信システムにおける個人化サービスの提供及び管理のための方法。
【請求項１７】
前記比較の結果として、前記管理されるエンティティの前記現在の状態が前記所望の状態と同一であれば、前記正規化されたセンサデータをモニタリングすることを続け、
前記比較の結果として、前記管理されるエンティティの現在の状態が前記所望の状態と同一でなければ、適切な追加の措置を取り、ここで、前記追加の措置は、問題がどこにあるかを決定することを手助けするようにモニタリングするための追加のデータを定義することと、管理人に構成の変更を推薦することと、１つ以上の構成変更を実行することを含むことを特徴とする請求項１６に記載の通信システムにおける個人化サービスの提供及び管理のための方法。
【請求項１８】
前記状態関連状況データが状況の変更を指示するかを点検して、仮に状況の変更が存在すれば、既存の政策規則が依然として変更された状況に適切であるかを分析することを特徴とする請求項１３に記載の通信システムにおける個人化サービスの提供及び管理のための方法。
【請求項１９】
前記分析の結果として、前記既存の政策規則がこれ以上前記変更された状況に適切でないと判断されれば、前記変更された状況に適切な新しい政策規則を算出することを特徴とする請求項１８に記載の通信システムにおける個人化サービスの提供及び管理のための方法。
【請求項２０】
仮に状況の変更が存在しなければ、前記ユーザの要求が依然として満足されるかを点検して、満足すれば、前記状態関連状況データをモニタリングすることを続け、満足しなければ、前記ユーザにより要求される前記サービス及びリソースが提供されるように保障するために再構成命令を算出することを特徴とする請求項１８に記載の通信システムにおける個人化サービスの提供及び管理のための方法。
【請求項２１】
前記個人化サービスは、状況の変更に従って管理されることを特徴とする請求項１３に記載の通信システムにおける個人化サービスの提供及び管理のための方法。
【請求項２２】
前記ユーザにより要求される前記サービス及びリソースの管理を統制するために、現在の状況により政策規則を選択することを特徴とする請求項１３に記載の通信システムにおける個人化サービスの提供及び管理のための方法。
【請求項２３】
前記ユーザに割り当てられる前記サービス及びリソースを決定するために、拡張可能な客体指向的な形態で定義されるプロファイル、選好度、加入情報を特定状況の関数として用いることを特徴とする請求項１３に記載の通信システムにおける個人化サービスの提供及び管理のための方法。
【請求項２４】
前記状況は、客体指向的なアトミック（Ａｔｏｍｉｃ）客体やコンポジット（Ｃｏｍｐｏｓｉｔｅ）客体で表すことができることを特徴とする請求項１３に記載の通信システムにおける個人化サービスの提供及び管理のための方法。
【請求項２５】
各状況要素は、それ自らの関連度に従って割り当てられることができ、前記状況が変化するとき、サービスとリソースの他の組み合わせが前記ユーザに割り当てられることを可能にすることを特徴とする請求項２４に記載の通信システムにおける個人化サービスの提供及び管理のための方法。
【請求項２６】
サービス及びリソースの連邦は、特定状況の関数としてユーザに割り当てられることができることを特徴とする請求項１３に記載の通信システムにおける個人化サービスの提供及び管理のための方法。
【請求項２７】
前記ユーザに提供される前記サービス及びリソースのそれぞれは、特定管理ドメインに割り当てられ、各管理ドメインは、特定の状況により決定される政策規則に従って統制されることを特徴とする請求項１３に記載の通信システムにおける個人化サービスの提供及び管理のための方法。
【請求項２８】
前記情報モデルは、分析テンプレートとランタイムテンプレートとして用いられることを特徴とする請求項１４に記載の通信システムにおける個人化サービスの提供及び管理のための方法。
【請求項２９】
前記情報モデルは、前記システムを設計し管理するために管理及び運用データを用いる方法を叙述することを特徴とする請求項２８に記載の通信システムにおける個人化サービスの提供及び管理のための方法。
【請求項３０】
前記情報モデルは、ランタイム管理のためにデータモデルで例示され、データモデルは、それの客体、属性、関係情報が測定されたデータとして表されることを特徴とする請求項２８に記載の通信システムにおける個人化サービスの提供及び管理のための方法。
【請求項３１】
分析データのランタイムデータへのマッチングは、前記情報モデルに対する前記ランタイムデータの適合性を測定することで、前記ランタイムデータが承認されることを可能にすることを特徴とする請求項３０に記載の通信システムにおける個人化サービスの提供及び管理のための方法。
【請求項３２】
分析データのランタイムデータへのマッチングは、前記情報モデルが形状化されるエンティティの特性と動きをいかに正確に表すかを測定することで、前記情報モデルが承認されることを可能にすることを特徴とする請求項３０に記載の通信システムにおける個人化サービスの提供及び管理のための方法。
【請求項１】
ベンダー及び装置に従属的なセンサデータを正規化された形態に変換して正規化されたセンサデータを生成する前処理部と、
前記正規化されたセンサデータに基づいて現在管理中のエンティティの現在の状態を決定し、状態関連状況データを生成して、それにより、ユーザに割り当てられた現在のサービス及びリソースが満足されるかを決定する分析部と、
前記分析部からの前記状態関連状況データを調べて、要求されるサービス及びリソースと関連して前記ユーザの要求が満たされるかを決定し、満たされなければ、前記要求されるサービス及びリソースを前記ユーザに提供するためにいかなる措置を取らなければならないかを決定する個人化サーバと
を含む通信システムにおける個人化サービスの提供及び管理のための装置。
【請求項２】
前記前処理部は、
多数の通信用装置と、
上位レベル（ｈｉｇｈ-ｌｅｖｅｌ）の知識を技術、ベンダー及び装置に中立的な形態で定義する情報モデルと、
前記上位レベルの知識を前記通信用装置に従属的な形態に変換させるデータモデルと、
前記ベンダー及び装置に従属的なデータを識別して正規化された形態に変換させて、正規化されたセンサデータ、即ち、プラットホーム、技術及びベンダーに独立的なデータを生成する装置変換器と、
前記装置変換器により生成された前記正規化されたセンサデータを受信して１つの結合モデルで組み合わせる客体生成ロジックモジュールと
を含むことを特徴とする請求項１に記載の通信システムにおける個人化サービスの提供及び管理のための装置。
【請求項３】
前記前処理部は、
前記前処理部における変換過程をガイドするために、情報又はデータモデルを用いることを特徴とする請求項１に記載の通信システムにおける個人化サービスの提供及び管理のための装置。
【請求項４】
前記分析部は、
前記正規化されたセンサデータを分析して、前記サービスとリソースを提供することに対する契約条件が特定の状況に対して違反する危険にさらされているかを決定することを更に含むことを特徴とする請求項１に記載の通信システムにおける個人化サービスの提供及び管理のための装置。
【請求項５】
前記分析部は、
前記システムにより把握されたり、類推された現在の状況情報に応じて選択された政策規則を用いて分析することを特徴とする請求項４に記載の通信システムにおける個人化サービスの提供及び管理のための装置。
【請求項６】
前記分析部は、
前記管理されるエンティティの前記現在の状態と所望の状態とを比較することによって、前記ユーザに割り当てられた前記現在のサービスとリソースが満足されるかを決定することを特徴とする請求項４に記載の通信システムにおける個人化サービスの提供及び管理のための装置。
【請求項７】
前記分析部は、
前記比較の結果として、前記管理されるエンティティの前記現在の状態が前記所望の状態と同一であれば、前記正規化されたセンサデータをモニタリングすることを続け、
前記比較の結果として、前記管理されるエンティティの前記現在の状態が前記所望の状態と同一でなければ、適切な追加の措置を取り、ここで、前記追加の措置は、問題がどこにあるかを決定することを手助けするようにモニタリングするための追加のデータを定義することと、管理人に構成の変更を推薦することと、１つ以上の構成変更を実行することを含むことを特徴とする請求項６に記載の通信システムにおける個人化サービスの提供及び管理のための装置。
【請求項８】
前記個人化部は、
前記状態関連状況データを調べて前記状態関連状況データが状況の変更を指示するかを把握し、仮に状況の変更が存在すれば、既存の政策規則が依然として変更された状況に適切であるかを分析することを特徴とする請求項１に記載の通信システムにおける個人化サービスの提供及び管理のための装置。
【請求項９】
前記個人化部は、
前記分析の結果として、前記既存の政策規則がこれ以上前記変更された状況に適切でないと判断されれば、前記変更された状況に適切な新しい政策規則を選択することを特徴とする請求項８に記載の通信システムにおける個人化サービスの提供及び管理のための装置。
【請求項１０】
前記個人化部は、
仮に状況の変更が存在しなければ、前記ユーザの前記要求が依然として満足されるかを点検することを特徴とする請求項８に記載の通信システムにおける個人化サービスの提供及び管理のための装置。
【請求項１１】
前記個人化部は、
前記ユーザの前記要求が依然として満足すれば、前記状態関連状況データをモニタリングすることを続けることを特徴とする請求項１０に記載の通信システムにおける個人化サービスの提供及び管理のための装置。
【請求項１２】
前記ユーザの前記要求が満足されなければ、前記ユーザの要求を再び算出して特定の状況に対して新しいサービス及びリソースが前記ユーザに提供されるかを決定することを特徴とする請求項１０に記載の通信システムにおける個人化サービスの提供及び管理のための装置。
【請求項１３】
ベンダー及び装置に従属的なセンサデータを正規化された形態に変換して正規化されたセンサデータを生成する前処理を行う段階と、
前記正規化されたセンサデータを分析し、管理されるエンティティの現在の状態を決定し、状態関連状況データを生成して、それにより、ユーザに割り当てられた現在のサービス及びリソースが満足されるかを決定する段階と、
前記状態関連状況データを調べて、前記ユーザにより要求される状況従属的なサービス及びリソースが提供されるように保障するために、いかなる措置を取らなければならないかを決定する段階と
を含む通信システムにおける個人化サービスの提供及び管理のための方法。
【請求項１４】
前記前処理を行う段階における変換過程をガイドするために、情報モデル又はデータモデルを用いることを特徴とする請求項１３に記載の通信システムにおける個人化サービスの提供及び管理のための方法。
【請求項１５】
前記ユーザに割り当てられた現在のサービス及びリソースが満足されるかを決定する段階で、前記サービスとリソースを提供することに対する契約条件が特定の状況に対して違反する危険にさらされているかを決定することを特徴とする請求項１３に記載の通信システムにおける個人化サービスの提供及び管理のための方法。
【請求項１６】
前記ユーザに割り当てられた前記現在のサービス及びリソースが満足されるかを決定することは、前記管理されるエンティティの前記現在の状態と所望の状態とを比較することによりなされることを特徴とする請求項１３に記載の通信システムにおける個人化サービスの提供及び管理のための方法。
【請求項１７】
前記比較の結果として、前記管理されるエンティティの前記現在の状態が前記所望の状態と同一であれば、前記正規化されたセンサデータをモニタリングすることを続け、
前記比較の結果として、前記管理されるエンティティの現在の状態が前記所望の状態と同一でなければ、適切な追加の措置を取り、ここで、前記追加の措置は、問題がどこにあるかを決定することを手助けするようにモニタリングするための追加のデータを定義することと、管理人に構成の変更を推薦することと、１つ以上の構成変更を実行することを含むことを特徴とする請求項１６に記載の通信システムにおける個人化サービスの提供及び管理のための方法。
【請求項１８】
前記状態関連状況データが状況の変更を指示するかを点検して、仮に状況の変更が存在すれば、既存の政策規則が依然として変更された状況に適切であるかを分析することを特徴とする請求項１３に記載の通信システムにおける個人化サービスの提供及び管理のための方法。
【請求項１９】
前記分析の結果として、前記既存の政策規則がこれ以上前記変更された状況に適切でないと判断されれば、前記変更された状況に適切な新しい政策規則を算出することを特徴とする請求項１８に記載の通信システムにおける個人化サービスの提供及び管理のための方法。
【請求項２０】
仮に状況の変更が存在しなければ、前記ユーザの要求が依然として満足されるかを点検して、満足すれば、前記状態関連状況データをモニタリングすることを続け、満足しなければ、前記ユーザにより要求される前記サービス及びリソースが提供されるように保障するために再構成命令を算出することを特徴とする請求項１８に記載の通信システムにおける個人化サービスの提供及び管理のための方法。
【請求項２１】
前記個人化サービスは、状況の変更に従って管理されることを特徴とする請求項１３に記載の通信システムにおける個人化サービスの提供及び管理のための方法。
【請求項２２】
前記ユーザにより要求される前記サービス及びリソースの管理を統制するために、現在の状況により政策規則を選択することを特徴とする請求項１３に記載の通信システムにおける個人化サービスの提供及び管理のための方法。
【請求項２３】
前記ユーザに割り当てられる前記サービス及びリソースを決定するために、拡張可能な客体指向的な形態で定義されるプロファイル、選好度、加入情報を特定状況の関数として用いることを特徴とする請求項１３に記載の通信システムにおける個人化サービスの提供及び管理のための方法。
【請求項２４】
前記状況は、客体指向的なアトミック（Ａｔｏｍｉｃ）客体やコンポジット（Ｃｏｍｐｏｓｉｔｅ）客体で表すことができることを特徴とする請求項１３に記載の通信システムにおける個人化サービスの提供及び管理のための方法。
【請求項２５】
各状況要素は、それ自らの関連度に従って割り当てられることができ、前記状況が変化するとき、サービスとリソースの他の組み合わせが前記ユーザに割り当てられることを可能にすることを特徴とする請求項２４に記載の通信システムにおける個人化サービスの提供及び管理のための方法。
【請求項２６】
サービス及びリソースの連邦は、特定状況の関数としてユーザに割り当てられることができることを特徴とする請求項１３に記載の通信システムにおける個人化サービスの提供及び管理のための方法。
【請求項２７】
前記ユーザに提供される前記サービス及びリソースのそれぞれは、特定管理ドメインに割り当てられ、各管理ドメインは、特定の状況により決定される政策規則に従って統制されることを特徴とする請求項１３に記載の通信システムにおける個人化サービスの提供及び管理のための方法。
【請求項２８】
前記情報モデルは、分析テンプレートとランタイムテンプレートとして用いられることを特徴とする請求項１４に記載の通信システムにおける個人化サービスの提供及び管理のための方法。
【請求項２９】
前記情報モデルは、前記システムを設計し管理するために管理及び運用データを用いる方法を叙述することを特徴とする請求項２８に記載の通信システムにおける個人化サービスの提供及び管理のための方法。
【請求項３０】
前記情報モデルは、ランタイム管理のためにデータモデルで例示され、データモデルは、それの客体、属性、関係情報が測定されたデータとして表されることを特徴とする請求項２８に記載の通信システムにおける個人化サービスの提供及び管理のための方法。
【請求項３１】
分析データのランタイムデータへのマッチングは、前記情報モデルに対する前記ランタイムデータの適合性を測定することで、前記ランタイムデータが承認されることを可能にすることを特徴とする請求項３０に記載の通信システムにおける個人化サービスの提供及び管理のための方法。
【請求項３２】
分析データのランタイムデータへのマッチングは、前記情報モデルが形状化されるエンティティの特性と動きをいかに正確に表すかを測定することで、前記情報モデルが承認されることを可能にすることを特徴とする請求項３０に記載の通信システムにおける個人化サービスの提供及び管理のための方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【公開番号】特開２０１１−１２３８７２（Ｐ２０１１−１２３８７２Ａ）
【公開日】平成２３年６月２３日（２０１１．６．２３）
【国際特許分類】
【出願番号】特願２０１０−２１８８８９（Ｐ２０１０−２１８８８９）
【出願日】平成２２年９月２９日（２０１０．９．２９）
【出願人】（５０５２８２０４２）ポステック・アカデミー‐インダストリー・ファウンデーション (34)
【Ｆターム（参考）】
【公開日】平成２３年６月２３日（２０１１．６．２３）
【国際特許分類】
【出願日】平成２２年９月２９日（２０１０．９．２９）
【出願人】（５０５２８２０４２）ポステック・アカデミー‐インダストリー・ファウンデーション (34)
【Ｆターム（参考）】
[ Back to top ]