JP5554890B2 - 仮想商店街管理システム - Google Patents

Description

本発明は、ネットワークを介して商品を販売する事業者の売買取引業務を支援するシステムに関し、特に、仮想商店街を管理運営するシステムにおける注文内容の修正に関するものである。

ネットワークを介して商品等を売買する場合、売買取引を支援するシステムである仮想商店街を利用することが多い。
仮想商店街を利用する取引において、取引の当事者間（販売者と購入者）で注文受付後（決済完了前）に注文内容を修正する場合には、取引の当事者間で電話，メール等により直接交渉を行うのが通常であり、仮想商店街を管理運用する仮想商店街管理システムは関与していなかった。

＜従来例＞
従来の仮想商店街管理システムにおける注文受付後に注文内容が修正される場合の処理の流れを、図１〜図３を用いて説明する。
（１）従来のシステムの構成
仮想商店街を管理運用している従来のシステムの構成を、図１に例示する。
図１に示すように、従来のシステムは、仮想商店街を総合的に管理する仮想商店街管理サーバ１０，並びに仮想商店街管理サーバ１０とインターネット等のネットワーク２０を介して接続している仮想商店街の会員の端末３０及び仮想商店街の加盟店の端末４０により構成される。会員端末３０及び加盟店端末４０は、ブラウザを有しており、ネットワーク２０を介して仮想商店街管理サーバ１０からサービスを受けることができる。

（２）従来のシステムによる注文の受付処理
次に、従来のシステムにより商品の注文を受け付ける場合の処理の流れを、図２のシーケンス図を用いて説明する。
図２に示すように、仮想商店街管理サーバ１０は、まず、会員端末３０に商品の選択ページを送信し、会員に注文するべき商品を選択させる（Ｓ２０５）。会員は、この選択ページにおいて注文するべき商品を選択する。
上記選択ページにおいて商品が選択されると、仮想商店街管理サーバ１０は、会員端末３０にログインページを送信し、注文者となる会員を認証する（Ｓ２１０）。会員は、このログインページにＩＤ及びパスワード等を入力して認証を受ける。
なお、商品の購入者が未登録であるときは、会員端末３０に会員登録情報の入力ページを送信し、購入者に会員登録を求める。

上記ログインページを介した会員認証が完了すると、仮想商店街管理サーバ１０は、会員端末３０に決済方法の選択ページを送信し、会員に決済方法を選択させる（Ｓ２１５）。会員は、この選択ページにおいて決済方法（例えば、銀行振込，代金引換，クレジットカード等）を選択する。
上記選択ページにおいて決済方法が選択されると、仮想商店街管理サーバ１０は、会員端末３０に注文内容の確認ページを送信し、会員に注文内容の確認を求める（Ｓ２２０）。会員は、この確認ページに表示される注文内容に間違いがないか確認する。
上記確認ページにおいて注文内容が確認されると、仮想商店街管理サーバ１０は、会員端末３０に注文の完了ページを送信し、注文を受け付けた旨を注文番号等とともに会員に提示する（Ｓ２２５）。

（３）従来のシステムによる注文内容の変更処理
次に、従来のシステムにおける注文の受付後に注文内容が修正される場合の処理の流れを、図３のシーケンス図を用いて説明する。
なお、図３のシーケンス図は、図２に示す処理により商品が注文された後の処理を示している。

図３に示すように、仮想商店街管理サーバ１０は、選択された商品の情報等をもとに注文の受付処理を行なう（Ｓ３０５）。ここでは、注文番号（図２のＳ２２５により付与した番号）ごとに所定の注文情報を生成し、所定のデータベースに記憶する。
注文の受付処理が完了すると、仮想商店街管理サーバ１０は、会員端末３０及び加盟店端末４０に注文を受け付けた旨の確認メールを送信し、会員（購入者）及び加盟店（販売者）に注文を受け付けた旨を通知する（Ｓ３１０，Ｓ３１５）。なお、会員端末３０及び加盟店端末４０に対する電子メールはほぼ同時に送信される。
上記通知を受けると、加盟店（担当者）は、加盟店端末４０を用いて仮想商店街管理サーバ１０にログインし、注文内容の確認ページを要求する。加盟店端末４０から確認ページの要求があると、仮想商店街管理サーバ１０は注文内容の確認ページを加盟店端末４０に送信し、加盟店に注文内容の確認を求める（Ｓ３２０）。加盟店（担当者）は、受信した注文内容の確認ページにおいて、注文内容を確認する。

その後、何らかの理由で注文内容（金額）に変更が生じる場合には、加盟店（担当者）と会員との間で、仮想商店街管理サーバ１０を介さずに、電話，メール等により直接交渉をする（Ｓ３２５）。この直接交渉は、加盟店側の事情（例えば、所定の送料の加算），会員側の事情（ラッピングの追加，注文数の変更）のいずれかが契機となる。
上記の直接交渉により修正内容（修正金額）が定まると、加盟店（担当者）は、加盟店端末４０を用いて仮想商店街管理サーバ１０にログインし、注文内容（金額）の修正ページを要求する。加盟店端末４０から修正ページの要求があると、仮想商店街管理サーバ１０は注文内容の修正ページを加盟店端末４０に送信し、加盟店端末４０からの注文内容（金額）の修正を受け付ける（Ｓ３３０）。

注文内容（金額）の修正を受け付けると、仮想商店街管理サーバ１０は、注文内容の変更処理を行なう（Ｓ３３５）。ここでは、注文の受付処理（Ｓ３０５）により生成した注文情報に、受け付けた修正をそのまま反映させる。
注文内容の変更処理が完了すると、仮想商店街管理サーバ１０は、会員端末３０及び加盟店端末４０に注文内容を変更した旨の電子メールを送信し、会員及び加盟店に注文内容を変更した旨を通知する（Ｓ３４０，Ｓ３４５）。なお、会員端末３０及び加盟店端末４０に対する電子メールはほぼ同時に送信される。
以上の処理が完了すると、受け付けた注文は、変更された金額により決済可能になる。この後、会員と加盟店との間で、決済方法の選択処理（図２のＳ２１５）において選択された方法により代金の決済が行なわれる。

