JP5414878B1 - 在庫切れ通知システム、在庫切れ通知装置、在庫切れ通知方法、及びプログラム - Google Patents

Abstract

【課題】入荷通知要求をしたユーザが在庫のない商品ページにアクセスしてしまう可能性を軽減する。
【解決手段】在庫切れ通知システムの入荷通知要求受付部８４は、ユーザによる商品の入荷通知要求を受け付ける。入荷通知部８６は、商品が入荷した場合に、入荷通知要求を受け付けたユーザに対する入荷通知を行う。在庫切れ通知部９０は、入荷通知が行われた後に商品の在庫がなくなった場合、入荷通知要求を受け付けたユーザに対する在庫切れ通知を行う。
【選択図】図８

Description

本発明は、在庫切れ通知システム、在庫切れ通知装置、在庫切れ通知方法、及びプログラムに関する。

従来から、商品が入荷した場合に、ユーザに対する入荷通知を行う技術が知られている。特許文献１には、インターネットを利用した通信販売を提供するシステムにおいて、商品の入荷通知要求を行ったユーザに対して、商品が入荷した場合に入荷通知を送信する技術が記載されている。

特開２００３−３０５０７号公報

上記のような技術では、ユーザに対して入荷通知が行われたとしても、その後に商品が売り切れてしまい、再び在庫がなくなってしまう可能性がある。このため、ユーザが入荷通知を見て商品ページにアクセスしても、当該アクセスの時点で在庫が再びなくなっていることがある。この場合、ユーザによる商品ページのアクセスが無駄になってしまう。

本発明は上記課題に鑑みてなされたものであって、その目的は、入荷通知要求をしたユーザが在庫のない商品ページにアクセスしてしまう可能性を軽減することが可能な在庫切れ通知システム、在庫切れ通知装置、在庫切れ通知方法、及びプログラムを提供することにある。

上記課題を解決するために、本発明に係る在庫切れ通知システムは、商品の在庫に関するデータを記憶する手段の記憶内容を取得する手段と、ユーザによる前記商品の入荷通知要求を受け付ける入荷通知要求受付手段と、前記商品が入荷した場合に、前記入荷通知要求を受け付けたユーザに対する入荷通知を行う入荷通知手段と、前記入荷通知が行われた後に前記商品の在庫がなくなった場合、前記入荷通知要求を受け付けたユーザに対する在庫切れ通知を行う在庫切れ通知手段と、を含むことを特徴とする。

また、本発明に係る在庫切れ通知装置は、商品の在庫に関するデータを記憶する手段の記憶内容を取得する手段と、ユーザによる前記商品の入荷通知要求を受け付ける入荷通知要求受付手段と、前記商品が入荷した場合に、前記入荷通知要求を受け付けたユーザに対する入荷通知を行う入荷通知手段と、前記入荷通知が行われた後に前記商品の在庫がなくなった場合、前記入荷通知要求を受け付けたユーザに対する在庫切れ通知を行う在庫切れ通知手段と、を含むことを特徴とする。

また、本発明に係る在庫切れ通知方法は、商品の在庫に関するデータを記憶する手段の記憶内容を取得するステップと、ユーザによる前記商品の入荷通知要求を受け付ける入荷通知要求受付ステップと、前記商品が入荷した場合に、前記入荷通知要求を受け付けたユーザに対する入荷通知を行う入荷通知ステップと、前記入荷通知が行われた後に前記商品の在庫がなくなった場合、前記入荷通知要求を受け付けたユーザに対する在庫切れ通知を行う在庫切れ通知ステップと、を含むことを特徴とする。

また、本発明に係るプログラムは、商品の在庫に関するデータを記憶する手段の記憶内容を取得する手段、ユーザによる前記商品の入荷通知要求を受け付ける入荷通知要求受付手段、前記商品が入荷した場合に、前記入荷通知要求を受け付けたユーザに対する入荷通知を行う入荷通知手段、前記入荷通知が行われた後に前記商品の在庫がなくなった場合、前記入荷通知要求を受け付けたユーザに対する在庫切れ通知を行う在庫切れ通知手段、としてコンピュータを機能させる。

また、本発明に係る情報記憶媒体は、上記プログラムを記憶したコンピュータ読み取り可能な情報記憶媒体である。

また、本発明の一態様では、前記在庫切れ通知システムは、前記入荷通知要求を受け付けたユーザによる、前記商品の商品ページへのアクセス履歴を取得する手段を更に含み、前記在庫切れ通知手段は、前記入荷通知が行われた時点から、前記商品の在庫がなくなった時点までの間に、前記ユーザが前記商品ページにアクセスした履歴が前記アクセス履歴に存在しない場合、前記入荷通知要求を受け付けたユーザに対する在庫切れ通知を行う、ことを特徴とする。

また、本発明の一態様では、前記入荷通知手段は、前記入荷通知要求を受け付けたユーザに対する入荷通知をすべきか否かを識別する識別情報に基づいて、当該ユーザに対する入荷通知を行うか否かを決定し、前記在庫切れ通知システムは、前記入荷通知が行われてから前記商品の在庫がなくなるまでの間に、前記入荷通知要求を受け付けたユーザが前記商品の商品ページにアクセスした場合、以降の入荷通知を行わないように前記識別情報を設定する手段を更に含み、前記在庫切れ通知手段は、前記入荷通知が行われた後において、前記識別情報が入荷通知を行うことを示している状態で、前記商品の在庫がなくなった場合、前記入荷通知要求を受け付けたユーザに対する在庫切れ通知を行う、ことを特徴とする。

また、本発明の一態様では、前記在庫切れ通知システムは、前記在庫切れ通知が前記入荷通知要求を受け付けたユーザに提示されたか否かを判定する在庫切れ通知判定手段を更に含み、前記在庫切れ通知手段は、前記在庫切れ通知判定手段の判定結果に基づいて、以降の前記在庫切れ通知の通知態様を変更する、ことを特徴とする。

また、本発明の一態様では、前記在庫切れ通知システムは、前記入荷通知が前記入荷通知要求を受け付けたユーザに提示されたか否かを判定する入荷通知判定手段を更に含み、前記在庫切れ通知手段は、前記入荷通知判定手段の判定結果に基づいて、以降の前記在庫切れ通知の通知態様を変更する、ことを特徴とする。

また、本発明の一態様では、前記在庫切れ通知システムは、前記在庫切れ通知が行われた後に、前記商品ページに前記入荷通知要求を受け付けたユーザがアクセスしたか否かを判定するアクセス判定手段を更に含み、前記在庫切れ通知手段は、前記アクセス判定手段の判定結果に基づいて、以降の前記在庫切れ通知の通知態様を変更する、ことを特徴とする。

また、本発明の一態様では、前記在庫切れ通知は、複数種類の通知媒体のうちの少なくとも一つを用いて行われ、前記在庫切れ通知手段は、前記複数種類の通知媒体のうちで使用する通知媒体の種類を変更することによって、前記在庫切れ通知の通知態様を変更する、ことを特徴とする。

また、本発明の一態様では、前記在庫切れ通知は、複数種類の雛型のうちの少なくとも一つを用いて行われ、前記在庫切れ通知手段は、前記複数種類の通知媒体のうちで使用する雛型の種類を変更することによって、前記在庫切れ通知の通知態様を変更する、ことを特徴とする。

また、本発明の一態様では、前記在庫切れ通知システムは、前記在庫切れ通知が前記入荷通知要求を受け付けたユーザに提示されたか否かを判定する在庫切れ通知判定手段を更に含み、前記入荷通知手段は、前記在庫切れ通知判定手段の判定結果に基づいて、以降の前記入荷通知の通知態様を変更する、ことを特徴とする。

また、本発明の一態様では、前記在庫切れ通知システムは、前記入荷通知が前記入荷通知要求を受け付けたユーザに提示されたか否かを判定する入荷通知判定手段を更に含み、前記入荷通知手段は、前記入荷通知判定手段の判定結果に基づいて、以降の前記入荷通知の通知態様を変更する、ことを特徴とする。

また、本発明の一態様では、前記在庫切れ通知システムは、前記在庫切れ通知が行われた後に、前記商品ページに前記入荷通知要求を受け付けたユーザがアクセスしたか否かを判定するアクセス判定手段を更に含み、前記入荷通知手段は、前記アクセス判定手段の判定結果に基づいて、以降の前記入荷通知の通知態様を変更する、ことを特徴とする。

また、本発明の一態様では、前記入荷通知は、複数種類の通知媒体のうちの少なくとも一つを用いて行われ、前記入荷通知手段は、前記複数種類の通知媒体のうちで使用する通知媒体の種類を変更することによって、前記入荷通知の通知態様を変更する、ことを特徴とする。

また、本発明の一態様では、前記入荷通知は、複数種類の雛型のうちの少なくとも一つを用いて行われ、前記入荷通知手段は、前記複数種類の通知媒体のうちで使用する雛型の種類を変更することによって、前記入荷通知の通知態様を変更する、ことを特徴とする。

また、本発明の一態様では、前記在庫切れ通知は、前記入荷通知要求を受け付けたユーザに対して送信される電子メールであり、前記在庫切れ通知システムは、前記入荷通知要求を受け付けたユーザによる電子メールの開封時点に関する時点情報を取得する手段を更に含み、前記在庫切れ通知手段は、前記時点情報に基づいて、前記在庫切れ通知の送信時点を決定する、ことを特徴とする。

また、本発明の一態様では、前記入荷通知は、前記入荷通知要求を受け付けたユーザに対して送信される電子メールであり、前記在庫切れ通知システムは、前記入荷通知要求を受け付けたユーザによる電子メールの開封時点に関する時点情報を取得する手段を更に含み、前記入荷通知手段は、前記時点情報に基づいて、前記入荷通知の送信時点を決定する、ことを特徴とする。

また、本発明の一態様では、前記在庫切れ通知システムは、前記入荷通知が前記入荷通知要求を受け付けたユーザに提示されたか否かを判定する入荷通知判定手段を更に含み、前記在庫切れ通知手段は、前記入荷通知判定手段の判定結果に基づいて、前記在庫切れ通知を行う、ことを特徴とする。

また、本発明の一態様では、前記通知制御システムは、前記入荷通知要求を受け付けたユーザにより指定される前記商品の数を取得する手段を更に含み、前記在庫切れ通知手段は、前記商品の現在の在庫数と前記入荷通知要求を受け付けたユーザにより指定された数とに基づいて、前記商品の在庫が再びなくなったと判定された場合、前記入荷通知要求を受け付けたユーザに対する在庫切れ通知を行う、ことを特徴とする。

