WO2016190169A1 - 情報処理システム、サーバ及びプログラム、並びに端末及びプログラム - Google Patents

Abstract

サーバでの輻輳を防止すると共に、端末側のユーザにストレスを与えずかつ飽きさせないようにする技術として、リクエスト＆レスポンス方式が採用された情報処理システムに適用して好適な技術を確立すること。　サーバ２の負荷監視部１０２は、リクエストの処理に関する所定条件を満たしているか否かを監視する。待ち時間演算部１０３は、所定条件を満たしていない場合、プレイヤー端末１側での時間の流れの速度を制御する時間パラメータとして待ち時間を演算する。リクエスト実行部１０４は、リクエストを到達順に実行して、レスポンスを生成する。レスポンス送信制御部１０５は、レスポンスを、対応するリクエストを送信したプレイヤー端末１に送信すると共に、待ち時間が演算されている場合には当該待ち時間を示す情報も併せてプレイヤー端末１に送信する制御を実行する。

Description

情報処理システム、サーバ及びプログラム、並びに端末及びプログラム

　本発明は、情報処理システム、サーバ及びプログラム、並びに端末及びプログラムに関する。

　従来から、スマートフォン等の端末で実行可能なゲームとして、マルチバトル等複数のプレイヤーが参加可能なゲームが存在する（例えば特許文献１参照）。

　このようなゲームでは、次のようなリクエスト＆レスポンス方式が採用されている場合が多い。即ち、プレイヤーが端末を操作してコマンドを入力すると、端末は、当該コマンドをリクエストとしてサーバに送信する。サーバは、リクエストを実行し、その実行結果等をレスポンスとして端末に送信する。

ＷＯ２０１４／０９８２３７パンフレット

　近年のモバイルコンピューティングの発達により、ゲームのクライアント（端末）の数は加速度的に増加している。このため、膨大な数の端末によりゲームが同時に実行されることとなり、多数の端末からのリクエストがサーバに集中してしまい、サーバが輻輳状態に陥るおそれがある。
　従って、リクエスト＆レスポンス方式が採用されたゲームでは、サーバでの輻輳を防止する技術が必要になる。
　しかしながら、このような技術として好適な技術が見受けられない状況である。

　具体的には例えば、特許文献１に記載の技術は、リクエスト＆レスポンス方式とは別の方式を採用した技術である。

　また例えば、サーバの負荷を低減する従来の技術としては、並列化と、非同期Ｉ／Ｏが存在する。しかしながら、これらの技術は、リクエスト＆レスポンス方式が採用されたゲームに対しては不適である。

　即ち、並列化とは、サーバ・インフラ内の計算機資源（ノード）を増加させる技術であり、クライアントの増大に応じてサーバを増設し、サーバ・インフラ全体の処理能力を高め、より多くのリクエストを処理可能とする技術である。
　従って、並列化を適用する場合、サーバ負荷の上昇に合わせてアドホックにサーバを増設することになる。
　しかしながら、サーバの増設は、クライアント数（端末数）の増加が極めて早いゲーム分野では、現実的ではない。
　また、並列化を適用する場合、サーバ・インフラ内部に膨大な数の計算ノードを予め用意する必要がある。
　このことは、インフラの維持コストの大幅増につながるため、経済的ではない。

　非同期Ｉ／Ｏは、Ｉ／Ｏに伴う待ち時間を利用して、１つのスレッド／プロセスが複数のクライアントと通信を行う技術であり、サーバのＣＰＵの利用効率を向上させることができる。
　しかしながら、非同期Ｉ／Ｏは、クライアント数（端末数）が急激に増加した場合の輻輳を防ぐ機能を有していない。

　このように、サーバでの輻輳を防止する技術として、リクエスト＆レスポンス方式が採用されたゲームに適用して好適な技術が見受けられない状況である。
　なお、リクエスト＆レスポンス方式はゲームに特に限定されない。つまり、上記状況を換言すると、サーバでの輻輳を防止する技術として、リクエスト＆レスポンス方式が採用された情報処理システムに適用して好適な技術が見受けられない状況である。

　さらに、たとえサーバでの輻輳の防止自体が実現できたとしても、その結果として、端末を操作するユーザ（ゲームの場合プレイヤー）に不要なストレスを与えたり飽きさせる事態になることは避けなければならない。

　本発明は、このような状況に鑑みてなされたものであり、サーバ側での輻輳を防止すると共に、端末側のユーザ（ゲームの場合プレイヤー）にストレスを与えずかつ飽きさせないようにする技術として、リクエスト＆レスポンス方式が採用された情報処理システムに適用して好適な技術を確立することを目的とする。

　上記目的を達成するため、本発明の一態様の情報処理システムは、
　サーバと、当該サーバに所定のリクエストを送信する複数の端末とを含む情報処理システムにおいて、
　前記サーバは、
　リクエストの処理に関する所定条件を満たしているか否かを監視する監視手段と、
　前記所定条件を満たしていない場合、端末側でのリクエストの送信までの待ち時間を演算する待ち時間演算手段と、
　リクエストを到達順に実行して、レスポンスを生成するリクエスト実行手段と、
　前記レスポンスを、対応するリクエストを送信した端末に送信すると共に、前記待ち時間が演算されている場合には当該待ち時間を示す情報も併せて当該端末に送信する制御を実行する第１送信制御手段と、
　を備え、
　前記端末は、
　所定のコマンドを受け付けるコマンド受付手段と、
　前記サーバから前記待ち時間を示す情報が送信されてきた場合には、当該情報で特定される当該待ち時間を設定し、当該情報が送信されてきていない場合には、所定時間を待ち時間として設定する待ち時間設定手段と、
　設定された前記待ち時間に応じて、前記端末側での時間の流れの速度を制御し、当該時間の流れの速度で変化する画像の表示を制御する表示制御手段と、
　設定された前記待ち時間の経過後に、前記コマンドをリクエストとして前記サーバに送信する制御を実行する第２送信制御手段と、
　を備える。

　本発明の一態様のサーバは、
　所定のリクエストを送信する複数の端末と通信をするサーバにおいて、
　リクエストの処理に関する所定条件を満たしているか否かを監視する第１監視手段と、
　前記所定条件を満たしていない場合、端末側での時間の流れの速度を制御する時間パラメータとして待ち時間を演算する待ち時間演算手段と、
　リクエストを到達順に実行して、レスポンスを生成するリクエスト実行手段と、
　前記レスポンスを、対応するリクエストを送信した端末に送信すると共に、前記待ち時間が演算されている場合には当該待ち時間を示す情報も併せて当該端末に送信する制御を実行する送信制御手段と、
　を備える。

　本発明の一態様の第１プログラムは、上述の本発明の一態様のサーバに対応するプログラムである。

　本発明の一態様の端末は、
　リクエストに対するレスポンスを、当該リクエストを送信した端末に送信すると共に、所定条件を満たしている場合には次のリクエストの送信までの待ち時間を示す情報も併せて当該端末に送信するサーバとの間で通信をする端末において、
　所定のコマンドを受け付けるコマンド受付手段と、
　前記サーバから前記待ち時間を示す情報が送信されてきた場合には、当該情報で特定される当該待ち時間を設定し、当該情報が送信されてきていない場合には、所定時間を待ち時間として設定する待ち時間設定手段と、
　設定された前記待ち時間に応じて、前記端末側での時間の流れの速度を制御し、当該時間の流れの速度で変化する画像の表示を制御する表示制御手段と、
　設定された前記待ち時間の経過後に、前記コマンドをリクエストとして前記サーバに送信する制御を実行する送信制御手段と、
　を備える。

　本発明の一態様の第２プログラムは、上述の本発明の一態様の端末に対応するプログラムである。

　本発明によれば、サーバ側での輻輳を防止すると共に、端末側のユーザ（ゲームの場合プレイヤー）にストレスを与えずかつ飽きさせないようにする技術として、リクエスト＆レスポンス方式が採用された情報処理システムに適用して好適な技術を確立することができる。

本発明の一実施形態に係る情報システムの構成を示すブロック図である。 図２は、図１の情報処理システムのうち、本発明の端末の一実施形態としてのプレイヤー端末のハードウェア構成を示すブロック図である。 図１の情報処理システムのうち、本発明の一実施形態に係るサーバのハードウェア構成を示すブロック図である。 図２のプレイヤー端末と図３のサーバの機能的構成例を示す機能ブロック図である。 図４の機能的構成を有するサーバが実行する予防的負荷分散処理の概要説明するための模式図である。 図５の待ち時間ＤＢに格納されているリストの一例を示す図である。 本実施形態のゲーム画面の一例を示す図である。 コマンドの編集を説明するための模式図である。 マンドの非同期入力の具体例を示すゲーム画面の遷移図である。 図４の機能的構成を有するサーバ側の処理の流れの一例を説明するフローチャートである。 図４の機能的構成を有するプレイヤー端末側の処理の流れの一例を説明するフローチャートである。

　以下、本発明の実施形態について、図面を用いて説明する。

