JP2013202270A - サーバシステム - Google Patents

Abstract

【課題】約束の時間を指定するゲームに係る予約行為を利用して、よりゲームの興趣を高めるとともに、ユーザ間のコミュニケーションを醸成する要素を生み出す。
【解決手段】ゲームプレイ中に予約イベントが発生すると、ユーザ２（２ａ）は、イベント本体がプレイ可能になる日時（プレイ予約日時）を設定・予約することができる。これに伴って、フレンドユーザ２（２ｂ）、２（２ｃ）へプレイ予約日時を通知する。そして、プレイ予約日時に基づく許容時間範囲内に、予約設定主のユーザ２（２ａ）と、通知を受けたフレンドユーザ２（２ｂ）、２（２ｃ）がゲームプレイすると、彼らに特典が付与される。
【選択図】図３

Description

本発明は、プレーヤ端末から送信される操作入力に従ってゲームを進行制御するサーバシステムに関する。

ゲームにおいて、時間を指定するといった予約行為自体は知られている。例えば、オンラインゲームに参加する日時を予約をしておいて、その予約日時にアクセスすると確実にゲームに参加できるようにする技術が知られている（例えば、特許文献１参照）。

また、ゲームによっては、ゲーム内のＮＰＣ（ノンプレーヤキャラクタ）がプレーヤの住居（ゲーム空間上に設定した住居）に遊びに行きたいと話しかけてきて、これを了承し訪問時間を指定すると、その訪問時間に訪問して来るイベントが発生するゲームも知られている（例えば、非特許文献１参照）。

特許第３８２２８２５号公報

携帯型ゲーム装置「ニンテンドーＤＳ」向けゲームソフト「おいでよ どうぶつの森」、任天堂株式会社、２００５年１１月２３日発売、製品公式ホームページのインターネットＵＲＬ<http://www.nintendo.co.jp/ds/admj/>

しかしながら、従来のゲームでは、予約は、１人のプレーヤ（或いはＰＣ（プレーヤキャラクタ））自身のみに関するものであり、プレーヤ（或いはＮＰＣ）同士に関するものではなかった。
勿論、近年のＳＮＳ（Social Networking Service）ゲームも同様である。ＳＮＳなどコミュニティ型のウェブサイトでは、サービスの一環として複数のゲームを用意して、ユーザが任意にゲームを選択してプレイできるようになっている。ＳＮＳゲームではユーザはそれぞれの都合の良い時間に短時間のゲームプレイを楽しむことが多い。このため、ユーザ間のコミュニケーションを醸成する仕組みは、ＳＮＳゲーム以外もそうであるが、ＳＮＳゲームにおいても望まれていた。

本発明は、約束の時間を指定するゲームに係る予約行為を利用して、よりゲームの興趣を高めるとともに、ユーザ間のコミュニケーションを醸成する要素を生み出すことを目的とする。

上述した課題を解決するための第１の形態は、プレーヤ端末（例えば、図１のユーザ端末）から送信される操作入力に従ってゲームを進行制御するサーバシステムであって、
各プレーヤそれぞれについて、当該プレーヤに関係する関係プレーヤを記憶する関係プレーヤ記憶手段（例えば、図１のストレージ１１４０、図５のサーバ記憶部５００ｓｖ、図６のユーザ登録データ５２０、フレンドリスト５２５）と、
一のプレーヤの次回のプレイ予約日時を設定する予約設定手段（例えば、図５のサーバ処理部２００ｓｖ、ゲーム管理サーバ制御部２３０、イベント管理部２３６、イベント予約設定部２３８、図９のステップＳ３０）と、
前記一のプレーヤ及び当該一のプレーヤの関係プレーヤが、前記予約設定手段により設定された予約日時を含む所定の許容時間範囲にプレイしたか否かを判定する判定手段（例えば、図５のサーバ処理部２００ｓｖ、ゲーム管理サーバ制御部２３０、予約設定主ユーザプレイ判定部２４６、予約日時通知先ユーザプレイ判定部２４８、図１２のステップＳ１２８、Ｓ１４４）と、
前記判定手段により肯定判定された場合に、前記一のプレーヤ、及び／又は、当該一のプレーヤの関係プレーヤに所与の特典を付与する特典付与手段（例えば、図５のサーバ処理部２００ｓｖ、ゲーム管理サーバ制御部２３０、特典付与制御部２５２、図９のステップＳ１５２）と、を備えたサーバシステムである。

第１の形態によれば、プレイ予約日時に予約を設定したプレーヤと関係プレーヤの双方がプレイした場合に特典を付与することができる。よって、予約の仕組を利用してゲームの興趣を高めるとともに、両者の話題作りをしてユーザ間のコミュニケーションを醸成する要素を生み出すことができる。

第２の形態は、前記一のプレーヤの関係プレーヤのプレーヤ端末に、前記予約設定手段により設定された予約日時を通知する関係プレーヤ通知手段（例えば、図５のサーバ処理部２００ｓｖ、ゲーム管理サーバ制御部２３０、図９のステップＳ６０）を更に備え、前記判定手段は、前記一のプレーヤ、及び、前記関係プレーヤ通知手段による通知先の関係プレーヤがプレイしたか否かを判定し、前記特典付与手段は、前記判定手段により肯定判定された場合に、前記一のプレーヤ、及び／又は、前記関係プレーヤ通知手段による通知先の関係プレーヤに所与の特典を付与する、第１の形態のサーバシステムである。

第２の形態によれば、第１の形態と同様の効果が得られるとともに、関係プレーヤに予約日時を通知することができる。そして、通知を受けた関係プレーヤが許容時間範囲内でプレイした場合に特典を付与するようにできる。

第３の形態は、通知先の関係プレーヤを選択する通知先選択手段（例えば、図５の操作入力部１００ｓｖ、サーバ処理部２００ｓｖ、ゲーム管理サーバ制御部２３０、通知先選択制御部２４２、図１０のステップＳ６２〜Ｓ９０）を更に備え、
前記関係プレーヤ通知手段は、前記通知先選択手段により選択された通知先に、前記予約設定手段により設定された予約日時を通知する、第２の形態のサーバシステムである。

第３の形態によれば、第２の形態と同様の効果が得られるとともに、通知先を関係プレーヤの中から選択可能になる。

第４の形態は、前記特典付与手段が、前記通知先の関係プレーヤのうち、前記予約日時を含む前記許容時間範囲にプレイした関係プレーヤの比率又は数に基づいて、付与する特典を変更する手段（例えば、図１２のステップＳ１４０）を有する、第３の形態のサーバシステムである。

第４の形態によれば、第３の形態と同様の効果が得られるとともに、付与する特典に変化をつけられる。

第５の形態は、前記ゲームにおける行動の指示操作入力がなされる毎に消費し、時間経過により回復する各プレーヤの行動パラメータを管理する行動パラメータ管理手段（例えば、図５のサーバ処理部２００ｓｖ、ゲーム管理サーバ制御部２３０、行動パラメータ管理部２３４）を更に備え、
前記通知先選択手段は、前記一のプレーヤの関係プレーヤの行動パラメータを用いて、通知先の関係プレーヤを選択する（例えば、図１１のステップＳ７８）、第３又は第４の形態のサーバシステムである。

第５の形態によれば、第３又は第４の形態と同様の効果が得られるとともに、行動パラメータが回復してそうな関係プレーヤを通知先として選択することができる。行動パラメータが不足しているとゲームプレイできないので、行動パラメータが回復してそうな関係プレーヤを通知先として選択することができれば、それだけ許容時間範囲内でゲームプレイしてもらえる可能性が高くなり、特典の付与が起きやすくなり、プレーヤ間での話題作り・コミュニケーションの醸成に寄与できる。

同様の効果を期待するならば、第６の形態として、前記関係プレーヤ記憶手段が、当該プレーヤと当該プレーヤの関係プレーヤとの友好度を記憶する友好度記憶手段（例えば、図６のサーバ記憶部５００ｓｖ、ユーザ登録データ５２０、図７のフレンドリスト５２５、友好度５２７）を有し、前記通知先選択手段は、前記一のプレーヤと当該関係プレーヤとの友好度を用いて、通知先の関係プレーヤを選択する、第３〜第５の何れかの形態のサーバシステムを構成することができる。

