JP2009527047A

JP2009527047A - 通信及び文書の管理システム及び方法

Info

Publication number: JP2009527047A
Application number: JP2008555202A
Authority: JP
Inventors: ジョン・エス・ガードナー; ジュアン・ジェイ・ワング; マシュー・ヴイ・スコット
Original assignee: イーポスタルサービシーズインコーポレイテッド
Priority date: 2006-02-13
Filing date: 2006-02-13
Publication date: 2009-07-23
Anticipated expiration: 2026-02-13
Also published as: JP5173841B2; CA2637868A1; CN101410829A; EP1989642A4; BRPI0621341A2; WO2007094772A1; MX2008010317A; EP1989642A1; CA2637868C; CN101410829B

Abstract

電子メールを、該電子メールの発信元又は受信元あるいは両方の多数のユーザー間で転送するための通信システム及び方法が提供される。本発明の通信システム及び方法は、インターネットにリンクした電子サーバー及び電子サーバーソフトウェアを使用し且つこれを増強する。発信元及び受信元は同様にインターネットにリンクした端末を有する。発信元は自分の郵便ソフトウェアを使用して特定のプレミアサービスを使用する転送を選択する。本システム及び方法には、プレミアサービスを使用するための支払い及び報告機能が含まれる。本システム及び方法は、１つ以上の場所で複数の郵便サーバーと共に動作し得る。通信は、メッセージ及び又はその転送に関するデータをプロセス処理するためだけの郵便サーバー及び郵便ソフトウェアを利用して行い得る。発信元、受信元、郵便サーバー、の間での通信が、仮想イントラネット的クォリティを創り出す。転送された電子メールは、メッセージデータを使用して発信元を識別し、ｅメールを確認及び検証し、そのプロセス処理を指示する。

Description

本発明は一般に通信システム及び方法に関連し、詳しくは、一般ユーザーがデリバリー、セキュリティ、プライバシー、管理が高度に保証される状態でインターネット上で電子メール及びメッセージをやりとりできるようにするシステム及び方法に関する。

インターネットは情報共有に革命的変化をもたらした。インターネット上での電子メールまたは“Ｅ”メールの発展は非常に確固としたものであり、今後も同様に続くことが予想されている。ｅメールの使用は多様な種類のコンピューター装置の普及、並びに、遠距離通信の帯域の利用可能性及びアクセスの増大により爆発的に増大している。２００２年には毎日３１０億通のｅメールメッセージが送信されたと推定され、その数は毎年２０％以上増大しており、２００６年には１日当たり６００億通を超えることが予想されている。

しかしながら、ｅメールの急増により思いがけない重大問題も生じている。ｅメールは他人にメッセージや文書を送信する容易且つ安価な方法であるが、こうした特徴により、受信者は予想外に大量のしかもますます増えて行く要、不要のメールを受信することになった。
必要ｅメールが激増すること自体、オーバーロードの絶えざる増加をもたらす点で問題がある。２００２年の１日当たり合計３１０億通のｅメールメッセージのうち、推定約２１０億通が必要メール、即ち、本来承諾非承諾を問わず、受信者にとって意味のあるメールである。そして、この必要ｅメールの量は２００６年には一日当たり３６０億通に達すると予想されている。

このオーバーロードな状態を更に悪化させているのは迷惑メール及び非承諾（または、時として攻撃的な）メールの量が何れも増大していることである。この迷惑メールの増大はメール受信者に迷惑なだけではなく、インターネットｅメールシステムの最適な発展を妨害しまたは制限する。迷惑メールには、仕事の効率低下、費用やセキュリティリスクの拡大等のマイナス効果があることも知られている。迷惑メールのマイナス効果については、例えば、Donaldsonの米国特許出願No.6,321,261号に記載されている。

ｅメールの全体量が増すにつれ、受信者（または、送信者）の問題は、保持しきれない大量の手紙を受ける通常の郵便受けの状況と似てくる。優先順位に意味上の差がないと、受信者は重要なｅメールを見つ出すために、手間をかけて全てのメールを閲覧しなければならない。反復的で無駄の多いこうした作業が増えてくると受信者はしばしば全てのメールを削除してしまい、その結果、受信者及び発信者にとって重要且つ意味のある情報を失ってしまう恐れが大きい。オーバーロードや迷惑メールにおけるこうした大量メッセージの問題は非常にやっかいなものとなりつつあり、ｅメール文書を管理する改善システム及び方法が緊急に望まれており、そうしたシステム及び方法を利用できないと、現在または将来のユーザーはインターネット利用に制約を受けることになる。

例えば、現在、従来のダイレクトメールに当たる合法的なｅメールマーケティングには制約がある。ダイレクトメールマーケティングは、商品やサービスの宣伝及び販促上の有効な方法として消費者及び販売者の両方に対して長年容認されて来ているが、この方法に相当する電子的方法、即ちｅメールマーケティングは、未だ実現してはいないものの、ダイレクトメールマーケティング法と同程度に認知され得且つ商業的効果を持つものに成長及び発展する潜在性を有している。
今日、オンライン広告の大部分はバナー式広告であってｅメールではない。オンライン広告として１９９９年に米国で費やされた２８億ドルのうち、バナー広告は５０％を占め、ｅメールは３％に過ぎない。オンライン広告費用は急増を続け、２００４年には１２０億ドルに達し、２００５年には２００４年を２３％上回る１４７億ドルに達すると見込まれている。しかしながら、バナー広告は周知のごとく非効率的であり、低クリック率に悩まされている。それ故、消費者の注目を引き、メッセージを伝達し、応答率を更に高めるための、ダイレクトｅメールマーケティング等の改善されたインターネットマーケティング方法に対する需要がある。

ｅメールはワールドワイドウェブより大きな基盤を有しているだけではなく、バナー広告よりも応答の良い、パーソナライズ化され、メディアリッチ（media-rich)な、インタラクティブな通信をいつでもどこでも消費者に与えることができる。しかし、ｅメールマーケティングは、ｅメールの増大及び混乱を管理するためのより良い方法が現れない限りはその可能性を最大限に発揮することはできない。現状ではｅメールハイウェイには非常に多くの「雑音」が有り、そうした雑音が受信者が正当なオンラインｅメール広告に充分に注目させる障害となっている。現在、特定のｅメールを開封し閲覧しなければそのｅメールの重要性、価値、優先順位はなかなか分からないが、開封及び閲覧は時間を要する作業であり、受信者は（ウイルス及びワーム等の）テクニカルリスク（不快な言動や写真等の）やコンテンツリスクに晒される。現在、ｅメールマーケティングでは、通信メッセージが、無意味で迷惑なｅメールと混同されたり関連付けられたりしてしまう心配がある点が制約となっている。

インターネットメールシステムには、オーバーロードや迷惑メールに加え、セキュリティーに関する問題が当然ある。ｅメール用の既存のセキュリティー処理は不十分であり、潜在する多くの商業目的に対するインターネット利用拡大の妨げとなっている。ｅメールアプリケーションの多くは暗号化プロセスを有しているが、このプロセスは多くのユーザーにとっては複雑過ぎたり、必要時に適正に及び又は一般的に利用できない。かくして、ｅメールのセキュリティーには有効解決されるべき別の問題がある。

ｅメールのセキュリティーに関する問題の良い例は、米国のFederal Health Insurance Portability and Accountability Act（ＨＩＰＡＡ）のｅメールセキュリティー要件に示されている。ＨＩＰＡＡは、暗号化による安全が保証されないｅメール（及び、ＦＡＸ）は、医者、その他の健康管理者、及び医療保険機関の間での個人健康管理情報（診断コード、試験結果、及び医学的必要性の証明書等の）通信用としては使用を認めないことを公表している。この法律が２００３年１０月に米国で施行された時、健康管理サービス会社の多くは、保護された健康管理情報の通信に使用するＨＩＰＡＡ要件を満たすｅメールシステムを持っていなかった。これらの技術は多くの健康管理供給者にとって簡単には利用できず、対費用効果も受け入れがたいものであり、そうした状況が今日まで未解決のまま続いている。
必要メールに関しては、現在のところ、上述したメールのオーバーロード及びプライオリティを区別する問題の解決策はまだ無い。

不要、または未要請の迷惑メールに関しては、いくつかの業者がメールのタイトル、発信者アドレス、メール内容に対して適用される様々なルールを使用してそうしたメールを阻止及び排除するソフトウェアフィルターを供給している。このソフトウェアはサービスプロバイダーのサーバーまたはユーザーのコンピューターシステム内に存在し得、ユーザーはこれらの迷惑メールブロッカーのフィルタリングルールを調整することができる。上述のDonaldsonの米国特許出願No.6,321,261号には、１９９９年の時点で既知の様々な迷惑メール制御のための解決法が記載される。米国特許出願No.6,321,261号自体には、遠隔のホストとローカルのメッセージ転送媒体との間の通常のファイアウォール設定に位置付けた、複数の防御レイヤーを備えた能動プローブフィルターを開示している。

そのようなソフトウェアフィルターサービスの最近の例としては、「Brightmail」の商標名で販売するフィルターをメールシステム内で使用しているインターネットサービスプロバイダー（以下、ＩＳＰ）がある。フィルターのルール及びソフトウェアはＩＳＰによって管理され、フィルターが初期状態でアクティブ化されるとフィルターの存在にすら気付かないユーザーもいる。これにより、全てではないが多少の不要メールが阻止される。
しかしながら、残念なことに、未要請の且つ要不要のメールのいくつかが尚、フィルターを通過してしまう。さらに悪いことに、（要請された又は待っている）所望のメールが阻止されても受信者にはそれが分からない。メールが阻止されたか、または、どのメールが阻止されたかを調べるにはユーザーはＩＳＰのメールアプリケーションとは別にウェブサイトにアクセスし、その特定エリアに入り、ＩＤ及びパスワードでログインし、メールの日付やメールラインをスクロールしなければならない。特定のセンダからのメールブロックを解除するには、ユーザーはそのセンダのメールアドレスを、フィルタールールを修正できる唯一の存在であるＩＳＰに送信しなければならない。

これらの迷惑メールフィルタリングサービスやソフトウェアには以下のような多くの欠点がある。
・必要メールの多数が阻止されて受信者に届かない。ある情報技術市場調査会社はこの問題が企業に２００３年に３５億ドルの損失をもたらすと推定している。
・経済的に無価値の、不要な、未要請の、または不快な多数のメールが受信者に届いてしまう。これによる企業の損失は２００３年に１００億ドルに達すると見込まれている。
・任意の一般的、社会的な基準によるコンテンツリスクに対するフィルタリングまたはスクリーニングが実施されない。
・テクニカルリスクに対する全般的なスクリーニングが実施されない。
・受信者が高プライオリティのメールを低プライオリティのものの中から素早く見つけ出し、見つけたメールを自動的に仕分けできるようにするための、一般的に認められたプライオリティまたは価値指標が提供されない。
・プライオリティ指定のメールを開くためのインセンティブを受信者に与える手段が提供されない。
・発信者または受信者のための統合的なメール追跡サービスが提供されない。
・受信または開封に対する公認通知が提供されない。
・アンチウイルススクリーニング以外の、包括的なセキュリティー手段が提供されない。メールの暗号化サービスは既知であるが、こうした暗号化サービスもやはり、上述したメールオーバーロードや迷惑メール問題に対処する完全なサービスパックの一部ではない。さらに、現在一般に入手可能なメールアプリケーションの一部となっている暗号化及び署名法を含むメール暗号化及びデジタル署名法の大部分は、一般ユーザーにとって複雑なものである。
・ユーザーのメールアプリケーション上で容易且つシームレスに動作しない場合が多い。

これらの欠点に対処しようとした組織の一例には米国の郵政公社（Ｕ.Ｓ.Ｐ.Ｓ.）があるが、Ｕ.Ｓ.Ｐ.Ｓ.の方法では、発信者が、使用中のｅメールアプリケーションとは別のＵ.Ｓ.Ｐ.Ｓ.ウェブサイトに移動して手紙を編集する必要がある。Ｕ.Ｓ.Ｐ.Ｓ.はその手紙を印刷し、封筒に入れて切手を貼り、物理的に配送する。２００３年の時点では、この方法で手紙を１ページ作成する料金は５０セントである。このサービスを魅力的と考えるユーザーもいるが、このサービスは、発信者が書類をメールするために自分のメールボックス（すなわち、自分のｅメールアプリケーション）を利用できないという欠点がある。第２に、このシステムでは多くの部分が非電子的な物理的処理であり、物理的な郵便配送につきものの制約がある。第３に、受信者は書類を受信するために自分のメールボックス（すなわち、手持ちのｅメールアプリケーション）を利用できない。
米国特許出願No.6,321,261号明細書

現在のところ、メールの優れたセキュリティーに対する要求は、オーバーロードや迷惑メール問題等と同様に部分的にしか満たされていない。安全なメールサービスのプロバイダーは安全なメールサービスのみに注意を向けている。さらに、これらの部分的なサービスでは多くの場合、例えば、発信者が自分のメールアプリケーションを使わずにプロバイダーのウェブサイトにログインする等の作業を含む面倒な処理が必要である。
従って、本発明が解決しようとする課題は、インターネットの本質的な特性を妨げずにこれらの全てのメール問題に対する完全かつ商業的に実現可能な解決策を提供することである。

本発明によれば、大小の企業や個人用の、ｅメールの商業的価値を解放する、インターネットベースの通信システムが提供される。
本発明によれば、システムを利用するｅメールの全発信者が、ｅメールの差別化、プライオリティ付け、防護及び安全化、配送プライオリティ（ｓｐｅｃｉａｌ−ｄｅｌｉｖｅｒ）及び追跡、仕分け及び取り扱いをずっと有効に行えるようになる。
本発明によれば、アクセスに制限を与えつつも尚、一般に且つ誰でも入手可能で、企業や個人を問わず、費用を要することなく、イントラネットライクな安全上の利益を得られる特別の通信チャンネルが提供される。
本発明によれば、現在、商業目的でのｅメール使用の制約となっている主要な問題が解決され、商業的ユーザーがカスタマーサービスや収益機会を広げる一方でｅメールのリスクや費用を低減させ得るようになる。

図１は本発明に従う通信システム１０を示している。通信システム１０は、電子メール（ｅメール）及び添付書類またはファイルの送信者（以下、センダ）１２または受信者（以下、レシーバ）１４の（図には２人しか示されていないが）多数のシステムユーザーを任意のトランザクション（または、取引）に接続する。通信システム１０はここでは“電子郵便サービス（以下、ｅポスタルサービス）”と称し、システム１０によって搬送され、本発明に従って扱われるメールは“電子レター（以下、ｅレター）”、“書類”または単に“メール”と呼ばれる。（用語“ｅレター”とは、本発明によって処理された又は処理されるメールに対してのみに使用される。“ｅポスタル”、“ｅポストオフィス”、“ｅレター”、は、コネチカット州スタンフォードのｅＰｏｓｔａｌＳｅｒｖｉｃｅ社の商標名である。）あるセンダ１２は指定された単独または複数のレシーバ１４に同一のメールを送信することができる。あるレシーバはｅポスタルシステムにアクセスすれば自分のｅレターのセンダにもなれる。図示されたセンダ１２がレシーバ１４となり得、その逆の場合もあり得る。システム１０には、単数又は複数のセンダ１２とインターネット１８との間の、センダＩＳＰ１９を介した、また単数又は複数のレシーバ１４とインターネット１８との間の、レシーバＩＳＰ１９を介した周知の遠隔通信リンク１６が含まれる。

センダ及びレシーバは通常、図１に示されるように、インターネットに接続されたＰＣ（パソコン又は端末）として知られる計算及びプロセス処理用装置を使用し、ＩＳＰ１９を介してメールを送受信してインターネットにアクセスするが、ユーザーは、ＰＣと同様に、サーバーや携帯式装置等の他の計算及びプロセス処理用装置を使用することもできる。これらのユーザーインターフェース装置はここでは概略的に“端末”と称する。端末は本質的にＩ／Ｏ装置だけのものから、インストール及び又はダウンロードしたソフトウェアを使用して実質的な情報処理を提供する装置までをも含む様々なレベルの情報処理能力を有するものであり得る。特に端末は、以下に説明する本発明の特徴的な動作機能を提供するためにサーバー及び又は接続した他のコンピューターやソフトウェアと共にネットワーク上の構成要素として動作し得るものであり、“センダ”及び“レシーバ”とは、端末及びその端末上で（または、端末を介して）動作可能なソフトウェアをも意味するものとする。

更に、図１の説明ではセンダ／レシーバとインターネットとの間の媒体をＩＳＰ１９として図示するが、図９に示すように、メール及びインターネットアクセスサーバー接続の実際の種類は企業のイントラネットのメール及びインターネットアクセスサーバー、またはエキストラネット、ＬＡＮまたは同様な接続等の、センダ／レシーバにサービスを提供し得る、既存のどのような代替物（又は代替的構成、別法、別態様、別構成（以降“オルタナティブ”と総称する））であってもかまわない。また、このシステムには代表的には通常のファイアウォール及びフィルターが含まれる。図９及び図１０にも示すように、物理的な遠隔通信接続の特定タイプのものでは電話、携帯電話、ＤＳＬ、ケーブル、衛星または他の形式の無線通信、及び、物理的配送（図１０参照）等の多数のオルタナティブを使用できる。
本発明は既知の基本的なＳＭＴＰインターネットｅメールシステム及びウェブメッセージングＨＴＴＰシステムを、使用し、補完し、拡張するものであり、“インターネット”とは、両システムを含むものとする。本発明はｅポストオフィス（以下、ｅＰＯ）２０（図１）を特徴とする。ｅＰＯ２０は、好ましい構成ではサーバー又は一組のサーバー（以下、サーバーセット）であり、図３Ａ〜Ｃ、図４Ｂ、図６及び図７に示すように、模範的ソフトウェア２４，２４'を実行し、遠隔通信リンク１６を介してインターネットに接続される。ｅＰＯ２０は郵便ソフトウェア２４，２４'を実行する単一サーバーとして説明されるが、複数のサーバーまたは同等のハードウェア及びソフトウェアであってもよい。“ｅポストオフィス（ｅＰＯ）”、“ポスタルサーバー”、“電子ポスタルサーバー”、“ポスタルサーバー及びソフトウェア”は、これらの変形及び他の既知の同等物を含むものとする。

実用上、ｅＰＯ２０の全サーバー又はサーバーセットは物理的な１つのサイトに位置付け得るが、割り当てられたセンダ１２及びレシーバ１４のために（そうした割り当てが変わった場合でも）ｅＰＯ２０の機能を実行可能な、模範的ソフトウェア２４、２４’を実行するそれらサーバー又はサーバーセットの各々を多数サイトに位置付けても良い。現在の所、地理的に離れ、模範的ソフトウェア２４、２４’を実行し且つインターネットや遠距離通信リンクによって相互に結ばれたサーバーセットは、作業効率、入手性、リダンダンシー、スカラビリティー、ユーザーサービス改善、セキュリティーアドバンテージ、に関して連係動作することが好ましい。そのようにネットワーク化した別々のｅＰＯ２０サーバーセットのグループ又はネットワーク全体が、図１に示すｅＰＯ２０を構成する。

ｅＰＯ２０は、図２Ａ、２Ｂ、図４Ａに示す模範的ソフトウェア２２、２６（センダ１２及びレシーバ１４の夫々のパソコン又はサーバーにインストールされたものであることが好ましい）を実行する、センダ１２及びレシーバ１４の夫々のパソコン又はサーバーその他及びそれらの間で通信及び連係する。センダ１２及びレシーバ１４の各端末のｅポスタルソフトウェア２２、２６との相互作用下にｅＰＯ２０を使用する場合は、基本的なインターネットｅメールＳＭＴＰシステム及び標準的なウェブメッセージングＨＴＴＰシステムの何れをも使用する。センダ及びレシーバのパソコン又はサーバーにインストールされ及び又はそれらパソコン又はサーバー上で動作するｅポスタルコンポーネントソフトウェア２２、２６は、そうしたパソコン又はサーバーの基本ソフトやアプリケーション（ｅメール及びブラウザ）ソフトウェアとの互換性を有する。

図１に示す通信システムを使用するための、図１の、ｅＰＯ２０とセンダ１２、ｅＰＯ２０とレシーバ１４、ｅＰＯ２０とセンダ１２及びレシーバ１４間の各連係及び通信方法には他に色々なものがあり、それらには、センダ１２が先にプロセス処理してから発送する、及び又はｅＰＯ２０が処理する、及び又はレシーバに配送され、最後にプロセス処理する、といった、ｅレター用の各オルタナティブが含まれる。これらのオルタナティブでは、ｅレターメッセージ（メッセージのプロセス処理用の情報に対するものとしての内容）それ自体がｅＰＯ２０を通過したか否かがその変数の１つとなる。他の変数は、ｅＰＯ２０がセンダ１２からレシーバ１４に送るｅレターをプロセス処理するために必要な、ｅレターメッセージ及び付随するｅレターポスタルデータを送信及び配送するための転送プロトコル（及びその使用法）オルタナティブである。“ｅレターポスタルデータ”は、“ｅポスタルデータ”、“ｅポスタルプロセス処理データ”、“ｅレターメッセージデータ”、“ｅレターデータ”、“メッセージデータ”、“メッセージデータコンポーネント”その他の如く称される。

図１１には、センダ１２からｅＰＯ２０にｅレターを送るための、以下に説明する利益及び不利益をある程度伴う、４つの基本的オルタナティブａ）〜ｄ）を示す。センダ１２、センダＩＳＰ１９、ｅＰＯ２０、の間の各リンクは、図１から遠距離通信リンク１６を省いて略示される。ｅレターに関する情報は全体にセンダ１２からｅＰＯ２０に流れるように示されるが、図１１ではｅレターの情報を転送するインターネット接続を容易化したり、セキュリティーやメッセージのデータを交換するための双方向データ転送が存在し得る。

オルタナティブａ）では発信者１２が、ｅレターメッセージをｅレターとして発送し、プロセス処理し、配送するために必要なｅレターメッセージ及び全ｅポスタルデータを、ＳＭＴＰのような標準的なインターネットメールプロトコルを使用して、発信者ＩＳＰ１９メールサーバーを介してｅＰＯ２０メールサーバーに送信する必要がある。今後は、メールプロトコルとして可能なプロトコル群を単にＳＭＴＰと称する。このオルタナティブには、全ての情報が１パッケージ化され、従って転送量が最小であるために、関連する不安定性がずっと低下し、またインターネットメール送信のための最も一般的なプロセスでもあることから、ｅＰＯ２０までの転送路に沿って何らかの問題が発生する恐れが小さい、等の利益がある。

オルタナティブｂ）では、ｅレターメッセージ及び大抵のｅポスタルプロセス処理データ”がオルタナティブａ）におけるようにして送信されるが、限定量のｅポスタルプロセス処理データ、例えば、センダ１２やｅレターのＩＤ及びセキュリティーナンバーは、センダ１２がＨＴＴＰのような特定の標準的ＴＣＰアプリケーションをセンダＩＳＰ１９を介して使用することから、センダ１２によって交換され得る。オルタナティブｂ）には、ｅレターメッセージが暗号化情報を含む場合に得られるセキュリティー上の利益、つまり、暗号化情報を含むｅレターメッセージが、そうした暗号化情報のためのｅレターＩＤナンバーや暗号化キーを含むｅポスタルプロセス処理データを含むセカンドコミュニケーションとは別個に送信されるという利益がある。他方、オルタナティブｂ）には、最小量以上の通信量が必要とされ、ユーザーがオンライン状態でなければセンダ１２はｅレターをプロセス処理できないという不利益がある。

オルタナティブｃ）では、ｅレターメッセージ及び、ＩＤやセキュリティーナンバーのような限られたｅポスタルプロセス処理データのみが、センダ１２によりＳＭＴＰプロトコル及びセンダＩＳＰ１９メールサーバーを介してｅＰＯ２０に送信される。ｅレターをプロセス処理するためのその他全てのｅポスタルプロセス処理データは、ＨＴＴＰ又は幾つかのその他のそうしたプロトコルを介してｅＰＯ２０にダイレクトに送信される。オルタナティブｃ）は、ＨＴＴＰを介してｅＰＯ２０にダイレクト送信されるｅポスタルプロセス処理データがずっと多い点を除いてオルタナティブｂ）と類似しているが、これは、オルタナティブｂ）の場合には、プログラミング及びプロセス処理上の機能に依存して別個に送信され得るデータ量に関し、その全てにおいてほぼ同じ結果を得られるオルタナティブが多数存在することを示唆している。
オルタナティブｄ）では、ｅレターメッセージ及び全ｅポスタルプロセス処理データを含む全情報がＨＴＴＰ形式のプロトコルを使用してｅＰＯ２０にダイレクトに送信される。オルタナティブｄ）の場合はｅレターが別個の２つのパッケージ状態で送信される利益はない。オルタナティブｄ）には、センダ１２が、自分の端末に依存してｅレターをプロセス処理する際にオンライン状態でなければならない点と、そうした様式下にｅメールを送信する場合に経験され得るインターネットメールの不確実性の問題があるという不利益がある。