（４）従来のシステムの問題点
このように、仮想商店街を利用する取引においては、注文受付後に注文内容を修正する場合、取引の当事者間で、電話，メール等により直接交渉をするという方法が採られていた。そのため、注文内容が修正される過程は、請求金額の大幅な増額につながるような場合であっても、仮想商店街を管理運営するシステムに記録として残らなかった。こうした状況が、取引の当事者間における取引内容をめぐるトラブルの温床となっていた。
とりわけ、決済方法の選択処理（図２のＳ２１５）において、決済機関を介して行なわれる決済方法であって金銭の支払に会員（購入者）が能動的に関与しないもの（例えば、クレジットカード等）が選択されている場合、会員には代金の支払を保留又は拒否するための選択機会がない。そのため、修正後の金額で決済が行なわれることになると、商品を購入した会員が不測の不利益を被るおそれがある。

本発明は、仮想商店街サービスにおいて、注文受付後の注文内容の修正が妥当であることを記録として残す仕組みを提供することを課題とする。

上記課題を解決するため、本発明は、仮想商店街の加盟店と会員との間の取引を支援する仮想商店街管理システムにおける注文情報の修正処理であって、前記加盟店の端末から前記注文情報に関する修正情報を受信する修正情報受信手段と、前記修正情報をもとに請求金額に所定金額を越える変更が生じると判定したとき、該所定金額を越える変更に対する承認を依頼する電子メールを、前記加盟店に注文した前記会員の端末に送信する変更承認依頼メール送信手段と、前記変更承認依頼メール送信手段により送信された電子メールを受け取った前記会員の端末から前記所定金額を越える変更に対する承認情報又は否認情報を受信する認否情報受信手段と、前記認否情報受信手段が承認情報を受信したときに前記注文情報の修正を確定し、否認情報を受信したときに前記注文情報を取り消す注文確定手段とを備えることを特徴とする。
前記認否情報受信手段が所定期間内に承認情報及び否認情報の何れも受信しないとき、前記注文確定手段は、前記注文情報を取り消すこととしてもよい。
前記認否情報受信手段が所定期間内に承認情報及び否認情報の何れも受信しないとき、前記変更承認依頼メール送信手段は、前記会員の端末に前記所定金額を越える変更に対する承認を依頼する電子メールを再度送信することとしてもよい。
前記仮想商店街管理システムにおいて、さらに、前記注文確定手段が前記注文情報の修正を確定したとき、前記取引に係る決済処理を所定の決済機関に依頼する決済処理依頼手段を備えることとしてもよい。

また、本発明は、仮想商店街の加盟店と会員との間の取引を支援する仮想商店街管理システムにおける注文情報の修正方法であって、前記加盟店の端末から前記注文情報に関する修正情報を受信する修正情報受信ステップと、前記修正情報をもとに請求金額に所定金額を越える変更が生じると判定したとき、該所定金額を越える変更に対する承認を依頼する電子メールを、前記加盟店に注文した前記会員の端末に送信する変更承認依頼メール送信ステップと、前記変更承認依頼メール送信ステップにより送信された電子メールを受け取った前記会員の端末から前記所定金額を越える変更に対する承認情報又は否認情報を受信する認否情報受信ステップと、前記認否情報受信ステップで承認情報を受信したときに前記注文情報の修正を確定し、否認情報を受信したときに前記注文情報を取り消す注文確定ステップとを含むことを特徴とする。
前記仮想商店街管理システムの各手段をコンピュータに機能として実現させるためのプログラムも本発明である。

本発明の仮想商店街管理システムは、請求金額の大幅な変更につながる注文内容の修正については、購入者の承認を要することとしている。これにより、注文内容の修正について購入者の承認が得られているという情報を記録として残すことができる。
その効果として、取引の当事者間における取引内容をめぐるトラブルを未然に防止することが可能となる。また、実際にトラブルが発生したとしても、記録内容を活用することにより、収拾がつかなくなるという事態を回避することができる。

以降、本発明の実施形態の一例を、図４〜図１２を参照して説明する。
本実施形態のシステムは、請求額の大幅な増額につながる注文内容の修正について、商品の購入者の承認を要することとしている。
前提として、本実施形態のシステムが提供する仮想商店街サービスは、利用登録をしているユーザ（会員）と出店登録をしている店舗（加盟店）との間で行なわれる取引を対象としている。なお、これは運用の一形態であり、サービスの対象となる取引を拡大（例えば、未登録のユーザを当事者とする取引に拡大）してもよい。

以下の説明は、注文内容（請求金額）の変更が確定した後に、会員が口座を有する銀行を介して口座振替による決済が行なわれる場合の例を用いている。口座振替は、決済機関（銀行）を介して行なわれる決済方法であり、取引成立後に代金が会員の口座から自動的に引き落とされるという点で「金銭の支払に会員（購入者）が能動的に関与しない」決済方法に該当する。
なお、本実施形態では、会員（購入者）の銀行口座から代金を引き落とし、加盟店（販売者）の銀行口座に代金を払い込む決済方法を「口座振替」という。

＜本実施形態の説明＞
（１．本実施形態のシステムの構成）
本実施形態のシステムの構成を、図４及び図５を用いて説明する。
本実施形態のシステムの構成は、銀行のサーバが加わった点を除き、基本的に図１に示す従来のシステムの構成と同様である。ここでは、仮想商店街管理サーバに構築されているデータベースについて詳しく説明する。

（１−１．仮想商店街管理サーバ）
図４において、仮想商店街管理サーバ１０は、注文の受付から取引の完了までを総合的に管理するサーバである。ここでは、本実施形態のシステムに関して必要な部分を説明する。

（１−２．会員情報データベース）
図４において、会員情報データベース１１は、本実施形態のシステムが提供するサービスを利用して商品を購入するユーザの情報（以下、「会員情報」という。）を記憶しているデータベースである。ここでは、本実施形態のシステムに関して必要な部分のみを説明する。
なお、本実施形態においては、会員情報データベース１１を仮想商店街管理サーバ１０に内蔵された記憶装置に構築しているが、記憶している情報の読出しが可能であれば他の独立した記憶装置に構築してもよい。

