JP2023172876A - プログラム、情報処理方法、端末、サーバ - Google Patents

Abstract

【課題】ゲームに関する興趣を向上させる。【解決手段】サーバと通信し、ゲームに関する処理を行う端末によって実行されるプログラムは、ソーシャルネットワーキングサービス（ＳＮＳ）で端末のユーザのアカウントと関連付けられた第１アカウントに関する情報を端末の表示部に表示することと、表示部に表示された第１アカウントに関する情報に対するユーザによる入力に基づいて、第１アカウントに基づく、ゲームに登場するオブジェクトを要求するための第１情報を端末の通信部によってサーバに送信することと、第１情報を送信したことに基づいて、オブジェクトであって第１アカウントに基づく第１オブジェクトに関する第２情報を通信部によってサーバから受信することと、第１オブジェクトを表示部に表示することとが端末によって実行される。【選択図】図１－１

Description

本開示は、プログラム、情報処理方法、端末、サーバ等に関する。

複数のユーザ間（複数の端末間）でコンテンツのやり取りを行うためのサービス（例えば、メッセージングサービス）がある。例えば特許文献１には、公式アカウント（オフィシャルアカウント）を利用して広告を配信する技術が開示されている。

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

本発明の第１の態様によると、ゲームに関する処理を行う端末によって実行されるプログラムは、ソーシャルネットワーキングサービス（以下、「ＳＮＳ」と称する）で端末のユーザのアカウントと関連付けられた第１アカウントに基づく、ゲームに登場する第１オブジェクトを、端末の制御部によって取得することと、第１オブジェクトと、第１アカウントに対応する対応情報とを、ＳＮＳにおいて表示させるための第１制御を、制御部によって実行することと、が端末によって実行される。
本発明の第２の態様によると、ゲームに関する処理を行う端末の情報処理方法は、ＳＮＳで端末のユーザのアカウントと関連付けられた第１アカウントに基づく、ゲームに関する第１オブジェクトを、端末の制御部によって取得することと、第１オブジェクトと、第１アカウントに対応する対応情報とを、ＳＮＳにおいて表示させるための第１制御を、制御部によって実行することと、が端末によって実行される。
本発明の第３の態様によると、ゲームに関する処理を行う端末は、ＳＮＳで端末のユーザのアカウントと関連付けられた第１アカウントに基づく、ゲームに関する第１オブジェクトを取得する制御部を備え、制御部は、第１オブジェクトと、第１アカウントに対応する対応情報とを、ＳＮＳにおいて表示させるための第１制御を実行する。

第１実施例に係る通信システムのシステム構成の一例を示す図。 第１実施例に係るサーバの制御部によって実現される機能の一例を示す図。 第１実施例に係るサーバの記憶部に記憶される情報の一例を示す図。 第１実施例に係るアカウント登録データのデータ構成の一例を示す図。 第１実施例に係るモンスター生成テーブルのテーブル構成の一例を示す図。 第１実施例に係る端末の制御部によって実現される機能の一例を示す図。 第１実施例に係る端末の記憶部に記憶される情報の一例を示す図。 第１実施例に係る端末の表示部に表示される画面の一例を示す図。 第１実施例に係る端末の表示部に表示される画面の一例を示す図。 第１実施例に係る端末の表示部に表示される画面の一例を示す図。 第１実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第１変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第１変形例に係る通信システムのシステム構成の一例を示す図。 第１変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第１変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第１変形例に係る端末の表示部に表示される画面の一例を示す図。 第１変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第１変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第１変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第１変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第１変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第１変形例に係るモンスター生成テーブルのテーブル構成の一例を示す図。 第１変形例に係る端末の表示部に表示される画面の一例を示す図。 第１変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第１変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第２実施例に係る公式アカウント管理データベースのデータ構成の一例を示す図。 第２実施例に係るモンスター生成テーブルのテーブル構成の一例を示す図。 第２実施例に係る端末の表示部に表示される画面の一例を示す図。 第２実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第２実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第２実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第２変形例に係る端末の表示部に表示される画面の一例を示す図。 第３実施例に係る端末の表示部に表示される画面の一例を示す図。 第３実施例に係る端末の表示部に表示される画面の一例を示す図。 第３実施例に係る端末の表示部に表示される画面の一例を示す図。 第３実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第３実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第３実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第４実施例に係る通信システムのシステム構成の一例を示す図。 第４実施例に係る端末の表示部に表示される画面の一例を示す図。 第４実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第４実施例に係る端末の表示部に表示される画面の一例を示す図。 第４実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第４実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第４実施例に係る端末の表示部に表示される画面の一例を示す図。 第４実施例に係る端末の表示部に表示される画面の一例を示す図。 第４実施例に係る端末の表示部に表示される画面の一例を示す図。 第４実施例に係る端末の表示部に表示される画面の一例を示す図。 第４実施例に係る端末の表示部に表示される画面の一例を示す図。 第４実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第４実施例に係る端末の表示部に表示される画面の一例を示す図。 第４実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第４実施例に係る端末の表示部に表示される画面の一例を示す図。 第４実施例に係るゲームサーバに記憶される情報の一例を示す図。 第４実施例に係る端末の表示部に表示される画面の一例を示す図。 第４実施例に係るゲームサーバに記憶される情報の一例を示す図。 第４実施例に係る端末の表示部に表示される画面の一例を示す図。 第４実施例に係る端末の表示部に表示される画面の一例を示す図。

＜法的事項の遵守＞
本明細書に記載の開示は、通信の秘密など、本開示の実施に必要な実施国の法的事項遵守を前提とすることに留意されたい。

＜実施形態＞
本明細書では、分かり易いように「限定ではなく例として」と記載する箇所があるが、該当箇所ばかりでなく、以下説明する実施形態の全体について、その記載内容に限定されるものではないことに留意されたい。

本開示に係るプログラム等を実施するための実施形態について、図面を参照して説明する。

システムとは、限定ではなく例として、複数の装置を有して構成されるものとすることができる。
複数の装置は、同じ種類の装置の組合せとしてもよいし、異なる種類の装置の組合せとしてもよいし、同じ種類の装置と異なる種類の装置との組合せとしてもよい。
なお、システムとは、限定ではなく例として、複数の装置が協働して何らかの処理を行うもの、と考えることもできる。

また、クライアント（クライアント装置）とサーバとに関するシステムとは、限定ではなく例として、少なくとも以下のいずれかと考えることができる。
（１）端末＆サーバ
（２）サーバ
（３）端末

（１）は、限定ではなく例として、少なくとも１つの端末と、少なくとも１つのサーバとを含むシステムである。この一例は、クライアントサーバシステムである。

サーバは、限定ではなく例として、以下の装置によって構成されており、単独の装置であってもよいし、複数の装置の組合せであってもよいものとする。

具体的には、サーバは、限定ではなく例として、少なくとも１つのプロセッサー（限定ではなく例として、ＣＰＵ：Central Processing Unit、ＧＰＵ：Graphics Processing Unit、ＡＰＵ：Accelerated Processing Unit、ＤＳＰ：Digital Signal Processor（限定ではなく例として、ＡＳＩＣ：Application Specific Integrated Circuit、ＦＰＧＡ：Field Programmable Gate Array）等）、コンピュータ装置（プロセッサー＋メモリ）、制御装置、演算装置、処理装置等のいずれかを有して構成され、いずれか１つの装置の同種を複数備える構成（限定ではなく例として、ＣＰＵ＋ＣＰＵ、ホモジニアスマルチコアプロセッサー等）や、いずれか１つの装置の異種を複数備える構成（限定ではなく例として、ＣＰＵ＋ＤＳＰ、ヘテロジニアスマルチコアプロセッサー等）としてもよいし、複数の装置の組み合わせ（限定ではなく例として、プロセッサー＋コンピュータ装置、プロセッサー＋演算装置、複数の装置をヘテロジニアス化したもの等）であってもよい。
なお、プロセッサーは、仮想プロセッサーとしてもよい。

また、サーバによって何らかの処理を実行する場合に、単一の装置で構成される場合は、単一の装置によって実施例に記載されている処理が実行される。また、複数の装置を有して構成されている場合には、一部の処理を一方の装置が実行し、その他の処理を他方の装置が実行するように構成されていてもよい。限定ではなく例として、プロセッサーと、演算装置とを有して構成される場合、第１処理をプロセッサーが実行し、第２処理を演算装置が実行するように構成されていてもよい。
また、複数の装置で構成する場合には、各々の装置が互いに物理的に離れた位置に配置されて構成されてもよい。

また、サーバの機能は、限定ではなく例として、クラウドコンピューティングにおけるＰａａＳやＩａａＳ、ＳａａＳの形態で提供されるようにしてもよい。

また、システムの制御部は、端末の制御部とサーバの制御部とのうちの少なくともいずれか一方とすることができる。つまり、限定ではなく例として、（１Ａ）端末の制御部のみ、（１Ｂ）サーバの制御部のみ、（１Ｃ）端末の制御部とサーバの制御部との両方、のうちのいずれかを、システムの制御部とすることができる。

また、システムの制御部が行う制御や処理（以下、包括的に「制御等」と称する。）は、（１Ａ）端末の制御部のみによって行うようにしてもよいし、（１Ｂ）サーバの制御部のみによって行うようにしてもよいし、（１Ｃ）端末の制御部とサーバの制御部との両方によって行うようにしてもよい。
また、（１Ｃ）では、限定ではなく例として、システムが制御部によって行う制御等のうちの一部の制御等を端末の制御部によって行うようにし、残りの制御等をサーバの制御部によって行うようにしてもよい。この場合、制御等の割り当て（割り振り）は、等分であってもよいし、等分ではなく異なる割合で割り当ててもよい。

また、サーバの通信部という場合、サーバが単一の装置によって構成されている場合には、単一の装置が備える通信部そのものであってもよい。また、サーバが複数の装置を有して構成されている場合には、サーバの通信部は、各々の装置が備える各々の通信部を含む構成であってもよい。
限定ではなく例として、サーバは、第１装置と第２装置とを備え、第１装置は第１通信部を有し、第２装置は第２通信部を有する場合、サーバの通信部は、第１通信部と第２通信部とを含む概念としてもよい。

（２）は、限定ではなく例として、複数のサーバによって構成されるシステム（以下、「サーバシステム」と称する。）とすることができる。この場合、各々のサーバの構成としては、前述した構成を同様に適用することができる。

サーバシステムが行う制御等は、複数のサーバのうち、（２Ａ）一のサーバのみによって行うようにしてもよいし、（２Ｂ）他のサーバのみによって行うようにしてもよいし、（２Ｃ）一のサーバと他のサーバとが行うようにしてもよい。
また、（２Ｃ）では、限定ではなく例として、サーバシステムが行う制御等のうちの一部の制御等を一のサーバが行うようにし、残りの制御等を他のサーバが行うようにしてもよい。この場合、制御等の割り当て（割り振り）は、等分であってもよいし、等分ではなく異なる割合で割り当ててもよい。

（３）は、限定ではなく例として、複数の端末によって構成されるシステムとすることができる。
このシステムは、限定ではなく例として、以下のようなシステムとすることができる。
・サーバの機能を端末に持たせるシステム（分散システム）。これは、限定ではなく例として、ブロックチェーンの技術を用いて実現することが可能である。
・端末同士が無線通信を行うシステム。これは、限定ではなく例として、ブルートゥース（登録商標）等の近距離無線通信技術を用いてＰ２Ｐ（ピアツーピア）方式等で通信を行うことで実現可能である。

なお、上記は、制御部に限らず、システムの構成要素となり得る入出力部、通信部、記憶部、時計部等の各機能部についても同様である。

以下の実施形態では、限定ではなく例として、端末とサーバとを含むシステム（限定ではなく例として、クライアントサーバシステム）を例示する。
なお、サーバとして、上記（２）のサーバシステムを適用することも可能である。

また、端末とサーバとを含むシステムに代えて、サーバを含まないシステム、限定ではなく例として、上記（３）のシステムを適用することも可能である。
この場合の実施形態は、前述したブロックチェーンの技術等に基づいて構成することが可能である。具体的には、限定ではなく例として、以下の実施形態で説明するサーバに記憶されて管理されるデータを、ブロックチェーン上に保管（格納）する。そして、端末が、ブロックチェーンへのトランザクションを生成し、トランザクションがブロックチェーン上で承認されると、ブロックチェーン上に保管されたデータが更新されるようにすることができる。

なお、端末と表現した場合でも、これは、クライアントサーバにおけるクライアントの装置としての端末の意味に限定されるものではない。
つまり、端末は、クライアントサーバにおけるものではない装置の概念を含むこともあり得る。

また、本明細書では、適宜「通信Ｉ／Ｆによって」という表現を用いる。これは、限定ではなく例として、装置が、制御部（プロセッサー等）の制御に基づいて、通信Ｉ／Ｆを介して（通信部を介して）、各種の情報やデータを送受信することを示してもよいものとする。

また、本明細書において「関する」、「関連する」と記載された用語について、「Ａに関するＢ」や「Ａに関連するＢ」という場合、限定ではなく例として、「Ａ」と何らかの関係性を有する「Ｂ」を意味してよいものとする。この具体例については後述する。

また、本明細書において、「ＡとＢとを送信する」、「ＡとＢとを受信する」といったように、装置が２以上のものを対象として処理を行うことには、「Ａ」と「Ｂ」とをタイミングを合わせて行うもの（以下、「同時」という。）と、「Ａ」と「Ｂ」とをタイミングをずらして行うもの（以下、「非同時」という。）とを含めてよいものとする。
限定ではなく例として、第１情報と第２情報とを送信するという場合、第１情報と第２情報とをタイミングを合わせて送信するものと、第１情報と第２情報とをタイミングをずらして送信するものとの両方の概念を含めてよいものとする。
なお、ラグ（タイムラグ）を考慮し、「同時」には「ほぼ同時」を含めてよいものとする。

なお、「Ａ」と「Ｂ」とをタイミングをずらして行うといっても、これはあくまでも「Ａ」と「Ｂ」とを対象として処理を行うものであればよく、その目的は必ずしも同じでなくてもよいものとする。
限定ではなく例として、上記のように第１情報と第２情報とを送信するという場合、第１情報と第２情報とを送信しさえすればよく、同じ目的で第１情報と第２情報とを送信する場合の他、異なる目的で第１情報と第２情報とを送信する場合も含めてよいものとする。

また、本明細書では、限定ではなく例として、ユーザのアカウント同士を関連付けて管理するサービス（ユーザのアカウントを管理してそれらの関係を管理するサービス）でユーザのアカウントと関連付けられたアカウントに基づいて、ゲームに登場するオブジェクトを取得する手法を説明する。
なお、アカウントは、ユーザの端末２０のアカウントとしてもよい。

以下説明する実施例では、限定ではなく例として、ソーシャルネットワーキングサービス（以下、「ＳＮＳ」と称する。）でユーザのアカウントと関連付けられたアカウントに基づいて、ゲームに登場するオブジェクトを取得する例を示す。
ＳＮＳは、上記のユーザのアカウント同士を関連付けて管理するサービス（ユーザのアカウントを管理してそれらの関係を管理するサービス）の一例とすることができる。
ＳＮＳは、ユーザ間の関係性の構築や促進、コミュニケーションを主目的とするサービスに限定されず、アカウントをある種の関係性のあるものとして管理する構成や機能を有するサービスであれば足りるとしてもよい。
また、ＳＮＳにおけるアカウントの関連付けには、一方向的な関連付け（限定ではなく例として、一のユーザが他のユーザを一方的にフォローするものなど）を含めてもよいし、双方向的な関連付け（限定ではなく例として、ユーザ同士が互いに友だちや友人として関連付けられるものなど）を含めてもよいし、複数のユーザを一のグループに属するものとして管理することによって関係性を管理するものなどを含めてもよい。

以下説明する実施例では、ＳＮＳの一例としてメッセージングサービスを例示する。
メッセージングサービスは、ユーザがチャットを行うためのサービス（以下、「チャットサービス」と称する。）の一例とすることができ、チャットサービスを実現するためのアプリケーションを「チャットアプリケーション」と称し、メッセージングサービスを実現するためのアプリケーションを「メッセージングアプリケーション」と称する。
チャットアプリケーションでは、限定ではなく例として、ユーザがチャットルームでチャットを行うことができるようにすることができる。

チャットルームは、限定ではなく例として、複数のユーザの端末間で送受信されるコンテンツを各々のユーザが閲覧できるＵＩ（User Interface）やＧＵＩ（Graphical User Interface）としてもよい。

また、メッセージングサービスには、インスタントメッセージサービスを含めてもよい。
インスタントメッセージングサービスでは、サーバを介して複数の装置（限定ではなく例として、端末）間で簡単なメッセージの送受信を行うようにすることができ、限定ではなく例として、ユーザがトークルームでトークを行うようにすることができる。トークルームは、チャットルームの一例とすることができる。

また、トークルームには、１対１のユーザのトークルーム（以下、「１対１トークルーム」と称する。）、複数のユーザを含むグループのトークルーム（以下、「グループトークルーム」と称する。）、ＯＡ事業者（限定ではなく例として、メッセージングサービスの事業者と提携する事業者）とのトークルーム（以下、「ＯＡトークルーム」と称する。）等を含めることができる。

また、メッセージングアプリケーションのアカウントであって、一般のユーザではない事業者のアカウントを「公式アカウント（ＯＡ（Official Account））」と称し、この公式アカウントのユーザを「公式ユーザ」と称する。なお、これを「公式アカウントユーザ」や「公式アカウント事業者」等のように称してもよい。
それに対し、メッセージングアプリケーションのアカウントであって、ＯＡ事業者ではないユーザのアカウントを「一般アカウント」と称し、一般アカウントのユーザを「一般ユーザ」と称する。なお、これを「一般アカウントユーザ」等のように称してもよい。
つまり、メッセージングアプリケーションのアカウントには、一般アカウントと公式アカウントとを含めてよいものとする。

一般アカウントは、第１種別のアカウントの一例としてもよく、公式アカウントは、第２種別のアカウントの一例としてもよい。
また、一般アカウントは、メッセージングサービス（メッセージングアプリケーション）で、第１種別として一の端末２０、またはその端末２０のユーザと関連付けられたアカウントの一例としてもよく、公式アカウントは、メッセージングサービス（メッセージングアプリケーション）で、第２種別として一の端末２０、またはその端末２０のユーザと関連付けられたアカウントの一例としてもよい。

また、ＯＡ事業者も、限定ではなく例として、一般アカウントのユーザの端末と同様の端末を利用して、サーバを介して、他の装置との間でメッセージの送受信を行うことができるようにしてもよい。

本明細書において、メッセージ（メッセージ情報）とは、限定ではなく例として、メッセージングサービスで用いられる送信元と送信先とが定められる情報であって、メッセージを識別するための識別情報（メッセージＩＤ）とメッセージコンテンツとで構成される情報を意味するものとしてもよい。
また、メッセージコンテンツとは、限定ではなく例として、メッセージＩＤを除くメッセージの中身を意味するものとしてもよい。メッセージコンテンツは、１または２以上のコンテンツとしてもよい。

また、メッセージを識別するための識別情報として設定される情報を、限定ではなく例として、「メッセージＩＤ」としてもよい。同じメッセージＩＤのメッセージに含まれるメッセージコンテンツは、このメッセージＩＤによって識別されると考えることもできる。よって、メッセージを識別するための識別情報は、メッセージコンテンツを識別するための識別情報と実質的に同義と考えることもできる。
なお、これとは異なり、メッセージコンテンツごとに個別の識別情報（メッセージコンテンツＩＤ）を設定するようにしてもよいし、そのようにしなくてもよい。

コンテンツには、限定ではなく例として、テキスト形式のテキストコンテンツ、画像（静止画像、動画像の少なくともいずれか一方を含む。）形式の画像コンテンツ、音（音声を含む。）形式の音コンテンツなどを含めてよいものとする。
なお、この他にも、ユーザの操作に供するボタンやアイコン等の操作コンテンツや、ＵＲＩ（ＵＲＬ等を含む。）などのリンクコンテンツを含めてもよいものとする。

テキストには、限定ではなく例として、文字コードで表される各国の文字、拡張文字、機種依存文字、数字、記号、図形及び符号の少なくともいずれか１つを含めてよいものとする。
なお、テキストは、上記の文字、拡張文字、機種依存文字、数字、記号、図形及び符号の少なくとも１つを含まなくてもよく、その他のテキストを含んでもよい。

画像には、限定ではなく例として、アイコン、ボタン、スタンプ、絵文字、バナー画像といった各種の画像の情報のうちの少なくともいずれか１つを含めることができる。

なお、上記の定義とは異なり、メッセージの上位概念がコンテンツである、またはコンテンツとメッセージとは同義である、と定義してもよいし、そのように定義しなくてもよい。

＜実施例＞
以下、本発明を適用した実施例の一例について説明する。
以下説明する実施例では、ＳＮＳとして、トークルーム（チャットルーム）を利用してユーザ同士がメッセージ（コンテンツ）を送受信可能なメッセージングサービスを適用する場合を例示するが、このようなメッセージングサービス以外のＳＮＳについても、以下説明する手法を同様に適用可能である。

＜第１実施例＞
第１実施例は、限定ではなく例として、ゲームアプリケーションを実行することで端末２０のユーザ（プレーヤ）がプレイ可能なゲームにおいて、メッセージングアプリケーションを利用する一般アカウントのユーザが、メッセージングアプリケーションにおいて友だちとして登録されている一般アカウント（一般ユーザの一般アカウント）に基づいて、オブジェクトを取得することに関する実施例である。

第１実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。

＜システム構成＞
図１－１は、本実施例における通信システム１Ａのシステム構成の一例を示す図である。
通信システム１Ａでは、限定ではなく例として、ネットワーク３０を介して、サーバ１０と、複数の端末２０（端末２０Ａ，端末２０Ｂ，端末２０Ｃ，・・・）とが接続される。

サーバ１０は、ネットワーク３０を介して、一般ユーザ（や公式ユーザ）が所有する端末２０に、ゲームサービス（ゲームアプリケーション）や、メッセージングサービス（メッセージングアプリケーション）を含むチャットサービス（チャットアプリケーション）を提供する機能を有する。

この実施例では、限定ではなく例として、サーバ１０を、メッセージングアプリケーションに関する情報を管理するメッセージングサーバとしての機能と、ゲームアプリケーションに関する情報を管理するゲームサーバとしての機能とを有するものとして説明する。
この場合、限定ではなく例として、メッセージングサービス事業者（運営者）をサーバ１０のユーザとしてもよい。

なお、電子マネー（電子貨幣）等による電子決済を可能とする支払いサービス（支払いアプリケーション）の事業者がサーバ１０のユーザとなって、メッセージングサービス等を運営するようにしてもよい。支払いサービス事業者は、支払いアプリケーションの一機能としてメッセージングサービスを提供するようにしてもよいし、そのようにしなくてもよい。

なお、ネットワーク３０に接続されるサーバ１０の数や端末２０の数は限定されない。

端末２０（端末２０Ａ，端末２０Ｂ，端末２０Ｃ、・・・）は、各実施例において記載する機能を実現できる情報処理端末であればどのような端末であってもよい。端末２０は、限定ではなく例として、スマートフォン、携帯電話（フィーチャーフォン）、コンピュータ（限定でなく例として、デスクトップ、ラップトップ、タブレットなど）、メディアコンピュータプラットホーム（限定でなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダ）、ハンドヘルドコンピュータデバイス（限定でなく例として、ＰＤＡ・（personal digital assistant）、電子メールクライアントなど）、ウェアラブル端末（メガネ型デバイス、時計型デバイスなど）、ＶＲ（Virtual Reality）端末、スマートスピーカ（音声認識用デバイス）、または他種のコンピュータ、またはコミュニケーションプラットホームを含む。また、端末２０は情報処理端末と表現されてもよい。

端末２０Ａ、端末２０Ｂおよび端末２０Ｃの構成は、限定ではなく例として、同一とすることができる。また、必要に応じて、ユーザＸが利用する端末を端末２０Ｘと表現し、ユーザＸまたは端末２０Ｘに対応づけられた、所定のサービスにおけるユーザ情報をユーザ情報Ｘと表現してもよいし、しなくてもよい。
なお、ユーザ情報とは、所定のサービスにおいてユーザが利用するアカウントに対応付けられたユーザの情報である。ユーザ情報は、限定でなく例として、ユーザにより入力される、または、所定のサービスにより付与される、ユーザの名前、ユーザのアイコン画像、ユーザの年齢、ユーザの性別、ユーザの住所、ユーザの趣味趣向、ユーザの識別子などのユーザに対応づけられた情報を含み、これらのいずれか一つまたは、組み合わせであってもよいし、そうでなくてもよい。

ネットワーク３０は、１以上の端末２０と、１以上のサーバ１０とを接続する役割を担う。すなわち、ネットワーク３０は、上記の各種の装置が接続した後、データを送受信することができるように接続経路を提供する通信網を意味する。

ネットワーク３０のうちの１つまたは複数の部分は、有線ネットワークや無線ネットワークであってもよいし、そうでなくてもよい。ネットワーク３０は、限定ではなく例として、アドホック・ネットワーク（ad hoc network）、イントラネット、エクストラネット、仮想プライベート・ネットワーク（virtual private network：ＶＰＮ）、ローカル・エリア・ネットワーク（local area network：ＬＡＮ）、ワイヤレスＬＡＮ（wireless LAN：ＷＬＡＮ）、広域ネットワーク（wide area network：ＷＡＮ）、ワイヤレスＷＡＮ（wireless WAN：ＷＷＡＮ）、大都市圏ネットワーク（metropolitan area network：ＭＡＮ）、インターネットの一部、公衆交換電話網（Public Switched Telephone Network：ＰＳＴＮ）の一部、携帯電話網、ＩＳＤＮ（integrated service digital networks）、無線ＬＡＮ、ＬＴＥ（long term evolution）、ＣＤＭＡ（code division multiple access）、ブルートゥース（Bluetooth（登録商標））、衛星通信など、または、これらの２つ以上の組合せを含むことができる。ネットワーク３０は、１つまたは複数のネットワーク３０を含むことができる。

サーバ１０（限定ではなく、サーバ、情報処理装置、情報管理装置の一例）は、端末２０に対して、所定のサービス（本実施例ではメッセージングサービス）を提供する機能を備える。サーバ１０は、各実施形態において記載する機能を実現できる情報処理装置であればどのような装置であってもよい。サーバ１０は、限定ではなく例として、サーバ装置、コンピュータ（限定ではなく例として、デスクトップ、ラップトップ、タブレットなど）、メディアコンピュータプラットホーム（限定ではなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダ）、ハンドヘルドコンピュータデバイス（限定ではなく例として、ＰＤＡ、電子メールクライアントなど）、あるいは他種のコンピュータ、またはコミュニケーションプラットホームを含む。また、サーバ１０は情報処理装置と表現されてもよい。サーバ１０と端末２０とを区別する必要がない場合は、サーバ１０と端末２０とは、それぞれ情報処理装置と表現されてもよいし、されなくてもよい。

［各装置のハードウェア（ＨＷ）構成］
通信システム１Ａに含まれる各装置のＨＷ構成について説明する。

（１）端末のＨＷ構成
図１－１には、端末２０のＨＷ構成の一例を示している。
端末２０は、制御部２１（ＣＰＵ：central processing unit（中央処理装置））、記憶部２８、通信Ｉ／Ｆ２２（インタフェース）、入出力部２３、時計部２９Ａ、位置算出用情報検出部２９Ｂを備える。端末２０のＨＷの各構成要素は、限定ではなく例として、バスＢを介して相互に接続される。なお、端末２０のＨＷ構成として、すべての構成要素を含むことは必須ではない。限定ではなく例として、端末２０は、個々の構成要素、または複数の構成要素を取り外すような構成であってもよいし、そうでなくてもよい。

通信Ｉ／Ｆ２２は、ネットワーク３０を介して各種データの送受信を行う。通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信Ｉ／Ｆ２２は、ネットワーク３０を介して、サーバ１０等の各種装置との通信を実行する機能を有する。通信Ｉ／Ｆ２２は、各種データを制御部２１からの指示に従って、サーバ１０等の各種装置に送信する。また、通信Ｉ／Ｆ２２は、サーバ１０等の各種装置から送信された各種データを受信し、制御部２１に伝達する。また、通信Ｉ／Ｆ２２を単に通信部と表現する場合もある。また、通信Ｉ／Ｆ２２が物理的に構造化された回路で構成される場合には、通信回路と表現する場合もある。

入出力部２３は、端末２０に対する各種操作を入力する装置や、端末２０で処理された処理結果を出力する装置等を含む。入出力部２３は、入力部と出力部が一体化していてもよいし、入力部と出力部に分離していてもよいし、そうでなくてもよい。

入力部は、ユーザからの入力を受け付けて、入力に係る情報を制御部２１に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入力部は、限定ではなく例として、タッチパネル、タッチディスプレイ、キーボード等のハードウェアキーや、マウス等のポインティングデバイス、カメラ（動画像を介した操作入力）、マイク（音声による操作入力）を含む。

出力部は、制御部２１で処理された処理結果を出力することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。出力部は、限定ではなく例として、タッチパネル、タッチディスプレイ、スピーカ（音声出力）、レンズ（限定ではなく例として３Ｄ（three dimensions）出力や、ホログラム出力）、プリンターなどを含む。

あくまでも一例であるが、入出力部２３は、限定ではなく例として、表示部２４、音入力部２５、音出力部２６、撮像部２７を備える。

表示部２４は、フレームバッファに書き込まれた表示データに従って、表示することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。表示部２４は、限定ではなく例として、タッチパネル、タッチディスプレイ、モニタ（限定ではなく例として、液晶ディスプレイやＯＥＬＤ（organic electroluminescence display））、ヘッドマウントディスプレイ（ＨＤＭ：Head Mounted Display）、プロジェクションマッピング、ホログラム、空気中など（真空であってもよいし、そうでなくてもよい）に画像やテキスト情報等を表示可能な装置を含む。なお、これらの表示部２４は、３Ｄで表示データを表示可能であってもよいし、そうでなくてもよい。

音入力部２５は、音データ（音声データを含む。以下同様。）の入力に利用される。音入力部２５は、マイクなどを含む。
音出力部２６は、音データの出力に利用される。音出力部２６は、スピーカなどを含む。
撮像部２７は、画像データ（静止画像データ、動画像データを含む。以下同様。）の取得に利用される。撮像部２７は、カメラなどを含む。

入出力部２３がタッチパネルの場合、入出力部２３と表示部２４とは、略同一の大きさおよび形状で対向して配置されていてもよい。

時計部２９Ａは、端末２０の内蔵時計であり、時刻情報（計時情報）を出力する。時計部２９Ａは、限定ではなく例として、水晶発振器を利用したクロック等を有して構成される。時計部２９Ａは、限定ではなく例として、計時部や時刻情報検出部と表現することもできる。

なお、時計部２９Ａは、ＮＩＴＺ（Network Identity and Time Zone）規格等を適用したクロックを有していてもよいし、有していなくてもよい。

位置算出用情報検出部２９Ｂは、制御部２１が自己の端末２０の位置を算出（測定）するために必要な情報（以下、「位置算出用情報」と称する。）を検出（計測）する機能部である。位置算出用情報検出部２９Ｂは、限定ではなく例として、位置算出用センサ部と表現することもできる。

位置算出用情報検出部２９Ｂは、限定ではなく例として、ＧＰＳ（Global Positioning System）等の衛星測位システムを利用して端末２０の位置を算出するためのセンサやユニットである衛星測位センサ（衛星測位ユニット）や、慣性航法システムを利用して端末２０の位置を算出するためのセンサやユニットである慣性計測センサ（慣性計測ユニット（ＩＭＵ（Inertial Measurement Unit）））、ＵＷＢ（超広帯域無線：Ultra Wide Band）を利用して端末２０の位置を算出するためのセンサやユニットであるＵＷＢ測位センサ（ＵＷＢ測位ユニット）等を含む。

衛星測位ユニットは、限定ではなく例として、不図示のアンテナで受信される測位用衛星から発信されている測位用衛星信号を含むＲＦ（Radio Frequency）信号をデジタル信号に変換するＲＦ受信回路や、ＲＦ受信回路から出力されるデジタル信号に対して相関演算処理等を行って測位用衛星信号を捕捉し、測位用衛星信号から取り出した衛星軌道データや時刻データ等の情報を、位置算出用情報として出力するベースバンド処理回路等を有する。

慣性計測ユニットは、慣性航法演算によって端末２０の位置を算出するために必要な情報を検出するセンサである慣性センサを有する。慣性センサには、限定ではなく例として、３軸の加速度センサや３軸のジャイロセンサが含まれ、加速度センサによって検出された加速度と、ジャイロセンサによって検出された角速度とを、位置算出用情報として出力する。

ＵＷＢ測位ユニットは、限定ではなく例として、不図示のアンテナで受信される測位用ビーコンから発信されている測位用超広帯域パルス信号を含む超広帯域ＲＦ（Radio Frequency）信号をデジタル信号に変換する超広帯域ＲＦ受信回路や、超広帯域ＲＦ受信回路から出力されるデジタル信号に基づいて端末２０と測位用ビーコンとの相対位置を算出する相対位置算出処理回路等を有する。
なお、限定ではなく例として、ＵＷＢ測位ユニットは、不図示のアンテナから測位用超広帯域パルス信号を含む超広帯域ＲＦ信号を送信することで、端末２０を測位用ビーコンとして機能させてもよいし、そうしなくてもよい。

制御部２１は、限定ではなく例として、位置算出用情報検出部２９Ｂによって検出された位置算出用情報に基づいて、定期的なタイミングや特定のタイミングで、自己の端末２０の位置を算出する。端末の位置を「端末位置」と称し、算出された端末位置を「算出端末位置」と称する。制御部２１は、算出端末位置を、その算出端末位置を算出した日時と関連付けて、算出端末位置履歴データとして記憶部２８に記憶させるようにしてもよいし、そうしなくてもよい。

制御部２１は、プログラム内に含まれたコードまたは命令によって実現する機能を実行するために物理的に構造化された回路を有し、限定ではなく例として、ハードウェアに内蔵されたデータ処理装置により実現される。そのため、制御部２１は、制御回路と表現されてもよいし、されなくてもよい。

制御部２１は、限定ではなく例として、中央処理装置（ＣＰＵ）、マイクロプロセッサ（microprocessor）、プロセッサコア（processor core）、マルチプロセッサ（multiprocessor）、ＡＳＩＣ（application-specific integrated circuit）、ＦＰＧＡ（field programmable gate array）を含む。

記憶部２８は、端末２０が動作するうえで必要とする各種プログラムや各種データを記憶する機能を有する。記憶部２８は、限定ではなく例として、ＨＤＤ（hard disk drive）、ＳＳＤ（solid state drive）、フラッシュメモリ、ＲＡＭ（random access memory）、ＲＯＭ（read only memory）など各種の記憶媒体を含む。また、記憶部２８は、メモリ(memory)と表現されてもよいし、されなくてもよい。

端末２０は、プログラムＰを記憶部２８に記憶し、このプログラムＰを実行することで、制御部２１が、制御部２１に含まれる各部としての処理を実行する。つまり、記憶部２８に記憶されるプログラムＰは、端末２０に、制御部２１が実行する各機能を実現させる。また、このプログラムＰは、プログラムモジュールと表現されてもよいし、されなくてもよい。

（２）サーバのＨＷ構成
図１－１には、サーバ１０のＨＷ構成の一例を示している。
サーバ１０は、制御部１１（ＣＰＵ）、記憶部１５、通信Ｉ／Ｆ１４（インタフェース）、入出力部１２、時計部１９を備える。サーバ１０のＨＷの各構成要素は、限定ではなく例として、バスＢを介して相互に接続される。なお、サーバ１０のＨＷは、サーバ１０のＨＷの構成として、全ての構成要素を含むことは必須ではない。限定ではなく例として、サーバ１０のＨＷは、個々の構成要素、または複数の構成要素を取り外すような構成であってもよいし、そうでなくてもよい。

制御部１１は、プログラム内に含まれたコードまたは命令によって実現する機能を実行するために物理的に構造化された回路を有し、限定ではなく例として、ハードウェアに内蔵されたデータ処理装置により実現される。

制御部１１は、代表的には中央処理装置（ＣＰＵ）、であり、その他にマイクロプロセッサ、プロセッサコア、マルチプロセッサ、ＡＳＩＣ、ＦＰＧＡであってもよいし、そうでなくてもよい。本開示において、制御部１１は、これらに限定されない。

記憶部１５は、サーバ１０が動作するうえで必要とする各種プログラムや各種データを記憶する機能を有する。記憶部１５は、ＨＤＤ、ＳＳＤ、フラッシュメモリなど各種の記憶媒体により実現される。ただし、本開示において、記憶部１５は、これらに限定されない。また、記憶部１５は、メモリ(memory)と表現されてもよいし、されなくてもよい。

通信Ｉ／Ｆ１４は、ネットワーク３０を介して各種データの送受信を行う。通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信Ｉ／Ｆ１４は、ネットワーク３０を介して、端末２０等の各種装置との通信を実行する機能を有する。通信Ｉ／Ｆ１４は、各種データを制御部１１からの指示に従って、端末２０等の各種装置に送信する。また、通信Ｉ／Ｆ１４は、端末２０等の各種装置から送信された各種データを受信し、制御部１１に伝達する。また、通信Ｉ／Ｆ１４を単に通信部と表現する場合もある。また、通信Ｉ／Ｆ１４が物理的に構造化された回路で構成される場合には、通信回路と表現する場合もある。

入出力部１２は、サーバ１０に対する各種操作を入力する装置や、サーバ１０で処理された処理結果を出力する装置等を含む。入出力部１２は、入力部と出力部が一体化していてもよいし、入力部と出力部に分離していてもよいし、そうでなくてもよい。

入力部は、ユーザからの入力を受け付けて、入力に係る情報を制御部１１に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入力部は、代表的にはキーボード等に代表されるハードウェアキーや、マウス等のポインティングデバイスで実現される。なお、入力部は、限定ではなく例として、タッチパネルやカメラ（動画像を介した操作入力）、マイク（音声による操作入力）を含んでいてもよいし、そうでなくてもよい。

出力部は、制御部１１で処理された処理結果を出力することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。出力部は、限定ではなく例として、 タッチパネル、タッチディスプレイ、スピーカ（音出力）、レンズ（限定ではなく例として３Ｄ（three dimensions）出力や、ホログラム出力）、プリンターなどを含む。

あくまでも一例であるが、入出力部１２は、限定ではなく例として、表示部１３を備える。

表示部１３は、ディスプレイ等で実現される。ディスプレイは、代表的にはモニタ（限定ではなく例として、液晶ディスプレイやＯＥＬＤ（organic electroluminescence display））で実現される。なお、ディスプレイは、ヘッドマウントディスプレイ（ＨＤＭ）などであってもよいし、そうでなくてもよい。なお、これらのディスプレイは、３Ｄで表示データを表示可能であってもよいし、そうでなくてもよい。本開示において、ディスプレイは、これらに限定されない。

時計部１９は、サーバ１０の内蔵時計であり、時刻情報（計時情報）を出力する。時計部１９は、限定ではなく例として、ハードウェアクロックとしてのＲＴＣ（Real Time Clock）やシステムクロック等を有して構成される。時計部１９は、限定ではなく例として、計時部や時刻情報検出部と表現することもできる。

