JP5130039B2 - 送受信料金を伴う金融トランザクション - Google Patents

Description

本発明は一般に電子メッセージングに関し、特に、金融トランザクションにおけるセキュリティを確保するとともに、ユーザが金融トランザクションを行うための電子メッセージングの現在の問題を解決する電子メッセージングを確保することに関する。

ビジネスや個人的な通信にインターネットを用いると、（ａ）金融トランザクションのセキュリティ性、（ｂ）電子メールアドレスの悪用、（ｃ）秘密情報の悪用、（ｄ）上記３つの問題を避けるための不便さ、というおそれがあった。

電子メールの悪用について、スパム対策は往々にして、必要なメッセージもブロックしてしまうリスクのあるフィルタリングや、それぞれ電子メールをソースに基づき許可またはブロックするホワイト／ブラックリストや、例えばＬｅｅｄｓによる米国特許６，３９３，４６５の応答システムの試みに頼っていた。他のアプローチは、スパムに対する金融活動の拒否を含んでいる。Ｓｕｎｄｓｔｅｄの米国特許５，９９９，９６７には、電子メールに「電子スタンプ」を添付し、受信者が「この電子メールの受領を承認した場合に送信者に合意した金額を請求」することが開示されている。あるいは、送信者は後に料金を徴収可能な第三者から電子スタンプを購入することができる。Ｃｏｕｎｃｉｌによる米国特許６，１９２，１１４と６，５８７，５５０は、権限のない送信者に電子メールの配信に先立ち支払うべき電子請求を送信する方法を開示している。Ｒａｙｍｏｎｄの米国特許６，６９７，４６２には、権限のない送信者に、配信されるメッセージを受信者が希望しなかった場合を検出したらサービスプロバイダがペナルティを課す契約の送信を求める方法が開示されている。

秘密情報の悪用について、取引相手との必要な連絡およびトランザクションであっても後に電子メールやクレジットカード番号や他に提供する情報を悪用されるリスクが高まっている。インターネット上にクレジットカード番号が流れるのを防止すべく、Ｓｔｅｉｎの米国特許６，２４６，９９６は、販売者が購入者に仲介者の電子メールシステムを介して請求するシステムを開示している。請求書は仲介者が運営する電子メールシステムを介して送られ、購入者がこの請求書への支払い確認とともに返信すると、仲介者がアカウント情報を送ることなく販売者にトランザクションが実行される。代替例として、Ｆｏｓｔｅｒの米国特許６，３３２，１３４は、金融クレジットカード情報を売り手に開示するのを防止すべく、顧客が金融機関へ電子メッセージを発すると、当該金融機関宛のメッセージ内で特定される販売者への支払いが承認されるようにしている。情報を制限する他の試みがＢｒｉｓｅｂｏｉｓによる米国特許６，３３０，５５０でなされており、これは顧客プロファイルサーバを用いている。

希望しない電子メールは時間と生産性の浪費となり、多くの人間が「スパム」から保護すべく実際に自身の電子メールアドレスを隠しているほどである。これでは、実際に連絡を希望する人間やビジネスの連絡をより簡単にするという目的が阻害されてしまう。同じ問題が、希望しない電話マーケティングコールにもある。このため、プライバシーと所望の製品の有効なマーケティングの必要性との間の適切なバランスを作り出すシステムの必要性があった。

上述の問題は、電子送金および電子メールシステムに関する既存のシステムを用いては適切に導けないものであり、後者はＳＭＴＰとＰＯＰ３プロトコルを用いている。したがって、（ａ）希望のあるいは希望しない通信の双方を閲覧するのに要する時間に対する強力なコントロール、（ｂ）自身のマーケットアイデンティティに関する共有情報の価値の向上、（ｃ）金融トランザクションを実行する才の簡便性とセキュリティ性の向上、をユーザにもたらす新規な電子通信システムの必要性があった。

本発明は、（ａ）電子メールに似た金融アカウントを用い、各ユーザに電子的に制御され送金および入金のいずれもが第三者への電子メールの一部としてなされる金融アカウントの安全なメッセージングシステムを構成し、（ｂ）特定の個人、個人のグループ、会社組織からの電子メールの受信に必要となる受信料金表をユーザが設定することができ、（ｃ）ユーザの許可を得て、この金融アカウントを利用したユーザの購入品のマーケティング情報を収集し、これを企業に販売してユーザが受信チャージから受け取る収入を増大させる、ことによりこれらの目的を達成するようにしている。これらの３つの特徴はいずれも、単独でも組合せでも、現在のところ知られていない。

＜用語解説＞
以下の技術用語は本明細書を通して反復して用いており、読者にとって実質的に本発明の理解に役立つであろう。
「デジタル証明（Digital Identification）」またはＤＩとは、法律で定められた電子署名、デジタル署名（ＤＳ）、または同一性の電子認証であり、非同時暗号化の形で、銀行や郵便局など信頼できる第三者から発行された証明機関（ＣＡ）の証明であり、指定された保持者の同一性を証明するおのである。
「ヘッダ」とは、Summaメッセージ（以下の定義を参照）に関する情報であり、通常は受信者に参照されるが、サーバとクライアント間でメッセージを処理しアカウントを決算するのにも用いられる。
「ネットワークサーバ」とは、Summaアカウント（以下の定義を参照）のクライアント間で情報を集配するサービスプロバイダに設けられたハードウェアとソフトウェアである。
「受信料金（receipt charge）」とは、Summaメッセージ（以下の定義を参照）の受信者により設定され送信者のアカウントに課される料金であり、一律に、あるいは料金表に規定された特別な金額が受信者にクレジットされる。
「受信者」とは、Summaアカウント（以下の定義を参照）のユーザであって、Summaメッセージ（以下の定義を参照）を受信する者である。
「送信者」とは、Summaメッセージ（以下の定義を参照）を送信するユーザである。
「サービスプロバイダ」とは、複数のユーザに少なくとも１のSummaネットワークサーバを介してSummaアカウント（以下の定義を参照）を提供する団体である。典型的に、このサービスプロバイダは、銀行や金融機関、インターネットサービスプロバイダ、あるいはSummaアカウント（以下の定義を参照）を介してユーザからアクセス可能な他の商業広告またはクレジット機関である。
「Summaアカウント（Summa account）」とは、電子的に運営される金融アカウントであり、統合電子メッセージングシステム、あるいは逆に、１またはそれ以上の金融アカウントの電子マネジメントに統合する電子メッセージシステムである。あるいは、Summaアカウントは、１またはそれ以上の金融アカウントに対するクレジットまたはデビットに必要なプログラムと権限を有する電子メッセージシステムからなる。
「Summaクライアント（Summa client）」とは、Summaメッセージ（以下の定義を参照）の作成、送信、受信、読み込みを行い、関連する金融アカウントおよびアカウント記録にアクセスするための、ユーザマシンに常駐するソフトウェアである。
「Summaメッセージ（Summa message）」とは、Summaアカウント間の送金に関する情報を含む電子メッセージであり、送信者から受信者への追加の情報、メッセージまたは添付物を含んでもよい。さらに、Summaメッセージは送金指示に加え、電子テキスト、イメージ、音声、電話通信を含んでもよい。
「ユーザ」とは、ネットワーク上のSummaアカウントにおける人物または商業団体である。あるユーザはSummaメッセージの受信者にも送信者にもなり得る。
（以下の定義を参照）

以上の記述により、本発明は理解され実践される。

本発明の好適な実施例によると、送金手続に先立ち、各Summaユーザは自身のSummaサービスプロバイダに金融アカウントを開設する必要がある。このアカウントは、預金とクレジットラインのいずれかまたは双方を含む必要がある。

ユーザがアクセスし１以上のSummaアカウントを操作するSummaクライアントを通して、ユーザはSummaメッセージの配信を受けるのと引き替えに送信者が受信者に支払わなければならない受信料金の表を規定する。Summaメッセージの配信に際し、Summaアカウントの送信者には合意した金額がデビットされ、この送信者のアカウントにはこの金額がクレジットされ、さらにサービスプロバイダにより課される任意のサービス料金がマイナスされる。

受信者がメッセージ受信料金を集める仕組みを提供するのに加え、本発明はさらに別に資金を２つのSummaアカウント間で転送する安全な方法を提供する。これによりインターネットでの購入、マイクロペイメント、電子インボイスや請求書の支払い、およびユーザが必要とする様々な他の送金が容易になる。この支払いは、Summaアカウント間での直接送金であるため、インターネット上でクレジットカード番号やアカウントナンバーを送信する必要がない。

さらに、ユーザの了承を得た上で、サービスプロバイダは購入の種別を追跡し、各ユーザのマーケティングデータベースに追加する。この利用可能なデータの収集と作成は各ユーザのマーケットアイデンティティの価値を高め、ひいてはユーザが受信料金で受け取る収入を増やすことができる。

このプロセスには以下の利点がある：（１）ユーザは自身の料金表により受信を了承ｓるうメッセージのみを受け取るため、無差別な商業広告または個人メッセージの「スパム」が排除され、（２）受信者は自分の時間とマーケットアイデンティティの価値による収入が得られ、（３）Summaサービスプロバイダは更なるサービスチャージと広告収入が得られ、（４）広告企業はSummaメッセージを介して自身の商業広告の受信に興味のある個人のリストをより簡単に得ることができ、（５）良好なトラッキングと検証により電子送金を安全な方法で実行することができる。

本発明の主たる特徴は、ユーザの信頼が信頼できる、インターネットを用いたユーザフレンドリーな送金システムを提供することにある。