図５（ａ）に、会員情報データベース１１の主要な項目を示す。
図５（ａ）において、「会員ＩＤ」は、利用登録をしている会員に一意の識別情報である。「パスワード」は、その会員の認証に用いるパスワードである。「メールアドレス」は、その会員が用いる会員端末３０（後述）のメールアドレスである。「個人情報」は、その会員の個人情報（例えば、氏名，性別，住所，電話番号等）である。
なお、会員の認証（ログイン）には、会員情報の項目のうち「会員ＩＤ」及び「パスワード」を用いる。

（１−３．加盟店情報データベース）
図４に戻り、加盟店情報データベース１２は、本実施形態のシステムが提供するサービスに出店して商品を販売する店舗の情報（以下、「加盟店情報」という。）を記憶しているデータベースである。ここでは、本実施形態のシステムに関して必要な部分のみを説明する。
なお、本実施形態においては、加盟店情報データベース１２を仮想商店街管理サーバ１０に内蔵された記憶装置に構築しているが、記憶している情報の読出しが可能であれば他の独立した記憶装置に構築してもよい。

図５（ｂ）に、加盟店情報データベース１２の主要な項目を示す。
図５（ｂ）において、「加盟店ＩＤ」は、出店登録をしている店舗に一意の識別情報である。本実施形態では、加盟店ＩＤとしてその加盟店のドメイン名を使用している。「認証キー」は、その加盟店の認証に用いるキーである。「メールアドレス」は、その加盟店が用いる加盟店端末４０（後述）のメールアドレスである。「担当者ＩＤ」は、その加盟店における受注管理業務の担当者の識別情報であり、少なくとも１つ登録されている。「店舗情報」は、その加盟店の店舗の情報（例えば、名称，店舗の詳細を掲載したウェブページのＵＲＬ等）である。
なお、加盟店の認証（ログイン）には、加盟店情報の項目のうち「加盟店ＩＤ」，「担当者ＩＤ」及び「認証キー」を用いる。

（１−４．商品情報データベース）
図４に戻り、商品情報データベース１３は、本実施形態のシステムが提供するサービスにおいて取り扱われている商品の情報（以下、「商品情報」という。）を記憶しているデータベースである。ここでは、本実施形態のシステムに関して必要な部分のみを説明する。
なお、本実施形態においては、商品情報データベース１３を仮想商店街管理サーバ１０に内蔵された記憶装置に構築しているが、記憶している情報の読出しが可能であれば他の独立した記憶装置に構築してもよい。

図５（ｃ）に、商品情報データベース１３の主要な項目を示す。
図５（ｃ）において、「商品コード」は、本実施形態のシステムが提供するサービスにおいて取り扱われている商品に一意の識別情報である。「名称」は、その商品の名称である。「単価」は、その商品に設定された単位数量あたりの価格である。「商品関連情報」は、その商品に関連する情報（例えば、取扱店舗のＩＤ（加盟店ＩＤ）等）である。

（１−５．注文情報データベース）
図４に戻り、注文情報データベース１４は、本実施形態のシステムが提供するサービスにおいて受け付けた注文の情報（以下、「注文情報」という。）を記憶しているデータベースである。ここでは、本実施形態のシステムに関して必要な部分のみを説明する。
なお、「注文情報」には、「会員情報」，「加盟店情報」及び「商品情報」が紐付けられている。
また、本実施形態においては、注文情報データベース１４を仮想商店街管理サーバ１０に内蔵された記憶装置に構築しているが、記憶している情報の読出しが可能であれば他の独立した記憶装置に構築してもよい。

図５（ｄ）に、注文情報データベース１４の主要な項目を示す。
図５（ｄ）において、「注文番号」は、本実施形態のシステムが提供するサービスを利用した注文に一意の識別情報である。「注文日時」は、その注文を受け付けた日時である。「会員ＩＤ」は、その注文をした会員の識別情報であり、注文情報に会員情報を紐付けている。「加盟店ＩＤ」は、その注文を受けた加盟店の識別情報であり、注文情報に加盟店情報を紐付けている。
同じく、図５（ｄ）において、「商品コード」は、その注文に係る商品の識別情報であり、注文情報に商品情報を紐付けている。「数量」は、その商品の注文数である。「請求金額」は、その注文において請求される金額の合計値である。「決済方法」は、その注文の決済方法（例えば、銀行振込，代金引換，クレジットカード，口座振替等）である。「受注処理ステータス」は、その注文の受注処理の進捗状況を示す区分（例えば、「新規受付」，「発送待ち」，「完了」，「取消」等）である。「決済処理ステータス」は、その注文の決済処理の進捗状況を示す区分（例えば、「未処理」，「振替依頼待ち」，「未承認」，「残高確認待ち」，「払込準備中」，「振替不能」，「完了」，「払込不能」等）である。なお、本実施形態においては、「受注処理ステータス」の初期値を「新規受付」とし、「決済処理ステータス」の初期値を「未処理」とする。

同じく、図５（ｄ）において、「修正日時」は、その注文情報について修正がされた日時である。「修正金額」は、その注文情報の修正後の請求金額である。「金額変更承認フラグ」は、その金額変更につき会員から承認が得られているか否かを示すフラグである。
なお、「修正日時」，「修正金額」及び「金額変更承認フラグ」は、注文内容の修正を受け付けた場合にのみ設ける項目であり、修正がない場合にはこれらの項目は設けない。また、注文内容が複数回にわたって修正された場合には、その修正ごとに「修正日時」，「修正金額」及び「金額変更承認フラグ」を設ける。

（１−６．会員端末）
図４に戻り、会員端末３０は、本実施形態のシステムが提供するサービスを利用して商品を購入するユーザ（会員）が用いる端末である。本実施形態においては、例えば、パソコンや携帯電話等の通信機能を有する端末とする。
会員端末３０はブラウザを有しており、インターネット等のネットワーク２０を介して仮想商店街管理サーバ１０に接続することにより、本実施形態のシステムを介して任意の加盟店に商品を注文することができる。

（１−７．加盟店端末）
加盟店端末４０は、本実施形態のシステムが提供するサービスを利用して商品を販売する店舗（加盟店）が用いる端末である。本実施形態においては、例えば、パソコンや携帯電話等の通信機能を有する端末とする。
加盟店端末４０はブラウザを有しており、インターネット等のネットワーク２０を介して仮想商店街管理サーバ１０に接続することにより、本実施形態のシステムを介して商品の注文を管理することができる。

