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

Description

本発明は、ネットワークを介して商品を販売する事業者の売買取引業務を支援するシステムに関し、特に、決済情報の管理に関するものである。

ネットワークを介して商品等を売買する場合、売買取引を支援するシステムである仮想商店街を利用することが多い。
仮想商店街を利用する取引においては、銀行等の金融機関を介した決済方法（例えば、振込等）が利用されることが多いが、仮想商店街を管理運用するシステムと金融機関のシステムとは連携していなかった。

＜従来例＞
従来のシステムにおける注文の受付から取引の完了までの処理の流れを、図１〜図２−２を用いて説明する。
ここでは、決済方法として銀行振込が選択される場合を説明する。

（１）従来のシステムの構成
従来のシステムの構成を、図１に例示する。
図１に示すように、従来のシステムは、仮想商店街を総合的に管理する仮想商店街管理サーバ１０，並びに仮想商店街管理サーバ１０とインターネット等のネットワーク２０を介して接続している仮想商店街の会員の端末３０，仮想商店街の加盟店の端末４０及び銀行システムのサーバ５０により構成される。
会員端末３０及び加盟店端末４０は、ブラウザを有しており、ネットワーク２０を介して、仮想商店街管理サーバ１０が提供するＷｅｂサービス（例えば、注文等の管理サービス等）及び銀行サーバ５０が提供するＷｅｂサービス（例えば、インターネットバンキング等）を受けることができる。

（２）従来のシステムによる処理の流れ
従来のシステムによる注文の受付から代金の決済までの処理の流れを、図２−１及び図２−２のシーケンス図を用いて説明する。
なお、図２−１と図２−２は、注文の受付処理（図２−１）と代金の決済処理（図２−２）にそれぞれ対応しており、連続しているものとする。

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

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

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

（ｂ）代金の決済処理
図２−２に進み、注文の内容を確認すると、加盟店（担当者）は、加盟店端末４０を用いて請求金額等（その他、振込先口座番号，振込先口座名義，振込期限，等）を記載した電子メールを会員端末３０に送信し、会員に代金の支払を請求する（Ｓ２５０）。
加盟店から代金の支払請求を受けると、会員は、銀行に加盟店の口座に対する代金の振込を依頼する（Ｓ２５５）。振込の依頼は、銀行サーバ５０が提供するＷｅｂサービス（インターネットバンキング）を利用することにより、会員端末３０から行なうことができる。
なお、振込の際、「振込依頼人」の欄等に、依頼人の氏名とともに注文番号を入力すれば、振り込んだ代金を注文に対応させることができる。
代金の振込依頼を受けると、銀行サーバ５０は、所定の代金振込処理を行なう（Ｓ２６０）。

一方、加盟店（担当者）は、会員に代金の支払を請求した後、頃合を見はからって、自己の銀行口座への入金の有無を確認する（Ｓ２６５）。入金の有無は、銀行サーバ５０が提供するＷｅｂサービス（インターネットバンキング）を利用することにより、加盟店端末４０上で確認することができる。
入金が確認できたとき、加盟店（担当者）は、該当する注文について所定の消込処理を行なう（Ｓ２７０）。この場合、加盟店（担当者）は、銀行サーバ５０が提供するＷｅｂサービス上の入金明細確認ページの表示内容と、仮想商店街管理サーバ１０が提供するＷｅｂサービス上の注文情報の確認ページの注文情報（例えば、会員（購入者）の氏名，請求金額等）との突合せ作業を、入金が確認された注文ごとに個別に行なう。
所定の消込処理が終了すると、加盟店は、注文に係る商品をその注文をした会員（購入者）に所定の方法（例えば、宅配，郵便小包等）で発送する。

（３）従来のシステムによる決済処理の問題点
以上のように、仮想商店街を利用する取引においては、銀行等の金融機関を介した決済方法（例えば、振込等）が利用されることが多い。
しかしながら、金融機関のサーバは仮想商店街管理サーバと連携していない。また、金融機関のＷｅｂサービスを利用した振込は会員が会員端末を操作することにより行なわれるため、振込の際に注文番号を確実に入力してもらうのは困難である。
こうした事情により、決済に関する情報（決済情報）は、注文に関する情報（注文情報）に対応づけられていない。そのため、加盟店は、注文情報と決済情報とを各別に管理せざるを得ない。これでは、決済情報の管理作業そのものに手間がかかる上に、作業ミスに起因するトラブルの発生も懸念される。

本発明は、仮想商店街における会員と加盟店との間の取引を支援するシステムにおいて、加盟店に対して決済に関する情報を注文に関する情報とともに一括して管理する仕組みを提供することを課題とする。

