JP2015519842A - ルーティング決定コンテキストオブジェクト - Google Patents

Abstract

さまざまな例示的な実施形態は、以下、すなわち、ＤＲＡで送信元デバイスからＤｉａｍｅｔｅｒメッセージを受信するステップと、Ｄｉａｍｅｔｅｒメッセージを受信するステップに応答してルーティング決定コンテキストオブジェクトを確立するステップであって、ルーティング決定コンテキストオブジェクトが、前のメッセージを受信するために選択された送信先デバイスに関連する、確立するステップと、コンテキストオブジェクトの参照を含む規則を評価するステップであって、評価が、コンテキストオブジェクトの参照に基づいてルーティング決定コンテキストオブジェクトにアクセスすることを含む、評価するステップと、規則の評価に基づいてメッセージを送信するステップとのうちの１つまたは複数を含む方法および関連するネットワークノードに関する。

Description

関連出願の相互参照
本出願は、引用により本明細書に組み込まれている次の同時係属中の出願、すなわち、特許出願第１３／４８２，５９７号、「ＯＲＧＡＮＩＺＡＴＩＯＮ ＯＦ ＤＩＡＭＥＴＥＲ ＲＯＵＴＩＮＧ ＡＧＥＮＴ ＲＵＬＥ ＳＥＴＳ」、代理人整理番号ＡＬＣ３８０９に関する。

本明細書において開示されるさまざまな例示的な実施形態は、一般に、コンピュータネットワーキングに関する。

Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ（ＩＥＴＦ）Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ（ＲＦＣ）３５８８におけるその提案以来、Ｄｉａｍｅｔｅｒプロトコルは、多くのネットワークアプリケーションによってますます採用されるようになった。例えば、第３世代パートナーシッププロジェクト（３ＧＰＰ）は、さまざまなポリシーおよび課金制御（ＰＣＣ：ｐｏｌｉｃｙ ａｎｄ ｃｈａｒｇｉｎｇ ｃｏｎｔｒｏｌ）、モビリティ管理、およびＩＰマルチメディアサブシステム（ＩＭＳ）アプリケーションにＤｉａｍｅｔｅｒを採用した。ＩＰに基づくネットワークが回路交換ネットワークに取って代わるにつれて、Ｄｉａｍｅｔｅｒが、さらに、重要な通信シグナリングプロトコルとしてＳＳ７と入れ替わってきている。ネットワークの発展につれて、Ｄｉａｍｅｔｅｒは、無線および有線通信ネットワークの中で広く使われるプロトコルになってきている。

Ｄｉａｍｅｔｅｒプロトコルの１つの重要な態様は、Ｄｉａｍｅｔｅｒパケットのルーティングである。Ｄｉａｍｅｔｅｒルーティングエージェント（ＤＲＡ）と呼ばれるエンティティが、ネットワークにおけるパケットの移動を容易にする。さまざまな展開で、ＤＲＡは、単純なルーティング、プロキシ、およびリダイレクトなどの基本的な機能を実行する可能性がある。

さまざまな例示的な実施形態の簡潔な概要が、以下に示される。以下の概要においていくつかの簡略化および省略が行われる可能性があり、そのことは、さまざまな例示的な実施形態のいくつかの態様を強調し、紹介するように意図されており、本発明の範囲を限定するように意図されていない。当業者が本発明の概念を実施し、使用することを可能にするのに適した好ましい例示的な実施形態の詳細な説明が、その後の節で後に続く。

さまざまな例示的な実施形態は、Ｄｉａｍｅｔｅｒメッセージを処理するためにＤｉａｍｅｔｅｒルーティングエージェント（ＤＲＡ）によって実行される方法であって、コンテキストアーチファクト（ａｒｔｉｆａｃｔ）を識別するステップであって、コンテキストアーチファクトがＤＲＡによる使用のためにコンテキストオブジェクトタイプを定義する、識別するステップと、ＤＲＡで送信元デバイスからＤｉａｍｅｔｅｒメッセージを受信するステップと、コンテキストアーチファクトによって定義されたコンテキストオブジェクトタイプのコンテキストオブジェクトを確立するステップと、コンテキストオブジェクトの参照を含む規則を評価するステップであって、評価が、コンテキストオブジェクトの参照に基づいてコンテキストオブジェクトにアクセスすることを含む、評価するステップと、規則の評価に基づいてメッセージを送信するステップとを含む、方法に関する。

さまざまな例示的な実施形態は、Ｄｉａｍｅｔｅｒメッセージを処理するためのＤｉａｍｅｔｅｒルーティングエージェント（ＤＲＡ）であって、コンテキストオブジェクトタイプを定義するコンテキストアーチファクトを格納するように構成されたコンテキストアーチファクトストレージと、コンテキストオブジェクトの参照を含む規則を格納するように構成された規則ストレージと、送信元デバイスからＤｉａｍｅｔｅｒメッセージを受信するように構成されたＤｉａｍｅｔｅｒスタックと、コンテキストアーチファクトによって定義されたコンテキストオブジェクトタイプのコンテキストオブジェクトを確立するように構成されコンテキスト生成器と、規則を評価するように構成された規則エンジンであって、評価が、コンテキストオブジェクトの参照に基づいてコンテキストオブジェクトにアクセスすることを含む、規則エンジンと、Ｄｉａｍｅｔｅｒスタックを介して規則の評価に基づいてメッセージを送信するように構成されたメッセージハンドラとを含む、Ｄｉａｍｅｔｅｒルーティングエージェント（ＤＲＡ）に関する。

さまざまな例示的な実施形態は、Ｄｉａｍｅｔｅｒメッセージを処理するためにＤｉａｍｅｔｅｒルーティングエージェント（ＤＲＡ）によって実行するための命令を符号化された非一時的機械可読ストレージ媒体であって、コンテキストアーチファクトを識別するための命令であって、コンテキストアーチファクトがＤＲＡによる使用のためにコンテキストオブジェクトタイプを定義する、識別するための命令と、ＤＲＡで送信元デバイスからＤｉａｍｅｔｅｒメッセージを受信するための命令と、コンテキストアーチファクトによって定義されたコンテキストオブジェクトタイプのコンテキストオブジェクトを確立するための命令と、コンテキストオブジェクトの参照に基づいてコンテキストオブジェクトにアクセスするための命令を含む、コンテキストオブジェクトの参照を含む規則を評価するための命令と、規則の評価に基づいてメッセージを送信するための命令とを含む、非一時的機械可読ストレージ媒体に関する。

コンテキストアーチファクトがコンテキストオブジェクトのクラスを定義するランタイムライブラリであるさまざまな実施形態が、説明される。

コンテキストオブジェクトにアクセスすることがコンテキストアーチファクトによって定義された属性を取り出すことを含むさまざまな実施形態が、説明される。

コンテキストオブジェクトにアクセスすることがコンテキストアーチファクトによって定義されたアクションを呼び出すことを含むさまざまな実施形態が、説明される。

さまざまな実施形態は、コンテキストアーチファクトを識別するステップの前に、ＤＲＡのユーザインターフェースを介してコンテキストアーチファクトを受信するステップをさらに含む。

さまざまな実施形態は、コンテキストアーチファクト内の注釈（ａｎｎｏｔａｔｉｏｎ）を見つけるステップと、注釈に基づいてコンテキストオブジェクトタイプに関する構成要素名を生成するステップであって、構成要素名がコンテキストオブジェクトタイプの属性およびアクションのうちの少なくとも１つを指す、生成するステップとをさらに含む。

さまざまな実施形態は、ユーザインターフェースを介して、規則に対応する規則の定義を受信するステップであって、規則の定義が構成要素名への参照を含み、構成要素名への参照がコンテキストオブジェクトの参照に対応する、受信するステップをさらに含む。

さまざまな例示的な実施形態は、Ｄｉａｍｅｔｅｒメッセージを処理するためにＤｉａｍｅｔｅｒルーティングエージェント（ＤＲＡ）によって実行される方法であって、ＤＲＡで送信元デバイスからＤｉａｍｅｔｅｒメッセージを受信するステップと、Ｄｉａｍｅｔｅｒメッセージを受信するステップに応答してルーティング決定コンテキストオブジェクトを確立するステップであって、ルーティング決定コンテキストオブジェクトが、前のメッセージを受信するために選択された送信先デバイスに関連する、確立するステップと、コンテキストオブジェクトの参照を含む規則を評価するステップであって、評価が、コンテキストオブジェクトの参照に基づいてルーティング決定コンテキストオブジェクトにアクセスすることを含む、評価するステップと、規則の評価に基づいてメッセージを送信するステップとを含む、方法に関する。

さまざまな例示的な実施形態は、Ｄｉａｍｅｔｅｒメッセージを処理するためのＤｉａｍｅｔｅｒルーティングエージェント（ＤＲＡ）であって、コンテキストオブジェクトの参照を含む規則を格納するように構成された規則ストレージと、前のルーティングの決定を格納するように構成されたルーティング決定データベースであって、前のルーティングの決定が、前のメッセージのために選択された送信先デバイスの識別情報を含む、ルーティング決定データベースと、送信元デバイスからＤｉａｍｅｔｅｒメッセージを受信するように構成されたＤｉａｍｅｔｅｒスタックと、Ｄｉａｍｅｔｅｒメッセージを受信することに基づいてルーティング決定コンテキストオブジェクトを確立するように構成されたコンテキスト生成器であって、ルーティング決定コンテキストオブジェクトが前のルーティングの決定に関連する、コンテキスト生成器と、規則を評価するように構成された規則エンジンであって、評価が、コンテキストオブジェクトの参照に基づいてルーティング決定コンテキストオブジェクトにアクセスすることを含む、規則エンジンと、Ｄｉａｍｅｔｅｒスタックを介して規則の評価に基づいてメッセージを送信するように構成されたメッセージハンドラとを含む、Ｄｉａｍｅｔｅｒルーティングエージェント（ＤＲＡ）に関する。

さまざまな例示的な実施形態は、Ｄｉａｍｅｔｅｒメッセージを処理するためにＤｉａｍｅｔｅｒルーティングエージェント（ＤＲＡ）によって実行するための命令を符号化された非一時的機械可読ストレージ媒体であって、ＤＲＡで送信元デバイスからＤｉａｍｅｔｅｒメッセージを受信するための命令と、Ｄｉａｍｅｔｅｒメッセージを受信することに応答してルーティング決定コンテキストオブジェクトを確立するための命令であって、ルーティング決定コンテキストオブジェクトが、前のメッセージを受信するために選択された送信先デバイスに関連する、確立するための命令と、コンテキストオブジェクトの参照に基づいてルーティング決定コンテキストオブジェクトにアクセスするための命令を含む、コンテキストオブジェクトの参照を含む規則を評価するための命令と、規則の評価に基づいてメッセージを送信するための命令とを含む、非一時的機械可読ストレージ媒体に関する。

規則の評価に基づいてメッセージを送信するステップがＤｉａｍｅｔｅｒメッセージを送信先デバイスに送信するステップを含むさまざまな実施形態が、説明される。

Ｄｉａｍｅｔｅｒメッセージが第１のＤｉａｍｅｔｅｒアプリケーションに関連し、前のメッセージが第２のＤｉａｍｅｔｅｒアプリケーションに関連するさまざまな実施形態が、説明される。

さまざまな実施形態は、Ｄｉａｍｅｔｅｒメッセージを受信するステップの前に、ＤＲＡで前のメッセージを受信するステップと、前のメッセージが送信先デバイスにルーティングされるべきであると決定するステップと、送信先デバイスに前のメッセージを送信するステップと、前のメッセージおよび送信先デバイスの識別情報をルーティングの決定として格納するステップとをさらに含む。

ルーティング決定コンテキストオブジェクトにアクセスすることがルーティングの決定に関連するタイムスタンプを更新することを含むさまざまな実施形態が、説明される。

さまざまな実施形態は、ルーティングの決定がルーティングの決定に関連するタイムスタンプに基づいて削除されるべきであると判定するステップと、ＤＲＡのメモリからルーティングの決定を削除するステップとをさらに含む。

ルーティング決定コンテキストオブジェクトを確立するステップおよびルーティング決定コンテキストオブジェクトにアクセスすることのうちの少なくとも一方が、Ｄｉａｍｅｔｅｒメッセージから少なくとも１つの識別情報を抽出するステップと、少なくとも１つの識別情報が前のメッセージに対応すると判定するステップとを含むさまざまな実施形態が、説明される。

さまざまな例示的な実施形態は、Ｄｉａｍｅｔｅｒメッセージを処理するためにＤｉａｍｅｔｅｒルーティングエージェント（ＤＲＡ）によって実行される方法であって、ＤＲＡで送信元デバイスからＤｉａｍｅｔｅｒメッセージを受信するステップであって、Ｄｉａｍｅｔｅｒメッセージが加入者に関連する、受信するステップと、Ｄｉａｍｅｔｅｒメッセージを受信するステップに応答して加入者レコードコンテキストオブジェクトを確立するステップであって、加入者レコードコンテキストオブジェクトが加入者の加入者レコードに関連する、確立するステップと、コンテキストオブジェクトの参照を含む規則を評価するステップであって、評価が、コンテキストオブジェクトの参照に基づいて加入者レコードコンテキストオブジェクトにアクセスすることを含む、評価するステップと、規則の評価に基づいてメッセージを送信するステップとを含む、方法に関する。

さまざまな例示的な実施形態は、Ｄｉａｍｅｔｅｒメッセージを処理するためのＤｉａｍｅｔｅｒルーティングエージェント（ＤＲＡ）であって、コンテキストオブジェクトの参照を含む規則を格納するように構成された規則ストレージと、送信元デバイスからＤｉａｍｅｔｅｒメッセージを受信するように構成されたＤｉａｍｅｔｅｒスタックであって、Ｄｉａｍｅｔｅｒメッセージが加入者に関連する、Ｄｉａｍｅｔｅｒスタックと、加入者レコードコンテキストオブジェクトを確立するように構成されたコンテキスト生成器であって、加入者レコードコンテキストオブジェクトが加入者の加入者レコードに関連する、コンテキスト生成器と、規則を評価するように構成された規則エンジンであって、評価が、コンテキストオブジェクトの参照に基づいて加入者レコードコンテキストオブジェクトにアクセスすることを含む、規則エンジンと、Ｄｉａｍｅｔｅｒスタックを介して規則の評価に基づいてメッセージを送信するように構成されたメッセージハンドラとを含む、Ｄｉａｍｅｔｅｒルーティングエージェント（ＤＲＡ）に関する。

