JP2007505409A - プロトコルゲートウェイでソフトウェアを動的に更新するシステム及び方法 - Google Patents

Abstract

ソフトウェアモジュールを動的に更新する方法は、既存のソフトウェアモジュールを置き換えるために新たなソフトウェアモジュールをロードするステップを含んでいる。古いソフトウェアモジュールが終了する前に、既存の通信セッションのような既存のルーチンに古いソフトウェアモジュールが関わっているか、既存の通信セッションのような既存のルーチンにより古いソフトウェアモジュールが使用されているかを判定するためにチェックが実行される。古いソフトウェアモジュールが使用されている場合、それが保存される。古いソフトウェアモジュールもはや使用されなくなると、それは終了され、全ての新たなルーチンが新たなソフトウェアモジュールを使用するために構成される。

Description

本発明は、デジタル通信ネットワークの分野全般に関し、より詳細には、インスタントメッセージ“Ｉｎｓｔａｎｔ Ｍｅｓｓａｇｅ”プロトコルのようなダイナミックプロトコルを含むネットワークにわたる複数のプロトコルの管理に関する。

ローカル又はプロプライエタリネットワークに結合されるローカルのコンピュータ装置がネットワーク外にあるリモートコンピュータ装置と通信するとき、ネットワークは、侵入の試みを受け易くなる。侵入は、たとえば、ネットワークに不正にアクセスするのを誰かが試みるとして定義することができる。また、侵入は、ネットワークで利用可能なリソースに不正にアクセスしようとする、コンピュータウィルスのようなプログラムとしても定義することができる。たとえば、コンピュータウィルスは、リモートコンピュータ装置からローカルコンピュータ装置に送出することができ、ローカルコンピュータ装置で動作することが許可された場合、ネットワークのローカルコンピュータ装置にとって利用可能なリソースのような、他のローカルリソースと同様にローカルコンピュータ装置でリソースを調達することができる。別の例として、リモートコンピュータ装置は、適切なリソースへのそのローカルコンピュータ装置によりアクセスを防止すること、又はそのローカルコンピュータ装置への他によるアクセスを防止することによるような、ローカルコンピュータ装置へのサービスを拒否しようとして１セットのメッセージを生成するか、さもなければローカルコンピュータ装置でのサービスへの影響を有する。

あるケースでは、侵入は、ネットワークに向けられるメッセージにより生じ、他のケースでは、侵入は、コンピュータウィルスの制御下でネットワーク内のコンピュータ装置又はネットワークを不正に使用する雇用者のような、ネットワーク内部からのメッセージにより生じることができる。ネットワーク内のコンピュータ装置は、そのコンピュータ装置の悪意のあるユーザ、すなわち望まれないやり方でローカルリソースにアクセスしようとするユーザにより汚染される可能性がある。また、コンピュータ装置は、プログラムがローカルリソースへのアクセスを有する装置に無害に導入されたときのように、比較的無害なやり方で汚染される可能性があり、この場合、プログラム自身は、望まれないやり方でローカルリソースにアクセスしようとする機能を含んでいる。

それ故、特に、ネットワークのビジネスの観点に向けられないメッセージプロトコルをメッセージが使用しないとき、ネットワークでメッセージを扱うためのポリシールールを適用することが望まれることがある。たとえば、個人の使用が主要である多数のメッセージプロトコルが最近開発されているが、これら多数のメッセージプロトコルは、企業ネットワークのようなプロプライエタリネットワークへの道をなし、可能性のある乱用を受ける。これらメッセージプロトコルは、たとえば、インスタントメッセージ（ＩＭ）プロトコル、ピア・ツー・ピア（Ｐ２Ｐ）及び他のファイルシェアリングプロトコル、インタラクティブゲームプロトコル、分散コンピューティングプロトコル、ＨＴＴＰトンネリング、及びコンピュータプログラムインタラクションの“ＮＥＴ”又は“ＳＯＡＰ”方法を含む。企業ネットワークに入るこれらメッセージプロトコルから生じる可能性のある乱用の幾つかは、企業ネットワーク内のクライアント装置へのコンピュータウィルスの偶発的な伝達、企業ネットワーク内のクライアント装置と企業ネットワーク外のクライアント装置との間のセンシティブ又はプロプライエタリな情報の伝達、及び企業ネットワーク内の他の許可されていないユーザの振る舞いである。

企業ネットワークにおけるメッセージにポリシールールを適用する従来の方法は、ＴＣＰ（ｔｒａｎｓｍｉｓｓｉｏｎ ｃｏｎｔｒｏｌ ｐｒｏｔｏｃｏｌ）及びＩＰ（Ｉｎｔｅｒｎｅｔ ｐｒｏｔｏｃｏｌ）のような比較的下位のメッセージプロトコルに主に向けられる。記載されたプロトコルは、典型的に、ＩＳＯ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｏｒｇａｎｉｚａｔｉｏｎ ｆｏｒ Ｓｔａｎｄａｒｄ）モデルで表されるように、上位のＴＣＰ／ＩＰプロトコルスタックで実現される。しばしば、速度及び結果の観点で、たとえばファイアウォールサーバは、ＩＳＯモデルにおける上位レベルを含むメッセージプロトコルに対して効果的ではないか、企業ネットワークに対して比較的新しくしたがってファイアウォールサーバにより予想されないメッセージプロトコルに対して非常に効果的ではない。さらに、多くのかかるプロトコルは、メッセージプロトコルを認識及び途中で捕らえ、これらのメセージプロトコルにポリシールールを強制する新たなシステム及び方法を配置するのが実施可能なよりも迅速に、迅速に開発及び変更される。

プロトコル管理システムは、所定のメッセージプロトコルを検出し、ポリシールールを検出されたメッセージプロトコルに適用可能であり、ネットワークリソースの侵入、又は乱用を防止する。１態様では、プロトコルメッセージゲートウェイは、ＩＳＯプロトコルスタックのレイヤ７にあるプロトコルのような上位レベルのメッセージプロトコルに適用するために構成される。

別の態様では、プロトコル管理システムは、ネットワークに入出するメッセージを途中で捕らえ、メッセージに関連するメッセージプロトコルを調べるために構成される。メッセージプロトコルが定義されたプロトコルテンプレートに整合する場合、メッセージは、メッセージプロトコルのポリシールールが適用されるように、プロトコルメッセージゲートウェイを使用するのに強制される。

別の態様では、外部サーバが目的地にメッセージを再度向き直すように構成される場合、外部サーバへのネットワークから向かうメッセージの目的地を決定することができる。目的地がネットワーク内にあることが決定された場合、メッセージは、シンプルに、目的地に再び向けることができる。

本発明のこれらの特徴及び他の特徴、並びに実施の形態は、発明の詳細な説明の好適な実施の形態と題されるセクションで以下に記載される。本発明の特徴、態様及び実施の形態は、添付図面と共に記載される。

図１は、本明細書で記載されるシステム及び方法にかかるプロトコル管理システム１００とインタフェースするために構成される企業ネットワーク１１０の例示的な実施の形態を示している。図１の例では、企業ネットワーク１１０は、ファイアウォール１２０を通して外部ネットワーク１３０に結合される。企業ネットワーク１１０は、企業ネットワーク１１０へのユーザ１７２のアクセスを提供するために構成される、少なくとも１つのローカルクライアント１７０に結合される。代替的な実施の形態では、プロキシサーバ（図示せず）は、外部ネットワーク１３０を企業ネットワーク１１０に結合するためのファイアウォール１２０に代わって使用することができる。

図１で分かるように、システム１００は、プロトコルメッセージゲートウェイ１２２、プロキシエンフォーサ１５０、及び認証モジュール１６０を含んでいる。プロトコルメッセージゲートウェイ１２２、プロキシエンフォーサ１５０、及び認証モジュールの実施の形態、配置及びアプリケーションは、以下に更に詳細に記載される。

本明細書で記載されるように、企業ネットワーク１１０は、ＬＡＮ（ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ）、ＷＡＮ（ｗｉｄｅ ａｒｅａ ｎｅｔｗｏｒｋ）、ローカルスイッチネットワーク、又はパブリックスイッチネットワーク、他の通信技術又はその組み合わせのような、１以上の内部ネットワークを含んでおり、これらにより、企業ネットワーク１１０にローカルに結合される装置は互いに通信することができる。企業ネットワーク１１０がＬＡＮを含む１実施の形態が本明細書では記載されるが、企業ネットワーク１１０がＬＡＮを含むこと、又は特定のネットワークコンフィギュレーションが利用されるべきことについて、特に要件がない。

外部ネットワーク１３０は、インターネットを含むことができるが、他の実施の形態では、外部ネットワーク１３０は、イントラネット、エクストラネット、バーチャルプライベートネットワーク（ＶＰＮ）、ＬＡＮ、ＷＡＮ、ローカルスイッチネットワーク又はパブリックスイッチネットワーク、他の通信技術、又はそれらの組み合わせを含むことができる。外部ネットワーク１３０がインターネットを含む実施の形態が本明細書で記載されるが、外部ネットワーク１３０がインターネット又は他の特定のタイプのネットワークを使用することの特定の要件が存在しない。

ファイアウォール１２０は、ＩＳＯレイヤのプロトコルモデルの選択されたレベルでフォーマット化されるメッセージを認識及び傍受し、それらのメッセージが所定のメッセージプロトコルフォーマットで受信されることが意図された情報を搬送するかを判定する選択されたフィルタリング基準に合致させるための従来の装置を含むことができる。

システム１００の１実施の形態では、プロトコルメッセージゲートウェイ１２０、プロキシエンフォーサ１５０、及び認証モジュール１６０は、管理コンソール１８０に結合することができ、このコンソールは、システム１００のターゲットとなるように定義された所定のプロトコルに関するパラメータ及びポリシーを設定するためにシステムアドミニストレータによる使用のために構成することができる。

さらに、所定の実施の形態では、プロトコルメッセージゲートウェイ１２２及びプロキシエンフォーサ１５０は、会社データベース１２５に結合することができ、このデータベースは、ユーザスクリーン名又はエイリアスを会社ネットワーク１１０内の特定のユーザと関連付けするために使用される。プロトコルメッセージゲートウェイ１２０、及びプロキシエンフォーサ１５０は、所定の実施の形態では、データトランスポートサービス１９０を含むロギング及びアーカイブサブシステムに結合される。データトランスポートサービス１９０は、プロトコルメッセージログ記録のためのリレーショナルモデルに変換し、ログを、リポート１９８が生成されるリポートデータベース１９６に記録するために構成される。所定の他の実施の形態では、かかるリポートは、アドミニストレータ１９２にメールされる電子メールに変換されるか、又は電子メールアーカイブサービス１９４により記録保管される。

図２は、更に詳細に記載されるプロキシエンフォーサ２５０を含む通信システム２００を例示するブロック図である。また、システム２００は、企業ネットワーク２１０、ファイアウォール２２０、外部ネットワーク２３０、プロトコルメッセージゲートウェイ２４０、プロキシエンフォーサ２５０、及びクライアント装置２６０のセットを含む。

以下に説明されるように、プロトコルメッセージゲートウェイ２４０は、所定のターゲットプロトコルを使用しているメッセージを認識し、ターゲットプロトコルに関連するポリシールールを実現するために構成される。これらターゲットプロトコルは、企業ネットワーク２１０に入り存在しつつ、検出を逃れるたとえばＩＳＯレベル７のようなハイレベルのプロトコルである。たとえば、これらのメッセージプロトコルは、企業ネットワーク２１０との監視されない通信コネクションを発見することがあり、メッセージが検出を逃れるのを可能にする。しかし、プロキシエンフォーサ２５０は、企業ネットワーク２１０に入出する全てのメッセージを傍受し、それらを、たとえばプロトコルメッセージゲートウェイ２４０の定義されたポートといった定義された通信コネクションを通して通過させる。このようにして、プロキシエンフォーサ２５０は、企業ネットワーク２１０に入出する全てのメッセージが要求されたようにプロトコルメッセージゲートウェイ２４０により処理されたことを保証し、これにより、適切なプロトコルルールをメッセージに適用することができる。

