WO2013038744A1 - 情報提供装置、情報提供方法、情報提供プログラム及び記録媒体 - Google Patents

Abstract

　商品の情報の提供を受けるユーザがその商品を注文したと仮定した場合に適用される価格を提供する。情報提供装置は、ユーザの要求に応じて特定された商品について該ユーザが注文を予定する数を取得し、取得された数と特定された商品のこれまでに注文された数との和に相当する注文数での販売が決定された場合の該商品の価格を、商品の価格と注文数との組み合わせから取得し、取得された価格を出力する。

Description

情報提供装置、情報提供方法、情報提供プログラム及び記録媒体

　本発明は、これまでの注文数に応じて価格が変化する商品の価格を提供する情報提供装置及び情報提供方法の技術分野に関する。

　従来、電子商取引における商品の取引形態として、これまでに受け付けられた商品の注文の合計数（以下、「合計注文数」という）に応じて、その商品の単価が段階的に安くなる形態が知られている。この販売形態は、例えば、共同購入として知られている。この形態で取引される商品の情報を提供する情報提供装置は、商品の情報として、その商品の現在の注文数に対して適用される価格等を提供する。例えば、特許文献１には、商品の現在の注文数と、現在の注文数に対して適用される価格とをユーザの端末に表示させる技術が開示されている。ユーザは、商品の情報を閲覧することによりその商品を購入したいと望むと、その商品を注文するための操作を行う。このとき、ユーザは、注文する商品の数を指定することができる。

特開２００１－３５７２７６号公報

　ユーザが商品を注文した場合、注文した商品の数分合計注文数が増加することになる。この場合、ユーザによる商品の購入価格は、そのユーザが注文した分増加した後の合計注文数に対して適用される価格である。そのため、ユーザが注文した商品の数に応じて、購入価格の最高値が変化することがある。従って、現時点の合計注文数に適用される価格が表示されるよりも、ユーザ自身が商品を注文したと仮定した場合の増加後の合計注文数に適用される価格が表示される方が、ユーザにとって好ましい場合がある。例えば、ユーザが商品を注文するか否か等を判断する場合、現時点での価格よりも、ユーザ自身が商品を注文したと仮定した場合に適用される価格の方が、判断材料としては適しているからである。

　しかしながら、従来の技術では、現在の注文数に適用される価格が表示されるだけであった。特許文献１に記載の技術では、商品の価格とその価格が適用される注文数の範囲の一覧が表示されるが、この一覧からでは、自分が注文した場合に適用される価格をユーザが即座に把握することができない。

　本発明は、以上の点に鑑みてなされたものであり、商品の情報の提供を受けるユーザがその商品を注文したと仮定した場合に適用される価格を提供することができる情報提供装置、情報提供方法、情報提供プログラム及び記録媒体を提供することを目的とする。

　上記課題を解決するために、請求項１に記載の発明は、ユーザの要求に応じて特定された商品について該ユーザが注文を予定する数を取得する注文数取得手段と、前記注文数取得手段により取得された数と前記特定された商品のこれまでに注文された数との和に相当する注文数での販売が決定された場合の該商品の価格を、商品の価格と注文数との組み合わせを示す組み合わせ情報を商品ごとに記憶する記憶手段から取得する価格取得手段と、前記価格取得手段により取得された価格を、前記特定された商品に関連付けて出力する出力手段と、を備えることを特徴とする。

　この発明によれば、ユーザは自分が商品を注文するとした場合に注文が予定される数分増加した注文数に応じた商品の価格を知ることができる。

　請求項２に記載の発明は、請求項１に記載の情報提供装置において、前記注文数取得手段は、注文された商品の数を含む注文ごとの購入履歴を記憶する履歴記憶手段に記憶された前記購入履歴に基づいて、前記ユーザが注文を予定する数を推定することを特徴とする。

　この発明によれば、ユーザは自分が商品を注文するとした場合に、過去の履歴に基づいて注文が予想される数分増加した注文数に応じた商品の価格を知ることができる。

　請求項３に記載の発明は、請求項１に記載の情報提供装置において、前記ユーザの要求は、該ユーザが注文を希望する数を含み、前記注文数取得手段は、前記ユーザの要求に含まれる数を、該ユーザが注文を予定する数として取得することを特徴とする。

　この発明によれば、ユーザは自分が希望する数で商品を注文するとした場合に希望する数分増加した注文数に応じた商品の価格を知ることができる。

　請求項４に記載の発明は、請求項１乃至３の何れか１項に記載の情報提供装置において、前記記憶手段には、各商品について、該商品の価格と該価格に対応する注文数とを示す前記組み合わせ情報対応情報が価格ごとに記憶され、商品のこれまでの注文数が増加した場合、前記記憶手段に記憶された該商品の前記組み合わせ情報のうち、増加後の注文数以上の範囲内にある注文数に対応しない前記組み合わせ情報対応情報を、前記記憶手段から削除する削除手段を更に備えることを特徴とする。

　この発明によれば、価格を出力するためには不要となった情報は記憶手段から削除されるため、記憶手段に記憶される情報の量を削減することができる。

　請求項５に記載の発明は、請求項１乃至４の何れか１項に記載の情報提供装置において、商品の販売者により設定された設定情報であり、商品の価格と該価格が適用される注文数とを示す設定情報を商品を識別する識別情報に関連付けて複数記憶する設定情報記憶手段に記憶された前記設定情報のうち、該設定情報に関連付けられた前記識別情報により識別される商品のこれまでに注文された数と予め設定された数との和に相当する注文数以下の範囲内にある注文数に対応する前記設定情報を取得する設定情報取得手段と、前記設定情報取得手段により取得された前記設定情報に応じた前記組み合わせ情報を前記記憶手段に記憶させる制御手段と、を更に備えることを特徴とする。

　この発明によれば、価格の出力に用いられる記憶手段を、販売者が設定した情報を記憶する設定情報記憶手段とは別に設けている場合に、設定情報記憶手段に記憶されている情報のうち、価格の出力に当面必要な情報のみを記憶手段に記憶させることができる。そのため、記憶手段の情報を設定情報記憶手段の情報に同期させるための処理負荷を低減させることができる。

　請求項６に記載の発明は、コンピュータにより実行される情報提供方法であって、ユーザの要求に応じて特定された商品について該ユーザが注文を予定する数を取得する注文数取得ステップと、前記注文数取得ステップにおいて取得された数と前記特定された商品のこれまでに注文された数との和に相当する注文数での販売が決定された場合の該商品の価格を、商品の価格と注文数との組み合わせを示す組み合わせ情報を商品ごとに記憶する記憶手段から取得する価格取得ステップと、前記価格取得ステップにおいて取得された価格を、前記特定された商品に関連付けて出力する出力ステップと、を含むことを特徴とする。

　請求項７に記載の発明は、コンピュータを、ユーザの要求に応じて特定された商品について該ユーザが注文を予定する数を取得する注文数取得手段、前記注文数取得手段により取得された数と前記特定された商品のこれまでに注文された数との和に相当する注文数での販売が決定された場合の該商品の価格を、商品の価格と注文数との組み合わせを示す組み合わせ情報を商品ごとに記憶する記憶手段から取得する価格取得手段、及び、前記価格取得手段により取得された価格を、前記特定された商品に関連付けて出力する出力手段、として機能させることを特徴とする。

　請求項８に記載の発明は、コンピュータを、ユーザの要求に応じて特定された商品について該ユーザが注文を予定する数を取得する注文数取得手段、前記注文数取得手段により取得された数と前記特定された商品のこれまでに注文された数との和に相当する注文数での販売が決定された場合の該商品の価格を、商品の価格と注文数との組み合わせを示す組み合わせ情報を商品ごとに記憶する記憶手段から取得する価格取得手段、及び、前記価格取得手段により取得された価格を、前記特定された商品に関連付けて出力する出力手段、として機能させる情報提供プログラムがコンピュータ読み取り可能に記録されていることを特徴とする。

　本発明によれば、ユーザは自分が商品を注文するとした場合に注文が予定される数分増加した注文数に応じた商品の価格を知ることができる。

一実施形態に係る共同購入システムＳの概要構成の一例を示す図である。 電子商店街のトップページの表示例を示す図である。 （ａ）及び図３（ｂ）は、検索結果ページの表示例である。 一実施形態に係る共同購入サーバ１の概要構成の一例を示すブロック図である。 （ａ）は、会員情報ＤＢ１２ａに登録される内容の一例を示す図であり、（ｂ）は、商品情報ＤＢ１２ｂに登録される内容の一例を示す図であり、（ｃ）は、注文情報ＤＢ１２ｃに登録される内容の一例を示す図であり、（ｄ）は、購入履歴ＤＢ１２ｄに登録される内容の一例を示す図であり、（ｅ）は、検索用ＤＢ１２ｅに登録される内容の一例を示す図である。 （ａ）は、注文数別価格リストに登録される内容の一例を示す図であり、（ｂ）乃至（ｄ）は、検索用ＤＢ１２ｅに登録される検索用レコードの内容の一例を示す図である。 一実施形態に係る共同購入サーバ１のシステム制御部１４の商品情報登録時処理における処理例を示すフローチャートである。 一実施形態に係る共同購入サーバ１のシステム制御部１４の検索処理における処理例を示すフローチャートである。 一実施形態に係る共同購入サーバ１のシステム制御部１４の検索処理における処理例を示すフローチャートである。 一実施形態に係る共同購入サーバ１のシステム制御部１４の予定注文数推定処理における処理例を示すフローチャートである。 一実施形態に係る共同購入サーバ１のシステム制御部１４の注文時処理における処理例を示すフローチャートである。 トップページの表示例を示す図である。

　以下、図面を参照して本発明の実施形態について詳細に説明する。なお、以下に説明する実施の形態は、共同購入システムに対して本発明を適用した場合の実施形態である。