（１−８．銀行サーバ）
銀行サーバ５０は、本実施形態のシステムにおいて口座振替による決済処理を行なう銀行のサーバである。銀行サーバ５０は、専用線２１を介して仮想商店街管理サーバ１０と接続しており、決済処理に関して仮想商店街管理サーバ１０と連携している。また、銀行サーバ５０と仮想商店街管理サーバ１０との間では、データを暗号化して送受信している。
なお、本実施形態では、仮想商店街管理サーバ１０と銀行サーバ５０は専用線２１を介して接続しているが、暗号化等によりデータを安全に送受信することができる限り、インターネット等のネットワーク２０を介して接続してもよい。

（２．本実施形態のシステムによる処理の流れ）
本実施形態のシステムにおいて請求金額の大幅な変更につながる注文内容の修正がされて会員に金額変更に対する承認を求める場合の処理の流れを、図６のシーケンス図を用いて説明する。
本実施形態のシステムによる注文内容の修正処理は、図３に示した従来のシステムによる処理と比較して、主として下記の２点において相違する。
（ａ）本実施形態のシステムは、注文の受付後に加盟店から請求金額の大幅な増額につながる注文内容の修正を受け付けた場合、その注文をした会員に承認を求める（Ｓ６３０ａ〜Ｓ６３５ａ）。
（ｂ）本実施形態のシステムは、加盟店から決済（口座振替）処理の依頼を受け付けた後に会員に承認を求め、会員から承認が得られると加盟店に再確認をすることなく決済（口座振替）処理を開始する（Ｓ６２５ａ〜Ｓ６４５ａ）。
なお、図６のシーケンス図は、図２に示す処理により商品が注文された後の処理を示している。また、決済方法の選択処理（図２のＳ２１５）において口座振替が選択されているものとする。

（２−１．注文の受付）
図６に示すように、仮想商店街管理サーバ１０は、選択された商品の情報等をもとに注文の受付処理を行なう（Ｓ６０５）。ここでは、注文番号（図２のＳ２２５により付与した番号）ごとに注文情報（図５（ｄ）参照）を生成し、注文情報データベース１４に記憶する。
注文の受付処理が完了すると、仮想商店街管理サーバ１０は、会員端末３０及び加盟店端末４０に注文を受け付けた旨の確認メールを送信し、会員及び加盟店に注文を受け付けた旨を通知する（Ｓ６１０１，Ｓ６１０２）。

（２−２．修正の受付）
上記通知があると、加盟店（担当者）は、加盟店端末４０を用いて仮想商店街管理サーバ１０にログインし、注文内容の確認ページを要求する。加盟店端末４０から確認ページの要求があると、仮想商店街管理サーバ１０は注文内容の確認ページを加盟店端末４０に送信し、加盟店に注文内容の確認を求める。加盟店（担当者）は、この確認ページで注文内容を確認し、必要があればこの確認ページから修正ページを要求する。
加盟店端末４０から修正ページの要求があると、仮想商店街管理サーバ１０は注文内容の修正ページを加盟店端末４０に送信し、加盟店端末４０から注文内容の修正情報を受け付ける（Ｓ６１５）。加盟店（担当者）は、この修正ページに必要な修正を入力する。
なお、注文内容の修正の受付の前には、従来例（図３のＳ３２５）と同様に、加盟店（担当者）と会員との間で、電話，メール等により直接交渉がされている場合もある。これは、上述のように、請求金額の大幅な変更につながる注文内容の修正として様々な契機（加盟店側の事情，会員側の事情）が考えられるからである。

（２−３．決済処理の依頼の受付）
注文内容の修正情報を受け付けると、仮想商店街管理サーバ１０は、加盟店端末４０に決済処理の依頼ページを送信し、加盟店（担当者）に修正後の金額による決済処理（本実施形態では、口座振替処理）の依頼を求める（Ｓ６２５ａ）。加盟店（担当者）は、受信した決済処理の依頼ページから修正後の金額による決済（口座振替）処理を依頼する。
なお、本実施形態のシステムは、加盟店から決済処理の依頼があったときに、会員に承認を得るための処理を行なう。そのため、請求金額の大幅な変更につながる注文内容の修正があった場合には、加盟店に修正後の金額による決済処理の依頼を例外なく求めることとしている。

（２−４．承認の依頼）
加盟店端末４０から修正後の金額による決済処理の依頼を受け付けると、仮想商店街管理サーバ１０は、会員端末３０に請求金額の大幅な変更につながる注文内容の修正を受け付けた旨の電子メールを送信し、会員に金額の変更に対する承認を依頼する（Ｓ６３０ａ）。
上記依頼を受けた会員は、会員端末３０を用いて仮想商店街管理サーバ１０にログインし、購入履歴の確認ページを要求する。会員端末３０から確認ページの要求があると、仮想商店街管理サーバ１０は購入履歴の確認ページを会員端末３０に送信し、会員に金額の変更に対する認否の応答を求める（Ｓ６３５ａ）。会員は、この購入履歴の確認ページで修正内容を確認し、金額の変更に対する認否を応答する。

（２−５．注文内容の変更・決済処理の開始）
会員端末３０から金額の変更に対する承認の応答があると、仮想商店街管理サーバ１０は、会員から確認がとれたため、注文内容の変更を確定させた上で、銀行サーバ５０に対して所定の口座振替処理を依頼する（Ｓ６４５ａ）。ここでは、会員が口座を有する銀行のサーバ５０に対して、所定の口座振替処理を依頼する。
このように、本実施形態のシステムは、会員から金額の変更に対する承認が得られると、加盟店（担当者）に再確認を求めることなく、決済（口座振替）処理を開始することとしている。そのため、加盟店（担当者）は、本実施形態のシステムを利用することにより、注文内容の修正について会員から承認が得られたか否かを確認する手間を省くことができる。
注文内容の変更処理が完了すると、仮想商店街管理サーバ１０は、会員端末３０及び加盟店端末４０に注文を変更した旨の電子メールを送信し、会員及び加盟店に注文を変更した旨を通知する（Ｓ６５０ａ１，Ｓ６５０ａ２）。

