【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、電子決済システムに関し、特に仮想空間領域において、遠隔での商品の発注と、発注商品との決済及び実際に商品を配送をするセキュリテイを確保した電子商取引を構築する電子決済システムに関するものである。

【０００２】

【従来の技術】従来から流通している、決済システムは、図１５に示すように、ユーザーとＥＣ（Ｅｒｃｔｒ
ｏｎｉｃ Ｃｏｍｍｅｒｃｅ）間において商取引を行うもので、決済時期が３種類に分類される。

【０００３】第１の分類は、図１５（イ）に示すように、決済時期が配送時の場合であり、ユーザーがＥＣに発注すると、ＥＣ側から、ユーザーに自己配達をし、且つ配送時において代金を回収するシステムである。

【０００４】第２の分類は、図１５（ロ）に示すように、ユーザー側からＥＣに対して予約をして物品を購入する手法であり、この場合の決済時期は、例えばユーザーが来店した時に決済する。

【０００５】第３の分類は、図１５（ハ）に示すように、ユーザーからＥＣに発注すると、ＥＣ側から物品が配送され、且つ請求書も発行される。 この決済時期は、
数ヶ月以内に自動引落し、月次決済、発生時に決済する等がある。

【０００６】このような３種類に分類される決済システムにおいて商品を購入するためには社会に流通している貨幣又は電子マネーがある。

【０００７】電子マネーは、クレジットタイプのもの、
ネットワークタイプのもの、ネットワークとＩＣカードを組み合わせたもの、ＩＣカードタイプのものがあり、
これらは、全て社会に流通している貨幣の代用として使用される。 例えば、ＩＣカードでの商品の購入は、所望の商品を特定したときに、ＩＣカードがその代金を支払ったようにして、後日別のルートにより、ＩＣカードで支払った代金の決済を上記決済システムの手法により行う。

【０００８】このようなＩＣカードの他に、現在のクレジットカードと同様に現金社会の中で使用するＩＣカードによる決済がある。 いわゆるモンデックス型といわれるＩＣカードによる決済は、先ず銀行等の金融機関と契約してエレクトロニック・ウオレット・サーバー用口座を開設して入金する。 そして、暗証番号及び暗号鍵を内蔵したＩＣカードの発行を受ける。 通信回線によりＩＣ
カードにエレクトロニック・ウオレット・サーバーの預金口座からエレクトロニック・マネー（ＥＭ）を移す。
この移されたＥＭ分だけＩＣカードの利用ができ、従って、予め決められた金額をＩＣカードで使用することができるようになっている。

【０００９】又、このような電子マネーを利用した商取引においては、セキュリテイを確保することが重要であり、そのためには、（１）ＩＤ＋パスワード、（２）通信暗号化システム（例えばセキュリテイカードを使用する）、（３）電子署名システム、（４）業務フロー全体が１つのセキュリテイ機構を形成するようにする等により安全性を図っている。

【００１０】

【発明が解決しようとする課題】しかしながら、上記従来技術で説明した商取引において使用される電子マネーは、即ち、クレジットカードとの提携型であるいわばカード会社による仮想空間における決済システムであり、
商品を配送及び管理等するトランスポート・カンパニー・サーバーや、複数の商品を手配したり管理するサイバー・ショップ・サーバー等を含め、且つ相互に承認及び保証すると云うシステムにはなっていないため、仮想空間における商取引で重要な根幹をなす商品の存在の証明及び決済金額の証明ができないと云う問題点がある。

【００１１】従って、仮想都市を構築した場合における電子商取引において、少なくとも商品の存在の証明及び決済金額の存在を証明できるシステムに解決しなければならない課題を有している。

【００１２】

【課題を解決するための手段】上記課題を解決するために、本発明に係る電子決済システムは、商品の発注及び購入を端末機器を介して行うユーザーと、該ユーザーに前記商品の購入決済金があることを証明及び保証するために行われる預託行為を含む金銭出納管理をする単独又は複数のエレクトロニック・ウオレット・サーバーと、
前記ユーザーが購入する前記商品を取り揃え且つ単独若しくは複数の商品仕入先との受発注管理を行う複数のサイバー・ショップ・サーバーと、前記ユーザーが選択した商品の自動的な配送及び集荷の情報を収集し、且つ該商品の集荷・配送及び管理を行い、配送が完了したことを証明する単独又は複数のトランスポート・カンパニー・サーバーと、前記ユーザーとエレクトロニック・ウオレット・サーバーとサイバー・ショップ・サーバーとトランスポート・カンパニー・サーバーとのそれぞれと個別に通信回線を介して接続し、該接続された全体を組織的に統合すると共に取引履歴をデータベース上に記録・
保管し、且つクーリングオフシステムにより予め設定されているクーリングオフ期間に基づいて最終的な商品の存在を証明するラピュタ・コマース・サーバーとから構成され、前記ラピュタ・コマース・サーバーに接続されたそれぞれのユーザーとエレクトロニック・ウオレット・サーバーとサイバー・ショップ・サーバーとトランスポート・カンパニー・サーバーとの相互間の通報、証明、保証を前記ラピュタ・コマース・サーバーを介して行い、且つ前記商品のキャンセル処理及び前記クーリングオフ期間に基づく処理を電子仮想空間上において普遍的にルール化して行うようにしたことである。

【００１３】このように構成した電子決済システムは、
通信回線を介した商取引において事前にユーザー側の資金と商品を販売するメーカー側の商品在庫を電子的に照合することができ、且つユーザーの資金は預託によりエレクトロニック・ウオレット・サーバーが保証し、商品はサイバー・ショップ・サーバーが保証し且つ商品の配達はトランスポート・カンパニー・サーバーが保証することができ、時空を超えた電子仮想空間における商取引の安全性を確保することができ、具体的にはインターネットに代表される電子仮想空間上の電子商取引に関する受注発注管理、物流管理、預託決済管理に基づいて商品とその決済代金の存在を保証する商取引のシステムを構築することができる。

【００１４】

【発明の実施の形態】次に、本発明に係る電子決済システムについて図面を参照にして説明する。

【００１５】本発明に係る電子決済システムは、図１に示すように、商品の発注及び購入を端末機器を介して行うユーザー（Ｕｓｅｒ；ＵＲ）と、このユーザーＵＲに商品の購入決済金があることを証明及び保証するために行われる預託行為を含む金銭出納管理をする単独又は複数のエレクトロニック・ウオレット・サーバー（Ｅｌｅ
ｃｔｒｏｎｉｃ Ｗａｌｌｅｔ Ｓｅｒｖｅｒ；ＥＷ
Ｓ）と、ユーザーＵＲが購入する商品をこのシステム上で取り揃えて販売し、そのための単独若しくは複数の商品仕入先との受発注管理を行う複数のサイバー・ショップ・サーバー（Ｃｙｂｅｒ Ｓｈｏｐ Ｓｅｒｖｅｒ；
ＣＳＳ）と、ユーザーＵＲが選択した商品を本システム上から自動的に配送及び集荷の情報を収集し、この商品の集荷・配送及び管理を行い、配送が完了したことを証明する、即ち、商品の存在を証明するための単独又は複数のトランスポート・カンパニー・サーバー（Ｔｒａｎ
ｓｐｏｒｔ Ｃｏｍｐａｎｙ Ｓｅｒｖｅｒ；ＴＣＳ）
と、ユーザーＵＲとエレクトロニック・ウオレット・サーバーＥＷＳとサイバー・ショップ・サーバーＣＳＳとトランスポート・カンパニー・サーバーＴＣＳとのそれぞれと個別に専用若しくは公衆の通信回線を介して接続し、この接続された全体を組織的に統合すると共に取引履歴をデータベース（Ｄａｔａ Ｂａｓｅ；ＤＢ）上に記録・保管し、且つクーリングオフシステムにより予め設定されているクーリングオフ期間をカウントダウンすることによって最終的な商品の存在を証明するラピュタ・コマース・サーバー（Ｌａｐｕｔａ Ｃｏｍｍｅｒｃ
ｅ Ｓｅｒｖｅｒ；ＬＣＳ）とから構成されている。

