JP7281007B1 - プログラムおよび情報処理装置 - Google Patents

Abstract

【課題】ユーザ間の関連付けの行いやすいサービスを提供する。【解決手段】プログラムは、コンピュータを、所定のサービス内で第１ユーザと所定の体験を共有決定後、共有中、または共有後の第２ユーザに対して、前記第２ユーザの前記第１ユーザへの関連付けに係る申請を自動的に行う申請手段として機能させる。【選択図】図７

Description

本発明は、プログラム、および情報処理装置に関する。

従来より、各ユーザが他のユーザをフレンドとして登録したりフォローしたりすることが可能なゲーム等のサービスが知られている（例えば、特許文献１参照）。

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

ところで、フレンド登録やフォロー等の、ユーザに他のユーザを関連付けることが可能なサービスにおいては、当該関連付けが行いにくいという問題があった。

本発明は、前記事情に鑑みてなされたものであり、ユーザ間の関連付けの行いやすいサービスを提供することを目的とする。

本開示に示す一実施形態によれば、
コンピュータを、
所定のサービス内で第１ユーザと所定の体験を共有決定後、共有中、または共有後の第２ユーザに対して、前記第２ユーザの前記第１ユーザへの関連付けに係る申請を自動的に行う申請手段として機能させる
プログラムが提供される。

本発明によれば、ユーザ間の関連付けの行いやすいサービスが提供される。

システムの概略構成を示す図である。 システムの機能的構成を示すブロック図である。 関連ユーザリスト表示画面の一例を示す図である。 経緯情報入力画面の一例を示す図である。 分類リスト表示画面の一例を示す図である。 分類リストの表示についての一例を示す図である。 ユーザに他のユーザを自動で関連付ける処理の一例を示すフローチャートである。 ユーザへの他のユーザの関連付けを自動で解除する処理の一例を示すフローチャートである。 経緯情報の入力に係る処理の一例を示すフローチャートである。 分類リストの作成および表示に係る処理の一例を示すフローチャートである。 分類リストの作成および表示に係る処理の一例を示すフローチャートである。

以下、図面を参照しながら本発明の実施形態について説明する。

＜システムのハードウェア構成＞
図１に示すように、本実施形態のシステム１は、複数の端末装置１０と、サーバ２０とを備えている。

端末装置１０とサーバ２０とは、ネットワーク２を介して接続される。ネットワーク２は、例えば、インターネット、移動通信システム（例えば、３Ｇ、４Ｇ、５Ｇ、ＬＴＥ（Long Term Evolution）等）、ＷｉＦｉ（Wireless Fidelity）、ブルートゥース（登録商標）、その他の通信回線、またはこれらの組み合わせ等のいずれによって構成されていてもよい。また、端末装置１０とサーバ２０との接続は、有線接続であるか無線接続であるかを問わない。

サーバ２０（換言すると、コンピュータ、情報処理装置）は、例えば、ワークステーションまたはパーソナルコンピュータ等の汎用コンピュータであってもよい。サーバ２０は、プロセッサ２１と、メモリ２２と、ストレージ２３と、通信ＩＦ（インターフェース）２４と、入出力ＩＦ２５と、を備える。サーバ２０が備えるこれらの構成は、通信バスによって互いに接続される。

プロセッサ２１は、サーバ２０全体の動作を制御する。プロセッサ２１は、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）およびＧＰＵ（Graphics Processing Unit）等を含み得る。プロセッサ２１は、ストレージ２３からプログラムを読み出し、メモリ２２に展開する。プロセッサ２１は、展開したプログラムを実行する。

メモリ２２は、主記憶装置である。メモリ２２は、例えば、ＲＯＭ（Read Only Memory）およびＲＡＭ（Random Access Memory）等の記憶装置により構成される。メモリ２２は、プロセッサ２１がストレージ２３から読み出したプログラムおよび各種データを一時的に記憶することにより、プロセッサ２１に作業領域を提供する。メモリ２２は、プロセッサ２１がプログラムに従って動作している間に生成した各種データも一時的に記憶する。

なお、本実施形態においてプログラムとは、ゲーム等の所定のサービス（換言するとアプリケーション）を端末装置１０により実現するプログラムであってもよい。また、当該プログラムは、当該所定のサービスを端末装置１０とサーバ２０との協働により実現するプログラムであってもよい。なお、端末装置１０とサーバ２０との協働により実現される所定のサービスは、一例として、端末装置１０において起動されたブラウザ上で提供されるサービスであってもよい。また、当該プログラムは、当該所定のサービスを複数の端末装置１０の協働により実現するプログラムであってもよい。また、各種データには、例えば、ユーザ情報およびサービス情報などのサービスに関するデータ、および端末装置１０とサーバ２０との間で送受信される指示や通知が含まれる。

ストレージ２３は、補助記憶装置である。ストレージ２３は、例えば、フラッシュメモリまたはＨＤＤ（Hard Disk Drive）等の記憶装置により構成される。ストレージ２３には、サービスに関する各種データが格納される。

通信ＩＦ２４は、サーバ２０と端末装置１０等との間におけるネットワークを介した各種データの送受信を制御する。

入出力ＩＦ２５は、サーバ２０がデータの入力を受け付けるためのインターフェースであるとともに、サーバ２０がデータを出力するためのインターフェースである。入出力ＩＦ２５は、例えば、マウス、キーボード等の情報入力機器である入力部と、画像を表示出力する機器である表示部とを含み得る。

端末装置１０（換言すると、コンピュータ、情報処理装置）は、例えば、スマートフォン、フィーチャーフォン、ＰＤＡ（Personal Digital Assistant）、タブレット型コンピュータ、パーソナルコンピュータ、ウェアラブル端末、またはゲーム装置等であってもよい。端末装置１０は、携帯端末であってもよい。端末装置１０は、ユーザがサービスの提供を受ける際（例えばゲームを実行する際）に可搬型の端末であってもよい。

端末装置１０は、プロセッサ１１と、メモリ１２と、ストレージ１３と、通信ＩＦ１４と、入出力ＩＦ１５と、入力部１７と、表示部１８と、を備える。端末装置１０が備えるこれらの構成は、通信バスによって互いに接続される。

プロセッサ１１は、端末装置１０全体の動作を制御する。プロセッサ１１は、ＣＰＵ、ＭＰＵおよびＧＰＵ等を含み得る。プロセッサ１１は、ストレージ１３からプログラムを読み出し、メモリ１２に展開する。プロセッサ１１は、展開したプログラムを実行する。

メモリ１２は、主記憶装置である。メモリ１２は、例えば、ＲＯＭおよびＲＡＭ等の記憶装置により構成される。メモリ１２は、プロセッサ１１がストレージ１３から読み出したプログラムおよび各種データを一時的に記憶することにより、プロセッサ１１に作業領域を提供する。メモリ１２は、プロセッサ１１がプログラムに従って動作している間に生成した各種データも一時的に記憶する。

ストレージ１３は、補助記憶装置である。ストレージ１３は、例えば、フラッシュメモリまたはＨＤＤ等の記憶装置により構成される。ストレージ１３には、サービスに関する各種データが格納される。

通信ＩＦ１４は、端末装置１０とサーバ２０等との間におけるネットワークを介した各種データの送受信を制御する。

入出力ＩＦ１５は、端末装置１０がデータの入力を受け付けるためのインターフェースであるとともに、端末装置１０がデータを出力するためのインターフェースである。入出力ＩＦ１５は、例えばＵＳＢ（Universal Serial Bus）等を介してデータの入出力を行うこととしてもよい。入出力ＩＦ１５は、入力部１７または表示部１８等を含み得る。

入力部１７は、ユーザによる入力を受け付ける。入力部１７は、例えば、タッチパッド等のポインティングデバイスであってもよい。表示部１８は、画像を表示する。表示部１８は、例えば、液晶ディスプレイまたは有機ＥＬ（Electro-Luminescence）ディスプレイ等であってもよい。端末装置１０は、例えば、入力部１７と表示部１８とを組み合わせた電子部品であるタッチスクリーン１６を備える。

入力部１７は、ユーザの操作（例えば、タッチ操作、タップ操作、スライド操作、スワイプ操作、フリック操作、ピンチイン操作およびピンチアウト操作等）により入力面に対して入力された位置を検知し、検知した位置を示す情報を入力信号として送信する機能を有する。入力部１７としてのタッチパネルは、静電容量方式または抵抗膜方式等を採用することができるが、他の方式であってもよい。

なお、入力部１７は、例えば、キーボード、各種物理ボタン、各種センサ（例えば、加速度センサまたは角速度センサ等）、操作スティック、カメラ、またはマイク等であってもよい。また、表示部１８は、例えば、プロジェクタ等であってもよい。

＜システムの機能的構成＞
図２は、サーバ２０および端末装置１０の機能的構成を示すブロック図である。本実施形態におけるサーバ２０は、例えば、サービスを提供するために必要な各種データおよびプログラムを各端末装置１０に提供する機能、各端末装置１０からサービスに関するデータを収集して管理する機能、ならびに複数の端末装置１０間の同期処理を行う機能等を有する。

なお、本実施形態において、サーバ２０は、事前に登録されるユーザのアカウントを用い、各ユーザおよび端末装置１０を識別する。アカウントの登録方法は特に限定されない。例えば、端末装置１０またはパーソナルコンピュータ等の他の装置が、ユーザの操作に基づいて、ユーザのアカウント登録に必要な情報をサーバ２０に送信し、サーバ２０が、受信した情報に基づいて各ユーザのアカウントを作成および保存することとしてもよい。また、各ユーザは、自身の端末装置１０からサーバ２０にアクセスし自身のアカウントでログインして本実施形態のサービス（換言するとアプリケーション）を利用する。なお、以下では、あるユーザの端末装置１０といった場合、当該あるユーザが自身のアカウントでログインしている端末装置１０等を指す。

図２に示すように、サーバ２０は、プロセッサ２１、メモリ２２、ストレージ２３、通信ＩＦ（インターフェース）２４、および入出力ＩＦ２５等の協働によって、制御部２１０および記憶部２２０として機能する。記憶部２２０は、制御部２１０が使用する各種データを格納する。各種データとして、例えば、プログラム２２１、サービス情報２２２およびユーザ情報２２３がある。

プログラム２２１は、サービスを実現するためのプログラムである。サービス情報２２２およびユーザ情報２２３は、制御部２１０がプログラム２２１を実行するときに参照するデータである。

なお、プログラム２２１は、サーバ２０側で実行するプログラムに加え、端末装置１０に送信して端末装置１０側で実行するプログラム（後述するプログラム１２１）を含むこととしてもよい。あるいは、記憶部２２０が、サーバ２０側で実行するプログラム２２１と、端末装置１０側で実行するプログラムとを格納することとしてもよい。

サービス情報２２２は、アカウント間で共通の情報である。サービス情報２２２は、例えば、各種仮想空間を規定するための情報を含む。仮想空間とは、ユーザのキャラクタ等のオブジェクトが配置される空間である。また、サービス情報２２２は、例えば、仮想空間内に配置される建物や木、石等の背景オブジェクトやノンプレイヤキャラクタ（non player character：ＮＰＣ）の配置位置や大きさ、色、形状等、アカウント間で共通のオブジェクトに関する各種設定情報を含む。また、サービス情報２２２は、例えば、ノンプレイヤキャラクタの各種パラメータの設定値等を含む。以下においては、仮想空間に配置されるキャラクタのオブジェクトを指して、単に「キャラクタ」ということもある。

ユーザ情報２２３は、サービスのアカウントごとに管理される情報である。ユーザ情報２２３は、例えば、ユーザのキャラクタに関する情報、後述する関連ユーザに関する情報、保有資産に関する情報、およびゲーム等の進行度合いを示す情報等を含む。保有資産として、例えば、仮想空間内の通貨やアイテム等が挙げられる。

制御部２１０は、記憶部２２０に格納されたプログラム２２１を実行することにより、サービスに関する各種処理を制御する。制御部２１０は、例えば、送受信部２１１、サーバ処理部２１２、同期処理部２１４、および関連ユーザ管理部２１５を有する。

送受信部２１１は、各種データを送信または受信する。送受信部２１１は、例えば、各種データおよびプログラムの送信要求や、マルチプレイ機能に対応するための同期処理の要求、同期処理の対象となるデータ等を、各端末装置１０から受信し、サーバ処理部２１２に渡す。また、送受信部２１１は、サーバ処理部２１２による制御に従って、同期を取るための指示等を含む各種データやプログラムを、各端末装置１０に送信する。

本実施形態において、マルチプレイ機能とは、複数のアカウントについて同期させた状態でサービスを提供する機能である。システム１のサーバ２０および端末装置１０は、システム１にログインしている複数のアカウントが一緒に所定のコンテンツを利用する場合（例えば、一緒にゲームを行う場合）等に、マルチプレイ機能に対応するための各種処理を実行する。

サーバ処理部２１２は、端末装置１０からの要求等に応じ、プログラム２２１に記述された演算処理を実行することで、端末装置１０にサービスを提供する。サーバ処理部２１２は、例えば、マルチプレイ機能に対応するための同期処理の要求や同期処理の対象となるデータを、送受信部２１１を介して端末装置１０から受け取ると、マルチプレイ機能に対応するための同期処理を実行する。また、サーバ処理部２１２は、サービス情報２２２またはユーザ情報２２３の送信指示を送受信部２１１に指令する。

同期処理部２１４は、サーバ処理部２１２からの指令に従って、マルチプレイ機能に対応するための同期処理を実行する。同期処理部２１４は、例えば、サーバ２０が複数の端末装置１０に対して情報を送信するときに、各端末装置１０に同時に情報を送信することで、各端末装置１０間で進行するゲーム等の同期を取る。具体的に、同期処理部２１４は、各アカウントに対応する端末装置１０から所定期間（例えば、一フレーム）内に受信した操作情報を、所定期間ごとに各端末装置１０に同時に送信する。操作情報は、端末装置１０に入力される操作に関する情報である。同期のタイミングや同期すべき情報は、サーバ処理部２１２から随時受信することとしてもよい。同期処理を実行することで、一つの端末装置１０で入力された操作に起因するサービス内の事象を、他の端末装置１０に同時に反映させることが可能となる。

関連ユーザ管理部２１５は、ユーザ間の関連付けに係る制御を行う。関連ユーザ管理部２１５は、関連付け部２１６、解除部２１７、リスト作成部２１８、および経緯情報管理部２１９を備える。関連ユーザ管理部２１５による制御について詳しくは後述する。

本実施形態における端末装置１０は、例えば、ユーザの入力操作を受け付ける入力装置としての機能、およびサービスに係る画像や音声を出力する出力装置としての機能等を有する。

端末装置１０は、プロセッサ１１、メモリ１２、ストレージ１３、通信ＩＦ１４、および入出力ＩＦ１５等の協働によって、制御部１１０および記憶部１２０として機能する。記憶部１２０は、制御部１１０が使用する各種データを格納する。各種データとして、例えば、プログラム１２１、サービス情報１２２およびユーザ情報１２３がある。

プログラム１２１は、端末装置１０側でサービスを実現するためのプログラムである。サービス情報１２２およびユーザ情報１２３は、制御部１１０がプログラム１２１を実行するときに参照するデータである。

サービス情報１２２は、上述したサーバ２０のサービス情報２２２と同様の情報を含む。したがって、ここではサービス情報１２２の説明を省略する。

ユーザ情報１２３は、端末装置１０を使用するユーザのアカウントに関するデータであり、上述したサーバ２０のユーザ情報２２３と同様の情報を含む。したがって、ここではユーザ情報１２３の説明を省略する。

