JP4300257B2 - 電子決済システム - Google Patents
電子決済システム Download PDFInfo
- Publication number
- JP4300257B2 JP4300257B2 JP01296697A JP1296697A JP4300257B2 JP 4300257 B2 JP4300257 B2 JP 4300257B2 JP 01296697 A JP01296697 A JP 01296697A JP 1296697 A JP1296697 A JP 1296697A JP 4300257 B2 JP4300257 B2 JP 4300257B2
- Authority
- JP
- Japan
- Prior art keywords
- server
- user
- cooling
- product
- laputa
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Landscapes
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、電子決済システムに関し、特に仮想空間領域において、遠隔での商品の発注と、発注商品との決済及び実際に商品を配送をするセキュリテイを確保した電子商取引を構築する電子決済システムに関するものである。
【０００２】
【従来の技術】
従来から流通している、決済システムは、図１５に示すように、ユーザーとＥＣ（Ｅｒｃｔｒｏｎｉｃ Ｃｏｍｍｅｒｃｅ）間において商取引を行うもので、決済時期が３種類に分類される。
【０００３】
第１の分類は、図１５（イ）に示すように、決済時期が配送時の場合であり、ユーザーがＥＣに発注すると、ＥＣ側から、ユーザーに自己配達をし、且つ配送時において代金を回収するシステムである。
【０００４】
第２の分類は、図１５（ロ）に示すように、ユーザー側からＥＣに対して予約をして物品を購入する手法であり、この場合の決済時期は、例えばユーザーが来店した時に決済する。
【０００５】
第３の分類は、図１５（ハ）に示すように、ユーザーからＥＣに発注すると、ＥＣ側から物品が配送され、且つ請求書も発行される。この決済時期は、数ヶ月以内に自動引落し、月次決済、発生時に決済する等がある。
【０００６】
このような３種類に分類される決済システムにおいて商品を購入するためには社会に流通している貨幣又は電子マネーがある。
【０００７】
電子マネーは、クレジットタイプのもの、ネットワークタイプのもの、ネットワークとＩＣカードを組み合わせたもの、ＩＣカードタイプのものがあり、これらは、全て社会に流通している貨幣の代用として使用される。例えば、ＩＣカードでの商品の購入は、所望の商品を特定したときに、ＩＣカードがその代金を支払ったようにして、後日別のルートにより、ＩＣカードで支払った代金の決済を上記決済システムの手法により行う。
【０００８】
このようなＩＣカードの他に、現在のクレジットカードと同様に現金社会の中で使用するＩＣカードによる決済がある。いわゆるモンデックス型といわれるＩＣカードによる決済は、先ず銀行等の金融機関と契約してエレクトロニック・ウオレット・サーバー用口座を開設して入金する。そして、暗証番号及び暗号鍵を内蔵したＩＣカードの発行を受ける。通信回線によりＩＣカードにエレクトロニック・ウオレット・サーバーの預金口座からエレクトロニック・マネー（ＥＭ）を移す。
この移されたＥＭ分だけＩＣカードの利用ができ、従って、予め決められた金額をＩＣカードで使用することができるようになっている。
【０００９】
又、このような電子マネーを利用した商取引においては、セキュリテイを確保することが重要であり、そのためには、（１）ＩＤ＋パスワード、（２）通信暗号化システム（例えばセキュリテイカードを使用する）、（３）電子署名システム、（４）業務フロー全体が１つのセキュリテイ機構を形成するようにする等により安全性を図っている。
【００１０】
【発明が解決しようとする課題】
しかしながら、上記従来技術で説明した商取引において使用される電子マネーは、即ち、クレジットカードとの提携型であるいわばカード会社による仮想空間における決済システムであり、商品を配送及び管理等するトランスポート・カンパニー・サーバーや、複数の商品を手配したり管理するサイバー・ショップ・サーバー等を含め、且つ相互に承認及び保証すると云うシステムにはなっていないため、仮想空間における商取引で重要な根幹をなす商品の存在の証明及び決済金額の証明ができないと云う問題点がある。
【００１１】
従って、仮想都市を構築した場合における電子商取引において、少なくとも商品の存在の証明及び決済金額の存在を証明できるシステムに解決しなければならない課題を有している。
【００１２】
【課題を解決するための手段】
上記課題を解決するために、本発明に係る電子決済システムは、商品の発注及び購入を端末機器を介して行うユーザーと、該ユーザーに前記商品の購入決済金があることを証明及び保証するために行われる預託行為を含む金銭出納管理をする単独又は複数のエレクトロニック・ウオレット・サーバーと、前記ユーザーが購入する前記商品を取り揃え且つ単独若しくは複数の商品仕入先との受発注管理を行う複数のサイバー・ショップ・サーバーと、前記ユーザーが選択した商品の自動的な配送及び集荷の情報を収集し、且つ該商品の集荷・配送及び管理を行い、配送が完了したことを証明する単独又は複数のトランスポート・カンパニー・サーバーと、前記ユーザーとエレクトロニック・ウオレット・サーバーとサイバー・ショップ・サーバーとトランスポート・カンパニー・サーバーとのそれぞれと個別に通信回線を介して接続し、該接続された全体を組織的に統合すると共に取引履歴をデータベース上に記録・保管し、且つクーリングオフシステムにより予め設定されているクーリングオフ期間に基づいて最終的な商品の存在を証明するラピュタ・コマース・サーバーとから構成され、前記ラピュタ・コマース・サーバーに接続されたそれぞれのユーザーとエレクトロニック・ウオレット・サーバーとサイバー・ショップ・サーバーとトランスポート・カンパニー・サーバーとの相互間の通報、証明、保証を前記ラピュタ・コマース・サーバーを介して行い、且つ前記商品のキャンセル処理及び前記クーリングオフ期間に基づく処理を電子仮想空間上において普遍的にルール化して行うようにしたことである。
【００１３】
このように構成した電子決済システムは、通信回線を介した商取引において事前にユーザー側の資金と商品を販売するメーカー側の商品在庫を電子的に照合することができ、且つユーザーの資金は預託によりエレクトロニック・ウオレット・サーバーが保証し、商品はサイバー・ショップ・サーバーが保証し且つ商品の配達はトランスポート・カンパニー・サーバーが保証することができ、時空を超えた電子仮想空間における商取引の安全性を確保することができ、具体的にはインターネットに代表される電子仮想空間上の電子商取引に関する受注発注管理、物流管理、預託決済管理に基づいて商品とその決済代金の存在を保証する商取引のシステムを構築することができる。
【００１４】
【発明の実施の形態】
次に、本発明に係る電子決済システムについて図面を参照にして説明する。
【００１５】
本発明に係る電子決済システムは、図１に示すように、商品の発注及び購入を端末機器を介して行うユーザー（Ｕｓｅｒ；ＵＲ）と、このユーザーＵＲに商品の購入決済金があることを証明及び保証するために行われる預託行為を含む金銭出納管理をする単独又は複数のエレクトロニック・ウオレット・サーバー（Ｅｌｅｃｔｒｏｎｉｃ Ｗａｌｌｅｔ Ｓｅｒｖｅｒ；ＥＷＳ）と、ユーザーＵＲが購入する商品をこのシステム上で取り揃えて販売し、そのための単独若しくは複数の商品仕入先との受発注管理を行う複数のサイバー・ショップ・サーバー（Ｃｙｂｅｒ Ｓｈｏｐ Ｓｅｒｖｅｒ；ＣＳＳ）と、ユーザーＵＲが選択した商品を本システム上から自動的に配送及び集荷の情報を収集し、この商品の集荷・配送及び管理を行い、配送が完了したことを証明する、即ち、商品の存在を証明するための単独又は複数のトランスポート・カンパニー・サーバー（Ｔｒａｎｓｐｏｒｔ Ｃｏｍｐａｎｙ Ｓｅｒｖｅｒ；ＴＣＳ）と、ユーザーＵＲとエレクトロニック・ウオレット・サーバーＥＷＳとサイバー・ショップ・サーバーＣＳＳとトランスポート・カンパニー・サーバーＴＣＳとのそれぞれと個別に専用若しくは公衆の通信回線を介して接続し、この接続された全体を組織的に統合すると共に取引履歴をデータベース（Ｄａｔａ Ｂａｓｅ；ＤＢ）上に記録・保管し、且つクーリングオフシステムにより予め設定されているクーリングオフ期間をカウントダウンすることによって最終的な商品の存在を証明するラピュタ・コマース・サーバー（Ｌａｐｕｔａ Ｃｏｍｍｅｒｃｅ Ｓｅｒｖｅｒ；ＬＣＳ）とから構成されている。
【００１６】
エレクトロニック・ウオレット・サーバーＥＷＳは、イーサネットを介して金融機関のバンクサーバーと接続してイントラネットを形成し、イントラネットを形成したエレクトロニック・ウオレット・サーバーＥＷＳは、インターネットを介してラピュタ・コマース・サーバーＬＣＳにイーサネットで接続しているエレクトロニック・ウオレット・デュプリカント・サーバー（ＥｌｅｃｔｒｏｎｉｃＷａｌｌｅｔ Ｄｕｐｌｉｃａｎｔ Ｓｅｒｖｅｒ；ＥＷＤＳ）に接続されている。このようにエレクトロニック・ウオレット・デュプリカント・サーバーＥＷＤＳを介してエレクトロニック・ウオレット・サーバーＥＷＳとラピュタ・コマース・サーバーＬＣＳとを接続したのは、ＣＧＩやＳＳＩを用いたシステムの場合、直接に相手方に書き込むシステムに比べ、リクエスト及び回答で二重にトランザクションが発生する為トラフイックが倍の密度になってしまい、更に、デーモンプログラムによる処理は頻繁なアクセスが発生する為、トラフイックに多大な負荷を与えてしまう。このようにただでさえトラフイックが過密なため、通信時間のかかりすぎやデータの紛失当の問題が発生してしまう。そのため、エレクトロニック・ウオレット・デュプリカント・サーバーＥＷＤＳを設置してイーサネットによって対応して、通信時間のかかりすぎやデータの紛失等の問題を解決している。
【００１７】
サイバー・ショップ・サーバーＣＳＳは、複数のホールセラー（Ｗｈｏｌｅｓａｌｅｒ；ＷＳ）と複数のファクトリ（Ｆａｃｔｏｒｙ；ＦＣ）とでイントラネットを構築してＣＡＬＳを形成し、且つサイバーショップサーバーＣＳＳは、インターネットを介してラピュタ・コマース・サーバーＬＣＳのサイバー・ショップ・デュプリカント・サーバー（Ｃｙｂｅｒ Ｓｈｏｐ Ｄｕｐｌｉｃａｎｔ Ｓｅｒｖｅｒ；ＣＳＤＰ）に接続された構成となっている。このサイバー・ショップ・デュプリカント・サーバーＣＳＤＰを介してラピュタ・コマース・サーバーＬＣＳに接続するようにしたのは、上述したエレクトロニック・ウオレット・デュプリカント・サーバーＥＷＤＳと同様の理由によるものであり、ＣＧＩやＳＳＩを用いたシステムの場合、リクエスト及び回答で二重にトランザクションが発生する為トラフイックが倍の密度になってしまうこと、及びデーモンプログラムによる処理は頻繁なアクセスが発生する為、トラフイックに多大な負荷を与えてしまい、トラフイックが過密になり、通信時間のかかりすぎやデータの紛失当の問題が発生してしまうため、サイバー・ショップ・デュプリカント・サーバーＣＳＤＰを設置してイーサネットによって対応し、通信時間のかかりすぎやデータの紛失等の問題を解決しているのである。
【００１８】
トランスポート・カンパニー・サーバーＴＣＳは、複数のブランチ（Ｂｒａｎｃｈ；ＢＲ）とからイントラネットを構築してＣＡＬＳを形成し、且つトランスポート・カンパニー・サーバーＴＣＳはインターネットを介してラピュタ・コマース・サーバーＬＣＳのトランスポート・カンパニー・デュプリカント・サーバー（Ｔｒａｎｓｐｏｒｔ Ｃｏｍｐａｎｙ Ｄｕｐｌｉｃａｎｔ Ｓｅｒｖｅｒ；ＴＣＤＰ）に接続された構成となっている。このトランスポート・カンパニー・デュプリカント・サーバーＴＣＤＰを介してラピュタ・コマース・サーバーＬＣＳに接続するようにしたのは、上述したエレクトロニック・ウオレット・デュプリカント・サーバーＥＷＤＳと同様の理由によるものであり、ＣＧＩやＳＳＩを用いたシステムの場合、リクエスト及び回答で二重にトランザクションが発生する為トラフイックが倍の密度になってしまうこと、及びデーモンプログラムによる処理は頻繁なアクセスが発生する為、トラフイックに多大な負荷を与えてしまい、トラフイックが過密になり、通信時間のかかりすぎやデータの紛失等の問題が発生してしまうため、トランスポート・カンパニー・デュプリカント・サーバーＴＣＤＰを設置してイーサネットによって対応し、通信時間のかかりすぎやデータの紛失等の問題を解決しているのである。
【００１９】
ラピュタ・コマース・サーバーＬＣＳは、サイバー・ショップ・サーバーＣＳＳとインターネットを介して接続するサイバー・ショップ・デュプリカント・サーバーＳＳＤＳと、エレクトロニック・ウオレット・サーバーＥＷＳとインターネットを介して接続するエレクトロニック・ウオレット・デュプリカント・サーバーＥＷＤＳと、トランスポート・カンパニー・サーバーＴＣＳとインターネットを介して接続するトランスポート・カンパニー・デュプリカント・サーバーＴＣＤＳとを備え、且つこれらのそれぞれはイーサネットを介してラピュタ・コマース・サーバーＬＣＳに接続されている。又、ラピュタ・コマース・サーバーＬＣＳは、複数のユーザーＵＲとインターネットを介して接続されている。
【００２０】
このような接続状態で構成した電子決済システムは、ラピュタ・コマース・サーバーＬＣＳに接続されたそれぞれのユーザーＵＲとエレクトロニック・ウオレット・サーバーＥＷＳとサイバー・ショップ・サーバーＣＳＳとトランスポート・カンパニー・サーバーＴＣＳとの相互間の通報、証明、保証をラピュタ・コマース・サーバーＬＣＳを介して行い、且つ各構成要素に跨ぐ商品のキャンセル処理及びクーリングオフ期間に基づく処理を電子仮想空間上において普遍的にルール化して整備することができ、これは時空を超えた電子仮想空間における商取引の安全性を確保した、いわゆるインターネットに代表される電子仮想空間上の電子商取引に関する受発注管理・物流管理・預託決済管理に基づいて商品とその決済代金の存在を保証するシステムを実現できるのである。
【００２１】
そして、上記構成にした電子決済システムにおいては、納期の通知による商品存在の証明と預託による決済金額の存在を保証することによる預託システムによる契約の成立と、消費者の保護及び最終的な商品の存在を証明するクーリングオフシステムの導入と、パスワードの盗難に対するセキュリテイとして預託通報システムの導入と、消費者保護と商品返品に対するセキュリテイを確保するクーリングオフ警報システムの導入と、サイバー・ショップ・サーバー側の商品を販売する販売者を保護する検品処理システムの導入と、システム全体のセキュリテイを図るために通知と云う概念を導入した通知システムが構築されている。
【００２２】
即ち、エレクトロニック・ウオレット・サーバーＥＷＳとサイバー・ショップ・サーバーＣＳＳとトランスポート・カンパニー・サーバーＴＣＳとラピュタ・コマース・サーバーＬＣＳ間のデータの送受信は、ＣＧＩ又はＳＳＩ若しくはこれらと同等の機能を有するシステムによって所定の相手サーバーにリクエストすることにより、相互に相手のデータベースＤＢを検索し、読み込むことによって行い、直接に相手のデータベースＤＢへの書き込みを行わないことによって、データの改ざんを行えないようにした構成となっている。
【００２３】
そして、ユーザーＵＲからラピュタ・コマース・サーバーＬＣＳ間のデータの送受信は、ＣＧＩ（Ｃｏｍｍｏ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃ）又はＳＳＩ（Ｓｅｒｖｅｒ Ｓｉｄｅ Ｉｎｃｌｕｄｅ）若しくはそれと同等又はそれ以上の機能を有するシステムによって、ユーザーＵＲからのリクエストのみとし、ユーザーＵＲからラピュタ・コマース・サーバーＬＣＳへの直接の書き込みをなくすことによって、データの改ざんを行えないようにした構成となっている。
【００２４】
また、ユーザーＵＲ又はサイバー・ショップ・サーバーＣＳＳ又はトランスポート・カンパニー・サーバーＴＣＳ又はエレクトロニック・ウオレット・サーバーＥＷＳの情報は、ラピュタ・コマース・サーバーＬＣＳがタイマー動作プログラム又は常時動作プログラムによって自動的にユーザーＵＲとサイバー・ショップ・サーバーＣＳＳとトランスポート・カンパニー・サーバーＴＣＳとエレクトロニック・ウオレット・サーバーＥＷＳとのそれぞれにリクエストを発行し、このユーザーＵＲとサイバー・ショップ・サーバーＣＳＳとトランスポート・カンパニー・サーバーＴＣＳとエレクトロニック・ウオレット・サーバーＥＷＳとのそれぞれがＣＧＩ又はＳＳＩを生成してラピュタ・コマース・サーバーＬＣＳに回答するようにして情報の授受を行うような構成となっている。
【００２５】
図２は、預託と契約の成立、即ち、納期の通知による商品存在の証明と預託による決済金額の存在保証による契約の成立を示した、いわゆる預託システムを示したブロックフロー図である。
【００２６】
先ず、ユーザーＵＲがラピュタホームページの注文書の書式を利用してラピュタ・コマース・サーバーＬＣＳのデータベースＤＢに、納品先、登録納期、品番、品名、数量、単価、金額等からなる注文内容を登録する（ＳＴ１００）。
【００２７】
サイバー・ショップ・サーバーＣＳＳに常駐し任意に定められた時間毎に検索を行いにいく機能を有するクーロン（ＣＲＯＮ）プログラムが、ラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索し、フラグの立っていない注文書若しくは「残高不足解消フラグ」、「再送請求フラグ」の立っている注文書を抽出する（ＳＴ１０１）。
【００２８】
サイバー・ショップ・サーバーＣＳＳのＣＡＬＳ（Ｃｏｎｔｉｎｕｅ Ａｃｑｕｉｓｉｔｉｏｎ ａｎｄ Ｌｉｆｅーｃｙｃｌｅ Ｓｕｐｐｏｒｔ）がデータベースＤＢを検索して注文書の商品のそれぞれの納期を算定する（ＳＴ１０２）。
【００２９】
サイバー・ショップ・サーバーＣＳＳが納期データをサイバー・ショップ・サーバーＣＳＳのＣＡＬＳから受け取りデータベースＤＢに登録する（ＳＴ１０３）。
【００３０】
ラピュタ・コマース・サーバーＬＣＳにおいて、常時アンダーグランドで動作しており、イベントが発生した時に即座に対応する機能を有するデーモン（ＤＡＥＭＯＮ）プログラムがサイバー・ショップ・サーバーＣＳＳの納期データを検索してデータベースＤＢに登録する（ＳＴ１０４）。
【００３１】
ユーザＵＲは、端末上で任意に定められた時間毎に動作するＨＴＭＬ（ハイパーテキストマークアップランゲージ）のプログラムであるメタタグプログラムにより、ラピュタホームページにおいて、ラピュタ・コマース・サーバーＬＣＳのデータベースＤＢの納期データを検索して読み込む（ＳＴ１０５）。
【００３２】
納期通知が存在していれば、納期通知インジケータが点滅し、納期通知画面が表示される（ＳＴ１０６）。入荷の見込みがなくまた在庫がない場合には、在庫無しのインジケータが点滅し、通知画面に表示される（ＳＴ１０７）。
【００３３】
納期が了承されると、納期了承ボタンをクリックし（ＳＴ１０８）、ラピュタ・コマース・サーバーＬＣＳのＨＴＴＰに納期了承をリクエストし（ＳＴ１０９）、ＣＧＩプログラム、即ち、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）のプログラムであって、外部からのリクエストを受けて動作し、且つリクエストの結果をリクエストの発信者に返答する機能を有する、このＣＧＩプログラムがラピュタ・コマース・サーバーＬＣＳのデータベースＤＢに契約成立のフラグを立てる（ＳＴ１１０）。
【００３４】
納期がキャンセルの場合は、キャンセルボタンをクリックする（ＳＴ１１１）。そうすると、ラピュタ・コマース・サーバーＬＣＳのＨＴＴＰにキャンセル処理をリクエストし、ラピュタ・コマース・サーバーＬＣＳのデータベースＤＢの注文書用の仮ファイルを削除し、データベースＤＢにキャンセルを登録する（ＳＴ１１２、ＳＴ１１３）。
【００３５】
このようにして商品の納期及び商品の存在の証明は、ユーザーＵＲが、ラピュタ・コマース・サーバーＬＣＳを介して行うサイバー・ショップ・サーバーＣＳＳに対する商品の発注は、サイバー・ショップ・サーバーＣＳＳ内においてラピュタ・コマース・サーバーＬＣＳがユーザーＵＲからの商品発注を受けたことを検知するようにし、この商品発注を検知した時にサイバー・ショップ・サーバーＣＳＳのデータベースＤＢ又はサイバー・ショップ・サーバーＣＳＳ内のクライアントに対してユーザーＵＲが発注した商品の在庫検索を実施して、当該商品の単純納期を算出することができる。
【００３６】
そして、この単純納期は、ユーザーＵＲの指定する配達地による配送必要日数と合わせることにより、ユーザーＵＲの指定する配達地までの最終納期を算定し、ラピュタ・コマース・サーバーＬＣＳを通じて商品の最終納期をユーザーＵＲに送り返すことによって商品の存在を証明することができるのである。
【００３７】
一方、ステップＳＴ１００において、注文書の注文内容が登録されると、エレクトロニック・ウオレット・サーバーＥＷＳがデーモンプログラムによりラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索し、何もフラグが立てられていない注文書若しくは「残高不足フラグ」「再送請求フラグ」の立てられた注文書を抽出する。そして登録済みのユーザーＵＲのエレクトロニック・ウオレット・サーバーＥＷＳでの残高と購入金額とを比較して「購入可否」をデータベースＤＢに登録する（ＳＴ１１４）。
【００３８】
ラピュタ・コマース・サーバーＬＣＳのデーモンプログラムがエレクトロニック・ウオレット・サーバーＥＷＳのデータベースＤＢを検索し、「購入可否」についての新規データを抽出し、データベースＤＢに「購入可否」のフラグを立てる（ＳＴ１１５）。
【００３９】
購入可であれば購入可能フラグを立て、購入否であれば購入不可フラグを立て、Ｅーｍａｉｌで通知する（ＳＴ１１６、ＳＴ１１７）。
【００４０】
又、ラピュタホームページのメタタグプログラムが残高不足フラグを検索し、あれば入金、キャンセルの入力の書式を表示し、ラピュタホームページのメタタグプログラムが「残高不足フラグ」を検索し、あれば残高不足のインジケータを点滅させる（ＳＴ１１８、ＳＴ１１９）。
【００４１】
もし入金処理がされると再度ステップＳＴ１０１及びＳＴ１１４から実行され、キャンセル処理の場合はキャンセルが選択される（ＳＴ１２０）。
【００４２】
ラピュタ・コマース・サーバーＬＣＳのデーモンプログラムが注文書用仮ファイルを削除し、データベースＤＢにキャンセルフラグを立て、エレクトロニック・ウオレット・サーバーＥＷＳのデーモンプログラムがラピュタ・コマース・サーバーＬＣＳを検索してキャンセルフラグを見つけると、この注文コードに基づくデータをデータベースＤＢから削除する（ＳＴ１２１、ＳＴ１２２）。
【００４３】
このようにして商品の存在を証明することと並行して、エレクトロニック・ウオレット・サーバーＥＷＳは、ユーザーＵＲの商品発注を検知し、この発注した商品の決済金額に対するエレクトロニック・ウオレット・サーバーＥＷＳ内のユーザーＵＲの預金残高の大小を検索し、この検索結果をラピュタ・コマース・サーバーＬＣＳを介してユーザーＵＲ及びサイバー・ショップ・サーバーＣＳＳに通知することによって決済金額の存在を保証することができる。
【００４４】
又、この商品の存在がサイバー・ショップ・サーバーＣＳＳによって証明され、且つ預金残高が決済預金残高より大きいか又は同等であることがエレクトロニック・ウオレット・サーバーＥＷＳによって証明され、ユーザーＵＲが最終納期を了承することをラピュタ・コマース・サーバーＬＣＳに通知した場合には、エレクトロニック・ウオレット・サーバーＥＷＳは、預金残高から決済金額相当分を預託することによって決済金額の存在を保証するようにすることができ、この保証により商品発注は成立したものとみなすことができるのである。
【００４５】
また、ユーザーＵＲから発注した商品がない場合、又はユーザーＵＲが最終納期を不満とした場合において、ラピュタ・コマース・サーバーＬＣＳを介して行われるエレクトロニック・ウオレット・サーバーＥＷＳからの預金残高通知に対してユーザーＵＲが商品発注をキャンセルした場合は、商品発注は成立しないものとすることができる。
【００４６】
預金残高が決済金額より少ない場合で且つユーザーＵＲがラピュタ・コマース・サーバーＬＣＳを介してエレクトロニック・ウオレット・サーバーＥＷＳから残高不足の通知を受けた場合において、ユーザーＵＲが入金処理を行うまでの間は、商品発注を一時保留の状態にする。
【００４７】
このようにして決済金額の存在が証明されたことを示す購入可能フラグが立ち、且つ商品の存在が証明されたことを示す契約成立のフラグが立つとラピュタ・コマース・サーバーＬＣＳのデーモンプログラムがデータベースＤＢに「預託フラグ」を立て、預託通報システムに行く（ＳＴ１１４、ＳＴ１１５）。
【００４８】
図３は、ユーザーのパスワードの盗難等に対するセキュリテイを図るための預託通報システムを示したブロックフロー図である。
【００４９】
預託通報システムは、商品を購入しようとする者と真実のユーザーとの一致を図るためのシステムであり、商品を購入すると、購入をしたパスワードを有するユーザーにフィードバックをかけてセキュリテイを図るように構成されている。
【００５０】
図３はそのブロックフロー図であり、先ず図２を参照にして説明した預託システムにおいてラピュタ・コマース・サーバーＬＣＳのデーモンプログラムがデータベースＤＢに預託フラグが立っていることが前提となる（ＳＴ１１６）。
【００５１】
ユーザーＵＲのラピュタホームページのメタタグプログラムがラピュタ・コマース・サーバーＬＣＳのＨＴＴＰに対して、ユーザーディレクトリーの仮ファイルの中の預託フラグの有無をリクエストする（ＳＴ１１７）。
【００５２】
預託フラグが立っている場合は、ユーザーＵＲの預託インジケータが点滅し、預託フラグがない場合には、何もしない（ＳＴ１１８、ＳＴ１１９）。
【００５３】
ここでユーザーＵＲは了解かキャンセルを入力することができる。
【００５４】
ユーザーＵＲがキャンセルを入力すると、、預託フラグが削除され、ユーザーディレクトリーの仮ファイルを削除するようにラピュタ・コマース・サーバーＬＣＳにリクエストをする（ＳＴ１２０、ＳＴ１２１）。
【００５５】
ラピュタ・コマース・サーバーＬＣＳはこのリクエストを受けると、データベースＤＢの預託フラグを削除し、且つユーザーディレクトリーの仮ファイルも削除する（ＳＴ１２２）。
【００５６】
預託フラグが削除されると預託オンジケータの点滅は終了する（ＳＴ１２３）。
【００５７】
一方ユーザが了解の入力を行うと、ラピュタ・コマース・サーバーＬＣＳに預託承認フラグのリクエストを行う（ＳＴ１２４、ＳＴ１２５）。
【００５８】
ラピュタ・コマース・サーバーＬＣＳのＨＴＴＰが預託承認ＣＧＩを作成し、ユーザーディレクトリーの仮ファイル及びデータベースＤＢに預託承認を登録する（ＳＴ１２６）。
【００５９】
エレクトロニック・ウオレット・サーバーＥＷＳは、ラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索し、預託承認フラグがあれば、自分のデータベースＤＢに預託フラグを立てる（ＳＴ１２７）。
【００６０】
バンクサーバーは、エレクトロニック・ウオレット・サーバーＥＷＳのデータベースＤＢを検索し、預託承認フラグがあれば、預託処理を実行する（ＳＴ１２８）。
【００６１】
このようにして、ユーザーＵＲが商品の納期を承認し、且つエレクトロニック・ウオレット・サーバーＥＷＳによる決済金額の存在が証明された時に、ラピュタ・コマース・サーバーＬＣＳにおいて預託フラグを立て、ユーザーＵＲがこの預託フラグが立っていることを検出すると、預託フラグが立っていることをユーザーＵＲがビジュアルで確認できるようにして、真実のユーザーが商品を購入したかどうかを視認により判別できる。
【００６２】
又、了解又はキャンセルの入力で対応できるようにして、ユーザーＵＲが、了解を入力すると、エレクトロニック・ウオレット・サーバーＥＷＳはこの了解した預託フラグを検出して預託金額と前記商品の決済金額との決済処理を行うようにして、金銭面でのセキュリテイを図ることができるのである。
【００６３】
また、ユーザーＵＲが、キャンセルを入力すると、これは真実のユーザーＵＲの商品の購入ではないと判断して、ラピュタ・コマース・サーバーＬＣＳは、このキャンセルした預託フラグを検出して当該商取引のデータフィールドの削除を行う。
【００６４】
図４〜図６は消費者を保護するためのキャンセルシステムを示したものである。
【００６５】
消費者を保護するためのキャンセルシステム、即ち、ユーザーが行った商品発注に対するキャンセル処理は、ラピュタ・コマース・サーバーＬＣＳが記録媒体、例えばデータベース上に商取引についてのデータフィールドをまだ作成していない商品発注時点から納期承認前までと、ラピュタ・コマース・サーバーが記録媒体上に商取引についてのデータフィールドを作成した納期承認時点から配達証明発行前までの２つの段階の時期においてのみ有効となっている。
【００６６】
データフィールドを作成していない場合とは、ラピュタ・コマース・サーバーＬＣＳがデータフィールドの作成を実行しないで終了したことを意味し、データフィールドを作成している場合とは、ラピュタ・コマース・サーバーＬＣＳは、このデータフィールドの削除を行う。
【００６７】
図４は、ユーザーＵＲが商品を納期了承してから配達までのキャンセル処理を示したブロックフロー図である。
【００６８】
先ず、ユーザーＵＲがキャンセル書式を用いてキャンセルを入力・送信すると、ラピュタ・コマース・サーバーＬＣＳのＣＧＩが仮ファイル及びデータベースＤＢにキャンセルフラグを立てる（ＳＴ１３０、ＳＴ１３１）。
【００６９】
エレクトロニック・ウオレット・サーバーＥＷＳのデーモンプログラがラピュタ・コマース・サーバーＬＣＳのユーザーディレクトリーを検索して、キャンセルフラグがあれば自分のデータベースＤＢにキャンセルフラグを立てる（ＳＴ１３２）。
【００７０】
トランスポート・カンパニー・サーバーＴＣＳのデーモンプログラムがラピュタ・コマース・サーバーＬＣＳのユーザーディレクトリーを検索してキャンセルフラグがあれば、自分のデータベースＤＢにキャンセルフラグを立てる（ＳＴ１３３）。
【００７１】
サイバー・ショップ・サーバーＣＳＳのデーモンプログラムが、ラピュタ・コマース・サーバーＬＣＳのユーザーディレクトリーを検索して、キャンセルフラグがあれば、自分のデータベースＤＢにキャンセルフラグを立てる（ＳＴ１３４）。
【００７２】
このようにしてそれぞれのサーバーＥＷＳ、ＴＣＳ、ＣＳＳにおいてキャンセルフラグの処理がなされ、ラピュタ・コマース・サーバーＬＣＳのデーモンプログラムが各サーバーのデータベースを検索してキャンセルフラグがあれば、ユーザーディレクトリーの仮ファイルを削除し、データベースＤＢにキャンセルを登録する（ＳＴ１３５）。
【００７３】
従って、サイバー・ショップ・サーバーＣＳＳは、ユーザーＵＲの商品発注に対するキャンセル処理を、ラピュタ・コマース・サーバーＬＣＳにおけるデータフィールドの喪失と自己のデータベースにおけるデータフィールドの存在とで検知するようにし、この検知した後においては更に出荷前と出荷後の２段階に分けてキャンセル処理を行うようにして消費者を保護するようにしてある。
【００７４】
図５は、キャンセル処理によるサイバー・ショップ・サーバーＣＳＳの対応を示したブロックフロー図である。
【００７５】
サイバー・ショップ・サーバーＣＳＳのデーモンプログラムが、ラピュタ・コマース・サーバーＬＣＳのユーザーディレクトリーを検索して、キャンセルフラグがあれば、自分のデータベースＤＢにキャンセルフラグを立てる（ＳＴ１３６）。
【００７６】
出荷前であれば、自分のデータベースに出庫データがなければ、データベースＤＢの当該データを削除する（ＳＴ１３７）。
【００７７】
そしてサイバー・ショップ・サーバーＣＳＳのＣＡＬＳの在庫データベースにキャンセル在庫として登録する（ＳＴ１３８）。
【００７８】
出荷後であれば、自分のデータベースＤＢに、当該データについての出庫データがあれば、ラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索し、当該データについての返品配送完了フラグがあれば、自己のデータベースＤＢの当該データ全てを削除する（ＳＴ１３９）。
【００７９】
キャンセルフラグがあれば、自分のデータベースの当該取引に関するファイルを削除し、なければなにもしない（ＳＴ１４０、ＳＴ１４１）。
【００８０】
さらに、トランスポート・カンパニー・サーバーＴＣＳにおいては、このキャンセル処理のデータを取得した後において、出荷前と出荷後と配送中の３段階に分けてキャンセル処理を行うようにして、消費者の保護を図った構成となっている。
【００８１】
図６は、キャンセル処理におけるトランスポート・カンパニー・サーバーＴＣＳの対応を示したブロックフロー図である。
【００８２】
トランスポート・カンパニー・サーバーＴＣＳのデーモンプログラムがラピュタ・コマース・サーバーＬＣＳのユーザーディレクトリーを検索して、キャンセルフラグがあれば自分のデータベースＤＢにキャンセルフラグを立てる（ＳＴ１４２）。
【００８３】
集荷前であれば、データベースＤＢに集荷済フラグがなければ、デーモンプログラムが６時間後に自分のデータベースＤＢの当該集荷データを削除する（ＳＴ１４３）。
【００８４】
集荷後であれば、データベースＤＢに集荷フラグが有り、且つ出荷フラグがなければ、返品配送フラグを立てる（ＳＴ１４４）。
【００８５】
そして、返品配達済みを入力し、データベースＤＢに返品配送済フラグを立てる（ＳＴ１４５）。
【００８６】
ラピュタ・コマース・サーバーＬＣＳのデーモンプログラムがトランスポート・カンパニー・サーバーＴＣＳのデータベースＤＢを検索し、返品配達済フラグが有れば、データベースＤＢに返品配達済フラグを立てる（ＳＴ１４６）。
【００８７】
エレクトロニック・ウオレット・サーバーＥＷＳのデーモンプログラムがラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索して、返品配達済フラグがあれば、預託解除フラグを立てる（ＳＴ１４７）。
【００８８】
ラピュタ・コマース・サーバーＬＣＳのデーモンプログラムがエレクトロニック・ウオレット・サーバーＥＷＳのデータベースＤＢを検索して預託解除フラグがあれば、当該データの仮ファイルを削除し、データベースＤＢにキャンセルを登録する（ＳＴ１４８）。
【００８９】
又、バンクサーバーのデーモンプログラムがエレクトロニック・ウオレット・サーバーＥＷＳのデータベースＤＢを検索して預託解除フラグがあれば、当該データの預託を解除する（ＳＴ１４９）。
【００９０】
そして、エレクトロニック・ウオレット・サーバーＥＷＳがバンクサーバーのデータベースＤＢを検索して、預託解除フラグデータの預託が解除されていれば、自己のデータベースＤＢの当該データを削除する（ＳＴ１５０）。
【００９１】
図７〜図１３はクーリングオフシステムを示したブロックフロー図である。
【００９２】
クーリングオフシステムは、法で定められた最低のクーリングオフ期間を持つ通販問題対策に設けられた消費者保護と最終的な商品の存在を証明するためのシステム、即ち、通販等により消費者が商品を直接確認することなく購入した場合、その商品が消費者のイメージと異っていたり、破損・汚損があった場合にはクーリングオフ期間内であれば無条件に返品できるシステムであり、本発明においてはこの返品することを拡張して独自の期間設定を行なうと同時に最終的な商品の存在の証明にも援用している。
【００９３】
即ち、クーリングオフシステムはトランスポート・カンパニー・サーバーＴＣＳによるユーザーＵＲへの商品の配達証明発行後から、各商品固有の性能・性質に基づいて設定されているガイドラインに従って、サイバー・ショップ・サーバーを提供・維持・管理する企業又は個人が各商品固有の性能・性質に基づいて設定されているクーリングオフ期間の終了まで機能するようにしたことである。
【００９４】
このクーリングオフシステムは、ユーザーＵＲが商品の返品の際に行うクーリングオフ申請によるキャンセル処理手段と、ユーザーＵＲからの再送依頼により商品の再送を行う再送請求処理手段と、クーリングオフ期間外処理手段と、トランスポート・カンパニー・サーバーＴＣＳにおける配達終了に基づくクーリングオフ解除期日算定手段と、トランスポート・カンパニー・サーバーＴＣＳにおける商品の配達終了期間に基づくクーリングオフ警報手段と、ユーザーからのクーリングオフの中止を処理するクーリングオフ中止手段と、クーリングオフ期間に基づいて前記ユーザーの手元に届いた商品の返品処理を行うクーリングオフの検品処理手段とから構成されている。
【００９５】
クーリングオフシステムにおけるクーリングオフ期間の終了が、商品が前記ユーザーの発注商品と同一であることをユーザー本人が確認したものとみなして、最終的な商品の存在の証明が行われたものとするようにしてある。
【００９６】
図７は、ユーザーＵＲが商品の返品の際に行うクーリングオフ申請によるキャンセル処理手段を示したブロックフロー図である。
【００９７】
先ず、ユーザＵＲがラピュタホームページのクーリングオフ書式により、商品を返品したい旨、即ちクーリングオフ申請をラピュタ・コマース・サーバーＬＣＳにリクエストすると、ラピュタ・コマース・サーバーＬＣＳのＣＧＩが注文書仮ファイルをユーザーディレクトリー及びデータベースＤＢに登録する（ＳＴ１５１）。
【００９８】
ラピュタ・コマース・サーバーＬＣＳのデーモンプログラムは、クーリングオフ申請がクーリングオフ期間内か否かのチエックをする（ＳＴ１５２）。
【００９９】
期間外であればクーリングオフ期間外処理ルーチン（クーリングオフ期間外処理手段）に行き、クーリングオフ期間内であれば、デーモンプログラムがクーリングオフのフラグを仮ファイルとデータベースＤＢに立てる（ＳＴ１５３、ＳＴ１５４）。
【０１００】
クーリングオフのフラグが立つと、さまざまなサーバーが動き出す。先ず、エレクトロニック・ウオレット・サーバーＥＷＳのクーロンプログラムがラピュタ・コマース・サーバーＬＣＳのクーリングオフフラグを抽出し、自分のデータベースＤＢにクーリングオフフラグを立てる（ＳＴ１５５）。
【０１０１】
サイバー・ショップ・サーバーＣＳＳのクーロンンプログラムがラピュタ・コマース・サーバーＬＣＳのクーリングオフフラグを抽出し、自分のデータベースＤＢにクーリングオフフラグを立てる（ＳＴ１５６）。
【０１０２】
トランスポート・カンパニー・サーバーＴＣＳのクーロンプログラムがラピュタ・コマース・サーバーＬＣＳのクーリングオフフラグを抽出し、自分のデータベースＤＢにクーリングオフフラグを立てる（ＳＴ１５７）。
【０１０３】
そして、トランスポート・カンパニー・サーバーＴＣＳの端末のプラウザにクーリングオフフラグが立てられたデータを表示する（ＳＴ１５８）。
【０１０４】
このような作業（ＳＴ１５５〜ＳＴ１５８）を終了後、ラピュタ・コマース・サーバーＬＣＳのクーロンプログラムが「クーリングオフ解除期日」に達した注文ファイルをピックアップし、クーリングオフフラグを削除し、解除する（ＳＴ１５９）。
【０１０５】
また、エレクトロニック・ウオレット・サーバーＥＷＳのクーロンプログラムが新しい「クーリングオフ解除期日データ」を検索し、自分のデータベースＤＢに期日を登録する（ＳＴ１６０）。
【０１０６】
エレクトロニック・ウオレット・サーバーＥＷＳのクーロンプログラムがラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索して、クーリングオフの解除を検知すると、自分のデータベースＤＢ内の「クーリングオフ期日」のデータと照合し、「期日データ」以降の日付ならば「預託解除・決済フラグ」を立てる（ＳＴ１６１）。
【０１０７】
ステップＳＴ１５７において、トランスポート・カンパニー・サーバーＴＣＳがクーリングオフのフラグを立てると、運送会社がデータベースに返品配達の完了を登録し、運送会社の集荷・配送システムにデータを渡す（ＳＴ１６２、ＳＴ１６３）。
【０１０８】
そして、ラピュタ・コマース・サーバーＬＣＳのクーロンプログラムがトランスポート・カンパニー・サーバーＴＣＳのデーターベースＤＢを検索して、「返品配達完了」の登録があれば、データベースＤＢに「返品配達完了」のフラグを立てる（ＳＴ１６４）。
【０１０９】
返品された商品は、サイバー・ショップ・サーバーＣＳＳにて、申請の商品であるか否かの検品処理がなされ、データベースＤＢにフラグを立てる（ＳＴ１６５）。
【０１１０】
ラピュタ・コマース・サーバーＬＣＳのクーロンプログラムがサイバー・ショップ・サーバーＣＳＳのデータベースを検索し、返品された商品の「真」、「偽」のフラグを読み込む（ＳＴ１６６）。
【０１１１】
「偽」の場合は、受理できない旨のメールを発送し、クレーム処理担当者にデータを渡す。「真」の場合は、ステップＳＴ１６４の「返品配達完了」のフラグにより、返品配達が完了し、且つ返品された商品が真であることを確認して、エレクトロニック・ウオレット・サーバーＥＷＳのクーロンプログラムがラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索し、上記フラグを検索して見つけると「預託解除・キャンセル」のフラグを立てる（ＳＴ１６７）。
【０１１２】
そして、ラピュタ・コマース・サーバーＬＣＳのクーロンプログラムがエレクトロニック・ウオレット・サーバーＥＷＳのデータベースＤＢを検索して、「預託解除・キャンセルフラグ」を発見すれば、仮ファイルを削除する（ＳＴ１６８）。
【０１１３】
また、ステップＳＴ１６１での照合、及びステップＳＴ１６７により、バンクサーバーのデーモンプログラムがデータベースＤＢから「預託解除・決済フラグ」若しくは「預託解除・キャンセルフラグ」を見つけると、預託を解除し、送金若しくは送金手続を行う（ＳＴ１６９）。
【０１１４】
また、ユーザーＵＲのメタタグプログラムがラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索して、「返品配達完了」のフラグ、及び「返品された商品が真である」フラグを見つけるとインジケータを点滅させる（ＳＴ１７０）。
【０１１５】
そして、ユーザーＵＲが「了解」を入力すると、クーリングオフ書式を削除若しくは停止して点滅を停止する（ＳＴ１７１、ＳＴ１７２）。
【０１１６】
さらに、ラピュタ・コマース・サーバーＬＣＳのクーロンプログラムがデータベースを検索して「返品配達完了」のフラグ及び「返品された商品が真である」フラグを見つけると、「返品が完了し、クーリングオフ処理が終了した旨」のメッセージをユーザーに送付する（ＳＴ１７３）。
【０１１７】
図８は、ユーザーＵＲからの再送依頼により商品の再送を行う再送請求処理手段を示したブロックフロー図である。
【０１１８】
再送請求をするクーリングオフ処理ユニットは、クーリングオフの一環として、商品の間違いや、破損、汚損等があった場合に、商品を返品し、再度送付を依頼するためのシステムである。
【０１１９】
先ず、ユーザーＵＲがクーリングオフ書式（ＪＡＶＡ）によって商品の再度依頼を行う。この時に入力する内容は、納入日、再送品希望配送日時、品番、数量、金額、請求原因（例示より数字で選択する、その他である（ＳＴ１７５）。
【０１２０】
ラピュタ・コマース・サーバーＬＣＳはデーモンプログラムによってデータベースＤＢを検索し、「該当する商品の有無」と「クーリングオフ期間内外」のチエックを行う（ＳＴ１７６）。
【０１２１】
そして、クーリングオフ期日外であればクーリングオフ期間外処理システムのルーチンにゆく（ＳＴ１７７）。
【０１２２】
期日内であればラピュタ・コマース・サーバーＬＣＳより品名を添えて確認のメッセージをユーザーＵＲに送付し、ユーザーＵＲは了解、又は変更の入力ができる（ＳＴ１７８、ＳＴ１７９）。
【０１２３】
ユーザーＵＲが了解すると、ラピュタ・コマース・サーバーＬＣＳのデーモンプログラムが、これまでの仮ファイルを削除して、新規の仮ファイルを作成してデータベースＤＢに新規の注文書（データフィールド）を作成し、それぞれに「再送請求フラグ」を立て、図２に示した預託システムにゆき商品発送の処理を行う（ＳＴ１８１）。
【０１２４】
一方、返品された商品は、サイバー・ショップ・サーバーＣＳＳにて、申請の商品か否かの検品作業を行い、データベースＤＢにフラグを立てる（ＳＴ１８２）。
【０１２５】
ラピュタ・コマース・サーバーＬＣＳのクーロンプログラムがサイバー・ショップ・サーバーＣＳＳのデータベースＤＢを検索し、「真」、「偽」のフラグを読み込む（ＳＴ１８３）。
【０１２６】
「真」であればラピュタ・コマース・サーバーＬＣＳが注文書の作成及び「再送請求フラグ」を立て、図２で示した預託システムに行き商品発送の処理を行う（ＳＴ１８１）。
【０１２７】
「偽」であれば受理できない旨のメール及びクレーム処理担当者にデータを渡す（ＳＴ１８４）。
【０１２８】
図９は、クーリングオフ期間外処理手段であるクーリングオフ期間外処理システムを示すブロックフロ図である。
【０１２９】
先ず、ラピュタ・コマース・サーバーＬＣＳのデーモンプログラムが「クーリングオフ不可フラグ」を仮ファイルとデータベースＤＢに立てていることが前提となる（ＳＴ１８５）。
【０１３０】
ユーザーＵＲのメタタグがクーリングオフ不可フラグを検出すると、ユーザーＵＲのラピュタホームページのインジケータを点滅させると同時に、クーリングオフ不可の旨のインフオメーションを表示し、了解を求める（ＳＴ１８６）。
【０１３１】
同時に、ラピュタ・コマース・サーバーＬＣＳのデーモンプログラムがユーザーＵＲにメールを発送する（ＳＴ１８７）。
【０１３２】
ここで、ユーザーＵＲがインフオメーションに対する回答を入力する（ＳＴ１８８）。
【０１３３】
同意しない場合は、ユーザーＵＲの残高を表示し、購入額が残高を超えていることを開示して、再度回答を促す（ＳＴ１８９）。
【０１３４】
了解した場合にはラピュタ・コマース・サーバーＬＣＳのデーモンプログラムがクーリングオフフラグ及びクーリングオフ不可フラグを削除して決済処理に行く（ＳＴ１９０、ＳＴ１９１）。
【０１３５】
図１０は、トランスポート・カンパニー・サーバーＴＣＳにおける配達終了に基づくクーリングオフ解除期日算定手段であるクーリングオフの解除期日算定ユニットを示したブロックフロー図である。
【０１３６】
クーリングオフの解除期日算定ユニットにおいては、先ずトランスポート・カンパニー・サーバーンスポーターサーバーＴＣＳにおけるデータベースＤＢに、配送が終了したことを登録する（ＳＴ１９５）。
【０１３７】
ラピュタ・コマース・サーバーＬＣＳのクーロンプログラムがトランスポート・カンパニー・サーバーＴＣＳのデータベースＤＢを検索して、新規の配送終了データがあれば、データベースＤＢに対して「配達終了フラグ」を立てる（ＳＴ１９６）。
【０１３８】
そして、ラピュタ・コマース・サーバーＬＣＳのクーロンプログラムがクーリングオフ解除期日算定をし、データベースＤＢに期日を登録する（ＳＴ１９７）。
【０１３９】
また、ラピュタ・コマース・サーバーＬＣＳのクーロンプログラムはクーリングオフ警報発令期日の算定をし、データベースＤＢに期日を登録する（ＳＴ１９８）。
【０１４０】
図１１は、トランスポート・カンパニー・サーバーＴＣＳにおける商品の配達終了期間に基づくクーリングオフ警報手段であるクーリングオフ警報システムを示したブロックフロー図である。
【０１４１】
クーリングオフ警報システムは、ユーザーＵＲが返品する時に申請するクーリングオフ申請をしてクーリングオフフラグを立て、ラピュタ・コマース・サーバーがこのクーリングオフフラグが立っていることを検出すると警報発令期日とクーリングオフ解除期日を算定する。この警報発令期日に達した注文ファイルをピックアップして警報フラグを立て、ユーザーＵＲがこのクーリングオフフラグが立っていることを検出すると、クーリングオフフラグが立っていることをユーザーＵＲがビジュアルで確認できるようにすると共に、了解、クレーム、クーリングオフの中止の３通りで対応できるようにしてある。
【０１４２】
そして、ユーザーＵＲが対応できるクレームは、ユーザーＵＲが既に返品配送済の段階において発行するものであり、ラピュタ・コマース・サーバーＬＣＳにクレームフラグを立てると同時に、トランスポート・カンパニー・サーバーＴＣＳに別途メールで通知するようにし、且つトランスポート・カンパニー・サーバーＴＣＳがこのクレームを検出するとクレームフラグを立て、トランスポート・カンパニー・サーバーＴＣＳがこのクレームフラグを検出する。するとクレームフラグが立っていることをトランスポート・カンパニー・サーバーＴＣＳがビジュアルで確認できるようになっている。以下、図１１のブロックフロー図で説明する。
【０１４３】
先ず、ラピュタ・コマース・サーバーＬＣＳのクーロンプログラムがユーザーＵＲが立てた新しいクーリングオフフラグを検出すると、「警報発令期日」と「クーリングオフ解除期日」を算定し、その結果をデータベースＤＢに登録する（ＳＴ２００）。
【０１４４】
ラピュタ・コマース・サーバーＬＣＳのクーロンプログラムが「警報発令期日」に達した注文ファイルをピックアップし、データベースＤＢに「警報フラグ」を立てる（ＳＴ２０１）。
【０１４５】
又は、トランスポート・カンパニー・サーバーＴＣＳが「返品の配送済フラグ」を自分のデータベースＤＢに立てていることが前提となる（ＳＴ２０２）。
【０１４６】
ラピュタ・コマース・サーバーＬＣＳのデーモンプログラムがトランスポート・カンパニー・サーバーＴＣのデータベースＤＢの「返品配送済フラグ」を見つけると、ラピュタ・コマース・サーバーＬＣＳのデータベースＤＢに「返品配送済フラグ」を立て、同時に「警報フラグ」を削除する（ＳＴ２０３）。
【０１４７】
ユーザーＵＲのメタタグプログラムがラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索し、そのデータの中に「警報フラグ」を見つけるとインジケータを点滅させる。インジケータをクリックすると了解書式を表示する（ＳＴ２０４）。
【０１４８】
ここで、ユーザーＵＲは、「了解」、「クーリングオフの中止」、「クレーム処理」の３通りのいずれかを入力することができる（ＳＴ２０５）。
【０１４９】
ユーザーＵＲが「了解」を入力すると、ユーザーＵＲに供給されている書式の中のブリンクコマンドの削除若しくは停止により点滅は停止する（ＳＴ２０６）。
【０１５０】
「クーリングオフの中止」を入力すると、クーリングオフ中止書式を選択し、クーリングオフ中止システムのルーチンに行く（ＳＴ２０７）。
【０１５１】
「クレーム処理」を入力すると、ユーザーＵＲがクレーム書式を選択し、配送番号と配送日時を入力する（ＳＴ２０８）。
【０１５２】
そうすると、ラピュタ・コマース・サーバーＬＣＳの仮ファイル及びデータベースＤＢにクレームフラグを立てると同時に、運送会社にメールにて通知する（ＳＴ２０９）。
【０１５３】
トランスポート・カンパニー・サーバーＴＣのデーモンプログラムがラピュタ・コマース・サーバーＬＣＳの仮ファイルのクレームフラグを見つけるとトランスポート・カンパニー・サーバーＴＣＳの端末に警報をブリンクさせる（ＳＴ２１０）。
【０１５４】
同時に、トランスポート・カンパニー・サーバーＴＣＳにメールを送付し、トランスポート・カンパニー・サーバーＴＣはクレーム処理担当に処理を移行する（ＳＴ２１１、ＳＴ２１２）。
【０１５５】
図１２は、ユーザーＵＲからのクーリングオフの中止を処理するクーリングオフ中止手段であるクーリングオフ中止システムを示したブロックフロー図である。
【０１５６】
クーリングオフ中止は、ユーザーＵＲがクーリングオフを申請したにも関わらず未だに返品発送を行っていない段階において発行されるものであり、ユーザーＵＲがクーリングオフを中止して当該商品が発注商品と同一であることを認定した場合に発行され、ユーザーＵＲがラピュタ・コマース・サーバーＬＣＳにクーリングオフ中止フラグを立てるようにリクエストを発行することによって、トランスポート・カンパニー・サーバーＴＣＳがこのクーリングオフ中止フラグを検出すると商品の配送プランを組み替えるようにする。
【０１５７】
又、エレクトロニック・ウオレット・サーバーＥＷＳ及びサイバー・ショップ・サーバーＣＳＳは、クーリングオフ中止フラグを検出すると、クーリングオフフラグを削除する。以下、図１２のブロックフロー図で説明する。
【０１５８】
ユーザーＵＲが「クーリングオフ中止」書式によりラピュタ・コマース・サーバーＬＣＳにクーリングオフ中止をリクエストする（ＳＴ２１５）
【０１５９】
すると、ラピュタ・コマース・サーバーＬＣＳのＣＧＩがデータベースＤＢ及び仮ファイルに「クーリングオフ中止フラグ」を立てる（ＳＴ２１６）。
【０１６０】
トランスポート・カンパニー・サーバーＴＣのデーモンプログラムがラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索し、「クーリングオフ中止フラグ」を見つけると、自分のデータベースＤＢの「クーリングオフフラグ」を削除し、「クーリングオフ中止フラグ」を立てる（ＳＴ２１７）。
【０１６１】
同時に、エレクトロニック・ウオレット・サーバーＥＷＳのデーモンプログラムがラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索し、「クーリングオフ中止フラグ」を見つけると自分のデータベースＤＢの「クーリングオフフラグ」を削除する（ＳＴ２１８）。
【０１６２】
同時に、サイバー・ショップ・サーバーＣＳＳのデーモンプログラムがラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索し、「クーリングオフ中止フラグ」を見つけると自分のデータベースＤＢの「クーリングオフフラグ」を削除する（ＳＴ２１９）。
【０１６３】
ラピュタ・コマース・サーバーＬＣＳのデーモンプログラムが各サーバーのデータベースＤＢを検索し、自分のデータベースＤＢの「クーリングオフ中止フラグ」を立てられたデータに相当するデータについてクーリングオフフラグが削除されているかどうかをチエックし、全て削除されていればラピュタ・コマース・サーバーＬＣＳのデーモンプログラムは仮ファイルから「クーリングオフ中止フラグ」を削除する（ＳＴ２２０）。
【０１６４】
一方、トランスポート・カンパニー・サーバーＴＣＳは、デーモンプログラムがデータベースＤＢの「クーリングオフ中止フラグ」を検出すると、配送プランを組み替える（ＳＴ２２１）。
【０１６５】
集荷当日の場合は、デーモンプログラムが配送車に電話若しくはメールで通報する。トランスポート・カンパニー・サーバーＴＣＳのデーモンプログラムは「クーリングオフ中止フラグ」を削除する（ＳＴ２２２、ＳＴ２２３）。
【０１６６】
図１３は、クーリングオフ期間に基づいてユーザーＵＲの手元に届いた商品の返品処理を行うクーリングオフの検品処理手段であるクーリングオフの検品処理ユニットを示したブロックフロー図である。
【０１６７】
クーリングオフの検品処理手段は、発注した商品がユーザーＵＲの手元に届いてから返品理由フラグを立てるようにしてある。この返品理由フラグは、商品間違い、破損・汚損、商品が予想と違っていた、その他の４種類からなり、それぞれのフラグはサイバー・ショップ・サーバーＣＳＳ内からの商品を、クーリングオフ申請に基づいて返品用商品の検品をするようになっている。
【０１６８】
又、このクーリングオフの検品処理手段は、返品用商品がクーリングオフ申請した期間内であって、破損・汚損の場合は運送中の破損・汚損又は配送する際の検品漏れ又は故意によるものかの判別をし、この運送中の破損・汚損又は配送する際の検品漏れの場合は再送するようになっている。
【０１６９】
そして、クーリングオフの検品処理手段は、返品用商品がクーリングオフ期間内であって、商品が予想と違っていた又はその他の理由の場合は、この商品の破損・汚損の有無を識別し、破損・汚損の場合は運送中の破損・汚損又は配送する際の検品漏れ又は故意によるものかの判別をし、この運送中の破損・汚損又は配送する際の検品漏れの場合は再送するようにしてある。以下、図１３のブロックフロー図で説明する。
【０１７０】
先ず、サイバー・ショップ・サーバーＣＳＳがラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索して、クーリングオフ申請物件から「返品理由（フラグ）」を読み込む（ＳＴ２２５）。
このフラグは、「商品間違い」、「破損、汚損」、「商品が予想と違っていた」、「その他」の４種類からなる。
【０１７１】
検品する商品が、自社取扱い商品かどうかを検査し、フラグを立て、自社商品の場合は品番を入力する（ＳＴ２２６）。
【０１７２】
非自社商品と認定した場合は、受理できない旨のメールを送付し、クレーム処理担当者にデータを渡す（ＳＴ２２７）。
【０１７３】
自社商品と認定した場合は、サイバー・ショップ・サーバーＣＳＳのデータベースＤＢを検索して品番商品の納入時期を調査し、クーリングオフ期間と比較してクーリングオフ該当商品かどうかをチエックする（ＳＴ２２８）。
【０１７４】
クーリングオフ期間内であって、返品原因が、「商品が予想と違っていた」、「その他の理由による場合」の検品は、破損・汚損の有無を検品し、入力書式により結果を入力する（ＳＴ２２８）。
【０１７５】
破損・汚損が有れば、サイバー・ショップ・サーバーＣＳＳのデータベースＤＢに「破損・汚損フラグ」を追加する（ＳＴ２２９）。
【０１７６】
破損・汚損が無ければサイバー・ショップ・サーバーＣＳＳのデータベースＤＢに返品された商品が「真」であるフラグを立てる（ＳＴ２３０）。
【０１７７】
又、クーリングオフ期間内において、返品原因が「破損・汚損」による場合は、その検品は、破損・汚損の原因を検査し、認定結果を入力書式で入力する（ＳＴ２３１）。
【０１７８】
故意によるものと認定された場合は、対策指示を表示し、受理できない旨のメールを発送し、クレーム担当者にデータを渡す（ＳＴ２３２、ＳＴ２３３）。
【０１７９】
運送中の事故と認定された場合は、運送会社と調整し、不調に終わればクレーム担当者にデータを渡す（ＳＴ２３４、ＳＴ２３５、ＳＴ２３６）。
【０１８０】
保険で対応できることに合意した場合には、入力書式から「真」のフラグをリクエストし、サイバー・ショップ・サーバーＣＳＳのデータベースＤＢに返品された商品が「真」であるフラグを立てる（ＳＴ２３７、ＳＴ２３８）。
【０１８１】
又、不明若しくは検品漏れと認定した場合も、サイバー・ショップ・サーバーＣＳＳのデータベースＤＢに返品された商品が「真」であるフラグを立てる（ＳＴ２３８）。
【０１８２】
ステップＳＴ２２８において、納入実績がない場合には、「納入実績無しフラグ」を立て、受理できない旨のメールを発送と、クレーム担当者にデータを渡す（ＳＴ２３９、ＳＴ２４０）。
【０１８３】
ステップ２２８において、クーリングオフ期間外であれば、メールにてユーザーＵＲに商品を間違えて送付していないかを確認する（ＳＴ２４１）。
【０１８４】
間違えていない場合は、クーリングオフ期間外のフラグを立て、クーリングオフ期間外処理システムに行く（ＳＴ２４２、ＳＴ２４３）。
【０１８５】
ステップ２４１において、商品を間違えて送付した場合は、ユーザーＵＲがクーリングオフフラグ削除をリクエストするか又はサイバー・ショップ・サーバーＣＳＳがクーリングオフフラグ削除をリクエストするかする。そして、ラピュタ・コマース・サーバーＬＣＳのデーモンプログラムが両者を検知すると、クーリングオフフラグを削除し、新規の仮ファイルを作成する。又、データベースＤＢに新規の注文書を作成し、それぞれに再発行フラグを立て、クーリングオフ申請処理に行く（ＳＴ２４４、ＳＴ２４５、ＳＴ２４６、ＳＴ２４７）。
【０１８６】
図１４は、商品の存在を証明した後の決済方法を示したブロックフロー図である。
【０１８７】
商品に対する代金の決済においては、エレクトロニック・ウオレット・サーバーＥＷＳに預託されている金銭を、商品を販売したサイバー・ショップ・サーバーＣＳＳの実際に商品を提供している者の口座に振り込む際に、エレクトロニック・ウオレット・サーバーＥＷＳはラピュタ・コマース・サーバーＬＣＳを介してトランスポート・カンパニー・サーバーＴＣＳからこの商品の配達証明を受け取ることによって、この商品がユーザーＵＲの手元にあることを確認する。且つラピュタ・コマース・サーバーＬＣＳがプログラムにより自動的に算定するクーリングオフ期間の終了を、ラピュタ・コマース・サーバーＬＣＳが確認することにより、ユーザーＵＲがこの商品をユーザーＵＲが発注した商品と同一物であることをユーザーＵＲが承認したものと認め、預託金額をサイバー・ショップ・サーバーＣＳＳの実際に商品を販売している者の口座に振り込むようにする。
【０１８８】
又、エレクトロニック・ウオレット・サーバーＥＷＳは、ラピュタ・コマース・サーバーＬＣＳに預託を解除して商品との決済をしたことを通知し、このラピュタ・コマース・サーバーＬＣＳは決済したことをデータベースＤＢに書き込むと共に当該商品発注のファイルを削除するようにしてある。以下、図１４のブロックフロー図を参照して説明する。
【０１８９】
先ず、トランスポート・カンパニー・サーバーＴＣＳが、データベースＤＢに配達終了が登録してあることが前提となる（ＳＴ２５０）。
【０１９０】
そうすると、ラピュタ・コマース・サーバーＬＣＳのクーロンプログラムがトランスポート・カンパニー・サーバーＴＣＳのデータベースＤＢを検索して新規の配達終了データがあれば、データベースＤＢに「配達終了フラグ」を立てる（ＳＴ２５１）。
【０１９１】
ラピュタ・コマース・サーバーＬＣＳのクーロンプログラムが「配達終了フラグ」を立てられたデータについて、クーリングオフ解除期日の算定をし、データベースＤＢに期日を登録する（ＳＴ２５２）。
【０１９２】
エレクトロニック・ウオレット・サーバーＥＷＳのクーロンプログラムがラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索して、「クーリングオフ解除期日」に達したデータがあれば、自分のデータベースＤＢに「預託解除・決済フラグ」を立てる（ＳＴ１６６）。
【０１９３】
バンクサーバーが、エレクトロニック・ウオレット・サーバーＥＷＳのデータベースＤＢを検索して「預託・決済フラグ」があれば、預託を解除して、サイバー・ショップ・サーバーＣＳＳに送金する（ＳＴ２５４）。
【０１９４】
又、ステップＳＴ１６４から、キャンセルする場合には図７に示すクーリングオフ処理ユニットに行き、再送請求であれば図８に示すクーリングオフ処理ユニットに行く（ＳＴ２５５、ＳＴ２５６）。
【０１９５】
【発明の効果】
以上説明したように本発明に係る電子決済システムは、端末機器を介して行うユーザーと、預託行為を含む金銭出納管理をする単独又は複数のエレクトロニック・ウオレット・サーバーと、商品を取り揃え且つ単独若しくは複数の商品仕入先との受発注管理を行うサイバー・ショップ・サーバーと、商品を自動的な配送及び集荷の情報を収集し、且つ商品の集荷・配送及び管理を行い、配送が完了したことを証明するトランスポート・カンパニー・サーバーと、ユーザーとエレクトロニック・ウオレット・サーバーとサイバー・ショップ・サーバーとトランスポート・カンパニー・サーバーとのそれぞれと個別に通信回線を介して接続し、接続された全体を組織的に統合すると共に取引履歴をデータベース上に記録・保管し、且つクーリングオフシステムにより予め設定されているクーリングオフ期間に基づいて最終的な商品の存在を証明するラピュタ・コマース・サーバーとから構成して、ラピュタ・コマース・サーバーに接続されたそれぞれのユーザーとエレクトロニック・ウオレット・サーバーとサイバー・ショップ・サーバーとトランスポート・カンパニー・サーバーとの相互間の通報、証明、保証をラピュタ・コマース・サーバーを介して行い、且つ商品のキャンセル処理及びクーリングオフ期間に基づく処理を電子仮想空間上において普遍的にルール化して行うようにしたことにより、時空を超えた電子仮想空間における商取引の安全を確保した、いわゆるインターネットに代表される電子仮想空間上の電子商取引に関する受発注管理、物流管理、預託決済管理に基づいて商品とその決済代金との存在を保証することができると云う効果がある。
【図面の簡単な説明】
【図１】本発明に係る全体構成の接続関係を示した説明図である。
【図２】同預託システムを示したブロックフロー図である。
【図３】同電子商取引システムにおける預託通報システムを示したブロックフロー図である。
【図４】同電子商取引システムにおけるキャンセル処理ユニットの納期了承〜配達までを示したブロックフロー図である。
【図５】同電子商取引システムにおけるキャンセル処理におけるサイバー・ショップ・サーバーＣＳＳの対応システムユニットを示したブロックフロー図である。
【図６】同電子商取引システムにおけるキャンセル処理におけるトランスポート・カンパニー・サーバーＴＣの対応システムユニットを示したブロックフロー図である。
【図７】同電子商取引システムにおけるクーリングオフ処理ユニット（１）のキャンセル処理を示したブロックフロー図である。
【図８】同電子商取引システムにおけるクーリングオフ処理ユニット（２）の再送請求を示したブロックフロー図である。
【図９】同電子商取引システムにおけるクーリングオフ処理ユニット（３）のクーリングオフ期間外処理システムを示したブロックフロー図である。
【図１０】同電子商取引システムにおけるクーリングオフの解除期日算定ユニットを示したブロックフロー図である。
【図１１】 同電子商取引システムにおけるクーリングオフ処理ユニット（４）のクーリングオフ警報システムを示したブロックフロー図である。
【図１２】同電子商取引システムにおけるクーリングオフ処理ユニット（５）のクーリングオフ中止システムを示したブロックフロー図である。
【図１３】同電子商取引システムにおけるクーリングオフの検品処理ユニットを示したブロックフロー図である。
【図１４】同電子商取引システムにおける決済処理ユニットを示したブロックフロー図である。
【図１５】従来技術における商取引を示した説明図である。
【符号の説明】
ＵＲ；ユーザー、ＣＳＳ；サイバー・ショップ・サーバー、ＥＷＳ；エレクトロニック・ウオレット・サーバー、ＴＣＳ；トランスポート・カンパニー・サーバー、ＬＣＳ；ラピュタ・コマース・サーバー
【発明の属する技術分野】
本発明は、電子決済システムに関し、特に仮想空間領域において、遠隔での商品の発注と、発注商品との決済及び実際に商品を配送をするセキュリテイを確保した電子商取引を構築する電子決済システムに関するものである。
【０００２】
【従来の技術】
従来から流通している、決済システムは、図１５に示すように、ユーザーとＥＣ（Ｅｒｃｔｒｏｎｉｃ Ｃｏｍｍｅｒｃｅ）間において商取引を行うもので、決済時期が３種類に分類される。
【０００３】
第１の分類は、図１５（イ）に示すように、決済時期が配送時の場合であり、ユーザーがＥＣに発注すると、ＥＣ側から、ユーザーに自己配達をし、且つ配送時において代金を回収するシステムである。
【０００４】
第２の分類は、図１５（ロ）に示すように、ユーザー側からＥＣに対して予約をして物品を購入する手法であり、この場合の決済時期は、例えばユーザーが来店した時に決済する。
【０００５】
第３の分類は、図１５（ハ）に示すように、ユーザーからＥＣに発注すると、ＥＣ側から物品が配送され、且つ請求書も発行される。この決済時期は、数ヶ月以内に自動引落し、月次決済、発生時に決済する等がある。
【０００６】
このような３種類に分類される決済システムにおいて商品を購入するためには社会に流通している貨幣又は電子マネーがある。
【０００７】
電子マネーは、クレジットタイプのもの、ネットワークタイプのもの、ネットワークとＩＣカードを組み合わせたもの、ＩＣカードタイプのものがあり、これらは、全て社会に流通している貨幣の代用として使用される。例えば、ＩＣカードでの商品の購入は、所望の商品を特定したときに、ＩＣカードがその代金を支払ったようにして、後日別のルートにより、ＩＣカードで支払った代金の決済を上記決済システムの手法により行う。
【０００８】
このようなＩＣカードの他に、現在のクレジットカードと同様に現金社会の中で使用するＩＣカードによる決済がある。いわゆるモンデックス型といわれるＩＣカードによる決済は、先ず銀行等の金融機関と契約してエレクトロニック・ウオレット・サーバー用口座を開設して入金する。そして、暗証番号及び暗号鍵を内蔵したＩＣカードの発行を受ける。通信回線によりＩＣカードにエレクトロニック・ウオレット・サーバーの預金口座からエレクトロニック・マネー（ＥＭ）を移す。
この移されたＥＭ分だけＩＣカードの利用ができ、従って、予め決められた金額をＩＣカードで使用することができるようになっている。
【０００９】
又、このような電子マネーを利用した商取引においては、セキュリテイを確保することが重要であり、そのためには、（１）ＩＤ＋パスワード、（２）通信暗号化システム（例えばセキュリテイカードを使用する）、（３）電子署名システム、（４）業務フロー全体が１つのセキュリテイ機構を形成するようにする等により安全性を図っている。
【００１０】
【発明が解決しようとする課題】
しかしながら、上記従来技術で説明した商取引において使用される電子マネーは、即ち、クレジットカードとの提携型であるいわばカード会社による仮想空間における決済システムであり、商品を配送及び管理等するトランスポート・カンパニー・サーバーや、複数の商品を手配したり管理するサイバー・ショップ・サーバー等を含め、且つ相互に承認及び保証すると云うシステムにはなっていないため、仮想空間における商取引で重要な根幹をなす商品の存在の証明及び決済金額の証明ができないと云う問題点がある。
【００１１】
従って、仮想都市を構築した場合における電子商取引において、少なくとも商品の存在の証明及び決済金額の存在を証明できるシステムに解決しなければならない課題を有している。
【００１２】
【課題を解決するための手段】
上記課題を解決するために、本発明に係る電子決済システムは、商品の発注及び購入を端末機器を介して行うユーザーと、該ユーザーに前記商品の購入決済金があることを証明及び保証するために行われる預託行為を含む金銭出納管理をする単独又は複数のエレクトロニック・ウオレット・サーバーと、前記ユーザーが購入する前記商品を取り揃え且つ単独若しくは複数の商品仕入先との受発注管理を行う複数のサイバー・ショップ・サーバーと、前記ユーザーが選択した商品の自動的な配送及び集荷の情報を収集し、且つ該商品の集荷・配送及び管理を行い、配送が完了したことを証明する単独又は複数のトランスポート・カンパニー・サーバーと、前記ユーザーとエレクトロニック・ウオレット・サーバーとサイバー・ショップ・サーバーとトランスポート・カンパニー・サーバーとのそれぞれと個別に通信回線を介して接続し、該接続された全体を組織的に統合すると共に取引履歴をデータベース上に記録・保管し、且つクーリングオフシステムにより予め設定されているクーリングオフ期間に基づいて最終的な商品の存在を証明するラピュタ・コマース・サーバーとから構成され、前記ラピュタ・コマース・サーバーに接続されたそれぞれのユーザーとエレクトロニック・ウオレット・サーバーとサイバー・ショップ・サーバーとトランスポート・カンパニー・サーバーとの相互間の通報、証明、保証を前記ラピュタ・コマース・サーバーを介して行い、且つ前記商品のキャンセル処理及び前記クーリングオフ期間に基づく処理を電子仮想空間上において普遍的にルール化して行うようにしたことである。
【００１３】
このように構成した電子決済システムは、通信回線を介した商取引において事前にユーザー側の資金と商品を販売するメーカー側の商品在庫を電子的に照合することができ、且つユーザーの資金は預託によりエレクトロニック・ウオレット・サーバーが保証し、商品はサイバー・ショップ・サーバーが保証し且つ商品の配達はトランスポート・カンパニー・サーバーが保証することができ、時空を超えた電子仮想空間における商取引の安全性を確保することができ、具体的にはインターネットに代表される電子仮想空間上の電子商取引に関する受注発注管理、物流管理、預託決済管理に基づいて商品とその決済代金の存在を保証する商取引のシステムを構築することができる。
【００１４】
【発明の実施の形態】
次に、本発明に係る電子決済システムについて図面を参照にして説明する。
【００１５】
本発明に係る電子決済システムは、図１に示すように、商品の発注及び購入を端末機器を介して行うユーザー（Ｕｓｅｒ；ＵＲ）と、このユーザーＵＲに商品の購入決済金があることを証明及び保証するために行われる預託行為を含む金銭出納管理をする単独又は複数のエレクトロニック・ウオレット・サーバー（Ｅｌｅｃｔｒｏｎｉｃ Ｗａｌｌｅｔ Ｓｅｒｖｅｒ；ＥＷＳ）と、ユーザーＵＲが購入する商品をこのシステム上で取り揃えて販売し、そのための単独若しくは複数の商品仕入先との受発注管理を行う複数のサイバー・ショップ・サーバー（Ｃｙｂｅｒ Ｓｈｏｐ Ｓｅｒｖｅｒ；ＣＳＳ）と、ユーザーＵＲが選択した商品を本システム上から自動的に配送及び集荷の情報を収集し、この商品の集荷・配送及び管理を行い、配送が完了したことを証明する、即ち、商品の存在を証明するための単独又は複数のトランスポート・カンパニー・サーバー（Ｔｒａｎｓｐｏｒｔ Ｃｏｍｐａｎｙ Ｓｅｒｖｅｒ；ＴＣＳ）と、ユーザーＵＲとエレクトロニック・ウオレット・サーバーＥＷＳとサイバー・ショップ・サーバーＣＳＳとトランスポート・カンパニー・サーバーＴＣＳとのそれぞれと個別に専用若しくは公衆の通信回線を介して接続し、この接続された全体を組織的に統合すると共に取引履歴をデータベース（Ｄａｔａ Ｂａｓｅ；ＤＢ）上に記録・保管し、且つクーリングオフシステムにより予め設定されているクーリングオフ期間をカウントダウンすることによって最終的な商品の存在を証明するラピュタ・コマース・サーバー（Ｌａｐｕｔａ Ｃｏｍｍｅｒｃｅ Ｓｅｒｖｅｒ；ＬＣＳ）とから構成されている。
【００１６】
エレクトロニック・ウオレット・サーバーＥＷＳは、イーサネットを介して金融機関のバンクサーバーと接続してイントラネットを形成し、イントラネットを形成したエレクトロニック・ウオレット・サーバーＥＷＳは、インターネットを介してラピュタ・コマース・サーバーＬＣＳにイーサネットで接続しているエレクトロニック・ウオレット・デュプリカント・サーバー（ＥｌｅｃｔｒｏｎｉｃＷａｌｌｅｔ Ｄｕｐｌｉｃａｎｔ Ｓｅｒｖｅｒ；ＥＷＤＳ）に接続されている。このようにエレクトロニック・ウオレット・デュプリカント・サーバーＥＷＤＳを介してエレクトロニック・ウオレット・サーバーＥＷＳとラピュタ・コマース・サーバーＬＣＳとを接続したのは、ＣＧＩやＳＳＩを用いたシステムの場合、直接に相手方に書き込むシステムに比べ、リクエスト及び回答で二重にトランザクションが発生する為トラフイックが倍の密度になってしまい、更に、デーモンプログラムによる処理は頻繁なアクセスが発生する為、トラフイックに多大な負荷を与えてしまう。このようにただでさえトラフイックが過密なため、通信時間のかかりすぎやデータの紛失当の問題が発生してしまう。そのため、エレクトロニック・ウオレット・デュプリカント・サーバーＥＷＤＳを設置してイーサネットによって対応して、通信時間のかかりすぎやデータの紛失等の問題を解決している。
【００１７】
サイバー・ショップ・サーバーＣＳＳは、複数のホールセラー（Ｗｈｏｌｅｓａｌｅｒ；ＷＳ）と複数のファクトリ（Ｆａｃｔｏｒｙ；ＦＣ）とでイントラネットを構築してＣＡＬＳを形成し、且つサイバーショップサーバーＣＳＳは、インターネットを介してラピュタ・コマース・サーバーＬＣＳのサイバー・ショップ・デュプリカント・サーバー（Ｃｙｂｅｒ Ｓｈｏｐ Ｄｕｐｌｉｃａｎｔ Ｓｅｒｖｅｒ；ＣＳＤＰ）に接続された構成となっている。このサイバー・ショップ・デュプリカント・サーバーＣＳＤＰを介してラピュタ・コマース・サーバーＬＣＳに接続するようにしたのは、上述したエレクトロニック・ウオレット・デュプリカント・サーバーＥＷＤＳと同様の理由によるものであり、ＣＧＩやＳＳＩを用いたシステムの場合、リクエスト及び回答で二重にトランザクションが発生する為トラフイックが倍の密度になってしまうこと、及びデーモンプログラムによる処理は頻繁なアクセスが発生する為、トラフイックに多大な負荷を与えてしまい、トラフイックが過密になり、通信時間のかかりすぎやデータの紛失当の問題が発生してしまうため、サイバー・ショップ・デュプリカント・サーバーＣＳＤＰを設置してイーサネットによって対応し、通信時間のかかりすぎやデータの紛失等の問題を解決しているのである。
【００１８】
トランスポート・カンパニー・サーバーＴＣＳは、複数のブランチ（Ｂｒａｎｃｈ；ＢＲ）とからイントラネットを構築してＣＡＬＳを形成し、且つトランスポート・カンパニー・サーバーＴＣＳはインターネットを介してラピュタ・コマース・サーバーＬＣＳのトランスポート・カンパニー・デュプリカント・サーバー（Ｔｒａｎｓｐｏｒｔ Ｃｏｍｐａｎｙ Ｄｕｐｌｉｃａｎｔ Ｓｅｒｖｅｒ；ＴＣＤＰ）に接続された構成となっている。このトランスポート・カンパニー・デュプリカント・サーバーＴＣＤＰを介してラピュタ・コマース・サーバーＬＣＳに接続するようにしたのは、上述したエレクトロニック・ウオレット・デュプリカント・サーバーＥＷＤＳと同様の理由によるものであり、ＣＧＩやＳＳＩを用いたシステムの場合、リクエスト及び回答で二重にトランザクションが発生する為トラフイックが倍の密度になってしまうこと、及びデーモンプログラムによる処理は頻繁なアクセスが発生する為、トラフイックに多大な負荷を与えてしまい、トラフイックが過密になり、通信時間のかかりすぎやデータの紛失等の問題が発生してしまうため、トランスポート・カンパニー・デュプリカント・サーバーＴＣＤＰを設置してイーサネットによって対応し、通信時間のかかりすぎやデータの紛失等の問題を解決しているのである。
【００１９】
ラピュタ・コマース・サーバーＬＣＳは、サイバー・ショップ・サーバーＣＳＳとインターネットを介して接続するサイバー・ショップ・デュプリカント・サーバーＳＳＤＳと、エレクトロニック・ウオレット・サーバーＥＷＳとインターネットを介して接続するエレクトロニック・ウオレット・デュプリカント・サーバーＥＷＤＳと、トランスポート・カンパニー・サーバーＴＣＳとインターネットを介して接続するトランスポート・カンパニー・デュプリカント・サーバーＴＣＤＳとを備え、且つこれらのそれぞれはイーサネットを介してラピュタ・コマース・サーバーＬＣＳに接続されている。又、ラピュタ・コマース・サーバーＬＣＳは、複数のユーザーＵＲとインターネットを介して接続されている。
【００２０】
このような接続状態で構成した電子決済システムは、ラピュタ・コマース・サーバーＬＣＳに接続されたそれぞれのユーザーＵＲとエレクトロニック・ウオレット・サーバーＥＷＳとサイバー・ショップ・サーバーＣＳＳとトランスポート・カンパニー・サーバーＴＣＳとの相互間の通報、証明、保証をラピュタ・コマース・サーバーＬＣＳを介して行い、且つ各構成要素に跨ぐ商品のキャンセル処理及びクーリングオフ期間に基づく処理を電子仮想空間上において普遍的にルール化して整備することができ、これは時空を超えた電子仮想空間における商取引の安全性を確保した、いわゆるインターネットに代表される電子仮想空間上の電子商取引に関する受発注管理・物流管理・預託決済管理に基づいて商品とその決済代金の存在を保証するシステムを実現できるのである。
【００２１】
そして、上記構成にした電子決済システムにおいては、納期の通知による商品存在の証明と預託による決済金額の存在を保証することによる預託システムによる契約の成立と、消費者の保護及び最終的な商品の存在を証明するクーリングオフシステムの導入と、パスワードの盗難に対するセキュリテイとして預託通報システムの導入と、消費者保護と商品返品に対するセキュリテイを確保するクーリングオフ警報システムの導入と、サイバー・ショップ・サーバー側の商品を販売する販売者を保護する検品処理システムの導入と、システム全体のセキュリテイを図るために通知と云う概念を導入した通知システムが構築されている。
【００２２】
即ち、エレクトロニック・ウオレット・サーバーＥＷＳとサイバー・ショップ・サーバーＣＳＳとトランスポート・カンパニー・サーバーＴＣＳとラピュタ・コマース・サーバーＬＣＳ間のデータの送受信は、ＣＧＩ又はＳＳＩ若しくはこれらと同等の機能を有するシステムによって所定の相手サーバーにリクエストすることにより、相互に相手のデータベースＤＢを検索し、読み込むことによって行い、直接に相手のデータベースＤＢへの書き込みを行わないことによって、データの改ざんを行えないようにした構成となっている。
【００２３】
そして、ユーザーＵＲからラピュタ・コマース・サーバーＬＣＳ間のデータの送受信は、ＣＧＩ（Ｃｏｍｍｏ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃ）又はＳＳＩ（Ｓｅｒｖｅｒ Ｓｉｄｅ Ｉｎｃｌｕｄｅ）若しくはそれと同等又はそれ以上の機能を有するシステムによって、ユーザーＵＲからのリクエストのみとし、ユーザーＵＲからラピュタ・コマース・サーバーＬＣＳへの直接の書き込みをなくすことによって、データの改ざんを行えないようにした構成となっている。
【００２４】
また、ユーザーＵＲ又はサイバー・ショップ・サーバーＣＳＳ又はトランスポート・カンパニー・サーバーＴＣＳ又はエレクトロニック・ウオレット・サーバーＥＷＳの情報は、ラピュタ・コマース・サーバーＬＣＳがタイマー動作プログラム又は常時動作プログラムによって自動的にユーザーＵＲとサイバー・ショップ・サーバーＣＳＳとトランスポート・カンパニー・サーバーＴＣＳとエレクトロニック・ウオレット・サーバーＥＷＳとのそれぞれにリクエストを発行し、このユーザーＵＲとサイバー・ショップ・サーバーＣＳＳとトランスポート・カンパニー・サーバーＴＣＳとエレクトロニック・ウオレット・サーバーＥＷＳとのそれぞれがＣＧＩ又はＳＳＩを生成してラピュタ・コマース・サーバーＬＣＳに回答するようにして情報の授受を行うような構成となっている。
【００２５】
図２は、預託と契約の成立、即ち、納期の通知による商品存在の証明と預託による決済金額の存在保証による契約の成立を示した、いわゆる預託システムを示したブロックフロー図である。
【００２６】
先ず、ユーザーＵＲがラピュタホームページの注文書の書式を利用してラピュタ・コマース・サーバーＬＣＳのデータベースＤＢに、納品先、登録納期、品番、品名、数量、単価、金額等からなる注文内容を登録する（ＳＴ１００）。
【００２７】
サイバー・ショップ・サーバーＣＳＳに常駐し任意に定められた時間毎に検索を行いにいく機能を有するクーロン（ＣＲＯＮ）プログラムが、ラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索し、フラグの立っていない注文書若しくは「残高不足解消フラグ」、「再送請求フラグ」の立っている注文書を抽出する（ＳＴ１０１）。
【００２８】
サイバー・ショップ・サーバーＣＳＳのＣＡＬＳ（Ｃｏｎｔｉｎｕｅ Ａｃｑｕｉｓｉｔｉｏｎ ａｎｄ Ｌｉｆｅーｃｙｃｌｅ Ｓｕｐｐｏｒｔ）がデータベースＤＢを検索して注文書の商品のそれぞれの納期を算定する（ＳＴ１０２）。
【００２９】
サイバー・ショップ・サーバーＣＳＳが納期データをサイバー・ショップ・サーバーＣＳＳのＣＡＬＳから受け取りデータベースＤＢに登録する（ＳＴ１０３）。
【００３０】
ラピュタ・コマース・サーバーＬＣＳにおいて、常時アンダーグランドで動作しており、イベントが発生した時に即座に対応する機能を有するデーモン（ＤＡＥＭＯＮ）プログラムがサイバー・ショップ・サーバーＣＳＳの納期データを検索してデータベースＤＢに登録する（ＳＴ１０４）。
【００３１】
ユーザＵＲは、端末上で任意に定められた時間毎に動作するＨＴＭＬ（ハイパーテキストマークアップランゲージ）のプログラムであるメタタグプログラムにより、ラピュタホームページにおいて、ラピュタ・コマース・サーバーＬＣＳのデータベースＤＢの納期データを検索して読み込む（ＳＴ１０５）。
【００３２】
納期通知が存在していれば、納期通知インジケータが点滅し、納期通知画面が表示される（ＳＴ１０６）。入荷の見込みがなくまた在庫がない場合には、在庫無しのインジケータが点滅し、通知画面に表示される（ＳＴ１０７）。
【００３３】
納期が了承されると、納期了承ボタンをクリックし（ＳＴ１０８）、ラピュタ・コマース・サーバーＬＣＳのＨＴＴＰに納期了承をリクエストし（ＳＴ１０９）、ＣＧＩプログラム、即ち、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）のプログラムであって、外部からのリクエストを受けて動作し、且つリクエストの結果をリクエストの発信者に返答する機能を有する、このＣＧＩプログラムがラピュタ・コマース・サーバーＬＣＳのデータベースＤＢに契約成立のフラグを立てる（ＳＴ１１０）。
【００３４】
納期がキャンセルの場合は、キャンセルボタンをクリックする（ＳＴ１１１）。そうすると、ラピュタ・コマース・サーバーＬＣＳのＨＴＴＰにキャンセル処理をリクエストし、ラピュタ・コマース・サーバーＬＣＳのデータベースＤＢの注文書用の仮ファイルを削除し、データベースＤＢにキャンセルを登録する（ＳＴ１１２、ＳＴ１１３）。
【００３５】
このようにして商品の納期及び商品の存在の証明は、ユーザーＵＲが、ラピュタ・コマース・サーバーＬＣＳを介して行うサイバー・ショップ・サーバーＣＳＳに対する商品の発注は、サイバー・ショップ・サーバーＣＳＳ内においてラピュタ・コマース・サーバーＬＣＳがユーザーＵＲからの商品発注を受けたことを検知するようにし、この商品発注を検知した時にサイバー・ショップ・サーバーＣＳＳのデータベースＤＢ又はサイバー・ショップ・サーバーＣＳＳ内のクライアントに対してユーザーＵＲが発注した商品の在庫検索を実施して、当該商品の単純納期を算出することができる。
【００３６】
そして、この単純納期は、ユーザーＵＲの指定する配達地による配送必要日数と合わせることにより、ユーザーＵＲの指定する配達地までの最終納期を算定し、ラピュタ・コマース・サーバーＬＣＳを通じて商品の最終納期をユーザーＵＲに送り返すことによって商品の存在を証明することができるのである。
【００３７】
一方、ステップＳＴ１００において、注文書の注文内容が登録されると、エレクトロニック・ウオレット・サーバーＥＷＳがデーモンプログラムによりラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索し、何もフラグが立てられていない注文書若しくは「残高不足フラグ」「再送請求フラグ」の立てられた注文書を抽出する。そして登録済みのユーザーＵＲのエレクトロニック・ウオレット・サーバーＥＷＳでの残高と購入金額とを比較して「購入可否」をデータベースＤＢに登録する（ＳＴ１１４）。
【００３８】
ラピュタ・コマース・サーバーＬＣＳのデーモンプログラムがエレクトロニック・ウオレット・サーバーＥＷＳのデータベースＤＢを検索し、「購入可否」についての新規データを抽出し、データベースＤＢに「購入可否」のフラグを立てる（ＳＴ１１５）。
【００３９】
購入可であれば購入可能フラグを立て、購入否であれば購入不可フラグを立て、Ｅーｍａｉｌで通知する（ＳＴ１１６、ＳＴ１１７）。
【００４０】
又、ラピュタホームページのメタタグプログラムが残高不足フラグを検索し、あれば入金、キャンセルの入力の書式を表示し、ラピュタホームページのメタタグプログラムが「残高不足フラグ」を検索し、あれば残高不足のインジケータを点滅させる（ＳＴ１１８、ＳＴ１１９）。
【００４１】
もし入金処理がされると再度ステップＳＴ１０１及びＳＴ１１４から実行され、キャンセル処理の場合はキャンセルが選択される（ＳＴ１２０）。
【００４２】
ラピュタ・コマース・サーバーＬＣＳのデーモンプログラムが注文書用仮ファイルを削除し、データベースＤＢにキャンセルフラグを立て、エレクトロニック・ウオレット・サーバーＥＷＳのデーモンプログラムがラピュタ・コマース・サーバーＬＣＳを検索してキャンセルフラグを見つけると、この注文コードに基づくデータをデータベースＤＢから削除する（ＳＴ１２１、ＳＴ１２２）。
【００４３】
このようにして商品の存在を証明することと並行して、エレクトロニック・ウオレット・サーバーＥＷＳは、ユーザーＵＲの商品発注を検知し、この発注した商品の決済金額に対するエレクトロニック・ウオレット・サーバーＥＷＳ内のユーザーＵＲの預金残高の大小を検索し、この検索結果をラピュタ・コマース・サーバーＬＣＳを介してユーザーＵＲ及びサイバー・ショップ・サーバーＣＳＳに通知することによって決済金額の存在を保証することができる。
【００４４】
又、この商品の存在がサイバー・ショップ・サーバーＣＳＳによって証明され、且つ預金残高が決済預金残高より大きいか又は同等であることがエレクトロニック・ウオレット・サーバーＥＷＳによって証明され、ユーザーＵＲが最終納期を了承することをラピュタ・コマース・サーバーＬＣＳに通知した場合には、エレクトロニック・ウオレット・サーバーＥＷＳは、預金残高から決済金額相当分を預託することによって決済金額の存在を保証するようにすることができ、この保証により商品発注は成立したものとみなすことができるのである。
【００４５】
また、ユーザーＵＲから発注した商品がない場合、又はユーザーＵＲが最終納期を不満とした場合において、ラピュタ・コマース・サーバーＬＣＳを介して行われるエレクトロニック・ウオレット・サーバーＥＷＳからの預金残高通知に対してユーザーＵＲが商品発注をキャンセルした場合は、商品発注は成立しないものとすることができる。
【００４６】
預金残高が決済金額より少ない場合で且つユーザーＵＲがラピュタ・コマース・サーバーＬＣＳを介してエレクトロニック・ウオレット・サーバーＥＷＳから残高不足の通知を受けた場合において、ユーザーＵＲが入金処理を行うまでの間は、商品発注を一時保留の状態にする。
【００４７】
このようにして決済金額の存在が証明されたことを示す購入可能フラグが立ち、且つ商品の存在が証明されたことを示す契約成立のフラグが立つとラピュタ・コマース・サーバーＬＣＳのデーモンプログラムがデータベースＤＢに「預託フラグ」を立て、預託通報システムに行く（ＳＴ１１４、ＳＴ１１５）。
【００４８】
図３は、ユーザーのパスワードの盗難等に対するセキュリテイを図るための預託通報システムを示したブロックフロー図である。
【００４９】
預託通報システムは、商品を購入しようとする者と真実のユーザーとの一致を図るためのシステムであり、商品を購入すると、購入をしたパスワードを有するユーザーにフィードバックをかけてセキュリテイを図るように構成されている。
【００５０】
図３はそのブロックフロー図であり、先ず図２を参照にして説明した預託システムにおいてラピュタ・コマース・サーバーＬＣＳのデーモンプログラムがデータベースＤＢに預託フラグが立っていることが前提となる（ＳＴ１１６）。
【００５１】
ユーザーＵＲのラピュタホームページのメタタグプログラムがラピュタ・コマース・サーバーＬＣＳのＨＴＴＰに対して、ユーザーディレクトリーの仮ファイルの中の預託フラグの有無をリクエストする（ＳＴ１１７）。
【００５２】
預託フラグが立っている場合は、ユーザーＵＲの預託インジケータが点滅し、預託フラグがない場合には、何もしない（ＳＴ１１８、ＳＴ１１９）。
【００５３】
ここでユーザーＵＲは了解かキャンセルを入力することができる。
【００５４】
ユーザーＵＲがキャンセルを入力すると、、預託フラグが削除され、ユーザーディレクトリーの仮ファイルを削除するようにラピュタ・コマース・サーバーＬＣＳにリクエストをする（ＳＴ１２０、ＳＴ１２１）。
【００５５】
ラピュタ・コマース・サーバーＬＣＳはこのリクエストを受けると、データベースＤＢの預託フラグを削除し、且つユーザーディレクトリーの仮ファイルも削除する（ＳＴ１２２）。
【００５６】
預託フラグが削除されると預託オンジケータの点滅は終了する（ＳＴ１２３）。
【００５７】
一方ユーザが了解の入力を行うと、ラピュタ・コマース・サーバーＬＣＳに預託承認フラグのリクエストを行う（ＳＴ１２４、ＳＴ１２５）。
【００５８】
ラピュタ・コマース・サーバーＬＣＳのＨＴＴＰが預託承認ＣＧＩを作成し、ユーザーディレクトリーの仮ファイル及びデータベースＤＢに預託承認を登録する（ＳＴ１２６）。
【００５９】
エレクトロニック・ウオレット・サーバーＥＷＳは、ラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索し、預託承認フラグがあれば、自分のデータベースＤＢに預託フラグを立てる（ＳＴ１２７）。
【００６０】
バンクサーバーは、エレクトロニック・ウオレット・サーバーＥＷＳのデータベースＤＢを検索し、預託承認フラグがあれば、預託処理を実行する（ＳＴ１２８）。
【００６１】
このようにして、ユーザーＵＲが商品の納期を承認し、且つエレクトロニック・ウオレット・サーバーＥＷＳによる決済金額の存在が証明された時に、ラピュタ・コマース・サーバーＬＣＳにおいて預託フラグを立て、ユーザーＵＲがこの預託フラグが立っていることを検出すると、預託フラグが立っていることをユーザーＵＲがビジュアルで確認できるようにして、真実のユーザーが商品を購入したかどうかを視認により判別できる。
【００６２】
又、了解又はキャンセルの入力で対応できるようにして、ユーザーＵＲが、了解を入力すると、エレクトロニック・ウオレット・サーバーＥＷＳはこの了解した預託フラグを検出して預託金額と前記商品の決済金額との決済処理を行うようにして、金銭面でのセキュリテイを図ることができるのである。
【００６３】
また、ユーザーＵＲが、キャンセルを入力すると、これは真実のユーザーＵＲの商品の購入ではないと判断して、ラピュタ・コマース・サーバーＬＣＳは、このキャンセルした預託フラグを検出して当該商取引のデータフィールドの削除を行う。
【００６４】
図４〜図６は消費者を保護するためのキャンセルシステムを示したものである。
【００６５】
消費者を保護するためのキャンセルシステム、即ち、ユーザーが行った商品発注に対するキャンセル処理は、ラピュタ・コマース・サーバーＬＣＳが記録媒体、例えばデータベース上に商取引についてのデータフィールドをまだ作成していない商品発注時点から納期承認前までと、ラピュタ・コマース・サーバーが記録媒体上に商取引についてのデータフィールドを作成した納期承認時点から配達証明発行前までの２つの段階の時期においてのみ有効となっている。
【００６６】
データフィールドを作成していない場合とは、ラピュタ・コマース・サーバーＬＣＳがデータフィールドの作成を実行しないで終了したことを意味し、データフィールドを作成している場合とは、ラピュタ・コマース・サーバーＬＣＳは、このデータフィールドの削除を行う。
【００６７】
図４は、ユーザーＵＲが商品を納期了承してから配達までのキャンセル処理を示したブロックフロー図である。
【００６８】
先ず、ユーザーＵＲがキャンセル書式を用いてキャンセルを入力・送信すると、ラピュタ・コマース・サーバーＬＣＳのＣＧＩが仮ファイル及びデータベースＤＢにキャンセルフラグを立てる（ＳＴ１３０、ＳＴ１３１）。
【００６９】
エレクトロニック・ウオレット・サーバーＥＷＳのデーモンプログラがラピュタ・コマース・サーバーＬＣＳのユーザーディレクトリーを検索して、キャンセルフラグがあれば自分のデータベースＤＢにキャンセルフラグを立てる（ＳＴ１３２）。
【００７０】
トランスポート・カンパニー・サーバーＴＣＳのデーモンプログラムがラピュタ・コマース・サーバーＬＣＳのユーザーディレクトリーを検索してキャンセルフラグがあれば、自分のデータベースＤＢにキャンセルフラグを立てる（ＳＴ１３３）。
【００７１】
サイバー・ショップ・サーバーＣＳＳのデーモンプログラムが、ラピュタ・コマース・サーバーＬＣＳのユーザーディレクトリーを検索して、キャンセルフラグがあれば、自分のデータベースＤＢにキャンセルフラグを立てる（ＳＴ１３４）。
【００７２】
このようにしてそれぞれのサーバーＥＷＳ、ＴＣＳ、ＣＳＳにおいてキャンセルフラグの処理がなされ、ラピュタ・コマース・サーバーＬＣＳのデーモンプログラムが各サーバーのデータベースを検索してキャンセルフラグがあれば、ユーザーディレクトリーの仮ファイルを削除し、データベースＤＢにキャンセルを登録する（ＳＴ１３５）。
【００７３】
従って、サイバー・ショップ・サーバーＣＳＳは、ユーザーＵＲの商品発注に対するキャンセル処理を、ラピュタ・コマース・サーバーＬＣＳにおけるデータフィールドの喪失と自己のデータベースにおけるデータフィールドの存在とで検知するようにし、この検知した後においては更に出荷前と出荷後の２段階に分けてキャンセル処理を行うようにして消費者を保護するようにしてある。
【００７４】
図５は、キャンセル処理によるサイバー・ショップ・サーバーＣＳＳの対応を示したブロックフロー図である。
【００７５】
サイバー・ショップ・サーバーＣＳＳのデーモンプログラムが、ラピュタ・コマース・サーバーＬＣＳのユーザーディレクトリーを検索して、キャンセルフラグがあれば、自分のデータベースＤＢにキャンセルフラグを立てる（ＳＴ１３６）。
【００７６】
出荷前であれば、自分のデータベースに出庫データがなければ、データベースＤＢの当該データを削除する（ＳＴ１３７）。
【００７７】
そしてサイバー・ショップ・サーバーＣＳＳのＣＡＬＳの在庫データベースにキャンセル在庫として登録する（ＳＴ１３８）。
【００７８】
出荷後であれば、自分のデータベースＤＢに、当該データについての出庫データがあれば、ラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索し、当該データについての返品配送完了フラグがあれば、自己のデータベースＤＢの当該データ全てを削除する（ＳＴ１３９）。
【００７９】
キャンセルフラグがあれば、自分のデータベースの当該取引に関するファイルを削除し、なければなにもしない（ＳＴ１４０、ＳＴ１４１）。
【００８０】
さらに、トランスポート・カンパニー・サーバーＴＣＳにおいては、このキャンセル処理のデータを取得した後において、出荷前と出荷後と配送中の３段階に分けてキャンセル処理を行うようにして、消費者の保護を図った構成となっている。
【００８１】
図６は、キャンセル処理におけるトランスポート・カンパニー・サーバーＴＣＳの対応を示したブロックフロー図である。
【００８２】
トランスポート・カンパニー・サーバーＴＣＳのデーモンプログラムがラピュタ・コマース・サーバーＬＣＳのユーザーディレクトリーを検索して、キャンセルフラグがあれば自分のデータベースＤＢにキャンセルフラグを立てる（ＳＴ１４２）。
【００８３】
集荷前であれば、データベースＤＢに集荷済フラグがなければ、デーモンプログラムが６時間後に自分のデータベースＤＢの当該集荷データを削除する（ＳＴ１４３）。
【００８４】
集荷後であれば、データベースＤＢに集荷フラグが有り、且つ出荷フラグがなければ、返品配送フラグを立てる（ＳＴ１４４）。
【００８５】
そして、返品配達済みを入力し、データベースＤＢに返品配送済フラグを立てる（ＳＴ１４５）。
【００８６】
ラピュタ・コマース・サーバーＬＣＳのデーモンプログラムがトランスポート・カンパニー・サーバーＴＣＳのデータベースＤＢを検索し、返品配達済フラグが有れば、データベースＤＢに返品配達済フラグを立てる（ＳＴ１４６）。
【００８７】
エレクトロニック・ウオレット・サーバーＥＷＳのデーモンプログラムがラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索して、返品配達済フラグがあれば、預託解除フラグを立てる（ＳＴ１４７）。
【００８８】
ラピュタ・コマース・サーバーＬＣＳのデーモンプログラムがエレクトロニック・ウオレット・サーバーＥＷＳのデータベースＤＢを検索して預託解除フラグがあれば、当該データの仮ファイルを削除し、データベースＤＢにキャンセルを登録する（ＳＴ１４８）。
【００８９】
又、バンクサーバーのデーモンプログラムがエレクトロニック・ウオレット・サーバーＥＷＳのデータベースＤＢを検索して預託解除フラグがあれば、当該データの預託を解除する（ＳＴ１４９）。
【００９０】
そして、エレクトロニック・ウオレット・サーバーＥＷＳがバンクサーバーのデータベースＤＢを検索して、預託解除フラグデータの預託が解除されていれば、自己のデータベースＤＢの当該データを削除する（ＳＴ１５０）。
【００９１】
図７〜図１３はクーリングオフシステムを示したブロックフロー図である。
【００９２】
クーリングオフシステムは、法で定められた最低のクーリングオフ期間を持つ通販問題対策に設けられた消費者保護と最終的な商品の存在を証明するためのシステム、即ち、通販等により消費者が商品を直接確認することなく購入した場合、その商品が消費者のイメージと異っていたり、破損・汚損があった場合にはクーリングオフ期間内であれば無条件に返品できるシステムであり、本発明においてはこの返品することを拡張して独自の期間設定を行なうと同時に最終的な商品の存在の証明にも援用している。
【００９３】
即ち、クーリングオフシステムはトランスポート・カンパニー・サーバーＴＣＳによるユーザーＵＲへの商品の配達証明発行後から、各商品固有の性能・性質に基づいて設定されているガイドラインに従って、サイバー・ショップ・サーバーを提供・維持・管理する企業又は個人が各商品固有の性能・性質に基づいて設定されているクーリングオフ期間の終了まで機能するようにしたことである。
【００９４】
このクーリングオフシステムは、ユーザーＵＲが商品の返品の際に行うクーリングオフ申請によるキャンセル処理手段と、ユーザーＵＲからの再送依頼により商品の再送を行う再送請求処理手段と、クーリングオフ期間外処理手段と、トランスポート・カンパニー・サーバーＴＣＳにおける配達終了に基づくクーリングオフ解除期日算定手段と、トランスポート・カンパニー・サーバーＴＣＳにおける商品の配達終了期間に基づくクーリングオフ警報手段と、ユーザーからのクーリングオフの中止を処理するクーリングオフ中止手段と、クーリングオフ期間に基づいて前記ユーザーの手元に届いた商品の返品処理を行うクーリングオフの検品処理手段とから構成されている。
【００９５】
クーリングオフシステムにおけるクーリングオフ期間の終了が、商品が前記ユーザーの発注商品と同一であることをユーザー本人が確認したものとみなして、最終的な商品の存在の証明が行われたものとするようにしてある。
【００９６】
図７は、ユーザーＵＲが商品の返品の際に行うクーリングオフ申請によるキャンセル処理手段を示したブロックフロー図である。
【００９７】
先ず、ユーザＵＲがラピュタホームページのクーリングオフ書式により、商品を返品したい旨、即ちクーリングオフ申請をラピュタ・コマース・サーバーＬＣＳにリクエストすると、ラピュタ・コマース・サーバーＬＣＳのＣＧＩが注文書仮ファイルをユーザーディレクトリー及びデータベースＤＢに登録する（ＳＴ１５１）。
【００９８】
ラピュタ・コマース・サーバーＬＣＳのデーモンプログラムは、クーリングオフ申請がクーリングオフ期間内か否かのチエックをする（ＳＴ１５２）。
【００９９】
期間外であればクーリングオフ期間外処理ルーチン（クーリングオフ期間外処理手段）に行き、クーリングオフ期間内であれば、デーモンプログラムがクーリングオフのフラグを仮ファイルとデータベースＤＢに立てる（ＳＴ１５３、ＳＴ１５４）。
【０１００】
クーリングオフのフラグが立つと、さまざまなサーバーが動き出す。先ず、エレクトロニック・ウオレット・サーバーＥＷＳのクーロンプログラムがラピュタ・コマース・サーバーＬＣＳのクーリングオフフラグを抽出し、自分のデータベースＤＢにクーリングオフフラグを立てる（ＳＴ１５５）。
【０１０１】
サイバー・ショップ・サーバーＣＳＳのクーロンンプログラムがラピュタ・コマース・サーバーＬＣＳのクーリングオフフラグを抽出し、自分のデータベースＤＢにクーリングオフフラグを立てる（ＳＴ１５６）。
【０１０２】
トランスポート・カンパニー・サーバーＴＣＳのクーロンプログラムがラピュタ・コマース・サーバーＬＣＳのクーリングオフフラグを抽出し、自分のデータベースＤＢにクーリングオフフラグを立てる（ＳＴ１５７）。
【０１０３】
そして、トランスポート・カンパニー・サーバーＴＣＳの端末のプラウザにクーリングオフフラグが立てられたデータを表示する（ＳＴ１５８）。
【０１０４】
このような作業（ＳＴ１５５〜ＳＴ１５８）を終了後、ラピュタ・コマース・サーバーＬＣＳのクーロンプログラムが「クーリングオフ解除期日」に達した注文ファイルをピックアップし、クーリングオフフラグを削除し、解除する（ＳＴ１５９）。
【０１０５】
また、エレクトロニック・ウオレット・サーバーＥＷＳのクーロンプログラムが新しい「クーリングオフ解除期日データ」を検索し、自分のデータベースＤＢに期日を登録する（ＳＴ１６０）。
【０１０６】
エレクトロニック・ウオレット・サーバーＥＷＳのクーロンプログラムがラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索して、クーリングオフの解除を検知すると、自分のデータベースＤＢ内の「クーリングオフ期日」のデータと照合し、「期日データ」以降の日付ならば「預託解除・決済フラグ」を立てる（ＳＴ１６１）。
【０１０７】
ステップＳＴ１５７において、トランスポート・カンパニー・サーバーＴＣＳがクーリングオフのフラグを立てると、運送会社がデータベースに返品配達の完了を登録し、運送会社の集荷・配送システムにデータを渡す（ＳＴ１６２、ＳＴ１６３）。
【０１０８】
そして、ラピュタ・コマース・サーバーＬＣＳのクーロンプログラムがトランスポート・カンパニー・サーバーＴＣＳのデーターベースＤＢを検索して、「返品配達完了」の登録があれば、データベースＤＢに「返品配達完了」のフラグを立てる（ＳＴ１６４）。
【０１０９】
返品された商品は、サイバー・ショップ・サーバーＣＳＳにて、申請の商品であるか否かの検品処理がなされ、データベースＤＢにフラグを立てる（ＳＴ１６５）。
【０１１０】
ラピュタ・コマース・サーバーＬＣＳのクーロンプログラムがサイバー・ショップ・サーバーＣＳＳのデータベースを検索し、返品された商品の「真」、「偽」のフラグを読み込む（ＳＴ１６６）。
【０１１１】
「偽」の場合は、受理できない旨のメールを発送し、クレーム処理担当者にデータを渡す。「真」の場合は、ステップＳＴ１６４の「返品配達完了」のフラグにより、返品配達が完了し、且つ返品された商品が真であることを確認して、エレクトロニック・ウオレット・サーバーＥＷＳのクーロンプログラムがラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索し、上記フラグを検索して見つけると「預託解除・キャンセル」のフラグを立てる（ＳＴ１６７）。
【０１１２】
そして、ラピュタ・コマース・サーバーＬＣＳのクーロンプログラムがエレクトロニック・ウオレット・サーバーＥＷＳのデータベースＤＢを検索して、「預託解除・キャンセルフラグ」を発見すれば、仮ファイルを削除する（ＳＴ１６８）。
【０１１３】
また、ステップＳＴ１６１での照合、及びステップＳＴ１６７により、バンクサーバーのデーモンプログラムがデータベースＤＢから「預託解除・決済フラグ」若しくは「預託解除・キャンセルフラグ」を見つけると、預託を解除し、送金若しくは送金手続を行う（ＳＴ１６９）。
【０１１４】
また、ユーザーＵＲのメタタグプログラムがラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索して、「返品配達完了」のフラグ、及び「返品された商品が真である」フラグを見つけるとインジケータを点滅させる（ＳＴ１７０）。
【０１１５】
そして、ユーザーＵＲが「了解」を入力すると、クーリングオフ書式を削除若しくは停止して点滅を停止する（ＳＴ１７１、ＳＴ１７２）。
【０１１６】
さらに、ラピュタ・コマース・サーバーＬＣＳのクーロンプログラムがデータベースを検索して「返品配達完了」のフラグ及び「返品された商品が真である」フラグを見つけると、「返品が完了し、クーリングオフ処理が終了した旨」のメッセージをユーザーに送付する（ＳＴ１７３）。
【０１１７】
図８は、ユーザーＵＲからの再送依頼により商品の再送を行う再送請求処理手段を示したブロックフロー図である。
【０１１８】
再送請求をするクーリングオフ処理ユニットは、クーリングオフの一環として、商品の間違いや、破損、汚損等があった場合に、商品を返品し、再度送付を依頼するためのシステムである。
【０１１９】
先ず、ユーザーＵＲがクーリングオフ書式（ＪＡＶＡ）によって商品の再度依頼を行う。この時に入力する内容は、納入日、再送品希望配送日時、品番、数量、金額、請求原因（例示より数字で選択する、その他である（ＳＴ１７５）。
【０１２０】
ラピュタ・コマース・サーバーＬＣＳはデーモンプログラムによってデータベースＤＢを検索し、「該当する商品の有無」と「クーリングオフ期間内外」のチエックを行う（ＳＴ１７６）。
【０１２１】
そして、クーリングオフ期日外であればクーリングオフ期間外処理システムのルーチンにゆく（ＳＴ１７７）。
【０１２２】
期日内であればラピュタ・コマース・サーバーＬＣＳより品名を添えて確認のメッセージをユーザーＵＲに送付し、ユーザーＵＲは了解、又は変更の入力ができる（ＳＴ１７８、ＳＴ１７９）。
【０１２３】
ユーザーＵＲが了解すると、ラピュタ・コマース・サーバーＬＣＳのデーモンプログラムが、これまでの仮ファイルを削除して、新規の仮ファイルを作成してデータベースＤＢに新規の注文書（データフィールド）を作成し、それぞれに「再送請求フラグ」を立て、図２に示した預託システムにゆき商品発送の処理を行う（ＳＴ１８１）。
【０１２４】
一方、返品された商品は、サイバー・ショップ・サーバーＣＳＳにて、申請の商品か否かの検品作業を行い、データベースＤＢにフラグを立てる（ＳＴ１８２）。
【０１２５】
ラピュタ・コマース・サーバーＬＣＳのクーロンプログラムがサイバー・ショップ・サーバーＣＳＳのデータベースＤＢを検索し、「真」、「偽」のフラグを読み込む（ＳＴ１８３）。
【０１２６】
「真」であればラピュタ・コマース・サーバーＬＣＳが注文書の作成及び「再送請求フラグ」を立て、図２で示した預託システムに行き商品発送の処理を行う（ＳＴ１８１）。
【０１２７】
「偽」であれば受理できない旨のメール及びクレーム処理担当者にデータを渡す（ＳＴ１８４）。
【０１２８】
図９は、クーリングオフ期間外処理手段であるクーリングオフ期間外処理システムを示すブロックフロ図である。
【０１２９】
先ず、ラピュタ・コマース・サーバーＬＣＳのデーモンプログラムが「クーリングオフ不可フラグ」を仮ファイルとデータベースＤＢに立てていることが前提となる（ＳＴ１８５）。
【０１３０】
ユーザーＵＲのメタタグがクーリングオフ不可フラグを検出すると、ユーザーＵＲのラピュタホームページのインジケータを点滅させると同時に、クーリングオフ不可の旨のインフオメーションを表示し、了解を求める（ＳＴ１８６）。
【０１３１】
同時に、ラピュタ・コマース・サーバーＬＣＳのデーモンプログラムがユーザーＵＲにメールを発送する（ＳＴ１８７）。
【０１３２】
ここで、ユーザーＵＲがインフオメーションに対する回答を入力する（ＳＴ１８８）。
【０１３３】
同意しない場合は、ユーザーＵＲの残高を表示し、購入額が残高を超えていることを開示して、再度回答を促す（ＳＴ１８９）。
【０１３４】
了解した場合にはラピュタ・コマース・サーバーＬＣＳのデーモンプログラムがクーリングオフフラグ及びクーリングオフ不可フラグを削除して決済処理に行く（ＳＴ１９０、ＳＴ１９１）。
【０１３５】
図１０は、トランスポート・カンパニー・サーバーＴＣＳにおける配達終了に基づくクーリングオフ解除期日算定手段であるクーリングオフの解除期日算定ユニットを示したブロックフロー図である。
【０１３６】
クーリングオフの解除期日算定ユニットにおいては、先ずトランスポート・カンパニー・サーバーンスポーターサーバーＴＣＳにおけるデータベースＤＢに、配送が終了したことを登録する（ＳＴ１９５）。
【０１３７】
ラピュタ・コマース・サーバーＬＣＳのクーロンプログラムがトランスポート・カンパニー・サーバーＴＣＳのデータベースＤＢを検索して、新規の配送終了データがあれば、データベースＤＢに対して「配達終了フラグ」を立てる（ＳＴ１９６）。
【０１３８】
そして、ラピュタ・コマース・サーバーＬＣＳのクーロンプログラムがクーリングオフ解除期日算定をし、データベースＤＢに期日を登録する（ＳＴ１９７）。
【０１３９】
また、ラピュタ・コマース・サーバーＬＣＳのクーロンプログラムはクーリングオフ警報発令期日の算定をし、データベースＤＢに期日を登録する（ＳＴ１９８）。
【０１４０】
図１１は、トランスポート・カンパニー・サーバーＴＣＳにおける商品の配達終了期間に基づくクーリングオフ警報手段であるクーリングオフ警報システムを示したブロックフロー図である。
【０１４１】
クーリングオフ警報システムは、ユーザーＵＲが返品する時に申請するクーリングオフ申請をしてクーリングオフフラグを立て、ラピュタ・コマース・サーバーがこのクーリングオフフラグが立っていることを検出すると警報発令期日とクーリングオフ解除期日を算定する。この警報発令期日に達した注文ファイルをピックアップして警報フラグを立て、ユーザーＵＲがこのクーリングオフフラグが立っていることを検出すると、クーリングオフフラグが立っていることをユーザーＵＲがビジュアルで確認できるようにすると共に、了解、クレーム、クーリングオフの中止の３通りで対応できるようにしてある。
【０１４２】
そして、ユーザーＵＲが対応できるクレームは、ユーザーＵＲが既に返品配送済の段階において発行するものであり、ラピュタ・コマース・サーバーＬＣＳにクレームフラグを立てると同時に、トランスポート・カンパニー・サーバーＴＣＳに別途メールで通知するようにし、且つトランスポート・カンパニー・サーバーＴＣＳがこのクレームを検出するとクレームフラグを立て、トランスポート・カンパニー・サーバーＴＣＳがこのクレームフラグを検出する。するとクレームフラグが立っていることをトランスポート・カンパニー・サーバーＴＣＳがビジュアルで確認できるようになっている。以下、図１１のブロックフロー図で説明する。
【０１４３】
先ず、ラピュタ・コマース・サーバーＬＣＳのクーロンプログラムがユーザーＵＲが立てた新しいクーリングオフフラグを検出すると、「警報発令期日」と「クーリングオフ解除期日」を算定し、その結果をデータベースＤＢに登録する（ＳＴ２００）。
【０１４４】
ラピュタ・コマース・サーバーＬＣＳのクーロンプログラムが「警報発令期日」に達した注文ファイルをピックアップし、データベースＤＢに「警報フラグ」を立てる（ＳＴ２０１）。
【０１４５】
又は、トランスポート・カンパニー・サーバーＴＣＳが「返品の配送済フラグ」を自分のデータベースＤＢに立てていることが前提となる（ＳＴ２０２）。
【０１４６】
ラピュタ・コマース・サーバーＬＣＳのデーモンプログラムがトランスポート・カンパニー・サーバーＴＣのデータベースＤＢの「返品配送済フラグ」を見つけると、ラピュタ・コマース・サーバーＬＣＳのデータベースＤＢに「返品配送済フラグ」を立て、同時に「警報フラグ」を削除する（ＳＴ２０３）。
【０１４７】
ユーザーＵＲのメタタグプログラムがラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索し、そのデータの中に「警報フラグ」を見つけるとインジケータを点滅させる。インジケータをクリックすると了解書式を表示する（ＳＴ２０４）。
【０１４８】
ここで、ユーザーＵＲは、「了解」、「クーリングオフの中止」、「クレーム処理」の３通りのいずれかを入力することができる（ＳＴ２０５）。
【０１４９】
ユーザーＵＲが「了解」を入力すると、ユーザーＵＲに供給されている書式の中のブリンクコマンドの削除若しくは停止により点滅は停止する（ＳＴ２０６）。
【０１５０】
「クーリングオフの中止」を入力すると、クーリングオフ中止書式を選択し、クーリングオフ中止システムのルーチンに行く（ＳＴ２０７）。
【０１５１】
「クレーム処理」を入力すると、ユーザーＵＲがクレーム書式を選択し、配送番号と配送日時を入力する（ＳＴ２０８）。
【０１５２】
そうすると、ラピュタ・コマース・サーバーＬＣＳの仮ファイル及びデータベースＤＢにクレームフラグを立てると同時に、運送会社にメールにて通知する（ＳＴ２０９）。
【０１５３】
トランスポート・カンパニー・サーバーＴＣのデーモンプログラムがラピュタ・コマース・サーバーＬＣＳの仮ファイルのクレームフラグを見つけるとトランスポート・カンパニー・サーバーＴＣＳの端末に警報をブリンクさせる（ＳＴ２１０）。
【０１５４】
同時に、トランスポート・カンパニー・サーバーＴＣＳにメールを送付し、トランスポート・カンパニー・サーバーＴＣはクレーム処理担当に処理を移行する（ＳＴ２１１、ＳＴ２１２）。
【０１５５】
図１２は、ユーザーＵＲからのクーリングオフの中止を処理するクーリングオフ中止手段であるクーリングオフ中止システムを示したブロックフロー図である。
【０１５６】
クーリングオフ中止は、ユーザーＵＲがクーリングオフを申請したにも関わらず未だに返品発送を行っていない段階において発行されるものであり、ユーザーＵＲがクーリングオフを中止して当該商品が発注商品と同一であることを認定した場合に発行され、ユーザーＵＲがラピュタ・コマース・サーバーＬＣＳにクーリングオフ中止フラグを立てるようにリクエストを発行することによって、トランスポート・カンパニー・サーバーＴＣＳがこのクーリングオフ中止フラグを検出すると商品の配送プランを組み替えるようにする。
【０１５７】
又、エレクトロニック・ウオレット・サーバーＥＷＳ及びサイバー・ショップ・サーバーＣＳＳは、クーリングオフ中止フラグを検出すると、クーリングオフフラグを削除する。以下、図１２のブロックフロー図で説明する。
【０１５８】
ユーザーＵＲが「クーリングオフ中止」書式によりラピュタ・コマース・サーバーＬＣＳにクーリングオフ中止をリクエストする（ＳＴ２１５）
【０１５９】
すると、ラピュタ・コマース・サーバーＬＣＳのＣＧＩがデータベースＤＢ及び仮ファイルに「クーリングオフ中止フラグ」を立てる（ＳＴ２１６）。
【０１６０】
トランスポート・カンパニー・サーバーＴＣのデーモンプログラムがラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索し、「クーリングオフ中止フラグ」を見つけると、自分のデータベースＤＢの「クーリングオフフラグ」を削除し、「クーリングオフ中止フラグ」を立てる（ＳＴ２１７）。
【０１６１】
同時に、エレクトロニック・ウオレット・サーバーＥＷＳのデーモンプログラムがラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索し、「クーリングオフ中止フラグ」を見つけると自分のデータベースＤＢの「クーリングオフフラグ」を削除する（ＳＴ２１８）。
【０１６２】
同時に、サイバー・ショップ・サーバーＣＳＳのデーモンプログラムがラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索し、「クーリングオフ中止フラグ」を見つけると自分のデータベースＤＢの「クーリングオフフラグ」を削除する（ＳＴ２１９）。
【０１６３】
ラピュタ・コマース・サーバーＬＣＳのデーモンプログラムが各サーバーのデータベースＤＢを検索し、自分のデータベースＤＢの「クーリングオフ中止フラグ」を立てられたデータに相当するデータについてクーリングオフフラグが削除されているかどうかをチエックし、全て削除されていればラピュタ・コマース・サーバーＬＣＳのデーモンプログラムは仮ファイルから「クーリングオフ中止フラグ」を削除する（ＳＴ２２０）。
【０１６４】
一方、トランスポート・カンパニー・サーバーＴＣＳは、デーモンプログラムがデータベースＤＢの「クーリングオフ中止フラグ」を検出すると、配送プランを組み替える（ＳＴ２２１）。
【０１６５】
集荷当日の場合は、デーモンプログラムが配送車に電話若しくはメールで通報する。トランスポート・カンパニー・サーバーＴＣＳのデーモンプログラムは「クーリングオフ中止フラグ」を削除する（ＳＴ２２２、ＳＴ２２３）。
【０１６６】
図１３は、クーリングオフ期間に基づいてユーザーＵＲの手元に届いた商品の返品処理を行うクーリングオフの検品処理手段であるクーリングオフの検品処理ユニットを示したブロックフロー図である。
【０１６７】
クーリングオフの検品処理手段は、発注した商品がユーザーＵＲの手元に届いてから返品理由フラグを立てるようにしてある。この返品理由フラグは、商品間違い、破損・汚損、商品が予想と違っていた、その他の４種類からなり、それぞれのフラグはサイバー・ショップ・サーバーＣＳＳ内からの商品を、クーリングオフ申請に基づいて返品用商品の検品をするようになっている。
【０１６８】
又、このクーリングオフの検品処理手段は、返品用商品がクーリングオフ申請した期間内であって、破損・汚損の場合は運送中の破損・汚損又は配送する際の検品漏れ又は故意によるものかの判別をし、この運送中の破損・汚損又は配送する際の検品漏れの場合は再送するようになっている。
【０１６９】
そして、クーリングオフの検品処理手段は、返品用商品がクーリングオフ期間内であって、商品が予想と違っていた又はその他の理由の場合は、この商品の破損・汚損の有無を識別し、破損・汚損の場合は運送中の破損・汚損又は配送する際の検品漏れ又は故意によるものかの判別をし、この運送中の破損・汚損又は配送する際の検品漏れの場合は再送するようにしてある。以下、図１３のブロックフロー図で説明する。
【０１７０】
先ず、サイバー・ショップ・サーバーＣＳＳがラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索して、クーリングオフ申請物件から「返品理由（フラグ）」を読み込む（ＳＴ２２５）。
このフラグは、「商品間違い」、「破損、汚損」、「商品が予想と違っていた」、「その他」の４種類からなる。
【０１７１】
検品する商品が、自社取扱い商品かどうかを検査し、フラグを立て、自社商品の場合は品番を入力する（ＳＴ２２６）。
【０１７２】
非自社商品と認定した場合は、受理できない旨のメールを送付し、クレーム処理担当者にデータを渡す（ＳＴ２２７）。
【０１７３】
自社商品と認定した場合は、サイバー・ショップ・サーバーＣＳＳのデータベースＤＢを検索して品番商品の納入時期を調査し、クーリングオフ期間と比較してクーリングオフ該当商品かどうかをチエックする（ＳＴ２２８）。
【０１７４】
クーリングオフ期間内であって、返品原因が、「商品が予想と違っていた」、「その他の理由による場合」の検品は、破損・汚損の有無を検品し、入力書式により結果を入力する（ＳＴ２２８）。
【０１７５】
破損・汚損が有れば、サイバー・ショップ・サーバーＣＳＳのデータベースＤＢに「破損・汚損フラグ」を追加する（ＳＴ２２９）。
【０１７６】
破損・汚損が無ければサイバー・ショップ・サーバーＣＳＳのデータベースＤＢに返品された商品が「真」であるフラグを立てる（ＳＴ２３０）。
【０１７７】
又、クーリングオフ期間内において、返品原因が「破損・汚損」による場合は、その検品は、破損・汚損の原因を検査し、認定結果を入力書式で入力する（ＳＴ２３１）。
【０１７８】
故意によるものと認定された場合は、対策指示を表示し、受理できない旨のメールを発送し、クレーム担当者にデータを渡す（ＳＴ２３２、ＳＴ２３３）。
【０１７９】
運送中の事故と認定された場合は、運送会社と調整し、不調に終わればクレーム担当者にデータを渡す（ＳＴ２３４、ＳＴ２３５、ＳＴ２３６）。
【０１８０】
保険で対応できることに合意した場合には、入力書式から「真」のフラグをリクエストし、サイバー・ショップ・サーバーＣＳＳのデータベースＤＢに返品された商品が「真」であるフラグを立てる（ＳＴ２３７、ＳＴ２３８）。
【０１８１】
又、不明若しくは検品漏れと認定した場合も、サイバー・ショップ・サーバーＣＳＳのデータベースＤＢに返品された商品が「真」であるフラグを立てる（ＳＴ２３８）。
【０１８２】
ステップＳＴ２２８において、納入実績がない場合には、「納入実績無しフラグ」を立て、受理できない旨のメールを発送と、クレーム担当者にデータを渡す（ＳＴ２３９、ＳＴ２４０）。
【０１８３】
ステップ２２８において、クーリングオフ期間外であれば、メールにてユーザーＵＲに商品を間違えて送付していないかを確認する（ＳＴ２４１）。
【０１８４】
間違えていない場合は、クーリングオフ期間外のフラグを立て、クーリングオフ期間外処理システムに行く（ＳＴ２４２、ＳＴ２４３）。
【０１８５】
ステップ２４１において、商品を間違えて送付した場合は、ユーザーＵＲがクーリングオフフラグ削除をリクエストするか又はサイバー・ショップ・サーバーＣＳＳがクーリングオフフラグ削除をリクエストするかする。そして、ラピュタ・コマース・サーバーＬＣＳのデーモンプログラムが両者を検知すると、クーリングオフフラグを削除し、新規の仮ファイルを作成する。又、データベースＤＢに新規の注文書を作成し、それぞれに再発行フラグを立て、クーリングオフ申請処理に行く（ＳＴ２４４、ＳＴ２４５、ＳＴ２４６、ＳＴ２４７）。
【０１８６】
図１４は、商品の存在を証明した後の決済方法を示したブロックフロー図である。
【０１８７】
商品に対する代金の決済においては、エレクトロニック・ウオレット・サーバーＥＷＳに預託されている金銭を、商品を販売したサイバー・ショップ・サーバーＣＳＳの実際に商品を提供している者の口座に振り込む際に、エレクトロニック・ウオレット・サーバーＥＷＳはラピュタ・コマース・サーバーＬＣＳを介してトランスポート・カンパニー・サーバーＴＣＳからこの商品の配達証明を受け取ることによって、この商品がユーザーＵＲの手元にあることを確認する。且つラピュタ・コマース・サーバーＬＣＳがプログラムにより自動的に算定するクーリングオフ期間の終了を、ラピュタ・コマース・サーバーＬＣＳが確認することにより、ユーザーＵＲがこの商品をユーザーＵＲが発注した商品と同一物であることをユーザーＵＲが承認したものと認め、預託金額をサイバー・ショップ・サーバーＣＳＳの実際に商品を販売している者の口座に振り込むようにする。
【０１８８】
又、エレクトロニック・ウオレット・サーバーＥＷＳは、ラピュタ・コマース・サーバーＬＣＳに預託を解除して商品との決済をしたことを通知し、このラピュタ・コマース・サーバーＬＣＳは決済したことをデータベースＤＢに書き込むと共に当該商品発注のファイルを削除するようにしてある。以下、図１４のブロックフロー図を参照して説明する。
【０１８９】
先ず、トランスポート・カンパニー・サーバーＴＣＳが、データベースＤＢに配達終了が登録してあることが前提となる（ＳＴ２５０）。
【０１９０】
そうすると、ラピュタ・コマース・サーバーＬＣＳのクーロンプログラムがトランスポート・カンパニー・サーバーＴＣＳのデータベースＤＢを検索して新規の配達終了データがあれば、データベースＤＢに「配達終了フラグ」を立てる（ＳＴ２５１）。
【０１９１】
ラピュタ・コマース・サーバーＬＣＳのクーロンプログラムが「配達終了フラグ」を立てられたデータについて、クーリングオフ解除期日の算定をし、データベースＤＢに期日を登録する（ＳＴ２５２）。
【０１９２】
エレクトロニック・ウオレット・サーバーＥＷＳのクーロンプログラムがラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索して、「クーリングオフ解除期日」に達したデータがあれば、自分のデータベースＤＢに「預託解除・決済フラグ」を立てる（ＳＴ１６６）。
【０１９３】
バンクサーバーが、エレクトロニック・ウオレット・サーバーＥＷＳのデータベースＤＢを検索して「預託・決済フラグ」があれば、預託を解除して、サイバー・ショップ・サーバーＣＳＳに送金する（ＳＴ２５４）。
【０１９４】
又、ステップＳＴ１６４から、キャンセルする場合には図７に示すクーリングオフ処理ユニットに行き、再送請求であれば図８に示すクーリングオフ処理ユニットに行く（ＳＴ２５５、ＳＴ２５６）。
【０１９５】
【発明の効果】
以上説明したように本発明に係る電子決済システムは、端末機器を介して行うユーザーと、預託行為を含む金銭出納管理をする単独又は複数のエレクトロニック・ウオレット・サーバーと、商品を取り揃え且つ単独若しくは複数の商品仕入先との受発注管理を行うサイバー・ショップ・サーバーと、商品を自動的な配送及び集荷の情報を収集し、且つ商品の集荷・配送及び管理を行い、配送が完了したことを証明するトランスポート・カンパニー・サーバーと、ユーザーとエレクトロニック・ウオレット・サーバーとサイバー・ショップ・サーバーとトランスポート・カンパニー・サーバーとのそれぞれと個別に通信回線を介して接続し、接続された全体を組織的に統合すると共に取引履歴をデータベース上に記録・保管し、且つクーリングオフシステムにより予め設定されているクーリングオフ期間に基づいて最終的な商品の存在を証明するラピュタ・コマース・サーバーとから構成して、ラピュタ・コマース・サーバーに接続されたそれぞれのユーザーとエレクトロニック・ウオレット・サーバーとサイバー・ショップ・サーバーとトランスポート・カンパニー・サーバーとの相互間の通報、証明、保証をラピュタ・コマース・サーバーを介して行い、且つ商品のキャンセル処理及びクーリングオフ期間に基づく処理を電子仮想空間上において普遍的にルール化して行うようにしたことにより、時空を超えた電子仮想空間における商取引の安全を確保した、いわゆるインターネットに代表される電子仮想空間上の電子商取引に関する受発注管理、物流管理、預託決済管理に基づいて商品とその決済代金との存在を保証することができると云う効果がある。
【図面の簡単な説明】
【図１】本発明に係る全体構成の接続関係を示した説明図である。
【図２】同預託システムを示したブロックフロー図である。
【図３】同電子商取引システムにおける預託通報システムを示したブロックフロー図である。
【図４】同電子商取引システムにおけるキャンセル処理ユニットの納期了承〜配達までを示したブロックフロー図である。
【図５】同電子商取引システムにおけるキャンセル処理におけるサイバー・ショップ・サーバーＣＳＳの対応システムユニットを示したブロックフロー図である。
【図６】同電子商取引システムにおけるキャンセル処理におけるトランスポート・カンパニー・サーバーＴＣの対応システムユニットを示したブロックフロー図である。
【図７】同電子商取引システムにおけるクーリングオフ処理ユニット（１）のキャンセル処理を示したブロックフロー図である。
【図８】同電子商取引システムにおけるクーリングオフ処理ユニット（２）の再送請求を示したブロックフロー図である。
【図９】同電子商取引システムにおけるクーリングオフ処理ユニット（３）のクーリングオフ期間外処理システムを示したブロックフロー図である。
【図１０】同電子商取引システムにおけるクーリングオフの解除期日算定ユニットを示したブロックフロー図である。
【図１１】 同電子商取引システムにおけるクーリングオフ処理ユニット（４）のクーリングオフ警報システムを示したブロックフロー図である。
【図１２】同電子商取引システムにおけるクーリングオフ処理ユニット（５）のクーリングオフ中止システムを示したブロックフロー図である。
【図１３】同電子商取引システムにおけるクーリングオフの検品処理ユニットを示したブロックフロー図である。
【図１４】同電子商取引システムにおける決済処理ユニットを示したブロックフロー図である。
【図１５】従来技術における商取引を示した説明図である。
【符号の説明】
ＵＲ；ユーザー、ＣＳＳ；サイバー・ショップ・サーバー、ＥＷＳ；エレクトロニック・ウオレット・サーバー、ＴＣＳ；トランスポート・カンパニー・サーバー、ＬＣＳ；ラピュタ・コマース・サーバー
Claims (2)
- 通信回線を介して外部のシステムと接続し、
購入者であるユーザーから販売者であるショップに対し商品の注文が行われたという情報と、該ユーザーの該注文に対する決済代金の有無即ち支払い能力の有無に関する情報とを受信して該発注の成立可否を判定し、
決済代金相当額が存在することによって該発注が成立していると判定されれば該ユーザーの決済能力を担保するため該決済代金相当額の預託を指示して決済代金の存在を保証し、
決済代金相当額が存在しないことによって該発注が成立しないと判定されれば、前記注文が成立していない旨を前記ユーザーにメール等で通知し、
前記商品と看做される物即ち発注者である前記ユーザーによって前記注文されたとみなされる何らかの物が該ユーザーに配送されたという情報（配達情報）を受信することで該ユーザーに配送された何らかの物の存在を保証し、同時にその配達情報に含まれる配送日の情報と事前に登録された前記商品に関するクーリングオフ期間（商取引契約の一方的解除可能期間）の情報によって、該配送日から起算したクーリングオフ期日を算定し、
「該配送された物がユーザーの注文した商品であるか否か」という情報を受信することで前記クーリングオフ期日と併せて該ユーザーによって注文され配送された商品の存在を判定し、
前記クーリングオフ期日までに前記商品の真偽に関する情報を受信しないか又は「該配送された前記何らかの物はユーザーの注文した商品である」という情報が受信されれば、該ユーザーによって前記注文され配送された商品が存在すると判定して、担保である前記預託を解除して決済即ち前記預託された決済代金を前記ショップに支払う処理を実行するよう指示を出し、
前記クーリングオフ期日までに「該配送された前記何らかの物はユーザーの注文した商品でない」という情報が受信され、且つ前記クーリングオフ期日までに前記ユーザーからの返品の配送と前記ショップによる商品の受領確認の情報を受信すれば、該ユーザーによって注文され配送された商品は存在しないと判定して、担保である前記預託を解除して返金即ち前記預託された決済代金を前記ユーザーに戻す処理を実行するよう指示を出すようにした
ラピュタ・コマース・サーバーと、
通信回線を介して外部のシステムと接続し、購入者であるユーザーが発注手続、クーリングオフ手続、返品申請手続および金銭出納管理手続を行うための端末機器と、
通信回線を介して外部のシステムと接続し、前記ユーザーが購入する商品を取り揃える前記ショップにおいて、該ショップが商取引に関わる情報を登録・集計するためのサイバー・ショップ・サーバー及びそのクライアント即ち端末機器と、
通信回線を介して外部のシステムと接続し、前記配達情報によって前記サイバー・ショップが発送した商品であるとする前記何らかの物がユーザーに配送されたことを情報的に保証し、該配達情報を前記ラピュタ・コマース・サーバーに通知するトランスポート・カンパニー・サーバー及び該配達情報を入力するためのクライアント即ち端末機器と、
金融機関のサーバー及び前記ラピュタ・コマース・サーバーと通信回線を介して接続し、且つユーザー端末、ショップおよびトランスポート・カンパニーのサーバー若しくは端末と通信回線を介して接続し、前記ラピュタ・コマース・サーバーからの指示によって決済代金の預託の実施・解除を実行すると同時に前記ユーザー、前記ショップ、前記トランスポート・カンパニーのエレクトロニック・ウォレットである口座に対し金銭出納を含む資金管理するためのシステム環境を提供し、決済または返金処理として振込処理を実行または指示するエレクトロニック・ウォレット・サーバーと
から構成され、
前記ユーザーの端末機器に入力された決済金額を含むユーザーの注文情報は、通信回線を介して前記ラピュタ・コマース・サーバーに送信され、該ラピュタ・コマース・サーバーは該ユーザーのエレクトロニック・ウォレットの口座の預金残高情報を前記エレクトロニック・ウォレット・サーバーから取得して預金残高が決済代金以上あるか否か即ち支払い能力の有無を判定し、該ユーザーのエレクトロニック・ウォレットの口座の預金残高が決済代金以上あればその注文情報を前記ラピュタ・コマース・サーバーのデータベースに登録することによって前記ショップ・サーバーに注文情報として通知され、同時に、該ラピュタ・コマース・サーバーは前記エレクトロニック・ウォレット・サーバーに決済代金を担保するための預託を指示し、預金残高が決済代金未満であれば注文不可であることを前記ユーザー端末に通知し、
前記エレクトロニック・ウォレット・サーバーは前記預託指示を受信すると、前記ユーザーの前記エレクトロニック・ウォレットである口座から決済代金相当額を担保するため預託し、
前記トランスポート・カンパニー端末から前記トランスポート・カンパニー・サーバーに配達済情報が入力されると、該トランスポート・カンパニー・サーバーから前記ラピュタ・コマース・サーバーに前記配達済情報が送信されて前記ラピュタ・コマース・サーバーに登録され、
前記ラピュタ・コマース・サーバーは、前記商品配達情報の配達日から起算した前記クーリングオフ期間内に前記ユーザーの端末機器からクーリングオフ申請即ち商品間違いあるいは破損・汚損等の通知があればそれを前記ショップ・サーバーに通知し、
前記商品配達情報の配達日から起算した前記クーリングオフ期間内に前記ユーザー端末から商品間違いあるいは破損・汚損等の通知がなければ前記発注から配達までの商取引が成立したものとして決済指示を前記エレクトロニック・ウォレット・サーバーに通知し、
該エレクトロニック・ウォレット・サーバーは、前記ラピュタ・コマース・サーバーから決済指示を受信すると決済能力を担保するための前記決済代金の預託を解除して前記ショップに支払う即ち前記ショップのエレクトロニック・ウォレットである口座に振り込む処理を実行するようにしたことにより
商取引即ち等価交換の対象物が互いに見えない電子仮想空間上において売り手、買い手の双方に安全な取引即ち交換が成立するようにしたことを特徴とする電子決済システム。 - ラピュタ・コマース・サーバーにおいて前記商品の配達通知の受信後、前記ユーザー端末からの返品要求に伴うクーリングオフ申請を受信した時、ラピュタ・コマース・サーバーは該商品の注文について決済または返金指示が発行されているか否か、または前記クーリングオフ期日以前か否かをチェックし、
該決済または返金指示が未発行または前記クーリングオフ期日以前であれば、前記トランスポート・カンパニー・サーバーからの前記返品要求の対象となっている商品に関する新たな配達証明の受信後、
前記クーリングオフ期日までに「その返品配送された商品が前記ショップの出荷した商品と同一でない」という情報が受信された場合は、該クーリングオフ期日を過ぎるとともに前記エレクトロニック・ウォレット・サーバーに決済指示を通知し、該エレクトロニック・ウォレット・サーバーは、該商品の決済代金の預託を解除し、その預託されていた決済代金を該ショップのエレクトロニック・ウォレットの口座に振り込む処理を指示または実行し、
前記クーリングオフ期日までに「その返品された商品が前記ショップの出荷した商品と同一である」という情報が該ラピュタ・コマース・サーバーに通知された場合または該配達された商品に関し何の通信も入らない場合は該クーリングオフ期日を過ぎるとともに該ラピュタ・コマース・サーバーは前記エレクトロニック・ウォレット・サーバーに前記決済代金を前記ユーザーに返すよう指示を通知し、該エレクトロニック・ウォレット・サーバーは、該商品の決済代金の預託を解除し、その預託されていた決済代金を前記ユーザーのエレクトロニック・ウォレットの口座に振り込む処理を指示または実行し、
該決済または返金指示が発行済または前記クーリングオフ期日以後であれば、前記ラピュタ・コマース・サーバーは前記返品申請が無効である旨の通知をユーザー端末に送信するようにしたことにより
商取引即ち等価交換の対象物が互いに見えない電子仮想空間上において売り手、買い手の双方に安全な取引即ち交換が成立するようにしたことを特徴とする請求項１に記載の電子決済システム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP01296697A JP4300257B2 (ja) | 1997-01-27 | 1997-01-27 | 電子決済システム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP01296697A JP4300257B2 (ja) | 1997-01-27 | 1997-01-27 | 電子決済システム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH10207956A JPH10207956A (ja) | 1998-08-07 |
| JP4300257B2 true JP4300257B2 (ja) | 2009-07-22 |
Family
ID=11819996
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP01296697A Expired - Lifetime JP4300257B2 (ja) | 1997-01-27 | 1997-01-27 | 電子決済システム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4300257B2 (ja) |
Families Citing this family (33)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR100542386B1 (ko) * | 2000-02-15 | 2006-01-10 | 주식회사 신한은행 | 기업간 대금결제 관리 시스템 및 이를 이용한 기업간대금결제 관리 방법 |
| JP2001246142A (ja) * | 2000-03-08 | 2001-09-11 | Sun Corp | 景品交換用情報端末 |
| KR100435854B1 (ko) * | 2000-03-10 | 2004-06-12 | 주식회사 신한은행 | 기업간 대금결제 관리 시스템 및 이를 이용한 기업간대금결제 관리 방법 |
| JP2001338173A (ja) * | 2000-05-29 | 2001-12-07 | Nec Corp | 売買仲介センタ、売買仲介システムおよび売買仲介方法 |
| JP3832710B2 (ja) * | 2000-06-05 | 2006-10-11 | アサヒビール株式会社 | 情報処理装置及び情報処理方法 |
| JP2002083241A (ja) * | 2000-06-30 | 2002-03-22 | Aozora Bank Ltd | 財貨決済装置、財貨決済システム、財貨決済方法および情報記録媒体 |
| JP4257023B2 (ja) | 2000-08-10 | 2009-04-22 | 日本電気株式会社 | 商品販売支援システム及び方法 |
| JP2002063523A (ja) * | 2000-08-22 | 2002-02-28 | Isola Barrier Free Co Ltd | 決済システム |
| WO2002017168A1 (en) * | 2000-08-25 | 2002-02-28 | Hironori Wakayama | Electronic commercial transaction system |
| JP2002140644A (ja) * | 2000-10-31 | 2002-05-17 | Time World:Kk | 電子商取引方法及び口座引落とし方法 |
| JP4678088B2 (ja) * | 2000-11-02 | 2011-04-27 | セイコーエプソン株式会社 | 在庫戻しシステムおよび在庫戻し処理方法 |
| JP2002149749A (ja) * | 2000-11-14 | 2002-05-24 | Yuichi Takami | コンピュータ双方向通信網による環境対策建築用品の取引・情報提供取得の方法及びその通信システム並びに情報記録媒体 |
| JP2002189882A (ja) * | 2000-12-20 | 2002-07-05 | Vires:Kk | 決済システム |
| US7266513B2 (en) | 2001-03-14 | 2007-09-04 | United Parcel Service Of America, Inc. | System and method for initiating returns over a network |
| JP2002334288A (ja) * | 2001-05-11 | 2002-11-22 | Nec Software Chubu Ltd | 携帯電話による商品代金支払いシステム、及び商品代金支払い方法 |
| US7765131B2 (en) | 2006-06-20 | 2010-07-27 | United Parcel Service Of America, Inc. | Systems and methods for providing personalized delivery services |
| CA2957168C (en) | 2005-06-21 | 2019-10-01 | United Parcel Service Of America, Inc. | Systems and methods for providing personalized delivery services |
| WO2008083383A2 (en) | 2006-12-30 | 2008-07-10 | Cfph, Llc | Methods and systems for managing and trading using a shared order book as internal exchange |
| US9916557B1 (en) | 2012-12-07 | 2018-03-13 | United Parcel Service Of America, Inc. | Systems and methods for item delivery and pick-up using social networks |
| US11144872B2 (en) | 2012-12-21 | 2021-10-12 | United Parcel Service Of America, Inc. | Delivery to an unattended location |
| US10387824B2 (en) | 2012-12-21 | 2019-08-20 | United Parcel Service Of America, Inc. | Systems and methods for delivery of an item |
| US10445682B2 (en) | 2013-02-01 | 2019-10-15 | United Parcel Service Of America, Inc. | Systems and methods for parcel delivery to alternate delivery locations |
| US10521761B2 (en) | 2013-03-12 | 2019-12-31 | United Parcel Service Of America, Inc. | Systems and methods of delivering parcels using attended delivery/pickup locations |
| US20150066795A1 (en) | 2013-08-30 | 2015-03-05 | United Parcel Service Of America, Inc. | Systems, methods, and computer program products for providing a customized content exchange platform between two or more parties |
| US10664787B2 (en) | 2013-10-09 | 2020-05-26 | United Parcel Service Of America, Inc. | Customer controlled management of shipments |
| CA2926985C (en) | 2013-10-14 | 2022-06-07 | United Parcel Service Of America, Inc. | Systems and methods for conveying a parcel to a consignee, for example, after an unsuccessful delivery attempt |
| US10002340B2 (en) | 2013-11-20 | 2018-06-19 | United Parcel Service Of America, Inc. | Concepts for electronic door hangers |
| EP3105722A1 (en) | 2014-02-16 | 2016-12-21 | United Parcel Service Of America, Inc. | Determining a delivery location and time based on the schedule or location of a consignee |
| US10733563B2 (en) | 2014-03-13 | 2020-08-04 | United Parcel Service Of America, Inc. | Determining alternative delivery destinations |
| CA2967064C (en) | 2014-11-14 | 2020-08-25 | United Parcel Service Of America, Inc. | Systems and methods for facilitating shipping of parcels for returning items |
| US10410164B2 (en) | 2014-11-14 | 2019-09-10 | United Parcel Service Of America, Inc | Systems and methods for facilitating shipping of parcels |
| US10600022B2 (en) | 2016-08-31 | 2020-03-24 | United Parcel Service Of America, Inc. | Systems and methods for synchronizing delivery of related parcels via a computerized locker bank |
| CN114493672A (zh) * | 2021-12-30 | 2022-05-13 | 广州趣丸网络科技有限公司 | 虚拟物品的发放方法及系统 |
-
1997
- 1997-01-27 JP JP01296697A patent/JP4300257B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JPH10207956A (ja) | 1998-08-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4300257B2 (ja) | 電子決済システム | |
| CA2504285C (en) | Alternate delivery location methods and systems | |
| US7310611B2 (en) | Order processing system and method | |
| JP3560327B2 (ja) | ロッカーシステム | |
| JPH10162066A (ja) | 電子取引支援方法 | |
| US7181418B1 (en) | Internet customer service method and system | |
| WO2002019233A9 (en) | Apparatus and method for ensuring availability of inventory for electronic commerce | |
| JP2001282899A (ja) | 貨物の受注方法と発注方法、集中物流管理方法、集中物流管理装置、集中物流管理システム、貨物保険情報作成方法、貨物保険情報作成装置、貨物保険情報作成システム、船荷証券用ドラフトの自動作成方法、船荷証券用ドラフト情報の自動作成装置および船荷証券自動発行システム | |
| JP2022031627A (ja) | 情報処理装置、情報処理方法、及びプログラム | |
| US20030061486A1 (en) | Electronic commerce information processing system and method | |
| US20060026097A1 (en) | Method and apparatus for verifying a financial instrument | |
| CN1388941A (zh) | 销售和交付商品的方法及设备 | |
| JP2002157541A (ja) | 携帯電話を利用した商品配送システム、商品配送方法及び記録媒体 | |
| JP2002312446A (ja) | 船荷証券の発行方法、船荷証券の発行装置、船荷証券発行システム、貨物トラッキング情報の検索方法、貨物トラッキング情報の検索システム、貨物の物流費請求方法、貨物の請求書発行システム、貨物代金決済方法、貨物代金検索システムおよび物流業者選定システム | |
| JP3955063B2 (ja) | 集配警備現金管理システム | |
| WO2002017168A1 (en) | Electronic commercial transaction system | |
| JP2003203163A (ja) | 電子商取引市場における企業間取引情報の仲介方法、その方法に用いられるサーバーおよび端末 | |
| JP2005284907A (ja) | 代金支払方法及び代金支払プログラム | |
| JP2002183621A (ja) | コンピュータ端末を用いた車両のレンタル支援方法及び車両レンタル支援システム | |
| KR100651790B1 (ko) | 통신망을 통한 ａ/ｓ 방법 및 시스템 | |
| JP2002132866A (ja) | 製品生涯カードおよびその運用方法 | |
| JP3878156B2 (ja) | 物品引渡し管理用ｕｒｌアダプタと物品引渡しシステムとプログラム | |
| EP1154364A1 (en) | Internet customer service method and system | |
| KR20010094823A (ko) | 결제보증에 의한 원격지상거래 대금결제방법 및 시스템 | |
| JP2003006746A (ja) | 販売管理システムにおける売上登録からの仕入の自動登録方法および販売管理システム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20081201 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090225 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090406 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20170501 Year of fee payment: 8 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20170501 Year of fee payment: 8 |
|
| EXPY | Cancellation because of completion of term |