第７の形態は、前記各プレーヤの前記ゲーム上の属性、職業、及びレベルのうちの少なくとも１つをプレイデータに含めて管理するプレイデータ管理手段（例えば、図５のサーバ処理部２００ｓｖ、ゲーム管理サーバ制御部２３０、プレイデータ管理部２３２、図８のプレイデータ５７０）を更に備え、前記通知先選択手段は、前記一のプレーヤのプレイデータと、関係プレーヤのプレイデータとを用いて、通知先の関係プレーヤを選択する、第３〜第６の何れかの形態のサーバシステムである。

第７の形態によれば、第３〜第６の形態の何れかと同様の効果が得られるとともに、プレーヤの（実質的にはプレーヤが操作するプレーヤキャラクタ）の特性や状態に応じて通知先の関係プレーヤを選択することができる。

第８の形態は、前記ゲームにおける行動の指示操作入力がなされる毎に消費し、時間経過により回復する各プレーヤの行動パラメータを管理する行動パラメータ管理手段（例えば、図５のサーバ処理部２００ｓｖ、ゲーム管理サーバ制御部２３０、行動パラメータ管理部２３４）を更に備え、前記予約設定手段は、前記一のプレーヤの行動パラメータに基づいて、次回のプレイ予約日時を設定する、第１〜第７の何れかの形態のサーバシステムである。

第８の形態によれば、第１〜第７の形態の何れかと同様の効果が得られるとともに、プレーヤの行動パラメータに基づいて予約日時を設定することができる。例えば、行動パラメータが時間経過とともに自動回復する仕様が盛り込まれている場合、現在の行動パラメータから次にゲームプレイ可能なほど回復している日時を予測して、予約日時を設定するならば、予約したが実際にはプレイできないといった事態を防ぐことができる。

第９の形態は、前記ゲームにおける行動の指示操作入力がなされる毎に消費し、時間経過により回復する各プレーヤの行動パラメータを管理する行動パラメータ管理手段を更に備え、前記予約設定手段は、前記一のプレーヤの関係プレーヤの行動パラメータに基づいて、次回のプレイ予約日時を設定する、第１〜第８の何れかの形態のサーバシステムである。

第９の形態によれば、第１〜第８の形態の何れかと同様の効果が得られるとともに、関係プレーヤの行動パラメータに基づいて予約日時を設定することができる。例えば、行動パラメータが時間経過とともに自動回復する仕様が盛り込まれている場合、関係プレーヤの現在の行動パラメータから次にゲームプレイ可能なほど回復している日時を予測して、予約日時を設定するならば、予約したが実際には関係プレーヤがプレイできないといった事態を防ぐことができる。

第１０の形態は、前記プレーヤ端末は位置取得手段（例えば、図２のＧＰＳアンテナ１５１４、ＧＳＰモジュール１５５４）を有しており、
前記プレーヤ端末からプレイ位置の情報を受信するプレイ位置情報受信手段（例えば、図５のサーバ処理部２００ｓｖ、プレイ位置情報取得制御部２５４、通信制御部２７０ｓｖ、通信部３７０ｓｖ）を更に備え、
前記予約設定手段は、次回のプレイ予約日時及びプレイ指定地点を設定し、
前記判定手段は、前記一のプレーヤ及び当該一のプレーヤの関係プレーヤのプレイ日時が前記予約日時を含む前記許容時間範囲であり、且つ、プレイ位置が前記プレイ指定地点を含む所定の許容圏内の場合に肯定判定する、第１〜第９の何れかの形態のサーバシステムである。

第１０の形態によれば、第１〜第９の形態の何れかと同様の効果が得られるとともに、判定手段による判定に、プレーヤがプレイしている位置を含めることができる。

第１実施形態におけるゲームシステムの構成の一例を示す図。 ユーザ端末の構成例を示す正面外観図。 第１実施形態におけるゲーム内予約について説明するための概念図。 ゲーム内予約に係るゲーム画面例を示す図。 第１実施形態におけるサーバシステムの機能構成の一例を示す機能ブロック図。 サーバ記憶部が記憶する情報の構成例を示す図。 フレンドリストのデータ構成の一例を示す図。 プレイデータのデータ構成の一例を示す図。 第１実施形態におけるゲーム内予約に係る処理の流れを説明するためのフローチャート。 プレイ予約日時通知処理の流れを説明するためのフローチャート。 お勧め順位設定処理の流れを説明するためのフローチャート。 特典付与予約設定処理の流れを説明するためのフローチャート。 特典付与処理の流れを説明するためのフローチャート。 プレイ指定位置候補リストのデータ構成の一例を示す図。 プレイ予約日時設定処理の変形例の流れを説明するためのフローチャート。

〔第１実施形態〕
本発明を適用した第１実施形態として、登録ユーザにサービスの一環として提供されるゲームにおいて、ゲーム内イベントの発動時間を予約するゲーム内予約を行う例について説明する。なお、以下では、ゲームに係る場合を含む一般的な意味として「ユーザ」という用語を用い、ゲームに係る場合に「プレーヤ」として適宜使い分けているが、同一に扱うことができるため、どちらか一方の用語に置き換えて読むこととしても勿論よい。

［システムの構成の説明］
図１は、本実施形態におけるゲームシステムの構成の一例を示す図である。本実施形態のゲームシステムは、通信回線１に接続することのできるサーバシステム１１００と、ゲームのプレーヤ２（２ａ，２ｂ，２ｃ，・・・）毎に用意されるユーザ端末１５００（１５００ａ，１５００ｂ，１５００ｃ，・・・）により構成される。

通信回線１は、データ通信が可能な通信路を意味する。すなわち、通信回線１とは、直接接続のための専用線（専用ケーブル）やイーサネット（登録商標）等によるＬＡＮ（Local Area Network）の他、電話通信網やケーブル網、インターネット等の通信網を含む意味であり、また、通信方法については有線／無線を問わない。

サーバシステム１１００は、単数又は複数のサーバシステムや記憶装置等を含んで構成され、コミュニティ型ウェブサイトや、オンラインゲームを運営するための各種サービスを提供し、ゲーム実行に必要なプレイデータの管理や、クライアントプログラム及び各種データ等を配信することができる。

本実施形態では、サーバシステム１１００は、筐体１１０２と、キーボード１１０６と、タッチパネル１１０８と、ストレージ１１４０とを備える。筐体１１０２には、複数のブレードサーバ１１０４が内蔵されている。

ブレードサーバ１１０４は、例えば、（１）ユーザ登録やプレーヤキャラクタの初期設定、及びログイン／ログアウトに関係する処理を担うアカウント管理サーバシステム１１１０、（２）ログインしてオンラインゲームに参加中のユーザ端末１５００へゲームを実行するのに必要なデータを随時管理・配信するゲーム管理サーバシステム１１１４、として機能する。尚、ブレードサーバ１１０４を構成するそれぞれのサーバは、通信回線１を介してデータ通信可能な独立したサーバシステムとして実現しても良い。

ユーザ端末１５００は、ユーザそれぞれに１台ずつ用意されるコンピュータであり、通信回線１に接続することのできる電子装置（電子機器）であり、ゲームプレイをするためのプレーヤ端末である。本実施形態のユーザ端末１５００は、スマートフォンとしての態様を有するが、その他、携帯型ゲーム装置や、据置型家庭用ゲーム装置、業務用ゲーム装置、パソコン、タブレット型コンピュータなどにより実現されるとしても良い。

図２は、ユーザ端末１５００の構成例を示す正面外観図である。本実施形態におけるユーザ端末１５００は、方向入力キー１５０２と、ホームキー１５０４と、画像表示デバイス兼接触位置入力デバイスとして機能するタッチパネル１５０６と、スピーカ１５１０と、マイク１５１２と、ＧＰＳ（Global Positioning System）アンテナ１５１４と、制御基板１５５０と、コンピュータ読み出し可能な情報記憶媒体であるメモリカード１５４０からデータを読み書きできるメモリカード読取装置１５４２と、を備える。その他、図示されていない内蔵バッテリーや電源ボタン、音量調節ボタン等が設けられている。