本発明によれば、入荷通知要求をしたユーザが在庫のない商品ページにアクセスしてしまう可能性を軽減することが可能になる。

本発明の実施形態に係る通信販売システムの全体構成の一例を示す図である。 販売管理サーバのハードウェア構成図である。 ユーザ端末のハードウェア構成図である。 商品ページの画面例を示す図である。 商品の在庫がない場合の商品ページの画面例を示す図である。 入荷通知メールの一例を示す図である。 在庫切れ通知メールの一例を示す図である。 通信販売システムで実現される機能ブロックの一例を示す機能ブロック図である。 在庫データのデータ格納例を示す図である。 ユーザデータのデータ格納例を示す図である。 入荷通知データのデータ格納例を示す図である。 通信販売システムで実行される処理を示す図である。 通信販売システムで実行される処理を示す図である。 変形例の機能ブロック図である。 在庫後切れ通知が画面に表示される場合を説明するための図である。 各通知媒体の使用状況を示す図である。 各雛型の使用状況を示す図である。 変形例（４）における処理の概要を示す図である。

［１．通信販売システムのハードウェア構成］
以下、本発明の実施形態の例について図面に基づき詳細に説明する。なお、ここでは、本発明に係る通知制御システムを、インターネットを利用して商品を販売する通信販売システムに適用した場合について説明する。

図１は、本発明の実施形態に係る通信販売システムの全体構成の一例を示す図である。図１に示すように、通信販売システム１は、販売管理サーバ１０（在庫切れ通知装置）、データベース１５、ユーザ端末２０、及び店舗端末３０を含む。販売管理サーバ１０は、通信ネットワーク２を介して、ユーザ端末２０及び店舗端末３０とデータ送受信可能に接続される。

図２は、販売管理サーバ１０のハードウェア構成図である。販売管理サーバ１０は、例えば、サーバコンピュータである。図２に示すように、販売管理サーバ１０は、制御部１１、記憶部１２、光ディスクドライブ部１３、及び通信部１４を含む。

制御部１１は、例えば、一又は複数のマイクロプロセッサを含む。制御部１１は、記憶部１２に記憶されたオペレーティングシステム又はプログラムに従って処理を実行する。

記憶部１２は、主記憶部及び補助記憶部を含む。例えば、主記憶部はＲＡＭであり、補助記憶部は、ハードディスク又はソリッドステートドライブ等である。

光ディスクドライブ部１３は、光ディスク（情報記憶媒体）に記録されたプログラムやデータを読み出す。光ディスクに記憶されたプログラムやデータは、光ディスクドライブ部１３を介して記憶部１２に供給される。即ち、光ディスクに記憶されたプログラムやデータは、光ディスクドライブ部１３によって読み出され、記憶部１２に記憶される。

なお、販売管理サーバ１０は、光ディスク以外の情報記憶媒体（例えばメモリカード）に記憶されたプログラム又はデータを読み出すための構成要素を含むようにしてもよい。そして、光ディスク以外の情報記憶媒体を介してプログラムやデータが、記憶部１２に供給されるようにしてもよい。

通信部１４は、ネットワークカードを含む。通信部１４は、通信ネットワーク２を介してデータ通信を行うためのものである。プログラム及びデータは、通信ネットワーク２を介して記憶部１２に供給されるようにしてもよい。

販売管理サーバ１０は、データベース１５にアクセス可能になっている。なお、データベース１５は、販売管理サーバ１０に構築されていてもよいし、販売管理サーバ１０とは別のサーバに構築されていてもよい。

データベース１５には、ユーザに商品を提供するために必要な各種情報が記憶される。データベース１５に記憶される情報については後述する（図９〜図１１参照）。

図３は、ユーザ端末２０のハードウェア構成図である。ユーザ端末２０は、ユーザが操作するコンピュータであり、例えば、携帯電話機（スマートフォンを含む）、携帯情報端末（タブレット型コンピュータを含む）、又はパーソナルコンピュータ等である。図３に示すように、ユーザ端末２０は、制御部２１、記憶部２２、通信部２３、操作部２４、及び表示部２５を含む。なお、制御部２１、記憶部２２、及び通信部２３のハードウェア構成は、制御部１１、記憶部１２、及び通信部１４と略同様であるので説明を省略する。

操作部２４は、ユーザが操作を行うためのものである。例えば、操作部２４は、マウスやキーボード、タッチパネル等である。操作部２４は、ユーザによる操作内容を制御部２１に伝達する。

表示部２５は、例えば、液晶表示部又は有機ＥＬ表示部等である。表示部２５は、制御部２１の指示に従って画面を表示する。

店舗端末３０は、店舗に設置される情報処理装置である。ここでは、説明の簡略化のために店舗端末３０の詳細な構成は省略するが、店舗端末３０は、例えば、商品の在庫数を更新可能な公知のパーソナルコンピュータ等である。店舗端末３０は、店舗のスタッフにより操作される。当該操作内容に関するデータは、通信ネットワーク２を介して販売管理サーバ１０に送信される。

［２．ユーザが商品を購入するまでの流れ］
次に、表示部２５に表示される画面を参照して、ユーザが商品を購入するまでの流れについて説明する。本実施形態では、ユーザがユーザ端末２０を操作して販売管理サーバ１０にアクセスすると、商品を購入するための商品ページが表示部２５に表示される。

図４は、商品ページの画面例を示す図である。図４に示すように、商品ページ４０には、店舗で取り扱う商品に関する基本情報４２と、現在の商品の在庫数４４と、ユーザが商品の購入数を入力するための入力フォーム４６と、ユーザが商品を購入するための購入ボタン４８と、が表示される。

図４の画面例では、在庫数４４が示すように、商品の在庫が残っているのでユーザは商品を購入することができる。例えば、ユーザが、商品の購入数を入力フォーム４６に入力して購入ボタン４８を選択すると、配送先や決済方法等を入力するためのページに画面遷移し、商品を購入するための操作が完了する。

商品を購入するための操作が完了すると、購入内容に応じてデータベース１５が更新される。例えば、ユーザが商品を購入した数だけ、当該商品の在庫数４４が減少するように、データベース１５が更新される。なお、ユーザによる購入内容を示す情報は、販売管理サーバ１０から店舗端末３０に送信され、店舗のスタッフにより商品の配送作業が行われる。

上記のように、商品の在庫が残っている場合は、ユーザは商品ページ４０から商品を購入することができるが、商品の在庫がなくなった場合には、商品ページ４０から商品を購入することができない。

図５は、商品の在庫がない場合の商品ページ４０の画面例を示す図である。図５に示すように、在庫切れのため商品を購入することができない旨を示すメッセージ５０が表示される。ここでは、入力フォーム４６及び購入ボタン４８が商品ページ４０から消去され、ユーザが商品を注文することができないようになっている。

また、図５に示すように、入荷通知要求ボタン５２が商品ページ４０に表示される。ユーザが入荷通知要求ボタン５２を選択すると、在庫切れの商品が入荷した場合に、当該ユーザに対して入荷通知が行われる。ここでは、入荷通知の一例として、電子メールがユーザに送信される場合を例に挙げて説明する。以降、入荷通知として送信される電子メールを、単に、入荷通知メールという。

図６は、入荷通知メールの一例を示す図である。図６に示すように、入荷通知メール６０には、商品が入荷したことを示す件名６２及びメッセージ６４と、商品ページ４０へのリンク６６と、が含まれる。ユーザが入荷通知メール６０を開封してリンク６６を選択すると、表示部２５に商品ページ４０が表示される。例えば、ユーザが商品ページ４０にアクセスした時点で商品の在庫がまだ残っていた場合には、図４に示すような商品ページ４０が表示され、ユーザは商品を購入することができる。

一方、入荷した商品がすぐに売れてしまった場合等には、ユーザがリンク６６を選択して商品ページ４０にアクセスしても、在庫が再びなくなっていることがある。この場合、ユーザは商品を購入することができない。このため、本実施形態では、入荷通知要求に対応する商品の在庫が再びなくなった場合に、在庫切れ通知が送信される。入荷通知と同様に、在庫切れ通知の一例として、電子メールがユーザに送信される場合を例に挙げて説明する。以降、在庫切れ通知として送信される電子メールを、単に、在庫切れ通知メール７０という。

図７は、在庫切れ通知メール７０の一例を示す図である。図７に示すように、在庫切れ通知メール７０には、商品の在庫が再びなくなったことを示す件名７２及びメッセージ７４と、商品ページ４０へのリンク７６と、が含まれる。このように、本実施形態では、入荷通知メール６０が送信された後において、再び商品の在庫がなくなった場合に、ユーザに対して在庫切れ通知メール７０が送信されることにより、在庫が再びなくなった商品ページにユーザがアクセスしてしまう可能性を軽減する構成になっている。以降、当該技術の詳細について説明する。

［３．通信販売システムにおいて実現される機能］
図８は、通信販売システム１で実現される機能ブロックの一例を示す機能ブロック図である。図８に示すように、データ記憶部８０と、在庫データ取得部８２と、入荷通知要求受付部８４と、入荷通知部８６と、アクセス履歴取得部８８と、在庫切れ通知部９０と、を含む。これら各機能のうち、データ記憶部８０は、データベース１５を主として実現され、他の各機能は、制御部１１を主として実現される。

［３−１．データ記憶部］
データ記憶部８０は、商品を販売するために必要な各種データを記憶する。ここでは、データ記憶部８０が、商品の在庫に関する在庫データと、通信販売システム１を利用する各ユーザに関するユーザデータと、入荷通知要求をしたユーザを識別するための入荷通知データと、を記憶する場合を例に挙げて説明する。

［在庫データ］
図９は、在庫データのデータ格納例を示す図である。図９に示すように、在庫データは、店舗を識別する店舗ＩＤと、店舗で取り扱う商品を識別する商品ＩＤと、商品の在庫数と、が関連付けられて格納される。在庫データは、ユーザによる購入操作又は店舗のスタッフによる操作に応じて更新される。

例えば、在庫データは、店舗の利用状況に応じて更新される。ここでの利用状況とは、通信販売システム１における店舗の利用状況と、現実世界における店舗の利用状況（例えば、店舗を実際に訪れる客による商品の購入状況）と、を含む意味である。即ち、例えば、通信販売用の仮想店舗において商品が販売された場合、及び、現実世界の店舗において商品が販売された場合に、在庫データの内容が更新される。

また、在庫データは、商品の入荷状況に応じて更新される。例えば、店舗で商品が入荷する場合、店舗のスタッフによる操作内容に基づいて、在庫データの内容が更新される。ここでは、店舗のスタッフが商品の入荷数を入力すると、在庫データのうち、当該店舗の店舗ＩＤ及び当該商品の商品ＩＤに対応するレコードの在庫数が、当該入力された入荷数だけ増加する。

