サーバ装置が、1以上の第1の端末装置のうちの任意の第1の端末装置から、商品またはサービスを示すとともに当該商品またはサービスを販売する条件を示す販売条件データを受信する販売条件データ受信ステップと、前記サーバ装置が、商品またはサービスの販売を許可するための条件を示す許可条件データを記憶する許可条件データ記憶ステップと、前記サーバ装置が、1以上の第2の端末装置のうちの任意の第2の端末装置から、商品またはサービスを示すとともに当該商品またはサービスに関する評価を示す評価データを受信する評価データ受信ステップと、前記サーバ装置が、前記評価データ受信ステップにおいて受信した評価データにより示される一の商品またはサービスに関する評価に基づき、前記許可条件データ記憶ステップにおいて記憶した当該一の商品またはサービスに関する許可条件データにより示される条件が満たされたか否かを判定する判定ステップと、前記サーバ装置が、前記判定ステップにおいて一の商品またはサービスに関し前記条件が満たされたと判定した場合に限り、前記販売条件データ受信ステップにおいて受信した販売条件データのうち当該一の商品またはサービスを示す販売条件データにより示される条件に従い当該一の商品またはサービスの販売の申し出を示す販売申出データを前記1以上の第2の端末装置のうちの少なくとも1の第2の端末装置に送信する販売申出データ送信ステップとを備える方法。前記サーバ装置が、前記販売申出データ送信ステップにおいて送信した販売申出データの送信先の第2の端末装置から、一の商品またはサービスの購入の申し込みを示す購入申込データを受信する購入申込データ受信ステップを備え、前記販売条件データ受信ステップにおいて前記サーバ装置が受信する一の商品またはサービスに関する販売条件データは、前記購入申込データ受信ステップにおいて受信した購入申込データにより購入が申し込まれた当該一の商品またはサービスの総量が所定の閾値以上である場合に限り、もしくは当該総量が所定の閾値を超過する場合に限り、当該一の商品またはサービスの販売を実施するという条件を示す請求項1に記載の方法。前記サーバ装置は、前記判定ステップにおいて、前記販売条件データ受信ステップにおいて複数の異なる第1の端末装置から受信した複数の販売条件データを所定の規則に従いグループ化して得られる一のグループに属する複数の販売条件データの各々に関し、当該販売条件データにより示される一の商品またはサービスに関し前記評価データ受信ステップにおいて受信した評価データにより示される評価に基づく指標を生成し、当該一のグループに属する複数の販売条件データの各々に関し生成した当該指標の比較結果に基づき当該複数の販売条件データのうちの少なくとも1の販売条件データを選択し、当該選択した少なくとも1の販売条件データにより示される商品またはサービスに関し前記許可条件が満たされたと判定する請求項1または2に記載の方法。前記サーバ装置が、前記評価データ受信ステップにおいて受信した評価データの送信元の第2の端末装置を識別する端末識別データを記憶する端末識別データ記憶ステップを備え、前記サーバ装置は、前記販売申出データ送信ステップにおいて、前記端末識別データ記憶ステップにおいて記憶した端末識別データにより識別される第2の端末装置に対し、前記端末識別データ記憶ステップにおいて記憶した端末識別データにより識別されない第2の端末装置と比較して安価な販売価格で一の商品またはサービスの販売を申し出ることを示す前記販売申出データを送信する請求項1乃至3のいずれかに記載の方法。前記サーバ装置が、前記1以上の第2の端末装置の各々に関し、当該第2の端末装置の使用者の属性を示す属性データを記憶する属性データ記憶ステップを備え、前記サーバ装置は、前記判定ステップにおいて、前記評価データ受信ステップにおいて受信した評価データの送信元の第2の端末装置の使用者に関し前記属性データ記憶ステップにおいて記憶した属性データにより示される属性に基づき、前記判定を行う請求項1乃至4のいずれかに記載の方法。前記サーバ装置が、前記評価データ受信ステップにおいて受信した一の商品またはサービス以外の他の商品またはサービスに関する評価データにより示される評価に基づき、当該一の商品またはサービスの販売を許可する条件を示す許可条件データを生成する許可条件データ生成ステップを備え、前記サーバ装置は、前記許可条件データ記憶ステップにおいて、前記許可条件データ生成ステップにおいて生成した許可条件データを記憶する請求項1乃至5のいずれかに記載の方法。前記サーバ装置が、前記販売条件データ受信ステップにおいて受信した一の商品またはサービスに関する販売条件データにより示される条件に基づき、当該一の商品またはサービスの販売を許可する条件を示す許可条件データを生成する許可条件データ生成ステップを備え、前記サーバ装置は、前記許可条件データ記憶ステップにおいて、前記許可条件データ生成ステップにおいて生成した許可条件データを記憶する請求項1乃至5のいずれかに記載の方法。他の通信装置から送信されてくるデータを受信する受信手段と、データを記憶する記憶手段と、演算処理を行う演算手段と、データを他の通信装置に送信する送信手段とを備え、前記受信手段は、1以上の第1の端末装置のうちの任意の第1の端末装置から、商品またはサービスを示すとともに当該商品またはサービスを販売する条件を示す販売条件データを受信し、前記記憶手段は、商品またはサービスの販売を許可するための条件を示す許可条件データを記憶し、前記受信手段は、1以上の第2の端末装置のうちの任意の第2の端末装置から、商品またはサービスを示すとともに当該商品またはサービスに関する評価を示す評価データを受信し、前記演算手段は、前記受信手段により受信された評価データにより示される一の商品またはサービスに関する評価に基づき、前記記憶手段により記憶されている当該一の商品またはサービスに関する許可条件データにより示される条件が満たされたか否かを判定し、前記送信手段は、前記演算手段による判定において一の商品またはサービスに関し前記条件が満たされたと判定された場合に限り、前記受信手段により受信された前記販売条件データのうち当該一の商品またはサービスを示す販売条件データにより示される条件に従い当該一の商品またはサービスの販売の申し出を示す販売申出データを前記1以上の第2の端末装置のうちの少なくとも1の第2の端末装置に送信するサーバ装置。前記受信手段は、前記送信手段により送信された販売申出データの送信先の第2の端末装置から、一の商品またはサービスの購入の申し込みを示す購入申込データを受信し、前記受信手段により受信された一の商品またはサービスに関する販売条件データは、前記受信手段により受信された購入申込データにより購入が申し込まれた当該一の商品またはサービスの総量が所定の閾値以上である場合に限り、もしくは当該総量が所定の閾値を超過する場合に限り、当該一の商品またはサービスの販売を実施するという条件を示す請求項8に記載のサーバ装置。前記演算手段は、前記判定において、前記受信手段により複数の異なる第1の端末装置から受信された複数の販売条件データを所定の規則に従いグループ化して得られる一のグループに属する複数の販売条件データの各々に関し、当該販売条件データにより示される一の商品またはサービスに関し前記受信手段により受信された評価データにより示される評価に基づく指標を生成し、当該一のグループに属する複数の販売条件データの各々に関し生成した当該指標の比較結果に基づき当該複数の販売条件データのうちの少なくとも1の販売条件データを選択し、当該選択した少なくとも1の販売条件データにより示される商品またはサービスに関し前記許可条件が満たされたと判定する請求項8または9に記載のサーバ装置。前記記憶手段は、前記受信手段により受信された評価データの送信元の第2の端末装置を識別する端末識別データを記憶し、前記送信手段は、前記記憶手段により記憶されている端末識別データにより識別される第2の端末装置に対し、前記記憶手段により記憶されている端末識別データにより識別されない第2の端末装置と比較して安価な販売価格で一の商品またはサービスの販売を申し出ることを示す前記販売申出データを送信する請求項8乃至10のいずれかに記載のサーバ装置。前記記憶手段は、前記1以上の第2の端末装置の各々に関し、当該第2の端末装置の使用者の属性を示す属性データを記憶し、前記演算手段は、前記受信手段により受信された評価データの送信元の第2の端末装置の使用者に関し前記記憶手段により記憶されている属性データにより示される属性に基づき、前記判定を行う請求項8乃至11のいずれかに記載のサーバ装置。前記演算手段は、前記受信手段により受信された一の商品またはサービス以外の他の商品またはサービスに関する評価データにより示される評価に基づき、当該一の商品またはサービスの販売を許可する条件を示す許可条件データを生成し、前記記憶手段は、前記演算手段により生成された許可条件データを記憶する請求項8乃至12のいずれかに記載のサーバ装置。前記演算手段は、前記受信手段により受信された一の商品またはサービスに関する販売条件データにより示される条件に基づき、当該一の商品またはサービスの販売を許可する条件を示す許可条件データを生成し、前記記憶手段は、前記演算手段により生成された許可条件データを記憶する請求項8乃至12のいずれかに記載のサーバ装置。他の通信装置との間でデータ通信を行う通信手段を備えるコンピュータを請求項8乃至14のいずれかに記載のサーバ装置が備える前記受信手段、前記記憶手段、前記演算手段、前記送信手段として機能させるプログラム。上述したように、既に商品またはサービスを購入した人によるレビューや口コミといった評価は、新たにその商品またはサービスの購入を検討している人にとって有意義な情報となる。ただし、そのような評価に関する情報が多量にある場合には、購入を検討している者は、それらの情報の全てを把握するために多大な時間と労力を用いなければならず、一方でそのような評価に関する情報が不足している場合には情報不足により必ずしも十分な検討が行えない。そこで、電子商取引のサイトの運営者が、電子商取引のサイトにおいて売買される商品またはサービスの質を担保するために、販売される予定の商品やサービスを個別に評価し、その評価に応じて販売者による商品またはサービスの販売を許可するか否かを判定する、という対策が取られている場合もある。しかしながら、その場合、サイトの運営者による判定が恣意的となりやすく、またサイトの運営者の労力が増す。上記の事情に鑑み、本発明は、電子商取引において、商品またはサービスの購入を検討している消費者と電子商取引のサイト運営者の両方に特段の労力を強いることなく、消費者にとって満足度の高い商取引を可能とする手段を提供することを目的とする。上記の課題を解決するため、本発明は、サーバ装置が、1以上の第1の端末装置のうちの任意の第1の端末装置から、商品またはサービスを示すとともに当該商品またはサービスを販売する条件を示す販売条件データを受信する販売条件データ受信ステップと、前記サーバ装置が、商品またはサービスの販売を許可するための条件を示す許可条件データを記憶する許可条件データ記憶ステップと、前記サーバ装置が、1以上の第2の端末装置のうちの任意の第2の端末装置から、商品またはサービスを示すとともに当該商品またはサービスに関する評価を示す評価データを受信する評価データ受信ステップと、前記サーバ装置が、前記評価データ受信ステップにおいて受信した評価データにより示される一の商品またはサービスに関する評価に基づき、前記許可条件データ記憶ステップにおいて記憶した当該一の商品またはサービスに関する許可条件データにより示される条件が満たされたか否かを判定する判定ステップと、前記サーバ装置が、前記判定ステップにおいて一の商品またはサービスに関し前記条件が満たされたと判定した場合に限り、前記販売条件データ受信ステップにおいて受信した販売条件データのうち当該一の商品またはサービスを示す販売条件データにより示される条件に従い当該一の商品またはサービスの販売の申し出を示す販売申出データを前記1以上の第2の端末装置のうちの少なくとも1の第2の端末装置に送信する販売申出データ送信ステップとを備える方法を提供する。第1の実施態様上記の第1の実施態様において、前記サーバ装置が、前記販売申出データ送信ステップにおいて送信した販売申出データの送信先の第2の端末装置から、一の商品またはサービスの購入の申し込みを示す購入申込データを受信する購入申込データ受信ステップを備え、前記販売条件データ受信ステップにおいて前記サーバ装置が受信する一の商品またはサービスに関する販売条件データは、前記購入申込データ受信ステップにおいて受信した購入申込データにより購入が申し込まれた当該一の商品またはサービスの総量が所定の閾値以上である場合に限り、もしくは当該総量が所定の閾値を超過する場合に限り、当該一の商品またはサービスの販売を実施するという条件を示す構成が採用されてもよい。第2の実施態様また、上記の第1または第2の実施態様において、前記サーバ装置は、前記判定ステップにおいて、前記販売条件データ受信ステップにおいて複数の異なる第1の端末装置から受信した複数の販売条件データを所定の規則に従いグループ化して得られる一のグループに属する複数の販売条件データの各々に関し、当該販売条件データにより示される一の商品またはサービスに関し前記評価データ受信ステップにおいて受信した評価データにより示される評価に基づく指標を生成し、当該一のグループに属する複数の販売条件データの各々に関し生成した当該指標の比較結果に基づき当該複数の販売条件データのうちの少なくとも1の販売条件データを選択し、当該選択した少なくとも1の販売条件データにより示される商品またはサービスに関し前記許可条件が満たされたと判定する構成が採用されてもよい。第3の実施態様また、上記の第1乃至第3のいずれかの実施態様において、前記サーバ装置が、前記評価データ受信ステップにおいて受信した評価データの送信元の第2の端末装置を識別する端末識別データを記憶する端末識別データ記憶ステップを備え、前記サーバ装置は、前記販売申出データ送信ステップにおいて、前記端末識別データ記憶ステップにおいて記憶した端末識別データにより識別される第2の端末装置に対し、前記端末識別データ記憶ステップにおいて記憶した端末識別データにより識別されない第2の端末装置と比較して安価な販売価格で一の商品またはサービスの販売を申し出ることを示す前記販売申出データを送信する構成が採用されてもよい。第4の実施態様また、上記の第1乃至第4のいずれかの実施態様において、前記サーバ装置が、前記1以上の第2の端末装置の各々に関し、当該第2の端末装置の使用者の属性を示す属性データを記憶する属性データ記憶ステップを備え、前記サーバ装置は、前記判定ステップにおいて、前記評価データ受信ステップにおいて受信した評価データの送信元の第2の端末装置の使用者に関し前記属性データ記憶ステップにおいて記憶した属性データにより示される属性に基づき、前記判定を行う構成が採用されてもよい。第5の実施態様また、上記の第1乃至第5のいずれかの実施態様において、前記サーバ装置が、前記評価データ受信ステップにおいて受信した一の商品またはサービス以外の他の商品またはサービスに関する評価データにより示される評価に基づき、当該一の商品またはサービスの販売を許可する条件を示す許可条件データを生成する許可条件データ生成ステップを備え、前記サーバ装置は、前記許可条件データ記憶ステップにおいて、前記許可条件データ生成ステップにおいて生成した許可条件データを記憶する構成が採用されてもよい。第6の実施態様また、上記の第1乃至第5のいずれかの実施態様において、前記サーバ装置が、前記販売条件データ受信ステップにおいて受信した一の商品またはサービスに関する販売条件データにより示される条件に基づき、当該一の商品またはサービスの販売を許可する条件を示す許可条件データを生成する許可条件データ生成ステップを備え、前記サーバ装置は、前記許可条件データ記憶ステップにおいて、前記許可条件データ生成ステップにおいて生成した許可条件データを記憶する構成が採用されてもよい。第7の実施態様また、本発明は、他の通信装置から送信されてくるデータを受信する受信手段と、データを記憶する記憶手段と、演算処理を行う演算手段と、データを他の通信装置に送信する送信手段とを備え、前記受信手段は、1以上の第1の端末装置のうちの任意の第1の端末装置から、商品またはサービスを示すとともに当該商品またはサービスを販売する条件を示す販売条件データを受信し、前記記憶手段は、商品またはサービスの販売を許可するための条件を示す許可条件データを記憶し、前記受信手段は、1以上の第2の端末装置のうちの任意の第2の端末装置から、商品またはサービスを示すとともに当該商品またはサービスに関する評価を示す評価データを受信し、前記演算手段は、前記受信手段により受信された評価データにより示される一の商品またはサービスに関する評価に基づき、前記記憶手段により記憶されている当該一の商品またはサービスに関する許可条件データにより示される条件が満たされたか否かを判定し、前記送信手段は、前記演算手段による判定において一の商品またはサービスに関し前記条件が満たされたと判定された場合に限り、前記受信手段により受信された前記販売条件データのうち当該一の商品またはサービスを示す販売条件データにより示される条件に従い当該一の商品またはサービスの販売の申し出を示す販売申出データを前記1以上の第2の端末装置のうちの少なくとも1の第2の端末装置に送信するサーバ装置を提供する。第8の実施態様上記の第8の実施態様において、前記受信手段は、前記送信手段により送信された販売申出データの送信先の第2の端末装置から、一の商品またはサービスの購入の申し込みを示す購入申込データを受信し、前記受信手段により受信された一の商品またはサービスに関する販売条件データは、前記受信手段により受信された購入申込データにより購入が申し込まれた当該一の商品またはサービスの総量が所定の閾値以上である場合に限り、もしくは当該総量が所定の閾値を超過する場合に限り、当該一の商品またはサービスの販売を実施するという条件を示す構成が採用されてもよい。第9の実施態様また、上記の第8または第9の実施態様において、前記演算手段は、前記判定において、前記受信手段により複数の異なる第1の端末装置から受信された複数の販売条件データを所定の規則に従いグループ化して得られる一のグループに属する複数の販売条件データの各々に関し、当該販売条件データにより示される一の商品またはサービスに関し前記受信手段により受信された評価データにより示される評価に基づく指標を生成し、当該一のグループに属する複数の販売条件データの各々に関し生成した当該指標の比較結果に基づき当該複数の販売条件データのうちの少なくとも1の販売条件データを選択し、当該選択した少なくとも1の販売条件データにより示される商品またはサービスに関し前記許可条件が満たされたと判定する構成が採用されてもよい。第10の実施態様また、上記の第8乃至第10のいずれかの実施態様において、前記記憶手段は、前記受信手段により受信された評価データの送信元の第2の端末装置を識別する端末識別データを記憶し、前記送信手段は、前記記憶手段により記憶されている端末識別データにより識別される第2の端末装置に対し、前記記憶手段により記憶されている端末識別データにより識別されない第2の端末装置と比較して安価な販売価格で一の商品またはサービスの販売を申し出ることを示す前記販売申出データを送信する構成が採用されてもよい。第11の実施態様また、上記の第8乃至第11のいずれかの実施態様において、前記記憶手段は、前記1以上の第2の端末装置の各々に関し、当該第2の端末装置の使用者の属性を示す属性データを記憶し、前記演算手段は、前記受信手段により受信された評価データの送信元の第2の端末装置の使用者に関し前記記憶手段により記憶されている属性データにより示される属性に基づき、前記判定を行う構成が採用されてもよい。第12の実施態様また、上記の第8乃至第12のいずれかの実施態様において、前記演算手段は、前記受信手段により受信された一の商品またはサービス以外の他の商品またはサービスに関する評価データにより示される評価に基づき、当該一の商品またはサービスの販売を許可する条件を示す許可条件データを生成し、前記記憶手段は、前記演算手段により生成された許可条件データを記憶する構成が採用されてもよい。第13の実施態様また、上記の第8乃至第12のいずれかの実施態様において、前記演算手段は、前記受信手段により受信された一の商品またはサービスに関する販売条件データにより示される条件に基づき、当該一の商品またはサービスの販売を許可する条件を示す許可条件データを生成し、前記記憶手段は、前記演算手段により生成された許可条件データを記憶する構成が採用されてもよい。第14の実施態様また、本発明は、他の通信装置との間でデータ通信を行う通信手段を備えるコンピュータを請求項8乃至14のいずれかに記載のサーバ装置が備える前記受信手段、前記記憶手段、前記演算手段、前記送信手段として機能させるプログラムを提供する。第15の実施態様上記の第1の実施態様にかかる方法または上記の第8の実施態様にかかるサーバ装置によれば、電子商取引において、一定以上の良好な評価を得た商品またはサービスに関してのみ当該商品またはサービスの販売が許可されるため、消費者に対し満足度の低い商品サービスの購入が促されるという不都合が生じる可能性が低減される。その際、基準となる評価は一般の消費者により提供されるため、電子商取引のサイト運営者等が評価を行う場合と比較し、その評価が中立的であるとともに、サイト運営者の管理負担の増大を伴わない。上記の第2の実施態様にかかる方法または上記の第9の実施態様にかかるサーバ装置によれば、共同購入として広く知られる仕組み、すなわち一定数量以上の購入が行われる場合に限り通常価格より低価格にて商品またはサービスの販売が実施される仕組みにおいて、商品またはサービスが一定以上の良好な評価を得た場合にのみ、その商品またはサービスの販売が許可される。そのため、特に価格が重視されがちな共同購入において、ともすれば低価格を実現するために質の低い商品やサービスの販売が行われるという危険性が低減され、効果的である。上記の第3の実施態様にかかる方法または上記の第10の実施態様にかかるサーバ装置によれば、異なる複数の提供者により販売が予定される同種の商品サービスに関し、それらの商品サービスに対する評価が高いものに関し優先的にその販売の許可が行われる。従って、同種の商品サービスの販売が同時期に重なることにより過度の低価格化が生じるという不都合が回避される。また、評価に基づく販売の許可不許可の判定において、例えば評価値の閾値を適切に設定することが困難な場合があるが、この実施態様においては評価値の順位相対値が判定の基準となるため、そのような困難も伴わない。上記の第4の実施態様にかかる方法または上記の第11の実施態様にかかるサーバ装置によれば、商品やサービスの評価を行った購入者は、評価を行わなかった購入者と比べ、低価格で当該商品やサービスの購入を行うことができる。そのため、同じ商品やサービスを繰り返し購入したいと思う購入者による評価が促され、販売許可の判定に要する評価を効率的に収集することができる。上記の第5の実施態様にかかる方法または上記の第12の実施態様にかかるサーバ装置によれば、商品やサービスの評価を行った購入者の属性、例えばその購入者が過去に同じ商品やサービスを購入しているか否かといった情報が、販売許可の判定において考慮される。そのため、より信頼性の高い判定が可能となる。上記の第6の実施態様にかかる方法または上記の第13の実施態様にかかるサーバ装置によれば、ある商品サービスの販売許可の判定において獲得すべき評価の基準が他の商品サービスにおいて獲得されている評価に基づき自動的に設定される。そのため、例えばサイト運営者がそれらの基準を個々の商品サービスに関し設定する手間を要さない。上記の第7の実施態様にかかる方法または上記の第14の実施態様にかかるサーバ装置によれば、ある商品サービスの販売許可の判定において獲得すべき評価の基準がその商品サービスの販売成立数や単価などの販売条件に基づき自動的に設定される。そのため、例えばサイト運営者がそれらの基準を個々の商品サービスに関し設定する手間を要さない。また、上記の第15の実施態様にかかるプログラムによれば、外部の通信装置との間でデータの送受信を行う通信手段を備えた一般的なコンピュータを用いて上記の第8乃至第14のいずれかの実施態様にかかるサーバ装置が実現され、それらの実施態様に関し上述した各種効果が得られる。[1.実施例]以下に本発明の実施例にかかる商品販売システムの構成および動作を説明する。[1.1.第1実施例]第1実施例にかかる商品販売システム1は、ネットワークを介して、商品の提供者であるサプライヤーが商品の販売の申し出を行い、商品の消費者であるバイヤーがその申し出に応じて商品の購入の申し込みを行うことで、商品の売買を仲介するシステムである。商品販売システム1は、上記の通常の商品売買の仕組みに加え、いわゆる共同購入による商品売買の仕組みを備えている。すなわち、商品販売システム1は、サプライヤーと個々のバイヤーとの間の個別の商品売買を仲介するだけでなく、サプライヤーと所定数以上のバイヤーの集まりとの間の商品売買も仲介する。その際、サプライヤーは価格に加え、販売成立数や販売期間といった販売の条件を付して商品の販売を申し出て、その条件により指定された販売期間内に指定された販売成立数を満たす多数のバイヤーからの商品購入の申し込みがあった場合に限り、商品の売買が実施される。ところで、一般的な共同購入の仕組みにおいては、サプライヤー間が過度な価格競争に陥りやすいという問題がある。バイヤーにとって通常の購入と比べ共同購入を行う主なメリットは低価格であり、共同購入に参加するバイヤーは一般的に価格に敏感である。従って、サプライヤーが共同購入において多くの購入者を獲得するためには、可能な限りその価格を抑える必要がある。そのような価格競争が行き過ぎると、通常販売における商品よりも質の劣る商品が共同購入において販売される、コスト削減のために商品管理等が十分に行われず商品の発送遅れや発送違いなどのエラーが頻発する、といった様々な不都合が生じ得る。上記のような問題を低減するために、商品販売システムの運営者以下、サイト運営者というが過去の販売実績等の情報に基づき、サプライヤーによる商品販売の可否を個別に判定する、という努力が行われている。その場合、サイト運営者はその判定に多大な時間と労力を費やさねばならないとともに、その判定が恣意的になりやすい。一方、商品販売システム1においては、サプライヤーによる商品販売の申し出を許可するか否かの判定が、バイヤーによる評価に基づき自動的に行われる。そのため、サイト運営者はその判定に時間と労力を費やす必要がなく、バイヤーは他の多くのバイヤーによる客観的な基準により選定された商品を安心して購入することができ、サプライヤーはバイヤーによる評価が下がれば共同購入における商品販売それ自体ができなくなるため、過度な価格競争に陥ることがない。以下においては、商品販売システム1における商品販売の仕組みのうち、一般的な商品販売システムと異なる部分、すなわちバイヤーによる評価に基づきサプライヤーによる商品販売の申し出の許可不許可が自動的に判定される仕組みを中心に説明する。図1は、商品販売システム1の全体構成を模式的に示したブロック図である。商品販売システム1は、サプライヤーおよびバイヤーとの間の商品の売買を仲介するサーバ装置11、サプライヤーにより操作され商品販売の申し出に用いられるサプライヤー端末装置12第1の端末装置、バイヤーにより操作され商品購入の申し込みに用いられるバイヤー端末装置13第2の端末装置を備えている。サプライヤー端末装置12およびバイヤー端末装置13は各々、ネットワーク19を介してサーバ装置11との間で各種データの送受信を行うことができる。図1において、図示されているサーバ装置11の数は1つであるが、サーバ装置11は単独の装置として構成されてもよいし、互いに連携し協働する複数の装置の集合体として構成されてもよい。そのような装置の集合体の構成としては、複数の装置の各々がロードバランサーにより配分された同種の処理を行うもの、ネットワーク19における地域により複数の装置の各々が処理を分担するもの、以下に説明するサーバ装置11の各種データ処理をその処理の種類に応じて複数の装置が分担するもの、など様々なものが採用可能である。また、サプライヤー端末装置12およびバイヤー端末装置13は各々、商品販売システム1を利用するサプライヤーおよびバイヤーの数に応じて常時変化する。図1においては、p個のサプライヤー端末装置12およびq個のバイヤー端末装置13が示されている。ただし、pおよびqは各々、任意の自然数である。以下、サプライヤー端末装置12およびバイヤー端末装置13の各端末装置群の中の個々の端末装置を区別する必要がある場合、例えばサプライヤー端末装置12-1のように枝符号を付してそれらを区別する。サーバ装置11は、外部の通信装置との間でデータの送受信が可能な汎用コンピュータに、本発明にかかるプログラムに従った処理を行わせることにより実現される。ただし、それに代えて、いわゆる専用サーバ機として以下の処理を行う装置がハードウェア的に構成されてもよい。図2は、サーバ装置11の機能構成を示したブロック図である。サーバ装置11はその機能構成部として、外部の通信装置サプライヤー端末装置12およびバイヤー端末装置13から送信されてくる各種データを受信する受信部111、外部の通信装置に対し各種データを送信する送信部112、本発明にかかるプログラムを示すデータや商品情報を示すデータなどの各種データを記憶する記憶部113、商品販売の申し出の許可不許可を判定するとともにサーバ装置11において他の構成部を制御するための各種演算を行う演算部114を備えている。記憶部113には、以下のDBDatabaseが格納されている。バイヤーDB:バイヤーに関する情報を管理するDB。サプライヤーDB:サプライヤーに関する情報を管理するDB。売買履歴DB:過去に行われた商品の売買に関する情報を管理するDB。評価DB:サプライヤーにより販売された商品に関するバイヤーによる評価を示す情報を管理するDB。共同購入DB:共同購入における商品販売の申し出に関する情報を管理するDB。図3は、バイヤーDBのデータ構成を模式的に示した図である。バイヤーDBはバイヤーの各々に関するデータを格納するレコードの集まりである。バイヤーDBの各レコードは以下の各種データを格納するフィールドを有している。バイヤーID:バイヤーを識別するユーザIDIdentifierを格納する。パスワード:バイヤーの本人確認を行うためのパスワードを格納する。端末ID:バイヤーが使用する端末装置がユニークな端末IDの割り当てられた携帯端末装置である場合、その端末IDを格納する。氏名:バイヤーの氏名を示すテキストデータを格納する。住所:バイヤーの住所を示すテキストデータを格納する。電話番号:バイヤーの住所を示すテキストデータを格納する。メールアドレス:バイヤーの住所を示すテキストデータを格納する。クレジットカード番号:バイヤーのクレジットカードの番号を示すテキストデータを格納する。バイヤーカテゴリー:バイヤーが一般バイヤーであることを示す一般、もしくはバイヤーが商品の仕入等を行うプロのバイヤーであることを示すプロのいずれかを示すテキストデータを格納する。図4は、サプライヤーDBのデータ構成を模式的に示した図である。サプライヤーDBはサプライヤーの各々に関するデータを格納するレコードの集まりである。サプライヤーDBの各レコードは以下の各種データを格納するフィールドを有している。サプライヤーID:サプライヤーを識別するサプライヤーIDを格納する。パスワード:サプライヤーの本人確認を行うためのパスワードを格納する。端末ID:サプライヤーが使用する端末装置がユニークな端末IDの割り当てられた携帯端末装置である場合、その端末IDを格納する。店舗名:サプライヤーが管理する電子商取引上の店舗の名称を示すテキストデータを格納する。店舗プロファイル:サプライヤーが管理する電子商取引上の店舗の紹介情報を示すテキストデータを格納する。口座情報:サイト運営者がクレジットカード会社から受け取った商品の販売代金をサプライヤーに支払う際の振込先口座に関する情報を示すテキストデータを格納する。図5は、売買履歴DBのデータ構成を模式的に示した図である。売買履歴DBは過去に行われた商品売買の各々に関するデータを格納するレコードの集まりである。なお、売買履歴DBには、共同購入による商品売買に関するデータに限られず、一般的な個別の商品売買通常購入に関するデータも格納されている。売買履歴DBの各レコードは以下の各種データを格納するフィールドを有している。売買ID:個々の売買を識別する売買IDを格納する。売買日時:売買が行われた日時を示す時刻データを格納する。サプライヤーID:商品の販売を行ったサプライヤーを識別するサプライヤーIDを格納する。バイヤーID:商品の購入を行ったバイヤーを識別するバイヤーIDを格納する。商品ID:売買された商品を識別する商品IDを格納する。同じサプライヤーから販売される同一の商品は、通常購入共同購入の別なく同じ商品IDで識別される。商品名:売買された商品の名称を示すテキストデータを格納する。商品カテゴリー:売買された商品が属する分類の名称例えば、食品-菓子-和菓子、スポーツ用品-自転車-本体などを示すテキストデータを格納する。売買数量:売買された商品の数量を示す数値データを格納する。売買単価:売買された商品の単価を示す数値データを格納する。割引率:売買単価に対する割引率を示す数値データを格納する。図6は、評価DBのデータ構成を模式的に示した図である。評価DBは特定のサプライヤーにより販売された特定の商品に関し、任意のバイヤーが行った評価に関するデータを格納するレコードの集まりである。なお、バイヤーは商品販売システム1を介して評価対象の商品を評価対象のサプライヤー店舗から過去に通常購入もしくは共同購入にて購入したか否かにかかわらず、店舗および商品の評価を行うことができる。他の商品販売システムを介して同じサプライヤーから同じ商品を購入したバイヤーなどの評価も受け付けるためである。評価DBの各レコードは以下の各種データを格納するフィールドを有している。評価ID:個々の評価を識別する評価IDを格納する。評価日時:評価が行われた日時を示す時刻データを格納する。バイヤーID:評価を行ったバイヤーを識別するバイヤーIDを格納する。サプライヤーID:評価対象のサプライヤーを識別するサプライヤーIDを格納する。商品ID:評価対象の商品を識別する商品IDを格納する。同じサプライヤーから販売される同一の商品は、通常購入共同購入の別なく同じ商品IDで識別される。商品カテゴリー:評価対象の商品が属する分類の名称を示すテキストデータを格納する。共同購入ID:共同購入における商品販売の予告から販売実施までの間にその店舗もしくは商品の評価を行った場合、その共同購入を識別する共同購入IDを格納する。なお、その間に行われた評価でない場合、このフィールドは空欄となる。店舗評価点:店舗に対する評価を1~5のいずれかの自然数で示す数値データを格納する。なお、数値が高い程、高い評価を示す。店舗口コミ:店舗に対する評価を言葉で示すテキストデータを格納する。商品評価点:商品に対する評価を1~5のいずれかの自然数で示す数値データを格納する。なお、数値が高い程、高い評価を示す。商品口コミ:商品に対する評価を言葉で示すテキストデータを格納する。図7は、共同購入DBのデータ構成を模式的に示した図である。共同購入DBは特定のサプライヤーにより提起された共同購入における商品販売の申し出の各々に関するデータを格納するレコードの集まりである。共同購入DBの各レコードは以下の各種データを格納するフィールドを有している。共同購入ID:共同購入における商品販売の申し出を識別する共同購入IDを格納する。サプライヤーID:商品の販売を行うサプライヤーを識別するサプライヤーIDを格納する。商品ID:販売される商品を識別する商品IDを格納する。同じサプライヤーから販売される同一の商品は、通常購入共同購入の別なく同じ商品IDで識別される。商品名:販売される商品の名称を示すテキストデータを格納する。商品画像:販売される商品の写真等を示す画像データのファイル名サーバ装置11における格納場所を示すテキストデータを格納する。商品カテゴリー:販売される商品が属する分類の名称を示すテキストデータを格納する。販売成立数:販売の実施に要する商品の購入申し込み総数の最低数を示す数値データを格納する。最大販売数:販売が可能な商品の最大数を示す数値データを格納する。単価:商品の単価を示す数値データを格納する。判定期間:販売の申し出を許可するか否かの判定を行う期間開始日時と終了日時を示す日時データを格納する。許可条件:販売の申し出を許可するために満たされるべき条件を示すデータを格納する。具体的には、例えば、店舗評価点と商品評価点を所定の重み付けを伴い加算して得られる総合評価点が200点以上であることを条件として示す総合評価点≧200などのテキストデータが格納される。販売許可:販売の申し出が未許可であることを示す未許可、もしくは販売の申し出が許可されていることを示す許可のいずれかを示すテキストデータを格納する。購入申込期間:バイヤーによる購入の申し込みを受け付ける期間開始日時と終了日時を示す日時データを格納する。購入申込:購入の申し込みを行ったバイヤーを識別するバイヤーIDと購入数量を示す数値データ購入数量データとの組み合わせを格納する。購入申込が複数あれば、それらに応じた複数組のバイヤーIDおよび購入数量データが格納される。販売実施:購入の申し込みが行われた商品の数が販売成立数にまだ達していないことを示す未定、購入の申し込みが行われた商品の数が販売成立数に達し販売が実施されることを示す実施、購入の申し込みが行われた商品の数が最大販売数に達し購入申込の受け付けが終了したことを示す受付終了、バイヤーからの代金を受領したことを示す完了、購入の申し込みが行われた商品の数が購入申込期間中に販売成立数に達さず販売が実施されないことを示す不実施のいずれかを示すテキストデータを格納する。以上が、記憶部113に格納される各種DBのデータ構成の説明である。なお、サプライヤー端末装置12およびバイヤー端末装置13は各々、Webブラウザ機能を備えネットワーク19を介してサーバ装置11との間で各種データの送受信が可能な汎用的な端末装置であり、その形態はノートPC、デスクトップPC、携帯電話機等のいずれでもよい。続いて、商品販売システム1の動作を説明する。商品販売システム1を利用するバイヤーおよびサプライヤーは各々、その利用に先立ってサーバ装置11に対するユーザ登録を行う必要がある。ユーザ登録の手順は広く知られているため詳しい説明は省略するが、例えばバイヤーであれば自分のバイヤー端末装置13例えば、バイヤー端末装置13-1のWebブラウザにおいて所定のURLUniformResourceLocatorを入力しユーザ登録用ページを表示させ、そのユーザ登録用ページにおいて要求されるパスワード、氏名等の入力を行いう。それらの入力されたデータがバイヤー端末装置13からサーバ装置11に送信され、バイヤーDB図3に登録される。その際、バイヤー端末装置13が端末IDの割り当てられた携帯端末装置であれば、その端末IDもバイヤー端末装置13からサーバ装置11へと送信され、バイヤーDBに登録される。端末IDがバイヤーDBに登録されている場合、ユーザは商品販売システム1の利用に際して通常であれば要求されるバイヤーIDとパスワードの入力による本人確認の操作を要求されない。携帯端末装置は個々のユーザにより携帯されるため、通常、その所有者の許可無く所有者以外の誰かに操作されることはないためである。サプライヤーは共同購入により商品を販売したい場合、サプライヤー端末装置12のWebブラウザにおいて所定のURLを入力し、共同購入販売申出ページを表示させる。ただし、共同購入販売申出ページの表示に先立ち、サプライヤー端末装置12が端末IDの割り当てられた携帯端末装置であれば端末IDがサプライヤー端末装置12からサーバ装置11に送信され、サーバ装置11においてサプライヤーDBに登録されている端末IDと照合されることにより、サプライヤーの識別および本人確認が行われる。一方、サプライヤー端末装置12が端末IDの割り当てられた携帯端末装置でない場合、ログインページが表示され、サプライヤーは自分のサプライヤーIDおよびパスワードを入力する。入力されたサプライヤーIDとパスワードの組み合わせはサプライヤー端末装置12からサーバ装置11に送信され、サーバ装置11においてサプライヤーDBに登録されているサプライヤーIDとパスワードの組み合わせと照合されることにより、サプライヤーの識別および本人確認が行われる。サプライヤーおよびバイヤーが商品販売システム1を利用する際には、上述した本人確認の処理が要求される。ただし、いったん本人確認ログインの処理が完了したユーザサプライヤーもしくはバイヤーに関しては、そのユーザの利用する端末装置とサーバ装置11との間で通信コネクションが維持されている限り、再度の本人確認は不要である。その間、サーバ装置11は接続相手の端末装置すなわち、その端末装置のユーザのサプライヤーIDもしくはバイヤーIDを通信コネクションのIDにより識別することができる。一方、ログアウトや端末装置のリセット等により通信コネクションが切断されると、再度の通信コネクションの確立に伴い再度の本人確認の処理が必要となる。共同購入販売申出ページにおいて、サプライヤーは共同購入における販売の申し出に関する以下のデータを入力する。商品名:販売される商品の名称を示すテキストデータ。商品ID:販売される商品を識別するID。サプライヤーが自分で決定する。商品画像:販売される商品の写真等を示す画像データのファイル名サプライヤー端末装置12における格納場所を示すテキストデータ。商品カテゴリー:販売される商品が属する分類の名称を示すテキストデータ。販売成立数:販売の実施に要する商品の購入申し込み総数の最低数を示す数値データ。最大販売数:販売が可能な商品の最大数を示す数値データ。単価:商品の単価を示す数値データ。判定期間:販売の申し出を許可するか否かの判定を行う期間開始日時と終了日時を示す日時データ。購入申込期間:バイヤーによる購入の申し込みを受け付ける期間開始日時と終了日時を示す日時データ。なお、商品IDはサプライヤーが自由に決定する。ただし、同じ商品を繰り返し販売する場合、サプライヤーはそれらの商品に同じ商品IDを用いる。また、商品カテゴリーは予めサイト運営者により決定されたものを全てのサプライヤーが共通して用いる。そのため、例えばサプライヤーは、共同購入販売申出ページにおいてメニューリストに表示される商品カテゴリーの中から該当するものを1つ選択することにより、その入力を行う。また、判定期間および購入申込期間は、具体的な開始日時および終了日時を指定してもよいが、例えば判定期間に関しては申出日から1ヶ月間、また購入申込期間は販売許可日から2週間のように、未確定の開始日時とその日時からの期間長により指定してもよい。サプライヤーにより入力された共同購入における販売の申し出に関するデータは、サプライヤー端末装置12からサーバ装置11に送信される。ただし、商品画像に関しては、入力されたファイル名ではなく、入力されたファイル名により指定される画像データのファイル本体がサプライヤー端末装置12からサーバ装置11に送信される。サーバ装置11はサプライヤー端末装置12からそれらのデータを受信すると、共同購入DB図7に新規レコードを作成した後、その新規レコードの対応するフィールドにそれらのデータを格納する。ただし、商品画像に関しては、受信した画像データのファイル本体はサーバ装置11の所定の場所に格納され、その格納場所を示すファイル名が新規レコードの対応するフィールドに格納される。また、例えば判定期間として申出日から1ヶ月間が指定されている場合、その時点の日時を開始日時、その時点から1ヶ月後の時点を終了日時として示す期間データが新規レコードの対応するフィールドに格納される。また、サーバ装置11は、その新規レコードの他のフィールドに関し、以下のデータを格納する。共同購入ID:新たに自動生成したユニークなID。サプライヤーID:販売の申し出を行ったサプライヤーを識別するサプライヤーID。許可条件:新たに自動生成した許可条件を示すテキストデータ。販売許可:未許可を示すテキストデータ。購入申込:空欄販売実施:未定を示すテキストデータ。なお、上記のサプライヤーIDは、サプライヤー端末装置12のログイン時の本人確認においてサーバ装置11が取得したサプライヤーIDもしくは端末IDに基づきサプライヤーDB図4から特定したサプライヤーIDである。また、上記の許可条件は、例えば以下の手順でサーバ装置11の演算部114により自動生成される。まず、演算部114は評価DB図6から、フィールド評価日時により示される日時が過去の所定期間例えば、1年間に含まれ、フィールド商品カテゴリーが共同購入販売申出ページにおいてサプライヤーにより入力された商品カテゴリーと一致するレコード群を抽出する。このように抽出されたレコード群は、例えば食品-菓子-和菓子のように、サプライヤーが販売の申し出を行おうとしている商品と同じカテゴリーに属する商品に関し任意のバイヤーから寄せられた評価を各々格納するレコードの集まりである。続いて、演算部114は抽出したレコード群を、サプライヤーIDおよび商品IDの組み合わせ毎にグループ化する。このようにグループ化されたレコード群は各々、個々のサプライヤーにより販売される同じ商品に関し任意のバイヤーから寄せられた評価を各々格納するレコードの集まりである。続いて、演算部114はグループ化したレコード群の各々に関し、総合評価点を算出する。総合評価点は、例えば以下の算出式1により算出される。総合評価点=ΣVS×0.3×WSVG×0.7×WG×WB算出式1ただし、VS:店舗評価点WS:評価者バイヤーによる店舗の利用の有無に基づくウェイト。例えば、評価者が過去の一定期間内例えば1年間にこの店舗を利用したことがある場合、WS=1.5、利用したことがない場合、WS=1.0とする。VG:商品評価点WG:評価者バイヤーによる商品の購入の有無に基づくウェイト。例えば、評価者が過去の一定期間内例えば1年間にこの商品を購入したことがある場合、WG=1.5、利用したことがない場合、WG=1.0とする。WB:評価者バイヤーの属性に基づくウェイト。例えば、評価者がプロのバイヤーである場合、WB=1.5、一般のバイヤーである場合、WB=1.0とする。また、Σはグループに属する複数のレコードの各々に関し内に示される算出式に従い算出された数値の総和を意味する。なお、VSおよびVGに関しては、評価DB図6のレコードから直接取得される。また、WSに関しては、売買履歴DB図5のレコードの中に、評価DBのレコードのフィールドバイヤーIDおよびサプライヤーIDと同じデータを格納し、かつフィールド売買日時がその時点から過去1年以内を示すレコードが発見された場合、過去1年間にその評価者が同じサプライヤーの店舗を利用したことがあることになるためWS=1.5が設定され、それ以外の場合はWS=1.0が設定される。また、WGに関しては、売買履歴DB図5のレコードの中に、評価DBのレコードのフィールドバイヤーIDおよび商品IDと同じデータを格納し、かつフィールド売買日時がその時点から過去1年以内を示すレコードが発見された場合、過去1年間にその評価者が同じ商品を購入したことがあることになるためWG=1.5が設定され、それ以外の場合はWG=1.0が設定される。また、WBに関しては、バイヤーDB図3の中から、評価DBのレコードのフィールドバイヤーIDと同じデータをフィールドバイヤーIDに格納するレコードを検索し、その検索されたレコードのフィールドバイヤーカテゴリーに格納されているデータがプロであればWB=1.5が設定され、それ以外の場合はWB=1.0が設定される。上記の算出式に従い算出される総合評価点は、店舗に対する評価点を30、商品に対する評価点を70の比率で勘案し、過去に同じ店舗を利用したバイヤーによる評価の場合、もしくは過去に同じ店舗で同じ商品を購入したバイヤーによる評価の場合、その評価点を1.5倍に重み付けし、さらにプロのバイヤーによる評価の場合、その評価を1.5倍に重み付けして得られる評価の指標である。このように算出される総合評価点は、バイヤーが過去に同じ店舗を利用したか否か、同じ商品を購入したか否か、プロのバイヤーであるか否か、といったバイヤーの属性に基づく重み付けにより、信頼性の高められた評価の指標である。演算部114は、グループ化されたレコード群の各々について上記のように総合評価点を算出し、それらの平均値以下、平均総合評価点というを算出する。演算部114は平均総合評価点を販売許可の条件における閾値として採用する。すなわち、演算部114は、総合評価点≧平均総合評価点といったテキストデータを生成し、先に共同購入DBに生成した新規レコードのフィールド許可条件に格納する。この許可条件は、サプライヤーにより販売の申し出の行われた商品が獲得すべき総合評価点が、販売される商品の属する商品カテゴリーにおける平均総合評価点以上であることを販売許可の条件として示すものである。続いて、演算部114は、以上のように新規レコードに対し設定した許可条件が満たされているか否かの判定を行う。サプライヤーが商品販売の実績を多く持ち、多くのバイヤーから既に多くの店舗評価点を獲得している場合や、サプライヤーが同じ商品を過去に多数販売し、多くのバイヤーから既に多くの商品評価点を獲得している場合には、直ちに許可条件が満たされる。その場合、演算部114は共同購入DB図7の該当レコードのフィールド販売許可を許可に書き換える。その際、フィールド購入申込期間が例えば販売許可日から2週間のように指定されている場合、演算部114はフィールド購入申込期間に、その時点の日時を開始日時、その時点から2週間後の時点を終了日時として示す期間データでフィールド購入申込期間を書き換える。以上が、サプライヤーにより商品販売システム1に対し申し込まれた共同購入による商品販売の申し出が共同購入DBに登録される際の商品販売システム1における処理である。演算部114は、共同購入DB図7に含まれるレコードのうち、現在の時刻がフィールド購入申込期間に示される期間に達しておらず、現在の時刻がフィールド判定期間に示される期間内のレコードの各々に関し、図8に模式的に示すような共同購入予告ページの表示を指示するWebページデータを生成し、任意のバイヤー端末装置13からアクセス可能な状態で記憶部113の所定の場所に記憶する。共同購入予告ページは、購入申込期間が到来していないため、バイヤーがまだ購入を申し込むことができない商品に関する情報を表示するページである。共同購入募集予告ページの中には、既に許可条件が満たされて販売が許可されている商品に関するものと、まだ許可条件が満たされておらず販売が未許可な商品に関するものが含まれる。共同購入募集予告ページに表示される販売開始までにさらに必要な総合評価点が0であれば既に販売が許可されており、正の数であれば販売が未許可である。また、演算部114は、共同購入DB図7に含まれるレコードのうち、現在の時刻がフィールド購入申込期間に示される期間内であり、フィールド販売許可が許可であるレコードの各々に関し、図9に模式的に示すような共同購入ページの表示を指示するWebページデータを生成し、任意のバイヤー端末装置13からアクセス可能な状態で記憶部113の所定の場所に記憶する。共同購入ページは、購入申込期間が到来し、かつ許可条件が満たされて販売が許可され、バイヤーが購入を申し込むことができる商品に関する情報を表示するページである。共同購入によって商品の購入を希望するバイヤーは、バイヤー端末装置13のWebブラウザにおいて所定のURLを入力し、共同購入品検索ページを表示させ、例えば商品カテゴリー=和菓子などの検索キーワードを入力することで、共同購入の対象となる商品のリストを表示させることができる。バイヤーが商品のリストから販売が未開始の商品を選択すると、その商品に関する共同購入予告ページ図8がバイヤー端末装置13に表示される。バイヤーは、その商品のサプライヤーから過去に何らかの商品を買ったことがある場合、共同購入予告ページの店舗を評価するボタンをクリック等することで店舗評価の入力ページを表示させ、店舗を1~5のいずれかの自然数で評価する店舗評価点と、店舗を言葉で評価する店舗口コミを入力することができる。同様に、バイヤーはその商品をいずれかのサプライヤーから過去に買ったことがある場合、共同購入予告ページにおいて商品を評価するボタンをクリック等することで商品評価の入力ページを表示させ、商品を1~5のいずれかの自然数で評価する商品評価点と、商品を言葉で評価する商品口コミを入力する。このように入力された店舗評価点、店舗口コミ、商品評価点、商品口コミを示すデータ評価データは、バイヤー端末装置13からサーバ装置11に送信される。サーバ装置11はバイヤー端末装置13から上記の各種評価データを受信すると、評価DB図6に新規レコードを生成し、その新規レコードの対応するフィールドに受信した評価データを各々格納する。また、サーバ装置11は、その新規レコードの他のフィールドに関し、以下のデータを格納する。評価ID:新たに自動生成したユニークなID。評価日時:現在の時刻を示す時刻データ。バイヤーID:評価を行ったバイヤーを識別するバイヤーID。サプライヤーID:評価対象のサプライヤーを識別するサプライヤーID。商品ID:評価対象の商品を識別する商品ID。商品カテゴリー:評価対象の商品が属する分類の名称を示すテキストデータ。共同購入ID:評価を行った共同購入予告ページの共同購入を識別する共同購入ID。なお、上記のバイヤーIDは、バイヤー端末装置13のログイン時の本人確認においてサーバ装置11が取得したバイヤーIDもしくは端末IDに基づきバイヤーDB図3から特定したバイヤーIDである。また、上記のサプライヤーID、商品ID、商品カテゴリー、共同購入IDは、バイヤーが評価を行う際にクリック等した店舗を評価するボタンおよび商品を評価するボタンが配置された共同購入予告ページを生成する際に、サーバ装置11において共同購入DB図7から抽出され用いられたレコードに格納されているデータである。バイヤーが、上述した共同購入品検索ページに表示される商品のリストから既に販売が開始されている商品を選択すると、その商品に関する共同購入ページ図9がバイヤー端末装置13に表示される。共同購入ページにおいても、共同購入予告ページと同様に、バイヤーは店舗を評価するボタンもしくは商品を評価するボタンをクリック等して、店舗の評価もしくは商品の評価を行うことができる。バイヤーは、共同購入予告ページおよび共同購入ページ以外にも、例えば通常購入のページに配置された店舗を評価するボタンもしくは商品を評価するボタンをクリック等して、店舗の評価もしくは商品の評価を行うことができる。ただし、その場合、評価DBにおいて評価データを格納するレコードのフィールド共同購入IDは空欄となる。演算部114は、評価DBに新たにレコードが追加されると、共同購入DB図7のレコードのうち、現在の時刻がフィールド判定期間に示される期間内であり、フィールド販売許可が未許可であるものを抽出し、抽出されたレコードの許可条件が満たされたか否かの判定を行う。すなわち、対象のレコードのフィールドサプライヤーIDおよびフィールド商品IDにより特定される商品に関する総合評価点を算出し、また対象のレコードのフィールド商品カテゴリーにより特定される商品群に関する平均総合評価点を算出し、総合評価点が平均総合評価点以上であるか否かを判定する。許可条件が満たされたと判定された場合、演算部114は共同購入DBの対象のレコードのフィールド販売許可を許可に書き換える。このように、販売が許可された共同購入に関しては、その後、フィールド購入申込期間に示される期間の開始日時になると、購入申込の受け付けが始まる。共同購入ページには、共同購入予告ページと異なり、商品を注文するボタンが配置されている。このページの商品は既に販売が許可され、かつその販売が開始されているため、バイヤーはその商品の購入を申し込むことができるためである。バイヤーが商品を注文するボタンをクリック等した後に行われる商品販売システム1の動作およびバイヤーが行うべき作業は、一般的な共同購入におけるものと同様であるので、その説明を省略する。バイヤーにより共同購入による商品の購入の申し込みが行われると、演算部114は共同購入DB図7の当該共同購入に関するレコードのフィールド購入申込に、バイヤーのバイヤーIDと、申し込みの行われた商品の数量を示す購入数量データの組み合わせを追加する。演算部114は、フィールド購入申込にそれらのデータを追加すると、フィールド販売実施が未定の場合、フィールド購入申込に含まれる1以上の購入数量データの各々により示される購入数量を合計し、その合計値がフィールド販売成立数に達したか否かを判定する。購入数量の合計が販売成立数に達した場合、フィールド販売実施を実施に書き換える。これにより、共同購入が成立し、サプライヤーからバイヤーへ商品の販売が実施されることになる。また、演算部114は、フィールド購入申込にデータを追加した際、購入数量の合計がフィールド最大販売数に達したか否かも判定する。購入数量の合計が最大販売数に達した場合、演算部114はフィールド販売実施を受付終了に書き換える。さらに、演算部114は、十分に短い間隔で、共同購入DB図7のレコードのうち、フィールド販売実施が未定または実施のものに関し、フィールド購入申込期間に示される期間の終了日時を過ぎたか否かを判定する。購入申込期間が既に過ぎていると判定した場合、演算部114はフィールド販売実施が未定のものに関しては、フィールド販売実施を不実施に書き換える。また、フィールド販売実施が実施のものに関しては、演算部114はまず、フィールド購入申込に格納されている1以上のバイヤーIDの各々に関し、バイヤーDB図3の中からフィールドバイヤーIDが一致するものを検索し、検索したレコードのフィールドクレジットカード番号から、バイヤーのクレジットカード番号を取得する。続いて、演算部114は受信部111および送信部112を介して、図1に図示せぬクレジットカード会社の決済サーバ装置にアクセスし、取得したクレジットカード番号により商品代金の支払い要求を行う。その結果、クレジットカード会社から商品販売システム1のサイト運営者に商品代金の支払いが行われる。ところで、商品販売システム1においては、バイヤーによるサプライヤーおよび商品に関する評価の実施を促すために、共同購入予告ページもしくは共同購入ページから評価を行ったバイヤーがそれらのページで紹介されている商品を購入した場合、商品代金の割引を受けることができる。その際の割引率は、例えば、過去に同じサプライヤーから何らかの商品を購入したことのあるバイヤーに関しては5、過去に同じサプライヤーから同じ商品を購入したことのあるバイヤーに関しては10、それらのいずれでもない場合は3、のように、バイヤーの属性によって変化させてもよいし、それらを区別せずに一律に5のように定めてもよい。サーバ装置11は、クレジットカード会社の決済サーバ装置との間のデータ通信において、評価を行わなかったバイヤーに関しては、共同購入DBの該当するレコードのフィールド単価に示される単価に、フィールド購入申込の購入数量データにより示される購入数量を乗じた金額を請求する一方、評価を行ったバイヤーに関しては、単価に購入数量を乗じた金額に上述したような割引率の割引を行った後の金額を請求する。上記のように、演算部114は決済サーバ装置に対する商品代金の支払い要求を完了すると、処理の完了した共同購入DB図7のレコードのフィールド購入申込の各々に関し、売買履歴DB図5に新規レコードを作成し、作成したレコードに対応するデータを格納する。その際、フィールド売買IDには演算部114が新たに自動生成したユニークなIDが格納され、フィールド売買日時にはその時点の日時を示す時刻データが格納される。また、フィールド割引率には上記のようにバイヤーによる評価の有無に基づく所定の割引率が格納される。その他のフィールドについては、共同購入DBのレコードの対応するフィールドのデータが格納される。演算部114は売買履歴DBに新たに生成したレコードの各々に関し、フィールドバイヤーIDを検索キーとしてバイヤーDB図3からレコードを検索し、検索したレコードのフィールド氏名、住所等のデータを取得する。演算部114はそのように取得したバイヤーのデータとともに、売買履歴DBのレコードのフィールド商品名、売買数量、売買単価、割引率のデータをサプライヤーID毎にリスト化し、例えばサーバ装置11に接続されたプリンタに出力し、リストの印字を行う。サイト運営者は、商品代金がクレジットカード会社から支払われると、サプライヤーDB図4のフィールド口座情報に示されるサプライヤー指定の銀行口座に商品代金を入金するとともに、上述のようにプリンタから印字された売買情報のリストを各サプライヤーに送付する。なお、この入金の処理は、サーバ装置11と各銀行のオンラインバンク用のサーバ装置との間のデータ通信により自動化してもよい。また、売買情報のリストの送付の処理は、予めサプライヤーから登録を受けたFAX番号やメールアドレス等に対し、サーバ装置11がリストの送信を行うことで自動化してもよい。サイト運営者から商品代金の支払いを受けたサプライヤーは、サイト運営者から受領した売買情報のリストに従い、各バイヤーに対し商品の発送を行う。これにより、共同購入における一連の処理が完了する。以上のように、商品販売システム1によれば、共同購入による商品の販売を申し出たいサプライヤーは、多くのバイヤーから高い評価を得る必要がある。そのため、例えば通常販売において質の高い商品を提供し、またその販売において質の高いサービスを行うように動機付けられる。また、共同購入により商品の購入を行いたいと思うバイヤーは、通常販売より安価に商品を購入できる共同購入を成立させるため、そのサプライヤーもしくは商品に関する評価を行うように動機付けられる。その際、商品購入時の割引が受けられるため、その動機付けがさらに強いものとなる。その結果、リピーター購入者の支持を受けた良質なサプライヤーによる良質な商品のみが共同購入の対象として許可されることになり、過度の価格競争に陥ることなくサプライヤーにとって望ましいとともに、バイヤーにとっても良質な商品提供を安心して受けられるため望ましい。[1.2.第2実施例]以下に、本発明の第2実施例にかかるサービス販売システム2を説明する。サービス販売システム2は、第1実施例にかかる商品販売システム1が扱う一般的な商品に代えて、バイヤーに対し所定のサービスを受けるためのチケットであるクーポンの販売を行うシステムである。サービスが共同購入の対象となる場合、同地域内において同じサービスに関し同時期に多数のサプライヤーが共同購入におけるサービス提供の申し出を行った場合、いずれのサプライヤーも必要な購入申込数を獲得することができない、という問題が生じやすい。そのため、サービス販売システム2においては、時期的なブロックであるタームと、地域的なブロックであるエリアを定め、タームとエリアの組み合わせの各々に関し、同種のサービスは例えば最大3件しか販売許可を行わない、というルールが採用されている。さらに、サービス販売システム2においては、販売許可を行う条件、すなわち許可条件として、商品販売システム1におけるような平均総合評価点を閾値とする絶対的評価によるものではなく、同種のサービス提供を行うサプライヤーの中で、獲得した総合評価点が多いもの上位3位に販売許可を与える、という相対的評価による条件が採用されている。その他の点に関しては、サービス販売システム2は商品販売システム1と共通している。従って、以下にサービス販売システム2が商品販売システム1と異なる点を中心に説明する。なお、以下に特に述べない場合であっても、サービス販売システム2が商品販売システム1と共通する部分において、商品はクーポンと読み替えられる必要がある。また、サービス販売システム2が備える構成部は商品販売システム1が備える構成部と共通であるため、以下の説明において、サービス販売システム2が備える構成部には商品販売システム1における対応する構成部と同じ符号を付す。図10は、サービス販売システム2におけるサプライヤーDBのデータ構成を模式的に示した図である。サービス販売システム2におけるサプライヤーDBのレコードは、商品販売システム1におけるサプライヤーDB図4のレコードが備えるフィールドに加え、以下のデータを格納するフィールドを有している。エリア:サプライヤーがサービスを提供するエリアを示すテキストデータを格納する。住所:サプライヤーがサービスを提供する場所の住所を示すテキストデータを格納する。電話番号:サプライヤーの電話番号を示すテキストデータを格納する。なお、フィールドエリアは、サプライヤーがサービス販売システム2に対するユーザ登録を行う際に、予めサイト運営者により定められたエリアをリストアップしたメニューリストから選択したものである。図11は、サービス販売システム2における共同購入DBのデータ構成を模式的に示した図である。サービス販売システム2における共同購入DBのレコードは、商品販売システム1における共同購入DB図7のレコードが備えるフィールドに加え、以下のデータを格納するフィールドを有している。エリア:サプライヤーがサービスを提供するエリアを示すテキストデータを格納する。サービス提供期間:サプライヤーがサービスを提供する期間クーポン有効期間を示すデータを格納する。また、サービス販売システム2における共同購入DBのレコードのフィールド判定期間およびフィールド購入申込期間には、商品販売システム1における場合と異なり、サプライヤーがそれらの期間の開始日時および終了日時を自由に決定して得られた期間ではなく、例えば2011年第1ターム:2011年1月1日~2011年2月15日のように、予めサイト運営者により定められた複数のタームの中から選択された期間を示すデータが格納される。フィールドサービス提供期間に関しても同様である。図12は、サービス販売システム2における共同購入予告ページを模式的に示した図である。サービス販売システム2における共同購入予告ページには、商品販売システム1における共同購入予告ページ図8と比較し、店舗エリア、店舗住所および店舗電話番号の記載が追加されている。これらのデータはサプライヤーDB図10から取得されたデータであり、サービスの提供場所がバイヤーにとってアクセス可能な場所であるか否かを判断するため、また必要に応じてバイヤーが直接サプライヤーにコンタクトをとるために表示されている。また、サービス販売システム2における共同購入予告ページにおいては、販売までにさらに獲得を要する総合評価点ポイント数ではなく、現在の総合評価点による順位と、現在の3位の総合評価点と比べ足りないポイント数が表示される。サービス販売システム2においては他のサプライヤーとの相対評価により販売の許可がなされるためである。サービス販売システム2において、サーバ装置11の演算部114は共同購入予告ページを生成するにあたり、共同購入DB図11のレコードのうち現在の日時がフィールド判定期間により示される期間内であるものを、フィールドクーポンカテゴリーによりグループ化する。そのようにグループ化された1以上のレコードの各々により示される共同購入に関し演算部114は総合評価点を算出し、算出した総合評価点が高いものから順に順位付けを行う。そのようにして特定された順位に基づき、共同購入予告ページにおける順位や獲得すべきポイント数等が決定される。演算部114は、フィールド判定期間に示される期間の終了日時を過ぎると、上記のようにグループ化したレコードの各々に関し総合評価点を算出し、総合評価点が高いものから順に上位3位を選択し、それらのレコードのフィールド販売許可を許可で書き換える。そのように販売許可の与えられたレコードにより示される共同購入に関しては、図13に示すような共同購入ページが生成され、バイヤーによる購入申込が可能となる。なお、バイヤーにクーポンが送付される形態としては様々なものが考えられる。例えば、いわゆる紙に印字されたクーポンがバイヤーに郵送されてもよいし、クーポンの内容を記載した電子メールがバイヤーのメールアドレス宛に送信されてもよい。以上説明したように、サービス販売システム2においては同じ時期に同じ地域において同種のサービスの提供を行う複数のサプライヤーの中から、バイヤーによる評価が高いものから優先的に適当な数のサプライヤーが選択され、それらのサプライヤーにのみ、共同購入によるクーポンの販売が許可される。そのため、サイト運営者により恣意的に特定のサプライヤーに対し販売許可がなされることがなく、またサイト運営者が販売許可を与えるサプライヤーを選択する手間も要さず、望ましい。[2.変形例]上述した実施例は本発明の技術的思想の範囲内において様々に変形可能である。以下にそのような変形の例を示す。上述した実施例においては、共同購入における商品販売またはクーポン販売の許可が、算出式1として示した式に従い算出された総合評価点に基づき判定されるものとしたが、この算出式1はあくまで例示であって、バイヤーによる評価に基づく数値指標を変数とする様々な算出式が採用可能である。さらに、総合評価点という1つの数値指標にのみ基づくのではなく、例えば、店舗評価点が100ポイント以上であり、商品評価点が300ポイント以上であり、評価が1のものが20以下であるといったような、複数の条件を組み合わせたものなど、様々な形式の許可条件が本発明において採用可能である。また、上述した実施例においては、販売許可の判定のために用いる変数として、バイヤーによる1~5のいずれかの自然数による評価点が採用されているが、他の様々な形式の評価が本発明における販売許可の判定のための変数として採用可能である。例えば、店舗や商品の評価に関する複数の質問項目の各々に関し、バイヤーがはいかいいえで答える形式のアンケートを行い、はいの数を評価点として用いることなどが考えられる。また、店舗や商品に対しバイヤーから寄せられた口コミのうち、肯定的なキーワードが否定的なキーワードより多く含まれる口コミの数を評価点として用いることなども考えられる。さらに、バイヤーによる評価に加えて、サプライヤーによる過去の販売実績販売成立回数、商品販売数、販売金額総計などなど、バイヤーによる評価以外の指標が販売許可の判定の基準として採用されてもよい。また、上述した実施例においてサーバ装置11は、販売許可の判定のために用いる評価データを、バイヤー端末装置13から送信されてくる評価データを受信することで取得するものとしたが、本発明においてサーバ装置11が評価データを取得する方法はそれに限られない。例えば、任意のバイヤーによりアンケート用紙等の紙媒体に記入された商品サービスもしくはサプライヤーに関する評価結果をサイト運営者がサーバ装置11に対し直接入力することでサーバ装置11が評価データを取得する構成や、サイト運営者が操作する端末装置に対し入力された評価データが当該端末装置からサーバ装置11に送信され、サーバ装置11がネットワーク19を介して当該評価データを受信することで評価データを取得する構成など、他の方法によりサーバ装置11が評価データを取得する構成が採用されてもよい。なお、サイト運営者等が紙媒体に記入された評価結果を端末装置に入力する方法としては、例えば手入力による方法が採用されてもよいし、スキャナ装置により読み取らせた画像データを認識プログラムに従った変換処理によりサーバ装置11またはサイト運営者等が操作する端末装置において評価データに自動変換する方法が採用されてもよい。また、上述した第1実施例においては、全てのサプライヤーに関し、同一の規則で算出された平均総合評価点が販売許可の条件における閾値として採用されているが、例えば商品カテゴリーや販売数量等に応じて、サプライヤー毎に販売許可の条件を自動的に変化させる構成が採用されてもよい。また、上述した第2実施例においては、全てのクーポンカテゴリーに関し、販売許可を与えるサプライヤーの数を同じとしたが、クーポンカテゴリー毎に、例えば過去の販売成立数等に応じて、販売許可を与えるサプライヤーの数を自動的に変化させる構成が採用されてもよい。さらに、上位3位まで、のように予め販売許可を与えるサプライヤー数を固定せずに、販売成立数の累計が所定数に達するまで上位のサプライヤーから順に販売許可を与えるなど、販売許可を与えるサプライヤーの数が所定の規則に従い変化する構成が採用されてもよい。また、上述した実施例においては、商品サービスの購入申込数の多少にかかわらず、商品サービスの単価は変化しないものとしたが、例えば購入申込数が多くなれば単価が下がるような価格体系が採用されてもよい。また、上述した実施例においては、共同購入における商品サービスの販売に関しバイヤーによる評価に基づく販売の許可が判定されるものとしたが、共同購入に加えて、もしくはそれに代えて、通常購入における商品サービスの販売に関しバイヤーの評価に基づく販売の許可が判定される構成が採用されてもよい。また、上述した実施例においては、バイヤーはバイヤーDB図3のフィールドバイヤーカテゴリーに示される一般もしくはプロという属性のいずれかに区分されるものとしたが、バイヤーの属性はその他、様々なものが考えられる。例えば、優れた口コミを書き込んでいるバイヤーを他のバイヤーが評価可能とし、あるバイヤーが他のバイヤーから獲得した評価がそのバイヤーの属性として利用される構成が採用されてもよい。以下にそのような例を示す。他のバイヤーを評価したいバイヤーは、バイヤー端末装置13を用いてサーバ装置11にアクセスし、バイヤー評価ページを表示させ、そのページにおいて他のバイヤーの評価を入力する。入力された評価を示すデータがバイヤー端末装置13からサーバ装置11に送信され、サーバ装置11において例えば5段階や上限のない評価ポイント等の指標に変換され、バイヤーDBの評価対象のバイヤーに関するレコードの、例えば、フィールドバイヤー評価に格納される。上記のように、フィールドバイヤー評価に格納されたデータにより示されるバイヤーに関する評価指標は、例えばそのバイヤーにより行われるサプライヤーに関する評価の重み付けに反映される。その結果、多くのバイヤーから高い評価を受けたバイヤーによる評価が、サプライヤーの評価においてより重視されることになり、サプライヤーの評価における信頼性が高まる。また、バイヤーの属性の他の例として、性別、職業、年齢、住んでいる地域、といった属性をバイヤーDBに格納するようにしてもよい。これらの属性を利用した例を以下に示す。サーバ装置11は、バイヤーを、年齢、職業、性別、といった属性に基づき、複数のバイヤーグループ、例えば、20歳代の学生男性、40歳以上の主婦女性等のいずれかに区分する。続いて、各バイヤーによるサプライヤーもしくは商品サービスに関する評価をバイヤーグループ毎に集計し、さらに、バイヤーグループ毎に予め設定された重み付けに従い全てのバイヤーグループに関する評価を1つの評価に集約する。サーバ装置11は、そのように集約した評価を、共同購入における商品サービスクーポンの販売許可における判定に用いる。上記のような構成が採用されると、実際に商品サービスを購入するがサプライヤーや商品サービスの評価はあまり行わないバイヤーグループの評価が過小評価される、といった不都合を回避することができる。なお、バイヤーグループ毎に評価を集計する方法としては、例えば、バイヤーグループに属するバイヤーによる評価点の平均値を用いる方法、上述した他のバイヤーによる評価の高い者から順に選出した所定数のバイヤーによる評価点の合計値を用いる方法など、様々な方法が採用可能である。また、上述した実施例において、売買履歴DB図5等に示される商品名クーポン名、商品カテゴリークーポンカテゴリー、販売数量等のデータは、各サプライヤーが販売している商品サービスの内容や過去の販売実績を示すため、サプライヤーの属性を示すデータの一種であるが、それら以外のサプライヤーの属性が本発明にかかる商品販売システムもしくはサービス販売システムにおいて利用されてもよい。そのような例を以下に示す。例えば、第1実施例における商品販売システム1においては、サプライヤーの拠点となる地域を問わず同じ評価点を獲得することが販売許可を受けるための条件として設定されている。そのような場合、実店舗を利用したバイヤーの評価が必ずしも公平に評価されない、といった不都合を生じる場合がある。すなわち、人口密度の高い地域にある実店舗には人口密度の低い地域にある実店舗よりも一般的に多くのバイヤーが訪れる。そのため、必然的に人口密度の高い地域に実店舗を持つサプライヤーは人口密度の低い地域に実店舗を持つサプライヤーと比べ、実店舗を訪れたバイヤーにより比較的容易に多くの評価を得ることができる。上記のような不公平を是正するために、例えばサプライヤーDB図4にフィールドサプライヤー地域を設ける。そして、サーバ装置11がフィールドサプライヤー地域に示される地域毎に、例えば販売許可の基準となる獲得すべきポイント数を変化させる。同様に、例えばサプライヤーを、商品サービスの販売経験期間もしくは販売実績に応じて、新店舗、中堅店舗、老舗のように区分し、それらの区分毎に異なる基準で販売許可の判定を行う構成が採用されてもよい。その場合、例えば、新規に商品サービスの販売を開始した店舗が、まだバイヤー間に認知されていないために多くの評価を獲得できず、共同購入による販売許可を受けることができないが故に認知度を高めることができない、という不都合を是正することができる。また、バイヤーが他のバイヤーを評価するのと同様に、サプライヤーが他のサプライヤーを評価することを可能とする構成が採用されてもよい。なお、サーバ装置11がバイヤー、サプライヤーもしくは商品サービスが獲得した評価に基づき、例えば獲得した評価ポイントが高い順にランキング表示するランキング表示ページをサプライヤー端末装置12やバイヤー端末装置13に対し配信する構成が採用されてもよい。その場合、バイヤーに関してはより良質な口コミや評価を行う動機付けが与えられ、サプライヤーに関してはより良質な商品サービスの提供を行う動機付けが与えられる。また、上記の実施例においては、バイヤーはサプライヤーと商品サービスの各々に関し個別に評価を行うものとしたが、本発明はそれに限られず、例えばあるサプライヤーにより提供される商品サービスに関する評価のみが行われる構成が採用されてもよい。バイヤーにとって、サプライヤーに関する評価と、そのサプライヤーから提供された商品サービスに関する評価を区別することが困難な場合も多く、上記のような構成によればバイヤーの評価における負担が軽減される。その際、サーバ装置11が、バイヤーにより商品サービスに関し行われた評価をサプライヤー毎に集計することで、サプライヤーに関する評価を自動的に生成する構成が採用されてもよい。また、上述した実施例においては、共同購入DB図7のフィールド判定期間に示される期間において、バイヤーからサプライヤーおよび商品サービスに関する評価を受け付ける構成が採用されている。このような構成によれば、ある商品サービスの共同購入による購入を望むバイヤーはその商品サービスの販売が許可されるように、その商品サービスおよびサプライヤーに関し積極的に評価を行うため、結果としてサーバ装置11が多くの評価データを取得できる点で望ましい。その一方で、販売許可前の駆け込み評価により販売許可の可否が左右されると、その商品サービスに対し実際より高い評価が行われ、評価の信憑性に疑いが生じる場合もある。そのような不都合を回避するために、判定期間における評価の受け付けを行わない構成が採用されてもよい。同様の理由で、判定期間および購入申込期間に評価を行ったバイヤーに対し購入価格の割引を行う等のインセンティブを与えることを行わない構成が採用されてもよい。また、上述した実施例において、サプライヤー端末装置12およびバイヤー端末装置13は、サーバ装置11から配信されるWebページを汎用のWebブラウザにより解釈し表示するものとしたが、本発明はそれに限られず、例えばサーバ装置11から送信されてくるWebページを、サプライヤー端末装置12およびバイヤー端末装置13が専用のWebブラウザに従い解釈し表示する構成が採用されてもよい。さらに、サーバ装置11とサプライヤー端末装置12およびバイヤー端末装置13との間で送受信されるデータの形式は、HTML等のページ記述言語により記述されたデータに限られない。その場合、例えばサプライヤー端末装置12およびバイヤー端末装置13に専用のアプリケーションプログラムをインストールしておき、サプライヤー端末装置12およびバイヤー端末装置13が当該アプリケーションプログラムに従いサーバ装置11から受信した独自形式のデータを処理することで、本発明にかかるシステムが実現される。また、上述した実施例において、第1実施例にかかる商品販売システム1は一般的な商品を販売するシステム、第2実施例にかかるサービス販売システム1はサービスの提供を受けるクーポンを販売するシステム、として区別されているが、商品販売システム1にサービス販売システム2を組み合わせ、一般的な商品とサービス提供に関するクーポン等の販売をともに扱う販売システムを構成してもよい。また、サービスの提供に関して一般的な商品の販売と比べ、地域性が高い場合が多いが、一般的な商品であっても、例えば生菓子のように、地域性が高い商品もある。一方、サービスの提供に関しても、全国にチェーン店を持つ教室など、地域性に乏しいサービスもある。従って、販売許可においてサプライヤーの店舗の所在地を問わない商品販売システム1においてサービス提供に関するクーポンの販売を行ってもよいし、販売許可においてサプライヤーの店舗の所在地に応じて地域毎に販売許可を行うサービス販売システム2において一般的な商品の販売を行ってもよい。