さまざまな例示的な実施形態は、Ｄｉａｍｅｔｅｒメッセージを処理するためにＤｉａｍｅｔｅｒルーティングエージェント（ＤＲＡ）によって実行するための命令を符号化された非一時的機械可読ストレージ媒体であって、ＤＲＡで送信元デバイスからＤｉａｍｅｔｅｒメッセージを受信するための命令であって、Ｄｉａｍｅｔｅｒメッセージが加入者に関連する、受信するための命令と、Ｄｉａｍｅｔｅｒメッセージを受信することに応答して加入者レコードコンテキストオブジェクトを確立するための命令であって、加入者レコードコンテキストオブジェクトが加入者の加入者レコードに関連する、確立するための命令と、コンテキストオブジェクトの参照に基づいて加入者レコードコンテキストオブジェクトにアクセスするための命令を含む、コンテキストオブジェクトの参照を含む規則を評価するための命令と、規則の評価に基づいてメッセージを送信するための命令とを含む、非一時的機械可読ストレージ媒体に関する。

加入者レコードコンテキストオブジェクトを確立するステップおよび加入者レコードコンテキストオブジェクトにアクセスすることのうちの少なくとも一方が、Ｄｉａｍｅｔｅｒメッセージに関連する少なくとも１つの加入者識別子を判定するステップと、少なくとも１つの加入者識別子に関連する加入者レコードを取り出すステップとを含むさまざまな実施形態が、説明される。

加入者レコードを取り出すステップが加入者プロファイルリポジトリ（ＳＰＲ）にメッセージを送信するステップを含むさまざまな実施形態が、説明される。

加入者レコードコンテキストオブジェクトにアクセスすることが加入者レコードのフィールドを読むことを含むさまざまな実施形態が、説明される。

加入者レコードコンテキストオブジェクトにアクセスすることが加入者レコードに値を書き込むことを含み、方法が修正された加入者レコードを格納するステップをさらに含むさまざまな実施形態が、説明される。

加入者レコードコンテキストオブジェクトにアクセスすることが加入者レコードコンテキストオブジェクトのアクションを呼び出すことを含み、加入者レコードコンテキストオブジェクトのアクションがコンテキストオブジェクトの関数以外のＤＲＡの関数を呼び出すさまざまな実施形態が、説明される。

ＤＲＡの関数が加入者プロファイルリポジトリから加入者レコードを取り出すさまざまな実施形態が、説明される。

さまざまな例示的な実施形態をより深く理解するために、添付の図面が参照される。

Ｄｉａｍｅｔｅｒルーティングエージェントに関する例示的なネットワーク環境を示す図である。 例示的なＤｉａｍｅｔｅｒルーティングエージェントを示す図である。 Ｄｉａｍｅｔｅｒメッセージを処理するための例示的な方法を示す図である。 コンテキストアーチファクトを利用するための例示的な方法を示す図である。 コンテキストオブジェクトのためのメタデータを生成するための例示的な方法を示す図である。 ルーティング決定コンテキストオブジェクトに関する例示的なクラス図である。 前のルーティングの決定を取り出すための例示的な方法を示す図である。 加入者レコードコンテキストオブジェクトに関する例示的なクラス図である。 加入者レコードを取り出すための例示的な方法を示す図である。 例示的な規則の組を示す図である。

説明および図面は、単に本発明の原理を示すに過ぎない。したがって、当業者が、本明細書において明示的に説明または図示されていないが、本発明の原理を具現化し、本発明の範囲内に含まれるさまざまな構成に想到することができることが理解されるであろう。さらに、本明細書に示されたすべての例は、もっぱら、本発明の原理、および当技術分野の発展のために（１人または複数の）発明者によってもたらされた概念を読者が理解することを助けるための教示のみを目的とするように明確に意図されており、そのような具体的に示された例および条件に限定されないと解釈されるべきである。加えて、本明細書において使用されるとき、用語「または（ｏｒ）」は、そうでないことが示され（例えば、「さもなくば（ｏｒ ｅｌｓｅ）」または「またはその代替として（ｏｒ ｉｎ ｔｈｅ ａｌｔｅｒｎａｔｉｖｅ）」）ていない限り非排他的なまたは（ｏｒ）（すなわち、および／または（ａｎｄ／ｏｒ））を指す。また、本明細書において説明されるさまざまな実施形態は、新しい実施形態を形成するために一部の実施形態が１つまたは複数のその他の実施形態と組み合わされ得るので、必ずしも互いに排他的であるとは限らない。本明細書において使用されるとき、用語「コンテキスト」および「コンテキストオブジェクト」は、そうでないことが示されない限り同義であると理解される。

今日利用可能なＤｉａｍｅｔｅｒルーティングエージェント（ＤＲＡ）は、典型的にはハードコーディングまたはスクリプティングで定義される基本的な機能だけを提供する。したがって、概して、ユーザは、ＤＲＡのより複雑な挙動を容易で柔軟に定義することができるようにされない可能性がある。以上のことに鑑みて、ＤＲＡメッセージ処理の挙動のユーザ定義および拡張を容易にする方法およびシステムを提供することが望ましい。

図１は、Ｄｉａｍｅｔｅｒルーティングエージェント（ＤＲＡ）１４２のための例示的なネットワーク環境１００を示す。例示的なネットワーク環境１００は、さまざまなサービスを提供するための加入者ネットワークである可能性がある。さまざまな実施形態において、加入者ネットワーク１００は、公衆陸上モバイルネットワーク（ＰＬＭＮ：ｐｕｂｌｉｃ ｌａｎｄ ｍｏｂｉｌｅ ｎｅｔｗｏｒｋ）である可能性がある。例示的な加入者ネットワーク１００は、さまざまなサービスへのアクセスを提供するための電気通信ネットワークまたはその他のネットワークである可能性がある。例示的な加入者ネットワーク１００は、ユーザ機器１１０、基地局１２０、進化型パケットコア（ＥＰＣ）１３０、パケットデータネットワーク１５０、およびアプリケーション機能（ＡＦ）１６０を含み得る。

ユーザ機器１１０は、エンドユーザにデータサービスを提供するためにパケットデータネットワーク１５０と通信するデバイスである可能性がある。そのようなデータサービスは、例えば、音声通信、テキストメッセージング、マルチメディアストリーミング、およびインターネットアクセスを含み得る。より詳細には、さまざまな例示的な実施形態において、ユーザ機器１１０は、パーソナルもしくはラップトップコンピュータ、無線電子メールデバイス、セル電話、タブレット、テレビセットトップボックス、またはＥＰＣ１３０を介してその他のデバイスと通信することができる任意のその他のデバイスである。

基地局１２０は、ユーザ機器１１０とＥＰＣ１３０との間の通信を可能にするデバイスである可能性がある。例えば、基地局１２０は、関連する３ＧＰＰ規格によって定義された進化型ｎｏｄｅＢ（ｅＮｏｄｅＢ）などの無線基地局である可能性がある。したがって、基地局１２０は、電波などの第１の媒体を介してユーザ機器１１０と通信し、イーサネット（登録商標）ケーブルなどの第２の媒体を介してＥＰＣ１３０と通信するデバイスである可能性がある。基地局１２０は、ＥＰＣ１３０と直接通信する可能性があるか、またはいくつかの中間ノード（図示せず）を介して通信する可能性がある。さまざまな実施形態においては、ユーザ機器１１０にモビリティを提供するために複数の基地局（図示せず）が存在する可能性がある。さまざまな代替的な実施形態において、ユーザ機器１１０は、ＥＰＣ１３０と直接通信する可能性があることに留意されたい。そのような実施形態においては、基地局１２０は存在しない可能性がある。

進化型パケットコア（ＥＰＣ）１３０は、ユーザ機器１１０にパケットデータネットワーク１４０へのゲートウェイアクセスを提供するデバイスまたはデバイスのネットワークである可能性がある。さらに、ＥＰＣ１３０は、提供されるデータサービスの使用について加入者に課金し、特定の体感品質（ＱｏＥ）の基準が満たされることを保証することができる。このように、ＥＰＣ１３０は、少なくとも部分的に、関連する３ＧＰＰ規格に準じて実装され得る。ＥＰＣ１３０は、サービングゲートウェイ（ＳＧＷ）１３２、パケットデータネットワークゲートウェイ（ＰＧＷ）１３４、およびセッション制御デバイス１４０を含み得る。

サービングゲートウェイ（ＳＧＷ）１３２は、ＥＰＣ１３０へのゲートウェイアクセスを提供するデバイスである可能性がある。ＳＧＷ１３２は、ユーザ機器１１０によって送信されたパケットを受信するＥＰＣ１３０内の第１のデバイスのうちの１つである可能性がある。さまざまな実施形態は、ＳＧＷ１３２の前にパケットを受信するモビリティ管理エンティティ（ＭＭＥ）（図示せず）も含み得る。ＳＧＷ１３２は、そのようなパケットをＰＧＷ１３４に転送することができる。ＳＧＷ１３２は、例えば、複数の基地局（図示せず）間のユーザ機器１１０のモビリティの管理、および提供されている各フローに関する特定のサービス品質（ＱｏＳ）特性の施行などのいくつかの機能を実行することができる。プロキシモバイルＩＰ（Ｐｒｏｘｙ Ｍｏｂｉｌｅ ＩＰ）規格を実装する実装などのさまざまな実装において、ＳＧＷ１３２は、ベアラバインディングおよびイベント報告機能（ＢＢＥＲＦ：Ｂｅａｒｅｒ Ｂｉｎｄｉｎｇ ａｎｄ Ｅｖｅｎｔ Ｒｅｐｏｒｔｉｎｇ Ｆｕｎｃｔｉｏｎ）を含み得る。さまざまな例示的な実施形態において、ＥＰＣ１３０は、複数のＳＧＷ（図示せず）を含む可能性があり、各ＳＧＷが、複数の基地局（図示せず）と通信する可能性がある。

パケットデータネットワークゲートウェイ（ＰＧＷ）１３４は、パケットデータネットワーク１４０へのゲートウェイアクセスを提供するデバイスである可能性がある。ＰＧＷ１３４は、ユーザ機器１１０によってＳＧＷ１３２を介してパケットデータネットワーク１４０に送信されたパケットを受信するＥＰＣ１３０内の最後のデバイスである可能性がある。ＰＧＷ１３４は、各サービスデータフロー（ＳＤＦ）に関するポリシーおよび課金制御（ＰＣＣ）規則を施行するポリシーおよび課金施行機能（ＰＣＥＦ：ｐｏｌｉｃｙ ａｎｄ ｃｈａｒｇｉｎｇ ｅｎｆｏｒｃｅｍｅｎｔ ｆｕｎｃｔｉｏｎ）を含み得る。したがって、ＰＧＷ１３４は、ポリシーおよび課金施行ノード（ＰＣＥＮ：ｐｏｌｉｃｙ ａｎｄ ｃｈａｒｇｉｎｇ ｅｎｆｏｒｃｅｍｅｎｔ ｎｏｄｅ）である可能性がある。ＰＧＷ１３４は、例えば、パケットフィルタリング、ディープパケットインスペクション、および加入者課金のサポートなどのいくつかの追加的な特徴を含み得る。ＰＧＷ１３４は、知られていないアプリケーションサービスに対するリソース割り当てを要求する役割を担う可能性もある。

セッション制御デバイス１４０は、ＥＰＣ１３０内のさまざまな管理またはその他の機能を提供するデバイスである可能性がある。例えば、セッション制御デバイス１４０は、ポリシーおよび課金規則機能（ＰＣＲＦ：Ｐｏｌｉｃｙ ａｎｄ Ｃｈａｒｇｉｎｇ Ｒｕｌｅｓ Ｆｕｎｃｔｉｏｎ）を提供する可能性がある。さまざまな実施形態において、セッション制御デバイス１４０は、Ａｌｃａｔｅｌ Ｌｕｃｅｎｔ ５７８０ Ｄｙｎａｍｉｃ Ｓｅｒｖｉｃｅｓ Ｃｏｎｔｒｏｌｌｅｒ（ＤＳＣ）を含み得る。セッション制御デバイス１４０は、ＤＲＡ１４２、複数のポリシーおよび課金規則ブレード（ＰＣＲＢ：ｐｏｌｉｃｙ ａｎｄ ｃｈａｒｇｉｎｇ ｒｕｌｅｓ ｂｌａｄｅ）１４４、１４６、ならびに加入者プロファイルリポジトリを含み得る。

以下でより詳細に説明されるように、ＤＲＡ１４２は、インテリジェントなＤｉａｍｅｔｅｒルーティングエージェントである可能性がある。したがって、ＤＲＡ１４２は、さまざまなＤｉａｍｅｔｅｒメッセージを受信、処理、および送信することができる。ＤＲＡ１４２は、ＤＲＡ１４２が出くわす可能性があるさまざまなＤｉａｍｅｔｅｒメッセージに関するＤＲＡ１４２の挙動を管理するいくつかのユーザ定義の規則を含み得る。そのような規則に基づいて、ＤＲＡ１４２は、リレーエージェント、プロキシエージェント、またはリダイレクトエージェントとして動作する可能性がある。例えば、ＤＲＡ１４２は、受信されたメッセージを適切な受信側デバイスに中継する可能性がある。そのようなルーティングは、到着するメッセージおよび出て行くメッセージ、ならびにセッション制御デバイスの内部のメッセージに対して実行される可能性がある。

