JPWO2003038700A1 - 商品に係わる情報を通知する方法 - Google Patents

Abstract

サーバコンピュータ（１）は、ネットワーク上にショッピングサイトを構築している。ユーザは、ユーザ端末（２）を利用してショッピングサイトから所望の商品を購入することができる。ユーザが要求する商品が在庫切れであった場合は、サーバコンピュータ（１）は、そのユーザに対し、その商品を購入することについての要求レベルを問い合わせる。在庫切れだった商品が入荷したとき、サーバコンピュータ（１）は、要求レベルの高いユーザから順番に、入荷通知メールを送信する。入荷通知メールの内容は、要求レベルに応じて異なっている。

Description

技術分野
本発明は、通信ネットワークを利用して商品を販売するシステムにおいて、その商品に係わる情報をユーザに通知する方法に係わる。
背景技術
近年、通信ネットワーク上に構築したショッピングサイトを利用して商品を販売または提供するサービスが普及してきている。この種のサービスでは、通常、ユーザ（消費者、需要者）がパーソナルコンピュータ等の端末装置を利用してショッピングサイトにアクセスすると、そのサイトが提供する商品のカタログ等がユーザの端末装置に表示される。ここで、ユーザは、表示されたカタログを参照して所望の商品を注文することができる。そして、ショッピングサイトを運営している商品販売業者は、ユーザからの注文に従って対応する商品を指定された送り先に発送する。
ところで、商品販売業者は、しばしば、自己のショッピングサイトで取り扱っている商品を提供できなくなることがある。一例としては、在庫切れが発生した場合が考えられる。そして、既存のショッピングサイトでは、そのような商品（以下、「在庫切れ商品」と呼ぶことがある。）は、ショッピングサイトのカタログから削除されたり、あるいは、ショッピングカートに入れることが出来ないように設定される。
このとき、ユーザは、そのショッピングサイトからその在庫切れ商品を購入しようとした場合、その商品が入荷したか否かを確認するために、当該ショッピングサイトを繰り返し訪れる必要があり、煩わしさを感じる。一方、商品販売業者は、在庫切れ商品についてユーザからアクセスがあったとしても、それを販売に結び付けることができず、ビジネスチャンスを失う可能性がある。
この問題を解決する方法の１つとして、例えば、在庫切れだった商品が入荷したときに、その在庫切れの期間にその商品にアクセスしてきたユーザに対して、Ｅメールでその旨を通知するサービスが実施されている。しかし、このサービスでは、通知を受け取った多数のユーザが一斉にショッピングサイトを訪れると、商品が入荷した旨の通知をもらったにもかかわらず、その商品を購入できないという事態が発生することがあった。例えば、ある在庫切れ商品に対して１００人のユーザからアクセスがあったものとする。そして、商品販売業者がその商品を１０個だけ入手したとする。この場合、既存のサービスにおいては、在庫切れだった商品が入荷した旨の通知が上記１００人のユーザに対してＥメールで一斉に送られる。したがって、一部のユーザは、その通知によりその商品を購入できるが、他のユーザは、商品が入荷した旨の通知をもらったにもかかわらず、その商品を購入できなくなってしまう。
発明の開示
本発明は、通信ネットワークを利用して商品を販売するシステムにおいて、ユーザの利便性を向上させることを目的とする。
本発明の商品情報通知方法は、ユーザからの要求に応じて商品を提供するシステムにおいて、上記要求を受け付けるサーバコンピュータから上記ユーザに上記商品に係わる情報を通知する方法である。そして、上記サーバコンピュータが、ユーザから要求された商品を提供できない場合にそのユーザに対して上記商品の購入に係わる要求レベルを問い合わせ、上記ユーザから上記要求レベルを表す要求レベル情報を受信し、上記提供できなかった商品を提供できるようになったときに上記ユーザから受信した要求レベル情報に基づいて上記商品の提供に係わる商品提供情報を上記ユーザのユーザ端末に送信する。
この方法によれば、サーバコンピュータは、各ユーザの要求レベルに応じて商品提供情報を各ユーザに通知する。ここで、一般に、商品の購入に係わる要求レベルの高いユーザは、その商品を購入する可能性が高いものと思われる。したがって、ユーザからの要求レベルに応じて異なるタイミングで又は異なる内容の商品提供情報を通知するようにすれば、在庫数が十分でない商品を効率的に販売することができる。
上記方法において、上記サーバコンピュータは、複数のユーザから上記要求レベル情報を受信した場合には、要求レベルの高いユーザから順番に対応する商品提供情報を送信するようにしてもよい。この手順を導入すれば、要求レベルの高いユーザに対して当該商品を販売できる旨が優先的に通知されるので、その要求レベルの高いユーザがその商品を優先的に購入できる。
また、上記方法において、上記サーバコンピュータは、所定時間間隔ごとに所定の人数のユーザに対して、順番に商品提供情報を送信するようにしてもよい。この手順を導入すれば、商品提供情報を受け取った多数のユーザが一斉にその商品を注文することはない。よって、ユーザが商品を販売している旨の通知を受け取ったにもかかわらずその商品を購入できないといった事態は回避される。
本発明の他の態様の商品情報通知方法は、サーバコンピュータが、ユーザから要求された商品を提供できない場合にそのユーザに対して上記商品の購入に係わる要求レベルおよびそのユーザのユーザ端末のアドレスを問い合わせ、上記ユーザから上記要求レベルを表す要求レベル情報およびアドレスを受信し、受信した要求レベル情報およびアドレスを対応づけてデータベースに格納し、上記提供できなかった商品を提供できるようになったときに要求レベル情報に基づいて上記商品の提供に係わる商品提供情報を優先的に送信すべきアドレスを上記データベースから抽出し、抽出したアドレスへ対応する商品提供情報を送信する。なお、「ユーザ端末のアドレス」は、実施例ではメールアドレスに相当する。すなわち、このアドレスは、端末装置に固定的に割り当てられるわけではなく、任意の端末装置に設定されることが可能である。
発明を実施するための最良の形態
以下、本発明の実施形態について説明する。なお、本発明は、通信ネットワークを利用して商品を販売する商品販売システムにおいて、一時的に販売することができなかった商品を販売できるようになったときに、その旨をユーザに通知する方法に係わる。ここで、ある商品を一時的に販売できなくなる要因としては、主に、「在庫切れ」が想定される。したがって、ある商品を一時的に販売できなくなる要因は、「在庫切れ」に限定されるものではないが、以下では、一時的に販売できなくなっている商品のことを、「在庫切れ商品」と呼ぶことがある。
図１は、本発明が適用される商品販売システムの実施形態の構成図である。実施形態の商品販売システムは、ネットワーク上にショッピングサイトを提供するサーバコンピュータ１により実現される。なお、このショッピングサイトは、例えば、インターネット上に公開されるウェブページ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂサーバにより提供されるページ情報）により実現され、各種商品を販売する商品販売業者により運営されるものとする。
ユーザは、商品販売業者のショッピングサイトを利用して商品を購入する場合は、ユーザ端末２を利用してサーバコンピュータ１にアクセスする。そして、ユーザ端末２に表示される情報に従って所望の商品を注文することができる。なお、ユーザ端末２は、ネットワークを介してサーバコンピュータ１と情報を送受信する機能を有していれば特に限定されるものではないが、例えば、パーソナルコンピュータ、ＰＤＡ、携帯電話機などである。ここで、ユーザ端末２は、ウェブページを閲覧する機能を備えているものとする。また、ユーザ端末とユーザとの対応は、固定的ではなく、ユーザが使用する閲覧機能を備えた端末がユーザ端末となり得る。
インタフェース部１１は、所定の通信プロトコル（ＴＣＰ／ＩＰ、ＨＴＴＰなど）に対応するソフトウェアを実装しており、ネットワークに接続する回線を終端する。
商品管理ＤＢ１２は、商品販売業者が提供する商品に係わる情報を格納するデータベースである。具体的には、例えば、商品の仕様、販売価格、外観画像などが格納されている。カタログ作成部１３は、ユーザからの要求に応じて商品管理データベース１２から対応する情報を抽出し、その抽出した情報からその商品の商品カタログを作成する。そして、作成した商品カタログをユーザに送信する。
顧客管理ＤＢ１４は、ショッピングサイトの会員として登録されているユーザ（顧客）を管理するデータベースである。なお、会員は、例えば、一定の特典を受けることができる。在庫管理ＤＢ１５は、ショッピングサイトが取り扱う商品の在庫状態を管理するデータベースである。
注文処理部１６は、ユーザからの注文を受け付ける。また、決済部１７は、ユーザからの注文に対応する決済を実行する。なお、注文処理部１６および決済部１７は、基本的に、既存の技術により実現される。
管理部１８は、上述したデータベース１２、１４、１５を管理すると共に、カタログ作成部１３、注文処理部１６、決済部１７の動作を管理する。たとえば、ユーザからある商品のカタログを要求された場合は、在庫管理ＤＢ１５を参照してその商品の在庫状況をチェックし、その結果をカタログ作成部１３に渡す。これにより、カタログ作成部１３は、在庫状態に応じて商品カタログを編集することができる。或いは、注文処理部１６がユーザからある商品についての注文を受けた場合は、その注文に応じて在庫管理ＤＢ１５を更新する。
入荷通知メールＤＢ２１は、入荷通知メールの受信を希望するユーザを登録するデータベースである。ここで、入荷通知メールは、在庫切れ商品が入荷したことを通知するための電子メール、すなわち、一時的に販売できなかった商品を販売できるようになったことを通知するための電子メールである。メール条件ＤＢ２２は、入荷通知メールの送出に係わる情報を格納するデータベースである。なお、これらのデータベース２１、２２も、管理部１８により管理される。
次に、実施形態の商品販売システムの処理シーケンスを説明する。なお、商品販売業者は、ショッピングサイトを識別するためのＵＲＬを公開している。ここで、このＵＲＬは、不特定多数のユーザがアクセスに公開されており、以下では、「一般ＵＲＬ」と呼ぶことにする。
ユーザは、ショッピングサイトを訪れる際には、一般ＵＲＬを利用してサーバコンピュータ１にアクセスする。これにより、ユーザ端末２には、ショッピングサイトを利用して商品を購入するための情報が表示される。そして、ユーザが所望の商品を選択すると、その商品に関連する情報（商品カタログなど）がユーザ端末２に表示される。
図２Ａは、ユーザ端末２に表示される商品情報（商品カタログ）の一例である。ここでは、ユーザが指定した商品の商品情報として、その商品の外観画像、仕様、販売価格、納期などが表示されている。また、上記情報と共に、購入数量を入力するための領域、および当該商品を購入する旨を指示するボタン（購入指示ボタン：カートへ入れる）が表示されている。なお、この商品情報は、カタログ作成部１３により作成される。
ユーザは、ユーザ端末２に表示されている商品を購入する場合は、購入数量を入力すると共に、購入指示ボタンをクリックする。これにより、ユーザの要求（注文）がサーバコンピュータ１に伝えられる。
サーバコンピュータ１がユーザからの注文を受け付けると、注文処理部１６および決済部１７により対応する処理が実行される。この処理は、例えば、ユーザに発送先住所や支払い方法を問い合わせる処理、ユーザのクレジットカードを認証する処理、在庫管理ＤＢ１５を更新する処理などを含む。
ユーザがアクセスした商品が在庫切れであった場合は、ユーザ端末２には、図２Ｂに示すように、その商品を購入できない旨を表す情報が表示される。すなわち、図２Ｂに示す実施例では、「お届け期間」として「未定」が表示されており、購入数量を入力するための領域が表示されておらず、さらに、購入指示ボタンの代わりに入荷通知メールの要求を指示するボタン（通知要求ボタン：入荷お知らせメール）が表示されている。なお、この商品情報も、カタログ作成部１３により作成される。
ユーザは、ユーザ端末２に表示されている商品について入荷通知メールを希望する場合には、通知要求ボタンをクリックする。これにより、ユーザの要求がサーバコンピュータ１に伝えられる。そして、サーバコンピュータ１は、この要求を受信すると、ユーザに対して、そのユーザのメールアドレスを問い合わせる。
図３Ａは、ユーザにメールアドレスを問い合わせる画面の例であり、ユーザ端末２に表示される。ユーザは、入荷通知メールを申し込む場合には、自分のメールアドレスを入力すると共に、登録ボタンをクリックする。これにより、ユーザにより入力された情報がサーバコンピュータ１に伝えられる。そして、サーバコンピュータ１は、図３Ａに示す画面を利用して入力された情報を受信すると、そのユーザを入荷通知メールＤＢ２１に登録する。
図４は、入荷通知メールＤＢ２１の概略構成を模式的に示す図である。入荷通知メールＤＢ２１は、在庫切れ商品ごとに登録領域が確保される。そして、各在庫切れ商品ごとに、入荷通知メールを希望するユーザのメールアドレスが登録される。ここでは、図３Ａに示す画面を利用して入力されたユーザのメールアドレスが登録されている。また、このとき、メールアドレスが登録された日時が記録される。
サーバコンピュータ１は、入荷通知メールを希望するユーザのメールアドレスを入荷通知メールＤＢ２１に登録すると、完了メッセージをユーザ端末２に送信する。ユーザ端末２に表示される完了メッセージの例を図３Ｂに示す。
この後、在庫切れ商品が入荷すると、サーバコンピュータ１は、入荷通知メールを作成し、それを入荷通知メールＤＢ２１に登録されているメールアドレスへ送信する。入荷通知メールには、図３Ｃに示すように、登録者専用ＵＲＬが表示されている。ここで、登録者専用ＵＲＬは、一般ユーザには公開されないＵＲＬである。そして、サーバコンピュータ１は、一般ＵＲＬを利用してアクセスしてくるユーザよりも、登録者専用ＵＲＬを利用してアクセスしてくるユーザを優先して商品の注文を受け付ける。
なお、サーバコンピュータ１は、入荷通知メールＤＢ２１に登録されているすべてのメールアドレスへ一斉に入荷通知メールを送信するのではなく、所定時間間隔ごとに順番に所定数の入荷通知メールを送信する。或いは、入荷数量に対応する人数のユーザ（登録者）のみに対して入荷通知メールを送信するようにしてもよい。これらの場合、入荷通知メールの送信は、基本的には、入荷通知メールＤＢ２１に登録された順番に従って行われる。したがって、入荷通知メールを受けとったユーザからのアクセスが一時期に集中することが回避される。あるいは、入荷通知メールを受け取ったユーザからの注文数が入荷数量を越えることはなく、「入荷通知メールを受け取ったにもかかわらず商品を購入できない」という事態が回避される。
実施形態の商品販売システムは、ユーザによりアクセスされた商品が在庫切れであったときに、そのユーザからその商品の購入予約を受け付けることもできる。この場合、サーバコンピュータ１は、図２Ｂに示す画面において通知要求ボタンがクリックされときに、ユーザ端末２に、図３Ａに示した画面の代わりに、図５Ａに示す画面を表示する。
ユーザは、在庫切れ商品の購入を予約する場合には、図５Ａに示す画面において予約ボタンをクリックする。これにより、ユーザの要求（購入予約）がサーバコンピュータ１に伝えられる。そして、サーバコンピュータ１は、この要求を受信すると、ユーザ端末２に図５Ｂに示す画面を表示する。この画面は、ユーザに予約金の支払い方法を問い合わせるためのものである。
ユーザが、図５Ｂに示す画面を利用して予約金の支払い方法（クレジットの場合は、カード番号を含む）、及びユーザの連絡先（電話番号など）を入力し、「予約する」をクリックすると、サーバコンピュータ１は、これらの情報を受け取る。そして、サーバコンピュータ１は、これらの情報を入荷通知メールＤＢ２１に登録する。この場合の入荷通知メールＤＢ２１の例を図６に示す。この入荷通知メールＤＢ２１は、「申込み区分」を登録するためのフィールドが設けられている。「申込み区分」は、ユーザが購入予約を要求しているか、あるいは入荷通知メールのみを要求しているのかを表す。即ち、「申込み区分」は、商品の購入についてのユーザの要求レベルを表示する。この例では、サーバコンピュータ１は、「購入予約」を希望するユーザの要求レベルが、「入荷通知メールのみ」を希望するユーザの要求レベルよりも高いものと判断する。
サーバコンピュータ１は、購入予約を申し込んだユーザを入荷通知メールＤＢ２１に登録する際、その予約に対して予約番号を割り当てる。そして、その予約番号は、図５Ｃに示すように、ユーザ端末２に表示される
この後、在庫切れだった商品が入荷すると、サーバコンピュータ１は、入荷通知メールを作成し、それを入荷通知メールＤＢ２１に登録されているメールアドレスへ送信する。入荷通知メールは、購入予約を申し込んだユーザ（予約者）に対して送信される場合と、通知のみを要求するユーザ（登録者）に送信する場合とで、基本的に同じものであってもよい。ただし、登録者に対して送信される入荷通知メールでは登録者専用ＵＲＬが表示されるが、予約者に対して送信される入荷通知メールでは予約者専用ＵＲＬが表示される。なお、登録者専用ＵＲＬおよび予約者専用ＵＲＬは、この実施例では互いに異なっているが、互いに同じであってもよい。もっとも、登録者専用ＵＲＬおよび予約者専用ＵＲＬは、一般ＵＲＬとは異なっている必要がある。
なお、サーバコンピュータ１は、商品が入荷したときに、まず、予約者に対して入荷通知メールを送信し、その予約者から優先的に注文を受け付ける。そして、すべての予約者が注文を済ませた後、あるいは予め決められている予約有効期間が経過した後、登録者に対して入荷通知メールを送信する。この場合、入荷通知メールをすべての登録者に対して一斉に送信するのではなく、上述したように、所定時間間隔ごとに所定数の入荷通知メールが順番に送信されていく。
このように、実施形態の商品販売システムでは、在庫切れだった商品を販売できるようになったときに、まず、要求レベル高いユーザ（予約者）に入荷通知メールが送信され、その後、要求レベルの低いユーザ（登録者）に対して入荷通知メールが送られる。したがって、要求レベルの高いユーザは、他のユーザよりも早く、且つ確実に、商品を購入することができる。
また、在庫切れだった商品が入荷したときには、上述のように、予約者および／または登録者に入荷通知メールが送信され、専用ＵＲＬが通知される。このとき、サーバコンピュータ１は、専用ＵＲＬを利用してアクセスしてきたユーザからの注文は受け付けるが、一般ＵＲＬを利用してアクセスしてきたユーザからの注文は受け付けない。すなわち、予約者および／または登録者からの注文を受け付ける期間は、在庫がある場合であっても、一般ＵＲＬを利用してアクセスするユーザのユーザ端末２には、「在庫切れ」である旨が表示されることになる。
図７Ａは、入荷通知メールＤＢ２１の実施例である。「メールアドレス」は、在庫切れ商品の購入予約を申し込んだユーザ、または入荷通知メールを要求するユーザのメールアドレスである。「配信区分」は、自動配信または手動配信を識別する情報であり、通常は、「自動」が設定される。「手動」は、例えば、ユーザに対して例外的な通知を行う必要がある場合などに設定される。例外的な通知とは、例えば、当該商品の生産が中止され、代替商品を紹介する場合などが想定される。
「型名」は、商品の型名または名称である。「申込み日時」は、ユーザが入荷通知（購入予約を含む）を申し込んだ日時である。「申込み区分」は、ユーザの要求が、「購入予約」または「入荷通知メールのみ」のいずれであるのかを識別する。「申込みレベル」は、ユーザの商品購入に係わる要求レベルを表示する。なお、この実施例では、要求レベルは、「１：購入予約」および「２：入荷通知のみ」の２つのみであるが、３以上の要求レベルが設定されてもよい。
「メール配信番号」は、各レコードをサーバコンピュータ１の内部で管理するためのシリアル番号である。「販売コード」は、ユーザが特定の団体に属するか否かを表示する。なお、実施形態の商品販売システムは、特定の団体に属するユーザに対して何らかの特典（例えば、ディスカウント）を提供することができる。
「予約番号（注文番号）」は、各購入予約に対して一意に割り当てられる識別番号である。「購入フラグ」は、入荷通知メールを受信したユーザが、当該商品を購入したか否かを表示する。「登録完了送信日時」は、入荷通知メールＤＢ２１への登録が完了したことを通知する完了メールを送信した日時を表す。「通知メール送信日時」は、入荷通知メールを送信した日時を表す。「削除フラグ」は、当該レコードを削除すべきか否かを表示する。
図７Ｂは、メール条件ＤＢ２２の実施例である。「配信間隔」は、所定数のユーザごとに入荷通知メールを送信する際に、その送信間隔を指定する。「一括配信数」は、入荷通知メールを送信すべきユーザ数を指定する。「予約有効期間」は、予約者からの注文を受け付ける期間であって、予約者に対して入荷通知メールを送信した時から起算される。「優先販売期間」は、登録者からの注文を受け付ける期間であって、登録者に対して入荷通知メールを送信した時から起算される。
次に、フローチャートを参照しながら、サーバコンピュータ１の動作を説明する。具体的には、実施形態の商品販売システムにおいて、ユーザからのアクセスがあったときのシーケンス、予約者および／または登録者へ入荷通知メールを送信するシーケンス、予約者および／または登録者からのアクセスを受け付ける際のシーケンスを説明する。
図８は、サーバコンピュータ１がユーザからのアクセスを受け付けたときの処理を示す図である。ここでは、ユーザがユーザ端末２を利用してショッピングサイトを訪れたものとする。なお、この処理は、ユーザがある商品の商品情報を要求したときに実行される。
ステップＳ１では、ユーザからの要求を受信する。なお、この要求は、ユーザがユーザ端末２を利用して所望の商品を指定することにより生成され、ネットワークを介してサーバコンピュータ１に伝送される。
ステップＳ２では、上記表示要求が、一般ＵＲＬを利用したアクセスであるか否かを調べる。そして、一般ＵＲＬを利用したアクセスであればステップＳ３以降の処理が実行され、そうでない場合には、ステップＳ１１において対応する専用処理が実行される。なお、ステップＳ１１の専用処理は、後で詳しく説明するが、専用ＵＲＬを利用したアクセスがあったときに実行される。
ステップＳ３およびＳ４では、ユーザにより指定された商品の在庫があるか否かを調べるために、在庫管理ＤＢ１５を参照する。このとき、在庫数量は、例えば、実際に確保してある数量（確実に入荷する予定の数量を含む）から販売先が決定している数量を減じた値である。ここで、入力通知メールＤＢ２１に登録されているユーザが予約している数量は、販売先が決定している数量に含まれるものとする。
在庫がある場合は、ステップＳ５において、ユーザから要求された商品の商品カタログを作成する。このとき、この商品カタログには、図２Ａに示すように、購入指示（カートに入れる）ボタンが設けられている。そして、その購入指示ボタンを含む商品カタログは、ユーザ端末２に送信される。これにより、ユーザ端末２には、ユーザが指定した商品の商品カタログおよび購入指示ボタンが表示される。そして、ステップＳ６において、商品販売に係わる標準処理が実行される。なお、標準処理は、ユーザとの対話により商品の注文を受け付ける処理であり、既存の技術により実現される。
ステップＳ７では、ステップＳ５と同様に、ユーザから要求された商品の商品カタログを作成する。ただし、ステップＳ７で作成する商品カタログには、図２Ｂに示すように、通知要求（入荷お知らせメール）ボタンが設けられている。したがって、ユーザ端末２には、ユーザが指定した商品の商品カタログおよび通知要求ボタンが表示される。
ステップＳ８では、ユーザとの対話処理が行われる。具体的には、例えば、ユーザに入荷通知を希望するか否かを問い合わせる処理、ユーザにメールアドレスを問い合わせる処理、それらの問合せに対するユーザからの回答を受信する処理などが実行される。なお、ユーザは、入荷通知を希望する場合には、図３Ａまたは図５Ａに示す画面を利用してメールアドレスを入力すると共に、「予約」または「登録」を選択する。
ステップＳ９では、ステップＳ８においてユーザから受信した情報を入荷通知メールＤＢ２１に登録する。具体的には、ユーザから受信した情報に従って「メールアドレス」および「申込み区分」が登録され、「申込み日時」が記録される。そして、登録作業が完了すると、ステップＳ１０において、ユーザに対して完了メールを送信する。このとき、入力通知メールＤＢ２１の「登録完了送信日時」が記録される。
このように、サーバコンピュータ１は、一般ＵＲＬを利用してアクセスされた商品が在庫切れであったときは、ユーザに対して、入荷通知メールの送信を希望するか否かを問い合わる。そして、そのユーザが入荷通知を希望する場合は、そのユーザを入荷通知メールＤＢ２１に登録する。
図９は、サーバコンピュータ１が入荷通知メールを送信する処理を示すフローチャートである。この処理は、例えばタイマ割込みにより、定期的に実行される。また、この処理は、入荷通知メールＤＢ２１に登録されている各商品、すなわち在庫切れとなっている各商品について実行される。
ステップＳ２１では、商品を販売できるか否かを調べる。すなわち、在庫切れだった商品が入荷したか否かを調べる。なお、この処理は、具体的には、在庫管理ＤＢ１５を参照し、当該商品の在庫数量を検出することにより実現される。そして、当該商品を販売できる場合はステップＳ２２〜Ｓ２８を実行し、販売できない場合はそれらのステップをスキップする。
ステップＳ２２およびＳ２３では、入荷通知メールを受信していない予約者が存在しているか否かを調べる。この処理は、入荷通知メールＤＢ２１において、「申込み区分」として「予約」が設定されており、且つ、「通知メール送信日時」が記録されていないレコードをサーチすることにより実現される。そして、入荷通知メールを受信していない予約者が存在する場合は、ステップＳ２４において、それらの予約者に対してそれぞれ入荷通知メールを送信する。なお、各予約者は、この入荷通知メールにより予約者専用ＵＲＬが通知される。また、このとき、入荷通知メールＤＢ２１において、対応するレコードの「通知メール送信日時」がそれぞれ記録される。
ステップＳ２５では、予約者専用ページを開設する。ここで、予約者専用ページは、予約者専用ＵＲＬにより識別されるサイトである。すなわち、このページは、予約者のみからの注文を受け付けるサイトである。なお、予約者専用ページが既に開設されている場合は、この処理はスキップされる。
入荷通知メールを受信していない予約者が存在しない場合（すべての予約者に対して入荷通知メールを送信済みの場合、或いは予約者がいない場合）は、ステップＳ２６において、入荷通知メールを受信していない登録者が存在するか否かを調べる。ここで、「登録者」とは、商品購入の予約をすることなく、入荷通知のみを希望するユーザを意味する。また、この処理は、入荷通知メールＤＢ２１において、「申込み区分」として「通知のみ」が設定されており、且つ「通知メール送信日時」が記録されていないレコードをサーチすることにより実現される。そして、入荷通知メールを受信していない登録者が存在する場合は、ステップＳ２７において、各登録者に対してそれぞれ入荷通知メールを送信する。なお、各登録者は、この入荷通知メールにより登録者専用ＵＲＬが通知される。また、このとき、入荷通知メールＤＢ２１において、対応するレコードの「通知メール送信日時」がそれぞれ記録される。
ステップＳ２８では、登録者専用ページを開設する。ここで、登録者専用ページは、登録者専用ＵＲＬにより識別されるサイトである。すなわち、このページは、登録者のみからの注文を受け付けるサイトである。なお、登録者専用ページが既に開設されている場合は、この処理はスキップされる。
ステップＳ２９は、予約有効期間が満了したときに予約者専用ページを終了し、優先販売期間が満了したときに登録者専用ページを終了する。なお、この処理については、後で詳しく説明する。
このように、サーバコンピュータ１は、在庫切れだった商品を販売できるようになったときに、予約者がいる場合には、各予約者に対して入荷通知メールを送信する。そして、すべての予約者に対して入荷通知メールを送信した後、登録者に対して入荷通知メールを送信する。すなわち、要求レベルの高いユーザに対して優先的に入荷通知メールが送られる。
図１０は、サーバコンピュータ１が予約者に対して入荷通知メールを送信する処理を示すフローチャートである。なお、この処理は、図９のステップＳ２４に相当する。また、ここでは、各予約者は、それぞれ商品を１個ずつ予約しているものとする。
ステップＳ３１では、商品の入荷数量と、入荷通知メールを受信していない予約者の人数とを比較する。ここで、商品の入荷数は、在庫管理ＤＢ１５を参照することにより検出される。また、入荷通知メールを受信していない予約者の人数は、入荷通知メールＤＢ２１において、「申込み区分」として「予約」が設定されており、且つ、「通知メール送信日時」が記録されていないレコードををサーチすることにより検出される。
商品の入荷数量が入荷通知メールを受信していない予約者の人数よりも多かった場合は、ステップＳ３２において、それらの全ての予約者に対して入荷通知メールを送信する。一方、商品の入荷数量が入荷通知メールを受信していない予約者の人数よりも少なかった場合は、ステップＳ３３において、商品の入荷数量に対応する人数の予約者を選択する。このとき、予約者の選択は、購入予約を申し込んだ順番（すなわち、登録順）に従う。そして、ステップＳ３４において、選択した予約者に対してそれぞれ入荷通知メールを送信する。
ステップＳ３５では、入荷通知メールＤＢ２１を更新する。具体的には、ステップＳ３２またはＳ３４の処理により入荷通知メールを受信するユーザに対応するレコードの「通知メール送信日時」を記録する。
このように、サーバコンピュータ１は、商品の入荷数量が予約者からの注文数よりも少なかった場合には、全予約者の中から購入予約を申し込んだ順番に所定数の予約者を選択し、その選択した予約者のみに対して入荷通知メールを送信する。
図１１は、サーバコンピュータ１が登録者に対して入荷通知メールを送信する処理を示すフローチャートである。なお、この処理は、図９のステップＳ２７に相当する。
ステップＳ４１では、入荷通知メールＤＢ２１に登録されている登録者の中から登録順に所定数の登録者を選択し、選択した各登録者に対して入荷通知メールを送信する。ここで、選択すべき登録者の人数は、メール条件ＤＢ２２に設定されている「一括配信数」に従う。続いて、ステップＳ４２では、入荷通知メールＤＢ２１を更新する。すなわち、ステップＳ４１の処理により入荷通知メールを受信するユーザに対応するレコードの「通知メール送信日時」を記録する。
ステップＳ４３では、入荷通知メールを受信していない登録者が残っているか否かを調べる。この処理は、入荷通知メールＤＢ２１において「申込み区分」として「通知のみ」が設定されており、且つ、「通知メール送信日時」が記録されていないレコードをサーチすることにより実現される。そして、すべての登録者が入荷通知メールを受信している場合には、処理を終了する。一方、入荷通知メールを受信していない登録者が残っている場合には、ステップＳ４４およびＳ４５において所定時間を計時した後、ステップＳ４１に戻って送信処理を実行する。なお、ステップＳ４４およびＳ４５において計時される時間は、メール条件ＤＢ２２に設定されている「配信間隔」に従う。
このように、サーバコンピュータ１は、所定時間間隔ごとに所定数の登録者に対して登録順に入荷通知メールを送信する。
図１２は、専用ＵＲＬを利用してアクセスされたサーバコンピュータ１の動作を示すフローチャートである。なお、この処理は、図８のステップＳ１１に相当する。
ステップＳ５１およびＳ５７では、ユーザからのアクセスが予約者専用ＵＲＬを利用したアクセスであるか、あるいは登録者専用ＵＲＬを利用したアクセスであるのかを調べる。そして、予約者専用ＵＲＬを利用したアクセスであれば、ステップＳ５２において、予約有効期間が終了しているか否かを調べる。ここで、予約有効期間は、メール条件ＤＢ２２に設定されており、予約者に対して入荷通知メールを送信したときから起算される。
予約有効期間が終了していなければ、ステップＳ５３において、予約者用注文書を作成する。予約者用注文書は、図１３に示すように、ユーザが予約番号などを入力するためのボックスを含んでおり、また、購入数量を入力するためのボックスには、先に予約してある数量が予め書き込まれている。つづいて、ステップＳ５４では、作成した予約者用注文書を対応するユーザ端末２に送信し、ユーザからの注文を受け付ける。なお、予約者用注文書を受け取ったユーザは、当該商品を実際に購入する場合には、購入指示ボタンをクリックすると共に、先に通知されている予約番号などを入力する。
ステップＳ５５およびＳ５６では、ユーザ認証処理を実行する。このユーザ認証処理では、ユーザにより入力された予約番号と、そのユーザに先に割り当ててある予約番号とが一致するか否かがチェックされる。そして、当該ユーザが正規の予約者であった場合には、ステップＳ６１において決済処理を実行する。さらに、ステップＳ６２において、入荷通知メールＤＢ２１を更新する。この場合、対応するレコードの「購入フラグ」として「購入済み」が書き込まれる。
一方、登録者専用ＵＲＬを利用したアクセスであれば、ステップＳ５８において、優先販売期間が終了しているか否かを調べる。なお、優先販売期間は、メール条件ＤＢ２２に設定されており、登録者に対して入荷通知メールを送信したときから起算される。
優先販売期間が終了していなければ、ステップＳ５９において、登録者用注文書を作成する。登録者用注文書は、基本的には上述の予約者用注文書と同じであるが、予約番号等を入力するためのボックスは設けられておらず、また、購入数量を入力するためのボックスには何も書き込まれていない。つづいて、ステップＳ６０では、作成した登録者用注文書を対応するユーザ端末２に送信し、ユーザからの注文を受け付ける。なお、ユーザ（登録者）からの注文を受信した場合は、予約者からの注文を受信した場合と同様に、ステップＳ６１およびＳ６２が実行される。
予約有効期間が終了していた場合、優先販売期間が終了していた場合、およびユーザ認証に失敗した場合には、ステップＳ６３において対応するエラー処理が実行される。また、一般ＵＲＬ、予約者専用ＵＲＬ、登録者専用ＵＲＬを利用しないアクセスを検出した場合には、ステップＳ６４において、そのアクセスに対応する処理が実行される。
なお、予約者専用ＵＲＬを用いて予約者に商品を販売する期間（予約有効期間）、および登録者専用ＵＲＬを用いて登録者に商品を販売する期間（優先販売期間）は、基本的に、一般ユーザにはその商品を販売しない。すなわち、これらの期間は、一般ＵＲＬを利用してショッピングサイトを訪れると、ユーザ端末２には、その商品が在庫切れである旨が表示される。
図１４は、サーバコンピュータ１が専用ページを終了する処理を示すフローチャートである。なお、この処理は、図９のステップＳ２９に相当する。
ステップＳ７１では、予約者専用ページが開いているか否かを調べる。そして、予約者専用ページが開いている場合は、ステップＳ７２において、すべての予約者が商品を購入済みであるか否かを調べる。この処理は、入荷通知メールＤＢ２１において、「申込み区分」として「予約」が設定されており、且つ、「購入フラグ」として「未購入」が設定されているレコードをサーチすることにより実現される。また、ステップＳ７３では、予約有効期間が終了しているか否かを調べる。この処理は、予約者に入荷通知メールを送信した時点からの経過時間が、メール条件ＤＢ２２に設定されている予約有効期間を越えているか否かを調べることにより実現される。
全ての予約者が商品を購入済みの場合、あるいは予約有効期間が終了している場合は、ステップＳ７４において予約専用ページを終了する。これにより、以降、予約者専用ＵＲＬを利用したアクセスは拒否されることになる。
ステップＳ７５では、登録者専用ページが開いているか否かを調べる。そして、登録者専用ページが開いている場合は、ステップＳ７６において、優先販売期間が終了しているか否かを調べる。この処理は、登録者に入荷通知メールを送信した時点からの経過時間が、メール条件ＤＢ２２に設定されている優先販売期間を越えているか否かを調べることにより実現される。そして、優先販売期間が終了している場合は、ステップＳ７７において登録専用ページを終了する。これにより、以降、登録者専用ＵＲＬを利用したアクセスは拒否されることになる。
このように、サーバコンピュータ１は、一時的に販売できなかった商品を販売できるようになったときに、入荷通知メールを申し込んでいたユーザに対してその商品を優先的に販売する。また、サーバコンピュータ１は、各ユーザが入荷通知メールを申し込む際、当該商品の購入についての要求レベルを問い合わせる。そして、サーバコンピュータ１は、要求レベルの高いユーザから順番に入荷通知メールを送信していくことにより、要求レベルの高いユーザから順番に注文を受け付ける。
なお、上述の実施例では、サーバコンピュータ１は、ユーザに対して２つの要求レベル（購入予約、通知のみ）を提供しているが、３以上の要求レベルを提供してもよい。５つの要求レベルを提供する場合の実施例を下記に示す。
レベル１：購入予約（予約金＝５０００円）
レベル２：購入予約（予約金＝１０００円）
レベル３：購入予約（予約金なし）
レベル４：通知のみ（期限付き（例えば、１週間以内に入荷した場合にのみ通知））
レベル５：通知のみ（期限なし）
この場合、サーバコンピュータ１は、要求レベルを選択するための画面をユーザ端末２に表示する。そして、ユーザがユーザ端末２を利用して所望の要求レベルを選択すると、サーバコンピュータ１は、その選択された要求レベルを検出する。
図１５は、サーバコンピュータ１が入荷通知メールを送信する処理の汎用フローチャートである。ここでは、在庫切れだった商品がＮ個だけ入荷した場合を想定する。また、要求レベル１〜Ｋが提供されており、「Ｌ（ｉ）」は、要求レベルｉのユーザの人数を表すものとする。更に、説明を簡単にするために、各ユーザごとの予約数量は、それぞれ１個であるものとする。
ステップＳ８１では、「在庫数量Ｚ」として「Ｎ」が設定される。ステップＳ８２では、「要求レベルｉ」の初期値として「１」が設定される。ステップＳ８３では、在庫数量Ｚと要求レベルｉのユーザの人数Ｌ（ｉ）とが比較される。そして、「Ｚ≧Ｌ（ｉ）」であれば、ステップＳ８４において、要求レベルｉの全てのユーザに対して入荷通知メールが送信される。
ステップＳ８５では、要求レベルｉよりも低い要求レベルのユーザが存在するか否かが調べられる。要求レベルｉよりも低い要求レベルのユーザが存在する場合は、ステップＳ８６において「ｉ」がインクリメントされる。そして、ステップＳ８７において在庫数量Ｚを更新した後、ステップＳ８３に戻って次の要求レベルについて同様の処理を実行する。
一方、在庫数量Ｚよりも要求レベルｉのユーザの人数Ｌ（ｉ）の方が多かった場合は、ステップＳ８８において、要求レベルｉのユーザの中から登録順にＺ人のユーザが選択される。そして、ステップＳ８９において、選択された各ユーザに対してそれぞれ入荷通知メールが送信される。
このように、サーバコンピュータ１は、在庫切れだった商品を販売できるようになったときには、要求レベルの高いユーザからの順番に入荷通知メールを送信する。このとき、一度に送信されるメールの数を抑えているので、サーバコンピュータの処理負荷、およびネットワークのトラヒックの増大を抑えることができる。
なお、サーバコンピュータ１は、ユーザに入荷通知メールの要否を問い合わせる際、そのユーザに対してアンケートを送るようにしてもよい。ここで、このアンケートは、ユーザが付加情報を入力するための画面をユーザ端末２に表示することにより実現される。また、ユーザにより入力される付加情報は、特に限定されるものではないが、例えば、希望納期や購入予定数量などを想定する。この場合、商品販売業者は、各ユーザからアンケートの回答を収集して分析することにより、確保すべき商品の数量を決定する際の参考データを得ることができる。
また、上述の実施例では、要求レベルの高いユーザから順番に入荷通知メールを受信できるようになっているが、要求レベルの高いユーザに対して他の特典を提供するようにしてもよい。例えば、要求レベルの高いユーザに対する販売価格をディスカウントするようにしてもよい。
図１６は、サーバコンピュータ１およびユーザ端末２のハードウェア構成図である。
ＣＰＵ１０１は、所定のプログラムをメモリ１０３へロードして実行する。ここで、サーバコンピュータ１においては、上述したフローチャートの手順を記述したプログラムが実行される。また、ユーザ端末２においては、例えば、ウェブページを閲覧するためのブラウザプログラム、およびメールを送受信するためのメーラプログラムなどが実行される。
記憶装置１０２は、例えばハードディスクであり、上述のプログラムを格納する。メモリ１０３は、例えば半導体メモリであり、ＣＰＵ１０１の作業領域として使用される。
記録媒体ドライバ１０４は、ＣＰＵ１０１の指示に従って可搬性記録媒体１０５にアクセスする。可搬性記録媒体１０５は、例えば、半導体デバイス（ＰＣカード、メモリスティックなど）、磁気的作用によりデータが入出力される媒体（フレキシブルディスク、磁気テープなど）、光学的作用によりデータが入出力される媒体（光ディスクなど）を含む。
通信制御装置１０６は、ネットワークに信号を送出し、ネットワークから信号を受信するインタフェースを提供する。表示装置１０７は、ＣＰＵ１０１の指示に従って、各種データを表示する。入力装置１０８は、ユーザの指示をＣＰＵ１０１に通知する。なお、サーバコンピュータ１は、必ずしも表示装置１０７を備えている必要はない。また、ユーザ端末２は、必ずしも記録媒体ドライバ１０４を備えている必要はない。
また、本発明に係わるソフトウェアプログラムは、例えば、以下の３つの方法の中の任意の方法により提供される。
方法Ａ：サーバコンピュータ１に予めインストールされて提供される。この場合、これらのプログラムは、サーバコンピュータ１の出荷前に記憶装置１０２に書き込まれる。
方法Ｂ：可搬性記録媒体に格納されて提供される。この場合、可搬性記録媒体１０５に格納されるプログラムは、基本的に、記録媒体ドライバ１０４を介して記憶装置１０２にインストールされる。
方法Ｃ：プログラムサーバ装置からネットワークを介して提供される。この場合、サーバコンピュータ１は、プログラムサーバ装置に格納されているプログラムをダウンロードすることによりそれを取得する。
産業上の利用可能性
本発明は、電子商取引またはＥコマースの分野において有用である。
【図面の簡単な説明】
図１は、本発明が適用される商品販売システムの実施形態の構成図である。
図２Ａおよび図２Ｂは、ユーザ端末に表示される商品情報の例である。
図３Ａは、ユーザにメールアドレスを問い合わせる画面の例である。
図３Ｂは、完了メッセージの例である。
図３Ｃは、入荷通知メールの例である。
図４は、入荷通知メールＤＢの概略構成を模式的に示す図である。
図５Ａは、ユーザにユーザアドレスを問い合わせる画面の例である。
図５Ｂは、予約の申込みのための画面の例である。
図５Ｃは、予約番号を通知するための画面の例である。
図６は、入荷通知メールＤＢの例である。
図７Ａは、入荷通知メールＤＢが管理する項目の実施例である。
図７Ｂは、メール条件ＤＢが管理する項目の実施例である。
図８は、サーバコンピュータがユーザからのアクセスを受け付けたときの処理を示すフローチャートである。
図９は、サーバコンピュータが入荷通知メールを送信する処理を示すフローチャートである。
図１０は、サーバコンピュータが予約者に対して入荷通知メールを送信する処理を示すフローチャートである。
図１１は、サーバコンピュータが登録者に対して入荷通知メールを送信する処理を示すフローチャートである。
図１２は、専用ＵＲＬを利用してアクセスされたサーバコンピュータの動作を示すフローチャートである。
図１３は、予約者用注文書の一例である。
図１４は、サーバコンピュータが専用ページを終了する処理を示すフローチャートである。
図１５は、サーバコンピュータが入荷通知メールを送信する処理の汎用フローチャートである。
図１６は、サーバコンピュータおよびユーザ端末のハードウェア構成図である。