　［１．第１実施形態］
　［１－１．共同購入システムの構成及び機能概要］
　先ず、本実施形態に係る共同購入システムＳの構成及び機能概要について、図１乃至図３を用いて説明する。図１は、本実施形態に係る共同購入システムＳの概要構成の一例を示す図である。

　図１に示すように、共同購入システムＳは、共同購入サーバ１と、複数の店舗端末２と、複数のユーザ端末３と、を含んで構成されている。共同購入サーバ１と、各店舗端末２及び各ユーザ端末３とは、ネットワークＮＷを介して、例えば、通信プロトコルにＴＣＰ／ＩＰ等を用いて相互にデータの送受信が可能になっている。なお、ネットワークＮＷは、例えば、インターネット、専用通信回線（例えば、ＣＡＴＶ（Community Antenna Television）回線）、移動体通信網（基地局等を含む）、及びゲートウェイ等により構築されている。

　共同購入サーバ１（本発明における情報提供装置の一例）は、商品の共同購入が可能な電子商店街に関する各種処理を実行するサーバ装置である。共同購入は、例えば、販売期間が設定された取引形態であり、この販売期間内における商品の注文数が多いほど、注文数に応じてその商品の購入価格が段階的に安くなる取引形態である。電子商店街においては、商品の販売者側として複数の店舗が出店している。ユーザは、電子商店街を利用することにより、所望の店舗から所望の商品を購入することができる。共同購入サーバ１は、ユーザ端末３からのリクエストに応じて、例えば、電子商店街のＷｅｂページを送信したり、商品の検索や購入等に関する処理を行ったりする。

　店舗端末２は、電子商店街に出店している店舗の従業員等により利用される端末装置である。店舗端末２は、例えば、販売する商品の情報を電子商店街に登録等するために用いられる。店舗端末２は、従業員等からの操作に基づいて共同購入サーバ１にアクセスする。これにより、店舗端末２は、サーバ装置からＷｅｂページを受信して表示する。店舗端末２には、ブラウザや電子メールクライアント等のソフトウェアが組み込まれている。店舗端末２としては、例えば、パーソナルコンピュータ等が用いられる。

　ユーザ端末３は、電子商店街を利用して商品を購入するユーザの端末装置である。ユーザ端末３は、ユーザからの操作に基づいて共同購入サーバ１にアクセスする。これにより、ユーザ端末３は、サーバ装置からＷｅｂページを受信して表示する。ユーザ端末３には、ブラウザや電子メールクライアント等のソフトウェアが組み込まれている。ユーザ端末３としては、例えば、パーソナルコンピュータ、ＰＤＡ（Personal Digital Assistant）、スマートフォン等の携帯情報端末、携帯電話機等が用いられる。

　このような構成の共同購入システムＳにおいて、共同購入サーバ１は、ユーザから指定された検索条件に基づいて、共同購入可能な商品を検索する。そして、共同購入サーバ１は、検索した商品の情報をユーザ端末３へ提供する。具体的に、共同購入サーバ１は、検索結果ページのＨＴＭＬ（HyperText Markup Language）文書をユーザ端末３へ送信する。検索結果ページは、商品の検索結果として、検索された商品の情報が、その商品に関連付けて一覧表示されるＷｅｂページである。表示される商品の情報としては、例えば、商品の価格がある。検索結果ページのＨＴＭＬ文書を送信することは、検索された商品の価格を、その商品に関連付けて出力することの一例である。

　商品の価格は、その商品がこれまでに注文された数の合計に応じて変化する。ある商品がこれまでに注文された数の合計を、「合計注文数」という。一例として、合計注文数が１個である場合は３０００円、合計注文数が２個以上１０個以下である場合は２０００円、合計注文数が１１個以上である場合は１０００円、というように商品の単価が設定される。それぞれの合計注文数の範囲に対して適用される単価を、「適用価格」という。適用価格は、商品の注文が締め切られた時点における最終的な合計注文数が、その適用価格に対応する合計注文数の範囲内である場合の販売価格である。また、ある適用価格が適用されるために最低限必要な合計注文数を、「必要注文数」という。上述した例では、３０００円、２０００円、１０００円それぞれの価格に対する必要注文数は、１個、２個、１１個である。必要注文数と適用価格との組み合わせは、商品を販売する店舗により設定される。現時点での合計注文数を、「現在注文数」という。また、現在注文数に対する適用価格を、「現在価格」という。また、合計注文数が１個である場合の適用価格を、「開始価格」という。また、設定された必要注文数のうち、最も大きい必要注文数に対する適用価格を、「最終価格」という。開始価格は、設定された適用価格のうち、最も高い価格である。最終価格は、設定された適用価格のうち、最も低い価格である。

　検索結果ページにおいては、共同購入可能な商品の価格の表示態様として、２通りの態様がある。第１の態様は、現在価格を表示する態様である。第２の態様は、検索結果ページを閲覧するユーザ自身が、検索結果ページに情報が表示された商品を、そのユーザが予定する注文数で注文したと仮定した場合に適用される価格を表示する態様である。具体的に、検索結果ページを閲覧するユーザが商品を購入したと仮定した場合、その商品の合計注文数が、そのユーザが注文した数分増加することになる。そこで、増加後の合計注文数に対して適用される価格を表示するのである。この価格を、「予定価格」という。ユーザは、自分が注文をした場合に、例えば、どれだけの価格になるのか、最低限どれだけ価格が安くなるのか等を知りたい場合がある。現在価格と予定価格とが異なる場合、予定価格の方が、商品を注文するか否か等を判断するための判断材料となるからである。

　検索結果ページを閲覧するユーザが商品を購入したと仮定した場合に、ユーザが注文する数を、「予定注文数」という。予定価格（本発明におけるユーザが注文を予定する数の一例）は、現在注文数と予定注文数との和に相当する注文数が最終的な合計注文数となり、その注文数での販売が決定された場合の商品の販売価格である。「予定価格」を表示するためには、ユーザが商品を注文を予定する数である予定注文数を取得する必要がある。本実施形態では、共同購入サーバ１が、ユーザのこれまでの商品の購入の履歴に基づいて、予定注文数を推定する。具体的には、過去にユーザが商品を注文したときにユーザが指定した注文数に基づいて、予定注文数が推定される。これは、過去の注文数と同様の注文数で未来においても商品が注文される傾向があると考えられるからである。予定注文数は、例えば、商品のジャンルごとに推定される。なお、各商品には、最大注文数が設定されている。最大注文数は、１回の注文で商品を注文可能な数の最大値である。最大注文数は、予定価格を表示する予定注文数の閾値として用いられる。具体的に、予定注文数が最大注文数を上回る場合、合計注文数が最大注文数分増加した場合の適用価格が予定価格として表示される。

　以下では、価格の表示態様の指定方法と、価格の表示例を説明する。図２は、電子商店街のトップページの表示例を示す図である。トップページは、電子商店街において最上位に位置するＷｅｂページであり、また、検索条件を指定するためのＷｅｂページである。

　図２に示すように、トップページは、検索条件設定領域１１０、ジャンル指定領域１２０、予定価格表示チェックボックス１３０等を含む。検索条件設定領域１１０は、キーワード入力欄１１１、ジャンル選択メニュー１１２、検索ボタン１１３等を含む。キーワード入力欄１１１は、キーワードを検索条件として入力するための入力領域である。ジャンル選択メニュー１１２は、商品のジャンルを検索条件として指定するジャンルを選択するためのプルダウンメニューである。検索ボタン１１３は、検索条件設定領域１１０において設定された検索条件で、共同購入サーバ１により商品を検索させるためのボタンである。ジャンル指定領域１２０には、それぞれジャンルに対応した複数のリンクが表示される。各リンクは、対応するジャンルを検索条件として共同購入サーバ１により商品を検索させるためのリンクである。予定価格表示チェックボックス１３０は、検索結果ページに予定価格を表示させるか否かを選択するためのチェックボックスである。なお、キーワードやジャンル以外の条件を検索条件として指定可能となっていても良い。

　トップページにおいて、ユーザが検索ボタン１１３を選択しまたはジャンル選択メニュー１１２から何れかのリンクを選択すると、共同購入サーバ１が商品の検索を行う。そして、その検索結果を示す検索結果ページが、ユーザ端末３の画面に表示される。

　図３（ａ）及び図３（ｂ）は、検索結果ページの表示例である。なお、図３（ａ）及び図３（ｂ）は、「ミネラルウォーター」というキーワードが検索条件として指定された場合の表示例である。また、図３（ａ）及び図３（ｂ）において、互いに同一の要素については同様の符号を付してある。トップページにおいて、ユーザが予定価格表示チェックボックス１３０に対してチェックを入れる操作をしなかった場合、図３（ａ）に示すような検索結果ページが表示される。

　図３（ａ）に示すように、検索結果ページは、検索条件設定領域２１０、ジャンル指定領域２２０、検索結果表示領域２３０等を含む。検索条件設定領域２１０は、キーワード等、新たな検索条件を設定するための領域である。ジャンル指定領域２２０には、ジャンルを検索条件として設定するためのリンクが表示される。ジャンル指定領域２２０では、検索された商品が属するジャンルに対応するリンクのみが表示される。ユーザは、検索条件設定領域２１０やジャンル指定領域２２０に対する操作を行うことで、新たな検索条件で共同購入サーバ１により商品を検索させることができる。

