JP4717886B2 - 電子メールを規制する方法及びシステム - Google Patents

Description

発明の背景
１．発明の分野
本発明は、不要なバルク（bulk）ｅメールつまり「スパム」の侵入を防ぎながら、正当な両通信者間での電子メール（ｅメール）の効率的な送達に関する。特に、正当なｅメールに添付することができ、バルク送信者（「スパマー」）がそれを購入するのは非経済的である再使用可能な許可証（permit）、つまり「スタンプ」のプロセスに関する。また、発明は、スタンプ無しのｅメールに対する返信の集中管理のプロセスに関する。

例えば、ＲＦＣ２８２１とＲＦＣ２８２２のプロトコルを使用する種類のｅメールが主要な通信テクノロジーになってきたことによって、「ジャンクメール」又は「スパム」ｅメールも問題になっている。ｅメールのユーザは、知らない者から無差別に送られてくる非常に大量の広告ｅメールに直面する。現存する「スパム・フィルタリング」サービスは、世界中で送られるすべてのｅメールの５０％〜７０％がスパムであると推定している。また、かなりの程度の「インターネットの存在」を持ち、従って標的となりやすい個人にとっては、受信するｅメールの９９％までがスパムであるかもしれない。

そのような大量の迷惑なｅメールの送信及び格納におけるネットワーク及びコンピュータリソースの浪費と並んで、関心のある少数のメールを見つけるために大量の望まない無関係のｅメールを選り分けなければならない受信者にとって、スパムに対処するコストは最も痛切である。これに要する時間と労力に加えて、重要なｅメールを「雑音」の中で見落とす恐れもある。これによって、ｅメールは全体として、さほど信頼できず、さほど有用でない通信の形になる。

スパムに対する完全な解決は、受信者にとっての知らない人、及び、関係者からの少量ではあるが高度にターゲットされた販売・広告のｅメールを含んで、正当な送信者からのｅメールの送達を許可しながら、受信者に関係のないバルク送信者からのｅメールの送達を防止することであろう。

２．関連背景技術
「スパム問題」のいくつかの解決策が提案されており、多くが現在実施されている。業界の慣例に従って、以下の説明で、「偽陽性（false positive）」は誤ってブロックされた正当なｅメールであり、「偽陰性（false negative）」は誤って送達されたスパムｅメールである。スパム防止の目的は、もちろん両タイプのエラーをゼロにすることである。

スパムを送る慣行は十分に有害であると考えられ、種々の司法当局がそれを禁止又は制限する立法措置を実施しており、それは以下を含む。
・アメリカのＣＡＮ−ＳＰＡＭ法
・プライバシー及び電子通信に関するＥＵ指令（特に１３条）

これらの法的措置は確かに一部のスパマーにとって活動をより難しくしているが、インターネットのグローバルな性質により、単に国外へと他の管轄に拠点を移したり、一連の偽装身分の後ろに隠れる、より巧妙な違反者に対処することが不可能になった。従って、焦点はより技術的な手段に移っている。

スパムの問題の最も明白な解決策は、まず第１にスパムの送信を防ぐことである。発信元でスパムを差し止めることは、スパマーのビジネスを削減する間接の経済効果を待たずに、ネットワーク帯域幅浪費に最大の直接効果を持つ。

ｅメールシステムは伝統的に非常にオープンであり、スパマーが匿名のままｅメールを発信するために、ほとんどのメールサーバを使用することを可能にしている。従って、第１の反スパム策の１つは、米国特許第６３２１２６７号に開示されているように、「オープンメールリレー」を停止あるいは封鎖することであった、

オープン中継がそれほど有効でなくなると、スパマーはインターネット・サービス・プロバイダー（ＩＳＰ）のサーバを使用し、一時的なユーザアカウントの後ろに隠れて、識別されずにｅメールを送るために比較的匿名のメールプロトコルを使用し始めた。これに対して試みられた解決策は、ＩＳＰのメールサーバに認証を受けさせることを送信者に強いる認証ＳＭＴＰの増加使用であった。サインアップ時のユーザ識別のより厳格な検証と組み合わせて、これは少なくとも違反のスパム・エピソードを発信者までさかのぼるのに使用することができ、その時点で上記法的制裁を課すことができる。

スパマーの他の選択肢はインターネットに直接接続された自分のメールサーバを操作することであり、それはｅメールの配信のための送達先メールサーバに直接接続する。これは発信元でスパムを操作する試みを回避するが、受信側のメールサーバの中には、送信側メールサーバがスパムのコンジットである疑いがあるかを示す「ブラックリスト」に対するチェックを実施するものもある。このプロセスは、残念ながら多くの偽陽性を引き起こす傾向がある。

他の解決策は、単に疑わしいスパマーからのｅメールをブロックするのではなく、別の解決策は、「壊れている」ｅメール受信サーバを構築して、非常にゆっくり応答することにより送信側メールサーバを遅くする「ターピット（tarpit）」として知られる考えであって、メール送信プロセスで故意に摩擦を作り出すことである。ターピットサーバが単にスパマーを陥れるために使用するいくつかの完全に虚構のアドレスのためのｅメールを扱えば、これは特にうまくいく。しかし、そのような技術は、個々のｅメールが配信されたかを気にかけないスパマーならかなり容易に対応でき、長くかかりすぎる送信を単に取り消すことができる。

個々のｅメール送信者の「悪質さ」を計る他の方法は、彼らが送るｅメールのボリュームを測定することである − これはまず第１にスパムに関する大問題である。理論上、彼が接続するネットワーク・エッジでこれを行うことができるかもしれないが、実際上は、ルーターの処理能力と記憶容量の制限のために無理であろう。しかし、いくつかの大きな組織では、ターンタイド反スパム・ルーター（TurnTide Anti-Spam Router）のような製品を使用して、それを根拠とした独自の管理を実施している。これは、特定のネットワーク・アドレスから来るｅメールのボリュームを測定し、それを毎時少数に制限する。これは単一のネットワーク・アドレスからの主なスパム攻撃を止めるが、より分散した「秘密」戦術を防止しない。

よりよく、より長期的なアプローチは、スパムとほとんど普遍的に密接な関係があり、「ホワイトリスト作成」（後述）ような他の技術の良好な実施を妨げるリターンアドレスの偽造を少なくとも防止するために、ｅメール交換処理自体のより強い認証を要求することである。ＹａｈｏｏのDomainKeysのようないくつかの特定のもの加えて、一般的な標題「軽量ＭＴＡ認証プロトコル（Lightweight MTA Authentication Protocol）」の下でいくつかの提案がなされている。これらの提案のより強いバージョンは、各端末での暗号のソフトウエアと本人確認の厳密な証明を要求するが、かなり前から存在している。

これらすべての提案の問題点は、送信者が発信元と主張するドメイン又はアイデンティティーを使用する権利を持っていることが検証可能である以上のものではないことある。ドメインは入手が容易で、ほとんど規制されていないから、これはスパムを送る能力に対してほとんど効果がない。アイデンティティーの厳密な証拠を要求するシステムは、ｅメールによって可能になったインフォーマル・コミュニケーションの容易さの多くを取り去る。

全体として、発信元での解決策の追求は、インターネットが設計上オープンでダイナミックなメッシュ構造であるという事実によって失敗しており、結局、スパマーが正当又は不当な方法で参入することを防止することは非常に困難である。

スパムを抑制するための、現在使用されている最も一般的な試みは個々のメッセージの内容に基づくフィルタリングである。スパム・メッセージが一部の製品（「成績を向上させる」薬、ローン、素早い金もうけ計画など）の簡単で悪文の広告を含んだ、伝統的に「ある種のもの」だったから、これは現在のところ比較的成功している。また、それは受信側のｅメールクライアントを含むプロセスの任意の段階でのフィルタリングの実施を可能にするという利点を伴う。

米国特許第５３７７３５４号に開示されたような初期のフィルタリングシステム、及び周知のｅメールクライアント・ソフトウェアに組み込まれた「規則ウィザード」は、受信ｅメールの一般的な構成に基本的なフィルタリングを行うもので、注意深く維持すればそれをスパムに使用できるであろう。スコアリングを使用する、より精巧なルールベースのシステムは、ネットワークの異なる層で多くのスパム・フィルター製品に組み込まれる。米国特許第６６５０８９０号はネットワークレベルで組み込まれるそのような製品を開示している。

米国特許第６１６１１３０号に開示されたようなより最新のコンテンツ・フィルタリング・システムは、スパム及び非スパムｅメールのコーパス（corpora）と比較して、言葉の存在に基づいて、受信したｅメールがスパムである「確率」を判定する統計的手法を使用する。これらの中で最も有名なものはPaul Grahamの「スパムの計画」であり、それはＢａｙｅｓの条件つき確率の定理を使用する。英国特許第２３９６９９３号は「人工知能」技術のさらなる使用を開示している。

各メッセージを単に個々に見ることよりも精巧な技術は、発信されている同一メッセージのボリュームを判断することを試みるためにｅメールフィルター間の共同作業を提供することである。そして、この協力による知識は、より一般的なフィルタリングシステムに通知するために使用される。そのような１つの技術は米国特許第６０２３７２３号及び米国特許第６３３０５９０号に開示されている。米国特許第６４５３３２７号に開示された別の技術は、一旦スパムが１人のユーザによって手動で報告されたら、他の者がそれに自動的に対応することを保証することである。これは、スパムの中核問題であるボリュームそのものにより直接に対処する。チェックのために中央サービスにｅメール全体を送ることを試みるのではなく、これらの「コラボラティブ・フィルタリング」システムは、メッセージ・テキスト自体より容易に送られ比較することができるメッセージの「シグネチャ」又は「ハッシュコード」を生成する。米国特許第６０５２７０９号に記載されたように、偽メール・アカウントが特にスパムを「収穫する」ために作成される場合もある。

すべてのコンテンツ・フィルタリング・システムに関する問題は単に、スパマーがそれらに適合するということである。最初に、彼らは句読点あるいはミススペリングでキーワードを「変装する」基本技術を使用し、その後、ベイズのフィルター技術あるいは協力的なチェックサム・システムを「混乱させる」ために大量の無意味な擬似テキストの挿入に移った。最終的に、スパマーは、個別化され、事実上正当なｅメールと同一の、違いを分別する人間の知能を必要とするｅメールを生成する。すべての形のフィルタリングの本質的な矛盾は、フィルターが厳重なほど偽陰性の可能性が低くなるが、偽陽性のそれは高くなることである。

スパムに対処することを試みる別の一般的方法は、ｅメールの（主張上の）送信者に基づいて受信ｅメールクライアント側でフィルタリングすることであった。これは、他のチェック、あるいはブロックされる送信者の否定の「ブラックリスト」を恐らく回避して、ｅメールが受け入れられる送信者の肯定的な「ホワイトリスト」の形でもよい。周知のｅメールクライアント・ソフトウェアは、これらを両方とも可能にする基本的特徴を含んでいる。ほとんどのフィルタリング解決策（上記参照）は、偽陽性の減少を保証するためにホワイトリスト特徴を提供する。また、ホワイトリストだけの完全支持を与える解決策もある。これは、知らない送信者のハイ・レベルの偽陽性によって非常に低い偽陰性率を達成する厳格な解決策である。

送信者のアドレスが慣例的に偽造されるとすれば、ドメインあるいは全ての国々についての使用は有効でありえるが、個々のアドレスについてのブラックリストの使用は今やすたれつつある。ホワイトリストの成功は、スパマーが受信側のホワイトリスト上にあるであろうアドレスをまだ偽造しないことを必要とするが、ドメインによるアドレスの相関、あるいは受信側のアドレス帳への不正アクセスによって偽造をますます行うことができる。両方の問題は、上記のように、送信者のアドレスのより厳重な認証によってある程度改善できる。

しかし、基本的に、ホワイトリストだけでは、知らない送信者からのｅメールを受け入れないという問題が生じる。ほとんどのユーザにとって、これはコミュニティーからの受け入れがたい程の分離である。しかし、ホワイトリストは依然として、他の技術と組み合わせた有用な要素である。

ホワイトリストにないユーザからｅメールを受け入れる問題の１つの解決策は、送信者が少なくとも人間であり、好ましくは受信者と通信する理由を持つ者であることを証明するように知らない送信者に求めることである。米国特許第６５４６４１６号及び欧州特許出願１３７６４２７号は、これを可能にするチャレンジ・レスポンス（Ｃ−Ｒ）システムを開示している。そのようなシステムでは、知らない送信者からのｅメールは、願わくば人間だけが答えることができる「チャレンジ」で自動的に応対される。これは「キャプチャ」として知られる視覚的又は聴覚的な問題、つまり送信者が受信者と通信する必要がある理由の提示の簡単な要請でよい。

いくつかの無料あるいは有料の製品とサービスがチャレンジ・レスポンスを使用している。そのような製品のいくつかは、チャレンジを扱う中央レスポンスサービスを使用する。

厳重な送信者認証がない状態でのチャレンジ・レスポンスの１つの大きな問題は、チャレンジが偽造アドレスへ送られるということである。最悪のケースで、いくつかのｅメールが同じ偽造された送信者アドレスへ発送された場合、これは、そのアドレスを持った不運な実在の人物に対する「サービスの分配された拒否」（ＤＤｏｓ）攻撃となりえる。少なくとも、それは誤ってチャレンジされた側に混乱と焦燥をもたらす。

チャレンジ・レスポンスの別の問題は、正当なｅメールの送信者が必ずしも人間でないということである。インターネットを頻繁に使用する人々は、注文確認、更新通知及びメーリング・リスト・トラフィックを含むいくつかの自動的に生成されたｅメールを規則的に受け取るかもしれない。最悪のケースでは、低レベルのチャレンジ・レスポンス・システムは、リストからｅメールを受け取るごとに、全メーリング・リストにチャレンジすることになり得る。

しかし、チャレンジ・レスポンスのある形式は、必要によって既存のｅメールシステムと相互作用することができる現実世界の解決策の必須要素である。チャレンジ・レスポンスの一般的な問題の解決策は本発明の目的の１つである。

従来の物理的な「ジャンク」メールがかなり小さな問題なのに対して、インターネット上のスパムがそのような大きな問題である理由の１つは、ｅメールを送るコストが実際上０であるということである。従来の通常の郵便にはもちろん印刷費や発送費があり、経済的に送ることができるボリュームを当然制限する。このため、送信者はアウトプットの対象を合理的にしぼることになり、ほとんどの場合「ジャンク」のボリュームは扱いやすく、歓迎されることさえある。