（３）その他
サーバ１０は、プログラムＰを記憶部１５に記憶し、このプログラムＰを実行することで、制御部１１が、制御部１１に含まれる各部としての処理を実行する。つまり、記憶部１５に記憶されるプログラムＰは、サーバ１０に、制御部１１が実行する各機能を実現させる。このプログラムＰは、プログラムモジュールと表現されてもよいし、されなくてもよい。
他の装置についても同様である。

本開示の各実施形態においては、端末２０および／またはサーバ１０のＣＰＵがプログラムＰを実行することにより、実現するものとして説明する。

なお、端末２０の制御部２１、および／または、サーバ１０の制御部１１は、制御回路を有するＣＰＵだけでなく、集積回路（ＩＣ（Integrated Circuit）チップ、ＬＳＩ（Large Scale Integration））等に形成された論理回路（ハードウェア）や専用回路によって各処理を実現してもよいし、そうでなくてもよい。また、これらの回路は、１または複数の集積回路により実現されてよく、各実施形態に示す複数の処理を１つの集積回路により実現されることとしてもよいし、そうでなくてもよい。また、ＬＳＩは、集積度の違いにより、ＶＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩなどと呼称されることもある。そのため、制御部２１は、制御回路と表現されてもよいし、されなくてもよい。

また、本開示の各実施形態のプログラムＰ(限定ではなく例として、ソフトウェアプログラム、コンピュータプログラム、またはプログラムモジュール)は、コンピュータに読み取り可能な記憶媒体に記憶された状態で提供されてもよいし、されなくてもよい。記憶媒体は、「一時的でない有形の媒体」に、プログラムＰを記憶可能である。また、プログラムＰは、本開示の各実施形態の機能の一部を実現するためのものであってもよいし、そうでなくてもよい。さらに、本開示の各実施形態の機能を記憶媒体にすでに記録されているプログラムＰとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であってもよいし、そうでなくてもよい。

記憶媒体は、１つまたは複数の半導体ベースの、または他の集積回路（ＩＣ）（限定ではなく例として、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）または特定用途向けＩＣ（ＡＳＩＣ）など）、ハード・ディスク・ドライブ（ＨＤＤ）、ハイブリッド・ハード・ドライブ（ＨＨＤ）、光ディスク、光ディスクドライブ（ＯＤＤ）、光磁気ディスク、光磁気ドライブ、フロッピィ・ディスケット、フロッピィ・ディスク・ドライブ（ＦＤＤ）、磁気テープ、固体ドライブ（ＳＳＤ）、ＲＡＭドライブ、セキュア・デジタル・カード、またはドライブ、任意の他の適切な記憶媒体、またはこれらの２つ以上の適切な組合せを含むことができる。記憶媒体は、適切な場合、揮発性、不揮発性、または揮発性と不揮発性の組合せでよい。なお、記憶媒体はこれらの例に限られず、プログラムＰを記憶可能であれば、どのようなデバイスまたは媒体であってもよい。また、記憶媒体をメモリ（memory）と表現されてもよいし、されなくてもよい。

サーバ１０および／または端末２０は、記憶媒体に記憶されたプログラムＰを読み出し、読み出したプログラムＰを実行することによって、各実施形態に示す複数の機能部の機能を実現することができる。

また、本開示のプログラムＰは、プログラムを伝送可能な任意の伝送媒体(通信ネットワークや放送波等)を介して、サーバ１０および／または端末２０に提供されてもよいし、されなくてもよい。サーバ１０および／または端末２０は、限定ではなく例として、インターネット等を介してダウンロードしたプログラムＰを実行することにより、各実施形態に示す複数の機能部の機能を実現する。

また、本開示の各実施形態は、プログラムＰが電子的な伝送によって具現化されたデータ信号の形態でも実現され得る。
サーバ１０および／または端末２０における処理の少なくとも一部は、１以上のコンピュータにより構成されるクラウドコンピューティングにより実現されていてもよいし、そうでなくてもよい。
端末２０における処理の少なくとも一部、または全部を、サーバ１０により行う構成としてもよいし、そうでなくてもよい。この場合、端末２０の制御部２１の各機能部の処理のうち少なくとも一部の処理、または全部の処理を、サーバ１０で行う構成としてもよいし、そうでなくてもよい。
サーバ１０における処理の少なくとも一部、または全部を、端末２０により行う構成としてもよいし、そうでなくてもよい。この場合、サーバ１０の制御部１１の各機能部の処理のうち少なくとも一部の処理、または全部の処理を、端末２０で行う構成としてもよいし、そうでなくてもよい。

明示的な言及のない限り、本開示の実施形態における判定の構成は必須でなく、判定条件を満たした場合に所定の処理が動作されたり、判定条件を満たさない場合に所定の処理がされたりしてもよいし、そうでなくてもよい。

なお、本開示のプログラムは、限定ではなく例として、ActionScript、JavaScript(登録商標)などのスクリプト言語、Objective-C、Java(登録商標)などのコンパイラ言語、HTML Living Standardなどのマークアップ言語などを用いて実装される。

［各装置の機能構成］
（１）サーバ
図１－２は、本実施例においてサーバ１０の制御部１１によって実現される機能の一例を示す図である。
制御部１１は、限定ではなく例として、記憶部１５に記憶されたアプリケーション管理処理プログラム１５１に従ってアプリケーション処理を実行するためのアプリケーション管理処理部１１１を機能部として含む。

図１－３は、本実施例においてサーバ１０の記憶部１５に記憶される情報等の一例を示す図である。
記憶部１５には、限定ではなく例として、アプリケーション管理処理プログラム１５１と、一般アカウント登録データ１５３と、一般アカウント管理データベース１５４と、プレーヤ管理データベース１５６と、モンスター生成用テーブル１５７とが記憶される。

アプリケーション管理処理プログラム１５１は、制御部１１によって実行され、アプリケーション管理処理として実行されるプログラムである。
なお、ここでは簡明化のため１つのアプリケーション管理処理プログラム１５１として図示しているが、メッセージングアプリケーションの管理処理として実行されるプログラムと、ゲームアプリケーションの管理処理として実行されるプログラムとが含まれていてもよい。

一般アカウント登録データ１５３は、限定ではなく例として、メッセージングアプリケーションの一般アカウントに関する登録データであり、そのデータ構成の一例を図１－４に示す。
一般アカウント登録データ１５３には、限定ではなく例として、一般ユーザ名と、一般メッセージングアプリケーションＩＤ（以下、「一般ＭＡＩＤ」と称する。）と、その他登録情報とが関連付けて記憶される。

一般ユーザ名は、メッセージングアプリケーションを利用する端末２０の一般アカウントの名称であり、限定ではなく例として、端末２０のユーザがメッセージングアプリケーションを利用する際に登録する名称が記憶される。

一般ＭＡＩＤは、メッセージングアプリケーションのアカウントを識別するために用いられる情報、またはアカウントそのものである。
この一般ＭＡＩＤは、好ましくはアカウントごとに一意な値であり、限定ではなく例として、サーバ１０によってアカウントごとに一意な値（固有の値）が設定されて記憶される。
一般ＭＡＩＤは、端末２０、またはその端末２０のユーザに関連付けられた情報であり、端末に関する情報、または端末のユーザに関する情報の一例である。

その他登録情報には、限定ではなく例として、端末２０を識別するための識別情報、端末２０の電話番号やメールアドレス等の連絡先情報、アプリケーションにおける各種の認証に利用されるパスワード（ログインパスワード、認証パスワード等）等の認証情報、メッセージングアプリケーションでこの一般ユーザによって登録される自己のアイコン画像（以下、「一般ユーザアイコン画像」と称する。）といった各種の情報を含めるようにしてもよい。

端末２０を識別するための識別情報は、限定ではなく例として、端末ＩＤ（限定ではなく例として、ＩＭＥＩ（International Mobile Equipment Identity））とすることができる。

一般ＭＡＩＤは、端末２０のユーザを識別するための識別情報の一例とすることができる。一般ＭＡＩＤに代えて「一般ユーザＩＤ」としてもよいし、しなくてもよい。
また、連絡先情報も、端末２０のユーザを識別するための識別情報の一例としてもよい。

また、１つの端末２０につき１つのアカウントしか登録することのできないアプリケーションであれば、限定ではなく例として、「端末２０を識別するための識別情報＝端末２０のユーザを識別するための識別情報＝一般ＭＡＩＤ」としてもよい。

また、限定ではなく例として、１つの一般ＭＡＩＤに、複数の端末ＩＤを割り当てることを可能としてもよいし、そのようにしなくてもよい。

また、一般ＭＡＩＤ等の各種のＩＤに代えて、電話番号等の連絡先情報によってアカウントを管理する手法を適用することも可能である。
この場合、一般ＭＡＩＤ等のＩＤの情報を一般アカウント登録データ１５３に記憶させるのに代えて、電話番号等の連絡先情報を一般アカウント登録データ１５３に記憶させるようにしてもよい。

一般アカウント管理データベース１５４は、限定ではなく例として、一般アカウント登録データ１５３に記憶された各々の一般ＭＡＩＤの一般ユーザに関する情報を管理するためのデータベースである。

一般アカウント管理データベース１５４には、限定ではなく例として、一般ＭＡＩＤごとの管理データとして、一般アカウント管理データを記憶させることができる。
各々の一般アカウント管理データには、限定ではなく例として、その一般ＭＡＩＤの一般ユーザが、メッセージングアプリケーションにおいて友だちとして登録している一般ユーザの一般ＭＡＩＤ等を記憶した友だち登録データや、メッセージングアプリケーションにおけるトーク履歴データ等のデータを記憶させることができる。

プレーヤ管理データベース１５６は、限定ではなく例として、本実施例におけるゲームのプレーヤとして登録された一般ユーザに関する情報を管理するためのデータベースである。

このプレーヤ管理データベース１５６には、限定ではなく例として、プレーヤとして登録された一般ユーザにサーバ１０によって設定されるプレーヤＩＤごとの管理データとして、プレーヤ管理データを記憶させることができる。
各々のプレーヤ管理データには、限定ではなく例として、このプレーヤによって任意に登録されるプレーヤ名やパスワード、ゲームのセーブデータ、ゲームのプレイ履歴データ等のデータを含めることができる。

セーブデータには、限定ではなく例として、このプレーヤのモンスターの所有有無や、所有しているモンスターの情報、所有しているモンスターの能力値等のパラメータ値等の情報を含めることができる。

プレイ履歴データには、限定ではなく例として、このプレーヤによるモンスターの生成の履歴、所有しているモンスターの育成の履歴、モンスター同士のバトル（対戦）の履歴等の情報を含めることができる。

なお、一般ＭＡＩＤをプレーヤＩＤとして用いて、プレーヤのゲームデータを管理するようにしてもよい。

モンスター生成用テーブル１５７は、ゲームのモンスターを生成するために用いられるテーブルであり、その一例であるモンスター生成用テーブル１５７Ａのテーブル構成例を図１－５に示す。
なお、ここでは、モンスターを生成する手法として比較的簡単な手法を例示するが、これに限定されるものではない。また、ここでは、一般ＭＡＩＤのうちの少なくとも下一桁が数字であることとして説明するが、これに限定されるものではない。

モンスター生成用テーブル１５７Ａには、限定ではなく例として、ＭＡＩＤ下一桁と、モンスター種別と、モンスター外見特徴とが関連付けて定められている。

ＭＡＩＤ下一桁には、モンスターを生成する元となるＭＡＩＤの下一桁、この例では、下一桁の数字が含まれる数値範囲が設定されている。

モンスター種別には、対応するＭＡＩＤ下一桁で生成するモンスターの種別が設定されている。

モンスター外見特徴には、対応するモンスター種別のモンスターの外見の特徴が設定されている。

具体的には、このテーブルでは、ＭＡＩＤ下一桁に、限定ではなく例として、「０～３」、「４～６」、「７～９」の数値範囲が設定されている。
下一桁「０～３」には、モンスター種別として「Ｍ－Ａ（モンスターＡ）」が、モンスター外見特徴として「かっこいい」がそれぞれ設定されている。
下一桁「４～６」には、モンスター種別として「Ｍ－Ｂ（モンスターＢ）」が、モンスター外見特徴として「こわい」がそれぞれ設定されている。
下一桁「７～９」には、モンスター種別として「Ｍ－Ｃ（モンスターＣ）」が、モンスター外見特徴として「かわいい」がそれぞれ設定されている。

サーバ１０の制御部１１は、プレーヤの端末２０から受信した一般ＭＡＩＤモンスター生成要求情報に含まれる一般ＭＡＩＤに基づいて、限定ではなく例として、その一般ＭＡＩＤの下一桁の数字を特定する。そして、限定ではなく例として、特定した数字に関連付けられたモンスター種別のモンスターであって、特定した数字に関連付けられたモンスター外見特徴のモンスターを、モンスター生成プログラムによって生成する。

なお、モンスター外見特徴ばかりでなく、モンスターの色に関する情報を同様に設定しておくことで、異なる色のモンスターが生成されるようにしてもよい。また、後述するモンスターの能力値（パラメータ値）に関する情報を同様に設定しておくことで、異なる能力値のモンスターが生成されるようにしてもよい。
同じモンスター種別のモンスターであっても、外見特徴、色、能力値等のうちの少なくともいずれか１つが異なるモンスターが生成されるようにしてもよい。

また、ＭＡＩＤの下一桁に基づいてモンスターを生成するのに限らず、ＭＡＩＤの上下のいずれかの設定された桁数に基づいてモンスターを生成するなどしてもよい。
また、数字に限らず、ＭＡＩＤにアルファベットを用いることを可能とし、ＭＡＩＤに含まれるアルファベットに基づいて同様の処理を行うようにしてもよい。

なお、上記のモンスター生成用テーブル１５７Ａを、第２実施例で説明する公式アカウントに基づいてモンスターを生成する場合における公式メッセージングアプリケーションＩＤ（以下、「公式ＭＡＩＤ」と称する。）にも同様に適用してもよいし、適用しなくてもよい。

（２）端末
図１－６は、本実施例において端末２０の制御部２１によって実現される機能の一例を示す図である。
制御部２１は、限定ではなく例として、記憶部２８に記憶されたアプリケーション処理プログラム２８１に従ってゲームアプリケーション処理を実行するためのアプリケーション処理部２１１を機能部として含む。

図１－７は、本実施例において端末２０の記憶部２８に記憶される情報等の一例を示す図である。
記憶部２８には、限定ではなく例として、ゲームアプリケーション処理として実行されるアプリケーション処理プログラム２８１と、自己の端末２０、または自己の端末２０のユーザの一般ＭＡＩＤ２８３とが記憶される。

なお、一般ＭＡＩＤ２８３には、複数の一般ＭＡＩＤを記憶できるようにしてもよいし、そうしなくてもよい。

＜ゲームの説明・ゲームアプリケーション＞
ここで、本明細書のゲームアプリケーションにおけるゲームについて説明する。
本ゲームは、限定ではなく例として、主として以下の（１）～（３）に示す要素で構成されている。
（１）ゲーム内コンテンツを生成
（２）ゲーム内コンテンツを育成
（３）ゲーム内コンテンツを用いたバトル

ゲーム内コンテンツとは、ゲーム内で用いられるコンテンツであり、限定ではなく例として、ゲームに登場するオブジェクトをこれに含めることができる。本実施例では、オブジェクトの一例として、限定ではなく例として、モンスターを例示する。
オブジェクトには、基本的には、ゲームに登場するもの全般を含めることができ、モンスター以外のゲームに登場するものを含めてもよい。この具体例については後述する。

本明細書におけるゲームは、限定ではなく例として、ゲーム内コンテンツ（オブジェクト）の一種であるモンスターを生成し、生成したモンスターを育成してバトルを行うゲームとする。
なお、ゲームアプリケーションによってゲームをプレイするユーザを「プレーヤ」と称する場合がある。

（１）モンスターを生成
本ゲームでは、メッセージングアプリケーションにおいて友だち登録されている一般アカウントの一般ユーザのうち、ゲームをプレイしている（ゲームアプリケーションにおいてアカウント連携が済んでいる）一般ユーザの一般ＭＡＩＤに基づいて、モンスターが生成される（図１－１２、図１－８参照）。

なお、メッセージングアプリケーションにおいて友だち登録されている公式アカウントの公式ユーザの公式ＭＡＩＤに基づいてモンスターが生成されるようにすることも可能であるが、これについては第２実施例で説明する。

（２）モンスターを育成
本ゲームでは、生成したモンスターごとにパラメータ値（以下、適宜「能力値」と称する。）が設定されている（図１－９参照）。具体的には、パラメータ値として、限定ではなく例として、モンスターの体力（ＨＰ）を示す「体力」、モンスターの攻撃力を示す「ちから」、モンスターの守備力を示す「まもり」、モンスターの素早さを示す「はやさ」が設定されている。

また、モンスターを育成することによって、これらのモンスターのパラメータ値を上昇させることができる。具体的には、各パラメータ値を上昇させるための育成メニュー（以下、適宜「トレーニング」と称する。）が設けられており、体力を上昇させるための「体力ＵＰトレーニング」、ちから（攻撃力）を上昇させるための「ちからＵＰトレーニング」、まもり（守備力）を上昇させるための「まもりＵＰトレーニング」、はやさ（素早さ）を上昇させるための「はやさＵＰトレーニング」が設けられている。プレーヤは、モンスターに任意のトレーニングをさせることにより、モンスターのパラメータ値を上昇させることができる。

なお、本ゲームにおけるトレーニングには、限定ではなく例として、トレーニングが成功する成功パターンと、トレーニングが失敗する失敗パターンとが設けられている。成功パターンのトレーニングとは、トレーニングに成功し、トレーニングに対応したパラメータ値が上昇する。失敗パターンのトレーニングとは、トレーニングに失敗し、いずれのパラメータ値も上昇しない。

限定ではなく例として、成功パターンまたは失敗パターンのいずれのパターンのトレーニングが実行されるか（以下、「トレーニング成否」と称する。）は、トレーニングをすることに決定したタイミングで抽選により決定される。
なお、このタイミングに限らず、他のタイミングでトレーニング成否が決定されてもよい。限定ではなく例として、トレーニングの演出中にプレーヤ参加型の（プレーヤの操作を必要とする）ミニゲームを搭載し、このミニゲームの終了時にミニゲームの結果に応じてトレーニングの成否が決定されてもよい。

また、本ゲームでは、プレーヤは、モンスターにトレーニングを行わせるときに、サポートカードを利用することによって、トレーニングの効果を向上させることができる。具体的には、トレーニングの成功する確率を上昇させるサポートカードや、トレーニングが成功した場合に上昇するパラメータ値の上昇値を高くするサポートカードなどのサポートカードがあり、これらのサポートカードのうち一以上のサポートカードを用いてトレーニングを行うことによって、トレーニングの効果をより一層向上できる。

このサポートカードは、限定ではなく例として、ゲーム内においてのみ利用可能な通貨（以下、「ゲーム内通貨」と称する。）を用いて購入できるものであってもよいし、モンスターを生成するときと同様にユーザの一般ＭＡＩＤ等に基づいて獲得できるものであってもよいし、後述するバトルに勝利した場合に賞品として獲得できるものであってもよい。

（３）モンスターを用いたバトル
本ゲームでは、育成したモンスター（以下、「自分のモンスター」、「マイモンスター」と称する。）と他のユーザのモンスター（以下、「敵モンスター」と称する。）とでバトルを行うことが可能である。本ゲームでは、自分のモンスターが敵モンスターにバトルで勝利した場合、勝利演出が実行され（図１－１０（４Ａ）参照）、自分のモンスターが敵モンスターにバトルで敗北した場合、敗北演出が実行される（図１－１０（４Ｂ）参照）。

限定ではなく例として、バトルでは、モンスターのパラメータ値に基づいて勝敗が決定されてもよく、プレーヤがモンスターを操作することでバトルが進行し勝敗が決定されてもよい。
なお、バトルに勝利した場合、限定ではなく例として、ゲーム内価値が付与されてもよい。限定ではなく例として、ゲーム内価値とは、パラメータ値、ゲーム内通貨、サポートカード、他のモンスターに関連したオブジェクト（限定ではなく例として、他のモンスター自体、将来的に他のモンスターが生まれてくる卵）などである。

本ゲームでは、一のプレーヤが複数のモンスターを所持することが可能である。この場合、プレーヤが所持するモンスターのうち後述するホーム画面に表示されている一のモンスターを「メインモンスター」と称し、プレーヤが所持するモンスターのうちホーム画面に表示されておらずメインモンスターとは異なるモンスターを「サブモンスター」と称する。限定ではなく例として、ホーム画面やバトル画面においてメインモンスターを他のモンスターに切り替えることができる。

なお、上記に示した（１）～（３）の要素は、本ゲームを構成する要素の一部に過ぎず、上記に示した（１）～（３）の要素とは異なる要素も、本ゲームを構成してもよいものとする。
限定ではなく例として、本ゲームの要素として、
・設定関連の情報（お知らせ、メニュー（音量、ＢＧＭ、言語等の設定）、プレーヤに関する情報）の表示
・ゲーム内コンテンツが排出される抽選（ガチャ等）
・ゲーム内コンテンツを用いたバトル以外のミニゲーム（クエスト等）
が設けられてもよい。

＜表示画面＞
以下、本実施例における表示画面例について説明する。
まず、ゲームアプリケーションにおいて、一般ユーザの友だちからモンスターを生成する場合を例示する。

以下では、限定ではなく例として、端末２０Ａに備えられたディスプレイの表示部２４が、横長の表示画面となるように端末２０Ａを位置させている場合を例示する。

なお、以下説明する表示画面の遷移は、本開示の手法を実現するための表示画面の遷移の一例に過ぎない。以下に例示する表示画面の遷移について、一部の表示画面の表示を省略してもよいし、別の表示画面を追加してもよい。

図１－８は、本実施例において端末２０Ａの表示部２４に表示されるゲームアプリケーションの画面の一例を示す図である。ここでは、ユーザＡ．Ａの端末２０Ａの表示部２４に表示される画面（ホーム画面、生成画面）を例示する。

図１－８（１）は、ゲームアプリケーションのホーム画面であり、画面最上部の左部には、ゲームアプリケーションの名称として「Ｇａｍｅ Ａｐｐ」の文字が表示されている。
また、この例では、「Ｇａｍｅ Ａｐｐ」の文字の左に、このゲームがメッセージングサービス（メッセージングアプリケーション）と関連したゲームであることを示す「ＭＳ（Messaging Service）」の文字を含むアイコンが表示されている。

また、画面最上部の右部には、ゲームアプリケーションにおいてホーム画面に戻るためのホームボタンＨＢＴと、ゲームアプリケーションにおいてお知らせを確認するためのお知らせボタンＮＢＴと、ゲームアプリケーションにおいてメニューを表示するためのメニューボタンＭＢＴと、この端末２０Ａのユーザのゲームアプリケーションにおけるアイコン画像（この例では「ユーザＡ．Ａ」）とが表示されている。

また、その下には、ゲームアプリケーション内で現在表示されているページ等を示す領域（以下、「アプリ内位置表示領域」と称する。）が構成され、この画面はホーム画面であるため「ホーム」と表示されている。

また、その下には、ゲームアプリケーションにおける各種の情報（以下、「ゲーム情報」と称する。）が表示されるゲーム情報表示領域が構成されている。ここでゲーム情報とは、限定ではなく例として、後述するホーム画面、生成画面、育成画面、バトル画面に関連する情報（限定ではなく例として、モンスター、能力値情報、各種ボタンなど）である。この例では、ゲーム情報表示領域には、モンスター（本例では、モンスターＡ）と、このモンスターのパラメータ値に関するパラメータ値情報（本例では、モンスターの名称として「モンスターＡ」、各能力値として「体力｜５０」、「ちから｜４０」、「まもり｜３０」、「はやさ｜４０」）と、ホーム画面に表示するモンスター（メインモンスター）を切り替えるためのモンスター変更ボタンＣＢＴと、モンスターを育成するための育成ボタンＴＢＴと、モンスターにバトルさせるためのバトルボタンＢＢＴと、モンスターを生成するための生成ボタンＧＢＴとが表示されている。

限定ではなく例として、図１－８（１）のように、生成ボタンＧＢＴがユーザによってタッチされると、限定ではなく例として、図１－８（２）のような表示がなされる。
この画面は、モンスターを生成するための生成画面のうち第１生成画面であり、アプリ内位置表示領域には「生成ステージ」の文字が表示されている。

その下には、モンスターの生成に関する情報が示される生成情報表示領域が構成されている。
この例では、第１Ａ生成確認情報（限定ではなく例として、「友だちからモンスターを生成しますか？」の文字）と、上記の情報に対して［ＹＥＳ］と答えるためのＹＥＳボタンＢＴ１（本例では、「はい」の文字を含むボタン）と、上記の情報に対して［ＮＯ］と答えるためのＮＯボタンＢＴ２（本例では、「いいえ」の文字を含むボタン）とが表示されている。

限定ではなく例として、図１－８（２）のように、ＹＥＳボタンＢＴ１がユーザによってタッチされると、限定ではなく例として、図１－８（３）のような表示がなされる。
この画面は、モンスターを生成するための生成画面のうち第２生成画面であり、アプリ内位置表示領域には「生成ステージ」の文字が継続して表示されている。

この例では、生成情報表示領域には、メッセージングサービス（メッセージングアプリケーション）における、この端末２０ＡのユーザＡ．Ａの友だち（ユーザＡ．Ａのアカウントの友だちとして登録されているアカウント）に関する情報が一覧表示される「友だちリスト」が表示されるように構成されている。
この画面では、友だちリストの項目として、ユーザＢ．Ｂに対応したアイコンおよびユーザ名、ユーザＣ．Ｃに対応したアイコンおよびユーザ名等が一覧表示されている。また、これらの各友だちリスト項目の右部には、その友だちリスト項目に対応した友だちを用いてモンスターを生成するための生成実行ボタンＭＧＢＴ（本例では「モンスター生成」の文字を含むボタン）が表示されている。

限定ではなく例として、図１－８（３）のように、生成実行ボタンＭＧＢＴがユーザによってタッチされると、限定ではなく例として、図１－８（４）のような表示がなされる。
この画面では、図１－８（３）の第２生成画面に重畳して、モンスター生成を行うことを確認するための生成確認領域ＭＧＲが表示されている。

生成確認領域ＭＧＲには、第２Ａ生成確認情報（本例では、「Ｂ．Ｂからモンスターを生成しますか？」の文字）と、上記の情報に対して［ＹＥＳ］と答えるためのＹＥＳボタンＢＴ１と、上記の情報に対して［ＮＯ］と答えるためのＮＯボタンＢＴ２とが表示されている。

限定ではなく例として、図１－８（４）のように、ＹＥＳボタンＢＴ１がユーザによってタッチされると、限定ではなく例として、図１－８（５）のような表示がなされる。
この画面は、モンスターを生成するための生成画面のうち第３生成画面であり、アプリ内位置表示領域には「生成ステージ」の文字が継続して表示されている。

この画面では、第２生成画面において選択した友だちからモンスターが生成される演出（以下、「生成演出」と称する。）が実行される。
具体的には、生成演出が実行されると、画面中央に生成エフェクト情報（本例では、煙型のエフェクト画像）が表示されている。この生成エフェクト情報が表示されることによって、いずれのモンスターが生成されるかをユーザに期待させることができる。

限定ではなく例として、生成演出が終了されると、限定ではなく例として、図１－８（６）のような表示がなされる。
この画面は、モンスターを生成するための生成画面のうち第４生成画面であり、アプリ内位置表示領域には「生成ステージ」の文字が継続して表示されている。

ゲーム情報表示領域には、ゲーム情報（限定ではなく例として、新たに生成されたモンスター情報（本例では、モンスターＢ）、このモンスターのパラメータ値情報（本例では、モンスターの名称として「モンスターＢ」、各能力値として「体力｜１０」、「ちから｜１０」、「まもり｜２０」、「はやさ｜５」）が表示されている。

このように、プレーヤが任意に選択した友だちからモンスターが生成されることによって、様々な種類のモンスターを生成することができるとともに、メッセージングアプリケーションの友だちとモンスターとが関連づけられることによって、モンスターを用いるゲーム性を有する本ゲームの興趣を向上できる。

次に、ゲームアプリケーションにおいてモンスターを育成する例について例示する。

図１－９は、本実施例において端末２０Ａの表示部２４に表示されるゲームアプリケーションの画面の一例を示す図である。ここでは、ユーザＡ．Ａの端末２０Ａの表示部２４に表示される画面（ホーム画面、育成画面）を例示する。

図１－９（１）における表示画面については、前述した図１－８（１）と同様であるので説明を省略する。

限定ではなく例として、図１－９（１）のように、育成ボタンＴＢＴがユーザによってタッチされると、限定ではなく例として、図１－９（２）のような表示がなされる。
この画面は、モンスターを育成するための育成画面のうち第１育成画面であり、アプリ内位置表示領域には「育成ステージ」の文字が表示されている。

その下には、モンスターの育成に関する情報が示される育成情報表示領域が構成されている。
この例では、育成情報表示領域には、第１育成情報（限定ではなく例として、「どのトレーニングにしますか？」の文字と、体力ＵＰトレーニングに対応した第１トレーニングアイコン（本例では、「体力ＵＰ」の文字を含むアイコン）と、ちからＵＰトレーニングに対応した第２トレーニングアイコン（本例では、「ちからＵＰ」の文字を含むアイコン）と、まもりＵＰトレーニングに対応した第３トレーニングアイコン（本例では、「まもりＵＰ」の文字を含むアイコン）と、はやさＵＰトレーニングに対応した第４トレーニングアイコン（本例では、「はやさＵＰ」の文字を含むアイコン）と、いずれのトレーニングも行わずにモンスターを休息させるための休むアイコン（本例では、「やすむ」の文字を含むアイコン）と、モンスターの育成をやめるためのアイコン（本例では、「トレーニングをやめる」の文字を含むアイコン））が表示されている。

限定ではなく例として、図１－９（２）のように、第１トレーニングアイコンＴＩＣ１がユーザによってタッチされると、限定ではなく例として、図１－９（３）のような表示がなされる。
この画面は、モンスターを育成するための育成画面のうち第２育成画面であり、アプリ内位置表示領域には「育成ステージ」の文字が継続して表示されている。

この例では、育成情報表示領域には、第２育成情報（限定ではなく例として、第１育成画面においてユーザが選択したトレーニング内容に対応した情報（本例では、「＜体力ＵＰトレーニング＞」の文字）と、「どのサポートカードを使いますか？」の文字と、サポートカード情報（本例では、「成功率ＵＰ」の文字を含むサポートカードＳＣ１、「上昇値ＵＰ」の文字を含むサポートカードＳＣ２などのサポートカードの画像）と、いずれのサポートカードも使用せずにトレーニングするための情報（本例では、「サポートカードは使わない」の文字を含むアイコン））が表示されている。

限定ではなく例として、図１－９（３）のように、サポートカードＳＣ１がユーザによってタッチされると、限定ではなく例として、図１－９（４）のような表示がなされる。
この画面は、モンスターを育成するための育成画面のうち第３育成画面であり、アプリ内位置表示領域には「育成ステージ」の文字が継続して表示されている。

この例では、育成情報表示領域には、第３育成情報（限定ではなく例として、「このトレーニングを開始しますか？」の文字と、第１育成画面と第２育成画面においてユーザが選択したトレーニング内容とサポートカードに対応した情報（本例では、第１トレーニングアイコンＴＩＣ１とサポートカードＳＣ１）と、上記の情報に対して［ＹＥＳ］と答えるためのＹＥＳボタンＢＴ１と、上記の情報に対して［ＮＯ］と答えるためのＮＯボタンＢＴ２）が表示されている。

限定ではなく例として、図１－９（４）のように、ＹＥＳボタンＢＴ１がユーザによってタッチされると、限定ではなく例として、図１－９（５）のような表示がなされる。
この画面は、モンスターを育成するための育成画面のうち第４育成画面であり、アプリ内位置表示領域には「育成ステージ」の文字が継続して表示されている。

この例では、育成情報表示領域には、第４育成情報（限定ではなく例として、「トレーニング開始」の文字と、第１育成画面と第２育成画面においてユーザが選択したトレーニング内容とサポートカードに対応した情報（本例では、第１トレーニングアイコンＴＩＣ１とサポートカードＳＣ１））が表示されている。

限定ではなく例として、トレーニング成否が報知されるべきタイミングになると、限定ではなく例として、図１－９（６Ａ）または（６Ｂ）のような表示がなされる。
限定ではなく例として、成功パターンである場合、図１－９（６Ａ）のような表示がなされ、失敗パターンである場合、図１－９（６Ｂ）のような表示がなされる。

（成功パターン）
図１－９（６Ａ）の画面は、モンスターを育成するための育成画面のうち第５Ａ育成画面であり、アプリ内位置表示領域には「育成ステージ」の文字が継続して表示されている。
この例では、育成情報表示領域には、第５Ａ育成情報（限定ではなく例として、「トレーニング成功」の文字と、喜んだ表情のモンスターＡと、このトレーニングでのパラメータ値の上昇値情報（本例では、「体力｜＋３」の文字））が表示されている。

（失敗パターン）
図１－９（６Ｂ）の画面は、モンスターを育成するための育成画面のうち第５Ｂ育成画面であり、アプリ内位置表示領域には「育成ステージ」の文字が継続して表示されている。
この例では、育成情報表示領域には、第５Ｂ育成情報（限定ではなく例として、「トレーニング失敗」の文字と、残念な表情のモンスターＡ）が表示されている。

次に、ゲームアプリケーションにおいてモンスターを用いてバトルする例について例示する。

図１－１０は、本実施例において端末２０Ａの表示部２４に表示されるゲームアプリケーションの画面の一例を示す図である。ここでは、ユーザＡ．Ａの端末２０Ａの表示部２４に表示される画面（ホーム画面、バトル画面）を例示する。

図１－１０（１）における表示画面については、前述した図１－８（１）と同様であるので説明を省略する。

限定ではなく例として、図１－１０（１）のように、バトルボタンＢＢＴがユーザによってタッチされると、限定ではなく例として、図１－１０（２）のような表示がなされる。
この画面は、モンスターを用いてバトルするためのバトル画面のうち第１バトル画面であり、アプリ内位置表示領域には「バトルステージ」の文字が表示されている。

その下には、モンスターのバトルに関する情報が示されるバトル情報表示領域が構成されている。
この例では、バトル情報表示領域には、第１バトル情報（限定ではなく例として、「このモンスターでバトルに挑戦しますか？」の文字と、メインモンスターに設定されているモンスター（本例ではモンスターＡ）と、パラメータ値情報（本例では、モンスターの名称として「モンスターＡ」、各能力値として「体力｜５０」、「ちから｜４０」、「まもり｜３０」、「はやさ｜４０」）と、上記の情報に対して［ＹＥＳ］と答えるためのＹＥＳボタンＢＴ１と、モンスター変更ボタンＣＢＴ）が表示されている。

限定ではなく例として、図１－１０（２）のように、ＹＥＳボタンＢＴ１がユーザによってタッチされると、限定ではなく例として、図１－１０（３）のような表示がなされる。
この画面は、モンスターを用いてバトルするためのバトル画面のうち第２バトル画面であり、アプリ内位置表示領域には「バトルステージ」の文字が継続して表示されている。

この例では、バトル情報表示領域には、第２バトル情報（限定ではなく例として、プレーヤ側のモンスター情報（本例では、モンスターＡと、ユーザＡ．Ａの名前とアイコン画像）、「ＶＳ」の文字と、敵プレーヤ側のモンスター情報（本例では、モンスターＢと、ユーザＢ．Ｂの名前とアイコン画像））が表示されている。

限定ではなく例として、バトルが開始し、勝敗結果が報知されるべきタイミングになると、限定ではなく例として、図１－１０（４Ａ）または（４Ｂ）のような表示がなされる。
限定ではなく例として、自分のモンスターが敵モンスターに勝利する場合、図１－１０（４Ａ）のような表示がなされ、自分のモンスターが敵モンスターに敗北する場合、図１－１０（４Ｂ）のような表示がなされる。

（勝利演出）
図１－１０（４Ａ）の画面は、モンスターを用いてバトルするためのバトル画面のうち第３Ａバトル画面であり、アプリ内位置表示領域には「バトルステージ」の文字が継続して表示されている。
この例では、勝利演出が実行されており、バトル情報表示領域には、第３Ａバトル情報（限定ではなく例として、「ＷＩＮ」の文字と、喜んだ表情のモンスターＡ）が表示されている。

（敗北演出）
図１－１０（４Ｂ）の画面は、モンスターを用いてバトルするためのバトル画面のうち第３Ｂバトル画面であり、アプリ内位置表示領域には「バトルステージ」の文字が継続して表示されている。
この例では、敗北演出が実行されており、バトル情報表示領域には、第３Ｂバトル情報（限定ではなく例として、「ＬＯＳＥ」の文字と、残念な表情のモンスターＡ）が表示されている。

＜処理＞
図１－１１～図１－１２は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左側から順に、端末２０Ａ（一般ユーザＡ．Ａの端末２０）の制御部２１が実行する処理、サーバ１０の制御部１１が実行する処理の一例を示している。

なお、この処理は、本開示の手法を実現するための処理の一例に過ぎず、この処理に限定されるものではない。この処理に別のステップを追加してもよいし、この処理から一部のステップを省略（削除）してもよい。
これは、以下説明する各フローチャート（処理）について同様である。

まず、端末２０Ａの制御部２１は、限定ではなく例として、端末２０Ａの入出力部２３に対するユーザによる入力（以下、「ユーザ入力」と称する。限定ではなく例として、操作による入力、音による入力、振動による入力等を含む。以下同様。）に基づいてゲームアプリケーションを起動する。そして、その起動が、ゲームアプリケーションの初回起動であるか否かを判定する（Ａ１１０）。

初回起動であると判定したならば（Ａ１１０：ＹＥＳ）、端末２０Ａの制御部２１は、限定ではなく例として、記憶部２８に記憶された一般ＭＡＩＤ２８３を含むアカウント連携要求情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ１２０）。

一方、初回起動ではないと判定したならば（Ａ１１０：ＮＯ）、端末２０Ａの制御部２１は、Ａ１２０のステップをスキップし、Ａ１３０のステップに処理を進める。

通信Ｉ／Ｆ１４によって端末２０Ａからアカウント連携要求情報を受信すると、サーバ１０の制御部１１は、アカウント連携処理を行う（Ｓ１１０）。具体的には、限定ではなく例として、受信したアカウント連携要求情報に含まれる一般ＭＡＩＤ２８３（この例では、ユーザＡ．Ａの一般ＭＡＩＤ）に対応するゲーム用のＩＤ（以下、「ゲーム用ＩＤ」と称する。）を生成する。
なお、詳細は後述するが、このタイミングでゲーム用ＩＤを生成しないようにすることも可能である。

ゲーム用ＩＤは、限定ではなく例として、一般ＭＡＩＤから、ユーザごとに一意であるがそのユーザ個人を特定することのできないＩＤ（限定ではなく例として、不可逆なＩＤ）として生成することができる。限定ではなく例として、一般ＭＡＩＤをハッシュするなどしてゲーム用ＩＤを生成するようにすることができる。
そして、サーバ１０の制御部１１は、生成したゲーム用ＩＤ（この例では、ユーザＡ．Ａのゲーム用ＩＤ）を、限定ではなく例として、一般アカウント管理データベース１５５における、ユーザＡ．Ａの一般ＭＡＩＤが記憶された一般アカウント管理データに、一般ＭＡＩＤと関連付けて記憶させる。

