JP7452921B1 - 制御システム、サーバおよび制御方法 - Google Patents

Abstract

ゲームの提供の前に、サーバ２とユーザ端末３とのそれぞれが、ゲームに対応する共通のノード定義データＮＤを利用可能な状態が構築される。ノード定義データＮＤには、ゲームの状態を示すノードが複数定義される。ユーザ端末３は、ユーザによってゲームが行われている間、ユーザ端末３のノード定義データに基づいてノードを遷移させ端末側設定情報の値を変化させる一方、ノードの遷移を再現可能な遷移再現情報および変化した端末側設定情報の値をログとしてログデータに記録する。更にユーザ端末３は、ログを含む送信用ログデータＤＬをサーバ２に送信する。サーバ２は、送信用ログデータの遷移再現情報およびサーバ２のノード定義データＮＤに基づいてノードの遷移を再現し、ノードの遷移に応じてサーバ側設定情報の値を変化させると共に、サーバ側設定情報の値と送信用ログデータに記録された端末側設定情報の値とを比較する。

Description

本発明は、サーバおよび端末によりゲームを提供する制御システム、当該制御装置、および、当該制御システムによる制御方法に関する。

従来、サーバと、このサーバにインターネットを介して通信可能に接続された端末とが協働して、ユーザにゲームを提供する制御システムが知られている。この種のゲームに関し、端末のプログラムが改変されたり、サーバと端末との間での通信が改ざんされたりすることによって不正行為が行われる場合がある。例えばユーザがゲームを有利に進めることができるように、ゲームのキャラクタ、ゲームで使用するアイテム、ゲームで使用可能なポイント、その他のゲームに関する要素が不正に改変される不正行為が行われる場合がある。不正行為に関し、特許文献１には、ゲームを進行させるための処理を全てサーバで実行することによって、不正行為を抑制できる点が記載されている（特に段落０００４参照）。

特開２０１９－１５４６６７号公報

端末およびサーバが協働してゲームを提供する制御システムに関しては、不正行為に対して耐性が高いことが求められている。そして特許文献１で示されている通り、制御システムについて、サーバがゲームを進行させるための処理（ゲームの進行に応じて画面情報を生成する処理を含む）を実行する一方、端末が画面情報に基づく画面の表示のみを行う構成とすることによって、効果的に不正行為を抑制することが可能である。しかしながら、この構成の場合、以下の問題がある。すなわちこの構成の場合、ゲームの進行に応じて頻繁に端末とサーバとの間での通信が発生することになる。そして、頻繁な通信の発生に起因してゲームの進行に遅延が生じる場合があり、このことがユーザの満足度の低下の要因となる。以上の問題がある。

本発明は、このような問題を解決するために成されたものであり、ゲームの進行の遅延を抑制し、かつ、不正行為に対する耐性を向上することを目的とする。

上記した課題を解決するために、本発明は、以下の構成を備える。すなわちゲームの提供の前に、サーバと端末とのそれぞれが、ゲームに対応する共通のノード定義データを利用可能な状態が構築される。このノード定義データには、ゲームの状態を示すノードが複数定義される。そして端末は、ユーザによってゲームが行われている間、端末のノード定義データに基づいてノードを遷移させ、ノードの遷移に応じて端末のノード定義データに対応する端末側設定情報の値を変化させる一方、ノードの遷移を再現可能な遷移再現情報およびノードの遷移に応じて変化した端末側設定情報の値をログとしてログデータに記録する。また端末は、ログの送信に関するログ送信条件が成立した場合、ログデータに記録されたログを含む送信用ログデータをサーバに送信する。一方、サーバは、端末から受信した送信用ログデータの遷移再現情報およびサーバのノード定義データに基づいてノードの遷移を再現し、ノードの遷移に応じてサーバのノード定義データに対応するサーバ側設定情報の値を変化させると共に、サーバ側設定情報の値と送信用ログデータに記録された対応する端末側設定情報の値とを比較する検証処理を実行する。

上記のように構成した本発明によれば、以下の効果を奏する。すなわちゲームの提供に際して、サーバと端末とが、共通するノード定義データを利用可能な状態が構築される。そして端末は、自身のノード定義データに基づいてノードを遷移させ、ゲームを進行させる。つまり端末は、ノードの遷移についてサーバに何らかの判断を行わせることなく、ゲームを進行させる。このためゲームの進行に関して、端末とサーバとの間で頻繁に通信が発生することを抑制でき、ゲームの進行の遅延を抑制できる。

更に本発明によれば、端末は、ノードの遷移を再現可能な遷移再現情報、および、ノードの遷移に応じて変化した端末側設定情報の値をログとしてログデータに記録する。更に端末は、所定の条件が成立した場合には、ログを含む送信用ログデータをサーバに送信する。一方、サーバは、送信用ログデータおよび自身のノード定義データに基づいてノードの遷移を再現する。更にサーバは、ノードの遷移に応じて、サーバ側設定情報の値を変化させると共に、当該値と送信用ログデータに記録された対応する端末側設定情報の値とを比較する。ここで、これら値が同じではない場合、端末において端末側設定情報の値が、正しい値から乖離したということである。従って、この場合、端末において何らかの不正行為が行われた可能性が高い。よって、これら値を比較するということは、端末における不正行為の発生の有無をサーバにおいて判別するということに等しい。つまり本発明によれば、不正行為の検出が可能であり、不正行為の検出に応じて不正行為を予防／防止する処理、または、不正行為に起因する悪影響を抑制する処理を行うことが可能である。

すなわち本発明によれば、ゲームの進行の遅延を抑制し、かつ、不正行為に対する耐性を向上できる。

図１は、制御システムの要部を示す図である。 図２は、制御システムの構成を示す図である。 図３は、サーバおよびユーザ端末の機能構成例を示すブロック図である。 図４は、ボーナスゲームの画面を示す図である。 図５は、ノード定義データの一例を示す図である。 図６は、ボーナスゲームのノードの遷移を示す図である。 図７は、ノード定義データ管理データベースのレコードの内容を示す図である。 図８は、制御システムによる制御方法を示すフローチャートである。 図９は、ノード関連情報の内容を示す図である。 図１０は、実行中ゲーム管理データベースのレコードの内容を示す図である。 図１１は、端末による制御方法を示す図である。 図１２は、端末による制御方法およびサーバによる制御方法を示す図である。 図１３は、ログの一例を示す図である。 図１４は、サーバによる制御方法を示す図である。 図１５は、サーバによる制御方法を示す図である。 図１６は、乱数利用実績情報の内容を示す図である。 図１７は、端末による制御方法およびサーバによる制御方法を示す図である。

以下、本発明の一実施形態が図面に基づいて説明される。

＜本実施形態の概要＞
まず、本実施形態の概要が説明される。図１は、制御システム１の要部を示す図である。図１で示すように制御システム１は、サーバ２およびサーバ２と通信可能なユーザ端末３（端末）を備える。サーバ２およびユーザ端末３は、協働してゲームを提供する。サーバ２は、サーバ制御部１０を備える。ユーザ端末３は、端末制御部１３を備える。サーバ制御部１０および端末制御部１３は共に、ハードウェアとソフトウェアとの協働により処理を実行する。例えばサーバ制御部１０は、ＣＰＵを含む処理装置が、ＲＯＭ、その他の記憶部に記憶されたプログラムを読み出して実行することによって処理を実行する。またサーバ２は、データを記憶するサーバ記憶部１２を備える。ユーザ端末３は、データを記憶する端末記憶部１７を備える。

ゲームの提供の前に、サーバ２とユーザ端末３とのそれぞれが、ゲームに対応する共通のノード定義データＮＤを利用可能な状態が構築される。ノード定義データＮＤには、ゲームの状態を示すノードが複数定義される。ユーザ端末３の端末制御部１３は、ユーザによってゲームが行われている間、ユーザ端末３のノード定義データＮＤに基づいてノードを遷移させ、ノードの遷移に応じてユーザ端末３のノード定義データＮＤに対応する端末側設定情報の値を変化させる。その一方で端末制御部１３は、ノードの遷移を再現可能な遷移再現情報およびノードの遷移に応じて変化した端末側設定情報の値をログＬＧとしてログデータＬＤに記録する。更に端末制御部１３は、ログＬＧの送信に関するログ送信条件が成立した場合、ログデータＬＤに記録されたログＬＧを含む送信用ログデータＤＬをサーバ２に送信する（ステップＳ１）。

サーバ２のサーバ制御部１０は、送信用ログデータＤＬの遷移再現情報およびサーバ２のノード定義データＮＤに基づいてノードの遷移を再現する。更にサーバ制御部１０は、ノードの遷移に応じてサーバのノード定義データＮＤに対応するサーバ側設定情報の値を変化させると共に、サーバ側設定情報の値と送信用ログデータＤＬに記録された対応する端末側設定情報の値とを比較する検証処理を実行する。制御システム１の構成によれば、ゲームの進行の遅延を抑制し、かつ、不正行為に対する耐性を向上できる。

＜本実施形態の詳細＞
次に本実施形態の詳細が説明される。図２は、本実施形態に係る制御システム１の構成例を示す図である。図２で示すように制御システム１は、サーバ２（コンピュータ）と、１つ以上のユーザ端末３（端末、コンピュータ）とを含んで構成される。サーバ２とユーザ端末３とは、インターネット、電話網、その他の通信網を含むネットワークＮを介して通信可能である。サーバ２およびユーザ端末３は、協働してゲームをユーザに提供する。

サーバ２は、ゲームに関するサービス（以下「本件サービス」という）を提供する。本実施形態に係るゲームでは、ユーザ端末３側で画面の提供、および、ユーザによる操作の受け付けが行われる。またゲームでは、ゲームに関する所定の情報がサーバ２に記憶され、ゲームの実行中は、ユーザ端末３とサーバ２との間で通信が行われる。図２および後述する図３では、サーバ２が１つのブロックで表されている。しかしこのことは、サーバ２が単一のサーバ装置で構成されることを意味しない。例えばサーバ２は、複数のサーバ装置により構成されてもよい。この場合においてサーバ２を構成するサーバ装置に、ＷｅｂサーバまたはＷｅｂアプリケーションサーバが含まれてもよい。特に負荷分散、通信の円滑化、その他の目的のために同一の機能を有する複数のサーバ装置が設けられてシステムが構成される場合がある。この構成の場合、例えばロードバランサによって各サーバ装置にリクエストが分散される。この構成の場合には、サーバ２は、複数のサーバ装置のうちの１つ以上のサーバ装置であってもよい。

ユーザ端末３は、ユーザが使用する端末である。ユーザとは、制御システム１によるゲームをプレイし得る者を意味する。ユーザ端末３は、ユーザが使用する端末を便宜的に示すものであり、ユーザが専用的に使用する端末を意味しない。ユーザ端末３のタイプは何でもよい。例えばタブレット型コンピュータ（いわゆるスマートフォンを含む）、デスクトップ型コンピュータ、ノート型コンピュータ、ゲーム機またはウェアラブル端末をユーザ端末３として機能させることができる。

図３は、サーバ２およびユーザ端末３の機能構成例を示すブロック図である。図３で示すように、サーバ２は機能構成として、サーバ制御部１０と、サーバ通信部１１と、サーバ記憶部１２とを備える。ユーザ端末３は機能構成として、端末制御部１３と、端末通信部１４と、端末表示部１５と、端末入力部１６と、端末記憶部１７とを備える。

サーバ２のサーバ制御部１０は、処理装置と一次記憶装置とを備える。処理装置は、情報処理機能を有する装置であり、ＣＰＵを備える。ＣＰＵは、制御装置と、演算装置と、レジスタと、キャッシュメモリとを備える。一次記憶装置は、ＤＲＡＭ、その他の揮発性メモリを備える。サーバ制御部１０は、処理装置がサーバ記憶部１２（他の記憶領域でもよい）に記憶されたプログラムを一次記憶装置に読み出して実行することによって処理を実行する。つまりサーバ制御部１０は、ハードウェアとソフトウェアとの協働により処理を実行する。サーバ通信部１１は、外部装置と通信する機能を有する通信装置を備える。通信装置は、通信制御装置とネットワークインタフェイスとを備える。サーバ通信部１１は、サーバ制御部１０の制御の下で通信装置により外部装置と通信する。以下ではサーバ２によるネットワークＮを利用した通信、その他の通信は、サーバ通信部１１により適切に行われるものとして詳細な説明を省略する。サーバ記憶部１２は、ハードディスクドライブ（他の磁気記憶装置であってもよい）、ＲＯＭ、フラッシュメモリ、その他の不揮発性メモリを備える。サーバ記憶部１２は、不揮発性メモリにデータを記憶する。

図３で示すように、サーバ通信部１１には、データベースサーバ２０が接続される。データベースサーバ２０には、ノード定義データ管理データベース２１および実行中ゲーム管理データベース２２が記憶される。以下、ノード定義データ管理データベース２１は「データ管理ＤＢ」と呼ばれ、実行中ゲーム管理データベース２２は「ゲーム管理ＤＢ」と呼ばれる。サーバ制御部１０はデータ管理ＤＢおよびゲーム管理ＤＢにアクセスすることができる。図３は、サーバ２とデータベースサーバ２０とが直接接続された図となっている。しかしながらサーバ２とデータベースサーバ２０との接続形態は限定されない。サーバ２とデータベースサーバ２０とはネットワークＮを介して接続されてもよく、ＬＡＮを介して接続されてもよく、有線または無線により直接接続されてもよい。

ユーザ端末３の端末制御部１３は、情報処理機能を有する処理装置と一次記憶装置とを備える。端末制御部１３は、処理装置が端末記憶部１７（他の記憶領域でもよい）に記憶されたプログラムを一次記憶装置に読み出して実行することによって処理を実行する。つまり端末制御部１３は、ハードウェアとソフトウェアとの協働により情報処理を実行する。端末通信部１４は、通信制御装置とネットワークインタフェイスとを有する通信装置を備える。端末通信部１４は、端末制御部１３の制御の下で通信装置により外部装置と通信する。以下ではユーザ端末３によるネットワークＮを利用した通信、その他の通信は、端末通信部１４により適切に行われるものとして詳細な説明を省略する。端末表示部１５は、液晶パネル、有機ＥＬパネル、その他の表示装置を備える。端末表示部１５は、端末制御部１３の制御の下で表示装置に画像を表示する。端末入力部１６は、キーボード、マウス、タッチパネル、その他の入力装置を備える。端末入力部１６は、入力装置に対する入力を検出し、検出結果を端末制御部１３に出力する。端末記憶部１７は、不揮発性メモリを備える。端末記憶部１７は、不揮発性メモリにデータを記憶する。

図３で示すようにユーザ端末３には、ゲームに関するアプリケーションＡＰ（以下「ゲームアプリＡＰ」という）がダウンロードされている。以下、ゲームアプリＡＰに対応するゲームを「本件ゲーム」という。ゲームアプリＡＰは例えば、スマートフォン向けのアプリケーションである。この場合、ゲームアプリＡＰは例えば、アプリケーションのダウンロードサービスを利用して、ユーザ端末３にダウンロードされる。ゲームアプリＡＰは、本件ゲームに関する各種画面を提供する機能、ユーザによる操作を受け付けて操作に対応する処理を実行する機能、サーバ２との間で各種情報を送受信する機能、その他の本件ゲームに関する処理を実行する機能を備えている。

