JP5044927B2 - 複数の当事者間における少額決済の円滑化 - Google Patents

Description

本発明は一般に商取引の自動化の分野に関しており、そして特に、売り手へむけて十分に蓄積した少額決済契約を支払う事ができるシステムに関している。

電子支払いのような支払いを可能とする為のアクセス性の技術が進むにつれ、取引をする当事者間における電子支払いが、ますます広がるようになった。例えば、今日、売り手の大部分がクレジットカードおよび／あるいはデビッドカード取引を処理する為の備えをしている。ネットワーク（あるいはオンライン）に基づいた売り手は、一般に電子支払いサービスにかなり依存しており、そして多くの電子支払い物（例えば、クレジットカード、デビットカード、他の電子支払いサービス（例えば、PayPalオンライン支払いサービス））を受け入れているかもしれない。

多くの企業は、電子支払い（あるいは、振替）サービスを提供している（例えば、Visa、Mastercard、American Express、Paypalなど）。そのような電子支払いサービスは、一般的に取引ごとに基づいて、当然そのようなサービス提供の料金を請求する。これらの取引請求は、さらに商品やサービスを提供している売り手に対しても一般的に課される。一方で、そのような取引請求は売り手を惹き付けない。多くの例として、取引請求が総取引額と比較して小さい事が挙げられる。さらに、売り手は、該当する費用を上回ってしまうとして売り手と購入者の双方の便益利潤を考慮している。

上述したように、様々な電子支払いサービスによって課される取引請求は、一般的に取引ごとの契約であり、さらにしばしば一定の取引請求を含んでいる。総取引額が低下するにつれ、その経過における取引契約ごとの請求は総取引額の割合に応じて増加し、そのような電子支払いサービスを使う事の売り手への魅力は減少する。その為に売り手が、総取引額が小さい場合には、電子支払い（例えば、クレジットカードを経由して）で受け取る事をしばしば嫌がると言う理由がある。取引費用が取引に関して得た利潤にほぼ等しくなり始める時、電子支払いサービスの使用は特に魅力のないものとなる。オンライン上での売り手が１ドル以下で電子内容物（例えば、MP3ファイル）を売る状況を例として考える。仮定として、例えば、一件あたりの取引請求を0.10ドルとすると、総取引額の10％が電子支払いサービス請求額として消費される為に、売り手は電子支払いサービスを経由した支払いの受取りを嫌がるかもしれない事が察知される。商品あたりの価値が低下する事がより深刻な問題となる。

いわゆる「少額決済」に関した取引請求の問題を解決する為の見解として、多くの解決策が提案された。そのような一つの解決策が、オランダ、アムステルダム、1998年５月の分割計算システム国際会議（ICDS’98）の会報における『分散化した少額決済整理統合』の中でJan Chomickiらによって提案された。特に、分散化したネットワーク環境において負債整理統合の概念に基づいたプロトコルを、この書類で検討している。

本発明の一つの態様によれば、複数の当事者間での少額決済を円滑にする為の方法が提供される。第一の当事者によってなされた第一の複数の少額決済契約が登録され、この第一の複数の支払い契約は第一の当事者における全契約支払い額に寄与する。第二の当事者へむけてなされた第二の複数の支払い契約が登録され、この第二の複数の支払い契約は第二の当事者における全契約受取り額に寄与する。第二の当事者における全契約受取り額は、リスク指数を利用する事で計算される。第二の当事者における全契約受取り額は、第一の当事者における全契約支払い額によって返済可能であると確認される。この決定に応じて、第二の当事者への第一の当事者による全契約受取り額の支払いの為の支払いプロセスが開始される。

本発明の別の特徴は、添付の図面および以下の詳細な記述から明らかとなる。
本発明は、例により描かれており、添付図面の図に限定されるものではなく、図中において同様な参照符号は類似の要素を示している。

売り手への少額決済の送金をする事を可能とする方法およびシステムが述べられている。以下の記述において、説明を目的として、多くの具体的な記述が本発明を十分に理解してもらうために記載してある。しかし、当業者には、これらの具体的な記述なしでも本発明を実施可能であることが明らかになるだろう。

『少額決済』の言葉が本明細書の所々で使われている一方で、本発明は、特定の金額における支払いプロセスに限っていない。本発明は、いくつかの金額の支払いプロセスへの応用がみられるかもしれず、少額決済のプロセスは、その発明の応用がみられる中での一つの使用事例として述べている。

下記に記した本発明の典型的な実施形態は、支払い契約が場合によっては少額（例えば、0.05ドル）であり、支払人が受取人へむけた支払い契約をする事ができる支払い契約システムを提案している。その支払人によってなされる支払い契約は、支払人（支払いユーザー）と受取人（受取りユーザー）の両方に対して登録される。長期にわたると、例えば支払人が多くの受取人に向けてした多くの支払い契約の総額が、大きくなる事が理解できるだろう。同様に、場合によって多くの支払人が受取人にむけてした支払い契約の総額もまた大きくなる。これらの様々な支払い契約のプロセスに関連した取引費用を削減する為に、本発明の一つの典型的な実施形態は、支払人によってなされた支払い契約の蓄積した全てを含む総額に関して資金納入すること(例えば、支払いをすること)を支払人に要求する時の閾値額を提案している。同様に、受取人にむけてなされた支払い契約の蓄積した総額が閾値額を超えている時、受取人は蓄積された支払い契約の返済の支払いを受け取る資格を有するようになる。本発明の典型的な実施形態の一つの特徴として、支払人が受取人にむけて支払いをする決定に関しており、さらなる本発明の典型的な実施形態の特徴は、いつ、そのような支払いがなされるか、およびそのような支払い額がいくらであるか、の決定に関している。それは、受取人へむけて支払われるべき、支払人によって支払らわれるべき支払い契約を蓄積する事、多くの蓄積した支払い契約の返済における一つの支払い取引（あるいは多くの支払い取引を減らした取引）が行われる事、複数の支払い契約の返済に関連した取引費用が削減される事によって高く評価される。

本発明の典型的な実施形態では、さらに、資金未納入（unfunded）の支払い契約（例えば、支払人が支払い契約の返済の支払いをしていない場合の支払い契約）と、資金納入済み（funded）の契約（例えば、支払人が既に済ませた支払いに関係する支払い契約）とを区別している。

図１は、クライアント−サーバー構造が展開されている、本発明の典型的な実施形態に係るネットワーク化された取引環境１０の概略図である。多くのクライアント側のマシンはネットワーク２０を経由して多くのサーバー側のマシンおよびプロセスに接続されている事が表されている。例えば、クライアントマシン１２は、ウェブブラウザ１４の典型的な形態においては、第一のクライアントアプリケーションを備えてこれを実行することが示され、また、第二のクライアントマシン１６はさらなるクライアント１８を実行する事が示されており、それらは公開されているアプリケーションプログラムインターフェイス（API）を利用している一つ以上のサーバー側のマシンを経由して通信可能である。各クライアントマシン１２および１６は、ネットワーク２０（例えば、インターネット、ローカルエリアネットワーク（LAN）、ワイドエリアネットワーク（WAN））に接続されている事が示されており、それは有線、無線あるいは有線と無線技術のいくつかの組み合わせを含んでいる。ネットワーク２０は、さらに多くの良く知られているプロトコルの一つ（例えば、HTTP）を利用する事でクライアントマシンとサーバー側の間の通信を円滑にする。

