JP4958225B2

JP4958225B2 - リクエスト受付方法およびシステム

Info

Publication number: JP4958225B2
Application number: JP2007207986A
Authority: JP
Inventors: 裕規古屋; 秀行小頭; 中村　　元
Original assignee: KDDI Corp
Current assignee: KDDI Corp
Priority date: 2007-08-09
Filing date: 2007-08-09
Publication date: 2012-06-20
Anticipated expiration: 2027-08-09
Also published as: JP2009043069A

Description

本発明は、ユーザ端末から送信されたアクセスパス要求を受け付けて、各ユーザ端末のサービス提供サーバへのアクセスタイミングを決定し、これを各ユーザ端末へのアクセスパスとして返信するリクエスト受付方法およびシステムに関する。

災害発生時の安否確認のためのリクエスト、あるいはTV番組やラジオ番組でヒットチャートを発表した直後に人気曲の配信を要求するリクエストなど、特定のイベントを契機とするリクエストメッセージは短時間に集中する傾向がある。これらの宛先でリクエストを受け付けるサーバでは、リクエスト数が処理能力を超過すると、超過分についてはサービスの提供が不可能となる。このことは、同サービスを利用するユーザの満足度を低下させると共に、たとえばリクエストが有料コンテンツの配信であれば、コンテンツ提供者にとっては販売機会の損失となる。

イベントを契機とするアクセスの集中は通常のアクセス量を遙かに凌駕し、瞬間的には、例えば１０倍から１００倍に達する場合もある。したがって、アクセス集中時のピーク時に合わせてサーバ容量を設計してしまうと、時間的に大半を占める通常時には大幅な過剰設備状態を招いてしまう。しかも、このようなアクセス集中は予測が難しいので、たとえ十分と予測される設備を用意できたとしても、その容量を上回るアクセスが集中する可能性を否定できない。

一方、２００３年１２月に東京・大阪・名古屋で地上デジタル放送が開始され、それ以後、他の地域でも放送が順次開始されると共に、移動体受信端末向けサービスなどが拡充されることになっている。地上デジタル放送で提供される通信放送連携サービスでは、番組内容を契機とした同時大量アクセスの発生が予見されており、上記で指摘した事象が今後ますます顕在化してくることが想定される。このような技術課題に対して、本発明の発明者等は様々な技術を提案し、以下の特許出願をした。

特許文献１には、通信放送連携双方向サービスにおいて、放送番組により提供された応答要求に対する視聴者からの応答情報の送信集中を防止すべく、視聴者が放送コンテンツを契機として、通信回線経由で短時間に集中的に情報を送受信する場合に、視聴者の通信トラヒックに遅延を付加して送出することにより、時間的な負荷分散を実現する技術が開示されている。付加される遅延量は、受付側のネットワークないしはサーバの負荷状態に応じて適応的に決定され、放送波により通知される。

特許文献２には、通信放送連携双方向サービスにおいて、視聴者が放送コンテンツを契機として、通信回線経由で短時間に集中的に情報を送受信する場合に、呼種（メール・Web・通話など）やユーザ種別（地域・料金体系など）に基づき、視聴者の通信トラヒックの発呼を規制する技術が開示されている。規制ポリシーは、受付側のネットワークないしはサーバの負荷状態に応じて適応的に決定され、放送波により通知される。

特許文献３には、アクセス集中により受付拒否されたリクエストメッセージの再アクセスを、新たなアクセス集中を生じさせることなく公平に受け付けて処理できるシステムが開示されている。ここでは、サービス提供サーバに多数のアクセスが集中すると、受け付けられないユーザに対して、現在混んでいる旨と、次回優先接続される時間帯が提示される。同ユーザが改めて優先接続時間帯にアクセスしてきた場合、このリクエストメッセージは他のリクエストメッセージよりも優先的に受け付けられる。
特開２００６−１０９２１８号公報特願２００６−１５３３３号特願２００６−３６９７９号

特許文献１では、各ユーザに許可される応答タイミングが、応答操作の検知後に一様乱数で決定される遅延時間の経過後なので、早く応答したユーザのメッセージが常に早く受け付けられるとは限らず、受付が公平に行われないという技術課題があった。

