"複数のユーザアカウントを有する金融トランザクションと電子メッセージングシステムの運用方法であって、このシステムは第1のユーザ、第2のユーザ、および第3のユーザをそれぞれ第1、第2および第3のネットワーク接続デバイスで接続し、前記ユーザはそれぞれシステム上に第1、第2および第3のアカウントを有し、各デバイスは1以上のネットワークサーバにアクセスして前記アカウントに関連する情報を含むファイルを保存または取得可能であり、a各ユーザアカウントはSummaアカウントを有し、各Summaアカウントはデビットとクレジットの双方が可能な金融アカウントおよびメッセージングシステムを具え、b第1のユーザアカウントを送信者とし、第2のユーザアカウントを受信者として、メッセージ部と料金割り当て部とを含むSummaメッセージを送信するステップと、c前記第2のユーザアカウントに前記メッセージ部を配信するとともに、当該メッセージ部の送達の確認がとれた場合にのみ、前記料金割り当て部にかかる資金を前記第2のユーザアカウントに移転させるステップと、d第2のユーザアカウントを送信者とし、第3のユーザアカウントを受信者として、第2のメッセージ部と第2の料金割り当て部とを含む第2のSummaメッセージを送信するステップと、e前記第3のユーザアカウントに前記第2のメッセージ部分を配信するとともに、当該第2のメッセージ部の送達の確認がとれた場合にのみ、前記第2の料金割り当て部にかかる資金を前記第3のユーザアカウントに移転させるステップと、を前記1以上のネットワークサーバが実行することを特徴とする方法。希望しない電子メールは時間と生産性の浪費となり、多くの人間がスパムから保護すべく実際に自身の電子メールアドレスを隠しているほどである。これでは、実際に連絡を希望する人間やビジネスの連絡をより簡単にするという目的が阻害されてしまう。同じ問題が、希望しない電話マーケティングコールにもある。このため、プライバシーと所望の製品の有効なマーケティングの必要性との間の適切なバランスを作り出すシステムの必要性があった。上述の問題は、電子送金および電子メールシステムに関する既存のシステムを用いては適切に導けないものであり、後者はSMTPとPOP3プロトコルを用いている。したがって、a希望のあるいは希望しない通信の双方を閲覧するのに要する時間に対する強力なコントロール、b自身のマーケットアイデンティティに関する共有情報の価値の向上、c金融トランザクションを実行する才の簡便性とセキュリティ性の向上、をユーザにもたらす新規な電子通信システムの必要性があった。本発明は、a電子メールに似た金融アカウントを用い、各ユーザに電子的に制御され送金および入金のいずれもが第三者への電子メールの一部としてなされる金融アカウントの安全なメッセージングシステムを構成し、b特定の個人、個人のグループ、会社組織からの電子メールの受信に必要となる受信料金表をユーザが設定することができ、cユーザの許可を得て、この金融アカウントを利用したユーザの購入品のマーケティング情報を収集し、これを企業に販売してユーザが受信チャージから受け取る収入を増大させる、ことによりこれらの目的を達成するようにしている。これらの3つの特徴はいずれも、単独でも組合せでも、現在のところ知られていない。<用語解説>以下の技術用語は本明細書を通して反復して用いており、読者にとって実質的に本発明の理解に役立つであろう。デジタル証明DigitalIdentificationまたはDIとは、法律で定められた電子署名、デジタル署名DS、または同一性の電子認証であり、非同時暗号化の形で、銀行や郵便局など信頼できる第三者から発行された証明機関CAの証明であり、指定された保持者の同一性を証明するおのである。ヘッダとは、Summaメッセージ以下の定義を参照に関する情報であり、通常は受信者に参照されるが、サーバとクライアント間でメッセージを処理しアカウントを決算するのにも用いられる。ネットワークサーバとは、Summaアカウント以下の定義を参照のクライアント間で情報を集配するサービスプロバイダに設けられたハードウェアとソフトウェアである。受信料金receiptchargeとは、Summaメッセージ以下の定義を参照の受信者により設定され送信者のアカウントに課される料金であり、一律に、あるいは料金表に規定された特別な金額が受信者にクレジットされる。受信者とは、Summaアカウント以下の定義を参照のユーザであって、Summaメッセージ以下の定義を参照を受信する者である。送信者とは、Summaメッセージ以下の定義を参照を送信するユーザである。サービスプロバイダとは、複数のユーザに少なくとも1のSummaネットワークサーバを介してSummaアカウント以下の定義を参照を提供する団体である。典型的に、このサービスプロバイダは、銀行や金融機関、インターネットサービスプロバイダ、あるいはSummaアカウント以下の定義を参照を介してユーザからアクセス可能な他の商業広告またはクレジット機関である。SummaアカウントSummaaccountとは、電子的に運営される金融アカウントであり、統合電子メッセージングシステム、あるいは逆に、1またはそれ以上の金融アカウントの電子マネジメントに統合する電子メッセージシステムである。あるいは、Summaアカウントは、1またはそれ以上の金融アカウントに対するクレジットまたはデビットに必要なプログラムと権限を有する電子メッセージシステムからなる。SummaクライアントSummaclientとは、Summaメッセージ以下の定義を参照の作成、送信、受信、読み込みを行い、関連する金融アカウントおよびアカウント記録にアクセスするための、ユーザマシンに常駐するソフトウェアである。SummaメッセージSummamessageとは、Summaアカウント間の送金に関する情報を含む電子メッセージであり、送信者から受信者への追加の情報、メッセージまたは添付物を含んでもよい。さらに、Summaメッセージは送金指示に加え、電子テキスト、イメージ、音声、電話通信を含んでもよい。ユーザとは、ネットワーク上のSummaアカウントにおける人物または商業団体である。あるユーザはSummaメッセージの受信者にも送信者にもなり得る。以下の定義を参照以上の記述により、本発明は理解され実践される。本発明の好適な実施例によると、送金手続に先立ち、各Summaユーザは自身のSummaサービスプロバイダに金融アカウントを開設する必要がある。このアカウントは、預金とクレジットラインのいずれかまたは双方を含む必要がある。ユーザがアクセスし1以上のSummaアカウントを操作するSummaクライアントを通して、ユーザはSummaメッセージの配信を受けるのと引き替えに送信者が受信者に支払わなければならない受信料金の表を規定する。Summaメッセージの配信に際し、Summaアカウントの送信者には合意した金額がデビットされ、この送信者のアカウントにはこの金額がクレジットされ、さらにサービスプロバイダにより課される任意のサービス料金がマイナスされる。受信者がメッセージ受信料金を集める仕組みを提供するのに加え、本発明はさらに別に資金を2つのSummaアカウント間で転送する安全な方法を提供する。これによりインターネットでの購入、マイクロペイメント、電子インボイスや請求書の支払い、およびユーザが必要とする様々な他の送金が容易になる。この支払いは、Summaアカウント間での直接送金であるため、インターネット上でクレジットカード番号やアカウントナンバーを送信する必要がない。さらに、ユーザの了承を得た上で、サービスプロバイダは購入の種別を追跡し、各ユーザのマーケティングデータベースに追加する。この利用可能なデータの収集と作成は各ユーザのマーケットアイデンティティの価値を高め、ひいてはユーザが受信料金で受け取る収入を増やすことができる。このプロセスには以下の利点がある:1ユーザは自身の料金表により受信を了承sるうメッセージのみを受け取るため、無差別な商業広告または個人メッセージのスパムが排除され、2受信者は自分の時間とマーケットアイデンティティの価値による収入が得られ、3Summaサービスプロバイダは更なるサービスチャージと広告収入が得られ、4広告企業はSummaメッセージを介して自身の商業広告の受信に興味のある個人のリストをより簡単に得ることができ、5良好なトラッキングと検証により電子送金を安全な方法で実行することができる。本発明の主たる特徴は、ユーザの信頼が信頼できる、インターネットを用いたユーザフレンドリーな送金システムを提供することにある。本発明の別の特徴は、ユーザが希望するのと希望しない通信の双方を見るのに費やす時間を大幅に抑制する上記のトランザクションシステムを提供し、ユーザのマーケットアイデンティティから伝わる情報の価値を増大させ、金融トランザクションを実行するのに多大な利便性とセキュリティ性を提供する。本発明のさらなる別の特徴は、安全なメッセージシステムを電子制御された金融アカウントに接続するトランザクションシステムを提供し、各ユーザが電子メールの一部として第三者に対し金銭の送受信の双方を同じSummaアカウントを用いて可能であり、ユーザが特定の個人、個人グループ、ビジネスのクラスからの電子メールの受信に必要な受信料金表を規定し、ユーザの了承を得たうえで、このユーザによるこの金融アカウントを用いた購入のマーケティング情報を収集し、これを企業に売ることによりユーザが受信料金から得られる収入が増大する。本発明の別の更なる特徴、利点、利益は、添付図面に関する以下の記載により明確となる。上述の総括的な記述と以下の詳細な説明は例示と説明に過ぎず、本発明を制限するものと解されてはならない。本発明に編入され一部を構成する添付の図面は、本発明の一実施例を図示しているが、記述とともに、本発明の一般的な用語の原則を説明するものである。開示において、同様の部品は同じ番号で参照している。ここでは、公知の特許システムの幾つかを考慮すべきと考え、その後本発明で得られ従来技術にない利点に話を戻すこととする。Sundstedの米国特許5,999,967は、固有のまたは譲渡可能な価値を有する電子スタンプを表す電子メール添付物を用いた電子メールのフィルタリング方法を開示する。この技術はジャンクな電子メールをより有効に識別して処理することを可能にする目的を明確に記載している。この主な特徴は電子スタンプを介してスパムに対する経済的なバリヤを生成することにある。この目的のため、電子スタンプは支払いが認められた人物に送信されるべき約束手形であればよい。あるいは、ユーザは第三者トークンプロバイダを通じて譲渡可能な通貨へと償還し交換されるトークンを購入するようにしてもよいと述べている。換言すれば、Sundstedは送金または個人の時間とマーケットアイデンティティの価値を捉えたよりよい方法を開示するものではない。これに対し、本発明は電子メールに金銭価値を添付するものではないが、代わりに1つの金融アカウントから別のアカウントまで実際のトランザクションあるいは預金を開始し完了する機構を提供することにより、約束手形やSundstedの集金用の宛名のないタスクを越えるものである。これは、Summaメッセージすなわち、金融トランザクションとメッセージの配信を絶対条件として実現する。特に、Sundstedは約束手形またはトークンを電子郵便料金に添付される1度きりの使用以外の他のいかなる目的にも用いる構成を持たないことである。事実、彼はいかなるトークンまたは電子情報の再使用も防がなければならないと述べている。Sundstedが教示する価値表示としての電子スタンプは、新たな購入に使用しうる、あるいは請求書に支払ったり、電子郵便料金いに支払える通貨ではない。Councilの米国特許6,192,114と6,587,550は、未承認の送信者すなわち、受信者のパススルーあるいはホワイトリストにない人物に電子メールの配信に先立って支払うべき電子請求書を送信することにより、電子メールをフィルタリングする方法を開示している。また、サービスプロバイダに請求アカウントまたはクレジットカード番号を開設することにより、送信者多くは、巨大な商業広告主が配信料金の支払いを予め指示できるようにした。Sundstedの例と同様に、Councilは、受信料金の受け取りによるデポジットや、購入、請求書の支払い、他人の受信料金への支払いのための引き出しする資金について金融アカウントを作成する利点の発見に失敗している。カウンシルはまた、特定の送信者または幅広い商業階層について異なる受信料金の表を作成することの利点の発見に失敗している。代わりに、Councilではユーザが許可送信者のリストを保持することが必要であり、このリストにない請求書送信者を検索する。これに対し、本発明はSummaアカウントにいるすべてのユーザ間の関係を単純化し、ユーザにとって知らない相手でも、自動的にメッセージ送信が予め承認され、配信料金の支払いを徴収するのにいかなる請求プロセスも不要としている。さらに、Councilはユーザに異なるサービスプロバイダのアカウントを持たせる機構はないが、請求書がすべてこのサービスを提供する一社に支払われることを必要とする。他の特徴は、Councilは、ユーザの受信コンピュータが電子メールのソースの特定の表示を検出するようプログラムされており、承認された送信者のリストのソースと比較する機能を要する。しかしながら、上述したように、Councilのシステムでは不正なヘッダを防ぐことができない。もし出所の表示が正当であれば検出する意味がなくなる。これに対し、本発明のシステムでは、Summaネットワークがそれ自体ユーザの同一性を立証するよう構成されているため、受信者のコンピュータが電子メールのソースを検出する必要がない。図面を参照すると、最初に図1は本発明特有の技術を示しており、ネットワークサーバ32,38が電子的な接続36を介してSummaメッセージを交換するコンピュータネットワークを用いて制御および実現されている。本発明は図面に示す実施例を参照して説明されるが、本発明は様々な代替例または実施例として実現可能であることを理解されたい。本発明の各要素または材料は様々な適切なサイズ、形態、種類であってよい。図1に示すように、個人ユーザ20,22,24,26,30はそれぞれ、少なくとも1のSummaクライアントにアクセスしている。ユーザ20は、例えば、Summaクライアント21にアクセスしている。ユーザ24,26は、1つはユーザ24用のuser24sn1、1つがユーザ26用のuser26sn1、1つがユーザ24,26双方で共有のjointsn1の計3つのアカウントアドレスにSummaメッセージを送受信するよう設定されたSummaクライアント25が動作する共有コンピュータにアクセスしている。これらのSummaクライアントを介して、ユーザはそれぞれ割り当てられたネットワークサーバ32、38と通信する。例えば、Summaクライアント21はインターネット接続28を介してネットワークサーバ32に接続されている。ユーザ20がユーザ22宛のメッセージを送信した場合、ネットワークサーバ32はSummaクライアント21から受け取るメッセージを、ユーザ22のSummaクライアント23が取得するまでメモリに格納する。異なるサーバのユーザ間でなされるメッセージ交換は、これより僅かに複雑となる。例えば、サーバ38が管轄するユーザ30にユーザ24がメッセージ送信を希望したとする。サーバ32により、受信者のアドレスであるユーザ30はサーバ38が管轄するユーザ宛であることが確認され、ネットワーク接続36を介してネットワークサーバ38に中継される。このサーバ38のメッセージ転送ソフトウェアは、自動的に受信者のアドレスを解析して、このメッセージがユーザ30に送られるものであることを認識する。メッセージが配信される場合、ユーザのSummaクライアント31が取得できるようにアクセス可能なファイルとして保存される。上述の説明は電子メッセージングの当業者であれば一般に理解可能である。本発明は、しかしながら、この共通スキームにさらに別の要素を付加している。すなわち、Summaネットワークサーバはさらに、各ユーザ用の金融アカウントとデータベース34、40を保持し、送信者のアカウントに課金され配信にあたり各ユーザにクレジットされる料金表と、Summaメッセージの配信にあたり金融アカウントにクレジット貸方記入またはデビット借方記入する手段とを備えている。図2に示すように、ユーザ20の料金表と消費者プロファイルの一般的な例がデータベース34に入力され保存されている。本図において、各列は異なる情報カテゴリを示している。説明のために、各列80~88は、別個のファイルを示している。当業者であれば他のデータ構成を考えることができる。図2に示すように、各ファイルの最初の行は、このファイルに登録された情報種別のラベルであり、第2行はユーザ20の固有の識別子であり、本例では単にUser20IDと示し、いくつものファイルにまたがりユーザ20の適切なデータを識別し、リンクし、アクセスするのに利用される。本例では、一般情報データファイル80には、パスワードやデフォルトの受信料金といった標準の情報とともに、ユーザ20のクレジット、デビット、サービスチャージの合計額が保持されている。個人連絡リストファイル82は、ユーザ20が知っているユーザであって、ユーザ20がデフォルトの受信料金とは異なる受信料金を設定したいと考えるユーザのリストである。受信料金がゼロで示されるすべてのアドレスは、パススルーリストに関連づけされる。消費者プロファイルリスト84は、ユーザ20の消費者プロファイルに関するデータを含んでおり、例えば、好き嫌い、製品嗜好、最近の購入歴、人口統計情報などである。宣伝費用リスト86は、ユーザ20が規定する様々な種類の商業アカウントに対して適用される料金表を含んでいる。拒否リストファイル88は、ユーザ20が自動的に返却または廃棄を望むユーザアドレスのリストであり、この者が最大の受信チャージを払うといっても考慮されない。新規のSummaアカウントを開設する場合、あるいはサービスプロバイダや顧客が自身のアカウント設定の変更を希望する場合、Summaアドレスの持ち主は基本の料金表を設定するための電子フォームを完成させるか修正する。図3は、図2に示すデータベースにユーザが提供した情報を登録するソフトウェアサブルーチンの各ステップを示すフローチャートである。これらのステップの順番は特に重要ではない。コンピュータプログラミングの当業者であれば、この処理の様々な変更例を構築できるであろう。本サブルーチンの基本ステップは、このユーザのデフォルトの受信料金を設定し、特定の商業メッセージの種類に課される特定の料金の入力を可能とし、消費者プロファイルを構成する付加情報を入力することである。デフォルトの受信料金以外の受信料金が設定される人物や拒否アドレスの設定は、基本要件に対して付加的な変更となる。これらのリストの特定のアドレスは個々に入力されてもよく、電子メールソフトで共通に用いられているアドレスブックファイルの形でアップロードされてもよい。図2に示すこれらのステップは、収集されてデータベースに保存され、本発明の通常の方法に含まれる料金とクレジットの交換に役立ついかなる種類のデータも除外するものではない。図4は、サーバのサブルーチンの主要なステップを概説する基本のフローチャートであり、受信者宛に受け取るSummaメッセージを検査して、1送信者に適切な料金を課し、受信者にクレジットを提供してSummaメッセージを受信者に配信する、または2拒否理由を示す適切な通知とともにメッセージを送信者に返却する。後者は、受信者の常に拒否するメッセージ送信者のリストに送信者が登録されている場合、および送信者がSummaアカウントを有さず、あるいはそのアカウントに十分な資金がない場合に生じうる。受信者の受信料金が、送信者が受信料金として支払いを同意した最大料金を超えている場合にもメッセージは返却される。例えば、ユーザが金融ニュースレターからのメッセージをそれぞれ10セントで受信するよう設定した場合であって、このような商業メッセージの送信者が受信者ごとに受信料金として7セントしか支払わない通知とともにメッセージを送ると、この送信者は当該メッセージが配信されなかった旨と配信に先立ってこの送信者が支払いを了承すべき適切な料金が示される。この方法により、商業広告メッセージの送信者は自身のコストを正確にコントロールすることができ、さらに自身の最大料金が低すぎた場合にSummaリストのどの部分に問題があるかが分かる。典型的な実施例では、送信者が支払ってもよい最大料金が受信者の受信料金を超えている場合、送信者のアカウントには実際の受信料金のみが課される。本発明は金融トランザクションおよびクレジットを実行する機構を提供するものであるため、サービスプロバイダは処理費用の請求を希望し、連邦、州や地方自治体もこれらのトランザクションに様々な課税を行うことが考えられる。これは例えば注文ごとにセールスマンのロイヤリティと売り主で利益を分けるように、ビジネスに利益をもたらす構成である資金の分割を含む。収集されたお金が法律、契約、または他の複数のアカウントに分割する同意により求められた場合はいつでも、各トランザクションについて適切な側から適切な金額を差し引いてその料金を例えば、税金、経費、利益分配として統制法や契約やユーザの指示により適切なアカウントに入れるようにプログラムするのは簡単な話である。要求に応じて、支払いの一部を受け取るそれぞれの側にオリジナルメッセージのコピーまたは他のメッセージが自動的に生成され送られるようにして、各側の需要に応えるようにしてもよい。このメッセージは、もしあれば、単なるトラック番号または配送アドレスのみであってもよい。この更なる支払いの適用と記録の追加プログラムを付加する処理は当業者であれば容易である。図4に示す各ステップは、Summaメッセージの配信を制御するすべての他の可能なサブルーチンを排除するものではない。むしろ、このフローチャートは、本発明によりカバーされる本発明の典型的な実施例を示すものに過ぎない。プログラミング技術の当業者であればこのアプローチに容易に様々な変更を施すことができる。典型的な実施例では、メッセージの安全な配信は、送信者のサーバからの送信要求RTSと、受信者のサーバからの送信許可PTSとで達成される。このステップは、Summaメッセージの配信にあたり課金および同一性の証明となる。追加のセキュリティの予防措置として、RTSはさらに、PTSの後に受領証として送られるメッセージのハッシュサムhashsumを含んでもよい。これにより、受信者のサーバが、受信メッセージが認められたPTSと合致することを確認することができる。PTSを受信すると、送信者のサーバは、メッセージ配信が成功するまで資金を一時的なエスクローアカウントに転送されるようにする。受信者のサーバから配信証明を受信したら、エスクローの資金は受信者にクレジットされる。上記の例では、メッセージの配信成功が確認された場合のみ送金が最終的に承認される。代替的に、別の環境では送金が最終的に確認されるまでメッセージを保持するのが望ましい場合もある。どの例を適用するかはメッセージの種類やユーザの選択オプションにより決定されてもよい。さらに、メッセージハッシュといったメッセージ識別情報とともに、Summaメッセージが最初に送信された日時とこれが配信された日時を簡単に記録することができる。この情報は様々な状況において、ユーザが保持する記録のコピーを第三者サービスプロバイダが保持する記録と比較して確認するのに用いる公的な日時スタンプとして利用可能である。あるSummaサービスプロバイダのユーザから別のサービスプロバイダのユーザへの送金は、各サービスプロバイダにおけるユーザアカウントに保持された資産価値の連続的な遷移を生じさせる。好適な実施例では、サービスプロバイダが金融機関であり、サービスプロバイダ間の差引勘定は、例えば一日の終わりなどに定期的に実行されるACHに似たトランザクションで調整される。典型的な実施例では、図1に示すように、この処理は、各Summaサービスプロバイダの正確なオーダのネットバランスを出すことが求められる周期的な送金を監視し、計算し、処理する1またはそれ以上の中央情報センタサーバ50で自動決済される。典型例では、中央情報センタ50はまた、すべてのSummaサービスプロバイダに対する全ネットワークサーバアドレスのリストを保持しており、各トランザクションは情報センタに受信者のサービスプロバイダのアドレスを問い合わせまたは確認するクエリーで開始される。同様に、受信サーバは情報センタを介して送信サーバの信頼性を確認する。これにより、許可されていないサーバを介するSummaメッセージおよびトランザクションを開始する試みを拒否できる。当業者であれば、この情報センタサーバの動作に匹敵する他の共通のセキュリティおよびデータ収集機能を容易に考えることができる。図1に示す好適な実施例において、メッセージシステムは、金融機関の電子送金およびアカウントシステムにより構成されている。代替例として、図5では、送金指示を行う外部の電子機材42を用いてSummaトランザクションを実行している。例えば、ユーザ20がインターネットバンキングアクセスを提供する銀行44にアカウントを有する場合、ユーザ20は自身のユーザIDとパスワードを自身のSummaクライアント21に入力し、これがユーザのサーバ32が前記インターネットバンキングのインタフェース42を介してアクセスし選択された銀行のアカウントに送金するのに用いられる。典型例では、これらの送金記録がSummaアカウントデータベース34に保持される。このような場合、Summaメッセージシステムが実際は銀行の金融アカウントシステム内に組み込まれていないため、金融アカウントへの十分なアクセスと制御がSummaシステムに許可されることにより、本発明の目的を達成するのに必要な送金を完了させることができる。代替例として、または付加的に、ユーザはSummaメッセージサービスの契約に署名して、ユーザがもつすべてのアカウントへの情報センタ自動決済を許可してもよい。この代替例において、送金手段42は様々な電子送金手段であってよく、特に限定するものではないが、Summaネットワークサーバが金融アカウント間の送金を手配可能な独立あるいは情報センタ50と組み合わさったACHシステム、クレジットカード処理システムである。例えば、あるACHトランザクションが行われる場合、ユーザが選択したアカウントルーチン番号がこのユーザのSummaクライアントを介して提供される。ACHトランザクションは通常バッチファイルを用いて処理されるため、それぞれ個別のSummaメッセージごとにACHの送金オーダを作成する必要はない。例えば、1日のうちに、ユーザ20がSumma支払いを10回行い、Summa支払いを13回受け取り、最終的に5.31を得たとする。この場合、ネットワークサーバは1日の送金記録を各Summaアカウントごとにクレジットとデビットの合計が登録されるデータベース42に蓄積する。ユーザ22について23回ものACHトランザクションを行うのではなく、ネットワークサーバはその日の終わりに5.31の1回のACHトランザクションを指示する。このプロセスはACHトランザクション費用を抑えるのみならず、銀行明細に記載する必要のある金融トランザクションの数を抑えることができる。サービスフィーを含むクレジットとデビットの合計金額は、毎日の終わりに差引勘定されるため、1日の終わりにすべてのSummaアカウントのクレジットを中央金融アカウントに入れるとともに、1日の終わりのすべてのSummaアカウントのデビットを同じ中央金融アカウントから出すことにより、このシステムをさらに単純化することができる。この代替例では、ユーザの毎日の銀行明細には、1日の合計のSummaアカウントのクレジットとデビットを示す1つのACHトランザクションしか載らないことになる。しかしながら、Summaアカウントデータベースを介して各トランザクション、上記実施例の場合はユーザ20による10のSumma支払いと13のSumma支払いの受領の詳細にアクセス可能である。代替例では、各アカウントの差引勘定を毎日行うのではなく、サービスプロバイダは各ユーザのアカウントのデビットまたはクレジットが、ACHの費用をかけるのに相応しい、例えば20の最低金額を超えるまで待って差引勘定するようにしてもよい。同様のプロセスを、例えばクレジットカード番号を用いたクレジットラインへのアクセスで行うようにしてもよい。別の実施例では、図5に示す複数の金融機関44,46に金融アカウントを所有する1つのサービスプロバイダのアカウント間でネットバランスのシフトを行ってもよい。44-46間のトランザクションを減らすには、ユーザが少なくとも44または46において少額を授受するSummaアカウントで制御される自身の金融アカウントを持つ必要がある。この代替例では、ユーザ22が銀行44、ユーザ30が銀行46を選択し、両者が1のサービスプロバイダが運用するネットワークサーバ32,38により運営されるSummaアカウントを有する。Summaユーザの適切な許可により、各銀行のサービスプロバイダのアカウントから、22-30間の支払いを銀行間での送金を伴わずに完了することができる。代わりに、22により支払われた金額が44でサービスプロバイダのアカウントに入り、46でサービスプロバイダのアカウントを出て30のアカウントに入る。これにより、低コストで、2つの銀行間での送金が1つの銀行内での送金で済む。この例では、各銀行の正味の預かり金は手を加えず、ただし各銀行におけるサービスプロバイダのアカウントに反映される。これは、44,46におけるサービスプロバイダ自身のアカウント間で、ごくまれにであるが周期的にACH送金を行うことにより簡単に実現する。このプロセスもまた、電子送金手段42内にあるSumma情報センタ50で実現することができる。上述の決済シナリオの多くの場合、サービスプロバイダがエスクローアカウントのクレジット貸方とデビット借方をまとめるのをユーザが許可する必要がある。このエスクローアカウントはネットワークサーバまたは情報センタサーバ50が保存するファイルの形で存在する。各アカウントの現在のバランスの記録に関連して、ネットワークサーバは現在のエスクローアカウントを用いて貸し越しを防ぐべく十分な資金があるかを確認する。典型例では、このエスクローは2つの部分からなる:ペンディングのトランザクションと完了したトランザクションである。ペンディングトランザクションは、おそらくまだ受信者にSummaメッセージがダウンロードされていないため配信キューにあるが未送信のSummaメッセージの配信に伴い支払いに回される資金を含む。ペンディングトランザクションで支払いが追認された資金はエスクローにより確保され、送受信ができなくなる。a配信が拒否された場合、b送信者が配信をキャンセルした場合、c送信者が配信要求してからタイムリミットを設けて取りやめるオプションを選択している場合、このメッセージについて寄託された資金は送信者のアカウントに戻される。それ以外の場合、ネットワークサーバが配信許可を受領したら、送信者のエスクローアカウントにおいてペンディングデビットを追認済みデビットに変更するとともに、受信者のアカウントに追認済みクレジットを記録することにより、送信者と受信者間の支払いが実行される。前日の決算バランスに当日の追認されたクレジットと、ペンディングと追認の双方の控除額とを加算して、ネットワークサーバはSummaユーザにリアルタイムの自由になる資金の差引勘定を提供することができる。前述のように、1日の終わりのバッチファイルは、金融機関またはサービスプロバイダが保持するネットデポジットに移すのに用いてもよい。この例では、1日の終わりのバッチ送金は、エスクローアカウントにある追認済みデビットと追認済みクレジットの累加を含む。すべてのペンディングトランザクションが、配信、キャンセル、Summaメッセージの拒否があるまでエスクローアカウントに保持される。本発明の他の重要な特徴は、ユーザの許可を得た上で、サービスプロバイダがさらに購入種別を追跡し各ユーザについて作成されたマーケティングデータベースに追加する。ユーザが調査票に記入することにより、さらなるマーケティング情報が収集される。人物データ、購入歴、調査データはネットワークサーバに保存され、或いは中央情報センタまたはマーケティングデータ50を蓄積する中央データセンタに送られる。このように取得されるデータの収集と作成は、各ユーザのマーケットアイデンティティの価値を向上し、このユーザが受信料金として得られる収入が増えることになる。伝統的に、例えば、ある消費者がある製品を購入すると、その人物は売り主からしばしば更なる製品案内を受け取る場合がある。さらに、その人物へ連絡するための情報や購入者プロファイルが他の企業に売られ、これが消費者ではなく売り主の利益となる。これに対し、Summa購入では消費者を熱い期待で注目しているため、買い手により向上したマーケットの独自性の金銭的利益は、Summaメッセージを介して配信される追加の案内を受ける際に、必要な受信チャージを受け取る消費者に与えられる。ユーザのSummaアカウントの価値を最大限とするために、マーケティングデータの使用はSummaメッセージを介して案内する場合に制限される。代替例では、サービスプロバイダはマーケティング情報を販売し、消費者のメールアドレスまたは電話番号を含むデータを企業が購入するごとに各Summaユーザにクレジットするブローカーとして動作してもよい。マーケティングデータが電子データベースに収集されたら、選択条件をプログラムに入力することにより企業が求めるリストを抽出して提供することは容易である。このようなデータ採取はプログラミングの当業者であれば通常の作業であり、労力となるものではない。さらに、ネットワーク設計の当業者であれば情報センタや情報マーケティング用の中央データベースを、上記のシステムの機能を妥協することなく、別個にあるいは組み合わせられることを直ちに理解するであろう。上記の一般的な説明と以降の詳細な説明は説明用の例示であって、本発明を何ら限定するものではない。この開示において、金融アカウントとメッセージアカウントをリンクさせ、受信料金を設定し、クレジットとデビットを追跡することは、コンピュータネットワークプログラミング、データベースプログラミング、電子メールプログラミングの当業者であればこのプロセスを実現する多数の方法を考えることができる。<基本発明の詳細>本発明の本質は、ネットワークサーバを介して金融アカウント同士を関連づけたことにあり、金融アカウントは安全な電子メッセージサービスにより制御され、ユーザが送金したり受信料金を得たりすることができる。一旦このメカニズムが実現すれば、当業者であれば特定のアプリケーションに役立つ追加の変更を施すことができる。これらの追加の特徴は、このプロセスを実現し追加の機能をもたらすSummaメッセージに含まれるヘッダにより実現される。以下に記載するような変更例を通じて、実際に伝統的な事務手続で行われる様々なビジネスまたはアカウント手法が実現し、さらに有効となるよう変更され、一方でユーザに自身の通信と金融トランザクションを強力に制御できるようにしている。第1に、上述したように、このヘッダは受信料金として送信者が支払える最大金額を特定するフィールドを備える。この最大金額が、例えば、10セントであり、受信者のこの商業カテゴリのメッセージ受信にかかる受信料金が5セントである場合、送信者のアカウントに5セントのみチャージされ、これが受信者にクレジットされる。他方、受信者の受信料金が20セントの場合、メッセージは配信されず、送信者には高い配信料金のことが通知される。第2に、ヘッダは、送信者のSummaメッセージが分類される商業カテゴリの識別子を含むと便利である。契約上の同意により、ユーザ受信者と送信者の双方を含むは、公告案内の厳密な分類に用いる情報を提供し、この分類システムの決定に拘束される。第3に、ヘッダ部分は、受信者が受け取ったメッセージに返信した場合にチャージされる金額を特定している。商業的アプリケーションにおいて、例えば、受信者には送信者にさらなる情報の問い合わせを返信した場合には何もチャージされないことが通知される。代替例では、送信者は、返信することにより受信者に案内した製品の購入金額と同じ金額をチャージするよう設定することができる。これにより、案内と承諾返信の2つのSummaメッセージを交換することで、金融トランザクションを実行することができる。この返信のチャージは、通常の受信チャージとは異なってよいが、所定期間経過後には通常の受信チャージと同じとなってもよい。第4に、ヘッダは、受信者のSummaアカウントに全部送られる全部の送金クレジット金額を特定するさらなるフィールドを備えてもよい。このように構成すると、たとえ受信者の受信チャージが指定された全部の送金クレジット金額より少ない場合であっても、この全部の送金クレジット金額が送金される。この方法により送信者は、支払い、製品購入、返金、金銭ギフト、または送金を伴う他の目的のために、Summaアカウントすべてのユーザに送金することができる。第5に、ヘッダは、特定の方法で表示あるいは処理されるべきメッセージの種類を特定する情報を含んでもよい。本例によれば、請求書の種類としてタグ付けられたメッセージは、請求書のアイテム番号、明細、数量、単価、合計金額が、受信者の会計ソフトウェアで自動的に取得されるよう構成される。XMLやXHTMLフォーマット言語をこの目的に簡単に用いることができる。Summaクライアントは、この請求書ヘッダを認識し、ユーザにこのメッセージを請求書として表示し、以下のオプションを提示する1請求金額と同額のクレジットを全部転送する指示を出すことにより全額支払う、2請求額の一部を支払う、3請求書に異論がある旨の返信を行う。オリジナルメッセージのヘッダを用いて、返信メッセージに自動的に請求書番号や他の情報を標準のフォーマットで含め、送信者の会計ソフトで適切な計算の調整が行われるようにすることができる。同様に、契約書タイプのドキュメントを、署名送信ボタン付きで表示させ、受信者がこのドキュメントに電子署名し、デジタル識別子とともに署名済みドキュメントを送信者に返信できるようにしてもよい。他にも様々なドキュメントタイプがあり、購入オーダー、スプレッドシート、調査や世論調査、ページ分けした電子ブック、申請書、納税書、全部または一部が音声または映像ファイルのドキュメントや所定の方法で処理されるべき実行コード、ビジネス政府非営利プライベートなトランザクションで通常用いられる様々な種類のフォームを含む。第6に、ヘッダは、単にネットワークサーバを特定し、予定する受信者の受信料金の通知を送信者が求めるために用いられてもよい。この料金問い合わせメッセージは、この予定の受信者には配信されず、単にSumma配信サブルーチンから前記受信者の正しい料金を、たとえ料金がゼロである場合にも、通知する自動返信を生成させるのに用いられる。サービスプロバイダはこの問い合わせのために料金情報を収集するようにする。第7に、図2の各ユーザのデータベースに更なる構成を付加して、広告メッセージの数、受信により希望する収入額、本当に必要な広告メッセージの呼び込みをさらに制御するようにしてもよい。例えば、ユーザは特定の商業分類から1週間または1月に受信を希望するSummaメッセージの最大数を指定することができる。例えば、ユーザが1週間に芝の肥料の広告を何ダースも受信し、実際に興味はあるのだがこれらに当惑した場合、彼はこのようなメッセージは週に6通までとする制限を自身の料金表のある欄に入力するようにしてもよい。あるいは、ネットワークサーバは、このようなすべてのSummaメッセージを毎週待ち行列に入れ、週末に受信料金が高い順に6通の広告を配信するよう設定することができる。この方法によれば、広告主は潜在顧客の関心に対し競ることができる。逆に、あるユーザは各週に受信料金で得たい最低金額を設定することができる。この所望金額を最後まで満たさない場合、ネットワークサーバは、ユーザが通常要求する受信チャージより少ないと認められるがより高い入札者から受信し、さらに受信者がこれらの申し出のレートで受信を望むまで待ち行列のメッセージを残すように設定することができる。同様に、広告主は彼らの選択条件に合致するSummaユーザ全員へのメッセージの配信を事前指定するようにしてもよい。例えば、料理本の売り主は事前に、調理器具を購入したユーザにその後直ちに、または所定の期間の後、広告が送信されるようにすることができる。事前指定されたSummaメッセージによると、ユーザが必要なときにマーケティング情報を呼び出すことが可能となる。例えば、ユーザはいつも住宅ローン金利に興味があるわけではないが、時によりよい住宅ローン金利を探すのに非常に関心がある場合がある。通常、住宅ローン情報の受信を防ぐには、高い受信料金を設定する。競合数社から情報を受けたくなった場合には、彼は受信料金をより適切なレベルまで引き下げることができる。さらに、Summaクライアントは、関心の告知AnnouncementofInterest:AIまたは対象物を特定して情報や入札や見積りを示す入札要求を示す特定のドキュメント種別を提供してもよい。別の代替例では、このAIは、AIが自身の関心カテゴリにある場合に配信を要求するすべての商業Summaユーザに放送されてもよい。あるいは、このAIは、AIの要求が事前指定されたメッセージと合致する中央サーバで処理され、商業Summaユーザは合致するすべてのAI要求に返信するよう準備している。これらの送受信において、消費者と商業ユーザは自身でよいと思う最大の配信料金または受信料金を設定する。もちろん、サービスプロバイダも更なる課金を適用することができる。第8に、本発明はさらに、幾重にも及ぶマーケティング努力を容易にしている。例えば、サウナを販売する企業が、100万もの人間への適格なメール送信において潜在顧客ごとに5セントのみを支払うことを希望するとする。このメッセージは企業が何を案内するかと、受信者が最初のメッセージを読んだ後にここをクリックしてこの企業の製品をさらに検討するまでに興味をもった場合に5の追加クレジットを約束する旨が説明されている。ここをクリックのリンクを操作すると、ユーザのSummaクライアントは更なる情報の要求を自動的に送信者に送信する。送信者はその後、例えばビデオクリップと、約束の5のクレジット全部送金とが添付され、情報が追加された第2のSummaメッセージを返信する。代替例では、この顧客にこの会社のインターネットサイトの特定のページへとクリックする指示が出されてもよく、ここで広告情報と、ユーザが5のクレジットが送信されるべきSummaアカウント情報を含む入力フォームとを表示する。第9に、他の変形例として、ユーザが受信料金に負の数字を設定可能とすることがある。これは予約支払いを意味し、受信者がSummaメッセージを受信するごとに送信者への支払いを認めるものである。これは、例えばニュースレターの発行への支払い手段として利用することができる。この負の受信料金は、送信者の最大受信料金の欄にある負の受信料金と比較される。受信者が設定した料金が十分でなければ、このニュースレターは配信されない。この方法により、ユーザはこの負の数字を正の数字に変更することにより容易に購読を取りやめることができ、情報提供者は発行ごとに確実に料金を収集することができる。第10に、セキュリティを強化するために、Summaメッセージの送信は、通常の電子メールクライアントやサーバで用いているPOP3やSMTPの方法とは大きく異なる通信プロトコルを含む。典型的な実施例では、SummaクライアントとSummaネットワークサーバ間、およびSummaネットワークサーバ同士の間では、暗号化、圧縮、送信要求、送信許可、呼びかけと応答、メッセージハッシュ、機関による証明、ID認証、およびコンピュータセキュリティ専門家にとってよく知られた他の技術を用いる。これらの技術は単独で、あるいは組み合わせて用い、身元確認された送信者から確実に送金され、また受信者宛の送金およびメッセージが秘密に行われるようにしている。特定のSummaクライアントはSummaメッセージをこの安全なプロトコルで作成する必要があるが、このSummaクライアントはまた、POP3/SMTP電子メールの作成、ダウンロード、読み込みもできるようプログラムされる。この後退的な両立しうる機能性により、Summaユーザは、パススルーリストにあるSummaアカウントを有さない人物からのPOP3の電子メールを継続的に受信することができ、また自分のSummaクライアントから同じ人物にSMTPメッセージを送信することができる。第11に、Summaアカウントデータベース34、40に登録されたマーケティングデータは、企業がもっとも商業広告の送信を希望するSummaユーザの部分集合を特定するデータマイニング、分離、選択に役立つものである。本発明によれば、このマーケティングデータは、個々のSummaネットワークサーバを介して作成されてもよく、あるいは企業がここからデータを抽出する中央データベースに収集されてもよい。このようなデータベースからのデータの編集、検索、分類は当業者にとって公知であり、追加の労力を伴うものではない。第12に、HTMLが電子メールクライアントに所定のアドレスにメッセージを送信するよう電子メールを送信する機構を提供するのと同様に、特別なウェブページプログラミングを用いて、所定のユーザに所定のクレジットを送るSummaメッセージを送信するハイパーリンクを提供することができる。買い手と売り手は単にSummaアカウントを有するだけでよい。Summaハイパーリンクのプログラミングは、大抵は送信者に購入される製品を特定するメッセージ情報を含み送信者への支払いを認めるSummaメッセージを送信することを含む。典型的な実施例において、買い手が購入を了承する場合、大体がパスワードを入力すると、Summaトランザクションが実行される。配送先住所が必要な場合、これは自動的に売り手のデータベースから提供される。この方法により、コンタクト情報を記入したりクレジットカード番号を示す必要がなくなり、インターネットでの購入を簡単にする手段が提供される。同様の方法をマイクロペイメントシステムにも適用できる。例えば、価値のある情報を含むウェブページにアクセスするためには、特別のハイパーリンクに次に進む場合の費用を表示し、これが実行された場合、ユーザを所望のページに移し、要求される数セントあるいは1セント未満のSumma支払いを了承する。本例では、ユーザは通常最大料金として、このユーザがパスワードを伴う購入手続を行うことなく支払ってもよい金額、例えば5セントを設定する。この方法により、Summaアカウントのユーザはコンテンツのブラウジングにマイクロペイメントが必要なウェブアクセスを簡単に行うことができる。第13に、多くのアプリケーションにおいて、デジタル証明DIを提供または要求することが有効である。例えば、送信者から契約要求や税金の申請と支払いとともにDIを送付したりする。この場合、送信者は単にSummaメッセージにDIを添付するオプションを選択するだけでよく、受信者はメッセージがDI付きか否かを見ることができる。反対に、送信者が受信者に、Summaメッセージの送信に先立ってDIを要求してもよい。これは、書留郵便を送ったり法的通知をしたりする際に、受信者が受け取るにあたり署名するしたり公的な証明や会社のIDを提示するのと同じである。この要素を追加することにより、Summaメッセージの送信者は一般的なあるいは特定のDIを用意して配信される状況を整える選択がある。DIを提供するタスクは自動化あるいは半自動化される。最も典型的には、受信者は電子的に1以上のデジタル証明を自身のSummaクライアントまたはネットワークサーバに登録しておき、いつでも使用できるようにする。例えば、送信者はSummaメッセージの配信の前に、デジタル証明および/または特定のCAの形の身元確認を要求してもよい。この例では、メッセージは保持キューに入れられ、ネットワークサーバが求められているDIを受信者のネットワークサーバに要求する。受信者が彼の側で自動的にDI要求を満たすよう構成されている場合、受信者のネットワークサーバは自動的にDIを送信者のネットワークサーバに送出する。必要に応じて、送信者または送信者ネットワーク発行団体の公開鍵を用いてCAの信頼を確認してもよい。受信者の信頼性が確認されたら、キューのSummaメッセージがその後開放され、通常の状態で配信される。あるいは、サーバから要求された場合または受信者の選択により、適切なボタンまたはアイコンをクリックしてDIを送る許可がマニュアルで行われ、その都度受信者が配信を認めた場合にのみDIが送られるようにしてもよい。この例では、受信者は現時点ではオリジナルのSummaメッセージを受け取っておらず、DIを要求する通知のみ受け取り、これには要求者の名前が含まれていてもよい。典型例では、キューに入れられたメッセージの配信に先立つDIの要求通知は、表示すると容易に要求に応えられるボタンを含む特別なドキュメント形式で扱われる。この要求は、しかしながら、適当な受信料金が課される別個のSummaメッセージとして扱われてもよい。第14に、他の金融トランザクションから購入嗜好の情報をさらに付加することにより、収集されたマーケティングデータの価値をさらに高め、これによりユーザが受信料金で受け取れる収入を増大することが可能である。例えば、購入時にデビットまたはクレジットカードセールスで通常収集されるデータを各ユーザのデーターベースにリンクすることができる。あるいは、サービスプロバイダが発行する新たなクレジットまたはデビットカードを、小売店の精算レーンに設けた専用のトランザクション端末におけるSummaトランザクションの認証に用いるトークンまたはスマートカードとして利用することができる。この場合、トークンは端末で認証される暗号化したCAを含み、さらにユーザパスワードを入力する構成であってもよい。ユーザがこの売買の認証を行うと、端末は代金を支払いネットワークサーバのユーザの購入品のリストをアップロードするSummaメッセージを生成する。この例では、精算端末は単に、適切な暗号トークンとパスワードで端末に識別される様々なユーザからアクセス可能な専用のSummaクライアントとして動作する。同じトークンを、Summaネットワークがいつものアクセスポイントでないと判断したネットワークデバイスからユーザが自身のSummaアカウントへのアクセスを希望した場合に追加のセキュリティの予防措置に用いてもよい。価値のあるマーケティングデータが蓄積される金融トランザクションを遂行する上記の手段あるいは同様のスキームは、電子技術の当業者であれば容易に実現できる。本発明は、マーケティングデータが消費者の利益のために蓄積される点で無比のものである。最後に、このシステムはネットワークサーバとSummaクライアントの手段により効果的に実現することができるが、プログラミング技術の当業者であれば本発明を通常の方法でサーバベースのアプリケーションソフトウェアまたはウェブベースのサイトのいずれでも容易に実現することができ、これによりOutlookExpressを用いる代わりにウェブベースの電子メールサイトであるHotmailと類似の方法を用いて、ネットワークサーバに保存された電子メールを見ることができる。<付加的な派生>本発明は、ビジネスにおける多くの新規な方法とモデルを紹介するものである。例えば、インターネットサービスプロバイダは、入会金をなくし、代わりにユーザの受信料金または送金に対するサービスフィーを課すことができる。テクニカルサポートセンタは、ヘルプリクエストに対する前払いを徴収するのにSummaアカウントを用いることができる。企業は雇用者に対してSummaアカウントの受信料金を設定し、外部から雇用者に対する接触の対価を徴収してもよい。この収入は雇用者に通信手段を提供し顧客から更なる価値を生じさせるコストと相殺するのに用いることができる。コンピュータプログラミングの当業者であれば、Summaアカウントを多くの通常のビジネス形態に適するように容易にプログラムすることができる。例えば、Summaアカウントは複数とし、1人のユーザアドレスでいくつもの金融アカウントにリンクさせることができる。この場合、ユーザは自身のメッセージのすべてを取得するのに単一のSummaクライアントを有するが、Summaメッセージを送信する場合にユーザは複数の金融アカウントから受信料金または他の支払いを引き落とす口座を選択することができる。反対に、例えば夫婦といった複数ユーザのユーザアドレスが同じ金融アカウントにリンクされてもよい。このシステムでは、2以上のユーザに支払いの了承を要求するように簡単に変更可能である。例えば、電子的なSumma請求書を企業の会計士に送信することもできる。この請求書を確認したら、会計士は支払いを指示するが、メッセージは受信者に直接送られるのではなく、代わりに自動的にこの会計士の共同署名人、すなわち企業のオーナーに回される。この支払い情報を含むSummaメッセージは、企業オーナーが配信を許可してからのみ送信されるようにしてもよい。すべてのSummaアカウントの記録は電子フォーマットであるため、この会計情報は容易に会計ソフトウェアで読み込みあるいはインポートすることができる。あるいは、会計ソフトをSummaクライアントに組み込むようにしてもよい。本発明の教示を考察するにあたり、プログラミングと会計技術の当業者であれば、複数のアカウント、複数の署名者、歳入と支出の追跡、顧客履歴の収集等は容易に実現可能であり、通常のまたは特別目的のSummaアカウントを制御するプログラミングを僅かに変更して変形例とすることができる。<結論>本発明が開示する技術は、以下の効果を有する:ユーザのアイデンティティと時間の価値を向上し、受信する電子メッセージの種類と量に対する多大なる制御をユーザに提供する。受信する電子メールメッセージの量と質を統制し、ユーザの収入を生成する実践的な方法がなかった従来技術の欠点を修正する。ユーザが望まない電子メールメッセージが殺到するおそれから電子メールアドレスを秘密に保つ衝動を低減し、アドレスを公共で記載できるようにして適切な連絡を受けやすくする。ユーザとサービスプロバイダ間の技術的かつ契約によるビジネス関係のシステムを通じたコンピュータネットワークを介する金融トランザクションを実行する新たな方法を提供する。商業的電子メールメッセージング、顧客需要の特定、およびユーザが望まない電子メールメッセージにより苦しめられている気持ちを取り除くことよる企業と顧客の関係向上のためよりオープンな構成を提供する。サービスプロバイダに新たな収入源を提供し、サービスのコストを低減し、電話会社、銀行、クレジットカード会社で用いられるモデルに沿ったビジネス展開の新たな道を開く。上記の説明は、多くの実施例と精密な例を含んでいるが、これらは本発明の範囲を限定するものとして解釈してはならず、単に本発明を実現する原理を示すにすぎないと解されるべきである。この開示により、このプロセスをユーザやサービスプロバイダの個々の需要に合わせて変更することは当業者であれば容易である。例えば、Summaクライアントは携帯電話機や他のネットワーク電子デバイスであってもよい。同様に、受信料金は電話着信や他の形態の電子メッセージの受信に適用してもよい。このように、上記は本発明の原理が示されていると解すべきであり、いかなる限定をするものではない。当業者であれば多数の変形例や変更例が可能である。このため、本発明はここに図示し説明した同一の構成に限る趣旨ではなく、したがって、コンピュータの周辺機器にアクセスを制限するユーザがアクセス可能なスイッチを用いるすべての変形例や均等物は本発明の範囲に含まれる。"