ｅＰＯ２０を通してｅレターを送る場合、これらの方法の任意又は組み合わせ使用、最良方法の１つの能動的選択、はセンダの状況に依存する。仮にユーザーがオンライン状態である又はオンライン状態になれる場合はオルタナティブｂ）が好ましい。オルタナティブｂ）ではセンダ１２は、ＨＴＴＰ又はその他のそうしたプロトコルを介してｅＰＯ２０と通信し、ｅＰＯ２０にｅレターのＩＤナンバーを含むｅポスタルプロセス処理データを提供し、ｅＰＯ２０から一回使用暗号化キーを入手し又は又はｅＰＯ２０に一回使用暗号化キーを与える。次いでこの暗号化キーがＳＭＴＰ及びＩＳＰメールサーバーを介してｅＰＯ２０に送信するｅレター及びその他のｅポスタルプロセス処理データを暗号化するために使用される。然し乍ら、ユーザーが非オンライン状態又はオンライン状態にならない場合はオルタナティブａ）を使用したほうが良い。なぜなら、センダ１２がｅレターをプロセス処理する前にｅＰＯ２０と通信する必要がないからである。ｅレター及び又はｅポスタルプロセス処理データは、センダ１２位置でこの目的のために記憶及び保存された暗号化キーを用いて暗号化する。然し乍ら、オルタナティブｄ）はセンダ１２が常にオンライン状態である場合及び又は、センダ１２位置での条件又は要件がｅＰＯ２０又はレシーバ１４によって認可されるものである場合に使用され得る。

ｅＰＯ２０位置でｅレターがプロセス処理された後、このｅＰＯ２０を介してｅレターを送信する場合はｅレターはｅＰＯ２０からレシーバ１４に送られる。図１２にはｅＰＯ２０からレシーバ１４にｅレターを送信するための３つの基本的オルタナティブｅ）〜ｇ）が示されるが、各構成には幾つかの利益及び不利益がある。図１２ではｅＰＯ２０、レシーバＩＳＰ１９、レシーバ１４の各間部分のリンクが、図１から電気通信リンクを省いた状態で略示されている。ｅレター及び当該ｅレターに関する情報の全体流れはｅＰＯ２０からレシーバ１４に向かうように示されるが、図１２ではｅレターの情報を転送するインターネット接続を容易化したり、セキュリティーやメッセージデータ交換のための双方向データ転送が存在し得る。
オルタナティブｅ）では、ｅレターメッセージをｅレターとしてレシーバ１４に発送し、プロセス処理し、配送するために必要なｅレターメッセージ及び全ｅポスタルデータを、ＳＭＴＰ及びＰＯＰ、ＩＭＡＰその他のそうしたメールプロトコルを使用してレシーバＩＳＰ１９メールサーバーに、次いでレシーバに送信する必要がある。このオルタナティブｅ）には以下の利益がある。
・全ての情報が１パッケージ化される。
・転送量が最小であるために、転送関連の不安定性がずっと低下する。
・レシーバＩＳＰ１９からｅレターを受け取る以外の通信が不要である。

従って、レシーバ１４はオンライン状態にならずともｅレターのプロセス処理を完了でき、また、このプロセスはインターネットメールを送信する場合の最も普通のプロセスであることから、ｅＰＯ２０からレシーバ１４への転送路に沿って何らかの問題が生じる恐れが小さい。
加えて、オルタナティブｅ）のみならずｆ）及びｇ）では、レシーバ１４がそうしたｅレターメッセージを受け取るための最も適当で、簡単且つ恐らくは唯一でさえある手段がレシーバＩＳＰ１９メールサーバーであると認識している。
オルタナティブｆ）では、ｅレターメッセージ及び幾つかのｅポスタルプロセス処理データ、例えばｅレターのＩＤやセキュリティーナンバーはレシーバＩＳＰ１９メールサーバーを介してレシーバ１４に送信される。ｅレターと共に送るｅポスタルデータ量はレシーバ１４及びレシーバＩＳＰ１９システムの組み合わせ機能次第で変化し得る。ｅレターがレシーバ１４に届くと、レシーバ１４はＨＴＴＰ又は幾つかのその他のそうしたプロトコルを介してｅＰＯ２０とダイレクト通信し、ｅＰＯ２０はレシーバ１４に対し、レシーバ１４がｅレターのプロセス処理完了上必要な残りの全ｅポスタルプロセス処理データを提供する。オルタナティブｆ）の利益には、ｅレターメッセージが暗号化情報を含む場合に得られるセキュリティー上の利益、つまり、暗号化情報を含むレターメッセージが、ｅレターのＩＤナンバーや暗号化キーを含むｅポスタルプロセス処理データを含むセカンドコミュニケーションとは別に、ＨＴＴＰを介して送信される利益が含まれる。然し乍ら、オルタナティブｆ）には、ｅＰＯ２０との通信要件がオルタナティブｅ）におけるそれよりもずっと複雑化されることや、ｅレターのプロセス処理を完了させるためにレシーバ１４がオンライン状態になる必要があるという不利益がある。レシーバ１４がオンライン状態ではない又はオンライン状態になれない場合は、ｅレターのプロセス処理を完了できず、オンライン状態になれるまで待たされることになる。

オルタナティブｇ）では、ｅＰＯ２０がセンダのｅレターメッセージを何も含まないｅＰＯｅレターをレシーバ１４に送信する。ｅＰＯ２０の送信するｅＰＯｅレターはセンダ１２についての限られたＩＤ及びセキュリティーナンバーのみを有し、レシーバ１４にはｅＰＯ２０位置でレシーバ１４のためのｅレターが保持されていることを知らせる。この場合、レシーバ１４はＨＴＴＰ又は幾つかのその他のそうしたプロトコルを使用してｅＰＯ２０と通信し、ｅＰＯ２０はレシーバ１４にセンダ１２のｅレターと、レシーバ１４側でセンダ１２ｅレターのプロセス処理を完了するために必要な全ｅポスタルプロセス処理データを提供する。このオルタナティブｇ）にはオルタナティブｆ）におけると同じ不利益がある。つまり、レシーバ１４は最終プロセス処理のために必要なｅレター及びｅポスタルプロセス処理データをｅＰＯ２０から入手するにはオンライン状態でなければならない、又はオンライン状態になる必要がある。然し乍ら、オルタナティブｇ）にはオルタナティブｆ）におけるそれを上回るセキュリティ上の利益がある。つまり、レシーバ１４がｅレターを最終的にプロセス処理するために必要なｅポスタルプロセス処理データを入手するまではｅＰＯ２０からはレシーバ１４にｅレターメッセージが送られないのである。

大抵の場合、これらの３つのオルタナティブのｅポスタルシステム１０の内、最も好ましいのはオルタナティブｅ）である。オルタナティブｅ）は最もシンプルで且つ通信量が最小でであり、多くの情報に非オンライン状態で接し得る柔軟性があり、しかも良好なセキュリティが提供される。然し乍ら、レシーバ１４とレシーバＩＳＰ１９システム機能が組み合わされる場合はオルタナティブｆ）又はｇ）の何れかの方が好ましい。レシーバ１４が常に又は通常的にオンライン状態にある場合、又は最も恐らくは、ｅポスタルデータをｅＰＯ２０と通信させるため必要上オンライン状態となる場合がそうした状況に相当する。先に説明したように、ｅレターメッセージとｅポスタルプロセス処理データとを分離通信させることでセキュリティー上の利益性が高まる。その他の例として、オルタナティブｇ）は、レシーバソフトウェア２６を持たないレシーバにｅレターを送信する場合に使用される。

図１３には、センダ１２からレシーバ１４にｅレターメッセージを送信するための基本的な２つのオルタナティブｈ）及びｉ）が示されるが、これらのオルタナティブはｅＰＯ２０を介さない。何れのオルタナティブにも利益と不利益がある。センダ１２と、センダＩＳＰ１９と、レシーバＩＳＰ１９と、レシーバ１４との各間部分のリンクは図１から電気通信リンクを省略して略示される。ｅレター及び当該ｅレターに関する情報の全体流れはセンダ１２からレシーバ１４に（幾つかの上方はｅＰＯ２０にまたｅＰＯ２０から）向かうように示されるが、図１３ではｅレターの情報を転送するインターネット接続を容易化したり、セキュリティーやメッセージデータ交換するための、センダ１２、レシーバ１４、ｅＰＯ２０間での双方向及び又は全方向のデータ転送が存在し得る。

オルタナティブｈ）では、ｅレターメッセージをｅレターとして発送し、プロセス処理し、配送するために必要なｅレターメッセージ及び大抵のｅポスタルデータを、ＳＭＴＰ及びＰＯＰ/ＩＭＡＰその他のそうしたインターネットメールプロトコルを使用して、ｅＰＯ２０を介さずにレシーバＩＳＰ１９及びレシーバ１４に送信する必要がある。然し乍ら、ｅレターをプロセス処理するために不可欠な、センダ１２のＩＤやセキュリティナンバーのような限られた量のｅポスタルプロセス処理データもまた、ＨＴＴＰのような幾つかの標準的なＴＣＰアプリケーションプロトコルをセンダＩＳＰ１９を介して用いることで、センダ１２によってｅＰＯ２０とダイレクト交換される。レシーバ１４は、ｅレターメッセージ及びｅポスタルプロセス処理データを受け取ると、ＨＴＴＰのような幾つかの標準的なＴＣＰアプリケーションプロトコルをレシーバＩＳＰ１９を介して用いることによってｅＰＯ２０とダイレクト通信し、ｅＰＯ２０から、ｅレターメッセージには含まれない残りの限定量のｅポスタルプロセス処理データを受け取る。次いで、レシーバ１４はｅレターメッセージのプロセス処理を完了する。オルタナティブｈ）には、オルタナティブｉ）に関して以下に説明するような利益及び不利益がある。

オルタナティブｉ）では、ｅレターメッセージと、ｅレターのＩＤやセキュリティナンバーのような限られた量のｅポスタルプロセス処理データのみが、ＳＭＴＰ及びＰＯＰ/ＩＭＡＰの様な標準的なインターネットメールプロトコルを使用するセンダ１２によって、ｅＰＯ２０を介することなく、レシーバＩＳＰ１９及びレシーバ１４に一緒に送信される。然し乍ら、ｅレターメッセージをｅレターとして送信し、プロセス処理し、配送するために必要な大抵のｅポスタルプロセス処理データは、ＨＴＴＰのような幾つかの標準的なＴＣＰアプリケーションプロトコルをセンダＩＳＰ１９を介して用いてセンダ１２がｅＰＯ２０とダイレクトに交換する。レシーバ１４は、ｅレターメッセージ及び限られたｅポスタルプロセス処理データを受け取ると、ＨＴＴＰのような幾つかの標準的なＴＣＰアプリケーションプロトコルをセンダＩＳＰ１９を介して用いてｅＰＯ２０とダイレクト通信し、ｅＰＯ２０からｅレターのプロセス処理を完了するために必要なｅポスタルプロセス処理データを受け取る。次いで、レシーバ１４はｅレターメッセージのプロセス処理を完了する。オルタナティブｉ）には、オルタナティブｈ）にも当てはまる、以下に説明するような利益及び不利益がある。

オルタナティブｈ）及びオルタナティブｉ）は類似しており、センダ１２が、ＳＭＴＰやＰＯＰ/ＩＭＡＰの様な標準的なインターネットメールプロトコルを使用してレシーバＩＳＰ１９やレシーバ１４にｅレターメッセージと一緒に送るｅポスタルプロセス処理データ量のみが異なる。

これらのオルタナティブｈ）及びオルタナティブｉ）は、センダ１２及びレシーバ１４が、ｅレターメッセージをどうしてもｅＰＯ２０に通したくない場合は有益なものとなる。オルタナティブｉ）は大抵のｅポスタルプロセス処理データがｅレターと同じ通信内で転送されない点で、オルタナティブｈ）に勝るセキュリティー上の利益がある。
然し乍ら、オルタナティブｈ）及びオルタナティブｉ）には数多くの不利益がある。先ず第１には、必要通信数がこれらの方法をより複雑化し、通信上の問題が生じる恐れが大きくなる点。第２には、より重大なことには、ｅレターメッセージがｅＰＯ２０を介さないために、以下の点、即ち、
・ｅＰＯ２０が、テクニカル及びコンテンツ的なリスクに関してセンダ１２及びレシーバ１４に代わってｅレターをスクリーニングすることができない。
・ｅＰＯ２０がセンダ１２を確認できず、センダ個人の認証を検証できず、レシーバ１４位置では、ｅＰＯ２０位置でできるようにはｅレターメッセージの整合性を確実に評価できない。これにより、一般的な状況でのセンダ１２の確認、センダ個人の認証、ｅレターの整合性の評価は信頼性に欠けるものとなり、安全性も低下する。
・ｅＰＯ２０にはセンダ１２への返送機能もない。従って、センダ１２を追加的に評価し、ｅポスタルシステムの全体的な安全性を監視する機会が無い。
・ｅＰＯ２０が、センダ１２及びレシーバ１４に対し、ｅＰＯ２０位置でのｅレターメッセージプロセス処理時間のタイムスタンプ又は追跡記録を提供できない。
・ｅＰＯ２０が、センダ１２にｅレターのｅポスタル料金についての最も信頼できる確認を提供できない。
・ｅＰＯ２０が、センダ１２がｅＰＯのｅレターリポジトリに入れるように選択したｅレターに、同程度の否認防止性を提供できない。そうした公認リポジトリの標準規格では、センダ１２又はレシーバ１４がオリジナルのｅレターのコピーを与えるのではなくむしろ、ｅＰＯ２０を通過するオリジナルのｅレターのコピーが要求される。
・センダ１２から多数のレシーバ１４に暗号化ｅレターをｅＰＯ２０を通さずにダイレクト送信するのがずっと複雑化され、ｅＰＯ２０によるレシーバ１４への暗号化ｅレターのプロセス処理及び配送に関して以下に詳しく説明するように、安全性が低下する。

以上から、図１１及び図１２に示すようにｅＰＯ２０を介したｅレター送信は、図１３に示すようにｅＰＯ２０をバイパスしてレシーバ１４にｅレターメッセージを送信するよりもずっと有益性が高いことは明らかである。ｅＰＯ２０を通すｅレターメッセージ送信は一般に好ましいものであり且つ本発明に最適なものである。然し乍ら、特定のセンダ１２及びレシーバ１４の組み合わせ状況ではｅレターをダイレクトにレシーバ１４に送信することが好ましい。例えば、レシーバ１４は、レシーバＩＳＰ１９が本来ネットワークメール及びインターネットアクセスサーバーを構成し、図８に示すようなｅポスタルネットワークソフトウェアが、ネットワークメール、インターネットアクセスサーバーその他の企業サーバーと共に運用される企業ネットワーク内クライアントワークステーションであり得る。

そうしたソフトウェア２２、２６は例えば、少なくとも部分的にはダウンロードによりインストールされ、その際、ユーザーはｅポスタルサービスへのユーザーアカウントを開設する。
インストール及びｅＰＯ２０へのアカウント開設に関し、センダ１２及びレシーバ１４がソフトウェア２２、２６を利用できるようになるまでの、センダ１２及びレシーバ１４によるダウンロード、インストール、アクティベーションのプロセス（センダ及びレシーバとソフトウェアとを組み合わせて、今後、“クライアントソフトウェア”または“クライアント”とも称することもある）にはオルタナティブがある。ダウンロード、インストール、アクティベーション、のプロセス及びその主要なオルタナティブを図１４Ａ及び図１４Ｂに示す。当該プロセスにおける特定の各ステップは、オペレーティングシステム（以下、ＯＳ）やｅメールアプリケーションを含むクライアント端末でのテクニカル環境次第のものである。

図１４Ａに示す如き代表的プロセスが、ダウンロード及びインストールフェーズＤ１を含むステップセットから開始される。ユーザーはソフトウェアのダウンロードを決定し、ユーザーの端末上でｅＰＯにオペレーティングシステム、ｅメールアプリケーション、ウェブブラウザのような重要なソフトウェアコンポーネンツを記入するプロセスを開始する。ダウンロードはｅＰＯ２０ウェブサイト、ｅポスタルソフトウェアＣＤ又は、ユーザーの端末のＯＳやｅメールアプリケーションと互換性のある必要なソフトウェアを含むその他のｅポスタルメディアの何れかによっても実行され得る。ユーザー端末は、この端末で実行されるクライアントソフトウェア２２、２６のセットアップファイルをダウンロード及び保存する。

この時点で、ユーザーには、ダウンロードを続ける前に承諾するべきユーザーライセンスとサービス契約（ＥＵＬＳＡ）とが提示されする。ＥＵＬＳＡはこのプロセス後に提示され得るが、ユーザーがＥＵＬＳＡを承諾しなかった場合、ダウンロードプロセスを中止し、ユーザー端末にそれ以上ソフトウェアがダウンロードされないようにするためにはこの時点で提示するのが最良である。ＥＵＬＳＡが承諾されると、クライアントセットアップファイルがダウンロードされ、残りのソフトウェアがインストールされる。
次いで、クライアントソフトウェア２２、２６はＨＴＴＰ又は幾つかのその他のそうしたＴＣＰアプリケーションプロトコルを使用してｅＰＯ２０とダイレクト通信し、ｅＰＯ２０のオンラインステータスをチェックする。これにより、クライアントソフトウェア２２、２６のセットアップのダウンロード及びインストールフェーズＤ１が終了する。

登録フェーズＤ２が開始される。クライアントソフトウェア２２、２６は、ｅＰＯ２０が通信可能な状態にあることを確認するとユーザーにｅＰＯ２０位置でのアカウント開設を要求し、ユーザーにアカウント開設画面を提示し、ユーザーは要求される情報を画面上で入力する。次いでクライアントはこのユーザーデータをＨＴＴＰ又は幾つかのその他のそうしたＴＣＰアプリケーションプロトコルを使用してｅＰＯ２０に転送する。ｅＰＯ２０はこのユーザーデータを保存し且つプロセス処理し、この新規なユーザーアカウントを登録し、登録したアカウント情報を、クライアントがｅＰＯ２０と通信するために使用したと同じＨＴＴＰの如きプロトコル用いてクライアントに返す。これにより、クライアントソフトウェア２２、２６のセットアップの登録フェーズＤ２が完了する。

検証フェーズＤ３が開始される。クライアントソフトウェア２２、２６はユーザーにクレジットカード（以下、ＣＣ）画面を提示し、ユーザーは要求されるＣＣ情報を当該画面上で入力する。次いでクライアントはこのユーザーデータをＨＴＴＰ又は幾つかのその他のそうしたＴＣＰアプリケーションプロトコルを使用してｅＰＯ２０に伝える。ｅＰＯ２０はＣＣデータを受け取ると、このＣＣデータが、ｅポスタル通信システム使用料をユーザーに請求できものであるか否かを確認する。次いで、ｅＰＯ２０はアカウント確認のための通信でクライアントが使用したと同じＨＴＴＰのようなプロトコルを使用して、アカウントの確認が取れたことを、センダ１２及びレシーバ１４の仮ＩＤ及びセキュリティーデータと共に伝える。このフェーズには、ユーザーのＣＣデータを確認する以前にクライアントにセンダ１２及びレシーバ１４の仮ＩＤ及びセキュリティーデータを提供するオルタナティブがあるが、このオルタナティブでは、ＣＣデータのステータスが暫定的ではあっても、このＣＣデータが、ユーザーがｅＰＯ２０アカウントを持つにふさわしい人物であることを保証する追加的手段として、クライアントがＩＤ及びセキュリティデータを受ける前に使用されることから、ｅポスタルシステム１０の構成として好ましいものである。これにより、クライアントソフトウェア２２、２６のセットアップにおける確認フェーズＤ３が終了する。

次ぎに、アクティベーションフェーズＤ４が開始される。このステージではｅＰＯ２０はクライアントソフトウェア２２、２６がアクティブであるとはみなされない。クライアントはユーザー端末に完全にインストールされるが、尚、ｅレターを送受信するためのユーザーのｅメールアプリケーションと共に使用するべく起動されてはいないスタンバイモード状態にある。この時点で、ｅＰＯ２０は、クライアントソフトウェア２２、２６がインストールされ、登録及び認証されたユーザー端末のプライマリーｅメールアドレスに、アクティベーションｅレターＤ５をｅメールで送付する。クライアントは送られて来るｅメールを監視してアクティベーションｅレターを探し、アクティベーションｅレターが届くとこれを識別し、内部のデータを解析し、新規のＩＤ及びセキュリティデータを保存する。次いで、クライアントは、ＨＴＴＰ又は幾つかのその他のそうしたＴＣＰアプリケーションプロトコルを使用して、アクティベーションｅレター及び新規のデータを受けたことをｅＰＯ２０に伝える。ｅＰＯ２０は、クライアントがｅＰＯ２０との通信に使用したと同じそうしたＨＴＴＰのようなプロトコルを使用してクライアントに応答し、ｅＰＯ２０が新規アカウントがアクティブであることを記録したことを伝える。これにより、クライアントソフトウェア２２、２６のセットアップのアクティベーションフェーズＤ４が完了する。ユーザーはこの時点で、クライアントを使用して全てのｅポスタルシステム機能及び利益にアクセスすることができる。

クライアントソフトウェアのこのアクティベーションフェーズには、アクティベーションｅレターではなく、クライアントとｅＰＯ２０との間でＨＴＴＰ又は幾つかのその他のそうしたＴＣＰアプリケーションプロトコルを使用したダイレクト通信Ｄ６を使用するオルタナティブがある。このオルタナティブの構成は、ｅＰＯ２０がクライアントにアカウントが認証されたこと及びセンダ１２及びレシーバ１４の仮ＩＤ及びセキュリティーデータを提供するステップ以降のステップに又は当該ステップに代えて使用することができる。ｅＰＯ２０は、クライアントがｅＰＯ２０との通信に使用したＨＴＴＰのような同じプロトコルを使用して、アカウントをアクティベートさせるための仮のＩＤ及びセキュリティーデータをクライアントに送る。
アクティベーションｅレターＤ５の使用はｅポスタルシステム１０の構成として好ましいものである。なぜなら、このアクティベーションｅレターＤ５によりソフトウェアのインストール及びセットアップの登録フェースＤ２の間にユーザーが提供するプライマリーｅメールアドレスの有効性が確認され、ユーザーの、従ってアカウントの正当性が更に確認されるからである。

上記説明の主たる２つのセクション、即ち、１）ｅＰＯ２０を介した又は介さないｅレター送受信における異なる構成に関する説明と、２）クライアントソフトウェア２２、２６のインストール、登録、認証及びアクティベーションに関する説明との中で、ダイレクト通信の使用について何度も言及したが、この場合のデータのダイレクト通信又はダイレクト転送とはセンダ１２及びレシーバ１４のクライアントソフトウェア２２、２６と、ｅＰＯ２０との間におけるものである。そうしたダイレクト通信の構造化及び実行方法には２つの主要な構成が存在し、そうした構成が図１５に示される。

第１の構成、“Ｎ”（ノーマル）は、セカンドパーティーのインターネットウェブサーバーと安全に通信するクライアントコンピューターの通常プロセス及びコンポーネンツのアウトラインを示す。クライアントコンピューターのウェブブラウザは、ユーザー定義ＵＲＬとのＴＣＰ／ＩＰ接続を確立し、ウェブサーバーと通信するためのＴＣＰアプリケーションプロトコルとしてＨＴＴＰ（及びＨＴＭＬ）を使用する。この通信は、特に、ウェブサーバーに通信相手が誰であるかを見分けさせるためにクッキーを補助的に使用する状況下に、サーバー側のポート２５を介して実施される。ＨＴＴＰＳを使用する転送における安全上、サーバーが暗号を管理し、暗号化キー及びデジタル認証のための外部サードパーティーが使用される。

