特許 5749293 ゲーム制御方法、コンピュータ、ゲーム制御プログラム及び記憶媒体

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5749293

(24)【登録日】2015年5月22日

(45)【発行日】2015年7月15日

(54)【発明の名称】ゲーム制御方法、コンピュータ、ゲーム制御プログラム及び記憶媒体

(51)【国際特許分類】

   A63F 13/79 20140101AFI20150625BHJP

   A63F 13/69 20140101ALI20150625BHJP

   A63F 13/847 20140101ALI20150625BHJP

   A63F 13/35 20140101ALI20150625BHJP

【ＦＩ】

   A63F13/79 500

   A63F13/69

   A63F13/847

   A63F13/35

【請求項の数】10

【全頁数】27

(21)【出願番号】特願2013-94459(P2013-94459)

(22)【出願日】2013年4月26日

(65)【公開番号】特開2014-213080(P2014-213080A)

(43)【公開日】2014年11月17日

【審査請求日】2013年4月26日

(73)【特許権者】

【識別番号】504437801

【氏名又は名称】グリー株式会社

(74)【代理人】

【識別番号】100108855

【弁理士】

【氏名又は名称】蔵田 昌俊

(74)【代理人】

【識別番号】100109830

【弁理士】

【氏名又は名称】福原 淑弘

(74)【代理人】

【識別番号】100088683

【弁理士】

【氏名又は名称】中村 誠

(74)【代理人】

【識別番号】100103034

【弁理士】

【氏名又は名称】野河 信久

(74)【代理人】

【識別番号】100095441

【弁理士】

【氏名又は名称】白根 俊郎

(74)【代理人】

【識別番号】100075672

【弁理士】

【氏名又は名称】峰 隆司

(74)【代理人】

【識別番号】100119976

【弁理士】

【氏名又は名称】幸長 保次郎

(74)【代理人】

【識別番号】100153051

【弁理士】

【氏名又は名称】河野 直樹

(74)【代理人】

【識別番号】100140176

【弁理士】

【氏名又は名称】砂川 克

(74)【代理人】

【識別番号】100158805

【弁理士】

【氏名又は名称】井関 守三

(74)【代理人】

【識別番号】100172580

【弁理士】

【氏名又は名称】赤穂 隆雄

(74)【代理人】

【識別番号】100179062

【弁理士】

【氏名又は名称】井上 正

(74)【代理人】

【識別番号】100124394

【弁理士】

【氏名又は名称】佐藤 立志

(74)【代理人】

【識別番号】100112807

【弁理士】

【氏名又は名称】岡田 貴志

(74)【代理人】

【識別番号】100111073

【弁理士】

【氏名又は名称】堀内 美保子

(74)【代理人】

【識別番号】100134290

【弁理士】

【氏名又は名称】竹内 将訓

(72)【発明者】

【氏名】宇佐美 亮

【審査官】 坪内 優佳

(56)【参考文献】

【文献】 特許第４１２５７６４（ＪＰ，Ｂ２）

【文献】 特開２０１０−０４２０８３（ＪＰ，Ａ）

【文献】 再公表特許第９９／０３８５９０（ＪＰ，Ａ１）

【文献】 特開２０１２−２５４３６６（ＪＰ，Ａ）

【文献】 特開２０１３−３４８１１（ＪＰ，Ａ）

【文献】 真・戦国バスター，電撃ゲームアプリ Vol.9，株式会社アスキー・メディアワークス，２０１３年 ４月１３日，p.10-13

【文献】 みんなと 放課後ソウルハンターズ，月刊アプリスタイル，株式会社イースト・プレス，２０１２年１２月２８日，第１巻／第１号，p.072-073

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ａ６３Ｆ １３／００−１３／９８

Ａ６３Ｆ ９／２４

(57)【特許請求の範囲】

【請求項1】

ソーシャルネットワーク上で１ユーザと関連のある他ユーザ間のレベル差と所定の希少度を有する特典データとを関連付けて記憶した記憶手段及び処理装置を備え、前記各ユーザが操作する第１及び第２の各携帯端末に通信可能なコンピュータに用いられ、前記第１の各携帯端末が用いる第１キャラクタが敵とバトル中に、前記第１の各携帯端末のうちのいずれかの第１の携帯端末から救援要請が出された場合、前記第２の各携帯端末のうちのいずれかの第２の携帯端末の救援機能がオン状態のときに前記いずれかの第２の携帯端末が用いる第２キャラクタが前記第１キャラクタを救援可能なバトルゲームを前記第１の各携帯端末に実行させるためのゲーム制御方法であって、
前記処理装置が、前記いずれかの第１の携帯端末のユーザの操作により、前記バトル中に当該いずれかの第１の携帯端末から前記救援要請を受けると、当該救援要請を前記第２の各携帯端末に送信する第１救援要請送信工程と、
前記処理装置が、前記送信した救援要請に対する応答がいずれもオフ状態を示すとき、前記いずれかの第１の携帯端末のユーザのレベルと、前記第２の各携帯端末の各ユーザのレベルとの差を個別に算出し、当該算出された各々の差が前記記憶手段内で該当するレベル差に関連付けられた特典データの一部を含む表示データと、前記救援要請とを前記第２の各携帯端末に送信する第２救援要請送信工程と、
前記処理装置が、前記第１救援要請送信工程又は前記第２救援要請送信工程により前記救援要請を送信した後、前記いずれかの第２の携帯端末から前記オン状態を示す応答を受信する応答受信工程と
を備えたゲーム制御方法。

【請求項2】

請求項１に記載のゲーム制御方法において、
前記処理装置が、前記敵が負けた場合に、前記算出された差が前記記憶手段内で該当するレベル差に関連付けられた特典データを前記いずれかの第２の携帯端末に送信する特典データ送信工程を備えたゲーム制御方法。

【請求項3】

請求項１又は請求項２に記載のゲーム制御方法において、
前記特典データの一部が前記特典データの全体に占める割合は、前記バトル中に変動する前記敵の体力値とは負の相関関係を有するゲーム制御方法。

【請求項4】

請求項１乃至請求項３のいずれか１項に記載のゲーム制御方法において、
前記特典データは、互いに異なる希少度をもつ複数の特典に関する情報からなり、
前記特典データの一部は、前記希少度の低い順に表示されるように前記表示データに含まれるゲーム制御方法。

【請求項5】

請求項１乃至請求項４のいずれか１項に記載のゲーム制御方法において、
前記記憶手段は、前記各ユーザのレベルの差と、所定の希少度をもつ特典データ及び特典データ交換ポイントとを関連付けて記憶しており、
前記処理装置が、前記いずれかの第１の携帯端末のユーザのレベルと、前記いずれかの第２の携帯端末のユーザのレベルとの差を算出し、当該算出された差が前記記憶手段内で該当するレベル差に関連付けられた特典データ交換ポイントを前記応答受信工程の後に、前記いずれかの第２の携帯端末に送信する交換ポイント送信工程を備えたゲーム制御方法。

【請求項6】

請求項５に記載のゲーム制御方法において、
前記特典データ交換ポイントは、累積した値に応じて任意の特典と交換可能なポイントであるゲーム制御方法。

【請求項7】

請求項１乃至請求項６のいずれか１項に記載のゲーム制御方法において、
前記バトルゲームの実行中、前記コンピュータと、前記第１及び第２の各携帯端末との間の通信にはウェブソケット通信を用いるゲーム制御方法。

【請求項8】

ソーシャルネットワーク上で１ユーザと関連のある他ユーザとの各ユーザが操作する第１及び第２の各携帯端末に通信可能なコンピュータであって、前記第１の各携帯端末が用いる第１キャラクタが敵とバトル中に、当該第１の各携帯端末のうちのいずれかの第１の携帯端末から救援要請が出された場合、前記第２の各携帯端末のうちのいずれかの第２の携帯端末の救援機能がオン状態のときに前記いずれかの第２の携帯端末が用いる第２キャラクタが前記第１キャラクタを救援可能なバトルゲームを前記第１の各携帯端末に実行させるための前記コンピュータであって、
前記各ユーザ間のレベル差と所定の希少度を有する特典データとを関連付けて記憶した記憶手段と、
前記いずれかの第１の携帯端末のユーザの操作により、前記バトル中に当該いずれかの第１の携帯端末から前記救援要請を受けると、当該救援要請を前記第２の各携帯端末に送信する第１救援要請送信手段と、
前記送信した救援要請に対する応答がいずれもオフ状態を示すとき、前記いずれかの第１の携帯端末のユーザのレベルと、前記第２の各携帯端末の各ユーザのレベルとの差を個別に算出し、当該算出された各々の差が前記記憶手段内で該当するレベル差に関連付けられた特典データの一部を含む表示データと、前記救援要請とを前記第２の各携帯端末に送信する第２救援要請送信手段と、
前記第１救援要請送信手段又は前記第２救援要請送信手段により前記救援要請を送信した後、前記いずれかの第２の携帯端末から前記オン状態を示す応答を受信する応答受信手段と
を備えたコンピュータ。

【請求項9】

処理装置及び記憶手段を備え、ソーシャルネットワーク上で１ユーザと関連のある他ユーザとの各ユーザが操作する第１及び第２の各携帯端末に通信可能なコンピュータであって、前記第１の各携帯端末が用いる第１キャラクタが敵とバトル中に、当該第１の各携帯端末のうちのいずれかの第１の携帯端末から救援要請が出された場合、前記第２の各携帯端末のうちのいずれかの第２の携帯端末の救援機能がオン状態のときに前記いずれかの第２の携帯端末が用いる第２キャラクタが前記第１キャラクタを救援可能なバトルゲームを前記第１の各携帯端末に実行させるための前記コンピュータに用いられるゲーム制御プログラムであって、
前記コンピュータの前記処理装置を、
前記各ユーザ間のレベル差と所定の希少度を有する特典データとを関連付けて前記記憶手段に設定する設定手段、
前記いずれかの第１の携帯端末のユーザの操作により、前記バトル中に当該いずれかの第１の携帯端末から前記救援要請を受けると、当該救援要請を前記第２の各携帯端末に送信する第１救援要請送信手段、
前記送信した救援要請に対する応答がいずれもオフ状態を示すとき、前記いずれかの第１の携帯端末のユーザのレベルと、前記第２の各携帯端末の各ユーザのレベルとの差を個別に算出し、当該算出された各々の差が前記記憶手段内で該当するレベル差に関連付けられた特典データの一部を含む表示データと、前記救援要請とを前記第２の各携帯端末に送信する第２救援要請送信手段、
前記第１救援要請送信手段又は前記第２救援要請送信手段により前記救援要請を送信した後、前記いずれかの第２の携帯端末から前記オン状態を示す応答を受信する応答受信手段、
として機能させるためのゲーム制御プログラム。

