(57)【要約】【課題】アクセス先へのアクセスを催促する催促通知に対する複数の利用者からのアクセスによるアクセス先にかかる最大負荷を低減する。【解決手段】サーバ１４が有するユーザ追跡情報ＤＢ３６には、ユーザを識別するユーザＩＤと、通知メールを送信してから当該ユーザがサーバ１４へアクセスするまでのアクセス時間を示すアクセス時間区分とが関連付けられて記憶されている。送信時刻設定部５０は、ユーザ追跡情報ＤＢ３６が示す各ユーザのアクセス時間区分に基づいて、各アクセス時間区分において、当該アクセス時間区分に関連付けられた複数のユーザを、各単位時間におけるユーザの数が平滑化されるように、各単位時間に割り当てる。送信時刻設定部５０は、各単位時間に割り当てられたユーザグループ毎に、当該単位時間に応じた更新送信時刻を設定する。【選択図】図１
2018041298.tif 000002
【特許請求の範囲】
【請求項１】
過去における、各利用者に対してアクセス先へのアクセスを催促するための催促通知を行った過去催促通知時刻から各利用者が前記アクセス先にアクセスした時刻までのアクセス時間を各利用者に関連付けて記憶するアクセス時間記憶部と、
各利用者の前記アクセス時間に基づいて、前記催促通知に応じた各利用者からのアクセスが時間方向に分散されるように、各利用者に対して前記催促通知を行う更新催促通知時刻を設定する催促通知時刻設定部と、
を備えることを特徴とする負荷分散装置。
【請求項２】
前記アクセス時間記憶部は、予め定められた複数のアクセス時間区分に分類して前記アクセス時間を記憶し、
前記催促通知時刻設定部は、一のアクセス時間区分に関連付けられた利用者群を、予め定められた複数の単位時間における利用者の数が平滑化されるように、各単位時間に割り当て、各単位時間に割り当てられた利用者グループ毎に、前記単位時間に応じた前記更新催促通知時刻を設定する、
ことを特徴とする請求項１に記載の負荷分散装置。
【請求項３】
前記アクセス時間記憶部は、さらに、各利用者に関連付けて前記過去催促通知時刻を記憶し、
前記催促通知時刻設定部は、前記利用者の前記過去催促通知時刻に応じた前記単位時間に当該利用者を優先的に割り当てる、
ことを特徴とする請求項２に記載の負荷分散装置。
【請求項４】
前記アクセス時間記憶部は、一の利用者に対して、前記過去催促通知時刻と前記アクセス時間との組を複数関連付けて記憶し、
前記負荷分散装置は、
前記過去催促通知時刻及び前記アクセス時間に基づいて、一の利用者に対する複数の予想アクセス時刻を演算する予想アクセス時刻演算部と、
一の利用者に対する前記過去催促通知時刻と前記予想アクセス時刻との複数の組に基づいて、一の利用者に対する前記過去催促通知時刻と前記予想アクセス時刻との組毎に、当該過去催促通知時刻に前記催促通知を行った場合に当該予想アクセス時刻に当該利用者が前記アクセス先にアクセスする期待値である予想アクセス率を演算する予想アクセス率演算部と、
をさらに備え、
前記催促通知時刻設定部は、前記予想アクセス時刻に応じて各単位時間に割り当てられた各利用者の予想アクセス率の和が平滑化されるように、各利用者を、対応する複数の予想アクセス時刻から選択された一の予想アクセス時刻に応じて各単位時間に割り当て、前記選択された一の予想アクセス時刻に対応する前記過去催促通知時刻を前記更新催促通知時刻として設定する、
ことを特徴とする請求項１に記載の負荷分散装置。
【請求項５】
前記予想アクセス率演算部は、前記一の利用者に対応する複数の前記予想アクセス率において、現時点により近い時点で取得された前記過去催促通知時刻に対応する前記予想アクセス率を相対的に低く演算する、
ことを特徴とする請求項４に記載の負荷分散装置。
【請求項６】
コンピュータを、
過去における、各利用者に対してアクセス先へのアクセスを催促するための催促通知を行った過去催促通知時刻から各利用者が前記アクセス先にアクセスした時刻までのアクセス時間を各利用者に関連付けて記憶するアクセス時間記憶部と、
各利用者の前記アクセス時間に基づいて、前記催促通知に応じた各利用者からのアクセスが時間方向に分散されるように、各利用者に対して前記催促通知を行う更新催促通知時刻を設定する催促通知時刻設定部と、
として機能させることを特徴とする負荷分散プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、負荷分散装置及び負荷分散プログラムに関する。
【背景技術】
【０００２】
従来、利用者からアクセスされることで利用者に種々のサービスを提供する通信装置が知られている。このような通信装置としては、例えばウェブサーバやアプリケーションサーバなどがある。通信装置において、利用者からのアクセスが短時間に集中して負荷が増大することで、通信装置が適切にサービスを提供することができなくなる場合がある。そこで、従来、通信装置の負荷が増大しても適切にサービスを提供し続けることができるようにするための技術が提案されている。
【０００３】
例えば、特許文献１には、画像処理サービスを提供する仮想サーバであって、仮想サーバに対するアクセス負荷に応じて仮想サーバの数を増やすことで、仮想サーバの処理能力を増大させるシステムが開示されている。また、特許文献２には、配信サーバから複数の機器にデジタル情報が配信されるシステムであって、配信サーバが一の機器にデジタル情報を配信した後に、他の機器が当該デジタル情報を配信サーバに要求した場合、一の機器から他の機器に対して当該デジタル情報を配信することで、配信サーバの負荷を低減するシステムが開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１１−６１６０８号公報
【特許文献２】特許２００５−３２２０３３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
利用者に対して催促通知を行うことで当該利用者にアクセス先へのアクセスを促す場合がある。例えば、会員制ポータルサイトを提供するサーバから請求書発行通知メールやプロモーションメールなどを利用者に送信することで、利用者に当該サーバ（会員制ポータルサイト）へのアクセスを促す場合がある。このような場合において、比較的短時間の間に催促通知を複数のユーザに送信したい場合がある。例えば、催促通知としての請求書発行通知メールは、請求書の締め日に一斉に送信されることが望まれる。そうすると、催促通知を受けた複数の利用者からのアクセスが短時間の間に集中してしまい、アクセス先（例えばサーバなど）の負荷が短時間だけ突出してしまうという問題が生じる。アクセス先の処理能力を当該突出した負荷に合わせることが考えられるが、他の時間においては負荷はそれほど大きくない場合もあり、費用対効果の点で問題がある。
【０００６】
本発明の目的は、アクセス先へのアクセスを催促する催促通知を複数の利用者に同時通知する場合に比して、催促通知に対する複数の利用者からのアクセスによるアクセス先にかかる最大負荷を低減することにある。
【課題を解決するための手段】
【０００７】
請求項１に係る発明は、過去における、各利用者に対してアクセス先へのアクセスを催促するための催促通知を行った過去催促通知時刻から各利用者が前記アクセス先にアクセスした時刻までのアクセス時間を各利用者に関連付けて記憶するアクセス時間記憶部と、各利用者の前記アクセス時間に基づいて、前記催促通知に応じた各利用者からのアクセスが時間方向に分散されるように、各利用者に対して前記催促通知を行う更新催促通知時刻を設定する催促通知時刻設定部と、を備えることを特徴とする負荷分散装置である。
【０００８】
請求項２に係る発明は、前記アクセス時間記憶部は、予め定められた複数のアクセス時間区分に分類して前記アクセス時間を記憶し、前記催促通知時刻設定部は、一のアクセス時間区分に関連付けられた利用者群を、予め定められた複数の単位時間における利用者の数が平滑化されるように、各単位時間に割り当て、各単位時間に割り当てられた利用者グループ毎に、前記単位時間に応じた前記更新催促通知時刻を設定する、ことを特徴とする請求項１に記載の負荷分散装置である。
【０００９】
請求項３に係る発明は、前記アクセス時間記憶部は、さらに、各利用者に関連付けて前記過去催促通知時刻を記憶し、前記催促通知時刻設定部は、前記利用者の前記過去催促通知時刻に応じた前記単位時間に当該利用者を優先的に割り当てる、ことを特徴とする請求項２に記載の負荷分散装置である。
【００１０】
請求項４に係る発明は、前記アクセス時間記憶部は、一の利用者に対して、前記過去催促通知時刻と前記アクセス時間との組を複数関連付けて記憶し、前記負荷分散装置は、前記過去催促通知時刻及び前記アクセス時間に基づいて、一の利用者に対する複数の予想アクセス時刻を演算する予想アクセス時刻演算部と、一の利用者に対する前記過去催促通知時刻と前記予想アクセス時刻との複数の組に基づいて、一の利用者に対する前記過去催促通知時刻と前記予想アクセス時刻との組毎に、当該過去催促通知時刻に前記催促通知を行った場合に当該予想アクセス時刻に当該利用者が前記アクセス先にアクセスする期待値である予想アクセス率を演算する予想アクセス率演算部と、をさらに備え、前記催促通知時刻設定部は、前記予想アクセス時刻に応じて各単位時間に割り当てられた各利用者の予想アクセス率の和が平滑化されるように、各利用者を、対応する複数の予想アクセス時刻から選択された一の予想アクセス時刻に応じて各単位時間に割り当て、前記選択された一の予想アクセス時刻に対応する前記過去催促通知時刻を前記更新催促通知時刻として設定する、ことを特徴とする請求項１に記載の負荷分散装置である。
【００１１】
請求項５に係る発明は、前記予想アクセス率演算部は、前記一の利用者に対応する複数の前記予想アクセス率において、現時点により近い時点で取得された前記過去催促通知時刻に対応する前記予想アクセス率を相対的に低く演算する、ことを特徴とする請求項４に記載の負荷分散装置である。
【００１２】
請求項６に係る発明は、コンピュータを、過去における、各利用者に対してアクセス先へのアクセスを催促するための催促通知を行った過去催促通知時刻から各利用者が前記アクセス先にアクセスした時刻までのアクセス時間を各利用者に関連付けて記憶するアクセス時間記憶部と、各利用者の前記アクセス時間に基づいて、前記催促通知に応じた各利用者からのアクセスが時間方向に分散されるように、各利用者に対して前記催促通知を行う更新催促通知時刻を設定する催促通知時刻設定部と、として機能させることを特徴とする負荷分散プログラムである。
【発明の効果】
【００１３】
請求項１、２及び６に記載の発明によれば、アクセス先へのアクセスを催促する催促通知を複数の利用者に同時通知する場合に比して、催促通知に対する複数の利用者からのアクセスによるアクセス先にかかる最大負荷を低減することができる。
【００１４】
請求項３に記載の発明によれば、各利用者に対する更新催促通知時刻を、当該利用者の過去催促通知時刻と同じ時刻に設定することができる。
【００１５】
請求項４に記載の発明によれば、一の利用者に複数の過去催促通知時刻が関連付けられている場合に、各単位時間において複数の利用者からの複数のアクセスが時間方向に分散されるように、各利用者の更新催促通知時刻を複数の過去催促通知時刻から選択することができる。
【００１６】
請求項５に記載の発明によれば、現時点により近い時点で取得された過去催促通知時刻を更新催促通知時刻として設定することができる。
【図面の簡単な説明】
【００１７】
【図１】第１実施形態に係る情報提供システムの構成概略図である。
【図２】第１実施形態におけるユーザ追跡情報ＤＢの例を示す概念図である。
【図３】第１実施形態における送信時刻更新処理がの実施される様子を示す概念図である。
【図４】第１実施形態における送信時刻更新処理の流れを示すフローチャートである。
【図５】第２実施形態に係る情報提供システムの構成概略図である。
【図６】第２実施形態におけるユーザ追跡情報ＤＢの例を示す概念図である。
【図７】予想アクセス時刻演算部の演算結果を示す概念図である。
【図８】予想アクセス率演算部の演算結果を示す概念図である。
【図９】第２実施形態における送信時刻更新処理の流れを示すフローチャートである。
【図１０】図９のステップＳ２８の処理結果を示す概念図である。
【図１１】図９のステップＳ３０の処理結果を示す概念図である。
【図１２】図９のステップＳ３６の処理結果を示す概念図である。
【発明を実施するための形態】
【００１８】
以下、本発明の実施形態を図面に基づいて説明する。
【００１９】
＜第１実施形態＞
図１に、第１実施形態に係る負荷分散システムとしての情報提供システム１０の構成概略図が示されている。情報提供システム１０は、複数の利用者であるユーザが使用する複数のユーザ端末１２、及び負荷分散装置としてのサーバ１４を含んで構成される。複数のユーザ端末１２とサーバ１４との間は、ＬＡＮ（Local Area Network）あるいはインターネットなどの通信回線を介して通信可能に接続されている。情報提供システム１０においては、情報提供システム１０に登録された各ユーザが利用する各ユーザ端末１２に対して、サーバ１４から催促通知としての通知メール（詳細は後述）が送信される。ユーザは、ユーザ端末１２において当該通知メールを閲覧することでサーバ１４にアクセスする。ユーザ端末１２からのアクセスを受けたサーバ１４は各種情報をユーザ端末１２に送信する。
【００２０】
ユーザ端末１２は、例えばＰＣ（Personal Computer）あるいはタブレット端末などである。ユーザ端末１２は、通常のコンピュータが有する、ＣＰＵ（Central Processing Unit）などからなる制御部、ハードディスク、ＲＯＭ（Read Only Memory）あるいはＲＡＭ（Random Access Memory）などからなる記憶部、マウス、キーボードなどからなる入力部、液晶パネルなどからなる表示部、ネットワークアダプタなどからなる通信部、などを含んでいる。
【００２１】
サーバ１４は、ウェブサーバとして機能し得る程度の処理能力を有するコンピュータから構成される。サーバ１４としては、以下に説明する機能を発揮可能である限りにおいてどのような装置であってもよい。以下、サーバ１４の各部について説明する。
【００２２】
通信部２０は、例えばネットワークアダプタなどから構成される。通信部２０は、各ユーザ端末１２と通信するためのものである。具体的には、通信部２０は、通知メールを各ユーザ端末１２に送信し、各ユーザ端末１２からのアクセス要求を受信し、さらに各ユーザ端末１２に各種情報を送信するものである。
【００２３】
記憶部３０は、例えばハードディスク、ＲＯＭ、あるいはＲＡＭなどから構成される。記憶部３０には、サーバ１４の各部を機能させるためのプログラムが記憶される。また、図１に示される通り、記憶部３０においては、ユーザＤＢ３２、メール設定ＤＢ３４、及びユーザ追跡情報ＤＢ３６が構築される。
【００２４】
ユーザＤＢ３２は、情報提供システム１０に登録されたユーザに関する情報が記憶される。詳しくは、ユーザＤＢ３２には、催促通知先を示す催促通知先情報、ユーザを識別するユーザ識別情報、及び当該ユーザが各種催促通知の通知対象であるか否かを示す情報などが関連付けられて記憶される。本実施形態では、催促通知先情報としてユーザのメールアドレス、ユーザ識別情報としてユーザＩＤが記憶される。
【００２５】
メール設定ＤＢ３４には、催促通知に関する情報が記憶される。詳しくは、情報提供システム１０に登録された複数のユーザに対して催促通知を開始する催促通知開始時刻、及び催促通知を終了する催促通知終了時刻が記憶される。催促通知開始時刻から催促通知終了時刻までの間の時間が複数のユーザに対する催促通知を完了すべき時間を表すことになる。また、メール設定ＤＢ３４には、後述の制御部４０による、ユーザからサーバ１４へのアクセス数を時間方向に平滑化する平滑化処理の単位時間を示す単位時間情報が記憶される。本実施形態では、催促通知開始時刻として各種通知メールの送信開始時刻、催促通知終了時刻として各種通知メールの送信終了時刻が記憶される。
【００２６】
ユーザ追跡情報ＤＢ３６には、過去においてユーザに催促通知が行われた過去催促通知時刻から当該ユーザがサーバ１４にアクセスしたアクセス時刻までの時間であるアクセス時間が関連付けられて記憶されている。このように、記憶部３０は、アクセス時間記憶部としても機能する。本実施形態では、過去催促通知時刻として、通知メールが送信された過去送信時刻からアクセス時刻までのアクセス時間が記憶される。
【００２７】
図２に、第１実施形態におけるユーザ追跡情報ＤＢ３６の内容を示す概念図が示されている。図２に示されるように、本実施形態では、ユーザ追跡情報ＤＢ３６はテーブル形式となっており、各レコードにおいてユーザＩＤとアクセス時間が関連付けられている。アクセス時間は、例えば分単位（１分、２分、３分・・・など）で記憶されてよい。あるいは、複数のアクセス時間区分を予め設定しておき、アクセス時間を当該アクセス時間区分に分類するようにしてもよい。例えば、本実施形態では、アクセス時間区分として「５分以内」、「５〜６０分以内」、及び、アクセス無しを意味する「Ｎ／Ａ」の３つが設定されている。なお、「Ｎ／Ａ」には、６０分以上経過してからアクセスしたユーザも含まれるが、統計上、そのようなユーザは非常に少ない場合が多い。
【００２８】
望ましくは、ユーザ追跡情報ＤＢ３６には、各ユーザＩＤに関連付けられて、ユーザＩＤが示すユーザに通知メールが送信された時刻である過去送信時刻が記憶される。
【００２９】
図２に示されたユーザ追跡情報ＤＢ３６によれば、例えば、ユーザＩＤ「ａａａ」が示すユーザ（以下単にユーザ「ａａａ」と記載する）は、サーバ１４から通知メールがユーザ「ａａａ」が使用するユーザ端末１２に送信された後、５分以内にサーバ１４へアクセスしたことが把握できる。また、ユーザ「ａａａ」には、通知メールが「９：００」に送信されたことが把握できる。
【００３０】
ユーザ追跡情報ＤＢ３６は、後述の制御部４０により生成あるいは更新される。ユーザ追跡情報ＤＢ１６を生成あるいは更新する処理については後述する。
【００３１】
なお、第１実施形態においては、ユーザ毎に、前回通知メールが送信されたときのアクセス時間のみがユーザ追跡情報ＤＢ３６に記憶される。例えば、図２に示す内容が記憶されている状態において、ユーザ「ａａａ」が通知メール送信から３０分経過後にサーバ１４にアクセスした場合は、ユーザＩＤ「ａａａ」に関連付けられるアクセス時間が「５〜６０分以内」に更新される。
【００３２】
制御部４０は、例えばＣＰＵなどから構成される。制御部４０は、記憶部３０に記憶されたプログラムに従って、サーバ１４の各部を制御する。また、制御部４０は、当該プログラムにより、メール生成部４２、送信時刻取得部４４、アクセス情報取得部４６、ユーザ追跡情報生成部４８、及び、催促通知時刻設定部としての送信時刻設定部５０としても機能する。
【００３３】
メール生成部４２は、各ユーザ端末１２に送信される通知メールを生成する。メール生成部４２は、ユーザＤＢ３２に記憶されたユーザのメールアドレスを参照して、通知メールの送信先メールアドレスを設定する。また、メール生成部４２は、ユーザＤＢ３２に記憶されたユーザＩＤを参照して、通知メールの本文中に、ユーザＩＤを含むＵＲＬ（Uniform Resource Locator）を含める。当該ＵＲＬは、サーバ１４からユーザへ提供される情報の所在を示すものである。これにより、通知メールを受信したユーザは、当該通知メールを開いて当該ＵＲＬをクリックあるいはタップすることで、サーバ１４へアクセスすることができる。且つ、サーバ１４側としても、ＵＲＬにユーザＩＤが含まれているから、どのユーザからアクセスされたのかを把握することができる。なお、通知メールには、上記の他、ユーザへサーバ１４へのアクセスを促す文あるいは画像などが含まれていてもよい。メール生成部４２により生成された通知メールは通信部２０に送られ、通信部２０から各ユーザ端末１２に送信される。
【００３４】
送信時刻取得部４４は、メール生成部４２が生成した通知メールがユーザ端末１２に送信された時刻（過去送信時刻）を取得する。具体的には、サーバ１４は、例えば、タイマＩＣや水晶振動子、クロックモジュールなどを含んで構成される計時部（不図示）を有しており、送信時刻取得部４４は、通信部２０が通知メールを送信したときに計時部から取得した時刻を過去送信時刻として取得する。送信時刻取得部４４は、通知メールの送信先であるユーザのユーザＩＤと当該通知メールの過去送信時刻とを関連付けてユーザ追跡情報生成部４８へ出力する。
【００３５】
アクセス情報取得部４６は、ユーザ端末１２に送信された通知メールに含まれるＵＲＬにユーザがアクセスした場合に、当該ＵＲＬに含まれるユーザＩＤ、及びアクセス時刻を取得する。具体的には、アクセス情報取得部４６は、アクセス先として指定されたＵＲＬを解析することでユーザＩＤを取得する。また、通信部２０がＵＲＬへのアクセス要求をユーザ端末１２から受信したときに計時部から取得した時刻をアクセス時刻として取得する。アクセス情報取得部４６は、取得したユーザＩＤとアクセス時刻とを関連付けてユーザ追跡情報生成部４８へ出力する。
【００３６】
ユーザ追跡情報生成部４８は、送信時刻取得部４４及びアクセス情報取得部４６からの情報に基づいて、ユーザ追跡情報ＤＢ３６を生成あるいは更新する処理を行う。具体的には、送信時刻取得部４４からユーザＩＤと過去送信時刻を受け取った後に、アクセス情報取得部４６から当該ユーザＩＤに関連付けられたアクセス時刻を受け取った場合、ユーザ追跡情報生成部４８は、当該過去送信時刻から当該アクセス時刻までの時間をアクセス時間として算出する。そして、当該ユーザＩＤとアクセス時間を関連付けてユーザ追跡情報ＤＢ３６に記憶させる。好適には、さらに、当該ユーザＩＤに当該過去送信時間を関連付けてユーザ追跡情報ＤＢ３６に記憶させる。このようにして、ユーザ追跡情報ＤＢ３６が生成あるいは更新される。
【００３７】
送信時刻設定部５０は、メール設定ＤＢ３４及びユーザ追跡情報ＤＢ３６に基づいて、各ユーザに対する更新催促通知時刻としての、通知メールの更新送信時刻を設定する送信時刻更新処理を行う。詳しくは、送信時刻設定部５０は、ユーザ追跡情報ＤＢ３６が示す各ユーザのアクセス時間を考慮しながら、メール設定ＤＢ３４に記憶された通知メールの送信開始時刻から送信終了時刻までの間において、通知メールに応じた各ユーザからのアクセスが時間方向に分散されるように、各ユーザに対する通知メールの送信時刻を設定する。以後、送信時刻更新処理により更新された送信時刻を「更新送信時刻」と記載する。送信時刻更新処理の詳細については後述する。
【００３８】
情報提供システム１０の構成概要については以上の通りである。以下、図１を参照しつつ、図４のフローチャートに沿って、第１実施形態における送信時刻更新処理の流れについて説明する。なお、図４のフローチャートの開始時において、メール設定ＤＢ３４には、送信開始時刻として「９：００」、送信終了時刻として「１０：３０」、単位時間情報として「３０分」が記憶されているとする。また、ユーザ追跡情報ＤＢ３６には、図２に示す内容が記憶されているとする。
【００３９】
ステップＳ１０において、まず、送信時刻設定部５０は、メール設定ＤＢ３４に記憶された単位時間情報に基づいて、通知メールの送信開始時刻から送信終了時刻までの間において複数の単位時間を設定する。上述のように、本例では、送信開始時刻が「９：００」、送信終了時刻が「１０：３０」、単位時間情報が「３０分」であるから、送信時刻設定部５０は、「９：００〜９：３０」、「９：３０〜１０：００」、及び「１０：００〜１０：３０」の３つの単位時間を設定する。なお、本例では単位時間は３０分であるが、単位時間は例えば１分、５分あるいは１０分など、情報提供システム１０の管理者などによって適宜設定されてよい。
【００４０】
次に、送信時刻設定部５０は、単位時間毎にアクセス時間区分を定義する。上述のように、本実施形態では、アクセス時間区分として「５分以内」、「５〜６０分以内」、及び「Ｎ／Ａ」の３つが設定されているため、単位時間毎に上記３つのアクセス時間区分を定義する。その結果、図３に示すように、単位時間とアクセス時間区分のマトリクスが形成される。
【００４１】
ステップＳ１２において、送信時刻設定部５０は、ユーザ追跡情報ＤＢ３６が示す各ユーザのアクセス時間区分に基づいて、各アクセス時間区分において、当該アクセス時間区分に関連付けられた複数のユーザを、各単位時間におけるユーザの数が平滑化されるように、各単位時間に割り当てる処理を行う。
【００４２】
例えば、図２を参照するに、アクセス時間区分「５分以内」には、利用者群として、ユーザ「ａａａ」、「ｄｄｄ」、及び「ｅｅｅ」の３人のユーザが関連付けられている。したがって、送信時刻設定部５０は、図３に示すアクセス時間区分列「５分以内」において、当該３人のユーザを各単位時間に対して均等に割り当てる。具体的には、図３に示すように、単位時間「９：００〜９：３０」にユーザ「ａａａ」を割り当て、単位時間「９：３０〜１０：００」にユーザ「ｄｄｄ」を割り当て、単位時間「１０：００〜１０：３０」にユーザ「ｅｅｅ」を割り当てる。なお、「均等」とは、各単位時間に割り当てられたユーザの数が完全に同一となる場合のみではなく、各単位時間に割り当てられたユーザの数が略同一（同等）となる場合までも含む概念である。
【００４３】
同様に、送信時刻設定部５０は、アクセス時間区分列「５〜６０分以内」においても、当該アクセス時間区分に関連付けられた各ユーザを各単位時間に対して均等に分類する。具体的には、図３に示すように、単位時間「９：００〜９：３０」にユーザ「ｂｂｂ」を割り当て、単位時間「９：３０〜１０：００」にユーザ「ｇｇｇ」を割り当て、単位時間「１０：００〜１０：３０」にユーザ「ｆｆｆ」を割り当てる。
【００４４】
送信時刻設定部５０は、アクセス時間区分列「Ｎ／Ａ」においても、同様の処理を行う。本例では、図３に示されるように、単位時間「９：００〜９：３０」にユーザ「ｃｃｃ」を割り当てる。
【００４５】
以上のように、上記マトリクスの各セルにユーザが割り当てられると、ステップＳ１４において、送信時刻設定部５０は、各単位時間に割り当てられたユーザグループ毎に、当該単位時間に応じた更新送信時刻を設定する。本例では、各単位時間に割り当てられた各ユーザの更新送信時刻を、各単位時間の開始時刻に設定する。具体的には、単位時間「９：００〜９：３０」に割り当てられたユーザグループであるユーザ「ａａａ」、「ｂｂｂ」、及び「ｃｃｃ」に対して、更新送信時刻「９：００」を設定し、単位時間「９：３０〜１０：００」に割り当てられたユーザグループであるユーザ「ｄｄｄ」及び「ｇｇｇ」に対して、更新送信時刻「９：３０」を設定し、単位時間「１０：００〜１０：３０」に割り当てられたユーザグループであるユーザ「ｅｅｅ」及び「ｆｆｆ」に対して、更新送信時刻「１０：００」を設定する。
【００４６】
上述した送信時刻更新処理によれば、通知メールに対する各ユーザからのアクセスを時間方向に分散することができる。つまり、アクセス集中によるサーバ１４の最大負荷を低減することができる。例えば、図２を参照するに、送信時刻更新処理前は、ユーザ「ａａａ」、「ｄｄｄ」、及び「ｅｅｅ」に対していずれも「９：００」に通知メールが送信されていた。上記３ユーザは、いずれも５分以内にサーバ１４にアクセスする可能性が高いから、９：００〜９：０５までの間に３名からのアクセスが集中すると考えられる。これに対し、送信時刻更新処理後においては、当該３名に対する通知メールの送信時間が分散されている。これにより、ユーザ「ａａａ」は９：００〜９：０５までの間にサーバ１４にアクセスすると考えられ、ユーザ「ｄｄｄ」は９：３０〜９：３５までの間にサーバ１４にアクセスすると考えられ、ユーザ「ｅｅｅ」は１０：００〜１０：０５までの間にサーバ１４にアクセスすると考えられる。つまり、通知メールに対する各ユーザからのアクセスが時間方向に分散される。
【００４７】
かつ、単位時間は、メール設定ＤＢ３４に記憶された送信開始時刻から送信終了時刻までの間において設定されるから、各ユーザに対する通知メールは、要望の時間内において全て送信することができる。
【００４８】
望ましくは、送信時刻設定部５０は、マトリクスの各セルに対するユーザの割り当ての際に、ユーザ追跡情報ＤＢ３６に記憶された過去送信時刻を考慮するようにしてもよい。詳しくは、ユーザに関連付けられた過去送信時刻に応じた単位時間に、当該ユーザを優先的に割り当てるようにしてもよい。図３のアクセス時間区分列「５〜６０分以内」に着目する。図３の例では、単位時間「９：３０〜１０：００」にユーザ「ｇｇｇ」が割り当てられ、単位時間「１０：００〜１０：３０」にユーザ「ｆｆｆ」が割り当てられているが、平滑化の観点からは、単位時間「９：３０〜１０：００」にユーザ「ｆｆｆ」を割り当て、単位時間「１０：００〜１０：３０」にユーザ「ｇｇｇ」を割り当てもよい。しかしながら、ここでは、ユーザ追跡情報ＤＢ３６において、ユーザＩＤ「ｆｆｆ」に過去送信時刻「１０：００」が関連付けられ、ユーザＩＤ「ｇｇｇ」に過去送信時刻「９：３０」が関連付けられているため、ユーザ「ｆｆｆ」を過去送信時刻「１０：００」に対応する単位時間「１０：００〜１０：３０」に優先的に割り当て、ユーザ「ｇｇｇ」を過去送信時刻「９：３０」に対応する単位時間「９：３０〜１０：００」に優先的に割り当てている。
【００４９】
このようにすることで、各ユーザの通知メールの送信時刻をできるだけ前回と同じ時刻にすることができる。例えば、請求書を閲覧可能な会員制ポータルサイトにおいて、月１回の請求書発行通知メールをユーザ端末１２に送信する場合において、あるユーザに対しては毎月９：００に送信されている場合、ユーザとしては、毎月９：００頃に請求書発行通知メールが送信されることを期待する場合がある。このような場合に、当該ユーザに対する更新送信時間が１１：００に更新される、ということが生じる可能性を低減することができる。
【００５０】
また、ユーザ追跡情報ＤＢ３６において「Ｎ／Ａ」が関連付けられた複数のユーザについて、当該複数のユーザがサーバ１４へアクセスしないならば、当該複数のユーザはサーバ１４の負荷に影響を与えることがないのであるから、どの単位時間に割り当てられてもよい。しかしながら、前回通知メールに対してアクセスしなかったユーザが次回アクセスする場合も考えられる。したがって、「Ｎ／Ａ」が関連付けられた複数のユーザについても、各単位時間に均等に分散させるのが好ましい。
【００５１】
＜第２実施形態＞
図５に、第２実施形態に係る負荷分散システムとしての情報提供システム６０の構成概略図が示されている。情報提供システム６０において、第１実施形態に係る情報提供システム１０と同様の構成については、同一の符号を付し、その説明を省略する。情報提供システム６０は、ユーザ追跡情報ＤＢ３６に記憶される内容、制御部４０がさらに予想アクセス時刻演算部７０及び予想アクセス率演算部７２の機能を有する点、並びに、送信時刻更新処理の内容において、第１実施形態に係る情報提供システム１０と異なる。
【００５２】
第１実施形態においては、ユーザ追跡情報ＤＢ３６には、ユーザ毎に、前回通知メールが送信されたときのアクセス時間のみがユーザ追跡情報ＤＢ３６に記憶されていた。第２実施形態においては、ユーザ追跡情報ＤＢ３６には、各ユーザの過去における複数のアクセス時間が蓄積して記憶される。
【００５３】
図６に、第２実施形態におけるユーザ追跡情報ＤＢ３６の内容を示す概念図が示されている。図６に示されるように、第２実施形態においては、ユーザがサーバ１４へアクセスした場合、当該アクセスに対応する過去送信時刻及びアクセス時間区分がユーザＩＤに関連付けられて新たなレコードとして蓄積記憶される。これにより、１人のユーザに対して過去送信時刻とアクセス時間区分との組が複数記憶される。例えば、ユーザ「ａａａ」についてみると、３日前に取得された過去送信時間「９：００」及びアクセス時間区分「５分以内」のレコード、２日前に取得された過去送信時間「９：００」及びアクセス時間区分「Ｎ／Ａ」のレコード、１日前に取得された過去送信時間「９：００」及びアクセス時間区分「５分以内」のレコードの３つのレコードが記憶されている。
【００５４】
予想アクセス時刻演算部７０は、ユーザ追跡情報ＤＢ３６に基づいて、ユーザ追跡情報ＤＢ３６のレコード毎に、ユーザがサーバ１４へアクセスすると予想される予想アクセス時刻を演算する。上述のように、第２実施形態におけるユーザ追跡情報ＤＢ３６には、１人のユーザに対して複数の過去送信時刻とアクセス時間区分との組が記憶される。したがって、予想アクセス時刻演算部７０は、１人のユーザに対して複数の予想アクセス時刻を演算する。
【００５５】
詳しくは、予想アクセス時刻演算部７０は、過去送信時刻及びアクセス時間区分に基づいて予想アクセス時刻を演算する。具体的には、過去送信時刻からアクセス時間区分が示す時間内の時刻のいずれかが予想アクセス時刻として演算される。本例では、過去送信時刻が「９：００」でありアクセス時間区分が「５分以内」である場合、予想アクセス時刻として「９：０５」が演算される。なお、アクセス時間区分「Ｎ／Ａ」を含むレコードについては、予想アクセス時刻は算出されない。図６に示す内容のユーザ追跡情報ＤＢ３６の各レコードについて演算された予想アクセス時刻が図７に示されている。予想アクセス時刻演算部７０が演算した各予想アクセス時刻は、予想アクセス率演算部７２に出力される。
【００５６】
予想アクセス率演算部７２は、予想アクセス時刻演算部７０が演算した予想アクセス時刻、及びユーザ追跡情報ＤＢ３６に基づいて、ユーザＩＤと、過去送信時刻と、予想アクセス時刻との組毎に、当該過去送信時刻に通知メールが送信された場合に、当該予想アクセス時刻に当該ユーザがサーバ１４にアクセスする期待値である予想アクセス率を演算する。
【００５７】
図７を参照しながら予想アクセス率演算部７２の処理を説明する。図７においてユーザ「ａａａ」に着目すると、ユーザ「ａａａ」に関する３つのレコードはいずれも過去送信時刻が「９：００」であり、そのうち２の予想アクセス時刻が「９：０５」となっている。そのため、通知メールを「９：００」に送信した場合、ユーザ「ａａａ」は３分の２の割合で「９：０５」にサーバ１４にアクセスしてくると判断できる。したがって、予想アクセス率演算部７２は、ユーザＩＤ「ａａａ」、過去送信時刻「９：００」、予想アクセス時刻「９：０５」の組に対する予想アクセス率として「０．６７」を演算する。０．６７は６７％、つまり３分の２の割合を意味するものである。
【００５８】
ユーザ「ａａａ」に関する残り１つのレコードはアクセス時間区分が「Ｎ／Ａ」となっているため予想アクセス時刻が演算されていない。したがって、予想アクセス率演算部７２は、当該レコードに対応する予想アクセス率は算出しない。
【００５９】
さらに、図７においてユーザ「ｂｂｂ」に着目すると、ユーザ「ｂｂｂ」に関するレコードは２つあるが、２つのレコードの過去送信時刻が互いに異なっている。そのため、通知メールを「９：００」に送信した場合、ユーザ「ｂｂｂ」は１００％の割合で「９：０５」にサーバ１４にアクセスしてくると判断でき、また、通知メールを「９：３０」に送信した場合、ユーザ「ｂｂｂ」は１００％の割合で「９：３５」にサーバ１４にアクセスしてくると判断できる。したがって、予想アクセス率演算部７２は、ユーザＩＤ「ｂｂｂ」、過去送信時刻「９：００」、予想アクセス時刻「９：０５」の組、及び、ユーザＩＤ「ｂｂｂ」、過去送信時刻「９：３０」、予想アクセス時刻「９：３５」の組に対する予想アクセス率としては、それぞれ「１（１００％を意味する）」を演算する。
【００６０】
予想アクセス率演算部７２は、ユーザＩＤ、過去送信時刻、及び予想アクセス時刻の組と、当該組に対する予想アクセス率を関連付けて、送信時刻設定部５０へ出力する。送信時刻設定部５０に出力される情報の内容が図８に示されている。なお、ユーザＤＢ３２に含まれていて、ユーザ追跡情報ＤＢ３６にアクセス時間が記憶されていないユーザがいる場合は、当該ユーザに対しては、予想アクセス率演算部７２の演算結果に含まれる過去送信時刻と予想アクセス時刻との各組に対して、各組に対する他のユーザの平均的な予想アクセス率を関連付ける。
【００６１】
第２実施形態における送信時刻設定部５０は、予想アクセス率演算部７２の演算結果に基づいて送信時刻更新処理を行う。詳しくは、送信時刻設定部５０は、予め定義された複数の単位時間に対して、予想アクセス率演算部７２の演算結果において各ユーザに関連付けられた予想アクセス時刻（図８参照）に基づいて、各ユーザを割り当てる。具体的には、一のユーザに関連する複数の予想アクセス時刻から一の予想アクセス時刻を選択して、選択された予想アクセス時間に基づいて当該ユーザを単位時間に割り当てる。送信時刻設定部５０は、その割り当て処理に当たって、各単位時間における、割り当てられた各ユーザに関連付けられた予想アクセス率の和が平滑化されるように各単位時間に各ユーザを割り当てる。送信時刻設定部５０は、各ユーザについて予想アクセス時刻を適切に選択することにより、各単位時間における予想アクセス率の和を平滑化させる。送信時刻更新処理の詳細については後述する。
【００６２】
以下、図５を参照しつつ、図９のフローチャートに沿って、第２実施形態における送信時刻更新処理の流れについて説明する。なお、図９のフローチャートの開始時において、メール設定ＤＢ３４には、送信開始時刻として「９：００」、送信終了時刻として「１１：００」、単位時間情報として「３０分」が記憶されているとする。また、ユーザ追跡情報ＤＢ３６には、図６に示す内容が記憶されているとする。
【００６３】
ステップＳ２０において、予想アクセス時刻演算部７０は、ユーザ追跡情報ＤＢ３６に基づいて、ユーザ追跡情報ＤＢ３６に含まれる各レコードについての予想アクセス時刻を演算する。予想アクセス時刻演算部７０の処理の詳細は上述の通りであり、その結果が図７に示されている。さらに、予想アクセス率演算部７２は、ユーザ追跡情報ＤＢ３６及び予想アクセス時刻演算部７０が演算した予想アクセス時刻に基づいて、ユーザＩＤ、過去送信時刻、及び予想アクセス時刻の組毎に予想アクセス率を演算する。予想アクセス率演算部７２の処理の詳細は上述の通りであり、その結果が図８に示されている。
【００６４】
ステップＳ２２において、送信時刻設定部５０は、メール設定ＤＢ３４に基づいて、複数の単位時間を設定する。ここでは、「９：００〜９：３０」、「９：３０〜１０：００」、及び「１０：００〜１０：３０」、及び「１０：３０〜１１：００」の４つの単位時間が設定される。
【００６５】
ステップＳ２４以後、送信時刻設定部５０は、図８に示す予想アクセス率演算部７２の演算結果においてユーザに関連付けられた予想アクセス時刻に基づいて、ユーザと、過去送信時間と、予想アクセス時刻との組（以下「ユーザ組」と記載する）をいずれかの単位時間に割り当てる処理を行う。まず、ステップＳ２４において、送信時刻設定部５０は、予想アクセス率演算部７２の演算結果において、予想アクセス率が１つしか演算されていないユーザに関するユーザ組の割り当て先を決定する。図８を参照するに、ここで割り当て先が決定されるユーザはユーザ「ａａａ」及びユーザ「ｅｅｅ」である。これらのユーザに関するユーザ組の割り当て先は、当該ユーザ組に含まれる予想アクセス時刻によって決定される。詳しくは、予想アクセス時刻を含む単位時間が割り当て先となる。したがって、ユーザＩＤ「ａａａ」及び予想アクセス時刻「９：０５」を含むユーザ組は、単位時間「９：００〜９：３０」に割り当てられる。同様に、ユーザＩＤ「ｅｅｅ」及び予想アクセス時間「１０：００」を含むユーザ組は、単位時間「９：３０〜１０：００」に割り当てられる。
【００６６】
ステップＳ２６において、送信時刻設定部５０は、全てのユーザ組を各単位時間に一旦割り当てる。例えば、ユーザ「ｂｂｂ」に関しては、ユーザＩＤ「ｂｂｂ」及び予想アクセス時刻「９：０５」を含むユーザ組と、ユーザＩＤ「ｂｂｂ」及び予想アクセス時刻「９：３５」を含むユーザ組の２つのユーザ組が存在する。したがって、ユーザ「ｂｂｂ」に関する２つのユーザ組は、一旦、単位時間「９：００〜９：３０」と「９：３０〜１０：００」の両方に割り当てられる。他のユーザに関するユーザ組についても同様である。このような割り当て処理を行った結果が図１０に示されている。図１０には、各単位時間に割り当てられたユーザ組と、各ユーザ組に対する予想アクセス率が示されている。なお、図１０（及び後述の図１１、図１２）において着色されているユーザ組は、その割り当て先が決定したユーザ組である。
【００６７】
ステップＳ２８において、送信時刻設定部５０は、単位時間毎に、割り当てられた各ユーザ組の予想アクセス率を合計して予想アクセス率和を演算する。例えば、図１０において単位時間「９：００〜９：３０」についてみると、ユーザＩＤ「ａａａ」及び予想アクセス時刻「９：０５」を含むユーザ組の予想アクセス率「０．６７」、ユーザＩＤ「ｂｂｂ」及び予想アクセス時刻「９：０５」を含むユーザ組の予想アクセス率「１」、ユーザＩＤ「ｃｃｃ」及び予想アクセス時刻「９：０５」を含むユーザ組の予想アクセス率「１」、及び、ユーザＩＤ「ｄｄｄ」及び予想アクセス時刻「９：０５」を含むユーザ組の予想アクセス率「１」を合計し、単位時間「９：００〜９：３０」に対する予想アクセス率和「３．６７」を演算する。他の単位時間についても同様に予想アクセス率和を演算する。
【００６８】
ここで、予想アクセス率和とは、各単位時間にアクセスすると期待されるユーザの人数を示すものとなる。例えば、図１０の例においては（この時点では１人のユーザが複数の単位時間に割り当てられてしまってはいるが）、単位時間「９：００〜９：３０」には３．６７人のユーザがアクセスすると期待され、単位時間「９：３０〜１０：００」には４人のユーザがアクセスすると期待され、単位時間「１０：００〜１０：３０」には１人のユーザがアクセスすると期待され、単位時間「１０：３０〜１１：００」には１人のユーザがアクセスすると期待されることが示されている。つまり、各単位時間における予想アクセス率和を平滑化することが、複数のユーザからのアクセスを時間方向に分散することになる。
【００６９】
ステップＳ３０において、送信時刻設定部５０は、予想アクセス率和が予想アクセス率閾値以下である単位時間に割り当てられたユーザ組の割り当て先を当該単位時間に決定する。予想アクセス率閾値は、記憶部３０（例えばメール設定ＤＢ３４など）に記憶されていてよい。予想アクセス率閾値は、例えば、予想アクセス率演算部７２が演算した各ユーザの予想アクセス率の合計を単位時間の数で割った値に基づいて決定される。あるいは、ユーザ追跡情報ＤＢ３６に記憶された単位時間におけるサーバ１４の処理能力に応じて、情報提供システム１０の管理者などによって予め設定されてもよい。ここでは、予想アクセス率閾値が「２」に設定されているとする。図１０を参照して、予想アクセス率和が予想アクセス率閾値「２」以下であるのは、単位時間「１０：００〜１０：３０」及び単位時間「１０：３０〜１１：００」である。したがって、送信時刻設定部５０は、単位時間「１０：００〜１０：３０」に割り当てられたユーザ組の割り当て先を当該単位時間に決定し、単位時間「１０：３０〜１１：００」に割り当てられたユーザ組の割り当て先を当該単位時間に決定する。これにより、ユーザ「ｄｄｄ」及び「ｆｆｆ」の割り当て先が決定される。
【００７０】
図１１に、ステップＳ３０の処理後における各単位時間に対する各ユーザ組の割り当て状態が示されている。上述の通り、ユーザＩＤ「ｄｄｄ」及び予想アクセス時刻「１０：０５」を含むユーザ組、及び、ユーザＩＤ「ｆｆｆ」及び予想アクセス時刻「１１：００」を含むユーザ組の割り当て先が決定されている。それに伴い、単位時間「１０：００〜１０：３０」以外の単位時間に割り当てられていたユーザＩＤ「ｄｄｄ」を含むユーザ組が削除される。同様に、単位時間「１０：３０〜１１：００」以外の単位時間に割り当てられていたユーザＩＤ「ｆｆｆ」を含むユーザ組が削除される。以上のように、１人のユーザに関する複数のユーザ組から１のユーザ組が選択され、選択されたユーザ組に含まれる予想アクセス時刻に基づいて、当該ユーザの割り当て先が決定される。
【００７１】
その後、送信時刻設定部５０は、各単位時間における予想アクセス率和を再演算する。再演算により、単位時間「９：００〜９：３０」の予想アクセス率和が「２．６７」となり、単位時間「９：３０〜１０：００」の予想アクセス率和が「２．５」となる。再演算の結果、予想アクセス率和が予想アクセス率閾値「２」以下となった場合は、その単位時間に割り当てられたユーザ組の割り当て先を決定する。
【００７２】
ステップＳ３２において、送信時刻設定部５０は、割り当て先が決定していないユーザ組が残っているか否かを判定する。すなわち、予想アクセス率和が予想アクセス率閾値以下となっていない単位時間が残っているか否かを判定する。ここでは、再演算の結果、単位時間「９：００〜９：３０」及び「９：３０〜１０：００」の予想アクセス率和がいずれも予想アクセス率閾値「２」より大きいため、ステップＳ３４に進む。割り当て先が決定していないユーザ組が残っていない場合、後述のステップＳ３８に進む。
【００７３】
ステップＳ３４において、送信時刻設定部５０は、未だに割り当て先が決定していないユーザ組の各単位時間への割り当てを解除する。ここでは、単位時間「９：００〜９：３０」に割り当てられた、ユーザＩＤ「ｂｂｂ」及び予想アクセス時刻「９：０５」を含むユーザ組、及び、ユーザＩＤ「ｃｃｃ」及び予想アクセス時刻「９：０５」を含むユーザ組の割り当てを解除する。その結果、単位時間「９：００〜９：３０」の予想アクセス率和が「０．６７」となる。同様に、単位時間「９：３０〜１０：００」に割り当てられた、ユーザＩＤ「ｂｂｂ」及び予想アクセス時刻「９：３５」を含むユーザ組、及び、ユーザ「ｃｃｃ」及び予想アクセス時刻「９：３５」を含むユーザ組の割り当てを解除する。その結果、単位時間「９：３０〜１０：００」の予想アクセス率和が「１」となる。
【００７４】
ステップＳ３６において、送信時刻設定部５０は、残ユーザ組に対応する残ユーザを予想アクセス率和がより小さい単位時間に順次割り当てていく処理を行う。なお、残ユーザの割り当て先候補は、残ユーザに対応する残ユーザ組に含まれる予想アクセス時刻に応じて決定される。例えば、残ユーザであるユーザ「ｂｂｂ」に対応する２つのユーザ組は、予想アクセス時刻「９：０５」及び「９：３５」をそれぞれ含んでいるため、ユーザ「ｂｂｂ」の割り当て先候補は単位時間「９：００〜９：３０」及び「９：３０〜１０：００」となる。
【００７５】
送信時刻設定部５０は、まず、ユーザ「ｂｂｂ」の割り当て先を決定する処理を行う。この時点では、ユーザ「ｂｂｂ」の割り当て先候補である、単位時間「９：００〜９：３０」の予想アクセス率和は「０．６７」であり、単位時間「９：３０〜１０：００」の予想アクセス率和は「１」である。つまり、ユーザ「ｂｂｂ」の割り当て先候補のうち予想アクセス率和が一番小さい単位時間は「９：００〜９：３０」であるから、送信時刻設定部５０は、ユーザ「ｂｂｂ」を単位時間「９：００〜９：３０」に割り当てる。つまり、ユーザＩＤ「ｂｂｂ」及び予想アクセス時刻「９：０５」を含むユーザ組を単位時間「９：００〜９：３０」に割り当てる。その結果、単位時間「９：００〜９：３０」の予想アクセス率和は「１．６７」となる。
【００７６】
送信時刻設定部５０は、次に、ユーザ「ｃｃｃ」の割り当て先を決定する処理を行う。この時点では、ユーザ「ｃｃｃ」の割り当て先候補である、単位時間「９：００〜９：３０」の予想アクセス率和は「１．６７」であり、単位時間「９：３０〜１０：００」の予想アクセス率和は「１」である。つまり、ユーザ「ｃｃｃ」の割り当て先候補のうち予想アクセス率和が一番小さい単位時間は「９：３０〜１０：００」であるから、送信時刻設定部５０は、ユーザ「ｃｃｃ」を単位時間「９：３０〜１０：００」に割り当てる。つまり、ユーザＩＤ「ｃｃｃ」及び予想アクセス時刻「９：３５」を含むユーザ組を単位時間「９：３０〜１０：００」に割り当てる。その結果、単位時間「９：３０〜１０：００」の予想アクセス率和は「１．５」となる。
【００７７】
ステップＳ３６の処理により、全ユーザの割り当て先が決定する。図１２にステップＳ３６の処理が終了したときの各単位時間への各ユーザへの割り当て状態が示されている。図１２に示す通り、送信時刻更新処理により、各単位時間の予想アクセス率和が平滑化されている。
【００７８】
ステップＳ３８において、送信時刻設定部５０は、各単位時間への各ユーザ組の割り当てに基づいて、各ユーザの更新送信時刻を決定する。具体的には、各単位時間に割り当てられたユーザ組に含まれる過去送信時間を、当該ユーザ組に含まれるユーザＩＤが示すユーザの更新送信時間として決定する。図１２の例においては、ユーザ「ａａａ」、「ｂｂｂ」、及び「ｅｅｅ」の更新送信時刻は「９：００」に設定され、ユーザ「ｃｃｃ」の更新送信時刻は「９：３０」に設定され、ユーザ「ｄｄｄ」及び「ｆｆｆ」の更新送信時刻は「１０：００」に設定される。
【００７９】
第２実施形態の送信時刻更新処理によれば、各ユーザに対する複数の過去送信時刻とアクセス時間に基づいて、各過去送信時刻に対する予想アクセス時刻が演算される。さらに、ユーザ組毎に予想アクセス率が演算され、各単位時間における予想アクセス率和が平滑化されるように、各ユーザの更新送信時刻が決定される。このような処理により、少なくとも第１実施形態に比して、通知メールに対する複数のユーザのサーバ１４へのアクセスをより確実に時間方向に分散させることができる。
【００８０】
各単位時間の予想アクセス率和が平滑化されるように、各単位時間に各ユーザ組を割り当てる方法としては、図９のフローチャートが示す方法に限られない。例えば、各単位時間への各ユーザ組を各単位時間へ割り当てる場合に考えられる全ての組み合わせについて、単位時間毎に予想アクセス率和を演算して、各単位時間における予想アクセス率和が最も均等となる組み合わせを選択する方法（総当たり法）を採用してもよい。
【００８１】
第２実施形態においても、各ユーザの通知メールの送信時刻を、現時点からできるだけ近い過去、望ましくは前回における送信時刻と同じ時刻にしたいという要求がある。このような要求に応えるために、予想アクセス率演算部７２は、予想アクセス率の演算処理において、あるユーザについて、現時点により近い時点で取得された過去送信時刻に対応する予想アクセス時刻を相対的に低く演算するようにしてもよい。
【００８２】
例えば、図６においてユーザ「ｂｂｂ」に着目すると、２日前において過去送信時刻「９：００」とアクセス時間区分「５分以内」の組が取得され、１日前において過去送信時刻「９：３０」とアクセス時間区分「５分以内」の組が取得されている。上述の第２実施形態では、図８を参照するに、ユーザ「ｂｂｂ」、過去送信時刻「９：００」、予想アクセス時刻「９：０５」の組（以下「２日前組」と記載する）と、ユーザ「ｂｂｂ」、過去送信時刻「９：３０」、予想アクセス時刻「９：３５」の組（以下「前日組」と記載する）とでは、共に予想アクセス率「１」が演算されているが、予想アクセス率演算部７２は、前日組の予想アクセス率を２日前組の予想アクセス率よりも低く演算してもよい。例えば、前日組の予想アクセス率を「０．８」としてよく、又は、２日前組の予想アクセス率を「１．２」としてもよい。あるいは、前日組の予想アクセス率を「０．８」にすると共に２日前組の予想アクセス率を「１．２」としてもよい。このようにすることで、現時点により近い時点で取得された過去送信時刻と予想アクセス時刻とを含む組が、単位時間に割り当てられる割り当て組として選択され易くすることができる。つまり、現時点により近い時点で取得された過去送信時刻が更新送信時刻として設定され易くすることができる。
【００８３】
以上、本発明に係る実施形態を説明したが、本発明は上記実施形態に限られるものではなく、本発明の趣旨を逸脱しない限りにおいて種々の変更が可能である。
【００８４】
例えば、上述の実施形態においては、催促通知として通知メールを用いていたが、催促通知としては、例えば特定のユーザにのみ閲覧可能であり、ユーザがクリックすることでサーバ１４にアクセスするような広告などであってよい。
【符号の説明】
【００８５】
１０，６０  情報提供システム、１２  ユーザ端末、１４  サーバ、２０  通信部、３０  記憶部、３２  ユーザＤＢ、３４  メール設定ＤＢ、３６  ユーザ追跡情報ＤＢ、４０  制御部、４２  メール生成部、４４  送信時刻取得部、４６  アクセス情報取得部、４８  ユーザ追跡情報生成部、５０  送信時刻設定部、７０  予想アクセス時刻演算部、７２  予想アクセス率演算部。
【図１】
2018041298.tif 000003
【図２】
2018041298.tif 000004
【図３】
2018041298.tif 000005
【図４】
2018041298.tif 000006
【図５】
2018041298.tif 000007
【図６】
2018041298.tif 000008
【図７】
2018041298.tif 000009
【図８】
2018041298.tif 000010
【図９】
2018041298.tif 000011
【図１０】
2018041298.tif 000012
【図１１】
2018041298.tif 000013
【図１２】
2018041298.tif 000014