このノーマルプロセスは図１のｅポスタルシステム１０で使用できるが好ましくはない。ｅポスタルシステム１０プロセスはそうではなくむしろ、図１５にオルタナティブである“Ｃ”（カスタム）プロセスとしてカスタムメードし、暗号化キー及びデジタル認証のためのサードパーティーから独立した、管理された、独自の暗号用プロセスを持たせることで安全性は向上する。ｅポスタルシステム１０は、削除可能なクッキー使用に依存しなくともクライアントを識別でき、入手できないかも知れない唯一のＴＣＰに依存しなくとも通信ができ、特定のウェブブラウザを使わなくて良いのであれば、その柔軟性は一段と向上する。ｅポスタルシステム１０はその設計上、そうした通信を構造化及び実行するために好ましい構成を提供し得る。

図１５に“Ｃ”として示す本発明で使用する通信の好ましいカスタム構成には以下の利益、即ち、本発明の設計、特には、クライアントソフトウェア２２、２６を使用するセンダ１２及びレシーバ１４が、ソフトウェア２４、２４’を使用してｅＰＯ２０とダイレクト通信する及びｅＰＯ２０に又はｅＰＯ２０からデータ転送できるという事実に基づく利益がある。実際上、ｅポスタルシステム１０はそれ自分の内部で通信し得る、つまり、センダ１２及びレシーバ１４の端末上で動作するｅポスタルクライアント側のソフトウェア２２、２６と、ｅポスタルサーバー上で動作するｅＰＯ２０側のソフトウェア２４、２４’との間に通信ネットワークを構成し得る。ｅポスタルシステム１０は、ｅＰＯ２０とクライアント（自分のウェブブラウザとして作用する）との間でダイレクト通信する間、ＨＴＴＰＳセッションをシミュレートし、システム自分の一回使用セッションＩＤを使用し、システム自分の一回セッション暗号化キー／暗号復号キーを確立し、かくして、図１７を参照して以下に詳しく説明する独自メッセージデータ構造を利用できる多数のＴＣＰアプリケーションプロトコルを利用できるようになる。事実このｅポスタルシステム１０は、インターネットを使用することや公開性（ｐｕｂｌｉｃａｖａｉｌａｂｉｌｉｔｙ）を有するにも関わらず、ユーザーに仮想イントラネットライクなクォリティー又は特性を提供する。

このようなダイレクト通信（以下、ダイレクト通信の他に、“ｅＰＯ通信”、又は単に“通信“とも称する）は、センダ１２と、ｅＰＯ２０と、レシーバ１４との間での、以下に挙げるようなものを含む、種々の管理、ヘルプ及びサポート、アカウントのメンテナンス、ｅレタープロセス処理機能を行うために重要なものである。
・ソフトウェア登録中の新規アカウントの生成
・既存アカウントでの別のコンピューターへのクライアントソフトウェア２２、２６のインストール及びアクティベーション。
・センダ１２及びレシーバ１４のクライアントソフトウェア２２、２６の自動更新。
・ｅＰＯ２０位置に保存した基本アカウント情報の閲覧及び編集。
・ｅレタークレジット（ｅレター送信料金の支払いに使用する）の購入。
・利用できるｅレタークレジットのチェック及びローカルクライアント記録の更新。
・ｅレタークレジット残高及びクレジットトランザクション（取引き）履歴の再閲覧。
・ｅレター開封により得られたクレジットインセンティブの受け取り記録の再閲覧。
・ｅＰＯ２０へのｅレター受け取りの報告。
・センダへのｅレター受け取りの通知。
・ｅＰＯ２０へのｅレター開封の報告。
・センダへのｅレター開封の通知。
・送信ｅレター履歴の再閲覧。
・送信した単一のｅレターに関する全詳細の再閲覧。
・受信したｅレターの履歴の再閲覧。
・単一の受信ｅレターに関する全詳細の再閲覧。
・ｅポスタルサービスのためのローカルクライアントコストの更新。
・パスワード及びパスワードのチェック及び更新。
・クライアントがプロセス処理できない別アドレスからのｅレターの受け取りの報告。
・クライアントがプロセス処理できる、別アドレスからではないｅレターの受け取りの報告。

図１６Ａ及び図１６Ｂに示す通り、こうしたダイレクト通信の全てに対してクライアント及びｅＰＯ２０が使用する５つの基本ステップ、即ち、Ｃ１：通信接続を開放、Ｃ２：安全なチャンネルを確立、Ｃ３：クライアントを確認、Ｃ４：メッセージを転送、Ｃ５：セッションをクローズ、があり、各ステップには以下のような色々のサブステップが含まれる。
・Ｃ１：通信接続を開放。
クライアントはｅＰＯ２０とのダイレクト通信用に記憶したＵＲＬとポート情報とを持っており、センダ１２及びレシーバ１４の全てがｅＰＯ２０用に同じＩＰアドレスを使用する必要はない。先に説明したように、物理的に異なる場所で動作してクライアント間や相互間で通信する多数のサーバーセットが存在する。更に、ｅＰＯ２０サーバー用のＩＰアドレスは時間と共に変更され（例えばセキュリティ上）、クライアントはダイレクト通信を介してｅＰＯ２０からそうした変更された情報を受け取る。任意の標準的ＴＣＰアプリケーションプロトコルを使うこともできるが、クライアントが先ず、標準的なＨＴＴＰ挙動を使用して、開放されている可能性が最も高いポート８０を介して接続を試行することが現在好ましい。通信が確立されると、クライアントはＨＴＴＰをそのまま使用して残りのダイレクト通信セッションを実行する。何らかの理由でＨＴＴＰ接続に失敗した時は、クライアントはＳＭＴＰを用い、標準及びカスタムのＳＭＴＰコマンドタグを使用してポート２５からｅＰＯ２０にダイレクトに接続する。例えば、ＳＭＴＰを使用する場合、ｅＰＯ２０が接続を承認するとクライアントは接続を認証し、クライアント自身を識別させる標準のＳＭＴＰＥＨＬＯコマンドをｅＰＯ２０に送る。ｅＰＯ２０はこのコマンドを理解及び承認し、次いでクライアントを検証する。ＳＭＴＰ通信が確立されると、クライアントは引き続きＳＭＴＰを使用して残りのダイレクト通信セッションを実行する。

・Ｃ２：安全チャンネルの確立
クライアントはこのセッション用の公開／秘密キーペアを生成させる。クライアントは、キーペアの公開キーを含むリクエストをｅＰＯ２０に送信する。この最初のリクエストメッセージを暗号化するキーはまだ設定されていないが、ｅポスタルシステム１０は、そうしたメッセージをプレーンテキストで残すのではなくむしろ、文字のランダム化及び入れ替え法を好ましく使用してメッセージの復号困難性を高める。ｅＰＯ２０は、クライアントからの最初のリクエストに含まれる公開キーを使用してセッションＩＤと対称キーとを１６進法文字に書き換えて暗号化し、クライアントへの応答メッセージでこれを返す（この場合、及び今後、１６進法文字での暗号データ書き換えは、暗号データのやりとりを可能にするための１６進法文字又はその他の類似のエンコード、例えばＵＵエンコードを使用する暗号データ書き換えを意味するものとする）。クライアントはｅＰｏ２０からの応答を受け取るとセッションＩＤ及び対称キーを記憶する。これらの各ステップで発生された対称キーは残りの通信セッション用の全転送データを暗号化及び復号化するために使用する。クライアントは、ｅポスタルサーバーがセッションを確認できるよう、このセッションでそれ以降に出すリクエストに際してセッションＩＤをｅＰＯ２０に送信する必要がある。ダイレクト通信を暗号化するためのオルタナティブとしては、ｅＰＯ２０とクライアントとの間で固定の公開／秘密キーペアを利用する方法がある。然し乍ら、ｅポスタルでは非対称暗号よりもずっと速くでき、しかも一回使用のセッションベースキーを使用する方がキーを再使用するよりもずっと安全であるという理由から、対称暗号化を基本設定としている。

・Ｃ３：クライアントの認証
クライアントはセッションＵＤと、クライアントユーザーさえ知らないクライアントＩＤナンバーを含むデータブロックと、ユーザーパスワードハッシュとを使用してリクエストメッセージを作成する。パスワードハッシュはクライアント側で記憶され得、又はユーザーがパスワードと生成されたハッシュとを要求できる。次いで、セッション対称キーを使用してデータブロックが暗号化され、１６進法文字に書き直される。クライアントはメッセージをｅＰＯ２０に送り、ｅＰＯ２０がセッションＩＤを読み取り、関連する対称キーを検索し、データブロックを復号化する。ｅＰＯ２０はクライアントＩＤナンバーとパスワードハッシュとを記録から認証し、当該セッションを認証済み（又は非認証）のものとして記憶し、次いで、認証が受け入れられた（又は受け入れられない）ことを示す応答メッセージを生成してクライアントに送る。このｅＰＯ２０からクライアントへの応答メッセージにはセッションＩＤは含まれない。なぜなら、クライアントは、これらのダイレクト通信を非同期のものとみなすｅＰＯ２０とは異なり、ｅＰＯ２０にメッセージを送るとその応答を待つからである。他の認証構成には、唯一の又は２つ以上のパラメーターを認証する構成が含まれる。大抵のｅポスタルシステム用の基本設定（ｐｒｅｆｅｒｅｎｃｅ）では、上述した通り、センダ１２の二重認証が有効に提供される。ｅＰＯ２０は安全性を高めるためにクライアントＩＤを定期的に変更することもできる。

・Ｃ４：メッセージの転送
この時点ではダイレクト通信は、本セッションのそれ以降の通信の安全性を維持し且つクライアントをｅＰＯ２０に認証させるための手段のみを確立する。引き続き転送されるメッセージは、ｅポスタルシステム１０の特徴であるｅポスタルプレミアムサービスの実施に伴う幾つかの動作又は管理動作を支援するようなものである。こうしたメッセージは、上述したクライアント認証ステップＣ３での２つのメッセージにおけるそれと同じ様式下に準備され、転送される。クライアントはリクエストメッセージを生成してｅＰＯ２０に送信する。このメッセージにはセッションＩＤと、暗号データブロックのサイズを表わすデータフィールド、セッション対称キーを使用して暗号化し１６進法文字に書き換えた暗号データブロック、が含まれる。メッセージデータは、ｅポスタル通信システム１０の特定のデータ要件、通信要求及び通信能力、そして本発明のｅポスタル通信システム１０、に適合する独自構造を有している。ｅＰＯ２０は、クライアントのリクエストメッセージを受け取ると、データブロック内に含まれる指示に従ってデータを復号化及びプロセス処理し、次いでクライアントのリクエストメッセージと同様にｅポスタル通信システム１０に対する独自構造を持つ応答メッセージをクライアント用に準備する。ｅＰＯ２０はステップＣ３の場合にそうであるようにこのステップＣ４でクライアントに応答メッセージを送る。この応答メッセージには、ステップＣ３で説明したように、セッションＩＤは含まれない。なぜなら、こうしたダイレクト通信を非同期的なものとみなすｅＰＯ２０とは異なり、クライアントはｅＰＯ２０にメッセージを送るとその応答を待つからである。ｅＰＯ２０の応答メッセージには、暗号データブロックのサイズを表わすデータフィールドが含まれ、かくして暗号データブロックはセッション対称キーを使用して暗号化され、１６進法文字で書き換えられている。本発明の説明のこれ以降の部分では、データが転送に際して暗号化されると説明される場合は、暗号データブロックが、上述したようにダイレクト通信で転送され得るように、暗号データ変換用の１６進法文字その他で書き換えられていることを意味するものとする。次いで、ｅＰＯ２０はその応答メッセージをクライアントに通信し、クライアントはデータブロックを復号化し、このデータブロックに含まれる指示に従ってデータをプロセス処理する。

・Ｃ５：接続のクローズ
クライアントは、当該セッションからの通信要求を満たすと、セッションを終了させる要求メッセージをｅＰＯ２０にダイレクト通信し、ｅＰＯ２０はその要求を承諾する応答を返す。本件出願全体を通し、ｅＰＯ２０又はクライアントの何れかからの応答内容として説明される承諾とは、承諾拒否のメッセージ、エラーメッセージ又は類似形式のメッセージに関しても使用され得るものとする。そうした他の状況では、説明した一般的プロセスに関与しないアドホック処置を引き続き使用して問題を解決する。
更には、幾つかのダイレクト通信用に上述したステップセットが変更される。大抵の場合、ｅポスタルシステム１０の動作は、種々の方法でステップＣ３及びＣ４及び又はステップＣ４及びＣ５を組み合わせた場合に最良化される。特定の組み合わせは、ダイレクト通信の使用目的と、データブロック内で使用するデータ及び指示の組み合わせを、ｅポスタル機能を最も効率化且つ安全化させる上でどれだけ最良の構成とさせ得るかに依存する。例えば、クライアントとｅＰＯ２０との間の、その全てが一組のリクエスト及び応答通信内におけるものである、クライアントからのプロセスデータ及びクライアントへの応答を認証することが好ましい場合があり得る。

ダイレクト通信に際してクライアント及びｅＰＯ２０とが使用する各ステップに関する先の議論では、独自のメッセージ構造が使用され、メッセージが、ダイレクト通信のｅＰＯ２０か又はクライアントの何れかであるレシーバのための、メッセージ中のデータのプロセス処理方法に関する指示を含んでいる。独自のメッセージ構造は図１７を参照する説明に記載される。
ダイレクト通信メッセージ中のデータフィールドは、クライアントからのリクエストメッセージやｅＰＯ２０からの応答メッセージのそれと良く似たものであり、何れも、暗号化直前のそれと同じデータブロックサイズを持つ暗号データブロックから構成される。クライアントからのリクエストメッセージとｅＰＯ２０からの応答メッセージとは、先に説明したように、クライアントからのリクエストメッセージにはセッションＩＤも含まれている点が唯一異なっている。セッションＩＤは、ｅポスタルサーバーがセッションを確認することができるよう、従って、対称キーも使用できるようにするために必要である。他方、ｅＰＯ２０からの応答メッセージにはセッションＩＤは含まれない。なぜなら、こうしたダイレクト通信を非同期的なものとみなすｅＰＯ２０とは異なり、クライアントはｅＰＯ２０にメッセージを送るとその応答を待つからである。

ｅポスタル通信システム１０用の、図１７に示す暗号化されたデータブロックの構造も独自のものである。このデータブロック４０のデータには以下のものが含まれる。先ず、既知サイズのランダムノイズブロック４２が含まれる。このデータは暗号の安全性を助成する。次ぎに、レシーバにリクエスト又は応答メッセージの形式又は目的を指定するメッセージタイプ４４が含まれる。レシーバはこのメッセージ形式によって、残りのデータブロック中に含まれるデータの種類やその対応の仕方が分かる。次いで、データストリング長さ４６及び関連するデータストリング４８の対のデータが含まれる。これらのストリング４６及び４６は、ｅポスタル機能の実行に伴う動作及び管理動作を支援するべくプロセス処理される。データストリング対の数及びその長さはメッセージ形式次第のものである。こうしたデータフィールドは、上述したように、リクエスト及び応答メッセージ用の同じ構造を提供する。標準のＴＣＰプロトコルラッパー内のメッセージング構造が同じであれば、その転送がＨＴＴＰ、ＳＭＴＰ又は任意のその他のＴＣＰアプリケーションプロトコルの何れを介したものであってもプロセス処理は類似したものとなる。ＨＴＴＰを使用する場合は、クライアントからｅＰＯへの大抵のリクエストはデータフィールドを持つＧＥＴ又はＰＯＳＴを使用し、ｅＰＯからの応答は、標準のＨＴＭＬにラッピングしたデータフィールドと、そうした応答がＨＴＭＬメッセージであることを表示するボディタグとを伴うＲＥＳＰＯＮＳＥコマンドを使用する。ＳＭＴＰを使用する場合は、ｅＰＯへの大抵のリクエストは、スペースと、ストリング“ＥＮＤ”と、＼ｒ＼ｎと、で終わるデータフィールドを伴うＥＰＳＡコマンド（ｅポスタル通信システム１０用に生成され、ｅＰＯ２０には既知のカスタマイズドＳＭＴＰ）を使用し、ｅＰＯからの応答は、スペースと、ストリング“ＥＮＤ”と、＼ｒ＼ｎと、で終わるデータフィールドを伴うＲＥＳＰＯＮＳＥコマンドを使用する。これらのリクエスト及び応答メッセージ内のデータの構造及びプロセス処理に関して考え得る多数のオルタナティブの組み合わせがある。データフィールド内の異なるコンテンツ又はデータや、データフィールド内のデータ用の異なるシーケンスが存在し得る。レシーバがメッセージ内のどのようなデータが欲しいのか、そしてそのデータで何をするか、等についてのオルタナティブでの通信が、また、こうしたメッセージを暗号化する別の方法が存在し得る。然し乍ら、上述した方法は最もシンプルなものであり、多数のＴＣＰプロトコルを使用する上で最も効率的で且つ最も柔軟性があることから、ｅポスタルシステム１０運用のために現在好ましい構造である。

図１６Ａに示すダイレクト通信ステップＣ３の先の議論ではクライアントが認証される。これは、先に端末として定義したセンダ１２及びそのｅポスタルクライアントソフトウェアが認証されると言うことである。センダ１２位置でｅポスタルソフトウェアを使用してアカウントを解説した個人又はユーザーは、自らを、クライアントからのｅレターの実際のセンダとしても認証させ得る。個人ユーザーは更に、ｅポスタルクライアントソフトウェアを使用する１つ以上の端末、例えば、オフィスのデスクトップパソコンや旅行用のラップトップパソコン上でアカウントを所有することも可能である。個人ユーザーは、自分のどの端末でも個人用及び企業用のアカウントでｅＰＯ２０を使用して容易に仕事ができるようにするための、多数の端末で使えるマルチアカウントをも所有できる他に、自分のｅポスタルアカウント及び端末のどれかを使用して多数のＥメールアドレスを使うこともできる。ｅポスタルシステム１０は、これを実現するためには、個人ユーザーのアカウント、クライアントソフトウェアを持つ端末、ｅメールアドレス用の全てのＩＤナンバーをｅＰＯ２０位置で相互に関連させて、全てのダイレクト通信及びその他のｅポスタル通信システムがそれらのＩＤナンバーや相互関連性を取り扱えるようにする必要がある。上述した複数機能サービス（ｍｕｌｔｉｐｌｅ−ｃａｐａｂｉｌｉｔｙ−ｓｅｒｖｉｃｅ）的なオルタナティブには、ｅポスタルシステム１０の個人ユーザーが所有し得るアカウント、クライアントソフトウェアを持つ端末、ｅメールアドレスの数を制限するものがある。そうした制限的構成を持つものは、管理や追跡がずっと簡単になる一方で個人ユーザーにずっと強固な総合的なサービスを提供する点で、ｅポスタルシステム１０を動作させる構造として現在好ましいものである。

図１ではセンダ１２は、インターネットを介して自分のｅメールを送信する方法として従来様式か又はｅＰＯ２０の何れかを選択できる。本発明のｅＰＯ２０を利用するためには、図１に示す本発明の構成では送受信に際しての操作上のユーザーの手間が、従来のｅメール受信操作におけるそれよりも若干増える。例えば、図２Ａ及び図２Ｂを参照して説明すると、センダ１２のユーザーはｅメールアプリケーションを開き（ステップＳ１）、でこのｅメールアプリケーション内で通常通りｅメールを生成し（添付物付き又は無しでの）（ステップＳ２）、センダ１２は単にアイコンをクリックし（ステップＳ３）、ｅポスタルシステム上でｅメールに付加させたい、選択した分かり易いサービスセットを介してプロセス処理し（ステップＳ４）、操作継続のためにクリックし、確認したｅレターを、センダ自分のＩＳＰ１９と、インターネット１８と、レシーバのＩＳＰ１９とを介して、（全てが電子的であり、センダのユーザーに対しても明らかに同じであるが）センダ自分のパソコンからレシーバ１４のユーザーに対して図１に示す如く送信する。

センダのパソコンその他にインストールされる又は動作し得る、本発明に従うセンダソフトウェア２２の一例が図２Ａ及び図２Ｂに示され且つ説明される。センダソフトウェア２２は、センダ１２のユーザーがｅポスタルサービスのアカウントを持つ利用者であることを反映する。本発明に従う様式下にｅＰＯ２０を開始する模範的ソフトウェア２４、２４’が、図２Ａ、図２Ｂ、図３Ａ〜Ｃ、図４Ａ、図４Ｂ、図６及び図７の夫々に示される。レシーバ１４のパソコンその他にインストールされるような本発明に従う模範的なレシーバソフトウェア２６は図４Ａに示される。レシーバソフトウェア２６は、レシーバ１４のユーザーがｅポスタルサービスのアカウントを持つ利用者であることを反映する。ソフトウェア２２、２４、２４’、２６の特定のコードインプレメンテーションは、運用環境、例えば、ハードウェア、システム及びアプリケーションソフト等の性質、通信システム及びその動作プロトコル、インターフェース、暗号、フィルター、ファイヤウォール、のような機能使用に基づいたものとなる。ｅポスタルシステムのユーザーが使用する、オペレーティングシステム、ｅメール、ブラウザソフトウェアの組み合わせは異なったものであり得る。本発明では、インターフェース、アドイン、又は、色々に組み合わせたプロセス及びプログラミングを使用するが、それらは各々、異なる組み合わせでの、センダ又はレシーバのオペレーティングシステム及びアプリケーションソフトウェア（リンクを介してポスタルサーバー２０とインターフェースするようにも機能するｅメールやブラウザ）とインターフェースする。

図１、図２Ａ、図２Ｂ、図３Ａ〜Ｃ、図４Ａ、図４Ｂ、図６及び図７に説明され又はこれらの図を参照して説明される如く、ｅＰＯ２０及びそのソフトウェア２４、２４’は、ソフトウェア２２及び２６と協同して、伝統的な郵便サービスのメールプロセス機能を完全な電子的プロセス下に実現する。詳しくは、本発明は、図２Ａ、図２Ｂ、図３Ａ〜Ｃ、図４Ａ、図４Ｂ、図６及び図７に詳しく示したように、以下の作用を提供するべく動作する。
・センダ１２のユーザーに被提供サービス選択上の支援を提供。
・センダ１２からのｅレターを集めてｅＰＯ２０に配送。
・ｅＰＯ２０によるｅレターの受け取り及び承諾。
・安全目的上のｅレターのスクリーニング。
・センダ１２の認証と、センダ１２のユーザーの確認。
・システムを介したｅレターのプロセス処理費用の徴収。
・サービスの適用及びｅレターのプロセス処理。
・ｅレター数の固有の削減又はフィルタリング。
・ｅレターの識別、マーキング、プライオリティ付け。
・ｅＰＯ２０のプロセス処理の日付及び時間の表示及びスタンプ。
・ｅレターの受け取り、転送及び配送の各プロセスの安全化。
・レシーバ１４へのｅレター配送。
・レシーバのユーザーによる開封を確認。
・要求に応じてのレシーバ１４からの応答／受け取りの収集。
・要求に応じてのセンダ１２へのレシーバ１４からの応答の通知。
・以下のようなその他の特別サービス。
：レシーバ１４のユーザーが自信のメールボックス／コンピューター及びｅメールアプリケーションから長時間離れている間のｅレターの保持。
：自信のメールボックス／コンピューター及びｅメールアプリケーションの動作を通してではなく、ｅＰＯ２０の“ウィンドウ”またはウェブサイトに行く、等による、ｅＰＯ２０へのアクセスオプションの提供。
：企業サイトがｅポスタルプロセスの各アスペクトをメータリング、バンドル、管理することの許可。

詳しくは、図２Ａ及び図２Ｂに又はこれらの図を参照して開示されるような、センダ１２の模範的ソフトウェア２２の機能には以下のものが含まれる。
・ステップ４で、センダ１２のユーザーが自分のｅメールアプリケーションで以下のようなｅポスタルサービスから適切なものを選択する上での補助を提供する。
：その他全てのｅメールからｅレターを差別化するための、ｅポスタルインダストリーの特別マーク、価値、設定画面の表示。
：暗号化。
：センダそのものに相対するものとしての、センダ１２のユーザーの認証（全てのｅレターではセンダ１２を認証するのが標準的である）。
：レシーバ１４がｅレターを受け取って開封したことをセンダ１２に通知。
：レシーバのユーザーによる開封を確認。
：レシーバ１４のユーザーがセンダ１２のｅレターにｅポスタルシステムを通して応答するためのプリペイド返信。
：レシーバ１４のユーザーへのハードコピーの配送。

