JP2003016368A - 電子決済処理システム - Google Patents

Abstract

(57)【要約】 【解決手段】 グループ企業の間で、取引に関する決済
は、仮想決済処理機能部３０が、グループ企業間でのみ
有効な仮想マネーを各取引者間で移動させることにより
行う。決済時期毎に、仮想決済額と運用口座１６への入
金額を比較して、最低限、運用口座への入金額が仮想決
済額を下回らないように 【効果】 任意の取引者間で一定の担保のもとに決済に
使われる資金を運用して、ネットワークを利用した安全
かつ効率のよい商取引を実現させる

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、グループ企業間の
商取引に伴う決済処理に必要な準備資金を効率良く運用
することができる電子決済処理システムに関する。

【０００２】

【従来の技術】例えば、グループ企業の間では、Ａ社か
らＢ社へ原材料を供給し、Ｂ社がその原材料を加工し
て、再びＡ社に納めるといった取引が頻繁に行われてい
る。通常は２社間の取引に止まらず、３社以上の企業間
で相互に様々な形態で取引が行われている。これらの企
業が、それぞれ独立した経理を行っているときは、それ
ぞれ、取引契約に定められた決済時期がくると、売掛金
や買掛金の決済業務を行う。即ち、各社個別に請求額に
応じた金額を銀行振り込み等の手段で決済している。

【０００３】

【発明が解決しようとする課題】ところで、上記のよう
な従来の技術には、次のような解決すべき課題があっ
た。一般に、取引の結果生じた決済に必要な資金は、各
社がそれぞれ決済時期までプールして、決済時期に送金
に充てる。多数の関連企業を含む大規模なグループ企業
では、グループに属する全ての企業が決済のためにプー
ルしておく資金の合計額は非常に多額になる。決済時期
毎にグループ企業間で所定の資金が相互に移動して決済
が行われている場合に、決済のために使用されている資
金は、グループ全体から見た場合には、必ずしも有効に
活用されているとはいえない。また、各企業はそれぞれ
その資金を調達するために利息を払って銀行から借り入
れを行っている。この利息の支払いもグループ全体から
見た場合に無視できないほどの額になる。また、決済に
使われる資金は、他の用途に使うことができないから、
多額の資金が行き来しても、何も利益を生み出さない。

【０００４】本発明は、資本関係のあるグループ企業間
のみならず、任意の取引者間で一定の担保のもとに、決
済に使われる資金を運用して、ネットワークを利用した
安全かつ効率のよい商取引を実現させる商取引システム
を提供することを目的とする。

【０００５】

【課題を解決するための手段】本発明は以上の点を解決
するため次の構成を採用する。 〈構成１〉予め定められた取引者間における所定の対象
に係わる商取引の結果を表示する取引情報を、上記各取
引者がネットワークを通じて閲覧できるサーバ上に保持
する記憶手段と、少なくとも上記取引者間で有効な仮想
マネーを各取引者間で移動させることにより上記取引情
報に基づく決済処理を実行する仮想決済処理手段と、上
記各取引者毎に各取引者の上記仮想マネーによる決済額
に応じた現金が資金運用のための所定の運用口座に入金
されているかどうかを監視して、所定のタイミングでそ
の結果を出力する口座監視手段とを備えたことを特徴と
する電子決済処理システム。

【０００６】〈構成２〉構成１に記載の電子決済処理シ
ステムにおいて、上記記憶装置には、サーバ上に各取引
者の仮想マネー移動状態を示す仮想決済データが記憶さ
れ、運用口座は、金融機関の実在の口座に設けられるこ
とを特徴とする電子決済処理システム。

【０００７】〈構成３〉構成１に記載の電子決済処理シ
ステムにおいて、上記記憶装置には、各取引者の運用口
座への入金情報を含む取引者情報が、ネットワークを通
じて各取引者に閲覧される状態で保持されていることを
特徴とする電子決済処理システム。

