ユーザの要求に応じて特定された商品について該ユーザが注文を予定する数を取得する注文数取得手段と、前記注文数取得手段により取得された数と前記特定された商品のこれまでに注文された数との和に相当する注文数での販売が決定された場合の該商品の価格を、商品の価格と注文数との組み合わせを示す組み合わせ情報を商品ごとに記憶する記憶手段から取得する価格取得手段と、前記価格取得手段により取得された価格を、前記特定された商品に関連付けて出力する出力手段と、を備えることを特徴とする情報提供装置。請求項1に記載の情報提供装置において、前記注文数取得手段は、注文された商品の数を含む注文ごとの購入履歴を記憶する履歴記憶手段に記憶された前記購入履歴に基づいて、前記ユーザが注文を予定する数を推定することを特徴とする情報提供装置。請求項1に記載の情報提供装置において、前記ユーザの要求は、該ユーザが注文を希望する数を含み、前記注文数取得手段は、前記ユーザの要求に含まれる数を、該ユーザが注文を予定する数として取得することを特徴とする情報提供装置。請求項1乃至3の何れか1項に記載の情報提供装置において、前記記憶手段には、各商品について、該商品の価格と該価格に対応する注文数とを示す前記組み合わせ情報対応情報が価格ごとに記憶され、商品のこれまでの注文数が増加した場合、前記記憶手段に記憶された該商品の前記組み合わせ情報のうち、増加後の注文数以上の範囲内にある注文数に対応しない前記組み合わせ情報対応情報を、前記記憶手段から削除する削除手段を更に備えることを特徴とする情報提供装置。請求項1乃至4の何れか1項に記載の情報提供装置において、商品の販売者により設定された設定情報であり、商品の価格と該価格が適用される注文数とを示す設定情報を商品を識別する識別情報に関連付けて複数記憶する設定情報記憶手段に記憶された前記設定情報のうち、該設定情報に関連付けられた前記識別情報により識別される商品のこれまでに注文された数と予め設定された数との和に相当する注文数以下の範囲内にある注文数に対応する前記設定情報を取得する設定情報取得手段と、前記設定情報取得手段により取得された前記設定情報に応じた前記組み合わせ情報を前記記憶手段に記憶させる制御手段と、を更に備えることを特徴とする情報提供装置。コンピュータにより実行される情報提供方法であって、ユーザの要求に応じて特定された商品について該ユーザが注文を予定する数を取得する注文数取得ステップと、前記注文数取得ステップにおいて取得された数と前記特定された商品のこれまでに注文された数との和に相当する注文数での販売が決定された場合の該商品の価格を、商品の価格と注文数との組み合わせを示す組み合わせ情報を商品ごとに記憶する記憶手段から取得する価格取得ステップと、前記価格取得ステップにおいて取得された価格を、前記特定された商品に関連付けて出力する出力ステップと、を含むことを特徴とする情報提供方法。コンピュータを、ユーザの要求に応じて特定された商品について該ユーザが注文を予定する数を取得する注文数取得手段、前記注文数取得手段により取得された数と前記特定された商品のこれまでに注文された数との和に相当する注文数での販売が決定された場合の該商品の価格を、商品の価格と注文数との組み合わせを示す組み合わせ情報を商品ごとに記憶する記憶手段から取得する価格取得手段、及び、前記価格取得手段により取得された価格を、前記特定された商品に関連付けて出力する出力手段、として機能させることを特徴とする情報提供プログラム。コンピュータを、ユーザの要求に応じて特定された商品について該ユーザが注文を予定する数を取得する注文数取得手段、前記注文数取得手段により取得された数と前記特定された商品のこれまでに注文された数との和に相当する注文数での販売が決定された場合の該商品の価格を、商品の価格と注文数との組み合わせを示す組み合わせ情報を商品ごとに記憶する記憶手段から取得する価格取得手段、及び、前記価格取得手段により取得された価格を、前記特定された商品に関連付けて出力する出力手段、として機能させる情報提供プログラムがコンピュータ読み取り可能に記録されていることを特徴とする記録媒体。ユーザが商品を注文した場合、注文した商品の数分合計注文数が増加することになる。この場合、ユーザによる商品の購入価格は、そのユーザが注文した分増加した後の合計注文数に対して適用される価格である。そのため、ユーザが注文した商品の数に応じて、購入価格の最高値が変化することがある。従って、現時点の合計注文数に適用される価格が表示されるよりも、ユーザ自身が商品を注文したと仮定した場合の増加後の合計注文数に適用される価格が表示される方が、ユーザにとって好ましい場合がある。例えば、ユーザが商品を注文するか否か等を判断する場合、現時点での価格よりも、ユーザ自身が商品を注文したと仮定した場合に適用される価格の方が、判断材料としては適しているからである。しかしながら、従来の技術では、現在の注文数に適用される価格が表示されるだけであった。特許文献1に記載の技術では、商品の価格とその価格が適用される注文数の範囲の一覧が表示されるが、この一覧からでは、自分が注文した場合に適用される価格をユーザが即座に把握することができない。本発明は、以上の点に鑑みてなされたものであり、商品の情報の提供を受けるユーザがその商品を注文したと仮定した場合に適用される価格を提供することができる情報提供装置、情報提供方法、情報提供プログラム及び記録媒体を提供することを目的とする。上記課題を解決するために、請求項1に記載の発明は、ユーザの要求に応じて特定された商品について該ユーザが注文を予定する数を取得する注文数取得手段と、前記注文数取得手段により取得された数と前記特定された商品のこれまでに注文された数との和に相当する注文数での販売が決定された場合の該商品の価格を、商品の価格と注文数との組み合わせを示す組み合わせ情報を商品ごとに記憶する記憶手段から取得する価格取得手段と、前記価格取得手段により取得された価格を、前記特定された商品に関連付けて出力する出力手段と、を備えることを特徴とする。この発明によれば、ユーザは自分が商品を注文するとした場合に注文が予定される数分増加した注文数に応じた商品の価格を知ることができる。請求項2に記載の発明は、請求項1に記載の情報提供装置において、前記注文数取得手段は、注文された商品の数を含む注文ごとの購入履歴を記憶する履歴記憶手段に記憶された前記購入履歴に基づいて、前記ユーザが注文を予定する数を推定することを特徴とする。この発明によれば、ユーザは自分が商品を注文するとした場合に、過去の履歴に基づいて注文が予想される数分増加した注文数に応じた商品の価格を知ることができる。請求項3に記載の発明は、請求項1に記載の情報提供装置において、前記ユーザの要求は、該ユーザが注文を希望する数を含み、前記注文数取得手段は、前記ユーザの要求に含まれる数を、該ユーザが注文を予定する数として取得することを特徴とする。この発明によれば、ユーザは自分が希望する数で商品を注文するとした場合に希望する数分増加した注文数に応じた商品の価格を知ることができる。請求項4に記載の発明は、請求項1乃至3の何れか1項に記載の情報提供装置において、前記記憶手段には、各商品について、該商品の価格と該価格に対応する注文数とを示す前記組み合わせ情報対応情報が価格ごとに記憶され、商品のこれまでの注文数が増加した場合、前記記憶手段に記憶された該商品の前記組み合わせ情報のうち、増加後の注文数以上の範囲内にある注文数に対応しない前記組み合わせ情報対応情報を、前記記憶手段から削除する削除手段を更に備えることを特徴とする。この発明によれば、価格を出力するためには不要となった情報は記憶手段から削除されるため、記憶手段に記憶される情報の量を削減することができる。請求項5に記載の発明は、請求項1乃至4の何れか1項に記載の情報提供装置において、商品の販売者により設定された設定情報であり、商品の価格と該価格が適用される注文数とを示す設定情報を商品を識別する識別情報に関連付けて複数記憶する設定情報記憶手段に記憶された前記設定情報のうち、該設定情報に関連付けられた前記識別情報により識別される商品のこれまでに注文された数と予め設定された数との和に相当する注文数以下の範囲内にある注文数に対応する前記設定情報を取得する設定情報取得手段と、前記設定情報取得手段により取得された前記設定情報に応じた前記組み合わせ情報を前記記憶手段に記憶させる制御手段と、を更に備えることを特徴とする。この発明によれば、価格の出力に用いられる記憶手段を、販売者が設定した情報を記憶する設定情報記憶手段とは別に設けている場合に、設定情報記憶手段に記憶されている情報のうち、価格の出力に当面必要な情報のみを記憶手段に記憶させることができる。そのため、記憶手段の情報を設定情報記憶手段の情報に同期させるための処理負荷を低減させることができる。請求項6に記載の発明は、コンピュータにより実行される情報提供方法であって、ユーザの要求に応じて特定された商品について該ユーザが注文を予定する数を取得する注文数取得ステップと、前記注文数取得ステップにおいて取得された数と前記特定された商品のこれまでに注文された数との和に相当する注文数での販売が決定された場合の該商品の価格を、商品の価格と注文数との組み合わせを示す組み合わせ情報を商品ごとに記憶する記憶手段から取得する価格取得ステップと、前記価格取得ステップにおいて取得された価格を、前記特定された商品に関連付けて出力する出力ステップと、を含むことを特徴とする。請求項7に記載の発明は、コンピュータを、ユーザの要求に応じて特定された商品について該ユーザが注文を予定する数を取得する注文数取得手段、前記注文数取得手段により取得された数と前記特定された商品のこれまでに注文された数との和に相当する注文数での販売が決定された場合の該商品の価格を、商品の価格と注文数との組み合わせを示す組み合わせ情報を商品ごとに記憶する記憶手段から取得する価格取得手段、及び、前記価格取得手段により取得された価格を、前記特定された商品に関連付けて出力する出力手段、として機能させることを特徴とする。請求項8に記載の発明は、コンピュータを、ユーザの要求に応じて特定された商品について該ユーザが注文を予定する数を取得する注文数取得手段、前記注文数取得手段により取得された数と前記特定された商品のこれまでに注文された数との和に相当する注文数での販売が決定された場合の該商品の価格を、商品の価格と注文数との組み合わせを示す組み合わせ情報を商品ごとに記憶する記憶手段から取得する価格取得手段、及び、前記価格取得手段により取得された価格を、前記特定された商品に関連付けて出力する出力手段、として機能させる情報提供プログラムがコンピュータ読み取り可能に記録されていることを特徴とする。本発明によれば、ユーザは自分が商品を注文するとした場合に注文が予定される数分増加した注文数に応じた商品の価格を知ることができる。以下、図面を参照して本発明の実施形態について詳細に説明する。なお、以下に説明する実施の形態は、共同購入システムに対して本発明を適用した場合の実施形態である。[1.第1実施形態][1-1.共同購入システムの構成及び機能概要]先ず、本実施形態に係る共同購入システムSの構成及び機能概要について、図1乃至図3を用いて説明する。図1は、本実施形態に係る共同購入システムSの概要構成の一例を示す図である。図1に示すように、共同購入システムSは、共同購入サーバ1と、複数の店舗端末2と、複数のユーザ端末3と、を含んで構成されている。共同購入サーバ1と、各店舗端末2及び各ユーザ端末3とは、ネットワークNWを介して、例えば、通信プロトコルにTCP/IP等を用いて相互にデータの送受信が可能になっている。なお、ネットワークNWは、例えば、インターネット、専用通信回線例えば、CATVCommunityAntennaTelevision回線、移動体通信網基地局等を含む、及びゲートウェイ等により構築されている。共同購入サーバ1本発明における情報提供装置の一例は、商品の共同購入が可能な電子商店街に関する各種処理を実行するサーバ装置である。共同購入は、例えば、販売期間が設定された取引形態であり、この販売期間内における商品の注文数が多いほど、注文数に応じてその商品の購入価格が段階的に安くなる取引形態である。電子商店街においては、商品の販売者側として複数の店舗が出店している。ユーザは、電子商店街を利用することにより、所望の店舗から所望の商品を購入することができる。共同購入サーバ1は、ユーザ端末3からのリクエストに応じて、例えば、電子商店街のWebページを送信したり、商品の検索や購入等に関する処理を行ったりする。店舗端末2は、電子商店街に出店している店舗の従業員等により利用される端末装置である。店舗端末2は、例えば、販売する商品の情報を電子商店街に登録等するために用いられる。店舗端末2は、従業員等からの操作に基づいて共同購入サーバ1にアクセスする。これにより、店舗端末2は、サーバ装置からWebページを受信して表示する。店舗端末2には、ブラウザや電子メールクライアント等のソフトウェアが組み込まれている。店舗端末2としては、例えば、パーソナルコンピュータ等が用いられる。ユーザ端末3は、電子商店街を利用して商品を購入するユーザの端末装置である。ユーザ端末3は、ユーザからの操作に基づいて共同購入サーバ1にアクセスする。これにより、ユーザ端末3は、サーバ装置からWebページを受信して表示する。ユーザ端末3には、ブラウザや電子メールクライアント等のソフトウェアが組み込まれている。ユーザ端末3としては、例えば、パーソナルコンピュータ、PDAPersonalDigitalAssistant、スマートフォン等の携帯情報端末、携帯電話機等が用いられる。このような構成の共同購入システムSにおいて、共同購入サーバ1は、ユーザから指定された検索条件に基づいて、共同購入可能な商品を検索する。そして、共同購入サーバ1は、検索した商品の情報をユーザ端末3へ提供する。具体的に、共同購入サーバ1は、検索結果ページのHTMLHyperTextMarkupLanguage文書をユーザ端末3へ送信する。検索結果ページは、商品の検索結果として、検索された商品の情報が、その商品に関連付けて一覧表示されるWebページである。表示される商品の情報としては、例えば、商品の価格がある。検索結果ページのHTML文書を送信することは、検索された商品の価格を、その商品に関連付けて出力することの一例である。商品の価格は、その商品がこれまでに注文された数の合計に応じて変化する。ある商品がこれまでに注文された数の合計を、合計注文数という。一例として、合計注文数が1個である場合は3000円、合計注文数が2個以上10個以下である場合は2000円、合計注文数が11個以上である場合は1000円、というように商品の単価が設定される。それぞれの合計注文数の範囲に対して適用される単価を、適用価格という。適用価格は、商品の注文が締め切られた時点における最終的な合計注文数が、その適用価格に対応する合計注文数の範囲内である場合の販売価格である。また、ある適用価格が適用されるために最低限必要な合計注文数を、必要注文数という。上述した例では、3000円、2000円、1000円それぞれの価格に対する必要注文数は、1個、2個、11個である。必要注文数と適用価格との組み合わせは、商品を販売する店舗により設定される。現時点での合計注文数を、現在注文数という。また、現在注文数に対する適用価格を、現在価格という。また、合計注文数が1個である場合の適用価格を、開始価格という。また、設定された必要注文数のうち、最も大きい必要注文数に対する適用価格を、最終価格という。開始価格は、設定された適用価格のうち、最も高い価格である。最終価格は、設定された適用価格のうち、最も低い価格である。検索結果ページにおいては、共同購入可能な商品の価格の表示態様として、2通りの態様がある。第1の態様は、現在価格を表示する態様である。第2の態様は、検索結果ページを閲覧するユーザ自身が、検索結果ページに情報が表示された商品を、そのユーザが予定する注文数で注文したと仮定した場合に適用される価格を表示する態様である。具体的に、検索結果ページを閲覧するユーザが商品を購入したと仮定した場合、その商品の合計注文数が、そのユーザが注文した数分増加することになる。そこで、増加後の合計注文数に対して適用される価格を表示するのである。この価格を、予定価格という。ユーザは、自分が注文をした場合に、例えば、どれだけの価格になるのか、最低限どれだけ価格が安くなるのか等を知りたい場合がある。現在価格と予定価格とが異なる場合、予定価格の方が、商品を注文するか否か等を判断するための判断材料となるからである。検索結果ページを閲覧するユーザが商品を購入したと仮定した場合に、ユーザが注文する数を、予定注文数という。予定価格本発明におけるユーザが注文を予定する数の一例は、現在注文数と予定注文数との和に相当する注文数が最終的な合計注文数となり、その注文数での販売が決定された場合の商品の販売価格である。予定価格を表示するためには、ユーザが商品を注文を予定する数である予定注文数を取得する必要がある。本実施形態では、共同購入サーバ1が、ユーザのこれまでの商品の購入の履歴に基づいて、予定注文数を推定する。具体的には、過去にユーザが商品を注文したときにユーザが指定した注文数に基づいて、予定注文数が推定される。これは、過去の注文数と同様の注文数で未来においても商品が注文される傾向があると考えられるからである。予定注文数は、例えば、商品のジャンルごとに推定される。なお、各商品には、最大注文数が設定されている。最大注文数は、1回の注文で商品を注文可能な数の最大値である。最大注文数は、予定価格を表示する予定注文数の閾値として用いられる。具体的に、予定注文数が最大注文数を上回る場合、合計注文数が最大注文数分増加した場合の適用価格が予定価格として表示される。以下では、価格の表示態様の指定方法と、価格の表示例を説明する。図2は、電子商店街のトップページの表示例を示す図である。トップページは、電子商店街において最上位に位置するWebページであり、また、検索条件を指定するためのWebページである。図2に示すように、トップページは、検索条件設定領域110、ジャンル指定領域120、予定価格表示チェックボックス130等を含む。検索条件設定領域110は、キーワード入力欄111、ジャンル選択メニュー112、検索ボタン113等を含む。キーワード入力欄111は、キーワードを検索条件として入力するための入力領域である。ジャンル選択メニュー112は、商品のジャンルを検索条件として指定するジャンルを選択するためのプルダウンメニューである。検索ボタン113は、検索条件設定領域110において設定された検索条件で、共同購入サーバ1により商品を検索させるためのボタンである。ジャンル指定領域120には、それぞれジャンルに対応した複数のリンクが表示される。各リンクは、対応するジャンルを検索条件として共同購入サーバ1により商品を検索させるためのリンクである。予定価格表示チェックボックス130は、検索結果ページに予定価格を表示させるか否かを選択するためのチェックボックスである。なお、キーワードやジャンル以外の条件を検索条件として指定可能となっていても良い。トップページにおいて、ユーザが検索ボタン113を選択しまたはジャンル選択メニュー112から何れかのリンクを選択すると、共同購入サーバ1が商品の検索を行う。そして、その検索結果を示す検索結果ページが、ユーザ端末3の画面に表示される。図3a及び図3bは、検索結果ページの表示例である。なお、図3a及び図3bは、ミネラルウォーターというキーワードが検索条件として指定された場合の表示例である。また、図3a及び図3bにおいて、互いに同一の要素については同様の符号を付してある。トップページにおいて、ユーザが予定価格表示チェックボックス130に対してチェックを入れる操作をしなかった場合、図3aに示すような検索結果ページが表示される。図3aに示すように、検索結果ページは、検索条件設定領域210、ジャンル指定領域220、検索結果表示領域230等を含む。検索条件設定領域210は、キーワード等、新たな検索条件を設定するための領域である。ジャンル指定領域220には、ジャンルを検索条件として設定するためのリンクが表示される。ジャンル指定領域220では、検索された商品が属するジャンルに対応するリンクのみが表示される。ユーザは、検索条件設定領域210やジャンル指定領域220に対する操作を行うことで、新たな検索条件で共同購入サーバ1により商品を検索させることができる。検索結果表示領域230には、検索された商品の情報が一覧表示される。具体的に、検索結果表示領域230には、該当商品情報231が商品ごとに表示される。該当商品情報231は、例えば、現在価格が低い商品の順に表示される。該当商品情報231は、商品名、店舗名、現在価格、現在注文数、割引率及び次価格残り必要注文数を含む。商品名は、検索された商品の名称である。この商品名は、商品ページへのリンクになっている。商品ページは、選択された商品名が示す商品の詳細な情報が表示されるWebページである。商品ページにおいてユーザが注文操作を行うことにより、その商品ページに情報が掲載されている商品を注文することができる。店舗名は、商品の販売元の店舗の名称である。現在注文数は現時点での合計注文数である。なお、現在注文数が0個である場合、現在価格として、便宜上、開始価格が表示される。次価格残り必要注文数は、商品の価格が現在価格から次の適用価格に変化するまでに必要な残りの注文数である。次の適用価格とは、商品に対して設定された複数の適用価格のうち、現在価格の次に高い価格である。現在注文数に次価格残り必要注文数を加算すると、次の適用価格の必要注文数になる。割引率は、開始価格から現在価格までに割り引かれた分の価格の開始価格に対する割合である。図3aに示す検索結果表示領域230には、例えば、商品A、B、C、D、Eの順に該当商品情報231が表示されているとする。商品Aの現在価格、現在注文数及び次価格残り必要注文数は、1700円、53個及び48個である。このときの現在注文数及び次価格残り必要注文数は、例えば、飲料をケース売りした場合のケースの数であっても良いし、飲料をばら売りした場合の飲料の本数であっても良い。商品Bの現在価格及び現在注文数は、1800円及び16個である。なお、1800円は、商品Bの最終価格である。商品Cの現在価格、現在注文数及び次価格残り必要注文数は、2000円、0個及び1個である。商品Dの現在価格、現在注文数及び次価格残り必要注文数は、2300円、13個及び3個である。商品Eの現在価格、現在注文数及び次価格残り必要注文数は、2500円、2個及び9個である。なお、商品A~Dは、水ミネラルウォーターのジャンルに属する商品である。また、商品Eは、ソフトドリンクに属する商品である。検索条件の指定内容によっては、複数のジャンルの商品が検索される場合がある。トップページにおいて、ユーザが予定価格表示チェックボックス130に対してチェックを入れる操作をした場合、図3bに示すような検索結果ページが表示される。図3bに示す検索結果ページの検索結果表示領域230には、該当商品情報232が商品ごとに表示される。該当商品情報232は、例えば、予定価格が低い商品の順に表示される。該当商品情報232は、商品名、店舗名、予定価格、予定注文数及び割引率を含む。割引率は、開始価格から予定価格までに割り引かれた分の価格の開始価格に対する割合である。ここで、水ミネラルウォーターのジャンルに属する商品の予定注文数は5個と推定され、ソフトドリンクに属する商品の予定注文数は8個と推定されたとする。そのため、商品A、B及びCについては、合計注文数が現在注文数から5個増加した場合の適用価格が予定価格として表示され、商品Eについては、合計注文数が現在注文数から8個増加した場合の適用価格が予定価格として表示されている。商品Dについては、合計注文数が現在注文数から3個増加した場合の適用価格が予定価格として表示されている。その理由は、商品Dの最大注文数が3個であるからである。商品A、B及びEについては、予定注文数が次価格の残り必要注文数未満であるため、予定価格が現在価格から変化していない。その一方で、商品C及びDについては、予定注文数が次価格の残り必要注文数以上であるため、予定価格が現在価格から変化している。具体的に、商品Cの予定価格は1600円であり、商品Dの予定価格は2000円である。その結果、該当商品情報232は、商品C、A、B、D、Eの順に表示されている。このように、検索された商品情報を予定価格が低い順に表示させることができる。ここで、商品Cの予定価格は、例えば、2段階変化している。例えば、必要注文数が2個に対する適用価格が1800円、必要注文数が5個に対する適用価格が1600円である。このように、予定注文数によっては価格が複数段階変化する場合であっても、その価格を表示することができる。なお、該当商品情報232の表示順は、価格の低い順に限られるものではない。例えば、価格の高い順、価格の割引率が高い順、注文数が多い順、注文の締め切り日時が近い順等に表示させることもできる。また、例えば、検索結果ページにおいて、ユーザが表示順を指定することを可能とし、指定された表示順で該当商品情報232を並べ替えた検索結果ページが再表示されるようにしても良い。また、検索条件設定領域210に、予定価格表示チェックボックス130が表示されるようにしても良い。そして、予定価格表示チェックボックス130に対してユーザが選択操作を行った瞬間に、検索結果表示領域230における該当商品情報231の表示と該当商品情報232の表示との切り替えが行われるようにしても良い。つまり、ユーザ端末3が検索結果ページを新たに受信することなく、現在価格の表示の予定価格と表示が瞬時に切り替わるようになっていても良い。[1-2.共同購入サーバの構成]次に、共同購入サーバ1の構成について、図4乃至図6を用いて説明する。図4は、本実施形態に係る共同購入サーバ1の概要構成の一例を示すブロック図である。図4に示すように、共同購入サーバ1は、通信部11と、記憶部12と、入出力インターフェース13と、システム制御部14と、を備えている。そして、システム制御部14と入出力インターフェース13とは、システムバス15を介して接続されている。通信部11は、ネットワークNWに接続して、ユーザ端末3等との通信状態を制御するようになっている。記憶部12は、例えば、ハードディスクドライブ等により構成されている。この記憶部12には、会員情報DB12a、商品情報DB12b、注文情報DB12c、購入履歴DB12d、検索用DB12e等のデータベースが構築されている。各データベースは、例えば、互いに異なるハードディスクドライブに構築されている。図5aは、会員情報DB12aに登録される内容の一例を示す図である。会員情報DB12aには、共同購入システムSに会員登録しているユーザに関する会員情報が登録される。具体的に、会員情報DB12aには、ユーザID、パスワード、ニックネーム、氏名、生年月日、性別、郵便番号、住所、電話番号、電子メールアドレス等のユーザの属性が、ユーザごとに対応付けて登録される。ユーザIDは、ユーザの識別情報である。なお、会員情報DB12aに登録されている会員情報は、共同購入システムS以外のシステムや、共同購入以外のサービスにも用いられる。図5bは、商品情報DB12bに登録される内容の一例を示す図である。商品情報DB12bには、共同購入可能な商品に関する商品情報が登録される。この商品情報は、店舗によって設定される情報である。具体的に、商品情報DB12bには、商品ID、店舗ID、商品コード、ジャンルID、商品名、商品画像のURLUniformResourceLocator、商品説明、注文数別価格リスト、取扱数、最大注文数、販売期間等の商品の属性が、店舗が販売する商品ごとに対応付けて登録される。商品ID本発明における識別情報の一例は、店舗等が、販売する商品を管理するための商品の識別情報である。店舗IDは、商品の販売元の店舗を示す。商品コードは、商品を識別するコード番号である。商品コードとしては、例えば、JANJapaneseArticleNumberCodeコード等がある。ジャンルIDは、商品が属するジャンルの識別情報である。商品名及び商品説明は、商品の情報として商品ページ等に表示されるとともに、キーワード検索で用いられる。具体的に、商品名及び商品説明の少なくとも何れか一方に、ユーザから指定されたキーワードを含む商品が検索される。取扱数は、店舗が対象の商品を販売することができる個数である。商品の合計注文数が取扱数に達すると、注文が締め切られる。販売期間は、商品の注文の受け付け開始日時販売開始日時と、注文の締め切り日時販売終了日時を示す。注文数別価格リストには、複数の価格情報が登録される。価格情報本発明における設定情報の一例は、必要注文数と適用価格との組み合わせを含む。必要注文数が多いほど、対応する適用価格が低くなるようになっている。また、基本的に、価格情報間で必要注文数は重複しない。また、価格情報間で適用価格は重複しない。図5cは、注文情報DB12cに登録される内容の一例を示す図である。注文情報DB12cには、商品の注文の受付に関する情報が登録される。具体的に、注文情報DB12cには、商品ID、現在注文数、注文履歴等が、商品ごとに対応付けて登録される。注文履歴には、対象の商品に対するユーザからの注文の履歴が登録される。具体的に、注文履歴には、注文コード、注文日時、ユーザID、注文数等が、注文ごとに登録される。注文コードは、商品の注文が受け付けられるたびに付与される注文の識別情報である。注文日時は、商品の注文が受け付けられた日時である。ユーザIDは、商品を注文したユーザを示す。注文数は、注文された商品の個数である。図5dは、購入履歴DB12dに登録される内容の一例を示す図である。購入履歴DB12dには、ユーザによる商品の購入履歴が登録される。具体的に、購入履歴DB12dには、注文コード、購入日時、ユーザID、商品ID、店舗ID、商品コード、注文数、購入価格等が対応付けて登録される。購入履歴は、注文の締め切り日時を経過することによって商品を注文したユーザによる商品の購入が確定した場合に、注文ごとに登録される。注文コードは、購入された商品の注文が受け付けられたときに付与されたものである。購入日時は、例えば、注文日時であっても良いし、注文の締め切り日時であっても良い。ユーザIDは、商品を購入したユーザを示す。商品ID及び商品コードは、購入された商品を示す。店舗IDは、購入された商品の販売元の店舗を示す。注文数は、購入された商品が注文された個数である。この場合の注文数は、購入数でもある。購入価格は、購入された商品の最終的な合計注文数に対する適用価格に、注文数を掛け合わせることによって得られた価格である。図5eは、検索用DB12eに登録される内容の一例を示す図である。検索用DB12eには、商品の検索と、該当商品情報231及び232の表示とに必要な商品の情報として、検索用レコードが登録される。この検索用レコード本発明における組み合わせ情報の一例は、検索を高速に行えるように編成された情報が格納される。また、検索用レコードは、各商品について、設定された適用価格ごと注文数別価格リストに登録されている価格情報ごとに登録される。具体的に、検索用レコードは、商品ID、現在注文数、現在価格、残り必要注文数、適用価格及びその他の情報を含む。商品IDが同一である複数の検索用レコードには、同一の現在注文数及び現在価格が含まれる。残り必要注文数は、商品の価格が現在価格から、この残り必要注文数と同一の検索用レコードに含まれる適用価格に変化するまでに必要な残りの注文数である。基本的には、現在注文数と残り必要注文数との和が、適用価格に対応する必要注文数となる。現在注文数が、適用価格に対する必要注文数以上になると、残り必要注文数は0になる。その他の情報としては、例えば、店舗ID、店舗名、ジャンルID、商品コード、商品名、商品画像のURL等がある。適用価格ごとに検索用レコードが登録される理由は、予定注文数に対応する適用価格を予定価格として検索結果ページに表示させるためである。しかしながら、検索用DB12eに、各商品全ての適用価格について検索用レコードを登録しておくと、検索用DB12eのデータ量が膨大となることがある。また、多数の検索用レコードを登録しておくと、検索速度が低下する場合がある。そこで、システム制御部14は、検索及び価格の表示に必要な検索用レコードのみを検索用DB12eに登録させておく。先ず、システム制御部14は、ある商品の注文数別価格リストを含む商品情報が商品情報DB12bに登録されたとき、注文数別価格リストに登録されている価格情報のうち、必要注文数が最大注文数以下である価格情報についてのみ価格情報を登録する。現在注文数最初は0個と最大注文数との和に相当する注文数以下の範囲内で予定価格が表示されれば良いからである。予定注文数が商品の最大注文数を超えた場合、その商品の予定価格として、現在注文数と最大注文数との和に対応する適用価格が表示されるようにすることとした理由は、その時点で検索用DB12eに登録されている情報だけで予定価格を表示可能とするためである。予定価格の表示に当面必要な検索用レコードのみを登録することで、注文数別価格リストに登録されている全ての価格情報について検索用レコードを登録する場合よりも、検索用DB12eの内容を注文数別価格リストの内容に同期させるための処理負荷を低減させることができる。その後、システム制御部14は、ユーザからの注文が受け付けられることによって現在注文数が増加すると、現在注文数に応じて新たに検索用レコードを登録する。具体的に、システム制御部14は、現在注文数の増加によって必要注文数が新たに現在注文数と最大注文数との和以下になった価格情報について検索用レコードを登録する。その一方で、システム制御部14は、現在注文数の増加によって、適用価格が現在価格よりも高くなった検索用レコードを、検索用DB12eから削除する。予定価格は、増加後の現在注文数以上の範囲内にある何れかの注文数に対応する適用価格である。従って、適用価格が現在価格よりも高くなった検索用レコードは、現在注文数以上の範囲内にある注文数に対応しない。現在価格よりも高い適用価格が予定価格として表示されることはないからである。以下に具体例を示す。図6aは、注文数別価格リストに登録される内容の一例を示す図である。また、図6b乃至dは、検索用DB12eに登録されているある商品Xの検索用レコードとこの検索用レコードの内容の一例を示す図である。なお、図6b乃至dにおいて、検索用レコードに含まれるその他の情報の図示は省略している。ある商品Xの注文数別価格リストが、例えば、図6aに示すように設定されている。具体的に、注文数別価格リストには、価格情報が5個登録されている。各価格情報において、必要注文数と適用価格との組み合わせは、1個と10000円、2個と9500円、11個と9000円、101個と8000円、及び、201個と7000円である。また、商品Xの最大注文数を50個とする。商品情報の登録当初、検索用DB12eには、図6bに示すように、商品Xの検索用レコードが3個登録される。具体的に、最大注文数以下である必要注文数1個、2個及び11個である検索用レコードが登録される。このとき、各検索用レコードの現在注文数と現在価格は、0個と10000円である。また、各検索用レコードの残り必要注文数と適用価格は、対応する価格情報の必要注文数と適用価格である。その後、商品Xが40個注文されたとする。すると、現在注文数が40個になるため、現在価格は9000円となる。そのため、図6cに示すように、適用価格が10000円の検索用レコードと、適用価格が9500円の検索用レコードが検索用DB12eから削除される。削除されなかった検索用レコードの現在注文数及び現在価格は更新される。その後、商品Xが更に20個注文されたとする。すると、現在注文数が60個になる。この場合、現在注文数と最大注文数との和が110となる。そのため、図6dに示すように、必要注文数が101個である検索用レコードが新たに検索用DB12eに登録される。また、検索用レコードの現在注文数が更新される。このように、検索用レコードの登録及び削除が行われる。なお、システム制御部14は、残り必要注文数が0個になった検索用レコードも検索用DB12eから削除しても良い。この検索用レコードに含まれる適用価格は現在価格と同一である。この検索用レコードに含まれる適用価格が予定価格として表示される場合は、予定価格が現在価格から変化しない場合である。従って、この場合は、他の検索用レコードに含まれる現在価格を、予定価格として表示すれば良い。ただしこの場合、システム制御部14は、適用価格が最終価格である検索用レコードは削除しない。この検索用レコードを削除してしまうと、対象の商品の検索用レコードが全て削除されることになり、その商品を検索することができなくなるからである。次に、記憶部12に記憶されるその他の情報について説明する。記憶部12には、Webページを表示するためのHTML文書、XMLExtensibleMarkupLanguage文書、画像データ、テキストデータ、電子文書等の各種データが記憶されている。また、記憶部12には、管理者等により設定された各種の設定値が記憶されている。また、記憶部12には、オペレーティングシステム、WWWWorldWideWebサーバプログラム、DBMSDatabaseManagementSystem、電子商取引管理プログラム等の各種プログラムが記憶されている。電子商取引管理プログラムは、商品情報の登録、商品の検索、検索結果ページ等のWebページの生成、商品の注文、検索用DB12eに対する検索用レコードの登録や削除等、電子商店街に関する処理を実行するためのプログラムである。なお、各種プログラムは、例えば、他のサーバ装置等からネットワークNWを介して取得されるようにしても良いし、DVDDigitalVersatileDisc等の記録媒体に記録されてドライブ装置を介して読み込まれるようにしても良い。入出力インターフェース13は、通信部11及び記憶部12とシステム制御部14との間のインターフェース処理を行うようになっている。システム制御部14は、CPU14a、ROMReadOnlyMemory14b、RAMRandomAccessMemory14c等により構成されている。そして、システム制御部14は、CPU14aが、各種プログラムを読み出し実行することにより、本発明における注文数取得手段、価格取得手段、出力手段、削除手段、設定情報取得手段及び制御手段として機能するようになっている。なお、共同購入サーバ1が、複数のサーバ装置で構成されても良い。例えば、商品情報を登録するサーバ装置、商品を検索するサーバ装置、商品の注文等の処理を行うサーバ装置、ユーザ端末3からのリクエストに応じてWebページを送信するサーバ装置、及びデータベースを管理するサーバ装置等が、互いにLAN等で接続されても良い。[1-3.共同購入システムの動作]次に、共同購入システムSの動作について、図7乃至図11を用いて説明する。図7は、本実施形態に係る共同購入サーバ1のシステム制御部14の商品情報登録時処理における処理例を示すフローチャートである。商品情報登録時処理においては、商品情報が登録された商品の検索用レコードが検索用DB12eに登録される。例えば、店舗の従業員が、新しく販売する商品の商品情報を登録するため、店舗端末2を操作する。すると、店舗端末2は、共同購入サーバ1にアクセスすることにより、商品情報を設定するためのWebページを表示する。従業員は、Webページに対して、必要注文数と適用価格との組み合わせを含む商品情報を設定する。すると、店舗端末2は、設定された商品情報を共同購入サーバ1に登録する。共同購入サーバ1は、受信した商品情報を商品情報DB12bに登録する。商品情報登録時処理は、商品情報が商品情報DB12bに登録されたときに開始される。先ず、システム制御部14は、登録された商品情報から検索用レコードの生成に必要な情報を取得するステップS1。ここで取得される情報としては、例えば、商品ID、店舗ID、ジャンルID、商品コード、商品名、商品説明等がある。また、システム制御部14は、店舗IDに対応する店舗名を取得する。また、システム制御部14は、登録された商品情報から最大注文数を取得する。次いで、システム制御部14は、登録された商品情報の注文数別価格リストから、必要注文数が最も少ない価格情報を取得するステップS2。次いで、システム制御部14は、開始価格に対して、取得した価格情報に含まれる適用価格を設定する。また、システム制御部14は、商品情報が登録された商品の現在注文数として0を、その商品の商品IDに対応付けて注文情報DB12cに登録するステップS3。次いで、システム制御部14は、取得した価格情報に対応する検索用レコード登録するステップS4。具体的に、システム制御部14は、検索用レコードを生成する。このとき、システム制御部14は、検索用レコードの商品IDとして、商品情報から取得した商品IDを設定する。また、システム制御部14は、検索用レコードの現在注文数として0を設定する。また、システム制御部14は、検索用レコードの残り必要注文数として、取得した価格情報に含まれる必要注文数を設定する。また、システム制御部14は、検索用レコードの適用価格として、取得した価格情報に含まれる価格情報を設定する。また、システム制御部14は、ステップS1において取得したその他の情報を設定する。システム制御部14は、こうして生成した検索用レコードを、検索用DB12eに登録する。次いで、システム制御部14は、登録された商品情報の注文数別価格リストから、まだ取得していない価格情報のうち、必要注文数が最も少ない価格情報を取得するステップS5。そして、システム制御部14は、取得した価格情報に対応する検索用レコード登録するステップS6。この場合の処理内容は、ステップS4の場合と同様である。ステップS5において取得される検索用レコードに含まれる適用価格は、販売開始時点の現在価格の次の適用価格である。検索結果ページの検索結果表示領域230に次価格残り必要注文数を表示するためには、ステップS5において取得される検索用レコードに含まれる残り必要注文数が必要となる。そのため、最低でも2個の検索用レコードが登録される。次いで、システム制御部14は、登録された商品情報の注文数別価格リストに、まだ取得していない価格情報があるか否かを判定するステップS7。このとき、システム制御部14は、全ての価格情報を取得したと判定した場合にはステップS7:NO、商品情報登録時処理を終了させる。一方、システム制御部14は、まだ取得していない価格情報があると判定した場合にはステップS7:YES、まだ取得していない価格情報のうち、必要注文数が最も少ない価格情報を選択するステップS8。次いで、システム制御部14は、選択した価格情報に含まれる必要注文数が最大注文数以下であるか否かを判定するステップS9。このとき、システム制御部14は、必要注文数が最大注文数以下である場合には、選択した価格情報を注文数別価格リストから取得し、この価格情報に対応する検索用レコード登録するステップS10。この場合の処理内容は、ステップS4の場合と同様である。システム制御部14は、この処理を終えると、ステップS7に移行する。一方、システム制御部14は、必要注文数が最大注文数以下ではないと判定した場合にはステップS9:NO、商品情報登録時処理を終了させる。こうして、システム制御部14は、検索用レコードを、必要な分だけ検索用DB12eに登録する。図8及び図9は、本実施形態に係る共同購入サーバ1のシステム制御部14の検索処理における処理例を示すフローチャートである。検索処理においては、ユーザ端末3からの要求に応じて商品の検索が行われ、検索結果ページのHTML文書がユーザ端末3へ送信される。電子商店街のトップページにおいてユーザが検索条件を指定すると、ユーザ端末3は、検索リクエストを共同購入サーバ1に送信する。検索リクエスト本発明におけるユーザの要求の一例は、ユーザからの商品の検索の要求を示すメッセージである。また、検索リクエストは、検索条件を示す情報を含む。具体的に、ユーザがキーワードを指定した場合、指定されたキーワードが設定される。また、ユーザがジャンルを指定した場合、指定されたジャンルのジャンルIDが設定される。また、検索リクエストは、検索結果ページに予定価格を表示させるか否かを示す予定価格表示フラグを含む。具体的に、予定価格表示チェックボックス130が、チェックが入れられている状態ではない場合、予定価格表示フラグがOFFに設定される。一方、予定価格表示チェックボックス130が、チェックが入れられている状態である場合、予定価格表示フラグがONに設定される。図8に示すように、システム制御部14は、ユーザ端末3から検索リクエストを受信するとステップS21、記憶部12から、検索結果ページのHTML文書のテンプレートを取得するステップS22。次いで、システム制御部14は、検索結果ページに予定価格を表示させるようにユーザから指示されたか否かを判定するステップS23。具体的に、システム制御部14は、予定価格表示フラグがOFFに設定されている場合、指示されていないと判定し、予定価格表示フラグがONに設定されている場合、指示されていると判定する。このとき、システム制御部14は、予定価格を表示させるように指示されていないと判定した場合にはステップS23:NO、通常の検索処理を行うステップS24。先ず、システム制御部14は、検索用DB12eから、検索条件を満たす商品の検索用レコードを検索する。具体的に、システム制御部14は、検索リクエストにキーワードが設定された場合、商品名及び商品説明の少なくとも一方に、このキーワードを含む検索用レコードを検索する。また、システム制御部14は、検索リクエストにジャンルIDが設定された場合、検索用レコードに含まれるジャンルIDに基づいて、指定されたジャンルに属する商品の検索用レコードを検索する。検索リクエストに検索条件を示す情報が複数設定されている場合、システム制御部14は、例えば、複数の検索条件を満たす検索用レコードを検索する。なお、ジャンルは階層構造になっていても良い。この場合、各商品にはその商品が属する最下層のジャンルだけを紐付けても良いし、最下層から最上層に遡る親子ジャンルの一部または全部を紐付けても良い。次いで、システム制御部14は、検索した検索用レコードに基づいて、該当商品情報231を表示するためのデータを商品ごとに生成する。このとき、システム制御部14は、検索用レコードに含まれる現在価格が表示されるようにデータを生成する。そして、システム制御部14は、生成したデータを、検索ページのHTML文書のテンプレートにおいて、検索結果表示領域230に対応する領域に追加設定する。ここで、システム制御部14は、検索用レコードに含まれる現在価格が低い順にデータを設定する。これにより、該当商品情報231が現在価格の低い順に表示されるようにする。システム制御部14は、この処理を終えると、ステップS58に移行する。ステップS23において、システム制御部14は、予定価格を表示させるように指示されていると判定した場合にはステップS23:YES、検索レコードリスト及び表示レコードを初期化するステップS25。検索レコードリストは、検索された商品の検索用レコードが登録されるリストである。表示レコードリストは、検索された商品の検索用レコードのうち、該当商品情報232を表示するために用いられる検索用レコードが登録されるリストである。次いで、システム制御部14は、検索用DB12eから、検索条件を満たす商品の検索用レコードを検索するステップS26。この場合の検索方法は、ステップS24の場合と同様である。そして、システム制御部14は、検索条件を満たす商品の検索用レコードを検索レコードリストに登録する。次いで、システム制御部14は、検索した商品のうち1つを選択するステップS27。具体的に、システム制御部14は、検索レコードリストに登録された検索用レコードのうち1つの検索用レコードに含まれる商品IDを、選択商品の商品IDとして取得する。次いで、システム制御部14は、検索レコードリストから、選択商品の商品IDを含む検索用レコードを全て抽出するステップS28。このとき、システム制御部14は、抽出した検索用レコードを検索レコードリストから削除する。次いで、システム制御部14は、注文数取得手段として、予定注文数推定処理を実行するステップS29。図10は、本実施形態に係る共同購入サーバ1のシステム制御部14の予定注文数推定処理における処理例を示すフローチャートである。先ず、システム制御部14は、抽出した選択商品の検索用レコードからジャンルIDを取得するステップS71。次いで、システム制御部14は、購入履歴DB12dから、検索リクエストを送信したユーザ端末3を利用するユーザのユーザIDと、検索用レコードから取得したジャンルIDを含む購入履歴を検索するステップS72。つまり、システム制御部14は、検索を要求したユーザが選択商品と同一のジャンルの商品を購入したときの購入履歴を検索する。システム制御部14は、ユーザが電子商店街にログインしている場合、検索を要求したユーザのユーザIDを取得することができる。例えば、システム制御部14は、ユーザによるログイン時に、ユーザ端末3からユーザIDを受信し、受信したユーザIDをクッキーとしてユーザ端末3に保存させている。そのため、ユーザがログインしている場合には、検索リクエストに、ユーザIDを含むクッキーが付加されている。そこで、システム制御部14は、検索クエリに付加されているクッキーからユーザIDを取得する。次いで、システム制御部14は、該当する購入履歴が検索されたか否かを判定するステップS73。このとき、システム制御部14は、該当する購入履歴が検索されたと判定した場合にはステップS73:YES、検索された購入履歴のうち、購入日時が最新の購入履歴を選択する。そして、システム制御部14は、選択した購入履歴に含まれる注文数を、予定注文数として設定する。つまり、システム制御部14は、選択商品と同一のジャンルの商品についての最新の注文数を予定注文数とする。なお、システム制御部14は、例えば、検索された各購入履歴に含まれる注文数の平均値を計算して、この平均値を予定注文数として設定しても良い。また、システム制御部14は、選択商品のジャンルIDではなく、選択商品の商品コードを含む購入履歴を検索しても良い。つまり、システム制御部14は、検索を要求したユーザによる選択商品と同一商品の購入履歴に基づいて、予定注文数を推定しても良い。システム制御部14は、この処理を終えると、予定注文数推定処理を終了させる。一方、システム制御部14は、該当する購入履歴が検索されなかったと判定した場合にはステップS73:NO、購入履歴DB12dから、検索用レコードから取得したジャンルIDを含む購入履歴を検索するステップS75。つまり、システム制御部14は、選択商品と同一のジャンルの商品が購入されたときの購入履歴を、購入したユーザが誰であるかを問わずに全ユーザについて検索する。次いで、システム制御部14は、検索された各購入履歴に含まれる注文数の平均値を計算して、この平均値を予定注文数として設定するステップS76。このとき、システム制御部14は、ユーザごとに購入日時が最新の購入履歴を選択し、選択された購入履歴に含まれる注文数のみを用いて平均値を計算しても良い。また、システム制御部14は、選択商品と同一のジャンルの商品の購入履歴ではなく、選択商品と同一商品の購入履歴に基づいて、予定注文数を推定しても良い。システム制御部14は、この処理を終えると、予定注文数推定処理を終了させる。なお、システム制御部14は、予定注文数推定処理において、ステップS71~S74のみを実行しても良いし、ステップS71、S75及びS76のみを実行しても良い。また、システム制御部14は、該当する購入履歴を検索することができなかった場合には、例えば、その選択商品については、予定価格ではなく現在価格が検索結果表示領域230に表示されるようにしても良い。システム制御部14は、予定注文数推定処理を終えると、図8に示すように、推定された予定注文数が選択商品の最大注文数以下であるか否かを判定するステップS30。このとき、システム制御部14は、予定注文数が最大注文数以下であると判定した場合にはステップS30:YES、表示予定注文数に予定注文数を設定するステップS31。表示予定注文数は、該当商品情報232に実際に表示される予定注文数であり、予定価格を特定するために用いられる予定注文数である。一方、システム制御部14は、予定注文数が最大注文数以下ではないと判定した場合にはステップS30:NO、表示予定注文数に最大注文数を設定するステップS32。システム制御部14は、ステップS30またはS31の処理を終えると、ステップS28において抽出した選択商品の検索用レコードのうち、格納されている残り必要注文数が最も多い検索用レコードを選択するステップS33。次いで、システム制御部14は、選択した検索用レコードに含まれる残り必要注文数が表示予定注文数以下であるか否かを判定するステップS34。このとき、システム制御部14は、残り必要注文数が表示予定注文数以下ではないと判定した場合にはステップS34:NO、選択商品の検索用レコードの中から、まだ選択していない検索用レコードのうち、格納されている残り必要注文数が最も多い検索用レコードを選択するステップS35。次いで、システム制御部14は、ステップS34に移行する。一方、システム制御部14は、残り必要注文数が表示予定注文数以下であると判定した場合にはステップS34:YES、選択した検索用レコードを表示レコードリストに登録するステップS36。つまり、システム制御部14は、表示予定注文数に対する適用価格を含む検索用レコードを登録する。こうして、システム制御部14は、価格取得手段として、現在注文数と表示予定注文数との和に相当する注文数に対応する適用価格を検索用DB12eから取得する。この適用価格が、予定価格として表示される。次いで、システム制御部14は、図9に示すように、検索した商品のうちまだ選択していない商品があるか否かを判定するステップS51。具体的に、システム制御部14は、検索レコードリストに検索用レコードがまだ登録されているか否かを判定する。システム制御部14は、検索用レコードがまだ登録されている場合には、まだ選択していない商品があると判定し、検索用レコードが登録されていない場合には、全ての商品を選択したと判定する。このとき、システム制御部14は、まだ選択していない商品があると判定した場合にはステップS51:YES、まだ選択していない商品のうち1つを選択するステップS52。具体的に、システム制御部14は、検索レコードリストに登録された検索用レコードのうち1つの検索用レコードに含まれる商品IDを、選択商品の商品IDとして取得する。次いで、システム制御部14は、ステップS28に移行する。システム制御部14は、ステップS28~S52の処理を繰り返すことにより、検索された各商品について、予定価格の表示に必要な検索用レコードを表示レコードリストに登録する。なお、システム制御部14は、予定注文数推定処理を、検索した商品ごとに実行しているが、例えば、検索した商品が属するジャンルごとに実行しても良い。そうすることで、同一ジャンルに属する商品が複数検索された場合に、予定注文数推定処理の実行回数を減らすことができる。ステップS51において、システム制御部14は、全ての商品を選択したと判定した場合にはステップS51:NO、表示レコードリストに登録されている検索用レコードのうち、格納されている適用価格が最も低い検索用レコードを1つ選択するステップS53。次いで、システム制御部14は、選択した検索用レコードに基づいて、該当商品情報232を表示するためのデータを、検索ページのHTML文書のテンプレートに追加するステップS54。具体的に、システム制御部14は、検索用レコードに含まれる商品名、店舗名及び適用価格と、表示予定注文数とを含むデータを生成する。このとき、システム制御部14は、適用価格を予定価格とする。そして、システム制御部14は、生成したデータを、検索ページのHTML文書のテンプレートにおいて、検索結果表示領域230に対応する領域に追加設定する。次いで、システム制御部14は、該当商品情報232を1ページあたりに表示可能な上限数まで、該当商品情報232のデータを追加したか否かを判定するステップS55。このとき、システム制御部14は、上限数まで追加していないと判定した場合にはステップS55:NO、表示レコードリストに登録されている検索用レコードのうち、まだ選択していない検索用レコードがあるか否かを判定するステップS56。このとき、システム制御部14は、まだ選択していない検索用レコードがあると判定した場合にはステップS56:YES、まだ選択していない検索用レコードのうち、格納されている適用価格が最も低い検索用レコードを1つ選択するステップS57。次いで、システム制御部14は、ステップS54に移行する。システム制御部14は、ステップS54~S57の処理を繰り返すことにより、検索された各商品の該当商品情報232が予定価格が低い順に表示されるようにHTML文書に対する設定を行う。システム制御部14は、ステップS24の処理を終えた場合、ステップS55において上限数まで追加したと判定した場合ステップS55:YES、または、ステップS56において全ての検索用レコードを選択したと判定した場合にはステップS56:NO、出力手段として、各データの設定により完成した検索結果ページのHTML文書を、検索リクエストの送信元のユーザ端末3へ送信するステップS58。システム制御部14は、この処理を終えると、検索処理を終了させる。図11は、本実施形態に係る共同購入サーバ1のシステム制御部14の注文時処理における処理例を示すフローチャートである。電子商店街の商品ページにおいて、ユーザが購入したい商品の数を注文数として入力し、注文するためのボタンを選択する。すると、ユーザ端末3は、商品の注文の要求を示す注文リクエストを共同購入サーバ1に送信する。注文リクエストは、注文対象の商品以下、注文商品というの商品IDと、入力された注文数とを含む。注文時処理は、共同購入サーバ1が注文リクエストを受信したときに開始される。先ず、システム制御部14は、注文商品の現在注文数を更新するステップS81。具体的に、システム制御部14は、注文情報DB12cに登録されている現在注文数のうち、注文商品の商品IDに対応する現在注文数を検索する。そして、システム制御部14は、検索した現在注文数に、検索リクエストに含まれる注文数を加算する。次いで、システム制御部14は、注文商品の現在価格を取得するステップS82。具体的に、システム制御部14は、注文商品の商品IDに対応付けて商品情報DB12bに登録されている注文数別価格リストから、更新後の現在注文数に対応する適用価格を、現在価格として取得する。現在注文数に対応する適用価格は、現在注文数以下の必要注文数を含む価格情報のうち、現在注文数に最も近い必要注文数を含む価格情報に含まれる適用価格である。次いで、システム制御部14は、注文履歴を記録するステップS83。具体的に、システム制御部14は、注文コード、注文日時、注文したユーザのユーザID、注文リクエストに含まれる注文数等を、注文商品の商品IDに対応付けて注文情報DB12cに登録する。次いで、システム制御部14は、検索用DB12eから、注文商品の商品IDを含む検索用レコードを検索するステップS84。次いで、システム制御部14は、検索した検索用レコードのうち、格納されている適用価格が最も高い検索用レコードを選択する。そして、システム制御部14は、選択した検索用レコードに含まれる適用価格を、登録済最高価格として設定するステップS85。次いで、システム制御部14は、検索した検索用レコードのうち1つを選択するステップS86。次いで、システム制御部14は、選択した検索用レコードに含まれる適用価格が現在価格以上であるか否かを判定するステップS87。このとき、システム制御部14は、適用価格が現在価格以上であると判定した場合にはステップS87:YES、選択した検索用レコードを更新するステップS88。具体的に、システム制御部14は、検索用レコードの現在注文数として、更新後の現在注文数を設定する。また、システム制御部14は、検索用レコードの現在価格として、現在注文数の更新後に対応する現在価格を設定する。また、システム制御部14は、検索用レコードの残り必要注文数から、検索リクエストに含まれる注文数を減算する。一方、システム制御部14は、適用価格が現在価格以上ではないと判定した場合にはステップS87:NO、選択した検索用レコードを検索用DB12eから削除するステップS89。システム制御部14は、ステップS88またはS89の処理を終えると、検索した検索用レコードのうちまだ選択していない検索用レコードがあるか否かを判定するステップS90。このとき、システム制御部14は、まだ選択していない検索用レコードがあると判定した場合にはステップS90:YES、まだ選択していない検索用レコードのうち1つを選択するステップS91。次いで、システム制御部14は、ステップS87に移行する。システム制御部14は、ステップS87~S91の処理を繰り返すことにより、削除手段として、増加後の現在注文数以上の範囲内にある注文数に対応しない検索用レコードを検索用DB12eから削除する。そして、システム制御部14は、全ての検索用レコードを選択したと判定した場合にはステップS90:NO、注文商品の注文数別価格リストに、登録済最高価格の次に低い適用価格を含む価格情報があるか否かを判定するステップS92。登録済最高価格の次に低い適用価格は、注文数別価格リストに登録されている複数の適用価格の中で、登録済最高価格より高い適用価格のうち、登録済最高価格に最も近い価格である。このとき、システム制御部14は、次に低い適用価格を含む価格情報がないと判定した場合にはステップS92:NO、注文時処理を終了させる。この場合は、注文商品の最終価格を含む検索用レコードが既に検索用DB12eに登録されている場合である。一方、システム制御部14は、次に低い適用価格を含む価格情報があると判定した場合にはステップS92:YES、登録済最高価格の次に低い適用価格を含む価格情報を選択するステップS93。次いで、システム制御部14は、選択した価格情報に含まれる適用価格が更新後の現在価格以上であるか否かを判定するステップS94。このとき、システム制御部14は、適用価格が現在価格以上であると判定した場合にはステップS94:YES、選択した価格情報に含まれる必要注文数が、注文商品の現在注文数と最大注文数との和以下であるか否かを判定するステップS95。このとき、システム制御部14は、必要注文数が現在注文数と最大注文数との和以下であると判定した場合にはステップS95:YES、設定情報取得手段として、選択した価格情報を商品情報DB12bから取得するステップS96。次いで、システム制御部14は、制御手段として、取得した価格情報に対応する検索用レコード登録するステップS97。具体的に、システム制御部14は、検索用レコードを生成する。このとき、システム制御部14は、検索用レコードの商品IDとして、注文商品の商品IDを設定する。また、システム制御部14は、検索用レコードの現在注文数として、更新後の現在注文数を設定する。また、システム制御部14は、検索用レコードの現在価格として、更新後の現在注文数に対応する現在価格を設定する。また、システム制御部14は、検索用レコードの残り必要注文数として、取得した価格情報に含まれる必要注文数と更新後の現在注文数との差を設定する。また、システム制御部14は、検索用レコードの適用価格として、取得した価格情報に含まれる価格情報を設定する。また、システム制御部14は、その他の情報を設定する。システム制御部14は、こうして生成した検索用レコードを、検索用DB12eに登録する。システム制御部14は、ステップS94において適用価格が現在価格以上ではないと判定した場合ステップS94:NO、または、ステップS97の処理を終えた場合には、注文商品の注文数別価格リストに、選択した価格情報に含まれる適用価格の次に低い適用価格を含む価格情報があるか否かを判定するステップS98。このとき、システム制御部14は、次に低い適用価格を含む価格情報があると判定した場合にはステップS98:YES、選択した価格情報に含まれる適用価格の次に低い適用価格を含む価格情報を選択するステップS99。次いで、システム制御部14は、ステップS94に移行する。システム制御部14は、ステップS94~S99の処理を繰り返すことにより、商品情報DB12bに登録されている注文商品の注文数別価格リストから、更新後の現在注文数と最大注文数との和に相当する注文数以下の範囲内にある注文数に対応する適用価格を含む価格情報を取得し、取得した価格情報に応じた検索用レコードを検索用DB12eに登録する。そして、システム制御部14は、ステップS95において必要注文数が現在注文数と最大注文数との和以下ではないと判定した場合ステップS95:NO、または、ステップS98において次に低い適用価格を含む価格情報がないと判定した場合にはステップS98:NO、注文時処理を終了させる。以上説明したように、本実施形態によれば、共同購入サーバ1のシステム制御部14は、検索リクエストに基づいて検索された商品についての予定注文数を取得し、予定注文数と検索された商品の現在注文数との和に相当する注文数での販売が決定された場合の適用価格を、検索用DB12eに登録された検索用レコードから取得し、取得された適用価格を予定価格として表示する検索結果ページのHTML文書を送信する。従って、ユーザは自分が商品を注文するとした場合に注文が予定される数分増加した合計注文数に応じた価格を知ることができる。また、システム制御部14が、購入履歴DB12dに登録された購入履歴に基づいて、予定注文数を推定する。従って、ユーザは自分が商品を注文するとした場合に注文が予想される数分増加した合計注文数に応じた商品の価格を知ることができる。また、システム制御部14が、商品の注文によって現在注文数が更新された場合、検索用DB12eに登録された注文商品の検索用レコードのうち、更新後の現在注文数以上の範囲内にある注文数に対応しない検索用レコードを削除する。従って、検索用DB12eのデータ量を削減することができる。また、システム制御部14が、商品情報DB12bに登録された注文数別価格リストに登録されている価格情報のうち、注文数別価格リストに対応する商品IDに対応する商品の現在注文数と最大注文数との和に相当する注文数以下の範囲内にある注文数に対応する価格情報を取得し、取得された価格情報に応じた検索用レコードを検索用DB12eに登録する。従って、検索用DB12eの内容を注文数別価格リストの内容に同期させるための処理負荷を低減させることができる。また、検索用DB12eのデータ量を削減することができる。なお、図11に示すフロー図では、適用価格が現在価格未満の検索用レコードを1レコードずつ検索用DB12eから削除する例を示したが、検索用レコードを一括して削除した後に適用価格が現在価格以上であるレコードを一括して追加するよう構成しても良い。[2.第2実施形態]上記第1実施形態においては、共同購入サーバ1が購入履歴に基づいて予定注文数が推定されていた。これに対し、以下に説明する第2実施形態においては、ユーザが、商品を注文すると仮定した場合に希望する注文数を指定し、共同購入サーバ1が、指定された注文数を予定注文数としてユーザ端末3から取得する。以下では、第1実施形態と異なる点を主として説明する。図12は、本実施形態におけるトップページの表示例を示す図である。図12において、図2と同様の要素については、同様の符号を付してある。図12に示すように、トップページは、検索条件設定領域110、ジャンル指定領域120、注文数入力欄140等を含む。注文数入力欄140は、希望する注文数を入力するための入力領域である。注文数入力欄140に対してユーザが注文数を入力せずに、検索条件のみを指定すると、検索結果ページとして、図3aに示すような検索結果ページが表示される。一方、注文数入力欄140に対してユーザが注文数を入力して、検索条件を指定すると、検索結果ページとして、図3bに示すような検索結果ページが表示される。この場合、検索された商品のジャンルの如何に関わらず、その商品の現在注文数とユーザが入力した注文数との和に対応する適用価格が予定価格として表示される。ただし、ユーザが入力した注文数が最大注文数を超える商品については、現在注文数と最大注文数との和に対応する適用価格が予定価格として表示される。ユーザが注文数を入力した場合、ユーザ端末3から送信される検索リクエストには、入力された注文数が、予定注文数として設定される。図8に示す検索処理のステップS23において、システム制御部14は、検索結果ページに予定価格を表示させるようにユーザから指示されたか否かを判定する代わりに、検索リクエストに予定注文数が設定されているか否かを判定する。このとき、システム制御部14は、予定注文数が設定されていないと判定した場合には、ステップS24に移行し、検索された商品の現在価格を表示させるための処理を行う。一方、システム制御部14は、予定注文数が設定されていると判定した場合には、ステップS26に移行し、検索された商品の予定価格を表示させるための処理を行う。ここで、システム制御部14は、ステップS29の予定注文数推定処理を実行せずに、ステップS30においては、検索リクエストに設定された予定注文数を用いて判定を行う。以上説明したように、本実施形態によれば、ユーザは自分が希望する数で商品を注文するとした場合に希望する数分増加した合計注文数に応じた商品の価格を知ることができる。なお、システム制御部14は、図7に示す商品情報登録時処理のステップS9、及び、図11に示す注文時処理のステップS95において、検索用レコードを検索用DB12eに登録する必要があるか否かを判定するための閾値として、商品の最大注文数を用いていた。しかしながら、この閾値として、最大注文数以外の情報を用いても良い。また、図8に示す検索処理のステップS30において予定注文数と比較する閾値として、最大注文数以外の情報を用いても良い。例えば、システム制御部14は、商品ごとに店舗により設定した閾値を用いても良い。また、購入履歴に基づいて閾値を設定しても良い。具体的に、システム制御部14は、購入履歴DB12dから、閾値を決定する商品とジャンルが同一の商品または商品コードが同一の商品の購入履歴を検索する。そして、システム制御部14は、検索した購入履歴に含まれる注文数に基づいて、閾値を決定する。このとき、システム制御部14は、過去の注文のうちある割合以上の注文における注文数が閾値以下となるように、閾値を決定する。具体的に、検索した各購入履歴における注文数のうち、Nパーセンタイルに対応する注文数を閾値とする。つまり、注文数が閾値以下である注文の割合がN、注文数が閾値よりも大きい注文の割合が100-Nとなるように、閾値を決定する。Nは、予め設定された値である。例えば、大部分の注文数が閾値以下となるように、50を超える範囲内でNを設定すると良い。また、上記各実施形態においては、検索用レコードに、現在注文数及び現在価格が設定されるようになっていた。しかしながら、検索結果ページに現在注文数及び現在価格を表示する必要がない場合図3aに示す検索結果ページを表示させなくても良い場合には、現在注文数及び現在価格は設定されなくても良い。また、上記各実施形態においては、検索用レコードに、残り必要注文数が設定されていた。しかしながら、同じ検索用レコードに含まれる適用価格が予定価格であるか否かの判定可能な情報であれば、残り必要注文数の代わりに別の情報が検索用レコードに設定されても良い。例えば、適用価格に対応する残りの注文数の範囲が検索用レコードに設定されても良い。例えば、図6cの例では、適用価格が9000円である検索用レコードには、残りの注文数の範囲として0~60が設定される。また、図6dの例では、適用価格が9000円である検索用レコードには、残りの注文数の範囲として0~40が設定され、適用価格が8000円である検索用レコードには、41~が設定される。また、例えば、必要注文数が検索用レコードに設定されても良い。この場合、現在注文数、予定注文数、及び検索用レコードに含まれる必要注文数に基づいて、その検索用レコードに含まれる適用価格が予定価格であるか否かを判定することができる。この場合の現在注文数は、検索用レコードに設定されて、検索用レコードから取得されるようにしても良いし、商品情報DB12bから取得されるようにしても良い。また、適用価格に対応する注文数の範囲が検索用レコードに設定されても良い。例えば、図6bの例では、適用価格が10000円である検索用レコードには、注文数の範囲として1~1が設定され、適用価格が9500円である検索用レコードには、注文数の範囲として2~10が設定され、適用価格が9000円である検索用レコードには、注文数の範囲として11~100が設定される。注文数の範囲は、現在注文数が増加しても変化しない。また、注文数別価格リストの価格情報には、必要注文数の代わりに、適用価格に対応する注文数の範囲が設定されても良い。また、上記実施形態においては、ユーザから指定された検索条件に基づく商品の検索結果として、検索された商品を表示する場合の価格の表示に本発明を適用していたが、本発明を適用可能な態様は検索結果の表示に限られるものではない。例えば、商品ページに商品の情報を表示する場合の価格の表示に本発明を適用しても良い。