JP5895101B2 - Ｄｉａｍｅｔｅｒルーティングエージェントの規則の組の編成 - Google Patents

Description

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

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

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

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

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

さまざまな例示的な実施形態は、Ｄｉａｍｅｔｅｒメッセージを処理するためにＤｉａｍｅｔｅｒルーティングエージェント（ＤＲＡ）によって実行される方法であって、以下、すなわち、ＤＲＡで第１の送信元デバイスから第１のＤｉａｍｅｔｅｒメッセージを受信するステップと、第１のＤｉａｍｅｔｅｒメッセージに関連する第１のメッセージタイプを判定するステップと、規則の複数の組のうちの規則の第１の組が第１のメッセージタイプに関連すると識別するステップと、規則の第１の組の第１の規則を評価するステップと、第１の規則の評価に基づいてメッセージを送信するステップとのうちの１つまたは複数を含む、方法に関する。

さまざまな例示的な実施形態は、Ｄｉａｍｅｔｅｒメッセージを処理するためのＤｉａｍｅｔｅｒルーティングエージェント（ＤＲＡ）であって、以下、すなわち、規則の複数の組を格納するように構成された規則ストレージと、第１の送信元デバイスから第１のＤｉａｍｅｔｅｒメッセージを受信するように構成されたＤｉａｍｅｔｅｒスタックと、メッセージハンドラであって、第１のＤｉａｍｅｔｅｒメッセージに関連する第１のメッセージタイプを判定し、規則の複数の組のうちの規則の第１の組が第１のメッセージタイプに関連すると識別するように構成された、メッセージハンドラと、規則の第１の組の第１の規則を評価するように構成された規則エンジンとのうちの１つまたは複数を含み、メッセージハンドラは、第１の規則の評価に基づいてメッセージを送信するようにさらに構成される、Ｄｉａｍｅｔｅｒルーティングエージェント（ＤＲＡ）に関する。

さまざまな例示的な実施形態は、Ｄｉａｍｅｔｅｒメッセージを処理するためにＤｉａｍｅｔｅｒルーティングエージェント（ＤＲＡ）によって実行するための命令を符号化された非一時的機械可読ストレージ媒体であって、以下、すなわち、ＤＲＡで第１の送信元デバイスから第１のＤｉａｍｅｔｅｒメッセージを受信するための命令と、第１のＤｉａｍｅｔｅｒメッセージに関連する第１のメッセージタイプを判定するための命令と、規則の複数の組のうちの規則の第１の組が第１のメッセージタイプに関連すると識別するための命令と、規則の第１の組の第１の規則を評価するための命令と、第１の規則の評価に基づいてメッセージを送信するための命令とのうちの１つまたは複数を含む、非一時的機械可読ストレージ媒体に関する。

メッセージタイプが第１のＤｉａｍｅｔｅｒメッセージのアプリケーションタイプおよびコマンドタイプに基づくさまざまな実施形態が、説明される。

さまざまな実施形態は、少なくとも２つの異なるメッセージタイプに適用可能である規則の複数の組のうちの規則の第２の組と、規則の第２の組の第２の規則を評価するステップとをさらに含み、第１の規則の評価に基づいて第１のメッセージを送信するステップは、第１の規則の評価および第２の規則の評価に基づいて第１のメッセージを送信するステップを含む。

第２の規則を評価するステップが、第１の規則を評価するステップの前に実行されるさまざまな実施形態が、説明される。

さまざまな実施形態は、ＤＲＡで第２の送信元デバイスから第２のＤｉａｍｅｔｅｒメッセージを受信するステップであって、第２のＤｉａｍｅｔｅｒメッセージがＤｉａｍｅｔｅｒ要求である、受信するステップと、規則の第２の組の第３の規則を評価するステップであって、Ｄｉａｍｅｔｅｒ応答の少なくとも一部を生成する、評価するステップと、第２の送信元デバイスにＤｉａｍｅｔｅｒ応答を送信するステップであって、規則の第２の組のみが評価された後で実行される、送信するステップとをさらに含む。

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

