(57)【特許請求の範囲】
【請求項１】
在庫切れの発生した商品に関する入荷の通知の要求をユーザ端末より受け付ける要求受付部と、
前記要求受付部にて受け付けたユーザ毎の同一の商品に関する前記要求の履歴を記憶する履歴記憶部と、
前記ユーザ毎の当該商品の購入意欲の度合いを、前記履歴記憶部に記憶された前記履歴における少なくとも前記ユーザ毎の要求の回数をもとに定量化し、この定量化された前記ユーザ毎の購入意欲の度合いをもとに複数の前記ユーザ間の優先順位を作成し、この優先順位に従って前記複数のユーザのユーザ端末に当該商品の入荷の通知を行う入荷通知部と
を具備する情報処理装置。
【請求項２】
請求項１に記載の情報処理装置であって、
前記入荷通知部は、前記購入意欲の度合いが等しい複数のユーザが判定された場合、前記要求の受付日時の平均時間間隔が短い順に前記複数のユーザに対して高い優先順位を割り当てる
情報処理装置。
【請求項３】
請求項１に記載の情報処理装置であって、
前記入荷通知部は、複数の前記ユーザ端末への入荷の通知を、前記優先順位に従って時間をずらして行う
情報処理装置。
【請求項４】
請求項３に記載の情報処理装置であって、
前記入荷通知部は、前記購入意欲の度合いの値に応じて前記時間のずらし量を可変する
情報処理装置。
【請求項５】
請求項１に記載の情報処理装置であって、
前記商品の少なくとも入荷予定日を含む入荷スケジュール情報を受けたとき、前記ユーザ毎の当該商品の購入意欲の度合いを、前記履歴記憶部に記憶された履歴における少なくとも前記ユーザ毎の要求の回数をもとに定量化し、この定量化された前記ユーザ毎の購入意欲の度合いをもとに複数の前記ユーザ間の優先順位を作成し、この優先順位に従って前記複数のユーザのユーザ端末に当該商品の入荷の予告を通知する入荷スケジュール通知部を
さらに具備する情報処理装置。
【請求項６】
請求項１に記載の情報処理装置であって、
前記履歴記憶部に記憶された前記履歴をもとに前記商品の需要度情報を生成し、当該商品を販売するショップの端末に通知する需要度通知部
さらに具備する情報処理装置。
【請求項７】
要求受付部が、在庫切れの発生した商品に関する入荷の通知の要求をユーザ端末より受け付け、
履歴記憶部が、前記要求受付部にて受け付けたユーザ毎の同一の商品に関する前記要求の履歴を記憶し、
入荷通知部が、前記ユーザ毎の当該商品の購入意欲の度合いを、前記履歴記憶部に記憶された前記履歴における少なくとも前記ユーザ毎の要求の回数をもとに定量化し、この定量化された前記ユーザ毎の購入意欲の度合いをもとに複数の前記ユーザ間の優先順位を作成し、この優先順位に従って前記複数のユーザのユーザ端末に当該商品の入荷の通知を行う
情報処理方法。
【請求項８】
在庫切れの発生した商品に関する入荷の通知の要求をユーザ端末より受け付ける要求受付部と、
前記要求受付部にて受け付けたユーザ毎の同一の商品に関する前記要求の履歴を記憶する履歴記憶部と、
前記ユーザ毎の当該商品の購入意欲の度合いを、前記履歴記憶部に記憶された前記履歴における少なくとも前記ユーザ毎の要求の回数をもとに定量化し、この定量化された前記ユーザ毎の購入意欲の度合いをもとに複数の前記ユーザ間の優先順位を作成し、この優先順位に従って前記複数のユーザのユーザ端末に当該商品の入荷の通知を行う入荷通知部と
としてコンピュータを機能させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、インターネットを通信媒体として用いた通信販売システム用のサーバとして好適な情報処理装置、情報処理方法およびプログラムに関する。
【背景技術】
【０００２】
近年、インターネットを利用した通信販売を提供するシステムが商品の取り引きを行うための手段として重要な位置付けにある。
このような通信販売システムにおいては、多数の商品が多数のショップと顧客であるユーザとの間で迅速に取り引きされる。そのため、特に人気のある商品や希少価値のある商品などは、その商品を販売するショップのウェブページに多数のユーザがアクセスし、商品が短い時間で売れ切れてしまう場合もある。【０００３】
そこで、売り切れた商品がショップに再入荷されたことを、例えば、電子メールなどによって各ユーザに通知する仕組みが多々利用されている。この仕組みは、ユーザがその商品のページ上で入荷通知要求ボタンをクリックすることなどによって利用可能となる。ユーザＩＤ、商品ＩＤなどは互いに紐付けられてサーバに管理され、サーバは、その商品の再入荷の通知を受け次第、その商品の入荷通知要求を設定しているユーザＩＤを検索して、ユーザに入荷通知を行う。【０００４】
その際、入荷通知は、場合によっては多数のユーザに対して一斉に行われる。このため、一部のユーザは、その通知を受け取ったことを認識したタイミングの遅れなどにより、購入の機会を再び逸してしまい、そのようなことが繰り返されることもある。そこで、入荷通知を要求するユーザに対して、その商品の購入に係る要求レベルを問い合わせ、サーバは商品の入荷された際に、要求レベルの高いユーザが先に通知を送信する技術が提案されている（例えば特許文献１）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】国際公開ＷＯ２００３／０３８７００
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、係る公知の仕組みによると、ユーザ自身が要求レベルを決める都合上、やはり複数ユーザ間での公平性を欠くものと考えられる。例えば、特に人気商品などは、多くのユーザが高い要求レベルを設定すると考えられるため、結果的には複数ユーザ間で、購入の機会に恵まれるユーザと恵まれないユーザが生じる可能性が高い。
さらに、通信販売システムにおいては、上記の課題を含め、様々な点で十分な解決に至っていないという課題がある。【０００７】
以上のような事情に鑑み、本発明の目的は、通信販売を利用するショップおよびその顧客であるユーザに対して公平でかつ利用しやすい通信販売システムを提供することのできる情報処理装置、情報処理方法およびプログラムを提供することにある。
【課題を解決するための手段】
【０００８】
上記の目的を達成するために、本発明に係る情報処理装置は、ユーザ端末との間での商品の購入に関するインターネットを通じた交信の履歴をユーザ交信履歴として記憶する履歴記憶部と、
前記商品の在庫数の増加に応じて、前記ユーザ毎の当該商品の購入意欲の度合いを、前記履歴記憶部に記憶されたユーザ交信履歴をもとに定量化し、この定量化された前記ユーザ毎の購入意欲の度合いをもとに複数の前記ユーザ間の優先順位を作成し、この優先順位に従って前記複数のユーザのユーザ端末に当該商品の入荷の通知を行う入荷通知部とを具備する。【０００９】
本発明に係る情報処理装置は、在庫切れの発生した商品に関する入荷の通知の要求を前記ユーザ端末より受け付ける要求受付部をさらに具備し、前記履歴記憶部は、前記要求受付部にて受け付けた要求のユーザ毎の履歴をユーザ交信履歴として記憶するものであってよい。【００１０】
前記履歴記憶部は、前記要求受付部にて受け付けた要求の回数を前記ユーザ交信履歴として記憶するものであってよい。【００１１】
前記履歴記憶部は、前記要求受付部にて受け付けた要求の日時を前記ユーザ交信履歴として記憶するものであってよい。【００１２】
前記履歴記憶部は、前記商品に関する情報を提示したウェブページへのアクセスのユーザ毎の履歴をユーザ交信履歴として記憶するものであってよい。【００１３】
前記履歴記憶部は、前記ウェブページへのアクセスの回数を前記ユーザ交信履歴として記憶するものであってよい。【００１４】
前記履歴記憶部は、前記ウェブページへのアクセスの日時を前記ユーザ交信履歴として記憶してもよい。【００１５】
前記履歴記憶部は、前記商品の入荷の通知の履歴をユーザ交信履歴として記憶するものであってよい。【００１６】
前記履歴記憶部は、前記商品の入荷の通知の回数をユーザ交信履歴として記憶するものであってよい。【００１７】
前記履歴記憶部は、前記商品の入荷の通知の日時をユーザ交信履歴として記憶するものであってよい。【００１８】
前記入荷通知部は、複数の前記ユーザ端末への入荷の通知を、前記優先順位に従って時間をずらして行うものであってよい。【００１９】
前記入荷通知部は、前記購入意欲の度合いの値に応じて前記時間のずらし量を可変するものであってよい。【００２０】
本発明に係る情報処理装置は、前記商品の少なくとも入荷予定日を含む入荷スケジュール情報を受けたとき、前記ユーザ毎の当該商品の購入意欲の度合いを、前記履歴記憶部に記憶されたユーザ交信履歴をもとに定量化し、この定量化された前記ユーザ毎の購入意欲の度合いをもとに複数の前記ユーザ間の優先順位を作成し、この優先順位に従って前記複数のユーザのユーザ端末に当該商品の入荷の予告を通知する入荷スケジュール通知部をさらに具備するものであってよい。【００２１】
本発明に係る情報処理装置は、前記履歴記憶部に記憶された前記ユーザ交信履歴をもとに前記商品の需要度情報を生成し、当該商品を販売するショップの端末に通知する需要度通知部さらに具備するものであってよい。
【発明の効果】
【００２２】
以上のように、本発明によれば、通信販売を利用するショップおよびその顧客であるユーザに対して公平でかつ利用しやすい通信販売システムを提供することができる。
【図面の簡単な説明】
【００２３】
【図１】本発明の実施形態に係る通信販売システムの全体構成の一例を示す図である。
【図２】商品ページの表示例を示す図である。
【図３】商品の在庫がない場合の商品ページの画面例を示す図である。
【図４】入荷通知メールの一例を示す図である。
【図５】販売管理サーバの機能的な構成を示すブロック図である。
【図６】在庫データの構成を示す図である。
【図７】ユーザデータの構成を示す図である。
【図８】入荷通知データの構成を示す図である。
【図９】入荷通知要求の履歴データの構成を示す図である。
【図１０】入荷予告メールの例を示す図である。
【図１１】ユーザ端末のユーザが商品ページにアクセスする場合に実行される販売管理サーバおよびユーザ端末での処理を示すフローチャートである。
【図１２】販売管理サーバが入荷通知をする場合に実行される処理のフローチャートである。
【図１３】入荷スケジュール通知部の処理を示すフローチャートである。
【図１４】商品需要度通知部の処理を示すフローチャートである。
【図１５】入荷通知要求の受付日時の平均時間間隔を用いた入荷通知要求の履歴データの構成を示す図である。
【図１６】第２の実施形態の通信販売システムにおける販売管理サーバの機能的な構成を示すブロック図である。
【図１７】図１６の通信販売システムにおいてユーザ端末のユーザが商品ページにアクセスする場合に実行される販売管理サーバおよびユーザ端末での処理を示すフローチャートである。
【図１８】図１６の通信販売システムにおいて販売管理サーバが入荷通知をする場合に実行される処理のフローチャートである。
【図１９】アクセス日時の平均時間間隔を用いた商品ページアクセスの履歴データの構成を示す図である。
【図２０】アクセスした回数を用いた商品ページアクセスの履歴データの構成を示す図である。
【図２１】販売管理サーバ、ユーザ端末およびショップ端末のハードウェア構成を示す図である。
【発明を実施するための形態】
【００２４】
＜１．第１の実施形態＞
以下、本発明にかかる第１の実施形態を図面に基づき詳細に説明する。
なお、ここでは、本発明に係る通信販売システムを、インターネットを利用して商品を販売する通信販売システムに適用した場合について説明する。
【００２５】
［１−１．通信販売システムの構成］
図１は、本発明の実施形態に係る通信販売システムの全体構成の一例を示す図である。
図１に示すように、通信販売システム１は、販売管理サーバ１０、ユーザ端末２０、ショップ端末３０、およびデータベース４０を含む。販売管理サーバ１０は、通信ネットワーク２を介して、ユーザ端末２０及びショップ端末３０と接続可能とされている。
【００２６】
販売管理サーバ１０は、ショップ端末３０より提供された商品の紹介、商品の購入、売れ切れ商品の再入荷の提示など、商品の通信販売に関するサービスをウェブページを通じて提供するための各種処理を行う。販売管理サーバ１０は、例えば、サーバ用のコンピュータなどのハードウェア要素と、オペレーティングシステム、アプリケーションプログラム、その他のデータなどのソフトウェア要素とで実現される。
【００２７】
ユーザ端末２０は、販売管理サーバ１０に通信ネットワーク２を通じて接続し、商品に関するウェブページの閲覧をはじめ、商品の検索、予約、購入、売れ切れ商品の再入荷時にその旨の連絡を受けることの要求、要求の送信などに利用される。
【００２８】
ショップ端末３０は、販売管理サーバ１０に通信ネットワーク２を通じて接続し、販売する商品に関する情報の販売管理サーバ１０へのアップロードなどに利用される。
【００２９】
ユーザ端末２０およびショップ端末３０は、具体的には、携帯電話機（スマートフォンを含む）、携帯情報端末（タブレット型コンピュータを含む）、又はパーソナルコンピュータなどである。
【００３０】
なお、販売管理サーバ１０、ユーザ端末２０およびショップ端末３０の具体的なハードウェア構成については後で説明する。
【００３１】
販売管理サーバ１０はデータベース４０にアクセス可能である。データベース４０には、商品の通信販売のために必要な各種のデータが蓄積される。すなわち、販売管理サーバ１０は、データベース４０にアクセスして、データベース４０への各種のデータの格納、更新、検索、消去などの各種の操作を行うことが可能である。データベース４０に記憶されるデータについては後で説明する。
【００３２】
なお、データベース４０は、販売管理サーバ１０に構築されていてもよいし、販売管理サーバ１０とは別のサーバに構築されていてもよい。本実施形態では、販売管理サーバ１０の外部に構築されたデータベース４０を販売管理サーバ１０からアクセスするような構成を想定している。
【００３３】
［１−２．通信販売の基本的な流れ］
次に、ショップから販売される商品をユーザが購入するまでの基本的な流れについて説明する。
ユーザ端末２０が販売管理サーバ１０にアクセスして、販売管理サーバ１０よりダウンロードされた商品ページを表示部に表示していることとする。
【００３４】
図２は、商品ページの表示例を示す図である。この商品ページ５０は、ショップが販売する商品の種類毎のページである。商品ページ５０は、商品名および商品ＩＤ５１、商品に関する基本情報５２、現在の在庫数５３、商品の写真５４などが表示される。商品ページ５０は、上記のテキスト情報に加え、ユーザが商品の購入数を入力するための入力フォーム５５およびユーザが商品を購入するための購入ボタン５６を備える。
【００３５】
この商品ページ５０は、商品の在庫数が"１０"であり、すなわち、ショップに商品の在庫があることを示している。入力フォーム５５および購入ボタン５６は、同図の例のように、商品の在庫がある場合に商品ページ５０に配置される。ユーザが商品を購入したい場合には、入力フォーム５５に購入数を設定した後、購入ボタン５６を操作する。これにより、その商品に割り当てられている商品ＩＤおよび購入数などの商品購入に関するデータを含む購入要求が販売管理サーバ１０に送信され、購入要求を受けた販売管理サーバ１０は、配送先や決済方法等の商品取引に関するデータを入力するためのウェブページを生成して、当該ユーザのユーザ端末２０に応答する。ユーザ端末２０の表示部に表示されたウェブページ上でユーザによって上記の商品取引に関するデータが入力され、確認ボタンが操作されると、商品取引に関するデータが販売管理サーバ１０に送信される。
【００３６】
販売管理サーバ１０は、ユーザ端末２０からの商品取引に関する情報を受信すると、データベース４０にアクセスして、データベース４０に蓄積された各種のデータを更新する。例えば、販売管理サーバ１０は、購入要求に含まれて送信された商品ＩＤおよび購入数などの商品購入に関するデータをもとに、データベース４０に保存された在庫データから該当する商品の在庫数を減算するように更新を行う。さらに、ユーザ端末２０より転送された商品取引に関するデータを対象のデータベースに登録する。
【００３７】
また、商品ＩＤおよび購入数などの商品購入に関するデータ、および配送先や決済方法等の商品取引に関するデータは、販売管理サーバ１０からショップ端末３０に通信ネットワーク２を通じて送信される。ショップ端末３０は、これらのデータを受信すると、これらのデータをもとに、ショップのスタッフにより商品の配送のための手続きが行われる。
【００３８】
上記のように、商品の在庫がある場合、ユーザは商品ページ５０から商品を購入することができる。しかし、商品の在庫がなくなった場合、商品を購入することができない。
【００３９】
図３は、商品の在庫がない場合の商品ページ５０の画面例を示す図である。同図に示すように、この商品ページ５０において、現在の在庫数５３は"０"とされ、入力フォーム５５と購入ボタン５６に代えて、在庫切れのため商品を購入することができない旨を示すメッセージ５７と、ショップにおいて商品が入荷されたことに際してその旨を示す通知を出してもらうことを要求するための入荷通知要求ボタン５８が設けられる。
【００４０】
典型的なサービスでは、この商品ページ５０の入荷通知要求ボタン５８がユーザによって操作されると、ユーザ端末２０から販売管理サーバ１０に、当該ユーザを識別するためのユーザＩＤ、商品を識別する商品ＩＤ、必要に応じてユーザの電子メールアドレスなどを含む入荷通知要求が送信される。なお、通信販売サービスにおいて予め会員としてユーザ登録が完了しているユーザの場合には、ユーザＩＤと電子メールアドレスとが紐付けて既にデータベース４０などに登録されているので、この場合には電子メールアドレスは入荷通知要求に含まれる必要はない。
【００４１】
典型的なサービスでは、販売管理サーバ１０は、この入荷通知要求を受けると、この入荷通知要求に含まれるユーザＩＤ、商品ＩＤ、電子メールアドレスなどを入荷通知データとしてデータベース４０に互いに紐付けて保存する。すなわち、入荷通知要求を出したユーザ毎のユーザＩＤ、商品ＩＤ、電子メールアドレスなどが対応付けられて一つの入荷通知データとしてデータベース４０に保存される。
【００４２】
典型的なサービスでは、在庫切れの商品が入荷されたことを通知するデータがショップ端末３０から販売管理サーバ１０に送信され、その入荷された商品が在庫切れの商品である場合、販売管理サーバ１０は、データベース４０から、その入荷された商品の商品ＩＤを含む入荷通知データを検索する。そして、販売管理サーバ１０は、検索された入荷通知データをもとに、該当する商品に対して入荷通知要求を出したユーザのユーザ端末２０に対して、その商品を入荷したことを示す入荷通知を発行する。
【００４３】
ここで、ユーザ端末２０に対する入荷通知は、例えば、電子メール、入荷通知用のウェブページ、などによって行われる。以下、入荷通知は電子メールで行われることを想定する。この入荷通知のための電子メールを以降「入荷通知メール」と呼ぶ。
【００４４】
図４は、この入荷通知メールの一例を示す図である。
同図に示すように、入荷通知メール６０には、商品が入荷したことを示す件名６１及びメッセージ本文６２と、商品ページ５０へのハイパーリンク６３などが含まれる。
【００４５】
ユーザ端末２０において、ユーザによって、この入荷通知メール６０を開封する操作が行われ、開封された入荷通知メール６０の文面に設けられたハイパーリンク６３がクリックされると、ユーザ端末２０は商品ページ５０をダウンロードして表示部に表示させる。
【００４６】
これにより、ユーザは、自分が入荷通知要求をした商品が再入荷されたことを知ることができ、さらに、商品ページ５０にアクセスすることによって、現時点での在庫数を確認することができる。
【００４７】
しかしながら、ショップに入荷された商品がすぐに売り切れてしまい、ユーザがハイパーリンク６３を使って商品ページ５０にアクセスした時点で在庫が再びなくなっていることがある。この場合、ユーザはそのショップから商品を購入することができないので、入荷通知要求ボタン５８を再度操作して販売管理サーバ１０に入荷通知要求を送信する可能性がある。多くのユーザに注目されている人気商品や、厳しい出荷制限がかけられた商品の場合、個々のユーザは何度も入荷通知要求を繰り替えすことになり、ユーザに負担をかける結果を招く。ユーザによっては、出勤形態や帰宅時間の違いなどに起因して、入荷通知メール６０を開封できる日時に制限があったりする。これに対して入荷通知メール６０が配信される日時は一般的には不定期であったり、ショップからの入荷通知日時に依存したりする。これらの事情から、商品を購入しやすいユーザとなかなか購入できないユーザが発生してしまう可能性がある。
【００４８】
そこで、本実施形態は、通信販売サービスにおいて商品を購入しようとしているユーザ間の公平性を可及的に改善することを図るものである。
【００４９】
［１−３．販売管理サーバ１０の機能的な構成］
図５は、販売管理サーバ１０の機能的な構成を示すブロック図である。
同図に示すように、販売管理サーバ１０は、機能的な構成として、データ管理部１１、入荷通知要求受付部１２、入荷通知部１３、入荷スケジュール通知部１４、および商品需要度通知部１５を備える。これらは、販売管理サーバ１０のＣＰＵがメインメモリに格納されたプログラムを実行することによって実現される機能部である。
【００５０】
（１−３−１．データ管理部１１）
データ管理部１１は、商品の紹介、商品の購入、売れ切れ商品の再入荷の提示など、商品の通信販売に関するサービスを提供するために必要なデータをデータベース４０を用いて管理する。データ管理部１１によってデータベース４０には、ショップ毎の商品の在庫に関する在庫データ、通信販売システム１を利用する各ユーザに関するユーザデータ、入荷通知要求をしたユーザを識別するための入荷通知データ、ユーザ端末からの入荷通知要求の履歴データ（ユーザ交信履歴）などが保存される。
【００５１】
図６は、在庫データの構成を示す図である。
在庫データは、ショップを識別するショップＩＤと、ショップで取り扱う商品を識別する商品ＩＤと、商品の在庫数などで構成される。ここで、在庫数は、ユーザ端末２０からの購入要求を販売管理サーバ１０が受けることによって、データ管理部１１によって購入数分デクリメントされ、ショップのショップ端末３０からの入荷の通知を販売管理サーバ１０が受けることによって、データ管理部１１によって入荷数分増加される。
【００５２】
図７は、ユーザデータの構成を示す図である。
ユーザデータは、ユーザを識別するユーザＩＤと、ユーザに関する基本情報（例えば、氏名、電子メールアドレス、連絡先、配送先等）と、ユーザが過去に購入した商品に関する購入履歴（例えば、ショップＩＤ、商品ＩＤ、購入数、購入日時等）などで構成される。
【００５３】
例えば、ユーザが通信販売システム１の利用登録を行った場合に、当該ユーザのユーザデータがデータベース４０に新たなレコードとして登録される。利用登録の完了後、ユーザは、通信販売システム１のサービスを利用することができる。ユーザが商品を購入すると、当該ユーザに対応する購入履歴が更新される。
【００５４】
図８は、入荷通知データの構成を示す図である。
入荷通知データは、ユーザＩＤと、ショップＩＤと、商品ＩＤと、入荷通知要求の受付日時と、入荷通知フラグなどで構成される。入荷通知データにユーザＩＤが格納されているユーザが、入荷通知要求をしたユーザである。
【００５５】
商品ページ５０においてユーザが入荷通知要求ボタン５８を操作すると、ユーザ端末２０から販売管理サーバ１０にユーザＩＤ、ショップＩＤ、商品ＩＤなどを含む入荷通知要求が送られる。販売管理サーバ１０は、この入荷通知要求を受けると、データ管理部１１によって、この入荷通知要求に含まれるユーザＩＤ、ショップＩＤ、商品ＩＤ、入荷通知要求の受付日時、および入荷通知フラグを入荷通知データにおける一つのレコードとしてデータベース４０に登録する。入荷通知フラグの値は"１"である場合に入荷通知を受けたことを表し、"０"である場合には入荷通知を受けていないことを表す。したがって、ユーザ端末２０において商品ページ５０の入荷通知要求ボタン５８の操作が行われた場合には、入荷通知フラグの値は自動的に"１"にセットされる。この入荷通知フラグの値は、商品の入荷による在庫データ中の在庫数の発生時に商品の入荷を通知する入荷通知メール６０をユーザ端末２０に送信するかしないかを決める条件となる。すなわち、入荷通知フラグの値が"１"であるとき、対応するユーザへ入荷通知メール６０を送信するように決定され、入荷通知フラグの値が"１"であるとき、対応するユーザへ入荷通知メール６０を送信しないように決定される。この判断は、入荷通知部１３によって行われる。
【００５６】
なお、入荷通知フラグの値が"１"であるユーザに対して商品の入荷を通知する入荷通知メール６０が送信された場合には、入荷通知フラグの値は"１"から"０"にリセットされる。これにより、一度入荷通知メール６０を受信したユーザ端末２０のユーザは、再び同じ商品ページ５０の入荷通知要求ボタン５８を操作しない限り、その商品の入荷を通知する入荷通知メール６０を受けることはない。
【００５７】
図９は、入荷通知要求の履歴データの構成を示す図である。
入荷通知要求の履歴データは、ユーザＩＤ、ショップＩＤ、商品ＩＤ、入荷通知要求回数などで構成される。ここで、入荷通知要求回数は、ユーザ端末２０においてユーザが入荷通知要求ボタン５８を操作することによって販売管理サーバ１０に通知された入荷通知要求の回数である。
【００５８】
商品ページ５０においてユーザが入荷通知要求ボタン５８を操作すると、ユーザ端末２０から販売管理サーバ１０にユーザＩＤ、ショップＩＤ、商品ＩＤなどを含む入荷通知要求が送られる。販売管理サーバ１０は、この入荷通知要求を受けると、データ管理部１１によって、この入荷通知要求に含まれるユーザＩＤ、ショップＩＤ、商品ＩＤをもとに更新対象のレコードを検索し、更新対象のレコードが存在すれば、ユーザＩＤ、ショップＩＤ、商品ＩＤ、および入荷通知要求回数"１"を入荷通知要求の履歴データの一つのレコードとしてデータベース４０に登録する。また、更新対象のレコードが既に存在する場合には、データ管理部１１によって、更新対象のレコードの入荷通知要求回数の値がインクリメントされる。
なお、入荷通知要求の履歴データのレコードは、例えば、その商品の販売終了に伴って消去される。すなわち、その商品の販売が終了するまで、入荷通知要求回数は増えることがあっても減ることはない。
【００５９】
（１−３−２．入荷通知要求受付部１２）
入荷通知要求受付部１２は、ユーザ端末２０において、商品ページ５０の入荷通知要求ボタン５８がユーザによって操作されたことのイベントに対応して送信された入荷通知要求を受け付ける。入荷通知要求受付部１２は、受け付けた入荷通知要求に含まれるユーザＩＤ、ショップＩＤ、商品ＩＤなどのデータをデータ管理部１１にわたす。入荷通知要求受付部１２よりユーザＩＤ、ショップＩＤ、商品ＩＤなどのデータをわたされたデータ管理部１１は、これらのデータとデータベース４０に保存されているデータとをもとに、上述したように、入荷通知データの登録、入荷通知要求の履歴データの登録または更新を行う。
【００６０】
（１−３−３．入荷通知部１３）
入荷通知部１３は、入荷判定部１３１、購入意欲定量化部１３２および通知送信部１３３とを有する。
入荷判定部１３１は、入荷通知要求の履歴データに登録されているレコードのショップＩＤと商品ＩＤとの組み合わせについて、在庫データの該当するレコードにおける在庫数を監視し、在庫数が発生した場合（入荷が発生した場合）、その在庫数が発生したレコードのショップＩＤと商品ＩＤとの組み合わせを購入意欲定量化部１３２にわたす。
【００６１】
購入意欲定量化部１３２は、入荷判定部１３１よりわたされたショップＩＤと商品ＩＤとの組み合わせと、入荷通知要求の履歴データにおけるショップＩＤと商品ＩＤとの組み合わせとを比較し、それらが一致した入荷通知要求の履歴データのレコードを判定する。購入意欲定量化部１３２は、判定した入荷通知要求の履歴データのレコードにおけるユーザＩＤ毎に、当該商品の購入意欲の度合いを定量化する。
【００６２】
本実施形態において、購入意欲定量化部１３２は、入荷通知要求の回数をもとに、ユーザＩＤに対応するユーザ毎の商品の購入意欲の度合いを定量化する。例えば、入荷通知要求の回数の値をそのまま購入意欲の度合いを示す値として採用することが可能である。購入意欲定量化部１３２は、求めたユーザ毎の商品の購入意欲の度合いを示す値とユーザＩＤとの組み合わせを通知送信部１３３にわたす。
【００６３】
通知送信部１３３は、購入意欲定量化部１３２より取得したユーザ毎の商品の購入意欲の度合いを示す値とユーザＩＤとの組み合わせをもとに、ユーザ間の優先順位を作成する。例えば、購入意欲の度合いを示す値が大きいほど、そのユーザに対して高い優先順位を割り当てる。通知送信部１３３は、作成された優先順位に従って、各ユーザのユーザ端末２０に入荷通知メール６０を送信する。
【００６４】
作成された優先順位に従って、複数のユーザのユーザ端末２０に入荷通知メール６０を送信する方法としては、
１．各ユーザのユーザ端末２０に入荷通知メール６０をいっせいに送信する場合、ショップの商品毎に作成されるメール送信リストに、送信順に記載されるユーザの電子メールアドレスの記載順を優先順位の順とする方法。
【００６５】
２．各ユーザのユーザ端末２０に入荷通知メール６０を一定の時間帯（例えば一日、１２時間、６時間、３時間、１時間など）内で送信する場合、一定の時間帯を複数の時間帯に分割しておき、各々の優先順位に対して、分割された各々の時間帯を割り当てる方法。この場合も、優先順位が高いユーザほど、早い時間帯が割り当てられる。
【００６６】
３．ユーザの購入意欲の度合いを示す値を、分割時間帯に割り当てる時間の長さに反映させる方法。例えば、全体のメール送信時間として６時間が与えられている場合で、ユーザＡの購入意欲の度合いを示す値が"５"、ユーザＢの購入意欲の度合いを示す値が"１"であった場合、まず最も高い優先順位が与えられたユーザＡに対する入荷通知メール６０を送信する時間帯として最初の５時間が割り当てられ、次に高い優先順位が与えられたユーザＢに対して入荷通知メール６０が送信される時間帯として残りの１時間が割り当てられる。
【００６７】
（１−３−４．入荷スケジュール通知部１４）
入荷スケジュール通知部１４は、ショップ端末３０より、商品の入荷予定日および入荷数を含む入荷スケジュール情報を受けたときその入荷スケジュール情報の送信元であるショップのショップＩＤおよび入荷予定の商品の商品ＩＤを含む購入意欲定量化要求を購入意欲定量化部１３２に送信する。購入意欲定量化部１３２は、入荷スケジュール通知部１４からの購入意欲定量化要求を受けると、これに含まれるショップＩＤと商品ＩＤとの組み合わせと、入荷通知要求の履歴データにおけるショップＩＤと商品ＩＤとの組み合わせとを比較し、それらが一致した入荷通知要求の履歴データのレコードを判定する。購入意欲定量化部１３２は、判定した入荷通知要求の履歴データのレコードにおけるユーザＩＤ毎に当該商品の購入意欲の度合いを定量化して、その結果を入荷スケジュール通知部１４に応答する。
【００６８】
入荷スケジュール通知部１４は、入荷通知部１３の通知送信部１３３と同様に、購入意欲定量化部１３２より取得したユーザ毎の商品の購入意欲の度合いを示す値とユーザＩＤとの組み合わせをもとに、ユーザ間の優先順位を作成する。例えば、購入意欲の度合いを示す値が大きいほど、そのユーザに対して高い優先順位を割り当てる。通知送信部１３３は、作成された優先順位に従って、各ユーザのユーザ端末２０に入荷予告メールを送信する。
【００６９】
（１−３−６．商品需要度通知部１５）
商品需要度通知部１５は、入荷通知要求の履歴データあるいは入荷通知データをもとに商品毎の需要度情報を生成し、ショップ端末３０に通知する処理を行う。商品需要度通知部１５は、例えば、定期的（一日置き、一週間置きなど）あるいはショップ端末３０からの商品需要度通知要求を受けたとき、入荷通知要求の履歴データあるいは入荷通知データをもとに商品毎の需要度情報を生成する。
【００７０】
［１−４．第１の実施形態の通信販売システム１で実行される処理］
図１１及び図１２は通信販売システム１で実行される処理を示す図である。図１１はユーザ端末２０のユーザが商品ページ５０にアクセスする場合に実行される販売管理サーバ１０およびユーザ端末２０での処理であり、図１２は、販売管理サーバ１０が入荷通知をする場合に実行される処理である。
【００７１】
まず、図１１に示す処理について説明する。
以下、「販売管理サーバ１０が」という場合には「販売管理サーバ１０のＣＰＵが」を意味し、同様に、「ユーザ端末２０が」という場合には「ユーザ端末２０のＣＰＵが」を意味し、「ショップ端末３０が」という場合には「ショップ端末３０のＣＰＵが」を意味する。人為的な処理については「ユーザ端末２０のユーザ」のように「ユーザ」の用語を使って明確にする。
【００７２】
いま販売管理サーバ１０とユーザ端末２０とのセッションが確立されており、ユーザが所与のログイン操作を完了しているものとする。
【００７３】
まず、ユーザ端末２０は、ユーザの操作（例えば、商品ページ５０のリンクを選択する操作）に応じて、商品ページ５０の閲覧要求を販売管理サーバ１０に送信する（ステップＳ１０１）。なお、ユーザ端末２０から販売管理サーバ１０に情報が送信される場合には、ＩＰアドレスやユーザＩＤ等が送信されるものとする。これにより、販売管理サーバ１０は、どのユーザが商品ページ５０にアクセスしているかを特定することができる。
【００７４】
販売管理サーバ１０は、商品ページ５０の閲覧要求を受信すると、在庫データを参照して、商品ページ５０に対応する商品の在庫があるか否かを判定する（ステップＳ２０１）。ここで、商品ページ５０のＵＲＬにはショップＩＤ及び商品ＩＤが対応付けてデータベース４０などに保存されている。したがって、販売管理サーバ１０は、商品ページ５０の閲覧要求を受けると、この閲覧要求に含まれる閲覧対象のＵＲＬに対応付けられたショップＩＤ及び商品ＩＤを検索し、このショップＩＤと商品ＩＤとの組み合わせを在庫データと比較することによって、在庫データの中の該当するレコードを検索し、このレコードの在庫数を確認することによって、在庫の有無を知ることができる。
【００７５】
販売管理サーバ１０は、商品の在庫があることを判定した場合（ステップＳ２０１のＹＥＳ）、入力フォーム５５及び購入ボタン５６を有する商品ページ５０を生成し、ユーザ端末２０に送信する（ステップＳ２０２）。
【００７６】
ユーザ端末２０は、商品ページ５０を受信して、これを表示部に表示させる（ステップ１０２）。これにより、図２に示したような商品ページ５０がユーザ端末２０の表示部に表示される。
以降、ユーザの操作に応じて商品の購入処理が行われる（ステップＳ１０３）。当該購入処理とこれに応じた販売管理サーバ１０の購入受付の処理（ステップＳ２０３，２０４）は一般的な処理として上述したとおりである。
【００７７】
一方、販売管理サーバ１０は、商品の在庫がないことを判定した場合（ステップＳ２０１のＮＯ）、商品の在庫がない場合の商品ページ５０（図３参照）を生成してユーザ端末２０に送信する（ステップＳ２０５）。
【００７８】
ユーザ端末２０は、販売管理サーバ１０からの商品の在庫がない場合の商品ページ５０を受信して、これを表示する（ステップＳ１０４）。この商品の在庫がない場合の商品ページ５０には入荷通知要求ボタン５８が設けられている。したがって、ユーザは、その商品を購入したい場合には入荷通知要求ボタン５８を操作する。これによりユーザ端末２０から販売管理サーバ１０にユーザＩＤ、ショップＩＤ、商品ＩＤなどを含む入荷通知要求が送信される（ステップＳ１０５）。
【００７９】
販売管理サーバ１０において、入荷通知要求受付部１２は、ユーザ端末２０からの入荷通知要求を受け付けてデータ管理部１１に供給する。データ管理部１１は、この入荷通知要求に含まれるユーザＩＤ、ショップＩＤおよび商品ＩＤの組み合わせをデータベース４０に既に保存されている入荷通知データと比較し、その組み合わせが入荷通知データに存在しない場合、その入荷通知要求を、今回のユーザＩＤ、ショップＩＤおよび商品ＩＤの組み合わせに対する初回の入荷通知要求としてみなし（ステップＳ２０６のＹＥＳ）、そのユーザＩＤ、ショップＩＤおよび商品ＩＤと、入荷通知要求の受付日時、さらには入荷通知フラグ"１"からなる新規のレコードを入荷通知データに追加する（ステップＳ２０７）。この後、データ管理部１１は、そのユーザＩＤ、ショップＩＤおよび商品ＩＤと、入荷通知要求回数"１"との組み合わせを、一つのレコードとして入荷通知要求の履歴データに新規に登録する（ステップＳ２０８）。
【００８０】
また、データ管理部１１は、入荷通知要求に含まれるユーザＩＤ、ショップＩＤおよび商品ＩＤの組み合わせが入荷通知データに既に存在する場合、その入荷通知要求は初回の入荷通知要求ではないことを判定し（ステップＳ２０６のＮＯ）、入荷通知要求の履歴データを更新する（ステップＳ２０７）。この入荷通知要求の履歴データの更新は、具体的には、入荷通知要求の履歴データの該当するレコードの入荷通知要求回数をインクリメントすることによって行われる。
【００８１】
次に、ユーザに対する入荷通知の処理を図１２に従って説明する。
まず、ショップ端末３０より、商品の入荷に関する情報が販売管理サーバ１０に送信される（ステップＳ３０１）。商品の入荷に関する情報とは、ショップＩＤ、入荷した商品の商品ＩＤ、入荷数などを含む。
【００８２】
販売管理サーバ１０において、データ管理部１１は、かかる商品の入荷に関する情報を取得すると（ステップＳ２０９のＹＥＳ）、在庫データを更新する（ステップＳ２１０）。
【００８３】
在庫データの更新が発生すると、入荷通知部１３は入荷判定部１３１を起動させる。入荷判定部１３１は、入荷通知要求の履歴データに登録されているレコードのショップＩＤと商品ＩＤとの組み合わせについて、在庫データの該当するレコードにおける在庫数をチェックする。ここで、商品が新たに入荷されていない場合には在庫数は"０"のままであるが、商品が新たに入荷された場合には在庫数は"１"以上となっている。このようにして、入荷判定部１３１は、入荷通知対象の商品が入荷されたどうかを知ることができる（ステップＳ２１１）。
【００８４】
入荷判定部１３１は、入荷通知対象の商品が入荷されたことを知ると（ステップＳ２１１のＹＥＳ）、その商品の入荷により在庫数が発生したレコードのショップＩＤと商品ＩＤとの組み合わせを購入意欲定量化部１３２にわたす。購入意欲定量化部１３２は、入荷判定部１３１よりわたされたショップＩＤと商品ＩＤとの組み合わせと、入荷通知要求の履歴データにおけるショップＩＤと商品ＩＤとの組み合わせとを比較し、それらが一致した入荷通知要求の履歴データのレコードを判定する。そして購入意欲定量化部１３２は、判定した入荷通知要求の履歴データのレコードにおけるユーザＩＤ毎に、当該商品の購入意欲の度合いを定量化する（ステップＳ２１２）。この商品の購入意欲の度合いの定量化の方法については前述したとおりである。
【００８５】
続いて、購入意欲定量化部１３２は、求めたユーザ毎の商品の購入意欲の度合いを示す値とユーザＩＤとの組み合わせを通知送信部１３３にわたす。通知送信部１３３は、購入意欲定量化部１３２より取得したユーザ毎の商品の購入意欲の度合いを示す値とユーザＩＤとの組み合わせをもとに、ユーザ間の優先順位を作成する（ステップＳ２１３）。このユーザ間の優先順位の具体的な作成方法については前述したとおりである。
【００８６】
次に、通知送信部１３３は、作成された優先順位に従って、各ユーザのユーザ端末２０に入荷通知メール６０を送信する（ステップＳ２１４）。作成された優先順位に従って、各ユーザのユーザ端末２０に入荷通知メール６０を送信する具体的な方法は前述したとおりである。
【００８７】
続いて、通知送信部１３３は入荷通知要求の履歴データの更新を行う。この入荷通知要求の履歴データの更新は、入荷通知要求回数の値をインクリメントすることによって行われる。すなわち、ユーザ端末２０への入荷通知の送信に伴って、入荷通知要求の履歴データにおける入荷通知要求回数の値は"１"ずつ増加されて行く。
【００８８】
次に、通知送信部１３３は入荷通知データにおける入荷通知フラグをリセットする（ステップＳ２１６）。すなわち、ユーザ端末２０への入荷通知の送信に伴って、入荷通知データにおける入荷通知フラグの値は"１"から"０"に更新される。
【００８９】
一般的には、ユーザ端末２０のユーザが入荷通知メール６０を受け取って開封した後、商品ページ５０にアクセスした時点で、既にその再入荷された商品が売れ切れている場合が考えられる。しかし、本実施形態によれば、この後、再度ユーザが入荷通知要求ボタン５８を操作することによってユーザ端末２０から販売管理サーバ１０に送信された入荷通知要求によって、入荷通知要求の履歴データにおける入荷通知要求回数の値はインクリメントされるので、次回の入荷通知の優先順位は前回より高くなっている可能性が高い。このため、商品が何度も再入荷されても、特定のユーザだけがその商品を購入できないといった不公平性を大きく緩和することができる。
【００９０】
次に、販売管理サーバ１０の入荷スケジュール通知部１４の処理を説明する。
図１３は、この入荷スケジュール通知部１４の処理を示すフローチャートである。
まず、ショップ端末３０より、入荷予定の商品に関するスケジュール情報が販売管理サーバ１０に送信される（ステップＳ４０１）。入荷予定の商品に関するスケジュール情報とは、ショップＩＤ、入荷予定の商品の商品ＩＤ、入荷予定日、入荷予定数などを含む。
【００９１】
販売管理サーバ１０において、入荷スケジュール通知部１４は、ショップ端末３０からの入荷スケジュール情報を受信すると（ステップＳ２２１）、その入荷スケジュール情報の送信元であるショップのショップＩＤおよび入荷予定の商品の商品ＩＤを含む購入意欲定量化要求を購入意欲定量化部１３２に送信する。
【００９２】
購入意欲定量化部１３２は、入荷スケジュール通知部１４からの購入意欲定量化要求を受けると、この購入意欲定量化要求に含まれるショップＩＤと商品ＩＤとの組み合わせと、入荷通知要求の履歴データにおけるショップＩＤと商品ＩＤとの組み合わせとを比較し、それらが一致した入荷通知要求の履歴データのレコードを判定する（ステップＳ２２１）。
【００９３】
購入意欲定量化部１３２は、該当する入荷通知要求の履歴データのレコードを判定すると、当該レコードにおけるユーザＩＤ毎に当該商品の購入意欲の度合いを定量化して（ステップＳ２２２）、その結果を入荷スケジュール通知部１４に応答する。
【００９４】
入荷スケジュール通知部１４は、入荷通知部１３の通知送信部１３３と同様に、購入意欲定量化部１３２より取得したユーザ毎の商品の購入意欲の度合いを示す値とユーザＩＤとの組み合わせをもとに、ユーザ間の優先順位を作成する（ステップＳ２２３）。そして、通知送信部１３３は、作成された優先順位に従って、各ユーザのユーザ端末２０に、例えば図入荷スケジュール通知メールを送信する（ステップＳ２２４）。
【００９５】
図１０は、入荷予告メール７０の例を示す図である。
同図に示すように、入荷予告メール７０には、商品が入荷スケジュールであることを示す件名７１及び入荷スケジュールのメッセージ本文７２と、商品ページ５０へのハイパーリンク７３などが含まれる。
【００９６】
ユーザ端末２０において、ユーザによって、この入荷予告メール７０を開封する操作が行われ、開封された入荷予告メール７０の文面に設けられたハイパーリンク７３がクリックされると、ユーザ端末２０は商品ページ５０を受信して表示部に表示させる。これにより、ユーザは、自分が入荷通知要求をした商品が入荷される予定日などを知ることができる。
【００９７】
なお、本実施形態では、入荷通知および入荷スケジュール通知として、入荷通知メール６０および入荷予告メール７０を送信する場合を想定しているが、入荷通知あるいは入荷スケジュール通知のためのウェブページを作成してユーザ端末２０に送信するようにしてもよい。
【００９８】
次に、販売管理サーバ１０の商品需要度通知部１５の処理を説明する。
図１４は、この商品需要度通知部１５の処理を示すフローチャートである。
商品需要度通知部１５は、例えば、定期的（一日置き、一週間置きなど）、あるいはショップ端末３０からの商品需要度通知要求を受けたとき（ステップＳ２３１のＹＥＳ）、入荷通知要求の履歴データあるいは入荷通知データをもとに商品毎の需要度情報を生成する（ステップＳ２３２）。具体的には、例えば、商品需要度通知部１５は、一つのショップについて、商品毎の入荷通知要求回数の累計値などを需要度情報として生成する。あるいは、商品毎の需要度情報は入荷通知フラグが"１"にセットされたユーザ数により定量化されてもよい。この後、商品需要度通知部１５は、生成された商品毎の需要度情報を、電子メールまたはウェブページとしてショップ端末３０に通知する（ステップＳ２３３）。
【００９９】
以上の実施形態では、商品の購入意欲の度合いを定量化するための入荷通知要求の履歴データとして入荷通知要求回数を用いた。しかしながら、入荷通知要求の受付日時の平均時間間隔を入荷通知要求の履歴データとして用いて定量化を行うようにしてもよい。
【０１００】
図１５は、入荷通知要求の受付日時の平均時間間隔を用いた入荷通知要求の履歴データの構成を示す図である。
図１５において、ユーザＩＤが"user001"のユーザと、ユーザＩＤが"user002"のユーザが互いに同じショップ（ＩＤ＝"sh001"）の同じ商品（ＩＤ＝"goh0001"）に対して入荷通知要求を設定していることとする。また、両ユーザとも入荷通知要求回数が"２"で一致している。このような状況において、入荷通知要求の受付日時の平均時間間隔を購入意欲の度合いの定量化の指標に用いる、あるいは指標の一つとして加えることによって、両ユーザ間に優先順位の差を適正に設けることができる。
【０１０１】
この例では、ユーザＩＤが"user001"の入荷通知要求の受付日時の平均時間間隔は"約１３日"であるのに対し、ユーザＩＤが"user002"の入荷通知要求の受付日時の平均時間間隔は"約１日"である。このような場合には、入荷通知要求の受付日時の平均時間間隔が短い方のユーザの購入意欲が高いということができ、ユーザ間の優先順位はuser001＜user002であると決定される。
【０１０２】
＜２．第２の実施形態＞
次に、本発明の第２の実施形態を説明する。
上記の第１の実施形態では、商品ページ５０に入荷通知要求ボタン５８を設け、ユーザから明示的に商品の入荷通知要求が送信された回数を、当該ユーザの商品に対する購入意欲の度合いを示す指標とした。
【０１０３】
第２の実施形態は、ユーザからの明示的な入荷通知要求の送信回数ではなく、図２０に示すように、ユーザが商品ページをアクセスした回数などを商品ページアクセスの履歴として記録し、この商品ページアクセスの履歴を当該ユーザの商品に対する購入意欲の度合いを示す指標とするものである。
【０１０４】
図１６は、本実施形態の通信販売システム１における販売管理サーバ１０Ａの機能的な構成を示すブロック図である。
第１の実施形態の販売管理サーバ１０の機能的な構成に対して相違する点は、商品ページアクセス管理部１７が付加され、データベース４０にはユーザ交信履歴として、入荷通知要求の履歴データに代えて、商品ページアクセスの履歴データが保存される点である。さらに、入荷通知部１３において、購入意欲定量化部１３２Ａは、入荷通知要求の履歴データをもとに、ユーザ毎の商品の購入意欲の度合いを定量化するのではなく、商品ページのアクセスの履歴をもとにユーザ毎の商品の購入意欲の度合いを定量化する点にある。
【０１０５】
（２−１．商品ページアクセス管理部１７）
商品ページアクセス管理部１７は、ユーザ端末２０のユーザのユーザＩＤ、アクセスした商品ページ５０に関連付けられたショップのショップＩＤ、アクセスした商品ページ５０に関連付けられた商品の商品ＩＤをデータ管理部１１にわたす。データ管理部１１は、データベース４０の商品ページアクセスの履歴データにユーザＩＤ、ショップＩＤ、商品ＩＤが一致するレコードが登録されていない場合には、これらユーザＩＤ、ショップＩＤ、商品ＩＤ、そしてアクセス回数の初期値"１"をデータベース４０の商品ページアクセスの履歴データにレコードとして新規に登録する。また、ユーザＩＤ、ショップＩＤ、商品ＩＤが一致するレコードがデータベース４０に既に登録されている場合には、データベース４０に保存された商品ページアクセスの履歴データの該当するレコードのアクセス回数の値をインクリメントする。
【０１０６】
［２−１．第２の実施形態の通信販売システムで実行される処理］
図１７及び図１８は第２の実施形態の通信販売システムで実行される処理を示す図である。図１７はユーザ端末２０のユーザが商品ページ５０にアクセスする場合に実行される販売管理サーバ１０Ａおよびユーザ端末２０での処理であり、図１８は、販売管理サーバ１０Ａが入荷通知を行うとき実行される処理である。
【０１０７】
図１７において、ユーザ端末２０のステップＳ１０１からステップＳ１０５までの動作は第１の実施形態の図１１と同じであるため、説明を省略する。また、販売管理サーバ１０Ａにおいて、ステップＳ２０１からステップＳ２０５までの動作も第１の実施形態の図１１と同じであるため、説明を省略する。
【０１０８】
第２の実施形態では、販売管理サーバ１０ＡがステップＳ２０５において、商品の在庫がない場合の商品ページ５０（図３参照）を生成してユーザ端末２０に送信した後、データベース４０の商品ページアクセスの履歴データの更新が行われる（ステップＳ２０６Ａ）。
【０１０９】
より具体的には、商品ページアクセス管理部１７が、ユーザ端末２０のユーザのユーザＩＤ、アクセスした商品ページ５０に関連付けられたショップのショップＩＤ、アクセスした商品ページ５０に関連付けられた商品の商品ＩＤをデータ管理部１１にわたす。データ管理部１１は、データベース４０の商品ページアクセスの履歴データにユーザＩＤ、ショップＩＤ、商品ＩＤが一致するレコードが登録されていない場合には、これらユーザＩＤ、ショップＩＤ、商品ＩＤ、そしてアクセス回数の初期値"１"をデータベース４０の商品ページアクセスの履歴データにレコードとして新規に登録する。
【０１１０】
また、ユーザＩＤ、ショップＩＤ、商品ＩＤが一致するレコードがデータベース４０に既に登録されている場合には、データベース４０に保存された商品ページアクセスの履歴データの該当するレコードのアクセス回数の値をインクリメントする。
【０１１１】
すなわち、この実施形態は、ユーザ端末２０において、ユーザが商品ページ５０の入荷通知要求ボタン５８を操作して入荷通知要求を出すかどうかにかかわらず、商品ページ５０へのアクセスが発生したら、その履歴をデータベース４０に保存することに特徴がある。
【０１１２】
次に、図１８を用いて、販売管理サーバ１０Ａが入荷通知を行うとき実行される処理を説明する。
本実施形態において、販売管理サーバ１０Ａのステップ２１２Ａ以外の各ステップの動作は、第１の実施形態の図１２に示した動作と同じであるため、これらの説明は省略する。
ステップ２１２Ａでは、販売管理サーバ１０Ａの購入意欲定量化部１３２Ａは、データベース４０に保存された商品ページのアクセスの履歴をもとにユーザ毎の商品の購入意欲の度合いを定量化する。
【０１１３】
このように、本実施形態では、ユーザが商品ページをアクセスした回数などの商品ページアクセスの履歴データを、ユーザの商品の購入意欲の度合いを示す指標としてユーザ間の優先順位を生成し、この優先順位に従って、各ユーザに入荷通知を行うことができる。これにより第１の実施形態と同様に、各ユーザが入荷通知を契機にして商品を購入する際の公平性を改善することができる。
【０１１４】
なお、第２の実施形態では、商品ページアクセスの履歴データとしては、商品ページをアクセスした回数に代えて、図１９に示すように、アクセス日時の平均時間間隔を用いることが可能である。あるいは、商品ページをアクセスした回数とアクセス日時の平均時間間隔の両方を用いて、ユーザの商品の購入意欲の度合いを定量化するようにしてもよい。
【０１１５】
＜３．変形例＞
以上、入荷通知要求の回数および要求日時、商品ページのアクセスの回数およびアクセス日時をユーザ交信履歴として用いて、商品の購入意欲の度合いを定量化する方式について述べたが、販売管理サーバ１０からユーザ端末２０への入荷通知の回数および通知日時をユーザ交信履歴として用いて、商品の購入意欲の度合いを定量化することも可能である。
【０１１６】
＜４．販売管理サーバ、ユーザ端末およびショップ端末のハードウェア構成＞
最後に、販売管理サーバ、ユーザ端末およびショップ端末のハードウェア構成について説明する。
【０１１７】
図２１は、販売管理サーバ１０、ユーザ端末２０およびショップ端末３０のハードウェア構成を示す図である。
ＣＰＵ１１１、システムバス１１２、ＲＯＭ１１３、ＲＡＭ１１４、ネットワーク接続部１１５、入力部１１６、出力部１１７、メディアＩ／Ｆ部１１８、および記憶部１１９などを有する。ＣＰＵ（Central Processing Unit）１１１は、メインメモリとして用いられるＲＡＭ１１４にロードされたオペレーティングシステムおよびアプリケーションプログラムを解釈実行して、ネットワーク接続部１１５、入力部１１６、出力部１１７、メディアＩ／Ｆ部１１８、および記憶部１１９などとの間で各種の情報のやりとりや各種の演算処理を実行する。
【０１１８】
ネットワーク接続部１１５はインターネットなどの通信ネットワークに接続するための処理を行う。入力部１１６および出力部１１７はユーザインタフェースのための手段であり、主にユーザ端末２０およびショップ端末３０において不可欠なハードウェア要素である。入力部１１６および出力部１１７は、例えば、タッチパネルディスプレイなどして組み込まれることもある。あるいは、キーボード、マウスなどの入力専用デバイスと、ＣＲＴ（Ｃａｔｈｏｄｅ Ｒａｙ Ｔｕｂｅ）、ＬＣＤ（Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ）などの表示専用デバイスとの組み合わせであってもよい。
【０１１９】
メディアＩ／Ｆ部１１８は、例えば、磁気ディスク、光ディスク、あるいは半導体メモリなどのリムーバブルメディア３の着脱を可能としたものである。販売管理サーバ１０、ユーザ端末２０およびショップ端末３０は、このリムーバブルメディア３から読み込んだアプリケーションプログラムを導入したり、逆に内部のデータをリムーバブルメディア３に保存したりすることができる。記憶部１１９は、例えば、ハードディスクドライブなどの不揮発性メモリで実現される。
【符号の説明】
【０１２０】
１…通信販売システム
２…通信ネットワーク
１０…販売管理サーバ
１１…データ管理部
１２…入荷通知要求受付部
１３…入荷通知部
１４…入荷スケジュール通知部
１５…商品需要度通知部
１７…商品ページアクセス管理部
２０…ユーザ端末
３０…ショップ端末
４０…データベース
５０…商品ページ
５８…入荷通知要求ボタン
６０…入荷通知メール
１３１…入荷判定部
１３２…購入意欲定量化部
１３３…通知送信部
【要約】
【解決手段】  ユーザ端末との間での商品の購入に関するインターネットを通じた交信の履歴をユーザ交信履歴として記憶する履歴記憶部と、商品の在庫数の増加に応じて、ユーザ毎の当該商品の購入意欲の度合いを、履歴記憶部に記憶されたユーザ交信履歴をもとに定量化し、この定量化されたユーザ毎の購入意欲の度合いをもとに複数のユーザ間の優先順位を作成し、この優先順位に従って複数のユーザのユーザ端末に当該商品の入荷の通知を行う入荷通知部とを具備する。
【選択図】図５【図１】
0005410642.tif 000002
【図２】
0005410642.tif 000003
【図３】
0005410642.tif 000004
【図４】
0005410642.tif 000005
【図５】
0005410642.tif 000006
【図６】
0005410642.tif 000007
【図７】
0005410642.tif 000008
【図８】
0005410642.tif 000009
【図９】
0005410642.tif 000010
【図１０】
0005410642.tif 000011
【図１１】
0005410642.tif 000012
【図１２】
0005410642.tif 000013
【図１３】
0005410642.tif 000014
【図１４】
0005410642.tif 000015
【図１５】
0005410642.tif 000016
【図１６】
0005410642.tif 000017
【図１７】
0005410642.tif 000018
【図１８】
0005410642.tif 000019
【図１９】
0005410642.tif 000020
【図２０】
0005410642.tif 000021
【図２１】
0005410642.tif 000022