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

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

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

(1-1.仮想商店街管理サーバ)
 図4において、仮想商店街管理サーバ10は、� ��文の受付から取引の完了までを総合的に管� ��するサーバである。ここでは、本実施形態� ��システムに関して必要な部分を説明する。

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

 図5(a)に、会員情報データベース11の主要な� ��目を示す。
 図5(a)において、「会員ID」は、利用登録を� ��ている会員に一意の識別情報である。「パ� ��ワード」は、その会員の認証に用いるパス� ��ードである。「メールアドレス」は、その� ��員が用いる会員端末30(後述)のメールアドレ スである。「個人情報」は、その会員の個人 情報(例えば、氏名,性別,住所,電話番号等)で� ��る。
 なお、会員の認証(ログイン)には、会員情� �の項目のうち「会員ID」及び「パスワード」 を用いる。

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

 図5(b)に、加盟店情報データベース12の主要� ��項目を示す。
 図5(b)において、「加盟店ID」は、出店登録� ��している店舗に一意の識別情報である。本� ��施形態では、加盟店IDとしてその加盟店の� �メイン名を使用している。「認証キー」は� �その加盟店の認証に用いるキーである。「� �ールアドレス」は、その加盟店が用いる加� �店端末40(後述)のメールアドレスである。「� ��当者ID」は、その加盟店における受注管理� �務の担当者の識別情報であり、少なくとも1� ��登録されている。「店舗情報」は、その加� ��店の店舗の情報(例えば、名称,店舗の詳細� �掲載したウェブページのURL等)である。
 なお、加盟店の認証(ログイン)には、加盟� �情報の項目のうち「加盟店ID」,「担当者ID」 及び「認証キー」を用いる。

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

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

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

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

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

(1-6.会員端末)
 図4に戻り、会員端末30は、本実施形態のシ� ��テムが提供するサービスを利用して商品を� ��入するユーザ(会員)が用いる端末である。� �実施形態においては、例えば、パソコンや� �帯電話等の通信機能を有する端末とする。
 会員端末30はブラウザを有しており、イン� �ーネット等のネットワーク20を介して仮想商 店街管理サーバ10に接続することにより、本� ��施形態のシステムを介して任意の加盟店に� ��品を注文することができる。

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

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

(2.本実施形態のシステムによる処理の流れ)
 本実施形態のシステムにおいて請求金額の� ��幅な変更につながる注文内容の修正がされ� ��会員に金額変更に対する承認を求める場合� ��処理の流れを、図6のシーケンス図を用いて 説明する。
 本実施形態のシステムによる注文内容の修� ��処理は、図3に示した従来のシステムによる 処理と比較して、主として下記の2点におい� �相違する。
 (a)本実施形態のシステムは、注文の受付後� ��加盟店から請求金額の大幅な増額につなが� ��注文内容の修正を受け付けた場合、その注� ��をした会員に承認を求める(S630a~S635a)。
 (b)本実施形態のシステムは、加盟店から決� ��(口座振替)処理の依頼を受け付けた後に会� �に承認を求め、会員から承認が得られると� �盟店に再確認をすることなく決済(口座振替) 処理を開始する(S625a~S645a)。
 なお、図6のシーケンス図は、図2に示す処� �により商品が注文された後の処理を示して� �る。また、決済方法の選択処理(図2のS215)に� ��いて口座振替が選択されているものとする� ��

(2-1.注文の受付)
 図6に示すように、仮想商店街管理サーバ10� ��、選択された商品の情報等をもとに注文の� ��付処理を行なう(S605)。ここでは、注文番号( 図2のS225により付与した番号)ごとに注文情報 (図5(d)参照)を生成し、注文情報データベース 14に記憶する。
 注文の受付処理が完了すると、仮想商店街� ��理サーバ10は、会員端末30及び加盟店端末40� ��注文を受け付けた旨の確認メールを送信し� ��会員及び加盟店に注文を受け付けた旨を通� ��する(S6101,S6102)。