【００１６】エレクトロニック・ウオレット・サーバーＥＷＳは、イーサネットを介して金融機関のバンクサーバーと接続してイントラネットを形成し、イントラネットを形成したエレクトロニック・ウオレット・サーバーＥＷＳは、インターネットを介してラピュタ・コマース・サーバーＬＣＳにイーサネットで接続しているエレクトロニック・ウオレット・デュプリカント・サーバー（ＥｌｅｃｔｒｏｎｉｃＷａｌｌｅｔ Ｄｕｐｌｉｃａ
ｎｔ Ｓｅｒｖｅｒ；ＥＷＤＳ）に接続されている。 このようにエレクトロニック・ウオレット・デュプリカント・サーバーＥＷＤＳを介してエレクトロニック・ウオレット・サーバーＥＷＳとラピュタ・コマース・サーバーＬＣＳとを接続したのは、ＣＧＩやＳＳＩを用いたシステムの場合、直接に相手方に書き込むシステムに比べ、リクエスト及び回答で二重にトランザクションが発生する為トラフイックが倍の密度になってしまい、更に、デーモンプログラムによる処理は頻繁なアクセスが発生する為、トラフイックに多大な負荷を与えてしまう。 このようにただでさえトラフイックが過密なため、
通信時間のかかりすぎやデータの紛失当の問題が発生してしまう。 そのため、エレクトロニック・ウオレット・
デュプリカント・サーバーＥＷＤＳを設置してイーサネットによって対応して、通信時間のかかりすぎやデータの紛失等の問題を解決している。

【００１７】サイバー・ショップ・サーバーＣＳＳは、
複数のホールセラー（Ｗｈｏｌｅｓａｌｅｒ；ＷＳ）と複数のファクトリ（Ｆａｃｔｏｒｙ；ＦＣ）とでイントラネットを構築してＣＡＬＳを形成し、且つサイバーショップサーバーＣＳＳは、インターネットを介してラピュタ・コマース・サーバーＬＣＳのサイバー・ショップ・デュプリカント・サーバー（Ｃｙｂｅｒ Ｓｈｏｐ
ＤｕｐｌｉｃａｎｔＳｅｒｖｅｒ；ＣＳＤＰ）に接続された構成となっている。 このサイバー・ショップ・デュプリカント・サーバーＣＳＤＰを介してラピュタ・コマース・サーバーＬＣＳに接続するようにしたのは、上述したエレクトロニック・ウオレット・デュプリカント・
サーバーＥＷＤＳと同様の理由によるものであり、ＣＧ
ＩやＳＳＩを用いたシステムの場合、リクエスト及び回答で二重にトランザクションが発生する為トラフイックが倍の密度になってしまうこと、及びデーモンプログラムによる処理は頻繁なアクセスが発生する為、トラフイックに多大な負荷を与えてしまい、トラフイックが過密になり、通信時間のかかりすぎやデータの紛失当の問題が発生してしまうため、サイバー・ショップ・デュプリカント・サーバーＣＳＤＰを設置してイーサネットによって対応し、通信時間のかかりすぎやデータの紛失等の問題を解決しているのである。

【００１８】トランスポート・カンパニー・サーバーＴ
ＣＳは、複数のブランチ（Ｂｒａｎｃｈ；ＢＲ）とからイントラネットを構築してＣＡＬＳを形成し、且つトランスポート・カンパニー・サーバーＴＣＳはインターネットを介してラピュタ・コマース・サーバーＬＣＳのトランスポート・カンパニー・デュプリカント・サーバー（Ｔｒａｎｓｐｏｒｔ Ｃｏｍｐａｎｙ Ｄｕｐｌｉｃ
ａｎｔ Ｓｅｒｖｅｒ；ＴＣＤＰ）に接続された構成となっている。 このトランスポート・カンパニー・デュプリカント・サーバーＴＣＤＰを介してラピュタ・コマース・サーバーＬＣＳに接続するようにしたのは、上述したエレクトロニック・ウオレット・デュプリカント・サーバーＥＷＤＳと同様の理由によるものであり、ＣＧＩ
やＳＳＩを用いたシステムの場合、リクエスト及び回答で二重にトランザクションが発生する為トラフイックが倍の密度になってしまうこと、及びデーモンプログラムによる処理は頻繁なアクセスが発生する為、トラフイックに多大な負荷を与えてしまい、トラフイックが過密になり、通信時間のかかりすぎやデータの紛失等の問題が発生してしまうため、トランスポート・カンパニー・デュプリカント・サーバーＴＣＤＰを設置してイーサネットによって対応し、通信時間のかかりすぎやデータの紛失等の問題を解決しているのである。

【００１９】ラピュタ・コマース・サーバーＬＣＳは、
サイバー・ショップ・サーバーＣＳＳとインターネットを介して接続するサイバー・ショップ・デュプリカント・サーバーＳＳＤＳと、エレクトロニック・ウオレット・サーバーＥＷＳとインターネットを介して接続するエレクトロニック・ウオレット・デュプリカント・サーバーＥＷＤＳと、トランスポート・カンパニー・サーバーＴＣＳとインターネットを介して接続するトランスポート・カンパニー・デュプリカント・サーバーＴＣＤＳとを備え、且つこれらのそれぞれはイーサネットを介してラピュタ・コマース・サーバーＬＣＳに接続されている。 又、ラピュタ・コマース・サーバーＬＣＳは、複数のユーザーＵＲとインターネットを介して接続されている。

【００２０】このような接続状態で構成した電子決済システムは、ラピュタ・コマース・サーバーＬＣＳに接続されたそれぞれのユーザーＵＲとエレクトロニック・ウオレット・サーバーＥＷＳとサイバー・ショップ・サーバーＣＳＳとトランスポート・カンパニー・サーバーＴ
ＣＳとの相互間の通報、証明、保証をラピュタ・コマース・サーバーＬＣＳを介して行い、且つ各構成要素に跨ぐ商品のキャンセル処理及びクーリングオフ期間に基づく処理を電子仮想空間上において普遍的にルール化して整備することができ、これは時空を超えた電子仮想空間における商取引の安全性を確保した、いわゆるインターネットに代表される電子仮想空間上の電子商取引に関する受発注管理・物流管理・預託決済管理に基づいて商品とその決済代金の存在を保証するシステムを実現できるのである。

【００２１】そして、上記構成にした電子決済システムにおいては、納期の通知による商品存在の証明と預託による決済金額の存在を保証することによる預託システムによる契約の成立と、消費者の保護及び最終的な商品の存在を証明するクーリングオフシステムの導入と、パスワードの盗難に対するセキュリテイとして預託通報システムの導入と、消費者保護と商品返品に対するセキュリテイを確保するクーリングオフ警報システムの導入と、
サイバー・ショップ・サーバー側の商品を販売する販売者を保護する検品処理システムの導入と、システム全体のセキュリテイを図るために通知と云う概念を導入した通知システムが構築されている。

【００２２】即ち、エレクトロニック・ウオレット・サーバーＥＷＳとサイバー・ショップ・サーバーＣＳＳとトランスポート・カンパニー・サーバーＴＣＳとラピュタ・コマース・サーバーＬＣＳ間のデータの送受信は、
ＣＧＩ又はＳＳＩ若しくはこれらと同等の機能を有するシステムによって所定の相手サーバーにリクエストすることにより、相互に相手のデータベースＤＢを検索し、
読み込むことによって行い、直接に相手のデータベースＤＢへの書き込みを行わないことによって、データの改ざんを行えないようにした構成となっている。

【００２３】そして、ユーザーＵＲからラピュタ・コマース・サーバーＬＣＳ間のデータの送受信は、ＣＧＩ
（Ｃｏｍｍｏ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃ）又はＳＳＩ（Ｓｅｒｖｅｒ Ｓｉｄｅ Ｉｎｃｌｕｄｅ）
若しくはそれと同等又はそれ以上の機能を有するシステムによって、ユーザーＵＲからのリクエストのみとし、
ユーザーＵＲからラピュタ・コマース・サーバーＬＣＳ
への直接の書き込みをなくすことによって、データの改ざんを行えないようにした構成となっている。

【００２４】また、ユーザーＵＲ又はサイバー・ショップ・サーバーＣＳＳ又はトランスポート・カンパニー・
サーバーＴＣＳ又はエレクトロニック・ウオレット・サーバーＥＷＳの情報は、ラピュタ・コマース・サーバーＬＣＳがタイマー動作プログラム又は常時動作プログラムによって自動的にユーザーＵＲとサイバー・ショップ・サーバーＣＳＳとトランスポート・カンパニー・サーバーＴＣＳとエレクトロニック・ウオレット・サーバーＥＷＳとのそれぞれにリクエストを発行し、このユーザーＵＲとサイバー・ショップ・サーバーＣＳＳとトランスポート・カンパニー・サーバーＴＣＳとエレクトロニック・ウオレット・サーバーＥＷＳとのそれぞれがＣＧ
Ｉ又はＳＳＩを生成してラピュタ・コマース・サーバーＬＣＳに回答するようにして情報の授受を行うような構成となっている。

【００２５】図２は、預託と契約の成立、即ち、納期の通知による商品存在の証明と預託による決済金額の存在保証による契約の成立を示した、いわゆる預託システムを示したブロックフロー図である。

【００２６】先ず、ユーザーＵＲがラピュタホームページの注文書の書式を利用してラピュタ・コマース・サーバーＬＣＳのデータベースＤＢに、納品先、登録納期、
品番、品名、数量、単価、金額等からなる注文内容を登録する（ＳＴ１００）。