したがって、１実施の形態では、プロキシエンフォーサ２５０は、ファイアウォール２２０に結合され、企業ネットワーク２１０の内外にファイアウォール２２０を通して流れる個々のパケットを含むメッセージを受動的に聞くことができるように配置される。プロキシエンフォーサ２５０は、プロトコル定義ルール２５４のセットに基づく１セットのエンフォースメントルール２５２を含んでいる。それぞれのプロトコル定義ファイル２５４は、ターゲットプロトコルを認識し、複数のコネクションにわたり状態を管理するインテリジェントヒューリスティックをもつ実行可能なコードの部分である。たとえば、ターゲットプロトコルの各クラス又はサブタイプについて、個々の定義ファイル２５４が存在する。個々のプロトコル定義ファイル２５４は、他のプロトコル定義ファイル２５４とは異なることができる。さらに、エンフォースメントルール２５２とプロトコル定義ルール２５４のセットは、異なるターゲットプロトコル及びターゲットプロトコルを処理する異なるやり方に応じて必要により拡張することができる。１実施の形態では、更なるエンフォースメントルール２５２及びプロトコル定義ファイル２５４は、企業ネットワーク２１０とインタフェースされるサーバからダウンロードすることができる。したがって、システムアドミニストレータは、たとえば、新たなエンフォースメントルール２５２及び／又はプロトコル定義２５４及びアップデートプロキシエンフォーサ２５０を必要に応じて定義することができる。

プロトコル定義ファイル２５４は、プロトコルテンプレートとして作用する。プロキシエンフォーサ２５０は、したがって、企業ネットワーク２１０においてメッセージを傍受し、次いで、それらをプロトコル定義ファイル２５４で定義されたプロトコルテンプレートに比較する。整合が生じた場合、プロキシエンフォーサ２９０は、対応するエンフォースメントルール２５２を実現するために構成することができる。整合パターンに全体的に依存する慣習的なウィルス認識ソフトウェアとは異なり、プロキシエンフォーサ５０は、ターゲットプロトコルが複数のポート及び／又はストリームを使用するときのように、２つの異なるメッセージ又は同じメッセージ内の２つの異なるブロックの相関をとる。これは、たとえば、プロトコル定義ファイル２５４が他のポート、パケット及びデータストリームに関連する情報を記憶するため、それ自身のデータ構造及びテーブルを形成するために構成することができるために達成することができる。

プロトコル定義ストリームは、メッセージのためのソースＩＰアドレス、メッセージのための目的地ＩＰアドレス、メッセージに関連するポート番号、メッセージに埋め込まれたヘッダストリング又はデータ値の他のセット、又はその組み合わせの観点でターゲットプロトコルを識別するために構成することができる。プロキシエンフォーサ２５０は、メッセージの系列に応答してプロキシエンフォーサ２５０により保持される一貫された状態に応答して関心のあるプロトコルを検出するために構成することもできる。

動作において、リモートサーバ２８０は、外部ネットワーク２３０に結合され、クライアント装置２６０に対するターゲットプロトコル及びクライアント装置２６０からのターゲットプロトコルを使用してメッセージを送出及び受信するために構成することができる。たとえば、リモートサーバ２８０は、ＩＭメッセージをクライアント装置２６０に伝達するために構成することができる。

プロキシエンフォーサ２５０は、たとえばファイアウォールを通して流れるときメッセージを受動的に聞くように構成される。プロキシエンフォーサ２５０は、たとえばエンフォースメントルールデータベース２５６に保持されているプロキシエンフォースメントルール２５２のセットを有する。プロキシエンフォーサ２５０がＩＭメッセージ、ターゲットプロトコルを傍受したとき、プロキシエンフォーサ２５０は、プロキシ定義ファイル２５４を使用してＩＭメッセージを整合する。プロキシエンフォーサ２５０は、関連されるエンフォースメントルール２５２を実行することができる。エンフォースメントルール２５２は、傍受されたＩＭメッセージと関連されるＩＭプロトコルの態様を無視するように構成することができる。たとえば、プロキシエンフォースメントルール２５２は、ＩＭメッセージがプロトコルメッセージゲートウェイ２４０を通過することを必要とし、プロトコルメッセージゲートウェイ２４０は、全てのＩＭメッセージのプロキシとして作用するために構成される。

プロキシエンフォーサ２５０は、プロキシエンフォースメントルール２５２に従わない場合、メッセージが有効になるのを妨げるために構成される。メッセージが有効になるのをプロキシエンフォーサ２５０が防止する１つのやり方は、企業ネットワーク２１０又は外部ネットワーク２３０でメッセージが生じるか否かで、メッセージのサービスと目的地との間の通信コネクションを無くすことである。代替的な実施の形態では、プロキシエンフォーサ２５０は、メッセージに関連される通信コネクションをリセットするために構成することができる。他の実施の形態では、エンフォースメントルール２５２は、プロキシエンフォーサ２５０にメッセージに関連する情報を記憶させる。記録された情報は、以下に記載されるようにログ及びリポートを生成するために使用することができる。

図３は、プロキシエンフォーサ２５０のようなプロキシエンフォーサを使用して、ネットワークにおける通信トラフィックを管理する例となる方法を例示するフローチャートである。はじめに、ステップ３０２では、プロキシエンフォーサ２５０は、通信トラフィックを含むメッセージを受動的に聞くために構成することができる。次いで、ステップ３０４では、プロキシエンフォーサ２５０は、メッセージを傍受し、ステップ３０６で、メッセージに関連されるプロトコルを調べる。ステップ３０６でメッセージを調べることは、ソースＩＰアドレス、目的地ＩＰアドレス、ポート番号、及びメッセージに関連するテキストのセットのような情報を決定するステップを含む。ステップ３０６では、プロキシエンフォーサ２５０は、たとえばステップ３０６で決定された情報に基づいて、プロトコルがターゲットプロトコルテンプレートに整合するかを判定する。テンプレートは、先に記載されたように、１以上のプロトコル定義ファイル２５４により定義される。ステップ３０３で整合があった場合、プロキシエンフォーサ２５０は、関連されるエンフォースメントルール２５２を実行するために構成することができる。整合がない場合、プロキシエンフォーサ２５０は、受動的に聞き続けるために構成される（ステップ３０２）。

プロトコル定義ファイル２５４は、ターゲットプロトコルを使用するメッセージと関連する値のパターンを定義する。したがって、プロキシエンフォーサ２５０は、メッセージトラフィックデータベース２５８に保持されるデータと値のパターンを整合するために構成される（ステップ３０３）。可能な例は、たとえば、ポート５１９０の全てのトラフィック、文字列“？ｙｍｅｓｓａｇｅ”を含むポート８０８０の全てのトラフィック、たとえば％１をメッセージトラフィックデータベース２５８に保持される値である文字列“？ｐｗｏｒｄ”を含むポート８０８０の全てのトラフィック、たとえば５つの文字をＩＭプロトコルで使用されるインスタントメッセージの署名である到来するパケットヘッダにおける５つの文字列を含むポート５１９０の全てのトラフィックを整合することを含む。

所定の実施の形態では、エンフォースメントルール２５２及び整合のタイプに依存して、メッセージの更なる分析を実行することができる。これは、たとえば、メッセージがＨＴＴＰトラフィックとしてＩＭマスカレードであることを最初の分析が示唆する場合に特に有効である。

ステップ３１０では、プロキシエンフォーサ２５０は、複数のトリガされたエンフォース面とルール２５２のうちの１つと関連されるアクションを実行する。１実施の形態では、第一のトリガされたエンフォースメントルール２５２に関連するアクションのみが実行されるが、代替的な実施の形態では、１を超えるアクションが実行される場合があり、パフォーマンスのオーダが、エンフォースメントルール２５２がエンフォースメントデータベース２５６に保持されるオーダに応じる。

所定の実施の形態では、エンフォースメント２５２は、メッセージトラフィックデータベース２５８における可能な記録値を含めて、傍受されたメッセージに関して行う特定のアクション含む。先に説明されたように、エンフォースメントルール２５２に応答して行われるアクションの可能な例は、メッセージに関連するコネクションを無くし、ソケットコネクションをリセットし、（値が将来的に認識することができるように、整合されたとき、及び／又はログに値％１を記憶するとき、％１は文字列“？ｐｗｏｒｄ”）メッセージトラフィックデータベース２５８に値％１を記録し、メッセージテキストを分析し、並びに、メッセージ及びメッセージテキストが時間的に将来的なポイントで再び見ることができるように、１以上の個々のユーザと関連されるログにメッセージを記憶する。これは、音楽ファイルをダウンロードする従業員のようなネットワークの許可されていない使用のレコードを発生するために使用することができる。

したがって、プロキシエンフォーサ２５０、又は類似のプロキシエンフォーサ１５０は、プロトコルメッセージゲートウェイ１２２を通してターゲットプロトコルパスを使用するメッセージを保証するために構成される。図１で分かるように、ファイアウォール１２０は、「インスペクトスクリプト“ｉｎｓｐｅｃｔ ｓｃｒｉｐｔ”」とも呼ばれる認識パターン１２４のセットを記憶するために構成されるメモリ１２６を含むことができる。認識パターン１２４は、たとえば、ファイアウォール１２０のアドミニストレータにより選択することができ、ターゲットプロトコルを使用してファイアウォール１２０のメッセージに記述するのに十分な情報を含むことができる。

ファイアウォール１２０は、認識パターン１２４に応答して、それが処理するメッセージのうちの少なくとも幾つかをプロトコルメッセージゲートウェイ１２２に再び向けるために構成することができる。１実施の形態では、たとえば、メッセージは、従来のコンテンツベクトリングプロトコル（Ｃｏｎｔｅｎｔ Ｖｅｃｔｏｒｉｎｇ Ｐｒｏｔｏｃｏｌ）技術を使用して再び向け直すことができ、メッセージを処理し、プロトコルメッセージゲートウェイ１２２により更に処理されるべきことを判定した後、ファイアウォール１２は、メッセージをプロトコルメッセージゲートウェイ１２０に伝送する。ＣＶＤを使用して再び向けること（ ｒｅｄｉｒｅｃｔｉｏｎ）は、図６と共に更に詳細に記載される。ひとたびプロトコルメッセージゲートウェイ１２２がメッセージを受けると、ターゲットプロトコルのポリシールールがメッセージを処理するために利用されることを保証する。

図４は、更に詳細にプロトコルメッセージゲートウェイ１２２の１実施の形態を例示する図である。分かるように、プロトコルメッセージゲートウェイ１２２は、プロトコルメッセージパーサ４１０、ゲートウェイマネージャ４２０、プロトコルアダプタ４３０のセット、ポリシーエンフォースメントモジュール４４０、認証モジュール４５０、更なるモジュールアダプタ４６０のセットを含むことができる。

１実施の形態では、プロトコルメッセージパーサ４１０は、先に記載されたように、従来のＣＶＰ技術を使用してファイアウォール１２０に結合される。プロトコルメッセージパーサ４１０は、ファイアウォール１２０からターゲットメッセージを受ける。プロトコルメッセージパーサ４１０は、受けたメッセージを分析し、受けたメッセージを処理するためにどのプロトコルアダプタの４３０のセットが適切であるかを判定する。プロトコルメッセージは、メッセージをゲートウェイマネージャ４２０に送出するために構成することができる。所定の実施の形態では、プロトコルメッセージゲートウェイ１２２は、１を超えるプロトコルメッセージパーサ４１０を含む。複数のプロトコルメッセージパーサの包含は、多数のターゲットメッセージを受け、精度又は応答時間のいずれかにおける実質的な品質低下なしに、それらのメッセージを分析して分散するプロトコルメッセージゲートウェイ１２２の能力を比較的容易かつ有効にスケーリングするのを可能にする。

