JP2006519559A - 非永続的メモリ内のキューを用いる電子メール - Google Patents

Abstract

好ましくはランダムアクセスメモリなどの非永続的ストレージ内でのみ動作する電子メール処理システム。ランダムアクセスメモリ内に電子メールのキューが形成され、各キューは、特定のドメインに振り向けられる電子メールに関する個人別情報へのポインタを含む。電子メールを送信するために、そのドメインへのチャネルが開かれ、開いている間にキュー内の電子メールが送信される。特殊な復旧エージェントが、システム内の処理状態のスナップショットを定期的に取得する。非永続的ストレージ内で処理が行われているので、システム内の障害は、それらのスナップショットを用いて、各電子メールが処理されている場所を復旧することによって復旧可能である。一態様では、他の電子メールサーバへの供給レートが、それらの電子メールサーバのレートに基づいて調整される。さらにシステムは、他の電子メールに関する情報を処理している間に、DNS情報などの情報を非同期にルックアップする。

Description

関連出願の相互参照
本出願は、内容が参照により本明細書に組み込まれている米国特許仮出願第60/449,301号(2003年2月20日出願)の利益を主張するものである。

電子メールは、十分に確立された、テキストメッセージを送信者から受信者に送信するプロセスである。従来の電子メールのプロセスは、異なるいくつかの対話プロトコルとサーバとで定義されている。

従来の電子メールでは、パーソナルコンピュータ100が電子メールクライアント102を実行する。よく知られた電子メールクライアントとして、Microsoft outlookおよびOutlook expressが挙げられる。電子メールクライアントはスタンドアロンクライアントであることも可能であり、また、「Hotmail」のようにWebページ内で実行されるよう修正された電子メールクライアントであることも可能である。電子メールクライアントは、見出しによってメッセージをユーザのメールボックスにリストし、その見出しに関連付けられた電子メールをユーザが選択して読むことを可能にする。電子メールクライアントではさらに、メッセージの新規作成および新規メッセージの送信が可能である。

電子メールクライアントは、インターネット110またはより一般的な任意のネットワーク接続を経由してメッセージの送受信を行うために、ユーザのローカルインターネットサービスプロバイダ(ここでは「ドメイン」99として図示)にある電子メールサーバ120と通信する。ドメインは、単一メールクラスタ(たとえば、すべてのhotmail.com)を含むことや、何らかの方法で関連付けられる複数のメールクラスタを含むことが可能である。

サーバは、クライアント102から電子メールメッセージを受信し、それらのメッセージのリストを形成する。サーバ120は、一般に、何らかのタイプのプロセッサまたはコンピュータを含み、本明細書に記載の特殊な電子メールプログラムを実行する。

電子メールシステムのメカニズムは、SMTP、POP3、およびIMAPとして知られる、異なる3つのプロトコルを用いて動作する。SMTPサーバは、着信する電子メールを受信するためにポート25をリスンする。POP3サーバ140は、ローカルメールボックス(145など)へのローカルメッセージの配信を処理する。メールボックスは、実際には、電子メールクライアントがドメイン99にあるPOP3サーバ140にログインしたときにその電子メールクライアントにメッセージを供給するために形成されたキューである。

電子メール送信の処理は、電子メール受信の場合と異なる。電子メールクライアント102は、電子メールを送信するために、ドメイン99にあるSMTPサーバ130と対話する。メッセージの宛先が同じドメインにある別のメールボックスであった場合は、SMTPサーバ130が、ローカルPOP3サーバ140にメッセージを送信する。メッセージの宛先が別のドメインであった場合は、SMTPサーバがドメインネームサーバ(DNS)135と通信する。DNSは、すべてのドメインのIPアドレスを保管するデータベースを格納し、このデータベースはインターネットから更新される。DNSは、IPアドレスをSMTPサーバ130に供給する。

メッセージは、SMTPサーバ130のハードドライブ131に格納される。動作を円滑にするために、「ピッカ」と呼ばれるソフトウェアがしばしば動作する。ピッカは、SMTPサーバのハードドライブ131に格納されているメッセージを調べ、宛先についてのメッセージ見出しの解析、DNSとの通信、および宛先ドメインにあるSMTPサーバの使用可能なポートの検索を行うメカニズムを実行する。

これらの動作が完了すると、SMTPサーバ130が、DNSサーバ135から取得したIPアドレスを用いて、メッセージを、宛先ドメイン149にある別のSMTPサーバ150に送信する。SMTPサーバ130は、ドメイン149にある、対応するSMTPサーバ155と通信する。メッセージは、ドメイン149にあるSMTPサーバ155に転送される。SMTPサーバ155は、メッセージがローカルメールボックス宛てであることを認識するので、メッセージをそのローカルPOP3サーバ160に供給する。ローカルPOP3サーバ160は、メッセージをローカルメールボックス165のキューに入れる。

電子メール送信では、sendmail(商標)として知られるオープンソースプログラムがよく用いられる。このプログラムはさらに、ただちに送信できないメッセージをキューに入れる機能を始めとして、多くの付加機能を含んでいる。

電子メール受信にはPOP3サーバが用いられる。POP3サーバは、送信または受信された各電子メールに対して1つずつあるテキストファイルの集合体を保持する。POP3サーバは、新しい電子メールが受信されるたびに、その電子メールを受信者ファイル(メールボックス)に追加する。電子メールクライアント102は、ローカルドメイン99にあるPOP3サーバ140と通信する。POP3サーバは、電子メールクライアント102にそのメールボックスの内容を提供し、その後、メッセージを削除する。