今、サーバー側に戻ると、３つのシステム、すなわち清算システム２２、少額決済システム２４、および商取引システム２６もまた、ネットワーク２０に接続されている。図１では、システム２２、２４、および２６のそれぞれは別々の異なるシステムとして示されているが、本発明の別の実施形態として、これらのシステムの機能および構成要素は、一つ以上の関連したシステムに統合されていてもよい。典型的なシステム２２、２４、および２６のそれぞれは、同じような３階層構造を有することが示されており、これは、関連したデータベースへのアクセスを容易にするデータベースサーバー２８と、それぞれのアプリケーションを備えて実行する一つ以上のアプリケーションサーバーマシン３０と、クライアント側から受け取った要求に応じてウェブページ（例、HTMLページ）を作成したり、および／または与えたりする一つ以上のウェブサーバー３２と、関連したシステムにプログラム上でのアクセスを提供する一つ以上のアプリケーションプログラムインターフェイス（API）サーバー３４とを含んでいる。例えばAPIサーバー３４は、クライアント側から受け取った要求に応じ、その要求しているマシンにエクステンシブルマークアップランゲージ（XML）を生成し、そして与える。

特に、今、清算システム２２について説明すると、関連のアプリケーションサーバーマシン３０は、取引当事者間での送金（例えば、ドルや所有している通貨）を可能とする一つ以上の清算アプリケーション４２を備えている。この清算アプリケーション４２は、さらにデータベースサーバー２８を経由して、清算データベース４０からデータを読み込む事も、そして清算データベース４０へデータを書き込む事もできる。清算システム２２は、カリフォルニアのマウンテンビューにあるPayPal,Inc.社によって運営されているPayPal支払いサービスのような、支払いサービスを支援するかもしれない。

少額決済システム２４は、同様にアプリケーションサーバーマシン３０上に一つ以上の少額決済アプリケーション３８を備えており、これらの少額決済アプリケーション３８は、データーサーバー２８を経由して、少額決済データベース３６に格納されたデータへの書き込みアクセスおよび読み出しアクセスを有している。典型的な少額決済アプリケーション３８に関するさらなる詳細は、以下にさらに詳しく述べられている。

商取引システム２６は、適切なアプリケーションサーバーマシン３０上に一つ以上の商取引アプリケーション４６を備えており、この商取引アプリケーション４６は、データベースサーバー２８を経由して、商取引データベース４４に格納されたデータへの書き込みアクセスおよび読み出しアクセスを有している。商取引アプリケーション４６は、一つ以上の金額設定アプリケーション（例えば、競売アプリケーション、定額アプリケーションなど）を含んでいてもよく、これにより、当事者間での契約額を設定するようにしてもよい。他の商取引アプリケーション４６は、例えば、ユーザーに関した足跡および取引履歴情報をたどる信用アプリケーションを含んでいてもよい。また、そのような信用アプリケーションは、商取引システム２６内でユーザーが信頼性を確立する事ができるように、ユーザーに関する信用情報を公開し、そしてこの信用情報を見込み商取引相手や他のシステム（例えば、清算システム２２あるいは少額決済システム２４）に公開して、これらのシステムが、特定のユーザーにおける信頼性、信用性、およびリスク要因を査定するのに使用できるようにしてもよい。商取引システム２６の一例としては、カリフォルニアのサンホセにあるe-Bay Inc.社によって運営されているeBayオンラインマーケットがある。

図２は、本発明の別の実施形態に係るネットワーク化した取引環境５０の概略図であり、ここでは、図１を参考に上述したサーバーベースのシステムとは対照的に、少額決済システムはピアツーピア（peer-to-peer）システムとして展開して示されている。そのために、図２は、ユーザーマシン５２および５８を含むネットワーク化した取引環境５０を示しており、そのそれぞれが、ピアツーピア少額決済アプリケーション５４および６０を備えている。ユーザーマシン５２および５８のそれぞれは、ネットワーク６４（例えば、インターネット）と接続されている事が示されており、そして少額決済アプリケーション５４と６０は、ネットワーク６４を介して適宜に通信する事ができる。少額決済アプリケーション５４および６０のそれぞれは、さらにローカル少額決済データベース５６および６２へのアクセスをそれぞれ有し、構築され、そして以下でさらに詳細に述べているような様々な機能を与える。

また、図２は、関連の少額決済アプリケーション５４および６０がネットワーク６４を経由して通信できるサーバーベースのシステムである清算システム２２および商取引システム２６を示している。本発明のさらなる実施形態においては、清算システム２２および／あるいは商取引システム２６は、図２に示したサーバーベースの構造とは対照的に、ピアツーピアの構造を利用して展開されてもよい。さらに加えて、清算システム２２あるいは商取引システム２６のどちらかにおける様々な構成要素は、別の実施形態においては、ピアーツーピアシステムとして展開されてもよい。例えば、ピアツーピア信用システム、あるいはピアツーピアリスク分析システムが、サーバーベースの少額決済システムや、それ自身がピアツーピアシステムである少額決済システムと組み合わせて利用されることもできる。

図３は、図１に示された少額決済システム２４の一つ以上のアプリケーションサーバー３０に備えられた、本発明の一つの典型的な実施形態に係る少額決済アプリケーション３８に関するさらなる詳細を提供するブロック図である。図示された少額決済アプリケーション３８は、ユーザーマシン５２上で実行する、ピアツーピアであってスタンドアローン型の少額決済アプリケーション５４のモジュールあるいはサブアプリケーションを形成することもできるとして、勿論、高く評価される。

その典型的な少額決済アプリケーション３８は、支払い契約登録モジュール７０を含んでおり、それは少額決済システム２４を利用して支払人によってなされる支払い契約を登録するように動作する。例えば、少額決済システム２４は一つ以上のユーザーインターフェイスを提供し、これにより支払人が支払い契約をしたいと願っている受取人を確認し、かつこれを利用して支払人が関連の支払い契約における金額（例えば、通貨価格）を特定する事もできる。本発明の一つの実施形態は、支払い契約を、資金未納入の支払い契約（例えば、関連の支払人が一つ以上の支払い契約を返済する為の実際の支払いをしていない）と、資金納入済みの支払い契約（例えば、支払人が一つ以上の支払い契約の返済において支払いをした）のどちらかとして分類する。

支払い契約登録モジュール７０は、（例えば、マークアップ言語の文書内に含められるべき）契約情報を送り、そして支払人から支払い契約情報を受け取る為に、ウェブサーバー３２および／あるいはAPIサーバー３４と通信する。支払い契約情報を受取り次第、支払い契約登録モジュール７０は、少額取引データベース３６内のアプリケーションテーブル内にこの情報を記録するようさらに動作する。そのようなテーブルは、例えば、支払い契約テーブル９４および受取り契約テーブル９６を含んでおり、それについては図４を参照しつつ下記においてさらに詳しく議論する。

同様に、受取り契約登録モジュール７２は、受取人にむけた支払い契約に関した契約情報を受け取り、そしてこの支払い契約情報を少額決済データベース３６内の適当な一つまたは複数のテーブルに登録するように動作する。例えば、受取り契約登録モジュール７２は、受取り契約情報を受取り契約テーブル９６内に記録してもよく、それは図４を参照して下記にさらに詳しく述べる。

支払い契約登録モジュール７０および受取り契約登録モジュール７２の両方は、定期循環払いモジュール７４と通信する。定期循環払いモジュール７４は、支払人によって決定された定期循環支払い契約を生じる事（受取人によって決定される契約要求を生成しあるいは定期循環する事) に関与し、かつ、登録モジュール７０および７２へ適切な契約情報を通知する事に関与しており、それに応じて登録モジュール７０および７２は適切なテーブル中の記録を作成および／あるいは更新する。ある支払人が、（例えば、特別なサービスを受ける為の）特定の受取人への月々の支払い契約を望んでいる例を考える。定期循環払いモジュール７４は、そのような定期循環払いを扱う。