【０００８】〈構成４〉構成１に記載の電子決済処理シ
ステムにおいて、上記記憶装置には、各取引者の運用口
座への入金情報を含む取引者情報が、ネットワークを通
じてそれぞれ特定の制限された取引者に閲覧される状態
で保持されていることを特徴とする電子決済処理システ
ム。

【０００９】〈構成５〉構成１に記載の電子決済処理シ
ステムにおいて、上記取引情報は、全ての取引者の商取
引の結果をリアルタイムに表示し、上記仮想決済処理手
段は、上記取引情報に基づく決済処理計算をリアルタイ
ムに実行して、運用口座への入金額が仮想決済額を下回
らないかどうかを比較してその判定結果を出力すること
を特徴とする電子決済処理システム。

【００１０】〈構成６〉構成１に記載の電子決済処理シ
ステムにおいて、サーバ上には、取引者情報に基づい
て、各取引者の運用口座への入金額が、少なくとも仮想
決済額を越える一定の基準額に満たないとき、当該取引
者の上記仮想決済額を上記運用口座の現金によって強制
的に精算させる精算処理手段を設けたことを特徴とする
電子決済処理システム。

【００１１】〈構成７〉構成１に記載の電子決済処理シ
ステムにおいて、サーバ上には、取引者情報に基づい
て、各取引者の運用口座への入金額が、少なくとも仮想
決済額に応じて定められた一定額を越える基準額に満た
ないとき、当該取引者の上記仮想決済額を上記運用口座
の現金によって強制的に精算させる精算処理手段を設け
たことを特徴とする電子決済処理システム。

【００１２】〈構成８〉予め定められた取引者間におけ
る所定の対象に係わる商取引の結果を表示する取引情報
を、上記各取引者がネットワークを通じて閲覧できるサ
ーバ上の記憶手段に保持する処理と、少なくとも上記取
引者間で有効な仮想マネーを各取引者間で移動させるこ
とにより上記取引情報に基づく決済処理を実行する処理
と、上記各取引者毎に各取引者の上記仮想マネーによる
決済額に応じた現金が資金運用のための所定の運用口座
に入金されているかどうかを監視して、所定のタイミン
グでその結果を出力する処理とを、コンピュータに実行
させるコンピュータプログラム。

【００１３】〈構成９〉構成８に記載のコンピュータプ
ログラムにおいて、取引者情報に基づいて、各取引者の
運用口座への入金額が、少なくとも仮想決済額を越える
一定の基準額に満たないとき、当該取引者の上記仮想決
済額を上記運用口座の現金によって強制的に精算させる
処理とを、コンピュータに実行させるコンピュータプロ
グラム。

【００１４】〈構成１０〉構成８に記載のコンピュータ
プログラムにおいて、取引者情報に基づいて、各取引者
の運用口座への入金額が、少なくとも仮想決済額に応じ
て定められた一定額を越える基準額に満たないとき、当
該取引者の上記仮想決済額を上記運用口座の現金によっ
て強制的に精算させる処理とを、コンピュータに実行さ
せるコンピュータプログラム。

【００１５】

【発明の実施の形態】以下、本発明の実施の形態を具体
例を用いて説明する。図１は、本発明の電子決済処理シ
ステムの具体例を示すブロック図である。図のシステム
は、あらかじめ一定の契約をした複数の企業からなるグ
ループによって運営される。図の例では、Ａ社、Ｂ社、
Ｃ社、Ｄ社の端末、２、３、４、５がネットワーク１を
介してサーバ１０と接続され、商取引に基づく決済処理
を一括して行うように構成されている。サーバ１０の記
憶装置には、イベント管理データ１１、決済条件データ
１２、買掛金データ１３、売掛金データ１４、仮想決済
データ１５などが記憶されている。これらのデータを一
括して取引情報と呼ぶ。これらの取引情報は、ネットワ
ーク１を通じて各社の端末２〜５により閲覧できるよう
に構成されている。