　検索結果表示領域２３０には、検索された商品の情報が一覧表示される。具体的に、検索結果表示領域２３０には、該当商品情報２３１が商品ごとに表示される。該当商品情報２３１は、例えば、現在価格が低い商品の順に表示される。該当商品情報２３１は、商品名、店舗名、現在価格、現在注文数、割引率及び次価格残り必要注文数を含む。商品名は、検索された商品の名称である。この商品名は、商品ページへのリンクになっている。商品ページは、選択された商品名が示す商品の詳細な情報が表示されるＷｅｂページである。商品ページにおいてユーザが注文操作を行うことにより、その商品ページに情報が掲載されている商品を注文することができる。店舗名は、商品の販売元の店舗の名称である。現在注文数は現時点での合計注文数である。なお、現在注文数が０個である場合、現在価格として、便宜上、開始価格が表示される。次価格残り必要注文数は、商品の価格が現在価格から次の適用価格に変化するまでに必要な残りの注文数である。次の適用価格とは、商品に対して設定された複数の適用価格のうち、現在価格の次に高い価格である。現在注文数に次価格残り必要注文数を加算すると、次の適用価格の必要注文数になる。割引率は、開始価格から現在価格までに割り引かれた分の価格の開始価格に対する割合である。

　図３（ａ）に示す検索結果表示領域２３０には、例えば、商品Ａ、Ｂ、Ｃ、Ｄ、Ｅの順に該当商品情報２３１が表示されているとする。商品Ａの現在価格、現在注文数及び次価格残り必要注文数は、１７００円、５３個及び４８個である。このときの現在注文数及び次価格残り必要注文数は、例えば、飲料をケース売りした場合のケースの数であっても良いし、飲料をばら売りした場合の飲料の本数であっても良い。商品Ｂの現在価格及び現在注文数は、１８００円及び１６個である。なお、１８００円は、商品Ｂの最終価格である。商品Ｃの現在価格、現在注文数及び次価格残り必要注文数は、２０００円、０個及び１個である。商品Ｄの現在価格、現在注文数及び次価格残り必要注文数は、２３００円、１３個及び３個である。商品Ｅの現在価格、現在注文数及び次価格残り必要注文数は、２５００円、２個及び９個である。なお、商品Ａ～Ｄは、水・ミネラルウォーターのジャンルに属する商品である。また、商品Ｅは、ソフトドリンクに属する商品である。検索条件の指定内容によっては、複数のジャンルの商品が検索される場合がある。

　トップページにおいて、ユーザが予定価格表示チェックボックス１３０に対してチェックを入れる操作をした場合、図３（ｂ）に示すような検索結果ページが表示される。

　図３（ｂ）に示す検索結果ページの検索結果表示領域２３０には、該当商品情報２３２が商品ごとに表示される。該当商品情報２３２は、例えば、予定価格が低い商品の順に表示される。該当商品情報２３２は、商品名、店舗名、予定価格、予定注文数及び割引率を含む。割引率は、開始価格から予定価格までに割り引かれた分の価格の開始価格に対する割合である。

　ここで、水・ミネラルウォーターのジャンルに属する商品の予定注文数は５個と推定され、ソフトドリンクに属する商品の予定注文数は８個と推定されたとする。そのため、商品Ａ、Ｂ及びＣについては、合計注文数が現在注文数から５個増加した場合の適用価格が予定価格として表示され、商品Ｅについては、合計注文数が現在注文数から８個増加した場合の適用価格が予定価格として表示されている。商品Ｄについては、合計注文数が現在注文数から３個増加した場合の適用価格が予定価格として表示されている。その理由は、商品Ｄの最大注文数が３個であるからである。商品Ａ、Ｂ及びＥについては、予定注文数が次価格の残り必要注文数未満であるため、予定価格が現在価格から変化していない。その一方で、商品Ｃ及びＤについては、予定注文数が次価格の残り必要注文数以上であるため、予定価格が現在価格から変化している。具体的に、商品Ｃの予定価格は１６００円であり、商品Ｄの予定価格は２０００円である。その結果、該当商品情報２３２は、商品Ｃ、Ａ、Ｂ、Ｄ、Ｅの順に表示されている。このように、検索された商品情報を予定価格が低い順に表示させることができる。ここで、商品Ｃの予定価格は、例えば、２段階変化している。例えば、必要注文数が２個に対する適用価格が１８００円、必要注文数が５個に対する適用価格が１６００円である。このように、予定注文数によっては価格が複数段階変化する場合であっても、その価格を表示することができる。

　なお、該当商品情報２３２の表示順は、価格の低い順に限られるものではない。例えば、価格の高い順、価格の割引率が高い順、注文数が多い順、注文の締め切り日時が近い順等に表示させることもできる。また、例えば、検索結果ページにおいて、ユーザが表示順を指定することを可能とし、指定された表示順で該当商品情報２３２を並べ替えた検索結果ページが再表示されるようにしても良い。

　また、検索条件設定領域２１０に、予定価格表示チェックボックス１３０が表示されるようにしても良い。そして、予定価格表示チェックボックス１３０に対してユーザが選択操作を行った瞬間に、検索結果表示領域２３０における該当商品情報２３１の表示と該当商品情報２３２の表示との切り替えが行われるようにしても良い。つまり、ユーザ端末３が検索結果ページを新たに受信することなく、現在価格の表示の予定価格と表示が瞬時に切り替わるようになっていても良い。

　［１－２．共同購入サーバの構成］
　次に、共同購入サーバ１の構成について、図４乃至図６を用いて説明する。

　図４は、本実施形態に係る共同購入サーバ１の概要構成の一例を示すブロック図である。図４に示すように、共同購入サーバ１は、通信部１１と、記憶部１２と、入出力インターフェース１３と、システム制御部１４と、を備えている。そして、システム制御部１４と入出力インターフェース１３とは、システムバス１５を介して接続されている。

　通信部１１は、ネットワークＮＷに接続して、ユーザ端末３等との通信状態を制御するようになっている。

　記憶部１２は、例えば、ハードディスクドライブ等により構成されている。この記憶部１２には、会員情報ＤＢ１２ａ、商品情報ＤＢ１２ｂ、注文情報ＤＢ１２ｃ、購入履歴ＤＢ１２ｄ、検索用ＤＢ１２ｅ等のデータベースが構築されている。各データベースは、例えば、互いに異なるハードディスクドライブに構築されている。

　図５（ａ）は、会員情報ＤＢ１２ａに登録される内容の一例を示す図である。会員情報ＤＢ１２ａには、共同購入システムＳに会員登録しているユーザに関する会員情報が登録される。具体的に、会員情報ＤＢ１２ａには、ユーザＩＤ、パスワード、ニックネーム、氏名、生年月日、性別、郵便番号、住所、電話番号、電子メールアドレス等のユーザの属性が、ユーザごとに対応付けて登録される。ユーザＩＤは、ユーザの識別情報である。なお、会員情報ＤＢ１２ａに登録されている会員情報は、共同購入システムＳ以外のシステムや、共同購入以外のサービスにも用いられる。

　図５（ｂ）は、商品情報ＤＢ１２ｂに登録される内容の一例を示す図である。商品情報ＤＢ１２ｂには、共同購入可能な商品に関する商品情報が登録される。この商品情報は、店舗によって設定される情報である。具体的に、商品情報ＤＢ１２ｂには、商品ＩＤ、店舗ＩＤ、商品コード、ジャンルＩＤ、商品名、商品画像のＵＲＬ（Uniform Resource Locator）、商品説明、注文数別価格リスト、取扱数、最大注文数、販売期間等の商品の属性が、店舗が販売する商品ごとに対応付けて登録される。商品ＩＤ（本発明における識別情報の一例）は、店舗等が、販売する商品を管理するための商品の識別情報である。店舗ＩＤは、商品の販売元の店舗を示す。商品コードは、商品を識別するコード番号である。商品コードとしては、例えば、ＪＡＮ（Japanese Article Number Code）コード等がある。ジャンルＩＤは、商品が属するジャンルの識別情報である。商品名及び商品説明は、商品の情報として商品ページ等に表示されるとともに、キーワード検索で用いられる。具体的に、商品名及び商品説明の少なくとも何れか一方に、ユーザから指定されたキーワードを含む商品が検索される。取扱数は、店舗が対象の商品を販売することができる個数である。商品の合計注文数が取扱数に達すると、注文が締め切られる。販売期間は、商品の注文の受け付け開始日時（販売開始日時）と、注文の締め切り日時（販売終了日時）を示す。注文数別価格リストには、複数の価格情報が登録される。価格情報（本発明における設定情報の一例）は、必要注文数と適用価格との組み合わせを含む。必要注文数が多いほど、対応する適用価格が低くなるようになっている。また、基本的に、価格情報間で必要注文数は重複しない。また、価格情報間で適用価格は重複しない。

　図５（ｃ）は、注文情報ＤＢ１２ｃに登録される内容の一例を示す図である。注文情報ＤＢ１２ｃには、商品の注文の受付に関する情報が登録される。具体的に、注文情報ＤＢ１２ｃには、商品ＩＤ、現在注文数、注文履歴等が、商品ごとに対応付けて登録される。注文履歴には、対象の商品に対するユーザからの注文の履歴が登録される。具体的に、注文履歴には、注文コード、注文日時、ユーザＩＤ、注文数等が、注文ごとに登録される。注文コードは、商品の注文が受け付けられるたびに付与される注文の識別情報である。注文日時は、商品の注文が受け付けられた日時である。ユーザＩＤは、商品を注文したユーザを示す。注文数は、注文された商品の個数である。

　図５（ｄ）は、購入履歴ＤＢ１２ｄに登録される内容の一例を示す図である。購入履歴ＤＢ１２ｄには、ユーザによる商品の購入履歴が登録される。具体的に、購入履歴ＤＢ１２ｄには、注文コード、購入日時、ユーザＩＤ、商品ＩＤ、店舗ＩＤ、商品コード、注文数、購入価格等が対応付けて登録される。購入履歴は、注文の締め切り日時を経過することによって商品を注文したユーザによる商品の購入が確定した場合に、注文ごとに登録される。注文コードは、購入された商品の注文が受け付けられたときに付与されたものである。購入日時は、例えば、注文日時であっても良いし、注文の締め切り日時であっても良い。ユーザＩＤは、商品を購入したユーザを示す。商品ＩＤ及び商品コードは、購入された商品を示す。店舗ＩＤは、購入された商品の販売元の店舗を示す。注文数は、購入された商品が注文された個数である。この場合の注文数は、購入数でもある。購入価格は、購入された商品の最終的な合計注文数に対する適用価格に、注文数を掛け合わせることによって得られた価格である。