本発明の一つの典型的な実施形態に係る閾値調整モジュール７６は、少額決済システム２４内で登録された支払い契約の返済における資金納入取引（例えば、支払いプロセスの開始）のきっかけとなる閾値を特定する事を容易にし、またはそれ自身が上記閾値を特定する。例えば、支払い閾値が、支払人の支払い契約に関連して特定され、その結果、支払人によってなされた全契約支払い額が支払い閾値を超えた時、支払人が関連の資金未納入の支払い契約に資金納入する事によって支払いプロセスが開始される。

同様に、受取り閾値が閾値調整モジュール７６によって決定され、この受取り閾値は、受取人へむけてなされた契約支払い額が閾値総額を超えた時に、支払い契約の返済において受取り資格がある受取人に払われる上記閾値総額である。

本発明の一つの実施形態において、例えば、閾値調整モジュール７６は、単に、例えば少額決済システム２４の管理者が一つ以上の閾値額（例えば、５.00ドル）を支払い閾値もしくは受取り閾値のどちらかとして決定する事を可能にするよう動作する。例えば、少額決済システム２４の管理者は、個々の支払人や受取人、あるいは支払人／受取人の組み合わせの様々な組にさえ適用可能な別々の閾値を決定してもよい。

本発明のもう一つの実施形態において、閾値調整モジュール７６は、例えば、関連のユーザーに適用可能な特定の最小および最大金額の制限内で、個々のユーザーが支払いおよび／もしくは受取り閾値を決定できるようにしている。

また、本発明のさらなる実施形態において、閾値調整モジュール７６は、様々な情報源を用いて、支払いおよび／もしくは受取り閾値を自動的に計算する。例えば、ある清算システム２２が特定の財務事情（funding events）との関連で利用されるという事に少額決済システム２４が気づくと、閾値調整モジュール７６が、関連の清算システム２２によってもたらされる取引変化に依存した閾値を調整する。清算システム２２が財務事情（funding events）に関連した取引変化を増大させるような特殊な例を考える。この場合、閾値調整モジュール７６は、取引変化を資金納入額の所定の最大割合として維持する為に、閾値を上げる。もう一つの典型的な実施形態において、閾値調整モジュール７６は、特定の受取人が支払い契約の所定の割合を達成するのを怠ったかどうかに基づいて、動的に閾値を調整する。例えば、閾値調整モジュール７６は、支払い契約に資金納入するよりも前に、関連の受取人がその容認できないかなりの時間を待たなければいけないのを防止する為に、資金納入受取り閾値を自動的に下げるようにしてもよい。また、支払人が事前に決定した割合で支払い契約をなさない場合、閾値調整モジュール７６は、容認できる期間内で資金納入をさせる（extract）為に、そのユーザーに関した資金納入支払い閾値を下げてもよい。

また、閾値調整モジュール７６は、ユーザーに関連した閾値を査定する際に、支払人あるいは受取人に関した特徴あるいは属性情報を配慮する。例えば、ユーザーに関した履歴や信用情報が、支払人から資金提供を得ることに関する増加したあるいは減少したリスクを示している場合、閾値調整モジュール７６はそのユーザーにおける資金納入支払い閾値を自動的に調整する。また、もう一つの典型的な実施形態では、閾値調整モジュール７６は、時間を延長して閾値を増やしたり、減らしたりする。たとえ資金納入支払いがとても小さくとも、最終的に支払人が確実に資金納入をしやすくなるように、例えば、閾値が、あるレベル（例えば、5.00ドル）で始まり、毎月所定の金額（例えば、１ヶ月につき1.00ドル）を最小容認取引額まで減らしてゆくようにしてもよい。

また、閾値調整モジュール７６は、変化する解決策に伴い閾値の決定をしてもよい。例えば、閾値調整モジュール７６は、少額決済システム２４にそったシステムレベルに適用されるべき閾値を決定する。また、閾値調整モジュール７６は、様々な境遇に依存した、ユーザーレベルもしくは資金提供取引レベルにおいて決定されるべき閾値を決定してもよい。

図３は、閾値査定モジュール８０に接続された閾値調整モジュール７６を示しており、閾値査定モジュール８０は、契約受取り総額における契約支払い総額が特定の閾値を超えているかどうかを査定するように動作する。閾値査定モジュール８０の動作は、図６を参照して以下でさらに詳しく述べる。

少額決済アプリケーション３８は、一つの典型的な実施形態において、ユーザー（例えば受取人）に関したリスクプロファイルを利用して受取人における総受取り契約額を計算するように動作する受取計算モジュール７８を含んでいる事を示している。本発明の他の実施形態において、全契約受取り額の計算は、他のリスク情報を考慮している。従って、本発明はユーザーに関連したリスクプロファイルの利用に限定されるものではなく、リスクを決定する、あるいは察知するいずれかの情報の利用を含んでいる。

受取計算モジュール７８が、ユーザー（例えば、受取人）に関連したリスクプロファイルを決定するリスク査定モジュール８１と通信する事が示されている。例えば、リスク査定モジュール８１は、履歴や信用情報を利用する事で、ユーザーについてのリスクプロファイルを作成する（あるいは、少額決済システム２４内で利用する為のリスク値を計算する）。リスク査定モジュール８１によって利用される履歴および／もしくは信用情報は、少額決済システム２４から部分的に得られてもよく、あるいは、例えば商取引システム２６から得られる信用情報、そして清算システム２２から得られる支払い履歴情報のような他の情報源から得られてもよい。リスク査定モジュール８１は、また、Equifaxおよびクレジットスコア機構のような第三者情報の販売人から情報を得てもよい。

少額決済システム２４内で活用する為のリスク値（例えば、ユーザーについてのリスクプロファイル）を計算する際に、広く様々な他の情報源が、リスク査定モジュール８１によって活用されてもよい。例えば、特定のユーザーによって提供されるサービスや商品のタイプが関連しているかもしれない。例えば、ゲームやポルノグラフィーサービスは、支払人による支払いの怠慢において典型的に高いリスクがある。また、支払人や受取人の地理的な位置も関連があるかもしれない。リスクを査定する際に、いくつかのタイプのユーザー、あるいは特別な取引にむけたいくつかの当事者に関連したいくつかの情報の組み合わせが、リスク査定モジュール８１によって利用されるかもしれない事を記している。このリスク査定は、さらに受取人における全契約受取り額の計算においても利用され、例えば、以下に述べているような少額決済システム２４内で他の支払い額のリスク調整を行なうために、および他の目的で利用されるかもしれない。

また、もし理由があるならば、ユーザーに関した閾値額を調整する際、モジュール７６がリスクプロファイルを利用可能とする為に、リスク査定モジュール８１が、閾値調整モジュールに対して入力を与える事を示している。

少額決済アプリケーション３８は、また、少額決済システム２４のユーザーに向けてのメッセージ（例えば、Eメール、SMSメッセージ、インスタントメッセージ（IMs）など）の通信だけでなく、少額決済アプリケーション３８および他のアプリケーション（例えば、図１に描かれている清算アプリケーション４２、および商取引アプリケーション４６）間の様々なタイプの情報通信を可能とする為の通信モジュール８２を含んでいる。例えば、通信モジュール８２は、支払人から受取人への送金を開始する為の指示を、支払いプロセスの一部として、清算アプリケーション４２へ通知する。そのような指示の通知は、支払い配分モジュール８４からの指示で自動的に行われるか、それとも関連の送金のための指示をユーザーから受ける事で行われる。