ゲートウェイマネージャ４２０は、分析されたメッセージを受け、メッセージに関連する必要なデータ構造４２２を作成する。これらのデータ構造４２２のなかで、ゲートウェイマネージャ４２０は、メッセージイベント４０４を受信することに関心があることを示すプロトコルアダプタ４３０及びモジュールアダプタ４６０に公表する新たなメッセージイベント４０４を作成するために構成される。メッセージイベント４０４を公表するとき、ゲートウェイマネージャ４２０は、メッセージを処理するための適切なプロトコルアダプタ４３０のような分析されたメッセージに関連する情報、及び、ユーザ、ユーザ名、メッセージに関連するスクリーン名等のようなメッセージ関する他の識別情報を含む。

１実施の形態では、ゲートウェイマネージャ４２０は、プロトコルアダプタ４３０がメッセージを処理するために適切なアダプタであるかを判定する。適切なプロトコルアダプタ４３０は、メッセージ及びその関連するメッセージイベント４０４を受けることができ、メッセージが関連するメッセージプロトコルの処理パラダイムにどのようにフィットするかを判定することができる。たとえば、メッセージが送信者と受信者、すなわちＩＭメッセージの送信者と受信者との間のセッションを始める場合、プロトコルアダプタ４３０は、新たなセッションが生成されるべきかを判定し、新たなセッションイベント４０６を生成する。この例では、生成されゲートウェイマネージャ４２０により使用されるデータ構造４２２は、データ構造４２２の一部としてのセッションデータ構造を含んでおり、このセッションデータ構造は、関連するメッセージプロトコルを使用して、送出するクライアント装置１７０と受信するクライアント装置との間の通信セッションに関連する情報を含む。

メッセージを処理するために割り当てられるプロトコルアダプタ４３０は、特定のメッセージ又はメッセージイベント４０６に関心があることを示したプロトコルアダプタ４３０又はモジュールアダプタ４６０に発するためのゲートウェイマネージャ４２０に生成する新たなイベント４０６を送出するために構成される。

プロトコルメッセージゲートウェイ１２２における１を超えるプロトコルアダプタ４３０の包含は、多数のメッセージを受け、精度又は応答時間のいずれかにおける実質的な品質の低下なしにプロトコルメッセージゲートウェイ１２２でのメッセージを個々に処理するために、比較的容易かつ有効なプロトコルメッセージゲートウェイ１２２のスケーリングを可能にする。さらに、それぞれが類似のターゲットプロトコルのセットの異なる変形例について特に設計された、複数のプロトコルアダプタ４３０の使用により、クライアント装置１７０は、プロトコルメッセージゲートウェイ１２２の一部への特別の変換の必要なしに、及びクライアント装置１７０の変更の必要なしに、異なる変形例を使用して通信することが可能である。

さらに、ゲートウェイマネージャ４２０は、メッセージイベント４０６に関心を示すプロトコルアダプタ４３０又はモジュールアダプタ４６０にメッセージイベント４０６を発するために構成される。関心を示したプロトコルアダプタ４３０又はモジュールアダプタ４６０のなかには、たとえば、ポリシーエンフォースメントモジュール４４０、認証モジュール４５０、及び選択された他の更なるモジュールアダプタ４６０がある。

認証モジュール４５０は、認証モジュール４５０が関連するメッセージに関連されるスクリーン名を認証するように、セッションイベント４０６を受けるために構成される。以下に更に詳細に記載されるように、認証モジュール４５０は、かかるスクリーン名に関連する実際のユーザを固有に識別し、認証モジュール４５０に関連されるユーザデータベース４５４にその識別情報を記録し、セッションイベント４０６についてゲートウェイマネージャ４２０により保持されるデータ構造４２２における包含のためにゲートウェイマネージャ４２０にその識別情報を送出するために構成される。

プロトコルメッセージゲートウェイ１２２は、送出するクライアント装置１７０からプロトコルメッセージゲートウェイ１２２により受信されたとき、受信するクライアント装置１７０または外部ネットワーク１３０のクライアント装置にプロトコルメッセージゲートウェイ１２２により送出されたとき、メッセージをログする機能を提供するために構成されるロギングオジュール４７０を含む。言い換えれば、ロギング４７０は、プロトコルメッセージゲートウェイ１２２にわたり交換される全てのメッセージの一貫したログを保持するための機能を提供する。１実施の形態では、ロギングモジュール４７０は、ログをロギングデータベース４７４に出力するために構成され、データベースのサーチが行われ、リポートが生成される。別の実施の形態では、ロギングモジュール４７０は、暗号化されたフォーマットでロギングデータベース４７４にログ情報を出力するために構成され、ロギングデータベース４７４へのアクセスが割り当てられている、ロギングモジュール４７０に関連する装置１７０、又はおそらくゲートウェイ１２２に関連する装置１７０に対するロギングデータベース４７４における情報へのアクセスを制限する。アクセスは、実施の形態に依存して、情報を暗号化するために使用されるフォーマットについて適切な鍵を使用して割り当てられる。

ロギングモジュール４７０は、送出するクライアント装置１７０と受信するクライアント装置との間の感知しにくい通信を含むメッセージを記録するやり方を提供する。かかる持続性のある記録は、それらクライアント装置間の通信のフォレンジックな調査（ｆｏｒｅｎｓｉｃ ｉｎｖｅｓｔｉｇａｔｉｏｎ）を可能にする。同様に、かかる持続性のある記録は、規制する要件、又はかかるクライアント装置間の通信の記録のメンテナンスを必要とする他の管理上のルールをとの互換線を可能にする。たとえば、送出するクライアント装置１７０及び受信するクライアント装置は、財政機関の部門におけるユーザにより制御される場合がある。規制する要件は、分析又は選択されたセキュリティの推薦に関する通信のような、かかるユーザ間の通信が所定のトピックスを回避することを要求する。かかる通信をログすることは、かかる要件に従うことを保証するのに役立つ。

プロトコルメッセージゲートウェイ１２２は、実施の形態に依存して、ポリシーエンフォースメントモジュール４４０を含むことができる。ポリシーエンフォースメントモジュール４４０は、それぞれのメッセージに関する情報を受信し、特定のメッセージが変更されていないフォームで送出するクライアント装置１７０から送出されるか否かを判定するために構成することができる。ポリシーエンフォースメントモジュール４４０は、以下を含む所定のクラスの情報のうちの少なくとも１つに応じて特定のポリシールールを含むポリシールールデータベース４４４へのアクセスを有する。送出するクライアント装置１７０の性質、受信するクライアント装置の性質、メッセージの性質、メッセージに含まれるキーワードを含む情報、メッセージが送出されたか又は受信されることが意図される週の日又は日時、メッセージがアタッチメント、ウィルスを含む実行可能なファイルアタッチメント等を含むか否かを含むメッセージのサイズ、選択された時間期間の間に送出するクライアント装置１７０により既に送出されか、又は受信するクライアント装置により既に受信されたトラフィックの量、若しくは、企業ネットワーク１１０の管理者により関連すると思われる他のクラスの情報。

所定の実施の形態では、プロトコルメッセージゲートウェイ１２２は、１以上の論理的に遠隔のアドミニストレータコンソール１８０から管理することができ、このコンソールは、企業ネットワーク１１０、外部のネットワーク１３０に結合される別のネットワーク、又は外部のネットワーク１３０それ自身に結合することができる。リモートアドミニストレータコンソール１８０の使用は、プロトコルメッセージゲートウェイ１２２に含まれる各種モジュール又はアダプタが遠隔の位置から動的に更新されるのを可能にする。たとえば、動的なポリシールールデータベース４４４は、実質的にリアルタイムでアドミニストレータコンソール１８０から動的に変更することができ、これにより、ターゲットプロトコルに関してリアルタイムの更新を可能にする。迅速に危険又は有害なプロトコルがポップアップすると、かかるプロトコルをできるだけ迅速に処理する必要性、かかる動的な更新の機能は非常に貴重となる。さらに、動的な更新を遠隔的に実行できる事実は、外部のネットワーク１３０でさえも、ネットワーク管理者はそれらの企業ネットワーク１１０をプロテクトするために常に存在することはできないので、より貴重となる。

図５は、プロトコルメッセージゲートウェイ１２２が企業ネットワーク１１０のようなネットワークにおける通信トラフィックを管理することができる例となる方法を例示するフローチャートである。はじめに、ステップ５０２では、プロトコルメッセージゲートウェイ１２２は、メッセージを受け、受けたメッセージをプロトコルメッセージパーサ４１０に送出し、このプロトコルメッセージパーサは、ステップ５０４でメッセージを分析し、メッセージの処理のためにどのプロトコルアダプタ４３０のセットが適しているかを判定する。ステップ５０４の一部として、プロトコルメッセージパーサ４１０、メッセージを更なる処理のためにゲートウェイマネージャ４２０に送出するために構成される。

ステップ５０６では、ゲートウェイマネージャ４２０は、分析されたメッセージを受け、メッセージに関連する必要なデータ構造４２２を作成する。先に述べたように、これらのデータ構造４２２のなかで、ゲートウェイマネージャ４２０は、メッセージイベント４０４を受信することに関心があることを示したプロトコルアダプタ４３０及びモジュールアダプタ４６０に発することができる、新たなメッセージイベントを作成するために構成される。先に更に述べたように、メッセージイベント４０４を発したとき、ゲートウェイマネージャ４２０は、メッセージを処理するために適切なプロトコルアダプタ４３０のようなメッセージに関連する情報、メッセージに関連するユーザ、ユーザ名、又はスクリーン名のようなメッセージに関する他の識別情報を含む。

ステップ５０８では、少なくとも１つのプロトコルアダプタ４３０は、メッセージを認識し、ステップ１０で関連されるメッセージプロトコルの処理パラダイムにメッセージがどのようにフィットするかを判定する。ステップ５１２では、プロトコルアダプタ４３０は、メッセージが関連されるプロトコルについて処理パラダイムにどのようにフィットするかに応じて、適切であると思われる新たなイベント４０６を生成するために構成される。プロトコルアダプタ４３０により発生されたかかる新たなイベント４０６は、ステップ５１４でゲートウェイマネージャ１２２に送出することができる。

ステップ５１６では、ゲートウェイマネージャ１２２は、新たなイベント４０６をプロトコルアダプタ４３０、又はイベント４０６のクラスに関心を示した他のモジュールアダプタに発する。

認証モジュールアダプタ４５０は、ステップ５１８で、新たなセッションイベント４０６を受け、関連するメッセージに関連するスクリーン名を認証する。

ステップ５２０では、ロギングモジュールアダプタ４７０は、メッセージのためのロギングエントリを生成し、ロギングデータベース４７４にログを出力し、ロギングデータベースから、データベースのサーチが行われ、リポートが生成される。先に述べたように、ロギングモジュールアダプタ４７０は、暗号化された形式でロギングデータベース４７４のためのログ情報を出力する。

ステップ５２２では、ポリシーエンフォースメントモジュール４４０は、それぞれのメッセージに関する情報を受け、特定のメッセージが送出するクライアント装置１７０から受信するクライアント装置に変更されない形式で送出されるべきか否かで判定する。先に述べたように、ポリシーエンフォースメントモジュール４４０は、少なくとも１つの、おそらく１を超える多数のクラスのポリシー情報に応じて特定のポリシールールを含む、ポリシールールデータベース４４４へのアクセスを有する。

プロトコルメッセージゲートウェイ１２２を実現するとき、使用することができる幾つかの開発オプションが存在する。たとえば、図６は、先に記載されたＣＶＰ方法を使用したプロトコルメッセージゲートウェイ１２２の開発を例示したブロック図である。したがって、ファイアウォール６２０は、ＣＶＰ ＡＰＩ６１０を有し、このＣＶＰ ＡＰＩは、プロトコルメッセージゲートウェイ１２２に結合される。ファイアウォール６２０は、このケースではプロトコルメッセージゲートウェイ１２２である、これを通して外部サーバが結合されるＣＶＰインタフェースメカニズムを有するために構成される。ファイアウォール６２０は、たとえば通信ポート５１９０又は通信ポート２０２０から、ＣＶＰ ＡＰＩ６１０を使用したＣＶＰインタフェースメカニズムを通してプロトコルメッセージゲートウェイ１２２にメッセージを向ける。