　図５（ｅ）は、検索用ＤＢ１２ｅに登録される内容の一例を示す図である。検索用ＤＢ１２ｅには、商品の検索と、該当商品情報２３１及び２３２の表示とに必要な商品の情報として、検索用レコードが登録される。この検索用レコード（本発明における組み合わせ情報の一例）は、検索を高速に行えるように編成された情報が格納される。また、検索用レコードは、各商品について、設定された適用価格ごと（注文数別価格リストに登録されている価格情報ごと）に登録される。具体的に、検索用レコードは、商品ＩＤ、現在注文数、現在価格、残り必要注文数、適用価格及びその他の情報を含む。商品ＩＤが同一である複数の検索用レコードには、同一の現在注文数及び現在価格が含まれる。残り必要注文数は、商品の価格が現在価格から、この残り必要注文数と同一の検索用レコードに含まれる適用価格に変化するまでに必要な残りの注文数である。基本的には、現在注文数と残り必要注文数との和が、適用価格に対応する必要注文数となる。現在注文数が、適用価格に対する必要注文数以上になると、残り必要注文数は０になる。その他の情報としては、例えば、店舗ＩＤ、店舗名、ジャンルＩＤ、商品コード、商品名、商品画像のＵＲＬ等がある。

　適用価格ごとに検索用レコードが登録される理由は、予定注文数に対応する適用価格を予定価格として検索結果ページに表示させるためである。しかしながら、検索用ＤＢ１２ｅに、各商品全ての適用価格について検索用レコードを登録しておくと、検索用ＤＢ１２ｅのデータ量が膨大となることがある。また、多数の検索用レコードを登録しておくと、検索速度が低下する場合がある。そこで、システム制御部１４は、検索及び価格の表示に必要な検索用レコードのみを検索用ＤＢ１２ｅに登録させておく。

　先ず、システム制御部１４は、ある商品の注文数別価格リストを含む商品情報が商品情報ＤＢ１２ｂに登録されたとき、注文数別価格リストに登録されている価格情報のうち、必要注文数が最大注文数以下である価格情報についてのみ価格情報を登録する。現在注文数（最初は０個）と最大注文数との和に相当する注文数以下の範囲内で予定価格が表示されれば良いからである。予定注文数が商品の最大注文数を超えた場合、その商品の予定価格として、現在注文数と最大注文数との和に対応する適用価格が表示されるようにすることとした理由は、その時点で検索用ＤＢ１２ｅに登録されている情報だけで予定価格を表示可能とするためである。予定価格の表示に当面必要な検索用レコードのみを登録することで、注文数別価格リストに登録されている全ての価格情報について検索用レコードを登録する場合よりも、検索用ＤＢ１２ｅの内容を注文数別価格リストの内容に同期させるための処理負荷を低減させることができる。

　その後、システム制御部１４は、ユーザからの注文が受け付けられることによって現在注文数が増加すると、現在注文数に応じて新たに検索用レコードを登録する。具体的に、システム制御部１４は、現在注文数の増加によって必要注文数が新たに現在注文数と最大注文数との和以下になった価格情報について検索用レコードを登録する。その一方で、システム制御部１４は、現在注文数の増加によって、適用価格が現在価格よりも高くなった検索用レコードを、検索用ＤＢ１２ｅから削除する。予定価格は、増加後の現在注文数以上の範囲内にある何れかの注文数に対応する適用価格である。従って、適用価格が現在価格よりも高くなった検索用レコードは、現在注文数以上の範囲内にある注文数に対応しない。現在価格よりも高い適用価格が予定価格として表示されることはないからである。

　以下に具体例を示す。図６（ａ）は、注文数別価格リストに登録される内容の一例を示す図である。また、図６（ｂ）乃至（ｄ）は、検索用ＤＢ１２ｅに登録されているある商品Ｘの検索用レコードとこの検索用レコードの内容の一例を示す図である。なお、図６（ｂ）乃至（ｄ）において、検索用レコードに含まれるその他の情報の図示は省略している。

　ある商品Ｘの注文数別価格リストが、例えば、図６（ａ）に示すように設定されている。具体的に、注文数別価格リストには、価格情報が５個登録されている。各価格情報において、必要注文数と適用価格との組み合わせは、１個と１００００円、２個と９５００円、１１個と９０００円、１０１個と８０００円、及び、２０１個と７０００円である。また、商品Ｘの最大注文数を５０個とする。

　商品情報の登録当初、検索用ＤＢ１２ｅには、図６（ｂ）に示すように、商品Ｘの検索用レコードが３個登録される。具体的に、最大注文数以下である必要注文数１個、２個及び１１個である検索用レコードが登録される。このとき、各検索用レコードの現在注文数と現在価格は、０個と１００００円である。また、各検索用レコードの残り必要注文数と適用価格は、対応する価格情報の必要注文数と適用価格である。

　その後、商品Ｘが４０個注文されたとする。すると、現在注文数が４０個になるため、現在価格は９０００円となる。そのため、図６（ｃ）に示すように、適用価格が１００００円の検索用レコードと、適用価格が９５００円の検索用レコードが検索用ＤＢ１２ｅから削除される。削除されなかった検索用レコードの現在注文数及び現在価格は更新される。その後、商品Ｘが更に２０個注文されたとする。すると、現在注文数が６０個になる。この場合、現在注文数と最大注文数との和が１１０となる。そのため、図６（ｄ）に示すように、必要注文数が１０１個である検索用レコードが新たに検索用ＤＢ１２ｅに登録される。また、検索用レコードの現在注文数が更新される。このように、検索用レコードの登録及び削除が行われる。

　なお、システム制御部１４は、残り必要注文数が０個になった検索用レコードも検索用ＤＢ１２ｅから削除しても良い。この検索用レコードに含まれる適用価格は現在価格と同一である。この検索用レコードに含まれる適用価格が予定価格として表示される場合は、予定価格が現在価格から変化しない場合である。従って、この場合は、他の検索用レコードに含まれる現在価格を、予定価格として表示すれば良い。ただしこの場合、システム制御部１４は、適用価格が最終価格である検索用レコードは削除しない。この検索用レコードを削除してしまうと、対象の商品の検索用レコードが全て削除されることになり、その商品を検索することができなくなるからである。

　次に、記憶部１２に記憶されるその他の情報について説明する。記憶部１２には、Ｗｅｂページを表示するためのＨＴＭＬ文書、ＸＭＬ（Extensible Markup Language）文書、画像データ、テキストデータ、電子文書等の各種データが記憶されている。また、記憶部１２には、管理者等により設定された各種の設定値が記憶されている。

　また、記憶部１２には、オペレーティングシステム、ＷＷＷ（World Wide Web）サーバプログラム、ＤＢＭＳ（Database Management System）、電子商取引管理プログラム等の各種プログラムが記憶されている。電子商取引管理プログラムは、商品情報の登録、商品の検索、検索結果ページ等のＷｅｂページの生成、商品の注文、検索用ＤＢ１２ｅに対する検索用レコードの登録や削除等、電子商店街に関する処理を実行するためのプログラムである。なお、各種プログラムは、例えば、他のサーバ装置等からネットワークＮＷを介して取得されるようにしても良いし、ＤＶＤ（Digital Versatile Disc）等の記録媒体に記録されてドライブ装置を介して読み込まれるようにしても良い。

　入出力インターフェース１３は、通信部１１及び記憶部１２とシステム制御部１４との間のインターフェース処理を行うようになっている。

　システム制御部１４は、ＣＰＵ１４ａ、ＲＯＭ（Read Only Memory）１４ｂ、ＲＡＭ（Random Access Memory）１４ｃ等により構成されている。そして、システム制御部１４は、ＣＰＵ１４ａが、各種プログラムを読み出し実行することにより、本発明における注文数取得手段、価格取得手段、出力手段、削除手段、設定情報取得手段及び制御手段として機能するようになっている。

　なお、共同購入サーバ１が、複数のサーバ装置で構成されても良い。例えば、商品情報を登録するサーバ装置、商品を検索するサーバ装置、商品の注文等の処理を行うサーバ装置、ユーザ端末３からのリクエストに応じてＷｅｂページを送信するサーバ装置、及びデータベースを管理するサーバ装置等が、互いにＬＡＮ等で接続されても良い。

　［１－３．共同購入システムの動作］
　次に、共同購入システムＳの動作について、図７乃至図１１を用いて説明する。

　図７は、本実施形態に係る共同購入サーバ１のシステム制御部１４の商品情報登録時処理における処理例を示すフローチャートである。

　商品情報登録時処理においては、商品情報が登録された商品の検索用レコードが検索用ＤＢ１２ｅに登録される。例えば、店舗の従業員が、新しく販売する商品の商品情報を登録するため、店舗端末２を操作する。すると、店舗端末２は、共同購入サーバ１にアクセスすることにより、商品情報を設定するためのＷｅｂページを表示する。従業員は、Ｗｅｂページに対して、必要注文数と適用価格との組み合わせを含む商品情報を設定する。すると、店舗端末２は、設定された商品情報を共同購入サーバ１に登録する。共同購入サーバ１は、受信した商品情報を商品情報ＤＢ１２ｂに登録する。商品情報登録時処理は、商品情報が商品情報ＤＢ１２ｂに登録されたときに開始される。