【請求項10】

請求項９に記載のゲーム制御プログラムを記憶したコンピュータ読み取り可能な記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ゲーム制御方法、コンピュータ、ゲーム制御プログラム及び記憶媒体に関する。

【背景技術】

【0002】

近年、ゲーム業界では、複数のユーザが参加可能なソーシャルアプリケーションを用いたゲームが普及してきている。この種のソーシャルアプリケーションは、端末にダウンロードされ、当該端末にインストールされて利用されるネイティブアプリケーションと、ウェブサーバ上で動作し、端末のウェブブラウザに利用されるウェブアプリケーションとに大別できる。

【0003】

ネイティブアプリケーションは、スマートフォンのiPhone（登録商標）端末やAndroid（登録商標）端末といった端末のＯＳに依存するアプリケーションである。例えば、サーバ装置は、Objective-Cを搭載したiPhoneアプリケーション、又はJava（登録商標）を搭載したAndroidアプリケーション等のネイティブアプリケーションをプラットフォームから各端末に配信している。ユーザは、プラットフォームから端末に配信されたネイティブアプリケーション（例：ＲＰＧ（role playing game）、バトル、恋愛等のゲームを含む）を楽しんでいる。

【0004】

但し、ネイティブアプリケーションは、iPhone端末に対応したプログラミング言語「Objective-C」と、Android端末に対応したプログラミング言語「Java」との２種類で開発する必要がある。このため、ネイティブアプリケーションは、端末のプラットフォーム特有の言語を使ったコーディング処理を介した後に、公式のマーケットプレイスを通して公開する必要がある。

【0005】

一方、ウェブアプリケーションは、両プラットフォームに向けてＨＴＭＬ５（Hyper Text Markup Language 5）、JavaScript（登録商標）、ＣＳＳ３（Cascading Style Sheets 3）等の言語をベースにしたクロス開発が可能であり、公開に当たって公式のマーケットプレイスを通す必要がない。また、ウェブアプリケーションは、端末のＯＳに依存しない。

【0006】

ここで、JavaScriptとは、オブジェクト指向スクリプト言語である。主にウェブブラウザなどのクライアントサイドで実装され、動的なウェブサイトの構築や、ＲＩＡ（rich Internet application）などの高度なユーザインタフェースの開発に用いられる。JavaScriptはプロトタイプベースのオブジェクト指向プログラミング言語である。

【0007】

JavaScriptは、多くの場合、Ｃ言語に似た手続き型言語のようなスタイルで書かれるが、第一級関数をサポートしている（関数を第一級オブジェクトとして扱える）など、関数型言語の性質も持ち合わせるように設計されている。JavaScriptは、そのような柔軟な設計から、いくつかのアプリケーションではマクロ言語としても採用されている。また、マークアップ言語（例：ＨＴＭＬ（hypertext markup language）、ＰＨＰ（PHP: Hypertext Preprocessor））での通信方式は、リクエスト＆レスポンス方式を採用している。

【0008】

リクエスト＆レスポンス方式では、ユーザによるクライアント装置の操作に応じて、クライアント装置からサーバ装置にリクエストが送信され、サーバ装置からクライアント端末にレスポンスが返信される。また、リクエスト＆レスポンス方式では、サービスに応じてシステムを動的に形成する際に、サービス実行に必要な機能群を待機させ、状況に応じて機能群を選択してサービスを実行する技術が知られている（例えば、特許文献１参照。）。

【0009】

図２１はリクエスト＆レスポンス方式を用いたバトルゲームを提供するゲームシステムの構成を示す模式図である。この種のバトルゲームとしては、携帯端末のユーザの操作により敵とのバトルを行うゲームであればよく、ここでは、ＲＰＧ内で生じるイベントの一つとして、敵であるレイドボスとのバトルを行うレイドバトルゲームを例に挙げて述べる。このレイドバトルゲームでは、通常のボス（boss）よりも強いレイドボス（raid boss）をサーバ装置Ｓｖが仮想空間に出現させる。なお、「強い」とは、例えば、ＨＰ（体力）が高いことや、攻撃によるダメージを受けにくいことを意味する。第１〜第３ユーザは、iPhone端末又はAndroid端末といった第１〜第３クライアント装置ＣＬ１〜ＣＬ３のタッチパネルをタップする等の操作により、このレイドボスとバトル（battle）する。例えば、制限時間内にレイドボスを退治できた場合にはユーザの勝ちであり、所定のインセンティブがユーザに与えられる。他の場合にはユーザの負けであり、所定のインセンティブが与えられない。

【0010】

具体的なバトルにおいて、サーバ装置Ｓｖは、バトル開始時から制限時間までの間、経過時間を計測する。各クライアント装置ＣＬ１〜ＣＬ３は、各ユーザの操作に応じたリクエストをサーバ装置Ｓｖに送信する。サーバ装置Ｓｖは、リクエストに応じてレイドボスのＨＰを減少させる処理やレイドボスが防御する処理などを実行し、処理結果をレスポンスとして各クライアント装置ＣＬ１〜ＣＬ３に返信する。

【0011】

この種のレイドバトルゲームでは、レイドボスが強いという設定のため、各クライアント装置ＣＬ１〜ＣＬ３の操作によって、レイドボスに大きなダメージを与えることが困難となっている。とはいえ、レイドボスが強すぎてユーザがほぼ負けるゲームは、ユーザの支持を得られない。一般にレイドバトルゲームは、バトルに参加するユーザが多いほど、レイドボスを倒しやすい傾向がある。そのため、例えば、レイドバトルゲームに多数のユーザを参加させ、これら多数のユーザが多数のクライアント装置ＣＬ１〜ＣＬ３、…のタッチパネルを連続的にタップする等の連携攻撃を表す操作を実行し、多数のユーザの操作に応じた大量のリクエストをサーバ装置Ｓｖに送信すればよい。

【0012】

しかしながら、多数のクライアント装置ＣＬ１〜ＣＬ３、…から大量のリクエストがサーバ装置Ｓｖに送信されると、サーバ装置Ｓｖに著しく処理負荷がかかる。このため、リクエスト＆レスポンス方式では、サーバ装置Ｓｖと接続できるクライアント装置ＣＬ１〜ＣＬ２の数を制限し、他のクライアント装置ＣＬ３、…を強制的にロックする通信方式を用いている。

【0013】

すなわち、リクエスト＆レスポンス方式では、サーバ装置Ｓｖに著しく処理負荷がかかるために、多数のユーザがバトルに参加可能なレイドバトルゲームの実現が困難となっている。

【先行技術文献】

【特許文献】

【0014】

【特許文献1】特開２００４−７０８４５号公報（段落００１５−００１７、要約書）

【発明の概要】

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

【0015】

以上説明したように、リクエスト＆レスポンス方式では、多数のユーザがバトルに参加可能なレイドバトルゲームの実現が困難であるという不都合がある。また、リクエスト＆レスポンス方式では、ロックされたクライアント装置ＣＬ３は、サーバ装置Ｓｖからロックが解除された後でなければ、正常な処理を実行できないという不都合もある。

【0016】

さらに、リクエスト＆レスポンス方式では、サーバ装置Ｓｖとクライアント装置ＣＬ１〜ＣＬ３間でマークアップ言語を送受信する場合、サーバ装置Ｓｖとクライアント装置ＣＬ１〜ＣＬ３間で複数ページに渡るヘッダ情報を送受信する必要がある。これにより、通信毎にヘッダ情報がサーバ装置Ｓｖに蓄積されるため、サーバ装置Ｓｖと接続できるクライアント装置ＣＬ１〜ＣＬ２の数が制限されている。

【0017】

また、以上のようなリクエスト＆レスポンス方式を用いる場合、本発明者の検討によれば、バトルに参加しているユーザから救援を求められた際には、当該ユーザを救援するために、ユーザの友達が途中からバトルに参加できることが望ましい。しかしながら、バトル途中からユーザの友達が参加可能なバトルゲームは、前述同様に、実現が困難となっている。

【0018】

本発明は上記実情を考慮してなされたもので、クライアント装置の数を制限せずに、複数のクライアント装置をウェブサーバ装置に接続でき、バトル途中からユーザの友達が参加可能なバトルゲームを実現し得るゲーム制御方法、コンピュータ、ゲーム制御プログラム及び記憶媒体を提供することを目的とする。

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

【0019】

本発明の一つの局面は、ソーシャルネットワーク上で友達関係にある各ユーザのレベルの差分の範囲と、前記差分の大きさに応じて高いレア度をもつ特典データとを関連付けて記憶した記憶手段及び処理装置を備え、前記各ユーザが操作する第１及び第２の各携帯端末にウェブソケット通信可能なウェブサーバ装置に用いられ、前記第１の各携帯端末が用いる第１キャラクタが敵とバトル中に、前記第１の各携帯端末のうちのいずれかの第１の携帯端末から救援要請が出された場合、前記第２の各携帯端末のうちのいずれかの第２の携帯端末の救援機能がオン状態のときに第２キャラクタが前記第１キャラクタを救援可能なバトルゲームを前記第１の各携帯端末に実行させるためのゲーム制御方法であって、前記処理装置が、前記いずれかの第１の携帯端末のユーザの操作により、前記バトル中に当該いずれかの第１の携帯端末から前記救援要請を受けると、当該救援要請を前記第２の各携帯端末に送信する第１救援要請送信工程と、前記処理装置が、前記送信した救援要請に対する応答がいずれもオフ状態を示すとき、前記いずれかの第１の携帯端末のユーザのレベルと、前記第２の各携帯端末の各ユーザのレベルとの差分を個別に算出し、当該算出された各々の差分が前記記憶手段内で該当する範囲に関連付けられた特典データの一部を含む表示データと、前記救援要請とを前記第２の各携帯端末に送信する第２救援要請送信工程と、前記処理装置が、前記第１救援要請送信工程又は前記第２救援要請工程により前記救援要請を送信した後、前記いずれかの第２の携帯端末から前記オン状態を示す応答を受信する応答受信工程と、前記処理装置が、前記敵が負けた場合に、前記いずれかの第１の携帯端末のユーザのレベルと、前記いずれかの第２の携帯端末のユーザのレベルとの差分を算出し、当該算出された差分が前記記憶手段内で該当する範囲に関連付けられた特典データを前記いずれかの第２の携帯端末に送信する特典データ送信工程と、を備え、前記特典データは、互いに異なるレア度をもつ複数のインセンティブデータからなり、前記特典データの一部は、前記レア度の低い順に前記表示データに含まれた各インセンティブデータの一部であり、前記特典データの一部が前記特典データの全体に占める割合は、前記敵の体力値とは負の相関関係を有するゲーム制御方法である。