代替的に、図７は、本実施の形態で記載されるシステム及び方法の別の実施の形態に係るゲートウェイプロキシ方法を使用したプロトコルメッセージゲートウェイの開発を例示するブロック図である。図７の例では、プロトコルメッセージゲートウェイ１２２は、プロキシモジュール７６０を有する。一般に、プロキシは、サーバ又はサーバのコンポーネントであり、ローカルクライアント装置７７０のようなクライアントへのプロトコル及びクライアントからのプロトコルを含むメッセージをリモートサーバ７８０のようなサーバに中継するために構成される。プロキシは、外部ネットワーク７３０からの侵入からクライアント装置７７０をシールドするために使用される。また、プロキシは、プロトコルメッセージゲートウェイ１２２のようなファイアウォール７２０又はゲートウェイを通して制御されるポータルとして使用される。したがって、プロキシモジュール７６０が設けられたプロトコルメッセージゲートウェイ１２２は、プロトコルメッセージゲートウェイ１２２がプロキシとして機能するのを許容し、ネットワーク７１０内のメッセージを調べるために構成される。

しかし、それぞれのローカルクライアント装置７７０のそれぞれのクライアントアプリケーションは、プロキシとしてプロトコルメッセージゲートウェイ１２２を使用するために構成される。かかるコンフィギュレーションなしで、ローカルクライアント装置７７０は、パス７４４により示されるように、企業ネットワーク７１０、ファイアウォール７２０及び外部ネットワーク７３０を通過することで、リモートサーバ７８０と通信することができる。したがって、協力的でない、教育されていないユーザは、リモートサーバ７８０と通信するため、プロとコルメッセージゲートウェイ１２２及びパス７４４のようなダイレクトパスを快く又は未知にバイパスする。この可能性を回避するのを助けるため、ファイアウォール７２０は、プロキシ７６０から生じている通信を除く全ての通信をブロックするために構成される。残念なことに、従来のファイアウォール７２０は、所定のＩＭプロトコルのような多くのはっきりしないプロトコルを検出するために設けられていない。したがって、プロキシエンフォーサ７５０は、ネットワーク７１０を進むメッセージが先に記載されたようにプロトコルメッセージゲートウェイ１２２を使用するのを保証するために使用される。

したがって、許可されていないパスがブロックされて、ユーザは、プロトコルメッセージゲートウェイ１２２により許可されるように、パス７４２によりプロキシ７４２を介してリモートサーバ７８０に接続される。プロキシモジュール７６０を流れる全ての通信トラフィックにより、プロトコルメッセージゲートウェイ１２２は、ターゲットプロトコルの全てのトラフィックをモニタし、先に記載されたように、かかるプロトコルのポリシーを強制する。

便宜的に、ユーザがログオンするたびに、ローカルクライアント装置７７０でスクリプトが実行される。スクリプトは、装置７７０で実行している全てのクライアントアプリケーションがプロトコルメッセージゲートウェイ１２２をプロキシとして有することを保証する。スクリプトは、それらのプロキシを手動で構成する必要がない点で、追加された便利さをユーザに与える。さらに、スクリプトは、たとえば、アドミニストレータのワークステーション１２０を使用して遠隔的に更新される。

図８及び図９は、本実施の形態で記載されるシステム及び方法の代替的な実施の形態に係るドメイン名サービス（ＤＮＳ）リディレクションを使用したプロトコルメッセージゲートウェイ１２２の開発を例示する。ネットワークにわたる通信において、クライアントは、ホスト名により識別されたサーバに伝達する。通信の始めで、クライアントは、ホスト名を解くためにネームサーバを要求する。発見された場合、ネームサーバは、サーバのネットワークアドレスに応答する。図８及び図９の実施の形態では、クライアントには、所定のサーバのホスト名が要求されるたびに、ゲートウェイ１２２のアドレスが与えられる。

図８は、ＤＮＳリディレクションを使用したプロトコルメッセージゲートウェイの配置を例示するブロック図を示しており、ここでは外部のネームサーバ８９０のみが使用される。外部のネームサーバ８９０は、外部ネットワーク８３０に接続されている。通常のＤＮＳ要求は、クライアント装置８７０から外部のネームサーバ８９０にパス８４０を通してなされる。プロキシエンフォーサ８５０又はファイアウォール８２０のいずれかを使用して、ＤＮＳ要求はブロックされ、クライアント装置は、ＤＮＳプロキシとしてＤＮＳ要求のたえにプロトコルメッセージゲートウェイ１２２を使用するのを強制される。クライアント装置８７０がパス８４２を通して疑わしいホスト名を要求した場合、プロトコルメッセージゲートウェイ１２２は、それ自身が所有のアドレスを対応するアドレスとしてそのホストに与えるために構成され、これによりプロトコルメッセージゲートウェイ１２２がリモートサーバ８８０であると信じるようにクライアント８７０を騙す。次いで、プロトコルメッセージゲートウェイ１２２は、リモートサーバ８８０にメッセージを中継し、これとの通信を監視及び規制する。たとえばターゲットプロトコルに関連するサーバといった所定のサーバに属する１つであるとホスト名が知られていない場合、ゲートウェイ１２２は、パス８４４を通して外部のネームサーバ８９０に要求をなし、外部のネームサーバ８９０により与えられた応答でクライアント装置８７０に応答する。

図９は、ＤＮＳリディレクションを使用したプロトコルメッセージゲートウェイの配置を例示するブロック図を示しており、ここで内部のネームサーバ９２０は、企業ネットワーク９１０内の全てのクライアント装置９７０により使用される。内部のネームサーバ９２０は、たとえば、企業のネットワーク９１０に結合される。ローカルクライアント装置９７０は、サーバのホスト名のアドレスを解くためにパス９５０を通してＤＮＳ要求をなす。アドレスリストを最新に保持するため、内部のネームサーバ９６０は、パス９４２を通して、「ゾーントランスファ」と呼ばれる、外部ネットワーク９３０に接続される外部のネームサーバ９９０とのアドレスリストを周期的に同期させる。これを補うため、プロトコルメッセージゲートウェイ１２２は、パス９４０を介して、ターゲットプロトコルに関連するサーバのホスト名のＤＮＳ要求を向け直すために内部のネームサーバ９６０に代替のホスト名を供給する。

図８及び図９は、ＤＮＳリディレクション方法を使用してプロトコルメッセージゲートウェイ１２２を配置するシステムの例示的な実施の形態として与えられる。しかし、様々な等価な技術及びネームサーバのプロトコルは、ＤＮＳの騙し（ｓｐｏｏｆｉｎｇ）を通してリディレクション（ｒｅｄｉｒｅｃｔｉｏｎ）を達成するために使用されることが理解される。

図１０は、ＨＴＴＰトンネル方法を使用したプロトコルメッセージゲートウェイ１２２の配置を例示したブロック図である。たとえば、図１０に例示される配置が使用される。ファイアウォール１０２０は、ＨＴＴＰを除いてインターネットへの全ての外部のアクセスをブロックするために構成される。かかる状況では、ファイアウォール１０２０は、外部ネットワーク１０６０に仮想的に存在するとして作用するように構成される、すなわち外部ネットワーク１０６０への、及び外部ネットワークからの全てのアクセスがＤＭＺホスト１０１０を通して進む、「デリミタライズド ゾーン」（ＤＭＺ）ホスト１０１０に結合される。ローカルクライアント装置１０７０が外部ネットワーク１０６０に向けられたメッセージを送出するとき、メッセージは、たとえば先に記載された機能を実行するために構成される、プロトコルメッセージゲートウェイ１２２を通して最初に通過するように強制される。次いで、メッセージは、ＨＴＴＰトンネルモジュール１０５０によりＨＴＴＰメッセージとして現れるように構成される。このように、たとえば、メッセージは、ファイアウォール１０２０を通して通過する。

ＨＴＴＰトンネルモジュール１０５０は、スタンドアロンモジュールとして構成されるか、実施の形態に依存してプロトコルメッセージゲートウェイ１２２に組み込まれる。実際、ＨＴＴＰトンネルモジュール１０５０は、本実施の形態で記載された機能を実行するために構成される限り、ファイアウォール１０２０内を含めて、企業ネットワークの何処かにある。

ＨＴＴＰモジュール１０５０がメッセージをひとたびフォーマット化すると、たとえばＤＭＺホスト１０１０の一部として含まれるウェブプロキシ１０３０にファイアウォール１０２０を通して通過される。ウェブプロキシ１０３０は、必要に応じてＨＴＴＰフォーマット化を元通りにし、外部ネットワーク１０６０の外部メッセージを送出するリレー１０４０にメッセージを送出するために構成される。

図１１は、ＣＶＰ方法を使用した配置に類似した、ＩＳＡアプリケーションフィルタ方法を使用してプロトコルメッセージゲートウェイ１２２の配置を例示するブロック図である。したがって、ファイアウォール１１２０は、ターゲットプロトコルを含むメッセージをプロトコルメッセージゲートウェイ１２２に送出するために構成されるＩＳＡアプリケーションフィルタ１１１０を含んでいる。

したがって、企業ネットワーク内、又は他のローカルネットワーク内のメッセージに関連するメッセージプロトコルを適合及び強制するために構成される。プロトコルメッセージゲートウェイ１２２は、先のパラグラフで記載されたものを含む様々なやり方で配置することができる。さらに、プロキシエンフォーサ１５０のようなプロキシエンフォーサは、かかるプロトコルメッセージゲートウェイ１２２を通過するためにネットワーク内にメッセージを強制的に進行させるため、企業ネットワーク内に配置することができる。プロキシエンフォーサ１５０は、メッセージにプロトコルメッセージゲートウェイ１２２を強制的に通過させるのが不可能なとき、通信コネクションを終了するために構成することができる。代替的に、フォーサプロキシエンフォーサ１５０は、プロトコルメッセージゲートウェイ１２２を通して強制されるメッセージに関連される情報をログし、及び／又はプロトコルメッセージゲートウェイ１２２を通して強制されるメッセージに関連するリポートを生成するため、強制的にプロトコルメッセージゲートウェイ１２２を通過されるメッセージに関連する通信コネクションをリセットするために構成される。

図１でわかるように、プロトコルマネージメントシステム１００は、認証モジュール１６０を含むことができる。認証モジュール１６０は、企業ネットワーク１１０に通過されるか、企業ネットワークから通過される関連するメッセージのターゲットプロトコルにより使用される、スクリーン名又はエイリアスから企業ネットワーク１１０内のユーザのアイデンティティを識別するために構成される。たとえば、ＩＭアプリケーションは、ユーザのためのエイリアスとしてスクリーン名を使用することがある。ＩＭアプリケーションにより生成されたメッセージは、スクリーン名を含む。スクリーン名に関連する実際のユーザを識別するためにプロトコルメッセージゲートウェイ１２２を使用したポリシーを適合又は強制するときに有効である。認証モジュール１６０は、かかるアイデンティフィケーションを実行するために構成される。さらに、認証モジュール１６０は、たとえば既に識別されたスクリーン名を使用して同じユーザにより生成されたＩＭメッセージを処理するときに後に検索できるように、識別情報を記憶するために構成される。

図１２は、本実施の形態で記載されるシステム及び方法に従って構成される認証モジュール１６０の１実施の形態を例示する図である。図１２の例示的な実施の形態で分かるように、認証モジュール１６０は、プロトコルメッセージゲートウェイ１２２の一部を含むことができる。代替的に、認証モジュール１６０は、図１に例示されるように、プロトコルメッセージゲートウェイ１２２から離れてスタンドアロンモジュールとして作用する。かかる実現では、認証モジュール１６０は、たとえば、個別のサーバ、又は企業ネットワーク１１０とインタフェースされるローカルクライアント装置にロードされる。同様に、プロトコルメッセージゲートウェイ１２２は、ユーザデータベース１２５２を含むローカルサーバ１２５０を含んでいる。さらに、代替的な実施の形態では、ローカルサーバ１２５０及びユーザデータベース１２５２は、特定の実施の形態により必要とされるときは、プロとコルメッセージゲートウェイ１２２の外にある。ユーザデータベース１２５２は、企業ネットワーク１１０内のターゲットプロトコルにより使用される、ユーザ名とスクリーン名、又はエイリアスとの間の関連を保持するために構成される。

