(57)【要約】【課題】  可変価格設定および条件付き償還により、迷惑電子メッセージを低減する方法およびシステムを提供すること。【解決手段】  各チケットは、電子メッセージの送信者によって指定される関連値を有することが可能である。これは、「可変価格設定」と呼ばれる。メッセージのチケットは、チケットサーバがその値のチケットを償還する保証として作用する。チケットを有するメッセージをレビューすると、受信者は、チケットを償還することを選択することが可能であり、これは、「条件付き償還」と呼ばれる。チケットが償還される場合、チケットサーバは、送信者のアカウントを借り方に記入し、その結果、送信者は、メッセージを送信するために実際に支払ったことになる。【選択図】  図２
2005243031.tif 000002
【特許請求の範囲】
【請求項１】
迷惑電子メッセージを低減する方法であって、
チケットエンティティからチケットを獲得し、前記チケットはメッセージの送信者によって指定された値を有すること、
前記獲得チケットを前記メッセージに付加すること、および
前記付加チケットを有する前記メッセージを受信者に送ることを備え、
前記メッセージを受信すると、前記受信者は、前記チケットエンティティから前記チケットの前記値を条件付きで償還することができることを特徴とする方法。
【請求項２】
前記獲得チケットは送信者認証コードを含み、それにより前記メッセージを受信するメールサーバは前記メッセージの前記送信者を認証することができることを特徴とする請求項１に記載の方法。
【請求項３】
チケットのブロックは、前記チケットエンティティから一度に獲得されることを特徴とする請求項１に記載の方法。
【請求項４】
前記ブロックの各チケットは、１方向機能を使用して開始コードから生成されるコードのシーケンスからのコードを含むことを特徴とする請求項３に記載の方法。
【請求項５】
前記チケットは、コードの生成とは反対の順序でメッセージに付加されることを特徴とする請求項４に記載の方法。
【請求項６】
メールサーバは、コードの前記シーケンスの終了コードを備え、前記メッセージのチケットが、前記終了コードを導出することができる元のコードを含むかを判定することを特徴とする請求項４に記載の方法。
【請求項７】
前記受信者メールシステムは、前記メッセージを前記受信者に提示する前に、前記チケットエンティティで前記チケットを確認することができることを特徴とする請求項１に記載の方法。
【請求項８】
前記受信者メールシステムは、前記受信者によって設定された閾値より低いチケット値を有するメッセージを自動的に破棄することができることを特徴とする請求項１に記載の方法。
【請求項９】
前記受信者が前記チケットを償還するとき、前記送信者のアカウントが借り方に記入されることを特徴とする請求項１に記載の方法。
【請求項１０】
前記受信者が前記チケットを償還するとき、前記受信者のアカウントが貸し方に記入されることを特徴とする請求項１に記載の方法。
【請求項１１】
前記メッセージは、電子メールメッセージであることを特徴とする請求項１に記載の方法。
【請求項１２】
電子メッセージを低減するシステムであって、
電子メッセージの送信に使用されるチケットを発行し、かつ要求時にチケットを償還するチケットエンティティと、
送信者によって送信されたメッセージに発行チケットを付加し、前記送信者が各メッセージの値を指定する、送信者メッセージシステムと、
受信者が前記チケットエンティティからチケットを条件付きで償還することを可能にする受信者メッセージシステムとを備えることを特徴とするシステム。
【請求項１３】
送信者によって送信されるチケットは、送信者認証コードを備え、送信者メッセージサーバは、前記送信者認証コードに基づいて前記送信者を認証することを特徴とする請求項１２に記載のシステム。
【請求項１４】
前記送信者認証コードは、１方向機能によって生成されるコードのシーケンスの１つであり、前記送信者メッセージサーバは、前記シーケンスの終了コードを有し、それにより、前記送信者メッセージコードは、メッセージの前記送信者認証コードから前記終了コードを導出することができるかを検証することができることを特徴とする請求項１３に記載のシステム。
【請求項１５】
前記送信者メッセージサーバは、コードの前記シーケンスを生成し、かつそれらを発行チケットに含むことを特徴とする請求項１４に記載のシステム。
【請求項１６】
送信者メッセージクライアントは、コードの前記シーケンスを生成して、前記シーケンスの末端コードを前記送信者メッセージサーバに提供することを特徴とする請求項１４に記載のシステム。
【請求項１７】
前記受信者メッセージシステムは、閾値より小さいチケット値を有するメッセージを自動的に破棄することを特徴とする請求項１２に記載のシステム。
【請求項１８】
前記破棄されたメッセージの前記チケットは、自動的に償還されることを特徴とする請求項１７に記載のシステム。
【請求項１９】
前記受信者メッセージシステムは、前記メッセージの前記チケット値に基づいた順序で前記受信者にメッセージを提示することを特徴とする請求項１２に記載のシステム。
【請求項２０】
前記受信者メッセージシステムは、チケットを償還することができるかを前記チケットエンティティで確認することを特徴とする請求項１２に記載のシステム。
【請求項２１】
前記受信者メッセージシステムは、チケットを確認することができないメッセージを破棄することを特徴とする請求項２０に記載のシステム。
【請求項２２】
電子メッセージを処理するコンピュータシステムによって実施される方法であって、
チケットエンティティによって発行されるチケットを有する電子メッセージを受信し、前記チケットは、送信者によって指定される値を有すること、
前記電子メッセージを受信者に提示すること、
前記受信者が前記チケットを償還することを示す場合、償還のために、前記チケットを前記チケットエンティティに提出し、前記チケットエンティティが、前記チケットの値について前記送信者に請求すること、および
前記受信者が前記チケットを償還することを示さない場合、前記チケットの前記償還を阻止し、それにより、受信者はチケットを条件付きで償還することができることを備えることを特徴とする方法。
【請求項２３】
前記償還は、前記送信者の勘定残高を減少させ、かつ前記受信者の勘定残高を増大させることを含むことを特徴とする請求項２２に記載の方法。
【請求項２４】
送信者のアカウントおよび受信者のアカウントは、同じエンティティによって保持されることを特徴とする請求項２２に記載の方法。
【請求項２５】
送信者のアカウントおよび受信者のアカウントは、異なるエンティティによって保持されることを特徴とする請求項２２に記載の方法。
【請求項２６】
前記送信者のアカウントを保持するエンティティは、前記受信者のアカウントを保持するエンティティに値を転送することを特徴とする請求項２５に記載の方法。
【請求項２７】
前記チケットを前記受信者に提示する前に、前記チケットを償還することができることを確認することを含むことを特徴とする請求項２２に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
記述される技術は、一般に、電子メッセージの処理に関し、より具体的には、迷惑メッセージを低減する方法およびシステムに関する。
【背景技術】
【０００２】
電子メッセージの送信および受信に関連するコストは、そのようなメッセージを送信または受信する限界コストがほぼゼロである点まで著しく低減された。したがって、商用および他のエンティティは、膨大なコストを負担せずに、数百万のメッセージを送信することができる。例として、インターネット宣伝エンティティは、１００万のアドレスに付き１９０ドルの割合で、数百万のアドレスのリストから収集された有効電子メールアドレスに電子メッセージを送信することを提供することが可能である。そのような低コストは、一般に「スパム」と呼ばれ、毎日世界中に送信されると推定される１３０億を超える迷惑電子メールの急増に寄与した。２００３年８月４日、１つのメールシステムが、その日に処理した２６億の電子メールのうち、２１億の電子メッセージをスパムであると自動的に分類した（非特許文献１参照）。
【０００３】
ろ過、チャレンジ／レスポンス、規制、訴訟、および価格設定の技法を含めて、いくつかの技術が、スパムを低減するために現在使用されている。
【０００４】
ろ過の技法は、メッセージの様々な属性に基づいて入りメッセージを分類することが可能である。インターネットサービスプロバイダ（「ＩＳＰ」）が、例えば、メッセージが有効な送信者の電子メールアドレスを含んでいないことを認識することによって、入りメッセージをスパムと分類することが可能である。受信者が、規則を使用して、入りメッセージを分類して、適切にスパムを識別および処理することが可能である。例として、電子メールクライアントプログラムのユーザが、テキスト「＄＄＄」を含む件名ヘディングを有するすべての入りメッセージを削除アイテムフォルダに移動させるように、「インボックスルール」をセットアップすることが可能である。ろ過の技法に関する問題は、メッセージの商用送信者（例えば、「スパマ」）が、メッセージがスパムとして分類されないことを保証するように、自分のメッセージを既知のフィルタまたは商用に使用されているフィルタに適合させることである。その結果、フィルタは、これらの適合に遅れずに付いて行くために、膨大な量の手作業による介入を必要とする可能性がある。ろ過の技法に関する他の問題は、フィルタ規則が、意図した受信者が受信することを望む可能性があるメッセージをスパムとして不注意に分類する可能性があることである。
【０００５】
チャレンジ／レスポンスの技法は、例えば送信者が人間であることを実証するために、送信者を必要とする可能性がある。例として、送信者は、図面において対象物を識別することを必要とされるなど、チューリング試験を試される可能性がある。この手法に関する問題は、初期チャレンジを処理して、チャレンジに対する応答を確認するために、媒介が必要とされることである。受信者が自動メーリングリストに参加する場合、または自動システムを使用してサービスプロバイダから正当なメッセージを受信する場合、受信者は、メッセージを受信しないことになるが、その理由は、自動システムは、（当然、試験の目的である）チューリング試験に応答することができない可能性が高いからである。そのような場合、受信者は、送信者がメッセージを受信者に送信することを許可されていることを手作業で示すことが必要である可能性がある。
【０００６】
規制の技法は、スパムを低減することを目的とする法律を導入することを含むことが可能である。例として、スパム対策法（ＣＡＮ  ＳＰＡＭ  Ａｃｔ）（「Ａｃｔ］）は、迷惑商用宣伝を普及させようとして、電子メッセージのヘッダ情報を故意に偽造する者に対して刑事的制裁を課す。Ａｃｔは、迷惑商用電子メッセージの受信を拒否することを望む受信者の「ｄｏ−ｎｏｔ−ｓｐａｍ」レジストリを創出するために、連邦遠隔通信会議（Ｆｅｄｅｒａｌ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｃｏｍｍｉｓｓｉｏｎ）をも必要とする。規制の技法に関する問題は、たとえ言論の性質が商用である場合でも、言論の自由を奪う可能性があることである。これらの技法に関する別の問題は、司法上の事項のために、国外スパマを摘発することが、不可能ではないにしても、困難である可能性があることである。
【０００７】
訴訟の技法は、スパムを低減するために、裁判制度を使用する。例として、カルフォニア最高裁判所が２００３年６月に判決が示されたインテル（Ｉｎｔｅｌ）対ハミディ（Ｈａｍｉｄｉ）では、被告は、大量の商用電子メッセージを送信することによって、これらのメッセージによりコンピュータシステムに悪影響がある場合、動産を侵害したとして有罪になり得る（すなわち、仲介者以外の誰かに属する個人特性での意図的な仲介）。同様に、コンピュサーブ（ＣｏｍｐｕＳｅｒｖｅ）は、企業エンティティが数千万の迷惑商用メッセージを顧客に送信した後、１９９７年の動産侵害訴訟に勝訴した。訴訟の技法に関する問題は、非常に高価なことである。膨大な経済的または他の損害に耐えることができるＩＳＰおよび他の大規模エンティティのみが、訴訟を起こすことが可能である可能性が高い。
【０００８】
価格設定の技法は、電子メッセージの送信について送信者に料金を課す、または、メッセージを送信する前に、計算タスクを実施することを送信者に要求することが可能である。例として、２００３年、ＩＳＰは、大容量電子メッセージをＩＳＰの顧客に送信するのに、送信者に料金を課すことを開始した。この技法に関する問題は、受信者がどのメッセージを受信するかをＩＳＰが制御することである。さらに、ＩＳＰによって提供された電子メッセージアドレスを有する複数の受信者が、メーリングリストに参加することを望む場合、ＩＳＰは、メーリングリストへのメッセージを大容量電子メッセージとして扱い、送信者が料金を支払うことを要求する可能性がある。メーリングリストの送信者が支払いを拒否する場合、受信者は、メッセージを受信しない可能性がある。
【０００９】
送信者が、メッセージを送信する前に、計算タスクを実施することを要求され、メッセージの受信者が、計算タスクが実際に実施されたことを確認することができる場合、大容量メッセージの送信者は、必要な計算を単一コンピューティングデバイスで安価に実施することができない可能性がある。例として、計算タスクを実施するのに０．５秒かかる場合、百万のメッセージの送信者が、実施にかかる時間のために、メッセージを送信することができなくなる可能性があるが、単一メッセージの送信者は、メッセージの送信を妨害されない。しかし、非常に高速なコンピュータ（例えば、「スーパーコンピュータ」）を使用することができる、または大量のマシンを集めて、計算を実施し、メッセージを送信することができる（例えば、信用のあるコンピュータに「トロイの木馬（ｔｒｏｊａｎ  ｈｏｒｓｅｓ）」をインストールすることによって）ことができる送信者は、メッセージを送信することができる。
【００１０】
スパムに関する他の問題は、より一般的には「なりすまし（スプーフィング）」と呼ばれる偽装である。「ｔｒｏｊａｎ  ｈｏｒｓｅｓ」プログラムまたはウィルスプログラムが、ユーザを偽装することが可能である。ｔｒｏｊａｎ  ｈｏｒｓｅｓプログラムは、疑われていないユーザが、ユーザによって通常は所望されない第２の意図されていない機能をも実際には実施する機能を実施するように、意図的にインストールするコンピュータプログラムである。ウィルスは、例えば電子メールを介して、１つのコンピュータから他へしばしば拡散し、実行されるときに所望されない機能をも実施するコンピュータプログラムである。所望されない機能は、ｔｒｏｊａｎ  ｈｏｒｓｅｓまたはウィルスプログラムが存在するコンピュータのユーザの電子メールアドレスからこれらのメッセージが送信されたことを示す電子メッセージを送信することである可能性がある。その結果、正当な送信者の名前においてであるが、その送信者の意図に反して、スパムが送信されることがある。
【００１１】
【非特許文献１】Martin Abadi et al., "Bankable Postage for Network Services," Springer-Verlag, 2003)
【発明の開示】
【発明が解決しようとする課題】
【００１２】
これらの技法のそれぞれは、上述したように、様々な欠点を有する。上述した問題のいくつかまたはすべてを回避する、スパムを低減する技法を有することが所望される。
【課題を解決するための手段】
【００１３】
迷惑電子メッセージを低減する方法およびシステムが開示される。一実施形態では、送信者は、送信者によって指定された値（例えば、１ドル）で、チケットエンティティからチケットを獲得する。送信者は、メッセージを送信する前に、チケットをメッセージに付加する。メッセージを受信すると、受信者は、チケットエンティティでチケットを確認することができる。有効であれば、受信者は、チケットエンティティからチケットの値を条件付きで償還（ｒｅｄｅｅｍ）することができる。
【発明を実施するための最良の形態】
【００１４】
可変価格設定および条件付き償還により、迷惑電子メッセージを低減する方法およびシステムが提供される。一実施形態では、迷惑電子メッセージを低減するシステムは、チケットサーバ、送信者メールサーバ、送信者のメールクライアント、および受信者のメールシステム（サーバまたはクライアント）間の相互作用を含む。送信者は、チケットサーバにチケットを要求して、チケットサーバからチケットを受信することが可能である。各チケットは、送信者によって指定される関連値を有することが可能である。値は送信者によって指定されるので、これは、「可変価格設定（ｖａｒｉａｂｌｅ  ｐｒｉｃｉｎｇ）」と呼ばれる。チケットは、チケットサーバが、要求された場合に関連値のチケットを償還する保証として作用する。送信者は、受信者に送信されるメッセージにこのチケットを付加することが可能である。送信者がメッセージを送信するとき、送信者メールサーバは、送信者から来る際に認証することができるチケットをメッセージが含むかを判定することが可能である。チケットを認証することができない場合、送信者メールサーバは、メッセージを転送せずに、単にメッセージを破棄することができる。メッセージが転送される場合、受信者のメールシステムは、チケットが償還可能であることを保証するために、チケットサーバでチケットを確認することが可能であり、かつ、チケットに関連付けられた値に基づいて、メッセージを分類することが可能である。チケットを確認することができない場合、受信者のメールシステムは、メッセージを破棄することが可能である。確認されたチケットを有するメッセージをレビューすると、受信者は、チケットサーバからチケットを償還することを選択することが可能である。受信者は、チケットを償還するかの選択肢を有するので、これは、「条件付き償還」と呼ばれる。チケットが償還される場合、チケットサーバは、送信者のアカウントを借り方に記入（ｄｅｂｉｔ）し、その結果、送信者は、メッセージを送信するために実際に支払ったことになる。一実施形態では、チケットサーバは、受信者がメッセージを見て、チケットを償還するインセンティブとして、償還値の一部を受信者のアカウントを貸し方に記入（ｃｒｅｄｉｔ）することが可能である。
【００１５】
可変価格設定および条件付き償還を使用することによって、システムは、迷惑電子メッセージを送信するコストを押し上げることによって、迷惑電子メッセージを低減することができる。まず、受信者のメールシステムが、償還することができるチケットを各受信メッセージが含むかを判定することができる。メッセージがそのようなチケットを含まない場合、受信者のメールシステムは、それを破棄して、それをジャンクメールフォルダに配置する、または受信者の指示に従ってある他の行為を自動的に取ることができる。受信者のメールシステムは、チケットの値に基づいてメッセージを分類することもできる。次いで、受信者は、高い値のチケットを有するメッセージを見て、他のメッセージを見ることを先送りすることができる。受信者は、受信される最小限のチケット値を指定することさえ可能である。例えば、受信者は、メールシステムが、１ドルより小さいチケット値を有するすべてのメッセージを履きすることを望むことが可能である。受信者のメールシステムは、１ドルより小さいチケット値を有するメッセージを送信したすべての送信者に、より高いチケット値を有するメッセージを再送信するように自動的に通知することが可能である。代替として、当事者は、当事者間のすべてのメッセージにおいて少なくとも１ドルのチケット値を含むことに合意することが可能である。そのような場合、受信者のメールシステムは、１ドルより小さい値を有するすべてのチケットを自動的に償還し、次いで、送信者に通知せずに、それらのメッセージを破棄することができる。受信者が１ドルより大きいチケット値を有するメッセージを受信する場合、受信者は、送信者が、受信者がメッセージを受信することを望む者からである場合、チケットを償還しないことを選択することができる。代替として、受信者は、チケットを償還して、送信者が未知である場合、メッセージを自動的に削除することを選択することができる。
【００１６】
したがって、可変価格設定および条件付き償還の使用により、迷惑電子メッセージを制御する有効な方式が提供される。受信者は、迷惑メッセージの送信者には法外に高価であるように高く、最小限のチケット値を設定することができる。例えば、スパムが１ドルのチケット値で１，０００，０００の受信者に送信される場合、各チケットが償還される場合、スパマに１，０００，０００ドルのコストがかかる。対照的に、受信者がメッセージを受信することを望む送信者には、より少なくコストがかかるが、その理由は、ある受信者は、受信を望むメッセージのチケットを償還しないからである。さらに、メッセージを読む可能性がより高い人々をメッセージの対象とすることによって、スパマの宣伝金は、より有効に支出される。その結果、スパマは、メッセージに興味を持つ可能性があり、したがってチケットを償還しない可能性がある、または少なくともメッセージを読む受信者により限定してメッセージを集中させることが必要である。チケットの償還により、少なくともそのチケット値については、受信者がその送信者からさらにメッセージを受信することに興味がないことを送信者に示すことができる。
【００１７】
可変価格設定のために、異なる送信者が、メッセージに付ける値に応じて、同等なメッセージについて異なる値を指定することが可能である。受信者は、低いチケット値を有するメッセージを見ない可能性が高いので（チケットを償還するが）、送信者は、選択受信者がメッセージを少なくとも見る、またおそらくはチケットを償還しないことを望んで受信者を識別するとき、チケット値を増大させて、より選択的であるように動機付けられる可能性がある。送信者は、増大したチケット値の全値を失う危険が依然としてあるので、システムは、メッセージに真に興味がある者にのみ受信者を限定するように、送信者を動機付ける。試行およびエラーのプロセスにより、送信者は、メッセージに非常に興味があるので、比較的高い値を有するチケットを償還しない受信者、またはメッセージを見る可能性が高い受信者のリストを確立することができる可能性がある。信頼されるエンティティは、受信者がチケットを償還した情報を提供することが可能であり、それにより、送信者は、それらの受信者をメーリングリストから外す、またはメッセージを読まずに削除した受信者に送信されたチケットの値を増大させることができる。あるチケット値では、送信者が受信者にメッセージを送信する費用効果は高くない。
【００１８】
一実施形態では、送信者メールサーバは、メールサーバを経て送信されたメッセージに最小限のチケット値を強制することが可能である。そのような場合、送信者メールサーバは、最小限のチケット値を有していないメッセージを受信すると、送信者に通知して（送信者が偽装者ではないことを想定する）、メッセージを破棄することができる。
【００１９】
したがって、価値があると受信者が見なすメールを受信者が選択的に読むようにすることによって、システムは、市場が、様々な迷惑メッセージについて適切な値を決定することを可能にする。
【００２０】
送信者メールサーバは、偽装者が送信者を偽装するのを防止するように作用することができる。偽装されるのを防止することを望む送信者は、メールクライアントに、終了コードを信用エンティティに登録させることができる。終了コードは、１方向機能（ｏｎｅ−ｗａｙ  ｆｕｎｃｔｉｏｎ）を、開始コードで開始する、以前の適用によって生成されたコードにうまく適用することによって生成されるコードのシーケンスの最終コードを表す（１方向機能は、入力が与えられると値を比較的容易に計算するが、その反対は、計算が比較的難しい機能である、すなわち、値が与えられた場合、入力を導出するのは困難である）。１方向機能の適用により、開始コードで開始し、終了コードで終了するコードのシーケンスが生成され、開始コードと終了コードとの間にいくつかの中間コードがある。そのようなコードは、これ以後、「送信者認証コード」または単に「コード」と呼ばれることが可能である。送信者から登録要求を受信すると（送信者の要求を偽装することができないように、安全な機構を介して）、信用エンティティは、終了コードを送信者メールサーバに提供する。送信者のメールクライアントは、終わりから２番目のコードで開始する、送信者が生成とは反対の順序で送信するシーケンスのコードを各メッセージに付加することができる。送信者メールサーバが送信者のメールクライアントからメッセージを受信するとき、送信者メールサーバは、メッセージに含まれるコードを使用して終了コードを導出することができるかを検証することができる。そうである場合、送信者メールサーバは、メッセージが、偽装者ではなく、送信者によって送信されたことを認識する。送信者メールサーバがコードを検証することができない場合、送信者メールサーバは、送信者が偽装されていると想定して、メッセージを破棄することが可能である。偽装者がともかくもメッセージを傍受して、そのコードを盗用する場合、偽装者は、１つのメッセージを偽装するために、そのコードを使用することがおそらくはできる。しかし、偽装者は、あらゆる他のメッセージを送信するために、そのコードを使用することはできない。その理由は、シーケンスの以前のコードを識別することが非常に困難であるからであり、これが、１方向機能が使用される理由である。偽装者は、シーケンスの次のコードを生成することができるが、送信者メールサーバは、そのコードを有するメッセージをすでに受信していることになり（送信者のメールクライアントが、生成とは反対の順序で、メッセージにコードを付加すると想定する）、メッセージが複製コードを含むので、メッセージを破棄する。
【００２１】
各チケットは、１方向機能によって生成されたシーケンスのコードを含むことが可能である。そうである場合、チケットサーバがコードのシーケンスを生成して、チケットサーバが送信者に提供するチケットにそれらのコードを埋め込むことが適切である可能性がある。チケットがシーケンスのコードを含む場合、送信者のメールクライアントは、コードのシーケンスの生成とは反対の順序に基づいて、チケットをメッセージに付加するべきである。上述したように、送信者メールサーバは、シーケンスの終了コードを有するので、送信者メールサーバは、各チケットが適切なコードを有するかを検証し、したがって、送信者が偽装されていないことを検証することができる。当業者なら、送信者認証コードを必要とせずに、チケットを使用することができ、チケットを使用せずに、送信者認証コードを使用して送信者を認証することができるという点で、チケットおよびコードを独立に使用することができることを理解するであろう。
【００２２】
チケットをメッセージに付加するとき、送信者は、送信者および受信者の両方によって信頼される信用エンティティの指示を付加することも必要であるとすることが可能である。信用エンティティは、チケットを発行したチケットサーバを制御する。この信用エンティティは、金融エンティティまたは送信者のＩＳＰとすることが可能である。このエンティティは、送信者がチケットを獲得することによって貸し方に記入する送信者のアカウントを有することが可能である。このエンティティは、受信者のアカウントを有することも可能であり、または、受信者のアカウントを有する他のエンティティで、値の転送を調整することが可能である。
【００２３】
メッセージを受信すると、受信者メールサーバは、メッセージにおいて指示されることが可能である信用エンティティと連絡を取ることによって、または、メッセージのチェックサムもしくはデジタル署名をチェックすることによって、チケットを確認することが可能である。チケットを確認すると、信用エンティティは、チケットが確認されたことを通知して、そのチケットが再び首尾よく確認されることを防止することが可能である。信用エンティティは、当然、チケットが１回のみ償還されることを可能にする。したがって、送信者は、複数のメッセージを送信するために、１つのチケットを使用することができず、受信者（またはあらゆる他の当事者）は、チケットを複数回償還することはできない。確認および償還の追跡を容易にするために、各チケットは、チケットサーバによって割り当てられ、かつデジタル方式で署名される固有の識別を有することが可能である。
【００２４】
受信者の電子メールシステムは、チケットに関連付けられた値に基づいて、入りメッセージを分類することが可能である。例として、メッセージがチケットを有していない場合、または値のないチケットを有する場合、プログラムは、メッセージを「フリー」フォルダに移動させることが可能である。しかし、メッセージが、受信者によって以前に示された閾値を超える値を有するチケットを含む場合、メールシステムは、メッセージを以前に示されたフォルダに移動させることが可能である。この閾値は、個人の好みであるので、１人のユーザが、１ドルより小さい値を有するすべてのチケットを自動的に償還して、それらのメッセージを破棄することを選択することが可能であり、他のユーザが、５０セントより大きいチケット値を含むすべてのメッセージを読み、それらのチケットを任意選択で償還することを選択することが可能である。メッセージをレビューすると、受信者は、チケットを償還することを選択することが可能である。例として、メッセージが同僚または知人からである場合、受信者は、チケットを償還しないことを選択することが可能である。しかし、メッセージがスパムである場合、受信者は、チケットを償還することを選択することが可能である。受信者がチケットを償還する場合、受信者のメールシステムは、送信者のアカウントからの値を借り方に記入して、受信者のアカウントを貸し方に記入するように、信用エンティティに要求する。受信者が、信用エンティティのアカウントを有してない場合、受信者は、受信者がアカウントを有する第２エンティティを示すことが可能である。その場合、送信者の信用エンティティは、第２エンティティの受信者アカウントにチケット値を転送することが可能である。受信者がチケットを償還することを選択しない場合、送信者のアカウントは、借り方に記入されない。しかし、チケットは、それにもかかわらず、チケットが償還されていないことを受信者が送信者に通知する場合でも、チケットが再び使用されることは可能ではない。信用エンティティは、送信者、受信者、ＩＳＰ、およびこれらのサービスのその他に料金を請求することが可能である。
【００２５】
チケットをチケットサーバに要求することは、比較的高い取引きコストを有することがあるので、送信者および信用エンティティは、チケット獲得が比較的大きいブロックにおいて行われることを望む可能性がある。チケットは、送信者によって要求される様々な関連値を有することが可能である。例として、チケットは、３７セントまたは１ドルの値を有することが可能である。チケットを要求するとき、送信者は、１０００のチケットなど、チケットの大きなブロックを要求することが可能である。それぞれが３７セントの値のチケットを有する１０００チケットのブロックは、全体で３７０ドルの値を有する。同様に、それぞれが１ドルの値のチケットを有する１００チケットのブロックは、全体で１００ドルの値を有することが可能である。代替として、ブロックは、様々な値を有するチケットを有することが可能である。例として、１０００チケットのブロックは、値のない５００のチケットと、それぞれが３７セントの値を有する４００のチケットと、それぞれが１ドルの値を有する１００チケットとを備えることが可能である。そのようなブロックは、全体で２４８ドルの値を有することが可能である（すなわち、０ドル×５００＋０．３７ドル×４００＋１ドル×１００）。様々な値を有するチケットのブロックは、チケットが送信者認証コードをも含む場合、実用的ではない可能性があるが、その理由は、ブロックのチケットは、特定な順序で送信される必要があるからである。チケットは、代替として、固定価格（例えば、５セント）を有することが可能であり、そのような場合、送信者は、複数のチケットをメッセージに付加することによって、可変価格設定を実施することができる。
【００２６】
送信者のアカウントは、信用限度（ｃｒｅｄｉｔ  ｌｉｍｉｔ）を有することが可能である。送信者がチケットエンティティからチケットを獲得するとき、送信者は、送信者の勘定残高（ａｃｃｏｕｎｔ  ｂａｌａｎｃｅ）を増大させるために、これから信用限度を引き出す。受信者がチケットを償還するとき、送信者の勘定残高は、償還された量（ａｍｏｕｎｔ）だけ減少する。チケットエンティティは、獲得チケットの値と送信者のアカウントの現在バランスとの差について、送信者に定期的に請求することが可能である。
【００２７】
チケットは、ある時間期間が経過した後、満了することが可能である。例として、メッセージの送信者は、メッセージが送信された後１週間でチケットが満了することを示すことが可能である。代替として、チケットサーバは、チケットの確認後ある時間期間が経過した場合、チケットが償還されないようにすることが可能である。送信者またはチケットエンティティは、この時間期間を指定することが可能である。送信者は、財政上の債務残高（ｆｉｎａｎｃｉａｌ  ｅｘｐｏｓｕｒｅ）を限定することを試みて、満了期間を設定することが可能である（例えば、時間が限定された提供に関する宣伝を送信するとき）。チケットサーバは、システムリソースを効率的に使用することができるように、満了期間を課すことが可能である（例えば、発行チケットのデータベースから行を削除するために、または使用済みチケットをリサイクルするために）。チケットが償還されずに満了する場合、送信者は、チケット値を保持して、それをその後のチケット購入に適用することが可能である（すなわち、送信者の勘定残高は、そのチケット値について借り方に記入されない）。
【００２８】
ここで図を参照すると、図１は、可変価格設定および条件付き償還により迷惑電子メッセージを低減するシステムの実施形態を示すブロック図である。システムは、送信者コンピューティングデバイス１０２および受信者コンピューティングデバイス１０４を有する。送信者コンピューティングデバイスを使用して送信者によって構成されるメッセージは、ローカルエリアネットワークなどのネットワーク１０６を介して、送信者メールサーバ１０８に転送されることが可能である。送信者コンピューティングデバイス、ネットワーク１０６、送信者メールサーバ、受信者コンピューティングデバイス、およびチケットサーバ１１２は、すべて、インターネットなどのネットワーク１１０に接続されることが可能である。送信者コンピューティングデバイスは、送信者認証コードを含むチケットをチケットサーバから獲得することが可能である。送信者は、送信者コンピューティングデバイスを使用して送信者によって指定されたチケット値を有するチケットを備えるメッセージを構成する。送信者コンピューティングデバイスは、メッセージを送信者メールサーバに転送する。メッセージを受信すると、送信者メールサーバは、メッセージのコードを使用して終了コード（送信者コンピューティングデバイスがチケットを得たとき、チケットサーバから受信されることが可能である）を導出することができることを確認し、そうである場合、メッセージを受信者コンピューティングデバイスに転送する。メッセージを受信すると、受信者コンピューティングデバイスは、上述したように、チケットサーバでメッセージのチケットを確認して、チケット値に基づいてメッセージを処理することができる。
【００２９】
ユーザのコンピュータシステム、および可変価格設定および条件付き償還を使用して迷惑メッセージを低減するシステムは、中央処理ユニット、メモリ、入力装置（例えば、キーボードおよびポインティングデバイス）、出力装置（例えば、表示装置）、ならびに記憶装置（例えば、ディスクドライブ）を含むことが可能である。メモリおよび記憶装置は、生成システムを実施する命令を含むことが可能であるコンピュータ可読媒体である。さらに、データ構造およびメッセージ構造は、記憶されることが可能であり、または、通信リンクの信号など、データ送信媒体を介して送信されることが可能である。インターネット、ローカルエリアネットワーク、ワイドエリアネットワーク、または点間ダイアルアップ接続など、様々な通信リンクを使用することが可能である。コンピュータシステムは、パーソナルコンピュータ、携帯電話、携帯情報端末など、任意のタイプのコンピューティングデバイスとすることができる。コンピュータシステムは、任意のネットワークまたはメッセージのプロトコルを使用する通信リンクを使用することが可能である。
【００３０】
図１は、可変価格設定および条件付き償還を使用して迷惑メッセージを低減するシステムを実施することが可能である、適切な動作環境の例を示す。この動作環境は、適切な動作環境の単なる一例であり、生成システムの使用または機能の範囲を限定することを示唆することを意図していない。このシステムと共に使用されるのに適切とすることが可能である他の周知のコンピューティングシステム、環境、および／または構成には、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルド装置またはラップトップ装置、マルチプロセッサシステム、マイクロプロセッサベースシステム、プログラム可能消費者電子機器、ネットワークＰＣ，ミニコンピュータ、メインフレームコンピュータ、上記のシステムまたは装置のいずれかを含む分散型計算環境などがある。
【００３１】
可変価格設定および条件付き償還を使用して迷惑メッセージを低減するシステムは、１つまたは複数のコンピュータまたは他の装置によって実行されるプログラムモジュールなどのコンピュータ実行可能命令の一般的な文脈において記述されることが可能である。一般に、プログラムモジュールは、特定のタスクを実施する、または特定の抽象データタイプを実施するルーチン、プログラム、オブジェクト、構成要素、データ構造などを含む。通常、プログラムモジュールの機能は、様々な一実施形態において、所望されるように組み合わされ、または分散されることが可能である。
【００３２】
図２は、図１の構成要素をさらに詳細に示すブロック図である。構成要素は、送信者コンピューティングデバイス１０２のＲｅｑｕｅｓｔ＿Ｔｉｃｋｅｔｓ構成要素２０２およびＳｅｎｄ＿Ｍａｉｌ構成要素２０４、受信者コンピューティングデバイス１０４のＲｅｃｅｉｖｅ＿Ｍａｉｌ構成要素２０６、送信者メールサーバ１０８のＦｉｌｔｅｒ＿Ｏｕｔｇｏｉｎｇ＿Ｍａｉｌ構成要素２０８、ならびにチケットサーバ１１２のＲｅｑｕｅｓｔ＿Ｔｉｃｋｅｔｓ構成要素２１０、およびＴｉｃｋｅｔ＿Ｖａｌｉｄ構成要素２１２、Ｒｅｄｅｅｍ構成要素２１４を含む。これらの構成要素は、図３〜９に示す方法を実施するために、個別におよび集団的に動作する。追加の構成要素が存在する可能性もある（図示せず）。システムは、すべてのユーザが、安全で信頼性のあるメッセージシステムへのアクセスについて、強力で請求可能な識別を有することを必要とすることが可能である。
【００３３】
図３は、送信者コンピューティングデバイスによって実施されるＲｅｑｕｅｓｔ＿Ｔｉｃｋｅｔｓルーチンの実施形態を示す流れ図である。このルーチンは、チケットサーバにチケットを要求するために、送信者メールクライアントプログラムまたはある他のユーザエージェントによって呼び出されることが可能である。ルーチンは、ブロック３０２において開始される。ブロック３０４において、ルーチンは、所望のチケットに関する情報を収集する。例として、ルーチンは、所望されるチケットの数およびチケットの値を収集することが可能である。ルーチンは、メールクライアントプログラムのユーザからこの情報を収集することが可能であり、または、以前に記憶されたデータ構造からこの情報を取り出すことが可能である。ブロック３０６において、ルーチンは、チケットサーバのＲｅｑｕｅｓｔ＿Ｔｉｃｋｅｔｓルーチンを呼び出して、それを収集情報に渡す。そのルーチンは、図４に関して以下でさらに記述される。ブロック３０８において、ルーチンは、チケットサーバのＲｅｑｕｅｓｔ＿Ｔｉｃｋｅｔｓルーチンによって返されたチケット情報を記憶する。次いで、ルーチンは、ブロック３１０においてコーラ（ｃａｌｌｅｒ）に戻る。返されたチケットは、メッセージに含むことができる。
【００３４】
図４は、チケットサーバによって実施されるＲｅｑｕｅｓｔ＿Ｔｉｃｋｅｔｓルーチンの実施形態を示す流れ図である。チケットサーバは、送信者が送信した電子メッセージについて送信者に請求する能力を有する信用エンティティによって所有されることが可能である。システムは、金融または非金融の請求エンティティと共に機能することが可能である。したがって、例えば、企業は、従業員と共有するチケットを生成することが可能である。そのような場合、従業員は、チケットを獲得することが必要ではない可能性があるが、その理由は、企業が、出力メッセージにチケットを自動的に付加することが可能であるからである。代替として、従業員は、ビジネス通信を送信するとき、従業員自身のお金を負担せずに、企業のチケットサーバからチケットを獲得することが可能である。チケットは、信用エンティティの指示を含むことが可能である。この指示は、エンティティを一意に識別することが可能であり、受信者は、他のエンティティではなく、あるエンティティを信頼することが可能である。したがって、受信者コンピューティングデバイスは、信頼されていないエンティティからのチケットを含むメッセージをろ過することができる。代替として、受信者コンピューティングデバイスは、信用エンティティからのチケットを含んでいないメッセージをろ過することができる。ルーチンは、ブロック４０２において開始され、ルーチンは、所望のチケットに関する情報をパラメータとして受信する。図３に関して上記で示したように、この情報は、いくつかの所望されるチケットおよびチケットの値を含むことが可能である。情報は、送信者のクレジットカード番号または銀行口座など、金融情報を含むことも可能である。
【００３５】
ブロック４０４において、ルーチンは、ブロック４０２において提供された情報を確認する。例として、ルーチンは、クレジットカード会社でクレジットカード番号を確認することが可能である。情報を確認することができない場合、ルーチンは、失敗をコーラ（図示せず）に返すことが可能である。代替として、ルーチンは、例えば、ユーザが既知である場合、または、ユーザがチケットサーバでクレジットを確立した場合、ブロック４０６において続行されることが可能である。一実施形態では、チケットサーバがユーザを認識するとき、ブロック４０４における確認は、ユーザの認証を含む。ブロック４０６において、ルーチンは、要求された数のチケットを生成する。一実施形態では、ルーチンは、ブロック４０８において開始コードおよびいくつかのチケットをコーラに返す。代替として、ルーチンは、開始コードをコーラに返し、終了コードをコーラによって指示されたＩＳＰに返す。一実施形態では、ルーチンは、コードのアレイをコーラに返すことが可能である。次いで、送信者は、送信者認証コードを生成して（または、取り出して）、各出力メッセージに付加することができる。次いで、送信者メールサーバ（または、送信者の１方向機能および終了コードを有するあらゆる他のプロセスもしくは装置）は、１方向機能を付加コードに適用することによって終了コードを導出することができるかを判定することによって、付加された送信者認証コードを検証することができる。
【００３６】
図５は、送信者コンピューティングデバイスによって実施されるＳｅｎｄ＿Ｍａｉｌルーチンの実施形態を示す流れ図である。このルーチンは、送信者がメッセージを送信するとき、送信者メールクライアントによって呼び出されることが可能である。ルーチンは、ブロック５０２において開始され、ルーチンは、ある量をパラメータとして受信する。一実施形態では、ルーチンは、デフォルト量を割り当てることが可能である。ブロック５０４において、ルーチンは、次のチケットを取り出す。一実施形態では、ルーチンは、メッセージに付加される送信者認証コードを生成することが可能である。例として、ルーチンは、以前にメッセージに付加した送信者認証コード（「最終使用コード（ｌａｓｔ−ｕｓｅｄ  ｃｏｄｅ）」）の指示を取り出して、シーケンスの以前のコードを生成することが可能である。ルーチンは、開始コードから最終使用コードまでのすべてのコードを生成し、次いで第２から最終コード（すなわち、最終使用コードより前のコード）を付加することによって、以前のコードを生成することが可能である。送信者は、より一般的には、すべてのコードを１度だけ生成し、次いで、生成とは反対の順序でそれらを使用する。一実施形態では、ルーチンは、いくつかのチケットを取り出すことが可能である。例として、量の値が１ドルであり、送信者が５０セントのチケットを有する場合、ルーチンは、要求された量を満たすために、２つのチケットを取り出すことが可能である。開始コードがすでに使用されているために、ブロック５０４において、送信者認証コードを生成すること、または取り出すことができない場合、ルーチンは、メッセージを送信する前に、追加の送信者認証コードを獲得することを試行することが可能である。
【００３７】
ブロック５０６において、ルーチンは、ブロック５０４において取り出されたチケットをメッセージに付加する。例えば、チケット、値、送信者認証コード、チケットの固有識別子、および信用エンティティの指示を含む情報が、電子メールメッセージのヘッダまたは本体に追加されることが可能である。この情報は、「メタデータ」またはプレーンテキストとして付加されることが可能であり、暗号形態もしくは人間可読形態にあることが可能である。この情報は、改竄を防止するために、デジタル署名されることが可能である。ブロック５０８において、ルーチンは、メッセージを送信する。ルーチンは、ブロック５０４において付加された送信者認証コードの指示も記憶する。一実施形態では、ルーチンは、メッセージを送信者メールサーバに送信する。代替として、ルーチンは、メッセージの送信の準備ができていることを送信者メールクライアントプログラムに示す。ルーチンは、ブロック５１０においてコーラに戻る。
【００３８】
図６は、送信者メールサーバによって実施されるＦｉｌｔｅｒ＿Ｏｕｔｇｏｉｎｇ＿Ｍａｉｌルーチンの実施形態を示す流れ図である。ルーチンは、ブロック６０２において開始され、ルーチンは、メッセージの指示をパラメータとして受信する。ブロック６０４において、ルーチンは、メッセージが既知のユーザからのものであるかを判定する。例として、ルーチンは、メッセージに示された送信者の電子メールアドレスが、送信者メールサーバによって保持される電子メールアドレスのデータベースに現れることを確認することが可能である。そうである場合、ルーチンは、ブロック６０６において続行される。そうでない場合、ルーチンは、ブロック６１２において続行される。ブロック６０６において、ルーチンは、メッセージがチケットを含むかを判定する。メッセージがチケットを含む場合、ルーチンは、ブロック６０８において続行される。そうでない場合、ルーチンは、ブロック６１０において続行される。ブロック６０８において、ルーチンは、チケットが、またはより具体的には、チケットの送信者認証コードが、メッセージが偽装者によって送信されなかったことを保証するために、適切に配列されているかを判定する。例として、ルーチンは、チケットの送信者認証コードから送信者の終了コードを導出することができるかを判定する。そうである場合、ルーチンは、ブロック６１２において続行される。そうでない場合、ルーチンは、ブロック６１４において続行される。
【００３９】
ブロック６１０において、ルーチンは、メッセージがチケットを含んでいない旨の指示と共に、メッセージを送信者に返す。一実施形態では、送信者メールサーバは、各既知の送信者が、コードを有するチケットを出力メッセージに付加することを必要とする。偽装を防止するために、コードを使用することができる。ブロック６１２において、ルーチンは、メッセージを転送する。例として、ルーチンは、示された受信者メールサーバにメッセージを転送する。代替として、ルーチンは、メッセージを中間メールサーバに送ることが可能である。ブロック６１４において、ルーチンは、チケットが適切に配列されなかったことを示すエラーを送信者に報告する。この状況は、例えば、送信者がメッセージを送信者メールサーバに送信したが、メールが失われたときに生じる可能性がある。そのような場合、サーバのＲｅｑｕｅｓｔ＿Ｔｉｃｋｅｔｓルーチンは、チケットの他のブロックを生成するために、呼び出されることが可能である。
【００４０】
一実施形態では、送信者メールクライアントプログラムまたはメッセージシステムのある他の構成要素は、コードを備えるチケットを出力メッセージが有することを必要とすることがある。
【００４１】
図７は、受信者メールサーバまたはメールクライアントプログラムによって実施されるＲｅｃｅｉｖｅ＿Ｍａｉｌルーチンの実施形態を示す流れ図である。ルーチンは、ブロック７０２において開始され、ルーチンは、入りメッセージの指示をパラメータとして受信する。ブロック７０４において、ルーチンは、入りメッセージがチケットを含むかを判定する。チケットが見つけられる場合、ルーチンは、ブロック７０６において続行される。そうでない場合、ルーチンは、ブロック７１４において続行される。ブロック７０６において、ルーチンは、メッセージに含まれるチケットが有効であるかを判定するために、チケットサーバ：Ｔｉｃｋｅｔ＿Ｖａｌｉｄルーチンを呼び出す。Ｔｉｃｋｅｔ＿Ｖａｌｉｄルーチンは、図８に関して以下でさらに記述される。チケットを確認するために呼び出されるチケットサーバは、メッセージにおいて識別される信用エンティティである。Ｔｉｃｋｅｔ＿Ｖａｌｉｄルーチンが、チケットが有効であることを示す場合、ルーチンは、ブロック７０８において続行される。一実施形態では、受信者コンピューティングデバイスは、エンティティでの検査の代わりに、単にチケットのチェックサムを検査することによって、チケットを確認することが可能である。チケットが無効である場合、ルーチンは、ブロック７１４において続行される。
【００４２】
ブロック７０８において、ルーチンは、メッセージを適切なフォルダに移動させることが可能である。例として、ルーチンは、１ドルの値のチケットを含むメッセージを「ハイバリュー」と名称付けされたフォルダに移動させ、値のないチケットを含むメッセージを「フリー」と名称付けされたフォルダに移動させることが可能である。代替として、ルーチンは、メッセージが既知の送信者からである場合、チケットを含まない、もしくは無効チケットを含む入りメッセージをインボックスフォルダに移動させ、またはそうでない場合は、フリーフォルダに移動させることが可能である。インボックスルールまたは同様の機構を使用して、受信者は、チケットを含まない未知の送信者からのメッセージ、またはチケットが無効である場合のメッセージを自動的に削除することを選択することが可能である。
【００４３】
ブロック７１０において、ルーチンは、受信者がチケットの値を償還することを望むかを判定する。例として、受信者メールクライアントプログラムは、ユーザからの指示を受信するために、押しボタンなどのユーザインターフェース要素を提供することが可能である。代替として、メールクライアントプログラムは、値が償還されるある他の指示を受信することが可能である。ユーザが値を償還することを望む場合、ルーチンは、ブロック７１２において続行される。一実施形態では、受信者電子メールクライアントプログラムは、送信者が未知である場合、または送信者のアドレスが特定のドメインにあるなどを含めて、ある他の基準を満たす場合、値を自動的に償還することが可能である。そうでない場合、ルーチンは、ブロック７１４において続行される。ブロック７１２において、ルーチンは、チケットサーバの償還サブルーチンを呼び出す。このルーチンは、図９に関して以下でさらに記述される。ブロック７１４において、ルーチンは、実行をコーラに返す。ルーチンは、メッセージがチケットを含まない、チケットが有効であるか、およびユーザがチケットに関連する値を償還したかという指示を返すことも可能である。受信者メールクライアントプログラムは、これらの指示に基づいて、メッセージをさらに処理することが可能である。例として、メッセージがチケットを含まなかった場合、メールクライアントプログラムは、メッセージを削除アイテムフォルダに移動させることが可能である。
【００４４】
一実施形態では、帯域幅を節約するために、受信者電子メールクライアントは、受信者メールサーバ（図示せず）からヘッダ情報（チケットを含む）のみをダウンロードし、次いで、受信者が指示する場合、メッセージの残りをダウンロードすることが可能である。メッセージは、受信者がメッセージの残りをダウンロードしない場合、ある時間期間後に、受信者メールサーバから削除されることが可能である。一実施形態では、受信者メールサーバは、入りメッセージのチケットを確認し、ダウンロードしたヘッダにチケットの値を含む。
【００４５】
図８は、チケットサーバのＴｉｃｋｅｔ＿Ｖａｌｉｄルーチンの実施形態を示す流れ図である。ルーチンは、ブロック８０２において開始され、ルーチンは、チケットの指示を受信する。ブロック８０４において、ルーチンは、チケットが有効であるかを判定する。ルーチンは、チケットの送信者認証コードに関するチェックサムを計算することによって、これを実施することが可能である。代替として、ルーチンは、メッセージの送信者に関する終了コードをチケットの送信者認証コードから導出することができるかを判定することを試行することが可能である。チケットが有効である場合、ルーチンは、ブロック８０６において続行される。そうでない場合、ルーチンは、ブロック８１２において続行される。ブロック８０６において、ルーチンは、チケットが以前に確認されたかを判定する。ルーチンは、例えば、チケットサーバが以前に確認したチケットのリストを検査することによって、これを実施することが可能である。チケットが以前に確認されていた場合、ルーチンは、ブロック８１２において続行される。そうでない場合、ルーチンは、ブロック８０８においてチケットを確認する。一実施形態では、ルーチンは、チケットが確認されたという指示を登録することによって、チケットを確認する。次いで、ルーチンは、ブロック８１０において続行され、ルーチンは、チケットが有効である旨の指示を返す。ブロック８１２において、ルーチンは、チケットが無効である旨の指示を返す。
【００４６】
一実施形態では、チケットサーバは、受信者がチケットを確認するまで、チケットの複数確認を可能にすると考えられる。これは、例えば、有効チケットのないメッセージを破棄することを中間メールサーバが所望する場合に行われることが可能である。そのような場合、Ｔｉｃｋｅｔ＿Ｖａｌｉｄルーチンのコーラは、コールが受信者の代わりであるかの指示を含むことが可能である。
【００４７】
図９は、チケットサーバによって実施されるＲｅｄｅｅｍルーチンの実施形態を示す流れ図である。ルーチンは、ブロック９０２において開始され、ルーチンは、チケットの指示をパラメータとして受信する。ブロック９０４において、ルーチンは、チケットがすでに償還されているかを判定する。一実施形態では、ルーチンは、チケットのリストを検査することによって、この判定を実施することが可能である。チケットがすでに償還されている場合、ルーチンは、ブロック９１２において続行される。そうでない場合、ルーチンは、ブロック９０６において続行される。ブロック９０６において、ルーチンは、送信者の勘定残高を減少させる。ブロック９０８において、ルーチンは、受信者の勘定残高を増大させる。受信者が、チケットサーバのアカウントを有していない場合、チケットサーバは、受信者のアカウントを有する指示されたエンティティに値を送ることが可能である。次いで、ルーチンは、ブロック９１０において続行され、ルーチンは、成功した旨の指示をコーラに返す。ブロック９１２において、ルーチンは、失敗の指示をコーラに返す。
【００４８】
アカウントを保持するエンティティによって設定された閾値を超える正の勘定残高を有する受信者は、支払い（図示せず）を要求することが可能である。支払いは、例えば、現金または賞金の形態とすることが可能である。受信者は、勘定残高が、ある量を超える場合、支払いを要求することが可能であり、またはそのバランスに基づいて、チケットを要求することが可能である。代替として、受信者は、収集したチケット値をチャリティに寄贈する、「エア・マイル（ａｉｒ  ｍｉｌｅ）」を購入する、またはいくつかの他の周波数に基づくプログラムに参加することを選択することが可能である。
【００４９】
一実施形態では、送信者および受信者は、チケットサーブエンティティの他に、自分自身のバランスを保持する。そのような場合、受信者は、チケットに関連付けられた値を償還するとき、チケットの送信者に通知が送信されることが可能である。
【００５０】
一実施形態では、送信者は、チケットを無効にすることができることが可能である。例として、メッセージを取り消すことを所望する、または受信者によってチケットが償還されることを望まない送信者は、送信者チケットサーバにチケットを無効にするように要求することができる。そのような場合、チケットは、確認されず、受信者システムによって無効チケットとして扱われる。当然、無効にすることは、チケットがすでに確認されている場合、許可されない可能性がある。
【００５１】
一実施形態において、システムは、２ステップ償還機構を支持することが可能である。第１ステップにおいて、受信者は、送信者からのその後の電子メッセージが望ましくないことをメッセージの送信者に示す。送信者が、その後引続きメッセージを送信する場合、システムは、メッセージに示された値を受信者が償還することを可能にする。そのようなシステムでは、送信者は、メッセージを受信することを望まない受信者のトラックを保持しなければならず、または、送信者に通知した受信者にメッセージを送信するために支払わなければならない危険を冒すことになる。代替として、受信者の中央「オプトアウト」レジストリを保持することができる。それにより、メッセージの送信者は、レジストリに列挙される受信者が、送信者がメッセージにおいて示す値を償還することを通知される。
【００５２】
システムは、様々なメッセージおよび通信のプロトコルを使用する様々な形態のメッセージに関して機能する。例として、システムは、ユーザを「インスタントメッセンジャ」仲間のリストに追加するために、迷惑メッセージを低減することに役立つことが可能である。他の例として、システムは、携帯電話、メッセージ可能腕時計、携帯情報端末、および電子メッセージを受信することができるあらゆる他の装置などの装置への電子メッセージを低減することに役立つことが可能である。
【００５３】
以上から、本発明の特定の実施形態について、例示の目的で記述したが、本発明の精神および範囲から逸脱せずに、様々な修正を実施することが可能であることが理解されるであろう。したがって、本発明は、添付の請求項による場合を除いて、限定されるものではない。
【図面の簡単な説明】
【００５４】
【図１】可変条件付き価格設定および償還を使用して迷惑電子メッセージを低減するシステムの実施形態の構成要素を示すブロック図である。
【図２】図１の構成要素をさらに詳細に示すブロック図である。
【図３】システムの送信者構成要素によって実施されるＲｅｑｕｅｓｔ＿Ｔｉｃｋｅｔｓルーチンの実施形態を示す流れ図である。
【図４】システムのチケットサーバ構成要素によって実施されるＲｅｑｕｅｓｔ＿Ｔｉｃｋｅｔｓルーチンの実施形態を示す流れ図である。
【図５】システムの送信者によって実施されるＳｅｎｄ＿Ｍａｉｌルーチンの実施形態を示す流れ図である。
【図６】システムのメールサーバ構成要素によって実施されるＦｉｌｔｅｒ＿Ｏｕｔｇｏｉｎｇ＿Ｍａｉｌルーチンの実施形態を示す流れ図である。
【図７】システムの受信者構成要素によって実施されるＲｅｃｅｉｖｅ＿Ｍａｉｌルーチンの実施形態を示す流れ図である。
【図８】システムのチケットサーバ構成要素によって実施されるＴｉｃｋｅｔ＿Ｖａｌｉｄルーチンの実施形態を示す流れ図である。
【図９】システムのチケットサーバ構成要素によって実施されるＲｅｄｅｅｍルーチンの実施形態を示す流れ図である。
【符号の説明】
【００５５】
１０２  送信者コンピューティングデバイス
１０４  受信者コンピューティングデバイス
１０６  ネットワーク
１０８  送信者メールサーバ
１１０  ネットワーク
１１２  チケットサーバ
２０２  Ｒｅｑｕｅｓｔ＿Ｔｉｃｋｅｔｓ
２０４  Ｓｅｎｄ＿Ｍａｉｌ
２０６  Ｒｅｃｅｉｖｅ＿Ｍａｉｌ
２０８  Ｆｉｌｔｅｒ＿Ｏｕｔｇｏｉｎｇ＿Ｍａｉｌ
２１０  Ｒｅｑｕｅｓｔ＿Ｔｉｃｋｅｔｓ
２１２  Ｔｉｃｋｅｔ＿Ｖａｌｉｄ
２１４  Ｒｅｄｅｅｍ
【図１】
2005243031.tif 000003
【図２】
2005243031.tif 000004
【図３】
2005243031.tif 000005
【図４】
2005243031.tif 000006
【図５】
2005243031.tif 000007
【図６】
2005243031.tif 000008
【図７】
2005243031.tif 000009
【図８】
2005243031.tif 000010
【図９】
2005243031.tif 000011