【発明の効果】

【0020】

以上説明したように本発明によれば、クライアント装置の数を制限せずに、複数のクライアント装置をウェブサーバ装置に接続でき、バトル途中からユーザの友達が参加可能なバトルゲームを実現することができる。

【図面の簡単な説明】

【0021】

【図1】本発明の一実施形態に係るゲーム制御方法が適用されたゲームシステム及びその周辺構成の一例を示す模式図である。

【図2】同実施形態における携帯端末の用途の一例を示す模式図である。

【図3】同実施形態におけるウェブサーバ装置の機能ブロック構成の一例を示す模式図である。

【図4】同実施形態におけるソーシャルグラフ情報データベースを説明するための模式図である。

【図5】同実施形態における設定機能を説明するための模式図である。

【図6】同実施形態における特典データの一部の表示を説明するための模式図である。

【図7】同実施形態における所定のインセンティブデータの表示を説明するための模式図である。

【図8】同実施形態における携帯端末の機能ブロック構成の一例を示す模式図である。

【図9】同実施形態におけるウェブサーバ装置と携帯端末間の接続アーキテクチャの概念を示す模式図である。

【図10】同実施形態における動作を説明するためのシーケンス図である。

【図11】同実施形態における動作を説明するための模式図である。

【図12】同実施形態における動作を説明するための模式図である。

【図13】同実施形態における動作を説明するための模式図である。

【図14】同実施形態における動作を説明するための模式図である。

【図15】同実施形態における動作を説明するための模式図である。

【図16】同実施形態における動作を説明するためのフローチャートである。

【図17】同実施形態におけるレベル管理情報の例を示す模式図である。

【図18】同実施形態におけるレベル管理情報の例を示す模式図である。

【図19】同実施形態における第２キャラクタの情報の例を示す模式図である。

【図20】同実施形態における第２キャラクタ等を説明するための模式図である。

【図21】一般的なリクエスト＆レスポンス方式を用いたバトルゲームを提供するゲームシステムの構成を示す模式図である。

【発明を実施するための形態】

【0022】

以下、本発明の一実施形態について図面を用いて説明するが、その前に、本発明の概要について述べる。なお、以下に述べる概要は、「救援要請」、「レイドボス」、「フレンドポイント」及び「友達」等といった具体的な用語を用いているが、本発明は概要の説明に限定されない。例えば、「救援」は、「支援」、「応援」、「援護」、「援軍」、「助勢」、「加勢」、「助太刀」、「ヘルプ(help)」又は「お助け」等のように類似した用語に読み替えてもよく、類似した用語でなくても、他のユーザがバトル途中から味方につく意味であれば、適宜、読み替えてもよい。このように、概要に述べた用語は、類似した用語に読替え可能であり、類似した用語でなくても、同じ結果をもたらす用語であれば、他の用語に適宜、読み替えてもよい。「要請」は、「依頼」、「要求」又は「リクエスト」等と呼んでもよい。「レイドボス」は、「敵」、「ボス」又は「対戦相手」等と呼んでもよい。「フレンドポイント」は、適宜、○○ポイントといった任意の名称に読み替えてもよい。「友達」は、「知人」と読み替えてもよい。

【0023】

本発明の概要は、複数のユーザと、複数のアプリケーション（例、バトルゲームアプリケーション、ソーシャルアプリケーション）とを管理するＳＮＳ（Social Networking Service）を運営するウェブサーバ装置に対し、あるユーザが携帯端末を介してバトル中に救援要請を出すと、あるユーザの友達である他のユーザの携帯端末の救援機能により、バトル途中から当該あるユーザを救援することが可能なゲームに関する。

【0024】

ここで、救援要請を出すユーザは、ゲーム初心者等のライトユーザ（以下、ライトユーザＡともいう）を想定している。なお、ライトユーザＡは、複数のライトユーザのうちの任意のユーザである。

【0025】

救援要請に応じてバトル途中から参加するユーザは、ゲーム熟練者等のヘビーユーザ（以下、ヘビーユーザＢともいう）を想定している。なお、ヘビーユーザＢは、複数のヘビーユーザのうちの任意のユーザである。

【0026】

各ユーザＡ、Ｂは、ＳＮＳ上の友達のように、ＳＮＳで繋がりがあるユーザである。

【0027】

救援の概要は、以下の通りである。

【0028】

ウェブサーバ装置は、予め各ユーザＡ，Ｂのレベル差と、特典データと、レア度と、フレンドポイントとを関連付けて管理する。例えば、大きいレベル差と、高いレア度の特典データと、高いレア度と、大きい値のフレンドポイントとが関連付けられる。一般に、レベル差が大きいと救援するための体力値を消耗するので、大きいレベル差と、高いレア度の特典データとを関連付けた方が好ましい。同様に、大きいレベル差と、大きい値のフレンドポイントとを関連付けた方が好ましい。但し、レベル差に代えて、敵の体力値（の範囲）を用いてもよい。このとき、レベル差の場合とは異なり、敵の体力値と、レア度とは負の相関を持たせた方が、敵の体力値が小さいときに（レア度の高い特典データとフレンドポイントによって）救援を強く要請する観点から好ましい。

【0029】

ヘビーユーザＢは、予め携帯端末の救援機能のオン状態又はオフ状態を設定する。

【0030】

ライトユーザＡは、携帯端末の操作により、バトルゲームを行う。

【0031】

ライトユーザＡは、例えばバトルゲームに負けそうになると、携帯端末の操作により、救援要請を出す。

【0032】

ウェブサーバ装置は、救援要請をライトユーザＡの友達の各ヘビーユーザＢの各携帯端末に転送する。

【0033】

ヘビーユーザＢの携帯端末は、救援機能をオフ状態に設定した場合には、各ユーザＡ，Ｂのレベル差に応じた特典データのうち、一部の特典データ（以下、特典データの一部という）を含む表示データと、救援要請とをウェブサーバ装置から受けて表示し、救援機能をオン状態に変更するようにヘビーユーザＢを促す。

【0034】

特典データの一部は、敵の体力値が小さいときには特典データ全体に占める割合が大きいように表示され、敵の体力値が大きいときには特典データ全体に占める割合が小さいように表示される。また、特典データの一部は、低いレア度の順に表示される。このように、救援機能の設定がオフ状態の場合には特典データの表示を小出しにすることにより、特典データへの期待感を持たせつつ、敵の体力値が小さいときには救援機能のオン状態への変更を強く促すことができる。補足すると、全ての特典データを表示すると、特典データへの期待感が無くなる心配があるので、特典データの一部のみを表示するようにしている。また、敵の体力値が小さい場合には救援により敵に勝てる可能性が高いので、救援を強く促すようにしている。

【0035】

ヘビーユーザＢの携帯端末は、救援機能をオン状態に設定した場合には、ライトユーザＡを救援機能により救援すると共に、各ユーザＡ，Ｂのレベル差に応じたフレンドポイントがウェブサーバ装置から提供される。フレンドポイントは、バトルの勝敗とは無関係に提供される。このように、救援機能の設定がオン状態の場合にはフレンドポイントを付与することにより、救援機能をオン状態に設定することをヘビーユーザＢに促している。但し、ヘビーユーザＢは、実際にフレンドポイントを受けるまで、何ポイントのフレンドポイントが提供されるかが知らされない。また、最初から救援機能をオン状態に設定した場合には、ヘビーユーザＢの携帯端末は、特典データを表示せずにライトユーザＡを救援する。

【0036】

ヘビーユーザＢの携帯端末は、敵が負けた場合に、各ユーザＡ，Ｂのレベル差に応じた特典データがウェブサーバ装置から提供される。

【0037】

ライトユーザＡの携帯端末は、敵が負けた場合に、所定のインセンティブデータがウェブサーバ装置から提供される。なお、ウェブサーバ装置は、例えば、敵の体力値が閾値以下になったときに、敵が負けた場合に提供するインセンティブデータを当該ライトユーザＡの携帯端末に表示してもよい。この場合、ライトユーザＡの戦闘意欲を維持又は向上させることが可能となる。

【0038】

以上が本発明の概要である。続いて、本発明の一実施形態について具体的に説明する。

【0039】

＜一実施形態＞
図１は本発明の一実施形態に係るゲーム制御方法が適用されたゲームシステムの構成例を示す模式図である。インターネットなどを含むネットワーク１に対し、ウェブサーバ装置２が接続されると共に、本システムでユーザが使用するクライアント装置となる、複数、例えば８台の携帯端末４Ａ〜４Ｈが、無線ＬＡＮのアクセスポイント（ＡＰ）５、あるいは基地局６を介して接続される。これらの各装置は、それぞれハードウェア構成、又はハードウェア資源とソフトウェアとの組合せ構成のいずれでも実施可能となっている。組合せ構成のソフトウェアとしては、予めネットワーク又は記憶媒体から各装置のコンピュータにインストールされ、対応する装置の機能を実現させるためのプログラムが用いられる。

【0040】

図２に一例を示すように、各携帯端末４Ａ〜４Ｈのうち、３台の携帯端末４Ａ〜４Ｃは、バトルを行う第１の携帯端末として用いられ、５台の携帯端末４Ｄ〜４Ｈは、救援要請に応答可能な第２の携帯端末として用いられる。第２の携帯端末４Ｄ〜４Ｈは、予め救援機能をオン状態又はオフ状態に設定し、救援要請を受けると、救援機能のオン状態又はオフ状態を示す応答を返信する。

【0041】