　先ず、システム制御部１４は、登録された商品情報から検索用レコードの生成に必要な情報を取得する（ステップＳ１）。ここで取得される情報としては、例えば、商品ＩＤ、店舗ＩＤ、ジャンルＩＤ、商品コード、商品名、商品説明等がある。また、システム制御部１４は、店舗ＩＤに対応する店舗名を取得する。また、システム制御部１４は、登録された商品情報から最大注文数を取得する。次いで、システム制御部１４は、登録された商品情報の注文数別価格リストから、必要注文数が最も少ない価格情報を取得する（ステップＳ２）。次いで、システム制御部１４は、開始価格に対して、取得した価格情報に含まれる適用価格を設定する。また、システム制御部１４は、商品情報が登録された商品の現在注文数として０を、その商品の商品ＩＤに対応付けて注文情報ＤＢ１２ｃに登録する（ステップＳ３）。

　次いで、システム制御部１４は、取得した価格情報に対応する検索用レコード登録する（ステップＳ４）。具体的に、システム制御部１４は、検索用レコードを生成する。このとき、システム制御部１４は、検索用レコードの商品ＩＤとして、商品情報から取得した商品ＩＤを設定する。また、システム制御部１４は、検索用レコードの現在注文数として０を設定する。また、システム制御部１４は、検索用レコードの残り必要注文数として、取得した価格情報に含まれる必要注文数を設定する。また、システム制御部１４は、検索用レコードの適用価格として、取得した価格情報に含まれる価格情報を設定する。また、システム制御部１４は、ステップＳ１において取得したその他の情報を設定する。システム制御部１４は、こうして生成した検索用レコードを、検索用ＤＢ１２ｅに登録する。

　次いで、システム制御部１４は、登録された商品情報の注文数別価格リストから、まだ取得していない価格情報のうち、必要注文数が最も少ない価格情報を取得する（ステップＳ５）。そして、システム制御部１４は、取得した価格情報に対応する検索用レコード登録する（ステップＳ６）。この場合の処理内容は、ステップＳ４の場合と同様である。ステップＳ５において取得される検索用レコードに含まれる適用価格は、販売開始時点の現在価格の次の適用価格である。検索結果ページの検索結果表示領域２３０に次価格残り必要注文数を表示するためには、ステップＳ５において取得される検索用レコードに含まれる残り必要注文数が必要となる。そのため、最低でも２個の検索用レコードが登録される。

　次いで、システム制御部１４は、登録された商品情報の注文数別価格リストに、まだ取得していない価格情報があるか否かを判定する（ステップＳ７）。このとき、システム制御部１４は、全ての価格情報を取得したと判定した場合には（ステップＳ７：ＮＯ）、商品情報登録時処理を終了させる。

　一方、システム制御部１４は、まだ取得していない価格情報があると判定した場合には（ステップＳ７：ＹＥＳ）、まだ取得していない価格情報のうち、必要注文数が最も少ない価格情報を選択する（ステップＳ８）。次いで、システム制御部１４は、選択した価格情報に含まれる必要注文数が最大注文数以下であるか否かを判定する（ステップＳ９）。このとき、システム制御部１４は、必要注文数が最大注文数以下である場合には、選択した価格情報を注文数別価格リストから取得し、この価格情報に対応する検索用レコード登録する（ステップＳ１０）。この場合の処理内容は、ステップＳ４の場合と同様である。システム制御部１４は、この処理を終えると、ステップＳ７に移行する。一方、システム制御部１４は、必要注文数が最大注文数以下ではないと判定した場合には（ステップＳ９：ＮＯ）、商品情報登録時処理を終了させる。こうして、システム制御部１４は、検索用レコードを、必要な分だけ検索用ＤＢ１２ｅに登録する。

　図８及び図９は、本実施形態に係る共同購入サーバ１のシステム制御部１４の検索処理における処理例を示すフローチャートである。検索処理においては、ユーザ端末３からの要求に応じて商品の検索が行われ、検索結果ページのＨＴＭＬ文書がユーザ端末３へ送信される。

　電子商店街のトップページにおいてユーザが検索条件を指定すると、ユーザ端末３は、検索リクエストを共同購入サーバ１に送信する。検索リクエスト（本発明におけるユーザの要求の一例）は、ユーザからの商品の検索の要求を示すメッセージである。また、検索リクエストは、検索条件を示す情報を含む。具体的に、ユーザがキーワードを指定した場合、指定されたキーワードが設定される。また、ユーザがジャンルを指定した場合、指定されたジャンルのジャンルＩＤが設定される。また、検索リクエストは、検索結果ページに予定価格を表示させるか否かを示す予定価格表示フラグを含む。具体的に、予定価格表示チェックボックス１３０が、チェックが入れられている状態ではない場合、予定価格表示フラグがＯＦＦに設定される。一方、予定価格表示チェックボックス１３０が、チェックが入れられている状態である場合、予定価格表示フラグがＯＮに設定される。

　図８に示すように、システム制御部１４は、ユーザ端末３から検索リクエストを受信すると（ステップＳ２１）、記憶部１２から、検索結果ページのＨＴＭＬ文書のテンプレートを取得する（ステップＳ２２）。

　次いで、システム制御部１４は、検索結果ページに予定価格を表示させるようにユーザから指示されたか否かを判定する（ステップＳ２３）。具体的に、システム制御部１４は、予定価格表示フラグがＯＦＦに設定されている場合、指示されていないと判定し、予定価格表示フラグがＯＮに設定されている場合、指示されていると判定する。このとき、システム制御部１４は、予定価格を表示させるように指示されていないと判定した場合には（ステップＳ２３：ＮＯ）、通常の検索処理を行う（ステップＳ２４）。

　先ず、システム制御部１４は、検索用ＤＢ１２ｅから、検索条件を満たす商品の検索用レコードを検索する。具体的に、システム制御部１４は、検索リクエストにキーワードが設定された場合、商品名及び商品説明の少なくとも一方に、このキーワードを含む検索用レコードを検索する。また、システム制御部１４は、検索リクエストにジャンルＩＤが設定された場合、検索用レコードに含まれるジャンルＩＤに基づいて、指定されたジャンルに属する商品の検索用レコードを検索する。検索リクエストに検索条件を示す情報が複数設定されている場合、システム制御部１４は、例えば、複数の検索条件を満たす検索用レコードを検索する。なお、ジャンルは階層構造になっていても良い。この場合、各商品にはその商品が属する最下層のジャンルだけを紐付けても良いし、最下層から最上層に遡る親子ジャンルの一部または全部を紐付けても良い。

　次いで、システム制御部１４は、検索した検索用レコードに基づいて、該当商品情報２３１を表示するためのデータを商品ごとに生成する。このとき、システム制御部１４は、検索用レコードに含まれる現在価格が表示されるようにデータを生成する。そして、システム制御部１４は、生成したデータを、検索ページのＨＴＭＬ文書のテンプレートにおいて、検索結果表示領域２３０に対応する領域に追加設定する。ここで、システム制御部１４は、検索用レコードに含まれる現在価格が低い順にデータを設定する。これにより、該当商品情報２３１が現在価格の低い順に表示されるようにする。システム制御部１４は、この処理を終えると、ステップＳ５８に移行する。

　ステップＳ２３において、システム制御部１４は、予定価格を表示させるように指示されていると判定した場合には（ステップＳ２３：ＹＥＳ）、検索レコードリスト及び表示レコードを初期化する（ステップＳ２５）。検索レコードリストは、検索された商品の検索用レコードが登録されるリストである。表示レコードリストは、検索された商品の検索用レコードのうち、該当商品情報２３２を表示するために用いられる検索用レコードが登録されるリストである。

　次いで、システム制御部１４は、検索用ＤＢ１２ｅから、検索条件を満たす商品の検索用レコードを検索する（ステップＳ２６）。この場合の検索方法は、ステップＳ２４の場合と同様である。そして、システム制御部１４は、検索条件を満たす商品の検索用レコードを検索レコードリストに登録する。

　次いで、システム制御部１４は、検索した商品のうち１つを選択する（ステップＳ２７）。具体的に、システム制御部１４は、検索レコードリストに登録された検索用レコードのうち１つの検索用レコードに含まれる商品ＩＤを、選択商品の商品ＩＤとして取得する。次いで、システム制御部１４は、検索レコードリストから、選択商品の商品ＩＤを含む検索用レコードを全て抽出する（ステップＳ２８）。このとき、システム制御部１４は、抽出した検索用レコードを検索レコードリストから削除する。次いで、システム制御部１４は、注文数取得手段として、予定注文数推定処理を実行する（ステップＳ２９）。

　図１０は、本実施形態に係る共同購入サーバ１のシステム制御部１４の予定注文数推定処理における処理例を示すフローチャートである。先ず、システム制御部１４は、抽出した選択商品の検索用レコードからジャンルＩＤを取得する（ステップＳ７１）。次いで、システム制御部１４は、購入履歴ＤＢ１２ｄから、検索リクエストを送信したユーザ端末３を利用するユーザのユーザＩＤと、検索用レコードから取得したジャンルＩＤを含む購入履歴を検索する（ステップＳ７２）。つまり、システム制御部１４は、検索を要求したユーザが選択商品と同一のジャンルの商品を購入したときの購入履歴を検索する。システム制御部１４は、ユーザが電子商店街にログインしている場合、検索を要求したユーザのユーザＩＤを取得することができる。例えば、システム制御部１４は、ユーザによるログイン時に、ユーザ端末３からユーザＩＤを受信し、受信したユーザＩＤをクッキーとしてユーザ端末３に保存させている。そのため、ユーザがログインしている場合には、検索リクエストに、ユーザＩＤを含むクッキーが付加されている。そこで、システム制御部１４は、検索クエリに付加されているクッキーからユーザＩＤを取得する。