(2-2.修正の受付)
 上記通知があると、加盟店(担当者)は、加� �店端末40を用いて仮想商店街管理サーバ10に� ��グインし、注文内容の確認ページを要求す� ��。加盟店端末40から確認ページの要求があ� �と、仮想商店街管理サーバ10は注文内容の確 認ページを加盟店端末40に送信し、加盟店に� ��文内容の確認を求める。加盟店(担当者)は� �この確認ページで注文内容を確認し、必要� �あればこの確認ページから修正ページを要� �する。
 加盟店端末40から修正ページの要求がある� �、仮想商店街管理サーバ10は注文内容の修正 ページを加盟店端末40に送信し、加盟店端末4 0から注文内容の修正情報を受け付ける(S615)� �加盟店(担当者)は、この修正ページに必要な 修正を入力する。
 なお、注文内容の修正の受付の前には、従� ��例(図3のS325)と同様に、加盟店(担当者)と会� ��との間で、電話,メール等により直接交渉が されている場合もある。これは、上述のよう に、請求金額の大幅な変更につながる注文内 容の修正として様々な契機(加盟店側の事情,� ��員側の事情)が考えられるからである。

(2-3.決済処理の依頼の受付)
 注文内容の修正情報を受け付けると、仮想� ��店街管理サーバ10は、加盟店端末40に決済処 理の依頼ページを送信し、加盟店(担当者)に� ��正後の金額による決済処理(本実施形態では 、口座振替処理)の依頼を求める(S625a)。加盟� ��(担当者)は、受信した決済処理の依頼ペー� �から修正後の金額による決済(口座振替)処理 を依頼する。
 なお、本実施形態のシステムは、加盟店か� ��決済処理の依頼があったときに、会員に承� ��を得るための処理を行なう。そのため、請� ��金額の大幅な変更につながる注文内容の修� ��があった場合には、加盟店に修正後の金額� ��よる決済処理の依頼を例外なく求めること� ��している。

(2-4.承認の依頼)
 加盟店端末40から修正後の金額による決済� �理の依頼を受け付けると、仮想商店街管理� �ーバ10は、会員端末30に請求金額の大幅な変� ��につながる注文内容の修正を受け付けた旨� ��電子メールを送信し、会員に金額の変更に� ��する承認を依頼する(S630a)。
 上記依頼を受けた会員は、会員端末30を用� �て仮想商店街管理サーバ10にログインし、購 入履歴の確認ページを要求する。会員端末30� ��ら確認ページの要求があると、仮想商店街� ��理サーバ10は購入履歴の確認ページを会員� �末30に送信し、会員に金額の変更に対する認 否の応答を求める(S635a)。会員は、この購入� �歴の確認ページで修正内容を確認し、金額� �変更に対する認否を応答する。

(2-5.注文内容の変更・決済処理の開始)
 会員端末30から金額の変更に対する承認の� �答があると、仮想商店街管理サーバ10は、会 員から確認がとれたため、注文内容の変更を 確定させた上で、銀行サーバ50に対して所定� ��口座振替処理を依頼する(S645a)。ここでは、 会員が口座を有する銀行のサーバ50に対して� ��所定の口座振替処理を依頼する。
 このように、本実施形態のシステムは、会� ��から金額の変更に対する承認が得られると� ��加盟店(担当者)に再確認を求めることなく� �決済(口座振替)処理を開始することとしてい る。そのため、加盟店(担当者)は、本実施形� ��のシステムを利用することにより、注文内� ��の修正について会員から承認が得られたか� ��かを確認する手間を省くことができる。
 注文内容の変更処理が完了すると、仮想商� ��街管理サーバ10は、会員端末30及び加盟店端 末40に注文を変更した旨の電子メールを送信� ��、会員及び加盟店に注文を変更した旨を通� ��する(S650a1,S650a2)。

(3.本実施形態のシステムによる処理の詳細)
 本実施形態のシステムにおける仮想商店街� ��理サーバによる処理の詳細を、図7のフロー チャート及び図8~図12のページ・メールの例� �用いて説明する。
 本実施形態においては、請求金額の大幅な� ��更に当たるか否かの基準となる閾値(所定金 額)を「1,000円」としている。なお、この閾値 は適宜変更することができる。
 以降、仮想商店街管理サーバによる処理の� ��れを、図7のフローチャートを用いて説明す る。なお、図7には、参照すべき他の図面の� �号を示している。また、図6と図7で符号が一 致している処理は、それぞれ同一の処理であ るものとする。