上記課題を解決するため、本発明は、仮想商店街の加盟店と会員との間の電気通信回線網を利用した取引を支援する仮想商店街管理システムにおける、前記会員が口座を有する金融機関のシステムと連携して行なう口座振替による決済処理であって、前記仮想商店街管理システムは、前記金融機関のシステムと電気通信回線を介して接続されているとともに、前記会員から受け付けた前記加盟店に対する注文の情報を、一意な注文番号を付与して記憶している注文情報記憶手段を有し、前記金融機関に口座を有する前記会員からの、決済を前記金融機関からの口座振替とする注文情報を前記注文情報記憶手段より読み出して一覧ページを生成し、前記加盟店の端末に送信する注文情報一覧ページ送信手段と、前記送信された注文情報についての決済処理の依頼情報を、前記加盟店の端末から受信する決済処理依頼情報受信手段と、前記決済処理の依頼があった注文に係る注文情報を前記注文情報記憶手段より読み出し、該読み出した注文情報の注文番号に対応する識別子を含む口座振替処理の依頼情報を生成して、前記金融機関のシステムに送信する口座振替処理依頼情報送信手段と、前記金融機関のシステムから、前記識別子を含む、前記口座振替処理の依頼情報に対応する口座振替処理の情報を受信する口座振替処理情報受信手段と、前記口座振替処理情報受信手段が口座振替処理情報を受信したとき、該受信した口座振替処理情報に含まれる識別子に対応する注文番号が付与されている注文情報を前記注文情報記憶手段より読み出し、該読み出した注文情報の決済に関する項目の情報を該受信した口座振替処理情報をもとに更新する注文情報更新手段と、前記加盟店の端末から注文情報についての入金の確認要求を受信する入金確認要求受信手段と、前記入金確認要求受信手段が入金確認要求を受信したとき、該入金確認要求があった注文情報を前記注文情報記憶手段より読み出し、該読み出した注文情報に係る入金情報を注文番号に対応させた入金情報確認ページを生成して、前記加盟店の端末に送信する入金情報確認ページ送信手段とを備えることを特徴とする。

上記仮想商店街管理システムにおいて、前記注文番号に対応する識別子は、注文情報に付与されている注文番号であってもよい。
上記仮想商店街管理システムにおいて、さらに、前記加盟店の端末から、前記金融機関に口座を有する会員の注文情報についての決済処理の進捗確認要求を受信する進捗確認要求受信手段と、前記進捗確認要求を受信したとき、該進捗確認要求があった注文情報を前記注文情報記憶手段より読み出し、該読み出した注文情報に係る決済処理の進捗情報を注文番号に対応させた進捗情報確認ページを生成して、前記加盟店の端末に送信する進捗情報確認ページ送信手段とを備え、前記口座振替処理情報受信手段が受信する口座振替処理情報は、引落情報と払込情報とからなり、前記注文情報更新手段は、注文情報の決済に関する項目の情報を、前記決済処理依頼情報受信手段が決済処理の依頼情報を受信したときに「残高確認待ち」に更新し、前記口座振替処理情報受信手段が引落情報を受信したときに「払込準備中」又は「引落不能」に更新し、前記口座振替処理情報受信手段が払込情報を受信したときに「完了」又は「払込不能」に更新し、前記進捗情報確認ページ送信手段は、前記決済に関する項目の情報を含む確認ページを生成して、送信することとしてもよい。このとき、前記入金情報確認ページ送信手段は、前記読み出した注文情報の決済に関する項目の情報が前記引落情報により「払込準備中」に更新されているときは、入金があったものとして入金情報確認ページを生成し、送信することとしてもよい。

また、上記課題を解決するため、本発明は、仮想商店街の加盟店と会員との間の電気通信回線網を利用した取引を支援する仮想商店街管理システムにおける、前記会員が口座を有する金融機関のシステムと連携して行なう口座振替による決済方法であって、前記仮想商店街管理システムは、前記金融機関のシステムと電気通信回線を介して接続されているとともに、前記会員から受け付けた前記加盟店に対する注文の情報を、一意な注文番号を付与して記憶している注文情報記憶手段を有し、前記金融機関に口座を有する前記会員からの、決済を前記金融機関からの口座振替とする注文情報を前記注文情報記憶手段より読み出して一覧ページを生成し、前記加盟店の端末に送信する注文情報一覧ページ送信ステップと、前記送信された注文情報についての決済処理の依頼情報を、前記加盟店の端末から受信する決済処理依頼情報受信ステップと、前記決済処理の依頼があった注文に係る注文情報を前記注文情報記憶手段より読み出し、該読み出した注文情報の注文番号に対応する識別子を含む口座振替処理の依頼情報を生成して、前記金融機関のシステムに送信する口座振替処理依頼情報送信ステップと、前記金融機関のシステムから、前記識別子を含む、前記口座振替処理の依頼情報に対応する口座振替処理の情報を受信する口座振替処理情報受信ステップと、前記口座振替処理情報受信ステップで口座振替処理情報を受信したとき、該受信した口座振替処理情報に含まれる識別子に対応する注文番号が付与されている注文情報を前記注文情報記憶手段より読み出し、該読み出した注文情報の決済に関する項目の情報を該受信した口座振替処理情報をもとに更新する注文情報更新ステップと、前記加盟店の端末から注文情報についての入金の確認要求を受信する入金確認要求受信ステップと、前記入金確認要求受信ステップで入金確認要求を受信したとき、該入金確認要求があった注文情報を前記注文情報記憶手段より読み出し、該読み出した注文情報に係る入金情報を注文番号に対応させた入金情報確認ページを生成して、前記加盟店の端末に送信する入金情報確認ページ送信ステップと
を備えることを特徴とする。
上記仮想商店街管理システムの各手段をコンピュータに機能として実現させるためのプログラムも本発明である。