制御部１１０は、記憶部１２０に格納されたプログラム１２１を実行することにより、端末装置１０において実行されるサービスに関する各種処理を制御する。制御部１１０は、例えば、操作受付部１１１、送受信部１１２、進行部１１３、および表示制御部１１４を有する。

操作受付部１１１は、入力部１７を介してユーザにより入力される操作（以下、「入力操作」ともいう。）を受け付ける。具体的には、操作受付部１１１は、入力部１７に対する入力操作がされた場合に、入力位置の座標および入力操作の種類を検知する。入力操作の種類として、例えば、タッチ操作、タップ操作、スライド操作、スワイプ操作、フリック操作、ピンチイン操作およびピンチアウト操作等の、手指等による各種操作が挙げられる。入力操作は、入力部１７（例えば、タッチスクリーン１６）に物理的に接触する操作に限らず、非接触による操作も含み得る。なお、タッチスクリーン１６への接触を終了するタッチオフ操作等のそれまで行っていた入力操作を終了する操作も、入力操作の一態様ということができる。

ここで、操作受付部１１１は、入出力ＩＦ１５を介して接続された操作機器を用いてされる入力操作についても、入力部１７に対する入力操作と同様に受け付けることができる。

送受信部１１２は、各種データを送受信する。以下に、具体例を挙げて説明する。

送受信部１１２は、サービス情報１２２またはユーザ情報１２３や、マルチプレイ機能に対応するための同期要求等を、サーバ２０に送信する。送受信部１１２は、各種データ、プログラム、およびマルチプレイ機能に対応するための同期のためのデータ等を、サーバ２０から受信する。同期のためのデータには、例えば、マルチプレイに参加している各端末装置１０間で同期を取るように指示するための同期指示データが含まれる。同期指示データには、例えば、同期対象となるデータおよびそのデータの種類や、同期する時期を特定するためのデータ等が含まれる。

送受信部１１２は、操作受付部１１１により受け付けられた入力操作に関する操作情報を、サーバ２０に送信する。送受信部１１２は、他の端末装置１０において他のユーザにより入力された操作に関する操作情報を、サーバ２０から受信する。

進行部１１３は、サービスの進行（例えばゲームの進行等）に関する各種処理を実行する。以下に、具体例を挙げて説明する。

進行部１１３は、サービス情報１２２に含まれる仮想空間を規定するための情報に基づいて、仮想空間を規定する。進行部１１３は、サービス情報１２２に含まれるオブジェクトの設定情報に基づいて、仮想空間にオブジェクトを配置する。進行部１１３は、仮想空間に配置したオブジェクトを制御する。具体的には、進行部１１３は、仮想空間内でのオブジェクトの位置、向き、形状、色等を変更することや、オブジェクトに所定の動作を行わせるように、オブジェクトを制御する。

進行部１１３は、仮想空間のうちユーザに提示する領域を指定するための仮想カメラを規定する。進行部１１３は、仮想空間内での仮想カメラの位置および向きを規定することにより、仮想空間内に仮想カメラを配置する。進行部１１３は、仮想カメラにより規定される視野領域およびこの視野領域に配置されているオブジェクトを描画した画像を生成するように、表示制御部１１４に指示する。

仮想カメラの位置および向きは、仮想空間ごとに適宜決定することができる。例えば、進行部１１３は、特定のオブジェクトの位置や向きを基準とし、特定のオブジェクトが特定の向きで視野領域の中央に位置するように、仮想カメラを配置する。その際、進行部１１３は、特定のオブジェクトに対する方向、距離および角度を用い、仮想カメラの位置や向きを調整する。特定のオブジェクトは、例えば、ユーザのキャラクタやノンプレイヤキャラクタ等の動的なオブジェクトであってもよいし、建物や木、石等の静的なオブジェクトであってもよい。動的なオブジェクトには、各ユーザの操作に基づいてそれぞれ動作するキャラクタと、プログラム１２１，２２１に基づいて動作するキャラクタ（例えば、ノンプレイヤキャラクタ等）とが含まれる。

進行部１１３は、操作受付部１１１により検知された入力位置の座標および入力操作の種類等に基づいて、ユーザの指示内容を解釈する。進行部１１３は、解釈した指示内容等に基づいて、サービスの進行に関わる各種判定処理を実行する。進行部１１３は、判定処理の結果等に基づいて、オブジェクトや仮想カメラ等を制御しながらサービスを進行する。進行部１１３は、サービスの進行状況に応じて、サービス情報１２２やユーザ情報１２３を更新、追加または削除する。

表示制御部１１４は、表示部１８に画像を表示させる。以下に、具体例を挙げて説明する。

表示制御部１１４は、仮想空間のうち、進行部１１３が規定する仮想カメラの視野の領域と、その領域に存在するオブジェクトとを描画した画像を生成し、表示部１８に表示させる。表示制御部１１４は、表示部１８に表示させる画像に対し、例えば、アイコン、ボタン、各種パラメータを示すメニュー等、サービスの種々の操作に必要なＵＩ（User Interface）に関わるオブジェクトを重畳して描画することができる。

なお、図２に示す端末装置１０およびサーバ２０の機能は一例にすぎない。端末装置１０およびサーバ２０の各装置は、他の装置が備える機能の少なくとも一部を備えていてもよい。換言すると、本実施形態において端末装置１０が備える機能ブロックの一部または全部をサーバ２０が備えていてもよく、サーバ２０の備える機能ブロックの一部または全部を端末装置１０が備えていてもよい。また、端末装置１０およびサーバ２０等の各装置は、一体の機器により実現されるものでなくてもよく、例えば、ネットワーク等を介して接続される複数の機器によって実現されてもよい。また、システム１は、例えば、端末装置１０またはサーバ２０のみによって構成されていてもよい。換言すると、システム１は、ネットワークを介して接続される複数の機器によって実現されていなくてもよい。

＜本実施形態に係る処理＞
次に、本実施形態に係る処理について説明する。なお、本実施形態では、端末装置１０のプロセッサ１１またはサーバ２０のプロセッサ２１が、システム１に記憶されているプログラムを実行することによって、後述する各処理を行うものとして説明する。ただし、後述する処理であってプロセッサ１１が行う処理のうちの少なくとも一部を、プロセッサ１１とは別のプロセッサが実行するようにしてもよい。また、後述する処理であってプロセッサ２１が行う処理のうちの少なくとも一部を、プロセッサ２１とは別のプロセッサが実行するようにしてもよい。換言すると、本実施形態においてプログラムを実行するコンピュータは、端末装置１０およびサーバ２０のいずれであってもよく、また、複数の装置の組み合わせにより実現されてもよい。

本実施形態のシステム１が提供するサービス（換言するとシステム１が実行するアプリケーション）は、例えば、ゲームであってもよく、ＳＮＳ（Social Networking Service）であってもよく、メタバースに係るもの等であってもよい。

本実施形態のサービスでは、ユーザは、他のユーザをフレンドとして登録することができる。フレンドとは、当該あるユーザと当該他のユーザとが互いに関連付けられている関係のことをいう。換言すると、フレンドとは、一方のユーザが他方のユーザに関連付けられているとともに、他方のユーザが一方のユーザに関連付けられている関係をいう。すなわち、第１のユーザから見て第２のユーザがフレンドである場合、当該第２のユーザから見て当該第１のユーザはフレンドとなる。フレンドとは、あるユーザと他のユーザとの相互の同意に基づいて成立する関係であってもよい。

本実施形態のサービスでは、ユーザは、他のユーザをフォローすることができる。フォローとは、あるユーザが、他のユーザを自らに関連付けて登録することをいう。すなわち、第１のユーザが第２のユーザをフォローしている場合に、当該第２のユーザが当該第１のユーザをフォローしているとは限らない。フォローとは、一方の意思に基づいて成立し得る関係であってもよい。

各ユーザに関連付けられている他のユーザを示す情報は、ユーザ情報２２３として記憶部２２０に記憶される。なお、当該情報は、ユーザ情報１２３として記憶部１２０に記憶されてもよい。また、当該情報は、各ユーザに関連付けられているユーザ（例えば、各ユーザのフレンドあるいはフォローしているユーザ）を識別可能なものであればよい。具体的には、例えば、各ユーザを一意に識別可能なユーザＩＤ（換言すると識別情報）を利用し、各ユーザのユーザＩＤに、各ユーザに関連付けられている他のユーザのユーザＩＤを紐付けて記憶しておくことにより、各ユーザのフレンドあるいはフォローしているユーザを管理してもよい。すなわち、あるユーザについて他のユーザをフレンドあるいはフォローするフレンドとして登録する場合、当該他のユーザのユーザＩＤを当該あるユーザのユーザＩＤに紐づけて記憶部２２０に記憶することとしてもよい。

なお、各ユーザは、自身のフレンドについては、フレンドではないユーザに比べて、ユーザに関する情報（例えば、当該ユーザがログインしているか否かを示す情報や、当該ユーザが発する情報や、当該ユーザの後述するランクに関する情報等）を、自身の端末装置１０で容易に閲覧（換言すると、確認）できるようになっていてもよい。換言すると、ユーザが他のユーザとフレンドとなっている場合、当該他のユーザとフレンドとなっていない場合に比べ、当該ユーザは、当該他のユーザに関する情報の閲覧について有利であってもよい。なお、情報の閲覧について有利とは、閲覧をするために必要な端末装置１０での操作数が少ないなど閲覧に要する手間が少ない場合や、閲覧に関する時期的な制限が少ない場合や、他方の場合には閲覧できない特定の情報を閲覧できる場合等を含む。また、サービス内には、例えば、自身のフレンドとしか使用できない機能が存在してもよい。具体的には、サービス内には、自身のフレンドとしか行えない特定の機能や特定のゲーム等が存在してもよい。また、サービス内では、自身のフレンドとの間でしか所定のメッセージの送信あるいは受信が行えないこととしてもよい。また、サービス内では、自身のフレンドとの間でしか保有資産の交換（例えば、アイテムの受け渡し）が行えないこととしてもよい。換言すると、フレンドとは、サービス内の所定の機能であって、フレンドではないユーザとの間では利用することができない機能（例えば、フォローしているユーザとの間でも利用することができない機能）を利用することができるユーザのことであってもよい。なお、当該機能は、フレンドとのマッチング（換言すると、特定のコンテンツを一緒に利用すること（例えば、同一の試合やイベント等に参加することなど））を容易化する機能等であってもよい。

また、各ユーザは、自身のフォローしているユーザについては、フォローしていない（かつフレンドではない）ユーザに比べて、ユーザに関する情報を、自身の端末装置１０で容易に閲覧（確認）できるようになっていてもよい。換言すると、ユーザが他のユーザをフォローしている場合、当該他のユーザをフォローしていない場合に比べ、当該ユーザは、当該他のユーザに関する情報の閲覧について有利であってもよい。また、サービス内には、例えば、自身のフォローしているユーザとしか使用できない機能が存在してもよい。換言すると、フォローしているユーザとは、サービス内の所定の機能であって、フォローしていない（かつフレンドではない）ユーザとの間では利用することができない機能を利用することができるユーザのことであってもよい。なお、一方のユーザが他方のユーザをフォローしている場合であって、当該他方のユーザが当該一方のユーザをフォローしていない場合が存在してもよい。この場合には、当該一方のユーザは、当該他方のユーザに比べ、相手方に関する情報の閲覧について有利であってもよい。具体的には、例えば、当該一方のユーザは当該他方のユーザに関する特定の情報が閲覧できるが、当該他方のユーザは、当該一方のユーザに関する特定の情報の閲覧ができないなどしてもよい。

（自動での関連付け）
関連付け部２１６は、サービス内においてあるユーザ（以下、「第１ユーザ」ともいう。）と所定の体験を共有する他のユーザを特定する。また、関連付け部２１６は、特定した当該他のユーザを、当該ユーザのフレンドとして自動で登録する。換言すると、関連付け部２１６は、特定した当該他のユーザと当該ユーザとを、自動的に互いに関連付ける。さらに換言すると、関連付け部２１６は、特定した当該他のユーザと当該ユーザとを互いに関連付ける関連付け処理を、当該ユーザによる当該関連付けを指示する操作および当該他のユーザによる当該関連付けを指示する操作を介することなく行う。なお、以下では、サービスを利用する複数のユーザのうちの任意のユーザを第１ユーザと呼ぶことがある。また、関連付け部２１６により特定される、第１ユーザのフレンドとして自動で登録する他のユーザ等の、第１ユーザ以外のユーザを第２ユーザと呼ぶことがある。

サービス内において体験を共有することの一例としては、以下が挙げられる。すなわち、所定の体験を共有するとは、例えば、「ゲームにおいて同一のクエストを行う」というものであってもよい。また、所定の体験を共有するとは、例えば、「仮想空間内において同一のイベントに参加する」というものであってもよい。また、所定の体験を共有するとは、例えば、「仮想空間内において会話（例えば、テキストメッセージによる会話等を含む）をする」というものであってもよい。また、所定の体験を共有するとは、例えば、「同一の映像（例えば、ライブ映像や、ゲーム中における特定のシーン）を見る」というものであってもよい。また、所定の体験を共有するとは、例えば、「同一のカテゴリのコンテンツ（例えば、イベントや映像）を利用する」というものであってもよい。また、所定の体験を共有するとは、例えば、「仮想空間内において同じ場所に訪れる（換言すると滞在する）」というものであってもよい。なお、ここで仮想空間内におけるユーザの位置は、現実世界におけるユーザの位置（例えば、ユーザの端末装置１０の位置）に連動するもの（換言すると応じたもの）であってもよい。

サービス内においてユーザと所定の体験を共有する他のユーザは、例えば、所定の体験を共有中の他のユーザであってもよく、共有後の他のユーザであってもよく、共有決定後の他のユーザであってもよい。ここで、所定の体験を共有決定後の他のユーザとは、例えば、ゲーム内におけるマッチングがされた他のユーザや、サービス内において所定のイベントへの参加を予約している他のユーザや、仮想空間内における所定のイベントを待機する場所（例えば、いわゆるロビー等）にいる他のユーザ等の、所定の体験を共有することが決定されている他のユーザか否かを関連付け部２１６が判別可能な他のユーザ（例えば、所定の体験の共有についての予定がサービス内において組まれている他のユーザ等）を意味し、一緒にゲームをすることを現実世界において約束しただけのユーザ等は含まない。

また、サービス内においてユーザと所定の体験を共有する他のユーザとは、例えば、サービス内において所定のコンテンツをユーザと一緒に利用する他のユーザであってもよい。換言すると、サービス内においてユーザと所定の体験を共有する他のユーザとは、例えば、所定のコンテンツを一緒に利用中の他のユーザであってもよく、一緒に利用した他のユーザであってもよく、一緒に利用すること決定後の他のユーザであってもよい。

サービス内において所定のコンテンツを一緒に利用することの一例としては、以下が挙げられる。すなわち、所定のコンテンツを一緒に利用するとは、例えば、「ゲームにおいて所定の試合やクエストに一緒に参加する（例えば、味方あるいは敵として参加する）」というものであってもよい。また、所定のコンテンツを一緒に利用するとは、例えば、「仮想空間内において所定のイベントに一緒に参加する」というものであってもよい。また、所定のコンテンツを一緒に利用するとは、例えば、「ＳＮＳまたはゲーム等において同一のグループチャットに参加する」というものであってもよい。また、所定のコンテンツを一緒に利用するとは、例えば、「所定の映像（例えば、ライブ映像や、ゲーム中における特定のシーン）を一緒に見る」というものであってもよい。