本実施形態では、以下のボーナスゲームが一例として利用される場合がある。ボーナスゲームは例えば、ユーザによって本件ゲームがプレイされているときに、所定の事象が発生したことをトリガとして本件ゲーム内で開始される。以下、ボーナスゲームが利用される例は「本件例」と呼ばれる。図４は、ボーナスゲームの説明に利用される図である。ボーナスゲームに関し、ユーザは、ポイントを保有する。ポイントの単位は「ｐｔ」である。図４の符号Ｚ４Ａで示すように、ボーナスゲームでは、最初に選択前画面Ｇ１が端末表示部１５に表示される。選択前画面Ｇ１には、４枚のカードの裏面が描画される。カードの中身は、アタリかハズレである。ユーザがアタリのカードを選択するとポイント残高が１０００ｐｔ増加し、ハズレのカードを選択するとポイント残高は変化しない。ユーザは、カーソルを利用して４枚のカードから１枚を指定し、確定ボタンＢ１を操作することによって１枚のカードを選択する。すると符号Ｚ４Ｂで示すように、ユーザが選択したカードがアタリのカードであったのかハズレのカードであったのかが明示された選択後画面Ｇ２が端末表示部１５に表示される。またアタリであったのかハズレであったのかに応じて、ユーザのポイント残高が変動する。ユーザは、当該画面の内容を確認し、ボーナスゲームを終了する場合には、終了ボタンＢ２を操作する。

ここで端末とサーバとの協働により提供されるゲームでは、不正行為が行われる場合がある。ボーナスゲームに関して言えば、何ら手当しない場合には、ハズレのカードが選択されたときにポイント残高を増加させたり、アタリのカードが選択されたときにポイント残高を１０００００ｐｔ増加させたりする不正行為が行われ得る。不正行為は典型的には、端末のプログラム（本実施形態では、ゲームアプリＡＰまたはこれに付随するプログラム）の改変、または、端末とサーバとの間で行われる通信の改ざんによって行われる。後に明らかとなるように、本実施形態に係る制御システム１では、不正行為に対する耐性の向上が実現されている。

後に明らかとなる通りボーナスゲームは、対応するノード定義データＮＤ（後述）が利用されてゲームが進行される。以下、ボーナスゲームのように、ゲームの進行にノード定義データＮＤが利用されるゲームは「単位ゲーム」と呼ばれる。本実施形態では、ユーザによって単位ゲームが行われ得る状況となる前に、単位ゲームに対応するノード定義データＮＤがサーバ２にアップロードされ、データ管理ＤＢに記憶される。なお「ユーザによって単位ゲームが行われ得る状況となる前」とは、例えば対応するゲームアプリＡＰがリリースされる前、または、本件ゲームのアップデートによって単位ゲームをプレイ可能となる前である。以下、単位ゲームに対応するノード定義データＮＤがデータ管理ＤＢに記憶されるまでの流れの一例が説明される。

まず本件ゲームを開発する主体は、単位ゲームに対応するノード定義データＮＤを作成する。以下、本件ゲームを開発する主体は「開発者」と呼ばれる。図５は、ボーナスゲームに対応するノード定義データＮＤの内容が、説明に適した態様で単純化されて示された図である。以下、ボーナスゲームに対応するノード定義データＮＤは「本件ノード定義データＮＤａ」と呼ばれる。ノード定義データＮＤは、単位ゲームの進行に利用されるデータ／ファイルである。ノード定義データＮＤは、少なくとも単位ゲームのノードの管理、および、単位ゲームに関する所定の事項の状態の管理に利用される。ノードとは、単位ゲームがとり得る状態を意味する。ここでの状態は、状態遷移図（ステートマシン図）によって表現される各状態を意味する。以下では、ノードとして管理される「単位ゲームの状態」は「ゲーム状態」と呼ばれる。

図６は、図５の本件ノード定義データＮＤａで定義されたノードに関する状態遷移図である。図６で示すように本件例では、ボーナスゲームが開始されると、ゲーム状態は待機ノードに遷移される。ゲーム状態が待機ノードのときにカード選択イベントが発生すると、ゲーム状態は抽選ノードに遷移される。ノードの遷移に関し、イベントとは、ノードの遷移のトリガとなる事象（トリガ事象）を意味する。イベントには、パラメータを付加可能である。パラメータは、例えばイベントの実行後に実行されるプログラム／関数に引き渡される引数である。ゲーム状態が抽選ノードのときに抽選完了イベントが発生すると、ゲーム状態は待機ノードに遷移される。ゲーム状態が待機ノードのときに終了イベントが発生すると、ゲーム状態は終了ノードに遷移される。ゲーム状態が終了ノードに遷移されるとボーナスゲームは終了する。各ノードおよび各イベントの内容は後に明らかとなる。本件例では、図６で示す状態遷移に従ってノードが遷移することによって、ボーナスゲームが進行していく。

ノード定義データＮＤには、状態変数情報を定義可能である。状態変数情報には、単位ゲームに関する所定の事項の状態を示す状態変数が定義される。図５で示すように本件ノード定義データＮＤａには、状態変数として、選択回数＜項目＞、ポイント残高＜項目＞および抽選結果＜項目＞が定義される。なお本実施形態において「＜項目＞」という表現は、対応する用語が値を持つ項目／変数であることを示す。選択回数＜項目＞には、ボーナスゲームにおいてユーザによってカードの選択が行われた回数を示す値が格納される。ポイント残高＜項目＞には、ユーザのポイント残高を示す値が格納される。抽選結果＜項目＞には、カードの選択の結果を示す値が格納される変数である。

またノード定義データＮＤには、初期ノード情報が定義される。初期ノード情報には、単位ゲームの開始時に最初に遷移すべきノード（以下「初期ノード」という）が定義される。図５で示すように本件ノード定義データＮＤａには、初期ノードとして待機ノードが定義される。またノード定義データＮＤには、複数のノードのそれぞれについて、個別ノード情報が定義される。ノード定義データＮＤに個別ノード定義情報が定義されることは、ノード定義データＮＤにノードが定義されることに相当する。個別ノード定義情報には、受容イベント情報、遷移時処理情報および完了時発行イベント情報が定義可能である。

受容イベント情報には、自ノードにゲーム状態が滞留しているときに受け付けるイベントが定義される。受容イベント情報には、イベントの種類、名称、その他の識別情報が記述されることによって、イベントが定義される。以下、受容イベント情報に定義されたイベントは「受容イベント」と呼ばれる。ゲーム状態が一のノードに滞留しているときに、当該一のノードに定義された受容イベントが発生した場合には、後述する遷移ルールに従って、当該一のノードから他のノードへの遷移が行われる。

遷移時処理情報には、自ノードに遷移した場合に実行される処理である遷移時処理が定義される。遷移時処理情報には、遷移時処理に対応するプログラムの識別情報（例えば関数名）が記述されることによって、遷移時処理が定義される。また遷移時処理情報には、遷移時処理に対応するプログラム（スクリプト）が直接、記述されることによって遷移時処理が定義される。遷移時処理には、状態変数の値を変化させる処理が含まれ得る。ゲーム状態が一のノードから他のノードへと遷移した場合において、当該他のノードに１つ以上の遷移時処理が定義されているときは、定義された遷移時処理のそれぞれが実行される。

完了時発行イベント情報には、自ノードに遷移された後、自ノードに定義された遷移時処理のそれぞれの実行が完了した後に発行すべきイベントが定義される。ただし、自ノードに遷移時処理が定義されていない場合には、自ノードに遷移された後、遷移時処理が実行されることなく、完了時発行イベント情報に定義されたイベントが発行される。完了時発行イベント情報には、イベントの種類、名称、その他の識別情報が記述されることによって、イベントが定義される。以下、完了時発行イベントに定義されたイベントを「完了時発行イベント」という。ゲーム状態が一のノードから他のノードへと遷移した場合、当該他のノードに遷移時処理が定義されているときは、遷移時処理が実行される。当該他のノードに遷移時処理が定義されていないときは、遷移時処理は実行されない。その後、当該他のノードに完了時発行イベントが定義されているときは、完了時発行イベントが発行される。なお本実施形態では、説明の便宜のため、初期ノードには、完了時発行イベントが定義されないものとする。つまり本実施形態では、初期ノードへの移行に応じて完了時発行イベントが発行されることはない。

図５で示すように本件ノード定義データＮＤａには、待機ノード、抽選ノードおよび終了ノードのそれぞれの個別ノード情報が定義されている。つまり本件ノード定義データＮＤａには、待機ノード、抽選ノードおよび終了ノードが定義されている。待機ノードに着目すると、待機ノードには、受容イベントとしてカード選択イベントおよび終了イベントが定義されている。これはゲーム状態が待機ノードのときにカード選択イベントまたは終了イベントが発生した場合には、後述する遷移ルールに従って他のノードへの遷移が行われることを意味する。また待機ノードには、遷移時処理および完了時発行イベントは定義されていない。これは、ボーナスゲームが待機ノードに遷移した後に、遷移時処理の実行、および、完了時発行イベントの発行が行われないことを意味する。また抽選ノードに注目すると、抽選ノードには、受容イベントとして抽選完了イベントが定義されている。これはゲーム状態が抽選ノードのときに抽選完了イベントが発生した場合には、後述する遷移ルールに従って他のノードへの遷移が行われることを意味する。また抽選ノードには、遷移時処理として抽選処理が定義されている。これはゲーム状態が抽選ノードに遷移されたときに、抽選処理が実行されることを意味する。また抽選ノードには、完了時発行イベントとして抽選完了イベントが定義されている。これはゲーム状態が抽選ノードに遷移され、抽選処理が完了した後に、抽選完了イベントが発行されることを意味する。

ノード定義データＮＤには、遷移ルール情報が定義される。遷移ルール情報には、ノードの遷移に関するルールである遷移ルールが定義される。遷移ルールには、ノードの遷移のトリガとなるイベント（トリガ事象）と、イベントが発生したときのノードの遷移の態様とが定義される。本実施形態では、遷移ルールには、遷移前のノード（ノードを示す識別情報）と、ノードの遷移のトリガとなるイベント（イベントを示す識別情報）と、遷移後のノード（ノードを示す識別情報）との組合せが定義される。例えば、遷移ルールＪＡについて、遷移前のノードとしてノードＮＡが、ノードの遷移のトリガとなるイベントとしてイベントＩＶが、遷移後のノードとしてノードＮＢが定義されているとする。この場合、遷移ルールＪＡは、ゲーム状態がノードＮＡのときに、イベントＩＶが発生した場合、ゲーム状態がノードＮＡからノードＮＢに遷移されることを示す。

図５で示すように本件ノード定義データＮＤａには、遷移ルールＪ１～Ｊ３が定義されている。遷移ルールＪ１は、遷移前のノードとして待機ノードが、ノードの遷移のトリガとなるイベントとしてカード選択イベントが、遷移後のノードとして抽選ノードが定義されている。この遷移ルールＪ１は、ゲーム状態が待機ノードのときに、カード選択イベントが発生した場合、待機ノードから抽選ノードに遷移されることを示す。遷移ルールＪ２～Ｊ３の内容は図５で示す通りである。図６では、ノードの遷移となるトリガとなるイベントと対応付けて、対応する遷移ルールが明示されている。

本実施形態ではノード定義データＮＤは、所定のプログラム言語によるプログラムが記述されたプログラムファイルである。ノード定義データＮＤには、当該所定のプログラム言語によって各種情報が記述される。当該所定のプログラム言語は、ノード定義データＮＤに特化された専用のプログラム言語である。ただし、当該所定のプログラム言語は、ＨＴＭＬ、その他の既存のプログラム言語であってもよい。例えば開発者は、サーバ２の管理者が提供するツールまたはソフトウェア開発キットを利用してノード定義データＮＤを作成する。なお本実施形態ではノード定義データＮＤは、プログラムによって情報が記述されたプログラムファイルである。しかしながらノード定義データＮＤは、プログラムファイルではなく、ＪＳＯＮ、その他の記述方式で情報が記述されたデータであってもよい。またノード定義データＮＤは、独自のフォーマットで情報が記述されたデータであってもよい。また１つのノード定義データＮＤが、他の１つ以上のノード定義データＮＤを参照する構成でもよい。この場合、複数のノード定義データＮＤの組合せが、「ノード定義データ」として機能する。なおノード定義データＮＤは、状態遷移に関する情報が記録されたデータであり、ステートマシーンに相当すると言える。

さて開発者は、ノード定義データＮＤを作成した後、当該データをサーバ２にアップロードする。サーバ２は、開発者に対してノード定義データＮＤをアップロードする手段を提供する。ノード定義データＮＤがアップロードされるとサーバ２のサーバ制御部１０は、以下の処理を実行する。すなわちサーバ制御部１０は、アップロードされたノード定義データＮＤを識別する一意な値のデータＩＤを生成する。次いでサーバ制御部１０は、データベースサーバ２０のデータ管理ＤＢに、生成したデータＩＤと、アップロードされたノード定義データＮＤとを含むレコードを登録する。ただしレコードには、ノード定義データＮＤに代えて、当該データの格納場所のアドレス、当該データの格納場所までのパス、その他の当該データにアクセスするための情報が格納されてもよい。図７は、データ管理ＤＢの１件のレコードの内容を示す。更にサーバ制御部１０は、生成したデータＩＤを所定の方法で開発者に通知する。以上の処理が行われる結果、ユーザによって単位ゲームが行われ得る状況となる前に、データＩＤとノード定義データＮＤとが対応付けられたレコードがデータ管理ＤＢに登録される。また開発者にデータＩＤが通知される。

以上が、ノード定義データＮＤがデータ管理ＤＢに記憶されるまでの流れの一例である。ただし例示した流れは一例であり、例示した流れとは異なる流れでノード定義データＮＤがデータ管理ＤＢに記憶されてもよい。本実施形態では単位ゲームのそれぞれについて、データＩＤとノード定義データＮＤとを含むレコードがデータ管理ＤＢに登録される。なお開発者、その他の権限を有する主体は、データ管理ＤＢに記憶されたノード定義データＮＤの内容を変更することができる。

次に制御システム１の動作が説明される。以下では、特にユーザによって単位ゲームが行われる場合の制御システム１の動作が説明される。図８は、単位ゲームが行われている期間の制御システム１の動作例を示すフローチャートである。図８のフローチャートＦＡはユーザ端末３の動作例を示し、フローチャートＦＢはサーバ２の動作例を示す。図８のフローチャートの開始時点では、ユーザ端末３においてゲームアプリＡＰが起動されており、ユーザが本件ゲームをプレイしているものとする。以下では、本件例に関し、ボーナスゲームをプレイするユーザは特に「注目ユーザ」と呼ばれる。そして、注目ユーザがボーナスゲームをプレイする前の時点では、注目ユーザのポイント残高は１０００ｐｔであるものとする。