Claims (14)

1. ユーザからの要求に応じて商品を提供するシステムにおいて、上記要求を受け付けるサーバコンピュータから上記ユーザに上記商品に係わる情報を通知する方法であって、
   上記サーバコンピュータが、
   ユーザから要求された商品を提供できない場合に、そのユーザに対して上記商品の購入に係わる要求レベルを問い合わせ、
   上記ユーザから上記要求レベルを表す要求レベル情報を受信し、
   上記提供できなかった商品を提供できるようになったときに、上記ユーザから受信した要求レベル情報に基づいて上記商品の提供に係わる商品提供情報を上記ユーザのユーザ端末に送信する
   を特徴とする商品情報通知方法。
2. 請求項１に記載の方法であって、
   上記サーバコンピュータは、要求レベルごとにそれぞれ対応する商品提供情報を作成する。
3. 請求項１に記載の方法であって、
   上記サーバコンピュータは、複数のユーザから上記要求レベル情報を受信した場合には、要求レベルの高いユーザから順番に対応する商品提供情報を送信する。
4. 請求項３に記載の方法であって、
   上記サーバコンピュータは、要求レベルの高いユーザから順番に、上記商品を提供することができる数量に基づいて決まる人数のユーザに対して対応する商品提供情報を通知する。
5. 請求項３に記載の方法であって、
   上記サーバコンピュータは、所定時間間隔ごとに所定の人数のユーザに対して、順番に商品提供情報を送信する。
