図面 (/)

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

出願人 株式会社Cygames
発明者 倉林修一
出願日 2015年5月22日 (5年7ヶ月経過) 出願番号 2015-104218
公開日 2016年12月22日 (4年0ヶ月経過) 公開番号 2016-214639
状態 特許登録済
技術分野 電子ゲーム機 デジタル計算機のユーザインターフェイス 計算機・データ通信
主要キーワード 待ち時間設定 ピクセル量 非同期入力 フレーム描画 ペナルティ処理 仮想待ち行列 可変時間 リクエストバッファ
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2016年12月22日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (12)

課題

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

解決手段

サーバ2の負荷監視部102は、リクエストの処理に関する所定条件を満たしているか否かを監視する。待ち時間演算部103は、所定条件を満たしていない場合、プレイヤー端末1側での時間の流れの速度を制御する時間パラメータとして待ち時間を演算する。リクエスト実行部104は、リクエストを到達順に実行して、レスポンスを生成する。レスポンス送信制御部105は、レスポンスを、対応するリクエストを送信したプレイヤー端末1に送信すると共に、待ち時間が演算されている場合には当該待ち時間を示す情報も併せてプレイヤー端末1に送信する制御を実行する。

概要

背景

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

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

概要

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

目的

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

効果

実績

技術文献被引用数
0件
牽制数
1件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

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

請求項2

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

請求項3

前記待ち時間演算手段は、単位時間あたりに到達するリクエストの数と、当該単位時間あたりに処理可能なリクエストの数とに基づいて、前記待ち時間を演算する請求項2に記載のサーバ。

請求項4

前記複数の端末毎に、直前のリクエストの到達時刻、及び前記待ち時間を対応付けて管理する管理手段と、リクエストが到達した際に、前記管理手段の管理内容に基づいて、当該リクエストを送信した前記端末が前記待ち時間を守ったか否かを監視する第2監視手段と、を備える請求項2又は3に記載のサーバ。

請求項5

所定のリクエストを送信する複数の端末と通信をするコンピュータに、リクエストの処理に関する所定条件を満たしているか否かを監視する監視ステップと、前記所定条件を満たしていない場合、端末側での時間の流れの速度を制御する時間パラメータとして待ち時間を演算する待ち時間演算ステップと、リクエストを到達順に実行して、レスポンスを生成するリクエスト実行ステップと、前記レスポンスを、対応するリクエストを送信した端末に送信すると共に、前記待ち時間が演算されている場合には当該待ち時間を示す情報も併せて当該端末に送信する制御を実行する送信制御ステップと、を含む制御処理を実行させるプログラム

請求項6

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

請求項7

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

請求項8

前記表示制御手段は、前記シンボルを、前記第1位置から前記第2位置を経由して第3位置まで移動させる様子を示す画像の表示を制御し、前記シンボルが前記第3位置に到達したときに、前記コマンドに対応する前記サーバからの前記レスポンスに基づいて、当該コマンドに対応する処理を実行するコマンド実行手段をさらに備える、請求項7に記載の端末。

請求項9

前記コマンド受付手段は、複数のコマンドを順次受け付け、前記表示制御手段は、前記複数のコマンドの夫々に対応する複数のシンボルを、コマンドの受付け順に、前記第1位置から第2位置まで夫々移動させる様子を示す画像を表示させ、前記第2位置に到達する前のシンボルについては、他のシンボルとの順番入れ替える操作を、当該シンボルに対応するコマンドの実行順番変更指示として受け付けるコマンド順番変更手段をさらに備える、請求項7又は8に記載の端末。

請求項10

前記第2位置に到達する前のシンボルに対して前記画像から削除する操作を、当該シンボルに対応するコマンドの取消指示として受け付けるコマンド取消手段をさらに備える、請求項7乃至9のうち何れか1項に記載の端末。

請求項11