フローチャートＦＡで示すように、本件ゲーム内で単位ゲームを開始するトリガとなる事象が発生した場合、ユーザ端末３の端末制御部１３は、単位ゲームの開始を通知する開始通知情報をサーバ制御部１０に送信する（ステップＳＡ１）。開始通知情報には、単位ゲームに対応するノード定義データＮＤのデータＩＤが含まれる。このように本実施形態では、単位ゲームごとに、ノード定義データＮＤがデータＩＤと対応付けてデータ管理ＤＢに記憶される。そしてユーザ端末３において単位ゲームが開始されると、端末制御部１３は、単位ゲームに対応するノード定義データＮＤのデータＩＤをサーバ制御部１０に送信する。

フローチャートＦＢで示すようにサーバ２のサーバ制御部１０は、開始通知情報を受信すると、対応するノード定義データＮＤを取得する（ステップＳＢ１）。詳述するとサーバ制御部１０は、データ管理ＤＢを参照し、開始通知情報に含まれるデータＩＤに対応するレコードを特定する。次いでサーバ制御部１０は、特定したレコードのノード定義データＮＤを取得する。このようにサーバ制御部１０は、データ管理ＤＢに記憶された任意のノード定義データＮＤを取得することができる。これは、サーバ制御部１０が、データ管理ＤＢに記憶された任意のノード定義データＮＤを利用できる状態であることを意味する。

ステップＳＢ１の処理後、サーバ制御部１０は、サーバ側初回起動処理を実行する（ステップＳＢ２）。詳述すると、まずサーバ制御部１０は、ステップＳＢ１で取得したノード定義データＮＤのインスタンスを生成する。「ノード定義データＮＤのインスタンスを生成する」とは、一次記憶装置、その他のメモリの領域にノード定義データＮＤの領域を確保し、サーバ制御部１０がノード定義データＮＤに基づく処理を実行可能な状態とすることを意味する。このように本実施形態では、ノード定義データＮＤは、インスタンスの基礎となるクラスとして機能する。

ノード定義データＮＤのインスタンスが生成されると、ノード定義データＮＤに対応するノード関連情報の項目のそれぞれについてメモリに領域が確保され、各項目に値を格納可能な状態となる。ノード関連情報とは、ノード定義データＮＤおよびノード定義データに対応する単位ゲームにおいて利用される情報である。ノード関連情報は、ノード定義データＮＤのインスタンスの生成に応じてメモリに領域が確保される複数の項目／変数によって構成される。ノード定義データＮＤのインスタンスの生成に応じて、サーバ制御部１０が、ノード関連情報の各項目に値を格納し、各項目の値を更新し、各項目の値を参照することができるようになる。

図９はノード関連情報の内容を示す図である。図９で示すように本実施形態ではノード関連情報には、実行中ゲームＩＤ＜項目＞、乱数シード＜項目＞、ノード遷移回数＜項目＞、現在ノード＜項目＞、および、ノード定義データＮＤに定義された状態変数のそれぞれが含まれる。図９では、状態変数は、第１状態変数、第２状態変数…のように表現されている。実行中ゲーム＜項目＞および乱数シード＜項目＞は初期値が格納された後、値が変化しない。ノード遷移回数＜項目＞、現在ノード＜項目＞、および、状態変数のそれぞれは、単位ゲームの進行に応じて値が変化し得る項目である。以下、これら項目をまとめて設定情報という。設定情報の各項目のうち、ノード遷移回数＜項目＞および現在ノード＜項目＞は、状態変数として定義されていない項目である。以下、これら項目をまとめて管理情報という。以下、「ノード関連情報の各項目の値」は、単に「ノード関連情報の値」と表現される場合がある。複数の項目により構成される他の情報についても同様である。

さてノード定義データＮＤのインスタンスを生成した後、サーバ制御部１０は、ノード関連情報の各項目のそれぞれに初期値をセットする。詳述すると実行中ゲームＩＤ＜項目＞には、生成したインスタンスの識別情報である実行中ゲームＩＤが格納される。サーバ制御部１０は、一意な値の実行中ゲームＩＤを生成し、初期値として実行中ゲームＩＤ＜項目＞に格納する。乱数シード＜項目＞には、乱数シードが格納される。乱数シードは、乱数生成器による乱数の生成に際して、乱数生成器に入力される値である。本実施形態において乱数生成器は、漸化式を用いて乱数を発生させるモジュールであり、１つの乱数シードから連続して乱数を出力することができる。本実施形態では、単位ゲームに関してサーバ２とユーザ端末３とのそれぞれは、共通する乱数生成器を利用可能である。乱数生成器が共通するとは、乱数生成器に対応する漸化式が同じであることを意味する。従って、互いに共通する乱数生成器は、入力値が同じであれば出力値が同じである。以下、単位ゲームに関してサーバ２が利用する乱数生成器を「サーバ側乱数生成器」という。サーバ側乱数側生成器は、例えばデータベースサーバ２０に記憶され、また例えばサーバ記憶部１２に記憶される。また単位ゲームに関してユーザ端末３が利用する乱数生成器を「端末側乱数生成器」という。サーバ制御部１０は、所定形式のランダムな値を生成する機能を有するプログラムを利用して乱数シードを生成し、初期値として乱数シード＜項目＞に格納する。

ノード遷移回数＜項目＞には、単位ゲームが行われている間に行われたノードの遷移の回数を示すノード遷移回数が格納される。サーバ制御部１０は、０回を示すノード遷移回数を初期値としてノード遷移回数＜項目＞に格納する。現在ノード＜項目＞には、現時点でゲーム状態が滞留するノード（以下「現在ノード」という）を示す現在ノード情報が格納される。サーバ制御部１０は、ノードの遷移が行われていないことを示すダミー値を初期値として現在ノード＜項目＞に格納する。またサーバ制御部１０は、状態変数のそれぞれに、適切な初期値を格納する。本件例ではサーバ制御部１０は、選択回数＜項目＞に０回を示す選択回数を格納し、ポイント残高＜項目＞に１０００ｐｔを示すポイント残高を格納し、抽選結果＜項目＞にアタリでもハズレでもないことを示すダミー値を格納する。なおサーバ制御部１０は、ユーザ管理データベース（不図示）から注目ユーザのポイント残高を取得する。ユーザ管理データベースは、データベースサーバ２０に記憶される。なおノード関連情報の各項目の値は、実際には、定義されたデータ型に準じた適切な表現形式で表現される。

以上がサーバ側初回起動処理である。サーバ側初回起動処理により、サーバ制御部１０がノード定義データＮＤに基づいて処理を実行可能な状態となると共に、生成されたインスタンスに対応するノード関連情報の各項目のそれぞれに初期値が格納される。以下の説明では、サーバ制御部１０が生成したインスタンスの基礎となったノード定義データＮＤは「サーバ側ノード定義データＮＤｓ」と呼ばれる。またサーバ制御部１０が、生成したインスタンスを利用して処理を実行することは、「サーバ側ノード定義データＮＤｓに基づいて処理を実行する」または「サーバ側ノード定義データＮＤｓを利用して処理を実行する」と表現される。またサーバ制御部１０が生成したインスタンスに対応するノード関連情報、設定情報、管理情報および状態変数はそれぞれ、サーバ側ノード関連情報、サーバ側設定情報、サーバ側管理情報およびサーバ側状態変数と呼ばれる。

なおサーバ側初回起動処理では、説明した処理だけが行われるのではなく、サーバ制御部１０がノード定義データＮＤに基づいて処理を実行可能な状態を構築するために必要な処理が適切に実行される。特に説明がされない場合であっても、処理の目的を達成するために必要な処理が行われる点は、他の処理についても同様である。

ステップＳＢ２の処理後、サーバ制御部１０は、ゲーム管理ＤＢに１件の新たなレコードを登録する（ステップＳＢ３）。登録されるレコードにはサーバ側ノード関連情報の各項目の値が含まれる。ただし、この段階では、サーバ側ノード関連情報の各項目の値は、初期値である。以下では、ゲーム管理ＤＢのレコードに含まれるノード関連情報について、ノード関連情報、設定情報、管理情報および状態変数はそれぞれ、登録ノード関連情報、登録設定情報、登録管理情報および登録状態変数と呼ばれる。図１０は、本件例に関して、ステップＳＢ３でゲーム管理ＤＢに登録されるレコードの内容を示す。なお図１０の例では、ゲーム実行中ＩＤの値を「ＧＭ０１」とし、乱数シードの値を適当な値としている。

ステップＳＢ３の処理後、サーバ制御部１０は、ステップＳＢ１で取得したノード定義データＮＤと、ステップＳＢ３でゲーム管理ＤＢに登録したレコードに含まれる登録ノード関連情報とを端末制御部１３に送信する（ステップＳＢ４）。なお端末制御部１３からサーバ制御部１０へのノード定義データＮＤの送信は、例えばユーザ端末３がノード定義データＮＤをサーバ２からダウンロードすることによって行われる。ステップＳＢ４の処理後、ステップＳＢ２のサーバ側初回起動処理で生成されたインスタンスは破棄される。

フローチャートＦＡで示すように端末制御部１３は、ステップＳＢ４でサーバ制御部１０が送信したノード定義データＮＤおよび登録ノード関連情報を受信し、各データを端末記憶部１７に記憶する（ステップＳＡ２）。ステップＳＡ２の処理により、端末制御部１３が、ノード定義データＮＤを利用可能な状態となる。このように本実施形態では、単位ゲーム（ゲーム）の提供の前に、サーバ２とユーザ端末３とのそれぞれが、単位ゲームに対応する共通のノード定義データＮＤを利用可能な状態が構築される。

ステップＳＡ２の処理後、端末制御部１３は、端末側起動処理を実行する（ステップＳＡ３）。ステップＳＡ３において端末制御部１３は、ステップＳＡ２で受信したノード定義データＮＤのインスタンスを生成し、ノード定義データＮＤに基づいて処理を実行可能な状態を構築する。インスタンスの生成に応じて、ノード関連情報の各項目のそれぞれについてメモリに領域が確保され、各項目に値を格納可能な状態となる。以下の説明では、端末制御部１３が生成したインスタンスの基礎となったノード定義データＮＤは便宜的に「端末側ノード定義データＮＤｄ」と呼ばれる。また端末制御部１３が、生成したインスタンスを利用して処理を実行することは、「端末側ノード定義データＮＤｄに基づいて処理を実行する」または「端末側ノード定義データＮＤｄを利用して処理を実行する」と表現される。また端末制御部１３が生成したインスタンスに対応するノード関連情報、設定情報、管理情報および状態変数はそれぞれ、端末側ノード関連情報、端末側設定情報、端末側管理情報および端末側状態変数と呼ばれる。後に明らかとなる通り端末側設定情報の各項目の値は、単位ゲームの進行に応じて、端末制御部１３によって更新される。

端末制御部１３は、端末側ノード関連情報の値を、ステップＳＡ２で受信した登録ノード関連情報に基づいて初期化する。端末側ノード関連情報の値を登録ノード関連情報に基づいて初期化するとは、端末側ノード関連情報の各項目のそれぞれに、受信した登録ノード関連情報の各項目の値のそれぞれを格納することを意味する。この結果、端末側ノード関連情報の各項目には、初期値が格納された状態となる。

ステップＳＡ３の処理後、端末制御部１３は、ゲーム進行処理を開始する（ステップＳＡ４）。ゲーム進行処理は、端末制御部１３が、端末側ノード定義データＮＤｄを利用して、単位ゲームを進行する処理である。以下、ゲーム進行処理の内容が詳述される。図１１のフローチャートＦＣは、単位ゲームの進行に関して、端末制御部１３が端末側ノード定義データＮＤｄに基づいて実行する処理を示す。なお単位ゲームの進行にあたっては、フローチャートＦＣで示される処理のほか、各種画面の提供、音声の出力、ユーザによる操作の受け付け、その他の本件ゲームに関する処理は当然に実行される。

図１１のフローチャートＦＣで示すように端末制御部１３は、端末側ノード定義データＮＤｄの初期ノード情報に基づいて、単位ゲームのゲーム状態を初期ノードに遷移させる（ステップＳＣ１）。初期ノードへの遷移に応じて端末制御部１３は、端末側管理情報であるノード遷移回数＜項目＞の値をインクリメントし、更に現在ノード＜項目＞に初期ノードを示す値を格納する。なお本実施形態では、特に説明されない場合であっても、ノードの遷移があると、ノード遷移回数＜項目＞および現在ノード＜項目＞の値が更新される。次いで端末制御部１３は、初期ノードに遷移時処理が定義されているか否かを判別する（ステップＳＣ２）。定義されている場合（ステップＳＣ２：ＹＥＳ）、端末制御部１３は、遷移時処理を実行する（ステップＳＣ３）。なお遷移時処理が状態変数の値の変化をもたらすような処理の場合、遷移時処理の実行に応じて状態変数の値が更新される。この点は、以下においても同様である。ステップＳＣ３の処理後、端末制御部１３は、処理手順をステップＳＣ４に移行する。初期ノードに遷移時処理が定義されていない場合（ステップＳＣ２：ＮＯ）、端末制御部１３は、処理手順をステップＳＣ４に移行する。

ステップＳＣ４において端末制御部１３は、ノードの遷移のトリガとなるイベントが発生したか否かを監視する。なお後述するステップＳＣ１１で発行された完了時発行イベントが、ノードの遷移のトリガとなるイベントとなるケースもある。ノードの遷移のトリガとなるイベントが発生した場合（ステップＳＣ４：ＹＥＳ）、端末制御部１３は、遷移再現情報記録処理を実行する（ステップＳＣ５）。遷移再現情報記録処理は、ノードの遷移を再現可能な遷移再現情報をログＬＧとしてログデータＬＤに記録する処理である。ログデータＬＤは、単位ゲームの開始に応じて生成され、端末記憶部１７の所定の記憶領域に記憶される。特に本実施形態では遷移再現情報記録処理は、ノードの遷移のトリガとなるイベントが発生したときに、発生したイベントの内容を示すイベント内容情報をログデータＬＤに記録する処理である。つまり本実施形態では、イベント内容情報が遷移再現情報に相当する。

イベント内容情報のログデータＬＤへの記録に関し、端末制御部１３は、イベントが発生したタイミングを示すイベントタイミング情報と、ログの種類がイベントであることを示す情報と、イベント内容情報とをフォーマットに従ってログデータＬＤに記録する。本実施形態ではイベントタイミング情報は、イベントが発生した日時（日付＋時刻）を示す情報である。ただしイベントタイミング情報は、イベントが発生したタイミングの時系列を把握可能な情報であればよい。この点は後述する状態取得タイミング情報についても同様である。イベント内容情報は、イベントの識別情報を含む。またイベントにパラメータが付加されている場合には、イベント内容情報には、付加されたパラメータの値が含まれる。