第１のＤｉａｍｅｔｅｒメッセージがＤｉａｍｅｔｅｒ要求であり、第１の規則を評価するステップがＤｉａｍｅｔｅｒ応答を修正するステップを含み、第１の規則の評価に基づいてメッセージを送信するステップが第１の送信元デバイスにＤｉａｍｅｔｅｒ応答を送信するステップを含むさまざまな実施形態が、説明される。

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

Ｄｉａｍｅｔｅｒルーティングエージェントのための例示的なネットワーク環境を示す図である。 例示的なＤｉａｍｅｔｅｒルーティングエージェントを示す図である。 Ｄｉａｍｅｔｅｒメッセージを処理するための例示的な方法を示す図である。 複数の規則の組を評価するための例示的な方法を示す図である。 例示的な包括的な規則の組を示す図である。 例示的なメッセージタイプに固有の規則の組を示す図である。 例示的なメッセージ交換を示す図である。

理解を容易にするために、実質的に同じもしくは同様の構造または実質的に同じもしくは同様の機能を有する要素を示すために同一の参照番号が使用されている。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

上述のように、ステップ３３５および３４０は、異なる種類の規則の組の評価をともなう可能性がある。例えば、一部の実施形態においては、それぞれのメッセージタイプが、そのタイプのメッセージに当てはまる規則の組に関連付けられる可能性がある。したがって、１つの規則の組が、Ｇｘ ＣＣＲメッセージに適用される可能性がある一方、異なる規則の組は、Ｒｘ ＡＡＲメッセージに適用される可能性がある。また、一部の実施形態は、概して、すべてのＤｉａｍｅｔｅｒメッセージ、すべてのＤｉａｍｅｔｅｒ要求、またはすべてのＤｉａｍｅｔｅｒ応答に適用され得る規則の組を含む可能性がある。そのような実施形態において、ＤＲＡ２００は、複数の規則の組を順に評価する可能性がある。図４は、複数の規則の組を評価するための例示的な方法４００を示す。方法４００は、方法３００のステップ３３５、３４０の代わりにＤＳＣ２００の構成要素によって実行され得る。

方法４００は、ステップ４０５で始まり、ＤＲＡ２００がステップ３１０で受信されたメッセージに適用可能である包括的な規則の組を識別することができるステップ４１０に進む可能性がある。例えば、ＤＲＡ２００は、概して、すべてのメッセージ、すべてのＤｉａｍｅｔｅｒメッセージ、すべてのＤｉａｍｅｔｅｒ要求、またはすべてのＤｉａｍｅｔｅｒ応答に適用され得る規則の組を含む可能性がある。例えば、受信されたメッセージがＧＸ ＣＣＲである場合、ＤＲＡ２００は、すべてのＤｉａｍｅｔｅｒ要求のための包括的な規則の組を識別する可能性がある。次いで、ステップ４１５において、ＤＲＡ４１５が、識別された規則の組を評価する可能性がある。そのようにする際に、ＤＲＡ２００は、受信されたメッセージを修正するか、または送信元デバイスに返送されるべき異なるＤｉａｍｅｔｅｒメッセージを生成する可能性がある。

包括的な規則の組を評価した後、方法４００は、受信されたメッセージが要求メッセージであったかどうかをＤＲＡ２００が判定することができるステップ４２０に進む可能性がある。メッセージが要求メッセージであった場合、方法４００は、要求が応答されたかどうかをＤＲＡ２００が判定することができるステップ４２５に進む可能性がある。例えば、ステップ４１５の間に、ＤＲＡ２００は、Ｄｉａｍｅｔｅｒ応答メッセージを生成または修正する可能性がある。ステップ４２５において、ＤＲＡ２００が、送信元デバイスへの送信のために応答メッセージが構築されたかどうかを判定するためにＤｉａｍｅｔｅｒ応答の結果コードＡＶＰまたは試験結果（ｅｘｐｅｒｉｍｅｎｔａｌ−ｒｅｓｕｌｔ）ＡＶＰが設定されたかどうかを判定する可能性がある。そうである場合、方法４００は、次に、いかなる追加の規則も評価せずにステップ４４０で終了する可能性がある。ＤＲＡ２００は、次に、例えば、ステップ３００のステップ３４５において、送信元デバイスに応答メッセージを送り返す可能性がある。

