特許 7161088 取引支援システム、中継事業体サーバ、取引支援方法及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2022-10-18

(45)【発行日】2022-10-26

(54)【発明の名称】取引支援システム、中継事業体サーバ、取引支援方法及びプログラム

(51)【国際特許分類】

   G06Q 30/06 20120101AFI20221019BHJP

【ＦＩ】

G06Q30/06 312

G06Q30/06 310

G06Q30/06 304

【請求項の数】 14

(21)【出願番号】P 2018163150

(22)【出願日】2018-08-31

(65)【公開番号】P2020035326

(43)【公開日】2020-03-05

【審査請求日】2021-07-19

(73)【特許権者】

【識別番号】508258600

【氏名又は名称】株式会社インコントロ

(74)【代理人】

【識別番号】110002572

【氏名又は名称】弁理士法人平木国際特許事務所

(72)【発明者】

【氏名】末吉 一成

【審査官】松野 広一

(56)【参考文献】

【文献】特開２００３－３４６０１１（ＪＰ，Ａ）

【文献】特開２００７－２１９８７９（ＪＰ，Ａ）

【文献】特開２００３－０３０４８３（ＪＰ，Ａ）

【文献】特開２００５－３３２１４２（ＪＰ，Ａ）

【文献】特開２００６－１７１８２９（ＪＰ，Ａ）

【文献】特開２００２－０５６２２６（ＪＰ，Ａ）

【文献】特開２００３－１３２２２２（ＪＰ，Ａ）

【文献】特表２０１２－５０６０８６（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｑ １０／００－９９／００

(57)【特許請求の範囲】

【請求項1】

複数の商品／サービス買い手側会員端末と、複数の商品／サービス売り手側企業サーバと、前記買い手側会員端末と前記売り手側企業サーバとの中継を行う中継事業体サーバと、を有する取引支援システムであって、
前記中継事業体サーバは、
複数の前記買い手側会員端末の集団を形成するための条件として提示される商品／サービスのカテゴリと集団の成立条件とを含む集団参加の募集要項を複数の前記買い手側会員端末に対して送信し、
前記募集要項に同意する前記買い手側会員端末からの応募入力操作に基づいて前記買い手側会員端末の集団が形成され、前記応募入力操作の集計結果に基づいて、複数の前記売り手側企業サーバに第１の見積要求を行い、
複数の前記売り手側企業サーバから、前記カテゴリ内の商品／サービスの選択肢と販売条件とを含む前記第１の見積要求に沿った第１の見積情報を受信し、受信した前記第１の見積情報を前記集団に参加する複数の前記買い手側会員端末に送信し、
前記第１の見積情報を受信した複数の前記買い手側会員端末から、商品／サービスを特定した購入希望操作を受信し、前記購入希望操作に基づいて集計した商品／サービスと数量に基づいて、前記第１の見積要求に返信した前記売り手側企業サーバに第２の見積要求を行い、
前記売り手側企業サーバから、前記第２の見積要求に沿った第２の見積情報を受信し、受信した前記第２の見積情報を前記購入希望操作があった前記買い手側会員端末に送信し、
前記第２の見積情報に同意しない前記買い手側会員端末から、前記第２の見積要求の再見積要求を受信し、同意されなかった前記第２の見積情報を送信した前記売り手側企業サーバに前記再見積要求を行い、
前記売り手側企業サーバから、前記再見積要求に沿った再見積情報を受信し、受信した前記再見積情報を前記第２の見積情報に同意しなかった前記買い手側会員端末に送信し、
複数の前記買い手側会員端末が同意した前記第２の見積情報及び前記再見積情報に係る同一売り手側企業サーバの同一商品／サービスが同じ価格となるように調整し、
前記第２の見積情報及び前記再見積情報に同意した前記買い手側会員端末の集団と前記売り手側企業サーバとの間の取引を支援することを特徴とする取引支援システム。

【請求項2】

前記中継事業体サーバは、
前記集団中の前記複数の買い手側会員端末による見積要求と前記募集要項に同意した前記売り手側企業サーバによる見積要求と見積のやり取りを仲介することを特徴とする請求項１に記載の取引支援システム。

【請求項3】

前記中継事業体サーバは、複数の前記買い手側会員端末が同意した前記第２の見積情報及び前記再見積情報に係る同一売り手側企業サーバの同一商品／サービスが前記集団に含まれる複数の前記買い手端末にとって最も安価な価格となるように前記中継事業体サーバが前記売り手側企業サーバに対して調整を要求する請求項１又は２に記載の取引支援システム。

【請求項4】

前記買い手側会員端末の集団は指定口座への入金を以って、指定口座残高合計と前記売り手側企業サーバ毎に合計人数・合計額を示して前記第２の見積要求を行う請求項１から３のいずれか１項に記載の取引支援システム。

【請求項5】

前記集団の参加者が操作する前記買い手側会員端末が、前記第２の見積要求への返信である第２の見積情報を受信し、前記買い手側会員端末が前記第２の見積情報を承認する操作を行うことで仮予約、予約、確定、送金の順に取引を進める請求項３に記載の取引支援システム。

【請求項6】

前記集団の参加者が操作する前記買い手側会員端末が、集団見積を承認する操作が完了するまでは、さらなる集団見積又は取引の中止操作が可能である請求項１から５のいずれか１項に記載の取引支援システム。

【請求項7】

前記中継事業体サーバは、
前記売り手側企業サーバからの見積を、前記売り手側企業サーバ全体と前記買い手側会員端末毎にまとめ、かつ、前記買い手側会員端末毎に整理し、その両方を前記買い手側会員端末毎に送信して前記買い手側会員端末からの送金を促す請求項１から６のいずれか１項に記載の取引支援システム。

【請求項8】

前記中継事業体サーバは、
参加者である前記買い手側会員端末における所持者の購入意思確定を、指定口座入金後の集団見積に対する前記買い手側会員端末からの承認を以って行い、確定結果を売り手側企業サーバに通知し、前記買い手側会員端末から受渡結果通知を得た上で、指定口座に対して売り手側企業サーバの所持者への送金が指示され、送金を以って前記集団が解除される請求項１から７のいずれか１項に記載の取引支援システム。

【請求項9】

前記中継事業体サーバは、
参加者である前記買い手側会員端末による検討取り止めや退出の受付を行うための取りやめ操作を受信可能である請求項１から８のいずれか１項に記載の取引支援システム。

【請求項10】

前記第１の見積要求時、前記第２の見積要求時、及び前記再見積要求時には、前記買い手側会員の個人情報の少なくとも一部を前記売り手側企業サーバに送信しない請求項１から９のいずれか１項に記載の取引支援システム。

【請求項11】

複数の商品／サービス買い手側会員端末と、複数の商品／サービス売り手側企業サーバと、前記買い手側会員端末と前記売り手側企業サーバとの中継を行う中継事業体サーバと、を有する取引支援システムにおける中継事業体サーバであって、
複数の前記買い手側会員端末の集団を形成するための条件として提示される提供を要求する商品／サービスのカテゴリと集団の成立条件とを含む集団参加の募集要項 を複数の前記買い手側会員端末に対して送信し、
前記募集要項に同意する前記買い手側会員端末からの応募入力操作による基づいて前記買い手側会員端末の集団が形成され、前記応募入力操作の集計結果に基づいて、複数の前記売り手側企業サーバに第１の見積要求を行い、
前記売り手側企業サーバから、前記カテゴリ内の商品／サービスの選択肢と販売条件とを含む前記第１の見積要求に沿った第１の見積情報を受信し、受信した前記第１の見積情報を前記集団に参加する複数の前記買い手側会員端末に送信し、
前記第１の見積情報を受信した複数の前記買い手側会員端末から、商品／サービスを特定した購入希望操作を受信し、前記購入希望操作に基づいて集計した商品／サービスと数量に基づいて、前記第１の見積要求に返信した前記売り手側企業サーバに第２の見積要求を行い、
前記売り手側企業サーバから、前記第２の見積要求に沿った第２の見積情報を受信し、受信した前記第２の見積情報を前記購入希望操作があった前記買い手側会員端末に送信し、
前記第２の見積情報に同意しない前記買い手側会員端末から、前記第２の見積要求の再見積要求を受信し、同意されなかった前記第２の見積情報を送信した前記売り手側企業サーバに前記再見積要求を行い、
前記売り手側企業サーバから、前記再見積要求に沿った再見積情報を受信し、受信した前記再見積情報を前記第２の見積情報に同意しなかった前記買い手側会員端末に送信し、
複数の前記買い手側会員端末が同意した前記第２の見積情報及び前記再見積情報に係る同一売り手側企業サーバの同一商品／サービスが同じ価格となるように調整し、
前記第２の見積情報及び前記再見積情報に同意した前記買い手側会員端末の集団と前記売り手側企業サーバとの間の取引を支援することを特徴とする中継事業体サーバ。

【請求項12】

複数の商品／サービス買い手側会員端末と、複数の商品／サービス売り手側企業サーバと、前記買い手側会員端末と前記売り手側企業サーバとの中継を行う中継事業体サーバと、を有する取引支援システムにおける中継事業体サーバによる取引支援方法であって、
複数の前記買い手側会員端末の集団を形成するための条件として提示される提供を要求する商品／サービスのカテゴリと集団の成立条件とを含む集団参加の募集要項 を複数の前記買い手側会員端末に対して送信し、
前記募集要項に同意する前記買い手側会員端末からの応募入力操作に基づいて前記買い手側会員端末の集団が形成され、前記応募入力操作の集計結果に基づいて、複数の前記売り手側企業サーバに第１の見積要求を行い、
前記売り手側企業サーバから、前記カテゴリ内の商品／サービスの選択肢と販売条件とを含む前記第１の見積要求に沿った第１の見積情報を受信した場合に、受信した前記第１の見積情報を前記集団に参加する複数の前記買い手側会員端末に送信し、
前記第１の見積情報を受信した複数の前記買い手側会員端末から、商品／サービスを特定した購入希望操作を受信し、前記購入希望操作に基づいて集計した商品／サービスと数量に基づいて、前記第１の見積要求に返信した前記売り手側企業サーバに第２の見積要求を行い、
前記売り手側企業サーバから、前記第２の見積要求に沿った第２の見積情報を受信し、受信した前記第２の見積情報を前記購入希望操作があった前記買い手側会員端末に送信し、
前記第２の見積情報に同意しない前記買い手側会員端末から、前記第２の見積要求の再見積要求を受信し、同意されなかった前記第２の見積情報を送信した前記売り手側企業サーバに前記再見積要求を行い、
前記売り手側企業サーバから、前記再見積要求に沿った再見積情報を受信し、受信した前記再見積情報を前記第２の見積情報に同意しなかった前記買い手側会員端末に送信し、
複数の前記買い手側会員端末が同意した前記第２の見積情報及び前記再見積情報に係る同一売り手側企業サーバの同一商品／サービスが同じ価格となるように調整し、
前記第２の見積情報及び前記再見積情報に同意した前記買い手側会員端末の集団と前記売り手側企業サーバとの間の取引を支援することを特徴とする取引支援方法。

【請求項13】

コンピュータに請求項１２に記載の取引支援方法を実行させるためのプログラム。

【請求項14】

請求項１３に記載のプログラムを記録するコンピュータ読み取り可能な記録媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、商品／サービス等の取引支援技術等に関する。

【背景技術】

【0002】

消費者と企業との間の取引情報の収集等に関する情報の非対称性、すなわち、企業側の情報取得能力の圧倒的な優位性を解消する取引支援技術としては、例えば、特許文献１に記載の技術がある。

【0003】

特許文献１に記載の情報処理システムは、商品／サービスの情報を収集する消費者甲端末（第１の端末）と、第１の端末からの、購入検討商品／サービスとその条件情報の提示を受けて、第１の端末に商品／サービスを提供する提供者（事業所）の売り手端末と、第１の端末及び売り手端末と関連付けされ、商品／サービスの情報を処理する情報処理装置（第１情報登録装置、第２情報登録装置及び第１表示装置）と、を有する。

【0004】

情報処理システムＡは、第１の端末からの商品／サービスの情報の収集依頼を受けて、第１の端末とは異なる、その他消費者端末（第２の端末群）に対する商品／サービスの情報の収集依頼への応答を受け付け、第１の端末へ返信する。

【先行技術文献】

【特許文献】

【0005】

【文献】特開２０１７－５８９７０号公報

【発明の概要】

【発明が解決しようとする課題】

【0006】

個人市場においては、販売と購入とは売り手の商品／サービスと買い手の金銭とを交換する経済活動である。

【0007】

しかしながら、売り手と買い手にとって経済活動の目的や評価は異なる。売り手は経済性、すなわち利益の追求を目的としている。一方、個人である買い手にとっては、生活課題（ニーズ）や自身の変化への対応が目的である。目的のために個人である買い手は多くの場合、「より良いものをより安く」という評価を行いながら購入行動を取っている。

【0008】

従来の技術では、まず売り手が、品揃え・価格設定などを行い、次いで買い手が購入する。すなわち、取引のアクションは常に売り手→買い手であり、売り手が起点であり買い手は“受け身”である。また市場とは、売り手が買い手の到来を待機するところであり、そこに買い手の個人が訪れるという構図である。

【0009】

このような、「まず売り手ありき」という取引のコンセプトは、商品／サービスが少なかった時代の産物であるともいえる。商品／サービスの製造・生産力が十分である現代では、この「まず売り手ありき」のコンセプトに基づく取引を続ける必然性はなく、一部は全く別の新しいコンセプトに基づく取引であってもよい。よって「まず売り手ありき」ではなく、「まず買い手ありき」の取引は、個人消費者にとって一つの選択肢になり得る。

【0010】