リクエストに対するレスポンスを、当該リクエストを送信した端末に送信すると共に、所定条件を満たしている場合には次のリクエストの送信までの待ち時間を示す情報も併せて当該端末に送信するサーバとの間で通信の制御をするコンピュータに、所定のコマンドを受け付けるコマンド受付ステップと、前記サーバから前記待ち時間を示す情報が送信されてきた場合には、当該情報で特定される当該待ち時間を設定し、当該情報が送信されてきていない場合には、所定時間を待ち時間として設定する待ち時間設定ステップと、設定された前記待ち時間に応じて、前記端末側での時間の流れの速度を制御し、当該時間の流れの速度で変化する画像の表示を制御する表示制御ステップと、設定された前記待ち時間の経過後に、前記コマンドをリクエストとして前記サーバに送信する制御を実行する送信制御ステップと、を含む制御処理を実行させるプログラム。

技術分野

0001

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

背景技術

0002

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

0003

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

先行技術

0004

WO2014/098237パンフレット

発明が解決しようとする課題

0005

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

0006

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

0007

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

0008

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

0009

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

0010

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

0011

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

0012

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

課題を解決するための手段

0013

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

0014

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

0015

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

0016

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

0017

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

発明の効果

0018

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

図面の簡単な説明

0019

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

実施例

0020

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

0021

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

0022

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

0023

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

0024

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

0025

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

0026

プレイヤー端末1は、スマートフォン等で構成される。
プレイヤー端末1は、CPU(Central Processing Unit)21と、ROM(Read Only Memory)22と、RAM(Random Access Memory)23と、バス24と、入出力インターフェース25と、タッチ操作入力部26と、表示部27と、入力部28と、記憶部29と、通信部30と、ドライブ31と、を備えている。

0027

CPU21は、ROM22に記録されているプログラム、又は、記憶部29からRAM23にロードされたプログラムに従って各種の処理を実行する。
RAM23には、CPU21が各種の処理を実行する上において必要なデータ等も適宜記憶される。

0028

CPU21、ROM22及びRAM23は、バス24を介して相互に接続されている。このバス24にはまた、入出力インターフェース25も接続されている。入出力インターフェース25には、タッチ操作入力部26、表示部27、入力部28、記憶部29、通信部30及びドライブ31が接続されている。

0029

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

0030

入力部28は、各種ハードウェア釦等で構成され、プレイヤーの指示操作に応じて各種情報を入力する。
記憶部29は、DRAM(Dynamic Random Access Memory)等で構成され、各種データを記憶する。
通信部30は、インターネットを含むネットワークNを介して他の装置(図1の例ではサーバ2や他のプレイヤー端末1)との間で行う通信を制御する。

0031

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

0032

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

0033

サーバ2は、CPU51と、ROM52と、RAM53と、バス54と、入出力インターフェース55と、出力部56と、入力部57と、記憶部58と、通信部59と、ドライブ60とを備えている。
サーバ2の構成は、プレイヤー端末1のタッチパネルを除いた構成と基本的に同様であるので、ここではその説明は省略する。

0034

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

0035

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

0036

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

0037

図4に示すように、サーバ2のCPU51においては、リクエスト受信制御部101と、負荷監視部102と、待ち時間演算部103と、リクエスト実行部104と、レスポンス送信制御部105と、不正監視部106とが機能する。
サーバ2の記憶部58の一領域には、待ち時間DB111が設けられる。

0038

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

0039

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

0040

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

0041

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

0042

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

0043

図5の左側のリクエストバッファ201は、リクエスト処理用のバッファであり、サーバ2に実在する。例えば図4等には図示しないが、本実施形態では記憶部58にリクエストバッファ201が存在するものとする。
リクエストバッファ201内の黒丸印が、所定のプレイヤー端末1から送信されたサーバ2で受信済みのリクエストを示している。即ち、サーバ2側のリクエスト実行部104により実行中又は実行待ちのリクエストを示している。ここで、黒丸印内の符号は、リクエストを送信したプレイヤー端末1を示している。即ち、1Aの黒丸印は、プレイヤー端末1−Aから送信されたリクエストを示している。1Bの黒丸印は、プレイヤー端末1−Bから送信されたリクエストを示している。1Cの黒丸印は、プレイヤー端末1−Cから送信されたリクエストを示している。
リクエストバッファ201は、サーバ2に届いた順にリクエストを格納し、届いた順にリクエスト実行部104に出力して実行させるFIFOキューである。