関連付け部２１６は、第１ユーザと所定の体験を共有する他のユーザを自動でフレンドとして登録する他のユーザとして特定するが、この際に、具体的には、第１ユーザと所定の体験を共有する他のユーザであって、サービス内において第１ユーザと所定の関係性を有する他のユーザを、自動で登録する他のユーザとして特定することとしてもよい。換言すると、関連付け部２１６は、第１ユーザと所定の体験を共有する他のユーザを自動でフレンドとして登録する場合に、当該他のユーザが第１ユーザと所定の関係性を有することを条件として自動でフレンドとして登録することとしてもよい。以下、所定の関係性の一例を説明する。

所定の関係性は、例えば、「サービス内における立場関係が特定の関係である関係性」であってもよい。具体的には、所定の関係性は、例えば、「所定の目的のために協力する集団（例えば、いわゆるチーム、パーティ、ギルドなど）に互いが所属している関係性」であってもよい。また、所定の関係性は、例えば、「互いが敵同士である関係性」であってもよい。

また、所定の関係性は、例えば、「少なくとも一方のユーザの属性に基づいて決まる関係性が特定の関係性である関係性」であってもよい。ここで、ユーザの属性の一例としては、ランク、性別、プレイ時間、行動傾向、または使用（換言すると所有）しているキャラクタ等が挙げられる。なお、ランクとは、ユーザの習熟度を示すものともいえ、ユーザ間での相対的な位置付けを示すものともいえる。ランクは、一般的なゲームにおいていわゆるレベルと呼ばれるもの等を含む。なお、ユーザのランクとは、ユーザ自体のランクであってもよく、ユーザの使用するキャラクタのランク等であってもよい。また、キャラクタとは、ユーザのアバター等を含む。すなわち、所定の関係性は、例えば、「ランクが第１ユーザよりも高い関係性」であってもよい。また、所定の関係性は、例えば、「サービス内における性別が一致している（あるいは異なっている）関係性」であってもよい。また、所定の関係性は、例えば、「迷惑な行為をされる確率が低い（換言すると、迷惑な行為を行うユーザではない）関係性」であってもよい。なお、迷惑な行為をされる確率が低いか否かは、例えば、過去にコンテンツの利用中（例えば他のユーザ（ここで、他のユーザは第１ユーザであってもよく、第１ユーザ以外のユーザを含む他のユーザであってもよい。）との試合中やクエスト中）においてネットワーク接続が切断された回数等をユーザ毎にユーザ情報２２３としてサーバ２０の記憶部２２０に記憶しておき、当該回数等に基づいて関連付け部２１６が判断してもよい。また、迷惑な行為をされる確率が低いか否かは、例えば、サービス内におけるチャットにおいて、予め設定されている禁止ワード（換言すると監視対象ワード）を使用した回数等をユーザ毎にユーザ情報２２３としてサーバ２０の記憶部２２０に記憶しておき、当該回数等に基づいて関連付け部２１６が判断してもよい。

また、ユーザの属性としての使用しているキャラクタに基づいて決まる関係性については、一例として、以下が挙げられる。すなわち、所定の関係性は、例えば、「使用しているキャラクタの種類が被らない（換言すると異なるキャラクタを使用している）関係性」であってもよい。また、所定の関係性は、例えば、「所定の集団（例えば、パーティ）を形成した場合にキャラクタの属性（換言するとユーザの属性）から考えて当該所定の集団のバランスが良くなる関係性」であってもよい。具体的には、所定の関係性は、例えば、「属性（換言すると得意な点等）の異なるキャラクタを使用している（例えば、ロールプレイングゲームやＦＰＳ（First Person shooter）等において、第１ユーザが攻撃の得意なキャラクタを使用し、第２ユーザが回復の得意なキャラクタを使用している）関係性」であってもよい。また、所定の関係性は、例えば、「属性の共通する（例えば、同じ）キャラクタを使用している関係性」であってもよい。

換言すると、所定の関係性（例えば、所定の集団のバランスが良くなる関係性）は、例えば、「一方のユーザの属性（例えば、「攻撃が得意」や「回復が得意」などの属性や、ユーザの使用するキャラクタの属性など）を他方のユーザの属性が補完する関係性（具体的には、例えば、「攻撃が得意」と「回復が得意」などの関係性。換言すると、一方のユーザの属性と他方のユーザの属性とが相補的な関係性。）」であってもよい。より具体的には、所定の関係性は、例えば、「一方のユーザの属性であって、ゲームの内容（換言すると、ゲームにおける所定の目的の達成（例えば、所定の敵キャラクタの討伐や、所定のステージのクリアや、チームの勝利等）に影響を与える属性を、他方のユーザの属性であって、ゲームの内容に影響を与える属性が補完する関係性」であってもよい。

また、所定の関係性は、例えば、「一方のユーザに関する所定の属性と他方のユーザに関する所定の属性とが共通する関係性」であってもよい。具体的には、所定の関係性は、例えば、「属性の共通するキャラクタを使用している関係性」であってもよい。また、所定の関係性は、例えば、「ランク帯の一致する関係性」であってもよい。また、所定の関係性は、例えば、「性別の一致する関係性」であってもよい。また、所定の関係性は、例えば、「行動傾向の類似する関係性」であってもよい。換言すると、所定の関係性は、例えば、「一方のユーザの属性であって、ゲームの内容（換言すると、ゲームにおける所定の目的の達成（例えば、所定の敵キャラクタの討伐や、所定のステージのクリアや、チームの勝利等）に影響を与える属性と、他方のユーザの属性であって、ゲームの内容に影響を与える属性とが共通する関係性」であってもよい。

また、所定の関係性は、例えば、「一緒に利用中または利用したコンテンツにおいて、少なくとも一方のユーザの行った行為に基づいて決まる関係性が特定の関係性である関係性」であってもよい。具体的には、所定の関係性は、例えば、「一緒に利用しているコンテンツにおいて、利となる行為（換言すると、アシスト行為）をしてくれた関係性」あるいは「一緒に利用しているコンテンツにおいて、利となる行為をしてあげた関係性」であってもよい。ここで、利となる行為としては、例えば、ロールプレイングゲームやＦＰＳ等において第１ユーザのキャラクタを回復させる行為（例えば、蘇生させる行為等を含む）や、第１ユーザが倒そうとしている敵キャラクタに対して攻撃を加える行為（換言するとアシスト攻撃する行為）等が挙げられる。また、所定の関係性は、例えば、「一緒に利用しているコンテンツにおいて、ネットワーク接続が切れてしまった（切断してしまったあるいは切断されてしまった）関係性」であってもよい。また、所定の関係性は、例えば、「一緒に参加しているグループチャット内において発言（具体的には一方または双方の発言）があった関係性」あるいは「一緒に参加しているグループチャット内において相互にメンションを付け合った（あるいは一方が他方に対してメンションを付けた）関係性」であってもよい。

また、所定の関係性は、例えば、「一緒に利用したコンテンツの利用結果に基づいて決まる関係性が特定の関係性である関係性」であってもよい。具体的には、所定の関係性は、例えば、「一緒に行ったゲームにおいて、仲間として勝利または敗北という結果を得た関係性」であってもよく、「一緒に行ったゲームにおいて、敵として勝利または敗北という結果を得た関係性」等であってもよい。また、所定の関係性は、例えば、「一緒に行ったゲームにおける所定の成績が、第１ユーザよりも優れている関係性」であってもよい。また、所定の関係性は、例えば、「複数回一緒にゲームを行った結果に基づいて判断される、所定のシチュエーション（例えば、各種ゲームにおける所定のステージ（換言するとマップ））においてチームを組んだ場合の勝率が高い（換言すると所定値よりも高い。ここで、所定値は固定値でなくてもよい。）関係性」であってもよい。

また、所定の関係性は、例えば、「少なくとも一方のユーザの行った行為に基づいて判断される親密度が高い（換言すると所定度合い以上である）関係性」であってもよい。ここで、関連付け部２１６は、例えば、親密度の高低を、一方のユーザが他方のユーザに対して行った好意的行動に基づいて判断してもよい。具体的には、例えば、関連付け部２１６は、ゲームにおいて第２ユーザが第１ユーザのキャラクタを蘇生してくれた場合に、第２ユーザが親密度の高い行動（蘇生させずに放置する場合等に比べて親密度が高い行動）をしてくれたとして、親密度が高い（換言すると所定度合い以上）と判断してもよい。また、関連付け部２１６は、複数の定型メッセージ（例えば、定型の文章やいわゆるスタンプ等。具体的には、例えば、「こんにちは」、「ナイスプレイ」、「がんばろう」など。）から定型メッセージを選択して相手方に送ることが可能なサービスにおいて、一方が他方に特定の定型メッセージ（例えば、「ナイスプレイ」）を送った場合に、当該一方が親密度の高い行動をしたとして、親密度が高い（換言すると所定度合い以上）と判断してもよい。なお、関連付け部２１６が、親密度が高いか否かを判断する方法は、例えば、ユーザの行う各行為（例えば、他のユーザのキャラクタを蘇生させる行為、特定の定型メッセージを送る行為など）について親密度が高い行為か否かを示す情報が付されており、当該情報に基づいて判断するものであってもよい。また、当該方法は、例えば、ユーザの行う各行為について親密度に係る数値が割り振られているとともに、記憶部２２０が当該数値の累積値を記憶するようになっており、関連付け部２１６は、サービス内におけるユーザの行為に基づいて当該累積値を増加あるいは減少させていくとともに、当該累積値が所定値以上となった場合に、親密度が高い（換言すると所定度合い以上である）と判断するもの等であってもよい。

また、所定の関係性は、例えば、「一緒に利用しているコンテンツの利用期間が所定期間以上となる関係性」であってもよい。具体的には、所定の関係性は、例えば、「一緒に参加しているグループチャットにおいて両者が当該グループチャットに参加している期間が所定期間以上である関係性」であってもよい。

なお、関連付け部２１６は、サービス内において第１ユーザと所定の関係性を有する他のユーザを、フレンドとして自動で登録する他のユーザとして特定する場合に、上に例示した一の関係性を満たす他のユーザを特定するのではなく、複数の関係性を満たす他のユーザを特定するものであってもよい。換言すると、例えば、「関連付け部２１６は、サービス内における立場関係が第１ユーザと特定の関係であるユーザをフレンドとして自動で登録する」といった場合には、フレンドとして自動で登録するユーザの条件の１つを示しているに過ぎず、例えば、当該ユーザであって、少なくとも一方のユーザの属性に基づいて決まる関係性が特定の関係性であるユーザについて自動で登録し、ユーザの属性に基づいて決まる関係性が特定の関係性でないユーザについては自動で登録しないといった構成等を含み得る。

関連付け部２１６は、ユーザが任意に設定可能な条件（以下、「登録条件」という。）を満たす他のユーザを、フレンドとして自動で登録する他のユーザとして特定してもよい。換言すると、所定の関係性は、例えば、「第１ユーザが設定した登録条件を満たす関係性」であってもよい。換言すると、所定の関係性（どのような関係性を有する他のユーザをフレンドとして自動で登録するのか）は、各ユーザが任意に設定可能となっていてもよい。さらに換言すると、登録条件の設定に応じて、上述の各関係性を満たした場合にフレンドとして自動で登録するか否かが変化するようになっていてもよい。

具体的には、関連付け部２１６は、例えば、第１ユーザと所定の体験を共有する他のユーザであって、第１ユーザが登録条件として指定している属性（例えば、ランク、性別、プレイ時間、行動傾向、またはキャラクタ（例えばキャラクタの属性）等）を有する他のユーザを、第１ユーザのフレンドとして自動で登録してもよい。

なお、このように、ユーザが任意に設定可能な登録条件を満たすユーザをフレンドとして自動で登録することとした場合に、関連付け部２１６は、一方のユーザが設定した登録条件を他方のユーザが満たす場合であって、かつ、当該他方のユーザが設定した登録条件を当該一方のユーザが満たす場合に、当該一方のユーザと当該他方のユーザとをフレンドとして自動で登録することとしてもよい。換言すると、関連付け部２１６は、一方のユーザから見て所定の関係性を有する他方のユーザを、当該一方のユーザのフレンドとして自動で登録する場合において、当該一方のユーザが当該他方のユーザから見て所定の関係性を有するユーザであることを条件として、両者をフレンドとして登録することとしてもよい。

なお、登録条件をユーザが任意に設定できることとした場合に、その設定方法については、特に限定されるものではないが、例えば以下のようにしてもよい。具体的には、各ユーザは、登録条件として、フレンドになりたいユーザの条件を自身の端末装置１０から設定することとしてもよい。換言すると、フレンドになりたいユーザの条件を規定するホワイトリストの設定が可能となっていてもよい。また、各ユーザは、登録条件として、フレンドになりたくないユーザの条件を自身の端末装置１０から設定することとしてもよい。換言すると、フレンドになりたくないユーザの条件を規定するブラックリストの設定が可能となっていてもよい。さらに換言すると、登録条件を満たすユーザとは、フレンドになりたくないユーザの条件として設定された条件を満たさないユーザのことであってもよい。

なお、あるユーザが第１ユーザと所定の関係性を有するか否かは、第１ユーザの属性に応じて変わることとしてもよい。具体的には、例えば、ＦＰＳにおいて、第１ユーザが攻撃の得意なキャラクタを使用している場合には、所定の関係性を有するユーザは、回復の得意なキャラクタを使用しているユーザであり、第１ユーザが回復の得意なキャラクタを使用している場合には、所定の関係性を有するユーザは、攻撃の得意なキャラクタを使用しているユーザである等してもよい。

また、所定の関係性の成立には、回数に関する条件があってもよい。具体的には、例えば、第１ユーザとサービス内において所定の体験を共有する他のユーザ、具体的には同じカテゴリのイベントに参加した他のユーザを、関連付け部２１６がフレンドとして自動で登録する場合に、同じカテゴリのイベントにＮ回（ここで、Ｎは１以上の整数）参加した他のユーザを、フレンドとして自動で登録することとしてもよい。また、例えば、第１ユーザと所定のコンテンツを一緒に利用する他のユーザ、具体的にはゲームにおいて同じ試合に参加した他のユーザを、関連付け部２１６がフレンドとして自動で登録する場合に、同じ試合にＮ回参加（例えば、Ｎ回連続で参加）した他のユーザを、フレンドとして自動で登録することとしてもよい。また、例えば、一緒に利用しているコンテンツにおいて、利となる行為をしてくれた他のユーザを、関連付け部２１６がフレンドとして自動で登録する場合に、利となる行為をＮ回してくれた他のユーザを、フレンドとして自動で登録することとしてもよい。また、例えば、一緒に参加しているグループチャット内において相互にメンションを付け合った（あるいは一方が他方に対してメンションを付けた）他のユーザを、関連付け部２１６がフレンドとして自動で登録する場合に、Ｎ回メンションを付けた他のユーザを、フレンドとして自動で登録することとしてもよい。なお、当該回数に関する条件（具体的には、Ｎをいくつにするか等）は、登録条件（具体的には、登録条件の少なくとも一部）としてユーザが任意に設定できることとしてもよい。

関連付け部２１６が、所定の体験を共有する（例えば、所定のコンテンツを一緒に利用する）ユーザを、フレンドとして自動で登録するタイミングは、例えば、所定の体験の共有中であってもよく、共有後であってもよく、共有することが決定されたときであってもよい。

