(57)【特許請求の範囲】
【請求項１】
複数のユーザの端末と、売買取引を管理する電子商取引管理サーバとが電気通信回線網を介して接続可能な電子商取引システムにおける電子商取引管理サーバであって、
前記電子商取引管理サーバは、さらに、クレジットカードの与信情報を管理する与信情報管理サーバと接続可能であり、
注文する商品を決定したユーザの端末から、注文形態の情報、決済情報を含む注文者の情報、商品の受取人の情報、及び、賛同者候補のメールアドレスを取得する注文情報取得手段と、
前記注文形態の情報、前記注文者の情報、前記受取人の情報、及び、前記注文者の決済情報として該注文者のクレジットカード情報を取得したとき、前記注文する商品の代金総額に相当する与信枠の確保を前記取得した注文者のクレジットカード情報に係るクレジットカード会社の与信情報管理サーバに要求する注文者与信枠確保手段と、
前記注文者の与信枠が確保されたとき、前記取得した賛同者候補のメールアドレス宛に、賛同者候補の情報を入力するページへのアクセス情報を記載した賛同募集メールを送信する賛同募集メール送信手段と、
前記賛同者候補のユーザ端末からの要求に応じて前記賛同者候補の情報を入力するページを送信し、該ページに入力された決済情報を含む賛同者候補の情報を受信する賛同者候補情報取得手段と、
前記賛同者候補の決済情報としてクレジットカード情報を取得したとき、前記注文する商品の代金総額を前記商品の代金を支払う人数で除して得られた負担額に相当する与信枠の確保を、前記取得した賛同者候補のクレジットカード情報に係るクレジットカード会社の与信情報管理サーバに要求する賛同者候補与信枠確保手段と、
前記賛同者候補の与信枠が確保されたとき、該賛同者候補を賛同者として確定する賛同者確定手段と、
を備え、
前記注文者与信枠確保手段は、賛同者が新たに確定されるごとに、前記注文者の既に確保されている与信枠を前記負担額に減額することを前記与信情報管理サーバに要求し、
前記賛同者候補与信枠確保手段は、賛同者が新たに確定されるごとに、前記確定した賛同者の既に確保されている与信枠を前記負担額に減額することを前記与信情報管理サーバに要求する、
電子商取引管理サーバ。
【請求項２】
請求項１に記載の電子商取引管理サーバにおいて、
前記受取人の情報には、メールアドレスが含まれており、
前記注文者により指定されたすべての賛同者候補が前記賛同者候補の情報を入力するページに情報を入力したとき、前記受取人のメールアドレス宛に前記注文された商品の受取の案内メールを送信する受取案内メール送信手段と、
前記受取人の端末から、前記注文された商品の受取拒否を含む応答を取得する応答取得手段とをさらに備え、
前記応答取得手段が前記受取人の端末から前記受取拒否の応答を取得したとき、前記注文者与信枠確保手段及び前記賛同者候補与信枠確保手段は、前記注文者又は確定済の賛同者の既に確保されている与信枠を返還することを前記与信情報管理サーバに要求する電子商取引管理サーバ。
【請求項３】
請求項２に記載の電子商取引管理サーバにおいて、前記注文情報取得手段は、注文する商品を決定したユーザの端末から、前記注文者が指定した募集人数を取得し、
前記受取案内メール送信手段は、確定済の賛同者の人数が前記募集人数に達したとき、前記受取人のメールアドレス宛に前記注文された商品の受取の案内メールを送信する電子商取引管理サーバ。
【請求項４】
請求項２又は３に記載の電子商取引管理サーバにおいて、
前記注文情報取得手段は、注文する商品を決定したユーザの端末から、前記注文者が指定した募集期限を取得し、
前記受取案内メール送信手段は、前記募集期限が経過したとき、前記受取人のメールアドレス宛に前記注文された商品の受取の案内メールを送信する電子商取引管理サーバ。
【請求項５】
複数のユーザの端末と、売買取引を管理する電子商取引管理サーバとが電気通信回線網を介して接続可能な電子商取引システムにおける電子商取引管理サーバによる決済方法であって、
前記電子商取引管理サーバは、さらに、クレジットカードの与信情報を管理する与信情報管理サーバと接続可能であり、
注文する商品を決定したユーザの端末から、注文形態の情報、決済情報を含む注文者の情報、商品の受取人の情報、及び、賛同者候補のメールアドレスを取得する注文情報取得ステップと、
前記注文形態の情報、前記注文者の情報、前記受取人の情報、及び前記注文者の決済情報として該注文者のクレジットカード情報を取得したとき、前記注文する商品の代金総額に相当する与信枠の確保を前記取得した注文者のクレジットカード情報に係るクレジットカード会社の与信情報管理サーバに要求する注文者与信枠確保ステップと、
前記注文者の与信枠が確保されたとき、前記取得した賛同者候補のメールアドレス宛に、賛同者候補の情報を入力するページへのアクセス情報を記載した賛同募集メールを送信する賛同募集メール送信ステップと、
前記賛同者候補のユーザ端末からの要求に応じて前記賛同者候補の情報を入力するページを送信し、該ページに入力された決済情報を含む賛同者候補の情報を受信する賛同者候補情報取得ステップと、
前記賛同者候補の決済情報としてクレジットカード情報を取得したとき、前記注文する商品の代金総額を前記商品の代金を支払う人数で除して得られた負担額に相当する与信枠の確保を、前記取得した賛同者候補のクレジットカード情報に係るクレジットカード会社の与信情報管理サーバに要求する賛同者候補与信枠確保ステップと、
前記賛同者候補の与信枠が確保されたとき、該賛同者候補を賛同者として確定する賛同者確定ステップと、
を備え、
前記注文者与信枠確保ステップでは、賛同者が新たに確定されるごとに、前記注文者の既に確保されている与信枠を前記負担額に減額することを前記与信情報管理サーバに要求し、
前記賛同者候補与信枠確保ステップでは、賛同者が新たに確定されるごとに、前記確定した賛同者の既に確保されている与信枠を前記負担額に減額することを前記与信情報管理サーバに要求する、
電子商取引管理サーバによる決済方法。
【請求項６】
請求項１〜４のいずれか一項に記載の電子商取引管理サーバが備える各手段を、コンピュータに機能として実現させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電子商取引システムに関し、特に、複数のユーザが共同で他の特定のユーザに商品を贈る場合における決済処理に関するものである。
【背景技術】
【０００２】
＜従来例１の概略＞
電気通信回線網を通じた商品等の売買取引を支援する仮想商店街管理サービスが知られている（例えば、非特許文献１）。また、電気通信回線網を通じて商品等を直接販売するオンラインストアサービスが知られている（例えば、非特許文献２）。
これらのサービスは、ギフトの注文にも対応している。仮想商店街又はオンラインストアでギフトを注文する場合、ユーザは、仮想商店街管理サービス又はオンラインストアサービスを管理・運営するサーバと電気通信回線網を介して接続している端末を用いて、例えば、次の操作を行う。
【０００３】
（１）商品を選択する。
（２）選択した商品をギフトとすることを選択する。
（２）ログインする（又は注文者の情報を入力する）。
（３）送付先の情報を入力する。
（４）決済方法（例えば、クレジットカード等）を指定する。
【０００４】
＜従来例２の概略＞
「ギャザリング」と呼ばれる販売形態での電子商取引サービスにおいて、共同購入商品をクレジットカードで決済するためのシステムが知られている（例えば、特許文献１参照）。
上記サービスは、「申込数（販売数）が増えるにつれて実販売価格がどんどん安くなっていく」というものである。このサービスに対応するため、上記システムでは、購入申込があると当該時点の申込総数に応じた価格で購入金額を計算し、購入者の与信承認を得、共同購入成立時には、申込総数に応じた価格で確定金額を算出し、売上処理依頼通知を送信する、という手順で決済が行われている。
【０００５】
【特許文献１】特開２００２−３１８９２７号公報
【非特許文献１】楽天株式会社、“楽天市場”、[online]、インターネット<URL:http://www.rakuten.co.jp/>
【非特許文献２】Amazon.com Int'l Sales, Inc.、“Amazon.co.jp”、[online]、インターネット<URL:http://www.amazon.co.jp/>
【発明の開示】
【発明が解決しようとする課題】
【０００６】
本発明は、電子商取引システムを利用して複数の者が共同で他の特定の者に商品等を贈るしくみを提供するとともに、集金の手間を軽減することを目的とする。
【課題を解決するための手段】
【０００７】
上記目的を達成するため、本発明は、複数のユーザの端末と、売買取引を管理する電子商取引管理サーバとが電気通信回線網を介して接続可能な電子商取引システムにおける電子商取引管理サーバであって、前記電子商取引管理サーバは、さらに、クレジットカードの与信情報を管理する与信情報管理サーバと接続可能であり、注文する商品を決定したユーザの端末から、注文形態の情報、決済情報を含む注文者の情報、商品の受取人の情報、及び、賛同者候補のメールアドレスを取得する注文情報取得手段と、前記注文形態の情報、前記注文者の情報、前記受取人の情報、及び、前記注文者の決済情報として該注文者のクレジットカード情報を取得したとき、前記注文する商品の代金総額に相当する与信枠の確保を前記取得した注文者のクレジットカード情報に係るクレジットカード会社の与信情報管理サーバに要求する注文者与信枠確保手段と、前記注文者の与信枠が確保されたとき、前記取得した賛同者候補のメールアドレス宛に、賛同者候補の情報を入力するページへのアクセス情報を記載した賛同募集メールを送信する賛同募集メール送信手段と、前記賛同者候補のユーザ端末からの要求に応じて前記賛同者候補の情報を入力するページを送信し、該ページに入力された決済情報を含む賛同者候補の情報を受信する賛同者候補情報取得手段と、前記賛同者候補の決済情報としてクレジットカード情報を取得したとき、前記注文する商品の代金総額を前記商品の代金を支払う人数で除して得られた負担額に相当する与信枠の確保を、前記取得した賛同者候補のクレジットカード情報に係るクレジットカード会社の与信情報管理サーバに要求する賛同者候補与信枠確保手段と、前記賛同者候補の与信枠が確保されたとき、該賛同者候補を賛同者として確定する賛同者確定手段とを備え、前記注文者与信枠確保手段は、賛同者が新たに確定されるごとに、前記注文者の既に確保されている与信枠を前記負担額に減額することを前記与信情報管理サーバに要求し、前記賛同者候補与信枠確保手段は、賛同者が新たに確定されるごとに、前記確定した賛同者の既に確保されている与信枠を前記負担額に減額することを前記与信情報管理サーバに要求する。
【０００８】
前記受取人の情報には、メールアドレスが含まれており、前記注文者により指定されたすべての賛同者候補が前記賛同者候補の情報を入力するページに情報を入力したとき、前記受取人のメールアドレス宛に前記注文された商品の受取の案内メールを送信する受取案内メール送信手段と、前記受取人の端末から、前記注文された商品の受取拒否を含む応答を取得する応答取得手段とをさらに備え、前記応答取得手段が前記受取人の端末から前記受取拒否の応答を取得したとき、前記注文者与信枠確保手段及び前記賛同者候補与信枠確保手段は、前記注文者又は確定済の賛同者の既に確保されている与信枠を返還してもよい。
【０００９】
前記注文情報取得手段は、注文する商品を決定したユーザの端末から、前記注文者が指定した募集人数を取得し、前記受取案内メール送信手段は、確定済の賛同者の人数が前記募集人数に達したとき、前記受取人のメールアドレス宛に前記注文された商品の受取の案内メールを送信してもよい。
前記注文情報取得手段は、注文する商品を決定したユーザの端末から、前記注文者が指定した募集期限を取得し、前記受取案内メール送信手段は、前記募集期限が経過したとき、前記受取人のメールアドレス宛に前記注文された商品の受取の案内メールを送信してもよい。
【００１２】
また、上記目的を達成するため、本発明は、複数のユーザの端末と、売買取引を管理する電子商取引管理サーバとが電気通信回線網を介して接続可能な電子商取引システムにおける電子商取引管理サーバによる決済方法であって、前記電子商取引管理サーバは、さらに、クレジットカードの与信情報を管理する与信情報管理サーバと接続可能であり、注文する商品を決定したユーザの端末から、注文形態の情報、決済情報を含む注文者の情報、商品の受取人の情報、及び、賛同者候補のメールアドレスを取得する注文情報取得ステップと、前記注文形態の情報、前記注文者の情報、前記受取人の情報、及び前記注文者の決済情報として該注文者のクレジットカード情報を取得したとき、前記注文する商品の代金総額に相当する与信枠の確保を前記取得した注文者のクレジットカード情報に係るクレジットカード会社の与信情報管理サーバに要求する注文者与信枠確保ステップと、前記注文者の与信枠が確保されたとき、前記取得した賛同者候補のメールアドレス宛に、賛同者候補の情報を入力するページへのアクセス情報を記載した賛同募集メールを送信する賛同募集メール送信ステップと、前記賛同者候補のユーザ端末からの要求に応じて前記賛同者候補の情報を入力するページを送信し、該ページに入力された決済情報を含む賛同者候補の情報を受信する賛同者候補情報取得ステップと、前記賛同者候補の決済情報としてクレジットカード情報を取得したとき、前記注文する商品の代金総額を前記商品の代金を支払う人数で除して得られた負担額に相当する与信枠の確保を、前記取得した賛同者候補のクレジットカード情報に係るクレジットカード会社の与信情報管理サーバに要求する賛同者候補与信枠確保ステップと、前記賛同者候補の与信枠が確保されたとき、該賛同者候補を賛同者として確定する賛同者確定ステップとを備え、前記注文者与信枠確保ステップでは、賛同者が新たに確定されるごとに、前記注文者の既に確保されている与信枠を前記負担額に減額することを前記与信情報管理サーバに要求し、前記賛同者候補与信枠確保ステップでは、賛同者が新たに確定されるごとに、前記確定した賛同者の既に確保されている与信枠を前記負担額に減額することを前記与信情報管理サーバに要求する。
【００１３】
上記いずれかに記載の電子商取引管理サーバが備える各手段を、コンピュータに機能として実現させるためのプログラムも本発明である。
【発明の効果】
【００１４】
本発明の電子商取引システムを利用すれば、複数の者が共同で他の特定の者に商品等を贈ることができる。
また、本発明の電子商取引システムを利用すれば、集金の手間を省くことができる。
【発明を実施するための最良の形態】
【００１５】
以降、本発明の一実施形態である、仮想商店街管理システムを利用して複数の者が共同で他の特定の者に商品を贈る場合における決済処理を説明する。
なお、加盟店が所有する商品だけでなく、サービスを管理・運営するサーバが所有する商品を共同ギフトの対象商品としてもよい。
【００１６】
＜用語の定義＞
以下の説明中で使用される用語の意義は、それぞれ次の定義の通りとする。
・幹事…商品を贈る側のユーザ。注文者。
・受取人…商品を受ける側のユーザ。
・賛同者候補…商品を贈る側のユーザ。賛同者の候補として指定されたユーザ。
・賛同者…商品を贈る側のユーザ。賛同承認の手続を完了させ、与信枠が確保された賛同者候補。
・共同ギフト…幹事及び賛同者が共同して、受取人に商品を贈ること。
・賛同手続…賛同者候補が、賛同を承認するか否かを確定させる手続。
・受取手続…受取人が、受取を承認するか否かを確定させる手続。
【００１７】
・与信業者…商取引で、取引相手に信用を供与する業務を行う者。例えば、クレジットカード会社。
・カード会員…クレジットカードの利用登録をしているユーザ。
・与信枠…特定の取引に優先的に利用させるため、他の取引への利用が一時的に制限されている与信限度枠内の一定額相当分。
・課金処理…確定した注文内容に基づき、金銭の支払を請求すること。
・決済処理…クレジットカードを利用する場合には、与信枠の確保及び課金処理の双方を含む。
【００１８】
＜実施形態の説明＞
以降、本実施形態について、次の順序で説明する。
（１．実施形態のシステムの概略）
（１−１．実施形態のシステムの構成）
（１−２．実施形態のシステムの概要）
（１−３．実施形態のシステムが提供する共同ギフト支援サービスの概要）
（１−４．実施形態のシステムによる処理の概要）
（１−５．実施形態のシステムによる処理の特徴）
【００１９】
（２．実施形態のシステムの詳細）
（２−１．仮想商店街管理サーバ）
（２−２（ａ）．会員情報データベース）
（２−２（ｂ）．加盟店情報データベース）
（２−２（ｃ）．商品情報データベース）
（２−２（ｄ）．注文情報データベース）
（２−３．ユーザ端末）
（２−４．店舗端末）
（２−５．与信情報管理サーバ）
【００２０】
（３．各手続の手順）
（３−１．注文手続の手順）
（３−２．賛同承認手続の手順）
（３−３．受取承認手続の手順）
（４．サーバによる決済処理）
（４−１．注文手続段階における決済処理）
（４−２．賛同手続段階における決済処理）
（４−３．受取手続段階における決済処理）
【００２１】
（１．実施形態のシステムの概略）
本実施形態のシステムの概略を、図１を用いて簡単に説明する。
なお、本実施形態において、賛同者（候補）はｎ人（ｎは自然数）とし、共同で贈る商品の代金の支払は、幹事及びすべての賛同者による割前勘定（いわゆる割勘）とする。また、本実施形態において、幹事及び賛同者は、代金の決済方法として同一の与信業者（クレジットカード会社）が発行するクレジットカードの利用を指定するものとする。
【００２２】
（１−１．実施形態のシステムの構成）
図１に示すように、本実施形態のシステムは、仮想商店街管理サービスを提供する仮想商店街管理サーバ１０，幹事（注文者）のユーザ端末３０Ａ，賛同者（１〜ｎ）のユーザ端末３０Ｂ（１〜ｎ），受取人のユーザ端末３０Ｃ，注文対象の商品を提供する加盟店の店舗端末４０及び与信情報を管理するクレジットカード会社の与信情報管理サーバ５０により構成される。
これらはＬＡＮ，ＷＡＮ，インターネット等の電気通信回線網２０を介して互いに接続している。また、仮想商店街管理サーバ１０と与信情報管理サーバ５０とは、例えば、専用線２１を介して接続している。
【００２３】
仮想商店街管理サーバ１０は、仮想商店街管理サービスの利用登録をしているユーザ（会員）の情報を記憶している会員情報データベース１１，仮想商店街管理サービスに出店登録をしている店舗（加盟店）の情報を記憶している加盟店情報データベース１２，仮想商店街管理サービスにおける注文対象の商品の情報を記憶している商品情報データベース１３及び仮想商店街管理サービスにおいて受け付けた注文の情報を記憶している注文情報データベース１４を備えている。
与信情報管理サーバ５０は、カード会員の与信情報を記憶している与信情報データベース（図示せず）及び与信取引の情報を記憶している取引情報データベース（図示せず）等を備えている。
【００２４】
（１−２．実施形態のシステムの概要）
本実施形態のシステムは、電気通信回線網を通じた商品等の売買取引を支援するサービス（仮想商店街管理サービス）を提供するシステムである。
本実施形態のシステムは、仮想商店街管理サービスの一形態として共同ギフト支援サービスを提供するため、従来例１の仮想商店街管理サーバに必要な機能を追加したものである。
【００２５】
（１−３．実施形態のシステムが提供する共同ギフト支援サービスの概要）
共同ギフト支援サービスは、仮想商店街管理サービスの新たな利用形態であり、幹事と賛同者が共同で受取人に商品を贈る手続を支援するサービスである。共同ギフト支援サービスの提供主体は仮想商店街管理サーバ１０であり、利用主体はユーザ端末３０Ａ，ユーザ端末３０Ｂ（１〜ｎ），ユーザ端末３０Ｃをそれぞれ使用する、幹事，賛同者（１〜ｎ），受取人である。
なお、本実施形態では、共同ギフト支援サービスを利用して商品を贈る場合、商品を贈る側のユーザ（幹事及び賛同者）は会員でなければならないものとする。ただし、会員でないユーザに提供することができるように設計を変更してもよい。また、共同ギフト支援サービスは、仮想商店街管理サービスと同様に、電気通信回線網２０を通じて提供されることを前提とするサービスである。
さらに、本実施形態では加盟店が所有する商品を共同ギフト商品としているが、仮想商店街管理サーバ１０が所有する商品を共同ギフト商品とする対象にしてもよい。
【００２６】
（１−４．実施形態のシステムによる処理の概要）
本実施形態のシステムによる決済処理の概要は、次のとおりである。
（ａ）ユーザ端末３０Ａからの注文手続や購入予約手続が完了すると、仮想商店街管理サーバ１０は、専用線２１を通じて与信情報管理サーバ５０に対し与信枠の確保を要求し、幹事の与信限度枠内において代金の総額に相当する与信枠を確保する。
（ｂ）ユーザ端末３０Ｂからの賛同承認手続が完了するごとに、仮想商店街管理サーバ１０は、専用線２１を通じて与信情報管理サーバ５０に対し与信枠の確保を要求し、各賛同者候補の与信限度枠内において｛（代金の総額）／（与信枠確保済の賛同者数＋２）｝により算出される額に相当する与信枠を確保する。
（ｃ）賛同者の与信枠が新たに確保されるごとに、仮想商店街管理サーバ１０は、専用線２１を通じて与信情報管理サーバ５０に対し、幹事及び他の賛同者の既に確保されている与信枠につき、｛（代金の総額）／（与信枠確保済の賛同者数＋１）｝により算出される額への減額を要求する。
（ｄ）ユーザ端末３０Ｃからの受取承認手続が完了すると、仮想商店街管理サーバ１０は、専用線２１を通じて与信情報管理サーバ５０に対し課金処理を行ない、最新の与信枠に相当する各ユーザの負担額を回収する。一方、ユーザ端末３０Ｃからの受取拒否手続が完了すると、仮想商店街管理サーバ１０は、専用線２１を通じて与信情報管理サーバ５０に対し確保している与信枠の解除を要求する。
【００２７】
（１−５．実施形態のシステムによる処理の特徴）
本実施形態のシステムによる決済処理の主たる特徴は、幹事及びすべての賛同者につき、与信業者に対し与信枠の確保を要求する時点における負担額に相当する額の与信枠を確保しておき、賛同者数が増加するごとに、与信業者に対し既に確保している与信枠の減額を要求する点にある。
与信枠の確保を要求する時点における負担額に相当する額の与信枠を確保することにより、不必要な与信枠を確保しなくて済むため、賛同者は、与信限度枠を他の取引のために有効に利用することができる。また、賛同者数が増加するごとに既に確保している与信枠を減額することにより、不必要になった与信枠を早期に返還（解除）することが可能になるため、幹事及び賛同者は、与信限度枠を他の取引のためにより有効に利用することができる。
【００２８】
（２．実施形態のシステムの詳細）
本実施形態のシステムの構成を、図１及び図２を用いて詳細に説明する。
ここでは、共同ギフト支援サービスの提供に必要な部分を中心として、特に注文情報データベース１４に記憶している情報の内容について詳細に説明する。
【００２９】
（２−１．仮想商店街管理サーバ）
図１において、仮想商店街管理サーバ１０は、仮想商店街管理サービス及び共同ギフト支援サービスを提供するサーバである。
仮想商店街管理サーバ１０は、Ｗｅｂサーバの機能を有しており、要求に応じてＷｅｂページの生成・送信等の処理を行うことができる。例えば、仮想商店街管理サーバ１０は、ユーザ端末３０Ａ，ユーザ端末３０Ｂ（１〜ｎ），ユーザ端末３０Ｃ等からの送信要求に応じて、会員情報データベース１１，加盟店情報データベース１２，商品情報データベース１３，注文情報データベース１４に記憶されている必要な情報を読み出し、指定されたＵＲＬに対応するＷｅｂページを生成し、送信することができる。
また、仮想商店街管理サーバ１０は、メールサーバの機能を有しており、必要に応じて電子メールの生成・送信処理を行うことができる。
【００３０】
（２−２（ａ）．会員情報データベース）
図１において、会員情報データベース１１は、仮想商店街管理サービスの会員の情報（以下、「会員情報」という。）を記憶しているデータベースである。ここでは、本実施形態のシステムに関して必要な部分のみを説明する。
なお、本実施形態においては、会員情報データベース１１を仮想商店街管理サーバ１０に内蔵された記憶装置に構築しているが、記憶している情報の読出しが可能であれば他の独立した記憶装置に構築してもよい。
【００３１】
図２（ａ）に、会員情報データベース１１の主要な項目を示す。
図２（ａ）は１つの会員情報であり、会員情報データベース１１には複数の会員情報が記憶されている。また、会員情報は、新規の会員登録により生成され、会員からの要求に応じて適宜変更される。
【００３２】
図２（ａ）において、「ユーザＩＤ」は、仮想商店街管理サービスの利用登録をしているユーザ（会員）に一意の識別情報である。「パスワード」は、そのユーザの認証に用いるパスワードである。会員の認証（ログイン）には、会員情報の項目のうち「ユーザＩＤ」及び「パスワード」を用いる。
同じく、図２（ａ）において、「氏名」は、そのユーザの氏名である。「フリガナ」は、そのユーザの氏名に対応するフリガナ（片仮名）である。「郵便番号」は、そのユーザの住所に対応する郵便番号である。「住所」は、そのユーザの生活の本拠である。「電話番号」は、そのユーザの連絡先の電話番号である。「メールアドレス」は、そのユーザのユーザ端末（後述）が有するメーラで使用可能な電子メールアドレスである。
【００３３】
同じく、図２（ａ）において、「カード会社名」は、そのユーザが利用登録しているクレジットカードの発行者（カード会社）の名称である。「カード番号」は、そのユーザ名義のクレジットカードの番号であり、カード会社ごとにカード会員に一意の識別番号である。「カード名義」は、そのクレジットカードの名義であり、上記「氏名」と同一である。「カード有効期限」は、そのクレジットカードの有効期限である。
同じく、図２（ａ）において、「その他のユーザ関連情報」は、そのユーザに関連する情報（例えば、利用可能ポイント数，利用枠確保済みポイント数等）である。
【００３４】
（２−２（ｂ）．加盟店情報データベース）
図１に戻り、加盟店情報データベース１２は、仮想商店街管理サービスの加盟店の情報（以下、「加盟店情報」という。）を記憶しているデータベースである。ここでは、本実施形態のシステムに関して必要な部分のみを説明する。
なお、本実施形態においては、加盟店情報データベース１２を仮想商店街管理サーバ１０に内蔵された記憶装置に構築しているが、記憶している情報の読出しが可能であれば他の独立した記憶装置に構築してもよい。
【００３５】
図２（ｂ）に、加盟店情報データベース１２の主要な項目を示す。
図２（ｂ）は１つの加盟店情報であり、加盟店情報データベース１２には複数の加盟店情報が記憶されている。また、加盟店情報は、新規の出店登録により生成され、加盟店からの要求に応じて適宜変更される。
【００３６】
図２（ｂ）において、「店舗ＩＤ」は、仮想商店街管理サービスに出店登録をしている店舗（加盟店）に一意の識別情報である。本実施形態では、「店舗ＩＤ」としてその店舗のドメイン名を使用している。「認証キー」は、その店舗の認証に用いるキーである。加盟店の認証（ログイン）には、加盟店情報の項目のうち「店舗ＩＤ」及び「認証キー」を用いる。
同じく、図２（ｂ）において、「名称」は、その店舗の名称（例えば、商号，屋号，商標等）である。「メールアドレス」は、その店舗の店舗端末（後述）が有するメーラで使用可能な電子メールアドレスである。「その他の店舗関連情報」は、その店舗に関連する情報（例えば、代金払込先口座の番号，事業所の所在地，店舗の詳細を掲載したウェブページのＵＲＬ等）である。
【００３７】
（２−２（ｃ）．商品情報データベース）
図１に戻り、商品情報データベース１３は、仮想商店街管理サービスにおける注文対象の商品の情報（以下、「商品情報」という。）を記憶しているデータベースである。ここでは、本実施形態のシステムに関して必要な部分のみを説明する。
なお、本実施形態においては、商品情報データベース１３を仮想商店街管理サーバ１０に内蔵された記憶装置に構築しているが、記憶している情報の読出しが可能であれば他の独立した記憶装置に構築してもよい。
【００３８】
図２（ｃ）に、商品情報データベース１３の主要な項目を示す。
図２（ｃ）は１つの商品情報であり、商品情報データベース１３には複数の商品情報が記憶されている。また、商品情報は、例えば店舗端末４０からの入力により生成され、店舗端末４０からの要求に応じて適宜変更される。
【００３９】
図２（ｃ）において、「商品コード」は、仮想商店街管理サービスにおける注文対象の商品に一意の識別情報である。「名称」は、その商品の名称である。「単価」は、その商品に設定された単位数量あたりの価格である。
同じく、図２（ｃ）において、「説明文」は、その商品の内容・品質・属性等を簡単に説明する文字列である。「画像ＵＲＬ」は、その商品の画像を識別するＵＲＬである。「その他の商品関連情報」は、その商品に関連する情報（例えば、取扱店舗ＩＤ（その商品を取り扱う店舗の店舗ＩＤ）等）である。
【００４０】
（２−２（ｄ）．注文情報データベース）
図１に戻り、注文情報データベース１４は、仮想商店街管理サービスにおいて受け付けられた注文の情報（以下、「注文情報」という。）を記憶しているデータベースである。ここでは、本実施形態のシステムに関して必要な部分のみを説明する。
なお、本実施形態においては、注文情報データベース１４を仮想商店街管理サーバ１０に内蔵された記憶装置に構築しているが、記憶している情報の読出しが可能であれば他の独立した記憶装置に構築してもよい。
【００４１】
図２（ｄ）に、注文情報データベース１４の主要な項目を示す。
図２（ｄ）は１つの注文情報であり、注文情報データベース１４には複数の注文情報が記憶されている。また、注文情報は、例えばユーザ端末３０Ａからの注文手続により生成され、決済処理等の進捗状況に応じて適宜変更される。
【００４２】
図２（ｄ）において、「注文番号」は、仮想商店街管理サービスにおいて受け付けられた注文に一意の識別情報である。「注文ステータス」は、その注文手続の進捗状況（例えば、「与信枠確保待ち」，「募集期限経過待ち」，「受取手続待ち」，「決済処理待ち」，「発送待ち」，「完了」，「不成立」等）を示す情報であり、初期値を「与信枠確保待ち」とする。
同じく、図２（ｄ）において、「商品１の商品コード」は、その注文に係る商品１の識別情報であり、注文情報に商品１の商品情報を紐付けている。「商品１の数量」は、その注文に係る商品１の注文数である。ｎ種類（ｎは任意の自然数）の商品が注文された場合には、商品１〜商品ｎに対応する「商品コード」及び「数量」の組を設ける。「代金総額」は、その注文に係る代金の総額である。
【００４３】
同じく、図２（ｄ）において、「幹事のユーザＩＤ」は、その注文に係る幹事の識別情報であり、注文情報に幹事の会員情報を紐付けている。「幹事の負担額」は、その注文において幹事が負担する金額であり、その注文に対する処理の進捗状況に応じて変化し得る。「幹事の与信枠確保済フラグ」は、その注文において幹事の与信枠が確保されているか否かを示すフラグであり、与信枠が確保されたときにフラグを立てる。
同じく、図２（ｄ）において、「受取人のユーザＩＤ」は、その注文に係る受取人の識別情報であり、注文情報に受取人の会員情報を紐付ける。「受取人の氏名」は、その注文に係る受取人の氏名である。「受取人のメールアドレス」は、その注文に係る受取人のユーザ端末（後述）が有するメーラで使用可能な電子メールアドレスである。「受取ステータス」は、その注文に係る受取手続の進捗状況（例えば、「手続待ち」，「承認」，「非承認」等）を示す情報であり、初期値を「手続待ち」とする。
【００４４】
同じく、図２（ｄ）において、「募集期限」は、その注文における賛同者の募集期間の終了日時である。「募集人数」は、その注文における賛同者の募集人数である。「募集メッセージ」は、その注文における賛同者の募集に関する幹事からのメッセージである。「認証用のキーワード」は、その注文に係る賛同者候補の認証に用いるキーワードである。
同じく、図２（ｄ）において、「与信枠確保済の賛同者数」は、その注文において既に与信枠が確保されている賛同者の人数である。「手続完了済の賛同者候補数」は、その注文において、賛同手続を完了させた賛同者候補の人数である。
【００４５】
同じく、図２（ｄ）において、「賛同者１のユーザＩＤ」は、その注文に係る賛同者１の識別情報であり、注文情報に賛同者１の会員情報を紐付ける。「賛同者１の氏名」は、その注文に係る賛同者１の氏名である。「賛同者１のメールアドレス」は、その注文に係る賛同者１のユーザ端末が有するメーラで使用可能な電子メールアドレスである。「賛同者１の賛同ステータス」は、その注文に係る賛同者１の賛同手続の進捗状況（例えば、「手続待ち」，「与信枠確保待ち」，「承認」，「非承認」等）を示す情報であり、初期値を「手続待ち」とする。「賛同者１の負担額」は、その注文に係る賛同者１が負担する金額であり、その注文に対する処理の進捗状況に応じて変化し得る。「賛同者１の与信枠確保済フラグ」は、その注文に係る賛同者１の与信枠が確保されているか否かを示すフラグであり、確保されたときにフラグを立てる。
賛同者の候補がｎ人（ｎは任意の自然数）である場合には、賛同者１〜賛同者ｎにつき、それぞれ「ユーザＩＤ」，「氏名」，「メールアドレス」，「賛同ステータス」，「負担額」，「与信枠確保済フラグ」の項目を設ける。
【００４６】
なお、本実施形態では、幹事は、注文手続において、上記「氏名」と「メールアドレス」により受取人を指定する。そのため、上記「受取人のユーザＩＤ」は、注文を受け付けた当初は空であり、受取人が受取手続においてユーザＩＤを入力した場合にのみ、受取人のユーザＩＤを追加する。
同様に、本実施形態では、幹事は、注文手続において、上記「氏名」と「メールアドレス」により賛同者（候補）を指定する。そのため、上記「賛同者（１〜ｎ）のユーザＩＤ」は、注文を受け付けた当初は空であり、各賛同者の候補が賛同手続においてユーザＩＤを入力した場合にのみ、各賛同者のユーザＩＤを追加する。
【００４７】
（２−３．ユーザ端末）
図１に戻り、ユーザ端末３０Ａ，ユーザ端末３０Ｂ（１〜ｎ），ユーザ端末３０Ｃは、それぞれ幹事，賛同者１〜ｎ，受取人が使用している端末である。本実施形態においては、例えば、パソコンや携帯電話等の通信機能を有する既存の端末でよい。
ユーザ端末３０Ａ，ユーザ端末３０Ｂ（１〜ｎ），ユーザ端末３０Ｃは、それぞれＷｅｂブラウザの機能を有しており、必要に応じてＷｅｂページの要求・受信・表示処理を行い、仮想商店街管理サーバ１０が提供する仮想商店街管理サービスを電気通信回線網２０を通じて受けることができる。また、ユーザ端末３０Ａ，ユーザ端末３０Ｂ（１〜ｎ），ユーザ端末３０Ｃは、それぞれメーラの機能を有しており、必要に応じて電子メールの受信・表示処理を行うことができる。
【００４８】
（２−４．店舗端末）
図１において、店舗端末４０は、共同ギフト支援サービスを利用して商品を提供する店舗（加盟店）が使用している端末である。本実施形態においては、例えば、パソコン等の通信機能を有する既存の端末でよい。
店舗端末４０はブラウザを有しており、必要に応じてＷｅｂページの要求・受信・表示処理を行い、仮想商店街管理サーバ１０が提供する仮想商店街管理サービスを電気通信回線網２０を介して受けることができる。また、店舗端末４０は、それぞれメーラの機能を有しており、必要に応じて電子メールの受信・表示処理を行うことができる。
【００４９】
（２−５．与信情報管理サーバ）
図１において、与信情報管理サーバ５０は、本実施形態のシステムにおいて与信情報を管理しているクレジットカード会社のサーバである。本実施形態においては、クレジットカード会社が保有する既存のサーバ装置でよい。
なお、与信情報管理サーバ５０は、専用線２１を介して仮想商店街管理サーバ１０と接続しており、決済処理に関して仮想商店街管理サーバ１０と連携している。また、与信情報管理サーバ５０と仮想商店街管理サーバ１０との間では、データを暗号化して送受信している。なお、暗号化等によりデータを安全に送受信することができる限り、電気通信回線網２０を介して接続してもよい。
【００５０】
（３．各手続の手順）
共同ギフト支援サービスにおける各手続の手順を、図３（ａ）〜（ｃ）のシーケンス図及びページ例を用いて説明する。
ここでは、次の３つの手続の手順を説明する。
（ａ）注文手続の手順
（ｂ）賛同承認手続の手順
（ｃ）受取承認手続の手順
【００５１】
（３−１．注文手続の手順）
注文手続の手順を、図３（ａ）のシーケンス図及びページ例を用いて説明する。
以下の説明には、幹事（注文者）が、ユーザ端末３０Ａを用いて、仮想商店街管理サーバ１０に対し注文情報を送信する場合を例として用いている。
なお、幹事はユーザ端末３０Ａを用いて、例えば仮想商店街管理サービスの商品選択ページにおいて、単数又は複数の商品を既に選択している。ここでは、選択された商品を確定させる手順以降の操作及び処理を説明する。
【００５２】
（３−１（ａ）．商品選択情報の取得）
図３（ａ）に示すように、商品確認ページ（図示せず）において幹事が選択した商品を確認し、送信の操作を実行すると、ユーザ端末３０Ａは選択された商品の情報を仮想商店街管理サーバ１０に送信する。
仮想商店街管理サーバ１０は、商品の選択情報をユーザ端末３０Ａから受信する（Ｓ３０５ａ）。
【００５３】
（３−１（ｂ）．認証情報の取得）
続いて、仮想商店街管理サーバ１０は、ユーザ端末３０Ａに認証情報入力ページ（図示せず）を送信し、幹事に認証情報の入力を求める。
認証情報入力ページにおいて幹事が認証情報（ユーザＩＤ及びパスワード）を入力し、送信の操作を実行すると、ユーザ端末３０Ａは入力された認証情報を仮想商店街管理サーバ１０に送信する。
仮想商店街管理サーバ１０は、入力されたユーザＩＤ及びパスワードをユーザ端末３０Ａから受信し、幹事が会員であることを認証する（Ｓ３１０ａ）。
【００５４】
（３−１（ｃ）．共同ギフト選択情報の取得）
続いて、仮想商店街管理サーバ１０は、ユーザ端末３０Ａに注文形態選択ページ（図示せず）を送信し、幹事に注文形態の選択を求める。
注文形態選択ページにおいて幹事が注文形態（本実施形態では、共同ギフト）を選択すると、ユーザ端末３０Ａは共同ギフトの選択情報を仮想商店街管理サーバ１０に送信する。
仮想商店街管理サーバ１０は、共同ギフトの選択情報をユーザ端末３０Ａから受信する（Ｓ３１５ａ）。
【００５５】
（３−１（ｄ）．受取人情報の取得）
続いて、仮想商店街管理サーバ１０は、ユーザ端末３０Ａに受取人情報入力ページ（図示せず）を送信し、幹事に受取人の情報の入力を求める。
受取人情報入力ページにおいて幹事が受取人の情報（本実施形態では、受取人の氏名及びメールアドレス）を入力すると、ユーザ端末３０Ａは入力された受取人の情報を仮想商店街管理サーバ１０に送信する。
仮想商店街管理サーバ１０は、入力された受取人の氏名及びメールアドレスをユーザ端末３０Ａから受信する（Ｓ３２０ａ）。
なお、受取人の情報として、幹事に受取人の住所及び配送日時の入力を求めてもよい。
【００５６】
（３−１（ｅ）．募集期限及びキーワードの取得）
続いて、仮想商店街管理サーバ１０は、ユーザ端末３０Ａに募集期限及びキーワードの入力ページ（例えば、図９の入力ページ９００）を送信し、幹事に賛同者の募集期限９３０及び賛同者認証用のキーワード９４０の入力を求める。
入力ページ９００には、既に選択されている商品の情報９１０（選択された商品とその単価及び注文数、並びに代金の総額等）が表示される。
【００５７】
入力ページ９００において幹事が賛同者の募集期限９３０及び賛同者認証用のキーワード９４０を入力し、「次へ進む」と表示されているボタン９５０をクリックすると、ユーザ端末３０Ａは入力された募集期限及びキーワードを仮想商店街管理サーバ１０に送信する。
仮想商店街管理サーバ１０は、入力された募集期限及びキーワードをユーザ端末３０Ａから受信する（Ｓ３２５ａ）。
【００５８】
（３−１（ｆ）．賛同者候補情報及び募集メッセージの取得）
続いて、仮想商店街管理サーバ１０は、ユーザ端末３０Ａに賛同者候補の情報及び募集メッセージの入力ページ（例えば、図１０の入力ページ１０００）を送信し、幹事に賛同者候補の情報１０３０及び募集（賛同）メッセージ１０４０の入力を求める。
入力ページ１０００には、既に選択されている商品の情報１０１０（選択された商品とその単価及び注文数、並びに代金の総額等）が表示される。
【００５９】
入力ページ１０００において幹事が、（１）賛同者の募集人数１０２０、（２）賛同者候補の情報１０３０（本実施形態では、賛同者候補の氏名１０３１及びメールアドレス１０３２）及び（３）募集メッセージ１０４０を入力し、「次へ進む」と表示されているボタン１０５０をクリックすると、ユーザ端末３０Ａは入力された募集人数，賛同者候補の情報及び募集メッセージを仮想商店街管理サーバ１０に送信する。
仮想商店街管理サーバ１０は、入力された賛同者候補の情報及び募集メッセージをユーザ端末３０Ａから受信する（Ｓ３３０ａ）。
【００６０】
なお、幹事に募集人数を入力させれば、募集人数を限定することにより、受取人の注文者及び賛同者の一人ひとりに対する感心を高めることができる。
また、幹事に募集人数を入力させれば、入力させた募集人数に達した段階で、賛同者を確定させることができる。
【００６１】
（３−１（ｇ）．決済情報の取得）
続いて、仮想商店街管理サーバ１０は、ユーザ端末３０Ａに決済情報の入力ページ（図示せず）を送信し、幹事に決済情報の入力を求める。
決済情報の入力ページにおいて幹事が決済情報（本実施形態では、カード会社名，カード番号，カード名義，カード有効期限）を入力し、送信の操作を実行すると、ユーザ端末３０Ａは入力された決済情報を仮想商店街管理サーバ１０に送信する。
なお、幹事の会員情報にクレジットカードの情報が登録されている場合には、登録されているクレジットカードの情報を選択できるようにしてもよい。
仮想商店街管理サーバ１０は、入力された決済情報をユーザ端末３０Ａから受信する（Ｓ３３５ａ）。
【００６２】
（３−１（ｈ）．手続内容の確認）
以上の情報を取得すると、仮想商店街管理サーバ１０は、ユーザ端末３０Ａに手続内容の確認ページ（例えば、図１１の確認ページ１１００）を送信し、幹事に手続内容の確認を求める。
確認ページ１１００には、既に選択されている商品の情報１１１０（選択された商品とその単価及び注文数、並びに代金の総額等），募集期限１１２１及び賛同者の情報１１２２，注文者のクレジットカードの情報１１３０，受取人の情報１１４０，注文者の情報１１５０が表示される。
【００６３】
確認ページ１１００において幹事が手続を確認し、「この内容で贈る」と表示されているボタン１１６０をクリックすると、ユーザ端末３０Ａは確認された注文情報を仮想商店街管理サーバ１０に送信する。
仮想商店街管理サーバ１０は、確認された注文情報をユーザ端末３０Ａから受信する（Ｓ３４０ａ）。
【００６４】
（３−１（ｉ）．注文情報の生成）
確認された注文情報をユーザ端末３０Ａから受信する（Ｓ３４０ａ）と、仮想商店街管理サーバ１０は、取得した注文情報に注文番号を付与して注文情報データベース１４に記憶する（Ｓ３４５ａ）。
ここでは、注文ステータスを初期値の「与信枠確保待ち」とする。
【００６５】
（３−１（ｊ）．連絡メールの送信）
以上の処理が完了すると、仮想商店街管理サーバ１０は、注文手続が完了した旨の連絡メールを生成し、ユーザ端末３０Ａに送信する（Ｓ３５０ａ）。
【００６６】
（３−２．賛同承認手続の手順）
賛同承認手続の手順を、図３（ｂ）のシーケンス図及びページ例を用いて説明する。
以下の説明には、賛同者候補のうちの１人が、ユーザ端末３０Ｂを用いて、仮想商店街管理サーバ１０に対し賛同承認情報を送信する場合を例として用いている。
【００６７】
（３−２（ａ）．募集メールの送信）
ユーザ端末３０Ａからの注文手続が完了すると、仮想商店街管理サーバ１０は、共同ギフトへの賛同を募集する旨の募集メールを生成し、ユーザ端末３０Ｂに送信する（Ｓ３０５ｂ）。
なお、募集メールには、賛同手続トップページのＵＲＬと、賛同者候補認証用のキーワード（図３（ａ）のＳ３２５ａで取得したキーワード）を記載する。また、賛同手続トップページのＵＲＬには、注文番号を暗号化したパラメータが付加される。
【００６８】
（３−２（ｂ）．アクセス要求の受信）
募集メールを受信したユーザ端末３０Ｂから、賛同手続トップページへのアクセス要求を受信したとき（Ｓ３１０ｂ）、仮想商店街管理サーバ１０は、ＵＲＬパラメータにより対象となる注文情報を識別する。
なお、募集期限（図３（ａ）のＳ３２５ａで取得した募集期限）が経過しているとき、仮想商店街管理サーバ１０は、募集期限が経過しており賛同手続を行うことができない旨を記載したＷｅｂページをユーザ端末３０Ｂに送信し、以降の処理を行わない。
【００６９】
（３−２（ｃ）．認証情報の取得）
続いて、仮想商店街管理サーバ１０は、ユーザ端末３０Ｂに認証情報入力ページ（例えば、図１２の入力ページ１２００）を送信し、賛同者候補に認証情報の入力を求める。
入力ページ１２００において賛同者候補が認証情報（ここでは、募集メールを受信したメールアドレス１２１０及び募集メールに記載されたキーワード１２２０）を入力し、「次へ進む」と表示されているボタン１２３０をクリックすると、ユーザ端末３０Ｂは入力された認証情報を仮想商店街管理サーバ１０に送信する。
仮想商店街管理サーバ１０は、入力されたメールアドレス１２１０及びキーワード１２２０をユーザ端末３０Ｂから受信し、賛同者候補が幹事により指定された賛同者候補（図３（ａ）のＳ３３０ａにおいて指定された賛同者候補）であることを認証する（Ｓ３１５ｂ）。
【００７０】
（３−２（ｄ）．応答の取得）
続いて、仮想商店街管理サーバ１０は、ユーザ端末３０Ｂに応答選択ページ（例えば、図１３の選択ページ１３００）を送信し、賛同者候補に応答の選択を求める。
選択ページ１３００には、幹事の氏名１３１０，選択された商品の情報１３２０，賛同メッセージ１３３０，賛同者の募集に関連する情報１３４０（ここでは、募集中である旨１３４１，現在の賛同人数及び１人当たりの負担額，募集期限１３４３並びに賛同する場合の負担額の上限額１３４４）が表示される。
【００７１】
選択ページ１３００において賛同者候補が応答（ここでは、賛同１３５１）を選択し、「次へ進む」と表示されているボタン１３５３をクリックすると、ユーザ端末３０Ｂは選択された応答を仮想商店街管理サーバ１０に送信する。
仮想商店街管理サーバ１０は、選択された賛同要求をユーザ端末３０Ｂから受信する（Ｓ３２０ｂ）。
【００７２】
なお、選択ページ１３００で賛同者候補が拒否１３５２を選択し、「次へ進む」と表示されているボタン１３５３をクリックした場合、ユーザ端末３０Ｂには拒否の確認ページ（例えば、図１６の確認ページ１６００）が送信される。この確認ページ１６００において、「賛同を拒否する」と表示されているボタン１６５０をクリックすると、賛同拒否の手続が完了される。
【００７３】
（３−２（ｅ）．認証情報の取得）
続いて、仮想商店街管理サーバ１０は、ユーザ端末３０Ｂに認証情報入力ページ（図示せず）を送信し、賛同者候補に認証情報の入力を求める。
認証情報入力ページにおいて賛同者候補が認証情報（ここでは、ユーザＩＤ及びパスワード）を入力し、送信の操作を実行すると、ユーザ端末３０Ｂは入力された認証情報を仮想商店街管理サーバ１０に送信する。
仮想商店街管理サーバ１０は、入力されたユーザＩＤ及びパスワードをユーザ端末３０Ｂから受信し、賛同者候補が会員であることを認証する（Ｓ３２５ｂ）。
【００７４】
（３−２（ｆ）．決済情報の取得）
続いて、仮想商店街管理サーバ１０は、ユーザ端末３０Ｂに決済情報の入力ページ（例えば、図１４の入力ページ１４００）を送信し、賛同者候補に決済情報の入力を求める。
入力ページ１４００において賛同者候補が決済情報１４１０（本実施形態では、カード会社名，カード番号，カード名義，カード有効期限）を入力し、「次へ進む」と表示されているボタン１４２０をクリックすると、ユーザ端末３０Ｂは入力された決済情報を仮想商店街管理サーバ１０に送信する。
なお、賛同者候補の会員情報にクレジットカードの情報が登録されている場合には、登録されているクレジットカードの情報を選択できるようにしてもよい。
仮想商店街管理サーバ１０は、入力された決済情報をユーザ端末３０Ｂから受信する（Ｓ３３０ｂ）。
【００７５】
（３−２（ｇ）．手続内容の確認）
以上の情報を取得すると、仮想商店街管理サーバ１０は、ユーザ端末３０Ｂに手続内容の確認ページ（例えば、図１５の確認ページ１５００）を送信し、賛同者候補に手続内容の確認を求める。
確認ページ１５００には、賛同した場合の負担額の上限額１５１０及び賛同者候補のクレジットカードの情報１５２０が表示される。
確認ページ１５００において賛同者候補が手続を確認し、「賛同する」と表示されているボタン１５３０をクリックすると、ユーザ端末３０Ｂは、確認された賛同情報（ここでは、賛同承認の情報）を仮想商店街管理サーバ１０に送信する。
仮想商店街管理サーバ１０は、確認された賛同承認の情報をユーザ端末３０Ｂから受信する（Ｓ３３５ｂ）。
【００７６】
（３−２（ｈ）．注文情報の更新）
確認された賛同承認の情報をユーザ端末３０Ｂから受信する（Ｓ３３５ｂ）と、仮想商店街管理サーバ１０は、取得した賛同承認情報に基づいて、識別した注文情報（図３（ｂ）のＳ３１０ｂにおいてＵＲＬパラメータにより識別した注文情報）を更新する（Ｓ３４０ｂ）。
ここでは、賛同ステータスを「与信枠確保待ち」に変更する。
【００７７】
（３−２（ｉ）．連絡メールの送信）
以上の処理が完了すると、仮想商店街管理サーバ１０は、賛同承認手続が完了した旨の連絡メールを生成し、ユーザ端末３０Ｂに送信する（Ｓ３４５ｂ）。
【００７８】
（３−３．受取承認手続の手順）
受取承認手続の手順を、図３（ｃ）のシーケンス図及びページ例を用いて説明する。
以下の説明には、受取人が、ユーザ端末３０Ｃを用いて、仮想商店街管理サーバ１０に対し受取承認情報を送信する場合を例として用いている。
【００７９】
（３−３（ａ）．案内メールの送信）
募集期限（図３（ａ）のＳ３２５ａで取得した募集期限）が経過すると、仮想商店街管理サーバ１０は、共同ギフトの受取りを案内する旨の案内メールを生成し、ユーザ端末３０Ｃに送信する（Ｓ３０５ｃ）。募集期限が経過したことの代わりに、賛同を承認した賛同者候補の人数が募集人数に達したことを条件として、同様の処理を行ってもよい。  なお、案内メールには、受取手続トップページのＵＲＬを記載する。また、受取手続トップページのＵＲＬには、注文番号を暗号化したパラメータが付加される。
【００８０】
（３−３（ｂ）．アクセス要求の受信）
案内メールを受信したユーザ端末３０Ｃから、受取手続トップページへのアクセス要求を受信したとき（Ｓ３１０ｃ）、仮想商店街管理サーバ１０は、ＵＲＬパラメータにより対象となる注文情報を識別する。
【００８１】
（３−３（ｃ）．応答の取得）
続いて、仮想商店街管理サーバ１０は、ユーザ端末３０Ｃに応答選択ページ（例えば、図１７の選択ページ１７００）を送信し、受取人に応答の選択を求める。
選択ページ１７００には、賛同メッセージ１７１０，選択された受取対象の商品１７２０が表示される。
【００８２】
選択ページ１７００において受取人が応答（ここでは、受取）を選択し、「受け取る」と表示されているボタン１７３１をクリックすると、ユーザ端末３０Ｃは選択された応答を仮想商店街管理サーバ１０に送信する。仮想商店街管理サーバ１０は、選択された受取要求をユーザ端末３０Ｃから受信する（Ｓ３１５ｃ）。
【００８３】
なお、選択ページ１７００において受取人が「受取を拒否する」と表示されているボタン１７３２をクリックした場合、ユーザ端末３０Ｃは拒否の応答を仮想商店街管理サーバ１０に送信する。
この場合、ユーザ端末３０Ｃには、受取拒否の確認ページ（例えば、図１９の確認ページ１９００）が送信される。この確認ページ１９００において、受取人が「受取を拒否する」と表示されているボタン１９３０をクリックすると、受取拒否の手続が完了する。
【００８４】
（３−３（ｄ）．認証情報の取得）
続いて、仮想商店街管理サーバ１０は、ユーザ端末３０Ｃに認証情報入力ページ（図示せず）を送信し、受取人に認証情報の入力を求める。
認証情報入力ページにおいて受取人が認証情報（ここでは、ユーザＩＤ及びパスワード）を入力すると、ユーザ端末３０Ｃは入力された認証情報を仮想商店街管理サーバ１０に送信する。
仮想商店街管理サーバ１０は、入力されたユーザＩＤ及びパスワードをユーザ端末３０Ｃから受信し、受取人が会員であることを認証する（Ｓ３２０ｃ）。
なお、受取人は会員でなくてもよいため、受取人は、ユーザ端末３０Ｃで操作することにより、認証情報の入力を省略することができる。
【００８５】
（３−３（ｅ）．受取人情報の取得）
続いて、仮想商店街管理サーバ１０は、ユーザ端末３０Ｃに配送先情報入力ページ（図示せず）を送信し、受取人が認証情報の入力をスキップしたときには受取人に配送先情報及び配送日時の入力を求める。
受取人情報入力ページにおいて受取人が配送先情報（ここでは、受取人の住所等）及び配送日時を入力すると、ユーザ端末３０Ｃは、入力された配送先情報及び配送日時を仮想商店街管理サーバ１０に送信する。
仮想商店街管理サーバ１０は、入力された受取人の住所及び配送日時をユーザ端末３０Ｃから受信する（Ｓ３２５ｃ）。
なお、受取人が会員であるとき（Ｓ３２０ｃで認証されているとき）は、受取人情報入力ページに予め受取人の会員情報に記憶されている住所等を表示しておくことができる。
【００８６】
（３−３（ｆ）．手続内容の確認）
以上の情報を取得すると、仮想商店街管理サーバ１０は、ユーザ端末３０Ｃに手続内容の確認ページ（例えば、図１８の確認ページ１８００）を送信し、受取人に手続内容の確認を求める。
確認ページ１８００において受取人が手続を確認し、「次へ進む」と表示されているボタン１８２０をクリックすると、ユーザ端末３０Ｃは、確認された受取情報（ここでは、受取承認の情報）を仮想商店街管理サーバ１０に送信する。
仮想商店街管理サーバ１０は、確認された受取承認の情報をユーザ端末３０Ｃから受信する（Ｓ３３５ｃ）。
【００８７】
（３−３（ｇ）．注文情報の更新）
確認された受取承認情報をユーザ端末３０Ｃから受信する（Ｓ３３５ｃ）と、仮想商店街管理サーバ１０は、取得した受取承認情報に基づいて、識別した注文情報（図３（ｃ）のＳ３１０ｃにおいてＵＲＬパラメータにより識別した注文情報）を更新する（Ｓ３４０ｃ）。
ここでは、受取ステータスを「承認」に変更する。
【００８８】
（３−３（ｈ）．連絡メールの送信）
以上の処理が完了すると、仮想商店街管理サーバ１０は、受取承認手続が完了した旨の連絡メールを生成し、ユーザ端末３０Ｃに送信する（Ｓ３４５ｃ）。
【００８９】
（４．サーバによる決済処理）
共同ギフト支援サービスにおける決済処理の手順を、図４〜図７のフローチャート及びページ例を用いて説明する。
ここでは、次の３つの決済処理を、それぞれ説明する。
（ａ）注文手続段階における決済処理
（ｂ）賛同手続段階における決済処理
（ｃ）受取手続段階における決済処理
【００９０】
（４−１．注文手続段階における決済処理）
注文手続段階における決済処理を、図４のフローチャートを用いて説明する。
なお、図４のフローチャートは、幹事（注文者）による注文手続が完了した後、注文情報を生成する処理（図３（ａ）のＳ３４５ａに対応）から始まる。
【００９１】
（４−１．幹事（注文者）の与信枠の確保）
図４に示すように、注文情報を生成する処理（Ｓ３４５ａ）に続いて、仮想商店街管理サーバ１０は、幹事が指定したクレジットカードの与信情報を管理している与信情報管理サーバ（ここでは、与信情報管理サーバ５０）に対し、与信枠の確保を要求する（Ｓ４１０）。ここでは、代金総額に相当する与信枠の確保を要求する。
与信枠確保の要求を受けた与信情報管理サーバ５０は、幹事の与信情報を参照し、与信限度額内において要求された額に相当する与信枠を確保することができるか否かを判定する。
【００９２】
与信枠を確保することができる場合、与信情報管理サーバ５０は、与信枠の確保処理を行い、仮想商店街管理サーバ１０に与信枠が確保された旨を通知する。一方、与信枠を確保することができない場合、与信情報管理サーバ５０は、与信枠が確保されなかった旨を仮想商店街管理サーバ１０に通知する。
与信情報管理サーバ５０から通知を受信すると、仮想商店街管理サーバ１０は、幹事に対する与信枠を確保することができたか否かを判定する（Ｓ４１５）。
【００９３】
（４−１（ｂ）．与信枠が確保できた場合）
幹事の与信枠が確保できたとき（Ｓ４１５でＹｅｓ）、仮想商店街管理サーバ１０は、注文情報を更新する（Ｓ４２０）。ここでは、「幹事の与信枠確保済フラグ」を立て、注文ステータスを「募集期限経過待ち」に変更する。
また、このとき、仮想商店街管理サーバ１０は、注文手続完了の連絡メールをユーザ端末３０Ａに送信する（Ｓ３５０ａ）。
【００９４】
（４−１（ｃ）．与信枠が確保できなかった場合）
一方、幹事の与信枠が確保できなかったとき（Ｓ４１５でＮｏ）、仮想商店街管理サーバ１０は、注文情報を更新する（Ｓ４２５）。ここでは、注文ステータスを「不成立」とする。
また、このとき、仮想商店街管理サーバ１０は、注文不成立の連絡メールをユーザ端末３０Ａに送信する（Ｓ４３０）。
【００９５】
（４−２．賛同手続段階における決済処理）
賛同手続段階における決済処理を、図５−１及び図５−２のフローチャート及びページ例を用いて説明する。
なお、図５−１及び図５−２のフローチャートは、ユーザ端末３０Ｂ（１〜ｎ）に募集メールを送信した後、賛同手続トップページの送信要求を受信する処理（図３（ｂ）のＳ３１０ｂに対応）から始まる。
【００９６】
（４−２（ａ）．賛同者候補の認証）
図５−１に示すように、仮想商店街管理サーバ１０は、賛同手続トップページの送信要求を受信すると（Ｓ３１０ｂ）、ＵＲＬパラメータにより対象となる注文情報を識別するとともに、ユーザ端末３０Ｂに認証情報入力ページ（例えば、図１２の入力ページ１２００）を送信し、賛同者候補に認証情報の入力を求める。
ユーザ端末３０Ｂが認証情報入力ページ１２００を受信すると、賛同者候補は、メールアドレス１２１０及びキーワード１２２０を入力する。
【００９７】
認証情報入力ページ１２００において賛同者候補が認証情報（ここでは、メールアドレス１２１０及びキーワード１２２０）を入力し、「次へ進む」と表示されているボタン１２３０をクリックすると、ユーザ端末３０Ｂは入力された認証情報を仮想商店街管理サーバ１０に送信する。
仮想商店街管理サーバ１０は、入力されたメールアドレス及びキーワードをユーザ端末３０Ｂから受信し、受信したメールアドレス及びキーワードが適正であるか否かを判定する（Ｓ５０５）。
【００９８】
取得したメールアドレス及びキーワードが適正であるとき（Ｓ５０５でＹｅｓ）、仮想商店街管理サーバ１０は、そのユーザが幹事により指定された適正な賛同者候補（図３（ａ）のＳ３３０ａにおいて指定された賛同者候補）であることを認証した上で、ユーザ端末３０Ｂに応答（賛同要求又は拒否要求）を選択させる応答選択ページ（例えば、図１３の選択ページ１３００）を送信し、その賛同者候補に賛同要求又は拒否要求を選択させる。
取得したメールアドレス及びキーワードが適正でないとき（Ｓ５０５でＮｏ）、仮想商店街管理サーバ１０は、そのユーザは幹事（注文者）が指定した適正な賛同者（候補）でないものとみなし、処理を終了する。
【００９９】
（４−２（ｂ）．賛同又は拒否の判定）
選択ページ１３００において賛同者候補が応答（賛同１３５１又は拒否１３５２）を選択すると、ユーザ端末３０Ｂは選択された応答を仮想商店街管理サーバ１０に送信する。
仮想商店街管理サーバ１０は、選択された応答をユーザ端末３０Ｂから受信し（Ｓ５１０）、応答が賛同要求か否かを判定する（Ｓ５１５）。
【０１００】
受信した応答が賛同要求であるとき（Ｓ５１５でＹｅｓ）、仮想商店街管理サーバ１０は、賛同承認として処理を進める（Ｓ５２０〜Ｓ５７５）。
一方、受信した応答が拒否要求であるとき（Ｓ５１５でＮｏ）、仮想商店街管理サーバ１０は、賛同拒否として処理を進める（Ｓ５８０〜Ｓ５９０）。
【０１０１】
（４−２（ｃ）．会員認証）
受信した応答が賛同要求であるとき（Ｓ５１５でＹｅｓ）、仮想商店街管理サーバ１０は、ユーザ端末３０Ｂに認証情報入力ページを送信し、賛同者候補に認証情報の入力又は新規会員登録を求める。
認証情報入力ページにおいて賛同者候補が認証情報（ここでは、ユーザＩＤ及びパスワード）を入力しログインを選択すると、ユーザ端末３０Ｂは認証要求とともに入力された認証情報を仮想商店街管理サーバ１０に送信する。また、賛同候補者が認証情報入力ページにユーザ情報を入力し新規登録を選択すると、ユーザ端末３０Ｂは会員登録要求とともに入力されたユーザ情報を仮想商店街管理サーバ１０に送信する。
仮想商店街管理サーバ１０は、応答の内容、並びに入力されたユーザＩＤ及びパスワード又はユーザ情報をユーザ端末３０Ｂから受信し（Ｓ５２０）、その内容を判定する（Ｓ５２５）。
【０１０２】
受信した応答が認証要求であるとき（Ｓ５２５でＹｅｓ）、仮想商店街管理サーバ１０は、続いて、認証要求とともに受信したユーザＩＤ及びパスワードが適正か否かを判定する（Ｓ５３０）。
一方、受信した応答が会員登録要求であるとき（Ｓ５２５でＮｏ）、仮想商店街管理サーバ１０は、会員登録要求とともに受信したユーザ情報をもとに、新規会員登録処理を行う（Ｓ５３５）。これにより、賛同者候補の未登録ユーザを、会員登録に誘導することができる。
【０１０３】
認証要求とともに受信したユーザＩＤ及びパスワードが適正であるとき（Ｓ５３０でＹｅｓ）、又は、新規会員登録処理（Ｓ５３５）が完了したとき、仮想商店街管理サーバ１０は、その賛同者候補の賛同承認手続を処理する（Ｓ５４０，図３（ｂ）のＳ３３０ｂ〜Ｓ３３５ｂに対応，図１４のページ１４００，図１５のページ１５００も参照）。
一方、認証要求とともに受信したユーザＩＤ及びパスワードが適正でないとき（Ｓ５３０でＮｏ）、仮想商店街管理サーバ１０は、応答等を受信する処理（Ｓ５２０）に戻る。
【０１０４】
（４−２（ｄ）．賛同承認の場合）
賛同承認の手続を処理した後、仮想商店街管理サーバ１０は、取得した賛同承認情報に基づいて、識別した注文情報（図３（ｂ）のＳ３１０ｂにおいてＵＲＬパラメータにより識別した注文情報）を更新する（Ｓ３４０ｂ）。
ここでは、賛同ステータスを「与信枠確保待ち」に変更する。
【０１０５】
続いて、仮想商店街管理サーバ１０は、注文情報の「与信枠確保済の賛同者数」を読出し（Ｓ５４５）、その賛同者候補が指定したクレジットカードの与信情報を管理している与信情報管理サーバ（ここでは、与信情報管理サーバ５０）に対し、与信枠の確保を要求する（Ｓ５５０）。ここでは、（代金総額）／（与信枠確保済の賛同者数＋２）に相当する与信枠の確保を要求する。
与信枠確保の要求を受けた与信情報管理サーバ５０は、幹事の与信情報を参照し、与信限度額内において要求された額に相当する与信枠を確保することができるか否かを判定する。
【０１０６】
与信枠を確保することができる場合、与信情報管理サーバ５０は、与信枠の確保処理を行い、仮想商店街管理サーバ１０に与信枠が確保された旨を通知する。一方、与信枠を確保することができない場合、与信情報管理サーバ５０は、与信枠が確保されなかった旨を仮想商店街管理サーバ１０に通知する。
与信情報管理サーバ５０から通知を受信すると、仮想商店街管理サーバ１０は、幹事に対する与信枠を確保することができたか否かを判定する（Ｓ４１５）。
【０１０７】
賛同者候補の与信枠が確保できたとき（Ｓ５５５でＹｅｓ）、仮想商店街管理サーバ１０は、注文情報を更新する（Ｓ５６０）。ここでは、その賛同者候補の「与信枠確保済フラグ」を立て、賛同ステータスを「承認」に変更するとともに、「与信枠確保済の賛同者数」に１を加算する。なお、以下の処理では、加算後の「与信枠確保済の賛同者数」を用いる。
また、このとき、仮想商店街管理サーバ１０は、賛同手続完了の連絡メールをユーザ端末３０Ｂに送信する（Ｓ３４５ｂ）。
【０１０８】
一方、賛同者候補の与信枠が確保できなかったとき（Ｓ５５５でＮｏ）、仮想商店街管理サーバ１０は、注文情報を更新する（Ｓ５８５）。ここでは、賛同ステータスを「非承認」とする。
また、このとき、仮想商店街管理サーバ１０は、賛同手続完了（拒否又は非承認）の連絡メールをユーザ端末３０Ｂに送信する（Ｓ５９０）。
【０１０９】
（４−２（ｆ）．確保済の与信枠を減額）
賛同手続完了の連絡メールをユーザ端末３０Ｂに送信した後（Ｓ３４５ｂ）、仮想商店街管理サーバ１０は、与信情報管理サーバ５０に対し、既に確保されている幹事の与信枠につき、｛（代金の総額）／（与信枠確保済の賛同者数＋１）｝により算出される額への減額を要求する（Ｓ５６５）。
同様に、仮想商店街管理サーバ１０は、与信情報管理サーバ５０に対し、既に確保されている他のすべての賛同者の与信枠につき、｛（代金の総額）／（与信枠確保済の賛同者数＋１）｝により算出される額への減額を要求する（Ｓ５７０）。
【０１１０】
他のすべての賛同者の与信枠が減額された後（Ｓ５７０）、及び賛同手続完了（非承認）の連絡メールをユーザ端末３０Ｂに送信した（Ｓ５９０）後、仮想商店街管理サーバ１０は、注文情報を更新する（Ｓ５７５）。ここでは、「手続完了済の賛同者候補数」に１を加算する。
【０１１１】
（４−２（ｅ）．賛同拒否の場合）
受信した応答の内容を判定する処理（図５−１のＳ５１５）において、受信した応答が拒否要求であるとき（Ｓ５１５でＮｏ）、仮想商店街管理サーバ１０は、賛同拒否の手続を処理し（Ｓ５８０，図１６のページ１６００も参照）、注文情報を更新する（Ｓ５８５）。ここでは、賛同ステータスを「非承認」とする。
また、このとき、仮想商店街管理サーバ１０は、賛同手続完了（非承認）の連絡メールをユーザ端末３０Ｂに送信する（Ｓ５９０）。
【０１１２】
（４−３．受取手続段階における決済処理）
受取手続段階における決済処理を、図６〜８のフローチャート及びページ例を用いて説明する。
まず、案内メールの送信処理を、図６のフローチャートを用いて説明する。本実施形態では、所定期間ごと（例えば、２４時間ごと）に起動するバッチ処理により、案内メールを送信する対象の注文情報を特定している。
なお、図７のフローチャートは、ユーザ端末３０Ｃに案内メールを送信した後、受取手続トップページの送信要求を受信する処理（図３（ｃ）のＳ３１０ｃに対応）から始まる。
【０１１３】
（４−３（ａ）．案内メールの送信）
図６に示すように、仮想商店街管理サーバ１０は、注文情報データベース１４に記憶されている注文情報のうち、注文ステータスが「募集期限経過待ち」であるものを検索し、読出す（Ｓ６０５）。
続いて、読出した処理対象の注文情報の件数を変数ｋに入力する（Ｓ６１０）。また、変数ｉに１を代入する。
【０１１４】
続いて、仮想商店街管理サーバ１０は、次の処理を繰り返す。
（１）ｉ番目に読み出した注文情報の募集期限が経過しているか否かを判定する（Ｓ６２０ａ）。募集期限が経過しているとき（Ｓ６２０ａでＹｅｓ）、下記（２）に進む。一方、募集期限が経過していないとき（Ｓ６２０ａでＮｏ）、下記（４）に進む。
（２）ｉ番目に読み出した注文情報を更新する（Ｓ６２５）。ここでは、注文ステータスを「受取手続待ち」に変更する。
（３）共同ギフトの案内メールを生成し、受取人のメールアドレス宛に送信する（Ｓ３０５ｃ）。
（４）ｉにｉ＋１を代入する（Ｓ６３０）。
（５）「ｉ＞ｋ」の真偽を判定する（Ｓ６３５）。真のとき（Ｓ６３５でＹｅｓ）、ループを抜けて終了する。一方、偽のとき（Ｓ６３５でＮｏ）、上記（１）に戻る。
【０１１５】
（４−３（ｂ）．応答の取得）
図７に示すように、共同ギフトの案内メールを受信したユーザ端末３０Ｃから、受取手続トップページへのアクセス要求を受信したとき（Ｓ３１０ｃ）、仮想商店街管理サーバ１０は、ＵＲＬパラメータにより対象となる注文情報を識別する。
続いて、仮想商店街管理サーバ１０は、ユーザ端末３０Ｃに応答選択ページ（例えば、図１７の選択ページ１７００）を送信し、受取人に応答の選択を求める。
選択ページ１７００において受取人が応答（受取要求又は拒否要求）を選択すると、ユーザ端末３０Ｃは選択された応答を仮想商店街管理サーバ１０に送信する。
仮想商店街管理サーバ１０は、選択された応答をユーザ端末３０Ｃから受信し（Ｓ７０５）、その内容を判定する（Ｓ７１０）。
【０１１６】
（４−３（ｃ）．受取承認の場合）
受信した応答が受取要求であるとき（Ｓ７１０でＹｅｓ）、仮想商店街管理サーバ１０は、受取承認手続を処理し（Ｓ７１５，図３（ｃ）のＳ３２０ｃ〜Ｓ３３５ｃ及び図１８の確認ページ１８００も参照）、取得した受取承認情報に基づいて、識別した注文情報（図７のＳ３１０ｃにおいてＵＲＬパラメータにより識別した注文情報）を更新する（Ｓ３４０ｃ）。
ここでは、受取ステータスを「承認」に変更する。
【０１１７】
続いて、仮想商店街管理サーバ１０は、幹事又は賛同者がそれぞれ指定したクレジットカードの与信情報を管理している与信情報管理サーバ（ここでは、いずれも与信情報管理サーバ５０）に対し、課金処理を行なう（Ｓ７２５）。ここでは、既に確保されている最新の与信枠に相当する金銭の支払を請求する。
以上の処理が完了すると、仮想商店街管理サーバ１０は、受取承認手続が完了した旨の連絡メールを生成し、ユーザ端末３０Ｃに送信する（Ｓ３４５ｃ）。
【０１１８】
（４−３（ｄ）．受取拒否の場合）
受信した応答が拒否要求であるとき（Ｓ７１０でＮｏ）、仮想商店街管理サーバ１０は、受取拒否手続を処理し（Ｓ７３０，図１９の確認ページ１９００も参照）、識別した注文情報（図７のＳ３１０ｃにおいてＵＲＬパラメータにより識別した注文情報）を更新する（Ｓ７４０）。
ここでは、受取ステータスを「非承認」に変更する。
【０１１９】
続いて、仮想商店街管理サーバ１０は、幹事又は賛同者がそれぞれ指定したクレジットカードの与信情報を管理している与信情報管理サーバ（ここでは、いずれも与信情報管理サーバ５０）に対し、与信枠の返還を行なう（Ｓ７４５）。ここでは、識別した注文情報に関し既に確保されているすべての与信枠を返還する。
以上の処理が完了すると、仮想商店街管理サーバ１０は、受取拒否手続が完了した旨の連絡メールを生成し、ユーザ端末３０Ｃに送信する（Ｓ７５０）。
【０１２０】
（４−３（ｅ）．案内メールの送信の変形例）
上述では、募集期限が経過したときに、受取人に対して案内メールを送信している（図６のＳ６２０ａ〜Ｓ３０５ｃ参照）。
これに対し、募集人数を定めず、かつ募集期限が経過しない場合であっても、幹事（注文者）により指定されたすべての賛同者候補の賛同手続が完了したときに、受取人に対して案内メールを送信してもよい。この場合、図８のフローチャートに示す処理により受取人に対して案内メールを送信するとよい。
【０１２１】
この場合にも、所定期間ごと（例えば、２４時間ごと）に起動するバッチ処理により、案内メールを送信する対象の注文情報を特定するとよい。
これにより、共同ギフトの受取案内メールを、募集期限経過前の早い時期に受取人のユーザ端末３０Ｃに送信することが可能になる。
【０１２２】
図８に示すように、仮想商店街管理サーバ１０は、注文情報データベース１４に記憶されている注文情報のうち、注文ステータスが「募集期限経過待ち」であるものを検索し、読出す（Ｓ６０５）。
続いて、読出した処理対象の注文情報の件数を変数ｋに入力する（Ｓ６１０）。また、変数ｉに１を代入する。
【０１２３】
続いて、仮想商店街管理サーバ１０は、次の処理を繰り返す。
（１）ｉ番目に読み出した注文情報につき「手続完了済の賛同者候補数」が「募集人数」に等しいか否かを判定する（Ｓ６２０ｂ）。「手続完了済の賛同者候補数」が「募集人数」に等しいとき（Ｓ６２０ｂでＹｅｓ）、下記（２）に進む。一方、「手続完了済の賛同者候補数」が「募集人数」に等しくないとき（Ｓ６２０ｂでＮｏ）、下記（４）に進む。
（２）ｉ番目に読み出した注文情報を更新する（Ｓ６２５）。ここでは、注文ステータスを「受取手続待ち」に変更する。
（３）共同ギフトの案内メールを生成し、受取人のメールアドレス宛に送信する（Ｓ３０５ｃ）。
（４）ｉにｉ＋１を代入する（Ｓ６３０）。
（５）「ｉ＞ｋ」の真偽を判定する（Ｓ６３５）。真のとき（Ｓ６３５でＹｅｓ）、ループを抜けて終了する。一方、偽のとき（Ｓ６３５でＮｏ）、上記（１）に戻る。
【０１２４】
なお、すべての賛同者候補の賛同手続が完了したか否かを判定する処理（図８のＳ６２０ｂ）を、各賛同者候補による賛同（承認又は拒否）の手続が完了するごとに行ってもよい。
このようにすれば、共同ギフトの受取案内メールを、募集期限経過前のより早い時期に受取人のユーザ端末３０Ｃに送信することが可能になる。
【０１２５】
この場合には、例えば、仮想商店街管理サーバ１０は、注文情報の更新により賛同手続完了済の賛同者候補数に１を加算する処理（図５−２のＳ５７５）の直後に、次の処理を行なう。
（１）その賛同手続に係る注文情報につき「手続完了済の賛同者候補数」が「募集人数」に等しいか否かを判定する（図８のＳ６２０ｂと同様）。「手続完了済の賛同者候補数」が「募集人数」に等しいとき、下記（２）に進む。一方、「手続完了済の賛同者候補数」が「募集人数」に等しくないとき、処理を終了する。
（２）その注文情報を更新する（図８のＳ６２５と同様）。ここでは、注文ステータスを「受取手続待ち」に変更する。
（３）共同ギフトの案内メールを生成し、受取人のメールアドレス宛に送信する（図８のＳ３０５ｃと同様）。
【０１２６】
＜他の実施形態の説明＞
（１．与信枠の減額の変形例）
（１−１．募集期限の経過を契機とする与信枠（差額）の返還）
上述の実施形態においては、賛同者が新たに確定されるごとに、幹事（注文者）及び確定している賛同者の既に確保されている与信枠を、（代金総額）／（与信枠確保済の賛同者数＋１）により得られる額に減額するよう与信情報管理サーバ５０に要求している（図５−２のＳ５６５，Ｓ５７０）。
これに対し、募集期限が経過したときに幹事（注文者）及び確定している賛同者の負担額を確定し、既に確保している与信枠との差額分（負担額の減額により与信枠を確保する必要がなくなった金額分）を返還するようにしてもよい。なお、募集期限が経過したか否かは、図６のフローチャートに示した処理により判定することができる。
これにより、注文が確定するまで待つ場合と比較して、早期に与信枠を返還することができる。
【０１２７】
（１−２．指定された募集人数の到達を契機とする与信枠（差額）の返還）
上述の実施形態においては、賛同者が新たに確定されるごとに、幹事（注文者）及び確定している賛同者の既に確保されている与信枠を、（代金総額）／（与信枠確保済の賛同者数＋１）により得られる額に減額するよう与信情報管理サーバ５０に要求している（図５−２のＳ５６５，Ｓ５７０）。
これに対し、幹事（注文者）に募集人数を指定させた上で、賛同者が募集人数に達したときに幹事（注文者）及び確定している賛同者の負担額を確定し、既に確保している与信枠との差額分（負担額の減額により与信枠を確保する必要がなくなった金額分）を返還するようにしてもよい。
これにより、注文が確定するまで待つ場合と比較して、早期に与信枠を返還することができる。
【０１２８】
（１−３．すべての賛同者候補の賛同手続完了を契機とする与信枠（差額）の返還）
上述の実施形態においては、賛同者が新たに確定されるごとに、幹事（注文者）及び確定している賛同者の既に確保されている与信枠を、（代金総額）／（与信枠確保済の賛同者数＋１）により得られる額に減額するよう与信情報管理サーバ５０に要求している（図５−２のＳ５６５，Ｓ５７０）。
これに対し、募集人数を定めず、幹事（注文者）により指定されたすべての賛同者候補が賛同手続（承認又は許否）を完了させたときに幹事（注文者）及び確定している賛同者の負担額を確定し、既に確保している与信枠との差額分（負担額の減額により与信枠を確保する必要がなくなった金額分）を返還するようにしてもよい。なお、幹事（注文者）により指定されたすべての賛同者候補が賛同手続（承認又は許否）を完了させたか否かは、図８のフローチャートに示した処理により判定することができる。
これにより、注文が確定するまで待つ場合と比較して、より早い時期に与信枠を返還することができる。同時に、受取人に対して、早期にギフトの案内メールを送信することができる。
【０１２９】
（２．システム構成の変形例）
上述の実施形態においては、幹事及び各賛同者の決済方法はクレジットカードによる信用取引であった。図１において、仮想商店街管理サーバ１０は、クレジットカード会社の与信情報管理サーバ５０に接続している。
これに対し、仮想商店街管理サービスを利用した商品の購入等により獲得した金銭的価値を示すポイントを、共同ギフト支援サービスにおける決済方法として指定することができるようにしてもよい。この場合、仮想商店街管理サーバ１０は、図１の与信情報管理サーバ５０に代えて、金銭的価値を示すポイントの情報を管理するポイント管理サーバに接続するとよい。
【０１３０】
（２−１．ポイント管理サーバの機能）
図１に示す構成において、与信情報管理サーバ５０に代えて仮想商店街管理サーバ１０に接続されるポイント管理サーバは、各会員が保有するポイントを管理するサーバである。
ポイント管理サーバは、専用線２１を介して仮想商店街管理サーバ１０と接続しており、決済処理に関して仮想商店街管理サーバ１０と連携する。
【０１３１】
（２−２．仮想商店街管理サーバ１０による決済に関する処理）
ポイント管理サーバと接続している構成の場合、仮想商店街管理サーバ１０は、与信情報管理サーバ５０に対する事前承認要求に代えて、ポイント管理サーバに対し、ユーザの利用可能ポイント内の一部を利用枠として確保するよう要求する。
利用枠の確保要求を受けたポイント管理サーバは、利用予約が可能であるとき、利用可能枠内の一部のポイントを利用枠として確保し、他の取引への利用を一時的に制限する。
【０１３２】
（２−３．効果）
図１に示す構成において、与信情報管理サーバ５０に代えてポイント管理サーバを仮想商店街管理サーバ１０に接続し、仮想商店街管理サーバ１０は、与信情報管理サーバ５０に対する与信枠の確保要求に代えて、ポイント管理サーバに対してポイント利用枠の確保を要求してもよい。
これにより、上述の共同ギフト支援サービスの決済方法として、ポイントの利用を選択させることが可能になる。
【０１３３】
なお、図１に示す構成において、与信情報管理サーバ５０とともにポイント管理サーバを仮想商店街管理サーバ１０に接続し、仮想商店街管理サーバ１０は、ユーザの選択に応じて与信情報管理サーバ５０に対する与信枠の確保要求又はポイント管理サーバに対するポイント利用枠の確保要求を行ってもよい。
これにより、上述の共同ギフト支援サービスの決済方法としてクレジットカードの利用又はポイントの利用のいずれか一方を選択させることが可能になる。
【０１３４】
（３．受取拒否の応答の変形例）
上述の実施形態において、受取人は、受取拒否の応答をＷｅｂページを介して送信している（図７のＳ７０５，図１７参照）。しかし、受取を拒否する場合、受取人は受取の手続において配送先の住所等を入力する必要がない。
したがって、例えば、受取の許否の応答を、受取人のユーザ端末３０Ｃが受信したギフトの案内メールに対する返信メールにより送信するにようすることが可能である。
【０１３５】
（４．受取人の情報の入力）
上述の実施形態において、幹事（注文者）は、受取人の情報として受取人の氏名とメールアドレスのみを指定している。また、商品の配送先の情報は、受取人が受取を承認する場合に入力している。
これに対し、商品の配送先の情報は、幹事（注文者）が入力するようにしてもよい。この場合、受取人は受取の手続において配送先の住所等を入力する必要がない。したがって、例えば、受取の承認又は許否の応答を、受取人のユーザ端末３０Ｃが受信したギフトの案内メールに対する返信メールにより送信するようにすることが可能になる。
【０１３６】
（５．与信業者の指定）
上述の実施形態において、幹事及び賛同者は、代金の決済方法として同一の与信業者（クレジットカード会社）が発行するクレジットカードの利用を指定している。
これに対し、幹事及び賛同者は、代金の決済方法として各別の与信業者（クレジットカード会社）が発行するクレジットカードの利用を指定してもよい。
【図面の簡単な説明】
【０１３７】
【図１】システムの構成例を示す図である。
【図２】（ａ）会員情報，（ｂ）加盟店情報，（ｃ）商品情報，（ｄ）注文情報の主要な項目を示す図である。
【図３】（ａ）注文手続，（ｂ）賛同承認手続，（ｃ）受取承認手続の手順を示すシーケンス図である。
【図４】注文手続段階におけるサーバによる決済処理の流れを示すフローチャートである。
【図５−１】賛同手続段階におけるサーバによる決済処理の流れを示すフローチャートの一部である。
【図５−２】賛同手続段階におけるサーバによる決済処理の流れを示すフローチャートの一部である。
【図６】ギフトの案内メールを送信する処理の流れを示すフローチャートである。
【図７】受取手続段階におけるサーバによる決済処理の流れを示すフローチャートである。
【図８】ギフトの案内メールを送信する処理の流れを示すフローチャートである。
【図９】募集期限及びキーワードを取得するためのページの例である。
【図１０】賛同者候補の情報及び賛同メッセージを取得するためのページの例である。
【図１１】注文手続の内容を確認させるためのページの例である。
【図１２】賛同者候補を認証するためのページの例である。
【図１３】応答（賛同承認又は賛同拒否）を取得するためのページの例である。
【図１４】賛同者候補の決済情報を取得するためのページの例である。
【図１５】賛同承認手続の内容を確認させるためのページの例である。
【図１６】賛同拒否手続の内容を確認させるためのページの例である。
【図１７】応答（受取承認又は受取拒否）を取得するためのページの例である。
【図１８】受取承認手続の内容を確認させるためのページの例である。
【図１９】受取拒否手続の内容を確認させるためのページの例である。
【符号の説明】
【０１３８】
１０      仮想商店街管理サーバ
１１      会員情報データベース
１２      加盟店情報データベース
１３      商品情報データベース
１４      注文情報データベース
２０      電気通信回線網
２１      専用線
３０Ａ    ユーザ端末
３０Ｂ    ユーザ端末
３０Ｃ    ユーザ端末
４０      店舗端末
５０      与信情報管理サーバ
【図１】
0005234918.tif 000002
【図２】
0005234918.tif 000003
【図３】
0005234918.tif 000004
【図４】
0005234918.tif 000005
【図５−１】
0005234918.tif 000006
【図５−２】
0005234918.tif 000007
【図６】
0005234918.tif 000008
【図７】
0005234918.tif 000009
【図８】
0005234918.tif 000010
【図９】
0005234918.tif 000011
【図１０】
0005234918.tif 000012
【図１１】
0005234918.tif 000013
【図１２】
0005234918.tif 000014
【図１３】
0005234918.tif 000015
【図１４】
0005234918.tif 000016
【図１５】
0005234918.tif 000017
【図１６】
0005234918.tif 000018
【図１７】
0005234918.tif 000019
【図１８】
0005234918.tif 000020
【図１９】
0005234918.tif 000021