１実施の形態では、先に記載されたように、プロトコルメッセージゲートウェイ１２２は、クライアント装置１７０から傍受されるメッセージを受信可能なセッションマネージャを含む。セッションマネージャ１２２０は、傍受されたメッセージを分析し、これに関連するメッセージプロトコルを決定するために構成される。セッションマネージャ１２２０は、メッセージ又はこれに等価な情報をローカルサーバ１２５０に送出するために構成され、このローカルサーバは、メッセージの受信を示す新たなセッションイベント１２４４を生成するために構成される。所定の実施の形態では、複数のローカルサーバ１２５０が含まれ、たとえばそれぞれは、異なるタイプのターゲットプロトコルの処理のために適合される。

セッションマネージャ１２２０は、セッションイベント１２４４を、認証モジュール１６０のようなプロトコルメッセージゲートウェイ１２２内の１以上の他のモジュールに分散するために構成される。認証モジュール１６０は、セッションイベント１２４４を受信し、ネームリクエストメッセージ１２４６を認証サーバ１２８に送出し、ネームレスポンスメッセージ１２４２を認証サーバ１２８から受信する。

たとえば、認証モジュール１６０により認証サーバ１２８に送出されたネームリクエストメッセージ１２４６は、メッセージを送出しているクライアント装置１７０のためのＩＰアドレスを含んでいる。認証サーバ１２８により認証モジュール１６０に送出されたネームレスポンスメッセージ１２４２は、メッセージを送出するクライアント装置１７０に関連する固有なユーザ名を含んでいる。ひとたびネームレスポンスメッセージ１２４２が受信されると、認証モジュール１６０は、セッションイベント１２４４に関連するセッションがなおアクティブであるかをはじめに判定するために構成される。アクティブである場場合、認証モジュール１６０は、固有のユーザ名をメッセージに関連されるスクリーン名と関連付けし、ユーザデータベース１２５２に関連を記憶する。同じスクリーン名を含むその後のメッセージが受信されたとき、認証モジュール１６０は、メッセージを送出する実際のユーザを識別するため、ユーザデータベース１２５２から関連情報にシンプルにアクセスすることができる。

ポリシーエンフォースメントモジュール１２３０、プロトコルアダプタ１２２０、及びロギングモジュール１２６０は、ユーザの識別に基づいてメッセージを処理する。たとえば、ポリシーエンフォースメントモジュール１２３０は、メッセージを送出しているユーザのアイデンティフィケーションに基づいて、メッセージをそのオリジナルに意図された目的地に送出するのを可能にするかを判定する。

複数のスクリーン名は、１つのユーザと関連することができる。したがって、ユーザデータベース１２９２に記憶される識別情報は、特定のユーザにより使用される、全てのスクリーン名、又はエイリアスの完全な関連を含むことができる。

図１３は、本実施の形態に記載されるシステム及び方法に従う、固有のユーザ名とスクリーン名を関連付けする例示的な方法を例示するフローチャートである。

はじめに、ステップ１３０２で、プロトコルメッセージゲートウェイ１２２は、受信されたメッセージを分析し、関連されるメッセージプロトコルを決定する。次いで、ステップ１３０９で、プロトコルメッセージゲートウェイ１２２は、メッセージをローカルサーバ１２５０に送出し、ステップ１３０６で、メッセージを送出しているユーザがローカルユーザであるか、すなわち企業ネットワーク１３０に結合されているかを判定する。送出しているユーザがローカルユーザである場合、ステップ１３０８で、ローカルユーザ１２５０は、メッセージに応答してセッションイベント１２４４を生成するために構成される。ユーザがローカルユーザではない場合、プロセスは、ステップ１３１２にジャンプする。

ステップ１３１０では、プロトコルメッセージゲートウェイ１２２内のローカルユーザ１２５０は、メッセージを送出しているユーザがローカルサーバ１２５０に知られているか、すなわちローカルサーバ１２５０により保持されているユーザデータベース１２５２におけるスクリーン名に関連するユーザ名であるかを判定する。メッセージを送出しているユーザがローカルユーザ１２５０に知られている場合、何も行われる必要がなく、ステップ１３２８で、メッセージは、これに応じて処理される。メッセージを送出しているユーザがローカルサーバ１２５０に知られていない場合、ステップ１３１２で、ローカルサーバ１２５０は、ゲストセッション、すなわちセッションを始めている新たなユーザによる新たなセッションを作成するために構成される。次いで、ステップ１３１４では、ローカルサーバ１２５０は、ユーザにとっての固有なユーザ名を得るのを認証サーバ１２８に要求する、認証サーバ１２８にメッセージを送出するために構成される。さらに、１実施の形態では、サーバ１２５０から認証サーバ１２８へのメッセージは、メッセージの送出者に関連するＩＰアドレスを含む。

ステップ１３１６では、認証サーバ１２８は、たとえばローカルサーバ１２５０から受信された送出されたＩＰアドレスと関連されるクライアント装置１７０を識別し、クライアント装置１７０のためのグローバルユーザＩＤ（ＧＵＩＤ）を決定するためにそのクライアント装置１７０でのレジストリを問い合わせる。認証サーバ１２８はクライアント装置１７０でのレジストリを直接的に問い合わせるので、ローカルサーバ１２９０は、それらユーザによる協力の要件なしに、それらユーザの制御下でクライアント装置の協力の要件なしに、ユーザを固有に識別する情報を取得する。ＩＭプロトコルを使用した個々のユーザがたとえば複数のスクリーン名を有する場合、ローカルサーバ１２５０は、それらのスクリーン名の全てを固有のユーザと関連付けする。

次に、ステップ１３１９では、認証サーバ１２８は、ドメインコントローラ１３２から、先に得られたＧＵＩＤに関連する固有のユーザ名を要求する。ドメインコントローラ１３２は、固有のユーザ名を送出することで応答するために構成される。

認証サーバ１２８は、ステップ１３２０で、ローカルサーバ１２５０に固有のユーザ名を送出するために構成される。

ステップ１３２２で、ローカルサーバ１２５０は、メッセージに関連されるセッションがなお進行中であるかを判定するために構成される。セッションが進行中でない、たとえばセッションがメッセージの送出者によりドロップされた場合、プロセスは終了する。セッションが進行中である場合、ステップ１３２４で、ローカルサーバ１２５０は、固有のユーザ名、及びそのスクリーン名との関連をユーザデータベース１２５２に記録する。

プロトコルメッセージゲートウェイ１２２は、実際のユーザによるそのメッセージの扱いを集合するために適合され、スクリーン名にかかわらず、それら実際のユーザは、それらの通信を選択する。したがって、個々のユーザが２つの個別のスクリーン名を有する場合、プロトコルメッセージゲートウェイ１２２は、２つの個別のスクリーン名を含むメッセージへの彼のメッセージのユーザ分離にもかかわらず、実際のユーザに関するポリシールールを実施する。たとえば、特定のポリシールールがそれぞれの時間当たり１００のＩＭメッセージを超えるメッセージをユーザが送信又は受信するのを制限した場合、プロトコルメッセージゲートウェイ１２２は、１以上のスクリーン名の下で動作している個々の実際のユーザが、結合された全てのスクリーン名についてそれぞれの時間当たり１００のＩＭメッセージを超えるメッセージを送信又は受信するのを制限する。

ユーザデータベース１２５２に記憶されるスクリーン名の関連情報は、企業ネットワーク１１０内のユーザにより生成されたメッセージが企業ネットワーク１１０内にある目的地に意図されるのを識別するために使用される。たとえば、企業ネットワーク１１０内の１ユーザ１７２は、ＩＭメッセージを企業ネットワーク内の別のユーザ１７２に送出することができる。従来のシステムでは、最初のユーザから送出されたＩＭメッセージは、ＩＭメッセージの目的地を判定するために構成されるリモートサーバに外部ネットワーク１３０を通してネットワーク１１０の外に通過させる必要がある。リモートサーバは、そのメッセージを、このケースでは企業ネットワーク１１０内の第二のユーザに送出する。本実施の形態に記載されるシステム及び方法に従って構成されるプロトコルメッセージゲートウェイ１２２は、目的地に関連されるスクリーン名を使用して、第二のユーザが企業ネットワーク１１０内にあり、企業ネットワーク１１０を出て、リモートサーバに到達するのを可能にするのとは反対に、第二のユーザにメッセージをシンプルに反映することを認識することができる。

したがって、プロトコルメッセージゲートウェイ１２２が新たなメッセージを受信したとき、メッセージのソースに関連するスクリーン名がユーザデータベース１２５２における固有のユーザ名と関連されているかを判定するだけではなく、プロトコルメッセージゲートウェイ１２２は、メッセージの目的地に関連されるスクリーン名がユーザデータベース１２５２における固有のユーザ名に関連されているかを判定するために構成されている。メッセージのソースに関連するユーザ名がユーザデータベース１２５２における固有のユーザ名と関連する場合、そのメッセージのポリシーエンフォースメントは、先に記載されたように実現される。メッセージのソースに関連するスクリーン名が固有なユーザ名と関連しない場合、スクリーン名と固有のユーザ名を関連付けする先に記載されたプロセスは、かかる関連付けを生成するために実現することができ、これは、ユーザデータベース１２５２に記憶することができる。

同様に、メッセージの目的地に関連されるセッション名が固有なユーザ名及びユーザデータベース１２５２と関連する場合、プロトコルメッセージゲートウェイ１２２は、固有のユーザ名と関連するクライアント装置１７０にメッセージをシンプルに反映するために構成される。このように、プロトコルメッセージゲートウェイ１２２は、メッセージが企業ネットワーク１１０、外部ネットワーク１３０からリモートサーバに進行して、戻るのを妨げる。この速度が企業ネットワーク１１０内のユーザ１７２間で伝達するだけでなく、企業ネットワーク１１０の外の通信と関連する問題を回避する。

目的地に関連するスクリーン名がユーザデータベース１２５２における固有のデータベースと関連しない場合、スクリーン名を固有のユーザ名と関連付けする類似のプロセスを実現することができるが、このケースでは、認証サーバ１２８は、目的地が企業ネットワーク１１０の外にあることができるため、関連付けをなすことができない場合がある。かかるケースでは、メッセージが反映されず、メッセージについて適切なポリシーエンフォースメントルールが実現される。

本実施の形態で記載されたシステム及び方法は、たとえば外部ネットワーク１３０を介してインタフェースされた複数のゲートウェイにわたり適用することができる。言い換えれば、企業は、複数のプロトコルメッセージゲートウェイを実現することができ、それぞれのゲートウェイ１２２は、他のゲートウェイ１２２及び関連するクライアント装置１７０に関連する情報を有する。したがって、ユーザデータベース１２５２に記憶される関連情報は、所定の実施の形態では、別のプロトコルメッセージゲートウェイ１２２に関連するユーザに関連する情報を有する。このケースでは、第一のプロトコルメッセージゲートウェイ１２２が、受信されたメッセージに関連されるスクリーン名又は目的地が関連されるプロトコルメッセージゲートウェイ１２２に順次に関連する固有のユーザ名と関連するとき、第一のプロトコルメッセージゲートウェイ１２２は、たとえば外部のネットワーク１３０及び関連されるプロトコルメッセージゲートウェイ１２２を通して、リモートサーバをバイパスして、目的地に直接的にメッセージをシンプルに送出するために構成される。

