JP2023172872A

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

Info

Publication number: JP2023172872A
Application number: JP2023017890A
Authority: JP
Inventors: 井上　敦司; Atsushi Inoue; 泰典長尾; Yasunori Nagao; 勇樹石川; Yuki Ishikawa
Original assignee: Z Intermediate Global Corp
Current assignee: Z Intermediate Global Corp
Priority date: 2022-05-23
Filing date: 2023-02-08
Publication date: 2023-12-06
Also published as: JP2023172876A

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

サーバと通信し、ゲームに関する処理を行う端末によって実行されるプログラムであって、
ソーシャルネットワーキングサービス（以下、「ＳＮＳ」と称する。）で前記端末のユーザのアカウントと関連付けられた第１アカウントに関する情報を前記端末の表示部に表示することと、
前記表示部に表示された前記第１アカウントに関する情報に対する前記ユーザによる入力に基づいて、前記第１アカウントに基づく、前記ゲームに登場するオブジェクトを要求するための第１情報を前記端末の通信部によって前記サーバに送信することと、
前記第１情報を送信したことに基づいて、前記オブジェクトであって前記第１アカウントに基づく第１オブジェクトに関する第２情報を前記通信部によって前記サーバから受信することと、
前記第１オブジェクトを前記表示部に表示することとが前記端末によって実行される。
請求項１に記載のプログラムであって、
前記ＳＮＳで前記アカウントと関連付けられた、前記第１アカウントとは異なる第２アカウントに関する情報を前記表示部に表示することと、
前記表示部に表示された前記第２アカウントに関する情報に対する前記ユーザによる入力に基づいて、前記第２アカウントに基づく前記第１情報を前記通信部によって前記サーバに送信することと、
前記第１情報を送信したことに基づいて、前記オブジェクトであって前記第２アカウントに基づく第２オブジェクトに関する前記第２情報を前記通信部によって前記サーバから受信することと、
前記第２オブジェクトを前記表示部に表示することとが前記端末によって実行される。
請求項２に記載のプログラムであって、
前記第１アカウントと前記第２アカウントとは、前記ＳＮＳで、第１種別として前記アカウントと関連付けられたアカウントである。
請求項３に記載のプログラムであって、
前記第１アカウントと前記第２アカウントとは、前記ＳＮＳで、第１種別として前記アカウントと関連付けられたアカウントであって、前記ゲームのプレーヤとして登録されているユーザのアカウントである。
請求項１に記載のプログラムであって、
前記第１アカウントは、前記ＳＮＳで、第１種別として前記アカウントと関連付けられたアカウントであり、
前記ＳＮＳで、前記第１種別とは異なる第２種別として前記アカウントと関連付けられた第３アカウントに関する情報を前記表示部に表示することと、
前記表示部に表示された前記第３アカウントに関する情報に対する前記ユーザによる入力に基づいて、前記第３アカウントに基づく前記第１情報を前記通信部によって前記サーバに送信することと、
前記第１情報を送信したことに基づいて、前記オブジェクトであって前記第３アカウントに基づく第３オブジェクトに関する前記第２情報を前記通信部によって前記サーバから受信することと、
前記第３オブジェクトを前記表示部に表示することとが前記端末によって実行される。
請求項５に記載のプログラムであって、
前記第１オブジェクトは、前記第１種別に対応するオブジェクトであり、
前記第３オブジェクトは、前記第２種別に対応するオブジェクトである。
請求項５または請求項６に記載のプログラムであって、
前記第３オブジェクトに関する前記第２情報は、設定された期間内に、前記第３アカウントに基づく前記第１情報が前記通信部によって前記サーバに送信された場合、前記サーバから前記端末に送信される。
請求項５に記載のプログラムであって、
前記ＳＮＳで、前記第２種別として前記アカウントと関連付けられていない第４アカウントに関する情報を前記通信部によって前記サーバから受信することと、
前記第４アカウントに関する情報を前記表示部に表示することとが前記端末によって実行される。
請求項８に記載のプログラムであって、
前記第４アカウントに関する情報は、前記ＳＮＳで前記第２種別として前記第４アカウントを前記アカウントと関連付けるよう前記ユーザに促す情報を含む。
請求項９に記載のプログラムであって、
前記第４アカウントに関する情報に対する前記ユーザによる入力に基づいて、前記第２種別として前記アカウントを前記第４アカウントと関連付けることに関する処理を前記端末の制御部によって行うことが前記端末によって実行される。
請求項１０に記載のプログラムであって、
前記関連付けることに関する処理が行われた後、前記第４アカウントに関する情報を前記表示部に表示することと、
前記表示部に表示された前記第４アカウントに関する情報に対する前記ユーザによる入力に基づいて、前記第４アカウントに基づく前記第１情報を前記通信部によって前記サーバに送信することと、
前記第１情報を送信したことに基づいて、前記オブジェクトであって前記第４アカウントに基づく第４オブジェクトに関する前記第２情報を前記通信部によって前記サーバから受信することと、
前記第４オブジェクトを前記表示部に表示することとが前記端末によって実行される。
請求項１に記載のプログラムであって、
前記第１オブジェクトに関する前記第２情報が前記表示部に表示された後、前記第１アカウントに関する情報を前記表示部に表示することと、
前記表示部に表示された前記第１アカウントに関する情報に対する前記ユーザによる入力に基づいて、前記第１アカウントに基づく前記第１情報を前記通信部によって前記サーバに送信することと、
前記第１情報を送信したことに基づいて、前記第１オブジェクトに代えて前記表示部に表示される、前記オブジェクトであって前記第１アカウントに基づく第５オブジェクトに関する前記第２情報を前記通信部によって前記サーバから受信することと、
前記第５オブジェクトを前記表示部に表示することとが前記端末によって実行される。
請求項１に記載のプログラムであって、
前記第１アカウントに関する情報と、前記第１アカウントとは異なる第５アカウントに関する情報とを含むリストを前記表示部に表示することが前記端末によって実行され、
前記第１アカウントに基づく前記第１情報が送信されておらず、前記第５アカウントに基づく前記第１情報が送信されていない場合に、前記第１アカウントに基づく前記第１情報が送信された場合、前記第１アカウントに関する情報と前記第５アカウントに関する情報とは同じ態様で前記リストに表示され、
前記第１アカウントに基づく前記第１情報が送信され、前記第５アカウントに基づく前記第１情報が送信されていない場合、前記第１アカウントに関する情報と前記第５アカウントに関する情報とは異なる態様で前記リストに表示される。
請求項１３に記載のプログラムであって、
前記第１オブジェクトは、前記第１アカウントに基づく前記第１情報が送信される前に、前記サーバによって前記第１アカウントと関連付けられている。
請求項１に記載のプログラムであって、
前記第１オブジェクトに関する第１条件が成立したことに基づいて、前記ＳＮＳによって前記第１アカウントに対して前記第１オブジェクトに関するメッセージを送信することに関する処理を前記端末の制御部によって行うことが前記端末によって実行される。
請求項１５に記載のプログラムであって、
前記メッセージを送信することに関する処理を行った後、前記ＳＮＳによって前記第１アカウントから送信された第１メッセージを前記通信部によって受信することと、
前記ＳＮＳによって前記第１メッセージを前記表示部に表示することとが前記端末によって実行される。
請求項１に記載のプログラムであって、
前記ゲームに関する処理は、前記アカウントが、前記アカウントとは異なるアカウントであって前記ゲームのプレーヤとして登録されている第１ユーザのアカウントを対戦相手のアカウントとして、前記第１オブジェクトを、前記第１ユーザの第１端末で取得されたオブジェクトと対戦させる対戦処理を含み、
前記対戦処理は、前記対戦相手のアカウントが前記第１アカウントである場合、前記対戦に関連して所定のイベントを発生させる処理を含む。
請求項１に記載のプログラムであって、
前記サーバは、前記ゲームに関する情報を管理する第１サーバと、前記ＳＮＳに関する情報を管理する第２サーバとを含み、
前記第１情報は、前記通信部によって前記第２サーバに送信され、前記第２サーバから前記第１サーバに送信され、
前記第２情報は、前記通信部によって前記第１サーバから受信される。
請求項１に記載のプログラムであって、
前記サーバは、前記ゲームに関する情報を管理する第１サーバを含み、
前記第１情報は、前記通信部によって前記第１サーバに送信され、
前記第２情報は、前記通信部によって前記第１サーバから受信される。
サーバと通信し、ゲームに関する処理を行う端末の情報処理方法であって、
ＳＮＳで前記端末のユーザのアカウントと関連付けられた第１アカウントに関する情報を前記端末の表示部に表示することと、
前記表示部に表示された前記第１アカウントに関する情報に対する前記ユーザによる入力に基づいて、前記第１アカウントに基づく、前記ゲームに登場するオブジェクトを要求するための第１情報を前記端末の通信部によって前記サーバに送信することと、
前記第１情報を送信したことに基づいて、前記オブジェクトであって前記第１アカウントに基づく第１オブジェクトに関する第２情報を前記通信部によって前記サーバから受信することと、
前記第１オブジェクトを前記表示部に表示することとを含む。
サーバと通信し、ゲームに関する処理を行う端末であって、
ＳＮＳで前記端末のユーザのアカウントと関連付けられた第１アカウントに関する情報を表示する表示部と、
前記表示部に表示された前記第１アカウントに関する情報に対する前記ユーザによる入力に基づいて、前記第１アカウントに基づく、前記ゲームに登場するオブジェクトを要求するための第１情報を前記サーバに送信する通信部とを備え、
前記通信部は、前記第１情報を送信したことに基づいて、前記オブジェクトであって前記第１アカウントに基づく第１オブジェクトに関する第２情報を前記サーバから受信し、
前記表示部は、前記第１オブジェクトを表示する。
ゲームに関する処理を行う端末と通信するサーバであって、
前記ゲームに登場するオブジェクトを生成する処理を行う制御部と、
ＳＮＳで前記端末のユーザのアカウントと関連付けられた第１アカウントに基づく、前記オブジェクトを要求するための第１情報を前記端末から受信する通信部とを備え、
前記通信部は、前記第１情報を受信したことに基づいて、前記オブジェクトであって前記第１アカウントに基づく第１オブジェクトに関する第２情報を前記端末に送信する。
サーバと通信し、ゲームに関する処理を行う端末によって実行されるプログラムであって、
前記ゲームに登場するオブジェクトであって、ＳＮＳで前記端末のユーザのアカウントと関連付けられた複数のアカウントのうちの第１アカウントに基づく第１オブジェクトに関する情報を前記端末の通信部によって前記サーバから受信することと、
前記第１オブジェクトを前記端末の表示部に表示することとが前記端末によって実行される。
ゲームに関する処理を行う端末と通信するサーバであって、
前記ゲームに登場するオブジェクトを生成する処理を行う制御部と、
前記オブジェクトであって、ＳＮＳで前記端末のユーザのアカウントと関連付けられた複数のアカウントのうちの第１アカウントに基づく第１オブジェクトに関する情報を前記端末に送信する通信部とを備える。