0044

図5の右側の仮想待ち行列202は、サーバ2から複数のプレイヤー端末1(図5の例では説明の便宜上プレイヤー端末1−A,1−B,1−C)の夫々に待ち時間が通知されることにより、仮想的に構成される待ち行列である。
仮想待ち行列202内の白丸印が、所定のプレイヤー端末1から未送信のリクエストを示している。即ち、プレイヤー端末1側ではコマンドが入力されてから、待ち時間分だけ送信が遅延しているリクエストが、白丸印である。待ち時間が経過して送信可能になったリクエストには、「Delay−time expired」という記述が施されている。
即ち、この仮想待ち行列202は、サーバ2上のメモリ領域やディスク領域消費して構築されるものではなく、プレイヤー端末1の夫々が、サーバ2から通知された待ち時間が経過するまで、次のリクエストの送信を待つ動作により、実質的に、あたかもプレイヤー端末1の夫々が1つの行列内に並ぶようにふるまうことにより構成される。

0045

図5の例では、複数のプレイヤー端末1−A,1−B,1−Cの夫々に対して、待ち時間3000msecが設定されている。
リクエストの実行は、リクエストバッファ201の格納順である。換言すると、所定の1タイミングには、少なくとも1つのリクエストが実行される。また、各リクエスト同士に依存関係がない場合は、サーバ2は、リクエストバッファ201からの複数のリクエストを一時に取り出し、並列に実行してもよい。
例えば、仮想待ち行列202の上から2番目のリクエストは、プレイヤー端末1−Bにおいて待ち時間が経過したリクエストである。従って、当該リクエストは、プレイヤー端末1−Bからサーバ2に送信され、サーバ2のリクエストバッファ201に格納され、それより前に格納されたリクエストがリクエストバッファ201に存在しなくなった段階で、リクエスト実行部104により実行される。
このようにしてリクエスト実行部104により当該リクエスト(リクエストバッファ201の上から2番目のリクエスト)が実行されると、レスポンス送信制御部105は、レスポンスを、プレイヤー端末1—Bに送信すると共に、待ち時間の値「3000msec」も併せてプレイヤー端末1−Bに通知する。
このようにしてプレーヤー端末1−Bに通知された待ち時間の値は、リクエストが送信可能になるまでの残り時間という観点で、全てのプレイヤー端末1(図5の例ではプレイヤー端末1−A,1−B,1−C)の中で最大値となる。従って、仮想待ち行列202の最後尾図5の例では上から5番目の白丸印)に追加されることになる。

0046

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

0047

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

0048

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



・・・(1)
式(1)において、delay_secは待ち時間を示している。request_per_secは、1秒間にサーバ2に到達するリクエスト数を示している。capacity_per_secは、サーバ2に1秒間に処理可能なリクエスト数を示している。
即ち、本実施形態では、待ち時間(delay_sec)として、現在のリクエスト数(capacity_per_sec)をキャパシティ数(capacity_per_sec)で除算した値が採用されている。
このような値を採用することにより、単位時間内にキャパシティ数を超過するリクエストが到達することが予想される場合(負荷大となる場合)、超過分のリクエストは図5の仮想待ち行列202に格納されるので、図5を用いて上述したように、単位時間内に処理可能なリクエストのみがサーバに到達する、といった制御が実現される。

0049

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

0050

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

0051

複数のプレイヤー端末1(図5の例ではプレイヤー端末1−A,1−B,1−C)の夫々は、次のリクエストを送信する際には、通知された待ち時間の経過後に、サーバ2にアクセスする。

0052

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

0053

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

0054

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

0055

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

0056

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

0057

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

0058

図4に示すように、プレイヤー端末1のCPU21においては、コマンド受付部121と、待ち時間設定部122と、リクエスト送信制御部123と、表示制御部124と、レスポンス受信制御部125と、コマンド実行部126とが機能する。

0059

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

0060

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

0061

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

0062

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

0063

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

0064

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

0065

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

0066