本発明の仮想商店街管理システムは、注文情報に一意に付与されている注文番号に１対１で対応する識別子を利用することにより、決済に関するデータを銀行等の金融機関のシステムと連携して処理している。そのため、決済に関する情報を、注文に関する情報とともに画面上に提示することができる。
その効果として、加盟店は、決済に関する情報を注文に関する情報とともに一括して管理することができる。これにより、決済情報の管理作業そのものの手間が軽減されるとともに、作業ミスに起因するトラブルの発生を予防することも可能になる。
また、本発明の仮想商店街管理システムでは、決済の方法として口座振替を選択可能としている。これにより、会員は、予め代金引落用の口座を登録しておけば、口座振替による決済を選択することにより、振込等の手続を取引の都度行なう必要がなくなる。

以降、本発明の実施形態の一例を、図３〜図１０を参照して説明する。
本実施形態のシステムは、決済に関するデータを銀行システムと連携して処理することにより、決済（口座振替）に関する情報を注文に関する情報と対応させて確認ページ上で提供するシステムである。銀行システムに送信する口座振替処理を依頼する旨の情報及び銀行システムから受信する口座振替処理が終了した旨の情報を注文番号に対応させることにより、この仕組みを実現している。
前提として、本実施形態のシステムが提供する仮想商店街サービスは、利用登録をしているユーザ（会員）と出店登録をしている店舗（加盟店）との間で行なわれる、インターネット等の電気通信回線網を利用した取引を対象としている。また、本実施形態においては、会員（購入者）の銀行口座から代金を引き落とし、加盟店（販売者）の銀行口座に代金を払い込む決済方法を「口座振替」という。
なお、会員及び加盟店は、それぞれ本実施形態のシステムが指定する銀行の口座を登録しており、決済方法の選択処理（図２のＳ２１５）において口座振替が選択されるものとする。口座振替は、会員及び加盟店のいずれもが銀行口座の口座番号を登録している場合に限り、決済方法の選択ページに表示されるものとする。

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

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

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

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

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

図４（ｂ）に、加盟店情報データベース１２の主要な項目を示す。
図４（ｂ）において、「加盟店ＩＤ」は、出店登録をしている店舗に一意の識別情報である。本実施形態では、加盟店ＩＤとしてその加盟店のドメイン名を使用している。「認証キー」は、その加盟店の認証に用いるキーである。「メールアドレス」は、その加盟店が用いる加盟店端末４０（後述）のメールアドレスである。
同じく図４（ｂ）において、「口座番号」は、その加盟店の代金払込先口座の番号である。「手数料負担者区分」は、その加盟店が受け付けたすべての注文に関する口座振替手数料の負担者の区分（例えば、「加盟店負担」，「会員負担」等）であり、各加盟店が事前に設定することができる。「担当者ＩＤ」は、その加盟店における受注管理業務の担当者の識別情報であり、少なくとも１つ登録されている。「店舗情報」は、その加盟店の店舗の情報（例えば、名称，店舗の詳細を掲載したウェブページのＵＲＬ等）である。
なお、加盟店の認証（ログイン）には、加盟店情報の項目のうち「加盟店ＩＤ」，「担当者ＩＤ」及び「認証キー」を用いる。

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

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

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

図４（ｄ）に、注文情報データベース１４の主要な項目を示す。
図４（ｄ）において、「注文番号」は、本実施形態のシステムが受け付けた注文に一意の識別情報である。「注文日時」は、その注文を受け付けた日時ある。「会員ＩＤ」は、その注文をした会員の識別情報であり、注文情報に会員情報を紐付けている。「加盟店ＩＤ」は、その注文を受けた加盟店の識別情報であり、注文情報に加盟店情報を紐付けている。

同じく、図４（ｄ）において、「商品コード」は、その注文に係る商品の識別情報であり、注文情報に商品情報を紐付けている。「数量」は、その注文に係る商品の注文数である。「請求金額」は、その注文に係る請求金額である。「決済方法」は、その注文の決済方法（例えば、口座振替，銀行振込，代金引換，クレジットカード等）である。なお、一の注文に複数の商品が含まれるときは、それぞれの商品に対応する「商品コード」及び「数量」の組を設けるものとする。
同じく、図４（ｄ）において、「受注処理ステータス」は、その注文の受注処理の進捗状況を示す区分（例えば、「新規受付」，「発送待ち」，「完了」，「取消」等）である。「決済処理ステータス」は、その注文の決済処理の進捗状況を示す区分（「未処理」，「振替依頼待ち」，「残高確認待ち」，「払込準備中」，「振替不能」，「完了」，「払込不能」等）である。「注文関連情報」は、その注文に関連する情報（例えば、注文内容の修正履歴等）である。
なお、本実施形態においては、「受注処理ステータス」の初期値を「新規受付」とし、「決済処理ステータス」の初期値を「未処理」とする。

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

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

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

（２．本実施形態のシステムによる処理）
本実施形態のシステムにおける銀行システムと連携して行なう決済処理の流れを、図５のシーケンス図及び図６〜図１０のページ例等を用いて説明する。
図２−２に示した従来のシステムによる処理との主要な相違点は、決済処理（口座振替処理）の明示的な依頼を加盟店から受け付けた上で、決済に関するデータを銀行サーバ５０と連携して処理し、その処理結果である決済情報を加盟店端末に提供する点である（Ｓ５１５〜Ｓ５６０）。
なお、図５のシーケンス図は、加盟店に注文を受け付けた旨の確認メールを送信（図２−１のＳ２４０）した後の処理を示している。