【００２７】サイバー・ショップ・サーバーＣＳＳに常駐し任意に定められた時間毎に検索を行いにいく機能を有するクーロン（ＣＲＯＮ）プログラムが、ラピュタ・
コマース・サーバーＬＣＳのデータベースＤＢを検索し、フラグの立っていない注文書若しくは「残高不足解消フラグ」、「再送請求フラグ」の立っている注文書を抽出する（ＳＴ１０１）。

【００２８】サイバー・ショップ・サーバーＣＳＳのＣ
ＡＬＳ（Ｃｏｎｔｉｎｕｅ Ａｃｑｕｉｓｉｔｉｏｎ
ａｎｄ Ｌｉｆｅーｃｙｃｌｅ Ｓｕｐｐｏｒｔ）がデータベースＤＢを検索して注文書の商品のそれぞれの納期を算定する（ＳＴ１０２）。

【００２９】サイバー・ショップ・サーバーＣＳＳが納期データをサイバー・ショップ・サーバーＣＳＳのＣＡ
ＬＳから受け取りデータベースＤＢに登録する（ＳＴ１
０３）。

【００３０】ラピュタ・コマース・サーバーＬＣＳにおいて、常時アンダーグランドで動作しており、イベントが発生した時に即座に対応する機能を有するデーモン（ＤＡＥＭＯＮ）プログラムがサイバー・ショップ・サーバーＣＳＳの納期データを検索してデータベースＤＢ
に登録する（ＳＴ１０４）。

【００３１】ユーザＵＲは、端末上で任意に定められた時間毎に動作するＨＴＭＬ（ハイパーテキストマークアップランゲージ）のプログラムであるメタタグプログラムにより、ラピュタホームページにおいて、ラピュタ・
コマース・サーバーＬＣＳのデータベースＤＢの納期データを検索して読み込む（ＳＴ１０５）。

【００３２】納期通知が存在していれば、納期通知インジケータが点滅し、納期通知画面が表示される（ＳＴ１
０６）。 入荷の見込みがなくまた在庫がない場合には、
在庫無しのインジケータが点滅し、通知画面に表示される（ＳＴ１０７）。

【００３３】納期が了承されると、納期了承ボタンをクリックし（ＳＴ１０８）、ラピュタ・コマース・サーバーＬＣＳのＨＴＴＰに納期了承をリクエストし（ＳＴ１
０９）、ＣＧＩプログラム、即ち、ＨＴＴＰ（Ｈｙｐｅ
ｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）
のプログラムであって、外部からのリクエストを受けて動作し、且つリクエストの結果をリクエストの発信者に返答する機能を有する、このＣＧＩプログラムがラピュタ・コマース・サーバーＬＣＳのデータベースＤＢに契約成立のフラグを立てる（ＳＴ１１０）。

【００３４】納期がキャンセルの場合は、キャンセルボタンをクリックする（ＳＴ１１１）。 そうすると、ラピュタ・コマース・サーバーＬＣＳのＨＴＴＰにキャンセル処理をリクエストし、ラピュタ・コマース・サーバーＬＣＳのデータベースＤＢの注文書用の仮ファイルを削除し、データベースＤＢにキャンセルを登録する（ＳＴ
１１２、ＳＴ１１３）。

【００３５】このようにして商品の納期及び商品の存在の証明は、ユーザーＵＲが、ラピュタ・コマース・サーバーＬＣＳを介して行うサイバー・ショップ・サーバーＣＳＳに対する商品の発注は、サイバー・ショップ・サーバーＣＳＳ内においてラピュタ・コマース・サーバーＬＣＳがユーザーＵＲからの商品発注を受けたことを検知するようにし、この商品発注を検知した時にサイバー・ショップ・サーバーＣＳＳのデータベースＤＢ又はサイバー・ショップ・サーバーＣＳＳ内のクライアントに対してユーザーＵＲが発注した商品の在庫検索を実施して、当該商品の単純納期を算出することができる。

【００３６】そして、この単純納期は、ユーザーＵＲの指定する配達地による配送必要日数と合わせることにより、ユーザーＵＲの指定する配達地までの最終納期を算定し、ラピュタ・コマース・サーバーＬＣＳを通じて商品の最終納期をユーザーＵＲに送り返すことによって商品の存在を証明することができるのである。

【００３７】一方、ステップＳＴ１００において、注文書の注文内容が登録されると、エレクトロニック・ウオレット・サーバーＥＷＳがデーモンプログラムによりラピュタ・コマース・サーバーＬＣＳのデータベースＤＢ
を検索し、何もフラグが立てられていない注文書若しくは「残高不足フラグ」「再送請求フラグ」の立てられた注文書を抽出する。 そして登録済みのユーザーＵＲのエレクトロニック・ウオレット・サーバーＥＷＳでの残高と購入金額とを比較して「購入可否」をデータベースＤ
Ｂに登録する（ＳＴ１１４）。

【００３８】ラピュタ・コマース・サーバーＬＣＳのデーモンプログラムがエレクトロニック・ウオレット・サーバーＥＷＳのデータベースＤＢを検索し、「購入可否」についての新規データを抽出し、データベースＤＢ
に「購入可否」のフラグを立てる（ＳＴ１１５）。

【００３９】購入可であれば購入可能フラグを立て、購入否であれば購入不可フラグを立て、Ｅーｍａｉｌで通知する（ＳＴ１１６、ＳＴ１１７）。

【００４０】又、ラピュタホームページのメタタグプログラムが残高不足フラグを検索し、あれば入金、キャンセルの入力の書式を表示し、ラピュタホームページのメタタグプログラムが「残高不足フラグ」を検索し、あれば残高不足のインジケータを点滅させる（ＳＴ１１８、
ＳＴ１１９）。

【００４１】もし入金処理がされると再度ステップＳＴ
１０１及びＳＴ１１４から実行され、キャンセル処理の場合はキャンセルが選択される（ＳＴ１２０）。

【００４２】ラピュタ・コマース・サーバーＬＣＳのデーモンプログラムが注文書用仮ファイルを削除し、データベースＤＢにキャンセルフラグを立て、エレクトロニック・ウオレット・サーバーＥＷＳのデーモンプログラムがラピュタ・コマース・サーバーＬＣＳを検索してキャンセルフラグを見つけると、この注文コードに基づくデータをデータベースＤＢから削除する（ＳＴ１２１、
ＳＴ１２２）。

【００４３】このようにして商品の存在を証明することと並行して、エレクトロニック・ウオレット・サーバーＥＷＳは、ユーザーＵＲの商品発注を検知し、この発注した商品の決済金額に対するエレクトロニック・ウオレット・サーバーＥＷＳ内のユーザーＵＲの預金残高の大小を検索し、この検索結果をラピュタ・コマース・サーバーＬＣＳを介してユーザーＵＲ及びサイバー・ショップ・サーバーＣＳＳに通知することによって決済金額の存在を保証することができる。

【００４４】又、この商品の存在がサイバー・ショップ・サーバーＣＳＳによって証明され、且つ預金残高が決済預金残高より大きいか又は同等であることがエレクトロニック・ウオレット・サーバーＥＷＳによって証明され、ユーザーＵＲが最終納期を了承することをラピュタ・コマース・サーバーＬＣＳに通知した場合には、エレクトロニック・ウオレット・サーバーＥＷＳは、預金残高から決済金額相当分を預託することによって決済金額の存在を保証するようにすることができ、この保証により商品発注は成立したものとみなすことができるのである。

【００４５】また、ユーザーＵＲから発注した商品がない場合、又はユーザーＵＲが最終納期を不満とした場合において、ラピュタ・コマース・サーバーＬＣＳを介して行われるエレクトロニック・ウオレット・サーバーＥ
ＷＳからの預金残高通知に対してユーザーＵＲが商品発注をキャンセルした場合は、商品発注は成立しないものとすることができる。

【００４６】預金残高が決済金額より少ない場合で且つユーザーＵＲがラピュタ・コマース・サーバーＬＣＳを介してエレクトロニック・ウオレット・サーバーＥＷＳ
から残高不足の通知を受けた場合において、ユーザーＵ
Ｒが入金処理を行うまでの間は、商品発注を一時保留の状態にする。

【００４７】このようにして決済金額の存在が証明されたことを示す購入可能フラグが立ち、且つ商品の存在が証明されたことを示す契約成立のフラグが立つとラピュタ・コマース・サーバーＬＣＳのデーモンプログラムがデータベースＤＢに「預託フラグ」を立て、預託通報システムに行く（ＳＴ１１４、ＳＴ１１５）。

【００４８】図３は、ユーザーのパスワードの盗難等に対するセキュリテイを図るための預託通報システムを示したブロックフロー図である。