すなわち、例えば、第１ユーザと所定のコンテンツを一緒に利用中の第２ユーザを自動で登録する場合に、コンテンツの利用中において特定の条件を満たした第２ユーザを、当該特定の条件を満たしたタイミングで自動で登録することとしてもよい。特定の条件を満たした第２ユーザとは、例えば、ゲーム中において、第１ユーザの利となる行為（換言するとアシスト行為）をした第２ユーザであってもよい。また、特定の条件を満たした第２ユーザとは、例えば、ゲーム中において、ネットワーク接続が切れたユーザであってもよい。また、特定の条件を満たしたユーザとは、例えば、第１ユーザと同じグループチャットに参加する第２ユーザであって、当該グループチャット内において発言をした第２ユーザ、または当該グループチャット内において相互にメンションを付け合った（あるいは一方が他方に対してメンションを付けた）第２ユーザ等であってもよい。また、特定の条件を満たした第２ユーザとは、ここで例示した行為等を複数回行った第２ユーザ（例えば、第１ユーザの利となる行為を複数回行った第２ユーザや、メンションを複数回付け合った（あるいは付けた）第２ユーザ等）であってもよい。なお、特定の条件を満たすとは、所定の関係性が成立することとなる条件を満たすことであってもよく、所定の関係性が成立することとなる条件以外の条件を満たすことであってもよい。

また、例えば、第１ユーザと所定のコンテンツを一緒に利用した第２ユーザを自動で登録する場合に、コンテンツの利用中において特定の条件を満たした第２ユーザ、またはコンテンツの利用結果について特定の条件を満たした第２ユーザを、当該コンテンツの利用が終了したタイミングで自動で登録することとしてもよい。なお、コンテンツの利用結果について特定の条件を満たした第２ユーザとは、例えば、ゲームにおいて仲間あるいは敵として勝利という結果または敗北という結果を得たユーザであってもよく、勝利という結果または敗北を得たユーザであって所定の成績を残したユーザ等であってもよい。なお、自動で登録するタイミングは、例えば、ゲームが終了した後、リザルト（換言すると成績）の表示中（例えば、第１ユーザの端末装置１０の表示部１８等において、リザルトが表示されているとき）等であってもよい。

また、例えば、第１ユーザと所定のコンテンツを一緒に利用した第２ユーザを自動で登録する場合に、コンテンツの利用中において特定の条件を満たした第２ユーザ、コンテンツの利用結果について特定の条件を満たした第２ユーザ、またはコンテンツの利用後に特定の条件を満たした第２ユーザを、当該コンテンツの利用が終了してから所定の期間が経過したタイミングで自動で登録することとしてもよい。具体的には、例えば、レベル１０以上となった場合に所定の関係性が成立する第２ユーザがいた場合において、一緒に行った試合の終了時点において第２ユーザのレベルがレベル１だったものの、その後期間が経過してレベル１０となった場合に、第２ユーザがレベル１０になったことに基づいて第２ユーザをフレンドとして自動で登録することとしてもよい。この場合、関連付け部２１６は、当該試合が終了してから第２ユーザがレベル１０になるまでの間、サーバ２０の記憶部２２０に、第２ユーザをフレンド候補として記憶しておき、レベル１０になったか（所定の関係性が成立する状態となったか）否かの監視を続けることとしてもよい。

また、例えば、第１ユーザと所定のコンテンツを一緒に利用することが決まっている第２ユーザをフレンドとして自動で登録する場合に、例えば、マッチングがされた直後のタイミングで自動で登録することとしてもよく、一緒に参加するゲームやイベントが開始されるタイミングで自動で登録することとしてもよく、第１ユーザと第２ユーザとの双方がグループチャットに参加したタイミングで自動で登録することとしてもよい。

なお、ここで説明したフレンドとして自動で登録するタイミングは、後述するフレンド登録またはフォローの申請を行うタイミング（換言すると、当該申請に係る後述する承諾画面を表示するタイミング）として読み替えてもよい。

なお、関連付け部２１６が、第１ユーザのフレンドとして自動で登録する第２ユーザを特定するタイミングと、第２ユーザを第１ユーザのフレンドとして自動で登録するタイミングとは、異なっていてもよい。

なお、各ユーザに関連付けることができるユーザの数（例えば、各ユーザのフレンドの数）に上限が設けられている場合に、関連付け部２１６は、例えば、第１ユーザに関連付けられている他のユーザの数が上限に対して所定割合未満である場合に自動での関連付けを行い、所定割合以上の場合に自動での関連付けを行わないこととしてもよい。換言すると、関連付け部２１６が他のユーザを自動で関連付けるための条件は、関連付けられている他のユーザの数に応じて緩和あるいは厳しくされてもよい。

なお、ここでは、関連付け部２１６は、特定した第２ユーザを第１ユーザのフレンドとして自動で登録するものとして説明したが、関連付け部２１６は、特定した第２ユーザを、第１ユーザがフォローするユーザとして自動で登録することとしてもよい。換言すると、関連付け部２１６は、特定した第２ユーザを第１ユーザに自動的に関連付けることとしてもよい。さらに換言すると、関連付け部２１６は、特定した第２ユーザを第１ユーザに関連付ける処理を、第１ユーザによる当該関連付けを指示する操作を介することなく行うこととしてもよい。また、関連付け部２１６は、特定した第２ユーザに対する、第１ユーザからのフレンド登録の申請またはフォローの申請を、自動で行うこととしてもよい。換言すると、関連付け部２１６は、特定した第２ユーザに対する、第２ユーザの第１ユーザへの関連付けに係る申請を自動で行うこととしてもよい。さらに換言すると、関連付け部２１６は、特定した第２ユーザに対する、第２ユーザの第１ユーザへの関連付けに係る申請を、第１ユーザによる当該申請を指示する操作を介することなく行う申請部として機能してもよい。なお、第２ユーザに対して、第２ユーザの第１ユーザへの関連付けに係る申請（具体的には、フレンド登録の申請またはフォローの申請）がされた場合、例えば、第２ユーザが、自身の端末装置１０で当該申請を承諾する所定の入力操作を行った場合等に、第１ユーザに第２ユーザが関連付けられる（換言すると、第１ユーザと第２ユーザとがフレンドとなるか、または第１ユーザが第２ユーザをフォローした状態となる）。

なお、他のユーザをフレンドまたはフォローするユーザとして自動で登録するか否か、あるいは、他のユーザに対してフレンド登録あるいはフォローの申請を自動で行うか否かは、各ユーザが自身の端末装置１０から設定可能となっていてもよい。

なお、本実施形態において、各種処理を「ユーザによる操作を介することなく行う」等といった場合には、当該処理を行う際にユーザによる操作が不要なものであればよく、例えば、当該処理を行うための条件を予め設定しておく操作や、自動での当該処理の実行を有効化する操作等の、ユーザによる事前の設定操作等は行われるものであってもよい。具体的には、「第２ユーザの第１ユーザへの関連付けに係る申請を、第１ユーザによる当該申請を指示する操作を介することなく行う」といった場合には、例えば、従来のゲーム等におけるフレンド登録を申請するボタンをタップする操作等を要さずに当該申請が行われるものであればよく、当該申請を自動で行うための事前の設定操作等については行われるものであってもよい。

なお、本実施形態のサービスは、他のユーザをフレンドとして登録する機能およびフォローするユーザとして登録する機能のいずれか一方を有さないものであってもよい。また、他のユーザをフレンドとして登録する機能およびフォローするユーザとして登録する機能の両方を有する場合において、いずれか一方については、自動での登録あるいは登録についての申請が行われるが、他方については自動での登録および登録についての申請が行われないこととしてもよい。また、他のユーザをフレンドとして登録する機能およびフォローするユーザとして登録する機能の両方を有し、両方について自動での登録あるいは登録についての申請が行われるが、それぞれについての自動で行うための条件は異なるなどしてもよい。

（関連付けの解除）
ここまで、関連付け部２１６により特定された第２ユーザについて、自動でフレンドとして登録すること、自動でフォローすること、および自動でフレンド登録あるいはフォローの申請をすることを説明した。換言すると、関連付け部２１６により特定された第２ユーザについて、ユーザ間の関連付けに係る処理を自動で行うことについて説明した。以下では、このように関連付けに係る処理が自動でされ、当該処理に基づいて第１ユーザに関連付けられた第２ユーザ（すなわち、第１ユーザのフレンドあるいはフォローしているユーザ。以下、「関連ユーザ」ともいう。）について、第１ユーザとの関連付けを解除する動作について説明する。なお、関連ユーザには、自動で関連付けられたユーザのみならず、例えば、第１ユーザが自身の端末装置１０からフレンド登録またはフォローの申請を行い、相手方ユーザが自身の端末装置１０で当該申請を承諾したことによりフレンドとなったユーザまたはフォローしているユーザ等が含まれてもよい。換言すると、関連ユーザには、手動で関連付けられたユーザ（具体的には、フレンド登録またはフォローの申請が第１ユーザの入力操作に基づいて行われ、当該申請に基づいて関連付けられたユーザ）が含まれてもよい。なお、ここで、フレンド登録またはフォローの申請が第１ユーザの入力操作に基づいて行われた場合に、第２ユーザの承諾を要することなく、第２ユーザが第１ユーザのフレンドまたはフォローするユーザとして登録されるようになっていてもよく、第２ユーザの承諾を介して当該登録がされるようになっていてもよい。なお、以下では、フレンドとしての登録もしくはフォローまたはこれらの申請が自動で行われ、関連付けられたユーザのことを「自動で関連付けられたユーザ」ともいう。

記憶部２２０は、ユーザ間の関連付けの解除に係る条件（以下、「解除条件」という。）を記憶する。解除部２１７は、各ユーザに関連付けられた関連ユーザのうち、解除条件を満たすユーザを、関連付けを解除するユーザ（以下、「解除ユーザ」という。）として特定する。また、解除部２１７は、特定した解除ユーザとの関連付けを解除する。

解除条件は、例えば、「所定期間一緒にコンテンツを利用していない（換言すると、所定期間一緒にプレイしていない）」というものであってもよい。また、解除条件は、例えば、「関連ユーザ（あるいは第１ユーザ）が、所定期間ログインしていない（換言すると、サービスを利用していない）」というものであってもよい。また、解除条件は、例えば、「メッセージの送信に関する頻度が低い（例えば、所定期間内における第１ユーザと関連ユーザとのうちの一方から他方へのメッセージの送信回数（あるいは双方からのメッセージの送信回数の合計）が所定回数以下）」というものであってもよい。また、解除条件は、例えば、「関連ユーザのランクが所定期間変化していない」というものであってもよい。また、解除条件は、例えば、「関連ユーザによってサービス内のチャットが荒らされた」というものであってもよい。なお、チャットが荒らされたか否かは、例えば、予め設定されている禁止ワード（換言すると監視対象ワード）を使用した回数が所定回数以上か否かに基づいて判断してもよく、関連ユーザから第１ユーザへのメッセージの送信回数が、第１ユーザから関連ユーザへのメッセージの送信回数に比べて過大であるか否か等に基づいて判断してもよい。

解除条件は、各ユーザが、自身の端末装置１０から任意に設定可能となっていてもよい。例えば、端末装置１０の表示部１８に、上述の各解除条件が選択項目として表示され、適用したい解除条件（あるいは適用を中止したい解除条件）を選択する入力操作をユーザが行うことで、解除条件が設定できるようになっていてもよい。

また、解除条件は、ユーザが任意に変更することができないものであってもよい。換言すると、解除条件のうちの少なくとも一部は、ユーザが任意に変更することはできず、全ユーザに適用されるものであってもよい。

また、解除条件として複数の条件が設定されている場合に、解除部２１７は、当該複数の条件のうちの１の条件を満たす関連ユーザとの関連付けを解除することとしてもよく、複数（例えば全部）の条件を満たす関連ユーザとの関連付けを解除することとしてもよい。

関連ユーザの自動解除に係る解除条件は、自動で関連付けられたユーザに適用されるものであって、手動で関連付けられたユーザには適用されないものであってもよい。ここで、「自動で関連付けられたユーザに適用され、手動で関連付けられたユーザに適用されない」とは、例えば、（１）システム上、手動で関連付けられたユーザについては解除条件に基づく関連付けの自動解除が行われることがない構成の場合、および、（２）手動で関連付けられたユーザについては自動で関連付けられたユーザの自動解除に係る解除条件とは異なる第２の解除条件に基づく自動での関連付けの解除が行われる構成の場合などを含む。なお、（２）の構成については、ユーザの選択に応じて、手動で関連付けられたユーザと自動で関連付けられたユーザとの両方について同一の解除条件に基づく自動での関連付けの解除が可能な構成も含む。このような構成によれば、ユーザが主体的に関連付けた他のユーザであって、関連付けの維持を希望する可能性が高い手動での関連付けがされたユーザについては、自動で解除されないようにし（あるいは解除されにくくし）、手動で関連付けられたユーザに比べて関連付けの維持を希望する可能性が低い自動での関連付けがされたユーザについては、自動で解除されるようにすることができる。

解除条件は、ユーザに関連付けられた関連ユーザの数に応じて緩和あるいは厳しくされてもよい。換言すると、解除部２１７は、ユーザに関連付けられた関連ユーザの数に応じて解除条件を変化させてもよい。具体的には、解除部２１７は、例えば、関連ユーザの数が多くなるほど解除条件を緩和するように（換言すると解除されやすくなるように）してもよい。ここで、関連ユーザの数が多くなるほど解除条件を緩和するとは、少なくとも、ある所定数を境とした解除条件が厳しい状態と緩和された状態との２つの状態が存在するものであればよい。ここで、所定数は、一定の数であってもよい。また、所定数は、ユーザが任意に設定可能なものであってもよい。また、所定数は、状況に応じて変動するものであってもよい。また、所定数は、例えば、一のユーザに関連付けることができる関連ユーザの数に上限数が設けられている場合に、この上限数に対する割合が所定割合以上となる数であってもよい。換言すると、解除部２１７は、例えば、あるユーザに関連付けられた関連ユーザの数が、当該上限数に近くなるほど解除条件を緩和するように（換言すると解除されやすくなるように）してもよい。なお、当該上限数は、自動で関連付けられたユーザと手動で関連付けられたユーザとで個別に設けられていてもよく、自動で関連付けられたユーザと手動で関連付けられたユーザとを合わせた数についてのものであってもよい。なお、解除条件が厳しい状態は、自動解除がされない状態であってもよい。換言すると、解除部２１７は、例えば、あるユーザに関連付けられた関連ユーザの数が、当該上限数に対して余裕がある場合には、自動で関連付けられたユーザの自動解除を行わないこととしてもよい。

なお、解除条件を緩和するとは、例えば、関連ユーザとの関連付けを自動で解除するために必要な条件の数が減少するものであってもよい。また、解除条件を緩和するとは、例えば、各解除条件に係るパラメータを変化させるもの等であってもよい。例えば、「所定期間一緒にコンテンツを利用していない」という条件等の、期間に関する定めのある条件を満たす関連ユーザについて関連付けを自動解除する場合において、当該期間を定めるパラメータを、当該期間が短くなるように変化させるもの等であってもよい。

上述のように、解除部２１７は、解除条件を満たす関連ユーザを、解除ユーザとして特定し、特定した解除ユーザとの関連付けを解除する。また、解除部２１７は、解除ユーザの特定を自動で行う。換言すると、解除部２１７は、第１ユーザへの関連付けを解除する解除ユーザを特定する際に、第１ユーザによる当該特定を指示する操作を介さずに、解除ユーザの特定を行う。