【００１６】サーバ１０には、システム運用のために、
口座監視機能部２１、精算処理機能部２３、受発注管理
機能部２５、出荷管理機能部２６、納品管理機能部２
７、決済条件管理機能部２８、売掛金管理機能部２９、
仮想決済処理機能部３０、買掛金管理機能部３１が設け
られている。これらの機能部は、いずれもサーバ１０の
コンピュータに一定の処理を実行させるコンピュータプ
ログラムからなる。なお、サーバ１０のコンピュータ本
体は従来どおりのものでよいから図示していない。口座
監視機能部２１は、銀行等の金融機関に設けられた運用
口座１６の内容をコピーした運用口座監視データ２２を
参照し、後で説明するようにして、仮想決済計算の結果
と運用口座残高とを比較する処理を実行する。精算処理
機能部２３は、後で説明するように運用残高の不足した
グループの構成員の仮想決済額を運用口座の現金によっ
て強制的に精算させる処理を行う部分である。

【００１７】受発注管理機能部２５は、グループ各社が
受発注取引を行った場合にその都度イベント管理データ
１１を更新処理する機能を持つ。出荷管理機能部２６や
納品管理機能部２７も同様にして、出荷処理、納品処理
のイベントが発生した場合にイベント管理データ１１を
更新する機能を持つ。決済条件管理機能部２８は、各社
それぞれの決済条件を決済条件データ１２として保持
し、必要に応じて変更があった場合にその内容を書き換
える等の管理を行う部分である。売掛金管理機能部２９
は、受発注出荷納品等の処理が行われた場合にその都度
売掛金データ１４を更新する機能を持つ。買掛金管理機
能部３１も売掛金管理機能部２９と同様にして、一定の
取引が行われた場合に買掛金データ１３を更新する機能
を持つ。仮想決済処理機能部３０は、後で説明する要領
で買掛金データ１３より売掛金データ１４を参照し、仮
想マネーを用いて仮想決済処理を実行する機能を持つ。
その結果は、仮想決済データ１５に記録される。

【００１８】このシステムでは、例えば、グループ企業
（取引者）相互間の取引について、その商取引の結果を
共通のデータベースに記録して、その取引情報を相互に
ネットワーク１を通じて閲覧できる状態にする。ネット
ワーク１はインターネット等の広域ネットワークや、ロ
ーカルエリアネットワーク等の任意の通信網でよい。対
象となる商取引は、商品に関するものでもサービスに関
するものでもよい。また、対象を特定の商品に限定して
もよい。グループ企業に含めるための資格は自由に定め
るとよい。必ずしも資本関係がなくてもよい。一定の信
用取引が可能な企業をグループに含めれば、本発明がよ
り効果を発揮する。

【００１９】対象となる取引に関する決済は、グループ
企業間でのみ有効な仮想マネーを各取引者間で移動させ
ることにより行う。売掛金と買掛金の相互承認処理によ
り一方が他方に支払うべき金額が算出されて承認されれ
ばよいとする方法もある。また、実際にグループ内では
現金と等価に通用する仮想マネーを移動させることによ
り、企業がグループから脱退するような場合の精算が容
易になる。以下の説明では、仮想マネーが移動する場合
も、実際にデータが移動しない場合も含めて、グループ
企業間の貸し借りが明確になる処理のことを仮想決済処
理と呼ぶことにする。

【００２０】仮想決済処理を安全に行うには、決済に必
要な、仮想マネーの額に相当する額の現金を実際に各取
引者が保有していることが前提になる。そこで、各取引
者毎に、仮想マネーによる決済額に応じた現金が所定の
口座に入金されているかどうかを監視する口座監視機能
部２１を設ける。この運用口座１６は、各取引者が自由
に預金を出し入れできるようでは資金を確保したことに
ならない。従って、運用口座は資金運用のための金融機
関の特定の口座とする。この運用口座には、グループ企
業全ての仮想マネーによる決済額に応じた現金が集めら
れることが好ましい。運用口座は金融機関の実在の口座
である。