一方、受信されたメッセージが要求メッセージでないかまたはステップ４１５で応答されていない場合、方法４００は、ステップ４３０に進む可能性がある。ステップ４３０で、ＤＲＡ２００が、受信されたメッセージに適用可能である第２の規則の組を選択する可能性がある。例えば、ＤＲＡ２００は、受信されたメッセージのアプリケーションおよびコマンドタイプに関連する規則の組を見つける可能性がある。例えば、受信されたＤｉａｍｅｔｅｒメッセージがＧｘ ＣＣＲである場合、ＤＲＡ２００は、Ｇｘ ＣＣＲメッセージに関連する規則の組を識別する可能性がある。それから、ステップ４３５において、ＤＲＡ２００が、規則エンジンを２度目に呼び出す可能性がある。この呼び出しは、ステップ４１０で識別された規則の組の代わりに、ステップ４３０において識別された規則の組を規則エンジンに渡すことをともなう可能性がある。したがって、ＤＲＡ２００は、ステップ４３５において、受信されたＤｉａｍｅｔｅｒメッセージのメッセージタイプに特に関連する規則の組を評価する可能性がある。方法４００は、次に、ステップ４４０で終了する可能性がある。さまざまな実施形態において、ＤＲＡ２００は、方法４００を完了した後、方法３００のステップ３４５に進む可能性がある。

方法４００に関して、さまざまな修正が明らかであろう。例えば、一部の実施形態においては、３つ以上の規則の組が、受信されたＤｉａｍｅｔｅｒメッセージに適用され得る可能性がある。そのような実施形態において、方法４００は、３回以上規則エンジンを呼び出す可能性がある。別の例として、さまざまな実施形態は、要求が応答されたかどうかを判定する前にすべての適用可能な規則の組を評価する可能性があり、または要求が応答されたかどうかを全く判定しない可能性がある。

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

包括的な規則の組５００は、概して、すべてのＤｉａｍｅｔｅｒ要求に適用され得る可能性がある。ＤＲＡは、すべてのＤｉａｍｅｔｅｒ応答に適用可能である別の包括的な規則の組（図示せず）を格納する可能性がある。規則の組５００は、基準ノード５１０などの基準ノードと、結果ノード５２０、５３０などの結果ノードとを含む可能性がある。規則の組５００が例示的であり、さまざまな実施形態が示された規則の組５００よりも複雑な規則の組（図示せず）を含み得ることは、明らかであろう。

基準ノードは、規則エンジンによって評価されるべき条件を提示する可能性がある。評価に基づいて、規則エンジンは、評価すべき別の基準ノードまたは結果ノードを選択することができる。例として、基準ノード５１０は、条件「Ｒｅｑｕｅｓｔ．Ｐｅｅｒ−Ｏｒｉｇｉｎ−ＨｏｓｔがＦｉｌｔｅｒＬｉｓｔにある」を格納する可能性がある。基準ノード５１０を評価すると、規則エンジンは、条件が真であるかまたは偽であるかを判定する可能性がある。例えば、規則エンジンは、受信されたメッセージまたは何らかのその他の要求メッセージを示す「Ｒｅｑｕｅｓｔ」コンテキストオブジェクトの「Ｐｅｅｒ−Ｏｒｉｇｉｎ−Ｈｏｓｔ」属性を読み、メッセージが遮断されるべきピア送信元ホストを一覧にする可能性がある別に定義された「ＦｉｌｔｅｒＬｉｓｔ」に値が載っているかどうかを判定する可能性がある。値が載っている場合、規則エンジンは、評価すべき次のノードとして結果ノード５２０を選択することができる。値が「ＦｉｌｔｅｒＬｉｓｔ」）に載っていない場合、規則エンジンは、評価されるべき次のノードとして結果ノード５３０を選択することができる。