また、解除部２１７は、特定した解除ユーザとの関連付けの解除を自動で行う。換言すると、解除部２１７は、解除ユーザの第１ユーザへの関連付けを解除する際に、第１ユーザによる当該解除を指示する操作を介さずに、解除ユーザの関連付けを解除する。

なお、例えば、第１ユーザへの関連付けを解除する関連ユーザとして解除部２１７が特定した解除ユーザは、関連付けの解除がされる前に、第１ユーザに対して提示されることとしてもよい。具体的には、例えば、解除部２１７が解除ユーザを特定すると、関連付けの解除がされる前に、第１ユーザの端末装置１０の表示部１８に、特定された解除ユーザが表示されることとしてもよい。ここで、表示部１８には、解除ユーザが特定された後、第１ユーザが初めてサービスを利用（換言するとアプリケーションを起動）するときなどに、特定された解除ユーザがポップアップ表示されてもよい。また、表示部１８には、特定された解除ユーザがリストで表示されてもよい。当該リストは、関連付けを解除する予定の関連ユーザのリストともいえ、例えばリスト作成部２１８が作成する。また、このようにポップアップ表示やリスト表示等によって解除ユーザを第１ユーザに提示する画面においては、解除ユーザの関連付けの解除をするか否かの選択を促す表示等が表示され、解除部２１７は、第１ユーザによる当該解除を選択する入力操作（換言すると、関連付けの解除を指示する操作）がされた場合に解除ユーザの関連付けを解除することとしてもよい。換言すると、解除部２１７は、特定した解除ユーザの第１ユーザへの関連付けを解除する際に、第１ユーザによる当該解除を指示する操作を介して、解除ユーザの関連付けを解除してもよい。

また、解除部２１７が解除ユーザを特定し、第１ユーザへの関連付けの解除を自動で行った場合等において、第１ユーザの端末装置１０の表示部１８に、関連付けが解除された解除ユーザが表示されることとしてもよい。ここで、表示部１８には、例えば、解除ユーザの関連付けが解除された後、第１ユーザが初めてサービスを利用（換言するとアプリケーションを起動）するときなどに、解除された解除ユーザがポップアップ表示されてもよい。また、表示部１８には、関連付けが解除された解除ユーザがリストで表示されてもよい。当該リストは、関連付けが解除された関連ユーザのリストともいえ、例えばリスト作成部２１８が作成する。また、このようにポップアップ表示やリスト表示等によって関連付けが解除された解除ユーザを第１ユーザに提示する画面においては、関連付けが解除された解除ユーザとの関連付けを復活させるか（再度関連付けるか）否かの選択を促す表示等が表示され、解除部２１７は、第１ユーザによる当該復活を選択する入力操作（換言すると、再度の関連付けを指示する操作）がされた場合に、関連付けが解除された解除ユーザを、第１ユーザに再度関連付けることとしてもよい。

なお、関連付けを解除する予定の解除ユーザのリストにおいては、各解除ユーザの当該リストへの掲載期間に期限が設けられており、所定期間が経過すると、当該所定期間が経過した解除ユーザの第１ユーザへの関連付けが解除されるとともに、当該解除ユーザの当該リスト上での表示が終了することとしてもよい。また、関連付けが解除された解除ユーザのリストにおいては、各解除ユーザのリストへの掲載期間に期限が設けられており、所定期間が経過すると、当該所定期間が経過した解除ユーザの当該リスト上での表示が終了することとしてもよい。換言すると、リスト作成部２１８は、これらのリストに含まれてから所定期間が経過した解除ユーザを、リストから削除してもよい。なお、これらの各掲載期間は、ユーザに関連付けられた関連ユーザの数（例えば、上限数に対する割合等）に応じて変化してもよい。

なお、関連付けを解除する予定の解除ユーザのリストあるいは関連付けが解除された解除ユーザのリストは、リスト作成部２１８が作成して記憶部２２０等の所定の記憶部に記憶しておき、表示部１８での表示を行う際に端末装置１０に送信されるなどしてもよい。

なお、第１ユーザとの関連付けを解除する関連ユーザとして解除部２１７が特定した解除ユーザを、関連付けの解除がされる前に、第１ユーザに対して提示するか否か（当該提示をしてから解除を行うか当該提示をせずに解除を行うか）は、第１ユーザが自身の端末装置１０から設定可能となっていてもよい。また、関連付けが解除された解除ユーザを第１ユーザに提示するか否かは、第１ユーザが自身の端末装置１０から設定可能となっていてもよい。

なお、解除部２１７による自動での関連付けの解除を行いたくない関連ユーザについて、自動での関連付けの解除の対象から除外することが可能となっていてもよい。具体的には、例えば、第１ユーザの端末装置１０の表示部１８に、第１ユーザに関連付けられている関連ユーザのリストが表示され、当該リストに含まれる関連ユーザの中から、解除の対象から除外したい関連ユーザを選択する入力操作（例えば、タッチ操作等）を入力部１７が受け付け、解除部２１７が当該入力操作に基づいて、選択されたユーザを解除の対象から除外するユーザとして記憶部２２０に登録することとしてもよい。解除部２１７は、解除の対象から除外された関連ユーザについては、当該関連ユーザが解除条件を満たす関連ユーザであったとしても、自動での解除ユーザとしての特定または自動での関連付けの解除を行わない。換言すると、関連ユーザ管理部２１５は、第１ユーザに関連付けられている関連ユーザのうち、第１ユーザが指定した関連ユーザを解除の対象から除外する特別関連ユーザとして登録することとしてもよい。この場合、当該特別関連ユーザは、特別関連ユーザでない関連ユーザ（換言すると、第１ユーザから指定されていない関連ユーザ）に比べ、関連付けの解除についての制限がされる（例えば、自動での解除ユーザとしての特定または解除が行われないなど）。

（関連ユーザのリスト）
各ユーザの端末装置１０からは、自身に関連付けられている関連ユーザのリスト（以下、「関連ユーザリスト」という。）を見ることが可能となっている。各ユーザの端末装置１０の表示制御部１１４は、自身に関連付けられた関連ユーザについての関連ユーザリストを表示部１８に表示させる。関連ユーザリストが表示される関連ユーザリスト表示画面５０の一例を図３に示す。

図３に示す関連ユーザリスト表示画面５０には、各関連ユーザについて、各関連ユーザの情報としてのユーザ名および関連付けられた経緯に関する情報（以下、「経緯情報５１」という。）、経緯情報５１の入力をする際に操作する経緯情報入力ボタン５２、および関連付けに関する設定を行うための各種ボタンが表示される。そして、各ユーザは、関連ユーザリスト表示画面５０（具体的には経緯情報５１）を見ることで、各関連ユーザが自身に関連付けられた経緯を確認することが可能となっている。

経緯情報５１は、例えば、以下のように入力される。まず、第１ユーザは、特定の関連ユーザについて、経緯情報５１を入力する場合に、経緯情報入力ボタン５２を選択する入力操作を行う。当該入力操作がされると表示制御部１１４は、経緯情報入力画面６０を表示部１８に表示させる。経緯情報入力画面６０の一例を図４に示す。

経緯情報入力画面６０では、例えば、関連付けの経緯に関する複数のタグ６１が表示される。経緯情報管理部２１９は、経緯情報入力画面６０に表示された複数のタグ６１の中から第１ユーザの入力操作によって選択されたタグ６１を、当該特定の関連ユーザの経緯情報５１として当該特定の関連ユーザに付して記憶部２２０に記憶させる。なお、一人の関連ユーザに対して、複数のタグ６１を付すことが可能となっていてもよい。

ここで、タグ６１は、例えば、第１ユーザと当該特定の関連ユーザとが共有した体験（例えば、両者を関連付けるきっかけとなった一緒にプレイした試合）での出来事に関するもの（例えば、第１ユーザまたは当該特定の関連ユーザの行動に関するものや、第１ユーザまたは当該特定の関連ユーザの成績に関するもの等）であってもよく、第１ユーザと当該特定の関連ユーザとの関係性に関するもの等であってもよい。また、タグ６１は、例えば、関連ユーザを自動で関連付ける原因となった事象に関するものであってもよい。具体的には、タグ６１は、例えば、「回復してくれた」、「回復してあげた」、「アシスト攻撃してくれた」、「アシスト攻撃してあげた」、「アイテムをくれた（例えば、消費アイテムを使ってくれた場合等を含む）」、「アイテムをあげた」、「上手かった（換言すると成績が良かった）」、「下手だった（換言すると成績が悪かった）」、「共闘した」、「対戦した」、「勝利した」、「敗北した」、「一緒に特定のライブに参加した」、または「チャットで何往復以上の会話をした」などといったものであってもよい。

なお、経緯情報入力画面６０では、第１ユーザと当該特定の関連ユーザとが共有した体験において実際に起こった出来事に関するタグ６１の選択に関する補助がされてもよい。具体的には、例えば、経緯情報入力画面６０では、実際に起こった出来事に関するタグ６１が優先的に表示されてもよい。ここで、優先的にとは、例えば、実際に起こった出来事に関するタグ６１のみが表示されるものであってもよく、実際に起こった出来事に関するタグ６１の表示上の優先順位が高いもの（例えば、実際に起こった出来事に関するタグ６１ほど、上側に表示される等）であってもよい。また、例えば、経緯情報入力画面６０の表示が開始されるときには、実際に起こった出来事に関するタグ６１が選択された状態（例えば、図４に示す例においてチェックマークが付された状態）で表示が開始されてもよい。

なお、経緯情報入力画面６０は、例えば、第１ユーザに第２ユーザが自動で関連付けられたタイミング（自動でのフレンドとしての登録がされたタイミング、自動でのフォローがされたタイミング、または自動でのフレンド登録あるいはフォローの申請を第２ユーザが承諾したタイミング）で第１ユーザ（および第２ユーザ）の端末装置１０の表示部１８に表示されるなどしてもよい。また、経緯情報入力画面６０は、例えば、第１ユーザに第２ユーザを自動で関連付けることが決定された試合が終了したとき（例えば、リザルトの表示中）に、第１ユーザ（および第２ユーザ）の端末装置１０の表示部１８に表示されるなどしてもよい。換言すると、経緯情報管理部２１９は、第１ユーザに第２ユーザを自動で関連付ける際に、経緯情報５１の入力を促す表示としての経緯情報入力画面６０を表示させるための情報を端末装置１０に送信し、表示制御部１１４は、当該情報に基づいて経緯情報入力画面６０を表示部１８に表示させるなどしてもよい。また、このように、所定のタイミングで経緯情報入力画面６０を表示するなどして経緯情報５１の入力を促すこととした場合に、第１ユーザに対して第２ユーザが自動で関連付けられた場合には、第１ユーザ（および第２ユーザ）の端末装置１０において経緯情報５１の入力を促す表示がされる一方、第１ユーザに対して第２ユーザが手動で関連付けられた場合には、第１ユーザ（および第２ユーザ）の端末装置１０において経緯情報５１の入力を促す表示がされない（換言すると、経緯情報管理部２１９は、経緯情報入力画面６０を表示させるための情報を端末装置１０に送信しない）こととしてもよい。

なお、第２ユーザに対するタグ付けは、体験の共有中（例えば、両者を関連付けるきっかけとなる一緒にプレイしている試合の最中）において実行可能となっていてもよい。具体的には、第１ユーザと第２ユーザとが一緒にゲームを行っている状態において、第２ユーザが第１ユーザのキャラクタを蘇生してくれた場合等に、第１ユーザが自身の端末装置１０で、「蘇生してくれた」というタグ６１を第２ユーザに付す入力操作を行うことが可能となっており（例えば、当該タグ６１が表示部１８に表示され、これを選択する入力操作が可能となっており）、関連付け部２１６は、当該入力操作に基づいて、当該タグ６１を、第２ユーザの経緯情報５１として第２ユーザに付して記憶部２２０に記憶させるなどしてもよい。なお、この場合に、タグ６１は、体験の共有中であって、第２ユーザを第１ユーザに関連付けることが決定される前に第２ユーザに付すことが可能となっていてもよい。また、関連付け部２１６は、当該タグ６１が付されたことに基づいて、第２ユーザを第１ユーザに関連付ける（換言するとフレンドとしての登録、フォロー、またはこれらの申請をする）こととしてもよい。

なお、ここでは、経緯情報入力画面６０では、経緯情報５１がタグ６１の選択に基づいて入力されることとしたが、経緯情報５１は、経緯情報入力画面６０において、テキスト入力によって入力されるようになっていてもよい。

また、経緯情報５１は、例えば、ユーザの操作を介さずに自動的に入力されるようになっていてもよい。例えば、関連ユーザを自動で関連付ける原因となった事象が、経緯情報５１として自動で入力されるようになっていてもよい。具体的には、例えば、第２ユーザが、ゲーム中のある試合Ｘにおいて第１ユーザのキャラクタを回復させる行為（具体的には、蘇生させる行為）を３回行ってくれたことに基づいて、第２ユーザを第１ユーザの関連ユーザとして自動で登録する場合に、経緯情報管理部２１９は、第２ユーザに、「試合Ｘで３回蘇生してくれた」という経緯情報５１を自動で（換言すると第１ユーザの操作を介することなく）付し、関連ユーザに関する情報として記憶部２２０に記憶させる等してもよい。換言すると、例えば、第２ユーザを自動で関連付けるきっかけとなったプレイ（例えば試合など）時における出来事、あるいは第１ユーザと第２ユーザとの関係性等が、経緯情報５１として自動で入力されるようになっていてもよい。また、記憶部２２０に自動的に記憶された経緯情報５１は、ユーザの端末装置１０での入力操作に基づいて編集可能となっていてもよい。この場合、例えば、経緯情報管理部２１９は、当該入力操作に基づいて、経緯情報５１を編集する。

また、所定のタイミングで経緯情報入力画面６０を表示させる場合に、経緯情報５１が自動で入力された状態で表示させるとともに、経緯情報入力画面６０では、ユーザによる当該自動で入力された経緯情報５１を編集する入力操作が受け付けられるようになっていてもよい。当該入力操作は、例えば、自動で入力された経緯情報５１を編集するテキスト入力操作であってもよく、自動で付されたタグ６１（例えば、図４に示す例においてチェックマークが自動で付されている場合等を含む。）を削除したり別のタグ６１を追加したりする入力操作であってもよい。

関連ユーザリスト表示画面５０に表示される、関連付けに関する設定を行うための各種ボタンには、例えば、関連ユーザの関連付けを解除する際に操作する解除ボタン５３と、関連ユーザをお気に入りとして登録する際に操作するお気に入りボタン５４と、関連ユーザの登録条件を編集する際に操作する条件編集ボタン５５と、条件の設定を解除する際に操作する条件解除ボタン５６と、経緯情報５１に基づいて登録条件を設定する際に操作する条件設定オブジェクト５７と、が含まれる。

解除ボタン５３に対する入力操作がされると、解除部２１７は、対象の関連ユーザとの関連付けを解除する。すなわち、ユーザは、解除ボタン５３に対する操作をすることにより、手動で関連ユーザとの関連付けを解除することが可能となっている。なお、解除ボタン５３が操作された際に、表示制御部１１４は、関連付けを本当に解除してもよいか確認する確認画面等を表示部１８に表示させてもよい。