特許文献２では、一のユーザが発呼した際に受付側の負荷が大きいと受付を後回しにされる一方、その直後に他の一のユーザが発呼した際に受付側の負荷が解消していると、当該他の一のユーザの発呼が先に受け付けられてしまうので、受付が公平に行われないという技術課題があった。

特許文献３では、一のユーザがリクエストメッセージを送信した際に受付側の負荷が大きいと受付を後回しにされる一方、その直後に他の一のユーザがリクエストメッセージを送信した際に受付側の負荷が解消していると、当該他の一のユーザのリクエストメッセージが先に受け付けられてしまうので、受付が公平に行われないという技術課題があった。

このように、上記した従来技術はいずれも、ユーザ間のアクセス順序を守った受付が困難であり、早くアクセスしたユーザが遅くアクセスしたユーザよりも常に早く受け付けられるという公平な受付を実現できなかった。また、リクエストメッセージが過度に集中すると、リクエストメッセージの一部が破棄されてしまい、全てのリクエストメッセージを漏れなく受け付けることができなかった。

本発明の目的は、上記した従来技術の課題を解決し、リクエストのアクセスを漏れなく、かつ順序逆転なく公平に受け付けられるようにしたリクエスト受付方法およびシステムを提供することにある。

上記した目的を達成するために、本発明は、ユーザ端末から送信されたアクセスパス要求を受け付けて、各ユーザ端末のサービス提供サーバへのアクセスタイミングを決定し、これを各ユーザ端末へのアクセスパスとして返信するリクエスト受付システムにおいて、以下のような手段を講じた点に特徴がある。

(1)ユーザ端末から受信したアクセスパス要求を受け付けてアクセスパス応答を返信するアクセスパスサーバを設け、このアクセスパスサーバが、アクセスパス要求を受信するアクセスパス要求受信手段と、受信したアクセスパス要求ごとにサービス提供サーバへのアクセスタイミングを決定するアクセスタイミング決定手段と、各アクセスパス要求への応答メッセージとして、前記アクセスタイミングを含むアクセスパス応答を生成するアクセスパス応答生成手段と、前記アクセスパス応答を返信するアクセスパス応答返信手段とを含み、前記アクセスタイミング決定手段は、アクセスパス要求の受信順序とアクセスタイミングの順序とに順序逆転が生じないように各アクセスタイミングを決定することを特徴とする。

(2)複数のサービス提供サーバを備え、前記アクセスタイミング決定手段は、各サービス提供サーバへのアクセス状況と各サービス提供サーバの処理能力とに基づいて、アクセスタイミングをサービス提供サーバごとに決定することを特徴とする。

(3)ユーザ端末が、アクセスパス要求をアクセスパスサーバへ送信する手段と、アクセスパス応答を受信する手段と、前記アクセスパス応答からアクセスタイミングを抽出する手段と、前記アクセスタイミングを待ってサービス要求をサービス提供サーバへ送信する手段とを含むことを特徴とする。

(4)アクセスパス要求を送信したユーザ端末がサービス要求を送信する推定確率を算出する手段を具備し、前記アクセスタイミング決定手段は、前記推定確率が低いほどアクセスタイミングを早めることを特徴とする。

本発明によれば、以下のような効果が達成される。

上記した特徴(1)によれば、アクセスパス要求に応答してアクセスパス応答を返信するという低負荷の処理のみを実行するアクセスパスサーバと、サービス要求を受け付けて処理するという高負荷の処理を実行するサービス提供サーバとが独立しているので、アクセスパスサーバでは、アクセスパス要求の受信が短時間に集中する場合でも全てのアクセスパス要求を漏れなく受け付けて応答できるようになる。しかも、アクセスパスサーバでは、アクセスパス要求の受信順に早いアクセスタイミングを割り当てるので、アクセスパス要求の受信が集中する場合でも、全てのサービス要求を漏れなく、かつ最初のアクセスパス要求の受付順序で公平に受け付けられるようになる。