IMAPサーバは、POP3サーバとともに、またはPOP3サーバの代わりに使用可能である。IMAPは、サーバにとどまるフォルダに電子メールを格納することを可能にする。

大規模な電子メールサーバでは、多数のピッカ(たとえば、50から100個のピッカ)が同時に動作する場合がある。これらの各ピッカは、SMTPサーバのハードドライブ131から情報を取得し、メッセージをハードドライブから一度に1つずつ移動させる

前述のタイプの従来の電子メールシステムでは、スループットの制限がしばしば発生することが指摘されている。ある制限の原因は、SMTPサーバのハードドライブにあるファイルにアクセスしなければならないことである可能性がある。

本システムは、このような従来の電子メール環境で動作することが可能でありながら、そうした動作に起因する遅延を低減することが可能なメッセージングシステムを表す。発明者は、SMTPサーバのハードドライブでの動作がサーバの負担になりうることと、それがさらにスループットの制限を引き起こす可能性があることとを認識した。

実施形態によれば、本メッセージングシステムは、メールを、非永続的メモリ(たとえば、ランダムアクセスメモリ)内に形成されるメモリキューおよびメモリキューマップに格納できる。メッセージ転送エージェントがメッセージおよびアドレスをフォーマットし、それらをメモリから送信されるように編成する。したがって、たとえば、このシステムは、Hotmailなどの特定ドメインへのパイプを開き、可能な限り多くのメッセージをそこから送信することを可能にする。

ある実施形態では、電子メールメッセージは、データベースからメモリに直接読み出され、メールボックスまたはホストに配信される。この場合、それらの電子メールが、電子メール処理ルーチンの一環として永続的ストレージに書き戻されることはない。

一態様は、メッセージを個人別部分と非個人別部分とに分割するメッセージラッパユーティリティを表す。

別の態様は、非永続的メモリ内の情報を定期的に保存するクラッシュ防止エージェントを表す。アプリケーションの処理状態は、このように、非常に効率的な方法でディスクに保存される。これは、実際にディスクに保存される情報量を最小限に抑えながら、クラッシュ時の復旧を容易にする。

以下、これらの態様および他の態様を、添付図面を参照しながら詳細に記載する。

本システムは、電子メールを処理および転送する、改良されたシステムを表す。

最初に断っておくが、本明細書の記載内容は、ワークステーションタイプのコンピュータやx86アーキテクチャに基づくコンピュータなどの汎用コンピュータで動作するソフトウェアモジュールについての説明である。しかしながら、本発明の記載内容は、ハードウェア定義言語で定義される機能を有する(たとえば、専用回路ベースまたはFPGAコンポーネント内の)ハードウェアとしても動作可能であることを理解されたい。本明細書の記載内容はソフトウェアについてのものであるが、発明者らは、この記載内容が、本明細書の記載対象と同等に動作するハードウェアデバイスをも同様にカバーすることを意図している。

図2は、メッセージキューマップの構成と使用方法とを示す。メッセージキューマップは、メールサーバ(たとえば、SMTP機能を実行するサーバ)内で動作する非永続的ストレージ(たとえば、ランダムアクセスメモリ)において形成されることが好ましい。好ましい実施形態では、電子メール処理動作の全体が、このタイプの非永続的メモリにおいて行われる。

先行システムでは、電子メール処理に非永続的メモリを用いることは遠ざけられている。実際、非永続的メモリを用いることは、システムが動作中にクラッシュした場合に大きな問題を引き起こす可能性がある。しかしながら、本システムは、電子メール処理の履歴情報およびそれらの電子メールの処理状態を保存することによってクラッシュ時の機能損失を回避する方法を教示する。態様は、その状態を保存する、非常に効率的な方法を表す。

図2に示したキューマップは、それぞれ200、202、および204として示した、いくつかのメッセージキューを有する。各メッセージキューは、ドメインネーム、システムユーザ(仮想サーバの場合)などの各種変数に基づいて定義される。メッセージキューは、キューの最も単純な形では、特定のドメインに関連付けられる。たとえば、メッセージキュー200は、Hotmail.comであるドメイン210に関連付けられている。yahoo.com(ドメイン214)用としたメッセージキュー204は、異なる2つのデータノード252、254を含み、それぞれがドメインyahoo.comに配信されることになっている。各データノードは、送信される電子メールに関する個人別情報を表す。

新しいメッセージ220も示されている。この新しいメッセージは、動作の一環として、既存のキューマップに追加される必要がある。225として示された入力ハンドラは、図3のフローチャートに示されるように動作可能である。300で、プロセスは、新しいメッセージ220を受信する。入力ハンドラは、305で、データノード230を、メッセージを表すダイジェストとして作成するよう動作する。この実施形態のデータノードは、1つのメッセージを表すオブジェクトである。データノードは、送信されるメッセージに関する情報を含み、受信者、送信者、その電子メールに関するデータ、ドメイン、一意のセッション識別子、訪問回数、およびサービス品質(「QoS」)保証とルーティング細目とに関する他の情報を含むことが可能である。ノードは、電子メール自体ではなく、メモリに格納される、電子メールへの単なるポインタであることに注意されたい。