・ｅレターをｅＰＯ２０に送信するための準備及びプロセス処理。
：ｅＰＯ２０との必要且つ適宜の通信の実行。
：ｅメールレシーバがｅポスタルシステムのアカウントを所有しているかを判定し、所有していない場合は送信者１２による選択を確認。
：送信者１２にｅポスタルシステムを使用するに十分なクレジットがあるかをチェックし、足りない場合はクレジットを更に取得する。
：ｅレターに、ｅＰＯ２０用に選択されたサービス及びその他情報をタグ付け。
：必要であればｅレターを暗号化。
：必要であればセンダ１２のユーザーの認証を実施。
：通常のｅメールＳＭＴＰ又は標準的なウェブメッセージング用ＴＨＨＰによるなどして、ｅＰＯ２０にｅレター及び又はｅレターデータを送信するための適宜のプロセスを決定。

・センダ１２の指示があった場合、コンテンツ証明用に暗号化したｅレターのリポジトリーを維持。
・ｅＰＯ２０にｅレターを送信。
・送信済みｅレターを特別のｅポスタルフォルダに保存。
・送信済みｅレターに関する返送通知を追跡。
・センダ１２における、提供されるｅポスタルサービス、要求クレジット、セキュリティー機能、といった部分を最新状態に維持するための、管理及び維持に関する様々のアカウントアクティビティーを実施。
・センダ１２の、ｅポスタル通信やｅＰＯ２０との相互作用の管理を支援。
・センダ１２のｅメール及びブラウザアプリケーションとのシームレスな動作。
先に説明され、図２Ａ及び図２Ｂに示した模範的なセンダソフトウェア２２に関し、動作上の更に他の代表的なプロセス処理ステップシーケンスと、現在好ましいシステム構造とが図１８Ａ及び図１８Ｂを参照して以下に説明される。

図１８ＡのステップＳＰ１での、ｅメールアプリケーションの中でｅポスタルサービスを使用開始するためのオルタナティブ及び、特定のサービスを選択するオルタナティブには以下ようなものが含まれる。
・ユーザーが、新規ｅメールの作成前又は作成後に、使用するサービスを選択できるオルタナティブ。ユーザーは、新規ｅメールを作成する前後何れの場合でも、新規ｅメールを作成し終えたこと及び、作成済みｅメールをｅポスタルシステム１０を使用して送信できる状態にあることを何らかの方法で表示する。従って、新規ｅメール作成の前後何れの場合でも、サービス使用を容易化するためにｅポスタルシステムの使用時点を指定する必要があり、また、何れの場合でも、新規のメッセージウィンドウ内にはｅポスタルプロセス選択用の手段が含まれることが要求される。
・新規メッセージウィンドウ内からの選択に関するオルタナティブとしては、ツールバー上のアイコンボタン、又はドロップダウンメニュー内に並ぶアイテムをクリックして使用するｅポスタルサービスを選択するものがある。ｅポスタルシステム１０は、ユーザーがサービスを最も柔軟に且つ容易に使用できるように何れのオルタナティブをも取り扱えることが好ましい。
・新規ｅレターに付加する特定ｅポスタルサービスの選択に関しては、ｅポスタルサービスを選択できる１つ以上の連係画面と、ユーザーが、選択するサービスをレビューし、選択したことを確認できる第２画面とを提供するオルタナティブがある。ｅポスタルシステムがユーザーに提示する画面はできるだけ少なくし、例えば、１つの画面のみを使用して、ユーザーがサービスを選択し、レビューし、送信用サービスとして確認できるようにすることが好ましい。然し乍ら、ユーザーに提示されるサービスの範囲が広すぎる又はユーザーのｅメールアプリケーション上で別の画面が必要になるような場合は、ｅポスタルシステム１０は２つの画面を使用することが好ましい。

上述したように、ｅポスタル機能を実施するために入手可能なオルタナティブのどれを選択するかは、特定のオペレーティングシステム、ｅメールアプリケーション、センダ１２及びレシーバ１４の持つウェブブラウザ、との組み合わせ次第のものである。使用されるｅポスタルソフトウェア２２及び２４は、既存のオペレーティングソフト、ｅメールアプリケーション、ウェブブラウザソフトウェアの組み合わせの中で動作する特定バージョンのものである。先に述べたように、ｅポスタルソフトウェア２２及び２４の特定バージョンは、ソフトウェア２２及び２４のインストール時に、ユーザーの提供するオペレーティングシステム、ｅメールアプリケーション、ウェブブラウザソフトウェアに関する情報の解析と、データに関して含まれ得る任意の認証チェックとをｅＰＯ２０が実施した後に決定される。
代表的な送信者ソフトウェア２２（図２Ａ及び図２Ｂに示し且つこれらの図を参照して先に説明された）及びセンダのプロセスシーケンス及び好ましい構成（図１８Ａ及び図１８Ｂに示した）に関しては、センダ１２は、ユーザーが、付加したいサービスを選択し、これをクリックしてｅポスタルシステムを通してｅメールを送信した後、ステップＳＰ２で、新規のｅレターのプロセス処理を開始する。センダ１２のこのプロセス処理についても、その方法及び選択上のオルタナティブがある。

センダ１２によるプロセス処理の実施方法のオルタナティブには、選択されたサービスのコストや、要求されるｅポスタルクレジット数をセンダ１２が決定することが含まれる。ｅＰＯ２０は、各センダ１２アカウント用のｅポスタルクレジットの残高及び履歴を記録した公式のクレジットバンクを持っている。センダ１２は、ｅＰＯ２０位置でのプロセス処理時に、センダ１２が、ステップＳＰ３で新規のｅレターをカバーするに十分な残高を持っていることをｅＰＯ２０のクレジットバンク位置で確認するためにダイレクト通信を使用できる。オルタナティブには、ステップＳＰ４で、センダ１２が自分の各アカウントに関するｅポスタルクレジット使用の残高及び履歴を追跡するローカルｅポスタルクレジットバンクを有するものがある。ｅポスタルシステム１０はセンダ１２位置のローカルバンクと、ｅＰＯ２０位置の公式のクレジットバンクとの何れをも有することが好ましい。なぜなら、センダ１２は、ｅＰＯ２０位置でセンダ１２のアカウントクレジット残高をチェックするべくダイレクト通信を使用できるオンライン状態にない又はオンライン状態になれない場合があり得るからである。センダ１２がローカルバンクを所有する場合は、オンライン状態にならなくともｅＰＯ２０位置に保持された公式のアカウントクレジット残高を見積もることが可能である。センダ１２がダイレクト通信を使用してｅＰＯ２０位置でクレジット残高をチェックすることが好ましく、他方、センダ１２がオンライン状態になれない時は、センダ１２が新規ｅレター用のアカウントクレジット残高を見積もるためのローカルクレジットバンクを有することが好ましい。ステップＳＰ５では、新規ｅレター用のクレジット残高が足りない場合に、センダ１２のソフトウェア２２が、ｅＰＯ２０とダイレクト通信してｅポスタルクレジットを購入するプロセスを開始する。更に他のオルタナティブには、図３Ａ〜Ｃに示すように、ユーザーが自分のウェブブラウザを使用してｅＰＯ２０のウェブサイトに行ってｅポスタルクレジットを購入し、ｅＰＯ２０ソフトウェア２４を使用するものが含まれる。ユーザーは、ダイレクト通信によるクレジット購入及びウェブサイト位置でのクレジット購入を含む何れのオルタナティブも利用できることが好ましい。

センダ１２による新規ｅレターのプロセス処理のオルタナティブとしては、ｅレターレシーバのｅメールアドレスの各々がｅＰＯ２０位置のユーザーアカウントのどれかに関連しているか否かを、例えば、センダ１２がｅＰＯ２０とダイレクト通信して確認することを含むものがある。ｅＰＯ２０位置で各レシーバのステータスをチェックするオルタナティブには、ステップＳＰ６でレシーバのｅメールアドレスをチェックしないものが含まれる。ｅポスタルシステム１０の使用方法としてどれを選択するかは、ｅポスタルシステム１０の、他人へのユーザー情報開示に関するプライバシーポリシーの取り扱いに依存する。

本発明の実施順序を逆にするオルタナティブでは、レシーバｅメールアドレスをチェックし、次いでｅポスタルクレジットをチェックする。大抵の場合、ｅレターのプロセス処理を実際に行う特定ステップの順序は重要なものではない。実際、プロセス処理を実施するための数多くのオルタナティブがある。他方、それ以外では実施し得ない固有の順序を持つ幾つかのプロセス処理ステップがある。シーケンスの重要性は、センダ１２でインストールしたソフトウェア２２のバージョン、ユーザーが選択したｅポスタルサービス及びその他の、ステップＳＰ７に示したような変数に依存する。

模範的ソフトウェア２２（図２Ａ及び図２Ｂ及びこれらの図を参照して先に説明した）及びセンダのプロセス処理及び好ましい方法（図１８Ａ及び図１８Ｂ）に関しては、ステップＳＰ７でのセンダ１２によるｅレターのプロセス処理もまた、センダ１２からレシーバ１４にｅレターを送信し、プロセス処理し、配送するために選択する、先に説明したような各ステップに依存する。要約すると、主要な２つのオルタナティブでは、ｅレターメッセージそのものをｅＰＯ２０を介して又はｅＰＯ２０を迂回して送信するか、又はｅレターメッセージをレシーバ１４にダイレクトに送信する。これら２つのオルタナティブのための補助的なオルタナティブでは、センダ１２から送信されるｅレターメッセージをレシーバ１４に配送するべくｅレターを要求通りプロセス処理するのに必要な量のｅＰＯデータをｅレターメッセージと共に送信する。大抵の場合、ｅポスタルシステム１０は以下に議論する理由により好ましく実行される。
・センダ１２が、ｅレターメッセージと、もし全てでなければ殆どのｅポスタルプロセス処理データをセンダＩＳＰ１９のメールサーサーバーを介してｅＰＯ２０に送信し、その他の残余分をｅポスタルダイレクト通信を介してｅＰＯ２０に送信する。
・次いで、ｅＰＯ２０がｅレターメッセージと、もし全てでなければ殆どのｅポスタルプロセス処理データをレシーバＩＳＰ１９のメールサーサーバーを介してレシーバ１４に送信し、その他の残余分をｅポスタルダイレクト通信を介してレシーバ１４に送信する。

ステップＳＰ８でセンダ１２がｅレターをプロセス処理する代表的ステップが以下に説明され且つ図１８Ａ及び図１８Ｂに示される。これらのステップは一般に、センダ１２からレシーバ１４にｅレターを送信するために考え得る全てのオルタナティブを含み、そうした構成には、ｅレターメッセージそのものと、もし全てでなければ殆どのｅポスタルプロセス処理データをｅＰＯ２０を介してセンダ１２からレシーバ１４に送信することによる、一般に好ましい実施構成が含まれる。
送信及び配送に関する代表的なオルタナティブ（ｅＰＯを介した又は介さない）の全ては、以下に説明する幾つかの又は全てのシステム構造を使用して実施され得る。即ち、
・センダ１２位置でｅレターをプロセス処理するための、上述した及び以下に説明する運用上のシステム構造。
・ｅＰＯ２０位置でｅレターをプロセス処理するための、上述した及び以下に説明する運用上のシステム構造。
・レシーバ１４がｅレターを受信し且つプロセス処理するための、上述した及び以下に説明する運用上のシステム構造。
・上述したダイレクト通信を実施するための方法。
・レシーバ１４にｅレターを送信するためにセンダ１２が使用するべき方法に関する、ダイレクト通信、ｅポスタルｅレター、その他のｅポスタルコミュニケーションを介してｅＰＯ２０からセンダ１２及びレシーバ１４に通信された情報。

センダ１２は、ｅＰＯ２０及びｅポスタルシステム１０全体（レシーバ１４を含む）に対して、ｅレターのプロセス処理及びレシーバ１４への配送をどのように継続するかを分からせるに十分なｅポスタルデータ及び指示が含まれるようにしてｅレターが準備されるようにｅレターをプロセス処理する。このデータはその他の、例えば、件名中、又は本文中、又は添付物（本分の一部として考慮され得る）として、または、カスタムヘッダとしての如き様々な場所泥ーレターに加入され得る。ｅポスタルシステム１０はステップＳＰ９でカスタムヘッダ又は多数のカスタムヘッダを使用することが好ましい。センダ１２位置で特定のｅメールにカスタムヘッダを付けられない場合又はデータをその他の位置に置かなければばならない場合は、その他の場所を使用する。

ステップＳＰ９で、センダ１２はｅＰＯ２０位置でｅレターをプロセス処理するためのデータのみならず、ｅレターを認証及び確認するためのデータをもカスタムヘッダに含ませるように調製する。ｅレターメッセージがセンダ１２からｅＰＯ２０に転送される間に変化していないことが認証作業により示され、ｅレターが実際にセンダ１２自身からのものであることが確認作業によって示される。ｅＰＯ２０位置で受信されるｅレターは数値シーケンスでプロセス処理される。これは、カスタムヘッダ内のデータは色々の異なる方法で取り込まれ得ることを意味する。本発明の好ましい構成は、ｅレターをｅＰＯ２０位置で先ず識別し、認証及び確認し、次いで残りのプロセス処理を実施するというものである。この構成が好ましいのは、ｅメールが真正（ｂｏｎａｆｉｄｅ）なｅポスタルユーザーアカウントからのものでない時は、ｅＰＯ２０が、ｅレターではないそうしたｅメールを完全にプロセス処理する理由がないからである。従って、識別、認証及び確認用のカスタムヘッダ内のデータは、データのプロセス処理以前、又は少なくとも同時に、カスタムヘッダから取得されるべきである。

図１９には代表的なカスタムヘッダが３つの部分１、２、３が示され且つ説明される。あるいはこれらの３つの部分全てを１つのカスタムヘッダとして、又は３つのカスタムヘッダ、又はそれ以上の数のヘッダとして取り扱い得るが、１つのカスタムヘッダに３つの部分が含まれることが好ましい。カスタムヘッダ内の３つの部分の物理的シーケンスは通常はそれほど重要ではないが、使用する論理シーケンス下に順序付けされることが好ましい。
図１９の部分１にはセンダ１２のＩＤナンバーが含まれる。ｅＰＯ２０は、ｅレターがｅＰＯ２０に届いた時点でこれらのナンバーからセンダ１２を識別する。ｅＰＯ２０は、これらのナンバーから、カスタムヘッダの部分２を復号化するために使用する暗号化キーを知る。

図１９の部分２は、ＭＤＣ（メッセージダイジェストコード）バリューと、カスタムヘッダの部分３を暗号化する暗号化キーとを含む。ＭＤＣは、ｅレターを、ｅＰＯ２０に届いた時点で認証するために用いる。この方法は、ｅレターがセンダ１２からのものであることを確認するための多数の方法の１つでもある。
図１９の部分３は、以下を含むｅポスタルプロセス処理データを含む。即ち、
・独自データセット、例えば、ｅレターを識別し且つｅレターに関する将来のトランザクションをプロセス処理し且つ追跡するために使用する数値データセット。
・センダ１２が選択したｅポスタルサービスを識別するデータ。
・センダ１２及びレシーバ１４に関する、ＩＤナンバーやｅメールアドレスのようなデータ。“Ｔｏ”、“ｃｃ”、“ｂｃｃ”の情報はｅレターのヘッダから削除され、そのハッシュ値と共に部分３に配置される。“Ｆｒｏｍ”や“Ｒｅｐｌｙｔｏ”の情報も、ハッシュ値と共に部分３に配置される。センダ１２用のｅＰＯ２０のＳＭＴＰｅメールアドレスが、“Ｔｏ”ヘッダ内の本来のレシーバｅメールアドレスで置換され、かくして、ｅレターをｅＰＯ２０にリダイレクトさせ得るようになる。このデータのハッシュ値により、追加的方法を使用してｅレターの安全性をチェックしセンダ１２を確認できるようになる。
・暗号サービスが選択された場合にｅレターメッセージ本文を復号化するための暗号化キー。

図１９には示されないが、部分１、２、３内の任意のデータは、ｅＰＯ２０が何らかのその他方法によってその情報を知り得ない限り、データサイズを含んでいる。やはり図１９には示されないが、部分２及び３には、これらの部分を安全上暗号化する前にランダムノイズを付加し得る。ダイレクト通信の説明で述べたように、カスタムヘッダは、その中に暗号データを含むことから、転送用に１６進法コードで書き換えられる。
あるいは、ヘッダは３つではなく２つの又は３つ以上の部分を有し得るが、その内の一つの部分は、残余のカスタムヘッダの復号化用に使う暗号化キーがｅＰＯ２０に分かるよう、センダ１２のＩＤナンバーをプレーンテキストで記述する必要があるので、これらの部分の最小数は２つとなる。然し乍ら、部分数を３つにすれば、別の暗号化キーを使用して部分３内のデータを別様に暗号化して安全性を高め得ると共に、部分２内のデータを使用する場合のそれとはまた別に復号時の認証及び確認が提供される点で安全性が一段と高くなる。部分数を３つ以上とし、暗号化ステップを増やすことで安全性は非常に高くなるが、こうした構成は非通常状況を除いては不要である。ヘッダ構造及びｅポスタルシステム１０の運用方法としては、図１８ＡのステップＳＰ９で、図１９に示すような３つの部分を持つカスタムヘッダを使用する方法が好ましい。

模範的なセンダソフトウェア２２（図２Ａ及び図２Ｂ及びこれらの図を参照して先に説明した）及びセンダの代表的なプロセス処理（図１８Ａ及び図１８Ｂに示され且つ説明された）では、図１８ＡのステップＳＰ１０で、ｅレターのカスタムヘッダをｅレタープロセス処理の一部として使用し、そのヘッダから“Ｔｏ／ｃｃ／ｂｃｃ”情報を削除してカスタムヘッダの部分３に配置する。次いで、ステップＳＰ１１で、ｅレターをｅＰＯ２０に送るためのｅメールアドレスが“Ｔｏ”ヘッダ内に配置される。ＳＭＴＰを使用してｅレター送信するオルタナティブには、オリジナルのレシーバ１４のアドレスが“Ｔｏ”、“ｃｃ”、“ｂｃｃ”の各ヘッダ内に保持されるＳＭＴＰリレールーティングを使用するものがある。このオルタナティブでは、各レシーバ１４用のｅレターはｅＰＯ２０位置で別々に受信され、次いでｅＰＯ２０が各ｅレターをプロセス処理してレシーバ１４に送る。このオルタナティブは、以下にもっと詳しく説明するように、ｅＰＯ２０位置のレシーバ数が多い場合のｅレターのプロセス処理を多少簡易化し得るが、センダＩＳＰ１９が、別々のレシーバアドレスの各ｅレター又は任意のｅレターをリレーする保証はないので、ｅＰＯ２０にｅレターが配送される確実性はずっと低くなる。従って、ｅポスタルシステム１０は、ステップ１０で、上述したように“Ｔｏ”、“ｃｃ”、“ｂｃｃ”のヘッダからレシーバ１４のアドレスを削除し、これをカスタムヘッダの部分３内に配置してｅレターを送信し、ステップＳＰ１１で、ｅレターをｅＰＯ２０にダイレクト送信する“Ｔｏ”ヘッダ内のセンダ１２用の特定ｅＰＯ２０アドレスを置換させることが好ましい。この好ましい構成を使用することで、ｅポスタルシステムは実際の転送ルートに一致する１つのアドレシング情報を維持し、かくしてリレーによって生じ得るその他の問題が回避される。

模範的なセンダソフトウェア２２（図２Ａ及び図２Ｂ）、センダ１２でのｅレターのプロセス処理及び好ましい構成（図１８Ａ及び図１８Ｂ）、を含む先の議論や、センダでのｅレターのプロセス処理の一部としてのカスタムヘッダ調製を含む上記議論では、暗号及び暗号化キーの使用が説明される。実際、暗号化は、以下に挙げるような、ｅポスタル通信システム１０内の多くの部分で必要とされる。
・ｅポスタル暗号サービスが選択された場合のｅレターメッセージ本文（ここではｅレターメッセージの“本文”とは、全て、“添付物”をも意味するものとする）。
・ｅポスタルプロセス処理データを含むｅレターカスタムヘッダ。
・ダイレクト通信。
・クライアント、ネットワークレベル、ｅＰＯ２０の各位置に記憶されたｅポスタルシステムデータ。

暗号化を実施するための多数のオルタナティブがある。例えば、有効変数には暗号化アルゴリズムや暗号化キー長さが含まれる。暗号化アルゴリズムは非対称又は対称のものであり得、この２つのカテゴリーには多数の特定のオルタナティブがある。代替アルゴリズムは公共的及び商業的に入手が可能なもの及び又はｅポスタルシステム１０が持つものであり得る。また、使用するアルゴリズムは、センダソフトウェア２２またセンダ１２の端末のオペレーティングシステムで使用するセンダソフトウェア２２が呼び出して使用する暗号化ライブラリ内に含まれるものであり得る。

クライアント、ネットワークレベル、又はｅＰＯ２０の何れかの位置でｅポスタルシステム１０が実行する任意の暗号化及び復号化プロセスの構成は、クライアントソフトウェア、ｅポスタルネットワークソフトウェアの動作環境（図８での）、ｅポスタルシステム１０の、暗号システム互換性に対するニーズやリソース次第のものである。好ましい構成形態は、選択した暗号／復号用のアルゴリズムの相対的な安全性及び速さにも依存する。最も一般的には、ｅレターメッセージ本文暗号化用のｅポスタルシステム１０の好ましい形態は、所望の安全性レベルを提供するに充分な長さであるように選択した対称アルゴリズム及びキーを使用するものである。ｅポスタルシステム１０は、センダ１２のオペレーティングシステムから呼び出せるアルゴリズムを使用する。もしそうしたアルゴリズム又はライブラリを取得できない場合は、センダソフトウェア２２に充分な対称アルゴリズムが提供される。これらのオルタナティブ及び優先性は、ｅポスタルシステム１０が実行する暗号法の全機能、例えば暗号化、復号化、ハッシング機能に対して適用され得る。ｅポスタルシステム１０のニーズによって幾つかのその他の好ましいオルタナティブが要求される状況もあり得る。そうした状況の一例には、クライアントとｅＰＯ２０との間でダイレクト通信を開始する場合が含まれる。この状況では非対称の公開／秘密キーペアが使用される。また、上述したように、ｅポスタル通信システム１０がインターネット上で転送するべき暗号データを持っている場合は、常に、この暗号データは転送できるように１６進法文字その他の幾つかの類似形態、例えばＵＵエンコードに書き換えられる。

センダ１２のプロセス処理には、ステップＳＰ１３で、ユーザーがｅポスタルサービスを選択した場合にｅレターメッセージ本文を暗号化することが含まれる。ユーザーが暗号化サービスを選択した場合は、安全目的上、ユーザーにパスワード入力を求める又は求めないオルタナティブがある。暗号化サービスの選択に関しては、ｅポスタルシステム１０はデフォルトではユーザーにパスワード入力を要求しないことが好ましいが、ユーザーは自分のパスワードを用いた場合にのみ可能なｅポスタルオプション及び設定画面を使用してこのデフォルトを変更することもできる。
先に説明したように、センダ１２は、一回使用の、充分に強力な対称キーと、センダ１２のオペレーティングシステムの暗号化ライブラリをリソースとするアルゴリズムとを使用して暗号化を実行する。そうしたライブラリ及びアルゴリズムはｅＰＯ２０には既知のものである。ステップＳＰ１３でメッセージを暗号化した後、ステップＳＰ１４で、センダ１２はｅレターのカスタムヘッダの部分３に対称キーを配置する。ステップＳＰ１２で、センダ１２はｅレターメッセージ本文を暗号化する前にメッセージ本文のＭＤＣハッシュをも生成する。

ステップＳＰ１５で、センダ１２は図１９に示す全ての代表データを含むカスタムヘッダの部分３の構造化を終了する。ステップＳＰ１６で、センダ１２は一回使用の、充分に強力な対称キーと、センダ１２のオペレーティングシステムの暗号化ライブラリをリソースとするアルゴリズムとを使用して部分３全体を暗号化する。
部分３を暗号化した後、ステップＳＰ１７で、センダ１２はカスタムヘッダの部分２を構造化し、ステップＳＰ１８で、部分３全体を暗号化するために使用した対称キーを部分２に配置する。ステップＳＰ１８で、センダ１２はＭＤＣデータを使用して、図１９に示し且つ先に説明したようにして部分２に書き込み（ｆｉｌｌｏｕｔ）、次いで、ステップＳＰ２１でカスタムヘッダの部分２を暗号化する。