6. ユーザからの要求に応じて商品を提供するシステムにおいて、上記要求を受け付けるサーバコンピュータから上記ユーザに上記商品に係わる情報を通知する方法であって、
   上記サーバコンピュータが、
   ユーザから要求された商品を提供できない場合に、そのユーザに対して上記商品の購入に係わる要求レベルおよびそのユーザのユーザ端末のアドレスを問い合わせ、
   上記ユーザから上記要求レベルを表す要求レベル情報およびアドレスを受信し、
   受信した要求レベル情報およびアドレスを対応づけてデータベースに格納し、
   上記提供できなかった商品を提供できるようになったときに、要求レベル情報に基づいて、上記商品の提供に係わる商品提供情報を優先的に送信すべきアドレスを上記データベースから抽出し、
   抽出したアドレスへ対応する商品提供情報を送信する
   を特徴とする商品情報通知方法。
7. ユーザからの要求に応じて商品を提供するシステムにおいて、上記要求を受け付けるサーバコンピュータから上記ユーザに上記商品に係わる情報を通知する方法であって、
   上記サーバコンピュータが、
   ユーザから要求された商品を提供できない場合に、そのユーザに対して上記商品の購入に係わる要求レベルおよびそのユーザのユーザ端末のアドレスを問い合わせ、
   上記ユーザから上記要求レベルを表す要求レベル情報およびアドレスを受信し、
   受信した要求レベル情報およびアドレスを対応づけてデータベースに格納し、
   上記データベースに格納されているアドレスを要求レベル情報に基づいて複数のグループに分割し、
   上記提供できなかった商品を提供できるようになったときに、上記グループ毎に、互いに異なるタイミングで、各アドレスへ対応する商品提供情報を送信する
   を特徴とする商品情報通知方法。