（３．本実施形態のシステムによる処理の詳細）
本実施形態のシステムにおける仮想商店街管理サーバによる処理の詳細を、図７のフローチャート及び図８〜図１２のページ・メールの例を用いて説明する。
本実施形態においては、請求金額の大幅な変更に当たるか否かの基準となる閾値（所定金額）を「１，０００円」としている。なお、この閾値は適宜変更することができる。
以降、仮想商店街管理サーバによる処理の流れを、図７のフローチャートを用いて説明する。なお、図７には、参照すべき他の図面の番号を示している。また、図６と図７で符号が一致している処理は、それぞれ同一の処理であるものとする。

（３−１．注文の受付）
図７に示すように、仮想商店街管理サーバ１０は、選択された商品の情報等をもとに、注文の受付処理を行なう（Ｓ６０５）。ここでは、注文番号（図２のＳ２２５により付与した番号）をキーとして注文情報（図５（ｄ）参照）を生成し、注文情報データベース１４に記憶する。また、注文情報の「受注処理ステータス」を初期値の「新規受付」とし、「決済処理ステータス」を初期値の「未処理」とする。
注文の受付処理が完了すると、仮想商店街管理サーバ１０は、会員端末３０及び加盟店端末４０に注文を受け付けた旨の電子メールを送信し、会員及び加盟店に注文を受け付けた旨を通知する（Ｓ６１０）。なお、会員端末３０及び加盟店端末４０に対する電子メールはほぼ同時に送信される。

（３−２．修正の受付）
上記通知があると、加盟店（担当者）は、加盟店端末４０を用いて仮想商店街管理サーバ１０にログインし、注文内容の確認ページを要求する。加盟店端末４０から確認ページの要求があると、仮想商店街管理サーバ１０は注文内容の確認ページを加盟店端末４０に送信し、加盟店に注文内容の確認を求める。加盟店（担当者）は、受信した確認ページにおいて注文内容を確認し、必要であれば注文内容の修正ページを要求する。
加盟店端末４０から修正ページの要求があると、仮想商店街管理サーバ１０は注文内容の修正ページを加盟店端末４０に送信し、加盟店端末４０から注文内容の修正情報を受け付ける（Ｓ６１５）。加盟店（担当者）は、この修正ページに必要な修正を入力する。

図８に注文内容の修正ページを例示する。修正ページ８００は、注文番号「１２３４５６−２００７０６０１−１２３４５６」の注文内容を個別に確認・修正するためのページである。
修正ページ８００は、注文内容の確認修正欄８１０及びボタン８２０により構成される。
注文内容の確認修正欄８１０には、注文番号に対応する注文情報が表示される。ここでは、注文情報に紐付けられた会員情報及び商品情報、並びに「数量」，「請求金額」等が表示されている。
注文内容を変更する場合には、変更する項目の表示欄に変更後の内容を入力し、「この内容で保存する」と表示されているボタン８２０をクリックする。

図７に戻り、加盟店端末４０から注文内容の修正を受け付けると、仮想商店街管理サーバ１０は、受け付けた修正内容をもとに、注文の受付処理（Ｓ６０５）により生成した注文情報を更新する。ここでは、「修正日時」，「修正金額」及び「金額変更承認フラグ」の項目を追加し、「決済処理ステータス」を「振替依頼待ち」とする。なお、この時点では、「金額変更承認フラグ」は立てない。
また、受け付けた修正情報をもとに、変更前後の差額を計算し、その差額が所定金額（１０００円）以上となるか否かを判定する（Ｓ６２０）。

（３−３．決済依頼の受付）
変更前後の差額が所定金額（１０００円）以上であると判定したとき（Ｓ６２０でＹｅｓ）、仮想商店街管理サーバ１０は、決済処理の依頼ページを生成して加盟店端末４０に送信し、加盟店に決済処理の依頼を求める（Ｓ６２５ａ）。このとき送信される決済処理の依頼ページには、決済処理の前に会員に金額変更に対する承認の依頼が通知される旨を表示する。
一方、変更前後の差額が所定金額（１０００円）以上でないと判定したとき（Ｓ６２０でＮｏ）、仮想商店街管理サーバ１０は、注文情報の「金額承認フラグ」を立てた上で、決済処理の依頼ページを生成して加盟店端末４０に送信し、加盟店に決済処理の依頼を求める（Ｓ６２５ｂ）。このとき送信される決済処理の依頼ページには、決済処理の前に会員に金額変更に対する承認の依頼が通知される旨を表示しない。

図９（ａ）に、変更前後の差額が所定金額（１０００円）以上であると判定されたときに加盟店端末４０に送信される決済処理の依頼ページを例示する。
決済処理の依頼ページ９００ａは、注文情報表示欄９１０ａ及び決済処理を依頼するためのボタン９２０ａにより構成されている。
注文情報表示欄９１０ａには、決済処理の対象となっている注文情報の「注文番号」及び「決済処理ステータス」が表示される。また、「ユーザへ金額確認あり」と表示されている欄９１１ａにアイコンを表示することにより、決済処理の前に会員に金額変更に対する承認の依頼が通知される旨を表示する。
決済処理の依頼ページ９００ａにおいて、「口座振替を依頼する」と表示されているボタン９２０ａがクリックされると、仮想商店街管理サーバ１０は、後述のように会員端末３０に金額変更に対する承認の依頼メールを送信する（後述のＳ６３０ａ）。

図９（ｂ）に、変更前後の差額が所定金額（１０００円）以上でないと判定されたときに加盟店端末４０に送信される決済処理の依頼ページを例示する。決済処理の依頼ページ９００ｂは、決済処理の依頼ページ９００ａと同様のものである。ただし、上述の「ユーザへ金額確認あり」と表示されている欄９１１ａに対応する欄９１１ｂには、アイコンが表示されない。
決済処理の依頼ページ９００ｂにおいて、「口座振替を依頼する」と表示されているボタン９２０ｂがクリックされると、仮想商店街管理サーバ１０は、会員から金額変更に対する承認を得る必要がないので、直ちに決済処理を開始する（後述のＳ６４５ａ）。

