JP2008523735A - ネットワーク装置を有する電子メッセージ配信システム - Google Patents

Abstract

オープンシステムインターコネクションモデルに基づき、少なくともネットワークレイヤ（レイヤ３）とアプリケーションレイヤ（レイヤ７）とを有するコンピュータネットワークシステムにおいて、当該コンピュータネットワークシステムとの間の電子メッセージトラフィックを管理するシステム及び方法は、電子メッセージトラフィックのフローを向上させるのに利用するため、レイヤ３とレイヤ７との間でデータを直接やりとりするレイヤ３とレイヤ７との間の通信チャネルを規定することを有する。

Description

発明の詳細な説明

［関連出願の相互参照］
本発明は、参照することによりその内容がここに含まれる２００４年１２月１３日に出願された米国特許仮出願第６０／６３５，８０３号の利益を主張する。

［開示の背景］
本開示は、一般に電子メッセージングシステムに関し、より詳細には、インターネットを介し送信者から受信者への電子メッセージを処理する電子メッセージ配信システムに関する。

今日、電子メッセージングの最も普及した形態である電子メールは、ネットワーク上で機能する不可欠なサービスであり、電子メールトラフィック及び管理コンプレクシティは急速に増大している。ネットワークオペレータは、それらの電子メールネットワークのサイズとそれらを処理するコストとを管理しながら、キャパシティ及びコンプレクシティチャレンジに対応するため観察するため、より良い手段に対する増大する強力な要求が存在する。

電子メールは、Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ（ＳＭＴＰ）と呼ばれる通信プロトコルによって規定されるサーバ間の一形式の電子通信である。ＳＭＴＰプロトコルは、電子メールメッセージを通常は１つのサーバから他のサーバに移動させる通信機構であり、一方から他方へのメッセージの送信のため、２つのサーバ間のマルチステップな情報交換に関するものである。同様のプロトコルが、他のタイプの電子メッセージング（ＳＭＳなど）に利用されている。

一般に、ＯＳＩモデルとして知られ、コンピュータシステム及びネットワークのマルチレイヤ動作環境を記述したオープンシステムインターコネクションモデルに対する７つのレイヤが存在することが知られている。各レイヤは、ハードウェア上でビット及びバイトを実行する最も低いレベルのマシーンコード（レイヤ１又は“物理レイヤ”）から最も高いレイヤ（レイヤ７又は“アプリケーションレイヤ”）まで、次の上位の抽象化ステップを表す。図１において、ＯＳＩモデルに基づく従来のコンピュータネットワークシステムの一例が示されている。図１は、物理レイヤ１２（レイヤ１）、データリンクレイヤ１４（レイヤ２）、ネットワークレイヤ１６（レイヤ３）、トランスポートレイヤ１８（レイヤ４）、セッションレイヤ２０（レイヤ５）、プレゼンテーションレイヤ２２（レイヤ６）及びアプリケーションレイヤ２４（レイヤ７）を有するコンピュータネットワークシステム１０を示す。矢印系列３０により示されるように、各レイヤは、隣接するレイヤとのみ通信する。すなわち、情報は、典型的なＯＳＩシステムでは隣接レイヤ間でのみやりとりされる。

ＳＭＴＰ及び他の電子メッセージプロトコルは、最も高いレイヤであるレイヤ７（又は図１に示されるようなアプリケーションレイヤ２４）上で実行されるソフトウェアアプリケーションを介し実行される。電子トラフィックルーティング及びセキュリティの多くの重要な機能は、データパケットトランザクションが行われるレベルであるレイヤ３（すなわち、図１に示されるようなネットワークレイヤ３）で行われる。これは、ルータ、スイッチ、ファイアウォールなどを含む多数のネットワーク装置の主要機能に対する処理の活動領域である。

典型的な電子メールシステムでは、電子メールサーバ又はメールトランスポートエージェント（ＭＴＡ）はレイヤ７上でのみ機能する。電子メールシステムを有するネットワークでは、ネットワークレイヤであるレイヤ３は、典型的には、アプリケーション関連プロトコル若しくは要件に関係なく、メッセージ関連機能若しくは設定とやりとりすることなく、ネットワークトラフィック上で動作する（例えば、データパケットをルーティングするなど）。従って、電子メール及び他のメッセージトラフィックについて、ルーティング及びセキュリティ機能は（プライオリティ、トラフィックアクセス、帯域幅割当て、フェイルオーバー、データ暗号化、リレイなど）、レイヤ３及びレイヤ７における独立して決定された基準及び独立したアクション全体を利用して個別に実行される。１つのレイヤで収集された関連するトラフィックフロー又はセキュリティ情報は、当該レイヤにのみ可視化され、動作可能である。

電子メッセージングのための標準的なネットワークコンフィギュレーションは、ネットワークとの間でデータをルーティングするためのネットワーク装置（スイッチなど）とメッセージトランスポートサーバ（ＭＴＡなど）から構成される。ＭＴＡ及びネットワーク装置は、個別に構成され、通信しない。図４Ａにおいて、このような標準的なネットワークコンフィギュレーションの例が示される。図４Ａは、ネットワーク装置５４を介しインターネット５６に接続されるＭＴＡ５２を含む従来技術による電子メッセージングシステム５０を示す。ＭＴＡ５２及びネットワーク装置５４は、ＳＭＴＰリンク５８（双方向の破線により示される）により通信し、ネットワーク装置５４は、他のＳＭＴＰリンク６０（他の双方向の破線により示される）によりインターネット５６に接続される。ネットワーク装置５４は、ＡＰＩ又はコマンドインタフェース６２を有してもよいが、インタフェース６２は、ＭＴＡ５２及びインターンネット６２に直接的には接続されない。

［開示の概要］
以下でより詳細に説明されるように、オープンシステムインターコネクションモデルに基づくコンピュータネットワークシステムにおいて利用される方法が開示される。コンピュータネットワークシステムは、少なくともネットワークレイヤ（レイヤ３）と、アプリケーションレイヤ（レイヤ７）とを有する。コンピュータネットワークシステムとの電子メッセージトラフィックの入力フローと出力フローを管理する方法は、電子メッセージトラフィックの入力フロート出力フローの少なくとも１つを向上させるのに利用されるレイヤ３とレイヤ７との間の直接的な情報交換を含む。“向上”という用語は、以下に限定されるものではないが、以下の記載で詳細に説明されるように、メッセージトラフィックのガイド、メッセージトラフィックのモニタリング、メッセージトラフィックの特定部分に対する帯域幅の保証、及びメッセージトラフィックの優先順位付けを含む各種関連する処理を含むと理解されるべきである。

他の実施例は、オープンシステムインターコネクションモデルに基づくコンピュータネットワークシステムである。コンピュータネットワークシステムは、当該コンピュータネットワークシステムとの電子メッセージトラフィックの入力フローと出力フローをサポートするよう構成される。コンピュータネットワークシステムは、ネットワークレイヤ（レイヤ３）とアプリケーションレイヤ（レイヤ７）と共に、電子メッセージトラフィックの入力フローと出力フローの少なくとも１つを向上させるのに利用される当該レイヤ間の直接的な情報の交換を行うためのレイヤ３とレイヤ７との間の通信チャネルを含む。再び、“向上”という用語は、以下に限定されるものではないが、以下の記載で詳細に説明されるように、メッセージトラフィックのガイド、メッセージトラフィックのモニタリング、メッセージトラフィックの特定部分に対する帯域幅の保証、及びメッセージトラフィックの優先順位付けを含む各種アクションを含む。