結果ノードは、規則エンジンによって実行されるべき１つまたは複数のアクションを提示する可能性がある。そのようなアクションは、例えば、Ｄｉａｍｅｔｅｒメッセージを修正すること、またはＤｉａｍｅｔｅｒメッセージを特定のデバイスに送信することを含む可能性がある。例として、結果ノード５２０は、規則エンジンが値「０ｘ１２」を有する「Ｒｅｓｕｌｔ−Ｃｏｄｅ」ＡＶＰを「Ａｎｓｗｅｒ」コンテキストオブジェクトに追加すべきであることを示す可能性がある。この「Ａｎｓｗｅｒ」コンテキストオブジェクトは、ＤＲＡ２００の関連応答モジュール２３５に関連して上で検討されたように、Ｄｉａｍｅｔｅｒスタックで生成された関連する応答メッセージを表す可能性がある。別の例として、結果ノード５３０は、規則エンジンが「Ｒｅｑｕｅｓｔ」コンテキストオブジェクトの「ｒｅｍｏｖｅ」アクションにアクセスしてＤｉａｍｅｔｅｒメッセージからＲｏｕｔｅ−Ｒｅｃｏｒｄ ＡＶＰを削除すべきであることを示す可能性があり、それによって、Ｄｉａｍｅｔｅｒメッセージを受信するための後続のデバイスから経路レコード（ｒｏｕｔｅ ｒｅｃｏｒｄ）を隠す。経路エンジンは、結果ノード５２０または結果ノード５３０はその他の子ノードを持たない葉ノードである可能性もあるので、それらのノードに遭遇した後、規則の組５００を評価する規則エンジンが、終了される可能性がある。

規則の組５００がさまざまな代替的な構造を持ち得ることは、明らかであろう。例えば、規則の組５００は、より少ないまたはさらなる基準ノードまたは結果ノードを含む可能性がある。さらに、基準ノードが、別の基準ノードを子として含む可能性があり、または結果ノードが、別の結果ノードを子として含む可能性がある。

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

メッセージタイプに固有の規則の組６００は、例えば、Ｒｘ ＡＡＲメッセージなどの特定のメッセージタイプのＤｉａｍｅｔｅｒメッセージに適用され得る可能性がある。ＤＲＡは、いくつかの異なるメッセージタイプのために別々のメッセージタイプに固有の規則の組（図示せず）を格納する可能性がある。規則の組５００と同様に、規則の組６００は、基準ノード６１０、６４０などの基準ノードと、結果ノード６２０、６３０、６５０、６６０などの結果ノードとを含む可能性がある。

例として、基準ノード６１０は、「Ｒｘ ＡＡＲ」コンテキストオブジェクトのＳｅｓｓｉｏｎ−ＩＤが０ｘ０Ａ未満であるかまたは０ｘ２Ａよりも大きいときに「真」と評価され得る条件「（Ｒｘ ＡＡＲ．Ｓｅｓｓｉｏｎ−ＩＤ＜０ｘ０Ａ｜｜Ｒｘ ＡＡＲ．Ｓｅｓｓｉｏｎ−ＩＤ＞０ｘ２Ａ）」を格納する可能性がある。基準６１０が「真」と評価されるとき、規則エンジンは、結果ノード６２０を評価する可能性がある。そのような評価は、値０ｘ１０をＳｅｓｓｉｏｎ−ＩＤ ＡＶＰの現在の値に足すことを含む可能性がある。