【００４９】預託通報システムは、商品を購入しようとする者と真実のユーザーとの一致を図るためのシステムであり、商品を購入すると、購入をしたパスワードを有するユーザーにフィードバックをかけてセキュリテイを図るように構成されている。

【００５０】図３はそのブロックフロー図であり、先ず図２を参照にして説明した預託システムにおいてラピュタ・コマース・サーバーＬＣＳのデーモンプログラムがデータベースＤＢに預託フラグが立っていることが前提となる（ＳＴ１１６）。

【００５１】ユーザーＵＲのラピュタホームページのメタタグプログラムがラピュタ・コマース・サーバーＬＣ
ＳのＨＴＴＰに対して、ユーザーディレクトリーの仮ファイルの中の預託フラグの有無をリクエストする（ＳＴ
１１７）。

【００５２】預託フラグが立っている場合は、ユーザーＵＲの預託インジケータが点滅し、預託フラグがない場合には、何もしない（ＳＴ１１８、ＳＴ１１９）。

【００５３】ここでユーザーＵＲは了解かキャンセルを入力することができる。

【００５４】ユーザーＵＲがキャンセルを入力すると、、預託フラグが削除され、ユーザーディレクトリーの仮ファイルを削除するようにラピュタ・コマース・サーバーＬＣＳにリクエストをする（ＳＴ１２０、ＳＴ１
２１）。

【００５５】ラピュタ・コマース・サーバーＬＣＳはこのリクエストを受けると、データベースＤＢの預託フラグを削除し、且つユーザーディレクトリーの仮ファイルも削除する（ＳＴ１２２）。

【００５６】預託フラグが削除されると預託オンジケータの点滅は終了する（ＳＴ１２３）。

【００５７】一方ユーザが了解の入力を行うと、ラピュタ・コマース・サーバーＬＣＳに預託承認フラグのリクエストを行う（ＳＴ１２４、ＳＴ１２５）。

【００５８】ラピュタ・コマース・サーバーＬＣＳのＨ
ＴＴＰが預託承認ＣＧＩを作成し、ユーザーディレクトリーの仮ファイル及びデータベースＤＢに預託承認を登録する（ＳＴ１２６）。

【００５９】エレクトロニック・ウオレット・サーバーＥＷＳは、ラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索し、預託承認フラグがあれば、自分のデータベースＤＢに預託フラグを立てる（ＳＴ１２
７）。

【００６０】バンクサーバーは、エレクトロニック・ウオレット・サーバーＥＷＳのデータベースＤＢを検索し、預託承認フラグがあれば、預託処理を実行する（Ｓ
Ｔ１２８）。

【００６１】このようにして、ユーザーＵＲが商品の納期を承認し、且つエレクトロニック・ウオレット・サーバーＥＷＳによる決済金額の存在が証明された時に、ラピュタ・コマース・サーバーＬＣＳにおいて預託フラグを立て、ユーザーＵＲがこの預託フラグが立っていることを検出すると、預託フラグが立っていることをユーザーＵＲがビジュアルで確認できるようにして、真実のユーザーが商品を購入したかどうかを視認により判別できる。

【００６２】又、了解又はキャンセルの入力で対応できるようにして、ユーザーＵＲが、了解を入力すると、エレクトロニック・ウオレット・サーバーＥＷＳはこの了解した預託フラグを検出して預託金額と前記商品の決済金額との決済処理を行うようにして、金銭面でのセキュリテイを図ることができるのである。

【００６３】また、ユーザーＵＲが、キャンセルを入力すると、これは真実のユーザーＵＲの商品の購入ではないと判断して、ラピュタ・コマース・サーバーＬＣＳ
は、このキャンセルした預託フラグを検出して当該商取引のデータフィールドの削除を行う。

【００６４】図４〜図６は消費者を保護するためのキャンセルシステムを示したものである。

【００６５】消費者を保護するためのキャンセルシステム、即ち、ユーザーが行った商品発注に対するキャンセル処理は、ラピュタ・コマース・サーバーＬＣＳが記録媒体、例えばデータベース上に商取引についてのデータフィールドをまだ作成していない商品発注時点から納期承認前までと、ラピュタ・コマース・サーバーが記録媒体上に商取引についてのデータフィールドを作成した納期承認時点から配達証明発行前までの２つの段階の時期においてのみ有効となっている。

【００６６】データフィールドを作成していない場合とは、ラピュタ・コマース・サーバーＬＣＳがデータフィールドの作成を実行しないで終了したことを意味し、データフィールドを作成している場合とは、ラピュタ・コマース・サーバーＬＣＳは、このデータフィールドの削除を行う。

【００６７】図４は、ユーザーＵＲが商品を納期了承してから配達までのキャンセル処理を示したブロックフロー図である。

【００６８】先ず、ユーザーＵＲがキャンセル書式を用いてキャンセルを入力・送信すると、ラピュタ・コマース・サーバーＬＣＳのＣＧＩが仮ファイル及びデータベースＤＢにキャンセルフラグを立てる（ＳＴ１３０、Ｓ
Ｔ１３１）。

【００６９】エレクトロニック・ウオレット・サーバーＥＷＳのデーモンプログラがラピュタ・コマース・サーバーＬＣＳのユーザーディレクトリーを検索して、キャンセルフラグがあれば自分のデータベースＤＢにキャンセルフラグを立てる（ＳＴ１３２）。

【００７０】トランスポート・カンパニー・サーバーＴ
ＣＳのデーモンプログラムがラピュタ・コマース・サーバーＬＣＳのユーザーディレクトリーを検索してキャンセルフラグがあれば、自分のデータベースＤＢにキャンセルフラグを立てる（ＳＴ１３３）。

【００７１】サイバー・ショップ・サーバーＣＳＳのデーモンプログラムが、ラピュタ・コマース・サーバーＬ
ＣＳのユーザーディレクトリーを検索して、キャンセルフラグがあれば、自分のデータベースＤＢにキャンセルフラグを立てる（ＳＴ１３４）。

【００７２】このようにしてそれぞれのサーバーＥＷ
Ｓ、ＴＣＳ、ＣＳＳにおいてキャンセルフラグの処理がなされ、ラピュタ・コマース・サーバーＬＣＳのデーモンプログラムが各サーバーのデータベースを検索してキャンセルフラグがあれば、ユーザーディレクトリーの仮ファイルを削除し、データベースＤＢにキャンセルを登録する（ＳＴ１３５）。

【００７３】従って、サイバー・ショップ・サーバーＣ
ＳＳは、ユーザーＵＲの商品発注に対するキャンセル処理を、ラピュタ・コマース・サーバーＬＣＳにおけるデータフィールドの喪失と自己のデータベースにおけるデータフィールドの存在とで検知するようにし、この検知した後においては更に出荷前と出荷後の２段階に分けてキャンセル処理を行うようにして消費者を保護するようにしてある。

【００７４】図５は、キャンセル処理によるサイバー・
ショップ・サーバーＣＳＳの対応を示したブロックフロー図である。

【００７５】サイバー・ショップ・サーバーＣＳＳのデーモンプログラムが、ラピュタ・コマース・サーバーＬ
ＣＳのユーザーディレクトリーを検索して、キャンセルフラグがあれば、自分のデータベースＤＢにキャンセルフラグを立てる（ＳＴ１３６）。

【００７６】出荷前であれば、自分のデータベースに出庫データがなければ、データベースＤＢの当該データを削除する（ＳＴ１３７）。

【００７７】そしてサイバー・ショップ・サーバーＣＳ
ＳのＣＡＬＳの在庫データベースにキャンセル在庫として登録する（ＳＴ１３８）。

【００７８】出荷後であれば、自分のデータベースＤＢ
に、当該データについての出庫データがあれば、ラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索し、当該データについての返品配送完了フラグがあれば、自己のデータベースＤＢの当該データ全てを削除する（ＳＴ１３９）。

【００７９】キャンセルフラグがあれば、自分のデータベースの当該取引に関するファイルを削除し、なければなにもしない（ＳＴ１４０、ＳＴ１４１）。

【００８０】さらに、トランスポート・カンパニー・サーバーＴＣＳにおいては、このキャンセル処理のデータを取得した後において、出荷前と出荷後と配送中の３段階に分けてキャンセル処理を行うようにして、消費者の保護を図った構成となっている。

【００８１】図６は、キャンセル処理におけるトランスポート・カンパニー・サーバーＴＣＳの対応を示したブロックフロー図である。

【００８２】トランスポート・カンパニー・サーバーＴ
ＣＳのデーモンプログラムがラピュタ・コマース・サーバーＬＣＳのユーザーディレクトリーを検索して、キャンセルフラグがあれば自分のデータベースＤＢにキャンセルフラグを立てる（ＳＴ１４２）。