［ユーザデータ］
図１０は、ユーザデータのデータ格納例を示す図である。図１０に示すように、ユーザデータには、ユーザを識別するユーザＩＤと、ユーザに関する基本情報（例えば、名前、連絡先、配送先等）と、ユーザによる商品ページ４０へのアクセスの履歴に関するアクセス履歴と（例えば、ユーザがアクセスした商品ページ４０のＵＲＬ、アクセス日時等）と、が関連付けられて格納される。

例えば、ユーザが通信販売システム１の利用登録を行った場合に、ユーザデータに新たなレコードが生成される。そして、当該レコードに、利用登録をしたユーザに付与されるユーザＩＤと、ユーザが入力した基本情報と、が格納される。利用登録が完了すると、ユーザは、商品ページ４０から商品を購入することができる。ユーザが商品ページ４０にアクセスするたびに、当該ユーザに対応するアクセス履歴が更新される。

［入荷通知データ］
図１１は、入荷通知データのデータ格納例を示す図である。図１１に示すように、入荷通知データには、ユーザＩＤと、店舗ＩＤと、商品ＩＤと、入荷通知要求の受付日時と、入荷通知フラグと、入荷通知日時と、が格納される。本実施形態では、入荷通知データにユーザＩＤが格納されているユーザが、入荷通知要求をしたユーザに相当する。

例えば、商品ページ４０においてユーザが入荷通知要求ボタン５２を選択した場合、入荷通知データに新たなレコードが作成される。そして、当該レコードに、入荷通知要求ボタン５２を選択したユーザのユーザＩＤと、商品ページ４０に対応する商品を扱う店舗の店舗ＩＤと、当該商品の商品ＩＤと、現在の日時と、が関連付けられて格納される。なお、入荷通知フラグには、初期値（ここでは「１」）が格納される。更に、この時点では、まだ入荷通知メール６０が送信されていないので、入荷通知日時にはデータが格納されない。

入荷通知フラグは、ユーザに対して入荷通知を行うべきか否かを識別するための識別情報である。ここでは、入荷通知フラグが「１」（第１の値）であることは、例えば、まだ入荷通知をしておらず、入荷通知をすべきことを示し、入荷通知フラグが「０」（第２の値）であることは、例えば、既に入荷通知済みであり、入荷通知をしないことを示す。入荷通知フラグの値は、入荷通知メール６０が送信された場合に「１」のまま変更されないようにしてもよいし、「１」から「０」に更新される（即ち、再入荷通知を行わないように識別情報を設定する）ようにしてもよい。

本実施形態では、後述する入荷通知部８６が入荷通知メールをユーザに送信すると、当該ユーザに対応する入荷通知日時の値が更新される。例えば、入荷通知部８６が入荷通知メールを送った場合の現在日時が、入荷通知日時として格納される。即ち、入荷通知日時に時刻が格納されていることは、既に入荷通知が行われていることを示している。

なお、データ記憶部８０が記憶するデータは、上記の例に限られない。データ記憶部８０は、ユーザが商品を購入するために必要な各種データを記憶するようにすればよい。例えば、データ記憶部８０は、入荷通知や在庫切れ通知の内容に関するデータ（例えば、入荷通知メール６０や在庫切れ通知メール７０の雛型）を記憶していてもよい。他にも例えば、データ記憶部８０は、商品の基本情報（例えば、ジャンル、画像、価格、配送料等）を示すデータを記憶していてもよいし、各商品ページ４０に関するデータ（例えば、ＵＲＬ、画像、レイアウト等）を記憶していてもよい。

［３−２．在庫データ取得部］
在庫データ取得部８２は、商品の在庫に関するデータを記憶する手段（例えば、データ記憶部８０）の記憶内容を取得する。本実施形態では、在庫データ取得部８２は、在庫データに格納された各商品の在庫数を取得することになる。

［３−３．入荷通知要求受付部］
入荷通知要求受付部８４は、ユーザによる商品の入荷通知要求を受け付ける。ここでは、ユーザが所与の操作をすること（例えば、入荷通知要求ボタン５２を選択すること）が、入荷通知要求をすることに相当する。

例えば、入荷通知要求受付部８４は、商品ページ４０に含まれる所与の指標（例えば、入荷通知要求ボタン５２）がユーザにより選択された場合に、入荷通知要求を受け付ける。即ち、入荷通知要求受付部８４は、ユーザが入荷通知要求ボタン５２を選択したことの通知を受け付けることによって、入荷通知要求を受け付ける。

［３−４．入荷通知部］
入荷通知部８６は、商品が入荷した場合に、入荷通知要求を受け付けたユーザ（即ち、入荷通知要求をしたユーザ）に対する入荷通知を行う。ここでは、メッセージを送信すること又は画像を表示させることが、入荷通知をすることに相当する。即ち、入荷通知部８６は、商品が入荷したことを示すメッセージ（例えば、入荷通知メール６０）を送信したり、商品が入荷したことを示す画像を表示部２５に表示させたりすることによって、入荷通知を行う。なお、この点は後述する在庫切れ通知も同様である。

入荷通知部８６は、入荷通知要求を受け付けたユーザに対する入荷通知をすべきか否かを識別する識別情報（例えば、入荷通知フラグ）に基づいて、当該ユーザに対する入荷通知を行うか否かを決定する。例えば、在庫のない商品が入荷した場合、入荷通知部８６は、入荷通知データを参照して、当該商品の入荷通知要求をしたユーザを特定する。そして、入荷通知部８６は、当該特定したユーザのうち入荷通知フラグが「１」のユーザに対して入荷通知メール６０を送信し、入荷通知フラグが「０」のユーザに対しては入荷通知メール６０を送信しない。更に、入荷通知部８６は、ユーザに対して入荷通知メール６０を送信すると、現在の日時が送信時刻に格納される。

［３−５．アクセス履歴取得部］
アクセス履歴取得部８８は、入荷通知要求を受け付けたユーザによる、商品の商品ページ４０へのアクセス履歴を取得する。本実施形態では、アクセス履歴取得部８８は、ユーザデータに格納された各ユーザのアクセス履歴を取得することになる。

［３−６．在庫切れ通知部］
在庫切れ通知部９０は、入荷通知が行われた後に商品の在庫がなくなった場合、入荷通知要求を受け付けたユーザに対する在庫切れ通知を行う。ここで、入荷通知が行われた後とは、入荷通知メール６０の送信日時よりも後の時点である。

例えば、在庫切れ通知部９０は、在庫データが示す在庫数が基準数（例えば、１）以上であるか否かを判定することによって、商品の在庫がなくなったか否かを判定する。商品の在庫数が基準数以上であることが、商品の在庫があることに相当し、商品の在庫数が基準数未満であることが、商品の在庫がないことに相当する。即ち、商品の在庫数が基準数以上の状態から基準数未満の状態に変化することが、商品がなくなることに相当する。

本実施形態では、在庫切れ通知部９０は、入荷通知が行われた時点から、商品の在庫がなくなった時点までの間に、ユーザが商品ページ４０にアクセスした履歴がアクセス履歴に存在しない場合、在庫切れ通知を行う。例えば、在庫切れ通知部９０は、入荷通知が行われた後、かつ、ユーザが商品の商品ページ４０にアクセスする前に、商品の在庫がなくなったか否かをアクセス履歴に基づいて判定する。ユーザが商品ページ４０にアクセスする前とは、商品ページ４０へのアクセスを受け付けた時点よりも前の時点であり、例えば、商品ページ４０が表示部２５に表示される時点よりも前の時点である。在庫切れ通知部９０は、入荷通知が行われた場合に、ユーザが商品ページ４０にアクセスすることなく、商品の在庫が再びなくなったか否かを判定することになる。

例えば、在庫切れ通知部９０は、入荷通知後かつアクセス前に商品の在庫が再びなくなったとアクセス履歴に基づいて判定された場合、在庫切れ通知を行う。一方、在庫切れ通知部９０は、入荷通知後かつアクセス前に商品の在庫が再びなくなったと判定されない場合、在庫切れ通知を行わない。

なお、本実施形態では、ユーザが実際に入荷通知メール６０を開封したか否かに関らず、在庫切れ通知部９０による判定処理が実行されるものとする。在庫切れ通知部９０は、既に入荷通知を行ったユーザに対して、在庫切れ通知を行うことになる。即ち、在庫切れ通知部９０は、在庫切れ通知を行うか否かを制御するともいえる。

また、ユーザに対して在庫切れ通知が行われた場合、当該ユーザのユーザＩＤと、在庫切れ通知に対応する店舗の店舗ＩＤ及び商品の商品ＩＤと、在庫切れ通知が行われた日時と、が関連付けられてデータ記憶部８０に記録されるようにしてもよい。即ち、在庫切れ通知の履歴がデータ記憶部８０に残されるようにしてもよい。

更に、本実施形態においては、在庫切れ通知部９０が、商品の在庫がなくなったか否かを判定する態様を説明したが、商品の在庫がなくなったか否かを判定する処理自体は、在庫切れ通知部９０以外で実行されるようにしてもよく、例えば、他のシステムにおいて実行されるようにしてもよい。この場合、例えば、当該他のシステムにおいて商品の在庫がなくなったか否かが判定され、在庫切れ通知部９０は、当該判定結果を取得することになる。即ち、在庫切れ通知部９０は、当該取得した判定結果に基づいて、在庫切れ通知メール７０を送信する。

［４．実施形態において実行される処理］
図１２及び図１３は、通信販売システム１で実行される処理を示す図である。販売管理サーバ１０の制御部１１が、記憶部１２に記憶されたプログラムに従って動作し、ユーザ端末２０の制御部２１が、記憶部２２に記憶されたプログラムに従って動作することにより、図１２及び図１３に示す処理が実行され、各機能ブロックが実現される。なお、説明の簡略化のため、下記の処理が実行されるにあたり、販売管理サーバ１０とユーザ端末２０とのセッションが確立されており、更に、ユーザが所与のログイン操作を完了しているものとする。

図１２に示すように、まず、販売管理サーバ１０においては、制御部１１は、ユーザから商品ページ４０の表示要求を受け付けたか否かを判定する（Ｓ１）。なお、ユーザ端末２０から販売管理サーバ１０に情報が送信される場合には、ＩＰアドレスやユーザＩＤ等が送信されるものとする。これにより、販売管理サーバ１０は、どのユーザが商品ページ４０にアクセスしているかを特定することができる。