ところで、買い手の個人は自然人であり、個人の要求と集団の規律との重層性に基づく行動（個人～家族～集団の行動）は自然人（人間）の特徴の一つとされる。購入経済活動において情報技術を活用しながら個人の買い手が集まり（集団）を形成することは、より大きな買い手として個人と集団との立場で購入行動を実現できる可能性がある。一個人で購買行動を行う場合と比べ、集団を形成することで購買力の規模が上り、価格等条件交渉でより優位に立つことができる可能性があり、また売り手側にはより大きな規模の取引高と利益への期待を生み高いレベルの売り手間競争の誘発が期待できる。

【0011】

しかしながら、同じような商品／サービスを求める個人どうしが集まって購入行動を起こすという仕組みの提案に関する開示は見当たらない。

【0012】

本発明は、同じような商品／サービス購入を求める個人の集団を形成し、商品／サービスの取引規模を大きくして買い手側（購入者側）の規模のメリットを生み、かつ売り手側の競争を誘発させることで「より良いものをより安く取引」の実現を支援することを目的とする。

【課題を解決するための手段】

【0013】

本発明の一観点によれば、複数の商品／サービス買い手側会員端末と、複数の商品／サービス売り手側企業サーバと、前記買い手側会員端末と前記売り手側企業サーバとの中継を行う中継事業体サーバと、を有する取引支援システムであって、前記中継事業体サーバは、複数の前記買い手側会員端末の集団を形成するための条件として提示される提供を要求する商品／サービスの商品名／サービス名（募集時の大まかな名称）、集団の成立条件（最低参加者数、期限など）および規約などを含む集団参加者の募集要項の情報を複数の前記買い手側会員端末に対して送信し（募集要項送信部）、前記募集要項に同意する前記買い手側会員端末からの応募入力操作に基づいて前記買い手側会員端末の集団が形成され（買い手側会員端末の集団形成促進部）、形成された集団の複数の前記買い手側会員端末からの商品／サービス名（購入を考慮する際の名称）を含む第１の見積要求（一般見積要求）情報を受信し、一般見積要求締め切り後に集計処理を行いその結果と受信した第１の見積要求（一般見積要求）情報とを、複数の前記売り手側企業サーバに送信し（第１の見積要求部）、前記売り手側企業サーバから、前記商品／サービス名（購入を考慮する際の名称）に含まれる商品／サービスの商品／サービス名（コード）の選択肢と販売条件とを含む前記第１の見積要求（一般見積要求）情報に沿った第１の見積情報（一般見積情報）を受信した場合に、受信した前記第１の見積情報（一般見積情報）を取りまとめ（集計等を行い）、前記買い手側会員端末に送信し（第１の見積情報送信部）、前記第１の見積情報（一般見積情報）を受信した複数の前記買い手側会員端末から、商品／サービスを特定した商品／サービス名（コード）と買い手側会員端末ＩＤ、売り手側企業ＩＤを含む購入希望（特定見積要求）情報を受信し（購入希望操作受信部）、受信した前記購入希望（特定見積要求）情報に基づいて集計した商品／サービスと数量と希望人数の情報と共に受信した前記購入希望（特定見積要求）情報を、前記売り手企業ＩＤと一致する前記売り手側企業サーバに送信し（第２の見積要求部、購入希望部）、それに対する特定見積情報を受信し（第２の見積情報受信部）、受信した前記特定見積情報と同意・不同意回答依頼をそれに含まれる買い手側会員端末ＩＤと一致する前記買い手側会員端末に送信し、前記買い手側会員端末からの同意・不同意回答を受信し、前記第２の見積情報（特定見積情報）に同意した前記買い手側会員端末のそれぞれに代金情報を送信して前記買い手側会員端末の集団と前記売り手側企業サーバとの間の取引を支援することを特徴とする取引支援システムが提供される。

【0014】

ここで、前記買い手側会員端末からの同意・不同意回答を受信し、中継事業体サーバは同意が得られた見積情報（特定見積情報）について同一売り手側企業で同一商品／サービス名（コード）の見積金額に異なる金額がある場合は最も低い方の金額に変更するよう当該売り手側企業サーバに見積要求情報を送信し、前記売り手側企業サーバから返信（見積情報）を受信し、当該買い手側会員端末に送信し、前記第２の見積情報（特定見積情報）に同意した前記買い手側会員端末のそれぞれに代金送金依頼文と代金送金先として中継事業体が指定する口座情報を含む代金情報を送信し、前記口座への着金を確認した上で口座残高合計額を売り手側企業毎に算定し集団として送金可能な金額情報と見積要求を売り手側企業サーバそれぞれに送信し、受信した前記売り手側企業サーバからの見積情報を送信して、前記買い手側会員端末の集団と前記売り手側企業サーバとの間の取引を支援するようにすると良い（以下も同様）。

【0015】

また、本発明は、複数の商品／サービス買い手側会員端末と、複数の商品／サービス売り手側企業サーバと、前記買い手側会員端末と前記売り手側企業サーバとの中継を行う中継事業体サーバと、を有する取引支援システムにおける中継事業体サーバであって、複数の前記買い手側会員端末の集団を形成するための条件として提示される提供を要求する商品／サービスの商品名／サービス名（募集時の大まかな名称）、集団の成立条件（最低参加者数、期限など）および規約などを含む集団参加者の募集要項の情報を複数の前記買い手側会員端末に対して送信し、前記募集要項に同意する前記買い手側会員端末からの応募入力操作に基づいて前記買い手側会員端末の集団が形成され（買い手側会員端末の集団形成促進部）、形成された集団の複数の前記買い手側会員端末からの商品／サービス名（購入を考慮する際の名称）を含む第１の見積要求（一般見積要求）情報を受信し、一般見積要求締め切り後に集計処理を行いその結果と受信した第１の見積要求（一般見積要求）情報とを、複数の前記売り手側企業サーバに送信し（第１の見積要求部）、前記売り手側企業サーバから、前記商品／サービス名（購入を考慮する際の名称）に含まれる商品／サービスの商品／サービス名（コード）の選択肢と販売条件とを含む前記第１の見積要求（一般見積要求）情報に沿った第１の見積（一般見積）情報を受信した場合に、受信した前記第１の見積情報（一般見積情報）を取りまとめ、全ての前記買い手側会員端末に送信し、前記第１の見積情報（一般見積情報）を受信した複数の前記買い手側会員端末から、商品／サービスを特定した商品／サービス名（コード）と買い手側会員端末ＩＤ、売り手側企業ＩＤを含む購入希望（特定見積要求）情報を受信し、受信した前記購入希望（特定見積要求）情報に基づいて集計した商品／サービスと数量と希望人数の情報と共に受信した前記購入希望（特定見積要求）情報を、前記売り手側企業ＩＤと一致する前記売り手側企業サーバに送信し、それに対する特定見積情報を受信し、受信した前記特定見積情報と同意・不同意回答依頼をそれに含まれる買い手側会員端末ＩＤと一致する前記買い手側会員端末に送信し、前記買い手側会員端末からの同意・不同意回答を受信し、前記第２の見積情報（特定見積情報）に同意した前記買い手側会員端末のそれぞれに代金情報を送信して前記買い手側会員端末における送金操作を促すことを特徴とする中継事業体サーバである。

【0016】

本発明は、複数の商品／サービス買い手側会員端末と、複数の商品／サービス売り手側企業サーバと、前記買い手側会員端末と前記売り手側企業サーバとの中継を行う中継事業体サーバと、を有する取引支援システムであって、前記中継事業体サーバは、複数の前記買い手側会員端末の集団を形成するための条件として提示される提供を要求する商品／サービスの商品名／サービス名（募集時の大まかな名称）、集団の成立条件および規約などを含む集団参加者の募集要項の情報を複数の前記買い手側会員端末に対して送信し、前記募集要項に同意する前記買い手側会員端末からの応募入力操作に基づいて前記買い手側会員端末の集団が形成され、形成された複数の前記買い手側会員端末からの商品／サービス名（購入を考慮する際の名称）を含む見積要求（一般見積要求）情報を受信し一般見積要求締め切り後に集計処理を行いその結果と受信した第１の見積要求（一般見積要求）情報とを、複数の前記売り手側企業サーバに送信し、前記売り手側企業サーバから、前記商品／サービス名（購入を考慮する際の名称）に含まれる商品／サービスの商品／サービス名（コード）の選択肢と販売条件とを含む前記見積要求情報に沿った見積情報（一般見積情報）を受信した場合に、受信した前記見積情報（一般見積情報）を取りまとめ、全ての前記買い手側会員端末に送信し、前記見積情報（一般見積情報）に同意した前記買い手側会員端末の集団と前記売り手側企業サーバとの間の取引を支援する取引支援システムである。

【0017】

また、本発明は、複数の商品／サービス買い手側と、複数の商品／サービス売り手側企業と、前記買い手側と前記売り手側企業との中継を行う中継事業体と、を有する取引支援システムであって、前記中継事業体は、複数の前記買い手側の集団を形成するための条件として提示される提供を要求する商品／サービスの商品名／サービス名（募集時の大まかな名称）、集団の成立条件および規約などを含む集団参加者の募集要項の情報を複数の前記買い手側に対して送信し、前記募集要項に同意する前記買い手側からの応募に基づいて前記買い手側の集団が形成され、形成された集団の複数の前記買い手側からの商品／サービス名（購入を考慮する際の名称）を含む見積要求（一般見積要求）情報を受信し、一般見積要求締め切り後に集計処理を行いその結果と受信した見積要求（一般見積要求）情報とを、複数の前記売り手側企業に送信し、前記売り手側企業から、前記商品／サービス名（購入を考慮する際の名称）に含まれるカテゴリ内の商品／サービスの商品／サービス名（コード）の選択肢と販売条件とを含む前記見積要求情報に沿った見積情報（一般見積情報）を受けた場合に、受信した前記見積情報（一般見積情報）を取りまとめ、全ての前記買い手側に送信し、前記見積情報（一般見積情報）に同意した前記買い手側の集団と前記売り手側企業との間の取引を支援することを特徴とする取引支援システムである。

【0018】

本発明の他の観点によれば、複数の商品／サービス買い手側会員端末と、複数の商品／サービス売り手側企業サーバと、前記買い手側会員端末と前記売り手側企業サーバとの中継を行う中継事業体サーバと、を有する取引支援システムにおける中継事業体サーバによる取引支援方法であって、複数の前記買い手側会員端末の集団を形成するための条件として提示される提供を要求する商品／サービスの商品名／サービス名（募集時の大まかな名称）、集団の成立条件（最低参加者数、期限など）および規約などを含む集団参加者の募集要項の情報を複数の前記買い手側会員端末に対して送信し、前記募集要項に同意する前記買い手側会員端末からの応募入力操作に基づいて前記買い手側会員端末の集団が形成され、形成された集団の複数の前記買い手側会員端末からの商品／サービス名（購入を考慮する際の名称）を含む第１の見積要求（一般見積要求）応募入力操作情報を受信し、一般見積要求締め切り後に集計処理を行いその結果と受信した第１の見積要求（一般見積要求）情報とを、複数の前記売り手側企業サーバに送信し、前記売り手側企業サーバから、前記商品／サービス名（購入を考慮する際の名称）に含まれる商品／サービスの商品／サービス名（コード）の選択肢と販売条件とを含む前記第１の見積要求（一般見積要求）情報に沿った第１の見積情報（一般見積情報）を受信した場合に、受信した前記第１の見積情報（一般見積情報）を前記買い手側会員端末に送信し、前記第１の見積情報（一般見積情報）を受信した複数の前記買い手側会員端末から、商品／サービスを特定した商品／サービス名（コード）と買い手側会員端末ＩＤ、売り手企業ＩＤを含む購入希望（特定見積要求）情報を受信し、受信した前記購入希望（特定見積要求）情報に基づいて集計した商品／サービスと数量と希望人数の情報と共に受信した前記購入希望（特定見積要求）情報を前記売り手側企業サーバに送信し、それに対する特定見積情報を受信し、受信した前記特定見積情報と同意・不同意回答依頼をそれに含まれる買い手側会員端末ＩＤと一致する前記買い手側会員端末に送信し、前記買い手側会員端末からの同意・不同意回答を受信し前記第２の見積情報（特定見積情報）に同意した前記買い手側会員端末の集団と前記売り手側企業サーバとの間の取引を支援することを特徴とする取引支援方法が提供される。

【発明の効果】

【0019】

本発明によれば、個人であっても集団に参加することにより集団という買い手側の規模のメリットを得ることができ、複数の売り手間の価格を含めた競争も誘発し、個人により有利な購入を目的とする取引支援システムを提供することができる。

【図面の簡単な説明】

【0020】

【図1A】本発明の一実施の形態による取引支援システム（装置）の一構成例を示す機能ブロック図である。

【図1B】中継事業体サーバの一構成例を示す機能ブロック図である。

【図2】データベースの一構成例を示す機能ブロック図である

【図3】本実施の形態による取引支援処理の流れを示すフローチャート図である。

【図4】本実施の形態による取引支援処理の流れを示すシーケンス図である。

【図5】本実施の形態による取引支援の概要を示す図であり、中継事業体、集団、チームの階層を示すツリー構造である。

【図6】商品／サービスが自動車（サービスであれば自動車販売）である場合の集団形成と取引状態の一例を図式的に示すイメージ例の図である。

【発明を実施するための形態】

【0021】

本明細書において、集団とは、同志、同じ意思を有するグループとほぼ同義で、ある商品／サービスについて購入意思がある自然人の集りである。

【0022】

取引支援とは、買い手側と売り手側の取引を円滑にすること、とりわけ、買い手側の規模を生かしながら取引の支援を行うことを意味する。但し、本発明の範囲は、これらの用語によって限定的に解釈されるべきではない。

