(57)【特許請求の範囲】
【請求項１】
クラウド側サーバと、エッジ側サーバと、プレイヤ端末とを備え、
前記エッジ側サーバは、
複数の前記プレイヤ端末各々が送信した同一対象に対するアクションのリクエストを受信するエッジ受信部と、
複数の前記プレイヤ端末各々が送信した前記リクエスト各々に基づく処理を実行し、所定期間内に受信された前記リクエスト各々に基づく処理の結果を集約した集約結果を算出し、前記集約結果を前記リクエストに対する第１のレスポンスとして複数の前記プレイヤ端末各々に送信する第１のエッジ処理部と、
一定期間ごとに、前記集約結果を前記クラウド側サーバに送信し、前記クラウド側サーバで実行された前記集約結果に基づく処理の結果を受信し、前記集約結果に基づく処理の結果を前記リクエストに対する第２のレスポンスとして前記プレイヤ端末に送信する第２のエッジ処理部と、
を有し、
前記クラウド側サーバは、
前記エッジ側サーバが送信した前記集約結果を受信するクラウド受信部と、
前記集約結果に基づく処理を実行し、前記集約結果に基づく処理の結果を前記エッジ側サーバに送信するクラウド処理部と、
を有し、
前記プレイヤ端末は、
前記リクエストを送信し、１つの前記リクエストに対し、非同期Ｉ／Ｏで前記第１のレスポンス及び前記第２のレスポンスをこの順に前記エッジ側サーバから受信する端末送受信部と、
を有するゲームシステム。
【請求項２】
前記プレイヤ端末は、
前記第１のレスポンスを受信すると前記第１のレスポンスに対応する第１の表示を行い、前記第２のレスポンスを受信すると前記第２のレスポンスに対応する第２の表示を行い、
前記第１の表示が終了する前に前記第２の表示を開始する請求項１に記載のゲームシステム。
【請求項３】
複数の前記プレイヤ端末各々は、複数の前記エッジ側サーバの中のいずれか１つと通信し、
前記エッジ受信部は、自エッジ側サーバと通信する複数の前記プレイヤ端末各々が送信した複数の前記リクエストを受信し、
前記第２のエッジ処理部は、自エッジ側サーバと通信する複数の前記プレイヤ端末各々が送信した複数の前記リクエストに基づく処理の結果を集約した並列的に受信したリクエストの暫定的集約結果を算出し、前記並列的に受信したリクエストの暫定的集約結果を前記クラウド側サーバに送信し、
前記クラウド受信部は、複数の前記エッジ側サーバ各々から、前記並列的に受信したリクエストの暫定的集約結果を受信し、
前記クラウド処理部は、複数の前記並列的に受信したリクエストの暫定的集約結果を集約して並列的に受信したリクエストの最終的集約結果を算出し、前記並列的に受信したリクエストの最終的集約結果を複数の前記エッジ側サーバに送信し、
前記第２のエッジ処理部は、受信した前記並列的に受信したリクエストの最終的集約結果を前記第２のレスポンスとして自エッジ側サーバと通信する複数の前記プレイヤ端末に送信する請求項１又は２に記載のゲームシステム。
【請求項４】
前記リクエストは、敵キャラクタに対する攻撃内容を示す攻撃リクエストであり、
前記エッジ側サーバ各々が算出する前記並列的に受信したリクエストの暫定的集約結果は、前記エッジ側サーバ各々と通信する複数の前記プレイヤ端末が送信した複数の前記攻撃リクエストに基づき算出された前記敵キャラクタに与えたダメージ値であり、
前記並列的に受信したリクエストの最終的集約結果は、前記エッジ側サーバ各々が算出した前記並列的に受信したリクエストの暫定的集約結果各々が示す前記敵キャラクタに与えたダメージ値の合計である請求項３に記載のゲームシステム。
【請求項５】
前記エッジ受信部は、１つの前記プレイヤ端末が時間差で送信した複数の前記リクエストを受信し、
前記第２のエッジ処理部は、１つの前記プレイヤ端末が時間差で送信した複数の前記リクエストに基づく処理の結果を集約した連続的に受信したリクエストの暫定的集約結果を算出し、前記連続的に受信したリクエストの暫定的集約結果を前記クラウド側サーバに送信し、
前記クラウド処理部は、前記連続的に受信したリクエストの暫定的集約結果に基づく処理を実行し、前記連続的に受信したリクエストの暫定的集約結果に基づく処理の結果を前記エッジ側サーバに送信する請求項１又は２に記載のゲームシステム。
【請求項６】
クラウド側サーバと、エッジ側サーバと、プレイヤ端末とを備え、
前記エッジ側サーバは、
前記プレイヤ端末が送信したリクエストを受信するエッジ受信部と、
前記リクエストに基づく処理を実行し、前記リクエストに基づく処理の結果を前記リクエストに対する第１のレスポンスとして前記プレイヤ端末に送信する第１のエッジ処理部と、
一定期間ごとに、前記リクエストに基づく処理の結果を集約した集約結果を前記クラウド側サーバに送信し、前記クラウド側サーバで実行された前記集約結果に基づく処理の結果を受信し、前記集約結果に基づく処理の結果を前記リクエストに対する第２のレスポンスとして前記プレイヤ端末に送信する第２のエッジ処理部と、
を有し、
前記クラウド側サーバは、
前記エッジ側サーバが送信した前記集約結果を受信するクラウド受信部と、
前記集約結果に基づく処理を実行し、前記集約結果に基づく処理の結果を前記エッジ側サーバに送信するクラウド処理部と、
を有し、
前記プレイヤ端末は、
前記リクエストを送信し、１つの前記リクエストに対し、非同期Ｉ／Ｏで前記第１のレスポンス及び前記第２のレスポンスをこの順に前記エッジ側サーバから受信する端末送受信部と、
を有し、
前記リクエストは、前記プレイヤ端末が管理している管理情報をサーバ側で保存する同期リクエストであり、
前記エッジ受信部は、所定時間Ｔ１毎に最新の前記管理情報及び前記同期リクエストを受信し、
前記第１のエッジ処理部は、受信された前記管理情報をエッジ記憶装置に記憶させる処理を実行し、処理に成功した旨を前記第１のレスポンスとして前記プレイヤ端末に送信し、
前記第２のエッジ処理部は、所定時間Ｔ２毎に（Ｔ２はＴ１より大）、前記エッジ記憶装置に記憶されている最新の前記管理情報を、連続的に受信したリクエストの暫定的集約結果として前記クラウド側サーバに送信し、
前記クラウド処理部は、前記連続的に受信したリクエストの暫定的集約結果として受信された前記管理情報をクラウド記憶装置に記憶させる処理を実行し、処理に成功した旨を前記連続的に受信したリクエストの暫定的集約結果に基づく処理の結果として前記エッジ側サーバに送信するゲームシステム。
【請求項７】
クラウド側サーバと、エッジ側サーバと、プレイヤ端末とを備えるゲームシステムが実行するゲーム制御方法であって、
前記エッジ側サーバは、
複数の前記プレイヤ端末各々が送信した同一対象に対するアクションのリクエストを受信し、
複数の前記プレイヤ端末各々が送信した前記リクエスト各々に基づく処理を実行し、同一期間内に受信された前記リクエスト各々に基づく処理の結果を集約した集約結果を算出し、前記集約結果を前記リクエストに対する第１のレスポンスとして複数の前記プレイヤ端末各々に送信し、
一定期間ごとに、前記集約結果を前記クラウド側サーバに送信し、前記クラウド側サーバで実行された前記集約結果に基づく処理の結果を受信し、前記集約結果に基づく処理の結果を前記リクエストに対する第２のレスポンスとして前記プレイヤ端末に送信し、
前記クラウド側サーバは、
前記エッジ側サーバが送信した前記集約結果を受信し、
前記集約結果に基づく処理を実行し、前記集約結果に基づく処理の結果を前記エッジ側サーバに送信し、
前記プレイヤ端末は、
前記リクエストを送信し、１つの前記リクエストに対し、非同期Ｉ／Ｏで前記第１のレスポンス及び前記第２のレスポンスをこの順に前記エッジ側サーバから受信するゲーム制御方法。
【請求項８】
クラウド側サーバと、エッジ側サーバと、プレイヤ端末とを備えるゲームシステムが実行するゲーム制御方法であって、
前記エッチ側サーバは、
前記プレイヤ端末が送信したリクエストを受信するエッジ受信工程と、
前記リクエストに基づく処理を実行し、前記リクエストに基づく処理の結果を前記リクエストに対する第１のレスポンスとして前記プレイヤ端末に送信する第１のエッジ処理工程と、
一定期間ごとに、前記リクエストに基づく処理の結果を集約した集約結果を前記クラウド側サーバに送信し、前記クラウド側サーバで実行された前記集約結果に基づく処理の結果を受信し、前記集約結果に基づく処理の結果を前記リクエストに対する第２のレスポンスとして前記プレイヤ端末に送信する第２のエッジ処理工程と、
を実行し、
前記クラウド側サーバは、
前記エッジ側サーバが送信した前記集約結果を受信するクラウド受信工程と、
前記集約結果に基づく処理を実行し、前記集約結果に基づく処理の結果を前記エッジ側サーバに送信するクラウド処理工程と、
を実行し、
前記プレイヤ端末は、
前記リクエストを送信し、１つの前記リクエストに対し、非同期Ｉ／Ｏで前記第１のレスポンス及び前記第２のレスポンスをこの順に前記エッジ側サーバから受信する端末送受信工程を実行し、
前記リクエストは、前記プレイヤ端末が管理している管理情報をサーバ側で保存する同期リクエストであり、
前記エッチ側サーバは、
前記エッジ受信工程では、所定時間Ｔ１毎に最新の前記管理情報及び前記同期リクエストを受信し、
前記第１のエッジ処理工程では、受信された前記管理情報をエッジ記憶装置に記憶させる処理を実行し、処理に成功した旨を前記第１のレスポンスとして前記プレイヤ端末に送信し、
前記第２のエッジ処理工程では、所定時間Ｔ２毎に（Ｔ２はＴ１より大）、前記エッジ記憶装置に記憶されている最新の前記管理情報を、連続的に受信したリクエストの暫定的集約結果として前記クラウド側サーバに送信し、
前記クラウド側サーバは、
前記クラウド処理工程では、前記連続的に受信したリクエストの暫定的集約結果として受信された前記管理情報をクラウド記憶装置に記憶させる処理を実行し、処理に成功した旨を前記連続的に受信したリクエストの暫定的集約結果に基づく処理の結果として前記エッジ側サーバに送信するゲーム制御方法。
【請求項９】
請求項１から６のいずれか１項に記載のゲームシステムのエッジ側サーバ。
【請求項１０】
請求項１から６のいずれか１項に記載のゲームシステムのクラウド側サーバ。
【請求項１１】
請求項１から６のいずれか１項に記載のゲームシステムのプレイヤ端末。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ゲームシステム、エッジ側サーバ、クラウド側サーバ、ゲーム端末及びゲーム制御方法に関する。
【背景技術】
【０００２】
次世代のモバイルネットワークである５Ｇでは、単にラストワンマイルの広帯域化に止まらず、インターネットの外側にサーバを設置可能になるというネットワークアーキテクチャの大規模な変更が行われる。関連する技術として、ＭＥＣ（Multi-access Edge Computing）が知られている。従来のクラウドコンピューティングが、クラウド側に大量のサーバを分散配置するという水平方向の分散（Horizontal Distribution）であることとの比較において、このＭＥＣの最大の特徴は、ネットワークの経路上に計算能力を持ったサーバを分散配置するという垂直方向の分散（Vertical Distribution）により、わずか数ミリ秒ほどの低遅延で、エッジサイドのサーバとクライアントとが通信できるようになる点にある。
【０００３】
関連する技術が、非特許文献１及び２に開示されている。非特許文献１は、５Ｇネットワーク及びＭＥＣについて説明するとともに、ＭＥＣのアプリケーション例としてゲームを提案していている。非特許文献２は、５Ｇネットワークのエッジにある通信プロバイダのデータセンターにエッジサイドのサーバを組み込み、ゲーム、ライブ動画ストリーミング、エッジでの機械学習推論、拡張現実やバーチャルリアリティなどにおいて、低遅延を実現できることを開示している。
【０００４】
その他、非特許文献３は、ＨＴＴＰのセッションをつないだままにするＣｏｍｅｔに関する内容を開示している。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】日本仮想化技術株式会社、"hbstudy#88  ５Ｇ＋ＭＥＣ時代のシステム設計"、［online］、２０２０年１月１７日、［２０２０年７月２０日検索］、インターネット＜URL: https://www.slideshare.net/VirtualTech-JP/hbstudy88-5gmec＞
【非特許文献２】Amazon Web Services, Inc. "AWS Wavelength"、［online］、［２０２０年７月２０日検索］、インターネット＜URL: https://aws.amazon.com/jp/wavelength/＞
【非特許文献３】"Comet: Low Latency Data for the Browser"、２００６年３月３日、［２０２０年７月２０日検索］、インターネット＜URL: https://infrequently.org/2006/03/comet-low-latency-data-for-the-browser/＞
【発明の概要】
【発明が解決しようとする課題】
【０００６】
非特許文献１及び２はいずれも、ＭＥＣの利用ケースとしてゲームを提案しているものの、その詳細な技術は開示していない。本発明の課題は、従来よりもはるかに高いレベルのゲームサービスのスケーラビリティ（多接続化）とレスポンス性能（低遅延化）を同時に達成することである。
【課題を解決するための手段】
【０００７】
本発明によれば、
クラウド側サーバと、エッジ側サーバと、プレイヤ端末とを備え、
前記エッジ側サーバは、
複数の前記プレイヤ端末各々が送信した同一対象に対するアクションのリクエストを受信するエッジ受信部と、
複数の前記プレイヤ端末各々が送信した前記リクエスト各々に基づく処理を実行し、所定期間内に受信された前記リクエスト各々に基づく処理の結果を集約した集約結果を算出し、前記集約結果を前記リクエストに対する第１のレスポンスとして複数の前記プレイヤ端末各々に送信する第１のエッジ処理部と、
一定期間ごとに、前記集約結果を前記クラウド側サーバに送信し、前記クラウド側サーバで実行された前記集約結果に基づく処理の結果を受信し、前記集約結果に基づく処理の結果を前記リクエストに対する第２のレスポンスとして前記プレイヤ端末に送信する第２のエッジ処理部と、
を有し、
前記クラウド側サーバは、
前記エッジ側サーバが送信した前記集約結果を受信するクラウド受信部と、
前記集約結果に基づく処理を実行し、前記集約結果に基づく処理の結果を前記エッジ側サーバに送信するクラウド処理部と、
を有し、
前記プレイヤ端末は、
前記リクエストを送信し、１つの前記リクエストに対し、非同期Ｉ／Ｏで前記第１のレスポンス及び前記第２のレスポンスをこの順に前記エッジ側サーバから受信する端末送受信部と、
を有するゲームシステムが提供される。
【０００８】
また、本発明によれば、
クラウド側サーバと、エッジ側サーバと、プレイヤ端末とを備えるゲームシステムが実行するゲーム制御方法であって、
前記エッジ側サーバは、
複数の前記プレイヤ端末各々が送信した同一対象に対するアクションのリクエストを受信し、
複数の前記プレイヤ端末各々が送信した前記リクエスト各々に基づく処理を実行し、同一期間内に受信された前記リクエスト各々に基づく処理の結果を集約した集約結果を算出し、前記集約結果を前記リクエストに対する第１のレスポンスとして複数の前記プレイヤ端末各々に送信し、
一定期間ごとに、前記集約結果を前記クラウド側サーバに送信し、前記クラウド側サーバで実行された前記集約結果に基づく処理の結果を受信し、前記集約結果に基づく処理の結果を前記リクエストに対する第２のレスポンスとして前記プレイヤ端末に送信し、
前記クラウド側サーバは、
前記エッジ側サーバが送信した前記集約結果を受信し、
前記集約結果に基づく処理を実行し、前記集約結果に基づく処理の結果を前記エッジ側サーバに送信し、
前記プレイヤ端末は、
前記リクエストを送信し、１つの前記リクエストに対し、非同期Ｉ／Ｏで前記第１のレスポンス及び前記第２のレスポンスをこの順に前記エッジ側サーバから受信するゲーム制御方法が提供される。
【０００９】
また、本発明によれば、前記ゲームシステムのエッジ側サーバが提供される。
【００１０】
また、本発明によれば、前記ゲームシステムのクラウド側サーバが提供される。
【００１１】
また、本発明によれば、前記ゲームシステムのプレイヤ端末が提供される。
【発明の効果】
【００１２】
本発明によれば、従来よりもはるかに高いレベルのゲームサービスのスケーラビリティ（多接続化）とレスポンス性能（低遅延化）を同時に達成することができる。
【図面の簡単な説明】
【００１３】
【図１】本実施形態のゲームシステムの全体像を説明するための図である。
【図２】本実施形態のゲームシステムの全体像を説明するための図である。
【図３】本実施形態のプレイヤ端末の機能ブロックの一例を示す図である。
【図４】本実施形態のエッジ側サーバの機能ブロックの一例を示す図である。
【図５】本実施形態のクラウド側サーバの機能ブロックの一例を示す図である。
【図６】本実施形態のゲームシステムの処理の流れの一例を示すシーケンス図である。
【図７】本実施形態のゲームシステムで実現される第１の表示の一例を示す図である。
【図８】本実施形態のゲームシステムで実現される第１の表示の一例を示す図である。
【図９】本実施形態のゲームシステムで実現される第２の表示の一例を示す図である。
【図１０】本実施形態の装置のハードウエア構成の一例を示す図である。
【図１１】本実施形態のゲームシステムの実施例を説明するための図である。
【図１２】本実施形態のゲームシステムの処理の流れの一例を示すシーケンス図である。
【発明を実施するための形態】
【００１４】
＜第１の実施形態＞
「概要」
本実施形態は、５Ｇ＋ＭＥＣという新しいエッジコンピューティング・インフラストラクチャの普及を捉えて、ネットワークの経路上に計算能力を持ったサーバを分散配置するという垂直方向の分散に適した、新たなＷｅｂＡＰＩの実装方式を提案するものである。従来のクラウドコンピューティングは、クラウド側に大量のサーバを分散配置するという水平方向の分散であったため、外部に露出するＷｅｂＡＰＩは、呼び出された後に可能な限り速やかにレスポンスを返すという、極めてシンプルなものであった。本実施形態の技術的特徴は、１つのＷｅｂＡＰＩを多数のクライアントが呼び出す時に、エッジ側サーバは暫定的なレスポンスを即座に（数ミリ秒で）クライアントに返しつつ、受信した複数のリクエストを集約してクラウド上の同一ＷｅｂＡＰＩを呼び出し、クラウド側サーバから得られる最終的な演算結果をその後で（数百ミリ秒後に）追加的に返すという、漸進的な応答を行う点にある。このような、集約的なリクエストのハンドリング（Aggregative Request Handling）と漸進的な応答（Progressive Response）により、サービスのスケーラビリティとレスポンス性能を同時に達成する。
【００１５】
本実施形態によるＷｅｂＡＰＩを呼び出すクライアントは、１つのＷｅｂＡＰＩを非同期処理で読み込むだけで、エッジ側サーバの局所的な情報を反映した即時的なレスポンスをまずは受け取り、その後にクラウド側サーバの大局的かつ確定的なレスポンスを追加的に受け取ることができる。また、クライアントは非同期Ｉ／Ｏで上記２つのレスポンスを受信するので、エッジ側サーバからのレスポンスに応じたエフェクトをアニメーションなどで描画している間に、クラウド側サーバからのレスポンスを受信することができる。このようにエッジ側サーバからの迅速なレスポンスに対応した第１の画面表示を行っている間に、クラウド側サーバからのレスポンスを受信し、上記第１の画面表示に繋げてシームレスに、クラウド側サーバからのレスポンスに対応した第２の画面表示を行うことで、プレイヤから見た時には、あたかもエッジ側サーバからのレスポンスのスピードで、クラウド側サーバからのレスポンスを受け取って画面表示されているように感じられる（すなわち、通信遅延を感じない）、という効果が得られる。
【００１６】
「全体像」
次に、本実施形態のゲームシステムの全体像を説明する。図１に示すように、ゲームシステムは、クラウド側サーバ１０と、複数のエッジ側サーバ２０と、複数のプレイヤ端末３０とを有する。
【００１７】
プレイヤ端末３０は、プレイヤが操作するモバイル端末であり、スマートフォン、タブレット端末、パーソナルコンピュータ、ゲーム機、スマートウォッチ、携帯電話等が例示されるが、これらに限定されない。エッジ側サーバ２０は、いわゆるＭＥＣサーバである。クラウド側サーバ１０は、クラウド側に設置されるサーバである。
【００１８】
図２に示すように、プレイヤ端末３０とクラウド側サーバ１０とは、モバイルネットワーク７０及びインターネット６０経由で通信する。モバイルネットワーク７０は、５Ｇネットワークである。モバイルネットワーク７０は、基地局７１、コア網７２及びインターネットゲートウェイ７３等を含む。図２から明らかなように、本実施形態のインターネット６０は、プレイヤ端末３０が繋がっているモバイルネットワーク７０を含まない概念である。
【００１９】
図２中に示していないが、エッジ側サーバ２０は、モバイルネットワーク７０内に位置する。そして、プレイヤ端末３０とエッジ側サーバ２０とは、インターネット６０を経由せずに通信する。エッジ側サーバ２０の設置位置は特段制限されないが、通信事業者の基地局７１内やコア網７２の設備内が例示される。
【００２０】
図１に示すように、複数のプレイヤ端末３０各々は、複数のエッジ側サーバ２０の中のいずれか１つと通信する。これは、複数のプレイヤ端末３０各々は、同時に複数のエッジ側サーバ２０と通信しないことを意味する。例えば、プレイヤ端末３０の位置の変更に応じて、そのプレイヤ端末３０の通信相手となるエッジ側サーバ２０は変更し得る。各プレイヤ端末３０は、例えば、自端末が繋がった基地局７１に設置されているエッジ側サーバ２０と通信する。
【００２１】
「機能構成」
次に、図３乃至図６を用いて、ゲームシステムの機能構成を説明する。
【００２２】
図３は、プレイヤ端末３０の機能ブロック図の一例を示す。図示するように、プレイヤ端末３０は、入力部３１と、出力部３２と、処理部３３と、記憶部３４と、端末送受信部３５とを有する。
【００２３】
これらの機能部により、プレイヤから入力を受付ける機能、入力内容に基づくリクエストをサーバに送信する機能、リクエストに対するレスポンスをサーバから受信する機能、受信したレスポンスに応じた画面表示を行う機能等が実現される。
【００２４】
図４は、エッジ側サーバ２０の機能ブロック図の一例を示す。図示するように、エッジ側サーバ２０は、エッジ受信部２１と、第１のエッジ処理部２２と、第２のエッジ処理部２３と、記憶部２４とを有する。
【００２５】
これらの機能部により、自装置（エッジ側サーバ２０）と通信するプレイヤ端末３０が送信したリクエストを受信する機能、プレイヤ端末３０から受信したリクエストに基づく処理の結果を暫定的な処理の結果としてプレイヤ端末３０に返信する機能、プレイヤ端末３０から受信したリクエストに基づく処理の結果を集約した集約結果をクラウド側サーバ１０に送信する機能、集約結果に基づく最終的な処理の結果をクラウド側サーバ１０から受信し、プレイヤ端末３０に返信する機能等が実現される。
【００２６】
図５は、クラウド側サーバ１０の機能ブロック図の一例を示す。図示するように、クラウド側サーバ１０は、クラウド受信部１１と、クラウド処理部１２と、記憶部１３とを有する。
【００２７】
これらの機能部により、複数のエッジ側サーバ２０各々から上記集約結果を受信する機能、複数のエッジ側サーバ２０各々から受信した複数の集約結果に基づく最終的な処理の結果を算出する機能、算出した最終的な処理の結果をエッジ側サーバ２０に送信する機能等が実現される。
【００２８】
図６は、ゲームシステムの処理の流れの一例を示すシーケンス図である。より詳細には、ゲーム進行中の任意のタイミングで複数のプレイヤが各プレイヤ端末３０に所定の操作（例：攻撃）を行ってから、当該操作に応じた画面表示がプレイヤ端末３０においてなされるまでの比較的短い時間の中で行われる処理の流れを示す。以下、処理の流れとともに、図３乃至図５に示す各機能部の機能構成を詳細に説明する。
【００２９】
前提として、本実施形態のゲームシステムが提供するゲームは、多数のプレイヤが同時に参加し、各プレイヤの操作が他のプレイヤのゲーム進行に影響するものである。例えば、ＭＭＯＲＰＧ（Massively Multiplayer Online Role-Playing Game）のレイドバトル等が例示されるが、これに限定されない。
【００３０】
図６では、複数の第１のプレイヤ端末３０、第１のエッジ側サーバ２０、複数の第ｍのプレイヤ端末３０、第ｍのエッジ側サーバ２０及びクラウド側サーバ１０が示されている。
【００３１】
複数の第１のプレイヤ端末３０は、ゲームに参加している複数のプレイヤの中の一部のプレイヤが操作するプレイヤ端末３０である。複数の第１のプレイヤ端末３０は、同じエッジ側サーバ２０（第１のエッジ側サーバ２０）と通信する点で共通する。例えば、複数の第１のプレイヤ端末３０は、同じ基地局に繋がっている。そして、第１のエッジ側サーバ２０は、例えば、複数の第１のプレイヤ端末３０が繋がっている基地局内に設置されている。
【００３２】
複数の第ｍのプレイヤ端末３０も同様に、ゲームに参加している複数のプレイヤの中の一部のプレイヤが操作するプレイヤ端末３０である。複数の第ｍのプレイヤ端末３０は、同じエッジ側サーバ２０（第ｍのエッジ側サーバ２０）と通信する点で共通する。例えば、複数の第ｍのプレイヤ端末３０は、同じ基地局に繋がっている。そして、第ｍのエッジ側サーバ２０は、例えば、複数の第ｍのプレイヤ端末３０が繋がっている基地局内に設置されている。
【００３３】
なお、図では、２つのエッジ側サーバ２０と、２組の複数のプレイヤ端末３０が示されているが、これらの数は図示するものに限定されない。
【００３４】
まず、複数の第１のプレイヤ端末３０の各々は、プレイヤからの入力に基づき生成されたリクエストをサーバに送信する（Ｓ１０１）。複数の第１のプレイヤ端末３０が送信したリクエストは、第１のエッジ側サーバ２０に受信される。
【００３５】
Ｓ１０１の処理に関連して、入力部３１は、タッチパネル、物理ボタン、マイク、キーボード、マウス等の任意の入力装置を介してプレイヤからの操作を受付ける。例えば、敵キャラクタに攻撃する操作や、防御する操作等を受付ける。処理部３３は、入力された内容を示すリクエスト（攻撃リクエストや防御リクエスト等）を生成する。端末送受信部３５は所定のＷｅｂＡＰＩを呼び出し、生成されたリクエストを送信する。
【００３６】
第１のエッジ側サーバ２０は、複数の第１のプレイヤ端末３０が送信したリクエストを受信すると（Ｓ１０１）、受信した複数のリクエストに基づく処理を実行し（Ｓ１０２）、リクエストに基づく処理の結果をリクエストに対する第１のレスポンスとして複数の第１のプレイヤ端末３０に送信する（Ｓ１０３）。Ｓ１０１のリクエストの受信はエッジ受信部２１により実現される。Ｓ１０２及びＳ１０３の処理は第１のエッジ処理部２２により実現される。
【００３７】
第１のエッジ処理部２２は、ゲームに参加している複数のプレイヤの中の一部（複数の第１のプレイヤ端末３０を操作するプレイヤ）に関連するデータを用いて、局所的に一貫性のある処理結果を算出する。
【００３８】
例えば、第１のエッジ処理部２２は、複数の第１のプレイヤ端末３０各々が送信した攻撃リクエストに基づく結果（敵キャラクタのダメージの有無やダメージ量等）を算出し、その後、その複数の攻撃リクエストの結果を集約した集約結果（その複数の攻撃リクエストで敵キャラクタに与えた総ダメージ量等）を算出する。そして、第１のエッジ処理部２２は、その複数の攻撃リクエストの結果を集約した集約結果（その複数の攻撃リクエストによる敵キャラクタのダメージの有無や敵キャラクタに与えた総ダメージ量等）を、第１のレスポンスとして複数の第１のプレイヤ端末３０に送信する。
【００３９】
また、第２のエッジ処理部２３は、一定期間ごとに、上記複数の第１のプレイヤ端末３０各々が送信したリクエストに基づく処理の結果を集約した集約結果を、クラウド側サーバ１０に送信する（Ｓ１０５）。
【００４０】
なお、各エッジ側サーバ２０で算出される上記集約結果は、空間方向に広がる複数のプレイヤの中の一部（各エッジ側サーバ２０と通信するプレイヤ端末３０を操作するプレイヤ）のリクエストの結果を集約した結果である。以降、各エッジ側サーバ２０で算出される当該集約結果を「"並列的に受信したリクエストの暫定的集約結果"」と呼ぶ。
【００４１】
複数の第１のプレイヤ端末３０は、第１のレスポンスを受信すると（Ｓ１０３）、第１のレスポンスに対応する第１の表示を行う（Ｓ１０４）。すなわち、端末送受信部３５が第１のレスポンスを受信すると、処理部３３は第１のレスポンス及び記憶部３４に記憶されているデータに基づき第１の表示を実現するデータを生成し、その後、出力部３２に第１の表示を実行させる。
【００４２】
Ｓ１０１で送信されたリクエストが攻撃リクエストである場合、第１の表示の一例として、例えば図７に示すように、敵キャラクタＰにダメージを与えたことを示すエフェクト表示Ｑが考えられる。その他、図８に示すように、エフェクト表示Ｑに加えて、"並列的に受信したリクエストの暫定的集約結果"で示される敵キャラクタＰに与えたダメージ量Ｒを含んでもよい。
【００４３】
第１の表示（Ｓ１０４）の継続時間は、その後の第２のレスポンスに対応する第２の表示（Ｓ１１６）が開始されるまで継続されるように設計される。
【００４４】
上述した複数の第１のプレイヤ端末３０及び第１のエッジ側サーバ２０による処理と同様の処理が、同タイミングで、他のプレイヤ端末３０と他のエッジ側サーバ２０とにより実行される（Ｓ１０６乃至Ｓ１１０）。
【００４５】
なお、複数の第１のプレイヤ端末３０が第１のエッジ側サーバ２０から受信する第１のレスポンスの内容と、複数の第ｍのプレイヤ端末３０が第ｍのエッジ側サーバ２０から受信する第１のレスポンスの内容は異なり得る。このため、第１のプレイヤ端末３０に表示される第１の表示の内容と、第ｍのプレイヤ端末３０に表示される第１の表示の内容は異なり得る。例えば、図８に示す例で示されるダメージ量Ｒは異なる値になり得る。
【００４６】
一方で、複数の第１のプレイヤ端末３０が第１のエッジ側サーバ２０から受信する第１のレスポンスの内容は同一である。このため、複数の第１のプレイヤ端末３０に表示される第１の表示の内容は同一である。例えば、図８に示す例で示されるダメージ量Ｒは同じ値になる。同様に、複数の第ｍのプレイヤ端末３０が第ｍのエッジ側サーバ２０から受信する第１のレスポンスの内容は同一である。このため、複数の第ｍのプレイヤ端末３０に表示される第１の表示の内容は同一である。例えば、図８に示す例で示されるダメージ量Ｒは同じ値になる。
【００４７】
その後、クラウド側サーバ１０は、複数のエッジ側サーバ２０各々から受信した"並列的に受信したリクエストの暫定的集約結果"に基づく処理を実行し（Ｓ１１１）、処理の結果を複数のエッジ側サーバ２０に送信する（Ｓ１１２、Ｓ１１３）。複数のエッジ側サーバ２０各々から"並列的に受信したリクエストの暫定的集約結果"を受信する処理は、クラウド受信部１１により実現される。Ｓ１１１乃至Ｓ１１３の処理は、クラウド処理部１２により実現される。
【００４８】
例えば、クラウド処理部１２は、複数のエッジ側サーバ２０各々から受信した"並列的に受信したリクエストの暫定的集約結果"各々が示す敵キャラクタに与えたダメージ値の合計を算出する。そして、クラウド処理部１２は、当該ダメージ値の合計を、複数のエッジ側サーバ２０に送信する。
【００４９】
なお、クラウド処理部１２で算出される上記処理結果は、複数のエッジ側サーバ２０から受信した"並列的に受信したリクエストの暫定的集約結果"を集約したものであり、すなわち、空間方向に広がる複数のプレイヤの全てのリクエストの結果を集約した結果である。以降、クラウド処理部１２で算出される当該処理結果を「"並列的に受信したリクエストの最終的集約結果"」と呼ぶ。
【００５０】
第１のエッジ側サーバ２０は、クラウド側サーバ１０から"並列的に受信したリクエストの最終的集約結果"を受信すると（Ｓ１１２）、その"並列的に受信したリクエストの最終的集約結果"を、Ｓ１０１で受信したリクエストに対する第２のレスポンスとして複数の第１のプレイヤ端末３０に送信する（Ｓ１１４）。Ｓ１１２及びＳ１１４の処理は、第２のエッジ処理部２３により実現される。
【００５１】
複数の第１のプレイヤ端末３０は、第２のレスポンスを受信すると（Ｓ１１４）、第２のレスポンスに対応する第２の表示を行う（Ｓ１１６）。すなわち、端末送受信部３５が第２のレスポンスを受信すると、処理部３３は第２のレスポンス及び記憶部３４に記憶されているデータに基づき第２の表示を実現するデータを生成し、その後、出力部３２に第２の表示を実行させる。
【００５２】
なお、上述の通り、第１の表示（Ｓ１０４）の継続時間は、その後の第２のレスポンスに対応する第２の表示（Ｓ１１６）が開始されるまで継続されるように設計される。このため、処理部３３は、第１の表示（Ｓ１０４）が終了する前に第２の表示（Ｓ１１６）を開始させることとなる。すなわち、第１の表示（Ｓ１０４）と第２の表示（Ｓ１１６）はシームレスにつながっている。
【００５３】
Ｓ１０１で送信されたリクエストが攻撃リクエストである場合、第２の表示の一例として、例えば図９に示すように、敵キャラクタＰにダメージを与えたことを示すエフェクト表示Ｑと、"並列的に受信したリクエストの最終的集約結果"で示される敵キャラクタＰに与えたダメージ量Ｒの表示が考えられる。
【００５４】
なお、上述した複数の第１のプレイヤ端末３０及び第１のエッジ側サーバ２０による処理と同様の処理が、同タイミングで、他のプレイヤ端末３０と他のエッジ側サーバ２０とにより実行される（Ｓ１１３、Ｓ１１５及びＳ１１７）。
【００５５】
複数の第１のプレイヤ端末３０が第１のエッジ側サーバ２０から受信する第２のレスポンスの内容と、複数の第ｍのプレイヤ端末３０が第ｍのエッジ側サーバ２０から受信する第２のレスポンスの内容は同一である。このため、第１のプレイヤ端末３０に表示される第２の表示の内容と、第ｍのプレイヤ端末３０に表示される第２の表示の内容は同一である。例えば、図９に示す例で示されるダメージ量Ｒは同じ値になる。
【００５６】
ところで、プレイヤ端末３０は、リクエストを送信すると（Ｓ１０１、Ｓ１０６）、その１つのリクエストに対し、非同期Ｉ／Ｏで第１のレスポンス及び前記第２のレスポンスをこの順にエッジ側サーバ２０から受信する（Ｓ１０３、Ｓ１１４、Ｓ１０８、Ｓ１１５）。このため、第１のレスポンスを受け取ってから第２のレスポンスを受け取るまでの間に、第１のレスポンスに対応する第１の表示を行うことができる（Ｓ１０４、Ｓ１０９）。
【００５７】
「ハードウエア構成」
【００５８】
次に、ゲームシステムを実現する各装置（クラウド側サーバ１０、エッジ側サーバ２０及びプレイヤ端末３０）のハードウエア構成を説明する。本実施形態の各装置が備える各機能部は、任意のコンピュータのＣＰＵ（Central Processing Unit）、メモリ、メモリにロードされるプログラム、そのプログラムを格納するハードディスク等の記憶ユニット（あらかじめ装置を出荷する段階から格納されているプログラムのほか、ＣＤ（Compact Disc）等の記憶媒体やインターネット上のサーバ等からダウンロードされたプログラムをも格納できる）、ネットワーク接続用インターフェイスを中心にハードウエアとソフトウエアの任意の組合せによって実現される。そして、その実現方法、装置にはいろいろな変形例があることは、当業者には理解されるところである。
【００５９】
図１０は、本実施形態の各装置のハードウエア構成を例示するブロック図である。図２に示すように、各装置は、プロセッサ１Ａ、メモリ２Ａ、入出力インターフェイス３Ａ、周辺回路４Ａ、バス５Ａを有する。周辺回路４Ａには、様々なモジュールが含まれる。なお、各装置は周辺回路４Ａを有さなくてもよい。
【００６０】
なお、クラウド側サーバ１０及びエッジ側サーバ２０は物理的及び／又は論理的に分かれた複数の装置で構成されてもよい。この場合、各装置が上記ハードウエア構成を備えることができる。その他、クラウド側サーバ１０及びエッジ側サーバ２０は、物理的及び論理的に１つの装置で構成されてもよい。
【００６１】
バス５Ａは、プロセッサ１Ａ、メモリ２Ａ、周辺回路４Ａ及び入出力インターフェイス３Ａが相互にデータを送受信するためのデータ伝送路である。プロセッサ１Ａは、例えばＣＰＵ、ＧＰＵ（Graphics Processing Unit）などの演算処理装置である。メモリ２Ａは、例えばＲＡＭ（Random Access Memory）やＲＯＭ（Read Only Memory）などのメモリである。入出力インターフェイス３Ａは、入力装置、外部装置、外部サーバ、外部センサ等から情報を取得するためのインターフェイスや、出力装置、外部装置、外部サーバ等に情報を出力するためのインターフェイスなどを含む。入力装置は、例えばキーボード、マウス、マイク等である。出力装置は、例えばディスプレイ、スピーカ、プリンター、メーラ等である。プロセッサ１Ａは、各モジュールに指令を出し、それらの演算結果をもとに演算を行うことができる。
【００６２】
「実施例」
【００６３】
次に、第１の実施形態の実施例を説明する。本実例の概要を図１１に示す。本実施例は、従来のクラウド上で運用されるＡＰＩを、５ＧのＭＥＣインフラストラクチャを用いて、
（１） クラウド側サーバ１０と同じＡＰＩをエッジ側サーバ２０で公開し、エッジ側サーバ２０でプレイヤ端末３０からのリクエストを集約してからクラウド側サーバ１０へ送信する機能、及び、
（２） エッジ側サーバ２０からプレイヤ端末３０への即時の応答と、クラウド側サーバ１０からプレイヤ端末３０への応答を非同期的に送信する機能、
の２つを実現することにより、高い応答性と高いスケーラビリティを同時に実現するものである。本実施例のゲームシステムを構成するモジュールは、次の６つである。
【００６４】
［Ｍ１］Game Server on the Edgeは、ＭＥＣインフラストラクチャ上に配置されたゲームサーバであり、エッジ側サーバ２０に該当する。従来の、クラウド上で動作するゲームサーバ（クラウド側サーバ１０）と同じ機能を実装しているものの、使用するデータベースが限定されている点が異なる。［Ｍ１］は、次の２つの機能を実装する。
【００６５】
［Ｍ１−１］API Implementationは、［Ｍ２］Game Server on the Cloudが備える［Ｍ２−１］API Implementationと同じロジックでリクエストを処理し、ゲーム内のアクションの結果を計算して、クライアント（プレイヤ端末３０）に即座に返却するＡＰＩの実装である。この［Ｍ１−１］は、ゲーム毎、実施形態毎に異なる機能を実装しているものの、外部から受信したリクエストをゲーム内のコマンドとして解釈し、何らかの演算を行なった後にレスポンスを返すという点においては、一般的なＲＥＳＴ  ＡＰＩとして位置付けることができる。
【００６６】
このモジュールと、クラウド側のモジュールの大きな違いは、［Ｍ１−１］は、モジュール［Ｍ１］が把握している情報、すなわち、特定の地域のプレイヤの情報のみを用いて、一貫性のある結果を算出し、最初のレスポンスを即座に（例：５ｍｓ以内）に返却する点にある。ここで参照する［Ｍ１］に限定された局所的な情報は、［Ｍ３］Small DBに格納されている。また、この時、最初のレスポンスの送信後、［Ｍ１］Game Server on the Edgeとクライアントの接続（セッション）を切断せずに維持しておく。
【００６７】
［Ｍ１−２］Request Aggregatorは、一定期間ごとに、リクエストを集約（例えば、敵キャラクタのダメージ数を合計するなど）して、対応する［Ｍ２］のＡＰＩを呼び出すモジュールである。ここで、リクエストを集約する例として、複数のプレイヤが、１つの敵キャラクタに与えたダメージの総量を合計する方式などが考えられる。
【００６８】
［Ｍ２］Game Server on the Cloudは、従来から用いられているゲームサーバであり、クラウド側サーバ１０に該当する。クライアントから呼び出される機能をＷｅｂ  ＡＰＩとして外部に公開している。本発明では、［Ｍ２］は、固定の頻度（高々、［Ｍ１］で設定されている頻度が上限となる）、低い同時接続数（高々、Ｍ１の設置数となる）で、ＡＰＩを実行し、データベース［Ｍ４］を用いて大局的に一貫性のある結果を計算して、［Ｍ１］に返却するモジュールとして位置付けることができる。［Ｍ２］は、少なくとも次の１つのサブモジュールから構成される。
【００６９】
［Ｍ２−１］API Implementationは、従来と同じクラウド側のゲームサーバのロジックを実装するモジュールである。このモジュールは、ほぼ全ての機能を、［Ｍ１−１］と共有することとなる。
【００７０】
［Ｍ３］Small DBは、ゲームに参加する複数のプレイヤの中の一部のゲーム状態を保存するためのデータベースである。各［Ｍ１］が備える［Ｍ３］は、各［Ｍ１］と通信するクライアントを操作するプレイヤのゲーム状態を保存する。
【００７１】
［Ｍ４］Large DBは、ゲームに参加する全てのプレイヤのゲーム状態を保存するデータベースであり、従来から用いられているゲーム用データベースである。
【００７２】
図１１には、各データの送受信に要する時間の目安を示している。なお、あくまで目安であり、これに限定されない。［Ｍ１］とクライアントとの間の通信時間の目安は、２ｍｓ程度である。［Ｍ１］と［Ｍ２］との間の通信時間の目安は、１００ｍｓ程度である。
【００７３】
なお、プレイヤ端末３０が５Ｇ以外のネットワーク（３Ｇ、４Ｇ等のモバイルネットワークや、無線ＬＡＮ等）を介してインターネット６０に繋がっている場合には、プレイヤ端末３０が直接（エッジ側サーバ２０を介さないで）クラウド側サーバ１０と通信し、同一のＵＲＬのＡＰＩを呼び出すだけであるため、容易にフォールバックさせることができる。その場合は、単にレスポンスが現在と同じ速度のＡＰＩとして使用することができる。
【００７４】
次に、本実施例による通信方式の具体例を示す。
【００７５】
（１）クライアントが攻撃のＲＥＳＴ  ＡＰＩを呼び出したとき、１回の攻撃リクエストの結果を、ネットワークのエッジサイド（下流）にある［Ｍ１］の［Ｍ１−１］が３ｍｓ程度の応答速度で暫定的なレスポンスを返す。ただし、伝統的なＣｏｍｅｔ接続のようにレスポンスのコネクションは切断せずに維持しておく。ここで、［Ｍ１］は、同じ携帯基地局（もしくはコアネットワーク設備）につながっているクライアントからのリクエストを受け取るので、ある特定の地域内における総ダメージ量（ローカル・ダメージ量）を計算することができ、その特定地域内の総ダメージ量をレスポンスとして返すことができる。このような合計値の算出を［Ｍ１−２］が担う。
【００７６】
（２）その暫定的なレスポンスに応じたアニメーションをクライアントがＵＩに描画している間（２００ｍｓ以上のアニメーションであることが好ましい）に、［Ｍ１］の［Ｍ１−２］は、上述した特定地域内の総ダメージ量を［Ｍ２］に送信する。［Ｍ２］は、例えば、基地局数分の総ダメージ量（ローカル・ダメージ量）を足し合わせて、全プレイヤ（例えば１００万人程度）が与えたダメージ量の合計（グローバル・ダメージ量）を算出する攻撃処理を実装することができる。
【００７７】
（３）２００ｍｓ程度の経過時間後に、［Ｍ２］は、全プレイヤ（例えば１００万人程度）が与えたダメージ量の合計（グローバル・ダメージ量）をレスポンスとして［Ｍ１］に返す。［Ｍ１］は、このグローバル・ダメージ量を、追加的にクライアントに返し、レスポンスを終了する。
【００７８】
（４）クライアントは、描画中の暫定的なレスポンスに応じたアニメーションをシームレスに更新する形で、グローバル・ダメージ量のエフェクトを描画する（例えば、図７から図９にシームレスに変更、図８から図９にシームレスに変更等）。このように、クライアントからは単一のＡＰＩからのレスポンスを非同期的に読むだけで、例えば３ｍｓ程度で５Ｇ固有の局所的な演算結果を受け取ることができ、その２００ｍｓ程度後に、従来のクラウドで計算される大局的な演算結果を受け取ることができる。
【００７９】
次に、本実施例におけるクライアント側でのレスポンスのパース方法の一例を示す。
【００８０】
一般的に、ＨＴＭＬ５やネイティブアプリ等のリッチクライアントが利用するＷｅｂ  ＡＰＩの戻り値は、ＪＳＯＮ等の木構造を有するデータが採用されることが多い。このＪＳＯＮをクライアントで読み込む（パースする）時に、ＪＳＯＮデータ全体をメモリ上に読み込んで、その木構造をプログラミング言語のデータ構造（オブジェクト）として一気に再現する方式がよく採用されている。しかしながら、本実施例は、ＪＳＯＮ等のデータを、例えば５ｍｓ後に先頭部分だけを返し、例えば１００ｍｓ後にその後の全体を返す、というような時間差のある漸進的なレスポンス返却を行うため、従来の標準的なＪＳＯＮのパース方法では、本実施例のメリットである低遅延を享受することができない。
【００８１】
そこで、ＪＳＯＮのパース方法として、ＪＳＯＮ文書を木構造として扱うのではなく、一連のイベントとして表現するイベント駆動型のＡＰＩを使用することができる。ＸＭＬパーサの分野で、このようなイベント駆動型のＡＰＩがＳＡＸ（Simple API for XML）と呼ばれており、ＪＳＯＮパーサも、「SAX-like API」としてイベント駆動型のＡＰＩを提供している。例えば、JavaScriptではstream-json (https://github.com/uhop/stream-json)、C++ではRapidJSON (http://rapidjson.org)が、SAX-like APIをサポートしている。このSAX-like APIでは、ＪＳＯＮの階層構造の開始と終了、属性の定義などがイベントとして逐次的にアプリケーションに通知されるため、断片的なＪＳＯＮを直ちにパースすることができる。
【００８２】
「作用効果」
本実施形態は、５Ｇ＋ＭＥＣという新しいエッジコンピューティング・インフラストラクチャの普及を捉えて、ネットワークの経路上に計算能力を持ったサーバが分散配置されるという垂直方向の分散（Vertical Distribution）に適した、新たなＷｅｂ  ＡＰＩの実装方式を初めて提案するものであり、５Ｇ時代のＡＰＩ実装方法のデファクトスタンダードになりうるものである。本実施形態の作用効果として、次の３点が挙げられる。
【００８３】
−超低遅延−
本実施形態は、モバイルネットワーク上のＭＥＣインフラストラクチャから直ちにプレイヤ端末３０にレスポンスを返すことができる。このため、レスポンスの返信に要する時間が例えば１０ｍｓ程度となり、クラウド側からレスポンスを返す場合に要する時間（100msから200ms程度）に比べて著しく低下させることができる。これは、６０ＦＰＳのゲームにおいても毎フレーム（約１６ｍｓ）の頻度でサーバ側の機能を使用することができることを意味しており、従来のゲームと全く異なる低遅延性を実現することができる。
【００８４】
−スケーラビリティ−
本実施形態は、１つのＷｅｂ  ＡＰＩを例えば数百万のプレイヤ端末３０が呼び出す時、エッジ側サーバ２０は暫定的なレスポンスを即座に（数ミリ秒で）プレイヤ端末３０に返しつつ、受信した複数のリクエストを集約（Aggregate）してクラウド側サーバ１０上の同一Ｗｅｂ  ＡＰＩを呼び出す。したがって、クラウド側サーバ１０においては、同時接続数を、高々、エッジ側サーバ２０の数だけに抑えることができる。
【００８５】
−互換性−
本実施形態は、低遅延の第１のレスポンスと通常の遅延の第２のレスポンスを組み合わせたＡＰＩにより、クラウド側サーバ１０のＡＰＩを大きく変更することなく、シンプルなＲＥＳＴ  ＡＰＩにしたまま、プレイヤ端末３０を操作するプレイヤからのネットワークアクセスの見た目の遅延を１０ミリ秒未満に抑えたゲームを構築することができる。さらに、４Ｇから５Ｇへの移行期や固定回線と５Ｇが混在する環境においては、５Ｇ以外の接続を、従来のクラウド側のロードバランサで負荷分散させることができるため、スムースに本実施形態を既存のシステムへ追加的に導入することができる。
【００８６】
＜第２の実施形態＞
「構成」
第１の実施形態のエッジ側サーバ２０は、空間方向に広がる複数の一部のプレイヤのリクエストの結果を集約した"並列的に受信したリクエストの暫定的集約結果"を算出した。これに対し、本実施形態のエッジ側サーバ２０は、１人のプレイヤが時間差で送信した複数のリクエストの結果を集約した"連続的に受信したリクエストの暫定的集約結果"を算出する。以下、詳細に説明する。
【００８７】
エッジ側サーバ２０のエッジ受信部２１は、１つのプレイヤ端末３０が時間差で送信した複数のリクエストを受信する。第１のエッジ処理部２２は、リクエストに基づく処理を実行し、リクエストに基づく処理の結果をリクエストに対する第１のレスポンスとしてそのプレイヤ端末３０に送信する。第２のエッジ処理部２３は、そのプレイヤ端末３０が時間差で送信した複数のリクエストに基づく処理の結果を集約した"連続的に受信したリクエストの暫定的集約結果"を算出し、"連続的に受信したリクエストの暫定的集約結果"をクラウド側サーバ１０に送信する。
【００８８】
クラウド側サーバ１０のクラウド処理部１２は、"連続的に受信したリクエストの暫定的集約結果"に基づく処理を実行し、"連続的に受信したリクエストの暫定的集約結果"に基づく処理の結果をエッジ側サーバ２０に送信する。エッジ側サーバ２０の第２のエッジ処理部２３は、"連続的に受信したリクエストの暫定的集約結果"に基づく処理の結果をクラウド側サーバ１０から受信すると、その結果を上記リクエストに対する第２のレスポンスとしてそのプレイヤ端末３０に送信する。
【００８９】
図１２に当該処理の流れの一例を示す。プレイヤ端末３０がエッジ側サーバ２０にリクエストを送信すると（Ｓ２００）、エッジ側サーバ２０はそのリクエストに基づく処理を実行し（Ｓ２０１）、処理の結果をそのリクエストに対する第１のレスポンスとしてプレイヤ端末３０に送信する（Ｓ２０２）。
【００９０】
その後、プレイヤ端末３０がエッジ側サーバ２０にリクエストを送信すると（Ｓ２０３）、エッジ側サーバ２０はそのリクエストに基づく処理を実行し（Ｓ２０４）、処理の結果をそのリクエストに対する第１のレスポンスとしてプレイヤ端末３０に送信する（Ｓ２０５）。
【００９１】
その後、プレイヤ端末３０がエッジ側サーバ２０にリクエストを送信すると（Ｓ２０６）、エッジ側サーバ２０はそのリクエストに基づく処理を実行し（Ｓ２０７）、処理の結果をそのリクエストに対する第１のレスポンスとしてプレイヤ端末３０に送信する（Ｓ２０８）。
【００９２】
なお、ここではリクエストと第１のレスポンスの送受信を３回繰り返しているが、その回数はこれに限定されない。
【００９３】
そして、予め定められた所定のタイミングになると、第２のエッジ処理部２３は、それまでに受信したリクエスト（Ｓ２００、Ｓ２０３、Ｓ２０６）に対する処理の結果を集約した"連続的に受信したリクエストの暫定的集約結果"を、クラウド側サーバ１０に送信する（Ｓ２０９）。
【００９４】
クラウド側サーバ１０は、"連続的に受信したリクエストの暫定的集約結果"に基づく処理を実行し（Ｓ２１０）、処理の結果をエッジ側サーバ２０に送信する（Ｓ２０９）。エッジ側サーバ２０は、クラウド側サーバ１０から受信した処理の結果を、リクエスト（Ｓ２００、Ｓ２０３、Ｓ２０６）に対する第２のレスポンスとしてプレイヤ端末３０に送信する（Ｓ２１２）。
【００９５】
本実施形態でも、プレイヤ端末３０は、リクエストに対する第１のレスポンス及び第２のレスポンスを非同期Ｉ／Ｏで受信する。このため、プレイヤ端末３０は、第１のレスポンスを受信してから第２のレスポンスを受信するまでの間に、他の処理を行うことができる。
【００９６】
なお、プレイヤ端末３０から送信されるリクエストの詳細は限定されないが、一例として、プレイヤ端末３０が管理している管理情報（プレイヤキャラクタの状態情報等）をサーバ側で保存する同期リクエストが挙げられる。
【００９７】
この場合、プレイヤ端末３０及びエッジ側サーバ２０は、所定時間Ｔ１毎に、最新の管理情報及び同期リクエストを送受信することができる（Ｓ２００、Ｓ２０３、Ｓ２０６）。
【００９８】
そして、エッジ側サーバ２０の第１のエッジ処理部２２は、受信された管理情報をエッジ記憶装置（記憶部２４）に記憶させる処理を実行し（Ｓ２０１、Ｓ２０４、Ｓ２０７）、処理に成功した旨を第１のレスポンスとしてプレイヤ端末３０に送信する（Ｓ２０２、Ｓ２０５、Ｓ２０８）。
【００９９】
エッジ側サーバ２０の第２のエッジ処理部２３は、所定時間Ｔ２毎に（Ｔ２はＴ１より大）、エッジ記憶装置（記憶部２４）に記憶されている最新の管理情報を、"連続的に受信したリクエストの暫定的集約結果"としてクラウド側サーバ１０に送信する（Ｓ２０９）。
【０１００】
クラウド側サーバ１０のクラウド処理部１２は、"連続的に受信したリクエストの暫定的集約結果"として受信された管理情報をクラウド記憶装置（記憶部１３）に記憶させる処理を実行し（Ｓ２１０）、処理に成功した旨を"連続的に受信したリクエストの暫定的集約結果"に基づく処理の結果としてエッジ側サーバ２０に送信する（Ｓ２１１）。
【０１０１】
なお、本実施形態のゲームシステムは、本実施形態で説明した時間方向の集約処理に加えて、第１の実施形態で説明した空間方向の集約処理を実行可能に構成されてもよい。
【０１０２】
本実施形態のゲームシステムのその他の構成は、第１の実施形態と同様である。
【０１０３】
「実施例」
次に、第２の実施形態の実施例を説明する。本実例の概要は図１１で示される。本実施例では、ネイティブのゲームアプリにおいて、例えば毎フレームの頻度でデータをサーバ側に保存・同期する例を示す。
【０１０４】
従来のネイティブアプリでは、クラウドサーバとの通信は比較的遅延が大きい処理であったため、ステージの区切りやバトルの前後などの、所定の遅延を挟んでも支障の無いタイミングで通信を行なっていた。しかしながら、このような実装方法では、ゲームの途中に通信が一時的に切断した場合などに、意図的な不正行為（チート）による切断か、それとも、止むを得ない通信切断かを区別することが難しいため、一律で無効試合にする等の処理が取られていた。これは、不正行為を行っていないプレイヤにとってはストレスとなる処理であるため、通信状態が安定した場所でゲームを楽しむことが必須となっていた。
【０１０５】
本実施例を適用すると、バトル等のゲーム中であっても高頻度（例えば、１秒間に複数回）にゲームの状態をサーバ側に保存（同期）することができるため、通信の切断が起きてもクライアント側を再起動せずにサーバから状態データを読み取り復帰させるようなクラウド・ネイティブな運用が可能になる。
【０１０６】
このようなリアルタイムセーブでは、図１１の［Ｍ１−１］と［Ｍ２−１］が、従来のゲームサーバと同じゲームデータの検証・保存ＡＰＩを実装し、さらに、［Ｍ１−２］として、複数回のデータ保存を行ったのちの最新のバージョンのデータのみを［Ｍ２］に送信する処理を実装することにより、低遅延で、かつ、クラウド側の負荷が大幅に低下されたセーブ機能を実現することができる。
【０１０７】
「作用効果」
以上説明した本実施形態のゲームシステムによれば、第１の実施形態と同様の作用効果が実現される。また、エッジ側サーバ２０は、１人のプレイヤが時間差で送信した複数のリクエストの結果を集約した"連続的に受信したリクエストの暫定的集約結果"を算出し、クラウド側サーバ１０に送信することができる。このため、エッジ側サーバ２０の利用場面が広がり、活用の幅が広がる。
【０１０８】
以下、参考形態の例を付記する。
１．  クラウド側サーバと、エッジ側サーバと、プレイヤ端末とを備え、
前記エッジ側サーバは、
前記プレイヤ端末が送信したリクエストを受信するエッジ受信部と、
前記リクエストに基づく処理を実行し、前記リクエストに基づく処理の結果を前記リクエストに対する第１のレスポンスとして前記プレイヤ端末に送信する第１のエッジ処理部と、
一定期間ごとに、前記リクエストに基づく処理の結果を集約した集約結果を前記クラウド側サーバに送信し、前記クラウド側サーバで実行された前記集約結果に基づく処理の結果を受信し、前記集約結果に基づく処理の結果を前記リクエストに対する第２のレスポンスとして前記プレイヤ端末に送信する第２のエッジ処理部と、
を有し、
前記クラウド側サーバは、
前記エッジ側サーバが送信した前記集約結果を受信するクラウド受信部と、
前記集約結果に基づく処理を実行し、前記集約結果に基づく処理の結果を前記エッジ側サーバに送信するクラウド処理部と、
を有し、
前記プレイヤ端末は、
前記リクエストを送信し、１つの前記リクエストに対し、非同期Ｉ／Ｏで前記第１のレスポンス及び前記第２のレスポンスをこの順に前記エッジ側サーバから受信する端末送受信部と、
を有するゲームシステム。
２．  前記プレイヤ端末は、
前記第１のレスポンスを受信すると前記第１のレスポンスに対応する第１の表示を行い、前記第２のレスポンスを受信すると前記第２のレスポンスに対応する第２の表示を行い、
前記第１の表示が終了する前に前記第２の表示を開始する１に記載のゲームシステム。
３．  複数の前記プレイヤ端末各々は、複数の前記エッジ側サーバの中のいずれか１つと通信し、
前記エッジ受信部は、自エッジ側サーバと通信する複数の前記プレイヤ端末各々が送信した複数の前記リクエストを受信し、
前記第２のエッジ処理部は、自エッジ側サーバと通信する複数の前記プレイヤ端末各々が送信した複数の前記リクエストに基づく処理の結果を集約した並列的に受信したリクエストの暫定的集約結果を算出し、前記並列的に受信したリクエストの暫定的集約結果を前記クラウド側サーバに送信し、
前記クラウド受信部は、複数の前記エッジ側サーバ各々から、前記並列的に受信したリクエストの暫定的集約結果を受信し、
前記クラウド処理部は、複数の前記並列的に受信したリクエストの暫定的集約結果を集約して並列的に受信したリクエストの最終的集約結果を算出し、前記並列的に受信したリクエストの最終的集約結果を複数の前記エッジ側サーバに送信し、
前記第２のエッジ処理部は、受信した前記並列的に受信したリクエストの最終的集約結果を前記第２のレスポンスとして自エッジ側サーバと通信する複数の前記プレイヤ端末に送信する１又は２に記載のゲームシステム。
４．  前記リクエストは、敵キャラクタに対する攻撃内容を示す攻撃リクエストであり、
前記エッジ側サーバ各々が算出する前記並列的に受信したリクエストの暫定的集約結果は、前記エッジ側サーバ各々と通信する複数の前記プレイヤ端末が送信した複数の前記攻撃リクエストに基づき算出された前記敵キャラクタに与えたダメージ値であり、
前記並列的に受信したリクエストの最終的集約結果は、前記エッジ側サーバ各々が算出した前記並列的に受信したリクエストの暫定的集約結果各々が示す前記敵キャラクタに与えたダメージ値の合計である３に記載のゲームシステム。
５．  前記エッジ受信部は、１つの前記プレイヤ端末が時間差で送信した複数の前記リクエストを受信し、
前記第２のエッジ処理部は、１つの前記プレイヤ端末が時間差で送信した複数の前記リクエストに基づく処理の結果を集約した連続的に受信したリクエストの暫定的集約結果を算出し、前記連続的に受信したリクエストの暫定的集約結果を前記クラウド側サーバに送信し、
前記クラウド処理部は、前記連続的に受信したリクエストの暫定的集約結果に基づく処理を実行し、前記連続的に受信したリクエストの暫定的集約結果に基づく処理の結果を前記エッジ側サーバに送信する１又は２に記載のゲームシステム。
６．  前記リクエストは、前記プレイヤ端末が管理している管理情報をサーバ側で保存する同期リクエストであり、
前記エッジ受信部は、所定時間Ｔ１毎に最新の前記管理情報及び前記同期リクエストを受信し、
前記第１のエッジ処理部は、受信された前記管理情報をエッジ記憶装置に記憶させる処理を実行し、処理に成功した旨を前記第１のレスポンスとして前記プレイヤ端末に送信し、
前記第２のエッジ処理部は、所定時間Ｔ２毎に（Ｔ２はＴ１より大）、前記エッジ記憶装置に記憶されている最新の前記管理情報を、前記連続的に受信したリクエストの暫定的集約結果として前記クラウド側サーバに送信し、
前記クラウド処理部は、前記連続的に受信したリクエストの暫定的集約結果として受信された前記管理情報をクラウド記憶装置に記憶させる処理を実行し、処理に成功した旨を前記連続的に受信したリクエストの暫定的集約結果に基づく処理の結果として前記エッジ側サーバに送信する１に記載のゲームシステム。
７．  クラウド側サーバと、エッジ側サーバと、プレイヤ端末とを備えるゲームシステムが実行するゲーム制御方法であって、
前記エッジ側サーバは、
前記プレイヤ端末が送信したリクエストを受信し、
前記リクエストに基づく処理を実行し、前記リクエストに基づく処理の結果を前記リクエストに対する第１のレスポンスとして前記プレイヤ端末に送信し、
一定期間ごとに、前記リクエストに基づく処理の結果を集約した集約結果を前記クラウド側サーバに送信し、前記クラウド側サーバで実行された前記集約結果に基づく処理の結果を受信し、前記集約結果に基づく処理の結果を前記リクエストに対する第２のレスポンスとして前記プレイヤ端末に送信し、
前記クラウド側サーバは、
前記エッジ側サーバが送信した前記集約結果を受信し、
前記集約結果に基づく処理を実行し、前記集約結果に基づく処理の結果を前記エッジ側サーバに送信し、
前記プレイヤ端末は、
前記リクエストを送信し、１つの前記リクエストに対し、非同期Ｉ／Ｏで前記第１のレスポンス及び前記第２のレスポンスをこの順に前記エッジ側サーバから受信するゲーム制御方法。
８．  １から６のいずれかに記載のゲームシステムのエッジ側サーバ。
９．  １から６のいずれかに記載のゲームシステムのクラウド側サーバ。
１０．  １から６のいずれかに記載のゲームシステムのプレイヤ端末。
【符号の説明】
【０１０９】
１Ａ    プロセッサ
２Ａ    メモリ
３Ａ    入出力Ｉ／Ｆ
４Ａ    周辺回路
５Ａ    バス
１０    クラウド側サーバ
１１    クラウド受信部
１２    クラウド処理部
１３    記憶部
２０    エッジ側サーバ
２１    エッジ受信部
２２    第１のエッジ処理部
２３    第２のエッジ処理部
２４    記憶部
３０    プレイヤ端末
３１    入力部
３２    出力部
３３    処理部
３４    記憶部
３５    端末送受信部
６０    インターネット
７０    モバイルネットワーク
７１    基地局
７２    コア網
７３    インターネットゲートウェイ
【要約】
【課題】従来よりもはるかに高いレベルのゲームサービスのスケーラビリティ（多接続化）とレスポンス性能（低遅延化）を同時に達成する。
【解決手段】エッジ側サーバ２０は、プレイヤ端末３０が送信したリクエストを受信すると、リクエストに対する第１のレスポンスをプレイヤ端末３０に送信するとともに、一定期間ごとに、リクエストに基づく処理の結果を集約した集約結果をクラウド側サーバ１０に送信する。そして、エッジ側サーバ２０は、クラウド側サーバ１０で実行された当該集約結果に基づく処理の結果を受信し、それを第２のレスポンスとしてプレイヤ端末３０に送信する。プレイヤ端末３０は、１つのリクエストに対し、非同期Ｉ／Ｏで第１のレスポンス及び第２のレスポンスをこの順にエッジ側サーバ２０から受信する。
【選択図】図１【図１】
0006913809.tif 000002
【図２】
0006913809.tif 000003
【図３】
0006913809.tif 000004
【図４】
0006913809.tif 000005
【図５】
0006913809.tif 000006
【図６】
0006913809.tif 000007
【図７】
0006913809.tif 000008
【図８】
0006913809.tif 000009
【図９】
0006913809.tif 000010
【図１０】
0006913809.tif 000011
【図１１】
0006913809.tif 000012
【図１２】
0006913809.tif 000013