　なお、以下において、単に「画像」と呼ぶ場合には、「動画像」と「静止画像」との両方を含むものとする。
　また、「動画像」には、次の第１処理乃至第３処理の夫々により表示される画像を含むものとする。
　第１処理とは、平面画像（２Ｄ画像）におけるオブジェクト（例えばゲームキャラクタ）の夫々の動作に対して、複数枚からなる一連の静止画像を時間経過と共に連続的に切り替えて表示させる処理をいう。具体的には例えば、２次元アニメーション、いわゆるパラパラ漫画的な処理が第１処理に該当する。
　第２処理とは、立体画像（３Ｄモデルの画像）におけるオブジェクト（例えばゲームキャラクタ）の夫々の動作に対応するモーションを設定しておき、時間経過と共に当該モーションを変化させて表示させる処理をいう。具体的には例えば、３次元アニメーションが第２処理に該当する。
　第３処理とは、オブジェクト（例えばゲームキャラクタ）の夫々の動作に対応した映像（即ち動画）を準備しておき、時間経過と共に当該映像を流していく処理をいう。

　図１は、本発明の一実施形態に係る情報処理システムの構成を示している。
　図１に示す情報処理システムは、ｍ人（ｍは１以上の任意の整数値）のプレイヤーの夫々により使用されるプレイヤー端末１－１乃至１－ｍと、サーバ２とを含むシステムである。プレイヤー端末１－１乃至１－ｍの夫々と、サーバ２とは、インターネット等の所定のネットワークＮを介して相互に接続されている。

　サーバ２は、プレイヤー端末１－１乃至１－ｍの夫々に対してゲームの実行環境を提供し、プレイヤー端末１－１乃至１－ｍの夫々において実行されるゲームに関する各種各様のサービスを提供する。

　なお、以下、プレイヤー端末１－１乃至１－ｍの夫々を個々に区別する必要がない場合、これらをまとめて「プレイヤー端末１」と呼ぶ。

　図２は、図１の情報処理システムのうち、本発明の端末の一実施形態としてのプレイヤー端末１のハードウェア構成を示すブロック図である。

　プレイヤー端末１は、スマートフォン等で構成される。
　プレイヤー端末１は、ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）２１と、ＲＯＭ（Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ）２２と、ＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）２３と、バス２４と、入出力インターフェース２５と、タッチ操作入力部２６と、表示部２７と、入力部２８と、記憶部２９と、通信部３０と、ドライブ３１と、を備えている。

　ＣＰＵ２１は、ＲＯＭ２２に記録されているプログラム、又は、記憶部２９からＲＡＭ２３にロードされたプログラムに従って各種の処理を実行する。
　ＲＡＭ２３には、ＣＰＵ２１が各種の処理を実行する上において必要なデータ等も適宜記憶される。

　ＣＰＵ２１、ＲＯＭ２２及びＲＡＭ２３は、バス２４を介して相互に接続されている。このバス２４にはまた、入出力インターフェース２５も接続されている。入出力インターフェース２５には、タッチ操作入力部２６、表示部２７、入力部２８、記憶部２９、通信部３０及びドライブ３１が接続されている。

　タッチ操作入力部２６は、例えば表示部２７の表示面に積層される静電容量式又は抵抗膜式（感圧式）の位置入力センサにより構成され、タッチ操作がなされた位置の座標を検出する。
　ここで、タッチ操作とは、タッチ操作入力部２６に対する物体の接触又は近接の操作をいう。タッチ操作入力部２６に対して接触又は近接する物体は、例えばプレイヤーの指やタッチペン等である。なお、以下、タッチ操作がなされた位置を「タッチ位置」と呼び、タッチ位置の座標を「タッチ座標」と呼ぶ。
　表示部１７は、液晶等のディスプレイにより構成され、ゲームに関する画像等、各種画像を表示する。
　このように、本実施形態では、タッチ操作入力部２６と表示部２７とにより、タッチパネルが構成されている。

　入力部２８は、各種ハードウェア釦等で構成され、プレイヤーの指示操作に応じて各種情報を入力する。
　記憶部２９は、ＤＲＡＭ（Ｄｙｎａｍｉｃ　Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）等で構成され、各種データを記憶する。
　通信部３０は、インターネットを含むネットワークＮを介して他の装置（図１の例ではサーバ２や他のプレイヤー端末１）との間で行う通信を制御する。

　ドライブ３１は、必要に応じて設けられる。ドライブ３１には、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリ等よりなる、リムーバブルメディア４１が適宜装着される。ドライブ３１によってリムーバブルメディア４１から読み出されたプログラムは、必要に応じて記憶部２９にインストールされる。また、リムーバブルメディア４１は、記憶部２９に記憶されている各種データも、記憶部２９と同様に記憶することができる。

　図３は、図１の情報処理システムのうち、本発明の一実施形態に係るサーバ２のハードウェア構成を示すブロック図である。

　サーバ２は、ＣＰＵ５１と、ＲＯＭ５２と、ＲＡＭ５３と、バス５４と、入出力インターフェース５５と、出力部５６と、入力部５７と、記憶部５８と、通信部５９と、ドライブ６０とを備えている。
　サーバ２の構成は、プレイヤー端末１のタッチパネルを除いた構成と基本的に同様であるので、ここではその説明は省略する。

　このような図２のプレイヤー端末１及び図３のサーバ２の各種ハードウェアと各種ソフトウェアとの協働により、プレイヤー端末１でゲームの実行が可能になる。
　本実施形態では、マルチバトル等の複数のプレーヤが参加するゲームが対象であり、リクエスト＆レスポンス方式が採用されている。
　即ち本実施形態では、複数のプレイヤー端末１の夫々は、ゲームを同時に実行しており、当該ゲームのコマンドをリクエストとしてサーバ２に逐次送信する。サーバ２は、複数のプレイヤー端末１の夫々からのリクエストを受信し、夫々のリクエストを順次実行して、夫々の実行結果等をレスポンスとして複数のプレイヤー端末１の夫々に対して送信する。複数のプレイヤー端末１の夫々は、レスポンスを受信すると、コマンドを実行する。

　ここで、多数のプレイヤー端末１からリクエストが送信されて、サーバ２が所定の単位時間あたりに実行可能な処理量（ピーク）を超えると、サーバ２で制御不可能な輻輳が発生してしまう。
　この場合、プレイヤー端末１にとっては、リクエストに対するレスポンスの到達が遅延する。この遅延は予期せぬものであるため、ユーザにとっては、ゲームのコマンドが実行されない或いは実行されるのが非常に遅いと感じて、飽きてしまったり、ストレスを覚えたりする場合がある。

　そこで、本実施形態のプレイヤー端末１とサーバ２は、サーバ側での輻輳を防止すると共に、端末側のプレイヤーにストレスを与えずかつ飽きさせないようにするための機能を有している。
　図４は、このような機能を発揮するためのプレイヤー端末１とサーバ２の機能的構成例を示す機能ブロック図である。

　図４に示すように、サーバ２のＣＰＵ５１においては、リクエスト受信制御部１０１と、負荷監視部１０２と、待ち時間演算部１０３と、リクエスト実行部１０４と、レスポンス送信制御部１０５と、不正監視部１０６とが機能する。
　サーバ２の記憶部５８の一領域には、待ち時間ＤＢ１１１が設けられる。

　リクエスト受信制御部１０１は、プレイヤー端末１から送信されてきたリクエストを通信部５９にて受信することを制御する。
　負荷監視部１０２は、リクエストの処理に関する所定条件を満たしているか否かを監視する。
　所定条件は、リクエストに関する条件であれば足り、例えば、現在のリクエストの数が所定の閾値を超えていないという条件を採用することができる。所定の閾値や所定条件等の具体例については後述する。

　待ち時間演算部１０３は、所定条件を満たしていない場合（例えば単位時間当たりに処理可能な閾値数を超えた場合）、プレイヤー端末１側でのリクエストの送信までの待ち時間を演算し、その演算結果を待ち時間ＤＢ１１１に記憶させる。
　ここで、「待ち時間」とは、次のリクエストの送信を許可するまでの時間パラメータであって、プレイヤー端末１側で実行中のゲームの時間経過（時間の流れの速度）を制御するためのパラメータをいい、例えば「現在時刻からプラス何秒」というような相対的な値として演算される。
　即ち、待ち時間ＤＢ１１１は、複数のプレイヤー端末１（本実施形態ではプレイヤー端末１－１乃至１－ｍ）毎に、待ち時間等の情報をリスト化して記憶している。なお、待ち時間ＤＢ１１１に記憶されているリストの具体例については、図６を参照して後述する。

　リクエスト実行部１０４は、リクエストを到達順に実行して、レスポンスを生成する。
　レスポンス送信制御部１０５は、レスポンスを、対応するリクエストを送信したプレイヤー端末１に送信すると共に、待ち時間が演算されている場合には当該待ち時間を示す情報も併せてプレイヤー端末１に送信する制御を実行する。

　詳細については後述するが、複数のプレイヤー端末１の夫々は、レスポンスと共に待ち時間を示す情報を受信した場合には、次回のリクエストについては、コマンド等を受付けたタイミングから当該待ち時間が経過した後に、サーバ２に送信する。
　このようにして、サーバ２は、制御不可能な輻輳が発生する前に（所定の条件を満たさなくなることで）、複数のプレイヤー端末１の夫々に対して待ち時間を設定する。つまり、サーバ２は、複数のプレイヤー端末１の夫々に対してリクエストを送信する頻度を制御する。
　これにより、複数のプレイヤー端末１の夫々が少しずつ待ち時間を共有するといった、時間軸方向の予防的な負荷分散処理（以下、「予防的負荷分散処理」と呼ぶ）が実現される。