【0023】

商品／サービス：個人向けの商品／サービス
商品名／サービス名（募集時の大まかな名称）：商品／サービスの大まかな分類名であり、カテゴリである。例えば、軽自動車、ルームエアコン、宅配など。
商品／サービス名（購入を考慮する際の名称）：商品／サービスの通称である。例えば、メーカーがブランド名としてつけている名称などを指す。ルームエアコンでは、三菱電機（商号）のブランド名 霧ケ峰（登録商標）、軽自動車ではスズキ（商号）のワゴンＲ（登録商標）などである。
商品／サービス名（コード）：商品／サービスを一意に特定する名称である。多くは流通コード（ＪＡＮコードなど）に対応している。例えば、三菱ルームエアコン霧ケ峰 MSZ-S2217-Wなどである。

【0024】

また、中継事業体サーバから買い手への送信は、メールでも良い。また、中継事業体サーバ←買い手からの受信は、Ｗｅｂ入力を行うようにしても良い。

【0025】

さらに、中継事業体サーバから売り手への送信、中継事業体サーバへの売り手からの受信は、メールでも良い。

【0026】

以下に、本発明の一実施の形態による取引支援技術について図面を参照しながら詳細に説明する。なお、データ管理技術などの一般的な技術については、記載を省略することがある。

【0027】

図１Ａは、本発明の実施の形態による取引支援システム（装置）の一構成例を示す機能ブロック図である。
図１Ａに示すように、本実施の形態による取引支援システムＡは、複数の商品／サービスの買い手側（例えば会員登録された買い手側）端末３－１，３－２，…，３－ｍ（ｍは２以上の整数）と（以下、「複数の商品／サービスの買い手側会員端末３」と称する。）、複数の売り手側企業サーバ５－１、５－２，…，５－ｎ（ｎは２以上の整数）（以下、「複数の売り手側企業サーバ５と称する。」と、複数の商品／サービスの買い手側会員端末３と複数の売り手側企業サーバ５とにネットワーク接続などにより関連付けされ両者間を中継する中継事業体サーバ１（中継サーバ）と、を有している。例えば、中継事業体サーバ１は、種々のデータを格納するデータベース（ＤＢ）１ｘと関連付けされていても良い。或いは、種々のデータをクラウド技術などにより分散配置させておいても良い。

【0028】

図１Ｂは、中継事業体サーバ１の一構成例を示す機能ブロック図である。
図１Ｂに示すように、中継事業体サーバ１は、中継事業体の職員（コーディネーターなど）が運営し、例えば、購入条件、すなわち、複数の買い手側会員端末３の集団（図１Ａの集団（１）３ｘ－１，…集団Ｐ（３ｘ－ｐ）等）を形成するための条件として提示される商品／サービスのカテゴリ(大まかな分類名)と集団の成立条件（最低参加者数、期限など）および規約などを含む集団参加者の募集要項の情報を複数の買い手側会員端末３に対して送信する募集要項送信部１－１と、募集要項に同意する買い手側会員端末３からの応募入力操作に基づいて会員登録された会員の買い手側会員端末３において、商品／サービスに関連する集団を形成する買い手側会員端末の集団形成促進部１－２と、集団が形成された買い手側会員端末３からの募集要項に同意する操作された入力に基づく集計結果に基づいて、複数の売り手側企業サーバ５に第１の見積要求を行う第１の見積要求部１－３と、売り手側企業サーバ５から、商品／サービス名（購入を考慮する際の名称）に含まれる商品／サービスの商品／サービス名（コード）、例えばカテゴリの選択肢と販売条件とを含む第１の見積要求に沿った第１の見積情報を受信した場合に、受信した第１の見積情報を買い手側会員端末３に送信する第１の見積情報送信部１－４と、第１の見積情報を受信した複数の買い手側会員端末３から、商品／サービスを特定した購入希望情報を受信する購入希望操作受信部１－５と、受信した購入希望情報に基づいて集計した商品／サービスと数量と希望人数の情報と共に受信した購入希望情報を返信のあった売り手側企業サーバ５に送信する第２の見積要求部１－６と、購入商品／サービスを例えば、１つに絞り込むための第２の見積情報の要求の送信とそれに対する返信を受け取る第２の見積情報送信部１－７と、第２の見積情報に同意した買い手側会員端末３のそれぞれに代金情報を送信して送金を促す代金情報送信部１－８と、を有している。

【0029】

中継事業体サーバ１には、図示しないが、記憶部（メモリ）が設けられており、このメモリ内に記憶されているプログラムなどにより、上記の機能部の機能を実行させることができる。上記の機能部は、このようにソフトウェアにより実現することができるが、ハードウェアにより実現するようにしても良い。以下では、各機能部の処理をフローチャート図で示したソフトウェア処理により行う例について説明する。

【0030】

ところで、本実施の形態における見積には大別して２種類がある。
一般見積は、買い手側が商品／サービス名（購入を考慮する際の名称）を含む見積要求情報と集団としての購買力の規模をデータで売り手側企業に示し、かつ全ての売り手側企業からの見積情報をまとめ、表示し当該取引が売り手側企業間の競争であることを明示する、購入商品の選択肢を得るための見積要求情報と見積情報（回答）であり、これにより、売り手側企業間の競争を促すことができる。

【0031】

特定見積は、買い手（買い手側会員端末ＩＤで特定される）が見積を依頼する複数の売り手側企業に対して商品／サービス名（コード）と買い手側会員端末ＩＤを含む見積要求情報を示し、依頼を受けた売り手側企業が買い手側（買い手側会員端末ＩＤ）に対して回答する、見積要求情報と見積情報（回答）である（中継事業体サーバを保持する中継事業体の職員であるコーディネーターが中継操作をする）。複数の売り手側企業からの回答で得られた見積情報について同一の買い手（買い手側会員端末ＩＤで特定される）が、見積情報について「同意・不同意（諾否）」判断を繰り返すことで、売り手側企業間の競争を促しながら、購入の仮予約、予約、確定とプロセスが進められる。このプロセスの進行は、中継事業体サーバ１の職員であるコーディネーターが行う。

【0032】

なお、仮予約とはひとりの買い手側による特定見積への同意（諾）であり、予約とは同一売り手側企業において同一物への仮予約が複数ある場合に集団が行う「同一売り手側企業1物１価」による調整要求に回答された見積への同意（諾）であり、確定とは例えば信託銀行などの指定口座残高すなわち送金された代金合計金額を売り手側企業毎に示す集団見積要求に基づく見積への同意（諾）であり、最終的な決定である。

【0033】

図２は、各種データを格納するデータベースＤＢ１ｘの一構成例を示す機能ブロック図である。図２に示すように、データベースＤＢ１ｘは、複数のデータベースを有している。例えば、買い手側会員端末３を所持する消費者のうち本システムに登録済みの会員のデータを格納する会員データベース（買い手側会員端末データベース）ＤＢ１ｘ－１，売り手側企業サーバを保持する企業のデータである売り手側企業サーバデータベースＤＢ１ｘ－２，後述するように買い手側会員端末３を所持する、ある一定の購買活動を行う消費者の集団のデータを格納する集団データベースＤＢ１ｘ－３，集団への参加者のデータを格納する集団への参加者データベースＤＢ１ｘ－４，…，一般見積結果全体情報データベースＤＢ１ｘ－５，一般見積データベースＤＢ１ｘ－６，特定見積データベースＤＢ１ｘ－７，特定見積結果全体情報データベースＤＢ１ｘ－８等を有している。以下、各データベースのデータ構成について例示的に説明する。

【0034】

会員データベース（買い手側会員端末データベース）ＤＢ１ｘ－１（以下、Ａ１（会員ＤＢ）と称する。）は、例えば、主体（買い手側会員端末３）のＩＤ（会員ＩＤ）と、買い手側会員端末３の属性（メールアドレス、パスワード等）と、登録された集団のＩＤ及び登録日等を有する。買い手側会員端末３の所有者の属性情報等（名前、住所など）を含んでも良い。

【0035】

売り手側企業サーバデータベースＤＢ１ｘ－２（以下、Ａ２（売り手側企業サーバＤＢ）と称する。）は、例えば、企業（売り手側企業サーバ５）のＩＤと、それに対応する属性（メールアドレス、パスワード等）と、集団ＩＤ，提供可能な商品／サービスを特定した商品／サービス名（コード）等情報と、を有している。企業の属性情報等を含んでも良い。集団ＩＤは登録済みのものであって、複数あっても良い。

【0036】

集団データベースＤＢ１ｘ－３（以下、Ａ３（集団ＤＢ）と称する。）は、例えば、集団ＩＤと募集要項とを有している。募集要項には、募集商品／サービス名（募集時の大まかな名称）すなわち募集商品／サービスのカテゴリなど募集商品／サービスの種別を大まかに特定できる事項と、集団活動を行う期限等の管理のための、応募締切日、最低参加者数、一般見積要求受付期限、一般見積諾否回答期限、特定見積要求受付期限、特定見積諾否回答期限、１物１価調整諾否受付期限、代金入金期限、集団見積諾否受付期限などの事項を含んでも良い。なお、特定見積要求受付期限、特定見積諾否回答期限は複数あっても良い。なお期限が守られない場合は参加者権利停止条件に該当すると表示されている。

【0037】

募集商品／サービスのカテゴリ（上下階層的に、一意に特定できる商品／サービス名などよりも上位の階層の名称等）など、募集商品／サービスの種別を大まかに特定できる事項とは、例えば、自動車名（型式）など１台の自動車を特定することができる事項ではなく、軽自動車、Ｘ社の１５００ｃｃの自動車など、商品／サービスを複数選択する幅を有しているという意味である。

【0038】

集団への参加者データベースＤＢ１ｘ－４（以下、Ａ４（参加者ＤＢ）と称する。）は、例えば、集団のＩＤと、当該集団への参加者が所持している買い手側会員端末のＩＤ（以下、参加者ＩＤと称する。）等と、参加状況（未回答，参加中，退出、会員停止条件による強制退出）などが含まれていても良い。参加者とは、参加者応募を行った会員の内、審査で承認された会員である。

【0039】

一般見積結果全体情報データベースＤＢ１ｘ－５（以下、Ａ５（一般見積結果全体情報ＤＢ）と称する。）は、例えば、集団ＩＤ、企業ＩＤ、商品／サービス名（コード）と、概算見積額情報、見積内訳書情報、商品情報等に関する情報を有する。また、Ａ５（一般見積結果全体情報ＤＢ）の情報は全ての売り手側企業サーバからの一般見積情報がＡ６（一般見積ＤＢ）に書き込まれた後に、Ａ６（一般見積ＤＢ）から抽出・格納されたデータであって、参加者が入力したデータから集団購入対象の商品／サービスの購入を希望する参加者人数や一般見積要求件数など当該集団の購買力の規模を表すデータ、売り手側企業が入力したデータから当該集団向けに提供可能な購入対象の商品／サービス名（コード）リストであり、いわば当該集団限定の売り手側企業商品／サービスチラシ（例えば、企業毎の提供価格等を表示する商品／サービスのトップページ）情報も持つ。売り手側企業サーバ５等は、当該集団の購買力の規模を表すデータなどにより販売可能性の規模を推測することができる。売り手側企業にとっては個人を相手にする場合に比べて、集団を相手にする場合には、参加人数に比例する取引規模（取引総額）になることが想定される。

【0040】

第１の見積（一般見積）データベースＤＢ１ｘ－６（以下、Ａ６（一般見積ＤＢ）と称する）は、例えば、集団ＩＤと、参加者ＩＤ、区・市町村までなど大まかな住所地を示す情報、家族人数などの付加プロフィールなどの参加者プロフィール情報、などの参加者の基本的な情報、管理のための一般見積要求番号、参加者が入力する商品／サービス名（購入を考慮する際の名称）、購入条件等の情報と、売り手側企業が見積要求時に入力する概算見積金額と、納品日情報、商品／サービス特定情報と、見積を提示した企業ＩＤ等と、を有している。

【0041】

さらに、参加者と売り手側企業がこのＤＢのレコードの各項目にデータを入力、あるいは閲覧していくための情報を含んでも良い。

【0042】

また、集団見積とは参加者でなく、中継事業体が予約後の指定口座着金を踏まえて指定口座の金額を示すことにより行う売り手側企業に対する見積要求と見積（回答）をいう。

【0043】

第２の見積（特定見積）データベースＤＢ１ｘ－７（以下、Ａ７（特定見積ＤＢ）と称する。）は、例えば、集団ＩＤと、参加者ＩＤ、区・市町村までなど大まかな住所地を示す情報、家族人数などの付加プロフィールなどの参加者プロフィール情報、などの参加者の基本的な情報、特定見積要求ＩＤ、検討ステータス、諾否回答期限、諾否回答、今回見積要求の種類などの特定見積概要情報、参加者が入力する商品／サービス名（コード）、見積要求先売り手側企業ＩＤ、購入条件等の情報と、売り手側企業が入力する見積金額、見積内訳書情報と、受領・納品日情報、商品資料情報と、中継事業体が仮予約後に使用する要求・回答の種類、指定口座情報、指定口座残高情報、受渡完了情報、送金指示情報等と、を有している。

【0044】

さらに、特定見積への同意・不同意（諾否）の情報を含んでも良い。指定口座情報に関する情報を含んでも良い。

【0045】

なお、指定口座とは、中継事業体サーバ１を運営する中継事業体事務局等が指定する口座であって参加者の代金の送金先口座である。指定口座は参加者からの支払代金を預かることができる。

【0046】