商品ページ４０の表示要求を受け付けないと判定された場合（Ｓ１；Ｎ）、Ｓ７の処理に移行する。一方、商品ページ４０の表示要求を受け付けたと判定された場合（Ｓ１；Ｙ）制御部１１は、商品ページ４０のＨＴＭＬデータを生成し、表示要求をしたユーザが操作するユーザ端末２０に送信する（Ｓ２）。なお、Ｓ２においては、商品ページ４０の商品の在庫がある場合には、制御部１１は、表示要求をしたユーザが当該商品の入荷通知要求をしたか否かを判定する。そして、入荷通知要求をしたユーザである場合には、制御部１１は、当該ユーザの入荷通知フラグを「０」に変更する。即ち、在庫がある状態で商品ページ４０にアクセスした場合には、制御部１１は、以降の入荷通知メール６０を送らないように、入荷通知フラグの値を更新することになる。

ユーザ端末２０においては、ＨＴＭＬデータを受信すると、制御部２１は、商品ページ４０を表示部２５に表示させる（Ｓ３）。商品の在庫がある場合には、Ｓ３において図４に示す商品ページ４０が表示される。以降は、ユーザの操作に応じて商品の購入処理が行われて、在庫データが適宜更新される。当該購入処理は公知の処理であるため、説明を省略する。一方、商品の在庫がない場合には、Ｓ４において図５に示す商品ページ４０が表示され、ユーザは商品を購入することができない。

制御部２１は、入荷通知要求ボタン５２が選択された否かを判定する（Ｓ４）。入荷通知要求ボタン５２が選択されたと判定された場合（Ｓ４；Ｙ）、制御部２１は、入荷通知要求ボタン５２が選択されたことを示す通知（即ち、入荷通知要求）を、販売管理サーバ１０に送信する（Ｓ５）。

販売管理サーバ１０においては、入荷通知要求ボタン５２が選択されたことを示す通知（入荷通知要求）を受信すると、制御部１１は、入荷通知データを更新する（Ｓ６）。Ｓ６においては、制御部１１は、入荷通知データに新たなレコードを作成し、当該レコードに、入荷通知要求ボタン５２を選択したユーザのユーザＩＤと、商品ページ４０に対応する店舗の店舗ＩＤと、商品ページ４０に対応する商品の商品ＩＤと、現在の日時と、入荷通知フラグの初期値と、を格納する。なお、先述したように、入荷通知メール６０が送信されるまでは、入荷通知日時にはデータが格納されない。

制御部１１は、店舗端末３０から、商品の入荷を受け付けたか否かを判定する（Ｓ７）。例えば、店舗のスタッフが店舗端末３０を操作して商品の入荷数を入力すると、当該店舗の店舗ＩＤと当該商品の商品ＩＤと当該入力された商品数とを含むデータが販売管理サーバ１０に送信される。Ｓ７においては、制御部１１は、当該データを受信したか否かを判定することになる。

商品の入荷を受け付けたと判定された場合（Ｓ７；Ｙ）、制御部１１は、当該受け付けた内容に基づいて、在庫データを更新する（Ｓ８）。Ｓ８においては、制御部１１は、在庫データの各レコードうち、店舗端末３０から受信したデータが示す店舗ＩＤ及び商品ＩＤと一致するレコードの在庫数を更新する。

制御部１１は、Ｓ７における受付結果に基づいて、在庫のない商品が入荷したか否かを判定する（Ｓ９）。Ｓ９においては、制御部１１は、在庫数が基準数（例えば、１）未満の商品の在庫が入荷したか否かを判定することになる。

在庫のない商品が入荷したと判定された場合（Ｓ９；Ｙ）、制御部１１は、入荷通知データを参照し、当該入荷した商品の入荷通知要求をしたユーザがいるか否かを判定する（Ｓ１０）。Ｓ１０においては、入荷通知データの各レコードのうちで、商品を入荷した店舗の店舗ＩＤ及び当該商品の商品ＩＤとが格納されているレコードがあるか否かを判定する。

入荷通知要求をしたユーザがいると判定された場合（Ｓ１０；Ｙ）、制御部１１は、当該ユーザに対して入荷通知メール６０を送信する（Ｓ１１）。Ｓ１１においては、制御部１１は、入荷した商品に関する入荷通知メール６０を生成し、入荷通知データにユーザＩＤが格納されているユーザに対して送信することになる。

図１３に移り、制御部１１は、入荷通知データを参照し、入荷通知データを更新する（Ｓ１２）。Ｓ１２においては、制御部１１は、入荷通知メール６０に対応するユーザＩＤ、店舗ＩＤ、及び商品ＩＤが格納されているレコードに、現在の日時を格納する。制御部１１は、入荷通知メール６０の送信時間を更新することになる。

制御部１１は、在庫データを参照し、在庫がなくなった商品が存在するか否かを判定する（Ｓ１３）。Ｓ１３においては、制御部１１は、在庫データを参照し、在庫数が基準数以上の状態から基準数未満の状態に変化した商品（例えば、在庫数が１以上の状態から０に変化した商品）が存在するか否かを判定することになる。

在庫がなくなった商品が存在すると判定された場合（Ｓ１３；Ｙ）、制御部１１は、入荷通知データを参照し、当該商品の入荷通知メール６０が過去に送信されたか否かを判定する（Ｓ１４）。Ｓ１４においては、制御部１１は、入荷通知データを参照し、在庫がなくなった商品を扱う店舗の店舗ＩＤ及び当該商品の商品ＩＤが格納されたレコードがあるか否かを判定することになる。

入荷通知メール６０が過去に送信されたと判定された場合（Ｓ１４；Ｙ）、制御部１１は、当該入荷通知メール６０の送信後において、当該商品の商品ページ４０にユーザがアクセスしているか否かを判定する（Ｓ１５）。Ｓ１５においては、制御部１１は、入荷通知データを参照し、在庫がなくなった商品の入荷通知メール６０が送信された日時を特定する。そして、ユーザデータのアクセス履歴を参照し、上記特定された送信日時よりも後に、ユーザが商品ページ４０にアクセスしているか否かを判定する。

商品ページ４０にユーザがアクセスしていないと判定された場合（Ｓ１５；Ｙ）、制御部１１は、当該ユーザに在庫切れ通知メール７０を送信する（Ｓ１６）。Ｓ１６においては、制御部１１は、店舗において在庫がなくなった商品に対応する在庫切れ通知メール７０を生成して、当該店舗の店舗ＩＤ及び当該商品の商品ＩＤが関連付けられているユーザＩＤのユーザに対して、在庫切れ通知メール７０を送信することになる。

制御部１１は、終了条件が満たされるか否かを判定する（Ｓ１７）。終了条件は、本処理を終了するために予め定められた条件であればよい。例えば、所定の時刻が到来したか否か、又は、販売管理サーバ１０を再起動するか否か等の条件である。

終了条件が満たされると判定された場合（Ｓ１７；Ｙ）、本処理は終了する。終了条件が満たされないと判定された場合（Ｓ１７；Ｎ）、Ｓ１の処理に戻る。

上記実施形態の通信販売システム１によれば、在庫切れ通知メール７０をユーザに送信することによって、在庫のない商品の商品ページ４０にユーザがアクセスしてしまう可能性を軽減することができる。更に、商品の在庫が再びなくなる前に、入荷通知要求をしたユーザが商品ページ４０にアクセスしていた場合には、当該ユーザが既に商品を購入している可能性があるので、在庫切れ通知メール７０を送らないようにすることによって、不必要な通知がユーザに送られることを防止することができる。

［５．変形例］
なお、本発明は、以上に説明した実施の形態に限定されるものではない。本発明の趣旨を逸脱しない範囲で、適宜変更可能である。

図１４は、変形例の機能ブロック図である。図１４に示すように、下記に説明する変形例では、上記実施形態の機能に加えて、フラグ設定部９２、在庫切れ通知判定部９４、入荷通知判定部９６、アクセス判定部９８、時点情報取得部１００、及び、基準数取得部１０２が実現される。これら各機能は、制御部１１を主として実現される。

（１）例えば、実施形態においては、在庫切れ通知部９０が、アクセス履歴に基づいて在庫切れ通知メール７０を送信するか否かを決定する場合を説明したが、他の方法により、在庫切れ通知メール７０を送信するか否かが制御されるようにしてもよい。例えば、各ユーザの入荷通知フラグの値に基づいて、商品の在庫がなくなる前に当該ユーザが商品ページ４０にアクセスしたか否かを推測し、在庫切れ通知メール７０を送信するか否かが決定されるようにしてもよい。

本変形例の販売管理サーバ１０は、フラグ設定部９２を含む。フラグ設定部９２は、入荷通知が行われてから商品の在庫がなくなるまでの間に、入荷通知要求を受け付けたユーザが前記商品の商品ページにアクセスした場合、以降の入荷通知を行わないように識別情報（例えば、入荷通知フラグ）を設定する。ここでは、入荷通知フラグを「０」にすることが、入荷通知を行わないように識別情報を設定することに相当する。即ち、フラグ設定部９２は、入荷通知メール６０が送信されてから商品の在庫がなくなるまでの期間内において、ユーザが商品ページ４０にアクセスした場合、当該ユーザに対応する入荷通知フラグの値を「０」に変更して、以降の入荷通知メール６０が送られないように制御する。これは、在庫がある状態で商品ページ４０にアクセスした場合には、ユーザはそのまま商品を購入する可能性が高いため、入荷通知メール６０が不要になる可能性が高いからである。

在庫切れ通知部９０は、入荷通知が行われた後において、識別情報（例えば、入荷通知フラグ）が入荷通知を行うことを示している状態で、商品の在庫がなくなった場合、入荷通知要求を受け付けたユーザに対する在庫切れ通知を行う。ここでは、在庫切れ通知部９０は、入荷通知が行われた後において、識別情報（例えば、入荷通知フラグ）が入荷通知を行うことを示している状態で、商品の在庫がなくなったか否かを識別情報に基づいて判定する。例えば、在庫切れ通知部９０は、入荷通知フラグが「１」である状態で商品の在庫がなくなった場合、在庫切れ通知メール７０を送信する。一方、在庫切れ通知部９０は、入荷通知フラグが「０」である状態で商品の在庫がなくなった場合、在庫切れ通知メール７０を送信しない。即ち、ここでは、アクセス履歴ではなく、入荷通知フラグの値を参照して、ユーザが商品ページ４０にアクセスしたか否かを推測することになる。

変形例（１）によれば、入荷通知フラグを用いることによって、ユーザが商品ページ４０にアクセスしたか否かを推測し、在庫切れ通知メール７０を送信すべきか否かを決定することができる。