ウェブサーバ装置２は、バトルゲームを実現するためのゲーム制御プログラム及びイベント情報を携帯端末４Ａ〜４Ｈに提供するコンピュータである。このウェブサーバ装置２は、例えばＳＮＳ（Social Networking Service）を運営する企業が、サービスの一環としてオンラインゲームのサービスを提供するべく設置するものであり、ネットワーク１に接続される。また、ウェブサーバ装置２としては、各ユーザが操作する第１及び第２の各携帯端末４Ａ〜４Ｈにウェブソケット通信可能なものを設置している。

【0042】

一方、クライアント側の携帯端末４Ａ〜４Ｈは、それぞれスマートフォン、フィーチャー・フォンなどを含み、例えば、Android又はiOSなどのＯＳ（Operating System）上で動作する携帯電話であっても良いし、さらにはノートブック型のパーソナルコンピュータ、モバイルコンピュータなどであっても良い。以下の実施形態では、説明を簡略化するために、携帯端末４Ａ〜４Ｈはいずれもタッチパネルを有するスマートフォンであるものとして説明する。

【0043】

携帯端末４Ａ〜４Ｈは、上記基地局６を介してのネットワーク１との接続に加えて、例えばＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎ規格の無線ＬＡＮ（Local Area Network）であるＷｉ−Ｆｉ（登録商標）を優先的に選択可能として、上記アクセスポイント５と相互接続が可能であるものとする。

【0044】

また、携帯端末４Ａ〜４Ｈは、例えば、近距離無線通信規格であるBluetooth（登録商標）技術により相互に無線接続が可能となっている。

【0045】

携帯端末４Ａ〜４Ｈとしては、その機種固有のハードウェア構成、採用しているＯＳ、インストールされているアプリケーション等が多岐にわたるものとし、ウェブサーバ装置２はそれら多様な携帯端末４Ａ〜４Ｈに対応した各種アプリケーションプログラムをそれぞれに配信可能であるものとする。

【0046】

上記ウェブサーバ装置２と携帯端末４Ａ〜４Ｈそれぞれの機能ブロック構成について図３乃至図８を参照して述べる。

【0047】

ウェブサーバ装置２は、図３に示すように、記憶装置２１、メモリ２２、プロセッサ２３及び通信部２４を備えている。

【0048】

記憶装置２１は、バトルゲームを実現するためのゲーム制御プログラムｐ_ｓ３等を記憶するものであり、例えば、ハードディスクドライブ（ＨＤＤ）、光ディスクドライブ、ＤＶＤ、ＭＯなどの大容量記憶装置である。この記憶装置２１には、ＯＳ（オペレーティングシステム）ｐ_ｓ０、サーバ側ＪＳ実行環境プログラムｐ_ｓ１、Ａ社フレームワークプログラムｐ_ｓ２、ソーシャルグラフ情報データベースｄ_ｓ及びゲーム制御プログラムｐ_ｓ３が記憶されている。

【0049】

ＯＳ ｐ_ｓ０、は、ウェブサーバ装置２の基本的な機能を実現するためのプログラムである。

【0050】

サーバ側ＪＳ実行環境プログラムｐ_ｓ１は、プロセッサ２３により実行され、後述するサーバ側ＪＳ実行環境Ｓ１を実現するためのプログラムである。

【0051】

Ａ社フレームワークプログラムｐ_ｓ２は、プロセッサ２３により実行され、後述するＡ社フレームワークＳ２を実現するためのプログラムである。

【0052】

ソーシャルグラフ情報データベースｄ_ｓは、図示しないソーシャルネットワーク運営プログラム（ＡＰＩ）によって用いられるデータを管理する。本実施形態においては、ゲーム（を実現するゲーム制御プログラムの識別情報）毎に、ユーザを識別するユーザ識別情報と、当該ユーザと他のユーザとの関係を示すユーザ関係情報（例、ソーシャルグラフ情報）とを関連付けて記憶装置２１に記憶している。以下、本実施形態では、ユーザ関係情報の一例としてソーシャルグラフ情報を用いた場合について説明する。

【0053】

なお、ゲーム（のゲーム制御プログラムの識別情報）毎に、ユーザ識別情報と、ソーシャルグラフ情報とを関連付けて記憶した旨が記載されているが、これに限らない。例えば、ソーシャルグラフ情報毎に、ユーザ識別情報と、ゲーム制御プログラムとを関連付けて記憶してもよい。

【0054】

ソーシャルグラフ情報データベースｐ_ｓでは、図４に示すように、各ゲーム（のゲーム制御プログラムの識別情報）毎に、ユーザＩＤ３１、ユーザ情報３２及びソーシャルグラフ情報３３が関連付けられて記憶装置２１に記憶されている。

【0055】

「ユーザＩＤ３１」は、各ゲームのゲーム制御プログラムにおいて、共通に使用される識別情報である。したがって、ユーザ識別情報が同じであれば、同一のユーザであることを示し、そのユーザ情報３２及びソーシャルグラフ情報３３は、各ゲーム（のゲーム制御プログラムの識別情報）毎に保持される。

【0056】

「ユーザ情報３２」は、ユーザ個人の属性に関する情報であり、例えば、ユーザのレベル、アイテム、コインの数、メダルの数、カードなどである。ここで、「レベル」は、例えばゲームの熟練度に応じた値であり、後述するレベルの差分の算出に用いられる。また、ユーザ情報３２にはユーザ認証情報や携帯端末識別情報を含めてもよい。あるいは、ユーザ認証情報や携帯端末識別情報は、図示しない他のデータベースで管理してもよい。

【0057】

「ソーシャルグラフ情報３３」は、ソーシャルグラフを表示する際に、検索される対象となる情報であり、他のユーザとの関係を示す情報である。例えば、他のユーザとの「親密度」、「相性」、「友達」といった情報をソーシャルグラフ情報３３としても良い。

【0058】

「親密度」は、例えば、ユーザＡと会話（チャットなど）をした回数により、ユーザ毎に定められる。「相性」は、例えば、ユーザのキャラクタの属性や、アイテムなどにより、ユーザ毎に定められる。「友達」は、ユーザＡの友達申請が承認されたユーザ、或いは相手方のユーザからの友達申請され、ユーザＡが承認した場合に「友達」となる。なお、ここで挙げた例は、あくまで一例にすぎず、他のユーザとの関係を示す情報であれば、これに限られない。例えば、相手方のユーザからの友達申請がされた後、ユーザＡが承認した場合に「友達」となると記載されているが、承認されなくても「友達」となってもよい。この場合、予めサーバー上で決められた閾値（新密度と相性の関係を示すもの）を用いてユーザ間の友達の定義が算出され、友達承認がなされる。新密度と相性の関係についてはサーバー上の計算であるので、ここでは説明を割愛する。

【0059】

ゲーム制御プログラムｐ_ｓ３は、プロセッサ２３により実行され、本発明の実施の形態に係るバトルゲームを実現するためのプログラムである。補足すると、ゲーム制御プログラムｐ_ｓ３は、ソーシャルネットワーク上で友達関係にある各ユーザのレベルの差分の範囲と、当該差分の大きさに応じて高いレア度をもつ特典データとを関連付けて記憶したメモリ（記憶手段）２２及びプロセッサ（処理装置）２３を備えたウェブサーバ装置に用いられる。このゲーム制御プログラムｐ_ｓ３は、各ユーザが操作する第１及び第２の各携帯端末４Ａ〜４Ｈのうちの第１の各携帯端末４Ａ〜４Ｃが用いる第１キャラクタが敵とバトル中に、当該第１の各携帯端末４Ａ〜４Ｃのうちのいずれかの第１の携帯端末（例、４Ａ）から救援要請が出された場合、第２の各携帯端末４Ｄ〜４Ｈのうちのいずれかの第２の携帯端末（例、４Ｄ）の救援機能がオン状態のときに第２キャラクタが当該第１キャラクタを救援可能なバトルゲームを第１の各携帯端末４Ａ〜４Ｃに実行させるためのプログラムである。第１キャラクタ及び第２キャラクタが敵に勝った場合、当該第１キャラクタに対応する第１の各携帯端末４Ａ〜４Ｃには所定のインセンティブデータがウェブサーバ装置２から送信され、当該第２キャラクタに対応する第２の携帯端末（例、４Ｄ）には、後述する特典データがウェブサーバ装置２から送信される。

【0060】

ここで、敵は、例えば、イベント情報によるアタック（攻撃）を受けるレイドボスとしてもよく、バトルゲームは、当該レイドボスとバトルを行うレイドバトルゲームとしてもよい。以下の説明では、敵がレイドボスであり、バトルゲームがレイドバトルゲームである場合を例に挙げて述べる。この場合、レイドバトルゲームは、例えば、バトルゲーム開始時から制限時間内にレイドボスを退治できるか否かで勝敗が決まる方式や、制限時間なしにレイドボスを退治できるか否かで勝敗が決まる方式のいずれでも実施可能である。バトルゲーム開始時は、レイドボス出現時としてもよい。また、「退治」とは、ＨＰ（体力）値をゼロにする方式、ダメージ値を目標値まで蓄積する方式、又は所定の弱点を攻撃する方式のいずれでも実施可能である。なお、レイドボスの設定（例、応戦する／応戦しない、ＨＰ値、ダメージ値の目標値、所定の弱点など）は、レイドバトルゲームの方式等に応じて若干変わるが、通常のボスよりも強い（＝退治しにくい）ボスであることに変わりはない。

【0061】

また、ゲーム制御プログラムｐ_ｓ３は、レイドバトルゲームの様々な方式に基づくゲーム機能の他に、以下の機能（ｆ１）〜（ｆ５）をプロセッサ２３に実現させるためのプログラムを含んでいる。

【0062】

（ｆ１） 各ユーザのレベルの差分の範囲と、当該差分の大きさに応じて高いレア度をもつ特典データとを関連付けてメモリ２２に設定する設定機能。

【0063】

なお、設定機能は、例えば、図５に一例を示すように、レベル差、特典データ、レア度及びフレンドポイントを関連付けてメモリ２２に設定してもよい。レベル差は、前述した各ユーザのレベルの差分の範囲を示している。また、特典データが差分の大きさに応じて高いレア度を有していればよいので、明示的にレア度を設定する必要はない。すなわち、特典設定データのうち、レア度は、任意の付加的事項であり、省略してもよい。また、フレンドポイント（データ交換ポイント）は、各ユーザのレベルの差分の大きさに応じて高い値を有し、累積した値に応じて任意のインセンティブデータと交換可能なポイントである。

【0064】