従って、従来の「スタンプ」に相当するものをｅメールに加えるいくつかの提案がなされている。従来の郵便制度のように、ｅメール配送システム自体がスタンプの存在をチェックすることを必要とする提案もあるが、それはスタンプのないｅメールの受信を単に拒絶するｅメールクライアントによってより容易に実施される。ｅメールを送ることにコストを課すことの利点は、通常の低レベルの送信者を著しく害することなく、スパム送信の経済的意味を直接問うことである。

提案されたシステムにはいくつかの別個の形がある。第１に、従来の郵便料金のようにスタンプのコストは返却不能で、ｅメールに対する直接税となる。ｅメールが伝統的に「無料」だったとすれば、これは一般大衆に恐らく受け入れ可能ではなく、従って、正当なユーザのｅメールを送信するｌＳＰがスタンプすることに依存することになりそうで、それは以前同様にＩＳＰに正当なユーザを識別する問題を単に押しつけることになる。

第２に、ｅメールが望まれない場合、受信者が自由に換金でき、ｅメールが望まれる場合、送信者に払い戻されるようなスタンプに関する提案がある。従って、スタンプはｅメールがスパムでないことの「保証金」の形となる。しかし、受信者が慣例的に保証金を返すか慣例的に換金しなければ、これは複合信託モデル（complex trust model）及びユーザアクションに依存することになる。

第３に、送信者から受信者へ金額を常に移し、ｅメールが受け入れ可能な場合に受信者がその金額を送り返すように仕向ける社会モデルをオプションとして付加する提案がある。そのような１つの提案が米国特許第５９９９９６７号と国際特許出願０３／０５４７６４号に開示されている。これと第２セットの提案の違いは、金額の移転が非スパムのｅメールに対するデフォルトによって発生するか否かのみである。

上記のすべての提案の短所は、ｅメールが送られるか受け取られるごとに、バンキング決済手段との重要な相互作用を必要とするということである。さらに、それはｅメールの送信者と受信者の両方の匿名性を取り除き、それを受け入れられないユーザもありえる。

示唆されたが実施されなかったこの問題の１つの解決法は、受信者によって単に格納することができ、送信するｅメールに再使用できる無記名の電子マネーの形を使用することである。しかし、同じキャッシュの「ダブル支出」をさけるための発行銀行による確認処理、又はダブル支出まで遡る事後追跡を必要とする。後者の場合では、スパマーはとにかく「ダブル支出」して（何百万単位で）から姿を消すに違いない。実際上、広く支持されたディジタル・キャッシュ・インフラストラクチャーは存在せず、ｅメールスタンプのための使用は非現実的である。

従って、本発明は、従来のｅメールの匿名性の喪失、バンキングシステムとの相互作用あるいは全面的な匿名のディジタル・キャッシュ解決を必要とせずに、大量のｅメールを送る貨幣原価の中核前提を保持することを目的とする。

米国特許第６４８４１９７号に開示された別のアプローチは、受信者が、送信者がｅメールを送るために使うことができる自分の「トークン」を発行することである。これは、受信者が送信者を知っている場合以外はうまく行かない。さらに、それは、トークン発行を管理する労力を受信者に要求する。

電子スタンプの「コスト」の代替モデルは提案され、そこでは、あるアルゴリズム的な問題を行なうのに必要ないくつかのマシンサイクルをコストが表わす。この概念はいくつかのプロトタイプ・システムで実施されているが、そのようなアプローチの問題は、一般大衆におけるｅメールの増加使用の邪魔をせずに、資金の潤沢な分散したスパマーにとって非経済的になるように、必要なサイクル数をバランスさせるのが難しいことである。

基本的には、バルクｅメールのための真の貨幣原価だけが十分にスパマーを思いとどまらせることができる。それが必然的に彼らの全ビジネスモデルにダメージをあたえ、従って、現金原価を伴うなんらかの形の電子スタンプは長期に渡って最適な解決策である。一般利用者に「公平」に映るために、受け取るのとほぼ同じ量のｅメールを送る利用者が財政的に影響されるべきでない。

有効なシステムは、ある既知の人々又はサービスがスタンプを必要とせずにｅメールを送ることを可能にするホワイトリストと、まだスタンプを添付していない未知の人々に対処するチャレンジ・レスポンス・システムを含む。さらに、スタンプをどうするべきか知らない受信者にそれを送ることによって価値が失われないことが重要である。

米国特許第６３２１２６７号 米国特許第５３７７３５４号 米国特許第６６５０８９０号 米国特許第６１６１１３０号 英国特許第２３９６９９３号 米国特許第６０２３７２３号 米国特許第６３３０５９０号 米国特許第６４５３３２７号 米国特許第６０５２７０９号 米国特許第６５４６４１６号 欧州特許出願１３７６４２７号 米国特許第５９９９９６７号 国際特許出願０３／０５４７６４号 米国特許第６４８４１９７号

従って、要約すれば、従来技術に教示されるようなこの種の最適システムには次の欠点がある：
１）ｅメールのすべての交換は、バンキングシステムあるいはその類似物を通して送信者から受信者への現金価格の移転を必要とするか、あるいは潜在的に必要とし得る。グローバルなｅメールのボリュームを考えると、これは多目的支払いシステムに対する受け入れがたい処理負担となる。
２）真に匿名のディジタル・キャッシュ・システム以外は、ｅメールの送受信に必要な匿名性を提供することができない。また、そのようなシステムは現在実用的な形で存在しない。
３）技術の大規模な切替えを必要とせずに有効なシステムを作ることは、システムが当初スタンプを理解しない既存のｅメールクライアント及びメールサーバと共同で作動することを要求する。

バンキング支払いシステム又はディジタル・キャッシュ・インフラストラクチャーへの連続的なアクセスに依存せず、しかも受信とほぼ同数のｅメールを送るユーザが純コストなしでそれを続けることを可能にする有効な電子スタンプシステムの必要性がある。また、管理外のチャレンジの落とし穴のいくつかを回避する、管理されたチャレンジ・レスポンス・システムを含むシステムの必要性もある。

発明の要約
本発明の１つの態様は、中央当局である許可証発行当局（ＰＩＡ）によって生成される再使用可能なメール許可証（ＲＭＰ）のシステムに関する。ＲＭＰは、貨幣価値等の表示、満期期限、発行ＰＩＡ及び他の「管理」情報が並記される大きな独自番号からなる。ＲＭＰは無記名である。

具体的には、本発明の態様は次のことができる：
１）発信ｅメールに再使用可能なメール許可証を生成、購入及び添付するメカニズムを提供する。
２）十分に価値のある有効で、固有で、再使用可能なメール許可証が着信ｅメールに添付されていることを検証する。
３）本格的なエレクトロニック・バンキングやディジタル・キャッシュ・システムを必要とせずに、同じ再使用可能なメール許可証の多重使用による不正行為を防止しながら、受け取った再使用可能なメール許可証の、後で発信するｅメールの受信者による単一再使用を可能にする。
４）ある特別待遇の送信者に再使用可能なメール許可証を自動的に返す。
５）再使用可能なメール許可証の値のいくらか又は全てを償還して、キャッシュあるいは製品又はサービスの中へ転換することをオプションで許可する。
６）再使用可能なメール許可証を添付できないか添付しない既知の送信者の「ホワイトリスト」を提供する。
７）再使用可能なメール許可証を添付していない未知の送信者との通信プロセスを慎重に管理して、送信者に次のものどちらかを可能にする：
ａ）手作業でホワイトリストに加えられる。
ｂ）現在のｅメールと後のｅメールに再使用可能なメール許可証を添付する手段を取得する。

発明の１つの態様によれば、受信者の代理であるｅメールクライアントによるｅメールの受信を規制する方法が提供され、その方法は以下のステップからなる：
・ｅメールクライアントによってｅメールサーバから最初のｅメールを受信し、
・前記最初のｅメールに添付された再使用可能なメール許可証の存在をチェックし
・再使用可能なメール許可証が添付されていない場合に、前記最初のｅメールに対して第１の処置を行い、
・再使用可能なメール許可証が添付されていれば、再使用可能メール許可証発行サービスに前記再使用可能なメール許可証の検証を要請し、
・再使用可能メール許可証発行サービスが前記再使用可能なメール許可証の検証を拒否すれば、最初のｅメールに対して第２の処置を行い、
・再使用可能メール許可証発行サービスが前記再使用可能なメール許可証の検証を許可すれば、前記最初のｅメールを受信者に送達し、
・前記再使用可能メール許可証発行サービスから、送達されたｅメールの前記再使用可能なメール許可証の更新を要請し、そして
・更新された再使用可能なメール許可証を、後の送信ｅメールに添付するために保管する。

発明の他の態様によれば、送信者による受信者へのｅメールの送信と受信者によるｅメールの受信を規制するシステムが提供され、そのシステムは以下を備える：
・送信者からの発信ｅメールを受け入れるよう構成された第１送信手段、
・発信ｅメールを遠隔の宛先へと送るよう構成された第２送信手段、
・遠隔の発信元からの着信ｅメールを受け入れるよう構成された第１受信手段、
・着信ｅメールを受信者へと送達するよう構成された第２受信手段、
・少なくとも１つの再使用可能なメール許可証を格納するよう構成された許可証格納手段、
・許可証格納手段から取り出した少なくとも１つの再使用可能なメール許可証を、第１送信手段に受け入れられた第２送信手段に送る前の発信ｅメールに添付するよう構成された添付手段、そして
・第１受信手段で受け入れられた第２受信手段に送達される前の着信ｅメールから少なくとも１つの再使用可能なメール許可証を抜き出して検証し、抜き出した再使用可能なメール許可証を許可証格納手段に格納するよう構成された抜き出し手段。

ＲＭＰは、通常のｅメールクライアントの一部あるいはその代理として送信者のコンピュータに常駐の許可証マネージャー（ＰＭ）によって発信ｅメールに添付される。あるいは、インターネットにおいて一般的なように、ＰＭは中央のサーバに遠隔にインストールされてもよい。受信したＰＭは、変造、十分な価値、受入れ可能な発行者及び満期期限のチェックを含む受入れ可能性のそれ自身のチェックを行い、次に、ｅメールを受け入れる前に、発行ＰＩＡとともに受信したＲＭＰの有効性を検証する。ＲＭＰの検証の要請を受けると、ＰＩＡはそれを使用済みとマークし、それを有効にするそれ以上の要請に応じない。また、ＰＩＡは同じ価値の交換用ＲＭＰの生成を開始し、それは検証するＰＭによって受け取れ、後の発信ｅメールでの使用のために保管される。検証と収集の要請は、ＲＭＰ（又は同じ発行者からの他のＲＭＰ）からの独自番号を使用して、ＰＭによって考案された独自の収集コード、及び任意の構成要素によって関連付けられる。任意に、ＰＭは、交換用ＲＭＰを添付して、着信ｅメールに自動的に返信してもよい。

このように、送信するｅメールとほぼ同じ数を受信するユーザは、ｅメールに「課税」されない。受信者にも、メーリング・リストのような受入れ可能なバルク送信者にｅメール送信コストを払い戻すオプションがある。受信者が多数のＲＭＰを蓄積する場合、要請に応じて、ＰＩＡは１つ以上のＲＭＰの値の一部又は全部に対して、現金、製品あるいはサービスで償還する便宜を提供してもよい。ＰＩＡは、管理用に新しいＲＭＰの購入の継続的な必要性を確保し、任意にその活動に対する資金調達を助けるために、ＲＭＰに満期を適用してもよい。

ｅメールが有効なあるいは十分なＲＭＰなしで受信され、送信者が、許可された非ＲＭＰ送信者の「ホワイトリスト」の中にない場合、チャレンジｅメールが返される。オリジナルのｅメール中のヘッダーによって示されるように送信者がＰＭをインストールしているが、受信者がそれを要求することを知らなかったために送信者がＲＭＰを添付しなかったか、価値が不十分なものを添付した場合、チャレンジｅメールは機械可読で、十分な価値のＲＭＰが添付されたｅメールの自動再送をトリガーする（手動確認用のしきい値に従う）。

送信者がＰＭをインストールしていない場合、チャレンジｅメールは人が読めるもので、送信者に２つの可能な行為を示す：
１）十分なＲＭＰを自動的に提供するＰＭを入手してインストールする方法についての指示、
２）（受信者の意向で）受信者が、許可された無ＲＭＰの送信者のホワイトリストにその送信者を追加すべき理由を送信することの要請。

後者の場合、ホワイトリストに加わる要請の要約がユーザに定期的に提示され、提示された情報にもとづいて許可又は却下を決めることができる。両方の場合、受信機は、チャレンジに対するレスポンスを待つ着信ｅメールをキューに入れ、適切なものが受信すればそれを送達する。

偽造された送信側アドレスがチャレンジであふれることや、明白なスパムに対してチャレンジを送信することを回避するため、チャレンジｅメールの送信は、ＰＩＡの一部又は独立した業務であり得るレスポンス管理サービス（ＲＭＳ）との通信を通じて規制される。受信側ＰＭは受信ｅメールについて記述するシグネチャ項目をＲＭＳに送り、それはそれらを他のＰＭからのシグネチャと比較することにより下記の是非を決定し、ＰＭに決定することができる：
ａ）チャレンジは直ちに送るべきか
ｂ）ｅメールを無視すべきか
ｃ）ｅメールはユーザに送達するべきか
ｄ）ｅメール全体を含んでそれに至る詳細をＲＭＳに送るべきか
ｅ）他のＰＭからの詳細を入手する及び／又はＲＭＳの多忙さが緩和するまで質問を延期すべきか。

発明の他の態様によれば、受信者によるｅメールの受信を規制するシステムが提供され、そのシステムは以下を備える：
・遠隔の発信元からの着信ｅメールを受け入れるよう構成された第１受信手段、
・着信ｅメールを受信者へと送達するよう構成された第２受信手段、
・少なくとも１つの再使用可能なメール許可証を格納するよう構成された許可証格納手段、そして
・第１受信手段で受け入れられた第２受信手段に送達される前の着信ｅメールから少なくとも１つの再使用可能なメール許可証を抜き出して検証し、抜き出した再使用可能なメール許可証を許可証格納手段に格納するよう構成された抜き出し手段。