本実施の形態で記載されるシステム及び方法の別の実施の形態では、プロトコルメッセージゲートウェイ１２２は、ローカルクライアント装置１２２とリモートクライアント装置との間のプライバシートンネルを構築するために構成される。プライバシートンネルを考案するプロセスは、複数のプロトコルメッセージゲートウェイが含まれるときにメッセージを反映するプロセスに幾分類似しているが、このケースでは、リモートのクライアント装置は、プロトコルメッセージゲートウェイ１２２に順次に関連されるプロトコルメッセージゲートウェイに関連される必要がない。プロトコルメッセージゲートウェイ１２２は、リモートクライアント装置及び／又はこれと関連するプロトコルメッセージゲートウェイに関連する情報を知る必要がある。ローカルクライアント装置１７０がリモートクライアント装置に意図されるメッセージを生成したとき、プロトコルメッセージゲートウェイ１２２は、リモートクライアント装置及び／又はその関連されるプロトコルメッセージゲートウェイとの直接的な通信リンクをセットアップするために構成される。言い換えれば、プロトコルメッセージゲートウェイ１２２がローカルクライアント装置７０により生成されたメッセージがダイレクトコネクション情報を処理するリモートクライアント装置について意図されることを認識したとき、リモートすなわちローカルサーバはバイパスされる。さらに、ローカルクライアント装置１７０とリモートクライアント装置との間の通信リンクは、リモートサーバを介した通信がセキュアでないときでさえセキュアにされる。

図１４には、本実施の形態で記載されるシステム及び方法に係るプライバシートンネルを生成するための例示的な実施の形態を例示するフローチャートが示されている。はじめに、ステップ１４０２では、ローカルユーザ、又はリモートユーザは、プロトコルメッセージゲートウェイ１２２に信号を送出することでセキュアな通信セッションを始める１実施の形態では、ユーザは、“＜ｓｅｃｕｒｅ＞”のような特定の文字列を送信することでセキュアなセッションを始める。プロトコルメッセージゲートウェイ１２２は、ステップ１４０４で要求を観察し、ステップ１４０６でリモートクライアント装置にセキュアなシンクライアント（ｔｈｉｎ ｃｌｉｅｎｔ）をダウンロードすることでセキュアな通信チャネルを発動する。リモートクライアント装置は、ステップ１４０８でシンクライアントを発動する。プロトコルメッセージゲートウェイ１２２は、ステップ１４１０で外部ネットワーク１３０を通してセキュアな通信チャネルを確立する。

プロトコルクライアント装置がリモートクライアント装置にメッセージを送出するとき、プロトコルメッセージゲートウェイ１２２は、ステップ１４１３でメッセージを傍受し、ステップ１４１４で、リモートクライアント装置で実行しているシンクライアントに送出する。

ユーザがセキュア通信を終了するのを望むとき、それらのクライアント装置は、ステップ１４１６でプロトコルメッセージゲートウェイ１２２に示される信号を送出する。１実施の形態では、セキュアなかかるセッションの終了は、“＜ｅｎｄｓｅｃｕｒｅ＞”のような文字列を使用して指定される。プロトコルメッセージゲートウェイ１２２は、ステップ１４１０で要求を受信し、セキュアな通信チャネルを終了する。終了に応じて、シンクライアントは、その実行を終了し、リモートクライアント装置は、ステップ１４２０でシンクライアントにより使用された全てのリソースを解放する。リモートクライアント装置は、ステップ１４２２でシンクライアント装置を削除する。

所定の実施の形態では、プロトコルメッセージゲートウェイ１２２は、ローカルクライアントからメッセージを傍受し、それらをリモートクライアント装置に送出する前に、１つのメッセージプロトコルから別のプロトコルに変換する。これは、たとえば、リモートクライアント装置とローカルクライアント装置が異なるメッセージプロトコルを使用する場合に有効である。

図１５は、たとえばネットワーク１１０内のアプリケーションにユーザがログオンしたときを検出及び報告するために構成されるメッセージプロトコルゲートウェイ１５００を例示する図である。図１５の例では、プロトコルメッセージゲートウェイ１５００は、メッセージプロトコルエレメント１５１０及びユーセージデータベース１５２０を含む。メッセージプロトコルエレメント１５１０は、たとえば企業ネットワークを使用して、クライアント装置１７０にメッセージを送出し、クライアント装置１７０からのメッセージを受信し、たとえば企業ネットワーク１１０及び外部ネットワーク１３０を使用して、外部のクライアント装置にメッセージを送出し、外部のクライアント装置からメッセージを受信する。メッセージプロトコルエレメント１５１０により送出又は受信されたメッセージは、それら先に記載されたような様々なターゲットプロトコルを実現することができる。

ユーセージデータベース１５２０は、ユーザテーブル１５５０及び反転されたユーザテーブル１５６０を含む、データベーステーブルのセットを含む。ユーセージデータベース１５２０はユーザの存在を検出及び報告するのに関して本実施の形態で記載されるが、ユーセージデータベース１５２０は、他のリソースの存在又は不存在を検出及び報告すること、他のタイプのイベントを検出及び報告することへの非常に一般的な拡張が可能であることは明らかである。また、ユーセージデータベース１５２０は、ＳＱＬインストラクション１５２２のセット及びＳＱＬエクステンション１５４０のセットを含むデータベースコードのセットを含む。勿論、ユーセージデータベース１５２０は、本実施の形態ではＳＱＬに関してデータベース操作及び問合せ言語の個々の例として記載しているが、ユーセージデータベース１５２０は、他のタイプのデータベース操作及び問合せについて、他のタイプのデータベース又はデータソース一般に対して構成することができることを理解されたい。

１実施の形態では、ユーザテーブル１５５０は、それぞれが選択されたユーザについて情報を含む、「行」と呼ばれることがあるエントリ１５５２のセットを含んでいる。かかる実施の形態では、ユーザテーブル１５５０は、そのエントリ１５５２に関連されるユーザについて、それぞれが選択されたデータアイテム又はデータアイテムのリストを含む、それぞれのエントリ１５５２について「列」と呼ばれることがあるフィールド１５５４のセットを含んでいる。たとえば、ユーザテーブル１５５０は、選択されたユーザに関連するユーザ名を含む第一のフィールド１５５４ａ、選択されたユーザに関連するコンタクトリストを含む第二のフィールド１５５４ｂ、及び選択されたユーザに関連するオンライン／オフラインステータスを含む第三のフィールド１５５４ｃを含んでいる。

フィールド１５５４ｂは、実施の形態に依存して、多次元の列を含んでおり、すなわちフィールド１５５４に関連する値がそれ自身にリストとなる。ＳＱＬエクステンション１５４０は、たとえば多次元の列１５５４からの複数の行のリストを生成可能な機能、及びリストから多次元の列１５５４を生成可能な機能を含む。これは、特に多数のデータベーステーブルをリンクすることを含むデータベースの問い合わせは、１つのデータベーステーブルでの動作を使用して実行可能であるという作用を有する。たとえば、多次元の列を使用することなしに、コンタクトリストを選択されたユーザとの関連付けすることは、すなわちユーザＡ及びユーザＢといったそれぞれのユーザのペアについて、ユーザＢがユーザＡのコンタクトリストにあるかを示す個別のリンクテーブルを含んでいる。したがって、コンタクトリストの問合せを行うことは、リンキングテーブルの少なくとも１つのサーチ、及びユーザテーブルの少なくとも２つのサーチを含んでいる。多次元の列を使用することで、コンタクトリストを選択されたユーザと関連付けすることは、ユーザテーブルそれ自身の１つのサーチと、コンタクトリストについて使用される多次元の列からリストを生成するためのＳＱＬエクステンション１５４０の使用を含んでいる。

１実施の形態では、ユーザテーブル１５５０に類似した、反転されたユーザテーブル１５６０は、それぞれが選択されたユーザ１７２について情報を含むエントリ１５５７のセットを含んでいる。ユーザテーブル１５５０に類似した、反転されたユーザテーブル１５６０は、そのエントリ１５５６に関連されるユーザについて、選択されたデータアイテム又はデータアイテムのリストをそれぞれが含む、それぞれのエントリ１５５６にフィールド１５８のセットを含んでいる。１実施の形態では、反転されたユーザテーブル１５６０は、選択されたユーザに関連するユーザ名を含む第一のフィールド１５５８ａ、及び選択されたユーザに関連する反転されたコンタクトリストを含む第二のフィールド１５５８ｂを含む。このケースにおけるその選択されたユーザに関連する反転されたコンタクトリストは、それらのコンタクトリストで選択されたユーザを列挙した他のユーザを示すために使用することができる。これに応じて、新たにログインしたユーザが検出されたとき、その新たにログインしたユーザの存在が通知されるのを望む他のユーザのセットをサーチするは比較的容易である。

１実施の形態では、ＳＱＬエクステンション１５４０は、頻繁に実行されることが期待されるデータベースの問合せのセットを指定可能な機能を含み、反転されたユーザテーブル１５６０とユーザテーブル１５５０との間の関係に類似した、オリジナルテーブルに応答して反転されたテーブルを構築するのが望まれる。かかる実施の形態では、ＳＱＬエクステンション１５４０は、たとえば、以下の機能のうちの１以上を含んでいる。反転されたユーザテーブル１５６０とユーザテーブル１５５０との間の関係に類似した、オリジナルテーブルに応答して反転されたテーブルが自動的に構築されるべきかを設計者が規定し、構築されるべき場合、反転されたテーブルのフィールド１５５８がオリジナルテーブルの対応するフィールド１５５４にどのように関連するかを設計者が規定するのを可能にする機能、オリジナルテーブルに関連する問合せが反転されたテーブルに関連して実行されるべき問合せに変換されるべきかを設計者が規定するのを可能にし、変換されるべき場合、反転されたテーブルのフィールド１５５８がオリジナルテーブルのフィールド１５５４のテストに対応してどのように試験されるべきかを設計者が規定するのを可能にする機能、オリジナルテーブル又は反転されたテーブルのいずれかに関連する問い合わせが後の仕様のためにキャッシュされるその結果を有するべきかを設計者が規定するのを可能にし、有するべき場合、トリガに応じて、問合せ及び／又は後の使用が実行される。

たとえば、コンタクトリストのどのユーザがログインしたかに関すル問合せは、以下のトリガの１以上に応じて実行される場合がある。（１）ユーザがログインしたとき、（２）ユーザがログアウトしたとき、（３）選択された時間が経過した後、（４）プロトコルメッセージゲートウェイ１５００がリブート又はリセットされた後、及び（５）選択された数のメッセージが処理された後。

また、ＳＱＬエクステンション１５４０は、オリジナルテーブル又は反転されたテーブルのいずれかに関連する問合せが実行され、その結果が実際の要求の前に計算されるべきであるか、計算されるべきである場合、トリガに応答してその問合せが実行されるべきことを設計者が規定するのを可能にする機能を含む。

また、ＳＱＬエクステンション１５４０は、テーブルが多次元の列を含むべきか、含むべき場合に、その多次元の列が問い合わせの結果に応答してどのように扱われるべきかを設計者が規定するのを可能にする機能を含む。たとえば、コンタクトリストのどのユーザがログインしたかに関する問合せは、それぞれのユーザのコンタクトリストに関連する多次元の列を含み、問合せの実行に応じて、多次元の列からの結果が集められ、問合せされたユーザのコンテンツリストの１つである特定のユーザの個々の行応答に分割される。

したがって、プロトコルメッセージゲートウェイ１５００は、効率的、ネットワーク１１０に存在するユーザの時間の節約される検出を可能にするために構成され、ユーザに使用されているアプリケーションにログオンすることができる。これは、ネットワーク１１０内の処理及び他のリソースを節約することができる。この機能は、たとえば、他のタイプのデータベース及びデータベースサーチについて、ネットワークアドミニストレータが多次元の列及び多次元の列の関連付けを定義するのを可能にすることで拡張される。

図１６は、本実施の形態で記載されるシステム及び方法の１実施の形態に係るユーザの存在を検出及び報告する例示的な方法を説明するフローチャートである。はじめに、ステップ１６０２では、クライアント装置１７０での内部ユーザ１７２、又は外部クライアント装置での外部ユーザは、アプリケーションを使用するためにログインするのを試みる。ステップ１６０で、関連されるクライアント装置１７０は、たとえばユーザ名又はスクリーン名をログインするのを試みることを示し、ログインするのが必要とされる情報を含むメッセージをプロトコルメッセージゲートウェイ１２２に送出するために構成される。ステップ１６０６では、プロトコルメッセージゲートウェイ１２２は、ログインする試みを示すメッセージを受信し、たとえばその受信を示してクライアント装置１７０に応答する。ステップ１６０８では、プロトコルメッセージゲートウェイ１２２がログインの試みを証明するか、又はログインの試みを否定するに十分な情報を有する場合、そのように示してクライアント装置１７０に応答するために構成される。