また、通信モジュール８２は、他のアプリケーションからの通知を受け取ってもよい。例えば、清算アプリケーション４２は、少額決済アプリケーション３８が、資金納入すると言うような特定の契約を登録する事に応答して、資金がうまく支払人から受取人へ送金された事を通信モジュール８２へ逆に通知してもよい。そのために、通信モジュール８２が登録モジュール７０および７２と通信するようにして、契約が適切であって清算アプリケーション４２によって確認されたものである場合に、この契約を資金納入されたものとして上記モジュールが登録できるようにする事が示されている。

また、閾値調整モジュール７６およびリスク査定モジュール８１が、清算システム２２および商取引システム２６のような外部のシステムへ通知を送ったり該システムから通知を受け取ったりできるようにする為に、通信モジュール８２が閾値調整モジュール７６と通信する事が示されている。

本発明の一つの典型的な実施形態において、支払い配分モジュール８４は、支払人から受取人への自動送金を指示するように動作する。例えば、支払い契約が資金の支払い閾値を超えている全契約において自動的に資金納入される際に勘案する優先度を、支払人が決めておくようにしてもよい。さらに、支払人は、どの受取人が関連の資金を受取るべきかに関する優先度を決めておき、あるいは、支払い配分モジュール８４が資金を配分する受取人を自動的に確認する際に勘案する基準を決定しておいてもよい。例えば、特定のユーザーは、支払人の全支払い契約が閾値を超えた時に、その契約が、資金を受け取る資格を有する慈善組織へ支払いをする事によって資金納入されると言うように、優先度を決定してもよい。

以下にさらに詳しく述べるように、一つの典型的な実施形態においては、受取り契約は、資金納入される受取り閾値を超える時、受取り計算モジュール７８および閾値査定モジュール８０によって資金納入待ち列（a funding queue）に位置づけられる。この実施形態において、支払い配分モジュール８４は、次に資金納入される、あるいは特別な事情下におかれている資金納入待ち列内における資格のある受取人を決定する為の様々なアルゴリズムを操作する。例えば、支払い配分モジュール８４は、単純な先入れ先出しの原理に基づいて資金納入待ちの列に資金納入額を配分する。もう一つの方法として、支払い配分モジュール８４は、資金納入待ち列内から受取人を選択するのにもっと高い基準を適用する。

図４は、本発明の典型的な実施形態に係る、少額決済データベース３６内に属している様々なテーブル９０を示す高いレベルの存在関係図である。テーブル９０は、各ユーザーに特定の関係（contact）情報および他の情報を格納しているユーザーテーブル９２を含んでいる。支払い契約テーブル９４は、特定のユーザーに対してなされた各支払い契約の記録を維持し、また、支払人、受取人、契約合計額、契約日付、契約内容、契約が未納かそうでないかの指示、契約が定期循環かどうかの指示を識別する識別名を含んでいる。

同様に、受取り契約テーブル９６は、特別なユーザーによって受取る事ができる各支払い契約の記録を格納しており、そして支払い契約テーブル９４内に記録されているのと同じ情報を記録している。

別々の支払い契約テーブル９４および受取り契約テーブル９６を維持する事により、これらのテーブルが２つの登録（double-entry）の検証を行う為に利用可能である事は高く評価できる。別の実施形態においては、支払い契約テーブル９４および受取り契約テーブル９６ は、結合されて一つの契約テーブルとなっている。

清算テーブル９８は、特定の支払人および特定の受取人の間の各資金納入取引の記録を有している。精算テーブル９８内の記録は、清算システム２２から引き出した情報から作成され、そして特定の資金提供取引に応じて資金納入されたものであるとしてテーブル９４および９６内の登録に登録モジュール７０および７２によってフラグを立てるのにも利用される。

テーブル９０は、さらにユーザー閾値テーブル１００を含んでおり、それはユーザーテーブル９２内に記録が存在する各ユーザーの資金納入受取り閾値および資金納入支払い閾値を格納している。上記のように、本発明の一つの典型的な実施形態においては、支払いおよび受取り閾値は、ユーザーレベルで決定される。本発明の別の実施形態においては、システム閾値テーブル１０２は、少額決済２４内のシステムレベルで適用可能な資金納入受取り閾値および資金納入支払い閾値を格納する事ができる。もちろん、ユーザー閾値テーブル１００およびシステム閾値テーブル１０２の両方が存在し、その記録された閾値が所定の基準に依存して、支払い配分モジュール８４によって選択的に適用される。

また、テーブル９０は、特定のユーザーにおけるフィードバックおよび履歴情報を含む記録を有している信用テーブル１０４をも含んでいる。例えば、信用テーブル１０４は、取引フィードバック情報、支払いフィードバック情報、会員継続情報、外部クレジットあるいは識別照合情報、および会員情報を含んでいる。上述したように、信用テーブル１０４内の情報は、少額決済システム２４内で内部的に生成され、あるいは外部の情報源やシステム（例えば、清算システム２２および商取引システム２６）から通信モジュール８２を経由して受け取られる。

図５は、金額を有している典型的な受取り契約テーブル９６を示すブロック図である。図示のように、様々な契約には、関連の支払人が、関連の支払い契約を適用かつ補填する資金提供取引を行ったかどうかに依存して、納入済みあるいは未納入のどちらかであるとしてフラグが立てられている。

一つの典型的な実施形態においては、ユーザーテーブル９２が、契約支払いバランスおよび契約受取りバランスを反映しているという事に注意すべきである。その受取り計算モジュール７８は、受取り契約テーブル９６および支払い契約テーブル９４内に含まれている情報に基づき、これらのバランスを定期的に更新する。

図６は、本発明の典型的な実施例に係る方法１１０のフローチャートであり、これによれば、少額決済アプリケーション３８が受取人に支払うべき受取り総額を計算し、資金納入待ち列にむけて受取り総額を配分する。特に、受取り契約テーブル９６は、生の契約受取り情報の形式で、受取り計算モジュール７８に入力を与える。その受取り計算モジュール７８は、リスク適用した全契約受取り額を計算する為にリスクモデル１１２を備えている。リスクモデル１１２は、関連の受取りユーザーに関連したリスクプロファイルを作成する為に信用テーブル１０４から取り出した情報を利用し、リスク調整された受取り総額を、上記作成されたリスクプロファイルの関数として計算する。一つの実施形態において、リスクプロファイルは、契約受取り総額の未納入部分の資金納入に関する不確実性を考慮して、生の契約受取り総額の未納入の部分のみに適用される。本発明の他の実施形態において、生の契約受取り総額の未納入部分に適応されるリスクプロファイルは、受取人に特に関連するものではなく、全体として少額決済システム２４のいたる所で適用可能であってもよく、あるいは未納入支払い契約に関連した支払人に基づいて計算されてもよい。

受取り計算モジュール７８によって適応されるリスクプロファイルの関数は、単純な関数（例えば、単純な割合計算）であってもよく、あるいはたくさんの要因を考慮したもっと複雑な関数であってもよい。例えば、リスクプロファイル（あるいは他のリスク指数）は、上述で決定した情報種のいずれかを利用する事で計算される。さらに、受取り計算モジュール７８によって適用されたリスクプロファイル（あるいは、リスク指数）の関数は、少額システム２４の管理責任者あるいはそれ自身の機械学習のどちらかによる絶え間ない改良や調整の主題である。

リスク調整された全契約受取り額は、次に、受取り計算モジュール７８から閾値査定モジュール８０へ通知され、それはリスク調整された全契約受取り額が、受取り総額に資金納入の資格を与える閾値を超えるかどうかに関しての決定をする。この評価をする際に、閾値査定モジュール８０は、図４を参照して上述されている閾値テーブル１００もしくは１０２の中に含まれている情報を利用する。なお、閾値は、システムレベル、ユーザーレベルあるいは取引レベルに適用される。