また、サーバ１０の制御部１１は、ユーザＡ．ＡのプレーヤＩＤとして、限定ではなく例としてランダムなＩＤを生成し、限定ではなく例として、プレーヤＩＤ（この例では、ユーザＡ．ＡのプレーヤＩＤ）とゲーム用ＩＤ（この例では、ユーザＡ．Ａのゲーム用ＩＤ）とを関連付けて記憶したプレーヤ管理データを生成して、記憶部１５のプレーヤ管理データベース１５６に記憶させる。

次いで、サーバ１０の制御部１１は、限定ではなく例として、アカウント連携が完了したことを示すアカウント連携情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ１２０）。

Ａ１２０のステップの後、通信Ｉ／Ｆ２２によってアカウント連携情報を受信した場合、端末２０Ａの制御部２１は、受信したアカウント連携情報を記憶部２８に記憶させる。

次いで、端末２０Ａの制御部２１は、メッセージングアプリケーションにおいて、ユーザＡ．Ａの一般ＭＡＩＤの友だちとして登録されている一般ユーザの一般アカウントに関する情報の一覧を要求する友だち一覧要求情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ１３０）。

Ｓ１２０のステップの後、通信Ｉ／Ｆ１４によって端末２０Ａから友だち一覧要求情報を受信すると、サーバ１０の制御部１１は、記憶部１５に記憶された一般アカウント管理データベース１５５のうち、ユーザＡ．Ａの一般ＭＡＩＤが記憶された一般アカウント管理データに含まれる友だち登録データに基づいて、ユーザＡ．Ａの友だちの一般ＭＡＩＤを特定する。そして、一般アカウント登録データ１５３を参照し、特定した友だちの一般ＭＡＩＤに関連付けて記憶された一般ユーザ名や一般ユーザアイコン画像等の情報を読み出す。そして、限定ではなく例として、友だちの一般ＭＡＩＤ、一般ユーザ名、一般ユーザアイコン画像等の情報を含む友だち一覧情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ１３０）。

Ａ１３０のステップの後、通信Ｉ／Ｆ２２によってサーバ１０から友だち一覧情報を受信すると、端末２０Ａの制御部２１は、受信した友だち一覧情報を記憶部２８に記憶させる。

その後、端末２０Ａとサーバ１０との間で、ゲーム処理が開始される（Ａ１４０、Ｓ１４０）。本明細書で説明するゲーム処理では、限定ではなく例として、前述したように、モンスターの生成、モンスターの育成、モンスター同士のバトル等を実現するための処理が含まれる。
なお、モンスターの生成に関するステップを、便宜的に、ゲーム処理が開始された後のステップとして図１－１２に図示・説明するが、このモンスターの生成に関するステップもゲーム処理のステップに含めてもよい（ゲーム処理の一部としてもよい）。

ゲーム処理では、サーバ１０の制御部１１は、ゲームの進行に応じて、記憶部１５のプレーヤ管理データベース１５６のうち、このプレーヤのプレーヤ管理データを更新する。

ゲーム処理が開始された後、端末２０Ａの制御部２１は、モンスターを生成するユーザ入力が入出力部２３を介してなされたか否かを判定するなどすることによって、モンスターを生成するか否かを判定する（Ａ１５０）。

モンスターを生成すると判定したならば（Ａ１５０：ＹＥＳ）、端末２０Ａの制御部２１は、先だってサーバ１０から取得して記憶部２８に記憶した友だち一覧情報を記憶部２８から読み出す。そして、端末２０Ａの制御部２１は、限定ではなく例として、各々の友だちの一般ユーザ名や一般ユーザアイコン画像、モンスター生成ボタン等を含む友だちリストを表示部２４に表示させる（Ａ１６０）。

次いで、端末２０Ａの制御部２１は、表示した友だち一覧の中から友だちを選択するユーザ入力がなされたか否かを判定するなどすることによって、一般ＭＡＩＤに基づいてモンスターを生成するか否かを判定する（Ａ１７０）。

一般ＭＡＩＤに基づいてモンスターを生成すると判定したならば（Ａ１７０：ＹＥＳ）、端末２０Ａの制御部２１は、限定ではなく例として、ユーザＡ．Ａによって選択された友だちの一般ＭＡＩＤを含む一般ＭＡＩＤモンスター生成要求情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ１８０）。

Ｓ１４０のステップの後、通信Ｉ／Ｆ１４によって端末２０Ａから一般ＭＡＩＤモンスター生成要求情報を受信すると、サーバ１０の制御部１１は、一般ＭＡＩＤモンスター生成処理を行う（Ｓ１８０）。具体的には、限定ではなく例として、前述したモンスター生成用テーブル１５７Ａに基づいて、モンスター生成プログラムに従って、端末２０Ａから受信した一般ＭＡＩＤモンスター生成要求情報に含まれる一般ＭＡＩＤ（ユーザＡ．Ａによって選択された友だちの一般ＭＡＩＤ）に対応するモンスターを生成する。そして、生成したモンスターに関する情報を、ユーザＡ．ＡのプレーヤＩＤが記憶されたプレーヤ管理データに記憶させる。

図１－１１に戻り、Ｓ１８０のステップの後、サーバ１０の制御部１１は、Ｓ１８０のステップで生成したモンスターに関する情報を含む一般ＭＡＩＤモンスター生成結果情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ１９０）。

Ａ１８０のステップの後、通信Ｉ／Ｆ２２によってサーバ１０から一般ＭＡＩＤモンスター生成結果情報を受信すると、端末２０Ａの制御部２１は、受信した一般ＭＡＩＤモンスター生成結果情報に基づいて、一般ＭＡＩＤモンスター生成結果情報を表示部２４に表示させる（Ａ１９０）。

次いで、端末２０Ａの制御部２１は、ゲームアプリケーションの処理を終了するか否かを判定する（Ａ１９５）。
処理を継続すると判定したならば（Ａ１９５：ＮＯ）、端末２０Ａの制御部２１は、限定ではなく例として、Ａ１５０に処理を戻す。
一方、処理を終了すると判定したならば（Ａ１９５：ＹＥＳ）、端末２０Ａの制御部２１は、実行中のゲーム処理を終了し、ゲームアプリケーションの処理を終了する。

Ｓ１９０のステップの後、サーバ１０の制御部１１は、ゲームアプリケーションの管理処理を終了するか否かを判定する（Ｓ１９５）。
処理を継続すると判定したならば（Ｓ１９５：ＮＯ）、サーバ１０の制御部１１は、限定ではなく例として、端末２０Ａからの一般ＭＡＩＤモンスター生成要求情報の受信を待機し、受信した場合は、再びＳ１８０の処理を実行する。
一方、処理を終了すると判定したならば（Ｓ１９５：ＹＥＳ）、サーバ１０の制御部１１は、実行中のゲーム処理を終了し、ゲームアプリケーションの管理処理を終了する。

＜ゲーム用ＩＤに関して＞
メッセージングアプリケーションで用いられる一般ＭＡＩＤは、ユーザによっては個人情報の１つであり、ユーザにとっても、メッセージングサービス事業者にとっても、重要な情報であると言える。このため、メッセージングアプリケーションの一般ＭＡＩＤが特定されてしまうようなリスクは回避する必要がある。
上記のように一般ＭＡＩＤを用いてモンスターを生成するようにする場合、限定ではなく例として、多数のモンスターを参照してモンスターの生成の規則性（生成ルール）を読み解くことで、第三者によってモンスターから一般ＭＡＩＤが推測されてしまうリスクがある。

そこで、限定ではなく例として、サーバ１０の制御部１１が、Ｓ１８０のステップにおいて、端末２０Ａから受信した一般ＭＡＩＤモンスター生成要求情報に含まれる一般ＭＡＩＤ（ユーザＡ．Ａによって選択された友だちの一般ＭＡＩＤ）に対応するモンスターを、その一般ＭＡＩＤに対応するゲーム用ＩＤに基づいて生成するようにしてもよい。
この場合、限定ではなく例として、図１－５に示したモンスター生成用テーブル１５７Ａの「ＩＤ下一桁」をゲーム用ＩＤの下一桁として用いて、同様の手法でモンスターを生成するようにすることができる。具体的には、サーバ１０の制御部１１は、上記の一般ＭＡＩＤからゲーム用ＩＤを生成し（生成済みである場合はそのゲーム用ＩＤを読み出し）、そのゲーム用ＩＤに基づいてモンスターを生成するようにすることができる。

また、限定ではなく例として、サーバ１０の制御部１１が、Ｓ１３０のステップにおいて、友だちの一般ＭＡＩＤに代えて、友だちのゲーム用ＩＤを友だち一覧情報に含めて端末２０Ａに送信するようにしてもよい。
また、この場合、限定ではなく例として、端末２０Ａの制御部２１が、Ｓ１３０のステップにおいて、ユーザＡ．Ａによって選択された友だちに対応するゲーム用ＩＤを一般ＭＡＩＤモンスター生成要求情報に含めてサーバ１０に送信するようにしてもよい。

また、サーバ１０の制御部１１が、各々の端末２０について、Ｓ１１０のステップのアカウント連携処理でゲーム用ＩＤを生成しないようにしてもよい。
友だちのゲーム用ＩＤも生成されないことになるが、この場合、サーバ１０の制御部１１は、Ｓ１８０のステップにおいて、端末２０Ａから受信した一般ＭＡＩＤモンスター生成要求情報に含まれる一般ＭＡＩＤ（ユーザＡ．Ａによって選択された友だちの一般ＭＡＩＤ）からゲーム用ＩＤを生成し、生成したゲーム用ＩＤに基づいてモンスターを生成するようにしてもよい。つまり、端末２０からモンスターの生成が要求された際に、サーバ１０の制御部１１が、その友だちのゲーム用ＩＤを生成して、モンスターを生成するようにしてもよい。

また、ゲーム用ＩＤに代えて、プレーヤＩＤを用いて、上記と同様の処理を行うようにしてもよい。

＜友だち一覧に関して＞
上記の処理において、サーバ１０の制御部１１が、メッセージングアプリケーションにおいて友だちとして登録されている全ての一般アカウントに関する情報ではなく、一部の一般アカウントに関する情報を友だち一覧情報に含めて端末２０Ａに送信するようにしてもよい。

メッセージングアプリケーションにおいて友だちとして登録されている全ての一般アカウントのユーザがこのゲームをプレイしているとは限らない。このため、ゲームをプレイしていないユーザの一般アカウントをモンスターの生成に用いることは好ましくない場合があり得る。
そこで、限定ではなく例として、サーバ１０の制御部１１が、Ｓ１３０のステップにおいて、ユーザＡ．Ａの友だちの一般アカウントのうち、このゲームのアカウント連携処理を実行済みの友だち、つまり、このゲームのプレーヤとして登録済みの友だちのみを対象として、その友だちの一般アカウントに関する情報を友だち一覧情報に含めて端末２０Ａに送信するようにしてもよい。

また、サーバ１０の制御部１１が、限定ではなく例として、メッセージングアプリケーションにおいて、各々の一般ユーザの端末２０に対して、その一般ユーザが登録している友だちが、ゲームアプリケーションにおいて自分のアカウントを使用することを許諾（承諾）するか否かを確認する使用許諾確認情報を端末２０に送信し、その使用許諾確認情報に対する回答を端末２０から受信するようにする。そして、限定ではなく例として、Ｓ１３０のステップにおいて、サーバ１０の制御部１１が、ユーザＡ．Ａの友だちのうち、使用許諾の回答が「ＯＫ」であった友だちのみを対象として、その友だちの一般アカウントに関する情報を友だち一覧情報に含めて端末２０Ａに送信するようにしてもよい。

また、サーバ１０の制御部１１が、端末２０ＡのユーザＡ．Ａがメッセージングアプリケーションにおいてメッセージのやり取りを行う回数が多い、または頻度が高い友だちを特定する。そして、特定した友だちのみを対象として、その友だちの一般アカウントに関する情報を友だち一覧情報に含めて端末２０Ａに送信するようにしてもよい。

また、端末２０ＡのユーザＡ．Ａが、メッセージングアプリケーション、またはゲームアプリケーションにおいて、モンスターの生成に用いる候補とする友だちを事前に選んで設定できるようにし、サーバ１０の制御部１１が、ユーザＡ．Ａによって設定された友だちのみを対象として、その友だちの一般アカウントに関する情報を友だち一覧情報に含めて端末２０Ａに送信するようにしてもよい。

また、上記の処理では、端末２０Ａの制御部２１が、Ａ１２０のステップの後に、友だち一覧要求情報をサーバ１０に送信するステップ（Ａ１３０）を行うこととしたが、これに限定されない。
限定ではなく例として、Ａ１５０のステップにおいてモンスターを生成すると判定した場合に（Ａ１５０：ＹＥＳ）、端末２０Ａの制御部２１が、友だち一覧要求情報をサーバ１０に送信するようにしてもよい。そして、サーバ１０の制御部１１が、受信した友だち一覧要求情報に基づいて友だち一覧情報を端末２０Ａに送信し、端末２０Ａの制御部２１が、受信した友だち一覧情報に基づいて、Ａ１６０のステップを行うようにしてもよい。

＜モンスターの生成に関して＞
また、サーバ１０の制御部１１が、一の一般アカウントに基づいてモンスターを生成した後は、同じ一般アカウントに基づいてモンスターを生成する要求が端末２０Ａからなされた場合であっても、モンスターを生成しないようにしてもよい。

また、端末２０Ａの制御部２１が、Ａ１６０のステップで友だちリストを表示する場合に、一度モンスターを生成した友だちについては、モンスター生成ボタンをグレーアウトして表示させるなどし、モンスター生成ボタンに対するユーザ入力を受け付けないようにしてもよい。この場合は、モンスター生成要求情報がサーバ１０に送信されないため、結果として、サーバ１０によってモンスターは生成されない。

また、サーバ１０の制御部１１が、一の一般アカウントに基づいてモンスターを生成した後、同じ一般アカウントに基づいてモンスターを生成する要求が端末２０Ａからなされた場合、限定ではなく例として、サーバ１０によって異なるモンスターが生成されるようにしてもよい。１つの手法として、一般ＭＡＩＤ（ゲーム用ＩＤ）に加えて、またはこれに代えて、時間に関する情報や友だちの属性情報等の情報に基づいて、サーバ１０の制御部１１がモンスターを生成するようにしてもよい。なお、たまたま同じモンスターが生成される場合もあり得るが、それは許容してもよい。

＜第１実施例の効果＞
本実施例は、サーバ１０（限定ではなく、サーバの一例）と通信し、ゲーム処理等のゲームに関する処理を行う端末２０（限定ではなく、端末の一例）が、メッセージングサービス（限定ではなく、ＳＮＳの一例）で端末２０のユーザのアカウントと友だちとして登録されている一のアカウント（限定ではなく、端末のユーザのアカウントと関連付けられた第１アカウント）に関する情報を表示部２４に表示する。そして、端末２０は、表示部２４に表示された、一のアカウントに関する情報に対する自己の端末２０のユーザによる入力に基づいて、一のアカウントに基づく、モンスター生成要求情報等の情報（限定ではなく、ゲームに登場するオブジェクトを要求するための第１情報の一例）を通信Ｉ／Ｆ２２によってサーバ１０に送信する。そして、端末２０は、モンスター生成要求情報を送信したことに基づいて、ゲームに登場するモンスターであって、一のアカウントに基づくモンスター（限定ではなく、第１アカウントに基づく第１オブジェクトの一例）に関する情報（限定ではなく、第２情報の一例）を通信Ｉ／Ｆ２２によって受信する。そして、端末２０は、受信した情報に基づき、モンスター（限定ではなく、第１オブジェクトの一例）を表示部２４に表示する構成を示している。
このような構成により得られる実施例の効果の一例として、端末が、ＳＮＳで端末のユーザのアカウントと関連付けられた第１アカウントに基づく第１オブジェクトに関する情報をサーバから受信した上で、第１オブジェクトを表示部に表示することができる。これにより、限定ではなく例として、ゲームにおいて、ＳＮＳにおいて自分のアカウントと関連付けられた他のアカウントに基づくモンスターを取得してゲームで利用するといったことが可能となり、ゲームの興趣が向上する。

また、この場合、端末２０は、メッセージングサービス（限定ではなく、ＳＮＳの一例）で端末２０のユーザのアカウントと友だちとして登録されている、上記の一のアカウント（限定ではなく、第１アカウントの一例）とは異なる他のアカウント（限定ではなく、第２アカウントの一例）に関する情報を表示部２４に表示する。そして、端末２０は、表示部２４に表示された、他のアカウントに関する情報に対する自己の端末２０のユーザによる入力に基づいて、他のアカウントに基づく、上記のモンスター生成要求情報等の情報（限定ではなく、第１情報の一例）を通信Ｉ／Ｆ２２によってサーバ１０に送信する。そして、端末２０は、モンスター生成要求情報を送信したことに基づいて、ゲームに登場するモンスターであって、他のアカウントに基づき生成されたモンスター（限定ではなく、第２アカウントに基づく第２オブジェクトの一例）に関する情報（限定ではなく、第２情報の一例）を通信Ｉ／Ｆ２２によって受信する。そして、端末２０は、受信した情報に基づき、モンスター（限定ではなく、第２オブジェクトの一例）を表示部２４に表示するようにしてもよい。
このような構成により得られる実施例の効果の一例として、端末が、ＳＮＳで端末のユーザのアカウントと関連付けられた第１アカウントとは異なる第２アカウントに基づく第２オブジェクトに関する情報をサーバから受信した上で、第２オブジェクトを表示部に表示することができる。これにより、限定ではなく例として、ゲームにおいて、ＳＮＳにおいて自分のアカウントと関連付けられた、複数の他のアカウントに基づくモンスターを取得してゲームで利用するといったことが可能となり、ゲームの興趣が向上する。

また、この場合、上記の第１アカウントと第２アカウントとは、メッセージングサービスで、一般アカウント（限定ではなく、第１種別の一例）として自己の端末２０のユーザのアカウントと友だちとして登録されているアカウントであるようにしてもよい。
このような構成により得られる実施例の効果の一例として、ＳＮＳで、第１種別として端末のユーザのアカウントと関連付けられた第１アカウントと第２アカウントとに基づく第１オブジェクトと第２オブジェクトとを、ゲームで利用することが可能となる。

なお、この場合、端末が、オブジェクトであって第１アカウントに基づく第１オブジェクトに関する情報をサーバから受信して第１オブジェクトを表示することはできるが、オブジェクトであって第２アカウントに基づく第２オブジェクトに関する情報をサーバから受信して第２オブジェクトを表示することはできないようにしてもよい。

また、この場合、上記の第１アカウントと第２アカウントとは、メッセージングサービスで、一般アカウント（限定ではなく、第１種別の一例）として自己の端末２０のユーザのアカウントと友だちとして登録されているアカウントであって、ゲームのプレーヤとして登録されている友だちのアカウントであるようにしてもよい。
このような構成により得られる実施例の効果の一例として、端末は、ＳＮＳで、第１種別として端末のユーザのアカウントと関連付けられたアカウントのうち、ゲームのプレーヤとして登録されているユーザのアカウントに基づくオブジェクトを、ゲームで利用することができる。

なお、この場合、第１アカウントは、ＳＮＳで、第１種別として端末のユーザのアカウントと関連付けられたアカウントであってゲームのプレーヤとして登録されているユーザのアカウントであるが、第２アカウントは、ＳＮＳで、第１種別として端末のユーザのアカウントと関連付けられたアカウントであるが、ゲームのプレーヤとしては登録されていないアカウントであるようにしてもよい。

また、本実施例は、サーバ１０は、ゲームサーバ（限定ではなく、ゲームに関する情報を管理する第１サーバの一例）を含み、上記の第１情報は、端末２０の通信Ｉ／Ｆ２２によってゲームサーバに送信され、上記の第２情報は、端末２０の通信Ｉ／Ｆ２２によってゲームサーバから受信されるようにしてもよい。
このような構成により得られる実施例の効果の一例として、端末が、ゲームに関する情報を管理する第１サーバに第１情報を送信した上で、第１サーバから第２情報を受信することができる。

また、本実施例は、ゲームに関する処理を行う端末２０と通信するサーバ１０は、ゲームに登場するモンスターを生成するモンスター生成処理を制御部２１によって行う。そして、サーバ１０の通信Ｉ／Ｆ１４は、メッセージングサービスで端末２０のユーザのアカウントと関連付けられた一のアカウントに基づくモンスター生成要求情報を端末２０から受信し、モンスター生成要求情報を受信したことに基づいて、モンスターであって一のアカウントに基づくモンスターに関する情報を端末２０に送信する構成を示している。
このような構成により得られる実施例の効果の一例として、サーバは、ＳＮＳで端末のユーザのアカウントと関連付けられた第１アカウントに基づく、オブジェクトを要求するための第１情報を端末から受信したことに基づいて、オブジェクトであって第１アカウントに基づく第１オブジェクトに関する第２情報を端末に送信することができる。

＜第１変形例（１）＞
上記の実施例では、通信システムに含まれるサーバを１つのサーバ（サーバ１０）として図示・説明したが、これに限定されない。限定ではなく例として、通信システムに含まれるサーバを物理的に分離された複数のサーバとしてもよい。

図１－１３は、本変形例における通信システム１Ｂのシステム構成の一例を示す図である。
通信システム１Ｂでは、限定ではなく例として、ネットワーク３０を介して、メッセージングサーバ４０と、ゲームサーバ５０と、複数の端末２０（端末２０Ａ，端末２０Ｂ，端末２０Ｃ，・・・）とが接続される。

メッセージングサーバ４０は、メッセージングアプリケーションに関する情報を管理するサーバ（メッセージングサービスを提供するサーバ）であり、限定ではなく例として、メッセージングサービス事業者が管理するサーバとすることができる。
メッセージングサーバ４０は、限定ではなく例として、制御部４１（ＣＰＵ）、記憶部４５、通信Ｉ／Ｆ４４（インタフェース）、入出力部４２、時計部４９を備える。
また、入出力部４２は、限定ではなく例として、表示部４３を含む。

ゲームサーバ５０は、ゲームアプリケーションに関する情報を管理するサーバ（ゲームサービスを提供するサーバ）であり、限定ではなく例として、ゲームサービス事業者（ゲームメーカ等）が管理するサーバとすることができる。
ゲームサーバ５０は、限定ではなく例として、制御部５１（ＣＰＵ）、記憶部５５、通信Ｉ／Ｆ５４（インタフェース）、入出力部５２、時計部５９を備える。
また、入出力部５２は、限定ではなく例として、表示部５３を含む。

なお、これらのサーバの各機能部のＨＷ構成は、限定ではなく例として、前述したサーバ１０の各機能部のＨＷ構成と同様とすることができるため、説明を省略する。

メッセージングサーバ４０の記憶部４５には、データとして、限定ではなく例として、図１－３に示した一般アカウント登録データ１５３や一般アカウント管理データベース１５４等のデータを記憶させるようにすることができる。

ゲームサーバ５０の記憶部５５には、データとして、限定ではなく例として、図１－３に示したプレーヤ管理データベース１５６やモンスター生成用テーブル１５７Ａ等のデータを記憶させるようにすることができる。
なお、この場合、限定ではなく例として、図１－５に示したモンスター生成用テーブル１５７Ａの「ＭＡＩＤ下一桁」を「ゲーム用ＩＤ下一桁」としたテーブルをゲームサーバ５０の記憶部５５に記憶させるようにし、ゲームサーバ５０が、ゲーム用ＩＤに基づいてモンスターを生成するようにしてもよい。

図１－１４～図１－１５は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左から順に、端末２０Ａの制御部２１が実行する処理、メッセージングサーバ４０の制御部４１が実行する処理、ゲームサーバ５０の制御部５１が実行する処理をそれぞれ示している。

メッセージングサーバ４０の制御部４１は、通信Ｉ／Ｆ４４によって端末２０Ａからアカウント連携要求情報を受信すると、限定ではなく例として、受信したアカウント連携要求情報に含まれる一般ＭＡＩＤ（この例では、ユーザＡ．Ａの一般ＭＡＩＤ）からゲーム用ＩＤを生成する。そして、メッセージングサーバ４０の制御部４１は、生成したゲーム用ＩＤ（この例では、ユーザＡ．Ａのゲーム用ＩＤ）を、限定ではなく例として、前述した一般アカウント管理データベース１５５における、上記の一般ＭＡＩＤ（この例では、ユーザＡ．Ａの一般ＭＡＩＤ）が記憶された一般アカウント管理データに、一般ＭＡＩＤと関連付けて記憶させる。

次いで、メッセージングサーバ４０の制御部４１は、限定ではなく例として、生成したゲーム用ＩＤを含むアカウント連携要求情報を、通信Ｉ／Ｆ４４によってゲームサーバ５０に送信する（Ｍ１１０）。

通信Ｉ／Ｆ５４によってメッセージングサーバ４０からアカウント連携要求情報を受信すると、ゲームサーバ５０の制御部５１は、アカウント連携処理を行う（Ｇ１１０）。具体的には、限定ではなく例として、受信したアカウント連携要求情報に含まれるゲーム用ＩＤに対応するプレーヤＩＤを生成し、プレーヤＩＤとゲーム用ＩＤとを関連付けて記憶したプレーヤ管理データを生成して、記憶部５５のプレーヤ管理データベース１５６に記憶させる。

本変形例では、ゲームサーバ５０は、限定ではなく例として、ゲームアプリケーション事業者（ゲームメーカ等）が管理するサーバとすることができる。前述したように、メッセージングアプリケーションの一般ＭＡＩＤは重要な情報である。
そこで、本処理では、限定ではなく例として、メッセージングサーバ４０は、自装置で管理している一般ＭＡＩＤを直接ゲームサーバ５０に送信するのではなく、一般ＭＡＩＤから生成したゲーム用ＩＤをゲームサーバ５０に送信するようにしている。

なお、これとは異なり、メッセージングサーバ４０が、一般ＭＡＩＤをゲームサーバ５０に送信するようにしてもよい。

その後、ゲームサーバ５０の制御部５１は、限定ではなく例として、アカウント連携が完了したことを示す情報とプレーヤＩＤとを含むアカウント連携完了情報を、通信Ｉ／Ｆ５４によってメッセージングサーバ４０に送信する（Ｇ１２０）。

Ｍ１１０のステップの後、通信Ｉ／Ｆ４４によってゲームサーバ５０からアカウント連携情報を受信すると、メッセージングサーバ４０の制御部４１は、受信したアカウント連携情報を、通信Ｉ／Ｆ４４によって端末２０Ａに送信する（Ｍ１２０）。

なお、この場合に、メッセージングサーバ４０の制御部４１は、受信したアカウント連携情報に含まれるプレーヤＩＤを、上記の一般ＭＡＩＤと関連付けて、ユーザＡ．Ａの一般アカウント管理データに記憶させるようにしてもよい。

その後、通信Ｉ／Ｆ４４によって端末２０Ａから友だち一覧要求情報を受信すると、メッセージングサーバ４０の制御部４１は、友だち一覧情報を、通信Ｉ／Ｆ４４によって端末２０Ａに送信する（Ｍ１３０）。このステップの処理は、限定ではなく例として、図１－１１でサーバ１０の制御部１１が行うＳ１３０のステップの処理と同様とすることができる。

その後、限定ではなく例として、端末２０Ａと、メッセージングサーバ４０と、ゲームサーバ５０との間で、ゲーム処理が行われる（Ａ１４０、Ｍ１４０、Ｇ１４０）。

なお、実質的には、ゲームサーバ５０の制御部５１による制御のもとで、端末２０Ａにおいてゲームが進行される。このため、本変形例において、メッセージングサーバ４０は、端末２０Ａとゲームサーバ５０とを中継する機能を果たすと考えてもよい。

通信Ｉ／Ｆ４４によって端末２０Ａから一般ＭＡＩＤモンスター生成要求情報を受信すると、メッセージングサーバ４０の制御部４１は、一般アカウント管理データベース１５５を参照し、受信した一般ＭＡＩＤモンスター生成要求情報に含まれるユーザＡ．Ａによって選択された友だちの一般ＭＡＩＤに関連付けてゲーム用ＩＤが記憶されているか否かを判定する。そして、記憶されていると判定した場合、メッセージングサーバ４０の制御部４１は、限定ではなく例として、そのゲーム用ＩＤを含む一般ＭＡＩＤモンスター生成要求情報を、通信Ｉ／Ｆ４４によってゲームサーバ５０に送信する（Ｍ１８０）。

ユーザＡ．Ａによって選択された友だちがこのゲームのプレーヤである場合は、この友だちの一般アカウント管理データには、この友だちの一般ＭＡＩＤと関連付けてゲーム用ＩＤが記憶されている。上記の処理には、メッセージングサーバ４０の制御部４１が、Ｍ１３０のステップにおいて、ユーザＡ．Ａの友だちのうち、このゲームのプレーヤとして登録済みの友だちのみを対象として友だち一覧情報を送信する場合が含まれる。

一方、ユーザＡ．Ａによって選択された友だちの一般ＭＡＩＤに関連付けてゲーム用ＩＤが記憶されていないと判定した場合、メッセージングサーバ４０の制御部４１は、その友だちの一般ＭＡＩＤからゲーム用ＩＤを生成する。そして、メッセージングサーバ４０の制御部４１は、限定ではなく例として、生成したゲーム用ＩＤを含む一般ＭＡＩＤモンスター生成要求情報を、通信Ｉ／Ｆ４４によってゲームサーバ５０に送信する（Ｍ１８０）。
ユーザＡ．Ａによって選択された友だちがこのゲームのプレーヤではない場合は、この友だちの一般アカウント管理データには、この友だちの一般ＭＡＩＤと関連付けてゲーム用ＩＤが記憶されていない（ゲーム用ＩＤが未だ生成されていない）。上記の処理には、メッセージングサーバ４０の制御部４１が、Ｍ１３０のステップにおいて、ユーザＡ．Ａの全ての友だちを対象として友だち一覧情報を送信する場合が含まれる。

通信Ｉ／Ｆ５４によってメッセージングサーバ４０から一般ＭＡＩＤモンスター生成要求情報を受信すると、ゲームサーバ５０の制御部５１は、一般ＭＡＩＤモンスター生成処理を行う（Ｇ１８０）。具体的には、限定ではなく例として、記憶部５５に記憶されたモンスター生成用テーブル１５７Ａに基づいて、モンスター生成プログラムに従って、受信した一般ＭＡＩＤモンスター生成要求情報に含まれるゲーム用ＩＤに対応するモンスターを生成する。そして、生成したモンスターに関する情報を、そのゲーム用ＩＤに関連付けられたプレーヤＩＤが記憶されたプレーヤ管理データに記憶させる。

なお、これとは異なり、メッセージングサーバ４０が、一般ＭＡＩＤをゲームサーバ５０に送信するようにし、ゲームサーバ５０が、一般ＭＡＩＤに基づいてモンスターを生成するようにしてもよい。

次いで、ゲームサーバ５０の制御部５１は、限定ではなく例として、一般ＭＡＩＤモンスター生成結果情報を、通信Ｉ／Ｆ５４によって端末２０Ａに送信する（Ｇ１９０）。

Ａ１８０のステップの後、通信Ｉ／Ｆ２２によってゲームサーバ５０から一般ＭＡＩＤモンスター生成結果情報を受信すると、端末２０Ａの制御部２１は、受信した一般ＭＡＩＤモンスター生成結果情報を表示部２４に表示させる（Ａ１９０）。

なお、ゲームサーバ５０が、メッセージングサーバ４０を介して、一般ＭＡＩＤモンスター生成結果情報を端末２０Ａに送信するようにしてもよい。

また、メッセージングサーバ４０が、前もって、モンスターの生成元となる友だちのＩＤ（モンスター生成に一般ＭＡＩＤを用いるようにする場合は一般ＭＡＩＤ、モンスター生成にゲーム用ＩＤを用いるようにする場合はゲーム用ＩＤ）をゲームサーバ５０に送信しておくようにする。
そして、図１－１５のＡ１８０のステップにおいて、端末２０Ａの制御部２１が、ユーザＡ．Ａによって選択された友だちのＩＤ（一般ＭＡＩＤが用いられるのであれば一般ＭＡＩＤ、ゲーム用ＩＤが用いられるのであればゲーム用ＩＤ）を含むモンスター生成要求情報を通信Ｉ／Ｆ２２によってゲームサーバ５０に送信するようにし、ゲームサーバ５０の制御部５１が、Ｇ１８０のステップを行うようにしてもよい。

本変形例は、サーバは、ゲームサーバ５０（限定ではなく、ゲームに関する情報を管理する第１サーバの一例）と、メッセージングサーバ４０（限定ではなく、ＳＮＳに関する情報を管理する第２サーバの一例）とを含む。そして、前述した第１情報は、端末２０の通信Ｉ／Ｆ２２によってメッセージングサーバ４０に送信され、メッセージングサーバ４０からゲームサーバ５０に送信され、前述した第２情報は、端末２０の通信Ｉ／Ｆ２２によってゲームサーバ５０から受信される構成を示している。
このような構成により得られる変形例の効果の一例として、端末が、ＳＮＳに関する情報を管理する第２サーバに第１情報を送信すると、この第１情報が、第２サーバから、ゲームに関する情報を管理する第１サーバに送信されるようにすることができる。そして、端末は、第２情報を、第１サーバから受信することができる。

＜第１変形例（２）＞
上記の実施例および変形例では、サーバが、プレーヤの端末２０からモンスターの生成を要求されたタイミングでモンスター生成処理を行うこととしたが、これに限定されない。サーバが、これとは別のタイミングで、モンスター生成処理を行うようにしてもよい。

図１－１６は、本変形例において端末２０Ａの表示部２４に表示されるゲームアプリケーションの画面の一例を示す図である。ここでは、ユーザＡ．Ａの端末２０Ａの表示部２４に表示される画面を例示する。

この例では、限定ではなく例として、ゲーム処理が実行されるよりも前のタイミングで、端末２０ＡのユーザＡ．Ａの全部または一部の友だちに基づくモンスター生成結果（一般ＭＡＩＤモンスター生成結果情報）を端末２０Ａがサーバから受信する。これにより、第２生成画面において、このモンスター生成結果に関連した情報（モンスター生成結果に基づく情報）を表示することが可能となっている。

具体的には、限定ではなく例として、友だちのうちモンスター生成済みとして扱われる友だちに対応するリスト項目には、生成済アイコンＧＩＣ１（本例では、生成されたモンスターのサムネイルを含むアイコン）が表示され、友だちのうちモンスター未生成として扱われる友だちに対応するリスト項目には、未生成アイコンＧＩＣ２（本例では、「？」の文字を含むアイコン）が表示される。

なお、未生成アイコンとして、限定ではなく例として、生成されるモンスターを示唆する情報を含むアイコンを表示するようにしてもよい。生成されるモンスターを示唆する情報には、限定ではなく例として、生成されるモンスターのシルエット（形状が異なる）や「？」の文字（表示色が異なる）を含めてもよい。

限定ではなく例として、モンスターのシルエットを含むアイコンを表示する場合、各モンスターの一部または全部を模したシルエットを含むアイコンを表示するようにしてもよい。

限定ではなく例として、「？」の文字を含むアイコンを表示する場合、各モンスターの外見特徴に応じて、「？」の文字の表示色を異ならせてもよい。
具体的には、限定ではなく例として、「？」の文字の表示色が赤色である場合、モンスター外見特徴が「かっこいい」のモンスターが生成される割合が高く、「？」の文字の表示色が青色である場合、モンスター外見特徴が「こわい」のモンスターが生成される割合が高く、「？」の文字の表示色が桃色である場合、モンスター外見特徴が「かわいい」のモンスターが生成される割合が高くなるようにしてもよい。

図１－１６の第２生成画面では、友だちリストの項目として、ユーザＢ．Ｂに対応した友だちリスト項目の中央部に未生成アイコンＧＩＣ２（本例では、「？」の文字を含むアイコン）が表示されており、ユーザＣ．Ｃに対応した友だちリスト項目の中央部に生成済アイコンＧＩＣ１（本例では、モンスターＣのサムネイルを含むアイコン）が表示されている。

このように、モンスター生成に用いる友だちを選択する第２生成画面のリスト項目において、モンスター生成の有無に応じて態様の異なるアイコン（生成済アイコンＧＩＣ１、未生成アイコンＧＩＣ２）が表示されることによって、既にモンスター生成している友だちと、まだモンスター生成していない友だちとを容易に認識することができる。また、既にモンスター生成した友だちのリスト項目に既に生成したモンスターのサムネイルを含む生成済アイコンが表示されることによって、ユーザが既に生成したモンスターと同じモンスターを生成したい場合に、いずれの友だちからモンスター生成を行えばよいかを容易に認識することができる。

図１－１７～図１－１８は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。これは、図１－１１～図１－１２に示した処理に適用する場合の処理例を示す図である。
Ｓ１２０のステップの後、通信Ｉ／Ｆ１４によって端末２０Ａから友だち一覧要求情報を受信すると、サーバ１０の制御部１１は、一般ＭＡＩＤモンスター生成処理を行う（Ｓ１８１）。具体的には、限定ではなく例として、前述したモンスター生成用テーブル１５７Ａに基づいて、モンスター生成プログラムに従って、ユーザＡ．Ａの全ての友だちについて、各々の一般ＭＡＩＤに対応するモンスターを生成する。そして、生成したモンスターに関する情報を、ユーザＡ．ＡのプレーヤＩＤが記憶されたプレーヤ管理データに記憶させる。

なお、この処理において、サーバ１０の制御部１１が、ユーザＡ．Ａの友だちのうちの一部の一般アカウントについて、各々の一般ＭＡＩＤに対応するモンスターを生成するようにしてもよい。一部の一般アカウントについては、前述した通りである。

その後、サーバ１０の制御部１１は、友だち一覧情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ１３１）。また、サーバ１０の制御部１１は、一般ＭＡＩＤモンスター生成結果情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ１５１）。
この場合、サーバ１０の制御部１１は、Ｓ１８１のステップでモンスターを生成した友だち（全部または一部の友だち）に関する友だち一覧情報をＳ１３１のステップで端末２０Ａに送信し、Ｓ１８１のステップで生成したモンスターに関するモンスター生成結果情報（全部または一部の友だちに対応するモンスター生成結果情報）をＳ１５１のステップで端末２０Ａに送信するようにすることができる。

Ａ１３０のステップの後、通信Ｉ／Ｆ２２によってサーバ１０から友だち一覧情報と、一般ＭＡＩＤモンスター生成結果情報とを受信すると、端末２０Ａの制御部２１は、これらの情報を記憶部２８に記憶させる。

Ａ１５０のステップにおいてモンスターを生成すると判定したならば（Ａ１５０：ＹＥＳ）、端末２０Ａの制御部２１は、友だち一覧を表示部２４に表示させる（Ａ１６１）。

この場合、端末２０Ａの制御部２１は、限定ではなく例として、モンスターを生成するためのユーザ入力（限定ではなく例として、モンスター生成ボタンに対する操作等）が未だ行われていない友だち（Ａ１９０のステップでモンスター生成結果情報を未だ表示部２４に表示していない友だち）については、表示部２４に表示する友だちリストにおいて、友だちのユーザアイコン画像やユーザ名、モンスター生成ボタン等と関連付けて、限定ではなく例として図１－１６に示したような未生成アイコンを表示させるようにすることができる。