上記した特徴(2)によれば、アクセスタイミングがサービス提供サーバごとに決定されるので、各サービス提供サーバの負荷や処理能力が異なる場合でも、負荷の小さいサービス提供サーバへのアクセスタイミングが、負荷の大きいサービス提供サーバでの処理遅延に引きずられて遅くなることがない。

上記した特徴(3)によれば、ユーザはユーザ端末を最初に一回だけ操作してアクセスパス要求を送信するだけで、その後のアクセスパス応答の受信やサービス要求の送信を意識することなく、所望のサービスを要求できるようになる。

上記した特徴(4)によれば、アクセスパス要求を送信してアクセスタイミングを取得したユーザ端末がサービス要求を送信する推定確率が低く、サービス提供サーバのアクセス状況や処理能力により求められたアクセスタイミングよりも早いタイミングでのサービス提供が可能な場合には、アクセスタイミングが早められるので、ユーザにとってはサービスを受けられるまでの時間を短縮できるようになると共に、サービスを提供する側にとっても、サービス提供サーバの稼働率を向上させることができる。

以下、図面を参照して本発明の最良の実施の形態について詳細に説明する。図１は、本発明のリクエスト受付システムが適用されるネットワークの主要部の構成を示したブロック図であり、ここでは、ユーザ端末からサービス提供サーバへコンテンツ配信を要求する場合を例にして説明する。

携帯電話、PDA、あるいはコンピュータなどのユーザ端末MNは基地局APを経由して携帯電話網あるいはインターネット等の広域ネットワークNWに接続されている。また、ユーザ端末MNからの要求に応答して、音楽や映像などのコンテンツを配信する複数のサービス提供サーバCSjが、アクセスパスサーバAPSと共にゲートウエイGW経由で前記広域ネットワークNWに接続されている。

前記アクセスパスサーバAPSは、各ユーザ端末MNにサービス提供サーバCSjへのアクセスを許可するタイミングを決定して各ユーザ端末MNへ通知する機能を備え、各ユーザ端末MNから、アクセス先のサービス提供サーバCSjの識別情報およびコンテンツの識別情報を含むアクセスパス要求のメッセージを受信すると、サービス提供サーバCSjの能力やアクセス状態に基づいてアクセスタイミングを決定し、これをユーザ端末MNへ通知する。

図２は、前記アクセスパスサーバAPSの主要部の構成を示した機能ブロック図である。アクセスパスサーバAPSがアクセスパス要求を受信ごとに実行する応答処理は低負荷なので、アクセスパス要求が短時間に集中的に受信される場合でも、アクセスパスサーバAPSは全てのアクセスパス要求を受信順に滞りなく受付処理できる。

アクセスパス要求受信部１１は、各ユーザ端末MNから送信されたアクセスパス要求を受信する。サーバ能力管理部１２には、各サービス提供サーバCSjの処理能力を代表する指標として、単位時間ごとに処理可能なメッセージ数やデータ量などが制御レートCjとして予め登録されている。サーバ処理管理部１３では、各サービス提供サーバCSjにおいて未処理のリクエスト量がキュー値として管理されている。

アクセスタイミング決定部１４は、後に詳述するように、前記サーバ処理管理部１３で管理されている各サービス提供サーバCSjのキュー値や各サービス提供サーバCSjの処理能力Cjをパラメータとして、各ユーザ端末に対して許可する各サービス提供サーバCSjへのアクセスタイミングをアクセスパス要求ごとに決定する。アクセスパス応答生成部１５は、サービス提供サーバCSjへのアクセスタイミングを含むアクセスパス応答を生成する。アクセスパス応答返信部１６は、前記アクセスパス応答を前記アクセスパス要求の送信元に返信する。

なお、本実施形態ではアクセスパスサーバAPSがサービス提供サーバCSjと共にゲートウエイGWの配下に接続されているが、ゲートウエイGWにアクセスパスサーバAPSの機能が収容されるようにしても良い。

次いで、フローチャートを参照して本発明の動作を詳細に説明する。図３は、コンテンツ配信を要求するユーザ端末MNにおけるリクエスト処理の手順を示したフローチャート、図４，５，６，７は、アクセスパスサーバAPSの動作を示したフローチャートであり、図８はシーケンスフローである。