（３−４．承認の依頼）
図７に戻り、変更前後の差額が所定金額（１０００円）以上であると判定された場合（Ｓ６２０でＹｅｓ）、加盟店端末４０から決済処理の依頼情報を受け付けると、仮想商店街管理サーバ１０は、会員端末３０に金額の大幅な変更につながる注文内容の修正を受け付けた旨の電子メールを送信し、会員に金額の変更に対する承認を依頼する（Ｓ６３０ａ）。このとき、注文情報の「決済処理ステータス」を「未承認」とする。
なお、本実施形態においては、この処理を定期的なバッチ処理（例えば、５分ごとのバッチ処理）で行なっているが、他のタイミングで行なってもよい。

図１０に金額変更に対する承認依頼メールを例示する。承認依頼メール１０００は、加盟店（担当者）が、修正ページ８００（図８）において数量表示欄８１１に「２」を入力してボタン８２０をクリックした後、送信されてきた決済依頼の依頼ページ９００ａ（図９（ａ））において「口座振替を依頼する」と表示されているボタン９２０ａをクリックすることにより決済処理の依頼を行なったときに、会員端末３０に送信されるメールである。
承認依頼メール１０００において、宛先欄１０１０には会員端末３０のメールアドレスが表示される。メールアドレスは、注文情報に紐付けられた会員情報から取得する。件名欄１０２０には、金額変更に対する承認依頼である旨を判別しやすい件名が表示される。

本文欄１０３０には、承認の対象となる注文の識別情報（１０３１），承認の依頼文（１０３２），承認の手順（１０３３），問合せ先等の注意事項（１０３４）等が表示される。また、本実施形態においては、金額変更に対する承認に期限（ここでは、修正の受付から３日以内）を設けており、期限内に承認がされないと注文が取消（キャンセル）となる旨の注意を表示する（１０３５）。
なお、注文の識別情報（１０３１）の［注文詳細］、又は承認の手順（１０３３）の［１］に表示されているＵＲＬは、依頼の対象となっている注文に係る確認ページへのリンクとなっている。そのため、会員は、会員端末３０上でこのリンクをクリックするだけで、依頼の対象となる注文に係る確認ページを受信することができる。

図７に戻り、上記依頼を受けた会員は、会員端末３０を用いて仮想商店街管理サーバ１０にログインし、購入履歴の確認ページを要求する。会員端末３０から確認ページの要求があると、仮想商店街管理サーバ１０は購入履歴の確認ページを会員端末３０に送信する。会員は、この購入履歴の確認ページにおいて注文内容を確認し、会員端末３０から金額変更に対する認否の選択ページを要求する。
会員端末３０から金額変更に対する認否の選択ページの要求があると、仮想商店街管理サーバ１０は金額変更に対する認否の選択ページを会員端末３０に送信し、会員から金額の変更に対する承認又は否認の応答を受け付ける（Ｓ６３５ａ）。会員は、この購入履歴の確認ページで修正内容を確認し、金額の変更に対する認否を応答する。

図１１に、購入履歴の確認ページを例示する。確認ページ１１００は、承認依頼メール１０００（図１０）の注文の識別情報（１０３１）の［注文詳細］、又は承認の手順（１０３３）の［１］に表示されているＵＲＬがクリックされたときに、会員端末３０に送信されるページである。
確認ページ１１００は、金額等表示欄１１１０，注文情報表示欄１１２０及び金額変更に対する認否の選択ページを要求するためのボタン１１３０により構成される。
金額等表示欄１１１０には、商品情報、及び注文情報の「数量」，「請求金額」等が表示される。注文情報表示欄１１２０には、注文情報の「注文番号」，「注文日時」，「決済方法」のほか、注文者の情報が表示される。
会員が「決済金額の確認」と表示されているボタン１１３０をクリックすると、会員端末３０から仮想商店街管理サーバ１０に金額変更に対する認否の選択ページを要求する。

図１２に、金額変更に対する認否の選択ページを例示する。選択ページ１２００は、確認ページ１１００（図１１）においてボタン１１３０がクリックされたときに、会員端末３０に送信されるページである。
選択ページ１２００は、金額等表示欄１２１０並びに金額承認ボタン１２２０ａ及び注文キャンセルボタン１２２０ｂにより構成される。
金額等表示欄１２１０には、注文時の金額，変更後の金額及び差額が表示される。本実施形態では、この差額が所定金額（１，０００円）以上であるときに会員の承認を要することとしている。
会員が「金額承認」と表示されているボタン１２２０ａをクリックすると、会員端末３０から仮想商店街管理サーバ１０に金額変更に対する承認の応答が送信される。一方、会員が「キャンセル」と表示されているボタン１２２０ｂをクリックすると、会員端末３０から仮想商店街管理サーバ１０に金額変更に対する否認の応答が送信される。
なお、本実施形態では、金額の否認を注文の取消（キャンセル）として扱うため、金額の変更のみを否認するという選択肢は用意していない。

（３−５．口座振替処理の依頼・注文の取消）
図７に戻り、会員端末３０から応答を受信すると、仮想商店街管理サーバ１０は、承認がされたか否かを判定する（Ｓ６４０ａ）。
会員端末３０からの応答が承認であると判定したとき（Ｓ６４０ａでＹｅｓ）、仮想商店街管理サーバ１０は、注文内容の修正が妥当であると判断し、注文内容の変更を確定させた上で、銀行サーバ５０に口座振替処理を依頼する（Ｓ６４５ａ）。
ここでは、注文の受付処理（Ｓ６０５）により生成した注文情報を修正された内容に更新するとともに、「受注処理ステータス」を「発送待ち」と、「決済処理ステータス」を「残高確認待ち」とする。また、「金額変更承認フラグ」を立てる。
注文内容の変更が確定すると、仮想商店街管理サーバ１０は、会員端末３０及び加盟店端末４０に注文を変更した旨の電子メールを送信し、会員及び加盟店に注文を変更した旨を通知する（Ｓ６５０ａ）。なお、会員及び加盟店に対する通知は、例えば日次バッチ処理により翌日に一括して送信される。