リスク調整された全契約受取り額が資金を受け取る資格があると言う事を閾値査定モジュール８０が決定した場合は、関連の受取り総額が資金納入待ち列１１４内に登録される。資金納入待ち列１１４内の各登録は、リスク調整された全契約受取り額、受取人、受取り総額が資金納入待ち列に入力された日付、および優先順位を記録する。一つの実施形態においては、支払い配分モジュール８４が、優先順位を決める。特に、その支払い配分モジュール８４は、先入れ先出しの優先案、もしくはさらに複雑な優先案に基づいて、資金納入待ち列１１４内の各登録に優先順位をつける。例えば、受取人が特殊なタイプの組織（例えば、慈善事業）であったり、あるいは優先受取人として指定されているような登録は、他の登録より先に優先される。他の実施形態においては、受取人が資金納入より先に容認できない期間を待たない事を確実にする為に、資金納入待ち列内の登録に優先順位を付けるのに優先案が利用される。

図７は、本発明の典型的な実施形態における、集積された支払い契約における当事者間の支払いを円滑にする為の方法１２０を示すフローチャートである。方法１２０は、支払人への支払い契約インターフェイスの提示をともなうブロック１２２で開始する。図９は、ブロック１２２に示される典型的な支払い契約インターフェイス１６０を示している。図９からわかるように、支払い契約インターフェイス１６０は、支払人が受取人を認証する受取人認証領域１６２と、支払人が関連の契約に関する金額を入力できる総額領域１６４とを含んでいる。その支払い契約インターフェイス１６０は、また、支払人が、契約が定期循環する（例えば、イエス／ノーラジオボタンを使う）事を確認できるようにし、かつ、支払人が、定期循環日付領域１６９内の定期循環日付と定期循環期間領域１７０内の定期循環期間を特定できるようにする定期循環領域１６８を含んでいる。他の実施形態においては、インターフェイス１６０は、支払いの頻度や回数のような、例えば「１日１契約で、0.10ドルずつの２５回の契約をする」と言ったような、定期循環を示す為の他のメカニズムを与える。

図７に戻って、ブロック１２４において、通信モジュール８２は、（例えば、ウェブサーバー３２やAPIサーバー３４を経由して）支払人から支払い契約情報を受け、その支払い契約情報は、受取人の識別名、総額、日付、そして上述の議論された定期循環情報を含んでいる。

ブロック１６２で、支払い契約登録モジュール７０は、契約支払いテーブル９４内の支払人に対する、支払い契約情報に基づく支払い契約を登録する。同様に、受取り契約登録モジュール７２は、契約受取りテーブル９６内の受取人に対する支払い契約を登録する。さらに、受取り計算モジュール７８は、受け取った支払い契約情報に基づき、ユーザーテーブル９２内の支払人および受取人のそれぞれにおける契約支払いおよび契約受取りバランスを計算し、更新する。

決定ブロック１２８では、上述したように、ブロック１２６で計算され、そしてユーザーテーブル９２に反映された、上記の更新された契約受取りバランスは、受取り計算モジュール７８によって計算された、リスク調整された契約受取りバランス（あるいは総額）である。

決定ブロック１２８に進むと、契約支払いバランスの更新に続いて、閾値査定モジュール８０は、支払人の契約支払いバランスが、所定の資金納入支払い閾値（例えば、ユーザーレベルあるいはシステムレベルで決定された閾値）を超えるかどうかを決定する。支払人における契約支払いバランスが閾値を超えない場合、方法１２０はブロック１３０で終了する。

一方、支払人における契約支払いバランスが資金納入支払い閾値を超えた場合は、決定ブロック１３２において、支払い配分モジュール８４は、受取人（例えば、売り手）が、支払人の契約支払いバランスと等しいかそれを超えている契約受取りバランスを伴って存在しているかどうかを決定する。上述したように、典型的な実施形態においては、契約受取りバランスはリスク調整された契約受取りバランスである。決定ブロック１３２における支払い配分モジュール８４によって行われる決定は、支払人の契約支払いバランスによって返済可能な契約受取り総額有する登録を確認する為に資金納入待ち列の検索を行う支払い配分モジュール８４を含んでいる。資金納入待ち列１１４の検索を行う際に、支払い配分モジュール８４は、資格のある受取人を確認しようとする時、各登録に関連した優先データを考慮してもよい。

支払い配分モジュール８４が、決定ブロック１３２で受取り人を確認する事に成功すると、方法１２０は、ブロック１３４に進み、そこで支払いプロセスが開始されて、支払人から、探し出された受取人への資金納入支払いを完了する。

本発明の様々な実施形態において、ブロック１３４での支払いプロセスの始まりは、様々な形式を採っている。例えば、少額決済システム２４は、ブロック１３４において、図１０に典型的な実施例で示された支払いインターフェイス１７２を支払人に提示するようにし、この支払いインターフェイス１７２は、（１）彼もしくは彼女の契約支払いバランスが閾値を超えているということ、および（２）探し出された受取人に向けての資金納入を支払人が要求されているということ、を支払人に通知する。本発明の一つの典型的な実施形態において、支払い配分モジュール３４は、決定ブロック１３２において、資金納入支払いを受け取る資格がある（受け取るのに適した）多くの受取人を実際に確認する。この典型的な実施形態においては、支払いインターフェイス１７２は、資金納入支払いを受け取る為の資格がある（受け取るのに適した）受取人の少なくとも一人を選ぶ為の機能（例えば、ラジオボックス）と共に、資格がある受取人のリスト１７４を支払人に提示してもよい。

また、支払いインターフェイス１７２は、清算システム２２にむけて支払人を迂回させる為の、ユーザーによる選択が可能な「支払いサービスに進む」ボタン１７６を含むことが、図１０に示されている。清算システムは、支払人が選んだ受取人への支払いをする事を好都合に可能にしている。それ故に、ボタン１７６の選択により、少額決済システム２４は、通信モジュール８２を利用して、清算システム２２に支払人個人情報、受取人個人情報、合計金額情報ならびに資金納入総額情報を通知する。清算システム２２がウェブサービスを可能としている場合、この情報は、関連したAPIサーバー３４を経由して受け取られる。続いて、清算システム２２における清算アプリケーション４２がフローを開始することにより、資金納入取引支払いが完了する。

本発明の別の実施形態においては、ブロック１３４で、支払い配分モジュール８４は、支払人による手作業での仲介や承認なしで資金納入支払いが受取人に支払われるようにする指示を、自動的に通知する。例えば、支払い配分モジュール８４は、通信モジュール８２を利用して、受取人の口座に資金納入支払いを行うようにする指示を清算システム２２へ通知する。

清算システム２２が、ブロック１３４で支払いを完全なものとする為に利用される場合、その清算システム２２は、確認情報を少額決済システム２４に返信し、その情報は通信モジュール８２によって受け取られ、登録モジュール７０および７２に与えられる。資金納入支払いの確認の受取りに応じて、登録モジュール７０、７２は、支払いテーブル９４および９６内の支払い契約に、資金納入されたものとしてフラグを立てる。

方法１２０のブロック１３４から進んで、方法１２０はブロック１３６で終了する。
決定ブロック１３２に戻って、支払い配分モジュール８４が、契約支払いバランスよりも大きい、あるいはそれに等しい契約受取り額を伴う資金納入待ち列１１４の中から受取人を探し出すことができない場合、支払い配分モジュール８４は所定の閾値額よりも大きい、もしくはそれに等しい契約受取りバランスを伴っている受取人を探し出すことを試みる。資金納入待ち列１１４を含んでいる本発明の典型的な実施形態において、閾値査定モジュール８０は、適当な資金納入支払い閾値を超す全ての契約受取りバランスをすでに確認し、それを資金納入待ち列１１４内に位置づける。この場合、その支払い配分モジュール８４は、資金納入を受ける為に、使用された優先案に従い、資金納入待ち列１１４から次の受取りバランス契約を選択する。本発明の別の実施形態においては、閾値査定モジュール８０は、決定ブロック１７８で、資格のある受取人を識別する目的で受取りバランス契約（例えば、リスク調整された、あるいはその他）における分析を行い、その後、支払い配分モジュール８４が資格のある受取人の中から動的に選択する。