発明の他の態様によれば、送信者による受信者へのｅメールの送信を規制するシステムが提供され、そのシステムは以下を備える：
・送信者からの発信ｅメールを受け入れるよう構成された第１送信手段、
・発信ｅメールを受信者に送るよう構成された第２送信手段、
・少なくとも１つの再使用可能なメール許可証を格納するよう構成された許可証格納手段、そして
・許可証格納手段から取り出した少なくとも１つの再使用可能なメール許可証を、第１送信手段に受け入れられた第２送信手段に送る前の発信ｅメールに添付するよう構成された添付手段。

発明の他の態様によれば、送信者と受信者の間のｅメール通信を規制するシステムが提供され、そのシステムは、受信者への発信ｅメールに再使用可能なメール許可証を添付する送信者側の手段を備え、送信者が、再使用可能なメール許可証を持たない受信ｅメールをブロックし、かつ再使用可能なメール許可証を持った受信ｅメールから前記再使用可能なメール許可証を抜き出すよう構成され、前記抜き出された再使用可能なメール許可証が、再使用可能メール許可証発行当局によって確認されれば交換され、後で受信者によって他の受信者へ送られる発信ｅメールへの添付用として保管される。

発明の他の態様によれば、送信者から受信者へのｅメールの送信及び受信者によるｅメールの受信を規制するコンピュータソフトウエアプログラムが提供され、そのプログラムが送信者から受信者への発信ｅメールに再使用可能なメール許可証を添付するよう構成され、そのプログラムがさらに、他の送信者からの再使用可能なメール許可証を持たない受信ｅメールをブロックするよう構成され、受信者が、受信ｅメールから再使用可能なメール許可証を抜き出し、再使用可能なメールを後で受信者によって他の受信者へ送られる発信ｅメールへの添付用として格納することができる。

図面の簡単な説明
以下、本発明の実施例を例としてのみ、添付図を参照して説明する。
図１は、ｅメールを送受信し、再使用可能なメール許可証を添付・検証するプロセスの主構成要素を示すブロック図である；
図２は、再使用可能なメール許可証の１つの考え得る内容とフォーマットを示す構成図である；
図３は許可証マネージャーの構成要素を示すブロック図である；
図４は、２つの許可証マネージャー対応ｅメールクライアント間の通常の成功するｅメール送信用の構成要素間のメッセージのシーケンス及び流れを示すＵＭＬシーケンス図である；
図５は、以前に通信したことのない２つの許可証マネージャー対応クライアント間のｅメールの配信用の構成要素間のメッセージのシーケンス及び流れを示すＵＭＬシーケンス図である；
図６は、当初非許可証マネージャー対応クライアントと許可証マネージャー対応クライアント間のｅメールの配信用の構成要素間のメッセージのシーケンス及び流れを示すＵＭＬシーケンス図である；そして
図７は、許可証発行当局の構成要素を示すブロック図である。

好適実施例の詳細な説明
以下、本発明の詳細なアーキテクチャーと動作を、図面の詳細な説明を通して開示する。
図１は発明の主構成要素を示す。構成要素１００，１０１，１０２，１０３，１０４，１０５，１０６は、既存のグローバルなｅメールシステムの通常の要素である。構成要素１０７，１０８，１０９，１１０（網掛け）は本発明が必要とする追加の構成要素である。

構成要素は、インターネット１００、あるいは未知の送信者からのｅメールの受信が規制される他の公的又は私的ネットワークによって互いに接続する。ｅメールは、業界において広く利用可能なような受信側ｅメールクライアント１０１によって受信される。ｅメールは、業界標準ｅメールプログラムでもあるｅメールクライアント１０２及び１０３と、スパマーの管理下の少なくとも１つの大量ｅメール送信システム１０４によって送られる。説明の目的で、ｅメールクライアント１０２、１０３を送信側、ｅメールクライアント１０１を受信側とするが、実際上、種々の時点ですべてのクライアントが送信側と受信側の両方になる。しかし、バルク送信者１０４は多くの場合ｅメールを受信することができない。

説明の目的で、ｅメールクライアント１０２は、本発明を実施するソフトウエアをインストールした正当な送信者に管理されると仮定し、ｅメールクライアント１０３は、必要なソフトウエアをインストールしていないが、バルク送信者１０４と異なり、受信側ｅメールクライアント１０１の所有者が正当な通信者であると考える送信者に管理されると仮定する。

ｅメールは一般に、ＳＭＴＰのような送信者に開始されるプロトコルによって、発信側のｅメールクライアント１０２、１０３及びバルク送信機１０４から送られ、０、１つ又はそれ以上の「スマートホスト」メールサーバ１０５を通して宛先メールサーバ１０６に配送され、そこに格納され、そこから一般にＰＯＰ３又はＩＭＡＰのような受信者に開始されるプロトコルを介して受信側ｅメールクライアント１０１によって取り出される。配信プロトコル及びメールサーバの別の構成は一般的で、当業者には明白であり、ｅメールクライアント間の末端間方式で作動する本発明にとって重要ではない。

ｅメールクライアント１０１、１０２が送受信するすべてのｅメールは許可証マネージャー（ＰＭ）１０７、１０８を通されるが、それはｅメールクライアント１０１、１０２に組み込まれてもよく、又はそれらの代理として働き、送受信されるｅメールを傍受し、それらに作用し、格納及び／又は修正し、それらの宛先へ転送する。

ＰＭ１０８は、発信されるｅメールへの添付用として再使用可能なメール許可証（ＲＭＰ）を得るために１つ以上の許可証発行当局（ＰＩＡ）１０９と通信する。典型的な実施例で、ＲＭＰは、価値、満期期限、発行ＰＩＡ及び他の「管理」情報の表示に加えて大きな独自番号からなる。この典型的な実施例は、ＲＭＰが無記名であるという長所を持つ。好適実施例では、巡回冗長検査（ＣＲＣ）又は周知の検証可能な冗長性の他の形が、検証を助けるためにＲＭＰの一部として含まれる。ＲＭＰの構造とフォーマットは以下でより完全に開示する。

ＲＭＰが添付されたｅメールを受信すると、ＰＭ１０７はＰＩＡ１０９と通信して、受け取ったＲＭＰを検証し、取替物を得、格納して、後で発信するそれ自身のｅメールに使用する。

ＲＭＰが添付されていないｅメールを受信すると、ＰＭ１０７は、送信者が許可された非ＲＭＰ送信者のホワイトリストに載っているかどうかチェックし、載っていれば、通常のものとしてｅメールを送達する。そうでなければ、受信したｅメールへの返信について助言を得るためにレスポンス管理サービス（ＲＭＳ）１１０と通信する。それは以下に開示されるようなチャレンジｅメールの送信を含んでもよい。

図２は、ＲＭＰ２００の典型的な内容とフォーマットを示すデータ構造図である。構造は６４バイト（５１２ビット）の２値ブロックとして示すが、他のデータサイズ及びフォーマットが可能で、当業者によって容易に設計される。２の累乗のサイズ及び構造内のフィールドの４バイトの整列を選ぶことに、特にハードウェアでの実施に利点と効率がある。「予備の」フィールドが将来の拡張に備えて残されている。ＲＭＰ値２０１は固定値であり、それは一般的なプロトコル内のＲＭＰのタイプ及びバージョンを識別するために使用することができる。テキスト字「ＲＭＰ１」の使用は一例で、デバッグとプロトコル分析を助ける。

フラグ・フィールド２０２は、表２１０で定義されたような個々のフラグ及び小さなフィールドのビットマップである。本発明では、次のフラグ及びフィールドが割り付けられている。

引換え可能フラグ２１１は、ＲＭＰが引換え可能かどうかを示す。永続フラグ２１２は、ＲＭＰの満期が更新で延長されるか、又はそれがＲＭＰの存続期間に固定されているかどうかを示す。使用回数フィールド２１４は、ＲＭＰの最大使用回数を示す。０の値は、使用が全体的な満期を条件に無制限であることを示す。

残りのフラグ２１３は、さらなる拡張用のデフォルトとしてゼロに設定されている。

独自ＩＤフィールド２０３は、発行ＰＩＡによって割り付けられる３２バイト（２５６ビット）の独自番号である。ＩＤは無作為に発行してもよいが、ＰＩＡは、同じ値の２つのＩＤが同時に存在しないことを保証しなければならない。ＰＩＡの好適実施例で、ＰＩＡは、ルックアップの効率を向上させるためにＩＤの初めの３２ビットが一意的であることを保証し、偽造を防ぐために冗長検査としてランダムデータを残りの２２４ビットに当てる。

満期時刻フィールド２０４は、Ｕｎｉｘの「ｔｉｍｅ＿ｔ」フォーマットで６４ビットのタイムスタンプとして、すなわち１９７０年１月１日の協定世界時の真夜中からの秒数でＲＭＰの満期を定める。このフォーマットは最大の一般法則を提供するが、他のフォーマットも可能で、当業者には明白である。タイムスタンプを現地時間ではなく協定世界時（ＧＭＴ）にすることによって、異なる時間帯のクライアント間の正確な動作を可能にする。

値フィールド２０５は、ある通貨の端数、例えばＵＳＤ０．００００１又はＥＵＲ０．００００１、の整数倍としてＲＭＰの値を定める。この端数の選択は、３２ビットのフィールド内で表わすことができる値の最大有効範囲を保証する。典型的な実施例では、値フィールドは、発行ＰＩＡの協力を通じて維持され、従来の国際通貨の固定又は変動為替相場に従う「仮想通貨」の値を表わす。これはＲＭＰの国境を挟む交換を容易にする。

発行者ＩＤフィールド２０６は、どのＰＩＡがＲＭＰを発行したかを示し、その更新又は回復のためのネットワーク・アドレスを得るために中央で維持されるＰＩＡの表で検索することができる。好適実施例では、この表はＤＮＳ又はＸ．５００分散型データベースに保持される。

予備フィールド２０７、２０８は将来の拡張用に設けられ、構造を６４バイト当てるために、本バージョンで０のデフォルトにセットされる。

ＣＲＣフィールド２０９は、ＲＭＰデータの残りにおけるエラーに対するチェックを提供する。典型的な実施例で、ＣＲＣはＲＭＰデータ・ブロックの残り部分にわたって標準ＣＣＩＴＴ ＣＲＣ−１６アルゴリズムで計算される。

図３は、許可証マネージャー（ＰＭ）１０７、１０８の典型的な実施のブロック図である。許可証マネージャーの定義は機能的で、ここに説明する構造によって限定されるものではない。

許可証マネージャー１０７、１０８は、発信するｅメールにＲＭＰを加え、着信するｅメール上のＲＭＰをチェックする許可プロセッサ３０１を備える。許可プロセッサ３０１は、メモリに、ディスクファイル上で、あるいは従来のデータベース・サブシステムに保持され得る３つのデータベース３０２、３０３、３０４を利用する。受信者データベース３０２は、ＰＭをインストールしていることがわかっている個々の受信者の情報をｅメールアドレスによって入力されて保持している。好適実施例で、受信者データベース３０２は、さらに各受信者の公開キーを含む。さらなる好適実施例で、受信者データベース３０２はさらに受信者に受入れ可能な最小のＲＭＰ値２０５を含む。さらに別の好適実施例で、受信者データベース３０２は受信者に受入れ可能なＲＭＰフラグ２０２を含む。

ＲＭＰデータベース３０３は、ＰＭに利用可能なＲＭＰをすべて保持する。収集リスト３０４は、後でより完全に述べるような取替ＲＭＰの検索で使用される、収集コードと対応データのリストを保持する。

ローカルのｅメールクライアント１０１、１０２と通信するのはローカルメール受信機３０５とローカルメール送信機３０６である。ローカルのメール受信機３０５は、ローカルｅメールクライアント１０１、１０２に着信したｅメールを送達する手段を提供する。典型的な実施例で、これはＰＯＰ３又はＩＭＡＰを介するような、クライアントに開始されるポーリングによってある。しかしＳＭＴＰによる直接配信又は「ＩｎＢｏｘ」への直接配信を含む他の構成も可能で、当業者には明白である。

ローカルメール送信機３０６はローカルｅメールクライアント１０１、１０２からの発信ｅメールを受け入れる。典型的な実施例で、これはＳＭＴＰを介するが、他の構成も可能で、当業者には明白である。

外部世界のメールサーバと通信するのは、グローバルメール受信機３０７とグローバルメール送信機３０８である。グローバルメール受信機３０７は、外部メールサーバ１０６から届くｅメールを受信する手段を提供する。典型的な実施例で、受信はＰＯＰ３によって行なわれる。別実施例で、受信はＳＭＴＰによって行なわれる。他のプロトコル及び機構も可能で、当業者には明白である。

グローバルメール送信機３０８は、外部の「スマートホスト」メールサーバ１０５に、又は直接宛先メールサーバ１０６に、あるいは示されない他の中間サーバを介して発信ｅメールを送達する。典型的な実施例で、この送達はＳＭＴＰによって行なわれが、他のプロトコル及び機構も可能で、当業者には明白である。

ＰＩＡインターフェース３０９は、ＰＭ１０７、１０８とＲＭＰ発行ＰＩＡ１０９の間の処理を管理する。これらの処理は、２進メッセージ、ＸＭＬメッセージ、ＣＯＲＢＡリクエスト、ＳＯＡＰリクエスト、周知の他の分散型システム技術で通信することができる。好適実施例で、これらの処理は、ＰＭへ構成されたか、ＤＮＳ又はＸ．５０９証明チェーンのような他の信頼された手段を介して得られた公開キーを使用して、ＲＳＡのような公開キー暗号方式で暗号化される。

ＲＭＳインターフェース３１０は、ＰＭ１０７、１０８とＲＭＳ１１０の間の処理を管理する。これらの処理は、上記のＰＭとＰＩＡの間の処理のように通信し、暗号化するここができる。別実施例で、ＰＩＡ及びＲＭＳインターフェースは全く同一である。

未決メールデータベース３１１は、最近送られたｅメール・メッセージであって、再送が必要となるチャレンジを受け得るもののデータベースである。典型的な実施例で、ｅメールはＲＦＣ２８２２メッセージＩＤによってデータベースに入力される。送り側のｅメールクライアントが有効なメッセージＩＤを提供しなければ、メールサーバの標準の行為として、ＰＭはそれを作り、それを発信されるｅメールに添付する。ｅメールは、無事に送達されたと考えられ、削除されるまで、設定可能な期間このデータベースに維持される。

図４は、２つのＰＭ対応のｅメールクライアント間のｅメールの通常の配信用構成要素間のメッセージのシーケンス及び流れを示す単純化されたＵＭＬシーケンス図である。