たとえば、プロトコルメッセージゲートウェイ１２２は、どの内部ユーザ１７２及びどの外部ユーザがアプリケーションを使用するためにログインすることが現在許可されているか示す、外部サーバから利用可能なキャッシュされた情報を有するために構成することができる。かかる実施の形態では、アプリケーションの使用は、外部サーバへのアクセスに関連される。したがって、ログインは、たとえばアプリケーションに関連される外部サーバといったサーバにログインする試みである。

別の実現では、プロとコルメッセージゲートウェイ１２２は、たとえば公開鍵の暗号化システム又は他の信頼されるサーバへの参照によるような、ログインメッセージが有効であるかを判定することができる利用可能な公知の手順を有するために構成される。

ステップ１６１０では、ログインが成功した場合、プロセスはステップ１６１２に続く。しかし、ログインが失敗した場合、プロトコルメッセージゲートウェイ１２２は、試みを拒否し、別のメッセージを待つ（ステップ１６０２）。ステップ１６１２では、プロトコルメッセージゲートウェイ１２２は、ログインに関連されるＳＱＬインストラクション１５２０を実行するために構成される。たとえば、ＳＱＬインストラクション１５２０は、たとえば複数の多次元の列を使用するときのような、ＳＱＬエクステンション１５４０のセットを要求する。

１実施の形態では、ログインメッセージに関連されるＳＱＬインストラクション１５２０は、内部ユーザ１７２又は外部ユーザである、新たにログインされたユーザについてコンタクトリストの他のユーザもログインしたかを検出することを含む。たとえば、ＳＱＬインストラクション１５２０は、新たにログインしたユーザに関連するコンタクトリストをサーチし、そのコンタクトリストのユーザが既にログインしたかを判定する、ユーザテーブル１５５０に対して実行されるべき問合せを含む。したがって、新たにログインしたユーザは、既にログインした関連するユーザが通知される。

別の実施の形態では、ログインに関連されるＳＱＬインストラクション１５２０は、新たにログインしたユーザが既にログインしたユーザのコンタクトリストであるかを検出することを含んでいる。したがって、その新たにログインされたユーザのコンタクトリストにある場合、既にログインされたユーザは、新たにログインしたユーザの存在が通知される。

したがって、ステップ１６１２で、ＳＱＬインストラクション１５２０を実行することは、ユーセージデータベース１５２０に、新たにログインされたユーザについて反転されたユーザテーブル１５６０をサーチするように指示する。１実施の形態では、ログインに関連されるＳＱＬインストラクション１５２０は、新たにログインされたユーザについて反転されたユーザテーブル１５６０をサーチするためにＳＱＬエクステンション１５４０のセットを要求する。たとえば、１実施の形態では、それらのコンタクトリストの新たにログインされたユーザを列挙するユーザのセットは、サーチを実行する作用によりかかるユーザのリストが提供されて、多次元の列を含むためにＳＱＬエクステンション１５４０により規定される。この例では、多次元の列は、それぞれがそれらのコンタクトリストに新たにログインされたユーザを列挙する１つのユーザを示す、行のセットに拡張されるべきＳＱＫエクステンション１５４０により規定される。したがって、ＳＱＬインストラクション１５２０又は他のインストラクションは、新たにログインされたユーザの、ユーザの存在をそれらのユーザのそれぞれに通知するために利用することができる。プロトコルメッセージゲートウェイ１２２は、ユーザの存在のそれらのコンタクトリストの新たにログインされたユーザを列挙しているユーザのセットにそれぞれを通知するために構成される。

類似のステップは、たとえば、新たなユーザがプロトコルメッセージゲートウェイ１２２により登録されたとき、システムアドミニストレータ又はチャットルームファシレータのような選択されたタイプのユーザがそれらのユーザの存在の状態を変えたとき、又はユーザがログアウトしたときを含めた、ユーザの存在の状態の作用を有する他のアクションに応答して、プロトコルメッセージゲートウェイ１２２により実行されることが明らかである。

たとえば、プロトコルメッセージゲートウェイ１２２により使用されるソフトウェアエレメントを更新することが必要なことがある。しかし、ソフトウェアが更新されている間にそれらのプロトコルの使用がディスエーブルにされる必要があるため、ソフトウェアエレメントを更新するためにプロトコルメッセージゲートウェイ１２２をシャットオフすることは望まれないことがあり、ソフトウェアが更新されるときに進行中のプロトコルセッションが終了されることも可能である。

したがって、図１７は、本実施の形態で記載されたシステム及び方法の１実施の形態に従って動的に更新されるプラガブル（ｐｌｕｇｇａｂｌｅ）モジュールをもつ例示的な通信装置１７００を例示する図である。装置１７００は、たとえばモジュール１７２２，１７２４及び／又は１７２６を含むプラガブルモジュール１７２０のセットを通して通信ネットワーク１７１０に結合される。それぞれのプラガブルモジュールは、１７２２，１７２４及び／又は１７２６は、セントラルモジュール１７３０と結合されている。セントラルモジュール１７３０は、たとえば、カーネルのようなプラガブルであるように設計されないモジュール、又はプラガブルモジュールマネージャを含む。先に記載されたように、従来のシステムでは、プラガブルモジュール１７２２，１７２４及び／又は１７２６が更新されたとき、そのモジュールに関わる通信がシャットダウンされる必要がある。さらに、アップグレードプロセスの間、そのモジュールを通した通信が行われない。

図１７の例では、プラガブルモジュール１７２２，１７２４及び／又は１７２６は、サービスへの混乱なしにアップグレードされる。たとえば、モジュール１７２２がプロトコルＡをサポートし、モジュールＢがプロトコルＢをサポートし、及びモジュール１７２６がプロトコルＣをサポートするとする。たとえば新たなモジュール１７２８といったプロトコルＡをサポートする新たなモジュールが利用可能であって、アップグレードが望まれるとき、装置１７００は、アップグレードを要求するために構成することができる。しかし、アップグレードが要求されたときに、モジュール１７２２が通信をサポートすることに関与する場合、新たなモジュール１７２８をロードすることができ、しかし、モジュール１７２２を使用した全ての通信が終了するまで、モジュール１７２２を保持することができる。アップグレード、すなわちモジュール１７２８のロードが行われた後、プロトコルＡを使用した新たな通信は、モジュール１７２２とは対照的にモジュール１７７８によりサポートされる。さらに、モジュール１７２２を使用した全ての通信がひとたび停止すると、モジュール１７２２に関連するリソースがリリースされ、アップグレードプロセスが完了される。

通信装置１７００は、たとえばプロトコルメッセージゲートウェイ１２２である。別の実施の形態では、通信装置１７００は、プロキシエンフォーサ１５０とすることができ、この場合、プラガブルモジュール１７２２，１７２４及び／又は１７２６は、プロトコルインスペクタとすることができる。記載されたシステム及び方法は、新たなソフトウェアモジュールをアップロードするために構成される多岐にわたる装置に適用されることを理解されたい。

図１８は、図４に例示されるものに対する類似した詳細でプロトコルメッセージゲートウェイ１２２を例示する図である。図１８の例では、しかし、プロトコルメッセージゲートウェイ１２２を含むモジュール又はアダプタは、本実施の形態で記載されるシステム及び方法に従って動的に更新される。したがって、プロトコルメッセージゲートウェイ１２２は、プロトコルメッセージパーサ４１０、ゲートウェイマネージャ４２０、プロトコルアダプタ４３０のセット、ポリシーエンフォースメントモジュール４４０、認証モジュール４５０、更なるモジュールアダプタ４６０のセットを含んでおり、これらは以下に更に記載される。

プロトコルアダプタ４３０は、たとえば、第一の古いプロトコルアダプタ１８３２のセット、第二の新たなプロトコルアダプタ１８３４のセットを含んでいる。結果として、古いプロトコルアダプタ１８３２は、関連するメッセージプロトコルを使用している通信セッションに関して使用されている。古いプロトコルアダプタ１８３２に関連する特定のメッセージプロトコルは、たとえばもはや関心がないか、又は新たなバージョンのプロトコルアダプタ１８３２が利用可能であって、新たなプロトコルアダプタ１８３４のロードとなる。

１実施の形態では、プロトコルメッセージパーサ４１０は、インバウンド及びアウトバンドメッセージを受信し、受信されたメッセージを調べ、特定の受信されたメッセージを処理するためにどのプロトコルアダプタ４３０が適切であるかを判定する。プロトコルメッセージパーサ４１０は、受信されたメッセージを更なる処理のためにゲートウェイマネージャ４２０に送出する。ゲートウェイマネージャ４２０は、メッセージを受信し、メッセージと関連されるべき必要なデータ構造４２２を作成するために構成することができる。データ構造４２２は、幾つかのプロトコルが複数のメッセージにわたり状態情報を保持するので新たな通信セッション又は古い通信セッションに関連される。

ゲートウェイマネージャ４２０は、プロトコルメッセージゲートウェイ１２２内の他のコンポーネントへのメッセージに関連する情報を発するために構成される。たとえあ、ゲートウェイマネージャ４２０は、選択されたプロトコルアダプタ４３０若しくは他のモジュール又はアダプタへのメッセージに関する情報を発するために構成される。したがって、少なくとも１つのプロトコルアダプタ４３０は、メッセージに関連するプロトコルを認識すべきであって、したがって、ゲートウェイマネージャ４２０により発せられるプロトコルメッセージ及び関連される情報を受信する。メッセージ及び情報を受信するプロトコルマネージャ４３０は、メッセージプロトコルに関連する処理パラダイムにメッセージがどのようにフィットするかを判定するために構成される。たとえば、メッセージがＩＭメッセージの送出者と受信者のような送出者と受信者との間でセッションを始動する場合、関連するプロトコルアダプタ４３０は、新たなセッションが作成されるべきことを判定するために構成される。

また、プロトコルメッセージゲートウェイ１２２は、ポリシーエンフォースメントモジュール４４０及び関連されるポリシールールデータベース４４４、認証モジュール４５０及び関連する認証データベース４５４、ロギングモジュール４７０及び関連するロギングデータベース４７４のような他のモジュール又はアダプタを有する。実現に依存して、これらモジュール又はアダプタのそれぞれは、特定の通信セッション及び関連するメッセージプロトコルに関連する不断の状態情報を保持するために構成される。

時間的に特定の瞬間で、プロトコルメッセージゲートウェイ１２２は、１以上のモジュール又はアダプタの新たなバージョンと古いバージョンの両者を含む、これらモジュール又はアダプタのそれぞれのうちで１を超えるモジュール又はアダプタを含む。同様に、ポリシールールデータベース４４４、認証データベース４５４、ロギングデータベース４７４、又は他のデータ構造４２２のような、それらモジュール又はアダプタに関連するデータベースの多数のバージョンは、ゲートウェイマネージャ４２０又はプロトコルメッセージゲートウェイ１２２の他のエレメントにより保持される。

たとえば、古いプロトコルアダプタ１８３２は、本実施の形態で記載されるシステム及び方法に従って新たなプロトコルアダプタ１８３４で置き換えられる。結果として、プロトコルメッセージゲートウェイ１２２は、古いプロトコルアダプタ１８３２及び新たなプロトコルアダプタ１８３４の両者を同時に含む。しかし、古いプロトコルアダプタ１８３２は既存の通信セッションに関わる場合、全ての係る既存のセッションが完了するまで保持される。そのとき、新たなセッションは、新たなプロトコルアダプタ１８３４を使用するために構成され、古いプロトコルアダプタ１８３２は除かれる。この能力により、プロトコルメッセージゲートウェイ１２２は、たとえばプロトコルメッセージゲートウェイをパワーダウンするか、又は既存の通信セッションを終了する必要なしに動的に更新することができる。