データノードは、310で、適切なキュー(ドメインおよび種々雑多な変数の関数)を決定するために解析される。315では、メッセージを既存のキューに追加できるかどうかを決定する。追加できる場合は、320で、そのデータノードが既存のキューに追加される。

たとえば、ここでは、新しいメッセージ220はドメイン210(Hotmail.com)宛である。したがって、データノード230は、既存キュー200の末尾に追加される。

一方、315でノードを既存キューに追加できない場合は、325で、新しいキューが作成され、330で、データノード230がその新しく作成されたキューに追加される。このようにして複数のキューが形成され、各キューは、同じのルーティングストラテジを有するメッセージを表すノードに関連する。既存キューに最大メッセージ数を超える数のメッセージがある場合は、各キュー変数に対して複数のキューを設けることが可能である。

各キューは、同じドメインに配信されるなど、同じ処理ストラテジを必要とするメッセージを表すので、メッセージのキュー全体を一度に送信して、送信処理を合理化することが可能である。

ここでは出力ハンドラ240として示されているコマンドセットは、図4のフローチャートに従って、メッセージおよびキューに対して動作可能である。各データノードは、特定のメッセージを表す。出力ハンドラは、意図された受信者に電子メールを送信するために、データノードを処理する。出力ハンドラ240は、単一プロセスであるように示されているが、一度に複数のプロセスが、たとえば、各プロセスが任意の一時点において単一キューを処理したり、パイプライン化またはマルチスレッド化されたシステムを用いたりして、動作可能である。

このプロセスは400から始まる。400では、出力ハンドラが、処理すべき次のキューを探す。これは、ラウンドロビン方式で行うことが可能である。すなわち、各キューに、たとえば番号(n)が割り当てられ、システムが単純にn+1のキューを探せば、そこには最大n個のキューが存在可能であることになる。代替システムは、出力ハンドラが、最大数のメッセージノードを含むキューを常に処理するシステムである。この例では、キューはそれぞれの長さに従ってソートされ、その場合、400では、最長のキューか、次のフルキューが見つけられる。一方、別の実施形態では、キューが存在している時間の長さも考慮されることが可能である。言い換えると、指定時間(X分など)の間に最長キューが処理されなかった場合以外は、その最長キューが最初にソートされる。

420は、現在のキューにおいてメッセージが見つけられ、キューから外され、配信のために処理される。425で、メッセージラッパが形成される。メッセージラッパには複数のメッセージを含めることができる。メッセージラッパ内の各メッセージはそれぞれの個人別化されたコンテンツを有するが、メッセージの共通部分(ドメイン情報など)は、ラッパ自体から提供される。これによって、プロセスをさらに合理化することが可能である。

430で、同じメッセージラッパに含めて送信できるアイテムがそのキューにさらにあるかどうかを調べ、ある場合は、420でメッセージを取得し、それを425でメッセージラッパに追加する。そのキューが完了したら、435による処理が実行される。435では、受信者ドメインのSMTPサーバを見つけ、そのSMTPサーバとの接続を行い、メッセージを表すプロトコルトークンを送信し、それからメッセージを配信する。

キュー内のメッセージがすべて外されたら、445で、そのキューはメモリマップから除去される(消される)。回復可能なエラーによってメッセージ処理が失敗した場合は、そのメッセージをキューに戻すか、同じドメインであることを表す新しいキューにプッシュすることが可能である。メッセージ配信が失敗するたびに「訪問回数」がインクリメントされる。メッセージの失敗は、受信者サーバが、たとえばビジーかアクセス不能かで使用不可能であるために起こる場合がある。その後、450で、処理が次のキューに移る。

オーバーフローの防止方法を図5のフローチャートに示す。オーバーフローは、キューイングエージェント225がメッセージを処理できる速度より高速でメッセージが受信された場合に起こる可能性がある。500で、入力ハンドラが、指定数(たとえば、1000メッセージ)を超える未処理分を抱えていることを検知するか、メッセージキューのサイズが指定の処理時間(たとえば、3秒)より長くなるかどうかを検知する。505で、入力ハンドラが、メッセージを受信しているメッセージサーバ(たとえば、SMTPサーバ)に「一時停止」確認応答を送信する。一時停止確認応答は、メッセージサーバに対し、受信したメッセージの送信を停止するよう伝える。これを受け、メッセージサーバは、未処理分が減少するまで、受信したメッセージを保存する。

ループは、500で未処理分をチェックすることを続ける。500で、キュー内のメッセージ数がサイズの制限値を下回ると、510で、リレーサーバが「送信」確認応答をメッセージサーバに送信する。これにより、メッセージサーバはメッセージの送信を再開することが可能になる。

サーバアプリケーション702は、特定のドメインへ電子メールメッセージを、他のドメインに対してより速く送信できる可能性がある。この場合は、ロードバランサ732が、より速いドメインへの電子メールを、より遅いドメインへのものよりも多くサーバ702に渡すことができる。統計ポーリングプロセス764およびリスナプロセスがこれを実行できる。このようにして、メッセージサーバは、リレーサーバが実行しているレートに従って供給レートを有効に調整する。これにより、システムは、より遅いリレーサーバを考慮して、より遅いリレーサーバによるメッセージのブロッキングを防止することができるであろう。

基本的なロードバランシングは、以下のステップで行われる。