特定見積結果全体情報データベースＤＢ１ｘ－８（以下、Ａ８（特定見積結果全体情報ＤＢ）と称する。）は、例えば、集団ＩＤと、企業ＩＤと、商品／サービスのＩＤと、数量、見積額、納品等に関する最新の情報を含む。これにより、集団の中の見積情報全体を参加者の買い手側会員端末３に伝え、再見積（特定見積）要求に役立てるなど参加者の買い手側会員端末３による選択肢を拡げることができる。また、この情報により、「売れ筋」商品・売り手側企業や「相場」感が分かるため、選択の幅が広がるばかりでなく、選択の満足度を向上させることができる。さらに、取引に関する種々の経過情報を少なくとも一時的に保持しておくと良い。

【0047】

中継事業体は次の２つの情報を売り手側企業に示し見積を要求し、さらなる好条件の見積を引き出す、最重要項目の一つである。
１）指定口座着金確認の根拠を示す
２）本集団と当該売り手側企業の間の総見積額を集計・提示する → ※集団として支払金も準備し、合計額の買い物をするのだから価格を下げて欲しい。

【0048】

なお、実務上は参加者には選択の自由（予約取り消しの自由）があることを示し、売り手側企業に対して立ち位置をより優位にする。

【0049】

以上のような構成により、取引支援システムを構成するそれぞれの主体のＩＤと、それに対応する属性（メールアドレス、パスワード等）、集団購入のために一時的に集団を形成し、集団によって買い手側の購買力を大きくすることができ、また集団として売り手側に要求することもできる。

【0050】

なお、購入に関わる確定、受渡（役務サービスにあってはサービス着手）確認、代金の売り手側企業への送金等の処理が完了すれば集団は役目を終え解散する。この意味で集団を構成する参加者や売り手側の企業は集団の形成毎に設定される。

【0051】

次に、本実施の形態による取引支援処理の詳細について説明する。図３は、本実施の形態による取引支援処理の流れを示すフローチャート図である。図４は、本実施の形態による取引支援処理のシーケンス図である。図３及び図４を参照して取引支援処理の流れについて説明する。なお、図３では、各処理をステップＳにより、図４では各処理を処理Ａ～ＣＣ等の大文字のアルファベット等で示している。

【0052】

中継事業体サーバ１が処理の対象とする集団について次に説明する。中継事業体サーバ１は中継事業体サーバ１、買い手側会員端末３あるいは売り手側企業サーバ５に対してＡ３（集団ＤＢ）に登録されている集団ＩＤを元に編集した集団ＩＤ選択入力画面を表示し、中継事業体サーバ１は入力されたデータを受け付け、処理対象の集団ＩＤを得る。以下の説明においては、この処理の説明を単に集団ＩＤ特定処理といい、たとえば中継事業体サーバ１は集団ＩＤ特定処理で得られた集団ＩＤ、などと表現する。

【0053】

端末/サーバの操作者の特定の処理手順について説明する。これは端末/サーバを用いて操作が開始される時に共通する処理である。中継事業体サーバ１は当該端末/サーバにまずログイン画面表示し、会員/参加者あるいは売り手側企業が入力したＩＤ・パスワードを受け付け、受け付けたＩＤ・パスワードと一致するＩＤ・パスワードを持つＡ１（会員ＤＢ）、Ａ４（参加者ＤＢ）あるいはＡ２（売り手側企業サーバＤＢ）のレコードを特定し、特定したレコードから会員ＩＤ、参加者ＩＤ、あるいは売り手側企業ＩＤを得ることにより買い手側会員端末３の会員/参加者や売り手側企業サーバ５の売り手側企業のＩＤを特定する（操作者の特定の処理）。以下の説明においては、この処理の説明を単にログイン処理といい、例えばログイン処理で得られた参加者ＩＤ、などと表現する。

【0054】

また、端末/サーバの操作者は中継事業体サーバ１が募集要項に示す各種受付期限に従い操作するものとし、中継事業体サーバ１は端末/サーバの操作者が中継事業体サーバ１にアクセスを開始した時刻データ（処理時刻）と各種受付期限を基に選択されたログイン画面を表示するものとする。処理時刻とは中継事業体サーバ１が処理を行う時刻とする。また、サーバや端末の時計は日本標準時など国際的な時計と同期しているとする。端末/サーバの操作者が各種受付期限を守らずに中継事業体サーバ１にアクセスした場合、募集時を除き参加資格がない場合、あるいは失った場合端末/サーバの操作者が中継事業体サーバ１にアクセスした場合は断りの文章を表示し処理を終了するものとする。以下の説明においては、上記の処理の説明は略するものとする。

【0055】

また、本明細書では売り手側企業は、集団の運営、すなわち買い手側に対する各種期限に十分に配慮して最優先に回答するものであり、売り手側企業の回答については期限のチェックは行う必要がないとしている。従って、以下の説明においては売り手側企業の回答については期限のチェック処理は省略している。

【0056】

まず、処理の前提として、複数の商品／サービスの買い手側会員端末３が、中継事業体サーバ１に対して、集団購入参加募集案内受信のための会員登録申請操作を行う。例えば、中継事業体サーバ１が買い手側会員端末３に住所、氏名、メールアドレスなどから成る会員登録入力画面を表示し、入力データを受け付け、ＩＤ・パスワードを生成・発行し、当該買い手側会員端末３に表示すると共に、Ａ１（会員ＤＢ）にレコードを生成し受け付けた入力データと生成・発行したＩＤ・パスワードを生成したレコードに格納する。買い手側会員端末以上により、会員登録処理が行われる。また、売り手側企業に関するＡ２（売り手側企業サーバＤＢ）は中継事業体が予め構築済みであるとする。

【0057】

次いで、取引支援処理が開始され（Ｓｔａｒｔ）、ステップＳ１において、集団参加者３ａから、Ａ：集団購入プロジェクト参加申込受付が行われる。中継事業体サーバ１は、集団ＩＤの生成、売り手側企業と買い手側の集団参加申込み受付処理を行う。例えば、中継事業体サーバ１は、集団ＩＤを生成すると共にＡ３（集団ＤＢ）のレコードを作成し、Ａ３（集団ＤＢ）のデータ項目に従い集団購入参加者募集要項を編集したデータ入力画面を中継事業体サーバ１に表示し、データ入力を受け付け、受け付けたデータを生成した集団ＩＤと共に、中継事業体サーバ１のＡ３（集団ＤＢ）レコードに格納する。

【0058】

加えて、中継事業体サーバ１は、全ての売り手側企業サーバに対しログイン処理、集団ＩＤ特定処理に続き、前記集団ＩＤとＡ３（集団ＤＢ）から当該集団購入募集要項のデータを表示すると共に集団への参加意向入力画面を表示し、データ入力を受け付け、受け付けたデータが“参加”のときログイン処理で得られた売り手側企業ＩＤと同じ売り手側企業ＩＤを持つＡ２（売り手側企業サーバＤＢ）のレコードの集団ＩＤに対して前記集団ＩＤのデータを格納する。

【0059】

続いて、中継事業体サーバ１の募集要項送信部１－１は、前記集団ＩＤとＡ３（集団ＤＢ）から応募締切日のデータを取得し、Ａ１（会員ＤＢ）を参照し、集団購入参加者募集案内と応募受付として次の処理を行う。中継事業体サーバ１は、買い手側会員端末３の表示部に対しログイン処理、集団ＩＤ特定処理に続き、募集要項確認・同意入力と参加応募入力画面を表示させ、入力データを受け付け、入力データが募集要項確認・同意＝“Ｙｅｓ”、応募入力＝“応募”のとき、Ａ４（参加者ＤＢ）のレコードと参加者ＩＤを生成し、ログイン処理で得られた会員ＩＤと生成した参加者ＩＤを生成したレコードに書き込む。

【0060】

中継事業体サーバ１の買い手側会員端末の集団形成促進部１－２は、中継事業体サーバ１に対し集団ＩＤ特定処理を行い、得られた集団ＩＤとＡ３（集団ＤＢ）から応募締切日のデータを取得し、処理時刻が応募締切日を過ぎている場合は、Ａ４（参加者ＤＢ）により参加者人数を集計し、集計結果の合計参加者数とＡ３（集団ＤＢ）の最低参加者数と比較し、合計参加者人数≧最低参加者数であれば集団を成立させる（ステップＳ２でＹｅｓ）。

【0061】

次いで、ステップＳ３において、Ｃ：一般見積要求受付処理と、それに続く、Ｄ：一般見積要求送信処理及びＥ：一般見積受信処理が行われる。

【0062】

Ｃ：一般見積要求受付処理では、集団として商品／サービス名（コード）と、おおよその価格を知ること、個別の一般見積要求ばかりでなく入力された一般見積要求情報を集計し集団の規模情報とニーズ情報とを売り手側企業サーバ５に送信する処理が行われる。

【0063】

たとえば、買い手側会員端末３に対し、中継事業体サーバ１は、中継事業体サーバ１に対し集団ＩＤ特定処理を行い、得られた集団ＩＤとＡ３（集団ＤＢ）から一般見積要求受付締切日のデータを取得し、処理時刻が一般見積要求受付締切日に到達していない場合、一般見積要求番号とＡ６（一般見積ＤＢ）のレコードを作成し、ログイン処理に続き、参加者からの一般見積要求データ受付のための入力画面を表示させ、入力データの受け付けを行い、受け付けたデータと生成した前記一般見積要求番号を、ログイン処理で得られた参加者ＩＤおよび集団ＩＤと共に作成したレコードに書き込みＡ６（一般見積ＤＢ）に格納する。これらの処理を一般見積要求受付締切日に到達するまで買い手側会員端末３に対して行う。

【0064】

なお、一般見積要求では、参加者の商品／サービスの買い手側会員端末３は見積要求先として売り手側企業サーバ５を特定せず、売り手側企業の全社が見積要求先となる。

【0065】

また、一般見積要求データ受付入力画面は、買い手側会員端末複数件の商品／サービス名（商品／サービス名（購入を考慮する際の名称）の一般見積要求入力と受付が可能である。

【0066】

次に、中継事業体サーバ１の第１の見積要求部１－３は、中継事業体サーバ１に対して集団ＩＤ特定処理を行い、得られた集団ＩＤとＡ３（集団ＤＢ）から一般見積要求受付締切期限のデータを取得し、処理時刻が一般見積要求受付締切期限を経過している場合、Ａ６（一般見積ＤＢ）のレコードの全て（全ての一般見積要求情報）について集計処理を行い、集団の購買力情報として集団全体および商品／サービス名（商品／サービス名（購入を考慮する際の名称）毎の参加人数、購入希望数量等規模を表すデータをＡ５（一般見積結果全体情報ＤＢ）に書き込み、前記レコード毎に編集した一般見積要求情報とＡ５（一般見積結果全体情報ＤＢ）のデータを編集した集団の購買力情報を売り手側企業サーバ５に対して送信する（ステップＳ３：Ｄ）。

【0067】

売り手側企業サーバ５は、中継事業体サーバ１に対して一般見積情報を返信する（ステップＳ３：Ｅ）。

【0068】

次に、ステップＳ４において、中継事業体サーバ１は、Ｆ：一般見積情報送信処理を行う。Ｆの処理は、売り手側企業サーバから送られてきた全ての一般見積情報を受信し、一般見積情報に含まれる参加者ＩＤを持つ買い手側会員端末３に送信する処理（Ｆ１）と、参加者の選択に資することを目的に売り手側企業サーバから送られてきた全ての一般見積情報から集団向けに売り手側企業が提供可能な全ての商品／サービス（コード）の情報を編集し編集した情報を一般見積要求を行った買い手側会員端末３に送信する処理（Ｆ２）と、次の特定見積に進むかどうか同意・不同意（諾否）回答要求情報を、一般見積要求を行った買い手側会員端末３に送信する処理（Ｆ３）を行う。

【0069】

たとえば、Ｆ１においては、中継事業体サーバ１は、売り手側企業サーバ５から一般見積情報を受信し、受信したデータを受け付け、受け付けたデータの集団ＩＤ，参加者ＩＤを含めデータの全てをＡ６（一般見積ＤＢ）に書き込む処理を全ての売り手側企業サーバ５について行う。但し、売り手側企業サーバ５による選択として、一般見積要求に対して、見積を行わないこともある（例えば、要求された商品等を取り扱っていない／在庫切れなど）。次いで、Ｇ：一般見積諾否受信・処理を行う。

【0070】

次いで、中継事業体サーバ１は、中継事業体サーバ１に対し集団ＩＤ特定処理を行い、得られた集団ＩＤと参加者ＩＤを検索ＫＥＹ項目にしてＡ６（一般見積ＤＢ）レコードを検索し、検索された全ての参加者ＩＤについて次の処理を行う、中継事業体サーバは、参加者ＩＤ毎にレコードを一般見積情報として編集・作成し、作成された一般見積情報と当該参加ＩＤのデータを用いＡ４（参加者ＤＢ）を検索して送信先（買い手側会員端末３）を特定し、特定された当該買い手側会員端末３に送信する。

【0071】

Ｆ２の送信処理においては、中継事業体サーバ１の第１の見積情報送信部１－４は、中継事業体サーバ１に対し集団ＩＤ特定処理を行い、得られた集団ＩＤと一致する集団ＩＤを持つＡ６（一般見積ＤＢ）の全てのレコードを取り出し、商品／サービス名（コード）毎に並び替えＡ５（一般見積結果全体情報ＤＢ）に書き込み、全ての参加者の買い手側会員端末３に送信する。但し、並び替え処理においてはレコードの商品／サービス名（コード）と売り手側企業ＩＤの組み合わせが同じレコードは重複しないようにする。

【0072】