図7は、本実施形態のゲーム画面の一例を示す図である。
図7のゲーム画面210の上方には、例えばRPG(Roll Playing Game)における戦闘画面221が表示される。
この戦闘画面221の下方に、プレイヤーがコマンドを選択するためのボタン(以下、「コマンド選択ボタン」と呼ぶ)が配置されたボタン群領域222が表示される。さらにその下方に、コマンドを示すアイコン(以下、「コマンドアイコン」と呼ぶ)があたかも一定方向に流れていくコマンドキュー223が表示される。

0067

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

0068

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

0069

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

0070

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

0071

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

0072

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

0073

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

0074

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

0075

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

0076

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

0077

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

0078

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

0079

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

0080

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

0081

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

0082

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

0083

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

0084

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

0085

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

0086

リクエストが無い場合には、ステップS4においてNOであると判定されて、処理はステップS9に進む。
ステップS9において、サーバ2のCPU51は、処理の終了指示が有ったか否かを判定する。ここで、処理の終了指示は、特に限定されないが、本実施形態ではサーバ2の電源遮断が採用されている。つまり、サーバ2において電源遮断されると、ステップS9においてYESであると判定されて、サーバ2側の処理は終了になる。
これに対して、サーバ2において電源が遮断されない限り、ステップS9においてNOであると判定されて処理はステップS1に戻され、それ以降の処理が繰り返される。

0087

ここで、複数のプレイヤー端末1(図1の例ではプレイヤー端末1−1乃至1−m)のうち所定の1台からリクエストが送信されると、ステップS4においてYESであると判定されて、処理はステップS5に進む。

0088

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

0089

即ち、不正監視部106は、待ち時間DB111に格納されたリスト(図9参照)から、リクエストに含まれるクライアントIDと対応付けられた待ち時間等を検索する。
その検索結果に基づいて特定される適正な時間よりも早いタイミングでリクエストが送信されてきた場合、不正であるとしてステップS5においてNOであると判定されて処理はステップ6に進む。
ステップS6において、不正監視部106は、リクエストを送信してきた不正なプレイヤー端末1に対して、ペナルティ処理を実行する。これにより、処理はステップS9に進み、それ以降の処理が繰り返される。
これに対して、リクエストの待ち時間が適正であれば、ステップS5においてYESであると判定されて、処理はステップS7に進む。
ステップS7において、リクエスト実行部104は、リクエストを実行し、レスポンスを生成する。
ステップS8において、レスポンス送信制御部105は、レスポンスと待ち時間をプレイヤー端末1に送信する。
その後処理はステップS9に進み、それ以降の処理が繰り返される。

0090

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

0091

ステップS21において、表示制御部124は、コマンド選択用UI、キューを含むゲーム画面を表示部27に表示させる。
ここで、コマンド選択用UIとは、例えば上述の図7乃至図9で説明したコマンド選択ボタンが配置されたボタン群領域222が該当する。キューとは、例えばコマンドキュー223が該当する。

0092

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

0093

コマンドが入力されていない場合、ステップS22においてNOであると判定されて、処理はステップS34に進む。
ステップS34において、プレイヤー端末1のCPU21は、処理の終了指示が有ったか否かを判定する。ここで、処理の終了指示は、特に限定されないが、本実施形態では上記所定のイベント(例えば先頭のイベント等)の終了の指示が採用されている。つまり、所定のイベントが終了すると、ステップS34においてYESであると判定されて、プレイヤー端末1側の処理は終了になる。
これに対して、所定のイベントが継続中である場合、ステップS34においてNOであると判定されて処理はステップS21に戻され、それ以降の処理が繰り返される。

0094