　次いで、システム制御部１４は、該当する購入履歴が検索されたか否かを判定する（ステップＳ７３）。このとき、システム制御部１４は、該当する購入履歴が検索されたと判定した場合には（ステップＳ７３：ＹＥＳ）、検索された購入履歴のうち、購入日時が最新の購入履歴を選択する。そして、システム制御部１４は、選択した購入履歴に含まれる注文数を、予定注文数として設定する。つまり、システム制御部１４は、選択商品と同一のジャンルの商品についての最新の注文数を予定注文数とする。なお、システム制御部１４は、例えば、検索された各購入履歴に含まれる注文数の平均値を計算して、この平均値を予定注文数として設定しても良い。また、システム制御部１４は、選択商品のジャンルＩＤではなく、選択商品の商品コードを含む購入履歴を検索しても良い。つまり、システム制御部１４は、検索を要求したユーザによる選択商品と同一商品の購入履歴に基づいて、予定注文数を推定しても良い。システム制御部１４は、この処理を終えると、予定注文数推定処理を終了させる。

　一方、システム制御部１４は、該当する購入履歴が検索されなかったと判定した場合には（ステップＳ７３：ＮＯ）、購入履歴ＤＢ１２ｄから、検索用レコードから取得したジャンルＩＤを含む購入履歴を検索する（ステップＳ７５）。つまり、システム制御部１４は、選択商品と同一のジャンルの商品が購入されたときの購入履歴を、購入したユーザが誰であるかを問わずに全ユーザについて検索する。次いで、システム制御部１４は、検索された各購入履歴に含まれる注文数の平均値を計算して、この平均値を予定注文数として設定する（ステップＳ７６）。このとき、システム制御部１４は、ユーザごとに購入日時が最新の購入履歴を選択し、選択された購入履歴に含まれる注文数のみを用いて平均値を計算しても良い。また、システム制御部１４は、選択商品と同一のジャンルの商品の購入履歴ではなく、選択商品と同一商品の購入履歴に基づいて、予定注文数を推定しても良い。システム制御部１４は、この処理を終えると、予定注文数推定処理を終了させる。

　なお、システム制御部１４は、予定注文数推定処理において、ステップＳ７１～Ｓ７４のみを実行しても良いし、ステップＳ７１、Ｓ７５及びＳ７６のみを実行しても良い。また、システム制御部１４は、該当する購入履歴を検索することができなかった場合には、例えば、その選択商品については、予定価格ではなく現在価格が検索結果表示領域２３０に表示されるようにしても良い。

　システム制御部１４は、予定注文数推定処理を終えると、図８に示すように、推定された予定注文数が選択商品の最大注文数以下であるか否かを判定する（ステップＳ３０）。このとき、システム制御部１４は、予定注文数が最大注文数以下であると判定した場合には（ステップＳ３０：ＹＥＳ）、表示予定注文数に予定注文数を設定する（ステップＳ３１）。表示予定注文数は、該当商品情報２３２に実際に表示される予定注文数であり、予定価格を特定するために用いられる予定注文数である。一方、システム制御部１４は、予定注文数が最大注文数以下ではないと判定した場合には（ステップＳ３０：ＮＯ）、表示予定注文数に最大注文数を設定する（ステップＳ３２）。

　システム制御部１４は、ステップＳ３０またはＳ３１の処理を終えると、ステップＳ２８において抽出した選択商品の検索用レコードのうち、格納されている残り必要注文数が最も多い検索用レコードを選択する（ステップＳ３３）。次いで、システム制御部１４は、選択した検索用レコードに含まれる残り必要注文数が表示予定注文数以下であるか否かを判定する（ステップＳ３４）。このとき、システム制御部１４は、残り必要注文数が表示予定注文数以下ではないと判定した場合には（ステップＳ３４：ＮＯ）、選択商品の検索用レコードの中から、まだ選択していない検索用レコードのうち、格納されている残り必要注文数が最も多い検索用レコードを選択する（ステップＳ３５）。次いで、システム制御部１４は、ステップＳ３４に移行する。一方、システム制御部１４は、残り必要注文数が表示予定注文数以下であると判定した場合には（ステップＳ３４：ＹＥＳ）、選択した検索用レコードを表示レコードリストに登録する（ステップＳ３６）。つまり、システム制御部１４は、表示予定注文数に対する適用価格を含む検索用レコードを登録する。こうして、システム制御部１４は、価格取得手段として、現在注文数と表示予定注文数との和に相当する注文数に対応する適用価格を検索用ＤＢ１２ｅから取得する。この適用価格が、予定価格として表示される。

　次いで、システム制御部１４は、図９に示すように、検索した商品のうちまだ選択していない商品があるか否かを判定する（ステップＳ５１）。具体的に、システム制御部１４は、検索レコードリストに検索用レコードがまだ登録されているか否かを判定する。システム制御部１４は、検索用レコードがまだ登録されている場合には、まだ選択していない商品があると判定し、検索用レコードが登録されていない場合には、全ての商品を選択したと判定する。このとき、システム制御部１４は、まだ選択していない商品があると判定した場合には（ステップＳ５１：ＹＥＳ）、まだ選択していない商品のうち１つを選択する（ステップＳ５２）。具体的に、システム制御部１４は、検索レコードリストに登録された検索用レコードのうち１つの検索用レコードに含まれる商品ＩＤを、選択商品の商品ＩＤとして取得する。次いで、システム制御部１４は、ステップＳ２８に移行する。システム制御部１４は、ステップＳ２８～Ｓ５２の処理を繰り返すことにより、検索された各商品について、予定価格の表示に必要な検索用レコードを表示レコードリストに登録する。なお、システム制御部１４は、予定注文数推定処理を、検索した商品ごとに実行しているが、例えば、検索した商品が属するジャンルごとに実行しても良い。そうすることで、同一ジャンルに属する商品が複数検索された場合に、予定注文数推定処理の実行回数を減らすことができる。

　ステップＳ５１において、システム制御部１４は、全ての商品を選択したと判定した場合には（ステップＳ５１：ＮＯ）、表示レコードリストに登録されている検索用レコードのうち、格納されている適用価格が最も低い検索用レコードを１つ選択する（ステップＳ５３）。次いで、システム制御部１４は、選択した検索用レコードに基づいて、該当商品情報２３２を表示するためのデータを、検索ページのＨＴＭＬ文書のテンプレートに追加する（ステップＳ５４）。具体的に、システム制御部１４は、検索用レコードに含まれる商品名、店舗名及び適用価格と、表示予定注文数とを含むデータを生成する。このとき、システム制御部１４は、適用価格を予定価格とする。そして、システム制御部１４は、生成したデータを、検索ページのＨＴＭＬ文書のテンプレートにおいて、検索結果表示領域２３０に対応する領域に追加設定する。

　次いで、システム制御部１４は、該当商品情報２３２を１ページあたりに表示可能な上限数まで、該当商品情報２３２のデータを追加したか否かを判定する（ステップＳ５５）。このとき、システム制御部１４は、上限数まで追加していないと判定した場合には（ステップＳ５５：ＮＯ）、表示レコードリストに登録されている検索用レコードのうち、まだ選択していない検索用レコードがあるか否かを判定する（ステップＳ５６）。このとき、システム制御部１４は、まだ選択していない検索用レコードがあると判定した場合には（ステップＳ５６：ＹＥＳ）、まだ選択していない検索用レコードのうち、格納されている適用価格が最も低い検索用レコードを１つ選択する（ステップＳ５７）。次いで、システム制御部１４は、ステップＳ５４に移行する。システム制御部１４は、ステップＳ５４～Ｓ５７の処理を繰り返すことにより、検索された各商品の該当商品情報２３２が予定価格が低い順に表示されるようにＨＴＭＬ文書に対する設定を行う。

　システム制御部１４は、ステップＳ２４の処理を終えた場合、ステップＳ５５において上限数まで追加したと判定した場合（ステップＳ５５：ＹＥＳ）、または、ステップＳ５６において全ての検索用レコードを選択したと判定した場合には（ステップＳ５６：ＮＯ）、出力手段として、各データの設定により完成した検索結果ページのＨＴＭＬ文書を、検索リクエストの送信元のユーザ端末３へ送信する（ステップＳ５８）。システム制御部１４は、この処理を終えると、検索処理を終了させる。

　図１１は、本実施形態に係る共同購入サーバ１のシステム制御部１４の注文時処理における処理例を示すフローチャートである。

　電子商店街の商品ページにおいて、ユーザが購入したい商品の数を注文数として入力し、注文するためのボタンを選択する。すると、ユーザ端末３は、商品の注文の要求を示す注文リクエストを共同購入サーバ１に送信する。注文リクエストは、注文対象の商品（以下、「注文商品」という）の商品ＩＤと、入力された注文数とを含む。注文時処理は、共同購入サーバ１が注文リクエストを受信したときに開始される。

　先ず、システム制御部１４は、注文商品の現在注文数を更新する（ステップＳ８１）。具体的に、システム制御部１４は、注文情報ＤＢ１２ｃに登録されている現在注文数のうち、注文商品の商品ＩＤに対応する現在注文数を検索する。そして、システム制御部１４は、検索した現在注文数に、検索リクエストに含まれる注文数を加算する。

　次いで、システム制御部１４は、注文商品の現在価格を取得する（ステップＳ８２）。具体的に、システム制御部１４は、注文商品の商品ＩＤに対応付けて商品情報ＤＢ１２ｂに登録されている注文数別価格リストから、更新後の現在注文数に対応する適用価格を、現在価格として取得する。現在注文数に対応する適用価格は、現在注文数以下の必要注文数を含む価格情報のうち、現在注文数に最も近い必要注文数を含む価格情報に含まれる適用価格である。