次のメッセージパラメータを取得する。

個人別のヘッダと本体とを完全に生成する。

現在のロード条件を照会し、メッセージの配信レートを計算する。

新しいメッセージに対してシステムリレーの準備ができているかどうかを計算する。

準備ができていれば、メッセージをプッシュする。

このようにして、入力ハンドラは、メッセージを処理できる場合のみ、メッセージを受信する。これが基本的なロードバランシングの一態様を与える。

図6は、電子メールメッセージングシステムの基本ブロック図である。リレーサーバ602が入力メッセージ処理の機能を実行する。リレーサーバ602は、キューイングエージェント604とともに、メモリキュー統計要素606とメッセージリアクタ607とを含む。メッセージリアクタ607としては、SMTPサーバまたは同等機能を実行するサーバ、あるいは既存のSMTPサーバとインターフェースするデバイスを用いることができる。

メッセージリアクタ607は、メッセージをユーザメールボックス608に配信する。存在しないメールボックスに宛てられたメッセージは、バウンスサーバ606が検出して、後処理のために「保管」する。

入力パーサ616がメッセージを受信して特徴づける。パーサ616は、メッセージサーバ610、統計コレクタ612、および復旧エージェント614を含む。これらの各機能は、処理を促進するために、RAM内または非永続的ストレージ内で実行される。復旧エージェントは、システム変数のスナップショットを永続的ストレージに格納して、システムがコンピュータクラッシュから復旧することを可能にする。一方、代替として、おそらくそれほど好ましい実施形態ではないが、キューまたはキューの一部をディスクドライブに保持することができる。これらの要素の機能については、本明細書においてさらに詳細に説明する。

図7は、クライアント、サーバ、およびライセンスサーバ認証ユニットの間でのメッセージのやりとりのフローチャートである。

クライアントアプリケーションは700として示されており、たとえば、ユーザのコンピュータで動作する電子メールクライアントがこれに相当する。クライアントアプリケーション700は、従来タイプの個人別メッセージを作成し、それらのメッセージのサーバへの送信を制御および命令する。これは、いくつかのエージェントを用いて行われ、そのすべてのエージェントがソフトウェアの形で動作することが可能である。

クライアントアプリケーション700では、電子メールを形成および送信するために、いくつかの異なるプロセスが連係して動作する。メッセージファイルデータベース712は、送信される個々のメッセージファイル、すなわち、電子メールの固有部分を形成するテキストおよび/または添付ファイルを表す。多くの様々な電子メールに用いることが可能な他の部分は、データベース710、714などのファイルに格納される。データベース710は、電子メールアドレスを提供する。電子メールの受信者に関するメーリング情報などを含むメーリングプリファレンスは、データベース712に格納される。これら2つのデータベースは、得られる電子メールに関する追跡情報を格納するメーリングコンフィグレーションファイル714と組み合わせて用いられる。

図2で252として示されるようなノードは、メッセージファイル712内の領域および/またはデータベース710とコンフィグレーションファイル714の中の領域へのポインタであることが可能である。さらに、各電子メールには、キューに入っている電子メールのビットベクトルから形成された一意のIDを割り当てることが可能である。ビットベクトルは、永続的ストレージに格納することが可能である。ビットベクトルは、メッセージと、各電子メールの処理状態とを再構築するのに十分な情報を含むことができる。この情報は、ディスクまたは永続的ストレージに格納される。これにより、電子メールをそっくりそのままディスクに格納しなくても、システムの全処理状態の復旧が可能になる。

格納されるのは、電子メールのコンテンツを表す特定のデータやメモリ内のロケーションなどだけである。たとえば、各キューにある各メッセージのメッセージIDは、状態を保存するために、定期的に記録されることが可能である。何らかの原因でリレーサーバがダウンすると、現在処理中だったメッセージのIDが記録される。このクラッシュは、新しいメッセージサーバを起動し、そのセットアップ時にそれらの未処理メッセージを他のリレーサーバに転送することによって修復される。すべてのリレーサーバが同時にダウンした場合は、配信されないメッセージのIDが記録されたままとなり、システムによって送信されることが可能である。

データベース710内の電子メールアドレス記録は、メーリングコンフィグレーションファイル714の内容とともに、データベースパーサ720で処理される。これに対応して、メッセージデータベース712内のメッセージ記録がメッセージパーサ722で処理される。2つのパーサ720および722は、データベース記録に作用し、解析されたコンテンツを個人別化エージェント724に渡す。このエージェントは、アドレス記録から解析された情報を、解析されたメッセージと結合する。一実施形態では、解析されたメッセージは、メッセージリストパラメータ(たとえば、図2の要素230で示されるパラメータ)からのトークンでメッセージテンプレートを埋めることによって形成されることが可能である。名前や他の情報などの個人別化されたコンテンツは、その個人別化に基づいて出力メッセージに挿入される。

電子メールメッセージは、個人別化エージェント724のコンテンツを用いてメッセージラッパを作成することによって作成される。個人別化エージェント724は、データベースパーサ720からの解析されたアドレスに、メッセージパーサ722からのメッセージを含めて、個人別化メッセージ725を作成する。得られるアドレスは、速い処理が可能であるように、ランダムアクセスメモリ内でのみ操作されることが好ましい。