(3-1.注文の受付)
 図7に示すように、仮想商店街管理サーバ10� ��、選択された商品の情報等をもとに、注文� ��受付処理を行なう(S605)。ここでは、注文番� ��(図2のS225により付与した番号)をキーとして 注文情報(図5(d)参照)を生成し、注文情報デー タベース14に記憶する。また、注文情報の「� ��注処理ステータス」を初期値の「新規受付� ��とし、「決済処理ステータス」を初期値の� ��未処理」とする。
 注文の受付処理が完了すると、仮想商店街� ��理サーバ10は、会員端末30及び加盟店端末40� ��注文を受け付けた旨の電子メールを送信し� ��会員及び加盟店に注文を受け付けた旨を通� ��する(S610)。なお、会員端末30及び加盟店端� �40に対する電子メールはほぼ同時に送信され る。

(3-2.修正の受付)
 上記通知があると、加盟店(担当者)は、加� �店端末40を用いて仮想商店街管理サーバ10に� ��グインし、注文内容の確認ページを要求す� ��。加盟店端末40から確認ページの要求があ� �と、仮想商店街管理サーバ10は注文内容の確 認ページを加盟店端末40に送信し、加盟店に� ��文内容の確認を求める。加盟店(担当者)は� �受信した確認ページにおいて注文内容を確� �し、必要であれば注文内容の修正ページを� �求する。
 加盟店端末40から修正ページの要求がある� �、仮想商店街管理サーバ10は注文内容の修正 ページを加盟店端末40に送信し、加盟店端末4 0から注文内容の修正情報を受け付ける(S615)� �加盟店(担当者)は、この修正ページに必要な 修正を入力する。

 図8に注文内容の修正ページを例示する。修 正ページ800は、注文番号「123456-20070601-123456� �の注文内容を個別に確認・修正するための� �ージである。
 修正ページ800は、注文内容の確認修正欄810� ��びボタン820により構成される。
 注文内容の確認修正欄810には、注文番号に� ��応する注文情報が表示される。ここでは、� ��文情報に紐付けられた会員情報及び商品情� ��、並びに「数量」,「請求金額」等が表示さ れている。
 注文内容を変更する場合には、変更する項� ��の表示欄に変更後の内容を入力し、「この� ��容で保存する」と表示されているボタン820� ��クリックする。

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

(3-3.決済依頼の受付)
 変更前後の差額が所定金額(1000円)以上であ� ��と判定したとき(S620でYes)、仮想商店街管理� ��ーバ10は、決済処理の依頼ページを生成し� �加盟店端末40に送信し、加盟店に決済処理の 依頼を求める(S625a)。このとき送信される決� �処理の依頼ページには、決済処理の前に会� �に金額変更に対する承認の依頼が通知され� �旨を表示する。
 一方、変更前後の差額が所定金額(1000円)以� ��でないと判定したとき(S620でNo)、仮想商店� �管理サーバ10は、注文情報の「金額承認フラ グ」を立てた上で、決済処理の依頼ページを 生成して加盟店端末40に送信し、加盟店に決� ��処理の依頼を求める(S625b)。このとき送信さ れる決済処理の依頼ページには、決済処理の 前に会員に金額変更に対する承認の依頼が通 知される旨を表示しない。

 図9(a)に、変更前後の差額が所定金額(1000円) 以上であると判定されたときに加盟店端末40� ��送信される決済処理の依頼ページを例示す� ��。
 決済処理の依頼ページ900aは、注文情報表示 欄910a及び決済処理を依頼するためのボタン92 0aにより構成されている。
 注文情報表示欄910aには、決済処理の対象と なっている注文情報の「注文番号」及び「決 済処理ステータス」が表示される。また、「 ユーザへ金額確認あり」と表示されている欄 911aにアイコンを表示することにより、決済� �理の前に会員に金額変更に対する承認の依� �が通知される旨を表示する。
 決済処理の依頼ページ900aにおいて、「口座 振替を依頼する」と表示されているボタン920 aがクリックされると、仮想商店街管理サー� �10は、後述のように会員端末30に金額変更に� ��する承認の依頼メールを送信する(後述のS63 0a)。

 図9(b)に、変更前後の差額が所定金額(1000円) 以上でないと判定されたときに加盟店端末40� ��送信される決済処理の依頼ページを例示す� ��。決済処理の依頼ページ900bは、決済処理の 依頼ページ900aと同様のものである。ただし� �上述の「ユーザへ金額確認あり」と表示さ� �ている欄911aに対応する欄911bには、アイコン が表示されない。
 決済処理の依頼ページ900bにおいて、「口座 振替を依頼する」と表示されているボタン920 bがクリックされると、仮想商店街管理サー� �10は、会員から金額変更に対する承認を得る 必要がないので、直ちに決済処理を開始する (後述のS645a)。