　さらに以下、図５を参照して、予防的負荷分散処理について説明する。
　図５は、予防的負荷分散処理の概要を説明するための模式図である。

　図５の左側のリクエストバッファ２０１は、リクエスト処理用のバッファであり、サーバ２に実在する。例えば図４等には図示しないが、本実施形態では記憶部５８にリクエストバッファ２０１が存在するものとする。
　リクエストバッファ２０１内の黒丸印が、所定のプレイヤー端末１から送信されたサーバ２で受信済みのリクエストを示している。即ち、サーバ２側のリクエスト実行部１０４により実行中又は実行待ちのリクエストを示している。ここで、黒丸印内の符号は、リクエストを送信したプレイヤー端末１を示している。即ち、１Ａの黒丸印は、プレイヤー端末１－Ａから送信されたリクエストを示している。１Ｂの黒丸印は、プレイヤー端末１－Ｂから送信されたリクエストを示している。１Ｃの黒丸印は、プレイヤー端末１－Ｃから送信されたリクエストを示している。
　リクエストバッファ２０１は、サーバ２に届いた順にリクエストを格納し、届いた順にリクエスト実行部１０４に出力して実行させるＦＩＦＯキューである。

　図５の右側の仮想待ち行列２０２は、サーバ２から複数のプレイヤー端末１（図５の例では説明の便宜上プレイヤー端末１－Ａ，１－Ｂ，１－Ｃ）の夫々に待ち時間が通知されることにより、仮想的に構成される待ち行列である。
　仮想待ち行列２０２内の白丸印が、所定のプレイヤー端末１から未送信のリクエストを示している。即ち、プレイヤー端末１側ではコマンドが入力されてから、待ち時間分だけ送信が遅延しているリクエストが、白丸印である。待ち時間が経過して送信可能になったリクエストには、「Ｄｅｌａｙ－ｔｉｍｅ　ｅｘｐｉｒｅｄ」という記述が施されている。
　即ち、この仮想待ち行列２０２は、サーバ２上のメモリ領域やディスク領域を消費して構築されるものではなく、プレイヤー端末１の夫々が、サーバ２から通知された待ち時間が経過するまで、次のリクエストの送信を待つ動作により、実質的に、あたかもプレイヤー端末１の夫々が１つの行列内に並ぶようにふるまうことにより構成される。

　図５の例では、複数のプレイヤー端末１－Ａ，１－Ｂ，１－Ｃの夫々に対して、待ち時間３０００ｍｓｅｃが設定されている。
　リクエストの実行は、リクエストバッファ２０１の格納順である。換言すると、所定の１タイミングには、少なくとも１つのリクエストが実行される。また、各リクエスト同士に依存関係がない場合は、サーバ２は、リクエストバッファ２０１からの複数のリクエストを一時に取り出し、並列に実行してもよい。
　例えば、仮想待ち行列２０２の上から２番目のリクエストは、プレイヤー端末１－Ｂにおいて待ち時間が経過したリクエストである。従って、当該リクエストは、プレイヤー端末１－Ｂからサーバ２に送信され、サーバ２のリクエストバッファ２０１に格納され、それより前に格納されたリクエストがリクエストバッファ２０１に存在しなくなった段階で、リクエスト実行部１０４により実行される。
　このようにしてリクエスト実行部１０４により当該リクエスト（リクエストバッファ２０１の上から２番目のリクエスト）が実行されると、レスポンス送信制御部１０５は、レスポンスを、プレイヤー端末１―Ｂに送信すると共に、待ち時間の値「３０００ｍｓｅｃ」も併せてプレイヤー端末１－Ｂに通知する。
　このようにしてプレーヤー端末１－Ｂに通知された待ち時間の値は、リクエストが送信可能になるまでの残り時間という観点で、全てのプレイヤー端末１（図５の例ではプレイヤー端末１－Ａ，１－Ｂ，１－Ｃ）の中で最大値となる。従って、仮想待ち行列２０２の最後尾（図５の例では上から５番目の白丸印）に追加されることになる。

　ここで着目すべき点は、図５を用いて説明した予防的負荷分散処理では、プレイヤー端末１同士のＰ２Ｐ通信は行われておらず、サーバ２へのアクセス頻度が複数のプレイヤー端末１毎にサーバ２側で自律分散的に決定されている点である。
　これにより、サーバ２へ到着するリクエストの単位時間内の総数が制御され、サーバ２での輻輳が防止される。

　具体的には本実施形態では、サーバ２に到着するリクエストの単位時間内の総数を制御することを目的として、サーバ２の単位時間内の処理可能リクエスト数（以下「キャパシティ数」と呼ぶ）が事前に見積られている。
　そして、このキャパシティ数に基づいて所定の閾値（例えばキャパシティ数の８０％の値）も予め定義され、現在のリクエスト数が当該閾値を超えないことという条件も予め設定されている。
　つまり、負荷監視部１０２は、当該条件を満たしているか否かを監視することで、サーバ２の負荷状態を関している。

　待ち時間演算部１０３は、前記条件を満たしていない場合、つまり、現在のリクエスト数が当該閾値を超えた場合（以下、このような場合を「負荷大」の場合と呼ぶ）、例えば次の式（１）に従って待ち時間を演算する。

　　　　　　　　　　　　　　　　　　　　　　　　　　　・・・（１）
　式（１）において、ｄｅｌａｙ＿ｓｅｃは待ち時間を示している。ｒｅｑｕｅｓｔ＿ｐｅｒ＿ｓｅｃは、１秒間にサーバ２に到達するリクエスト数を示している。ｃａｐａｃｉｔｙ＿ｐｅｒ＿ｓｅｃは、サーバ２に１秒間に処理可能なリクエスト数を示している。
　即ち、本実施形態では、待ち時間（ｄｅｌａｙ＿ｓｅｃ）として、現在のリクエスト数（ｃａｐａｃｉｔｙ＿ｐｅｒ＿ｓｅｃ）をキャパシティ数（ｃａｐａｃｉｔｙ＿ｐｅｒ＿ｓｅｃ）で除算した値が採用されている。
　このような値を採用することにより、単位時間内にキャパシティ数を超過するリクエストが到達することが予想される場合（負荷大となる場合）、超過分のリクエストは図５の仮想待ち行列２０２に格納されるので、図５を用いて上述したように、単位時間内に処理可能なリクエストのみがサーバに到達する、といった制御が実現される。

　なお、待ち時間の演算手法は、特に式（１）に従った本実施形態の手法に限定されず、例えば、ネットワークＮの性能やＤＢの書き込み性能等を考慮し、リクエスト毎に異なる待ち時間を演算する手法を採用してもよい。

　リクエスト実行部１０４は、図５のリクエストバッファ２０１の格納順（到達順）にリクエストを実行して、レスポンスを生成する。
　レスポンス送信制御部１０５は、レスポンスを、対応するリクエストを送信したプレイヤー端末１に送信すると共に、上述の待ち時間を当該プレイヤー端末１に通知する。

　複数のプレイヤー端末１（図５の例ではプレイヤー端末１－Ａ，１－Ｂ，１－Ｃ）の夫々は、次のリクエストを送信する際には、通知された待ち時間の経過後に、サーバ２にアクセスする。

　このようにして、複数のプレイヤー端末１の夫々に対して、レスポンスが送信される際に待ち時間が設定される。
　ここで、レスポンスの送信タイミングは、複数のプレイヤー端末１毎に少しずつずれている。その結果、上述した図５に示すように、複数のプレイヤー端末１の夫々が少しずつ異なる待ち時間（次のリクエストを送信するまでの残り時間）を有することになる。つまり、膨大な数のプレイヤー端末１（送信予定のリクエスト）が、あたかも巨大な仮想待ち行列２０２に格納されることになる。
　これにより、サーバ２における輻輳が防止される。

　なお、仮想待ち行列２０２内の位置は厳密なものではなく、待ち時間の通知やリクエストの送信に用いるネットワークＮの性能により、多少前後する可能性があるが、ゲーム分野に適用する場合には特に問題とならない。
　また、この仮想待ち行列２０２からサーバ２上のリクエストバッファ２０１に対してリクエストを送出するためのキューイングの演算は、プレイヤー端末１間の比較操作を伴わず、待ち時間の設定のみで実現される。従って、このキューイングは常に０（ｎ）のコストで実施が可能である。

　ただし、このような待ち時間を複数のプレイヤー端末１に通知しただけでは、当該待ち時間を守らない不正なプレイヤー端末１がでてくるおそれがある。
　そこで、本実施形態のサーバ２においては、図４に示すように不正監視部１０６も機能する。
　不正監視部１０６は、リクエスト受信制御部１０１の制御により受信されたリクエストが、待ち時間を守ってプレイヤー端末１から送信されたものか否かを監視している。

　具体的には例えば本実施形態では、図６に示すリストが待ち時間ＤＢ１１１に格納されている。
　図６のリストの所定の１行は、所定の１つのプレイヤー端末１に対応している。即ち、所定の１行には、対応するプレイヤー端末１についての、クライアントＩＤ、最後のリクエストが到達した時間、及び、割り当てた待ち時間が格納されている。換言すると、待ち時間ＤＢ１１１は、直前のリクエストの到達時刻（最後のリクエストが到達した時間）、及び待ち時間を対応付けて管理している。
　そこで、不正監視部１０６は、リクエストに含まれるクライアントＩＤを用いて、待ち時間ＤＢ１１１を検索し、「最後のリクエストが到達した時間」＋「割り当てた待ち時間」と、当該リクエストが実際に到達した時間とを照合する。
　そして、不正監視部１０６は、その照合結果に基づいて、当該リクエストを送信したプレイヤー端末１が不性であるか否かを判定する。
　不正であると判定されたプレイヤー端末１に対しては、所定のペナルティ処理が実行される。
　ペナルティ処理の内容は、特に限定されないが、例えば本実施形態では、不正なプレイヤー端末１からのリクエストを破棄し、レスポンスを返さないという処理が採用されている。