（２−１．口座振替依頼の受付・注文の確定）
図５に示すように、受注確認通知を受けた加盟店（担当者）は、加盟店端末４０を用いて仮想商店街管理サーバ１０にログインし、注文内容の確認ページを要求する。加盟店端末４０から確認ページの要求があると、仮想商店街管理サーバ１０は注文内容の確認ページを加盟店端末４０に送信し、加盟店に注文内容の確認を求める（Ｓ５０５）。加盟店（担当者）は、確認ページで所定の確認処理を行なう。
確認処理を受け付けると、仮想商店街管理サーバ１０は、注文情報の「決済処理ステータス」を更新する（Ｓ５１０）。ここでは、「決済処理ステータス」を初期値の「未処理」から「振替依頼待ち」に変更する。

加盟店（担当者）は、確認ページで注文内容を確認した後、加盟店端末４０から仮想商店街管理サーバ１０に口座振替の依頼ページを要求する。加盟店端末４０から口座振替依頼ページの要求があると、仮想商店街管理サーバ１０は加盟店端末４０に口座振替依頼ページを送信し、加盟店から口座振替の依頼を受け付ける（Ｓ５１５）。加盟店（担当者）は、この口座振替の依頼ページから口座振替を依頼する。
口座振替の依頼を受け付けると、仮想商店街管理サーバ１０は、会員から受け付けた注文の内容を確定し、注文情報の「決済処理ステータス」を更新する（Ｓ５２０）。ここでは、注文情報（図２のＳ２３０により生成した注文情報）の「決済処理ステータス」を「残高確認待ち」に変更する。

図６に、口座振替の一括依頼ページを例示する。口座振替の一括依頼ページ６００は、仮想商店街管理サーバ１０が提供するＷｅｂサービスにログインした直後に表示されるメインメニューのページにおいて決済に関する情報の一覧ページが選択されたときに、デフォルトのページとして加盟店端末４０に送信される口座振替の一括依頼ページである。
口座振替の一括依頼ページ６００は、絞込対象限定タブ６１１〜６１４，絞込条件指定欄６２０，注文情報表示欄６３０及びボタン６４０により構成される。

絞込対象限定タブ６１１〜６１４は、決済に関する情報を処理の目的別に絞り込むときに利用するタブである。例えば、「口座振替依頼」と表示されているタブ６１１がクリックされると、口座振替の依頼が可能になっている注文情報（決済処理ステータスが「振替依頼待ち」である注文情報）のみが表示されたページが送信される。
同様に、「振替ＮＧ確認」と表示されているタブ６１２は、何らかの理由で口座振替（ここでは、代金の引落し）に失敗した注文情報（決済処理ステータスが「引落不能」である注文情報）に、「振替依頼待ちへ戻す」と表示されているタブ６１４は、既に口座振替の依頼をしたが未だ引落しはされていない注文情報（決済処理ステータスが「残高確認待ち」である注文情報）に、それぞれ対応している。また、「ステータス別に確認する」と表示されているタブ６１３がクリックされると、決済処理ステータスがタブ６１１，タブ６１２，タブ６１４に対応しているもの以外の注文情報を絞り込むページが送信される。

絞込条件指定欄６２０には、期間指定欄６２１，注文番号指定欄６２２及び「絞り込み表示」と表示されているボタン６２３がある。
加盟店（担当者）が、期間指定欄６２１において、注文日又は発送日のラジオボタンをクリックし、期間の始期と終期を指定し、「絞り込み表示」ボタン６２３をクリックすると、注文日又は発送日が指定された期間内に含まれる注文情報が注文情報表示欄６３０に表示される。また、加盟店（担当者）が、注文番号指定欄６２２に特定の注文番号を入力し、「絞り込み表示」ボタン６２３をクリックすると、指定された注文番号の注文情報が注文情報表示欄６３０に表示される。

注文情報表示欄６３０には、注文情報のうち「注文日時」，「受注処理ステータス」，「注文番号」，「請求金額」等、及び「会員ＩＤ」により紐付けされた会員情報の「個人情報（氏名）」等が表示される。
加盟店（担当者）が「すべてチェック」と表示されている欄６３１ａ又は６３１ｂのチェックボックスの少なくとも１つにチェックを入れて「口座振替を依頼する」と表示されているボタン６４０をクリックすると、加盟店端末４０は、チェックされた注文情報に係る口座振替の依頼情報を仮想商店街管理サーバ１０に送信する。

図７に、口座振替の個別依頼ページを例示する。口座振替の個別依頼ページ７００は、口座振替の一括依頼ページ６００（図６）において、注文番号「１９９４１２-２００７０５２８−８２４３５７」の個別依頼ページへのリンク６３２がクリックされたときに仮想商店街管理サーバ１０から加盟店端末４０に送信される、口座振替の個別依頼ページである。
口座振替の個別依頼ページ７００は、注文情報表示欄７１０及びボタン７２０により構成される。注文情報表示欄７１０には、注文情報のうち「注文番号」，「決済処理ステータス」等が表示される。
加盟店（担当者）が「口座振替を依頼する」と表示されているボタン７２０をクリックすると、加盟店端末４０は、選択された注文情報（ここでは、注文番号「１９９４１２-２００７０５２８−８２４３５７」）に係る口座振替の依頼情報を仮想商店街管理サーバ１０に送信する。