ステップＳＰ２１でのカスタムヘッダの部分２の暗号化には２つのオルタナティブがある。
第１のオルタナティブでは、センダ１２でのクライアントソフトウェアをアクティベーションする際に、クライアントが部分２の暗号化に使用できる暗号化キーを保存する。暗号化キーは、ｅＰＯ２０の復号化用の秘密キーと合致するセンダ１２の秘密キーを使用して部分２を暗号化する場合は非対称の公開／秘密キーペアタイプであり得、ｅＰＯ２０も対称キーを持っている場合は対称形式のものであり得る。対称アルゴリズムはより高速で且つ比較的強力なので、非対称キー及び対称キーの設定に関してはｅポスタルシステム１０では対称キーを使用することが基本設定となる。

第２のオルタナティブでは、センダ１２がオンライン状況にある場合、センダ１２はｅＰＯ２０とのダイレクト通信を使用して、ｅＰＯ２０から、ｅレターのカスタムヘッダの部分２を暗号化するために使用できる一回使用の対称キーを取得する。
ｅポスタルシステム１０は、何れのオルタナティブをも使用できることが好ましい。センダ１２がオンライン状態にある場合、ステップＳＰ１９で、センダ１２はｅＰＯ２０とのダイレクト通信を使用して一回使用の対称キーを取得し、特定の一回使用キー及びｅレターに結びつく特定のセンダ１２ＩＤナンバーをｅＰＯ２０に残す。センダ１２がオンライン状態になれない場合は、ステップＳＰ２０で、センダ１２は記憶した対称キーを使用してカスタムヘッダの部分２を暗号化する。何れの場合でも、ｅＰＯ２０は、ｅレターと、このｅレターのカスタムヘッダ内のｅポスタルプロセス処理データとがｅＰＯ２０に届いた時、カスタムヘッダの部分１内のセンダ１２ＩＤナンバーによって、部分２の復号化用に使用するべき暗号化キーを識別する。部分２を暗号化及び復号化するためにクライアント及びｅＰＯ２０位置に記憶された対称キーは、安全目的上定期的に変更することもできる。

ステップＳＰ２２で、センダ１２はカスタムヘッダの部分１内にセンダ１２ＩＤナンバーを配置し、かくしてｅレターのプロセス処理を完了する。ステップＳＰ２３で、センダ１２はｅレターにカスタムヘッダを配置し、新規にプロセス処理したこのｅレターをセンダ１２のｅメールアプリケーションの“送信ボックス”に入れ、又はステップＳＰ２４で送信ｅメール保持用フォルダに入れる。ステップＳＰ２６で、ｅメールアプリケーションはｅメールを“転送”する送受信イベント待ち状態にあり、このイベントの発生時にはセンダ１２ＩＳＰ１９のメールサーバーと通信し、“送信ボックス”からｅレターを実際に転送する。本プロセスのオルタナティブでは、可能であれば、センダ１２はｅレターをプロセス処理する前に、ｅメールアプリケーションの“送信ボックス”に入れる。次いで、実際の“転送”送受信イベントが生じ、センダ１２がｅレターをプロセス処理し、かくしてｅレターがセンダＩＳＰ１９に転送される。

“転送”送受信イベントが実際に起こるまでｅレターのプロセス処理を待つオルタナティブは、以下の点に基づく利益、即ち、
・プロセス処理状況下において、ｅメールアプリケーションの“送信ボックス”内にｅレターが一時的に常駐し無いので観察されない。
・実際の“転送”イベント時にはセンダ１２の端末はオンライン状態にあるので、センダ１２は自分の端末をオンライン状態にする必要のあるｅレタープロセス処理の利益を得られる。

基本設定では“待ち”であるが、オペレーションシステム、ｅメールアプリケーション、ウェブブラウザの組み合わせによっては、クライアントが“転送”イベント時にｅレターをプロセス処理できない場合もある。従って、“転送”イベント以前にプロセス処理することが選択オプションとなる第１のオルタナティブがある。“転送”イベント以前にプロセス処理する必要がある場合は、プロセス処理したｅレターはｅメールアプリケーションの“送信ボックス”内にしばらく留め置かれ、その間、センダ１２はユーザーのリクエストに応じて、プロセス処理したこのｅレターを“送信ボックス”から取り出し、ユーザーがこのｅレターの宛先、内容、本文、ｅレター用に選択したｅポスタルサービスを変更（ステップＳＰ２５でのｅレター用のｅポスタルサービスのキャンセルを含む）できるようにする。

ｅレターがセンダＩＳＰ１９に送られた後、ステップＳＰ２７で、センダ１２はｅレターが送信されたことを確認し、ステップＳＰ２８で、“Ｔｏ”、“ｃｃ”、“ｂｃｃ”のｅメールアドレス用の全オリジナルデータをリセットし、ステップ２９で、ｅレターメッセージ本文が暗号化されている場合はこれを復号化し、ステップＳＰ３０で、ｅレターを適宜のｅポスタル送信アイテムフォルダに仕分けする。ステップＳＰ３０で、ユーザーオプションや基本設定メニューアイテムからユーザーに提供される任意の特定ソーティングも実施され得る。

模範的なセンダソフトウェア２２（図２Ａ及び図２Ｂ）と、センダの好ましいプロセス処理ステップ（図１８Ａ及び図１８Ｂ）に関し、ステップＳＰ３１で特定のｅポスタルフォルダ内にｅレターを仕分け、移動し、保存するための代表的且つ好ましいシステム構造及び構成を以下に説明する。これらのｅポスタルフォルダは、センダ１２が、送信したｅレターのコピーや、受信してレシーバ１４位置でプロセス処理したｅレターを置いておく場所である。従って、ｅポスタルの送信アイテム及び受信フォルダは特定の基本フォルダとなる。その他の特定フォルダは、センダ１２がｅポスタルオプション及び基本設定画面を使用することで、又はクライアントインストール中にｅＰＯ２０によって、又は、ダイレクト通信やｅＰＯｅレターによって作成される。ｅレターを、最初に入れたｅポスタルフォルダから別のフォルダに移すためのオルタナティブがある。ある方法は、ｅポスタルフォルダから取り出したｅレターを任意のその他のフォルダ（ｅレター用ではないフォルダを含む）に出し入れできるものであり、他の方法は、元のフォルダからのｅレターの移動を禁止するものである。ｅポスタルフォルダの安全性を保証し、ｅレターの移動及びｅポスタルユーザーによる仕分けのための最適な柔軟性は、以下のような構成とすることで好ましいものとなり得る。即ち、
・ｅレターを任意のその他のｅポスタルフォルダに移動できる。
・ｅレターをｅポスタルフォルダから別のｅメールフォルダに取り出せる。
・ｅポスタルフォルダから取り出したｅレターを、このｅレターが無変更のものである場合は任意のｅポスタルフォルダに戻せる。
・ステップ３２で、非ｅポスタルのｅメールを任意のｅポスタルフォルダに移動できない。

こうした基本設定によれば、ｅポスタルフォルダにとって安全上のリスクのある任意の非ｅポスタルｅメールからｅポスタルフォルダを守ることができる。各ｅレターは、ｅポスタルフォルダに戻す前にｅレターとして認証され確認される。
代表的センダソフトウェア２２（図２Ａ及び図２Ｂ）及びセンダの好ましいプロセス処理ステップ（図１８Ａ及び図１８Ｂ）に関しては、センダ１２が選択したサービスに、ステップＳＰ３３でのセンダ１２への受信の通知、レシーバ１４のｅレター開封、レシーバ１４がｅレターを開封したユーザーの一人であることの認証、の各サービスが含まれる場合は、そうした通知を送るシステム構造及び構成の代表的オルタナティブには以下に説明するものがある。これらのオルタナティブには、一通のｅレターに対するセンダ１２への通知回数、例えば、ｅレターの受け取り及び開封の何れも通知する、又は、一通のｅレターに対して開封時に一回だけ通知するものが含まれる。また、それらのオルタナティブには、センダ１２に対する通知方法が含まれ、そうした通知は、センダ１２にｅレターを返送することによるもの及び又は、センダ１２がｅメールアプリケーションのｅポスタルメニューアイテムを使用するか又はｅＰＯ２０ウェブサイトに行ってログインし、情報をリクエストして自分が送ったｅレターの履歴をチェックすることによるものがある。ｅポスタルシステム１０は、ステップＳＰ３４で、ｅポスタルオプションやｅポスタルメニューアイテムの基本設定の中でユーザーが選択できるオプション範囲が提示される構成のものであることが好ましい。

模範的なセンダソフトウェア２２（図２Ａ及び図２Ｂ）及びセンダの好ましいプロセス処理ステップ（図１８Ａ及び図１８Ｂ）に関しては、レシーバ１４に対して、センダ１２からのｅレターを開封するｅポスタルクレジットのインセンティブのための、以下に説明するシステム構造及び構成のオルタナティブがある。多数のオルタナティブの幾つかには、インセンティブを誰にも与えないもの、ｅレター開封のための同じインセンティブを全てのレシーバ１４に与えるもの、個人やグループ毎に、ｅポスタルシステム１０の管理上の決定に従う別のインセンティブを与えるもの、センダ１２が、ｅレター開封のためにレシーバ１４に与えるインセンティブ量を決定できるもの、が含まれる。ｅポスタルの“ｅレター開封インセンティブ”機能を利用する際のｅポスタルシステム１０及びセンダ１２の柔軟性が最大となるよう、ｅポスタルシステム１０がこれら全てのオルタナティブその他を動作させ得ることが理想的である。

模範的なセンダソフトウェア２２（図２Ａ及び図２Ｂ）及びセンダの好ましいプロセス処理ステップ（図１８Ａ及び図１８Ｂ）に関しては、ｅポスタル暗号化サービスのための、以下に説明するシステム及び構成及び方法のオルタナティブがある。それらのオルタナティブには、ｅレターの暗号化に先立ち、センダがユーザーにパスワード入力を要求できる又はできないものがあり、また、暗号化されたｅレターを受け取った時点でレシーバ１４が、復号化前にユーザーにパスワード入力を要求できる又はできないものがある。ｅポスタルシステム１０は、デフォルトで、暗号化に際してはパスワード入力を要求しないが、復号化に際してはパスワード入力を要求するようにクライアントソフトウェアをインストールしていることが好ましい。更には、ステップＳＰ３４で、ユーザーはｅポスタルユーザーオプションや基本設定メニューからその他の上記オルタナティブを選択できる。

詳しくは、図３Ａ〜Ｃ、図４Ａ、図４Ｂ、図６及び図７に示され又はこれらの図を参照して説明されるように、ｅＰＯ２０（ｅポストオフィスの略称）の模範的ソフトウェア２４、２４’の機能には、以下に挙げるｅＰＯ２０での全てのプロセス処理及び管理上の動作を管理することが含まれる。
・センダ１２のｅメールの受け取り。
・テクニカルリスクのためのｅメールのスクリーニング。
・センダ１２を認証。
・センダのｅメールを取り扱いを許可するためのセンダ１２のアカウント閲覧。
・必要郵送料に関し、センダ１２のアカウントを借方に記入。
・コンテンツのスクリーニング。
・センダ１２のｅメールの公式受け取り及び仕分け。
・レシーバ１４がｅポスタルサービスのアカウントの有無を確認。
・センダ１２のｅレターをレシーバ１４に配送する準備。
・タグ付け、プライオリティ付け、センダの端末の認証、センダ個人の認証、暗号化、通知、レシーバ個人の認証、プリペイドリプライ、ハードコピー配送、等の全ての要求サービスに対するセンダ１２のｅメールのプロセス処理。タグ付け、プライオリティ付け、その他のセキュリティーコード化により、ｅポスタルのマークや標識の盗用が防止される。
・その他の配送上の特別の指示の実行。
・ｅＰＯ２０のプロセス処理の日付スタンプ生成。
・センダ１２のｅレターをレシーバ１４に配送。
・プロセス処理したｅレターに関し、センダ１２及びレシーバ１４のアカウントを付与（ａｄｍｉｎｉｓｔｅｒｉｎｇ）。
・必要であれば、レシーバ１４から、ｅレターの受け取り及び開封についての確認と、各レシーバについての認証とを取得及び記録。
・ｅレター開封についてのレシーバ１４のインセンティブアカウントを借方に記入。
・レシーバ１４からの通知をセンダ１２に転送。
・継続中のセンダ１２及びレシーバ１４のアカウントメンテナンスの実施。
・センダ１２及びレシーバ１４のユーザー及びそれらユーザーのｅポスタルソフトウェア２２、２６との、要求された且つ適宜の通信。
・センダ１２／レシーバ１４位置でのｅポスタルソフトウェア２２、２６の更新。
・ｅポスタルシステムを使用するアカウント開設、センダ／レシーバソフトウェアの取得及びインストールに関してのユーザー支援。
・ｅポスタルアカウント及びソフトウェアを持たないセンダ１２からレシーバへのｅレター配送の支援。
・ｅポスタルアカウント及びソフトウェアを持たないレシーバーの、ｅＰＯウィンドｗまたはウェブサイトでのｅレターへのアクセス支援。
・要求時における、ｅレタープロセス処理の時間／日付の公式の解析結果の作成。
・要求時における、安全なｅレターコンテンツの解析的確認。

これらのサービス及び、以下に説明するレシーバソフトウェアと組み合わされ且つ基本的なインターネット及びウェブメッセージングシステム及び方法によっては本発明におけるようには提供されないサービス（既存のｅメール及びウェブメッセージングアプリケーションやブラウザアプリケーションとシームレスに動作する、一体システムの一部として提供される自動的又は選択自在のサービス）を、ここでは“プレミアムサービス”と称する。
また、先に言及し且つ図１０に示したように、本発明はセンダ１２のユーザーに対し、ｅＰＯ２０によるプロセス処理後にこのｅレターをここで説明する任意の方法で入手し、ハードコピーに印刷し、封筒にシールし、レシーバ１４に物理的に配送するオプションを提供し得る。
図３Ａ〜Ｃ、図４Ａ、図４Ｂ、図６及び図７に示され又はこれらの図を参照して説明されるように、ｅＰＯ２０（ｅポストオフィスの略称）の模範的ソフトウェア２４、２４’はｅポストオフィスソフトウェア２４、２４’の運用に際してオルタナティブにおいてに実施され得る。ｅＰＯソフトウェア２４、２４’のプロセス処理ステップの代表的シーケンス及び、運用上の現在好ましいシステム構造は以下に説明され且つ図２０Ａ及び図２０Ｂに示されるようなものである。
・特定の処理がセンダ１２からレシーバ１４への、ｅレター送信、プロセス処理、配送に関して先に説明したようなｅレターの送信、プロセス処理及び配送に依存するもの。

オルタナティブにおけるシステム構造及びｅＰＯ２０位置でｅレターをプロセス処理するための操作の代表的なものを図２０Ａ及び図２０Ｂを参照して以下に説明するが、それらは一般に、センダ１２からレシーバ１４にｅレターを送信するための広汎なオルタナティブに関わるものであり、また、ｅレターメッセージそのものを送信する、また、ｅポスタルプロセス処理データの、全てでなければその殆どをセンダ１２からｅＰＯ２０を介してレシーバ１４に送信する、好ましい代表的な構成に特に関わるものでもある。

送信及び配送のオルタナティブの全て（ｅＰＯ介する又は介さないものを含む）は、以下の構成の幾つか又は全てを使用して処理できる。
・センダ１２位置でｅレターをプロセス処理するための、上述した様々なオルタナティブの構成。
・ｅＰＯ２０位置でｅレターをプロセス処理するための、以下に説明する様々なオルタナティブの構成。
・レシーバ１４がｅレターを受け取ってプロセス処理するための、以下に説明する様々なオルタナティブの構成。
・ダイレクト通信のための上述した様々なオルタナティブの構成。
・ダイレクト通信を介してのセンダ１２及びレシーバ１４へのｅＰＯ２０による通信情報、又は、センダ１２がｅレターをレシーバ１４に送信するために使用するべきオルタナティブに関するその他のｅポスタル通信。
ｅレターをｅＰＯ２０に通さないオルタナティブでは、図３Ａ〜Ｃ、図４Ａ、図４Ｂ、図６及び図７に示され又はこれらの図を参照して説明されるような、ｅＰＯ２０の模範的ソフトウェア２４、２４’の運用プロセスの、全てでなければ殆どが尚、実施される。然し乍ら、これらのオルタナティブではｅＰＯ２０は、ｅレターがｅＰＯ２０を介する場合のｅＰＯ２０による全プロセス処理を管理及び実行するのではなくむしろ、そうしたプロセス処理の全ての管理を継続しつつも、その幾つかの処理を、センダ１２及びレシーバ１４及び又は図８に示すｅポスタルネットワークソフトウェア２８に委ねる。ｅＰＯ２０は、そのように委任したプロセス処理を管理し、その結果を、先に議論したようなｅポスタルシステムのダイレクト通信を介して、センダ１２、レシーバ１４、ｅポスタルネットワークソフトウェア２８と共有する。

ｅＰＯ２０は、代表的なｅＰＯソフトウェア２４、２４’を使用してｅレターをプロセス処理する。図２０Ａ及び図２０Ｂに示され且つ以下に説明する好ましいステップシーケンスはその代表例であって、センダ１２からレシーバ１４を送信及び配送するために使用する方法、ｅレターに関するｅＰＯ２０の実施するプロセス処理量、センダ１２が選択したサービスによって変更され得る。
ステップＥＰ１で、ｅＰＯ２０は送られてくるｅレターを先ずこれがｅレターであることを確認することからプロセス処理を開始する。もし、ｅＰＯ２０のプロセス処理上の任意のステージでのプロセス処理データが予想外の又は異なる場合は、ｅメールのプロセス処理が拒否され、特殊状況に該当するものとして取り扱われる。ｅＰＯ２０は、上述したセンダソフトウェア２２で説明した、通常好ましい構成を使用して動作され、ｅレター内のｅポスタルプロセス処理データ、即ちＳＭＴＰカスタムヘッダ（図１９）内のデータを探す。次いで、ｅＰＯはステップＥＰ２で、好ましいプロセス処理シーケンスを開始し、ステップＥＰ３で認証及び確認を行い、ステップＥＰ４で全体的なプロセス処理を実行する。

ステップＥＰ５で、ｅＰＯ２０はカスタムヘッダの部分１を解析する。図１９を再度参照されたい。ｅＰＯ２０はステップＥＰ６で、カスタムヘッダの部分２を復号化するためにステップＥＰ７で使用する暗号化用対称キーをｅＰＯ２０に示すセンダ１２のＩＤナンバーを部分１内から探し出す。ｅレターのプロセス処理に際してセンダ１２が使用する暗号化用対称キーの生成及び通信はセンダソフトウェア２２に関連して説明した通りのものである。
ステップＥＰ８で、ｅポスタルシステム１０は、説明したように暗号化用対称キーを用いて部分２を復号化するためにｅＰＯ２０を好ましく使用するのに加え、ステップＥＰ９で、メッセージ本文のＭＤＣのハッシュを記憶し、ステップＥＰ１０で、部分３を復号化するために使用する暗号化用対称キーを取得する。
上述した各ステップは本来、図２０の動作ダイヤグラムの“識別（ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）”と表示される部分に反映されるようなｅレターとして、ｅメールを識別する。この識別に際しては、先ず第１には、ｅポスタルのｅレターのカスタムヘッダのように作用する少なくとも２つの部分を持つカスタムヘッダが存在することが、第２には、ｅポスタルアカウントを持つセンダ１２として認識されるセンダＩＤナンバーが存在することが、そして第３には、ｅＰＯに、センダＩＤナンバーと合致する、部分２を復号化できる暗号化用対称キーが存在することが識別される。

ステップＥＰ１１で、ｅポスタルシステム１０は部分２から得た暗号化用対称キーを使用して部分３を復号化するためにｅＰＯ２０を好ましく使用する。
ステップＥＰ１２で、ｅＰＯ２０はセンダ１２が選択したｅポスタルサービスを識別する。ｅポスタルサービスの幾つかにおけるプロセス処理に関しては以下に特に説明しないが、ｅＰＯ２０は、必要であればそうしたサービスを実施するように改変し得るものとする。
ステップＥＰ１３で、ｅＰＯ２０は暗号化サービスがセンダ１２が選択したｅポスタルサービスである場合は、カスタムヘッダの部分３に記憶された暗号化用対称キーを使用してｅレターメッセージを復号化する。

本発明では、ｅＰＯ２０でのプロセス処理中は、暗号化されたｅレターメッセージ、つまりｅレターを復号化しないオルタナティブが意図される。このオルタナティブでは、ｅレターが復号化されないのでｅＰＯ２０のプロセス処理中のｅレターの安全性やプライバシー保護性は高いと考えられるがそれは誤りである。復号化、プレーンテキストのプロセス処理、再暗号化は全て“ブラックボックス”環境内で行われ、この環境には、ｅレターがプレーンテキストでプロセス処理されている間でも、ｅポスタルシステム位置の誰もアクセスすることができない。また、ｅＰＯでプロセス処理される間、暗号化されたｅレターを復号化しない点には重大な不利益がある。そうした不利益には、技術上及びコンテンツリスク上のスクリーニングを実施するために復号化しなければならない点や、メッセージ本文のＭＤＣハッシュが、ｅＰＯ２０がメッセージを認証しセンダ１２を確認できるようにこのメッセージ本文が復号化されていないと、良好に検証されない点が含まれる。従って、ｅポスタルシステム１０が、送られてくる全ての暗号化されたｅレターを復号化して技術上及びコンテンツ上のリスクに関する適切なスクリーニングを実行し得、また、メッセージ本文のＭＤＣハッシュが正しく検証され得るようにすることが好ましい。
ｅＰＯ２０はステップＥＰ１４でｅレターに対する技術上及びコンテンツリスク上のスクリーニングを実施する。
ステップＥＰ１５で、ｅＰＯ２０はメッセージ本文のＭＤＣハッシュを生成し、ステップ６でこのＭＤＣハッシュを、カスタムヘッダの部分２に記憶したＭＤＣハッシュと比較し、ステップＥＰ１７で、比較の結果両ＭＤＣッシュが同じである場合はこのｅレターの内容はセンダ１２が送信したものであることが検証される。

ステップＥＰ１８で、ｅＰＯ２０はセンダ１２を確認する。この確認テクニックには数多くのものがあるが、その１つは、センダ１２だけに結びつく様々なデータのみをｅＰＯに保存し、センダ１２がそれらのデータをｅＰＯ２０に転送し、このデータが転送中に暗号化によって保護されている時はこのデータによってｅＰＯ２０位置でセンダ１２が確認される。現在好ましい形態は、ｅポスタルシステム１０はメッセージ検証のみならず、センダ１２を確認するためにもＭＤＣを使用するものである。ＭＤＣがセンダ１２を確認するのは、センダ１２のみが、カスタムヘッダの部分１内のセンダ１２のＩＤナンバーを知り得るからであり、このＩＤナンバーが、（１）ｅＰＯ２０に対して、センダ１２以外にはこのｅＰＯ２０のみが持ち得る暗号化用対称キーを指定し、（２）メッセージ本文のＭＤＣハッシュを検証するからである。加えて、カスタムヘッダの部分３内のセンダ１２のＩＤナンバーには、復号化又はハッシュ化された場合に、ｅＰＯ２０位置に記憶された相当するセンダ１２のＩＤナンバーと合致する、少なくとも２つの異なるセットが存在する。これら２つのＩＤナンバーセットによる解析により、ステップＥＰ１９において２つのセンダ１２確認方法が提供される。上述したように、部分２及び部分３で使用する暗号化用対称キーのみならず、部分２及び３におけるデータシーケンスをも定期的に変更することで、ｅポスタルプロセス処理データの安全性を改善するｅポスタルシステム１０も意図される。

ステップＥＰ２０で、ｅＰＯ２０はレシーバソフトウェア２６を持たないレシーバ用の、プロセス処理上法及びレシーバ用のメッセージを含む任意の管理上のメッセージをｅレター内に配置する。
ｅＰＯ２０は、ステップＥＰ２１で、任意の管理上のメッセージが追加されたことでＭＤＣハッシュが変更された場合は、新規のＭＤＣハッシュを生成する。
ステップＥＰ２２で、ｅＰＯ２０はセンダ１２がｅポスタルサービスで暗号化を選択していた場合はｅレターメッセージを再暗号化する。あるオルタナティブではメッセージ本文を、元のメッセージ本文を暗号化するために使用した、センダ１２からのｅレターのカスタムヘッダの部分３に保存した暗号化用対称キーを使用して再暗号化するが、別のオルタナティブでは新規の暗号化用対称キーが使用される。ｅＰＯ２０は元の同じ暗号化用対称キーを使用することが好ましい。なぜなら、同じキーを使用しても暗号の安全性はそれほど損なわれず、新規のキーを発生させるよりも時間が短くて済むからである。