（２）また例えば、電子メール以外の方法を使って在庫切れ通知を行ったり、在庫切れ通知メール７０の雛型を変更したりすることによって、ユーザが在庫切れ通知に気付きやすくするようにしてもよい。

（２−１）例えば、ユーザが在庫切れ通知メール７０を開封していない場合には、当該ユーザに対する在庫切れ通知のしかたを変えるようにしてもよい。

本変形例の販売管理サーバ１０は、在庫切れ通知判定部９４を含む。在庫切れ通知判定部９４は、在庫切れ通知がユーザに提示されたか否かを判定する。在庫切れ通知判定部９４は、過去の在庫切れ通知（即ち、既にユーザに対して行われた在庫切れ通知。例えば、過去の所定期間内に行われた在庫切れ通知）がユーザに提示されたか否かを判定する。当該判定対象となる在庫切れ通知は、直近の在庫切れ通知であってもよいし、直近の在庫切れ通知及びそれよりも前に行われた在庫切れ通知であってもよい。

また、「在庫切れ通知がユーザに提示される」とは、ユーザに対応する表示部２５において、在庫切れ通知が表示されることであり、例えば、在庫切れ通知メール７０が開封されることである。ここで、在庫切れ通知がユーザに提示されたか否かを判定するための方法は、在庫切れ通知として用いる通知媒体（チャンネル）によって異なる。

在庫切れ通知として電子メールを用いる場合には、在庫切れ通知判定部９４は、在庫切れ通知メール７０をユーザが開封したか否かを判定する。例えば、在庫切れ通知メール７０が画像タグを含むＨＴＭＬ形式の電子メールの場合、ユーザが在庫切れ通知メール７０を開封すると、販売管理サーバ１０に画像の読み込み要求が送信される。在庫切れ通知判定部９４は、当該読み込み要求がユーザ端末２０から受信したか否かを判定することによって、在庫切れ通知メール７０をユーザが開封したか否かを判定する。

なお、この場合、画像タグに所与の引数を挿入しておいて、販売管理サーバ１０が読み込み要求を受け付けた際に当該引数を取得することにより、販売管理サーバ１０は、どのユーザが画像の読み込み要求をしたか（即ち、在庫切れ通知メール７０を開封したか）を特定することができる。更に、電子メールを開封したか否かを判定するための方法は、これに限られず、公知の種々の手法を適用可能である。例えば、メールソフトの開封確認機能を使用することによって、在庫切れ通知メール７０が開封されたか否かが判定されるようにしてもよい。

また、在庫切れ通知として、画面（ウェブブラウザ）に表示される画像又は文字列を用いる場合には、在庫切れ通知判定部９４は、ユーザデータのアクセス履歴を参照して、ユーザが当該画面を閲覧したか否かを判定する。

図１５は、在庫後切れ通知が画面に表示される場合を説明するための図である。図１５に示すように、例えば、各ユーザがブックマークしている商品ページ４０を示すブックマーク画面１１０に、入荷通知要求をした商品の在庫がなくなったことを示すメッセージ１１２が表示される。在庫切れ通知判定部９４は、ブックマーク画面１１０がユーザにより閲覧された場合、在庫切れ通知が提示されたと判定することになる。

なお、在庫切れ通知が表示される画面は、例えば、ブラウザに表示されるものであればよく、他にも例えば、各ユーザが閲覧済みの商品ページ４０を示すウェブページ、通信販売システム１に対応するトップページ、及び、ウェブブラウザにおけるツールバーの少なくとも一つが用いられるようにしてもよい。

また、在庫切れ通知判定部９４の判定結果を示すデータが、ユーザデータに格納されるようにしてもよい。例えば、データ記憶部８０に在庫切れ通知の履歴が記録される場合、在庫切れ通知がユーザに提示されたか否かを示す情報が更に格納されるようにしてもよい。過去の在庫切れ通知がユーザに提示されたと判定された場合には、当該情報が更新されることになる。

本変形例の在庫切れ通知部９０は、在庫切れ通知判定部９４の判定結果に基づいて、以降の在庫切れ通知の通知態様（通知方法）を変更する。以降の在庫切れ通知とは、今後ユーザに対して行われる在庫切れ通知のことである。通知態様とは、在庫切れ通知として用いる通知媒体の種類、又は、在庫切れ通知に含まれる文章の内容のことである。

［通知媒体を変える場合］
まず、在庫切れ通知として用いる通知媒体の種類を変えることによって、通知態様を変更する場合を説明する。例えば、在庫切れ通知が、複数種類の通知媒体のうちの少なくとも一つを用いて行われる場合、在庫切れ通知部９０は、複数種類の通知媒体のうちで使用する通知媒体の種類を変更することによって、在庫切れ通知の通知態様を変更する。

図１６は、各通知媒体の使用状況を示す図である。当該使用状況を示すデータは、データ記憶部８０に記憶されており、例えば、ユーザデータの各ユーザに対応するレコードに格納されているものとする。図１６に示すように、複数種類の通知媒体の各々の使用状況（例えば、使用回数）と、使用フラグと、が関連付けられて格納されている。在庫切れ通知として各通知媒体が使用されると、使用状況が更新されることになる。

使用フラグは、現在において在庫切れ通知として用いられている通知媒体を示すフラグである。例えば、使用フラグの値が「０」であることは、在庫切れ通知として使用されていないことを示し、使用フラグの値が「１」であることは、在庫切れ通知として使用されていることを示す。

在庫切れ通知部９０は、過去の在庫切れ通知がユーザに提示されていない場合、在庫切れ通知で用いる通知媒体の種類を変更する。本変形例では、使用フラグの値を変化させることが、通知媒体の種類を変更することに相当する。更に、ここでの通知媒体の種類を変更することは、通知媒体の種類の数を変更すること（即ち、在庫切れ通知で用いる通知媒体を追加又は削減すること）、及び、通知媒体の種類の数は変えずに在庫切れ通知で用いる種類を変更すること、の両者を含む意味である。

例えば、在庫切れ通知部９０は、現在使用していない通知媒体を用いて在庫切れ通知を行うように、通知媒体の種類を変更する。即ち、在庫切れ通知部９０は、通知媒体の使用フラグの値を「０」から「１」に変更する。以降、在庫切れ通知部９０は、当該変更された種類の通知媒体を用いて、在庫切れ通知を行うことになる。

また例えば、在庫切れ通知部９０は、過去の在庫切れ通知がユーザに提示された場合、在庫切れ通知で用いる通知媒体の種類を変更しない。即ち、在庫切れ通知部９０は、通知媒体の使用フラグの値を変更しない。この場合、ユーザが在庫切れ通知に気付いている可能性が高いので、以降においても、在庫切れ通知部９０は、以前の在庫切れ通知で用いた通知媒体と同じ種類の通知媒体を用いて在庫切れ通知を行うことになる。

［雛型を変える場合］
次に、在庫切れ通知の雛型を変えることによって、通知態様を変更する場合を説明する。ここでの雛型とは、在庫切れ通知に含まれる文字列であり、例えば、メッセージや件名の定型文（フォーマット）のことである。例えば、在庫切れ通知が、複数種類の雛型のうちの少なくとも一つを用いて行われる場合、在庫切れ通知部９０は、複数種類の通知媒体のうちで使用する雛型の種類を変更することによって、在庫切れ通知の通知態様を変更する。

図１７は、各雛型の使用状況を示す図である。当該使用状況を示すデータは、データ記憶部８０に記憶されており、例えば、ユーザデータの各ユーザに対応するレコードに格納されているものとする。図１７に示すように、複数種類の雛型の各々の使用状況（例えば、使用回数）と、使用フラグと、が関連付けられて格納されている。

使用フラグは、現在において在庫切れ通知として用いられている雛型を示すフラグである。例えば、使用フラグの値が「０」であることは、在庫切れ通知として使用されていないことを示し、使用フラグの値が「１」であることは、在庫切れ通知として使用されていることを示す。

在庫切れ通知部９０は、過去の在庫切れ通知がユーザに提示されていない場合、在庫切れ通知で用いる雛型の種類を変更する。本変形例では、使用フラグの値を変化させることが、雛型の種類を変更することに相当する。

例えば、在庫切れ通知部９０は、現在使用していない雛型を用いて在庫切れ通知を行うように、雛型の種類を変更する。即ち、在庫切れ通知部９０は、雛型の使用フラグの値を「０」から「１」に変更し、他の雛型の使用フラグの値を「０」にする。以降、在庫切れ通知部９０は、当該変更された種類の雛型を用いて、在庫切れ通知を行うことになる。

また例えば、在庫切れ通知部９０は、過去の在庫切れ通知がユーザに提示された場合、在庫切れ通知で用いる雛型の種類を変更しない。即ち、在庫切れ通知部９０は、各雛型の使用フラグの値を変更しない。この場合、ユーザが在庫切れ通知に気付いている可能性が高いので、以降においても、在庫切れ通知部９０は、前回の在庫切れ通知で用いた雛型と同じ種類の雛型を用いて在庫切れ通知を行う。

変形例（２−１）によれば、例えば、ユーザが在庫切れ通知メール７０を開封したか否かに応じて、在庫切れ通知の通知態様を変更することができ、ユーザ毎に気付きやすい通知態様で在庫切れ通知を行うことができる。

なお、在庫切れ通知部９０は、通知媒体及び雛型の少なくとも一方を変更すればよく、上記の態様を組み合わせて、通知媒体及び雛型の両方を変更するようにしてもよい。即ち、在庫切れ通知部９０は、在庫切れ通知判定部９４の判定結果に基づいて、在庫切れ通知として用いる通知媒体及び雛型の両方を変更するようにしてもよい。以降説明する変形例のうち、通知態様を変更する処理に関する変形例においても同様である。

（２−２）また例えば、入荷通知メール６０を開封したか否かに応じて、在庫切れ通知の態様を変更するようにしてもよい。

本変形例の販売管理サーバ１０は、入荷通知判定部９６を含む。入荷通知判定部９６は、入荷通知がユーザに提示されたか否かを判定する。入荷通知が提示されたか否かを判定する方法は、在庫切れ通知が提示されたか否かを判定する方法と同様であり、変形例（２−１）における在庫切れ通知判定部９４の説明の「在庫切れ通知」の文言を「入荷通知」と読み替えればよい。

即ち、入荷通知判定部９６は、入荷通知メール６０が開封されたか否かを判定したり、入荷通知を含む画面をユーザが閲覧したか否かを判定したりすることになる。更に、入荷通知がユーザに提示されたか否かを示す情報がユーザデータに格納され、入荷通知判定部９６の判定結果により当該情報が更新されるようにしてもよい点も、変形例（２−１）と同様である。