一方、モンスターを生成するためのユーザ入力（限定ではなく例として、モンスター生成ボタンに対する操作等）が行われた友だち（Ａ１９０のステップでモンスター生成結果情報を表示部２４に表示済みの友だち）については、表示部２４に表示する友だちリストにおいて、友だちのユーザアイコン画像やユーザ名、モンスター生成ボタン等と関連付けて、限定ではなく例として図１－１６に示したような、対応するモンスターの生成済みアイコン（対応するモンスターのサムネイル等を含むアイコン）を表示させるようにすることができる。

なお、生成済みアイコンや、生成済みアイコンに表示されるモンスターのサムネイル等は、Ｓ１５１のステップでサーバ１０から送信されて端末２０Ａで受信されて記憶部２８に記憶しておいた一般ＭＡＩＤモンスター生成結果情報に含まれるモンスターの画像に基づいて、端末２０Ａの制御部２１が生成するようにしてもよい。
また、サーバ１０の制御部１１が、Ｓ１３１のステップにおいて、Ｓ１８１のステップで生成したモンスターのサムネイルや生成済みアイコンを友だち一覧情報に含めて端末２０Ａに送信するようにしてもよい。また、サーバ１０の制御部１１が、これらの情報を、Ｓ１５１のステップにおいて一般ＭＡＩＤモンスター生成結果情報に含めて端末２０Ａに送信するようにしてもよい。

Ａ１７０のステップで一般ＭＡＩＤに基づいてモンスターを生成すると判定したならば（Ａ１７０：ＹＥＳ）、端末２０Ａの制御部２１は、記憶部２８に記憶しておいた一般ＭＡＩＤモンスター生成結果情報に基づいて、ユーザＡ．Ａによって選択された友だちに対応するモンスター生成結果情報を表示部２４に表示させる（Ａ１９０）。

図１－１９～図１－２０は、本変形例において各装置が実行する処理の流れの別例を示すフローチャートである。これは、図１－１１～図１－１２に示した処理に適用する場合の処理例を示す図である。
この処理では、サーバ１０の制御部１１は、Ｓ１８１のステップの後、Ｓ１３１のステップの処理を行い、その後、Ｓ１４０のステップに処理を進める。つまり、この処理では、Ｓ１３１のステップの後、サーバ１０の制御部１１は、Ｓ１８１のステップで生成したモンスターに関するモンスター生成結果情報（全部または一部の友だちに対応するモンスター生成結果情報）を端末２０Ａに送信しない。

Ａ１７０のステップで一般ＭＡＩＤに基づいてモンスターを生成すると判定したならば（Ａ１７０：ＹＥＳ）、端末２０Ａの制御部２１は、ユーザＡ．Ａによって選択された友だちを対象として一般ＭＡＩＤモンスター取得要求情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ１８２）。

Ｓ１４０のステップの後、通信Ｉ／Ｆ１４によって端末２０Ａから一般ＭＡＩＤモンスター取得要求情報を受信すると、サーバ１０の制御部１１は、Ｓ１８１のステップで生成したモンスターのうち、受信した一般ＭＡＩＤモンスター取得要求情報に含まれる一般ＭＡＩＤ（ユーザＡ．Ａによって選択された友だちの一般ＭＡＩＤ）に対応するモンスターに関する情報を含む一般ＭＡＩＤモンスター生成結果情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ１９０）。

図１－２１は、本変形例において各装置が実行する処理の流れの別例を示すフローチャートである。これは、図１－１７に続く処理の一例を示したものである。
Ａ１７０のステップで一般ＭＡＩＤに基づいてモンスターを生成すると判定したならば（Ａ１７０：ＹＥＳ）、端末２０Ａの制御部２１は、ユーザＡ．Ａによって選択された友だちを対象として一般ＭＡＩＤモンスターアクティブ化要求情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ１８４）。

ここで、アクティブ化（アクティベーション）とは、限定ではなく例として、ゲームでそのモンスター（オブジェクト）を用いてプレイすることができない状態からプレイ可能な状態にすること、とすることができる。ゲームでそのモンスターを使用できない状態から使用可能な状態にすることと捉えてもよい。

Ｓ１４０のステップの後、通信Ｉ／Ｆ１４によって端末２０Ａから一般ＭＡＩＤモンスターアクティブ化要求情報を受信すると、サーバ１０の制御部１１は、Ｓ１８１のステップで生成したモンスターのうち、受信した一般ＭＡＩＤモンスターアクティブ化要求情報に含まれる一般ＭＡＩＤ（ユーザＡ．Ａによって選択された友だちの一般ＭＡＩＤ）に対応するモンスターをアクティブ化するか否かを判定する（Ｓ１８５）。

具体的には、サーバ１０の制御部１１は、アクティブ化条件として、限定ではなく例として、以下のうちの少なくともいずれか１つの条件に基づいて、モンスターをアクティブ化するか否かを判定するようにしてもよい。
（Ａ）１日のモンスター生成の上限回数に達していない
（Ｂ）モンスター生成用の特定のゲーム内コンテンツ・アイテム・対価（限定ではなく例として、モンスター生成にコイン１枚を消費等）をユーザが所有している

このモンスターをアクティブ化すると判定したならば（Ｓ１８５：ＹＥＳ）、サーバ１０の制御部１１は、モンスターアクティブ化処理（モンスターアクティベーション処理）を行う（Ｓ１８７）。
具体的には、限定ではなく例として、（Ａ）の条件を用いた場合はユーザＡ．Ａのアカウントに関連付けてモンスター生成回数をインクリメントし、（Ｂ）の条件を用いた場合はユーザＡ．Ａのアカウントに関連付けて記憶されている特定のアイテムを減算する処理（限定ではなく例として、コインを１枚減算する処理）を行う。そして、Ｓ１８１のステップで生成したモンスターのうち、受信した一般ＭＡＩＤモンスターアクティブ化要求情報に含まれる一般ＭＡＩＤ（ユーザＡ．Ａによって選択された友だちの一般ＭＡＩＤ）に対応するモンスターをアクティブ化する。より具体的には、限定ではなく例として、Ｓ１８１のステップで、ユーザＡ．Ａの友だちのアカウントに基づいて生成した各々のモンスター（モンスターの識別情報等）と関連付けて、アクティブ化フラグ（デフォルトでは「ＯＦＦ」）を設定し、ユーザＡ．ＡのプレーヤＩＤが記憶されたプレーヤ管理データに記憶させておくようにする。そして、受信した一般ＭＡＩＤモンスターアクティブ化要求情報に含まれる一般ＭＡＩＤ（ユーザＡ．Ａによって選択された友だちの一般ＭＡＩＤ）に対応するモンスターのアクティブ化フラグを「ＯＮ」に設定する。このようにすることで、あらかじめ生成されたモンスターのうち、ユーザによって選択された友だちに対応するモンスターをゲームで使用可能な状態にすることができる。

次いで、サーバ１０の制御部１１は、このモンスターをアクティブ化したことを示す一般ＭＡＩＤモンスターアクティブ化情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ１９１）。この一般ＭＡＩＤモンスターアクティブ化情報は、限定ではなく例として、モンスターをユーザに使用可能にさせるための情報と捉えてもよく、第２情報（オブジェクトであってアカウントに基づくオブジェクトに関する情報）の一例とすることができる。
なお、サーバ１０の制御部１１が、アクティブ化したモンスターの生成結果の情報も併せて端末２０Ａに送信するようにしてもよい。

通信Ｉ／Ｆ２２によってサーバ１０から一般ＭＡＩＤモンスターアクティブ化情報を受信すると、端末２０Ａの制御部２１は、Ａ１９０のステップを行う。具体的には、限定ではなく例として、先にサーバ１０から受信して記憶しておいたモンスターの生成結果の情報（またはサーバ１０から受信したモンスターの生成結果の情報）に基づいて、アクティブ化された一般ＭＡＩＤモンスター生成結果情報を表示部２４に表示させる。
なお、端末２０Ａの制御部２１が、サーバ１０から受信した一般ＭＡＩＤモンスターアクティブ化情報も併せて表示部２４に表示させるようにしてもよい。

この場合、端末２０Ａの制御部２１は、限定ではなく例として、先にサーバ１０から受信して記憶しておいたモンスターのうち、受信した一般ＭＡＩＤモンスターアクティブ化情報から特定されるモンスターのフラグを「ＯＮ」に設定するなどすることで、アクティブ状態のモンスターと非アクティブ状態のモンスターとを識別可能となり、前述した友だちリストへの表示を実現可能となる。

なお、アクティブ化条件に、限定ではなく例として、以下の条件を含めるようにしてもよい。
（Ｃ）端末から受信した一般ＭＡＩＤモンスターアクティブ化要求情報に含まれるモンスターの情報と、サーバが記憶しているモンスターの情報とが一致する

具体的には、端末２０Ａの制御部２１が、Ａ１８４のステップにおいて、限定ではなく例として、アクティブ化を要求するモンスターの情報（限定ではなく例として、モンスターのパラメータ値、モンスターの画像等の情報）を一般ＭＡＩＤモンスターアクティブ化要求情報に含めてサーバ１０に送信する。そして、サーバ１０の制御部１１は、Ｓ１８７のステップにおいて、受信した一般ＭＡＩＤモンスターアクティブ化要求情報に含まれるモンスターの情報と、Ｓ１８１のステップで生成して記憶しておいたモンスターのうちの対応するモンスターの情報とを比較し、これらの情報が一致する場合に、そのモンスターをアクティブ化すると判定するようにすることができる。

このようにすることで、限定ではなく例として、不正な手法（いわゆるチート）によって、サーバ１０側で管理されているモンスターが改変されたような場合であっても（限定ではなく例として、パラメータ値の改変、態様の改変等）、そのモンスターがアクティブ化されないようにすることができる。つまり、限定ではなく例として、端末２０で内部的に記憶されているモンスターの情報に基づき、モンスターのパラメータ値等の情報が不正に改変されたような場合であっても、そのモンスターがサーバ１０でアクティブ化されないようにすることができる。

なお、本処理の図１－１７のＳ１５１のステップにおいて、サーバ１０の制御部１１が、少なくともモンスターのパラメータ値の情報は端末２０Ａに送信しないようにし（モンスターの態様の情報も送信しないようにしてもよい）、友だちリストへの表示用の情報（限定ではなく例として、前述した生成済アイコンＧＩＣ１やモンスターのサムネイル等）を端末２０Ａに送信するようにしてもよい。この場合、図１－２１のＳ１９１のステップにおいて、サーバ１０の制御部１１が、アクティブ化したモンスターの生成結果の情報も併せて端末２０Ａに送信するようにし、端末２０Ａの制御部２１が、受信したモンスターの生成結果の情報に基づいてＡ１９０のステップを行うようにしてもよい。このようにすることによっても、モンスターのパラメータ値等の情報が改変されないようにすることができる。

また、上記の処理において、端末２０Ａの制御部２１が、選択されたモンスターをアクティブ化するか否かの判定を行うようにしてもよい。
また、端末２０Ａの制御部２１が、その判定結果をサーバ１０に送信し、サーバ１０によってモンスターがアクティブ化されるようにしてもよい。

また、上記の処理を、図１－１３に示した通信システム１Ｂにおいて実行される、図１－１５～図１－１７に示した処理についても同様に適用してもよい。

本変形例は、端末２０が、自己の端末２０のユーザの一の友だちのアカウント（限定ではなく、第１アカウントの一例）に関する情報と、他の友だちのアカウント（限定ではなく、第５アカウントの一例）に関する情報とを含む友だちリスト（限定ではなく、リストの一例）を表示部２４に表示する。そして、端末２０は、一の友だちのアカウントに基づくモンスター生成要求情報が送信されておらず、他の友だちのアカウントに基づくモンスター生成要求情報が送信されていない場合に、一の友だちのアカウントに基づくモンスター生成要求情報が送信された場合、一の友だちのアカウントに関する情報と他の友だちのアカウントに関する情報とは同じ態様で友だちリストに表示され、一の友だちのアカウントに基づくモンスター生成要求情報が送信され、他の友だちのアカウントに基づくモンスター生成要求情報が送信されていない場合、一の友だちのアカウントに関する情報と他の友だちのアカウントに関する情報とは異なる態様で友だちリストに表示される構成を示している。
このような構成により得られる変形例の効果の一例として、第１アカウントに基づく第１情報が送信されておらず、第５アカウントに基づく第１情報が送信されていない場合に、第１アカウントに基づく第１情報が送信された場合、第１アカウントに関する情報と第５アカウントに関する情報とが同じ態様でリストに表示されることで、いずれのアカウントに基づく第１情報も送信されていないことを端末のユーザに知らせることができる。一方、第１アカウントに基づく第１情報が送信され、第５アカウントに基づく第１情報が送信されていない場合、第１アカウントに関する情報と第５アカウントに関する情報とが異なる態様でリストに表示されることで、第１アカウントに基づく第１情報が送信されたことを端末のユーザに知らせることができる。

また、この場合、第１アカウントに基づくモンスター（限定ではなく、第１オブジェクトの一例）は、第１アカウントに基づくモンスター生成要求情報が送信される前に、サーバ１０によって生成されるなどして、サーバ１０によって第１アカウントと関連付けられているようにしてもよい。
このような構成により得られる変形例の効果の一例として、第１アカウントに基づく第１情報が送信される前に、第１オブジェクトが、サーバによって第１アカウントと関連付けられるようにすることができる。

なお、端末２０が、メッセージングサービスで自己の端末２０のユーザの友だちのうちの全部または一部のアカウントに基づき、あらかじめ生成されたモンスターに関する情報（限定ではなく例として、モンスターの態様、モンスターのパラメータ値等の情報）を記憶部２８に記憶する。モンスターの生成は、端末２０で行ってもよいし、サーバ１０で行ってもよい。
そして、端末２０は、上記のモンスターの生成元の友だちのアカウントのうちの１以上のアカウントに関する情報（限定ではなく例として、ユーザ名、ユーザアイコン画像、モンスター生成ボタン等）を表示部２４に表示する。
そして、端末２０は、表示部２４に表示された１以上のアカウントに関する情報のうちの少なくとも１つのアカウントに関する情報に対する自己の端末２０のユーザによる入力に基づいて、記憶部２８に記憶されたモンスターに関する情報を用いて、そのアカウントに基づくモンスターを表示部２４に表示するようにしてもよい。

また、端末２０でモンスターを生成する場合において、表示部２４に表示された１以上のアカウントに関する情報のうちの少なくとも１つのアカウントに関する情報に対する自己の端末２０のユーザによる入力に基づいて、そのアカウントに基づくモンスターを生成し、生成したモンスターを表示部２４に表示するようにしてもよい。

また、オブジェクトを要求するための情報を送信することには、限定ではなく例として、
・サーバがアカウントに基づき生成済みのオブジェクトを取得するための情報を、端末からサーバに送信すること
・端末がサーバから取得済みのオブジェクトをアクティブ化するための情報を、端末からサーバに送信すること
を含めてもよい。

＜第１変形例（３）＞
上記の実施例や変形例において、定期的なタイミングや期限付きのタイミングなどで、生成されるモンスターがリフレッシュされるようにしてもよい。
本明細書で説明するような売り切り形式のゲームではなく、運営形式のゲームにおいては、運営者がゲームを運営している間にモンスターの種類を追加するような場合があり得る。

図１－２２は、本変形例におけるモンスター生成用テーブル１５７の一例であるモンスター生成用テーブル１５７Ｂのテーブル構成例を示す図である。
このモンスター生成用テーブル１５７Ｂのテーブル構成は、図１－５のモンスター生成用テーブル１５７Ａと同様であるが、その内容が異なっている。

具体的には、このテーブルでは、ＭＡＩＤ下一桁に、限定ではなく例として、「０～１」、「２～３」、「４～５」、「６～７」、「８～９」の数値範囲が設定されている。
下一桁「０～１」には、モンスター種別として「Ｍ－Ｅ（モンスターＥ）」が、モンスター外見特徴として「かわいい」がそれぞれ設定されている。
下一桁「２～３」には、モンスター種別として「Ｍ－Ｄ（モンスターＤ）」が、モンスター外見特徴として「かっこいい」がそれぞれ設定されている。
下一桁「４～５」には、モンスター種別として「Ｍ－Ｃ（モンスターＣ）」が、モンスター外見特徴として「かわいい」がそれぞれ設定されている。
下一桁「６～７」には、モンスター種別として「Ｍ－Ｂ（モンスターＢ）」が、モンスター外見特徴として「こわい」がそれぞれ設定されている。
下一桁「８～９」には、モンスター種別として「Ｍ－Ａ（モンスターＡ）」が、モンスター外見特徴として「かっこいい」がそれぞれ設定されている。

サーバ１０の制御部１１は、限定ではなく例として、上記のモンスター生成用テーブル１５７Ｂに基づいて、モンスターを生成するようにすることができる。
この場合、サーバ１０の制御部１１は、限定ではなく例として、ゲーム配信開始時には前述したモンスター生成用テーブル１５７Ａに基づいてモンスターを生成する。そして、その後、モンスターをリフレッシュするタイミングが到来した場合、サーバ１０の制御部１１は、上記のモンスター生成用テーブル１５７Ｂに基づいてモンスターを生成するようにするなどすることができる。
このようにすることで、同じ一般ＭＡＩＤに基づいてモンスターを生成する場合であっても、異なるモンスターが生成され得る。

なお、ゲームサーバ５０の制御部５１がモンスターを生成する場合も同様としてもよい。

なお、このような例に限定されず、リフレッシュされた後でも、ユーザの要望に応じて、リフレッシュされる前のモンスター生成用テーブルに基づいてモンスターが生成されるようにしてもよい。
また、限定ではなく例として、リフレッシュされる前に第１のモンスター生成用テーブルが設定されており、リフレッシュされた後に第１のモンスター生成用テーブルに加えて第２のモンスター生成用テーブルが追加で設定されている場合、ユーザが任意のモンスター生成用テーブルを選択し、そのモンスター生成用テーブルに基づいてモンスターが生成されるようにしてもよい。

また、上記のモンスター生成用テーブル１５７Ｂを、第２実施例で説明する公式アカウントに基づいてモンスターを生成する場合における公式ＭＡＩＤにも同様に適用してもよいし、適用しなくてもよい。

本変形例は、端末２０は、自己の端末２０のユーザの一の友だちの第１アカウントに基づくモンスター（限定ではなく、第１オブジェクト）に関する第２情報が端末２０の表示部２４に表示された後、一の友だちの第１アカウントに関する情報を表示部２４に表示する。そして、端末２０は、表示部２４に表示された一の友だちのアカウントに関する情報に対する自己の端末２０のユーザによる入力に基づいて、一の友だちのアカウントに基づくモンスター生成要求情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する。そして、端末２０は、モンスター生成要求情報を送信したことに基づいて、この一の友だちのアカウントに基づいて先にサーバ１０から取得したモンスター（限定ではなく、第１オブジェクトの一例）に代えて表示部２４に表示される、モンスターであってこの一の友だちのアカウントに基づくモンスター（限定ではなく、第５オブジェクトの一例）に関する第２情報を通信Ｉ／Ｆ２２によってサーバ１０から受信し、受信した第２情報に基づきモンスター（第５オブジェクト）を表示部２４に表示する構成を示している。
このような構成により得られる変形例の効果の一例として、端末は、第１アカウントに基づく第１オブジェクトに代えて端末の表示部に表示される、オブジェクトであって第１アカウントに基づく第５オブジェクトに関する第２情報をサーバから受信した上で、第５オブジェクトを表示部に表示することができる。

＜第１変形例（４）＞
上記の実施例や変形例において、メッセージングアプリケーションにおいて友だちとして登録している一般アカウントとは異なる仮想アカウントをゲームアプリケーションにおいて友だちとして登録し、この仮想アカウントに基づいてモンスターが生成されてもよい。
本明細書におけるゲームでは、メッセージングアプリケーションにおいて友だちとして登録されている一般アカウントに基づいてモンスターが生成されるが、プレーヤによってはメッセージングアプリケーションにおいて友だちとして登録されている一般アカウントの数が少ない場合があり得る。

図１－２３は、本変形例において端末２０Ａの表示部２４に表示されるゲームアプリケーションの画面の一例を示す図である。ここでは、ユーザＡ．Ａの端末２０Ａの表示部２４に表示される画面を例示する。

この例では、限定ではなく例として、ゲームにおいて仮想アカウントを友だちとして登録するための追加ボタンが表示されており、この追加ボタンがプレーヤによってタッチされると、仮想アカウントが友だちとして登録される。この仮想アカウントは、実際の人間（ユーザ）とは異なり、限定ではなく例として、ゲーム内のキャラクタ（人、モンスター等）としてもよい。

図１－２３（１）における表示画面については、前述した図１－８（３）と同様である部分については説明を省略する。

図１－２３（１）の画面では、画面最上部のホームボタンの左方に、仮想アカウントを友だちとして追加するための追加ボタンＦＢＴ（本例では、「＋」の記号を含むボタン）が表示されている。
また、その下には、友だちリストの項目として、ユーザＢ．Ｂに対応したアイコンおよびユーザ名のみが（一覧）表示されている。

限定ではなく例として、図１－２３（１）のように、追加ボタンＦＢＴがユーザによってタッチされると、限定ではなく例として、図１－２３（２）のような表示がなされる。
この画面では、図１－２３（１）の画面に重畳して、仮想アカウントを友だちとして追加することを確認するための確認領域ＭＧＲ２（追加確認領域）が表示されている。

確認領域ＭＧＲ２には、追加確認情報（本例では、「モンスターを生成するための友だちを追加しますか？」の文字）と、上記の情報に対して［ＹＥＳ］と答えるためのＹＥＳボタンＢＴ１と、上記の情報に対して［ＮＯ］と答えるためのＮＯボタンＢＴ２とが表示されている。

限定ではなく例として、図１－２３（２）のように、ＹＥＳボタンＢＴ１がユーザによってタッチされると、限定ではなく例として、図１－２３（３）のような表示がなされる。
この画面では、友だちリストの項目（本例では、ユーザＢ．Ｂに対応したアイコンおよびユーザ名）の下の領域に、本ゲームにおける、この端末２０ＡのユーザＡ．Ａの仮想アカウントの友だちに関する情報が一覧表示される「仮想友だちリスト」が表示されるように構成されている。

この例では、仮想友だちリストの項目として、キャラクタＸに対応したアイコンおよびユーザ名等が一覧表示されている。また、これらの各友だちリスト項目の右部には、生成実行ボタンＭＧＢＴ（本例では「モンスター生成」の文字を含むボタン）が表示されている。
なお、仮想友だちリストに表示されるキャラクタ等のアイコンは、友だちリストに表示される友だちのアイコンとは区別可能な態様で表示されるようにしてもよい。

ここで、キャラクタＸに対応する生成実行ボタンＭＧＢＴがプレーヤによってタッチされると、実際には存在しない仮想アカウントであるキャラクタＸからモンスターが生成されることとなる（不図示）。

この場合、限定ではなく例として、生成実行ボタンＭＧＢＴに対するユーザによる入力に基づいて、仮想アカウント（仮想友だち）を要求する情報が端末２０からサーバ１０に送信され、サーバ１０によって設定数の仮想アカウントが生成されて、または仮想アカウントのデータベースから設定数の仮想アカウントが読み出されて、その情報が端末２０に送信されるようにしてもよい。

なお、限定ではなく例として、友だちリストの友だちの数に基づいて、上記の設定数を異ならせてもよい。限定ではなく例として、友だちの数と設定数とを関連付けたテーブルに基づいて、サーバ１０が仮想アカウントの数を決定するようにしてもよい。この場合、限定ではなく例として、友だちの数が小さいほど設定数として大きい数（友だちの数が大きいほど設定数として小さい数）を設定しておくようにしてもよい。
また、端末２０のユーザが設定数を設定することができるようにしてもよい。

また、限定ではなく例として、友だちの数が所定数以下である場合にのみ、仮想アカウントを追加することができるようにしてもよい。

このように、メッセージングアプリケーションにおいて友だちとして登録している一般アカウントの数が少ないプレーヤが、友だちとして登録している一般アカウントの数によってゲームを進行するうえで不利になってしまうことを防止でき、健全なゲーム性を有するゲームを提供できる。

また、上記の手法により、友だち（仮想友だちを除く。）よりも多い数のモンスターを生成させることができる。限定ではなく例として、友だちが「０」の場合であってもモンスターを生成させることができる。

また、限定ではなく例として、友だちの数が所定数以下である第１ユーザの端末２０でゲームがプレイされる場合、サーバ１０が、メッセージングアプリケーションに登録されている少なくとも一部の第２ユーザ（他のユーザ）を、第１ユーザに友だち候補として紹介するようにしてもよい。限定ではなく例として、第１ユーザの端末２０で、友だち候補の第２ユーザの一覧情報（プロフィール等を含めてもよい。）が表示され、第１ユーザによって友だちになりたい第２ユーザを選択する入力がなされたことに基づいて、端末２０が、選択された第２ユーザに関する情報をサーバ１０に送信する。そして、サーバ１０が、第１ユーザの友だちとして、選択された第２ユーザをメッセージングアプリケーションで登録するようにしてもよい。

また、この場合、限定ではなく例として、サーバ１０が、メッセージングアプリケーションに登録されており、かつ、ゲームのプレーヤとして登録されているユーザのうちの少なくとも一部のユーザを端末２０のユーザに友だち候補として紹介するようにしてもよい。
さらに、この場合、サーバ１０が、同じく友だちの数が所定数以下であるユーザを紹介するようにしてもよい。

＜第１変形例（５）＞
上記の実施例では、友だちリストの中からユーザによって選択された友だちを対象としてサーバがモンスターを生成する例を示したが、これに限定されない。限定ではなく例として、モンスターを生成する友だちをユーザが選択しないようにしてもよい。つまり、モンスターを生成する友だちをユーザが選択するという要件を除外してもよい。

図１－２４～図１－２５は、本変形例において各装置が実行する処理の流れの別例を示すフローチャートである。これは、図１－１１～図１－１２に示した処理に適用する場合の処理例を示す図である。
まず、この処理では、図１－１１における、Ａ１３０のステップとＳ１３０のステップとが除外されている。

図１－２５において、Ａ１５０のステップでモンスターを生成すると判定すると（Ａ１５０：ＹＥＳ）、端末２０Ａの制御部２１は、モンスター生成要求情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ１８１）。
そして、端末２０Ａの制御部２１は、Ａ１９０のステップに処理を移す。

Ｓ１２０のステップの後、通信Ｉ／Ｆ１４によって端末２０Ａからモンスター生成要求情報を受信すると、サーバ１０の制御部１１は、一般アカウント選択処理を行う（Ｓ１７５）。具体的には、ユーザＡ．Ａのアカウントと友だちとして登録されている一般アカウントの中から、限定ではなく例として、少なくとも１つの一般アカウントをランダムに選択する。モンスターを生成する一般アカウントを抽選すると考えてもよい。
そして、サーバ１０の制御部１１は、Ｓ１８０のステップに処理を移す。

なお、上記において、サーバ１０の制御部１１が、設定数の一般アカウントをランダムに選択するようにしてもよく、設定数は、「１」としてもよいし、２以上の数としてもよい。

また、一般アカウントの選択は、友だちとして登録されている全ての一般アカウントから選択するようにしてもよいし、友だちとして登録されている一部の一般アカウントから選択するようにしてもよい。一部の一般アカウントについては、前述した通りである。

本変形例は、サーバ１０（限定ではなく、サーバの一例）と通信し、ゲーム処理等のゲームに関する処理を行う端末２０（限定ではなく、端末の一例）が、ゲームに登場するモンスター（限定ではなく、オブジェクト）であって、メッセージングサービス（限定ではなく、ＳＮＳの一例）で端末２０のユーザの一般アカウントと友だちとして登録されている複数の一般アカウントのうちの一の一般アカウントに基づき生成されたモンスター（限定ではなく、第１アカウントに基づく第１オブジェクトの一例）に関する情報を通信Ｉ／Ｆ２２によってサーバ１０から受信する。そして、端末２０は、受信した情報に基づき、生成されたモンスター（限定ではなく、第１オブジェクトの一例）を表示部２４に表示する構成を示している。
このような構成により得られる実施例の効果の一例として、端末が、ＳＮＳで端末のユーザのアカウントと関連付けられた複数のアカウントのうちの第１アカウントに基づく第１オブジェクトに関する情報をサーバから受信した上で、第１オブジェクトを表示部に表示することができる。これにより、限定ではなく例として、ゲームにおいて、ＳＮＳにおいて自分のアカウントと関連付けられた他のアカウントに基づくモンスターを取得してゲームで利用するといったことが可能となり、ゲームの興趣が向上する。

また、本実施例は、ゲームに関する処理を行う端末２０と通信するサーバ１０は、ゲームに登場するモンスターを生成するモンスター生成処理を制御部２１によって行う。そして、サーバ１０の通信Ｉ／Ｆ１４は、モンスターであって、メッセージングサービスで端末２０のユーザのアカウントと関連付けられた複数のアカウントのうちの一のアカウントに基づくモンスターに関する情報を端末２０に送信する構成を示している。
このような構成により得られる実施例の効果の一例として、サーバは、オブジェクトであって、ＳＮＳで端末のユーザのアカウントと関連付けられた複数のアカウントのうちの第１アカウントに基づく第１オブジェクトに関する第２情報を端末に送信することができる。

＜第２実施例＞
第１実施例では、メッセージングアプリケーションを利用する一般アカウントのユーザが、メッセージングアプリケーションにおいて友だちとして登録している一般アカウントに基づいてオブジェクトを取得する実施例について説明した。
第２実施例は、これに加えて、またはこれに代えて、限定ではなく例として、メッセージングアプリケーションを利用する一般アカウントのユーザが、公式アカウントに基づいてオブジェクトを取得することに関する実施例である。

第２実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。

＜データ構成＞
図２－１は、本実施例においてサーバ１０の記憶部１５に記憶される公式アカウント管理データベース１５９のデータ構成の一例を示す図である。
公式アカウント管理データベース１５９は、メッセージングアプリケーションにおける公式アカウントを管理するための管理用のデータベースであり、限定ではなく例として、公式アカウントごとの管理データとして、公式アカウント管理データが記憶される。

各々の公式アカウント管理データには、限定ではなく例として、公式ＭＡＩＤ（公式メッセージングアプリケーションＩＤ）と、公式ユーザ名と、その他登録情報と、公式アカウント友だちデータとが記憶される。

公式ユーザ名は、メッセージングアプリケーションを利用する公式アカウントの名称であり、限定ではなく例として、公式ユーザが端末２０によってメッセージングアプリケーションを利用する際に登録する名称が記憶される。
なお、公式ユーザも、一般ユーザと同様に、端末２０によってメッセージングアプリケーション等を利用することができるようにすることができる。

公式ＭＡＩＤは、メッセージングアプリケーションにおける公式ユーザのアカウントを識別するために用いられる情報、またはアカウントそのものである。
この公式ＭＡＩＤは、好ましくはアカウントごとに一意な値であり、限定ではなく例として、サーバ１０によってアカウントごとに一意な値（固有の値）が設定されて記憶される。
公式ＭＡＩＤは、公式ユーザが利用する端末２０、または公式ユーザに関連付けられた情報であり、端末に関する情報、または端末のユーザに関する情報の一例である。

その他登録情報には、限定ではなく例として、端末２０を識別するための識別情報、端末２０の電話番号やメールアドレス等の連絡先情報、アプリケーションにおける各種の認証に利用されるパスワード（ログインパスワード、認証パスワード等）等の認証情報、メッセージングアプリケーションでこの公式ユーザによって登録される自己のアイコン画像（公式ユーザアイコン画像）といった各種の情報を含めるようにしてもよい。

端末２０を識別するための識別情報は、限定ではなく例として、端末ＩＤ（限定ではなく例として、ＩＭＥＩとすることができる。

公式ＭＡＩＤは、端末２０のユーザを識別するための識別情報の一例とすることができる。公式ＭＡＩＤに代えて「公式ユーザＩＤ」としてもよい。また、一般ＭＡＩＤと公式ＭＡＩＤとを区別する必要がない場合には、単に「ユーザＩＤ」としてもよいし、しなくてもよい。
また、連絡先情報も、端末２０のユーザを識別するための識別情報の一例としてもよい。

また、１つの端末２０につき１つのアカウントしか登録することのできないアプリケーションであれば、限定ではなく例として、「端末２０を識別するための識別情報＝端末２０のユーザを識別するための識別情報＝公式ＭＡＩＤ」としてもよい。

また、限定ではなく例として、１つの公式ＭＡＩＤに、複数の端末ＩＤを割り当てることを可能としてもよいし、そのようにしなくてもよい。

また、電話番号等の情報によってアカウントを管理する手法を適用することも可能である。この場合、限定ではなく例として、電話番号等の情報を、公式アカウント管理データに記憶させるようにしてもよい。

公式アカウント友だちデータは、メッセージングアプリケーションにおいて、この公式ユーザ名の公式アカウントを友だちとして登録している一般ユーザに関するデータであり、限定ではなく例として、一般ユーザ名と、その一般ユーザ名の一般ユーザの一般ＭＡＩＤとが関連付けて記憶される。

図２－２は、本実施例においてサーバ１０の記憶部１５に記憶されるモンスター生成用テーブルの一例であるモンスター生成用テーブル１５７Ｃのデータ構成例を示す図である。ここでは、限定ではなく例として、前述したモンスター生成用テーブル１５７Ａ（１５７Ｂ）とは別のテーブルとして図示・説明する。
モンスター生成用テーブル１５７Ｃには、限定ではなく例として、公式ＭＡＩＤと、モンスター種別と、モンスター外見特徴とが関連付けて記憶される。

公式ＭＡＩＤには、限定ではなく例として、公式アカウント管理データベース１５９に含まれる公式アカウントのうち、限定ではなく例として、一部の公式アカウントの公式ＭＡＩＤが記憶される。

モンスター種別およびモンスター外見特徴の意味合いは、前述したモンスター生成用テーブル１５７Ａと同様である。

具体的には、このテーブルでは、公式ＭＡＩＤに、限定ではなく例として、「Ｃ００１」、「Ｃ００１５」等が設定されている。
公式ＭＡＩＤ「Ｃ００１」には、モンスター種別として「Ｍ－Ｃ（モンスターＣ）」が、モンスター外見特徴として「かわいい」がそれぞれ設定されている。
公式ＭＡＩＤ「Ｃ０１５」には、モンスター種別として「Ｍ－Ｄ（モンスターＤ）」が、モンスター外見特徴として「かっこいい」がそれぞれ設定されている。

限定ではなく例として、公式ＭＡＩＤ「Ｃ００１」の公式アカウントの公式ユーザは、図２－１に示すように、公式ユーザ名「Ｘ．Ｘスイーツ」の公式ユーザである。この公式ユーザは、限定ではなく例として、スイーツを提供・販売する事業を行う公式ユーザとすることができる。

スイーツを提供・販売する事業を行う公式ユーザの公式アカウントから、限定ではなく例として、外見特徴が「こわい」であるモンスターが生成されると、この公式ユーザの企業イメージが損なわれてしまう可能性がある。そこで、限定ではなく例として、モンスター外見特徴として「かわいい」を設定しておくことで、外見が「かわいい」モンスターが生成されるようにすることができ、企業イメージが損なわれることを防止できる。
なお、この他にも、限定ではなく例として、ぬいぐるみの販売を行う事業者等についても、同様にすることができる。

また、この例では、公式ＭＡＩＤ「Ｃ０１５」の公式アカウントの公式ユーザについては、その公式ユーザの事業内容等に基づき、外見が「かっこいい」モンスターが生成されるようにしている。

サーバ１０の制御部１１は、限定ではなく例として、プレーヤの端末２０から受信した公式ＭＡＩＤモンスター生成要求情報に含まれる公式ＭＡＩＤに基づいて、その公式ＭＡＩＤがモンスター生成用テーブル１５７Ｃに含まれるか否かを判定する。そして、含まれると判定した場合は、モンスター生成用テーブル１５７Ｃに設定されたモンスター種別とモンスター外見特徴とに基づき、対応する公式ＭＡＩＤのモンスターを生成するようにすることができる。

なお、モンスター生成用テーブル１５７Ｃに公式ＭＡＩＤが記憶されていない公式アカウントについて、プレーヤの端末２０からモンスターの生成要求がなされた場合、サーバ１０の制御部１１は、限定ではなく例として、前述したモンスター生成用テーブル１５７Ａに基づいてモンスターを生成するようにしてもよい。

また、公式ＭＡＩＤについても、第１実施例と同様にゲーム用ＩＤを生成するようにし、ゲーム用ＩＤに基づいてモンスターを生成するようにしてもよい。

＜表示画面＞
図２－３（１）における表示画面については、前述した図１－８（１）と同様であるので説明を省略する。

限定ではなく例として、図２－３（１）のように、生成ボタンＧＢＴがユーザによってタッチされると、限定ではなく例として、図２－３（２）のような表示がなされる。
この画面は、モンスターを生成するための生成画面のうち第１Ｂ生成画面であり、アプリ内位置表示領域には「生成ステージ」の文字が表示されている。

この例では、生成情報表示領域には、第１Ｂ生成確認情報（限定ではなく例として、「どのユーザからモンスターを生成しますか？」の文字）と、一般友だち（一般アカウント）からモンスター生成するための友だちボタンＵＢＴ１（本例では、「友だち」の文字を含むボタン）と、公式アカウントからモンスター生成するためのＯＡボタンＵＢＴ２（本例では、「公式アカウント」の文字を含むボタン）とが表示されている。

限定ではなく例として、友だちボタンＵＢＴ１がユーザによってタッチされた場合（即ち、モンスター生成するユーザの種別を一般友だち（一般アカウント）とした場合）、図２－３（３Ａ）のような表示がなされ、ＯＡボタンＵＢＴ２がユーザによってタッチされた場合（即ち、モンスター生成するユーザの種別を公式アカウントとした場合）、図２－３（３Ｂ）のような表示がなされる。

（一般友だちからモンスター生成するパターン）
図２－３（３Ａ）における表示画面については、前述した図１－８（３）と同様であるので説明を省略する。

（公式アカウントからモンスター生成するパターン）
図２－３（３Ｂ）の画面は、モンスターを生成するための生成画面のうち第２Ｂ生成画面であり、アプリ内位置表示領域には「生成ステージ」の文字が継続して表示されている。

この例では、生成情報表示領域には、友だちリストの項目として、公式アカウント（Ｘ．Ｘスイーツ）に対応したアイコンおよびユーザ名、公式アカウント（Ｙ．Ｙトラベル）に対応したアイコンおよびユーザ名等が一覧表示されている。また、これらの各友だちリスト項目の右部には、その友だちリスト項目に対応した友だちを用いてモンスターを生成するための生成実行ボタンＭＧＢＴ（本例では「モンスター生成」の文字を含むボタン）が表示されている。

次いで、図２－３（３Ａ）および（３Ｂ）において、任意の友だちリスト項目に対応した生成実行ボタンＭＧＢＴがユーザによってタッチされると、図１－８（４）以降に示したように、ユーザによって選択された友だち（一般友だち、公式アカウント）に基づいてモンスターが生成される。

このように、一般友だち（一般アカウント）ばかりでなく、公式アカウントからもモンスターを生成可能とすることで、一般友だちからしかモンスターを生成できない場合よりも多くの友だちからモンスター生成する機会をユーザに提供することができ、モンスター生成のゲーム性を有する本ゲームの興趣を向上できる。