【００２１】こうすれば、この運用口座１６に入金され
た現金を、グループ企業の合意のもとに、例えば、銀行
の定期預金として活用し、リスクの少ない確実な運用が
可能になる。この例の場合には、運用口座１６からの出
金は無いから、運用口座１６への入金額が仮想決済額を
常に下回らないように監視すればよい。もちろん、グル
ープ各社の同意があれば、運用口座の資金を株式運用等
に使用することもできる。しかも、頻繁に相互に送金を
行う場合に比べて送金手数料の節約ができる。

【００２２】このシステムでは、運用口座１６に入金さ
れた現金の内訳、即ち、どの取引者がどれだけの額を入
金したかを示す情報が必要になる。口座監視機能部２１
は、運用口座１６の入出金情報を逐次収集して出力する
ことが好ましい。出力先は、グループ各社の端末２、
３、４、５である。図示しない管理端末に出力してもよ
い。この情報を出力するのは、仮想決済処理の安全を確
保するためである。故に定期的に、例えば１月毎に、全
てのグループ企業各社の入金額と、運用のための出金額
とを出力して、グループ各社に公表するようにするとよ
い。また、口座監視手段が誤りなく機能すれば、企業各
社の入金額や仮想決済額を公表しなくても、自動的に安
全が確保できる。

【００２３】この運用口座に入金された現金は、一定期
間有効に運用した後に、グループ企業間の実決済に使用
する。全ての取引者の仮想マネーによる決済額に応じた
現金が、この決済時期に運用口座に存在すれば、この実
決済は運用口座の残高の範囲内で行える。精算処理機能
部２３は、この実決済処理を実行する。各取引者の仮想
マネー移動のための仮想口座をサーバ上に設けると、各
取引者間の貸し借りが明確になる。仮想決済データ１５
は、仮想口座の内容を表示する。また、各取引者の運用
口座への入金情報を含む取引者情報が、サーバ１０上に
保持されていれば、その内容も、グループ企業各社で相
互に監視できる。さらに、データが集中しているので、
実決済処理のための演算処理が容易になる。

【００２４】図２（ａ）は、イベント管理データの例を
示す説明図、（ｂ）は買掛金データの例を示す説明図、
（ｃ）は売掛金データの例を示す説明図である。イベン
ト管理データ１１には、グループ各社間で取引が発生し
た場合に発注元と発注先と発注日、出荷日、納品日、検
収日、品番、数量などのデータが記録される。これによ
ってどのような商取引がいつ行われ、いつ検収がされた
といった内容が明確になる。これが売掛金や買掛金計算
の根拠になる。このデータは、全てのグループ構成員に
閲覧できる必要はない。関係がある企業のみ閲覧できる
ようにして構わない。買掛金データは、図の（ｂ）に示
すようにそれぞれ企業毎にどの取引先に対しいくら買掛
金が存在し、その計上日がいつで、支払日がいつかとい
ったデータになる。売掛金データ１４は、（ｃ）に示す
ようにそれぞれどの企業がどの取引先に対し、いくら売
掛金を持ち、計上日がいつで入金日がいつといった内容
になる。

【００２５】上記のような買掛金データと売掛金データ
全てを参照して計算をすれば、どの企業がいくらどの企
業に対し決済を行う義務があるかといった点が全て明ら
かになる。従って、後で説明するような要領でグループ
に所属する企業間での仮想マネーによる決済処理を自動
的に行うことが可能になる。

