JP4300257B2

JP4300257B2 - Electronic payment system

Info

Publication number: JP4300257B2
Application number: JP01296697A
Authority: JP
Inventors: 裕典若山
Original assignee: Individual
Current assignee: Individual
Priority date: 1997-01-27
Filing date: 1997-01-27
Publication date: 2009-07-22
Anticipated expiration: 2017-01-27
Also published as: JPH10207956A

Description

【０００１】
【発明の属する技術分野】
本発明は、電子決済システムに関し、特に仮想空間領域において、遠隔での商品の発注と、発注商品との決済及び実際に商品を配送をするセキュリテイを確保した電子商取引を構築する電子決済システムに関するものである。
【０００２】
【従来の技術】
従来から流通している、決済システムは、図１５に示すように、ユーザーとＥＣ（ＥｒｃｔｒｏｎｉｃＣｏｍｍｅｒｃｅ）間において商取引を行うもので、決済時期が３種類に分類される。
【０００３】
第１の分類は、図１５（イ）に示すように、決済時期が配送時の場合であり、ユーザーがＥＣに発注すると、ＥＣ側から、ユーザーに自己配達をし、且つ配送時において代金を回収するシステムである。
【０００４】
第２の分類は、図１５（ロ）に示すように、ユーザー側からＥＣに対して予約をして物品を購入する手法であり、この場合の決済時期は、例えばユーザーが来店した時に決済する。
【０００５】
第３の分類は、図１５（ハ）に示すように、ユーザーからＥＣに発注すると、ＥＣ側から物品が配送され、且つ請求書も発行される。この決済時期は、数ヶ月以内に自動引落し、月次決済、発生時に決済する等がある。
【０００６】
このような３種類に分類される決済システムにおいて商品を購入するためには社会に流通している貨幣又は電子マネーがある。
【０００７】
電子マネーは、クレジットタイプのもの、ネットワークタイプのもの、ネットワークとＩＣカードを組み合わせたもの、ＩＣカードタイプのものがあり、これらは、全て社会に流通している貨幣の代用として使用される。例えば、ＩＣカードでの商品の購入は、所望の商品を特定したときに、ＩＣカードがその代金を支払ったようにして、後日別のルートにより、ＩＣカードで支払った代金の決済を上記決済システムの手法により行う。
【０００８】
このようなＩＣカードの他に、現在のクレジットカードと同様に現金社会の中で使用するＩＣカードによる決済がある。いわゆるモンデックス型といわれるＩＣカードによる決済は、先ず銀行等の金融機関と契約してエレクトロニック・ウオレット・サーバー用口座を開設して入金する。そして、暗証番号及び暗号鍵を内蔵したＩＣカードの発行を受ける。通信回線によりＩＣカードにエレクトロニック・ウオレット・サーバーの預金口座からエレクトロニック・マネー（ＥＭ）を移す。
この移されたＥＭ分だけＩＣカードの利用ができ、従って、予め決められた金額をＩＣカードで使用することができるようになっている。
【０００９】
又、このような電子マネーを利用した商取引においては、セキュリテイを確保することが重要であり、そのためには、（１）ＩＤ＋パスワード、（２）通信暗号化システム（例えばセキュリテイカードを使用する）、（３）電子署名システム、（４）業務フロー全体が１つのセキュリテイ機構を形成するようにする等により安全性を図っている。
【００１０】
【発明が解決しようとする課題】
しかしながら、上記従来技術で説明した商取引において使用される電子マネーは、即ち、クレジットカードとの提携型であるいわばカード会社による仮想空間における決済システムであり、商品を配送及び管理等するトランスポート・カンパニー・サーバーや、複数の商品を手配したり管理するサイバー・ショップ・サーバー等を含め、且つ相互に承認及び保証すると云うシステムにはなっていないため、仮想空間における商取引で重要な根幹をなす商品の存在の証明及び決済金額の証明ができないと云う問題点がある。
【００１１】
従って、仮想都市を構築した場合における電子商取引において、少なくとも商品の存在の証明及び決済金額の存在を証明できるシステムに解決しなければならない課題を有している。
【００１２】
【課題を解決するための手段】
上記課題を解決するために、本発明に係る電子決済システムは、商品の発注及び購入を端末機器を介して行うユーザーと、該ユーザーに前記商品の購入決済金があることを証明及び保証するために行われる預託行為を含む金銭出納管理をする単独又は複数のエレクトロニック・ウオレット・サーバーと、前記ユーザーが購入する前記商品を取り揃え且つ単独若しくは複数の商品仕入先との受発注管理を行う複数のサイバー・ショップ・サーバーと、前記ユーザーが選択した商品の自動的な配送及び集荷の情報を収集し、且つ該商品の集荷・配送及び管理を行い、配送が完了したことを証明する単独又は複数のトランスポート・カンパニー・サーバーと、前記ユーザーとエレクトロニック・ウオレット・サーバーとサイバー・ショップ・サーバーとトランスポート・カンパニー・サーバーとのそれぞれと個別に通信回線を介して接続し、該接続された全体を組織的に統合すると共に取引履歴をデータベース上に記録・保管し、且つクーリングオフシステムにより予め設定されているクーリングオフ期間に基づいて最終的な商品の存在を証明するラピュタ・コマース・サーバーとから構成され、前記ラピュタ・コマース・サーバーに接続されたそれぞれのユーザーとエレクトロニック・ウオレット・サーバーとサイバー・ショップ・サーバーとトランスポート・カンパニー・サーバーとの相互間の通報、証明、保証を前記ラピュタ・コマース・サーバーを介して行い、且つ前記商品のキャンセル処理及び前記クーリングオフ期間に基づく処理を電子仮想空間上において普遍的にルール化して行うようにしたことである。
【００１３】
このように構成した電子決済システムは、通信回線を介した商取引において事前にユーザー側の資金と商品を販売するメーカー側の商品在庫を電子的に照合することができ、且つユーザーの資金は預託によりエレクトロニック・ウオレット・サーバーが保証し、商品はサイバー・ショップ・サーバーが保証し且つ商品の配達はトランスポート・カンパニー・サーバーが保証することができ、時空を超えた電子仮想空間における商取引の安全性を確保することができ、具体的にはインターネットに代表される電子仮想空間上の電子商取引に関する受注発注管理、物流管理、預託決済管理に基づいて商品とその決済代金の存在を保証する商取引のシステムを構築することができる。
【００１４】
【発明の実施の形態】
次に、本発明に係る電子決済システムについて図面を参照にして説明する。
【００１５】
本発明に係る電子決済システムは、図１に示すように、商品の発注及び購入を端末機器を介して行うユーザー（Ｕｓｅｒ；ＵＲ）と、このユーザーＵＲに商品の購入決済金があることを証明及び保証するために行われる預託行為を含む金銭出納管理をする単独又は複数のエレクトロニック・ウオレット・サーバー（ＥｌｅｃｔｒｏｎｉｃＷａｌｌｅｔＳｅｒｖｅｒ；ＥＷＳ）と、ユーザーＵＲが購入する商品をこのシステム上で取り揃えて販売し、そのための単独若しくは複数の商品仕入先との受発注管理を行う複数のサイバー・ショップ・サーバー（ＣｙｂｅｒＳｈｏｐＳｅｒｖｅｒ；ＣＳＳ）と、ユーザーＵＲが選択した商品を本システム上から自動的に配送及び集荷の情報を収集し、この商品の集荷・配送及び管理を行い、配送が完了したことを証明する、即ち、商品の存在を証明するための単独又は複数のトランスポート・カンパニー・サーバー（ＴｒａｎｓｐｏｒｔＣｏｍｐａｎｙＳｅｒｖｅｒ；ＴＣＳ）と、ユーザーＵＲとエレクトロニック・ウオレット・サーバーＥＷＳとサイバー・ショップ・サーバーＣＳＳとトランスポート・カンパニー・サーバーＴＣＳとのそれぞれと個別に専用若しくは公衆の通信回線を介して接続し、この接続された全体を組織的に統合すると共に取引履歴をデータベース（ＤａｔａＢａｓｅ；ＤＢ）上に記録・保管し、且つクーリングオフシステムにより予め設定されているクーリングオフ期間をカウントダウンすることによって最終的な商品の存在を証明するラピュタ・コマース・サーバー（ＬａｐｕｔａＣｏｍｍｅｒｃｅＳｅｒｖｅｒ；ＬＣＳ）とから構成されている。
【００１６】
エレクトロニック・ウオレット・サーバーＥＷＳは、イーサネットを介して金融機関のバンクサーバーと接続してイントラネットを形成し、イントラネットを形成したエレクトロニック・ウオレット・サーバーＥＷＳは、インターネットを介してラピュタ・コマース・サーバーＬＣＳにイーサネットで接続しているエレクトロニック・ウオレット・デュプリカント・サーバー（ＥｌｅｃｔｒｏｎｉｃＷａｌｌｅｔＤｕｐｌｉｃａｎｔＳｅｒｖｅｒ；ＥＷＤＳ）に接続されている。このようにエレクトロニック・ウオレット・デュプリカント・サーバーＥＷＤＳを介してエレクトロニック・ウオレット・サーバーＥＷＳとラピュタ・コマース・サーバーＬＣＳとを接続したのは、ＣＧＩやＳＳＩを用いたシステムの場合、直接に相手方に書き込むシステムに比べ、リクエスト及び回答で二重にトランザクションが発生する為トラフイックが倍の密度になってしまい、更に、デーモンプログラムによる処理は頻繁なアクセスが発生する為、トラフイックに多大な負荷を与えてしまう。このようにただでさえトラフイックが過密なため、通信時間のかかりすぎやデータの紛失当の問題が発生してしまう。そのため、エレクトロニック・ウオレット・デュプリカント・サーバーＥＷＤＳを設置してイーサネットによって対応して、通信時間のかかりすぎやデータの紛失等の問題を解決している。
【００１７】
サイバー・ショップ・サーバーＣＳＳは、複数のホールセラー（Ｗｈｏｌｅｓａｌｅｒ；ＷＳ）と複数のファクトリ（Ｆａｃｔｏｒｙ；ＦＣ）とでイントラネットを構築してＣＡＬＳを形成し、且つサイバーショップサーバーＣＳＳは、インターネットを介してラピュタ・コマース・サーバーＬＣＳのサイバー・ショップ・デュプリカント・サーバー（ＣｙｂｅｒＳｈｏｐＤｕｐｌｉｃａｎｔＳｅｒｖｅｒ；ＣＳＤＰ）に接続された構成となっている。このサイバー・ショップ・デュプリカント・サーバーＣＳＤＰを介してラピュタ・コマース・サーバーＬＣＳに接続するようにしたのは、上述したエレクトロニック・ウオレット・デュプリカント・サーバーＥＷＤＳと同様の理由によるものであり、ＣＧＩやＳＳＩを用いたシステムの場合、リクエスト及び回答で二重にトランザクションが発生する為トラフイックが倍の密度になってしまうこと、及びデーモンプログラムによる処理は頻繁なアクセスが発生する為、トラフイックに多大な負荷を与えてしまい、トラフイックが過密になり、通信時間のかかりすぎやデータの紛失当の問題が発生してしまうため、サイバー・ショップ・デュプリカント・サーバーＣＳＤＰを設置してイーサネットによって対応し、通信時間のかかりすぎやデータの紛失等の問題を解決しているのである。
【００１８】
トランスポート・カンパニー・サーバーＴＣＳは、複数のブランチ（Ｂｒａｎｃｈ；ＢＲ）とからイントラネットを構築してＣＡＬＳを形成し、且つトランスポート・カンパニー・サーバーＴＣＳはインターネットを介してラピュタ・コマース・サーバーＬＣＳのトランスポート・カンパニー・デュプリカント・サーバー（ＴｒａｎｓｐｏｒｔＣｏｍｐａｎｙＤｕｐｌｉｃａｎｔＳｅｒｖｅｒ；ＴＣＤＰ）に接続された構成となっている。このトランスポート・カンパニー・デュプリカント・サーバーＴＣＤＰを介してラピュタ・コマース・サーバーＬＣＳに接続するようにしたのは、上述したエレクトロニック・ウオレット・デュプリカント・サーバーＥＷＤＳと同様の理由によるものであり、ＣＧＩやＳＳＩを用いたシステムの場合、リクエスト及び回答で二重にトランザクションが発生する為トラフイックが倍の密度になってしまうこと、及びデーモンプログラムによる処理は頻繁なアクセスが発生する為、トラフイックに多大な負荷を与えてしまい、トラフイックが過密になり、通信時間のかかりすぎやデータの紛失等の問題が発生してしまうため、トランスポート・カンパニー・デュプリカント・サーバーＴＣＤＰを設置してイーサネットによって対応し、通信時間のかかりすぎやデータの紛失等の問題を解決しているのである。
【００１９】
ラピュタ・コマース・サーバーＬＣＳは、サイバー・ショップ・サーバーＣＳＳとインターネットを介して接続するサイバー・ショップ・デュプリカント・サーバーＳＳＤＳと、エレクトロニック・ウオレット・サーバーＥＷＳとインターネットを介して接続するエレクトロニック・ウオレット・デュプリカント・サーバーＥＷＤＳと、トランスポート・カンパニー・サーバーＴＣＳとインターネットを介して接続するトランスポート・カンパニー・デュプリカント・サーバーＴＣＤＳとを備え、且つこれらのそれぞれはイーサネットを介してラピュタ・コマース・サーバーＬＣＳに接続されている。又、ラピュタ・コマース・サーバーＬＣＳは、複数のユーザーＵＲとインターネットを介して接続されている。
【００２０】
このような接続状態で構成した電子決済システムは、ラピュタ・コマース・サーバーＬＣＳに接続されたそれぞれのユーザーＵＲとエレクトロニック・ウオレット・サーバーＥＷＳとサイバー・ショップ・サーバーＣＳＳとトランスポート・カンパニー・サーバーＴＣＳとの相互間の通報、証明、保証をラピュタ・コマース・サーバーＬＣＳを介して行い、且つ各構成要素に跨ぐ商品のキャンセル処理及びクーリングオフ期間に基づく処理を電子仮想空間上において普遍的にルール化して整備することができ、これは時空を超えた電子仮想空間における商取引の安全性を確保した、いわゆるインターネットに代表される電子仮想空間上の電子商取引に関する受発注管理・物流管理・預託決済管理に基づいて商品とその決済代金の存在を保証するシステムを実現できるのである。
【００２１】
そして、上記構成にした電子決済システムにおいては、納期の通知による商品存在の証明と預託による決済金額の存在を保証することによる預託システムによる契約の成立と、消費者の保護及び最終的な商品の存在を証明するクーリングオフシステムの導入と、パスワードの盗難に対するセキュリテイとして預託通報システムの導入と、消費者保護と商品返品に対するセキュリテイを確保するクーリングオフ警報システムの導入と、サイバー・ショップ・サーバー側の商品を販売する販売者を保護する検品処理システムの導入と、システム全体のセキュリテイを図るために通知と云う概念を導入した通知システムが構築されている。
【００２２】
即ち、エレクトロニック・ウオレット・サーバーＥＷＳとサイバー・ショップ・サーバーＣＳＳとトランスポート・カンパニー・サーバーＴＣＳとラピュタ・コマース・サーバーＬＣＳ間のデータの送受信は、ＣＧＩ又はＳＳＩ若しくはこれらと同等の機能を有するシステムによって所定の相手サーバーにリクエストすることにより、相互に相手のデータベースＤＢを検索し、読み込むことによって行い、直接に相手のデータベースＤＢへの書き込みを行わないことによって、データの改ざんを行えないようにした構成となっている。
【００２３】
そして、ユーザーＵＲからラピュタ・コマース・サーバーＬＣＳ間のデータの送受信は、ＣＧＩ（ＣｏｍｍｏＧａｔｅｗａｙＩｎｔｅｒｆａｃ）又はＳＳＩ（ＳｅｒｖｅｒＳｉｄｅＩｎｃｌｕｄｅ）若しくはそれと同等又はそれ以上の機能を有するシステムによって、ユーザーＵＲからのリクエストのみとし、ユーザーＵＲからラピュタ・コマース・サーバーＬＣＳへの直接の書き込みをなくすことによって、データの改ざんを行えないようにした構成となっている。
【００２４】
また、ユーザーＵＲ又はサイバー・ショップ・サーバーＣＳＳ又はトランスポート・カンパニー・サーバーＴＣＳ又はエレクトロニック・ウオレット・サーバーＥＷＳの情報は、ラピュタ・コマース・サーバーＬＣＳがタイマー動作プログラム又は常時動作プログラムによって自動的にユーザーＵＲとサイバー・ショップ・サーバーＣＳＳとトランスポート・カンパニー・サーバーＴＣＳとエレクトロニック・ウオレット・サーバーＥＷＳとのそれぞれにリクエストを発行し、このユーザーＵＲとサイバー・ショップ・サーバーＣＳＳとトランスポート・カンパニー・サーバーＴＣＳとエレクトロニック・ウオレット・サーバーＥＷＳとのそれぞれがＣＧＩ又はＳＳＩを生成してラピュタ・コマース・サーバーＬＣＳに回答するようにして情報の授受を行うような構成となっている。
【００２５】
図２は、預託と契約の成立、即ち、納期の通知による商品存在の証明と預託による決済金額の存在保証による契約の成立を示した、いわゆる預託システムを示したブロックフロー図である。
【００２６】
先ず、ユーザーＵＲがラピュタホームページの注文書の書式を利用してラピュタ・コマース・サーバーＬＣＳのデータベースＤＢに、納品先、登録納期、品番、品名、数量、単価、金額等からなる注文内容を登録する（ＳＴ１００）。
【００２７】
サイバー・ショップ・サーバーＣＳＳに常駐し任意に定められた時間毎に検索を行いにいく機能を有するクーロン（ＣＲＯＮ）プログラムが、ラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索し、フラグの立っていない注文書若しくは「残高不足解消フラグ」、「再送請求フラグ」の立っている注文書を抽出する（ＳＴ１０１）。
【００２８】
サイバー・ショップ・サーバーＣＳＳのＣＡＬＳ（ＣｏｎｔｉｎｕｅＡｃｑｕｉｓｉｔｉｏｎａｎｄＬｉｆｅーｃｙｃｌｅＳｕｐｐｏｒｔ）がデータベースＤＢを検索して注文書の商品のそれぞれの納期を算定する（ＳＴ１０２）。
【００２９】
サイバー・ショップ・サーバーＣＳＳが納期データをサイバー・ショップ・サーバーＣＳＳのＣＡＬＳから受け取りデータベースＤＢに登録する（ＳＴ１０３）。
【００３０】
ラピュタ・コマース・サーバーＬＣＳにおいて、常時アンダーグランドで動作しており、イベントが発生した時に即座に対応する機能を有するデーモン（ＤＡＥＭＯＮ）プログラムがサイバー・ショップ・サーバーＣＳＳの納期データを検索してデータベースＤＢに登録する（ＳＴ１０４）。
【００３１】
ユーザＵＲは、端末上で任意に定められた時間毎に動作するＨＴＭＬ（ハイパーテキストマークアップランゲージ）のプログラムであるメタタグプログラムにより、ラピュタホームページにおいて、ラピュタ・コマース・サーバーＬＣＳのデータベースＤＢの納期データを検索して読み込む（ＳＴ１０５）。
【００３２】
納期通知が存在していれば、納期通知インジケータが点滅し、納期通知画面が表示される（ＳＴ１０６）。入荷の見込みがなくまた在庫がない場合には、在庫無しのインジケータが点滅し、通知画面に表示される（ＳＴ１０７）。
【００３３】
納期が了承されると、納期了承ボタンをクリックし（ＳＴ１０８）、ラピュタ・コマース・サーバーＬＣＳのＨＴＴＰに納期了承をリクエストし（ＳＴ１０９）、ＣＧＩプログラム、即ち、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）のプログラムであって、外部からのリクエストを受けて動作し、且つリクエストの結果をリクエストの発信者に返答する機能を有する、このＣＧＩプログラムがラピュタ・コマース・サーバーＬＣＳのデータベースＤＢに契約成立のフラグを立てる（ＳＴ１１０）。
【００３４】
納期がキャンセルの場合は、キャンセルボタンをクリックする（ＳＴ１１１）。そうすると、ラピュタ・コマース・サーバーＬＣＳのＨＴＴＰにキャンセル処理をリクエストし、ラピュタ・コマース・サーバーＬＣＳのデータベースＤＢの注文書用の仮ファイルを削除し、データベースＤＢにキャンセルを登録する（ＳＴ１１２、ＳＴ１１３）。
【００３５】
このようにして商品の納期及び商品の存在の証明は、ユーザーＵＲが、ラピュタ・コマース・サーバーＬＣＳを介して行うサイバー・ショップ・サーバーＣＳＳに対する商品の発注は、サイバー・ショップ・サーバーＣＳＳ内においてラピュタ・コマース・サーバーＬＣＳがユーザーＵＲからの商品発注を受けたことを検知するようにし、この商品発注を検知した時にサイバー・ショップ・サーバーＣＳＳのデータベースＤＢ又はサイバー・ショップ・サーバーＣＳＳ内のクライアントに対してユーザーＵＲが発注した商品の在庫検索を実施して、当該商品の単純納期を算出することができる。
【００３６】
そして、この単純納期は、ユーザーＵＲの指定する配達地による配送必要日数と合わせることにより、ユーザーＵＲの指定する配達地までの最終納期を算定し、ラピュタ・コマース・サーバーＬＣＳを通じて商品の最終納期をユーザーＵＲに送り返すことによって商品の存在を証明することができるのである。
【００３７】
一方、ステップＳＴ１００において、注文書の注文内容が登録されると、エレクトロニック・ウオレット・サーバーＥＷＳがデーモンプログラムによりラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索し、何もフラグが立てられていない注文書若しくは「残高不足フラグ」「再送請求フラグ」の立てられた注文書を抽出する。そして登録済みのユーザーＵＲのエレクトロニック・ウオレット・サーバーＥＷＳでの残高と購入金額とを比較して「購入可否」をデータベースＤＢに登録する（ＳＴ１１４）。
【００３８】
ラピュタ・コマース・サーバーＬＣＳのデーモンプログラムがエレクトロニック・ウオレット・サーバーＥＷＳのデータベースＤＢを検索し、「購入可否」についての新規データを抽出し、データベースＤＢに「購入可否」のフラグを立てる（ＳＴ１１５）。
【００３９】
購入可であれば購入可能フラグを立て、購入否であれば購入不可フラグを立て、Ｅーｍａｉｌで通知する（ＳＴ１１６、ＳＴ１１７）。
【００４０】
又、ラピュタホームページのメタタグプログラムが残高不足フラグを検索し、あれば入金、キャンセルの入力の書式を表示し、ラピュタホームページのメタタグプログラムが「残高不足フラグ」を検索し、あれば残高不足のインジケータを点滅させる（ＳＴ１１８、ＳＴ１１９）。
【００４１】
もし入金処理がされると再度ステップＳＴ１０１及びＳＴ１１４から実行され、キャンセル処理の場合はキャンセルが選択される（ＳＴ１２０）。
【００４２】
ラピュタ・コマース・サーバーＬＣＳのデーモンプログラムが注文書用仮ファイルを削除し、データベースＤＢにキャンセルフラグを立て、エレクトロニック・ウオレット・サーバーＥＷＳのデーモンプログラムがラピュタ・コマース・サーバーＬＣＳを検索してキャンセルフラグを見つけると、この注文コードに基づくデータをデータベースＤＢから削除する（ＳＴ１２１、ＳＴ１２２）。
【００４３】
このようにして商品の存在を証明することと並行して、エレクトロニック・ウオレット・サーバーＥＷＳは、ユーザーＵＲの商品発注を検知し、この発注した商品の決済金額に対するエレクトロニック・ウオレット・サーバーＥＷＳ内のユーザーＵＲの預金残高の大小を検索し、この検索結果をラピュタ・コマース・サーバーＬＣＳを介してユーザーＵＲ及びサイバー・ショップ・サーバーＣＳＳに通知することによって決済金額の存在を保証することができる。
【００４４】
又、この商品の存在がサイバー・ショップ・サーバーＣＳＳによって証明され、且つ預金残高が決済預金残高より大きいか又は同等であることがエレクトロニック・ウオレット・サーバーＥＷＳによって証明され、ユーザーＵＲが最終納期を了承することをラピュタ・コマース・サーバーＬＣＳに通知した場合には、エレクトロニック・ウオレット・サーバーＥＷＳは、預金残高から決済金額相当分を預託することによって決済金額の存在を保証するようにすることができ、この保証により商品発注は成立したものとみなすことができるのである。
【００４５】
また、ユーザーＵＲから発注した商品がない場合、又はユーザーＵＲが最終納期を不満とした場合において、ラピュタ・コマース・サーバーＬＣＳを介して行われるエレクトロニック・ウオレット・サーバーＥＷＳからの預金残高通知に対してユーザーＵＲが商品発注をキャンセルした場合は、商品発注は成立しないものとすることができる。
【００４６】
預金残高が決済金額より少ない場合で且つユーザーＵＲがラピュタ・コマース・サーバーＬＣＳを介してエレクトロニック・ウオレット・サーバーＥＷＳから残高不足の通知を受けた場合において、ユーザーＵＲが入金処理を行うまでの間は、商品発注を一時保留の状態にする。
【００４７】
このようにして決済金額の存在が証明されたことを示す購入可能フラグが立ち、且つ商品の存在が証明されたことを示す契約成立のフラグが立つとラピュタ・コマース・サーバーＬＣＳのデーモンプログラムがデータベースＤＢに「預託フラグ」を立て、預託通報システムに行く（ＳＴ１１４、ＳＴ１１５）。
【００４８】
図３は、ユーザーのパスワードの盗難等に対するセキュリテイを図るための預託通報システムを示したブロックフロー図である。
【００４９】
預託通報システムは、商品を購入しようとする者と真実のユーザーとの一致を図るためのシステムであり、商品を購入すると、購入をしたパスワードを有するユーザーにフィードバックをかけてセキュリテイを図るように構成されている。
【００５０】
図３はそのブロックフロー図であり、先ず図２を参照にして説明した預託システムにおいてラピュタ・コマース・サーバーＬＣＳのデーモンプログラムがデータベースＤＢに預託フラグが立っていることが前提となる（ＳＴ１１６）。
【００５１】
ユーザーＵＲのラピュタホームページのメタタグプログラムがラピュタ・コマース・サーバーＬＣＳのＨＴＴＰに対して、ユーザーディレクトリーの仮ファイルの中の預託フラグの有無をリクエストする（ＳＴ１１７）。
【００５２】
預託フラグが立っている場合は、ユーザーＵＲの預託インジケータが点滅し、預託フラグがない場合には、何もしない（ＳＴ１１８、ＳＴ１１９）。
【００５３】
ここでユーザーＵＲは了解かキャンセルを入力することができる。
【００５４】
ユーザーＵＲがキャンセルを入力すると、、預託フラグが削除され、ユーザーディレクトリーの仮ファイルを削除するようにラピュタ・コマース・サーバーＬＣＳにリクエストをする（ＳＴ１２０、ＳＴ１２１）。
【００５５】
ラピュタ・コマース・サーバーＬＣＳはこのリクエストを受けると、データベースＤＢの預託フラグを削除し、且つユーザーディレクトリーの仮ファイルも削除する（ＳＴ１２２）。
【００５６】
預託フラグが削除されると預託オンジケータの点滅は終了する（ＳＴ１２３）。
【００５７】
一方ユーザが了解の入力を行うと、ラピュタ・コマース・サーバーＬＣＳに預託承認フラグのリクエストを行う（ＳＴ１２４、ＳＴ１２５）。
【００５８】
ラピュタ・コマース・サーバーＬＣＳのＨＴＴＰが預託承認ＣＧＩを作成し、ユーザーディレクトリーの仮ファイル及びデータベースＤＢに預託承認を登録する（ＳＴ１２６）。
【００５９】
エレクトロニック・ウオレット・サーバーＥＷＳは、ラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索し、預託承認フラグがあれば、自分のデータベースＤＢに預託フラグを立てる（ＳＴ１２７）。
【００６０】
バンクサーバーは、エレクトロニック・ウオレット・サーバーＥＷＳのデータベースＤＢを検索し、預託承認フラグがあれば、預託処理を実行する（ＳＴ１２８）。
【００６１】
このようにして、ユーザーＵＲが商品の納期を承認し、且つエレクトロニック・ウオレット・サーバーＥＷＳによる決済金額の存在が証明された時に、ラピュタ・コマース・サーバーＬＣＳにおいて預託フラグを立て、ユーザーＵＲがこの預託フラグが立っていることを検出すると、預託フラグが立っていることをユーザーＵＲがビジュアルで確認できるようにして、真実のユーザーが商品を購入したかどうかを視認により判別できる。
【００６２】
又、了解又はキャンセルの入力で対応できるようにして、ユーザーＵＲが、了解を入力すると、エレクトロニック・ウオレット・サーバーＥＷＳはこの了解した預託フラグを検出して預託金額と前記商品の決済金額との決済処理を行うようにして、金銭面でのセキュリテイを図ることができるのである。
【００６３】
また、ユーザーＵＲが、キャンセルを入力すると、これは真実のユーザーＵＲの商品の購入ではないと判断して、ラピュタ・コマース・サーバーＬＣＳは、このキャンセルした預託フラグを検出して当該商取引のデータフィールドの削除を行う。
【００６４】
図４〜図６は消費者を保護するためのキャンセルシステムを示したものである。
【００６５】
消費者を保護するためのキャンセルシステム、即ち、ユーザーが行った商品発注に対するキャンセル処理は、ラピュタ・コマース・サーバーＬＣＳが記録媒体、例えばデータベース上に商取引についてのデータフィールドをまだ作成していない商品発注時点から納期承認前までと、ラピュタ・コマース・サーバーが記録媒体上に商取引についてのデータフィールドを作成した納期承認時点から配達証明発行前までの２つの段階の時期においてのみ有効となっている。
【００６６】
データフィールドを作成していない場合とは、ラピュタ・コマース・サーバーＬＣＳがデータフィールドの作成を実行しないで終了したことを意味し、データフィールドを作成している場合とは、ラピュタ・コマース・サーバーＬＣＳは、このデータフィールドの削除を行う。
【００６７】
図４は、ユーザーＵＲが商品を納期了承してから配達までのキャンセル処理を示したブロックフロー図である。
【００６８】
先ず、ユーザーＵＲがキャンセル書式を用いてキャンセルを入力・送信すると、ラピュタ・コマース・サーバーＬＣＳのＣＧＩが仮ファイル及びデータベースＤＢにキャンセルフラグを立てる（ＳＴ１３０、ＳＴ１３１）。
【００６９】
エレクトロニック・ウオレット・サーバーＥＷＳのデーモンプログラがラピュタ・コマース・サーバーＬＣＳのユーザーディレクトリーを検索して、キャンセルフラグがあれば自分のデータベースＤＢにキャンセルフラグを立てる（ＳＴ１３２）。
【００７０】
トランスポート・カンパニー・サーバーＴＣＳのデーモンプログラムがラピュタ・コマース・サーバーＬＣＳのユーザーディレクトリーを検索してキャンセルフラグがあれば、自分のデータベースＤＢにキャンセルフラグを立てる（ＳＴ１３３）。
【００７１】
サイバー・ショップ・サーバーＣＳＳのデーモンプログラムが、ラピュタ・コマース・サーバーＬＣＳのユーザーディレクトリーを検索して、キャンセルフラグがあれば、自分のデータベースＤＢにキャンセルフラグを立てる（ＳＴ１３４）。
【００７２】
このようにしてそれぞれのサーバーＥＷＳ、ＴＣＳ、ＣＳＳにおいてキャンセルフラグの処理がなされ、ラピュタ・コマース・サーバーＬＣＳのデーモンプログラムが各サーバーのデータベースを検索してキャンセルフラグがあれば、ユーザーディレクトリーの仮ファイルを削除し、データベースＤＢにキャンセルを登録する（ＳＴ１３５）。
【００７３】
従って、サイバー・ショップ・サーバーＣＳＳは、ユーザーＵＲの商品発注に対するキャンセル処理を、ラピュタ・コマース・サーバーＬＣＳにおけるデータフィールドの喪失と自己のデータベースにおけるデータフィールドの存在とで検知するようにし、この検知した後においては更に出荷前と出荷後の２段階に分けてキャンセル処理を行うようにして消費者を保護するようにしてある。
【００７４】
図５は、キャンセル処理によるサイバー・ショップ・サーバーＣＳＳの対応を示したブロックフロー図である。
【００７５】
サイバー・ショップ・サーバーＣＳＳのデーモンプログラムが、ラピュタ・コマース・サーバーＬＣＳのユーザーディレクトリーを検索して、キャンセルフラグがあれば、自分のデータベースＤＢにキャンセルフラグを立てる（ＳＴ１３６）。
【００７６】
出荷前であれば、自分のデータベースに出庫データがなければ、データベースＤＢの当該データを削除する（ＳＴ１３７）。
【００７７】
そしてサイバー・ショップ・サーバーＣＳＳのＣＡＬＳの在庫データベースにキャンセル在庫として登録する（ＳＴ１３８）。
【００７８】
出荷後であれば、自分のデータベースＤＢに、当該データについての出庫データがあれば、ラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索し、当該データについての返品配送完了フラグがあれば、自己のデータベースＤＢの当該データ全てを削除する（ＳＴ１３９）。
【００７９】
キャンセルフラグがあれば、自分のデータベースの当該取引に関するファイルを削除し、なければなにもしない（ＳＴ１４０、ＳＴ１４１）。
【００８０】
さらに、トランスポート・カンパニー・サーバーＴＣＳにおいては、このキャンセル処理のデータを取得した後において、出荷前と出荷後と配送中の３段階に分けてキャンセル処理を行うようにして、消費者の保護を図った構成となっている。
【００８１】
図６は、キャンセル処理におけるトランスポート・カンパニー・サーバーＴＣＳの対応を示したブロックフロー図である。
【００８２】
トランスポート・カンパニー・サーバーＴＣＳのデーモンプログラムがラピュタ・コマース・サーバーＬＣＳのユーザーディレクトリーを検索して、キャンセルフラグがあれば自分のデータベースＤＢにキャンセルフラグを立てる（ＳＴ１４２）。
【００８３】
集荷前であれば、データベースＤＢに集荷済フラグがなければ、デーモンプログラムが６時間後に自分のデータベースＤＢの当該集荷データを削除する（ＳＴ１４３）。
【００８４】
集荷後であれば、データベースＤＢに集荷フラグが有り、且つ出荷フラグがなければ、返品配送フラグを立てる（ＳＴ１４４）。
【００８５】
そして、返品配達済みを入力し、データベースＤＢに返品配送済フラグを立てる（ＳＴ１４５）。
【００８６】
ラピュタ・コマース・サーバーＬＣＳのデーモンプログラムがトランスポート・カンパニー・サーバーＴＣＳのデータベースＤＢを検索し、返品配達済フラグが有れば、データベースＤＢに返品配達済フラグを立てる（ＳＴ１４６）。
【００８７】
エレクトロニック・ウオレット・サーバーＥＷＳのデーモンプログラムがラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索して、返品配達済フラグがあれば、預託解除フラグを立てる（ＳＴ１４７）。
【００８８】
ラピュタ・コマース・サーバーＬＣＳのデーモンプログラムがエレクトロニック・ウオレット・サーバーＥＷＳのデータベースＤＢを検索して預託解除フラグがあれば、当該データの仮ファイルを削除し、データベースＤＢにキャンセルを登録する（ＳＴ１４８）。
【００８９】
又、バンクサーバーのデーモンプログラムがエレクトロニック・ウオレット・サーバーＥＷＳのデータベースＤＢを検索して預託解除フラグがあれば、当該データの預託を解除する（ＳＴ１４９）。
【００９０】
そして、エレクトロニック・ウオレット・サーバーＥＷＳがバンクサーバーのデータベースＤＢを検索して、預託解除フラグデータの預託が解除されていれば、自己のデータベースＤＢの当該データを削除する（ＳＴ１５０）。
【００９１】
図７〜図１３はクーリングオフシステムを示したブロックフロー図である。
【００９２】
クーリングオフシステムは、法で定められた最低のクーリングオフ期間を持つ通販問題対策に設けられた消費者保護と最終的な商品の存在を証明するためのシステム、即ち、通販等により消費者が商品を直接確認することなく購入した場合、その商品が消費者のイメージと異っていたり、破損・汚損があった場合にはクーリングオフ期間内であれば無条件に返品できるシステムであり、本発明においてはこの返品することを拡張して独自の期間設定を行なうと同時に最終的な商品の存在の証明にも援用している。
【００９３】
即ち、クーリングオフシステムはトランスポート・カンパニー・サーバーＴＣＳによるユーザーＵＲへの商品の配達証明発行後から、各商品固有の性能・性質に基づいて設定されているガイドラインに従って、サイバー・ショップ・サーバーを提供・維持・管理する企業又は個人が各商品固有の性能・性質に基づいて設定されているクーリングオフ期間の終了まで機能するようにしたことである。
【００９４】
このクーリングオフシステムは、ユーザーＵＲが商品の返品の際に行うクーリングオフ申請によるキャンセル処理手段と、ユーザーＵＲからの再送依頼により商品の再送を行う再送請求処理手段と、クーリングオフ期間外処理手段と、トランスポート・カンパニー・サーバーＴＣＳにおける配達終了に基づくクーリングオフ解除期日算定手段と、トランスポート・カンパニー・サーバーＴＣＳにおける商品の配達終了期間に基づくクーリングオフ警報手段と、ユーザーからのクーリングオフの中止を処理するクーリングオフ中止手段と、クーリングオフ期間に基づいて前記ユーザーの手元に届いた商品の返品処理を行うクーリングオフの検品処理手段とから構成されている。
【００９５】
クーリングオフシステムにおけるクーリングオフ期間の終了が、商品が前記ユーザーの発注商品と同一であることをユーザー本人が確認したものとみなして、最終的な商品の存在の証明が行われたものとするようにしてある。
【００９６】
図７は、ユーザーＵＲが商品の返品の際に行うクーリングオフ申請によるキャンセル処理手段を示したブロックフロー図である。
【００９７】
先ず、ユーザＵＲがラピュタホームページのクーリングオフ書式により、商品を返品したい旨、即ちクーリングオフ申請をラピュタ・コマース・サーバーＬＣＳにリクエストすると、ラピュタ・コマース・サーバーＬＣＳのＣＧＩが注文書仮ファイルをユーザーディレクトリー及びデータベースＤＢに登録する（ＳＴ１５１）。
【００９８】
ラピュタ・コマース・サーバーＬＣＳのデーモンプログラムは、クーリングオフ申請がクーリングオフ期間内か否かのチエックをする（ＳＴ１５２）。
【００９９】
期間外であればクーリングオフ期間外処理ルーチン（クーリングオフ期間外処理手段）に行き、クーリングオフ期間内であれば、デーモンプログラムがクーリングオフのフラグを仮ファイルとデータベースＤＢに立てる（ＳＴ１５３、ＳＴ１５４）。
【０１００】
クーリングオフのフラグが立つと、さまざまなサーバーが動き出す。先ず、エレクトロニック・ウオレット・サーバーＥＷＳのクーロンプログラムがラピュタ・コマース・サーバーＬＣＳのクーリングオフフラグを抽出し、自分のデータベースＤＢにクーリングオフフラグを立てる（ＳＴ１５５）。
【０１０１】
サイバー・ショップ・サーバーＣＳＳのクーロンンプログラムがラピュタ・コマース・サーバーＬＣＳのクーリングオフフラグを抽出し、自分のデータベースＤＢにクーリングオフフラグを立てる（ＳＴ１５６）。
【０１０２】
トランスポート・カンパニー・サーバーＴＣＳのクーロンプログラムがラピュタ・コマース・サーバーＬＣＳのクーリングオフフラグを抽出し、自分のデータベースＤＢにクーリングオフフラグを立てる（ＳＴ１５７）。
【０１０３】
そして、トランスポート・カンパニー・サーバーＴＣＳの端末のプラウザにクーリングオフフラグが立てられたデータを表示する（ＳＴ１５８）。
【０１０４】
このような作業（ＳＴ１５５〜ＳＴ１５８）を終了後、ラピュタ・コマース・サーバーＬＣＳのクーロンプログラムが「クーリングオフ解除期日」に達した注文ファイルをピックアップし、クーリングオフフラグを削除し、解除する（ＳＴ１５９）。
【０１０５】
また、エレクトロニック・ウオレット・サーバーＥＷＳのクーロンプログラムが新しい「クーリングオフ解除期日データ」を検索し、自分のデータベースＤＢに期日を登録する（ＳＴ１６０）。
【０１０６】
エレクトロニック・ウオレット・サーバーＥＷＳのクーロンプログラムがラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索して、クーリングオフの解除を検知すると、自分のデータベースＤＢ内の「クーリングオフ期日」のデータと照合し、「期日データ」以降の日付ならば「預託解除・決済フラグ」を立てる（ＳＴ１６１）。
【０１０７】
ステップＳＴ１５７において、トランスポート・カンパニー・サーバーＴＣＳがクーリングオフのフラグを立てると、運送会社がデータベースに返品配達の完了を登録し、運送会社の集荷・配送システムにデータを渡す（ＳＴ１６２、ＳＴ１６３）。
【０１０８】
そして、ラピュタ・コマース・サーバーＬＣＳのクーロンプログラムがトランスポート・カンパニー・サーバーＴＣＳのデーターベースＤＢを検索して、「返品配達完了」の登録があれば、データベースＤＢに「返品配達完了」のフラグを立てる（ＳＴ１６４）。
【０１０９】
返品された商品は、サイバー・ショップ・サーバーＣＳＳにて、申請の商品であるか否かの検品処理がなされ、データベースＤＢにフラグを立てる（ＳＴ１６５）。
【０１１０】
ラピュタ・コマース・サーバーＬＣＳのクーロンプログラムがサイバー・ショップ・サーバーＣＳＳのデータベースを検索し、返品された商品の「真」、「偽」のフラグを読み込む（ＳＴ１６６）。
【０１１１】
「偽」の場合は、受理できない旨のメールを発送し、クレーム処理担当者にデータを渡す。「真」の場合は、ステップＳＴ１６４の「返品配達完了」のフラグにより、返品配達が完了し、且つ返品された商品が真であることを確認して、エレクトロニック・ウオレット・サーバーＥＷＳのクーロンプログラムがラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索し、上記フラグを検索して見つけると「預託解除・キャンセル」のフラグを立てる（ＳＴ１６７）。
【０１１２】
そして、ラピュタ・コマース・サーバーＬＣＳのクーロンプログラムがエレクトロニック・ウオレット・サーバーＥＷＳのデータベースＤＢを検索して、「預託解除・キャンセルフラグ」を発見すれば、仮ファイルを削除する（ＳＴ１６８）。
【０１１３】
また、ステップＳＴ１６１での照合、及びステップＳＴ１６７により、バンクサーバーのデーモンプログラムがデータベースＤＢから「預託解除・決済フラグ」若しくは「預託解除・キャンセルフラグ」を見つけると、預託を解除し、送金若しくは送金手続を行う（ＳＴ１６９）。
【０１１４】
また、ユーザーＵＲのメタタグプログラムがラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索して、「返品配達完了」のフラグ、及び「返品された商品が真である」フラグを見つけるとインジケータを点滅させる（ＳＴ１７０）。
【０１１５】
そして、ユーザーＵＲが「了解」を入力すると、クーリングオフ書式を削除若しくは停止して点滅を停止する（ＳＴ１７１、ＳＴ１７２）。
【０１１６】
さらに、ラピュタ・コマース・サーバーＬＣＳのクーロンプログラムがデータベースを検索して「返品配達完了」のフラグ及び「返品された商品が真である」フラグを見つけると、「返品が完了し、クーリングオフ処理が終了した旨」のメッセージをユーザーに送付する（ＳＴ１７３）。
【０１１７】
図８は、ユーザーＵＲからの再送依頼により商品の再送を行う再送請求処理手段を示したブロックフロー図である。
【０１１８】
再送請求をするクーリングオフ処理ユニットは、クーリングオフの一環として、商品の間違いや、破損、汚損等があった場合に、商品を返品し、再度送付を依頼するためのシステムである。
【０１１９】
先ず、ユーザーＵＲがクーリングオフ書式（ＪＡＶＡ）によって商品の再度依頼を行う。この時に入力する内容は、納入日、再送品希望配送日時、品番、数量、金額、請求原因（例示より数字で選択する、その他である（ＳＴ１７５）。
【０１２０】
ラピュタ・コマース・サーバーＬＣＳはデーモンプログラムによってデータベースＤＢを検索し、「該当する商品の有無」と「クーリングオフ期間内外」のチエックを行う（ＳＴ１７６）。
【０１２１】
そして、クーリングオフ期日外であればクーリングオフ期間外処理システムのルーチンにゆく（ＳＴ１７７）。
【０１２２】
期日内であればラピュタ・コマース・サーバーＬＣＳより品名を添えて確認のメッセージをユーザーＵＲに送付し、ユーザーＵＲは了解、又は変更の入力ができる（ＳＴ１７８、ＳＴ１７９）。
【０１２３】
ユーザーＵＲが了解すると、ラピュタ・コマース・サーバーＬＣＳのデーモンプログラムが、これまでの仮ファイルを削除して、新規の仮ファイルを作成してデータベースＤＢに新規の注文書（データフィールド）を作成し、それぞれに「再送請求フラグ」を立て、図２に示した預託システムにゆき商品発送の処理を行う（ＳＴ１８１）。
【０１２４】
一方、返品された商品は、サイバー・ショップ・サーバーＣＳＳにて、申請の商品か否かの検品作業を行い、データベースＤＢにフラグを立てる（ＳＴ１８２）。
【０１２５】
ラピュタ・コマース・サーバーＬＣＳのクーロンプログラムがサイバー・ショップ・サーバーＣＳＳのデータベースＤＢを検索し、「真」、「偽」のフラグを読み込む（ＳＴ１８３）。
【０１２６】
「真」であればラピュタ・コマース・サーバーＬＣＳが注文書の作成及び「再送請求フラグ」を立て、図２で示した預託システムに行き商品発送の処理を行う（ＳＴ１８１）。
【０１２７】
「偽」であれば受理できない旨のメール及びクレーム処理担当者にデータを渡す（ＳＴ１８４）。
【０１２８】
図９は、クーリングオフ期間外処理手段であるクーリングオフ期間外処理システムを示すブロックフロ図である。
【０１２９】
先ず、ラピュタ・コマース・サーバーＬＣＳのデーモンプログラムが「クーリングオフ不可フラグ」を仮ファイルとデータベースＤＢに立てていることが前提となる（ＳＴ１８５）。
【０１３０】
ユーザーＵＲのメタタグがクーリングオフ不可フラグを検出すると、ユーザーＵＲのラピュタホームページのインジケータを点滅させると同時に、クーリングオフ不可の旨のインフオメーションを表示し、了解を求める（ＳＴ１８６）。
【０１３１】
同時に、ラピュタ・コマース・サーバーＬＣＳのデーモンプログラムがユーザーＵＲにメールを発送する（ＳＴ１８７）。
【０１３２】
ここで、ユーザーＵＲがインフオメーションに対する回答を入力する（ＳＴ１８８）。
【０１３３】
同意しない場合は、ユーザーＵＲの残高を表示し、購入額が残高を超えていることを開示して、再度回答を促す（ＳＴ１８９）。
【０１３４】
了解した場合にはラピュタ・コマース・サーバーＬＣＳのデーモンプログラムがクーリングオフフラグ及びクーリングオフ不可フラグを削除して決済処理に行く（ＳＴ１９０、ＳＴ１９１）。
【０１３５】
図１０は、トランスポート・カンパニー・サーバーＴＣＳにおける配達終了に基づくクーリングオフ解除期日算定手段であるクーリングオフの解除期日算定ユニットを示したブロックフロー図である。
【０１３６】
クーリングオフの解除期日算定ユニットにおいては、先ずトランスポート・カンパニー・サーバーンスポーターサーバーＴＣＳにおけるデータベースＤＢに、配送が終了したことを登録する（ＳＴ１９５）。
【０１３７】
ラピュタ・コマース・サーバーＬＣＳのクーロンプログラムがトランスポート・カンパニー・サーバーＴＣＳのデータベースＤＢを検索して、新規の配送終了データがあれば、データベースＤＢに対して「配達終了フラグ」を立てる（ＳＴ１９６）。
【０１３８】
そして、ラピュタ・コマース・サーバーＬＣＳのクーロンプログラムがクーリングオフ解除期日算定をし、データベースＤＢに期日を登録する（ＳＴ１９７）。
【０１３９】
また、ラピュタ・コマース・サーバーＬＣＳのクーロンプログラムはクーリングオフ警報発令期日の算定をし、データベースＤＢに期日を登録する（ＳＴ１９８）。
【０１４０】
図１１は、トランスポート・カンパニー・サーバーＴＣＳにおける商品の配達終了期間に基づくクーリングオフ警報手段であるクーリングオフ警報システムを示したブロックフロー図である。
【０１４１】
クーリングオフ警報システムは、ユーザーＵＲが返品する時に申請するクーリングオフ申請をしてクーリングオフフラグを立て、ラピュタ・コマース・サーバーがこのクーリングオフフラグが立っていることを検出すると警報発令期日とクーリングオフ解除期日を算定する。この警報発令期日に達した注文ファイルをピックアップして警報フラグを立て、ユーザーＵＲがこのクーリングオフフラグが立っていることを検出すると、クーリングオフフラグが立っていることをユーザーＵＲがビジュアルで確認できるようにすると共に、了解、クレーム、クーリングオフの中止の３通りで対応できるようにしてある。
【０１４２】
そして、ユーザーＵＲが対応できるクレームは、ユーザーＵＲが既に返品配送済の段階において発行するものであり、ラピュタ・コマース・サーバーＬＣＳにクレームフラグを立てると同時に、トランスポート・カンパニー・サーバーＴＣＳに別途メールで通知するようにし、且つトランスポート・カンパニー・サーバーＴＣＳがこのクレームを検出するとクレームフラグを立て、トランスポート・カンパニー・サーバーＴＣＳがこのクレームフラグを検出する。するとクレームフラグが立っていることをトランスポート・カンパニー・サーバーＴＣＳがビジュアルで確認できるようになっている。以下、図１１のブロックフロー図で説明する。
【０１４３】
先ず、ラピュタ・コマース・サーバーＬＣＳのクーロンプログラムがユーザーＵＲが立てた新しいクーリングオフフラグを検出すると、「警報発令期日」と「クーリングオフ解除期日」を算定し、その結果をデータベースＤＢに登録する（ＳＴ２００）。
【０１４４】
ラピュタ・コマース・サーバーＬＣＳのクーロンプログラムが「警報発令期日」に達した注文ファイルをピックアップし、データベースＤＢに「警報フラグ」を立てる（ＳＴ２０１）。
【０１４５】
又は、トランスポート・カンパニー・サーバーＴＣＳが「返品の配送済フラグ」を自分のデータベースＤＢに立てていることが前提となる（ＳＴ２０２）。
【０１４６】
ラピュタ・コマース・サーバーＬＣＳのデーモンプログラムがトランスポート・カンパニー・サーバーＴＣのデータベースＤＢの「返品配送済フラグ」を見つけると、ラピュタ・コマース・サーバーＬＣＳのデータベースＤＢに「返品配送済フラグ」を立て、同時に「警報フラグ」を削除する（ＳＴ２０３）。
【０１４７】
ユーザーＵＲのメタタグプログラムがラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索し、そのデータの中に「警報フラグ」を見つけるとインジケータを点滅させる。インジケータをクリックすると了解書式を表示する（ＳＴ２０４）。
【０１４８】
ここで、ユーザーＵＲは、「了解」、「クーリングオフの中止」、「クレーム処理」の３通りのいずれかを入力することができる（ＳＴ２０５）。
【０１４９】
ユーザーＵＲが「了解」を入力すると、ユーザーＵＲに供給されている書式の中のブリンクコマンドの削除若しくは停止により点滅は停止する（ＳＴ２０６）。
【０１５０】
「クーリングオフの中止」を入力すると、クーリングオフ中止書式を選択し、クーリングオフ中止システムのルーチンに行く（ＳＴ２０７）。
【０１５１】
「クレーム処理」を入力すると、ユーザーＵＲがクレーム書式を選択し、配送番号と配送日時を入力する（ＳＴ２０８）。
【０１５２】
そうすると、ラピュタ・コマース・サーバーＬＣＳの仮ファイル及びデータベースＤＢにクレームフラグを立てると同時に、運送会社にメールにて通知する（ＳＴ２０９）。
【０１５３】
トランスポート・カンパニー・サーバーＴＣのデーモンプログラムがラピュタ・コマース・サーバーＬＣＳの仮ファイルのクレームフラグを見つけるとトランスポート・カンパニー・サーバーＴＣＳの端末に警報をブリンクさせる（ＳＴ２１０）。
【０１５４】
同時に、トランスポート・カンパニー・サーバーＴＣＳにメールを送付し、トランスポート・カンパニー・サーバーＴＣはクレーム処理担当に処理を移行する（ＳＴ２１１、ＳＴ２１２）。
【０１５５】
図１２は、ユーザーＵＲからのクーリングオフの中止を処理するクーリングオフ中止手段であるクーリングオフ中止システムを示したブロックフロー図である。
【０１５６】
クーリングオフ中止は、ユーザーＵＲがクーリングオフを申請したにも関わらず未だに返品発送を行っていない段階において発行されるものであり、ユーザーＵＲがクーリングオフを中止して当該商品が発注商品と同一であることを認定した場合に発行され、ユーザーＵＲがラピュタ・コマース・サーバーＬＣＳにクーリングオフ中止フラグを立てるようにリクエストを発行することによって、トランスポート・カンパニー・サーバーＴＣＳがこのクーリングオフ中止フラグを検出すると商品の配送プランを組み替えるようにする。
【０１５７】
又、エレクトロニック・ウオレット・サーバーＥＷＳ及びサイバー・ショップ・サーバーＣＳＳは、クーリングオフ中止フラグを検出すると、クーリングオフフラグを削除する。以下、図１２のブロックフロー図で説明する。
【０１５８】
ユーザーＵＲが「クーリングオフ中止」書式によりラピュタ・コマース・サーバーＬＣＳにクーリングオフ中止をリクエストする（ＳＴ２１５）
【０１５９】
すると、ラピュタ・コマース・サーバーＬＣＳのＣＧＩがデータベースＤＢ及び仮ファイルに「クーリングオフ中止フラグ」を立てる（ＳＴ２１６）。
【０１６０】
トランスポート・カンパニー・サーバーＴＣのデーモンプログラムがラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索し、「クーリングオフ中止フラグ」を見つけると、自分のデータベースＤＢの「クーリングオフフラグ」を削除し、「クーリングオフ中止フラグ」を立てる（ＳＴ２１７）。
【０１６１】
同時に、エレクトロニック・ウオレット・サーバーＥＷＳのデーモンプログラムがラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索し、「クーリングオフ中止フラグ」を見つけると自分のデータベースＤＢの「クーリングオフフラグ」を削除する（ＳＴ２１８）。
【０１６２】
同時に、サイバー・ショップ・サーバーＣＳＳのデーモンプログラムがラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索し、「クーリングオフ中止フラグ」を見つけると自分のデータベースＤＢの「クーリングオフフラグ」を削除する（ＳＴ２１９）。
【０１６３】
ラピュタ・コマース・サーバーＬＣＳのデーモンプログラムが各サーバーのデータベースＤＢを検索し、自分のデータベースＤＢの「クーリングオフ中止フラグ」を立てられたデータに相当するデータについてクーリングオフフラグが削除されているかどうかをチエックし、全て削除されていればラピュタ・コマース・サーバーＬＣＳのデーモンプログラムは仮ファイルから「クーリングオフ中止フラグ」を削除する（ＳＴ２２０）。
【０１６４】
一方、トランスポート・カンパニー・サーバーＴＣＳは、デーモンプログラムがデータベースＤＢの「クーリングオフ中止フラグ」を検出すると、配送プランを組み替える（ＳＴ２２１）。
【０１６５】
集荷当日の場合は、デーモンプログラムが配送車に電話若しくはメールで通報する。トランスポート・カンパニー・サーバーＴＣＳのデーモンプログラムは「クーリングオフ中止フラグ」を削除する（ＳＴ２２２、ＳＴ２２３）。
【０１６６】
図１３は、クーリングオフ期間に基づいてユーザーＵＲの手元に届いた商品の返品処理を行うクーリングオフの検品処理手段であるクーリングオフの検品処理ユニットを示したブロックフロー図である。
【０１６７】
クーリングオフの検品処理手段は、発注した商品がユーザーＵＲの手元に届いてから返品理由フラグを立てるようにしてある。この返品理由フラグは、商品間違い、破損・汚損、商品が予想と違っていた、その他の４種類からなり、それぞれのフラグはサイバー・ショップ・サーバーＣＳＳ内からの商品を、クーリングオフ申請に基づいて返品用商品の検品をするようになっている。
【０１６８】
又、このクーリングオフの検品処理手段は、返品用商品がクーリングオフ申請した期間内であって、破損・汚損の場合は運送中の破損・汚損又は配送する際の検品漏れ又は故意によるものかの判別をし、この運送中の破損・汚損又は配送する際の検品漏れの場合は再送するようになっている。
【０１６９】
そして、クーリングオフの検品処理手段は、返品用商品がクーリングオフ期間内であって、商品が予想と違っていた又はその他の理由の場合は、この商品の破損・汚損の有無を識別し、破損・汚損の場合は運送中の破損・汚損又は配送する際の検品漏れ又は故意によるものかの判別をし、この運送中の破損・汚損又は配送する際の検品漏れの場合は再送するようにしてある。以下、図１３のブロックフロー図で説明する。
【０１７０】
先ず、サイバー・ショップ・サーバーＣＳＳがラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索して、クーリングオフ申請物件から「返品理由（フラグ）」を読み込む（ＳＴ２２５）。
このフラグは、「商品間違い」、「破損、汚損」、「商品が予想と違っていた」、「その他」の４種類からなる。
【０１７１】
検品する商品が、自社取扱い商品かどうかを検査し、フラグを立て、自社商品の場合は品番を入力する（ＳＴ２２６）。
【０１７２】
非自社商品と認定した場合は、受理できない旨のメールを送付し、クレーム処理担当者にデータを渡す（ＳＴ２２７）。
【０１７３】
自社商品と認定した場合は、サイバー・ショップ・サーバーＣＳＳのデータベースＤＢを検索して品番商品の納入時期を調査し、クーリングオフ期間と比較してクーリングオフ該当商品かどうかをチエックする（ＳＴ２２８）。
【０１７４】
クーリングオフ期間内であって、返品原因が、「商品が予想と違っていた」、「その他の理由による場合」の検品は、破損・汚損の有無を検品し、入力書式により結果を入力する（ＳＴ２２８）。
【０１７５】
破損・汚損が有れば、サイバー・ショップ・サーバーＣＳＳのデータベースＤＢに「破損・汚損フラグ」を追加する（ＳＴ２２９）。
【０１７６】
破損・汚損が無ければサイバー・ショップ・サーバーＣＳＳのデータベースＤＢに返品された商品が「真」であるフラグを立てる（ＳＴ２３０）。
【０１７７】
又、クーリングオフ期間内において、返品原因が「破損・汚損」による場合は、その検品は、破損・汚損の原因を検査し、認定結果を入力書式で入力する（ＳＴ２３１）。
【０１７８】
故意によるものと認定された場合は、対策指示を表示し、受理できない旨のメールを発送し、クレーム担当者にデータを渡す（ＳＴ２３２、ＳＴ２３３）。
【０１７９】
運送中の事故と認定された場合は、運送会社と調整し、不調に終わればクレーム担当者にデータを渡す（ＳＴ２３４、ＳＴ２３５、ＳＴ２３６）。
【０１８０】
保険で対応できることに合意した場合には、入力書式から「真」のフラグをリクエストし、サイバー・ショップ・サーバーＣＳＳのデータベースＤＢに返品された商品が「真」であるフラグを立てる（ＳＴ２３７、ＳＴ２３８）。
【０１８１】
又、不明若しくは検品漏れと認定した場合も、サイバー・ショップ・サーバーＣＳＳのデータベースＤＢに返品された商品が「真」であるフラグを立てる（ＳＴ２３８）。
【０１８２】
ステップＳＴ２２８において、納入実績がない場合には、「納入実績無しフラグ」を立て、受理できない旨のメールを発送と、クレーム担当者にデータを渡す（ＳＴ２３９、ＳＴ２４０）。
【０１８３】
ステップ２２８において、クーリングオフ期間外であれば、メールにてユーザーＵＲに商品を間違えて送付していないかを確認する（ＳＴ２４１）。
【０１８４】
間違えていない場合は、クーリングオフ期間外のフラグを立て、クーリングオフ期間外処理システムに行く（ＳＴ２４２、ＳＴ２４３）。
【０１８５】
ステップ２４１において、商品を間違えて送付した場合は、ユーザーＵＲがクーリングオフフラグ削除をリクエストするか又はサイバー・ショップ・サーバーＣＳＳがクーリングオフフラグ削除をリクエストするかする。そして、ラピュタ・コマース・サーバーＬＣＳのデーモンプログラムが両者を検知すると、クーリングオフフラグを削除し、新規の仮ファイルを作成する。又、データベースＤＢに新規の注文書を作成し、それぞれに再発行フラグを立て、クーリングオフ申請処理に行く（ＳＴ２４４、ＳＴ２４５、ＳＴ２４６、ＳＴ２４７）。
【０１８６】
図１４は、商品の存在を証明した後の決済方法を示したブロックフロー図である。
【０１８７】
商品に対する代金の決済においては、エレクトロニック・ウオレット・サーバーＥＷＳに預託されている金銭を、商品を販売したサイバー・ショップ・サーバーＣＳＳの実際に商品を提供している者の口座に振り込む際に、エレクトロニック・ウオレット・サーバーＥＷＳはラピュタ・コマース・サーバーＬＣＳを介してトランスポート・カンパニー・サーバーＴＣＳからこの商品の配達証明を受け取ることによって、この商品がユーザーＵＲの手元にあることを確認する。且つラピュタ・コマース・サーバーＬＣＳがプログラムにより自動的に算定するクーリングオフ期間の終了を、ラピュタ・コマース・サーバーＬＣＳが確認することにより、ユーザーＵＲがこの商品をユーザーＵＲが発注した商品と同一物であることをユーザーＵＲが承認したものと認め、預託金額をサイバー・ショップ・サーバーＣＳＳの実際に商品を販売している者の口座に振り込むようにする。
【０１８８】
又、エレクトロニック・ウオレット・サーバーＥＷＳは、ラピュタ・コマース・サーバーＬＣＳに預託を解除して商品との決済をしたことを通知し、このラピュタ・コマース・サーバーＬＣＳは決済したことをデータベースＤＢに書き込むと共に当該商品発注のファイルを削除するようにしてある。以下、図１４のブロックフロー図を参照して説明する。
【０１８９】
先ず、トランスポート・カンパニー・サーバーＴＣＳが、データベースＤＢに配達終了が登録してあることが前提となる（ＳＴ２５０）。
【０１９０】
そうすると、ラピュタ・コマース・サーバーＬＣＳのクーロンプログラムがトランスポート・カンパニー・サーバーＴＣＳのデータベースＤＢを検索して新規の配達終了データがあれば、データベースＤＢに「配達終了フラグ」を立てる（ＳＴ２５１）。
【０１９１】
ラピュタ・コマース・サーバーＬＣＳのクーロンプログラムが「配達終了フラグ」を立てられたデータについて、クーリングオフ解除期日の算定をし、データベースＤＢに期日を登録する（ＳＴ２５２）。
【０１９２】
エレクトロニック・ウオレット・サーバーＥＷＳのクーロンプログラムがラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索して、「クーリングオフ解除期日」に達したデータがあれば、自分のデータベースＤＢに「預託解除・決済フラグ」を立てる（ＳＴ１６６）。
【０１９３】
バンクサーバーが、エレクトロニック・ウオレット・サーバーＥＷＳのデータベースＤＢを検索して「預託・決済フラグ」があれば、預託を解除して、サイバー・ショップ・サーバーＣＳＳに送金する（ＳＴ２５４）。
【０１９４】
又、ステップＳＴ１６４から、キャンセルする場合には図７に示すクーリングオフ処理ユニットに行き、再送請求であれば図８に示すクーリングオフ処理ユニットに行く（ＳＴ２５５、ＳＴ２５６）。
【０１９５】
【発明の効果】
以上説明したように本発明に係る電子決済システムは、端末機器を介して行うユーザーと、預託行為を含む金銭出納管理をする単独又は複数のエレクトロニック・ウオレット・サーバーと、商品を取り揃え且つ単独若しくは複数の商品仕入先との受発注管理を行うサイバー・ショップ・サーバーと、商品を自動的な配送及び集荷の情報を収集し、且つ商品の集荷・配送及び管理を行い、配送が完了したことを証明するトランスポート・カンパニー・サーバーと、ユーザーとエレクトロニック・ウオレット・サーバーとサイバー・ショップ・サーバーとトランスポート・カンパニー・サーバーとのそれぞれと個別に通信回線を介して接続し、接続された全体を組織的に統合すると共に取引履歴をデータベース上に記録・保管し、且つクーリングオフシステムにより予め設定されているクーリングオフ期間に基づいて最終的な商品の存在を証明するラピュタ・コマース・サーバーとから構成して、ラピュタ・コマース・サーバーに接続されたそれぞれのユーザーとエレクトロニック・ウオレット・サーバーとサイバー・ショップ・サーバーとトランスポート・カンパニー・サーバーとの相互間の通報、証明、保証をラピュタ・コマース・サーバーを介して行い、且つ商品のキャンセル処理及びクーリングオフ期間に基づく処理を電子仮想空間上において普遍的にルール化して行うようにしたことにより、時空を超えた電子仮想空間における商取引の安全を確保した、いわゆるインターネットに代表される電子仮想空間上の電子商取引に関する受発注管理、物流管理、預託決済管理に基づいて商品とその決済代金との存在を保証することができると云う効果がある。
【図面の簡単な説明】
【図１】本発明に係る全体構成の接続関係を示した説明図である。
【図２】同預託システムを示したブロックフロー図である。
【図３】同電子商取引システムにおける預託通報システムを示したブロックフロー図である。
【図４】同電子商取引システムにおけるキャンセル処理ユニットの納期了承〜配達までを示したブロックフロー図である。
【図５】同電子商取引システムにおけるキャンセル処理におけるサイバー・ショップ・サーバーＣＳＳの対応システムユニットを示したブロックフロー図である。
【図６】同電子商取引システムにおけるキャンセル処理におけるトランスポート・カンパニー・サーバーＴＣの対応システムユニットを示したブロックフロー図である。
【図７】同電子商取引システムにおけるクーリングオフ処理ユニット（１）のキャンセル処理を示したブロックフロー図である。
【図８】同電子商取引システムにおけるクーリングオフ処理ユニット（２）の再送請求を示したブロックフロー図である。
【図９】同電子商取引システムにおけるクーリングオフ処理ユニット（３）のクーリングオフ期間外処理システムを示したブロックフロー図である。
【図１０】同電子商取引システムにおけるクーリングオフの解除期日算定ユニットを示したブロックフロー図である。
【図１１】同電子商取引システムにおけるクーリングオフ処理ユニット（４）のクーリングオフ警報システムを示したブロックフロー図である。
【図１２】同電子商取引システムにおけるクーリングオフ処理ユニット（５）のクーリングオフ中止システムを示したブロックフロー図である。
【図１３】同電子商取引システムにおけるクーリングオフの検品処理ユニットを示したブロックフロー図である。
【図１４】同電子商取引システムにおける決済処理ユニットを示したブロックフロー図である。
【図１５】従来技術における商取引を示した説明図である。
【符号の説明】
ＵＲ；ユーザー、ＣＳＳ；サイバー・ショップ・サーバー、ＥＷＳ；エレクトロニック・ウオレット・サーバー、ＴＣＳ；トランスポート・カンパニー・サーバー、ＬＣＳ；ラピュタ・コマース・サーバー[0001]
BACKGROUND OF THE INVENTION
The present invention relates to an electronic payment system, and more particularly, to an electronic payment system for constructing electronic commerce that secures security for ordering products remotely, making payments with ordered products, and actually delivering products in a virtual space domain. It is.
[0002]
[Prior art]
As shown in FIG. 15, a settlement system that has been distributed in the past conducts a commercial transaction between a user and an EC (Erctronic Commerce), and the settlement timing is classified into three types.
[0003]
As shown in FIG. 15 (a), the first classification is a case where the settlement time is at the time of delivery. When the user places an order with the EC, the EC performs self-delivery to the user and pays the price at the time of delivery. It is a system to collect.
[0004]
As shown in FIG. 15 (b), the second classification is a method of purchasing goods by making a reservation with the EC from the user side. In this case, for example, payment is made when the user visits the store. .
[0005]
In the third classification, as shown in FIG. 15C, when an order is placed from the user to the EC, the goods are delivered from the EC side and a bill is also issued. This settlement period includes automatic withdrawal within a few months, monthly settlement, settlement when it occurs.
[0006]
In order to purchase commodities in such three types of payment systems, there are money or electronic money distributed in society.
[0007]
Electronic money includes a credit type, a network type, a combination of a network and an IC card, and an IC card type, all of which are used as a substitute for money distributed in society. For example, when purchasing a product with an IC card, the IC card pays the price when the desired product is specified, and the payment system pays the price paid with the IC card by another route at a later date. This method is used.
[0008]
In addition to such an IC card, there is a settlement by an IC card used in a cash society as in the current credit card. In order to make a payment using an IC card called a so-called Mondex type, first, an account is established with an electronic wallet server by making a contract with a financial institution such as a bank. Then, it receives an IC card with a built-in password and encryption key. Electronic money (EM) is transferred from the electronic wallet server deposit account to the IC card via the communication line.
The IC card can be used for the transferred EM, and therefore, a predetermined amount can be used for the IC card.
[0009]
Also, in such commercial transactions using electronic money, it is important to ensure security. For this purpose, (1) ID + password, (2) communication encryption system (for example, using a security card), Safety is achieved by (3) an electronic signature system and (4) the entire business flow forms one security mechanism.
[0010]
[Problems to be solved by the invention]
However, the electronic money used in the commercial transaction described in the above prior art is a payment system in a virtual space by a card company that is an affiliated type with a credit card, and is a transport company that delivers and manages products. -Servers, cyber shop servers, etc. that arrange and manage multiple products, etc. and are not mutually approved and guaranteed systems, so products that are important in commercial transactions in virtual space There is a problem that proof of existence and proof of payment amount cannot be made.
[0011]
Therefore, in electronic commerce in the case of constructing a virtual city, there is a problem that must be solved to a system that can at least prove the existence of goods and the existence of a settlement amount.
[0012]
[Means for Solving the Problems]
In order to solve the above-described problems, an electronic payment system according to the present invention is intended to prove and guarantee that a user who orders and purchases goods through a terminal device and that the user has a purchase payment for the goods. A plurality of electronic wallet servers that perform cash accounting management including deposits performed in the past, and a plurality of products that the user purchases the above-mentioned products and that manages ordering with a single or a plurality of product suppliers One or more cyber shop servers that collect information on automatic delivery and collection of the product selected by the user, collect and deliver and manage the product, and prove that the delivery is complete Transport Company Server, User, Electronic Wallet Server and Cyber Shop Server And the transport company server individually through a communication line, systematically integrating the entire connection and recording / storing transaction history in a database, and using a cooling-off system in advance. It consists of a Laputa Commerce server that proves the existence of the final product based on the set cooling-off period, and each user connected to the Laputa Commerce server, the electronic wallet server and the cyber -Notification, certification, and guarantee between shop server and transport company server via the Laputa Commerce server, and processing based on the product cancellation process and the cooling-off period are electronic virtual Universal rules in space And it is to the be carried out.
[0013]
The electronic payment system configured as described above can electronically collate the user's funds and the product inventory of the manufacturer selling the products in advance through commercial communication over the communication line, and the user's funds can be deposited. The electronic wallet server guarantees the goods, the cyber shop server guarantees the goods, and the delivery of the goods can be guaranteed by the transport company server, ensuring the safety of commerce in electronic virtual space beyond space-time Specifically, a business transaction system that guarantees the existence of goods and their payments based on order management, distribution management, and deposit settlement management related to electronic commerce in an electronic virtual space represented by the Internet. Can be built.
[0014]
DETAILED DESCRIPTION OF THE INVENTION
Next, an electronic payment system according to the present invention will be described with reference to the drawings.
[0015]
As shown in FIG. 1, the electronic payment system according to the present invention proves that a user (User; UR) who orders and purchases merchandise through a terminal device and that the user UR has a purchase payment for the merchandise. And one or more Electronic Wallet Servers (EWS) that manage cash accounting, including deposits performed to guarantee, and products purchased by users UR on this system. For this purpose, a plurality of cyber shop servers (CSS) that manage ordering with a single or a plurality of product suppliers, and a product selected by the user UR are automatically delivered and collected from this system. Information is collected, collected, delivered and managed for this product. One or more Transport Company Servers (TCS), a user UR, an electronic wallet server EWS, and a cyber shop The server CSS and the transport company server TCS are individually connected to each other via a dedicated or public communication line, and the entire connection is systematically integrated and a transaction history database (Data Base; DB) Laputa Commerce Server, which records and stores above, and proves the presence of the final product by counting down the cooling-off period preset by the cooling-off system It is constructed from LCS) and; ver.
[0016]
The electronic wallet server EWS is connected to the bank server of the financial institution via Ethernet to form an intranet, and the electronic wallet server EWS that has formed the intranet is connected to the Laputa commerce server LCS via the Ethernet. Connected to an Electronic Wallet Duplicant Server (EWDS). The electronic wallet server EWS and the Laputa commerce server LCS are connected via the electronic wallet duplicant server EWDS in this way. In the case of a system using CGI or SSI, writing directly to the other party Compared to the system, double transactions occur in requests and responses, so the traffic is doubled. In addition, processing by the daemon program causes frequent access, which places a heavy load on the traffic. . In this way, even if the traffic is too dense, problems such as excessive communication time and loss of data occur. For this reason, an electronic wallet / duplicant server EWDS is installed and supported by Ethernet to solve problems such as excessive communication time and loss of data.
[0017]
The cyber shop server CSS forms an intranet with a plurality of wholesalers (WS) and a plurality of factories (FC) to form CALS, and the cyber shop server CSS is a computer via the Internet. -It is configured to be connected to a cyber shop duplicate server (CSDP) of the commerce server LCS. The reason why the connection to the Laputa Commerce Server LCS via the Cyber Shop Duplicant Server CSDP is due to the same reason as the above-mentioned Electronic Wallet Duplicant Server EWDS. In the case of a system using SSI, traffic is doubled because of double transactions between requests and responses, and the processing by the daemon program generates frequent access, so a heavy load on traffic. The traffic becomes overcrowded, and it takes too much communication time and data is lost. Therefore, the Cyber Shop Duplicant Server CSDP is installed and supported by Ethernet. Too much or day With each other to solve such as loss of the problem.
[0018]
The transport company server TCS constructs an intranet from a plurality of branches (BR) to form a CALS, and the transport company server TCS transposes the Laputa commerce server LCS via the Internet. It is configured to be connected to a Port Company Duplicant Server (TCDP). The reason why the connection to the Laputa Commerce Server LCS via the Transport Company Duplicant Server TCDP is due to the same reason as that of the Electronic Wallet Duplicant Server EWDS is described above. In the case of a system using SSI or SSI, traffic is doubled because of double transactions in requests and responses, and the processing by the daemon program generates frequent access. This creates an overload and traffic becomes overcrowded, causing problems such as excessive communication time and loss of data. Therefore, the Transport Company Duplicant Server TCDP is installed and supported by Ethernet. Temporal With each other to resolve the Karisugi and data such as loss of the problem.
[0019]
Laputa Commerce Server LCS consists of Cyber Shop Duplicant Server SSDS, which is connected to Cyber Shop Server CSS via the Internet, and Electronic Wallet Duplica, which is connected to Electronic Wallet Server EWS, via the Internet. Kant Server EWDS and Transport Company Duplicant Server TCDS connected to Transport Company Server TCS via the Internet, each of which is connected to Laputa Commerce Server LCS via Ethernet It is connected. The Laputa commerce server LCS is connected to a plurality of users UR via the Internet.
[0020]
The electronic payment system configured in such a connection state includes a user UR, an electronic wallet server EWS, a cyber shop server CSS, and a transport company server TCS connected to the Laputa commerce server LCS. Notifications, certifications, and guarantees between each other are made via Laputa Commerce Server LCS, and product cancellation processing across components and processing based on the cooling-off period are universally ruled in the electronic virtual space. This is based on order management / distribution management / deposit management for electronic commerce in the electronic virtual space represented by the Internet, which secures the safety of commerce in the electronic virtual space beyond time and space. Guarantee the existence of the product and its payment It can be realized the system.
[0021]
In the electronic payment system configured as described above, the proof of the existence of the product by notification of the delivery date and the establishment of the contract by the deposit system by guaranteeing the existence of the settlement amount by the deposit, the protection of the consumer and the final product Introducing a cooling-off system that proves its existence, a deposit notification system as a security against password theft, a cooling-off alarm system that ensures security for consumer protection and product return, and the cyber shop server side Introducing an inspection processing system that protects sellers who sell products, and a notification system that introduces the concept of notification in order to ensure the security of the entire system has been constructed.
[0022]
That is, data transmission / reception among the electronic wallet server EWS, cyber shop server CSS, transport company server TCS, and Laputa Commerce server LCS is performed by CGI or SSI or a system having functions equivalent to these. A configuration in which data is not altered by making a request to a predetermined partner server to search and read the partner database DB and not directly writing to the partner database DB. It has become.
[0023]
The data transmission / reception between the user UR and the Laputa Commerce server LCS is performed only by a request from the user UR by a system having a function equivalent to or higher than CGI (Community Gateway Interface) or SSI (Server Side Include). In this configuration, the data is not altered by eliminating direct writing from the user UR to the Laputa commerce server LCS.
[0024]
In addition, information of the user UR, cyber shop server CSS, transport company server TCS, or electronic wallet server EWS is automatically updated by the Laputa Commerce Server LCS by the timer operation program or the constant operation program. And a cyber shop server CSS, a transport company server TCS and an electronic wallet server EWS, and requests are issued to the user UR, the cyber shop server CSS, and the transport company server TCS. Each electronic wallet server EWS generates a CGI or SSI and responds to the Laputa Commerce Server LCS. It has become such as to perform the transmission and reception configuration.
[0025]
FIG. 2 is a block flow diagram showing a so-called deposit system showing the deposit and contract establishment, that is, the establishment of the contract based on the proof of the existence of the product by the notice of the delivery date and the existence guarantee of the settlement amount by the deposit.
[0026]
First, the user UR uses the order form on the Laputa homepage to register the order details consisting of the delivery destination, registered delivery date, product number, product name, quantity, unit price, amount, etc. in the database DB of the Laputa Commerce Server LCS. (ST100).
[0027]
Cron (CRON) program, which has a function to search at any time that is resident in Cyber Shop Server CSS, searches the database DB of Laputa Commerce Server LCS and has no flag A purchase order or a purchase order with “Balance deficiency resolution flag” and “Retransmission request flag” is extracted (ST101).
[0028]
The CALS (Continuation Acquisition and Lifecycle Support) of the cyber shop server CSS searches the database DB and calculates the delivery date of each item in the order form (ST102).
[0029]
The cyber shop server CSS receives the delivery date data from the CALS of the cyber shop server CSS and registers it in the database DB (ST103).
[0030]
In the Laputa Commerce Server LCS, a daemon (DAEMON) program that always operates in the underground and has a function to respond immediately when an event occurs searches the delivery date data of the Cyber Shop Server CSS and creates a database DB (ST104).
[0031]
The user UR uses the meta tag program, which is an HTML (Hyper Text Markup Language) program that runs at an arbitrarily determined time on the terminal, to deliver the delivery date data of the database DB of the Laputa Commerce Server LCS on the Laputa homepage. Search and read (ST105).
[0032]
If a delivery date notification exists, the delivery date notification indicator blinks and a delivery date notification screen is displayed (ST106). When there is no prospect of arrival and there is no stock, the stock out indicator blinks and is displayed on the notification screen (ST107).
[0033]
When the delivery date is accepted, the delivery date click button is clicked (ST108), and HTTP of the Laputa Commerce Server LCS is requested to accept the delivery date (ST109), and the CGI program, that is, the Hyper Text Transfer Protocol (HTTP) program is used. The CGI program that operates in response to an external request and has a function of returning the result of the request to the originator of the request sets a contract establishment flag in the database DB of the Laputa Commerce Server LCS ( ST110).
[0034]
If the delivery date is cancelled, the cancel button is clicked (ST111). Then, a cancellation process is requested to HTTP of Laputa Commerce Server LCS, a temporary file for an order form in Database DB of Laputa Commerce Server LCS is deleted, and cancellation is registered in Database DB (ST112, ST113).
[0035]
In this way, the delivery date of the product and the proof of the existence of the product can be proved by the user UR placing an order for the product to the cyber shop server CSS through the Laputa Commerce server LCS within the cyber shop server CSS. -The commerce server LCS detects that a product order has been received from the user UR. When this product order is detected, the database DB of the cyber shop server CSS or the client in the cyber shop server CSS is detected. The inventory search for the product ordered by the user UR can be performed to calculate the simple delivery date of the product.
[0036]
This simple delivery time is combined with the number of days required for delivery by the delivery location designated by the user UR to calculate the final delivery date to the delivery location designated by the user UR, and the final delivery date of the product is determined through the Laputa Commerce Server LCS. The product can be proved by sending it back to the user UR.
[0037]
On the other hand, when the order contents of the order form are registered in step ST100, the electronic wallet server EWS searches the database DB of the Laputa commerce server LCS by the daemon program, and the order form is not flagged at all. Alternatively, an order form with a “balance shortage flag” and “retransmission request flag” is extracted. Then, the balance of the registered user UR in the electronic wallet server EWS is compared with the purchase amount, and “purchase availability” is registered in the database DB (ST114).
[0038]
The daemon program of Laputa Commerce Server LCS searches the database DB of the electronic wallet server EWS, extracts new data about “purchasability”, and sets a flag of “purchasability” in the database DB (ST115).
[0039]
If the purchase is possible, a purchase possible flag is set, and if the purchase is not possible, a purchase impossible flag is set and notified by E-mail (ST116, ST117).
[0040]
Also, the meta tag program on the Laputa homepage searches for an insufficient balance flag, and if so, displays the format for depositing and canceling, and the metatag program on the Laputa home page searches for "Balance shortage flag" and if there is an indicator of insufficient balance Flashes (ST118, ST119).
[0041]
If the deposit process is performed, the process is executed again from steps ST101 and ST114. In the case of the cancel process, cancel is selected (ST120).
[0042]
The Laputa Commerce Server LCS daemon program deletes the temporary file for the purchase order, sets a cancel flag in the database DB, and the Electronic Wallet Server EWS daemon program searches the Laputa Commerce Server LCS and sets the cancel flag. If found, the data based on the order code is deleted from the database DB (ST121, ST122).
[0043]
In parallel with proving the existence of the product in this way, the electronic wallet server EWS detects the product order of the user UR and the user in the electronic wallet server EWS with respect to the settlement amount of the ordered product. The existence of the settlement amount can be guaranteed by searching the magnitude of the UR deposit balance and notifying the user UR and the cyber shop server CSS via the search result via the Laputa Commerce server LCS.
[0044]
In addition, the existence of this product is proved by Cyber Shop Server CSS, and it is proved by Electronic Wallet Server EWS that the deposit balance is greater than or equal to the settlement deposit balance, and user UR approves the final delivery date. When the Laputa Commerce Server LCS is notified that the electronic wallet server EWS is able to guarantee the existence of the payment amount by depositing the payment amount equivalent from the deposit balance, This guarantee can be considered as a product order.
[0045]
In addition, when there is no product ordered from the user UR, or when the user UR is dissatisfied with the final delivery date, the deposit balance notification from the electronic wallet server EWS is made via the Laputa Commerce Server LCS. If the user UR cancels the product order, the product order may not be established.
[0046]
When the deposit balance is less than the settlement amount and the user UR receives a shortage of balance notification from the electronic wallet server EWS via the Laputa Commerce server LCS, until the user UR performs the deposit process , Put the product order on hold.
[0047]
In this way, when the purchase possible flag indicating that the existence of the settlement amount is proved and the contract establishment flag indicating that the existence of the commodity is proved, the daemon program of the Laputa Commerce Server LCS is stored in the database. The “deposit flag” is set in the DB, and the deposit notification system is set (ST114, ST115).
[0048]
FIG. 3 is a block flow diagram showing a deposit notification system for security against a user password theft.
[0049]
The deposit and reporting system is a system for trying to match the person who wants to purchase the product with the true user. When the product is purchased, it is configured to provide feedback to the user who has the purchased password for security. Has been.
[0050]
FIG. 3 is a block flow diagram thereof. First, in the deposit system described with reference to FIG. 2, it is assumed that the daemon program of Laputa Commerce Server LCS has a deposit flag in the database DB (ST116).
[0051]
The meta tag program of the user UR's Laputa homepage requests the HTTP of the Laputa Commerce Server LCS for the presence or absence of a deposit flag in the temporary file in the user directory (ST117).
[0052]
When the deposit flag is set, the deposit indicator of the user UR blinks, and when there is no deposit flag, nothing is done (ST118, ST119).
[0053]
Here, the user UR can input approval or cancellation.
[0054]
When the user UR inputs cancel, the deposit flag is deleted, and a request is made to the Laputer Commerce Server LCS to delete the temporary file in the user directory (ST120, ST121).
[0055]
When Laputa Commerce Server LCS receives this request, it deletes the deposit flag in the database DB and also deletes the temporary file in the user directory (ST122).
[0056]
When the deposit flag is deleted, the blinking of the deposit indicator ends (ST123).
[0057]
On the other hand, when the user inputs consent, a request for a deposit approval flag is made to the Laputa commerce server LCS (ST124, ST125).
[0058]
HTTP of Laputa Commerce Server LCS creates a deposit approval CGI and registers the deposit approval in the temporary file and database DB of the user directory (ST126).
[0059]
The electronic wallet server EWS searches the database DB of the Laputa commerce server LCS and, if there is a deposit approval flag, sets a deposit flag in its own database DB (ST127).
[0060]
The bank server searches the database DB of the electronic wallet server EWS, and executes the deposit process if there is a deposit approval flag (ST128).
[0061]
In this way, when the user UR approves the delivery date of the product and the existence of the payment amount by the electronic wallet server EWS is proved, the deposit flag is set in the Laputa Commerce server LCS, and the user UR makes this deposit. When it is detected that the flag is set, the user UR can visually confirm that the deposit flag is set, and it is possible to visually determine whether the true user has purchased the product.
[0062]
In addition, when the user UR inputs the approval in such a manner that the response can be made by inputting the approval or cancellation, the electronic wallet server EWS detects the accepted deposit flag and settles the deposit amount and the settlement amount of the product. By performing the processing, it is possible to achieve financial security.
[0063]
Further, when the user UR inputs a cancel, it is determined that this is not the purchase of the goods of the true user UR, and the Laputa Commerce server LCS detects the canceled deposit flag and detects the data field of the commercial transaction. Delete.
[0064]
4 to 6 show a cancellation system for protecting consumers.
[0065]
A cancellation system for protecting consumers, that is, a cancellation process for a product order made by a user, is a product order for which the Laputa Commerce Server LCS has not yet created a data field for a commercial transaction on a recording medium, such as a database. It is valid only at the two stages from the time until the delivery date is approved and the time when the Laputa Commerce Server creates the data field for the commercial transaction on the recording medium to the time before the delivery certificate is issued.
[0066]
The case where the data field has not been created means that the Laputer Commerce Server LCS has finished without executing the creation of the data field, and the case where the data field has been created means that the Laputa Commerce Server LCS has been created. Deletes this data field.
[0067]
FIG. 4 is a block flow diagram showing a cancellation process from when the user UR approves the delivery date of the product until delivery.
[0068]
First, when the user UR inputs and transmits a cancel using the cancel form, the CGI of the Laputa Commerce server LCS sets a cancel flag in the temporary file and the database DB (ST130, ST131).
[0069]
The daemon program of the electronic wallet server EWS searches the user directory of the Laputa commerce server LCS, and if there is a cancel flag, sets a cancel flag in its own database DB (ST132).
[0070]
If the daemon program of Transport Company Server TCS searches the user directory of Laputa Commerce Server LCS and there is a cancel flag, it sets a cancel flag in its own database DB (ST133).
[0071]
The daemon program of the cyber shop server CSS searches the user directory of the Laputa commerce server LCS, and if there is a cancel flag, sets a cancel flag in its own database DB (ST134).
[0072]
In this way, the cancel flag is processed in each of the servers EWS, TCS, and CSS. If the daemon program of the Laputa Commerce Server LCS searches the database of each server and there is a cancel flag, the temporary file in the user directory is Delete and register the cancellation in the database DB (ST135).
[0073]
Therefore, the cyber shop server CSS detects the cancellation process for the product order of the user UR based on the loss of the data field in the Laputa Commerce server LCS and the presence of the data field in its own database. Later, the consumer is protected by performing cancellation processing in two stages before shipment and after shipment.
[0074]
FIG. 5 is a block flow diagram showing the correspondence of the cyber shop server CSS by cancel processing.
[0075]
The daemon program of the cyber shop server CSS searches the user directory of the Laputa commerce server LCS, and if there is a cancel flag, sets a cancel flag in its own database DB (ST136).
[0076]
If it is before shipment and there is no outgoing data in its own database, the data in the database DB is deleted (ST137).
[0077]
Then, it is registered as a canceled stock in the CALS inventory database of the cyber shop server CSS (ST138).
[0078]
After shipment, if there is outgoing data for the data in its own database DB, the database DB of Laputa Commerce Server LCS is searched, and if there is a return delivery completion flag for the data, its own database All the data in the DB is deleted (ST139).
[0079]
If there is a cancel flag, the file related to the transaction in its own database is deleted, and nothing is required (ST140, ST141).
[0080]
Furthermore, after acquiring the data for this cancellation process, the transport company server TCS performs the cancellation process in three stages before shipment, after shipment, and during delivery to protect consumers. It has the configuration shown.
[0081]
FIG. 6 is a block flow diagram showing the correspondence of the transport company server TCS in the cancellation process.
[0082]
The daemon program of the transport company server TCS searches the user directory of the Laputa commerce server LCS, and if there is a cancel flag, sets a cancel flag in its own database DB (ST142).
[0083]
If it is before collection, if there is no collected flag in the database DB, the daemon program deletes the collected data in its own database DB after 6 hours (ST143).
[0084]
If it is after collection, if there is a collection flag in the database DB and there is no shipment flag, a return delivery flag is set (ST144).
[0085]
Then, “Returned delivery completed” is input, and a returned delivery completed flag is set in the database DB (ST145).
[0086]
The daemon program of Laputa Commerce Server LCS searches the database DB of the transport company server TCS, and if there is a return delivery flag, sets a return delivery flag in the database DB (ST146).
[0087]
The electronic wallet server EWS daemon program searches the database DB of the Laputa commerce server LCS, and if there is a return delivery flag, sets the deposit cancellation flag (ST147).
[0088]
If the daemon program of Laputa Commerce Server LCS searches the database DB of the electronic wallet server EWS and there is a deposit release flag, the temporary file of the data is deleted, and cancellation is registered in the database DB (ST148).
[0089]
If the bank server daemon program searches the database DB of the electronic wallet server EWS and there is a deposit release flag, the deposit of the data is released (ST149).
[0090]
Then, the electronic wallet server EWS searches the database DB of the bank server, and if the deposit of the deposit cancellation flag data is cancelled, the data in its own database DB is deleted (ST150).
[0091]
7 to 13 are block flow diagrams showing the cooling-off system.
[0092]
The cooling-off system is a system for proof of consumer protection and final product existence provided for measures against mail-order problems with the minimum cooling-off period stipulated by law. This is a system that can be returned unconditionally within the cooling-off period if the product is different from the consumer's image, or is damaged or soiled, without being confirmed directly. Is expanding this return and setting its own period, and at the same time uses it to prove the existence of the final product.
[0093]
In other words, the cooling-off system provides the cyber shop server according to the guidelines set based on the performance and properties of each product after the delivery certificate of the product to the user UR is issued by the Transport Company Server TCS. -The company or individual that maintains and manages functions until the end of the cooling-off period that is set based on the performance and properties unique to each product.
[0094]
This cooling-off system includes: a cancel processing means by a cooling off application performed by the user UR when returning a product; a retransmission request processing means for resending the product in response to a resend request from the user UR; a cooling off period out-of-period processing means; Cooling-off cancellation date calculation means based on delivery end at Transport Company Server TCS, Cooling-off warning means based on product delivery end time at Transport Company Server TCS, and cancellation of cooling-off from the user It comprises cooling-off canceling means for processing, and cooling-off inspection processing means for performing return processing of the product that has arrived at the user's hand based on the cooling-off period.
[0095]
Assuming that the end of the cooling-off period in the cooling-off system has been confirmed by the user that the product is identical to the user's ordered product, the final product has been proved. It is.
[0096]
FIG. 7 is a block flow diagram showing a cancellation processing means by a cooling-off application that is performed when the user UR returns a product.
[0097]
First, when the user UR wants to return the product in the cooling off form on the Laputa homepage, that is, when requesting the cooling off application from the Laputa Commerce Server LCS, the CGI of the Laputa Commerce Server LCS sends the temporary purchase order file to the user directory. And it registers in database DB (ST151).
[0098]
The daemon program of Laputa Commerce Server LCS checks whether or not the cooling-off application is within the cooling-off period (ST152).
[0099]
If it is outside the period, the process goes to a processing routine outside the cooling off period (processing means outside the cooling off period), and if it is within the cooling off period, the daemon program sets a cooling off flag in the temporary file and the database DB (ST153, ST154). .
[0100]
When the cooling-off flag is raised, various servers are started. First, the coulomb program of the electronic wallet server EWS extracts the cooling off flag of the Laputa commerce server LCS, and sets the cooling off flag in its own database DB (ST155).
[0101]
The cron program of the cyber shop server CSS extracts the cooling off flag of the Laputa commerce server LCS and sets the cooling off flag in its own database DB (ST156).
[0102]
The Coulomb program of Transport Company Server TCS extracts the cooling off flag of Laputa Commerce Server LCS and sets the cooling off flag in its own database DB (ST157).
[0103]
Then, the data with the cooling-off flag set is displayed on the browser of the terminal of the transport company server TCS (ST158).
[0104]
After completing such work (ST155 to ST158), the Coulomb program of Laputa Commerce Server LCS picks up an order file that has reached the “cooling-off release date”, deletes the cooling-off flag, and releases it (ST159). .
[0105]
Also, the electronic wallet server EWS coulomb program searches for new “cooling-off release date data” and registers the date in its own database DB (ST160).
[0106]
When the Coulomb program of Electronic Wallet Server EWS searches the database DB of Laputa Commerce Server LCS and detects the release of cooling off, it collates with the data of “Cooling Off Date” in its own database DB, If it is a date after "date data", a "deposit / settlement flag" is set (ST161).
[0107]
In step ST157, when the transport company server TCS sets a cooling-off flag, the shipping company registers completion of return delivery in the database, and passes the data to the shipping company's collection / delivery system (ST162, ST163).
[0108]
The Coulomb program of Laputa Commerce Server LCS searches the database DB of Transport Company Server TCS, and if there is a “Return Delivery Complete” registration, the flag “Return Delivery Complete” is set in the Database DB. Stand up (ST164).
[0109]
The returned merchandise is inspected by the cyber shop server CSS to determine whether or not it is a merchandise requested, and a flag is set in the database DB (ST165).
[0110]
The Coulomb program of Laputa Commerce Server LCS searches the database of Cyber Shop Server CSS and reads the “true” and “false” flags of the returned goods (ST166).
[0111]
In the case of “false”, an email not accepting is sent and the data is given to the person in charge of complaint processing. In the case of “true”, it is confirmed by the flag of “return delivery complete” in step ST164 that the return delivery is completed and the returned product is true, and the electronic wallet server EWS coulomb program is When the database DB of the Laputa Commerce server LCS is searched and the flag is searched and found, a flag of “deposit / cancel” is set (ST167).
[0112]
If the Coulomb program of the Laputa Commerce Server LCS searches the database DB of the electronic wallet server EWS and finds the “deposit / cancel flag”, the temporary file is deleted (ST168).
[0113]
If the bank server daemon program finds "deposit / settlement flag" or "deposit / cancel flag" from the database DB in step ST161 and step ST167, the deposit is canceled and remittance or remittance procedure is performed. (ST169).
[0114]
Further, when the meta tag program of the user UR searches the database DB of the Laputa Commerce server LCS and finds a “return delivery complete” flag and a “returned product is true” flag, the indicator blinks ( ST170).
[0115]
When the user UR inputs “OK”, the cooling-off format is deleted or stopped, and the blinking is stopped (ST171, ST172).
[0116]
In addition, when the cron program of Laputa Commerce Server LCS searches the database to find the “Return Delivery Complete” flag and the “Returned Good is True” flag, A message “completion completed” is sent to the user (ST173).
[0117]
FIG. 8 is a block flow diagram showing retransmission request processing means for resending a product in response to a retransmission request from the user UR.
[0118]
The cooling-off processing unit that makes a re-transmission request is a system for returning a product and requesting it to be sent again if there is an error, damage, or contamination of the product as part of the cooling-off.
[0119]
First, the user UR requests a product again in the cooling-off format (JAVA). The contents to be input at this time are the delivery date, the desired delivery date / time for the re-sent product, the product number, the quantity, the amount of money, the cause of the charge (selected by numbers from the example, etc. (ST175)
[0120]
The Laputa commerce server LCS searches the database DB by the daemon program and checks “presence / absence of applicable product” and “inside / out of cooling off period” (ST176).
[0121]
If it is outside the cooling-off date, the routine goes to the routine of the processing system outside the cooling-off period (ST177).
[0122]
If it is within the due date, a confirmation message is sent to the user UR from the Laputa Commerce server LCS, and the user UR can accept or input a change (ST178, ST179).
[0123]
When the user UR accepts, the daemon program of Laputa Commerce Server LCS deletes the existing temporary file, creates a new temporary file, and creates a new purchase order (data field) in the database DB. A “retransmission request flag” is set for each of them, and the product is sent to the deposit system shown in FIG. 2 (ST181).
[0124]
On the other hand, the returned merchandise is inspected by the cyber shop server CSS to determine whether or not it is an applied merchandise, and a flag is set in the database DB (ST182).
[0125]
The Coulomb program of Laputa Commerce Server LCS searches the database DB of Cyber Shop Server CSS and reads the “true” and “false” flags (ST183).
[0126]
If it is “true”, Laputa Commerce Server LCS creates an order form and sets a “retransmission request flag”, goes to the deposit system shown in FIG. 2 and performs the process of shipping the goods (ST181).
[0127]
If it is “false”, the mail is sent to the effect that it cannot be accepted and the data is given to the person in charge of complaint processing (ST184).
[0128]
FIG. 9 is a block flow diagram showing a cooling off-period outside processing system which is a processing unit outside the cooling off period.
[0129]
First, it is assumed that the daemon program of Laputa Commerce Server LCS sets the “cooling off impossible flag” in the temporary file and the database DB (ST185).
[0130]
When the user UR's meta tag detects the cooling off impossibility flag, the indicator on the user UR's Laputa homepage blinks, and at the same time, an information indicating that the cooling off is impossible is displayed and an approval is obtained (ST186).
[0131]
At the same time, the daemon program of Laputa Commerce Server LCS sends mail to the user UR (ST187).
[0132]
Here, the user UR inputs an answer to the information (ST188).
[0133]
When not agreeing, the balance of the user UR is displayed, the fact that the purchase amount exceeds the balance is disclosed, and the reply is prompted again (ST189).
[0134]
If it is accepted, the daemon program of Laputa Commerce Server LCS deletes the cooling-off flag and the cooling-off impossible flag and goes to the settlement process (ST190, ST191).
[0135]
FIG. 10 is a block flow diagram showing a cooling-off cancellation date calculation unit, which is a cooling-off cancellation date calculation means based on the end of delivery in the Transport Company Server TCS.
[0136]
In the cooling-off cancellation date calculation unit, first, the fact that the delivery has been completed is registered in the database DB in the Transport Company Server Sporter Server TCS (ST195).
[0137]
The Coulomb program of Laputa Commerce Server LCS searches the database DB of the transport company server TCS, and if there is new delivery end data, it sets a “delivery end flag” for the database DB (ST196).
[0138]
Then, the Coulomb program of Laputa Commerce Server LCS calculates the cooling-off cancellation date and registers the date in the database DB (ST197).
[0139]
In addition, the Coulomb program of Laputa Commerce Server LCS calculates the cooling off alarm issuance date and registers the date in the database DB (ST198).
[0140]
FIG. 11 is a block flow diagram showing a cooling-off warning system which is a cooling-off warning means based on the delivery end period of goods in the transport company server TCS.
[0141]
The cooling-off warning system applies a cooling-off request that is applied when the user UR returns, sets a cooling-off flag, and when the Laputa Commerce Server detects that this cooling-off flag is set, the warning issuance date and cooling-off Calculate the release date. Pick up the order file that has reached this warning date and set an alarm flag. When the user UR detects that the cooling off flag is set, the user UR can visually confirm that the cooling off flag is set. In addition, it is possible to cope with three ways of understanding, claiming, and canceling the cooling-off.
[0142]
The claims that can be handled by the user UR are issued when the user UR has already returned and delivered, and at the same time a claim flag is set in the Laputa Commerce Server LCS, and at the same time, a separate email is sent to the Transport Company Server TCS. When the transport company server TCS detects this claim, it sets a claim flag, and the transport company server TCS detects this claim flag. Then, the transport company server TCS can visually confirm that the claim flag is set. This will be described below with reference to the block flow diagram of FIG.
[0143]
First, when the Coulomb program of the Laputa Commerce Server LCS detects a new cooling off flag set by the user UR, it calculates “alarm issue date” and “cooling off release date” and registers the results in the database DB ( ST200).
[0144]
The Coulomb program of Laputa Commerce Server LCS picks up the order file that has reached the “alarm announcement date” and sets an “alarm flag” in the database DB (ST201).
[0145]
Alternatively, it is assumed that the transport company server TCS has set a “returned delivery flag” in its own database DB (ST202).
[0146]
When the daemon program of Laputa Commerce Server LCS finds the “Returned Delivery Flag” in the database DB of Transport Company Server TC, it sets the “Returned Delivery Flag” in the Database DB of Laputa Commerce Server LCS, At the same time, the “alarm flag” is deleted (ST203).
[0147]
When the meta tag program of the user UR searches the database DB of the Laputa Commerce server LCS and finds an “alarm flag” in the data, the indicator flashes. When the indicator is clicked, an approval form is displayed (ST204).
[0148]
Here, the user UR can input any one of “OK”, “Cooling-off cancellation”, and “Claim processing” (ST205).
[0149]
When the user UR inputs “OK”, the blinking is stopped by deleting or stopping the blink command in the format supplied to the user UR (ST206).
[0150]
If "Cooling-off cancellation" is input, a cooling-off cancellation format is selected and the routine goes to the cooling-off cancellation system routine (ST207).
[0151]
When “claim processing” is input, the user UR selects a claim format and inputs a delivery number and a delivery date (ST208).
[0152]
Then, a complaint flag is set in the temporary file and database DB of Laputa Commerce Server LCS, and at the same time, the shipping company is notified by e-mail (ST209).
[0153]
When the daemon program of the transport company server TC finds the claim flag of the temporary file of the Laputa commerce server LCS, the terminal of the transport company server TCS blinks an alarm (ST210).
[0154]
At the same time, a mail is sent to the transport company server TCS, and the transport company server TC shifts the processing to the claim processing person (ST211 and ST212).
[0155]
FIG. 12 is a block flow diagram showing a cooling-off canceling system which is a cooling-off canceling means for processing cooling-off canceling from the user UR.
[0156]
The cooling-off cancellation is issued when the user UR has applied for the cooling-off but has not yet returned or shipped it. The user UR stops the cooling-off and the product is the same as the ordered product. Issued when it is confirmed that the transport company server TCS detects this cooling-off stop flag by issuing a request for the user UR to set a cooling-off stop flag to the Laputa Commerce Server LCS. Then, the delivery plan of the product is rearranged.
[0157]
Further, when the electronic wallet server EWS and the cyber shop server CSS detect the cooling off stop flag, the electronic wallet server EWS and the cyber shop server CSS delete the cooling off flag. Hereinafter, this will be described with reference to the block flow diagram of FIG.
[0158]
The user UR requests the Laputa Commerce Server LCS to cancel the cooling off in the “cooling off cancellation” format (ST215).
[0159]
Then, the CGI of Laputa Commerce Server LCS sets a “cooling off stop flag” in the database DB and the temporary file (ST216).
[0160]
When the daemon program of Transport Company Server TC searches the database DB of Laputa Commerce Server LCS and finds “Cooling Off Cancel Flag”, it deletes “Cooling Off Flag” from its own database DB, An “off stop flag” is set (ST217).
[0161]
At the same time, when the electronic wallet server EWS daemon program searches the database DB of the Laputa Commerce server LCS and finds the “cooling off stop flag”, it deletes the “cooling off flag” of its own database DB (ST218). .
[0162]
At the same time, if the daemon program of the cyber shop server CSS searches the database DB of the Laputa commerce server LCS and finds the “cooling off stop flag”, the “cooling off flag” of its own database DB is deleted (ST219). .
[0163]
The daemon program of Laputa Commerce Server LCS searches the database DB of each server, and checks whether the cooling off flag has been deleted for the data corresponding to the data for which the “cooling off cancellation flag” is set in its own database DB If all checks have been deleted, the daemon program of Laputa Commerce Server LCS deletes the “Cooling Off Cancel Flag” from the temporary file (ST220).
[0164]
On the other hand, when the daemon program detects the “cooling off stop flag” in the database DB, the transport company server TCS rearranges the delivery plan (ST221).
[0165]
On the day of pickup, the daemon program will notify the delivery vehicle by phone or email. The daemon program of the transport company server TCS deletes the “cooling off stop flag” (ST222, ST223).
[0166]
FIG. 13 is a block flow diagram showing a cooling-off inspection processing unit which is a cooling-off inspection processing means for performing a return processing of a product delivered to the user UR based on the cooling-off period.
[0167]
The cooling-off inspection processing means sets a return reason flag after the ordered product reaches the user UR. This return reason flag consists of four types of mistakes, damage / stain, and the product was different from what was expected. Each flag is based on the cooling-off application for the product from the cyber shop server CSS. The products for return are inspected.
[0168]
In addition, the inspection processing means for the cooling-off is within the period when the product for return is applied for cooling-off, and in the case of damage / stain, whether it is due to damage / stain during transportation or omission of inspection during delivery or intentional A determination is made, and in the case of breakage / fouling during transportation or omission of inspection at the time of delivery, it is retransmitted.
[0169]
Then, the inspection processing means for cooling off will identify whether the product for return is within the cooling off period and the product is different from the expected or for other reasons, and whether the product is damaged or soiled.・ In case of damage, determine whether it is damaged during transportation, damage, inspection omission during delivery or intentional inspection, and if it is damaged during transportation, contamination or omission of inspection during delivery, resend is there. This will be described below with reference to the block flow diagram of FIG.
[0170]
First, the cyber shop server CSS searches the database DB of the Laputa Commerce server LCS, and reads “Reason for return (flag)” from the cooling-off application item (ST225).
This flag is composed of four types: “product mistake”, “damage / stain”, “product was different than expected”, and “other”.
[0171]
Whether the product to be inspected is a product handled by the company is inspected, a flag is set, and if the product is an in-house product, the product number is input (ST226).
[0172]
If it is certified as a non-in-house product, an email indicating that it is not accepted is sent, and the data is passed to the person in charge of complaint processing (ST227).
[0173]
If the product is certified as an in-house product, the database DB of the cyber shop server CSS is searched to investigate the delivery time of the product number product, and compared with the cooling-off period, it is checked whether the product is a cooling-off product (ST228).
[0174]
For inspections that are within the cooling-off period and the cause of return is “product was not as expected” or “for other reasons”, check for damage / stain and enter the result in the input format ( ST228).
[0175]
If there is damage / stain, a “damage / stain flag” is added to the database DB of the cyber shop server CSS (ST229).
[0176]
If there is no damage / stain, a flag indicating that the returned product is “true” is set in the database DB of the cyber shop server CSS (ST230).
[0177]
If the cause of return is “damage / stain” during the cooling-off period, the inspection inspects the cause of damage / stain and inputs the result of certification in the input format (ST231).
[0178]
If it is determined to be intentional, a countermeasure instruction is displayed, an e-mail indicating that it cannot be accepted is sent, and the data is passed to the person in charge of the complaint (ST232, ST233).
[0179]
If it is determined that the accident is in transit, it is coordinated with the shipping company, and if unsuccessful, the data is passed to the claimant (ST234, ST235, ST236).
[0180]
When it is agreed that insurance can be handled, a flag of “true” is requested from the input form, and a flag indicating that the returned product is “true” in the database DB of the cyber shop server CSS is set (ST237, ST238). ).
[0181]
In addition, even when it is determined that it is unknown or omission of inspection, a flag indicating that the product returned to the database DB of the cyber shop server CSS is “true” is set (ST238).
[0182]
In step ST228, if there is no delivery record, a “no delivery record flag” is set, an email indicating that the delivery is not accepted is sent, and data is sent to the person in charge of complaint (ST239, ST240).
[0183]
In step 228, if it is outside the cooling-off period, it is confirmed by e-mail whether the product has been sent to the user UR by mistake (ST241).
[0184]
If there is no mistake, a flag outside the cooling-off period is set and the system goes to the processing system outside the cooling-off period (ST242, ST243).
[0185]
In step 241, if a product is sent in error, the user UR requests the cooling off flag deletion or the cyber shop server CSS requests the cooling off flag deletion. When the daemon program of Laputa Commerce Server LCS detects both, the cooling off flag is deleted and a new temporary file is created. Also, a new order form is created in the database DB, a reissue flag is set for each, and a cooling-off application process is performed (ST244, ST245, ST246, ST247).
[0186]
FIG. 14 is a block flow diagram showing a settlement method after the existence of a product is proved.
[0187]
In payment for goods, when depositing money deposited with Electronic Wallet Server EWS to the account of the person who actually provides the goods at Cyber Shop Server CSS that sold the goods, Electronic -The wallet server EWS confirms that this product is in the hands of the user UR by receiving a proof of delivery of this product from the transport company server TCS via the Laputa Commerce server LCS. In addition, when the Laputa Commerce Server LCS confirms the end of the cooling-off period automatically calculated by the program by the Laputa Commerce Server LCS, the user UR makes this product the same as the product ordered by the user UR. It is recognized that the user UR has approved, and the deposit amount is transferred to the account of the person who actually sells the goods in the cyber shop server CSS.
[0188]
In addition, the electronic wallet server EWS notifies the Laputa Commerce Server LCS that the deposit has been canceled and the product is settled, and the Laputa Commerce Server LCS writes the settlement in the database DB. The product order file is deleted. Hereinafter, a description will be given with reference to the block flow diagram of FIG.
[0189]
First, it is assumed that the transport company server TCS has registered delivery completion in the database DB (ST250).
[0190]
Then, the Coulomb program of Laputa Commerce Server LCS searches the database DB of the transport company server TCS, and if there is new delivery end data, it sets a “delivery end flag” in the database DB (ST251).
[0191]
For the data for which the cron program of Laputa Commerce Server LCS has set the “delivery end flag”, the cooling-off cancellation date is calculated and the date is registered in the database DB (ST252).
[0192]
The electronic wallet server EWS coulomb program searches the database DB of the Laputa Commerce server LCS, and if there is data that has reached the "cooling-off release date", it will be stored in its own database DB (ST166).
[0193]
The bank server searches the database DB of the electronic wallet server EWS, and if there is a “deposit / settlement flag”, the deposit is canceled and remittance is sent to the cyber shop server CSS (ST254).
[0194]
Further, from step ST164, when canceling, the process goes to the cooling-off processing unit shown in FIG. 7, and when requesting retransmission, the process goes to the cooling-off processing unit shown in FIG. 8 (ST255, ST256).
[0195]
【The invention's effect】
As described above, the electronic payment system according to the present invention includes a user who performs through a terminal device, a single or a plurality of electronic wallet servers that manage deposits and deposits including a deposit, and a single product or a plurality of products. A cyber shop server that manages ordering with other product suppliers, collects information on automatic delivery and collection of products, collects, delivers and manages products, and confirms that delivery has been completed. The company is connected to the Transport Company Server to be certified, the User, the Electronic Wallet Server, the Cyber Shop Server, and the Transport Company Server individually via a communication line. Integration, transaction history recorded and stored in a database, and cooling Each user and electronic wallet connected to the Laputa Commerce Server consists of a Laputa Commerce Server that proves the presence of the final product based on the cooling off period preset by the system.・ Communication, certification, and guarantee between the server, cyber shop server, and transport company server via the Laputa Commerce server, and electronic processing based on product cancellation processing and cooling off period Order management related to electronic commerce in the electronic virtual space represented by the Internet, which secures the safety of commerce in the electronic virtual space beyond the space-time by making it universally ruled in the virtual space, Based on logistics management and deposit settlement management There is an effect that say that it is possible to guarantee the presence of and its settlement price goods Te.
[Brief description of the drawings]
FIG. 1 is an explanatory diagram showing a connection relationship of an overall configuration according to the present invention.
FIG. 2 is a block flow diagram showing the deposit system.
FIG. 3 is a block flow diagram showing a deposit notification system in the electronic commerce system.
FIG. 4 is a block flow diagram showing from delivery date acceptance to delivery of a cancellation processing unit in the electronic commerce system.
FIG. 5 is a block flow diagram showing a corresponding system unit of the cyber shop server CSS in a cancellation process in the electronic commerce system.
FIG. 6 is a block flow diagram showing a corresponding system unit of the transport company server TC in a cancellation process in the electronic commerce system.
FIG. 7 is a block flow diagram showing cancellation processing of a cooling-off processing unit (1) in the electronic commerce system.
FIG. 8 is a block flow diagram showing a request for retransmission of a cooling-off processing unit (2) in the electronic commerce system.
FIG. 9 is a block flow diagram showing a cooling off-period processing system of a cooling off processing unit (3) in the electronic commerce system.
FIG. 10 is a block flow diagram showing a cooling-off cancellation date calculation unit in the electronic commerce system.
FIG. 11 is a block flow diagram showing a cooling off alarm system of a cooling off processing unit (4) in the electronic commerce system.
FIG. 12 is a block flow diagram showing a cooling off cancellation system of a cooling off processing unit (5) in the electronic commerce system.
FIG. 13 is a block flow diagram showing a cooling-off inspection processing unit in the electronic commerce system.
FIG. 14 is a block flow diagram showing a settlement processing unit in the electronic commerce system.
FIG. 15 is an explanatory view showing a commercial transaction in the prior art.
[Explanation of symbols]
UR; User, CSS; Cyber Shop Server, EWS; Electronic Wallet Server, TCS; Transport Company Server, LCS; Laputa Commerce Server