制御基板１５５０は、ＣＰＵ（Central Processing Unit）１５５１やＧＰＵ（Graphics Processing Unit）、ＤＳＰ（Digital Signal Processor）などの各種マイクロプロセッサ、ＡＳＩＣ（Application Specific Integrated Circuit）、ＶＲＡＭやＲＡＭ，ＲＯＭ等の各種ＩＣメモリ１５５２を搭載する。

そして、制御基板１５５０には、携帯電話基地局や無線ＬＡＮ基地局などと無線接続するための無線通信モジュール１５５３と、ＧＰＳモジュール１５５４と、電子コンパス１５５５と、３軸ジャイロ１５５６と、３軸加速度センサ１５５７とが搭載されている。
その他、タッチパネル１５０６のドライバ回路、方向入力キー１５０２及びホームキー１５０４からの信号を受信する回路、スピーカ１５１０へ音声信号を出力する出力アンプ回路、マイク１５１２で集音した音声の信号を生成する入力信号生成回路、メモリカード読取装置１５４２への信号入出力回路といった所謂Ｉ／Ｆ回路（インターフェース回路）、等が搭載されている。これら制御基板１５５０に搭載されている各要素は、それぞれバス回路などを介して電気的に接続され、データの読み書きや信号の送受信が可能に接続されている。

ＧＰＳモジュール１５５４は、ＧＰＳアンテナ１５１４とともにＧＰＳを利用した位置情報を取得する手段を構成する。ＧＰＳモジュール１５５４は、ＧＰＳアンテナ１５１４で受信したＧＰＳ衛星３からの信号に基づいて、所定時間毎（例えば、１秒毎）に、位置情報（例えば、緯度・経度）及びその他の情報（絶対時間）を、制御基板１５５０で演算処理可能なデータとして出力する。尚、測位に利用するシステムはＧＰＳに限らない。その他の衛星測位システムでも良いし、衛星を用いない測位システムを用いることもできる。後者の例としては、例えば、無線通信モジュール１５５３が無線接続できる携帯電話基地局からの信号に基づいて三角測量の原理で測位して、位置情報を取得するとしても良い。

制御基板１５５０は、サーバシステム１１００から取得したゲームクライアントプログラムやデータをＩＣメモリ１５５２に一時記憶する。そして、プログラムを実行して演算処理を実行し、方向入力キー１５０２やホームキー１５０４、タッチパネル１５０６からの操作入力に応じてユーザ端末１５００の各部を制御して、オンラインＲＰＧを実行する。尚、本実施形態では、ユーザ端末１５００は必要なプログラムや各種設定データをサーバシステム１１００から取得する構成としているが、別途入手したメモリカード１５４０から読み出す構成としても良い。

本実施形態では、ユーザはサーバシステム１１００が提供するサービスを利用するには、所定の手続きを行ってユーザアカウントを取得する必要がある。取得したユーザアカウントと対応づけられるパスワードをもってログインすることで、登録ユーザ間でのメッセージ交換や、フレンド登録、ゲームプレイなどのサービスが利用可能となる。

登録ユーザは、所定のゲーム利用登録をすることで、複数のゲームの中から任意のゲームを好きな時に遊ぶことが可能である。そして、登録ユーザ同士で、メッセージ交換サービスを利用してゲームのことなどを話題にしてコミュニケーションすることができる。

登録ユーザは同じゲームをプレイする他ユーザとメッセージのやりとりを通じて気の合った他ユーザを、フレンド登録サービスを利用して「フレンド」として登録することができる。つまり、各プレーヤそれぞれについて、当該プレーヤに関係する関係プレーヤを登録することができる。フレンド登録したユーザ間では、ユーザ登録情報やプレイデータ（ゲームの進行状況を記述するパラメータを含むデータ群）に相互に参照可能になる。以降、フレンドとして登録された他ユーザを「フレンドユーザ」と呼称する。

尚、ユーザ登録や、フレンド登録、メッセージ交換、ゲームの提供などのサービス機能は、公知のＳＮＳ（social networking service）などコミュニティ型のウェブサイトの運用技術と同様に実現できる。本実施形態のメッセージ交換サービスは、ユーザ端末１５００へのプッシュ通知として実現さされるが、その他の公知の通知サービスや電子メールサービスにより実現されるとしても良い。

［ゲーム内予約についての説明］
図３は、本実施形態におけるゲーム内予約について説明するための概念図である。本実施形態では、イベント本体と、その開始時刻を事前に予約する予約イベントの２つでセットのゲーム内予約と呼ぶ特別なイベントがある。

ユーザ２（２ａ）が１０：００にログインしてゲームを開始したとする。途中、予約イベントが発生すると、イベント本体がプレイ可能になる基準日時を予約することができる。本実施形態では、この基準日時をプレーヤが自由に指定できる。以降、この基準日時を「プレイ予約日時」と呼称する。

予約イベントにおいてプレイ予約日時を設定すると、ユーザ２（２ａ）はフレンドユーザの中から幾人かにプレイ予約日時を通知することができる。図３の例では、通知先はフレンドユーザ２（２ｂ）、２（２ｃ）の２名であるがその人数は適宜設定可能である。

プレイ予約日時を基準として、許容時間範囲が自動的に決定される。図３の例ではプレイ予約日時を含んで前３０分を許容範囲時間としているが、プレイ予約日時を含んでいれば前後の幅（時間）としてもよいし、許容範囲時間の幅自体も適宜設定可能である。また、場合によってはプレイ予約日時以降の時刻のみを含むとしても良い。

そして、プレイ予約日時を設定した本人、つまりユーザ２（２ａ）が許容時間範囲内でプレイしているとイベント本体が開始され、約束を守った褒美として特典が付与される。
また、プレイ予約日時の通知を受けたフレンドユーザ２（２ｂ），２（２ｃ）が、その通知を元に同じ許容時間範囲内にゲームをプレイすると、やはり彼らにも特典が付与される。ただし、ユーザ２（２ａ）と、フレンドユーザ２（２ｂ），２（２ｃ）とは非同期のゲーム進行がなされている。

付与される特典の内容及びその量や度合は，ゲーム内容等に応じて適宜設定可能である。
本実施形態のゲームは行動ポイント制を採用しているため、本実施形態での特典は行動ポイントの回復とする。
具体的には、プレーヤキャラクタの行動に関するパラメータとして行動ポイント（ＡＰ：Action Point）が与えられるものとする。行動ポイントは、プレーヤキャラクタが何らかの行動をとる際に消費されるポイントであって、行動の種類によって消費されるポイントが異なる。例えば、移動なら２ポイント消費、攻撃なら４ポイント消費、アイテム使用なら１ポイント消費、・・・と言った具合である。行動ポイントは、時間とともに自動的に回復するが、所定のＡＰ回復アイテムの使用にともなって瞬時に回復を図ることもできる。そして、特典として付与される行動ポイントの回復は、プレイ予約日時の通知をしたフレンドユーザのうち、実際に許容時間範囲内にプレイした人数やその比率が多いほど多くのポイントが回復されるように設定される。
勿論、特典内容は、アイテムの付与であったり、ゲーム開始前やゲーム中に実行できる抽選権の付与、ゲーム開始前やゲーム中に実行できる抽選権、ゲーム開始前やゲーム中に実行できる抽選の当選確率の限定的な上昇（例えば、１回限り当選確率を高めるなど）、ゲームステージをプレイする権利、などを設定することができる。

図４は、本実施形態におけるゲーム内予約に係るゲーム画面例を示す図である。ＮＰＣによる“遊び”の誘いを受けるか否か、及びその“遊び”をする日時を設定することをゲーム内予約としている。“遊び”がイベント本体に相当し、“遊び”にはＮＰＣの他、フレンドユーザも一緒に誘うことができる。図４（１）は、予約イベントが発生した状態のゲーム画面Ｗ２の例である。画面下部にイベント本体の予告６が表示される。図の例では、一緒に映画に行くイベントであることを告げるテキストが表示されている。また、ゲーム画面Ｗ２には、イベント本体をプレイする意志があって許可するか、すなわちイベント本体の予約をするか否かを選択する操作ガイド８が表示される。

ユーザ２（２ａ）が操作ガイド８に従ってイベント本体をプレイする意志がある場合、許可操作入力すると、例えば図４（２）のようなプレイ予約日時設定ウィンドウ１０がポップアップ表示される。当該ウィンドウでは、月・日・時刻をカラム表示形式などで選択可能に表示される。そして、所定のプレイ予約日時の設定完了操作をすると、プレイ予約日時設定ウィンドウ１０に代えて、例えば図４（３）のような通知先選択ウィンドウ１２が表示される。