その後、個人別化メッセージ725は、キューイングエージェント730に渡される。キューイングエージェント730は、メッセージ入力を取得し、それを適切なキューに入れる。このキューは、図2を参照して前述したように形成されることが可能である。電子メールは、一般に、その電子メールを受信するドメイン別にキューに入れられる。よく用いられるドメインネームは、複数のキューを受信する場合がある。

クライアントからサーバへのロードバランサ732は、図5を参照して前述したように、キューを監視して、サーバ702に着信電子メールによる負担がかかり過ぎていないことを確認する。

サーバアプリケーション702は、要求ハンドラ740を用いて、メッセージを取得し、そのメッセージを1つまたは複数の配信エージェント742に配信する。配信エージェントは1つだけ図示されているが、複数のそのようなエージェントが存在可能である。これらの配信エージェント742は、いくつかのリモート接続を管理するリモート接続プールマネージャ744に電子メールメッセージを伝達する。リモート接続プールマネージャ744は、746、780、および782として示される受信者SMTPサーバとの接続を確立、維持、および終了する。

リモート接続プールマネージャ744は、受信者SMTPサーバとの接続を直接保持でき、これにより、この接続を維持する負担をローカルISPのSMTPサーバにかけないようにできる。

リモート接続プールマネージャ744はさらに、定期的に更新されるオフラインキューまたはキャッシュ352からの指示で動作する非同期DNSリゾルバ750を用いる。DNSルックアップは、メッセージ配信の残りの部分に対して非同期で行うことが可能である。このようにして、750での、DNSキャッシュ752からのDNS情報のルックアップは、メッセージ配信の他の部分と並行して行うことができる。

配信エージェント342はさらにロギングエージェント760と通信し、ロギングエージェント760は、どの電子メールが送信されたかを監視するモニタプロセスを形成する。これにより、システムクラッシュがあった場合に完全に復旧できよう。

メーリングコンフィグレーションファイル714、データベースパーサ720、およびメッセージパーサ722の動作は、予測可能かつ論理的である(フローチャート?)。したがって、電子メール送信がどこで中断されたかがわかれば、任意のシステムクラッシュの時点で存在したポイントを容易に復旧することが可能である。

ロギングエージェント760はさらに、統計リスナプロセス762および統計ポーリングプロセス764と通信する。ロギングエージェント760は、成功した電子メール送信と失敗した電子メール送信とを監視する。送信の失敗は、リモートサーバが使用不能か、DNS解決が失敗した場合に起こる可能性がある。ステータスポーリングプロセス764はさらに、キューイングエージェント730と通信し、最後の出力メッセージの記録を保持する。このようにして、中断されたメールストリームを、中断ポイントで再構築することが可能である。

リスナプロセス762は、成功した電子メール送信についてログを作成するか、情報を提供する。ある実施形態では、電子メールに関する情報は、そのリストにおいて、参考としてのみリストされる。たとえば、リスナプロセス762は、どの配信が成功したかを示すことができる。これはさらに、拒否された電子メールに関する情報またはログも保持する。それらの電子メールは、失敗がどのように起こったかを突き止めるための科学検査的解析が実施可能であるように、完全な形式で拒否される可能性がある。

ロギングエージェント760はさらに、電子メールがいつクリックされたか、あるいはいつ開かれたかを示すことも可能である。

複数のソースから電子メール情報を収集および集約するロギングエージェントは、ライセンスサーバ統計コレクタ770と連絡をとることもでき、ライセンスサーバ認証プロセス704と連絡をとることもできる。ライセンスサーバ認証はさらに、サーバおよびクライアントの両方と通信する。

ライセンス認証の概念は、本システムによる完全に新しいパラダイムである。統計コレクタ370は、このシステムで処理されたメッセージの数に関する統計を収集する。ある実施形態では、サーバ認証304は、これまでに送信されたメッセージの数/タイプに見合うだけのライセンス料金をユーザが払っているかどうかを調べる。サーバ認証304は、超過したメッセージ数に基づいて、メッセージ送信を拒否したり、警告を送信したりできる。このようにして、このソフトウェアは、利用回数制料金のソフトウェアとして有効に動作可能である。すなわち、初期ソフトウェアを、ある程度の数のメッセージが有効な状態で販売できる。これによって、ユーザは、一定期間の間、そのソフトウェアをほとんどシェアウェアとして評価できるであろう。それらのユーザは、そのソフトウェアをインストールでき、そのソフトウェアは、メッセージの数が指定値に達するまで、所望の動作を行う。指定値に達した後、さらにメッセージを処理するには、ユーザは追加ライセンス料金を支払う必要がある。

以上、わずかな数の実施形態について詳細に説明してきたが、他の修正も可能である。本明細書には、その修正のほとんどが記載されている。

ある実施形態では、前述のプログラム機能がC++で書かれるが、他のプログラムを用いてこのプログラムを書くことも可能であることを理解されたい。また、これらの動作は、ハードウェア定義言語を用いて定義されたハードワイヤードロジック、またはFPGA、または他のコンポーネントで実行可能であることも理解されたい。

本システムは、電子メールアプリケーションとともに使用する文脈で説明されているが、インターネットのようなネットワークを経由してメッセージ(好ましくはテキストメッセージ)を送信する任意のシステムに対して用いることが可能である。

具体化された場合の本システムは、sendmailなどのサードパーティ製メール送信アプリケーションや他のプログラムには依拠しないが、それらの使用は可能である。