ユーザがユーザ端末MNのキースイッチ等を操作してコンテンツのリクエスト操作を実施し、これが図３のステップＳ１１で検知されるとステップＳ１２へ進む。ステップＳ１２では、リクエストするコンテンツの識別子および当該コンテンツを提供するサービス提供サーバCSjの識別子を含み、アクセスパスサーバAPSを宛先とするアクセスパス要求が生成され、ステップＳ１３において送信される。

アクセスパスサーバAPSは、図４のステップＳ３１において前記アクセスパス要求を受信すると、ステップＳ３２では、前記アクセスタイミング決定部１４において、ユーザ端末MNに前記サービス提供サーバCSjへのアクセスを許可するタイミングが以下の手順で決定される。

図５は、アクセスタイミング決定処理の手順を示したフローチャートであり、主に前記アクセスタイミング決定部１４の動作を示している。なお、各符号の定義は以下の通りである。

i：アクセスパス要求の識別子
j：サービス提供サーバCSの識別子
ti,j：サービス提供サーバCSjに対するi番目のアクセス要求時刻
di,j：サービス提供サーバCSjに対するi番目のアクセス要求に対して割り当てられるアクセスタイミングまでの遅延時刻
Cj：各サービス提供サーバCSjの処理能力（制御レート）
Qmax_j：各サービス提供サーバCSjのキュー値の上限値
bi,j：重み値
δ：アクセスパスサーバAPSからユーザ端末MNへのアクセスパス要求の想定伝達遅延時間
Qj(ti,j)⁻：時刻tiでアクセスパス要求を受信する直前のサービス提供サーバCSjのキュー値
Qj(ti,j)^＋：時刻tiでアクセスパス要求を受信した直後のサービス提供サーバCSjのキュー値
pj：サービス提供サーバCSjへアクセスパス要求を送信したユーザ端末MNが、許可されたアクセスタイミングでサービス提供サーバCSjへサービス要求を送信する推定確率

図５のステップＳ３２１では、受信したアクセスパス要求に登録されている識別子に対応したサービス提供サーバCSjに関して、前回のアクセスパス要求を時刻[ti-1]で受信した直後のキュー値[Qj(ti-1,j)^＋]が前記サーバ処理管理部１３から取り込まれる。ステップＳ３２２では、サービス提供サーバCSjの制御レートCjが前記サーバ能力管理部１２から取り込まれる。ステップＳ３２３では、時刻[ti,j]でサービス提供サーバCSj宛のアクセスパス要求を受信する直前の当該サービス提供サーバCSjの未処理リクエスト量、すなわちキュー値[Qj(ti,j)⁻]が次式(1)で求められる。

ステップＳ３２４では、時刻[ti,j]でアクセスパス要求を受信した直後のキュー値[Qj(ti,j)^＋]が次式(2)で求められる。

ここで、重み値[bi,j]はサービス要求を処理するサービス提供サーバCSjの処理負荷に依存し、例えば、アクセスパス要求が音楽コンテンツの配信要求であれば、リクエストする音楽ファイルのサイズが大きいメッセージほど大きな重み値bi,jが割り当てられる。なお、重み付けが不要であれば、前記重み値[bi,j]には所定の定数（例えば、「１」）が割り当てられる。

ステップＳ３２５では、アクセスパス要求を送信したユーザ端末MNに通知するアクセスタイミングが、当該アクセスパス要求の受信時刻[ti,j]を基準にした遅延時刻[di,j]として次式(3)で求められる。ステップＳ３２６では、前記キュー値[Qj(ti,j)^＋]の計算結果が前記サーバ処理管理部１３へ更新登録される。

なお、ユーザ端末MNがアクセスパス応答を受信しても、回線状況の変化等が原因で、許可されたアクセスタイミングにおいてサービス要求を送信できなくなる場合がある。次式(4)では、このような状況を考慮して、サービス要求を送信したユーザ端末MNが、さらにサービス要求を送信する推定確率pj(ti,j)をサービス提供サーバCSjごとに統計的に求めて前記遅延時刻[di,j]に反映させている。

図６は、前記推定確率Pj(ti,j)をサービス提供サーバCSjへのアクセスレートに基づいて算出する手順を示したフローチャートである。