一方、会員端末３０からの応答が否認であると判定したとき（Ｓ６４０ａでＮｏ）、仮想商店街管理サーバ１０は、注文内容の修正が妥当でないと判断し、注文の取消処理を行なう（Ｓ６４５ｂ）。ここでは、注文の受付処理（Ｓ６０５）により生成した注文情報の「受注処理ステータス」を「取消」とする。「金額変更承認フラグ」は立てない。
また、所定期間（例えば、３日間）内に会員端末３０から応答を受信しないときにも、仮想商店街管理サーバ１０は、注文内容の修正が妥当でないと判断し、注文の取消処理を行なう。この場合、仮想商店街管理サーバ１０は、日次バッチ処理の際に注文情報データベース１４を検索し、注文内容の修正があるにもかかわらず会員の承認が得られないまま所定期間を経過している注文情報（「受注処理ステータス」が「発送待ち」であり、「決済処理ステータス」が「未承認」であり、かつ「金額変更承認フラグ」が立っていない情報のうち、「修正日時」から所定期間を経過しているもの）を読み出す。そして、読み出した注文情報について、上述の注文の取消処理（Ｓ６４５ｂ）と同様の処理を行なう。
注文の取消処理が完了すると、仮想商店街管理サーバ１０は、会員端末３０及び加盟店端末４０に注文が取消された旨の電子メールを送信し、会員及び加盟店に注文が取消された旨を通知する（Ｓ６５０ｂ）。なお、会員及び加盟店に対する通知は、日次バッチ処理により翌日に一括して送信される。

＜他の実施形態１＞
上述の実施形態においては、加盟店から決済処理の依頼があったときに、会員に承認を得るための処理を行なうこととしている。これは、決済機関を介して決済が行なわれる場合、注文内容（請求金額）が変更された後に会員には代金の支払を保留又は拒否するための選択機会がないので、修正後の金額で安全に決済を行なうためには会員から事前に承認を得ておく処理が有効だからである。
これに対し、加盟店端末４０から注文内容の修正情報を受け付けたときに、会員に承認を得るための処理を行なうこととしてもよい。
この場合、例えば図７に示す処理においては、加盟店端末４０から注文内容の修正情報を受け付け（Ｓ６１５）、修正前後の請求金額の変更額が所定金額以上か否かを判定する（Ｓ６２０）と、決済処理の依頼を受け付ける処理（Ｓ６２５ａ）を行なわずに、会員端末３０に金額変更の承認を依頼する電子メールを送信する（Ｓ６３０ａ）。これにより、加盟店から注文内容の修正情報を受け付けたときに、会員に承認を得るための処理を行なうことができる。

＜他の実施形態２＞
上述の実施形態においては、会員端末３０又は加盟店端末４０がパソコン等の端末である場合を想定していた。これに対し、会員端末３０又は加盟店端末４０が携帯電話等のモバイル端末である場合には、その性質に応じてパソコン等の端末と異なるページ及びメールを提供することとしてもよい。
図１３〜図１５に例示するメール又はページは、いずれも、会員端末３０又は加盟店端末４０が携帯電話等のモバイル端末であることを前提として、全体としてコンパクトになっている。

図１３に、モバイル端末宛の金額変更に対する承認依頼メールを例示する。承認依頼メール１３００は、承認依頼メール１０００（図１０）に対応している。
承認依頼メール１３００において、宛先欄１３１０には会員端末３０のメールアドレスが表示される。メールアドレスは、注文情報に紐付けられた会員情報から取得する。件名欄１３２０には、金額変更に対する承認依頼である旨を判別しやすい件名が表示される。
本文欄１３３０には、承認の依頼文（１３３１）及び期限内に承認がされないと注文が取消（キャンセル）となる旨の注意（１３３２）が表示される。
なお、承認の依頼文（１３３１）の下に表示されているＵＲＬは、依頼の対象となっている注文に係る確認ページではなく、購入履歴のトップページへのリンクとなっている。これは、依頼の対象となっている注文に係る確認ページへのリンクとすると、ＵＲＬが長くなってしまうからである。

図１４に、モバイル端末用の購入履歴の確認ページを例示する。確認ページ１４００は、確認ページ１１００（図１１）に対応している。なお、確認ページ１４００は、承認依頼メール１３００（図１３参照）の承認の依頼文（１３３１）の下に表示されているＵＲＬがクリックされたときに会員端末３０に送信されるログインページでの会員認証を経て、依頼の対象となっている注文に係る購入履歴の確認ページを要求したときに、会員端末３０に送信されるページである。
確認ページ１４００は、金額等表示欄１４１０，注文情報表示欄１４２０及び金額変更に対する認否の選択ページを要求するためのボタン１４３０により構成される。
金額等表示欄１４１０には、商品情報、及び注文情報の「請求金額」等が表示される。注文情報表示欄１４２０には、注文情報の「注文番号」，「注文日時」，「決済方法」のほか、注文者の情報が表示される。
会員が「決済金額の確認」と表示されているボタン１４３０をクリックすると、会員端末３０から仮想商店街管理サーバ１０に金額変更に対する認否の選択ページを要求する。

図１５に、金額変更に対する認否の選択ページを例示する。選択ページ１５００は、選択ページ１２００（図１２）に対応している。なお、選択ページ１５００は、確認ページ１４００（図１４）においてボタン１４３０がクリックされたときに、会員端末３０に送信されるページである。
選択ページ１５００は、金額等表示欄１５１０並びに金額承認ボタン１５２０ａ及び注文キャンセルボタン１５２０ｂにより構成される。
金額等表示欄１５１０には、注文時の金額，変更後の金額及び差額が表示される。本実施形態では、この差額が所定金額（１，０００円）以上であるときに会員の承認を要することとしている。
会員が「金額承認」と表示されているボタン１５２０ａをクリックすると、会員端末３０から仮想商店街管理サーバ１０に金額変更に対する承認の応答が送信される。一方、会員が「キャンセル」と表示されているボタン１５２０ｂをクリックすると、会員端末３０から仮想商店街管理サーバ１０に金額変更に対する否認の応答が送信される。
なお、本実施形態では、金額の否認を注文の取消（キャンセル）として扱うため、金額の変更のみを否認するという選択肢は用意していない。