なお、入荷通知判定部９６は、在庫切れ通知メール７０が送信される前に入荷通知が提示されたか否かを判定するようにしてもよいし、在庫切れ通知メール７０が送信された後に入荷通知が提示されたか否かを判定するようにしてもよい。

在庫切れ通知部９０は、入荷通知判定部９６の判定結果に基づいて、以降の在庫切れ通知の通知態様を変更する。なお、在庫切れ通知の通知態様の変更方法自体は、変形例（２−１）と同様であり、通知媒体と雛型との少なくとも一方が変更されることになる。

例えば、在庫切れ通知部９０は、過去の入荷通知がユーザに提示されたと判定された場合、在庫切れ通知の通知態様を変更する。この場合、ユーザが入荷通知メール６０に気付いており、商品の在庫があると思っているので、落胆しないように在庫切れ通知を気付きやすくすることができる。即ち、在庫切れ通知部９０は、過去の入荷通知がユーザに提示されていないと判定された場合、在庫切れ通知の通知態様を変更しないことになる。

一方、在庫切れ通知部９０は、過去の入荷通知がユーザに提示されていないと判定された場合、在庫切れ通知の通知態様を変更するようにしてもよい。この場合、ユーザが入荷通知メール６０に気付いていないので、同じ電子メールである在庫切れ通知メール７０にも気付かない可能性があるため、在庫切れ通知の通知態様を変更して気付きやすくすることができる。即ち、在庫切れ通知部９０は、過去の入荷通知がユーザに提示されたと判定された場合、在庫切れ通知の通知態様を変更しないことになる。

変形例（２−２）によれば、例えば、入荷通知メール６０を開封したか否かに応じて、在庫切れ通知の通知態様を変更することができ、ユーザ毎に気付きやすい通知態様で在庫切れ通知を行うことができる。

（２−３）また例えば、在庫切れ通知メール７０の送信後に、ユーザが商品ページ４０にアクセスしたか否かに応じて、以降の在庫切れ通知メール７０の通知態様を変更するようにしてもよい。

本変形例の販売管理サーバ１０は、アクセス判定部９８を含む。アクセス判定部９８は、在庫切れ通知が行われた後に、商品ページ４０にユーザがアクセスしたか否かを判定する。例えば、アクセス判定部９８は、ユーザデータのアクセス履歴を参照し、入荷通知要求をした商品ページ４０に、在庫切れ通知が行われた後にアクセスしているか否かを判定する。

在庫切れ通知部９０は、アクセス判定部９８の判定結果に基づいて、以降の在庫切れ通知の通知態様を変更する。在庫切れ通知の通知態様の変更方法は、変形例（２−１）と同様であり、通知媒体と雛型との少なくとも一方が変更されることになる。

例えば、在庫切れ通知部９０は、アクセス判定部９８により商品ページ４０にユーザがアクセスしたと判定された場合、在庫切れ通知の通知態様を変更する。この場合、在庫のない商品ページ４０にアクセスして落胆した可能性があるため、以降の在庫切れ通知の通知態様を変更して気付きやすくすることができる。即ち、在庫切れ通知部９０は、アクセス判定部９８により商品ページ４０にユーザがアクセスしていないと判定された場合、在庫切れ通知の通知態様を変更しないことになる。

一方、例えば、在庫切れ通知部９０は、アクセス判定部９８により商品ページ４０にユーザがアクセスしていないと判定された場合、在庫切れ通知の通知態様を変更するようにしてもよい。この場合、在庫切れ通知に気付かずに商品ページ４０にアクセスしていない可能性があるので、以降の在庫切れ通知の通知態様を変更して気付きやすくすることができる。即ち、在庫切れ通知部９０は、アクセス判定部９８により商品ページ４０にユーザがアクセスしたと判定された場合、在庫切れ通知の通知態様を変更しないことになる。

変形例（２−３）によれば、例えば、在庫切れ通知メール７０の送信後に、ユーザが商品ページ４０にアクセスしたか否かに応じて、以降の在庫切れ通知メール７０の通知態様を変更することができ、ユーザ毎に気付きやすい通知態様で在庫切れ通知を行うことができる。

なお、上記変形例（２−１）〜（２−３）を組み合わせるようにしてもよい。即ち、在庫切れ通知部９０は、在庫切れ通知判定部９４の判定結果と、入荷通知判定部９６の判定結果と、アクセス判定部９８の判定結果と、の何れか二つ又は全てに基づいて、在庫切れ通知の通知態様を変更するようにしてもよい。例えば、ユーザが入荷通知メール６０も在庫切れ通知メール７０も開封せず、商品ページ４０にもアクセスしていない場合には、当該ユーザが商品自体の興味を失っており、意図的に通知を開封していない可能性があるので、在庫切れ通知の通知態様を変更しないようにしてもよい。

（３）また例えば、在庫切れ通知と同様に、入荷通知についても、電子メール以外の方法を使ったり、雛型を変更したりすることによって、ユーザが入荷通知に気付きやすくするようにしてもよい。

（３−１）例えば、ユーザが在庫切れ通知メール７０を開封したか否かに応じて、入荷通知の態様を変更するようにしてもよい。

本変形例の販売管理サーバ１０は、在庫切れ通知判定部９４を含む。在庫切れ通知判定部９４の判定方法は、変形例（２−１）と同様であるので、説明を省略する。

本変形例の入荷通知部８６は、在庫切れ通知判定部９４の判定結果に基づいて、以降の入荷通知の通知態様を変更する。入荷通知の通知態様の変更方法自体は、変形例（２−１）で説明した在庫切れ通知の通知態様の変更方法と同様である。変形例（２−１）における「在庫切れ通知」を「入荷通知」と読み替えるようにすればよい。

即ち、入荷通知が、複数種類の通知媒体のうちの少なくとも一つを用いて行われる場合、入荷通知部８６は、複数種類の通知媒体のうちで使用する通知媒体の種類を変更することによって、入荷通知の通知態様を変更する。また例えば、入荷通知が、複数種類の雛型のうちの少なくとも一つを用いて行われる場合、入荷通知部８６は、複数種類の通知媒体のうちで使用する雛型の種類を変更することによって、入荷通知の通知態様を変更する。

例えば、入荷通知部８６は、過去の在庫切れ通知がユーザに提示されていないと判定された場合、入荷通知の通知態様を変更する。この場合、ユーザが商品の在庫切れに気付いておらず、商品ページ４０へのアクセス時に落胆してしまう可能性があるので、今後は入荷通知に気付きやすくして、早めに商品ページ４０へアクセスさせることができる。即ち、在庫切れ通知部９０は、過去の在庫切れ通知がユーザに提示されたと判定された場合、入荷通知の通知態様を変更しないことになる。

一方、入荷通知部８６は、過去の在庫切れ通知がユーザに提示されたと判定された場合、入荷通知の通知態様を変更するようにしてもよい。この場合、ユーザが入荷通知メール６０を見て落胆している可能性があるので、今後は早めに入荷通知に気付かせることができる。即ち、在庫切れ通知部９０は、過去の在庫切れ通知がユーザに提示されていないと判定された場合、入荷通知の通知態様を変更しないことになる。

変形例（３−１）によれば、例えば、ユーザが在庫切れ通知メール７０を開封したか否かに応じて、入荷通知の通知態様を変更することができる。

なお、入荷通知部８６は、入荷通知の通知媒体及び雛型の少なくとも一方を変更すればよく、通知媒体及び雛型の片方のみを変更してもよいし、両方を変更するようにしてもよい点も、変形例（２−１）と同様である。

（３−２）また例えば、入荷通知メール６０を開封したか否かに応じて、入荷通知の態様を変更するようにしてもよい。

本変形例の販売管理サーバ１０は、入荷通知判定部９６を含む。入荷通知判定部９６の判定方法は、変形例（２−２）と同様であるので、説明を省略する。

入荷通知部８６は、入荷通知判定部９６の判定結果に基づいて、以降の入荷通知の通知態様を変更する。

例えば、入荷通知部８６は、過去の入荷通知がユーザに提示されていないと判定された場合、入荷通知の通知態様を変更する。この場合、ユーザが入荷通知メール６０に気付いておらず、在庫切れ通知を気付きやすくすることができる。即ち、入荷通知部８６は、過去の入荷通知がユーザに提示されたと判定された場合、入荷通知の通知態様を変更しないことになる。

一方、入荷通知部８６は、過去の入荷通知がユーザに提示されていないと判定された場合、入荷通知の通知態様を変更しないようにしてもよい。この場合、ユーザが商品に興味を無くし、入荷通知メール６０を意図的に開封しなかった可能性があるので、入荷通知を変更しないようにしてもよい。

変形例（３−２）によれば、例えば、入荷通知メール６０を開封したか否かに応じて、入荷通知の通知態様を変更することができる。

（３−３）また例えば、ユーザが商品ページ４０にアクセスしたか否かに応じて、以降の入荷通知の通知態様を変更するようにしてもよい。

本変形例の販売管理サーバ１０は、アクセス判定部９８を含む。アクセス判定部９８の判定方法は、変形例（２−３）と同様であるので、説明を省略する。

入荷通知部８６は、アクセス判定部９８の判定結果に基づいて、以降の入荷通知の通知態様を変更する。

例えば、入荷通知部８６は、アクセス判定部９８により商品ページ４０にユーザがアクセスしたと判定された場合、入荷通知の通知態様を変更する。この場合、在庫のない商品ページ４０にアクセスして落胆した可能性があるため、以降の入荷通知を気付きやすくして、早めに商品ページ４０にアクセスさせることができる。即ち、入荷通知部８６は、アクセス判定部９８により商品ページ４０にユーザがアクセスしていないと判定された場合、入荷通知の通知態様を変更しないことになる。

一方、例えば、入荷通知部８６は、アクセス判定部９８により商品ページ４０にユーザがアクセスしていないと判定された場合、入荷通知の通知態様を変更するようにしてもよい。この場合、入荷通知に気付かずに商品ページ４０にアクセスしていない可能性があるので、以降の入荷通知の通知態様を変更して気付きやすくすることができる。即ち、入荷通知部８６は、アクセス判定部９８により商品ページ４０にユーザがアクセスしたと判定された場合、入荷通知の通知態様を変更しないようにしてもよい。

変形例（３−３）によれば、例えば、在庫切れ通知メール７０の送信後に、ユーザが商品ページ４０にアクセスしたか否かに応じて、以降の入荷通知の通知態様を変更することができる。