【００８３】集荷前であれば、データベースＤＢに集荷済フラグがなければ、デーモンプログラムが６時間後に自分のデータベースＤＢの当該集荷データを削除する（ＳＴ１４３）。

【００８４】集荷後であれば、データベースＤＢに集荷フラグが有り、且つ出荷フラグがなければ、返品配送フラグを立てる（ＳＴ１４４）。

【００８５】そして、返品配達済みを入力し、データベースＤＢに返品配送済フラグを立てる（ＳＴ１４５）。

【００８６】ラピュタ・コマース・サーバーＬＣＳのデーモンプログラムがトランスポート・カンパニー・サーバーＴＣＳのデータベースＤＢを検索し、返品配達済フラグが有れば、データベースＤＢに返品配達済フラグを立てる（ＳＴ１４６）。

【００８７】エレクトロニック・ウオレット・サーバーＥＷＳのデーモンプログラムがラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索して、返品配達済フラグがあれば、預託解除フラグを立てる（ＳＴ１４
７）。

【００８８】ラピュタ・コマース・サーバーＬＣＳのデーモンプログラムがエレクトロニック・ウオレット・サーバーＥＷＳのデータベースＤＢを検索して預託解除フラグがあれば、当該データの仮ファイルを削除し、データベースＤＢにキャンセルを登録する（ＳＴ１４８）。

【００８９】又、バンクサーバーのデーモンプログラムがエレクトロニック・ウオレット・サーバーＥＷＳのデータベースＤＢを検索して預託解除フラグがあれば、当該データの預託を解除する（ＳＴ１４９）。

【００９０】そして、エレクトロニック・ウオレット・
サーバーＥＷＳがバンクサーバーのデータベースＤＢを検索して、預託解除フラグデータの預託が解除されていれば、自己のデータベースＤＢの当該データを削除する（ＳＴ１５０）。

【００９１】図７〜図１３はクーリングオフシステムを示したブロックフロー図である。

【００９２】クーリングオフシステムは、法で定められた最低のクーリングオフ期間を持つ通販問題対策に設けられた消費者保護と最終的な商品の存在を証明するためのシステム、即ち、通販等により消費者が商品を直接確認することなく購入した場合、その商品が消費者のイメージと異っていたり、破損・汚損があった場合にはクーリングオフ期間内であれば無条件に返品できるシステムであり、本発明においてはこの返品することを拡張して独自の期間設定を行なうと同時に最終的な商品の存在の証明にも援用している。

【００９３】即ち、クーリングオフシステムはトランスポート・カンパニー・サーバーＴＣＳによるユーザーＵ
Ｒへの商品の配達証明発行後から、各商品固有の性能・
性質に基づいて設定されているガイドラインに従って、
サイバー・ショップ・サーバーを提供・維持・管理する企業又は個人が各商品固有の性能・性質に基づいて設定されているクーリングオフ期間の終了まで機能するようにしたことである。

【００９４】このクーリングオフシステムは、ユーザーＵＲが商品の返品の際に行うクーリングオフ申請によるキャンセル処理手段と、ユーザーＵＲからの再送依頼により商品の再送を行う再送請求処理手段と、クーリングオフ期間外処理手段と、トランスポート・カンパニー・
サーバーＴＣＳにおける配達終了に基づくクーリングオフ解除期日算定手段と、トランスポート・カンパニー・
サーバーＴＣＳにおける商品の配達終了期間に基づくクーリングオフ警報手段と、ユーザーからのクーリングオフの中止を処理するクーリングオフ中止手段と、クーリングオフ期間に基づいて前記ユーザーの手元に届いた商品の返品処理を行うクーリングオフの検品処理手段とから構成されている。

【００９５】クーリングオフシステムにおけるクーリングオフ期間の終了が、商品が前記ユーザーの発注商品と同一であることをユーザー本人が確認したものとみなして、最終的な商品の存在の証明が行われたものとするようにしてある。

【００９６】図７は、ユーザーＵＲが商品の返品の際に行うクーリングオフ申請によるキャンセル処理手段を示したブロックフロー図である。

【００９７】先ず、ユーザＵＲがラピュタホームページのクーリングオフ書式により、商品を返品したい旨、即ちクーリングオフ申請をラピュタ・コマース・サーバーＬＣＳにリクエストすると、ラピュタ・コマース・サーバーＬＣＳのＣＧＩが注文書仮ファイルをユーザーディレクトリー及びデータベースＤＢに登録する（ＳＴ１５
１）。

【００９８】ラピュタ・コマース・サーバーＬＣＳのデーモンプログラムは、クーリングオフ申請がクーリングオフ期間内か否かのチエックをする（ＳＴ１５２）。

【００９９】期間外であればクーリングオフ期間外処理ルーチン（クーリングオフ期間外処理手段）に行き、クーリングオフ期間内であれば、デーモンプログラムがクーリングオフのフラグを仮ファイルとデータベースＤＢ
に立てる（ＳＴ１５３、ＳＴ１５４）。

【０１００】クーリングオフのフラグが立つと、さまざまなサーバーが動き出す。 先ず、エレクトロニック・ウオレット・サーバーＥＷＳのクーロンプログラムがラピュタ・コマース・サーバーＬＣＳのクーリングオフフラグを抽出し、自分のデータベースＤＢにクーリングオフフラグを立てる（ＳＴ１５５）。

【０１０１】サイバー・ショップ・サーバーＣＳＳのクーロンンプログラムがラピュタ・コマース・サーバーＬ
ＣＳのクーリングオフフラグを抽出し、自分のデータベースＤＢにクーリングオフフラグを立てる（ＳＴ１５
６）。

【０１０２】トランスポート・カンパニー・サーバーＴ
ＣＳのクーロンプログラムがラピュタ・コマース・サーバーＬＣＳのクーリングオフフラグを抽出し、自分のデータベースＤＢにクーリングオフフラグを立てる（ＳＴ
１５７）。

【０１０３】そして、トランスポート・カンパニー・サーバーＴＣＳの端末のプラウザにクーリングオフフラグが立てられたデータを表示する（ＳＴ１５８）。

【０１０４】このような作業（ＳＴ１５５〜ＳＴ１５
８）を終了後、ラピュタ・コマース・サーバーＬＣＳのクーロンプログラムが「クーリングオフ解除期日」に達した注文ファイルをピックアップし、クーリングオフフラグを削除し、解除する（ＳＴ１５９）。

【０１０５】また、エレクトロニック・ウオレット・サーバーＥＷＳのクーロンプログラムが新しい「クーリングオフ解除期日データ」を検索し、自分のデータベースＤＢに期日を登録する（ＳＴ１６０）。

【０１０６】エレクトロニック・ウオレット・サーバーＥＷＳのクーロンプログラムがラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索して、クーリングオフの解除を検知すると、自分のデータベースＤＢ内の「クーリングオフ期日」のデータと照合し、「期日データ」以降の日付ならば「預託解除・決済フラグ」を立てる（ＳＴ１６１）。

【０１０７】ステップＳＴ１５７において、トランスポート・カンパニー・サーバーＴＣＳがクーリングオフのフラグを立てると、運送会社がデータベースに返品配達の完了を登録し、運送会社の集荷・配送システムにデータを渡す（ＳＴ１６２、ＳＴ１６３）。

【０１０８】そして、ラピュタ・コマース・サーバーＬ
ＣＳのクーロンプログラムがトランスポート・カンパニー・サーバーＴＣＳのデーターベースＤＢを検索して、
「返品配達完了」の登録があれば、データベースＤＢに「返品配達完了」のフラグを立てる（ＳＴ１６４）。

【０１０９】返品された商品は、サイバー・ショップ・
サーバーＣＳＳにて、申請の商品であるか否かの検品処理がなされ、データベースＤＢにフラグを立てる（ＳＴ
１６５）。

【０１１０】ラピュタ・コマース・サーバーＬＣＳのクーロンプログラムがサイバー・ショップ・サーバーＣＳ
Ｓのデータベースを検索し、返品された商品の「真」、
「偽」のフラグを読み込む（ＳＴ１６６）。

【０１１１】「偽」の場合は、受理できない旨のメールを発送し、クレーム処理担当者にデータを渡す。 「真」
の場合は、ステップＳＴ１６４の「返品配達完了」のフラグにより、返品配達が完了し、且つ返品された商品が真であることを確認して、エレクトロニック・ウオレット・サーバーＥＷＳのクーロンプログラムがラピュタ・
コマース・サーバーＬＣＳのデータベースＤＢを検索し、上記フラグを検索して見つけると「預託解除・キャンセル」のフラグを立てる（ＳＴ１６７）。

【０１１２】そして、ラピュタ・コマース・サーバーＬ
ＣＳのクーロンプログラムがエレクトロニック・ウオレット・サーバーＥＷＳのデータベースＤＢを検索して、
「預託解除・キャンセルフラグ」を発見すれば、仮ファイルを削除する（ＳＴ１６８）。