ステップＥＰ２３で、ｅＰＯ２０はセンダ１２が選択したｅポスタルサービスを識別し、ｅレターに必要なｅポスタルクレジットを計算し、ステップＥＰ２５で、センダ１２のアカウントのクレジット残高をそれに合わせて調整する。センダソフトウェア２２を参照して先に議論したように、ｅＰＯ２０は、全てのｅポスタルアカウントに対し、公式のクレジットバンクレコードを維持することが好ましい。もし十分なクレジットが入手できない場合は、ｅＰＯ２０は、ステップＥＰ２６で、ｅレターのプロセス処理を進めつつ、センダ１２位置で、ユーザーにｅポスタルクレジットの追加購入を要求するプロセスを開始する。そうした状況では、企業ポリシーが、センダ１２に対する未購入クレジットの延長を決定する。
本発明においては、ｅポスタルサービスの価格構成と、サービスに対する支払い方法のオルタナティブが意図される。価格構成のオルタナティブの主なものには、定期購読料、使用上選択したサービスに関わらずｅレターの値段が同じもの、使用上選択したサービスによってｅレター毎の値段を段階的に変えるもの、が含まれる。ステップＥＰ２４では、各ｅレター用に使用上選択したｅポスタルサービスに対して段階的な価格構成とすることが現在好ましい。この基本設定は、カスタマーのタイプや企業環境によって変更できることは言うまでもない。支払い方法についてのオルタナティブには、提供されるサービスに対してユーザーに定期的に課金するもの、サービスを使用することで使い切れる所定量のｅポスタルクレジットに対して色々な手段によって前払いさせるもの、が含まれる。ｅポスタルシステム１０は、サービスを使用することで使い切れる所定量のｅポスタルクレジットに対して前払いさせる支払い方法を使用することが好ましい。、この方策として幅広く受け入れられている経済的モデルには、郵便切手帳を購入し、メールルームの郵便料金メーター内にクレジットを補充するものがある。

ステップＥＰ２７で、ｅＰＯ２０は、部分３内に保存した、センダ１２位置のクライアントバージョンのようなデータを使用して管理上のチェックを実施し、ステップＥＰ２８で、センダ１２のクライアントに対する通信を準備する。
次いで、ステップＥＰ２８で、ｅＰＯ２０は以下に説明され且つ図２０Ａ及び図２０Ｂに示すような、プロセス処理ステップの代表的なｅＰＯシーケンスを用いて、発送するｅレターのプロセス処理を開始する。ｅＰＯ２０は、発送されるｅレターに十分なｅポスタルデータ及び指示が含まれるようにｅレターを準備し、ｅレターがレシーバＩＳＰ１９を介してレシーバ１４に配送され、レシーバ１４がｅレターのプロセス処理の受け取り方法や終了方法が分かるように、発送するｅレターをプロセス処理する。発送するｅレターのプロセス処理数に関しては色々の形態のオルタナティブが存在する。

ステップＥＰ３０では、ｅポスタルシステム１０は、センダ１２のプロセス処理の場合にそうであるように、また同様の理由から、カスタムヘッダを使用することが好ましい。カスタムヘッダ数はこの場合も重要ではないが、ｅＰＯ２０からレシーバ１４に送るｅレターに対しては、ｅポスタルシステム１０は２つのヘッダ又は、１つのヘッダに２つの部分を持つものであることが好ましい。以下の議論は２つヘッダを参照してなされる。ヘッダを２つとする基本設定は、レシーバ１４位置のコンテンツ又はプロセス処理上必要であれば、ヘッダがそれ以上の数の部分を持つように変更され得る。センダ１２の場合にそうであるように、仮にレシーバ１４位置の特定のｅメールアプリケーションがカスタムヘッダの使用を許可せず、データをｅレターの何処か他の場所に置くことを要求する場合、又はこの方法でｅポスタルのプロセス処理データを配送することが許可されない場合は、別の場所又は別の配送構成が使用される。ｅＰＯ２０はレシーバ１４のオペレーティングシステム及びｅメールアプリケーションを認識しており、従ってそうした制約を知っている。

ｅＰＯ２０は、カスタムヘッダを、レシーバ１４位置でｅレターをプロセス処理するためのデータのみならず、ｅレターを検証及び確認するためのデータをも含むように調製する。検証は、センダ１２の場合にそうであるように、ｅレターメッセージがｅＰＯ２０からレシーバ１４に送られる間に変化していないことを示すものであり、確認は、レシーバ１４に送られるｅレターが実際にｅＰＯ２０からのものであり、従って、本来、ｅＰＯ２０以前にセンダ１２から送られたものであることを示すものである。センダ１２のプロセス処理の場合にそうであるように、レシーバ１４は、送られてくるｅレターを様々なその他のシーケンスでプロセス処理することができる。これは、カスタムヘッダ内のデータが多くの異なる方法で構成され得ることを意味している。然し乍ら、センダ１２のプロセス処理におけるように、レシーバ１４に送られてくるｅレターには多数のレシーバｅメールアドレスが含まれ得、他方、センダ１２からｅＰＯ２０に送られるｅレターにはｅＰＯ２０のアドレスのみが含まれる。従って、レシーバ１４位置でのプロセス処理シーケンスに関しては、レシーバ１４がｅレター内で先ず自分を確認し、次いでｅレターを検証及び確認してから残りのプロセス処理を実施することが好ましい。これは、識別、検証又は確認のどれかを実施できない場合はそうしたｅメールはｅレターでは無いと考えられるので、レシーバ１４はｅメールをプロセス処理しないことが望ましいからである。従って、カスタムヘッダ内に含まれる、レシーバー自身をｅレターの中で確認させるためのデータを、任意のその他のデータよりも先に取得できることが好ましく、次いで、プロセス処理用のデータよりも先に又は少なくとも同時に、カスタムヘッダから検証及び確認用のデータを取得できることが好ましい。

図２１には代表的なカスタムヘッダの構造が示され、２つのカスタムヘッダ１及び２を含んでいる。これらの２つのカスタムヘッダは、オルタナティブでは２つの部分を持つ１つのカスタムヘッダとして取り扱われ得、又は３つ以上のカスタムヘッダに解析（ｐａｒｓｅ）され得る。ｅポスタルシステム１０は２つのカスタムヘッダを使用することが好ましい。更には、２つのカスタムヘッダの物理的シーケンスは重要ではない。然し乍ら、２つのカスタムヘッダは使用する論理シーケンス順のものとすべきである。
カスタムヘッダ１は、ｅレターの多数のレシーバ（ｅＰＯ２０位置のユーザーアカウントに関わるｅメールアドレスを持つレシーバ１４や、ユーザーアカウントに関係のないｅメールアドレスを持つレシーバーを含む）を最良に収受する構造を有する。オルタナティブでは、カスタムヘッダ及びｅレター内のその他形式のデータ構造が使用され、ｅＰＯ２０から各レシーバに対して個別にｅレターが送られるように、多数のレシーバを収受する。

図２１には現在好ましいｅポスタルシステム１０の構成が示される。この構成によれば、ｅＰＯ２０はセンダ１２が送信した各ｅレターに対して１通のｅレターを受信及び送信することが可能であり、かくして、運用上及び安全上のアドバンテージが提供される。
ステップＥＰ３１で、カスタムヘッダ２は、図２１に示すようにｅポスタルプロセス処理データを持つように構成される。そうしたデータには以下に挙げるものが含まれる。即ち、
・本来センダ１２により生成され、ｅレターを識別し、また、ｅレターに関する将来的なトランザクションをプロセス処理及び追跡するために使用する独自セットのナンバー。
・ｅレター検証用のＭＤＣ。このＭＤＣはレシーバへの伝送時には変化されない。ｅレターがｅＰＯ２０からのものであり、従ってセンダ１２からのものであることをレシーバが確認するための数多くの方法の１つでもある。
・ＩＤナンバーやｅメールアドレスと言った、センダ１２、ｅＰＯ２０、レシーバに関するデータ。“Ｔｏ”、“ｃｃ”、“ｂｃｃ”の情報はセンダ１２からのｅレターのカスタムヘッダの部分２から削除され、カスタムヘッダ２内にそのハッシュ値と共に取り込まれる。“Ｆｒｏｍ”、“Ｒｅｐｌｙ−ｔｏ”情報もカスタムヘッダ２内にそのハッシュ値と共に配置される。このデータのハッシュ値は、ｅレターの安全性のチェック及びｅＰＯ２０やセンダ１２を確認するための追加方法の使用を可能とする。
・センダ１２が選択したｅポスタルサービスを識別するデータ。
・暗号化サービスが選択された場合にｅレターメッセージ本文を復号化するための復号化キー。ｅポスタルシステム１０と、ｅＰＯ２０とは、センダ１２が送信したいーレターのカスタムヘッダの部分３に保存した暗号化用対称キーを再利用することが好ましい。
次いで、カスタムヘッダ２は、ステップＥＰ３２で、ｅＰＯ２０位置で生成された暗号化用対称キーを使用して暗号化される。ｅポスタルシステム１０は暗号化用対称キーを使用することが好ましい。

カスタムヘッダ１は、ステップＥＰ３３で、図２１に示す如くｅポスタルプロセス処理用データを持つように構成される。カスタムヘッダ１は一連のナンバーペアから構成され、１つのナンバーペアが、各レシーバの、ｅポスタルアカウントとの関連性の有無に関わらずｅメールアドレスに対応する。ステップＥＰ３４ではナンバーペアは、レシーバのＩＤナンバーと、復号化キーとから構成される。
ｅポスタルアカウントとは無関係のレシーバメールアドレスに対しては、ｅＰＯ２０はそのレシーバのメールアドレスの記録を生成し、この記録を、カスタムヘッダ１で使用するレシーバＩＤナンバーに与える。この記録により、ｅＰＯ２０はこのレシーバｅメールアドレスに対するｅレター及び任意の将来的なｅレター及びその他のｅポスタルシステム１０の、このレシーバに関するアクションを追跡することが可能になる。
カスタムヘッダ１に保存した復号化キーは、レシーバ１４がカスタムヘッダ２を復号化するために使用する。この復号化キーは、ｅＰＯ２０が発生させ（先に議論したようにして）、カスタムヘッダ２を暗号化するために使用したものと同じであることが好ましい。各レシーバ用の暗号化されたカスタムヘッダ２は同じものであることから、各レシーバ用の復号化キーは同じものである。

レシーバＩＤナンバーは、このレシーバＩＤナンバーがレシーバ１４一にも保存されたものであることから、レシーバ１４に所属するものとしてレシーバ１４が認識するところのものである。ｅＰＯ位置では、アカウントを持たないレシーバはＩＤナンバーを認識できない。実際、そうしたレシーバは、レシーバソフトウェア２６を持たないので、カスタムヘッダ又はｅレターの処理方法が分からない。この状況は、レシーバソフトウェア２６に関連して以下に詳しく議論される。

ｅＰＯ２０は、次いで、ステップＥＰ３５で、カスタムヘッダ１内の各ナンバーペアに対し、暗号化用対称キーを暗号化する。カスタムヘッダ１内の各ナンバーペアに対しては、暗号化用対称キーを、ランダムに異なるノイズと混合させて暗号化の安全性を向上させることが好ましい。また、ｅＰＯ２０は、異なる暗号化用対称キーを使用して各レシーバのナンバーペアの暗号化用対称キーを暗号化することも好ましい。各レシーバＩＤナンバー用に使用する暗号化用対称キーは、ｅＰＯ２０の記録にあるレシーバＩＤナンバーと一致するものである（ｅレターがレシーバ１４に到達し、レシーバ１４がカスタムヘッダ１内に、レシーバ自身のそうしたナンバーの記録リスト中のレシーバＩＤナンバーと一致するレシーバＩＤナンバーを発見した場合、レシーバ１４はレシーバＩＤナンバーと共に保存した復号化キーを使用してカスタムヘッダ１内の暗号化用対称キーを復号化する）。

次いでステップＥＰ３６で、ｅＰＯ２０はカスタムヘッダ１及び２をｅレター内に配置する。図２１には示されないが、カスタムヘッダ１及び２内の任意のデータには、ｅＰＯ２０が何らかの他の方法で知り得る場合を除き、データサイズの情報が含まれる。また、図２１には示されないが、暗号化技術の好ましいオルタナティブに関する先の説明を参照するに、ｅポスタルシステム１０は、カスタムヘッダ２内のデータ内に、これらのデータを暗号化する前にランダムノイズ（先にカスタムヘッダ１に関して言及したような）を付加して安全性を向上させることが好ましい。また、図２１には示されないが、カスタムヘッダ２内のデータの構造は暗号化の安全性を更に高めるように変更される。ダイレクト通信の説明で述べたように、そしてカスタムヘッダ内に暗号化されたデータが存在することにより、カスタムヘッダは、伝送され得るように１６進法コード又はその他類似の実行コードで書き換えられる。

この時点でそれがまだ済んでいない場合は、ｅＰＯ２０は、ステップＥＰ３７で、センダ１２からのｅレターのカスタムヘッダの部分３からの本来の“Ｔｏ”、“ｃｃ”、“ｂｃｃ”の情報をｅレターの”Ｔｏ”、“ｃｃ”、“ｂｃｃ”のヘッダにコピーする。ｅＰＯ２０は、それがまだ済んでいない場合は、ステップＥＰ３８で、センダ１２がｅレターに書き込んだカスタムヘッダをｅレターから削除する。
次いで、本発明の現在好ましい形態では、ステップＥＰ３９で、ｅＰＯ２０は発送するｅレターメッセージを送信し、センダ１２からのｅレターを、レシーバ１４がｅレターを受け取り、識別し、検証し、確認し、プロセス処理を終了するために必要な全てのｅポスタルプロセス処理データと共に、レシーバ１４に送信し且つ配送させる。
最後に、ｅＰＯ２０はステップ４０で、プロセス処理及び配送のこのステージでのｅレターに関する必要な全データベースの記録及び保持を完了する。

詳しくは、図４Ａに開示され又はこれらの図を参照して開示されるようなレシーバ１４の模範的ソフトウェア２６の機能には以下のものが含まれる。
・全てのｅレターをレシーバ１４が受け取ったものとして識別。
・デフォルトで、又はレシーバ１４のその他のカスタマイズされた指令、例えば特定のｅポスタル受信箱に入れるなどの指令により、ｅレターを仕分けしてその他全てのｅメールから分離。
・受け取った全てのｅレターにｅポスタルの特別のマークやプライオリティ表示体を付けてそれらのｅレターがその他全てのｅメールから見分けられるようにする。
・レシーバ１４からの指示があった場合に、既知及び未知のセンダ内の如きへの非ｅポスタルｅメールのカスタマイズされた特定仕分けを実施。
・レシーバ１４からの指示があった場合に、その他のｅメールを、例えば全て“非ｅポスタル及び未知のセンダ”メールとして管理及び削除。
・センダ１２位置で選択された全てのｅポスタルサービスの探索についてレシーバ１４を支援。
・要求に応じてｅレターを復号化。
・レシーバ１４からの指示があった場合に、ｅレター暗号化のリポジトリをコンテンツ証明のために維持。
・センダ１２の、自己認証されたユーザーを識別。
・開封されたｅレターを識別。
・ｅレター開封用のレシーバ１４のクレジットを管理。
・ｅＰＯ２０にｅレターの受け取り及び開封通知を送信。
・レシーバのユーザを認証しこの認証をｅＰＯ２０に送信。
・レシーバ１４の、センダ１２のプリペイドリプライｅレターへの応答を支援。
・レシーバ１４のアカウントカレントを保持するｅＰＯ２０との通信及びｅＰＯ２０と連係しての様々な管理上のタスクの実行を支援。
・レシーバ１４のｅメール及びブラウザアプリケーションとのシームレスな作業。

図４Ａに開示され又はこれらの図を参照して開示されるような、ｅポスタルアカウント及びソフトウェア２６を持たないレシーバ１４でも、図３及び図４Ｂに示されるように、ｅメールを受け取れ且つｅＰＯ２０を介してプロセス処理したｅレターにアクセスすることができる。ｅポスタルアカウント及びソフトウェアを持たないレシーバがセンダ１２から受け取れるｅメールに関しては、技術上及びコンテンツ上のリスクに対するスクリーニング以外にｅポスタルシステムから得られる利益は限られたものである。例えば、アカウントを持たないそうしたレシーバは、ｅメールが実際にｅＰＯによってプロセス処理されたものであるか、又はセンダ１２からのものであるかを検証できない。従って、ｅメールには、通常のｅメールの如く、ｅポスタルシステム１０に関連する安全上の利益が無い。然し乍ら、このｅメールはそうしたアカウントを持たないレシーバに、ｅメールがセンダ１２からのものであることやｅＰＯ２０がプロセス処理したものであることを検証するためのオプションを提供し得る。ｅメールは、無アカウントレシーバに、レシーバがセンダ１２からのｅレターをｅＰＯウィンドウ又はウェブサイト２０位置で閲覧できるようにするコードを提供し得る。これらのｅレターは、技術上及びコンテンツ上のスクリーニング、重要度及び優先度の表示体、センダ１２の端末の確認、センダ１２のユーザーの認証、暗号化やセンダ１２へのプリペイドリプライ、のようなｅポスタルシステムの多くの機能や利益を有するが、レシーバ自身のｅメールアプリケーションでは受け取れないこと及びそうしたｅメールアプリケーションには存在しないこと、に関する重要な制限もある。

本発明には、模範的なレシーバソフトトウェア２６（図４Ａに開示され又はこれらの図を参照して開示されるような）及び、レシーバの好ましいプロセス処理ステップのシーケンス（以下に説明され且つ図２２Ａ及び図２２Ｂに示される）に関する運用上の色々のオルタナティブが含まれる。
こうしたレシーバ１４のオルタナティブの構成は、ｅレターの送信、プロセス処理、配送のためのオルタナティブに関して先に説明したような、センダ１２からレシーバ１４へのｅレターの送信、プロセス処理、配送のために選択する構成次第のものである。図２２Ａ及び図２２Ｂに示し且つ以下に説明する、レシーバ１４位置でのｅレターのプロセス処理に関するオルタナティブは、一般に、センダ１２からレシーバ１４にｅレターを送信するために考えられる全てのオルタナティブに関係するものである。更には、ｅレターメッセージ自体及び、センダ１２からのｅポスタルプロセス処理データの、全てでなければ殆どがｅＰＯ２０を介してレシーバ１４に送信される場合に通常好ましい構成が説明される。

レシーバ１４はレシーバソフトウェア２６を使用してｅレターを受け取り且つプロセス処理する。ステップＲＰ１のレシーバ１４シーケンス（図２２Ａ及び図２２Ｂに示し且つ以下に説明する）は代表的なものであって、例えば、センダ１２からレシーバ１４にｅレターを送信及び配送するために使用したフォーム、ｅＰＯ２０がｅレターに対して行なうプロセス処理量、センダ１２が選択したサービス、レシーバ１４位置でのオペレーティングシステムやｅメールアプリケーションの性質、によって変更可能である。
現在好ましいｅポスタルシステム１０では、レシーバ１４位置でのプロセス処理の３つの主要ステップは、識別ステップＲＰ２と、検証及び確認ステップＲＰ３と、その他の一般的なプロセス処理ステップＲＰ４とである。プロセス処理の任意のステージにおいて、予測するプロセス処理データが現れない又はデータが違う場合は、ｅメールはそれ以降のプロセス処理を拒否され、特殊状況ステップＲＰ１０に該当するものとして取り扱われる。

ｅメールが、ＰＯＰ３のような特定のＴＣＰを介して、レシーバ１４位置のｅメールアプリケーションに届くと、識別ステップＲＰ２が開始される。然し乍ら、レシーバ１４がそうしたｅメールアプリケーションではなくむしろ、ｅメール用のウェブブラウザのような別のソフトウェアアプリケーションを使用している場合は、ｅポスタルレシーバソフトウェア２６は、先に説明した（ｅポスタルソフトウェアのインストール及び好ましい構成のアクティベーションに関して説明したような）幾分異なるプロセスではあっても、そうしたソフトウェアアプリケーションと共に動作する。詳しくは、レシーバ１４が、新規のｅメールがどのようにして、どこから、いつ届いたかを知るのは、レシーバ１４のオペレーティングシステム及びｅメールアプリケーション次第のものとなる。到達時間については、ｅメールがｅメールアプリケーションのメールフォルダに入る前後であり得る。例えば、レシーバ１４がｅメールアプリケーションのメールフォルダに入った後に新規ｅメールの到達を知る場合は、レシーバ１４は新規受信ｅメール用のｅメールアプリケーションメールフォルダをスクリーニングする。

好ましい形態では、レシーバ１４が新規ｅメールを発見した場合、レシーバ１４は先ず、ステップＲＰ１５で、ｅメールの“Ｆｒｏｍ”のアドレスが、ｅＰＯ２０のために認証された“Ｆｒｏｍ”のアドレスとして既知のものであるかを決定することで、受信したｅメールがｅレターであるかどうかチェックする。次ぎに、レシーバ１４は、ｅＰＯソフトウェア２４、２４’によりプロセス処理される発送ｅレターについてのセクションで説明した好ましい方法の結果として、ステップＲＰ６で、ｅレター内にｅポスタルプロセス処理データ、つまり、ＳＭＴＰカスタムヘッダ１があるかどうかを探す。ＳＭＴＰカスタムヘッダ１があった場合はこのｅメールはそれ以降のプロセス処理のためのｅレターであると考えられる。

レシーバ１４は、ステップＲＰ７で、ｅメールの“ＤｅｌｉｖｅｒｅｄＴｏ”アドレスが“Ｏｒｉｇｉｎａｌ−Ｔｏ”及び“Ｔｏ”、“ｃｃ”、“ｂｃｃ”のデータフィールドの中で一致するかどうかチェックし、一致しない場合は、ステップＲＰ８で、エリアス（別名）アドレスである可能性をチェックする。ｅポスタルシステム１０上、エリアスアドレスの可能性がある時は、レシーバ１４はｅＰＯ２０に対し直接通信を介して、エリアスであることを示すデータを与える。ｅＰＯ２０は、ｅレターのプロセス処理を続けるための正しいレシーバＩＤナンバーや復号化キーのような更に他の指示をダイレクト通信によって応答する。

次いで、ステップＲＰ１１で、レシーバ１４は、レシーバ１４のデータレコード内の、ｅメール配送先アドレスと対をなすレシーバＩＤナンバーを探し出し、ステップＲＰ１２で、このＩＤナンバーをカスタムヘッダ１内の各レシーバＩＤナンバーと比較し、関連する暗号化された暗号化用対称キーを見つける。先に議論したように、レシーバ１４は、ステップＲＰ１３で、レシーバ１４のデータレコード内を探し、ステップＲＰ１４で、カスタムヘッダ１内の、一致するレシーバＩＤナンバーと関連する復号化対称キーを探し出す。この復号化用対称キーを使用して、レシーバ１４はステップＲＰ１５で、カスタムヘッダ１に保存され一致するレシーバＩＤナンバーとペア化された暗号化された対称キーを復号化する。レシーバ１４はまた、ｅポスタルシステム１０の好ましいステップとしてｅＰＯ２０位置で暗号化される前に安全性向上のために付加されたランダムノイズを対称キーから除去する。

暗号化に関する先の説明と同じように、ステップＲＰ１６で、レシーバ１４はカスタムヘッダ１からの復号化用対称キーを使用してカスタムヘッダ２を復号化してこのカスタムヘッダ２内の全てのデータ、例えばセンダ１２が選択したｅポスタルサービスのリストの如きを入手して使用できるようにする。
ステップＲＰ１７で、レシーバ１４はセンダ１２が選択したｅポスタルサービスを識別する。幾つかのｅポスタルサービスのプロセス処理については以下に詳しく説明しないが、ｅＰＯ２０はレシーバ１４が当業者に知られた技術を使用してプロセス処理する上での必要に応じてそれらのサービスを実施する。
センダ１２がｅポスタルの暗号化サービスを選択していた場合は、レシーバはステップＲＰ８で、カスタムヘッダ２内に保存された対称キーを使用してｅレターのメッセージ本文を復号化する。
ステップＲＰ１９で、レシーバ１４はｅレターのメッセージ本文のＭＤＣハッシュを生成し、ステップＲＰ２０でこれをカスタムヘッダ２内に保存したメッセージ本文のＭＤＣハッシュと比較する。２つのＭＤＣハッシュが一致すれば、ステップＲＰ２１で、メッセージはｅＰＯ２０からレシーバ１４への伝達過程で変化していないことが検証される。