ポリシーおよび課金規則ブレード（ＰＣＲＢ）１４４、１４６は、それぞれ、アプリケーションサービスの要求を受信し、ＰＣＣ規則を生成し、ＰＣＣ規則をＰＧＷ１３４またはその他のＰＣＥＮ（図示せず）に提供するデバイスまたはデバイスのグループである可能性がある。ＰＣＲＢ１４４、１４６は、ＲｘインターフェースによってＡＦ１６０と通信する可能性がある。ＡＦ１６０に関連して以下でさらに詳細に説明されるように、ＰＣＲＢ１４４、１４６は、ＡＦ１６０から認証および認可要求（ＡＡＲ）の形態のアプリケーション要求を受信する可能性がある。ＡＡＲを受信すると、ＰＣＲＢ１４４、１４６は、アプリケーション要求を満たすための少なくとも１つの新しいＰＣＣ規則を生成することができる。

ＰＣＲＢ１４４、１４６は、それぞれＧｘｘおよびＧｘインターフェースによってＳＧＷ１３２およびＰＧＷ１３４とやはり通信する可能性がある。ＰＣＲＢ１４４、１４６は、ＳＧＷ１３２またはＰＧＷ１３４からクレジット制御要求（ＣＣＲ：ｃｒｅｄｉｔ ｃｏｎｔｒｏｌ ｒｅｑｕｅｓｔ）の形態でアプリケーション要求を受信する可能性がある。ＡＡＲと同様に、ＣＣＲを受信すると、ＰＣＲＢ１４４、１４６は、アプリケーション要求を満たすための少なくとも１つの新しいＰＣＣ規則を生成することができる。さまざまな実施形態において、ＡＡＲおよびＣＣＲは、別々に処理されるべき２つの独立したアプリケーション要求を表す可能性があり、一方、その他の実施形態においては、ＡＡＲおよびＣＣＲは、単一のアプリケーション要求に関する情報を運ぶ可能性があり、ＰＣＲＢ１４４、１４６は、ＡＡＲとＣＣＲとの組み合わせに基づいて少なくとも１つのＰＣＣ規則を生成する可能性がある。さまざまな実施形態において、ＰＣＲＢ１４４、１４６は、単一のメッセージのアプリケーション要求と、対のメッセージのアプリケーション要求との両方を処理することができる可能性がある。

新しいＰＣＣ規則を生成すると、またはＰＧＷ１３４によって要求されると、ＰＣＲＢ１４４、１４６は、Ｇｘインターフェースを介してＰＧＷ１３４にＰＣＣ規則を与える可能性がある。例えば、プロキシモバイルＩＰ（ＰＭＩＰ）規格を実装する実施形態などのさまざまな実施形態において、ＰＣＲＢ１４４、１４６は、ＱｏＳ規則も生成する可能性がある。新しいＱｏＳ規則を生成すると、またはＳＧＷ１３２によって要求されると、ＰＣＲＢ１４４、１４６は、Ｇｘｘインターフェースを介してＳＧＷ１３２にＱｏＳ規則を与える可能性がある。

加入者プロファイルリポジトリ（ＳＰＲ）１４８は、加入者ネットワーク１００への加入者に関連する情報を格納するデバイスである可能性がある。したがって、ＳＰＲ１４８は、読み出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスクストレージ媒体、光学式ストレージ媒体、フラッシュメモリデバイス、および／または同様のストレージ媒体などの機械可読ストレージ媒体を含み得る。ＳＰＲ１４８は、ＰＣＲＢ１４４、１４６のうちの１つのコンポーネントである可能性があるか、またはＥＰＣ１３０またはセッション制御デバイス１４０内の独立したノードを構成する可能性がある。ＳＰＲ１３８によって格納されるデータは、それぞれの加入者の識別子、帯域幅の制限、課金パラメータ、および加入者の優先度などの加入者情報を含み得る。

パケットデータネットワーク１５０は、ユーザ機器１１０と、ＡＦ１６０などのパケットデータネットワーク１５０に接続されたその他のデバイスとの間のデータ通信を提供するための任意のネットワークである可能性がある。パケットデータネットワーク１５０は、パケットデータネットワーク１５０と通信するさまざまなユーザデバイスに、例えば、電話またはインターネットサービスをさらに提供する可能性がある。

アプリケーション機能（ＡＦ）１６０は、ユーザ機器１１０に知られているアプリケーションサービスを提供するデバイスである可能性がある。したがって、ＡＦ１６０は、ユーザ機器１１０に、例えば、ビデオストリーミングまたは音声通信サービスを提供するサーバまたはその他のデバイスである可能性がある。さらに、ＡＦ１６０は、Ｒｘインターフェースを介してＥＰＣ１３０のＰＣＲＢ１４４、１４６と通信する可能性がある。ＡＦ１６０は、ユーザ機器１１０への知られているアプリケーションサービスの提供を開始すべきであるとき、Ｄｉａｍｅｔｅｒプロトコルにしたがって認証および認可要求（ＡＡＲ）などのアプリケーション要求メッセージを生成して、アプリケーションサービスにリソースが割り当てられるべきであることをＰＣＲＢ１４４、１４６に知らせることができる。このアプリケーション要求メッセージは、アプリケーションサービスを使用する加入者の識別情報、加入者のＩＰアドレス、関連するＩＰ−ＣＡＮセッションに関するＡＰＮ、または要求されたサービスを提供するために確立されなければならない特定のサービスデータフローの識別情報などの情報を含み得る。

理解されるであろうように、さまざまなＤｉａｍｅｔｅｒアプリケーションが、加入者ネットワーク１００内で確立され、ＤＲＡ１４２によってサポートされる可能性がある。例えば、Ｒｘアプリケーションが、ＡＦ１６０とＰＣＲＢ１４４、１４６のそれぞれとの間で確立される可能性がある。別の例として、Ｓｐアプリケーションが、ＳＰＲ１４８とＰＣＲＢ１４４、１４６のそれぞれとの間で確立される可能性がある。さらに別の例として、Ｓ９アプリケーションが、ＰＣＲＢ１４４、１４６のうちの１つまたは複数と、別のＰＣＲＦを実装する遠隔のデバイス（図示せず）との間で確立される可能性がある。理解されるであろうように、多数のその他のＤｉａｍｅｔｅｒアプリケーションが、加入者ネットワーク１００内で確立される可能性がある。

さまざまな潜在的なＤｉａｍｅｔｅｒアプリケーションをサポートする際、ＤＲＡ１４２は、Ｄｉａｍｅｔｅｒメッセージを受信し、メッセージを処理し、処理に基づいてアクションを実行することができる。例えば、ＤＲＡ１４２は、ＰＧＷ１３４からＧｘ ＣＣＲを受信し、Ｇｘ ＣＣＲを処理するための適切なＰＣＲＢ１４４、１４６を識別し、識別されたＰＣＲＢ１４４、１４６にＧｘ ＣＣＲを転送する可能性がある。ＤＲＡ１４２は、ＰＣＲＢ１４４、１４６によって送信された後続のＧｘ ＣＣＡを、ＰＣＲＢ１４４、１４６の代わりにＤＲＡ１４２を指す送信元ホストの識別情報を運ぶように修正することによってプロキシとして動作する可能性もある。追加的にまたは代替的に、ＤＲＡ１４２は、リダイレクトエージェントとして動作するか、またはそうでなければ、適切な応答メッセージを形成し、適切な要求元デバイスに応答メッセージを送信することによって要求メッセージに直接応答する可能性がある。

図２は、例示的なＤｉａｍｅｔｅｒルーティングエージェント（ＤＲＡ）２００を示す。ＤＲＡ２００は、スタンドアロンのデバイス、または別のシステムの構成要素である可能性がある。例えば、ＤＲＡ２００は、例示的な環境１００のＤＲＡ１４２に対応する可能性がある。そのような実施形態において、ＤＲＡ１４２は、Ｇｘ、Ｇｘｘ、Ｒｘ、またはＳｐなどの３ＧＰＰによって定義されたさまざまなＤｉａｍｅｔｅｒアプリケーションをサポートする可能性がある。ＤＲＡ２００は、追加的なまたは代替的なアプリケーションがサポートされるさまざまな代替的な実施形態で配備され得ることが理解されるであろう。したがって、本明細書において説明される方法およびシステムが、概して、任意のＤｉａｍｅｔｅｒアプリケーションをサポートすることに適用され得る可能性があることは、明らかであろう。

ＤＲＡ２００は、Ｄｉａｍｅｔｅｒスタック２０５、メッセージハンドラ２１０、規則エンジン２１５、規則ストレージ２２０、ユーザインターフェース２２５、コンテキスト生成器２３０、コンテキストアーチファクトストレージ２４０、メッセージ辞書２４５、ルーティング決定データベース２５０、クリーンアップモジュール２５５、または加入者レコード取得器２６０などのいくつかの構成要素を含み得る。

Ｄｉａｍｅｔｅｒスタック２０５は、Ｄｉａｍｅｔｅｒプロトコルにしたがってその他のデバイスとメッセージを交換するように構成されたハードウェアまたは機械可読ストレージ媒体上の実行可能命令を含み得る。Ｄｉａｍｅｔｅｒスタック２０５は、その他のデバイスと通信するように構成されたハードウェアまたは機械可読ストレージ媒体上に符号化された実行可能命令を含むインターフェースを含み得る。例えば、Ｄｉａｍｅｔｅｒスタック２０５は、イーサネットまたはＴＣＰ／ＩＰインターフェースを含む可能性がある。さまざまな実施形態において、Ｄｉａｍｅｔｅｒスタック２０５は、複数の物理ポートを含み得る。

また、Ｄｉａｍｅｔｅｒスタック２０５は、Ｄｉａｍｅｔｅｒプロトコルにしたがってメッセージを読み、構築するように構成され得る。例えば、Ｄｉａｍｅｔｅｒスタックは、ＣＣＲ、ＣＣＡ、ＡＡＲ、ＡＡＡ、ＲＡＲ、およびＲＡＡメッセージを読み、構築するように構成される可能性がある。Ｄｉａｍｅｔｅｒスタック２０５は、ＤＲＡ２００のその他の構成要素がＤｉａｍｅｔｅｒスタックの機能性を呼び出すことができるようにアプリケーションプログラムインターフェース（ＡＰＩ）を提供する可能性がある。例えば、規則エンジン２１５は、ＡＰＩを利用して、受信されたＣＣＲから属性−値ペア（ＡＶＰ）を読み、新しいＣＣＡのＡＶＰを修正することができる可能性がある。さまざまなさらなる機能性が、以下の説明から明らかになるであろう。

メッセージハンドラ２１０は、受信されたメッセージを解釈し、必要に応じて規則エンジン２１５を呼び出すように構成されたハードウェアまたは機械可読ストレージ媒体上の実行可能命令を含み得る。さまざまな実施形態において、メッセージハンドラ２１０は、Ｄｉａｍｅｔｅｒスタック２０５によって受信されたメッセージからメッセージタイプを抽出し、抽出されたメッセージタイプに適する規則の組を用いて規則エンジンを呼び出すことができる。例えば、メッセージタイプは、受信されたメッセージのアプリケーションおよびコマンドによって定義される可能性がある。規則エンジン２１５が１つまたは複数の規則の評価を終えた後、メッセージハンドラ２１０は、規則エンジン２１５によって呼び出された１つまたは複数のコンテキストオブジェクトのアクションに基づいてＤｉａｍｅｔｅｒスタックを介して１つまたは複数のメッセージを送信することができる。

規則エンジン２１５は、規則ストレージ２２０に格納された１つまたは複数の規則を評価することによって受信されたメッセージを処理するように構成されたハードウェアまたは機械可読ストレージ媒体上の実行可能命令を含み得る。したがって、規則エンジン２１５は、ある種の処理エンジンである可能性がある。規則エンジン２１５は、１つまたは複数の規則を取り出し、規則の基準を評価して規則が適用可能であるかどうかを判定し、任意の適用可能な規則の１つまたは複数の結果を指定することができる。例えば、規則エンジン２１５は、受信されたＧｘ ＣＣＲがＤＲＡ２００を識別する送信先ホストＡＶＰを含むときに、規則が適用可能であると判定する可能性がある。規則は、メッセージが転送される前に送信先ホストＡＶＰがＰＣＲＢを識別するように変更されるべきであることを指定する可能性がある。

規則ストレージ２２０は、規則エンジン２１５による評価のための１つまたは複数の規則を格納することができる任意の機械可読媒体である可能性がある。したがって、規則ストレージ２２０は、読み出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスクストレージ媒体、光学式ストレージ媒体、フラッシュメモリデバイス、および／または同様のストレージ媒体などの機械可読ストレージ媒体を含み得る。さまざまな実施形態において、規則ストレージ２２０は、１つまたは複数の規則の組を二分決定木データ構造として格納する可能性がある。規則の組を格納するためのさまざまなその他のデータ構造は、明らかであろう。

さまざまな構成要素は、規則を評価することまたは規則に基づいてコンテキストオブジェクトにアクセスすることなどの機能を実行するように構成されるものとして説明されるが、そのような構成は、任意の規則が規則ストレージに存在することを必要としない可能性があることが理解されるであろう。例えば、規則エンジン２１５が、たとえコンテキストオブジェクトの参照を含む規則が規則ストレージ２２０に格納されていないとしてもそのような規則を評価するように構成される可能性がある。その後、ユーザがそのような規則を規則ストレージに追加する場合、規則エンジン２１５は、本明細書において説明されるように規則を処理することができる。換言すれば、本明細書において使用されるとき、語句「〜ように構成された（ｃｏｎｆｉｇｕｒｅｄ ｔｏ）」は、規則に関する機能性に関連して使用されるとき、構成要素が、そのような機能性を要求する規則が実際に存在するかどうかに関わらず必要に応じて機能性を実行することができることを意味すると理解される。