【０１１３】また、ステップＳＴ１６１での照合、及びステップＳＴ１６７により、バンクサーバーのデーモンプログラムがデータベースＤＢから「預託解除・決済フラグ」若しくは「預託解除・キャンセルフラグ」を見つけると、預託を解除し、送金若しくは送金手続を行う（ＳＴ１６９）。

【０１１４】また、ユーザーＵＲのメタタグプログラムがラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索して、「返品配達完了」のフラグ、及び「返品された商品が真である」フラグを見つけるとインジケータを点滅させる（ＳＴ１７０）。

【０１１５】そして、ユーザーＵＲが「了解」を入力すると、クーリングオフ書式を削除若しくは停止して点滅を停止する（ＳＴ１７１、ＳＴ１７２）。

【０１１６】さらに、ラピュタ・コマース・サーバーＬ
ＣＳのクーロンプログラムがデータベースを検索して「返品配達完了」のフラグ及び「返品された商品が真である」フラグを見つけると、「返品が完了し、クーリングオフ処理が終了した旨」のメッセージをユーザーに送付する（ＳＴ１７３）。

【０１１７】図８は、ユーザーＵＲからの再送依頼により商品の再送を行う再送請求処理手段を示したブロックフロー図である。

【０１１８】再送請求をするクーリングオフ処理ユニットは、クーリングオフの一環として、商品の間違いや、
破損、汚損等があった場合に、商品を返品し、再度送付を依頼するためのシステムである。

【０１１９】先ず、ユーザーＵＲがクーリングオフ書式（ＪＡＶＡ）によって商品の再度依頼を行う。 この時に入力する内容は、納入日、再送品希望配送日時、品番、
数量、金額、請求原因（例示より数字で選択する、その他である（ＳＴ１７５）。

【０１２０】ラピュタ・コマース・サーバーＬＣＳはデーモンプログラムによってデータベースＤＢを検索し、
「該当する商品の有無」と「クーリングオフ期間内外」
のチエックを行う（ＳＴ１７６）。

【０１２１】そして、クーリングオフ期日外であればクーリングオフ期間外処理システムのルーチンにゆく（Ｓ
Ｔ１７７）。

【０１２２】期日内であればラピュタ・コマース・サーバーＬＣＳより品名を添えて確認のメッセージをユーザーＵＲに送付し、ユーザーＵＲは了解、又は変更の入力ができる（ＳＴ１７８、ＳＴ１７９）。

【０１２３】ユーザーＵＲが了解すると、ラピュタ・コマース・サーバーＬＣＳのデーモンプログラムが、これまでの仮ファイルを削除して、新規の仮ファイルを作成してデータベースＤＢに新規の注文書（データフィールド）を作成し、それぞれに「再送請求フラグ」を立て、
図２に示した預託システムにゆき商品発送の処理を行う（ＳＴ１８１）。

【０１２４】一方、返品された商品は、サイバー・ショップ・サーバーＣＳＳにて、申請の商品か否かの検品作業を行い、データベースＤＢにフラグを立てる（ＳＴ１
８２）。

【０１２５】ラピュタ・コマース・サーバーＬＣＳのクーロンプログラムがサイバー・ショップ・サーバーＣＳ
ＳのデータベースＤＢを検索し、「真」、「偽」のフラグを読み込む（ＳＴ１８３）。

【０１２６】「真」であればラピュタ・コマース・サーバーＬＣＳが注文書の作成及び「再送請求フラグ」を立て、図２で示した預託システムに行き商品発送の処理を行う（ＳＴ１８１）。

【０１２７】「偽」であれば受理できない旨のメール及びクレーム処理担当者にデータを渡す（ＳＴ１８４）。

【０１２８】図９は、クーリングオフ期間外処理手段であるクーリングオフ期間外処理システムを示すブロックフロ図である。

【０１２９】先ず、ラピュタ・コマース・サーバーＬＣ
Ｓのデーモンプログラムが「クーリングオフ不可フラグ」を仮ファイルとデータベースＤＢに立てていることが前提となる（ＳＴ１８５）。

【０１３０】ユーザーＵＲのメタタグがクーリングオフ不可フラグを検出すると、ユーザーＵＲのラピュタホームページのインジケータを点滅させると同時に、クーリングオフ不可の旨のインフオメーションを表示し、了解を求める（ＳＴ１８６）。

【０１３１】同時に、ラピュタ・コマース・サーバーＬ
ＣＳのデーモンプログラムがユーザーＵＲにメールを発送する（ＳＴ１８７）。

【０１３２】ここで、ユーザーＵＲがインフオメーションに対する回答を入力する（ＳＴ１８８）。

【０１３３】同意しない場合は、ユーザーＵＲの残高を表示し、購入額が残高を超えていることを開示して、再度回答を促す（ＳＴ１８９）。

【０１３４】了解した場合にはラピュタ・コマース・サーバーＬＣＳのデーモンプログラムがクーリングオフフラグ及びクーリングオフ不可フラグを削除して決済処理に行く（ＳＴ１９０、ＳＴ１９１）。

【０１３５】図１０は、トランスポート・カンパニー・
サーバーＴＣＳにおける配達終了に基づくクーリングオフ解除期日算定手段であるクーリングオフの解除期日算定ユニットを示したブロックフロー図である。

【０１３６】クーリングオフの解除期日算定ユニットにおいては、先ずトランスポート・カンパニー・サーバーンスポーターサーバーＴＣＳにおけるデータベースＤＢ
に、配送が終了したことを登録する（ＳＴ１９５）。

【０１３７】ラピュタ・コマース・サーバーＬＣＳのクーロンプログラムがトランスポート・カンパニー・サーバーＴＣＳのデータベースＤＢを検索して、新規の配送終了データがあれば、データベースＤＢに対して「配達終了フラグ」を立てる（ＳＴ１９６）。

【０１３８】そして、ラピュタ・コマース・サーバーＬ
ＣＳのクーロンプログラムがクーリングオフ解除期日算定をし、データベースＤＢに期日を登録する（ＳＴ１９
７）。

【０１３９】また、ラピュタ・コマース・サーバーＬＣ
Ｓのクーロンプログラムはクーリングオフ警報発令期日の算定をし、データベースＤＢに期日を登録する（ＳＴ
１９８）。

【０１４０】図１１は、トランスポート・カンパニー・
サーバーＴＣＳにおける商品の配達終了期間に基づくクーリングオフ警報手段であるクーリングオフ警報システムを示したブロックフロー図である。

【０１４１】クーリングオフ警報システムは、ユーザーＵＲが返品する時に申請するクーリングオフ申請をしてクーリングオフフラグを立て、ラピュタ・コマース・サーバーがこのクーリングオフフラグが立っていることを検出すると警報発令期日とクーリングオフ解除期日を算定する。 この警報発令期日に達した注文ファイルをピックアップして警報フラグを立て、ユーザーＵＲがこのクーリングオフフラグが立っていることを検出すると、クーリングオフフラグが立っていることをユーザーＵＲがビジュアルで確認できるようにすると共に、了解、クレーム、クーリングオフの中止の３通りで対応できるようにしてある。

【０１４２】そして、ユーザーＵＲが対応できるクレームは、ユーザーＵＲが既に返品配送済の段階において発行するものであり、ラピュタ・コマース・サーバーＬＣ
Ｓにクレームフラグを立てると同時に、トランスポート・カンパニー・サーバーＴＣＳに別途メールで通知するようにし、且つトランスポート・カンパニー・サーバーＴＣＳがこのクレームを検出するとクレームフラグを立て、トランスポート・カンパニー・サーバーＴＣＳがこのクレームフラグを検出する。 するとクレームフラグが立っていることをトランスポート・カンパニー・サーバーＴＣＳがビジュアルで確認できるようになっている。
以下、図１１のブロックフロー図で説明する。

【０１４３】先ず、ラピュタ・コマース・サーバーＬＣ
ＳのクーロンプログラムがユーザーＵＲが立てた新しいクーリングオフフラグを検出すると、「警報発令期日」
と「クーリングオフ解除期日」を算定し、その結果をデータベースＤＢに登録する（ＳＴ２００）。

【０１４４】ラピュタ・コマース・サーバーＬＣＳのクーロンプログラムが「警報発令期日」に達した注文ファイルをピックアップし、データベースＤＢに「警報フラグ」を立てる（ＳＴ２０１）。

【０１４５】又は、トランスポート・カンパニー・サーバーＴＣＳが「返品の配送済フラグ」を自分のデータベースＤＢに立てていることが前提となる（ＳＴ２０
２）。