（２−２．銀行サーバと連携した口座振替処理）
図５に戻り、注文情報を更新すると、仮想商店街管理サーバ１０は、引落情報及び払込情報を生成して銀行サーバ５０に送信し、銀行サーバ５０に口座振替処理を依頼する（Ｓ５２５）。
本実施形態において、仮想商店街管理サーバ１０は、引落情報及び払込情報を、定期的なバッチ処理（例えば、１日２回のバッチ処理）により銀行サーバ５０に送信している。なお、これは実施の一形態であり、他のタイミングで送信してもよい。
図８（ａ）に引落情報の主要な項目を、図８（ｂ）に払込情報の主要な項目を、それぞれ示す。

図８（ａ）において、「注文番号」は、引落依頼に係る注文に付与された注文番号であり、引落情報を注文情報に紐付けている。「口座振替依頼日時」は、その注文についての口座振替依頼処理（図５のＳ５２５）を行なった日時である。「引落金額」は、その注文をした会員の銀行口座から引き落とす代金の金額であり、注文情報の「請求金額」（図４（ｄ））に対応する。ただし、その注文を受け付けた加盟店の加盟店情報（図４（ｂ））において、「手数料負担者区分」が「会員負担」に設定されているときは、注文情報の「請求金額」に所定の手数料を加算した額を「引落金額」とする。
同じく図８（ａ）において、「引落元口座番号」は、その注文をした会員の銀行口座の番号であり、引落元の口座を特定している。「会員ＩＤ」は、その注文をした会員の識別情報であり、引落情報に会員情報を紐付けている。「引落処理日時」は、引落処理（図５のＳ５３０）を行なった日時であり、仮想商店街管理サーバ１０が銀行サーバ５０に送信する時点では空である。「引落完了フラグ」は、その注文をした会員の銀行口座から引落処理が成功したか否かを示すフラグである。

図８（ｂ）に、払込情報の主要な項目を示す。
図８（ｂ）において、「注文番号」は、払込依頼に係る注文に付与された注文番号であり、払込情報を注文情報に紐付けている。「口座振替依頼日時」は、その注文についての口座振替依頼処理（図５のＳ５２５）を行なった日時である。「払込金額」は、その注文を受け付けた加盟店の銀行口座に払い込む代金の金額であり、注文情報の「請求金額」（図４（ｄ））に対応する。ただし、その注文を受け付けた加盟店の加盟店情報（図４（ｂ））において、「手数料負担者区分」が「加盟店負担」に設定されているときは、注文情報の「請求金額」から所定の手数料を減算した額を「払込金額」とする。
同じく図８（ｂ）において、「払込先口座番号」は、その注文を受け付けた加盟店の銀行口座の番号であり、払込先の口座を特定している。「加盟店ＩＤ」は、その注文を受け付けた加盟店の識別情報であり、払込情報に加盟店情報を紐付けている。「払込処理日時」は、払込処理（図５のＳ５４５）を行なった日時であり、仮想商店街管理サーバ１０が銀行サーバ５０に送信する時点では空である。「払込完了フラグ」は、その注文を受け付けた加盟店の銀行口座への払込処理が成功したか否かを示すフラグである。

（２−３．銀行サーバと連携した引落処理）
図５に戻り、口座振替処理の依頼（Ｓ５２５）を受けると、銀行サーバ５０は、口座振替処理の依頼とともに受信した引落情報をもとに引落処理を行なう（Ｓ５３０）。ここでは、「引落元口座番号」に対応する銀行口座から「引落金額」に相当する代金を引き落とし、銀行サーバ５０が管理する所定の口座に一時的に蓄えておく。
本実施形態において、銀行サーバ５０は、仮想商店街管理サーバ１０から口座振替の依頼情報（引落情報及び払込情報）を受信するタイミングに合わせて、引落処理を行なっている。

会員の銀行口座から依頼された金額を引き落とすことができたとき、銀行サーバ５０は、引落情報の「引落処理日時」を入力するとともに、「引落完了フラグ」を立てる。一方、会員の銀行口座から依頼された金額を引き落とすことができなかったときは、引落情報の「引落処理日時」を入力するのみで、「引落完了フラグ」は立てない。
引落処理が完了すると、銀行サーバ５０は、更新した引落情報を仮想商店街管理サーバ１０に送信し、仮想商店街管理サーバ１０に引落処理が完了した旨を通知する（Ｓ５３５）。
更新された引落情報を受信すると、仮想商店街管理サーバ１０は、受信した引落情報に応じて注文情報の「決済処理ステータス」を更新する（Ｓ５４０）。引落情報の「引落完了フラグ」が立っているときは、「決済処理ステータス」を「払込準備中」に変更する。一方、引落情報の「引落処理済みフラグ」が立っていないときは、「決済処理ステータス」を「引落不能」に変更する。

（２−４．銀行サーバと連携した払込処理）
引落処理が成功すると、銀行サーバ５０は、口座振替処理の依頼（Ｓ５２５）とともに受信した払込情報をもとに払込処理を行なう（Ｓ５４５）。ここでは、所定の口座に一時的に蓄えてある「払込金額」に相当する代金を、「払込先口座番号」に対応する銀行口座に払い込む。
加盟店の銀行口座に依頼された金額を払い込むことができたとき、銀行サーバ５０は、払込情報の「払込処理日時」を入力するとともに、「払込完了フラグ」を立てる。一方、加盟店の銀行口座に依頼された金額を払込することができなかったときは、払込情報の「払込処理日時」を入力するのみで、「払込完了フラグ」は立てない。