ユーザインターフェース２２５は、ユーザとのコミュニケーションを可能にするように構成されたハードウェアまたは機械可読ストレージ媒体上の実行可能命令を含み得る。したがって、ユーザインターフェース２２５は、（Ｄｉａｍｅｔｅｒスタック２０５に含まれるネットワークインターフェースなどの）ネットワークインターフェース、モニタ、キーボード、マウス、またはタッチ感知式ディスプレイを含み得る。ユーザインターフェース２２５は、ユーザのインタラクションを容易にするためのグラフィカルユーザインターフェース（ＧＵＩ）も提供する可能性がある。ユーザインターフェース２２５は、ユーザがＤＲＡ２００の挙動をカスタマイズすることを可能にし得る。例えば、ユーザインターフェース２２５は、規則ストレージ２２０に格納し、規則エンジン２１５により評価するための規則をユーザが定義することを可能にし得る。ユーザがユーザインターフェース２２５を介してＤＲＡ２００の挙動をカスタマイズするためのさまざまなさらなる方法は、当業者に明らかであろう。

さまざまな実施形態によれば、規則ストレージ２２０は、１つまたは複数の「コンテキスト」または「コンテキストオブジェクト」を参照する規則を含み得る。そのような実施形態において、コンテキスト生成器２３０は、コンテキストオブジェクトをインスタンス化し、要求元構成要素にコンテキストオブジェクトのメタデータを提供するように構成されたハードウェアまたは機械可読ストレージ媒体上の実行可能命令を含み得る。コンテキストオブジェクトは、コンテキスト生成器２３０によってランタイムでインスタンス化される可能性があり、規則エンジン２１５をサポートし、ユーザがユーザインターフェース２２５を介して複雑な規則を定義することを可能にするために有用な属性またはアクションを含む可能性がある。例えば、コンテキスト生成器２３０は、さまざまなＤｉａｍｅｔｅｒメッセージ、前のルーティングの決定、または加入者プロファイルを示すコンテキストオブジェクトを提供する可能性がある。

ＤＲＡ２００が処理されるべきＤｉａｍｅｔｅｒメッセージを受信すると、メッセージハンドラ２１０は、適切なコンテキストオブジェクトがインスタンス化されるべきであるという指示をコンテキスト生成器２３０に送信することができる。そのとき、コンテキスト生成器２３０は、そのようなコンテキストオブジェクトをインスタンス化することができる。一部の実施形態において、コンテキスト生成器２３０は、すべての知られているコンテキストオブジェクトをインスタンス化することができるか、または規則ストレージ２２０によって適用される規則の組によって実際に使用されるコンテキストオブジェクトのみをインスタンス化することができる。その他の実施形態において、コンテキスト生成器２３０は、コンテキストオブジェクトが規則エンジン２１５によって実際に要求されるまでそのコンテキストオブジェクトをインスタンス化しない可能性がある。

加えて、コンテキスト生成器２３０は、コンテキストのメタデータをユーザインターフェース２２５に提供することによって規則の生成を容易にする可能性がある。さまざまな実施形態において、コンテキスト生成器２３０は、どのコンテキストオブジェクトが規則の組が修正されるために利用可能である可能性があるか、およびどの属性またはアクションを各コンテキストオブジェクトが持っている可能性があるかをユーザインターフェース２２５に示すことができる。この情報を用いて、ユーザインターフェース２２５は、複雑な規則を生成するためのポイントアンドクリックインターフェースを表示することができる。例えば、ユーザインターフェース２２５は、構築または修正中の規則に含めるためにリストからコンテキストオブジェクトの所望の属性またはアクションをユーザが選択することを可能にする可能性がある。

コンテキスト生成器２３０は、コンテキストオブジェクトを確立する際に、コンテキストアーチファクトストレージ２４０に格納された１つまたは複数のコンテキストアーチファクトに依拠する可能性がある。したがって、コンテキストアーチファクトストレージ２４０は、１つまたは複数のコンテキストアーチファクトを格納することができる任意の機械可読媒体である可能性がある。したがって、コンテキストアーチファクトストレージ２４０は、読み出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスクストレージ媒体、光学式ストレージ媒体、フラッシュメモリデバイス、および／または同様のストレージ媒体などの機械可読ストレージ媒体を含み得る。コンテキストアーチファクトストレージ２４０は、例えば、ランタイムライブラリなどのさまざまな形態でアーチファクトを格納する可能性がある。さまざまな実施形態において、そのようなランタイムライブラリは、Ｊａｖａ（登録商標）アーカイブ（．ｊａｒ）ファイルとして格納される可能性がある。

それぞれのコンテキストアーチファクトは、コンテキストオブジェクトのために利用可能な属性またはアクションを定義することができる。さまざまな実施形態において、コンテキストアーチファクトは、属性またはアクションがアクセスされるときに実行されるべき１つまたは複数の関数を定義することができる。そのような関数は、ＤｉａｍｅｔｅｒスタックのＡＰＩにアクセスするなど、ＤＲＡ２００のその他の機能を利用する可能性があり、または属性またはアクションを呼び出した構成要素に値を返す可能性がある。コンテキストアーチファクトは、コンテキストオブジェクトのアクションおよび属性を記述するためにコンテキスト生成器２３０がユーザインターフェース２２５に提供するためのタグまたはその他のメタデータも含む可能性がある。例示的なＤＲＡ２００において、コンテキストアーチファクトストレージ２４０は、メッセージコンテキスト、ルーティング決定コンテキスト、または加入者レコードコンテキストを定義するコンテキストアーチファクトを格納することができる。これらのコンテキストアーチファクトは、異なる種類のコンテキストオブジェクトをインスタンス化するためにコンテキスト生成器２３０によってランタイムで使用される可能性がある。したがって、コンテキスト生成器２３０は、メッセージコンテキストモジュール２３２、ルーティング決定コンテキストモジュール２３６、および加入者レコードコンテキストモジュール２３８を含むと見なされ得る。さまざまな実施形態において、ユーザは、既存のファイル（例えば、．ｊａｒファイル）を指定することによるなどして、コンテキストアーチファクトストレージに格納するために、ユーザインターフェース２２５を介して新しいコンテキストアーチファクトを定義することができる可能性がある。

メッセージコンテキストモジュール２３２は、Ｄｉａｍｅｔｅｒメッセージを示し、Ｄｉａｍｅｔｅｒメッセージへのアクセスを示し提供するコンテキストオブジェクトを生成するコンテキスト生成器２３０の能力を表す可能性がある。例えば、メッセージコンテキストモジュール２３２は、受信されたメッセージを示すコンテキストオブジェクトを生成する可能性がある。さまざまな実施形態において、メッセージコンテキストモジュール２３２は、必要に応じて、受信されたＤｉａｍｅｔｅｒメッセージに関連する要求メッセージまたは応答メッセージを示すコンテキストオブジェクトを生成するようにやはり構成される可能性がある。したがって、メッセージコンテキストモジュール２３２は、受信メッセージサブモジュール２３３、関連要求サブモジュール２３４、および関連応答サブモジュール２３５を含むと見なされ得る。

Ｄｉａｍｅｔｅｒメッセージの内容は、アプリケーションおよびコマンドの種類に応じて変わり得る。例えば、ＲＸ ＲＡＡメッセージは、ＧＸ ＣＣＲメッセージとは異なるデータを含む可能性がある。そのような違いは、関連するＤｉａｍｅｔｅｒアプリケーションを管理するさまざまな規格によって定義される可能性がある。さらに、さまざまなベンダーが、プロプライエタリなまたはそうでなければ標準的でない定義を含む可能性がある。メッセージコンテキストモジュール２３２は、異なる種類のＤｉａｍｅｔｅｒメッセージに関するメッセージコンテキストを生成するために、メッセージ辞書２４５に格納されたメッセージの定義に依拠する可能性がある。例えば、Ｄｉａｍｅｔｅｒメッセージを受信すると、メッセージハンドラ２１０は、アプリケーションおよびコマンドタイプをコンテキスト生成器２３０に渡すことができる。そのとき、メッセージコンテキストモジュール２３２は、メッセージ辞書２４５内で一致する定義を見つけることができる。この定義は、指定された種類のメッセージに存在し得るＡＶＰを示す可能性がある。そのとき、メッセージコンテキストモジュール２３２は、メッセージの定義で識別されたＡＶＰに合致する属性およびアクションを有するメッセージコンテキストオブジェクトをインスタンス化することができる。

メッセージ辞書２４５は、１つまたは複数のコンテキストアーチファクトを格納することができる任意の機械可読媒体である可能性がある。したがって、メッセージ辞書２４５は、読み出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスクストレージ媒体、光学式ストレージ媒体、フラッシュメモリデバイス、および／または同様のストレージ媒体などの機械可読ストレージ媒体を含み得る。メッセージ辞書２４５は、例えば、ＸＭＬファイルなどの適切な形態のさまざまなメッセージの定義を含み得る。メッセージ辞書２４５は、供給業者によってＤＲＡ２００とともに含められたいくつかの予め定義された定義を含む可能性がある。さまざまな実施形態において、ユーザは、ユーザインターフェース２２５を介して新しいユーザ定義のメッセージの定義を与えることができる可能性がある。例えば、ユーザは、予め定義された定義によってまだ定義されていないアプリケーションをサポートしたい場合、メッセージ辞書２４５に格納するための定義ファイルを生成するかまたはそうでなければ取得することができる。さまざまな実施形態において、ユーザ定義の定義は、予め定義された定義とは異なるディレクトリなど、メッセージ辞書の異なる部分に格納される可能性がある。

さまざまな実施形態において、ユーザは、ユーザインターフェース２２５を介して予め定義された定義を拡張することもできる可能性がある。ユーザは、特定のメッセージタイプに現れるべき新しいＡＶＰを定義するか追加のＡＶＰを指定する拡張定義を与えることができる可能性がある。例えば、ユーザは、Ｒｘ ＡＡＲ内のプロプライエタリのＡＶＰをサポートしたい可能性がある。そのようなサポートを提供するために、ユーザは、プロプライエタリのＡＶＰを定義し、プロプライエタリのＡＶＰがＲｘ ＡＡＲに存在する可能性があることを示すＸＭＬファイルなどの定義ファイルを与える可能性がある。そのような拡張定義は、予め定義された定義とは異なるメッセージ辞書２４５の領域に格納される可能性もある。メッセージコンテキストモジュール２３２は、新しいメッセージコンテキストオブジェクトをインスタンス化するか、またはコンテキストのメタデータをユーザインターフェース２２５に提供するとき、任意の適用可能な拡張定義を適用するように構成され得る。

上述のように、Ｄｉａｍｅｔｅｒメッセージを受信すると、メッセージハンドラ２１０は、アプリケーションおよびコマンドタイプを抽出し、この情報をコンテキスト生成器２３０に渡すことができ、次いで、コンテキスト生成器２３０が、新しい受信メッセージコンテキストオブジェクトをインスタンス化するために任意の適用可能な定義を見つけることができる。受信メッセージサブモジュール２３３は、新しいコンテキストオブジェクトを受信されたＤｉａｍｅｔｅｒメッセージ自体に関連付けるようにさらに構成され得る。例えば、受信メッセージサブモジュール２３３は、受信されたＤｉａｍｅｔｅｒメッセージをＤｉａｍｅｔｅｒスタック２０５からｐｒｉｖａｔｅまたはｐｒｏｔｅｃｔｅｄ変数にコピーする可能性がある。代替的に、受信メッセージサブモジュール２３３は、Ｄｉａｍｅｔｅｒスタック２０５のＡＰＩを介してＤｉａｍｅｔｅｒメッセージへのアクセスを可能にすることに役立つＤｉａｍｅｔｅｒメッセージの識別情報を格納する可能性がある。

さまざまな実施形態において、ＤＲＡ２００は、逆（ｉｎｖｅｒｓｅ）メッセージコンテキストの使用をサポートする可能性がある。そのような実施形態において、受信されたＤｉａｍｅｔｅｒメッセージからコマンドタイプを抽出すると、メッセージハンドラ２１０は、逆コマンドタイプも識別することができる。一部のそのような実施形態において、メッセージハンドラ２１０は、それぞれのメッセージコマンドの逆を識別するルックアップテーブルを実装し得る。例えば、受信されたＤｉａｍｅｔｅｒメッセージがＧｘ ＣＣＲであると判定すると、メッセージハンドラは、逆メッセージがＧｘ ＣＣＡであると判定する可能性がある。メッセージハンドラ２１０は、この情報もコンテキスト生成器２３０に渡すことができる。

逆メッセージタイプを受信すると、メッセージコンテキストモジュール２３２は、受信されたメッセージコンテキストオブジェクトに関連して上で説明されたのと同様にして逆メッセージコンテキストオブジェクトをインスタンス化することができる。関連要求サブモジュール２３４または関連応答サブモジュール２３５は、必要に応じて、新しいコンテキストオブジェクトをメッセージデータにやはり関連付けることができる。逆メッセージが要求メッセージである場合、関連要求モジュール２３４は、Ｄｉａｍｅｔｅｒスタック２０５に格納された既に処理された要求メッセージを識別し、上で説明されたのと同様にしてメッセージを新しいコンテキストオブジェクトに関連付けることができる。さまざまな実施形態において、応答メッセージを受信すると、Ｄｉａｍｅｔｅｒスタック２０５は、応答メッセージが対応する既に処理され、転送された要求メッセージを見つけることができる。Ｄｉａｍｅｔｅｒスタック２０５は、コンテキスト生成器２３０またはＤＲＡ２００のその他の構成要素による使用のためにＡＰＩを通じてこの関連する要求メッセージを提示することができる。前の要求メッセージを関連する要求コンテキストオブジェクトに関連付けることによって、規則エンジン２１５は、処理されている応答メッセージの送信を促した要求メッセージによって運ばれたＡＶＰにアクセスすることができる属性を与えられ得る。