なお、上記変形例（３−１）〜（３−３）を組み合わせるようにしてもよい。即ち、在庫切れ通知部９０は、在庫切れ通知判定部９４の判定結果と、入荷通知判定部９６の判定結果と、アクセス判定部９８の判定結果と、の何れか二つ又は全てに基づいて、入荷通知の通知態様を変更するようにしてもよい。例えば、ユーザが入荷通知メール６０も在庫切れ通知メール７０も開封せず、商品ページ４０にもアクセスしていない場合には、当該ユーザが商品自体の興味を失っており、意図的に通知を開封していない可能性があるので、在庫切れ通知の通知態様を変更しないようにしてもよい。

更に、変形例（２−１）〜（２−３）と、変形例（３−１）〜（３−３）と、を組み合わせるようにしてもよい。即ち、在庫切れ通知判定部９４の判定結果と、入荷通知判定部９６の判定結果と、アクセス判定部９８の判定結果と、の少なくとも一つに基づいて、入荷通知と在庫切れ通知との両方の通知態様が変更されるようにしてもよい。

（４）また例えば、ユーザによる電子メールの開封時点を解析し、ユーザが開封しやすい時間帯に入荷通知メール６０や在庫切れ通知メール７０を送信するようにしてもよい。

図１８は、変形例（４）における処理の概要を示す図である。ここでは、例えば、ユーザによる過去の電子メールの開封状況から、ユーザが開封しやすい時間帯が推測される。図１８に示す例では、ユーザが電子メールを午前７時に開封する傾向にある場合を示している。例えば、在庫のない商品が入荷された場合、この時間帯の所定時間前になるまで入荷通知メール６０の送信を待機したり、在庫が再び無くなった場合、この時間帯の所定時間前になるまで在庫切れ通知メール７０の送信を待機したりするようにしてもよい。

本変形例の販売管理サーバ１０は、時点情報取得部１００を含む。時点情報取得部１００は、ユーザによる電子メールの開封時点に関する時点情報を取得する。電子メールが開封されたか否かを判定する方法は、在庫切れ通知判定部９４や入荷通知判定部９６で説明した方法と同様である。

時点情報取得部１００は、販売管理サーバ１０がユーザに対して過去に送信した電子メール（例えば、入荷通知メール６０、在庫切れ通知メール７０、及び、ダイレクトメール等の他の電子メール）の開封日時を取得する。例えば、時点情報取得部１００は、電子メールが開封されたと判定された場合の現在の日時をデータ記憶部８０に記録し、当該記録内容に基づいて、ユーザが電子メールを開封する時間帯を推測することになる。この場合、時点情報取得部１００は、過去の電子メールの開封日時を所与の数式に代入することによって、ユーザが電子メールを開封する時間帯を推測する。

（４−１）例えば、在庫切れ通知が、ユーザに対して送信される電子メールである場合、在庫切れ通知部９０は、時点情報に基づいて、在庫切れ通知の送信時点を決定する。在庫切れ通知部９０は、上記推測された開封日時に基づいて定まる期間内に、在庫切れ通知メール７０を送信する。例えば、在庫切れ通知部９０は、上記推測された開封日時、当該日時の所定時間前又は後に、在庫切れ通知メール７０を送信する。即ち、在庫切れ通知部９０は、在庫切れ通知メール７０の送信を待機することになる。

変形例（４−１）によれば、ユーザが電子メールを開封しやすい時間帯に在庫切れ通知メール７０を送信するので、ユーザに在庫切れ通知メール７０を気付きやすくすることができる。

（４−２）また例えば、入荷通知が、ユーザに対して送信される電子メールである場合、入荷通知部８６は、時点情報に基づいて、入荷通知の送信時点を決定する。入荷通知部８６は、上記推測された開封日時に基づいて定まる期間内に、入荷通知メール６０を送信する。例えば、入荷通知部８６は、上記推測された開封日時、当該日時の所定時間前又は後に、入荷通知メール６０を送信する。即ち、入荷通知部８６は、入荷通知メール６０の送信を待機することになる。

変形例（４−２）によれば、ユーザが電子メールを開封しやすい時間帯に入荷通知メール６０を送信するので、ユーザに入荷通知メール６０を気付きやすくすることができる。

（５）また例えば、ユーザが入荷通知メール６０を開封することを、在庫切れ通知メール７０を送信することの条件とするようにしてもよい。

本変形例の販売管理サーバ１０は、入荷通知判定部９６を含む。入荷通知判定部９６の判定方法は、変形例（２−２）と同様であるので、説明を省略する。

在庫切れ通知部９０は、入荷通知判定部９６の判定結果と、在庫切れ通知部９０の判定結果と、に基づいて、在庫切れ通知を行う。

在庫切れ通知部９０は、入荷通知判定部９６により入荷通知が提示されたと判定された場合、在庫切れ通知を行う。この場合、ユーザが入荷通知を見ており、在庫があると思い込んでいるので、早急に在庫切れ通知メール７０を送ることができる。即ち、在庫切れ通知部９０は、入荷通知判定部９６により入荷通知が提示されないと判定された場合、在庫切れ通知を行わないことになる。

一方、在庫切れ通知部９０は、入荷通知判定部９６により入荷通知が提示されないと判定された場合、在庫切れ通知を行うようにしてもよい。この場合、ユーザが入荷通知を見る前に在庫切れ通知メール７０を送ることにより、現在の在庫状況を通知することができる。即ち、在庫切れ通知部９０は、入荷通知判定部９６により入荷通知が提示されないと判定された場合、在庫切れ通知を行わないようにしてもよい。

変形例（５）によれば、ユーザが入荷通知メール６０を開封することを、在庫切れ通知メール７０を送信することの条件とすることができる。

（６）また例えば、商品の在庫が一つでも残っていれば在庫があると判定されたが、商品をまとめて購入するユーザにとっては、自分が欲する数以上の在庫がなければ、商品を購入しないことがある。例えば、２０個の商品をまとめ買いしたいユーザにとっては、在庫が０個の状態から１０個の状態に変化しても商品を購入せず、在庫が２０個以上にならなければ商品を購入しないことがある。このため、例えば、在庫が２０個未満の状態になった時点で、ユーザに対して在庫切れ通知メール７０を送信するようにしてもよい。

変形例（６）の通信販売システム１は、基準数取得部１０２を含む。基準数取得部１０２は、ユーザにより指定される商品の数（即ち、基準数）を取得する。例えば、入荷通知要求ボタン５２を選択する場合に、ユーザは商品の数を入力する。基準数取得部１０２は、ユーザ端末２０の操作部２４からユーザが入力した数値を取得することによって、ユーザが指定した基準数を取得する。ここで指定される数値は、ユーザが商品の購入を希望する数であり、入荷通知又は在庫切れ通知を行うための条件となる数ともいえる。

本変形例の在庫切れ通知部９０は、商品の現在の在庫数と入荷通知要求を受け付けたユーザにより指定された数とに基づいて商品の在庫が再びなくなったと判定された場合、入荷通知要求を受け付けたユーザに対する在庫切れ通知を行う。例えば、在庫切れ通知部９０は、商品の現在の在庫数とユーザにより指定された数とに基づいて、商品の在庫があるか否かを判定する。在庫切れ通知部９０は、商品の在庫がユーザにより指定された数以上あるか否かを判定し、入荷通知要求をしたユーザが指定した数以上の在庫数であるか否かを判定することによって、商品の在庫があるか否かを判定することになる。

なお、ここでは、在庫切れ通知部９０が、商品の在庫があるか否かを判定する処理を実行する場合を説明したが、当該判定処理が他の機能又は他のシステムにおいて実行され、当該判定処理の判定結果を在庫切れ通知部９０が取得するようにしてもよい点は、実施形態と同様である。

変形例（６）によれば、在庫切れ通知をするために在庫が満たすべき条件ユーザの好みに応じて変化させることができる。

（７）また例えば、ある商品の入荷通知メール６０を受信したユーザが、当該商品と同一又は類似する他の商品を購入していた場合には、在庫切れ通知メール７０を送信しないように制限してもよい。当該他の商品は、入荷通知要求に対応する店舗と同じ店舗で扱うものであってもよいし、他の店舗で扱うものであってもよい。類似する商品とは、属性（性質）が同じ商品であり、例えば、同じ商品カテゴリの商品である。

また例えば、ユーザが商品を購入した場合及び店舗のスタッフが入荷の操作をした場合に在庫データが更新される場合を説明したが、在庫データの更新方法自体は、公知の種々の手法を適用可能である。例えば、ユーザが実際に商品を購入する前に購入予定のある商品をリスト（いわゆる、買い物かご）に追加する場合には、当該リストに商品が追加された時点で在庫データが更新されるようにしてもよい。

また例えば、ユーザが、自分の入荷通知要求を解除できるようにしてもよい。例えば、ある商品の入荷通知要求をした場合、当該商品の商品ページ４０の入荷通知要求ボタン５２が選択済みの状態になっており、当該ボタンをもう一度選択すると、入荷通知要求が解除されるようにしてもよい。入荷通知要求が解除された場合には、ユーザに対して在庫切れ通知が行われないことになる。

また例えば、実施形態においては、各機能ブロックが１台のサーバコンピュータにより実現される場合を説明したが、通信販売システム１を構成する複数のコンピュータにより各機能が分担されるようにしてもよい。通信販売システム１に複数のサーバが含まれる場合には、例えば、入荷通知要求を受け付けるサーバ（即ち、入荷通知要求受付部８４を実現するサーバ）と、実際に入荷通知メール６０や在庫切れ通知メール７０を送信するサーバ（即ち、入荷通知部８６や在庫切れ通知部９０を実現するサーバ）と、が異なっていてもよい。

更に、機能ブロックのうちの一部の機能が、ユーザ端末２０において実現されるようにしてもよい。例えば、Ｊａｖａスクリプト（登録商標）によって入荷通知や在庫切れ通知の画面を表示させる場合には、当該スクリプトの実行主体はユーザ端末２０であるので、ユーザ端末２０が当該画面を表示させる処理を実行することにより、入荷通知部８６や在庫切れ通知部９０の機能がユーザ端末２０において実現されるようにしてもよい。

また例えば、上記においては、本発明に関る在庫切れ通知システムを通信販売システムに適用する例を説明したが、本発明に関る通知制御システムは、在庫切れを通知する種々のシステムに適用可能である。例えば、通信販売ではなく、ユーザが商品ページから商品を注文して現実世界の店舗で商品を受け取るシステムについても、本発明に係る在庫切れ通知制御システムを適用可能である。

