(57)【要約】【課題】電子商取引において、商品またはサービスの購入を検討している消費者と電子商取引のサイト運営者の両方に特段の労力を強いることなく、消費者にとって満足度の高い商取引を可能とする手段を提供する。【解決手段】サーバ装置１１は、過去にバイヤーにより操作されるバイヤー端末装置１３から受信した店舗や商品に関する評価を示すデータを記憶している。サプライヤーは、サプライヤー端末装置１２を操作して、共同購入における商品販売の条件を示すデータをサーバ装置１１に送信することで、商品販売の申込を行う。サーバ装置１１は申込のあった商品販売に関し、バイヤーの評価が所定の条件を満たすか否かを判定し、条件が満たされたと判定した場合に限り、商品販売の許可を与える。その結果、過度の価格競争により質の低い商品が販売される、という不都合が回避される。【選択図】図１
2012234227.tif 000002
【特許請求の範囲】
【請求項１】
サーバ装置が、1以上の第１の端末装置のうちの任意の第１の端末装置から、商品またはサービスを示すとともに当該商品またはサービスを販売する条件を示す販売条件データを受信する販売条件データ受信ステップと、
前記サーバ装置が、商品またはサービスの販売を許可するための条件を示す許可条件データを記憶する許可条件データ記憶ステップと、
前記サーバ装置が、１以上の第２の端末装置のうちの任意の第２の端末装置から、商品またはサービスを示すとともに当該商品またはサービスに関する評価を示す評価データを受信する評価データ受信ステップと、
前記サーバ装置が、前記評価データ受信ステップにおいて受信した評価データにより示される一の商品またはサービスに関する評価に基づき、前記許可条件データ記憶ステップにおいて記憶した当該一の商品またはサービスに関する許可条件データにより示される条件が満たされたか否かを判定する判定ステップと、
前記サーバ装置が、前記判定ステップにおいて一の商品またはサービスに関し前記条件が満たされたと判定した場合に限り、前記販売条件データ受信ステップにおいて受信した販売条件データのうち当該一の商品またはサービスを示す販売条件データにより示される条件に従い当該一の商品またはサービスの販売の申し出を示す販売申出データを前記１以上の第２の端末装置のうちの少なくとも１の第２の端末装置に送信する販売申出データ送信ステップと
を備える方法。
【請求項２】
前記サーバ装置が、前記販売申出データ送信ステップにおいて送信した販売申出データの送信先の第２の端末装置から、一の商品またはサービスの購入の申し込みを示す購入申込データを受信する購入申込データ受信ステップを備え、
前記販売条件データ受信ステップにおいて前記サーバ装置が受信する一の商品またはサービスに関する販売条件データは、前記購入申込データ受信ステップにおいて受信した購入申込データにより購入が申し込まれた当該一の商品またはサービスの総量が所定の閾値以上である場合に限り、もしくは当該総量が所定の閾値を超過する場合に限り、当該一の商品またはサービスの販売を実施するという条件を示す
請求項１に記載の方法。
【請求項３】
前記サーバ装置は、前記判定ステップにおいて、前記販売条件データ受信ステップにおいて複数の異なる第１の端末装置から受信した複数の販売条件データを所定の規則に従いグループ化して得られる一のグループに属する複数の販売条件データの各々に関し、当該販売条件データにより示される一の商品またはサービスに関し前記評価データ受信ステップにおいて受信した評価データにより示される評価に基づく指標を生成し、当該一のグループに属する複数の販売条件データの各々に関し生成した当該指標の比較結果に基づき当該複数の販売条件データのうちの少なくとも１の販売条件データを選択し、当該選択した少なくとも１の販売条件データにより示される商品またはサービスに関し前記許可条件が満たされたと判定する
請求項１または２に記載の方法。
【請求項４】
前記サーバ装置が、前記評価データ受信ステップにおいて受信した評価データの送信元の第２の端末装置を識別する端末識別データを記憶する端末識別データ記憶ステップを備え、
前記サーバ装置は、前記販売申出データ送信ステップにおいて、前記端末識別データ記憶ステップにおいて記憶した端末識別データにより識別される第２の端末装置に対し、前記端末識別データ記憶ステップにおいて記憶した端末識別データにより識別されない第２の端末装置と比較して安価な販売価格で一の商品またはサービスの販売を申し出ることを示す前記販売申出データを送信する
請求項１乃至３のいずれかに記載の方法。
【請求項５】
前記サーバ装置が、前記１以上の第２の端末装置の各々に関し、当該第２の端末装置の使用者の属性を示す属性データを記憶する属性データ記憶ステップを備え、
前記サーバ装置は、前記判定ステップにおいて、前記評価データ受信ステップにおいて受信した評価データの送信元の第２の端末装置の使用者に関し前記属性データ記憶ステップにおいて記憶した属性データにより示される属性に基づき、前記判定を行う
請求項１乃至４のいずれかに記載の方法。
【請求項６】
前記サーバ装置が、前記評価データ受信ステップにおいて受信した一の商品またはサービス以外の他の商品またはサービスに関する評価データにより示される評価に基づき、当該一の商品またはサービスの販売を許可する条件を示す許可条件データを生成する許可条件データ生成ステップを備え、
前記サーバ装置は、前記許可条件データ記憶ステップにおいて、前記許可条件データ生成ステップにおいて生成した許可条件データを記憶する
請求項１乃至５のいずれかに記載の方法。
【請求項７】
前記サーバ装置が、前記販売条件データ受信ステップにおいて受信した一の商品またはサービスに関する販売条件データにより示される条件に基づき、当該一の商品またはサービスの販売を許可する条件を示す許可条件データを生成する許可条件データ生成ステップを備え、
前記サーバ装置は、前記許可条件データ記憶ステップにおいて、前記許可条件データ生成ステップにおいて生成した許可条件データを記憶する
請求項１乃至５のいずれかに記載の方法。
【請求項８】
他の通信装置から送信されてくるデータを受信する受信手段と、データを記憶する記憶手段と、演算処理を行う演算手段と、データを他の通信装置に送信する送信手段とを備え、
前記受信手段は、1以上の第１の端末装置のうちの任意の第１の端末装置から、商品またはサービスを示すとともに当該商品またはサービスを販売する条件を示す販売条件データを受信し、
前記記憶手段は、商品またはサービスの販売を許可するための条件を示す許可条件データを記憶し、
前記受信手段は、１以上の第２の端末装置のうちの任意の第２の端末装置から、商品またはサービスを示すとともに当該商品またはサービスに関する評価を示す評価データを受信し、
前記演算手段は、前記受信手段により受信された評価データにより示される一の商品またはサービスに関する評価に基づき、前記記憶手段により記憶されている当該一の商品またはサービスに関する許可条件データにより示される条件が満たされたか否かを判定し、
前記送信手段は、前記演算手段による判定において一の商品またはサービスに関し前記条件が満たされたと判定された場合に限り、前記受信手段により受信された前記販売条件データのうち当該一の商品またはサービスを示す販売条件データにより示される条件に従い当該一の商品またはサービスの販売の申し出を示す販売申出データを前記１以上の第２の端末装置のうちの少なくとも１の第２の端末装置に送信する
サーバ装置。
【請求項９】
前記受信手段は、前記送信手段により送信された販売申出データの送信先の第２の端末装置から、一の商品またはサービスの購入の申し込みを示す購入申込データを受信し、
前記受信手段により受信された一の商品またはサービスに関する販売条件データは、前記受信手段により受信された購入申込データにより購入が申し込まれた当該一の商品またはサービスの総量が所定の閾値以上である場合に限り、もしくは当該総量が所定の閾値を超過する場合に限り、当該一の商品またはサービスの販売を実施するという条件を示す
請求項８に記載のサーバ装置。
【請求項１０】
前記演算手段は、前記判定において、前記受信手段により複数の異なる第１の端末装置から受信された複数の販売条件データを所定の規則に従いグループ化して得られる一のグループに属する複数の販売条件データの各々に関し、当該販売条件データにより示される一の商品またはサービスに関し前記受信手段により受信された評価データにより示される評価に基づく指標を生成し、当該一のグループに属する複数の販売条件データの各々に関し生成した当該指標の比較結果に基づき当該複数の販売条件データのうちの少なくとも１の販売条件データを選択し、当該選択した少なくとも１の販売条件データにより示される商品またはサービスに関し前記許可条件が満たされたと判定する
請求項８または９に記載のサーバ装置。
【請求項１１】
前記記憶手段は、前記受信手段により受信された評価データの送信元の第２の端末装置を識別する端末識別データを記憶し、
前記送信手段は、前記記憶手段により記憶されている端末識別データにより識別される第２の端末装置に対し、前記記憶手段により記憶されている端末識別データにより識別されない第２の端末装置と比較して安価な販売価格で一の商品またはサービスの販売を申し出ることを示す前記販売申出データを送信する
請求項８乃至１０のいずれかに記載のサーバ装置。
【請求項１２】
前記記憶手段は、前記１以上の第２の端末装置の各々に関し、当該第２の端末装置の使用者の属性を示す属性データを記憶し、
前記演算手段は、前記受信手段により受信された評価データの送信元の第２の端末装置の使用者に関し前記記憶手段により記憶されている属性データにより示される属性に基づき、前記判定を行う
請求項８乃至１１のいずれかに記載のサーバ装置。
【請求項１３】
前記演算手段は、前記受信手段により受信された一の商品またはサービス以外の他の商品またはサービスに関する評価データにより示される評価に基づき、当該一の商品またはサービスの販売を許可する条件を示す許可条件データを生成し、
前記記憶手段は、前記演算手段により生成された許可条件データを記憶する
請求項８乃至１２のいずれかに記載のサーバ装置。
【請求項１４】
前記演算手段は、前記受信手段により受信された一の商品またはサービスに関する販売条件データにより示される条件に基づき、当該一の商品またはサービスの販売を許可する条件を示す許可条件データを生成し、
前記記憶手段は、前記演算手段により生成された許可条件データを記憶する
請求項８乃至１２のいずれかに記載のサーバ装置。
【請求項１５】
他の通信装置との間でデータ通信を行う通信手段を備えるコンピュータを
請求項８乃至１４のいずれかに記載のサーバ装置が備える前記受信手段、前記記憶手段、前記演算手段、前記送信手段として機能させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを利用して商品またはサービスの販売および購入を可能とする技術に関する。
【背景技術】
【０００２】
近年、インターネットおよび携帯電話網を介したデータの送受信の仕組みが普及するに伴い、それらのネットワークを介したデータ通信に基づく電子商取引が盛んに行われている。
【０００３】
一般的な実店舗における場合と比較して、購入者が商品またはサービスの質が十分であるか否かを電子商取引において購入前に十分に検討することは難しい。電子商取引においては、実店舗において実際に商品を手にしたりサービスの実演を見たり、もしくは店員の説明を聞いたりする場合と比較し、購入者に提示される商品やサービスに関する情報が限られているためである。
【０００４】
また、電子商取引においては通常、購入者が販売者と直接対面することがないため、誇大広告など、購入者を欺く情報がＷｅｂサイトに掲載される危険性も高い。
【０００５】
上記のような電子商取引における不都合を軽減するために、多くの電子商取引のサイトにおいて、過去に同じ商品またはサービスの購入を行った消費者による口コミやレビューといった評価を示す情報が掲載されている。購入者はそれらの評価を商品またはサービスの質を判断する上で参考とすることができる。
【０００６】
例えば、特許文献１には、商品のレビューを行ったユーザが過去にその商品を購入した個数等の情報に基づき、そのユーザのレビューの信頼度を評価することで、電子商取引において購入者が商品の質を事前に判断することを容易とする仕組みが提案されている。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００９−１２３１９２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
上述したように、既に商品またはサービスを購入した人によるレビューや口コミといった評価は、新たにその商品またはサービスの購入を検討している人にとって有意義な情報となる。ただし、そのような評価に関する情報が多量にある場合には、購入を検討している者は、それらの情報の全てを把握するために多大な時間と労力を用いなければならず、一方でそのような評価に関する情報が不足している場合には情報不足により必ずしも十分な検討が行えない。
【０００９】
そこで、電子商取引のサイトの運営者が、電子商取引のサイトにおいて売買される商品またはサービスの質を担保するために、販売される予定の商品やサービスを個別に評価し、その評価に応じて販売者による商品またはサービスの販売を許可するか否かを判定する、という対策が取られている場合もある。しかしながら、その場合、サイトの運営者による判定が恣意的となりやすく、またサイトの運営者の労力が増す。
【００１０】
上記の事情に鑑み、本発明は、電子商取引において、商品またはサービスの購入を検討している消費者と電子商取引のサイト運営者の両方に特段の労力を強いることなく、消費者にとって満足度の高い商取引を可能とする手段を提供することを目的とする。
【課題を解決するための手段】
【００１１】
上記の課題を解決するため、本発明は、
サーバ装置が、1以上の第１の端末装置のうちの任意の第１の端末装置から、商品またはサービスを示すとともに当該商品またはサービスを販売する条件を示す販売条件データを受信する販売条件データ受信ステップと、
前記サーバ装置が、商品またはサービスの販売を許可するための条件を示す許可条件データを記憶する許可条件データ記憶ステップと、
前記サーバ装置が、１以上の第２の端末装置のうちの任意の第２の端末装置から、商品またはサービスを示すとともに当該商品またはサービスに関する評価を示す評価データを受信する評価データ受信ステップと、
前記サーバ装置が、前記評価データ受信ステップにおいて受信した評価データにより示される一の商品またはサービスに関する評価に基づき、前記許可条件データ記憶ステップにおいて記憶した当該一の商品またはサービスに関する許可条件データにより示される条件が満たされたか否かを判定する判定ステップと、
前記サーバ装置が、前記判定ステップにおいて一の商品またはサービスに関し前記条件が満たされたと判定した場合に限り、前記販売条件データ受信ステップにおいて受信した販売条件データのうち当該一の商品またはサービスを示す販売条件データにより示される条件に従い当該一の商品またはサービスの販売の申し出を示す販売申出データを前記１以上の第２の端末装置のうちの少なくとも１の第２の端末装置に送信する販売申出データ送信ステップと
を備える方法を提供する。（第１の実施態様）
【００１２】
上記の第１の実施態様において、
前記サーバ装置が、前記販売申出データ送信ステップにおいて送信した販売申出データの送信先の第２の端末装置から、一の商品またはサービスの購入の申し込みを示す購入申込データを受信する購入申込データ受信ステップを備え、
前記販売条件データ受信ステップにおいて前記サーバ装置が受信する一の商品またはサービスに関する販売条件データは、前記購入申込データ受信ステップにおいて受信した購入申込データにより購入が申し込まれた当該一の商品またはサービスの総量が所定の閾値以上である場合に限り、もしくは当該総量が所定の閾値を超過する場合に限り、当該一の商品またはサービスの販売を実施するという条件を示す
構成が採用されてもよい。（第２の実施態様）
【００１３】
また、上記の第１または第２の実施態様において、
前記サーバ装置は、前記判定ステップにおいて、前記販売条件データ受信ステップにおいて複数の異なる第１の端末装置から受信した複数の販売条件データを所定の規則に従いグループ化して得られる一のグループに属する複数の販売条件データの各々に関し、当該販売条件データにより示される一の商品またはサービスに関し前記評価データ受信ステップにおいて受信した評価データにより示される評価に基づく指標を生成し、当該一のグループに属する複数の販売条件データの各々に関し生成した当該指標の比較結果に基づき当該複数の販売条件データのうちの少なくとも１の販売条件データを選択し、当該選択した少なくとも１の販売条件データにより示される商品またはサービスに関し前記許可条件が満たされたと判定する
構成が採用されてもよい。（第３の実施態様）
【００１４】
また、上記の第１乃至第３のいずれかの実施態様において、
前記サーバ装置が、前記評価データ受信ステップにおいて受信した評価データの送信元の第２の端末装置を識別する端末識別データを記憶する端末識別データ記憶ステップを備え、
前記サーバ装置は、前記販売申出データ送信ステップにおいて、前記端末識別データ記憶ステップにおいて記憶した端末識別データにより識別される第２の端末装置に対し、前記端末識別データ記憶ステップにおいて記憶した端末識別データにより識別されない第２の端末装置と比較して安価な販売価格で一の商品またはサービスの販売を申し出ることを示す前記販売申出データを送信する
構成が採用されてもよい。（第４の実施態様）
【００１５】
また、上記の第１乃至第４のいずれかの実施態様において、
前記サーバ装置が、前記１以上の第２の端末装置の各々に関し、当該第２の端末装置の使用者の属性を示す属性データを記憶する属性データ記憶ステップを備え、
前記サーバ装置は、前記判定ステップにおいて、前記評価データ受信ステップにおいて受信した評価データの送信元の第２の端末装置の使用者に関し前記属性データ記憶ステップにおいて記憶した属性データにより示される属性に基づき、前記判定を行う
構成が採用されてもよい。（第５の実施態様）
【００１６】
また、上記の第１乃至第５のいずれかの実施態様において、
前記サーバ装置が、前記評価データ受信ステップにおいて受信した一の商品またはサービス以外の他の商品またはサービスに関する評価データにより示される評価に基づき、当該一の商品またはサービスの販売を許可する条件を示す許可条件データを生成する許可条件データ生成ステップを備え、
前記サーバ装置は、前記許可条件データ記憶ステップにおいて、前記許可条件データ生成ステップにおいて生成した許可条件データを記憶する
構成が採用されてもよい。（第６の実施態様）
【００１７】
また、上記の第１乃至第５のいずれかの実施態様において、
前記サーバ装置が、前記販売条件データ受信ステップにおいて受信した一の商品またはサービスに関する販売条件データにより示される条件に基づき、当該一の商品またはサービスの販売を許可する条件を示す許可条件データを生成する許可条件データ生成ステップを備え、
前記サーバ装置は、前記許可条件データ記憶ステップにおいて、前記許可条件データ生成ステップにおいて生成した許可条件データを記憶する
構成が採用されてもよい。（第７の実施態様）
【００１８】
また、本発明は、
他の通信装置から送信されてくるデータを受信する受信手段と、データを記憶する記憶手段と、演算処理を行う演算手段と、データを他の通信装置に送信する送信手段とを備え、
前記受信手段は、1以上の第１の端末装置のうちの任意の第１の端末装置から、商品またはサービスを示すとともに当該商品またはサービスを販売する条件を示す販売条件データを受信し、
前記記憶手段は、商品またはサービスの販売を許可するための条件を示す許可条件データを記憶し、
前記受信手段は、１以上の第２の端末装置のうちの任意の第２の端末装置から、商品またはサービスを示すとともに当該商品またはサービスに関する評価を示す評価データを受信し、
前記演算手段は、前記受信手段により受信された評価データにより示される一の商品またはサービスに関する評価に基づき、前記記憶手段により記憶されている当該一の商品またはサービスに関する許可条件データにより示される条件が満たされたか否かを判定し、
前記送信手段は、前記演算手段による判定において一の商品またはサービスに関し前記条件が満たされたと判定された場合に限り、前記受信手段により受信された前記販売条件データのうち当該一の商品またはサービスを示す販売条件データにより示される条件に従い当該一の商品またはサービスの販売の申し出を示す販売申出データを前記１以上の第２の端末装置のうちの少なくとも１の第２の端末装置に送信する
サーバ装置を提供する。（第８の実施態様）
【００１９】
上記の第８の実施態様において、
前記受信手段は、前記送信手段により送信された販売申出データの送信先の第２の端末装置から、一の商品またはサービスの購入の申し込みを示す購入申込データを受信し、
前記受信手段により受信された一の商品またはサービスに関する販売条件データは、前記受信手段により受信された購入申込データにより購入が申し込まれた当該一の商品またはサービスの総量が所定の閾値以上である場合に限り、もしくは当該総量が所定の閾値を超過する場合に限り、当該一の商品またはサービスの販売を実施するという条件を示す
構成が採用されてもよい。（第９の実施態様）
【００２０】
また、上記の第８または第９の実施態様において、
前記演算手段は、前記判定において、前記受信手段により複数の異なる第１の端末装置から受信された複数の販売条件データを所定の規則に従いグループ化して得られる一のグループに属する複数の販売条件データの各々に関し、当該販売条件データにより示される一の商品またはサービスに関し前記受信手段により受信された評価データにより示される評価に基づく指標を生成し、当該一のグループに属する複数の販売条件データの各々に関し生成した当該指標の比較結果に基づき当該複数の販売条件データのうちの少なくとも１の販売条件データを選択し、当該選択した少なくとも１の販売条件データにより示される商品またはサービスに関し前記許可条件が満たされたと判定する
構成が採用されてもよい。（第１０の実施態様）
【００２１】
また、上記の第８乃至第１０のいずれかの実施態様において、
前記記憶手段は、前記受信手段により受信された評価データの送信元の第２の端末装置を識別する端末識別データを記憶し、
前記送信手段は、前記記憶手段により記憶されている端末識別データにより識別される第２の端末装置に対し、前記記憶手段により記憶されている端末識別データにより識別されない第２の端末装置と比較して安価な販売価格で一の商品またはサービスの販売を申し出ることを示す前記販売申出データを送信する
構成が採用されてもよい。（第１１の実施態様）
【００２２】
また、上記の第８乃至第１１のいずれかの実施態様において、
前記記憶手段は、前記１以上の第２の端末装置の各々に関し、当該第２の端末装置の使用者の属性を示す属性データを記憶し、
前記演算手段は、前記受信手段により受信された評価データの送信元の第２の端末装置の使用者に関し前記記憶手段により記憶されている属性データにより示される属性に基づき、前記判定を行う
構成が採用されてもよい。（第１２の実施態様）
【００２３】
また、上記の第８乃至第１２のいずれかの実施態様において、
前記演算手段は、前記受信手段により受信された一の商品またはサービス以外の他の商品またはサービスに関する評価データにより示される評価に基づき、当該一の商品またはサービスの販売を許可する条件を示す許可条件データを生成し、
前記記憶手段は、前記演算手段により生成された許可条件データを記憶する
構成が採用されてもよい。（第１３の実施態様）
【００２４】
また、上記の第８乃至第１２のいずれかの実施態様において、
前記演算手段は、前記受信手段により受信された一の商品またはサービスに関する販売条件データにより示される条件に基づき、当該一の商品またはサービスの販売を許可する条件を示す許可条件データを生成し、
前記記憶手段は、前記演算手段により生成された許可条件データを記憶する
構成が採用されてもよい。（第１４の実施態様）
【００２５】
また、本発明は、
他の通信装置との間でデータ通信を行う通信手段を備えるコンピュータを
請求項８乃至１４のいずれかに記載のサーバ装置が備える前記受信手段、前記記憶手段、前記演算手段、前記送信手段として機能させるプログラムを提供する。（第１５の実施態様）
【発明の効果】
【００２６】
上記の第１の実施態様にかかる方法または上記の第８の実施態様にかかるサーバ装置によれば、電子商取引において、一定以上の良好な評価を得た商品またはサービスに関してのみ当該商品またはサービスの販売が許可されるため、消費者に対し満足度の低い商品・サービスの購入が促されるという不都合が生じる可能性が低減される。その際、基準となる評価は一般の消費者により提供されるため、電子商取引のサイト運営者等が評価を行う場合と比較し、その評価が中立的であるとともに、サイト運営者の管理負担の増大を伴わない。
【００２７】
上記の第２の実施態様にかかる方法または上記の第９の実施態様にかかるサーバ装置によれば、共同購入として広く知られる仕組み、すなわち一定数量以上の購入が行われる場合に限り通常価格より低価格にて商品またはサービスの販売が実施される仕組みにおいて、商品またはサービスが一定以上の良好な評価を得た場合にのみ、その商品またはサービスの販売が許可される。そのため、特に価格が重視されがちな共同購入において、ともすれば低価格を実現するために質の低い商品やサービスの販売が行われるという危険性が低減され、効果的である。
【００２８】
上記の第３の実施態様にかかる方法または上記の第１０の実施態様にかかるサーバ装置によれば、異なる複数の提供者により販売が予定される同種の商品・サービスに関し、それらの商品・サービスに対する評価が高いものに関し優先的にその販売の許可が行われる。従って、同種の商品・サービスの販売が同時期に重なることにより過度の低価格化が生じるという不都合が回避される。また、評価に基づく販売の許可・不許可の判定において、例えば評価値の閾値を適切に設定することが困難な場合があるが、この実施態様においては評価値の順位（相対値）が判定の基準となるため、そのような困難も伴わない。
【００２９】
上記の第４の実施態様にかかる方法または上記の第１１の実施態様にかかるサーバ装置によれば、商品やサービスの評価を行った購入者は、評価を行わなかった購入者と比べ、低価格で当該商品やサービスの購入を行うことができる。そのため、同じ商品やサービスを繰り返し購入したいと思う購入者による評価が促され、販売許可の判定に要する評価を効率的に収集することができる。
【００３０】
上記の第５の実施態様にかかる方法または上記の第１２の実施態様にかかるサーバ装置によれば、商品やサービスの評価を行った購入者の属性、例えばその購入者が過去に同じ商品やサービスを購入しているか否かといった情報が、販売許可の判定において考慮される。そのため、より信頼性の高い判定が可能となる。
【００３１】
上記の第６の実施態様にかかる方法または上記の第１３の実施態様にかかるサーバ装置によれば、ある商品・サービスの販売許可の判定において獲得すべき評価の基準が他の商品・サービスにおいて獲得されている評価に基づき自動的に設定される。そのため、例えばサイト運営者がそれらの基準を個々の商品・サービスに関し設定する手間を要さない。
【００３２】
上記の第７の実施態様にかかる方法または上記の第１４の実施態様にかかるサーバ装置によれば、ある商品・サービスの販売許可の判定において獲得すべき評価の基準がその商品・サービスの販売成立数や単価などの販売条件に基づき自動的に設定される。そのため、例えばサイト運営者がそれらの基準を個々の商品・サービスに関し設定する手間を要さない。
【００３３】
また、上記の第１５の実施態様にかかるプログラムによれば、外部の通信装置との間でデータの送受信を行う通信手段を備えた一般的なコンピュータを用いて上記の第８乃至第１４のいずれかの実施態様にかかるサーバ装置が実現され、それらの実施態様に関し上述した各種効果が得られる。
【図面の簡単な説明】
【００３４】
【図１】図１は、本発明の第１実施例にかかる商品販売システムの全体構成を模式的に示したブロック図である。
【図２】図２は、本発明の実施例にかかるサーバ装置の機能構成を示したブロック図である。
【図３】図３は、本発明の実施例にかかるバイヤーＤＢのデータ構成を模式的に示した図である。
【図４】図４は、本発明の第１実施例にかかるサプライヤーＤＢのデータ構成を模式的に示した図である。
【図５】図５は、本発明の実施例にかかる売買履歴ＤＢのデータ構成を模式的に示した図である。
【図６】図６は、本発明の実施例にかかる評価ＤＢのデータ構成を模式的に示した図である。
【図７】図７は、本発明の第１実施例にかかる共同購入ＤＢのデータ構成を模式的に示した図である。
【図８】図８は、本発明の第１実施例にかかる共同購入予告ページを模式的に示した図である。
【図９】図９は、本発明の第１実施例にかかる共同購入ページを模式的に示した図である。
【図１０】図１０は、本発明の第２実施例にかかるサプライヤーＤＢのデータ構成を模式的に示した図である。
【図１１】図１１は、本発明の第２実施例にかかる共同購入ＤＢのデータ構成を模式的に示した図である。
【図１２】図１２は、本発明の第２実施例にかかる共同購入予告ページを模式的に示した図である。
【図１３】図１３は、本発明の第２実施例にかかる共同購入ページを模式的に示した図である。
【発明を実施するための形態】
【００３５】
［１．実施例］
以下に本発明の実施例にかかる商品販売システムの構成および動作を説明する。
【００３６】
［１．１．第１実施例］
第１実施例にかかる商品販売システム１は、ネットワークを介して、商品の提供者であるサプライヤーが商品の販売の申し出を行い、商品の消費者であるバイヤーがその申し出に応じて商品の購入の申し込みを行うことで、商品の売買を仲介するシステムである。
【００３７】
商品販売システム１は、上記の通常の商品売買の仕組みに加え、いわゆる共同購入による商品売買の仕組みを備えている。すなわち、商品販売システム１は、サプライヤーと個々のバイヤーとの間の個別の商品売買を仲介するだけでなく、サプライヤーと所定数以上のバイヤーの集まりとの間の商品売買も仲介する。その際、サプライヤーは価格に加え、販売成立数や販売期間といった販売の条件を付して商品の販売を申し出て、その条件により指定された販売期間内に指定された販売成立数を満たす多数のバイヤーからの商品購入の申し込みがあった場合に限り、商品の売買が実施される。
【００３８】
ところで、一般的な共同購入の仕組みにおいては、サプライヤー間が過度な価格競争に陥りやすいという問題がある。バイヤーにとって通常の購入と比べ共同購入を行う主なメリットは低価格であり、共同購入に参加するバイヤーは一般的に価格に敏感である。従って、サプライヤーが共同購入において多くの購入者を獲得するためには、可能な限りその価格を抑える必要がある。そのような価格競争が行き過ぎると、通常販売における商品よりも質の劣る商品が共同購入において販売される、コスト削減のために商品管理等が十分に行われず商品の発送遅れや発送違いなどのエラーが頻発する、といった様々な不都合が生じ得る。
【００３９】
上記のような問題を低減するために、商品販売システムの運営者（以下、「サイト運営者」という）が過去の販売実績等の情報に基づき、サプライヤーによる商品販売の可否を個別に判定する、という努力が行われている。その場合、サイト運営者はその判定に多大な時間と労力を費やさねばならないとともに、その判定が恣意的になりやすい。
【００４０】
一方、商品販売システム１においては、サプライヤーによる商品販売の申し出を許可するか否かの判定が、バイヤーによる評価に基づき自動的に行われる。そのため、サイト運営者はその判定に時間と労力を費やす必要がなく、バイヤーは他の多くのバイヤーによる客観的な基準により選定された商品を安心して購入することができ、サプライヤーはバイヤーによる評価が下がれば共同購入における商品販売それ自体ができなくなるため、過度な価格競争に陥ることがない。
【００４１】
以下においては、商品販売システム１における商品販売の仕組みのうち、一般的な商品販売システムと異なる部分、すなわちバイヤーによる評価に基づきサプライヤーによる商品販売の申し出の許可・不許可が自動的に判定される仕組みを中心に説明する。
【００４２】
図１は、商品販売システム１の全体構成を模式的に示したブロック図である。商品販売システム１は、サプライヤーおよびバイヤーとの間の商品の売買を仲介するサーバ装置１１、サプライヤーにより操作され商品販売の申し出に用いられるサプライヤー端末装置１２（第１の端末装置）、バイヤーにより操作され商品購入の申し込みに用いられるバイヤー端末装置１３（第２の端末装置）を備えている。
【００４３】
サプライヤー端末装置１２およびバイヤー端末装置１３は各々、ネットワーク１９を介してサーバ装置１１との間で各種データの送受信を行うことができる。
【００４４】
図１において、図示されているサーバ装置１１の数は１つであるが、サーバ装置１１は単独の装置として構成されてもよいし、互いに連携し協働する複数の装置の集合体として構成されてもよい。そのような装置の集合体の構成としては、複数の装置の各々がロードバランサーにより配分された同種の処理を行うもの、ネットワーク１９における地域により複数の装置の各々が処理を分担するもの、以下に説明するサーバ装置１１の各種データ処理をその処理の種類に応じて複数の装置が分担するもの、など様々なものが採用可能である。
【００４５】
また、サプライヤー端末装置１２およびバイヤー端末装置１３は各々、商品販売システム１を利用するサプライヤーおよびバイヤーの数に応じて常時変化する。図１においては、ｐ個のサプライヤー端末装置１２およびｑ個のバイヤー端末装置１３が示されている。ただし、ｐおよびｑは各々、任意の自然数である。以下、サプライヤー端末装置１２およびバイヤー端末装置１３の各端末装置群の中の個々の端末装置を区別する必要がある場合、例えばサプライヤー端末装置１２−１のように枝符号を付してそれらを区別する。
【００４６】
サーバ装置１１は、外部の通信装置との間でデータの送受信が可能な汎用コンピュータに、本発明にかかるプログラムに従った処理を行わせることにより実現される。ただし、それに代えて、いわゆる専用サーバ機として以下の処理を行う装置がハードウェア的に構成されてもよい。
【００４７】
図２は、サーバ装置１１の機能構成を示したブロック図である。サーバ装置１１はその機能構成部として、外部の通信装置（サプライヤー端末装置１２およびバイヤー端末装置１３）から送信されてくる各種データを受信する受信部１１１、外部の通信装置に対し各種データを送信する送信部１１２、本発明にかかるプログラムを示すデータや商品情報を示すデータなどの各種データを記憶する記憶部１１３、商品販売の申し出の許可・不許可を判定するとともにサーバ装置１１において他の構成部を制御するための各種演算を行う演算部１１４を備えている。
【００４８】
記憶部１１３には、以下のＤＢ（Database）が格納されている。
バイヤーＤＢ：バイヤーに関する情報を管理するＤＢ。
サプライヤーＤＢ：サプライヤーに関する情報を管理するＤＢ。
売買履歴ＤＢ：過去に行われた商品の売買に関する情報を管理するＤＢ。
評価ＤＢ：サプライヤーにより販売された商品に関するバイヤーによる評価を示す情報を管理するＤＢ。
共同購入ＤＢ：共同購入における商品販売の申し出に関する情報を管理するＤＢ。
【００４９】
図３は、バイヤーＤＢのデータ構成を模式的に示した図である。バイヤーＤＢはバイヤーの各々に関するデータを格納するレコードの集まりである。バイヤーＤＢの各レコードは以下の各種データを格納するフィールドを有している。
【００５０】
バイヤーＩＤ：バイヤーを識別するユーザＩＤ（Identifier）を格納する。
パスワード：バイヤーの本人確認を行うためのパスワードを格納する。
端末ＩＤ：バイヤーが使用する端末装置がユニークな端末ＩＤの割り当てられた携帯端末装置である場合、その端末ＩＤを格納する。
氏名：バイヤーの氏名を示すテキストデータを格納する。
住所：バイヤーの住所を示すテキストデータを格納する。
電話番号：バイヤーの住所を示すテキストデータを格納する。
メールアドレス：バイヤーの住所を示すテキストデータを格納する。
クレジットカード番号：バイヤーのクレジットカードの番号を示すテキストデータを格納する。
バイヤーカテゴリー：バイヤーが一般バイヤーであることを示す「一般」、もしくはバイヤーが商品の仕入等を行うプロのバイヤーであることを示す「プロ」のいずれかを示すテキストデータを格納する。
【００５１】
図４は、サプライヤーＤＢのデータ構成を模式的に示した図である。サプライヤーＤＢはサプライヤーの各々に関するデータを格納するレコードの集まりである。サプライヤーＤＢの各レコードは以下の各種データを格納するフィールドを有している。
【００５２】
サプライヤーＩＤ：サプライヤーを識別するサプライヤーＩＤを格納する。
パスワード：サプライヤーの本人確認を行うためのパスワードを格納する。
端末ＩＤ：サプライヤーが使用する端末装置がユニークな端末ＩＤの割り当てられた携帯端末装置である場合、その端末ＩＤを格納する。
店舗名：サプライヤーが管理する電子商取引上の店舗の名称を示すテキストデータを格納する。
店舗プロファイル：サプライヤーが管理する電子商取引上の店舗の紹介情報を示すテキストデータを格納する。
口座情報：サイト運営者がクレジットカード会社から受け取った商品の販売代金をサプライヤーに支払う際の振込先口座に関する情報を示すテキストデータを格納する。
【００５３】
図５は、売買履歴ＤＢのデータ構成を模式的に示した図である。売買履歴ＤＢは過去に行われた商品売買の各々に関するデータを格納するレコードの集まりである。なお、売買履歴ＤＢには、共同購入による商品売買に関するデータに限られず、一般的な個別の商品売買（通常購入）に関するデータも格納されている。売買履歴ＤＢの各レコードは以下の各種データを格納するフィールドを有している。
【００５４】
売買ＩＤ：個々の売買を識別する売買ＩＤを格納する。
売買日時：売買が行われた日時を示す時刻データを格納する。
サプライヤーＩＤ：商品の販売を行ったサプライヤーを識別するサプライヤーＩＤを格納する。
バイヤーＩＤ：商品の購入を行ったバイヤーを識別するバイヤーＩＤを格納する。
商品ＩＤ：売買された商品を識別する商品ＩＤを格納する。同じサプライヤーから販売される同一の商品は、通常購入・共同購入の別なく同じ商品ＩＤで識別される。
商品名：売買された商品の名称を示すテキストデータを格納する。
商品カテゴリー：売買された商品が属する分類の名称（例えば、「食品−菓子−和菓子」、「スポーツ用品−自転車−本体」など）を示すテキストデータを格納する。
売買数量：売買された商品の数量を示す数値データを格納する。
売買単価：売買された商品の単価を示す数値データを格納する。
割引率：売買単価に対する割引率を示す数値データを格納する。
【００５５】
図６は、評価ＤＢのデータ構成を模式的に示した図である。評価ＤＢは特定のサプライヤーにより販売された特定の商品に関し、任意のバイヤーが行った評価に関するデータを格納するレコードの集まりである。なお、バイヤーは商品販売システム１を介して評価対象の商品を評価対象のサプライヤー（店舗）から過去に通常購入もしくは共同購入にて購入したか否かにかかわらず、店舗および商品の評価を行うことができる。他の商品販売システムを介して同じサプライヤーから同じ商品を購入したバイヤーなどの評価も受け付けるためである。評価ＤＢの各レコードは以下の各種データを格納するフィールドを有している。
【００５６】
評価ＩＤ：個々の評価を識別する評価ＩＤを格納する。
評価日時：評価が行われた日時を示す時刻データを格納する。
バイヤーＩＤ：評価を行ったバイヤーを識別するバイヤーＩＤを格納する。
サプライヤーＩＤ：評価対象のサプライヤーを識別するサプライヤーＩＤを格納する。
商品ＩＤ：評価対象の商品を識別する商品ＩＤを格納する。同じサプライヤーから販売される同一の商品は、通常購入・共同購入の別なく同じ商品ＩＤで識別される。
商品カテゴリー：評価対象の商品が属する分類の名称を示すテキストデータを格納する。
共同購入ＩＤ：共同購入における商品販売の予告から販売実施までの間にその店舗もしくは商品の評価を行った場合、その共同購入を識別する共同購入ＩＤを格納する。なお、その間に行われた評価でない場合、このフィールドは空欄となる。
店舗評価点：店舗に対する評価を１〜５のいずれかの自然数で示す数値データを格納する。なお、数値が高い程、高い評価を示す。
店舗口コミ：店舗に対する評価を言葉で示すテキストデータを格納する。
商品評価点：商品に対する評価を１〜５のいずれかの自然数で示す数値データを格納する。なお、数値が高い程、高い評価を示す。
商品口コミ：商品に対する評価を言葉で示すテキストデータを格納する。
【００５７】
図７は、共同購入ＤＢのデータ構成を模式的に示した図である。共同購入ＤＢは特定のサプライヤーにより提起された共同購入における商品販売の申し出の各々に関するデータを格納するレコードの集まりである。共同購入ＤＢの各レコードは以下の各種データを格納するフィールドを有している。
【００５８】
共同購入ＩＤ：共同購入における商品販売の申し出を識別する共同購入ＩＤを格納する。
サプライヤーＩＤ：商品の販売を行うサプライヤーを識別するサプライヤーＩＤを格納する。
商品ＩＤ：販売される商品を識別する商品ＩＤを格納する。同じサプライヤーから販売される同一の商品は、通常購入・共同購入の別なく同じ商品ＩＤで識別される。
商品名：販売される商品の名称を示すテキストデータを格納する。
商品画像：販売される商品の写真等を示す画像データのファイル名（サーバ装置１１における格納場所）を示すテキストデータを格納する。
商品カテゴリー：販売される商品が属する分類の名称を示すテキストデータを格納する。
販売成立数：販売の実施に要する商品の購入申し込み総数の最低数を示す数値データを格納する。
最大販売数：販売が可能な商品の最大数を示す数値データを格納する。
単価：商品の単価を示す数値データを格納する。
判定期間：販売の申し出を許可するか否かの判定を行う期間（開始日時と終了日時）を示す日時データを格納する。
許可条件：販売の申し出を許可するために満たされるべき条件を示すデータを格納する。具体的には、例えば、店舗評価点と商品評価点を所定の重み付けを伴い加算して得られる総合評価点が２００点以上であることを条件として示す「（総合評価点）≧２００」などのテキストデータが格納される。
販売許可：販売の申し出が未許可であることを示す「未許可」、もしくは販売の申し出が許可されていることを示す「許可」のいずれかを示すテキストデータを格納する。
購入申込期間：バイヤーによる購入の申し込みを受け付ける期間（開始日時と終了日時）を示す日時データを格納する。
購入申込：購入の申し込みを行ったバイヤーを識別するバイヤーＩＤと購入数量を示す数値データ（購入数量データ）との組み合わせを格納する。購入申込が複数あれば、それらに応じた複数組のバイヤーＩＤおよび購入数量データが格納される。
販売実施：購入の申し込みが行われた商品の数が販売成立数にまだ達していないことを示す「未定」、購入の申し込みが行われた商品の数が販売成立数に達し販売が実施されることを示す「実施」、購入の申し込みが行われた商品の数が最大販売数に達し購入申込の受け付けが終了したことを示す「受付終了」、バイヤーからの代金を受領したことを示す「完了」、購入の申し込みが行われた商品の数が購入申込期間中に販売成立数に達さず販売が実施されないことを示す「不実施」のいずれかを示すテキストデータを格納する。
【００５９】
以上が、記憶部１１３に格納される各種ＤＢのデータ構成の説明である。
【００６０】
なお、サプライヤー端末装置１２およびバイヤー端末装置１３は各々、Ｗｅｂブラウザ機能を備えネットワーク１９を介してサーバ装置１１との間で各種データの送受信が可能な汎用的な端末装置であり、その形態はノートＰＣ、デスクトップＰＣ、携帯電話機等のいずれでもよい。
【００６１】
続いて、商品販売システム１の動作を説明する。商品販売システム１を利用するバイヤーおよびサプライヤーは各々、その利用に先立ってサーバ装置１１に対するユーザ登録を行う必要がある。ユーザ登録の手順は広く知られているため詳しい説明は省略するが、例えばバイヤーであれば自分のバイヤー端末装置１３（例えば、バイヤー端末装置１３−１）のＷｅｂブラウザにおいて所定のＵＲＬ（Uniform Resource Locator）を入力しユーザ登録用ページを表示させ、そのユーザ登録用ページにおいて要求されるパスワード、氏名等の入力を行いう。それらの入力されたデータがバイヤー端末装置１３からサーバ装置１１に送信され、バイヤーＤＢ（図３）に登録される。
【００６２】
その際、バイヤー端末装置１３が端末ＩＤの割り当てられた携帯端末装置であれば、その端末ＩＤもバイヤー端末装置１３からサーバ装置１１へと送信され、バイヤーＤＢに登録される。端末ＩＤがバイヤーＤＢに登録されている場合、ユーザは商品販売システム１の利用に際して通常であれば要求されるバイヤーＩＤとパスワードの入力による本人確認の操作を要求されない。携帯端末装置は個々のユーザにより携帯されるため、通常、その所有者の許可無く所有者以外の誰かに操作されることはないためである。
【００６３】
サプライヤーは共同購入により商品を販売したい場合、サプライヤー端末装置１２のＷｅｂブラウザにおいて所定のＵＲＬを入力し、共同購入販売申出ページを表示させる。
【００６４】
ただし、共同購入販売申出ページの表示に先立ち、サプライヤー端末装置１２が端末ＩＤの割り当てられた携帯端末装置であれば端末ＩＤがサプライヤー端末装置１２からサーバ装置１１に送信され、サーバ装置１１においてサプライヤーＤＢに登録されている端末ＩＤと照合されることにより、サプライヤーの識別および本人確認が行われる。一方、サプライヤー端末装置１２が端末ＩＤの割り当てられた携帯端末装置でない場合、ログインページが表示され、サプライヤーは自分のサプライヤーＩＤおよびパスワードを入力する。入力されたサプライヤーＩＤとパスワードの組み合わせはサプライヤー端末装置１２からサーバ装置１１に送信され、サーバ装置１１においてサプライヤーＤＢに登録されているサプライヤーＩＤとパスワードの組み合わせと照合されることにより、サプライヤーの識別および本人確認が行われる。
【００６５】
サプライヤーおよびバイヤーが商品販売システム１を利用する際には、上述した本人確認の処理が要求される。ただし、いったん本人確認（ログイン）の処理が完了したユーザ（サプライヤーもしくはバイヤー）に関しては、そのユーザの利用する端末装置とサーバ装置１１との間で通信コネクションが維持されている限り、再度の本人確認は不要である。その間、サーバ装置１１は接続相手の端末装置（すなわち、その端末装置のユーザのサプライヤーＩＤもしくはバイヤーＩＤ）を通信コネクションのＩＤにより識別することができる。一方、ログアウトや端末装置のリセット等により通信コネクションが切断されると、再度の通信コネクションの確立に伴い再度の本人確認の処理が必要となる。
【００６６】
共同購入販売申出ページにおいて、サプライヤーは共同購入における販売の申し出に関する以下のデータを入力する。
商品名：販売される商品の名称を示すテキストデータ。
商品ＩＤ：販売される商品を識別するＩＤ。サプライヤーが自分で決定する。
商品画像：販売される商品の写真等を示す画像データのファイル名（サプライヤー端末装置１２における格納場所）を示すテキストデータ。
商品カテゴリー：販売される商品が属する分類の名称を示すテキストデータ。
販売成立数：販売の実施に要する商品の購入申し込み総数の最低数を示す数値データ。
最大販売数：販売が可能な商品の最大数を示す数値データ。
単価：商品の単価を示す数値データ。
判定期間：販売の申し出を許可するか否かの判定を行う期間（開始日時と終了日時）を示す日時データ。
購入申込期間：バイヤーによる購入の申し込みを受け付ける期間（開始日時と終了日時）を示す日時データ。
【００６７】
なお、商品ＩＤはサプライヤーが自由に決定する。ただし、同じ商品を繰り返し販売する場合、サプライヤーはそれらの商品に同じ商品ＩＤを用いる。
【００６８】
また、商品カテゴリーは予めサイト運営者により決定されたものを全てのサプライヤーが共通して用いる。そのため、例えばサプライヤーは、共同購入販売申出ページにおいてメニューリストに表示される商品カテゴリーの中から該当するものを１つ選択することにより、その入力を行う。
【００６９】
また、判定期間および購入申込期間は、具体的な開始日時および終了日時を指定してもよいが、例えば判定期間に関しては「申出日から1ヶ月間」、また購入申込期間は「販売許可日から２週間」のように、未確定の開始日時とその日時からの期間長により指定してもよい。
【００７０】
サプライヤーにより入力された共同購入における販売の申し出に関するデータは、サプライヤー端末装置１２からサーバ装置１１に送信される。ただし、商品画像に関しては、入力されたファイル名ではなく、入力されたファイル名により指定される画像データのファイル本体がサプライヤー端末装置１２からサーバ装置１１に送信される。
【００７１】
サーバ装置１１はサプライヤー端末装置１２からそれらのデータを受信すると、共同購入ＤＢ（図７）に新規レコードを作成した後、その新規レコードの対応するフィールドにそれらのデータを格納する。ただし、商品画像に関しては、受信した画像データのファイル本体はサーバ装置１１の所定の場所に格納され、その格納場所を示すファイル名が新規レコードの対応するフィールドに格納される。また、例えば判定期間として「申出日から１ヶ月間」が指定されている場合、その時点の日時を開始日時、その時点から1ヶ月後の時点を終了日時として示す期間データが新規レコードの対応するフィールドに格納される。
【００７２】
また、サーバ装置１１は、その新規レコードの他のフィールドに関し、以下のデータを格納する。
共同購入ＩＤ：新たに自動生成したユニークなＩＤ。
サプライヤーＩＤ：販売の申し出を行ったサプライヤーを識別するサプライヤーＩＤ。
許可条件：新たに自動生成した許可条件を示すテキストデータ。
販売許可：「未許可」を示すテキストデータ。
購入申込：（空欄）
販売実施：「未定」を示すテキストデータ。
【００７３】
なお、上記のサプライヤーＩＤは、サプライヤー端末装置１２のログイン時の本人確認においてサーバ装置１１が取得したサプライヤーＩＤ（もしくは端末ＩＤに基づきサプライヤーＤＢ（図４）から特定したサプライヤーＩＤ）である。
【００７４】
また、上記の許可条件は、例えば以下の手順でサーバ装置１１の演算部１１４により自動生成される。
【００７５】
まず、演算部１１４は評価ＤＢ（図６）から、フィールド「評価日時」により示される日時が過去の所定期間（例えば、１年間）に含まれ、フィールド「商品カテゴリー」が共同購入販売申出ページにおいてサプライヤーにより入力された商品カテゴリーと一致するレコード群を抽出する。このように抽出されたレコード群は、例えば「食品−菓子−和菓子」のように、サプライヤーが販売の申し出を行おうとしている商品と同じカテゴリーに属する商品に関し任意のバイヤーから寄せられた評価を各々格納するレコードの集まりである。
【００７６】
続いて、演算部１１４は抽出したレコード群を、サプライヤーＩＤおよび商品ＩＤの組み合わせ毎にグループ化する。このようにグループ化されたレコード群は各々、個々のサプライヤーにより販売される同じ商品に関し任意のバイヤーから寄せられた評価を各々格納するレコードの集まりである。
【００７７】
続いて、演算部１１４はグループ化したレコード群の各々に関し、総合評価点を算出する。総合評価点は、例えば以下の算出式１により算出される。
総合評価点＝Σ（（ＶＳ×０．３×ＷＳ＋ＶＧ×０．７×ＷＧ）×ＷＢ）・・・（算出式１）
【００７８】
ただし、
ＶＳ：店舗評価点
ＷＳ：評価者（バイヤー）による店舗の利用の有無に基づくウェイト。例えば、評価者が過去の一定期間内（例えば1年間）にこの店舗を利用したことがある場合、ＷＳ＝１．５、利用したことがない場合、ＷＳ＝１．０とする。
ＶＧ：商品評価点
ＷＧ：評価者（バイヤー）による商品の購入の有無に基づくウェイト。例えば、評価者が過去の一定期間内（例えば1年間）にこの商品を購入したことがある場合、ＷＧ＝１．５、利用したことがない場合、ＷＧ＝１．０とする。
ＷＢ：評価者（バイヤー）の属性に基づくウェイト。例えば、評価者がプロのバイヤーである場合、ＷＢ＝１．５、一般のバイヤーである場合、ＷＢ＝１．０とする。
【００７９】
また、「Σ（  ）」はグループに属する複数のレコードの各々に関し（  ）内に示される算出式に従い算出された数値の総和を意味する。
【００８０】
なお、ＶＳおよびＶＧに関しては、評価ＤＢ（図６）のレコードから直接取得される。
【００８１】
また、ＷＳに関しては、売買履歴ＤＢ（図５）のレコードの中に、評価ＤＢのレコードのフィールド「バイヤーＩＤ」および「サプライヤーＩＤ」と同じデータを格納し、かつフィールド「売買日時」がその時点から過去1年以内を示すレコードが発見された場合、過去1年間にその評価者が同じサプライヤーの店舗を利用したことがあることになるためＷＳ＝１．５が設定され、それ以外の場合はＷＳ＝１．０が設定される。
【００８２】
また、ＷＧに関しては、売買履歴ＤＢ（図５）のレコードの中に、評価ＤＢのレコードのフィールド「バイヤーＩＤ」および「商品ＩＤ」と同じデータを格納し、かつフィールド「売買日時」がその時点から過去1年以内を示すレコードが発見された場合、過去1年間にその評価者が同じ商品を購入したことがあることになるためＷＧ＝１．５が設定され、それ以外の場合はＷＧ＝１．０が設定される。
【００８３】
また、ＷＢに関しては、バイヤーＤＢ（図３）の中から、評価ＤＢのレコードのフィールド「バイヤーＩＤ」と同じデータをフィールド「バイヤーＩＤ」に格納するレコードを検索し、その検索されたレコードのフィールド「バイヤーカテゴリー」に格納されているデータが「プロ」であればＷＢ＝１．５が設定され、それ以外の場合はＷＢ＝１．０が設定される。
【００８４】
上記の算出式に従い算出される総合評価点は、店舗に対する評価点を３０％、商品に対する評価点を７０％の比率で勘案し、過去に同じ店舗を利用したバイヤーによる評価の場合、もしくは過去に同じ店舗で同じ商品を購入したバイヤーによる評価の場合、その評価点を１．５倍に重み付けし、さらにプロのバイヤーによる評価の場合、その評価を１．５倍に重み付けして得られる評価の指標である。
【００８５】
このように算出される総合評価点は、バイヤーが過去に同じ店舗を利用したか否か、同じ商品を購入したか否か、プロのバイヤーであるか否か、といったバイヤーの属性に基づく重み付けにより、信頼性の高められた評価の指標である。
【００８６】
演算部１１４は、グループ化されたレコード群の各々について上記のように総合評価点を算出し、それらの平均値（以下、「平均総合評価点」という）を算出する。演算部１１４は平均総合評価点を販売許可の条件における閾値として採用する。すなわち、演算部１１４は、「（総合評価点）≧（平均総合評価点）」といったテキストデータを生成し、先に共同購入ＤＢに生成した新規レコードのフィールド「許可条件」に格納する。この許可条件は、サプライヤーにより販売の申し出の行われた商品が獲得すべき総合評価点が、販売される商品の属する商品カテゴリーにおける平均総合評価点以上であることを販売許可の条件として示すものである。
【００８７】
続いて、演算部１１４は、以上のように新規レコードに対し設定した許可条件が満たされているか否かの判定を行う。サプライヤーが商品販売の実績を多く持ち、多くのバイヤーから既に多くの店舗評価点を獲得している場合や、サプライヤーが同じ商品を過去に多数販売し、多くのバイヤーから既に多くの商品評価点を獲得している場合には、直ちに許可条件が満たされる。その場合、演算部１１４は共同購入ＤＢ（図７）の該当レコードのフィールド「販売許可」を「許可」に書き換える。その際、フィールド「購入申込期間」が例えば「販売許可日から２週間」のように指定されている場合、演算部１１４はフィールド「購入申込期間」に、その時点の日時を開始日時、その時点から２週間後の時点を終了日時として示す期間データでフィールド「購入申込期間」を書き換える。
【００８８】
以上が、サプライヤーにより商品販売システム１に対し申し込まれた共同購入による商品販売の申し出が共同購入ＤＢに登録される際の商品販売システム１における処理である。
【００８９】
演算部１１４は、共同購入ＤＢ（図７）に含まれるレコードのうち、現在の時刻がフィールド「購入申込期間」に示される期間に達しておらず、現在の時刻がフィールド「判定期間」に示される期間内のレコードの各々に関し、図８に模式的に示すような共同購入予告ページの表示を指示するＷｅｂページデータを生成し、任意のバイヤー端末装置１３からアクセス可能な状態で記憶部１１３の所定の場所に記憶する。
【００９０】
共同購入予告ページは、購入申込期間が到来していないため、バイヤーがまだ購入を申し込むことができない商品に関する情報を表示するページである。共同購入募集予告ページの中には、既に許可条件が満たされて販売が許可されている商品に関するものと、まだ許可条件が満たされておらず販売が未許可な商品に関するものが含まれる。共同購入募集予告ページに表示される「販売開始までにさらに必要な総合評価点」が「０」であれば既に販売が許可されており、正の数であれば販売が未許可である。
【００９１】
また、演算部１１４は、共同購入ＤＢ（図７）に含まれるレコードのうち、現在の時刻がフィールド「購入申込期間」に示される期間内であり、フィールド「販売許可」が「許可」であるレコードの各々に関し、図９に模式的に示すような共同購入ページの表示を指示するＷｅｂページデータを生成し、任意のバイヤー端末装置１３からアクセス可能な状態で記憶部１１３の所定の場所に記憶する。
【００９２】
共同購入ページは、購入申込期間が到来し、かつ許可条件が満たされて販売が許可され、バイヤーが購入を申し込むことができる商品に関する情報を表示するページである。
【００９３】
共同購入によって商品の購入を希望するバイヤーは、バイヤー端末装置１３のＷｅｂブラウザにおいて所定のＵＲＬを入力し、共同購入品検索ページを表示させ、例えば「商品カテゴリー＝和菓子」などの検索キーワードを入力することで、共同購入の対象となる商品のリストを表示させることができる。
【００９４】
バイヤーが商品のリストから販売が未開始の商品を選択すると、その商品に関する共同購入予告ページ（図８）がバイヤー端末装置１３に表示される。バイヤーは、その商品のサプライヤーから過去に何らかの商品を買ったことがある場合、共同購入予告ページの「店舗を評価する」ボタンをクリック等することで店舗評価の入力ページを表示させ、店舗を１〜５のいずれかの自然数で評価する店舗評価点と、店舗を言葉で評価する店舗口コミを入力することができる。
【００９５】
同様に、バイヤーはその商品をいずれかのサプライヤーから過去に買ったことがある場合、共同購入予告ページにおいて「商品を評価する」ボタンをクリック等することで商品評価の入力ページを表示させ、商品を１〜５のいずれかの自然数で評価する商品評価点と、商品を言葉で評価する商品口コミを入力する。このように入力された店舗評価点、店舗口コミ、商品評価点、商品口コミを示すデータ（評価データ）は、バイヤー端末装置１３からサーバ装置１１に送信される。
【００９６】
サーバ装置１１はバイヤー端末装置１３から上記の各種評価データを受信すると、評価ＤＢ（図６）に新規レコードを生成し、その新規レコードの対応するフィールドに受信した評価データを各々格納する。
【００９７】
また、サーバ装置１１は、その新規レコードの他のフィールドに関し、以下のデータを格納する。
評価ＩＤ：新たに自動生成したユニークなＩＤ。
評価日時：現在の時刻を示す時刻データ。
バイヤーＩＤ：評価を行ったバイヤーを識別するバイヤーＩＤ。
サプライヤーＩＤ：評価対象のサプライヤーを識別するサプライヤーＩＤ。
商品ＩＤ：評価対象の商品を識別する商品ＩＤ。
商品カテゴリー：評価対象の商品が属する分類の名称を示すテキストデータ。
共同購入ＩＤ：評価を行った共同購入予告ページの共同購入を識別する共同購入ＩＤ。
【００９８】
なお、上記のバイヤーＩＤは、バイヤー端末装置１３のログイン時の本人確認においてサーバ装置１１が取得したバイヤーＩＤ（もしくは端末ＩＤに基づきバイヤーＤＢ（図３）から特定したバイヤーＩＤ）である。
【００９９】
また、上記のサプライヤーＩＤ、商品ＩＤ、商品カテゴリー、共同購入ＩＤは、バイヤーが評価を行う際にクリック等した「店舗を評価する」ボタンおよび「商品を評価する」ボタンが配置された共同購入予告ページを生成する際に、サーバ装置１１において共同購入ＤＢ（図７）から抽出され用いられたレコードに格納されているデータである。
【０１００】
バイヤーが、上述した共同購入品検索ページに表示される商品のリストから既に販売が開始されている商品を選択すると、その商品に関する共同購入ページ（図９）がバイヤー端末装置１３に表示される。
【０１０１】
共同購入ページにおいても、共同購入予告ページと同様に、バイヤーは「店舗を評価する」ボタンもしくは「商品を評価する」ボタンをクリック等して、店舗の評価もしくは商品の評価を行うことができる。
【０１０２】
バイヤーは、共同購入予告ページおよび共同購入ページ以外にも、例えば通常購入のページに配置された「店舗を評価する」ボタンもしくは「商品を評価する」ボタンをクリック等して、店舗の評価もしくは商品の評価を行うことができる。ただし、その場合、評価ＤＢにおいて評価データを格納するレコードのフィールド「共同購入ＩＤ」は空欄となる。
【０１０３】
演算部１１４は、評価ＤＢに新たにレコードが追加されると、共同購入ＤＢ（図７）のレコードのうち、現在の時刻がフィールド「判定期間」に示される期間内であり、フィールド「販売許可」が「未許可」であるものを抽出し、抽出されたレコードの許可条件が満たされたか否かの判定を行う。すなわち、対象のレコードのフィールド「サプライヤーＩＤ」およびフィールド「商品ＩＤ」により特定される商品に関する総合評価点を算出し、また対象のレコードのフィールド「商品カテゴリー」により特定される商品群に関する平均総合評価点を算出し、総合評価点が平均総合評価点以上であるか否かを判定する。
【０１０４】
許可条件が満たされたと判定された場合、演算部１１４は共同購入ＤＢの対象のレコードのフィールド「販売許可」を「許可」に書き換える。このように、販売が許可された共同購入に関しては、その後、フィールド「購入申込期間」に示される期間の開始日時になると、購入申込の受け付けが始まる。
【０１０５】
共同購入ページには、共同購入予告ページと異なり、「商品を注文する」ボタンが配置されている。このページの商品は既に販売が許可され、かつその販売が開始されているため、バイヤーはその商品の購入を申し込むことができるためである。
【０１０６】
バイヤーが「商品を注文する」ボタンをクリック等した後に行われる商品販売システム１の動作およびバイヤーが行うべき作業は、一般的な共同購入におけるものと同様であるので、その説明を省略する。
【０１０７】
バイヤーにより共同購入による商品の購入の申し込みが行われると、演算部１１４は共同購入ＤＢ（図７）の当該共同購入に関するレコードのフィールド「購入申込」に、バイヤーのバイヤーＩＤと、申し込みの行われた商品の数量を示す購入数量データの組み合わせを追加する。
【０１０８】
演算部１１４は、フィールド「購入申込」にそれらのデータを追加すると、フィールド「販売実施」が「未定」の場合、フィールド「購入申込」に含まれる１以上の購入数量データの各々により示される購入数量を合計し、その合計値がフィールド「販売成立数」に達したか否かを判定する。購入数量の合計が販売成立数に達した場合、フィールド「販売実施」を「実施」に書き換える。これにより、共同購入が成立し、サプライヤーからバイヤーへ商品の販売が実施されることになる。
【０１０９】
また、演算部１１４は、フィールド「購入申込」にデータを追加した際、購入数量の合計がフィールド「最大販売数」に達したか否かも判定する。購入数量の合計が最大販売数に達した場合、演算部１１４はフィールド「販売実施」を「受付終了」に書き換える。
【０１１０】
さらに、演算部１１４は、十分に短い間隔で、共同購入ＤＢ（図７）のレコードのうち、フィールド「販売実施」が「未定」または「実施」のものに関し、フィールド「購入申込期間」に示される期間の終了日時を過ぎたか否かを判定する。購入申込期間が既に過ぎていると判定した場合、演算部１１４はフィールド「販売実施」が「未定」のものに関しては、フィールド「販売実施」を「不実施」に書き換える。
【０１１１】
また、フィールド「販売実施」が「実施」のものに関しては、演算部１１４はまず、フィールド「購入申込」に格納されている1以上のバイヤーＩＤの各々に関し、バイヤーＤＢ（図３）の中からフィールド「バイヤーＩＤ」が一致するものを検索し、検索したレコードのフィールド「クレジットカード番号」から、バイヤーのクレジットカード番号を取得する。続いて、演算部１１４は受信部１１１および送信部１１２を介して、図１に図示せぬクレジットカード会社の決済サーバ装置にアクセスし、取得したクレジットカード番号により商品代金の支払い要求を行う。その結果、クレジットカード会社から商品販売システム１のサイト運営者に商品代金の支払いが行われる。
【０１１２】
ところで、商品販売システム１においては、バイヤーによるサプライヤーおよび商品に関する評価の実施を促すために、共同購入予告ページもしくは共同購入ページから評価を行ったバイヤーがそれらのページで紹介されている商品を購入した場合、商品代金の割引を受けることができる。
【０１１３】
その際の割引率は、例えば、過去に同じサプライヤーから何らかの商品を購入したことのあるバイヤーに関しては５％、過去に同じサプライヤーから同じ商品を購入したことのあるバイヤーに関しては１０％、それらのいずれでもない場合は３％、のように、バイヤーの属性によって変化させてもよいし、それらを区別せずに一律に５％のように定めてもよい。
【０１１４】
サーバ装置１１は、クレジットカード会社の決済サーバ装置との間のデータ通信において、評価を行わなかったバイヤーに関しては、共同購入ＤＢの該当するレコードのフィールド「単価」に示される単価に、フィールド「購入申込」の購入数量データにより示される購入数量を乗じた金額を請求する一方、評価を行ったバイヤーに関しては、単価に購入数量を乗じた金額に上述したような割引率の割引を行った後の金額を請求する。
【０１１５】
上記のように、演算部１１４は決済サーバ装置に対する商品代金の支払い要求を完了すると、処理の完了した共同購入ＤＢ（図７）のレコードのフィールド「購入申込」の各々に関し、売買履歴ＤＢ（図５）に新規レコードを作成し、作成したレコードに対応するデータを格納する。
【０１１６】
その際、フィールド「売買ＩＤ」には演算部１１４が新たに自動生成したユニークなＩＤが格納され、フィールド「売買日時」にはその時点の日時を示す時刻データが格納される。また、フィールド「割引率」には上記のようにバイヤーによる評価の有無に基づく所定の割引率が格納される。その他のフィールドについては、共同購入ＤＢのレコードの対応するフィールドのデータが格納される。
【０１１７】
演算部１１４は売買履歴ＤＢに新たに生成したレコードの各々に関し、フィールド「バイヤーＩＤ」を検索キーとしてバイヤーＤＢ（図３）からレコードを検索し、検索したレコードのフィールド「氏名」、「住所」等のデータを取得する。演算部１１４はそのように取得したバイヤーのデータとともに、売買履歴ＤＢのレコードのフィールド「商品名」、「売買数量」、「売買単価」、「割引率」のデータをサプライヤーＩＤ毎にリスト化し、例えばサーバ装置１１に接続されたプリンタに出力し、リストの印字を行う。
【０１１８】
サイト運営者は、商品代金がクレジットカード会社から支払われると、サプライヤーＤＢ（図４）のフィールド「口座情報」に示されるサプライヤー指定の銀行口座に商品代金を入金するとともに、上述のようにプリンタから印字された売買情報のリストを各サプライヤーに送付する。なお、この入金の処理は、サーバ装置１１と各銀行のオンラインバンク用のサーバ装置との間のデータ通信により自動化してもよい。また、売買情報のリストの送付の処理は、予めサプライヤーから登録を受けたＦＡＸ番号やメールアドレス等に対し、サーバ装置１１がリストの送信を行うことで自動化してもよい。
【０１１９】
サイト運営者から商品代金の支払いを受けたサプライヤーは、サイト運営者から受領した売買情報のリストに従い、各バイヤーに対し商品の発送を行う。これにより、共同購入における一連の処理が完了する。
【０１２０】
以上のように、商品販売システム１によれば、共同購入による商品の販売を申し出たいサプライヤーは、多くのバイヤーから高い評価を得る必要がある。そのため、例えば通常販売において質の高い商品を提供し、またその販売において質の高いサービスを行うように動機付けられる。また、共同購入により商品の購入を行いたいと思うバイヤーは、通常販売より安価に商品を購入できる共同購入を成立させるため、そのサプライヤーもしくは商品に関する評価を行うように動機付けられる。その際、商品購入時の割引が受けられるため、その動機付けがさらに強いものとなる。その結果、リピーター購入者の支持を受けた良質なサプライヤーによる良質な商品のみが共同購入の対象として許可されることになり、過度の価格競争に陥ることなくサプライヤーにとって望ましいとともに、バイヤーにとっても良質な商品提供を安心して受けられるため望ましい。
【０１２１】
［１．２．第２実施例］
以下に、本発明の第２実施例にかかるサービス販売システム２を説明する。サービス販売システム２は、第１実施例にかかる商品販売システム１が扱う一般的な商品に代えて、バイヤーに対し所定のサービスを受けるためのチケットであるクーポンの販売を行うシステムである。
【０１２２】
サービスが共同購入の対象となる場合、同地域内において同じサービスに関し同時期に多数のサプライヤーが共同購入におけるサービス提供の申し出を行った場合、いずれのサプライヤーも必要な購入申込数を獲得することができない、という問題が生じやすい。そのため、サービス販売システム２においては、時期的なブロックであるタームと、地域的なブロックであるエリアを定め、タームとエリアの組み合わせの各々に関し、同種のサービスは例えば最大３件しか販売許可を行わない、というルールが採用されている。
【０１２３】
さらに、サービス販売システム２においては、販売許可を行う条件、すなわち許可条件として、商品販売システム１におけるような平均総合評価点を閾値とする絶対的評価によるものではなく、同種のサービス提供を行うサプライヤーの中で、獲得した総合評価点が多いもの上位３位に販売許可を与える、という相対的評価による条件が採用されている。
【０１２４】
その他の点に関しては、サービス販売システム２は商品販売システム１と共通している。従って、以下にサービス販売システム２が商品販売システム１と異なる点を中心に説明する。なお、以下に特に述べない場合であっても、サービス販売システム２が商品販売システム１と共通する部分において、「商品」は「クーポン」と読み替えられる必要がある。また、サービス販売システム２が備える構成部は商品販売システム１が備える構成部と共通であるため、以下の説明において、サービス販売システム２が備える構成部には商品販売システム１における対応する構成部と同じ符号を付す。
【０１２５】
図１０は、サービス販売システム２におけるサプライヤーＤＢのデータ構成を模式的に示した図である。サービス販売システム２におけるサプライヤーＤＢのレコードは、商品販売システム１におけるサプライヤーＤＢ（図４）のレコードが備えるフィールドに加え、以下のデータを格納するフィールドを有している。
エリア：サプライヤーがサービスを提供するエリアを示すテキストデータを格納する。
住所：サプライヤーがサービスを提供する場所の住所を示すテキストデータを格納する。
電話番号：サプライヤーの電話番号を示すテキストデータを格納する。
【０１２６】
なお、フィールド「エリア」は、サプライヤーがサービス販売システム２に対するユーザ登録を行う際に、予めサイト運営者により定められたエリアをリストアップしたメニューリストから選択したものである。
【０１２７】
図１１は、サービス販売システム２における共同購入ＤＢのデータ構成を模式的に示した図である。サービス販売システム２における共同購入ＤＢのレコードは、商品販売システム１における共同購入ＤＢ（図７）のレコードが備えるフィールドに加え、以下のデータを格納するフィールドを有している。
エリア：サプライヤーがサービスを提供するエリアを示すテキストデータを格納する。
サービス提供期間：サプライヤーがサービスを提供する期間（クーポン有効期間）を示すデータを格納する。
【０１２８】
また、サービス販売システム２における共同購入ＤＢのレコードのフィールド「判定期間」およびフィールド「購入申込期間」には、商品販売システム１における場合と異なり、サプライヤーがそれらの期間の開始日時および終了日時を自由に決定して得られた期間ではなく、例えば「２０１１年第１ターム：２０１１年１月１日〜２０１１年２月１５日」のように、予めサイト運営者により定められた複数のタームの中から選択された期間を示すデータが格納される。フィールド「サービス提供期間」に関しても同様である。
【０１２９】
図１２は、サービス販売システム２における共同購入予告ページを模式的に示した図である。サービス販売システム２における共同購入予告ページには、商品販売システム１における共同購入予告ページ（図８）と比較し、店舗エリア、店舗住所および店舗電話番号の記載が追加されている。これらのデータはサプライヤーＤＢ（図１０）から取得されたデータであり、サービスの提供場所がバイヤーにとってアクセス可能な場所であるか否かを判断するため、また必要に応じてバイヤーが直接サプライヤーにコンタクトをとるために表示されている。
【０１３０】
また、サービス販売システム２における共同購入予告ページにおいては、販売までにさらに獲得を要する総合評価点（ポイント数）ではなく、現在の総合評価点による順位と、現在の３位の総合評価点と比べ足りないポイント数が表示される。サービス販売システム２においては他のサプライヤーとの相対評価により販売の許可がなされるためである。
【０１３１】
サービス販売システム２において、サーバ装置１１の演算部１１４は共同購入予告ページを生成するにあたり、共同購入ＤＢ（図１１）のレコードのうち現在の日時がフィールド「判定期間」により示される期間内であるものを、フィールド「クーポンカテゴリー」によりグループ化する。そのようにグループ化された１以上のレコードの各々により示される共同購入に関し演算部１１４は総合評価点を算出し、算出した総合評価点が高いものから順に順位付けを行う。そのようにして特定された順位に基づき、共同購入予告ページにおける順位や獲得すべきポイント数等が決定される。
【０１３２】
演算部１１４は、フィールド「判定期間」に示される期間の終了日時を過ぎると、上記のようにグループ化したレコードの各々に関し総合評価点を算出し、総合評価点が高いものから順に上位３位を選択し、それらのレコードのフィールド「販売許可」を「許可」で書き換える。そのように販売許可の与えられたレコードにより示される共同購入に関しては、図１３に示すような共同購入ページが生成され、バイヤーによる購入申込が可能となる。
【０１３３】
なお、バイヤーにクーポンが送付される形態としては様々なものが考えられる。例えば、いわゆる紙に印字されたクーポンがバイヤーに郵送されてもよいし、クーポンの内容を記載した電子メールがバイヤーのメールアドレス宛に送信されてもよい。
【０１３４】
以上説明したように、サービス販売システム２においては同じ時期に同じ地域において同種のサービスの提供を行う複数のサプライヤーの中から、バイヤーによる評価が高いものから優先的に適当な数のサプライヤーが選択され、それらのサプライヤーにのみ、共同購入によるクーポンの販売が許可される。そのため、サイト運営者により恣意的に特定のサプライヤーに対し販売許可がなされることがなく、またサイト運営者が販売許可を与えるサプライヤーを選択する手間も要さず、望ましい。
【０１３５】
［２．変形例］
上述した実施例は本発明の技術的思想の範囲内において様々に変形可能である。以下にそのような変形の例を示す。
【０１３６】
上述した実施例においては、共同購入における商品販売またはクーポン販売の許可が、算出式１として示した式に従い算出された総合評価点に基づき判定されるものとしたが、この算出式１はあくまで例示であって、バイヤーによる評価に基づく数値指標を変数とする様々な算出式が採用可能である。
【０１３７】
さらに、総合評価点という１つの数値指標にのみ基づくのではなく、例えば、「店舗評価点が１００ポイント以上であり、商品評価点が３００ポイント以上であり、評価が「１」のものが２０％以下である」といったような、複数の条件を組み合わせたものなど、様々な形式の許可条件が本発明において採用可能である。
【０１３８】
また、上述した実施例においては、販売許可の判定のために用いる変数として、バイヤーによる１〜５のいずれかの自然数による評価点が採用されているが、他の様々な形式の評価が本発明における販売許可の判定のための変数として採用可能である。例えば、店舗や商品の評価に関する複数の質問項目の各々に関し、バイヤーが「はい」か「いいえ」で答える形式のアンケートを行い、「はい」の数を評価点として用いることなどが考えられる。また、店舗や商品に対しバイヤーから寄せられた口コミのうち、肯定的なキーワードが否定的なキーワードより多く含まれる口コミの数を評価点として用いることなども考えられる。
【０１３９】
さらに、バイヤーによる評価に加えて、サプライヤーによる過去の販売実績（販売成立回数、商品販売数、販売金額総計など）など、バイヤーによる評価以外の指標が販売許可の判定の基準として採用されてもよい。
【０１４０】
また、上述した実施例においてサーバ装置１１は、販売許可の判定のために用いる評価データを、バイヤー端末装置１３から送信されてくる評価データを受信することで取得するものとしたが、本発明においてサーバ装置１１が評価データを取得する方法はそれに限られない。例えば、任意のバイヤーによりアンケート用紙等の紙媒体に記入された商品・サービスもしくはサプライヤーに関する評価結果をサイト運営者がサーバ装置１１に対し直接入力することでサーバ装置１１が評価データを取得する構成や、サイト運営者が操作する端末装置に対し入力された評価データが当該端末装置からサーバ装置１１に送信され、サーバ装置１１がネットワーク１９を介して当該評価データを受信することで評価データを取得する構成など、他の方法によりサーバ装置１１が評価データを取得する構成が採用されてもよい。
【０１４１】
なお、サイト運営者等が紙媒体に記入された評価結果を端末装置に入力する方法としては、例えば手入力による方法が採用されてもよいし、スキャナ装置により読み取らせた画像データを認識プログラムに従った変換処理によりサーバ装置１１またはサイト運営者等が操作する端末装置において評価データに自動変換する方法が採用されてもよい。
【０１４２】
また、上述した第１実施例においては、全てのサプライヤーに関し、同一の規則で算出された平均総合評価点が販売許可の条件における閾値として採用されているが、例えば商品カテゴリーや販売数量等に応じて、サプライヤー毎に販売許可の条件を自動的に変化させる構成が採用されてもよい。
【０１４３】
また、上述した第２実施例においては、全てのクーポンカテゴリーに関し、販売許可を与えるサプライヤーの数を同じとしたが、クーポンカテゴリー毎に、例えば過去の販売成立数等に応じて、販売許可を与えるサプライヤーの数を自動的に変化させる構成が採用されてもよい。さらに、上位３位まで、のように予め販売許可を与えるサプライヤー数を固定せずに、販売成立数の累計が所定数に達するまで上位のサプライヤーから順に販売許可を与えるなど、販売許可を与えるサプライヤーの数が所定の規則に従い変化する構成が採用されてもよい。
【０１４４】
また、上述した実施例においては、商品・サービスの購入申込数の多少にかかわらず、商品・サービスの単価は変化しないものとしたが、例えば購入申込数が多くなれば単価が下がるような価格体系が採用されてもよい。
【０１４５】
また、上述した実施例においては、共同購入における商品・サービスの販売に関しバイヤーによる評価に基づく販売の許可が判定されるものとしたが、共同購入に加えて、もしくはそれに代えて、通常購入における商品・サービスの販売に関しバイヤーの評価に基づく販売の許可が判定される構成が採用されてもよい。
【０１４６】
また、上述した実施例においては、バイヤーはバイヤーＤＢ（図３）のフィールド「バイヤーカテゴリー」に示される「一般」もしくは「プロ」という属性のいずれかに区分されるものとしたが、バイヤーの属性はその他、様々なものが考えられる。
【０１４７】
例えば、優れた口コミを書き込んでいるバイヤーを他のバイヤーが評価可能とし、あるバイヤーが他のバイヤーから獲得した評価がそのバイヤーの属性として利用される構成が採用されてもよい。以下にそのような例を示す。
【０１４８】
他のバイヤーを評価したいバイヤーは、バイヤー端末装置１３を用いてサーバ装置１１にアクセスし、バイヤー評価ページを表示させ、そのページにおいて他のバイヤーの評価を入力する。入力された評価を示すデータがバイヤー端末装置１３からサーバ装置１１に送信され、サーバ装置１１において例えば５段階や上限のない評価ポイント等の指標に変換され、バイヤーＤＢの評価対象のバイヤーに関するレコードの、例えば、フィールド「バイヤー評価」に格納される。
【０１４９】
上記のように、フィールド「バイヤー評価」に格納されたデータにより示されるバイヤーに関する評価指標は、例えばそのバイヤーにより行われるサプライヤーに関する評価の重み付けに反映される。その結果、多くのバイヤーから高い評価を受けたバイヤーによる評価が、サプライヤーの評価においてより重視されることになり、サプライヤーの評価における信頼性が高まる。
【０１５０】
また、バイヤーの属性の他の例として、性別、職業、年齢、住んでいる地域、といった属性をバイヤーＤＢに格納するようにしてもよい。これらの属性を利用した例を以下に示す。
【０１５１】
サーバ装置１１は、バイヤーを、年齢、職業、性別、といった属性に基づき、複数のバイヤーグループ、例えば、「２０歳代の学生（男性）」、「４０歳以上の主婦（女性）」等のいずれかに区分する。続いて、各バイヤーによるサプライヤーもしくは商品・サービスに関する評価をバイヤーグループ毎に集計し、さらに、バイヤーグループ毎に予め設定された重み付けに従い全てのバイヤーグループに関する評価を１つの評価に集約する。サーバ装置１１は、そのように集約した評価を、共同購入における商品・サービス（クーポン）の販売許可における判定に用いる。
【０１５２】
上記のような構成が採用されると、実際に商品・サービスを購入するがサプライヤーや商品・サービスの評価はあまり行わないバイヤーグループの評価が過小評価される、といった不都合を回避することができる。
【０１５３】
なお、バイヤーグループ毎に評価を集計する方法としては、例えば、バイヤーグループに属するバイヤーによる評価点の平均値を用いる方法、上述した他のバイヤーによる評価の高い者から順に選出した所定数のバイヤーによる評価点の合計値を用いる方法など、様々な方法が採用可能である。
【０１５４】
また、上述した実施例において、売買履歴ＤＢ（図５）等に示される商品名（クーポン名）、商品カテゴリー（クーポンカテゴリー）、販売数量等のデータは、各サプライヤーが販売している商品・サービスの内容や過去の販売実績を示すため、サプライヤーの属性を示すデータの一種であるが、それら以外のサプライヤーの属性が本発明にかかる商品販売システムもしくはサービス販売システムにおいて利用されてもよい。そのような例を以下に示す。
【０１５５】
例えば、第１実施例における商品販売システム１においては、サプライヤーの拠点となる地域を問わず同じ評価点を獲得することが販売許可を受けるための条件として設定されている。そのような場合、実店舗を利用したバイヤーの評価が必ずしも公平に評価されない、といった不都合を生じる場合がある。すなわち、人口密度の高い地域にある実店舗には人口密度の低い地域にある実店舗よりも一般的に多くのバイヤーが訪れる。そのため、必然的に人口密度の高い地域に実店舗を持つサプライヤーは人口密度の低い地域に実店舗を持つサプライヤーと比べ、実店舗を訪れたバイヤーにより比較的容易に多くの評価を得ることができる。
【０１５６】
上記のような不公平を是正するために、例えばサプライヤーＤＢ（図４）にフィールド「サプライヤー地域」を設ける。そして、サーバ装置１１がフィールド「サプライヤー地域」に示される地域毎に、例えば販売許可の基準となる獲得すべきポイント数を変化させる。
【０１５７】
同様に、例えばサプライヤーを、商品・サービスの販売経験（期間もしくは販売実績）に応じて、「新店舗」、「中堅店舗」、「老舗」のように区分し、それらの区分毎に異なる基準で販売許可の判定を行う構成が採用されてもよい。その場合、例えば、新規に商品・サービスの販売を開始した店舗が、まだバイヤー間に認知されていないために多くの評価を獲得できず、共同購入による販売許可を受けることができないが故に認知度を高めることができない、という不都合を是正することができる。
【０１５８】
また、バイヤーが他のバイヤーを評価するのと同様に、サプライヤーが他のサプライヤーを評価することを可能とする構成が採用されてもよい。
【０１５９】
なお、サーバ装置１１がバイヤー、サプライヤーもしくは商品・サービスが獲得した評価に基づき、例えば獲得した評価ポイントが高い順にランキング表示するランキング表示ページをサプライヤー端末装置１２やバイヤー端末装置１３に対し配信する構成が採用されてもよい。その場合、バイヤーに関してはより良質な口コミや評価を行う動機付けが与えられ、サプライヤーに関してはより良質な商品・サービスの提供を行う動機付けが与えられる。
【０１６０】
また、上記の実施例においては、バイヤーはサプライヤーと商品・サービスの各々に関し個別に評価を行うものとしたが、本発明はそれに限られず、例えばあるサプライヤーにより提供される商品・サービスに関する評価のみが行われる構成が採用されてもよい。バイヤーにとって、サプライヤーに関する評価と、そのサプライヤーから提供された商品・サービスに関する評価を区別することが困難な場合も多く、上記のような構成によればバイヤーの評価における負担が軽減される。
【０１６１】
その際、サーバ装置１１が、バイヤーにより商品・サービスに関し行われた評価をサプライヤー毎に集計することで、サプライヤーに関する評価を自動的に生成する構成が採用されてもよい。
【０１６２】
また、上述した実施例においては、共同購入ＤＢ（図７）のフィールド「判定期間」に示される期間において、バイヤーからサプライヤーおよび商品・サービスに関する評価を受け付ける構成が採用されている。このような構成によれば、ある商品・サービスの共同購入による購入を望むバイヤーはその商品・サービスの販売が許可されるように、その商品・サービスおよびサプライヤーに関し積極的に評価を行うため、結果としてサーバ装置１１が多くの評価データを取得できる点で望ましい。
【０１６３】
その一方で、販売許可前の「駆け込み」評価により販売許可の可否が左右されると、その商品・サービスに対し実際より高い評価が行われ、評価の信憑性に疑いが生じる場合もある。そのような不都合を回避するために、判定期間における評価の受け付けを行わない構成が採用されてもよい。同様の理由で、判定期間および購入申込期間に評価を行ったバイヤーに対し購入価格の割引を行う等のインセンティブを与えることを行わない構成が採用されてもよい。
【０１６４】
また、上述した実施例において、サプライヤー端末装置１２およびバイヤー端末装置１３は、サーバ装置１１から配信されるＷｅｂページを汎用のＷｅｂブラウザにより解釈し表示するものとしたが、本発明はそれに限られず、例えばサーバ装置１１から送信されてくるＷｅｂページを、サプライヤー端末装置１２およびバイヤー端末装置１３が専用のＷｅｂブラウザに従い解釈し表示する構成が採用されてもよい。
【０１６５】
さらに、サーバ装置１１とサプライヤー端末装置１２およびバイヤー端末装置１３との間で送受信されるデータの形式は、ＨＴＭＬ等のページ記述言語により記述されたデータに限られない。その場合、例えばサプライヤー端末装置１２およびバイヤー端末装置１３に専用のアプリケーションプログラムをインストールしておき、サプライヤー端末装置１２およびバイヤー端末装置１３が当該アプリケーションプログラムに従いサーバ装置１１から受信した独自形式のデータを処理することで、本発明にかかるシステムが実現される。
【０１６６】
また、上述した実施例において、第１実施例にかかる商品販売システム１は一般的な商品を販売するシステム、第２実施例にかかるサービス販売システム１はサービスの提供を受けるクーポンを販売するシステム、として区別されているが、商品販売システム１にサービス販売システム２を組み合わせ、一般的な商品とサービス提供に関するクーポン等の販売をともに扱う販売システムを構成してもよい。
【０１６７】
また、サービスの提供に関して一般的な商品の販売と比べ、地域性が高い場合が多いが、一般的な商品であっても、例えば生菓子のように、地域性が高い商品もある。一方、サービスの提供に関しても、全国にチェーン店を持つ教室など、地域性に乏しいサービスもある。従って、販売許可においてサプライヤーの店舗の所在地を問わない商品販売システム１においてサービス提供に関するクーポンの販売を行ってもよいし、販売許可においてサプライヤーの店舗の所在地に応じて地域毎に販売許可を行うサービス販売システム２において一般的な商品の販売を行ってもよい。
【産業上の利用可能性】
【０１６８】
本発明は、商品またはサービスの販売に貢献し、広くサービス業において利用可能である。
【符号の説明】
【０１６９】
１…商品販売システム、２…サービス販売システム、１１…サーバ装置、１２…サプライヤー端末装置、１３…バイヤー端末装置、１９…ネットワーク、１１１…受信部、１１２…送信部、１１３…記憶部、１１４…演算部
【図１】
2012234227.tif 000003
【図２】
2012234227.tif 000004
【図３】
2012234227.tif 000005
【図４】
2012234227.tif 000006
【図５】
2012234227.tif 000007
【図６】
2012234227.tif 000008
【図７】
2012234227.tif 000009
【図８】
2012234227.tif 000010
【図９】
2012234227.tif 000011
【図１０】
2012234227.tif 000012
【図１１】
2012234227.tif 000013
【図１２】
2012234227.tif 000014
【図１３】
2012234227.tif 000015