本発明の別の特徴は、ユーザが希望するのと希望しない通信の双方を見るのに費やす時間を大幅に抑制する上記のトランザクションシステムを提供し、ユーザのマーケットアイデンティティから伝わる情報の価値を増大させ、金融トランザクションを実行するのに多大な利便性とセキュリティ性を提供する。

本発明のさらなる別の特徴は、安全なメッセージシステムを電子制御された金融アカウントに接続するトランザクションシステムを提供し、各ユーザが電子メールの一部として第三者に対し金銭の送受信の双方を同じSummaアカウントを用いて可能であり、ユーザが特定の個人、個人グループ、ビジネスのクラスからの電子メールの受信に必要な受信料金表を規定し、ユーザの了承を得たうえで、このユーザによるこの金融アカウントを用いた購入のマーケティング情報を収集し、これを企業に売ることによりユーザが受信料金から得られる収入が増大する。

本発明の別の更なる特徴、利点、利益は、添付図面に関する以下の記載により明確となる。上述の総括的な記述と以下の詳細な説明は例示と説明に過ぎず、本発明を制限するものと解されてはならない。本発明に編入され一部を構成する添付の図面は、本発明の一実施例を図示しているが、記述とともに、本発明の一般的な用語の原則を説明するものである。開示において、同様の部品は同じ番号で参照している。

ここでは、公知の特許システムの幾つかを考慮すべきと考え、その後本発明で得られ従来技術にない利点に話を戻すこととする。

Ｓｕｎｄｓｔｅｄの米国特許５，９９９，９６７は、「固有の」または譲渡可能な価値を有する電子スタンプを表す電子メール添付物を用いた電子メールのフィルタリング方法を開示する。この技術は「ジャンクな電子メールをより有効に識別して処理する」ことを可能にする目的を明確に記載している。この主な特徴は（電子スタンプを介して）スパムに対する経済的なバリヤを生成することにある。この目的のため、電子スタンプは支払いが認められた人物に送信されるべき約束手形であればよい。あるいは、ユーザは第三者トークンプロバイダを通じて譲渡可能な通貨へと償還し交換されるトークンを購入するようにしてもよいと述べている。換言すれば、Ｓｕｎｄｓｔｅｄは送金または個人の時間とマーケットアイデンティティの価値を捉えたよりよい方法を開示するものではない。これに対し、本発明は電子メールに金銭価値を添付するものではないが、代わりに１つの金融アカウントから別のアカウントまで実際のトランザクションあるいは預金を開始し完了する機構を提供することにより、約束手形やＳｕｎｄｓｔｅｄの集金用の宛名のないタスクを越えるものである。これは、Summaメッセージ（すなわち、金融トランザクションとメッセージ）の配信を絶対条件として実現する。特に、Ｓｕｎｄｓｔｅｄは約束手形またはトークンを電子郵便料金に添付される１度きりの使用以外の他のいかなる目的にも用いる構成を持たないことである。事実、彼はいかなるトークンまたは電子情報の再使用も防がなければならないと述べている。Ｓｕｎｄｓｔｅｄが教示する「価値表示」としての電子スタンプは、新たな購入に使用しうる、あるいは請求書に支払ったり、電子郵便料金いに支払える通貨ではない。

Ｃｏｕｎｃｉｌの米国特許６，１９２，１１４と６，５８７，５５０は、未承認の送信者（すなわち、受信者のパススルーあるいはホワイトリストにない人物）に電子メールの配信に先立って支払うべき電子請求書を送信することにより、電子メールをフィルタリングする方法を開示している。また、サービスプロバイダに請求アカウントまたはクレジットカード番号を開設することにより、送信者（多くは、巨大な商業広告主）が配信料金の支払いを予め指示できるようにした。Ｓｕｎｄｓｔｅｄの例と同様に、Ｃｏｕｎｃｉｌは、受信料金の受け取りによるデポジットや、購入、請求書の支払い、他人の受信料金への支払いのための引き出しする資金について金融アカウントを作成する利点の発見に失敗している。カウンシルはまた、特定の送信者または幅広い商業階層について異なる受信料金の表を作成することの利点の発見に失敗している。代わりに、Ｃｏｕｎｃｉｌではユーザが許可送信者のリストを保持することが必要であり、このリストにない請求書送信者を検索する。これに対し、本発明はSummaアカウントにいるすべてのユーザ間の関係を単純化し、ユーザにとって知らない相手でも、自動的にメッセージ送信が予め承認され、配信料金の支払いを徴収するのにいかなる請求プロセスも不要としている。さらに、Ｃｏｕｎｃｉｌはユーザに異なるサービスプロバイダのアカウントを持たせる機構はないが、請求書がすべてこのサービスを提供する一社に支払われることを必要とする。他の特徴は、Ｃｏｕｎｃｉｌは、ユーザの受信コンピュータが電子メールのソースの特定の表示を検出するようプログラムされており、承認された送信者のリストのソースと比較する機能を要する。しかしながら、上述したように、Ｃｏｕｎｃｉｌのシステムでは不正なヘッダを防ぐことができない。もし出所の表示が正当であれば検出する意味がなくなる。これに対し、本発明のシステムでは、Summaネットワークがそれ自体ユーザの同一性を立証するよう構成されているため、受信者のコンピュータが電子メールのソースを検出する必要がない。

図面を参照すると、最初に図１は本発明特有の技術を示しており、ネットワークサーバ３２，３８が電子的な接続３６を介してSummaメッセージを交換するコンピュータネットワークを用いて制御および実現されている。本発明は図面に示す実施例を参照して説明されるが、本発明は様々な代替例または実施例として実現可能であることを理解されたい。本発明の各要素または材料は様々な適切なサイズ、形態、種類であってよい。

図１に示すように、個人ユーザ２０，２２，２４，２６，３０はそれぞれ、少なくとも１のSummaクライアントにアクセスしている。ユーザ２０は、例えば、Summaクライアント２１にアクセスしている。ユーザ２４，２６は、１つはユーザ２４用のuser24@sn1、１つがユーザ２６用のuser26@sn1、１つがユーザ２４，２６双方で共有のjoint@sn1の計３つのアカウントアドレスにSummaメッセージを送受信するよう設定されたSummaクライアント２５が動作する共有コンピュータにアクセスしている。これらのSummaクライアントを介して、ユーザはそれぞれ割り当てられたネットワークサーバ３２、３８と通信する。例えば、Summaクライアント２１はインターネット接続２８を介してネットワークサーバ３２に接続されている。ユーザ２０がユーザ２２宛のメッセージを送信した場合、ネットワークサーバ３２はSummaクライアント２１から受け取るメッセージを、ユーザ２２のSummaクライアント２３が取得するまでメモリに格納する。

異なるサーバのユーザ間でなされるメッセージ交換は、これより僅かに複雑となる。例えば、サーバ３８が管轄するユーザ３０にユーザ２４がメッセージ送信を希望したとする。サーバ３２により、受信者のアドレスであるユーザ３０はサーバ３８が管轄するユーザ宛であることが確認され、ネットワーク接続３６を介してネットワークサーバ３８に中継される。このサーバ３８のメッセージ転送ソフトウェアは、自動的に受信者のアドレスを解析して、このメッセージがユーザ３０に送られるものであることを認識する。メッセージが配信される場合、ユーザのSummaクライアント３１が取得できるようにアクセス可能なファイルとして保存される。

上述の説明は電子メッセージングの当業者であれば一般に理解可能である。本発明は、しかしながら、この共通スキームにさらに別の要素を付加している。すなわち、Summaネットワークサーバはさらに、各ユーザ用の金融アカウントとデータベース３４、４０を保持し、送信者のアカウントに課金され配信にあたり各ユーザにクレジットされる料金表と、Summaメッセージの配信にあたり金融アカウントにクレジット（貸方記入）またはデビット（借方記入）する手段とを備えている。

図２に示すように、ユーザ２０の料金表と消費者プロファイルの一般的な例がデータベース３４に入力され保存されている。本図において、各列は異なる情報カテゴリを示している。説明のために、各列８０〜８８は、別個のファイルを示している。当業者であれば他のデータ構成を考えることができる。図２に示すように、各ファイルの最初の行は、このファイルに登録された情報種別のラベルであり、第２行はユーザ２０の固有の識別子であり、本例では単に「User20 ID」と示し、いくつものファイルにまたがりユーザ２０の適切なデータを識別し、リンクし、アクセスするのに利用される。

本例では、一般情報データファイル８０には、パスワードやデフォルトの受信料金といった標準の情報とともに、ユーザ２０のクレジット、デビット、サービスチャージの合計額が保持されている。個人連絡リストファイル８２は、ユーザ２０が知っているユーザであって、ユーザ２０がデフォルトの受信料金とは異なる受信料金を設定したいと考えるユーザのリストである。受信料金がゼロで示されるすべてのアドレスは、パススルーリストに関連づけされる。消費者プロファイルリスト８４は、ユーザ２０の消費者プロファイルに関するデータを含んでおり、例えば、好き嫌い、製品嗜好、最近の購入歴、人口統計情報などである。宣伝費用リスト８６は、ユーザ２０が規定する様々な種類の商業アカウントに対して適用される料金表を含んでいる。「拒否リスト」ファイル８８は、ユーザ２０が自動的に返却または廃棄を望むユーザアドレスのリストであり、この者が最大の受信チャージを払うといっても考慮されない。