電子メールのフロー図である。 本システムに従って形成されるキューを示す図である。 キューの作成および処理のフローチャートである。 キュー内でのメッセージ処理のフローチャートである。 ロードバランシングの一態様のフローチャートである。 キューおよびキューを処理するエージェントのブロック図である。 動作プログラムを構成する各種機能要素を示す図である。 動作プログラムを構成する各種機能要素を示す図である。

Claims (83)

1. 複数のそれぞれの宛先への配布を意図された複数の電子メールを取得することと、前記電子メールの処理中に、前記電子メールを表す情報を永続的ストレージに書き込んで読み出すことを必要とせず、前記複数の電子メールを非永続的ストレージ内でのみ処理することとを含む方法。
2. 前記処理を表す復旧情報を永続的ストレージに格納することをさらに含み、前記復旧情報がシステム障害からの復旧に用いられる、請求項1に記載の方法。
3. 前記復旧情報が、複数の電子メールを表す情報を含み、各電子メールを表す各情報が、電子メールそのものより少ない情報を表す、請求項2に記載の方法。
4. 前記電子メールを表す前記情報がビットベクトルを含む、請求項3に記載の方法。
5. 前記処理が、前記電子メールに関する情報を、各キューがそれぞれ単一ドメインを表す複数のキューに整理し、さらに、前記１つのキューからの複数の電子メールを、特定の１つの送信インスタンスで単一ドメインに送信することによって、電子メールを受信者に送信することを含む、請求項1に記載の方法。
6. 前記送信することが、単一の指定されたドメインへの通信チャネルを開き、前記単一の通信チャネル内で複数の電子メールを送信することを含む、請求項5に記載の方法。
7. 前記復旧情報が、各電子メールを表す数値表示と、前記電子メールの処理状態とを含む、請求項3に記載の方法。
8. 処理すべきキューを選択することと、前記キューから一度にすべての電子メールを前記単一ドメインに送信することとをさらに含む、請求項5に記載の方法。
9. 前記選択することが、キュー内に最大数の前記電子メールを含む前記キューを選択することを含む、請求項8に記載の方法。
10. 前記選択することが、最も長い時間にわたって存在しているキューを選択することを含む、請求項8に記載の方法。
11. 第1のキューを選択している間に、前記第1の、選択中のキューとは別の第2のキューに関するドメインネームサーバ情報を非同期にルックアップすることをさらに含む、請求項8に記載の方法。
12. 各電子メールに関する個人別情報を非個人別情報と分離することによって前記電子メールを処理することをさらに含む、請求項1に記載の方法。
13. 前記非個人別情報が、前記電子メールの宛先情報を含む、請求項12に記載の方法。
14. 前記処理が、前記ドメインによる処理に関する情報を決定することと、前記ドメインの処理の前記情報に基づいて前記電子メールの処理の速度を調整することとを含む、請求項5に記載の方法。
15. 前記処理に関する情報が、電子メール処理の速度を含む、請求項14に記載の方法。
16. 前記ソフトウェアパッケージ内で処理された電子メールに関連する情報を表すログを保持することと、
    前記ログの内容をライセンシング情報と比較して、前記情報の電子メールがライセンスされている数を超えていないかどうかを調べることとをさらに含む、請求項1に記載の方法。
17. 処理のために複数の電子メールを取得することと、
    前記電子メールの処理状態に関する、前記電子メールそのものより情報量が少ない復旧情報を永続的ストレージに格納することと、
    前記処理中に前記電子メールを永続的ストレージに書き込むことなく、前記電子メールを所望の所在地に振り向けるよう、前記電子メールを処理することとを含む方法。
18. 前記処理が、電子メールを電子メールクライアントから所望のロケーションに送信することを含む、請求項17に記載の方法。
19. 前記処理が、電子メールを受信することと、指定された宛先に前記電子メールを配布することとを含む、請求項17に記載の方法。
20. 前記復旧情報が、複数の電子メールを表す情報を含み、各電子メールを表す各情報が、電子メールそのものより少ない情報を表す、請求項17に記載の方法。
21. 電子メールを表す前記情報がビットベクトルを含む、請求項19に記載の方法。
22. 前記処理が、前記電子メールに関する情報を、各キューがそれぞれ単一ドメインを表す複数のキューに整理し、さらに、複数の電子メールを、特定の１つの送信インスタンスで、単一ドメインに送信することによって、電子メールを受信者に送信することを含む、請求項17に記載の方法。
23. 前記送信することが、単一の指定されたドメインへの通信チャネルを開くことと、前記単一の通信チャネル内で複数の電子メールを送信することとを含む、請求項18に記載の方法。
24. 前記復旧情報が、電子メールの数と、前記電子メールの処理状態とを含む、請求項17に記載の方法。
25. 処理すべきキューを選択することと、前記キューから一度にすべての電子メールを前記単一ドメインに送信することとをさらに含む、請求項22に記載の方法。
26. 前記選択することが、キュー内に最大数の前記電子メールを含む前記キューを選択することを含む、請求項25に記載の方法。
27. 前記選択することが、最も長い時間にわたって存在しているキューを選択することを含む、請求項25に記載の方法。
28. 第1のキューを選択している間に、前記選択中のキューとは別の第2のキューに関するドメインネームサーバ情報を非同期にルックアップすることをさらに含む、請求項25に記載の方法。
29. 各電子メールに関する個人別情報を非個人別情報と分離することによって前記電子メールを処理することをさらに含む、請求項17に記載の方法。
30. 前記非個人別情報が、前記電子メールの宛先情報を含む、請求項29に記載の方法。
31. 前記処理が、前記ドメインの処理の速度を決定することと、前記ドメインの処理の前記速度に基づいて前記電子メールの処理の速度を調整することとを含む、請求項22に記載の方法。
32. 処理された電子メールに関連する情報を表すログを保持することと、
    前記ログの内容をライセンシング情報と比較して、前記情報の電子メールがライセンスされている数を超えていないかどうかを調べることとをさらに含む、請求項17に記載の方法。