Ｆ３の送信処理においては、すなわち、中継事業体サーバ１の購入希望操作受信部１－５は、中継事業体サーバ１に対し集団ＩＤ特定処理を行い、得られた集団ＩＤと一致する集団ＩＤを持つＡ４（参加者ＤＢ）のレコードから得られた全ての買い手側会員端末３に対し特定見積に進むかどうか、その同意・不同意（諾否）の回答お願い情報を送信する。
受信した買い手側会員端末３の参加者は回答を中継事業体サーバ１に対して入力操作を行う。

【0073】

中継事業体サーバ１は、買い手側会員端末３に対しログイン処理、集団ＩＤ特定処理を行い得られた集団ＩＤとＡ３（集団ＤＢ）から一般見積諾否回答期限のデータを取得し、処理時刻が一般見積諾否回答期限を経過していない場合、Ｇ１（一般見積諾否ファイル）のレコードを作成し、参加者からの一般見積諾否入力受付のための入力画面を買い手側会員端末３に表示させ、入力データの受け付けを行い、受け付けたデータ（諾否回答）とログイン処理で得られた参加者ＩＤを作成したＧ１（一般見積諾否ファイル）のレコードに書き込みＧ１（一般見積諾否ファイル）に格納する。この処理を一般見積要求受付締切日に到達するまで買い手側会員端末３について行う。なお、Ｇ１（一般見積諾否ファイル）のレコードのデータ項目は諾否回答（“諾”or“否”）と参加者ＩＤ、の他にデータ項目があっても良い。

【0074】

ステップＳ５において、中継事業体サーバ１は、Ｈ：一般見積諾否意向処理（特定見積への移行又は退出受付処理）を行う。中継事業体サーバ１は、処理時刻が一般見積要求受付締切日を超えている場合、買い手側会員端末３（参加者）から受信した同意・不同意（諾否）情報に従い、買い手側会員端末３（参加者）毎に特定見積に進むかどうか、あるいは一般見積要求受付締切日までに同意・不同意（諾否）回答がなく強制退出処理対象かなどの参加者の区分処理をおこなう。

【0075】

例えば、中継事業体サーバ１は、中継事業体サーバ１に対し集団ＩＤ特定処理を行い、得られた集団ＩＤとＡ３（集団ＤＢ）から一般見積諾否回答期限のデータを取得し、処理時刻が一般見積諾否回答期限を経過している場合、得られた集団ＩＤと一致する集団ＩＤを持つＡ４（参加者ＤＢ）のレコードとＧ１（一般見積諾否ファイル）のレコードの参加者ＩＤが一致するレコードを検索し、Ｇ１（一般見積諾否ファイル）レコードの諾否回答結果のデータに従ってＡ４（参加者ＤＢ）の「参加状況」データ（初期値は０（未回答））を例えば以下のように書き換える。

【0076】

Ｇ１（一般見積諾否ファイル）の諾否回答＝“諾”のとき、Ａ４（参加者ＤＢ）の「参加状況」＝１（参加継続）
Ｇ１（一般見積諾否ファイル）の諾否回答＝“否”のとき、Ａ４（参加者ＤＢ）の「参加状況」＝９９（退出）

【0077】

また、Ａ４（参加者ＤＢ）の参加者ＩＤと一致する参加者ＩＤを持つレコードがＧ１（一般見積諾否ファイル）に見つからないとき（参加者が期限までに諾否回答を行っていないとき）は、Ａ４（参加者ＤＢ）の「参加状況」＝０（未回答（初期値））であることを確認し、それは変更しない。

【0078】

次いで、中継事業体サーバ１は、書き換え処理後のＡ４（参加者ＤＢ）の「参加状況」のデータ内容に従って次の処理を行う。

【0079】

「参加状況」＝１（参加継続）の場合には、特定見積へ進む。
「参加状況」＝９９（退出）の場合には、参加者が自らの意思により集団購入参加を中止し、集団から退出することであるから処理を終了する。この場合には、取引に関する一切の権利を失うようにすると良い。
「参加状況」＝０（未回答）の場合には、募集要項の参加者権利停止条件に該当することから強制退出として処理を終了する。この場合も、取引に関する一切の権利を失うようにすると良い。また、Ａ４（参加者ＤＢ）の「参加状況」＝９９９と書き換える。

【0080】

また、特定見積へ進む準備として特定見積回数カウンターＤＢのレコードを生成し、生成したレコードについて、集団ＩＤ＝前記集団ＩＤ，特定見積回数＝１とし、前記レコードを特定見積回数カウンターＤＢに格納する。

【0081】

ステップＳ６において、中継事業体サーバ１は、Ｊ：特定見積要求受付処理を行う。中継事業体サーバ１は、処理時刻が特定見積要求受付締切期限を経過していない場合、参加者の商品／サービスの買い手側会員端末３からの特定見積要求（Ｊ）を受信し、売り手側企業サーバ５に対して特定見積要求（Ｋ）を行う。また、Ｋ/Ｌ：特定見積送信／受信も行う。

【0082】

そして、特定見積要求情報入力受付を行う対象の買い手側会員端末３はＡ４（参加者ＤＢ）の「参加状況」＝１（参加継続）の参加者の買い手側会員端末３である。

【0083】

また、特定見積要求（Ｊ）処理は、条件を変更して行う２回目以降の特定見積要求を可能とすることができるとしても良い。

【0084】

たとえば、中継事業体サーバ１は、買い手側会員端末３に対してログイン処理に続き集団ＩＤ特定処理を行い参加者ＩＤと集団ＩＤを得る。得られた集団ＩＤとＡ３（集団ＤＢ）から該当の特定見積要求受付期限のデータを取得し、処理時刻が特定見積要求受付期限に到達していない場合、次の処理を行う。前記集団ＩＤと特定見積回数カウンターＤＢから当該集団ＩＤの特定見積回数を得て、特定見積回数＝１のときには、中継事業体サーバ１は、得られた集団ＩＤと参加者ＩＤとＡ４（参加者ＤＢ）から当該参加者レコードについて、当該レコードから「参加状況」のデータを抽出し、「参加状況」＝１（参加継続）であるか確認し（１以外のときは警告を表示させトップ画面に戻る）、中継事業体サーバ１は、Ａ７（特定見積ＤＢ）のレコードを作成し、作成したレコードについて「今回見積要求の種類」＝１とし、以下の処理を行う。

【0085】

特定見積要求番号を生成し、商品／サービス名（コード）、見積要求先売り手側企業ＩＤ、購入条件等および参加者プロフィールと、を含む入力項目の入力画面を表示させて、入力データを受け付け、受け付けた入力データを参加者ＩＤおよび集団ＩＤと共にＡ７（特定見積ＤＢ）のレコードに書き込む。

【0086】

一方、特定見積回数＞１のときには、前回特定見積要求の条件変更による“再見積要求”か新たな要求（“新規特定見積要求”）かに誘導する（分岐させる）選択画面を買い手側会員端末３に表示し、参加者は選択操作入力を行い、中継事業体サーバ１は、入力データを受け付け、受け付けた選択操作のデータ内容に従い以下の処理を行う。

【0087】

選択操作＝“再見積要求”のときは、中継事業体サーバ１は、前記集団ＩＤおよび前記参加者ＩＤと一致する集団ＩＤと参加者ＩＤを持つＡ７（特定見積ＤＢ）のレコードから「特定見積諾否回答」＝１（再見積）あるいは＝０（保留）であるレコード全てを抽出し、買い手側会員端末３に対し抽出したレコードに基づいて購入条件や参加者プロフィール等の変更条件を含む入力項目を編集し、編集した入力画面を表示させて入力データを受け付け、受け付けた前記レコードに格納し、選択操作＝“新規特定見積要求”のときは、中継事業体サーバ１は、Ａ７（特定見積ＤＢ）のレコードと特定見積要求番号を生成し、商品／サービス名（コード）、見積要求先売り手側企業ＩＤ、購入条件等および参加者プロフィールを含む入力項目の入力画面を表示させて入力データを受け付け、受け付けた入力データを参加者ＩＤおよび前記集団ＩＤと共に生成したレコードに書き込みＡ７（特定見積ＤＢ）に格納する。

【0088】

次いで、中継事業体サーバ１は、Ｋ：特定見積要求送信処理を行う。
中継事業体サーバ１は、上記Ｊで受信したＡ７（特定見積ＤＢ）のデータを売り手側企業サーバ５に向けて特定見積要求情報を売り手側企業毎に編集し、編集された特定見積要求書を売り手側企業サーバ５に対して送信する処理を行う。また、企業間競争を促すことを目的にＡ７（特定見積ＤＢ）のデータを集計・編集し売り手側企業サーバ５に送信する処理を行う。

【0089】

例えば、中継事業体サーバ１は、中継事業体サーバ１に対し集団ＩＤ特定処理を行い、得られた集団ＩＤと特定見積回数カウンターＤＢおよびＡ３（集団ＤＢ）から特定見積回数に適合する該当の特定見積要求受付期限のデータを取得し、処理時刻が特定見積要求受付期限を過ぎている場合、次の処理を行う。

【0090】

Ｋ１（個別特定見積要求情報の送信処理）は、特定見積要求の送信において、中継事業体サーバ１の第２の見積要求部１－６は、前記集団ＩＤと一致する集団ＩＤを持つＡ７（特定見積ＤＢ）のレコードから「今回見積要求の種類」＝１（新規）、＝２（再見積）である全てのレコードを抽出し、抽出したレコードにについて「見積要求先売り手側企業ＩＤ」を第１のＫＥＹ項目に、さらに「商品／サービス名（コード）」を第２のＫＥＹ項目にしてレコードを並び替え、並び替えたレコードに対し「見積要求先売り手側企業ＩＤ」をＫＥＹに同一「見積要求先売り手側企業ＩＤ」を持つレコードの全てを送信用特定見積情報として作成し次の処理を行う。見積要求先売り手側企業ＩＤをＫＥＹにＡ２（売り手側企業サーバＤＢ）を検索し見積要求先企業サーバ５を特定し、作成した送信用特定見積情報を当該見積要求先企業サーバ５に送信する。この処理を全ての見積要求先売り手側企業ＩＤについて行う。

【0091】

Ｋ２（特定見積要求情報の集計情報の送信処理）は、中継事業体サーバ１の第２の見積情報送信部１－７は、売り手側企業間の競争を促すためにＡ７（特定見積ＤＢ）のレコードから「検討ステータス」＝２（仮予約）である全てのレコードを抽出し、抽出したレコードから重複を除いた参加者ＩＤの数（純参加者数）を集計し合計参加者数を仮予約済み参加者数とし、レコード数（件数）を集計し合計件数を仮予約件数とし、数量を集計し合計数量を仮予約数量とするなど仮予約状況情報を作成し、全ての売り手側企業サーバ買い手側会員端末５に送信する。

【0092】

次いで、中継事業体サーバ１は、Ｌ：特定見積受信処理を行う。中継事業体サーバ１は、売り手側企業サーバから受信した特定見積情報をＡ７（特定見積ＤＢ）のレコードに入力する処理を行う。

【0093】

例えば、中継事業体サーバ１は、売り手側企業サーバ５から送信された特定見積情報を受け付け、受け付けた特定見積情報のレコードの特定見積要求ＩＤをＫＥＹ項目にして前記レコードに記録されている全ての特定見積要求ＩＤについて次の処理をおこなう。中継事業体サーバ１は、当該特定見積要求ＩＤと一致する特定見積要求ＩＤを持つＡ７（特定見積ＤＢ）のレコードを抽出し、抽出したレコードのうち「今回見積要求の種類」＝１（新規）あるいは、＝２（再見積）であるレコードに対して受信した特定見積データを書き込む。この処理を中継事業体サーバ１は、Ｋにおいて確定見積要求情報を送信した全ての売り手側企業サーバ５について行う。なお、この処理は特定見積要求ＩＤの値がユニークであり同じ値を持つことがないという特徴を利用している処理である。

【0094】

ステップＳ７において、中継事業体サーバ１は、Ｍ：特定見積送信処理を行う。Ａ７（特定見積ＤＢ）に格納されている売り手側企業サーバ５から受信した特定見積情報について、特定見積情報に含まれる参加者ＩＤのデータに基づき当該参加者の特定見積要求を行った買い手側会員端末３を特定し、当該特定見積情報を当該端末に対して送信する処理（Ｍ）を行う。すなわち、中継事業体サーバ１は、買い手側会員端末３が特定見積要求情報の中で指定した売り手側企業からの特定見積情報を当該買い手側会員端末３に送信する処理（Ｍ１）と、集団としての見積情報全体を買い手側会員端末３に伝え、買い手側会員端末３の参加者が特定見積結果に対する同意・不同意（諾否）や再見積要求などに役立ててもらうことを目的とする処理（Ｍ２）から成る。

【0095】

例えば、中継事業体サーバ１は、中継事業体サーバ１に対し集団ＩＤ特定処理を行い、得られた集団ＩＤとＡ３（集団ＤＢ）から該当の特定見積要求受付期限のデータを取得し、また得られた集団ＩＤと一致する集団ＩＤを持つＡ７（特定見積ＤＢ）のレコードについて、「今回見積要求の種類」＝１（新規）あるいは＝２の（再見積）である全てのレコードを抽出し、抽出した全てのレコード（特定見積情報全レコードＡと称する。）について、レコードの「諾否回答期限」＝前記特定見積諾否受付期限とした上で参加者ＩＤをＫＥＹ項目にして、参加者ＩＤ毎に参加者ＩＤに基づきＡ４（参加者ＤＢ）から買い手側会員端末３を特定し、当該参加者ＩＤを含むレコード全てを編集し、編集した特定見積情報を当該特定見積情報に関する同意・不同意（諾否）回答依頼文と共に特定された買い手側会員端末３へ送信する（Ｍ１）。Ｎ：諾否受信・処理も行う。