8. ネットワークを介して注文を受け付けるサーバコンピュータを用いて商品を販売する商品販売方法であって、
   上記サーバコンピュータが、
   ユーザから要求された商品を販売できない場合に、そのユーザに対してそのユーザのメールアドレスを問い合わせ、
   上記販売できなかった商品を販売できるようになったときに、上記ユーザのメールアドレスに上記商品の販売が再開されたことを通知するメールを送信し、
   上記メールを送信したときから所定の期間、上記ユーザに対して優先的に上記商品を販売する
   を特徴とする商品販売方法。
9. ユーザから要求された商品を販売するサーバ装置であって、
   ユーザから要求された商品を提供できない場合に、そのユーザに対して上記商品の購入に係わる要求レベルを問い合わせる問合せ手段と、
   上記ユーザから上記要求レベルを表す要求レベル情報を受信する受信手段と、
   上記提供できなかった商品を提供できるようになったときに、上記ユーザから受信した要求レベル情報に基づいて上記商品の提供に係わる商品提供情報を上記ユーザのユーザ端末に送信する送信手段と
   を有するサーバ装置。
10. ユーザから要求された商品を販売するサーバ装置であって、
    ユーザから要求された商品を提供できない場合に、そのユーザに対して上記商品の購入に係わる要求レベルおよびそのユーザのユーザ端末のアドレスを問い合わせる問合せ手段と、
    上記ユーザから上記要求レベルを表す要求レベル情報およびアドレスを受信する受信手段と、
    受信した要求レベル情報およびアドレスを対応づけてデータベースに格納する格納手段と、
    上記提供できなかった商品を提供できるようになったときに、要求レベル情報に基づいて、上記商品の提供に係わる商品提供情報を優先的に送信すべきアドレスを上記データベースから抽出する抽出手段と、
    抽出したアドレスへ対応する商品提供情報を送信する送信手段と
    を有するサーバ装置。