お気に入りボタン５４に対する入力操作がされると、関連ユーザ管理部２１５は、対象の関連ユーザ（換言すると、操作されたお気に入りボタン５４に係る関連ユーザ）を、お気に入りとして登録する。お気に入りとして登録された関連ユーザについては、例えば、当該関連ユーザが解除条件を満たす場合であっても、自動での解除ユーザとしての特定または自動での関連付けの解除を行わない。また、お気に入りとして登録された関連ユーザについては、例えば、解除ボタン５３に対する操作に基づいて関連付けを解除する場合等に、お気に入りとして登録されていない関連ユーザに比べて解除に必要な手順数（例えば、解除しても良いかの確認の回数等）が増えることとしてもよい。換言すると、関連ユーザ管理部２１５は、第１ユーザに関連付けられている関連ユーザのうち、第１ユーザが指定した関連ユーザを特別関連ユーザ（換言すると、お気に入り）として登録する。そして、ここで、当該特別関連ユーザは、特別関連ユーザでない関連ユーザ（換言すると、第１ユーザから指定されていない関連ユーザ）に比べ、関連付けの解除についての制限がされてもよい（例えば、自動での解除ユーザとしての特定または解除が行われない、あるいは解除をする際に第１ユーザが行う手順数が多いなど）。

なお、関連ユーザのお気に入りとしての登録は、お気に入りボタン５４に対する操作に基づくものでなくてもよい。例えば、関連ユーザ管理部２１５は、ユーザによる入力操作（例えば、テキスト入力による入力あるいはタグ６１の選択による入力等）によって経緯情報５１が入力された関連ユーザを、自動的にお気に入りとして登録してもよい。

条件編集ボタン５５に対する入力操作がされると、表示制御部１１４は、登録条件の編集を行うための編集画面（図示せず）を表示部１８に表示させる。編集画面で登録条件の編集（換言すると設定）が行われると、関連付け部２１６は、編集後の登録条件を満たすユーザを自動で関連付けるようになる。換言すると、本実施形態では、編集画面で登録条件の編集をすることにより、自動で関連付けるユーザの条件を変更することが可能となっている。さらに換言すると、本実施形態では、条件編集ボタン５５に対する入力操作に基づいて、関連ユーザの登録条件が編集可能となっている。

編集画面では、例えば、対象の関連ユーザの経緯情報５１に対応する登録条件の詳細条件を設定することが可能となっていてもよい。具体的には、「試合Ｘで３回蘇生してくれた」という経緯情報５１、すなわち「蘇生をしてくれた」という経緯情報５１が付された関連ユーザに係る条件編集ボタン５５が操作された場合、編集画面では、「蘇生をしてくれた」という登録条件についての詳細条件として、「何回」蘇生をしてくれた場合に、蘇生行為をしてくれたユーザを関連ユーザとして自動で登録するかが設定可能となっている。換言すると、当該編集画面では、当該詳細条件の設定に関する入力操作が受け付けられるようになっていてもよい。

また、編集画面では、例えば、対象の関連ユーザの経緯情報５１とは関係のない登録条件についての設定が可能となっていてもよい。具体的には、「蘇生をしてくれた」という経緯情報５１が付された関連ユーザに係る条件編集ボタン５５が操作された場合に、編集画面では、「蘇生をしてくれた」という登録条件に替え、あるいは追加して、「アイテムをくれた」という登録条件や、「共闘した」という登録条件等を設定可能となっていてもよい。

また、本実施形態では、条件設定オブジェクト５７に対する入力操作がされると、関連付け部２１６は、対象の関連ユーザの経緯情報５１に基づいて、今後自動で関連付けるために他のユーザが満たすべき条件（すなわち登録条件）を設定する。具体的には、関連ユーザリスト表示画面５０においては、各関連ユーザの経緯情報５１に基づいて抽出される登録条件が条件設定オブジェクト５７として表示される。より具体的には、例えば、関連ユーザに「試合Ｘで３回蘇生してくれた」という経緯情報５１が付されている場合には、当該経緯情報５１に基づいて抽出される登録条件として、「蘇生をしてくれた」という登録条件に係る条件設定オブジェクト５７が、関連ユーザリスト表示画面５０に表示される。そして、ユーザによる当該条件設定オブジェクト５７に対する入力操作がされると、関連付け部２１６は、今後、蘇生をしてくれた他のユーザを自動で関連付けるように「蘇生をしてくれた」という登録条件を設定（換言すると有効化）する。すなわち、本実施形態では、経緯情報５１に関連する登録条件が、設定する（換言すると有効化する）登録条件の候補として関連ユーザリスト表示画面５０に表示され、ユーザに当該登録条件の設定が提案されるようになっている。なお、条件設定オブジェクト５７の表示は、例えば、以下のようにして実現することができる。すなわち、経緯情報５１に含まれ得るキーワード（例えば、上述の例においては「蘇生」など）と、登録条件との対応関係を示すテーブルを記憶部２２０に記憶しておき、経緯情報５１に特定のキーワードが含まれる場合には、関連ユーザ管理部２１５が、当該特定のキーワードに対応する登録条件を抽出するとともに、抽出した登録条件に係る条件設定オブジェクト５７を表示部１８に表示させるための情報を端末装置１０に送信することとしてもよい。

条件解除ボタン５６は、条件設定オブジェクト５７として表示される登録条件の設定を解除（換言すると無効化）する際に操作するボタンである。条件解除ボタン５６に対する入力操作がされると、関連付け部２１６は、対象の関連ユーザの条件設定オブジェクト５７に係る登録条件を、今後自動で関連付けるために他のユーザが満たすべき条件から除外する。換言すると、条件解除ボタン５６に対する入力操作がされると、関連付け部２１６は、対象の関連ユーザの経緯情報５１に基づいて抽出される登録条件を、今後自動で関連付けるために他のユーザが満たすべき条件から除外する。なお、条件解除ボタン５６に対する入力操作がされると、関連付け部２１６は、対象の関連ユーザを自動で関連付ける際に当該関連ユーザが満たした登録条件を、今後自動で関連付けるために他のユーザが満たすべき条件から除外することとしてもよい。なお、条件解除ボタン５６に対する入力操作がされ、登録条件の設定が解除されると、条件解除ボタン５６が条件設定ボタン（図示せず）に変化し、当該条件設定ボタンに対する入力操作がされると、条件解除ボタン５６に対する入力操作に基づいて解除（換言すると無効化）された登録条件が、再度設定（換言すると有効化）されるようになっていてもよい。換言すると、条件設定オブジェクト５７は、登録条件を設定（換言すると有効化）する操作を受け付けるオブジェクトではなく、単に所定の登録条件を表示するオブジェクトであってもよい。

なお、経緯情報５１等の関連ユーザリストの表示に必要な情報は、例えば、サーバ２０の記憶部２２０に記憶されており、関連ユーザリストの表示を行う際に（例えば、操作受付部１１１に対する所定の入力操作に基づく端末装置１０からサーバ２０への要求に基づいて）、関連ユーザ管理部２１５から端末装置１０に送信される。なお、関連ユーザリストの表示に必要な情報は、記憶部１２０に記憶されていてもよい。

（分類リスト）
リスト作成部２１８は、ユーザに関連付けられた複数の関連ユーザを関連ユーザの属性に応じて分類した複数のリスト（以下、「分類リスト」という。）を作成する。また、各ユーザの端末装置１０の表示制御部１１４は、自身に関連付けられた関連ユーザについての分類リストを表示部１８に表示させる。分類リストが表示される分類リスト表示画面７０の一例を図５に示す。

リスト作成部２１８は、例えば、第１ユーザに関連付けられた関連ユーザを、第１ユーザとの相性に応じて分類した複数の分類リストを作成してもよい。なお、１人の関連ユーザが、複数の分類リストに割り当てられていてもよい。また、１人の関連ユーザが、複数の分類リストに割り当てられること（換言すると、重複して含まれること）はないようになっていてもよい。また、各関連ユーザは、必ずいずれかの分類リストに割り当てられるようになっており、いずれの分類リストにも割り当てられていない関連ユーザが存在しないようになっていてもよい。また、いずれの分類リストにも割り当てられない関連ユーザが存在し得るようになっていてもよい。

具体的には、例えば、所定のゲーム（具体的には、ロールプレイングゲームやＦＰＳ等）を想定した場合に、リスト作成部２１８は、関連ユーザを第１ユーザとの相性に応じて分類した分類リストとして、「回復が得意」という属性を有する関連ユーザをまとめた分類リスト（図５（ａ）参照）と、「攻撃が得意」という属性を有する関連ユーザをまとめた分類リスト（図５（ｂ）参照）とを作成してもよい。ここで、回復が得意か、攻撃が得意かは、例えば、各関連ユーザの使用するキャラクタの属性（例えば職業）に基づいて判断してもよく、各関連ユーザの所有するアイテム等に基づいて判断してもよい。例えば、使用するキャラクタの職業が「回復系魔法使い」、「衛生兵」などの関連ユーザを、回復が得意な関連ユーザの分類リストに含めてもよい。また、例えば、使用するキャラクタの職業が「攻撃系魔法使い」、「剣士」などの関連ユーザを、攻撃が得意な関連ユーザの分類リストに含めてもよい。ここで、使用するキャラクタとは、例えば、そのユーザがもっとも頻繁に（換言すると多く）使用しているキャラクタであってもよく、メインで使用するキャラクタを各ユーザが選択可能なゲーム等においてメインで使用するキャラクタとして設定されているキャラクタであってもよく、よく使用するキャラクタを各ユーザがお気に入りとして登録可能なゲームに等においてお気に入りとして登録されているキャラクタであってもよく、使用回数が所定回数を超えているキャラクタであってもよく、そのキャラクタを使用しての勝利回数が所定回数を越えているキャラクタ等であってもよい。また、例えば、所有する回復アイテムの数が所定個数以上の関連ユーザを、回復が得意な関連ユーザの分類リストに含めてもよい。また、例えば、ゲーム内における最強の銃など、他のユーザが所有する武器（換言するとゲーム内に存在する他の武器）に比べて攻撃性能の高い武器を所有する関連ユーザを、攻撃が得意な関連ユーザの分類リストに含めてもよい。

換言すると、リスト作成部２１８は、関連ユーザを第１ユーザとの相性に応じて分類した分類リストとして、関連ユーザを関連ユーザの使用するキャラクタの属性に応じて分類した分類リストを作成してもよい。リスト作成部２１８は、例えば、上述のようにキャラクタの職業等によって分類した分類リストを作成してもよく、キャラクタのランク等によって分類した分類リストを作成してもよい。また、リスト作成部２１８は、例えば、ユーザが使用するキャラクタと被らないキャラクタを使用する関連ユーザをまとめた分類リスト等を作成してもよい。このような、キャラクタの属性に応じて分類した分類リスト等は、第１ユーザが一緒にプレイをしやすい関連ユーザ（例えば、第１ユーザが一緒にプレイしやすい属性のキャラクタを有する関連ユーザや、第１ユーザが一緒にプレイしやすいランク帯の関連ユーザ等）や、一緒にプレイしにくい関連ユーザを探しやすくなるものであり、第１ユーザとの相性に応じて分類した分類リストといえる。

また、リスト作成部２１８は、関連ユーザを第１ユーザとの相性に応じて分類した分類リストとして、第１ユーザと各関連ユーザとの過去のプレイ履歴に基づいて判断される第１ユーザとの相性に応じた分類リストを作成してもよい。具体的には、例えば、所定のゲーム（具体的には、所定の目的の達成を目指すゲーム（例えば対戦ゲーム）等）を想定した場合に、リスト作成部２１８は、過去に関連ユーザと第１ユーザとが一緒にプレイ（ここで、一緒にとは、仲間としてプレイした場合および敵としてプレイをした場合のどちらであってもよい。）して所定の目的を達成した回数または確率（換言すると、対戦ゲームにおける勝率等）に応じて関連ユーザを分類した分類リストを作成してもよい。また、リスト作成部２１８は、例えば、第１ユーザと関連ユーザとの一方が他方に対して高評価のリアクションをした回数（例えば、いわゆる「いいね」の数など）に応じて関連ユーザを分類した分類リストを作成してもよい。また、リスト作成部２１８は、例えば、第１ユーザと関連ユーザとの一方が他方に対して利となる行為を行った回数に応じて関連ユーザを分類した分類リストを作成してもよい。

また、例えば、リスト作成部２１８は、関連ユーザを第１ユーザとの相性に応じて分類した分類リストとして、関連ユーザを各ステージ毎の相性で分類した分類リストを作成してもよい。具体的には、例えば、ＦＰＳにおいて第１ステージと第２ステージとを含む複数のステージ（換言するとマップ）が用意されている場合に、リスト作成部２１８は、第１ステージとの相性が良い関連ユーザをまとめた分類リストと、第２ステージとの相性が良い関連ユーザをまとめた分類リストと、を作成してもよい。ここで、各関連ユーザの各ステージとの相性は、例えば、各関連ユーザの各ステージでの過去の対戦での勝率（例えば、勝率７割以上だと相性が良い、など。）、勝利回数（例えば、累計勝利回数が１００回に達していれば相性が良い、など。）あるいは前回の試合で優れた成績を収めたか否か（例えば、その試合で勝利していれば相性がよい、など。）に基づいて判断してもよい。

また、リスト作成部２１８は、例えば、第１ユーザに関連付けられた関連ユーザを、一緒にプレイをする頻度に応じて分類した複数の分類リストを作成してもよい。具体的には、リスト作成部２１８は、例えば、関連ユーザを所定期間内に一緒にプレイをした回数に応じて分類した複数の分類リストを作成してもよい。

また、リスト作成部２１８は、例えば、第１ユーザに関連付けられた関連ユーザを、関連ユーザに付された経緯情報５１に応じて分類した複数の分類リストを作成してもよい。具体的には、リスト作成部２１８は、例えば、関連ユーザを、関連ユーザに付されたタグ６１で分類した複数の分類リストを作成してもよい。

また、リスト作成部２１８は、例えば、第１ユーザに関連付けられた関連ユーザを、サービス内での関連ユーザの行為に基づく属性に応じて分類した複数の分類リストを作成してもよい。具体的には、リスト作成部２１８は、例えば、第１ユーザに関連付けられた関連ユーザを、第１ユーザと一緒に利用したコンテンツ（例えば、ゲーム）中の関連ユーザの行為に基づく属性に応じて分類した複数の分類リストを作成してもよい。なお、行為に基づく属性とは、行為の結果に関する属性を含む。具体的には、リスト作成部２１８は、例えば、関連ユーザを、関連ユーザが行った行為（例えば、第１ユーザを回復してくれた、アシスト攻撃してくれた、アイテムをくれた、敵キャラクタを倒した）の種類、特定の行為を行った回数、行為の結果としての特定の結果（例えば、試合で勝利したなど）を得た（換言すると、達成した）回数、得た結果の種類、または特定の結果を得る確率（例えば、勝率など）などに応じて分類した複数の分類リストを作成してもよい。また、リスト作成部２１８は、第１ユーザに関連付けられた関連ユーザを、サービス内での関連ユーザの行為であって、第１ユーザの利となる行為に基づく属性に応じて分類した複数の分類リストを作成してもよい。具体的には、リスト作成部２１８は、例えば、関連ユーザを、関連ユーザが行った第１ユーザの利となる行為の種類、利となる特定の行為を行った回数、利となる行為の結果としての特定の結果を得た回数、利となる行為により得られた結果の種類などに応じて分類した複数の分類リストを作成してもよい。

リスト作成部２１８が作成した複数の分類リストは、分類リスト記憶部としてのサーバ２０の記憶部２２０に記憶される。また、記憶部２２０に記憶された各分類リストは、所定のタイミングで第１ユーザに提示可能（所定のタイミングで第１ユーザの端末装置１０に表示させることが可能）となっている。