Claims

Connect to an external system via a communication line,
Receives information from the user who is the purchaser that the product has been ordered to the shop which is the seller, and information on whether or not the user has a payment for the order, that is, whether or not there is a payment ability, and the order is established Determine whether or not
If it is determined that the order has been established due to the presence of the settlement price equivalent, the deposit price is instructed to guarantee the existence of the settlement price in order to secure the settlement capability of the user,
If it is determined that the order is not established due to the absence of an amount equivalent to the settlement price, the user is notified by email or the like that the order is not established,
Something delivered to the user by receiving information (delivery information) that the item considered as the product, that is, any item deemed to be ordered by the user who is the orderer, has been delivered to the user Cooling calculated from the delivery date based on the delivery date information included in the delivery information and the pre-registered cooling-off period (universal cancellation period of commercial transaction contract) information Calculate the off-date,
Receiving the information “whether the delivered item is a product ordered by the user” or not, and determining the presence of the product ordered and delivered by the user together with the cooling-off date;
If the information about the authenticity of the product is not received by the cooling-off date or if the information that “the delivered item is the product ordered by the user” is received, the ordered and delivered by the user It is determined that there is a product that has been released, and the deposit is secured, and an instruction is issued to execute the process of paying the store for settlement, i.e., the deposited settlement price,
By the cooling-off date, information that “the delivered item is not a product ordered by the user” is received, and by the cooling-off date, delivery of returned goods from the user and confirmation of receipt of the product by the shop If the information is received, it is determined that there is no product ordered and delivered by the user, and the deposit as a collateral is canceled and a refund, that is, the deposit settlement price is returned to the user. A Laputa Commerce server that gives instructions to
A terminal device that is connected to an external system via a communication line, and that allows a purchaser to perform an ordering procedure, a cooling-off procedure, a return application procedure, and a cash accounting management procedure;
A cyber shop server and a client, that is, a terminal device, for connecting to an external system via a communication line and registering / aggregating information related to a commercial transaction by the shop ,
Connecting to an external system via a communication line, and using the delivery information, the delivery information is used to guarantee that the product is delivered to the user as a product shipped by the cyber shop, and the delivery information is A transport company server notifying the Laputa commerce server and a client or terminal device for inputting the delivery information;
Connected to a financial institution server and the Laputa Commerce server via a communication line, and connected to a user terminal, shop and transport company server or terminal via a communication line, from the Laputa Commerce server. Providing a system environment for managing funds including cash in and out of the account that is the electronic wallet of the user, the shop, and the transport company at the same time as executing and canceling the deposit of the settlement price according to the instructions of Consists of an electronic wallet server that performs or directs the transfer process as a payment or refund process,
The user's order information including the settlement amount input to the user's terminal device is transmitted to the Laputa Commerce server via a communication line, and the Laputa Commerce server stores the account of the user's electronic wallet. Obtain deposit balance information from the electronic wallet server and determine whether the deposit balance is more than the settlement price, that is, whether there is a payment capability, and if the deposit balance in the user's electronic wallet account is greater than the settlement price By registering the order information in the database of the Laputa Commerce Server, the shop server is notified as order information, and at the same time, the Laputa Commerce Server secures the payment for the Electronic Wallet Server. Instructing the deposit of That the deposit balance is not the order if it is less than the settlement price notifies the user terminal,
When the electronic wallet server receives the deposit instruction, the electronic wallet server deposits to secure an amount equivalent to the settlement price from the account of the electronic wallet of the user,
When delivered information is input from the transport company terminal to the transport company server, the delivered information is transmitted from the transport company server to the Laputa Commerce server, and the Laputa Registered with the commerce server,
The Laputa Commerce Server, if there is a notification of a cooling-off application from the user's terminal device, that is, a product error or damage / stain, etc. within the cooling-off period calculated from the delivery date of the product delivery information.・ Notify the server,
If there is no notification of product error or damage / stain from the user terminal within the cooling-off period calculated from the delivery date of the product delivery information, a settlement instruction is issued assuming that a commercial transaction from the ordering to delivery has been established. Notify the wallet server,
When the electronic wallet server receives a payment instruction from the Laputa Commerce server, the electronic wallet server cancels the deposit of the payment for securing the payment capability and pays the shop, that is, an account that is the electronic wallet of the shop An electronic system characterized in that a safe transaction or exchange is established for both a seller and a buyer in an electronic virtual space in which objects of commercial transaction or equivalent exchange cannot be seen from each other by executing the process of transferring to Payment system.