【００２６】図３（ａ）は決済条件データの例を示す説
明図、（ｂ）は仮想決済データの例を示す説明図であ
る。決済条件データ１２には、（ａ）に示すようにそれ
ぞれ一定の商品についてその締日がいつで支払日がいつ
で決済が納品時か検収時か発注時か出荷時かといったデ
ータが記録される。これによって、決済のタイミングを
確認した上で各社の相互の決済処理が可能になる。仮想
決済データ１５は（ｂ）に示すように最終的に各社が決
済用の電子マネーとしてどれだけの額を用意しなければ
ならないかを示すデータである。このデータを得る前に
それぞれ各社がグループを構成する他の企業に個別にい
くら決済をしなければいけないかを計算し、これを集計
する。その集計額がこの仮想決済データに表れている。
例えば、Ａ社が決済時期にこの図に示すように７５０万
円を仮想決済用の電子マネーとして必要な場合に、これ
だけの資金が運用口座に入金されているかどうかを判断
しなければならない。そこでこのデータには、入金金額
が含められている。実際には、図１に示した運用口座監
視データ２２の内容が運用口座の金額が変更される都度
ここに転記されることになる。

【００２７】図４は具体的に例えば、Ａ社の商取引につ
いて取引情報の推移と運用口座との関係を示す説明図で
ある。図４（ａ）には、Ａ社のＢ社に対する売掛金と買
掛金の額の推移が示されている。図に示すように１月、
２月、３月と、それぞれ売掛金と買掛金の金額が棒グラ
フで示されている。１月の場合には売掛金が買掛金より
多くなっている。２月と３月の場合には売掛金よりも買
掛金の方が多くなっている。このデータに基づいて仮想
決済額を計算した結果が図の（ｂ）に示されている。こ
の図に示すように、Ａ社のＢ社に対する仮想決済額は、
１月はプラスである。２月と３月についてはマイナスで
ある。プラスというのは、Ｂ社からＡ社に仮想マネーの
入金があったことを意味する。マイナスはその反対であ
る。棒グラフは各月毎の仮想決済額であり、（ａ）に示
す月毎の売掛金と買掛金の差額に相当する。また、
（ｂ）に示す折線グラフは仮想決済額の累積値の推移を
示す。

【００２８】Ａ社は、３月の段階では、Ｂ社に仮想決済
額の累積値相当分の債務があることになる。従って、Ａ
社はＢ社との取引のために、この仮想決済額に相当する
運転資金をあらかじめ用意していなければならない。図
４（ｃ）に示すように運用口座には１月、２月、３月と
いうように、その都度順次必要な資金を入金しておく。
例えば、３月の運用口座の残高は、図の（ｂ）に示す折
線グラフの３月のレベルよりも多くなければ、実際の運
用口座の現金で電子マネーを精算することができない。
従って、ここでは、Ａ社のＢ社に対する仮想決済額や運
用口座の金額を説明したが、他の全ての企業に対する仮
想決済額や運用口座の額を計算し、それらを累積した金
額の現金が運用口座に入金されているように運用しなけ
ればならない。なお、このように複数の企業に対する仮
想決済額の累積を行い、必要な運転資金を計算すると、
ある企業に対しては、仮想決済額がプラスになり、ある
企業に対しては仮想決済額がマイナスになるという現象
が起きる。従って、これらを集計すると、全体としては
累積値が比較的少額になり、運用口座に入金しておかな
ければならない金額が多額にならないという効果があ
る。こうして、運用口座に仮想決済額を担保できるだけ
の額の現金を入金しておけば、後で説明するようにして
一定の運用により利益を受けることが可能になる。

【００２９】ところで、いずれかの取引者の運用口座へ
の入金額が、仮想マネーによる決済額を下回る事態が発
生すると、取引の安全が確保できない。そこで、口座監
視機能部２１の出力が関係者に提供される。さらに、取
引者の運用口座への入金額が、例えば仮想マネーによる
決済額を越える一定の基準額に満たないときには、その
取引者を自動的にグループ企業から排除するとよい。こ
の場合には、当該取引者の前記仮想マネーによる決済額
に相当する額を前記運用口座のそれまでの入金残高によ
って強制的に精算させる。これで、残りの取引者はその
まま安全に仮想マネーによる決済システムを続行でき
る。