新規のSummaアカウントを開設する場合、あるいはサービスプロバイダや顧客が自身のアカウント設定の変更を希望する場合、Summaアドレスの持ち主は基本の料金表を設定するための電子フォームを完成させるか修正する。図３は、図２に示すデータベースにユーザが提供した情報を登録するソフトウェアサブルーチンの各ステップを示すフローチャートである。これらのステップの順番は特に重要ではない。コンピュータプログラミングの当業者であれば、この処理の様々な変更例を構築できるであろう。本サブルーチンの基本ステップは、このユーザのデフォルトの受信料金を設定し、特定の商業メッセージの種類に課される特定の料金の入力を可能とし、消費者プロファイルを構成する付加情報を入力することである。デフォルトの受信料金以外の受信料金が設定される人物や拒否アドレスの設定は、基本要件に対して付加的な変更となる。これらのリストの特定のアドレスは個々に入力されてもよく、電子メールソフトで共通に用いられているアドレスブックファイルの形でアップロードされてもよい。図２に示すこれらのステップは、収集されてデータベースに保存され、本発明の通常の方法に含まれる料金とクレジットの交換に役立ついかなる種類のデータも除外するものではない。

図４は、サーバのサブルーチンの主要なステップを概説する基本のフローチャートであり、受信者宛に受け取るSummaメッセージを検査して、（１）送信者に適切な料金を課し、受信者にクレジットを提供してSummaメッセージを受信者に配信する、または（２）拒否理由を示す適切な通知とともにメッセージを送信者に返却する。後者は、受信者の常に拒否するメッセージ送信者のリストに送信者が登録されている場合、および送信者がSummaアカウントを有さず、あるいはそのアカウントに十分な資金がない場合に生じうる。受信者の受信料金が、送信者が受信料金として支払いを同意した最大料金を超えている場合にもメッセージは返却される。例えば、ユーザが金融ニュースレターからのメッセージをそれぞれ１０セントで受信するよう設定した場合であって、このような商業メッセージの送信者が受信者ごとに受信料金として７セントしか支払わない通知とともにメッセージを送ると、この送信者は当該メッセージが配信されなかった旨と配信に先立ってこの送信者が支払いを了承すべき適切な料金が示される。この方法により、商業広告メッセージの送信者は自身のコストを正確にコントロールすることができ、さらに自身の最大料金が低すぎた場合にSummaリストのどの部分に問題があるかが分かる。典型的な実施例では、送信者が支払ってもよい最大料金が受信者の受信料金を超えている場合、送信者のアカウントには実際の受信料金のみが課される。

本発明は金融トランザクションおよびクレジットを実行する機構を提供するものであるため、サービスプロバイダは処理費用の請求を希望し、連邦、州や地方自治体もこれらのトランザクションに様々な課税を行うことが考えられる。これは例えば注文ごとにセールスマンのロイヤリティと売り主で利益を分けるように、ビジネスに利益をもたらす構成である資金の分割を含む。収集されたお金が法律、契約、または他の複数のアカウントに分割する同意により求められた場合はいつでも、各トランザクションについて適切な側から適切な金額を差し引いてその料金を（例えば、税金、経費、利益分配として）統制法や契約やユーザの指示により適切なアカウントに入れるようにプログラムするのは簡単な話である。要求に応じて、支払いの一部を受け取るそれぞれの側にオリジナルメッセージのコピーまたは他のメッセージが自動的に生成され送られるようにして、各側の需要に応えるようにしてもよい。このメッセージは、もしあれば、単なるトラック番号または配送アドレスのみであってもよい。この更なる支払いの適用と記録の追加プログラムを付加する処理は当業者であれば容易である。

図４に示す各ステップは、Summaメッセージの配信を制御するすべての他の可能なサブルーチンを排除するものではない。むしろ、このフローチャートは、本発明によりカバーされる本発明の典型的な実施例を示すものに過ぎない。プログラミング技術の当業者であればこのアプローチに容易に様々な変更を施すことができる。

典型的な実施例では、メッセージの安全な配信は、送信者のサーバからの送信要求（ＲＴＳ）と、受信者のサーバからの送信許可（ＰＴＳ）とで達成される。このステップは、Summaメッセージの配信にあたり課金および同一性の証明となる。追加のセキュリティの予防措置として、ＲＴＳはさらに、ＰＴＳの後に受領証として送られるメッセージのハッシュサム（hash sum）を含んでもよい。これにより、受信者のサーバが、受信メッセージが認められたＰＴＳと合致することを確認することができる。ＰＴＳを受信すると、送信者のサーバは、メッセージ配信が成功するまで資金を一時的なエスクローアカウントに転送されるようにする。受信者のサーバから配信証明を受信したら、エスクローの資金は受信者にクレジットされる。

上記の例では、メッセージの配信成功が確認された場合のみ送金が最終的に承認される。代替的に、別の環境では送金が最終的に確認されるまでメッセージを保持するのが望ましい場合もある。どの例を適用するかはメッセージの種類やユーザの選択オプションにより決定されてもよい。さらに、メッセージハッシュといったメッセージ識別情報とともに、Summaメッセージが最初に送信された日時とこれが配信された日時を簡単に記録することができる。この情報は様々な状況において、ユーザが保持する記録のコピーを第三者サービスプロバイダが保持する記録と比較して確認するのに用いる公的な日時スタンプとして利用可能である。

あるSummaサービスプロバイダのユーザから別のサービスプロバイダのユーザへの送金は、各サービスプロバイダにおけるユーザアカウントに保持された資産価値の連続的な遷移を生じさせる。好適な実施例では、サービスプロバイダが金融機関であり、サービスプロバイダ間の差引勘定は、例えば一日の終わりなどに定期的に実行されるＡＣＨに似たトランザクションで調整される。典型的な実施例では、図１に示すように、この処理は、各Summaサービスプロバイダの正確なオーダのネットバランスを出すことが求められる周期的な送金を監視し、計算し、処理する１またはそれ以上の中央情報センタサーバ５０で自動決済される。典型例では、中央情報センタ５０はまた、すべてのSummaサービスプロバイダに対する全ネットワークサーバアドレスのリストを保持しており、各トランザクションは情報センタに受信者のサービスプロバイダのアドレスを問い合わせまたは確認するクエリーで開始される。同様に、受信サーバは情報センタを介して送信サーバの信頼性を確認する。これにより、許可されていないサーバを介するSummaメッセージおよびトランザクションを開始する試みを拒否できる。当業者であれば、この情報センタサーバの動作に匹敵する他の共通のセキュリティおよびデータ収集機能を容易に考えることができる。

図１に示す好適な実施例において、メッセージシステムは、金融機関の電子送金およびアカウントシステムにより構成されている。代替例として、図５では、送金指示を行う外部の電子機材４２を用いてSummaトランザクションを実行している。例えば、ユーザ２０がインターネットバンキングアクセスを提供する銀行４４にアカウントを有する場合、ユーザ２０は自身のユーザＩＤとパスワードを自身のSummaクライアント２１に入力し、これがユーザのサーバ３２が前記インターネットバンキングのインタフェース４２を介してアクセスし選択された銀行のアカウントに送金するのに用いられる。典型例では、これらの送金記録がSummaアカウントデータベース３４に保持される。このような場合、Summaメッセージシステムが実際は銀行の金融アカウントシステム内に組み込まれていないため、金融アカウントへの十分なアクセスと制御がSummaシステムに許可されることにより、本発明の目的を達成するのに必要な送金を完了させることができる。

代替例として、または付加的に、ユーザはSummaメッセージサービスの契約に署名して、ユーザがもつすべてのアカウントへの情報センタ自動決済を許可してもよい。この代替例において、送金手段４２は様々な電子送金手段であってよく、特に限定するものではないが、Summaネットワークサーバが金融アカウント間の送金を手配可能な独立あるいは情報センタ５０と組み合わさったＡＣＨシステム、クレジットカード処理システムである。例えば、あるＡＣＨトランザクションが行われる場合、ユーザが選択したアカウントルーチン番号がこのユーザのSummaクライアントを介して提供される。ＡＣＨトランザクションは通常バッチファイルを用いて処理されるため、それぞれ個別のSummaメッセージごとにＡＣＨの送金オーダを作成する必要はない。例えば、１日のうちに、ユーザ２０がSumma支払いを１０回行い、Summa支払いを１３回受け取り、最終的に＄５．３１を得たとする。この場合、ネットワークサーバは１日の送金記録を各Summaアカウントごとにクレジットとデビットの合計が登録されるデータベース４２に蓄積する。ユーザ２２について２３回ものＡＣＨトランザクションを行うのではなく、ネットワークサーバはその日の終わりに＄５．３１の１回のＡＣＨトランザクションを指示する。このプロセスはＡＣＨトランザクション費用を抑えるのみならず、銀行明細に記載する必要のある金融トランザクションの数を抑えることができる。サービスフィーを含むクレジットとデビットの合計金額は、毎日の終わりに差引勘定されるため、１日の終わりにすべてのSummaアカウントのクレジットを中央金融アカウントに入れるとともに、１日の終わりのすべてのSummaアカウントのデビットを同じ中央金融アカウントから出すことにより、このシステムをさらに単純化することができる。この代替例では、ユーザの毎日の銀行明細には、１日の合計のSummaアカウントのクレジットとデビットを示す１つのＡＣＨトランザクションしか載らないことになる。しかしながら、Summaアカウントデータベースを介して各トランザクション、上記実施例の場合はユーザ２０による１０のSumma支払いと１３のSumma支払いの受領の詳細にアクセス可能である。代替例では、各アカウントの差引勘定を毎日行うのではなく、サービスプロバイダは各ユーザのアカウントのデビットまたはクレジットが、ＡＣＨの費用をかけるのに相応しい、例えば＄２０の最低金額を超えるまで待って差引勘定するようにしてもよい。同様のプロセスを、例えばクレジットカード番号を用いたクレジットラインへのアクセスで行うようにしてもよい。