図１９は、本実施の形態で記載されるシステム及び方法に従ってソフトウェアモジュールを動的に更新するための例示的な方法を説明するフローチャートである。たとえば、図１９の方法は、新たなモジュールアダプタ１８３４で古いモジュールアダプタ１８３２を更新するために使用する。したがって、ステップ１９０２では、メッセージパーサ４１０は、受信されたメッセージに関連するメッセージプロトコルを決定し、ステップ１９０４でメッセージをゲートウェイマネージャ４２０に送出するために構成される。ステップ１９０６では、ゲートウェイマネージャ４２０は、たとえばデータ構造４２２により示されるように、公知の進行しているセッションとメッセージが関連付けされているかを判定するために構成される。

メッセージが実際に公知の進行しているセッションと関連している場合、ゲートウェイマネージャ４２０は、ステップ１９０８で、たとえば古いプロトコルアダプタ１８３２といったどのプロトコルアダプタ４３０がメッセージと関連しているか、及び特定のセッションがどのメッセージに属するかを含めて、データ構造４２２から情報を検索するために構成される。メッセージが古いプロトコルアダプタ１８３２と関連している場合、ゲートウェイマネージャ４２０は、少なくとも１つのセッションについてなお使用していることを示して、ステップ１９１０で、古いプロトコルアダプタ１８３２に関する状態情報を維持するために構成される。

ステップ１９１２で、ゲートウェイマネージャ４２０は、場合に応じて古いプロトコルアダプタ１８３２又は新たなプロトコルアダプタ１８３４のいずれかである、指定されたプロトコルアダプタ４３０にメッセージの到達に関する情報を送出する。

ステップ１９０２で受信されたメッセージが進行しているセッションの一部ではない場合、ステップ１９１４で、ゲートウェイマネージャ４２０は、たとえばデータ構造４２２から、どのプロトコルアダプタ４３０とメッセージが関連しているかに関する情報を検索する。ステップ１９１６で、同時に存在する新たなプロトコルアダプタ１８３４及び古いプロトコルアダプタ１８３２があるかが判定される。同時に存在する古いプロトコルアダプタ１８３２及び新たなプロトコルアダプタ１８３４がある場合、ゲートウェイマネージャ４２０は、新たなプロトコルアダプタ１８３４を選択し、ステップ１９１８で新たなプロトコルアダプタ１８３４にメッセージを送出する。次いで、ステップ１９２０で、メッセージが処理される。

ステップ１９２２では、プロトコルメッセージゲートウェイ１２２は、新たなプロトコルアダプタ１８３４を受ける準備がある。ステップ１９２４では、プロトコルメッセージゲートウェイ１２２は、新たなプロトコルアダプタ１８３４をインストールし、新たなプロトコルアダプタ１８３４を使用するのに利用可能にする。ステップ１９２６では、ゲートウェイマネージャ４２０は、新たなプロトコルアダプタ１８３４が関連するメッセージプロトコルに関連されることを示すため、データ構造４２２を変更する。ステップ１９２８では、ゲートウェイマネージャ４２０は、古いプロトコルアダプタ１８３２を使用したセッションはなお動作中であるかを判定するため、データ構造４２２をチェックするために構成される。かかるセッションがある場合、ゲートウェイマネージャ４２０は、指定された時間を待ち、ステップ１９２８を繰り返す。かかるセッションが存在しない場合、ゲートウェイマネージャ４２０は、古いプロトコルマネージャ１８３２がもはや使用されないことを判定して、古いプロトコルアダプタ１８３２を消去する。

このようにして、ソフトウェアモジュールは、サービスにおける割込みなしで動的に更新される。したがって、たとえば、プロトコルメッセージゲートウェイ１２２は、最新のアダプタおよびモジュールを維持しつつ、全ての既存のセッション及びメッセージをサービスし続ける。ひとたび全ての既存のセッション及びメッセージがサービスされると、新たな更新されたモジュールは、全ての新たなメッセージ及びセッションをサービスするために使用される。

本発明の所定の実施の形態が先に記載されたが、記載された実施の形態は例示するのみであることを理解されたい。したがって、本発明は、記載された実施の形態に基づいて制限されるべきではない。むしろ、本実施の形態で記載される本発明の範囲は、先の記載及び添付図面と共に読まれたときに従う特許請求の範囲に照らしてのみ制限される。

プロトコル管理システムを組み込むために構成される企業ネットワークの例示的な実施の形態を示す図である。 プロキシエンフォーサを含むシステムのブロック図である。 プロキシエンフォースメントを含む方法のプロセスフローチャートである。 関心のあるプロトコルに対するプロテクションが可能なゲートウェイのブロック図である。 関心のあるプロトコルに対するプロテクションは可能なゲートウェイを動作する方法に関するプロセスフローチャートである。 ＣＶＰ方法を使用したプロトコルメッセージゲートウェイの配置のブロック図である。 ゲートウェイプロキシ方法を使用したプロトコルメッセージゲートウェイの配置を例示するブロック図である。 外部のネームサーバのみが使用される場合のＤＮＳリディレクト方法を使用したプロトコルメッセージゲートウェイの配置を例示するブロック図である。 内部のネームサーバが企業内ネットワーク内の全てのクライアント装置により使用される場合のＤＮＳリディレクト方法を使用したプロトコルメッセージゲートウェイの配置を例示するブロック図である。 ＨＴＴＰトンネル方法を使用したプロトコルメッセージゲートウェイの配置を例示するブロック図である。 ＩＳＡアプリケーションフィルタ方法を使用したプロトコルメッセージゲートウェイの配置を例示するブロック図である。 関心のあるプロトコルのユーザとスクリーン名の関連付けが可能なローカルサーバのブロック図である。 関心のあるプロトコルのユーザとスクリーン名の関連付けを含む方法のプロセスフローチャートである。 プライバシートンネルを使用した通信のための方法のプロセスフローチャートである。 ユーザの存在を検出するために構成されるメッセージプロトコルゲートウェイを例示するブロック図である。 ユーザの存在を検出するための方法のプロセスフローチャートである。 所定のソフトウェアモジュールが動的に更新されるのを可能にするために構成される通信装置を示す図である。 ソフトウェアの動的な更新のためのプロトコルメッセージゲートウェイの構成を示す図である。 ソフトウェアモジュールを動的に更新する方法を例示するフローチャートである。

Claims (21)

1. ソフトウェアモジュールを動的に更新する方法であって、
   新たなソフトウェアモジュールをダウンロードするステップと、
   古いソフトウェアモジュールが既存のルーチンをサービスしているかを判定するステップと、
   古いソフトウェアモジュールが既存のルーチンをサービスしている場合、前記新たなサービスモジュールが新たなルーチンをサービスするのを可能にしつつ、前記古いソフトウェアモジュールが前記既存のルーチンをサービスし続けるのを可能にするステップと、
   を含むことを特徴とする方法。
2. 前記古いソフトウェアモジュールがもはやルーチンをサービスしないときを判定し、前記古いソフトウェアモジュールを終了するステップとを更に含む、
   請求項１記載の方法。
3. 前記古いソフトウェアが既存のルーチンをサービスしない場合、前記新たなソフトウェアモジュールが新たなルーチンをサービスするのを可能にして前記古いソフトウェアモジュールを終了するステップを更に含む、
   請求項１記載の方法。
4. 前記既存のルーチン及び新たなルーチンは通信セッションである、
   請求項１記載の方法。
5. 前記古いソフトウェアモジュール及び新たなソフトウェアモジュールはプロトコルアダプタである、
   請求項１記載の方法。
6. 前記新たなソフトウェアモジュールが利用可能であるかを判定するステップと、前記新たなソフトウェアモジュールが利用可能であると判定されたとき、前記新たなソフトウェアモジュールをダウンロードするステップとを更に含む、
   請求項１記載の方法。
7. ソフトウェアモジュールを動的に更新する方法であって、
   ソフトウェアモジュールに関連されるメッセージを受信するステップと、
   １を超えるバージョンのソフトウェアモジュールが存在するかを判定するステップと、
   １を超えるバージョンが存在する場合に、古いバージョンのソフトウェアモジュールによりメッセージがサービスされているかを判定するステップと、
   古いバージョンのソフトウェアモジュールによりメッセージがサービスされたと判定された場合、前記古いバージョンのソフトウェアモジュールによりメッセージがサービスされ続けるのを可能にするステップと、
   を含むことを特徴とする方法。
8. 唯一のバージョンのソフトウェアモジュールが存在する場合、前記ソフトウェアモジュールによりメッセージがサービスされるのを可能にするステップを更に含む、
   請求項７記載の方法。
9. 古いバージョンのソフトウェアモジュールによりメッセージがサービスされていると判定されない場合、新たなバージョンのソフトウェアモジュールによりメッセージがサービスされるのを可能にするステップを更に含む、
   請求項７記載の方法。
10. 前記古いバージョンのソフトウェアモジュールによりメッセージがサービスされるかを判定するステップと、前記古いバージョンのソフトウェアモジュールによりメッセージがサービスされない場合に、前記古いバージョンのソフトウェアモジュールを終了するステップとを更に含む、
    請求項７記載の方法
11. 古いバージョンのソフトウェアモジュールによりメッセージがサービスされるかを判定するステップは、どのバージョンのソフトウェアモジュールがメッセージをサービスしているかを判定するためにデータ構造をチェックするステップを含む、
    請求項７記載の方法。
12. 通信装置により受信されたメッセージをサービスするために構成される古いソフトウェアモジュールと、
    新たなソフトウェアモジュールをダウンロードするために構成される通信インタフェースと、
    前記古いソフトウェアモジュールが既存のルーチンをサービスしているかを判定し、前記古いソフトウェアモジュールが既存のルーチンをサービスしている場合、前記新たなソフトウェアモジュールが新たなルーチンをサービスするのを可能にしつつ、前記古いソフトウェアモジュールが既存のルーチンをサービスし続けるのを可能にするために構成されるゲートウェイマネージャと、
    を有することを特徴とする通信装置。
13. 前記ゲートウェイマネージャは、前記古いソフトウェアモジュールがもはやルーチンをサービスしないときを判定し、前記古いソフトウェアモジュールを終了させるために更に構成される、
    請求項１２記載の通信装置。
14. 前記ゲートウェイマネージャは、前記古いソフトウェアが既存のルーチンをサービスしていない場合に、前記新たなソフトウェアモジュールが新たなルーチンをサービスするのを可能にしつつ前記古いソフトウェアモジュールを終了させるために更に構成される、
    請求項１２記載の通信装置。
15. 前記古いソフトウェアモジュール及び新たなソフトウェアモジュールはプロトコルアダプタである、
    請求項１２記載の通信装置。
16. 前記古いソフトウェアモジュール及び新たなソフトウェアモジュールは認証モジュールである、
    請求項１２記載の通信装置。
17. 前記古いソフトウェアモジュール及び新たなソフトウェアモジュールは、ポリシーエンフォースメントモジュールである、
    請求項１２記載の通信装置。
18. 前記古いソフトウェアモジュール及び新たなソフトウェアモジュールは、ロギングモジュールアダプタである、
    請求項１２記載の通信装置。
19. 前記古いソフトウェアモジュール及び新たなソフトウェアモジュールは、データベースモジュールである、
    請求項１２記載の通信装置。
20. メッセージを受信し、受信されたメッセージを処理するためにどのソフトウェアモジュールが必要とされるかを判定するために構成されるメッセージパーサを更に有する、
    請求項１２記載の通信装置。
21. 前記ゲートウェイマネージャは、前記受信されたメッセージのデータ構造を生成するために更に構成され、古いバージョンのソフトウェアモジュールによりメッセージがサービスされているかを判定することは、どのバージョンのソフトウェアモジュールがメッセージをサービスしているかを判定するためにデータ構造をチェックすることを含む、
    請求項１９記載の通信装置。
    

Images