【０１４６】ラピュタ・コマース・サーバーＬＣＳのデーモンプログラムがトランスポート・カンパニー・サーバーＴＣのデータベースＤＢの「返品配送済フラグ」を見つけると、ラピュタ・コマース・サーバーＬＣＳのデータベースＤＢに「返品配送済フラグ」を立て、同時に「警報フラグ」を削除する（ＳＴ２０３）。

【０１４７】ユーザーＵＲのメタタグプログラムがラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索し、そのデータの中に「警報フラグ」を見つけるとインジケータを点滅させる。 インジケータをクリックすると了解書式を表示する（ＳＴ２０４）。

【０１４８】ここで、ユーザーＵＲは、「了解」、「クーリングオフの中止」、「クレーム処理」の３通りのいずれかを入力することができる（ＳＴ２０５）。

【０１４９】ユーザーＵＲが「了解」を入力すると、ユーザーＵＲに供給されている書式の中のブリンクコマンドの削除若しくは停止により点滅は停止する（ＳＴ２０
６）。

【０１５０】「クーリングオフの中止」を入力すると、
クーリングオフ中止書式を選択し、クーリングオフ中止システムのルーチンに行く（ＳＴ２０７）。

【０１５１】「クレーム処理」を入力すると、ユーザーＵＲがクレーム書式を選択し、配送番号と配送日時を入力する（ＳＴ２０８）。

【０１５２】そうすると、ラピュタ・コマース・サーバーＬＣＳの仮ファイル及びデータベースＤＢにクレームフラグを立てると同時に、運送会社にメールにて通知する（ＳＴ２０９）。

【０１５３】トランスポート・カンパニー・サーバーＴ
Ｃのデーモンプログラムがラピュタ・コマース・サーバーＬＣＳの仮ファイルのクレームフラグを見つけるとトランスポート・カンパニー・サーバーＴＣＳの端末に警報をブリンクさせる（ＳＴ２１０）。

【０１５４】同時に、トランスポート・カンパニー・サーバーＴＣＳにメールを送付し、トランスポート・カンパニー・サーバーＴＣはクレーム処理担当に処理を移行する（ＳＴ２１１、ＳＴ２１２）。

【０１５５】図１２は、ユーザーＵＲからのクーリングオフの中止を処理するクーリングオフ中止手段であるクーリングオフ中止システムを示したブロックフロー図である。

【０１５６】クーリングオフ中止は、ユーザーＵＲがクーリングオフを申請したにも関わらず未だに返品発送を行っていない段階において発行されるものであり、ユーザーＵＲがクーリングオフを中止して当該商品が発注商品と同一であることを認定した場合に発行され、ユーザーＵＲがラピュタ・コマース・サーバーＬＣＳにクーリングオフ中止フラグを立てるようにリクエストを発行することによって、トランスポート・カンパニー・サーバーＴＣＳがこのクーリングオフ中止フラグを検出すると商品の配送プランを組み替えるようにする。

【０１５７】又、エレクトロニック・ウオレット・サーバーＥＷＳ及びサイバー・ショップ・サーバーＣＳＳ
は、クーリングオフ中止フラグを検出すると、クーリングオフフラグを削除する。 以下、図１２のブロックフロー図で説明する。

【０１５８】ユーザーＵＲが「クーリングオフ中止」書式によりラピュタ・コマース・サーバーＬＣＳにクーリングオフ中止をリクエストする（ＳＴ２１５）

【０１５９】すると、ラピュタ・コマース・サーバーＬ
ＣＳのＣＧＩがデータベースＤＢ及び仮ファイルに「クーリングオフ中止フラグ」を立てる（ＳＴ２１６）。

【０１６０】トランスポート・カンパニー・サーバーＴ
Ｃのデーモンプログラムがラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索し、「クーリングオフ中止フラグ」を見つけると、自分のデータベースＤＢ
の「クーリングオフフラグ」を削除し、「クーリングオフ中止フラグ」を立てる（ＳＴ２１７）。

【０１６１】同時に、エレクトロニック・ウオレット・
サーバーＥＷＳのデーモンプログラムがラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索し、
「クーリングオフ中止フラグ」を見つけると自分のデータベースＤＢの「クーリングオフフラグ」を削除する（ＳＴ２１８）。

【０１６２】同時に、サイバー・ショップ・サーバーＣ
ＳＳのデーモンプログラムがラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索し、「クーリングオフ中止フラグ」を見つけると自分のデータベースＤＢ
の「クーリングオフフラグ」を削除する（ＳＴ２１
９）。

【０１６３】ラピュタ・コマース・サーバーＬＣＳのデーモンプログラムが各サーバーのデータベースＤＢを検索し、自分のデータベースＤＢの「クーリングオフ中止フラグ」を立てられたデータに相当するデータについてクーリングオフフラグが削除されているかどうかをチエックし、全て削除されていればラピュタ・コマース・サーバーＬＣＳのデーモンプログラムは仮ファイルから「クーリングオフ中止フラグ」を削除する（ＳＴ２２
０）。

【０１６４】一方、トランスポート・カンパニー・サーバーＴＣＳは、デーモンプログラムがデータベースＤＢ
の「クーリングオフ中止フラグ」を検出すると、配送プランを組み替える（ＳＴ２２１）。

【０１６５】集荷当日の場合は、デーモンプログラムが配送車に電話若しくはメールで通報する。 トランスポート・カンパニー・サーバーＴＣＳのデーモンプログラムは「クーリングオフ中止フラグ」を削除する（ＳＴ２２
２、ＳＴ２２３）。

【０１６６】図１３は、クーリングオフ期間に基づいてユーザーＵＲの手元に届いた商品の返品処理を行うクーリングオフの検品処理手段であるクーリングオフの検品処理ユニットを示したブロックフロー図である。

【０１６７】クーリングオフの検品処理手段は、発注した商品がユーザーＵＲの手元に届いてから返品理由フラグを立てるようにしてある。 この返品理由フラグは、商品間違い、破損・汚損、商品が予想と違っていた、その他の４種類からなり、それぞれのフラグはサイバー・ショップ・サーバーＣＳＳ内からの商品を、クーリングオフ申請に基づいて返品用商品の検品をするようになっている。

【０１６８】又、このクーリングオフの検品処理手段は、返品用商品がクーリングオフ申請した期間内であって、破損・汚損の場合は運送中の破損・汚損又は配送する際の検品漏れ又は故意によるものかの判別をし、この運送中の破損・汚損又は配送する際の検品漏れの場合は再送するようになっている。

【０１６９】そして、クーリングオフの検品処理手段は、返品用商品がクーリングオフ期間内であって、商品が予想と違っていた又はその他の理由の場合は、この商品の破損・汚損の有無を識別し、破損・汚損の場合は運送中の破損・汚損又は配送する際の検品漏れ又は故意によるものかの判別をし、この運送中の破損・汚損又は配送する際の検品漏れの場合は再送するようにしてある。
以下、図１３のブロックフロー図で説明する。

【０１７０】先ず、サイバー・ショップ・サーバーＣＳ
Ｓがラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索して、クーリングオフ申請物件から「返品理由（フラグ）」を読み込む（ＳＴ２２５）。 このフラグは、「商品間違い」、「破損、汚損」、「商品が予想と違っていた」、「その他」の４種類からなる。

【０１７１】検品する商品が、自社取扱い商品かどうかを検査し、フラグを立て、自社商品の場合は品番を入力する（ＳＴ２２６）。

【０１７２】非自社商品と認定した場合は、受理できない旨のメールを送付し、クレーム処理担当者にデータを渡す（ＳＴ２２７）。

【０１７３】自社商品と認定した場合は、サイバー・ショップ・サーバーＣＳＳのデータベースＤＢを検索して品番商品の納入時期を調査し、クーリングオフ期間と比較してクーリングオフ該当商品かどうかをチエックする（ＳＴ２２８）。

【０１７４】クーリングオフ期間内であって、返品原因が、「商品が予想と違っていた」、「その他の理由による場合」の検品は、破損・汚損の有無を検品し、入力書式により結果を入力する（ＳＴ２２８）。

【０１７５】破損・汚損が有れば、サイバー・ショップ・サーバーＣＳＳのデータベースＤＢに「破損・汚損フラグ」を追加する（ＳＴ２２９）。

【０１７６】破損・汚損が無ければサイバー・ショップ・サーバーＣＳＳのデータベースＤＢに返品された商品が「真」であるフラグを立てる（ＳＴ２３０）。

【０１７７】又、クーリングオフ期間内において、返品原因が「破損・汚損」による場合は、その検品は、破損・汚損の原因を検査し、認定結果を入力書式で入力する（ＳＴ２３１）。

【０１７８】故意によるものと認定された場合は、対策指示を表示し、受理できない旨のメールを発送し、クレーム担当者にデータを渡す（ＳＴ２３２、ＳＴ２３
３）。