なお、各分類リストに含める関連ユーザの条件は、各ユーザが、自身の端末装置１０から設定可能となっていてもよい。換言すると、関連ユーザをどのように分類し、どのような分類リストを作成するかは、各ユーザが、自身の端末装置１０から設定可能となっていてもよい。

また、上述のように、関連付け部２１６は、第１ユーザと所定の体験を共有する他のユーザを第１ユーザに自動で関連付けるが、リスト作成部２１８は、このように自動で関連付けられた関連ユーザを、当該関連ユーザの属性に応じた分類リストに自動的に振り分けてもよい。また、このような自動で関連付けられた関連ユーザを、どの分類リストに振り分けるかは、各ユーザが、自身の端末装置１０から手動で選択可能となっていてもよい。

また、関連付け部２１６は、第１ユーザと所定の体験を共有する他のユーザであって、サービス内において第１ユーザと所定の関係性を有する他のユーザを、第１ユーザに自動で関連付けるが、ここで所定の関係性は、「いずれかの分類リストに該当する関係性」であってもよい。すなわち、例えば、第１ユーザの分類リストとして、ＦＰＳにおける第１ステージとの相性が良い関連ユーザの分類リストが用意されている場合に、第１ユーザと同じ試合に参加したユーザのうち、第１ステージとの相性が良いユーザを、第１ユーザのフレンド等として自動で登録するなどしてもよい。換言すると、フレンドの分類として複数の分類が記憶部２２０に記憶されていることとした場合に、関連付け部２１６は、当該複数の分類のいずれかに該当するユーザを自動で関連付けることとしてもよい。

なお、リスト作成部２１８は、複数の分類リストを作成し、記憶部２２０に記憶させるが、当該複数の分類リストは、複数の関連ユーザを関連ユーザの属性に応じて分類したものでなくてもよい。例えば、リスト作成部２１８は、第１ユーザに関連付けられた複数の関連ユーザを、単に複数のリストに分類した分類リストを作成してもよい。また、各分類リストにどの関連ユーザを含めるかは、第１ユーザが自身の端末装置１０で選択可能となっていてもよい。換言すると、リスト作成部２１８は、ユーザの操作に基づいて、各分類リストに含める関連ユーザを決定してもよい。さらに換言すると、記憶部２２０には、ユーザの操作に基づいて作成された複数の分類リストが記憶可能になっていてもよい。

表示部１８における分類リストの表示は、例えば、以下のようにしてもよい。すなわち、例えば、図５に示すように、表示部１８に表示される、分類リストを表示する分類リスト表示画面７０においては、複数の分類リストの中から表示させる分類リストを選択する操作を受け付けるオブジェクト（例えばタブ７１）が表示されてもよい。そして、表示制御部１１４は、ユーザによる当該オブジェクトに対する入力操作により選択された分類リストを表示部１８に表示させてもよい。なお、分類リストの表示にあたり必要となる分類リストの情報は、例えば、分類リスト表示画面７０の表示開始時等に、端末装置１０からの要求に基づいてサーバ２０から端末装置１０に送られてもよく、表示させる分類リストを選択するユーザの入力操作に基づいて端末装置１０からサーバ２０へ要求し、サーバ２０から端末装置１０に送られてもよい。なお、複数の分類リストは端末装置１０の記憶部１２０に記憶されており、表示制御部１１４は、記憶部１２０に記憶された分類リストを表示部１８に表示させることとしてもよい。また、端末装置１０の制御部１１０がリスト作成部２１８を備えてもよい。

なお、以上のように、本実施形態では、リスト作成部２１８が複数の分類リストを記憶部に記憶させておき、記憶部に記憶された当該複数の分類リストのうちの各分類リストが端末装置１０で表示されるようになっている。すなわち、本実施形態に係る構成は、ユーザに関連付けられた複数の関連ユーザを、当該ユーザが入力した所定の検索条件に基づいて絞り込んだ結果を表示するだけのものや、当該複数の関連ユーザを、当該ユーザが入力した所定の条件に基づいて並べ替えた結果を表示するだけのものとは異なり、複数の分類リストが、関連ユーザのリストの表示がされるよりも前の時点において予め作成され記憶される構成となっている。

また、表示制御部１１４は、分類リストを表示部１８に表示させる場合に、ユーザの選択に基づいて決まるサービス内の所定のシチュエーションに適した分類リストを優先的に表示させてもよい。なお、優先的にとは、所定のシチュエーションに適した分類リストのみが表示されるものであってもよく、所定のシチュエーションに適した分類リストの表示上の優先順位が高いもの（例えば、所定のシチュエーションに適した分類リストが初めに表示され、表示させる分類リストを変更する入力操作（例えば上述のタブを選択する操作）に基づいて他の分類リストが表示されるものや、所定のシチュエーションに適した分類リストが他の分類リストに比べて大きく表示されるものなど）であってもよい。ここでは、具体例として、図６（ａ）に示すように、ＦＰＳにおいて、第１ステージおよび第２ステージ等の各種ステージ（換言するとマップ）を選択することができるステージ選択画面７５が表示部１８に表示されている場合を例に説明する。なお、ステージ選択画面７５は、例えば、ステージを選択することで、そのステージでの対戦が開始される画面であってもよく、ステージを選択することで、そのステージについての情報を確認することができる画面であってもよい。ステージ選択画面７５において、第１ステージを選択する入力操作がされた場合、表示制御部１１４は、図６（ｂ）に示すように、第１ステージとの相性が良い関連ユーザの分類リストが表示される分類リスト表示画面７０を表示部１８に表示させる。一方、ステージ選択画面７５において、第２ステージを選択する入力操作がされた場合、表示制御部１１４は、第２ステージとの相性が良い関連ユーザの分類リストが表示される分類リスト表示画面７０を表示部１８に表示させる。すなわち、表示制御部１１４は、複数の分類リストのうち、ユーザの選択に基づいて決まる所定のシチュエーション（換言するとユーザがプレイしようとするステージ）に適した属性を有する関連ユーザの分類リストを表示部１８に表示させる。なお、上述のように、ステージ選択画面７５は、ステージを選択することで、そのステージでの対戦が開始される画面であってもよい。そして、例えば、ステージ選択画面７５において、ステージを選択する入力操作がされ、表示された分類リストの中から、１または複数の関連ユーザを選択する操作がされると、選択したユーザの端末装置１０から、選択された関連ユーザの端末装置１０へ、サーバ２０を介してプレイへの参加に関する招待が送られ、当該関連ユーザが当該招待を承諾する操作を行うことにより、当該ステージでの両者が参加してのプレイが開始されるようになっていてもよい。

なお、ユーザの選択に基づいて決まるシチュエーションは、例えば、ユーザが参加しようとするイベント等であってもよい。例えば、ユーザが参加しようとするライブを選択する入力操作を行った場合に、表示制御部１１４は、当該ライブに一緒に参加するのに適した属性を有する関連ユーザの分類リスト（例えば、参加したイベントの履歴から当該ライブに興味を抱く可能性が高いと判断される関連ユーザの分類リストなど）を優先的に表示させてもよい。

なお、ユーザの選択に基づいて決まるシチュエーションは、例えば、ユーザの属性等に関するものであってもよい。具体的には、例えば、ロールプレイングゲームで、ユーザが使用するキャラクタとして回復の得意なキャラクタを選択している場合において、ユーザが関連ユーザのリストを表示させるための所定の入力操作を行った場合に、表示制御部１１４は、回復の得意なキャラクタでプレイするというシチュエーションに適した属性を有する関連ユーザの分類リストとして、攻撃が得意なキャラクタを使用する関連ユーザの分類リスト（換言すると、ユーザの属性を補完する属性を有する関連ユーザの分類リスト）を優先的に表示させてもよい。

なお、ここでは、リスト作成部２１８は、予め複数の分類リストを作成して記憶部に記憶させておき、表示制御部１１４は、表示部１８に分類リストを表示させる際に、当該複数の分類リストの中から選択される分類リストを表示させることとして説明した。ただし、リスト作成部２１８は、表示部１８への表示を行う際に分類リストを作成するものであってもよい。具体的には、例えば、図６（ａ）に示すステージ選択画面７５において、第１ステージを選択する入力操作がされた場合に、リスト作成部２１８が第１ステージとの相性が良い関連ユーザの分類リスト（換言するとユーザの選択に基づいて決まるシチュエーションに適した属性を有する関連ユーザのリスト）を作成し、表示制御部１１４が当該分類リストを表示部１８に表示させるなどしてもよい。

次に図７～１１を参照しながら、システム１が実行する処理の流れについて説明する。なお、ここでは、ゲーム（具体的には、ＦＰＳ）に本実施形態に係るシステム１を適用した場合を例に説明する。

（関連付けに係る処理）
システム１を利用する所定のユーザとしての第１ユーザに、第２ユーザを自動で関連付ける処理について、図７を参照しながら説明する。

まず、サーバ２０の関連付け部２１６は、第１ユーザと体験を共有しているユーザを特定する（ステップＳ１０１）。具体的には、関連付け部２１６は、例えば、第１ユーザと同じ試合に参加しているユーザを特定する。

次いで、関連付け部２１６は、第１ユーザと同じ試合に参加しているユーザの中に、第１ユーザに自動で関連付けるための登録条件を満たすユーザがいるか否かを判定する（ステップＳ１０２）。ここでは、当該登録条件は、第１ユーザが自身の端末装置１０から予め入力し、登録条件記憶部としてのサーバ２０の記憶部２２０に記憶されているものとする。また、ここでは、第１ユーザが入力し設定した当該登録条件は、「１試合の間に３回以上蘇生してくれた」というものであることとする。

関連付け部２１６は、第１ユーザと同じ試合に参加しているユーザの中に、当該登録条件を満たすユーザがいない場合（ステップＳ１０２でＮＯ）、第１ユーザに対して他のユーザを自動で関連付ける処理を行わない。具体的には、１試合が終了するまでの間に第１ユーザのことを３回以上蘇生してくれたユーザである第２ユーザがいない場合、関連付け部２１６は、第１ユーザに対して他のユーザを自動で関連付ける処理を行わない。

一方、関連付け部２１６は、第１ユーザと同じ試合に参加しているユーザの中に、当該登録条件を満たすユーザがいる場合（ステップＳ１０２でＹＥＳ）、第１ユーザに対して他のユーザを関連付けるための所定の処理を自動で行う。具体的には、１試合が終了するまでの間に第１ユーザのことを３回以上蘇生してくれたユーザである第２ユーザがいる場合（ステップＳ１０２でＹＥＳ）、関連付け部２１６は、第２ユーザに対して、第１ユーザからのフレンド登録の申請を行う（ステップＳ１０３）。このとき、関連付け部２１６は、第１ユーザによる入力操作を要さずに当該申請を自動で行う。具体的には、関連付け部２１６は、第２ユーザの端末装置１０に対して、フレンド登録の申請に係るデータを送信する（ステップＳ１０３）。第２ユーザの端末装置１０の送受信部１１２が当該データを受信すると、第２ユーザの端末装置１０の表示制御部１１４は、第１ユーザからのフレンド登録の申請に対する回答を促す画面（以下、「承諾画面」という。）を表示部１８に表示させる（ステップＳ１０４）。承諾画面においては、第１ユーザからのフレンド登録の申請を承諾するか否か、第２ユーザに確認する表示がされる。換言すると、承諾画面の表示中においては、第２ユーザの端末装置１０の操作受付部１１１は、フレンド登録の申請に対する回答に係る操作としての、フレンド登録の申請を承諾する操作および拒否する操作を受け付ける。

第２ユーザの端末装置１０において、フレンド登録の申請を承諾する操作または拒否する操作が受け付けられると、フレンド登録の申請を承諾するか否かを示すデータ（換言すると、フレンド登録の申請に対する回答）が端末装置１０の送受信部１１２から関連付け部２１６に送られる（ステップＳ１０５）。

関連付け部２１６は、第２ユーザの端末装置１０から送られる、フレンド登録の申請を承諾するか否かを示すデータを受け取ると、当該データに基づいて、フレンド登録の申請が承諾されたか否かを判定する（ステップＳ１０６）。すなわち、第２ユーザが、フレンド登録の申請を承諾する操作を行った場合には、フレンド登録の申請が承諾されたと判定する（ステップＳ１０６でＹＥＳ）。一方、第２ユーザが、フレンド登録の申請を拒否する操作を行った場合には、フレンド登録の申請が拒否されたと判定する（ステップＳ１０６でＮＯ）。フレンド登録の申請が拒否されたと判定した場合（ステップＳ１０６でＮＯ）、関連付け部２１６は、第１ユーザに対する第２ユーザの関連付けを行わない。

フレンド登録の申請が承諾されたと判定した場合（ステップＳ１０６でＹＥＳ）、関連付け部２１６は、第１ユーザと第２ユーザとを互いに関連付ける（ステップＳ１０７）。換言すると、フレンド登録の申請が承諾されたと判定した場合、関連付け部２１６は、第２ユーザを第１ユーザのフレンドとして登録する。さらに換言すると、フレンド登録の申請が承諾されたと判定した場合、関連付け部２１６は、第２ユーザが第１ユーザのフレンドであることを示す情報を記憶部２２０に記憶させる。

また、関連付け部２１６は、第１ユーザと第２ユーザとを互いに関連付けると、第１ユーザの端末装置１０に対して、第２ユーザを第１ユーザのフレンドとして登録したことを示すデータを送信する（ステップＳ１０８）。換言すると、サーバ２０は、第２ユーザを第１ユーザのフレンドとして登録したことを、第１ユーザの端末装置１０に対して知らせる。第１ユーザの端末装置１０の送受信部１１２が当該データを受信すると、第１ユーザの端末装置１０の表示制御部１１４は、第２ユーザを第１ユーザのフレンドとして登録したことを第１ユーザに対して報知する登録報知画面を表示部１８に表示させる（ステップＳ１０９）。

なお、第２ユーザの端末装置１０では、他のユーザからのフレンド登録の申請があった場合に、当該申請を受信するか否か（換言すると、承諾画面を表示させるか否か）を予め設定しておくことが可能となっていてもよい。また、当該申請の受信を拒否する設定がされている場合、関連付け部２１６は、フレンド登録の申請が拒否されたと判定（ステップＳ１０６でＮＯ）してもよい。また、例えば、第２ユーザの端末装置１０では、フレンドになりたいユーザの条件を規定するホワイトリストの設定、あるいはフレンドになりたくないユーザの条件を規定するブラックリストの設定等が可能となっていてもよい。そして、ホワイトリストに設定されている条件を満たすユーザからの申請については受信をするようにしてもよい。また、ブラックリストに設定されている条件を満たすユーザからの申請については受信を拒否するようにしてもよい。

なお、ここでは、関連付け部２１６は、登録条件を満たす場合にフレンド登録の申請を行うものとして説明したが、フレンド申請に代えてフォローの申請をしてもよい。また、例えば、登録条件を満たす場合に、申請を行わずに、フレンド登録あるいはフォローを自動で行ってもよい。換言すると、例えば、ステップＳ１０２でＹＥＳの場合に、ステップＳ１０３～ステップＳ１０６の処理を介さずに、ステップＳ１０７の処理を行う構成等としてもよい。

（関連付けの解除に係る処理）
次に、第１ユーザに関連付けられた関連ユーザについて、第１ユーザへの関連付けを自動で解除する処理について、図８を参照しながら説明する。