ステップＳＣ４でイベントが発生したと判定した場合（ステップＳＣ４：ＹＥＳ）、端末制御部１３は、更に以下の処理を実行する。すなわち端末制御部１３は、端末側ノード定義データＮＤｄに定義された遷移ルールに従ってノードを遷移させる（ステップＳＣ６）。端末制御部１３は、ノードの遷移に応じて端末側設定情報を更新する。ステップＳＣ６の処理後、端末制御部１３は、遷移後のノードに遷移時処理が定義されているか否かを判別する（ステップＳＣ７）。定義されている場合（ステップＳＣ７：ＹＥＳ）、端末制御部１３は、遷移時処理を実行し（ステップＳＣ８）、処理手順をステップＳＣ９へ移行する。定義されていない場合（ステップＳＣ７：ＮＯ）、端末制御部１３は、処理手順をステップＳＣ９へ移行する。

ステップＳＣ９において端末制御部１３は、端末側設定情報記録処理を実行する。端末側設定情報記録処理は、端末側設定情報の値をログとしてログデータＬＤに記録する処理である。特に本実施形態では端末制御部１３は、端末側設定情報の値として、端末側設定情報の値のハッシュ値である状態ハッシュ値をログデータＬＤに記録する。詳述すると端末制御部１３は、現時点の端末側設定情報の各項目の値を取得する。端末側設定情報の各項目は、管理情報と状態変数とを含む。次いで端末制御部１３は、端末側設定情報の各項目のそれぞれの値をルール（以下「配列ルール」という）に従って配列したデータ（以下「配列データ」という）を生成する。次いで端末制御部１３は、所定のハッシュ関数を用いて配列データのハッシュ値を導出する。ここで導出されたハッシュ値が状態ハッシュ値である。次いで端末制御部１３は、現時点を示す状態取得タイミング情報と、ログの種類が端末側設定情報であることを示す情報と、状態ハッシュ値とをフォーマットに従ってログデータＬＤに記録する。このように本実施形態では端末制御部１３は、ノードの遷移が行われた後、遷移後のノードに遷移時処理が定義されている場合には当該処理を実行し、その後、端末側設定情報の値（本実施形態では端末側設定情報の値に基づく状態ハッシュ値）をログＬＧとしてログデータＬＤに記録する。

ステップＳＣ９の処理後、端末制御部１３は、遷移後のノードに完了時発行イベントが定義されているか否かを判別する（ステップＳＣ１０）。定義されている場合（ステップＳＣ１０：ＹＥＳ）、端末制御部１３は、完了時発行イベントを発行し（ステップＳＣ１１）、処理手順をステップＳＣ４に戻す。定義されていない場合（ステップＳＣ１０：ＮＯ）、端末制御部１３は、処理手順をステップＳＣ４に戻す。

次に本件例においてユーザ端末３により実行されるゲーム進行処理が説明される。図１２のフローチャートＦＤは、本件例に係るゲーム進行処理の詳細を示す。なおフローチャートＦＤでは、説明の便宜のため、フローチャートの主軸には、ノードを遷移させる処理、および、遷移時処理のみが表記される。フローチャートＦＤにおいてイベントを発生させる処理、遷移再現情報記録処理、端末側設定情報記録処理、および、各種画面を表示する処理は、フローの主軸と関連付けて表記される。フローチャートＦＤにおいて、端末側ノード定義データＮＤｄの内容は、図５の本件ノード定義データＮＤａの内容である。

フローチャートＦＤで示すように端末制御部１３は、端末側ノード定義データＮＤｄの初期ノード情報に基づいて、ボーナスゲームのゲーム状態を待機ノードへ遷移させる（ステップＳＤ１）。待機ノードへの遷移に応じて端末制御部１３は、ノード遷移回数＜項目＞の値を０回から１回へとインクリメントし、更に現在ノード＜項目＞の値を、待機ノードを示す値へと更新する。ステップＳＤ１の処理後、端末制御部１３は、ゲームアプリＡＰの機能により選択前画面Ｇ１（図４参照）を端末表示部１５に表示する（ステップＳＤ２）。本実施形態では、ゲーム状態が待機ノードに遷移したときに、端末側状態変数の選択回数＜項目＞の値に応じた画面を表示する処理が行われるようにゲームアプリＡＰがプログラミングされている。ステップＳＤ２において端末制御部１３は、選択回数＜項目＞の値を参照し、カード選択の回数が０回であることを認識した上で、選択前画面Ｇ１を表示する。また端末制御部１３は、端末側状態変数のポイント残高＜項目＞の値を参照し、選択前画面Ｇ１にポイント残高を示す情報を表示する。このように状態変数は、単位ゲームが行われている間、ゲームアプリＡＰを実行する端末制御部１３により適宜、参照される。端末制御部１３は、選択前画面Ｇ１の表示後、当該画面の確定ボタンＢ１が注目ユーザによって操作されたか否かを監視する。

その後、注目ユーザにより選択前画面Ｇ１の確定ボタンＢ１が操作されると、端末制御部１３は、ゲームアプリＡＰの機能により、カード選択イベントを発行する（ステップＳＤ３）。カード選択イベントの発生に応じて端末制御部１３は、遷移再現情報記録処理を実行する（ステップＳＤ４）。図１３の符号ＬＧ１は、ステップＳＤ４の処理でログデータＬＤに新たに記録される第１ログの内容を示している。第１ログＬＧ１は、ステップＳＤ３のカート選択イベントが発生したタイミングを示すイベントタイミング情報と、第１ログＬＧ１の種類がイベントであることを示す情報と、ステップＳＤ３で発生したイベントの内容を示すイベント内容情報とを含む。

更にカード選択イベントの発生に応じて端末制御部１３は、端末側ノード定義データＮＤｄに定義された遷移ルールＪ１に基づいて、ゲーム状態を抽選ノードへ遷移させる（ステップＳＤ５）。端末制御部１３は、抽選ノードへの遷移に応じて端末側設定情報を適切に更新する。抽選ノードへの遷移に応じて端末制御部１３は、抽選ノードに遷移時処理として定義された抽選処理を実行する（ステップＳＤ６）。抽選処理とは、端末制御部１３が、端末側乱数生成器およびフローチャートＦＡのステップＳＡ２で受信した登録ノード関連情報に含まれる乱数シードを利用して、カードの選択の結果を決定する処理である。以下、抽選処理が詳述される。

抽選処理において端末制御部１３は、ステップＳＡ２で受信した乱数シードを端末側乱数生成器に入力し、その出力値（乱数）を得る。次いで端末制御部１３は、予め定められたルール（以下「抽選ルール」という）に従って、出力値から、カードの選択の結果を決定する。非常に単純化した例として、例えば乱数生成器は、乱数シードの入力に応じて０、１、２、３の４つの整数のうち、何れかを出力するよう構成される。この場合において抽選ルールは、出力値が０または１のときはカード選択の結果をアタリとし、出力値が２または３のときはカード選択の結果をハズレとするというルールとされる。

カードの選択の結果を決定した後、端末制御部１３は、端末側設定情報の必要な項目の値を更新する。具体的には端末制御部１３は、選択回数＜項目＞の値をインクリメントし、ポイント残高＜項目＞の値をカードの選択の結果に基づいて更新し、抽選結果＜項目＞にカード選択の結果を示す値を格納する。本件例では、カード選択の結果はアタリと決定されたものとする。従って本件例では、端末制御部１３は、選択回数＜項目＞の値を「１回」とし、ポイント残高＜項目＞の値を「２０００ｐｔ」とし、抽選結果＜項目＞にアタリを示す値を格納する。以上の通り端末制御部１３は、ノードの遷移に応じて乱数を使用する処理を実行する場合には、サーバ２から受信した乱数シードおよびユーザ端末３の乱数生成器を使用して処理を実行する。

ステップＳＤ６の処理後、端末制御部１３は、端末側設定情報記録処理を実行する（ステップＳＤ７）。図１３の符号ＬＧ２は、ステップＳＤ７の処理によってログデータＬＤに新たに記録される後の第２ログの内容を示している。第２ログＬＧ２は、現時点を示す状態取得タイミング情報と、ログＬＧの種類が端末側設定情報であることを示す情報と、現時点の端末側設定情報の各項目の値に基づく状態ハッシュ値とが記録される。

ステップＳＤ７の処理後、端末制御部１３は、抽選ノードに完了時発行イベントとして定義された抽選完了イベントを発行する（ステップＳＤ８）。抽選完了イベントの発生に応じて端末制御部１３は、遷移再現情報記録処理を実行する（ステップＳＤ９）。図１３の符号ＬＧ３は、ステップＳＤ９の処理でログデータＬＤに新たに記録される第３ログの内容を示している。抽選完了イベントの発生に応じて更に端末制御部１３は、端末側ノード定義データＮＤｄに定義された遷移ルールＪ２に基づいて、ゲーム状態を待機ノードへ遷移させる（ステップＳＤ１０）。端末制御部１３は、待機ノードへの遷移に応じて端末側設定情報を適切に更新する。待機ノードへの遷移に応じて端末制御部１３は、端末側設定情報記録処理を実行する（ステップＳＤ１１）。図１３の符号ＬＧ４は、ステップＳＤ１１の処理によってログデータＬＤに新たに記録される第４ログの内容を示している。待機ノードのへの遷移に応じて更に端末制御部１３は、選択後画面Ｇ２（図４参照）を端末表示部１５に表示する（ステップＳＤ１２）。端末制御部１３は、端末側状態変数の選択回数＜項目＞の値を参照し、カード選択の回数が１回であることを認識した上で、選択後画面Ｇ２を表示する。また端末制御部１３は、端末側状態変数のポイント残高＜項目＞の値および抽選結果＜項目＞の値を参照し、選択後画面Ｇ２の内容をこれら値に基づく内容とする。端末制御部１３は、選択後画面Ｇ２の表示後、当該画面の終了ボタンＢ２が注目ユーザによって操作されたか否かを監視する。

その後、注目ユーザから選択後画面Ｇ２の終了ボタンＢ２が選択されると、端末制御部１３は、ゲームアプリＡＰの機能により終了イベントを発行する（ステップＳＤ１３）。終了イベントの発生に応じて端末制御部１３は、遷移再現情報記録処理を実行する（ステップＳＤ１４）。図１３のＬＧ５は、ステップＳＤ１４の処理でログデータＬＤに新たに記録される第５ログの内容を示している。終了イベントの発生に応じて更に端末制御部１３は、端末側ノード定義データＮＤｄに定義された遷移ルールＪ３に基づいて、ゲーム状態を終了ノードへ遷移させる（ステップＳＤ１５）。端末制御部１３は、待機ノードへの遷移に応じて端末側設定情報を適切に更新する。待機ノードへの遷移に応じて端末制御部１３は、端末側設定情報記録処理を実行する（ステップＳＤ１６）。図１３の符号ＬＧ６は、ステップＳＤ１６の処理によってログデータＬＤに新たに記録される第６ログの内容を示している。終了ノードへの遷移に応じてボーナスゲームは終了する。

以上、ゲーム進行処理が説明された。以上の通り端末制御部１３は、ゲーム進行処理において以下の処理を実行する。すなわち端末制御部１３は、ユーザによってゲームが行われている間、ユーザ端末３のノード定義データＮＤに基づいてノードを自動で遷移させ、ノードの遷移に応じてユーザ端末３のノード定義データＮＤに対応する端末側設定情報の値を動的に変化させる。一方で、端末制御部１３は、ノードの遷移を再現可能な遷移再現情報およびノードの遷移に応じて変化した端末側設定情報の値をログＬＧとしてログデータＬＤに自動で記録する。より詳細には端末制御部１３は以下の処理を実行する。すなわち端末制御部１３は、ユーザによってゲームが行われている間、イベント（トリガ事象）が発生したか否かを継続して監視し、イベント（トリガ事象）の発生に応じて、ユーザ端末３のノード定義データＮＤの遷移ルールに基づいてノードを自動で遷移させ、ノードの遷移に応じて端末側設定情報の値を動的に変化させる。一方で、端末制御部１３は、発生したイベントの内容を示す遷移再現情報をログＬＧとしてログデータＬＤに自動で記録すると共に、ノードの遷移に応じて変化した端末側設定情報の値をログＬＧとしてログデータＬＤに自動で記録する。

以上の通り本実施形態では、単位ゲームを進行させるためのノードの遷移、および、ノードの遷移に伴う端末側設定情報の更新は、サーバ制御部１０ではなく、端末制御部１３が端末側ノード定義データＮＤｄに基づいて実行する。つまり端末制御部１３は、ノードの遷移および端末側設定情報の更新に関して、「サーバ２に必要な情報を通信によって送信し、サーバ２から処理結果が通信によって送られてくるのを待機する」といった、サーバ２との通信を伴う処理を実行しない。従って、単位ゲームの進行に関して、ユーザ端末３とサーバ２との間での通信の発生が抑制され、当該通信の発生に起因したゲームの進行の遅延が抑制される。

ただし端末制御部１３が端末側ノード定義データＮＤｄに基づいて単位ゲームを進行させる構成では、何ら手当がされない場合、以下の問題が生じ得る。すなわち単位ゲームが行われている間、端末制御部１３は、サーバ制御部１０に何らかの判断を行わせることなく、ノードを遷移させ、端末側設定情報を更新し、単位ゲームを進行させる。つまり単位ゲームの進行中、端末側設定情報の値の正しさは、サーバ制御部１０によって検証されない。このため不正行為によって、端末側設定情報の値が本来の正しい値から改変された場合であっても、端末側設定情報の値が誤った状態のままゲームが進行する、という問題がある。例えば、フローチャートＦＤのステップＳＤ６の抽選処理において、不正に改変されたプログラムの機能により、ポイント残高＜項目＞の値が２０００ｐｔ（本来の正しい値）から、１０００００ｐｔへと改変されたとする。この場合であっても、何ら手当がされない場合には、改変後のポイント残高＜項目＞の値の正しさはサーバ制御部１０によって検証されない。従って、何ら手当がされない場合には、ポイント残高＜項目＞の値が１０００００ｐｔのまま、ボーナスゲームが進行していくことになる。後に明らかとなるように、本実施形態では、このような不正行為に対する対策が行われ、不正行為に対する耐性の向上が実現されている。

さて図８で示すように、ステップＳＡ４でゲーム進行処理を開始した後、端末制御部１３は、ログＬＧの送信に関するログ送信条件が成立したか否かを監視しつつ（ステップＳＡ５）、単位ゲームが終了したか否かを監視する（ステップＳＡ６）。ステップＳＡ５およびステップＳＡ６の処理は、ステップＳＡ４で開始されたゲーム進行処理と並行して実行される。ログ送信条件とは、送信用ログデータＤＬ（後述）を送信する条件のことである。本実施形態では、所定の間隔（例えば、１秒、１０秒または３０秒）をあけて定期的に送信用ログデータＤＬの送信が行われるよう定められている。これを踏まえ本実施形態に係るログ送信条件は、定期的に発生するタイミングが到来したことという条件である。以下、送信用ログデータＤＬを送信するタイミングを「ログ送信タイミング」という。