支払い配分モジュール８４が、ブロック１３８で資格がある受取人を探し出すことができない（例えば、資金納入待ち列１１４が空である）場合、方法１２０はブロック１３６に進んで終了する。一方、もし少なくとも一人の資格がある受取りユーザーが確認されたならば、方法１２０はブロック１４０に進み、そして支払人が受取人に資金納入額を払うプロセスが開始される。方法１２０は、次に、ブロック１４０から決定ブロック１２８まで戻って繰り返される。

図８は典型的な方法１２７のフローチャートであり、それは、図７のブロック１２６の文脈（context）内で行われる。方法１２７は、特定の受取人のためのリスク調整された契約受取りバランスを計算する。受取り計算モジュール７８が、方法１２７を遂行する。

その方法は、契約支払いテーブル９４の調査を行う事により、受取人への資金納入済みの契約の確認をともなうブロック１４２で始まる。
ブロック１４４において、モジュール７８は、受取人への確認された資金納入済みの契約を合計し、その結果、資金納入済みの全契約受取り額を生成する。

ブロック１４６において、モジュール７８は、契約支払いテーブル９４の再調査を行う事によって受取人への未納の支払い契約を確認する。
ブロック１４８において、モジュール７８は、資金未納入の全契約受取り額を出す為に、関連の受取人への資金未納入の支払い契約を合計する。

ブロック１５０に進み、リスクモデル１１２を利用して、受取り計算モジュール７８は、資金未納入の全契約受取り額にリスクプロファイル関数を適用し、結果としてリスク調整された資金未納入の全契約受取り額を生成する。

ブロック１５２において、受取り計算モジュール７８は、次に、資金納入済みの全契約受取り額、およびリスク調整された資金納入済みの全契約受取り額を合計して、リスク調整された全契約受取り額を生成し、それは続いてユーザーテーブル９２内に書き込まれるか、あるいは少額決済システム２４内に格納される。方法１２７は、その後ブロック１５４で終了する。

上記では、リスク調整が、受取人への資金未納入の契約に関して行われるとして述べたが、本発明はそれに限定されるものではない。本発明の別の実施形態において、そのリスク調整は、全体の全契約受取り額に関して行われ、そして、その資金未納入の要素のみで行われる必要はない。

図１１は、それぞれのウェブサーバー３２を経由して少額決済システム２４のユーザーに提示される典型的な支払い契約受取りインターフェイス１８０を示している。特に、インターフェイス１８０は、支払人からの支払い契約の受取りを受取人に報告するために、受取人に提示される。そのために、インターフェイス１８０は、支払人領域１８２を経由して受取人に対する支払人を確認し、また総額領域１８４内の支払い契約の総額を通知する。

インターフェイス１８０は、また、記述部分１８８含む事を示しており、それは上述した方法で計算した、資金未納入の全契約受取り額１９０、資金納入済みの全契約受取り額１９２、全契約受取り額１９４、リスク調整された全契約受取り額１９６を受取人に通知する。

本発明の一つの実施形態において、少額決済システム２４は、また、受取人が、資金納入支払いを受ける事を好んでいる、資格がある支払人のリストから選択する事を可能にする。このために、図１２は典型的な支払いインターフェイス１９８を示しており、それは、契約受取りバランスが、資金納入支払いに対し資格がある閾値を超えている事を受取人に報告し、そしてまた、資格のある支払人が支払う為に適した総額と共に、資格がある（適した）支払人のリスト１９９を提示することにより、提示される。支払いインターフェイス１９８は、また、上述したようにして少額決済システム２４と清算システム２２の間の相互のやりとりを開始する「支払いサービスに進む」ボタン１７６を含んでいる。

図１３は、コンピュータシステム２００の典型的な形態でマシンを図式的に示したものであり、このコンピュータシステム２００内では、本誌で論じた手順のいずれか一つあるいはそれより多くを上記マシンに遂行させる為の命令（指示）の一式が実行される。別の実施形態において、マシンは、独立の装置として動作し、あるいは他のマシンに接続（例えばネットワーク接続）されている。ネットワーク化された展開において、マシンは、サーバー−クライアントネットワーク環境内ではサーバーマシンあるいはクライアントマシンの能力内で動作し、あるいはピアツーピア（もしくは分散）ネットワーク環境内では対等なマシンとして動作する。マシンとは、パーソナルコンピューター（PC）であり、タブレット型パソコンであり、セットトップボックス（STB）であり、パーソナル・デジタル・アシスタント（PDA）であり、携帯電話であり、ウェブ機器、ネットワークルーター、スウィッチやブリッジ、あるいは起こすべき動作を特定する（連続した、あるいは他の）指示の一式を実行可能ないずれかのマシン、である。さらに、ただ一つのマシンが示されているが、『マシン』と言う言葉は、また、本誌で論じた方法論のいずれか一つあるいはそれよりも多くを行う為の指示の一式（またはその多く）を個別にあるいは一緒に実行するマシンのいくつかの集まりを含んでいるとも解される。

その典型的なコンピューターシステム２００は、プロセッサー２０２（例えば、中央演算装置（CPU）、画像演算装置（GPU）、あるいは両方）、主メモリ２０４、そしてスタティックメモリ２０６を含み、これらはバス２０８を経由して互いに通信し合っている。コンピューターシステム２００は、さらにビデオ表示装置２１０（例えば、液晶ディスプレイ（LCD）もしくは陰極線管（CRT））も含んでいる。コンピューターシステム２００は、また、英数字入力装置２１２（例えば、キーボード）、ユーザーインターフェイス（UI）ナビゲーション装置２１４（例えば、マウス）、ディスクドライブユニット２１６、信号発生装置２１８（例えば、スピーカー）、そしてネットワークインターフェイス装置２２０を含んでいる。

ディスクドライブユニット２１６は、ここで述べられた方法や機能のいずれか一つあるいはそれよりも多くを具体化する、またはそれらによって利用される、命令およびデータ構造の一式またはその多く（例えば、ソフトウェア２２４）が格納されたマシン読み取り可能媒体２２２を含んでいる。ソフトウェア２２４は、それがコンピューターシステム２００によって実行されている期間は、主メモリ２０４内および／もしくは演算装置２０２内に完全にもしくは少なくとも部分的に存在し、主メモリ２０４および演算装置２０２はまたマシン読み取り可能媒体を構成する。

ソフトウェア２２４は、さらに、多くの良く知られた転送プロトコル（例えば、HTTP）のいずれか一つを利用して、ネットワークインターフェイス装置２２０を経由してネットワーク２２６を介して送信あるいは受信される。

マシン読み取り可能媒体２９２が、典型的な実施形態においては単独の媒体であるとして示されているが、「マシン読み取り可能媒体」という用語は、命令の一式またはその多くを格納している単一の媒体または複数の媒体（例えば、集合型あるいは分散型のデータベース、および／もしくは関連したキャッシュおよびサーバー）を含むと解されるべきである。「マシン読み取り可能媒体」という用語は、マシンによる実行の為の命令一式を格納、符号化、または運搬することが可能で、かつ、本発明の方法のいずれか一つまたはそれよりも多数をマシンに遂行させるいずれかのメディア、あるいはそのような命令一式によって利用される、またはそれに関連した、データ構造を格納、符号化、または運搬することの可能ないずれかのメディアを含むとも解されるべきである。従って、「マシン読み取り可能媒体」という用語は、固体メモリ、光学および磁気媒体、そして搬送波信号を含むが、それに限定されないものと解されるべきである。