【００３０】上記のシステムでは、決済時期毎に、仮想
決済額と運用口座への入金額を比較して、最低限、運用
口座への入金額が仮想決済額を下回らないように運営を
した。しかしながら、決済時期に至る前に一時的に運用
口座への入金額が仮想決済額を下回る場合も生じ得る。
従って、より厳格に安全にシステムを運営するには、常
に口座監視機能部２１がリアルタイムに各社の一時仮想
決済額を計算して、運用口座への入金額が一時仮想決済
額をいかなる場合にも下回らないように運営をすること
もできる。

【００３１】図５は、本発明のシステムの具体的な動作
を示すフローチャートである。まず、ステップＳ１にお
いて、あらかじめサーバ１０の決済条件データ１２に対
し、各社の決済条件データが入力される。これによりシ
ステム運営の準備ができる。次にステップＳ２におい
て、データのイニシャライズを行う。このイニシャライ
ズは、仮想決済処理が行われたとき、その都度実行され
る。その後各社相互の商取引即ち、何らかのイベントが
発生したかどうかを監視する（ステップＳ３）。そして
イベントが発生した場合には、ステップＳ４に進み、イ
ベント管理データ１１への記録が行われる。さらにステ
ップＳ５に進んで、買掛金データ１３や売掛金データ１
４へのデータ入力が行われ、これらのデータが更新され
る。次にステップＳ６において決済時期がきたかどうか
の判断がされる。

【００３２】決済時期がくるまでは、イベント管理デー
タ１１、買掛金データ１３、売掛金データ１４の更新が
順次行われる。決済時期がきた場合にはステップＳ７に
進み、まず、仮想決済処理機能部３０が決済処理計算を
実行する。この計算結果はまだ仮想決済データ１５に反
映しない。ステップＳ８の運用口座監視処理を先に行
う。

【００３３】図６は、運用口座監視処理のための動作フ
ローチャートである。まず、図の（ａ）に示すように、
口座監視機能部２１は、一定の時間おきにタイマをオン
させてステップＳ２１からステップＳ２２に進み、運用
口座１６の残高照会を行う。そしてその結果を運用口座
監視データ２２に記録する（ステップＳ２３）。このよ
うにしてリアルタイムで運用口座の内容を運用口座監視
データ２２に記録しておき、仮想決済処理機能部３０の
仮想決済計算が行われると、図６（ｂ）に示す処理が実
行される。

【００３４】ステップＳ３１では、運用口座残高と決済
金額との比較が行われる。そして、運用口座１６への入
金額が不足しているかどうかの判断が行われる（ステッ
プＳ３２）。入金額が不足していなければ、運用口座監
視処理を終了する。その後図５のステップＳ９に進む。
もし、入金額が不足していれば、ステップＳ３３に進
み、運用口座に残っている運用資金で仮想決済額を精算
する処理を実行する。即ち、銀行に対し、仮想決済額に
相当する額を各社に送金するように処理をして、精算を
完了させる。そしてステップＳ３４に進み、該当する企
業をグループから除外するように登録除外処理を行う。
このように運用資金が不足した場合には、自動的にグル
ープから該当する企業を除外するようにしてこのシステ
ム運用の安全を計る。なお、運用口座残高と決済金額と
を比較した場合に例えば、運用口座の残高の方が決済金
額よりも必ず一定額以上多いというように条件を決めて
おくのが最も安全である。しかしながら、例えば、決済
金額の３０％以上運用口座残高があればよいとするケー
スも可能である。これは、グループ各社間の信頼関係と
各社間の資産との関係で自由に設定すればよい。