　次いで、システム制御部１４は、注文履歴を記録する（ステップＳ８３）。具体的に、システム制御部１４は、注文コード、注文日時、注文したユーザのユーザＩＤ、注文リクエストに含まれる注文数等を、注文商品の商品ＩＤに対応付けて注文情報ＤＢ１２ｃに登録する。

　次いで、システム制御部１４は、検索用ＤＢ１２ｅから、注文商品の商品ＩＤを含む検索用レコードを検索する（ステップＳ８４）。次いで、システム制御部１４は、検索した検索用レコードのうち、格納されている適用価格が最も高い検索用レコードを選択する。そして、システム制御部１４は、選択した検索用レコードに含まれる適用価格を、登録済最高価格として設定する（ステップＳ８５）。

　次いで、システム制御部１４は、検索した検索用レコードのうち１つを選択する（ステップＳ８６）。次いで、システム制御部１４は、選択した検索用レコードに含まれる適用価格が現在価格以上であるか否かを判定する（ステップＳ８７）。このとき、システム制御部１４は、適用価格が現在価格以上であると判定した場合には（ステップＳ８７：ＹＥＳ）、選択した検索用レコードを更新する（ステップＳ８８）。具体的に、システム制御部１４は、検索用レコードの現在注文数として、更新後の現在注文数を設定する。また、システム制御部１４は、検索用レコードの現在価格として、現在注文数の更新後に対応する現在価格を設定する。また、システム制御部１４は、検索用レコードの残り必要注文数から、検索リクエストに含まれる注文数を減算する。一方、システム制御部１４は、適用価格が現在価格以上ではないと判定した場合には（ステップＳ８７：ＮＯ）、選択した検索用レコードを検索用ＤＢ１２ｅから削除する（ステップＳ８９）。

　システム制御部１４は、ステップＳ８８またはＳ８９の処理を終えると、検索した検索用レコードのうちまだ選択していない検索用レコードがあるか否かを判定する（ステップＳ９０）。このとき、システム制御部１４は、まだ選択していない検索用レコードがあると判定した場合には（ステップＳ９０：ＹＥＳ）、まだ選択していない検索用レコードのうち１つを選択する（ステップＳ９１）。次いで、システム制御部１４は、ステップＳ８７に移行する。システム制御部１４は、ステップＳ８７～Ｓ９１の処理を繰り返すことにより、削除手段として、増加後の現在注文数以上の範囲内にある注文数に対応しない検索用レコードを検索用ＤＢ１２ｅから削除する。

　そして、システム制御部１４は、全ての検索用レコードを選択したと判定した場合には（ステップＳ９０：ＮＯ）、注文商品の注文数別価格リストに、登録済最高価格の次に低い適用価格を含む価格情報があるか否かを判定する（ステップＳ９２）。登録済最高価格の次に低い適用価格は、注文数別価格リストに登録されている複数の適用価格の中で、登録済最高価格より高い適用価格のうち、登録済最高価格に最も近い価格である。このとき、システム制御部１４は、次に低い適用価格を含む価格情報がないと判定した場合には（ステップＳ９２：ＮＯ）、注文時処理を終了させる。この場合は、注文商品の最終価格を含む検索用レコードが既に検索用ＤＢ１２ｅに登録されている場合である。

　一方、システム制御部１４は、次に低い適用価格を含む価格情報があると判定した場合には（ステップＳ９２：ＹＥＳ）、登録済最高価格の次に低い適用価格を含む価格情報を選択する（ステップＳ９３）。次いで、システム制御部１４は、選択した価格情報に含まれる適用価格が更新後の現在価格以上であるか否かを判定する（ステップＳ９４）。このとき、システム制御部１４は、適用価格が現在価格以上であると判定した場合には（ステップＳ９４：ＹＥＳ）、選択した価格情報に含まれる必要注文数が、注文商品の現在注文数と最大注文数との和以下であるか否かを判定する（ステップＳ９５）。このとき、システム制御部１４は、必要注文数が現在注文数と最大注文数との和以下であると判定した場合には（ステップＳ９５：ＹＥＳ）、設定情報取得手段として、選択した価格情報を商品情報ＤＢ１２ｂから取得する（ステップＳ９６）。次いで、システム制御部１４は、制御手段として、取得した価格情報に対応する検索用レコード登録する（ステップＳ９７）。具体的に、システム制御部１４は、検索用レコードを生成する。このとき、システム制御部１４は、検索用レコードの商品ＩＤとして、注文商品の商品ＩＤを設定する。また、システム制御部１４は、検索用レコードの現在注文数として、更新後の現在注文数を設定する。また、システム制御部１４は、検索用レコードの現在価格として、更新後の現在注文数に対応する現在価格を設定する。また、システム制御部１４は、検索用レコードの残り必要注文数として、取得した価格情報に含まれる必要注文数と更新後の現在注文数との差を設定する。また、システム制御部１４は、検索用レコードの適用価格として、取得した価格情報に含まれる価格情報を設定する。また、システム制御部１４は、その他の情報を設定する。システム制御部１４は、こうして生成した検索用レコードを、検索用ＤＢ１２ｅに登録する。

　システム制御部１４は、ステップＳ９４において適用価格が現在価格以上ではないと判定した場合（ステップＳ９４：ＮＯ）、または、ステップＳ９７の処理を終えた場合には、注文商品の注文数別価格リストに、選択した価格情報に含まれる適用価格の次に低い適用価格を含む価格情報があるか否かを判定する（ステップＳ９８）。このとき、システム制御部１４は、次に低い適用価格を含む価格情報があると判定した場合には（ステップＳ９８：ＹＥＳ）、選択した価格情報に含まれる適用価格の次に低い適用価格を含む価格情報を選択する（ステップＳ９９）。次いで、システム制御部１４は、ステップＳ９４に移行する。システム制御部１４は、ステップＳ９４～Ｓ９９の処理を繰り返すことにより、商品情報ＤＢ１２ｂに登録されている注文商品の注文数別価格リストから、更新後の現在注文数と最大注文数との和に相当する注文数以下の範囲内にある注文数に対応する適用価格を含む価格情報を取得し、取得した価格情報に応じた検索用レコードを検索用ＤＢ１２ｅに登録する。

　そして、システム制御部１４は、ステップＳ９５において必要注文数が現在注文数と最大注文数との和以下ではないと判定した場合（ステップＳ９５：ＮＯ）、または、ステップＳ９８において次に低い適用価格を含む価格情報がないと判定した場合には（ステップＳ９８：ＮＯ）、注文時処理を終了させる。

　以上説明したように、本実施形態によれば、共同購入サーバ１のシステム制御部１４は、検索リクエストに基づいて検索された商品についての予定注文数を取得し、予定注文数と検索された商品の現在注文数との和に相当する注文数での販売が決定された場合の適用価格を、検索用ＤＢ１２ｅに登録された検索用レコードから取得し、取得された適用価格を予定価格として表示する検索結果ページのＨＴＭＬ文書を送信する。従って、ユーザは自分が商品を注文するとした場合に注文が予定される数分増加した合計注文数に応じた価格を知ることができる。

　また、システム制御部１４が、購入履歴ＤＢ１２ｄに登録された購入履歴に基づいて、予定注文数を推定する。従って、ユーザは自分が商品を注文するとした場合に注文が予想される数分増加した合計注文数に応じた商品の価格を知ることができる。

　また、システム制御部１４が、商品の注文によって現在注文数が更新された場合、検索用ＤＢ１２ｅに登録された注文商品の検索用レコードのうち、更新後の現在注文数以上の範囲内にある注文数に対応しない検索用レコードを削除する。従って、検索用ＤＢ１２ｅのデータ量を削減することができる。

　また、システム制御部１４が、商品情報ＤＢ１２ｂに登録された注文数別価格リストに登録されている価格情報のうち、注文数別価格リストに対応する商品ＩＤに対応する商品の現在注文数と最大注文数との和に相当する注文数以下の範囲内にある注文数に対応する価格情報を取得し、取得された価格情報に応じた検索用レコードを検索用ＤＢ１２ｅに登録する。従って、検索用ＤＢ１２ｅの内容を注文数別価格リストの内容に同期させるための処理負荷を低減させることができる。また、検索用ＤＢ１２ｅのデータ量を削減することができる。

　なお、図１１に示すフロー図では、適用価格が現在価格未満の検索用レコードを１レコードずつ検索用ＤＢ１２ｅから削除する例を示したが、検索用レコードを一括して削除した後に適用価格が現在価格以上であるレコードを一括して追加するよう構成しても良い。

　［２．第２実施形態］
　上記第１実施形態においては、共同購入サーバ１が購入履歴に基づいて予定注文数が推定されていた。これに対し、以下に説明する第２実施形態においては、ユーザが、商品を注文すると仮定した場合に希望する注文数を指定し、共同購入サーバ１が、指定された注文数を予定注文数としてユーザ端末３から取得する。以下では、第１実施形態と異なる点を主として説明する。

　図１２は、本実施形態におけるトップページの表示例を示す図である。図１２において、図２と同様の要素については、同様の符号を付してある。図１２に示すように、トップページは、検索条件設定領域１１０、ジャンル指定領域１２０、注文数入力欄１４０等を含む。注文数入力欄１４０は、希望する注文数を入力するための入力領域である。注文数入力欄１４０に対してユーザが注文数を入力せずに、検索条件のみを指定すると、検索結果ページとして、図３（ａ）に示すような検索結果ページが表示される。一方、注文数入力欄１４０に対してユーザが注文数を入力して、検索条件を指定すると、検索結果ページとして、図３（ｂ）に示すような検索結果ページが表示される。この場合、検索された商品のジャンルの如何に関わらず、その商品の現在注文数とユーザが入力した注文数との和に対応する適用価格が予定価格として表示される。ただし、ユーザが入力した注文数が最大注文数を超える商品については、現在注文数と最大注文数との和に対応する適用価格が予定価格として表示される。