ステップＳ７１において、サービス提供サーバCSjに関するアクセスパス要求が受信されると、ステップＳ７２では、前回のアクセスパス要求の受信時刻ti-1,jから今回のアクセスパス要求の受信時刻ti,jまでの経過期間Δti,j、および当該経過時間Δti,jにおけるサービス提供サーバCSjへのアクセス数ni,j、すなわちサービス要求の総数が算出される。

ステップＳ７３では、今回のアクセスパス要求を受信する直前のサービス提供サーバCSjのキュー値[Qj(ti,j)⁻]がゼロよりも大きいか否かが判定される。キュー値[Qj(ti,j)⁻]がゼロよりも大きければステップＳ７４へ進み、キュー値[Qj(ti,j)⁻]が最後にゼロとなった以降の累積アクセス数Mおよび経過時刻Tが算出される。ステップＳ７５では、サービス提供サーバCSjへの平均アクセスレートARj(ti,j)が、前記累積アクセス数Mおよび経過時刻Tに基づいて算出される。ステップＳ７６では、次式(5)に基づいて推定確率Pj(ti,j)が設定される。なお、符号Pminは０＜Pmin＜１の定数である。

これに対して、前記ステップＳ７３においてキュー値[Qj(ti,j)⁻]がゼロと判定されると、ステップＳ７７において推定確率Pj(ti,j)に「１」が登録される。ステップＳ７８では、前記累積アクセス数Mおよび経過時刻Tがリセットされる。

図７は、前記推定確率Pj(ti,j)をサービス要求やコンテンツのボリューム（以下、アクセスボリュームで総称する）に基づいて算出する手順を示したフローチャートである。

ステップＳ８１において、サービス提供サーバCSjに関するアクセスパス要求が受信されると、ステップＳ８２では、前回のアクセスパス要求の受信時刻ti-1,jから今回のアクセスパス要求の受信時刻ti,jまでの経過期間Δti,j、および当該経過時間Δti,jにおけるサービス提供サーバCSjのアクセスボリュームvi,jが算出される。

ステップＳ８３では、今回のアクセスパス要求を受信する直前のサービス提供サーバCSjのキュー値[Qj(ti,j)⁻]がゼロよりも大きいか否かが判定される。キュー値[Qj(ti,j)⁻]がゼロよりも大きければステップＳ８４へ進み、キュー値[Qj(ti,j)⁻]が最後にゼロとなった以降の累積アクセスボリュームWおよび経過時刻Tが算出される。ステップＳ８５では、サービス提供サーバCSjへの平均アクセスボリュームVRj(ti,j)が、前記累積アクセスボリュームWおよび経過時刻Tに基づいて算出される。ステップＳ８６では、次式(6)に基づいて推定確率Pj(ti,j)が設定される。なお、符号Pminは０＜Pmin＜１の定数である。

これに対して、前記ステップＳ８３においてキュー値[Qj(ti,j)⁻]がゼロと判定されると、ステップＳ８７において推定確率Pj(ti,j)に「１」が登録される。ステップＳ８８では、前記累積アクセスボリュームWおよび経過時刻Tがリセットされる。

図４へ戻り、ステップＳ３３では、前記アクセスタイミングとしての遅延時刻[di,j]を含むアクセスパス応答が前記アクセスパス応答生成部１５で生成され、ステップＳ３４において、前記アクセスパス応答返信部１６から前記アクセスパス要求の送信端末宛に返信される。

図３へ戻り、ユーザ端末MNでは、前記アクセスパス応答をステップＳ１４で受信すると、ステップＳ１５では、このアクセスパス応答に登録されているアクセスタイミングとしての遅延時刻[di,j]が抽出される。ステップＳ１６では、抽出された遅延時刻[di,j]が所定の上限値dmaxと比較され、遅延時刻[di,j]＞dmaxであればステップＳ１７へ進み、サービスを提供できない旨のエラーメッセージを端末ディスプレーに表示して当該処理を中止する。これに対して、遅延時刻[di,j]≦dmaxであればステップＳ１８へ進み、図９(a)，(b)に一例を示したように、リクエストが先着順に処理されている旨を示す受付完了メッセージが端末ディスプレーに表示される。