以上、売り手に向けた少額決済の移行を可能とするシステムと方法について述べた。本発明は特定の典型的な実施形態に関して述べられたが、本発明の一層広い精神および範囲から逸脱することなしに、これらの実施形態に対し様々な変更および変化を加えてもよい事は明らかである。従って、この明細書および図面は、限定的な意味よりはむしろ例示的な意味で考えられるべきである。

図１は、本発明の典型的な実施形態に係る、クライアント−サーバーの構成が展開されているネットワーク化された取引環境の概略図である。 図２は、本発明の別の実施形態に係る、少額決済システムがピアツーピアシステムとして展開されている事が示されたネットワーク化された取引環境の概略図である。 図３は、本発明の一つの典型的な実施形態に係る、少額決済システムの一部分を形成する少額決済アプリケーションに関してさらに詳しく示すブロック図である。 図４は、本発明の一つの典型的な実施形態に係る、少額決済システムに関連した少額決済データベース内に属する様々なテーブルを示す高いレベルの実体関係の図である。 図５は、金額を設定されている典型的な契約受取りテーブルを示すブロック図である。 図６は、本発明の一つの典型的な実施形態に係る、少額決済アプリケーションが受取人に支払われるべき全契約受取り額を計算し、そしてその全契約受取り額を資金納入待ち列に割り当てる方法のフローチャートである。 図７は、本発明の一つの典型的な実施形態に係る、集めた支払い契約における当事者間での支払いを円滑にする為の方法を示すフローチャートである。 図８は、特定の受取人にむけてリスク調整された契約受取りバランスを計算する為の典型的な方法を示すフローチャートである。 図９は、少額決済システムによって生成されて提示される典型的な支払い契約インターフェイスを示している。 図１０は、少額決済システムによって生成されて提示される典型的な支払いインターフェイスを示している。 図１１は、それぞれのウェブサーバーを経由して少額決済システムのユーザーに提示される典型的な支払い契約受取りインターフェイスを示している。 図１２は、契約受取りバランスが、資金納入支払いにふさわしい閾値を超える事を受取人に報告し、受取人に提示される典型的な支払いインターフェイスを示している。 図１３は、ここで論じられた方法論のどれか一つあるいはそれよりも多くをマシンに行わせるための命令の一式が実行されるコンピュータシステムの典型的な形態でマシンの概略図を表している。

Claims (42)

1. 複数の支払人と複数の受取人の間における少額決済を円滑にする為のコンピュータ処理システムであって、
   一つ以上のユーザーインターフェースを介して、複数の支払人によって複数の受取人に対してなされる複数の支払契約についての情報を受け取る通信モジュールと、
   データベース内にある一つ以上のテーブル内に、前記複数の支払契約についての前記情報を登録する為の登録モジュールであって、前記一つ以上のテーブルは、前記複数の支払人、前記複数の受取人、前記複数の支払人の各々における契約支払額、および前記複数の受取人の各々における契約受取額を識別する識別子を含む、登録モジュールと、
   前記複数の支払人の各々における全契約支払額と、前記複数の受取人の各々における全契約受取額を計算し、さらに、リスク情報を用いてリスク査定モジュールによって計算されるリスク値を利用する関数を適用することによって、リスク調整された全契約受取額を計算する計算モジュールと、
   前記全契約支払額が、前記複数の支払人の各々における所定の支払閾値額を超えるかどうか、および、前記リスク調整された全契約受取額が、前記複数の受取人の各々における所定の受取閾値額を超えるかどうかを判定する為の閾値査定モジュールであって、前記受取閾値額を超えるリスク調整された全契約受取額は、資金納入待ち列に入力される、閾値査定モジュールと、
   前記全契約支払額が前記所定の支払閾値額を超えると判定された後、前記支払人からの契約支払総額と同じまたはそれ以上である、前記資金納入待ち列内のリスク調整された全契約受取額を持つ一つ以上の資格のある受取人を判別する、支払い配分モジュールと、
   を含み、
   前記通信モジュールが、前記判別された受取人のうちで前記支払人により指定された受取人の識別子を受信し、前記指定された受取人は前記一つ以上の資格のある受取人のうちの一つであり、
   前記計算モジュールが、前記複数の支払契約についての情報に基づいて、前記テーブル内の前記複数の支払人および前記複数の受取人のそれぞれにおける契約支払いバランスおよび契約受取りバランスを電子計算機を用いて計算して更新し、
   前記支払配分モジュールが、前記指定された受取人に対してその全契約受取額の支払いのための支払いプロセスを開始する
   ことを特徴とするコンピュータ処理システム。