33. 処理のために複数の電子メールを取得することと、
    それぞれが電子メールの宛先を表す複数のキューの1つに電子メールを割り当てる、前記電子メールに関するキュー情報を形成することと、
    前記キュー内の前記電子メールを処理して、前記電子メールを前記宛先に送信することと、
    前記宛先における処理のレートに基づいて前記電子メールの前記処理のレートを調整して、ロードバランシングを実行することとを含む方法。
34. 前記処理が、
    前記電子メールの処理中に、前記電子メールを表す情報を永続的ストレージに書き込んで読み出すことを必要とせず、前記複数の電子メールを非永続的ストレージ内でのみ処理することを含む、請求項33に記載の方法。
35. 前記処理を表す復旧情報を永続的ストレージに格納することをさらに含み、前記復旧情報がシステム障害からの復旧に用いられる、請求項34に記載の方法。
36. 前記復旧情報が、複数の電子メールを表す情報を含み、各電子メールを表す各情報が、電子メールそのものより少ない情報を表す、請求項35に記載の方法。
37. 前記電子メールを表す前記復旧情報がビットベクトルを含む、請求項36に記載の方法。
38. 特定の１つの送信インスタンスで、単一ドメインに複数の電子メールを送信することによって、電子メールを受信者に送信することをさらに含む、請求項33に記載の方法。
39. 前記送信することが、単一の指定されたドメインへの通信チャネルを開き、前記単一の通信チャネル内で複数の電子メールを送信することを含む、請求項38に記載の方法。
40. 前記復旧情報が、電子メールの数と、前記電子メールの処理状態とを含む、請求項36に記載の方法。
41. 処理すべきキューを選択することと、前記キューから一度にすべての電子メールを前記単一ドメインに送信することとをさらに含む、請求項33に記載の方法。
42. 前記選択することが、キュー内に最大数の前記電子メールを含む前記キューを選択することを含む、請求項41に記載の方法。
43. 前記選択することが、最も長い時間にわたって存在しているキューを選択することを含む、請求項41に記載の方法。
44. 第1のキューを選択している間に、前記選択中のキューとは別の第2のキューに関するドメインネームサーバ情報を非同期にルックアップすることをさらに含む、請求項41に記載の方法。
45. 各電子メールに関する個人別情報を非個人別情報と分離することによって前記電子メールを処理することをさらに含む、請求項33に記載の方法。
46. 前記非個人別情報が、前記電子メールの宛先情報を含む、請求項45に記載の方法。
47. 処理された電子メールに関連する情報を表すログを保持することと、
    前記ログの内容をライセンシング情報と比較して、前記情報の電子メールがライセンスされている数を超えていないかどうかを調べることとをさらに含む、
    請求項33に記載の方法。
48. 電子メールソフトウェアパッケージで複数の電子メールを処理することと、
    前記ソフトウェアパッケージ内で処理された電子メールの数を表すログを保持することと、
    前記ログの得られた内容をライセンシング情報と比較して、処理された電子メールの数が前記ライセンスされている電子メールを超えていないかどうかを調べることとを含む方法。
49. 前記電子メールの処理中に、前記電子メールを表す情報を永続的ストレージに書き込んで読み出すことを必要とせず、前記複数の電子メールを非永続的ストレージ内でのみ処理することをさらに含む、請求項48に記載の方法。
50. 前記処理を表す復旧情報を永続的ストレージに格納することをさらに含み、前記復旧情報がシステム障害からの復旧に用いられる、請求項49に記載の方法。
51. 前記復旧情報が、複数の電子メールを表す情報を含み、各電子メールを表す各情報が、電子メールそのものより少ない情報を表す、請求項50に記載の方法。
52. 前記処理が、前記電子メールに関する情報を、各キューがそれぞれ単一ドメインを表す複数のキューに整理し、さらに、複数の電子メールを、特定の１つの送信インスタンスで、単一ドメインに送信することによって、電子メールを受信者に送信することを含む、請求項48に記載の方法。
53. 前記送信することが、単一の指定されたドメインへの通信チャネルを開き、前記単一の通信チャネル内で複数の電子メールを送信することを含む、請求項52に記載の方法。
54. 前記復旧情報が、電子メールの数と、前記電子メールの処理状態とを含む、請求項50に記載の方法。
55. 処理すべきキューを選択することと、前記キューから一度にすべての電子メールを前記単一ドメインに送信することとをさらに含む、請求項52に記載の方法。
56. 前記選択することが、キュー内に最大数の前記電子メールを含む前記キューを選択することを含む、請求項55に記載の方法。
57. 前記選択することが、最も長い時間にわたって存在しているキューを選択することを含む、請求項55に記載の方法。
58. 第1のキューを選択している間に、前記選択中のキューとは別の第2のキューに関するドメインネームサーバ情報を非同期にルックアップすることをさらに含む、請求項55に記載の方法。
59. 前記処理が、前記ドメインの処理の速度を決定することと、前記ドメインの処理の前記速度に基づいて前記電子メールの処理の速度を調整することとを含む、請求項49に記載の方法。
60. 処理のために複数の電子メールを取得することと、
    前記電子メールの宛先を表す、前記電子メールに関する編成情報を形成することと、
    特定の時刻に、特定の宛先に複数の電子メールを送信することと、
    前記送信中に、その後のある時刻に送信を行う別の特定の宛先に関してドメインネーム情報を非同期にルックアップすることとを含む方法。
