JP2004102853A

JP2004102853A - 情報配信方法とシステム

Info

Publication number: JP2004102853A
Application number: JP2002266207A
Authority: JP
Inventors: Kenji Baba; 馬場　健治; Chizuko Yasunobu; 安信　千津子; Haruko Yakabe; 矢加部　晴子; Kikuo Endo; 遠藤　紀久雄
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2002-09-12
Filing date: 2002-09-12
Publication date: 2004-04-02

Abstract

【課題】本発明の課題は、時間を分散して情報を配信する際に、配信する情報の内容をより早く得たいと考えているユーザから順に情報を配信し、これによって、ユーザのニーズを満足することである。
【解決手段】アクセス管理部１４が、情報を配信した時刻とアクセスを受信した時刻をもとに、メール配信部１１が情報を配信してから、アドレス情報によって特定されたアクセス先がユーザからのアクセスを受信するまでの応答時間を計算し、配信計画作成部１２が、応答時間をもとに、情報を配信すべきユーザの配信順序を決定し、メール配信部１１が、決定された配信順序に従って、ユーザへメールを配信する。
【選択図】　図１

Description

【０００１】
【発明の属する技術分野】
本発明は、提供しているサービスへのアクセスを促すために情報を配信するシステム及び方法に係り、特に、インターネットを用いた情報提供サービスにおいて、顧客満足度の低下を抑えつつ情報提供サーバの負荷を軽減するのに好適な情報配信システム及び方法に関する。
【０００２】
【従来の技術】
近年、インターネット上では情報提供や商品販売などを行う、ＷＷＷサーバを用いたサイトが数多く存在している。しかし、ただサイトを公開しただけではユーザのアクセスは期待できないため、多くのサイトでは、新しい機能やコンテンツの追加などの情報をメールで配信することにより、ユーザからのサイトへのアクセスを促すよう試みている。ユーザは、メールの本文にあるＵＲＬをクリックしたり、ＷＷＷブラウザに入力したりすることなどで、興味のあるコンテンツに容易にたどり着けるようになっている。
【０００３】
しかし、メールによってユーザのアクセスを促す場合、一度に多くのユーザに対してメールを配信すると、それだけ多くのユーザが短い時間の間に集中してサイトにアクセスすることになり、ユーザへのレスポンスが遅くなったり、接続することが出来なくなったりする場合がある。このため、時間を分散してメールを配信するということが行われている。
【０００４】
【特許文献１】
特開平０５−２１９１０６号公報
【０００５】
【発明が解決しようとする課題】
従来技術では、時間を分散してメールを配信する際に、各ユーザへ配信する順序についての配慮がされておらず、少しでも早く情報が欲しいと考えているユーザへのメール配信が後になることが考えられる。
【０００６】
本発明の目的は、時間を分散して情報を配信する際に、配信する情報の内容をより早く得たいと考えているユーザから順に情報を配信し、これによって、ユーザのニーズを満足する方法及びシステムを提供することである。
【０００７】
本発明の他の目的は、配信する情報に興味がないと考えられるユーザに情報を配信しないことによって、ユーザの情報の閲覧負担及び情報配信サーバの配信負荷を軽減する方法及びシステムを提供することである。
【０００８】
本発明の他の目的は、予想されるアクセス負荷に耐え且つオーバースペックとならない適切なアクセス先サーバを提案できる方法及びシステムを提供することである。
【０００９】
本発明の他の目的は、アクセス先サーバのアクセス負荷が限界を超えない範囲で、ユーザのアクセスを短時間に集中させ、アクセス先サーバの効率を向上する方法及びシステムを提供することである。
【００１０】
【課題を解決するための手段】
上記目的を達成するために、本発明は、情報を送信してからアクセス先のサーバにアクセスがあるまでの時間を応答時間と定義し、その時間を計測して、その時間が短いユーザから順に情報を配信することとした。これにより、一定の順序以下のユーザに情報を配信しないことも可能となる。
【００１１】
また、応答時間に加え、応答がある確率と、応答があってからユーザの処理が終了するまでの時間を計測することで、どのユーザが、どの時間にどの程度の確率でアクセスし、アクセス後どのくらいの時間滞在するかが予測し、これを用いてシミュレーションを行う。このシミュレーションにより、アクセス先のサーバの最大の負荷がどのくらいかを見積もることが出来る。
【００１２】
さらに、シミュレーション時に、アクセス先のサーバの負荷がばらついている場合は、ユーザへの配信順序を変更して負荷のばらつきを平滑化することができる。アクセス先のサーバの限界負荷付近で平滑化すれば、最短時間で全員に情報を配信するためのスケジュールが出来ることになる。
【００１３】
【発明の実施の形態】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。
【００１４】
まず、図１に示すシステムの全体構成図について説明する。
【００１５】
本実施形態では、情報提供や商品販売を行うサービス提供サーバ１と、メール登録クライアント４１と、ユーザ用クライアント２１、２２、２３が通信ネットワーク３で接続されている。ここではサーバが１台、クライアントが４台の構成であるが、より台数を増やして実施することも可能である。通信ネットワーク３は、ＬＡＮ、インターネット、他の任意の有線又は無線を使ったネットワークを利用することができる。
【００１６】
サービス提供サーバ１の構成を以下に説明する。
【００１７】
サービス提供部１３は、各クライアントからの要求に対し情報提供や商品販売などのサービス提供を行う。ここでは、情報提供や商品販売を行うインターネットを介したＷＷＷサーバ機能を考える。
【００１８】
メール内容登録部１５は、ユーザに配信するメールの内容の登録を受け付け、記憶装置１７にその内容を格納する。
【００１９】
配信計画作成部１２は、記憶装置１７に格納されている、ユーザのメールアドレス等の情報と、アクセス分析部１６によって分析された結果に基づいて、メールの配信計画を立てる。
【００２０】
メール配信部１１は、配信計画作成部１２により作成された配信計画に基づき、ユーザにメールを配信する。
【００２１】
アクセス管理部１４は、クライアントがサービス提供サーバ１にアクセスした際に、アクセスしたユーザのユーザＩＤやアクセスしたコンテンツの分類等を取得し記憶装置１７に格納する。
【００２２】
アクセス分析部１６は、記憶装置１７に格納された、アクセス管理部１４が取得した情報や、アクセス分析部１６自身の過去の分析結果から、新たに情報を分析し、配信計画作成部１２が配信計画を立てるために必要な情報を作成して、記憶装置１７に格納する。
【００２３】
次に、本実施形態における処理手順を図２のフローチャートに従って説明する。
【００２４】
まず、サービス提供サーバ１の運営者や提携機関等が、ユーザに配信するメールを登録する（ステップ１０１）。メールの登録は、メール登録クライアント４１がメール内容登録部１５にアクセスし、ＷＷＷブラウザ上に表示された登録画面に入力したり、専用フォーマットのフォームに入力したものを送信したりすることにより行う。勿論、サービス提供サーバ１上の画面から直接入力したり、記憶媒体に保存したデータをコピーしたりするなどの方法でもよい。
【００２５】
ここで登録されるメールは、メールの本文に加え、サービス提供部１３が提供するサービスのうち特定の部分を指し示すリンクが含まれている。例えば、「ｈｔｔｐ：／／ｗｗｗ．ａａａ．ｃｏ．ｊｐ／ｃａｒ／ｘ．ｈｔｍｌ」といった、ＷＷＷサーバ上のコンテンツの場所（アドレス）を指すＵＲＬ等である。ＷＷＷサーバは、このＵＲＬによって特定された場所からコンテンツを含むファイルを出力する。
【００２６】
メールを登録する際には、メールの本文、ＵＲＬ等のリンク、それぞれのＵＲＬ等のリンクが指し示すコンテンツのコンテンツ分類を入力する。コンテンツ分類とは、「車」「金融」「スポーツ」などのコンテンツの内容を示す分類である。コンテンツ分類は、あらかじめ決めておいてメール登録時に選択することにしても良いし、メール登録時に自由に設定することにしても良い。どちらの場合でも、コンテンツ分類は記憶装置１７に保管しておく。
【００２７】
例えば、カー用品、資産管理ツール、外貨預金の３種のコンテンツにリンクしているメールを登録した場合は、コンテンツ分類は「車」と「金融」であり、図３のテーブル１７０１に示すように、メール固有の番号、メールの本文、メールに含まれるリンクが指し示すコンテンツの分類が記憶装置１７に格納される。さらに、図４のテーブル１７０２のように、メールに含まれるリンクと、それぞれのリンクに対応するコンテンツの分類も、メール内容の固有番号と対応づけて記憶装置１７に格納する。
【００２８】
配信計画作成部１２は、メールの配信順序を決定する（ステップ１０２）。その詳細な手順を図５のフローチャートに従って説明する。
【００２９】
まず、配信計画作成部１２は、記憶装置１７から図３のテーブル１７０１に示す配信予定メールの内容及びコンテンツ分類を取得する（ステップ１３０１）。また、記憶装置１７から図６のテーブル１７０３に示す、ユーザとコンテンツ分類ごとの平均応答時間の情報を取得する（ステップ１３０２）。ここで平均応答時間とは、メールをユーザに配信してから、ユーザがそのメールに記述した情報をもとにサービス提供サーバ１のサービス提供部１３にアクセスするまでにかかった時間の平均を示す。平均応答時間の詳細は後述する。単位は任意であるが、ここでは「分」を使う。テーブル１７０３は、配信計画作成部が、過去に配信したメールに対する反応時間を集計して作成し、新たにメールを配信するごとに新しくデータを更新する。
【００３０】
ステップ１３０２で得たテーブル１７０３の情報から、ステップ１３０１で得た配信予定メールのコンテンツ分類である、「車」と「金融」についての情報のみを抜き出す。抜き出した情報から、ユーザ毎に最も平均応答時間が短いものを選んで、最低平均応答時間とする（ステップ１３０３）。すなわち、図７のテーブル１７０４に示すとおり、ユーザＩＤが００１のユーザは、コンテンツ分類が「車」の場合平均応答時間が３で、「金融」の場合が８３０であるため、最低平均応答時間は、小さい方の３とする。同様にして、ユーザＩＤが００２のユーザは２２１、ユーザＩＤが００３のユーザは３７という値が最低平均応答時間となる。最低の値を利用するのは、メールを配信後最初のアクセスを予測するために利用するためである。これらの最低平均応答時間の短い順にユーザを並べ替える（ステップ１３０４）。最後に、記憶装置１７に格納されている図８のテーブル１７０５に示すユーザごとのメールアドレスと、ステップ１３０４でソートしたユーザＩＤを合わせ、図９に示すように最低平均応答時間でソートした形態でテーブル１７０６を作成し、メール配信部１１に渡す（ステップ１３０５）。
【００３１】
図２のフローチャートに戻って説明を継続する。
【００３２】
メール配信部１１は、配信計画作成部１２が作成したテーブル１７０６に従い、最低平均応答時間の短い順にメールを配信する（ステップ１０３）。
【００３３】
メールの配信は、メールを分散して配信する。１通ずつ送付しても良いし、複数のメールを同時に送ることを繰り返しても良い。ただし、最低平均応答時間の短い順にメールを配信するため、初めの方で配信したユーザは早くサービス提供サーバ１にアクセスし、後の方で配信したユーザは遅くサービス提供サーバ１にアクセスする可能性が高い。従って、従来技術のように、一度に送るメール数と、メールを配信する間隔とを同じにすると、ユーザからのサービス提供サーバ１へのアクセスは最初の方に多く集まってしまう。そのため、サービス提供部１３の能力を無駄なく利用するためには、初めの方では一度に配信するメール数を抑えるかメールの配信間隔を長めにし、後の方になるほど一度に配信するメール数を増やすかメールの配信間隔を短くすることによって、負荷を平滑化するのがよい。他の方法としては、サービス提供部１３の負荷状況により、メールの配信間隔をリアルタイムで決定することも考えられる。例えば、サービス提供部１３が対応できる能力の５０％など一定の値を下回ったら次のメールを送付することとするなどである。サービス提供部１３が対応できる能力とは、ＣＰＵ利用率や最大セッション数に対する占有されたセッション数の割合などが考えられる。
【００３４】
メールを受け取ったユーザは、メールに記述されているＵＲＬをクリック（指定）するなどの方法で、サービス提供サーバ１にアクセスする（ステップ１０４）。そのアクセスはサービス提供部１３が受け、適切なコンテンツを表示したり、サービスを提供したりする（ステップ１０５）。
【００３５】
アクセス管理部１４は、アクセスしてきたユーザのユーザＩＤと、配信したメールのどのＵＲＬをクリックしてアクセスしてきたかを入手する（ステップ１０６）。以下、図１０に示すフローチャートを用いてアクセス管理部１４の動作を詳細に説明する。
【００３６】
アクセス管理部１４は、ユーザが行うログイン処理や、ＵＲＬにユーザ固有の文字列を設定しておくなどの方法によりユーザＩＤを取得する（ステップ１４０１）。ＵＲＬとコンテンツ分類の対応は、図４のテーブル１７０２に示すようにメール内容登録部１５によって記憶装置１７に格納されているので、この情報を利用してユーザがどのコンテンツ分類の情報を求めてきたのかを取得する（ステップ１４０２）。また、ユーザがサービス提供部１３にアクセスした時刻（Ａ）と、メールを配信した時刻（Ｂ）を取得する（ステップ１４０３、ステップ１４０４）。（Ｂ）と（Ａ）の時間差を計算し、その結果をユーザの応答時間とする。応答時間、ユーザＩＤ、コンテンツ分類は、図１１に示すテーブル１７０８のように、記憶装置１７に格納しておく（ステップ１４０５）。以上がアクセス管理部１４の動作である。
【００３７】
ここで、メールを配信した時刻（Ｂ）は、ユーザがメールの存在に気づいた時刻とする方が、より正確にユーザの応答時間を計測できる。ユーザがメールサーバからメールをダウンロードした時刻や、ユーザがメールを開封した時刻が取得できる場合には、この時刻を利用しても良い。
【００３８】
図２のフローチャートに戻り、説明を継続する。
【００３９】
アクセス分析部１６は、図１１に示すテーブル１７０８の情報を分析し、ステップ１０２で配信計画作成部が利用した図６に示すテーブル１７０３を最新の状態に更新する。テーブル１７０３は、テーブル１７０８の入力によって、図１２に示すテーブル１７０９のように変更される。
【００４０】
例を挙げて具体的に説明する。テーブル１７０３において、ユーザＩＤ００１のユーザは、コンテンツ分類が「車」の平均応答時間が３であった。今回のメール送付では、テーブル１７０８の２行目が示すようにユーザＩＤ００１のユーザはコンテンツ分類が「車」のコンテンツへの応答時間が１２となっている。記憶装置１７には、過去のメールに対する応答時間の全ての履歴、もしくはコンテンツ分類ごとに過去のメールの件数が保管されている。従って、今回の応答時間１２を加えることによって平均応答時間が５と計算され、テーブル１７０９のようになった。また、ユーザＩＤ００３のユーザは、コンテンツ分類が「車」のコンテンツにアクセスしなかった。この場合、例えば上限を１０００と決めて計算する。本実施形態では、平均応答時間は５４が８３に増えている。更新されたテーブル１７０９は、次にメールを配信する際に利用される。
【００４１】
以上により、メールを分散して配信する際、メールの内容にある情報をより早く必要としていると考えられるユーザに対して、早くメールを送信することができる。
【００４２】
以上の実施形態ではユーザにメールを配信したが、メールの代わりに、インスタントメッセージングのような、サーバを経由せずに直接相手のクライアントに対して情報を配信する方法を利用しても良い。また、ダイレクトメール等の郵送によってＵＲＬを通知することも考えられる。郵送の際には、地域によって配送時間にばらつきがあるため、遠隔地や離島のように配達に時間がかかる地域と、すぐに届く近接地区との違いなどを考慮し、配信時刻を調整して応答時間を計算する必要がある。
【００４３】
また、以上の実施形態では、ユーザが早く情報を欲しがっているかどうかを知る指標として平均応答時間を利用しているが、平均応答時間の代わりに、ｎ分間以内にアクセスする確率（ｎは任意に決めた数値）等、一定時間内にアクセスした確率を利用しても良い。５分以内でアクセスしてくるユーザと１時間でアクセスしてくるユーザとの違いは大きいが、１日後と３日後では、その違いの意味は大きくないという考えに立てば、合理的な評価方法である。他にも、ｌｏｇ_１０Ｎ（Ｎは応答時間）等のように対数を利用することにより短い時間を重視した指標に変換することなども考えられる。
【００４４】
さらに、以上の実施形態では、コンテンツ分類を、車、金融、スポーツなどといった分野で分けているが、同じ分野でも早く知りたい場合とそうでない場合がある。例えば、スポーツでは、野球は見たいがサッカーは見たくないといった場合がある。これは、コンテンツ分類をより細分化することで対応できる。ただ、コンテンツ分類を細分化すると、各コンテンツ分類における応答時間のサンプルが少なくなるので、信頼性が低くなる場合がある。この場合、コンテンツ分類は階層化しておき、最下層から平均応答時間などの指標を確認し、そのサンプル数が少ない場合は一つ階層を上げたコンテンツ分類で確認することで対応できる。例えば、信頼性があるとみなす過去のサンプル数を５件と設定しておいた場合、配信するメールに含まれるＵＲＬが示すコンテンツ分類が「サッカー」で、コンテンツ分類が「サッカー」である過去のメールに対するサンプル数が２件だったとすると、信頼性がないとみなし、上位の階層である「スポーツ」で調べる。「スポーツ」の場合が１０件だとすると、信頼性があるとみなせるので、その値を利用する。
【００４５】
また、ただコンテンツ分類を細分化するだけではなく、同じコンテンツ分類でも情報の内容が異なることにより、早く見たいかどうかが決まる場合も考えられる。例えば、クレジットカードの利用明細といった情報の場合、通知対象となる月の請求金額が大きい場合や、過去の平均請求金額より通知対象となる月の請求金額が大幅に増加した場合はより早く確認したいと考えることが想定できる。こういう場合、請求対象金額、請求対象金額の増加率を平均応答時間などの指標に加味しても良い。例えば、平均応答時間を請求対象金額（単位万円）で割るなどが考えられる。また、請求対象額、請求対象額の増加率でコンテンツ分類を細分化すると言うことも考えられる。例えば、請求対象額１万円未満、５万円未満、１０万円未満、３０万円未満、３０万円以上などといったようにグループ化し、クレジットカード利用明細というコンテンツ分類をさらに細分化することが考えられる。
【００４６】
さらに、上記の実施の形態では、メールによる通知によってサービス提供サーバ１へアクセスを促す場合を考慮していたが、他の媒体にも応用できる。例えば、ハガキ、封書、電話などによってユーザに通知したり、ユーザからのアクセスを受けたりする場合に応用できる。具体的に例を挙げれば、ハガキによる通知によってコールセンタへのアクセスを促す場合などである。
【００４７】
また、情報を配信すべきユーザの順序が決まるので、一定の順序以下のユーザには配信しないことにより、メール配信や郵送によるコスト削減や興味のないユーザに配信することによるスパムメール化を防ぐことも考えられる。
【００４８】
上記の実施の形態では、早く情報を得たいと考えているであろうユーザに対してより早く情報提供することを目的に、平均応答時間が短いユーザから順に配信することを考えている。しかし、この目的を離れて自由に配信順序を決定することとすれば、平均応答時間の短いユーザと長いユーザに同時にメールを配信することにより、ＷＷＷサーバの負荷が限界を超えない範囲でユーザのアクセスを短期間に集中させることも考えられる。例えば、配信対象ユーザ全体を、平均応答時間の短いユーザと長いユーザをまんべんなく選んだいくつかのグループに分け、一定間隔でグループ毎にメールを配信することが考えられる。これにより、ユーザの応答時間の分布は、各グループで類似したものになると予想されるが、この分布は、一般的に山形になると考えられるので、これらの分布を重ね合わせたものである全体のアクセスは、高いレベルである程度平滑化されると考えられる。別の方法としては、平均応答時間が一定以上の（すなわちアクセスしてくるのが遅い）ユーザにまずメールを送り、送ったユーザの平均応答時間の分布が少ない時間帯に、平均応答時間が短いユーザに対してメールを送ることで、ユーザからサービス提供サーバ１へのアクセスを平滑化することも考えられる。これらの方法により、サービス提供サーバ１の性能を有効活用することができる。
【００４９】
以上に述べている実施の形態では、平均応答時間を利用することにより、メールを配信するべきユーザの順序を導き出したが、さらに、一定時間までに応答があった確率と、滞在時間を加えて利用すれば、ユーザのアクセスをシミュレーションすることができる。ここで滞在時間とは、ユーザがＷＷＷサーバにアクセスしてから、アクセスを終えるまでの時間とする。コールセンタの場合では、ユーザが電話をかけてから話し終えて受話器を下ろすまでの時間を滞在時間とする。ユーザのアクセスをシミュレーションすることにより、ＷＷＷサーバやコールセンタにかかる最大負荷の予測が算出できるので、事前にＷＷＷサーバの性能強化やコールセンタ人員の増加などの対策ができる。ユーザへのメール配信順序や配信間隔を変更しながらシミュレーションが出来るようにすれば、一定の負荷に抑えながら短時間で集中してメール配信するなどの計画が立てられる。
【００５０】
【発明の効果】
本発明によれば、時間を分散して情報を配信する際に、配信する情報の内容をより早く得たいと考えているユーザから順に情報を配信し、これによって、ユーザのニーズを満足するという効果を奏する。
【００５１】
本発明によれば、配信する情報に興味がないと考えられるユーザに情報を配信しないことによって、ユーザの情報の閲覧負担及び情報配信サーバの配信負荷を軽減するという効果を奏する。
【００５２】
本発明によれば、予想されるアクセス負荷に耐え且つオーバースペックとならない適切なアクセス先サーバを提案できるという効果を奏する。
【００５３】
本発明によれば、アクセス先サーバのアクセス負荷が限界を超えない範囲で、ユーザのアクセスを短時間に集中させ、アクセス先サーバの効率を向上するという効果を奏する。
【図面の簡単な説明】
【図１】本発明の実施形態を示すシステム構成図である。
【図２】本発明の実施形態における情報提供方法の全体処理フロー図である。
【図３】本発明の実施形態におけるメール内容を格納したテーブルである。
【図４】本発明の実施形態におけるコンテンツ分類とリンク先の対応テーブルである。
【図５】本発明の実施形態におけるメール配信計画作成部の処理フロー図である。
【図６】本発明の実施形態におけるユーザごとの平均応答時間を示すテーブルである。
【図７】本発明の実施形態におけるユーザごとの最低平均応答時間を示すテーブルである。
【図８】本発明の実施形態におけるユーザのメールアドレスを示すテーブルである。
【図９】本発明の実施形態におけるメール配信順序を示すテーブルである。
【図１０】本発明の実施形態におけるアクセス管理部の処理フロー図である。
【図１１】本発明の実施形態におけるユーザからのアクセスログを示すテーブルである。
【図１２】本発明の実施形態における更新されたユーザごとの平均応答時間を示すテーブルである。
【符号の説明】
１…サービス提供サーバ、１１…メール配信部、１２…配信計画作成部、１３…サービス提供部、１４…アクセス管理部、１５…メール内容登録部、１６…アクセス分析部、１７…記憶装置、２１…ユーザクライアント、２２…ユーザクライアント、２３…ユーザクライアント、３…ネットワーク、４１…メール登録クライアント