ステップＳ１９では、配信を要求するコンテンツの識別子およびサービス提供サーバの識別子を含むコンテンツ要求がサービス要求として生成される。ステップＳ２０では、前記ステップＳ１３においてアクセス要求パスを送信してからの経過時間が前記遅延時刻[di,j]に達したか否かに基づいてアクセスタイミングであるか否かが判定され、アクセスタイミングを待ってステップＳ２１へ進む。ステップＳ２１では、前記ステップＳ１９で生成されたサービス要求（ここでは、コンテンツ要求）が、前記サービス提供サーバCSjを宛先として送信される。このようなユーザ端末MNにおけるアクセスタイミングまでの待機処理は、Java(登録商標)scriptなどの各種スクリプト言語やFlash機能を利用することで実装できる。

このサービス要求を受信したサービス提供サーバCSは、リクエストされているコンテンツを用意して前記ユーザ端末MNへ配信する。

ユーザ端末MNは、前記コンテンツをステップＳ２２で受信すると、ステップＳ２３へ進んで当該コンテンツを保存する。ステップＳ２４では、図１０に一例を示したダウンロード完了メッセージが端末ディスプレーに表示される。

図８に示したシーケンスフローは、ユーザ端末MN1，MN3がいずれもサービス提供サーバCS1にコンテンツ配信を要求し、ユーザ端末MN2がサービス提供サーバCS2にコンテンツ配信を要求した場合を示している。

前記アクセスパスサーバAPSは、ユーザ端末MN1からのアクセスパス要求に対しては、遅延時間d1後の時刻t1をアクセスタイミングとするアクセスパス応答を返信し、ユーザ端末MN3からのアクセスパス要求に対しては、遅延時間d3後の時刻t2をアクセスタイミングとするアクセスパス応答を返信し、ユーザ端末MN2からのアクセスパス要求に対しては、遅延時間d2後の時刻t3をアクセスタイミングとするアクセスパス応答を返信する。

ここで、ユーザ端末MN1，MN3のリクエスト先はいずれも同一のサービス提供サーバCS1なので、遅延時間d1，d3は、各ユーザ端末MN1，MN3のアクセスパス要求の受付順とアクセスタイミングの順序とが入れ替わらないように設定される。したがって、ユーザ端末MN1，MN3に関しては、アクセスパス要求の送信タイミングに応じた順序を維持してコンテンツを配信できるようになる。

これに対して、本実施形態ではサービス提供サーバCS2の処理能力がサービス提供サーバCS1に比べて低いか、あるいはサービス提供サーバCS2にアクセスが集中しているためにサービス提供サーバCS2の負荷がサービス提供サーバCS1の負荷よりも大きいので、ユーザ端末MN2に通知される遅延時間d2は、前記各遅延時間d1，d3よりも長くなっている。

なお、上記した実施形態では、ユーザ端末がコンテンツ配信用のアクセスパスを予め取得し、このアクセスパスによって許可されたアクセスタイミングでサービス提供サーバへコンテンツ要求を送信してコンテンツを受信する場合を例にして説明したが、本発明はこれのみに限定されるものではなく、ユーザ端末がデータやコンテンツをサービス提供サーバへアップロードするためのアクセスパスを予め取得し、許可されたアクセスタイミングでアップロードを実行する場合にも同様に適用できる。

本発明のリクエスト受付システムが適用されるネットワークのブロック図である。アクセスパスサーバAPSの主要部の構成を示した機能ブロック図である。ユーザ端末MNにおけるリクエスト処理の手順を示したフローチャートである。アクセスパスサーバにおけるアクセスパス応答処理の手順を示したフローチャートである。アクセスタイミング決定処理の手順を示したフローチャートである。ユーザ端末がサービス要求を送信する推定確率をサービス要求のアクセスレートに基づいて算出する手順を示したフローチャートである。ユーザ端末がサービス要求を送信する推定確率をアクセスパス要求のアクセスボリュームに基づいて算出する手順を示したフローチャートである。各アクセスパス要求後の手順を示したシーケンスフローである。受付完了メッセージの表示例を示した図である。ダウンロード完了メッセージの表示例を示した図である。

