ステートレス通信プロトコルにおけるサーバ状態推測
ステートレス通信プロトコルに基づくネットワーク上で、アプリケーションサーバとクライアントデバイスとの間で送信されるパケット間の仲介サーバによって、そのアプリケーションサーバとクライアントデバイスとの間で送信されるこれらのパケットをモニタおよび解析することで、サーバ状態オブジェクトは、同定される。これらのパケットは、複数の名前−値のペア（データオブジェクト）に構文解析される。同じ名前フィールドを有する名前−値のペアのエントロピが計算され、その計算されたエントロピに基づいて、サーバ状態オブジェクトとなりそうな候補データオブジェクトが選択される。アプリケーションサーバとクライアントデバイスとの間で双方向に送信された候補データオブジェクトが、サーバ状態オブジェクトとして同定される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的に、ステートレス通信プロトコルに関する。より特定的には、ＸＭＬ（拡張可能マークアップ言語）またはＳＯＡＰ（シンプルオブジェクトアクセスプロトコル）のようなステートレス通信プロトコル下において、サーバとクライアントデバイスとの間で送信されるパケット間のサーバ状態オブジェクトを同定することに関する。
【背景技術】
【０００２】
ＨＴＴＰ（ハイパーテキスト転送プロトコル）、ＸＭＬまたはＳＯＡＰのようなステートレス通信プロトコルは、以前のコマンドの状態情報を一切維持することなく、各コマンドを独立に実行する。このように、厳格にステートレスなプロトコルにおいて、サーバは、サーバと以前通信したクライアントデバイスのアイデンティティを格納しない。それゆえ、そのサーバは、以前のトランザクションを考慮して、そのクライアントの現在のトランザクションを処理しない。
【０００３】
クッキーまたは隠れフィールドのようなサーバ状態オブジェクトは、このように、ステートレス通信プロトコルを使用するサーバと通信するクライアントデバイスを同定するために、よく使用される。例えば、クッキーは、サーバウェブサイトが、クライアントデバイス上に、クライアントデバイスに関する自分自身の情報を格納できるサーバ状態オブジェクトである。これは、サーバウェブサイトが、後に、クライアントデバイスのアイデンティティをその後判断し得るようにするためである。このように、サーバは、サーバ状態オブジェクトを調査することで、クライアントデバイスがそのサーバと以前に通信したことを判断し得るので、サーバが、そのクライアントデバイスの同定のために追加の試みを行わなくても、クライアントデバイスは、その確立されたアイデンティティに基づいて、そのサーバとトランザクションできる。
【０００４】
サーバ状態オブジェクトは、サーバにクライアントデバイスを同定し、クライアントデバイスは、その判断されたアイデンティティに基づいて、サーバと通信できるので、サーバは、クライアントデバイスの特定のアイデンティティを装う不正な企てから自衛する手段を有しているはずである。それゆえ、サーバがこのような不正な企てに遭わないようにするために、サーバ状態オブジェクトは、典型的には、ステートレス通信プロトコル下において、不変である。言い換えれば、サーバがクライアントデバイスにサーバ状態オブジェクトを送信するとき、サーバは、そのサーバ状態オブジェクトが、そのクライアントデバイス上で変更も改竄もされずに、戻ってくることを期待する。
【０００５】
ＨＴＴＰのような構造化された明確な通信プロトコル下では、ファイアウォール、ゲートウェーまたはアプリケーションプロキシのような仲介サーバは、アプリケーションサーバとクライアントデバイスとの間で送信されたパケット間のサーバ状態オブジェクトを容易に同定し得る。なぜなら、サーバ状態オブジェクトを含むパケットは、このようなサーバ状態オブジェクトを同定する特定のフィールドを含むように構成されるからである。例えば、クッキーは、＜ｓｅｔ−ｃｏｏｋｉｅ：．．．．．．＞のようなストリングを含み、隠れフィールドは、＜ｉｎｐｕｔ ｔｙｐｅ＝ｈｉｄｄｅｎ．．．＞のようなストリングを含み、これらは、仲介サーバによって容易に同定され得る。
【０００６】
しかしながら、ＸＭＬまたはＳＯＡＰのような構造化度の少ないステートレス通信プロトコルにおいて、仲介サーバは、サーバ状態オブジェクトを容易に同定し得ない。なぜなら、これらのプロトコルは、アプリケーション設計者が、設計者自身のオブジェクトを任意に定義できるからである。ファイアウォールのような仲介サーバは、典型的には、アプリケーション設計者によって、アプリケーションサーバに与えられたプロトコル定義へのアクセスを有しないので、それゆえ、アプリケーション設計者によって任意に定義されたサーバ状態オブジェクトは、仲介サーバによって、容易に同定し得ない。例えば、一つのアプリケーションサーバにおいて、サーバ状態は、「課金番号」オブジェクトに保持され得るが、別の一つのアプリケーションにおいて、同じサーバ状態は、「クライアントＩＤ」オブジェクトに保持され得る。アプリケーションサーバは、これらプロトコル定義に対するアクセスを有し、こうして、これらサーバ状態オブジェクトを同定し得る。しかしながら、仲介サーバ（ファイアウォールまたは他のフィルタ）は、仲介サーバの背後にある全てのアプリケーションのプロトコル／アプリケーション定義を有しない。
【０００７】
それゆえ、仲介サーバによって、サーバ状態オブジェクトを同定する所定の方法を有しないＸＭＬまたはＳＯＡＰのような構造化度の低いステートレス通信プロトコル下において、サーバとクライアントデバイスとの間で送信されるサーバ状態オブジェクトを同定する必要性がある。
【発明の開示】
【課題を解決するための手段】
【０００８】
（発明の概要）
本発明は、ステートレス通信プロトコルに基づくネットワーク上で、アプリケーションサーバとクライアントデバイスとの間で送信されるパケット間のサーバ状態オブジェクトを同定することを提供する。ここで、パケットは、クライアントデバイスおよびアプリケーションサーバによって使用されるプロトコル定義に対するアクセスを有しない仲介サーバによって受信される。アプリケーションサーバとクライアントデバイスとの間で送信されるパケットは、仲介サーバによってモニタされ、複数の名前−値のペア（データオブジェクト）に構文解析される。同じ名前フィールドを有するデータオブジェクトのエントロピが計算され、サーバ状態オブジェクトとなりそうな候補データオブジェクトが、選択される。一実施形態において、閾値より高いエントロピを有するデータオブジェクトが、候補データオブジェクトとして選択される。最終的に、アプリケーションサーバとクライアントデバイスとの間で双方向に送信されたと判断される候補データオブジェクトが、サーバ状態オブジェクトとして同定される。
【０００９】
一実施形態において、データオブジェクトのエントロピは、同じ名前フィールドを有する構造解析されたデータオブジェクトの値フィールドを連結すること、エントロピベースの圧縮アルゴリズムを用いて、この連結値フィールドを圧縮すること、および、圧縮連結値フィールドの合計サイズを、同じ名前フィールドを有するデータオブジェクトの合計数で割ることによって計算される。
【００１０】
本発明の実施形態は、たとえ、ＸＭＬまたはＳＯＡＰのような構造化度の低いステートレス通信プロトコルが使用されたときでも、アプリケーションサーバとクライアントデバイスとの間で送信されるサーバ状態オブジェクトを同定し得る。このように、仲介サーバは、同定されたサーバ状態オブジェクトを調査すると、アプリケーションサーバとクライアントとによって使用される基盤アプリケーションプロトコルに何らアクセスを有しなくても、そのアプリケーションサーバと以前に通信したクライアントデバイスを同定し得る。これによって、仲介サーバによって保持される情報を絶えず更新することを必要とせずに、基盤アプリケーションプロトコルが変更されることも、あるいは、新たなアプリケーションがネットワーク上でホストされることも可能になる。また、これによって、このように構造化度の低いステートレスデータ通信プロトコルを用いるインターネットトランザクションのインプリメンテーションが容易になる。
【発明を実施するための最良の形態】
【００１１】
（実施形態の詳細な説明）
図１は、本発明の一実施形態に従うサーバ状態オブジェクトを同定するシステム１００のアーキテクチャを示すブロック図である。システム１００は、アプリケーションサーバ１０２とクライアントデバイス１０４との間で送信されるパケット１１８をモニタするためにアプリケーションサーバ１０２とクライアントデバイス１０４との間に結合される。パケット１１８は、アプリケーションサーバ１０２とクライアントデバイス１０４との間で双方向に、あるいは、アプリケーションサーバ１０２からクライアントデバイス１０４への一方向にのみ、または、その逆の一方向にのみ送信され得る。パケット１１８は、ＸＭＬ、ＳＯＡＰまたはＨＴＴＰのようなステートレスデータ通信プロトコルを用いて、アプリケーションサーバ１０２とクライアントデバイスとの間を送信される。しかしながら、システム１００は、アプリケーションサーバ１０２によって与えられるプロトコル定義を典型的には有しない。このアプリケーションサーバ１０６は、サーバ状態オブジェクトを同定するために、パケットを解析する。図１には、単一のクライアントデバイス１０４が示されているが、実際には、アプリケーションサーバ１０２と通信する多数のクライアントデバイス１０４があることは、理解されるべきである。また、単一のアプリケーションサーバ１０２が示されているが、任意の数のアプリケーションサーバ１０２が、クライアントデバイス１０４をサービスするために、システム１００の背後に配備され得る。
【００１２】
一実施形態において、システム１００は、アプリケーションファイアウォール１０６、学習エンジン１０８、および、データストレージモジュール１１０を含む。アプリケーションファイアウォール１０６は、サーバ１０２からクライアントデバイス１０４に、および、クライアントデバイス１０４からサーバ１０２に送信されるパケット１１８をモニタする。アプリケーションファイアウォール１０６は、モニタされたパケット１１８を構文解析し、学習エンジン１０８によって提供されるフィルタリングルール１１６に従って、悪意あるパケットまたは望まれぬパケット１１８をフィルタリングする。フィルタリングルール１１６は、サーバ１０２とクライアントデバイス１０４との間で送信される特定のパケット１１８を通過または阻止する基準を有するアプリケーションファイアウォール１０６を提供する。
【００１３】
アプリケーションファイアウォール１０６は、モニタされたパケット１１８を構文解析し、学習エンジン１０８によって提供されたデータ収集パラメータ１１２に従って収集されたデータ１１４を学習エンジン１０８に提供する。データ収集パラメータ１１２は、アプリケーションファイアウォール１０６に、アプリケーションファイアウォール１０６がモニタされたパケット１１８から収集すべきデータの型に関する基準を提供する。これらデータ収集パラメータ１１２は、例えば、通信プロトコルに従うパケット１１８に対応する名前−値（名前−属性）のペアを集めるために、パケット１１８を構文解析する方法を含む。しかしながら、典型的な実施形態において、アプリケーションファイアウォール１０６は、アプリケーションサーバ１０４によって使用されるような基盤プロトコル定義（例えば、文書型定義（ＤＴＤ））に対するアクセスを有しない。
【００１４】
一実施形態において、アプリケーションファイアウォール１０６自身は、そのアプリケーションファイアウォール機能専用のコンピュータシステム実行中ソフトウェアであり得る。別の実施形態において、アプリケーションファイアウォール１０６は、コンピュータシステム１００上で実行中の大きなソフトウェアシステムの一部であるソフトウェアモジュールであり得る。
【００１５】
学習エンジン１０８は、フィルタリングルール１１６およびデータ収集パラメータ１１２をアプリケーションファイアウォール１０６に提供し、データ収集パラメータ１１２に従って、アプリケーションファイアウォール１０６によって収集されたデータ１１４を受信する。パケット１１８は、使用された通信プロトコルに従って、サーバ１０２とクライアントデバイス１０４との間で送信されるパケットである。例えば、パケット１１８は、また、ＸＭＬパケットまたはＳＯＡＰパケットでもあり得る。アプリケーションファイアウォール１０６は、パケット１１８を名前−値（名前−属性）のペア１１４に構文解析し、学習エンジン１０８は、パケット１１８間のサーバ状態オブジェクトを同定するさらなる処理のために、これらの名前−値のペア１１４を受信する。名前−値（名前−属性）のペアは、また、本明細書で、「データオブジェクト」とも称される。
【００１６】
学習エンジン１０８は、アプリケーションファイアウォール１０６から受信されたデータオブジェクト１１４すなわち名前−値のペア１１４を解析することによって、サーバ１０２とクライアントデバイス１０４との間で送信されるパケット１１８間のサーバ状態オブジェクトを同定する。この点について、学習エンジン１０８は、名前−値のペア１１４を同定し、各同定された名前フィールドに対して、その名前に対する値を連結する。各名前に対する値の最小数を累積した後、学習エンジン１０８は、次いで、圧縮アルゴリズムを用いて、その名前に対する連結値を圧縮する。圧縮アルゴリズムは、Ｌｅｍｐｅｌ−Ｚｉｖ型圧縮アルゴリズムのようなエントロピベースの圧縮アルゴリズムであり得る。次いで、学習エンジン１０８は、圧縮値の合計サイズをその同じ名前を有する値の合計数で割ることで、圧縮値のそれぞれのエントロピを計算する。
【００１７】
学習エンジン１０８は、データオブジェクトの計算されたエントロピに従って、データオブジェクトからサーバ状態オブジェクトでありそうな候補データオブジェクトを選択する。サーバ状態オブジェクトは、典型的には、各クライアントの状態を維持するために、データオブジェクトの値フィールド内の比較的明確なストリングを含むので、サーバ状態オブジェクトのエントロピは、高くなりそうである。このように、一実施形態において、学習エンジン１０８は、候補データオブジェクトとして、閾値より高いエントロピ値を有するデータオブジェクトを選択する。エントロピに対する閾値は、パケット１１８の通信に用いられる基盤通信プロトコルによって異なる。典型的なサーバ状態オブジェクトは、３２ビット以上に相当するエントロピ値を有する。なぜなら、そのオブジェクトは、さらに、サーバインプリメンテーションまたはデータベーステーブル内のキーを参照するオブジェクトであることが多いからである。このように、一実施形態において、閾値は、２４ビットに相当するエントロピレベルに設定される。
【００１８】
候補データオブジェクトが、アプリケーションサーバ１０２からクライアントデバイス１０４へ、かつ、クライアントデバイス１０４からアプリケーションサーバ１０２へと双方に送信された場合、学習エンジン１０８は、１つ以上の候補データオブジェクトをサーバ状態オブジェクトとして同定する。これは、サーバ状態オブジェクトが、アプリケーションサーバ１０２によってクライアントデバイス１０４に送信され、クライアントデバイス１０４に格納されたからである。こうして、アプリケーションサーバ１０２は、後にクライアントデバイス１０４を同定し得る。また、サーバ状態オブジェクトが、後に、クライアントデバイス１０４からアプリケーションサーバ１０２に送信されたからである。こうして、クライアントデバイス１０４は、自らをアプリケーションサーバ１０２に同定し得る。
【００１９】
一実施形態において、学習エンジン１０８は、通信プロトコル下にある関連パケットを、サーバからクライアントデバイスに送信された第一のパケットのグループと、クライアントデバイスからサーバに送信された第二のパケットのグループとに、分けることによって、サーバ１０２とクライアントデバイス１０４との間で双方向に送信された候補データオブジェクトを同定する。関連パケットは、通信プロトコル下の「関連メッセージ」に対応するパケットである。例えば、ＨＴＴＰセッションの要求／応答通信の一部を形成するパケットは、ＨＴＴＰプロトコル下の関連パケットである。ＳＯＡＰにおいて、要求および応答は、個別の接続で実行され得る。それゆえ、ＳＯＡＰ下の関連パケットの概念は、外部的に提供される。一実施形態において、（ソースＩＰアドレス／ポートと目的地ＩＰアドレス／ポートとに基づく）同じソースポイントと目的地ポイントとの間のメッセージは、ＳＯＡＰ下の関連パケットと考えられ得る。他の実施形態において、（ＵＲＬ（統一リソースロケータ）によって同定された）２つの同じサービスの間のメッセージは、ＳＯＡＰ下の関連パケットと考えられる。学習エンジン１０８は、サーバ状態オブジェクトとして、第一のパケットのグループと第二のパケットのグループとの双方に含まれる候補データオブジェクトを同定する。
【００２０】
一実施形態において、データストレージモジュール１１０は、収集されたデータ１１４および他の暫定データを一時的に格納する。その間、パケット１１８の中からサーバ状態オブジェクトを同定するために、データオブジェクト１１４が、アプリケーションファイアウォール１０６から受信されたとき、学習エンジン１０８は、収集されたデータ１１４をリアルタイムで解析する。別の実施形態において、ストレージモジュール１１０は、所定の期間にわたり、または、格納されたデータオブジェクトが特定の閾値に達するまで、収集されたデータ１１４の中に受信されたデータオブジェクトを格納し、学習エンジン１０８は、このデータオブジェクトがサーバ状態オブジェクトであるかどうかを判断するために、格納されたデータオブジェクトをバッチ処理する。
【００２１】
図２は、ステートレス通信プロトコルに基づくネットワーク上で、サーバ１０２とクライアントデバイス１０４との間で送信されたパケット１１８の中から、サーバ状態オブジェクトを同定する方法を示す流れ図である。図２に記載された方法は、図１のシステム１００内で実行され得る。
【００２２】
本方法が、開始２０２されると、アプリケーションファイアウォール１０６は、サーバ１０２からクライアントデバイス１０４に、あるいは、クライアントデバイス１０４からサーバ１０２に送信されたパケット１１８を、複数の名前−値のペア（データオブジェクト）に構文解析２０４する。図３は、名前−値のペア３０３の例を示す。図３を参照すると、パケット１１８は、構文解析され、名前３０２と、その名前３０２に対応する値（属性）３０４とに分けられる。例えば、名前「注文ＩＤ」３０５は、ウェブサイト１０２とクライアントデバイス１０４との間で実行されたインターネット販売のトランザクションに対応する名前であり得る。これらの名前フィールド「注文ＩＤ」３０５は、対応する値フィールド「ＡＢＣＤＥＦＡＢＣＤＥＦ」、「１１１ＢＢＣＣＣＤＤＤ」および「ＤＤＤＣＣＣｌ１１２２３３」を有する。名前フィールド「著者」３０６、「課金番号」３０７および「題名」３０８は、対応する値フィールド「ジョン」、「１２３４５６７８９」および「インターネット販売」をそれぞれ有する。図３は、３つの名前−値のペア３０３しか示していないが、実際には、いつでも、アプリケーションファイアウォール１０６によって維持管理される数百あるいは数千もの名前−値のペア３０３であり得る。
【００２３】
図２に戻って参照すると、学習エンジン１０８は、同じ名前フィールドを有する構文解析されたデータオブジェクトの値フィールドを連結２０６する。例えば、図３の名前−値のペアの幾つかは、同じ名前「注文ＩＤ」３０５を有する。このように、名前「注文ＩＤ」に対応する値フィールド３０４は、名前フィールド「注文ＩＤ」３０５に対応する連結値「ＡＢＣＤＥＦＡＢＣＤＥＦ１１１ＢＢＣＣＣＤＤＤＤＤＤＣＣＣ１１１２２３３」を得るために、連結される。
【００２４】
任意の所定の名前に対する最小数の名前−値のペアが、同定された後、学習エンジン１０８は、圧縮アルゴリズムを用いて、その名前に対する連結値を圧縮２０８する。一実施形態において、圧縮アルゴリズムは、Ｌｅｍｐｅｌ−Ｚｉｖタイプの圧縮アルゴリズムのようなエントロピベースの圧縮アルゴリズムであり得る。次いで、学習エンジン１０８は、圧縮連結値リストの合計サイズを、その名前に対する名前−値のペアの合計数で割ることによって、圧縮連結値のエントロピを計算２１０する。それゆえ、図３に示す例において、連結値リスト「ＡＢＣＤＥＦＡＢＣＤＥＦ１１１ＢＢＣＣＣＤＤＤＤＤＤＣＣＣ１１１２２３３」は、圧縮アルゴリズムを用いて、圧縮２０８され、圧縮連結値の合計サイズは、その同じ名前フィールド（「注文ＩＤ」）を有する名前−値のペアの数（図３に示す例では、３）で割られる。
【００２５】
明らかなように、サーバ状態オブジェクトとなる潜在的候補となるデータオブジェクトは多数あり、これら各候補のそれぞれに対し、計算されたエントロピメジャがある。この潜在的候補のセットから、学習エンジン１０８は、計算されたエントロピに従って、サーバ状態オブジェクトとなりそうな候補名前−値のペアを選択２１２する。既に述べたように、一実施形態において、学習エンジン１０８は、候補名前−値のペアとして、所定の閾値より高いエントロピメジャを有する名前−値のペアを選択する。エントロピに対する閾値は、パケット１１８の送信に使用される基盤通信プロトコルによって異なる。典型的なサーバ状態オブジェクトは、３２ビット以上に相当するエントロピ値を有する。なぜなら、そのオブジェクトは、サーバインプリメンテーションまたはデータベーステーブル内のキーを参照するオブジェクトであることが多いからである。このように、一実施形態において、閾値は、２４ビットに相当するエントロピレベルに設定される。こうして、前述の「注文ＩＤ」および「課金番号」は、十分に高いエントロピを有するものとして選択され得る。その一方、「著者」および「題名」は、十分に高いエントロピを有するものとして選択され得ない。
【００２６】
次いで、学習エンジン１０８は、どの名前−値のペアが、アプリケーションサーバ１０２とクライアントデバイス１０４との間で双方向に送信されたかを判断２１４する。その候補名前−値のペアが双方向に送信されたら、学習エンジン１０８は、その名前−値のペアをサーバ状態オブジェクトとして、ラベル付け２１８する。その候補名前−値のペアが双方向に送信されなかったたら、学習エンジン１０８は、その名前−値のペアはサーバ状態オブジェクトでないと、判断２１６する。
【００２７】
図４は、図２に記載されたようにサーバとクライアントデバイスとの間で双方向に送信された名前−値のペアを同定するプロセスを示す。前述のように、学習エンジン１０８は、候補名前−値のペアがアプリケーションサーバ１０２とクライアントデバイス１０４との間で双方向に送信された場合、その名前−値のペアの１つ以上をサーバ状態オブジェクトとして同定する。これは、サーバ状態オブジェクトが、アプリケーションサーバ１０２によってクライアントデバイス１０４に送信され、クライアントデバイス１０４に格納されたからである。こうして、アプリケーションサーバ１０２は、後にクライアントデバイス１０４を同定し得る。また、サーバ状態オブジェクトが、後に、クライアントデバイス１０４からアプリケーションサーバ１０２に送信されたからである。こうして、クライアントデバイス１０４は、自らをアプリケーションサーバ１０２に同定し得る。
【００２８】
図４を参照すると、一実施形態において、学習エンジン１０８は、通信プロトコル下にある関連パケット１１８を、アプリケーションファイアウォール１０６によって対応するパケットの受領を示すそのパケットの関連タイムスタンプの順番に、アプリケーションサーバ１０２からクライアントデバイス１０４に送信された第一のパケットのグループ４０２と、クライアントデバイス１０４からアプリケーションサーバ１０２に送信された第二のパケットのグループ４０４とに分ける。関連パケットは、通信プロトコル下の関連メッセージに対応するパケットである。例えば、ＨＴＴＰセッションの要求／応答通信の一部を形成するパケットは、ＨＴＴＰプロトコル下の関連パケットである。ＳＯＡＰにおいて、要求および応答は、個別の接続で実行され得る。それゆえ、ＳＯＡＰ下の関連パケットの概念は、外部的に提供される。一実施形態において、（ソースＩＰアドレス／ポートと目的地ＩＰアドレス／ポートとに基づく）同じソースポイントと目的地ポイントとの間のメッセージは、ＳＯＡＰ下の関連パケットと考えられ得る。他の実施形態において、（ＵＲＬ（統一リソースロケータ）によって同定された）２つの同じサービス間のメッセージは、ＳＯＡＰ下の関連パケットと考えられる。図４に示す例において、名前−値のペア４０６、４０８、４１０および４１２は、アプリケーションサーバ１０２とクライアントデバイス１０４との間で双方向に送信された候補名前−値のペアである。図４には示されていないが、これらの名前−値のペア４０６、４０８、４１０、４１２以外にも、追加の候補名前−値のペアも、またあり得ることは留意されるべきである。
【００２９】
学習エンジン１０８は、第一のパケットのグループ４０２と第二のパケットのグループ４０４との双方に含まれる名前−値のペアを、サーバ状態オブジェクトとし、同定する。例えば、候補名前−値のペア４０６、４０８、４１０、４１２、４２０、４２２は、第一のパケットのグループ４０２と第二のパケットのグループ４０４との双方に含まれ、学習エンジン１０８によって、サーバ状態オブジェクトと判断される。しかしながら、候補名前−値のペア４１６および４１８は、第二のパケットのグループ４０４の中にしか含まれておらず、それゆえ、サーバ状態オブジェクトではない。
【００３０】
本発明は、たとえ、仲介サーバが基盤通信プロトコルに対するアクセスを有しないＸＭＬまたはＳＯＡＰのような構造化度の低いステートレスデータ通信が使用されたときでさえも、アプリケーションサーバとクライアントデバイスとの間で双方向に送信されるサーバ状態オブジェクトが、フィルタまたはゲートウェーのような仲介サーバによって同定され得るというメリットを有する。これによって、このように構造化度の低いステートレスデータ通信プロトコルを用いるインターネットトランザクションのインプリメンテーションが容易になる。なぜなら、サーバは、サーバ状態オブジェクトを調査することによって、そのサーバと以前に通信したクライアントデバイスを同定し得るからである。
【００３１】
本発明は、幾つかの実施形態の観点から、以上に説明されてきたが、様々な変更も本発明の範囲内でなされ得る。例えば、本発明は、任意の通信プロトコルに限定されないし、また、任意のステートレス通信プロトコルとともに使用され得る。図１のシステム１００のアーキテクチャは、単なる例示に過ぎず、システム１００がアプリケーションサーバ１０２とクライアントデバイス１０４との間で送信されるパケットをモニタし得るシステムである限り、任意の方法で変更され得る。データオブジェクトの値フィールドの圧縮は、任意のタイプの圧縮アルゴリズムを用いて行われ得、連結圧縮データオブジェクトのエントロピの計算方法は、本明細書の記載に限定されない。双方向パケットを同定する方法は、本明細書の図４で記載されたことに限定されないし、異なる方法も、アプリケーションサーバ１０２とクライアントデバイスとの間で双方向に送信されるパケットを同定する適切な方法である限り、使用され得る。また、複数のクライアントデバイス１０４が、１つのアプリケーションサーバ１０２と通信するときも、あるいは、１つのクライアントデバイス１０４が複数のアプリケーション１０２と通信するときも、本発明は、サーバ状態オブジェクトを同定するために使用され得る。
【００３２】
したがって、本発明の開示は、本発明の範囲を例示するものであって、限定するものではなく、本発明の範囲は以下の請求項で示される。
【図面の簡単な説明】
【００３３】
【図１】図１は、本発明の一実施形態に従って、サーバ状態オブジェクトを同定するシステムのアーキテクチャを示すブロック図である。
【図２】図２は、本発明の一実施形態に従って、サーバ状態オブジェクトを同定する方法を示す流れ図である。
【図３】図３は、名前−値のペアを示す図である。
【図４】図４は、サーバとクライアントデバイスとの間の双方向送信される名前−値のペアを同定するステップを示す図である。
【技術分野】
【０００１】
本発明は、一般的に、ステートレス通信プロトコルに関する。より特定的には、ＸＭＬ（拡張可能マークアップ言語）またはＳＯＡＰ（シンプルオブジェクトアクセスプロトコル）のようなステートレス通信プロトコル下において、サーバとクライアントデバイスとの間で送信されるパケット間のサーバ状態オブジェクトを同定することに関する。
【背景技術】
【０００２】
ＨＴＴＰ（ハイパーテキスト転送プロトコル）、ＸＭＬまたはＳＯＡＰのようなステートレス通信プロトコルは、以前のコマンドの状態情報を一切維持することなく、各コマンドを独立に実行する。このように、厳格にステートレスなプロトコルにおいて、サーバは、サーバと以前通信したクライアントデバイスのアイデンティティを格納しない。それゆえ、そのサーバは、以前のトランザクションを考慮して、そのクライアントの現在のトランザクションを処理しない。
【０００３】
クッキーまたは隠れフィールドのようなサーバ状態オブジェクトは、このように、ステートレス通信プロトコルを使用するサーバと通信するクライアントデバイスを同定するために、よく使用される。例えば、クッキーは、サーバウェブサイトが、クライアントデバイス上に、クライアントデバイスに関する自分自身の情報を格納できるサーバ状態オブジェクトである。これは、サーバウェブサイトが、後に、クライアントデバイスのアイデンティティをその後判断し得るようにするためである。このように、サーバは、サーバ状態オブジェクトを調査することで、クライアントデバイスがそのサーバと以前に通信したことを判断し得るので、サーバが、そのクライアントデバイスの同定のために追加の試みを行わなくても、クライアントデバイスは、その確立されたアイデンティティに基づいて、そのサーバとトランザクションできる。
【０００４】
サーバ状態オブジェクトは、サーバにクライアントデバイスを同定し、クライアントデバイスは、その判断されたアイデンティティに基づいて、サーバと通信できるので、サーバは、クライアントデバイスの特定のアイデンティティを装う不正な企てから自衛する手段を有しているはずである。それゆえ、サーバがこのような不正な企てに遭わないようにするために、サーバ状態オブジェクトは、典型的には、ステートレス通信プロトコル下において、不変である。言い換えれば、サーバがクライアントデバイスにサーバ状態オブジェクトを送信するとき、サーバは、そのサーバ状態オブジェクトが、そのクライアントデバイス上で変更も改竄もされずに、戻ってくることを期待する。
【０００５】
ＨＴＴＰのような構造化された明確な通信プロトコル下では、ファイアウォール、ゲートウェーまたはアプリケーションプロキシのような仲介サーバは、アプリケーションサーバとクライアントデバイスとの間で送信されたパケット間のサーバ状態オブジェクトを容易に同定し得る。なぜなら、サーバ状態オブジェクトを含むパケットは、このようなサーバ状態オブジェクトを同定する特定のフィールドを含むように構成されるからである。例えば、クッキーは、＜ｓｅｔ−ｃｏｏｋｉｅ：．．．．．．＞のようなストリングを含み、隠れフィールドは、＜ｉｎｐｕｔ ｔｙｐｅ＝ｈｉｄｄｅｎ．．．＞のようなストリングを含み、これらは、仲介サーバによって容易に同定され得る。
【０００６】
しかしながら、ＸＭＬまたはＳＯＡＰのような構造化度の少ないステートレス通信プロトコルにおいて、仲介サーバは、サーバ状態オブジェクトを容易に同定し得ない。なぜなら、これらのプロトコルは、アプリケーション設計者が、設計者自身のオブジェクトを任意に定義できるからである。ファイアウォールのような仲介サーバは、典型的には、アプリケーション設計者によって、アプリケーションサーバに与えられたプロトコル定義へのアクセスを有しないので、それゆえ、アプリケーション設計者によって任意に定義されたサーバ状態オブジェクトは、仲介サーバによって、容易に同定し得ない。例えば、一つのアプリケーションサーバにおいて、サーバ状態は、「課金番号」オブジェクトに保持され得るが、別の一つのアプリケーションにおいて、同じサーバ状態は、「クライアントＩＤ」オブジェクトに保持され得る。アプリケーションサーバは、これらプロトコル定義に対するアクセスを有し、こうして、これらサーバ状態オブジェクトを同定し得る。しかしながら、仲介サーバ（ファイアウォールまたは他のフィルタ）は、仲介サーバの背後にある全てのアプリケーションのプロトコル／アプリケーション定義を有しない。
【０００７】
それゆえ、仲介サーバによって、サーバ状態オブジェクトを同定する所定の方法を有しないＸＭＬまたはＳＯＡＰのような構造化度の低いステートレス通信プロトコル下において、サーバとクライアントデバイスとの間で送信されるサーバ状態オブジェクトを同定する必要性がある。
【発明の開示】
【課題を解決するための手段】
【０００８】
（発明の概要）
本発明は、ステートレス通信プロトコルに基づくネットワーク上で、アプリケーションサーバとクライアントデバイスとの間で送信されるパケット間のサーバ状態オブジェクトを同定することを提供する。ここで、パケットは、クライアントデバイスおよびアプリケーションサーバによって使用されるプロトコル定義に対するアクセスを有しない仲介サーバによって受信される。アプリケーションサーバとクライアントデバイスとの間で送信されるパケットは、仲介サーバによってモニタされ、複数の名前−値のペア（データオブジェクト）に構文解析される。同じ名前フィールドを有するデータオブジェクトのエントロピが計算され、サーバ状態オブジェクトとなりそうな候補データオブジェクトが、選択される。一実施形態において、閾値より高いエントロピを有するデータオブジェクトが、候補データオブジェクトとして選択される。最終的に、アプリケーションサーバとクライアントデバイスとの間で双方向に送信されたと判断される候補データオブジェクトが、サーバ状態オブジェクトとして同定される。
【０００９】
一実施形態において、データオブジェクトのエントロピは、同じ名前フィールドを有する構造解析されたデータオブジェクトの値フィールドを連結すること、エントロピベースの圧縮アルゴリズムを用いて、この連結値フィールドを圧縮すること、および、圧縮連結値フィールドの合計サイズを、同じ名前フィールドを有するデータオブジェクトの合計数で割ることによって計算される。
【００１０】
本発明の実施形態は、たとえ、ＸＭＬまたはＳＯＡＰのような構造化度の低いステートレス通信プロトコルが使用されたときでも、アプリケーションサーバとクライアントデバイスとの間で送信されるサーバ状態オブジェクトを同定し得る。このように、仲介サーバは、同定されたサーバ状態オブジェクトを調査すると、アプリケーションサーバとクライアントとによって使用される基盤アプリケーションプロトコルに何らアクセスを有しなくても、そのアプリケーションサーバと以前に通信したクライアントデバイスを同定し得る。これによって、仲介サーバによって保持される情報を絶えず更新することを必要とせずに、基盤アプリケーションプロトコルが変更されることも、あるいは、新たなアプリケーションがネットワーク上でホストされることも可能になる。また、これによって、このように構造化度の低いステートレスデータ通信プロトコルを用いるインターネットトランザクションのインプリメンテーションが容易になる。
【発明を実施するための最良の形態】
【００１１】
（実施形態の詳細な説明）
図１は、本発明の一実施形態に従うサーバ状態オブジェクトを同定するシステム１００のアーキテクチャを示すブロック図である。システム１００は、アプリケーションサーバ１０２とクライアントデバイス１０４との間で送信されるパケット１１８をモニタするためにアプリケーションサーバ１０２とクライアントデバイス１０４との間に結合される。パケット１１８は、アプリケーションサーバ１０２とクライアントデバイス１０４との間で双方向に、あるいは、アプリケーションサーバ１０２からクライアントデバイス１０４への一方向にのみ、または、その逆の一方向にのみ送信され得る。パケット１１８は、ＸＭＬ、ＳＯＡＰまたはＨＴＴＰのようなステートレスデータ通信プロトコルを用いて、アプリケーションサーバ１０２とクライアントデバイスとの間を送信される。しかしながら、システム１００は、アプリケーションサーバ１０２によって与えられるプロトコル定義を典型的には有しない。このアプリケーションサーバ１０６は、サーバ状態オブジェクトを同定するために、パケットを解析する。図１には、単一のクライアントデバイス１０４が示されているが、実際には、アプリケーションサーバ１０２と通信する多数のクライアントデバイス１０４があることは、理解されるべきである。また、単一のアプリケーションサーバ１０２が示されているが、任意の数のアプリケーションサーバ１０２が、クライアントデバイス１０４をサービスするために、システム１００の背後に配備され得る。
【００１２】
一実施形態において、システム１００は、アプリケーションファイアウォール１０６、学習エンジン１０８、および、データストレージモジュール１１０を含む。アプリケーションファイアウォール１０６は、サーバ１０２からクライアントデバイス１０４に、および、クライアントデバイス１０４からサーバ１０２に送信されるパケット１１８をモニタする。アプリケーションファイアウォール１０６は、モニタされたパケット１１８を構文解析し、学習エンジン１０８によって提供されるフィルタリングルール１１６に従って、悪意あるパケットまたは望まれぬパケット１１８をフィルタリングする。フィルタリングルール１１６は、サーバ１０２とクライアントデバイス１０４との間で送信される特定のパケット１１８を通過または阻止する基準を有するアプリケーションファイアウォール１０６を提供する。
【００１３】
アプリケーションファイアウォール１０６は、モニタされたパケット１１８を構文解析し、学習エンジン１０８によって提供されたデータ収集パラメータ１１２に従って収集されたデータ１１４を学習エンジン１０８に提供する。データ収集パラメータ１１２は、アプリケーションファイアウォール１０６に、アプリケーションファイアウォール１０６がモニタされたパケット１１８から収集すべきデータの型に関する基準を提供する。これらデータ収集パラメータ１１２は、例えば、通信プロトコルに従うパケット１１８に対応する名前−値（名前−属性）のペアを集めるために、パケット１１８を構文解析する方法を含む。しかしながら、典型的な実施形態において、アプリケーションファイアウォール１０６は、アプリケーションサーバ１０４によって使用されるような基盤プロトコル定義（例えば、文書型定義（ＤＴＤ））に対するアクセスを有しない。
【００１４】
一実施形態において、アプリケーションファイアウォール１０６自身は、そのアプリケーションファイアウォール機能専用のコンピュータシステム実行中ソフトウェアであり得る。別の実施形態において、アプリケーションファイアウォール１０６は、コンピュータシステム１００上で実行中の大きなソフトウェアシステムの一部であるソフトウェアモジュールであり得る。
【００１５】
学習エンジン１０８は、フィルタリングルール１１６およびデータ収集パラメータ１１２をアプリケーションファイアウォール１０６に提供し、データ収集パラメータ１１２に従って、アプリケーションファイアウォール１０６によって収集されたデータ１１４を受信する。パケット１１８は、使用された通信プロトコルに従って、サーバ１０２とクライアントデバイス１０４との間で送信されるパケットである。例えば、パケット１１８は、また、ＸＭＬパケットまたはＳＯＡＰパケットでもあり得る。アプリケーションファイアウォール１０６は、パケット１１８を名前−値（名前−属性）のペア１１４に構文解析し、学習エンジン１０８は、パケット１１８間のサーバ状態オブジェクトを同定するさらなる処理のために、これらの名前−値のペア１１４を受信する。名前−値（名前−属性）のペアは、また、本明細書で、「データオブジェクト」とも称される。
【００１６】
学習エンジン１０８は、アプリケーションファイアウォール１０６から受信されたデータオブジェクト１１４すなわち名前−値のペア１１４を解析することによって、サーバ１０２とクライアントデバイス１０４との間で送信されるパケット１１８間のサーバ状態オブジェクトを同定する。この点について、学習エンジン１０８は、名前−値のペア１１４を同定し、各同定された名前フィールドに対して、その名前に対する値を連結する。各名前に対する値の最小数を累積した後、学習エンジン１０８は、次いで、圧縮アルゴリズムを用いて、その名前に対する連結値を圧縮する。圧縮アルゴリズムは、Ｌｅｍｐｅｌ−Ｚｉｖ型圧縮アルゴリズムのようなエントロピベースの圧縮アルゴリズムであり得る。次いで、学習エンジン１０８は、圧縮値の合計サイズをその同じ名前を有する値の合計数で割ることで、圧縮値のそれぞれのエントロピを計算する。
【００１７】
学習エンジン１０８は、データオブジェクトの計算されたエントロピに従って、データオブジェクトからサーバ状態オブジェクトでありそうな候補データオブジェクトを選択する。サーバ状態オブジェクトは、典型的には、各クライアントの状態を維持するために、データオブジェクトの値フィールド内の比較的明確なストリングを含むので、サーバ状態オブジェクトのエントロピは、高くなりそうである。このように、一実施形態において、学習エンジン１０８は、候補データオブジェクトとして、閾値より高いエントロピ値を有するデータオブジェクトを選択する。エントロピに対する閾値は、パケット１１８の通信に用いられる基盤通信プロトコルによって異なる。典型的なサーバ状態オブジェクトは、３２ビット以上に相当するエントロピ値を有する。なぜなら、そのオブジェクトは、さらに、サーバインプリメンテーションまたはデータベーステーブル内のキーを参照するオブジェクトであることが多いからである。このように、一実施形態において、閾値は、２４ビットに相当するエントロピレベルに設定される。
【００１８】
候補データオブジェクトが、アプリケーションサーバ１０２からクライアントデバイス１０４へ、かつ、クライアントデバイス１０４からアプリケーションサーバ１０２へと双方に送信された場合、学習エンジン１０８は、１つ以上の候補データオブジェクトをサーバ状態オブジェクトとして同定する。これは、サーバ状態オブジェクトが、アプリケーションサーバ１０２によってクライアントデバイス１０４に送信され、クライアントデバイス１０４に格納されたからである。こうして、アプリケーションサーバ１０２は、後にクライアントデバイス１０４を同定し得る。また、サーバ状態オブジェクトが、後に、クライアントデバイス１０４からアプリケーションサーバ１０２に送信されたからである。こうして、クライアントデバイス１０４は、自らをアプリケーションサーバ１０２に同定し得る。
【００１９】
一実施形態において、学習エンジン１０８は、通信プロトコル下にある関連パケットを、サーバからクライアントデバイスに送信された第一のパケットのグループと、クライアントデバイスからサーバに送信された第二のパケットのグループとに、分けることによって、サーバ１０２とクライアントデバイス１０４との間で双方向に送信された候補データオブジェクトを同定する。関連パケットは、通信プロトコル下の「関連メッセージ」に対応するパケットである。例えば、ＨＴＴＰセッションの要求／応答通信の一部を形成するパケットは、ＨＴＴＰプロトコル下の関連パケットである。ＳＯＡＰにおいて、要求および応答は、個別の接続で実行され得る。それゆえ、ＳＯＡＰ下の関連パケットの概念は、外部的に提供される。一実施形態において、（ソースＩＰアドレス／ポートと目的地ＩＰアドレス／ポートとに基づく）同じソースポイントと目的地ポイントとの間のメッセージは、ＳＯＡＰ下の関連パケットと考えられ得る。他の実施形態において、（ＵＲＬ（統一リソースロケータ）によって同定された）２つの同じサービスの間のメッセージは、ＳＯＡＰ下の関連パケットと考えられる。学習エンジン１０８は、サーバ状態オブジェクトとして、第一のパケットのグループと第二のパケットのグループとの双方に含まれる候補データオブジェクトを同定する。
【００２０】
一実施形態において、データストレージモジュール１１０は、収集されたデータ１１４および他の暫定データを一時的に格納する。その間、パケット１１８の中からサーバ状態オブジェクトを同定するために、データオブジェクト１１４が、アプリケーションファイアウォール１０６から受信されたとき、学習エンジン１０８は、収集されたデータ１１４をリアルタイムで解析する。別の実施形態において、ストレージモジュール１１０は、所定の期間にわたり、または、格納されたデータオブジェクトが特定の閾値に達するまで、収集されたデータ１１４の中に受信されたデータオブジェクトを格納し、学習エンジン１０８は、このデータオブジェクトがサーバ状態オブジェクトであるかどうかを判断するために、格納されたデータオブジェクトをバッチ処理する。
【００２１】
図２は、ステートレス通信プロトコルに基づくネットワーク上で、サーバ１０２とクライアントデバイス１０４との間で送信されたパケット１１８の中から、サーバ状態オブジェクトを同定する方法を示す流れ図である。図２に記載された方法は、図１のシステム１００内で実行され得る。
【００２２】
本方法が、開始２０２されると、アプリケーションファイアウォール１０６は、サーバ１０２からクライアントデバイス１０４に、あるいは、クライアントデバイス１０４からサーバ１０２に送信されたパケット１１８を、複数の名前−値のペア（データオブジェクト）に構文解析２０４する。図３は、名前−値のペア３０３の例を示す。図３を参照すると、パケット１１８は、構文解析され、名前３０２と、その名前３０２に対応する値（属性）３０４とに分けられる。例えば、名前「注文ＩＤ」３０５は、ウェブサイト１０２とクライアントデバイス１０４との間で実行されたインターネット販売のトランザクションに対応する名前であり得る。これらの名前フィールド「注文ＩＤ」３０５は、対応する値フィールド「ＡＢＣＤＥＦＡＢＣＤＥＦ」、「１１１ＢＢＣＣＣＤＤＤ」および「ＤＤＤＣＣＣｌ１１２２３３」を有する。名前フィールド「著者」３０６、「課金番号」３０７および「題名」３０８は、対応する値フィールド「ジョン」、「１２３４５６７８９」および「インターネット販売」をそれぞれ有する。図３は、３つの名前−値のペア３０３しか示していないが、実際には、いつでも、アプリケーションファイアウォール１０６によって維持管理される数百あるいは数千もの名前−値のペア３０３であり得る。
【００２３】
図２に戻って参照すると、学習エンジン１０８は、同じ名前フィールドを有する構文解析されたデータオブジェクトの値フィールドを連結２０６する。例えば、図３の名前−値のペアの幾つかは、同じ名前「注文ＩＤ」３０５を有する。このように、名前「注文ＩＤ」に対応する値フィールド３０４は、名前フィールド「注文ＩＤ」３０５に対応する連結値「ＡＢＣＤＥＦＡＢＣＤＥＦ１１１ＢＢＣＣＣＤＤＤＤＤＤＣＣＣ１１１２２３３」を得るために、連結される。
【００２４】
任意の所定の名前に対する最小数の名前−値のペアが、同定された後、学習エンジン１０８は、圧縮アルゴリズムを用いて、その名前に対する連結値を圧縮２０８する。一実施形態において、圧縮アルゴリズムは、Ｌｅｍｐｅｌ−Ｚｉｖタイプの圧縮アルゴリズムのようなエントロピベースの圧縮アルゴリズムであり得る。次いで、学習エンジン１０８は、圧縮連結値リストの合計サイズを、その名前に対する名前−値のペアの合計数で割ることによって、圧縮連結値のエントロピを計算２１０する。それゆえ、図３に示す例において、連結値リスト「ＡＢＣＤＥＦＡＢＣＤＥＦ１１１ＢＢＣＣＣＤＤＤＤＤＤＣＣＣ１１１２２３３」は、圧縮アルゴリズムを用いて、圧縮２０８され、圧縮連結値の合計サイズは、その同じ名前フィールド（「注文ＩＤ」）を有する名前−値のペアの数（図３に示す例では、３）で割られる。
【００２５】
明らかなように、サーバ状態オブジェクトとなる潜在的候補となるデータオブジェクトは多数あり、これら各候補のそれぞれに対し、計算されたエントロピメジャがある。この潜在的候補のセットから、学習エンジン１０８は、計算されたエントロピに従って、サーバ状態オブジェクトとなりそうな候補名前−値のペアを選択２１２する。既に述べたように、一実施形態において、学習エンジン１０８は、候補名前−値のペアとして、所定の閾値より高いエントロピメジャを有する名前−値のペアを選択する。エントロピに対する閾値は、パケット１１８の送信に使用される基盤通信プロトコルによって異なる。典型的なサーバ状態オブジェクトは、３２ビット以上に相当するエントロピ値を有する。なぜなら、そのオブジェクトは、サーバインプリメンテーションまたはデータベーステーブル内のキーを参照するオブジェクトであることが多いからである。このように、一実施形態において、閾値は、２４ビットに相当するエントロピレベルに設定される。こうして、前述の「注文ＩＤ」および「課金番号」は、十分に高いエントロピを有するものとして選択され得る。その一方、「著者」および「題名」は、十分に高いエントロピを有するものとして選択され得ない。
【００２６】
次いで、学習エンジン１０８は、どの名前−値のペアが、アプリケーションサーバ１０２とクライアントデバイス１０４との間で双方向に送信されたかを判断２１４する。その候補名前−値のペアが双方向に送信されたら、学習エンジン１０８は、その名前−値のペアをサーバ状態オブジェクトとして、ラベル付け２１８する。その候補名前−値のペアが双方向に送信されなかったたら、学習エンジン１０８は、その名前−値のペアはサーバ状態オブジェクトでないと、判断２１６する。
【００２７】
図４は、図２に記載されたようにサーバとクライアントデバイスとの間で双方向に送信された名前−値のペアを同定するプロセスを示す。前述のように、学習エンジン１０８は、候補名前−値のペアがアプリケーションサーバ１０２とクライアントデバイス１０４との間で双方向に送信された場合、その名前−値のペアの１つ以上をサーバ状態オブジェクトとして同定する。これは、サーバ状態オブジェクトが、アプリケーションサーバ１０２によってクライアントデバイス１０４に送信され、クライアントデバイス１０４に格納されたからである。こうして、アプリケーションサーバ１０２は、後にクライアントデバイス１０４を同定し得る。また、サーバ状態オブジェクトが、後に、クライアントデバイス１０４からアプリケーションサーバ１０２に送信されたからである。こうして、クライアントデバイス１０４は、自らをアプリケーションサーバ１０２に同定し得る。
【００２８】
図４を参照すると、一実施形態において、学習エンジン１０８は、通信プロトコル下にある関連パケット１１８を、アプリケーションファイアウォール１０６によって対応するパケットの受領を示すそのパケットの関連タイムスタンプの順番に、アプリケーションサーバ１０２からクライアントデバイス１０４に送信された第一のパケットのグループ４０２と、クライアントデバイス１０４からアプリケーションサーバ１０２に送信された第二のパケットのグループ４０４とに分ける。関連パケットは、通信プロトコル下の関連メッセージに対応するパケットである。例えば、ＨＴＴＰセッションの要求／応答通信の一部を形成するパケットは、ＨＴＴＰプロトコル下の関連パケットである。ＳＯＡＰにおいて、要求および応答は、個別の接続で実行され得る。それゆえ、ＳＯＡＰ下の関連パケットの概念は、外部的に提供される。一実施形態において、（ソースＩＰアドレス／ポートと目的地ＩＰアドレス／ポートとに基づく）同じソースポイントと目的地ポイントとの間のメッセージは、ＳＯＡＰ下の関連パケットと考えられ得る。他の実施形態において、（ＵＲＬ（統一リソースロケータ）によって同定された）２つの同じサービス間のメッセージは、ＳＯＡＰ下の関連パケットと考えられる。図４に示す例において、名前−値のペア４０６、４０８、４１０および４１２は、アプリケーションサーバ１０２とクライアントデバイス１０４との間で双方向に送信された候補名前−値のペアである。図４には示されていないが、これらの名前−値のペア４０６、４０８、４１０、４１２以外にも、追加の候補名前−値のペアも、またあり得ることは留意されるべきである。
【００２９】
学習エンジン１０８は、第一のパケットのグループ４０２と第二のパケットのグループ４０４との双方に含まれる名前−値のペアを、サーバ状態オブジェクトとし、同定する。例えば、候補名前−値のペア４０６、４０８、４１０、４１２、４２０、４２２は、第一のパケットのグループ４０２と第二のパケットのグループ４０４との双方に含まれ、学習エンジン１０８によって、サーバ状態オブジェクトと判断される。しかしながら、候補名前−値のペア４１６および４１８は、第二のパケットのグループ４０４の中にしか含まれておらず、それゆえ、サーバ状態オブジェクトではない。
【００３０】
本発明は、たとえ、仲介サーバが基盤通信プロトコルに対するアクセスを有しないＸＭＬまたはＳＯＡＰのような構造化度の低いステートレスデータ通信が使用されたときでさえも、アプリケーションサーバとクライアントデバイスとの間で双方向に送信されるサーバ状態オブジェクトが、フィルタまたはゲートウェーのような仲介サーバによって同定され得るというメリットを有する。これによって、このように構造化度の低いステートレスデータ通信プロトコルを用いるインターネットトランザクションのインプリメンテーションが容易になる。なぜなら、サーバは、サーバ状態オブジェクトを調査することによって、そのサーバと以前に通信したクライアントデバイスを同定し得るからである。
【００３１】
本発明は、幾つかの実施形態の観点から、以上に説明されてきたが、様々な変更も本発明の範囲内でなされ得る。例えば、本発明は、任意の通信プロトコルに限定されないし、また、任意のステートレス通信プロトコルとともに使用され得る。図１のシステム１００のアーキテクチャは、単なる例示に過ぎず、システム１００がアプリケーションサーバ１０２とクライアントデバイス１０４との間で送信されるパケットをモニタし得るシステムである限り、任意の方法で変更され得る。データオブジェクトの値フィールドの圧縮は、任意のタイプの圧縮アルゴリズムを用いて行われ得、連結圧縮データオブジェクトのエントロピの計算方法は、本明細書の記載に限定されない。双方向パケットを同定する方法は、本明細書の図４で記載されたことに限定されないし、異なる方法も、アプリケーションサーバ１０２とクライアントデバイスとの間で双方向に送信されるパケットを同定する適切な方法である限り、使用され得る。また、複数のクライアントデバイス１０４が、１つのアプリケーションサーバ１０２と通信するときも、あるいは、１つのクライアントデバイス１０４が複数のアプリケーション１０２と通信するときも、本発明は、サーバ状態オブジェクトを同定するために使用され得る。
【００３２】
したがって、本発明の開示は、本発明の範囲を例示するものであって、限定するものではなく、本発明の範囲は以下の請求項で示される。
【図面の簡単な説明】
【００３３】
【図１】図１は、本発明の一実施形態に従って、サーバ状態オブジェクトを同定するシステムのアーキテクチャを示すブロック図である。
【図２】図２は、本発明の一実施形態に従って、サーバ状態オブジェクトを同定する方法を示す流れ図である。
【図３】図３は、名前−値のペアを示す図である。
【図４】図４は、サーバとクライアントデバイスとの間の双方向送信される名前−値のペアを同定するステップを示す図である。
【特許請求の範囲】
【請求項１】
通信プロトコルに基づくネットワーク上で、サーバとクライアントデバイスとの間で送信されるパケット間のサーバ状態オブジェクトを同定する方法であって、該方法は、
該パケット中の複数のデータオブジェクトに対するエントロピメジャを計算することと、
該複数のデータオブジェクトのエントロピメジャに従って、該複数のデータオブジェクトから候補データオブジェクトを選択することと、
該候補データオブジェクトの少なくとも１つを、該少なくとも１つの候補データオブジェクトが該サーバと該クライアントデバイスとの間で双方向に送信されることに応答して、サーバ状態オブジェクトとして同定することと
を包含する、方法。
【請求項２】
エントロピメジャを計算することは、
前記データオブジェクトを圧縮することと、
該圧縮データオブジェクトの該エントロピメジャを計算することと
を包含する、請求項１に記載の方法。
【請求項３】
前記データオブジェクトを圧縮することは、
同じ名前フィールドを有する該データオブジェクトを連結することと、
圧縮アルゴリズムを用いて、該連結データオブジェクトを圧縮することと
を包含する、請求項２に記載の方法。
【請求項４】
前記圧縮アルゴリズムは、エントロピベースの圧縮アルゴリズムである、請求項３に記載の方法。
【請求項５】
前記圧縮データオブジェクトの前記エントロピメジャを計算することは、前記圧縮連結データオブジェクトの値フィールドの合計サイズを、前記同じ名前フィールドを有するデータオブジェクトの合計数で割ることを包含する、請求項３に記載の方法。
【請求項６】
前記少なくとも１つの候補データオブジェクトが、前記サーバと前記クライアントデバイスとの間で双方向に送信されたことは、
前記通信プロトコル下にある関連パケットを、該サーバから該クライアントデバイスに送信された第一のパケットのグループと、該クライアントデバイスから該サーバに送信された第二のパケットのグループとに分けることと、
前記少なくとも１つの候補データオブジェクトは、該第一のパケットのグループと該第二のパケットのグループとの双方に含まれるかどうかを判断することと
によって判断される、請求項１に記載の方法。
【請求項７】
前記関連パケットは、前記通信プロトコル下の関連メッセージに対応するパケットである、請求項６に記載の方法。
【請求項８】
通信プロトコルに基づくネットワーク上で、サーバとクライアントデバイスとの間で送信されるパケット間のサーバ状態オブジェクトを同定する方法であって、該方法は、
該パケットを複数の名前−値のペアに構文解析することと、
同じ名前を有する名前−値のペアのエントロピを計算することと、
該サーバ状態オブジェクトに対する候補として、閾値より高いエントロピを有する名前−値のペアを選択することと、
該候補が、該サーバと該クライアントデバイスとの間で双方向に送信されたかどうかを判断することと、
該候補の少なくとも１つを、該少なくとも１つの候補が該サーバと該クライアントデバイスとの間で双方向に送信されたことに応答して、サーバ状態オブジェクトとして同定することと
を包含する、方法。
【請求項９】
同じ名前を有する前記名前−値のペアの前記エントロピを計算することは、
該同じ名前を有する該名前−値のペアを圧縮することと、
該圧縮名前−値のペアの該エントロピを計算することと
を包含する、請求項８に記載の方法。
【請求項１０】
前記同じ名前を有する前記名前−値のペアを圧縮することは、
該同じ名前を有する該名前−値のペアの値フィールドを連結することと、
圧縮アルゴリズムを用いて、該名前−値のペアの該連結値フィールドを圧縮することと
を包含する、請求項９に記載の方法。
【請求項１１】
前記圧縮アルゴリズムは、エントロピベースの圧縮アルゴリズムである、請求項１０に記載の方法。
【請求項１２】
前記圧縮名前−値のペアの前記エントロピを計算することは、前記名前−値のペアの前記圧縮連結値フィールドの合計サイズを、前記同じ名前を有する該名前−値のペアの合計数によって割ることを包含する、請求項１０に記載の方法。
【請求項１３】
前記候補が、前記サーバと前記クライアントデバイスとの間で双方向に送信されたかどうかを判断することは、
前記通信プロトコル下にある関連パケットを、該サーバから該クライアントデバイスに送信された第一のパケットのグループと、該クライアントデバイスから該サーバに送信された第二のパケットのグループとに分けることと、
前記候補は、該第一のパケットのグループと該第二のパケットのグループとの双方に含まれるかどうかを判断することと
を包含する、請求項８に記載の方法。
【請求項１４】
前記関連パケットは、前記通信プロトコル下の関連メッセージに対応するパケットである、請求項１３に記載の方法。
【請求項１５】
通信プロトコルに基づくネットワーク上で、サーバとクライアントデバイスとの間で送信されるパケット間のサーバ状態オブジェクトを同定するシステムであって、該システムは、
該サーバと該クライアントデバイスとの間に結合され、両者間で送信されたパケットを複数のデータオブジェクト間で送信されたパケットを複数の名前−値のペアに構文解析するための構文解析モジュールと、
該構文解析モジュールに結合され、該データオブジェクトを受信し、該データオブジェクトがサーバ状態オブジェクトであるかどうかを
該データオブジェクトのエントロピメジャを計算することと、
該複数のデータオブジェクトのエントロピメジャに従って、該複数のデータオブジェクトから候補データオブジェクトを選択することと、
該候補データオブジェクトの少なくとも１つを、該サーバと該クライアントデバイスとの間で双方向に送信される該少なくとも１つのデータオブジェクトに応答して、サーバ状態オブジェクトとして同定することと
によって判断する解析モジュールと
を備える、システム。
【請求項１６】
前記構文解析モジュールは、前記解析モジュールによって提供されるルールに従って、前記サーバと前記クライアントデバイスとの間で送信される前記パケットをフィルタリングするファイアウォールとして動作する、請求項１５に記載のシステム。
【請求項１７】
前記構文解析モジュールは、前記解析モジュールによって提供されるデータ収集パラメータに従って、前記サーバと前記クライアントデバイスとの間で送信される前記パケットに関するデータを収集する、請求項１５に記載のシステム。
【請求項１８】
前記データオブジェクトが前記構文解析モジュールから受信されるとき、該データオブジェクトがサーバ状態オブジェクトであるかどうかを判断するために、前記解析モジュールは、該データオブジェクトをリアルタイムで処理する、請求項１５に記載のシステム。
【請求項１９】
前記解析モジュールに結合されたストレージモジュールをさらに備え、
該解析モジュールは、前記受信したデータオブジェクトを該ストレージモジュールの中に格納し、該データオブジェクトがサーバ状態オブジェクトであるかどうかを判断するために、該格納されたデータオブジェクトをバッチで処理する、請求項１５に記載のシステム。
【請求項２０】
前記解析モジュールは、前記データオブジェクトの前記エントロピメジャを
該データオブジェクトを圧縮することと、
該圧縮データオブジェクトの該エントロピメジャを計算することと
によって計算する、請求項１５に記載のシステム。
【請求項２１】
前記解析モジュールは、前記データオブジェクトを
同じ名前フィールドを有する該データオブジェクトを連結することと、
圧縮アルゴリズムを用いて、該連結データオブジェクトを圧縮することと
によって圧縮する、請求項２０に記載のシステム。
【請求項２２】
前記圧縮アルゴリズムは、エントロピベースの圧縮アルゴリズムである、請求項２１に記載のシステム。
【請求項２３】
前記解析モジュールは、前記圧縮連結データオブジェクトの値フィールドの合計サイズを、前記同じ名前フィールドを有するデータオブジェクトの合計数で割ることによって、前記圧縮データオブジェクトの前記エントロピメジャを計算する、請求項２１に記載のシステム。
【請求項２４】
前記解析モジュールは、前記少なくとも１つの候補データオブジェクトが、前記サーバと前記クライアントデバイスとの間で双方向に送信されたことを
前記通信プロトコル下にある関連パケットを、該サーバから該クライアントデバイスに送信された第一のパケットのグループと、該クライアントデバイスから該サーバに送信された第二のパケットのグループとに分けることと、
前記少なくとも１つの候補データオブジェクトは、該第一のパケットのグループと該第二のパケットのグループとの双方に含まれるかどうかを判断することと
によって判断する、請求項１５に記載のシステム。
【請求項２５】
前記関連パケットは、前記通信プロトコル下の関連メッセージに対応するパケットである、請求項２４に記載のシステム。
【請求項２６】
通信プロトコルに基づくネットワーク上で、サーバとクライアントデバイスとの間で送信されるパケット間のサーバ状態オブジェクトを同定するシステムであって、該システムは、
該サーバと該クライアントデバイスとの間に結合され、両者間で送信されたパケットを複数の名前−値のペアに構文解析するための構文解析モジュールと、
同じ名前を有する該名前−値のペアのエントロピを計算することと、
該サーバ状態オブジェクトに対する候補として、閾値より高いエントロピを有する該名前−値のペアを選択することと、
該サーバと該クライアントデバイスとの間で双方向に送信されたかどうかを判断することと、
該候補の少なくとも１つは、該少なくとも１つの候補が該サーバと該クライアントデバイスとの間で双方向に送信されたとの判断に応答して、サーバ状態オブジェクトであると判断することと
によって判断する解析モジュールと
を備える、システム。
【請求項２７】
前記構文解析モジュールは、前記解析モジュールによって提供されるルールに従って、前記サーバと前記クライアントデバイスとの間で送信される前記パケットをフィルタリングするファイアウォールとして動作する、請求項２６に記載のシステム。
【請求項２８】
前記構文解析モジュールは、前記解析モジュールによって提供されるデータ収集パラメータに従って、前記サーバと前記クライアントデバイスとの間で送信される前記パケットに関するデータを収集する、請求項２６に記載のシステム。
【請求項２９】
前記名前−値のペアが前記構文解析モジュールから受信されるとき、該名前−値のペアがサーバ状態オブジェクトであるかどうかを判断するために、前記解析モジュールは、該名前−値のペアをリアルタイムで処理する、請求項２６に記載のシステム。
【請求項３０】
前記解析モジュールに結合されたストレージモジュールをさらに備え、
該解析モジュールは、該ストレージモジュールの中に前記受信した名前−値のペアを格納し、該名前−値のペアがサーバ状態オブジェクトであるかどうかを判断するために、該格納された名前−値のペアをバッチで処理する、請求項２６に記載のシステム。
【請求項３１】
前記解析モジュールは、同じ名前を有する前記名前−値のペアの前記エントロピを
該同じ名前を有する該名前−値のペアを圧縮することと、
該圧縮名前−値のペアの該エントロピを計算することと
によって計算する、請求項２６に記載のシステム。
【請求項３２】
前記解析モジュールは、前記同じ名前を有する前記名前−値のペアを
該同じ名前を有する該名前−値のペアの値フィールドを連結することと、
圧縮アルゴリズムを用いて、該名前−値のペアの該連結値フィールドを圧縮することと
によって圧縮する、請求項３１に記載のシステム。
【請求項３３】
前記圧縮アルゴリズムは、エントロピベースの圧縮アルゴリズムである、請求項３２に記載のシステム。
【請求項３４】
前記解析モジュールは、前記圧縮名前−値のペアの前記エントロピを
該名前−値のペアの前記圧縮連結値フィールドの合計サイズを、前記同じ名前を有する該名前−値のペアの合計数によって割ること
によって計算する、請求項３２に記載のシステム。
【請求項３５】
前記解析モジュールは、前記候補が前記サーバと前記クライアントデバイスとの間で双方向に送信されたことを
前記通信プロトコル下にある関連パケットを、該サーバから該クライアントデバイスに送信された第一のパケットのグループと、該クライアントデバイスから該サーバに送信された第二のパケットのグループとに分けることと、
前記候補は、該第一のパケットのグループと該第二のパケットのグループとの双方に含まれるかどうかを判断することと
によって判断する、請求項２６に記載のシステム。
【請求項３６】
前記関連パケットは、前記通信プロトコル下の関連メッセージに対応するパケットである、請求項３５に記載のシステム。
【請求項３７】
コンピュータ可読媒体上に格納され、通信プロトコルに基づくネットワーク上でサーバとクライアントデバイスとの間で送信されるパケット間のサーバ状態オブジェクトを同定する方法を実行するように適合されたコンピュータプログラム製品であって、該方法は、
該パケット中の複数のデータオブジェクトに対するエントロピメジャを計算することと、
該複数のデータオブジェクトのエントロピメジャに従って、該複数のデータオブジェクトから候補データオブジェクトを選択することと、
該候補データオブジェクトの少なくとも１つを、該少なくとも１つの候補データオブジェクトが該サーバと該クライアントデバイスとの間で双方向に送信されることに応答して、サーバ状態オブジェクトとして同定することと
を包含する、コンピュータプログラム製品。
【請求項３８】
エントロピメジャを計算することは、
前記データオブジェクトを圧縮することと、
該圧縮データオブジェクトの該エントロピメジャを計算することと
を包含する、請求項３７に記載のコンピュータプログラム製品。
【請求項３９】
前記データオブジェクトを圧縮することは、
同じ名前フィールドを有する該データオブジェクトを連結することと、
圧縮アルゴリズムを用いて、該連結データオブジェクトを圧縮することと
を包含する、請求項３８に記載のコンピュータプログラム製品。
【請求項４０】
前記圧縮データオブジェクトの前記エントロピメジャを計算することは、前記圧縮連結データオブジェクトの値フィールドの合計サイズを、前記同じ名前フィールドを有するデータオブジェクトの合計数で割ることを包含する、請求項３９に記載のコンピュータプログラム製品。
【請求項４１】
前記少なくとも１つの候補データオブジェクトが、前記サーバと前記クライアントデバイスとの間で双方向に送信されたことは、
前記通信プロトコル下にある関連パケットを、該サーバから該クライアントデバイスに送信された第一のパケットのグループと、該クライアントデバイスから該サーバに送信された第二のパケットのグループとに分けることと、
前記少なくとも１つの候補データオブジェクトは、該第一のパケットのグループと該第二のパケットのグループとの双方に含まれるかどうかを判断することと
によって判断される、請求項３７に記載のコンピュータプログラム製品。
【請求項４２】
コンピュータ可読媒体上に格納され、通信プロトコルに基づくネットワーク上でサーバとクライアントデバイスとの間で送信されるパケット間のサーバ状態オブジェクトを同定する方法を実行するように適合されたコンピュータプログラム製品であって、該方法は、
該パケットを複数の名前−値のペアに構文解析することと、
同じ名前を有する名前−値のペアのエントロピを計算することと、
該サーバ状態オブジェクトに対する候補として、閾値より高いエントロピを有する名前−値のペアを選択することと、
該候補が、該サーバと該クライアントデバイスとの間で双方向に送信されたかどうかを判断することと、
該候補の少なくとも１つを、該少なくとも１つの候補が該サーバと該クライアントデバイスとの間で双方向に送信されたことに応答して、サーバ状態オブジェクトとして同定することと
を包含する、コンピュータプログラム製品。
【請求項４３】
同じ名前を有する前記名前−値のペアの前記エントロピを計算することは、
該同じ名前を有する該名前−値のペアを圧縮することと、
該圧縮名前−値のペアの該エントロピを計算することと
を包含する、請求項４２に記載のコンピュータプログラム製品。
【請求項４４】
前記同じ名前を有する前記名前−値のペアを圧縮することは、
該同じ名前を有する該名前−値のペアの値フィールドを連結することと、
圧縮アルゴリズムを用いて、該名前−値のペアの該連結値フィールドを圧縮することと
を包含する、請求項４３に記載のコンピュータプログラム製品。
【請求項４５】
前記圧縮名前−値のペアの前記エントロピを計算することは、前記名前−値のペアの前記圧縮連結値フィールドの合計サイズを、前記同じ名前を有する該名前−値のペアの合計数によって割ることを包含する、請求項４４に記載のコンピュータプログラム製品。
【請求項４６】
前記候補が、前記サーバと前記クライアントデバイスとの間で双方向に送信されたかどうかを判断することは、
前記通信プロトコル下にある関連パケットを、該サーバから該クライアントデバイスに送信された第一のパケットのグループと、該クライアントデバイスから該サーバに送信された第二のパケットのグループとに分けることと、
前記候補は、該第一のパケットのグループと該第二のパケットのグループとの双方に含まれるかどうかを判断することと
を包含する、請求項４２に記載のコンピュータプログラム製品。
【請求項４７】
通信プロトコルに基づくネットワーク上で、サーバとクライアントデバイスとの間で送信されるパケット間のサーバ状態オブジェクトを同定するシステムであって、該システムは、
該サーバと該クライアントデバイスとの間に結合され、両者間で送信されたパケットを複数のデータオブジェクトに構文解析するための構文解析手段と、
該構文解析手段に結合され、該データオブジェクトを受信し、該データオブジェクトがサーバ状態オブジェクトであるかどうかを
該データオブジェクトのエントロピメジャを計算することと、
該複数のデータオブジェクトのエントロピメジャに従って、該複数のデータオブジェクトから候補データオブジェクトを選択することと、
該候補データオブジェクトの少なくとも１つを、該サーバと該クライアントデバイスとの間で双方向に送信される該少なくとも１つのデータオブジェクトに応答して、サーバ状態オブジェクトとして同定することと
によって判断する解析手段と
を備える、システム。
【請求項４８】
通信プロトコルに基づくネットワーク上で、サーバとクライアントデバイスとの間で送信されるパケット間のサーバ状態オブジェクトを同定するシステムであって、該システムは、
該サーバと該クライアントデバイスとの間に結合され、両者間で送信されたパケットを複数の名前−値のペアに構文解析するための構文解析手段と、
該構文解析手段に結合され、該名前−値のペアを受信し、該名前−値のペアがサーバ状態オブジェクトであるかどうかを
同じ名前を有する該名前−値のペアのエントロピを計算することと、
該サーバ状態オブジェクトに対する候補として、所定の閾値より高いエントロピを有する該名前−値のペアを選択することと、
該サーバと該クライアントデバイスとの間で双方向に送信されたかどうかを判断することと、
該候補の少なくとも１つは、該少なくとも１つの候補が該サーバと該クライアントデバイスとの間で双方向に送信されたとの判断に応答して、サーバ状態オブジェクトであることを判断することと
によって判断する解析手段と
を備える、システム。
【請求項１】
通信プロトコルに基づくネットワーク上で、サーバとクライアントデバイスとの間で送信されるパケット間のサーバ状態オブジェクトを同定する方法であって、該方法は、
該パケット中の複数のデータオブジェクトに対するエントロピメジャを計算することと、
該複数のデータオブジェクトのエントロピメジャに従って、該複数のデータオブジェクトから候補データオブジェクトを選択することと、
該候補データオブジェクトの少なくとも１つを、該少なくとも１つの候補データオブジェクトが該サーバと該クライアントデバイスとの間で双方向に送信されることに応答して、サーバ状態オブジェクトとして同定することと
を包含する、方法。
【請求項２】
エントロピメジャを計算することは、
前記データオブジェクトを圧縮することと、
該圧縮データオブジェクトの該エントロピメジャを計算することと
を包含する、請求項１に記載の方法。
【請求項３】
前記データオブジェクトを圧縮することは、
同じ名前フィールドを有する該データオブジェクトを連結することと、
圧縮アルゴリズムを用いて、該連結データオブジェクトを圧縮することと
を包含する、請求項２に記載の方法。
【請求項４】
前記圧縮アルゴリズムは、エントロピベースの圧縮アルゴリズムである、請求項３に記載の方法。
【請求項５】
前記圧縮データオブジェクトの前記エントロピメジャを計算することは、前記圧縮連結データオブジェクトの値フィールドの合計サイズを、前記同じ名前フィールドを有するデータオブジェクトの合計数で割ることを包含する、請求項３に記載の方法。
【請求項６】
前記少なくとも１つの候補データオブジェクトが、前記サーバと前記クライアントデバイスとの間で双方向に送信されたことは、
前記通信プロトコル下にある関連パケットを、該サーバから該クライアントデバイスに送信された第一のパケットのグループと、該クライアントデバイスから該サーバに送信された第二のパケットのグループとに分けることと、
前記少なくとも１つの候補データオブジェクトは、該第一のパケットのグループと該第二のパケットのグループとの双方に含まれるかどうかを判断することと
によって判断される、請求項１に記載の方法。
【請求項７】
前記関連パケットは、前記通信プロトコル下の関連メッセージに対応するパケットである、請求項６に記載の方法。
【請求項８】
通信プロトコルに基づくネットワーク上で、サーバとクライアントデバイスとの間で送信されるパケット間のサーバ状態オブジェクトを同定する方法であって、該方法は、
該パケットを複数の名前−値のペアに構文解析することと、
同じ名前を有する名前−値のペアのエントロピを計算することと、
該サーバ状態オブジェクトに対する候補として、閾値より高いエントロピを有する名前−値のペアを選択することと、
該候補が、該サーバと該クライアントデバイスとの間で双方向に送信されたかどうかを判断することと、
該候補の少なくとも１つを、該少なくとも１つの候補が該サーバと該クライアントデバイスとの間で双方向に送信されたことに応答して、サーバ状態オブジェクトとして同定することと
を包含する、方法。
【請求項９】
同じ名前を有する前記名前−値のペアの前記エントロピを計算することは、
該同じ名前を有する該名前−値のペアを圧縮することと、
該圧縮名前−値のペアの該エントロピを計算することと
を包含する、請求項８に記載の方法。
【請求項１０】
前記同じ名前を有する前記名前−値のペアを圧縮することは、
該同じ名前を有する該名前−値のペアの値フィールドを連結することと、
圧縮アルゴリズムを用いて、該名前−値のペアの該連結値フィールドを圧縮することと
を包含する、請求項９に記載の方法。
【請求項１１】
前記圧縮アルゴリズムは、エントロピベースの圧縮アルゴリズムである、請求項１０に記載の方法。
【請求項１２】
前記圧縮名前−値のペアの前記エントロピを計算することは、前記名前−値のペアの前記圧縮連結値フィールドの合計サイズを、前記同じ名前を有する該名前−値のペアの合計数によって割ることを包含する、請求項１０に記載の方法。
【請求項１３】
前記候補が、前記サーバと前記クライアントデバイスとの間で双方向に送信されたかどうかを判断することは、
前記通信プロトコル下にある関連パケットを、該サーバから該クライアントデバイスに送信された第一のパケットのグループと、該クライアントデバイスから該サーバに送信された第二のパケットのグループとに分けることと、
前記候補は、該第一のパケットのグループと該第二のパケットのグループとの双方に含まれるかどうかを判断することと
を包含する、請求項８に記載の方法。
【請求項１４】
前記関連パケットは、前記通信プロトコル下の関連メッセージに対応するパケットである、請求項１３に記載の方法。
【請求項１５】
通信プロトコルに基づくネットワーク上で、サーバとクライアントデバイスとの間で送信されるパケット間のサーバ状態オブジェクトを同定するシステムであって、該システムは、
該サーバと該クライアントデバイスとの間に結合され、両者間で送信されたパケットを複数のデータオブジェクト間で送信されたパケットを複数の名前−値のペアに構文解析するための構文解析モジュールと、
該構文解析モジュールに結合され、該データオブジェクトを受信し、該データオブジェクトがサーバ状態オブジェクトであるかどうかを
該データオブジェクトのエントロピメジャを計算することと、
該複数のデータオブジェクトのエントロピメジャに従って、該複数のデータオブジェクトから候補データオブジェクトを選択することと、
該候補データオブジェクトの少なくとも１つを、該サーバと該クライアントデバイスとの間で双方向に送信される該少なくとも１つのデータオブジェクトに応答して、サーバ状態オブジェクトとして同定することと
によって判断する解析モジュールと
を備える、システム。
【請求項１６】
前記構文解析モジュールは、前記解析モジュールによって提供されるルールに従って、前記サーバと前記クライアントデバイスとの間で送信される前記パケットをフィルタリングするファイアウォールとして動作する、請求項１５に記載のシステム。
【請求項１７】
前記構文解析モジュールは、前記解析モジュールによって提供されるデータ収集パラメータに従って、前記サーバと前記クライアントデバイスとの間で送信される前記パケットに関するデータを収集する、請求項１５に記載のシステム。
【請求項１８】
前記データオブジェクトが前記構文解析モジュールから受信されるとき、該データオブジェクトがサーバ状態オブジェクトであるかどうかを判断するために、前記解析モジュールは、該データオブジェクトをリアルタイムで処理する、請求項１５に記載のシステム。
【請求項１９】
前記解析モジュールに結合されたストレージモジュールをさらに備え、
該解析モジュールは、前記受信したデータオブジェクトを該ストレージモジュールの中に格納し、該データオブジェクトがサーバ状態オブジェクトであるかどうかを判断するために、該格納されたデータオブジェクトをバッチで処理する、請求項１５に記載のシステム。
【請求項２０】
前記解析モジュールは、前記データオブジェクトの前記エントロピメジャを
該データオブジェクトを圧縮することと、
該圧縮データオブジェクトの該エントロピメジャを計算することと
によって計算する、請求項１５に記載のシステム。
【請求項２１】
前記解析モジュールは、前記データオブジェクトを
同じ名前フィールドを有する該データオブジェクトを連結することと、
圧縮アルゴリズムを用いて、該連結データオブジェクトを圧縮することと
によって圧縮する、請求項２０に記載のシステム。
【請求項２２】
前記圧縮アルゴリズムは、エントロピベースの圧縮アルゴリズムである、請求項２１に記載のシステム。
【請求項２３】
前記解析モジュールは、前記圧縮連結データオブジェクトの値フィールドの合計サイズを、前記同じ名前フィールドを有するデータオブジェクトの合計数で割ることによって、前記圧縮データオブジェクトの前記エントロピメジャを計算する、請求項２１に記載のシステム。
【請求項２４】
前記解析モジュールは、前記少なくとも１つの候補データオブジェクトが、前記サーバと前記クライアントデバイスとの間で双方向に送信されたことを
前記通信プロトコル下にある関連パケットを、該サーバから該クライアントデバイスに送信された第一のパケットのグループと、該クライアントデバイスから該サーバに送信された第二のパケットのグループとに分けることと、
前記少なくとも１つの候補データオブジェクトは、該第一のパケットのグループと該第二のパケットのグループとの双方に含まれるかどうかを判断することと
によって判断する、請求項１５に記載のシステム。
【請求項２５】
前記関連パケットは、前記通信プロトコル下の関連メッセージに対応するパケットである、請求項２４に記載のシステム。
【請求項２６】
通信プロトコルに基づくネットワーク上で、サーバとクライアントデバイスとの間で送信されるパケット間のサーバ状態オブジェクトを同定するシステムであって、該システムは、
該サーバと該クライアントデバイスとの間に結合され、両者間で送信されたパケットを複数の名前−値のペアに構文解析するための構文解析モジュールと、
同じ名前を有する該名前−値のペアのエントロピを計算することと、
該サーバ状態オブジェクトに対する候補として、閾値より高いエントロピを有する該名前−値のペアを選択することと、
該サーバと該クライアントデバイスとの間で双方向に送信されたかどうかを判断することと、
該候補の少なくとも１つは、該少なくとも１つの候補が該サーバと該クライアントデバイスとの間で双方向に送信されたとの判断に応答して、サーバ状態オブジェクトであると判断することと
によって判断する解析モジュールと
を備える、システム。
【請求項２７】
前記構文解析モジュールは、前記解析モジュールによって提供されるルールに従って、前記サーバと前記クライアントデバイスとの間で送信される前記パケットをフィルタリングするファイアウォールとして動作する、請求項２６に記載のシステム。
【請求項２８】
前記構文解析モジュールは、前記解析モジュールによって提供されるデータ収集パラメータに従って、前記サーバと前記クライアントデバイスとの間で送信される前記パケットに関するデータを収集する、請求項２６に記載のシステム。
【請求項２９】
前記名前−値のペアが前記構文解析モジュールから受信されるとき、該名前−値のペアがサーバ状態オブジェクトであるかどうかを判断するために、前記解析モジュールは、該名前−値のペアをリアルタイムで処理する、請求項２６に記載のシステム。
【請求項３０】
前記解析モジュールに結合されたストレージモジュールをさらに備え、
該解析モジュールは、該ストレージモジュールの中に前記受信した名前−値のペアを格納し、該名前−値のペアがサーバ状態オブジェクトであるかどうかを判断するために、該格納された名前−値のペアをバッチで処理する、請求項２６に記載のシステム。
【請求項３１】
前記解析モジュールは、同じ名前を有する前記名前−値のペアの前記エントロピを
該同じ名前を有する該名前−値のペアを圧縮することと、
該圧縮名前−値のペアの該エントロピを計算することと
によって計算する、請求項２６に記載のシステム。
【請求項３２】
前記解析モジュールは、前記同じ名前を有する前記名前−値のペアを
該同じ名前を有する該名前−値のペアの値フィールドを連結することと、
圧縮アルゴリズムを用いて、該名前−値のペアの該連結値フィールドを圧縮することと
によって圧縮する、請求項３１に記載のシステム。
【請求項３３】
前記圧縮アルゴリズムは、エントロピベースの圧縮アルゴリズムである、請求項３２に記載のシステム。
【請求項３４】
前記解析モジュールは、前記圧縮名前−値のペアの前記エントロピを
該名前−値のペアの前記圧縮連結値フィールドの合計サイズを、前記同じ名前を有する該名前−値のペアの合計数によって割ること
によって計算する、請求項３２に記載のシステム。
【請求項３５】
前記解析モジュールは、前記候補が前記サーバと前記クライアントデバイスとの間で双方向に送信されたことを
前記通信プロトコル下にある関連パケットを、該サーバから該クライアントデバイスに送信された第一のパケットのグループと、該クライアントデバイスから該サーバに送信された第二のパケットのグループとに分けることと、
前記候補は、該第一のパケットのグループと該第二のパケットのグループとの双方に含まれるかどうかを判断することと
によって判断する、請求項２６に記載のシステム。
【請求項３６】
前記関連パケットは、前記通信プロトコル下の関連メッセージに対応するパケットである、請求項３５に記載のシステム。
【請求項３７】
コンピュータ可読媒体上に格納され、通信プロトコルに基づくネットワーク上でサーバとクライアントデバイスとの間で送信されるパケット間のサーバ状態オブジェクトを同定する方法を実行するように適合されたコンピュータプログラム製品であって、該方法は、
該パケット中の複数のデータオブジェクトに対するエントロピメジャを計算することと、
該複数のデータオブジェクトのエントロピメジャに従って、該複数のデータオブジェクトから候補データオブジェクトを選択することと、
該候補データオブジェクトの少なくとも１つを、該少なくとも１つの候補データオブジェクトが該サーバと該クライアントデバイスとの間で双方向に送信されることに応答して、サーバ状態オブジェクトとして同定することと
を包含する、コンピュータプログラム製品。
【請求項３８】
エントロピメジャを計算することは、
前記データオブジェクトを圧縮することと、
該圧縮データオブジェクトの該エントロピメジャを計算することと
を包含する、請求項３７に記載のコンピュータプログラム製品。
【請求項３９】
前記データオブジェクトを圧縮することは、
同じ名前フィールドを有する該データオブジェクトを連結することと、
圧縮アルゴリズムを用いて、該連結データオブジェクトを圧縮することと
を包含する、請求項３８に記載のコンピュータプログラム製品。
【請求項４０】
前記圧縮データオブジェクトの前記エントロピメジャを計算することは、前記圧縮連結データオブジェクトの値フィールドの合計サイズを、前記同じ名前フィールドを有するデータオブジェクトの合計数で割ることを包含する、請求項３９に記載のコンピュータプログラム製品。
【請求項４１】
前記少なくとも１つの候補データオブジェクトが、前記サーバと前記クライアントデバイスとの間で双方向に送信されたことは、
前記通信プロトコル下にある関連パケットを、該サーバから該クライアントデバイスに送信された第一のパケットのグループと、該クライアントデバイスから該サーバに送信された第二のパケットのグループとに分けることと、
前記少なくとも１つの候補データオブジェクトは、該第一のパケットのグループと該第二のパケットのグループとの双方に含まれるかどうかを判断することと
によって判断される、請求項３７に記載のコンピュータプログラム製品。
【請求項４２】
コンピュータ可読媒体上に格納され、通信プロトコルに基づくネットワーク上でサーバとクライアントデバイスとの間で送信されるパケット間のサーバ状態オブジェクトを同定する方法を実行するように適合されたコンピュータプログラム製品であって、該方法は、
該パケットを複数の名前−値のペアに構文解析することと、
同じ名前を有する名前−値のペアのエントロピを計算することと、
該サーバ状態オブジェクトに対する候補として、閾値より高いエントロピを有する名前−値のペアを選択することと、
該候補が、該サーバと該クライアントデバイスとの間で双方向に送信されたかどうかを判断することと、
該候補の少なくとも１つを、該少なくとも１つの候補が該サーバと該クライアントデバイスとの間で双方向に送信されたことに応答して、サーバ状態オブジェクトとして同定することと
を包含する、コンピュータプログラム製品。
【請求項４３】
同じ名前を有する前記名前−値のペアの前記エントロピを計算することは、
該同じ名前を有する該名前−値のペアを圧縮することと、
該圧縮名前−値のペアの該エントロピを計算することと
を包含する、請求項４２に記載のコンピュータプログラム製品。
【請求項４４】
前記同じ名前を有する前記名前−値のペアを圧縮することは、
該同じ名前を有する該名前−値のペアの値フィールドを連結することと、
圧縮アルゴリズムを用いて、該名前−値のペアの該連結値フィールドを圧縮することと
を包含する、請求項４３に記載のコンピュータプログラム製品。
【請求項４５】
前記圧縮名前−値のペアの前記エントロピを計算することは、前記名前−値のペアの前記圧縮連結値フィールドの合計サイズを、前記同じ名前を有する該名前−値のペアの合計数によって割ることを包含する、請求項４４に記載のコンピュータプログラム製品。
【請求項４６】
前記候補が、前記サーバと前記クライアントデバイスとの間で双方向に送信されたかどうかを判断することは、
前記通信プロトコル下にある関連パケットを、該サーバから該クライアントデバイスに送信された第一のパケットのグループと、該クライアントデバイスから該サーバに送信された第二のパケットのグループとに分けることと、
前記候補は、該第一のパケットのグループと該第二のパケットのグループとの双方に含まれるかどうかを判断することと
を包含する、請求項４２に記載のコンピュータプログラム製品。
【請求項４７】
通信プロトコルに基づくネットワーク上で、サーバとクライアントデバイスとの間で送信されるパケット間のサーバ状態オブジェクトを同定するシステムであって、該システムは、
該サーバと該クライアントデバイスとの間に結合され、両者間で送信されたパケットを複数のデータオブジェクトに構文解析するための構文解析手段と、
該構文解析手段に結合され、該データオブジェクトを受信し、該データオブジェクトがサーバ状態オブジェクトであるかどうかを
該データオブジェクトのエントロピメジャを計算することと、
該複数のデータオブジェクトのエントロピメジャに従って、該複数のデータオブジェクトから候補データオブジェクトを選択することと、
該候補データオブジェクトの少なくとも１つを、該サーバと該クライアントデバイスとの間で双方向に送信される該少なくとも１つのデータオブジェクトに応答して、サーバ状態オブジェクトとして同定することと
によって判断する解析手段と
を備える、システム。
【請求項４８】
通信プロトコルに基づくネットワーク上で、サーバとクライアントデバイスとの間で送信されるパケット間のサーバ状態オブジェクトを同定するシステムであって、該システムは、
該サーバと該クライアントデバイスとの間に結合され、両者間で送信されたパケットを複数の名前−値のペアに構文解析するための構文解析手段と、
該構文解析手段に結合され、該名前−値のペアを受信し、該名前−値のペアがサーバ状態オブジェクトであるかどうかを
同じ名前を有する該名前−値のペアのエントロピを計算することと、
該サーバ状態オブジェクトに対する候補として、所定の閾値より高いエントロピを有する該名前−値のペアを選択することと、
該サーバと該クライアントデバイスとの間で双方向に送信されたかどうかを判断することと、
該候補の少なくとも１つは、該少なくとも１つの候補が該サーバと該クライアントデバイスとの間で双方向に送信されたとの判断に応答して、サーバ状態オブジェクトであることを判断することと
によって判断する解析手段と
を備える、システム。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公表番号】特表２００８−５０７０１０（Ｐ２００８−５０７０１０Ａ）
【公表日】平成２０年３月６日（２００８．３．６）
【国際特許分類】
【出願番号】特願２００７−５１８１１１（Ｐ２００７−５１８１１１）
【出願日】平成１７年６月１３日（２００５．６．１３）
【国際出願番号】ＰＣＴ／ＵＳ２００５／０２０９１９
【国際公開番号】ＷＯ２００６／０１１９８７
【国際公開日】平成１８年２月２日（２００６．２．２）
【出願人】（５０６４２２６９６）テロス， インコーポレイテッド (1)
【Ｆターム（参考）】
【公表日】平成２０年３月６日（２００８．３．６）
【国際特許分類】
【出願日】平成１７年６月１３日（２００５．６．１３）
【国際出願番号】ＰＣＴ／ＵＳ２００５／０２０９１９
【国際公開番号】ＷＯ２００６／０１１９８７
【国際公開日】平成１８年２月２日（２００６．２．２）
【出願人】（５０６４２２６９６）テロス， インコーポレイテッド (1)
【Ｆターム（参考）】
[ Back to top ]