図はプロセスの抽象的概念を示す。構成要素間の、及び構成要素内のメッセージは、ダイレクトコール、ＳＯＡＰ、ＣＯＲＢＡ、Ｊａｖａ ＲＭＩ、ＤＣＯＭ、．ＮＥＴ、ＨＴＴＰ、ＸＭＬメッセージ、ＡＳＮ．１メッセージ、他の標準化された又は所有権を主張できるテキスト又は２進のプロトコルを非限定的に含む、周知のメッセージ送信又はリモート・プロシージャ・コール（ＲＰＣ）技術で実施することができる。

典型的な実施例のために、ＰＭは個別の構成要素として示すが、ＰＭの一方又は両方がそれぞれのｅメールクライアントに組み込まれ、ＰＭとｅメールクライアントが通常の手続きコールを通じて通信する場合、プロセスは同様に適用可能である。

そのプロセスは送信側ｅメールクライアント１０２が４０１でｅメール送信することで開始する。図示の典型的な実施例で、送信側ＰＭ１０８は、ｅメールクライアントの代理として働き、他の「スマート」メールサーバのようにローカルメール送信機３０６でＳＭＴＰによってｅメールを受け入れる。送信側ｅメールクライアント１０２は、送信側ＰＭ１０８経由でｅメールを送信するよう手動であるいは自動的に設定されてもよい。あるいはローカルコンピュータ又はネットワークが、クライアントに知らせずにＰＭへＳＭＴＰトラフィックを転送するように構成されてもよい。両方の技術はｅメールウィルスチェックに関する技術において周知である。他のｅメール配達プロトコルのｅメールを傍受し修正する方法は、関連するプロトコルの当業者にとって明白であろう。

送信側ＰＭの最初のステップ４０２は、受信者データベース３０２中のｅメール受信者を調べることである。考え得る３つのケースがある：
１）受信者がＰＭをインストールしていると考えられる
２）受信者がＰＭをインストールしないと考えられる
３）受信者に関してそのいずれもわからない

第１ケースは図４に示すケースである。好適実施例で、受信者がＰＭを持つと考えられることを判断すると、送信側ＰＭ１０８は、ｅメールの受信を許可するのに受信者が必要とするＲＭＰの最小値に関する受信者データベース３０２の情報をチェックする。好適実施例で、送信側ＰＭ１０８は、受信者によって要求されるＲＭＰフラグについての情報をもチェックする。

次のステップ４０３はＲＭＰデータベース３０３から適切なＲＭＰ２００を取り出すことである。送信側ＰＭが十分に価値のある有効なＲＭＰ、及び／又は利用可能なフラグ・セッティングを持つと仮定すると、次のステップ４０４は、ＲＭＰデータベース３０３からそれを取り外し、ｅメールにそれを添付することである。好適実施例で、値は多数のより小さなＲＭＰで構成されてもよい。以下で言及する単数のＲＭＰはすべて複数を含むと理解するべきである。より好適な実施例で、添付されたＲＭＰは、送信が拒絶され、ＲＭＰを回復する必要が生じる場合に備えて、別のデータベースに格納するか、あるいは使用済みと一時的にマークする。ＳＭＴＰを使用する典型的な実施例で、ｅメールへのＲＭＰの添付は、１６進又はＢａｓｅ６４又は他の周知の符号化法などの、ＲＭＰデータのテキスト符号でＲＦＣ２８２２拡張ヘッダーを挿入することにより行なわれてもよい。ｅメール・メッセージにＲＭＰを添付する他のプロトコル特異な方法は、関連するプロトコルの当業者にとって明白であろう。

より好適な実施例で、受信側ＰＭ１０７のための公開キーも第１ステップ４０２で受信者データベース３０２で検索され、ＲＭＰは、ｅメールへの添付前にＲＳＡのような公開キー暗号方式又は他の周知のもので、この公開キーで暗号化される。さらに好適な実施例で、ＰＩＡでの処理要件を減らし予測可能なプレーンテキストを取り除くために、ＲＭＰの独自のＩＤ２０３だけが公開キーで暗号化される。

ＲＭＰデータベース３０３に利用可能な十分な値のＲＭＰがなければ、エラーがユーザに返され、より多くのＲＭＰを購入する必要があることが通知される。典型的な実施例で、これは、ローカルメール受信機３０５を経由して返されるｅメールの形をとる。十分なＲＭＰが利用可能になるまで、オリジナルのｅメールは未決メールデータベース３１１に格納される。ユーザが追加のＲＭＰ購入するか（後述）、ＲＭＰが着信ｅメールから到着すれば、ＰＭは未決ｅメールを検索し、送信プロセスを再開する。

すべての場合に、送信側ＰＭの次のステップ４０５は、ｅメールにＰＭデータを添付して送信側ＰＭの存在を示すことである。典型的な実施例で、これはＲＦＣ２８２２拡張ヘッダーの添付により行なわれる。暗号が使用される好適実施例で、ＰＭデータは送信側ＰＭの公開キーをも示す。ｅメールを受け取るための最小値及び／又はＲＭＰのフラグ・セッティングが加えられるさらに好適な実施例では、これもＰＭデータで示される。

より好適な実施例（図示せず）で、ＲＭＰがそれに関する古すぎるデータのため、例えば受信側ＰＭ１０７が要求するＲＭＰの最低値のため、受信側ＰＭ１０７によって拒絶される場合に備えて、送信側ＰＭ１０８は常に未決メールデータベース３１１にｅメールを格納する。この場合、送られたｅメールは、返されるエラー用の妥当な期間の後に未決メールデータベース３１１から削除される。

送信側ＰＭ１０８にとっての最終ステップ４０６は、グローバルメール送信機３０８を介して、ＳＭＴＰのような標準のｅメール機構を使用して、修正済のｅメールをその宛先へ送ることである。ステップ４０６は、それがいくつかの中間のメールサーバ１０５、１０６を関与させるかもしれないため、点線で非同期のように示されている。受信側ＰＭ１０７は、ＳＭＴＰ自体によってｅメールを受け取ってもよく、あるいは、より普通に宛先メールサーバ１０６がＳＭＴＰによってそれを受け取り、受信側ＰＭ１０７がＰＯＰ３又はＩＭＡＰのような受信者が開始するプロトコルを使用してポールするまでそれを格納する。そのようなｅメールの配信のプロトコル及び機構とその変形は周知であり、本発明の一般法則に重要でない。

受信側ＰＭの最初のステップ４０７は、ｅメールからＲＭＰ又はＲＭＰ２００（もしあれば）を抜き出すことである。ＳＭＴＰを使用する典型的な実施例で、これは、４０４で挿入された拡張ヘッダーの抜き出し及び解読により行なわれてもよい。ＲＭＰが暗号化されるより好適な実施例では、このステップは受信側ＰＭ１０７のプライベートキーでＲＭＰを解読することをさらに含む。

受信側ＰＭ１０７の次のステップ４０８は、それ自身の情報を使用して可能な限りで、各ＲＭＰの一応の受入れ可能性をチェックすることである。これは次のものを含む：
１）ＣＲＣ２０９を使用して、ＲＭＰが不正でないかチェック
２）フォーマット・フィールド２０１を使用して、ＲＭＰが正しいタイプ及びバージョンであることをチェック
３）フラグ・フィールド２０２を使用して、ＲＭＰが受入れ可能なフラグを持つことをチェック
４）満期時刻フィールド２０４を使用して、ＲＭＰが期限切れでいないことをチェック
５）値フィールド２０５を使用して、ＲＭＰ値がｅメールの受信を許可するのに十分であることをチェック
６）発行者ＩＤフィールド２０６を使用して、ＲＭＰが受入れ可能な発行者のリストにある受入れ可能な発行者によって発行されたことをチェック

それぞれの場合で、受入れ可能性チェックが不可なら、ｅメールは削除され、エラーメッセージが送信者に返信されてもよい。これは以下でより完全に開示されるようなＲＭＳ１１０による管理に従う。好適実施例で、受入れ可能性チェックが不可なら、機械可読のメッセージが返され、それは不可の理由を示し、より適切なＲＭＰを添付してｅメールを再送し、オリジナルのｅメールに添付されたＲＭＰを回復する機会を送信側ＰＭ１０８にあたえる。

より好適な実施例で、受信者によって拒絶されるＲＭＰの損失を回避するために、送信側ＰＭ１０８は、発送したＲＭＰをすべて記録し、それらが拒絶されれば、ＲＭＰデータベース３０３にそれらを戻す。さらに好適な実施例で、受信側ＰＭ１０７が不正にＲＭＰを拒絶しながらそれを再使用することを防ぐために、送信側ＰＭ１０８は、受信者によって拒絶されるあらゆるＲＭＰの再検証を発行ＰＩＡに要求する。

ＲＭＰが受信ＰＭ１０７に一応受入れ可能に思える場合、次のステップ４０９は発行ＰＩＡ１０９とＲＭＰを検証することである。典型的な実施例で、受信側ＰＭは、時々リフレッシュされ得る内部の表中のＲＭＰの発行者ＩＤフィールド２０６からの発行ＰＩＡのネットワーク・アドレスを調べる。より好適な実施例で、受信側ＰＭは、グローバルドメイン名システム（ＤＮＳ）又はＸ．５００のような分散型データベース中の発行者ＩＤ２０６を調べる。ＤＮＳの場合には、受信側ＰＭは「１２３４５．ｉｓｓｕｅｒｓ．ｒｍｐ．ｎｅｔ」のようなアドレスを調べることができる。「１２３４５」は発行者ＩＤフィールド２０６の値で、「ｉｓｓｕｅｒｓ．ｒｍｐ．ｎｅｔ」は、この目的のためにＰＭへ登録され構成された任意のＤＮＳドメインである。

発行ＰＩＡ１０９のアドレスを得ると、受信側ＰＭ１０７は発行ＰＩＡによるＲＭＰ２００の検証を要求する。受信側ＰＭは、検証のために発行ＰＩＡにＲＭＰ全体を送る。典型的な実施例で、受信側ＰＭは、後で行う交換ＲＭＰの受け取り要請が一意的に識別されるような受け取り用コードをも送る。ＰＩＡではなくＰＭによる受け取り用コードの指定は、メッセージの紛失又は失敗が生じても、ＰＩＡからの返送を必要とせずにＰＭが処理を再び試みることができるから、よりよい回復が可能になる。好適実施例で、受け取り用コードは大きく、一意的で、偽造不可能な数であり、それは、チェックされているものと同じ発行者ＩＤを持つ、ＰＭが所持するＲＭＰの初めの３２ビットのような独自性の要素と、３２ビットの乱数のような任意の要素を含んでいる。さらに好適な実施例で、ＰＩＡからの返答メッセージを確保できるように、受信側ＰＭはその公開キーをも送る。さらに別の好適実施例では、受信側ＰＭは、処理用として対称なセッションキーを考案し、これをＰＩＡの公開キーで暗号化して、最初の検証リクエストとともに送る。そして、このセッションキーはＲＭＰ自体と後の受け取り要求及びレスポンスの両方を暗号化するのに使用することができ、ＰＩＡの作業負荷をさらに減らすことになる。公開キー基盤を使用してセッションキーを設定する他の方法は周知である。

ＲＭＰ２００の検証の要請を受けると、発行ＰＩＡ１０９は、提出されたＲＭＰの受入れ可能性のそれ自身の一応のチェックを行うことができる。提出されたＲＭＰが受入れ可能に思われ、このＰＩＡによって発行されたことをチェックすると（発行者ＩＤ２０６のチェックによる）、発行されたＩＤの内部データベース中の独自ＩＤ２０３を調べる。独自ＩＤ２０３の最初の３２ビットが一意的であることを保証する好適実施例で、ＰＩＡは、ルックアップ・キーとしてこれを２５６ビットＩＤ全体を探索するより効率的に使用することができる。ルックアップ・プロセスの典型的な実施例では、データベースに保持されたＩＤの数に関係なくルックアップ時間をほぼ一定にするために、少なくとも１つのハッシュ表が使用される。

独自ＩＤ２０３を調べた後、ＰＩＡは、提出されたＲＭＰ２００全体を独自ＩＤで示されたデータベースに格納されたコピーと対比する。提出されたＲＭＰと格納されたＲＭＰがあらゆる点で同一の場合のみ、提出されたＲＭＰが有効であると考える。このチェックは、有効期間中にＲＭＰのフィールドのいかなる変更も、例えば失効期日や値の変更を防止する。

ルックアップ及びブロック比較が非常に効率的な本発明の別実施例で、ＲＭＰ全体の比較がどんな場合もその有効性を検証するのに十分であるので、一応のチェックは省略される。

提出されたＲＭＰがデータベースに存在し修正されていない場合、発行ＰＩＡ１０９は受信側ＰＭ１０７に成功の知らせを返信する。好適実施例で、この成功の知らせは、受信側ＰＭが交換ＲＭＰを受け取ることのできる時の表示を含む。この時は、交換ＲＭＰを発行する際にその負担を分散させるために、発行ＰＩＡによって変えられことがある。より好適な実施例で、成功の知らせは、受け取り用の新しい発行者ＩＤをも含む。これは発行ＰＩＡが、過負担又は差し迫った一時休止の理由で、必要に応じて別の発行ＰＩＡにその作業を渡すことを可能にする。

提出されたＲＭＰが一応受入れ不可か、データベースに存在しないか、発行されて以来変更された場合、失敗の知らせが受信側ＰＭ１０７へ返信され、エラーが人為調査に付される。この種の失敗の繰返しは、システム上の不正行為の試みを示し得る。

さらなる好適実施例で、ＰＭ１０７、１０８と発行ＰＩＡ１０９の間のすべてのやり取りは、ＲＳＡのような公開キー暗号方式の下で発行ＰＩＡの公開キーで暗号化される。これは、発行ＰＩＡのネットワーク・アドレスの場合ように、内部の表から、あるいはＤＮＳのような分散型データベースの検索によって決定することができる。別実施例では、すべてのやり取りが、発行ＰＩＡの公開キーを使用して設定される対称なセッションキーによって暗号化されて行なわれる。公開キーインフラストラクチャを使用して、対称なセッションキーを設定するそのような機構は周知である。