一方、逆メッセージが応答メッセージであるとき、関連応答モジュール２３５は、例えば、ＡＰＩを介して、Ｄｉａｍｅｔｅｒスタック２０５が応答メッセージを構築することを要求することによって新しい応答メッセージを構築することができる。新しい応答メッセージは、全くの空である可能性があり、または受信されたＤｉａｍｅｔｅｒ要求メッセージからコピーされた少なくともいくつかの値を含む可能性がある。関連応答モジュール２３５は、受信メッセージモジュール２３３に関連して上で説明されたようにして新しいコンテキストオブジェクトを新しい応答メッセージに関連付けることができる。そのとき、関連する応答コンテキストオブジェクトは、新しい応答メッセージを修正することができるさまざまなアクションに規則エンジン２１５がアクセスすることができるようにする可能性がある。例えば、規則エンジンは、関連する応答コンテキストオブジェクトのアクションを利用して、応答メッセージの結果コード（ｒｅｓｕｌｔ−ｃｏｄｅ）ＡＶＰを設定する可能性があり、それによって、受信された要求を送信したデバイスに応答が返信されるべきであることをメッセージハンドラ２１０に示す。そのとき、メッセージハンドラ２１０は、受信された要求メッセージを任意のその他のデバイスに転送することを控える可能性もある。

上述のように、コンテキスト生成器２３０は、Ｄｉａｍｅｔｅｒメッセージを示さないその他のコンテキストオブジェクトを定義することができる可能性がある。そのようなコンテキストオブジェクトは、「計算コンテキスト（ｃｏｍｐｕｔａｔｉｏｎａｌ ｃｏｎｔｅｘｔ）」と呼ばれる可能性があり、コンテキストアーチファクトストレージ２４０のコンテキストアーチファクトによってやはり定義される可能性がある。例として、ルーティング決定コンテキストモジュール２３６は、ルーティング決定コンテキストオブジェクトをインスタンス化するように構成され得る。そのようなルーティング決定コンテキストは、それぞれの受信されたＤｉａｍｅｔｅｒメッセージに関して、受信されたメッセージに適用することができる可能性がある前になされたルーティングの決定を識別することができる。そのような前になされたルーティングの決定は、受信されたメッセージを既に処理されたメッセージと相互に関連付けるためのセッション識別子とともにルーティング決定データベース２５０に格納され得る。ルーティング決定データベース２５０は、そのようなルーティングの決定を格納することができる任意の機械可読媒体である可能性がある。したがって、ルーティング決定データベース２５０は、読み出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスクストレージ媒体、光学式ストレージ媒体、フラッシュメモリデバイス、および／または同様のストレージ媒体などの機械可読ストレージ媒体を含み得る。

計算コンテキストは、その他のＤＲＡ２００の機能性によってサポートされる可能性がある。例えば、ＤＲＡ２００は、ルーティング決定データベース２５０から古いエントリを周期的に削除するクリーンアップモジュール２５５を含み得る。一部の実施形態において、ルーティング決定コンテキストオブジェクトは、クリーンアップモジュール２５５と直接インタラクションしない可能性がある。その代わりに、クリーンアップ２５５は、ルーティング決定データベース２５０の内容を修正することによって間接的にルーティング決定コンテキストオブジェクトの挙動に影響を与えながら独立して動作する可能性がある。

計算コンテキストの別の例として、加入者レコードコンテキストモジュール２３８は、加入者レコードコンテキストオブジェクトを生成することができる。加入者レコードコンテキストオブジェクトは、加入者レコード取得器２６０などのその他のＤＲＡ２００の機能性を利用して、受信されたＤｉａｍｅｔｅｒメッセージに関する加入者レコードを取り出すことができる。加入者レコード取得器２６０は、Ｄｉａｍｅｔｅｒスタック２０５を介して加入者プロファイルリポジトリ（ＳＰＲ）と通信してＤｉａｍｅｔｅｒメッセージに関する加入者レコードを取り出すように構成されたハードウェアまたは機械可読ストレージ媒体上の実行可能命令を含み得る。そのような通信は、例えば、Ｓｐアプリケーションに応じて実行される可能性がある。加入者レコード取得器２６０を実装するさまざまな方法は、明らかであろう。加入者レコードのこの取り出しを通じて、加入者レコードコンテキストオブジェクトは、加入者レコードに規則エンジン２１５がアクセスできるようにする可能性がある。

規則ストレージ２２０、コンテキストアーチファクトストレージ２４０、メッセージ辞書２４５、およびルーティング決定データベース２５０は別々のデバイスとして示されているが、これらの構成要素のうちの１つまたは複数は、複数のストレージデバイスに存在する可能性があることに留意されたい。さらに、これらの構成要素のうちの１つまたは複数は、ストレージデバイスを共有する可能性がある。例えば、規則ストレージ、コンテキストアーチファクトストレージ２４０、メッセージ辞書２４５、およびルーティング決定データベース２５０は、すべて、同じハードディスクまたはフラッシュメモリデバイスの一部を指す可能性がある。

図３は、Ｄｉａｍｅｔｅｒメッセージを処理するための例示的な方法３００を示す。方法３００は、例えば、Ｄｉａｍｅｔｅｒスタック２０５、メッセージハンドラ２１０、規則エンジン２１５、またはコンテキスト生成器２３０などのＤＲＡ２００の構成要素によって実行される可能性がある。

方法３００は、ステップ３０５で始まり、ＤＲＡ２００が処理されるべきＤｉａｍｅｔｅｒメッセージを受信することができるステップ３１０に進む可能性がある。次に、ステップ３１５において、ＤＲＡ２００が、受信されたＤｉａｍｅｔｅｒメッセージからメッセージタイプを抽出する可能性がある。さまざまな実施形態において、メッセージタイプは、メッセージのアプリケーションおよびコマンドタイプによって定義される可能性がある。それから、ステップ３２０において、ＤＲＡが、抽出されたメッセージタイプを用いて、受信されたＤｉａｍｅｔｅｒメッセージをラップするメッセージコンテキストオブジェクトを確立する可能性がある。同様にして、ＤＲＡ２００が、ステップ３２５において、Ｄｉａｍｅｔｅｒメッセージの逆に関するメッセージコンテキストオブジェクトを確立する可能性がある。例えば、ＤＲＡ２００は、ルックアップテーブルを用いて、抽出されたメッセージタイプの逆メッセージタイプを識別し、逆メッセージタイプに基づいて新しいメッセージコンテキストを要求する可能性がある。

次いで、ステップ３３０において、ＤＲＡ２００が、ＤＲＡ２００がコンテキストアーチファクトを格納するかまたは規則エンジンが要求する可能性がある任意のその他の計算コンテキストオブジェクトを確立し始める可能性がある。例えば、ＤＲＡ２００は、ルーティング決定コンテキストオブジェクトおよび加入者レコードコンテキストオブジェクトを確立する可能性がある。適切なコンテキストオブジェクトが少なくともインスタンス化された後、方法３００は、ＤＲＡ２００が受信されたＤｉａｍｅｔｅｒメッセージを処理する際に評価すべき１つまたは複数の適切な規則の組を選択するステップ３３５に進む可能性がある。さまざまな実施形態において、ＤＲＡ２００は、それぞれのメッセージタイプに関する規則の組を格納することができる。一部の実施形態において、ＤＲＡ２００は、追加的にまたは代替的に、概して、すべてのＤｉａｍｅｔｅｒメッセージ、特定のアプリケーションのすべてのＤｉａｍｅｔｅｒメッセージ、またはＤｉａｍｅｔｅｒメッセージの別のサブセットに適用可能な規則の組を格納することができる。

適切な規則の組を識別した後、ＤＲＡ２００が、ステップ３４０において、選択された規則の組またはテーブルを、インスタンス化されたコンテキストに対して評価する可能性がある。個々の規則は、本明細書においては「コンテキストオブジェクトの参照」と呼ばれるコンテキストオブジェクトのさまざまな構成要素に対する参照を含む可能性がある。そのような構成要素は、コンテキストオブジェクトの属性またはアクションを構成する可能性がある。そのような参照を含む規則を評価するために、ＤＲＡは、参照された構成要素にアクセスすることができる。例えば、コンテキストオブジェクトの属性が、規則が適用可能であるかどうかを判定するための比較に使用される可能性があり、またはコンテキストオブジェクトのアクションが、規則の結果を適用する際に使用される可能性がある。コンテキストオブジェクトに対する参照のさまざまなさらなる用途は、明らかであろう。適切な規則の組を適用した後、ＤＲＡ２００が、ステップ３４５において、１つまたは複数のメッセージをその他のデバイスに送信する可能性がある。例えば、ＤＲＡは、修正される可能性があるＤｉａｍｅｔｅｒメッセージを別のデバイスに転送する可能性があり、または受信されたメッセージを送信したデバイスに応答を返送する可能性がある。方法３００は、次に、ステップ３５０で終了する可能性がある。

図４は、コンテキストアーチファクトを利用するための例示的な方法４００を示す。方法４００は、例えば、ユーザインターフェース２２５またはコンテキスト生成器２３０などのＤＲＡ２００の構成要素によって実行される可能性がある。方法４００は、例えば、システムが起動したとき、ユーザインターフェースによって要求されたとき、またはＤｉａｍｅｔｅｒメッセージを受信したときに実行される可能性がある。コンテキストアーチファクトは、計算コンテキストおよびメッセージコンテキストを定義するために使用され得ることが理解されるであろう。

方法４００は、ステップ４０５で始まり、ＤＲＡが処理すべきコンテキストアーチファクトに関して１つまたは複数のディレクトリを詳しく調べることができるステップ４１０に進む可能性がある。さまざまな実施形態において、ＤＲＡは、ストレージデバイスまたは特定のディレクトリで見つかったすべてのコンテキストアーチファクトを処理する可能性があり、または処理されるべきアーチファクトのリスト内の指定されたコンテキストアーチファクトのみを処理する可能性がある。コンテキストアーチファクトを見つけた後、方法４００は、ＤＲＡが規則エンジン、ユーザインターフェース、またはコンテキスト生成器による使用のためにシステムにコンテキストオブジェクトタイプを追加することができるステップ４１５に進む可能性がある。コンテキストアーチファクトが１つまたは複数のＪａｖａのクラスを定義する実施形態などのさまざまな実施形態において、ステップ４１５は、クラスによって定義されたコンテキストオブジェクトタイプを有するコンテキストオブジェクトのインスタンス化を可能にするためにコンテキストアーチファクトを解釈することを含む可能性がある。コンテキストアーチファクトを利用して新しいコンテキストオブジェクトタイプの使用を可能にするためのさまざまなその他の方法は、明らかであろう。

次に、ステップ４２０において、ＤＲＡが、コンテキストオブジェクトのコンテキストオブジェクトタイプに関する任意のメタデータを抽出する可能性がある。例えば、図５に関連して以下でより詳細に説明されるように、コンテキストアーチファクトは、コンテキストオブジェクトタイプ、属性、またはアクションのユーザが分かりやすい名前を指定する注釈またはタグを含む可能性がある。ＤＲＡは、ユーザインターフェースまたは規則エンジンによる使用のためにこのメタデータを格納する可能性がある。次に、ステップ４２５において、ＤＲＡが、さらなるコンテキストアーチファクトがまだ処理されずに残っているかどうかを判定する可能性がある。さらなるコンテキストアーチファクトが残っている場合、方法４００は、ステップ４１０にループして戻る可能性がある。そうでない場合、方法４００は、次に、ステップ４３０で終了する可能性がある。

上述のように、コンテキストアーチファクトは、ＤＲＡによる使用のためにさまざまなメタデータを指定する注釈またはタグを含む可能性がある。例えば、コンテキストオブジェクト「Ｆｌｏｏｂｅｒ」に関するコンテキストアーチファクトは、部分的に以下のように読める可能性がある。

上の例において、コンテキストアーチファクトは、３つの注釈を含む可能性がある。第１の注釈は、コンテキストオブジェクトタイプに関する名前（「Ｆｌｏｏｂｅｒ」）を指定する可能性があり、その他の２つの注釈は、コンテキストオブジェクトの構成要素に関する名前（「Ｆｌｏｏｂｅｒ−Ａｔｔｒｉｂｕｔｅ」および「Ｆｌｏｏｂｅｒ−Ａｃｔｉｏｎ」）を指定する可能性がある。このメタデータを用いて、ユーザインターフェースは、ユーザが関数ｇｅｔＦｌｏｏｂｅｒＶａｌｕｅ（）およびｄｏＦｌｏｏｂｅｒ（）への参照を含む規則を構築することを可能にし得る。そのような参照は、例えば、それぞれ、「Ｆｌｏｏｂｅｒ．Ｆｌｏｏｂｅｒ−Ａｔｔｒｉｂｕｔｅ」および「Ｆｌｏｏｂｅｒ．Ｆｌｏｏｂｅｒ−Ａｃｔｉｏｎ」である可能性がある。

図５は、コンテキストオブジェクトのためのメタデータを生成するための例示的な方法５００を示す。方法５００は、ユーザインターフェース２２５またはコンテキスト生成器２３０などのＤＲＡ２００の構成要素によって実行される可能性がある。方法５００は、例えば、システムの起動中、ユーザインターフェースによって要求されたとき、または規則エンジンによって要求されたときなどのさまざまな時間に実行される可能性がある。一部の実施形態において、方法５００は、方法４００のステップ４２０に対応する可能性があり、または方法３００のステップ３３０と一緒に実行される可能性がある。