【0096】

さらに中継事業体サーバ１は、前記特定見積情報全レコードＡから、売り手側企業ＩＤ、商品／サービス名（コード）、見積額、見積内訳書、などのデータを抽出、商品／サービス名（コード）などの項目をＫＥＹに並び替えなどを行った上で特定見積結果全体情報として編集し、次いで前記特定見積情報全レコードＡの全てのレコードについて、レコードから参加者ＩＤを抽出、抽出した参加者ＩＤに基づきＡ４（参加者ＤＢ）から買い手側会員端末３を特定し、特定した買い手側会員端末３に対して前記特定見積結果全体情報の送信する処理を行う（Ｍ２）。

【0097】

次いで、中継事業体サーバ１は、Ｎ：諾否受信・処理を行う。中継事業体サーバ１は、買い手側会員端末３からの同意・不同意（諾否）情報を受信し、次の処理の選択を行う。

【0098】

例えば、中継事業体サーバ１は、買い手側会員端末３に対してログイン処理に続き集団ＩＤ特定処理を行い参加者ＩＤと集団ＩＤを得、得られた集団ＩＤと特定見積回数カウンターＤＢおよびＡ３（集団ＤＢ）から特定見積回数に適合する該当の特定見積要求受付期限のデータを取得し、処理時刻が特定見積諾否受付期限に到達していない場合は、次の処理を行う。中継事業体サーバ１は、前記集団ＩＤおよび前記参加者ＩＤと一致する集団ＩＤおよび参加者ＩＤをもつＡ７（特定見積ＤＢ）のレコードのううちレコードの「今回見積要求の種類」＝１（”新規”）あるいは＝２の（“変更”）である全てのレコードそれぞれに対応する諾否回答入力画面を編集作成し、作成した諾否回答入力画面買い手側会員端末３に表示し、入力データを受け付け、受け付けたデータを当該レコードの「諾否回答」のデータとして書き込み、「諾否回答」のデータに従って処理を行う。

【0099】

「諾否回答」＝０（保留）のとき処理なし。
「諾否回答」＝１（再見積）のとき処理なし。
「諾否回答」＝２（仮予約）のとき当該レコードの「検討ステータス」＝２（仮予約）とする。
「諾否回答」＝９（削除）のとき当該レコードを削除レコードＤＢに移した上で削除する。
「諾否回答」＝９９（退出）のとき参加者ＩＤを含むＡ７（特定見積ＤＢ）のレコードの全てを削除レコードＤＢに移した上で削除し、参加者ＩＤと一致する参加者ＩＤを持つＡ４（参加者ＤＢ）のレコードについて「参加状況」＝９９とする。

【0100】

この処理の結果、当該集団ＩＤと一致する集団ＩＤを持つＡ７（特定見積ＤＢ）のレコードの「諾否回答」は、保留、再見積、仮予約のいずれかとなる。

【0101】

ステップＳ８において、中継事業体サーバ１は、Ｏ：仮予約期限処理を行う。中継事業体サーバ１は、処理時刻が特定見積諾否回答期限（仮予約期限）の期日に到達しているかどうかチェックし、仮予約期限に到達していれば特定見積に関する参加者と売り手側企業とのやり取りの中継を終え次のステップへ進み、到達してなければ再特定見積要求を行う処理ステップに戻る。

【0102】

例えば、中継事業体サーバ１は、中継事業体サーバ１に対し集団ＩＤ特定処理を行い、得られた集団ＩＤと特定見積回数カウンターＤＢおよびＡ３（集団ＤＢ）から特定見積回数に適合する該当の特定見積要求受付期限のデータを取得し、得られたデータを仮約期限とし、次のように処理時刻と仮予約期限を比較し処理を選択する。

【0103】

処理時刻≦仮予約期限のとき、前記集団ＩＤと一致する集団ＩＤを持つ特定見積回数カウンターＤＢのレコードについて、レコードの特定見積回数データを特定見積回数＝特定見積回数＋１として前記レコードに格納し、ステップＳ６に戻る。

【0104】

処理時刻＞仮予約期限のとき、ステップＳ９へ進む。

【0105】

ステップＳ９において、中継事業体サーバ１は、Ｐ：仮予約処理・強制退出処理を行う。すなわち、特定見積終了に伴う処理を行う。

【0106】

例えば、Ａ７（特定見積ＤＢ）のレコードの「諾否回答」のデータが保留、再見積、仮予約のいずれかであることから、中継事業体サーバ１は、中継事業体サーバ１に対し集団ＩＤ特定処理を行い、得られた集団ＩＤと一致する集団ＩＤを持つＡ７（特定見積ＤＢ）の全てのレコードについて以下の処理を行う。

【0107】

中継事業体サーバ１は、前記レコードの「諾否回答」のデータ内容に従い次の処理を行う。

【0108】

「諾否回答」＝０（保留）、あるいは＝１（再見積）のとき、参加者ＩＤを含むＡ７（特定見積ＤＢ）のレコードの全てを削除レコードＤＢに移した上で削除し、参加者ＩＤと一致する参加者ＩＤを持つＡ４（参加者ＤＢ）のレコードの「参加状況」＝９９９（強制退出）とする。
「諾否回答」＝２（仮予約）のとき処理なし
この処理の結果、Ａ７（特定見積ＤＢ）の全てのレコードの「諾否回答」は、「諾否回答」＝２（仮予約）となる。

【0109】

次いで、ステップＳ１０において、中継事業体サーバ１は、Ｑ：１物１価の調整要求処理を行う。特定見積は繰り返し行われる可能性があるため、早い段階で仮予約した参加者と遅い段階で仮予約された参加者との間で同一売り手側企業であって同一商品／サービスでありながら見積金額に差が生じる可能性がある。集団内では、基本的に同一売り手側企業１物１価のルール（本処理Ｓｔａｒｔ時に同意を取り付けている）であり、このルールに沿って中継事業体サーバ１は売り手側企業に対して見積金額等調整を要求する処理を行う。ここで、同一売り手側企業１物１価とは、集団にとって同一企業、同一商品／サービスは１つの価格とすることである。Ｒ：調整済見積受信も行う。

【0110】

たとえば、中継事業体サーバ１は、中継事業体サーバ１に対し集団ＩＤ特定処理を行い、得られた集団ＩＤと一致する集団ＩＤを持つＡ７（特定見積ＤＢ）の全てのレコード（レコードＱと称する。）について以下の処理を行う。
１）レコードの「検討ステータス」＝２“仮予約”であることを確認する。
２）レコードの「要求・回答の種類」＝“１物１価調整要求”とする。

【0111】

次いで、中継事業体サーバ１は、前記レコードＢについて見積要求先売り手側企業ＩＤ毎にレコードを抽出し、抽出したレコードのデータを１物１価見積要求情報として編集・作成し、見積要求先売り手側企業ＩＤとＡ２（売り手側企業サーバＤＢ）から売り手側企業サーバ５を特定し、編集・作成した１物１価見積要求情報を当該売り手側企業サーバ５に送信する。この処理を見積要求先売り手側企業ＩＤの全てについて行う。

【0112】

次いで、中継事業体サーバ１は、Ｒ：調整済見積受信処理を行う。見積要求先の売り手側企業サーバ５は１物１価に調整済みの特定見積情報を送信し、中継事業体サーバ１は受信する。

【0113】

例えば、中継事業体サーバ１は、受信した同一売り手側企業１物１価に調整済みの特定見積情報を受け付け、受け付けた特定見積情報のレコードとＡ７（特定見積ＤＢ）のレコードの参加者ＩＤ、特定見積要求ＩＤ、見積要求先売り手側企業ＩＤのデータが一致する特定見積情報のレコードとＡ７（定見積ＤＢ）のレコードを抽出し、抽出した特定見積情報のレコードのデータを抽出したＡ７（特定見積ＤＢ）のレコードに格納する処理を受け付けた特定見積情報の全てのレコードについて行う。

【0114】

さらに、ステップＳ１１において、中継事業体サーバ１は、Ｓ：調整済見積送信処理を行う。同一売り手側企業１物１価に調整済みの特定見積情報を参加者の商品／サービスの買い手側会員端末３に送信し、参加者に同意・不同意（諾否）の回答を求める。Ｔ：諾否受信・予約処理も行う。

【0115】

例えば、中継事業体サーバ１は、中継事業体サーバ１に対し集団ＩＤ特定処理を行い、得られた集団ＩＤとＡ３（集団ＤＢ）から１物１価調整諾否受付期限のデータを取得し、処理時刻が１物１価調整諾否受付期限に到達していない場合、前記集団ＩＤを持つＡ７（特定見積ＤＢ）の全てのレコード（レコードＳと称する。）について以下の処理を行う。

【0116】

１）「要求・回答の種類」＝“１物１価調整要求”であることを確認する。
２）「諾否回答期限」＝１物１価調整諾否受付期限とする。
３）参加者の諾否意思表明を支援するために「諾否回答」の選択肢表示を、例えば、以下の通りに設定する。

【0117】

「諾否回答」＝０（保留）（初期値）
「諾否回答」＝３（予約）１物１価調整後見積に諾（承認）
「諾否回答」＝９（削除）１物１価調整後見積に否。退出ではない（他の商品があるなどの理由）。
「諾否回答」＝９９（退出）１物１価調整後見積を否定。集団を退出する。

【0118】

次いで、中継事業体サーバ１は、レコードＳについて参加者ＩＤをＫＥＹ項目にレコードを抽出し、参加者ＩＤ毎に抽出したレコードのデータを１物１価調整後特定見積情報として編集・作成し、作成した１物１価調整後特定見積情報と当該１物１価調整後特定見積情報に関する同意・不同意（諾否）回答依頼文とを、参加者ＩＤとＡ４（参加者ＤＢ）から特定された買い手側会員端末３へ送信する。この処理をレコードＳの参加者ＩＤの全てについて行う。

【0119】

また、中継事業体サーバ１は、Ｔ：諾否受信・予約処理を行う。中継事業体サーバ１は、参加者の商品／サービスの買い手側会員端末３から送られてきた１物１価調整後特定見積情報に対する諾否回答を受信し、諾否回答の内容に従って次へ進む選択の処理を行う。

【0120】

この処理は、例えば、以下の通りである。中継事業体サーバ１は、買い手側会員端末３に対して、ログイン処理に続き集団ＩＤ特定処理を行い、参加者ＩＤと集団ＩＤを得る。得られた集団ＩＤとＡ３（集団ＤＢ）から１物１価調整諾否受付期限のデータを取得し、処理時刻が１物１価調整諾否受付期限に到達していない場合、前記ログイン処理で取得した参加者ＩＤを含むＡ７（特定見積ＤＢ）のレコードのデータに基づいて参加者ＩＤ、特定見積要求ＩＤ、見積要求先売り手側企業ＩＤを含む１物１価調整諾否回答画面を編集・作成し、作成した１物１価調整諾否回答画面を前記買い手側会員端末３に表示し、諾否回答入力を受け付け、受け付けた諾否回答データを、受け付けた１物１価調整後特定見積情報の参加者ＩＤ、特定見積要求ＩＤ、見積要求先売り手側企業ＩＤの３つのデータが一致するデータを持つＡ７（特定見積ＤＢ）のレコードの「諾否回答」に格納する。

【0121】

上記処理は、処理時刻が１物１価調整諾否受付期限に到達するまで行う。

【0122】

次いで、中継事業体サーバ１は、中継事業体サーバ１に対し集団ＩＤ特定処理を行い、得られた集団ＩＤとＡ３（集団ＤＢ）から１物１価調整諾否受付期限のデータを取得し、処理時刻が１物１価調整諾否受付期限を過ぎている場合、Ａ７（特定見積ＤＢ）の全てのレコードについて以下の予約処理を行う。

【0123】

すなわち「諾否回答」＝０（保留）のとき、参加者ＩＤを含むＡ７（特定見積ＤＢ）のレコードの全てを削除レコードＤＢに移した上で削除し、参加者ＩＤと一致する参加者ＩＤを持つＡ４（参加者ＤＢ）のレコードの「参加状況」＝９９９（強制退出）とする。これは、受付期限内に諾否回答を受信していないか、保留のままであるからである。

【0124】

「諾否回答」＝３（予約）のとき、参加者ＩＤと一致する参加者ＩＤを持つＡ４（参加者ＤＢ）のレコードの「参加状況」＝1（参加中）とする。「諾否回答」＝９（削除）のとき、当該レコードを削除レコードＤＢに移した上で削除する。

【0125】

「諾否回答」＝９９（退出）のとき参加者ＩＤを含むＡ７（特定見積ＤＢ）のレコードの全てを削除レコードＤＢに移した上で削除し、参加者ＩＤと一致する参加者ＩＤを持つＡ４（参加者ＤＢ）のレコードの「参加状況」＝９９とする。この処理の結果、Ａ７（特定見積ＤＢ）は“予約”の１種のみである。

【0126】

ステップＳ１２において、中継事業体サーバ１の代金情報送信部１－８は、Ｕ：指定口座入金案内処理を行う。これは、中継事業体が指定口座を設定し、予約処理で買い手が承認した見積額の代金の入金案内を行うものである。例えば、中継事業体サーバ１は、Ａ７（特定見積ＤＢ）の全てのレコードの「指定口座情報」に指定口座情報値を書き込み、Ａ７（特定見積ＤＢ）の全てのレコードについて、以下の処理を行う。中継事業体サーバ１は、Ａ３（集団ＤＢ）から代金入金期限を取得し、レコード毎にレコードの「参加者ＩＤ」のデータと一致する「参加者ＩＤ」データを持つＡ４（参加者ＤＢ）から当該参加者の買い手側会員端末３を特定し当該買い手側会員端末３に指定口座情報、金額（見積額）、代金入金期限）の情報を送信する。