さらに別の好適実施例で、発行ＰＩＡ１０９とＰＭ１０７、１０８の間のすべてのやり取りは、ＲＳＡのような公開キー暗号方式の下で問題のＰＭの公開キーで暗号化される。それはステップ４０９で受け取られたメッセージから検索することができる。別の好適実施例で、発行ＰＩＡとＰＭの間のすべてのやり取りは、一時的な対称なセッションキーの下で暗号化される。それは、ＰＩＡ公開キーで暗号化されている、ステップ４０９で受け取られたメッセージから検索することができる。公開キーインフラストラクチャを使用して、対称なセッションキーを設定するそのような機構は周知である。

受信側ＰＭ１０７が検証ステップ４０９から成功の知らせを受け取れば、受信側ＰＭ１０７の次のステップ４１０は、４０５で挿入されたｅメールに添付された任意のＰＭデータも抜き出すことである。典型的な実施例で、これはメッセージ中の特定のＲＦＣ２８２２拡張ヘッダーを探索することにより行われる。ＰＭデータが利用可能な場合、受信側ＰＭの次のステップ４１１は、受信者データベース３０２に、ｅメール送信者に対してＰＭデータを格納することで、任意の返信に使用できるようにする。

好適実施例において、送信者が新しいか、そのＰＭデータが変更しており、また、その最低の受入れ可能なＲＭＰ値が、ユーザが設定可能な値を越え、あるいは、それが設定可能なＲＭＰフラグを必要とする場合、ユーザは、受信者データベースへの送信者の保存を手動で認可し、その結果として高価値のＲＭＰあるいは特にフラグが立てられたＲＭＰを送るように依頼される。典型的な実施例において、これは、ｅメールのメッセージＩＤを参照する主題を提示して、ローカルメール受信機３０５を介してユーザに質問ｅメールを返信することにより行なわれる。ユーザが質問ｅメールに回答すれば、送信者がデータベースに格納される。さもなければ、送信者は無視されるか、あるいは、送信者のアドレスへの発信ｅメールをブロックするよう受信者データベースに記入する。

受信側ＰＭの次のステップ４１２は、ローカルメール受信機３０５を介して受信側ｅメールクライアント１０１が後で取り出すように受信ｅメールを格納することである。その後の時点４１３で、受信側ｅメールクライアント１０１は、新しいｅメールがあるかポール（poll）することができ、受信ｅメールがユーザに送達される。ＰＭがｅメールクライアントに組み込まれている場合、ステップ４１２で、通常通り単にユーザの「ＩｎＢｏｘ」に受信ｅメールを格納する。

受信したＲＭＰの検証合格に続いて、受信側ＰＭは、発行ＰＩＡから返信された受け取り用コード、受け取り時間及び受け取り用発行者ＩＤをも収集リスト３０４に格納する。

受信側ＰＭ１０７が検証ステップ４０９から失敗の知らせを受け取れば、そのｅメールを削除し、受信ｅメールの送信者にエラーｅメールを返信することができるが、これは、以下でより完全に開示するように、ＲＭＳ１１０による管理に従う。

別の時点で、４１３のｅメール送達の前又はその後で、受信側ＰＭ１０７の次のステップ４１４は収集リスト３０４によって作動し、適切な発行ＰＩＡ１０９から更新ＲＭＰを取得する。発行ＰＩＡによるＲＭＰの更新プロセスは以下で詳述する。

発行ＰＩＡが検証ステップ４０９で成功通知の一部として受け取り時間を知らせる好適実施例において、受信側ＰＭは、ステップ４１４で交換ＲＭＰの受け取りを始める前にその時間まで待つ。発行ＰＩＡが成功通知の一部として代わりの発行者ＩＤを供給するより好適な実施例において、受信側ＰＭは、ステップ４０９でのようにステップ４１４で代わりの発行者のネットワーク・アドレス（そして随意に公開キー）を調べる。

本発明の別実施例（図示せず）で、ＲＭＰを検証するステップ４０９とＲＭＰを受け取るステップ４１４は、発行ＰＩＡに対する単一のリクエスト及び返答に組み合わせてもよい。ＲＭＰを検証し交換するためのＰＭとＰＩＡの間の通信を行なう他の方法は当業者に明白であろう。

交換ＲＭＰを取得すると、受信側ＰＭの最終ステップ４１５は、ＲＭＰデータベース３０３にそれを格納し、自らの事後の発信ｅメールでの使用に備えることである。新しいｅメールを送信する場合、最初に受信するＰＭ１０７が送信側ＰＭ１０８と同様に作動し、サイクルが再び始まる。

本発明の好適実施例（図示せず）で、受側信ＰＭ１０７は、受信ｅメールの特定の送信者又は特定のクラスの送信者へ等価のＲＭＰを添付したｅメールを自動的に返信するよう構成されてもよい。これは、ｅメール・リストサーバ及び自動返答機のような選択された送信機が、純原価を生じずに受信側ｅメールクライアントに繰り返しｅメールを送ることを可能にする。

図５は、初めて通信し合い、従って相手がＰＭ技術をインストールしていることまだ知らない、２つのＰＭ対応のｅメールクライアント間のｅメールの配信用構成要素間のメッセージのシーケンス及び流れを示す単純化されたＵＭＬシーケンス図である。

プロセスは、図４と同様に、送信ステップ４０１と受信者検索ステップ４０２で開始する。しかし、この場合は、受信者の検索が失敗し、ＲＭＰが使用されない（ステップ４０３、４０４がない）。その代わりに、送信側ＰＭ１０８が、チャレンジを受けるのに備えて、ｅメールを未決メールデータベース３１１に格納するステップ５０１を実行する。そして、図４と同様に、４０５で自己のＰＭデータを添付して、４０６で受信者にｅメールを配送する。

受信側ＰＭ１０７は受信ｅメール中で拡張ヘッダーを捜すことにより、ＲＭＰの存在をチェックし、見つからないと、ステップ４０７〜４０９をスキップする。しかし、ＰＭデータを示すヘッダーを見つけると、４１０でＰＭデータを抜き出すが、ＲＭＰが存在しないので、ステップ４１１〜４１５を実行できない。代わりに、新しいステップ５０２、５０３を実行して、ｅメールのシグネチャを形成し、ＲＭＰを添付するように送信者に促すべきかＲＭＳ１１０に助言を求める。

ｅメールのシグネチャの形成はコラボラティブ・フィルタリング技術を使用するシステムで周知である。シグネチャはｅメールの重要な、独自の特徴を表わす要約された形式であり、帯域幅を浪費し、プライバシーの侵害になり得るｅメール全体の送信を必要としない。典型的な実施例で、ＳＨＡ−１のような一方向ハッシュ技術を使用して、重要なヘッダーのシグネチャと内容の多数のオーバーラップする部分を形成するが、それはメッセージへのランダムなテキストの追加に対する反証を提供する。識別情報の抜き出しとプライバシーが保護されたシグネチャを形成するさらなる技術は当業者に明白であろう。

そのシグネチャからのｅメールについてのアドバイスの要請を受信すると、ＲＭＳは周知のコラボラティブ・フィルタリングの技術と、後で述べる他の技術を利用して、ｅメールが以下のものかを決定する：
１）正当なｅメール
２）サービス停止（ＤｏＳ）攻撃としてチャレンジ機構を使用する明らかな試み
３）スパムの明らかな試み
４）不確実

どの決定がなされるかによって、ＲＭＳは、次のもののうちの１つを行うように助言するアドバイス結果を受信側ＰＭに返信し得る：
１）ｅメールを直ちに削除する
２）チャレンジで返信せずに、ユーザにｅメールを直ちに配達する；
３）チャレンジで直ちに返信する；
４）さらなるアドバイスのためにＲＭＳにより詳細なシグネチャを送る；
５）さらなるアドバイスのためにＲＭＳにｅメール全体を送る；
６）ある期間を待ち、アドバイスの要請を繰り返す；指定期間は経過時間又は絶対的な時間。

これらのオプションは、潜在的に正当なｅメールが許可されることを保証しながら、ＲＭＳが広まったスパム又はＤｏｓ攻撃に対する対応を管理することを可能にする。不確実の場合の全体安全な返信は他のＰＭからのさらなる情報を入手するまで助言を遅らせることであり、それでもまだ不確かな場合、チャレンジの送信を助言する。ユーザによって設定可能なエラーマージン内でｅメールが明らかにスパムである場合のみ、即時の削除を助言する。同様に、ユーザ設定可能なエラーマージン内で非ＰＭ対応の送信者からのｅメールが明らかに正当な場合のみ、即時の配送を助言する。このように、ユーザ、あるいはユーザを代表するＲＭＳは、最善の結果のため偽陽性、偽陰性及びのチャレンジの間のバランスを管理することができる。

従って、ある１通のｅメールについてのアドバイス用のＲＭＳへの恐らく多数の時間間隔をおいた要請の結果は、ｅメールを直ちに削除し、送達を止めること、ステップ４１２で配信を直ちに継続する、あるいはＲＭＰを添付するように送信側ＰＭに促すことである。

後者の場合は、受信側ＰＭは、送信側ＰＭに対してチャレンジｅメールを作成して送る新しいステップ５０４、５０５を実行する。受信側ＰＭは送信側ＰＭのＰＭデータを知っているので、チャレンジｅメールは大半が機械可読になり得る。チャレンジｅメールはそのＲＦＣ２８２２メッセージＩＤによってオリジナルのｅメールに言及し、受信側ＰＭのＰＭデータをも含む。好適実施例で、ＰＭデータは最低の受入れ可能なＲＭＰ値及び／又はオリジナルのｅメールを配送するために必要なフラグ値を含んでいる。さらに好適な実施例で、つけられた値は、送信者のアイデンティティーあるいはオリジナルｅメールの他の特性に依存してもよい。

チャレンジｅメール５０５の送達は、返信ｅメールを送達する周知の標準手続きを使用する、４０６のオリジナルｅメールの送達の逆である。

さらなる特別のヘッダーの存在によって識別されたチャレンジｅメールを受信すると、送信側ＰＭの最初のステップ５０６は、引用されたＰＭデータをその受信者データベース３０２に格納することである。これは、すべての将来の場合にこの受信者へｅメールを正常に送信することを可能にする。以前のように４１１で、受信者の最低の受入れ可能なＲＭＰ値がユーザ設定可能な値を越えるか、設定可能なＲＭＰフラグを必要とする場合、ユーザは、受信者データベースへの受信者の格納を手作業で認可するように依頼される。

送信側ＰＭの次のステップ５０７は、チャレンジｅメールで引用されたメッセージＩＤを利用して、その未決メールデータベース３１１からオリジナルｅメールを検索することである。ｅメールと有効な受信者データを入手すれば、ステップ４０３（図４）からの送信プロセスを再試行することができ、それはそれ以上のチャレンジなしで正常に完了するはずである。送信者からＲＭＰを不正に抜き出そうとする第三者からの攻撃を回避するために、ステップ４０６でｅメールを配信するのに、チャレンジ用の返信アドレスではなく、オリジナルの受信者アドレスを使用することが重要である。

図６は、ＰＭ技術をインストールしていないｅメールクライアントとインストールしているクライアントと間のｅメールの配信用構成要素間のメッセージのシーケンス及び流れを示す単純化されたＵＭＬシーケンス図である。

最初のステップ６０１で、上記のように、送信側ｅメールクライアント１０２は共通のｅメールプロトコル又はその他によって受信側ＰＭ１０７へｅメールを送信する。送信側ＰＭ１０８が（まだ）存在しないことに留意されたい。ＰＭデータもＲＭＰも添付されていないことを受信ＰＭが知るので、それはｅメールに対してチャレンジするよう直ちに動きだす。先ず、前にステップ５０２、５０３で示したように、チャレンジを行なう方法についてのアドバイスをＲＭＳ１１０に要請する。チャレンジが必要であることをＲＭＳが示すと仮定して、受信側ＰＭの次のステップ６０２は、以前のようにｅメールを送信用ではなく受信用に未決のものとしてマークして、未決メールデータベース３１１にｅ格納することである。

次のステップ６０３はチャレンジｅメールを作成することである。しかし、今回、ｅメールは人間によって読まれることを目指しており、なぜ送信側ｅメールがまだ送達されていないかという、ＲＭＰシステムの説明と、送達を可能にするＲＭＰを得るために許可証マネージャーを得てインストールする方法についての指示を含んでいる。好適実施例で、指示は構成時にユーザによって指定された言語で送られる。さらに好適な実施例で、指示は多数の言語で送られる。さらに別の好適実施例で、指示が送られる第１のあるいは唯一の言語は、ＩＰアドレス割付けデータベース、ドメイン・データベース等の検索によって決定されるような送信者の地理的位置に依存する。

ｅメールの指示は、格納されたｅメールのメッセージＩＤとともに、好適実施例では受信側ＰＭの公開キーと最低のＲＭＰ値を含めて、受信者のＰＭデータをも符号化している。好適実施例で、このデータは、インストールプロセスを開始めるためにユーザがクリックするＵＲＬリンクへ符号化される。

そして、受信側ＰＭは６０４で、返答メッセージ送るための標準方法を使用して、チャレンジ・メッセージを送信側ｅメールクライアントへ送達する。この場合、ユーザが、ステップ６０５でＰＭをインストールすることに同意するものとする。そうでなければ、チャレンジには応答がなく、オリジナルのｅメールは最終的に未決メールデータベース３１１からタイムアウトし、暗黙に削除される。

しかし、オリジナルの送信者は、ＰＭをインストールせずにチャレンジに手作業で答えることを望む（あるいはそう強要される）かも知れない。この場合、送信者はＰＭをインストールしない理由を簡単に説明するべきであり、返答メッセージを送る標準方法を使用しなければならない。好適実施例で、受信側ＰＭ１０７が手動の返答を識別することができるために、手動の返答の「参照」ヘッダーにおいて従来通りに引用されるチャレンジｅメールのための特有のメッセージＩＤを作成する。より好適の実施例で、このメッセージＩＤは、オリジナルｅメールの言及をも含む。そして、受信側ＰＭは、返送されたチャレンジから手動の返答を抜き出し、通常の周期的報告機構内で受信者にそれを提示する。そして、受信者はオリジナルｅメールを読み、かつ、又は送信者をホワイトリストに載せるよう希望するかもしれない。より好適な実施例で、オリジナルのｅメールは、返送されたチャレンジ中の参照ヘッダーから抜き出されたｅメールの言及を使用して、未決メールデータベース３１１から取り出すことができる。