11. 商品販売システムにおいて、ユーザに商品に係わる情報を通知するために、コンピュータを、
    ユーザから要求された商品を提供できない場合に、そのユーザに対して上記商品の購入に係わる要求レベルを問い合わせる問合せ手段、
    上記ユーザから上記要求レベルを表す要求レベル情報を受信する受信手段、
    上記提供できなかった商品を提供できるようになったときに、上記ユーザから受信した要求レベル情報に基づいて上記商品の提供に係わる商品提供情報を上記ユーザのユーザ端末に送信する送信手段
    として機能させるプログラム。
12. 商品販売システムにおいて、ユーザに商品に係わる情報を通知するために、コンピュータを、
    ユーザから要求された商品を提供できない場合に、そのユーザに対して上記商品の購入に係わる要求レベルおよびそのユーザのユーザ端末のアドレスを問い合わせる問合せ手段、
    上記ユーザから上記要求レベルを表す要求レベル情報およびアドレスを受信する受信手段、
    受信した要求レベル情報およびアドレスを対応づけてデータベースに格納する格納手段、
    上記提供できなかった商品を提供できるようになったときに、要求レベル情報に基づいて、上記商品の提供に係わる商品提供情報を優先的に送信すべきアドレスを上記データベースから抽出する抽出手段、
    抽出したアドレスへ対応する商品提供情報を送信する送信手段
    として機能させるプログラム。