別の実施例では、図５に示す複数の金融機関４４，４６に金融アカウントを所有する１つのサービスプロバイダのアカウント間でネットバランスのシフトを行ってもよい。４４−４６間のトランザクションを減らすには、ユーザが少なくとも４４または４６において少額を授受するSummaアカウントで制御される自身の金融アカウントを持つ必要がある。この代替例では、ユーザ２２が銀行４４、ユーザ３０が銀行４６を選択し、両者が１のサービスプロバイダが運用するネットワークサーバ３２，３８により運営されるSummaアカウントを有する。Summaユーザの適切な許可により、各銀行のサービスプロバイダのアカウントから、２２−３０間の支払いを銀行間での送金を伴わずに完了することができる。代わりに、２２により支払われた金額が４４でサービスプロバイダのアカウントに入り、４６でサービスプロバイダのアカウントを出て３０のアカウントに入る。これにより、低コストで、２つの銀行間での送金が１つの銀行内での送金で済む。この例では、各銀行の正味の預かり金は手を加えず、ただし各銀行におけるサービスプロバイダのアカウントに反映される。これは、４４，４６におけるサービスプロバイダ自身のアカウント間で、ごくまれにであるが周期的にＡＣＨ送金を行うことにより簡単に実現する。このプロセスもまた、電子送金手段４２内にあるSumma情報センタ５０で実現することができる。

上述の決済シナリオの多くの場合、サービスプロバイダがエスクローアカウントのクレジット（貸方）とデビット（借方）をまとめるのをユーザが許可する必要がある。このエスクローアカウントはネットワークサーバまたは情報センタサーバ５０が保存するファイルの形で存在する。各アカウントの現在のバランスの記録に関連して、ネットワークサーバは現在のエスクローアカウントを用いて貸し越しを防ぐべく十分な資金があるかを確認する。典型例では、このエスクローは２つの部分からなる：ペンディングのトランザクションと完了したトランザクションである。ペンディングトランザクションは、おそらくまだ受信者にSummaメッセージがダウンロードされていないため配信キューにあるが未送信のSummaメッセージの配信に伴い支払いに回される資金を含む。ペンディングトランザクションで支払いが追認された資金はエスクローにより確保され、送受信ができなくなる。（ａ）配信が拒否された場合、（ｂ）送信者が配信をキャンセルした場合、（ｃ）送信者が配信要求してからタイムリミットを設けて取りやめるオプションを選択している場合、このメッセージについて寄託された資金は送信者のアカウントに戻される。それ以外の場合、ネットワークサーバが配信許可を受領したら、送信者のエスクローアカウントにおいてペンディングデビットを追認済みデビットに変更するとともに、受信者のアカウントに追認済みクレジットを記録することにより、送信者と受信者間の支払いが実行される。前日の決算バランスに当日の追認されたクレジットと、ペンディングと追認の双方の控除額とを加算して、ネットワークサーバはSummaユーザにリアルタイムの自由になる資金の差引勘定を提供することができる。前述のように、１日の終わりのバッチファイルは、金融機関またはサービスプロバイダが保持するネットデポジットに移すのに用いてもよい。この例では、１日の終わりのバッチ送金は、エスクローアカウントにある追認済みデビットと追認済みクレジットの累加を含む。すべてのペンディングトランザクションが、配信、キャンセル、Summaメッセージの拒否があるまでエスクローアカウントに保持される。

本発明の他の重要な特徴は、ユーザの許可を得た上で、サービスプロバイダがさらに購入種別を追跡し各ユーザについて作成されたマーケティングデータベースに追加する。ユーザが調査票に記入することにより、さらなるマーケティング情報が収集される。人物データ、購入歴、調査データはネットワークサーバに保存され、或いは中央情報センタまたはマーケティングデータ５０を蓄積する中央データセンタに送られる。このように取得されるデータの収集と作成は、各ユーザのマーケットアイデンティティの価値を向上し、このユーザが受信料金として得られる収入が増えることになる。

伝統的に、例えば、ある消費者がある製品を購入すると、その人物は売り主からしばしば更なる製品案内を受け取る場合がある。さらに、その人物へ連絡するための情報や購入者プロファイルが他の企業に売られ、これが消費者ではなく売り主の利益となる。これに対し、Summa購入では消費者を「熱い期待」で注目しているため、買い手により向上したマーケットの独自性の金銭的利益は、Summaメッセージを介して配信される追加の案内を受ける際に、必要な受信チャージを受け取る消費者に与えられる。ユーザのSummaアカウントの価値を最大限とするために、マーケティングデータの使用はSummaメッセージを介して案内する場合に制限される。代替例では、サービスプロバイダはマーケティング情報を販売し、消費者のメールアドレスまたは電話番号を含むデータを企業が購入するごとに各Summaユーザにクレジットするブローカーとして動作してもよい。マーケティングデータが電子データベースに収集されたら、選択条件をプログラムに入力することにより企業が求めるリストを抽出して提供することは容易である。このようなデータ採取はプログラミングの当業者であれば通常の作業であり、労力となるものではない。さらに、ネットワーク設計の当業者であれば情報センタや情報マーケティング用の中央データベースを、上記のシステムの機能を妥協することなく、別個にあるいは組み合わせられることを直ちに理解するであろう。

上記の一般的な説明と以降の詳細な説明は説明用の例示であって、本発明を何ら限定するものではない。この開示において、金融アカウントとメッセージアカウントをリンクさせ、受信料金を設定し、クレジットとデビットを追跡することは、コンピュータネットワークプログラミング、データベースプログラミング、電子メールプログラミングの当業者であればこのプロセスを実現する多数の方法を考えることができる。

＜基本発明の詳細＞
本発明の本質は、ネットワークサーバを介して金融アカウント同士を関連づけたことにあり、金融アカウントは安全な電子メッセージサービスにより制御され、ユーザが送金したり受信料金を得たりすることができる。一旦このメカニズムが実現すれば、当業者であれば特定のアプリケーションに役立つ追加の変更を施すことができる。これらの追加の特徴は、このプロセスを実現し追加の機能をもたらすSummaメッセージに含まれるヘッダにより実現される。以下に記載するような変更例を通じて、実際に伝統的な事務手続で行われる様々なビジネスまたはアカウント手法が実現し、さらに有効となるよう変更され、一方でユーザに自身の通信と金融トランザクションを強力に制御できるようにしている。

第１に、上述したように、このヘッダは受信料金として送信者が支払える最大金額を特定するフィールドを備える。この最大金額が、例えば、１０セントであり、受信者のこの商業カテゴリのメッセージ受信にかかる受信料金が５セントである場合、送信者のアカウントに５セントのみチャージされ、これが受信者にクレジットされる。他方、受信者の受信料金が２０セントの場合、メッセージは配信されず、送信者には高い配信料金のことが通知される。

第２に、ヘッダは、送信者のSummaメッセージが分類される商業カテゴリの識別子を含むと便利である。契約上の同意により、ユーザ（受信者と送信者の双方を含む）は、公告案内の厳密な分類に用いる情報を提供し、この分類システムの決定に拘束される。

第３に、ヘッダ部分は、受信者が受け取ったメッセージに返信した場合にチャージされる金額を特定している。商業的アプリケーションにおいて、例えば、受信者には送信者にさらなる情報の問い合わせを返信した場合には何もチャージされないことが通知される。代替例では、送信者は、返信することにより受信者に案内した製品の購入金額と同じ金額をチャージするよう設定することができる。これにより、（案内と承諾返信の）２つのSummaメッセージを交換することで、金融トランザクションを実行することができる。この返信のチャージは、通常の受信チャージとは異なってよいが、所定期間経過後には通常の受信チャージと同じとなってもよい。

第４に、ヘッダは、受信者のSummaアカウントに全部送られる全部の送金クレジット金額を特定するさらなるフィールドを備えてもよい。このように構成すると、たとえ受信者の受信チャージが指定された全部の送金クレジット金額より少ない場合であっても、この全部の送金クレジット金額が送金される。この方法により送信者は、支払い、製品購入、返金、金銭ギフト、または送金を伴う他の目的のために、Summaアカウントすべてのユーザに送金することができる。

第５に、ヘッダは、特定の方法で表示あるいは処理されるべきメッセージの種類を特定する情報を含んでもよい。本例によれば、請求書の種類としてタグ付けられたメッセージは、請求書のアイテム番号、明細、数量、単価、合計金額が、受信者の会計ソフトウェアで自動的に取得されるよう構成される。ＸＭＬやＸＨＴＭＬフォーマット言語をこの目的に簡単に用いることができる。Summaクライアントは、この請求書ヘッダを認識し、ユーザにこのメッセージを請求書として表示し、以下のオプションを提示する（１）請求金額と同額のクレジットを全部転送する指示を出すことにより全額支払う、（２）請求額の一部を支払う、（３）請求書に異論がある旨の返信を行う。オリジナルメッセージのヘッダを用いて、返信メッセージに自動的に請求書番号や他の情報を標準のフォーマットで含め、送信者の会計ソフトで適切な計算の調整が行われるようにすることができる。同様に、契約書タイプのドキュメントを、「署名・送信」ボタン付きで表示させ、受信者がこのドキュメントに電子署名し、デジタル識別子とともに署名済みドキュメントを送信者に返信できるようにしてもよい。他にも様々なドキュメントタイプがあり、購入オーダー、スプレッドシート、調査や世論調査、ページ分けした電子ブック、申請書、納税書、全部または一部が音声または映像ファイルのドキュメントや所定の方法で処理されるべき実行コード、ビジネス・政府・非営利・プライベートなトランザクションで通常用いられる様々な種類のフォームを含む。