　なお、全てのリクエストの正当性を確認するとコストが大きい等の観点から、不正監視部１０６は、例えば一部のリクエスト、より具体的には無作為に抽出した全体の１０％程度のリクエストのみを確認してもよい。この場合、ペナルティ処理としては例えば、所定時間（例えば５分間）、不正が認められたプレイヤー端末１からのリクエストを破棄する等の処理を採用することができる。

　以上、予防的負荷分散処理（図５参照）を実現するためのサーバ２の機能的構成について説明した。
　次に、予防的負荷分散処理が実行される際のプレイヤー端末１の機能的構成について説明する。

　図４に示すように、プレイヤー端末１のＣＰＵ２１においては、コマンド受付部１２１と、待ち時間設定部１２２と、リクエスト送信制御部１２３と、表示制御部１２４と、レスポンス受信制御部１２５と、コマンド実行部１２６とが機能する。

　プレイヤーは、ゲーム実行中において、コマンドの入力が可能な画面（図７乃至図９を参照して後述する）が表示部２７に表示されている状態で、タッチ操作入力部２６に対して所定のタッチ操作（例えばタップ操作等）をすることで、所定のコマンドを入力する。
　コマンド受付部１２１は、このような所定のコマンドを受け付ける。

　待ち時間設定部１２２は、サーバ２から待ち時間を示す情報が送信されてきた場合には、当該情報で特定される待ち時間を設定する。これに対して、待ち時間設定部１２２は、当該情報が送信されてきていない場合には、所定時間を待ち時間として設定する。ここで、所定時間は、特に限定されず、予め設定された固定時間でもよいし、可変時間でもよい。また、所定時間には０も含むものとする。ここで、待ち時間が０とは、コマンドが受け付けられると即座に当該コマンドがリクエストとして送信されることを意味する。

　リクエスト送信制御部１２３は、待ち時間設定部１２２により設定された待ち時間の経過後に、コマンドをリクエストとして、通信部３０を介してサーバ２に送信する。

　このようにして、プレイヤー端末１側で、コマンド受付部１２１、待ち時間設定部１２２、及びリクエスト送信制御部１２３が機能することで、予防的負荷分散処理が実現される。

　ただし、プレイヤーにとっては、所定のコマンドを入力した後、当該所定のコマンドが実行されるまでに、待ち時間分だけ待たされることには変わりはない。この場合、プレイヤー端末１側で何ら措置を施さないと、プレイヤーは飽きてしまったり、何らかのストレスを覚えるおそれがある。

　ここで重要な点は、従来においては、プレイヤーの端末側では、コマンド入力と、当該コマンドの実行とは同期することが前提となっていた点である。つまり、従来のプレイヤーは、コマンドを入力すると、即座に当該コマンドが実行されるはず、という意識を持っていた。
　このため、端末やプレイヤーにとっては、コマンド入力後、当該コマンドに対応するリクエストがサーバに送信され、そのレスポンスがサーバから到達し、当該レスポンスに基づいてコマンドが実行されるまでの時間が長くなると、それは「予期せぬ待ち時間」として把握される。
　つまり、従来のサーバにおいて輻輳が発生したことにより、この「予期せぬ待ち時間」が発生することは、端末やプレイヤーにとって想定外のことである。
　このような「予期せぬ待ち時間」に対して端末側に何らかの措置を事前に施すことは困難である。このため、何ら措置を施していない従来の端末側では、「予期せぬ待ち時間」が経過するまで、待機状態となる。つまり、プレイヤーや端末にとっては、コマンド入力後、即座にコマンドが実行されずに待機状態が継続する時間が、「予期せぬ待ち時間」である。しかも、この「予期せぬ待ち時間」の長さは、プレイヤーや端末の与り知らぬサーバ側の輻輳の状態によって変化してしまう。従って、「予期せぬ待ち時間」が発生して端末側で待機状態になると、プレイヤーは、いつになったらコマンドが実行されるのかを予測することができなくなる。これにより、プレイヤーは、飽きてしまったり、何らかのストレスを覚えてしまうことになる。

　これに対して、本実施形態における「待ち時間」とは、サーバ２側で意図的に発生させた時間パラメータであり、従来の「予期せぬ待ち時間」とは本質的に異なる概念である。
　つまり、プレイヤー端末１は、このような「待ち時間（時間パラメータ）」が到達することは予測済みである。従って、プレイヤー端末１側で、「待ち時間（時間パラメータ）」を用いて、プレイヤーを飽きさせずかつストレスを与えないようにするための措置を施すことが可能になる。
　具体的には本実施形態では、プレイヤー端末１は、コマンドの入力と、コマンドの実行とを非同期にして、コマンドの入力から当該コマンドの実行までの時間の流れの速度を、「待ち時間（時間パラメータ）」に応じて制御する。そして、プレイヤー端末１は、この時間の流れの速度をプレイヤーに視覚的に提示する。このような措置により、プレイヤーを飽きさせずかつストレスを与えないようにすることが可能になる。
　より具体的には本実施形態では、表示制御部１２４は、図７乃至図９に示すようなゲーム画面を表示部２７に表示する制御を実行することで、プレイヤーを飽きさせずかつストレスを与えないようにしている。

　図７は、本実施形態のゲーム画面の一例を示す図である。
　図７のゲーム画面２１０の上方には、例えばＲＰＧ（Ｒｏｌｌ　Ｐｌａｙｉｎｇ　Ｇａｍｅ）における戦闘画面２２１が表示される。
　この戦闘画面２２１の下方に、プレイヤーがコマンドを選択するためのボタン（以下、「コマンド選択ボタン」と呼ぶ）が配置されたボタン群領域２２２が表示される。さらにその下方に、コマンドを示すアイコン（以下、「コマンドアイコン」と呼ぶ）があたかも一定方向に流れていくコマンドキュー２２３が表示される。

　プレイヤーは、ボタン群領域２２２に配置された１以上のコマンド選択ボタンのうち、所望のコマンド選択ボタンに対してタップ操作をすることで、対応するコマンドを入力する。
　コマンドキュー２２３は、ＦＩＦＯ（Ｆｉｒｓｔ－ｉｎ，Ｆｉｒｓｔ－ｏｕｔ）のキューとして実装されている。従って、プレイヤーにより入力されたコマンド（タップ操作されたコマンド選択ボタン）に対応するコマンドアイコンは、コマンドキュー２２３の最後尾（図７の例では最右側）に追加される。
　つまり、プレイヤーにより複数種類のコマンド選択ボタンがタップ操作されると、タップ操作がなされた順番で、複数種類のコマンドアイコンの夫々がコマンドキュー２２３に順次格納されて、当該コマンドキュー２２３内を順次左方に移動していく。
　そして、左端（図７の例では「発動」という文字列が記載された端）に到達したコマンドアイコンから、対応するコマンドが実行されるようになっている。
　ここで、コマンドキュー２２３内のコマンドアイコンの移動速度は、一定ではなく、待ち時間に応じて可変する。即ち、サーバ２から設定された待ち時間が長いほど、コマンドアイコンの移動速度は遅くなる。換言すると、サーバ２からの待ち時間の通知をサーバ２からの指示と把握するならば、サーバ２からの指示に応じて、コマンドキュー２２３の中のコマンドアイコンの移動速度が調整される。

　このように、コマンドキュー２２３内のコマンドアイコンの移動速度が、プレイヤー端末１側での時間の流れの速度に該当し、サーバ２により設定された「待ち時間（時間パラメータ）」に応じて制御される。
　従って、プレイヤーにとっては、コマンドが発動（実行）されるまでの時間の流れの速度が可視化される。つまり、プレイヤーは、あとどのぐらい待てばコマンドが発動されるのかを容易に視認することができる。これにより、プレイヤーは、ストレスもさほど受けずに、コマンドが発動されるまで飽きずに待つことができる。

　換言すると、このようなコマンドキュー２２３を導入したことで、コマンドの非同期入力とプレイヤー端末１側での時間の流れの速度制御とその可視化が実現され、その結果として、プレイヤーにストレスを与えずかつ飽きさせることない状態で、予防的負荷分散処理を実現することが可能になる。
　以下、コマンドの非同期入力について説明する。

　即ち、ボタン群領域２２２に配置されるコマンド選択ボタン自体は、一般的なＲＰＧ等のゲームにおいて従来から用いられているものである。
　従来においては、クライアント（本実施形態のプレイヤー端末１に相当する従来の端末）においてコマンド選択ボタンが押下されると、従来のサーバにリクエストが送信され、当該サーバからレスポンスが受信された後、コマンドが実行される。このリクエストの送信からレスポンスの受信までに要する時間は通常短時間であるため、プレイヤーにとっては、コマンド選択ボタンの押下とコマンドの実行とは同期しているように感じられる。それゆえ、サーバが負荷大の状態になり、コマンド選択ボタンの押下からコマンドの実行までの間にタイムラグが発生すると、プレイヤーは、ストレスを受けたり、飽きてしまうことになる。