さらなる他の実施例は、オープンシステムインターコネクトモデルに基づくコンピュータネットワークシステムに使用するためのコンフィギュレーションであり、当該オープンシステムインターコネクトモデルは、ネットワークレイヤ（レイヤ３）とアプリケーションレイヤ（レイヤ７）を有し、コンピュータネットワークシステムとの電子メッセージトラフィックの入力フロート出力フローをサポートするよう構成される。当該コンフィギュレーションは、電子メッセージトラフィックの入力フローと出力フローの少なくとも１つを向上させるのに利用されるレイヤ間の直接的な情報交換のためのレイヤ３とレイヤ７の間の通信チャネルを有する。

［開示の詳細な説明］
以下の説明は、当業者が開示を作成及び利用することを可能にするため提供され、特許出願及びそれの要件に関して提供される。記載された実施例に対する各種改良は、当業者に容易に明らかとなり、ここでの一般的な原理が他の実施例にも適用されてもよい。従って、本開示は、示された実施例に限定されることを意図せず、ここに記載された原理及び特徴に一致した最も広範な範囲が与えられるべきである。

電子メッセージトラフィックの処理では、多数の同様のルーティング及びセキュリティ機能がＯＳＩモデルのレイヤ３とレイヤ７の両方において実行されるという出願人の認識が与えられると、ここでは１つのレイヤにおいて実行されるコマンドが他方のレイヤに送信され、結合したモニタリング、報告及びアクションのためトラフィックフロー及び他の情報がレイヤ間で中継されることを可能にする上記２つのレイヤ間の通信チャネルを生成するという効果があることがさらに認識される。

レイヤ７の電子メッセージングアプリケーションからレイヤ３のネットワーク装置へのコマンド及びデータの送信を可能にし、レイヤ３のネットワーク装置がレイヤ７の電子メッセージングアプリケーションにコマンド及びデータを送信することを可能にする通信チャネルを生成することは、電子メッセージング技術において大きな効果を表すものである。このようなプロセスが、図１に関連して図２及び３において示される。図２は、図１に示されるものと同一の７つのレベルを含む改良されたコンピュータネットワークシステム１００を示す。しかしながら、レイヤ７からレイヤ３への通信チャネル１０２（矢印により示される）は、レイヤ７からレイヤ３への情報の直接的な送信を可能にする。同様に、図３において、改良されたコンピュータネットワークシステム１００’は、レイヤ３からレイヤ７への情報の直接的な送信を可能にするため、レイヤ３からレイヤ７への通信チャネル１０２’（他の矢印により示される）を含む。

電子メッセージトラフィックのルーティング及びセキュリティに対する上記統合されたアプローチは、電子メールサービスがネットワークサービスと統合される新たなタイプのシステム、すなわち、“ネットワーク上の電子メールサービス”を生成する。レイヤ３ネットワークパケットルーティングと、レイヤ７電子メッセージプロトコル（ＳＭＴＰなど）トラフィックを処理する際のメッセージトランスポートエージェント（ＭＴＡ）の長所とを組み合わせることによって、メッセージトランスポート及びメッセージネットワークアーキテクチャについて新たなパラダイムが確立される。

図４Ｂにおいて、コンピュータネットワークシステムの改良されたコンフィギュレーションが示される。図４Ａに関連して図４Ｂを参照するに、改良されたコンピュータネットワークシステム１５０は、ネットワーク装置１５４を介しインターネット５６に接続されるＭＴＡ１５２を有する。図４Ａのコンピュータネットワークシステム５０と同様に、ＭＴＡ１５２とネットワーク装置１５４はＳＭＴＰリンク５８により接続され、ネットワーク装置１５４は他のＳＭＴＰリンク６０によりインターネット５６と接続される。しかしながら、コンピュータネットワークシステム１５０では、さらなる通信チャネル１６０がネットワーク装置１５４と接続されるコマンドインタフェース１６２又はＡＰＩとＭＴＡ１５２との間に確立される。すなわち、ＭＴＡ１５２はネットワーク通信インタフェースなどの通信チャネル１６０を介しネットワーク装置に接続され、ネットワーク装置は、ＭＴＡ１５２とネットワーク装置１５４との間でコマンド及び情報を通信するのに使用される。さらに、例えば、ＭＴＡ１５２はＭＴＡ管理ツールを含むコントロールインタフェース１７０を有してもよい。改良されたコンピュータネットワークシステム１５０では、コントロールインタフェース１７０は第２インタラクティブ接続１７４（破線の双方向の矢印により示される）と共に、ＨＴＴＰ接続１７２（双方向の矢印により示される）によりＭＴＡ１５２と接続される。改良されたコンピュータネットワークシステム１５０では、ＨＴＴＰ接続１７２が、ＭＴＡ１５２とコントロールインタフェース１７０との間の情報の標準的なやりとりを行い、第２インタラクティブ接続１７４が、新たなコンフィギュレーション情報を通信チャネル１６０を介しコントロールインタフェース１７０からネットワーク装置１５４に送信するのに利用される。

コマンドの送信及びコンフィギュレーション命令の発行時、スタティックとダイナミックの２つのタイプのコンフィギュレーションが存在する。スタティックコンフィギュレーションは、ＭＴＡ管理コンソールに入力される情報がネットワーク装置に転送されるときに（ネットワーク装置のＡＰＩ又はコマンドインタフェースを介し）実現される。図５において、スタティックコンフィギュレーションの一例が示される。図５のコンピュータネットワークシステム１５０’は、図４Ｂのコンピュータネットワークシステム１５０と同一の基本コンポーネントを有しているが、コントロールインタフェース１７０’からの情報が、ＭＴＡ１５２とのインタラクティブ接続１７４’を介し（コントロールインタフェースからコマンド又は命令セットなどの情報を受け取るまでスタティックを継続する）、そしてインタフェース１６２’を介し通信チャネル１６０’を通じてネットワーク装置１５４’上に（コントロールインタフェースから情報を受け取るまでスタティックを継続する）送信される。すなわち、ＭＴＡ１５２’又はネットワーク装置１５４’の変更はコントロールインタフェース１７０’における情報の入力を要求する。このプロセスは、アクティブなユーザ入力によりレイヤ３に影響を与えるため、レイヤ７からの情報転送の一例である。“発行する”という用語は、以下に限定されるものではないが、コンフィギュレーション及びコマンドなどの与えられた情報の送信として本開示では理解される。

ＭＴＡがネットワーク装置に対するコンフィギュレーション変更を、コントロールインタフェースにおけるユーザのやりとり又は入力なしに行うとき、ダイナミックコンフィギュレーションが行われる。図６において、このようなシステムが示される。再び、図６のコンピュータネットワークシステム１５０’’は、コンピュータネットワークシステム１５０と同一の基本コンポーネントを有しているが、ＭＴＡ１５２’’はインタフェース１６２’’を介し通信チャネル１６０’’を通じた及びネットワーク装置１５４’’への情報の転送をダイナミックに開始する。この場合、ＭＴＡ１５２’’又はネットワーク装置１５４’’の変更は、ＭＴＡ１５２’’自体により開始されるダイナミックプロセスでなく、コントロールインタフェース１７０’’における情報の入力を要求しない。図６に示されるプロセスは、外部入力なしにレイヤ７において開始される情報転送によりレイヤ３に影響を与えるためのレイヤ７からの情報転送の一例である。