所定のコマンド選択ボタンがタップ操作されて、対応するコマンドがコマンド受付部121により受け付けられると、ステップS22においてYESであると判定されて処理はステップS23に進む。
ステップS23において、待ち時間設定部122は、サーバ2から待ち時間が通知済みか否かを判定する。
サーバ2から待ち時間が未通知の場合(図10のステップS3で待ち時間が0に設定された場合も含む)、ステップS23においてNOであると判定されて、処理はステップS24に進む。
ステップS24において、待ち時間設定部122は、規定の待ち時間を設定する。ここで、規定の待ち時間とは、プレイヤー端末1側での時間の流れの速度についての「基準速度」を示す時間パラメータである。このようなステップS24の処理が終了すると、処理はステップS26に進む。
これに対して、待ち時間が通知済みの場合(前回のステップS32において受信されたレスポンスに対して、待ち時間を示す情報が付加されていた場合)、ステップS23においてYESであると判定されて、処理はステップS25に進む。
ステップS25において、待ち時間設定部122は、サーバ2からの待ち時間を設定する。ここで、サーバ2からの待ち時間とは、上述したように、プレイヤー端末1側での時間の流れの速度を基準速度に対して変更するための時間パラメータであって、サーバ2により設定される時間パラメータである。このようなステップS25の処理が終了すると、処理はステップS26に進む。

0095

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

0096

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

0097

ステップS28において、コマンド受付部121は、コマンドアイコンの操作が有ったか否かを判定する。
コマンドアイコンに対するドラッグ操作等が有った場合、ステップS28においてYESであると判定されて、処理はステップS29に進む。
ステップS29において、表示制御部124は、コマンドを削除したり順番を変更等する編集処理を実行する。これにより、処理はステップS30に進む。
これに対して、コマンドアイコンに対するドラッグ操作等が無かった場合、ステップS28においてNOであると判定されて、コマンドの編集処理(ステップS29の処理)は実行されずに、処理はステップS30に進む。

0098

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

0099

待ち時間が経過すると、ステップS30においてYESであると判定されて、処理はステップS31に進む。
ステップS31において、リクエスト送信制御部123は、コマンドをリクエストとしてサーバ2に送信する。
これにより、図10のステップS4においてYESであると判定されて、不正なリクエストでない限り、ステップS8においてレスポンスと待ち時間がプレイヤー端末1に送信されてくる。
ステップS32において、レスポンス受信制御部125は、レスポンスと待ち時間を受信する。
ステップS33において、コマンド実行部126は、コマンドを実行する。
これにより、処理はステップS34に進み、それ以降の処理が繰り返される。

0100

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

0101

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

0102

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

0103

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

0104

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

0105

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

0106

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

0107

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

0108

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

0109

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

0110

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

0111

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

0112

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

0113

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

0114

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

0115

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

0116

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

0117

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

0118

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

0119

1、1−1乃至1−m・・・プレイヤー端末、2・・・サーバ、21・・・CPU、51・・・CPU、101・・・リクエスト受信制御部、102・・・負荷監視部、103・・・待ち時間演算部、104・・・リクエスト実行部、105・・・レスポンス送信制御部、106・・・不正監視部、111・・・待ち時間DB、121・・・コマンド受付部、122・・・待ち時間設定部、123・・・リクエスト送信制御部、124・・・表示制御部、125・・・レスポンス受信制御部、126・・・コマンド実行部

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

  • 京セラ株式会社の「 電子機器、制御方法、及びプログラム」が 公開されました。( 2020/10/29)

    【課題】操作性を向上させた電子機器、制御方法、及びプログラムを提供する。【解決手段】電子機器1は、自機器に接触されないジェスチャを検出する第1センサ(近接センサ18)と、自機器に接触されるタッチを検出... 詳細

  • 温州根旭電子科技有限公司の「 正答なら奨励するデジタルおもちゃ」が 公開されました。( 2020/10/29)

    【課題】本発明は正答なら奨励するデジタルおもちゃを開示した。【解決手段】主体を含み、前記主体の前端面の上側にはディスプレイ画面が固定的に設置され、前記主体の前端面の下側にはキーボードが固定的に設置され... 詳細

  • クリスタルメソッド株式会社の「 推定システム、及び推定装置」が 公開されました。( 2020/10/29)

    【課題】キー入力を推定する精度の向上を図ることができる推定システム、及び推定装置を提供する。【解決手段】仮想キーボードを用いて入力された文字列を推定する推定システムであって、ユーザが前記仮想キーボード... 詳細

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