通知先選択ウィンドウ１２では、自動仮設定されたフレンドユーザのユーザアカウントが通知先表示部１６に表示される。一方、選択候補表示部１４では、カラム表示形式などによりユーザ２（２ａ）のフレンドユーザが選択可能に表示され、通知先に仮設定されているフレンドユーザを変えることができる。
具体的には、通知先表示部１６の何れかの表示を変更対象指定操作し（図４（３）中の太枠線が選択状態）、選択候補表示部１４にて新たなフレンドユーザを選択すると、先の変更対象指定操作された通知先を新たなフレンドユーザに変更可能である。この一連の操作を「通知先の入れ替え操作」或いは「通知先の設定操作」と呼ぶ。

本実施形態の選択候補表示部１４では、フレンドユーザをお勧め順位に従って上から下に降順に表示することができる。お勧め順位は、許容時間範囲内にプレイしてくれる可能性の高い順に相当する。例えば、ユーザ２（２ａ）と各フレンドユーザとの組み合わせで、コミュニケーションの頻度等に応じて自動付与される好感度や友好度といったパラメータの大きい順ほど上位順に設定される。更には、フレンドユーザの行動ポイントが、許容時間範囲内で回復されているであろう予測ポイント値が大きい程上位順位が設定されるとしても良い。

通知先選択ウィンドウ１２にて所定の設定完了操作を入力すると、今回の予約イベントにおけるプレイ予約日時の設定は完了となる。以降、許容時間範囲の開始時刻までは、プレイを継続していても良いし、プレイを中断するとしてもよくユーザの自由である。そして、許容時間範囲にプレイ予約日時の設定主であるユーザ２（２ａ）がプレイをしていれば、当該プレイ予約日時と紐付けされるイベント本体が発動する。

［機能ブロックの説明］
次に、本実施形態を実現するための機能構成について説明する。
図５は、本実施形態におけるサーバシステム１１００の機能構成の一例を示す機能ブロック図である。サーバシステム１１００は、操作入力部１００ｓｖと、サーバ処理部２００ｓｖと、画像表示部３６０ｓｖと、通信部３７０ｓｖと、サーバ記憶部５００ｓｖとを備える。

操作入力部１００ｓｖは、サーバオペレータによって為された各種の操作入力（プレーヤキャラクタの行動の指示操作入力を含む）に応じて操作入力信号をサーバ処理部２００ｓｖに出力する。例えば、キーボードや、タッチパネル、マウス、トラックパッドなどによって実現できる。図１ではキーボード１１０６やタッチパネル１１０８がこれに該当する。

サーバ処理部２００ｓｖは、例えばＣＰＵやＧＰＵ等のマイクロプロセッサや、ＡＳＩＣ、ＩＣメモリなどの電子部品によって実現される。サーバ処理部２００ｓｖは、各機能部との間でデータの入出力制御を行い、所定のプログラムやデータ、操作入力部１００ｓｖからの操作入力信号や、通信部３７０ｓｖを介して外部からアクセスしてきた外部装置（他コンピュータ）等からのリクエストに応じて各種の演算処理を実行して、サーバシステム１１００の動作を制御する。図１ではブレードサーバ１１０４、より具体的にはその制御基板がこれに該当する。

そして、本実施形態のサーバ処理部２００ｓｖは、コミュニティサービス制御部２０２と、ゲーム管理サーバ制御部２３０と、画像生成部２６０ｓｖと、通信制御部２７０ｓｖとを備える。

コミュニティサービス制御部２０２は、登録会員制のコミュニティサイトの会員サービスを実現する。本実施形態では、ユーザ登録情報管理部２０４と、プッシュ通知制御部２０８と、ログイン処理部２１０とを含む。

ユーザ登録情報管理部２０４は、ユーザアカウントの新規発行、パスワードの登録など各種ユーザ情報の取得・登録管理に関する処理を実行する。そして、本実施形態のユーザ登録情報管理部２０４は、フレンドリスト管理部２０６と、友好度管理部２０７とを含む。

フレンドリスト管理部２０６は、各プレーヤそれぞれについて、当該プレーヤに関係する関係プレーヤ（本実施形態のフレンド）の登録／登録抹消に関する制御をする。
友好度管理部２０７は、フレンドとのコミュニケーションの頻度（例えば、相互間のプッシュ通知の頻度）に応じてユーザと各フレンドユーザとの友好度を所定の関数に従って自動設置・自動更新できる。こうしたユーザ登録情報管理部２０４の機能は、公知のマルチプレイオンラインゲームにおける会員サービスや、コミュニティ型ウェブサイトにおける会員サービスの技術を適宜利用することで実現できる。

ゲーム管理サーバ制御部２３０は、本実施形態のゲームの進行制御並びにユーザ端末１５００にゲーム画像等を表示させるのに必要な処理を実行する。すなわち、常時機能している状態にあって、ユーザ端末１５００からゲーム開始リクエストを受けると新たなプレイデータを生成して、個別にゲーム進行を制御することができる。そして、これら両制御部は、ゲーム内容が異なるだけで基本的には同じ構成を有する。

そして、ゲーム管理サーバ制御部２３０は、プレイデータ管理部２３２と、イベント管理部２３６と、予約設定主ユーザプレイ判定部２４６と、予約日時通知先ユーザプレイ判定部２４８と、特典付与制御部２５２と、プレイ位置情報取得制御部２５４と、を含む。

プレイデータ管理部２３２は、当該ゲーム管理サーバ制御部で進行制御するゲームの進行状況を記述するデータ、所謂プレイデータを管理する。本実施形態では更に、行動パラメータ管理部２３４を含む。

行動パラメータ管理部２３４は、プレーヤキャラクタの行動パラメータを管理する。本実施形態では、ゲームにおける行動の指示操作入力がなされる毎に行動ポイントを行動種類に応じた値だけ減算し消費する。また、時間経過又はＡＰ回復アイテムの使用により加算・回復させる。

イベント管理部２３６は、ゲーム進行状況に応じて各種イベントの発動を管理する。本実施形態では、予約イベントを発動させ、予約イベントで設定されたプレイ予約日時を基準とした許容時間範囲内に、当該プレイ予約日時の設定主がゲームプレイをしていることを検出して、イベント本体を発動させることができる。
具体的には、イベント管理部２３６は、イベント予約設定部２３８と、通知先選択制御部２４２と、予約日時通知制御部２４４と、を含む。

イベント予約設定部２３８は、予約イベントの発動条件を満たしたことが検出された場合に、プレイ予約日時の設定に関する処理を実行する。例えば、図４に示したように、ゲーム画面に予告６や操作ガイド８、プレイ予約日時設定ウィンドウ１０を表示させ、プレイ予約日時を設定する。

通知先選択制御部２４２は、プレイ予約日時の通知先をフレンドユーザの中から選択する。具体的には、ゲーム画面に通知先選択ウィンドウ１２を表示させる。この時、フレンドユーザ毎の関連情報を参照してお勧め順位を決定し、当該お勧め順位に従って通知先を仮設定し、仮の通知先としたフレンドユーザのユーザアカウントを通知先表示部１６に表示させる。そして、ユーザによる通知先の入れ替え選択操作に応じて仮の通知先としていたフレンドユーザを、選択候補表示部１４で選択操作されたフレンドユーザに再設定する。

予約日時通知制御部２４４は、通知先として設定されたフレンドユーザ宛に、プッシュ通知制御部２０８を介したプレイ予約日時の通知制御をする。通知の形式は適宜設定可能であるが、プレイ予約日時の設定主のユーザアカウントと、ゲームタイトル、プレイ予約日時、を含むとする。更に好ましくは、許容時間範囲内にプレイすると特典が付与される旨の勧誘が含まれると良い。

予約設定主ユーザプレイ判定部２４６は、既に設定されているプレイ予約日時の許容時間範囲内に、当該プレイ予約日時の設定主ユーザがゲームをプレイしているか否かを判定する。