＜処理＞
図２－４は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。ここでは、図１－１に示した通信システム１Ａを適用する場合の処理例を示し、図１－１２に対応する処理部分を示す。

Ａ１９０のステップの後、端末２０Ａの制御部２１は、表示した友だち一覧の中から公式アカウントを選択するユーザ入力がなされたか否かを判定するなどすることによって、公式ＭＡＩＤに基づいてモンスターを生成するか否かを判定する（Ｂ２００）。

公式ＭＡＩＤに基づいてモンスターを生成すると判定したならば（Ｂ２００：ＹＥＳ）、端末２０Ａの制御部２１は、限定ではなく例として、ユーザＡ．Ａによって選択された友だちの公式ＭＡＩＤを含む公式ＭＡＩＤモンスター生成要求情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ｂ２１０）。

Ｓ１９０のステップの後、通信Ｉ／Ｆ１４によって端末２０Ａから公式ＭＡＩＤモンスター生成要求情報を受信すると、サーバ１０の制御部１１は、公式ＭＡＩＤモンスター生成処理を行う（Ｓ２００）。具体的には、限定ではなく例として、前述したモンスター生成用テーブル１５７Ａやモンスター生成用テーブル１５７Ｃに基づいて、モンスター生成プログラムに従って、端末２０Ａから受信した公式ＭＡＩＤモンスター生成要求情報に含まれる公式ＭＡＩＤ（ユーザＡ．Ａによって選択された友だちの公式ＭＡＩＤ）に対応するモンスターを生成する。そして、生成したモンスターに関する情報を、ユーザＡ．ＡのプレーヤＩＤが記憶されたプレーヤ管理データに記憶させる。

その後、サーバ１０の制御部１１は、Ｓ２００のステップで生成したモンスターに関する情報を含む公式ＭＡＩＤモンスター生成結果情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ２１０）。

Ｂ２１０のステップの後、通信Ｉ／Ｆ２２によってサーバ１０から公式ＭＡＩＤモンスター生成結果情報を受信すると、端末２０Ａの制御部２１は、受信した公式ＭＡＩＤモンスター生成結果情報に基づいて、公式ＭＡＩＤモンスター生成結果情報を表示部２４に表示させる（Ｂ２２０）。

図２－５～図２－６は、本実施例において各装置が実行する処理の流れの別例を示すフローチャートである。ここでは、図１－１３に示した通信システム１Ｂを適用する場合の処理例を示し、図１－１５に対応する処理部分を示す。

通信Ｉ／Ｆ４４によって端末２０Ａから公式ＭＡＩＤを含む公式ＭＡＩＤモンスター生成要求情報を受信すると、メッセージングサーバ４０の制御部４１は、受信した公式ＭＡＩＤモンスター生成要求情報に含まれるユーザＡ．Ａによって選択された友だちの公式ＭＡＩＤからゲーム用ＩＤを生成し、生成したゲーム用ＩＤを含む公式ＭＡＩＤモンスター生成要求情報を、通信Ｉ／Ｆ４４によってゲームサーバ５０に送信する（Ｍ１８５）。

通信Ｉ／Ｆ５４によってメッセージングサーバ４０から公式ＭＡＩＤモンスター生成要求情報を受信すると、ゲームサーバ５０の制御部５１は、公式ＭＡＩＤモンスター生成処理を行う（Ｇ１９２）。具体的には、限定ではなく例として、記憶部５５に記憶されたモンスター生成用テーブル１５７Ａやモンスター生成用テーブル１５７Ｃに基づいて、モンスター生成プログラムに従って、受信した公式ＭＡＩＤモンスター生成要求情報に含まれるゲーム用ＩＤに対応するモンスターを生成する。そして、生成したモンスターに関する情報を、ユーザＡ．ＡのプレーヤＩＤが記憶されたプレーヤ管理データに記憶させる。

次いで、ゲームサーバ５０の制御部５１は、限定ではなく例として、公式ＭＡＩＤモンスター生成結果情報を、通信Ｉ／Ｆ５４によって端末２０Ａに送信する（Ｇ１９４）。

Ｂ２１０のステップの後、通信Ｉ／Ｆ２２によってゲームサーバ５０から公式ＭＡＩＤモンスター生成結果情報を受信すると、端末２０Ａの制御部２１は、受信した公式ＭＡＩＤモンスター生成結果情報を表示部２４に表示させる（Ｂ２２０）。

なお、ゲームサーバ５０が、メッセージングサーバ４０を介して、公式ＭＡＩＤモンスター生成結果情報を端末２０Ａに送信するようにしてもよい。

＜第２実施例の効果＞
本実施例は、第１アカウントは、メッセージングサービスで、一般アカウントの種別（限定ではなく、第１種別の一例）として端末２０のユーザのアカウントと友だち登録されているアカウントであり、端末２０は、メッセージングサービスで、公式アカウントの種別（限定ではなく、第２種別の一例）として端末２０のユーザのアカウントと友だち登録されているアカウント（限定ではなく、第３アカウントの一例）に関する情報を表示部２４に表示する。そして、端末２０は、表示部２４に表示された公式アカウントに関する情報に関する自己の端末２０のユーザによる入力に基づいて、その公式アカウントに基づくモンスター生成要求情報等の情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する。そして、端末２０は、モンスター生成要求情報等の情報を送信したことに基づいて、モンスターであって公式アカウントに基づくモンスター（限定ではなく、第３オブジェクトの一例）に関する情報を通信Ｉ／Ｆ２２によってサーバ１０から受信し、受信した情報に基づき、モンスターを表示部２４に表示する構成を示している。
このような構成により得られる実施例の効果の一例として、端末は、ＳＮＳで、第１種別とは異なる第２種別として端末のユーザのアカウントと関連付けられた第３アカウントに関する情報を表示し、表示された第３アカウントに関する情報に対する端末のユーザによる入力に基づいて、第３アカウントに基づく第１情報を通信部によってサーバに送信する。そして、端末は、第１情報を送信したことに基づいて、オブジェクトであって第３アカウントに基づく第３オブジェクトに関する第２情報を通信部によってサーバから受信した上で、その第３オブジェクトを表示部に表示することができる。これにより、限定ではなく例として、第１種別とは異なる第２種別のアカウントに基づくオブジェクトを、ゲームで利用するといったことが可能となる。

また、この場合、一の一般アカウントに基づくモンスター（限定ではなく、第１オブジェクトの一例）は、一般アカウントの種別に対応するモンスターであり、一の公式アカウントに基づくモンスター（限定ではなく、第３オブジェクトの一例）は、公式アカウントの種別に対応するモンスターであるようにしてもよい。
このような構成により得られる実施例の効果の一例として、第１種別として端末のユーザのアカウントと関連付けられたアカウントについては第１種別に対応するオブジェクトが取得され、第２種別として端末のユーザのアカウントと関連付けられたアカウントについては第２種別に対応するオブジェクトが取得されるようにすることができる。

＜第２変形例（１）＞
上記の実施例において、限定ではなく例として、ゲームアプリケーションにおいてお知らせ等から公式アカウントを新たに友だち登録したり、モンスターを生成したりすることができるようにしてもよい。

図２－７は、本変形例において端末２０Ａの表示部２４に表示される画面の一例を示す図である。
図２－７（１）における表示画面については、前述した図１－８（１）と同様であるので説明を省略する。

限定ではなく例として、図２－７（１）のように、お知らせボタンＮＢＴがユーザによってタッチされると、限定ではなく例として、図２－７（２）のような表示がなされる。
この画面は、お知らせを表示するためのお知らせ画面のうち第１お知らせ画面であり、アプリ内位置表示領域には「お知らせ」の文字が表示されている。

また、その下には、ゲームアプリケーションにおけるお知らせに関する情報（以下、「お知らせ情報」と称する。）が表示されるお知らせ情報表示領域が構成されている。
この例では、お知らせ情報表示領域には、このアカウント（この例では「ユーザＡ．Ａ」）が受信したお知らせを一覧表示させるためのお知らせリストが表示されるように構成されている。
この画面では、お知らせリストの項目として、お知らせのタイトルに関連するお知らせタイトル情報（本例では、「Ｚ．Ｚドリンクの公式アカウントと友だちで限定モンスターＧＥＴ！」の文字、「現在確認している不具合について」の文字等）が一覧表示されている。

なお、この「限定モンスター」は、本ゲームにおける友だちからモンスターを生成する通常のモンスター生成では生成されないモンスターであり、プレーヤにとって珍しく価値の高いモンスターとなるようにすることができる。この「限定モンスター」として、１種類のモンスターが設けられてもよく、複数種類のモンスターが設けられてもよい。

限定ではなく例として、図２－７（２）のように、お知らせリストの項目のうち、「Ｚ．Ｚドリンクの公式アカウントと友だちで限定モンスターＧＥＴ！」の文字を含むお知らせタイトル情報がユーザによってタッチされると、限定ではなく例として、図２－７（３Ａ）または図２－７（３Ｂ）のような表示がなされる。
限定ではなく例として、未だＺ．Ｚドリンクの公式アカウントと友だちでない場合、図２－７（３Ａ）のような表示がなされ、既にＺ．Ｚドリンクの公式アカウントと友だちである場合、図２－７（３Ｂ）のような表示がなされる。

（Ｚ．Ｚドリンクの公式アカウントと友だちでない場合）
図２－７（３Ａ）の画面は、お知らせを表示するためのお知らせ画面のうち第２Ａお知らせ画面であり、アプリ内位置表示領域には「お知らせ」の文字が継続して表示されている。

この例では、お知らせ情報表示領域には、限定ではなく例として、タッチされたお知らせタイトル情報に関連するお知らせの詳細な情報（以下、適宜「お知らせ詳細情報」と称する。）が展開された状態で表示されている。
本例では、お知らせ詳細情報は、「［Ｚ．Ｚドリンクに対応したアイコンおよびユーザ名］と友だちで［未生成アイコンＧＩＣ２および「限定モンスター」の文字］ＧＥＴ！！」の文字および画像と、この公式アカウントを友だち登録するための登録ボタンＲＢＴ（本例では、「友だちになる」の文字を含むボタン）と、第２お知らせ画面から第１お知らせ画面に戻るための戻るボタン（本例では、「戻る」の文字を含むボタン）とを含む情報である。登録ボタンＲＢＴがタッチされると、Ｚ．Ｚドリンクの公式アカウントを友だち登録することを要求するための情報が端末２０Ａからサーバ１０に送信され、サーバ１０によって友だち登録される。

（Ｚ．Ｚドリンクの公式アカウントと友だちである場合）
図２－７（３Ｂ）の画面は、お知らせを表示するためのお知らせ画面のうち第２Ｂお知らせ画面であり、アプリ内位置表示領域には「お知らせ」の文字が継続して表示されている。

この例では、お知らせ情報表示領域には、限定ではなく例として、お知らせ詳細情報が展開された状態で表示されている。
本例では、お知らせ詳細情報は、「［Ｚ．Ｚドリンクに対応したアイコンおよびユーザ名］と友だちで［未生成アイコンＧＩＣ２および「限定モンスター」の文字］ＧＥＴ！！」の文字および画像と、生成実行ボタンＭＧＢＴと、戻るボタンとを含む情報である。
生成実行ボタンＭＧＢＴがタッチされると、前述したように、公式ＭＡＩＤモンスター生成要求情報が端末２０Ａからサーバ１０に送信され、モンスターが生成される。

なお、この例では、上記の情報をおしらせ画面に表示することとしたが、おしらせ画面以外の画面に表示させるようにしてもよい。

このように、特定の公式アカウントを登録することで珍しいモンスターを入手できることをお知らせ画面等においてプレーヤに報知することによって、その公式アカウントを友だち登録するようにプレーヤに動機付けすることができる。また、その公式アカウントと友だちでない場合、友だち登録するための導線を確保している一方で、既にその公式アカウントと友だちである場合、不要な友だち登録するための導線の代わりにその公式アカウントからモンスター生成するための導線を確保していることによって、プレーヤの状況に応じた好適な画面を提供することができる。

なお、公式アカウントについては、期間限定のモンスターをユーザが取得することができるようにしてもよい。具体的には、限定ではなく例として、設定された期間（限定ではなく例として、その公式アカウントとのコラボキャンペーン期間等）内に、端末２０から公式ＭＡＩＤモンスター生成要求情報がサーバ１０に送信された場合、サーバ１０の制御部１１が、期間限定の特別なモンスターを生成するようにしてもよい。この場合、サーバ１０の制御部１１は、限定ではなく例として、期間限定の特別なモンスター生成用テーブルに基づいて、前述した手法と同様の手法によって、期間限定の特別なモンスターを生成するようにすることができる。

本変形例は、公式アカウントに関するモンスター生成結果情報等の情報（限定ではなく、第２情報の一例）は、設定された期間内に、その公式アカウントに基づくモンスター生成要求情報が通信Ｉ／Ｆ２２によって端末２０からサーバ１０に送信された場合、サーバ１０から端末２０に送信される構成を示している。
このような構成により得られる変形例の効果の一例として、設定された期間内に、第３アカウントに基づく第１情報が通信部によってサーバに送信された場合、第３オブジェクトに関する第２情報を、端末はサーバから取得することができる。

また、本変形例は、端末２０は、メッセージングサービスで、公式アカウントの種別として端末２０のユーザのアカウントが友だち登録していないアカウント（限定ではなく、第４アカウントの一例）に関する情報を通信Ｉ／Ｆ２２によってサーバ１０から受信する。そして、端末２０は、受信したアカウントに関する情報を表示部２４に表示する構成を示している。
このような構成により得られる変形例の効果の一例として、端末は、ＳＮＳで、第２種別として端末のユーザのアカウントと関連付けられていない第４アカウントに関する情報をサーバから取得した上で、取得した第４アカウントに関する情報を表示して、端末のユーザに知らせることができる。

また、この場合、上記の第４アカウントに関する情報は、メッセージングサービスで公式アカウントの種別として第４アカウントを友だち登録するよう端末のユーザに促す情報を含むようにしてもよい。
このような構成により得られる変形例の効果の一例として、ＳＮＳで第２種別として第４アカウントを自分のアカウントと関連づけるよう端末のユーザに促すことができる。

また、この場合、端末２０は、友だち登録ボタン等の情報（限定ではなく、第４アカウントに関する情報の一例）に対する自己の端末２０のユーザによる入力に基づいて、公式アカウントとして自己の端末２０のユーザのアカウントを上記の第４アカウントと関連付けることに関する処理を制御部２１によって行うようにしてもよい。
このような構成により得られる変形例の効果の一例として、第４アカウントに関する情報に対する端末のユーザによる入力に基づいて、第２種別として端末のユーザのアカウントを第４アカウントと関連付けることができる。

また、この場合、端末２０は、公式アカウントとして自己の端末２０のユーザのアカウントを上記の第４アカウントと関連付けることに関する処理が行われた後、上記の第４アカウントに関する情報を表示部２４に表示する。そして、端末２０は、表示部２４に表示された上記の第４アカウントに関する情報に対する端末２０のユーザによる入力に基づいて、上記の第４アカウントに基づくモンスター生成要求情報（限定ではなく、第１情報の一例）を通信Ｉ／Ｆ２２によってサーバ１０に送信する。そして、端末２０は、モンスター生成要求情報を送信したことに基づいて、モンスターであって上記の第４オブジェクトに基づくモンスター（限定ではなく、第４オブジェクトの一例）に関する情報（限定ではなく、第２情報の一例）を通信Ｉ／Ｆ２２によってサーバ１０から受信し、そのモンスターを表示部２４に表示するようにしてもよい。
このような構成により得られる変形例の効果の一例として、端末は、第２種別として端末のアカウントを第４アカウントと関連付けることに関する処理が行われた後、第４アカウントに基づくオブジェクトに関する第２情報をサーバから受信して、第４オブジェクトを表示部に表示することができる。

＜第３実施例＞
第３実施例は、モンスターの生成元の友だちを親として設定することや、それに関連する内容に関する実施例である。

第３実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。

＜表示画面＞
以下では、限定ではなく例として、端末２０Ａに備えられたディスプレイの表示部２４が横長の表示画面となるように端末２０Ａを位置させており、端末２０Ｂに備えられたディスプレイの表示部２４が縦長の表示画面となるように端末２０Ｂを位置させている画面図を例示する。また、ここでは、ゲームアプリケーションにおいて生成されたモンスターの生成元の友だちを、このモンスターの親として設定する例について例示する。

図３－１は、本実施例において端末２０Ａの表示部２４に表示されるゲームアプリケーションの画面と、端末２０Ｂの表示部２４に表示されるメッセージングアプリケーションの画面との一例を示す図である。
ここでは、図３－１左側：（１Ａ）～（４Ａ）にユーザＡ．Ａの端末２０Ａの表示部２４に表示される画面（ホーム画面、生成画面）を、図３－１右側：（１Ｂ）にユーザＢ．Ｂの端末２０Ｂの表示部２４に表示される画面（トークルーム画面）を例示する。

（端末２０Ａの表示画面）
図３－１（１Ａ）～（４Ａ）における表示画面については、前述した図１－８（４）～（６）と同様である部分についての説明を省略する。

図３－１（３Ａ）の画面左下部には、生成元の友だちにモンスター生成結果を通知するための通知ボタンＰＢＴ（本例では、「生成元の友だちに結果を教える」の文字を含むボタン）が表示されている。

（端末２０Ａの表示画面→端末２０Ｂの表示画面）
限定ではなく例として、図３－１（３Ａ）のように、端末２０Ａの表示部２４において通知ボタンＰＢＴがユーザによってタッチされると、限定ではなく例として、端末２０Ｂの表示部２４Ｂにおいて、図３－１（１Ｂ）のような表示がなされる。
この画面は、メッセージングアプリケーションにおけるトークルーム画面であり、画面最上部中央には、メッセージングアプリケーションの名称として「Ｍｅｓｓａｇｉｎｇ Ａｐｐ」の文字が表示されており、画面最上部の右部には、この端末２０Ｂのユーザのメッセージングアプリケーションにおけるアイコン画像およびユーザ名（この例では「ユーザＢ．Ｂ」）が表示されている。

このトークルーム画面では、画面最上部のメッセージングアプリケーションの名称等が表示される領域の下に、限定ではなく例として、メッセージングアプリケーション内のいずれのページ（この例では、トークルーム）が現在表示されているかを示す領域の一種として、トークルームの名称（以下、「トークルーム名」と称する。）を含むトークルーム名表示領域が設けられている。トークルーム名表示領域は、現在ユーザが位置しているメッセージングアプリケーション内のページ（この例では、トークルーム）を示す領域とも言える。
この例では、トークルーム名表示領域には、限定ではなく例として、前の画面に戻るための「＜」の戻るボタンと、ユーザＢ．ＢがユーザＡ．Ａを相手としてトークを行うためのトークルームであることを示す文字（本例では「Ａ．Ａ」）が表示されている。

また、その下には、ユーザＢ．ＢとユーザＡ．Ａとが対話形式でトークを行うためのトーク領域が構成されており、画面向かって左側には相手であるユーザＡ．Ａのメッセージが、画面向かって右側には自分であるユーザＢ．Ｂのメッセージが表示されるように構成されている。
この例では、トーク領域に、ユーザＡ．Ａのアイコンと関連付けて、メッセージＭＳ１（本例では、「君でモンスター生成したらこんなモンスターが生まれたよ」の文字、モンスターＢに対応する生成済アイコンＧＩＣ１Ｂとモンスターの名称、このモンスター生成に関連する詳細な情報をゲームアプリケーションにおいて確認するためのゲームアプリケーションへのリンク情報を含む詳細ボタンＤＢＴ（本例では、「詳細はコチラ」の文字を含むボタン））が表示されている。

ここで、限定ではなく例として、詳細ボタンＤＢＴがユーザＢ．Ｂによってタッチされると、限定ではなく例として、端末２０Ｂにおいてゲームアプリケーションが起動し、メッセージＭＳ１に示されていたモンスター生成に関連する詳細な情報（限定ではなく例として、モンスターＢのパラメータ値、モンスター生成画面など）を含む画面が表示されるようにすることができる（不図示）。

（端末２０Ａの表示画面）
限定ではなく例として、図３－１（３Ａ）のように、端末２０Ａの表示部２４において通知ボタンＰＢＴがユーザによってタッチされた後に、端末２０Ａでモンスター親設定情報を受信すると、限定ではなく例として、図３－１（４Ａ）のような表示がなされる。
この画面では、図３－１（３Ａ）の画面左下部から、通知ボタンＰＢＴ（本例では、「生成元の友だちに結果を教える」の文字を含むボタン）が消去されているとともに、画面左上部には、モンスター親設定完了情報ＰＳＩＣ（本例では、「Ｂ．Ｂが親に設定されました」の文字を含むアイコン）が表示されており、モンスターＢの下方に親アイコン（本例では、「＜親：Ｂ．Ｂ＞」の文字を含むアイコン）が表示されている。

このように、ゲームアプリケーションにおいて生成されたモンスターの生成元の友だちに対してメッセージングアプリケーションを用いてモンスター生成結果を通知することによって、プレーヤであるユーザとは異なる他のユーザに対して本ゲームを広告促進することができる。また、モンスターの生成元の友だちに対してメッセージングアプリケーションを用いてモンスター生成結果を通知するという条件が成立した場合にモンスターの親設定がなされるような構成とすることによって、モンスターの親設定の有無をプレーヤが任意に選択できるようにすることができる。

次に、ゲームアプリケーションにおいてモンスターがバトルに勝利したことを親に通知する例について例示する。

図３－２は、図３－１と同様に、図３－２左側：（１Ａ）～（３Ａ）にユーザＡ．Ａの端末２０Ａの表示部２４に表示される画面（バトル画面）を、図３－１右側：（１Ｂ）にユーザＢ．Ｂの端末２０Ｂの表示部２４に表示される画面（トークルーム画面）を例示する。

（端末２０Ａの表示画面）
図３－２（１Ａ）の画面は、モンスターを用いてバトルするためのバトル画面のうち第３Ｃバトル画面であり、アプリ内位置表示領域には「バトルステージ」の文字が表示されている。
この例では、勝利演出が実行されており、バトル情報表示領域には、第３Ｃバトル情報（限定ではなく例として、「ＷＩＮ」の文字と、喜んだ表情のモンスターＢと、モンスターＢの下方に親アイコン（本例では、「＜親：Ｂ．Ｂ＞」の文字を含むアイコン））が表示されている。

限定ではなく例として、勝利演出が終了されると、限定ではなく例として、図３－２（２Ａ）のような表示がなされる。
この画面は、モンスターを用いてバトルするためのバトル画面のうち第４バトル画面であり、アプリ内位置表示領域には「バトルステージ」の文字が継続して表示されている。

この例では、バトル情報表示領域には、第４バトル情報（限定ではなく例として、「モンスターＢが親に勝利したことをしますか？」および「報告してあげますか？」の文字と、バトルに勝利したメインモンスター（本例では、喜んだ表情のモンスターＢ）と、上記の情報に対して［ＹＥＳ］と答えるためのＹＥＳボタンＢＴ１と、上記の情報に対して［ＮＯ］と答えるためのＮＯボタンＢＴ２）が表示されている。

（端末２０Ａの表示画面→端末２０Ｂの表示画面）
限定ではなく例として、図３－２（２Ａ）のように、端末２０Ａの表示部２４においてＹＥＳボタンＢＴ１がユーザによってタッチされると、限定ではなく例として、端末２０Ｂの表示部２４において、図３－２（１Ｂ）のような表示がなされる。図３－２（１Ｂ）における表示画面については、前述した図３－１（１Ｂ）と同様である部分についての説明を省略する。

この例では、トーク領域に、ユーザＡ．Ａのアイコンと関連付けて、メッセージＭＳ２（本例では、「君から生まれたモンスターが見事勝利したよ！」の文字、モンスターＢに対応する生成済アイコンＧＩＣ１Ｂと、モンスターのバトルに関連する情報（本例では、「ＶＳ」、「モンスターＣ」、および「ＷＩＮ」の文字）と、このバトルに関連する詳細な情報をゲームアプリケーションにおいて確認するためのゲームアプリケーションへのリンク情報を含む詳細ボタンＤＢＴ（本例では、「詳細はコチラ」の文字を含むボタン））が表示されている。

ここで、限定ではなく例として、詳細ボタンＤＢＴがユーザＢ．Ｂによってタッチされると、限定ではなく例として、端末２０Ｂにおいてゲームアプリケーションが起動し、メッセージＭＳ２に示されていたバトルに関連する詳細な情報（限定ではなく例として、このバトルの様子に関連したサムネイル画面（映像）、端末２０Ａの表示部２４において表示されていた第３Ｃバトル画面と同様の画面など）を含む画面が表示されるようにすることができる（不図示）。

（端末２０Ａの表示画面）
限定ではなく例として、図３－２（２Ａ）のように、端末２０Ａの表示部２４においてＹＥＳボタンＢＴ１がユーザによってタッチされると、限定ではなく例として、端末２０Ａの表示部２４において図３－２（３Ａ）のような表示がなされる。
この画面は、モンスターを用いてバトルするためのバトル画面のうち第５バトル画面であり、アプリ内位置表示領域には「バトルステージ」の文字が継続して表示されている。

この例では、バトル情報表示領域には、第５バトル情報（限定ではなく例として、「モンスターＢは喜んでいます。」の文字と、バトルに勝利したメインモンスター（本例では、照れた表情のモンスターＢ））が表示されている。

なお、限定ではなく例として、図３－２（２Ａ）において、端末２０Ａの表示部２４においてＮＯボタンＢＴ２がユーザによってタッチされた場合であっても、限定ではなく例として、端末２０Ａの表示部２４において図３－２（３Ａ）と同様の表示がなされるようにすることができる。
この場合、バトル情報表示領域には、第５バトル情報（限定ではなく例として、「今度会ったら伝えておくよと言うと、モンスターＢは喜んでいた。」の文字と、バトルに勝利したメインモンスター（本例では、照れた表情のモンスターＢ））が表示されるようにすることができる。

このように、モンスターに関連するいずれかのイベントが発生したとき（限定ではなく例として、バトルに勝利したとき、モンスターの育成が完了したとき（パラメータ値が最大値となったとき）等）に、このイベントの発生を、このモンスターの親（生成元の友だち）に対してメッセージングアプリケーションを用いて通知することによって、プレーヤであるユーザとは異なる他のユーザに対して本ゲームを広告促進することができる。

また、イベントの発生を、このモンスターの親（生成元の友だち）に対して通知したか否かに関わらず、同様のバトル情報が表示されるようにすることによって、イベントが発生する毎に親に通知することで親に煩わしさを感じさせてしまうことを防止できる。また、プレーヤもモンスターを蔑ろにしないことでモンスターを育成するというゲーム性を有する本ゲームの興趣が低下してしまうことを防止できる。

次に、ゲームアプリケーションのバトルにおいて、自分のモンスターの親と、敵のモンスターの親とが一致している例について例示する。

本実施例では、ゲームアプリケーションのバトルにおいて、自分のモンスターの親と、敵のモンスターの親とが一致している場合、自分のモンスターのパラメータ値が上昇する絆演出を実行可能である。
この絆演出では、自分のモンスターの親と、敵のモンスターの親とが一致していることが認識可能な場面（限定ではなく例として、自分のモンスターと敵モンスターと「ＶＳ」の文字とが表示されるとき）において、自分のモンスターの近傍に絆エフェクト情報（限定ではなく例として、炎の画像、「ＵＰ」の文字を含む画像、「絆」の文字を含む画像など）が表示されるとともに、状況を説明するための実況情報（限定ではなく例として、スピーカを模した画像および「モンスターＢは張り切っている！」の文字を含む吹き出し画像）が表示される。また、絆演出では、自分のモンスターのパラメータ値が内部的に上昇するので、パラメータ値の上昇値に関連する情報（限定ではなく例として、「ちから｜＋５」の文字、「ＡＬＬ｜＋３」の文字（「ＡＬＬ」とは全パラメータ値のことである。）など）が表示されることによって、絆演出に関連して内部的に上昇したパラメータ値が可視化されてもよい。

図３－３は、本実施例において端末２０Ａの表示部２４に表示されるゲームアプリケーションの画面の一例を示す図である。ここでは、ユーザＡ．Ａの端末２０Ａの表示部２４に表示される画面（バトル画面）を例示する。

図３－３（１）および（２）における表示画面については、前述した図１－１０（３）と同様である部分についての説明を省略する。

図３－３（１）の第２Ｃバトル画面では、バトル情報表示領域には、第２Ｃバトル情報（限定ではなく例として、プレーヤ側のモンスター情報（本例では、モンスターＢと、親アイコン（本例では、「＜親：Ｂ．Ｂ＞」の文字を含むアイコン）と、ユーザＡ．Ａの名前とアイコン画像）、「ＶＳ」の文字と、敵プレーヤ側のモンスター情報（本例では、モンスターＣと、親アイコン（本例では、「＜親：Ｂ．Ｂ＞」の文字を含むアイコン）と、ユーザＢ．Ｂの名前とアイコン画像））が表示されている。

限定ではなく例として、絆演出を実行する条件が成立すると、限定ではなく例として、図３－３（２）のような表示がなされる。
この画面では、絆演出が実行されており、モンスターＢの背景に絆エフェクト情報ＥＦ１（限定ではなく例として、炎の画像）が表示され、モンスターＢの上方に実況情報（限定ではなく例として、スピーカを模した画像および「モンスターＢは張り切っている！」の文字を含む吹き出し画像）が表示されている。

このように、ゲームアプリケーションのバトルにおいて、自分のモンスターの親と、敵のモンスターの親とが一致している場合、自分のモンスターのパラメータ値が上昇されるなどする絆演出が実行されることによって、モンスターの親設定をすることができるゲーム性を有する本ゲームの興趣を向上できる。

＜処理＞
図３－４～図３－５は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。ここでは、図１－１に示した通信システム１Ａを適用する場合の処理例を示し、図１－１２に対応する処理部分を示す。
以下の図では、左から順に、端末２０Ａの制御部２１が実行する処理、サーバ１０の制御部１１が実行する処理、端末２０Ｂの制御部２１が実行する処理をそれぞれ示している。

Ａ１９０のステップの後、端末２０Ａの制御部２１は、表示した一般ＭＡＩＤモンスター生成結果情報における通知ボタンに対するユーザ入力がなされたか否かを判定するなどすることによって、生成元友だちにモンスター生成結果を通知するか否かを判定する（Ｃ２００）。

生成元友だちにモンスター生成結果を通知すると判定したならば（Ｃ２００：ＹＥＳ）、端末２０Ａの制御部２１は、限定ではなく例として、一般ＭＡＩＤモンスター生成結果情報を含むモンスター生成結果通知情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ｃ２１０）。

通信Ｉ／Ｆ１４によって端末２０Ａからモンスター生成結果通知情報を受信すると、サーバ１０の制御部１１は、限定ではなく例として、モンスター生成結果通知情報を、通信Ｉ／Ｆ１４によって端末２０Ｂに送信する（Ｓ１９２）。

通信Ｉ／Ｆ２２によってサーバ１０からモンスター生成結果通知情報を受信すると、端末２０Ｂの制御部２１は、受信したモンスター生成結果通知情報に基づいて、モンスター生成結果通知情報を表示部２４に表示させる（Ｄ２１０）。この場合、端末２０Ｂの制御部２１は、限定ではなく例として、メッセージングアプリケーションによって、モンスター生成結果通知情報を表示部２４（表示部２４に表示されるトークルーム等）に表示させるようにすることができる。

Ｓ１９２のステップの後、サーバ１０の制御部１１は、限定ではなく例として、モンスター親設定処理を行う（Ｓ１９４）。具体的には、限定ではなく例として、モンスター親設定プログラムに従って、モンスター生成結果通知情報に含まれるモンスター（ユーザＢ．Ｂを元に生成されたモンスター）の親として生成元のユーザ（ユーザＢ．Ｂ）を設定する。そして、親設定されたモンスターに関する情報を、ユーザＡ．ＡのプレーヤＩＤが記憶されたプレーヤ管理データに記憶させる。

Ｓ１９４の後、サーバ１０の制御部１１は、限定ではなく例として、モンスター親設定情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ１９６）。

通信Ｉ／Ｆ２２によってサーバ１０からモンスター親設定情報を受信すると、端末２０Ａの制御部２１は、受信したモンスター親設定情報に基づいて、モンスター親設定情報を表示部２４に表示させる（Ｃ２２０）。

なお、端末２０Ｂの制御部２１が、限定ではなく例として、表示部２４に表示されたモンスター生成結果通知情報に対するユーザ入力に基づいて、サーバ１０を介して、メッセージングアプリケーションによってメッセージを端末２０Ａに送信可能としてもよい。そして、端末２０Ａの制御部２１は、受信したメッセージを、メッセージングアプリケーションによって表示可能としてもよい。

図３－６は、本実施例において各装置が実行するモンスターバトル勝利処理の流れの一例を示すフローチャートである。ここでは、図１－１に示した通信システム１Ａを適用する場合の処理例を示す。

まず、端末２０Ａの制御部２１は、限定ではなく例として、モンスターバトルにおいて自分のモンスターが勝利することに決定された（バトルにおいて「敵モンスターの体力を０にした」、「敵モンスターよりも残り体力が多い状態でバトルの制限時間が経過した」等）か否かを判定するなどすることによって、バトルで勝利するか否かを判定する（Ｃ３１０）。

モンスターバトルに勝利したと判定したならば（Ｃ３１０：ＹＥＳ）、端末２０Ａの制御部２１は、限定ではなく例として、自分のモンスターがバトルに勝利した情報を含むバトル勝利情報を表示部２４に表示させる（Ｃ３２０）。

その後、端末２０Ａの制御部２１は、表示したバトル勝利情報（第４バトル画面）におけるＹＥＳボタンに対するユーザ入力がなされたか否かを判定するなどすることによって、生成元友だち（親）にバトル勝利を通知するか否かを判定する（Ｃ３３０）。

生成元友だち（親）にバトル勝利を通知すると判定したならば（Ｃ３３０：ＹＥＳ）、端末２０Ａの制御部２１は、限定ではなく例として、バトル勝利情報を含むバトル勝利通知情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ｃ３４０）。

通信Ｉ／Ｆ１４によって端末２０Ａからバトル勝利通知情報を受信すると、サーバ１０の制御部１１は、限定ではなく例として、バトル勝利通知情報を、通信Ｉ／Ｆ１４によって端末２０Ｂに送信する（Ｓ３１０）。

通信Ｉ／Ｆ２２によってサーバ１０からバトル勝利通知情報を受信すると、端末２０Ｂの制御部２１は、受信したバトル勝利通知情報に基づいて、バトル勝利通知情報を表示部２４に表示させる（Ｄ３１０）。この場合、端末２０Ｂの制御部２１は、限定ではなく例として、メッセージングアプリケーションによって、バトル勝利通知情報を表示部２４（表示部２４に表示されるトークルーム等）に表示させるようにすることができる。

なお、端末２０Ｂの制御部２１が、限定ではなく例として、表示部２４に表示されたバトル勝利通知情報に対するユーザ入力に基づいて、サーバ１０を介して、メッセージングアプリケーションによってメッセージを端末２０Ａに送信可能としてもよい。そして、端末２０Ａの制御部２１は、受信したメッセージを、メッセージングアプリケーションによって表示可能としてもよい。

Ｃ３３０：ＮＯまたはＣ３４０のステップの後、表示したバトル勝利情報（第４バトル画面）におけるＮＯボタンまたはＹＥＳボタンのいずれかのボタンに対するユーザ入力がなされると、端末２０Ａの制御部２１は、バトル勝利通知完了情報を表示部２４に表示させる（Ｃ３５０）。

次いで、端末２０Ａの制御部２１は、モンスターバトル勝利処理を終了するか否かを判定する（Ｃ３６０）。
処理を継続すると判定したならば（Ｃ３６０：ＮＯ）、端末２０Ａの制御部２１は、限定ではなく例として、Ｃ３１０に処理を戻す。
一方、処理を終了すると判定したならば（Ｃ３６０：ＹＥＳ）、端末２０Ａの制御部２１は、モンスターバトル勝利処理の処理を終了する。

Ｓ３１０のステップの後、サーバ１０の制御部１１は、モンスターバトル勝利処理を終了するか否かを判定する（Ｓ３６０）。
処理を継続すると判定したならば（Ｓ３６０：ＮＯ）、サーバ１０の制御部１１は、限定ではなく例として、端末２０Ａからのバトル勝利通知情報の受信を待機し、受信した場合は、再びＳ３１０の処理を実行する。
一方、処理を終了すると判定したならば（Ｓ３６０：ＹＥＳ）、サーバ１０の制御部１１は、モンスターバトル勝利処理を終了する。

次いで、端末２０Ｂの制御部２１は、モンスターバトル勝利処理を終了するか否かを判定する（Ｄ３６０）。
処理を継続すると判定したならば（Ｄ３６０：ＮＯ）、端末２０Ｂの制御部２１は、限定ではなく例として、サーバ１０からのバトル勝利通知情報の受信を待機し、受信した場合は、再びＤ３１０の処理を実行する。
一方、処理を終了すると判定したならば（Ｄ３６０：ＹＥＳ）、端末２０Ｂの制御部２１は、モンスターバトル勝利処理の処理を終了する。

＜第３実施例の効果＞
本実施例は、端末２０は、第１アカウントに基づくモンスター（限定ではなく、第１オブジェクトの一例）に関する設定された条件（限定ではなく、第１条件の一例）が成立したことに基づいて、メッセージングアプリケーションによって第１アカウントに対してモンスターに関するメッセージを送信することに関する処理を制御部２１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、第１オブジェクトに関する第１条件が成立したことに基づいて、ＳＮＳによって第１アカウントに対して第１オブジェクトに関するメッセージを送信することに関する処理を行うことで、第１アカウントのユーザに第１オブジェクトに関するメッセージを届けることができる。

また、この場合、端末２０は、上記のメッセージを送信することに関する処理を行った後、メッセージングサービスによって第１アカウントから送信されたメッセージ（限定ではなく、第１メッセージの一例）を通信Ｉ／Ｆ２２によって受信する。そして、端末２０は、メッセージングサービスによってメッセージを表示部２４に表示するようにしてもよい。
このような構成により得られる実施例の効果の一例として、メッセージを送信することに関する処理を行った後、ＳＮＳによって第１アカウントから送信された第１メッセージを通信部によって受信してＳＮＳによって第１メッセージを表示部に表示することで、第１アカウントから送信された第１メッセージを端末２０のユーザに知らせることができる。

また、本実施例は、ゲーム処理は、モンスターを対戦させる対戦処理を含み、対戦処理は、対戦相手のアカウントが第１アカウントである場合、対戦に関連して所定のイベントを発生させる処理を含む構成を示している。
このような構成により得られる実施例の効果の一例として、対戦相手のアカウントが、オブジェクトを生成する元となったアカウントである場合、限定ではなく例として、対戦に関連する特別なイベントを発生させることが可能となり、ゲームの興趣が向上する。

＜他の実施例＞
（１）オブジェクト（ゲーム内コンテンツ）の生成は、サーバ１０で行われるのに限らず、端末２０で行われるようにしてもよい。