【0127】

次いで、Ｔ：諾否受信・予約処理も行う。

【0128】

中継事業体サーバ１は、Ｖ：入金確認・強制退出処理を行う。中継事業体サーバ１は、代金入金期限後に指定口座入金・残高情報を確認し、未入金の場合は代金入金期限を過ぎていることから、当該参加者の強制退出処理を行う。

【0129】

例えば、中継事業体サーバ１は、中継事業体サーバ１に対し集団ＩＤ特定処理を行い、得られた集団ＩＤとＡ３（集団ＤＢ）から代金入金期限を取得し処理時刻と共に中継事業体サーバ１に表示させ、中継事業体サーバ１の管理運営者は処理時刻が代金入金期限を過ぎている場合、指定口座の入金実績（入金した参加者ＩＤと入金金額）を確認し、入金実績の全てについて、入金金額を前記参加者ＩＤおよび前記集団ＩＤと一致する参加者ＩＤおよび集団ＩＤを持つＡ７（特定見積ＤＢ）のレコードの指定口座残高情報に入力し、格納する。次いで、中継事業体サーバ１は、前記集団ＩＤと一致する集団ＩＤを持つＡ７（特定見積ＤＢ）のレコードの指定口座残高情報の残高データがゼロであるレコードの参加者ＩＤを抽出し、前記参加者ＩＤを持つＡ７（特定見積ＤＢ）のレコードの全てを削除レコードＤＢに移した上でＡ７（特定見積ＤＢ）から削除する（強制退出処理）。この結果、Ａ７（特定見積ＤＢ）の全てのレコードの「諾否回答」は「諾否回答」＝３（予約）であり、指定口座残高情報には入金された金額が記録されている。

【0130】

ステップＳ１３において、中継事業体サーバ１は、Ｗ：集団見積要求処理を行う。参加者から買い手側会員端末指定口座に着金（入金）しており、中継事業体サーバ１はこの着金した金額を売り手側企業サーバ５に表示することにより売り手側企業に対して集団見積を要求する。集団見積要求とは“予約”の参加者からの指定口座着金金額を売り手側企業毎に集計し、集計された金額合計を支払実施可能な金額として売り手側企業毎に示すことにより見積の再考を要求するものである。Ｘ：集団見積受信も行う。

【0131】

たとえば、中継事業体サーバ１は、中継事業体サーバ１に対し集団ＩＤ特定処理を行い、得られた集団ＩＤと一致する集団ＩＤを持つＡ７（特定見積ＤＢ）の全てのレコード（レコードＷと称する。）について「今回見積要求の種類」＝２（資金到着後交渉）とする。さらにレコードＷについて見積要求先売り手側企業ＩＤ毎にレコードを抽出し次の処理を行う。即ち前記レコードの指定口座残高情報のデータを集計し集計結果を対売り手側企業支払可能金額とし、さらに前記レコードのデータを編集し対売り手側企業予約一覧情報を作成した上で、当該見積要求先売り手側企業ＩＤとＡ２（売り手側企業ＤＢ）から売り手側企業サーバ３を特定し、特定された売り手側企業サーバ５に対し対売り手側企業支払可能金額と対売り手側企業予約一覧情報を集団見積要求のメッセージと共に送信する。この処理をレコードＷに含まれる見積要求先売り手側企業ＩＤの全てについて行う。なお、前記集団見積要求メッセージは、たとえば「貴社への送金実施可能金額合計は〇〇円、ただし、参加者は予約を取り止めることができる。集団として再度の見積を要求する」などの趣旨を含んでも良い。

【0132】

次に、中継事業体サーバ１は、Ｘ：集団見積受信処理を行う。

【0133】

例えば、中継事業体サーバ１は、売り手側企業サーバ５から送信された特定見積情報を受け付け、受け付けた特定見積情報のレコードから集団ＩＤ、特定見積要求ＩＤと見積金額、見積内訳書情報などのデータを抽出し、抽出したデータを売り手側企業が入力する項目のデータとして前記集団ＩＤおよび前記特定見積要求ＩＤと一致する集団ＩＤおよび特定見積要求ＩＤを持つＡ７（特定見積ＤＢ）のレコードに書き込む。この処理を中継事業体サーバ１は、受け付けた特定見積情報の全てのレコードについて行い、またＷにおいて特定見積要求情報を送信した全ての売り手側企業サーバ５について行う。

【0134】

ステップＳ１４において、中継事業体サーバ１は、Ｙ：集団見積送信処理を行う。この処理では、集団見積として受信した特定見積情報と諾否回答お願いメッセージを予約の参加者に送信する処理を行う。Ｚ：諾否受信・確定処理も行う。

【0135】

例えば、中継事業体サーバ１は、中継事業体サーバ１に対し集団ＩＤ特定処理を行い、得られた集団ＩＤと一致する集団ＩＤを持つＡ７（特定見積ＤＢ）の全てのレコードについてレコード毎に以下の処理を行う。

【0136】

レコードの「要求・回答の種類のデータ」＝２（資金到着後交渉）であることを確認する。
１）中継事業体サーバ１は、中継事業体サーバ１に対し集団ＩＤ特定処理を行い、得られた集団ＩＤとＡ３（集団ＤＢ）から集団見積諾否受付期限を取得する。
２）次いで、中継事業体サーバ１は、前記集団ＩＤと一致する集団ＩＤを持つＡ７（特定見積ＤＢ）のレコードの全てを抽出し（レコードＹと称する）、レコードＹについて参加者ＩＤ毎にレコードを抽出し、抽出したレコードの諾否回答期限＝前記集団見積諾否受付期限とし、さらに当該レコードのデータを特定見積（集団見積）情報として編集・作成し、編集・作成された特定見積（集団見積）情報と当該特定見積（集団見積）情報に関する同意・不同意（諾否）回答依頼文とを参加者ＩＤとＡ４（参加者ＤＢ）から買い手側会員端末３を特定し、特定された買い手側会員端末３に対し送信する。この処理をレコードＹに記録されている参加者ＩＤの全てについて行う。

【0137】

次に、Ｚ：諾否受信・確定処理を行う。この処理は、参加者の所持する商品／サービスの買い手側会員端末３から送られてきた”資金到着後交渉”見積に対する諾否回答受信し、確定処理を行う。

【0138】

例えば、中継事業体サーバ１は、買い手側会員端末３に対しログイン処理に続き集団ＩＤ特定処理を行い、得られた集団ＩＤとＡ３（集団ＤＢ）から集団見積諾否受付期限を取得し、処理時刻が集団見積諾否受付期限に到達していない場合、ログイン処理で得られた参加者ＩＤと一致する参加者ＩＤをもつＡ７（特定見積ＤＢ）のレコード（レコードＺと称する。）を抽出し、抽出したレコードのデータに基づいて特定見積要求ＩＤを含む諾否回答入力画面を編集・作成し、編集・作成した諾否回答入力画面を表示する。諾否回答表示については、参加者の諾否意思表明サポートするために選択肢表示を以下の通りとする。

【0139】

「諾否回答」＝０ （保留）（初期値）
「諾否回答」＝４ （確定）（集団見積としての特定見積に諾）
「諾否回答」＝９ （削除）（集団見積としての特定見積に否。退出ではない）
「諾否回答」＝９９（退出）（集団見積としての特定見積を否。退出）

【0140】

次いで、中継事業体サーバ１は、表示されている特定見積要求ＩＤのデータおよび諾否回答入力を受け付け、受け付けたデータを前記特定見積要求ＩＤと一致する前記レコードＺのレコードの諾否回答のデータとし、Ａ７（特定見積ＤＢ）に格納する。買い手側会員端末に対する上記処理は処理時刻が集団見積諾否受付期限に到達するまで行う。

【0141】

次いで、中継事業体サーバ１は、Ａ３（集団ＤＢ）から集団見積諾否受付期限を取得し、処理時刻が集団見積諾否受付期限を過ぎている場合、次の取引確定処理を行う。例えば、中継事業体サーバ１は、中継事業体サーバ１に対し集団ＩＤ特定処理を行い、得られた集団ＩＤと一致する集団ＩＤを持つＡ７（特定見積ＤＢ）の全てのレコード（レコードＺ２と称する。）について次の処理を行う。レコード毎に当該レコードの「諾否回答」のデータ内容に従い以下の処理を行う。

【0142】

「諾否回答」＝０（保留）のとき、強制退出処理を行う。すなわち、前記集団ＩＤおよび当該レコードの参加者ＩＤと一致する集団ＩＤおよび参加者ＩＤを持つＡ７（特定見積ＤＢ）のレコードの全てを削除レコードＤＢに移した上でＡ７（特定見積ＤＢ）から削除し、前記集団ＩＤおよび前記参加者ＩＤと一致する集団ＩＤおよび参加者ＩＤを持つＡ４（参加者ＤＢ）のレコードの「参加状況」＝９９９（強制退出）とする。これは、受付期限内に諾否回答を受信していないか、保留のままであるからである。

【0143】

「諾否回答」＝４（確定）のとき、処理なし。

【0144】

「諾否回答」＝９（削除）のとき、さらにレコードＺ２に当該参加者ＩＤを持つレコードが当該レコード以外にある場合とない場合を判定し、ある場合は、当該レコードを削除レコードＤＢに移した上で削除し、ない場合は、前記強制退出処理を行う。

【0145】

「諾否回答」＝９９（退出）のとき、退出処理を行う。すなわち、前記集団ＩＤおよび当該レコードの参加者ＩＤと一致する集団ＩＤおよび参加者ＩＤを持つＡ７（特定見積ＤＢ）のレコードの全てを削除レコードＤＢに移した上でＡ７（特定見積ＤＢ）から削除し、前記集団ＩＤおよび前記参加者ＩＤと一致する集団ＩＤおよび参加者ＩＤを持つＡ４（参加者ＤＢ）のレコードの「参加状況」＝９９（退出）とする。

【0146】

次いで、中継事業体サーバ１は、Ａ７（特定見積ＤＢ）の全てのレコードの検討ステータスについて「検討ステータス」＝４（確定）とする。

【0147】

次いで、ステップＳ１５において、中継事業体サーバ１は、ＡＡ：確定通知処理を行う。まず、中継事業体サーバ１は、参加者の商品／サービスの買い手側会員端末３、売り手側企業サーバ５の双方に確定通知を送信する。売り手側企業はこの確定通知を受け取ることにより納品・納入・着手を行うことができる。

【0148】

例えば、中継事業体サーバ１は、中継事業体サーバ１に対し集団ＩＤ特定処理を行い、得られた集団ＩＤと一致するＡ７（特定見積ＤＢ）の全てのレコードについて、レコード毎に当該レコードの参加者ＩＤおよび見積要求先売り手側企業ＩＤのデータとＡ４（参加者ＤＢ）およびＡ２（売り手側企業サーバＤＢ）から買い手側会員端末３と売り手側企業サーバ５を特定し、特定された買い手側会員端末３と売り手側企業サーバ５に対し買い手側会員端末当該レコードのデータを確定購入・販売情報として編集・作成し作成・編集した確定購入・販売情報と確定通知のメッセージと共に送信する。

【0149】

次いで、ステップＳ１６において、中継事業体サーバ１は、ＢＢ：受渡完了受信処理を行う。中継事業体サーバ１は、買い手側会員端末３に対してログイン処理に続き集団ＩＤ特定処理を行い参加者ＩＤと集団ＩＤを得る。得られた集団ＩＤおよび得られた参加者ＩＤと一致する集団ＩＤおよび参加者ＩＤを持つＡ７（特定見積ＤＢ）のレコード（レコードＢＢと称する。）のデータに基づいて編集・作成した確定購入・販売情報と受渡完了回答画面を表示し、確定購入・販売情報のうちの特定見積要求ＩＤと共に諾否回答入力（“完了”か“未完了”）を受け付け、受け付けた諾否回答のデータを、レコードＢＢの「受渡完了情報」に格納する。ＣＣ：送金指示処理も行う。

【0150】

中継事業体サーバ１は、ＣＣ：送金指示処理を行う。中継事業体サーバ１は、中継事業体サーバ１の管理運営者に対し受渡完了情報を表示し、前記管理運営者は指定口座を管理する者に対し当該売り手側企業に受渡完了情報の送信および当該売り手側企業への送金を指示する。

【0151】

例えば、中継事業体サーバ１は、中継事業体サーバ１に対し集団ＩＤ特定処理を行い、得られた集団ＩＤと一致する集団ＩＤを持つＡ７（特定見積ＤＢ）のレコードの「受渡完了情報」のデータが“完了”である全てのレコードについて、レコード毎に当該レコードのデータを編集し送金指示情報を編集・作成し、編集・作成した送金指示情報を指定口座の管理者に伝える。

【0152】

以上の処理を踏まえ、中継事業体サーバ１の管理運営者は、参加者に対して指定口座入金額と売り手側企業への送金指示金額との差額精算などを行うことも良い。

【0153】

以上の処理により、以下の効果を発揮することができる。集団購入のために一時的に集団を組成し、購買力を大きくして、参加者の自由（商品選択の自由）を最大限守りながら、目的達成までの集団の継続性を確保することができる。

【0154】

多数の人が集まり、より大きい規模の購買力を背景により有利な購入経済活動が可能になる。取引全体として価格を下げる方向に進むため参加者の経済的メリットをより大きくすることができる。

【0155】

また、複数の売り手側企業サーバから見積を取ることもできる。そのような場合には、購入条件と対象売り手側企業サーバとを変えながら繰り返し見積要求を行うこともできる。但し、得られた見積情報は、他の売り手側企業サーバには伝えないようにすることが好ましい。なぜなら、売り手側企業サーバの注目先が顧客（参加者）でなくライバル側の売り手側企業サーバに移ってしまう可能性が高いからである。