ステップＳＡ５でログ送信条件が成立したと判定した場合（ステップＳＡ５：ＹＥＳ）、端末制御部１３は、ログ送信処理を実行し（ステップＳＡ７）、処理手順をステップＳＡ６へ移行する。一方、ステップＳＡ５でログ送信条件が成立していないと判定した場合（ステップＳＡ５：ＮＯ）、端末制御部１３は、処理手順をステップＳＡ６へ移行する。ステップＳＡ６において端末制御部１３は、単位ゲームが終了したと判定した場合（ステップＳＡ６：ＹＥＳ）、処理手順をステップＳＡ８へ移行し、終了していないと判定した場合（ステップＳＡ６：ＮＯ）、処理手順をステップＳＡ５へ戻す。ステップＳＡ８において端末制御部１３は、単位ゲームの終了を示す終了通知情報をサーバ制御部１０に送信する。終了通知情報には、対応する単位ゲームの実行中ゲームＩＤが少なくも含まれる。ステップＳＡ８の処理後、フローチャートＦＡの処理は終了する。

以下、ステップＳＡ７のログ送信処理が詳述される。ログ送信処理において、端末制御部１３は、ログデータＬＤに記録されたログＬＧのうち、サーバ２に未送信のログＬＧを特定し、特定したログＬＧのそれぞれを含む送信用ログデータＤＬを生成する。送信用ログデータＤＬには、時系列に沿って各ログＬＧが記録される。次いで端末制御部１３は、単位ゲームに対応するデータＩＤ、および、ステップＳＡ２で受信した登録ノード関連情報に含まれる実行中ゲームＩＤと共に送信用ログデータＤＬをサーバ制御部１０に送信する。以下、ログ送信処理により送信されるデータＩＤ、実行中ゲームＩＤおよび送信用ログデータＤＬの組合せは、「ログ関連データ」と呼ばれる。

例えば図１６で示すように、１回目のログ送信タイミングが、第４ログＬＧ４の記録が行われた後、第５ログＬＧ５の記録が行われる前に到来した場合、端末制御部１３は、第１～第４ログＬＧ１～ＬＧ４を含む送信用ログデータＤＬを送信する。その後、２回目のログ送信タイミングが、第６ログＬＧ６の記録が行われた後に到来した場合、端末制御部１３は、第５、第６ログＬＧ５、ＬＧ６を含む送信用ログデータＤＬを送信する。なお端末制御部１３は、ログ送信タイミングが到来したときに、未送信のログＬＧがない場合には、送信用ログデータＤＬの送信を行わない。ただし以下では、説明の便宜上、「端末制御部１３が、定期的に送信用ログデータＤＬを送信する」と表現する場合がある。

以上の通り本実施形態では端末制御部１３は、ユーザによって本件ゲームが行われている間、継続してログ送信条件が成立したか否かを監視する。そして端末制御部１３は、ログ送信条件が成立した場合、ログデータＬＤに記録されたログＧを含む送信用ログデータＤＬをサーバ２に自動で送信する。

さて図８のフローチャートＦＢで示すように、サーバ制御部１０は、ステップＳＢ４の処理後、以下の処理を実行する。すなわちサーバ制御部１０は、ログ関連データ（送信用ログデータＤＬ）を受信したか否かを監視しつつ（ステップＳＢ５）、終了通知情報を受信したか否かを監視する（ステップＳＢ６）。ステップＳＢ７においてログ関連データを受信したと判定した場合（ステップＳＢ５：ＹＥＳ）、サーバ制御部１０は、検証処理を実行し（ステップＳＢ７）、処理手順をステップＳＢ６へ移行する。一方、ステップＳＢ５において送信用ログデータＤＬを受信していないと判定した場合（ステップＳＢ５：ＮＯ）、サーバ制御部１０は、処理手順をステップＳＢ６へ移行する。ステップＳＢ６においてサーバ制御部１０は、終了通知情報を受信していないと判定した場合（ステップＳＢ６：ＮＯ）、処理手順をステップＳＢ５に戻し、受信したと判定した場合（ステップＳＢ６：ＹＥＳ）、サーバ側終了処理を実行する（ステップＳＢ８）。サーバ側終了処理では、単位ゲームの終了時に実行される処理として定められた処理が実行される。例えばサーバ制御部１０は、終了通知情報に含まれる実行中ゲームＩＤに対応するレコードに基づいて、ユーザ管理データベース、その他のデータベースを適切に更新する。ステップＳＢ８の処理後、フローチャートＦＢは終了する。

なお図８のフローチャートＦＢは、ある１つのサーバ２が全てのステップの処理を実行する内容となっている。しかしながら、全ての処理が１つのサーバ２において順番に行われる必要はない。例えばサーバ２が複数のサーバ装置によって構成され、ロードバランサによって負荷分散が実現されているものとする。また、ある特定のユーザ端末３（ユーザ端末ＴＸとする）で単位ゲームが開始されたとする。この構成において、ユーザ端末ＴＸから開始通知情報を受信するサーバ２と、ユーザ端末ＴＸから送信用ログデータＤＬを受信するサーバ２と、ユーザ端末ＴＸから終了通知情報を受信するサーバ装置とが異なっていてもよい。またユーザ端末ＴＸが、送信用ログデータＤＬを複数回送信する場合において、複数の送信用ログデータＤＬを受信するサーバ装置がそれぞれ異なっていてもよい。

以上の通りサーバ制御部１０は、ユーザによって単位ゲームが行われている間、送信用ログデータＤＬを受信したか否かを継続して監視し、送信用ログデータＤＬの受信に応じて、検証処理を実行する。以下、検証処理が詳述される。

図１４のフローチャートＦＦは、検証処理の詳細を示す。フローチャートＦＦで示すように、サーバ制御部１０は、受信したログ関連データを取得する（ステップＳＦ１）。ログ関連データには、送信元のユーザ端末３でプレイされている単位ゲームに対応するデータＩＤおよび実行中ゲームＩＤと、送信用ログデータＤＬとが含まれる。次いでサーバ制御部１０は、受信したデータＩＤに対応するノード定義データＮＤをデータ管理ＤＢから取得する（ステップＳＦ２）。次いでサーバ制御部１０は、受信した実行中ゲームＩＤに対応する登録ノード関連情報をゲーム管理ＤＢから取得する（ステップＳＦ３）。

次いでサーバ制御部１０は、サーバ側起動処理を実行する（ステップＳＦ４）。詳述するとサーバ制御部１０は、ステップＳＦ２で取得したノード定義データＮＤのインスタンスを生成し、サーバ側ノード定義データＮＤｓに基づく処理を実行可能な状態とする。ノード定義データＮＤのインスタンスの生成に応じて、サーバ側ノード関連情報の各項目に値を格納可能な状態となる。次いでサーバ制御部１０は、サーバ側ノード関連情報の各項目の値を、ステップＳＦ３で取得した登録ノード関連情報の各項目の値によって初期化する。この結果、サーバ側ノード関連情報の値と、現時点でゲーム管理ＤＢに登録されている対応する登録ノード関連情報の値とが一致した状態となる。なおサーバ制御部１０は、ノード定義データＮＤのインスタンスを生成し、ノード関連情報の各項目を初期化した後、サーバ側ノード定義データＮＤｓに基づいてノードを遷移させ、疑似的に単位ゲームを進行させていく。以下、説明の便宜上、サーバ側ノード定義データＮＤｓに基づいて進行される疑似的な単位ゲームは、「疑似単位ゲーム」と呼ばれる。特に疑似的なボーナスゲームは、「疑似ボーナスゲーム」と呼ばれる。また、ステップＳＦ１～ＳＦ４の処理は、「再起動処理」と呼ばれる。

ステップＳＦ４の処理後、サーバ制御部１０は、受信したログ関連データが、単位ゲームの開始後、最初に送信されたデータであるか否かを判別する（ステップＳＦ５）。上述したように端末制御部１３は、単位ゲームが開始された後、定期的にログ関連データ（送信用ログデータＤＬ）を送信する。そしてステップＳＦ５においてサーバ制御部１０は、受信したログ関連データが１回目のログ送信タイミングで送信されたデータであるか否かを判別している。最初に送信されたデータであるか否かは、例えば、所定のフラグによって管理される。また例えば、ログ関連データに、最初のデータかどうかを示す情報が含められる。最初のデータではない場合（ステップＳＦ５：ＮＯ）、サーバ制御部１０は、処理手順をステップＳＦ７へ移行する。最初のデータの場合（ステップＳＦ５：ＹＥＳ）、サーバ制御部１０は、初期ノード遷移処理を実行する（ステップ：ＳＦ６）。初期ノード遷移処理においてサーバ制御部１０は、ゲーム状態を初期ノードへ遷移させ、初期ノードに遷移時処理が定義されている場合には当該処理を実行する。初期ノードへの遷移に応じてサーバ側設定情報の値は適切に更新される。ステップＳＦ６の処理後、サーバ制御部１０は、処理手順をステップＳＦ７へ移行する。

ステップＳＦ７以降、サーバ制御部１０は、送信用ログデータＤＬに含まれるログＬＧのそれぞれについて、ログＬＧの時系列に沿ってログ対応処理を実行する。すなわちステップＳＦ７においてサーバ制御部１０は、送信用ログデータＤＬに記録されたログＬＧのうち、未処理のログＬＧがあるか否かを判別する。未処理のログＬＧがある場合（ステップＳＦ７：ＹＥＳ）、サーバ制御部１０は、未処理のログＬＧのうち、最も古いログＬＧを処理対象ログとして決定する（ステップＳＦ８）。次いでサーバ制御部１０は、処理対象ログを対象としてログ対応処理を実行し（ステップＳＦ９）、処理手順をステップＳＦ７へ戻す。

一方、ステップＳＦ７において未処理のログＬＧがないと判定した場合（ステップＳＦ７：ＮＯ）、サーバ制御部１０は、サーバ反映処理を実行する（ステップＳＦ１０）。ステップＳＦ１０のサーバ反映処理においてサーバ制御部１０は、現時点のサーバ側設定情報の各項目の値によって、ゲーム管理ＤＢの対応するレコード（ステップＳＦ３で登録ノード関連情報を取得したレコード）の登録設定情報の各項目の値を更新する。ステップＳＦ１０の処理後、フローチャートＦＦは終了する。

このように本実施形態では、送信用ログデータＤＬに記録された全てのログＬＧについて、状態不一致（後述）が発生することなく、ログ対応処理が完了した場合、サーバ側設定情報の各項目の値によって、ゲーム管理ＤＢの対応するレコードの登録設定情報の各項目の値が更新される。これにより次に新たなログ関連データを受信したときに再起動処理が行われると、サーバ側設定情報の各項目の値が、１つ前に受信したログ関連データに対する処理が完了した時点の各項目の値となる。なお後に明らかとなる通り、ログ対応処理において状態不一致（後述）が発生し、エラー処理が行われる場合には、検証処理は中断される。この場合には、ステップＳＦ１０のサーバ反映処理は行われないことになる。

図１５のフローチャートＦＧは、ログ対応処理の詳細を示す。ログ対応処理においてサーバ制御部１０は、処理対象ログの種類が、イベントであるか端末側設定情報であるかを判別する（ステップＳＧ１）。上述の通り、処理対象ログの種類がイベントの場合、処理対象ログにはイベント内容情報が記録され、当該種類が端末側設定情報の場合、処理対象ログには状態ハッシュ値が記録される。処理対象ログの種類がイベントの場合（ステップＳＧ１：「イベント」）、サーバ制御部１０は、処理対象ログのイベント内容情報が示すイベントを発行する（ステップＳＧ２）。なおイベント内容情報が、パラメータが付加されたイベントを示している場合には、サーバ制御部１０は、パラメータを正確に再現してイベントを発行する。次いでサーバ制御部１０は、サーバ側ノード定義データＮＤｓの遷移ルールに従って、擬似単位ゲームのノードを遷移させる（ステップＳＧ３）。サーバ制御部１０は、ノードの遷移に応じて必要なサーバ側設定情報の更新を実行する。次いでサーバ制御部１０は、遷移後のノードに遷移時処理が定義されているか否かを判別する（ステップＳＧ４）。定義されている場合（ステップＳＧ４：ＹＥＳ）、サーバ制御部１０は、遷移時処理を実行する（ステップＳＧ５）。遷移時処理は、状態変数、その他のサーバ側設定情報の項目の値を変化させる処理を含む。従ってステップＳＧ５の処理によって、サーバ側設定情報の１つ以上の項目の値が変化する場合がある。またサーバ制御部１０は、遷移時処理が乱数を使用する処理の場合には、サーバ側設定情報の乱数シード＜項目＞に格納された乱数シードおよびサーバ側乱数生成器を用いて乱数を発生させる。当該乱数シードの値は、サーバ制御部１０がステップＳＢ２で生成し、ステップＳＢ４でユーザ端末３に送信した乱数シードの値と一致する。

以上の通りサーバ２とユーザ端末３とのそれぞれは、共通する乱数生成器を利用可能である。そしてサーバ制御部１０は、乱数シードを生成してユーザ端末３に送信する一方、検証処理においてノードの遷移に応じて乱数を使用する処理を実行する場合には、生成した乱数シードおよびサーバ２の乱数生成器を使用して処理を実行する。一方で端末制御部１３は、ノードの遷移に応じて乱数を使用する処理を実行する場合には、サーバ２から受信した乱数シードおよび端末の乱数生成器を使用して処理を実行する。これにより、その他の乱数生成器を用いて行う処理に関し、サーバ制御部１０の処理結果と、端末制御部１３の処理結果とを完全に一致させることが可能となる。

なおサーバ制御部１０は、検証処理において、遷移後のノードに完了時発行イベントが定義されている場合であっても、完了時発行イベントの発行を行わず、完了時発行イベントの発行をキャンセルする。ステップＳＧ５の処理後、ログ対応処理は終了する。一方、遷移後のログに遷移時処理が定義されていない場合（ステップＳＧ４：ＮＯ）、サーバ制御部１０は、ログ対応処理を終了する。

ステップＳＧ１において処理対象ログの種類が端末側設定情報であると判定した場合（ステップＳＧ１：「端末側状態情報」）、サーバ制御部１０は、比較対象ハッシュ値を導出する（ステップＳＧ６）。サーバ制御部１０は、端末制御部１３が状態ハッシュ値を導出する方法と同じ方法で比較対象ハッシュ値を導出する。すなわちサーバ制御部１０は、サーバ側設定情報の各項目の値を取得する。次いでサーバ制御部１０は、各項目の値に基づいて、ユーザ端末３のルールと同じルールで配列データを生成する。次いでサーバ制御部１０は、ユーザ端末３のハッシュ関数と同じハッシュ関数を用いてハッシュ値を導出する。ここで導出されたハッシュ値が比較対象ハッシュ値である。仮に状態ハッシュ値の基礎となった端末側設定情報の各項目の値と、比較対象ハッシュ値の基礎となったサーバ側設定情報の各項目の値とが同じであるならば、状態ハッシュ値と比較対象ハッシュ値とは完全に一致する。