ネットワーク装置への発信に加えて、ＭＴＡ（又はＭＴＡ管理コンソール）はまた、ネットワーク装置からのデータをキャプチャするかもしれない。すなわち、情報転送はレベル３において開始され、レベル７に送信されてもよい。再び、これは、ＭＴＡ及びネットワーク装置がユーザ入力を受け取るまでスタティックであるときスタティックアクションとして、又はユーザとのやりとりなくダイナミックに実現可能である。図７及び８において、これらの具体例の両方がそれぞれ示されている。図７は、図４Ｂのコンピュータネットワークシステム１５０と同一の基本コンポーネントを有するコンピュータネットワークシステム２５０を示すが、ＭＴＡ２５０は、ネットワーク装置２６４のインタフェース２６２におけるアクティブなユーザ入力（図示せず）に関する情報を通信チャネル２６０を介し受信するまで、スタティックを継続する。このような受信情報の記録は、例えば、ＨＴＴＰ接続２７２や他のインタラクティブ接続２７４を介し受信するようなコントロールインタフェース２７０において保持されてもよい。あるいは、ダイナミックネットワーク装置２６４からの情報が、コンピュータネットワークシステム２５０における他のコンフィギュレーションを変更する際にユーザがコントロールインタフェース２７０をモニタリングすることによって考慮されてもよい。他方、図８に示されるコンピュータネットワークシステム２５０’では、ネットワーク装置２６４’は、ユーザとのやりとりなくインタフェース２６２’から通信チャネル２６０’を介しＭＴＡ２５２’への情報の転送を開始する。ユーザとのやりとりはこのケースでは必要でないため、コントロールインタフェース２７０’は、外部のユーザがＨＴＴＰ接続２７２’を介しネットワーク装置のダイナミックアクションを依然としてモニタするが、インタラクティブ接続を介しこのようなアクションの通知を受信しないかもしれない。図７及び８に示されるこれらの例は、レイヤ７におけるＭＴＡがレイヤ３におけるネットワーク装置に関する情報をスタティック又はダイナミックに収集可能な例である。ネットワーク装置から取得されるデータは、ＭＴＡとネットワーク装置の両方を制御するため、統合された管理コンソールを生成するのに利用可能である。

アプリケーション
コマンドを送信し、レイヤ３とレイヤ７との間でデータを共有することが可能であることは、メールネットワーク上での電子メッセージトラフィックのための具体的なルーティング及びセキュリティをより迅速に実行するための機会を作り出し、これにより、コンピュータネットワークシステムとの電子メッセージトラフィックの入力及び／又は出力フローを向上する。レイヤ３とレイヤ７との間の上記情報交換を利用する具体例が、以下で詳細に説明される。

プライオリティ
電子メッセージトランスポートの現在技術における重要な問題は、電子メールシステムとの間で入出力される電子メールトラフィックを優先順位付けし、これにより、サーバ及びネットワーク装置間のメッセージ及びメッセージトラフィックを優先順位付けする能力である。本開示のコンフィギュレーションは、最も高い優先度のメールがより低い優先度のメールの前にキューから放出されることによって、電子メールが配信のため優先順位付けされることを可能にする真のプライオリティキュー処理に対する一意的なアプローチを利用する。この強力な特徴は、ＳＭＴＰメールプライオリティ割当てがデータパケットレベルにおける真のＩＰプレセダンス（ＩＰ ｐｒｅｃｅｄｅｎｃｅ）のためネットワーク装置に送信可能であるとき、より強力なものとなる。ＭＴＡを介したプライオリティルーティングがパケットプライオリティと組み合わされるとき、真の電子メールプライオリティがネットワークパス中に確立され、メッセージトラフィックがＭＴＡにおいて優先順位付けされるとき、同一の割当てに従ってパケットトラフィックがネットワーク装置間で優先順位付けされることを保証する。

このような電子メールトラフィック優先順位付けは、例えば、以下の手順によって確立されるかもしれない。
１．電子メールトラフィックを優先順位付けするため、ＭＴＡにおいてプライオリティコンフィギュレーションを設定する。
２．ＭＴＡからネットワーク装置に設定を発行する。
３．メールトラフィックが、レイヤ７とレイヤ３の双方において適用されるプライオリティによりネットワーク装置を介しＭＴＡから伝送される（ＩＰプレセダンスとして知られる）。

図９において、電子メールトラフィック優先順位付けの第２ステップの詳細が示される。図９は、ＭＴＡ（レイヤ７）からネットワーク装置（レイヤ３）への情報のフロー３００の一例を示す。コンピュータネットワークのＭＴＡにおいて、ユーザはステップ３０２においてコントロールインタフェース（図５のＭＴＡ１５２’などにおける）コントロールインタフェースを介しＭＴＡにおける設定を更新してもよく、又はＭＴＡは、それのコンフィギュレーションをダイナミックに調整してもよい（図６のＭＴＡ１５２’’などにおける）。何れのケースでも、更新されたＭＴＡコンフィギュレーション（又は“ルール”）は、ステップ３０６においてネットワーク装置との直接的な通信チャネルを介し発行される。その後ステップ３０８において、コンピュータネットワークの更新された設定が完了される。

図１０において、メッセージトラフィック優先順位付けプロセスの全体が示される。プロセス３１０は、ステップ３１２において電子メールトラフィック優先順位付け（すなわち、“キュープライオリティ”）を指定するメッセージをネットワーク装置１５４に送信するＭＴＡ１５２において開始される。ネットワーク装置１５４において、判定３１４は、与えられたメッセージに対してプライオリティパスが要求されるかクエリする。判定３１４の回答が“ＮＯ”である場合、ステップ３１６において、当該メッセージは通常のＳＭＴＰ通信によって送信される。判定３１４の回答が“ＹＥＳ”である場合、メッセージは、要求されるプライオリティレベルを指定するため、次の判定３２０にわたされる（すなわち、ＩＰプレセダンスの設定）。判定３２０の回答が“ＮＯＲＭＡＬ”である場合、ＩＰプレセダンスは設定されず、判定３１４においてプライオリティパスが与えられなかったメッセージに先行して、メッセージが通常のＳＭＴＰにより配信される。判定３２０の回答が“ＵＲＧＥＮＴ”である場合、メッセージは高いレベルのＩＰプレセダンス（“ＩＰプレセダンスＸ”など）を受け取り、大変高いプライオリティにより配信される。判定３２０の回答が“ＨＩＧＨ”である場合、又は“ＮＯＲＭＡＬ”と“ＵＲＧＥＮＴ”の間のレベルである場合、メッセージはノーマルとハイとの間のＩＰプレセダンスレベルを受け取り（ＩＰプレセダンスＹなど）、中程度のプライオリティにより配信される。ＭＴＡ（レイヤ７）から受信する情報に従って、ネットワーク装置におけるこのような電子メールトラフィックの優先順位付けは、従来技術に対して効果的であると考えられる。

ＱｏＳ
ＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）は、特定のアプリケーション若しくはネットワークパスのネットワーク帯域幅やネットワーク装置の共通の機能を限定又は保証する能力である。ここでは、ネットワークパスは、１つのコンピュータ又はシステムから他のコンピュータ又はシステムへのネットワークトラフィックルートとして理解される。