　これに対して、本実施形態では、コマンド選択ボタンの押下タイミングと、コマンドの実行とにはタイムラグがあることが前提となっているＵＩ（Ｕｓｅｒ　Ｉｎｔｅｒｆａｃｅ）が採用されている。このようなＵＩが、コマンドの非同期入力である。そして、このタイムラグの時間長が、サーバ２から与えられた待ち時間（時間パラメータ）により可変制御され、その可変制御の結果の視覚化、即ち時間の流れの速度の視覚化が行われる。
　即ち、コマンド選択ボタンが押下されると、対応するコマンドアイコンがコマンドキュー２２３に格納されて、左方への移動を開始する。このコマンドアイコンの移動速度が、端末１側での時間の流れの速度に該当し、サーバ２から指定された待ち時間に応じて可変制御される。そして、サーバ２から指定された待ち時間が経過すると、リクエストがサーバ２に送信される。サーバ２側では予防的負荷分散処理が実行されているので、負荷大になることなく、短時間でレスポンスが送信されてくる。
　すると、図４のレスポンス受信制御部１２５は、当該レスポンスを受信する制御を実行する。ここで、待ち時間を示す情報も送信されてきている場合、レスポンス受信制御部１２５は、当該情報も受信して、待ち時間設定部１２２に提供する。コマンド実行部１２６は、レスポンスが受信されると、コマンドを実行する。

　このような一連の処理についていま現在どの程度まで進んでいるのか、つまり、あとどのぐらい時間が経てばコマンドが実行されるのかについては、対応するコマンドアイコンのコマンドキュー２２３の移動状況を視認することで、プレイヤーは容易に把握することができる。このため、プレイヤーは、ストレスを受けたり、飽きてしまうことなく、コマンドの実行を待つことができる。

　さらに、このようなコマンドの非同期入力を採用することで、コマンドの編集も可能になる。
　即ち、コマンドの非同期入力を採用すると、プレイヤーは、所定の第１コマンドを入力した後、当該第１コマンドが実行されるまでの間、さらに第２コマンドを入力することができる。つまり、１の種類のコマンドが実行される前に、複数種類のコマンドの入力が可能になる。
　従って、コマンドをリクエストとして送信する前の段階であれば、当該コマンドの編集も可能になる。

　図８は、コマンドの編集を説明するための模式図である。
　図８の例では、６種類の第１コマンド乃至第６コマンドがその順番で順次入力され、第１コマンド乃至第６コマンドの夫々に対応するコマンドアイコンＣ１乃至Ｃ６の夫々が、その順番でコマンドキュー２２３に格納されている。ここで、コマンド入力時にコマンドアイコンが格納される位置を以下「第１位置」と呼ぶ。コマンドアイコンＣ１乃至Ｃ６の夫々は、その順番で順次、待ち時間（時間パラメータ）に応じた移動速度で第１位置から左方に移動していく。

　ここで、コマンドアイコンの移動速度（プレイヤー端末１側での時間の流れの速度）は待ち時間に応じて変更されるので、コマンドキュー２２３内の所定位置にコマンドアイコンが到達したときに、リクエストの送信を行うことが可能になる。このように、リクエストが送信される時にコマンドアイコンが到達する所定位置を、以下「第２位置」と呼ぶ。
　コマンドキュー２２３のうち、第１位置から第２位置までの右側の範囲Ｒに存在するコマンドアイコンは、リクエスト送信前の段階のコマンドに対応するものである。従って、プレイヤーは、これらのコマンドを自由に編集できる。つまり、図８の例では、コマンドアイコンＣ２乃至Ｃ６に対応する第２コマンド乃至第６コマンドが編集可能である。
　これに対して、第２位置から、コマンドが実行される位置（図８の例では「発動」の文字列が表示される位置であり、以下「第３位置」と呼ぶ）までの左側の範囲Ｌに存在するコマンドアイコンは、リクエストが既に送信されてレスポンスの受信を待っている段階のコマンドに対応するものである。従って、プレイヤーは、これらのコマンドを編集することができない。つまり、図８の例では、コマンドアイコンＣ１に対応する第１コマンドは編集不可能である。

　コマンドの編集の操作等は、特に限定されない。例えば本実施形態では図８に示すように、プレイヤーは、編集対象のコマンドアイコンに対して所定のタッチ操作をすることで、当該コマンドアイコンに対応するコマンドの編集をすることができる。
　具体的には例えば、プレイヤーは、ドラッグ操作で、コマンドアイコンＣ５をコマンドキュー２２３の外側に移動させることで、当該コマンドアイコンＣ５に対応する第５コマンドをキャンセルすることができる。
　また例えば、プレイヤーは、ドラッグ操作で、コマンドアイコンＣ２，Ｃ４の順番（配置位置）を入れ替えることで、当該コマンドアイコンＣ２，Ｃ４の夫々にに対応する第２コマンド，第４コマンドの実行（発動）の順番を変更することができる。

　このように、コマンドキュー２２３内のコマンドアイコンの移動速度が低下したとき、即ち、サーバ２から待ち時間が設定されたとき、プレイヤーは、ボタン群領域２２２に配置されたコマンド選択ボタンに対してタップ操作したり、コマンドキュー２２３内のコマンドアイコンに対してドラッグ操作をすることで、対応するコマンドの追加や編集を行うことができる。ここで、コマンドの編集の種類は、特に限定されず、上述したキャンセルや、順序の入れ替え等任意の種類を採用することができる。

　これにより、コマンドの非同期入力を採用していない従来の方式と比較して、プレイヤーは、複数種類のコマンドを高速に入力し、かつ、それらをゲームの状況等に応じて適宜変更しながら、より深く当該ゲームの戦術を構成することができるようになる。

　図９は、コマンドの非同期入力の具体例を示すゲーム画面の遷移図である。

　図９の左側のゲーム画面が表示された状態で、プレイヤーは、戦闘画面２２１に表示されたキャラクタのうち、枠２５１（実際には枠２５１は表示されなくてもよい）内の第１キャラクタをタップ操作することで、当該第１キャラクタを選択することができる。
　すると、第１キャラクタが保有する複数のコマンドの一覧として、複数のコマンド選択ボタンが配置されたボタン群領域２２２が表示される。
　ここで、プレイヤーは、コマンド選択ボタンＢ７に対してタップ操作をしたものとする。すると、コマンド選択ボタンＢ７に対応するコマンドアイコンＣ７が、コマンドキュー２２３の最後尾の第１位置に追加され、左方への移動が開始される。

　次に、図９の中央のゲーム画面として示すように、プレイヤーは、戦闘画面２２１に表示されたキャラクタのうち、枠２５２（実際には枠２５２は表示されなくてもよい）内の第２キャラクタをタップ操作することで、当該第２キャラクタを選択することができる。
　すると、第２キャラクタが保有する複数のコマンドの一覧として、複数のコマンド選択ボタンが配置されたボタン群領域２２２が表示される。
　ここで、プレイヤーは、コマンド選択ボタンＢ８に対してタップ操作をしたものとする。すると、コマンド選択ボタンＢ８に対応するコマンドアイコンＣ８が、コマンドキュー２２３の最後尾の第１位置に追加され、左方への移動が開始される。この間、コマンドアイコンＣ７はさらに左方に移動している。
　このように、コマンドの非同期入力を採用することで、先に入力したコマンドがサーバ２に対してリクエストとして送信される前であっても、次のコマンドの入力が可能になる。

　次に、図９の右側のゲーム画面として示すように、プレイヤーは、戦闘画面２２１に表示されたキャラクタのうち、枠２５３（実際には枠２５３は表示されなくてもよい）内の第３キャラクタをタップ操作することで、当該第３キャラクタを選択することができる。
　すると、第３キャラクタが保有する複数のコマンドの一覧として、複数のコマンド選択ボタンが配置されたボタン群領域２２２が表示される。
　ここで、プレイヤーは、コマンド選択ボタンＢ９に対してタップ操作をしたものとする。すると、コマンド選択ボタンＢ９に対応するコマンドアイコンＣ９が、コマンドキュー２２３の最後尾の第１位置に追加され、左方への移動が開始される。この間、コマンドアイコンＣ８はさらに左方に移動している。
　コマンドアイコンＣ７は、さらなる左方の第２位置を通過して（その結果、対応するコマンドがサーバ２に対してリクエストとして送信され、サーバ２からのレスポンスが受信されて）、第３位置まで到達している。従って、この時点で図８の左側のゲーム画面において入力されたコマンド、即ちコマンドアイコンＣ７（コマンド選択ボタンＢ７）に対応するコマンドが実行される。

　以上、図４乃至図９を参照して、予防的負荷分散処理及びコマンドの非同期入力を実現可能にするためのプレイヤー端末１及びサーバ２の機能的構成について説明した。
　次に、図１０及び図１１を参照して、このような機能的構成を有するプレイヤー端末１及びサーバ２の処理の流れを説明する。

