ネットワークを介して複数の商品情報を受信する受信部と、前記受信部で受信された複数の商品情報を表示する表示部と、ユーザが前記表示部で表示された複数の商品情報から1つの商品を選択し、購入の指示を入力するための入力部と、購入した商品のカテゴリーと購入した日を管理する購入履歴情報と、次回購入見込み日の何日前からユーザに通知を開始するかを示す通知開始幅と何日間通知を継続するかを示す通知期間とを商品カテゴリごとに定めた買い時商品通知パラメータと、通知開始日と通知終了日とを商品カテゴリごとに管理する買い時商品情報と、を蓄積する蓄積部と、各商品カテゴリごとに、前記購入履歴情報の購入間隔に基づいて次回購入見込み日を算出し、前記買い時商品通知パラメータの通知開始幅と通知期間とに基づいて通知開始日と通知終了日とを決定して前記買い時商品情報に保存させる制御部とを備え、各商品カテゴリごとに、現在の日付が前記通知開始日から前記通知終了日の間である場合に、前記表示部において該当する商品カテゴリの購入を推薦する表示がされることを特徴とする商品購入の推薦装置。前記買い時商品通知パラメータは、さらに前記通知期間後も通知を継続する期間を示す予備通知期間を定め、前記買い時商品情報は、さらに通知終了日より後の予備通知終了日を管理し、前記制御部は、さらに前記買い時商品通知パラメータの予備通知期間に基づいて通知終了日より後の予備通知終了日を決定して前記買い時商品情報に保存させ、前記制御部は、各商品カテゴリごとに、現在の日付が前記通知終了日から前記予備通知終了日の間であって、かつ、前回の購入日が前記通知開始日以前である場合に、前記表示部において該当する商品カテゴリの購入を推薦する表示がされることを特徴とする請求項1に記載の商品購入の推薦装置。各商品カテゴリごとに、現在の日付が前記通知終了日から前記予備通知終了日の間であって、かつ、前回の購入日が前記通知開始日より後である場合には、前記表示部において該当する商品カテゴリの購入を推薦する表示がされないことを特徴とする請求項1に記載の商品購入の推薦装置。前記買い時商品情報は、さらに通知終了日より後の予備通知終了日を管理し、前記制御部は、前記購入履歴情報の購入間隔の最大値を算出し、当該最大値に基づいて、通知終了日より後の予備通知終了日を決定して前記買い時商品情報に保存させることを特徴とする請求項1に記載の商品購入の推薦装置。前記買い時商品通知パラメータは、さらに通知を行うか否かを示す通知フラグを定め、前記買い時商品通知パラメータの通知フラグが通知を行うことを示す商品カテゴリについて、現在の日付が前記通知開始日から前記通知終了日の間である場合に、前記表示部において該当する商品カテゴリの購入を推薦する表示がされることを特徴とする請求項1に記載の商品購入の推薦装置。しかしながら、特許文献1の手法は、どのような商品であっても一定の事前の日数で通知を行うようになっており、商品の特性に合わせた日数で事前に通知することができていなかった。そこで、上記課題を鑑み、商品ごとに最適なタイミングで事前に購入を促すことを目的とする。上記目的を達成するために、例えば、特許請求の範囲に記載の構成を採用する。本発明によれば、ユーザの購入行動にもとづいて商品ごとに最適な買い時を通知し、定期的に購入する商品の買い忘れを防止することができる。以下、図面を用いて実施例を説明する。本実施例では、商品カテゴリごとに事前に通知する幅や通知する期間を変えてユーザに購入を促す例を示す。図1は、本実施例にかかる推薦装置の構成の一例を示した図である。推薦装置101は、推薦装置101内の各処理部を制御する制御部102と、制御部で処理を行うために一時的にデータを保持しておくメモリ103と、マウス操作やタッチパネル操作などユーザからの指示を受け付けるユーザ操作入力部104と、ネットワーク経由でデータの送受信を行うネットワーク送受信部105と、ユーザに画面を提示する表示部106と、データを蓄積しておく蓄積部107と、を備える。ユーザがネット通信販売を利用する際、ネットワーク送受信部105により取得した商品情報を表示部106に提示し、マウスやタッチパネルを通じた商品選択操作をユーザ操作入力部104のより受け付ける。本発明の処理を行うにあたって、蓄積部107には、ユーザが購入した商品を管理する購入履歴情報108と、後述する買い時商品通知パラメータ109および、買い時商品情報110を保存している。図2は、本実施例にかかる推薦装置101と、ネット通信販売に関わる機器との接続構成の一例を示した図である。受注サーバ201はネット通信販売を行う事業者が管理するサーバであって、たとえばインターネットなど、ネットワークにより推薦装置101と接続されている。推薦装置101は、ユーザがネット通信販売を利用するインタフェースとなる装置である。ユーザは推薦装置101を操作して商品を閲覧、選択する。推薦装置101はネットワークにより受注サーバ201と接続されており、商品情報をダウンロードしたり、注文情報をアップロードしたりする。受注サーバ201は商品を管理しており、推薦装置101の要求に応じて商品情報を送信する。また、受注サーバ201は推薦装置101から注文情報を受信して、管理する。図3は、本実施例にかかる受注サーバ201の内部構成の一例を示した図である。受注サーバ201は、受注サーバ201内の各処理部を制御する制御部301と、制御部で処理を行うために一時的にデータを保持しておくメモリ302と、マウス操作やタッチパネル操作など管理者からの指示を受け付ける管理者操作入力部303と、ネットワーク経由でデータの送受信を行うネットワーク送受信部304と、管理者に画面を提示する表示部305と、データを蓄積しておく蓄積部306と、を備える。蓄積部306には、ネット通信販売で扱う商品を管理する商品情報307と、ユーザの氏名や住所などを管理するユーザ情報308と、ユーザからの注文を管理する注文情報309を保存している。商品情報307は、推薦装置101からの要求に応じてネットワーク送受信部304を介して送信する。注文情報309は、推薦装置101からネットワーク送受信部304を介して受信し、蓄積部306に保存する。また、受注サーバ201の管理者が管理操作を行う際には、マウスやタッチパネルを通じた管理操作を管理者操作入力部303より受け付け、処理結果を表示部305に提示する。管理者は表示部305により蓄積部306に保存されている商品情報307および、ユーザ情報308、注文情報309の内容を閲覧することができる。図4は、本実施例にかかる推薦装置101で買い物を行う手順を示した図である。推薦装置101の電源を投入し、買い物を開始する段階から説明する。ステップ401は、受注サーバ201から最新の商品情報を取得するステップである。推薦装置101から受注サーバ201に対して要求を出し、受注サーバ201から送信されてきた商品情報を受信する。ステップ402は、推薦装置101の表示部106に商品情報を提示するステップである。ステップ401で取得した商品情報を表示部106に表示できる形式に変換して、ユーザに提示する。ユーザは提示された画面を操作して商品を閲覧し、商品を選択する。ユーザに提示する画面の一例を図5に示す。画面501は、推薦装置101が表示部106に提示する画面の領域である。商品情報は、商品画像503と、商品詳細504の組み合わせで表示する。商品詳細504には、商品名、産地、内容量、価格等のテキスト情報を含む。ユーザは数量指定領域505に購入する商品の数量を入力し、購入決定ボタン506を選択することで商品を購入候補として登録する。また、スクロールボタン502を選択することで画面を隣のページに切り替えて別の商品を閲覧したり、支払い画面遷移ボタン507を選択することで購入候補の商品を確定し決済をする画面に移行することができる。ステップ403は商品選択が完了したことを示すユーザ入力があったか否かを判定するステップである。例えば、支払い画面遷移ボタン507をユーザが押したことを検知する。商品選択が完了したことを示すユーザ入力があった場合はステップ406に、ない場合はステップ404に進む。ステップ404は、ユーザによる商品選択の入力を受け付けるステップである。入力を受け付けたのち、ステップ405に進む。ステップ405は、ステップ404で選択した商品について購入数量の指示を受け付けるステップである。指示を受け付けたのち、ステップ403に戻って、商品選択が完了したことを示すユーザ入力があるか否かを再度判定する。ステップ406は、支払いのための情報をユーザから受け付けるステップである。代引きやクレジットカード払いなど支払い方法の指定、配達希望日時の指定などを受け付ける。指定を受け付けたのち、ステップ407に進む。ステップ407は、ユーザ入力により購入候補の商品を確定するステップである。購入候補商品の一覧および、支払い方法や配達希望日時などを表示してユーザに確認を促したのち、ユーザ入力により注文を確定させる。確定した注文情報は、推薦装置101から受注サーバ201に送信して、事業者に受け付けられる。ステップ408は、確定した注文情報をもとに購入履歴を生成して蓄積部107に保存するステップである。購入履歴を蓄積しておき、ユーザ購買行動の分析などに用いる。購入履歴を管理するテーブルの一例を図6に示す。購入履歴テーブル601は、日付、商品コード、商品名、商品カテゴリコード、商品カテゴリ名、購入数量、消費期限等のフィールドを備える。商品は、推薦装置101が処理を行う際に商品を識別するための商品コードと、ユーザに提示するための商品名により、購入した日付ごとに管理されている。また、類似の商品をまとめて扱うために、商品が属するカテゴリを表す商品カテゴリコードと、商品カテゴリ名が付与されている。購入した商品に付属する情報として、購入数量および、消費期限を関連付けて保存しておく。以下、買い時商品提示の考え方を説明する。図7は、例えばトイレットペーパーの商品カテゴリに属する商品の購入間隔をもとに次回購入日を予測する方法を示した図である。この例では、トイレットペーパーの商品カテゴリに属する商品を15、130、218の3回購入している。過去3回の購入間隔は25日と19日であり、その平均は22日である。次回もこの平均的な間隔に基づいて購入すると仮定すると、購入日は312であると推測できる。本実施例の推薦装置101が、トイレットペーパーについては次回購入日の5日前からユーザに対して通知するとすれば、通知開始日は37となる。また、トイレットペーパーの通知期間を10日間とすれば、通知終了日は317となる。本実施例にかかる推薦装置101は、次回購入日の何日前からユーザへの通知を開始するか、何日間ユーザに通知を継続するかを商品カテゴリごとに最適化する。たとえば、牛乳などの生鮮食品の場合は次回購入日の直前に通知を開始し、短い期間で通知を終了する。また、トイレットペーパーなど消費期限がない商品の場合は、次回購入日に対して十分余裕をもって早めに通知を開始し、長い期間通知を継続する。図8は、次回購入日の何日前からユーザへの通知を開始するか、何日間ユーザに通知を継続するかを商品カテゴリごとに定義した買い時通知パラメータテーブルである。次回購入日の何日前からユーザへの通知を開始するかを示す情報は、通知開始幅フィールドで管理される。何日間ユーザに通知を継続するかを示す情報は、通知期間フィールドで管理される。たとえば、牛乳について次回購入日の2日前から通知を開始し、4日間通知を継続する場合は、通知開始幅を2、通知期間を4に設定しておく。本実施例にかかる推薦装置101は、あらかじめ通知開始幅と通知期間を定義した買い時通知パラメータを蓄積部107に保持しておき、通知開始日や通知終了日を決定する際にこのテーブルを参照する。図9に、たとえばトイレットペーパーの次回購入日を推測する処理のフローチャートを示す。ステップ901は、トイレットペーパーに関する購入履歴を取得する処理である。取得する購入履歴には、過去にトイレットペーパーを購入した日付が格納されている。ステップ902は、ステップ901で取得した購入履歴の分析が完了したか否かを判定する処理である。完了した場合はステップ905に進む。完了していない場合はステップ903に進んで分析を継続する。ステップ903は、トイレットペーパーをN回目に購入した日付と回目に購入した日付の間隔を算出する処理である。図9に示す処理を開始する際に、Nはあらかじめ1に設定されているものとする。例えば、1回目は15に購入し、2回目に130に購入した場合、その購入間隔は25日となる。ステップ904は、購入履歴の分析対象を一つ進める処理である。例えば、1回目と2回目の購入間隔を算出した場合、次は2回目と3回目の購入間隔を算出する。ステップ905は、ステップ902からステップ904で算出した各購入間隔について平均を算出する処理である。例えば、1回目と2回目の購入間隔が25日、2回目と3回目の購入間隔が19日の場合、平均の購入間隔は22日となる。ステップ906は、トイレットペーパーの最終購入日にステップ905で算出した平均値を加算して、次回購入日を推測する処理である。例えば、最終購入日が218で、平均の購入間隔が22日だった場合、次回購入日は312となる。ユーザが購入したすべての商品カテゴリについて分析を行う場合は、図9に示す処理をそれぞれの商品カテゴリに対して実施すればよい。図10に、たとえばトイレットペーパーの次回購入日に対して通知開始日と通知終了日を決定する処理のフローチャートを示す。ステップ1001は、トイレットペーパーに関する買い時通知パラメータを取得する処理である。前述の通り、取得する買い時通知パラメータには、次回購入日に対して何日前からユーザに通知するかを示す通知開始幅と、何日間ユーザへの通知を継続するかの幅を示す通知期間が格納されている。ステップ1002は、図9に示す処理により推測した次回購入日から通知開始幅を減算して、通知開始日を算出する処理である。例えば次回購入日が312で、トイレットペーパーの通知開始幅が5日の場合、通知開始日は37となる。ステップ1003は、ステップ1002で算出した通知開始日に通知期間を加算して、通知終了日を決定する処理である。例えば通知開始日が37で、トイレットペーパーの通知期間が10日の場合、通知終了日は317となる。ユーザが購入したすべての商品カテゴリについて通知開始日と通知終了日を決定する場合は、図10に示す処理をそれぞれの商品カテゴリに対して実施すればよい。図10の処理により決定した通知開始日と通知終了日は、図11に示す形式のテーブルに保存する。買い時商品テーブル1101は、商品カテゴリごとに分析した結果の通知開始日と通知終了日を登録するフィールドを備える。図9の処理により得た購入間隔や次回購入日を合わせて保存しておいてもよい。図12は、本実施例にかかる推薦装置101が買い時商品を通知する処理のフローチャートである。ステップ1201は、トイレットペーパーに関する買い時商品テーブルを取得するステップである。前述の通り、取得する買い時商品テーブル1101には、商品カテゴリごとに通知開始日と通知終了日が格納されている。ステップ1202は、現在日時が通知開始日と同じか、または越えているか否かを判定する処理である。現在日時が通知開始日と同じか、または越えている場合はステップ1203へ進む。同じでなく、かつ越えていない場合は、本実施例の通知処理を終了する。ステップ1203は、現在日時が通知終了日をすでに経過しているか否かを判定する処理である。現在日時が通知終了日を経過していない場合はステップ1204へ進む。すでに経過している場合は、本実施例の通知処理を終了する。ステップ1204は、対象商品カテゴリを買い時商品としてユーザに通知するステップである。たとえば図13に示すようにユーザにトイレットペーパーが買い時であることを通知して、購入を促す。画面1301は、推薦装置101が表示部106に提示する画面の領域である。買い時商品の情報は、買い時商品詳細1302と、買い時商品画像1303の組み合わせで表示する。ユーザは買い時商品選択ボタン1304を選択することで通知されたトイレットペーパーについて個別の商品を探す画面に移行することができる。また、その他商品選択ボタン1305を選択することで、トイレットペーパーとは別の商品を探す画面に移行することもできる。なお、提示する買い時商品詳細1302と買い時商品画像1303は個別の商品に関する情報であってもよく、ユーザがよく購入している商品を少ない操作で購入することができればユーザにとって使い勝手がよい。本実施例の処理により、ユーザが定期的に購入する商品について購入を促し、ユーザの買い忘れを防止することができる。実施例1では、過去の購入間隔のみにもとづいて次回購入日を推測し、ユーザへの通知開始日と通知終了日を決定したが、最終購入品の消費期限を考慮して通知開始日と通知終了日を決定してもよい。図14は、本実施例における買い時商品提示の考え方である。この例では、牛乳を32、39、314の3回購入している。過去3回の購入間隔は7日と5日であり、その平均は6日である。次回もこの平均的な間隔に基づいて購入すると仮定すると、購入日は320であると推測できる。本実施例の推薦装置101が、牛乳については次回購入日の2日前からユーザに対して通知するとすれば、通知開始日は318となる。また、牛乳の通知期間を4日間とすれば、通知終了日は322となる。ここで、最終購入日の314に購入した牛乳の消費期限が318であったとすると、上記で決定した通知開始日は消費期限より後であり、ユーザは通知開始日の時点で最終購入品を消費し終わってすでに新しい牛乳を購入してしまっている可能性が高い。そこで、最終購入品の消費期限が通知開始日以前となる場合は、消費期限をもとに通知開始日と通知終了日を変更する。最終購入品の消費期限が318であった場合は、たとえば通知開始日を317に、通知終了日を319に変更する。消費期限に対して何日前からユーザへの通知を開始するか、何日間ユーザに通知を継続するかは、商品カテゴリごとに最適化されていることが望ましい。図15は、消費期限に対して何日前からユーザへの通知を開始するかを示す消費期限事前通知開始幅と、何日間ユーザに通知を継続するかを示す消費期限事前通知期間とを、商品カテゴリごとに定義した買い時通知パラメータテーブルである。たとえば、牛乳について最終購入品の消費期限に対しての1日前から通知を開始し、2日間通知を継続する場合は、消費期限事前通知開始幅を1、消費期限事前通知期間を2に設定しておく。本実施例にかかる推薦装置101は、あらかじめ消費期限事前通知開始幅と消費期限事前通知期間を定義した買い時通知パラメータ1501を蓄積部107に保持しておき、通知開始日や通知終了日を決定する際にこのテーブルを参照する。図16に、たとえば牛乳の消費期限に対して通知開始日と通知終了日を決定する処理のフローチャートを示す。あらかじめ図9と図10の処理により次回購入日、通知開始日、通知終了日が算出されているものとする。ステップ1601は、前回購入品について消費期限が保存されているか否かを判定する処理である。消費期限が保存されている場合は、ステップ1602に進む。消費期限が保存されていない場合は本実施例の処理は終了とし、あらかじめ算出しておいた通知開始日と通知終了日を利用する。ステップ1602は、前回購入品の消費期限があらかじめ算出しておいた通知開始日より前の日付であるか否かを判定する処理である。前回購入品の消費期限が通知開始日より前の日付である場合は、ステップ1603に進む。前回購入品の消費期限が通知開始日と同じか、または後の日付である場合は、本実施例の処理を終了し、あらかじめ算出しておいた通知開始日と通知終了日を利用する。ステップ1603は、前回購入品の消費期限にもとづいて通知開始日を変更する処理である。前回購入品の消費期限から消費期限事前通知開始幅を減算して、新たな通知開始日とする。例えば前回購入した牛乳の消費期限が318であって、牛乳の消費期限事前通知開始幅が1日である場合は、通知開始日を317に変更する。ステップ1604は、ステップ1603で変更した通知開始日をもとに通知終了日を変更する処理である。ステップ1603で変更した通知開始日に消費期限事前通知期間を加算して、新たな通知終了日とする。例えば通知開始日が317であって、牛乳の消費期限事前通知期間が2日である場合は、通知終了日を319に変更する。図16の処理により変更した通知開始日と通知終了日は、図17示す形式のテーブルに保存する。通知開始日や通知終了日とともに前回購入品の消費期限を関連づけて管理しておくことが望ましい。たとえばトイレットペーパーのように消費期限が存在しないものや、消費期限が不明な商品カテゴリについては、前回購入商品の消費期限を格納するフィールドは空でも構わない。図16の処理により変更した通知開始日と通知終了日にもとづいて行う買い時商品の通知は、図12に示した手順で行う。本実施例の処理により、ユーザが前回購入した商品の消費期限を考慮した上で事前に購入を促し、ユーザの買い忘れを防止することができる。実施例2では、前回購入品の消費期限にもとづいて通知開始日と通知終了日を決定したが、購入履歴からユーザが消費期限を意識する商品カテゴリであるかを判断した上で、通知開始日と通知終了日を決定してもよい。図18および、図19は、本実施例における買い時商品提示の考え方である。図19は、牛乳の購入履歴と通知開始日の関係を示している。この例では、牛乳を32、39、314の3回購入している。ここで、39に購入した商品の消費期限が315であったとすると、3回目の購入が314であることからユーザは39に購入した商品が消費期限を迎える前に次の商品を購入したことになる。つまり、牛乳についてこのユーザは消費期限を意識していると推測することができる。ここで、最終購入日の314に購入した牛乳の消費期限が318であったとすると、実施例2の処理によって最終購入品の消費期限にもとづいて通知開始日と通知終了日を決定することが望ましい。図19は、スナック菓子の購入履歴と通知開始日の関係を示している。この例では、スナック菓子を15、130、218の3回購入している。ここで、130に購入した商品の消費期限が210であったとすると、3回目の購入が218であることからユーザは130に購入した商品が消費期限を迎えた後に次の商品を購入したことになる。つまり、スナック菓子についてこのユーザは消費期限を意識していないと推測することができる。ここで、最終購入日の218に購入したせんべいの消費期限が35であったとしても、実施例1の処理によって購入間隔のみにもとづいて通知開始日と通知終了日を決定することが望ましい。図20に、たとえば牛乳についてユーザが消費期限を意識するか否かを判定した上で通知開始日と通知終了日を決定する処理のフローチャートを示す。あらかじめ図9と図10の処理により次回購入日、通知開始日、通知終了日が算出されているものとする。ステップ2001は、前々回購入品について消費期限が保存されているか否かを判定する処理である。消費期限が保存されている場合は、ステップ2002に進む。消費期限が保存されていない場合は本実施例の処理は終了とし、あらかじめ算出されている通知開始日と通知終了日を利用する。ステップ2002は、前々回購入品の消費期限が前回購入日より後の日付であるか否かを判定する処理である。前々回購入品の消費期限が前回購入日より後の日付である場合は、ステップ2003に進む。前々回購入品の消費期限が前回購入日と同じか、または前の日付である場合は、本実施例の処理を終了し、あらかじめ算出されている通知開始日と通知終了日を利用する。ステップ2003は、前回購入品について消費期限が保存されているか否かを判定する処理である。消費期限が保存されている場合は、ステップ2004に進む。消費期限が保存されていない場合は本実施例の処理は終了とし、あらかじめ算出されている通知開始日と通知終了日を利用する。ステップ2004は、前回購入品の消費期限が通知開始日より前の日付であるか否かを判定する処理である。前回購入品の消費期限が通知開始日より前の日付である場合は、ステップ2005に進む。前回購入品の消費期限が通知開始日と同じか、または後の日付である場合は、本実施例の処理を終了し、あらかじめ算出されている通知開始日と通知終了日を利用する。ステップ2005は、前回購入品の消費期限にもとづいて通知開始日を変更する処理である。前回購入品の消費期限から消費期限事前通知開始幅を減算して、新たな通知開始日とする。例えば前回購入した牛乳の消費期限が318であって、牛乳の消費期限事前通知開始幅が1日である場合は、通知開始日を317に変更する。ステップ2006は、ステップ2005で変更した通知開始日をもとに通知終了日を変更する処理である。ステップ2005で変更した通知開始日に消費期限事前通知期間を加算して、新たな通知終了日とする。例えば通知開始日が317であって、牛乳の消費期限事前通知期間が2日である場合は、通知終了日を319に変更する。図20の処理により変更した通知開始日と通知終了日は、図17に示す形式のテーブルに保存する。図20の処理により変更した通知開始日と通知終了日にもとづいて行う買い時商品の通知は、図12に示した手順で行う。本実施例の処理により、ユーザが消費期限を意識する商品であるか否かを考慮した上で事前に購入を促し、ユーザの買い忘れを防止することができる。実施例1から3では、過去の購入間隔にもとづいて次回購入日を推測し、ユーザへの通知開始日と通知終了日を決定したが、ユーザが通知期間内に一度も推薦装置を利用しなかった場合には、通知期間を延長するための予備通知期間を設けるようにしてもよい。図21は、本実施例における買い時商品提示の考え方である。この例では、牛乳を224、31、311、314の4回購入している。過去4回の購入間隔はそれぞれ5日、10日、3日であり、その平均は6日である。次回もこの平均的な間隔に基づいて購入すると仮定すると、次回購入日は320であると推測できる。本実施例の推薦装置101が、牛乳について次回購入日の2日前からユーザに対して通知するとすれば、通知開始日は318となる。また、牛乳の通知期間を4日間とすれば、通知終了日は322となる。さらに、本実施例で示す予備通知期間を2日とすれば、予備通知を含めた最終的な通知終了日は324となる。予備通知期間は、ユーザが通知開始日から通知終了日までの間に一度も推薦装置を利用しなかった場合に備えて設けたものであり、ユーザが買い時通知を見逃す可能性を小さくする役目を果たす。このため、ユーザが、元々の通知終了日である322までに推薦装置を利用したのであれば、予備通知期間を用いて通知終了日を延長する必要はない。本実施例にかかる推薦装置101は、次回購入日の何日前からユーザへの通知を開始するか、何日間ユーザに通知を継続するかを商品カテゴリごとに最適化して保持する。図22は、商品カテゴリごとに定義した買い時通知パラメータテーブルである。図8の買い時通知パラメータテーブルと異なる点は、新たに予備通知期間フィールドを設け、買い時通知期間を延長できるようにした点である。例えば、牛乳について次回購入日の2日前から通知を開始し、4日間通知を継続する場合は、通知開始幅を2、通知期間を4に設定しておくが、さらに通知終了日から継続して通知を行いたい場合は、予備通知期間に数値を設定しておく。ここでは、通知終了日の2日後まで通知を行う例を示している。買い時通知を見逃す恐れを減らす目的からして、予備通知期間は、牛乳や野菜などの食品であれば短めに設定し、トイレットペーパーなどの比較的長い間隔で購入を行う買い置き商品であれば長めに設定するなど、商品の持つ特性に応じて商品カテゴリ毎に適切に設定することが望ましい。買い時通知パラメータテーブル2201に対して、図9および図10と同様の処理を行うことで、次回購入日の推測、および次回購入日に対する通知開始日と通知終了日を決定することができる。同様に、ここで得られた通知終了日に対して、買い時通知パラメータテーブル2201の予備通知期間を加算することで、予備通知終了日を算出することができる。本処理により決定した情報を保存する買い時商品テーブルを、図23に示す。買い時商品テーブル2301は、商品カテゴリごとに分析した結果の通知開始日と通知終了日、および予備通知終了日を登録するフィールドを備える。また、図9のステップ905の処理により得られた平均購入間隔や、ステップ903により得られる最長購入間隔や、ステップ906によって得られた次回購入日を合わせて買い時商品テーブル2301に保存しておいてもよい。ここで、予備通知終了日は、購入履歴情報108から算出される最長購入間隔を基に決定するようにしてもよい。例えば図21の例では、牛乳を購入した日付224、31、311、314から、平均の購入間隔は6日であり、最長購入間隔は10日である。この利用者の場合、長くても10日以内に次回の牛乳を購入する可能性が高いことから、前回購入日から10日間が経過するまでを買い時商品の通知期間と設定することが有効と考えられる。図24は、本実施例にかかる推薦装置101が買い時商品を通知する処理のフローチャートである。ステップ2401は、牛乳に関する買い時商品テーブルを取得するステップである。前述の通り、取得する買い時商品テーブル2301には、商品カテゴリごとに通知開始日と通知終了日、および予備通知終了日が格納されている。ステップ2402は、現在日時が通知開始日と同じか、または越えているか否かを判定する処理である。現在日時が通知開始日と同じか、または越えている場合はステップ2403へ進む。同じでなく、かつ越えていない場合は、本実施例の通知処理を終了する。ステップ2403は、現在日時が通知終了日をすでに経過しているか否かを判定する処理である。現在日時が通知終了日を経過していない場合はステップ2404へ進む。ステップ2404は、対象商品カテゴリを買い時商品としてユーザに通知するステップである。例えば図13に示すような画面にてユーザに買い時であることを通知し、商品の購入を促す。ステップ2405は、牛乳に関する買い時商品テーブルを更新する処理であり、例えばユーザが次回の買い時通知を不要と考える場合には、通知を行わないように設定を行うことができる。設定は、例えば図25に示すような画面をユーザに提示することで行う。画面2501は、推薦装置101が表示部106に提示する画面の領域である。買い時商品の通知を継続するか否かを確認するメッセージ2502と、買い時商品画像2503を表示する。ユーザは、通知を継続してよい場合には、継続する2504を選択し、通知を希望しない場合には継続不要2505を選択する。継続不要2505が選択された場合、例えば買い時商品テーブル2301の通知開始日、通知終了日、あるいは予備通知終了日を無効にすることで、以降の買い時通知を行わないようにする。一方、図24のステップ2403において、現在日時がすでに通知終了日を過ぎている場合は、ステップ2406に進み、さらに現在日時が予備通知終了日を過ぎているか否かを判定する。すでに予備通知終了日を過ぎている場合は、本実施例の通知処理を終了する。予備通知終了日に達していない場合、ステップ2406からステップ2407に移行し、購入履歴を取得する処理を行う。取得する購入履歴には、過去に何らかの商品を購入した日時や、推薦装置を起動した日時が格納されている。ステップ2408は、前回推薦装置を起動して何らかの商品を購入した日時が、通知開始日を過ぎていたか否かを判定する処理である。ここでは、ユーザが買い時通知メッセージを目にしたか否かを確認したいのであるから、この場合の商品は、ステップ2405で扱う牛乳と異なっていてもよい。前回商品を購入したのが通知開始日より前であった場合は、ステップ2404に進み、買い時商品の通知を実行する。前回購入日時が通知開始日を越えていた場合、すなわち、通知開始日の後にユーザが推薦装置を利用した形跡がある場合は、ユーザがすでに買い時通知を受けている可能性が高いことから、買い時商品通知を行わず本実施例の処理を終了する。これにより、例えば買い時通知は目にしたものの意識的に牛乳を買わなかったようなユーザに対して、買い時通知が何度も行われるという煩わしさを解消することができる。なお、構成としてステップ2408の抑止処理を行わず、予備通知終了日に至るまで通知を継続するようにしても構わないし、またユーザが通知の有無を予め選択できるようにしてもよい。また、図24では前回商品購入を行った日時を用いる例について説明したが、前回推薦装置を起動した日時を用いるなど、ユーザが推薦装置を用いたことがわかる情報を用いるようにしても構わない。本実施例では説明を省略したが、購入履歴は、図4のステップ408に示すように、商品の注文に合わせて更新される。本実施例の処理により、ユーザが定期的に購入する商品について購入を促すと同時に、通知期間内に買い時通知を見ることができなかったユーザに対しては、通知期間を一定期間延長することで、ユーザの買い忘れを防止することができる。実施例4では、特定の商品について買い時通知を無効に設定したが、商品カテゴリ毎にユーザが買い時通知の要否を選択できるようにしてもよい。図26は、商品カテゴリごとに定義した買い時通知パラメータテーブルである。図22の買い時通知パラメータテーブルと異なる点は、新たに通知フラグフィールドを設け、カテゴリ毎に買い時通知の要否を選択できるようにした点である。ユーザが、牛乳に対して買い時通知を不要と考える場合、例えば図25のような画面提示により、買い時通知を否無効に設定することが可能である。買い時通知は、例えばティッシュやトイレットペーパー、シャンプーなどの買い置き商品に対して特に有効であると考えられることから、買い時通知パラメータテーブル2601のように、牛乳の通知は不要、米の通知は要、トイレットペーパーの通知は要など、商品の持つ特性に応じて商品カテゴリ毎に適切に設定することが望ましい。図27は、商品カテゴリ毎に買い時通知の要否を設定するための画面例である。買い時通知の設定2702を、牛乳2703、米2704、トイレットペーパー2705に対して、各々設定できるようにしている。ユーザは、通知を希望する場合には、要を、通知を希望しない場合には不要を選択する。図28は、本実施例にかかる推薦装置101が買い時商品を通知する処理のフローチャートである。図24と同じ機能については同一番号を付し、説明を省略する。ステップ2401は、商品カテゴリに関する買い時商品テーブルを取得するステップである。ここで参照する買い時商品テーブルには、買い時通知パラメータテーブル2601で設定した通知フラグが反映される。ステップ2801は、本実施例で新たに行う判定処理であり、対象となっている商品に対して、前述した通知フラグが要か否かを判定する。例えば、買い時通知パラメータテーブル2601を参照する場合、牛乳に対する通知は否であり、米、トイレットペーパーに対する通知は要となる。通知が要と判定された場合、ステップ2402に移行し、買い時通知を行うための処理を実行する。ステップ2801において、買い時通知が否、すなわち不要と判定された場合、買い時通知は行わずステップ2405に移行する。ステップ2405では、対象商品に対する買い時商品テーブルの更新を実行する。ユーザが次回の買い時通知も不要と考える場合には、買い時商品テーブルが参照する通知フラグは否のままであり、買い時通知を有効に変更したい場合には、例えば画面2501や画面2701を表示し、通知フラグを要に変更する。本実施例の処理により、ユーザが希望する商品に対しては買い時通知により購入を促すことができ、ユーザが希望しない商品に対しては買い時通知を行わないようにすることができるため、必要以上に買い時通知が行われることを防ぎながら、適切にユーザの買い忘れを防止することができる。