（ｆ２） いずれかの第１の携帯端末（例、４Ａ）のユーザの操作により、バトル中に当該いずれかの第１の携帯端末４Ａから救援要請を受けると、当該救援要請を第２の各携帯端末４Ｄ〜４Ｈに送信する第１救援要請送信機能。

【0065】

（ｆ３） 送信した救援要請に対する応答がいずれもオフ状態を示すとき、当該いずれかの第１の携帯端末４Ａのユーザのレベルと、第２の各携帯端末４Ｄ〜４Ｈの各ユーザのレベルとの差分を個別に算出し、当該算出された各々の差分がメモリ２２内で該当する範囲に関連付けられた特典データの一部を含む表示データと、救援要請とを第２の各携帯端末４Ｄ〜４Ｈに送信する第２救援要請送信機能。

【0066】

ここで、特典データは、互いに異なるレア度をもつ複数のインセンティブデータからなるデータである。インセンティブデータとしては、当該レイドバトルを含むＲＰＧ又は他のゲーム等で使用可能なデータであって、例えば、衣服や道具などのアイテム、カード及びゲーム内通貨といった任意の種類のデータが適用可能となっている。レア度は、希少価値を意味しており、例えば、売却するときの値段に正の相関がある値である（レア度が高いほど、売却時の値段が高い。）。

【0067】

特典データの一部は、レア度の高いインセンティブデータを早期に見せずに第２の携帯端末４Ｄ〜４Ｈのユーザに期待感を持たせる観点から、レア度の低い順に表示データに含まれた各インセンティブデータの一部であることが好ましい。なお、レア度の低い順に表示データに含まれることは、必須ではなく、任意の付加的事項である。

【0068】

表示データに含まれる特典データの一部が特典データの全体に占める割合は、敵の体力値（ＨＰ）が低いときには制限時間が迫っていて救援要請が切実な場合が多いことから、敵の体力値とは負の相関関係を有することが好ましい。

【0069】

例えば、敵の体力値が小さい場合（例、１０％）には、表示データに含まれる特典データの一部が特典データ全体に占める割合が大きい（例、９０％＝１００％−敵の体力値）ことが好ましい。なお、ここでは、「割合」に関する説明の便宜上、体力値の単位を％としているが、体力値の単位としては、「点」又は「ポイント」のように任意の単位が使用可能である（例えば、１００００点を１００％と定めた場合のように、任意の単位と％とは容易に換算可能である。）。また、図６に示すように、敵の体力値が大きい場合（例、７０％）には、表示データに含まれる特典データの一部が特典データ全体に占める割合（以下、特典表示割合ともいう）が小さい（例、３０％）ことが好ましい。また、特典データの一部が特典データ全体に占める割合が小さい場合（例、５％）であっても、何らかの特典データを表示したいときには、例えばデフォルトで、レア度が最低のインセンティブデータを１つだけ示すようにし、残りの９５％の特典データについては、敵の体力値と負の相関関係を有する割合で表示してもよい。なお、表示データに含まれる特典データの一部と、敵の体力値とが負の相関を持つことは、必須ではなく、任意の付加的事項である。

【0070】

また、図７に示すように、第１の各携帯端末４Ａ〜４Ｃは、特典表示割合が閾値（例、５０％）を超えたら（又は敵の体力値が閾値より低下したら）、敵が負けた場合に第１の各携帯端末４Ａ〜４Ｃのユーザが獲得する所定のインセンティブデータを予め表示するようにしてもよい。これにより、敵の体力値が小さい場合（例、５０％未満）に、第１の各携帯端末４Ａ〜４Ｃのユーザを元気づけることができる。

【0071】

（ｆ４） 第１救援要請送信機能又は第２救援要請機能により救援要請を送信した後、いずれかの第２の携帯端末（例、４Ｄ）からオン状態を示す応答を受信する応答受信機能。

【0072】

（ｆ５） 敵が負けた場合に、当該いずれかの第１の携帯端末４Ａのユーザのレベルと、当該いずれかの第２の携帯端末４Ｄのユーザのレベルとの差分を算出し、当該算出された差分がメモリ２２内で該当する範囲に関連付けられた特典データを当該いずれかの第２の携帯端末４Ｄに送信する特典データ送信機能。

【0073】

なお、メモリ２２にフレンドポイントが設定される場合、ゲーム制御プログラムｐ_ｓ３は、次の機能（ｆ６）を備えてもよい。

【0074】

（ｆ６） 応答受信機能による受信の後に、いずれかの第１の携帯端末４Ａのユーザのレベルと、当該いずれかの第２の携帯端末４Ｄのユーザのレベルとの差分を算出し、当該算出された差分がメモリ２２内で該当する範囲に関連付けられたフレンドポイント（データ交換ポイント）を当該いずれかの第２の携帯端末４Ｄに送信する交換ポイント送信機能。

【0075】

このように、救援機能のオン状態を設定したことによるフレンドポイントと、救援したことによる特典データを与えることができるので、救援する意欲の向上を図ることができる。これに対し、従来は、バトル途中からユーザの友達が救援する形態が無く、ユーザが所定の強さレベルのレイドボスとバトルを行い、バトル途中でレイドボスに負けそうになると、多くの場合、そのままレイドボスに負けてしまう方式であった。すなわち、従来のバトルゲームは、救援とは無関係の方式であった。

【0076】

また、ウェブソケット通信に関し、ゲーム制御プログラムｐ_ｓは、以下の機能（ｆ７）〜（ｆ１１）を備えてもよい。

【0077】

（ｆ７） バトルゲームへの参加募集期間中、第１の各携帯端末４Ａ〜４Ｃからバトルへの参加を求める第１ハンドシェイク要求を受けると、当該第１ハンドシェイク要求に基づき、当該第１の各携帯端末４Ａ〜４Ｃとの接続を確立して第１ハンドシェイク応答を返信し、当該第１の各携帯端末４Ａ〜４Ｃにバトルへの参加を許可する第１接続確立機能。

【0078】

（ｆ８） 第２の各携帯端末４Ｄ〜４Ｈから救援機能のオン状態又はオフ状態の設定完了を含む第２ハンドシェイク要求を受けると、当該第２ハンドシェイク要求に基づき、当該第２の各携帯端末４Ｄ〜４Ｈとの接続を確立して第２ハンドシェイク応答を返信する第２接続確立機能。

【0079】

（ｆ９） 第１及び第２の各携帯端末４Ａ〜４Ｈのうちのいずれかの携帯端末（例、４Ａ）からユーザの操作に応じたイベント情報を受けると、このイベント情報をウェブソケットの通信規格に従っていずれかの携帯端末（例、４Ａ）以外の他の各携帯端末（４Ｂ〜４Ｄ）に送信するウェブソケット通信機能。

【0080】

ここで、当該イベント情報は、ユーザの操作を示すアクション情報と、当該操作された時点から所定の期間を示す期間情報とを含んでもよい。また、当該ウェブソケット通信機能（ｆ９）においては、プロセッサ２３が、イベント情報を当該イベント情報に含まれる期間情報が示す期間内に他の携帯端末（例、４Ｂ〜４Ｄ）に送信するものとしてもよい。

【0081】

（ｆ１０） 敵が負けた場合に、所定のインセンティブデータを第１の各携帯端末４Ａ〜４Ｃに送信し、当該第１の各携帯端末４Ａ〜４Ｃとの接続を切断する第１接続切断機能。

【0082】

（ｆ１１） 敵が負けた場合に、特典データ送信機能（ｆ５）により特典データを第２の携帯端末４Ｄに送信した後、当該第２の携帯端末４Ｄとの接続を切断する第２接続切断機能。

【0083】

メモリ２２は、ゲーム制御プログラムｐ_ｓ３等を実行する際に必要とされるワークエリアなどとして使用される。

【0084】

プロセッサ２３は、記憶装置２１に記憶されたゲーム制御プログラムｐ_ｓ３と協働して、本発明の実施の形態に係るバトルゲームを行なう他、ウェブサーバ装置２全体の制御を司るものである。

【0085】

通信部２４は、ネットワーク１を介した携帯端末４Ａ〜４Ｈなどの外部装置との通信の制御を司る。

【0086】

各携帯端末４Ａ〜４Ｈの機能ブロック構成は、互いに同一のため、ここでは携帯端末４Ａの機能ブロック構成を代表例に挙げて述べる。

【0087】

携帯端末４Ａは、図８に示すように、記憶装置４１Ａ、メモリ４２Ａ、プロセッサ４３Ａ、通信部４４Ａ、電子コンパス４５Ａ、カメラ４６Ａ、表示部４７Ａ及びタッチパネル４８Ａを備えている。各部４１Ａ〜４８Ａの説明は、符号の末尾ＡをＢ、Ｃ、Ｄ、Ｅ、Ｆ、Ｇ又はＨに読み替えることにより、他の携帯端末４Ｂ、４Ｃ、４Ｄ、４Ｅ、４Ｆ、４Ｇ又は４Ｈにおける各部４１Ｂ〜４８Ｂ、４１Ｃ〜４８Ｃ、４１Ｄ〜４８Ｄ、４１Ｅ〜４８Ｅ、４１Ｆ〜４８Ｆ、４１Ｇ〜４８Ｇ又は４１Ｈ〜４８Ｈの説明として読み替え可能となっている。

【0088】

記憶装置４１Ａは、バトルゲームを実現するためのクライアントサイドのゲーム制御プログラムｐ_ｃ４等を記憶するものであり、例えば、ハードディスクドライブ（ＨＤＤ）などの大容量記憶装置である。この記憶装置４１Ａには、ＯＳ（オペレーティングシステム）ｐ_ｃ０、アプリケーション実行環境プログラムｐ_ｃ１、Ａ社ＤＢ接続キットプログラムｐ_ｃ２、Ａ社フレームワークプログラムｐ_ｃ３及びゲーム制御プログラムｐ_ｃ４が記憶されている。

【0089】

ＯＳ ｐ_ｃ０は、携帯端末４Ａの基本的な機能を実現するためのプログラムである。

【0090】

アプリケーション実行環境プログラムｐ_ｃ１は、プロセッサ４３Ａにより実行され、後述するアプリケーション実行環境Ｃ１を実現するためのプログラムである。

【0091】

Ａ社ＤＢ接続キットプログラムｐ_ｃ２は、プロセッサ４３Ａにより実行され、後述するＡ社ＤＢ接続キットＣ２を実現するためのプログラムである。