符号の説明

１１…アクセスパス要求受信部，１２…サーバ能力管理部，１３…サーバ処理管理部，１４…アクセスタイミング決定部，１５…アクセスパス応答生成部，１６…アクセスパス応答返信部、ＭＮ…ユーザ端末，ＡＰ…アクセスポイント，ＧＷ…ゲートウェイ，ＣＳ…サービス提供サーバ，ＡＰＳ…アクセスパスサーバ

Claims

ユーザ端末から送信されたアクセスパス要求を受け付けて、各ユーザ端末のサービス提供サーバへのアクセスタイミングを決定し、これを各ユーザ端末へのアクセスパスとして返信するリクエスト受付システムにおいて、
ユーザ端末から受信したアクセスパス要求を受け付けてアクセスパス応答を返信するアクセスパスサーバを備え、
前記アクセスパスサーバが、
アクセスパス要求を受信するアクセスパス要求受信手段と、
アクセスパス要求を送信したユーザ端末がサービス要求を送信する推定確率を算出する手段と、
受信したアクセスパス要求ごとにサービス提供サーバへのアクセスタイミングを決定するアクセスタイミング決定手段と、
各アクセスパス要求への応答メッセージとして、前記サービス提供サーバへのアクセスタイミングを含むアクセスパス応答を生成するアクセスパス応答生成手段と、
前記アクセスパス応答を返信するアクセスパス応答返信手段とを含み、
前記ユーザ端末が、
アクセスパス要求をアクセスパスサーバへ送信する手段と、
アクセスパス応答を受信する手段と、
前記アクセスパス応答からアクセスタイミングを抽出する手段と、
前記アクセスタイミングを待ってサービス要求をサービス提供サーバへ送信する手段とを含み
前記アクセスタイミング決定手段は、アクセスパス要求の受信順序とアクセスタイミングの順序とに順序逆転が生じないように、アクセスパス要求の受付順で各アクセスタイミングを決定し、前記推定確率が低いほどアクセスタイミングを早めることを特徴とするリクエスト受付システム。
複数のサービス提供サーバを備え、
前記アクセスタイミング決定手段は、各サービス提供サーバへのアクセス状況と各サービス提供サーバの処理能力とに基づいて、アクセスタイミングをサービス提供サーバごとに決定することを特徴とする請求項１に記載のリクエスト受付システム。
ユーザ端末から送信されたアクセスパス要求を受け付けて、各ユーザ端末のサービス提供サーバへのアクセスタイミングを決定し、これを各ユーザ端末へのアクセスパスとして返信するリクエスト受付方法において、
ユーザ端末から受信したアクセスパス要求を受け付けてアクセスパス応答を返信するアクセスパスサーバが、
アクセスパス要求を受信する手順と、
アクセスパス要求を送信したユーザ端末がサービス要求を送信する推定確率を算出する手順と
受信したアクセスパス要求ごとにサービス提供サーバへのアクセスタイミングを決定する手順と、
各アクセスパス要求への応答メッセージとして、前記サービス提供サーバへのアクセスタイミングを含むアクセスパス応答を生成する手順と、
前記アクセスパス応答を返信する手順とを含み、
前記ユーザ端末が、
アクセスパス要求をアクセスパスサーバへ送信する手順と、
アクセスパス応答を受信する手順と、
前記アクセスパス応答からアクセスタイミングを抽出する手順と、
前記アクセスタイミングを待ってサービス要求をサービス提供サーバへ送信する手順とを含み、
前記アクセスタイミングを決定する手順では、アクセスパス要求の受信順序とアクセスタイミングの順序とに順序逆転が生じないように、アクセスパス要求の受付順で各アクセスタイミングが決定され、前記推定確率が低いほどアクセスタイミングを早めることを特徴とするリクエスト受付方法。
複数のサービス提供サーバを備え、
前記アクセスタイミングを決定する手順では、各サービス提供サーバへのアクセス状況と各サービス提供サーバの処理能力とに基づいて、アクセスタイミングがサービス提供サーバごとに決定されることを特徴とする請求項３に記載のリクエスト受付方法。