第６に、ヘッダは、単にネットワークサーバを特定し、予定する受信者の受信料金の通知を送信者が求めるために用いられてもよい。この「料金問い合わせ」メッセージは、この予定の受信者には配信されず、単にSumma配信サブルーチンから前記受信者の正しい料金を、たとえ料金がゼロである場合にも、通知する自動返信を生成させるのに用いられる。サービスプロバイダはこの問い合わせのために料金情報を収集するようにする。

第７に、図２の各ユーザのデータベースに更なる構成を付加して、広告メッセージの数、受信により希望する収入額、本当に必要な広告メッセージの「呼び込み」をさらに制御するようにしてもよい。例えば、ユーザは特定の商業分類から１週間または１月に受信を希望するSummaメッセージの最大数を指定することができる。例えば、ユーザが１週間に芝の肥料の広告を何ダースも受信し、実際に興味はあるのだがこれらに当惑した場合、彼はこのようなメッセージは週に６通までとする制限を自身の料金表のある欄に入力するようにしてもよい。あるいは、ネットワークサーバは、このようなすべてのSummaメッセージを毎週待ち行列に入れ、週末に受信料金が高い順に６通の広告を配信するよう設定することができる。この方法によれば、広告主は潜在顧客の関心に対し「競る」ことができる。逆に、あるユーザは各週に受信料金で得たい最低金額を設定することができる。この所望金額を最後まで満たさない場合、ネットワークサーバは、ユーザが通常要求する受信チャージより少ないと認められるがより高い入札者から受信し、さらに受信者がこれらの申し出のレートで受信を望むまで待ち行列のメッセージを残すように設定することができる。同様に、広告主は彼らの選択条件に合致するSummaユーザ全員へのメッセージの配信を事前指定するようにしてもよい。例えば、料理本の売り主は事前に、調理器具を購入したユーザにその後直ちに、または所定の期間の後、広告が送信されるようにすることができる。事前指定されたSummaメッセージによると、ユーザが必要なときにマーケティング情報を呼び出すことが可能となる。例えば、ユーザはいつも住宅ローン金利に興味があるわけではないが、時によりよい住宅ローン金利を探すのに非常に関心がある場合がある。通常、住宅ローン情報の受信を防ぐには、高い受信料金を設定する。競合数社から情報を受けたくなった場合には、彼は受信料金をより適切なレベルまで引き下げることができる。さらに、Summaクライアントは、「関心の告知」（Announcement of Interest：ＡＩ）または対象物を特定して情報や入札や見積りを示す「入札要求」を示す特定のドキュメント種別を提供してもよい。別の代替例では、このＡＩは、ＡＩが自身の関心カテゴリにある場合に配信を要求するすべての商業Summaユーザに放送されてもよい。あるいは、このＡＩは、ＡＩの要求が事前指定されたメッセージと合致する中央サーバで処理され、商業Summaユーザは合致するすべてのＡＩ要求に返信するよう準備している。これらの送受信において、消費者と商業ユーザは自身でよいと思う最大の配信料金または受信料金を設定する。もちろん、サービスプロバイダも更なる課金を適用することができる。

第８に、本発明はさらに、幾重にも及ぶマーケティング努力を容易にしている。例えば、サウナを販売する企業が、１００万もの人間への「適格な」メール送信において潜在顧客ごとに５セントのみを支払うことを希望するとする。このメッセージは企業が何を案内するかと、受信者が最初のメッセージを読んだ後に「ここをクリック」してこの企業の製品をさらに検討するまでに興味をもった場合に＄５の追加クレジットを約束する旨が説明されている。「ここをクリック」のリンクを操作すると、ユーザのSummaクライアントは更なる情報の要求を自動的に送信者に送信する。送信者はその後、例えばビデオクリップと、約束の＄５のクレジット全部送金とが添付され、情報が追加された第２のSummaメッセージを返信する。代替例では、この顧客にこの会社のインターネットサイトの特定のページへとクリックする指示が出されてもよく、ここで広告情報と、ユーザが＄５のクレジットが送信されるべきSummaアカウント情報を含む入力フォームとを表示する。

第９に、他の変形例として、ユーザが受信料金に負の数字を設定可能とすることがある。これは予約支払いを意味し、受信者がSummaメッセージを受信するごとに送信者への支払いを認めるものである。これは、例えばニュースレターの発行への支払い手段として利用することができる。この負の受信料金は、送信者の最大受信料金の欄にある負の受信料金と比較される。受信者が設定した料金が十分でなければ、このニュースレターは配信されない。この方法により、ユーザはこの負の数字を正の数字に変更することにより容易に購読を取りやめることができ、情報提供者は発行ごとに確実に料金を収集することができる。

第１０に、セキュリティを強化するために、Summaメッセージの送信は、通常の電子メールクライアントやサーバで用いているＰＯＰ３やＳＭＴＰの方法とは大きく異なる通信プロトコルを含む。典型的な実施例では、SummaクライアントとSummaネットワークサーバ間、およびSummaネットワークサーバ同士の間では、暗号化、圧縮、送信要求、送信許可、呼びかけと応答、メッセージハッシュ、機関による証明、ＩＤ認証、およびコンピュータセキュリティ専門家にとってよく知られた他の技術を用いる。これらの技術は単独で、あるいは組み合わせて用い、身元確認された送信者から確実に送金され、また受信者宛の送金およびメッセージが秘密に行われるようにしている。特定のSummaクライアントはSummaメッセージをこの安全なプロトコルで作成する必要があるが、このSummaクライアントはまた、ＰＯＰ３／ＳＭＴＰ電子メールの作成、ダウンロード、読み込みもできるようプログラムされる。この後退的な両立しうる機能性により、Summaユーザは、パススルーリストにあるSummaアカウントを有さない人物からのＰＯＰ３の電子メールを継続的に受信することができ、また自分のSummaクライアントから同じ人物にＳＭＴＰメッセージを送信することができる。

第１１に、Summaアカウントデータベース３４、４０に登録されたマーケティングデータは、企業がもっとも商業広告の送信を希望するSummaユーザの部分集合を特定するデータマイニング、分離、選択に役立つものである。本発明によれば、このマーケティングデータは、個々のSummaネットワークサーバを介して作成されてもよく、あるいは企業がここからデータを抽出する中央データベースに収集されてもよい。このようなデータベースからのデータの編集、検索、分類は当業者にとって公知であり、追加の労力を伴うものではない。

第１２に、ＨＴＭＬが電子メールクライアントに所定のアドレスにメッセージを送信するよう電子メールを送信する機構を提供するのと同様に、特別なウェブページプログラミングを用いて、所定のユーザに所定のクレジットを送るSummaメッセージを送信するハイパーリンクを提供することができる。買い手と売り手は単にSummaアカウントを有するだけでよい。Summaハイパーリンクのプログラミングは、大抵は送信者に購入される製品を特定するメッセージ情報を含み送信者への支払いを認めるSummaメッセージを送信することを含む。典型的な実施例において、買い手が購入を了承する場合、大体がパスワードを入力すると、Summaトランザクションが実行される。配送先住所が必要な場合、これは自動的に売り手のデータベースから提供される。この方法により、コンタクト情報を記入したりクレジットカード番号を示す必要がなくなり、インターネットでの購入を簡単にする手段が提供される。同様の方法をマイクロペイメントシステムにも適用できる。例えば、価値のある情報を含むウェブページにアクセスするためには、特別のハイパーリンクに次に進む場合の費用を表示し、これが実行された場合、ユーザを所望のページに移し、要求される数セントあるいは１セント未満のSumma支払いを了承する。本例では、ユーザは通常最大料金として、このユーザがパスワードを伴う購入手続を行うことなく支払ってもよい金額、例えば５セントを設定する。この方法により、Summaアカウントのユーザはコンテンツのブラウジングにマイクロペイメントが必要なウェブアクセスを簡単に行うことができる。