【0092】

Ａ社フレームワークプログラムｐ_Ｃ３は、プロセッサ４３Ａにより実行され、後述するＡ社フレームワークＣ３を実現するためのプログラムである。

【0093】

ゲーム制御プログラムｐ_ｃ４は、プロセッサ４３Ａにより実行され、本発明の実施の形態に係るバトルゲームのクライアント側の処理を制御するプログラムである。

【0094】

メモリ４２Ａは、クライアントサイドのゲーム制御プログラムｐ_ｃ４を実行する際に必要とされるワークエリアなどとして使用される。

【0095】

プロセッサ４３Ａは、記憶装置４１Ａに記憶されたゲーム制御プログラムｐ_ｃ４と協働して、本発明の実施の形態に係るバトルゲームを行なう他、携帯端末４Ａ全体の制御を司るものである。

【0096】

通信部４４Ａは、ネットワーク１を介したウェブサーバ装置２などの外部装置との通信の制御を司る。また、通信部４３は、無線ＬＡＮ、ブルートゥース（登録商標）、ＷｉＦｉなどの無線通信機能をも有する。

【0097】

電子コンパス４５Ａは、地磁気センサを有し、方位を測定する。

【0098】

カメラ４６Ａは、撮像機能を有し、撮像した画像を記憶装置４１Ａに格納する。

【0099】

表示部４７Ａは、タッチパネル４８Ａが取り付けられたディスプレイ装置である。

【0100】

タッチパネル４８Ａは、ユーザの操作に応じて、操作データを入力する機能をもっている。

【0101】

上記ウェブサーバ装置２と携帯端末４Ａ〜４Ｈそれぞれの機能ブロック構成に対応する電子回路のハードウェア構成自体は、きわめて一般的で周知であるものとして、その記載及び説明を省略する。

【0102】

図９は、本実施形態に係るウェブサーバ装置２と携帯端末４Ａ〜４Ｈ間の接続アーキテクチャの概念を示す模式図である。同図に示すように、Ａ社が提供するオンラインのゲームプログラム又はアプリケーションプログラムを実行するに当たり、携帯端末４Ａ〜４Ｈには、例えばＡＩＲ（登録商標）などで記述された、当該ゲームプログラム又はアプリケーションプログラムのためのアプリケーション実行環境Ｃ１が実装されると共に、当該Ａ社のデータベースに接続して課金処理等を行うためのＡ社データベース接続キットＣ２が組込まれる。

【0103】

これと共に、携帯端末４Ａ〜４Ｈがウェブサーバ装置２との通信を行う部分に関しては、Ａ社が開発した（ソフトウェア）クライアントサイドのフレームワークＣ３がインストールされる。

【0104】

一方のウェブサーバ装置２では、オンラインゲーム及びアプリケーションを実行するための、例えばNode.js（登録商標）で記述されたサーバ側JavaScript（登録商標）実行環境Ｓ１が設けられると共に、携帯端末４Ａ〜４Ｈとの通信を行う部分には、上記フレームワークＣ３と対応するＡ社（ソフトウェア）サーバサイドのフレームワークＳ２が設けられる。

【0105】

携帯端末４Ａ〜４ＨのフレームワークＣ３と、ウェブサーバ装置２のフレームワークＳ２との間では、ＨＴＭＬ５に関連した規格であるウェブソケット（WebSocket）を基盤としてアイテムの情報等が送受される。

【0106】

ウェブソケットによれば、サーバクライアント間でＨＴＴＰ（hypertext transfer protocol）を使用して１回ハンドシェイクを行い、サーバクライアント間で接続が確立すると、ＨＴＴＰ（リクエスト＆レスポンス方式）を使用せずに、ウェブソケット専用のプロトコルで双方向通信が実行される。ウェブソケットによる双方向通信は、長時間の接続を前提としており、サーバ又はクライアントにより切断されるまで継続して実行される。また、ウェブソケットによる通信は、ＨＴＴＰ通信よりもヘッダ情報及び処理負荷（オーバーヘッド）が小さい利点もある。さらに、ウェブソケットによる通信は、接続状態にある全ての装置が同じデータをリアルタイムで送受信して共有できる利点もある。また、ウェブソケットでは、クライアント側とサーバ側のいずれからでも送信が可能であり、例えば、サーバ側からクライアント側にデータをプッシュ配信することが可能である。

【0107】

このように、ウェブソケットによれば、リクエスト＆レスポンス形式の通信とは異なり、処理負荷が小さいリアルタイム通信を実現できる。このため、従来とは異なり、クライアント装置の数を制限せずに、複数のクライアント装置をサーバ装置に接続でき、バトルゲームを実現できる。

【0108】

上記フレームワークＣ３、Ｓ２は、ＯＳに依存しないスクリプト言語として、例えばJavaScriptを用いて記述されている。そのため、携帯端末４Ａ〜４ＨのＯＳがAndroid及びiOSなどのいずれのＯＳであっても同一接続環境を構築できる。

【0109】

次に、以上のように構成されたゲームシステムの動作について図１０乃至図２０を用いて説明する。なお、以下の説明では、ウェブサーバ装置２には、予め図３に示した各プログラムｐ_ｓ１〜ｐ_ｓ３がインストールされているものとする。同様に、各携帯端末４Ａ〜４Ｈには、最初にＡ社からサービス提供を受けた際に、図８に示した各プログラムｐ_ｃ１〜ｐ_ｃ４がインストールされたものとする。また、以下の説明では、記載を簡潔にする観点から、送受信に通信部２４、４４Ａ〜４４Ｈを介在させている旨の記載を省略する。また、以下の説明では、救援を含まない場合（第１の携帯端末４Ａ〜４Ｃを含み、第２の携帯端末４Ｄ〜４Ｈを含まない場合）の動作について説明し、続いて、救援を含む場合（第１及び第２の携帯端末４Ａ〜４Ｈを含む場合）の動作について説明する。

【0110】

（救援を含まない場合；図１０）
始めに、ウェブサーバ装置２では、第１の各携帯端末４Ａ〜４Ｃからハンドシェイク要求を受けると、当該第１の各携帯端末４Ａ〜４Ｃとの接続を確立してハンドシェイク応答を返信し、第１の各携帯端末４Ａ〜４Ｃにバトルを開始させる（時刻ｔ０）。例えば、ウェブサーバ装置２では、ほぼ同時刻にハンドシェイク要求を受け付けた第１の各携帯端末４Ａ〜４Ｃを１つのグループとしてレイドバトルゲームに参加させるものとする。また、このときの接続の確立により、ウェブサーバ装置２と第１の各携帯端末４Ａ〜４Ｃとの間でウェブソケット通信が実行可能となる。

【0111】

次に、例えば第１の携帯端末４Ａでは、ユーザがタッチパネル４８Ａに対し、レイドボスのＨＰ（体力）を「−１０」させる攻撃に相当するタップ操作を行った場合、図１０及び図１１に示すように、プロセッサ４３Ａが、当該タップ操作を示すアクション情報actＡと、当該タップ操作された時点（ｔ１１）から所定の期間１（＝ｔ１１〜ｔ１９）を示す期間情報とを含むイベント情報ivＡを作成する（時刻ｔ１１）。なお、期間１の値“１”としては、例えば、タップ操作された時点ｔ１１から＋１ずつカウントアップしてｔ１９に至るまでの間の十の位を示す値“１”が使用可能となっている。これは他の期間の値も同様である。また、カウントアップの時間間隔は任意であるが、リアルタイムでゲーム上の処理を実行する観点から、短い方が好ましい。

【0112】

また、第１の携帯端末４Ａでは、プロセッサ４３Ａが、このイベント情報ivＡによるアタックをレイドボスに加え、このイベント情報ivＡに応じたゲーム上の処理（レイドボスのＨＰを−１０させる処理）を実行すると共に、このイベント情報ivＡを含むリクエストをウェブサーバ装置２に送信する。なお、レイドボスのＨＰを−１０させる処理は、アタックによりレイドボスがダメージを受けることに相当する。このことは、以下の説明でも同様である。

【0113】

ウェブサーバ装置２では、プロセッサ２３が、このイベント情報ivＡによるアタックをレイドボスに加え、このイベント情報ivＡに応じたゲーム上の処理（レイドボスのＨＰを−１０させる処理）を実行する。また、プロセッサ２３は、図１０及び図１２に示すように、このイベント情報ivＡをウェブソケットの通信規格に従って他の第１の携帯端末４Ｂ、４Ｃに送信する（時刻ｔ１２）。このとき、プロセッサ２３は、プッシュ動作により、イベント情報ivＡを当該イベント情報ivＡに含まれる期間情報が示す期間内に他の第１の携帯端末４Ｂ、４Ｃに送信する。

【0114】

他の第１の携帯端末４Ｂ、４Ｃでは、プロセッサ４３Ｂ、４３Ｃが、このイベント情報ivＡによるアタックをレイドボスに加え、このイベント情報ivＡに応じたゲーム上の処理（レイドボスのＨＰを−１０させる処理）を実行する。

【0115】

また同様に、例えば第１の携帯端末４Ｂでは、ユーザがタッチパネル４８Ｂに対し、レイドボスのＨＰ（体力）を「−１０」させる攻撃に相当するタップ操作を行った場合、図１０及び図１３に示すように、プロセッサ４３Ｂが、当該タップ操作を示すアクション情報actＢと、当該タップ操作された時点（ｔ２１）から所定の期間２（＝ｔ２１〜ｔ２９）を示す期間情報とを含むイベント情報ivＢを作成する（時刻ｔ２１）。

【0116】

また、第１の携帯端末４Ｂでは、プロセッサ４３Ｂが、このイベント情報ivＢによるアタックをレイドボスに加え、このイベント情報ivＢに応じたゲーム上の処理（レイドボスのＨＰを−１０させる処理）を実行すると共に、このイベント情報ivＢを含むリクエストをウェブサーバ装置２に送信する。

【0117】

ウェブサーバ装置２では、プロセッサ２３が、このイベント情報ivＢによるアタックをレイドボスに加え、このイベント情報ivＢに応じたゲーム上の処理（レイドボスのＨＰを−１０させる処理）を実行する。また、プロセッサ２３は、図１０及び図１４に示すように、このイベント情報ivＢをウェブソケットの通信規格に従って他の第１の携帯端末４Ａ、４Ｃに送信する（時刻ｔ２２）。このとき、プロセッサ２３は、プッシュ動作により、イベント情報ivＢを当該イベント情報ivＢに含まれる期間情報が示す期間内に他の第１の携帯端末４Ａ、４Ｃに送信する。