Claims

アドレス情報を含む情報を複数のユーザに配信する情報配信部と、
前記情報配信部が前記情報を配信した時刻と前記アドレス情報によって特定されたアクセス先が前記ユーザからのアクセスを受信した時刻を取得する時刻取得部と、
前記情報を配信した時刻と前記アクセスを受信した時刻をもとに、前記情報を配信すべきユーザの前記情報の配信順序を決定する配信計画部とを具備した情報配信システム。
請求項１の情報配信システムにおいて、
前記情報を配信した時刻と前記アクセスを受信した時刻をもとに、前記情報配信部が前記情報を配信してから、前記アドレス情報によって特定されたアクセス先が前記ユーザからのアクセスを受信するまでの応答時間を計算する応答時間計算部を具備し、
前記配信計画部は、前記応答時間が短いユーザほど前記情報を早く送るように、前記ユーザの配信順序を決定する情報配信システム。
コンピュータによる情報配信方法において、
前記コンピュータの情報配信部が、アドレス情報を含む情報を複数のユーザに配信し、
前記コンピュータの時刻取得部が、前記情報配信部が前記情報を配信した時刻と前記アドレス情報によって特定されたアクセス先が前記ユーザからのアクセスを受信した時刻を取得し、
前記コンピュータの配信計画部が、前記情報を配信した時刻と前記アクセスを受信した時刻をもとに、前記情報を配信すべきユーザの配信順序を決定する情報配信方法。
請求項３に記載の情報配信方法において、
前記コンピュータの応答時間計算部が、前記情報を配信した時刻と前記アクセスを受信した時刻をもとに、前記情報配信部が前記情報を配信してから、前記アドレス情報によって特定されたアクセス先が前記ユーザからのアクセスを受信するまでの応答時間を計算し、
前記配信計画部が、前記応答時間をもとに、前記情報を配信すべきユーザの配信順序を決定する情報配信方法。
請求項４に記載の情報配信方法において、
前記応答時間計算部が、前記アクセス先が提供するコンテンツの種類ごとに分類したコンテンツ分類ごとに、前記応答時間を計算し、
前記配信計画部が、前記コンテンツ分類ごとの前記応答時間をもとに、前記情報を配信すべきユーザの配信順序を決定する情報配信方法。
請求項５に記載の情報配信方法において、
前記コンテンツ分類は、階層化され、
前記応答時間計算部が、前記コンテンツ分類の階層ごとの前記応答時間を計算可能で、任意の階層の前記応答時間のサンプル数が予め定められたサンプル数以下又は未満の場合に前記任意の階層を上位側の階層へ移行し、前記任意の階層の前記応答時間のサンプル数が予め定められたサンプル数以上又は超えた場合の前記任意の階層の応答時間を計算し、
前記配信計画部が、前記任意の階層の前記応答時間のサンプル数が予め定められたサンプル数以上又は超えた場合の前記任意の階層の応答時間をもとに、前記情報を配信すべきユーザの配信順序を決定する情報配信方法。
請求項３に記載の情報配信方法において、
前記情報配信部が、予め定められた配信順序以下又は未満のユーザへの前記情報の配信を停止する情報配信方法。
請求項３に記載の情報配信方法において、
前記コンピュータの集計部が、前記情報を配信してから予め定められた時間以内に前記ユーザが前記アクセス先をアクセスするアクセス確率と、前記ユーザが前記アクセス先にアクセスを開始してから終了するまでのアクセス時間を集計し、
前記ユーザからのアクセスによる前記アクセス先の負荷を算出する情報配信方法。