(57)【要約】【課題】管理するシステムのモデルを定義して、このモデルのコンポーネントに適用可能なポリシーを定義することからなるネットワーク電子システム内の同時セションを管理する方法を提供する。【解決手段】システムコンポーネントはエンティティ間の階層関係によってモデルのエンティティとしてモデル化される。エンティティはシステムの１つの物理オブジェクトまたは非物理オブジェクトで構成される。【選択図】図１
2005506016.tif 000002
【特許請求の範囲】
【請求項１】
管理するシステムのモデルを定義して、このモデルのコンポーネントに適用可能なポリシーを定義することからなるネットワーク電子システム内の同時セションを管理する方法であって、
システムコンポーネントは、システム内の単一の物理または非物理オブジェクトで構成されるエンティティ間の階層関係のモデルでエンティティとしてモデル化され、
ポリシーはシステム内エンティティ間の交互作用に応じて実施される
ことを特徴とする方法。
【請求項２】
エンティティは共通のポリシーが適用できる複数の物理オブジェクトまたは非物理オブジェクトで構成されることを特徴とする請求項１に記載の方法。
【請求項３】
エンティティは共通のテーマを有する集団にグループ分けされることを特徴とする請求項１または２に記載の方法。
【請求項４】
各エンティティはローカルまたは分散されたものとして定義され、ローカルエンティティの状態情報は定義済のサーバおよび関連するバックアップサーバにのみ位置し、また分散されたエンティティの状態情報はシステム内のすべてのサーバにアクセス可能であることを特徴とする請求項１ないし３のいずれか１項に記載の方法。
【請求項５】
モデルの表現は単一オブジェクトタイプに関するビューで構成されることを特徴とする請求項１ないし４のいずれか１項に記載の方法。
【請求項６】
ビューは重ならないことを特徴とする請求項５に記載の方法。
【請求項７】
ビューはサービス、ユーザまたはデータで構成されることを特徴とする請求項５または６に記載の方法。
【請求項８】
エンティティは１つ以上の子および／または１つ以上の親を有することを特徴とする請求項１ないし７のいずれか１項に記載の方法。
【請求項９】
ポリシーが複数のエンティティに適用されて、これらエンティティを参照する要求に応じて前記エンティティの組合せによりポリシーの適用が決定されることを特徴とする請求項１ないし８のいずれか１項に記載の方法。
【請求項１０】
ポリシーが複数のエンティティに適用されるとき、前記エンティティは各タイプにつき１つのエンティティで構成されることを特徴とする請求項９に記載の方法。
【請求項１１】
新しいトランザクション／要求に応じて１つのポリシー定義が動的に生成されて、要求に記述されたオブジェクトに適用され、使用されるポリシーは要求に関係するオブジェクトのクラスに基づくものであることを特徴とする請求項１ないし１０のいずれか１項に記載の方法。
【請求項１２】
オブジェクトタイプの使用による１つのポリシー定義には同一ポリシーを多数のオブジェクトに自動的に適用する手段が備わることを特徴とする請求項１１に記載の方法。
【請求項１３】
電子システムの同時セションはネットワーク電子システム内のユーザアクセスセションで構成され、かつポリシーは帯域稼働率に関しユーザのトラヒックの優先を命令するように定義されることを特徴とする請求項１ないし１２のいずれか１項に記載の方法。
【請求項１４】
複数のユーザによるシステムコンポーネントの使用法は監視されて、そのユーザまたは各ユーザが定義する権利を有するものがポリシーで定義され、ポリシーはそのユーザまたは各ユーザによるシステムコンポーネントの使用法に応じて定義されることを特徴とする請求項１ないし１３のいずれか１項に記載の方法。
【請求項１５】
請求項１ないし１４のいずれか１項に記載の方法に基づいて電子システム内の同時セションを管理するよう適合されたコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は電子システム内の同時セションを管理する方法に関する。
【背景技術】
【０００２】
電子システムは企業マーケットおよび個人マーケットの両マーケットに対してあらゆる種類のサービスを提供するのに広く使用される。通常このシステムは一括してサービスすることが多く、各顧客には異なるレベルでサービスが提供される。システムによっては、このようなシステムの個々のユーザレベルにまでカスタマイズできるサービスレベルが備わるものもある。これは一般にサービスレベル契約（ＳＬＡ）と呼ばれる。サービス提供者は通常、ポリシーに基づく管理を使用するので、音声、データあるいはビデオなどのあらゆる種類のトラヒックはそれぞれのＳＬＡで要求される帯域稼働率の条件で優先順位を受ける。したがって、このようなＳＬＡｓにはシステムアクティビティ、ポリシー管理およびこのアクティビティに基づくポリシーの実施を監視する機構が要求される。
【０００３】
監視活動と実施行為にはシステム環境内コンポーネントの必要な機能にアクセスすることが必要となる。このコンポーネントは公知の適切なインタフェースによってアクセスできるので、これは簡単な統合の問題である。しかし、ポリシーが実施できる方法でシステムの瞬間の状態をモデル化する作業は簡単ではない。
【０００４】
最近のポリシー管理システムはアクセス制御リストや待ち行列の管理ソフトウエアを使用するポリシーの実施ポイント（ルータ、スイッチなど）を制御するため、ポリシー決定のポイントサーバを使用するネットワークエレメントビューを採用する。
【０００５】
ネットワークエレメントビューを扱うこのようなシステムの１つが、通信ネットワークにおける構成管理のポリシーを実施する方法を記載したＵＳ６２４３７４７に開示される。この方法には、ネットワーク装置を表すモデルのデータベースが備わり、ネットワーク装置のパラメタ用の属性値が含まれる。この方法でネットワークグループとこれらのグループのポリシーが定義され、グループ間の矛盾が決定解消される。
【特許文献１】
ＵＳ６２４３７４７
【発明の開示】
【発明が解決しようとする課題】
【０００６】
本発明の目的はシステム、特にインフラストラクチュアが広範囲に分散するシステムの現在の状態に基づくポリシーを管理、実施する方法を提供することにある。
【課題を解決するための手段】
【０００７】
本発明によると、管理するシステムのモデルを定義して、このモデルのコンポーネントに適用可能なポリシーを定義することからなるネットワーク電子システム内の同時セションを管理する方法であって、システムコンポーネントは、システム内の単一の物理または非物理オブジェクトで構成されるエンティティ間の階層関係のモデルでエンティティとしてモデル化され、ポリシーはシステム内エンティティ間の交互作用に応じて実施される方法が提供される。
【０００８】
エンティティは共通のポリシーが適用できる複数の物理または非物理オブジェクトで構成されることが好ましい。エンティティは共通のテーマを有する集団にグループ分けされることが好ましい。各エンティティはローカルまたは分散されたものとして定義され、ローカルエンティティの状態情報は定義済のサーバおよび関連するバックアップサーバにのみ位置し、また分散されたエンティティの状態情報はシステム内のすべてのサーバにアクセス可能であることが好ましい。モデルの表現は単一オブジェクトタイプに関するビューで構成されることが好ましい。複数のユーザによるシステムコンポーネントの使用法は監視されて、そのユーザまたは各ユーザが定義する権利を有するものがポリシーで定義され、ポリシーはそのユーザまたは各ユーザによるシステムコンポーネントの使用法に応じて定義されることが好ましい。
【０００９】
ポリシー管理はいかなる定義済み概念にも依存しなく、そのためポリシーはポリシーモデル内エンティティとしてモデル化されるすべてのものに適用できるので好都合である。ネトワークエレメント手法から離れた抽象化が好都合であることが分かった。この適応性はデータモデルや、ポリシーモデルの構成に使用される方法によって備わる。さらに、システム使用法を維持し、この使用法に応じてポリシーを適用したり実施したりすることで、発明のポリシーサーバによって電子システムが誤用されにくいものとなる。
【発明を実施するための最良の形態】
【００１０】
発明の一般的な実施形態を図面を参照してさらに詳細に記載する。
図１にデータモデルの概略を示す。仮想ＩＳＰすなわちｖＩＳＰなどの同時セションの管理が必要な環境において、本発明は使用法を監視したり、エレメント、サービス、地理的領域、ユーザまたはその他の抽象概念に適用されたポリシーを実施したりするのに使用できる。
【００１１】
一般にポリシーモデルは異なった２つの部分を含むように定義できる。
１．環境モデルとして知られる、システム環境のモデル
２．環境モデルに適用できるポリシー
環境モデルを定義するプロセスの最初のステップは、したがってポリシーモデルは、システム環境内のポリシー管理の目的が何であるかを決定することである。一旦これが確立されると、実動化は展開可能となる。
【００１２】
目的の例としては「ネットワークアクセス環境で同時セションアクセスを管理すること」がある。
環境モデルの定義に必要な次のステップはシステム環境の分析である。この分析には一般的に、ハードウエアであれソフトウエアであれ、インフラストラクチュアの（エレメントへの）分解が含まれ、またシステムが編成の全事務や戦略目的にいかに適合するかの記述も含まれる。例えば製品やサービスが含まれるこのような概念はこのシステム内のポリシー管理の目的に依存するモデル内で必要となる。
【００１３】
環境モデルは簡単なデータモデルを使って定義され、システムコンポーネントは階層関係を有する環境モデルのエンティティとしてモデル化される。
エンティティは次の２つの広いクラスのうちの１つを表す。
【００１４】
１．単一の物理または非物理オブジェクト−例えばエンドユーザ
２．物理または非物理オブジェクトの集合はグループとして表される−例えば、多数のオブジェクトは、共通の集合としてポリシーを適用するため、共に「グループ化」される。
【００１５】
エンティティには子がないか、１つ以上の子がある。またエンティティには親がないか、１つ以上の親がある。
この定義によるエンティティの例としては、仮想インターネットサービスプロバイダ（ｖＩＳＰ）などのサービスがある。別の例としては、「東部海岸」および「西部海岸」の子領域を有する「ＵＳ」領域などの、多数の子領域を有する地理的領域がある。
【００１６】
一旦、環境モデルが定義されると、ポリシーは前記環境モデルに適用できるように定義する必要がある。ポリシーは与えられたシステム内の交互作用の望ましい結果の局面を管理するアドミニストレータ特定指令である。このシステムはユーザ、アプリケーション、サービスおよびインフラストラクチュア、またはエンティティとしてモデル化できるその他の定量化可能なオブジェクトに対する環境を備えている。ポリシーはこのような環境内の異なるエンティティをシステム内の交互作用に応じて各エンティティでいかに管理するかのガイドラインを備えている。
【００１７】
最も簡単な形では、ポリシーは、ある定義済の条件（イベント）が存在するか否かを約束するためいくつかのアクションを記述する１つ以上の時間に敏感なルールである。ポリシーは通常１つ以上のエンティティ（ポリシー関連）に適用される。これらエンティティの組合せはポリシーに手がかりを与え、ポリシーはこれらのエンティティを参照する要求に応じて適用される。
【００１８】
ポリシーの主要な例としては与えられたｖＩＳＰエンティティに適用されるセション制限がある。このセション制限には、例えばｖＩＳＰの同時セションの数が定義済の数を超えないように制限するものがある。
【００１９】
ルールは数学的操作を実行して一定の結果を得るための論理的で決定的な方法を与える。ルールは１つ以上の入力パラメタまたは引き数を含み、またルールが破られたことに応じて多数のイベントを発生させる。
【００２０】
ルールタイプは、ポリシーサーバによって管理されるプラグインコンポーネント、一般的にはジャワプラグインを使用して与えられる。これらルールタイプのパラメタは個々のそれぞれのルールタイプによって記述する必要がある。ルールの例としては、与えられた状態カウントが定義済の制限値に達すると、記述したイベントが生じるものがある。
【００２１】
イベントはルールによって満たされた条件の結果である。さらに、イベントは実行される１つ以上のアクションをトリガすることができる。１つ以上のイベントは単一のルールに結合される。例えば、イベントは、呼び出しに応じてｅメイルやＳＮＭＰトラップを送信するなどの多くのアクションをトリガする。
【００２２】
アクションはＳＮＭＰトラップやｅメイルの生成など定義済の処理の実行である。処理あるいはアクションタイプは、アクションプロセッサにパラメタを送るので識別が必要となる。
【００２３】
アクションの例としては、ｅメイルやＳＮＭＰトラップを定義済のメッセージで定義済のアドレスに送信することがある。
前述のとおり、ポリシーは１つ以上のエンティティに適用でき、これらのエンティティの組合せはポリシーに手がかりを与えるので、要求に応じてポリシーが適用される。ポリシー関連内では各タイプにエンティティは１つしか存在しない。
【００２４】
例えば、与えられたｖＩＳＰ，ｖＩＳＰ１が地理的領域の「東部海岸」で制限Ｘを有し、地理的領域の「西部海岸」で別の制限Ｙを有するものとすると、各組合わせに１つの、すなわち２つのポリシーが必要になる。
【００２５】
図２にシステム環境を記述するすべてのエンティティ（この例では仮想インターネットサービスプロバイダ（ｖＩＳＰ）インストラクチュアネットワーク）を示す。エンティティは共通テーマを分担する特定の集合にグループ分けされる。
【００２６】
それぞれのグループはビューとして知られる。これらのビューはモデル化されるシステムを定義する手段を備える。一般に、ビューは重ならない。各エンティティビューはいくつかの情報処理の基準となる。ビューは通常サービス、ユーザあるいはデータとすることができる。
【００２７】
各ビューはポリシーサーバ内でモデル化しなければならないエンティティの集合を表す。データモデルはエンティティの実現値が特定のエンティティタイプであることが要求される（標準のオブジェクト指向タイプの設計原理に従う）。エンティティタイプは単一のビューであるのが有効である。すなわち、ビュー「ＶＩＳＰＳ」はエンティティタイプ「Ｖｉｓｐ」に必要であり、ビュー「領域」はエンティティタイプ「領域」に必要である等等。
【００２８】
これらエンティティタイプはポリシーサーバ内でエンティティを作成するテンプレートを備える。各エンティティタイプはエンティティタイプを識別する唯一の名称などの定義が必要となる。
【００２９】
各エンティティは適切なエンティティタイプとともに、各エンティティに適用される唯一の識別で定義される。さらに、エンティティのホームサーバは主要なサーバ（ホームサーバ）が故障した場合のバックアップサーバとともに、識別する必要がある。
【００３０】
最後に、エンティティはホームサーバに対して「ローカル」または「分散」のいずれかで定義しなければならない。エンティティが「ローカル」で定義された場合は、エンティティに関連するすべてのデータはホームサーバ（および関連するバックアップサーバ）だけに位置するので、このエンティティに対する要求はホームサーバまたは（故障中は）バックアップサーバだけに限定される。これはエンティティが要求のためにポリシーモデル内をローミングする能力を必要としないようにするためであり、したがって状態情報はローカル位置でしか必要がなく、ポリシーサーバシステム全体には分散されず、他のいずれのポリシーサーバにも不必要なネットワークのトラヒックや負担が発生しない。
【００３１】
しかし、エンティティが「分散」として定義されると、それに関連するデータは、データがローカルサーバに位置していても、ポリシーサーバシステム全体を通して他のすべてのサーバがアクセスすることができる。これらのサーバで、分散で指名された特定のエンティティが直接要求する場所を知ることができる。これはエンティティがポリシーモデル全体をローミングする能力を必要とするからであり、したがって状態情報はポリシーサーバ全体を通して必要となり、ポリシーサーバ間プロトコルによって複製される。
【００３２】
図２に関する例に続いて定義が必要なエンティティは次のとおりである。
【００３３】
【表１】
2005506016.tif 000003
次のステップは、必要に応じて各ビュー内で定義されたネットワーク関連を使用する前ステップで定義されたエンティティ間の関係を定義することである。
【００３４】
図３はエンティティ間で定義された親子関連に従った「領域」の単一ビューを示す。
ネットワーク関連は２つのエンティティ間の単なる親子関係として定義される。ネットワーク関連は同一エンティティタイプのエンティティを結合する手段を備えるのに使用され、これは与えられた要求にポリシーが適用される識別手段を備える。
【００３５】
ネットワーク関連の一般的な例は「ＵＳ」エンティティと、「東部海岸」および「西部海岸」エンティティとの関係である。後者の両エンティティは「ＵＳ」エンティティの子である。
【００３６】
ネットワーク関連の根底となる目的は多数のレベルでポリシーを適用する手段を備えることである。例えば前述のようにマイアミはＭｉＰＯＰＡの親である。ＭｉＰＯＰＡは自身に適用されるポリシーを有し、マイアミも自身に適用されるポリシーを有する必要がある。ネットワーク関連を使用して、２つのポリシーはＭｉＰＯＰＡエンティティにおいてポリシーモデルを入力する要求に適用される。しかし、要求によってマイアミエンティティでポリシーモデルが入力されると、マイアミポリシーのみが適用される。したがって、子エンティティは親、祖父母などすべてのポリシーを受け継ぐことが明白となる。
【００３７】
ネットワーク関連はポリシー関連とは微妙に異なる。強調したいのは、自身に適用されるポリシーを有するエンティティだけを環境モデルにおいて定義する必要があることである。その他のエンティティでは、設計段階のモデルで明白にするが、必要ではない。例えば図４で「ユーザ」ビューは省略されている。これはユーザには直接にポリシーが適用されないという事実に基づいている。適用されるポリシーのみが、図示するようにポリシーモデルの「Ｖｉｓｐ」および「領域」ビューに保持される。実際、この例にある「サービスアクセス」を使って、ユーザ状態情報は実行時のメモリー内に動的に作成（具体化）されたオブジェクトに保持される。しかし、ポリシーを個々のユーザに適用する要求があるときは、「ユーザ」ビューを含め、したがってポリシーを適用しなければならない。
【００３８】
ポリシーのリストを定義する際の第１ステップは環境モデルを調査することであり、各ポリシーに対して、ポリシーをそれが適用される１以上のエンティティに結合することである。各ポリシーの定義には唯一のポリシー識別（ラベル）とこれらエンティティのリストが必要となる。
【００３９】
例えば前述の例を拡張して、環境モデル内でエンティティに適用されるポリシーは識別しなければならない。次に一例を示す。
【００４０】
【表２】
2005506016.tif 000004
備考１：これらのポリシーは、各ＰＯＰが利用可能なＮＡＳポートの数に基づいて物理的に制限されるので、「領域」ビュー内で適用されて使用法の報告／警告メカニズムのみを与える。したがって、これらのポリシーを使用して、制限値を超えたときはイベントおよびアクションが実行され、適切なシステムに伝わる。
【００４１】
備考２：ワイルドカードは特定されたエンティティタイプのすべてのエンティティにポリシーを適用させる構成である。星印（＊）を使用して表示される。このワイルドカードを表すエンティティは適切なビューの環境モデル内で定義する必要があることが注目される。
【００４２】
ポリシー関連を使ってポリシーモデルのビュー間が結合される。この構想はポリシーが適用される唯一の手がかりを与えるようにエンティティを関連させることにあり、したがってポリシー関連と呼ばれる。したがって、各ポリシーはエンティティの唯一の集合に基づいている。図５に環境モデル上で重なったポリシー関連の例を示す。これはポリシーモデルとして知られる。
【００４３】
要求が変更され、ユーザに適用されるポリシーが必要性になったときは、「ユーザ名」ビューを含む必要があり、したがってポリシーを適用する必要がある。
したがって、上記のモデルをユーザのユーザＺに適用されるポリシーに拡張すると、図６のポリシーモデルとなる。
【００４４】
次のステップは表２に記載のテクスチャのポリシー要求をルール、イベントおよびアクションに翻訳することである。
一般的な実施形態を続けると、接続された「サービスアクセス」ルールはここで目指す解決環境に使用される。このために下記のルール特定パラメタが必要となる。
【００４５】
１．ルール識別子（各ルール実現値のラベル）
２．定義済の制限
３．ポリシーが動作している期間
したがって、前に定義したポリシーのリストは拡張してこれらの追加のパラメタを識別する必要が生じてくる。
【００４６】
例えば表３のとおり。
【００４７】
【表３】
2005506016.tif 000005
各ルール用に、時間制限、イベントおよびアクションが選択される。
【００４８】
時間制限は期間でとらえる。期間はシステムデフォルトまたはユーザデフォルトとすることができる。時間制限はルールが動作する期間を制限するためにルールに適用される。例えば、ルールが平日の午前９時から午後５時までの間だけ動作するのが望ましく、したがってこの期間を定義する時間制限が作成されて、望ましいルールに適用される。
【００４９】
ルールの動作期間を制限する一定の期間が定義されて適切なルールに適用される。期間は曜日または日の開始時間と終了時間によって定義される。
通常、各ポリシーに少なくとも１つのイベントが定義される。しかしこれは要求ではない。というのは、イベントは制限に達した時に生成されることが要求されるものではなく、イベントは報告／警報メカニズムとして使用されるだけであるからである。
【００５０】
例えば、ポリシーＰ１は制限に達した時にトリガされるイベントを有する。このイベントの目的はＮＡＳポートの稼働率が危機的に低くなっていることをインフラストラクチュアプロバイダーに通告することである。
【００５１】
この制限に達してイベントがトリガされると、イベントはアクションを発生させる。アクションプロセッサにパラメタを通過させるので、処理あるいはアクションタイプには識別が必要になる。
【００５２】
イベントがポリシーＰ１のためにトリガされることによって、ＳＮＭＰトラップを使って制限値に達していることをアクションでＯＳＳモニタに警告するが、さらに適切な人に危険制限値に達していることを直接ｅメールで通知することもできる。
【００５３】
以下に、ポリシーモデルに基づいた適切な応答を決定するために、ポリシーサーバに対する顧客要求の処理詳細を詳しく記載する。
第１に理解すべきことはポリシーサーバ顧客要求とポリシーモデルとの関係である。
【００５４】
下表は顧客要求（ポリシーモデル例に関するもの）の一般的な例である。
【００５５】
【表４】
2005506016.tif 000006
この文献の例で使用されるこの要求とポリシーモデルとの関係を図７に示す。ポリシーモデルにおいてはＶｉｓｐのラベルは実際には「ＶＩＳＰ３．ｃｏｍ」であって、ダイヤグラムに示すような「ＶＩＳＰ３」ではない。また、ユーザ名のラベルは実際には「ユーザＺ＠ＶＩＳＰ３．ｃｏｍ」であって、ダイヤグラムに示すような「ユーザＺ」ではない。これらの省略版は明瞭にするために設けたものである。
【００５６】
このダイヤグラムから、要求の各分野はポリシーモデルの各ビューに直接関係することが明らかである。したがって、与えられた要求に対して、以下のポリシーがポリシーサーバによって適用される（時間制限によって定義されるように動作すると仮定する）。
【００５７】
【表５】
2005506016.tif 000007
（要求を開始した）顧客に対するその結果生じる回答は要求に適用されるすべてのポリシーの集合結果に依存して「受入れ」か、または「断り」メッセージとなる。すなわち、（例として与えられた）Ｐ１，Ｐ２，Ｐ４，Ｐ５およびＰ８のすべてが「受入れ」を返信してきたときのみ、ポリシーサーバは「受入れ」メッセージを顧客に応答する。その他のすべての組合せは「断り」メッセージとなる。
【００５８】
ポリシーモデルに基づき与えられた要求に適用するポリシーを決定するプロセスはポリシーチェッカーと呼ばれるコンポーネントで実施される。ポリシーモデルを多数のサーバに展開する必要がある場合は、ポリシーモデルは適切な環境インターフェース（ＲＡＤＩＵＳサーバなど）に最も深く関係する別々の部分に分割する必要がある。このような筋書きの例としては、高い実行性とスケーラビリティが要求され、地理的に広がったいくつかの場所で大きなロードが取り扱われる国際的サービスの場合がある。各場所はその地区のすべての要求を扱うサーバを有する。
【００５９】
しかし、（分散した）多数サーバの展開やローミングサービスにおいては、与えられたエンティティのポリシー情報は指定された単一のサーバに保持されるが、システムの一部を形成する他のすべてのサーバにはポリシー情報のある場所だけが知らされる。したがって、国際的サービスによって要求されるようなローミング要求は効率的かつ有効に処理できる。
【００６０】
サーバ間データ交換はすべてポリシー間サーバプロトコルを使用して実施される。ポリシーチェッカーによって、与えられた要求に適用する適切なポリシーが決定される。これが一旦決定されると、中核となるポリシーエンジンで各ポリシーのルールが実行される。これを達成するために、ポリシーエンジンには入力パラメタとして各ポリシーに関連する適切な状態情報を与える必要がある。この状態情報はシステムのすべてのサーバにあるポリシーの基底に格納される。このアロケーションはポリシー作成の間に決められる。
【００６１】
同一オブジェクトタイプである特定のオブジェクト集団に特定のポリシーを適用する必要がある場合は、デフォルトポリシーが使用される。デフォルトポリシーの単一の実現値はこの単一のオブジェクト集団に適用される。これによって、すべてのオブジェクトを明確に定義する必要はなく、ポリシーは多数のオブジェクトに適用され、それぞれのオブジェクトにポリシーが適用される。
【００６２】
デフォルトポリシーには同一タイプの多数のオブジェクトにポリシーを適用する手段が備わる。デフォルトポリシーはベースとなるオブジェクトタイプを選択することによってオブジェクトに適用される。このオブジェクトタイプはオブジェクト指向展開に使用される一般的な概念であるが、オブジェクトはクラスによって記載されるような特定のタイプのものである。オブジェクトはオブジェクトクラスの具体化されたものである。
【００６３】
デフォルトポリシーはトランザクション／要求に基づき動的に作成される。このようなポリシーによりその後のトランザクション／要求が取り扱われる。
以下の実施例により、デフォルトポリシーの処理とその適用を説明するのに必要なすべての情報が備わる。
【００６４】
以下の特徴によって、デフォルトポリシーの発生で取られる手法とポリシー管理アリーナで最近提案されたその他の手法とが区別される。
１．１つのポリシー定義の実現値を新しいトランザクション／要求に応じて動的に発生させ、要求に記述されたオブジェクトに適用させる。
【００６５】
２．オブジェクトタイプの使用に沿った単一のポリシーを定義することで、同一ポリシーを多数のオブジェクトに自動的に適用する手段を備える。
システムは次のオブジェクトからなる。
【００６６】
オブジェクトＡ，オブジェクトＢ，オブジェクトＣ
これらのオブジェクトは次のオブジェクトタイプである。
オブジェクトＡ：オブジェクトタイプＸＸ
オブジェクトＢ：オブジェクトタイプＹＹ
オブジェクトＣ：オブジェクトタイプＺＺ
各オブジェクトタイプには次のポリシーが割り当てられる。
【００６７】
オブジェクトタイプＸＸ：ポリシーＮ
オブジェクトタイプＹＹ：ポリシーＯ
オブジェクトタイプＺＺ：ポリシーＰ
オブジェクトタイプＸＸのオブジェクトＡを参照することからなるトランザクション／要求が受け取られると、ポリシーＮタイプのポリシーがその要求に適用され、引続くすべての要求にはオブジェクトＡを参照することが含まれる。オブジェクトＡとオブジェクトＣを参照することからなる要求が受け取られた場合は、ポリシーＮとポリシーＰの両方のポリシーが要求に適用される。用語「適用される」は指示されたポリシーの唯一の実現値がメモリーで作成され、状態を維持してポリシー実施のために必要なルールとアクションを参照するのに使用される。
【００６８】
本発明は特にｖＩＳＰに関して述べたが、同時ライセンスポリシーやオンラインゲームセションポリシーなどの他のネットワークアクセスセションポリシーにも適用できる。
【図面の簡単な説明】
【００６９】
【図１】データモデルの概略的な表示である。
【図２】仮想のＩＳＰインフラストラクチュアネットワーク用の分解環境またはシステムを記述したエンティティを示す。
【図３】エンティティ間に定義した親子関係を単一のビューで示す。
【図４】図３にビューを追加したものを示す。
【図５】環境モデルにポリシー関連を重ねた例を示す。
【図６】ポリシーモデルを示す。
【図７】要求とポリシーモデルとの関係を示す。
【図８】別のポリシーモデルを示す。
【図１】
2005506016.tif 000008
【図２】
2005506016.tif 000009
【図３】
2005506016.tif 000010
【図４】
2005506016.tif 000011
【図５】
2005506016.tif 000012
【図６】
2005506016.tif 000013
【図７】
2005506016.tif 000014
【図８】
2005506016.tif 000015
【国際公開パンフレット】
2005506016.tif 000016
2005506016.tif 000017
2005506016.tif 000018
2005506016.tif 000019
2005506016.tif 000020
2005506016.tif 000021
2005506016.tif 000022
2005506016.tif 000023
2005506016.tif 000024
2005506016.tif 000025
2005506016.tif 000026
2005506016.tif 000027
2005506016.tif 000028
2005506016.tif 000029
2005506016.tif 000030
2005506016.tif 000031
2005506016.tif 000032
2005506016.tif 000033
2005506016.tif 000034
2005506016.tif 000035
2005506016.tif 000036
2005506016.tif 000037
2005506016.tif 000038
2005506016.tif 000039
2005506016.tif 000040
【国際公開パンフレット（コレクトバージョン）】
2005506016.tif 000041
2005506016.tif 000042
【国際調査報告】
2005506016.tif 000043
2005506016.tif 000044
2005506016.tif 000045