基準ノード６１０が偽と評価される場合、規則エンジンは、結果ノード６３０を評価する可能性がある。そのような評価は、Ｒｘ ＡＡＲコンテキストオブジェクトのＦｌｏｗ−Ｄｅｓｃｒｉｐｔｉｏｎ ＡＶＰに関する「ｒｅｍｏｖｅ」アクションにアクセスすることを含み得る。それから、規則エンジンは、基準ノード６４０に移る可能性がある。基準ノード６４０は、Ｒｘ ＡＡＲオブジェクトがＭｅｄｉａ−Ｃｏｍｐｏｎｅｎｔ−Ｄｅｓｃｒｉｐｔｉｏｎ ＡＶＰを含むときに真と評価され得る条件「Ｐｒｅｓｅｎｔ（Ｒｘ ＡＡＲ．Ｍｅｄｉａ−Ｃｏｍｐｏｎｅｎｔ−Ｄｅｓｃｒｉｐｔｉｏｎ」を含む可能性がある。基準ノード６４０が真と評価されるとき、規則エンジンは、規則エンジンがＦｌｏｗ−Ｄｅｓｃｒｉｐｔｉｏｎ ＡＶＰを値「ｆｌｏｏｂｅｒ」に設定し得る結果ノード６５０に移る可能性がある。基準ノード６４０が偽と評価される場合、規則エンジンは、結果ノード６６０に移る可能性がある。結果ノード６６０は、評価中に行われるべき複数のアクションを指定する可能性がある。例えば、結果ノード６６０は、新しいＭｅｄｉａ−Ｃｏｍｐｏｎｅｎｔ−ＤｅｓｃｒｉｐｔｉｏｎがＲｘ ＡＡＲコンテキストオブジェクトに追加されるべきであり、Ｆｌｏｗ−Ｄｅｓｃｒｉｐｔｉｏｎ「ｆｌｏｏｂｅｒ」がＭｅｄｉａ−Ｓｕｂ−Ｃｏｍｐｏｎｅｎｔ ＡＶＰに追加されるべきであることを示す可能性がある。

規則の組５００、６００がユーザ入力に基づいて生成される可能性があることは、明らかであろう。さまざまな実施形態において、ユーザインターフェースは、ユーザが示されたように木を構成することを可能にし得る。その他の実施形態において、ユーザインターフェースは、ユーザによって与えられた異なる木の定義に基づいて二分決定木またはその他の規則の表現を生成することができる。例えば、規則の組５００、６００は、ユーザによって与えられた以下の擬似コードの規則の定義に基づいて生成される可能性がある。

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

例示的なネットワーク１００およびＤＲＡ２００の動作のための例示的な構成要素および方法を説明したので、以降で、ＤＲＡの動作の例が、図１−７を参照して与えられる。図７は、例示的なメッセージ交換７００を示す。メッセージ交換７００は、アプリケーション機能７１０と、ＤＲＡ７２０と、ＰＣＲＢ７３０との間で行われる可能性がある。例示を目的として、アプリケーション機能７１０はアプリケーション機能１６０に対応する可能性があり、ＤＲＡ７２０はＤＲＡ１４２およびＤＲＡ２００に対応する可能性があり、ＰＣＲＢはＰＣＲＢ１４４に対応する可能性があり、方法３００、４００はＤＲＡ７２０の動作を示す可能性があり、規則の組５００、６００は規則ストレージ２２０の内容を示す可能性がある。

プロセスは、ＤＲＡ７２０がＡＦ７１０からＤｉａｍｅｔｅｒメッセージ７４０を受信することができるステップ３１０で始まる可能性がある。メッセージハンドラ２１０が、ステップ３１５においてメッセージ７４０からコマンド「Ｒｘ ＡＡＲ」およびアプリケーションを抽出し、次に、ステップ３２０−３３０において任意のコンテキストオブジェクトを確立する可能性がある。例えば、コンテキスト生成器２３０は、Ｒｘ ＡＡＲコンテキストオブジェクトおよびＲｘ ＡＡＡコンテキストオブジェクトをインスタンス化する可能性がある。