（２）ユーザを識別するための識別情報の一例として、限定ではなく例として、端末２０（またはクラウドサーバ）に保存された連絡先情報に基づいてオブジェクトが取得されるようにしてもよい。つまり、ＳＮＳ等のサービスのアカウントに限らず、端末２０等に保存されている連絡先情報を用いるようにしてもよく、限定ではなく例として、前述したＭＡＩＤに代えて電話番号の情報を用いるなどし、端末２０等に保存された連絡先情報に基づいてオブジェクトが生成されるようにしてもよい。このようにすることで、ＳＮＳで関連付けられているアカウント数が少ないユーザであっても、ある程度の数の連絡先情報が端末２０に登録されていれば、ある程度の数のオブジェクトを用いてゲームをプレイすることが可能となる。
これは、限定ではなく例として、ユーザに関連付けられた他のユーザの識別情報に基づいて、ゲームに登場するオブジェクトが取得されることと考えてもよく、連絡先情報はユーザの識別情報の一例としてもよい。

この場合、端末２０の制御部２１は、オブジェクト取得のための選択肢として、限定ではなく例として、自己の端末２０等に保存された連絡先情報（限定ではなく例として、登録されている電話番号）をリストとして表示し、その中から選択された連絡先情報に基づいてオブジェクトが決定されるようにしてもよい。

なお、自分の連絡先情報に基づいてオブジェクトを取得可能としてもよい。

（３）上記の実施例では、ユーザのアカウントと関連付けられたアカウントに基づいて、ゲームに登場するオブジェクトが取得される例を示したが、ユーザのアカウントと関連付けられたアカウントは、他人のアカウントに限らず、自分のアカウントとしてもよい。限定ではなく例として、サブアカウントを登録可能なサービスで、メインアカウントと関連付けられたサブアカウントに基づいてオブジェクトを取得可能としてもよい。

なお、アカウントを１つしか登録することのできないサービスで自分のアカウントに基づいてオブジェクトを取得可能としてもよいし、サブアカウントを登録可能なサービスでメインアカウントに基づいてオブジェクトを取得可能としてもよい。

（４）上記の実施例では、１つのＳＮＳにおけるアカウントに基づいてオブジェクトが生成される例を示したが、これに限定されない。限定ではなく例として、上記の実施例のアカウント連携処理において、複数のＳＮＳのアカウントを連携することができるようにしてもよい。

この場合、端末２０の制御部２１は、オブジェクト取得のためのリストを表示させる際、またはそれよりも前のタイミングで、どのＳＮＳのアカウントを用いるかをユーザに選択させるための画面（または設定させるための画面）を表示部２４に表示させる。そして、ユーザによって選択（設定）されたＳＮＳのアカウントのリストを表示部２４に表示させ、その中から選択されたアカウントに基づいてモンスターが生成されるようにしてもよい。

また、このリストにおいて、リスト対象ごとに、どのＳＮＳに対応するリストであるかを示す情報（限定ではなく例として、ＳＮＳの種類を示すアイコン）を関連付けて表示させるなど、ユーザが各々のリストを区別可能に表示するようにしてもよい。

（５）上記の実施例では、ゲーム内コンテンツとしてモンスターが登場するゲームの例を示したが、このような例に限定されず、ゲーム内コンテンツとしてモンスターとは異なるコンテンツが登場するゲームであってもよい。

限定ではなく例として、ゲーム内コンテンツとして車両が登場するゲームであってもよい。この場合におけるゲームは、限定ではなく例として、友だちからゲーム内コンテンツ（オブジェクト）の一種である車両を生成し、生成した車両を改造してバトル（レース）を行うゲームとしてもよい。

限定ではなく例として、ゲーム内コンテンツとして人間（人型のキャラクタ）が登場するゲームであってもよい。この場合におけるゲームは、限定ではなく例として、友だちからゲーム内コンテンツ（オブジェクト）の一種である人型のキャラクタを生成し、生成した人型のキャラクタを育成してバトルやストーリーを進めるゲームとしてもよい。

（６）上記の実施例では、ゲームにおけるメインのゲーム内コンテンツ（モンスター等）が友だちから生成される例を示したが、このような例に限定されず、ゲームにおけるメインのゲーム内コンテンツ（モンスター等）とは異なるゲーム内コンテンツが友だちから生成されてもよい。

限定ではなく例として、ゲームにおけるメインのゲーム内コンテンツ（モンスター等）とは異なるサブのゲーム内コンテンツであるモンスターが装備する武器や防具が友だちから生成されてもよい。

（７）上記の実施例では、一の友だちから複数回ゲーム内コンテンツ（モンスター等）が生成される場合、外見やパラメータ値が共通のモンスターが生成される例を示したが、このような例に限定されず、一の友だちから複数回ゲーム内コンテンツ（モンスター等）が生成される場合、外見やパラメータ値が異なるモンスターが生成されてもよい。

限定ではなく例として、一の友だちから２回モンスター生成された場合、限定ではなく例として、２回とも外見が共通のモンスターＡが生成されてもよく、限定ではなく例として、１回目に生成されたモンスターＡのパラメータ値と、２回目に生成されたモンスターＡのパラメータ値とが異なっていてもよい。

また、限定ではなく例として、一の友だちから２回モンスター生成された場合、限定ではなく例として、２回ともパラメータ値が共通であるモンスターＡが生成されてもよく、限定ではなく例として、１回目に生成されたモンスターＡは白色のモンスターＡであり、２回目に生成されたモンスターＡは赤色のモンスターＡであるように、外見が異なっていてもよい。

（８）上記の実施例では、ゲームにおいて他のプレーヤのモンスター（敵モンスター）とバトルを行う例を示したが、このような例に限定されず、ゲームにおいて他のプレーヤのモンスターとともに（共闘して）敵モンスターとバトルを行ってもよく、ゲームにおいて仮想のプレーヤ（ＣＰＵ）のモンスター（敵モンスター）とバトルを行ってもよい。

また、バトルは必須ではなく、限定ではなく例として、上記の実施例において、モンスターの育成のみを行うゲーム（モンスターの育成を楽しむゲーム）としてもよい。

（９）上記の実施例では、一の公式アカウント（Ｚ．Ｚドリンク）を友だちとして登録した場合、ゲーム内コンテンツ（限定モンスター）が生成される例を示したが、このような例に限定されず、友だちとして登録する公式アカウントに応じて、生成されるゲーム内コンテンツの種別が異なってもよい。

限定ではなく例として、第１の公式アカウントを友だちとして登録した場合、ゲーム内コンテンツ（第１の限定モンスター）が生成され、第２の公式アカウントを友だちとして登録した場合、ゲーム内コンテンツ（第２の限定モンスター）が生成されてもよい。

（１０）上記の実施例では、友だちからモンスター生成を行う回数に上限を設けない例を示したが、このような例に限らず、友だちからモンスター生成を行う回数に上限を設けてもよい。

第１変形例（２）にも関連するが、限定ではなく例として、以下に示す（ａ）～（ｃ）のうちの少なくともいずれかの１つの条件が成立した場合にモンスター生成を行えるようにしてもよい。
（ａ）１日に１０回よりも多い回数のモンスター生成を行っていない場合
（ｂ）ゲーム内コンテンツ（モンスター生成用のコイン１枚等）を使用した場合
（ｃ）ゲーム内のイベント（バトルで５連勝）をクリアした場合

（７）上記の実施例では、モンスターがバトルに勝利したことを親に通知するか否かを選択するときに、［ＹＥＳ］または［ＮＯ］の選択肢からプレーヤが選択する例を示したが、このような例に限らず、モンスターがバトルに勝利したことを親に通知するか否かを選択するときに、［ＹＥＳ］または［ＮＯ］の選択肢とは異なる選択肢からプレーヤが選択するようにしてもよい。

限定ではなく例として、モンスターがバトルに勝利したことを親に通知するか否かを選択するときに、［ＹＥＳ］に対応する選択肢として［「メッセージを送るよ」の文字を含む選択肢］、または、［ＮＯ］に対応する選択肢として［「今度会ったときに伝えておくよ」の文字を含む選択肢］からプレーヤが選択するようにしてもよい。

（１１）上記の実施例では、モンスターの外見特徴を異ならせることによってモンスター種別の特徴を出す例を示したが、このような例に限らず、モンスターの外見特徴とは異なる要素を異ならせることによってモンスター種別の特徴を出してもよい。

限定ではなく例として、モンスターに応じてモンスター性格特徴を設けてもよい。モンスター性格特徴には、対応するモンスター種別のモンスターの性格の特徴が設定されており、限定ではなく例として、モンスター種別に応じて、「熱血」、「乱暴」、「まじめ」、「せっかち」等のモンスター性格特徴が設定されてもよい。

また、限定ではなく例として、このモンスター性格特徴が、モンスターの育成やバトルに影響を与えるものであってもよい。限定ではなく例として、モンスターの育成において、「熱血」のモンスター性格特徴を有するモンスターは「体力ＵＰトレーニング」が得意であり（成功率が高い、上昇値が高い）、「乱暴」のモンスター性格特徴を有するモンスターは「ちからＵＰトレーニング」が得意であり、「まじめ」のモンスター性格特徴を有するモンスターは「まもりＵＰトレーニング」が得意であり、「せっかち」のモンスター性格特徴を有するモンスターは「はやさＵＰトレーニング」が得意であってもよい。

また、限定ではなく例として、モンスターに応じてモンスター個体値特徴を設けてもよい。モンスター個体値特徴には、対応するモンスター種別のモンスターの個体値の特徴が設定されており、限定ではなく例として、モンスター種別に応じて、初期値が異なるパラメータ値が設定されてもよい。

（１２）上記の実施例では、一般友だちからモンスターが生成されるときに、一般ＭＡＩＤに基づいて生成されるモンスターの種別（モンスターの種類、性格特徴、個体値特徴なども含む）が決定される例を示したが、このような例に限らず、一般友だちからモンスターが生成されるときに、一般ＭＡＩＤとは異なる情報に基づいて生成されるモンスターの種別が決定されてもよい。

限定ではなく例として、一般友だちからモンスターが生成されるときに、その一般友だちの属性情報（限定ではなく例として、性別、年齢、国籍など）に基づいて生成されるモンスターの種別が決定されてもよい。
ただし、この一般友だちの属性情報を用いてモンスター生成を行う場合、実際にサーバ１０でモンスター生成処理を行う前に、この一般友だちの承認を得るなどする必要がある。

また、限定ではなく例として、一般友だちからモンスターが生成されるときに、そのモンスター生成が行われる時刻、日時、時間帯等に基づいて生成されるモンスターの種別が決定されてもよい。具体的には、０時台～１１時台の期間に生成されたモンスターは、第１の種別のモンスター（限定ではなく例として、モンスターＡ、モンスターＢ、「熱血」、「まじめ」等）が生成される割合が高く、１２時台～２３時台の期間に生成されたモンスターは、第２の種別のモンスター（限定ではなく例として、モンスターＣ、モンスターＤ、「乱暴」、「せっかち」等）が生成される割合が高くなるようにしてもよい。

また、一般ＭＡＩＤを含む上記の各種の情報の組み合わせによって生成されるモンスターの種別が決定されてもよい。

（１３）上記の実施例では、一のプレーヤが既に所持しているモンスターが生成された場合、これらの共通のモンスターの有効な活用方法が設けられていない例を示したが、このような例に限らず、一のプレーヤが既に所持しているモンスターが生成された場合、これらの共通のモンスターの有効な活用方法が設けられてもよい。

限定ではなく例として、共通のモンスターの有効な活用方法として以下に示す方法が設けられてもよい。
（Ａ）モンスター強化の素材（強化アイテム）として変換されプレーヤに付与される（モンスター強化とは、モンスターと強化アイテムとを合成することで、モンスターのパラメータ値などが上昇するゲーム要素である。）
（Ｂ）サポートカードとして変換されプレーヤに付与される

＜第４実施例＞
第４実施例は、生成されたモンスターを、プレーヤがＳＮＳで共有することや、それに関連する内容に関する実施例である。

第４実施例に記載の内容は、他の各実施例や他の変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。

＜システム構成＞
図４－１は、本実施例における通信システム１Ｃのシステム構成の一例を示す図である。
通信システム１Ｃでは、限定ではなく例として、ネットワーク３０を介して、複数のＳＮＳサーバ４０（ＳＮＳサーバ４０Ｘ、ＳＮＳサーバ４０Ｙ、・・・）（ＳＮＳサーバ４０の一種として前述したメッセージングサーバ４０を適用してもよいため、便宜的に「４０」の符号としているが、メッセージングサーバ４０以外のＳＮＳのサーバとしてもよい。）と、ゲームサーバ５０と、複数の端末２０（端末２０Ａ、端末２０Ｂ、・・・、端末２０Ｍ、・・・）とが接続される。
なお、各々の装置のＨＷ構成は、前述した実施例と同様としてよいため、説明を省略する。

ＳＮＳサーバ４０Ｘは、限定ではなく例として、ＳＮＳのうちの第１ＳＮＳに関する情報を管理するサーバ（第１ＳＮＳサーバ）とすることができる。

ＳＮＳサーバ４０Ｙは、限定ではなく例として、ＳＮＳのうちの第２ＳＮＳに関する情報を管理するサーバ（第２ＳＮＳサーバ）とすることができる。

第１ＳＮＳと第２ＳＮＳとは、異なるＳＮＳとすることができ、その種類や形態は問わない。
なお、第１ＳＮＳの事業者と、第２ＳＮＳの事業者とは、異なる事業者としてもよいし、同じ事業者としてもよい。

以下では、限定ではなく例として、第１ＳＮＳを、前述したメッセージングサービスとし、第２ＳＮＳを、メッセージングサービスとは異なるＳＮＳの一例であるビジネスＳＮＳとして説明する場合がある。
また、第１ＳＮＳのアプリケーション（以下、「第１ＳＮＳアプリケーション」と称する。）を「Ｍｅｓｓａｇｉｎｇ Ａｐｐ」とし、第２ＳＮＳのアプリケーション（以下、「第２ＳＮＳアプリケーション」と称する。）を「Ｂｕｓｉｎｅｓｓ Ａｐｐ」として図示・説明する場合がある。

また、以下では、タイムラインを、そのＳＮＳアプリケーションにおいて、ユーザのコメントや出来事などを時系列に表示するもの（時系列に表示した画面）として説明する場合がある。

＜表示画面＞
以下では、プレーヤであるユーザＡ．Ａの端末２０Ａの表示画面と、ユーザＡ．ＡとＳＮＳで友達関係にある（ユーザＡ．Ａのアカウントと自分のアカウントとが関連付けられた関係にある）ユーザＭ．Ｍの端末２０の表示画面とに関する例を説明する。

図４－２は、モンスターの生成結果をＳＮＳで共有する場合の例を示す図である。
（１Ａ）～（３Ａ）に示す画面は、ゲームのプレーヤであるユーザＡ．Ａの端末２０Ａの表示部２４に表示される画面であり、モンスターの生成過程において表示される画面である。これらの説明に関しては、図１－８に関して行った説明と同様であるため、異なる特徴部を除いては、説明を省略する。

なお、前述したように、モンスターの生成は、プレーヤの端末２０Ａからの要求に基づいて、ゲームサーバ５０が実行し、端末２０Ａの制御部２１が通信Ｉ／Ｆ２２を介して、その生成結果を受信する（第１オブジェクトを取得することの一例）ようにしてもよく、端末２０Ａおいて、制御部２１がゲームアプリケーションによって実行する（第１オブジェクトを取得することの一例）ようにしてもよい。

図１－８（６）で示した例とは異なり、図４－２（３Ａ）に示す画面には、共有ボタンＳＢＴが含まれており、共有ボタンＳＢＴには、「生成結果をＳＮＳで共有」と表示されている。ユーザＡ（プレーヤ）が、共有ボタンＳＢＴをタップすることにより、ユーザＡ．Ａがアカウントを持っているＳＮＳ（例えば、第１ＳＮＳ）において、生成されたモンスターに関する情報と、生成元のユーザに関する情報と、が共有されることになる。

図４－２の（１Ｍ）は、ユーザＡ．Ａが共有ボタンＳＢＴをタップすることによって、第１ＳＮＳ（メッセージングアプリケーション）におけるユーザＡ．Ａのアカウントに投稿された内容の一例を示す図である。この端末２０Ｍは、第１ＳＮＳにアカウントを有するユーザＭ．Ｍ（例えば、プレーヤと異なり、生成元のユーザとも異なるユーザ）の端末であり、第１ＳＮＳのアプリケーション（例えば、「Ｍｅｓｓａｇｉｎｇ Ａｐｐ」と表示されるユーザインターフェイスを提供するアプリケーション）を介して、第１ＳＮＳへの投稿内容（第１ＳＮＳ内で共有される情報）が表示されている。

（１Ｍ）の例では、第１ＳＮＳのタイムライン情報として、ユーザＡ．Ａが共有した情報が表示されている。ユーザＡ．Ａが第１ＳＮＳで使用しているプロフィール画像、及び、ユーザＡの第１ＳＮＳにおける登録名（Ａ．Ａ）に対応させて、「Ｂ．Ｂさん（＠ｂｂ１２３４）からモンスター生成したらモンスターＢが生まれたよ。」というメッセージと、生成されたモンスターの画像とが表示されている。このメッセージには、モンスターＢの生成元になったユーザＢ．ＢのアカウントＩＤ（＠ｂｂ１２３４）と、そのアカウントＩＤが含まれるＳＮＳにおけるユーザＢ．Ｂの登録名（Ｂ．Ｂ）と、が含まれている。

また、ユーザＡの投稿内容の下方には、第１ＳＮＳのアカウントを有するユーザＣ．Ｃ（プレーヤと異なり、生成元のユーザとも異なるユーザ）の、アイコン画像及び第１ＳＮＳにおける登録名（Ｃ．Ｃ）に対応して、ユーザＣ．Ｃのメッセージが表示されている。

（１Ｍ）で、モンスターの画像の右側に表示された「ゲームを開く」と表示されたボタンＯＢＴを、ユーザＭ．Ｍがタップすることで、端末２０Ｍにゲームが既にインストールされてる場合には、ユーザＭ．Ｍのゲームアカウントに基づくゲーム画面（例えば、モンスター生成画面）に移行し、インストールされていない場合には、ゲームのインストール画面に移行する。
このようにして、生成されたモンスターがＳＮＳで共有されることにより、ゲームのプレーヤを増加させることが可能である。

（１Ｍ）で、モンスターの生成元となったユーザＢのアカウントＩＤ（＠ｂｂ１２３４）には、リンクが設定されており、ユーザＭ．Ｍが、そのアカウントＩＤをタップすることにより、（２Ｍ）に示すように、そのアカウントＩＤが含まれるＳＮＳの、ユーザＢ．Ｂに関する情報が開示されたページに移行する。

（２Ｍ）の例では、アカウントＩＤ（＠ｂｂ１２３４）が、第１ＳＮＳのアカウントＩＤであることに基づいて、第１ＳＮＳに関するユーザＢ．Ｂのプロフィールが開示された画面に移行している。この例では、ユーザＢ．Ｂのプロフィールとして、第１ＳＮＳにおけるユーザＢ．Ｂのアイコン画像、第１ＳＮＳにおけるユーザＢ．Ｂの登録名（Ｂ．Ｂ）、及び、第１ＳＮＳにおけるユーザＢ．ＢのアカウントＩＤ（＠ｂｂ１２３４）が公開されており、ユーザＢ．Ｂの、ゲームに関するメッセージも表示されている。そして、これらの情報とともに「友だちになる」と表示された友だちボタンＦＯＢＴが表示されている。

ユーザＭ．Ｍが、友だちボタンＦＯＢＴをタップすることにより、端末２０Ｍから第１ＳＮＳのＳＮＳサーバ４０Ｘに対して、生成元のユーザＢ．Ｂに対する友だち登録要求が送信され、これを受信したＳＮＳサーバ４０Ｘは、ユーザＢ．Ｂのアカウント（端末２０Ｂ）に対して、ユーザＭ．Ｍとの友達登録を許可する否かを確認するための確認メッセージを送信する。

端末２０Ｂが受信して、表示部２４に表示した確認メッセージ（例えば、「Ｍ．Ｍさんから友だち登録要求がありました。Ｍ．Ｍさんと友だちになりますか？」）を見たユーザＢ．Ｂが、友だち登録を許可するための入力（例えば、確認メッセージと共に表示された「友だちになる」と表示されたボタンの操作）を行うことで、友だち登録許可がＳＮＳサーバ４０Ｘに送信され、ＳＮＳサーバ４０Ｘにおいて、ユーザＢ．ＢのアカウントＩＤにユーザＭ．ＭのアカウントＩＤが紐づけられる（友だち登録される）。このようにして、ゲームのプレーヤ以外にも、ＳＮＳで友だちを増やすことができるという楽しみを提供できる。

また、ユーザＢ．Ｂは、ユーザＭ．Ｍが第１ＳＮＳにおいて友だちとなったことで、ユーザＢ．Ｂ自身がゲームのプレーヤとなる場合には、以降、ユーザＭ．Ｍを生成元とする（例えば、前述したように、ユーザＭ．Ｍの一般ＭＡＩＤに基づいて）モンスターを生成することが可能となる。このようにして、生成元であり、プレーヤでもあるユーザＢ．Ｂは、自分を生成元とするモンスターが共有されることで、友だちが増え、増えた友だちからモンスターを生成する、といった循環を楽しむことができる。

また、（２Ｍ）の例では、画面下部に「投稿」と表示された投稿ボタンＰＯＢＴと、「いいね」と表示されたいいねボタンＦＡＢＴと、が設けられている。投稿ボタンＰＯＢＴがユーザＭ．Ｍによってタップされると、ユーザＢ．Ｂがこれまでに投稿した情報の一覧が表示される。また、いいねボタンＦＡＢＴがユーザＭ．Ｍによってタップされると、ユーザＢ．Ｂがこれまでに高評価した（ユーザＢ．Ｂがいいねボタンをタップした）、ユーザＢ以外のユーザによる投稿の情報の一覧が表示される。

＜処理＞
図４－３は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左側から順に、ゲームサーバ５０の制御部５１が実行する処理、ＳＮＳサーバ４０Ｘの制御部が実行する処理、ユーザＭ．Ｍの端末２０Ｍの制御部２１が実行する処理をそれぞれ示している。
本処理は、限定ではなく例として、ユーザＡ．Ａの端末２０Ａによって、前述したＡ１９０のステップが行われた後に、この端末２０Ａの制御部２１を含む各装置で実行される処理としてよい。
なお、端末２０Ａの制御部２１の処理については図示を省略している。

また、本処理では、限定ではなく例として、第１ＳＮＳアプリケーションにおいてタイムラインを表示させる端末２０を端末２０Ｍとし、そのユーザをユーザＭ．Ｍとする。

Ａ１９０のステップの後、ゲームサーバ５０の制御部５１は、通信Ｉ／Ｆ１４によって、ユーザＡ．Ａの端末２０ＡからＳＮＳ共有要求情報を受信したか否かを判定する（Ｇ４１０）。
ＳＮＳ共有要求情報は、限定ではなく例として、前述したモンスター生成によって生成されたモンスターと、そのモンスターの生成元（親）のユーザ（以下、「生成元ユーザ」と称する。）とを、この例では第１ＳＮＳのタイムラインに共有することがユーザＡ．Ａによって要求された情報（生成されたオブジェクトと生成元のユーザに対応する対応情報とをＳＮＳにおいて表示させるための情報の一例）としてよい。ＳＮＳ共有要求情報には、ユーザＡ．ＡのアプリケーションＩＤ等の情報の他、限定ではなく例として、モンスターを識別可能な情報や、生成元ユーザを識別可能な情報等を含めてよい。

端末２０ＡからＳＮＳ共有要求情報を受信したと判定したならば（Ｇ４１０：ＹＥＳ）、ゲームサーバ５０の制御部５１は、そのＳＮＳ共有要求情報を、通信Ｉ／Ｆ１４によってＳＮＳサーバ４０Ｘに送信する（Ｇ４３０）。

ＳＮＳサーバ４０Ｘの制御部４１は、通信Ｉ／Ｆ１４によって端末２０ＡからＳＮＳ共有要求情報を受信したか否かを判定し、受信したと判定したならば、ＳＮＳ更新処理を行う（Ｘ４１０）。
具体的には、限定ではなく例として、受信したＳＮＳ共有要求情報に含まれる情報に基づいて、生成されたモンスターと、そのモンスターの生成元ユーザに関する情報とを、第１ＳＮＳで共有させるための処理を行う。

なお、ＳＮＳサーバ４０Ｘの制御部４１が、Ｘ４１０のステップにおいて、ＳＮＳ共有要求情報に含まれる生成元ユーザに関する情報をタイムライン更新情報に含めるか否かの判定を行うようにしてもよい。生成元ユーザに関する情報は、表示させるようにしてもよいし、表示させず秘匿するようにしてもよい。

次いで、ＳＮＳサーバ４０Ｘの制御部４１は、タイムライン更新情報を、通信Ｉ／Ｆ１４によって端末２０Ｍに送信する（Ｘ４３０）。
タイムライン更新情報は、限定ではなく例として、最新のタイムラインの情報に対して、Ｘ４１０のステップの結果に基づく情報を更新して表示させるための情報としてよい。

通信Ｉ／Ｆ２２によってＳＮＳサーバ４０Ｘからタイムライン更新情報を受信すると、端末２０Ｍの制御部２１は、受信したライムライン更新情報に基づくタイムラインを表示部２４に表示させる（Ｍ４３０）。

Ｇ４３０のステップの後、ゲームサーバ５０の制御部５１は、処理の終了判定に進み（Ｇ１９５）、処理を継続すると判定したならば（Ｇ１９５：ＮＯ）、限定ではなく例として、処理を最初に戻し、端末２０ＡからのＳＮＳ共有要求情報の受信を待機する。
処理を終了すると判定したならば（Ｇ１９５；ＹＥＳ）、処理を終了する。

Ｘ４３０のステップの後、ＳＮＳサーバ４０Ｘの制御部４１は、処理の終了判定に進み（Ｘ１９５）、処理を継続すると判定したならば（Ｘ１９５：ＮＯ）、限定ではなく例として、処理を最初に戻し、ゲームサーバ５０からのＳＮＳ共有要求情報の受信を待機する。
処理を終了すると判定したならば（Ｘ１９５；ＹＥＳ）、処理を終了する。

Ｍ４３０の後、端末２０Ｍの制御部２１は、処理の終了判定に進み（Ｍ１９５）、処理を継続すると判定したならば（Ｍ１９５：ＮＯ）、限定ではなく例として、処理を最初に戻し、ＳＮＳサーバ４０Ｘからのタイムライン更新情報の受信を待機する。
処理を終了すると判定したならば（Ｍ１９５；ＹＥＳ）、処理を終了する。

なお、本処理では、端末２０Ａからゲームサーバ５０に対してＳＮＳ共有要求情報が送信されることとしたが、これに限定されない。
限定ではなく例として、端末２０ＡからＳＮＳサーバ４０Ｘに対してＳＮＳ共有要求情報が送信されるようにしてもよい。

（フローチャートにおける各装置の制御）
（Ｆ－１）上記の実施例において、端末２０Ａが、ユーザＡ．Ａの入力（共有ボタンＳＢＴの操作）に基づいて、ＳＮＳ共有要求情報をゲームサーバ５０（または、ゲームサーバ５０を介してＳＮＳサーバ４０Ｘ）に送信する制御は、端末２０において実行される、生成されたモンスター（限定ではなく、第１オブジェクトの一例）と、そのモンスターの生成元ユーザに関する情報（限定ではなく、第１アカウントに対応する対応情報の一例）とを、ＳＮＳにおいて表示させるための制御（限定ではなく、第１制御の一例）である。

ＳＮＳにおいて第１オブジェクトと対応情報とが表示されること（ＳＮＳにおいて第１オブジェクトと対応情報とが共有されることとしてもよい）には、限定ではなく例として、そのＳＮＳにアカウントを有するユーザＭ．Ｍ（プレーヤとは異なり、生成元とも異なるユーザ）の端末２０Ｍにおいて、ＳＮＳサーバ４０から受信した情報に基づく、第１オブジェクトと対応情報の表示が行われること（例えば、図４－３のＭ４３０、後述する図４－１２のＭ４３２、図４－１４のＭ４３４やＭ４７４）が含まれてよい。

また、ＳＮＳにおいて第１オブジェクトと対応情報とが表示されること（ＳＮＳにおいて第１オブジェクトと対応情報とが共有されることとしてもよい）には、限定ではなく例として、そのＳＮＳにアカウントを有する生成元のユーザである、ユーザＢ．Ｂの端末２０Ｂにおいて、ＳＮＳサーバ４０から受信した情報に基づく、第１オブジェクトと対応情報の表示が行われること（例えば、図４－３のＭ４３０、後述する図４－１２のＭ４３２、図４－１４のＭ４３４やＭ４７４に相当する処理）が含まれてよい。

また、ＳＮＳにおいて第１オブジェクトと対応情報とが表示されること（ＳＮＳにおいて第１オブジェクトと対応情報とが共有されることとしてもよい）には、限定ではなく例として、そのＳＮＳにアカウントを有するプレーヤである、ユーザＡ．Ａ（共有ボタンＳＢＴを操作したプレーヤ）の端末２０Ａ自体において、ＳＮＳサーバ４０から受信した情報に基づく、第１オブジェクトと対応情報の表示が行われること（例えば、図４－３のＭ４３０、後述する図４－１２のＭ４３２、図４－１４のＭ４３４やＭ４７４に相当する処理）が含まれてよい。

また、上記の第１制御には、端末２０に対するユーザ入力の有無に関わらず、サーバに対して情報の共有を要求する制御（共有要求情報を送信する制御）が含まれてもよい。
また、第１制御には、限定ではなく例として、端末２０に対するユーザ入力に基づく情報の手動共有／自動共有の設定を行う制御が含まれてもよい。限定ではなく例として、ユーザが事前に自動共有「有」に設定し、その設定情報が端末２０からサーバに送信され、サーバによって、そのユーザのアカウントと関連付けて自動共有「有」が記憶されるようにすることによって、情報がサーバから自動で共有されるようにしてもよい。
また、ユーザによる設定ではなく、サーバ側で自動共有「有」に設定されるようにするなどしてもよい。

（Ｆ－２）端末２０でゲームアプリケーションが実行されている場合に、限定ではなく例として、情報を共有する入力がなされたことに基づいて、ＳＮＳのアプリケーションが起動（ゲームアプリケーション上にＳＮＳのアプリケーションを展開することを含む。）され、そのＳＮＳのアプリケーションから、端末２０のユーザがＳＮＳサーバ４０に対して情報の投稿を指示することができるようにしてもよい。

図４－４は、生成されたモンスターを共有しようとするプレーヤの端末２０Ａにおいて、ゲームアプリケーションと連携したＳＮＳアプリケーションによって共有が行われる例を示す画面図である。
（１）は、図４－２の（３Ａ）に示した図と同様の図である。

（１）で、プレーヤが、共有ボタンＳＢＴをタップすると、その入力操作に基づいて、ゲームアプリケーションと連携した第１ＳＮＳのＳＮＳアプリケーションが起動して、（２）に示すように、ゲームアプリケーションのユーザーインターフェイス（ＵＩ）とともに、ＳＮＳアプリケーションのユーザーインターフェイス（ＵＩ）が表示される。なお、ゲームアプリケーションのＵＩが非表示となった後に、ＳＮＳアプリケーションのＵＩが表示されるようにしてもよい。

（２）では、ＳＮＳアプリケーションのＵＩ内に、第１ＳＮＳ（共有先のＳＮＳ）におけるプレーヤのアイコン画像及び登録名（Ａ．Ａ）に関連付けて（つまり、プレーヤの投稿内容として）、第１ＳＮＳにおける生成元のユーザの登録名（Ｂ．Ｂ）とアカウントＩＤ（＠ｂｂ１２３４）、生成元のユーザから生成されたモンスターＢの画像が表示されている。

さらに、ＳＮＳアプリケーションのＵＩ内には、投稿ボタンＰＯＢＴと、キャンセルボタンＣＡＢＴとが表示されており、プレーヤが、投稿ボタンＰＯＢＴをタップすると、ＳＮＳアプリケーションのＵＩ内の情報（第１ＳＮＳにおける生成元のユーザの登録名（Ｂ．Ｂ）とアカウントＩＤ（＠ｂｂ１２３４）、生成元のユーザから生成されたモンスターＢの画像）が、プレーヤの投稿として（プレーヤのアイコン画像及び登録名（Ａ．Ａ）とともに）第１ＳＮＳで共有されることになる。

そして、（３）に示すように、ＳＮＳアプリケーションのＵＩにおいて、投稿が完了したこと（第１ＳＮＳで情報が共有されたこと）が通知される。
一方、（２）でキャンセルボタンＣＡＢＴがタップされた場合には、ＳＮＳアプリケーションのＵＩ内の情報は共有されない。

図４－５は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左側に、端末２０Ａの制御部２１が実行する処理を示し、右側に、第１ＳＮＳのＳＮＳサーバ４０Ｘの制御部４１が実行する処理を示している。

端末２０Ａの制御部２１は、ゲームアプリケーションにおいて、入出力部２３を介して、情報をＳＮＳ共有する入力がなされたか否かを判定する（Ａ５１０）。
なされなかったと判定したならば（Ａ５１０：ＮＯ）、端末２０Ａの制御部２１は、Ａ５９０の終了判定に処理を進める。

入力がなされたと判定したならば（Ａ５１０：ＹＥＳ）、端末２０Ａの制御部２１は、記憶部２８に記憶されたＳＮＳアプリケーションの処理プログラムに基づき、実行中のゲームアプリケーション上にＳＮＳアプリケーション（この例では、第１ＳＮＳアプリケーション）を展開し、ＳＮＳサーバ４０Ｘとの通信を開始する（Ａ５２０）。
この場合、限定ではなく例として、ＳＮＳアプリケーションをフォアグラウンド状態に制御し、ゲームアプリケーションをバックグラウンド状態に制御するようにしてもよい。

ＳＮＳサーバ４０Ｘの制御部４１は、ＳＮＳに共有する情報（ＳＮＳ共有情報）を取得する（Ｘ５１０）。
この場合、限定ではなく例として、ＳＮＳサーバ４０Ｘの制御部４１は、以下のいずれかによってＳＮＳ共有情報を取得するようにしてよい。
・ゲームサーバ５０から取得（ゲームサーバ５０からＳＮＳサーバ４０Ｘに情報送信）
・端末２０Ａから取得（端末２０ＡからＳＮＳサーバ４０Ｘに情報送信）

次いで、ＳＮＳサーバ４０Ｘの制御部４１は、取得したＳＮＳ共有情報に基づく投稿確認情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｘ５２０）。
この投稿確認情報には、限定ではなく例として、図４－４（２）に示したような情報を含めてよい。
なお、モンスターの生成元情報は投稿確認情報に含めなくてもよい。

Ａ５２０の後、通信Ｉ／Ｆ２２によってＳＮＳサーバ４０Ｘから投稿確認情報を受信すると、端末２０Ａの制御部２１は、展開したＳＮＳアプリケーションで投稿確認情報を表示する（Ａ５３０）。
この場合、限定ではなく例として図４－４に示したように、ゲームアプリケーションの画面の少なくとも一部に重畳するようにＳＮＳアプリケーションの領域を表示させ、この領域に投稿確認情報を表示させるようにしてもよい。

次いで、端末２０Ａの制御部２１は、入出力部２３を介して、投稿確認情報を編集する入力されたか否かを判定する（Ａ５４０）。なお、この入力には、投稿確認情報に加えて追加で投稿するコメントの入力を含めてもよい。
入力されなかったと判定したならば（Ａ５４０：ＮＯ）、端末２０Ａの制御部２１は、Ａ５５０のステップをスキップする。

入力がなされたと判定したならば（Ａ５４０：ＹＥＳ）、端末２０Ａの制御部２１は、入力内容に基づき、投稿確認情報を更新（記憶更新、表示更新）する（Ａ５５０）。

なお、Ａ５４０、Ａ５５０のステップは行わないようにしてもよい。

次いで、端末２０Ａの制御部２１は、入出力部２３を介した投稿の入力（限定ではなく例として、図４－４の投稿ボタンＰＯＢＴに対する操作入力）に基づいて、投稿要求情報を、通信Ｉ／Ｆ２２によってＳＮＳサーバ４０Ｘに送信する（Ａ５６０）。
この場合、Ａ５５０のステップを行った場合、更新後の投稿確認情報を投稿要求情報に含めてＳＮＳサーバ４０Ｘに送信するようにしてよい。
そして、端末２０Ａの制御部２１は、Ａ５９０の終了判定に処理を進める。

通信Ｉ／Ｆ４４によって端末２０Ａから投稿要求情報を受信すると、ＳＮＳサーバ４０Ｘの制御部４１は、受信した投稿要求情報に基づき、前述した、ＳＮＳ更新処理（Ｘ４１０）と端末２０Ｍへのタイムライン更新情報の送信（Ｘ４３０）とを行う。
そして、ＳＮＳサーバ４０Ｘの制御部４１は、Ｘ５９０の終了判定に処理を進める。

なお、Ａ５１０のステップに際して、ユーザＡ．Ａが、複数のＳＮＳの中から、いずれのＳＮＳに情報を共有するかを選択することができるようにしてもよい。
この場合、端末２０Ａの制御部２１は、ユーザによって選択されたＳＮＳに対応するＳＮＳアプリケーション（第１ＳＮＳが選択された場合は第１ＳＮＳアプリケーション、第２ＳＮＳが選択された場合は第２ＳＮＳアプリケーション）を展開し、そのＳＮＳに対応するＳＮＳサーバ４０（第１ＳＮＳが選択された場合はＳＮＳサーバ４０Ｘ、第２ＳＮＳが選択された場合はＳＮＳサーバ４０Ｙ）と通信して、上記と同様の処理を行うようにしてよい。

図４－５の処理では、ＳＮＳサーバ４０Ｘの制御部４１が、ＳＮＳに共有する情報（ＳＮＳ共有情報）を、ゲームサーバ５０または端末２０Ａから取得した（Ｘ５１０）後、端末２０Ａから投稿要求情報を受信したことに基づいて、ＳＮＳ更新処理を実行する（Ｘ４１０）例について説明したが、このような形態に限らず、端末２０Ａにおいて、ＳＮＳ共有情報が、ゲームアプリケーションから共有先のＳＮＳのＳＮＳアプリケーションに出力されたことに基づいて、ＳＮＳサーバ４０Ｘの制御部４１が、ＳＮＳ更新処理を実行するようにしてもよい。

図４－６は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。

端末２０Ａの制御部２１は、ゲームアプリケーションにおいて、入出力部２３を介して、情報をＳＮＳ共有する入力がなされたか否かを判定する（Ａ６１０）。
なされなかったと判定したならば（Ａ６１０：ＮＯ）、端末２０Ａの制御部２１は、Ａ６９０の終了判定に処理を進める。

入力がなされたと判定したならば（Ａ６１０：ＹＥＳ）、端末２０Ａの制御部２１は、実行中のゲームアプリケーションによって、ＳＮＳで共有させるための投稿用情報を生成する（Ａ６２０）。投稿用情報には、限定ではなく例として、図４－４（２）に示したような、第１ＳＮＳにおける生成元のユーザの登録名（Ｂ．Ｂ）とアカウントＩＤ（＠ｂｂ１２３４）、生成元のユーザから生成されたモンスターＢの画像を含めてよい。
なお、モンスターの生成元情報は投稿用情報に含めなくてもよい。