【００３５】図５に戻って、運用口座監視処理で入金額
が不足していないと判断されるとステップＳ９に進み、
仮想決済処理が現実に実行される。即ち仮想決済データ
１５を更新して、電子マネーを現実に移動させる。ここ
でステップＳ１０において精算処理を行う時期がきたか
どうかを判断する。精算処理をする時期がきていない場
合には、電子マネーの仮想決済処理だけを行って、ステ
ップＳ２に戻り、データのイニシャライズを行って、再
びシステムを運営する。なお、データのイニシャライズ
では、実際に過去のデータを消去するという必要はな
く、仮想決済処理を新たに行う場合にその決済の期間を
明確にし、次の期間の決済処理が行えるような環境を整
えれば足りる。なお、ステップＳ１０において精算期で
あると判断すると、ステップＳ１０からステップＳ１１
に進み、精算処理が行われる。このときは実際に運用口
座の現金を各社に仮想決済額に相当する分振り込みし
て、全ての企業の仮想決済額相当分を精算する。そして
再びデータをイニシャライズしてシステムの運営を進め
る。

【００３６】なお、図１に示した各機能ブロックは、そ
れぞれ別々のプログラムモジュールにより構成してもよ
いし、一体化したプログラムモジュールにより構成して
もよい。また、これらの機能ブロックの全部または一部
を論理回路によるハードウエアで構成しても構わない。
また、各プログラムモジュールは、既存のアプリケーシ
ョンプログラムに組み込んで動作させてもよいし、独立
のプログラムとして動作させてもよい。上記のような本
発明を実現するためのコンピュータプログラムは、例え
ばＣＤ−ＲＯＭのようなコンピュータで読み取り可能な
記録媒体に記録して、インストールして利用することが
できる。また、ネットワークを通じてコンピュータのメ
モリ中にダウンロードして利用することもできる。

【発明の効果】グループ各社の、例えば半期分の決済準
備資金を、所定の運用口座にプールして投資等の運用に
利用すると、資金の有効な活用が図れ、利益を生み出す
ことができる。また、短期間毎に決済し送金をする手間
が省け、送金手数料を節約できる。このような一括決済
を相互に行う企業は、いずれも充分に信頼のおける企業
であって、取引の内容を必要な範囲で相互に公開できる
企業でなければならない。本発明では、グループ企業各
社の運用口座の内容をサーバ上で公開して、各社の運用
口座への入金額を監視し、各社の運用口座への入金額
が、少なくとも仮想マネーによる決済額を越える一定の
基準額にあることを担保する。この基準額に満たないと
きは、該当する企業をグループから自動的に排除するこ
ともできる。従って、それぞれ全く資本関係のない取引
者が一定の契約のもとにグループを形成することも可能
になる。

【図面の簡単な説明】

【図１】本発明の電子決済処理システムの具体例を示す
ブロック図である。

【図２】（ａ）は、イベント管理データの例を示す説明
図、（ｂ）は買掛金データの例を示す説明図、（ｃ）は
売掛金データの例を示す説明図である。

【図３】（ａ）は決済条件データの例を示す説明図、
（ｂ）は仮想決済データの例を示す説明図である。

【図４】具体的に例えば、Ａ社の商取引について取引情
報の推移と運用口座との関係を示す説明図である。

【図５】本発明のシステムの具体的な動作を示すフロー
チャートである。

【図６】運用口座監視処理のための動作フローチャート
である。

【符号の説明】

１ ネットワーク ２〜５ 端末 １０ サーバ １１ イベント管理データ １２ 決済条件データ １３ 買掛金データ １４ 売掛金データ １５ 仮想決済データ １６ 運用口座 ２１ 口座監視機能部 ２２ 運用口座監視データ ２３ 精算処理機能部 ２５ 受発注管理機能部 ２６ 出荷管理機能部 ２７ 納品管理機能部 ２８ 決済条件管理機能部 ２９ 売掛金管理機能部 ３０ 仮想決済処理機能部 ３１ 買掛金管理機能部

Claims (10)

【特許請求の範囲】
1. 【請求項１】 予め定められた取引者間における所定の
   対象に係わる商取引の結果を表示する取引情報を、前記
   各取引者がネットワークを通じて閲覧できるサーバ上に
   保持する記憶手段と、 少なくとも前記取引者間で有効な仮想マネーを各取引者
   間で移動させることにより前記取引情報に基づく決済処
   理を実行する仮想決済処理手段と、 前記各取引者毎に各取引者の前記仮想マネーによる決済
   額に応じた現金が資金運用のための所定の運用口座に入
   金されているかどうかを監視して、所定のタイミングで
   その結果を出力する口座監視手段とを備えたことを特徴
   とする電子決済処理システム。