61. 前記電子メールの処理中に、前記電子メールを表す情報を永続的ストレージに書き込んで読み出すことを必要とせず、前記複数の電子メールを非永続的ストレージ内でのみ処理することをさらに含む、請求項60に記載の方法。
62. 前記処理を表す復旧情報を永続的ストレージに格納することをさらに含み、前記復旧情報がシステム障害からの復旧に用いられる、請求項61に記載の方法。
63. 前記復旧情報が、複数の電子メールを表す情報を含み、各電子メールを表す各情報が、電子メールそのものより少ない情報を表す、請求項61に記載の方法。
64. 前記処理が、前記電子メールに関する情報を、各キューがそれぞれ単一ドメインを表す複数のキューに整理し、さらに、複数の電子メールを、特定の１つの送信インスタンスで、単一ドメインに送信することによって、電子メールを受信者に送信することを含む、請求項60に記載の方法。
65. 前記送信することが、単一の指定されたドメインへの通信チャネルを開き、前記単一の通信チャネル内で複数の電子メールを送信することを含む、請求項64に記載の方法。
66. 前記復旧情報が、電子メールの数と、前記電子メールの処理状態とを含む、請求項63に記載の方法。
67. 処理すべきキューを選択することと、前記キューから一度にすべての電子メールを前記単一ドメインに送信することとをさらに含む、請求項64に記載の方法。
68. 前記選択することが、キュー内に最大数の前記電子メールを含む前記キューを選択することを含む、請求項67に記載の方法。
69. 前記選択することが、最も長い時間にわたって存在しているキューを選択することを含む、請求項67に記載の方法。
70. 第1のキューを選択している間に、前記選択中のキューとは別の第2のキューに関するドメインネームサーバ情報を非同期にルックアップすることをさらに含む、請求項67に記載の方法。
71. 前記処理が、前記ドメインの処理の速度を決定することと、前記ドメインの処理の前記速度に基づいて前記電子メールの処理の速度を調整することとを含む、請求項63に記載の方法。
72. 前記ソフトウェアパッケージ内で処理された電子メールの数を表すログを保持することと、
    前記ログの内容をライセンシング情報と比較して、前記電子メールの数がライセンスされている数を超えていないかどうかを調べることとをさらに含む、請求項60に記載の方法。
73. 処理のために複数の電子メールを取得することと、
    共通の宛先への配布を意図されている電子メールのキューを表す、前記電子メールに関する編成情報を形成することと、
    どのキューから送信するかを、前記キュー内の電子メールの特性に基づいて決定することとを含む方法。
74. 前記電子メールの処理中に、前記電子メールを表す情報を永続的ストレージに書き込んで読み出すことを必要とせず、前記複数の電子メールを非永続的ストレージ内でのみ処理することをさらに含む、請求項73に記載の方法。
75. 前記選択することが、キュー内に最大数の前記電子メールを含む前記キューを選択することを含む、請求項73に記載の方法。
76. 前記選択することが、最も長い時間にわたって存在しているキューを選択することを含む、請求項73に記載の方法。
77. 第1のキューを選択している間に、前記選択中のキューとは別の第2のキューに関するドメインサーバネームサーバ情報を非同期にルックアップすることをさらに含む、請求項73に記載の方法。
78. 前記処理を表す復旧情報を永続的ストレージに格納することをさらに含み、前記復旧情報がシステム障害からの復旧に用いられる、請求項73に記載の方法。
79. 前記復旧情報が、複数の電子メールを表す情報を含み、各電子メールを表す各情報が、電子メールそのものより少ない情報を表す、請求項73に記載の方法。
80. 前記処理が、前記電子メールに関する情報を、各キューがそれぞれ単一ドメインを表す複数のキューに整理し、さらに、複数の電子メールを、特定の１つの送信インスタンスで、単一ドメインに送信することによって、電子メールを受信者に送信することを含む、請求項73に記載の方法。
81. 前記送信することが、単一の指定されたドメインへの通信チャネルを開き、前記単一の通信チャネル内で複数の電子メールを送信することを含む、請求項80に記載の方法。
82. 前記処理が、前記ドメインの処理の速度を決定することと、前記ドメインの処理の前記速度に基づいて前記電子メールの処理の速度を調整することとを含む、請求項80に記載の方法。
83. 前記ソフトウェアパッケージ内で処理された電子メールの数を表すログを保持することと、
    前記ログの内容をライセンシング情報と比較して、前記電子メールの数がライセンスされている数を超えていないかどうかを調べることとをさらに含む、請求項73に記載の方法。

Images