端末２０Ａの制御部２１は、ゲームアプリケーションにおいて、生成した投稿用情報を表示部２４に表示させる（Ａ６３０）。この際、表示部２４には、投稿用情報とともに、その投稿用情報をＳＮＳで共有させるための、図４－４（２）に示したような投稿ボタンＰＯＢＴも表示される。
なお、本例では、この時点でＳＮＳアプリケーションは起動されていないため、図４－４（２）に示したようなＳＮＳアプリケーションのＵＩは表示されていないが、ゲームアプリケーションによって、予め記憶部２８に記憶されているＳＮＳのＵＩ画像（限定ではなく例として、ＳＮＳアプリケーションのＵＩを模した画像）を投稿用情報とともに表示させるようにしてもよい。

端末２０Ａの制御部２１は、ユーザＡ．Ａが投稿ボタンＰＯＢＴを操作したか否か（入出力部２３を介して、投稿用情報をＳＮＳで共有するための入力がなされたか否か）を判定する（Ａ６４０）。
なされなかったと判定したならば（Ａ６４０：ＮＯ）、端末２０Ａの制御部２１は、Ａ６９０の終了判定に処理を進める。

端末２０Ａの制御部２１は、入力がなされたと判定したならば（Ａ６４０でＹＥＳ）、ゲームアプリケーションに連携した（ゲームアプリケーションに関連付けて記憶部２８に記憶されている）ＳＮＳアプリケーションを起動させる（Ａ６５０）。
本例では、ゲームアプリケーションと連携したＳＮＳアプリケーションが第１ＳＮＳのＳＮＳアプリケーションであることに基づいて、Ａ６５０の処理によって、第１ＳＮＳのＳＮＳアプリケーションが起動する。

端末２０Ａの制御部２１は、ゲームアプリケーションにおいて、ゲームアプリケーションが生成した投稿用情報（投稿用情報が格納されている領域の情報（限定ではなく例として、ＵＲＩ（ＵＲＬ等）としてもよい）を、起動させた第１ＳＮＳのＳＮＳアプリケーションに出力する（Ａ６６０）。
このように、本形態では、端末２０Ａにおいて、ゲームアプリケーションによって生成された投稿用情報は、端末２０Ａにおいて、第１ＳＮＳのＳＮＳアプリケーションによって取得され、第１ＳＮＳのＳＮＳアプリケーションを介して、ＳＮＳサーバ４０Ｘに記憶される。

ＳＮＳサーバ４０Ｘの制御部４１は、第１ＳＮＳのＳＮＳアプリケーションを介した投稿用情報の受信に基づいて、投稿用情報を送信したＳＮＳアプリケーションのアプリケーションＩＤ（プレーヤであり投稿者（共有者）であるユーザＡ．Ａを一意に特定できる識別情報）に基づいて、限定ではなく例として、アプリケーションＩＤに関連付けられたプロフィール画像と、登録名（Ａ．Ａ）とを特定する。

ＳＮＳサーバ４０Ｘの制御部４１は、特定した情報と、取得した投稿用情報とを対応させて第１ＳＮＳで共有するための、ＳＮＳ更新処理（Ｘ４１０）と端末２０Ｍへのタイムライン更新情報の送信（Ｘ４３０）とを行う。
そして、ＳＮＳサーバ４０Ｘの制御部４１は、Ｘ６９０の終了判定に処理を進める。

なお、Ａ６５０のステップに際して、ユーザＡ．Ａが、複数のＳＮＳの中から、いずれのＳＮＳに情報を共有するかを選択することができるようにしてもよい。
この場合、端末２０Ａの制御部２１は、ユーザによって選択されたＳＮＳに対応するＳＮＳアプリケーション（第１ＳＮＳが選択された場合は第１ＳＮＳアプリケーション、第２ＳＮＳが選択された場合は第２ＳＮＳアプリケーション）を起動させ、ゲームアプリケーションにより生成された投稿用情報が、ゲームアプリケーションから、選択されたＳＮＳに対応するＳＮＳアプリケーションに出力され、そのＳＮＳで共有されることになる。

このように、端末２０Ａにおいて、ゲームアプリケーションによって、ＳＮＳでプレーヤ（端末のユーザの一例）と友だち関係にあるユーザのアカウント（第１アカウントの一例）に基づいて生成されたモンスター（第１オブジェクトの一例）が取得された場合に、ゲームアプリケーションが、生成されたモンスターと、生成元情報（第１アカウントに対応する対応情報の一例）とを、共有先となるＳＮＳのＳＮＳアプリケーションに出力する（ＳＮＳにおいて表示させるための第１制御の一例）ようにしてもよい。

なお、ゲームアプリケーションが、生成されたモンスターと、生成元情報とを、共有先となるＳＮＳのＳＮＳアプリケーションで読込可能な記憶領域（限定ではなく例として、端末２０の記憶領域であってもよく、ゲームサーバ５０の記憶領域であってもよく、ＳＮＳサーバ４０の記憶領域であってもよい）に記憶させた後、ＳＮＳアプリケーションが起動して、その記憶領域の情報を読み込んで、ＳＮＳで共有するようにしてもよい。

（Ｆ－３）限定ではなく例として、特定のモンスター（限定ではなく例として、モンスターＺのような特典の対象となるモンスター）が生成された場合にのみ、プレーヤの端末２０による上記の第１制御が可能となってもよい。
また、デフォルトでは端末２０によって上記の第１制御が行われる設定とされるが、上記の特定のモンスターが生成された場合は、上記の第１制御によらず、その特定のモンスターに関する情報がサーバから端末に自動で共有されるようにしてもよい。

（Ｆ－４）端末２０またはゲームサーバ５０からＳＮＳサーバ４０に対してモンスター画像や生成元情報等の情報を送信することには、限定ではなく例として、これらの情報のデータ自体を送信することが含まれてもよいし、これらの情報の格納場所に関する情報（限定ではなく例として、ＵＲＩ）を送信することが含まれてもよい。
また、端末２０に対してモンスター画像や生成元情報等の情報を共有することには、限定ではなく例として、これらの情報のデータ自体を端末２０に送信することが含まれてもよいし、これらの情報の格納場所に関する情報（限定ではなく例として、ＵＲＩ）を端末２０に送信することが含まれてもよい。

本形態では、ＳＮＳ（第１ＳＮＳ及び第２ＳＮＳの少なくとも一方）においてユーザＡ．Ａ（プレーヤ）のアカウント（端末のユーザのアカウントの一例）と関連付けられたユーザのアカウント（第１アカウントの一例）に基づいて生成されたモンスター（第１オブジェクトの一例）をユーザＡ．Ａの端末２０Ａの制御部２１が取得して、生成されたモンスターと、生成元のユーザのアカウントに対応する情報（第１アカウントに対応する情報の一例であり、例えば、アカウントＩＤまたはＳＮＳ名）とを、ＳＮＳ（例えば、第１ＳＮＳ及び第２ＳＮＳの少なくとも一方）で表示させるための制御（第１制御の一例）が、ユーザＡ．Ａの端末２０Ａに対する入力に基づいて実行されている。
これにより、ＳＮＳのユーザ間で第１オブジェクトの情報を共有することができるため、ＳＮＳ内でのゲームに関するコミュニケーションを活発化させることができる。

（生成元情報に関する変形例（１））
図４－７は、生成されたモンスターがＳＮＳで共有される場合の変形例を示す図である。
図４－２の（１Ｍ）に示した例とは異なり、「Ｍｅｓｓａｇｉｎｇのフレンドからモンスター生成したらモンスターＢが生まれたよ。」というメッセージ（つまり、生成元となったＳＮＳ名を知らせる情報）が表示されるとともに、モンスター画像の下端に、生成元となったＳＮＳにおける生成元のユーザの登録名（Ｂ．Ｂ）と、アカウントＩＤ（＠ｂｂ１２３４）と、が表示されている。

さらに、モンスターＢの画像として、生成元のユーザＢ．Ｂのアイコン画像（例えば、生成元のＳＮＳでユーザＢ．Ｂのプロフィール画像として使用されているアイコン画像）を加工（例えば、画像処理により表示角度を変更）してモンスターＢと融合した画像が表示されている。
このように、生成元のユーザの情報を加工して、生成されたモンスターの画像に反映させることで、ＳＮＳで共有された場合に、様々な反応を期待することができる。

（生成元情報に関する変形例（２））
図４－８は、生成されたモンスターがＳＮＳで共有される場合の変形例（図４－２の（１Ｍ）や図４－７とは異なる例）を示す図である。
（３Ａ）に示す画面で、ユーザＡ．Ａ（プレーヤ）が、共有ボタンＳＢＴをタップすることにより、（１Ｍ）に示すように、端末２０Ｍにおいて、第１ＳＮＳのタイムライン情報として、ユーザＡが共有した情報が表示されている。図４－２の（１Ｍ）や図４－７に示した例とは異なり、生成元のユーザの登録名やアカウントＩＤ等は表示されておらず、「Ｍｅｓｓａｇｉｎｇのフレンドからモンスター生成したらモンスターＢが生まれたよ。」というメッセージ（つまり、生成元となったユーザが属するＳＮＳ名を知らせる情報）のみが表示されている。

このように、生成されたモンスターを共有する場合に、生成元のユーザを一意に特定できるような情報は開示しないようにすることもできる。
以下の説明では、前述した図４－２（１Ｍ）や、図４－７のように、ＳＮＳにおいて、生成されたモンスターの画像とともに共有される生成元のユーザの情報が、アカウントＩＤを含む場合（生成元のユーザの識別性が高い場合）、その情報を第１態様の生成元情報（第１態様の対応情報の一例）と称し、アカウントＩＤを含まない場合（生成元のユーザの識別性が低い場合）、その情報を第２態様の生成元情報（第２態様の対応情報の一例）と称する場合がある。

（生成元情報に関する変形例（３））
図４－９及び図４－１０は、第２態様の生成元情報に関する具体例である。
図４－９に関しては、「Ｍｅｓｓａｇｉｎｇのフレンドからモンスター生成したらモンスターＢが生まれたよ。」というメッセージ（つまり、生成元となったユーザが属するＳＮＳ名を知らせる情報）のみが表示されている一方、図４－１０に関しては、そのメッセージに加えて、生成元のユーザの画像と、生成元のＳＮＳにおける登録名（Ｂ．Ｂ）とが開示されている。第２態様の生成元情報をどのような態様にするのかを、プレーヤとなるユーザ側や、生成元となるユーザ側で設定できるようにしてもよい。

＜第４変形例（１）＞
図４－１１は、ゲームのプレーヤが、第１ＳＮＳ（限定ではなく例として、Ｍｅｓｓａｇｉｎｇ Ａｐｐ）と、第２ＳＮＳ（限定ではなく例として、Ｂｕｓｉｎｅｓｓ Ａｐｐ）とで、自分のアカウントを有している場合の例である。
この場合、（１）に示すように、プレーヤ（ユーザＡ．Ａ）の端末２０Ａは、ゲームのアプリケーション（Ｇａｍｅ Ａｐｐ）を介して、ゲームサーバ５０とのアカウント連携処理の対象となった（図１－１４を参照）ＳＮＳサーバ４０Ｘからは、第１ＳＮＳにおいて、自分のアカウントに紐づけられた友だち一覧情報（生成元の候補となるアカウントに関する情報）を取得し、同じく、ゲームサーバ５０とのアカウント連携処理の対象となった（図１－１４を参照）ＳＮＳサーバ４０Ｙからは、第２ＳＮＳにおいて、自分のアカウントに紐づけられた友だち一覧情報（生成元の候補となるアカウントに関する情報）を取得することができる。

（１）に示すように、端末２０Ａの表示部２４には、第１ＳＮＳの友だち一覧情報に基づく友だちのリスト（Ｍｅｓｓａｇｉｎｇ 友だち）と、第２ＳＮＳの友だち一覧情報に基づく友だちのリスト（Ｂｕｓｉｎｅｓｓ 友だち）と、がそれぞれ表示される。
第１ＳＮＳのそれぞれの友だちのアイコンに対応させて、生成実行ボタンＭＧＢＴが設けられており、第２ＳＮＳのそれぞれの友だちのアイコンに対応させて、生成実行ボタンＭＧＢＴが設けられているため、プレーヤ（ユーザＡ．Ａ）に、第１ＳＮＳの友だちと、第２ＳＮＳの友だちのどちらを生成元にするかといった選択肢を提供することができる。

次いで、プレーヤ（ユーザＡ．Ａ）が、生成元として選択した友だちが、第１ＳＮＳの友だちであった場合（第１ＳＮＳの友だちに対応して表示された生成実行ボタンＭＧＢＴが選択された場合）、（２Ａ）に示すように、第１ＳＮＳの友だちのアカウント（限定ではなく例として、一般ＭＡＩＤ）に基づくモンスターが生成されて、共有ボタンＳＢＴとともに端末２０Ａの表示部２４に表示される。
一方、プレーヤ（ユーザＡ．Ａ）が、生成元として選択した友だちが、第２ＳＮＳの友だちであった場合（第２ＳＮＳの友だちに対応して表示された生成実行ボタンＭＧＢＴが選択された場合）、（２Ｂ）に示すように、第２ＳＮＳの友だちのアカウント（限定ではなく例として、一般ＭＡＩＤ）に基づくモンスターが生成されて、共有ボタンＳＢＴとともに端末２０Ａの表示部２４に表示される。

（２Ａ）で、共有ボタンＳＢＴが操作されたことに基づいて、（１ＭＡ）に示すように、第１態様の生成元情報が第１ＳＮＳで共有される。すなわち、プレーヤのアカウントと生成元のユーザのアカウントとが第１ＳＮＳで関連付けられていることに基づいて、生成されたモンスターとともに、第１態様（アカウントＩＤ有）の生成元情報がＳＮＳ（本例では、第１ＳＮＳのＭｅｓｓａｇｉｎｇ Ａｐｐ）で共有される。（１ＭＡ）は、第１ＳＮＳにアカウントを有するユーザＭ．Ｍの端末２０Ｍにおける表示画面である。

一方、（２Ｂ）で、共有ボタンＳＢＴが操作されたことに基づいて、（１ＭＢ）に示すように、第２態様の生成元情報が第１ＳＮＳで共有される。すなわち、プレーヤのアカウントと生成元のユーザのアカウントとが第２ＳＮＳで関連付けられていることに基づいて、生成されたモンスターとともに、第２態様（アカウントＩＤ無）の生成元情報がＳＮＳ（本例では、第１ＳＮＳのＭｅｓｓａｇｉｎｇ Ａｐｐ）で共有される。（１ＭＢ）は、第１ＳＮＳにアカウントを有するユーザＭの端末２０Ｍにおける表示画面である。

＜処理＞
図４－１２は、本実施例において各装置によって実行される処理の流れの一例を示すフローチャートである。図の見方は、図４－３と同様とすることができる。
Ｇ４１０のステップにおいて端末２０ＡからＳＮＳ共有要求情報を受信したと判定したならば（Ｇ４１０：ＹＥＳ）、ゲームサーバ５０の制御部５１は、タイムラインに更新して表示させる情報の態様に関する設定を行う（Ｇ４２０）。
具体的には、限定ではなく例として、ゲームアプリケーションにおけるモンスターの生成元のＳＮＳが第１ＳＮＳである場合、第１態様の設定（以下、「第１態様設定」と称する。）として、限定ではなく例として、生成元ユーザのアカウントの表示を「有」に設定する一方、ゲームアプリケーションにおけるモンスターの生成元のＳＮＳが第２ＳＮＳである場合、第１態様とは異なる第２態様の設定（以下、「第２態様設定」と称する。）として、限定ではなく例として、生成元ユーザのアカウントの表示を「無」に設定する。

なお、この場合における第１態様設定と第２態様設定とを逆にしてもよい。
また、態様設定をいずれも第１態様設定としてもよいし、態様設定をいずれも第２態様設定としてもよい。

次いで、ゲームサーバ５０の制御部５１は、Ｇ４２０のステップにおける態様の設定情報（以下、「態様設定情報」と称する。）を含むＳＮＳ共有要求情報を、通信Ｉ／Ｆ５４によってＳＮＳサーバ４０Ｘに送信する（Ｇ４３２）。

ＳＮＳサーバ４０Ｘは、通信Ｉ／Ｆ４４によってゲームサーバ５０からＳＮＳ共有要求情報を受信したと判定したならば、ゲームサーバ５０から受信したＳＮＳ共有要求情報に基づいて、前述したＳＮＳ更新処理を行う（Ｘ４１２）。この場合、ＳＮＳサーバ４０Ｘの制御部４１は、ゲームサーバ５０から受信したＳＮＳ共有要求情報に含まれる態様設定情報に基づいて、タイムラインに表示させる情報の態様を判定するようにしてよい。
そして、ＳＮＳサーバ４０Ｘの制御部４１は、Ｘ４３０のステップに処理を進める。

この場合、端末２０Ｍの制御部２１が、Ｍ４３２のステップにおいて、第１ＳＮＳアプリケーションでタイムライン更新情報に基づくタイムラインを表示する場合、モンスターの生成元のＳＮＳが第１ＳＮＳである場合は、更新して表示されるタイムライン情報が第１態様で表示され、モンスターの生成元のＳＮＳが第２ＳＮＳである場合は、更新して表示されるタイムライン情報が第２態様で表示される。

なお、本処理では、端末２０Ａからゲームサーバ５０に対してＳＮＳ共有要求情報が送信されることとしたが、これに限定されない。
限定ではなく例として、端末２０ＡからＳＮＳサーバ４０Ｘに対してＳＮＳ共有要求情報が送信されるようにしてもよい。そして、ＳＮＳサーバ４０Ｘの制御部４１が、Ｇ４２０のステップと同様の、タイムラインに更新して表示させる情報（生成元ユーザに関する情報）の態様に関する設定を行うようにしてもよい。

また、第１態様と第２態様とのいずれの態様で情報を表示させるかをユーザに選択させるための態様選択用情報を端末２０Ａの表示部２４に表示させるようにし、ユーザによる入力に基づいて選択された態様の情報を含むＳＮＳ共有要求情報が、端末２０Ａから送信されるようにしてもよい。

また、共有先のＳＮＳは、必ずしも第１ＳＮＳである必要はなく、第２ＳＮＳとしてもよいし、第１ＳＮＳおよび第２ＳＮＳとは異なる第３ＳＮＳであってもよい。

（アプリケーション間の連携）
なお、図４－１２で、Ｇ４２０及びＧ４３２に相当する処理が、プレーヤの端末２０Ａで実行されるようにしてもよい。
限定ではなく例として、図４－４（１）で、プレーヤが、共有ボタンＳＢＴをタップすると、その入力操作に基づいて、ゲームアプリケーションと連携したＳＮＳアプリケーションが起動する。生成元が第１ＳＮＳの友だちである場合には、端末２０Ａの制御部２１により第１態様が設定され、生成元が第２ＳＮＳの友だちである場合には、端末２０Ａの制御部２１により第２態様が設定されて、態様設定情報を含むＳＮＳ共有要求情報が、連携したＳＮＳアプリケーションを介してＳＮＳサーバに送信されるようにしてもよい。

本形態では、ユーザＡ．Ａ（プレーヤ）のアカウントと、その友だちのアカウント（第１アカウントの一例）とが関連付けられたＳＮＳが第１ＳＮＳである場合、ＳＮＳ（限定ではなく例として、第１ＳＮＳ及び第２ＳＮＳの少なくとも一方）において、ユーザＡの投稿として、生成されたモンスターと共に、生成元のユーザのアカウントＩＤ（第１態様の対応情報の一例）が表示されるため、生成元のユーザとコミュニケーションを図りたいユーザ（限定ではなく例として友だち申請したいユーザ）を増やす機会を設けることができ、第１ＳＮＳのアカウントを有する生成元のユーザにとって有益になる。
なお、生成元のユーザのアカウントＩＤは、生成元のユーザを識別可能な情報の一例である。

本形態では、ユーザＡ．Ａ（プレーヤ）のアカウントと、その友だちのアカウント（第１アカウントの一例）とが関連付けられたＳＮＳが第２ＳＮＳである場合、ＳＮＳ（限定ではなく例として、第１ＳＮＳ及び第２ＳＮＳの少なくとも一方）において、ユーザＡの投稿として、生成されたモンスターと共に、生成元のユーザのアカウントが存在するＳＮＳ名（第２態様の対応情報の一例）が表示されるため、生成元のユーザがどのＳＮＳに属しているのかを把握することは可能であるものの、ユーザを特定するところまではできない。従って、第三者との間で、第２ＳＮＳからどのようなモンスターが生成されたのかを共有することができる一方、生成元となった第２ＳＮＳのユーザが明確に開示されてしまうことによる不利益を防止することができる。

＜第４変形例（２）＞
図４－１１の例では、生成元の友だちが、第１ＳＮＳである場合と、第２ＳＮＳである場合の、何れの場合にも、生成元情報が第１ＳＮＳで共有されているが、このような形態にかかわらず、生成元の友だちが、第１ＳＮＳであることに基づいて、生成元情報が第１ＳＮＳで共有され、生成元の友だちが、第２ＳＮＳであることに基づいて、生成元情報が第２ＳＮＳで共有されるようにしてもよい。

限定ではなく例として、図４－１３の例では、生成元の友だちが、第２ＳＮＳであることに基づいて、生成元情報が第２ＳＮＳ（Ｂｕｓｉｎｅｓｓ Ａｐｐ）で共有されている。

すなわち、図４－１３の例では、（２Ａ）で、共有ボタンＳＢＴが操作されたことに基づいて、（１ＭＡ）に示すように、生成元情報が第１ＳＮＳで共有される。すなわち、プレーヤのアカウントと生成元のユーザのアカウントとが第１ＳＮＳで関連付けられていることに基づいて、生成されたモンスターとともに、生成元情報が第１ＳＮＳ（Ｍｅｓｓａｇｉｎｇ Ａｐｐ）で共有される。

一方、（２Ｂ）で、共有ボタンＳＢＴが操作されたことに基づいて、（１ＭＢ）に示すように、生成元情報が第２ＳＮＳで共有される。すなわち、プレーヤのアカウントと生成元のユーザのアカウントとが第２ＳＮＳで関連付けられていることに基づいて、生成されたモンスターとともに、生成元情報が第２ＳＮＳ（Ｂｕｓｉｎｅｓｓ Ａｐｐ）で共有される。

また、図４－１３の例では、（２Ａ）で、共有ボタンＳＢＴが操作されたことに基づいて、（１ＭＡ）に示すように、「第１態様（アカウントＩＤ有）」の生成元情報が第１ＳＮＳで共有される。すなわち、プレーヤのアカウントと生成元のユーザのアカウントとが第１ＳＮＳで関連付けられていることに基づいて、生成されたモンスターとともに、「第１態様」の生成元情報が第１ＳＮＳ（Ｍｅｓｓａｇｉｎｇ Ａｐｐ）で共有される。

一方、（２Ｂ）で、共有ボタンＳＢＴが操作されたことに基づいて、（１ＭＢ）に示すように、「第２態様（アカウントＩＤ無）」の生成元情報が第２ＳＮＳで共有される。すなわち、プレーヤのアカウントと生成元のユーザのアカウントとが第２ＳＮＳで関連付けられていることに基づいて、生成されたモンスターとともに、「第２態様」の生成元情報が第２ＳＮＳ（Ｂｕｓｉｎｅｓｓ Ａｐｐ）で共有される。

図４－１３の例では、ユーザＭ．Ｍが、第１ＳＮＳと第２ＳＮＳの両方に自分のアカウントを持っているため、端末２０Ｍにおいて、第１ＳＮＳと第２ＳＮＳの両方で、プレーヤが生成した同じモンスターの画像を見ることができる。そして、同じモンスターの画像を異なるＳＮＳアプリケーションを介して表示させることで、生成元情報の表示態様が異なっていることになる。

仮に、ユーザＭ．Ｍが、第１ＳＮＳに自分のアカウントを有しているが、第２ＳＮＳには有していない場合、端末２０Ｍで、第１態様の生成元情報を見ることはできる（第１態様の生成元情報は端末２０Ｍの表示部２４に表示される）が、第２態様の生成元情報を見ることはできない（第２態様の生成元情報は端末２０Ｍの表示部２４に表示されない）。
一方、ユーザＭ．Ｍが、第２ＳＮＳに自分のアカウントを有しているが、第１ＳＮＳには有していない場合、端末２０Ｍで、第２態様の生成元情報を見ることはできる（第２態様の生成元情報は端末２０Ｍの表示部２４に表示される）が、第１態様の生成元情報を見ることはできない（第１態様の生成元情報は端末２０Ｍの表示部２４に表示されない）。

＜処理＞
このように、生成元の友だちが、第１ＳＮＳであることに基づいて、生成元情報が第１ＳＮＳで共有され、生成元の友だちが、第２ＳＮＳであることに基づいて、生成元情報が第２ＳＮＳで共有されるようにする場合、限定ではなく例として、図４－１２において、Ｇ４３２のステップで、生成元が第１ＳＮＳである場合には、第１態様に関する態様設定情報を含むＳＮＳ共有要求情報を、第１ＳＮＳのＳＮＳサーバ４０Ｘに送信し、生成元が第２ＳＮＳである場合には、第２態様に関する態様設定情報を含むＳＮＳ共有要求情報を、第２ＳＮＳのＳＮＳサーバ４０Ｙに送信してもよい。

この場合、ＳＮＳサーバ４０Ｘでは、後述するＸ４１２以降の処理が実行され、ＳＮＳサーバ４０Ｙでは、後述するＹ４１２以降の処理が実行されてもよい（図４－１４）。

（アプリケーション間の連携）
このように、共有先となる候補のＳＮＳが複数存在する場合、ゲームアプリケーションが、各ＳＮＳのＳＮＳアプリケーションと連携するようにしてもよい。

限定ではなく例として、図４－４（１）で、プレーヤが、共有ボタンＳＢＴをタップすると、その入力操作に基づいて、ゲームアプリケーションと連携して何れかのＳＮＳアプリケーションが起動する。例えば、生成元のユーザが第１ＳＮＳであることに基づいて、第１ＳＮＳのＳＮＳアプリケーションが起動し、生成元のユーザが第２ＳＮＳであることに基づいて、第２ＳＮＳのＳＮＳアプリケーションが起動する。

第１ＳＮＳのアプリケーションが起動した場合、端末２０Ａの制御部２１により第１態様が設定され、第１態様に関する態様設定情報を含むＳＮＳ共有要求情報が、共有先の第１ＳＮＳのＳＮＳサーバ４０Ｘに送信される。
第２ＳＮＳのアプリケーションが起動した場合、端末２０Ａの制御部２１により第２態様が設定され、第２態様に関する態様設定情報を含むＳＮＳ共有要求情報が、共有先の第２ＳＮＳのＳＮＳサーバ４０Ｙに送信される。

本形態では、生成元のユーザのアカウントとして、複数のＳＮＳのうちの何れのＳＮＳのアカウントが用いられたのかに応じて、複数のＳＮＳのうちの何れのＳＮＳに結果（生成されたモンスター及び対応情報）を表示させるのかが制御されるため、生成元のユーザと、そのユーザのアカウントが存在するＳＮＳとの関係を第三者が把握し易くなる。

本形態では、生成元のユーザのアカウントとして、複数のＳＮＳのうちの何れのＳＮＳのアカウントが用いられたのかに応じて、複数のＳＮＳのうちの何れのＳＮＳに結果（生成されたモンスター及び対応情報）を表示させるのかが制御され、且つ、複数のＳＮＳのうちの何れのＳＮＳに結果（生成されたモンスター及び対応情報）が表示されるのかに応じて、対応情報の表示態様を異ならせている。
これにより、生成元のユーザと、そのユーザのアカウントが存在するＳＮＳとの関係を第三者が把握し易くなり、第三者が生成元のユーザとコミュニケーションを取りやすくなる。また、結果が表示されるＳＮＳに応じた表示態様を採用することにより、各ＳＮＳの特徴を損なわないようにすることができる。

第４変形例（１）及び第４変形例（２）では、生成元のユーザのアカウントとして、複数のＳＮＳのうちの何れのＳＮＳのアカウントが用いられたのかと、複数のＳＮＳのうちの何れのＳＮＳに結果（生成されたモンスター及び対応情報）を表示させるのか、の少なくとも一方に応じて、対応情報の態様を異ならせており、第１態様と、第２態様とで生成元のユーザのアカウントの識別性が異なることにより、生成元のユーザに関する情報の開示レベルを適切に制御できる。

＜第４変形例（３）＞
図４－１３の例は、生成元の友だちが、第１ＳＮＳであることに基づいて、生成元情報が第１ＳＮＳで共有され、生成元の友だちが、第２ＳＮＳであることに基づいて、生成元情報が第２ＳＮＳで共有される例であるが、限定ではなく例として、プレーヤが共有先として設定したＳＮＳで、生成されたモンスター及び生成元情報の共有が行われるようにしてもよい。

＜処理＞
図４－１４は、本実施例において各装置によって実行される処理の流れの一例を示すフローチャートである。
この図では、左側に、ゲームサーバ５０の制御部５１が実行する処理を、中央に、ＳＮＳサーバ４０Ｘの制御部４１が実行する処理とＳＮＳサーバ４０Ｙの制御部４１が実行する処理とを、右側に、端末２０Ｍの制御部２１が実行する処理をそれぞれ示している。

本処理において、端末２０Ａは、限定ではなく例として、ユーザＡ．Ａによって選択された、情報の共有先のＳＮＳに関する情報（限定ではなく例として、ＳＮＳの識別情報）をＳＮＳ共有要求情報に含めて、ゲームサーバ５０に送信するようにすることができる。

Ｇ４１０のステップにおいて端末２０ＡからＳＮＳ共有要求情報を受信したと判定したならば（Ｇ４１０：ＹＥＳ）、ゲームサーバ５０の制御部５１は、タイムラインに更新して表示させる情報の態様に関する設定を行う（Ｇ４２２）。
この場合、ゲームサーバ５０の制御部５１は、受信したＳＮＳ共有要求情報に含まれる情報の共有先のＳＮＳに関する情報に基づいて、情報の共有先のＳＮＳを判定するようにすることができる。そして、限定ではなく例として、共有先のＳＮＳが第１ＳＮＳである場合、第１態様設定として、生成元ユーザのアカウントの表示を「有」に設定する。一方、共有先のＳＮＳが第２ＳＮＳである場合、第２態様設定として、生成元ユーザのアカウントの表示を「無」に設定する。

なお、これらは逆としてもよい。
また、第１態様設定と第２態様設定との両方について、生成元ユーザのアカウントの表示を「有」としてもよいし、「無」としてもよい。

次いで、ゲームサーバ５０の制御部５１は、Ｇ４２２のステップでの設定に基づき、態様設定情報であって、共有先のＳＮＳに対応する態様設定情報を含むＳＮＳ共有要求情報を、通信Ｉ／Ｆ５４によって、共有先のＳＮＳのＳＮＳサーバ４０に送信する（Ｇ４３４）。
具体的には、共有先が第１ＳＮＳである場合は、第１態様の態様設定情報を含むＳＮＳ共有要求情報をＳＮＳサーバ４０Ｘに送信し、共有先が第２ＳＮＳである場合は、第２態様の態様設定情報を含むＳＮＳ共有要求情報をＳＮＳサーバ４０Ｙに送信する。

ＳＮＳサーバ４０Ｘに態様設定情報が送信された場合、ＳＮＳサーバ４０Ｘの制御部４１は、前述したＸ４１０のステップと同様のＳＮＳ更新処理（この例では、生成元ユーザに関する情報を第１態様でタイムラインに表示させるための処理）を行う（Ｘ４１２）。そして、ＳＮＳサーバ４０Ｘの制御部４１は、タイムライン更新情報を通信Ｉ／Ｆ４４によって端末２０Ｍに送信する（Ｘ４３０）。

同様に、ＳＮＳサーバ４０Ｙに態様設定情報が送信された場合、ＳＮＳサーバ４０Ｙの制御部４１は、ＳＮＳ更新処理（この例では、生成元ユーザに関する情報を第２態様でタイムラインに表示させるための処理）を行う（Ｙ４１２）。そして、ＳＮＳサーバ４０Ｙの制御部４１は、タイムライン更新情報を通信Ｉ／Ｆ４４によって端末２０Ｍに送信する（Ｙ４３０）。

端末２０Ｍの制御部２１は、ＳＮＳサーバ４０Ｘからタイムライン更新情報を受信したか否かを判定し（Ｍ４１０）、受信しなかったと判定したならば（Ｍ４１０：ＮＯ）、Ｍ４５０のステップに処理を進める。
受信したと判定したならば（Ｍ４１０：ＹＥＳ）、端末２０Ｍの制御部２１は、第１ＳＮＳアプリケーションにおいて、受信したタイムライン更新情報に基づくタイムラインを表示部２４に表示させる（Ｍ４３４）。この例では、第１ＳＮＳアプリケーションにおいて、更新して表示されるタイムライン情報が第１態様で表示される。

次いで、端末２０Ｍの制御部２１は、ＳＮＳサーバ４０Ｙからタイムライン更新情報を受信したか否かを判定し（Ｍ４５０）、受信しなかったと判定したならば（Ｍ４５０：ＮＯ）、Ｍ１９５のステップに処理を進める。
受信したと判定したならば（Ｍ４５０：ＹＥＳ）、端末２０Ｍの制御部２１は、ＳＮＳサーバ４０Ｙから受信したタイムライン更新情報に基づくタイムラインを表示部２４に表示させる（Ｍ４７４）。この例では、第２ＳＮＳアプリケーションにおいて、更新して表示されるタイムライン情報が第２態様で表示される。

なお、本処理では、端末２０Ａからゲームサーバ５０に対してＳＮＳ共有要求情報が送信されることとしたが、これに限定されない。
限定ではなく例として、端末２０Ａから、情報の共有先として選択されたＳＮＳに対応するＳＮＳサーバ４０に対してＳＮＳ共有要求情報が送信されるようにしてもよい。具体的には、限定ではなく例として、ユーザＡ．Ａによって選択された共有先のＳＮＳが第１ＳＮＳである場合は、ＳＮＳ共有要求情報をＳＮＳサーバ４０Ｘに送信する。そして、ＳＮＳサーバ４０Ｘの制御部４１が、第１ＳＮＳアプリケーションのタイムラインに更新して表示させる情報（生成元ユーザに関する情報）の態様に関する設定を行うようにしてもよい。

また、限定ではなく例として、ユーザＡ．Ａによって選択された共有先のＳＮＳが第２ＳＮＳである場合は、ＳＮＳ共有要求情報をＳＮＳサーバ４０Ｙに送信する。そして、ＳＮＳサーバ４０Ｙの制御部４１が、第２ＳＮＳアプリケーションのタイムラインに更新して表示させる情報（生成元ユーザに関する情報）の態様に関する設定を行うようにしてもよい。

また、共有先のＳＮＳにおいて、第１態様と第２態様とのいずれの態様で情報を表示させるかをユーザに選択させるための態様選択用情報を端末２０Ａの表示部２４に表示させるようにし、ユーザによる入力に基づいて選択された態様の情報を含むＳＮＳ共有要求情報が、端末２０Ａから送信されるようにしてもよい。

また、共有先のＳＮＳは、必ずしも第１ＳＮＳと第２ＳＮＳとの組み合わせのうちのいずれかのＳＮＳである必要はなく、第１ＳＮＳおよび第２ＳＮＳとは異なる第３ＳＮＳを含めた組み合わせのいずれかのＳＮＳであってもよい。

（アプリケーション間の連携）
このように、共有先となるＳＮＳをプレーヤが選択する場合、ゲームアプリケーションが、選択されたＳＮＳのＳＮＳアプリケーションと連携するようにしてもよい。

限定ではなく例として、図４－４（１）で、プレーヤが、共有ボタンＳＢＴをタップすると、その入力操作に基づいて、ゲームアプリケーションと連携して、プレーヤが選択したＳＮＳのＳＮＳアプリケーションが起動する。例えば、選択されたＳＮＳが第１ＳＮＳであることに基づいて、第１ＳＮＳのＳＮＳアプリケーションが起動し、選択されたＳＮＳが第２ＳＮＳであることに基づいて、第２ＳＮＳのＳＮＳアプリケーションが起動する。

第１ＳＮＳのアプリケーションが起動した場合、端末２０Ａの制御部２１により第１態様が設定され、第１態様に関する態様設定情報を含むＳＮＳ共有要求情報が、共有先の第１ＳＮＳのＳＮＳサーバ４０Ｘに送信される（Ｇ４２２，Ｇ４３４，Ｘ４１２）。
第２ＳＮＳのアプリケーションが起動した場合、端末２０Ａの制御部２１により第２態様が設定され、第２態様に関する態様設定情報を含むＳＮＳ共有要求情報が、共有先の第２ＳＮＳのＳＮＳサーバ４０Ｙに送信される（Ｇ４２２，Ｇ４３４，Ｙ４１２）。

本形態では、ユーザＡのアカウントが存在するＳＮＳのうちの第１ＳＮＳにおいて、ユーザＡの投稿として、生成されたモンスターと共に、生成元のユーザ（第１ＳＮＳ及び第２ＳＮＳの少なくとも一方にアカウントを有するユーザ）のアカウントＩＤ（第１態様の対応情報の一例）が表示されるため、生成元のユーザとコミュニケーションを図りたいユーザ（限定ではなく例として友だち申請したいユーザ）を増やす機会を設けることができ、生成元のユーザにとって有益になる。

本形態では、ユーザＡのアカウントが存在するＳＮＳのうちの第２ＳＮＳにおいて、ユーザＡの投稿として、生成されたモンスターと共に、生成元のユーザのアカウントが存在するＳＮＳ名（第１ＳＮＳ及び第２ＳＮＳの少なくとも一方であり、第２態様の対応情報の一例）が表示されるため、生成元のユーザがどのＳＮＳに属しているのかを把握することは可能であるものの、ユーザを特定するところまではできない。従って、第三者との間で、どのようなモンスターが生成されたのかを共有することができる一方、生成元のユーザが第２ＳＮＳで明確に開示されてしまうことによる不利益を防止することができる。

＜第４変形例（４）＞
第４変形例（３）に示したように、ゲームのプレーヤ等が、生成されたモンスターと生成元情報とを共有するＳＮＳを選択・設定することを可能としてもよい。この場合、限定ではなく例として、以下に示す方法によって、ＳＮＳを選択・設定するようにしてもよい。

図４－１５は、モンスターの生成結果を共有するＳＮＳを選択する場合の例を示す図である。
（１）に示す画面は、ゲームのプレーヤであるユーザＡ．Ａの端末２０Ａの表示部２４に表示される画面であり、前述した図４－８（３Ａ）と同様の画面である。

（１）に示す画面で、ユーザＡ．Ａ（プレーヤ）が、共有ボタンＳＢＴをタップすることにより、（２）に示すように、生成されたモンスターと生成元情報とを共有するＳＮＳを選択するための画面が表示される。
この画面には、「共有するＳＮＳを選んでください」の文字と、共有するＳＮＳを選択するための共有ＳＮＳ選択情報（プレーヤのアカウントが存在する各ＳＮＳの名称と、各ＳＮＳに対応して設けられたチェックボックス）と、チェックボックスでチェックされたＳＮＳを共有先として決定するために操作する決定ボタンＤＥＢＴと、前の画面に戻るための戻るボタンとが表示されている。