予約日時通知先ユーザプレイ判定部２４８は、既に設定されているプレイ予約日時の許容時間範囲内に、当該プレイ予約日時の通知先となったフレンドユーザがゲームをプレイしているか否かを判定する。

特典付与制御部２５２は、ゲーム進行状況が所定の特典付与条件を満たす場合にユーザへ特典を付与する制御を行う。本実施形態では、予約日時通知先ユーザプレイ判定部２４８により予約設定主ユーザが許容時間範囲内でゲームプレイしていると判定された場合に、当該予約設定主ユーザの行動ポイントを回復させる。また、予約日時通知先ユーザプレイ判定部２４８でゲームプレイしていると判定されたフレンドへ特典を付与する。また、付与する特典内容を決定することができる。

プレイ位置情報取得制御部２５４は、通信部３７０ｓｖを介してユーザ端末１５００からゲームプレイしている地点を示す位置情報を取得するための制御をする。

画像生成部２６０ｓｖは、例えば、ＧＰＵ（Graphics Processing Unit）、デジタルシグナルプロセッサ（ＤＳＰ）などのプロセッサ、ビデオ信号ＩＣ、ビデオコーデックなどのプログラム、フレームバッファ等の描画フレーム用ＩＣメモリ、テクスチャデータの展開用に使用されるＩＣメモリ等によって実現される。画像生成部２６０ｓｖは、サーバ処理部２００ｓｖによる処理結果に基づいて１フレーム時間（例えば１／６０秒）で１枚の画面を生成し、生成した画面の画像信号を画像表示部３６０ｓｖに出力する。

画像表示部３６０ｓｖは、画像生成部２６０ｓｖから入力される画像信号に基づいて各種画像を表示する。例えば、フラットパネルディスプレイ、ブラウン管（ＣＲＴ）、プロジェクター、ヘッドマウントディスプレイといった画像表示装置によって実現できる。本実施形態では、図１のタッチパネル１１０８がこれに該当する。

通信制御部２７０ｓｖは、データ通信に係るデータ処理を実行し、通信部３７０ｓｖを介して外部装置とのデータのやりとりを実現する。
これに関連する通信部３７０ｓｖは、通信回線１と接続してユーザ端末１５００との間の通信を実現する。例えば、無線通信機、モデム、ＴＡ（ターミナルアダプタ）、有線用の通信ケーブルのジャックや制御回路等によって実現される。

サーバ記憶部５００ｓｖは、サーバ処理部２００ｓｖに諸機能を実現させるためのプログラムやデータを記憶する。また、サーバ処理部２００ｓｖの作業領域として用いられ、各種プログラムに従って実行した演算結果や、ユーザ端末１５００から受信した情報等を一時的に記憶する。こうした機能は、例えばＲＡＭやＲＯＭなどのＩＣメモリ、ハードディスク等の磁気ディスク、ＣＤ−ＲＯＭやＤＶＤなどの光学ディスクなどによって実現される。図１では、ブレードサーバ１１０４に搭載されているＩＣメモリ等の情報記憶媒体や、ストレージ１１４０がこれに該当する。

図６は、本実施形態におけるサーバ記憶部５００ｓｖが記憶する情報の構成例を示す図である。
本実施形態のサーバ記憶部５００ｓｖは、サーバシステムプログラム５０１と、コミュニティサービスプログラム５０３と、ゲーム管理サーバプログラム５０５と、ゲームクライアントプログラム５０９と、ゲーム実行用データ５１１と、プレイ中ユーザ端末リスト５１３とを記憶する。
また、ユーザ登録データ５２０と、予約日時通知雛形データ５６８と、プレイデータ５７０と、イベント予約データ５９０と、特典付与予約データ６００とを記憶する。勿論、その他、ゲーム進行制御に必要な計時制御のカウント値、各種フラグなどを適宜記憶することができる。

サーバシステムプログラム５０１は、コンピュータにサーバとしての基本的な機能を実現させるためのプログラムである。
コミュニティサービスプログラム５０３は、サーバ処理部２００ｓｖに、コミュニティサービス制御部２０２としての機能を実現させるためのプログラムである。

ゲーム管理サーバプログラム５０５は、サーバ処理部２００ｓｖに、ゲーム管理サーバ制御部２３０としての機能を実現させるためのプログラムである。
ゲームクライアントプログラム５０９は、ゲームのプレイを希望するユーザ端末１５００に提供するクライアントプログラムの原本である。ユーザ端末１５００は、これをダウンロードして搭載する情報記憶媒体に記憶させて実行する。ゲームクライアントプログラム５０９は、専用のプログラムや、ウェブブラウサプログラム及びウェブブラウザプログラム上で動的な表示を実現するためのプラグインなどにより実現される。後者の構成は、オンラインゲームを所謂ブラウザゲームとして実現する場合に利用可能である。

ゲーム実行用データ５１１は、ゲームを実行するために必要な各種データを格納する。例えば、ゲームフィールドを設定するためのデータ、プレーヤキャラクタや敵キャラクタのモデルデータやモーションデータ、テクスチャデータ、キャラクタの初期能力パラメータ値、ゲーム中で使用可能なアイテムの設定データなどが含まれる。本実施形態では、予約制イベント設定データ５１２を含む。当該データでは、予約イベントとイベント本体を実行させるための情報が複数セット格納されている。予約イベント及びイベント本体にはそれぞれ予約イベントＩＤとイベント本体ＩＤとが付与されている。

プレイ中ユーザ端末リスト５１３は、現在ゲームプレイ中のユーザ端末１５００の識別情報や、ゲームプレイに必要な情報を送信するためのアドレス等を格納する。

ユーザ登録データ５２０は、ユーザ別に用意され、当該ユーザに係わる各種情報を格納する。例えば、ログインするために必要なユーザアカウント５２２とパスワード５２３を格納する。また、ログイン履歴データ５２４と、フレンドリスト５２５と、プッシュ通知用アドレス５２６とを格納する。

ログイン履歴データ５２４は、ログイン、ログアウトの日時等の履歴である。
フレンドリスト５２５は、フレンドとして登録されている他ユーザに係る情報を格納する。例えば、図７に示すようにように、フレンドユーザのユーザアカウント５２６と、友好度５２７と、チャット履歴データ５２８とを対応づけて格納する。

プレイデータ５７０は、ユーザ（すなわちプレーヤ）毎に用意され、当該ゲームの進行状況を記述する各種データを格納する。
例えば図８に示すように、ユーザアカウント５７１と、現有の行動ポイントの値を格納する行動ポイント５７２と、プレイ位置座標５７３と、プレイ履歴データ５７４とを格納する。

プレイ位置座標５７３は、ユーザ端末１５００で取得された最新の位置座標である。プレイ履歴データ５７４は、プレイ開始日時又はプレイ終了日時と、その時ユーザ端末１５００から取得したプレイ位置座標とのセットを所定期間分格納する。

また、プレイデータ５７０は、プレーヤキャラクタに関する情報として、キャラクタの属性５７５（例えば、水属性、火属性、土属性、風属性の何れか）と、職業５７６と、ゲーム成績等に応じて自動的に付与されるレベル５７７と、所持アイテムリスト５７８と、ゲーム世界で使用できるアイテムを購入するための仮想マネー残高５７９と、能力パラメータ値テーブル５８０と、を格納する。勿論、その他のタイマー値や、各種フラグなどのゲーム進行制御に必要な各種情報を格納することができる。

図６に戻り、イベント予約データ５９０は、予約イベントでイベント本体の発動を予約する操作入力があると生成される。本実施形態では、予約設定主ユーザアカウント５９１と、予約イベントＩＤ５９２と、プレイ予約日時５９３と、通知先ユーザのユーザアカウントを登録した通知先ユーザリスト５９４と、を含む。予約イベントＩＤ５９２を元にゲーム実行用データ５１１の予約制イベント設定データ５１２を参照すると、対応するイベント本体を実行させるためのデータを読み出すことが可能となる。

特典付与予約データ６００は、プレイ予約日時の通知先となったフレンドユーザが許容時間範囲内でゲームプレイしていることが検出された場合に付与される特典の予約情報である。例えば、付与先ユーザアカウント６０１と、特典内容を定義する特典内容６０２とを対応づけて格納する。当該予約データは、プレイ予約日時の通知先となったフレンドユーザが許容時間範囲内でゲームプレイしていることが検出されると生成・登録され、許容時間範囲が終了すると実行に移され、特典が付与される。