【0118】

他の第１の携帯端末４Ａ、４Ｃでは、プロセッサ４３Ａ、４３Ｃが、このイベント情報ivＢによるアタックをレイドボスに加え、このイベント情報ivＢに応じたゲーム上の処理（レイドボスのＨＰを−１０させる処理）を実行する。

【0119】

更に同様に、他の第１の携帯端末４Ｃでは、ユーザがタッチパネル４８Ｃに対し、レイドボスのＨＰ（体力）を「−１０」させる攻撃に相当するタップ操作を行った場合、図１０及び図１５に示すように、プロセッサ４３Ｃが、当該タップ操作を示すアクション情報actＣと、当該タップ操作された時点（ｔ３１）から所定の期間３（＝ｔ３１〜ｔ３９）を示す期間情報とを含むイベント情報ivＣを作成する（時刻ｔ３１）。

【0120】

また、第１の携帯端末４Ｃでは、プロセッサ４３Ｃが、このイベント情報ivＣによるアタックをレイドボスに加え、このイベント情報ivＣに応じたゲーム上の処理（レイドボスのＨＰを−１０させる処理）を実行すると共に、このイベント情報ivＣを含むリクエストをウェブサーバ装置２に送信する。

【0121】

ウェブサーバ装置２では、プロセッサ２３が、このイベント情報ivＣによるアタックをレイドボスに加え、このイベント情報ivＣに応じたゲーム上の処理（レイドボスのＨＰを−１０させる処理）を実行する。また、プロセッサ２３は、このイベント情報ivＣをウェブソケットの通信規格に従って他の第１の携帯端末４Ａ、４Ｂに送信する（時刻ｔ３２）。このとき、プロセッサ２３は、プッシュ動作により、イベント情報ivＣを当該イベント情報ivＣに含まれる期間情報が示す期間内に他の第１の携帯端末４Ａ、４Ｂに送信する。

【0122】

他の第１の携帯端末４Ａ、４Ｂでは、プロセッサ４３Ａ、４３Ｃが、このイベント情報ivＣによるアタックをレイドボスに加え、このイベント情報ivＣに応じたゲーム上の処理（レイドボスのＨＰを−１０させる処理）を実行する。

【0123】

続いて、以上のようなイベント情報ivＡ、ivＢ、ivＣ、…に基づいてゲーム状況が進行し、例えばレイドボスのＨＰがゼロ値になったとする。

【0124】

このとき、ウェブサーバ装置２では、プロセッサ２３が、イベント情報ivＡ、ivＢ、ivＣ、…に基づいてバトルを終了させる。なお、バトルの終了は、レイドボスのＨＰがゼロになった場合に限らず、例えば制限時間内にレイドボスのＨＰがゼロにならなかった場合でもよい。

【0125】

いずれにしても、ウェブサーバ装置２では、プロセッサ２３が、バトルを終了させると、第１の各携帯端末４Ａ〜４Ｃとの接続を切断する（時刻ｔｎ）。このときの接続の切断により、ウェブソケット通信が終了される。

【0126】

これにより、救援を用いない場合の１回のレイドバトルゲームが完了する。

【0127】

次に、以上の説明を踏まえ、救援を用いる場合の動作について述べる。

【0128】

（救援を用いる場合；図１６）
救援を用いる場合、ウェブサーバ装置２は、図１０に示した動作に並行して、図１６に示すように、各ステップＳＴ２〜ＳＴ１２等を実行する。

【0129】

始めに、ウェブサーバ装置２では、プロセッサ２３が、各ユーザのレベルの差分の範囲と、特典データと、レア度と、特典データ交換ポイントとを関連付けてメモリ２２に設定する（ＳＴ１）。この設定により、救援を用いるレイドバトルゲームが実行可能となる。

【0130】

続いて、ウェブサーバ装置２では、プロセッサ２３が、バトルゲームへの参加募集期間の計時を開始する。

【0131】

ウェブサーバ装置２では、プロセッサ２３が、参加募集期間中、第１の各携帯端末４Ａ〜４Ｃからバトルへの参加を求める第１ハンドシェイク要求を受けると、当該第１ハンドシェイク要求に基づき、当該第１の各携帯端末４Ａ〜４Ｃとの接続を確立して第１ハンドシェイク応答を返信し（時刻ｔ０）、第１の各携帯端末４Ａ〜４Ｃにバトルへの参加を許可する（ＳＴ２）。このときの接続の確立により、ウェブサーバ装置２と第１の各携帯端末４Ａ〜４Ｃとの間でウェブソケット通信が実行可能となる。以下、接続の切断までの間は、特に述べなくても、ウェブサーバ装置２と第１の各携帯端末４Ａ〜４Ｃとの間の通信にはウェブソケット通信が用いられる。

【0132】

ステップＳＴ２と並行して、ウェブサーバ装置２では、プロセッサ２３が、参加募集期間中、例えば、ＳＮＳ上で第１の各携帯端末４Ａ〜４Ｃの各ユーザとは友達関係にある各ユーザをソーシャルグラフ情報データベースｐ_ｓから当該ゲームに関して検索する。また、ウェブサーバ装置２では、プロセッサ２３が、検索結果に基づいて、図１７に示すように、第１の各携帯端末４Ａ〜４Ｃの各ユーザのユーザ識別情報と、第２の各携帯端末４Ｄ〜４Ｈの各ユーザのユーザ識別情報とを関連付けてメモリ２２に書込む。このとき、ユーザ識別情報には各ユーザのレベル（同図中「Ｌｖ：○○」と表記。○○は任意の数値）（図示せず）も付加しておく。なお、各ユーザ識別情報（及びレベル）を関連付けた情報（以下、レベル管理情報３４という）の書き込みは、第２の各携帯端末４Ｄ〜４Ｈとの接続の確立後に実行してもよい。また、レベル管理情報３４内のユーザ識別情報にはユーザのレベルの他に、携帯端末識別情報（図示せず）を付加してもよい。また、レベル管理情報３４は、例えば図１８に示すように、各ユーザのユーザ識別情報及びレベルを互いに関連付けた情報と表現してもよい。

【0133】

しかる後、ウェブサーバ装置２では、プロセッサ２３が、参加募集期間中、検索結果に基づき、ＳＮＳ上で第１の各携帯端末４Ａ〜４Ｃの各ユーザとは友達関係にある各ユーザの第２の各携帯端末４Ｄ〜４Ｈに対し、第２キャラクタの情報の設定と、第２ハンドシェイク要求の送信とを促すメッセージを送信する。但し、このメッセージの送信は必須ではない。例えば、第１の各携帯端末４Ａ〜４Ｃの各ユーザが電子メール等で個人的に第２の各携帯端末のユーザに救援機能の設定を依頼してもよいためである。あるいは、参加募集期間中、第２の各携帯端末４Ｄ〜４Ｈのユーザが自発的に救援機能の設定をしてもよいためである。

【0134】

第２の各携帯端末４Ｄ〜４Ｈは、このメッセージを表示すると、各ユーザの操作により、第２キャラクタの情報をそれぞれメモリ４２Ｄ〜４２Ｈに設定した後、設定完了を含む第２ハンドシェイク要求をウェブサーバ装置２に送信する。なお、第２キャラクタの情報は、図１９に一例を示すように、第２キャラクタによる救援機能のオン状態又はオフ状態を含んでいる。具体的には、第２キャラクタの情報は、例えばユーザＩＤ、キャラクタＩＤ、ＨＰ等のパラメータ情報、及び救援機能のオン／オフの設定を含んでいる。

【0135】

ウェブサーバ装置２では、プロセッサ２３が、第２の各携帯端末４Ｄ〜４Ｈから第２ハンドシェイク要求を受けると、当該第２ハンドシェイク要求に基づき、当該第２の各携帯端末４Ｄ〜４Ｈとの接続を確立して第２ハンドシェイク応答を返信し（時刻ｔ０’）、第２の各携帯端末４Ｄ〜４Ｈの救援機能による救援態勢を整える（ＳＴ３）。このときの接続の確立により、ウェブサーバ装置２と第２の各携帯端末４Ｄ〜４Ｈとの間でウェブソケット通信が実行可能となる。以下、接続の切断までの間は、特に述べなくても、ウェブサーバ装置２と第２の各携帯端末４Ｄ〜４Ｈとの間の通信にはウェブソケット通信が用いられる。

【0136】

なお、参加募集期間は第１及び第２の各携帯端末４Ａ〜４Ｈ間で同一（又は共通）であるが、時刻ｔ０の値は第１の各携帯端末４Ａ〜４Ｃにおける第１ハンドシェイク要求の送信時刻に応じて第１の各携帯端末４Ａ〜４Ｃ毎に異なる。同様に、時刻ｔ０’の値は第２の各携帯端末４Ｄ〜４Ｈにおける第２ハンドシェイク要求の送信時刻に応じて第２の各携帯端末４Ｄ〜４Ｈ毎に異なる。

【0137】

ウェブサーバ装置３では、プロセッサ２３が、参加募集期間の終了後、所定の制限時間等に基づいてバトルゲームの実行を開始する（ＳＴ４）。なお、携帯端末の電源オフ等により、参加募集期間中にステップＳＴ３が実行されなかった第２の各携帯端末があれば、バトルの実行期間中もステップＳＴ３の救援態勢を整える処理を継続してもよい（ＳＴ５）。

【0138】

次に、ウェブサーバ装置３では、プロセッサ２３が、第１の各携帯端末４Ａ〜４Ｃのうちのいずれかの携帯端末４Ａ，４Ｂ又は４Ｃからユーザの操作に応じたイベント情報を受けると、このイベント情報をウェブソケットの通信規格に従っていずれかの携帯端末以外の他の各携帯端末に送信する（ＳＴ６）。

【0139】

例えば第１の携帯端末４Ａでは、ユーザによるタッチパネル４８Ａのタップ操作に応じて、前述同様に、プロセッサ４３Ａが、イベント情報ivＡを作成し、このイベント情報ivＡに応じたゲーム上の処理（レイドボスのＨＰを減少させる処理）を実行すると共に、このイベント情報ivＡを含むリクエストをウェブサーバ装置２に送信する。