13. 商品販売システムにおいて、ユーザに商品に係わる情報を通知するために、コンピュータを、
    ユーザから要求された商品を提供できない場合に、そのユーザに対して上記商品の購入に係わる要求レベルを問い合わせる問合せ手段、
    上記ユーザから上記要求レベルを表す要求レベル情報を受信する受信手段、
    上記提供できなかった商品を提供できるようになったときに、上記ユーザから受信した要求レベル情報に基づいて上記商品の提供に係わる商品提供情報を上記ユーザのユーザ端末に送信する送信手段
    として機能させるプログラムを記録した記録媒体。
14. 商品販売システムにおいて、ユーザに商品に係わる情報を通知するために、コンピュータを、
    ユーザから要求された商品を提供できない場合に、そのユーザに対して上記商品の購入に係わる要求レベルおよびそのユーザのユーザ端末のアドレスを問い合わせる問合せ手段、
    上記ユーザから上記要求レベルを表す要求レベル情報およびアドレスを受信する受信手段、
    受信した要求レベル情報およびアドレスを対応づけてデータベースに格納する格納手段、
    上記提供できなかった商品を提供できるようになったときに、要求レベル情報に基づいて、上記商品の提供に係わる商品提供情報を優先的に送信すべきアドレスを上記データベースから抽出する抽出手段、
    抽出したアドレスへ対応する商品提供情報を送信する送信手段
    として機能させるプログラムを記録した記録媒体。

Images