2. 【請求項２】 請求項１に記載の電子決済処理システム
   において、 前記記憶装置には、サーバ上に各取引者の仮想マネー移
   動状態を示す仮想決済データが記憶され、 運用口座は、金融機関の実在の口座に設けられることを
   特徴とする電子決済処理システム。
3. 【請求項３】 請求項１に記載の電子決済処理システム
   において、 前記記憶装置には、各取引者の運用口座への入金情報を
   含む取引者情報が、ネットワークを通じて各取引者に閲
   覧される状態で保持されていることを特徴とする電子決
   済処理システム。
4. 【請求項４】 請求項１に記載の電子決済処理システム
   において、 前記記憶装置には、各取引者の運用口座への入金情報を
   含む取引者情報が、ネットワークを通じてそれぞれ特定
   の制限された取引者に閲覧される状態で保持されている
   ことを特徴とする電子決済処理システム。
5. 【請求項５】 請求項１に記載の電子決済処理システム
   において、 前記取引情報は、全ての取引者の商取引の結果をリアル
   タイムに表示し、 前記仮想決済処理手段は、前記取引情報に基づく決済処
   理計算をリアルタイムに実行して、運用口座への入金額
   が仮想決済額を下回らないかどうかを比較してその判定
   結果を出力することを特徴とする電子決済処理システ
   ム。
6. 【請求項６】 請求項１に記載の電子決済処理システム
   において、 サーバ上には、取引者情報に基づいて、各取引者の運用
   口座への入金額が、少なくとも仮想決済額を越える一定
   の基準額に満たないとき、当該取引者の前記仮想決済額
   を前記運用口座の現金によって強制的に精算させる精算
   処理手段を設けたことを特徴とする電子決済処理システ
   ム。
7. 【請求項７】 請求項１に記載の電子決済処理システム
   において、 サーバ上には、取引者情報に基づいて、各取引者の運用
   口座への入金額が、少なくとも仮想決済額に応じて定め
   られた一定額を越える基準額に満たないとき、当該取引
   者の前記仮想決済額を前記運用口座の現金によって強制
   的に精算させる精算処理手段を設けたことを特徴とする
   電子決済処理システム。
8. 【請求項８】 予め定められた取引者間における所定の
   対象に係わる商取引の結果を表示する取引情報を、前記
   各取引者がネットワークを通じて閲覧できるサーバ上の
   記憶手段に保持する処理と、 少なくとも前記取引者間で有効な仮想マネーを各取引者
   間で移動させることにより前記取引情報に基づく決済処
   理を実行する処理と、 前記各取引者毎に各取引者の前記仮想マネーによる決済
   額に応じた現金が資金運用のための所定の運用口座に入
   金されているかどうかを監視して、所定のタイミングで
   その結果を出力する処理とを、コンピュータに実行させ
   るコンピュータプログラム。
9. 【請求項９】 請求項８に記載のコンピュータプログラ
   ムにおいて、 取引者情報に基づいて、各取引者の運用口座への入金額
   が、少なくとも仮想決済額を越える一定の基準額に満た
   ないとき、当該取引者の前記仮想決済額を前記運用口座
   の現金によって強制的に精算させる処理とを、コンピュ
   ータに実行させるコンピュータプログラム。
10. 【請求項１０】 請求項８に記載のコンピュータプログ
    ラムにおいて、 取引者情報に基づいて、各取引者の運用口座への入金額
    が、少なくとも仮想決済額に応じて定められた一定額を
    越える基準額に満たないとき、当該取引者の前記仮想決
    済額を前記運用口座の現金によって強制的に精算させる
    処理とを、コンピュータに実行させるコンピュータプロ
    グラム。