方法５００は、ステップ５０５で始まり、ＤＲＡが処理すべきコンテキストアーチファクトを取り出すことができるステップ５１０に進む可能性がある。これは、アーチファクトストレージからアーチファクトを取り出すこと、または方法４００などの別の方法で既に取り出されたアーチファクトを単に識別することを含む可能性がある。次に、ステップ５１５において、ＤＲＡが、コンテキスト名の注釈に関してコンテキストアーチファクトを詳しく調べる可能性がある。例えば、ＤＲＡは、文字列「ＤＤＭＣｏｎｔｅｘｔ」、「ｌｏｃａｌｉｚｅｄＮａｍｅ」、または別の注釈を含む注釈を見つけるためにアーチファクトをトークン化するかまたはそれ以外の方法で解析する可能性がある。注釈を見つけた後、ＤＲＡは、ステップ５２０において、注釈に関連する名前を含む新しいメタデータのレコードを確立する可能性がある。上の例において、ＤＲＡは、名前「Ｆｌｏｏｂｅｒ」に関するメタデータのレコードを確立する可能性がある。ＤＲＡは、メタデータのレコードをアーチファクトによって定義されたコンテキストオブジェクトタイプに関連付ける可能性もある。

次に、ステップ５２５において、ＤＲＡが、さらなる注釈に関してコンテキストアーチファクトを詳しく調べる可能性がある。さまざまな実施形態において、ＤＲＡは、文字列「ＤＤＭ」、「ＤＤＭＲｕｌｅＡｔｔｒｉｂｕｔｅ」、または別の注釈を含む注釈を見つけるためにアーチファクトをトークン化するかまたはそれ以外の方法で解析する可能性がある。そのような属性を見つけることを試みた後、ＤＲＡが、ステップ５３０において、アーチファクトの終わりに到達したかどうかを判定する可能性がある。ＤＲＡがファイルの終わりに到達した場合、方法５００は、次に、ステップ５５０で終了する可能性がある。それ以外の場合、方法５００はステップ５３５に進む可能性がある。

ステップ５３５において、ＤＲＡが、注釈がコンテキストオブジェクトの属性またはアクションに対応するかどうかを判定する可能性がある。さまざまな実施形態においては、注釈自体が、注釈が属性またはアクションに当てはまるかどうかを指定する可能性がある。その他の実施形態において、ＤＲＡは、この判定を行うために以下の関数または変数を評価する可能性がある。例えば、ＤＲＡは、以下の関数が値を返す場合に、注釈が属性に対応し得ると判定する可能性がある。別の例として、ＤＲＡは、以下の関数がいかなる値も返さない場合に、注釈がアクションに対応し得ると判定する可能性がある。注釈が注釈に対応する場合、ＤＲＡが、ステップ５４０において、適切なクラスの関数に関連するメタデータのレコードに新しい属性を追加する可能性がある。上の例において、ＤＲＡは、関数ｇｅｔＦｌｏｏｂｅｒＶａｌｕｅ（）に関連してメタデータのレコードに属性名「Ｆｌｏｏｂｅｒ−Ａｔｔｒｉｂｕｔｅ」を追加する可能性がある。注釈がアクションに対応する場合、ＤＲＡが、ステップ５４０において、適切なクラスの関数に関連するメタデータのレコードに新しいアクションを追加する可能性がある。上の例において、ＤＲＡは、関数ｄｏＦｌｏｏｂｅｒ（）に関連してメタデータのレコードにアクション名「Ｆｌｏｏｂｅｒ−Ａｃｔｉｏｎ」を追加する可能性がある。方法５００は、次に、ステップ５４０かまたは５４５かのどちらかからステップ５２５にループして戻ることによってさらなる注釈に関するアーチファクトの分析を継続する可能性がある。

上述のように、コンテキストアーチファクトは、「ルーティング決定コンテキストオブジェクト」などの計算コンテキストを定義するために使用され得る。例えば、ルーティング決定コンテキストオブジェクトを定義するために、コンテキストアーチファクトは、部分的に以下のように読める可能性がある。

図６は、ルーティング決定コンテキストオブジェクトに関する例示的なクラス図６００を示す。クラス図６００は、上の例示的なコンテキストアーチファクトで定義されたルーティング決定コンテキストオブジェクトタイプに基づくコンテキストオブジェクトを示す可能性がある。コンテキストアーチファクトの注釈によって指定された構成要素名に関連する構成要素は、そのような構成要素名によって示される可能性がある。

示されたように、ルーティング決定コンテキストオブジェクト６２０は、コンテキストベースクラス６１０を拡張する可能性がある。コンテキストベースクラスは、基本的なコンテキストオブジェクトの機能性を含む可能性がある。例えば、コンテキストベースクラス６１０は、受信されたＤｉａｍｅｔｅｒメッセージを格納するためのｐｒｏｔｅｃｔｅｄ ｓｔｒｉｎｇ変数を含む可能性がある。追加的にまたは代替的に、コンテキストベースクラスは、受信されたＤｉａｍｅｔｅｒメッセージまたはその他のＤｉａｍｅｔｅｒメッセージを読むかまたは操作するためにＤｉａｍｅｔｅｒスタックのＡＰＩとインターフェースをとるための１つまたは複数の関数を提供する可能性がある。コンテキストベースクラスで提供するのに好適なさまざまなさらなるまたは代替的な属性およびアクションは、明らかであろう。

ルーティング決定コンテキストオブジェクト６２０は、１つまたは複数の属性またはアクションを追加することによってコンテキストベースクラス６１０を拡張する可能性がある。例えば、ルーティング決定コンテキストオブジェクト６２０は、ユーザインターフェースまたは規則エンジンによる使用のためのＢｏｏｌｅａｎ「Ｄｅｃｉｓｉｏｎ−Ｅｘｉｓｔｓ」属性を追加する可能性がある。Ｄｅｃｉｓｉｏｎ−Ｅｘｉｓｔｓ属性は、コンテキストアーチファクトの関数として定義される可能性があるが、値を返すので規則エンジンまたはユーザインターフェースによって属性と見なされ得ることが理解されるであろう。ルーティング決定コンテキストオブジェクトは、ルーティング決定レコード、およびそのようなルーティング決定レコードがフェッチされたかどうかについての指示をそれぞれ格納するための「ｒｏｕｔｉｎｇＤｅｃｉｓｉｏｎ」および「ｄｅｃｉｓｉｏｎＦｅｔｃｈｅｄ」などのｐｒｏｔｅｃｔｅｄ変数を含む可能性もある。

ルーティング決定レコードは、ＤＲＡによる使用のためのさまざまなデータを格納する可能性がある。例えば、ルーティング決定レコードは、ルーティング決定レコードが提示されたＤｉａｍｅｔｅｒメッセージに当てはまるかどうかを判定するための１つまたは複数の識別子を含む可能性がある。さまざまな実施形態において、これらの識別子は、「セッションバインディング識別子」（ＳＢＩ：Ｓｅｓｓｉｏｎ Ｂｉｎｄｉｎｇ Ｉｄｅｎｔｉｆｉｅｒ）を構成するためにまとめられ得る。ＳＢＩは、ＩＰｖ４アドレス、ＩＰｖ６アドレス、１つもしくは複数の加入者識別子、アクセスポイント名（ＡＰＮ）、またはＤｉａｍｅｔｅｒセッション識別子を含み得る。また、ルーティング決定レコードは、前のＤｉａｍｅｔｅｒメッセージがルーティングされたデバイスの識別情報をタイムスタンプと一緒に含む可能性がある。タイムスタンプは、例えば、クリーンアップ動作の一部としてルーティングレコードをメモリからいつ削除すべきかを決定する際に使用され得る。

ルーティング決定コンテキストオブジェクトは、いくつかのアクションをさらに含み得る。例えば、ルーティング決定コンテキストオブジェクト６２０は、「Ｕｐｄａｔｅ−Ｍｅｓｓａｇｅ−Ｗｉｔｈ−Ｄｅｓｔｉｎａｔｉｏｎ」アクションを含み得る。このアクションは、ルーティング決定レコードから送信先を抽出し、受信されたＤｉａｍｅｔｅｒメッセージのＤｅｓｔｉｎａｔｉｏｎ−Ｈｏｓｔ ＡＶＰに送信先識別子を挿入する可能性がある。別の例として、ルーティング決定コンテキストオブジェクト６２０は、ルーティング決定データベースに格納するために新しいルーティング決定レコードを生成することができる「Ｃｒｅａｔｅ−Ｎｅｗ−Ｒｏｕｔｉｎｇ−Ｄｅｃｉｓｉｏｎ」アクションを含み得る。例えば、規則は、Ｄｉａｍｅｔｅｒメッセージを新しいＤｅｓｔｉｎａｔｉｏｎ−Ｈｏｓｔで更新した後、「Ｃｒｅａｔｅ−Ｎｅｗ−Ｒｏｕｔｉｎｇ−Ｄｅｃｉｓｉｏｎ」アクションを呼び出す可能性がある。そのとき、「Ｃｒｅａｔｅ−Ｎｅｗ−Ｒｏｕｔｉｎｇ−Ｄｅｃｉｓｉｏｎ」アクションは、ＳＢＩおよび送信先ホストを抽出して、現在のタイムスタンプを持つ新しいレコードを生成することができる。別の例として、「Ｕｐｄａｔｅ−Ｔｉｍｅｓｔａｍｐ」アクションは、ルーティング決定レコードのクリーンアップを遅らせるために、ルーティング決定レコードの古いタイムスタンプを現在のタイムスタンプで上書きする可能性がある。ルーティング決定コンテキストオブジェクトに含まれる可能性があるさらなるアクション（図示せず）は、処理されているメッセージに関連するセッションに関するルーティング決定レコードを削除するためのアクション、または現在のメッセージに関連するすべてのルーティング決定レコード（例えば、同じＩＰに関するすべてのセッション）を削除するアクションを含み得る。

上述のさまざまな属性およびアクションは、ルーティングの決定の存在に依存する可能性がある。したがって、ルーティング決定コンテキストオブジェクト６２０は、受信されたメッセージからＳＢＩを抽出し、ＳＢＩに一致するルーティング決定データベース内のルーティング決定レコードを見つけることを試みることができるｐｒｏｔｅｃｔｅｄ「ＦｅｔｃｈＤｅｃｉｓｉｏｎ」関数も含む可能性がある。さまざまな実施形態において、「ＦｅｔｃｈＤｅｃｉｓｉｏｎ」関数は、ルーティング決定コンテキストオブジェクトがルーティング決定コンテキストオブジェクトのクラスコンストラクタによるなどして初期化されるときに呼び出される可能性がある。その他の実施形態において、ルーティング決定コンテキストオブジェクト６２０は、ルーティング決定レコードが使用されるべきであるような時間まで「ＦｅｔｃｈＤｅｃｉｓｉｏｎ」を呼び出さない可能性がある。例えば、「Ｕｐｄａｔｅ−Ｍｅｓｓａｇｅ−Ｗｉｔｈ−Ｄｅｓｔｉｎａｔｉｏｎ」、「Ｄｅｃｉｓｉｏｎ−Ｅｘｉｓｔｓ」、および「Ｕｐｄａｔｅ−Ｔｉｍｅｓｔａｍｐ」構成要素が、それぞれ、「ｄｅｃｉｓｉｏｎＦｅｔｃｈｅｄ」変数が偽であるときに「ＦｅｔｃｈＤｅｃｉｓｉｏｎ」を呼び出す可能性がある。

図７は、前のルーティングの決定を取り出すための例示的な方法７００を示す。方法７００は、ルーティング決定コンテキストオブジェクト６２０の「ＦｅｔｃｈＤｅｃｉｓｉｏｎ」関数に対応する可能性がある。方法７００は、例えば、コンテキスト生成器２３０などのＤＲＡの構成要素によって実行される可能性がある。

方法７００は、ステップ７０５で始まり、ステップ７１０に進む可能性があり、ステップ７１０において、ＤＲＡが、受信されたＤｉａｍｅｔｅｒメッセージからＳＢＩを抽出することができる。上述のように、ＳＢＩは、複数の識別子で構成される可能性があり、それらの識別子の一部は、Ｄｉａｍｅｔｅｒメッセージに存在する可能性がある。次に、ステップ７１５において、ＤＲＡが、ＳＢＩの少なくとも一部に一致するレコードに関してルーティング決定データベースを検索する可能性がある。ＳＢＩの一致に基づいて、ルーティング決定コンテキストオブジェクトは、前のＤｉａｍｅｔｅｒメッセージが受信されたＤｉａｍｅｔｅｒメッセージとは異なるアプリケーションまたはコマンドに応じて送信されたときでさえも、前のＤｉａｍｅｔｅｒメッセージに関するルーティングの決定を見つけることができることが理解されるであろう。例えば、ＤＲＡは、Ｒｘ ＡＡＲを受信し、ＳＢＩに基づいて、Ｇｘ ＣＣＲに関して前になされたルーティングの決定を見つける可能性がある。

次に、ステップ７２０において、ＤＲＡが、ルーティング決定レコードが見つかったかどうかを判定する可能性がある。そのようなレコードが見つかった場合、方法７００は、ステップ７２５に進む可能性がある。ステップ７２５において、ＤＲＡが、例えば、レコードをルーティング決定コンテキストオブジェクトの変数にコピーするか、またはそうでなければルーティング決定レコードを読むもしくは修正するルーティング決定コンテキストオブジェクトの関数を有効にすることによってルーティング決定コンテキストオブジェクトを見つかったルーティング決定レコードに関連付ける可能性がある。次いで、ステップ７３０において、ＤＲＡが、ルーティング決定コンテキストオブジェクトの「Ｄｅｃｉｓｉｏｎ−Ｅｘｉｓｔｓ」属性を「真」に設定する可能性がある。

一方、ＤＲＡが一致するルーティング決定レコードを見つけることができない場合、方法７００は、代わりにステップ７２０からステップ７３５に進む可能性がある。ステップ７３５において、ＤＲＡが、ルーティング決定コンテキストオブジェクトの「Ｄｅｃｉｓｉｏｎ−Ｅｘｉｓｔｓ」属性を「偽」に設定する可能性がある。方法７００は、ステップ７３０かまたは７３５かのどちらかからステップ７４０に進む可能性がある。ステップ７４０において、ＤＲＡが、「ｄｅｃｉｓｉｏｎＦｅｔｃｈｅｄ」変数を「真」に設定する可能性がある。ルーティング決定コンテキストオブジェクトは、その後、「ｄｅｃｉｓｉｏｎＦｅｔｃｈｅｄ」の「真」値に基づいて、方法７００を再び実行することを避ける可能性がある。