ステップ４１０において、メッセージハンドラが、メッセージ７４０がＤｉａｍｅｔｅｒ要求であるので規則の組５００がメッセージ７４０に適用され得る可能性があると判定することができる。次いで、メッセージハンドラ２１０が、ステップ４１５において、規則の組５００を用いて規則エンジン２１５を呼び出す可能性がある。ステップ４１５の一部として、規則エンジン２１５は、基準ノード５１０を評価し、Ｒｘ ＡＡＲ７４０に関連するＰｅｅｒ−Ｏｒｉｇｉｎ−Ｈｏｓｔ、「０ｘ２」がＦｉｌｔｅｒＬｉｓｔに属する可能性があると判定することができる。結果として、規則エンジン２１５は、結果ノード５２０を評価し、値「０ｘ１２」を有するＲｅｓｕｌｔＣｏｄｅ ＡＶＰをＲｘ ＡＡＡコンテキストオブジェクトに加えることができる。それから、ＤＲＡ７２０は、Ｒｅｓｕｌｔ−Ｃｏｄｅ ＡＶＰがＡＡＡに設定されているので、ステップ４２０、４２５において、受信されたメッセージが要求メッセージであったと判定し、ステップ４１５において、要求が応答されたと判定することができる。ＤＲＡ７２０は、次に、規則の組５００の評価にのみ基づいてＡＦ７１０にメッセージ７５０を送り返す可能性がある。

その後、ＡＦ７１０は、ＤＲＡ７２０に別のＲｘ ＡＡＲメッセージ７６０を送信する可能性がある。上述のようにステップ３１０−３３０および４１０を実行した後。しかし、メッセージ７６０に関連して規則の組５００を評価する際、規則エンジン２１５は、Ｐｅｅｒ−Ｏｒｉｇｉｎ−Ｈｏｓｔ「０ｘ５」がＦｉｌｔｅｒＬｉｓｔにないと判定する可能性がある。したがって、規則エンジン２１５は、ＲｅｑｕｅｓｔコンテキストオブジェクトのＲｏｕｔｅ−Ｒｅｃｏｒｄオブジェクトに関するｒｅｍｏｖｅアクションにアクセスすることによって結果ノード５３０を評価する可能性がある。

次に、ステップ４１５において要求が応答されていない可能性があるので、方法４００は、ステップ４２５からステップ４３０に進む可能性があり、メッセージハンドラ２１０が、規則の組６００がメッセージ７６０などのＲｘ ＡＡＲメッセージに適用可能であると識別することができる。次いで、メッセージハンドラ２１０が、ステップ４３５において、今回は規則の組６００を用いて規則エンジンを２度目に呼び出す可能性がある。始めに、規則エンジンは、Ｓｅｓｓｉｏｎ−ＩＤ） ０ｘ１Ａが０ｘ０Ａよりも大きいが０ｘ２Ａ未満であるので基準ノード６１０が「偽」と評価されると判定することができる。したがって、規則エンジン２１５は、メッセージ７６０からＦｌｏｗ−Ｄｅｓｃｒｉｐｔｉｏｎ ＡＶＰを削除することによって結果ノード６３０を評価することができる。次に、Ｍｅｄｉａ−Ｃｏｍｐｏｎｅｎｔ−Ｄｅｓｃｒｉｐｔｉｏｎ）がメッセージ７６０に存在すると判定した後、規則エンジン２１５は、値「ｆｌｏｏｂｅｒ」を有するＦｌｏｗ−Ｄｅｓｃｒｉｐｔｉｏｎ ＡＶＰをＭｅｄｉａ−Ｓｕｂ−Ｃｏｍｐｏｎｅｎｔに加えることによって結果ノード６５０を評価することができる。最後に、ＤＲＡは、ステップ３４５において、ＰＣＲＢ７３０に修正されたメッセージ７７０を送信することができる。示されたように、メッセージ７７０は、Ｆｌｏｗ−Ｄｅｓｃｒｉｐｔｉｏｎ「ｆｌｏｏｂｅｒ」を含め、Ｒｏｕｔｅ−Ｒｅｃｏｒｄ ＡＶＰをもはや含めないように規則の組５００、６００に基づいて修正された。