本実施形態において、銀行サーバ５０は、定期的なバッチ処理により、払込処理を行なっている。このバッチ処理は、送金に要する手数料等の関係で、下記（ａ），（ｂ）のように、引落元の銀行口座と払込先の銀行口座とが同一銀行・同一支店の口座であるか否かにより、異なるタイミングで行なっている。
なお、これは実施の一形態であり、他のタイミングで払込処理を行なうことも可能であるから、適宜変更してもよい。
また、引落元の銀行口座と払込先の銀行口座とが同一銀行の口座であるか否かにより場合を分けて処理を行なってもよい。

（ａ）同一銀行・同一支店の口座でない場合
引落元の銀行口座と払込先の銀行口座とが同一銀行・同一支店の口座でない場合、銀行サーバ５０は、例えば、１月に１回のバッチ処理により、依頼のあった金額を払込先の銀行口座に送金する。
この場合、加盟店が代金を受け取ることができるのは、決済の依頼（図５のＳ５１５）を行なった日の含まれる月の翌月の最初の営業日以降になる。

（ｂ）同一銀行・同一支店の口座である場合
一方、引落元の銀行口座と払込先の銀行口座とが同一銀行・同一支店の口座である場合、銀行サーバ５０は、例えば、１日２回のバッチ処理により、引落処理の完了後直ちに、依頼のあった金額を払込先の銀行口座に入金する。
これにより、加盟店は、早ければ口座振替の依頼（図５のＳ５１５）を行なった当日中に、代金を受け取ることができる。
なお、この場合、引落元の銀行口座から代金を引き落とす処理と払込先の銀行口座に代金を払い込む処理とはほぼ同時に行なわれるので、「決済処理ステータス」が「払込準備中」である期間は極めて短い。そのため、銀行サーバ５０は、引落処理（図５のＳ５３０）の完了後、引落処理が完了した旨の通知（Ｓ５３５）を省略し、直ちに払込処理（Ｓ５４５）を行なう。このとき、仮想商店街管理サーバ１０も、「決済処理ステータス」を更新する処理（Ｓ５４０）を省略する。

払込処理が完了すると、銀行サーバ５０は、更新した払込情報を仮想商店街管理サーバ１０に送信し、仮想商店街管理サーバ１０に払込処理が完了した旨を通知する（Ｓ５５０）。
更新された払込情報を受信すると、仮想商店街管理サーバ１０は、受信した払込情報に応じて注文情報の「決済処理ステータス」を更新する（Ｓ５５５）。払込情報の「払込完了フラグ」が立っているときは、「決済処理ステータス」を「完了」に変更する。一方、引落情報の「引落完了フラグ」が立っていないときは、「決済処理ステータス」を「払込不能」に変更する。

（２−５．決済情報の提供）
以上の処理が完了すると、仮想商店街管理サーバ１０は、決済に関する情報（入金情報）を注文情報と併せてＷｅｂサービス上の確認ページで提供することが可能な状態になる。
なお、引落処理の完了後に注文情報の「決済処理ステータス」が「払込準備中」に更新されれば（Ｓ５４０）、口座振替による決済が完了したとみなすことができる状態になる。そこで、本実施形態では、会員の銀行口座から代金の引落が完了し「決済処理ステータス」が「払込準備中」に更新された注文情報については、加盟店の銀行口座に払込（入金）が見込まれる情報として、決済に関する情報（入金情報）を表示するページに表示することとしている。
加盟店（担当者）は、頃合を見はからって、加盟店端末４０を用いて仮想商店街管理サーバ１０にログインし、入金明細の確認ページを要求する。加盟店端末４０から入金明細の確認ページの要求を受けると、仮想商店街管理サーバ１０は、加盟店端末４０に入金明細の確認ページを送信し、加盟店（担当者）に決済に関する情報（入金）を確認させる（Ｓ５６０）。加盟店（担当者）は、受信した入金明細の確認ページを参照して、決済の成否等を確認する。

図９に、入金明細の確認ページを例示する。
入金明細の確認ページ９００は、絞込条件指定欄９１０，入金額表示欄９２０及び入金明細表示欄９３０により構成される。
絞込条件指定欄９１０には、期間指定欄９１１，注文番号指定欄９１２及び「検索」と表示されているボタン９１３がある。
加盟店（担当者）が、期間指定欄９１１において、口座振替日又は注文日をラジオボタンにより選択し、期間の始期と終期を指定し、「検索」ボタン９１３をクリックすると、口座振替日又は注文日が指定された期間内に含まれる注文情報に対応する入金明細が入金明細表示欄９３０に表示される。また、加盟店（担当者）が、注文番号指定欄９１２に特定の注文番号を入力し、「検索」ボタン９１３をクリックすると、指定された注文番号の注文情報に対応する入金明細があれば入金明細表示欄９３０に表示される。