2. 前記データベース内にある前記一つ以上のテーブルは、前記複数の支払契約の各々が資金納入されたか否かの指標を含み、前記通信モジュールは、関連する支払人が前記一つ以上の資格のある受取人への支払契約のための支払いを行ったとき、通知を受信し、その後、前記複数の支払契約の各々が資金納入されたか否かの更新通知を受信することを特徴とする請求項１に記載のコンピュータ処理システム。
3. 前記リスク値が、前記支払人および前記受取人の少なくとも一方に関連したリスクプロファイルを含むことを特徴とする請求項１に記載のコンピュータ処理システム。
4. 取引履歴、支払い履歴、取引フィードバック、及び支払いフィードバックを含んだリスク指数のグループの中のいずれか一つもしくはそれより多くのリスク指数を利用して前記リスクプロファイルが決定されることを特徴とする請求項３に記載のコンピュータ処理システム。
5. 前記支払人によってなされる前記複数の支払契約が期限を超えてなされ、前記全契約支払額が前記複数の支払契約の各支払契約を反映する為に前記期限を超えて変化するようにしたことを特徴とする請求項１に記載のコンピュータ処理システム。
6. 前記受取人対してなされる前記複数の支払契約が期限を超えてなされ、前記全契約受取額が前記複数の支払契約の各支払契約を反映する為に前記期限を超えて変化するようにしたことを特徴とする請求項１に記載のコンピュータ処理システム。
7. 前記登録モジュールは、前記支払人および前記受取人がネットワークを経由して動作的に接続されている一つのサーバーに属しており、さらに、前記登録モジュールは前記サーバーで前記複数の支払契約についての前記情報を登録するようにしたことを特徴とする請求項１に記載のコンピュータ処理システム。
8. 前記登録モジュールが前記支払人および前記受取人のそれぞれに関連した第一および第二のマシンの少なくとも一つに属しており、さらに、前記登録モジュールは前記第一および第二のマシンの少なくとも一つに前記複数の支払契約についての前記情報を登録することを特徴とする請求項１に記載のコンピュータ処理システム。
9. 前記複数の受取人の各々における複数の受取額が前記資金納入待ち列に配分され、前記支払い配分モジュールは、前記支払人に向けて前記複数の受取額を通知して、前記支払人における前記全契約支払額によって返済されるべき受取額の少なくとも１つを前記支払人が選択することを可能にすることを特徴とする請求項１に記載のコンピュータ処理システム。
10. 前記支払人にむけた前記複数の受取額の通知が、前記支払人に前記複数の受取人の各々を個別に知らせることを含むことを特徴とする請求項９に記載のコンピュータ処理システム。
11. 前記所定の受取閾値額が、前記複数の受取人およびシステムの管理者のうちの少なくとも一方によって決定されることを特徴とする請求項１に記載のコンピュータ処理システム。
12. 前記所定の受取閾値額が、前記複数の受取人に関係した属性によって決定されることを特徴とする請求項１に記載のコンピュータ処理システム。
13. 前記所定の支払閾値額が、前記複数の支払人およびシステムの管理者のうちの少なくとも一方によって決められることを特徴とする請求項１に記載のコンピュータ処理システム。
14. 前記所定の支払閾値額が、前記複数の支払人に関係した属性によって決められることを特徴とする請求項１に記載のコンピュータ処理システム。
15. 前記支払い配分モジュールがネットワークに接続されたサーバーに備わっていることを特徴とする請求項１に記載のコンピュータ処理システム。
16. 前記支払い配分モジュールが、前記支払人および前記受取人にそれぞれ関連した第一および第二のクライアントマシンの少なくとも一方に備わっていることを特徴とする、請求項１に記載のコンピュータ処理システム。
17. 前記支払い配分モジュールが、前記受取人に向けて前記全契約受取額の支払いをするよう前記支払人に指示を与えることにより前記支払いプロセスを開始することを特徴とする請求項１に記載のコンピュータ処理システム。
18. 前記支払い配分モジュールが、前記支払人から受け取るべき前記全契約受取額の支払いの受取りに関して前記受取人へ通知を与えることによって前記支払いプロセスを開始することを特徴とする請求項１に記載のコンピュータ処理システム。
19. 前記支払い配分モジュールが、前記支払人が前記受取人にむけて前記全契約受取額の支払いを可能にするのに利用する支払いサービスへの前記支払人による前記支払いプロセスを開始することを特徴とする請求項１に記載のコンピュータ処理システム。
20. 前記支払い配分モジュールが、前記受取人が前記全契約受取額の支払いを受け取ることができるのに利用する支払いシステムに合わせて前記受取人を修正することにより前記支払いプロセスを開始することを特徴とする請求項１に記載のコンピュータ処理システム。
21. 前記支払い配分モジュールが、前記支払人の口座から前記受取人へ前記全契約受取額を自動的に送ることによって前記支払いプロセスを開始することを特徴とする請求項１に記載のコンピュータ処理システム。
22. 前記登録モジュールが、前記複数の受取人の少なくとも一つへ前記支払人による定期循環払い契約を登録し、前記定期循環払い契約に従い支払契約を登録することを特徴とする請求項１に記載のコンピュータ処理システム。
23. 複数の支払人と複数の受取人の間での少額決済を円滑にする為の方法であって、
    前記複数の支払人によってなされ、前記複数の支払人における全契約支払額に寄与する第一の複数の支払契約についての情報をデータベース内にある一つ以上のテーブル内に登録する手順、
    前記複数の受取人に対してなされ、前記複数の受取人における全契約受取り額に寄与する第二の複数の支払契約についての情報をデータベース内にある一つ以上のテーブル内に登録する手順、
    リスク情報を用いて計算されるリスク値を利用する関数を適用することによって、前記複数の受取人の各々におけるリスク調整された全契約受取額を計算する手順、
    前記全契約支払額が、前記複数の支払人の各々における所定の支払閾値額を超えるかどうか、および、前記リスク調整された全契約受取額が、前記複数の受取人の各々における所定の受取閾値額を超えるかどうかを判定する手順、
    前記受取閾値額を超えるリスク調整された全契約受取額を、資金納入待ち列に入力する手順、
    前記全契約支払額が前記所定の支払閾値額を超えると判定された後、前記支払人からの契約支払総額と同じまたはそれ以上である、前記資金納入待ち列内のリスク調整された全契約受取額を持つ一つ以上の資格のある受取人を判別する手順、および、
    前記判別された受取人のうちで前記支払人により指定された受取人に対してその全契約受取額の支払いのための支払いプロセスを開始する手順、
    を含み、
    前記計算する手順が、前記複数の支払契約についての情報に基づいて、前記テーブル内の前記複数の支払人および前記複数の受取人のそれぞれにおける契約支払いバランスおよび契約受取りバランスを電子計算機を用いて計算して更新することを特徴とする方法。
24. 前記データベース内にある前記一つ以上のテーブルは、前記複数の支払契約の各々が資金納入されたか否かの指標を含み、関連する支払人が前記一つ以上の資格のある受取人への支払契約のための支払いを行ったとき、通知を受信し、その後、前記複数の支払契約の各々が資金納入されたか否かの更新通知を受信することを含む請求項２３に記載の方法。
25. 前記リスク値が前記支払人および前記受取人の少なくとも一方に関連したリスクプロファイルを含んでいる請求項２３に記載の方法。
26. 前記リスクプロファイルが、取引履歴、支払い履歴、商取引フィードバック、及び支払いフィードバックを含むリスク指数のグループの中のいずれか１つ又はそれよりも多くを利用して決定される請求項２５に記載の方法。
27. 前記支払人によってなされる前記第一の複数の支払契約が期限を超えてなされ、そして前記全契約支払額が前記第一の複数の支払契約における各支払契約を反映する為に前記期限を超えて修正される請求項２３に記載の方法。
28. 前記受取人にむけてなされる前記第二の複数の支払契約が期限を超えてなされ、そして前記全契約受取額が前記第二の複数の支払契約における各支払契約を反映する為に前記期限を超えて修正される請求項２３に記載の方法。
29. 前記第一および第二の各複数の支払契約についての前記情報の登録が、前記支払人および前記受取人がネットワークを経由して接続されたサーバーでなされる請求項２３に記載の方法。
30. 前記第一および第二の各複数の支払契約についての前記情報の登録が、前記支払人および前記受取人に関連しネットワークを経由して接続された第一および第二のマシンのそれぞれでなされる請求項２３に記載の方法。
31. 前記複数の受取人の各々における複数の受取額が前記資金納入待ち列に配分され、前記方法は、前記支払人にむけた複数の受取額を確認し、そして前記支払人における前記全契約支払額によって返済されるべき受取額の少なくとも一つを、前記支払人によって選択可能にすることを含んでいる請求項２３に記載の方法。
32. 前記複数の受取額の確認が、前記支払人に前記複数の受取人の各々を個別に知らせることを含んでいる請求項３１に記載の方法。
33. 前記所定の受取閾値額が、前記複数の受取人によって決められる請求項２３に記載の方法。
34. 前記所定の受取閾値額が、前記複数の受取人に関連した属性によって決められる請求項２３に記載の方法。
35. 前記所定の支払閾値額が前記複数の支払人によって決められる請求項２３に記載の方法。
36. 前記所定の支払閾値額が、前記複数の支払人に関連した属性によって決められる請求項２３に記載の方法。
37. 前記支払いプロセスの開始が、前記受取人にむけて前記全契約受取額の支払いをするように前記支払人へ指示を与えることを含んでいる請求項２３に記載の方法。
38. 前記支払いプロセスの開始が、前記支払人から受け取るべき前記全契約受取額の支払いの受取りに関して前記受取人へ通知をすることを含んでいる請求項２３に記載の方法。
39. 前記支払いプロセスの開始が、前記支払人が前記受取人へ前記全契約受取額の支払いをするのに利用する支払いサービスに前記支払人を導くことを含んでいる請求項２３に記載の方法。
40. 前記支払いプロセスの開始が、前記受取人が前記全契約受取額を受け取ることができるのに利用する支払いサービスに前記受取人を導くことを含んでいる請求項２３に記載の方法。
41. 前記支払いプロセスの開始が、前記支払人の口座から前記受取人へ前記全契約受取額を自動的に送金することを含んでいる請求項２３に記載の方法。
42. 前記複数の受取人の少なくとも一つにむけて前記支払人による定期循環払い契約を登録すること、および前記定期循環払い契約に従い支払契約を登録することを含んでいる請求項２３に記載の方法。

Images