さらに好適な実施例では、システムを回避して、スパマーが受信者へ自由なテキストを送るループホールを提供しないようにするために、いかなる手動の返答もＲＭＳ１１０によって最初にフィルターされる。同じアドレスからの多くの一見手動の返答又はスパム内容の他の指標を、オリジナルの受信者への提示前に手動の返答をフィルターするために使用することができる。

送信側ＰＭ１０８が一旦インストールされれば、自動返答メッセージとともにＲＭＰを送るプロセスを継続することができる。返答メッセージを構築し、かつ適切にＲＭＰを添付するためには、６０３、６０４で非ＰＭｅメールクライアントへ返信されたチャレンジメッセージから受取側アドレス、ＰＭデータ及びメッセージＩＤを必要とする。これはステップ６０６として示されている。好適実施例で、チャレンジデータはインストールＵＲＬを介して、ＰＭソフトウエアを提供するダウンロード・サービスへ渡され、ダウンロードされたパッケージへ直接組込むか、ダウンロードされたパッケージとともに返された参照に対して格納されてもよく、そこから、新しくインストールされたＰＭによって取り出される。別の実施例で、チャレンジデータは、新しくインストールされたＰＭがアクセスすることができるブラウザ・クッキーのようなローカルに格納されたデータに符号化される。新しくインストールされたＰＭへチャレンジデータを渡す他の手段は当業者に明白であろう。

別実施例で、新しくインストールされたＰＭ１０８に渡されるチャレンジデータは、受信者アドレスとメッセージＩＤのみであり、新しくインストールされたＰＭ１０８は、特別に符号化されたｅメールによって受信者１０７にＰＭデータを直ちに要請する。

新しくインストールされた送信側ＰＭ１０８がチャレンジｅメールから受信者アドレスとＰＭデータを一旦入手すれば、６０７で受信者データベース３０２に受信者の詳細を格納し、この受信者へのさらなるｅメールに備えることができる。また、６０８で受信側ＰＭへ返信する、オリジナルのｅメールのメッセージＩＤを含む自動返答ｅメールを作成することができる。そして、ＲＭＰと自身のＰＭデータを見つけて、この返答メッセージへの添付し、受信側ＰＭ１０７にそれを送達する通常のステップ４０３、４０４、４０５、４０６を実行する。

さらなる特別のヘッダーの存在によって識別される、チャレンジに対する真のレスポンスを受け取った受信側ＰＭ１０７の最初のステップ６０９は、レスポンスで引用されたメッセージＩＤを調べることにより、６０２で格納されたオリジナルのｅメールを検索することである。一旦オリジナルのｅメールが回復されれば、オリジナルｅメール自体ではなく返答ｅメールからＰＭデータとＲＭＰを得る以外は、受信ＰＭは、以前のようにオリジナルｅメールの送達を可能にするステップ４０７〜４１５を完了することができる。

ＰＭ対応ｅメールクライアント１０２、１０８が非ＰＭ対応ｅメールクライアントにｅメールを送る場合、ｅメールが非ＰＭ対応ｅメールクライアントに送達される図５のステップ４０６まで実行する。添付のＰＭデータが拡張ヘッダーにおいて符号化されるから、非ＰＭ対応ｅメールクライアントは通常通りｅメールを表示し、チャレンジで回答しない。所定時間の後、送られたｅメールは、未決メールデータベース３１１からタイムアウトして、単に削除される。

図７は、許可証発行当局（ＰＩＡ）の構造を示すブロック図である。ＰＩＡの定義は機能的であり、ここで説明する構造に限定されないと見なすべきである。

ＰＩＡ１０９は中央の許可証発行機７００を備え、それは発行されたＲＭＰのデータベース７０１と未決の収集物のデータベース７０２とを維持する。ＰＭインターフェース７０３、７０６を備えた許可証チェッカー７０４、７０７が許可証発行機７００に取り付けられ、それらは、すでに述べたように、ＲＭＰを検証し、新しいものを集めるためにＰＭからのリクエストを受け入れる。さらに、後述のようにＲＭＰの購入と引換えにサービスへのユーザ・アクセスを提供するウェブ・インターフェース７０９が許可証発行機７００に取り付けられている。

ＰＩＡの第一の技術的問題はスケーラビリティの問題である。許可証発行機７００は、ＲＭＰの単一データベース７０１と未決収集物のリスト７０２をかんりするから、単一の論理装置でなければならない。非常にスケーラブルなデータベース例を配布するためのシステムは周知である。しかし、ＲＭＰデータベース及び収集リストを維持する限界機能以外の本質的でない機能性はすべて、中核の発行機から外して、多数のデバイスに分配すべきである。

ＰＩＡの最高負荷は、図４の４０９のような提出されたＲＭＰの検証である。
これは、上記のように、いくつかの一応の受入れ可能性のテスト、ＲＭＰの特有の部分の参照ステップ及び提出されたＲＭＰ全体の格納されたコピーに対する比較ステップを必要とする。ＲＭＰが暗号化されるより好適な実施例で、このステップは検証前にＲＭＰを解読することをさらに含む。これらのプロセスは、有効なＲＭＰ７０５、７０８のインメモリー・キャッシュを各々含む専用サーバのクラスタによって行なうのが最善である。ハッシュ表によって増大したメモリのルックアップは非常に速く、メモリー要求は数百万の未決ＲＭＰでさえ可能である。

ＲＭＰの有効性を検証する許可証チェッカー７０４、７０７は、成功又は失敗を示して、要請側ＰＭ１０７に回答を直ちに返信することができる。好適実施例で、検証が成功した場合、収集時間も返信される。より好適な実施例では、発行するＰｌＡが更新と収集をオフロードしたい場合、交替発行者ＩＤが返信される。検証する許可証チェッカー７０４、７０７は、許可証発行機７００に、オリジナルＲＭＰとＰＭ収集コードを引用した更新メッセージと収集時間を送る。更新メッセージを受け取ると、許可証発行機７００は、オリジナルのものと同じフラグ２０２、満期時刻２０４、値２０５及び発行者ＩＤ２０７と、新しい独自ＩＤ２０３及びＣＲＣ２０９を付けてＲＭＰを更新する。好適実施例で、独自ＩＤは、最初の３２ビットが一意的で、残りがランダムに配列される。それはＲＭＰデータベース７０１中の古いＲＭＰを新しいＲＭＰに取り替え、収集コードによって入力された新しいＲＭＰを収集データベース７０２に加える。より好適な実施例で、ＲＭＰの他のフィールドはＰＩＡの方針によって修正されてもよい。

すべての許可証チェッカー７０４、７０７のＲＭＰキャッシュ７０５、７０８を更新するために、許可証発行機７００は、古いＲＭＰと新しいＲＭＰを示して、更新メッセージをすべての許可証チェッカーに送信する。各許可証発行機は自身のメモリキャッシュから古いＲＭＰを削除し、新しいものを挿入する。別の実施例では、古いＲＭＰだけが引用され削除され、新しいものは収集時に挿入される。さらに別の実施例では、古いＲＭＰだけが引用され削除され、新しいものは別の時にさらなるメッセージによって挿入される。

図４の４１４でのように収集の要請を受信すると、許可証チェッカー７０４、７０７はそれを許可証発行機７００へ直接渡す。許可証発行機７００は、収集データベース７０２で収集コードを探し、見つかった場合、収集データベース７０２から記録を削除し、適切な更新されたＲＭＰを返信する。それを許可証チェッカー７０４、７０７が要請側ＰＭ１０７に返信する。分散型システム及び／又は信頼できないプロトコル（例えばＵＤＰ）が使用される場合、このプロセスは、周知のような処理の一貫性及び信頼性を保証する機構をひつようとすることになる。

好適実施例で、許可証発行機７００は、示めされた収集時間と及び収集が成功裡に完了する時に基づいて、それ自身の作業負荷を制御するために、許可チェッカー７０４、７０７によって発行される収集時間を管理してもよい。

上記では、あるＲＭＰは最終的に期限がきれる前に、何度も再使用され得る。システム全体内でＲＭＰの「フロート」を維持するために、ユーザは発行ＰＩＡ１０９からの新しいＲＭＰを時々購入する必要がある。

本発明の典型的な実施例で、ＲＭＰは、周知のような標準のウェブ・ベースの電子商取引インターフェースを提供する、ウェブ・インターフェース７０９へ接続するためにウエブブラウザーを使用して、ユーザによって購入されることができる。クレジットカード又は他の支払方法での購入の結果、ウェブ・インターフェース７０９は、古いものを更新する場合と同様に、指定されたフラグ２０２、値２０５及び満期時刻２０４を備えたいくつかの新しいＲＭＰを作成することを許可証発行機７００に要請する。

別実施例で、ＲＭＰは、ウェブ・インターフェース７０９によって提供されるＳＯＡＰのようなウェブサービス・インターフェースを介して大量に購入されてもよい。

好適実施例で、ＲＭＰ作成用の収集コードは、ウェブ・インターフェース７０９によって考案され、機械可読の更新ｅメールを介してユーザのＰＭ１０７に返信される。そして、ユーザのＰＭ１０７は図４の４１４のようにＲＭＰを取得する。別の好適実施例で、ウェブ・インターフェース７０９自体がＲＭＰを集め、全ＲＭＰを自動ｅメールによってユーザのＰＭ１０７に直接返送する。そのようなメッセージが暗号化されるより好適な実施例で、公開キーを交換するために先のｅメール交換が要求される。そのようなｅメールの交換は、購入プロセスの終わりに示される「ｍａｉｌｔｏ：」ウェブ・リンクを介して開始し得る。「ｍａｉｌｔｏ：」の正確な形式は取引用のデータを識別することを含んでいてもよい。

発行するＰＩＡは、ＲＭＰ購買価格の全部又は一部の換金を提供することにしてよい。この場合、ＲＭＰは「引換え可能」フラグ２１１を立てさせる。このフラグが立てられたＲＭＰは、更新する代わりに、会計システム中のユーザの口座（図示せず）に払われる値での換金のリクエストとともに、検証用にＰＭ１０７によってＰＩＡ１０９に送られればよい。ウェブ・インターフェース７０９は、ア口座を管理し、周知のように資金を払い込んだり引出したりするのに使用されてもよい。

ＰＭが広く配備された大規模シナリオでは、各ＰＭユーザは、いくつかのＲＭＰを発行するＰＩＡのうちの１だけに口座を持つ可能性が高い。そのような場合、受信者によって受け取られたＲＭＰが、受信者が直接の会計関係を持っているＰＩＡ以外のものによって発行され、従って換金されなければならないことがありえる。従って、好適実施例では、１つのＰＩＡでなされた支払いが別のもの保持された口座の貸し方になることを可能にするＰＩＡ間支払い決済システム（図示せず）が設けられる。供給者間の支払い又は請求の決済あるいは清算のためのそのようなシステムは、バンキングや電話のような分野で周知である。従って、好適実施例で、ＰＭの「ホーム」ＰＩＡ宛でないＲＭＰ換金のリクエストは、換金される値の一部又は全部をホームＰＩＡのユーザの口座で決済できるようにするために、ホームＰＩＡとユーザの口座の言及を含む。

別の好適実施例（図示せず）で、ユーザは、特定のＰＩＡでの口座を必要とせずに、ＲＭＰの換金をＲＭＰ清算サービスによって行える。このサービスは、いくつかのＰＩＡからＲＭＰを受け入れて、ユーザの代わりに代理によってそれらを換金するプロセスを扱い、合計換金額から手数料を引いて、ユーザに集計支払をするか、あるいは品物又はサービスを配送する。ＰＩＡからＲＭＰ清算サービスへの支払は周期的な集計で行なわれる。ＰＩＡとＲＭＰ清算サービスの間の通信は周知のウエブサービスを介してもよい。

別実施例で、ユーザとＰＭ及びＰＩＡとの間の通信はすべてｅメールによって行なわれる。さらに好適な実施例で、ＰＭはＰＩＡと直接通信する、ＲＭＰ管理用のそれ自身のユーザ・インターフェースを持つ。さらに別の好適実施例で、ＲＭＰの購入及び引換えの管理に、ウェブサービス又は他の分散型システム技術が使用される。ＲＭＰの購入及び引換えを行なうさらなる方法は当業者にとって明白であろう。

本発明の好適実施例で、システムの新規のユーザは、サービスを利用を促進するために少数の無料ＲＭＰを支給される。これらの無料ＲＭＰは２１１で換金可能でなく、システムが無料ＲＭＰであふれることがないように２０４で短い満期になるであろう。理想的には、無料ＲＭＰはそれらが発行されるのと同じ割合で終了する。乱用を回避するために、任意の単一の人又は団体に発行される無料ＲＭＰの数が制限される。

本発明に記載されるようなスタンプに基づいたスパム管理サービスを展開させることの主なハードルの１つは、「スタンプ」（ＲＭＰ）を添付するためにソフトウエア（ＰＭ）をインストールしていないか、しようとしないか、できない送信者の扱いにある。図６に、ＰＭ１０８を最初はインストールしていない送信者がそれを得る方法を指示され、オリジナルと後続のｅメールの自由な流れを可能にする方法を示した。しかし、状況によっては、受信者が、ＰＭ技術をインストールしないか、できないと信じる送信者からのＲＭＰの添付のないｅメールの自由な通過を許可したいこともある。

従って、本発明の好適実施例では、送信者の「ホワイトリスト」（図示せず）がＰＭ１０７で格納される。ホワイトリスト上の送信者からの電子メールは、ＲＭＰが添付されなくても許可される。送信者は手作業で、あるいは、ユーザの意志でそれらへの任意の送信ｅメールの結果、あるいはユーザのアドレス帳での存在によってホワイトリストに加えられてもよい。

ホワイトリストにない非ＰＭ対応の送信者からの通信を許可するために、図６のチャレンジ・プロセス６０３、６０４はＰＭ１０８の設置の強要ではなく、チャレンジに対する代わりの人の返答を可能にするよう構成される。好適実施例で、チャレンジは人間だけが容易に行なうことができる「キャプチャ」タスクの完了を要求する。別の好適実施例で、チャレンジは、返信でｅメールの理由を簡単に示すように送信者に求め、受信側ＰＭ１０７は、これらを受信側ユーザに周期的に提示されリクエストのリストに一括して認可又は否認を求める。いずれの場合も、送信者がチャレンジを成功裡に完了させる場合、それらがホワイトリストに加えられ、６０９で未決のｅメールが送達される。