またこの時点で、レシーバ１４は、ｅレターがレシーバ１４に届いたことを、センダであるｅＰＯ２０に確認できる。センダ１２のｅレターをｅＰＯ２０で確認する場合にそうであるように、この機能を実施するための数多くのオルタナティブが存在する。レシーバ１４位置には、ｅＰＯ２０のみに結びつけられた様々なデータが保存され得、そうしたデータがｅＰＯ２０からレシーバ１４に伝送され、且つ伝送中は暗号化によって保護される場合は、それらのデータがレシーバ１４位置でｅＰＯを確認する。現在好ましい構成には、ＭＤＣをメッセージ検証用のみならず、ステップＲＰ２１でのｅＰＯ２０の検証用としても使用するものが含まれる。レシーバ１４が生成したメッセージ本文のＭＤＣハッシュと、カスタムヘッダ２に保存した復号化されたＭＤＣハッシュとが一致するとｅＰＯ２０が確認され、更にメッセージが検証される。これは、ｅＰＯ２０だけが、カスタムヘッダ１内の、レシーバ１４のみが（ｅＰＯ２０の他には）持つ対称キーに対してレシーバを指定するレシーバＩＤナンバーを知り得るからである。加えて、ｅポスタルシステム１０の好ましい形態では、カスタムヘッダ２内にはその他任意のｅＰＯＩＤナンバーが存在し得るが、それらは、復号化又はハッシュ化された場合に、レシーバ１４に保存した相当するｅＰＯ２０ＩＤナンバーと合致するものである。ｅポスタルシステム１０の基本設定では２つのＩＤナンバーが使用される。ステップＲＰ２２では、これら２つのＩＤナンバーを解析することによる、センダ１２確認用の２つの追加方法が提供される。カスタムヘッダ１及び２と共に使用する対称キーのみならず、カスタムヘッダ内のデータシーケンスと共に使用する対称キーをも定期的に変更し、ｅポスタルプロセス処理用データの安全性を向上させることが好ましい。

図２２を更に参照するに、レシーバ１４位置での一般的なプロセス処理が開始される。
ステップＲＰ２３で、レシーバ１４はカスタムヘッダ２に保存されたオリジナルの“Ｆｒｏｍ”データを使用して、“Ｆｒｏｍ”及び“Ｒｅｐｌｙ−Ｔｏ”情報を更新し、ｅレターをｅポスタルアカウントユーザーに表示する準備を行う。
ステップＲＰ２４で、レシーバ１４はｅＰＯ２０位置でメッセージ本文に付加された管理上のコンテンツをプロセス処理することで、ｅレターを表示させる準備を行う。ｅポスタルの管理上のメッセージは、ステップＲＰ３８で、レシーバソフトウェア２６を持たない誰かに配送される全てのｅレターメッセージ本文の開始部分に配置されていることが好ましい。レシーバ１４ソフトウェアを持たない場合、レシーバのｅメールアプリケーションは、ステップＲＰ３９でｅレターを通常のｅメール受信箱フォルダに入れ、このｅメールをその他のｅメールとは区別しない。ｅポスタルの管理上のメッセージは、以下を含む点で重要である。
・ステップＲＰ４０で、ソフトウェア２６を持たないレシーバに対し、ｅレターがセンダ１２のユーザーに代わってｅＰＯ２０によりこのレシーバに送られたものであると説明する。
・ステップＲＰ４１で、レシーバにｅポスタルのｅレターに関する情報を提供する。
・ステップＲＰ４２で、ソフトウェア２６を持たないレシーバに、ｅレターが暗号化されていた場合に、独自コードの入手方法に関する情報を与える。
・ステップＲＰ４３で、レシーバ１４に、ｅポスタルサービスが法準拠のものであることを保証するための重要情報を提供する。

レシーバのプロセス処理のオルタナティブには、そうした管理上のコンテンツを持たないレシーバ１４や、レシーバソフトウェア２６を持たないレシーバに別個にｅレターを送信することが含まれる。この場合、レシーバソフトウェア２６の有無に関わらず、全てのレシーバに同じ管理上コンテンツが送信され、どのレシーバーでもそうした管理上コンテンツが閲覧できるようにされ、ｅレターがｅＰＯ２０でプロセス処理される間に管理上コンテンツが好ましく付加され、次いで、レシーバ１４が（ソフトウェア２６を持っている）、表示されたｅレターをレシーバ１４のユーザーが閲覧する前にそうしたコンテンツを除去する。ソフトウェア２６を持たないレシーバは管理上コンテンツを削除する方法が無いが、レシーバのユーザーはｅレターが表示された時に管理上のメッセージを読むことはできる。

ステップＲＰ２５で、レシーバ１４は、レシーバ１４のユーザーに表示するための、カスタムヘッダ２内のデータによって定義されるようなその他の管理上のコンテンツをｅレターメッセージの本文に追加する。それらのコンテンツには、レシーバ１４のユーザーのための以下のような情報が含まれる。
・ｅＰＯ位置でｅレターをプロセス処理するための時間及び日付。
・センダ１２の要求に従ってｅレターに適用されたｅポスタルサービス（ｅポスタルのプライオリティクラス表示体、ｅレターの受け取り及び開封の通知、ｅレターを開封するための、レシーバ１４のユーザーへの任意のカスタムインセンティブ、暗号化、センダ１２のユーザーの認証、プリペイドリプライ）。
・ステップＲＰ３７での、ｅレターに適用されプリペイドリプライサービスその他のｅポスタル機能のレシーバ１４による使い方。

こうした情報を提供するためのあるオルタナティブでは、ｅポスタルシステム１０は、レシーバ１４がこれらの情報の受け取り方を選択するためのオプションや基本設定画面を使用できる。そうした情報は、先に説明したような数多くの方法において提供され得、それらの方法には、ｅレターそれ自体又は、レシーバ１４のユーザーのリクエストに応じてポップアップする特別のｅポスタル画面に示されるコンテンツとして提供されるものが含まれる。
ｅレターを表示させる準備におけるステップＲＰ２６で、レシーバ１４は、カスタムヘッダ２内の情報を用いてこのｅレターのメールメッセージのクラスを設定し、センダ１２が選択したｅポスタルのプライオリティクラスの表示体が表示されるようにする。こうした操作を行う各ステップは、レシーバ１４位置のｅメールアプリケーション次第のものである。
この時点で、レシーバ１４がｅポスタルフォルダ内のｅレターを表示させるための十分なプロセス処理が完了される。

ステップＲＰ２７で、レシーバ１４はｅレターをｅポスタルフォルダ内に仕分けする。模範的なレシーバソフトトウェア２６に関するセンダ１２のプロセス処理に関するセクションで先に説明し且つ図４Ａに示したそれと同じように、ｅポスタルフォルダ間でのｅレターの、仕分け、移動、保存に関するオルタナティブが存在する。これらのｅポスタルの受け取り用フォルダは、受け取ったｅレターのコピーを、レシーバ１４がそのｅレターをプロセス処理した後、レシーバ１４の位置で受け取る。ｅポスタルの基本的な受け取り用フォルダはｅポスタル受信箱フォルダである。レシーバ１４がｅポスタルオプションや基本設定画面を使用することで、又はクライアントインストール中にｅＰＯ２０により、又は、ダイレクト通信及びｅＰＯｅレターを介して、その他の特別のｅポスタルフォルダが生成され得る。更には、また先に述べたように、レシーバ１４は、全てのｅレターをｅポスタルフォルダ内に仕分けるのとは無関係に、レシーバ１４のユーザーのオプションとして、センダのｅメールアドレスがレシーバ１４のユーザーのｅメールアドレス帳内のｅメールアドレスと一致しない全てのその他のｅメールを別の１つのフォルダ内に仕分けし、そうしたｅメールの全てを容易に廃棄することができる。
ｅレターがｅポスタルフォルダ内に最初に配置された後のセンダ１２のプロセス処理に関して先に議論したように、ステップＲＰ３０で、ｅレターをその他のフォルダに移動することに関するオルタナティブが存在する。オルタナティブの１つでは、ｅレターをそのフォルダから取り出して任意のその他のフォルダ（非ｅレターフォルダを含む）に移動させ得る。他のオルタナティブでは、ｅレターをその下のフォルダから移動することができない。ｅポスタルフォルダの安全性を保証し、ｅポスタルユーザーによるｅレターの移動及び仕分けの柔軟性を最適化するためには、ｅレターの移動は下記のようなものであることが好ましい。
・ｅレターを任意のその他のｅポスタルフォルダに移動できる。
・ｅレターをｅポスタルフォルダからその他のｅメールフォルダに移動できる。
・ｅポスタルフォルダから取り出されたｅレターを、それが未変更である場合にｅポスタルフォルダ内に戻せる。
・ステップＲＰ３１で、任意の非ｅポスタルｅメールを任意のｅポスタルフォルダ内に移動できない。
・これらの好ましい方法では、ｅポスタルフォルダは、ｅポスタルｅレター及びフォルダに対する安全性の点でリスクのある非ｅポスタルｅメールから守られる。各ｅレターは、ｅポスタルフォルダに戻される前に、ｅレターとして検証及び確認される。
・ｅレターをがｅポスタルフォルダ内に配置された場合に、ステップＲＰ２８で、レシーバ１４に対して、新規のｅレターの到着を、例えば、ポップアップメッセージ又はチャイムを使用して通信し又は通信しない。ｅポスタルのデフォルトではポップアップメッセージが使用されるが、ｅポスタルシステム１０がレシーバ１４のユーザーに対して、ｅポスタルオプション及び基本設定画面を使用するオルタナティブを選択させることが好ましい。

センダ１２がｅポスタル暗号化サービスを選択していた場合は、レシーバ１４はメッセージ本文が読まれないようにｅレターを自分のｅポスタルフォルダに配置する。これにより、“Ｔｏ／ｃｃ／ｂｃｃ”、“Ｆｒｏｍ”、“Ｓｕｂｊｅｃｔ”の情報しか見えなくなる。レシーバのユーザーがステップＲＰ３２で、レシーバ１４がｅレターを読めるプレーンテキストで表示させる前にｅレターを選択すると、レシーバ１４はレシーバ１４のユーザーに対し、識別及び安全上の目的でユーザーパスワードの入力を求める。ユーザーがパスワードを入力すると、レシーバ１４は、ステップＲＰ３３で、暗号化され、読めるようにプレーンテキスト化されたｅレターを表示する。レシーバ１４のみならずセンダ１２は、ｅＰＯ２０に対して、ステップＲＰ３４で、このｅレターだけでなく任意のその他のｅレターをｅＰＯ２０位置のｅレターリポジトリ内に維持するよう要求できる。デフォルトではユーザーが、暗号化されたｅレターを読み取れる状態で見る前にユーザーパスワードの入力を求められる場合であっても、パスワード入力の要求如何に拘わらず、ｅポスタルシステム１０がｅポスタルオプションや基本設定画面の使用を選択できるようにすることが好ましい。オルタナティブとして、ｅポスタルフォルダ内の復号化されたｅレターを表示するものがあるが、ｅポスタルシステム１０が、レシーバ１４（及びセンダ１２）に対し、そうした暗号化されたｅレター用に指定されたｅポスタルフォルダ内の暗号化されたｅレターを保存するためのｅポスタルオプション及び基本設定画面の使用を許可することが好ましい。保存されたこれらの暗号化されたｅレターは、その後、レシーバ１４のユーザーが自分のパスワードを入力することによってレシーバ１４によって開封され得る。

ｅレターの識別、検証及び確認が済むと、ステップＲＰ２９で、レシーバ１４はオンライン状態又はすぐにオンライン状態になれる場合は、先に説明したようにｅポスタルのダイレクト通信を使用してｅＰＯ２０にｅレターがレシーバ１４位置に到着したことを知らせることが好ましい。この、ｅＰＯ２０へのダイレクト通信により、ｅレターがレシーバ１４に配送され、また十分にプロセス処理されたことが知らされる。ｅＰＯ２０は、この情報を記録する。
レシーバ１４のユーザーがこのｅレターを開封すると、ステップＲＰ３６で、レシーバ１４はオンライン状態又はすぐにオンライン状態になれる場合は、先に議論したようなｅポスタルダイレクト通信を使用して、ｅレターが開封されたことをｅＰＯ２０に確認させることが好ましい。センダ１２のユーザーが、ｅレターを開封する一人としてレシーバ１４のユーザーを認証することを要求した場合は、レシーバ１４はステップＲＰ３６で、ｅレターの開封時に認証を実施し、それをダイレクト通信によってｅＰＯ２０に報告し、ｅＰＯ２０は、この情報を記録する。

ｅレターの受け取り及び開封に関する通信については、センダ１２の選択の如何を問わず、レシーバ１４はダイレクト通信を使用してｅＰＯ２０にこれを通知する。センダ１２が受け取り及び開封（ＮＯＲＯ）サービスの通知を選択していた場合は、センダ１２への通知方法のオルタナティブが存在する。それらのオルタナティブには、ｅＰＯ２０又はレシーバの何れかがセンダ１２に通知するものが含まれる。ＮＯＲＯ通信は、もっとりシンプルでしかもより安全な方法として、ｅＰＯ２０がセンダ１２に対して実施することが好ましい。他の方法では、センダ１２は、別個に行われた受け取りと開封の通知を両方受け、又は、ｅレターの開封後にセンダ１２が受け取りの通知と共に開封通知を受ける。ｅＰＯ２０が、センダ１２がこのｅポスタルサービスを選択できるようにすることが構成上好ましい。

また、レシーバ１４のユーザーがｅレターを開封する時、ステップＲＰ３５で、レシーバ１４は好ましくはその開封時点で、ｅＰＯ２０位置でレシーバ１４のユーザアカウントに付加する（レシーバ１４がダイレクト通信を使用してｅレター開封をｅＰＯ２０に通知した後）ところの、開封に対するｅポスタルインセンティブ（ＩＴＯ）クレジットを見積り、この見積りを、ｅポスタルクレジットのレシーバ１４のローカルバンクに追加することが好ましい。レシーバ１４は、センダ１２がこのｅレターのために選択した任意のセンダ１２ＩＴＯのクレジットをもローカルバンクに追加する。
以上で、ｅレターの受け取り及びプロセス処理における、レシーバ１４の代表的ステップシーケンスの説明及びそのオルタナティブ、及びこうしたプロセス処理ステップのために好ましい特定構成の説明を終わる。

図５には本発明の、伝統的な郵便サービスに似ている別の特徴が示される。センダ１２のユーザーは、ｅレターを差し出し、送信するためにｅＰＯ２０に“行き（ｇｏ）”、レシーバ１４のユーザーはｅＰＯ２０に“行って（ｇｏ）”ｅＰＯ２０の“箱”からｅレターを取り出す。この特徴が重要になる状況は、例えば、センダ１２及びレシーバ１４の各ユーザーが、ｅポスタルソフトウェア２２、２６を持つ端末から離れている場合である。この場合、図６及び図７に示すようなウェブブラウザを持つ端末を使用してｅＰＯのウェブサイトに行き、ログインし、ｅレターを送信及び読み取るための各自のアカウント情報及びツールにアクセスし、ｅＰＯ位置に保持させていたｅレターを、あたかも、ｅメール、ブラウザ、ｅポスタルソフトウェアを持つ各自の端末を使用するようにして送り、あるいはそうでなければ取り扱うことができる。

先に説明し且つ図５に示された種々の特徴では、ユーザーは、各自の端末にｅポスタルソフトウェアがインストールされていなくとも、ｅＰＯウェブサイト位置に開設したｅポスタルアカウントを持っている限り、ｅＰＯ２０に“行って”ｅレターを差し出し／送信し、ｅＰＯの“箱”からｅレターを取り出せる。この状況では、やはり先に説明したように、ユーザーは、図６及び図７に示すように、ウェブブラウザを持つ任意の端末を使用してｅＰＯのウェブサイトに行き、ログインし、ｅレターを送信及び読み取るための各自のアカウント情報及びツールにアクセスし、ｅＰＯ位置にユーザー用として保持させていたｅレターを送り、あるいはそうでなければ取り扱える。

先に説明し、図９に示したように、センダ１２及びレシーバ１４は、ＩＳＰを通しての他に、企業イントラネット又は幾つかのその他の組織ネットワーク内からの如くしてｅメールやインターネットアクセスサービスに接続し得る。図８には、こうした非ＩＳＰ接続の企業イントラネットの例が示され、ｅポスタルソフトウェアが各センダ１２の端末だけでなく、企業サーバー位置でも動作するようになっている。企業は、そうしたネットワーク及びサーバーの代表的環境であるが、よく知られるように、多くの企業では異なるプロトコルを使用して動作するサイズや容量の異なるネットワークが使用されている。都合上、ここでは“企業”には、“企業ネットワーク”、“企業イントラネット”、“企業サーバー”なる用語が含まれるものとする。

図８では、センダ１２は、図２Ａ及び図２Ｂに示されるように、ｅポスタルサービスを使用して又は使用せずに各自のｅメールを送信することができる。然し乍ら、センダがｅポスタルサービスを使用する場合のネットワークでは、ネットワークのｅポスタルソフトウェア２８を、センダ１２位置のセンダのｅポスタルソフトウェア及び企業のｅメールサーバー１３と共に動作させれば、ｅポスタルソフトウェアが各センダ１２のコンピューター位置だけにある場合よりも組織全体に対するｅポスタルの運用をずっと良好に管理できる。そうしたシステム構成には、入手可能なｅポスタル機能の管理、企業の合計ｅポスタルクレジットの確認、ｅＰＯ２０との通信、種々の関連データの収集及び補完アクティビティー、が含まれる。
企業のセンダ１２のユーザーは、個人のみならず、アカウンティングやビリングのような企業情報システムグループでもある。例えば、ネットワークのｅポスタルソフトウェア２８は、これらの情報システム１７及び企業のｅメールサーバー１３における、顧客請求書やアナウンスメントのようなｅレターの形で送られる企業文書のための準備、送信、ｅポスタルサービス（ｅＰＯの“郵便料金メーター”を含む）の提供を支援する。

会社やその従業員は、ある企業ネットワーク内に属するレシーバ１４のユーザであり、またセンダ１２のユーザーでもある。送信操作の場合にそうであるように、ネットワークのｅポスタルソフトウェア２８は、レシーバ１４位置のレシーバｅポスタルソフトウェア及び企業のｅメールサーバー１３の双方と共に作動する場合は、企業ネットワーク及びｅポスタル運用が共により効率化され且つ有効化される。そうして得られる利益の一例は、これまで企業ネットワークに入り込んできた、低バリュー、低プライオリティのｅメールが排除されることである。
従って、本発明の要素を持つ企業では、その従業員のワークステーションのみならず企業サーバー位置において、ｅポスタルのセンダのユーザーにおけるような、差別化された、安全な、暗号化され且つ追跡されたことによる利益のみならず、ｅポスタルのレシーバのユーザーにおけるような、送られてくるｅメールをフィルタリングし、カテゴライズし、分配及び排除（適宜の場合）して不要な企業ＩＴのプロセス処理量、テクニカルリスク、使用帯域幅を低減させ、他方では従業員のｅメール作成能力を向上させによる利益を、非常に扱い易い様式において享受することができる。

図１及び図９を参照して先に議論したように、本発明はＩＳＰネットワーク内又その他幾つかの、企業イントラネットのようなネットワーク内のセンダ及びレシーバと共に作用し得るものである。図８において参照され且つ先に議論されたネットワークのｅポスタルソフトウェア２８は、企業イントラネットのみならず、特定のネットワーク用のネットワークのｅポスタルソフトウェアがネットワーク端末構成や組織のニーズに応じて変化得るその他の組織的及びＩＳＰネットワークと共に、ネットワークサーバーレベル位置での支援を提供し得る。

本発明の他の重要な様相は、従来の郵便サービスの場合にそうであるように、センダが、使用するｅポスタルサービスに対する支払いを行い、料金の異なる、異なるレベルのサービスが入手され得る点である。この様相自体、全ての従来のｅメールとの対比においてのみならず、ｅポスタルシステム自体の各ｅレター間においてｅメールがプライオリティ付けされる利益がある。また、支払い状況（ａｓｐｅｃｔ）によってシステムの利用が制限され、かくして、“フリー”ｅメールのトラフィック量増大の問題に対する市場解決策が提供される。先に議論したように、そうしたトラフィックノイズには２つの成分、即ち、１）正規の及び必要なｅメールのオーバーロード、２）不要な迷惑ｅメールが成分として含まれる。更には、センダにはｅメール量のみならずｅメール品質に関わる問題解決に対する関心がある。センダは、ｅポスタルシステムに固有の及びオプショナルとしてのより多くの安全上のオプションを求め、また、差別化され、安全な／暗号化され且つ追跡されたｅメール、より生産的なｅメール管理、使い易さ、全体的なアクセシビリティ、企業イントラネット及びその他ネットワークにおけるサポート、による利益を享受し得る。
あるセンダは、センダのみならずレシーバ１４のユーザーのためのものとしての“価値”のために、最も重要なｅメールをｅポスタルシステムを通してプロセス処理するために料金を支払う。

レシーバは、その他の通常のｅメールよりもｅレターを開封しがちである。その理由は第１には、ｅポスタルシステムのみがｅメールのプレミアムサービスの独自セットを提供することであり、第２には、レシーバはｅポスタルシステムからのｅレターを開封する方が通常のｅメールを開封する場合よりも価値が高く且つリスクを受ける恐れが低いと考えるからである。一般に、ｅポスタルシステムは、インターネットメールに関する、全体的な安全性、妥当なオーバーロード、プライオリティ管理、暗号化、追跡、使い易さ、迷惑メール、といった問題や機会に成功裏に対応する。その多くの理由の幾つかには以下のものが含まれる。
・レシーバ１４は、その他の通常の無料のｅメールの全てのレシーバとは異なり、センダがｅレターがレシーバに送信するために料金を支払うに十分重要であると考えていることが分かる。つまり、センダが、レシーバにｅレターを開封させるために、そのほかの通常の無料ｅメールの場合にはしないような何か価値の有るものを提供したがっていることが分かる。
・レシーバは、ｅＰＯ位置でのプロセス処理中は、ｅレターが技術上のリスク（ウィルスやワーム）及びコンテンツ上のリスク（攻撃的コンテンツ）からスクリーニングされていることを知っている。
・やはり全体的安全性の観点上から、レシーバは、各ｅレターがセンダの端末及びｅメールアドレスの確認を受けていることを知っている。詳しくは、レシーバは、以前はオリジナルのｅメールがセンダの端末からのものであることを検証していた自分の端末が、ｅレターがｅＰＯから送られてきたことを検証し、また各センダの認証さえし得ることが分かる。ｅＰＯは、各ｅレターに対し、プロセス処理の、検証され得る日付及び時間を与え得る。レシーバはセンダに対し、ｅポスタルシステムでｅレターのハードコピーをレシーバに配送させるようにリクエストすることもできる。

・レシーバは、例えば以下に挙げるような特徴によって、ｅレターをずっと容易且つ素早くスキャン、レビュー、読み取りが可能なことが分かる。
＊ｅメールアプリケーションの一般的な受信箱では、ｅポスタルのＩＤ及びプライオリティマークが付いているのでｅレターはより明瞭且つ迅速に見分けられる。
＊ｅレターは受信時に収集され、レシーバのｅメールアプリケーションの特別のｅポスタルフォルダ（又は、ｅポスタルプライオリティ、センダのアドレス、会社、等によって整理された様々のｅポスタルフォルダ）内に配置される。
＊新規のｅレターが到着すると特別の通知がレシーバに与えられ、到着に気付かないことによるそうした重要なｅレターの入手の遅れが回避される。
＊レシーバが自分の端末から長時間離れている時は、レシーバはｅＰＯのウェブサイトのｅポスタルメールボックスを借用して、その間に送られてくるｅレターを保持することができる。ユーザーは、ウェブブラウザを持つ別の端末を使用して、自分のアカウントやｅポスタルウェブサイトツールにアクセスして自分のｅレターを読む（及び送る）ことができる。