上述のように、さまざまな実施形態において、ルーティング決定データベース２５０に格納されたルーティング決定レコードは、それらのルーティング決定レコードに関連するタイムスタンプに基づいて周期的にクリーンアップされる可能性がある。例えば、クリーンアップモジュール２５５は、それぞれのルーティング決定レコードのタイムスタンプを調べることによってルーティング決定データベース２５０を周期的に監査する可能性がある。クリーンアップモジュール２５５は、ルーティングレコードに関する「生存時間」の値を用いて構成され、この値および現在の時間に基づいて、各レコードが予め構成された生存時間を超えたかどうかを判定する可能性がある。そうである場合、クリーンアップモジュール２５５は、ルーティング決定データベース２５０からレコードを削除する可能性がある。

計算コンテキストの別の例として、コンテキストアーチファクトは、「加入者レコードコンテキストオブジェクト」を定義する可能性がある。例えば、加入者レコードコンテキストオブジェクトを定義するために、コンテキストアーチファクトは、部分的に以下のように読める可能性がある。

上記の例において示されたように、その他のクラスに含まれるクラスが、注釈を含む可能性もある。例えば、［ｓｕｂＣｏｎｔｅｘｔ］クラスは、「Ｓｕｂｉｄｓ」クラスによって定義されたオブジェクトを含む可能性がある。「Ｓｕｂｉｄｓ」クラスは、アクションのいくつかの属性に関するいくつかの注釈を含む可能性がある。さらに、「Ｓｕｂｉｄｓ」クラス自体が、クラス定義の前に「Ｓｕｂｓｃｒｉｂｅｒ−ＩＤｓ」などの構成要素名によって注釈を付けられる可能性がある。さまざまな代替的な構成は、明らかであろう。例えば、「Ｓｕｂｉｄｓ」クラスに関する注釈が、「ｓｕｂｓｃｒｉｂｅｒＩＤｓ」オブジェクトの定義の前に、「ｓｕｂＣｏｎｔｅｘｔ」クラスの定義内で代わりに見つけられる可能性がある。

図８は、加入者レコードコンテキストオブジェクトに関する例示的なクラス図８００を示す。クラス図８００は、上の例示的なコンテキストアーチファクトで定義された加入者レコードコンテキストオブジェクトタイプに基づくコンテキストオブジェクトを示す可能性がある。コンテキストアーチファクトの注釈によって指定された構成要素名に関連する構成要素は、そのような構成要素名によって示される可能性がある。

示されたように、加入者レコードコンテキストオブジェクト８２０は、コンテキストベースクラス８１０を拡張する可能性がある。さまざまなその他の継承が使用され得ることが、理解されるであろう。例えば、加入者レコードコンテキストオブジェクト８２０は、ＬＤＡＰサーバまたはデータベースとインターフェースをとるための基本的な機能性を実装するＣｏｍｍｏｎＬＤＡＰＣｏｎｔｅｘｔオブジェクト（図示せず）を拡張する可能性がある。そしてまた、そのようなＣｏｍｍｏｎＬＤＡＰＣｏｎｔｅｘｔオブジェクトは、コンテキストベースクラス８１０を拡張する可能性がある。クラスおよび継承のさまざまなその他の構成は、明らかであろう。

コンテキストベースクラスは、基本的なコンテキストオブジェクトの機能性を含む可能性がある。例えば、コンテキストベースクラス８１０は、受信されたＤｉａｍｅｔｅｒメッセージを格納するためのｐｒｏｔｅｃｔｅｄ ｓｔｒｉｎｇ変数を含む可能性がある。追加的にまたは代替的に、コンテキストベースクラスは、受信されたＤｉａｍｅｔｅｒメッセージまたはその他のＤｉａｍｅｔｅｒメッセージを読むかまたは操作するためにＤｉａｍｅｔｅｒスタックのＡＰＩとインターフェースをとるための１つまたは複数の関数を提供する可能性がある。コンテキストベースクラスで提供するのに好適なさまざまなさらなるまたは代替的な属性およびアクションは、明らかであろう。

加入者レコードコンテキストオブジェクト８２０は、１つまたは複数の属性またはアクションを追加することによってコンテキストベースクラス８１０を拡張する可能性がある。例えば、加入者レコードコンテキストオブジェクト８２０は、加入者レコード、およびそのような加入者レコードがフェッチされたかどうかについての指示をそれぞれ格納するための「ｓｕｂｓｃｒｉｂｅｒＲｅｃｏｒｄ」および「ｒｅｃｏｒｄＦｅｔｃｈｅｄ」などのｐｒｏｔｅｃｔｅｄ変数を含む可能性がある。

理解されるであろうように、加入者レコードは、ＤＲＡに関連して外部デバイスに格納される可能性がある。加入者レコードは、加入者に関連するさまざまなデータを格納する可能性がある。例えば、加入者レコードは、１つもしくは複数の加入者ｉｄ、保証されるビットレート、最大ビットレート、合計最大ビットレート（ａｇｇｒｅｇａｔｅ ｍａｘｉｍｕｍ ｂｉｔｒａｔｅ）、または課金基準を格納する可能性がある。

加入者レコードコンテキストオブジェクト８２０などの計算コンテキストオブジェクトは、コンテキストアーチファクトによってやはり定義される１つまたは複数のその他のオブジェクトを含む可能性がある。例えば、加入者レコードコンテキストオブジェクト８２０は、加入者識別子を格納する加入者レコードの１つまたは複数のフィールドにアクセスするために有用な属性またはアクションを含むＳｕｂｓｃｒｉｂｅｒ−ＩＤｓオブジェクトを含む可能性がある。Ｓｕｂｓｃｒｉｂｅｒ−ＩＤｓオブジェクト８３０は、加入者レコードから加入者識別子のリストを返すことができる「ｇｅｔ」属性を含む可能性がある。さまざまな実施形態において、規則は、「ｇｅｔ」属性自体を指定せずに「ｇｅｔ」属性にアクセスするためにオブジェクト名を単に参照する可能性がある。例えば、規則は、「Ｓｕｂｓｃｒｉｂｅｒ Ｒｅｃｏｒｄ．Ｓｕｂｓｃｒｉｂｅｒ−ＩＤｓ．ｇｅｔ」の代わりに、加入者識別子のリストを取り出すために「Ｓｕｂｓｃｒｉｂｅｒ Ｒｅｃｏｒｄ．Ｓｕｂｓｃｒｉｂｅｒ−ＩＤｓ」を参照する可能性がある。また、Ｓｕｂｓｃｒｉｂｅｒ−ＩＤｓオブジェクト８３０は、加入者レコードの加入者識別子を追加、削除、および修正するための「ａｄｄ」、「ｒｅｍｏｖｅ」、および「ｓｅｔ」アクションを含む可能性がある。一部のアクションは、１つまたは複数のパラメータを受け入れる可能性がある。例えば、規則は、加入者レコードに新しい加入者識別子「ｆｏｏ」を追加するために「Ｓｕｂｓｃｒｉｂｅｒ Ｒｅｃｏｒｄ．Ｓｕｂｓｃｒｉｂｅｒ−ＩＤｓ．ａｄｄ ｆｏｏ」を呼び出す可能性がある。加入者レコードコンテキストオブジェクト８２０は、Ｓｕｂｓｃｒｉｂｅｒ−ＩＤｓ８３０と同様の多数のさらなるオブジェクトを含み得ることが理解されるであろう。例えば、加入者レコードコンテキストオブジェクト８２０は、保証ビットレートオブジェクトまたはサービス品質（ＱｏＳ）オブジェクト（図示せず）を含む可能性がある。

加入者レコードコンテキストオブジェクト８２０に関連して説明されたさまざまな属性およびアクションは、加入者レコードの存在に依存する可能性がある。したがって、加入者レコードコンテキストオブジェクト８２０は、受信されたメッセージから１つまたは複数の加入者識別子を抽出し、加入者識別子に一致するＳＰＲの加入者レコードを要求することを試みることができるｐｒｏｔｅｃｔｅｄ「ＦｅｔｃｈＲｅｃｏｒｄ」関数を含む可能性がある。さまざまな実施形態において、「ＦｅｔｃｈＲｅｃｏｒｄ」関数は、加入者レコードコンテキストオブジェクトがルーティング決定コンテキストオブジェクトのクラスコンストラクタによるなどして初期化されるときに呼び出される可能性がある。その他の実施形態において、加入者レコードコンテキストオブジェクト８２０は、加入者レコードが使用されるべきであるような時間まで「ＦｅｔｃｈＲｅｃｏｒｄ」を呼び出さない可能性がある。例えば、「ｇｅｔ」、「ａｄｄ」、「ｒｅｍｏｖｅ」、および「ｓｅｔ」構成要素が、それぞれ、「ｒｅｃｏｒｄＦｅｔｃｈｅｄ」変数が偽であるときに「ＦｅｔｃｈＲｅｃｏｒｄ」を呼び出す可能性がある。

ルーティングレコードコンテキストオブジェクト６２０または加入者レコードコンテキストオブジェクト８２０のさまざまなアクションまたは関数は、後の使用のために格納されるべきレコードを修正する可能性がある。例えば、加入者レコードコンテキストオブジェクト８２０は、加入者レコードに加入者識別子を追加する可能性がある。さまざまな実施形態において、ルーティングレコードコンテキストオブジェクト６２０または加入者レコードコンテキストオブジェクト８２０は、それぞれのコンテキストオブジェクトのローカルのレコードを格納する変数を修正し、後でレコードをコミットしてストレージに戻す可能性がある。例えば、ルーティングレコードコンテキストオブジェクト６２０または加入者レコードコンテキストオブジェクト８２０のデストラクタ関数は、それぞれのレコードを後で使用するために適切なストレージデバイスに送信する可能性がある。

図９は、加入者レコードを取り出すための例示的な方法９００を示す。方法９００は、加入者レコードコンテキストオブジェクト８２０の「ＦｅｔｃｈＲｅｃｏｒｄ」関数に対応する可能性がある。方法９００は、例えば、コンテキスト生成器２３０などのＤＲＡの構成要素によって実行される可能性がある。

方法９００は、ステップ９０５で始まり、ＤＲＡが受信されたＤｉａｍｅｔｅｒメッセージによって運ばれた１つまたは複数の加入者識別子を識別することができるステップ９１０に進む可能性がある。例えば、ＤＲＡは、ＤｉａｍｅｔｅｒメッセージからＩＰｖ４アドレス、ＩＰｖ６アドレス、およびＡＰＮを抽出する可能性がある。代替的に、加入者レコードコンテキストオブジェクトが、インスタンス化されると、Ｄｉａｍｅｔｅｒメッセージから抽出された加入者識別子を既に格納している可能性がある。次に、ステップ９１５において、ＤＲＡが、ＳＰＲなどの別のデバイスからの加入者レコードを要求する可能性がある。そのようにする際に、加入者レコードコンテキストオブジェクトの関数が、ＤＲＡのその他の構成要素によってやはり使用される加入者レコード取得器モジュール２６０などのＤＲＡのその他の機能性を呼び出す可能性がある。ステップ９１５で送信された要求に応答して加入者レコードを受信した後、ＤＲＡが、ステップ９２０において、加入者レコードを加入者レコードコンテキストオブジェクトに関連付ける可能性がある。例えば、ＤＲＡは、加入者レコードコンテキストオブジェクトの１つまたは複数の変数の中に加入者レコードを格納する可能性がある。それから、ステップ９２５において、ＤＲＡが、加入者レコードコンテキストオブジェクトが加入者レコードを再フェッチしようとすることを防止するために加入者レコードコンテキストオブジェクトのｒｅｃｏｒｄＦｅｔｃｈｅｄ変数を「真」値に設定する可能性がある。そして、方法９００は、次に、ステップ９３０で終了する可能性がある。

その他のコンテキストオブジェクトと同様に、ユーザは、ルーティング決定コンテキストオブジェクトおよび加入者レコードコンテキストオブジェクトの属性およびアクションへの参照を有するさまざまな規則を定義することができる。例えば、ユーザは、以下の擬似コードの規則の定義を与えることによって規則の組を指定する可能性がある。

上記の擬似コードを受信すると、ＤＲＡは、ランタイムでより速くまたは効率的に評価され得る形態で規則の組を生成する可能性がある。ユーザが規則または規則の組を定義することを可能にするためのさまざまな代替的な方法は、明らかであろう。

図１０は、例示的な規則の組１０００を示す。規則の組１０００は、ＤＲＡ２００の規則ストレージ２２０などの規則ストレージに格納される可能性がある。さまざまな実施形態において、規則の組１０００は、示されるように、二分決定木として格納される可能性がある。さまざまな代替的な構成が規則の組を格納するために使用され得ることは、明らかであろう。例えば、規則の組１０００は、規則が適用可能であるかどうかを判定するための評価のための基準フィールドと、規則が適用可能であるときに行われるべきアクションを格納する結果フィールドとをそれぞれが含む複数のレコードとして格納される可能性がある。さらに、規則の組１０００は、例えば、規則ストレージ２２０に格納されたデータベースのテーブルとして格納される可能性がある。代替的に、規則の組１０００は、一連のリンクされたリスト、配列、または同様のデータ構造である可能性がある。したがって、規則の組１０００が基礎をなすデータの抽象化である可能性があり、このデータの格納に好適な任意のデータ構造が使用され得ることは明らかであるに違いない。

規則の組１０００は、Ｇｘ ＣＣＲ Ｄｉａｍｅｔｅｒメッセージに適用することができる可能性がある。規則の組１０００は、上の例などのユーザによって与えられた擬似コードに基づいて生成された可能性がある。ＤＲＡは、いくつかの異なるメッセージタイプのために別々のメッセージタイプに固有の規則の組（図示せず）を格納する可能性がある。規則の組１０００は、基準ノード１０１０、１０３０などの基準ノードと、結果ノード１０２０、１０４０、１０５０などの結果ノードとを含む可能性がある。規則の組１０００が例示的であり、さまざまな実施形態が示された規則の組１０００よりも複雑な規則の組（図示せず）を含み得ることは、明らかであろう。