【0140】

ウェブサーバ装置２では、プロセッサ２３が、このイベント情報ivＡに応じたゲーム上の処理（レイドボスのＨＰを減少させる処理）を実行し、当該イベント情報ivＡをウェブソケットの通信規格に従って他の携帯端末４Ｂ，４Ｃに送信する。

【0141】

他の携帯端末４Ｂ，４Ｃでは、プロセッサ４３Ｂ，４３Ｃが、このイベント情報ivＡに応じたゲーム上の処理（レイドボスのＨＰを−１０させる処理）を実行する。

【0142】

すなわち、ステップＳＴ６では、各携帯端末４Ａ〜４Ｃから送信されたイベント情報ivＡ〜ivＣが、ウェブソケット通信により、リアルタイムで他の各携帯端末４Ａ〜４Ｃに共有される。

【0143】

続いて、以上のようなイベント情報及び制限時間に基づいてゲーム状況が進行し、例えば、バトル中に第１の携帯端末４Ａの第１キャラクタが敵に負けそうになったとする。このとき、第１の携帯端末４Ａは、ユーザの操作により、救援要請をウェブサーバ装置２に送信する。

【0144】

ウェブサーバ装置２では、プロセッサ２３が、第１の携帯端末４Ａから救援要請を受けると、当該救援要請を第２の各携帯端末４Ｄ〜４Ｈに送信する（ＳＴ７）。

【0145】

各携帯端末４Ｄ〜４Ｈは、プロセッサ４３Ｄ〜４３Ｈが、救援要請を受けると、メモリ４２Ｄ〜４２Ｈを参照し、救援機能のオン状態又はオフ状態を示す応答をウェブサーバ装置２に送信する。

【0146】

ウェブサーバ装置２では、プロセッサ２３が、送信した救援要請に対する応答がいずれもオフ状態を示すとき、救援要請を送信した第１の携帯端末４Ａのユーザのレベルと、第２の各携帯端末４Ｄ〜４Ｈの各ユーザのレベルとの差分を個別に算出し、当該算出された各々の差分がメモリ２２内で該当する範囲に関連付けられた特典データの一部を含む表示データと、救援要請とを第２の各携帯端末４Ｄ〜４Ｈにウェブソケットの通信規格に従って送信（プッシュ配信）する。

【0147】

第２の各携帯端末４Ｄ〜４Ｈでは、特典データの一部を含む表示データと、救援要請とを表示し、救援機能をオン状態に変更することを各ユーザに促す。このとき、第２の携帯端末４Ｄでは、ユーザの操作により、メモリ４２Ｄに設定された救援機能のオフ状態をオン状態に変更したとする。第２の携帯端末４Ｄでは、プロセッサ４３Ｄが、当該救援機能のオン状態を示す応答をウェブサーバ装置２に送信する。これは、２回目の救援要請に対する応答が救援機能のオン状態を示す例であるが、この例に限らず、１回目の救援要請に対する応答が救援機能のオン状態を示していてもよい。

【0148】

いずれにしても、ウェブサーバ装置２では、プロセッサ２３が、救援要請を送信した後、例えば第２の携帯端末４Ｄから救援機能のオン状態を示す応答を受信したとする（ＳＴ８）。

【0149】

ここで、フレンドポイントを用いる場合には、ウェブサーバ装置２では、救援機能のオン状態を示す応答の受信の後に、救援要請を出した第１の携帯端末４Ａのユーザのレベルと、当該応答を送信した第２の携帯端末４Ｄのユーザのレベルとの差分を算出し、当該算出された差分がメモリ２２内で該当する範囲に関連付けられたフレンドポイントを当該第２の携帯端末４Ｄに送信する。第２の携帯端末４Ｄでは、プロセッサ４３Ｄが、フレンドポイントを受信すると、当該フレンドポイントをメモリ４２Ｄに保存する。また、フレンドポイントを用いない場合には、このフレンドポイントに関する処理は省略される。

【0150】

さて、ウェブサーバ装置２では、プロセッサ２３が、第２の携帯端末４Ｄから救援機能のオン状態を示す応答を受信すると、図２０に一例を示すように、当該第２の携帯端末４Ｄの救援機能により第２キャラクタＣ−４Ｄをバトル途中からバトルに参加させる（ＳＴ９）。第２キャラクタＣ−４Ｄとしては、例えば、第２の携帯端末４Ｄによる操作が不要であり、ゲームＡＩ（人工知能）により制御されるＮＰＣ（ノン・プレイヤー・キャラクタ）が使用可能となっている。第２キャラクタＣ−４Ｄは、救援要請を出した第１の携帯端末４Ａの第１キャラクタＣ−４Ａを救援するように、レイドボスとバトルを行う。なお、第１キャラクタＣ−４Ａは、第１の携帯端末４Ａの攻撃ボタンＢ１のタップ操作により、レイドボスを攻撃するＰＣ（プレイヤー・キャラクタ）である。また、図中の救援要請ボタンＢ２は、救援要請を送信する指示を入力するためのボタンである。回復ボタンＢ３は、ユーザのタップ操作により、第１キャラクタＣ−４Ａの体力値（ＨＰ）を回復させるためのボタンである。

【0151】

続いて、前述したイベント情報及び制限時間に基づいてゲーム状況が進行し、例えばレイドボスのＨＰがゼロ値になったとする。

【0152】

このとき、ウェブサーバ装置２では、プロセッサ２３が、イベント情報によるアタックに基づいてバトルを終了させる（ＳＴ１０）。但し、バトルの終了は、イベント情報に基づいてレイドボスのＨＰがゼロになった場合（レイドボスが負けた場合）に限らず、例えば、制限時間内にレイドボスのＨＰがゼロにならなかった場合（レイドボスが勝った場合）でもよい。

【0153】

ウェブサーバ装置２では、プロセッサ２３が、敵が負けた場合に、所定のインセンティブデータを第１の各携帯端末４Ａ〜４Ｃに送信し、当該第１の各携帯端末４Ａ〜４Ｃとの接続を切断する（ＳＴ１１；時刻ｔｎ）。但し、プロセッサ２３は、敵が勝った場合にはインセンティブデータを送信せずに、各携帯端末４Ａ〜４Ｃとの接続を切断する（時刻ｔｎ）。

【0154】

また、ウェブサーバ装置２では、プロセッサ２３が、敵が負けた場合に、救援要請を出した第１の携帯端末４Ａのユーザのレベルと、救援機能のオン状態を示す応答を送信した第２の携帯端末４Ｄのユーザのレベルとの差分を算出する。

【0155】

しかる後、ウェブサーバ装置２では、プロセッサ２３が、当該算出した差分がメモリ２２内で該当する範囲に関連付けられた特典データを当該第２の携帯端末４Ｄに送信し、当該第２の携帯端末４Ｄとの接続を切断する（ＳＴ１２；時刻ｔｎ’）。

【0156】

ステップＳＴ１１とＳＴ１２により接続が切断されると、ウェブソケット通信が終了される。これにより、図１４に示した如き、救援を用いた場合の１回のレイドバトルゲームが完了する。

【0157】

上述したように本実施形態によれば、ウェブサーバ装置２は、各携帯端末４Ａ〜４Ｈとウェブソケット通信を実行する。ウェブサーバ装置２は、いずれかの第１の携帯端末４Ａから救援要請を受けると、当該救援要請を第２の各携帯端末４Ｄ〜４Ｈに送信する。ウェブサーバ装置２は、第２の各携帯端末４Ｄ〜４Ｈのうちのいずれかの第２の携帯端末４Ｄの救援機能がオン状態のときに第２キャラクタが第１キャラクタを救援可能なバトルゲームを第１の各携帯端末４Ａ〜４Ｃに実行させる。

【0158】

従って、クライアント装置の数を制限せずに、複数のクライアント装置をウェブサーバ装置に接続でき、バトル途中からユーザの友達が参加可能なバトルゲームを実現することができる。

【0159】

また、救援要請に対する応答がいずれもオフ状態を示すとき、ウェブサーバ装置２が、当該いずれかの第１の携帯端末４Ａのユーザのレベルと、第２の各携帯端末４Ｄ〜４Ｈの各ユーザのレベルとの差分に該当する範囲に関連付けられた特典データの一部を含む表示データと、救援要請とを第２の各携帯端末４Ｄ〜４Ｈに送信する。ここで、特典データの一部は、レア度の低い順に表示データに含まれた各インセンティブデータの一部である。特典データの一部が特典データの全体に占める割合は、敵の体力値とは負の相関関係を有する。すなわち、ゲーム終盤の敵の体力値が小さいときに、特典データの多くが表示されると共に、表示内容にレア度の高い特典データが含まれるようになる。

【0160】

従って、ゲーム終盤の敵の体力値が小さいときに、第２の各携帯端末４Ｄ〜４Ｈの各ユーザに対し、救援機能の設定をオン状態に変えるように、強く促すことができる。

【0161】

また、救援要請に対する応答のいずれかがオン状態を示すとき、ウェブサーバ装置２が、救援要請を出した第１の携帯端末４Ａのユーザのレベルと、オン状態を示す応答をした第２の携帯端末４Ｄのユーザのレベルとの差分に該当する範囲に関連付けられたフレンドポイントを当該第２の携帯端末４Ｄに送信する。

【0162】

このように、救援機能をオン状態に設定した第２の携帯端末４Ｄにフレンドポイントを与えることができるので、救援する意欲の向上を図ることができる。

【0163】

なお、上記実施形態に記載した手法は、コンピュータに実行させることのできるプログラムとして、磁気ディスク（フロッピー（登録商標）ディスク、ハードディスクなど）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤなど）、光磁気ディスク（ＭＯ）、半導体メモリなどのコンピュータ読み取り可能な記憶媒体に格納して頒布することもできる。

【0164】

なお、本願発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。更に、異なる実施形態に亘る構成要素を適宜組合せてもよい。

【符号の説明】

【0165】

１…ネットワーク、２…ウェブサーバ装置、４Ａ〜４Ｈ…携帯端末、５…アクセスポイント（ＡＰ）、６…基地局、２１，４１Ａ…記憶装置、２２，４２Ａ…メモリ、２３，４３Ａ…プロセッサ、２４，４４Ａ…通信部、４５Ａ…電子コンパス、４６Ａ…カメラ、４７Ａ…表示部、４８Ａ…タッチパネル。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】