メールネットワーク又はシステムでは、サーバ若しくはネットワークを介し若しくはから伝送される電子メッセージトラフィックを制限可能な機能について効果的である（すなわち、帯域幅制約を課す）。このため、現在技術では、いくつかのＭＴＡが時間インターバル毎に送信されるメッセージ若しくは同時接続の個数を制限する方法を提供する。このタイプの制限は有用であるが、それは、ネットワークトラフィック量を制御し、ネットワークアクセスポイントを介した予測可能なトラフィックフローを保証する手段としては不完全なものである。

ここで教示されるような従来技術に対する進歩は、メッセージトラフィックのためＭＴＡに利用可能な帯域幅を制御するため該当するネットワーク装置上で直接的に動作するＭＴＡ内部からの真の帯域幅制約を設定する能力である。この帯域幅制御は、維持されるフロー及び最適化されたスループットを保証するため、ネットワークの要求及び要件に従って入力メッセージトラフィック又は出力メッセージトラフィックに適用可能である。

例えば、このような帯域幅制約は、以下の方法により機能するかもしれない。
１．メッセージトラフィック（又はメッセージトラフィックの一部）のためＭＴＡにおける最大帯域幅利用コンフィギュレーションを設定する。
２．ＭＴＡからネットワーク装置に設定を発行する（例えば、図９に示されるように）。
３．メールトラフィックが、適用された帯域幅利用の制限によりネットワーク装置からＭＴＡに伝送される。
４．メールトラフィックが、帯域幅利用に対する制約が装置及びネットワークからのメッセージトラフィックに適用される場合にＭＴＡからネットワーク装置に伝送される。

上述したプロセスフローにおいて、ステップ３は入力帯域幅制約に関し、ステップ４は出力帯域幅制約に関する。図１１において、ネットワーク装置１５４を介しインターネット５６からＭＴＡ１５２に受信されたメッセージのための帯域幅を制限する入力帯域幅制限プロセス４００が示される。上述したステップ２においてＭＴＡから受信される発行された設定に従って、ネットワーク装置１５４は、帯域幅利用を制限するか判定４０２を行う。判定４０２の回答が“ＮＯ”である場合（例えば、ＭＴＡ１５２が入力メッセージを受信する準備ができているなど）、インターネット５６から受信したメッセージはノーマルＳＭＴＰ配信によってＭＴＡ１５２に導かれる。判定４０２の回答が“ＹＥＳ”である場合（例えば、ＭＴＡ１５２が利用不可であるか若しくはあるタイプのエラーを有するか、又はＭＴＡ１５２が特定ソースからのメッセージを拒絶するよう設定されているなど）、ＭＴＡ１５２への入力配信のため利用可能な帯域幅は、入力メッセージの一部のみ又は何れも当該時点においてＭＴＡ１５２に改心されないように、ネットワーク装置１５４において制限される。

図１２において、出力帯域幅制約のための同様のプロセスが示される。出力帯域幅制限プロセス４５０では、ステップ４５２において、ＭＴＡ１５２がＳＭＴＰメッセージをネットワーク装置１５４に送信することにより開始される。上述したステップ２におけるＭＴＡ１５２から受信した発行された設定に従って、ネットワーク装置１５４は、出力メッセージについて帯域幅利用を制限するか否かの判定４５４が行われる。判定４５４の回答が“ＹＥＳ”である場合、ネットワーク装置１５４は、ＳＭＴＰメッセージ配信ステップ４５８におけるインターネット５６への出力メッセージの送信処理前に、ステップ４５６において出力メッセージのための利用可能な帯域幅を制限する。あるいは、判定４５４の回答が“ＮＯ”である場合、ネットワーク装置は、帯域幅制限なく出力メッセージを配信ステップに送信する。帯域幅制限は、トラフィック量が大きいとき、メッセージ配信トラフィックが同じインターネット接続上の他のトラフィックを号外することを回避するのに利用される。例えば、ＳＭＴＰトラフィックが大きい期間に、メッセージトラフィックはウェブサイトに利用される帯域幅を占有する可能性があり、これにより、当該ウェブサイトへの外部のアクセスを妨害又は抑制する。図１２に示されるような出力帯域幅制限は、メッセージトラフィックが一定量の利用可能な帯域幅を占有するだけであることを保証し、これにより、ウェブサイト、ＩＰ電話又はデータ転送などの他のインターネットプログラムへの残りの帯域幅の割当てを可能にする。同様に、入力帯域幅制限は、他のプログラムに帯域幅を留保するのに使用され、入力帯域幅及び他のリソースを使用することによってネットワークを妨害するよう設計されたＳＭＴＰＤＯＳ（Ｄｅｎｉａｌ Ｏｆ Ｓｅｒｖｉｃｅ）攻撃などの入力ＳＭＴＰベースボリュームネットワーク攻撃に対する予防的手段として特に有用である。

帯域幅制限の直接的に対立するものは、特定のネットワークパスについて保証された帯域幅割当てを提供することである。この保証された帯域幅割当ては、１つのコンピュータ又はシステムから第２のコンピュータ又はシステムに割当て可能である。この構成は、信頼される又は既知のルートが常にメッセージを配信するのに要求される帯域幅を受けることを可能にする。この保証のソースは、システムＩＰアドレス又はソース電子メールアドレスからのものであってもよい。従って、インターネットから到着するメッセージは、すべての入力接続について帯域幅の一部が保証可能であり、及び／又は特定量の帯域幅が出力メッセージついて保証可能である。

このような帯域幅保証プロセスは、例えば、以下のステップを有するかもしれない。
１．メッセージトラフィック（又はメッセージトラフィックの一部）のためＭＴＡにおける最小の帯域幅利用コンフィギュレーションを設定する。
２．ＭＴＡからネットワーク装置に設定を発行する（図９に示されるものなど）。
３．メールトラフィックは、適用された最小の帯域幅割当てによりネットワーク装置からＭＴＡに伝送される。
４．メールトラフィックは、最小の帯域幅割当てがネットワーク及び装置からのメッセージトラフィックに適用される場合、ＭＴＡからネットワーク装置に伝送される。

図１２及び１４において、入出力メッセージの帯域幅保証プロセスが示される。図１３において、ネットワーク装置１５４及びＭＴＡ１５２にインターネット５６から受信されるメッセージの帯域幅を制限する入力帯域幅保証プロセス４１０が示される。上述したステップ２におけるＭＴＡから受信した発行された設定に従って、ネットワーク装置１５４は、受信したメッセージの配信の帯域幅利用を保証するか否かの判定４１２を行う。判定４１２の回答が“ＮＯ”である場合（例えば、ＭＴＡ１５２が、所与の入力メッセージのソースの具体的な帯域幅保証を有しないなど）、インターネット５６から受信したメッセージは、通常の帯域幅制約によりＭＴＡ１５２に送信される。判定４１２の回答が“ＹＥＳ”である場合（例えば、ＭＴＡ１５２が、特定ソースからのメッセージについて要求されている帯域幅保証を有している）、ＭＴＡ１５２への入力配信について利用可能な帯域幅は、ＭＴＡ１５２に対する入力メッセージについてネットワーク装置１５４において保証される。