（第１ＳＮＳを選択した場合）
（２）に示す画面で、ユーザＡ．Ａ（プレーヤ）が、共有先のＳＮＳとして第１ＳＮＳを選択した状態（「Ｍｅｓｓａｇｉｎｇ Ａｐｐ」に対応するチェックボックスにチェックを入れた状態）で、決定ボタンＤＥＢＴをタップすることにより、ユーザＡ．Ａ（プレーヤ）がアカウントを持っている第１ＳＮＳにおいて、生成されたモンスターに関する情報と、生成元のユーザに関する情報と、が共有されることになる。

図４－１５の（１ＭＡ）は、前述した図４－１３の（１ＭＡ）と同様の画面である。図４－１５の（１ＭＡ）の例では、第１態様（アカウントＩＤ有）の生成元情報が第１ＳＮＳで共有される。すなわち、プレーヤのアカウントと生成元のユーザのアカウントとが第１ＳＮＳで関連付けられており、プレーヤが共有先のＳＮＳとして第１ＳＮＳを選択したことに基づいて、生成されたモンスターとともに、第１態様の生成元情報が第１ＳＮＳ（Ｍｅｓｓａｇｉｎｇ Ａｐｐ）で共有される。

（第２ＳＮＳを選択した場合）
（２）に示す画面で、ユーザＡ．Ａ（プレーヤ）が、共有先のＳＮＳとして第２ＳＮＳを選択した状態（Ｂｕｓｉｎｅｓｓ Ａｐｐ」に対応するチェックボックスにチェックを入れた状態）で、決定ボタンＤＥＢＴをタップすることにより、ユーザＡ．Ａ（プレーヤ）がアカウントを持っている第２ＳＮＳにおいて、生成されたモンスターに関する情報と、生成元のユーザに関する情報と、が共有されることになる。

図４－１５の（１ＭＢ）は、前述した図４－１３の（１ＭＢ）と同様の画面である。図４－１５の（１ＭＢ）の例では、第２態様（アカウントＩＤ無）の生成元情報が第２ＳＮＳで共有される。すなわち、プレーヤのアカウントと生成元のユーザのアカウントとが第２ＳＮＳで関連付けられており、プレーヤが共有先のＳＮＳとして第２ＳＮＳを選択したことに基づいて、生成されたモンスターとともに、第２態様の生成元情報が第２ＳＮＳ（Ｂｕｓｉｎｅｓｓ Ａｐｐ）で共有される。

このようにしてプレーヤの端末２０Ａによって設定された共有先ＳＮＳに関するＳＮＳ識別情報は、端末２０Ａからゲームサーバ５０に送信されるＳＮＳ共有要求情報に含まれるようにしてもよい。ゲームサーバ５０では、ＳＮＳ共有要求情報（ＳＮＳ識別情報）に基づいて、何れのＳＮＳで生成されたモンスター（及び生成元情報）を共有するかを判定して、判定結果に基づいたＳＮＳで共有を行うようにしてもよい。

また、プレーヤの端末２０Ａによって設定された共有先ＳＮＳに関する情報が、ゲームサーバ５０の記憶部５５に記憶されるようにしてもよい。限定ではなく例として、設定操作を行ったプレーヤのアカウントＩＤに関連付けて、共有先ＳＮＳを識別可能なＳＮＳ識別情報が記憶されるようにしてもよく、制御部５１は、アカウントＩＤを含むＳＮＳ共有要求情報を受信すると、そのアカウントＩＤに関連付けられたＳＮＳ識別情報に基づいて、共有先となるＳＮＳを決定して、そのＳＮＳで共有を行うようにしてもよい。

なお、（２）の選択操作において、共有先のＳＮＳを複数選択することが可能であるようにしてもよい。限定ではなく例として、第１ＳＮＳを選択した状態（「Ｍｅｓｓａｇｉｎｇ Ａｐｐ」に対応するチェックボックスにチェックを入れた状態）とし、且つ、第２ＳＮＳを選択した状態（Ｂｕｓｉｎｅｓｓ Ａｐｐ」に対応するチェックボックスにチェックを入れた状態）で、決定ボタンＤＥＢＴをタップすることにより、第１ＳＮＳにおいては、生成されたモンスターと第１態様の生成元情報とが共有され、且つ、第２ＳＮＳにおいては、生成されたモンスターと第２態様の生成元情報とが共有されるようにしてもよい。

図４－１６（Ａ）には、この場合にゲームサーバ５０の記憶部５５に記憶される共有先ＳＮＳ設定データの一例を示している。
この共有先ＳＮＳ設定データには、限定ではなく例として、ＧａｍｅＡｐｐＩＤと、共有先ＳＮＳとが関連付けて記憶される。

ＧａｍｅＡｐｐＩＤには、限定ではなく例として、各々のプレーヤに固有に設定されるプレーヤＩＤが記憶されるようにしてよい。

共有先ＳＮＳは、このＧａｍｅＡｐｐＩＤ（プレーヤＩＤ）によって識別されるプレーヤが、生成されたモンスターと生成元情報とをいずれのＳＮＳに共有することを許可したかを示す情報としてよく、限定ではなく例として、このアカウントのプレーヤによって選択されたＳＮＳに対応するＳＮＳ識別情報が記憶されるようにしてよい。

このデータによれば、限定ではなく例として、ＧａｍｅＡｐｐＩＤ「Ｐ００００１」には、共有先ＳＮＳとして「第１ＳＮＳ」と「第２ＳＮＳ」とが記憶されている。これは、このアカウントのプレーヤによって、共有先のＳＮＳとして、「第１ＳＮＳ」と「第２ＳＮＳ」との２つが選択されたことを示している。
限定ではなく例として、ＧａｍｅＡｐｐＩＤ「Ｐ００００２」には、共有先ＳＮＳとして「第２ＳＮＳ」が記憶されている。これは、このアカウントのプレーヤによって、共有先のＳＮＳとして１つのＳＮＳが選択されたことを示している。
限定ではなく例として、ＧａｍｅＡｐｐＩＤ「Ｐ００００３」には、共有先ＳＮＳとして「無し」が記憶されている。これは、このアカウントのプレーヤによって、共有先のＳＮＳが選択されなかったことを示している。

なお、限定ではなく例として、デフォルトでは全てのＳＮＳＡｐｐｐＩＤについて共有先ＳＮＳに「共有不可」が記憶され、ユーザの端末２０から送信される情報に基づいて、共有先として選択されたＳＮＳの識別情報が共有先ＳＮＳに記憶されるようにしてよい。

（アプリケーション間の連携）
また、限定ではなく例として、プレーヤの端末２０Ａの記憶部２８に記憶されているゲームアプリケーションのＩＤに関連付けられた共有先ＳＮＳ設定データ（例えば、Ｐ００００１に関連付けられている共有先ＳＮＳである第１ＳＮＳ及び第２ＳＮＳ）に基づいて、ゲームアプリケーションが、共有先ＳＮＳに対応したＳＮＳアプリケーションと連携して、情報を共有するようにしてもよい。

また、限定ではなく例として、プレーヤの端末２０Ａの制御部２１は、ゲームアプリケーションにより、そのＧａｍｅＡｐｐＩＤに対応する情報（共有先ＳＮＳ，後述する生成元ＩＤの表示有無に関する情報等）をゲームサーバ５０から取得すること、取得した情報に基づく制御（例えば、共有先ＳＮＳの設定、生成元ＩＤの表示有無の設定等）を実行することが可能であってもよい。また、取得した情報がプレーヤの入力により更新された場合（例えば、共有先ＳＮＳが変更された場合、生成元ＩＤの表示有無が変更された場合等）に、更新後の情報をゲームサーバ５０に送信して、そのＧａｍｅＡｐｐＩＤ対応した情報を更新させることが可能であってもよい。

また、図４－１５の例では、プレーヤが共有先のＳＮＳを何れのＳＮＳとするかを設定可能な例を示したが、これに限定されない。
プレーヤに限らず、限定ではなく例として、生成元となるユーザが、共有を許可するＳＮＳを何れのＳＮＳとするかを設定できるようにしてもよい。

限定ではなく例として、生成元となるユーザが、自分の端末２０Ｂを使用して、図４－１５で示した方法と同様にして、自分のアカウントに基づいて生成されたモンスターと生成元情報との共有を許可するＳＮＳを選択することで、共有元となるユーザのアカウントＩＤと、共有が許可される許可ＳＮＳとがゲームサーバ５０の記憶部５５に記憶されるようにしてもよい。そして、プレーヤからのＳＮＳ共有要求情報を受信したことに基づいて、制御部５１が、ＳＮＳ共有要求情報に基づいて特定される生成元のアカウントＩＤに関連付けて記憶されている許可ＳＮＳを共有先のＳＮＳとして設定してもよい。

図４－１６（Ｂ）には、この場合にゲームサーバ５０の記憶部５５に記憶される共有先ＳＮＳ設定データの一例を示している。
このＳＮＳ設定データには、限定ではなく例として、ＳＮＳＡｐｐＩＤ（生成元ＩＤ）と、共有先ＳＮＳとが関連付けて記憶される。

ＳＮＳＡｐｐＩＤには、限定ではなく例として、各々のＳＮＳについて、そのＳＮＳでアカウントを所有している生成元のユーザに固有に設定された、そのＳＮＳでのアカウントであるＳＮＳＩＤが記憶されるようにしてよい。

共有先ＳＮＳは、このＳＮＳＡｐｐＩＤによって識別されるユーザ（モンスターの生成元となり得るユーザ）が、生成されたモンスターと生成元情報とをいずれのＳＮＳに共有することを許可したかを示す情報とすることができ、限定ではなく例として、このユーザによって選択されたＳＮＳに対応するＳＮＳ識別情報が記憶されるようにしてよい。

このデータによれば、限定ではなく例として、頭のアルファベットが「Ｘ」であるアカウントは、第１ＳＮＳのアカウントであり、頭のアルファベットが「Ｙ」であるアカウントは、第２ＳＮＳのアカウントであることを示している。
限定ではなく例として、ＳＮＳＡｐｐＩＤ「Ｘ００００１」には、共有先ＳＮＳとして「第１ＳＮＳ」が記憶されている。これは、このアカウントのユーザによって、共有先のＳＮＳを「第１ＳＮＳ」とすることが許可されたことを示している。
限定ではなく例として、ＳＮＳＡｐｐＩＤ「Ｘ０００２８」には、共有先ＳＮＳとして「共有不可」が記憶されている。これは、このアカウントのユーザによって、いずれのＳＮＳにも共有することが許可されなかったことを示している。
限定ではなく例として、ＳＮＳＡｐｐＩＤ「Ｘ００１９８」には、共有先ＳＮＳとして「第１ＳＮＳ」と「第２ＳＮＳ」とが記憶されている。これは、このアカウントのユーザによって、共有先のＳＮＳを「第１ＳＮＳ」と「第２ＳＮＳ」との２つとすることが許可されたことを示している。

なお、限定ではなく例として、デフォルトでは全てのＳＮＳＡｐｐｐＩＤについて共有先ＳＮＳに「共有不可」が記憶され、ユーザの端末２０から送信される情報に基づいて、共有を許可するＳＮＳとして選択されたＳＮＳの識別情報が共有先ＳＮＳに記憶されるようにしてよい。

また、限定ではなく例として、図４－１６（Ｂ）の共有先ＳＮＳ設定データのうち、生成元ＩＤが第１ＳＮＳのデータは、ゲームサーバ５０と第１ＳＮＳサーバ４０Ｘとで共有され、生成元ＩＤが第２ＳＮＳのデータは、ゲームサーバ５０と第２ＳＮＳサーバ４０Ｙとで共有されるようにしてもよい。なお、この「共有」は、一方の要求に応じて他方がデータを提供することを含んでもよい。

この場合、ＳＮＳのユーザの端末２０Ｂの制御部２１は、ＳＮＳアプリケーションにより、そのＳＮＳＡｐｐＩＤに対応する情報（共有先ＳＮＳ，後述する生成元ＩＤの表示有無に関する情報等）を、そのＳＮＳＡｐｐＩＤに対応するＳＮＳサーバ（第１ＳＮＳのＩＤであれば第１ＳＮＳサーバ４０Ｘ、第２ＳＮＳのＩＤであれば第２ＳＮＳサーバ４０Ｙ）から取得することが可能であってもよい。また、取得した情報がユーザの入力により更新された場合（例えば、共有先ＳＮＳが変更された場合、生成元ＩＤの表示有無が変更された場合等）に、変更後の情報を、対応するＳＮＳサーバ５０に送信して、そのＳＮＳＡｐｐＩＤ対応した情報を更新させることが可能であってもよい。

また、この場合、限定ではなく例として、プレーヤの端末２０Ａの制御部２１は、ゲームアプリケーションにより、友だち（モンスターの生成元となるユーザ）のＳＮＳＡｐｐＩＤに対応する情報（共有先ＳＮＳ，後述する生成元ＩＤの表示有無に関する情報等）を、ゲームサーバ５０から取得して、取得した情報に基づく制御（例えば、共有先ＳＮＳの設定、生成元ＩＤの表示有無の設定等）を実行することが可能であってもよい。

本形態では、プレーヤの端末に対する入力に基づいて、モンスターの生成結果（生成されたモンスター及び対応情報）を表示させるＳＮＳを選択（ＳＮＳの設定の一例）することができるため、投稿者（プレーヤ）が、生成結果を共有したいＳＮＳと、そうでないＳＮＳとを設定して、生成結果を共有したいＳＮＳにおいてのみ生成結果を共有することができる。

本形態では、第１ユーザ（生成元のユーザ）の第１端末に対する入力に基づいて、モンスターの生成結果（生成されたモンスター及び対応情報）を表示させるＳＮＳを選択（ＳＮＳの設定の一例）することができるため、生成されたモンスターの生成元である（または、これからモンスターの生成元になる）第１ユーザが、生成結果を共有してもよいと考えるＳＮＳと、そうでないＳＮＳとを設定して、生成結果を共有してもよいと考えるＳＮＳ（限定ではなく例として、第１ＳＮＳのみ）においてのみ生成結果を共有させることができる。

＜第４変形例（５）＞
限定ではなく例として、生成元のユーザ（生成元となることが可能なユーザ，生成元の候補となるユーザ）が、生成元情報を第１態様とするか第２態様とするか（生成元情報に自分のアカウントＩＤを含めるか否か）を設定可能であるようにしてもよい。

図４－１７は、生成元のユーザが、ＳＮＳにおける自分のアカウントに基づいてモンスターが生成された場合に、その生成元情報として、自分のアカウントＩＤを開示するか否かを設定する例を示す図である。

図４－１７は、生成元のユーザＢ．Ｂ（ゲームのプレーヤであってもよいし、プレーヤでなくてもよい）の端末２０Ｂに表示される画面の一例である。

（１）は、ＳＮＳ（メッセージングアプリケーション）におけるユーザＢ．Ｂの生成元情報に関する設定を行う画面の一例である。この画面では、「連携ゲームアプリケーションで、他のユーザがあなたのアカウントＩＤをＳＮＳに開示することを許可しますか？」というメッセージと、許可する場合に操作する許可ボタンＰ１ＢＴ（本例では、「許可する」の文字を含む）と、許可しない場合に操作する不許可ボタンＰ２ＢＴ（本例では、「許可しない」の文字を含む）と、前の画面に戻るための戻るボタンと、が表示されている。

ユーザＢ．Ｂによって許可ボタンＰ１ＢＴがタップされた場合、生成元情報を第１態様（アカウントＩＤ表示）とすることを指定する第１態様指定が端末２０ＢからＳＮＳサーバ４０Ｘを介して連携先のゲームサーバ５０に送信され、ゲームサーバ５０の記憶部５５において、ユーザＢのアカウントＩＤに関連付けて、第１態様指定情報が記憶される。これにより、生成元がユーザＢとなる場合には、ユーザＢのアカウントに基づいて生成されたモンスターとともに、第１態様の生成元情報が共有されることになる。

第１態様の生成元情報が共有される設定が行われたことに基づいて、（２Ａ）に示すように、「連携ゲームアプリケーションで、他のユーザがあなたのアカウントＩＤをＳＮＳに開示することを許可しました。」のメッセージが端末２０Ｂの表示部２４に表示される。

一方、ユーザＢ．Ｂによって不許可ボタンＰ２ＢＴがタップされた場合、生成元情報を第２態様（アカウントＩＤ非表示）とすることを指定する第２態様指定が端末２０ＢからＳＮＳサーバ４０Ｘを介して連携先のゲームサーバ５０に送信され、ゲームサーバ５０の記憶部５５において、ユーザＢ．ＢのアカウントＩＤに関連付けて、第２態様指定情報が記憶される。これにより、生成元がユーザＢ．Ｂとなる場合には、ユーザＢ．Ｂのアカウントに基づいて生成されたモンスターとともに、第２態様の生成元情報が共有されることになる。

第２態様の生成元情報が共有される設定が行われたことに基づいて、（２Ｂ）に示すように、「連携ゲームアプリケーションで、他のユーザがあなたのアカウントＩＤをＳＮＳに開示できないように設定しました。」のメッセージが端末２０Ｂの表示部２４に表示される。

なお、図４－１７の操作に関しては、複数のＳＮＳについてそれぞれ行うことができるようにしてもよい。すなわち、生成元のユーザが、ＳＮＳ毎に、そのＳＮＳにおいて、自分が生成元になったモンスターとともに表示させる生成元情報を、第１態様とするか、第２態様とするかを設定できるようにしてもよい。

図４－１８（Ｂ）には、この場合にゲームサーバ５０の記憶部５５に記憶される共有先ＳＮＳ設定データの一例を示している。
この共有先ＳＮＳ設定データでは、図４－１６（Ｂ）に示した共有先ＳＮＳ設定データとは異なり、ＳＮＳＡｐｐＩＤ（生成元ＩＤ）と、共有先ＳＮＳとに加えて、限定ではなく例として、生成元ＩＤの表示有無に関する情報が関連付けて記憶されている。

生成元ＩＤの表示有無に関する情報は、限定ではなく例として、このＳＮＳＡｐｐＩＤによって識別されるユーザ（モンスターの生成元となり得るユーザ）によって、生成元情報を表示／非表示のいずれとする設定が行われたかを示すフラグ（生成元情報を第１態様／第２態様のいずれの態様で表示させる設定が行われたかを示すフラグ）としてよく、限定ではなく例として、「表示（第１態様）」とする設定を行った場合は「表示有」が記憶され、「非表示（第２態様）」とする設定を行った場合は「表示無」が記憶されるようにしてよい。

このデータによれば、限定ではなく例として、ＳＮＳＡｐｐＩＤ「Ｘ００００１」には、共有先ＳＮＳとして「第１ＳＮＳ」が記憶され、生成元ＩＤとして「表示有」が記憶されている。これは、このアカウントのユーザによって、共有先のＳＮＳを「第１ＳＮＳ」とすることが許可され、生成元の情報を表示することも許可されたことを示している。
限定ではなく例として、ＳＮＳＡｐｐＩＤ「Ｘ０００２８」には、共有先ＳＮＳとして「共有不可」が記憶され、生成元ＩＤには「－」が記憶されている。これは、このアカウントのユーザによって、いずれのＳＮＳにも共有することが許可されなかったことを示している。
限定ではなく例として、ＳＮＳＡｐｐＩＤ「Ｘ００１９８」には、共有先ＳＮＳとして「第１ＳＮＳ」と「第２ＳＮＳ」とが記憶され、共有先ＳＮＳ「第１ＳＮＳ」には生成元ＩＤとして「表示有」が記憶され、共有先ＳＮＳ「第２ＳＮＳ」には生成元ＩＤとして「表示無」が記憶されている。これは、このアカウントのユーザによって、共有先のＳＮＳを「第１ＳＮＳ」と「第２ＳＮＳ」との２つとすることが許可され、「第１ＳＮＳ」については生成元情報を表示することが許可されたが、「第２ＳＮＳ」について生成元情報を表示することが許可されなかったことを示している。

なお、図４－１７では、生成元のユーザが、生成元情報を第１態様とするか第２態様とするかを設定する例を示したが、生成元のユーザに限らず、限定ではなく例として、プレーヤが、共有先とするＳＮＳにおける生成元情報の態様を設定できるようにしてもよく、ＳＮＳ毎に、生成元情報を第１態様とするか第２態様とするかを設定できるようにしてもよい。

図４－１８（Ａ）には、この場合にゲームサーバ５０の記憶部５５に記憶される共有先ＳＮＳ設定データの一例を示している。
この共有先ＳＮＳ設定データでは、図４－１６（Ａ）に示した共有先ＳＮＳ設定データとは異なり、ＧａｍｅＡｐｐＩＤと、共有先ＳＮＳとに加えて、限定ではなく例として、生成元ＩＤの表示有無に関する情報が関連付けて記憶されている。

生成元ＩＤの表示有無に関する情報は、このＧａｍｅＡｐｐＩＤによって識別されるプレーヤによって、生成元情報を表示／非表示のいずれとする設定が行われたかを示すフラグ（生成元情報を第１態様／第２態様のいずれの態様で表示させる設定が行われたかを示すフラグ）としてよく、限定ではなく例として、「表示（第１態様）」とする設定を行った場合は「表示有」が記憶され、「非表示（第２態様）」とする設定を行った場合は「表示無」が記憶されるようにしてよい。

このデータによれば、限定ではなく例として、ＧａｍｅＡｐｐＩＤ「Ｐ００００１」には、共有先ＳＮＳとして「第１ＳＮＳ」と「第２ＳＮＳ」とが記憶され、共有先「第１ＳＮＳ」と「第２ＳＮＳ」とのいずれにも、生成元ＩＤとして「表示有」が記憶されている。これは、このアカウントのプレーヤによって、共有先のＳＮＳとして「第１ＳＮＳ」と「第２ＳＮＳ」との２つが選択され、いずれのＳＮＳでも生成元情報の表示を有りとすることが選択されたことを示している。
限定ではなく例として、ＧａｍｅＡｐｐＩＤ「Ｐ００００２」には、共有先ＳＮＳとして「第２ＳＮＳ」が記憶され、生成元ＩＤとして「表示無」が記憶されている。これは、このアカウントのプレーヤによって、共有先のＳＮＳとして「第２ＳＮＳ」が選択されたが、生成元情報の表示は無しとすることが選択されたことを示している。

本形態では、第１ユーザ（生成元のユーザ）の第１端末に対する入力に基づいて、１以上のＳＮＳについて、それぞれ、生成されたモンスターと共に表示させる対応情報の表示態様を設定することができるため、生成されたモンスターの生成元である（または、これからモンスターの生成元になる）第１ユーザが、自分の情報をどのレベルで開示するのかを、開示先となるＳＮＳ毎に設定することができる。

本形態では、プレーヤの端末に対する入力に基づいて、１以上のＳＮＳについて、それぞれ、生成されたモンスターと共に表示させる対応情報の表示態様を設定することができるため、生成元のユーザの情報をどのレベルで開示するのかを、開示先となるＳＮＳ毎に設定することができる。

＜第４変形例（６）＞
限定ではなく例として、ゲームアプリケーションの運営者などによって指定された特定のモンスターが生成されたことに基づいて、プレーヤに所定の価値（所定の特典）が付与されるようにしてもよい。

図４－１９及び図４－２０は、この場合における表示画面の一例を示す図である。
ここでは、特定のモンスターの生成結果がＳＮＳに共有されたことに基づいて、プレーヤに所定の価値（所定の特典）が付与されるようにする場合の例を示す。

ここで、特定のモンスターとは、友だちからモンスターを生成する本ゲームにおいて、限定ではなく例として、他の通常のモンスターよりも生成される割合の低いモンスターとしてよく、プレーヤにとって珍しく価値の高いモンスターであるようにしてもよい。以下では、このようなモンスターを、適宜「レアモンスター」と称する。

また、所定の価値とは、前述したゲーム内価値であるようにしてもよく、ゲーム内価値とは異なるゲーム外価値であるようにしてもよい。ゲーム外価値とは、本ゲーム中でのみ価値のあるゲーム内価値とは異なり、本ゲームに関連しない場面において利用できる価値としてよい。ゲーム外価値は、商品やサービスを販売するウェブサイト等で利用できるギフト券（電子ギフト券も含む）、商品やサービス等であってもよい。本例では、ゲームに関する商品やサービスを販売するウェブサイト等で利用できる電子ギフト券の一例である「Ｇａｍｅギフト」を、ゲーム外価値として利用可能であるものとする。

図４－１９～図４－２０の（１）～（５）に示す画面は、ゲームのプレーヤであるユーザＡの端末２０Ａの表示部２４に表示される画面であり、本ゲームアプリケーションにおけるお知らせ画面である。これらの説明に関しては、図１－７に関して行った説明と同様であるため、異なる特徴部を除いては、説明を省略する。

図４－１９（１）の画面は、お知らせリストのお知らせタイトル情報から「ＷａｎｔｅｄモンスターをＧＥＴして友だちに教えてあげよう！」のお知らせタイトル表示が、ユーザＡ．Ａ（プレーヤ）によってタップされたことに基づいて、そのお知らせ詳細情報が端末２０Ａの表示部２４に表示された画面の一例である。
この画面では、お知らせ詳細情報として、運営者によって指定されたレアモンスターに関する情報（本例では、「Ｗａｎｔｅｄモンスター」の文字、モンスターＺの画像、「モンスターＺ」の文字）と、「Ｗａｎｔｅｄモンスターの生成結果をＳＮＳ投稿すると、抽選でＧａｍｅギフトをプレゼント」の文字と、生成ボタンＧＢＴと、この画面から一つ前の画面に戻るための戻るボタンとが表示されている。

図４－１９（１）の画面において、生成ボタンＧＢＴがユーザＡ（プレーヤ）によってタップされると、図４－１９（２）に示すような、モンスターを生成するための生成画面が表示される。
この画面は、前述した図１－８（２）と同様である部分についての説明を省略する。

図４－１９（２）の例では、友だちリストの項目として、ユーザＢ．ＢおよびユーザＣ．Ｃに加えて、ユーザＺ．Ｚに対応したアイコンおよびユーザ名等が一覧表示されている。また、これらの各友だちリスト項目の右部には、生成実行ボタンＭＧＢＴが表示されている。

本例では、
（ｉ）ユーザＢ．Ｂに対応する生成実行ボタンＭＧＢＴがタップされ、そのモンスターの生成結果としてレアモンスターとは異なる通常のモンスターが生成され、ユーザＡ（プレーヤ）の操作によって、図４－１９（２）の生成画面に戻り、
（ｉｉ）ユーザＣ．Ｃに対応する生成実行ボタンＭＧＢＴがタップされ、そのモンスターの生成結果としてレアモンスターとは異なる通常のモンスターが生成され、ユーザＡ（プレーヤ）の操作によって、図４－１９（２）の生成画面に戻り、
（ｉｉｉ）ユーザＺ．Ｚに対応する生成実行ボタンＭＧＢＴがタップされた、
場合を示している。すると、限定ではなく例として、図４－１９（３）に示すような、画面が表示される。

この画面は、前述した図４－２（３Ａ）と同様である部分についての説明を省略する。
図４－１９（３）の例では、モンスターＺに対応するゲーム情報が表示されている。
この画面において、共有ボタンＳＢＴがタップされ、第１ＳＮＳ（限定ではなく例として、メッセージングアプリケーション）におけるユーザＡのアカウントが投稿されると、限定ではなく例として、ユーザＭ．Ｍの端末２０Ｍでは、図４－１９（１Ｍ）に示すような画面が表示される。
この画面は、前述した図４－２（１Ｍ）と同様である部分についての説明を省略する。

図４－１９（１Ｍ）の例では、第１ＳＮＳのタイムライン情報として、「Ｚ．Ｚさん（＠ｚｚ００ｚｚ）からモンスター生成したらモンスターＺが生まれたよ。」というメッセージと、生成されたモンスターの画像（この例では、モンスターＺの画像）とが表示されている。このメッセージには、モンスターＺの生成元になったユーザＺのアカウントＩＤ（＠ｚｚ００ｚｚ）と、そのアカウントが管理されるＳＮＳにおけるユーザＺの登録名（Ｚ．Ｚ）と、が含まれている。

本例では、所定の期間が経過し、図４－１９（１）に示した「ＷａｎｔｅｄモンスターをＧＥＴして友だちに教えてあげよう！」の企画に当選したことに関するお知らせがユーザＡ．Ａ（プレーヤ）のゲームアプリケーションにおけるアカウントに通知されたものとする。

図４－２０（４）の画面は、お知らせリストのお知らせタイトル情報から「Ｇａｍｅギフト当選のお知らせ」のお知らせタイトル表示が、ユーザＡ（プレーヤ）によってタップされたことに基づいて、そのお知らせ詳細情報が端末２０Ａの表示部２４に表示された画面の一例である。
この画面では、お知らせ詳細情報として、「『Ｗａｎｔｅｄモンスターの生成結果をＳＮＳ投稿すると、抽選でＧａｍｅギフトをプレゼント』企画で当選しましたのでＧａｍｅギフトをお受け取りください。」の文字と、当選品を受け取るための受取ボタンＲＥＢＴ（本例では、「受け取る」の文字を含むボタン）と、この画面から一つ前の画面に戻るための戻るボタンとが表示されている。

次いで、図４－２０（４）の画面において、受取ボタンＲＥＢＴがユーザＡ（プレーヤ）によってタップされると、図４－２０（５）に示すような、当選品の詳細な内容が示された画面が表示される。
この画面では、ユーザＡ（プレーヤ）が受け取った当選品に関する情報として、プレゼント箱の画像と、「Ｇａｍｅギフト：３，０００円」の文字とが表示されている。

このような電子ギフト券等の特典の情報は、限定ではなく例として、デジタルデータとして、サーバにユーザのアカウントと関連付けて記憶されるようにしてよい。
また、そのデータの格納場所に関する情報（限定ではなく例として、ＵＲＩ（ＵＲＬ等））やコード情報が、ユーザがゲームアプリケーションとアカウント連携させたＳＮＳやアドレスを登録したメール等を通じて端末２０に配信されるようにすることによって、ユーザが特典を使用することができるようにしてもよい。
なお、特典の情報を端末２０の記憶部２８に記憶させてもよい。

このように、レアモンスターが生成されたことをＳＮＳに共有することで、所定の価値（所定の特典）が付与される企画が行われることによって、そのレアモンスターを生成するために、その企画が行われていないときよりも多くの回数のモンスター生成を行うように、プレーヤに動機付けすることができる。また、レアモンスターの生成結果をＳＮＳに共有するようにプレーヤに促すことによって、その投稿を見た他のユーザにも同様の効果を与え、その企画や本ゲームの周知を促進できる。

なお、上記の例では、レアモンスターが生成されたことがＳＮＳに共有されることで、プレーヤに所定の価値が付与される例を示したが、このような例に限定されず、ＳＮＳへの共有を不要とし、レアモンスターが生成されたことで、プレーヤに所定の価値が付与されるようにしてもよい。
また、これらの場合において、レアモンスターの生成元ユーザに所定の価値が付与されるようにしてもよいし、プレーヤと生成元ユーザとの両方に所定の価値が付与されるようにしてもよい。

本形態では、生成されたモンスターに関する所定条件（限定ではなく例として、生成されたモンスターが、指定されていたＷａｎｔｅｄモンスターであり、その生成されたモンスターをプレーヤがＳＮＳで共有したこと）が成立したことに基づいて、そのモンスターをＳＮＳで共有したプレーヤ（ユーザＡ）に特典が付与されるため、ゲーム内で新たなモンスターを生成してＳＮＳで共有する意欲を高めさせることができる。

本形態では、生成されたモンスターに関する所定条件（限定ではなく例として、生成されたモンスターが、指定されていたＷａｎｔｅｄモンスターであり、その生成されたモンスターをプレーヤがＳＮＳで共有したこと）が成立したことに基づいて、そのモンスターの生成元となった第１ユーザに特典が付与されるため、モンスターの生成元となることが有益であると第１ユーザに感じさせることができ、プレーヤ以外のユーザにもゲームにより楽しみを与えることができる。

＜他の変形例＞
＜第１変形例（４）＞において示した、メッセージングアプリケーションにおいて友だちとして登録している一般アカウントとは異なる仮想アカウントをゲームアプリケーションにおいて友だちとして登録し、この仮想アカウントに基づいてモンスターが生成されてもよい構成を、第４実施例に適用するようにしてもよい。

この場合、仮想アカウントとして、通常の仮想アカウントと、特別な仮想アカウントとが設けられてもよい。特別な仮想アカウントとは、限定ではなく例として、ゲームにタイアップする芸能人やタレント、ゲームに関するキャラクタ等を含めることができる。但し、特別な仮想アカウントのうち芸能人やタレントに関連する仮想アカウントは、限定ではなく例として、実際に本人がメッセージングアプリケーションにおいて登録している一般アカウントとは異なり、ゲームの運営者が登録した芸能人やタレントの擬似的なアカウントとすることができる。この仮想アカウントは、限定ではなく例として、ランダムに設定人数分（限定ではなく例として１０名分）抽出され、一日に一回更新されるようにするなどしてもよい。また、その１０名の仮想アカウントのうち１名が、特別な仮想アカウントであるようにするなどしてもよい。

このような構成によれば、メッセージングアプリケーションにおいて友だちとして登録している一般アカウントの数が少ないプレーヤが、友だちとして登録している一般アカウントの数によってゲームを進行するうえで不利になってしまうことを防止でき、健全なゲーム性を有するゲームを提供できるとともに、仮想アカウントを利用したゲームの進行に関して公平性を保ち、特別な仮想アカウントによりゲームの興趣を向上できる。

また、それらの仮想アカウントに基づいて生成されたモンスターの生成結果をＳＮＳに共有できるようにしてもよい。特別な仮想アカウントに基づいて生成されたモンスターの生成結果がＳＮＳに共有される場合、共有先での生成元情報は第１態様で表示され、通常の仮想アカウントに基づいて生成されたモンスターの生成結果がＳＮＳに共有される場合、共有先での生成元情報は第２態様で表示されるようにしてもよい。

特別な仮想アカウントは、ＳＮＳにおいて第１態様の生成元情報が表示されることによって、特別な仮想アカウントの存在を他のユーザに共有することで、その影響力の高さから他のユーザを本ゲームに注目させ、本ゲームの販売促進につなげることが期待できる。
一方で、通常の仮想アカウントは、ＳＮＳにおいて第２態様の生成元情報が表示されることによって、通常の仮想アカウントの存在を他のユーザに共有しないことで、他のユーザのゲームへの関心が低下してしまうことを防止できる。

１ 通信システム
１０ サーバ
２０ 端末
３０ ネットワーク
４０ メッセージングサーバ、ＳＮＳサーバ
５０ ゲームサーバ

Claims (14)

1. ゲームに関する処理を行う端末によって実行されるプログラムであって、
   ソーシャルネットワーキングサービス（以下、「ＳＮＳ」と称する。）で前記端末のユーザのアカウントと関連付けられた第１アカウントに基づく、前記ゲームに登場する第１オブジェクトを、前記端末の制御部によって取得することと、
   前記第１オブジェクトと、前記第１アカウントに対応する対応情報とを、ＳＮＳにおいて表示させるための第１制御を、前記制御部によって実行することと、を含む、
   プログラム。
2. 請求項１に記載のプログラムであって、
   前記アカウントと前記第１アカウントとが関連付けられたＳＮＳが第１ＳＮＳである場合、前記第１制御により、前記第１オブジェクトと、第１態様の前記対応情報とが表示され、
   前記アカウントと前記第１アカウントとが関連付けられたＳＮＳが第２ＳＮＳである場合、前記第１制御により、前記第１オブジェクトと、第２態様の前記対応情報とが表示される、
   プログラム。
3. 請求項１に記載のプログラムであって、
   前記第１制御により前記第１オブジェクトと前記対応情報とが表示されるＳＮＳが、第１ＳＮＳである場合、前記対応情報は第１態様で表示され、
   前記第１制御により前記第１オブジェクトと前記対応情報とが表示されるＳＮＳが、第２ＳＮＳである場合、前記対応情報は第２態様で表示される、
   プログラム。
4. 請求項１に記載のプログラムであって、
   前記アカウントと前記第１アカウントとが関連付けられたＳＮＳが第１ＳＮＳである場合、前記第１制御により、前記第１オブジェクトと前記対応情報とが前記第１ＳＮＳに表示され、
   前記アカウントと前記第１アカウントとが関連付けられたＳＮＳが第２ＳＮＳである場合、前記第１制御により、前記第１オブジェクトと前記対応情報とが前記第２ＳＮＳに表示される、
   プログラム。
5. 請求項４に記載のプログラムであって、
   前記アカウントと前記第１アカウントとが関連付けられたＳＮＳが第１ＳＮＳである場合、前記第１制御により、前記第１オブジェクトと第１態様の前記対応情報とが前記第１ＳＮＳに表示され、
   前記アカウントと前記第１アカウントとが関連付けられたＳＮＳが第２ＳＮＳである場合、前記第１制御により、前記第１オブジェクトと第２態様の前記対応情報とが前記第２ＳＮＳに表示される、
   プログラム。
6. 請求項２、請求項３、請求項５の何れか１項に記載のプログラムであって、
   前記第２態様は、前記第１態様よりも前記第１アカウントの識別性が低い態様である、
   プログラム。
7. 請求項１に記載のプログラムであって、
   前記ユーザの入力に基づいて、前記対応情報が表示される１以上のＳＮＳを設定するための第１設定制御を実行することを含む、
   プログラム。
8. 請求項７に記載のプログラムであって、
   前記ユーザの入力に基づいて、前記対応情報が表示される１以上のＳＮＳ各々における前記対応情報の態様を設定するための第２設定制御を実行することを含む、
   プログラム。
9. 請求項１に記載のプログラムであって、
   前記第１オブジェクトに関する所定条件が成立したことに基づく特典を前記端末の表示部に表示することを含む、
   プログラム。
10. 請求項１に記載のプログラムであって、
    前記対応情報が表示される１以上のＳＮＳは、前記第１アカウントの第１ユーザの第１端末に対する入力に基づいて設定されたＳＮＳである、
    プログラム。
11. 請求項１０に記載のプログラムであって、
    前記対応情報が表示される１以上のＳＮＳ各々における前記対応情報の態様は、前記第１ユーザの前記第１端末に対する入力に基づいて設定された態様である、
    プログラム。
12. 請求項１に記載のプログラムであって、
    前記第１オブジェクトに関する所定条件が成立したことに基づく特典は、前記第１アカウントに関連付けられる、
    プログラム。
13. ゲームに関する処理を行う端末の情報処理方法であって、
    ＳＮＳで前記端末のユーザのアカウントと関連付けられた第１アカウントに基づく、前記ゲームに関する第１オブジェクトを、前記端末の制御部によって取得することと、
    前記第１オブジェクトと、前記第１アカウントに対応する対応情報とを、ＳＮＳにおいて表示させるための第１制御を、前記制御部によって実行することと、を含む、
    情報処理方法。
14. ゲームに関する処理を行う端末であって、
    ＳＮＳで前記端末のユーザのアカウントと関連付けられた第１アカウントに基づく、前記ゲームに関する第１オブジェクトを取得する制御部を備え、
    前記制御部は、前記第１オブジェクトと、前記第１アカウントに対応する対応情報とを、ＳＮＳにおいて表示させるための第１制御を実行する、
    端末。

Images