　図１０は、サーバ２側の処理の流れを説明するフローチャートである。
　ステップＳ１において、負荷監視部１０２は、負荷大か否かを判定する。
　即ち、負荷監視部１０２は、サーバ２のリソースの使用状況から、現在のリクエスト数が、キャパシティ数に基づく所定の閾値を超えないという条件を満たしているか否かを監視する。
　前記条件を満たしている場合、つまり、現在のリクエスト数が当該閾値を超えていない場合、ステップＳ１においてＮＯであると判定されて、処理はステップＳ３に進む。
　ステップＳ３において、待ち時間演算部１０３は、待ち時間を０として演算する。
　これに対して、前記条件を満たしていない場合、つまり、現在のリクエスト数が当該閾値を超えている場合、負荷大であるとしてステップＳ１においてＹＥＳであると判定され、処理はステップＳ２に進む。ステップＳ２において、待ち時間演算部１０３は、例えば上述の式（１）に従って待ち時間を演算する。

　ステップＳ４において、リクエスト受信制御部１０１は、リクエストが有るか否かを判定する。

　リクエストが無い場合には、ステップＳ４においてＮＯであると判定されて、処理はステップＳ９に進む。
　ステップＳ９において、サーバ２のＣＰＵ５１は、処理の終了指示が有ったか否かを判定する。ここで、処理の終了指示は、特に限定されないが、本実施形態ではサーバ２の電源遮断が採用されている。つまり、サーバ２において電源が遮断されると、ステップＳ９においてＹＥＳであると判定されて、サーバ２側の処理は終了になる。
　これに対して、サーバ２において電源が遮断されない限り、ステップＳ９においてＮＯであると判定されて処理はステップＳ１に戻され、それ以降の処理が繰り返される。

　ここで、複数のプレイヤー端末１（図１の例ではプレイヤー端末１－１乃至１－ｍ）のうち所定の１台からリクエストが送信されると、ステップＳ４においてＹＥＳであると判定されて、処理はステップＳ５に進む。

　ステップＳ５において、不正監視部１０６は、リクエストの待ち時間が適正か否かを判定する。

　即ち、不正監視部１０６は、待ち時間ＤＢ１１１に格納されたリスト（図９参照）から、リクエストに含まれるクライアントＩＤと対応付けられた待ち時間等を検索する。
　その検索結果に基づいて特定される適正な時間よりも早いタイミングでリクエストが送信されてきた場合、不正であるとしてステップＳ５においてＮＯであると判定されて処理はステップ６に進む。
　ステップＳ６において、不正監視部１０６は、リクエストを送信してきた不正なプレイヤー端末１に対して、ペナルティ処理を実行する。これにより、処理はステップＳ９に進み、それ以降の処理が繰り返される。
　これに対して、リクエストの待ち時間が適正であれば、ステップＳ５においてＹＥＳであると判定されて、処理はステップＳ７に進む。
　ステップＳ７において、リクエスト実行部１０４は、リクエストを実行し、レスポンスを生成する。
　ステップＳ８において、レスポンス送信制御部１０５は、レスポンスと待ち時間をプレイヤー端末１に送信する。
　その後処理はステップＳ９に進み、それ以降の処理が繰り返される。

　このようなサーバ２側の処理に対して、プレイヤー端末１側の処理の流れは、図１１に示されるようになる。
　即ち、図１１は、プレイヤー端末１側の処理の流れを説明するフローチャートである。
　図１１のプレイヤー端末１側の処理は、ゲーム実行中の所定のイベント、例えばＲＰＧにおける戦闘のイベント等により開始される。

　ステップＳ２１において、表示制御部１２４は、コマンド選択用ＵＩ、キューを含むゲーム画面を表示部２７に表示させる。
　ここで、コマンド選択用ＵＩとは、例えば上述の図７乃至図９で説明したコマンド選択ボタンが配置されたボタン群領域２２２が該当する。キューとは、例えばコマンドキュー２２３が該当する。

　ステップＳ２２において、コマンド受付部１２１は、コマンドが入力されたか否かを判定する。

　コマンドが入力されていない場合、ステップＳ２２においてＮＯであると判定されて、処理はステップＳ３４に進む。
　ステップＳ３４において、プレイヤー端末１のＣＰＵ２１は、処理の終了指示が有ったか否かを判定する。ここで、処理の終了指示は、特に限定されないが、本実施形態では上記所定のイベント（例えば先頭のイベント等）の終了の指示が採用されている。つまり、所定のイベントが終了すると、ステップＳ３４においてＹＥＳであると判定されて、プレイヤー端末１側の処理は終了になる。
　これに対して、所定のイベントが継続中である場合、ステップＳ３４においてＮＯであると判定されて処理はステップＳ２１に戻され、それ以降の処理が繰り返される。

　所定のコマンド選択ボタンがタップ操作されて、対応するコマンドがコマンド受付部１２１により受け付けられると、ステップＳ２２においてＹＥＳであると判定されて処理はステップＳ２３に進む。
　ステップＳ２３において、待ち時間設定部１２２は、サーバ２から待ち時間が通知済みか否かを判定する。
　サーバ２から待ち時間が未通知の場合（図１０のステップＳ３で待ち時間が０に設定された場合も含む）、ステップＳ２３においてＮＯであると判定されて、処理はステップＳ２４に進む。
　ステップＳ２４において、待ち時間設定部１２２は、規定の待ち時間を設定する。ここで、規定の待ち時間とは、プレイヤー端末１側での時間の流れの速度についての「基準速度」を示す時間パラメータである。このようなステップＳ２４の処理が終了すると、処理はステップＳ２６に進む。
　これに対して、待ち時間が通知済みの場合（前回のステップＳ３２において受信されたレスポンスに対して、待ち時間を示す情報が付加されていた場合）、ステップＳ２３においてＹＥＳであると判定されて、処理はステップＳ２５に進む。
　ステップＳ２５において、待ち時間設定部１２２は、サーバ２からの待ち時間を設定する。ここで、サーバ２からの待ち時間とは、上述したように、プレイヤー端末１側での時間の流れの速度を基準速度に対して変更するための時間パラメータであって、サーバ２により設定される時間パラメータである。このようなステップＳ２５の処理が終了すると、処理はステップＳ２６に進む。

　ステップＳ２６において、表示制御部１２４は、ステップＳ２４又はＳ２５において設定された待ち時間を用いて、コマンドアイコンの移動速度（プレイヤー端末１側での時間の流れの速度）を演算する。
　具体的には例えば、コマンドアイコンの描画方式として、多くのゲームシステムで採用されているフレーム描画方式が採用されている場合、表示制御部１２４は、１フレームあたりの移動ピクセル量を、移動速度として演算する。
　より具体的には例えば、５０ｍｓｅｃ毎に画面が更新されるゲームシステムにおいて、サーバ２から「１０００ｍｓｅｃ」という待ち時間を示す情報が通知されものとする。この場合、表示制御部１２４は、上述の例のコマンドキュー２２３内の最後尾の第１位置から、リクエストが送信される第２位置まで１秒間でコマンドアイコンが到達するように、移動速度を演算する。即ち、表示制御部１２４は、コマンドアイコンを第１位置に配置した場合における、当該アイコンから第２位置までのピクセル数を（１０００／５０）で除算した値を、１フレームあたりの移動ピクセル量（移動速度）として演算する。

　ステップＳ２７において、表示制御部１２４は、コマンドアイコンの移動表示を開始させる。
　即ち、上述の例で言えば、コマンドアイコンは、コマンドキュー２２３内の最後尾の第１位置に配置され、左方に移動を開始する。

　ステップＳ２８において、コマンド受付部１２１は、コマンドアイコンの操作が有ったか否かを判定する。
　コマンドアイコンに対するドラッグ操作等が有った場合、ステップＳ２８においてＹＥＳであると判定されて、処理はステップＳ２９に進む。
　ステップＳ２９において、表示制御部１２４は、コマンドを削除したり順番を変更等する編集処理を実行する。これにより、処理はステップＳ３０に進む。
　これに対して、コマンドアイコンに対するドラッグ操作等が無かった場合、ステップＳ２８においてＮＯであると判定されて、コマンドの編集処理（ステップＳ２９の処理）は実行されずに、処理はステップＳ３０に進む。

　ステップＳ３０において、表示制御部１２４は、待ち時間が経過したか否かを判定する。
　待ち時間が経過していない場合、リクエストを送信するタイミングでないので、処理はステップＳ２８に戻され、それ以降の処理が繰り返される。即ち、リクエストが送信されるまでの間、コマンドアイコンの操作による、コマンドの編集処理の実行が可能になる。

　待ち時間が経過すると、ステップＳ３０においてＹＥＳであると判定されて、処理はステップＳ３１に進む。
　ステップＳ３１において、リクエスト送信制御部１２３は、コマンドをリクエストとしてサーバ２に送信する。
　これにより、図１０のステップＳ４においてＹＥＳであると判定されて、不正なリクエストでない限り、ステップＳ８においてレスポンスと待ち時間がプレイヤー端末１に送信されてくる。
　ステップＳ３２において、レスポンス受信制御部１２５は、レスポンスと待ち時間を受信する。
　ステップＳ３３において、コマンド実行部１２６は、コマンドを実行する。
　これにより、処理はステップＳ３４に進み、それ以降の処理が繰り返される。

　なお、説明の便宜上、図１１のフローチャートでは、ステップＳ２７乃至Ｓ３３の処理は、ステップＳ２１乃至Ｓ３４内の一環の処理として記載されている。
　ただし、実際には上述したように、本実施形態ではコマンドの非同期入力が実現されているので、ステップＳ２７乃至Ｓ３３の処理は、複数のコマンドが入力される毎に、複数のコマンドの夫々に対する処理として並行して実行される。