入金額表示欄９２０には、注文情報表示欄９３０に表示される注文情報のうち、決済金額，手数料及び入金額について、それぞれ合計金額が表示される。なお、ここでの入金額には、入金予定額（引落処理完了後であって、払込処理完了前の代金）が含まれる。
注文情報表示欄９３０には、注文日，口座振替日，注文番号，決済金額，手数料及び入金額が、注文番号ごとに表示される。このうち、決済金額は、注文情報の「請求金額」に対応する金額である。また、入金額は、払込情報の「払込金額」に対応する金額である。
ここでは、すべての注文について手数料が「ユーザ負担」（加盟店情報の「手数料負担者区分」が「会員負担」に設定されている場合）であるから、決済金額と入金額は同額である。逆に、手数料が「店舗負担」（加盟店情報の「手数料負担者区分」が「加盟店負担」に設定されている場合）であれば、入金額は決済金額から所定の手数料を減算した額となる。
なお、注文情報表示欄９３０の注文番号は、その注文番号に対応する注文内容の詳細確認ページへのリンクになっている。これにより、加盟店（担当者）は、本実施形態のシステムを用いれば、入金明細の確認ページを参照して消込処理を行ないながら、必要に応じて注文内容の確認ページを参照することができる。

図１０に、注文内容の確認ページを例示する。注文内容の確認ページ１０００は、入金明細の確認ページ９００（図９）において注文情報表示欄９３０のリンク９３１がクリックされたときに加盟店端末４０に送信される、注文番号「１９９４１２−２００７０３２２−８１３１９７」の注文内容の確認ページである。
注文内容の確認ページ１０００は、注文情報のうち注文の内容に係る項目を表示する注文内容表示欄１０１０，注文情報のうち商品の発送に係る項目を表示する発送情報表示欄１０２０及び「入力内容を反映する」ボタン１０３０等により構成される。
注文内容表示欄１０１０には、注文番号「１９９４１２−２００７０３２２−８１３１９７」の注文情報、並びにこれに紐付けされた会員情報が表示される。発送情報表示欄１０２０には、商品の送付先，発送する商品，代金等が表示される。
また、注文内容表示欄１０１０又は発送情報表示欄１０２０の空欄に必要な情報を入力し、「入力内容を反映する」と表示されているボタン１０３０をクリックすると、注文情報の内容が更新される。

図５に戻り、決済が完了したことが確認できたとき、加盟店（担当者）は、該当の注文についてこの確認ページを参照して消込処理を行なう（Ｓ５６５）。以上の処理が完了すると、加盟店は、注文に係る商品をその注文をした会員（購入者）に所定の方法で発送する。

＜他の実施形態１＞
上述の実施形態において、仮想商店街管理サーバ１０は、口座振替の依頼に係る引落情報及び払込情報にその依頼に係る注文情報に付与された注文番号を付加して、銀行サーバ５０に送信することとしている。これに対し、銀行サーバ５０に送信する引落情報及び払込情報に、その依頼に係る注文情報に付与された注文番号に１対１で対応する識別子を付加することとしてもよい。
この実施形態によっても、決済情報を注文情報に対応付けることができる。また、銀行サーバ５０に注文番号そのものを送信する必要がなくなるので、銀行サーバ５０と連携した決済処理の安全性を高めることができる。

この場合、仮想商店街管理サーバ１０は、引落情報及び払込情報を銀行サーバ５０に送信するときに注文番号と識別子とを対応付けたテーブルを生成・記憶した上で、注文番号に対応付けられた識別子を引落情報及び払込情報に付加して送信する。また、銀行サーバ５０から引落情報又は払込情報を受信したときに記憶しているテーブルを参照し、引落情報又は払込情報に含まれる識別子に対応する注文番号が付与されている注文情報を特定する。
これらの処理により、引落情報及び払込情報に注文番号を付加する場合と同様の効果を得ることができる。なお、注文番号に１対１で対応する識別子としては、口座振替の依頼情報に一意に付与された識別番号や、所定の関数（例えば、ＭＤ５等のハッシュ関数）を用いて注文番号から算出した値（例えば、ハッシュ値）等が考えられる。

＜他の実施形態２＞
上述の実施形態において、仮想商店街管理サーバ１０は、口座振替による決済処理（引落処理）が完了したときに、決済に関する情報（入金情報）をＷｅｂサービス上の確認ページ上に表示させることとしている。これに対し、注文の受付から取引の完了までのすべてのタイミングにおいて、決済に関する情報（進捗情報）をＷｅｂサービス上の注文内容の一覧ページ，注文内容の個別確認ページ，注文内容の修正ページ，決済処理の依頼ページ等に表示させることとしてもよい。
これにより、「頃合を見はからって」入金確認をしていた加盟店（担当者）は、注文の受付から取引の完了後のすべてのタイミングにおいて、決済に関する情報を閲覧したときに決済処理の進捗状況を確認することができるようになる。

上述の実施形態では、注文情報に決済処理ステータスが含まれている。したがって、決済に関する情報（進捗情報）を確認ページ等に表示させる場合には、この決済処理ステータスの内容を利用することができる。なお、必要に応じて、表示される文言を変更してもよい。
例えば、加盟店端末４０から決済の依頼を受け付けた後、銀行サーバ５０から口座振替に係る引落処理が完了した旨の通知を受ける前の段階（図５のＳ５２０〜Ｓ５４０の段階）にあるとき、仮想商店街管理サーバ１０は、例えば、図１１に例示する決済処理の個別依頼ページ１１００（ここでは、「振替依頼待ち」に戻すという処理を依頼するページ）に決済処理の進捗状況を提示する。
決済処理の個別依頼ページ１１００を参照すれば、注文番号「１９９４１２-２００７０５２８−８２４３５７」の注文情報に係る決済処理ステータスは「残高確認待ち」であることが分かる。