＜他の実施形態３＞
上述の実施形態においては、仮想商店街管理サーバ１０は、請求金額の大幅な変更につながる注文内容の修正を受け付けた後、決済処理の依頼を受け付けたとき、会員端末３０に対して１度だけ金額変更に対する承認を依頼するメールを送信している。これに対し、所定期間（例えば、２４時間）内に会員端末３０から応答がない場合は、金額変更に対する承認を依頼するメールを再度送信し、会員に金額変更の承認を催促することとしてもよい。なお、この「応答がない場合に金額変更の承認を催促するか否かを判断するための基準となる期間」は、上述の「応答がない場合に注文の取消処理を行なうか否かを判断するための基準となる期間」よりも短い期間とする。
この場合、仮想商店街管理サーバ１０は、上述の日次バッチ処理の際に、注文情報データベース１４を検索し、注文内容の修正があるにもかかわらず会員の承認が得られていない注文情報（「受注処理ステータス」が「発送待ち」であり、「決済処理ステータス」が「未承認」であり、かつ「金額変更承認フラグ」が立っていない情報のうち、「修正日時」から所定期間を経過しているもの）を読み出す。そして、読み出した注文情報からその注文をした会員を特定し、その会員の会員端末３０に金額変更に対する承認の依頼メールを再度送信する。

従来のシステムの構成例を示す図である。 従来のシステムを介して商品の注文を受け付ける場合の処理の流れを示すシーケンス図である。 従来のシステムにおける注文の受付後に、注文内容が修正される場合の処理の流れを示すシーケンス図である。 本実施形態のシステムの構成例を示す図である。 （ａ）会員情報，（ｂ）加盟店情報，（ｃ）商品情報，（ｄ）注文情報の主要な項目を示す図である。 本実施形態のシステムにおいて請求金額の大幅な変更につながる注文の修正がされて会員に金額変更に対する承認を求める場合の処理の流れを示すシーケンス図である。 本実施形態のシステムにおける仮想商店街管理サーバによる処理の詳細を示すフローチャートである。 注文内容の修正ページの例を示す図である。 （ａ）変更前後の差額が所定金額以上であると判定されたときに加盟店端末に送信される決済処理の依頼ページの例，（ｂ）変更前後の差額が所定金額以上でないと判定されたときに加盟店端末に送信される決済処理の依頼ページの例を示す図である。 金額変更に対する承認依頼メールの例を示す図である。 購入履歴の確認ページの例を示す図である。 金額変更に対する認否の選択ページの例を示す図である。 金額変更に対する承認依頼メール（モバイル端末宛）の例を示す図である。 購入履歴の確認ページ（モバイル端末用）の例を示す図である。 金額変更に対する認否の選択ページ（モバイル端末用）の例を示す図である。

符号の説明

１０ 仮想商店街管理サーバ
１１ 会員情報データベース
１２ 加盟店情報データベース
１３ 商品情報データベース
１４ 注文情報データベース
２０ ネットワーク
２１ 専用線
３０ 会員端末
４０ 加盟店端末
５０ 銀行サーバ
８００ 注文内容の修正ページ
９００ａ 変更前後の差額が所定金額以上であると判定されたときに送信される決済処理の依頼ページ
９００ｂ 変更前後の差額が所定金額以上でないと判定されたときに送信される決済処理の依頼ページ
１０００ 金額変更に対する承認依頼メール
１１００ 購入履歴の確認ページ
１２００ 金額変更に対する認否の選択ページ
１３００ 金額変更に対する承認依頼メール（モバイル端末宛）
１４００ 購入履歴の確認ページ（モバイル端末用）
１５００ 金額変更に対する認否の選択ページ（モバイル端末用）

Claims (6)

1. 仮想商店街の加盟店と会員との間の取引を支援する仮想商店街管理システムにおける注文情報の修正処理であって、
   前記加盟店の端末から前記注文情報に関する修正情報を受信する修正情報受信手段と、
   前記修正情報をもとに請求金額に所定金額を越える変更が生じると判定したとき、該所定金額を越える変更に対する承認を依頼する電子メールを、前記加盟店に注文した前記会員の端末に送信する変更承認依頼メール送信手段と、
   前記変更承認依頼メール送信手段により送信された電子メールを受け取った前記会員の端末から前記所定金額を越える変更に対する承認情報又は否認情報を受信する認否情報受信手段と、
   前記認否情報受信手段が承認情報を受信したときに前記注文情報の修正を確定し、否認情報を受信したときに前記注文情報を取り消す注文確定手段と
   を備えることを特徴とする仮想商店街管理システム。
2. 請求項１に記載の仮想商店街管理システムにおいて、
   前記認否情報受信手段が所定期間内に承認情報及び否認情報の何れも受信しないとき、前記注文確定手段は、前記注文情報を取り消す
   ことを特徴とする仮想商店街管理システム。
3. 請求項１又は２に記載の仮想商店街管理システムにおいて、
   前記認否情報受信手段が所定期間内に承認情報及び否認情報の何れも受信しないとき、前記変更承認依頼メール送信手段は、前記会員の端末に前記所定金額を越える変更に対する承認を依頼する電子メールを再度送信する
   ことを特徴とする仮想商店街管理システム。
4. 請求項１に記載の仮想商店街管理システムにおいて、
   さらに、前記注文確定手段が前記注文情報の修正を確定したとき、前記取引に係る決済処理を所定の決済機関に依頼する決済処理依頼手段を備える
   ことを特徴とする仮想商店街管理システム。
5. 仮想商店街の加盟店と会員との間の取引を支援する仮想商店街管理システムにおける注文情報の修正方法であって、
   前記加盟店の端末から前記注文情報に関する修正情報を受信する修正情報受信ステップと、
   前記修正情報をもとに請求金額に所定金額を越える変更が生じると判定したとき、該所定金額を越える変更に対する承認を依頼する電子メールを、前記加盟店に注文した前記会員の端末に送信する変更承認依頼メール送信ステップと、
   前記変更承認依頼メール送信ステップにより送信された電子メールを受け取った前記会員の端末から前記所定金額を越える変更に対する承認情報又は否認情報を受信する認否情報受信ステップと、
   前記認否情報受信ステップで承認情報を受信したときに前記注文情報の修正を確定し、否認情報を受信したときに前記注文情報を取り消す注文確定ステップと
   を含むことを特徴とする仮想商店街管理システムにおける注文情報の修正方法。
6. 請求項１〜４のいずれかに記載の仮想商店街管理システムの各手段をコンピュータに機能として実現させるためのプログラム。