第１３に、多くのアプリケーションにおいて、デジタル証明（ＤＩ）を提供または要求することが有効である。例えば、送信者から契約要求や税金の申請と支払いとともにＤＩを送付したりする。この場合、送信者は単にSummaメッセージにＤＩを添付するオプションを選択するだけでよく、受信者はメッセージがＤＩ付きか否かを見ることができる。反対に、送信者が受信者に、Summaメッセージの送信に先立ってＤＩを要求してもよい。これは、書留郵便を送ったり法的通知をしたりする際に、受信者が受け取るにあたり署名するしたり公的な証明や会社のＩＤを提示するのと同じである。この要素を追加することにより、Summaメッセージの送信者は一般的なあるいは特定のＤＩを用意して配信される状況を整える選択がある。ＤＩを提供するタスクは自動化あるいは半自動化される。最も典型的には、受信者は電子的に１以上のデジタル証明を自身のSummaクライアントまたはネットワークサーバに登録しておき、いつでも使用できるようにする。例えば、送信者はSummaメッセージの配信の前に、デジタル証明および／または特定のＣＡの形の身元確認を要求してもよい。この例では、メッセージは保持キューに入れられ、ネットワークサーバが求められているＤＩを受信者のネットワークサーバに要求する。受信者が彼の側で自動的にＤＩ要求を満たすよう構成されている場合、受信者のネットワークサーバは自動的にＤＩを」送信者のネットワークサーバに送出する。必要に応じて、送信者または送信者ネットワーク発行団体の公開鍵を用いてＣＡの信頼を確認してもよい。受信者の信頼性が確認されたら、キューのSummaメッセージがその後開放され、通常の状態で配信される。あるいは、サーバから要求された場合または受信者の選択により、適切なボタンまたはアイコンをクリックしてＤＩを送る許可がマニュアルで行われ、その都度受信者が配信を認めた場合にのみＤＩが送られるようにしてもよい。この例では、受信者は現時点ではオリジナルのSummaメッセージを受け取っておらず、ＤＩを要求する通知のみ受け取り、これには要求者の名前が含まれていてもよい。典型例では、キューに入れられたメッセージの配信に先立つＤＩの要求通知は、表示すると容易に要求に応えられるボタンを含む特別なドキュメント形式で扱われる。この要求は、しかしながら、適当な受信料金が課される別個のSummaメッセージとして扱われてもよい。

第１４に、他の金融トランザクションから購入嗜好の情報をさらに付加することにより、収集されたマーケティングデータの価値をさらに高め、これによりユーザが受信料金で受け取れる収入を増大することが可能である。例えば、購入時にデビットまたはクレジットカードセールスで通常収集されるデータを各ユーザのデーターベースにリンクすることができる。あるいは、サービスプロバイダが発行する新たなクレジットまたはデビットカードを、小売店の精算レーンに設けた専用のトランザクション端末におけるSummaトランザクションの認証に用いるトークンまたはスマートカードとして利用することができる。この場合、トークンは端末で認証される暗号化したＣＡを含み、さらにユーザパスワードを入力する構成であってもよい。ユーザがこの売買の認証を行うと、端末は代金を支払いネットワークサーバのユーザの購入品のリストをアップロードするSummaメッセージを生成する。この例では、精算端末は単に、適切な暗号トークンとパスワードで端末に識別される様々なユーザからアクセス可能な専用のSummaクライアントとして動作する。同じトークンを、Summaネットワークが「いつもの」アクセスポイントでないと判断したネットワークデバイスからユーザが自身のSummaアカウントへのアクセスを希望した場合に追加のセキュリティの予防措置に用いてもよい。価値のあるマーケティングデータが蓄積される金融トランザクションを遂行する上記の手段あるいは同様のスキームは、電子技術の当業者であれば容易に実現できる。本発明は、マーケティングデータが消費者の利益のために蓄積される点で無比のものである。

最後に、このシステムはネットワークサーバとSummaクライアントの手段により効果的に実現することができるが、プログラミング技術の当業者であれば本発明を通常の方法でサーバベースのアプリケーションソフトウェアまたはウェブベースのサイトのいずれでも容易に実現することができ、これによりOutlook Expressを用いる代わりにウェブベースの電子メールサイトであるHotmailと類似の方法を用いて、ネットワークサーバに保存された電子メールを見ることができる。

＜付加的な派生＞
本発明は、ビジネスにおける多くの新規な方法とモデルを紹介するものである。例えば、インターネットサービスプロバイダは、入会金をなくし、代わりにユーザの受信料金または送金に対するサービスフィーを課すことができる。テクニカルサポートセンタは、ヘルプリクエストに対する前払いを徴収するのにSummaアカウントを用いることができる。企業は雇用者に対してSummaアカウントの受信料金を設定し、外部から雇用者に対する接触の対価を徴収してもよい。この収入は雇用者に通信手段を提供し顧客から更なる価値を生じさせるコストと相殺するのに用いることができる。

コンピュータプログラミングの当業者であれば、Summaアカウントを多くの通常のビジネス形態に適するように容易にプログラムすることができる。例えば、Summaアカウントは複数とし、１人のユーザアドレスでいくつもの金融アカウントにリンクさせることができる。この場合、ユーザは自身のメッセージのすべてを取得するのに単一のSummaクライアントを有するが、Summaメッセージを送信する場合にユーザは複数の金融アカウントから受信料金または他の支払いを引き落とす口座を選択することができる。反対に、例えば夫婦といった複数ユーザのユーザアドレスが同じ金融アカウントにリンクされてもよい。このシステムでは、２以上のユーザに支払いの了承を要求するように簡単に変更可能である。例えば、電子的なSumma請求書を企業の会計士に送信することもできる。この請求書を確認したら、会計士は支払いを指示するが、メッセージは受信者に直接送られるのではなく、代わりに自動的にこの会計士の「共同署名人」、すなわち企業のオーナーに回される。この支払い情報を含むSummaメッセージは、企業オーナーが配信を許可してからのみ送信されるようにしてもよい。

すべてのSummaアカウントの記録は電子フォーマットであるため、この会計情報は容易に会計ソフトウェアで読み込みあるいはインポートすることができる。あるいは、会計ソフトをSummaクライアントに組み込むようにしてもよい。本発明の教示を考察するにあたり、プログラミングと会計技術の当業者であれば、複数のアカウント、複数の署名者、歳入と支出の追跡、顧客履歴の収集等は容易に実現可能であり、通常のまたは特別目的のSummaアカウントを制御するプログラミングを僅かに変更して変形例とすることができる。

＜結論＞
本発明が開示する技術は、以下の効果を有する：
・ユーザのアイデンティティと時間の価値を向上し、受信する電子メッセージの種類と量に対する多大なる制御をユーザに提供する。
・受信する電子メールメッセージの量と質を統制し、ユーザの収入を生成する実践的な方法がなかった従来技術の欠点を修正する。
・ユーザが望まない電子メールメッセージが殺到するおそれから電子メールアドレスを秘密に保つ衝動を低減し、アドレスを公共で記載できるようにして適切な連絡を受けやすくする。
・ユーザとサービスプロバイダ間の技術的かつ契約によるビジネス関係のシステムを通じたコンピュータネットワークを介する金融トランザクションを実行する新たな方法を提供する。
・商業的電子メールメッセージング、顧客需要の特定、およびユーザが望まない電子メールメッセージにより「苦しめられている」気持ちを取り除くことよる企業と顧客の関係向上のためよりオープンな構成を提供する。
・サービスプロバイダに新たな収入源を提供し、サービスのコストを低減し、電話会社、銀行、クレジットカード会社で用いられるモデルに沿ったビジネス展開の新たな道を開く。

上記の説明は、多くの実施例と精密な例を含んでいるが、これらは本発明の範囲を限定するものとして解釈してはならず、単に本発明を実現する原理を示すにすぎないと解されるべきである。この開示により、このプロセスをユーザやサービスプロバイダの個々の需要に合わせて変更することは当業者であれば容易である。例えば、Summaクライアントは携帯電話機や他のネットワーク電子デバイスであってもよい。同様に、受信料金は電話着信や他の形態の電子メッセージの受信に適用してもよい。

このように、上記は本発明の原理が示されていると解すべきであり、いかなる限定をするものではない。当業者であれば多数の変形例や変更例が可能である。このため、本発明はここに図示し説明した同一の構成に限る趣旨ではなく、したがって、コンピュータの周辺機器にアクセスを制限するユーザがアクセス可能なスイッチを用いるすべての変形例や均等物は本発明の範囲に含まれる。

図１は、すべて本発明にかかる、Summaユーザ、ネットワークサーバ、各ユーザのSummaアカウントに関連するデータベースの関係を示すブロック図である。 図２は、本発明に係るユーザアカウントに関連するデータベースに保持された情報の種類の一例を示すスプレッドシートである。 図３は、ユーザが用いる本発明のソフトウェアサブルーチンの簡単なフローチャートであり、このユーザにメッセージを送信したい人物により要求されるチャージ表を設定するものである。 図４は、ネットワークサーバが用いる本発明のソフトウェアサブルーチンの一例を示すフローチャートであり、１つのサーバが担当する１人のユーザから他のサーバが担当する別のユーザへのSummaメッセージの送信の扱いを決定するものである。 図５は図１と似たブロック図であるが、金融アカウントが本発明にかかるSummaネットワークデータベースの外にあり、外部の金融機関が保持するユーザの金融アカウントに対する電子オーダー送金への承認とアクセスによりどのようにして送金を完了する機能を設けるかを示している。

Claims (27)