次いでサーバ制御部１０は、比較対象ハッシュ値と、処理対象ログに含まれる状態ハッシュ値とが同一であるか否かを判別する（ステップＳＧ７）。ここで、これら値が同一ではない場合、ユーザ端末３において端末側設定情報の１つ以上の項目の値が、正しい値から乖離したということである。従って、この場合、何らかの不正行為が行われた可能性が高い。よって、これら値が同一か否かを判別するということは、ユーザ端末３における不正行為の発生の有無をサーバ２において判別するということに等しい。比較対象ハッシュ値と状態ハッシュ値とが同一の場合（ステップＳＧ７：ＹＥＳ）、サーバ制御部１０は、ログ対応処理を終了する。一方、これら値が同一ではない場合（ステップＳＧ７：ＮＯ）、サーバ制御部１０は、エラー処理を実行する（ステップＳＧ８）。エラー処理は後述される。エラー処理が実行される場合、検証処理は中断される。

以下の説明において、ログ対応処理において比較対象ハッシュ値と状態ハッシュ値とが同一ではないことは、「状態不一致」と表現される場合がある。またステップＳＧ６、ＳＧ７で示す比較対象ハッシュ値を導出し、比較対象ハッシュ値と状態ハッシュ値とを比較する処理のことは、「状態比較処理」と呼ばれる。

次に本件例についてサーバ制御部１０が実行する検証処理が説明される。図１２のフローチャートＦＥは、本件例についてサーバ制御部１０が実行する検証処理の詳細を示す。本件例では端末制御部１３が、１回目のログ送信タイミングで第１～第４ログＬＧ１～ＬＧ４を含む送信用ログデータＤＬ（以下「第１送信用ログデータＤＬ－１」とする）を送信し、２回目のログ送信タイミングで第５、第６ログＬＧ５、ＬＧ６を含む送信用ログデータＤＬ（以下「第２送信用ログデータＤＬ－２」とする）を送信したものとする。第１～第６ログＬＧ１～ＬＧ６については図１３に示されている。図１２のフローチャートＦＥは、第１送信用ログデータＤＬ－１の受信に応じた検証処理、および、第２送信用ログデータＤＬ－２の受信に応じた検証処理を示す。

フローチャートＦＥで示すようにサーバ制御部１０は、第１送信用ログデータＤＬ－１を含むログ関連データを受信すると（ステップＳＥ１）、再起動処理を実行する（ステップＳＥ２）。これによりサーバ側ノード定義データＮＤｓに基づく処理が実行可能な状態となり、サーバ側ノード関連情報の各項目の値が、ゲーム管理ＤＢの対応するレコードの現時点の登録ノード関連情報の各項目の値によって初期化される。次いでサーバ制御部１０は、初期ノード遷移処理を行って、疑似ボーナスゲームのゲーム状態を待機ノードへ遷移させる（ステップＳＥ３）。待機ノードへの遷移に応じてサーバ制御部１０は、サーバ側設定情報の値を適切に更新する。

次いでサーバ制御部１０は、第１ログＬＧ１に基づくログ対応処理を行ってカード選択イベントを発行する（ステップＳＥ４）。ここで発行されたカード選択イベントは、フローチャートＦＤの遷移再現情報記録処理でログデータＬＤに記録されたカード選択イベントに対応する。カード選択イベントの発生に応じて、サーバ制御部１０は、サーバ側ノード定義データＮＤｓの遷移ルールＪ１に基づいて疑似ボーナスゲームのゲーム状態を抽選ノードへ遷移させる（ステップＳＥ５）。抽選ノードへの遷移に応じてサーバ制御部１０は、サーバ側設定情報の値を更新する。カード選択イベントの発生に応じて更にサーバ制御部１０は、抽選ノードに遷移時処理として定義された抽選処理を実行する（ステップＳＥ６）。

ステップＳＥ６の抽選処理に関し、サーバ制御部１０は、以下の処理を実行する。すなわちサーバ制御部１０は、サーバ側ノード関連情報の乱数シード＜項目＞に格納された乱数シードをサーバ側乱数生成器に入力し、その出力値を得る。次いでサーバ制御部１０は、端末制御部１３が用いた抽選ルールと同じルールに従って、出力値に基づいてカードの選択の結果を決定する。次いでサーバ制御部１０は、サーバ側状態変数の各項目の値を、決定した結果に基づいて更新する。ここで端末制御部１３がフローチャートＦＤのステップＳＤ６の抽選処理において使用する乱数生成器と、サーバ制御部１０がフローチャートＦＥのステップＳＥ６の抽選処理において使用する乱数生成器とは共通している。更に端末制御部１３が抽選処理において乱数生成器に入力する乱数シードの値と、サーバ制御部１０が抽選処理において乱数生成器に入力する乱数シードの値とは同一である。従ってサーバ制御部１０による抽選処理の処理結果は、端末制御部１３による抽選処理の処理結果と必ず同じとなる。このためユーザ端末３で不正行為が行われていない場合には、ステップＳＥ６の抽選処理が終わった時点のサーバ側状態変数の値と、フローチャートＦＤのステップＳＤ６の抽選処理が終わった時点の端末側状態変数の値とは一致する。

ステップＳＥ６の処理後、サーバ制御部１０は、第２ログＬＧ２に基づくログ対応処理の状態比較処理を実行する（ステップＳＥ７）。ステップＳＥ７の状態比較処理では、現時点のサーバ側設定情報の各項目の値に基づく比較対象ハッシュ値と、フローチャートＦＤのステップＳＤ７でログデータＬＤに記録された状態ハッシュ値とが同一か否か判別される。ユーザ端末３において不正行為が行われていない場合にはこれら値は一致する。ステップＳＥ７において各値が同一ではないと判定した場合、サーバ制御部１０は、検証処理を中断しエラー処理を実行する。

ステップＳＥ７の処理後、サーバ制御部１０は、第３ログＬＧ３に基づくログ対応処理を行って抽選完了イベントを発行する（ステップＳＥ８）。この抽選完了イベントは、フローチャートＦＤのステップＳＤ９の遷移再現情報記録処理で記録された抽選完了イベントに対応する。抽選完了イベントの発生に応じて、サーバ制御部１０は、サーバ側ノード定義データＮＤｓの遷移ルールＪ２に基づいて疑似ボーナスゲームのゲーム状態を待機ノードへ遷移させる（ステップＳＥ９）。待機ノードの遷移に応じてサーバ制御部１０は、サーバ側設定情報の各項目の値を更新する。

ステップＳＥ９の処理後、サーバ制御部１０は、第４ログＬＧ４に基づく状態比較処理を実行する（ステップＳＥ１０）。状態比較処理では、現時点のサーバ側設定情報の各項目の値に基づく比較対象ハッシュ値と、フローチャートＦＤのステップＳＤ１１でログデータＬＤに記録された状態ハッシュ値とが同一か否か判別される。ステップＳＥ１０において各値が同一ではないと判定した場合、サーバ制御部１０は、検証処理を中断しエラー処理を実行する。ステップＳＥ１０の処理後、サーバ制御部１０は、サーバ反映処理を実行する（ステップＳＥ１１）。ステップＳＥ１１の処理により、ゲーム管理ＤＢの対応するレコードの登録ノード関連情報の各項目の値が、現時点のサーバ側ノード関連情報の各項目の値となる。以上により第１送信用ログデータＤＬ－１に基づく検証処理は完了する。

その後、サーバ制御部１０は、第２送信用ログデータＤＬ－２を含むログ関連データを受信する（ステップＳＥ１２）。するとサーバ制御部１０は、再起動処理を実行する（ステップＳＥ１３）。ステップＳＥ１３の処理により、サーバ側ノード定義データＮＤｓに基づく処理が実行可能な状態となる。更にサーバ側ノード関連情報の各項目の値が、ゲーム管理ＤＢの対応するレコードの現時点の登録ノード関連情報の各項目の値によって初期化される。次いでサーバ制御部１０は、第５ログＬＧ５に基づくログ対応処理を行って終了イベントを発行する（ステップＳＥ１４）。この終了イベントは、フローチャートＦＤのステップＳＤ１４でログデータＬＤに記録された終了イベントに対応する。終了イベントの発生に応じて、サーバ制御部１０は、サーバ側ノード定義データＮＤｓの遷移ルールＪ３に基づいて疑似ボーナスゲームのゲーム状態を終了ノードへ遷移させる（ステップＳＥ１５）。終了ノードへの遷移に応じてサーバ制御部１０は、サーバ側設定情報の値を更新する。ステップＳＥ１５の処理後、サーバ制御部１０は、第５ログＬＧ５に基づく状態比較処理を実行する（ステップＳＥ１６）。ステップＳＥ１６の処理後、サーバ制御部１０は、サーバ反映処理を実行する（ステップＳＥ１７）。ステップＳＥ１７の処理により、ゲーム管理ＤＢの対応するレコードの登録ノード関連情報の各項目の値が、現時点のサーバ側ノード関連情報の各項目の値となる。以上により第２送信用ログデータＤＬ－２に基づく検証処理は完了する。

以上の通りサーバ制御部１０は、ユーザ端末３から受信した送信用ログデータＤＬの遷移再現情報およびサーバ２のノード定義データＮＤに基づいてノードの遷移を再現する。更にサーバ制御部１０は、ノードの遷移に応じてサーバ２のノード定義データＮＤに対応するサーバ側設定情報の値を変化させると共に、サーバ側設定情報の値と送信用ログデータＤＬに記録された対応する端末側設定情報の値とを比較する検証処理を実行する。より詳細には、サーバ制御部１０は、検証処理において、送信用ログデータＤＬに記録された遷移再現情報に基づいて、時系列に沿ってトリガ事象を発生させ、トリガ事象の発生に応じて、サーバのノード定義データに基づいてノードを自動で遷移させ、ノードの遷移に応じてサーバ側設定情報の値を動的に変化させると共に、変化後のサーバ側設定情報の値と送信用ログデータに記録された対応する端末側設定情報の値とを比較する。この構成のため、以下の効果を奏する。すなわちサーバ側設定情報の値と送信用ログデータＤＬに記録された対応する端末側設定情報の値とが同じではない場合、ユーザ端末３において端末側設定情報の値が、正しい値から乖離したということである。従って、この場合、ユーザ端末３において何らかの不正行為が行われた可能性が高い。よって、これら値を比較するということは、ユーザ端末３における不正行為の発生の有無をサーバ２において判別するということに等しい。そして上記構成によれば、不正行為の検出が可能であり、不正行為の検出に応じて不正行為を予防／防止する処理、または、不正行為に起因する悪影響を抑制する処理を行うことが可能である。これにより不正行為に対する耐性を向上できる。

次にエラー処理が詳述される。エラー処理では、不正行為の予防／防止に寄与する処理、または、不正行為に起因する悪影響を抑制する処理が実行される。本実施形態ではサーバ制御部１０は、エラー処理として、ロールバック処理を実行する。ロールバック処理においてサーバ制御部１０は、過去に比較対象ハッシュ値（サーバ側設定情報の値）と同一であると判定した状態ハッシュ値（端末側設定情報の値）がログデータＬＤに記録された段階よりも前からゲームが再開される状態を構築する。以下、本件例を用いてエラー処理の一例が説明される。

図１２のフローチャートＦＥを参照し、例えばステップＳＥ１６の状態比較処理において状態不一致が発生したとする。この場合、ステップＳＥ１０の状態比較処理では状態不一致が発生しなかったということである。この場合、フローチャートＦＤのステップＳＤ１１の処理が行われたタイミングから、ステップＳＤ１６の処理が行われたタイミングまでの期間に、不正行為によって端末側設定情報の１つ以上の項目の値が改変されたことが想定される。なおこの場合、サーバ制御部１０は、検証処理を中断し、ステップＳＥ１７のサーバ反映処理を実行しない。

そしてステップＳＥ１６で状態不一致が発生すると、サーバ制御部１０は、ゲーム管理ＤＢの対応するレコードを参照し、現時点の登録ノード関連情報を取得する。ここで取得された登録ノード関連情報は、ステップＳＥ１１のサーバ反映処理において更新された情報である。次いでサーバ制御部１０は、取得した登録ノード関連情報、および、ボーナスゲームに対応するノード定義データＮＤを端末制御部１３に送信する。更にサーバ制御部１０は、ステップＳＤ１１の端末側設定情報記録処理が行われた段階からボーナスゲームを再開することを端末制御部１３に指示する。

当該指示に応じて端末制御部１３は、受信したノード定義データＮＤに基づいてインスタンスを生成し、受信した登録ノード関連情報に基づいてインスタンスに対応する端末側ノード関連情報の各項目の値を初期化する。この初期化によって、現在ノード＜項目＞の値が更新され、ボーナスゲームのゲーム状態は、端末側設定情報の現在ノード＜項目＞が示すノード（本例では待機ノード）へ遷移される。更に端末制御部１３は、端末側設定情報の各項目の値に対応する処理を実行する。本例では端末制御部１３は、選択後画面Ｇ２を端末表示部１５に表示する。以上の処理が行われる結果、ボーナスゲームがステップＳＤ１１の端末側設定情報記録処理が行われた段階から再開される状態が構築される。

なおボーナスゲームが再開された後、端末制御部１３は、図１１のフローチャートＦＣのステップＳＣ４以降の処理に従ってゲーム進行処理を実行すると共に、定期的にログ関連データを送信する。サーバ制御部１０は、ログ関連データの受信に応じて検証処理を実行する。

このように本実施形態では、ログ対応処理において状態不一致が発生した場合には、不正行為による影響がない時点からボーナスゲームが再開される。この構成のため、不正行為が行われた場合であっても、不正行為による悪影響を抑制することができる。また不正行為を行ったユーザに対して、不正行為を行っても、不正行為による利益を享受できないことを認識させることができ、ユーザが不正行為を行うことを牽制することができる。なお、不正行為を行わないユーザについては、ボーナスゲームが行われている間、ロールバック処理が行われることなく、ゲームがスムーズに進行することになる。従って不正行為を行わないユーザの満足度が低下することはない。

＜変形例＞
次に上記実施形態の変形例が説明される。本変形例では、管理情報に項目として、乱数使用実績情報が含まれる。図１６は、乱数使用実績情報の内容を模式的に示す図である。乱数使用実績情報には、単位ゲームで使用され得る乱数カテゴリごとに、乱数カテゴリＩＤ＜項目＞と、乱数使用回数＜項目＞とが設けられる。乱数カテゴリは後述される。乱数カテゴリＩＤ＜項目＞には、乱数カテゴリの識別情報である乱数カテゴリＩＤが格納される。乱数使用回数＜項目＞には、対応する乱数カテゴリにおいて乱数が使用された回数を示す乱数使用回数が格納される。乱数使用回数の初期値は、０回を示す値である。図１６の１つ目のレコードは、乱数カテゴリＩＤ：Ｒ０１の乱数カテゴリにおいて乱数が３回使用されたことを示している。なお、端末側設定情報には、単位ゲームにおける端末制御部１３によるカテゴリ別の乱数の使用回数が含まれることになる。またサーバ側設定情報には、検証処理におけるサーバ制御部１０によるカテゴリ別の乱数の使用回数が含まれることになる。