基準ノードは、規則エンジンによって評価されるべき条件を提示する可能性がある。評価に基づいて、規則エンジンは、評価すべき別の基準ノードまたは結果ノードを選択することができる。例として、基準ノード１０１０は、条件「Ｒｏｕｔｉｎｇ Ｄｅｃｉｓｉｏｎ．Ｄｅｃｉｓｉｏｎ−Ｅｘｉｓｔｓ」を格納する可能性がある。基準ノード１０１０を評価すると、規則エンジンは、条件が真であるかまたは偽であるかを判定する可能性がある。例えば、規則エンジンは、「Ｒｏｕｔｉｎｇ Ｄｅｃｉｓｉｏｎ」コンテキストオブジェクトから「Ｄｅｃｉｓｉｏｎ−Ｅｘｉｓｔｓ」属性を読む可能性がある。そのようにする際に、Ｒｏｕｔｉｎｇ Ｄｅｃｉｓｉｏｎコンテキストオブジェクトは、受信されたＤｉａｍｅｔｅｒメッセージに基づいてルーティング決定レコードを取り出す可能性がある。Ｄｅｃｉｓｉｏｎ−Ｅｘｉｓｔｓ属性が真である場合、規則エンジンは、結果ノード１０２０の評価に移る可能性がある。Ｄｅｃｉｓｉｏｎ−Ｅｘｉｓｔｓ属性が偽である場合、規則エンジンは、基準ノード１０３０の評価に移る可能性がある。

結果ノードは、規則エンジンによって実行されるべき１つまたは複数のアクションを提示する可能性がある。そのようなアクションは、例えば、Ｄｉａｍｅｔｅｒメッセージを修正すること、またはＤｉａｍｅｔｅｒメッセージを特定のデバイスに送信することを含む可能性がある。例として、結果ノード１０２０は、規則エンジンがＲｏｕｔｉｎｇ Ｄｅｃｉｓｉｏｎコンテキストオブジェクトの２つのアクション、すなわち、「Ｕｐｄａｔｅ−Ｍｅｓｓａｇｅ−Ｗｉｔｈ−Ｄｅｓｔｉｎａｔｉｏｎ」および「Ｕｐｄａｔｅ−Ｔｉｍｅｓｔａｍｐ」アクションにアクセスすべきであることを示す可能性がある。それから、規則の組１０００を評価する規則エンジンが、終了される可能性がある。

基準ノード１０３０は、条件「Ｓｕｂｓｃｒｉｂｅｒ Ｒｅｃｏｒｄ．Ｓｕｂｓｃｒｉｂｅｒ−ＩＤｓが部分文字列ｆｌｏｏｂｅｒを含む」を含めることによって加入者レコードコンテキストオブジェクトを呼び出す条件を含む可能性がある。基準ノード１０３０を評価する際、規則エンジンは、「Ｓｕｂｓｃｒｉｂｅｒ Ｒｅｃｏｒｄ」コンテキストオブジェクトの「Ｓｕｂｓｃｒｉｂｅｒ−ＩＤｓ」属性にアクセスし、次いで、返されたデータが部分文字列「ｆｌｏｏｂｅｒ」を含むかどうかを判定することができる。部分文字列が存在する場合、規則エンジンは、結果ノード１０４０の評価に移る可能性がある。そうでない場合、規則エンジンは、結果ノード１０５０の評価に移る可能性がある。

結果ノード１０４０は、異なる種類のコンテキストオブジェクトへの参照を含む可能性がある。例えば、結果ノード１０４０は、規則エンジンが、受信されたＤｉａｍｅｔｅｒメッセージのＤｅｓｔｉｎａｔｉｏｎ−ＨｏｓｔおよびＤｅｓｔｉｎａｔｉｏｎ−Ｒｅａｌｍ ＡＶＰを更新するためにＧｘ ＣＣＲコンテキストオブジェクトのａｄｄアクションおよびｓｅｔアクションにアクセスすべきであることを指定する可能性がある。結果ノード１０４０は、規則エンジンが、その他のＤｉａｍｅｔｅｒメッセージに関連した将来の使用のためにＤｅｓｔｉｎａｔｉｏｎ−ＨｏｓｔおよびＤｅｓｔｉｎａｔｉｏｎ−Ｒｅａｌｍの値を保存するために「Ｒｏｕｔｉｎｇ Ｄｅｃｉｓｉｏｎ」コンテキストオブジェクトの「Ｃｒｅａｔｅ−Ｎｅｗ−Ｒｏｕｔｉｎｇ−Ｄｅｃｉｓｉｏｎ」アクションにアクセスすべきであることを指定する可能性もある。結果ノード１０５０は、規則エンジンが、「Ｓｕｂｓｃｒｉｂｅｒ Ｒｅｃｏｒｄ」コンテキストオブジェクトの「ａｄｄ」アクションにアクセスすることによって加入者レコードに新しい加入者識別子「ｆｌｏｏｂｅｒ」を追加すべきであることを指定する可能性がある。

以上により、さまざまな実施形態は、ＤｉａｍｅｔｅｒルーティングエージェントにおけるさまざまなＤｉａｍｅｔｅｒメッセージの堅牢で動的な処理を可能にする。特に、コンテキストアーチファクトに基づいて計算コンテキストオブジェクトを生成することによって、ＤＲＡは、さまざまなＤｉａｍｅｔｅｒメッセージの処理においてしたがわれるべき複雑な挙動を指定する際にユーザを楽にすることができる。例えば、ユーザは、前のルーティングの決定または加入者レコードの内容に基づいて挙動を決めることができる。さらに、ユーザは、さらなる種類のコンテキストオブジェクトを指定し得る新しいコンテキストアーチファクトを追加することによって機能性を拡張することができる。さまざまなさらなる利益は、以上の開示から明らかであろう。

本発明のさまざまな例示的な実施形態がハードウェアまたはファームウェアで実装され得ることは、上述の説明から明らかであるに違いない。さらに、さまざまな例示的な実施形態は、本明細書において詳細に説明された動作を実行するために少なくとも１つのプロセッサによって読まれ、実行され得る、機械可読ストレージ媒体に格納された命令として実装される可能性がある。機械可読ストレージ媒体は、パーソナルもしくはラップトップコンピュータ、サーバ、またはその他のコンピューティングデバイスなどの機械によって読まれ得る形態で情報を格納するための任意のメカニズムを含む可能性がある。したがって、有形の非一時的機械可読ストレージ媒体は、読み出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスクストレージ媒体、光学式ストレージ媒体、フラッシュメモリデバイス、および同様のストレージ媒体を含む可能性がある。

本明細書の任意のブロック図が本発明の原理を具現化する例示的な回路の概念図を示すことは、当業者に理解されるに違いない。同様に、任意のフローチャート、流れ図、状態遷移図、擬似コードなどは、機械可読媒体内に実質的に表現され、したがって、コンピュータまたはプロセッサによって、そのようなコンピュータまたはプロセッサが明示的に図示されているか否かに関わらず実行され得るさまざまなプロセスを表すことが理解されるであろう。

さまざまな例示的な実施形態がそれらの実施形態の特定の例示的な態様を特に参照して詳細に説明されたが、本発明は、その他の実施形態が可能であり、本発明の詳細はさまざまな明らかな観点で修正可能であることを理解されたい。当業者には容易に分かるように、変更および修正は、本発明の精神および範囲内にとどまったまま実現される可能性がある。したがって、上述の開示、説明、および図は、例示のみを目的とするものであり、本発明を全く限定せず、本発明は、特許請求の範囲によってのみ定義される。

Claims (14)

1. Ｄｉａｍｅｔｅｒメッセージを処理するためにＤｉａｍｅｔｅｒルーティングエージェント（ＤＲＡ）によって実行される方法であって、
   ＤＲＡで送信元デバイスからＤｉａｍｅｔｅｒメッセージを受信するステップ（３１０）と、
   Ｄｉａｍｅｔｅｒメッセージを受信するステップに応答してルーティング決定コンテキストオブジェクトを確立するステップ（３３０、７００）であって、ルーティング決定コンテキストオブジェクトが、前のメッセージを受信するために選択された送信先デバイスに関連する、確立するステップ（３３０、７００）と、
   コンテキストオブジェクトの参照を含む規則を評価するステップ（３４０）であって、評価が、コンテキストオブジェクトの参照に基づいてルーティング決定コンテキストオブジェクトにアクセスすることを含む、評価するステップ（３４０）と、
   規則の評価に基づいてメッセージを送信するステップ（３４５）とを含む、方法。
2. 規則の評価に基づいてメッセージを送信するステップ（３４５）が、Ｄｉａｍｅｔｅｒメッセージを送信先デバイスに送信するステップを含む、請求項１に記載の方法。
3. Ｄｉａｍｅｔｅｒメッセージが、第１のＤｉａｍｅｔｅｒアプリケーションに関連し、前のメッセージが、第２のＤｉａｍｅｔｅｒアプリケーションに関連する、請求項１から２のいずれかに記載の方法。
4. Ｄｉａｍｅｔｅｒメッセージを受信するステップの前に、
   ＤＲＡで前のメッセージを受信するステップ（３１０）と、
   前のメッセージが送信先デバイスにルーティングされるべきであると決定するステップ（３４０）と、
   送信先デバイスに前のメッセージを送信するステップ（３４５）と、
   前のメッセージおよび送信先デバイスの識別情報をルーティングの決定として格納するステップとをさらに含む、請求項１から３のいずれか一項に記載の方法。
5. ルーティング決定コンテキストオブジェクトにアクセスすることが、ルーティングの決定に関連するタイムスタンプを更新することを含む、請求項４に記載の方法。
6. ルーティングの決定が、ルーティングの決定に関連するタイムスタンプに基づいて削除されるべきであると判定するステップと、
   ＤＲＡのメモリからルーティングの決定を削除するステップとをさらに含む、請求項４から５のいずれかに記載の方法。
7. ルーティング決定コンテキストオブジェクトを確立するステップおよびルーティング決定コンテキストオブジェクトにアクセスすることのうちの少なくとも一方が、
   Ｄｉａｍｅｔｅｒメッセージから少なくとも１つの識別情報を抽出するステップ（７１０）と、
   少なくとも１つの識別情報が前のメッセージに対応すると判定するステップ（７２０）とを含む、請求項１から６のいずれか一項に記載の方法。
8. Ｄｉａｍｅｔｅｒメッセージを処理するためのＤｉａｍｅｔｅｒルーティングエージェント（ＤＲＡ）であって、
   コンテキストオブジェクトの参照を含む規則を格納するように構成された規則ストレージ（２２０）と、
   前のルーティングの決定を格納するように構成されたルーティング決定データベース（２５０）であって、前のルーティングの決定が、前のメッセージのために選択された送信先デバイスの識別情報を含む、ルーティング決定データベース（２５０）と、
   送信元デバイスからＤｉａｍｅｔｅｒメッセージを受信するように構成されたＤｉａｍｅｔｅｒスタック（２０５）と、
   Ｄｉａｍｅｔｅｒメッセージを受信することに基づいてルーティング決定コンテキストオブジェクトを確立するように構成されたコンテキスト生成器（２３０）であって、ルーティング決定コンテキストオブジェクトが、前のルーティングの決定に関連する、コンテキスト生成器（２３０）と、
   規則を評価するように構成された規則エンジン（２１５）であって、評価が、コンテキストオブジェクトの参照に基づいてルーティング決定コンテキストオブジェクトにアクセスすることを含む、規則エンジン（２１５）と、
   Ｄｉａｍｅｔｅｒスタックを介して規則の評価に基づいてメッセージを送信するように構成されたメッセージハンドラ（２１０）とを含む、Ｄｉａｍｅｔｅｒルーティングエージェント（ＤＲＡ）。
9. 規則の評価に基づいてメッセージを送信する際に、メッセージハンドラ（２１０）が、送信先デバイスにＤｉａｍｅｔｅｒメッセージを送信するように構成される、請求項８に記載のＤＲＡ。
10. Ｄｉａｍｅｔｅｒメッセージが、第１のＤｉａｍｅｔｅｒアプリケーションに関連し、前のメッセージが、第２のＤｉａｍｅｔｅｒアプリケーションに関連する、請求項８から９のいずれかに記載のＤＲＡ。
11. Ｄｉａｍｅｔｅｒスタック（２０５）が、Ｄｉａｍｅｔｅｒメッセージを受信する前に前のメッセージを受信するようにさらに構成され、
    規則エンジン（２１５）が、前のメッセージが送信先デバイスにルーティングされるべきであると決定するようにさらに構成され、
    ルーティング決定コンテキストオブジェクト（６２０）が、規則エンジンによるアクセスに基づいて、前のメッセージおよび送信先デバイスの識別情報をルーティングの決定として格納するように構成される、請求項８から１０のいずれか一項に記載のＤＲＡ。
12. ルーティング決定コンテキストオブジェクト（６２０）が、規則エンジンによるアクセスに基づいて、ルーティングの決定に関連するタイムスタンプを更新するように構成される、請求項１１に記載のＤＲＡ。
13. ルーティングの決定が、ルーティングの決定に関連するタイムスタンプに基づいて削除されるべきであると判定し、
    ＤＲＡのメモリからルーティングの決定を削除するように構成されたクリーンアップモジュール（２５５）をさらに含む、請求項１１から１２のいずれかに記載のＤＲＡ。
14. ルーティング決定コンテキストオブジェクト（６２０）が、
    Ｄｉａｍｅｔｅｒメッセージから少なくとも１つの識別情報を抽出し、
    少なくとも１つの識別情報が前のメッセージに対応すると判定するように構成される、請求項８から１３のいずれか一項に記載のＤＲＡ。

Images