［処理の流れの説明］
次に、ゲーム進行制御に係る処理の流れについて説明する。
図９は、本実施形態におけるゲーム内予約に係る処理の流れを説明するためのフローチャートである。ゲーム管理サーバ制御部２３０は、ユーザ端末１５００からゲーム開始リクエストを受信すると（ステップＳ２のＹＥＳ）、当該ユーザ端末１５００をプレイ中ユーザ端末リスト５１３に登録する（ステップＳ４）。

そして、ユーザ端末１５００のユーザのプレイ履歴データ５７４を更新する（ステップＳ６）。この際、ユーザ端末１５００から最新の位置情報を取得し、プレイ履歴データ５７４に格納する。また、もしリクエストしてきたユーザ端末１５００のユーザのユーザアカウントと一致するプレイデータ５７０が無ければ、ゲーム管理サーバ制御部２３０は新規に当該ユーザのプレイデータ５７０を生成することとする。

次に、ゲーム管理サーバ制御部２３０は、プレイ中のゲーム毎にループＡを実行する（ステップＳ２０〜Ｓ１０６）。
ループＡでは、先ず操作入力に応じたゲーム進行制御を行う（ステップＳ２２）。上述のように、本実施形態は行動ポイント制なので、プレーヤキャラクタの行動にともない行動ポイント５７２の減算・消費が行われる。その一方で、所定単位時間の経過毎に行動ポイント５７２に所定量を加算し自動回復させる。尚、ゲーム進行制御では、アイテムを購入する操作があればアイテム購入額だけ仮想マネー残高５７９を減算・更新し、アイテムを取得したり消費すれば所持アイテムリスト５７８を更新し、ゲームの成績によってはレベル５７７や能力パラメータ値テーブル５８０の各パラメータ値を更新する。

次に、ゲーム管理サーバ制御部２３０は、ゲーム進行状況が予約イベントの発動条件に合致するかを判定し、合致すれば当該予約イベントを発生させる（図４（１）参照）。
そして、予約イベントが発生し（ステップＳ２４のＹＥＳ）、且つイベント本体の予約を許可する許可操作を検出したならば（ステップＳ２６のＹＥＳ）、ゲーム管理サーバ制御部２３０は、新規にイベント予約データ５９０（図６参照）を生成し（ステップＳ２８）、プレイ予約日時の設定に係る処理を実行する（ステップＳ３０）。
すなわち、イベント予約データ５９０の予約設定主ユーザアカウント５９１には、ループＡの処理対象のゲームプレイをしているユーザのユーザアカウントを格納し、予約イベントＩＤには発生した予約イベントＩＤを格納する。そして、プレイ予約日時設定ウィンドウ１０の表示並びに当該ウィンドウにおける操作入力に応じてプレイ予約日時５９３を設定する。

次いで、ゲーム管理サーバ制御部２３０は、プレイ予約日時通知処理を実行する（ステップＳ６０）。
図１０は、本実施形態におけるプレイ予約日時通知処理の流れを説明するためのフローチャートである。同処理において、ゲーム管理サーバ制御部２３０は、ループＡの処理対象のゲームをプレイしているユーザのフレンドリスト５２５（図６、図７参照）から通知先候補とするフレンドユーザを抽出する（ステップＳ６２）。本実施形態では、同じゲームをプレイしているフレンドユーザを抽出するが、プレイ位置が同じ地域に該当するフレンドユーザ、同年齢のフレンドユーザなどを適宜抽出する構成としても良い。

次に、ゲーム管理サーバ制御部２３０は、抽出したフレンドユーザを対象としてお勧め順位設定処理を実行する（ステップＳ６４）。
図１１は、本実施形態におけるお勧め順位設定処理の流れを説明するためのフローチャートである。同処理において、ゲーム管理サーバ制御部２３０は抽出したフレンドユーザ毎にループＥの処理を実行する（ステップＳ７０〜Ｓ８０）。ループＥでは、処理対象とするフレンドユーザのお勧め順判定ポイントを生成し、その値を「０」に初期化する（ステップＳ７２）。

次に、フレンドリスト５２５を参照して、処理対象フレンドユーザの友好度５２７（図７参照）に応じてお勧め順判定ポイントを加算する（ステップＳ７４）。

次いで、処理対象フレンドユーザのプレーヤキャラクタの属性５７５と、ループＡ処理対象のゲームをプレイしているユーザのプレーヤキャラクタの属性５７５（図８参照）の相対関係に応じてお勧め順判定ポイントを加算する（ステップＳ７６）。

更に、処理対象フレンドユーザのプレイ予約日時における行動ポイントの予測値を算出し、当該予測値に応じてお勧め順判定ポイントを加算し（ステップＳ７８）、ループＥを終了する（ステップＳ８０）。

そして、抽出したフレンドユーザ全てについてループＥを実行したならば、ゲーム管理サーバ制御部２３０は、お勧め順判定ポイントの上位順に、抽出したフレンドユーザごとのお勧め順位を決定し（ステップＳ８２）、お勧め順位設定処理を終了する。

図１０のフローチャートに戻って、ゲーム管理サーバ制御部２３０は、ステップＳ６２で抽出したフレンドユーザの中から、ステップＳ６４で設定されたお勧め順位に従って上位順に通知先とするフレンドユーザを自動仮設定する（ステップＳ９０）。自動選択されたフレンドユーザのユーザアカウントは、イベント予約データ５９０の通知先ユーザリスト５９４（図６参照）に格納される。

次いで、ゲーム管理サーバ制御部２３０は、通知先選択ウィンドウ１２（図４参照）を表示させる（ステップＳ９２）。選択候補表示部１４では、お勧め順位に従った順で抽出されたフレンドユーザのユーザアカウントを表示させ、通知先表示部１６には、自動仮設定したフレンドユーザのユーザアカウントを表示させる。

そして、通知先の入れ替え選択操作に応じて通知先とするフレンドユーザを、選択候補表示部１４で選択操作されたフレンドユーザに再設定する（ステップＳ９４）。
そして、ゲーム管理サーバ制御部２３０は、予約日時通知雛形データ５６８を参照して、通知先に決定されたフレンドユーザへ、プレイ予約日時５９３を通知し（ステップＳ９４６、プレイ予約日時通知処理を終了する。

図９のフローチャートに戻って、ゲーム管理サーバ制御部２３０は次に、ループＡの処理対象のユーザが予約設定主となっているイベント予約データ５９０が登録されている場合（ステップＳ１００のＹＥＳ）、現在日時がプレイ予約日時５９３を起点として算出される許容時間範囲内に有るかを判定する（ステップＳ１０２）。もし、許容時間範囲内であれば（ステップＳ１０２のＹＥＳ）、予約制イベント設定データ５１２を参照して、予約イベントＩＤ５９２に対応するイベント本体を発動させ（ステップＳ１０４）、ループＡを終了する（ステップＳ１０６）。
そしてプレイ中のゲーム全てについてループＡを終了したならば、ゲーム管理サーバ制御部２３０は次に特典付与予約設定処理を実行する（ステップＳ１０８）。

図１２は、本実施形態における特典付与予約設定処理の流れを説明するためのフローチャートである。同処理において、ゲーム管理サーバ制御部２３０はイベント予約データ５９０毎にループＢを実行する（ステップＳ１２０〜Ｓ１５０）。

ループＢでは先ず、処理対象とするイベント予約データ５９０のプレイ予約日時５９３を起点とする許容時間範囲をすでに超えている場合には（ステップＳ１２２のＹＥＳ）、作業用データとして無登録状態の通知応答ユーザリストを生成し（ステップＳ１２４）、ループＢの処理対象とされるイベント予約データ５９０の通知先ユーザリスト５９４のユーザ毎にループＣを実行する（ステップＳ１２６〜Ｓ１３２）。

ループＣでは、ゲーム管理サーバ制御部２３０は、ループＢの処理対象のユーザのプレイ履歴データ５７４を参照して、許容時間範囲内にプレイした履歴があるかを判定する（ステップＳ１２８）。
もし、許容時間範囲内でプレイしていれば（ステップＳ１２８のＹＥＳ）、ゲーム管理サーバ制御部２３０は、ループＣの処理対象のユーザをステップＳ１２４で生成した通知応答ユーザリストに追加し（ステップＳ１３０）、ループＣを終了する（ステップＳ１３２）。