本変形例では、端末制御部１３は、ゲーム進行処理において以下の処理を実行する。図１７のフローチャートＦＨは、端末制御部１３により実行されるゲーム進行処理のうち、乱数使用処理に関連する部分を示す。以下の説明では、単位ゲームに第１ステージ、第２ステージおよび第３ステージが設けられているものとする。更に第１ステージについて乱数カテゴリＩＤとして「Ｒ０１」が割り振られ、第２ステージについて「Ｒ０２」が割り振られ、第３ステージについて「Ｒ０３」が割り振られているものとする。また上述の通り、遷移時処理には乱数を使用する処理が含まれる。以下、乱数を使用する処理を「乱数使用処理」という。第１ステージでは乱数使用処理Ｐ１ａ～Ｐ１ｃが実行され、第２ステージでは乱数使用処理Ｐ２ａ、Ｐ２ｂが実行され、第３ステージでは乱数使用処理Ｐ３ａ、Ｐ３ｂが実行される。なお図１７を用いた説明では、乱数生成器は、０～３の範囲で整数を出力するものとする。また、特に説明しないものの、乱数使用処理は、ノードの遷移に応じて実行される。

図１７のフローチャートＦＨで示すように、端末制御部１３は、第１ステージで乱数使用処理Ｐ１ａを実行する際、第１ステージに対応する乱数カテゴリＩＤ：Ｒ０１（カテゴリ）を指定する。当該指定は、例えば、乱数を発生させる関数にパラメータとして乱数カテゴリＩＤ：Ｒ０１が引き渡されることによって実行される。次いで端末制御部１３は、指定した乱数カテゴリＩＤ（カテゴリ）に応じて乱数シードの値を変化させる。上記実施形態で説明した通り乱数シードは、サーバ２から受信されたものである。変化させるときのルールは、乱数シードが同じ場合に、カテゴリＩＤが異なれば変化後の乱数シードの値が異なり、カテゴリＩＤが同じであれば変化後の乱数シードの値が同じとなるルールとされる。当該ルールは例えば、乱数シードの値に、カテゴリＩＤに応じた値を加算するというルールである。以下、変化後の乱数シードを「変化後乱数シード」という。

次いで端末制御部１３は、変化後乱数シードを端末側乱数生成器に入力し、その出力を得る。図１７は、乱数使用処理Ｐ１ａにおける端末側乱数生成器の出力が３であったことを示す。更に端末制御部１３は、端末側設定情報の乱数使用実績情報の乱数カテゴリＩＤ：Ｒ０１に対応する乱数使用回数の値をインクリメントする。以後、第１ステージにおいて、端末制御部１３は、乱数使用処理を実行する場合、カテゴリＩＤ：Ｒ０１に対応して変化された変化後乱数シードを入力とする端末乱数生成器が連続して出力する出力値を順番に使用（消費）する。また端末制御部１３は、乱数の使用に応じて対応する乱数使用回数の値をインクリメントする。上述したように乱数生成器は漸化式であり、特定の値が入力された場合には、連続する出力値の態様が特定の態様となる。図１７は、第１ステージにおいて乱数使用処理Ｐ１ｂで乱数：０が使用され、乱数使用処理Ｐ１ｃで乱数：１が使用された様子を示す。

乱数使用処理Ｐ１ｃの処理後、端末制御部１３は、第１端末側設定情報記録処理を実行する。この時点で乱数カテゴリＩＤ：Ｒ０１、Ｒ０２、Ｒ０３に対応する乱数使用回数はそれぞれ、３回、０回、０回である。

第１ステージに続く第２ステージにおいて端末制御部１３は、以下の処理を実行する。すなわち端末制御部１３は、乱数使用処理Ｐ２ａにおいて、乱数カテゴリＩＤ：Ｒ０２を指定し、指定した乱数カテゴリＩＤに応じて変化後乱数シードを生成する。端末制御部１３は、変化後乱数シードを端末側乱数生成器に入力し、出力値（乱数）を得る。乱数使用処理Ｐ２ａに続く乱数使用処理Ｐ２ｂにおいて端末制御部１３は、乱数カテゴリＩＤ：Ｒ０２に対応する変化後乱数シードを入力とする端末乱数生成器が次に出力する出力値（乱数）を取得する。端末制御部１３は、乱数の使用に応じて、対応する乱数使用回数の値をインクリメントする。図１７は、第２ステージにおいて乱数使用処理Ｐ２ａで乱数：１が使用され、乱数使用処理Ｐ２ｂで乱数：０が使用された様子を示す。乱数使用処理Ｐ２ｂの処理後、端末制御部１３は、第２端末側設定情報記録処理を実行する。この時点で乱数カテゴリＩＤ：Ｒ０１、Ｒ０２、Ｒ０３に対応する乱数使用回数はそれぞれ、３回、２回、０回である。

第２ステージに続く第３ステージについても端末制御部１３は、第１ステージおよび第２ステージと同様の処理を実行する。図１７は、第３ステージにおいて乱数使用処理Ｐ３ａで乱数：３が使用され、乱数使用処理Ｐ３ｂで乱数：２が使用された様子を示す。乱数使用処理Ｐ３ｂの処理後、端末制御部１３は、第３端末側設定情報記録処理を実行する。この時点で乱数カテゴリＩＤ：Ｒ０１、Ｒ０２、Ｒ０３に対応する乱数使用回数はそれぞれ、３回、２回、２回である。

以上の通り本実施形態では、端末制御部１３は、ノードの遷移に応じて乱数を使用する処理を実行する場合、カテゴリを指定し、指定したカテゴリに応じて乱数シードの値を変化させ、値が変化された後の乱数シードおよび端末に記憶された乱数生成器を使用して処理を実行する。これにより以下の効果を奏する。すなわち単位ゲームにおいて、１つの乱数シードに基づいて端末側乱数生成器が連続して出力する出力値（乱数）が継続して使われた場合、乱数の予測可能性が高まると共に、いわゆる乱数調整が行われ易くなる。一方で、単位ゲームに複数のカテゴリが設けられ、カテゴリごとに独立した乱数シードが用いられることによって、単位ゲームにおいてカテゴリごとに、乱数の関連性をなくすことができ、乱数の予測可能性を低減することができると共に、乱数調整の困難性を向上できる。

次に本変形例におけるサーバ２の動作を説明する。図１７のフローチャートＦＩは、ユーザ端末３がフローチャートＦＨの処理を実行した場合におけるサーバ２の動作例を示す。特にフローチャートＦＩは、検証処理におけるサーバ２の動作例を示す。フローチャートＦＩで示される通り、サーバ制御部１０は、検証処理において、ノードの遷移に応じて、乱数使用処理Ｑ１ａ、Ｑ１ｂ、Ｑ１ｃを実行する。この乱数使用処理Ｑ１ａ、Ｑ１ｂ、Ｑ１ｃは、フローチャートＦＨで端末制御部１３が実行した乱数使用処理Ｐ１ａ、Ｐ１ｂ、Ｐ１ｃに対応する。乱数使用処理Ｑ１ａにおいて端末制御部１３は、乱数カテゴリＩＤ：Ｒ０１を指定し、乱数カテゴリＩＤ：Ｒ０１に応じて、ユーザ端末３のルールと同じルールに従って変化後乱数シードを生成する。そして端末制御部１３は、変化後乱数シードをサーバ側乱数生成器に入力し、その出力値（乱数）を得る。サーバ側乱数生成器と端末側乱数生成器とは共通するため、サーバ２に係る乱数使用処理Ｑ１ａで使用される乱数の値と、ユーザ端末３に係る乱数使用処理Ｐ１ａで使用される乱数の値とは必ず一致する。以後、サーバ制御部１０は、乱数使用処理Ｑ１ｂ、Ｑ１ｃにおいてカテゴリＩＤ：Ｒ０１に対応する変化後乱数シードに基づいてサーバ側乱数生成器が連続して出力する出力値を順番に使用（消費）する。この結果、サーバ２に係る乱数使用処理Ｑ１ｂ、Ｑ１ｃで使用される乱数の値と、ユーザ端末３に係る乱数使用処理Ｐ１ｂ、Ｐ１ｃで使用される乱数の値とは同じとなる。

またサーバ制御部１０は、乱数使用処理Ｑ１ｃの後に、第１状態比較処理を実行する。この第１状態比較処理において、比較対象ハッシュ値の基礎となる乱数使用実績情報の乱数使用回数の値は以下である。乱数カテゴリＩＤ：Ｒ０１→３回、Ｒ０２→０回、Ｒ０３→０回。これは、第１端末側設定情報記録処理において、状態ハッシュ値の基礎となった乱数使用実績情報の乱数使用回数の値と一致する。従って、不正行為が行われていない場合、第１状態比較処理において状態不一致は発生しない。

フローチャートＦＩの乱数使用処理Ｑ２ａ、Ｑ２ｂは、フローチャートＦＨで端末制御部１３が実行した乱数使用処理Ｐ２ａ、Ｐ２ｂに対応する。乱数使用処理Ｑ２ａ、Ｑ２ｂについて、サーバ制御部１０は、カテゴリＩＤ：Ｒ０２に対応する変化後乱数シードに基づいてサーバ側乱数生成器が連続して出力する出力値を順番に使用（消費）する。サーバ制御部１０は、乱数使用処理Ｑ２ｂの処理後、第２状態比較処理を実行する。この第２状態比較処理では、第１状態比較処理と同じ理由により、不正行為が行われていない場合には、状態不一致は発生しない。またフローチャートＦＩの乱数使用処理Ｑ３ａ、Ｑ３ｂは、フローチャートＦＨで端末制御部１３が実行した乱数使用処理Ｐ３ａ、Ｐ３ｂに対応する。乱数使用処理Ｑ３ａ、Ｑ３ｂについて、サーバ制御部１０は、カテゴリＩＤ：Ｒ０３に対応する変化後乱数シードに基づいてサーバ側乱数生成器が連続して出力する出力値を順番に使用（消費）する。この結果、サーバ２に係る乱数使用処理Ｑ３ａ、Ｑ３ｂで使用される乱数の値と、ユーザ端末３に係る乱数使用処理Ｐ３ａ、Ｐ３ｂで使用される乱数の値とは同じとなる。また乱数使用処理Ｑ３ｂに続く第３状態比較処理では、第１状態比較処理と同じ理由により、不正行為が行われていない場合には、状態不一致は発生しない。

以上の通り、サーバ制御部１０は、検証処理において、ノードの遷移に応じて乱数を使用する処理を実行する場合、ユーザ端末３で行われた対応する処理において端末制御部１３により指定されたカテゴリと同じカテゴリを指定し、指定したカテゴリに応じて乱数シードの値を変化させ、値が変化された後の乱数シードおよびサーバ２の乱数生成器を使用して処理を実行する。

以上、本発明の一実施形態について説明したが、上記実施形態は、本発明を実施するにあたっての具体化の一例を示したものに過ぎず、これによって本発明の技術的範囲が限定的に解釈されてはならないものである。すなわち、本発明はその要旨、またはその主要な特徴から逸脱することなく、様々な形で実施することができる。

例えば上記実施形態では、ログ送信条件は、定期的に発生するタイミングが到来したことという条件であった。しかしながら、ログ送信条件の内容は、上記実施形態で例示した内容に限られない。一例として、ログデータＬＤに一定数のログＬＧが記録されたことという条件であってもよい。この場合に、一定数は、１つでもよく、２つ以上でもよい。

また上記実施形態では端末制御部１３は、ログ送信条件が成立した場合、ログデータＬＤに記録されたログのうち未送信のものを含む送信用ログデータＤＬを送信する構成であった。この点に関し、端末制御部１３が、ログデータＬＤに記録された全てのログＬＧを含む送信用ログデータＤＬを送信する構成でもよい。この構成の場合においてサーバ制御部１０は、送信用ログデータＤＬを受信した後、都度、未処理のログＬＧを抽出し、ログ対応処理を実行してもよい。またサーバ制御部１０は、送信用ログデータＤＬを受信する度に、全てのログＬＧを対象としてログ対応処理を実行してもよい。

また上記実施形態では、端末制御部１３は、ログデータＬＤにハッシュ値である状態ハッシュ値を記録した。この点に関し端末制御部１３が、状態ハッシュ値ではなく、端末側設定情報の値（ハッシュ化されていない値）をフォーマットに従ってログデータＬＤに記録する構成でもよい。この場合、送信用ログデータＬＳのログＬＧには、状態ハッシュ値に代えて端末側設定情報の値（ハッシュ化されていない値）が含まれる。この構成の場合、サーバ制御部１０は、状態比較処理において、比較対象ハッシュ値を導出することなく、サーバ側ノード定義データＮＤｓのサーバ側設定情報の値と、送信用ログデータＤＬの対応する端末側設定情報の値とが同一であるか否かを判別する。

またサーバ制御部１０が実行するエラー処理は、上記実施形態で例示した処理に限定されない。例えばサーバ制御部１０が以下の処理を実行する構成でもよい。例えばサーバ制御部１０が、エラー処理として、単位ゲームが最初から再開される状態を構築する構成でもよい。この場合、サーバ制御部１０は、再開の対象となる単位ゲームに対応するゲーム管理ＤＢのレコードを破棄し、図８のフローチャートＦＢのステップＳＢ１以下の処理を改めて実行する。また例えばサーバ制御部１０が、端末制御部１３と協働してユーザに対して所定の警告を通知する構成でもよい。また例えばサーバ制御部１０が、不正行為を行ったユーザをリストに登録する構成でもよい。すなわち、状態不一致が発生したときにサーバ制御部１０が実行する処理は、不正行為の予防／防止に寄与する処理、または、不正行為に起因する悪影響を抑制する処理であればよい。

また上記実施形態では、サーバ制御部１０が、ノード定義データＮＤと併せて乱数シードを端末制御部１３に送信する構成であった。しかしながら単位ゲームにおいて乱数が使用されない場合には、端末制御部１３が乱数シードを送信しない構成でもよい。

またログＬＧの内容は上記実施形態で例示した内容に限られない。特に上記実施形態では、遷移再現情報は、イベント（トリガ事象）の内容を示す情報であったが、遷移再現情報の内容は例示した内容に限定されない。例えば、遷移再現情報は、ノードの遷移にあたって参照した遷移ルールを識別する情報でもよい。また例えば遷移再現情報は、イベント以外の事象によってノードの遷移が可能に構成されている場合には、ノードの遷移のトリガとなった事象を示す情報でもよい。すなわち遷移再現情報は、サーバ制御部１０が、検証処理においてノードの遷移を再現するときに利用可能な情報であればよい。