まず、サーバ２０の解除部２１７は、第１ユーザに関連付けられた関連ユーザの中に、解除条件を満たす関連ユーザがいるか否かを判定する（ステップＳ２０１）。ここでは、当該解除条件は、第１ユーザが自身の端末装置１０から予め入力し、解除条件記憶部としてのサーバ２０の記憶部２２０に記憶されているものとする。

解除条件を満たす関連ユーザがいる場合（ステップＳ２０１でＹＥＳ）、解除部２１７は、当該関連ユーザを解除ユーザとして特定し、特定した解除ユーザを知らせるデータを第１ユーザの端末装置１０に送信する（ステップＳ２０２）。第１ユーザの端末装置１０の送受信部１１２が当該データを受信すると、第１ユーザの端末装置１０の表示制御部１１４は、解除ユーザとの関連付けを解除するか否かについての回答を促す解除確認画面を表示部１８に表示させる（ステップＳ２０３）。解除確認画面の表示中においては、第１ユーザの端末装置１０の操作受付部１１１は、解除ユーザとの関連付けの解除を承諾する操作および拒否する操作を受け付ける。

第１ユーザの端末装置１０において、解除ユーザとの関連付けの解除を承諾する操作または拒否する操作が受け付けられると、解除ユーザとの関連付けの解除を承諾するか否かを示すデータ（換言すると、解除ユーザとの関連付けの解除についての回答）が端末装置１０の送受信部１１２から解除部２１７に送られる（ステップＳ２０４）。

解除部２１７は、第１ユーザの端末装置１０から送られる、解除ユーザとの関連付けの解除を承諾するか否かを示すデータを受け取ると、当該データに基づいて、解除ユーザとの関連付けの解除が承諾されたか否かを判定する（ステップＳ２０５）。すなわち、第１ユーザが、解除を承諾する操作を行った場合には、解除ユーザとの関連付けの解除が承諾されたと判定する（ステップＳ２０５でＹＥＳ）。一方、第１ユーザが、解除を拒否する操作を行った場合には、解除ユーザとの関連付けの解除が拒否されたと判定する（ステップＳ２０５でＮＯ）。解除が拒否されたと判定した場合（ステップＳ２０５でＮＯ）、解除部２１７は、解除ユーザの第１ユーザへの関連付けを解除しない。

解除ユーザとの関連付けの解除が承諾されたと判定した場合（ステップＳ２０５でＹＥＳ）、解除部２１７は、第１ユーザへの解除ユーザの関連付けを解除する（ステップＳ２０６）。

（経緯情報の入力に係る処理）
次に、第１ユーザに関連付けられた関連ユーザとしての第２ユーザについての経緯情報５１を入力する処理について、図９を参照しながら説明する。

まず、経緯情報管理部２１９は、経緯情報入力画面６０に表示させるタグ６１を決定する（ステップＳ３０１）。ここでは、経緯情報管理部２１９は、第１ユーザに第２ユーザを関連付けるきっかけとなった試合（換言すると、第２ユーザが第１ユーザが設定した登録条件（ここでは当該登録条件は「１試合の間に３回以上蘇生してくれた」とする。）を満たした試合）での出来事に基づいて、経緯情報入力画面６０に表示させるタグ６１を決定する。具体的には、例えば、経緯情報管理部２１９は、この試合において、第２ユーザのキャラクタが第１ユーザのキャラクタを蘇生してくれたことに基づいて、「蘇生してくれた」というタグ６１を表示させるタグ６１に決定する。また、例えば、この試合において、第２ユーザのキャラクタが第１ユーザのキャラクタが攻撃している相手を一緒に攻撃してくれた場合、「アシスト攻撃してくれた」というタグ６１を表示させるタグ６１に決定する。また、例えば、この試合において第１ユーザと第２ユーザとが共闘して勝利した場合、「共闘した」というタグ６１および「勝利した」というタグ６１を表示させるタグ６１に決定する。なお、ステップＳ３０１の処理については、試合において起こり得る出来事と、表示させるタグ６１と、の対応関係を示すテーブルが記憶部２２０に記憶されており、経緯情報管理部２１９は、当該テーブルを用いて、試合で実際に起こった出来事に対応するタグ６１を抽出し、経緯情報入力画面６０に表示させるタグ６１として決定することとしてもよい。

次いで、経緯情報管理部２１９は、表示させるタグ６１についての情報を含む、経緯情報入力画面６０の表示に必要な情報を第１ユーザの端末装置１０に送信する（ステップＳ３０２）。

第１ユーザの端末装置１０の送受信部１１２が当該情報を受信すると、第１ユーザの端末装置１０の表示制御部１１４は、経緯情報入力画面６０を表示させる（ステップＳ３０３）。この経緯情報入力画面６０には、ステップＳ３０１において表示させることが決定されたタグ６１が表示される。

次いで、第１ユーザの端末装置１０の操作受付部１１１は、経緯情報入力画面６０に表示されるタグ６１のうち、第２ユーザについての経緯情報５１として付すタグ６１を選択する入力操作を受け付ける（ステップＳ３０４）。換言すると経緯情報入力画面６０の表示中は、経緯情報５１を入力する入力操作が受け付けられる。

第１ユーザの端末装置１０において、タグ６１を選択する入力操作が受け付けられると、選択されたタグ６１を示すデータ（換言すると入力された経緯情報に関するデータ）が端末装置１０の送受信部１１２から関連ユーザ管理部２１５に送られる（ステップＳ３０５）。

経緯情報管理部２１９は、選択されたタグ６１を示すデータを受信すると、選択されたタグ６１を、第２ユーザの経緯情報５１として第２ユーザに付して記憶部２２０に記憶させる（ステップＳ３０６）。換言すると、経緯情報管理部２１９は、端末装置１０での入力操作に基づいて、第２ユーザの経緯情報５１を登録する。

なお、ここで、選択されるタグ６１は１つであってもよく、複数であってもよい。

（分類リストの表示に係る処理）
次に、第１ユーザに関連付けられた複数の関連ユーザを、関連ユーザの属性に応じて分類した分類リストの作成および表示に係る処理について、図１０を参照しながら説明する。

まず、リスト作成部２１８は、第１ユーザに関連付けられている複数の関連ユーザを、関連ユーザの属性毎に分類し、分類リストを作成する（ステップＳ４０１）。具体的には、リスト作成部２１８は、各関連ユーザのユーザ情報２２３を参照して関連ユーザを分類し、分類リストを作成する。リスト作成部２１８は、例えば、使用するキャラクタが攻撃が得意なキャラクタである関連ユーザを、攻撃が得意な関連ユーザに分類し、攻撃が得意な関連ユーザをまとめた分類リストを作成する。また、リスト作成部２１８は、例えば、使用するキャラクタが回復が得意なキャラクタである関連ユーザを、回復が得意な関連ユーザに分類し、回復が得意な関連ユーザをまとめた分類リストを作成する。

また、リスト作成部２１８は、作成した複数の分類リストを分類リスト記憶部としての記憶部２２０に記憶させる（ステップＳ４０２）。

分類リストの表示にあたっては、まず、第１ユーザの端末装置１０は、分類リストの送信をサーバ２０に要求する（ステップＳ４０３）。また、関連ユーザ管理部２１５は、当該要求に基づいて、分類リストを第１ユーザの端末装置１０に送信する（ステップＳ４０４）。ここでは、攻撃が得意な関連ユーザの分類リストと、回復が得意な関連ユーザの分類リストが送信されるものとする。

次いで、第１ユーザの端末装置１０の表示制御部１１４は、表示させる分類リストの選択（例えば、攻撃が得意な関連ユーザの分類リストと、回復が得意な関連ユーザの分類リストとのどちらを表示させるかの選択）を促す画面（例えば、図５に示す分類リスト表示画面７０）を表示部１８に表示させる（ステップＳ４０５）。また、当該画面の表示中においては、操作受付部１１１は、表示させる分類リストを選択する入力操作を受け付ける。

表示させる分類リストを選択する入力操作がされると、表示制御部１１４は、選択された分類リストを表示部１８に表示させる（ステップＳ４０６）。

なお、リスト作成部２１８は、端末装置１０が有していてもよい。また、分類リストを記憶する分類リスト記憶部（例えば、記憶部１２０）は端末装置１０が有していてもよい。この場合、表示制御部１１４は、端末装置１０に記憶されている複数の分類リストのうち、ユーザが選択した分類リスト（ステップＳ４０５，Ｓ４０６）を表示部１８に表示させてもよい。

（分類リストの表示に係る処理の変形例）
次に、第１ユーザに関連付けられた複数の関連ユーザを、関連ユーザの属性に応じて分類した分類リストの作成および表示に係る処理の変形例について、図１１を参照しながら説明する。

まず、第１ユーザの端末装置１０の表示制御部１１４は、シチュエーション（例えば、第１ユーザが行おうとするゲームのシチュエーション）の選択を促す画面を表示部１８に表示させる（ステップＳ５０１）。また、当該画面の表示中においては、操作受付部１１１は、シチュエーションを選択する入力操作を受け付ける。具体的には、操作受付部１１１は、当該シチュエーションとしてのステージ（換言するとマップ）を選択する入力操作を受け付ける。

次いで、第１ユーザの端末装置１０は、選択されたシチュエーション（具体的にはステージ）に適した分類リストの送信をサーバ２０に要求する（ステップＳ５０２）。また、関連ユーザ管理部２１５は、当該要求に基づいて、選択されたシチュエーションに適した属性を有する関連ユーザの分類リストを第１ユーザの端末装置１０に送信する（ステップＳ５０３）。具体的には、例えば、第１ユーザが、第１ステージおよび第２ステージを含む複数のステージの中から第１ステージを選択する入力操作を行った場合、関連ユーザ管理部２１５は、第１ユーザに関連付けられた複数の関連ユーザのうち、第１ステージでの過去の対戦での勝率が高い関連ユーザをまとめた分類リストを第１ユーザの端末装置１０に送信する。なお、ここで関連ユーザ管理部２１５から端末装置１０に送信される分類リストは、当該要求に基づいてリスト作成部２１８が作成するものであってもよく、予めリスト作成部２１８が作成し記憶部２２０に記憶されている複数の分類リストの中から当該要求に基づいて抽出されるものであってもよい。なお、リスト作成部２１８は、端末装置１０が有していてもよい。また、分類リストを記憶する分類リスト記憶部（例えば、記憶部１２０）は端末装置１０が有していてもよい。

次いで、第１ユーザの端末装置１０の表示制御部１１４は、サーバ２０から送信された、選択されたシチュエーションに適した属性を有する関連ユーザの分類リストを表示部１８に表示させる（ステップＳ５０４）。

なお、本発明は、上述した実施形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変形して実施できる。本発明はその発明の範囲内において、各構成要素の自由な組み合わせ、任意の構成要素の変形、または任意の構成要素の省略等が可能である。また、本明細書において説明した処理の流れはあくまで一例であり、各処理の順序や構成は異なるものであってもよい。

＜付記＞
以上の実施形態で説明した事項は、以下の付記のようにも記載され得る。

（付記１）
コンピュータを、
所定のサービス内で第１ユーザと所定の体験を共有決定後、共有中、または共有後の第２ユーザに対して、前記第２ユーザの前記第１ユーザへの関連付けに係る申請を自動的に行う申請手段（例えば、関連付け部２１６）として機能させる
プログラム。
このような構成によれば、ゲーム等の所定のサービスにおいて他のユーザをフレンドとして登録する際やフォローする際等に通常必要となる、これらについて相手方へ申請する操作が不要となる。したがって、ユーザ間の関連付けが行いやすくなる。また、相手方において当該申請を拒否することも可能となるので、不要なフレンドの数が増加してしまうこと等を防止できる。

（付記２）
前記第２ユーザは、前記所定のサービス内の所定のコンテンツを前記第１ユーザと一緒に利用すること決定後、利用中、または利用後のユーザである
付記１に記載のプログラム。
このような構成によれば、一緒にコンテンツを利用したユーザとの間での関連付けが容易となる。

（付記３）
前記コンピュータをさらに、
前記第２ユーザによる前記申請を承諾する操作に基づいて、前記第１ユーザへの前記第２ユーザの関連付けを行う関連付け手段（例えば、関連付け部２１６）として機能させる
付記１に記載のプログラム。

（付記４）
前記第２ユーザは、前記所定のサービス内で前記第１ユーザと所定の関係性を有するユーザである
付記１～３のいずれか１つに記載のプログラム。
このような構成によれば、関連付けに係る申請を自動的に行う相手を、所定の体験を共有するユーザのうち、所定の関係性を有するユーザに限定することが可能となる。

（付記５）
前記所定の関係性は、前記第１ユーザが設定した、前記申請を自動的に行う相手としての条件を満たす関係性である
付記４に記載のプログラム。
このような構成によれば、各ユーザは、関連付けに係る申請を自動的に行う相手の条件を設定することが可能となる。

（付記６）
所定のサービス内で第１ユーザと所定の体験を共有決定後、共有中、または共有後の第２ユーザに対して、前記第２ユーザの前記第１ユーザへの関連付けに係る申請を自動的に行う申請手段（例えば、関連付け部２１６）を備える
情報処理装置。
このような構成によれば、付記１に記載のプログラムと同様の作用効果を奏することができる。

１ システム、１０ 端末装置、１１ プロセッサ、１２ メモリ、１３ ストレージ、１６ タッチスクリーン、１７ 入力部、１８ 表示部、２０ サーバ、２１ プロセッサ、２２ メモリ、２３ ストレージ、５０ 関連ユーザリスト表示画面、５１ 経緯情報、６０ 経緯情報入力画面、６１ タグ、７０ 分類リスト表示画面、７５ ステージ選択画面、１１０ 制御部、１１１ 操作受付部、１１２ 送受信部、１１３ 進行部、１１４ 表示制御部、１２０ 記憶部、２１０ 制御部、２１１ 送受信部、２１２ サーバ処理部、２１４ 同期処理部、２１５ 関連ユーザ管理部、２１６関連付け部、２１７ 解除部、２１８ リスト作成部、２１９ 経緯情報管理部、２２０ 記憶部

Claims (3)

1. コンピュータを、
   所定のサービス内で第１ユーザと所定の体験を共有決定後、共有中、または共有後の第２ユーザに対して、前記第２ユーザの前記第１ユーザへの関連付けに係る申請を自動的に行う申請手段と、
   前記第２ユーザによる前記申請を承諾する操作に基づいて、前記第１ユーザへの前記第２ユーザの関連付けを行う関連付け手段と、として機能させ、
   前記第２ユーザは、前記所定のサービス内で前記第１ユーザと所定の関係性を有するユーザであり、
   前記所定の関係性は、前記第１ユーザが設定した、前記申請を自動的に行う相手としての条件を満たす関係性である
   プログラム。
2. 前記第２ユーザは、前記所定のサービス内の所定のコンテンツを前記第１ユーザと一緒に利用すること決定後、利用中、または利用後のユーザである
   請求項１に記載のプログラム。
3. 所定のサービス内で第１ユーザと所定の体験を共有決定後、共有中、または共有後の第２ユーザに対して、前記第２ユーザの前記第１ユーザへの関連付けに係る申請を自動的に行う申請手段と、
   前記第２ユーザによる前記申請を承諾する操作に基づいて、前記第１ユーザへの前記第２ユーザの関連付けを行う関連付け手段と、を備え、
   前記第２ユーザは、前記所定のサービス内で前記第１ユーザと所定の関係性を有するユーザであり、
   前記所定の関係性は、前記第１ユーザが設定した、前記申請を自動的に行う相手としての条件を満たす関係性である
   情報処理装置。

Images