同様に、出力帯域幅保証プロセス４７０は、ＭＴＡ１５２がステップ４７２においてネットワーク装置１５４にＳＭＴＰメッセージを送信することにより開始される。上述したステップ２におけるＭＴＡ１５４から受信した発行された設定に従って、ネットワーク装置１５４は、出力メッセージの帯域幅利用を保証すべきか否かの判定４７４を行う。判定４７４の回答が“ＹＥＳ”である場合、ネットワーク装置１５４は、ＳＭＴＰメッセージ配信ステップ４７８におけるインターネット５６への出力メッセージのすべてを送信する処理前に、ステップ４７６において出力メッセージの利用可能な帯域幅を保証する。あるいは、判定４７４の回答が“ＮＯ”である場合、ネットワーク装置は、帯域幅保証なしに配信ステップに出力メッセージを送信する。

ロードバランシング／フェイルオーバー
典型的な大規模ネットワークでは、トラフィックの一時的なスパイク又は何れか１つのサーバ若しくは接続の故障が発生すると、トラフィックを処理し、トラフィックの連続的なフローを保証するため複数の電子メッセージサーバが存在する。

従来技術では、これらのサーバに対するトラフィックフローは、レイヤ３パケットデータ上で動作するネットワーク装置を用いて管理されている。これらのネットワーク装置は、サーバ間にトラフィックを分散し“ロードバランシング”、故障が発生すると、故障したサーバへのトラフィックを切断し、機能しているルートにトラフィックをルーティング及び送信する。（“フェイルオーバー”）これらのトラフィックフローに適用されるコマンドのコンフィギュレーションは、ネットワーク装置によって提供され、電子メッセージトラフィックに関する何れの直接的な情報にも関連しない管理コンソール（通常はコマンドライン）を利用して実行される。

従来技術に対する進歩は、ＭＴＡクラスタの管理コンソール内のロードバランシング及びフェイルオーバー設定の選択及び適用を統合することによって実現される。このシステムでは、システムを担当する管理者は、ＭＴＡの管理環境内で作業しながら、ロウバストでスケーラブルな電子メールネットワークを容易に構成することが可能である。それはまた、ＭＴＡのシステム利用設定とメッセージトラフィックフローの両方にロードバランシング及びフェイルオーバー命令を関連付ける能力を提供する。これは、システム利用閾値がＭＴＡにおいて到達しているときネットワーク装置により変更可能であることを意味するため、実際の故障前に対する措置として特に重要である。

このようなロードバランシング／フェイルオーバープロセスは、以下のように機能するかもしれない。

１．ＭＴＡのクラスタ管理インタフェース内に複数のＭＴＡサーバをインストール／セットアップする。
２．クラスタのＭＴＡ選好内のロードバランシング及びフェイルオーバー設定を設定する。
３．すべてのＭＴＡサーバ及びネットワーク装置に当該設定を発行する（図１６）。
４．メールサーバ間でロードバランシングが実行される。メールトラフィックがインターネットから受付され、ネットワーク装置は各メッセージ又はセッションをネットワーク装置に接続される次のＭＴＡに送信する。これは、それがリストのエンドに到達すると最初から開始されるエンドレスループにおいて発生する。
当該プロセスはまた、何れのＭＴＡが新たなＳＭＴＰセッションについて利用可能であるか決定する“Ｌｅａｓｔ Ｕｓｅｄ ”アルゴリズムを使用することによって実現可能である。これらは、ネットワーク装置からＭＴＡ系列へのメッセージ配信及びフローについて利用可能なアルゴリズムの典型例である。
５．フェイルオーバーが、メールサーバ間で実行される。図１７に示されるシナリオでは、ＭＴＡはネットワーク装置とのそれの接続を失っている。ネットワーク装置は、それがもはやＳＭＴＰセッションを当該ＭＴＡに送信することができないと判断し、それは第１のＭＴＡのみにセッションを送信する。

図１５において、ラウンドロビンロード分散プロセスの一例が示される。図１５のプロセス５００では、レイヤ７はネットワーク装置１５４に接続された２つのＭＴＡ（それぞれ参照番号５０２と５０４により示されるＭＴＡ１及びＭＴＡ２）を有する。ＭＴＡ１及びＭＴＡ２のそれぞれは、ステップ５０６においてそれらのロードバランスコンフィギュレーションをネットワーク装置１５４に発行する。ＭＴＡ１２及びＭＴＡ２から受信した発行されたロードバランスコンフィギュレーションに従って、ネットワーク装置は、インターネット５６から受信した入力メッセージを配信する。ラウンドロビンロード分散プロセスは、上述したロードバランシング／フェイルオーバープロセスにおけるステップ４に対応する。

図１６において、ロードバランスコンフィギュレーションの発行ステップがより詳細に説明される。発行プロセス５１０は、例えば、ステップ５１２においてネットワーク装置と接続するＭＴＡ５０２などにおいて開始される。コマンド系列が与えられると、各コマンドについて、ステップ５１４は、ネットワーク装置にコマンドを入力するプロセス５１６を開始する。コマンド入力が完了すると、ステップ５１８は他のコマンドをチェックする。さらなるコマンドがある場合、当該プロセスはステップ５１４に戻る。すべてのコマンドがネットワーク装置に送信された場合、ステップ５２０において、ＭＴＡからネットワーク装置への接続がクローズされる。このように、レイヤ７のＭＴＡは、直接的な通信によってレイヤ３のネットワーク装置にそれのロード状態に関する情報を通信する。

図１７において、フェイルオーバー分散プロセスの一例が示される。図１７のプロセス５３０において、レイヤ７は再びネットワーク装置１５４に接続される２つのＭＴＡを有する。ＭＴＡ１とＭＴＡ２のそれぞれは、ステップ５３２においてネットワーク装置１５４にそれらのフェイルオーバーコンフィギュレーションを発行する。この発行ステップ５３２は、例えば、図１６に示されるような発行プロセスなどに従うものであってもよい。このように、ネットワーク装置は、存在する場合には、ＭＴＡの何れが利用不可である（故障している）か認識する。その後、ＭＴＡから受信した当該上方に従って、ネットワーク装置は、インターネット５６からの入力メッセージの配信のため、ステップ５３４において利用可能なサーバを選択する。このフェイルオーバープロセスは、上述したロードバランシング／フェイルオーバープロセスにおけるステップ５に対応する。

ＶＰＮ／セキュア配信
従来技術では、ＭＴＡが１つのサーバから他のサーバにセキュア配信を行うことが要求される場合、それらは共に、トランスポートレイヤセキュリティなどの確立されたセキュアなＳＭＴＰトランスポートプロトコルを利用するよう構成される必要がある。これは未知のドメインへの一般的な配信に適しているが、処理に関しては面倒であり、レイヤ３で実行されるセキュアデータトランスポートの効率性を欠いたものとなる。

従来技術に対する進歩は、ポイントＡからポイントＢへの真のＩＰ配信トンネルを形成するため、ネットワークＶＰＮ（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）サービスを利用する能力である。この改良は、ＶＰＮが他のタイプのネットワークトラフィックを処理するためすでに存在している場合、同一のオペレータ（すなわち、企業）のネットワークサイト間の電子メッセージングに特に効果的であるとわかる。このような手段は、ＭＴＡがネットワークパスをＶＰＮ可能であると認識することを要求する。当該検出が行われると、ＭＴＡはＶＰＮ接続を開始し、電子メールのＳＭＴＰ配信を実行し、切断する。あるいは、ＭＴＡは、ＶＰＮ可能なルートに予め接続し、当該エンドポイントに送信されるメールトラフィックのルートを介してのみ配信する。受信するＭＴＡはまた、セキュアな電子メールを受信するため、入力ＶＰＮ接続を受け付けるよう構成されてもよい。