1. 複数のユーザアカウントを有する金融トランザクションと電子メッセージングシステムの運用方法であって、このシステムは第１のユーザ、第２のユーザ、および第３のユーザをそれぞれ第１、第２および第３のネットワーク接続デバイスで接続し、前記ユーザはそれぞれシステム上に第１、第２および第３のアカウントを有し、各デバイスは１以上のネットワークサーバにアクセスして前記アカウントに関連する情報を含むファイルを保存または取得可能であり、
   （ａ）各ユーザアカウントはSummaアカウントを有し、各Summaアカウントはデビットとクレジットの双方が可能な金融アカウントおよびメッセージングシステムを具え、
   （ｂ）第１のユーザアカウントを送信者とし、第２のユーザアカウントを受信者として、メッセージ部と料金割り当て部とを含むSummaメッセージを送信するステップと、
   （ｃ）前記第２のユーザアカウントに前記メッセージ部を配信するとともに、当該メッセージ部の送達の確認がとれた場合にのみ、前記料金割り当て部にかかる資金を前記第２のユーザアカウントに移転させるステップと、
   （ｄ）第２のユーザアカウントを送信者とし、第３のユーザアカウントを受信者として、第２のメッセージ部と第２の料金割り当て部とを含む第２のSummaメッセージを送信するステップと、
   （ｅ）前記第３のユーザアカウントに前記第２のメッセージ部分を配信するとともに、当該第２のメッセージ部の送達の確認がとれた場合にのみ、前記第２の料金割り当て部にかかる資金を前記第３のユーザアカウントに移転させるステップと、
   （ｆ）各Summaメッセージの送信者に、前記受信者が前記Summaメッセージに返信することを選択した場合に前記送信者が要求する返信料金を指定するよう促すステップと、
   （ｇ）前記受信者に、前記Summaメッセージへの返信に前記送信者が要求する返信料金を通知するステップと、
   （ｈ）前記返信を配信する際に前記返信料金の支払いを前記受信者から前記送信者へ移転させるステップと
   を前記１以上のネットワークサーバが実行することを特徴とする方法。
2. 請求項１の方法において、前記ステップ（ｃ）の前に、前記１以上のネットワークサーバが、
   （ｉ）前記第１のユーザアカウントにおける利用可能な資金が対応する料金割り当て部のものより少ないと判明した場合に、前記Summaメッセージの配信を拒否するステップと、
   （ｊ）前記送信者に、前記Summaメッセージの配信は資金不足により拒否されたことを通知するステップとを具えることを特徴とする方法。
3. 請求項１に記載の方法において、前記ステップ（ｃ）の前に、前記１以上のネットワークサーバが、
   （ｉ）１以上のアカウントのユーザに、当該アカウント宛のSummaメッセージの受信に際しての１以上の受信料金を決定させるステップを具えるとともに、前記ステップ（ｂ）が、
   （ｊ）前記受信者が要求する受信料の支払いに適用されるべき認定資金の少なくとも一部を提供するステップとを備えることを特徴とする方法。
4. 請求項３に記載の方法において、前記ステップ（ｉ）が、前記１以上のネットワークサーバが、
   （ｋ）第１のカテゴリに属する第１の送信者群に要求される第１の受信料金と、第２のカテゴリに属する第２の送信者群に要求される第２の受信料金とを設定するステップを備え、前記ステップ（ｃ）が、前記１以上のネットワークサーバが、
   （ｌ）前記送信者が前記第１のカテゴリのメンバーであると判明した場合に、前記Summaメッセージの配信時に、前記送信者の第１のカテゴリに要求される受信料金の支払いを転送するステップと、
   （ｍ）送信者が前記第２のカテゴリのメンバーであると判明した場合に、前記Summaメッセージの配信時に、前記送信者の第２のカテゴリに要求される受信料金の支払いを転送するステップとを具えることを特徴とする方法。
5. 請求項４に記載の方法において、前記ステップ（ｃ）の前に、前記１以上のネットワークサーバが、
   （ｎ）前記送信者に、当該送信者のカテゴリを特定するのに用いる情報を提供するよう促すステップを具え、
   前記ステップ（ｌ）と（ｍ）が、ステップ（ｎ）で提供された情報に基づいて遂行されることを特徴とする方法。
6. 請求項３に記載の方法において、前記ステップ（ｃ）で前記第２のユーザアカウントに転送される資金は、前記受信料金の金額のみと等しく、
   （ｋ）前記１以上のネットワークサーバが、前記第１のユーザアカウントからの引き落としが認められた資金の余剰分を、前記第１のユーザアカウントに戻すステップを具えることを特徴とする方法。
7. 請求項３に記載の方法において、前記ステップ（ｃ）の前に、前記１以上のネットワークサーバが、
   （ｋ）前記Summaメッセージの送信者に、前記受信料金の支払いとして適用を認める最大配信料金を設定するよう促すステップと、
   （ｌ）ここで認めた最大料金が前記受信料金より低い場合に前記ユーザメッセージを拒否するステップと、
   （ｍ）ここで認めた最大料金が前記受信料金の支払いに足りる場合に前記Summaメッセージの処理を進めるステップとを具えることを特徴とする方法。
8. 請求項７に記載の方法において、前記ステップ（ｃ）の前に、前記１以上のネットワークサーバが、
   （ｎ）各アカウントの少なくとも１のオーナーに、第１のカテゴリに属する第１の送信者群にかかる第１の必要な最小受信料金を設定し、第２のカテゴリに属する第２の送信者群にかかる第２の必要な最小受信料金を設定するよう促すステップと、
   （ｏ）各アカウントの少なくとも１のオーナーに、受信者によって予め設定された期間中に、前記第１のカテゴリの送信者から受信者が受け取りを希望するSummaメッセージの最大数と、前記第２のカテゴリの送信者から受信者が受け取りを希望するSummaメッセージの最大数とを設定するよう促すステップと、
   （ｐ）前記第１のカテゴリの送信者から送信されたSummaメッセージに関して認められた最大料金が必要な受信料金に足る場合、配信について最大の配信料金で処理された前記第１のカテゴリの送信者からの受信を希望する受信者のSummaメッセージの最大数に前記Summaメッセージの数が等しくなった後の前記Summaメッセージを前記受信者により予め設定された期間まで保持するステップと、
   （ｑ）前記第２のカテゴリの送信者から送信されたSummaメッセージに関して認められた最大料金が必要な受信料金に足る場合、配信について最大の配信料金で処理された前記第２のカテゴリの送信者からの受信を希望する受信者のSummaメッセージの最大数に前記Summaメッセージの数が等しくなった後の前記Summaメッセージを前記受信者により予め設定された期間まで保持するステップと、を具えることを特徴とする方法。
9. 請求項３に記載の方法において、前記ステップ（ｃ）の前に、前記１以上のネットワークサーバが、
   （ｋ）前記Summaメッセージの送信者に、前記受信料金の支払いとして適用を認める最大配信料金を設定するよう促すステップと、
   （ｌ）各アカウントの１以上のオーナーに、所定期間内に、１以上の所定の送信者群により支払われた配信料金から希望する最小限レベルの収入を規定するよう促すステップと、
   （ｍ）前記所定の送信者群内の少なくとも１の送信者により開始されたSummaメッセージに応答して、前記認めた最大料金が必要な受信料金の支払いに足る場合に前記Summaメッセージを処理し、所定期間内に前記送信者群から集められた受信料金の記録（tally）を蓄積するステップと、
   （ｎ）所定の群における１以上の送信者が開始したSummaメッセージに応答して、最大受信料金が必要な受信料金より低い場合に、前記Summaメッセージを入札キューに保持するステップと、
   （ｏ）前記所定期間経過後に、前記入札キューに保持されたSummaメッセージの最小数のみを前記受信者に配送するステップであって、前記認められた配信料金が前記所定期間内に既に集められた受信料金の記録に追加され、前記希望する最小限の収入とほぼ等しいかこれ以上である場合に、ここで配送されるよう選択されたSummaメッセージは認められた最大配信料金が最も高いもののみであるステップと、
   （ｐ）前記認められた最大配信料金を、ステップ（ｏ）における入札キューからの各メッセージ配信に必要な支払いの全部として受け付けられるようにするステップと、を備えることを特徴とする方法。
10. 請求項３に記載の方法において、前記ステップ（ｃ）の前に、前記１以上のネットワークサーバが、
    （ｋ）各アカウントの１以上のオーナーに、１以上の送信者から受信する１以上のSummaメッセージの受信にかかる１以上の受信料金を設定するよう促すステップを具え、
    さらに前記ステップ（ｃ）において、
    （ｌ）前記受信料金として認められた資金の少なくとも一部を前記第１のユーザアカウントに移転するステップを備えることを特徴とする方法。
11. 請求項１に記載の方法において、前記１以上のネットワークサーバが、
    （ｍ）法律、契約、あるいはユーザに規定されたトランザクション管理の要求により、前記認められた資金の少なくとも一部を差し引く（deduct）するステップと、
    （ｎ）ここで差し引いた資金を、前記法律、契約、あるいはユーザに規定されたトランザクション管理により指定された金融アカウントに預けるステップと、を備えることを特徴とする方法。
12. 請求項１に記載の方法において、前記ステップ（ｃ）の前に、前記１以上のネットワークサーバが、
    （ｋ）支払われるべき金額を前記Summaメッセージ未配信のエスクローアカウントに入れるステップと、
    （ｌ）前記Summaメッセージが配信されなかった場合に前記エスクローアカウントに移した金額を引き落としたアカウントに戻すステップとを備えることを特徴とする方法。
13. 請求項１に記載の方法において、前記１以上のネットワークサーバが、
    （ｋ）各Summaアカウントの１以上のオーナーによる購入の記録をファイルに記録するステップを備えることを特徴とする方法。
14. 請求項１に記載の方法において、前記１以上のネットワークサーバが、
    （ｉ）１以上のマーケティングメッセージを最も受容的と考えられる１以上のユーザを特定するのに有用な、１以上のアカウントの１以上のユーザに関する情報からなるマーケティングデータベースをファイル内に保存するステップと、
    （ｊ）前記１以上のマーケティングメッセージの１以上の送信者に、前記マーケティングデータベースからマーケティングの提案をユーザ最も受容的と考えられる１以上のユーザのリストを特定するよう促すステップと、
    （ｋ）前記マーケティングメッセージの送信者からのマーケティングメッセージを記載したSummaメッセージを、前記選択された１以上のユーザのリストに送信するステップとを備えることを特徴とする方法。