　ユーザが注文数を入力した場合、ユーザ端末３から送信される検索リクエストには、入力された注文数が、予定注文数として設定される。図８に示す検索処理のステップＳ２３において、システム制御部１４は、検索結果ページに予定価格を表示させるようにユーザから指示されたか否かを判定する代わりに、検索リクエストに予定注文数が設定されているか否かを判定する。このとき、システム制御部１４は、予定注文数が設定されていないと判定した場合には、ステップＳ２４に移行し、検索された商品の現在価格を表示させるための処理を行う。一方、システム制御部１４は、予定注文数が設定されていると判定した場合には、ステップＳ２６に移行し、検索された商品の予定価格を表示させるための処理を行う。ここで、システム制御部１４は、ステップＳ２９の予定注文数推定処理を実行せずに、ステップＳ３０においては、検索リクエストに設定された予定注文数を用いて判定を行う。

　以上説明したように、本実施形態によれば、ユーザは自分が希望する数で商品を注文するとした場合に希望する数分増加した合計注文数に応じた商品の価格を知ることができる。

　なお、システム制御部１４は、図７に示す商品情報登録時処理のステップＳ９、及び、図１１に示す注文時処理のステップＳ９５において、検索用レコードを検索用ＤＢ１２ｅに登録する必要があるか否かを判定するための閾値として、商品の最大注文数を用いていた。しかしながら、この閾値として、最大注文数以外の情報を用いても良い。また、図８に示す検索処理のステップＳ３０において予定注文数と比較する閾値として、最大注文数以外の情報を用いても良い。例えば、システム制御部１４は、商品ごとに店舗により設定した閾値を用いても良い。また、購入履歴に基づいて閾値を設定しても良い。具体的に、システム制御部１４は、購入履歴ＤＢ１２ｄから、閾値を決定する商品とジャンルが同一の商品または商品コードが同一の商品の購入履歴を検索する。そして、システム制御部１４は、検索した購入履歴に含まれる注文数に基づいて、閾値を決定する。このとき、システム制御部１４は、過去の注文のうちある割合以上の注文における注文数が閾値以下となるように、閾値を決定する。具体的に、検索した各購入履歴における注文数のうち、Ｎパーセンタイルに対応する注文数を閾値とする。つまり、注文数が閾値以下である注文の割合がＮ％、注文数が閾値よりも大きい注文の割合が１００－Ｎ％となるように、閾値を決定する。Ｎは、予め設定された値である。例えば、大部分の注文数が閾値以下となるように、５０を超える範囲内でＮを設定すると良い。

　また、上記各実施形態においては、検索用レコードに、現在注文数及び現在価格が設定されるようになっていた。しかしながら、検索結果ページに現在注文数及び現在価格を表示する必要がない場合（図３（ａ）に示す検索結果ページを表示させなくても良い場合）には、現在注文数及び現在価格は設定されなくても良い。

　また、上記各実施形態においては、検索用レコードに、残り必要注文数が設定されていた。しかしながら、同じ検索用レコードに含まれる適用価格が予定価格であるか否かの判定可能な情報であれば、残り必要注文数の代わりに別の情報が検索用レコードに設定されても良い。例えば、適用価格に対応する残りの注文数の範囲が検索用レコードに設定されても良い。例えば、図６（ｃ）の例では、適用価格が９０００円である検索用レコードには、残りの注文数の範囲として０～６０が設定される。また、図６（ｄ）の例では、適用価格が９０００円である検索用レコードには、残りの注文数の範囲として０～４０が設定され、適用価格が８０００円である検索用レコードには、４１～が設定される。また、例えば、必要注文数が検索用レコードに設定されても良い。この場合、現在注文数、予定注文数、及び検索用レコードに含まれる必要注文数に基づいて、その検索用レコードに含まれる適用価格が予定価格であるか否かを判定することができる。この場合の現在注文数は、検索用レコードに設定されて、検索用レコードから取得されるようにしても良いし、商品情報ＤＢ１２ｂから取得されるようにしても良い。また、適用価格に対応する注文数の範囲が検索用レコードに設定されても良い。例えば、図６（ｂ）の例では、適用価格が１００００円である検索用レコードには、注文数の範囲として１～１が設定され、適用価格が９５００円である検索用レコードには、注文数の範囲として２～１０が設定され、適用価格が９０００円である検索用レコードには、注文数の範囲として１１～１００が設定される。注文数の範囲は、現在注文数が増加しても変化しない。

　また、注文数別価格リストの価格情報には、必要注文数の代わりに、適用価格に対応する注文数の範囲が設定されても良い。

　また、上記実施形態においては、ユーザから指定された検索条件に基づく商品の検索結果として、検索された商品を表示する場合の価格の表示に本発明を適用していたが、本発明を適用可能な態様は検索結果の表示に限られるものではない。例えば、商品ページに商品の情報を表示する場合の価格の表示に本発明を適用しても良い。

１　共同購入サーバ
２　店舗端末
３　ユーザ端末
１１　通信部
１２　記憶部
１２ａ　会員情報ＤＢ
１２ｂ　商品情報ＤＢ
１２ｃ　注文情報ＤＢ
１２ｄ　購入履歴ＤＢ
１２ｅ　検索用ＤＢ
１３　入出力インターフェース
１４　システム制御部
１４ａ　ＣＰＵ
１４ｂ　ＲＯＭ
１４ｃ　ＲＡＭ
１５　システムバス
ＮＷ　ネットワーク
Ｓ　共同購入システム

Claims (8)

1. 　ユーザの要求に応じて特定された商品について該ユーザが注文を予定する数を取得する注文数取得手段と、
   　前記注文数取得手段により取得された数と前記特定された商品のこれまでに注文された数との和に相当する注文数での販売が決定された場合の該商品の価格を、商品の価格と注文数との組み合わせを示す組み合わせ情報を商品ごとに記憶する記憶手段から取得する価格取得手段と、
   　前記価格取得手段により取得された価格を、前記特定された商品に関連付けて出力する出力手段と、
   　を備えることを特徴とする情報提供装置。
2. 　請求項１に記載の情報提供装置において、
   　前記注文数取得手段は、注文された商品の数を含む注文ごとの購入履歴を記憶する履歴記憶手段に記憶された前記購入履歴に基づいて、前記ユーザが注文を予定する数を推定することを特徴とする情報提供装置。
3. 　請求項１に記載の情報提供装置において、
   　前記ユーザの要求は、該ユーザが注文を希望する数を含み、
   　前記注文数取得手段は、前記ユーザの要求に含まれる数を、該ユーザが注文を予定する数として取得することを特徴とする情報提供装置。
4. 　請求項１乃至３の何れか１項に記載の情報提供装置において、
   　前記記憶手段には、各商品について、該商品の価格と該価格に対応する注文数とを示す前記組み合わせ情報対応情報が価格ごとに記憶され、
   　商品のこれまでの注文数が増加した場合、前記記憶手段に記憶された該商品の前記組み合わせ情報のうち、増加後の注文数以上の範囲内にある注文数に対応しない前記組み合わせ情報対応情報を、前記記憶手段から削除する削除手段を更に備えることを特徴とする情報提供装置。
5. 　請求項１乃至４の何れか１項に記載の情報提供装置において、
   　商品の販売者により設定された設定情報であり、商品の価格と該価格が適用される注文数とを示す設定情報を商品を識別する識別情報に関連付けて複数記憶する設定情報記憶手段に記憶された前記設定情報のうち、該設定情報に関連付けられた前記識別情報により識別される商品のこれまでに注文された数と予め設定された数との和に相当する注文数以下の範囲内にある注文数に対応する前記設定情報を取得する設定情報取得手段と、
   　前記設定情報取得手段により取得された前記設定情報に応じた前記組み合わせ情報を前記記憶手段に記憶させる制御手段と、
   　を更に備えることを特徴とする情報提供装置。
6. 　コンピュータにより実行される情報提供方法であって、
   　ユーザの要求に応じて特定された商品について該ユーザが注文を予定する数を取得する注文数取得ステップと、
   　前記注文数取得ステップにおいて取得された数と前記特定された商品のこれまでに注文された数との和に相当する注文数での販売が決定された場合の該商品の価格を、商品の価格と注文数との組み合わせを示す組み合わせ情報を商品ごとに記憶する記憶手段から取得する価格取得ステップと、
   　前記価格取得ステップにおいて取得された価格を、前記特定された商品に関連付けて出力する出力ステップと、
   　を含むことを特徴とする情報提供方法。
7. 　コンピュータを、
   　ユーザの要求に応じて特定された商品について該ユーザが注文を予定する数を取得する注文数取得手段、
   　前記注文数取得手段により取得された数と前記特定された商品のこれまでに注文された数との和に相当する注文数での販売が決定された場合の該商品の価格を、商品の価格と注文数との組み合わせを示す組み合わせ情報を商品ごとに記憶する記憶手段から取得する価格取得手段、及び、
   　前記価格取得手段により取得された価格を、前記特定された商品に関連付けて出力する出力手段、
   　として機能させることを特徴とする情報提供プログラム。
8. 　コンピュータを、
   　ユーザの要求に応じて特定された商品について該ユーザが注文を予定する数を取得する注文数取得手段、
   　前記注文数取得手段により取得された数と前記特定された商品のこれまでに注文された数との和に相当する注文数での販売が決定された場合の該商品の価格を、商品の価格と注文数との組み合わせを示す組み合わせ情報を商品ごとに記憶する記憶手段から取得する価格取得手段、及び、
   　前記価格取得手段により取得された価格を、前記特定された商品に関連付けて出力する出力手段、
   　として機能させる情報提供プログラムがコンピュータ読み取り可能に記録されていることを特徴とする記録媒体。

Images