このようなセキュアな配信プロセスは、以下の１つとして行われてもよい。
１．ダイナミックＶＰＮ接続が、ＭＴＡが受信機をＶＰＮ可能であると判断すると確立される。
２．あるいは、メールトラフィックはスタティックＶＰＮルートに対して認証可能である。その後、ＭＴＡはメッセージルーティングのためこのスタティックＶＰＮ接続を利用することを選択する。

図１８及び１９において、上述されるプロセス１及び２がそれぞれ示される。図１８のダイナミックなセキュア配信プロセス６００は、ステップ６０２において、ソースＭＴＡが受信ＭＴＡに接続することにより開始される。判定６０４は、ＶＰＮが受信するＭＴＡにおいて可能であるか判断する。判定６０４の回答が“ＮＯ”である場合、ステップ６０６において、通常のＳＭＴＰ配信を利用してメッセージが送信される。判定６０４の回答が“ＹＥＳ”である場合、ソースＭＴＡはステップ６０８においてＶＰＮセッションを開始する。ステップ６１０において、メッセージがＶＰＮを介しセキュア送信されると、ＶＰＮセッションはステップ６１２においてクローズされる。

図１９において、他のスタティックな配信プロセス６２０が示される。スタティックなセキュア配信プロセス６２０では、ソースＭＴＡはステップ６２２において配信ドメインをチェックし、判定６２４において、与えられたメールトラフィックルートがスタティックＶＰＮルートであるか判断する。判定６２４の回答が“ＹＥＳ”である場合、ソースＭＴＡはステップ６２２において配信ドメインは、ステップ６２８において既存のＶＰＮセッションを介し受信するＭＴＡとの接続を確立し、その後ステップ６３０においてそれを介しメッセージを送信する。

ネットワークアノマリ検出
ＭＴＡをネットワーク侵入検出又はアノマリ検出システムにリンクさせる明快かつ重要な効果がある。認証されていないユーザがリモートＰＣ及びサーバから不正に電子メールを送信することを可能にする技術の出現によって（ゾンビホスト）、再配信のためのＭＴＡに出力ポート２５（ＳＭＴＰ）トラフィックをルーティングし、ネットワークオペレータが規定された電子メールトラフィックポリシーを強制し、アノマリを特定することを可能にし、これにより、ゾンビトラフィックを最小化若しくは解消するための新たな要求がある。

同様に、ＭＴＡは、ネットワーク装置においてトラフィックをスロットル又は中断することが可能な侵入検出システム（ＩＤＳ）に情報をわたすことによって当該トラフィックを抑制又はブロックするため、１つのローカルコンピュータが異常に大量の電子メールを送信するなど、ＭＴＡは通常でない動作について入力電子メールトラフィックをモニタすることが可能である。

ゾンビメールホストからの出力メッセージトラフィックアノマリを決定するプロセスが以下に与えられる。ゾンビメールホストは、妥協したかもしれないローカルネットワーク内のサーバであると理解され、そうでない場合にはＳＭＴＰトラフィックを送信することが許可されない。

このようなメッセージトラフィックアノマリ検出は、以下のように実行されるかもしれない。
１．ゾンビホストは、ポート２５を介しネットワーク装置にネットワークトラフィックを送信する。
２．当該トラフィックは、配信及び有効性の確認のため、ＭＴＡに再ルーティングされる。
３．それが有効でない又は許容されないトラフィックである場合、メッセージは破棄される。

図２０において、出力メッセージに対するこのゾンビメール検出プロセスが示される。プロセス７００は、プロセス７００は、ゾンビホスト７０２がポート２５の接続（矢印７０４により示されるような）を介しネットワーク装置１５４にネットワークトラフィックを送信するとき（すなわち、電子メールメッセージを送信するとき）、開始される。その後、ネットワーク装置１５４は、判定７０６において受信したネットワークトラフィックがポート２５を介し受信されたものであるか判断する。判定７０６の回答が“ＮＯ”である場合、ネットワークトラフィックは、インターネット５６にわたすことが許可される。判定７０６の回答が“ＹＥＳ”である場合、ネットワークトラフィックは、判定７０８におけるさらなる有効性確認のためＭＴＡ１５２に送信される。判定７０８の回答が“ＹＥＳ”である場合、ネットワークトラフィックはインターネット５６にわたすことが許可される。判定７０８の回答が“ＮＯ”である場合、受信したメッセージはステップ７１０においてネットワークシステムから削除される。

同様に、入力メッセージトラフィックアノマリを判断し、当該情報をアクションのため侵入検出装置に送信するプロセスが以下に与えられる。
１．ＳＭＴＰトラフィックが、ＭＴＡにおいてインターネットから到着する。
２．当該トラフィックが有効であるとみなされた場合、それは通常処理される。
３．トラフィックが通常のものでないか、又は疑わしい場合、それはさらなるモニタリング及び／又はアクションのためＩＤＳシステムにわたされる。

特に図２１を参照して、プロセス７５０は、ＭＴＡ１５２がインターネット５６から入力メッセージトラフィックを受信したとき開始される。ＭＴＡ１５２は、入力メッセージが有効なトラフィックであるか否かの判定７５２を行う。判定７５２の回答が“ＹＥＳ”である場合、入力メッセージは、メッセージに指定された受信者に通常配信される。判定７５２の回答が“ＮＯ”である場合、入力メッセージは侵入検出装置７５６に送信される。

リアルタイムＩＰセッションデータモニタ
ネットワーク装置は、ＭＴＡにコマンド及びデータを送信するかもしれない。スイッチ又はルータなどのネットワーク装置は、それのシステムを介しリアルタイムなパケットフローをトラックすることが可能である。この情報は、ダイナミックかつユーザとのやりとりなく、特定のネットワークパスのスループット特性を変更するのに利用可能である。例えば、主要な入力ソースと考えられるＩＰアドレスは、発行されたブラックリスト（ＲＢＬ）又はリバースドメインネームサービス（ＲＤＮＳ）ルックアップに対してチェック可能である。当該ＩＰアドレスが疑わしいとみなされる場合、それは自動的により小さなパーセンテージの帯域幅利用に限定可能であり、これにより、当該ソースからローカルネットワークへのメッセージへのより限定されたアクセスが実現される。

このようなモニタリングプロセスは、以下のように機能するかもしれない。
１．ＭＴＡのモニタリングコンソールは、ＩＰセッションデータを収集する。
２．このアプリケーションは、セッションデータを受け付け、その後に処理チェーンを介しそれを実行する。
３．当該処理の結果が、ダイナミックメールフロールールを生成するため、ＭＴＡ及びネットワーク装置に報告される。

図２２において、上記モニタリングプロセスのステップ１が示される。モニタリングプロセス８００は、さらにインターネット５６に接続されるネットワーク装置１５４とＭＴＡ１５２の相互接続に関する。ＭＴＡ１５２は、さらなるモニタリングコンソール８０２を有する。モニタリングコンソール８０２は、ネットワーク装置１５４からエクスポートセッション情報を受信し（矢印８０４により示されるような）、処理チェーン８０６を介し当該情報を処理する。ネットワーク装置から受信したＩＰセッションデータに変更がある場合、モニタリングコンソール８０２は、その後にネットワーク装置１５４とＭＴＡ１５２の一方又は両方に当該変更をわたす。