１ 通信販売システム、２ 通信ネットワーク、１０ 販売管理サーバ、１１，２１ 制御部、１２，２２ 記憶部、１３ 光ディスクドライブ部、１４，２３ 通信部、１５ データベース、２０ ユーザ端末、２４ 操作部、２５ 表示部、３０ 店舗端末、４０ 商品ページ、４２ 基本情報、４４ 在庫数、４６ 入力フォーム、４８ 購入ボタン、５０ メッセージ、５２ 入荷通知要求ボタン、６０ 入荷通知メール、６２ 件名、６４ メッセージ、６６ リンク、７０ 在庫切れ通知メール、７２ 件名、７４ メッセージ、７６ リンク、８０ データ記憶部、８２ 在庫データ取得部、８４ 入荷通知要求受付部、８６ 入荷通知部、８８ アクセス履歴取得部、９０ 在庫切れ通知部、９２ フラグ設定部、９４ 在庫切れ通知判定部、９６ 入荷通知判定部、９８ アクセス判定部、１００ 時点情報取得部、１０２ 基準数取得部、１１０ ブックマーク画面、１１２ メッセージ。

Claims (20)

1. 商品の在庫に関するデータを記憶する手段の記憶内容を取得する手段と、
   ユーザによる前記商品の入荷通知要求を受け付ける入荷通知要求受付手段と、
   前記商品が入荷した場合に、前記入荷通知要求を受け付けたユーザに対する入荷通知を行う入荷通知手段と、
   前記入荷通知が行われた後に前記商品の在庫がなくなった場合、前記入荷通知要求を受け付けたユーザに対する在庫切れ通知を行う在庫切れ通知手段と、
   を含むことを特徴とする在庫切れ通知システム。
2. 前記在庫切れ通知システムは、
   前記入荷通知要求を受け付けたユーザによる、前記商品の商品ページへのアクセス履歴を取得する手段を更に含み、
   前記在庫切れ通知手段は、
   前記入荷通知が行われた時点から、前記商品の在庫がなくなった時点までの間に、前記ユーザが前記商品ページにアクセスした履歴が前記アクセス履歴に存在しない場合、前記入荷通知要求を受け付けたユーザに対する在庫切れ通知を行う、
   ことを特徴とする請求項１に記載の在庫切れ通知システム。
3. 前記入荷通知手段は、
   前記入荷通知要求を受け付けたユーザに対する入荷通知をすべきか否かを識別する識別情報に基づいて、当該ユーザに対する入荷通知を行うか否かを決定し、
   前記在庫切れ通知システムは、
   前記入荷通知が行われてから前記商品の在庫がなくなるまでの間に、前記入荷通知要求を受け付けたユーザが前記商品の商品ページにアクセスした場合、以降の入荷通知を行わないように前記識別情報を設定する手段を更に含み、
   前記在庫切れ通知手段は、
   前記入荷通知が行われた後において、前記識別情報が入荷通知を行うことを示している状態で、前記商品の在庫がなくなった場合、前記入荷通知要求を受け付けたユーザに対する在庫切れ通知を行う、
   ことを特徴とする請求項１に記載の在庫切れ通知システム。
4. 前記在庫切れ通知システムは、
   前記在庫切れ通知が前記入荷通知要求を受け付けたユーザに提示されたか否かを判定する在庫切れ通知判定手段を更に含み、
   前記在庫切れ通知手段は、
   前記在庫切れ通知判定手段の判定結果に基づいて、以降の前記在庫切れ通知の通知態様を変更する、
   ことを特徴とする請求項１〜３の何れか一項に記載の在庫切れ通知システム。
5. 前記在庫切れ通知システムは、
   前記入荷通知が前記入荷通知要求を受け付けたユーザに提示されたか否かを判定する入荷通知判定手段を更に含み、
   前記在庫切れ通知手段は、
   前記入荷通知判定手段の判定結果に基づいて、以降の前記在庫切れ通知の通知態様を変更する、
   ことを特徴とする請求項１〜４の何れか一項に記載の在庫切れ通知システム。
6. 前記在庫切れ通知システムは、
   前記在庫切れ通知が行われた後に、前記商品ページに前記入荷通知要求を受け付けたユーザがアクセスしたか否かを判定するアクセス判定手段を更に含み、
   前記在庫切れ通知手段は、
   前記アクセス判定手段の判定結果に基づいて、以降の前記在庫切れ通知の通知態様を変更する、
   ことを特徴とする請求項２又は３に記載の在庫切れ通知システム。
7. 前記在庫切れ通知は、複数種類の通知媒体のうちの少なくとも一つを用いて行われ、
   前記在庫切れ通知手段は、
   前記複数種類の通知媒体のうちで使用する通知媒体の種類を変更することによって、前記在庫切れ通知の通知態様を変更する、
   ことを特徴とする請求項４〜６の何れか一項に記載の在庫切れ通知システム。
8. 前記在庫切れ通知は、複数種類の雛型のうちの少なくとも一つを用いて行われ、
   前記在庫切れ通知手段は、
   前記複数種類の通知媒体のうちで使用する雛型の種類を変更することによって、前記在庫切れ通知の通知態様を変更する、
   ことを特徴とする請求項４〜７の何れか一項に記載の在庫切れ通知システム。
9. 前記在庫切れ通知システムは、
   前記在庫切れ通知が前記入荷通知要求を受け付けたユーザに提示されたか否かを判定する在庫切れ通知判定手段を更に含み、
   前記入荷通知手段は、
   前記在庫切れ通知判定手段の判定結果に基づいて、以降の前記入荷通知の通知態様を変更する、
   ことを特徴とする請求項１〜８の何れか一項に記載の在庫切れ通知システム。
10. 前記在庫切れ通知システムは、
    前記入荷通知が前記入荷通知要求を受け付けたユーザに提示されたか否かを判定する入荷通知判定手段を更に含み、
    前記入荷通知手段は、
    前記入荷通知判定手段の判定結果に基づいて、以降の前記入荷通知の通知態様を変更する、
    ことを特徴とする請求項１〜９の何れか一項に記載の在庫切れ通知システム。
11. 前記在庫切れ通知システムは、
    前記在庫切れ通知が行われた後に、前記商品ページに前記入荷通知要求を受け付けたユーザがアクセスしたか否かを判定するアクセス判定手段を更に含み、
    前記入荷通知手段は、
    前記アクセス判定手段の判定結果に基づいて、以降の前記入荷通知の通知態様を変更する、
    ことを特徴とする請求項２又は３に記載の在庫切れ通知システム。
12. 前記入荷通知は、複数種類の通知媒体のうちの少なくとも一つを用いて行われ、
    前記入荷通知手段は、
    前記複数種類の通知媒体のうちで使用する通知媒体の種類を変更することによって、前記入荷通知の通知態様を変更する、
    ことを特徴とする請求項９〜１１の何れか一項に記載の在庫切れ通知システム。
13. 前記入荷通知は、複数種類の雛型のうちの少なくとも一つを用いて行われ、
    前記入荷通知手段は、
    前記複数種類の通知媒体のうちで使用する雛型の種類を変更することによって、前記入荷通知の通知態様を変更する、
    ことを特徴とする請求項９〜１２の何れか一項に記載の在庫切れ通知システム。
14. 前記在庫切れ通知は、前記入荷通知要求を受け付けたユーザに対して送信される電子メールであり、
    前記在庫切れ通知システムは、
    前記入荷通知要求を受け付けたユーザによる電子メールの開封時点に関する時点情報を取得する手段を更に含み、
    前記在庫切れ通知手段は、
    前記時点情報に基づいて、前記在庫切れ通知の送信時点を決定する、
    ことを特徴とする請求項１〜１３の何れか一項に記載の在庫切れ通知システム。
15. 前記入荷通知は、前記入荷通知要求を受け付けたユーザに対して送信される電子メールであり、
    前記在庫切れ通知システムは、
    前記入荷通知要求を受け付けたユーザによる電子メールの開封時点に関する時点情報を取得する手段を更に含み、
    前記入荷通知手段は、
    前記時点情報に基づいて、前記入荷通知の送信時点を決定する、
    ことを特徴とする請求項１〜１４の何れか一項に記載の在庫切れ通知システム。
16. 前記在庫切れ通知システムは、
    前記入荷通知が前記入荷通知要求を受け付けたユーザに提示されたか否かを判定する入荷通知判定手段を更に含み、
    前記在庫切れ通知手段は、
    前記入荷通知判定手段の判定結果に基づいて、前記在庫切れ通知を行う、
    ことを特徴とする請求項１〜１５の何れか一項に記載の在庫切れ通知システム。
17. 前記通知制御システムは、
    前記入荷通知要求を受け付けたユーザにより指定される前記商品の数を取得する手段を更に含み、
    前記在庫切れ通知手段は、
    前記商品の現在の在庫数と前記入荷通知要求を受け付けたユーザにより指定された数とに基づいて前記商品の在庫が再びなくなったと判定された場合、前記入荷通知要求を受け付けたユーザに対する在庫切れ通知を行う、
    ことを特徴とする請求項１〜１６の何れか一項に記載の通知制御システム。
18. 商品の在庫に関するデータを記憶する手段の記憶内容を取得する手段と、
    ユーザによる前記商品の入荷通知要求を受け付ける入荷通知要求受付手段と、
    前記商品が入荷した場合に、前記入荷通知要求を受け付けたユーザに対する入荷通知を行う入荷通知手段と、
    前記入荷通知が行われた後に前記商品の在庫がなくなった場合、前記入荷通知要求を受け付けたユーザに対する在庫切れ通知を行う在庫切れ通知手段と、
    を含むことを特徴とする在庫切れ通知装置。
19. 在庫切れ通知装置が、
    商品の在庫に関するデータを記憶する手段の記憶内容を取得するステップと、
    ユーザによる前記商品の入荷通知要求を受け付ける入荷通知要求受付ステップと、
    前記商品が入荷した場合に、前記入荷通知要求を受け付けたユーザに対する入荷通知を行う入荷通知ステップと、
    前記入荷通知が行われた後に前記商品の在庫がなくなった場合、前記入荷通知要求を受け付けたユーザに対する在庫切れ通知を行う在庫切れ通知ステップと、
    を実行することを特徴とする在庫切れ通知方法。
20. 商品の在庫に関するデータを記憶する手段の記憶内容を取得する手段、
    ユーザによる前記商品の入荷通知要求を受け付ける入荷通知要求受付手段、
    前記商品が入荷した場合に、前記入荷通知要求を受け付けたユーザに対する入荷通知を行う入荷通知手段、
    前記入荷通知が行われた後に前記商品の在庫がなくなった場合、前記入荷通知要求を受け付けたユーザに対する在庫切れ通知を行う在庫切れ通知手段、
    としてコンピュータを機能させるためのプログラム。

Images