従来のシステムの構成例を示す図である。 従来のシステムによる注文の受付処理の流れを示すシーケンス図である。 従来のシステムによる代金の決済処理の流れを示すシーケンス図である。 実施形態のシステムの構成例を示す図である。 （ａ）会員情報，（ｂ）加盟店情報，（ｃ）商品情報，（ｄ）注文情報の主要な項目を示す図である。 実施形態のシステムにおける銀行システムと連携して行なう決済処理の流れを説明するためのシーケンス図である。 口座振替の一括依頼ページの例を示す図である。 口座振替の個別依頼ページの例を示す図である。 （ａ）引落情報，（ｂ）払込情報の主要な項目を示す図である。 入金明細の確認ページの例を示す図である。 注文内容の確認ページの例を示す図である。 決済処理の個別依頼ページの例を示す図である。

符号の説明

１０ 仮想商店街管理サーバ
１１ 会員情報データベース
１２ 加盟店情報データベース
１３ 商品情報データベース
１４ 注文情報データベース
２０ ネットワーク
２１ 専用線
３０ 会員端末
４０ 加盟店端末
５０ 銀行サーバ
６００ 口座振替の一括依頼ページ
７００ 口座振替の個別依頼ページ
９００ 入金明細の確認ページ
１０００ 注文内容の確認ページ
１１００ 決済処理の個別依頼ページ

Claims (6)

1. 仮想商店街の加盟店と会員との間の取引を支援する仮想商店街管理システムであって、
   前記会員から受け付けた前記加盟店に対する注文の情報を、一意な注文番号に紐付けて記憶している注文情報記憶手段から取得した情報に基づき、注文番号に紐付けられた注文を選択可能に表示するための依頼ページであって、選択された注文に紐付けられた注文番号に対応する識別子を含む決済依頼の送信を前記加盟店の端末にさせるための依頼ページを生成し、前記加盟店の端末に前記依頼ページを送信する依頼ページ送信手段と、
   前記依頼ページを利用して前記加盟店の端末から送信された決済依頼を受信した場合に、前記決済依頼に含まれる識別子に対応する注文番号を特定し、該注文番号に対応する識別子を含む口座振替依頼を銀行サーバに送信する振替依頼送信手段と、
   前記銀行サーバから前記口座振替依頼に対応する口座振替処理情報を受信した場合に、前記口座振替処理情報に含まれる識別子に対応する注文番号を特定し、前記注文情報記憶手段における該注文番号に紐付けられた注文の決済の状況を示す決済処理ステータスを前記口座振替処理情報に応じて更新する注文情報更新手段と、
   前記決済処理ステータスを前記加盟店に送信する決済処理ステータス送信手段と、
   を備える仮想商店街管理システム。
2. 前記決済依頼に含まれる識別子及び前記注文番号に対応する識別子は、注文情報に付与されている注文番号である、
   請求項１に記載の仮想商店街管理システム。
3. 前記加盟店の端末から、前記注文情報についての決済処理の進捗確認要求を受信する進捗確認要求受信手段をさらに備え、
   前記決済処理ステータス送信手段は、前記進捗確認要求を受信したとき、該進捗確認要求に対応する注文情報を前記注文情報記憶手段より読み出し、該読み出した注文情報に係る決済処理ステータスを注文番号に対応させた進捗情報確認ページを生成して、前記加盟店の端末に送信し、
   前記口座振替処理情報は、引落情報と払込情報とからなり、
   前記注文情報更新手段は、注文情報の前記決済処理ステータスを、前記決済依頼を受信したときに「残高確認待ち」に更新し、前記引落情報を受信したときに「払込準備中」又は「引落不能」に更新し、前記払込情報を受信したときに「完了」又は「払込不能」に更新する、
   請求項１又は２に記載の仮想商店街管理システム。
4. 前記決済処理ステータス送信手段は、前記読み出した注文情報の決済処理ステータスが前記引落情報により「払込準備中」に更新されているときは、入金があったものとして入金情報確認ページを生成し、送信する、
   請求項３に記載の仮想商店街管理システム。
5. 仮想商店街の加盟店と会員との間の取引を支援する仮想商店街管理システムにおける決済方法であって、
   前記会員から受け付けた前記加盟店に対する注文の情報を、一意な注文番号に紐付けて記憶している注文情報記憶手段から取得した情報に基づき、注文番号に紐付けられた注文を選択可能に表示するための依頼ページであって、選択された注文に紐付けられた注文番号に対応する識別子を含む決済依頼の送信を前記加盟店の端末にさせるための依頼ページを生成し、前記加盟店の端末に前記依頼ページを送信する依頼ページ送信ステップと、
   前記依頼ページを利用して前記加盟店の端末から送信された決済依頼を受信した場合に、前記決済依頼に含まれる識別子に対応する注文番号を特定し、該注文番号に対応する識別子を含む口座振替依頼を銀行サーバに送信する振替依頼送信ステップと、
   前記銀行サーバから前記口座振替依頼に対応する口座振替処理情報を受信した場合に、前記口座振替処理情報に含まれる識別子に対応する注文番号を特定し、前記注文情報記憶手段における該注文番号に紐付けられた注文の決済の状況を示す決済処理ステータスを前記口座振替処理情報に応じて更新する注文情報更新ステップと、
   前記決済処理ステータスを前記加盟店に送信する決済処理ステータス送信ステップと、
   を有する決済方法。
6. 請求項１〜４のいずれかに記載の仮想商店街管理システムの各手段をコンピュータに機能として実現させるためのプログラム。