(3-4.承認の依頼)
 図7に戻り、変更前後の差額が所定金額(1000� ��)以上であると判定された場合(S620でYes)、加 盟店端末40から決済処理の依頼情報を受け付� ��ると、仮想商店街管理サーバ10は、会員端� �30に金額の大幅な変更につながる注文内容の 修正を受け付けた旨の電子メールを送信し、 会員に金額の変更に対する承認を依頼する(S6 30a)。このとき、注文情報の「決済処理ステ� �タス」を「未承認」とする。
 なお、本実施形態においては、この処理を� ��期的なバッチ処理(例えば、5分ごとのバッ� �処理)で行なっているが、他のタイミングで� ��なってもよい。

 図10に金額変更に対する承認依頼メールを� �示する。承認依頼メール1000は、加盟店(担当 者)が、修正ページ800(図8)において数量表示� �811に「2」を入力してボタン820をクリックし� ��後、送信されてきた決済依頼の依頼ページ9 00a(図9(a))において「口座振替を依頼する」と 表示されているボタン920aをクリックするこ� �により決済処理の依頼を行なったときに、� �員端末30に送信されるメールである。
 承認依頼メール1000において、宛先欄1010に� �会員端末30のメールアドレスが表示される。 メールアドレスは、注文情報に紐付けられた 会員情報から取得する。件名欄1020には、金� �変更に対する承認依頼である旨を判別しや� �い件名が表示される。

 本文欄1030には、承認の対象となる注文の識 別情報(1031),承認の依頼文(1032),承認の手順(103 3),問合せ先等の注意事項(1034)等が表示される 。また、本実施形態においては、金額変更に 対する承認に期限(ここでは、修正の受付か� �3日以内)を設けており、期限内に承認がされ ないと注文が取消(キャンセル)となる旨の注� ��を表示する(1035)。
 なお、注文の識別情報(1031)の[注文詳細]、� �は承認の手順(1033)の[1]に表示されているURL� �、依頼の対象となっている注文に係る確認� �ージへのリンクとなっている。そのため、� �員は、会員端末30上でこのリンクをクリック するだけで、依頼の対象となる注文に係る確 認ページを受信することができる。

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

 図11に、購入履歴の確認ページを例示する� �確認ページ1100は、承認依頼メール1000(図10)� �注文の識別情報(1031)の[注文詳細]、又は承認 の手順(1033)の[1]に表示されているURLがクリッ クされたときに、会員端末30に送信されるペ� ��ジである。
 確認ページ1100は、金額等表示欄1110,注文情� ��表示欄1120及び金額変更に対する認否の選択 ページを要求するためのボタン1130により構� �される。
 金額等表示欄1110には、商品情報、及び注文 情報の「数量」,「請求金額」等が表示され� �。注文情報表示欄1120には、注文情報の「注� ��番号」,「注文日時」,「決済方法」のほか� �注文者の情報が表示される。
 会員が「決済金額の確認」と表示されてい� ��ボタン1130をクリックすると、会員端末30か� ��仮想商店街管理サーバ10に金額変更に対す� �認否の選択ページを要求する。

 図12に、金額変更に対する認否の選択ペー� �を例示する。選択ページ1200は、確認ページ1 100(図11)においてボタン1130がクリックされた� ��きに、会員端末30に送信されるページであ� �。
 選択ページ1200は、金額等表示欄1210並びに� �額承認ボタン1220a及び注文キャンセルボタン 1220bにより構成される。
 金額等表示欄1210には、注文時の金額,変更� �の金額及び差額が表示される。本実施形態� �は、この差額が所定金額(1,000円)以上である� ��きに会員の承認を要することとしている。
 会員が「金額承認」と表示されているボタ� ��1220aをクリックすると、会員端末30から仮想 商店街管理サーバ10に金額変更に対する承認� ��応答が送信される。一方、会員が「キャン� ��ル」と表示されているボタン1220bをクリッ� �すると、会員端末30から仮想商店街管理サー バ10に金額変更に対する否認の応答が送信さ� ��る。
 なお、本実施形態では、金額の否認を注文� ��取消(キャンセル)として扱うため、金額の� �更のみを否認するという選択肢は用意して� �ない。