記載したようなホワイトリストの追加で、ＲＭＰの使用は、多くの「第１接触」ｅメールを発送する個人また小量のマーケティング資料を送る組織等の、単にチャレンジ・プロセスを回避したい以前に知られていない送信者だけが必要である。しかし、長期的には、ホワイトリスト・プロセスはいくつかの点でスパマーによって攻撃を受けやすい。

１）キャプチャのチャレンジへの自動レスポンス − 攻撃者がキャプチャ問題をとらえ、異なる状況（例えば「アダルト」ウェブサイトへのエントリー用）で実際のユーザにそれを提示し、オリジナルのチャレンジに対して回答を使用することが知られている。
２）人間のチャレンジへの自動レスポンス − スパマーは、（例えば）ウェブサイト・コンテンツに基づいて通信の正当に思える理由を作り上げることができよう。
３）有望な既知の送信者を使用した偽造送信者アドレス − スパマーは、周知の電子商取引サービスを装ったり、同じドメイン内のアドレスを関連させることが考えられる。

従って、ＰＭ対応のクライアントが比較的珍しく、スパマーがまだ追いついていない間、配備の初期にホワイトリスト・オプションは役に立つだろう。

上記で、ユーザが彼らのローカルｅメールクライアントにＰＭソフトウエア１０７をインストールすると仮定した。これは次の長所を持つ：
１）既存のｅメールアドレスの保持
２）通信のプライバシーの保持
３）中央のボトルネックを回避する送達の分布

しかし、多くのユーザが、ヤフーメール及びグーグルメールのような半集中「Ｗｅｂｍａｉｌ」サービスを利用することに既に決めている。この場合、本発明の別実施例では、ＰＭ機能性が中央サービスの一部としてより効率的にインストールすることができる。ＰＭの動作は、受信側及び送信側ｅメールクライアント１０１、１０２へのインターフェースがＷｅｂｍａｉｌサービスの内部にあり、ユーザとの通信がすべてサービスの通常のウェブ・インターフェースを介する以外は同一である。

同様に、メーリング・リストや電子商取引動作のような自動のｅメール送信システムを持ったいかなる組織も、ｅメール送信システムに送信側ＰＭ１０８の機能性を含めることを希望するであろう。通常のユーザと同様に、ＰＩＡからのＲＭＰを購入するか、すでに開示したように、自動的にＲＭＰを返す受信者に依存するかも知れない。後者のオプションは任意の操作されるメーリング・リストにとって不可欠であろう。

既に述べたように、ある自動ｅメール送信者は、メーリング・リスト、サービス更新及び電子商取引からの注文の受領確認のように、いずれにしても正当かもしれない。自動の送信者がＰＭ機能性をインストールしないか、それができず、そして受信者がホワイトリストにそれらを載せていない場合、それらのｅメールが送達される方法がない。本発明の好適実施例では、ＰＩＡは、ユーザによってリースされ、それによってｅメールがＲＭＰの添付を要求されずに受信されることができる一時的なｅメールアドレスの生成のメカニズムを提供する。すると、ユーザは、メーリング・リストを予約購入したり、品物を注文するときに、これらの一時的なｅメールアドレスの１つを使用することができる。

さらなる好適実施例で、一時的なｅメールアドレスのリースは、ＰＩＡへの任意の値のＲＭＰの提出による購入を必要とする。別の好適実施例では、一時的なｅメールアドレスで受信されたｅメールはそれぞれ、受信者によるＲＭＰの支払いを必要とする。

さらに別の好適実施例では、一時的なｅメールアドレスで１つあるいは少数のｅメールを受信するとすぐに、あるいは短いユーザ設定可能な期間の後に、そのｅＥメールアドレスは自動的に削除される。別の好適実施例では、１つあるいは少数のｅメールを受信するまで、あるいは短いユーザ設定可能な期間、送信者のｅメールアドレスをホワイトリストに含めることにより同じ利益が得られる。

本発明を典型的な実施例によって説明したが、発明の真の趣旨と範囲から外れずに、多くの改変が当業者によってなされ得ることが理解されよう。

ｅメールを送受信し、再使用可能なメール許可証を添付・検証するプロセスの主構成要素を示すブロック図 再使用可能なメール許可証の１つの考え得る内容とフォーマットを示す構成図 許可証マネージャーの構成要素を示すブロック図 ２つの許可証マネージャー対応ｅメールクライアント間の通常の成功するｅメール送信用の構成要素間のメッセージのシーケンス及び流れを示すＵＭＬシーケンス図 以前に通信したことのない２つの許可証マネージャー対応クライアント間のｅメールの配信用の構成要素間のメッセージのシーケンス及び流れを示すＵＭＬシーケンス図 当初非許可証マネージャー対応クライアントと許可証マネージャー対応クライアント間のｅメールの配信用の構成要素間のメッセージのシーケンス及び流れを示すＵＭＬシーケンス図 許可証発行当局の構成要素を示すブロック図

Claims (87)

1. 受信者の代理であるｅメールクライアントによるｅメールの受信を規制する方法であって、その方法は以下のステップからなる：
   ａ）ｅメールクライアントによってｅメールサーバから最初のｅメールを受信し、
   ｂ）前記最初のｅメールに添付された再使用可能なメール許可証の存在をチェックし、
   ｃ）再使用可能なメール許可証が添付されていない場合に、前記最初のｅメールに対して第１の処置を行い、
   ｄ）再使用可能なメール許可証が添付されていれば、再使用可能メール許可証発行サービスに前記再使用可能なメール許可証の検証を要請し、
   ｅ）再使用可能メール許可証発行サービスが前記再使用可能なメール許可証の検証を拒否すれば、最初のｅメールに対して第２の処置を行い、
   ｆ）再使用可能メール許可証発行サービスが前記再使用可能なメール許可証の検証を許可すれば、前記最初のｅメールを受信者に送達し、
   ｇ）前記再使用可能メール許可証発行サービスから、送達されたｅメールの前記再使用可能なメール許可証の更新を要請し、そして
   ｈ）更新された再使用可能なメール許可証を、後の送信ｅメールに添付するために保管する。
2. 再使用可能なメール許可証が添付された送信ｅメールで前記最初のｅメールに返答することからなる請求項１に記載の方法。
3. ｅメールクライアントが別のｅメールクライアントの代理を務め、最初のｅメールの送達は、別のｅメールクライアントへ最初のｅメールを転送することからなる請求項１に記載の方法。
4. 再使用可能なメール許可証が前記最初のｅメールに添付されていなくても、最初のｅメールの送信者が事前に定義された受入れ可能な送信者のリストに載っていれば、最初のｅメールが受信者に送達される請求項１に記載の方法。
5. 第１の処置と第２の処置の一方又は両方が最初のｅメールを削除することを含む請求項１に記載の方法。
6. 第１の処置と第２の処置の一方又は両方が最初のｅメールの送信者に第２のｅメールを返信することを含む請求項１に記載の方法。
7. 第２のｅメールが、最初のｅメールを再送する前に行なわれるべき処置を決定するために、最初のｅメールの送信者によって使用され得る情報を含む請求項６に記載の方法。
8. 第１の処置と第２の処置の一方又は両方が、さらに以下のステップからなる請求項６に記載の方法、
   ａ）最初のｅメールを未決のキューに保持し、
   ｂ）第２のｅメールを返信し、
   ｃ）第２のｅメールに対する満足な返信を受信すれば、保持された第１のｅメールを受信者に送達し、そして
   ｄ）第２のｅメールに対する不満足な返信を受信すれば、あるいは所定の時限までに無回答なら、保持された第１のｅメールを削除する。
9. 第２のｅメールが、有効な再使用可能なメール許可証を送ることを送信者に要請する請求項６に記載の方法。
10. 第２のｅメールが、再使用可能なメール許可証を添付する能力を得る方法についての指示を含む請求項６に記載の方法。
11. 最初のｅメールの送信者に第２のｅメールを返信するステップが、さらに以下のステップを含む請求項６に記載の方法、
    ａ）最初のｅメールのシグネチャを形成し、
    ｂ）少なくともシグネチャを送信し、提案処置をレスポンス管理サービスに要請し、そして
    ｃ）提案処置によって処置する。
12. 提案処置が以下のものの１つ以上を含む請求項１１に記載の方法、
    ａ）第２のｅメールで返信せずに、最初のｅメールを直ちに削除する、
    ｂ）第２のｅメールで返信せずに、最初のｅメールを直ちに送達する、
    ｃ）第２のｅメールで直ちに応答する、
    ｄ）レスポンス管理サービスに更に詳細なシグネチャを送り、更なる提案処置を要請する、
    ｅ）レスポンス管理サービスに第１のｅメール全体を送り、さらなる提案処置を要請する、
    ｆ）所定期間待ち、要請を繰り返す、あるいは
    ｇ）所定の絶対的な時間まで待ち、要請を繰り返す。
13. 再使用可能なメール許可証の存在をチェックすることが、存在する場合に再使用可能なメール許可証の一応の受入れ可能性をチェックするステップをさらに含む請求項１に記載の方法。
14. 再使用可能なメール許可証の一応の受入れ可能性のチェックが、再使用可能なメール許可証のＣＲＣ又は他の冗長性の情報を検証することからなる請求項１３に記載の方法。
15. 再使用可能なメール許可証の検証の要請と再使用可能なメール許可証の更新の要請のステップが、再使用可能メール許可証発行サービスへの単一の要請として組み合わせられる請求項１に記載の方法。
16. 再使用可能なメール許可証の検証の要請と再使用可能なメール許可証の更新要請のステップが、ｅメールクライアントによって作成され、再使用可能メール許可証発行サービスへの検証要請とともに供給される収集コードによって関連づけられる請求項１に記載の方法。
17. 収集コードが、ｅメールクライアントによってランダムに選ばれた数を含む請求項１６に記載の方法。
18. 収集コードが、検証されている再使用可能なメール許可証、又は同じ再使用可能メール許可証発行サービスによって発行され、ｅメールクライアントによって保持された他の再使用可能なメール許可証の独自の名前の一部又はすべてを含む請求項１６に記載の方法。
19. 検証要請の結果が更新要請の最も早い時期をさらに含み、ｅメールクライアントが再使用可能なメール許可証の更新を要請する前に少なくとも最も早い時期まで待つ請求項１６に記載の方法。
20. 検証要請の結果が、同じ又は異なる再使用可能メール許可証発行サービスの新しいアドレスへの転送をさらに含む請求項１６に記載の方法。
21. 再使用可能なメール許可証が、再使用可能メール許可証発行サービスによって発行された少なくとも独自の識別子を含み、再使用可能メール許可証発行サービによる再使用可能なメール許可証の検証が、独自の識別子が発行され、以前に検証されていないことを少なくとも検証することからなり、再使用可能メール許可証発行サービによる再使用可能なメール許可証の更新が、少なくとも新しい独自の識別子の生成及び発行からなり、それが、少なくともｅメールクライアントに返信され、ｅメールクライアントによって、更新された再使用可能なメール許可証の一部として保管される請求項１に記載の方法。
22. 独自の識別子が大きい番号である請求項２１に記載の方法。
23. 再使用可能なメール許可証が、現在の再使用可能なメール許可証が有効にされ更新され得る、いくつかの再使用可能メール許可証発行サービスの１つを識別する情報を含む請求項１に記載の方法。
24. ｅメールクライアントが、受入れ可能な再使用可能メール許可証発行サービスのリストを維持し、リストに載っていない再使用可能メール許可証発行サービスからの再使用可能なメール許可証付きのｅメールを拒絶する請求項２３に記載の方法。
25. 再使用可能なメール許可証が、許可証がもはや有効にされない或いは更新されない満期期限を含む請求項１に記載の方法。
26. 受信ｅメール上の再使用可能なメール許可証の存在をチェックするステップが、再使用可能なメール許可証の満期期限を現在の日付と比較し、現在の日付が満期期限の後である場合に、別の許可証の要求で送信者に回答するステップを含む請求項２５に記載の方法。
27. 再使用可能なメール許可証が変数値の表示を含む請求項１に記載の方法。
28. 受信ｅメール上の再使用可能なメール許可証の存在をチェックするステップが、再使用可能なメール許可証の変数値をユーザによって設定可能な最低値と比較し、最低値が満たされない場合に、加算値の要求で送信者に回答するステップを含む請求項２７に記載の方法。
29. 変数値が現金価格である請求項２７に記載の方法。
30. 再使用可能なメール許可証の現金価格の一部又は全部、又は再使用可能メール許可証発行サービスにおける等価の製品又はサービスと引換えるステップをさらに含む請求項２９に記載の方法。
31. 再使用可能なメール許可証が、現在の再使用可能なメール許可証が有効にされ更新され得る、いくつかの再使用可能メール許可証発行サービスの１つを識別する情報を含み、再使用可能なメール許可証を引換えするステップが、１つ以上の再使用可能なメール許可証を再使用可能なメール許可証清算サービスに送って、それぞれの再使用可能メール許可証発行サービスにおける代理による再使用可能なメール許可証の引換えを行ない、ユーザへ現金、製品あるいはサービスの送達のため、このように得られた値を集計するステップをさらに含む請求項３０に記載の方法。
32. 送信者による受信者へのｅメールの送信と受信者によるｅメールの受信を規制するシステムであって、そのシステムは以下を備える：
    ａ）送信者からの発信ｅメールを受け入れるよう構成された第１送信手段、
    ｂ）発信ｅメールを遠隔の宛先へとさらに送るよう構成された第２送信手段、
    ｃ）遠隔の発信元からの着信ｅメールを受け入れるよう構成された第１受信手段、
    ｄ）着信ｅメールを受信者へとさらに送達するよう構成された第２受信手段、
    ｅ）少なくとも１つの再使用可能なメール許可証を格納するよう構成された許可証格納手段、
    ｆ）許可証格納手段から取り出した少なくとも１つの再使用可能なメール許可証を、第１送信手段に受け入れられた第２送信手段に送る前の発信ｅメールに添付するよう構成された添付手段、そして
    ｇ）第１受信手段で受け入れられた第２受信手段に送達される前の着信ｅメールから少なくとも１つの再使用可能なメール許可証を抜き出して検証し、抜き出した再使用可能なメール許可証を許可証格納手段に格納するよう構成された抜き出し手段。
33. 抜き出し手段が以下のものをさらに備える請求項３２に記載のシステム、
    ａ）少なくとも１つの再使用可能メール許可証発行サービスへ接続するよう構成されたインターフェース手段、
    ｂ）再使用可能メール許可証発行サービスと再使用可能なメール許可証の有効性を検証するよう構成された検証手段、そして
    ｃ）許可証格納手段に格納するために、再使用可能メール許可証発行サービスから更新された再使用可能なメール許可証を収集するよう構成された収集手段。