図２３において、一例となる処理チェーン８０６の詳細が示される。処理チェーン８０６は、ネットワーク装置１５４からＩＰセッションデータ８０４を取得し、各ソースＩＰについてステップ８１２を開始する。各ソースＩＰについて、ステップ８１２の後に、リバースドメインネームサーバ（ＤＮＳ）チェックのためのステップ８１４と、リアルタイムブロックリスト（ＲＢＬ）チェックのためのステップ８１６と、認証チェックのためのステップ８１８と、所望される場合にはさらなるチェックのためのステップ８２０とが続く。これらチェックステップに続いて、ステップ８２２はとられるべき利用可能なアクションを設定し、その後に次のソースＩＰについて次のステップ８２４に移行する。この処理は、ネットワーク装置がＭＴＡに何れのトラフィックがネットワーク上で送信されているか通知することを可能にし、これにより、ＭＴＡがトラフィックフローに対する処理判定をすることを可能にする。とられる可能性のあるさらなるアクションは、さらなるスキャンが実行可能となるように、帯域幅の破棄完了を含む帯域幅制限若しくは保証、メッセージのプライオリティの設定又はメールフローの変更を含む。

結論
上記実施例のそれぞれが各自の向きを有する各種コンポーネントにより示されたが、他の実施例が広範なポジション及び相互の向きにより配置された各種コンポーネントを有し、依然として本開示の趣旨及び範囲内に属する各種具体的コンフィギュレーションにより構成可能である。さらに、適切な均等物が各種コンポーネントの代わりに又はさらに加えて利用可能であり、このような代替的又は追加的コンポーネントの機能及び利用は、当業者に周知であるとされ、本開示の範囲内に属するものとみなされる。例えば、上記各実施例は主として電子メールメッセージングのケースを利用して説明されたが、本開示の電子メッセージ配信システムは、例えば、携帯電話及び他の携帯装置との間のメッセージ、インターネットプロトコルベース音声トラフィック（ＶＯＩＰ（Ｖｏｉｃｅ Ｏｖｅｒ ＩＰ））又はセッションイニシエーションプロトコル（ＳＩＰ）メッセージなどの他のタイプの電子メッセージに適応するよう容易に設定可能である。

要約すると、本開示は、コンピュータネットワークシステムが少なくともネットワークレイヤ（レイヤ３）とアプリケーションレイヤ（レイヤ７）とを有するオープンシステム相互接続モデルに基づくコンピュータネットワークシステム、電子メッセージトラフィックのフローを向上させるのに利用されるそれらの間で直接データを交換するため、レイヤ３とレイヤ７との間の通信チャネルを規定することを含むコンピュータネットワークシステムに対する電子メッセージトラフィックを管理するシステム及び方法について説明された。

従って、与えられた実施例は、例示的なものであり、限定的なものとみなされるべきでなく、本開示は、ここに与えられた詳細に限定されず、添付した請求項の範囲内で改良されてもよい。

図１は、現在利用可能な従来技術によるオープンシステムインターコネクション接続モデルの主要コンポーネントを示すブロック図形式による概略図である。 図２は、本開示によるＯＳＩモデルによるレベル７と３との間の相互接続の新たなモデルを示す概略図である。 図３は、本開示によるＯＳＩモデルによりレベル３と７との間の他の相互接続モデルを示す概略図である。 図４Ａは、従来技術によるＭＴＡ及びネットワーク装置が通信しない電子メッセージのための標準的なネットワークコンフィギュレーションを示すフローチャートである。 図４Ｂは、本開示によるＭＴＡ及びネットワーク装置が通信する新たなコンフィギュレーションを示すフローチャートである。 図５は、ＭＴＡからネットワーク装置にコマンドを送信し、又はコンフィギュレーション命令を発行するスタティックコンフィギュレーションを示すフローチャートである。 図６は、ＭＴＡからネットワーク装置にコマンドを送信し、又はコンフィギュレーション命令を発行するダイナミックコンフィギュレーションを示すフローチャートである。 図７は、ＭＴＡにおいてネットワーク装置からのデータをキャプチャするスタティックコンフィギュレーションを示すフローチャートである。 図８は、ＭＴＡにおけるネットワーク装置からのデータをキャプチャするダイナミックコンフィギュレーションを示すフローチャートである。 図９は、ＭＴＡからネットワーク装置に設定を発行するプロセスを示すフローチャートである。 図１０は、本開示によるメールフローのプライオリティ設定のプロセスを示すハイブリッドフローチャートである。 図１１は、本開示による入力電子メッセージトラフィックのための帯域幅利用を制限するプロセスを示すフローチャートである。 図１２は、本開示による入力電子メッセージトラフィックのための帯域幅保証のプロセスを示すフローチャートである。 図１３は、本開示による出力電子メッセージトラフィックのための帯域幅利用を制限するプロセスを示すフローチャートである。 図１４は、本開示による出力電子メッセージトラフィックのための帯域幅保証のプロセスを示すフローチャートである。 図１５は、本開示によるラウンドロビンロード分散による通信ループを示すフローチャートである。 図１６は、本開示によるネットワーク装置にＭＴＡコンフィギュレーションを発行するプロセスを示すフローチャートである。 図１７は、本開示によるフェイルオーバー分散のプロセスを示すフローチャートである。 図１８は、本開示によるダイナミックＶＰＮ接続のプロセスを示すフローチャートである。 図１９は、本開示によるスタティックＶＰＮ接続のプロセスを示すフローチャートである。 図２０は、本開示による出力メッセージトラフィックアノマリを決定するプロセスを示すフローチャートである。 図２１は、本開示による入力メッセージトラフィックアノマリを決定するプロセスを示すフローチャートである。 図２２は、本開示によるＭＴＡによるＩＰセッションデータの収集プロセスを示すフローチャートである。 図２３は、本開示によるＭＴＡによるＩＰデータの収集における処理チェーンを示すフローチャートである。

Claims (20)

1. オープンシステムインターコネクションモデルに基づき、少なくともネットワークレイヤ（レイヤ３）とアプリケーションレイヤ（レイヤ７）とを有するコンピュータネットワークシステムにおいて、前記コンピュータネットワークシステムとの間の電子メッセージトラフィックの入力フローと出力フローとを管理する方法であって、
   レイヤ３とレイヤ７との間で情報を直接やりとりするステップと、
   前記情報に基づき、前記電子メッセージトラフィックの入力フローと出力フローの少なくとも１つを向上させるステップと、
   を有する方法。
2. レイヤ７は、複数のデータパケットを有する電子メッセージトラフィックを生成するためソフトウェアアプリケーションを処理するよう構成され、
   レイヤ３は、前記複数のデータパケットを処理するよう構成され、
   当該方法はさらに、
   レイヤ３において、レイヤ７において処理される前記ソフトウェアアプリケーションに関する情報をレイヤ７から受け付けるステップと、
   レイヤ３において、レイヤ７から受け付けた前記情報に従って、前記複数のデータパケットの処理を改良することによって向上させるステップと、
   を有する、請求項１記載の方法。
3. 前記レイヤ３における改良は、
   前記複数のデータパケットから選択されたデータパケットグループを特定するステップと、
   レイヤ７から受け付けた前記情報に従って、前記選択されたデータパケットグループについて保証された帯域幅を割り当てるステップと、
   を有する、請求項２記載の方法。