　以上本発明の一実施形態について説明したが、本発明は、上述の実施形態に限定されるものではなく、本発明の目的を達成できる範囲での変形、改良等は本発明に含まれるものである。

　例えば、図４の機能的構成は例示に過ぎず、特に限定されない。即ち、上述した一連の処理を全体として実行できる機能が情報処理システムに備えられていれば足り、この機能を実現するためにどのような機能ブロックを用いるのかは特に図４の例に限定されない。また、機能ブロックの存在場所も、図４に特に限定されず、任意でよい。例えば、サーバ２の機能ブロックをプレイヤー端末１等に移譲させてもよいし、逆に端末１の機能ブロックをサーバ２等に移譲させてもよい。
　また、１つの機能ブロックは、ハードウェア単体で構成してもよいし、ソフトウェア単体で構成してもよいし、それらの組み合わせで構成してもよい。

　各機能ブロックの処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、コンピュータ等にネットワークや記録媒体からインストールされる。
　コンピュータは、専用のハードウェアに組み込まれているコンピュータであってもよい。また、コンピュータは、各種のプログラムをインストールすることで、各種の機能を実行することが可能なコンピュータ、例えばサーバの他汎用のスマートフォンやパーソナルコンピュータであってもよい。

　このようなプログラムを含む記録媒体は、プレイヤーにプログラムを提供するために装置本体とは別に配布される図示せぬリムーバブルメディアにより構成されるだけでなく、装置本体に予め組み込まれた状態でプレイヤーに提供される記録媒体等で構成される。

　なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、その順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的或いは個別に実行される処理をも含むものである。
　また、本明細書において、システムの用語は、複数の装置や複数の手段等より構成される全体的な装置を意味するものとする。

　換言すると、本発明が適用される情報処理システムは、上述の図１の実施形態としての情報処理システムを含め、次のような構成を有する各種各様の実施形態を取ることができる。
　即ち、本発明が適用される情報処理システムは、
　サーバ（例えば図１等のサーバ２）と、当該サーバに所定のリクエストを送信する複数の端末（例えば図１等プレイヤー端末１－１乃至１－ｍ）とを含む。
　前記サーバは、
　リクエストの処理に関する所定条件を満たしているか否かを監視する監視手段（例えば図４の負荷監視部１０２）と、
　前記所定条件を満たしていない場合、端末側でのリクエストの送信までの待ち時間を演算する待ち時間演算手段（例えば図４の待ち時間演算部１０３）と、
　リクエストを到達順に実行して、レスポンスを生成するリクエスト実行手段（例えば図４のリクエスト実行部１０４）と、
　前記レスポンスを、対応するリクエストを送信した端末に送信すると共に、前記待ち時間が演算されている場合には当該待ち時間を示す情報も併せて当該端末に送信する制御を実行する第１送信制御手段（例えば図４のレスポンス送信制御部１０５）と、
　を備える。
　前記端末は、
　所定のコマンドを受け付けるコマンド受付手段（例えば図４のコマンド受付部１２１）と、
　前記サーバから前記待ち時間を示す情報が送信されてきた場合には、当該情報で特定される当該待ち時間を設定し、当該情報が送信されてきていない場合には、所定時間を待ち時間として設定する待ち時間設定手段（例えば図４の待ち時間設定部１２２）と、
　設定された前記待ち時間に応じて、前記端末側での時間の流れの速度を制御し、当該時間の流れの速度で変化する画像の表示を制御する表示制御手段（例えば図４の表示制御部１２４）と、
　設定された前記待ち時間の経過後に、前記コマンドをリクエストとして前記サーバに送信する制御を実行する第２送信制御手段（例えば図４のリクエスト送信制御部１２３）と、
　を備える。

　ここで、例えばサーバ側の有限の計算機資源の処理能力を予め把握し、当該処理能力内のリクエストが到達することを前提として「所定の条件」を設定することができる。これにより、当該処理能力を超過するリクエストが到達して、サーバ負荷がピークに達する前に、各端末からのリクエストの到達を時間方向に分散することが可能になる。即ち、予防的負荷分散処理が実現可能になる。
　つまり、サーバ・インフラの処理能力を超えるリクエストが来るときには、各端末に対して待ち時間が夫々設定されて、当該待ち時間が到達した順にリクエストが順次サーバに送信されてくる。これにより、サーバは、致命的な輻輳を起こすことなく、それらのリクエストを処理することができる。
　このようにして、サーバでの輻輳を防止する技術として、リクエスト＆レスポンス方式が採用された情報処理システムに適用して好適な技術が確立される。

　さらに、端末側では、所定のコマンドが受け付けられてから、当該コマンドのリクエストが送信されるまでにはタイムラグがあることが前提となっているため、上述のコマンド非同期入力が実現される。
　そして、サーバにより時間パラメータとして設定される「待ち時間」、又は基準となる「所定時間」に応じて、端末側での時間の流れの速度が制御され、その時間の流れの速度が視覚化されてユーザ（ゲームの場合プレイヤー）に提示される。
　これにより、ユーザは、コマンド入力後当該コマンドの実行までの間、飽きずにかつストレスを覚えずに済むようになる。

　また、本発明が適用される情報処理システムでは、負荷分散をする際に追加のサーバハードウェアやネットワーク設備を特に必要としないため、従来よりも極めて実施コストで実現可能である。さらに、本発明が適用される情報処理システムは、既存のアプリケーション・プロトコル（ｈｔｔｐやｈｔｔｐｓ、Web Socket等）を用いて実装することができるため、既存のロードバランサをそのまま併用することができる。

　ここで、サーバの前記待ち時間演算手段は、単位時間あたりに到達するリクエストの数と、当該単位時間あたりに処理可能なリクエストの数とに基づいて、前記待ち時間を演算することができる。
　これにより、単位時間あたりに処理可能なリクエストの数（キャパシティ）と、単位時間あたりに到達するリクエストの数（実績）とに基づく適切な時間が、待ち時間として設定される。その結果、予防的負荷分散処理がより効率的に実現可能になる。

　また、サーバは、
　前記複数の端末毎に、直前のリクエストの到達時刻、及び前記待ち時間を対応付けて管理する管理手段（例えば図４の待ち時間ＤＢ１１１及びＣＰＵ５１）と、
　リクエストが到達した際に、前記管理手段の管理内容に基づいて、当該リクエストを送信した前記端末が前記待ち時間を守ったか否かを監視する第２監視手段（例えば図４の不正監視部１０６）と、
　をさらに備えるようにすることができる。
　これにより、待ち時間を守らない不正な端末（ユーザであり、ゲームの場合プレイヤー）に対して各種ペナルティ処理を実行することが容易に可能になる。

　ここで、端末の表示制御手段は、上述したように、設定された待ち時間に応じて、端末側での時間の流れの速度を制御し、当該時間の流れの速度で変化する画像の表示を制御する。
　また、送信制御手段は、設定された前記待ち時間の経過後に、前記コマンドをリクエストとして前記サーバに送信する制御を実行する。

　ここで、「当該時間の流れの速度で変化する画像」は、上述の実施形態に限定されず、任意の動画像、例えばゲームが採用されている場合には当該ゲーム内のキャラクタが動くアニメーション等を採用することもできる。
　この場合、端末側で設定される「待ち時間」とは、端末側での時間の流れの速度を制御するパラメータであり、次の２通りの方法で使用される。
　１つ目の方法は、動画像の再生時間を制御するパラメータとして用いる方法である。これにより、「当該時間の流れの速度で変化する画像」が実現可能になる。
　２つ目の方法は、端末から次のリクエストがサーバへ送信されるタイミングを制御するパラメータとして用いる方法である。これにより、送信制御手段の制御が実現可能になる。

　このように「当該時間の流れの速度で変化する画像」は、任意の動画像で足りるが、上述の実施形態のように、コマンドを示すシンボルを、第１位置から第２位置まで移動させる様子を示す画像であると好適である。
　この場合、シンボルの移動速度が、端末側での時間の流れの速度に該当する。つまり、当該時間の流れの速度で変化する画像とは、当該移動速度で前記シンボルを前記第２位置に向かって移動させる様子を示す画像である。
　ユーザ（ゲームの場合プレイヤー）は、このような画像を視認することで、その時間の流れの速度を即座にかつ明確に認識することができるようになる。即ち、ユーザは、あとどのぐらいでコマンドが実行されるのかを即座にかつ明確に視認することができる。その結果、ユーザは、より一段と、飽きずにかつストレスを覚えずに済むようになる。

　具体的には、端末の前記表示制御手段は、
　コマンドを示すシンボルを、第１位置から第２位置まで移動させる様子を示す画像を表示する制御として、
　前記コマンドが受け付けられたときには前記シンボルを第１位置に配置させ、
　設定された前記待ち時間で前記シンボルが前記第１位置から前記第２位置まで移動するように、前記シンボルの移動速度を決定し、
　当該移動速度で前記シンボルを前記第２位置に向かって移動させる、
　様子を示す画像を表示させる制御を実行し、
　前記送信制御手段は、前記シンボルが前記第２位置に到達したときに、前記コマンドをリクエストとして前記サーバに送信することができる。