34. 検証手段と収集手段の処置を関連付ける独自の収集コードを生成するよう構成された収集コード生成手段をさらに備える請求項３３に記載のシステム。
35. 検証手段へ返された情報の結果、収集手段の動作を遅らせるよう構成された遅延手段をさらに備える請求項３３に記載のシステム。
36. 検証要請を同じ又は異なる再使用可能メール許可証発行サービスの新しいアドレスへ転送するよう構成された転送手段をさらに備える請求項３３に記載のシステム。
37. ある事前に定義された送信者からの着信ｅメールに応答して、再使用可能なメール許可証が添付されたｅメールを自動的に返信するよう構成された返信手段をさらに備える請求項３２に記載のシステム。
38. 前記抜き出し手段が、再使用可能なメール許可証の一応の受入れ可能性をチェックするよう構成されたチェック手段をさらに備える請求項３２に記載のシステム。
39. チェック手段が以下のものの１つ以上をチェックする請求項３８に記載のシステム、
    再使用可能なメール許可証の
    ａ）ＣＲＣ又は他の冗長性の情報、
    ｂ）価値、
    ｃ）満期期限、
    ｄ）発行者ＩＤ、
    ｅ）タイプ又はバージョンフィールド、又は
    ｆ）フラグ値。
40. 受入れ可能な再使用可能なメール許可証が添付されていない着信ｅメールを拒絶するよう構成された拒絶手段をさらに備える請求項３２に記載のシステム。
41. 拒絶手段が以下のものをさらに備える請求項４０に記載のシステム、
    ａ）着信ｅメールの送信者へチャレンジｅメールを生成して返信するよう構成されたチャレンジ手段、そして
    ｂ）チャレンジｅメールへのレスポンスの有効性をチェックするよう構成されたレスポンスチェック手段。
42. 拒絶手段が以下のものをさらに備える請求項４１に記載のシステム、
    ａ）チャレンジ・プロセスの間、着信ｅメールを格納するよう構成されたｅメール格納手段、そして
    ｂ）一旦チャレンジが満足に応答されたなら、ｅメール格納手段から着信ｅメールを検索するよう構成された検索手段。
43. 格納されてから設定時間が経過した後、ｅメール格納手段から着信ｅメールを取り除くよう構成されたタイムアウト手段をさらに備える請求項４２に記載のシステム、
44. チャレンジｅメールが、再使用可能なメール許可証の添付を可能にするソフトウエアをインストールする方法についての指示を含む請求項４１に記載のシステム。
45. チャレンジｅメールが着信ｅメールを受け入れる理由を求め、レスポンスチェック手段が、受信者に理由を提示して、受信者から処理の委任を得る検証手段をさらに備える請求項４１に記載のシステム。
46. チャレンジ手段が、チャレンジｅメールを返信する前にレスポンス管理サービスから助言を求めるよう構成された助言要請手段をさらに備える請求項４１に記載のシステム。
47. 助言要請手段が、レスポンス管理サービスへの提出用に着信ｅメールの少なくとも１つのコード化されたシグネチャを生成するよう構成されたシグネチャ生成手段を備える請求項４６に記載のシステム。
48. 助言要請手段が着信ｅメールの処理を行なうように構成された手段をさらに備え、その処理が以下のものの１つ以上を含む請求項４６に記載のシステム、
    ａ）着信ｅメール削除する、
    ｂ）着信ｅメールを受信者に送達する、
    ｃ）着信ｅメールにチャレンジする、
    ｄ）そのｅメールに関するさらなる情報をレスポンス管理サービスに送る、あるいは
    ｅ）レスポンス管理サービスに着信ｅメールを再提出する前に一定時間遅らせる。
49. 再使用可能メール許可証発行サービスから新しい再使用可能なメール許可証を購入するよう構成された購入手段をさらに備える請求項３２に記載のシステム。
50. 再使用可能なメール許可証が価値を示すフィールドを含み、再使用可能なメール許可証を現金、価値又は再使用可能メール許可証発行サービスにおける等価の製品又はサービスと引換えるよう構成された引換え手段をさらに備える請求項３２に記載のシステム。
51. 再使用可能なメール許可証が、再使用可能なメール許可証の発行元である、複数の再使用可能メール許可証発行サービスの１つを示すフィールドを含む請求項５０に記載のシステム。
52. 再使用可能なメール許可証の発行元と、受信者が保持する別の再使用可能メール許可証サービスの口座との間で引換え支払いを移す清算手段をさらに備える請求項５１に記載のシステム。
53. 複数の再使用可能メール許可証発行サービスによって発行された再使用可能なメール許可証を受け入れる中央の受入れ手段と、ユーザに代わって再使用可能なメール許可証を引換える代理手段と、ユーザに集計額を払うかあるいは等価の製品又はサービスを送達する集計手段をさらに備える請求項５１に記載のシステム。
54. 受信者によるｅメールの受信を規制するシステムであって、そのシステムは以下を備える：
    ａ）遠隔の発信元からの着信ｅメールを受け入れるよう構成された第１受信手段、
    ｂ）着信ｅメールを受信者へと送達するよう構成された第２受信手段、
    ｃ）少なくとも１つの再使用可能なメール許可証を格納するよう構成された許可証格納手段、そして
    ｄ）第１受信手段で受け入れられた第２受信手段に送達される前の着信ｅメールから少なくとも１つの再使用可能なメール許可証を抜き出して検証し、抜き出した再使用可能なメール許可証を許可証格納手段に格納するよう構成された抜き出し手段。
55. 抜き出し手段が以下のものをさらに備える請求項５４に記載のシステム、
    ａ）少なくとも１つの再使用可能メール許可証発行サービスへ接続するよう構成されたインターフェース手段、
    ｂ）再使用可能メール許可証発行サービスと再使用可能なメール許可証の有効性を検証するよう構成された検証手段、そして
    ｃ）許可証格納手段に格納するために、再使用可能メール許可証発行サービスから、更新された再使用可能なメール許可証を収集するよう構成された収集手段。
56. 検証手段と収集手段の処置を関連付ける独自の収集コードを生成するよう構成された収集コード生成手段をさらに備える請求項５５に記載のシステム。
57. 検証手段へ返された情報の結果、収集手段の動作を遅らせるよう構成された遅延手段をさらに備える請求項５４に記載のシステム。
58. ある事前に定義された送信者からの着信ｅメールに応答して、再使用可能なメール許可証が添付されたｅメールを自動的に返信するよう構成された返信手段をさらに備える請求項５４に記載のシステム。
59. 前記抜き出し手段が、再使用可能なメール許可証の一応の受入れ可能性をチェックするよう構成されたチェック手段をさらに備える請求項５４に記載のシステム。
60. チェック手段が以下のものの１つ以上をチェックする請求項５９に記載のシステム、
    再使用可能なメール許可証の
    ａ）ＣＲＣ又は他の冗長性の情報、
    ｂ）価値、
    ｃ）満期期限、
    ｄ）発行者ＩＤ、
    ｅ）タイプ又はバージョンフィールド、又は
    ｆ）フラグ値。
61. 受入れ可能な再使用可能なメール許可証が添付されていない着信ｅメールを拒絶するよう構成された拒絶手段をさらに備える請求項５４に記載のシステム。
62. 拒絶手段が以下のものをさらに備える請求項６１に記載のシステム、
    ａ）着信ｅメールの送信者へチャレンジｅメールを生成して返信するよう構成されたチャレンジ手段、そして
    ｂ）チャレンジｅメールへのレスポンスの有効性をチェックするよう構成されたレスポンスチェック手段。
63. 拒絶手段が以下のものをさらに備える請求項６１に記載のシステム、
    ａ）チャレンジ・プロセスの間、着信ｅメールを格納するよう構成されたｅメール格納手段、そして
    ｂ）一旦チャレンジが満足に応答されたなら、ｅメール格納手段から着信ｅメールを検索するよう構成された検索手段。
64. 格納されてから設定時間が経過した後、ｅメール格納手段から着信ｅメールを取り除くよう構成されたタイムアウト手段をさらに備える請求項６３に記載のシステム、
65. チャレンジｅメールが、再使用可能なメール許可証の添付を可能にするソフトウエアをインストールする方法についての指示を含む請求項６２に記載のシステム。
66. チャレンジｅメールが着信ｅメールを受け入れる理由を求め、レスポンスチェック手段が、受信者に理由を提示して、受信者から処理の委任を得るように構成された検証手段をさらに備える請求項６２に記載のシステム。
67. チャレンジ手段が、チャレンジｅメールを返信する前にレスポンス管理サービスから助言を求めるように構成された助言要請手段をさらに備える請求項６２に記載のシステム。
68. 助言要請手段が、レスポンス管理サービスへの提出用に着信ｅメールの少なくとも１つのコード化されたシグネチャを生成するよう構成されたシグネチャ生成手段を備える請求項６７に記載のシステム。
69. 助言要請手段が着信ｅメールの処理を行なうように構成された手段をさらに備え、その処理が以下のものの１つ以上を含む請求項６７に記載のシステム、
    ａ）着信ｅメール削除する、
    ｂ）着信ｅメールを受信者に送達する、
    ｃ）着信ｅメールにチャレンジする、
    ｄ）そのｅメールに関するさらなる情報をレスポンス管理サービスに送る、あるいは
    ｅ）レスポンス管理サービスに着信ｅメールを再提出する前に一定時間遅らせる。
70. 再使用可能メール許可証発行サービスから新しい再使用可能なメール許可証を購入するよう構成された購入手段をさらに備える請求項５５に記載のシステム。
71. 再使用可能なメール許可証が価値を示すフィールドを含み、再使用可能なメール許可証を現金、価値又は再使用可能メール許可証発行サービスにおける等価の製品又はサービスと引換えるよう構成された引換え手段をさらに備える請求項５５に記載のシステム。
72. 送信者による受信者へのｅメールの送信を規制するシステムであって、そのシステムは以下を備える：
    ａ）送信者からの発信ｅメールを受け入れるよう構成された第１送信手段、
    ｂ）発信ｅメールを受信者に送るよう構成された第２送信手段、
    ｃ）少なくとも１つの再使用可能なメール許可証を格納するよう構成された許可証格納手段、そして
    ｄ）許可証格納手段から取り出した少なくとも１つの再使用可能なメール許可証を、第１送信手段に受け入れられた第２送信手段に送る前の発信ｅメールに添付するよう構成された添付手段。
73. 受信者が再使用可能なメール許可証を利用することができるかを判定するよう構成された判定手段を備え、受信者が再使用可能なメール許可証を利用することができれば、添付手段が、発信ｅメールに前記再使用可能なメール許可証を添付するようにのみ構成されている請求項７２に記載のシステム。
74. 前記判定手段が、受信者によるｅメールの受信のために添付される必要のある再使用可能なメール許可証の価値を判定するようにも構成されている請求項７３に記載のシステム。
75. 十分に価値のある再使用可能なメール許可証がｅメールへの添付に使用可能でない場合に、ｅメールの送信者に通知するように構成された請求項７４に記載のシステム。
76. 再使用可能なメール許可証がｅメールへの添付に使用可能でない場合に、ｅメールの送信者に通知するように構成された請求項７２に記載のシステム。
77. 受信者が再使用可能なメール許可証を利用できると判定されない場合に、前記ｅメールを格納するよう構成され、第２送信手段が、その際、再使用可能なメール許可証を添付することができるとして送信者を特定するデータを添付するよう構成された請求項７３に記載のシステム。
78. 受信者からのチャレンジｅメールレスポンスを受信し、チャレンジｅメールレスポンスに従って格納されたｅメールを処理するよう構成された受信手段を備える請求項７７に記載のシステム。
79. 前記受信手段が格納されたｅメールを削除する処理を行なうよう構成された請求項７８に記載のシステム。
80. 受信手段が、受信者によって要求された再使用可能なメール許可証の値を見いだすようチャレンジｅメールレスポンスを解釈し、前記要求を満たすために十分な再使用可能なメール許可証を添付して格納されたｅメールを受信者へ再送する処理を行なうよう構成された請求項７８に記載のシステム。
81. 受信者への将来のｅメールで使用するために、受信手段が、受信者の再使用可能なメール許可証能力と、受信者によって要求される再使用可能なメール許可証の値を判定手段から知るよう構成された請求項８０に記載のシステム。
82. 送信者と受信者の間のｅメール通信を規制するシステムであって、そのシステムは、受信者への発信ｅメールに再使用可能なメール許可証を添付する送信者側の手段を備え、送信者が、再使用可能なメール許可証を持たない受信ｅメールをブロックし、かつ再使用可能なメール許可証を持った受信ｅメールから前記再使用可能なメール許可証を抜き出すよう構成され、前記抜き出された再使用可能なメール許可証が、再使用可能メール許可証発行当局によって確認されれば交換され、後に受信者によって他の受信者へ送られる発信ｅメールへの添付用として保管される。
83. 受信者が、受け取った再使用可能なメール許可証の値をチェックし、かつ十分に価値のある再使用可能なメール許可証を持たない受信ｅメールをブロックするよう構成された請求項８２に記載のシステム。
84. 受信者が、後に受信者又は他の受信者へ送信者によって送られる発信ｅメールに添付される再使用可能なメール許可証を持つさらなるｅメールで送信者に応答するよう構成された請求項８２に記載のシステム。
85. 送信者が、再使用可能メール許可証発行サービスからさらなる再使用可能なメール許可証を購入することができる請求項８２に記載のシステム。
86. 受信者によって受け取られた許可証を遠隔から検証するよう構成された遠隔検証手段を備え、各受信者が、前記遠隔検証手段によって検証されていない再使用可能なメール許可証を持つｅメールをブロックするよう構成されたブロッキング手段を備える請求項８２に記載のシステム。
87. 送信者から受信者へのｅメールの送信及び受信者によるｅメールの受信を規制するコンピュータソフトウエアプログラムであって、そのプログラムが送信者から受信者への発信ｅメールに再使用可能なメール許可証を添付するよう構成され、そのプログラムがさらに、他の送信者からの再使用可能なメール許可証を持たない受信ｅメールをブロックするよう構成され、受信者が、受信ｅメールから再使用可能なメール許可証を抜き出し、再使用可能なメールを後で受信者によって他の受信者へ送られる発信ｅメールへの添付用として格納することができる。

Images