以上により、さまざまな実施形態は、ＤｉａｍｅｔｅｒルーティングエージェントにおけるさまざまなＤｉａｍｅｔｅｒメッセージの堅牢で動的な処理を可能にする。特に、広い部類のＤｉａｍｅｔｅｒメッセージに概して適用可能である規則、および特定のＤｉａｍｅｔｅｒメッセージタイプに関連する規則の組を含めることによって、ＤＲＡは、さまざまなＤｉａｍｅｔｅｒメッセージの処理においてしたがわれるべき複雑な挙動を指定する際にユーザを楽にすることができる。例えば、ユーザは、異なるＤｉａｍｅｔｅｒアプリケーションに適用されるべき異なる挙動を指定することができ、なおもその他のシステム全体のポリシーを効率的に施行することができる。さまざまなさらなる利益は、以上の開示から明らかであろう。

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

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

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

Claims (12)

1. Ｄｉａｍｅｔｅｒメッセージを処理するためにＤｉａｍｅｔｅｒルーティングエージェント（ＤＲＡ）によって実行される方法であって、
   前記ＤＲＡで第１の送信元デバイスから第１のＤｉａｍｅｔｅｒメッセージを受信するステップ（３１０）と、
   前記第１のＤｉａｍｅｔｅｒメッセージに関連する第１のメッセージタイプを判定するステップ（３１５）と、
   規則の複数の組のうちの規則の第１の組が前記第１のメッセージタイプに関連すると識別するステップ（３３５）と、
   前記規則の第１の組の第１の規則を評価するステップ（３４０）と、
   前記第１の規則の評価に基づいてメッセージを送信するステップ（３４５）とを含み、
   方法は、
   前記規則の複数の組のうちの規則の第２の組が少なくとも２つの異なるメッセージタイプに適用可能であると識別するステップ（４１０）と、
   前記規則の第２の組の第２の規則を評価するステップ（４１５）とをさらに含み、
   前記第１の規則の評価に基づいてメッセージを送信するステップ（３４５）が、前記第１の規則の評価および前記第２の規則の評価に基づいて前記メッセージを送信するステップを含む、方法。
2. 前記第１のメッセージタイプと前記少なくとも２つの異なるメッセージタイプとが、前記第１のＤｉａｍｅｔｅｒメッセージのアプリケーションタイプおよびコマンドタイプに基づく、請求項１に記載の方法。
3. 前記第２の規則を評価するステップが、前記第１の規則を評価するステップの前に実行される、請求項１または２に記載の方法。
4. 前記ＤＲＡで第２の送信元デバイスから第２のＤｉａｍｅｔｅｒメッセージを受信するステップ（３１０）であって、前記第２のＤｉａｍｅｔｅｒメッセージがＤｉａｍｅｔｅｒ要求である、受信するステップ（３１０）と、
   前記規則の第２の組の第３の規則を評価するステップ（４１５）であって、Ｄｉａｍｅｔｅｒ応答の少なくとも一部を生成する、評価するステップ（４１５）と、
   前記第２の送信元デバイスに前記Ｄｉａｍｅｔｅｒ応答を送信するステップ（３４５）であって、前記規則の第２の組のみが評価された後で実行される、送信するステップ（３４５）とをさらに含む、請求項３に記載の方法。
5. 前記第１の規則を評価するステップ（３４０）が、前記第１のＤｉａｍｅｔｅｒメッセージを修正するステップを含み、
   前記第１の規則の評価に基づいてメッセージを送信するステップ（３４５）が、別のデバイスに前記第１のＤｉａｍｅｔｅｒメッセージを送信するステップを含む、請求項１から４のいずれか一項に記載の方法。
6. 前記第１のＤｉａｍｅｔｅｒメッセージが、Ｄｉａｍｅｔｅｒ要求であり、
   前記第１の規則を評価するステップ（３４０）が、Ｄｉａｍｅｔｅｒ応答を修正するステップを含み、
   前記第１の規則の評価に基づいてメッセージを送信するステップ（３４５）が、前記第１の送信元デバイスに前記Ｄｉａｍｅｔｅｒ応答を送信するステップを含む、請求項１から５のいずれか一項に記載の方法。