When the Laputa Commerce Server receives a cooling-off application accompanying the return request from the user terminal after receiving the delivery notification of the product, the Laputa Commerce Server will issue a settlement or refund instruction for the order of the product. Whether or not before the cooling-off date,
If the payment or refund instruction has not been issued or is before the cooling-off date, after receiving a new proof of delivery for the goods subject to the return request from the Transport Company Server,
If information indicating that the product delivered and returned is not the same as the product shipped by the shop is received by the cooling-off date, the electronic wallet server is instructed to make a settlement instruction after the cooling-off date has passed. The electronic wallet server cancels the settlement of the payment for the product, and instructs or executes the process of transferring the deposited payment to the electronic wallet account of the shop,
If the Laputa Commerce Server is notified of the information that the returned product is the same as the product shipped by the shop by the cooling-off date, or no communication is received regarding the delivered product. If not, the Laputa Commerce Server notifies the Electronic Wallet Server to return the payment to the user and the Electronic Wallet Server Instructing or executing the process of canceling the deposit and transferring the deposited payment to the user's electronic wallet account;
If the settlement or refund instruction has been issued or is after the cooling-off date, the Laputa Commerce server sends a notification to the user terminal that the return application is invalid, so that the transaction or equivalent exchange 2. The electronic settlement system according to claim 1, wherein a safe transaction, that is, an exchange is established for both a seller and a buyer in an electronic virtual space in which the objects of the object cannot be seen from each other.