共同購入管理サーバ、システム及びプログラム
【課題】 共同購入の仕組みをリアル・ショッピングの場に融合するための共同購入管理サーバ等を提供する。
【解決手段】 共同購入管理サーバは、店舗端末から共同購入に参加するリアル店舗の情報を登録し、当該リアル店舗にて販売される商品等の共同購入に関する情報を受付けて、当該共同購入に関する情報を通信媒体に発信する。さらに、共同購入の対象となる商品等に対して消費者からの購入情報を受付けて、商品等の共同購入に関する情報を、所定のタイミングで更新して通信媒体に発信する。さらに、共同購入期間が終了した際には、商品等の決済データを生成し、消費者が購入情報で指定した金融機関のシステムに送信する。共同購入に関する商品等の情報は、リアル店舗の位置情報と消費者端末の位置情報に基づき段階的に発信する。
【解決手段】 共同購入管理サーバは、店舗端末から共同購入に参加するリアル店舗の情報を登録し、当該リアル店舗にて販売される商品等の共同購入に関する情報を受付けて、当該共同購入に関する情報を通信媒体に発信する。さらに、共同購入の対象となる商品等に対して消費者からの購入情報を受付けて、商品等の共同購入に関する情報を、所定のタイミングで更新して通信媒体に発信する。さらに、共同購入期間が終了した際には、商品等の決済データを生成し、消費者が購入情報で指定した金融機関のシステムに送信する。共同購入に関する商品等の情報は、リアル店舗の位置情報と消費者端末の位置情報に基づき段階的に発信する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、共同購入管理サーバ、システム及びプログラムに関し、特にネットワーク上の共同購入の仕組みを実際に店舗を持つ商店等に統合させることができる共同購入管理サーバ、共同購入管理システム及び共同購入管理プログラムに関する。
【背景技術】
【０００２】
昨今、インターネット上のオンライン・ショッピングにおいて、共同購入のシステムが広く利用されるようになってきている。ここで、共同購入とは、あらかじめ同一の商品またはサービス（以下、商品等）の提供者が、購入者のデータを管理し、購入者数や商品等の販売数に応じて割引価格を設定することによって販売を促進するための仕組みである。つまり、同一の商品等を購入する人が増えれば増えるほどその商品等の価格が下がっていく仕組みである。商品等の提供者にとっては、販売数の大幅な増加が期待できるほか、仕入れ数や在庫数の調整にも役立てることができる。また、消費者にとっても、購入を検討している商品等の価格が日々下がっていく様子を見るのは楽しいし、単独で購入するよりも割安な価格で購入できるので購買のインセンティブが高まる。
【０００３】
ネット上の共同購入をサポートするシステムとしては、例えば、特許文献１のように、複数の会員から共同購入資金を一括集金し、その中からボーナス（賞金）を創出し、抽出された会員に分配するものや、特許文献２のように、共同購入する際の商品代金の決済を行う場合に、あらかじめ登録してある複数の購入者から仮想的な振込みを行い、決済時に仮想的に振り込んだ金額に応じて各購入者の預金口座のある銀行に対して自動振り替えを指示するものなど、いくつかが開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００２−３２６７２号公報
【特許文献２】特開２００３−１３２２２２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記の特許文献１や特許文献２に記載されているシステムや方法は、あくまでもネット上のオンライン・ショッピングでの共同購入をサポートする仕組みであり、現実に存在する百貨店や商店街等での「リアル」店舗の場での共同購入の活動をサポートするものではなかった。
【０００６】
最近では、「リアル」店舗の場であらかじめ商品を、見て手にとって触れて確かめておいた後で、実際の購入はネット・ショッピングで、というようなことがよく見られる。しかし、商店街や百貨店（以下商店街等）では、このようにネット・ショッピングにばかりに多くの顧客が流れてしまうことは避けたいと願っており、昨今の「シャッター通り」の現象に見られるような商店街等の低迷化を打破することが地域の大きな課題となっている。
【０００７】
ところで、ネット・ショッピングでは、消費者は、ある程度、購入する商品を決めてから購入する傾向があるのに対し、「リアル・ショピング」では、消費者は、店舗に入ってからはじめて購入商品を決める場合や、たまたま隣の店舗で目にはいったものを「ついでに買ってしまう」ことが少なくない。すなわち、「リアル」店舗の場では、副次的・衝動的な購買（買い周り）が多くみられるといった特色がある。そこで、上記のようなリアル・ショッピングでの特色に着目しつつ、商店街等や地域の活性化に繋がるような新たな仕組み作りが求められている。
【０００８】
本発明では、上記のような課題に鑑み、ネット上の共同購入の仕組みをリアル・ショッピングの場に融合するための共同購入管理サーバ、システム及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
上記目的を達成するため、本発明の共同購入管理サーバは、以下の解決手段を備えている。
現実社会に店舗を有する店舗情報を発信する店舗端末とネットワークを介して接続された共同購入管理サーバであって、前記店舗端末から共同購入に参加する店舗の情報を受付けて記憶する店舗情報登録部と、前記店舗にて販売される商品またはサービスの共同購入に関する情報を受付けて記憶する共同購入商品受付部と、前記受付けた商品またはサービスの共同購入に関する情報を通信媒体に発信する共同購入情報発信部と、前記共同購入の対象となる商品またはサービスに対して消費者からの購入情報を受付けて記憶する商品購入受付部と、前記共同購入情報発信部が発信した前記商品またはサービスの共同購入に関する情報を、所定のタイミングで更新して前記通信媒体に発信する購入状況監視部と、前記商品購入受付部によって購入を受付けられた商品またはサービスの決済データを生成し、前記消費者が前記購入情報で指定した金融機関のシステムに送信する決済部と、を備えたことを特徴とする、共同購入管理サーバ。
【００１０】
上記発明によれば、現実社会（リアル）の店舗の情報を受付けた共同購入管理サーバが、当該店舗情報の登録、共同購入対象商品情報の登録と外部への発信、それを受けた消費者が実際購入した購入商品情報（共同購入商品等の購入データ）の管理、共同購入商品等の販売状況を監視し、購入商品情報の更新と発信、決済データの生成、金融機関への請求データの発信までを一環して行うので、リアル店舗での共同購入の仕組みを容易に導入することができる。
【００１１】
さらに、本発明の共同購入管理サーバは、以下の機能を備えることができる。
前記共同購入管理サーバは、消費者が携帯する消費者携帯端末の位置情報を検知する手段を備え、前記店舗情報登録部が受付ける前記店舗情報は、前記店舗の位置情報を含み、前記共同購入情報発信部または前記購入状況監視部が発信する前記商品またはサービスの情報を、前記店舗の位置情報と前記消費者携帯端末の位置情報に基づいて段階的に前記消費者携帯端末に発信する。
【００１２】
上記発明によれば、共同購入管理サーバは、消費者が携帯する携帯端末の位置を検出する手段を有し（典型的には、携帯電話機等に備えられたＧＰＳ機能を利用する）、消費者がその店舗あるいは商店街等に近づくにつれて、共同購入に関するより詳しい情報を段階的に送信する。これによって、消費者は、その店舗や商店街等に近づけば近づくほど有用な情報が得られるので、実際に行ってみようという気分が高まり、店舗や商店街等とっては、リアル・ショッピングの特色でもある買い周りを促進することができる。
【００１３】
さらに、本発明の共同購入管理サーバは、以下の機能も備えることができる。
前記共同購入情報発信部は、前記店舗が属する地域内の一又は複数の所定の場所の位置情報を記憶し、前記消費者携帯端末の位置情報が前記所定の場所の位置情報の近傍にあるときは、前記共同購入情報発信部または前記購入状況監視部は、前記所定の場所から目視できるあらかじめ定められた店舗の情報を前記消費者携帯端末に発信する。
【００１４】
上記発明によれば、店舗が属する地域や商店街等の中に所定の位置をあらかじめ定めておき、消費者がその所定の位置近傍（例えば数メートル以内）に来たときに、その位置から見えるあらかじめ定めた店舗の情報や共同購入の情報をまとめて発信することができる。このことによって、消費者は、自分の位置から見える範囲のごく真近の店舗内部の情報が一覧的に判るのでそれらの店舗に立ち寄ることが抵抗なく行える。このとき消費者は、携帯端末上で商店街のホームページ等を開くだけでよく、例えば、携帯電話機のカメラをそれぞれの店舗に向ける必要などはない。
【００１５】
さらに、本発明の共同購入管理サーバの決済部は、以下の機能も備えることができる。
前記決済部は、消費者が購入時の共同購入対象商品の価格と共同購入期間が終了したときの販売数に基づく前記共同購入対象商品の価格を比較して、後者が前者が後者より高い場合には、その差額分を追加購入データとして前記金融機関のシステムに送信する。
【００１６】
上記発明によれば、本発明の共同購入管理サーバの決済部は、消費者が購入時は共同購入で最も価格が下がった場合の価格（最低価格）を支払い、共同購入期間終了後に最低価格に届かなかった場合のみ差額を追加購入分としてクレジットカード会社等の金融機関に請求する。金融機関は、後日、消費者に購入時の代金および追加購入として差額代金も請求することになる。もちろん、消費者は、このような仕組みを同意の上、商品等を購入するものとする。このことにより、消費者は共同購入対象商品を想定される最低価格をまずは支払って購入することができ、万一差額が発生したときのみ、その差額分を支払えばよいので共同購入で最低価格になるまで待ったり、購入をためらうことがなくなる。ネット・ショッピングと異なり、リアル・ショッピングでは消費者は長時間その店舗に留まって価格の変化をチェックすることができないので消費者の共同購入の購買意欲を高めることができる。
【００１７】
さらに、本発明の共同購入管理サーバの決済部は、以下の別の機能も備えることができる。
前記決済部は、消費者が購入した共同購入対象商品の価格を共同購入期間が終了したときの販売数に基づく価格を含む購入データを作成し、前記金融機関のシステムに送信する。
【００１８】
上記発明によれば、本発明の共同購入管理サーバの決済部は、共同購入期間終了時の価格を含む購入データを作成して、金融機関のシステムに送信する。つまり、最終価格が確定するまで金融機関には購入請求データは送信されないので、購入時には消費者が支払う代金は未定である。前記の決済部の処理と異なり、消費者は、共同購入の最終価格のみを請求されるので、あとから追加請求されるかもしれない、という不安が解消される。
【００１９】
上記の発明は、店舗側からみれば、購入時にクレジット会社等に請求できないので代金が直ぐには回収できないが、決済処理が一度ですむので、消費者に信用力がある場合には、有効である。
【００２０】
また、本発明は、共同購入管理サーバの発明としてだけでなく、以下のように、サーバと店舗端末を含んだ共同購入管理システム、またはコンピュータを共同購入管理サーバとして機能させるコンピュータ・プログラムの発明としてとらえることもでき、前述の共同購入管理サーバの発明と場合と同様な効果を得ることができる。
【００２１】
現実社会に店舗を有する店舗の情報を発信する店舗端末と、共同購入管理サーバがネットワークを介して接続されたシステムであって、前記店舗端末は、共同購入に参加する店舗情報を送信し、前記共同購入管理サーバは、前記店舗端末から受信した店舗情報を受付けて記憶する店舗情報登録部と、前記店舗にて販売される商品またはサービスの共同購入に関する情報を受付けて記憶する共同購入商品受付部と、前記受付けた商品またはサービスの共同購入に関する情報を通信媒体に発信する共同購入情報発信部と、前記共同購入の対象となる商品またはサービスに対して消費者からの購入情報を受付けて記憶する商品購入受付部と、前記共同購入情報発信部が発信した前記商品またはサービスの共同購入に関する情報を、所定のタイミングで更新して前記通信媒体に発信する購入状況監視部と、前記商品購入受付部によって購入を受付けられた商品またはサービスの決済データを生成し、前記消費者が前記購入情報で指定した金融機関のシステムに送信する決済部と、を備えたことを特徴とする、システム。
【００２２】
現実社会に店舗を有する店舗の情報を発信する店舗端末とネットワークを介して接続されたコンピュータを、前記店舗端末から共同購入に参加する店舗情報を受付けて記憶する店舗情報登録部と、前記店舗にて販売される商品またはサービスの共同購入に関する情報を受付けて記憶する共同購入商品受付部と、前記受付けた商品またはサービスの共同購入に関する情報を通信媒体に発信する共同購入情報発信部と、前記共同購入の対象となる商品またはサービスに対して消費者からの購入情報を受付けて記憶する商品購入受付部と、前記共同購入情報発信部が発信した前記商品またはサービスの共同購入に関する情報を、所定のタイミングで更新して前記通信媒体に発信する購入状況監視部と、前記商品購入受付部によって購入を受付けられた商品またはサービスの決済データを生成し、前記消費者が前記購入情報で指定した金融機関のシステムに送信する決済部として、機能させることを特徴とする、コンピュータ・プログラム。
【発明の効果】
【００２３】
本発明によれば、ネット上の共同購入の仕組みを、リアル店舗へ商品販売活動に融合させ、リアル店舗に消費者を呼び込こむことで、商店街等の活性化や地域の活性化に役立たせることとができる。
【図面の簡単な説明】
【００２４】
【図１】本発明の実施形態に係る共同購入管理サーバ１０の機能ブロックを示す図である。
【図２】本発明の実施形態に係る店舗情報及び共同購入商品情報を示す図である。
【図３】本発明の実施形態に係る購入者情報及び購入商品情報を示す図である。
【図４】本発明の実施形態に係る共同購入商品受付部１３の処理を示すフロー図である。
【図５】本発明の実施形態に係る商品購入受付部１５の処理を示すフロー図である。
【図６】本発明の実施形態に係る購入状況監視部１６の処理を示すフロー図である。
【図７】本発明の実施形態に係る共同購入対象店舗の発信情報の一例を示す図である。
【図８】本発明の実施形態に係る共同購入対象の発信情報の別の例を示す図である。
【図９】本発明の実施形態に係る決済部１７の一つの処理を示す図である。
【発明を実施するための形態】
【００２５】
以下、図面を参照して、本発明を実施するための形態（以下、実施形態）について詳細に説明する。なお、実施形態の説明の全体を通して同じ要素には同じ番号を付している。
【００２６】
図１は、本発明の実施形態に係る共同購入管理システム１の機能ブロックを示す図である。本システムにおいて、共同購入管理サーバ１０は、ネットワーク２０を介して、店舗端末３０と消費者携帯端末４０とに接続される。共同購入管理サーバ１０は、ＣＰＵ(Central Processing Unit)、メモリ（ＲＡＭ，ＲＯＭ）、ハードティスク等の記憶装置、ＣＲＴや液晶ディスプレイ等の表示装置、キーボードやマウス等の入力装置、及び通信インターフェースを含む一般的なコンピュータであってよい。図示するように、本実施形態の共同購入管理サーバ１０は、制御部１１、店舗情報登録部１２、共同購入商品受付部１３、共同購入情報発信部１４、商品購入受付部１５、購入状況監視部１６、決済部１７とデータベース（以下、ＤＢ）である店舗ＤＢ１８Ａ、消費者ＤＢ１８Ｂ、通信部１９の機能ブロックから構成される。
【００２７】
上記の機能構成は、あくまで一例であり、一つの機能部を更に分割したり、複数の機能部をまとめて一つの機能部として構成してもよい。データベースについても同様である。各機能部は、典型的には、メモリや記憶装置に格納されたコンピュータ・プログラムが読み出され、ＣＰＵで実行され、実行されたプログラムが記憶装置に格納されたＤＢから必要なデータを読み書きし、場合によっては、その他関連するハードウェア（例えば、入出力装置や通信インターフェース装置）を制御することによって実現される。
【００２８】
制御部１１は、各機能部のプログラムを読み出したり、ＣＡＬＬすることにより各機能部の実行を制御する。通信部１９は、通信インターフェースとなるハードウェアを含み、ネットワーク２０を介して、本サーバと店舗端末３０や消費者携帯端末４０との通信を制御する。
【００２９】
店舗情報登録部１２は、店舗端末３０から受信した、商店街等の店舗情報をあらかじめ店舗ＤＢ１８Ａに登録する機能を持つ。店舗情報は、後述するように、本共同購入システムに参加する店舗名や住所、店舗の位置情報、所属する商店街名などを記録したテーブルで構成される。共同購入商品受付部１３は、登録された上記の店舗端末３０から共同購入対象商品として販売する商品、サービスの情報（以下、共同購入商品情報）を受付けて記憶する機能を持つ。共同購入商品情報とは、本共同購入システムの対象となる商品ＩＤ、商品名や、販売期間、割引価格の情報を記憶したテーブルである。共同購入商品情報は、店舗ＤＢ１８Ａ上の店舗情報と紐づけされ、店舗ＤＢ１８Ａ上に格納される。
【００３０】
共同購入情報発信部１４は、共同購入商品受付部１３で登録された共同購入商品情報を、それを提供する店舗情報と共に、外部の通信媒体に情報発信する機能部である。情報発信の手段としては、商店街のホームページ等にアップロードする方法、登録された消費者にダイレクトメールを発信する方法、店舗前や商店街入口、近隣の商業施設、駅等に設置された広告パネルやデジタル・サイネージに発信する方法等、様々な方法があるが、共同購入情報発信部１４は、それらの一または複数の方法に対応できる手段をもつことができる。また、共同購入情報発信部１４は、後述するように、消費者の位置（消費者の携帯端末の位置情報）によって、表示する内容や情報の量を変化させることができる。消費者の携帯端末の位置情報は、共同購入情報発信部１４が、ＧＰＳ（Global Positioning System）付の携帯電話機やＰＨＳ（Personal
Handy-phone System）の基地局の位置情報を取得すること等によって得られる。
【００３１】
商品購入受付部１５は、消費者が共同購入対象商品等を実際に購入する場合に、その消費者（購入者）の情報（住所氏名などの消費者個人情報や代金支払い方法等）と購入品の情報（商品ＩＤ、割引価格情報等）を、消費者ＤＢ１８Ｂに格納された購入者情報と購入商品情報にそれぞれ記憶させる役目を果たす。購入者情報と購入商品情報は、任意のテーブル形式でＤＢに保存され、購入者と購入商品が紐付けされる限り、分離してＤＢに格納しても、まとめてひとつのＤＢに格納してもどちらでもよい。
【００３２】
購入状況監視部１６は、定められた共同購入対象期間中、その対象製品の購入状況（販売状況）をモニタする。すなわち、購入が発生するたびに、または所定の間隔で、対象商品の購入商品情報を読み出し、最新の購入者数や商品等の購入数（２つ総じて単に販売数と呼ぶ）を読み出し集計する。そして、集計した販売数と、あらかじめ登録されている共同購入商品情報とに基づいて現在の割引価格を決定する。例えば、販売数が１〜１０までは２００円、１１〜４９までは１００円、５０以上は８０円として登録されている商品の販売数が現在１５であれば、割引価格は１００円となり、さきに共同購入情報発信部１４が発信した共同購入商品情報を更新する。また、購入状況監視部１６も、消費者携帯端末４０の位置情報を取得することによって、それに基づいて更新情報を変化させることができる。例えば、近隣にいる消費者に、共同購入販売期間の終了時刻や、タイムセールスの終了時間の情報を付加したりすることもできる。なお、購入状況監視部１６と共同購入情報発信部１４は、情報発信の共通機能を持つため一つに統合してもよい。
【００３３】
決済部１７は、消費者が共同購入対象商品を購入した際に、商品の価格の支払い決済を行う。共同購入の価格を決定する方法は、購入時にその時点の販売数または購入者数によって価格が決定する場合と、購入時には最終価格を決めずに共同購入期間終了時に終了時点の販売数（通常は、購入者数または商品等の購入数であり、あらかじめどちらかに選択される）によって最終価格を決定する場合とが考えられる。前者の場合は、ある消費者にとっては購入時点で最終価格が決定するので、通常の商品購入と同様にその時点の金額で決済すればよいが、後者の場合には、購入時点では最終価格が決定しない。その消費者が購入した後も、他の消費者によって販売数が増えれば増えるほどその消費者が購入した時点よりも価格が下がる可能性がある。そのため、購入時点では、店舗側は、価格の支払いをせずに後日最終価格が決定した時点で請求するか、購入時には仮の金額を支払ってもらい、後に差額が生じた場合には、清算することが必要である。本実施形態の決済部１７は、様々な決済方法に対応できるものとするが、後述するように、購入時点ではあらかじめ定められた最低価格（すなわち、最も大量に売れたと仮定した場合の価格）を支払ってもらい、のちに価格が最低価格に届かなかった場合にのみ、差額を購入者に追加請求することができる。逆に、購入時にはその時点の販売数に応じた価格を支払ってもらい、その後価格が下がった場合には、差額を返金することもできる。返金するより追加請求するほうがシステム上は煩雑にならないが、消費者にとっては追加請求されることは抵抗があるので、どちらも消費者が選択できるようにしておくほうがよい。また、差額が発生した場合、返金する代わりに、次回来店時の支払に充当されるようにシステム上で管理されてもよい。もちろん、購入時には代金をもらわず、最終価格が決定した時点ではじめて請求することもできるが、消費者の信用力が必要で、店舗側にとっては入金が遅れるという問題は残る。
【００３４】
図２は、本発明の実施形態に係る店舗情報及び共同購入商品情報を示す図である。店舗情報は、図２（ａ）に示すような、店舗ＩＤ，店舗名，取扱商品，店舗住所，店舗位置情報，所属商店街ＩＤ等、共同購入販売に参加する店舗の情報を含んだテーブルである。テーブルの形式は任意である。このうち、店舗位置情報は、ＧＰＳから取得した東経、緯度、および高度の情報であってよいし、店舗の地図データを掲載しその地図データから得られる位置情報であってもよい。店舗情報は、各店舗の端末からデータを共同購入管理サーバに送信してもよいし、店舗端末がない店舗のために商店街組合等の共有端末からデータを送信してもよい。もちろん、登録用紙に記入したものを持参してもらい、サービス提供者の端末からオペレータが入力してもよい。以上、いずれの端末も図１では店舗端末３０として表している。
【００３５】
共同購入商品情報は、図２（ｂ）に示すような共同購入の対象となる商品の情報と販売情報を集めたテーブルである。テーブルの形式は任意である。商品情報には、商品ＩＤ、商品名が含まれ、販売情報には、共同購入の販売期間，商品の取扱数（在庫数），価格情報，現在の購入者数および購入数，現在価格，残り取扱数（取扱数−購入数）等が含まれる。価格情報には、共同購入開始時のスタート価格とスタート価格が適用となる販売数の条件であるスタート価格数が含まれ、同様に、少なくとも最終価格（最低価格）とそれに必要な最終価格数が含まれる。スタート価格と最終価格の間に、割引価格１や割引価格１数のように、複数の割引価格と対応する販売数を段階的に決めて配置してもよい。また、付加データとして、商品宣伝のために発信する共同購入商品情報に付加するメッセージや写真などを追加することができる。もちろん、商品自体の写真やより詳細な情報を含んだページへのリンク等を付加してもよい。また、後述するように、消費者携帯端末の位置情報と店舗の位置情報をもとに、発信する情報に段階的に変化をもたせるようにテーブルを構成してもよい。例えば、商店街等から離れている消費者には、商店街全体のイベントやセールス情報を発信し、商店街近傍にいる消費者には当日限りの共同購入情報を、店舗に近い消費者には、実際に店舗に呼び込むための特別な情報を配信する。すなわち、消費者が店舗に近づけば近づくほど有用な情報を発信するようにして、リアル店舗での消費活動を促すようにすることが好ましい。
【００３６】
図３は、本発明の実施形態に係る店舗情報及び共同購入商品情報を示す図である。購入者情報は、図３（ａ）に示すように、購入者のＩＤ（ユーザＩＤ），住所，氏名，電話番号，生年月日等の個人情報や、決済のためのクレジット番号や銀行の口座情報等を消費者毎に記録したテーブルである。テーブルの形式は任意である。このような情報は、消費者が初めてその商店街等で買い物をしたときに消費者が開示できる範囲で許諾を受けてデータベースに登録する。もちろん、携帯電話機やノートパソコンなどの消費者携帯端末４０や消費者の自宅のパソコン等から商店街等のホームページにアクセスし、消費者が直接登録してもよい。もっとも、購入時に購入価格が決定し現金で決済が行われる場合は、住所・氏名等の個人情報の開示は必須ではない。すなわち、購入時の販売数に対応する価格で決済するからである。ただし、この場合、購入者は、購入後に価格が下がっても、追加割引等のメリットは享受することはできない。なお、現金決済の場合でも共同購入商品情報のテーブルにある現在購入者数や現在購入数は更新されることが必要である。
【００３７】
購入商品情報は、図３（ｂ）に示すように、消費者（購入者）が購入した商品のＩＤ，購入日時，購入店名，購入商品名，購入価格，決済日時（共同購入期間終了日時），決済価格（共同購入期間終了時に確定した価格）を商品毎に記録したテーブルである。テーブルの形式は問わない。ここで「購入価格」とは、購入時に消費者が支払った価格（請求のみで実際の支払いは後日の場合でもよい）である。その後、販売数が増えさらに価格が下がった場合には差額を調整できるように、「購入価格」を想定される最低価格（共同購入で最も大量に売れた場合の価格）にセットしておくと、その後、最低価格に届かなかった場合に、差額を追加請求できるようにする。逆に、「購入価格」を購入時点の販売数に応じた価格にセットしておき、その後価格が下がった場合には、差額を返金するようにすることもできる。
【００３８】
図４は、本発明の実施形態に係る共同購入商品受付部１３の処理を示すフロー図である。ここで、商品購入とは消費者が店舗等で商品を受け取る代わりに代金を支払う、あるいは後日支払うことを同意することを意味する。
【００３９】
共同購入商品受付部１３は、まずステップＳ１０において、店舗端末３０から共同購入対象商品の登録データを受付ける。登録データには、図２（ｂ）で示したような共同購入商品情報が含まれる。
【００４０】
次に、共同購入商品受付部１３は、現在の日時が登録データに含まれる販売期間、すなわち共同購入の対象期間を過ぎてないかチェックする。過ぎている場合は（ステップＳ１１；Ｎｏ）、しかるべきエラーメッセージを発し、処理を終了する。販売期間が過ぎていない場合は（ステップＳ１１；Ｙｅｓ）、ステップＳ１２に処理を移す。
【００４１】
ステップＳ１２においては、共同購入商品受付部１３は、対象商品が新規かどうか判断する。具体的には、店舗ＤＢ１８Ａから共同購入商品情報テーブルを読み出し、すでに登録されている商品ＩＤが存在していなければ（ステップＳ１２；Ｙｅｓ）新規登録商品と判断する。商品ＩＤが存在する場合は（ステップＳ１２；Ｎｏ）は、さらにステップＳ１３において、その商品を登録した販売店名（または店舗ＩＤ）をチェックし、販売店が同じであれば（ステップＳ１３；Ｙｅｓ）、既存商品の更新であると判断し、ステップＳ１５に移り、既存商品として商品情報を更新する。販売店が異なる場合は（ステップＳ１３；Ｎｏ）、新規の商品としてステップＳ１４に移り、商品情報を新既登録する。商品ＩＤが同じでも販売店が異なれば、販売条件（販売期間，価格，数量等）が異なるので、新規の商品として登録する。その場合、過去に登録された同じ商品の情報を注意喚起として店舗端末３０に表示してもよい。また、また同じ商品の販売期間が重なり、その他の条件が同じ場合には両者のデータをマージするようにしてもよい。この場合は、一つの商品等に販売店が複数登録される。
【００４２】
なお、ここでは図示していないが、共同購入商品受付部１３が商品を登録し処理を終了した後は、共同購入情報発信部１４が、登録された共同購入商品情報を外部の通信媒体に発信する。外部の通信媒体とは、店舗や商店街のホームページや消費者へのダイレクトメール、広告パネルやディジタル・サイネージなどが考えられるが、それらへの情報発信手段はいずれも既存技術を用いて実現できる。
【００４３】
図５は、本発明の実施形態に係る商品購入受付部１５の処理を示すフロー図である。ここでの商品購入は、共同購入商品の情報をなんらかのかたちで知った消費者が実際にそのリアル店舗に赴き、対象製品をクレジットカードで購入する場面を想定している。基本的には、支払いがデビットカードでも同様である。
【００４４】
まず、商品購入受付部１５は、ステップＳ２０において、店舗端末３０またはカード読み取り機から入力されたクレジットカードの情報をもとにクレジットカードの与信照会をする。その結果、与信ＯＫの場合は（ステップＳ２１；Ｙｅｓ）の場合は次の処理に移るが、Ｎｏの場合は、その旨エラーメッセージを送信する。
【００４５】
クレジットカードの与信が正常に終了すると、商品購入受付部１５は、この辞実施例では、最終価格を購入価格にセットする。最終価格とは、その商品の共同購入における最も低い価格であり、通常は、最もその商品が売れた場合の価格（最低価格）である。購入価格とは、消費者がその場でひとまず支払うあるいは支払う意思を確約した価格である。
【００４６】
購入価格が決まると、商品購入受付部１５は、ステップＳ２２において、最終価格を購入価格とした仮購入データを作成し（ステップＳ２３）、その仮購入データを、クレジットカード会社の金融機関のシステムに正規の請求データとして送信する（ステップＳ２４）。ついで、商品購入受付部１５は、消費者ＤＢ１８Ｂ上の共同購入情報を更新する（ステップＳ２５）。すなわち、該当商品の現在購入者数を１増加させ、現在購入数をその消費者が購入した数だけ増加させる。商品購入受付部１５の処理は以上で終了するが、後日、クレジットカード会社は、この送信されたデータに基づいて、店舗側に購入価格の立替払いを行う。そして、クレジットカード会社では、クレジットカードの締め日までの消費者が使用したカードの購入データをまとめて、消費者側に通常の請求処理を行う。本実施例では、クレジットカード会社側では特に商品購入受付部１５が送信した仮購入データが共同購入商品であるか否かを知る必要はない。
【００４７】
なお、図５のステップＳ２２の例では、最終価格（最低価格）を購入価格にセットしたが、現時点（購入時）での価格（現在価格）を購入価格にセットするようにしてもよい。これは、消費者がその後の販売数の増加による価格の低下によるメリットを放棄した場合に有効である。すなわち、ステップＳ２２においては、購入価格は最低価格にセットされているのでこれ以上価格が下がることはなく、購入数が最低価格ラインまで届かない場合は、逆に差額を追加請求されることを消費者が嫌うことがあるからである。この場合には、購入時の価格が最終価格となり、以後の差額調整は行われないことになるので、ステップＳ２３、Ｓ２４で処理するのは仮購入データではなく最終購入データとなる。なお。仮購入データの場合は、後の処理のために、フラグをデータ内に付加しておく。
【００４８】
図６は、本発明の実施形態に係る購入状況監視部１６の処理を示すフロー図である。購入状況監視部１６は、所定のタイミングで常に共同購入対象製品の販売状況を監視する機能を持っている。
【００４９】
購入状況監視部１６は、まず、店舗ＤＢ１８Ａから共同購入商品情報を読み出す（ステップＳ３０）。読み出すタイミングは、あらかじめ定められた時間毎であってもよいし、商品購入受付部１５が共同購入商品情報を更新したイベントを検知したときでもよい。次に、購入状況監視部１６は、ステップＳ３１において、読み出した共同購入商品情報の中の現在価格、残り取扱数を同じ共同購入商品情報の価格情報に基づいて更新する。さらに、更新された付加データがあれば（ステップＳ３２；Ｙｅｓ）、その更新された付加データをマージして前述の通信媒体に送信する（ステップＳ３４）。付加データの更新は、販売開始時だけでなく、販売中も随時、店舗側から更新できるものとする。例えば、売れ行きが芳しくないときに、販促メッセージを付加したいような場合である。また、ある商品が予想外に早く売り切れになりそうな場合にもその旨をメッセージとして提供することによって、近くにいる消費者に購買機会を失わないようにすることもできる。このため付加メッセージも購入状況監視部１６による常時監視する。以上の処理（ステップＳ３０〜Ｓ３４）を終了条件（例えば、購入対象商品をすべて処理した場合や、商店街全体での共同購入販売期間が終了した場合）に達するまで繰り返す（ステップＳ３５）。
【００５０】
＜情報発信画面例＞
図７は、本発明の実施形態に係る共同購入対象店舗の発信情報の一例を示す図である。図示するように、店舗名、店舗の紹介記事等と共に、共同購入対象商品の情報が一覧できるようにする。すなわち、店舗ごとに共同購入対象商品の商品名，販売期間（共同購入対象期間）の日時，商品の取扱数（在庫数），スタート価格とその対象数量（かっこ内），最終価格とその対象数量（かっこ内）が少なくとも表示される。特に図示していないが、スタート価格と最終価格以外にも段階的な割引価格を設定する場合にもそれらの価格と数量を掲載する。また、商店街へのアクセスや他のキャンペーン情報、各店舗の地図等が表示されてもよい。
【００５１】
前述したように、共同購入情報発信部１４は、商店街等の共同購入の情報を知らしめるため数々の通信媒体に送信する。しかし、リアル店舗の情報発信（広告）には、実際に消費者にその店舗まで足を運んでもらう必要があるため通常のネット販売とは異なる情報発信方法が必要である。
【００５２】
図８は、このための本発明の実施形態に係る共同購入対象の発信情報の別の例を示す図である。具体的には、地図情報を利用した商店街での共同購入のキャンペーンをＷｅｂページ上に発信した場合の画面の一例である。
【００５３】
図８の左側の図では、消費者の携帯端末（たとえば、ＧＰＳ付きの携帯電話機）における画面の一例が示されている。この図では、人物のアニメーションの位置が消費者のいる現在位置を示している。この消費者は、現在ＡＢＣ商店街の近くにおり、広告やメール等の何らかのトリガで携帯画面を開き、この商店街の各店舗で共同購入のセールスが行われていることを知る。ただし、この時点では対象店舗数は３０店舗であること以外、詳しい情報は示されていない。
【００５４】
その後、消費者は、商店街の入口付近で再度、携帯画面を開いたとする。そのときの画面が図８の右側の図である。この図でわかるように、左の画面では表示されなかった商店街の情報がより詳しく表示される。また、当初は見えなかった店舗も表示されている。このようなことは、消費者の携帯端末のＧＰＳ等からの位置情報をもとに、共同購入情報発信部１４または購入状況監視部１６が、その消費者の興味を引くように（呼び込むように）、共同購入対象店舗や商品情報を段階的に送信することによって実現できる。
【００５５】
例えば、より具体的には、商店街の地図と消費者の携帯端末の位置から見える範囲の店舗と商品情報を携帯画面に表示する。同じ商店街であっても消費者の現在位置からは見えないと想定される店舗の情報はこの時点では表示されない。しかし、消費者がその表示されなかった店舗により近づくとその店舗の情報が表示され、逆に遠ざかるとその店舗の情報が徐々に消えていくようにする。これは、店舗ＤＢ１８Ａには各店舗の位置情報が登録されているので、消費者の携帯端末の位置情報と店舗の位置情報との水平距離と、発信する情報を対応付けたテーブルを店舗ＤＢ１８Ａに持つことにより実現できる。
【００５６】
あるいは、商店街等の所定の位置にあらかじめ何点かポイントを定義しておき、消費者がそのポイント近傍（例えば５ｍ以内とか）に来たときに、はじめてそこから見える店舗（あらかじめポイントごとに定義しておく）の情報を発信する。こうすることで単に水平距離にもとづいて情報発信することに比べて、ビルなどの障害物のあるなし等を考慮した「現実にそこから見える店舗」のみの情報を発信することで消費者がその店舗に行くことの動機付けを行う。あるいは、そのポイントからは直接見えなくとも、もう少し行けば見える店舗の存在自体を示す情報を付加してもよい。例えば、あるポイントでは、そのポイントから見える店舗の名前やそのセールスポイント以外にも、そのポイントからは見えないが、近くの観光名所やパワースポット等の情報を追加で表示するといったことである。ただし、最初からすべての情報を発信するのでなく、そのスポットに行ってはじめて見える情報も残しておく。いずれにしても、消費者がその場に入ってみたいという情報を段階的に表示することが必要である。そしてその情報を、共同購入と関連付ける。例えば、指定したスポットや店舗を数箇所立ち寄れば、さらに共同購入の特典を付加する、といったことである。
【００５７】
このようなシステムは、消費者にとっては、ネット・ショッピングと異なり、現実に「その場」に行くことにより、より有用」な情報が増えることになるので、店舗に人を呼びこむための方法として有効である。しかも、共同購入による割引価格のメリットが受けられるため、消費者はその近辺の店舗で当初予定していなかった買い物をしてくれる確率、すなわち、その場で見たものを衝動的に買ってしまう「衝動買い」や、欲しいものを忘れていたことに気付かされたり、新たな情報を理解して商品に惹かれて購入する「気付き買い」の確率が高まり、「リアル」な店舗で買い回りを促進するためのツールとしても本発明は有効である。
【００５８】
このように、本発明の共同購入のシステムは、多くの人を商店街等に呼び込めば呼び込むほどその効果が増大し、店舗、消費者共にメリットがあるので、消費者の口コミや店舗間の販売促進のための協力が推進されることが期待できる。そして、商店街等の近くにより人を引きつけ、地域の活性化に繋がる。
【００５９】
＜共同購入における決済方法＞
すでにいくつか部分的には述べたが、共同購入における決済方法について、ここで再度まとめて議論する。共同購入では、購入時の販売数量に基づいた価格を支払う場合と、共同購入期間中の購入後の最終販売数量にもとづいた最終価格で支払いを行う場合とが考えられる。前者の場合のみだと、消費者は最低価格に達するまで購入を待つことが想定され、ネット・ショッピングと異なり、リアル・ショッピングの場合では、消費者は長期間その場で留まることはできないので（逆にそれを誘導するという考え方もあるが）、なかなか最低価格では購入しにくい、といった問題がある。
【００６０】
そのため、以下に示す決済処理は、いったん購入時に仮決済し、その後、価格が変動したときにはその差額を追加処理するためのものである。以下、具体的にフロー図で説明する。
【００６１】
図９は、本発明の実施形態に係る決済部１７の一つの処理を示す図である。決済部１７は、まずステップＳ４０において、店舗ＤＢ１８Ａから共同購入情報を読み込む。そして、読み込んだ情報中に販売期間終了（共同購入期間終了）の商品データがあるかどうかを判断する（ステップＳ４１）。販売期間終了のものがなければ（ステップＳ４１；Ｎｏ）、ステップＳ４７へ処理を移す。
【００６２】
販売期間中であれば（ステップＳ４１；Ｙｅｓ）、その商品の購入商品情報（購入データ）を読み込み（ステップＳ４２）、購入者がある場合は（ステップＳ４３；Ｙｅｓ）、現在価格と最終価格を比較し、現在価格が最終価格より高い場合は（ステップＳ４４；Ｙｅｓ）、現在価格から最終価格を減算した価格（差額）を購入価格とし、その差額を追加請求するための追加購入データを新たに作成する（ステップＳ４５）。そして、ステップＳ４４とステップＳ４５の処理をその商品の購入者全員に対しておこなう（ステップＳ４６）。
【００６３】
ステップＳ４３で購入者がない場合（ステップＳ４３；Ｎｏ）、またはステップＳ４６で別の購入者がいない場合は（ステップＳ４６；Ｎｏ）、次の未処理の共同購入対象商品がなくなるまで、ステップＳ４１〜ステップＳ４６の処理を繰り返す（ステップＳ４８）。
【００６４】
決済部１７は、最後に、購入者ごとに追加購入データをクレジット会社等の金融機関のシステムに送信する（ステップＳ４８）。追加購入データがない場合は、すなわち、現在価格が最終価格であるということで、購入者は最終価格をすでに購入時に支払っているので（図５ステップＳ２２参照）、差額調整は必要なく追加購入データは送信しない。
【００６５】
上記実施例では、購入時に購入者は、最低価格でいったん購入代金を支払い、共同購入終了時に最低価格に相当する販売量に届かなかったために差額が発生した場合にのみ、その差額を追加で支払う処理について示した。
【００６６】
別の決済処理方法としては、特に図示していないが、購入時には価格は決定せず（購入者は購入時には代金を支払わず、購入確約の意思のみを示して必要なデータを登録して商品を受け取る）、その後、共同購入期間終了後に最終価格が決定した時点ではじめて決済部１７が、購入データを作成し、クレジット会社に送信する決済方法もある。この場合は、最初の購入価格がゼロ円、追加購入価格が最終価格となる。
【００６７】
上記の別の決済方法は、一種の信用買いであるため、消費者によほど信用力がないと店舗側としては採用しずらい。また、共同購入のシステムでできるだけ多くの人を地域に集めたいという趣旨には多少そぐわない。そこで、以下に示す「通常の決済方法」もある。
【００６８】
「通常の決済方法」では、購入時に、その時点での販売数量にもとづいた価格で取引し、その後、差額が発生した場合にもいっさい差額の調整を行わないものである。これは購入後の価格低下の楽しみはなくなるが、支払い代金を購入時に確定させたい思う購入者もいるためにオプションとしては必要である。なお、上記の決済方法はすべて、共同購入の割引は価格割引の提供で行うことを前提にしたが、割引の方法は、価格割引だけでなく、買物券や地域通貨の提供であってもよい。いずれにしても本発明では、決済部１７の処理ロジックを多少変更するだけで様々な決済方法に対応できる。
【００６９】
以上、実施形態を用いて本発明を説明したが、本発明の技術的範囲は上記実施形態に記載の範囲には限定されないことは言うまでもない。上記実施形態に、多様な変更または改良を加えることが可能であることが当業者に明らかである。またその様な変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。
【符号の説明】
【００７０】
１０ 共同購入管理サーバ
１１ 制御部
１２ 店舗情報登録部
１３ 共同購入商品受付部
１４ 共同購入情報発信部
１５ 商品購入受付部
１６ 購入状況監視部
１７ 決済部
１８Ａ 店舗ＤＢ
１８Ｂ 消費者ＤＢ
１９ 通信部
２０ ネットワーク
３０ 店舗端末
４０ 消費者携帯端末
【技術分野】
【０００１】
本発明は、共同購入管理サーバ、システム及びプログラムに関し、特にネットワーク上の共同購入の仕組みを実際に店舗を持つ商店等に統合させることができる共同購入管理サーバ、共同購入管理システム及び共同購入管理プログラムに関する。
【背景技術】
【０００２】
昨今、インターネット上のオンライン・ショッピングにおいて、共同購入のシステムが広く利用されるようになってきている。ここで、共同購入とは、あらかじめ同一の商品またはサービス（以下、商品等）の提供者が、購入者のデータを管理し、購入者数や商品等の販売数に応じて割引価格を設定することによって販売を促進するための仕組みである。つまり、同一の商品等を購入する人が増えれば増えるほどその商品等の価格が下がっていく仕組みである。商品等の提供者にとっては、販売数の大幅な増加が期待できるほか、仕入れ数や在庫数の調整にも役立てることができる。また、消費者にとっても、購入を検討している商品等の価格が日々下がっていく様子を見るのは楽しいし、単独で購入するよりも割安な価格で購入できるので購買のインセンティブが高まる。
【０００３】
ネット上の共同購入をサポートするシステムとしては、例えば、特許文献１のように、複数の会員から共同購入資金を一括集金し、その中からボーナス（賞金）を創出し、抽出された会員に分配するものや、特許文献２のように、共同購入する際の商品代金の決済を行う場合に、あらかじめ登録してある複数の購入者から仮想的な振込みを行い、決済時に仮想的に振り込んだ金額に応じて各購入者の預金口座のある銀行に対して自動振り替えを指示するものなど、いくつかが開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００２−３２６７２号公報
【特許文献２】特開２００３−１３２２２２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記の特許文献１や特許文献２に記載されているシステムや方法は、あくまでもネット上のオンライン・ショッピングでの共同購入をサポートする仕組みであり、現実に存在する百貨店や商店街等での「リアル」店舗の場での共同購入の活動をサポートするものではなかった。
【０００６】
最近では、「リアル」店舗の場であらかじめ商品を、見て手にとって触れて確かめておいた後で、実際の購入はネット・ショッピングで、というようなことがよく見られる。しかし、商店街や百貨店（以下商店街等）では、このようにネット・ショッピングにばかりに多くの顧客が流れてしまうことは避けたいと願っており、昨今の「シャッター通り」の現象に見られるような商店街等の低迷化を打破することが地域の大きな課題となっている。
【０００７】
ところで、ネット・ショッピングでは、消費者は、ある程度、購入する商品を決めてから購入する傾向があるのに対し、「リアル・ショピング」では、消費者は、店舗に入ってからはじめて購入商品を決める場合や、たまたま隣の店舗で目にはいったものを「ついでに買ってしまう」ことが少なくない。すなわち、「リアル」店舗の場では、副次的・衝動的な購買（買い周り）が多くみられるといった特色がある。そこで、上記のようなリアル・ショッピングでの特色に着目しつつ、商店街等や地域の活性化に繋がるような新たな仕組み作りが求められている。
【０００８】
本発明では、上記のような課題に鑑み、ネット上の共同購入の仕組みをリアル・ショッピングの場に融合するための共同購入管理サーバ、システム及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
上記目的を達成するため、本発明の共同購入管理サーバは、以下の解決手段を備えている。
現実社会に店舗を有する店舗情報を発信する店舗端末とネットワークを介して接続された共同購入管理サーバであって、前記店舗端末から共同購入に参加する店舗の情報を受付けて記憶する店舗情報登録部と、前記店舗にて販売される商品またはサービスの共同購入に関する情報を受付けて記憶する共同購入商品受付部と、前記受付けた商品またはサービスの共同購入に関する情報を通信媒体に発信する共同購入情報発信部と、前記共同購入の対象となる商品またはサービスに対して消費者からの購入情報を受付けて記憶する商品購入受付部と、前記共同購入情報発信部が発信した前記商品またはサービスの共同購入に関する情報を、所定のタイミングで更新して前記通信媒体に発信する購入状況監視部と、前記商品購入受付部によって購入を受付けられた商品またはサービスの決済データを生成し、前記消費者が前記購入情報で指定した金融機関のシステムに送信する決済部と、を備えたことを特徴とする、共同購入管理サーバ。
【００１０】
上記発明によれば、現実社会（リアル）の店舗の情報を受付けた共同購入管理サーバが、当該店舗情報の登録、共同購入対象商品情報の登録と外部への発信、それを受けた消費者が実際購入した購入商品情報（共同購入商品等の購入データ）の管理、共同購入商品等の販売状況を監視し、購入商品情報の更新と発信、決済データの生成、金融機関への請求データの発信までを一環して行うので、リアル店舗での共同購入の仕組みを容易に導入することができる。
【００１１】
さらに、本発明の共同購入管理サーバは、以下の機能を備えることができる。
前記共同購入管理サーバは、消費者が携帯する消費者携帯端末の位置情報を検知する手段を備え、前記店舗情報登録部が受付ける前記店舗情報は、前記店舗の位置情報を含み、前記共同購入情報発信部または前記購入状況監視部が発信する前記商品またはサービスの情報を、前記店舗の位置情報と前記消費者携帯端末の位置情報に基づいて段階的に前記消費者携帯端末に発信する。
【００１２】
上記発明によれば、共同購入管理サーバは、消費者が携帯する携帯端末の位置を検出する手段を有し（典型的には、携帯電話機等に備えられたＧＰＳ機能を利用する）、消費者がその店舗あるいは商店街等に近づくにつれて、共同購入に関するより詳しい情報を段階的に送信する。これによって、消費者は、その店舗や商店街等に近づけば近づくほど有用な情報が得られるので、実際に行ってみようという気分が高まり、店舗や商店街等とっては、リアル・ショッピングの特色でもある買い周りを促進することができる。
【００１３】
さらに、本発明の共同購入管理サーバは、以下の機能も備えることができる。
前記共同購入情報発信部は、前記店舗が属する地域内の一又は複数の所定の場所の位置情報を記憶し、前記消費者携帯端末の位置情報が前記所定の場所の位置情報の近傍にあるときは、前記共同購入情報発信部または前記購入状況監視部は、前記所定の場所から目視できるあらかじめ定められた店舗の情報を前記消費者携帯端末に発信する。
【００１４】
上記発明によれば、店舗が属する地域や商店街等の中に所定の位置をあらかじめ定めておき、消費者がその所定の位置近傍（例えば数メートル以内）に来たときに、その位置から見えるあらかじめ定めた店舗の情報や共同購入の情報をまとめて発信することができる。このことによって、消費者は、自分の位置から見える範囲のごく真近の店舗内部の情報が一覧的に判るのでそれらの店舗に立ち寄ることが抵抗なく行える。このとき消費者は、携帯端末上で商店街のホームページ等を開くだけでよく、例えば、携帯電話機のカメラをそれぞれの店舗に向ける必要などはない。
【００１５】
さらに、本発明の共同購入管理サーバの決済部は、以下の機能も備えることができる。
前記決済部は、消費者が購入時の共同購入対象商品の価格と共同購入期間が終了したときの販売数に基づく前記共同購入対象商品の価格を比較して、後者が前者が後者より高い場合には、その差額分を追加購入データとして前記金融機関のシステムに送信する。
【００１６】
上記発明によれば、本発明の共同購入管理サーバの決済部は、消費者が購入時は共同購入で最も価格が下がった場合の価格（最低価格）を支払い、共同購入期間終了後に最低価格に届かなかった場合のみ差額を追加購入分としてクレジットカード会社等の金融機関に請求する。金融機関は、後日、消費者に購入時の代金および追加購入として差額代金も請求することになる。もちろん、消費者は、このような仕組みを同意の上、商品等を購入するものとする。このことにより、消費者は共同購入対象商品を想定される最低価格をまずは支払って購入することができ、万一差額が発生したときのみ、その差額分を支払えばよいので共同購入で最低価格になるまで待ったり、購入をためらうことがなくなる。ネット・ショッピングと異なり、リアル・ショッピングでは消費者は長時間その店舗に留まって価格の変化をチェックすることができないので消費者の共同購入の購買意欲を高めることができる。
【００１７】
さらに、本発明の共同購入管理サーバの決済部は、以下の別の機能も備えることができる。
前記決済部は、消費者が購入した共同購入対象商品の価格を共同購入期間が終了したときの販売数に基づく価格を含む購入データを作成し、前記金融機関のシステムに送信する。
【００１８】
上記発明によれば、本発明の共同購入管理サーバの決済部は、共同購入期間終了時の価格を含む購入データを作成して、金融機関のシステムに送信する。つまり、最終価格が確定するまで金融機関には購入請求データは送信されないので、購入時には消費者が支払う代金は未定である。前記の決済部の処理と異なり、消費者は、共同購入の最終価格のみを請求されるので、あとから追加請求されるかもしれない、という不安が解消される。
【００１９】
上記の発明は、店舗側からみれば、購入時にクレジット会社等に請求できないので代金が直ぐには回収できないが、決済処理が一度ですむので、消費者に信用力がある場合には、有効である。
【００２０】
また、本発明は、共同購入管理サーバの発明としてだけでなく、以下のように、サーバと店舗端末を含んだ共同購入管理システム、またはコンピュータを共同購入管理サーバとして機能させるコンピュータ・プログラムの発明としてとらえることもでき、前述の共同購入管理サーバの発明と場合と同様な効果を得ることができる。
【００２１】
現実社会に店舗を有する店舗の情報を発信する店舗端末と、共同購入管理サーバがネットワークを介して接続されたシステムであって、前記店舗端末は、共同購入に参加する店舗情報を送信し、前記共同購入管理サーバは、前記店舗端末から受信した店舗情報を受付けて記憶する店舗情報登録部と、前記店舗にて販売される商品またはサービスの共同購入に関する情報を受付けて記憶する共同購入商品受付部と、前記受付けた商品またはサービスの共同購入に関する情報を通信媒体に発信する共同購入情報発信部と、前記共同購入の対象となる商品またはサービスに対して消費者からの購入情報を受付けて記憶する商品購入受付部と、前記共同購入情報発信部が発信した前記商品またはサービスの共同購入に関する情報を、所定のタイミングで更新して前記通信媒体に発信する購入状況監視部と、前記商品購入受付部によって購入を受付けられた商品またはサービスの決済データを生成し、前記消費者が前記購入情報で指定した金融機関のシステムに送信する決済部と、を備えたことを特徴とする、システム。
【００２２】
現実社会に店舗を有する店舗の情報を発信する店舗端末とネットワークを介して接続されたコンピュータを、前記店舗端末から共同購入に参加する店舗情報を受付けて記憶する店舗情報登録部と、前記店舗にて販売される商品またはサービスの共同購入に関する情報を受付けて記憶する共同購入商品受付部と、前記受付けた商品またはサービスの共同購入に関する情報を通信媒体に発信する共同購入情報発信部と、前記共同購入の対象となる商品またはサービスに対して消費者からの購入情報を受付けて記憶する商品購入受付部と、前記共同購入情報発信部が発信した前記商品またはサービスの共同購入に関する情報を、所定のタイミングで更新して前記通信媒体に発信する購入状況監視部と、前記商品購入受付部によって購入を受付けられた商品またはサービスの決済データを生成し、前記消費者が前記購入情報で指定した金融機関のシステムに送信する決済部として、機能させることを特徴とする、コンピュータ・プログラム。
【発明の効果】
【００２３】
本発明によれば、ネット上の共同購入の仕組みを、リアル店舗へ商品販売活動に融合させ、リアル店舗に消費者を呼び込こむことで、商店街等の活性化や地域の活性化に役立たせることとができる。
【図面の簡単な説明】
【００２４】
【図１】本発明の実施形態に係る共同購入管理サーバ１０の機能ブロックを示す図である。
【図２】本発明の実施形態に係る店舗情報及び共同購入商品情報を示す図である。
【図３】本発明の実施形態に係る購入者情報及び購入商品情報を示す図である。
【図４】本発明の実施形態に係る共同購入商品受付部１３の処理を示すフロー図である。
【図５】本発明の実施形態に係る商品購入受付部１５の処理を示すフロー図である。
【図６】本発明の実施形態に係る購入状況監視部１６の処理を示すフロー図である。
【図７】本発明の実施形態に係る共同購入対象店舗の発信情報の一例を示す図である。
【図８】本発明の実施形態に係る共同購入対象の発信情報の別の例を示す図である。
【図９】本発明の実施形態に係る決済部１７の一つの処理を示す図である。
【発明を実施するための形態】
【００２５】
以下、図面を参照して、本発明を実施するための形態（以下、実施形態）について詳細に説明する。なお、実施形態の説明の全体を通して同じ要素には同じ番号を付している。
【００２６】
図１は、本発明の実施形態に係る共同購入管理システム１の機能ブロックを示す図である。本システムにおいて、共同購入管理サーバ１０は、ネットワーク２０を介して、店舗端末３０と消費者携帯端末４０とに接続される。共同購入管理サーバ１０は、ＣＰＵ(Central Processing Unit)、メモリ（ＲＡＭ，ＲＯＭ）、ハードティスク等の記憶装置、ＣＲＴや液晶ディスプレイ等の表示装置、キーボードやマウス等の入力装置、及び通信インターフェースを含む一般的なコンピュータであってよい。図示するように、本実施形態の共同購入管理サーバ１０は、制御部１１、店舗情報登録部１２、共同購入商品受付部１３、共同購入情報発信部１４、商品購入受付部１５、購入状況監視部１６、決済部１７とデータベース（以下、ＤＢ）である店舗ＤＢ１８Ａ、消費者ＤＢ１８Ｂ、通信部１９の機能ブロックから構成される。
【００２７】
上記の機能構成は、あくまで一例であり、一つの機能部を更に分割したり、複数の機能部をまとめて一つの機能部として構成してもよい。データベースについても同様である。各機能部は、典型的には、メモリや記憶装置に格納されたコンピュータ・プログラムが読み出され、ＣＰＵで実行され、実行されたプログラムが記憶装置に格納されたＤＢから必要なデータを読み書きし、場合によっては、その他関連するハードウェア（例えば、入出力装置や通信インターフェース装置）を制御することによって実現される。
【００２８】
制御部１１は、各機能部のプログラムを読み出したり、ＣＡＬＬすることにより各機能部の実行を制御する。通信部１９は、通信インターフェースとなるハードウェアを含み、ネットワーク２０を介して、本サーバと店舗端末３０や消費者携帯端末４０との通信を制御する。
【００２９】
店舗情報登録部１２は、店舗端末３０から受信した、商店街等の店舗情報をあらかじめ店舗ＤＢ１８Ａに登録する機能を持つ。店舗情報は、後述するように、本共同購入システムに参加する店舗名や住所、店舗の位置情報、所属する商店街名などを記録したテーブルで構成される。共同購入商品受付部１３は、登録された上記の店舗端末３０から共同購入対象商品として販売する商品、サービスの情報（以下、共同購入商品情報）を受付けて記憶する機能を持つ。共同購入商品情報とは、本共同購入システムの対象となる商品ＩＤ、商品名や、販売期間、割引価格の情報を記憶したテーブルである。共同購入商品情報は、店舗ＤＢ１８Ａ上の店舗情報と紐づけされ、店舗ＤＢ１８Ａ上に格納される。
【００３０】
共同購入情報発信部１４は、共同購入商品受付部１３で登録された共同購入商品情報を、それを提供する店舗情報と共に、外部の通信媒体に情報発信する機能部である。情報発信の手段としては、商店街のホームページ等にアップロードする方法、登録された消費者にダイレクトメールを発信する方法、店舗前や商店街入口、近隣の商業施設、駅等に設置された広告パネルやデジタル・サイネージに発信する方法等、様々な方法があるが、共同購入情報発信部１４は、それらの一または複数の方法に対応できる手段をもつことができる。また、共同購入情報発信部１４は、後述するように、消費者の位置（消費者の携帯端末の位置情報）によって、表示する内容や情報の量を変化させることができる。消費者の携帯端末の位置情報は、共同購入情報発信部１４が、ＧＰＳ（Global Positioning System）付の携帯電話機やＰＨＳ（Personal
Handy-phone System）の基地局の位置情報を取得すること等によって得られる。
【００３１】
商品購入受付部１５は、消費者が共同購入対象商品等を実際に購入する場合に、その消費者（購入者）の情報（住所氏名などの消費者個人情報や代金支払い方法等）と購入品の情報（商品ＩＤ、割引価格情報等）を、消費者ＤＢ１８Ｂに格納された購入者情報と購入商品情報にそれぞれ記憶させる役目を果たす。購入者情報と購入商品情報は、任意のテーブル形式でＤＢに保存され、購入者と購入商品が紐付けされる限り、分離してＤＢに格納しても、まとめてひとつのＤＢに格納してもどちらでもよい。
【００３２】
購入状況監視部１６は、定められた共同購入対象期間中、その対象製品の購入状況（販売状況）をモニタする。すなわち、購入が発生するたびに、または所定の間隔で、対象商品の購入商品情報を読み出し、最新の購入者数や商品等の購入数（２つ総じて単に販売数と呼ぶ）を読み出し集計する。そして、集計した販売数と、あらかじめ登録されている共同購入商品情報とに基づいて現在の割引価格を決定する。例えば、販売数が１〜１０までは２００円、１１〜４９までは１００円、５０以上は８０円として登録されている商品の販売数が現在１５であれば、割引価格は１００円となり、さきに共同購入情報発信部１４が発信した共同購入商品情報を更新する。また、購入状況監視部１６も、消費者携帯端末４０の位置情報を取得することによって、それに基づいて更新情報を変化させることができる。例えば、近隣にいる消費者に、共同購入販売期間の終了時刻や、タイムセールスの終了時間の情報を付加したりすることもできる。なお、購入状況監視部１６と共同購入情報発信部１４は、情報発信の共通機能を持つため一つに統合してもよい。
【００３３】
決済部１７は、消費者が共同購入対象商品を購入した際に、商品の価格の支払い決済を行う。共同購入の価格を決定する方法は、購入時にその時点の販売数または購入者数によって価格が決定する場合と、購入時には最終価格を決めずに共同購入期間終了時に終了時点の販売数（通常は、購入者数または商品等の購入数であり、あらかじめどちらかに選択される）によって最終価格を決定する場合とが考えられる。前者の場合は、ある消費者にとっては購入時点で最終価格が決定するので、通常の商品購入と同様にその時点の金額で決済すればよいが、後者の場合には、購入時点では最終価格が決定しない。その消費者が購入した後も、他の消費者によって販売数が増えれば増えるほどその消費者が購入した時点よりも価格が下がる可能性がある。そのため、購入時点では、店舗側は、価格の支払いをせずに後日最終価格が決定した時点で請求するか、購入時には仮の金額を支払ってもらい、後に差額が生じた場合には、清算することが必要である。本実施形態の決済部１７は、様々な決済方法に対応できるものとするが、後述するように、購入時点ではあらかじめ定められた最低価格（すなわち、最も大量に売れたと仮定した場合の価格）を支払ってもらい、のちに価格が最低価格に届かなかった場合にのみ、差額を購入者に追加請求することができる。逆に、購入時にはその時点の販売数に応じた価格を支払ってもらい、その後価格が下がった場合には、差額を返金することもできる。返金するより追加請求するほうがシステム上は煩雑にならないが、消費者にとっては追加請求されることは抵抗があるので、どちらも消費者が選択できるようにしておくほうがよい。また、差額が発生した場合、返金する代わりに、次回来店時の支払に充当されるようにシステム上で管理されてもよい。もちろん、購入時には代金をもらわず、最終価格が決定した時点ではじめて請求することもできるが、消費者の信用力が必要で、店舗側にとっては入金が遅れるという問題は残る。
【００３４】
図２は、本発明の実施形態に係る店舗情報及び共同購入商品情報を示す図である。店舗情報は、図２（ａ）に示すような、店舗ＩＤ，店舗名，取扱商品，店舗住所，店舗位置情報，所属商店街ＩＤ等、共同購入販売に参加する店舗の情報を含んだテーブルである。テーブルの形式は任意である。このうち、店舗位置情報は、ＧＰＳから取得した東経、緯度、および高度の情報であってよいし、店舗の地図データを掲載しその地図データから得られる位置情報であってもよい。店舗情報は、各店舗の端末からデータを共同購入管理サーバに送信してもよいし、店舗端末がない店舗のために商店街組合等の共有端末からデータを送信してもよい。もちろん、登録用紙に記入したものを持参してもらい、サービス提供者の端末からオペレータが入力してもよい。以上、いずれの端末も図１では店舗端末３０として表している。
【００３５】
共同購入商品情報は、図２（ｂ）に示すような共同購入の対象となる商品の情報と販売情報を集めたテーブルである。テーブルの形式は任意である。商品情報には、商品ＩＤ、商品名が含まれ、販売情報には、共同購入の販売期間，商品の取扱数（在庫数），価格情報，現在の購入者数および購入数，現在価格，残り取扱数（取扱数−購入数）等が含まれる。価格情報には、共同購入開始時のスタート価格とスタート価格が適用となる販売数の条件であるスタート価格数が含まれ、同様に、少なくとも最終価格（最低価格）とそれに必要な最終価格数が含まれる。スタート価格と最終価格の間に、割引価格１や割引価格１数のように、複数の割引価格と対応する販売数を段階的に決めて配置してもよい。また、付加データとして、商品宣伝のために発信する共同購入商品情報に付加するメッセージや写真などを追加することができる。もちろん、商品自体の写真やより詳細な情報を含んだページへのリンク等を付加してもよい。また、後述するように、消費者携帯端末の位置情報と店舗の位置情報をもとに、発信する情報に段階的に変化をもたせるようにテーブルを構成してもよい。例えば、商店街等から離れている消費者には、商店街全体のイベントやセールス情報を発信し、商店街近傍にいる消費者には当日限りの共同購入情報を、店舗に近い消費者には、実際に店舗に呼び込むための特別な情報を配信する。すなわち、消費者が店舗に近づけば近づくほど有用な情報を発信するようにして、リアル店舗での消費活動を促すようにすることが好ましい。
【００３６】
図３は、本発明の実施形態に係る店舗情報及び共同購入商品情報を示す図である。購入者情報は、図３（ａ）に示すように、購入者のＩＤ（ユーザＩＤ），住所，氏名，電話番号，生年月日等の個人情報や、決済のためのクレジット番号や銀行の口座情報等を消費者毎に記録したテーブルである。テーブルの形式は任意である。このような情報は、消費者が初めてその商店街等で買い物をしたときに消費者が開示できる範囲で許諾を受けてデータベースに登録する。もちろん、携帯電話機やノートパソコンなどの消費者携帯端末４０や消費者の自宅のパソコン等から商店街等のホームページにアクセスし、消費者が直接登録してもよい。もっとも、購入時に購入価格が決定し現金で決済が行われる場合は、住所・氏名等の個人情報の開示は必須ではない。すなわち、購入時の販売数に対応する価格で決済するからである。ただし、この場合、購入者は、購入後に価格が下がっても、追加割引等のメリットは享受することはできない。なお、現金決済の場合でも共同購入商品情報のテーブルにある現在購入者数や現在購入数は更新されることが必要である。
【００３７】
購入商品情報は、図３（ｂ）に示すように、消費者（購入者）が購入した商品のＩＤ，購入日時，購入店名，購入商品名，購入価格，決済日時（共同購入期間終了日時），決済価格（共同購入期間終了時に確定した価格）を商品毎に記録したテーブルである。テーブルの形式は問わない。ここで「購入価格」とは、購入時に消費者が支払った価格（請求のみで実際の支払いは後日の場合でもよい）である。その後、販売数が増えさらに価格が下がった場合には差額を調整できるように、「購入価格」を想定される最低価格（共同購入で最も大量に売れた場合の価格）にセットしておくと、その後、最低価格に届かなかった場合に、差額を追加請求できるようにする。逆に、「購入価格」を購入時点の販売数に応じた価格にセットしておき、その後価格が下がった場合には、差額を返金するようにすることもできる。
【００３８】
図４は、本発明の実施形態に係る共同購入商品受付部１３の処理を示すフロー図である。ここで、商品購入とは消費者が店舗等で商品を受け取る代わりに代金を支払う、あるいは後日支払うことを同意することを意味する。
【００３９】
共同購入商品受付部１３は、まずステップＳ１０において、店舗端末３０から共同購入対象商品の登録データを受付ける。登録データには、図２（ｂ）で示したような共同購入商品情報が含まれる。
【００４０】
次に、共同購入商品受付部１３は、現在の日時が登録データに含まれる販売期間、すなわち共同購入の対象期間を過ぎてないかチェックする。過ぎている場合は（ステップＳ１１；Ｎｏ）、しかるべきエラーメッセージを発し、処理を終了する。販売期間が過ぎていない場合は（ステップＳ１１；Ｙｅｓ）、ステップＳ１２に処理を移す。
【００４１】
ステップＳ１２においては、共同購入商品受付部１３は、対象商品が新規かどうか判断する。具体的には、店舗ＤＢ１８Ａから共同購入商品情報テーブルを読み出し、すでに登録されている商品ＩＤが存在していなければ（ステップＳ１２；Ｙｅｓ）新規登録商品と判断する。商品ＩＤが存在する場合は（ステップＳ１２；Ｎｏ）は、さらにステップＳ１３において、その商品を登録した販売店名（または店舗ＩＤ）をチェックし、販売店が同じであれば（ステップＳ１３；Ｙｅｓ）、既存商品の更新であると判断し、ステップＳ１５に移り、既存商品として商品情報を更新する。販売店が異なる場合は（ステップＳ１３；Ｎｏ）、新規の商品としてステップＳ１４に移り、商品情報を新既登録する。商品ＩＤが同じでも販売店が異なれば、販売条件（販売期間，価格，数量等）が異なるので、新規の商品として登録する。その場合、過去に登録された同じ商品の情報を注意喚起として店舗端末３０に表示してもよい。また、また同じ商品の販売期間が重なり、その他の条件が同じ場合には両者のデータをマージするようにしてもよい。この場合は、一つの商品等に販売店が複数登録される。
【００４２】
なお、ここでは図示していないが、共同購入商品受付部１３が商品を登録し処理を終了した後は、共同購入情報発信部１４が、登録された共同購入商品情報を外部の通信媒体に発信する。外部の通信媒体とは、店舗や商店街のホームページや消費者へのダイレクトメール、広告パネルやディジタル・サイネージなどが考えられるが、それらへの情報発信手段はいずれも既存技術を用いて実現できる。
【００４３】
図５は、本発明の実施形態に係る商品購入受付部１５の処理を示すフロー図である。ここでの商品購入は、共同購入商品の情報をなんらかのかたちで知った消費者が実際にそのリアル店舗に赴き、対象製品をクレジットカードで購入する場面を想定している。基本的には、支払いがデビットカードでも同様である。
【００４４】
まず、商品購入受付部１５は、ステップＳ２０において、店舗端末３０またはカード読み取り機から入力されたクレジットカードの情報をもとにクレジットカードの与信照会をする。その結果、与信ＯＫの場合は（ステップＳ２１；Ｙｅｓ）の場合は次の処理に移るが、Ｎｏの場合は、その旨エラーメッセージを送信する。
【００４５】
クレジットカードの与信が正常に終了すると、商品購入受付部１５は、この辞実施例では、最終価格を購入価格にセットする。最終価格とは、その商品の共同購入における最も低い価格であり、通常は、最もその商品が売れた場合の価格（最低価格）である。購入価格とは、消費者がその場でひとまず支払うあるいは支払う意思を確約した価格である。
【００４６】
購入価格が決まると、商品購入受付部１５は、ステップＳ２２において、最終価格を購入価格とした仮購入データを作成し（ステップＳ２３）、その仮購入データを、クレジットカード会社の金融機関のシステムに正規の請求データとして送信する（ステップＳ２４）。ついで、商品購入受付部１５は、消費者ＤＢ１８Ｂ上の共同購入情報を更新する（ステップＳ２５）。すなわち、該当商品の現在購入者数を１増加させ、現在購入数をその消費者が購入した数だけ増加させる。商品購入受付部１５の処理は以上で終了するが、後日、クレジットカード会社は、この送信されたデータに基づいて、店舗側に購入価格の立替払いを行う。そして、クレジットカード会社では、クレジットカードの締め日までの消費者が使用したカードの購入データをまとめて、消費者側に通常の請求処理を行う。本実施例では、クレジットカード会社側では特に商品購入受付部１５が送信した仮購入データが共同購入商品であるか否かを知る必要はない。
【００４７】
なお、図５のステップＳ２２の例では、最終価格（最低価格）を購入価格にセットしたが、現時点（購入時）での価格（現在価格）を購入価格にセットするようにしてもよい。これは、消費者がその後の販売数の増加による価格の低下によるメリットを放棄した場合に有効である。すなわち、ステップＳ２２においては、購入価格は最低価格にセットされているのでこれ以上価格が下がることはなく、購入数が最低価格ラインまで届かない場合は、逆に差額を追加請求されることを消費者が嫌うことがあるからである。この場合には、購入時の価格が最終価格となり、以後の差額調整は行われないことになるので、ステップＳ２３、Ｓ２４で処理するのは仮購入データではなく最終購入データとなる。なお。仮購入データの場合は、後の処理のために、フラグをデータ内に付加しておく。
【００４８】
図６は、本発明の実施形態に係る購入状況監視部１６の処理を示すフロー図である。購入状況監視部１６は、所定のタイミングで常に共同購入対象製品の販売状況を監視する機能を持っている。
【００４９】
購入状況監視部１６は、まず、店舗ＤＢ１８Ａから共同購入商品情報を読み出す（ステップＳ３０）。読み出すタイミングは、あらかじめ定められた時間毎であってもよいし、商品購入受付部１５が共同購入商品情報を更新したイベントを検知したときでもよい。次に、購入状況監視部１６は、ステップＳ３１において、読み出した共同購入商品情報の中の現在価格、残り取扱数を同じ共同購入商品情報の価格情報に基づいて更新する。さらに、更新された付加データがあれば（ステップＳ３２；Ｙｅｓ）、その更新された付加データをマージして前述の通信媒体に送信する（ステップＳ３４）。付加データの更新は、販売開始時だけでなく、販売中も随時、店舗側から更新できるものとする。例えば、売れ行きが芳しくないときに、販促メッセージを付加したいような場合である。また、ある商品が予想外に早く売り切れになりそうな場合にもその旨をメッセージとして提供することによって、近くにいる消費者に購買機会を失わないようにすることもできる。このため付加メッセージも購入状況監視部１６による常時監視する。以上の処理（ステップＳ３０〜Ｓ３４）を終了条件（例えば、購入対象商品をすべて処理した場合や、商店街全体での共同購入販売期間が終了した場合）に達するまで繰り返す（ステップＳ３５）。
【００５０】
＜情報発信画面例＞
図７は、本発明の実施形態に係る共同購入対象店舗の発信情報の一例を示す図である。図示するように、店舗名、店舗の紹介記事等と共に、共同購入対象商品の情報が一覧できるようにする。すなわち、店舗ごとに共同購入対象商品の商品名，販売期間（共同購入対象期間）の日時，商品の取扱数（在庫数），スタート価格とその対象数量（かっこ内），最終価格とその対象数量（かっこ内）が少なくとも表示される。特に図示していないが、スタート価格と最終価格以外にも段階的な割引価格を設定する場合にもそれらの価格と数量を掲載する。また、商店街へのアクセスや他のキャンペーン情報、各店舗の地図等が表示されてもよい。
【００５１】
前述したように、共同購入情報発信部１４は、商店街等の共同購入の情報を知らしめるため数々の通信媒体に送信する。しかし、リアル店舗の情報発信（広告）には、実際に消費者にその店舗まで足を運んでもらう必要があるため通常のネット販売とは異なる情報発信方法が必要である。
【００５２】
図８は、このための本発明の実施形態に係る共同購入対象の発信情報の別の例を示す図である。具体的には、地図情報を利用した商店街での共同購入のキャンペーンをＷｅｂページ上に発信した場合の画面の一例である。
【００５３】
図８の左側の図では、消費者の携帯端末（たとえば、ＧＰＳ付きの携帯電話機）における画面の一例が示されている。この図では、人物のアニメーションの位置が消費者のいる現在位置を示している。この消費者は、現在ＡＢＣ商店街の近くにおり、広告やメール等の何らかのトリガで携帯画面を開き、この商店街の各店舗で共同購入のセールスが行われていることを知る。ただし、この時点では対象店舗数は３０店舗であること以外、詳しい情報は示されていない。
【００５４】
その後、消費者は、商店街の入口付近で再度、携帯画面を開いたとする。そのときの画面が図８の右側の図である。この図でわかるように、左の画面では表示されなかった商店街の情報がより詳しく表示される。また、当初は見えなかった店舗も表示されている。このようなことは、消費者の携帯端末のＧＰＳ等からの位置情報をもとに、共同購入情報発信部１４または購入状況監視部１６が、その消費者の興味を引くように（呼び込むように）、共同購入対象店舗や商品情報を段階的に送信することによって実現できる。
【００５５】
例えば、より具体的には、商店街の地図と消費者の携帯端末の位置から見える範囲の店舗と商品情報を携帯画面に表示する。同じ商店街であっても消費者の現在位置からは見えないと想定される店舗の情報はこの時点では表示されない。しかし、消費者がその表示されなかった店舗により近づくとその店舗の情報が表示され、逆に遠ざかるとその店舗の情報が徐々に消えていくようにする。これは、店舗ＤＢ１８Ａには各店舗の位置情報が登録されているので、消費者の携帯端末の位置情報と店舗の位置情報との水平距離と、発信する情報を対応付けたテーブルを店舗ＤＢ１８Ａに持つことにより実現できる。
【００５６】
あるいは、商店街等の所定の位置にあらかじめ何点かポイントを定義しておき、消費者がそのポイント近傍（例えば５ｍ以内とか）に来たときに、はじめてそこから見える店舗（あらかじめポイントごとに定義しておく）の情報を発信する。こうすることで単に水平距離にもとづいて情報発信することに比べて、ビルなどの障害物のあるなし等を考慮した「現実にそこから見える店舗」のみの情報を発信することで消費者がその店舗に行くことの動機付けを行う。あるいは、そのポイントからは直接見えなくとも、もう少し行けば見える店舗の存在自体を示す情報を付加してもよい。例えば、あるポイントでは、そのポイントから見える店舗の名前やそのセールスポイント以外にも、そのポイントからは見えないが、近くの観光名所やパワースポット等の情報を追加で表示するといったことである。ただし、最初からすべての情報を発信するのでなく、そのスポットに行ってはじめて見える情報も残しておく。いずれにしても、消費者がその場に入ってみたいという情報を段階的に表示することが必要である。そしてその情報を、共同購入と関連付ける。例えば、指定したスポットや店舗を数箇所立ち寄れば、さらに共同購入の特典を付加する、といったことである。
【００５７】
このようなシステムは、消費者にとっては、ネット・ショッピングと異なり、現実に「その場」に行くことにより、より有用」な情報が増えることになるので、店舗に人を呼びこむための方法として有効である。しかも、共同購入による割引価格のメリットが受けられるため、消費者はその近辺の店舗で当初予定していなかった買い物をしてくれる確率、すなわち、その場で見たものを衝動的に買ってしまう「衝動買い」や、欲しいものを忘れていたことに気付かされたり、新たな情報を理解して商品に惹かれて購入する「気付き買い」の確率が高まり、「リアル」な店舗で買い回りを促進するためのツールとしても本発明は有効である。
【００５８】
このように、本発明の共同購入のシステムは、多くの人を商店街等に呼び込めば呼び込むほどその効果が増大し、店舗、消費者共にメリットがあるので、消費者の口コミや店舗間の販売促進のための協力が推進されることが期待できる。そして、商店街等の近くにより人を引きつけ、地域の活性化に繋がる。
【００５９】
＜共同購入における決済方法＞
すでにいくつか部分的には述べたが、共同購入における決済方法について、ここで再度まとめて議論する。共同購入では、購入時の販売数量に基づいた価格を支払う場合と、共同購入期間中の購入後の最終販売数量にもとづいた最終価格で支払いを行う場合とが考えられる。前者の場合のみだと、消費者は最低価格に達するまで購入を待つことが想定され、ネット・ショッピングと異なり、リアル・ショッピングの場合では、消費者は長期間その場で留まることはできないので（逆にそれを誘導するという考え方もあるが）、なかなか最低価格では購入しにくい、といった問題がある。
【００６０】
そのため、以下に示す決済処理は、いったん購入時に仮決済し、その後、価格が変動したときにはその差額を追加処理するためのものである。以下、具体的にフロー図で説明する。
【００６１】
図９は、本発明の実施形態に係る決済部１７の一つの処理を示す図である。決済部１７は、まずステップＳ４０において、店舗ＤＢ１８Ａから共同購入情報を読み込む。そして、読み込んだ情報中に販売期間終了（共同購入期間終了）の商品データがあるかどうかを判断する（ステップＳ４１）。販売期間終了のものがなければ（ステップＳ４１；Ｎｏ）、ステップＳ４７へ処理を移す。
【００６２】
販売期間中であれば（ステップＳ４１；Ｙｅｓ）、その商品の購入商品情報（購入データ）を読み込み（ステップＳ４２）、購入者がある場合は（ステップＳ４３；Ｙｅｓ）、現在価格と最終価格を比較し、現在価格が最終価格より高い場合は（ステップＳ４４；Ｙｅｓ）、現在価格から最終価格を減算した価格（差額）を購入価格とし、その差額を追加請求するための追加購入データを新たに作成する（ステップＳ４５）。そして、ステップＳ４４とステップＳ４５の処理をその商品の購入者全員に対しておこなう（ステップＳ４６）。
【００６３】
ステップＳ４３で購入者がない場合（ステップＳ４３；Ｎｏ）、またはステップＳ４６で別の購入者がいない場合は（ステップＳ４６；Ｎｏ）、次の未処理の共同購入対象商品がなくなるまで、ステップＳ４１〜ステップＳ４６の処理を繰り返す（ステップＳ４８）。
【００６４】
決済部１７は、最後に、購入者ごとに追加購入データをクレジット会社等の金融機関のシステムに送信する（ステップＳ４８）。追加購入データがない場合は、すなわち、現在価格が最終価格であるということで、購入者は最終価格をすでに購入時に支払っているので（図５ステップＳ２２参照）、差額調整は必要なく追加購入データは送信しない。
【００６５】
上記実施例では、購入時に購入者は、最低価格でいったん購入代金を支払い、共同購入終了時に最低価格に相当する販売量に届かなかったために差額が発生した場合にのみ、その差額を追加で支払う処理について示した。
【００６６】
別の決済処理方法としては、特に図示していないが、購入時には価格は決定せず（購入者は購入時には代金を支払わず、購入確約の意思のみを示して必要なデータを登録して商品を受け取る）、その後、共同購入期間終了後に最終価格が決定した時点ではじめて決済部１７が、購入データを作成し、クレジット会社に送信する決済方法もある。この場合は、最初の購入価格がゼロ円、追加購入価格が最終価格となる。
【００６７】
上記の別の決済方法は、一種の信用買いであるため、消費者によほど信用力がないと店舗側としては採用しずらい。また、共同購入のシステムでできるだけ多くの人を地域に集めたいという趣旨には多少そぐわない。そこで、以下に示す「通常の決済方法」もある。
【００６８】
「通常の決済方法」では、購入時に、その時点での販売数量にもとづいた価格で取引し、その後、差額が発生した場合にもいっさい差額の調整を行わないものである。これは購入後の価格低下の楽しみはなくなるが、支払い代金を購入時に確定させたい思う購入者もいるためにオプションとしては必要である。なお、上記の決済方法はすべて、共同購入の割引は価格割引の提供で行うことを前提にしたが、割引の方法は、価格割引だけでなく、買物券や地域通貨の提供であってもよい。いずれにしても本発明では、決済部１７の処理ロジックを多少変更するだけで様々な決済方法に対応できる。
【００６９】
以上、実施形態を用いて本発明を説明したが、本発明の技術的範囲は上記実施形態に記載の範囲には限定されないことは言うまでもない。上記実施形態に、多様な変更または改良を加えることが可能であることが当業者に明らかである。またその様な変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。
【符号の説明】
【００７０】
１０ 共同購入管理サーバ
１１ 制御部
１２ 店舗情報登録部
１３ 共同購入商品受付部
１４ 共同購入情報発信部
１５ 商品購入受付部
１６ 購入状況監視部
１７ 決済部
１８Ａ 店舗ＤＢ
１８Ｂ 消費者ＤＢ
１９ 通信部
２０ ネットワーク
３０ 店舗端末
４０ 消費者携帯端末
【特許請求の範囲】
【請求項１】
現実社会に店舗を有する店舗情報を発信する店舗端末とネットワークを介して接続された共同購入管理サーバであって、
前記店舗端末から共同購入に参加する店舗の情報を受付けて記憶する店舗情報登録部と、
前記店舗にて販売される商品またはサービスの共同購入に関する情報を受付けて記憶する共同購入商品受付部と、
前記受付けた商品またはサービスの共同購入に関する情報を通信媒体に発信する共同購入情報発信部と、
前記共同購入の対象となる商品またはサービスに対して消費者からの購入情報を受付けて記憶する商品購入受付部と、
前記共同購入情報発信部が発信した前記商品またはサービスの共同購入に関する情報を、所定のタイミングで更新して前記通信媒体に発信する購入状況監視部と、
前記商品購入受付部によって購入を受付けられた商品またはサービスの決済データを生成し、前記消費者が前記購入情報で指定した金融機関のシステムに送信する決済部と、
を備えたことを特徴とする、共同購入管理サーバ。
【請求項２】
前記共同購入管理サーバは、消費者が携帯する消費者携帯端末の位置情報を検知する手段を備え、
前記店舗情報登録部が受付ける前記店舗情報は、前記店舗の位置情報を含み、前記共同購入情報発信部または前記購入状況監視部が発信する前記商品またはサービスの情報を、前記店舗の位置情報と前記消費者携帯端末の位置情報に基づいて段階的に前記消費者携帯端末に発信する、
請求項１に記載の共同購入管理サーバ。
【請求項３】
前記共同購入情報発信部は、前記店舗が属する地域内の一又は複数の所定の場所の位置情報を記憶し、前記消費者携帯端末の位置情報が前記所定の場所の位置情報の近傍にあるときは、前記共同購入情報発信部または前記購入状況監視部は、前記所定の場所から目視できるあらかじめ定められた店舗の情報を前記消費者携帯端末に発信する、
請求項２に記載の共同購入管理サーバ。
【請求項４】
前記決済部は、消費者が購入時の共同購入対象商品の価格と共同購入期間が終了したときの販売量に基づく前記共同購入対象商品の価格を比較して、後者が前者が後者より高い場合には、その差額分を追加購入データとして前記金融機関のシステムに送信する、
請求項１に記載の共同購入管理サーバ。
【請求項５】
前記決済部は、消費者が購入した共同購入対象商品の価格を共同購入期間が終了したときの販売数に基づく価格を含む購入データを作成し、前記金融機関のシステムに送信する、
請求項１に記載の共同購入管理サーバ。
【請求項６】
現実社会に店舗を有する店舗の情報を発信する店舗端末と、共同購入管理サーバがネットワークを介して接続されたシステムであって、
前記店舗端末は、共同購入に参加する店舗情報を送信し、
前記共同購入管理サーバは、
前記店舗端末から受信した店舗情報を受付けて記憶する店舗情報登録部と、
前記店舗にて販売される商品またはサービスの共同購入に関する情報を受付けて記憶する共同購入商品受付部と、
前記受付けた商品またはサービスの共同購入に関する情報を通信媒体に発信する共同購入情報発信部と、
前記共同購入の対象となる商品またはサービスに対して消費者からの購入情報を受付けて記憶する商品購入受付部と、
前記共同購入情報発信部が発信した前記商品またはサービスの共同購入に関する情報を、所定のタイミングで更新して前記通信媒体に発信する購入状況監視部と、
前記商品購入受付部によって購入を受付けられた商品またはサービスの決済データを生成し、前記消費者が前記購入情報で指定した金融機関のシステムに送信する決済部と、
を備えたことを特徴とする、システム。
【請求項７】
現実社会に店舗を有する店舗の情報を発信する店舗端末とネットワークを介して接続されたコンピュータを、
前記店舗端末から共同購入に参加する店舗情報を受付けて記憶する店舗情報登部と、
前記店舗にて販売される商品またはサービスの共同購入に関する情報を受付けて記憶する共同購入商品受付部と、
前記受付けた商品またはサービスの共同購入に関する情報を通信媒体に発信する共同購入情報発信部と、
前記共同購入の対象となる商品またはサービスに対して消費者からの購入情報を受付けて記憶する商品購入受付部と、
前記共同購入情報発信部が発信した前記商品またはサービスの共同購入に関する情報を、所定のタイミングで更新して前記通信媒体に発信する購入状況監視部と、
前記商品購入受付部によって購入を受付けられた商品またはサービスの決済データを生成し、前記消費者が前記購入情報で指定した金融機関のシステムに送信する決済部として、
機能させることを特徴とする、コンピュータ・プログラム。
【請求項１】
現実社会に店舗を有する店舗情報を発信する店舗端末とネットワークを介して接続された共同購入管理サーバであって、
前記店舗端末から共同購入に参加する店舗の情報を受付けて記憶する店舗情報登録部と、
前記店舗にて販売される商品またはサービスの共同購入に関する情報を受付けて記憶する共同購入商品受付部と、
前記受付けた商品またはサービスの共同購入に関する情報を通信媒体に発信する共同購入情報発信部と、
前記共同購入の対象となる商品またはサービスに対して消費者からの購入情報を受付けて記憶する商品購入受付部と、
前記共同購入情報発信部が発信した前記商品またはサービスの共同購入に関する情報を、所定のタイミングで更新して前記通信媒体に発信する購入状況監視部と、
前記商品購入受付部によって購入を受付けられた商品またはサービスの決済データを生成し、前記消費者が前記購入情報で指定した金融機関のシステムに送信する決済部と、
を備えたことを特徴とする、共同購入管理サーバ。
【請求項２】
前記共同購入管理サーバは、消費者が携帯する消費者携帯端末の位置情報を検知する手段を備え、
前記店舗情報登録部が受付ける前記店舗情報は、前記店舗の位置情報を含み、前記共同購入情報発信部または前記購入状況監視部が発信する前記商品またはサービスの情報を、前記店舗の位置情報と前記消費者携帯端末の位置情報に基づいて段階的に前記消費者携帯端末に発信する、
請求項１に記載の共同購入管理サーバ。
【請求項３】
前記共同購入情報発信部は、前記店舗が属する地域内の一又は複数の所定の場所の位置情報を記憶し、前記消費者携帯端末の位置情報が前記所定の場所の位置情報の近傍にあるときは、前記共同購入情報発信部または前記購入状況監視部は、前記所定の場所から目視できるあらかじめ定められた店舗の情報を前記消費者携帯端末に発信する、
請求項２に記載の共同購入管理サーバ。
【請求項４】
前記決済部は、消費者が購入時の共同購入対象商品の価格と共同購入期間が終了したときの販売量に基づく前記共同購入対象商品の価格を比較して、後者が前者が後者より高い場合には、その差額分を追加購入データとして前記金融機関のシステムに送信する、
請求項１に記載の共同購入管理サーバ。
【請求項５】
前記決済部は、消費者が購入した共同購入対象商品の価格を共同購入期間が終了したときの販売数に基づく価格を含む購入データを作成し、前記金融機関のシステムに送信する、
請求項１に記載の共同購入管理サーバ。
【請求項６】
現実社会に店舗を有する店舗の情報を発信する店舗端末と、共同購入管理サーバがネットワークを介して接続されたシステムであって、
前記店舗端末は、共同購入に参加する店舗情報を送信し、
前記共同購入管理サーバは、
前記店舗端末から受信した店舗情報を受付けて記憶する店舗情報登録部と、
前記店舗にて販売される商品またはサービスの共同購入に関する情報を受付けて記憶する共同購入商品受付部と、
前記受付けた商品またはサービスの共同購入に関する情報を通信媒体に発信する共同購入情報発信部と、
前記共同購入の対象となる商品またはサービスに対して消費者からの購入情報を受付けて記憶する商品購入受付部と、
前記共同購入情報発信部が発信した前記商品またはサービスの共同購入に関する情報を、所定のタイミングで更新して前記通信媒体に発信する購入状況監視部と、
前記商品購入受付部によって購入を受付けられた商品またはサービスの決済データを生成し、前記消費者が前記購入情報で指定した金融機関のシステムに送信する決済部と、
を備えたことを特徴とする、システム。
【請求項７】
現実社会に店舗を有する店舗の情報を発信する店舗端末とネットワークを介して接続されたコンピュータを、
前記店舗端末から共同購入に参加する店舗情報を受付けて記憶する店舗情報登部と、
前記店舗にて販売される商品またはサービスの共同購入に関する情報を受付けて記憶する共同購入商品受付部と、
前記受付けた商品またはサービスの共同購入に関する情報を通信媒体に発信する共同購入情報発信部と、
前記共同購入の対象となる商品またはサービスに対して消費者からの購入情報を受付けて記憶する商品購入受付部と、
前記共同購入情報発信部が発信した前記商品またはサービスの共同購入に関する情報を、所定のタイミングで更新して前記通信媒体に発信する購入状況監視部と、
前記商品購入受付部によって購入を受付けられた商品またはサービスの決済データを生成し、前記消費者が前記購入情報で指定した金融機関のシステムに送信する決済部として、
機能させることを特徴とする、コンピュータ・プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【公開番号】特開２０１２−１０４０６１（Ｐ２０１２−１０４０６１Ａ）
【公開日】平成２４年５月３１日（２０１２．５．３１）
【国際特許分類】
【出願番号】特願２０１０−２５４２１９（Ｐ２０１０−２５４２１９）
【出願日】平成２２年１１月１２日（２０１０．１１．１２）
【出願人】（３０２０６４７６２）株式会社日本総合研究所 (367)
【公開日】平成２４年５月３１日（２０１２．５．３１）
【国際特許分類】
【出願日】平成２２年１１月１２日（２０１０．１１．１２）
【出願人】（３０２０６４７６２）株式会社日本総合研究所 (367)
[ Back to top ]