7. Ｄｉａｍｅｔｅｒメッセージを処理するためのＤｉａｍｅｔｅｒルーティングエージェント（ＤＲＡ）であって、
   規則の複数の組を格納するように構成された規則ストレージ（２２０）と、
   第１の送信元デバイスから第１のＤｉａｍｅｔｅｒメッセージを受信するように構成されたＤｉａｍｅｔｅｒスタック（２０５）と、
   メッセージハンドラ（２１０）であって、
   前記第１のＤｉａｍｅｔｅｒメッセージに関連する第１のメッセージタイプを判定し、
   前記規則の複数の組のうちの規則の第１の組が前記第１のメッセージタイプに関連すると識別するように構成された、メッセージハンドラ（２１０）と、
   前記規則の第１の組の第１の規則を評価するように構成された規則エンジン（２１５）とを含み、
   前記メッセージハンドラ（２１０）が、前記第１の規則の評価に基づいてメッセージを送信するようにさらに構成され、
   前記メッセージハンドラ（２１０）が、前記規則の複数の組のうちの規則の第２の組が少なくとも２つの異なるメッセージタイプに適用可能であると識別するようにさらに構成され、
   前記規則エンジン（２１５）が、前記規則の第２の組の第２の規則を評価するようにさらに構成され、
   前記第１の規則の評価に基づいて前記メッセージを送信する際に、前記メッセージハンドラ（２１０）が、前記第１の規則の評価および前記第２の規則の評価に基づいて前記メッセージを送信するように構成される、Ｄｉａｍｅｔｅｒルーティングエージェント（ＤＲＡ）。
8. 前記第１のメッセージタイプと前記少なくとも２つの異なるメッセージタイプとが、前記第１のＤｉａｍｅｔｅｒメッセージのアプリケーションタイプおよびコマンドタイプに基づく、請求項７に記載のＤＲＡ。
9. 前記規則エンジン（２１５）が、前記第１の規則を評価する前に前記第２の規則を評価する、請求項７または８に記載のＤＲＡ。
10. 前記Ｄｉａｍｅｔｅｒスタック（２０５）が、第２の送信元デバイスから第２のＤｉａｍｅｔｅｒメッセージを受信するようにさらに構成され、前記第２のＤｉａｍｅｔｅｒメッセージが、Ｄｉａｍｅｔｅｒ要求であり、
    前記規則エンジン（２１５）が、前記規則の第２の組の第３の規則を評価するようにさらに構成され、前記第３の規則を評価することが、Ｄｉａｍｅｔｅｒ応答の少なくとも一部を生成し、
    前記メッセージハンドラ（２１０）が、前記第２の送信元デバイスに前記Ｄｉａｍｅｔｅｒ応答を送信するようにさらに構成され、送信することが、前記規則の第２の組のみが評価された後に実行される、請求項９に記載のＤＲＡ。
11. 前記第１の規則を評価する際に、前記規則エンジン（２１５）が、前記第１のＤｉａｍｅｔｅｒメッセージを修正するように構成され、
    前記第１の規則の評価に基づいて前記メッセージを送信する際に、前記メッセージハンドラ（２１０）が、別のデバイスに前記第１のＤｉａｍｅｔｅｒメッセージを送信するように構成される、請求項７から１０のいずれか一項に記載のＤＲＡ。
12. 前記第１のＤｉａｍｅｔｅｒメッセージが、Ｄｉａｍｅｔｅｒ要求であり、
    前記第１の規則を評価する際に、前記規則エンジン（２１５）が、Ｄｉａｍｅｔｅｒ応答を修正するように構成され、
    前記第１の規則の評価に基づいて前記メッセージを送信する際に、前記メッセージハンドラ（２１０）が、前記第１の送信元デバイスに前記Ｄｉａｍｅｔｅｒ応答を送信するように構成される、請求項７から１１のいずれか一項に記載のＤＲＡ。

Images