ループＢの処理対象とされるイベント予約データ５９０の通知先ユーザリスト５９４のユーザ全てについてループＣを実行したならば、ゲーム管理サーバ制御部２３０は次に、先の通知応答ユーザリストの登録数（または通知先ユーザリスト５９４の登録数に対する通知応答ユーザリストの登録数の割合）に応じて、特典内容を決定する（ステップＳ１４０）。そして、決定した特典内容を、通知応答ユーザリストに登録されているユーザへ付与するための特典付与予約データ６００を設定する（ステップＳ１４２）。

更に、ループＢの処理対象となっているイベント予約データ５９０の予約設定主ユーザのプレイ履歴データ５７４を参照して、許容時間範囲内にプレイした履歴があるかを判定し（ステップＳ１４４）、プレイした履歴があれば約束を守ったとみなし（ステップＳ１４４のＹＥＳ）、ゲーム管理サーバ制御部２３０は当該予約設定主のユーザへ特典を付与する特典付与予約データ６００を設定する（ステップＳ１４６）。

次いで、ゲーム管理サーバ制御部２３０は、ループＢの処理対象とされるイベント予約データ５９０を消去して（ステップＳ１４８）、ループＢを終了する（ステップＳ１５０）。そして、全てのイベント予約データ５９０についてループＢを実行したならば、ゲーム管理サーバ制御部２３０は特典付与予約設定処理を終了する

図９のフローチャートに戻って、ゲーム管理サーバ制御部２３０は次に特典付与処理を実行する（ステップＳ１５２）。

図１３は、本実施形態における特典付与処理の流れを説明するためのフローチャートである。同処理において、ゲーム管理サーバ制御部２３０は特典付与予約データ６００毎にループＤを実行する（ステップＳ１７０〜Ｓ１８０）。ループＤでは、先ず処理対象とされる特典付与予約データ６００の付与先ユーザアカウント６０１に登録されているユーザアカウントをもつユーザが、現在ゲームプレイ中であるかを判定する（ステップＳ１７２）。

もし、プレイ中であれば（ステップＳ１７２のＹＥＳ）、ゲーム管理サーバ制御部２３０は、ループＤの処理対象の特典付与予約データ６００の特典内容６０２に従って、当該ユーザへ特典付与を行い（ステップＳ１７４）、当該ユーザのユーザ端末１５００のゲーム画面にて、約束を守った褒美として特典が付与された旨の通知表示をさせる（ステップＳ１７６）。
そして、ループＤの処理対象の特典付与予約データ６００を消去して（ステップＳ１７８）、ループＤを終了する（ステップＳ１８０）。
全ての特典付与予約データ６００についてループＤを実行したならば、ゲーム管理サーバ制御部２３０は特典付与処理を終了する。

図９のフローチャートに戻って、特典付与処理を終了したならば、ゲーム管理サーバ制御部２３０は、ステップＳ２に戻る。

尚、当該フローチャートには記載していないが、ゲームプレイ中に所定のゲーム終了条件を満たした場合（例えば、ゲーム終了の操作入力が有った場合、ユーザ端末１５００との通信が所定時間以上途絶した場合、ゲームのストーリの最後まで到達した場合など）には、該当するユーザ端末１５００をプレイ中ユーザ端末リスト５１３から登録抹消するとともに、該当するユーザのプレイデータ５７０のプレイ履歴データ５７４にプレイ終了日時と現在位置座標を登録するものとする。

以上、本実施形態によれば、イベント本体のプレイ予約日時を設定し、当該プレイ予約日時に基づく許容時間範囲内で、予約設定主のユーザがゲームをプレイすると、当該ユーザに特典が付与される。また、プレイ予約日時の設定の際に、予約設定主のユーザのフレンドユーザへプレイ予約日時の通知をすることが可能であり、更に通知を受けたフレンドユーザが許容時間範囲内でゲームプレイすると、そのフレンドユーザにも特典が与えられる。
結果、予約設定主のユーザと、そのフレンドユーザとの間の話題を作ることとなり、ユーザ間のコミュニケーションを活発化させることができる。

また、例えば、イベント本体を次のようにしてもよい。すなわち、イベント本体を共通の特別キャラクタを攻撃するイベントとし、異なる多数のユーザが非同期で同じ特別キャラクタに攻撃した場合、特別キャラクタへのダメージが蓄積され、所定のダメージを受けると特別キャラクタが倒されて、ダメージを与えたユーザへ特典が分配される構成とする。しかも、特別キャラクタは、一人では到底倒すことができない強敵とする。
この構成に本実施形態を適用した場合には、あるユーザが特別キャラクタの出現条件を満たし、攻撃を行うプレイ予約日時を設定し、フレンドユーザに通知することで、非同期のゲームでありながら、あたかも友人が集まり共通の敵を倒す、或いは狩りをするといったマルチプレイオンラインゲーム的なシチュエーションを実現できる。勿論、この特別キャラクタを倒せば、参加したユーザに特典が付与されるので、特典が付与されたことをきっかけに、今回の戦いをネタとしたコミュニケーションが盛り上がるのは必定である。

〔変形例〕
以上、本発明を適用した実施形態について説明したが、本発明の形態はこれに限定されるものではなく、適宜構成要素の追加・省略・変更を施すことができる。

例えば、上記実施形態では、特典付与を、予約設定主のユーザと、予約日時通知先となったフレンドユーザの何れにも行う構成としたが、特典付与対象を何れか一方、或いは予約設定主のユーザ及び予約日時通知先のユーザ誰か一人に限定する構成としても良い。その場合、適宜ステップＳ１４２を省略したり、ステップＳ１４２の対象を所定数抽選する構成とすると良い（図１２参照）。

また、特典付与の条件に関しても、上記実施形態では予約設定主のユーザと予約日時通知先となったフレンドユーザそれぞれを個別に判定し、条件を満たせば（所定時間範囲内にゲームプレイすれば）特典を付与する構成としているが、予約設定主のユーザと予約日時通知先となったフレンドユーザの双方が条件を満たさないと特典が付与されない構成も可能である。その場合、ステップＳ１４４をステップＳ１２２の次に実行し、肯定判定の場合に、ステップＳ１２４に進む処理の流れとすれば良い。

また、上記実施形態では、プレイ予約日時の通知先をユーザが選択する構成としたが、ゲーム管理サーバ制御部２３０が自動的に選択設定する構成としても良い。

また、上記実施形態では、予約を守ったと見なす要件を、プレイ予約日時に基づく許容時間範囲内でのゲームプレイとしたが、それに加えてプレイする場所すなわちプレイ指定位置をその要件に加えることもできる。更には、プレイ予約日時をユーザが設定するのではなく、自動設定する構成とすることもできる。

具体的には、例えばサーバ記憶部５００ｓｖに、図１４に示すようなプレイ指定位置候補リスト６３０を記憶させておく。プレイ指定位置候補リスト６３０は、プレイ地域６３２と、プレイ指定位置候補６３４とを対応づけて格納する。プレイ地域６３２は、ユーザのユーザ端末１５００で取得される位置情報から判定される地域の区分であって、実際には対応する地域と見なすための位置情報の範囲情報が定義される。例えば、図の「東京都内」の場合、東京都内と見なすＧＰＳ座標の範囲が定義されており、ユーザ端末１５００で取得される位置情報と比較し、該当すればプレイ位置は「東京都内」と判定される。

プレイ指定位置候補６３４は、予約を守ったと見なす要件に含まれる位置情報のの範囲情報を定義する。図中、地名で表示している部分（例えば、東京タワー、雷門）は、実際にはそれら地名の位置にいると見なすＧＰＳ座標の範囲が定義されているものとする。プレイ指定位置候補６３４が、複数ならば何れか又は所定数がランダム抽選され、一つならばそれが選択される。

そして、上記実施形態のステップＳ３０（図９参照）に代えて、図１５に示すプレイ予約日時設定処理を実行する。
同処理において、ゲーム管理サーバ制御部２３０は先ず、ループＡの処理対象のユーザの行動ポイント５７２（図８参照）が１００％回復する主予測日時を算出し（ステップＳ４０）、次いで当該処理対象ユーザのフレンドユーザの行動ポイント５７２が１００％回復されるフレンド別予測日時を算出する（ステップＳ４２）。