4. 前記レイヤ３における改良は、レイヤ７から受け付けた前記情報に従って、前記複数のデータパケットを優先順位付けするステップを有する、請求項２記載の方法。
5. 前記レイヤ３における改良は、レイヤ７から受け付けた前記情報に従って、前記複数のデータパケットの処理に利用可能な帯域幅に関する制限を設定するステップを有する、請求項３記載の方法。
6. レイヤ７は、複数のデータパケットを有する電子メッセージトラフィックの入力フローと出力フローとを生成するソフトウェアアプリケーションを処理するよう構成され、
   レイヤ３は、ネットワーク状態セットをモニタリングするよう構成され、
   当該方法はさらに、
   レイヤ７において、前記ネットワーク状態セットに関する情報をレイヤ３から受け付けるステップと、
   レイヤ７において、レイヤ３から受け付けた前記情報に従ってソフトウェアアプリケーションの処理を改良することによって向上させるステップと、
   を有する、請求項１記載の方法。
7. 前記レイヤ７における改良は、レイヤ３から受け付けた前記情報に従って、前記電子メッセージトラフィックの入力フローと出力フローの少なくとも１つにおける前記複数のデータパケットを優先順位付けするステップを有する、請求項６記載の方法。
8. 前記レイヤ７における改良は、レイヤ３から受け付けた前記情報に従って、レイヤ７において前記ソフトウェアアプリケーションに利用可能な帯域幅に関する制限を設定するステップを有する、請求項６記載の方法。
9. 前記帯域幅に関する制限を設定するステップは、レイヤ３から受け付けた前記情報に従って、前記入力フローと前記出力フローの少なくとも選択された１つの帯域幅をゼロに低減するステップを有する、請求項８記載の方法。
10. レイヤ３は、少なくとも第１及び第２ネットワーク装置を有し、
    前記レイヤ７における改良は、レイヤ３から受け付けた前記情報に従って、前記第１及び第２ネットワーク装置の選択された１つに前記複数のデータパケットを送信するステップを有する、請求項６記載の方法。
11. レイヤ７は、複数のデータパケットを有する電子メッセージトラフィックを生成するためソフトウェアアプリケーションを処理するよう構成され、
    レイヤ３は、ネットワーク状態セットをモニタしながら、前記複数のデータパケットを処理するよう構成され、
    当該方法はさらに、
    レイヤ３において、レイヤ７において処理される前記ソフトウェアアプリケーションに関する第１情報をレイヤ７から受け付けるステップと、
    レイヤ３において、レイヤ７から受け付けた前記第１情報に従って、前記複数のデータパケットの処理を改良するステップと、
    レイヤ７において、前記ネットワーク状態セットに関する第２情報をレイヤ３から受け付けるステップと、
    レイヤ７において、前記電子メッセージトラフィックの入力フローと出力フローの少なくとも１つを向上させるため、レイヤ３から受け付けた前記第２情報に従って、前記ソフトウェアアプリケーションの処理を改良するステップと、
    を有する、請求項１記載の方法。
12. オープンシステムインターコネクトモデルに基づき、当該コンピュータネットワークシステムとの間の電子メッセージトラフィックの入力フローと出力フローとをサポートするよう構成されるコンピュータネットワークシステムであって、
    ネットワークレイヤ（レイヤ３）と、
    アプリケーションレイヤ（レイヤ７）と、
    前記電子メッセージトラフィックの入力フローと出力フローの少なくとも選択された１つを向上させるのに利用するため、レイヤ３とレイヤ７との間で情報を直接やりとりするレイヤ３とレイヤ７との間の通信チャネルと、
    を有するコンピュータネットワークシステム。
13. レイヤ７は、複数のデータパケットを有する前記電子メッセージトラフィックを生成するためソフトウェアアプリケーションを有し、
    レイヤ３は、
    レイヤ７における前記ソフトウェアアプリケーションに関する情報をレイヤ７から前記通信チャネルを介し受け付ける受信構成と、
    前記フローの選択された１つを向上させるため、レイヤ７から受け付けた前記情報に従って、前記複数のデータパケットを処理する処理構成と、
    を有する、請求項１２記載のコンピュータネットワークシステム。
14. 前記処理構成はさらに、
    前記複数のデータパケットから選択されたデータパケットグループを特定し、
    レイヤ７から受け付けた前記情報に従って、前記選択されたデータパケットグループについて保証された帯域幅を割り当てる、
    よう構成される、請求項１３記載のコンピュータネットワークシステム。
15. レイヤ３は、ネットワーク状態セットをモニタするモニタリング構成を有し、
    レイヤ７は、
    前記ネットワーク状態セットに関する情報をレイヤ３から前記通信チャネルを介し受け付ける受信構成と、
    前記フローの選択された１つを向上させるため、レイヤ３から受け付けた前記情報に従って、前記電子メッセージトラフィックの入力フローと出力フローとを生成する少なくとも１つのソフトウェアプリケーションと、
    を有する、請求項１２記載のコンピュータネットワークシステム。
16. 前記ソフトウェアアプリケーションは、レイヤ３から受け付けた前記情報に従って、前記電子メッセージトラフィックの入力フローと出力フローの少なくとも１つを優先順位付けするよう構成される、請求項１５記載のコンピュータネットワークシステム。
17. レイヤ７はさらに、レイヤ３から受け付けた前記情報に従って、前記ソフトウェアアプリケーションに利用可能な帯域幅に関する制限を設定する制限構成を有する、請求項１５記載のコンピュータネットワークシステム。
18. レイヤ３は、少なくとも第１及び第２ネットワーク装置を有し、
    前記ソフトウェアアプリケーションは、レイヤ３から受け付けた前記情報に従って、前記第１及び第２ネットワーク装置の選択された１つに前記電子メッセージトラフィックの出力フローを送信するよう構成される、請求項１５記載のコンピュータネットワークシステム。
19. レイヤ７は、複数のデータパケットを有する前記電子メッセージトラフィックを生成するためソフトウェアアプリケーションを有し、
    レイヤ３は、
    レイヤ７における前記ソフトウェアアプリケーションに関する情報をレイヤ７から前記通信チャネルを介し受け付ける受信構成と、
    レイヤ７から受け付けた前記情報に従って、前記複数のデータパケットを処理する処理構成と、
    ネットワーク状態セットをモニタするモニタリング構成と、
    を有し、
    レイヤ７はさらに、前記ネットワーク状態セットに関する情報をレイヤ３から前記通信チャネルを介し受け付けるさらなる受信構成を有し、
    前記少なくとも１つのソフトウェアプリケーションは、前記電子メッセージトラフィックの入力フローと出力フローの少なくとも１つを向上させるため、レイヤ３から受け付けた前記情報に従って、前記電子メッセージトラフィックの入力フローと出力フローの生成を改良するよう構成される、請求項１２記載のコンピュータネットワークシステム。
20. オープンシステムインターコネクションモデルに基づき、ネットワークレイヤ（レイヤ３）とアプリケーションレイヤ（レイヤ７）とを有するコンピュータネットワークシステムにおいて、
    前記コンピュータネットワークは、当該コンピュータネットワークシステムとの間の電子メッセージトラフィックの入力フローと出力フローとをサポートするよう構成され、
    当該コンピュータネットワークシステムは、前記電子メッセージトラフィックの入力フローと出力フローの少なくとも１つを向上させるのに利用するため、レイヤ３とレイヤ７との間で情報を直接やりとりするレイヤ３とレイヤ７との間の通信チャネルを有する構成。

Images