15. 請求項１に記載の方法において、前記ステップ（ｃ）の前に、前記１以上のネットワークサーバが、
    （ｋ）１以上のマーケティングメッセージを最も受容的と考えられる１以上のユーザを特定するのに有用な、１以上のアカウントの１以上のユーザに関する情報からなるマーケティングデータベースをファイル内に保存するステップと、
    （ｌ）前記マーケティングメッセージの１以上の送信者に、１以上のユーザに関する情報が前記送信者が予め規定された１以上の条件に合致する場合に、１以上のSummaメッセージの送信を予め承認するよう促すステップと、
    （ｍ）前記ユーザに関し収集された情報が前記送信者により予め規定された条件に合致する場合に、１以上の予め承認されたSummaメッセージを、前記１以上のユーザに送信するステップとを備えることを特徴とする方法。
16. 請求項１５に記載の方法において、ステップ（ｌ）と（ｍ）の間に、前記１以上のネットワークサーバが、
    （ｎ）１以上のユーザに、１以上のネットワークサーバに、このユーザを１以上の予め承認されたメッセージの受信に興味のあるものとして特定する情報を送るよう促すステップを含むことを特徴とする方法。
17. 請求項１に記載の方法において、前記１以上のネットワークサーバが、
    （ｋ）前記送信者に、１以上のメッセージ部を第１の種類のSummaメッセージか第２の種類のSummaメッセージかを規定するよう促すステップと、
    （ｌ）前記第１の種類のSummaメッセージを、予め前記第１の種類のSummaメッセージ用に規定された方法で処理するステップと、
    （ｍ）前記第２の種類のSummaメッセージを、予め前記第２の種類のSummaメッセージ用に規定された方法で処理するステップと、を含むことを特徴とする方法。
18. 請求項１に記載の方法において、ステップ（ｂ）において、前記１以上のネットワークサーバが、
    （ｋ）あるアカウントの１以上のユーザによりアクセスされるプログラムを提供するステップであって、ユーザがこのプログラムを操作すると、当該プログラムが予め規定された部分を含むSummaメッセージが生成されるステップとを含むことを特徴とする方法。
19. 請求項１に記載の方法において、ステップ（ｃ）の前に、前記１以上のネットワークサーバが、
    （ｋ）前記送信者に、前記Summaメッセージの配信の試みを止める時間を設定させるステップと、
    （ｍ）前記配信を許可する時間が経過したらステップ（ｃ）を排除するステップとを含むことを特徴とする方法。
20. 請求項１に記載の方法において、ステップ（ｂ）において、前記１以上のネットワークサーバが、
    （ｋ）前記送信者に、第１のユーザアカウントに関する複数の金融アカウントのうち、引き落としを承認された資金が引き落とされるべき１以上を特定させるステップを含むことを特徴とする方法。
21. 請求項１に記載の方法において、ステップ（ｂ）と（ｃ）の間に、前記１以上のネットワークサーバが、
    （ｋ）前記第１のユーザアカウントからの引き落としに関するさらなる承認要求を、資金を引き落とすべきアカウントの１以上の別のユーザに送信するステップと、
    （ｌ）前記さらなる承認が受信されるまで、ステップ（ｃ）を差し止めるステップとを含むことを特徴とする方法。
22. 請求項１に記載の方法において、前記１以上のネットワークサーバが、
    （ｋ）１以上のサービスプロバイダに管理された複数のネットワークサーバを通して複数のアカウントを提供するステップと、
    （ｌ）各ネットワークサーバを、１以上の手形交換所サーバ（clearinghouse server）と同定するステップと、
    （ｍ）１以上のネットワークサーバに、１のネットワークサーバにサービスされる１以上のアカウントに関する利用可能な資金における１以上の変化（change）を記述する情報を、１以上の手形交換所サーバに送信するよう促すステップと、
    （ｎ）前記手形交換所サーバが、１以上のネットワークサーバにより提供された情報を、資金の移動を処理して１以上のアカウントの利用可能な資金を正しいバランスに変化させるよう利用させるステップと、を含むことを特徴とする方法。
23. 請求項１に記載の方法において、前記１以上のネットワークサーバが、
    （ｋ）１以上のサービスプロバイダに管理された複数のネットワークサーバを通して複数のアカウントを提供するステップと、
    （ｌ）各サービスプロバイダに、１以上の電子的に管理された資産アカウントのうちの１のネットワークサーバにサービスされた前記ユーザアカウントに預金された純資産を保持するよう促すステップと、
    （ｍ）各ネットワークサーバを１以上の手形交換所サーバとして同定するステップと、
    （ｎ）１以上のネットワークサーバに、１以上の電子運営ファンドアカウント内の純資産の１以上の変動を示す情報を、１以上の手形交換所サーバに送信するよう促すステップと、
    （ｏ）前記手形交換所サーバが、１以上のネットワークサーバが提供する情報に基づいて、各電気的に管理された資産アカウントの純資産がただしバランスとなるように、２以上の電子的に管理された資産アカウント間で資産の移動を処理するステップと、を含むことを特徴とする方法。
24. 請求項１に記載の方法において、前記１以上のネットワークサーバが、
    （ｋ）第１のユーザ群が、第１の金融機関に保持された金融アカウントに関するユーザアカウントを有し、第２のユーザ群が、第２の金融機関に保持された金融アカウントに関するユーザアカウントを有するようにするステップと、
    （ｌ）１以上のサービスプロバイダにおいて、第１のユーザ群と第２のユーザ群が、第１の金融機関に１以上の第１の金融アカウントと、第２の金融機関に第２の金融アカウントを有するようにするステップと、
    （ｍ）前記第１のユーザ群におけるメッセージの送信者が資金の移動を承認した場合に、この資金は前記第１の金融機関の対応するユーザアカウントに関する金融アカウントから引き落とされ、前記サービスプロバイダの第１の金融アカウントに預金されるステップと、
    （ｎ）第２のユーザ群におけるメッセージの送信者が資金の移動を承認した場合に、この資金は前記第２の金融機関の対応するユーザアカウントに関する金融アカウントから引き落とされ、前記サービスプロバイダの第２の金融アカウントに預金されるステップと、
    （ｏ）前記第１の群におけるSummaメッセージの受信者が資金の預託を受けた場合、この資金を前記サービスプロバイダの第１の金融アカウントから引き落とすステップと、
    （ｐ）前記第２の群におけるSummaメッセージの受信者が資金の預託を受けた場合、この資金を前記サービスプロバイダの第２の金融アカウントから引き落とすステップと、を含むことを特徴とする方法。
25. 請求項１に記載の方法において、ステップ（ｃ）の前に、前記１以上のネットワークサーバが、
    （ｋ）１以上のユーザに、１以上のネットワーク接続型電子機器で読み込み可能なトークンであって１以上のユーザアカウントを同定する情報を含むトークンを提供するステップと、
    （ｌ）前記ネットワーク接続型電子機器で前記トークンを読み込んで、前記１以上のユーザアカウントの情報を抽出するステップと、
    （ｍ）前記トークンから抽出された情報を、前記送信者の資金を引き落とすべき金融アカウントを同定するのに用いるステップと、を含むことを特徴とする方法。
26. 複数のユーザアカウントを有する金融トランザクションと電子メッセージングシステムであって、このシステムは第１のユーザ、第２のユーザ、および第３のユーザをそれぞれ第１、第２および第３のネットワーク接続デバイスで接続し、前記ユーザはそれぞれシステム上に第１、第２および第３のアカウントを有し、各デバイスはネットワークサーバにアクセスして前記アカウントに関連する情報を含むファイルを保存または取得可能であり、
    （ａ）各ユーザアカウントはSummaアカウントを有し、各Summaアカウントはデビットとクレジットの双方が可能な金融アカウントと統合メッセージングシステムを有し、
    前記１以上のネットワークサーバが、
    （ｂ）第１のユーザアカウントを送信者とし、第２のユーザアカウントを受信者として、メッセージ部と料金割り当て部とを含むSummaメッセージを送信するステップと、
    （ｃ）前記第２のユーザアカウントに前記メッセージ部を配信するとともに、当該メッセージ部の送達の確認がとれた場合にのみ、前記料金割り当て部にかかる資金を前記第２のユーザアカウントに移転するステップと、
    （ｄ）第２のユーザアカウントを送信者とし、第３のユーザアカウントを受信者として、第２のメッセージ部と第２の料金割り当て部とを含む第２のsummaメッセージを送信するステップと、
    （ｅ）前記第３のユーザアカウントに前記第２のメッセージ部分を配信するとともに、当該第２のメッセージ部の送達の確認がとれた場合にのみ、前記第２の料金割り当て部にかかる資金を前記第３のユーザアカウントに移転させるステップと、
    （ｆ）各Summaメッセージの送信者に、前記受信者が前記Summaメッセージに返信することを選択した場合に前記送信者が要求する返信料金を指定するよう促すステップと、
    （ｇ）前記受信者に、前記Summaメッセージへの返信に前記送信者が要求する返信料金を通知するステップと、
    （ｈ）前記返信を配信する際に前記返信料金の支払いを前記受信者から前記送信者へ移転させるステップと
    を実行するようプログラムされていることを特徴とするシステム。
27. 請求項１に記載の方法において、前記ステップ（ｄ）と（ｅ）における第３のSummaアカウントは、前記第１のSummaアカウントであることを特徴とする方法。

Images