そして、ゲーム管理サーバ制御部２３０は、フレンド別予測日時を時間軸でプロットして統計処理し、（ステップＳ４４）、主予測日時以降で、且つフレンド別予測日時が所定の基準数以上集中する日時をプレイ予約日時として設定する（ステップＳ４６）。

次いで、ゲーム管理サーバ制御部２３０は、 ループＡの処理対象のユーザのユーザ端末１５００から位置情報を取得する制御を行い、プレイ指定位置候補リスト６３０を参照して該当するプレイ地域６３２を判定する（ステップＳ４８）。そして、対応するプレイ指定位置候補６３４から何れか又は所定数を選択して、イベント予約データ５９０にプレイ指定位置５９５として設定する（ステップＳ５０）。

そして、特典付与予約設定処理（図１２参照）のステップＳ１２８及びステップＳ１４４では、ループＣの処理対象ユーザ、またはループＢの処理対象のイベント予約データ５９０の予約設定主ユーザが、許容時間範囲内でゲームプレイしている履歴があって、且つプレイ指定位置５９５を満たしているかを判定するものとする。

こうした構成の場合、例えば、予約イベントの予告６（図４参照）にて『私と勝負しない？プレイ予約日時にフレンドユーザを３人以上集められたら、特別なアイテムをプレゼントするよ。もし集められなかったら行動ポイントの残り全部もらうけどどうする？』といった内容を表示させる。そして、イベント本体でプレイ予約日時に規定数のフレンドユーザが許容時間範囲内で、プレイ指定位置５９５でゲームプレイした履歴があれば、所定のアイテムを予約設定主のユーザに付与するといった、ミッション形式のイベントとすることもできる。

２…ユーザ
６…予告
１０…プレイ予約日時設定ウィンドウ
１２…通知先選択ウィンドウ
１４…選択候補表示部
１６…通知先表示部
２００ｓｖ…サーバ処理部
２０２…コミュニティサービス制御部
２０４…ユーザ登録情報管理部
２０６…フレンドリスト管理部
２０７…友好度管理部
２０８…プッシュ通知制御部
２１０…ログイン処理部
２３０…ゲーム管理サーバ制御部
２３２…プレイデータ管理部
２３４…行動パラメータ管理部
２３６…イベント管理部
２３８…イベント予約設定部
２４２…通知先選択制御部
２４４…予約日時通知制御部
２４６…予約設定主ユーザプレイ判定部
２４８…予約日時通知先ユーザプレイ判定部
２５２…特典付与制御部
２５４…プレイ位置情報取得制御部
５００ｓｖ…サーバ記憶部
５０１…サーバシステムプログラム
５０３…コミュニティサービスプログラム
５０５…ゲーム管理サーバプログラム
５０９…ゲームクライアントプログラム
５１１…ゲーム実行用データ
５１２…予約制イベント設定データ
５１３…プレイ中ユーザ端末リスト
５２０…ユーザ登録データ
５２２…ユーザアカウント
５２５…フレンドリスト
５２７…友好度
５２８…チャット履歴データ
５２９…プッシュ通知用アドレス
５７０…プレイデータ
５７１…ユーザアカウント
５７２…行動ポイント
５７３…プレイ位置座標
５７４…プレイ履歴データ
５９０…イベント予約データ
５９１…予約設定主ユーザアカウント
５９２…予約イベントＩＤ
５９３…プレイ予約日時
５９４…通知先ユーザリスト
５９５…プレイ指定位置
６００…特典付与予約データ
６０１…付与先ユーザアカウント
６０２…特典内容
６３０…プレイ指定位置候補リスト
６３２…プレイ地域
６３４…プレイ指定位置候補
１１００…サーバシステム
１５００…ユーザ端末

Claims (10)

1. プレーヤ端末から送信される操作入力に従ってゲームを進行制御するサーバシステムであって、
   各プレーヤそれぞれについて、当該プレーヤに関係する関係プレーヤを記憶する関係プレーヤ記憶手段と、
   一のプレーヤの次回のプレイ予約日時を設定する予約設定手段と、
   前記一のプレーヤ及び当該一のプレーヤの関係プレーヤが、前記予約設定手段により設定された予約日時を含む所定の許容時間範囲にプレイしたか否かを判定する判定手段と、
   前記判定手段により肯定判定された場合に、前記一のプレーヤ、及び／又は、当該一のプレーヤの関係プレーヤに所与の特典を付与する特典付与手段と、
   を備えたサーバシステム。
2. 前記一のプレーヤの関係プレーヤのプレーヤ端末に、前記予約設定手段により設定された予約日時を通知する関係プレーヤ通知手段を更に備え、
   前記判定手段は、前記一のプレーヤ、及び、前記関係プレーヤ通知手段による通知先の関係プレーヤがプレイしたか否かを判定し、
   前記特典付与手段は、前記判定手段により肯定判定された場合に、前記一のプレーヤ、及び／又は、前記関係プレーヤ通知手段による通知先の関係プレーヤに所与の特典を付与する、
   請求項１に記載のサーバシステム。
3. 通知先の関係プレーヤを選択する通知先選択手段を更に備え、
   前記関係プレーヤ通知手段は、前記通知先選択手段により選択された通知先に、前記予約設定手段により設定された予約日時を通知する、
   請求項２に記載のサーバシステム。
4. 前記特典付与手段は、前記通知先の関係プレーヤのうち、前記予約日時を含む前記許容時間範囲にプレイした関係プレーヤの比率又は数に基づいて、付与する特典を変更する手段を有する、
   請求項３に記載のサーバシステム。
5. 前記ゲームにおける行動の指示操作入力がなされる毎に消費し、時間経過により回復する各プレーヤの行動パラメータを管理する行動パラメータ管理手段を更に備え、
   前記通知先選択手段は、前記一のプレーヤの関係プレーヤの行動パラメータを用いて、通知先の関係プレーヤを選択する、
   請求項３又は４に記載のサーバシステム。
6. 前記関係プレーヤ記憶手段は、当該プレーヤと当該プレーヤの関係プレーヤとの友好度を記憶する友好度記憶手段を有し、
   前記通知先選択手段は、前記一のプレーヤと当該関係プレーヤとの友好度を用いて、通知先の関係プレーヤを選択する、
   請求項３〜５の何れか一項に記載のサーバシステム。
7. 前記各プレーヤの前記ゲーム上の属性、職業、及びレベルのうちの少なくとも１つをプレイデータに含めて管理するプレイデータ管理手段を更に備え、
   前記通知先選択手段は、前記一のプレーヤのプレイデータと、関係プレーヤのプレイデータとを用いて、通知先の関係プレーヤを選択する、
   請求項３〜６の何れか一項に記載のサーバシステム。
8. 前記ゲームにおける行動の指示操作入力がなされる毎に消費し、時間経過により回復する各プレーヤの行動パラメータを管理する行動パラメータ管理手段を更に備え、
   前記予約設定手段は、前記一のプレーヤの行動パラメータに基づいて、次回のプレイ予約日時を設定する、
   請求項１〜７の何れか一項に記載のサーバシステム。
9. 前記ゲームにおける行動の指示操作入力がなされる毎に消費し、時間経過により回復する各プレーヤの行動パラメータを管理する行動パラメータ管理手段を更に備え、
   前記予約設定手段は、前記一のプレーヤの関係プレーヤの行動パラメータに基づいて、次回のプレイ予約日時を設定する、
   請求項１〜８の何れか一項に記載のサーバシステム。
10. 前記プレーヤ端末は位置取得手段を有しており、
    前記プレーヤ端末からプレイ位置の情報を受信するプレイ位置情報受信手段を更に備え、
    前記予約設定手段は、次回のプレイ予約日時及びプレイ指定地点を設定し、
    前記判定手段は、前記一のプレーヤ及び当該一のプレーヤの関係プレーヤのプレイ日時が前記予約日時を含む前記許容時間範囲であり、且つ、プレイ位置が前記プレイ指定地点を含む所定の許容圏内の場合に肯定判定する、
    請求項１〜９の何れか一項に記載のサーバシステム。

Images