　ここで、シンボルが第２位置に到達した際にリクエストが端末からサーバに送信される。予防的負荷分散処理が実行されていたとしても、リクエストの送信からレスポンスの受信までには短時間であるが、一定のタイムラグは生ずる。つまり、シンボルが第２位置に到達してから、コマンドが実行（発動）されるまでに、一定のタイムラグが生ずる。
　そこで、前記表示制御手段は、前記シンボルを、前記第１位置から前記第２位置を経由して第３位置まで移動させる様子を示す画像の表示を制御し、
　前記シンボルが前記第３位置に到達したときに、前記コマンドに対応する前記サーバからの前記レスポンスに基づいて、当該コマンドに対応する処理を実行するコマンド実行手段をさらに備える、
　ようにすることができる。

　前記コマンド受付手段は、複数のコマンドを順次受け付け、
　前記表示制御手段は、前記複数のコマンドの夫々に対応する複数のシンボルを、コマンドの受付け順に、前記第１位置から第２位置まで夫々移動させる様子を示す画像を表示させ、
　前記第２位置に到達する前のシンボルについては、他のシンボルとの順番を入れ替える操作を、当該シンボルに対応するコマンドの実行順番の変更指示として受け付けるコマンド順番変更手段をさらに備える、
　ようにしてもよい。
　また、前記第２位置に到達する前のシンボルに対して前記画像から削除する操作を、当該シンボルに対応するコマンドの取消指示として受け付けるコマンド取消手段をさらに備える、
　ようにしてもよい。

　これにより、ユーザ（ゲームの場合プレイヤー）は、コマンドを入力した後に、別のコマンドを入力してコマンドの実行（発動）順番を変更したり、コマンドを削除したり等の編集操作が容易に可能になる。その結果として、ユーザにより一段とストレスを与えずかつ飽きさせることなく、予防的負荷分散処理を実現することが可能になる。

　１、１－１乃至１－ｍ・・・プレイヤー端末、２・・・サーバ、２１・・・ＣＰＵ、５１・・・ＣＰＵ、１０１・・・リクエスト受信制御部、１０２・・・負荷監視部、１０３・・・待ち時間演算部、１０４・・・リクエスト実行部、１０５・・・レスポンス送信制御部、１０６・・・不正監視部、１１１・・・待ち時間ＤＢ、１２１・・・コマンド受付部、１２２・・・待ち時間設定部、１２３・・・リクエスト送信制御部、１２４・・・表示制御部、１２５・・・レスポンス受信制御部、１２６・・・コマンド実行部

Claims (11)

1. 　サーバと、当該サーバに所定のリクエストを送信する複数の端末とを含む情報処理システムにおいて、
   　前記サーバは、
   　リクエストの処理に関する所定条件を満たしているか否かを監視する監視手段と、
   　前記所定条件を満たしていない場合、端末側でのリクエストの送信までの待ち時間を演算する待ち時間演算手段と、
   　リクエストを到達順に実行して、レスポンスを生成するリクエスト実行手段と、
   　前記レスポンスを、対応するリクエストを送信した端末に送信すると共に、前記待ち時間が演算されている場合には当該待ち時間を示す情報も併せて当該端末に送信する制御を実行する第１送信制御手段と、
   　を備え、
   　前記端末は、
   　所定のコマンドを受け付けるコマンド受付手段と、
   　前記サーバから前記待ち時間を示す情報が送信されてきた場合には、当該情報で特定される当該待ち時間を設定し、当該情報が送信されてきていない場合には、所定時間を待ち時間として設定する待ち時間設定手段と、
   　設定された前記待ち時間に応じて、前記端末側での時間の流れの速度を制御し、当該時間の流れの速度で変化する画像の表示を制御する表示制御手段と、
   　設定された前記待ち時間の経過後に、前記コマンドをリクエストとして前記サーバに送信する制御を実行する第２送信制御手段と、
   　を備える、
   　情報処理システム。
2. 　所定のリクエストを送信する複数の端末と通信をするサーバにおいて、
   　リクエストの処理に関する所定条件を満たしているか否かを監視する第１監視手段と、
   　前記所定条件を満たしていない場合、端末側での時間の流れの速度を制御する時間パラメータとして待ち時間を演算する待ち時間演算手段と、
   　リクエストを到達順に実行して、レスポンスを生成するリクエスト実行手段と、
   　前記レスポンスを、対応するリクエストを送信した端末に送信すると共に、前記待ち時間が演算されている場合には当該待ち時間を示す情報も併せて当該端末に送信する制御を実行する送信制御手段と、
   　を備えるサーバ。
3. 　前記待ち時間演算手段は、単位時間あたりに到達するリクエストの数と、当該単位時間あたりに処理可能なリクエストの数とに基づいて、前記待ち時間を演算する
   　請求項２に記載のサーバ。
4. 　前記複数の端末毎に、直前のリクエストの到達時刻、及び前記待ち時間を対応付けて管理する管理手段と、
   　リクエストが到達した際に、前記管理手段の管理内容に基づいて、当該リクエストを送信した前記端末が前記待ち時間を守ったか否かを監視する第２監視手段と、
   　を備える請求項２又は３に記載のサーバ。
5. 　所定のリクエストを送信する複数の端末と通信をするコンピュータに、
   　リクエストの処理に関する所定条件を満たしているか否かを監視する監視ステップと、
   　前記所定条件を満たしていない場合、端末側での時間の流れの速度を制御する時間パラメータとして待ち時間を演算する待ち時間演算ステップと、
   　リクエストを到達順に実行して、レスポンスを生成するリクエスト実行ステップと、
   　前記レスポンスを、対応するリクエストを送信した端末に送信すると共に、前記待ち時間が演算されている場合には当該待ち時間を示す情報も併せて当該端末に送信する制御を実行する送信制御ステップと、
   　を含む制御処理を実行させるプログラム。
6. 　リクエストに対するレスポンスを、当該リクエストを送信した端末に送信すると共に、所定条件を満たしている場合には次のリクエストの送信までの待ち時間を示す情報も併せて当該端末に送信するサーバとの間で通信をする端末において、
   　所定のコマンドを受け付けるコマンド受付手段と、
   　前記サーバから前記待ち時間を示す情報が送信されてきた場合には、当該情報で特定される当該待ち時間を設定し、当該情報が送信されてきていない場合には、所定時間を待ち時間として設定する待ち時間設定手段と、
   　設定された前記待ち時間に応じて、前記端末側での時間の流れの速度を制御し、当該時間の流れの速度で変化する画像の表示を制御する表示制御手段と、
   　設定された前記待ち時間の経過後に、前記コマンドをリクエストとして前記サーバに送信する制御を実行する送信制御手段と、
   　を備える端末。
7. 　前記表示制御手段は、
   　コマンドを示すシンボルを、第１位置から第２位置まで移動させる様子を示す画像を表示する制御として、
   　前記コマンドが受け付けられたときには前記シンボルを第１位置に配置させ、
   　設定された前記待ち時間で前記シンボルが前記第１位置から前記第２位置まで移動するように、前記シンボルの移動速度を決定し、
   　当該移動速度で前記シンボルを前記第２位置に向かって移動させる、
   　様子を示す画像を表示させる制御を実行し、
   　前記送信制御手段は、前記シンボルが前記第２位置に到達したときに、前記コマンドをリクエストとして前記サーバに送信する、
   　請求項６に記載の端末。
8. 　前記表示制御手段は、前記シンボルを、前記第１位置から前記第２位置を経由して第３位置まで移動させる様子を示す画像の表示を制御し、
   　前記シンボルが前記第３位置に到達したときに、前記コマンドに対応する前記サーバからの前記レスポンスに基づいて、当該コマンドに対応する処理を実行するコマンド実行手段をさらに備える、
   　請求項７に記載の端末。
9. 　前記コマンド受付手段は、複数のコマンドを順次受け付け、
   　前記表示制御手段は、前記複数のコマンドの夫々に対応する複数のシンボルを、コマンドの受付け順に、前記第１位置から第２位置まで夫々移動させる様子を示す画像を表示させ、
   　前記第２位置に到達する前のシンボルについては、他のシンボルとの順番を入れ替える操作を、当該シンボルに対応するコマンドの実行順番の変更指示として受け付けるコマンド順番変更手段をさらに備える、
   　請求項７又は８に記載の端末。
10. 　前記第２位置に到達する前のシンボルに対して前記画像から削除する操作を、当該シンボルに対応するコマンドの取消指示として受け付けるコマンド取消手段をさらに備える、
    　請求項７乃至９のうち何れか１項に記載の端末。
11. 　リクエストに対するレスポンスを、当該リクエストを送信した端末に送信すると共に、所定条件を満たしている場合には次のリクエストの送信までの待ち時間を示す情報も併せて当該端末に送信するサーバとの間で通信の制御をするコンピュータに、
    　所定のコマンドを受け付けるコマンド受付ステップと、
    　前記サーバから前記待ち時間を示す情報が送信されてきた場合には、当該情報で特定される当該待ち時間を設定し、当該情報が送信されてきていない場合には、所定時間を待ち時間として設定する待ち時間設定ステップと、
    　設定された前記待ち時間に応じて、前記端末側での時間の流れの速度を制御し、当該時間の流れの速度で変化する画像の表示を制御する表示制御ステップと、
    　設定された前記待ち時間の経過後に、前記コマンドをリクエストとして前記サーバに送信する制御を実行する送信制御ステップと、
    　を含む制御処理を実行させるプログラム。

Images