(3-5.口座振替処理の依頼・注文の取消)
 図7に戻り、会員端末30から応答を受信する� ��、仮想商店街管理サーバ10は、承認がされ� �か否かを判定する(S640a)。
 会員端末30からの応答が承認であると判定� �たとき(S640aでYes)、仮想商店街管理サーバ10� �、注文内容の修正が妥当であると判断し、� �文内容の変更を確定させた上で、銀行サー� �50に口座振替処理を依頼する(S645a)。
 ここでは、注文の受付処理(S605)により生成� ��た注文情報を修正された内容に更新すると� ��もに、「受注処理ステータス」を「発送待� ��」と、「決済処理ステータス」を「残高確� ��待ち」とする。また、「金額変更承認フラ� ��」を立てる。
 注文内容の変更が確定すると、仮想商店街� ��理サーバ10は、会員端末30及び加盟店端末40� ��注文を変更した旨の電子メールを送信し、� ��員及び加盟店に注文を変更した旨を通知す� ��(S650a)。なお、会員及び加盟店に対する通知 は、例えば日次バッチ処理により翌日に一括 して送信される。

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

<他の実施形態1>
 上述の実施形態においては、加盟店から決� ��処理の依頼があったときに、会員に承認を� ��るための処理を行なうこととしている。こ� ��は、決済機関を介して決済が行なわれる場� ��、注文内容(請求金額)が変更された後に会� �には代金の支払を保留又は拒否するための� �択機会がないので、修正後の金額で安全に� �済を行なうためには会員から事前に承認を� �ておく処理が有効だからである。
 これに対し、加盟店端末40から注文内容の� �正情報を受け付けたときに、会員に承認を� �るための処理を行なうこととしてもよい。
 この場合、例えば図7に示す処理においては 、加盟店端末40から注文内容の修正情報を受� ��付け(S615)、修正前後の請求金額の変更額が� ��定金額以上か否かを判定する(S620)と、決済� ��理の依頼を受け付ける処理(S625a)を行なわず に、会員端末30に金額変更の承認を依頼する� ��子メールを送信する(S630a)。これにより、加 盟店から注文内容の修正情報を受け付けたと きに、会員に承認を得るための処理を行なう ことができる。

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

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

 図14に、モバイル端末用の購入履歴の確認� �ージを例示する。確認ページ1400は、確認ペ� ��ジ1100(図11)に対応している。なお、確認ペ� �ジ1400は、承認依頼メール1300(図13参照)の承� �の依頼文(1331)の下に表示されているURLがク� �ックされたときに会員端末30に送信されるロ グインページでの会員認証を経て、依頼の対 象となっている注文に係る購入履歴の確認ペ ージを要求したときに、会員端末30に送信さ� ��るページである。
 確認ページ1400は、金額等表示欄1410,注文情� ��表示欄1420及び金額変更に対する認否の選択 ページを要求するためのボタン1430により構� �される。
 金額等表示欄1410には、商品情報、及び注文 情報の「請求金額」等が表示される。注文情 報表示欄1420には、注文情報の「注文番号」,� ��注文日時」,「決済方法」のほか、注文者の 情報が表示される。
 会員が「決済金額の確認」と表示されてい� ��ボタン1430をクリックすると、会員端末30か� ��仮想商店街管理サーバ10に金額変更に対す� �認否の選択ページを要求する。

 図15に、金額変更に対する認否の選択ペー� �を例示する。選択ページ1500は、選択ページ1 200(図12)に対応している。なお、選択ページ15 00は、確認ページ1400(図14)においてボタン1430� ��クリックされたときに、会員端末30に送信� �れるページである。
 選択ページ1500は、金額等表示欄1510並びに� �額承認ボタン1520a及び注文キャンセルボタン 1520bにより構成される。
 金額等表示欄1510には、注文時の金額,変更� �の金額及び差額が表示される。本実施形態� �は、この差額が所定金額(1,000円)以上である� ��きに会員の承認を要することとしている。
 会員が「金額承認」と表示されているボタ� ��1520aをクリックすると、会員端末30から仮想 商店街管理サーバ10に金額変更に対する承認� ��応答が送信される。一方、会員が「キャン� ��ル」と表示されているボタン1520bをクリッ� �すると、会員端末30から仮想商店街管理サー バ10に金額変更に対する否認の応答が送信さ� ��る。
 なお、本実施形態では、金額の否認を注文� ��取消(キャンセル)として扱うため、金額の� �更のみを否認するという選択肢は用意して� �ない。

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