【0156】

具体的な効果の例：
１）参加者の期待する商品（通称）と売り手側企業の商品（コード）の対応を明らかにすることができる。
２）得られた対応を、例えば“一覧表”にして公開することができる（例えば各売り手の “広告ビラの集り”）。これにより、売り手側企業間の競争と参加者側の選択行動との出発点とすることができる。
３）集団の参加者の買い手側会員端末３の規模（人数＝端末の台数）と購入検討の内容と量を報知することにより購買力規模のメリット追求の出発点とすることができる。
４）複数の売り手側企業サーバ５に見積を依頼し、見積を取得する。買い手側会員端末３が納得するという操作が行われるまで処理（見積依頼）を繰り返すことができる。
５）途中別途売り手や商品（コード）を変更しても良いルールで、参加者の選択の自由を実現し売り手側企業の競争を誘引することができる。
６）一般的な取引支援システムの構想の対売り手の個人の買い手の弱点は支払いに対する信用である。そこで、商品／サービスを予約したところで指定口座に入金を促す。これにより、集団（中継事業体サーバ）は口座残高を信用の根拠とすることができる。
７）具体的には、指定口座入金残高合計情報を売り手側企業サーバ５に示し、集団に対する信用とし、後述の集団見積要求の基礎とすることができる。
８）同一の売り手側企業サーバ５において同一商品／サービスは同一価格である。複数人が購入する時には、同一価格である。中継事業体サーバ１が最も低い価格に調整するよう売り手側企業サーバ５に要求する。これにより、集団形成のメリットの追求することができる。
９）集団（中継事業体サーバ）は複数人や複数種類商品購入予約に関し、売り手側企業に対しそれらの合計人数、合計金額、指定口座残高を示した上で、当該売り手側企業購入予約参加者全員について集団見積要求を行う。併せて回答の見積結果を参加者が承認しない場合は、予約は取り消されるルールであることを改めて確認する。これを参加者が行うのではなく集団（中継事業体サーバ）が行うことから集団参加のメリット、および購買力規模のメリット追求することができる。
１０）参加者の選択の自由の一つとして、取引確定前はいつでも集団から抜けられることが挙げられる。取引確定後の退出は法令等に沿って別途対応することになる。

【0157】

これにより、集団としてのまとまりのための参加者に対する規範の一つとして、予め約束した期限等を守らない場合は集団から退出を促す。

【0158】

以下に、上記の取引支援処理に関する具体的かつ例示的な説明を行う。

【0159】

（商品／サービスの具体例の説明）
本実施の形態で対象とする商品／サービスは、個人向けの商品／サービス（以下、この項目では、「商品」と呼ぶ）である。

【0160】

商品の大まかな分類名とは、例えば、「ルームエアコン」、「軽自動車」などであり、カテゴリを明確にするが、選択肢を絞りすぎないようにする方が良い。

【0161】

商品名の通称は、例えば、ルームエアコンの霧ケ峰（登録商標）などである。

【0162】

商品を一意に特定する名称は、例えば、ルームエアコン霧ケ峰MSZ-S2217-Wなどで指定する。

【0163】

集団に名称を付ける場合には、何の商品／サービスの集団購入なのか分かりやすい名称（名称は任意であるが、ある程度内容がわかるようにする）が良い。例えば、「エアコン集団購入の会」などである。

【0164】

登録会員が、当該商品に関わる価格、商品販売・利用条件、商品説明に関する情報提供を要求すること、また問合せすることができる。

【0165】

当該商品に関わる見積書記載の主要事項（見積条件、価格など）および見積書、商品説明、問合せ応答の処理が行われる。

【0166】

とくに参加者にとっては支払金額がいくらになるかは重要で、価格については売り手側企業サーバに支払う本体金額やオプション料金、その他に売り手側企業サーバ５が買い手側会員端末３から預かり支払う費用（例えば、消費税や車購入のときの自動車税など）も問い合わせることができる。

【0167】

（集団購入の会、集団購入プロジェクトの組成・設置者の具体例）
集団購入の会は、「集団購入を希望する人の集り」の趣旨に賛同する会員（自然人）（買い手側会員端末３を所持する。）からなる。

【0168】

買い手側会員端末３を所持する会員は、集団購入の会などから会員登録が承認された自然人である。買い手側会員端末３を所持する会員は集団購入プロジェクト参加者募集の案内を受ける。

【0169】

中継事業体サーバ１は、特定の商品名（募集）について募集要項を示した上で会員から参加者を募り、買い手側会員端末３の操作に基づいて、集団購入を進める。当該集団の会員は、集団購入集団の参加者募集に応募し登録が認められた会員である。当該会員は、参加応募時において購入を希望する商品について検討しており、数種までに絞り込んでいる。

【0170】

中継事業体サーバ１を運営する職員は、集団購入プロジェクト事務局担当者である。売り手側企業サーバ５は、中継事業体サーバ１が募集公表前までに予め集団購入協力の承諾を得ている企業のサーバである。企業名等は募集要項に記載しても良い。

【0171】

或いは、集団が企業サーバを引き寄せる逆市場として機能するようにしても良い。

【0172】

図５は、本実施の形態による取引支援の概要を示す図であり、中継事業体サーバ１、買い手側会員端末３の集団、チーム、というように、集団は、図に示すような階層構造（例えばツリー構造）をなす。中継事業体サーバ１を運営する運営体としては、人の側に立つ運営が必要であるという意味で社員が個人に限定されている一般社団法人などが例示的に挙げられる。

【0173】

ツリー構造の上層に中継事業体サーバ１、下層に複数の集団（買い手側会員端末３群）買い手側会員端末が形成されている逆市場のイメージ図となる。

【0174】

図６は、取引対象商品が自動車である場合の集団形成と取引状態の一例を図式的に示すイメージ例の図である。

【0175】

図６に示すように、自動車という大まかなカテゴリで募集されたＴＮという地域の集団である新規名称：ＴＮくるま購入集団が形成されたとする。このＴＮくるま購入集団中には、例えば、Ｔ社の自動車（Ｔ車）が好きなＴ車好きチーム、小型車が好きな小型車好きチーム、その他の自動車が好きなその他の車好きチームがそれぞれ、５０人、３０人、２０人で結成されているとする。この集団で、中継事業体サーバ１から購入提案、見積要求がなされると、少なくとも売り手側企業サーバ５のＡ社サーバ、Ｂ社サーバ、Ｃ社サーバ、Ｄ社サーバのいずれか１から見積が提案され、これを参照して、最終的には、当該集団（買い手側会員端末３）中で、８０人が自動車を購入し、２０人が購入しなかった（集団から離脱又は本取引から退出した）。そして、当初の初期登録時とは異なる自動車を購入する個人もいるため、最終的には、Ａ社は、Ｔ車を３０人に販売し、Ｂ社はＮ車を２０人に販売し、Ｃ社はＨ車を３０人に販売することができた。

【0176】

この際、重要なことは、購入希望者が集団を形成しているため、個人であっても、企業のような大きな規模の購入者と同じように価格交渉優位性を持つことである。

【0177】

（集団購入プロジェクト参加者募集要項の具体例）
以下に、集団購入プロジェクト参加者募集要項に記載される項目の一例について具体的に説明する。
１）集団購入プロジェクの名称および／または集団ＩＤ番号
２）商品名（募集）：商品の大まかな分類名
３）応募期限、会（集団）成立・不成立条件
４）見積諾否回答締切日（１次、２次、これらは任意）、代金入金締切日、対売り手側企業への送金予定日
５）売り手企業名リスト（募集開始後追加もある）
６）応募者（買い手側会員端末３）が応募条件（集団不成立条件、会則（参加者権利停止条件含む）に同意したときに中継事業体サーバ１は参加者（買い手側会員端末３）として登録する
７）参加者（買い手側会員端末３）が見積諾否回答締切日（１次、２次）、代金入金締切日を守らなかったときなどの規定
８）参加者の登録数等が成立条件を満たした時、集団購入プロジェクが正式発足する。

【0178】

参加者（買い手側会員端末３）が購入希望商品（商品／サービス名（コード））の「諾否」判断する（売り手側企業サーバ５間の競争、購入意思の集約）。

【0179】

参加者（買い手側会員端末３）の最終意思を集約（中継事業体サーバ１の職員であるコーディネーターが確認・集約する）。

【0180】

参加者（買い手側会員端末３）は、代金を指定口座に入金する。この入金を以って購入意思の最終確認とする。

【0181】

集団購入プロジェクト事務局（中継事業体サーバ１）が商品受け渡し完了報告を確認し、指定口座から売り手側企業へ送金する。

【0182】

参加者（買い手側会員端末３）が自らの意思により集団購入プロジェクト参加を中止、退出した場合の一切の権利を停止する処置を行うことができる。

【0183】

会員権利停止条件に該当する時に集団購入プロジェクトとして処置。無条件に一切の権利を停止する処置することができる。

【0184】

指定口座は、代金の送金先口座である。中継事業体サーバ１（集団事務局）は、指定口座において参加者（買い手側会員端末３）からの支払金をまとめて預かる。

【0185】

（処理の流れの概要）
１）中継事業体サーバ１は、対象商品名（募集）、集団における自由と制限を含んだ募集要項を示したうえで参加者（買い手側会員端末３）を募集、集団を組成する。
２）集団参加者（図４参照：買い手側会員端末３）は売り手側（売り手側企業サーバ５）から基準となる見積情報を集め、集団内でまとめて共有し、共有していることを売り手（売り手側企業サーバ５）に知らせる。
３）商品名と購入検討者数を示すことにより、集団の購買力の規模を売り手（売り手側企業サーバ５）に示す。
４）集団参加者（買い手側会員端末３）は売り手側（売り手側企業サーバ５）に対し仮予約に至るまで複数回の特定見積要求を行うようにすることもできる。
５）売り手（売り手側企業サーバ５）からの見積を売り手全体と買い手毎にまとめ、かつ買い手毎に整理、その両方の情報を買い手毎に送信する。
６）参加者（買い手側会員端末３）の購入意思確定は指定口座入金を以って行い、確定結果を売り手（売り手側企業サーバ５）に通知する。受渡結果通知を得た上で、売り手へ送金指示する。
７）集団は仮予約後、同一売り手内「１物１価」調整により、同一売り手・同一商品を買い手全員が最も安価な価格への調整を要求する。
８）集団（買い手側会員端末３）は予約後の指定口座入金を以って、指定口座残高合計と売り手側企業（売り手側企業サーバ５）毎に合計人数・合計額を示し集団見積要求を行う。
９）集団参加者（買い手側会員端末３）が上記集団見積を承認すれば買う・売るが確定する。
１０）集団参加者（買い手側会員端末３）は確定するまでは取り止めることも含め自由である。
１１）集団は、商品が参加者（買い手側会員端末３の所持者）の元に届き、受渡完了通知を受け取り後に、指定口座に対し当該売り手企業への送金を指示する。
１２）中継事業体サーバ１は、検討取り止めや退出の処理を行う。

【0186】

このようにして、本実施の形態は個人が買い手である個人市場においてパラダイムシフトを引き起こすことができる。

【0187】

本実施の形態によれば、商品／サービスの取引規模を大きくして購入者側のスケールメリットを生かすことができる。例えば、集団における自由と規則の下に「より良いものをより安く」という目標に向けて個人の集団を組成し、集団という規模のメリット、複数の売り手間の競争も誘発しながら購入行動プロセス(取引)を支援する取引支援技術を提供することができる。

【0188】

なお、上記の処理および制御は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）やＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）によるソフトウェア処理、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）やＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）によるハードウェア処理によって実現することができる。

【0189】

また、上記の実施の形態において、図示されている構成等については、これらに限定されるものではなく、本発明の効果を発揮する範囲内で適宜変更することが可能である。その他、本発明の目的の範囲を逸脱しない限りにおいて適宜変更して実施することが可能である。

【0190】

また、本発明の各構成要素は、任意に取捨選択することができ、取捨選択した構成を具備する発明も本発明に含まれるものである。

【0191】

また、本実施の形態で説明した機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより各部の処理を行ってもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。

【0192】

また、「コンピュータシステム」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。

【0193】

また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ－ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含むものとする。また前記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであっても良い。機能の少なくとも一部は、集積回路などのハードウェアで実現しても良い。

【産業上の利用可能性】

【0194】

本発明は、取引支援システムに利用可能である。

【符号の説明】

【0195】

Ａ 取引支援システム（装置）
１ 中継事業体サーバ（中継サーバ，取引支援サーバ）
１－１ 募集要項送信部
１－２ 集団形成促進部
１－３ 第１の見積要求部
１－４ 第１の見積情報送信部
１－５ 購入希望操作受信部
１－６ 第２の見積要求部
１－７ 第２の見積情報送信部
１－８ 代金情報送信部
３ 商品／サービス買い手側会員端末
５ 商品／サービス売り手側企業サーバ
（ＤＢ）１ｘ－１ 会員データベース（買い手側会員端末データベース）
（ＤＢ）１ｘ－２ 売り手側企業サーバデータベース
（ＤＢ）１ｘ－３ 集団データベース
（ＤＢ）１ｘ－４ 集団への参加者データベース
（ＤＢ）１ｘ－５ 一般見積結果全体情報データベース
（ＤＢ）１ｘ－６ 一般見積データベース
（ＤＢ）１ｘ－７ 特定見積データベース
（ＤＢ）１ｘ－８ 特定見積結果全体情報データベース

【図1A】

【図1B】

【図2】

【図3】

【図4】

【図5】

【図6】