また上記実施形態では、遷移ルールがノード定義データに記録された構成であった。しかしながら、遷移ルールがノード定義データに記録されない構成でもよい。例えば遷移ルールは、ノード定義データＮＤとは別のファイルに記録されてもよい。ただしこの構成の場合、ノード定義データＮＤのファイルと、遷移ルールが記録されたファイルとの組合せが「ノード定義データ」であると捉えられてもよい。また、ある単位ゲームに関し、サーバ制御部１０が使用するプログラム（ノード定義データに係るプログラムとは別のプログラム）に遷移ルールが定義され、端末制御部１３が使用するプログラム（例えばゲームアプリＡＰ）にサーバ２に係る遷移ルールと同じ内容の遷移ルールが定義される構成でもよい。すなわち、単位ゲームに関し、サーバ制御部１０と端末制御部１３とが同じ内容の遷移ルールを利用する状態が構築されればよい。

また本実施形態では、単位ゲームの提供の前に、サーバ２とユーザ端末３とのそれぞれが単位ゲームに対応する共通のノード定義データＮＤを利用可能な状態（以下「共有状態」という）が構築された。そして共有状態が構築される方法は、本実施形態で例示した方法に限られない。例えば、一の単位ゲームについて、サーバ２にノード定義データＮＤがアップロードされると共に、ゲームアプリＡＰにノード定義データＮＤが組み込まれる構成でもよい。この構成の場合、ユーザ端末３側のノード定義データＮＤの内容の改変（更新）は、ゲームアプリＡＰのアップデートによって行われるようにすればよい。またこの構成において、ゲームアプリＡＰにノード定義データＮＤが最初から組み込まれないものの、追加データとして事後的に組み込まれる構成としてもよい。また例えば、ＣＤ－ＲＯＭ、ＵＳＢメモリ、その他の物理的媒体に記憶されたノード定義データＮＤがユーザ端末３にダウンロードされ、これにより共有状態が構築される構成でもよい。すなわち、共有状態を構築する手段は何でもよく、単位ゲームの提供の前に、サーバ２とユーザ端末３とのそれぞれが単位ゲームに対応する共通のノード定義データＮＤを利用可能な状態が構築されればよい。なお「サーバ２が利用するノード定義データＮＤと、ユーザ端末３が利用するノード定義データＮＤとが共通する」とは、サーバ２に係るノード定義データＮＤと、ユーザ端末３に係るノード定義データＮＤとが形式的な点も含めて完全に一致することを意味しない。すなわち、これらデータが共通するとは、ノード定義データＮＤに基づいて処理が実行されたときに、不正行為が行われない限り、同じ態様でノードが遷移し、同じ態様で処理が行われ、同じ態様で設定情報が更新されるという点でデータの内容に同一性があることを意味する。

また上記実施形態では、ユーザ端末３およびサーバ２により提供されるゲームは、ユーザ端末３にダウンロードされた専用的なアプリケーションによって提供されるものであった。しかしながらゲームは、上記実施形態で例示したゲームに限られない。一例として、ブラウザを利用して行われるオンラインゲームであってもよい。

また上述の通りノード定義データＮＤは、プログラムファイルではなく、ＪＳＯＮ、その他の記述方式で情報が記述されたデータであってもよい。すなわちノード定義データＮＤは、端末制御部１３およびサーバ制御部１０が利用可能な態様でノードが記述されたデータであればよい。例えば、ノード定義データＮＤが所定のデータフォーマットに従って情報が記述されたテキストデータであるものとする。またノード定義データＮＤの設定情報の各項目（一部の項目でもよい）について、項目名と項目値とが対応付けてテキストによってノード定義データＮＤを構成するテキストデータに記述されているものとする。この構成において端末制御部１３（サーバ制御部１０も同様）は、ノード定義データＮＤを構成するテキストデータを適宜、参照し、ノードの遷移およびノードの遷移に伴う処理を実行する。また端末制御部１３は、適宜、当該テキストデータに記録された項目値を更新することによって、設定情報の値を更新する。

また上記実施形態では、端末側設定情報を具体的に例示した。ここで端末側設定情報は、状態比較処理において端末側設定情報と比較される対象となる情報を意味するものとする。上記実施形態では、状態ハッシュ値の基礎となる項目の組合せが端末側設定情報に相当する。そして端末側設定情報に関して、端末側設定情報の態様は、上記実施形態で例示した態様に限られない。例えば、端末側状態変数の一部の状態変数または端末側管理情報の一部の項目が端末側設定情報に含められる構成でもよい。また、設定情報および管理情報のうち、何れか一方の情報が端末側設定情報に含められる構成でもよい。すなわち、端末側設定情報は、単位ゲームの進行に伴うノードの遷移に応じて値が変化し得る情報であればよい。なお状態比較処理において比較対象となるサーバ側設定情報の項目は、端末側設定情報の項目に応じて適切に選択される。

またノード関連情報の内容は、上記実施形態で例示した内容に限られない。例えば、ノード関連情報に、ユーザＩＤまたはノード定義データＮＤのバージョンが含まれてもよい。

また上記実施形態において、ゲームアプリＡＰの機能により実行されるとした処理の一部または全部を、ブラウザが実行する構成としてもよい。

また上記実施形態において、サーバ記憶部１２にデータ管理ＤＢおよびゲーム管理ＤＢが記憶される構成でもよい。

また上記実施形態で示した機能ブロックは、任意のハードウェア、または、任意のハードウェアと任意のソフトウェアとの連携により実現可能である。つまり、これら機能ブロックは、特定のハードウェアに限定されるものではない。

また上記実施形態のフローチャートの処理単位は、処理を理解容易にするために、主な処理内容に応じて分割したものである。処理単位の分割の仕方または名称によって、本願発明が制限されることはない。各装置の処理は、処理内容に応じて、さらに多くの処理単位に分割することもできる。また、１つの処理単位がさらに多くの処理を含むように分割することもできる。また、同様の処理を行うことができるのであれば、上記のフローチャートの処理順序も、図示した例に限られるものではない。

また例えば、サーバ２またはユーザ端末３のコンピュータが実行するプログラムの提供を実施形態に含めることができる。また、当該プログラムをコンピュータで読み取り可能に記録した記録媒体の提供を実施形態に含めることができる。上記記録媒体は例えば、フレキシブルディスク、ＨＤＤ（Hard Disk Drive）、ＣＤ－ＲＯＭ（Compact Disc Read Only Memory）、ＤＶＤ（Digital Versatile Disc）、Ｂｌｕ－ｒａｙ Ｄｉｓｃ（登録商標）、光磁気ディスク、フラッシュメモリ、カード型記録媒体である。

１ 制御システム
２ サーバ
３ ユーザ端末（端末）
１０ サーバ制御部
１３ 端末制御部
ＬＤ ログデータ
ＬＧ ログ
ＮＤ ノード定義データ
ＤＬ 送信用ログデータ

Claims (11)

1. サーバと、前記サーバと通信可能な端末とを備え、ゲームを提供する制御システムであって、
   前記ゲームの提供の前に、前記サーバと前記端末とのそれぞれが、前記ゲームに対応する共通のノード定義データを利用可能な状態が構築され、
   前記ノード定義データには、前記ゲームの状態を示すノードが複数定義され、
   前記端末は、
   ユーザによって前記ゲームが行われている間、前記端末の前記ノード定義データに基づいて前記ノードを遷移させ、前記ノードの遷移に応じて前記端末の前記ノード定義データに対応する端末側設定情報の値を変化させる一方、前記ノードの遷移を再現可能な遷移再現情報および前記ノードの遷移に応じて変化した前記端末側設定情報の値をログとしてログデータに記録する機能と、
   前記ログの送信に関するログ送信条件が成立した場合、前記ログデータに記録された前記ログを含む送信用ログデータを前記サーバに送信する機能とを有する端末制御部を備え、
   前記サーバは、
   前記端末から受信した前記送信用ログデータの前記遷移再現情報および前記サーバの前記ノード定義データに基づいて前記ノードの遷移を再現し、前記ノードの遷移に応じて前記サーバの前記ノード定義データに対応するサーバ側設定情報の値を変化させると共に、前記サーバ側設定情報の値と前記送信用ログデータに記録された対応する前記端末側設定情報の値とを比較する検証処理を実行する機能を有するサーバ制御部を備える
   ことを特徴とする制御システム。
2. 前記ノード定義データには、前記ノードの遷移のトリガとなるトリガ事象と、前記トリガ事象が発生したときの前記ノードの遷移の態様とが定義された遷移ルールが更に定義され、
   前記端末制御部は、
   前記ユーザによって前記ゲームが行われている間、前記トリガ事象の発生に応じて、前記端末の前記ノード定義データの前記遷移ルールに基づいて前記ノードを遷移させ、前記ノードの遷移に応じて前記端末側設定情報の値を変化させる一方、
   発生した前記トリガ事象の内容を示す前記遷移再現情報を前記ログとして前記ログデータに記録すると共に、前記ノードの遷移に応じて変化した前記端末側設定情報の値を前記ログとして前記ログデータに記録し、
   前記サーバ制御部は、前記検証処理において、
   前記送信用ログデータに記録された前記遷移再現情報に基づいて、時系列に沿って前記トリガ事象を発生させ、前記トリガ事象の発生に応じて、前記サーバの前記ノード定義データに基づいて前記ノードを遷移させ、前記ノードの遷移に応じて前記サーバ側設定情報の値を変化させると共に、変化後の前記サーバ側設定情報の値と前記送信用ログデータに記録された対応する前記端末側設定情報の値とを比較する
   ことを特徴とする請求項１に記載の制御システム。
3. 前記ノード定義データには、前記ゲームに関する所定の事項の状態を示す状態変数と、自ノードに遷移された場合に実行される処理である遷移時処理が定義可能であり、
   前記遷移時処理には、前記状態変数を変化させる処理が含まれ、
   前記端末側設定情報には、前記端末の前記ノード定義データに定義された前記状態変数が含まれ、
   前記サーバ側設定情報には、前記サーバの前記ノード定義データに定義された前記状態変数が含まれる
   ことを特徴とする請求項１に記載の制御システム。
4. 前記端末制御部は、前記端末側設定情報の値として、前記端末側設定情報の値のハッシュ値である状態ハッシュ値を前記ログデータに記録し、
   前記サーバ制御部は、前記検証処理において、前記ノードの遷移に応じて前記サーバ側設定情報の値のハッシュ値である比較対象ハッシュ値を導出し、前記比較対象ハッシュ値と前記送信用ログデータに記録された対応する前記状態ハッシュ値とを比較する
   ことを特徴とする請求項１に記載の制御システム。
5. 前記サーバと前記端末とのそれぞれは、共通する乱数生成器を利用可能であり、
   前記サーバ制御部は、乱数シードを生成して前記端末に送信する一方、前記検証処理において前記ノードの遷移に応じて乱数を使用する処理を実行する場合には、生成した前記乱数シードおよび前記サーバの前記乱数生成器を使用して処理を実行し、
   前記端末制御部は、前記ノードの遷移に応じて乱数を使用する処理を実行する場合には、前記サーバから受信した前記乱数シードおよび前記端末の前記乱数生成器を使用して処理を実行する
   ことを特徴とする請求項１に記載の制御システム。
6. 前記端末制御部は、
   前記ノードの遷移に応じて乱数を使用する処理を実行する場合、カテゴリを指定し、指定したカテゴリに応じて前記乱数シードの値を変化させ、値が変化された後の前記乱数シードおよび前記端末の前記乱数生成器を使用して処理を実行し、
   前記サーバ制御部は、前記検証処理において、
   前記ノードの遷移に応じて乱数を使用する処理を実行する場合、前記端末で行われた対応する処理において前記端末制御部により指定されたカテゴリと同じカテゴリを指定し、指定したカテゴリに応じて前記乱数シードの値を変化させ、値が変化された後の前記乱数シードおよび前記サーバの前記乱数生成器を使用して処理を実行する
   ことを特徴とする請求項５に記載の制御システム。
7. 前記端末側設定情報には、前記ゲームにおける前記端末制御部によるカテゴリ別の乱数の使用回数が含まれ、
   前記サーバ側設定情報には、前記検証処理における前記サーバ制御部によるカテゴリ別の乱数の使用回数が含まれる
   ことを特徴とする請求項６に記載の制御システム。
8. 前記サーバ制御部は、前記検証処理において、
   前記ノードの遷移に応じて各値を比較した結果、各値が同一ではないと判定した場合、過去に前記サーバ側設定情報の値と同一であると判定した前記端末側設定情報の値が前記ログデータに記録された段階よりも前から前記ゲームが再開される状態を構築するか、または、前記ゲームが最初から再開される状態を構築する
   ことを特徴とする請求項１に記載の制御システム。
9. 前記ログ送信条件は、定期的に発生するタイミングが到来したことという条件、または、前記ログデータに一定数の前記ログが記録されたことという条件である
   ことを特徴とする請求項１に記載の制御システム。
10. 端末と通信可能であり、前記端末と協働してゲームを提供するサーバであって、
    前記ゲームの提供の前に、前記サーバと前記端末とのそれぞれが、前記ゲームに対応する共通のノード定義データを利用可能な状態が構築され、
    前記ノード定義データには、前記ゲームの状態を示すノードが複数定義され、
    前記端末で行われた前記ノードの遷移を再現可能な遷移再現情報を示すログ、および、前記ノードの遷移に応じて変化した前記端末の前記ノード定義データに対応する端末側設定情報の値を示す前記ログを含む送信用ログデータを前記端末から受信し、受信した前記送信用ログデータの前記遷移再現情報および前記サーバの前記ノード定義データに基づいて前記ノードの遷移を再現し、前記ノードの遷移に応じて前記サーバの前記ノード定義データに対応するサーバ側設定情報の値を変化させると共に、前記サーバ側設定情報の値と前記送信用ログデータに記録された対応する前記端末側設定情報の値とを比較する検証処理を実行する機能を有するサーバ制御部を備える
    ことを特徴とするサーバ。
11. サーバと、前記サーバと通信可能な端末とを備え、ゲームを提供する制御システムによる制御方法であって、
    前記ゲームの提供の前に、前記サーバと前記端末とのそれぞれが、前記ゲームに対応する共通のノード定義データを利用可能な状態が構築され、
    前記ノード定義データには、前記ゲームの状態を示すノードが複数定義され、
    前記端末が、ユーザによって前記ゲームが行われている間、前記端末の前記ノード定義データに基づいて前記ノードを遷移させ、前記ノードの遷移に応じて前記端末の前記ノード定義データに対応する端末側設定情報の値を変化させる一方、前記ノードの遷移を再現可能な遷移再現情報および前記ノードの遷移に応じて変化した前記端末側設定情報の値をログとしてログデータに記録するステップと、
    前記端末が、前記ログの送信に関するログ送信条件が成立した場合、前記ログデータに記録された前記ログを含む送信用ログデータを前記サーバに送信するステップと、
    前記サーバが、前記端末から受信した前記送信用ログデータの前記遷移再現情報および前記サーバの前記ノード定義データに基づいて前記ノードの遷移を再現し、前記ノードの遷移に応じて前記サーバの前記ノード定義データに対応するサーバ側設定情報の値を変化させると共に、前記サーバ側設定情報の値と前記送信用ログデータに記録された対応する前記端末側設定情報の値とを比較する検証処理を実行するステップとを含む
    ことを特徴とする制御方法。