【０１７９】運送中の事故と認定された場合は、運送会社と調整し、不調に終わればクレーム担当者にデータを渡す（ＳＴ２３４、ＳＴ２３５、ＳＴ２３６）。

【０１８０】保険で対応できることに合意した場合には、入力書式から「真」のフラグをリクエストし、サイバー・ショップ・サーバーＣＳＳのデータベースＤＢに返品された商品が「真」であるフラグを立てる（ＳＴ２
３７、ＳＴ２３８）。

【０１８１】又、不明若しくは検品漏れと認定した場合も、サイバー・ショップ・サーバーＣＳＳのデータベースＤＢに返品された商品が「真」であるフラグを立てる（ＳＴ２３８）。

【０１８２】ステップＳＴ２２８において、納入実績がない場合には、「納入実績無しフラグ」を立て、受理できない旨のメールを発送と、クレーム担当者にデータを渡す（ＳＴ２３９、ＳＴ２４０）。

【０１８３】ステップ２２８において、クーリングオフ期間外であれば、メールにてユーザーＵＲに商品を間違えて送付していないかを確認する（ＳＴ２４１）。

【０１８４】間違えていない場合は、クーリングオフ期間外のフラグを立て、クーリングオフ期間外処理システムに行く（ＳＴ２４２、ＳＴ２４３）。

【０１８５】ステップ２４１において、商品を間違えて送付した場合は、ユーザーＵＲがクーリングオフフラグ削除をリクエストするか又はサイバー・ショップ・サーバーＣＳＳがクーリングオフフラグ削除をリクエストするかする。 そして、ラピュタ・コマース・サーバーＬＣ
Ｓのデーモンプログラムが両者を検知すると、クーリングオフフラグを削除し、新規の仮ファイルを作成する。
又、データベースＤＢに新規の注文書を作成し、それぞれに再発行フラグを立て、クーリングオフ申請処理に行く（ＳＴ２４４、ＳＴ２４５、ＳＴ２４６、ＳＴ２４
７）。

【０１８６】図１４は、商品の存在を証明した後の決済方法を示したブロックフロー図である。

【０１８７】商品に対する代金の決済においては、エレクトロニック・ウオレット・サーバーＥＷＳに預託されている金銭を、商品を販売したサイバー・ショップ・サーバーＣＳＳの実際に商品を提供している者の口座に振り込む際に、エレクトロニック・ウオレット・サーバーＥＷＳはラピュタ・コマース・サーバーＬＣＳを介してトランスポート・カンパニー・サーバーＴＣＳからこの商品の配達証明を受け取ることによって、この商品がユーザーＵＲの手元にあることを確認する。 且つラピュタ・コマース・サーバーＬＣＳがプログラムにより自動的に算定するクーリングオフ期間の終了を、ラピュタ・コマース・サーバーＬＣＳが確認することにより、ユーザーＵＲがこの商品をユーザーＵＲが発注した商品と同一物であることをユーザーＵＲが承認したものと認め、預託金額をサイバー・ショップ・サーバーＣＳＳの実際に商品を販売している者の口座に振り込むようにする。

【０１８８】又、エレクトロニック・ウオレット・サーバーＥＷＳは、ラピュタ・コマース・サーバーＬＣＳに預託を解除して商品との決済をしたことを通知し、このラピュタ・コマース・サーバーＬＣＳは決済したことをデータベースＤＢに書き込むと共に当該商品発注のファイルを削除するようにしてある。 以下、図１４のブロックフロー図を参照して説明する。

【０１８９】先ず、トランスポート・カンパニー・サーバーＴＣＳが、データベースＤＢに配達終了が登録してあることが前提となる（ＳＴ２５０）。

【０１９０】そうすると、ラピュタ・コマース・サーバーＬＣＳのクーロンプログラムがトランスポート・カンパニー・サーバーＴＣＳのデータベースＤＢを検索して新規の配達終了データがあれば、データベースＤＢに「配達終了フラグ」を立てる（ＳＴ２５１）。

【０１９１】ラピュタ・コマース・サーバーＬＣＳのクーロンプログラムが「配達終了フラグ」を立てられたデータについて、クーリングオフ解除期日の算定をし、データベースＤＢに期日を登録する（ＳＴ２５２）。

【０１９２】エレクトロニック・ウオレット・サーバーＥＷＳのクーロンプログラムがラピュタ・コマース・サーバーＬＣＳのデータベースＤＢを検索して、「クーリングオフ解除期日」に達したデータがあれば、自分のデータベースＤＢに「預託解除・決済フラグ」を立てる（ＳＴ１６６）。

【０１９３】バンクサーバーが、エレクトロニック・ウオレット・サーバーＥＷＳのデータベースＤＢを検索して「預託・決済フラグ」があれば、預託を解除して、サイバー・ショップ・サーバーＣＳＳに送金する（ＳＴ２
５４）。

【０１９４】又、ステップＳＴ１６４から、キャンセルする場合には図７に示すクーリングオフ処理ユニットに行き、再送請求であれば図８に示すクーリングオフ処理ユニットに行く（ＳＴ２５５、ＳＴ２５６）。

【０１９５】

【発明の効果】以上説明したように本発明に係る電子決済システムは、端末機器を介して行うユーザーと、預託行為を含む金銭出納管理をする単独又は複数のエレクトロニック・ウオレット・サーバーと、商品を取り揃え且つ単独若しくは複数の商品仕入先との受発注管理を行うサイバー・ショップ・サーバーと、商品を自動的な配送及び集荷の情報を収集し、且つ商品の集荷・配送及び管理を行い、配送が完了したことを証明するトランスポート・カンパニー・サーバーと、ユーザーとエレクトロニック・ウオレット・サーバーとサイバー・ショップ・サーバーとトランスポート・カンパニー・サーバーとのそれぞれと個別に通信回線を介して接続し、接続された全体を組織的に統合すると共に取引履歴をデータベース上に記録・保管し、且つクーリングオフシステムにより予め設定されているクーリングオフ期間に基づいて最終的な商品の存在を証明するラピュタ・コマース・サーバーとから構成して、ラピュタ・コマース・サーバーに接続されたそれぞれのユーザーとエレクトロニック・ウオレット・サーバーとサイバー・ショップ・サーバーとトランスポート・カンパニー・サーバーとの相互間の通報、
証明、保証をラピュタ・コマース・サーバーを介して行い、且つ商品のキャンセル処理及びクーリングオフ期間に基づく処理を電子仮想空間上において普遍的にルール化して行うようにしたことにより、時空を超えた電子仮想空間における商取引の安全を確保した、いわゆるインターネットに代表される電子仮想空間上の電子商取引に関する受発注管理、物流管理、預託決済管理に基づいて商品とその決済代金との存在を保証することができると云う効果がある。

【図面の簡単な説明】

【図１】本発明に係る全体構成の接続関係を示した説明図である。

【図２】同預託システムを示したブロックフロー図である。

【図３】同電子商取引システムにおける預託通報システムを示したブロックフロー図である。

【図４】同電子商取引システムにおけるキャンセル処理ユニットの納期了承〜配達までを示したブロックフロー図である。

【図５】同電子商取引システムにおけるキャンセル処理におけるサイバー・ショップ・サーバーＣＳＳの対応システムユニットを示したブロックフロー図である。

【図６】同電子商取引システムにおけるキャンセル処理におけるトランスポート・カンパニー・サーバーＴＣの対応システムユニットを示したブロックフロー図である。

【図７】同電子商取引システムにおけるクーリングオフ処理ユニット（１）のキャンセル処理を示したブロックフロー図である。

【図８】同電子商取引システムにおけるクーリングオフ処理ユニット（２）の再送請求を示したブロックフロー図である。

【図９】同電子商取引システムにおけるクーリングオフ処理ユニット（３）のクーリングオフ期間外処理システムを示したブロックフロー図である。

【図１０】同電子商取引システムにおけるクーリングオフの解除期日算定ユニットを示したブロックフロー図である。

【図１１】同電子商取引システムにおけるクーリングオフ処理ユニット（４）のクーリングオフ警報システムを示したブロックフロー図である。

【図１２】同電子商取引システムにおけるクーリングオフ処理ユニット（５）のクーリングオフ中止システムを示したブロックフロー図である。

【図１３】同電子商取引システムにおけるクーリングオフの検品処理ユニットを示したブロックフロー図である。

【図１４】同電子商取引システムにおける決済処理ユニットを示したブロックフロー図である。

【図１５】従来技術における商取引を示した説明図である。

【符号の説明】

ＵＲ；ユーザー、ＣＳＳ；サイバー・ショップ・サーバー、ＥＷＳ；エレクトロニック・ウオレット・サーバー、ＴＣＳ；トランスポート・カンパニー・サーバー、
ＬＣＳ；ラピュタ・コマース・サーバー