・暗号化されたｅレターについては、レシーバは、ｅポスタルシステムを介してプロセス処理された暗号化されたｅレターの受け取り、復号化、読み取りが素早く且つ容易にできることを知っている。システムは、レシーバが、暗号化されたｅレターをコンテンツの検証目的上アーカイブする作業をも助成する。これは、ＨＩＰＡＡ（個人情報保護法）の下で、暗号化されたｅレターを高度に分散及び規制することが要求される場合、例えば保健医療産業では非常に価値がある。
・無用な、迷惑メールの取り扱いに関しては、ｅポスタルシステムはレシーバが自分の通常の全ｅメールを受け取ることには干渉せず、レシーバの非ｅポスタルｅメールのどれかを、レシーバがそうしないことを選択しない限り、削除せず、レシーバのその他のｅメールの安全対策に干渉することもない。然し乍ら、ｅポスタルは、レシーバがそのように選択すれば、全ての非ｅポスタルｅメール及び非アドレスブックｅメール（未知のセンダの）を別のフォルダに入れることができる。この、非請求の、未知の、無用の迷惑ｅメールは、“第３カテゴリー”のフォルダは、まとめて簡単に削除され得る。
・先に述べたように、ｅポスタルアカウントを持つレシーバは、ｅレターを受け取り且つ管理するための全ｅポスタル機能を利用できるのに加え、ｅレターを開封するための経済的インセンティブをクレジットすることができる。レシーバはこのクレジットを使ってｅポスタルシステムを介して自分のｅレターを送信することができ、又は、このクレジットは、その残高が所定額に達したときはレシーバに定期的に加算され得る。
・こうした機能の全ては、レシーバ自身のｅメールアプリケーション内から容易且つシームレスに動作する。
・ｅポスタルシステムと企業あるいはその他組織のネットワークｅメール及びインターネットアクセスサーバーが互いに動作する場合は、そうすることが適宜である場合には、送られてくるｅメールをフィルタリングし、カテゴライズし、分散及び排除するための手段をネットワークレベルで持つことで、ＩＴ部門は自分のネットワークに関わる重要な制御を取り戻せる。それにより、そうでなければ無用なＩＴプロセス処理、自分のネットワークシステムに対するテクニカルリスク、使用帯域幅要件が軽減され、かくして資金やダウンタイムの節減が実現される他、会社の従業員のｅメール作成能力も向上する。

従って、レシーバがｅレターをその他のｅメールよりもずっと価値があると認め、その他のｅメールよりもｅレターの方をより多く開封するようになれば、センダにとって、ｅポスタルシステムを使用することの価値はそのコストを遙かに上回るものとなる。然し乍ら、レシーバがｅレターを高く評価するのに加え、センダにとってｅポスタルシステムを介して最も重要なｅメールをプロセス処理することには以下のような更に多くの理由がある。
・ｅレターが差別化されされること。ｅポスタルシステムは、区別用のプライオリティやサービス表示体のマークをｅレターに付ける。センダは、レシーバが自分のｅメールログをスキャンする時、ｅレターがｅポスタルシステムによってプロセス処理されていることを確かめる（従って、レシーバは、センダに対して、配送されたｅレターに対する支払いをするに十分に安全で、信用性があり、重要なものであることが分かる）のみならず、ｅレターを、自分のメールボックス内に受け取ったその他の通常の全ての“フリー”ｅメールから差別化し、またｅポスタルシステムを通して入ってくるその他の低プライオリティの（且つ低コストの）ｅレターから差別化するそうしたプライオリティやサービス表示体をも確認することを知っている。センダは、レシーバが、ｅレターがウィルスや攻撃的コンテンツからのリスクが最小であることを理解していることや、ｅレターのセンダが検証されていることを知っている。センダは、レシーバがｅレターをもっと簡単に見たりアクセスしたりできるように仕分けできることも認識している。従って、センダは、レシーバが通常のｅメールよりもｅポスタルのｅレターの方を開封して読むことの方がずっと多いことを知っている。本来、これら全ての機能（プライオリティ表示体、仕分け及び安全性）の効果によって、センダのｅレターは、レシーバの通常のｅメールの“山”の“頂上”に来るようになる。従来のメールではなく夜間配達を選んでも似たような効果が得られるが、そうしたは、配送が速いことではなく、レシーバが通常のｅメールを開封するより先に、プレミアム配送された“メールコンテナ”を見て開封しがちであることによって得られるものである。

・暗号化が容易であること。ｅレターはセンダによって極めて迅速に、容易に、且つ一般に入手可能な方法で安全に暗号化され得る。センダは、重要な、暗号化されたｅメールを書き換える必要のあるだれかのために特別のデジタルキーを入手して分配する必要がない。この点は、先にＨＩＰＰＡや保健医療産業について言及したように安全な、暗号化された通信を要求するセンダにとって新規且つ非常に価値のあるオプションとなる。センダのみならずレシーバは、コンテンツの検証目的のために、暗号化されたｅレターをアーカイブすることができる。
・ｅレターが追跡されること。センダは、レシーバがｅレターの受け取り／開封を通知することを要求できる。この通知は、センダのオリジナルのｅレターにリンクさせ得る、センダにとって役立つ大事な記録となる。センダは、レシーバのユーザーを、ｅレターの開封者の一人として認証することさえも要求できる。これは、企業とその顧客及び、インターネットによる情報交換に関心を持つクライアントとの間の構成を容易化する上で非常に重要である。そうした記録を使用すれば、企業は結局は自らの電子システムを信頼できる電子配達及び追跡システムにリンクさせ、特にｅポスタルシステムの一般に入手可能な安全対策を使用することで、コストを大幅に節約できようになる。

・レシーバが特別扱いされること。レシーバは、有用性のみならず、ｅレターの受け取り／開封に対するインセンティブを受けられ、それが、レシーバがセンダからのｅレターを開封することに対する更に大きな保証ともなる。センダは、センダから送ったｅレターに対してレシーバがｅポスタルシステムを通して返してくる反応に対して前納することもできる。これによりセンダへのそうした反応（及び評価）をレシーバにアピールされ且つ増大されることになる。
・使いやすく且つ使用上の融通性があること。ｅポスタルサービスは、センダにとって使いやすい。サービスの選択は全てセンダのｅメールアプリケーションをシームレスに使用する中で行える。センダの送信したｅレターは、このｅレターをその他の通常の送信ｅメールから、例えばプライオリティ、レシーバ別に分ける特別のフォルダ内で自動的に管理され得る。センダが自分の端末位置にいない場合は、自分のｅポスタルアカウント及びｅレターを送信（及び受信）するためのツールにｅＰＯウェブサイト位置でアクセスすることができる。

・全てのセンダがｅポスタルの機能を受けられるが、特に企業及びその他組織にとっては、差別化された、安全な、暗号化された、追跡されたｅメールに関わる能力のみならず、ｅポスタルネットワークレベルのソフトウェアがそれら企業等のネットワークレベルのｅメール及びインターネットアクセスサーバー及びその他企業情報システムと直結して作用する場合の、全体的に高い通信管理上のサービス効果にも有用性がある。

結局、本発明により、センダやレシーバそして個人及び企業双方のｅメールユーザーにとって非常に大きな利益が提供される。例えば会社では、本発明の機能を従業員のワークステーションや共有サーバー位置に配置することで、センダにおけるように、差別化された、安全且つ追跡されたｅメールを入手することができる他、レシーバにおけるように、受信するｅメールをフィルタリングし、カテゴライズし、分配し且つ排除する（そうすることが適切な場合）能力によって、従業員間等のネットワーク上での制御を回復できる利益も受けられる。その結果、無用なプロセス処理量、テクニカルリスク、使用帯域幅が削減され、それに伴って従業員のｅメール作成能力が向上する。企業に加え、その他組織のネットワークやＩＳＰでも、本発明の機能をそれら企業等のネットワークサーバーに組み込むことによる利益を受けられる。
以上、本発明を実施例を参照して説明したが、本発明の内で種々の変更をなし得ることを理解されたい。

本発明に従う構成を有し且つ動作するｅポストオフィス及びｅポスタルインターネット通信システムのブロックダイヤグラム図である。図１に示すシステムで使用する、本発明に従うセンダ電子郵便ソフトウェアを含むセンダｅポスタルのブロックダイヤグラム図である。図１に示すシステムで使用する、本発明に従うセンダ電子郵便ソフトウェアを含むセンダｅポスタルのブロックダイヤグラム図である。図１で示すセンダ及びレシーバ間でのインターネットを介するｅポストオフィス通信として動作する、本発明に従うｅポスタルサーバーソフトウェアに対するブロックダイヤグラム図である。図１に示されるシステムで使用される、本発明に従うレシーバｅポスタルソフトウェアを備えた場合のレシーバｅポスタルの動作に対するブロックダイヤグラム図である。図１に示されるシステムで使用される、本発明に従うレシーバｅポスタルソフトウェアを備えていない場合のレシーバｅポスタルの動作に対するブロックダイヤグラム図である。本発明の代替的実施例の図１に相当する図であり、センダ及びレシーバは使用中のコンピューター上に図２Ａ、Ｂ及び図４Ａに示されるようなｅポスタルソフトウェアを有していないが、ｅポスタルアカウントを有し、ｅポスタルウィンドウまたはｅポスタルウェブサイトにおいてｅポスタルシステムを介して電子レターを送受信することができる。図５に示されている実施例で使用される、本発明に従うセンダｅポスタルのｅポストオフィスの“ウィンドウ”またはｅポスタルウェブサイトでのインタラクション動作のブロックダイヤグラム図である。図５に示される実施例で使用される、本発明に従うレシーバｅポスタルのｅポストオフィスの“ウィンドウ”またはｅポスタルウェブサイトでのインタラクション動作のブロックダイヤグラム図である。本発明の更に他の代替的実施例の、図１及び図９に相当する図であり、本発明に従うｅポスタル動作上の構成要素はネットワーク内でセンダ／レシーバレベルとネットワークサーバーレベルとの間で共有される。インターネットへの様々な接続モードを使用する、本発明の他の実施例の、図１に相当する図である。レシーバへの物理的伝達用のオプションを示す、本発明の更に他の実施例の図１に相当する図である。レシーバがｅポストオフィスにｅポスタルｅメール及び関連するｅポスタルデータを送信するための、本発明の他の実施例を示す、図１に相当する図である。ｅポストオフィスからレシーバへのｅポスタルｅメール及び関連するｅポスタルデータ送信のための本発明の他の実施例を示す、図１に相当する図である。センダからレシーバへのｅポスタルｅメール及び関連するｅポスタルデータの直接送信のための本発明の他の実施例を示す、図１に相当する図である。ユーザーがｅポスタルソフトウェアをダウンロードし、インストールし、起動するための各ステップの一例を示す操作上のブロックダイヤグラム図である。ユーザーがｅポスタルソフトウェアをダウンロードし、インストールし、起動するための各ステップの一例を示す操作上のブロックダイヤグラム図である。ｅポスタルクライアント（センダ及びレシーバ）ソフトウェアとｅポストオフィスとの間の直接通信の一例を示す図である。クライアントソフトウェアとｅポストオフィスとの間の直接通信の一例を示す図である。クライアントソフトウェアとｅポストオフィスとの間の直接通信の一例を示す図である。ｅポスタルクライアントソフトウェアとｅポストオフィスとの間の直接通信のための、本発明に従うメッセージデータ構造の一例を示す表である。ｅレターをプロセス処理してｅポストオフィスに送信するためのセンダのステップシーケンスの一例を表す操作流れダイヤグラム図である。ｅレターをプロセス処理してｅポストオフィスに送信するためのセンダのステップシーケンスの一例を表す操作流れダイヤグラム図である。センダからｅポストオフィスに送るための本発明に従うｅレターのカスタムヘッダを構造化する一例を表す図である。ｅレターをプロセス処理してレシーバに送信するためのｅポストオフィスのステップシーケンスの一例を表す操作流れ上のダイヤグラム図である。ｅレターをプロセス処理してレシーバに送信するためのｅポストオフィスのステップシーケンスの一例を表す操作流れ上のダイヤグラム図である。センダからｅポストオフィスに送るための、本発明に従うｅレターのカスタムヘッダを構造化する一例を表す表である。ｅレターの最終プロセス処理のためのレシーバのステップシーケンスの一例を表す操作流れダイヤグラム図である。ｅレターの最終プロセス処理のためのレシーバのステップシーケンスの一例を表す操作流れダイヤグラム図である。

符号の説明

１０ｅポスタルシステム
１２センダ
１３企業メールサーバー
１４レシーバ
１６遠隔通信リンク
１７企業情報システム
１８インターネット
１９ＩＳＰ（インターネットサービスプロバイダー）
２０ｅポストオフィス
２２、２６クライアントソフトウェア
２８ネットワークｅポスタルソフトウェア

Claims

メッセージ内容成分と、当該メッセージ内容に関わる及び又は当該メッセージ内容を、インターネットを使用し且つインターネットを増強する多数の発信者及び受信者の端末間で転送することに関するメッセージデータ成分とを有する電子メールを転送するための通信システムであって、
郵便サーバー及び郵便サーバーソフトウェアと、
発信者及び受信者の各端末を郵便サーバー及び郵便サーバーソフトウェアに結び付けるリンクと、
発信者端末をインターネット及び発信者のリンクを介して郵便サーバーに選択的に接続するように、少なくとも発信者端末上で動作する発信者ソフトウェアと、
を含み、
郵便サーバーソフトウェアが電子メールにおけるプレミアムサービスを提供し、発信者端末及び発信者ソフトウェアが、転送された電子メールに関して前記プレミアムサービスが実施されるようにするための選択を提供し、発信者端末及び発信者ソフトウェア及び郵便サーバー及び郵便サーバーソフトウェアが、少なくとも部分的にはダイレクト通信を使用して相互に通信する通信システム。
インターネット及び受信者のリンクを介して郵便サーバー及び郵便サーバーソフトウェアから受けた電子メールを少なくとも受信者端末上でプロセス処理するように動作する受信者ソフトウェアを更に含み、受信者端末及び受信者ソフトウェアが、発信者端末及び発信者ソフトウェアと郵便サーバー及び郵便サーバーソフトウェアとの少なくとも一方と通信して、発信者及び受信者が使用するための及び通信システム自体のための仮想イントラネットを生成する請求項１の通信システム。
発信者ソフトウェア及び受信者ソフトウェアの少なくとも一方が、発信者端末及び受信者端末位置に保存されたアプリケーションソフトウェアである請求項２の通信システム。
インターネットが、多数の発信者及び受信者の端末上で動作するｅメールアプリケーションソフトウェアを有し、発信者ソフトウェア及び受信者ソフトウェアの少なくとも一方が、前記ｅメールアプリケーションソフトウェア内で動作自在である請求項３の通信システム。
発信者ソフトウェア及び受信者ソフトウェアの少なくとも一方が、郵便サーバー位置で発信者及び又は受信者に保存され且つ発信者及び又は受信者にアクセス可能である請求項２の通信システム。
リンクが、多数の端末をインターネットと相互接続するネットワークを含み、発信者、受信者、郵便サーバーソフトウェアの少なくとも１つが、前記ネットワーク位置の発信者及び又は受信者に保存され且つ発信者及び又は受信者にアクセス可能である請求項２の通信システム。
発信者ソフトウェア、受信者ソフトウェア、郵便サーバー及び郵便サーバーソフトウェア、の少なくとも一つによって動作され得る支払いソフトウェアを含み、該支払いソフトウェアが、郵便サーバー及び郵便サーバーソフトウェアの使用料金を確認及び報告する請求項１の通信システム。
支払いソフトウェアが、受信者端末位置で選択された電子メールが開封されるのに応答して受信者端末用のインセンティブクレジットを報告する請求項７の通信システム。
支払いソフトウェアが、発信者ソフトウェアが選択する郵便サーバー及び郵便サーバーソフトウェアのオプショナルサービスに応じた追加料金を徴収する請求項７の通信システム。
インターネットと、発信者端末、受信者端末、郵便サーバーの何れかとの間を結ぶリンクが、遠距離通信リンクを含む請求項１の通信システム。
インターネットと、発信者端末、受信者端末、郵便サーバーの何れかとの間を結ぶリンクが、ＩＳＰ、イントラネット、エキストラネット、ＬＡＮ、ダイヤルアップ、ＤＳＬ、ケーブル、衛星、携帯電話、無線、物理的配送、及びそれらの組み合わせ、の少なくとも１つを含む請求項１の通信システム。
プレミアムサービスが、発信者の許可、発信者端末を運用するエンティティの同一性の認証、受信者端末を運用するエンティティの同一性の確認、送受信メールの優先順位付け、テクニカルリスクに対するメールのスクリーニング、コンテンツリスクに対するメールのスクリーニング、メールが受信されたことを発信者に通知、メールが開封されたことを発信者に通知、郵便サーバーを介しての受信者による発信者への応答のためのプリペイド返信、メールのハードコピーの配送、受信者に対する、メールを開封するためのカスタム化されたインセンティブ、郵便サーバーのプロセス処理の検証可能な日付及び時間スタンプ、コンテンツの完全性の検証、通常メールからプレミアムメールを安全に保存、送受信されたプレミアムメールのアクセス可能な履歴、郵便サーバー位置でのメールのホールディング（ｈｏｌｄｉｎｇ）の生成、メールサービスに対する支払いと報告、及びそれらの組み合わせ、を含む請求項１の通信システム。
優先順位付けが、郵便サーバー及び郵便サーバーソフトウェアによってプロセス処理される電子メールと、その他の、インターネット上で運ばれる電子メールとの間での差別化である請求項１２の通信システム。
優先順位付けが、郵便サーバー及び郵便サーバーソフトウェアによってプロセス処理されたメールの中での差別化を含む請求項１２の通信システム。
発信者端末及び受信者端末及びインターネットが、異なる組み合わせでのオペレーティングシステム及びインターネットソフトウェアを有し得、発信者ソフトウェア及び受信者ソフトウェアが、そうした異なる組み合わせのオペレーティングシステム及びインターネットソフトウェアを、郵便サーバーを介して横断してインターフェースするようになっている請求項１の通信システム。
郵便サーバーが、少なくとも１つの位置において複数のサーバーを含んでいる請求項１〜１５の何れかの通信システム。
発信者ソフトウェア、受信者ソフトウェア、郵便サーバーソフトウェアが、転送セッション用の通信接続を開設し、リンク上の安全性を確立し、発信者を確認し、メッセージコンテンツ及びメッセージデータを転送し、転送セッションを閉じるように動作する請求項１６の通信システム。
ダイレクト通信が、ＨＴＴＰ、ＳＭＴＰ又はその他のソケットプロトコルを使用する請求項１７の通信システム。
リンクが、ＩＳＰのコンテンツメッセージが、郵便サーバー及び郵便サーバーソフトウェアをバイパスすることにより、発信者及び受信者のＩＳＰ間を転送されるリンク、データメッセージが、少なくとも部分的には、発信者と郵便サーバー及び郵便サーバーソフトウェアとの間のダイレクト通信及び受信者と、郵便サーバー及び郵便サーバーソフトウェアとの間のダイレクト通信を使用して通信されるリンクを含む請求項１８の通信システム。
メッセージコンテンツの通信が、インターネットのメールサーバーを介してＳＭＴＰ／ＰＯＰ及び又はＩＭＡＰプロトコルを使用し、メッセージデータ通信の少なくとも一部分が、ＨＴＴＰ、ＳＭＴＰ又はその他のソケットプロトコルを使用する請求項１９の通信システム。
データが、送信元及び又は受信者を識別する部分を含むカスタムヘッダとしてフォーマットされる請求項１６の通信システム。
カスタムヘッダが、メッセージ成分を確認及び検証する部分と、メッセージ成分のプロセス処理を指定する部分とを更に含む請求項２１の通信システム。
発信者及び発信者の各端末及びソフトウェアと、郵便サービスサーバー及び郵便サーバーソフトウェアとの間のダイレクト通信が、クッキー、サードパーティー認証／キー、を利用する一般的なＨＴＴＰＳセッショニングプロトコルと、単独の転送プロトコルとである請求項１６の通信システム。
ダイレクト通信が、ＨＴＴＰ、ＳＭＴＰ又はその他の、セッションＩＤを使用して発信者及び受信者のソフトウェアとのＨＴＴＰセッションをシミュレートするソケットプロトコル、暗号化の管理、別の転送プロトコル、転送されるメッセージ成分のためのカスタムデータ構造、を使用するリンク上での取引（ｃｕｓｔｏｍ）である請求項１６の通信システム。
支払いのための確認及び報告が、発信者及び受信者のソフトウェアのセットアップファイルのダウンロード及びインストール、発信者及び受信者のソフトウェアの、発信者及び受信者の各端末へのインストール、発信者及び受信者のアカウントの登録、発信者及び受信者のアカウント及びクレジットの検証、ｅレター又はダイレクト通信によるアクティベーション、を含む請求項７の通信システム。
メッセージコンテンツ成分と、当該メッセージ内容に関わる及び又は当該メッセージ内容を、インターネットを使用し且つ拡大させる多数の発信者及び受信者の間で転送することに関するメッセージデータ成分とを有する電子メールのための通信方法であって、
発信者及び受信者の各端末をインターネットにリンクさせること、
受信者における通信上のプレミアムサービスを、転送される電子メールのメッセージデータ成分の少なくとも一部をプロセスするための電子郵便サービスを使用して発信者に選択させること、
を含む方法。
発信者によるプレミアムサービスの選択又は発信者によるｅメール通信に応答して受信者に電子郵便サービスを連係させること、を更に含む請求項２６の方法。
連係が電気通信によるものを含む請求項２７の方法。
連係が、多数の発信者又は受信者の各端末をネットワーク化するものを含む請求項２７の方法。
選択できる郵便サービスには、郵便のプレミアムサービスの少なくとも一部のための支払い及び報告の各サービスが含まれる請求項２７の方法。
支払い及び報告の各サービスが、受信者端末のユーザーに対する相互通信のためのインセンティブを提供するものである請求項３０の方法。
電子メールのメッセージデータの少なくとも一部分が、ダイレクト通信によって電子郵便サービスに通信され、また電子郵便サービスから通信される請求項２６〜３１の何れかの方法。
発信者、受信者、電子郵便サービス、の中でのダイレクト通信及びその他の通信が、仮想イントラネットを構成する請求項３２の方法。
電子郵便サービスが、少なくとも部分的にはダイレクト通信によって内部通信を行う複数のサーバーに分配される請求項３２の方法。
ダイレクト通信が、ＨＴＴＰ、ＳＭＴＰ又はその他のソケットプロトコルを使用する請求項３２の方法。
メッセージ成分が、郵便サーバー及び郵便ソフトウェアをバイパスするＩＳＰを介して発信者及び受信者間で転送され、メッセージデータ成分が、少なくとも部分的には、発信者と、郵便サーバー及び郵便ソフトウェアとの間の及び受信者と、郵便サーバー及び郵便ソフトウェアとの間のダイレクト通信を使用して通信される請求項３５の方法。
メッセージコンテンツ成分の通信が、インターネットのメールサーバーを介してＳＭＴＰ／ＰＯＰ及び又はＩＭＡＰプロトコルを使用して通信され、少なくとも部分的なメッセージデー多成分の通信が、ＨＴＴＰ、ＳＭＴＰ又はその他のソケットプロトコルを使用する請求項３６の方法。
電子メールのメッセージデータの一部を、発信者端末及び又は受信者端末を識別するカスタムヘッダとしてフォーマットすることを更に含む請求項３２の方法。
カスタムヘッダとしてフォーマットすることが、メッセージ成分を確認及び検証し且つそのプロセス処理を指定する部分を提供させることを更に含む請求項３８の方法。
電子郵便サービスへの及び電子郵便サービスからのダイレクト通信が、通常はＨＴＴＰＳセッションプロトコルクッキーと、サードパーティー認証／キーと、単独の転送プロトコルとを使用する請求項３２の方法。
電子郵便サービスへの及び電子郵便サービスからのダイレクト通信が、ＨＴＴＰ、ＳＭＴＰ又はその他の、セッションＩＤを使用して発信者及び受信者のソフトウェアとのＨＴＴＰセッションをシミュレートするソケットプロトコル、暗号化の管理、別の転送プロトコル、転送されるメッセージ成分のためのカスタムデータ構造、を使用するリンク上での取引（ｃｕｓｔｏｍ）である請求項３２の方法。
支払いのための確認及び報告が、発信者及び受信者のソフトウェアのセットアップファイルのダウンロード及びインストール、発信者及び受信者のソフトウェアの、発信者及び受信者の各端末へのインストール、発信者及び受信者のアカウントの登録、発信者及び受信者のアカウント及びクレジットの検証、ｅレター又はダイレクト通信によるアクティベーション、を含む請求項３０の方法。