IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社コロプラの特許一覧

<>
  • 特許-プログラムおよび情報処理システム 図1
  • 特許-プログラムおよび情報処理システム 図2
  • 特許-プログラムおよび情報処理システム 図3
  • 特許-プログラムおよび情報処理システム 図4
  • 特許-プログラムおよび情報処理システム 図5
  • 特許-プログラムおよび情報処理システム 図6
  • 特許-プログラムおよび情報処理システム 図7
  • 特許-プログラムおよび情報処理システム 図8
  • 特許-プログラムおよび情報処理システム 図9
  • 特許-プログラムおよび情報処理システム 図10
  • 特許-プログラムおよび情報処理システム 図11
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-09-12
(45)【発行日】2024-09-24
(54)【発明の名称】プログラムおよび情報処理システム
(51)【国際特許分類】
   A63F 13/79 20140101AFI20240913BHJP
   A63F 13/69 20140101ALI20240913BHJP
   A63F 13/795 20140101ALI20240913BHJP
【FI】
A63F13/79 500
A63F13/69
A63F13/795
【請求項の数】 5
(21)【出願番号】P 2023093097
(22)【出願日】2023-06-06
(62)【分割の表示】P 2022131726の分割
【原出願日】2022-08-22
(65)【公開番号】P2024029743
(43)【公開日】2024-03-06
【審査請求日】2023-06-06
(73)【特許権者】
【識別番号】509070463
【氏名又は名称】株式会社コロプラ
(74)【代理人】
【識別番号】100104547
【弁理士】
【氏名又は名称】栗林 三男
(74)【代理人】
【識別番号】100206612
【弁理士】
【氏名又は名称】新田 修博
(74)【代理人】
【識別番号】100209749
【弁理士】
【氏名又は名称】栗林 和輝
(74)【代理人】
【識別番号】100217755
【弁理士】
【氏名又は名称】三浦 淳史
(72)【発明者】
【氏名】山崎 聡士
(72)【発明者】
【氏名】中前 秀太
【審査官】岸 智史
(56)【参考文献】
【文献】特開2018-166947(JP,A)
【文献】国際公開第2013/136830(WO,A1)
【文献】特開2017-136346(JP,A)
【文献】特開2013-254305(JP,A)
【文献】特開2018-110626(JP,A)
【文献】特開2022-108559(JP,A)
【文献】特開2010-237970(JP,A)
【文献】特開2019-141350(JP,A)
【文献】特開2016-123756(JP,A)
【文献】特開2014-183953(JP,A)
【文献】特開2014-209321(JP,A)
【文献】[サンブレイク]ハンターコネクトとは?自動招待と使い方[モンハンライズ],GameWith [online],2022年07月27日,https://gamewith.jp/mhrize/article/show/260894,[2023年1月17日検索]
【文献】[モンハンライズ]グッドのやり方、グッドの効果やメリット[サンブレイク],攻略大百科 [online],2021年04月09日,[2024年7月17日検索],<https://gamepedia.jp/mh-rise/archives/16921>
(58)【調査した分野】(Int.Cl.,DB名)
A63F 9/24、13/00-13/98
(57)【特許請求の範囲】
【請求項1】
コンピュータを、
ゲーム内で第1ユーザと同じイベントに参加し特定の条件を満たした第2ユーザに対して、前記第2ユーザの前記第1ユーザへの関連付けに係る申請を自動的に行う申請手段と、
前記第2ユーザによる前記申請を承諾する操作に基づいて、前記第1ユーザへの前記第2ユーザの関連付けを行う関連付け手段と、として機能させ、
前記特定の条件を満たした前記第2ユーザとは、前記第1ユーザにとって前記イベントの進行について利となる所定の行為を前記イベントの進行中に行ったユーザまたは前記イベントの進行に係る行為に基づき前記イベントにおいて所定の結果を残したユーザである
プログラム。
【請求項2】
前記申請手段は、前記イベントの進行中において前記第2ユーザが前記所定の行為を行い前記特定の条件を満たしたタイミングで前記申請を自動的に行う
請求項1に記載のプログラム。
【請求項3】
前記特定の条件を満たした前記第2ユーザとは、前記イベントの進行中において前記所定の行為を複数回行ったユーザである
請求項またはに記載のプログラム。
【請求項4】
前記特定の条件を満たした前記第2ユーザとは、前記イベントにおいて所定の成績を残したユーザである
請求項1に記載のプログラム。
【請求項5】
ゲーム内で第1ユーザと同じイベントに参加し特定の条件を満たした第2ユーザに対して、前記第2ユーザの前記第1ユーザへの関連付けに係る申請を自動的に行う申請手段と、
前記第2ユーザによる前記申請を承諾する操作に基づいて、前記第1ユーザへの前記第2ユーザの関連付けを行う関連付け手段と、を備え、
前記特定の条件を満たした前記第2ユーザとは、前記第1ユーザにとって前記イベントの進行について利となる所定の行為を前記イベントの進行中に行ったユーザまたは前記イベントの進行に係る行為に基づき前記イベントにおいて所定の結果を残したユーザである
情報処理システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、プログラム、および情報処理システムに関する。
【背景技術】
【0002】
従来より、各ユーザが他のユーザをフレンドとして登録可能なゲーム等のサービスが知られている(例えば、特許文献1参照)。
【先行技術文献】
【特許文献】
【0003】
【文献】特開2013-188456号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
ところで、フレンド登録やフォロー等の、ユーザに他のユーザを関連付けることが可能なサービスにおいては、当該関連付けが行いにくいことがあるという問題があった。
【0005】
本発明は、ユーザ間の関連付けの行いやすいサービスを提供することを目的とする。
【課題を解決するための手段】
【0006】
本開示に示す一実施形態によれば、
コンピュータを、
所定のサービス内で第1ユーザと所定の体験を共有決定後、共有中、または共有後の第2ユーザと、前記第1ユーザと、を自動的に互いに関連付ける関連付け手段として機能させる
プログラムが提供される。
【発明の効果】
【0007】
本発明によれば、ユーザ間の関連付けの行いやすいサービスが提供される。
【図面の簡単な説明】
【0008】
図1】システムの概略構成を示す図である。
図2】システムの機能的構成を示すブロック図である。
図3】関連ユーザリスト表示画面の一例を示す図である。
図4】経緯情報入力画面の一例を示す図である。
図5】分類リスト表示画面の一例を示す図である。
図6】分類リストの表示についての一例を示す図である。
図7】ユーザに他のユーザを自動で関連付ける処理の一例を示すフローチャートである。
図8】ユーザへの他のユーザの関連付けを自動で解除する処理の一例を示すフローチャートである。
図9】経緯情報の入力に係る処理の一例を示すフローチャートである。
図10】分類リストの作成および表示に係る処理の一例を示すフローチャートである。
図11】分類リストの作成および表示に係る処理の一例を示すフローチャートである。
【発明を実施するための形態】
【0009】
以下、図面を参照しながら本発明の実施形態について説明する。
【0010】
<システムのハードウェア構成>
図1に示すように、本実施形態のシステム1は、複数の端末装置10と、サーバ20とを備えている。
【0011】
端末装置10とサーバ20とは、ネットワーク2を介して接続される。ネットワーク2は、例えば、インターネット、移動通信システム(例えば、3G、4G、5G、LTE(Long Term Evolution)等)、WiFi(Wireless Fidelity)、ブルートゥース(登録商標)、その他の通信回線、またはこれらの組み合わせ等のいずれによって構成されていてもよい。また、端末装置10とサーバ20との接続は、有線接続であるか無線接続であるかを問わない。
【0012】
サーバ20(換言すると、コンピュータ、情報処理装置)は、例えば、ワークステーションまたはパーソナルコンピュータ等の汎用コンピュータであってもよい。サーバ20は、プロセッサ21と、メモリ22と、ストレージ23と、通信IF(インターフェース)24と、入出力IF25と、を備える。サーバ20が備えるこれらの構成は、通信バスによって互いに接続される。
【0013】
プロセッサ21は、サーバ20全体の動作を制御する。プロセッサ21は、CPU(Central Processing Unit)、MPU(Micro Processing Unit)およびGPU(Graphics Processing Unit)等を含み得る。プロセッサ21は、ストレージ23からプログラムを読み出し、メモリ22に展開する。プロセッサ21は、展開したプログラムを実行する。
【0014】
メモリ22は、主記憶装置である。メモリ22は、例えば、ROM(Read Only Memory)およびRAM(Random Access Memory)等の記憶装置により構成される。メモリ22は、プロセッサ21がストレージ23から読み出したプログラムおよび各種データを一時的に記憶することにより、プロセッサ21に作業領域を提供する。メモリ22は、プロセッサ21がプログラムに従って動作している間に生成した各種データも一時的に記憶する。
【0015】
なお、本実施形態においてプログラムとは、ゲーム等の所定のサービス(換言するとアプリケーション)を端末装置10により実現するプログラムであってもよい。また、当該プログラムは、当該所定のサービスを端末装置10とサーバ20との協働により実現するプログラムであってもよい。なお、端末装置10とサーバ20との協働により実現される所定のサービスは、一例として、端末装置10において起動されたブラウザ上で提供されるサービスであってもよい。また、当該プログラムは、当該所定のサービスを複数の端末装置10の協働により実現するプログラムであってもよい。また、各種データには、例えば、ユーザ情報およびサービス情報などのサービスに関するデータ、および端末装置10とサーバ20との間で送受信される指示や通知が含まれる。
【0016】
ストレージ23は、補助記憶装置である。ストレージ23は、例えば、フラッシュメモリまたはHDD(Hard Disk Drive)等の記憶装置により構成される。ストレージ23には、サービスに関する各種データが格納される。
【0017】
通信IF24は、サーバ20と端末装置10等との間におけるネットワークを介した各種データの送受信を制御する。
【0018】
入出力IF25は、サーバ20がデータの入力を受け付けるためのインターフェースであるとともに、サーバ20がデータを出力するためのインターフェースである。入出力IF25は、例えば、マウス、キーボード等の情報入力機器である入力部と、画像を表示出力する機器である表示部とを含み得る。
【0019】
端末装置10(換言すると、コンピュータ、情報処理装置)は、例えば、スマートフォン、フィーチャーフォン、PDA(Personal Digital Assistant)、タブレット型コンピュータ、パーソナルコンピュータ、ウェアラブル端末、またはゲーム装置等であってもよい。端末装置10は、携帯端末であってもよい。端末装置10は、ユーザがサービスの提供を受ける際(例えばゲームを実行する際)に可搬型の端末であってもよい。
【0020】
端末装置10は、プロセッサ11と、メモリ12と、ストレージ13と、通信IF14と、入出力IF15と、入力部17と、表示部18と、を備える。端末装置10が備えるこれらの構成は、通信バスによって互いに接続される。
【0021】
プロセッサ11は、端末装置10全体の動作を制御する。プロセッサ11は、CPU、MPUおよびGPU等を含み得る。プロセッサ11は、ストレージ13からプログラムを読み出し、メモリ12に展開する。プロセッサ11は、展開したプログラムを実行する。
【0022】
メモリ12は、主記憶装置である。メモリ12は、例えば、ROMおよびRAM等の記憶装置により構成される。メモリ12は、プロセッサ11がストレージ13から読み出したプログラムおよび各種データを一時的に記憶することにより、プロセッサ11に作業領域を提供する。メモリ12は、プロセッサ11がプログラムに従って動作している間に生成した各種データも一時的に記憶する。
【0023】
ストレージ13は、補助記憶装置である。ストレージ13は、例えば、フラッシュメモリまたはHDD等の記憶装置により構成される。ストレージ13には、サービスに関する各種データが格納される。
【0024】
通信IF14は、端末装置10とサーバ20等との間におけるネットワークを介した各種データの送受信を制御する。
【0025】
入出力IF15は、端末装置10がデータの入力を受け付けるためのインターフェースであるとともに、端末装置10がデータを出力するためのインターフェースである。入出力IF15は、例えばUSB(Universal Serial Bus)等を介してデータの入出力を行うこととしてもよい。入出力IF15は、入力部17または表示部18等を含み得る。
【0026】
入力部17は、ユーザによる入力を受け付ける。入力部17は、例えば、タッチパッド等のポインティングデバイスであってもよい。表示部18は、画像を表示する。表示部18は、例えば、液晶ディスプレイまたは有機EL(Electro-Luminescence)ディスプレイ等であってもよい。端末装置10は、例えば、入力部17と表示部18とを組み合わせた電子部品であるタッチスクリーン16を備える。
【0027】
入力部17は、ユーザの操作(例えば、タッチ操作、タップ操作、スライド操作、スワイプ操作、フリック操作、ピンチイン操作およびピンチアウト操作等)により入力面に対して入力された位置を検知し、検知した位置を示す情報を入力信号として送信する機能を有する。入力部17としてのタッチパネルは、静電容量方式または抵抗膜方式等を採用することができるが、他の方式であってもよい。
【0028】
なお、入力部17は、例えば、キーボード、各種物理ボタン、各種センサ(例えば、加速度センサまたは角速度センサ等)、操作スティック、カメラ、またはマイク等であってもよい。また、表示部18は、例えば、プロジェクタ等であってもよい。
【0029】
<システムの機能的構成>
図2は、サーバ20および端末装置10の機能的構成を示すブロック図である。本実施形態におけるサーバ20は、例えば、サービスを提供するために必要な各種データおよびプログラムを各端末装置10に提供する機能、各端末装置10からサービスに関するデータを収集して管理する機能、ならびに複数の端末装置10間の同期処理を行う機能等を有する。
【0030】
なお、本実施形態において、サーバ20は、事前に登録されるユーザのアカウントを用い、各ユーザおよび端末装置10を識別する。アカウントの登録方法は特に限定されない。例えば、端末装置10またはパーソナルコンピュータ等の他の装置が、ユーザの操作に基づいて、ユーザのアカウント登録に必要な情報をサーバ20に送信し、サーバ20が、受信した情報に基づいて各ユーザのアカウントを作成および保存することとしてもよい。また、各ユーザは、自身の端末装置10からサーバ20にアクセスし自身のアカウントでログインして本実施形態のサービス(換言するとアプリケーション)を利用する。なお、以下では、あるユーザの端末装置10といった場合、当該あるユーザが自身のアカウントでログインしている端末装置10等を指す。
【0031】
図2に示すように、サーバ20は、プロセッサ21、メモリ22、ストレージ23、通信IF(インターフェース)24、および入出力IF25等の協働によって、制御部210および記憶部220として機能する。記憶部220は、制御部210が使用する各種データを格納する。各種データとして、例えば、プログラム221、サービス情報222およびユーザ情報223がある。
【0032】
プログラム221は、サービスを実現するためのプログラムである。サービス情報222およびユーザ情報223は、制御部210がプログラム221を実行するときに参照するデータである。
【0033】
なお、プログラム221は、サーバ20側で実行するプログラムに加え、端末装置10に送信して端末装置10側で実行するプログラム(後述するプログラム121)を含むこととしてもよい。あるいは、記憶部220が、サーバ20側で実行するプログラム221と、端末装置10側で実行するプログラムとを格納することとしてもよい。
【0034】
サービス情報222は、アカウント間で共通の情報である。サービス情報222は、例えば、各種仮想空間を規定するための情報を含む。仮想空間とは、ユーザのキャラクタ等のオブジェクトが配置される空間である。また、サービス情報222は、例えば、仮想空間内に配置される建物や木、石等の背景オブジェクトやノンプレイヤキャラクタ(non player character:NPC)の配置位置や大きさ、色、形状等、アカウント間で共通のオブジェクトに関する各種設定情報を含む。また、サービス情報222は、例えば、ノンプレイヤキャラクタの各種パラメータの設定値等を含む。以下においては、仮想空間に配置されるキャラクタのオブジェクトを指して、単に「キャラクタ」ということもある。
【0035】
ユーザ情報223は、サービスのアカウントごとに管理される情報である。ユーザ情報223は、例えば、ユーザのキャラクタに関する情報、後述する関連ユーザに関する情報、保有資産に関する情報、およびゲーム等の進行度合いを示す情報等を含む。保有資産として、例えば、仮想空間内の通貨やアイテム等が挙げられる。
【0036】
制御部210は、記憶部220に格納されたプログラム221を実行することにより、サービスに関する各種処理を制御する。制御部210は、例えば、送受信部211、サーバ処理部212、同期処理部214、および関連ユーザ管理部215を有する。
【0037】
送受信部211は、各種データを送信または受信する。送受信部211は、例えば、各種データおよびプログラムの送信要求や、マルチプレイ機能に対応するための同期処理の要求、同期処理の対象となるデータ等を、各端末装置10から受信し、サーバ処理部212に渡す。また、送受信部211は、サーバ処理部212による制御に従って、同期を取るための指示等を含む各種データやプログラムを、各端末装置10に送信する。
【0038】
本実施形態において、マルチプレイ機能とは、複数のアカウントについて同期させた状態でサービスを提供する機能である。システム1のサーバ20および端末装置10は、システム1にログインしている複数のアカウントが一緒に所定のコンテンツを利用する場合(例えば、一緒にゲームを行う場合)等に、マルチプレイ機能に対応するための各種処理を実行する。
【0039】
サーバ処理部212は、端末装置10からの要求等に応じ、プログラム221に記述された演算処理を実行することで、端末装置10にサービスを提供する。サーバ処理部212は、例えば、マルチプレイ機能に対応するための同期処理の要求や同期処理の対象となるデータを、送受信部211を介して端末装置10から受け取ると、マルチプレイ機能に対応するための同期処理を実行する。また、サーバ処理部212は、サービス情報222またはユーザ情報223の送信指示を送受信部211に指令する。
【0040】
同期処理部214は、サーバ処理部212からの指令に従って、マルチプレイ機能に対応するための同期処理を実行する。同期処理部214は、例えば、サーバ20が複数の端末装置10に対して情報を送信するときに、各端末装置10に同時に情報を送信することで、各端末装置10間で進行するゲーム等の同期を取る。具体的に、同期処理部214は、各アカウントに対応する端末装置10から所定期間(例えば、一フレーム)内に受信した操作情報を、所定期間ごとに各端末装置10に同時に送信する。操作情報は、端末装置10に入力される操作に関する情報である。同期のタイミングや同期すべき情報は、サーバ処理部212から随時受信することとしてもよい。同期処理を実行することで、一つの端末装置10で入力された操作に起因するサービス内の事象を、他の端末装置10に同時に反映させることが可能となる。
【0041】
関連ユーザ管理部215は、ユーザ間の関連付けに係る制御を行う。関連ユーザ管理部215は、関連付け部216、解除部217、リスト作成部218、および経緯情報管理部219を備える。関連ユーザ管理部215による制御について詳しくは後述する。
【0042】
本実施形態における端末装置10は、例えば、ユーザの入力操作を受け付ける入力装置としての機能、およびサービスに係る画像や音声を出力する出力装置としての機能等を有する。
【0043】
端末装置10は、プロセッサ11、メモリ12、ストレージ13、通信IF14、および入出力IF15等の協働によって、制御部110および記憶部120として機能する。記憶部120は、制御部110が使用する各種データを格納する。各種データとして、例えば、プログラム121、サービス情報122およびユーザ情報123がある。
【0044】
プログラム121は、端末装置10側でサービスを実現するためのプログラムである。サービス情報122およびユーザ情報123は、制御部110がプログラム121を実行するときに参照するデータである。
【0045】
サービス情報122は、上述したサーバ20のサービス情報222と同様の情報を含む。したがって、ここではサービス情報122の説明を省略する。
【0046】
ユーザ情報123は、端末装置10を使用するユーザのアカウントに関するデータであり、上述したサーバ20のユーザ情報223と同様の情報を含む。したがって、ここではユーザ情報123の説明を省略する。
【0047】
制御部110は、記憶部120に格納されたプログラム121を実行することにより、端末装置10において実行されるサービスに関する各種処理を制御する。制御部110は、例えば、操作受付部111、送受信部112、進行部113、および表示制御部114を有する。
【0048】
操作受付部111は、入力部17を介してユーザにより入力される操作(以下、「入力操作」ともいう。)を受け付ける。具体的には、操作受付部111は、入力部17に対する入力操作がされた場合に、入力位置の座標および入力操作の種類を検知する。入力操作の種類として、例えば、タッチ操作、タップ操作、スライド操作、スワイプ操作、フリック操作、ピンチイン操作およびピンチアウト操作等の、手指等による各種操作が挙げられる。入力操作は、入力部17(例えば、タッチスクリーン16)に物理的に接触する操作に限らず、非接触による操作も含み得る。なお、タッチスクリーン16への接触を終了するタッチオフ操作等のそれまで行っていた入力操作を終了する操作も、入力操作の一態様ということができる。
【0049】
ここで、操作受付部111は、入出力IF15を介して接続された操作機器を用いてされる入力操作についても、入力部17に対する入力操作と同様に受け付けることができる。
【0050】
送受信部112は、各種データを送受信する。以下に、具体例を挙げて説明する。
【0051】
送受信部112は、サービス情報122またはユーザ情報123や、マルチプレイ機能に対応するための同期要求等を、サーバ20に送信する。送受信部112は、各種データ、プログラム、およびマルチプレイ機能に対応するための同期のためのデータ等を、サーバ20から受信する。同期のためのデータには、例えば、マルチプレイに参加している各端末装置10間で同期を取るように指示するための同期指示データが含まれる。同期指示データには、例えば、同期対象となるデータおよびそのデータの種類や、同期する時期を特定するためのデータ等が含まれる。
【0052】
送受信部112は、操作受付部111により受け付けられた入力操作に関する操作情報を、サーバ20に送信する。送受信部112は、他の端末装置10において他のユーザにより入力された操作に関する操作情報を、サーバ20から受信する。
【0053】
進行部113は、サービスの進行(例えばゲームの進行等)に関する各種処理を実行する。以下に、具体例を挙げて説明する。
【0054】
進行部113は、サービス情報122に含まれる仮想空間を規定するための情報に基づいて、仮想空間を規定する。進行部113は、サービス情報122に含まれるオブジェクトの設定情報に基づいて、仮想空間にオブジェクトを配置する。進行部113は、仮想空間に配置したオブジェクトを制御する。具体的には、進行部113は、仮想空間内でのオブジェクトの位置、向き、形状、色等を変更することや、オブジェクトに所定の動作を行わせるように、オブジェクトを制御する。
【0055】
進行部113は、仮想空間のうちユーザに提示する領域を指定するための仮想カメラを規定する。進行部113は、仮想空間内での仮想カメラの位置および向きを規定することにより、仮想空間内に仮想カメラを配置する。進行部113は、仮想カメラにより規定される視野領域およびこの視野領域に配置されているオブジェクトを描画した画像を生成するように、表示制御部114に指示する。
【0056】
仮想カメラの位置および向きは、仮想空間ごとに適宜決定することができる。例えば、進行部113は、特定のオブジェクトの位置や向きを基準とし、特定のオブジェクトが特定の向きで視野領域の中央に位置するように、仮想カメラを配置する。その際、進行部113は、特定のオブジェクトに対する方向、距離および角度を用い、仮想カメラの位置や向きを調整する。特定のオブジェクトは、例えば、ユーザのキャラクタやノンプレイヤキャラクタ等の動的なオブジェクトであってもよいし、建物や木、石等の静的なオブジェクトであってもよい。動的なオブジェクトには、各ユーザの操作に基づいてそれぞれ動作するキャラクタと、プログラム121,221に基づいて動作するキャラクタ(例えば、ノンプレイヤキャラクタ等)とが含まれる。
【0057】
進行部113は、操作受付部111により検知された入力位置の座標および入力操作の種類等に基づいて、ユーザの指示内容を解釈する。進行部113は、解釈した指示内容等に基づいて、サービスの進行に関わる各種判定処理を実行する。進行部113は、判定処理の結果等に基づいて、オブジェクトや仮想カメラ等を制御しながらサービスを進行する。進行部113は、サービスの進行状況に応じて、サービス情報122やユーザ情報123を更新、追加または削除する。
【0058】
表示制御部114は、表示部18に画像を表示させる。以下に、具体例を挙げて説明する。
【0059】
表示制御部114は、仮想空間のうち、進行部113が規定する仮想カメラの視野の領域と、その領域に存在するオブジェクトとを描画した画像を生成し、表示部18に表示させる。表示制御部114は、表示部18に表示させる画像に対し、例えば、アイコン、ボタン、各種パラメータを示すメニュー等、サービスの種々の操作に必要なUI(User Interface)に関わるオブジェクトを重畳して描画することができる。
【0060】
なお、図2に示す端末装置10およびサーバ20の機能は一例にすぎない。端末装置10およびサーバ20の各装置は、他の装置が備える機能の少なくとも一部を備えていてもよい。換言すると、本実施形態において端末装置10が備える機能ブロックの一部または全部をサーバ20が備えていてもよく、サーバ20の備える機能ブロックの一部または全部を端末装置10が備えていてもよい。また、端末装置10およびサーバ20等の各装置は、一体の機器により実現されるものでなくてもよく、例えば、ネットワーク等を介して接続される複数の機器によって実現されてもよい。また、システム1は、例えば、端末装置10またはサーバ20のみによって構成されていてもよい。換言すると、システム1は、ネットワークを介して接続される複数の機器によって実現されていなくてもよい。
【0061】
<本実施形態に係る処理>
次に、本実施形態に係る処理について説明する。なお、本実施形態では、端末装置10のプロセッサ11またはサーバ20のプロセッサ21が、システム1に記憶されているプログラムを実行することによって、後述する各処理を行うものとして説明する。ただし、後述する処理であってプロセッサ11が行う処理のうちの少なくとも一部を、プロセッサ11とは別のプロセッサが実行するようにしてもよい。また、後述する処理であってプロセッサ21が行う処理のうちの少なくとも一部を、プロセッサ21とは別のプロセッサが実行するようにしてもよい。換言すると、本実施形態においてプログラムを実行するコンピュータは、端末装置10およびサーバ20のいずれであってもよく、また、複数の装置の組み合わせにより実現されてもよい。
【0062】
本実施形態のシステム1が提供するサービス(換言するとシステム1が実行するアプリケーション)は、例えば、ゲームであってもよく、SNS(Social Networking Service)であってもよく、メタバースに係るもの等であってもよい。
【0063】
本実施形態のサービスでは、ユーザは、他のユーザをフレンドとして登録することができる。フレンドとは、当該あるユーザと当該他のユーザとが互いに関連付けられている関係のことをいう。換言すると、フレンドとは、一方のユーザが他方のユーザに関連付けられているとともに、他方のユーザが一方のユーザに関連付けられている関係をいう。すなわち、第1のユーザから見て第2のユーザがフレンドである場合、当該第2のユーザから見て当該第1のユーザはフレンドとなる。フレンドとは、あるユーザと他のユーザとの相互の同意に基づいて成立する関係であってもよい。
【0064】
本実施形態のサービスでは、ユーザは、他のユーザをフォローすることができる。フォローとは、あるユーザが、他のユーザを自らに関連付けて登録することをいう。すなわち、第1のユーザが第2のユーザをフォローしている場合に、当該第2のユーザが当該第1のユーザをフォローしているとは限らない。フォローとは、一方の意思に基づいて成立し得る関係であってもよい。
【0065】
各ユーザに関連付けられている他のユーザを示す情報は、ユーザ情報223として記憶部220に記憶される。なお、当該情報は、ユーザ情報123として記憶部120に記憶されてもよい。また、当該情報は、各ユーザに関連付けられているユーザ(例えば、各ユーザのフレンドあるいはフォローしているユーザ)を識別可能なものであればよい。具体的には、例えば、各ユーザを一意に識別可能なユーザID(換言すると識別情報)を利用し、各ユーザのユーザIDに、各ユーザに関連付けられている他のユーザのユーザIDを紐付けて記憶しておくことにより、各ユーザのフレンドあるいはフォローしているユーザを管理してもよい。すなわち、あるユーザについて他のユーザをフレンドあるいはフォローするフレンドとして登録する場合、当該他のユーザのユーザIDを当該あるユーザのユーザIDに紐づけて記憶部220に記憶することとしてもよい。
【0066】
なお、各ユーザは、自身のフレンドについては、フレンドではないユーザに比べて、ユーザに関する情報(例えば、当該ユーザがログインしているか否かを示す情報や、当該ユーザが発する情報や、当該ユーザの後述するランクに関する情報等)を、自身の端末装置10で容易に閲覧(換言すると、確認)できるようになっていてもよい。換言すると、ユーザが他のユーザとフレンドとなっている場合、当該他のユーザとフレンドとなっていない場合に比べ、当該ユーザは、当該他のユーザに関する情報の閲覧について有利であってもよい。なお、情報の閲覧について有利とは、閲覧をするために必要な端末装置10での操作数が少ないなど閲覧に要する手間が少ない場合や、閲覧に関する時期的な制限が少ない場合や、他方の場合には閲覧できない特定の情報を閲覧できる場合等を含む。また、サービス内には、例えば、自身のフレンドとしか使用できない機能が存在してもよい。具体的には、サービス内には、自身のフレンドとしか行えない特定の機能や特定のゲーム等が存在してもよい。また、サービス内では、自身のフレンドとの間でしか所定のメッセージの送信あるいは受信が行えないこととしてもよい。また、サービス内では、自身のフレンドとの間でしか保有資産の交換(例えば、アイテムの受け渡し)が行えないこととしてもよい。換言すると、フレンドとは、サービス内の所定の機能であって、フレンドではないユーザとの間では利用することができない機能(例えば、フォローしているユーザとの間でも利用することができない機能)を利用することができるユーザのことであってもよい。なお、当該機能は、フレンドとのマッチング(換言すると、特定のコンテンツを一緒に利用すること(例えば、同一の試合やイベント等に参加することなど))を容易化する機能等であってもよい。
【0067】
また、各ユーザは、自身のフォローしているユーザについては、フォローしていない(かつフレンドではない)ユーザに比べて、ユーザに関する情報を、自身の端末装置10で容易に閲覧(確認)できるようになっていてもよい。換言すると、ユーザが他のユーザをフォローしている場合、当該他のユーザをフォローしていない場合に比べ、当該ユーザは、当該他のユーザに関する情報の閲覧について有利であってもよい。また、サービス内には、例えば、自身のフォローしているユーザとしか使用できない機能が存在してもよい。換言すると、フォローしているユーザとは、サービス内の所定の機能であって、フォローしていない(かつフレンドではない)ユーザとの間では利用することができない機能を利用することができるユーザのことであってもよい。なお、一方のユーザが他方のユーザをフォローしている場合であって、当該他方のユーザが当該一方のユーザをフォローしていない場合が存在してもよい。この場合には、当該一方のユーザは、当該他方のユーザに比べ、相手方に関する情報の閲覧について有利であってもよい。具体的には、例えば、当該一方のユーザは当該他方のユーザに関する特定の情報が閲覧できるが、当該他方のユーザは、当該一方のユーザに関する特定の情報の閲覧ができないなどしてもよい。
【0068】
(自動での関連付け)
関連付け部216は、サービス内においてあるユーザ(以下、「第1ユーザ」ともいう。)と所定の体験を共有する他のユーザを特定する。また、関連付け部216は、特定した当該他のユーザを、当該ユーザのフレンドとして自動で登録する。換言すると、関連付け部216は、特定した当該他のユーザと当該ユーザとを、自動的に互いに関連付ける。さらに換言すると、関連付け部216は、特定した当該他のユーザと当該ユーザとを互いに関連付ける関連付け処理を、当該ユーザによる当該関連付けを指示する操作および当該他のユーザによる当該関連付けを指示する操作を介することなく行う。なお、以下では、サービスを利用する複数のユーザのうちの任意のユーザを第1ユーザと呼ぶことがある。また、関連付け部216により特定される、第1ユーザのフレンドとして自動で登録する他のユーザ等の、第1ユーザ以外のユーザを第2ユーザと呼ぶことがある。
【0069】
サービス内において体験を共有することの一例としては、以下が挙げられる。すなわち、所定の体験を共有するとは、例えば、「ゲームにおいて同一のクエストを行う」というものであってもよい。また、所定の体験を共有するとは、例えば、「仮想空間内において同一のイベントに参加する」というものであってもよい。また、所定の体験を共有するとは、例えば、「仮想空間内において会話(例えば、テキストメッセージによる会話等を含む)をする」というものであってもよい。また、所定の体験を共有するとは、例えば、「同一の映像(例えば、ライブ映像や、ゲーム中における特定のシーン)を見る」というものであってもよい。また、所定の体験を共有するとは、例えば、「同一のカテゴリのコンテンツ(例えば、イベントや映像)を利用する」というものであってもよい。また、所定の体験を共有するとは、例えば、「仮想空間内において同じ場所に訪れる(換言すると滞在する)」というものであってもよい。なお、ここで仮想空間内におけるユーザの位置は、現実世界におけるユーザの位置(例えば、ユーザの端末装置10の位置)に連動するもの(換言すると応じたもの)であってもよい。
【0070】
サービス内においてユーザと所定の体験を共有する他のユーザは、例えば、所定の体験を共有中の他のユーザであってもよく、共有後の他のユーザであってもよく、共有決定後の他のユーザであってもよい。ここで、所定の体験を共有決定後の他のユーザとは、例えば、ゲーム内におけるマッチングがされた他のユーザや、サービス内において所定のイベントへの参加を予約している他のユーザや、仮想空間内における所定のイベントを待機する場所(例えば、いわゆるロビー等)にいる他のユーザ等の、所定の体験を共有することが決定されている他のユーザか否かを関連付け部216が判別可能な他のユーザ(例えば、所定の体験の共有についての予定がサービス内において組まれている他のユーザ等)を意味し、一緒にゲームをすることを現実世界において約束しただけのユーザ等は含まない。
【0071】
また、サービス内においてユーザと所定の体験を共有する他のユーザとは、例えば、サービス内において所定のコンテンツをユーザと一緒に利用する他のユーザであってもよい。換言すると、サービス内においてユーザと所定の体験を共有する他のユーザとは、例えば、所定のコンテンツを一緒に利用中の他のユーザであってもよく、一緒に利用した他のユーザであってもよく、一緒に利用すること決定後の他のユーザであってもよい。
【0072】
サービス内において所定のコンテンツを一緒に利用することの一例としては、以下が挙げられる。すなわち、所定のコンテンツを一緒に利用するとは、例えば、「ゲームにおいて所定の試合やクエストに一緒に参加する(例えば、味方あるいは敵として参加する)」というものであってもよい。また、所定のコンテンツを一緒に利用するとは、例えば、「仮想空間内において所定のイベントに一緒に参加する」というものであってもよい。また、所定のコンテンツを一緒に利用するとは、例えば、「SNSまたはゲーム等において同一のグループチャットに参加する」というものであってもよい。また、所定のコンテンツを一緒に利用するとは、例えば、「所定の映像(例えば、ライブ映像や、ゲーム中における特定のシーン)を一緒に見る」というものであってもよい。
【0073】
関連付け部216は、第1ユーザと所定の体験を共有する他のユーザを自動でフレンドとして登録する他のユーザとして特定するが、この際に、具体的には、第1ユーザと所定の体験を共有する他のユーザであって、サービス内において第1ユーザと所定の関係性を有する他のユーザを、自動で登録する他のユーザとして特定することとしてもよい。換言すると、関連付け部216は、第1ユーザと所定の体験を共有する他のユーザを自動でフレンドとして登録する場合に、当該他のユーザが第1ユーザと所定の関係性を有することを条件として自動でフレンドとして登録することとしてもよい。以下、所定の関係性の一例を説明する。
【0074】
所定の関係性は、例えば、「サービス内における立場関係が特定の関係である関係性」であってもよい。具体的には、所定の関係性は、例えば、「所定の目的のために協力する集団(例えば、いわゆるチーム、パーティ、ギルドなど)に互いが所属している関係性」であってもよい。また、所定の関係性は、例えば、「互いが敵同士である関係性」であってもよい。
【0075】
また、所定の関係性は、例えば、「少なくとも一方のユーザの属性に基づいて決まる関係性が特定の関係性である関係性」であってもよい。ここで、ユーザの属性の一例としては、ランク、性別、プレイ時間、行動傾向、または使用(換言すると所有)しているキャラクタ等が挙げられる。なお、ランクとは、ユーザの習熟度を示すものともいえ、ユーザ間での相対的な位置付けを示すものともいえる。ランクは、一般的なゲームにおいていわゆるレベルと呼ばれるもの等を含む。なお、ユーザのランクとは、ユーザ自体のランクであってもよく、ユーザの使用するキャラクタのランク等であってもよい。また、キャラクタとは、ユーザのアバター等を含む。すなわち、所定の関係性は、例えば、「ランクが第1ユーザよりも高い関係性」であってもよい。また、所定の関係性は、例えば、「サービス内における性別が一致している(あるいは異なっている)関係性」であってもよい。また、所定の関係性は、例えば、「迷惑な行為をされる確率が低い(換言すると、迷惑な行為を行うユーザではない)関係性」であってもよい。なお、迷惑な行為をされる確率が低いか否かは、例えば、過去にコンテンツの利用中(例えば他のユーザ(ここで、他のユーザは第1ユーザであってもよく、第1ユーザ以外のユーザを含む他のユーザであってもよい。)との試合中やクエスト中)においてネットワーク接続が切断された回数等をユーザ毎にユーザ情報223としてサーバ20の記憶部220に記憶しておき、当該回数等に基づいて関連付け部216が判断してもよい。また、迷惑な行為をされる確率が低いか否かは、例えば、サービス内におけるチャットにおいて、予め設定されている禁止ワード(換言すると監視対象ワード)を使用した回数等をユーザ毎にユーザ情報223としてサーバ20の記憶部220に記憶しておき、当該回数等に基づいて関連付け部216が判断してもよい。
【0076】
また、ユーザの属性としての使用しているキャラクタに基づいて決まる関係性については、一例として、以下が挙げられる。すなわち、所定の関係性は、例えば、「使用しているキャラクタの種類が被らない(換言すると異なるキャラクタを使用している)関係性」であってもよい。また、所定の関係性は、例えば、「所定の集団(例えば、パーティ)を形成した場合にキャラクタの属性(換言するとユーザの属性)から考えて当該所定の集団のバランスが良くなる関係性」であってもよい。具体的には、所定の関係性は、例えば、「属性(換言すると得意な点等)の異なるキャラクタを使用している(例えば、ロールプレイングゲームやFPS(First Person shooter)等において、第1ユーザが攻撃の得意なキャラクタを使用し、第2ユーザが回復の得意なキャラクタを使用している)関係性」であってもよい。また、所定の関係性は、例えば、「属性の共通する(例えば、同じ)キャラクタを使用している関係性」であってもよい。
【0077】
換言すると、所定の関係性(例えば、所定の集団のバランスが良くなる関係性)は、例えば、「一方のユーザの属性(例えば、「攻撃が得意」や「回復が得意」などの属性や、ユーザの使用するキャラクタの属性など)を他方のユーザの属性が補完する関係性(具体的には、例えば、「攻撃が得意」と「回復が得意」などの関係性。換言すると、一方のユーザの属性と他方のユーザの属性とが相補的な関係性。)」であってもよい。より具体的には、所定の関係性は、例えば、「一方のユーザの属性であって、ゲームの内容(換言すると、ゲームにおける所定の目的の達成(例えば、所定の敵キャラクタの討伐や、所定のステージのクリアや、チームの勝利等)に影響を与える属性を、他方のユーザの属性であって、ゲームの内容に影響を与える属性が補完する関係性」であってもよい。
【0078】
また、所定の関係性は、例えば、「一方のユーザに関する所定の属性と他方のユーザに関する所定の属性とが共通する関係性」であってもよい。具体的には、所定の関係性は、例えば、「属性の共通するキャラクタを使用している関係性」であってもよい。また、所定の関係性は、例えば、「ランク帯の一致する関係性」であってもよい。また、所定の関係性は、例えば、「性別の一致する関係性」であってもよい。また、所定の関係性は、例えば、「行動傾向の類似する関係性」であってもよい。換言すると、所定の関係性は、例えば、「一方のユーザの属性であって、ゲームの内容(換言すると、ゲームにおける所定の目的の達成(例えば、所定の敵キャラクタの討伐や、所定のステージのクリアや、チームの勝利等)に影響を与える属性と、他方のユーザの属性であって、ゲームの内容に影響を与える属性とが共通する関係性」であってもよい。
【0079】
また、所定の関係性は、例えば、「一緒に利用中または利用したコンテンツにおいて、少なくとも一方のユーザの行った行為に基づいて決まる関係性が特定の関係性である関係性」であってもよい。具体的には、所定の関係性は、例えば、「一緒に利用しているコンテンツにおいて、利となる行為(換言すると、アシスト行為)をしてくれた関係性」あるいは「一緒に利用しているコンテンツにおいて、利となる行為をしてあげた関係性」であってもよい。ここで、利となる行為としては、例えば、ロールプレイングゲームやFPS等において第1ユーザのキャラクタを回復させる行為(例えば、蘇生させる行為等を含む)や、第1ユーザが倒そうとしている敵キャラクタに対して攻撃を加える行為(換言するとアシスト攻撃する行為)等が挙げられる。また、所定の関係性は、例えば、「一緒に利用しているコンテンツにおいて、ネットワーク接続が切れてしまった(切断してしまったあるいは切断されてしまった)関係性」であってもよい。また、所定の関係性は、例えば、「一緒に参加しているグループチャット内において発言(具体的には一方または双方の発言)があった関係性」あるいは「一緒に参加しているグループチャット内において相互にメンションを付け合った(あるいは一方が他方に対してメンションを付けた)関係性」であってもよい。
【0080】
また、所定の関係性は、例えば、「一緒に利用したコンテンツの利用結果に基づいて決まる関係性が特定の関係性である関係性」であってもよい。具体的には、所定の関係性は、例えば、「一緒に行ったゲームにおいて、仲間として勝利または敗北という結果を得た関係性」であってもよく、「一緒に行ったゲームにおいて、敵として勝利または敗北という結果を得た関係性」等であってもよい。また、所定の関係性は、例えば、「一緒に行ったゲームにおける所定の成績が、第1ユーザよりも優れている関係性」であってもよい。また、所定の関係性は、例えば、「複数回一緒にゲームを行った結果に基づいて判断される、所定のシチュエーション(例えば、各種ゲームにおける所定のステージ(換言するとマップ))においてチームを組んだ場合の勝率が高い(換言すると所定値よりも高い。ここで、所定値は固定値でなくてもよい。)関係性」であってもよい。
【0081】
また、所定の関係性は、例えば、「少なくとも一方のユーザの行った行為に基づいて判断される親密度が高い(換言すると所定度合い以上である)関係性」であってもよい。ここで、関連付け部216は、例えば、親密度の高低を、一方のユーザが他方のユーザに対して行った好意的行動に基づいて判断してもよい。具体的には、例えば、関連付け部216は、ゲームにおいて第2ユーザが第1ユーザのキャラクタを蘇生してくれた場合に、第2ユーザが親密度の高い行動(蘇生させずに放置する場合等に比べて親密度が高い行動)をしてくれたとして、親密度が高い(換言すると所定度合い以上)と判断してもよい。また、関連付け部216は、複数の定型メッセージ(例えば、定型の文章やいわゆるスタンプ等。具体的には、例えば、「こんにちは」、「ナイスプレイ」、「がんばろう」など。)から定型メッセージを選択して相手方に送ることが可能なサービスにおいて、一方が他方に特定の定型メッセージ(例えば、「ナイスプレイ」)を送った場合に、当該一方が親密度の高い行動をしたとして、親密度が高い(換言すると所定度合い以上)と判断してもよい。なお、関連付け部216が、親密度が高いか否かを判断する方法は、例えば、ユーザの行う各行為(例えば、他のユーザのキャラクタを蘇生させる行為、特定の定型メッセージを送る行為など)について親密度が高い行為か否かを示す情報が付されており、当該情報に基づいて判断するものであってもよい。また、当該方法は、例えば、ユーザの行う各行為について親密度に係る数値が割り振られているとともに、記憶部220が当該数値の累積値を記憶するようになっており、関連付け部216は、サービス内におけるユーザの行為に基づいて当該累積値を増加あるいは減少させていくとともに、当該累積値が所定値以上となった場合に、親密度が高い(換言すると所定度合い以上である)と判断するもの等であってもよい。
【0082】
また、所定の関係性は、例えば、「一緒に利用しているコンテンツの利用期間が所定期間以上となる関係性」であってもよい。具体的には、所定の関係性は、例えば、「一緒に参加しているグループチャットにおいて両者が当該グループチャットに参加している期間が所定期間以上である関係性」であってもよい。
【0083】
なお、関連付け部216は、サービス内において第1ユーザと所定の関係性を有する他のユーザを、フレンドとして自動で登録する他のユーザとして特定する場合に、上に例示した一の関係性を満たす他のユーザを特定するのではなく、複数の関係性を満たす他のユーザを特定するものであってもよい。換言すると、例えば、「関連付け部216は、サービス内における立場関係が第1ユーザと特定の関係であるユーザをフレンドとして自動で登録する」といった場合には、フレンドとして自動で登録するユーザの条件の1つを示しているに過ぎず、例えば、当該ユーザであって、少なくとも一方のユーザの属性に基づいて決まる関係性が特定の関係性であるユーザについて自動で登録し、ユーザの属性に基づいて決まる関係性が特定の関係性でないユーザについては自動で登録しないといった構成等を含み得る。
【0084】
関連付け部216は、ユーザが任意に設定可能な条件(以下、「登録条件」という。)を満たす他のユーザを、フレンドとして自動で登録する他のユーザとして特定してもよい。換言すると、所定の関係性は、例えば、「第1ユーザが設定した登録条件を満たす関係性」であってもよい。換言すると、所定の関係性(どのような関係性を有する他のユーザをフレンドとして自動で登録するのか)は、各ユーザが任意に設定可能となっていてもよい。さらに換言すると、登録条件の設定に応じて、上述の各関係性を満たした場合にフレンドとして自動で登録するか否かが変化するようになっていてもよい。
【0085】
具体的には、関連付け部216は、例えば、第1ユーザと所定の体験を共有する他のユーザであって、第1ユーザが登録条件として指定している属性(例えば、ランク、性別、プレイ時間、行動傾向、またはキャラクタ(例えばキャラクタの属性)等)を有する他のユーザを、第1ユーザのフレンドとして自動で登録してもよい。
【0086】
なお、このように、ユーザが任意に設定可能な登録条件を満たすユーザをフレンドとして自動で登録することとした場合に、関連付け部216は、一方のユーザが設定した登録条件を他方のユーザが満たす場合であって、かつ、当該他方のユーザが設定した登録条件を当該一方のユーザが満たす場合に、当該一方のユーザと当該他方のユーザとをフレンドとして自動で登録することとしてもよい。換言すると、関連付け部216は、一方のユーザから見て所定の関係性を有する他方のユーザを、当該一方のユーザのフレンドとして自動で登録する場合において、当該一方のユーザが当該他方のユーザから見て所定の関係性を有するユーザであることを条件として、両者をフレンドとして登録することとしてもよい。
【0087】
なお、登録条件をユーザが任意に設定できることとした場合に、その設定方法については、特に限定されるものではないが、例えば以下のようにしてもよい。具体的には、各ユーザは、登録条件として、フレンドになりたいユーザの条件を自身の端末装置10から設定することとしてもよい。換言すると、フレンドになりたいユーザの条件を規定するホワイトリストの設定が可能となっていてもよい。また、各ユーザは、登録条件として、フレンドになりたくないユーザの条件を自身の端末装置10から設定することとしてもよい。換言すると、フレンドになりたくないユーザの条件を規定するブラックリストの設定が可能となっていてもよい。さらに換言すると、登録条件を満たすユーザとは、フレンドになりたくないユーザの条件として設定された条件を満たさないユーザのことであってもよい。
【0088】
なお、あるユーザが第1ユーザと所定の関係性を有するか否かは、第1ユーザの属性に応じて変わることとしてもよい。具体的には、例えば、FPSにおいて、第1ユーザが攻撃の得意なキャラクタを使用している場合には、所定の関係性を有するユーザは、回復の得意なキャラクタを使用しているユーザであり、第1ユーザが回復の得意なキャラクタを使用している場合には、所定の関係性を有するユーザは、攻撃の得意なキャラクタを使用しているユーザである等してもよい。
【0089】
また、所定の関係性の成立には、回数に関する条件があってもよい。具体的には、例えば、第1ユーザとサービス内において所定の体験を共有する他のユーザ、具体的には同じカテゴリのイベントに参加した他のユーザを、関連付け部216がフレンドとして自動で登録する場合に、同じカテゴリのイベントにN回(ここで、Nは1以上の整数)参加した他のユーザを、フレンドとして自動で登録することとしてもよい。また、例えば、第1ユーザと所定のコンテンツを一緒に利用する他のユーザ、具体的にはゲームにおいて同じ試合に参加した他のユーザを、関連付け部216がフレンドとして自動で登録する場合に、同じ試合にN回参加(例えば、N回連続で参加)した他のユーザを、フレンドとして自動で登録することとしてもよい。また、例えば、一緒に利用しているコンテンツにおいて、利となる行為をしてくれた他のユーザを、関連付け部216がフレンドとして自動で登録する場合に、利となる行為をN回してくれた他のユーザを、フレンドとして自動で登録することとしてもよい。また、例えば、一緒に参加しているグループチャット内において相互にメンションを付け合った(あるいは一方が他方に対してメンションを付けた)他のユーザを、関連付け部216がフレンドとして自動で登録する場合に、N回メンションを付けた他のユーザを、フレンドとして自動で登録することとしてもよい。なお、当該回数に関する条件(具体的には、Nをいくつにするか等)は、登録条件(具体的には、登録条件の少なくとも一部)としてユーザが任意に設定できることとしてもよい。
【0090】
関連付け部216が、所定の体験を共有する(例えば、所定のコンテンツを一緒に利用する)ユーザを、フレンドとして自動で登録するタイミングは、例えば、所定の体験の共有中であってもよく、共有後であってもよく、共有することが決定されたときであってもよい。
【0091】
すなわち、例えば、第1ユーザと所定のコンテンツを一緒に利用中の第2ユーザを自動で登録する場合に、コンテンツの利用中において特定の条件を満たした第2ユーザを、当該特定の条件を満たしたタイミングで自動で登録することとしてもよい。特定の条件を満たした第2ユーザとは、例えば、ゲーム中において、第1ユーザの利となる行為(換言するとアシスト行為)をした第2ユーザであってもよい。また、特定の条件を満たした第2ユーザとは、例えば、ゲーム中において、ネットワーク接続が切れたユーザであってもよい。また、特定の条件を満たしたユーザとは、例えば、第1ユーザと同じグループチャットに参加する第2ユーザであって、当該グループチャット内において発言をした第2ユーザ、または当該グループチャット内において相互にメンションを付け合った(あるいは一方が他方に対してメンションを付けた)第2ユーザ等であってもよい。また、特定の条件を満たした第2ユーザとは、ここで例示した行為等を複数回行った第2ユーザ(例えば、第1ユーザの利となる行為を複数回行った第2ユーザや、メンションを複数回付け合った(あるいは付けた)第2ユーザ等)であってもよい。なお、特定の条件を満たすとは、所定の関係性が成立することとなる条件を満たすことであってもよく、所定の関係性が成立することとなる条件以外の条件を満たすことであってもよい。
【0092】
また、例えば、第1ユーザと所定のコンテンツを一緒に利用した第2ユーザを自動で登録する場合に、コンテンツの利用中において特定の条件を満たした第2ユーザ、またはコンテンツの利用結果について特定の条件を満たした第2ユーザを、当該コンテンツの利用が終了したタイミングで自動で登録することとしてもよい。なお、コンテンツの利用結果について特定の条件を満たした第2ユーザとは、例えば、ゲームにおいて仲間あるいは敵として勝利という結果または敗北という結果を得たユーザであってもよく、勝利という結果または敗北を得たユーザであって所定の成績を残したユーザ等であってもよい。なお、自動で登録するタイミングは、例えば、ゲームが終了した後、リザルト(換言すると成績)の表示中(例えば、第1ユーザの端末装置10の表示部18等において、リザルトが表示されているとき)等であってもよい。
【0093】
また、例えば、第1ユーザと所定のコンテンツを一緒に利用した第2ユーザを自動で登録する場合に、コンテンツの利用中において特定の条件を満たした第2ユーザ、コンテンツの利用結果について特定の条件を満たした第2ユーザ、またはコンテンツの利用後に特定の条件を満たした第2ユーザを、当該コンテンツの利用が終了してから所定の期間が経過したタイミングで自動で登録することとしてもよい。具体的には、例えば、レベル10以上となった場合に所定の関係性が成立する第2ユーザがいた場合において、一緒に行った試合の終了時点において第2ユーザのレベルがレベル1だったものの、その後期間が経過してレベル10となった場合に、第2ユーザがレベル10になったことに基づいて第2ユーザをフレンドとして自動で登録することとしてもよい。この場合、関連付け部216は、当該試合が終了してから第2ユーザがレベル10になるまでの間、サーバ20の記憶部220に、第2ユーザをフレンド候補として記憶しておき、レベル10になったか(所定の関係性が成立する状態となったか)否かの監視を続けることとしてもよい。
【0094】
また、例えば、第1ユーザと所定のコンテンツを一緒に利用することが決まっている第2ユーザをフレンドとして自動で登録する場合に、例えば、マッチングがされた直後のタイミングで自動で登録することとしてもよく、一緒に参加するゲームやイベントが開始されるタイミングで自動で登録することとしてもよく、第1ユーザと第2ユーザとの双方がグループチャットに参加したタイミングで自動で登録することとしてもよい。
【0095】
なお、ここで説明したフレンドとして自動で登録するタイミングは、後述するフレンド登録またはフォローの申請を行うタイミング(換言すると、当該申請に係る後述する承諾画面を表示するタイミング)として読み替えてもよい。
【0096】
なお、関連付け部216が、第1ユーザのフレンドとして自動で登録する第2ユーザを特定するタイミングと、第2ユーザを第1ユーザのフレンドとして自動で登録するタイミングとは、異なっていてもよい。
【0097】
なお、各ユーザに関連付けることができるユーザの数(例えば、各ユーザのフレンドの数)に上限が設けられている場合に、関連付け部216は、例えば、第1ユーザに関連付けられている他のユーザの数が上限に対して所定割合未満である場合に自動での関連付けを行い、所定割合以上の場合に自動での関連付けを行わないこととしてもよい。換言すると、関連付け部216が他のユーザを自動で関連付けるための条件は、関連付けられている他のユーザの数に応じて緩和あるいは厳しくされてもよい。
【0098】
なお、ここでは、関連付け部216は、特定した第2ユーザを第1ユーザのフレンドとして自動で登録するものとして説明したが、関連付け部216は、特定した第2ユーザを、第1ユーザがフォローするユーザとして自動で登録することとしてもよい。換言すると、関連付け部216は、特定した第2ユーザを第1ユーザに自動的に関連付けることとしてもよい。さらに換言すると、関連付け部216は、特定した第2ユーザを第1ユーザに関連付ける処理を、第1ユーザによる当該関連付けを指示する操作を介することなく行うこととしてもよい。また、関連付け部216は、特定した第2ユーザに対する、第1ユーザからのフレンド登録の申請またはフォローの申請を、自動で行うこととしてもよい。換言すると、関連付け部216は、特定した第2ユーザに対する、第2ユーザの第1ユーザへの関連付けに係る申請を自動で行うこととしてもよい。さらに換言すると、関連付け部216は、特定した第2ユーザに対する、第2ユーザの第1ユーザへの関連付けに係る申請を、第1ユーザによる当該申請を指示する操作を介することなく行う申請部として機能してもよい。なお、第2ユーザに対して、第2ユーザの第1ユーザへの関連付けに係る申請(具体的には、フレンド登録の申請またはフォローの申請)がされた場合、例えば、第2ユーザが、自身の端末装置10で当該申請を承諾する所定の入力操作を行った場合等に、第1ユーザに第2ユーザが関連付けられる(換言すると、第1ユーザと第2ユーザとがフレンドとなるか、または第1ユーザが第2ユーザをフォローした状態となる)。
【0099】
なお、他のユーザをフレンドまたはフォローするユーザとして自動で登録するか否か、あるいは、他のユーザに対してフレンド登録あるいはフォローの申請を自動で行うか否かは、各ユーザが自身の端末装置10から設定可能となっていてもよい。
【0100】
なお、本実施形態において、各種処理を「ユーザによる操作を介することなく行う」等といった場合には、当該処理を行う際にユーザによる操作が不要なものであればよく、例えば、当該処理を行うための条件を予め設定しておく操作や、自動での当該処理の実行を有効化する操作等の、ユーザによる事前の設定操作等は行われるものであってもよい。具体的には、「第2ユーザの第1ユーザへの関連付けに係る申請を、第1ユーザによる当該申請を指示する操作を介することなく行う」といった場合には、例えば、従来のゲーム等におけるフレンド登録を申請するボタンをタップする操作等を要さずに当該申請が行われるものであればよく、当該申請を自動で行うための事前の設定操作等については行われるものであってもよい。
【0101】
なお、本実施形態のサービスは、他のユーザをフレンドとして登録する機能およびフォローするユーザとして登録する機能のいずれか一方を有さないものであってもよい。また、他のユーザをフレンドとして登録する機能およびフォローするユーザとして登録する機能の両方を有する場合において、いずれか一方については、自動での登録あるいは登録についての申請が行われるが、他方については自動での登録および登録についての申請が行われないこととしてもよい。また、他のユーザをフレンドとして登録する機能およびフォローするユーザとして登録する機能の両方を有し、両方について自動での登録あるいは登録についての申請が行われるが、それぞれについての自動で行うための条件は異なるなどしてもよい。
【0102】
(関連付けの解除)
ここまで、関連付け部216により特定された第2ユーザについて、自動でフレンドとして登録すること、自動でフォローすること、および自動でフレンド登録あるいはフォローの申請をすることを説明した。換言すると、関連付け部216により特定された第2ユーザについて、ユーザ間の関連付けに係る処理を自動で行うことについて説明した。以下では、このように関連付けに係る処理が自動でされ、当該処理に基づいて第1ユーザに関連付けられた第2ユーザ(すなわち、第1ユーザのフレンドあるいはフォローしているユーザ。以下、「関連ユーザ」ともいう。)について、第1ユーザとの関連付けを解除する動作について説明する。なお、関連ユーザには、自動で関連付けられたユーザのみならず、例えば、第1ユーザが自身の端末装置10からフレンド登録またはフォローの申請を行い、相手方ユーザが自身の端末装置10で当該申請を承諾したことによりフレンドとなったユーザまたはフォローしているユーザ等が含まれてもよい。換言すると、関連ユーザには、手動で関連付けられたユーザ(具体的には、フレンド登録またはフォローの申請が第1ユーザの入力操作に基づいて行われ、当該申請に基づいて関連付けられたユーザ)が含まれてもよい。なお、ここで、フレンド登録またはフォローの申請が第1ユーザの入力操作に基づいて行われた場合に、第2ユーザの承諾を要することなく、第2ユーザが第1ユーザのフレンドまたはフォローするユーザとして登録されるようになっていてもよく、第2ユーザの承諾を介して当該登録がされるようになっていてもよい。なお、以下では、フレンドとしての登録もしくはフォローまたはこれらの申請が自動で行われ、関連付けられたユーザのことを「自動で関連付けられたユーザ」ともいう。
【0103】
記憶部220は、ユーザ間の関連付けの解除に係る条件(以下、「解除条件」という。)を記憶する。解除部217は、各ユーザに関連付けられた関連ユーザのうち、解除条件を満たすユーザを、関連付けを解除するユーザ(以下、「解除ユーザ」という。)として特定する。また、解除部217は、特定した解除ユーザとの関連付けを解除する。
【0104】
解除条件は、例えば、「所定期間一緒にコンテンツを利用していない(換言すると、所定期間一緒にプレイしていない)」というものであってもよい。また、解除条件は、例えば、「関連ユーザ(あるいは第1ユーザ)が、所定期間ログインしていない(換言すると、サービスを利用していない)」というものであってもよい。また、解除条件は、例えば、「メッセージの送信に関する頻度が低い(例えば、所定期間内における第1ユーザと関連ユーザとのうちの一方から他方へのメッセージの送信回数(あるいは双方からのメッセージの送信回数の合計)が所定回数以下)」というものであってもよい。また、解除条件は、例えば、「関連ユーザのランクが所定期間変化していない」というものであってもよい。また、解除条件は、例えば、「関連ユーザによってサービス内のチャットが荒らされた」というものであってもよい。なお、チャットが荒らされたか否かは、例えば、予め設定されている禁止ワード(換言すると監視対象ワード)を使用した回数が所定回数以上か否かに基づいて判断してもよく、関連ユーザから第1ユーザへのメッセージの送信回数が、第1ユーザから関連ユーザへのメッセージの送信回数に比べて過大であるか否か等に基づいて判断してもよい。
【0105】
解除条件は、各ユーザが、自身の端末装置10から任意に設定可能となっていてもよい。例えば、端末装置10の表示部18に、上述の各解除条件が選択項目として表示され、適用したい解除条件(あるいは適用を中止したい解除条件)を選択する入力操作をユーザが行うことで、解除条件が設定できるようになっていてもよい。
【0106】
また、解除条件は、ユーザが任意に変更することができないものであってもよい。換言すると、解除条件のうちの少なくとも一部は、ユーザが任意に変更することはできず、全ユーザに適用されるものであってもよい。
【0107】
また、解除条件として複数の条件が設定されている場合に、解除部217は、当該複数の条件のうちの1の条件を満たす関連ユーザとの関連付けを解除することとしてもよく、複数(例えば全部)の条件を満たす関連ユーザとの関連付けを解除することとしてもよい。
【0108】
関連ユーザの自動解除に係る解除条件は、自動で関連付けられたユーザに適用されるものであって、手動で関連付けられたユーザには適用されないものであってもよい。ここで、「自動で関連付けられたユーザに適用され、手動で関連付けられたユーザに適用されない」とは、例えば、(1)システム上、手動で関連付けられたユーザについては解除条件に基づく関連付けの自動解除が行われることがない構成の場合、および、(2)手動で関連付けられたユーザについては自動で関連付けられたユーザの自動解除に係る解除条件とは異なる第2の解除条件に基づく自動での関連付けの解除が行われる構成の場合などを含む。なお、(2)の構成については、ユーザの選択に応じて、手動で関連付けられたユーザと自動で関連付けられたユーザとの両方について同一の解除条件に基づく自動での関連付けの解除が可能な構成も含む。このような構成によれば、ユーザが主体的に関連付けた他のユーザであって、関連付けの維持を希望する可能性が高い手動での関連付けがされたユーザについては、自動で解除されないようにし(あるいは解除されにくくし)、手動で関連付けられたユーザに比べて関連付けの維持を希望する可能性が低い自動での関連付けがされたユーザについては、自動で解除されるようにすることができる。
【0109】
解除条件は、ユーザに関連付けられた関連ユーザの数に応じて緩和あるいは厳しくされてもよい。換言すると、解除部217は、ユーザに関連付けられた関連ユーザの数に応じて解除条件を変化させてもよい。具体的には、解除部217は、例えば、関連ユーザの数が多くなるほど解除条件を緩和するように(換言すると解除されやすくなるように)してもよい。ここで、関連ユーザの数が多くなるほど解除条件を緩和するとは、少なくとも、ある所定数を境とした解除条件が厳しい状態と緩和された状態との2つの状態が存在するものであればよい。ここで、所定数は、一定の数であってもよい。また、所定数は、ユーザが任意に設定可能なものであってもよい。また、所定数は、状況に応じて変動するものであってもよい。また、所定数は、例えば、一のユーザに関連付けることができる関連ユーザの数に上限数が設けられている場合に、この上限数に対する割合が所定割合以上となる数であってもよい。換言すると、解除部217は、例えば、あるユーザに関連付けられた関連ユーザの数が、当該上限数に近くなるほど解除条件を緩和するように(換言すると解除されやすくなるように)してもよい。なお、当該上限数は、自動で関連付けられたユーザと手動で関連付けられたユーザとで個別に設けられていてもよく、自動で関連付けられたユーザと手動で関連付けられたユーザとを合わせた数についてのものであってもよい。なお、解除条件が厳しい状態は、自動解除がされない状態であってもよい。換言すると、解除部217は、例えば、あるユーザに関連付けられた関連ユーザの数が、当該上限数に対して余裕がある場合には、自動で関連付けられたユーザの自動解除を行わないこととしてもよい。
【0110】
なお、解除条件を緩和するとは、例えば、関連ユーザとの関連付けを自動で解除するために必要な条件の数が減少するものであってもよい。また、解除条件を緩和するとは、例えば、各解除条件に係るパラメータを変化させるもの等であってもよい。例えば、「所定期間一緒にコンテンツを利用していない」という条件等の、期間に関する定めのある条件を満たす関連ユーザについて関連付けを自動解除する場合において、当該期間を定めるパラメータを、当該期間が短くなるように変化させるもの等であってもよい。
【0111】
上述のように、解除部217は、解除条件を満たす関連ユーザを、解除ユーザとして特定し、特定した解除ユーザとの関連付けを解除する。また、解除部217は、解除ユーザの特定を自動で行う。換言すると、解除部217は、第1ユーザへの関連付けを解除する解除ユーザを特定する際に、第1ユーザによる当該特定を指示する操作を介さずに、解除ユーザの特定を行う。
【0112】
また、解除部217は、特定した解除ユーザとの関連付けの解除を自動で行う。換言すると、解除部217は、解除ユーザの第1ユーザへの関連付けを解除する際に、第1ユーザによる当該解除を指示する操作を介さずに、解除ユーザの関連付けを解除する。
【0113】
なお、例えば、第1ユーザへの関連付けを解除する関連ユーザとして解除部217が特定した解除ユーザは、関連付けの解除がされる前に、第1ユーザに対して提示されることとしてもよい。具体的には、例えば、解除部217が解除ユーザを特定すると、関連付けの解除がされる前に、第1ユーザの端末装置10の表示部18に、特定された解除ユーザが表示されることとしてもよい。ここで、表示部18には、解除ユーザが特定された後、第1ユーザが初めてサービスを利用(換言するとアプリケーションを起動)するときなどに、特定された解除ユーザがポップアップ表示されてもよい。また、表示部18には、特定された解除ユーザがリストで表示されてもよい。当該リストは、関連付けを解除する予定の関連ユーザのリストともいえ、例えばリスト作成部218が作成する。また、このようにポップアップ表示やリスト表示等によって解除ユーザを第1ユーザに提示する画面においては、解除ユーザの関連付けの解除をするか否かの選択を促す表示等が表示され、解除部217は、第1ユーザによる当該解除を選択する入力操作(換言すると、関連付けの解除を指示する操作)がされた場合に解除ユーザの関連付けを解除することとしてもよい。換言すると、解除部217は、特定した解除ユーザの第1ユーザへの関連付けを解除する際に、第1ユーザによる当該解除を指示する操作を介して、解除ユーザの関連付けを解除してもよい。
【0114】
また、解除部217が解除ユーザを特定し、第1ユーザへの関連付けの解除を自動で行った場合等において、第1ユーザの端末装置10の表示部18に、関連付けが解除された解除ユーザが表示されることとしてもよい。ここで、表示部18には、例えば、解除ユーザの関連付けが解除された後、第1ユーザが初めてサービスを利用(換言するとアプリケーションを起動)するときなどに、解除された解除ユーザがポップアップ表示されてもよい。また、表示部18には、関連付けが解除された解除ユーザがリストで表示されてもよい。当該リストは、関連付けが解除された関連ユーザのリストともいえ、例えばリスト作成部218が作成する。また、このようにポップアップ表示やリスト表示等によって関連付けが解除された解除ユーザを第1ユーザに提示する画面においては、関連付けが解除された解除ユーザとの関連付けを復活させるか(再度関連付けるか)否かの選択を促す表示等が表示され、解除部217は、第1ユーザによる当該復活を選択する入力操作(換言すると、再度の関連付けを指示する操作)がされた場合に、関連付けが解除された解除ユーザを、第1ユーザに再度関連付けることとしてもよい。
【0115】
なお、関連付けを解除する予定の解除ユーザのリストにおいては、各解除ユーザの当該リストへの掲載期間に期限が設けられており、所定期間が経過すると、当該所定期間が経過した解除ユーザの第1ユーザへの関連付けが解除されるとともに、当該解除ユーザの当該リスト上での表示が終了することとしてもよい。また、関連付けが解除された解除ユーザのリストにおいては、各解除ユーザのリストへの掲載期間に期限が設けられており、所定期間が経過すると、当該所定期間が経過した解除ユーザの当該リスト上での表示が終了することとしてもよい。換言すると、リスト作成部218は、これらのリストに含まれてから所定期間が経過した解除ユーザを、リストから削除してもよい。なお、これらの各掲載期間は、ユーザに関連付けられた関連ユーザの数(例えば、上限数に対する割合等)に応じて変化してもよい。
【0116】
なお、関連付けを解除する予定の解除ユーザのリストあるいは関連付けが解除された解除ユーザのリストは、リスト作成部218が作成して記憶部220等の所定の記憶部に記憶しておき、表示部18での表示を行う際に端末装置10に送信されるなどしてもよい。
【0117】
なお、第1ユーザとの関連付けを解除する関連ユーザとして解除部217が特定した解除ユーザを、関連付けの解除がされる前に、第1ユーザに対して提示するか否か(当該提示をしてから解除を行うか当該提示をせずに解除を行うか)は、第1ユーザが自身の端末装置10から設定可能となっていてもよい。また、関連付けが解除された解除ユーザを第1ユーザに提示するか否かは、第1ユーザが自身の端末装置10から設定可能となっていてもよい。
【0118】
なお、解除部217による自動での関連付けの解除を行いたくない関連ユーザについて、自動での関連付けの解除の対象から除外することが可能となっていてもよい。具体的には、例えば、第1ユーザの端末装置10の表示部18に、第1ユーザに関連付けられている関連ユーザのリストが表示され、当該リストに含まれる関連ユーザの中から、解除の対象から除外したい関連ユーザを選択する入力操作(例えば、タッチ操作等)を入力部17が受け付け、解除部217が当該入力操作に基づいて、選択されたユーザを解除の対象から除外するユーザとして記憶部220に登録することとしてもよい。解除部217は、解除の対象から除外された関連ユーザについては、当該関連ユーザが解除条件を満たす関連ユーザであったとしても、自動での解除ユーザとしての特定または自動での関連付けの解除を行わない。換言すると、関連ユーザ管理部215は、第1ユーザに関連付けられている関連ユーザのうち、第1ユーザが指定した関連ユーザを解除の対象から除外する特別関連ユーザとして登録することとしてもよい。この場合、当該特別関連ユーザは、特別関連ユーザでない関連ユーザ(換言すると、第1ユーザから指定されていない関連ユーザ)に比べ、関連付けの解除についての制限がされる(例えば、自動での解除ユーザとしての特定または解除が行われないなど)。
【0119】
(関連ユーザのリスト)
各ユーザの端末装置10からは、自身に関連付けられている関連ユーザのリスト(以下、「関連ユーザリスト」という。)を見ることが可能となっている。各ユーザの端末装置10の表示制御部114は、自身に関連付けられた関連ユーザについての関連ユーザリストを表示部18に表示させる。関連ユーザリストが表示される関連ユーザリスト表示画面50の一例を図3に示す。
【0120】
図3に示す関連ユーザリスト表示画面50には、各関連ユーザについて、各関連ユーザの情報としてのユーザ名および関連付けられた経緯に関する情報(以下、「経緯情報51」という。)、経緯情報51の入力をする際に操作する経緯情報入力ボタン52、および関連付けに関する設定を行うための各種ボタンが表示される。そして、各ユーザは、関連ユーザリスト表示画面50(具体的には経緯情報51)を見ることで、各関連ユーザが自身に関連付けられた経緯を確認することが可能となっている。
【0121】
経緯情報51は、例えば、以下のように入力される。まず、第1ユーザは、特定の関連ユーザについて、経緯情報51を入力する場合に、経緯情報入力ボタン52を選択する入力操作を行う。当該入力操作がされると表示制御部114は、経緯情報入力画面60を表示部18に表示させる。経緯情報入力画面60の一例を図4に示す。
【0122】
経緯情報入力画面60では、例えば、関連付けの経緯に関する複数のタグ61が表示される。経緯情報管理部219は、経緯情報入力画面60に表示された複数のタグ61の中から第1ユーザの入力操作によって選択されたタグ61を、当該特定の関連ユーザの経緯情報51として当該特定の関連ユーザに付して記憶部220に記憶させる。なお、一人の関連ユーザに対して、複数のタグ61を付すことが可能となっていてもよい。
【0123】
ここで、タグ61は、例えば、第1ユーザと当該特定の関連ユーザとが共有した体験(例えば、両者を関連付けるきっかけとなった一緒にプレイした試合)での出来事に関するもの(例えば、第1ユーザまたは当該特定の関連ユーザの行動に関するものや、第1ユーザまたは当該特定の関連ユーザの成績に関するもの等)であってもよく、第1ユーザと当該特定の関連ユーザとの関係性に関するもの等であってもよい。また、タグ61は、例えば、関連ユーザを自動で関連付ける原因となった事象に関するものであってもよい。具体的には、タグ61は、例えば、「回復してくれた」、「回復してあげた」、「アシスト攻撃してくれた」、「アシスト攻撃してあげた」、「アイテムをくれた(例えば、消費アイテムを使ってくれた場合等を含む)」、「アイテムをあげた」、「上手かった(換言すると成績が良かった)」、「下手だった(換言すると成績が悪かった)」、「共闘した」、「対戦した」、「勝利した」、「敗北した」、「一緒に特定のライブに参加した」、または「チャットで何往復以上の会話をした」などといったものであってもよい。
【0124】
なお、経緯情報入力画面60では、第1ユーザと当該特定の関連ユーザとが共有した体験において実際に起こった出来事に関するタグ61の選択に関する補助がされてもよい。具体的には、例えば、経緯情報入力画面60では、実際に起こった出来事に関するタグ61が優先的に表示されてもよい。ここで、優先的にとは、例えば、実際に起こった出来事に関するタグ61のみが表示されるものであってもよく、実際に起こった出来事に関するタグ61の表示上の優先順位が高いもの(例えば、実際に起こった出来事に関するタグ61ほど、上側に表示される等)であってもよい。また、例えば、経緯情報入力画面60の表示が開始されるときには、実際に起こった出来事に関するタグ61が選択された状態(例えば、図4に示す例においてチェックマークが付された状態)で表示が開始されてもよい。
【0125】
なお、経緯情報入力画面60は、例えば、第1ユーザに第2ユーザが自動で関連付けられたタイミング(自動でのフレンドとしての登録がされたタイミング、自動でのフォローがされたタイミング、または自動でのフレンド登録あるいはフォローの申請を第2ユーザが承諾したタイミング)で第1ユーザ(および第2ユーザ)の端末装置10の表示部18に表示されるなどしてもよい。また、経緯情報入力画面60は、例えば、第1ユーザに第2ユーザを自動で関連付けることが決定された試合が終了したとき(例えば、リザルトの表示中)に、第1ユーザ(および第2ユーザ)の端末装置10の表示部18に表示されるなどしてもよい。換言すると、経緯情報管理部219は、第1ユーザに第2ユーザを自動で関連付ける際に、経緯情報51の入力を促す表示としての経緯情報入力画面60を表示させるための情報を端末装置10に送信し、表示制御部114は、当該情報に基づいて経緯情報入力画面60を表示部18に表示させるなどしてもよい。また、このように、所定のタイミングで経緯情報入力画面60を表示するなどして経緯情報51の入力を促すこととした場合に、第1ユーザに対して第2ユーザが自動で関連付けられた場合には、第1ユーザ(および第2ユーザ)の端末装置10において経緯情報51の入力を促す表示がされる一方、第1ユーザに対して第2ユーザが手動で関連付けられた場合には、第1ユーザ(および第2ユーザ)の端末装置10において経緯情報51の入力を促す表示がされない(換言すると、経緯情報管理部219は、経緯情報入力画面60を表示させるための情報を端末装置10に送信しない)こととしてもよい。
【0126】
なお、第2ユーザに対するタグ付けは、体験の共有中(例えば、両者を関連付けるきっかけとなる一緒にプレイしている試合の最中)において実行可能となっていてもよい。具体的には、第1ユーザと第2ユーザとが一緒にゲームを行っている状態において、第2ユーザが第1ユーザのキャラクタを蘇生してくれた場合等に、第1ユーザが自身の端末装置10で、「蘇生してくれた」というタグ61を第2ユーザに付す入力操作を行うことが可能となっており(例えば、当該タグ61が表示部18に表示され、これを選択する入力操作が可能となっており)、関連付け部216は、当該入力操作に基づいて、当該タグ61を、第2ユーザの経緯情報51として第2ユーザに付して記憶部220に記憶させるなどしてもよい。なお、この場合に、タグ61は、体験の共有中であって、第2ユーザを第1ユーザに関連付けることが決定される前に第2ユーザに付すことが可能となっていてもよい。また、関連付け部216は、当該タグ61が付されたことに基づいて、第2ユーザを第1ユーザに関連付ける(換言するとフレンドとしての登録、フォロー、またはこれらの申請をする)こととしてもよい。
【0127】
なお、ここでは、経緯情報入力画面60では、経緯情報51がタグ61の選択に基づいて入力されることとしたが、経緯情報51は、経緯情報入力画面60において、テキスト入力によって入力されるようになっていてもよい。
【0128】
また、経緯情報51は、例えば、ユーザの操作を介さずに自動的に入力されるようになっていてもよい。例えば、関連ユーザを自動で関連付ける原因となった事象が、経緯情報51として自動で入力されるようになっていてもよい。具体的には、例えば、第2ユーザが、ゲーム中のある試合Xにおいて第1ユーザのキャラクタを回復させる行為(具体的には、蘇生させる行為)を3回行ってくれたことに基づいて、第2ユーザを第1ユーザの関連ユーザとして自動で登録する場合に、経緯情報管理部219は、第2ユーザに、「試合Xで3回蘇生してくれた」という経緯情報51を自動で(換言すると第1ユーザの操作を介することなく)付し、関連ユーザに関する情報として記憶部220に記憶させる等してもよい。換言すると、例えば、第2ユーザを自動で関連付けるきっかけとなったプレイ(例えば試合など)時における出来事、あるいは第1ユーザと第2ユーザとの関係性等が、経緯情報51として自動で入力されるようになっていてもよい。また、記憶部220に自動的に記憶された経緯情報51は、ユーザの端末装置10での入力操作に基づいて編集可能となっていてもよい。この場合、例えば、経緯情報管理部219は、当該入力操作に基づいて、経緯情報51を編集する。
【0129】
また、所定のタイミングで経緯情報入力画面60を表示させる場合に、経緯情報51が自動で入力された状態で表示させるとともに、経緯情報入力画面60では、ユーザによる当該自動で入力された経緯情報51を編集する入力操作が受け付けられるようになっていてもよい。当該入力操作は、例えば、自動で入力された経緯情報51を編集するテキスト入力操作であってもよく、自動で付されたタグ61(例えば、図4に示す例においてチェックマークが自動で付されている場合等を含む。)を削除したり別のタグ61を追加したりする入力操作であってもよい。
【0130】
関連ユーザリスト表示画面50に表示される、関連付けに関する設定を行うための各種ボタンには、例えば、関連ユーザの関連付けを解除する際に操作する解除ボタン53と、関連ユーザをお気に入りとして登録する際に操作するお気に入りボタン54と、関連ユーザの登録条件を編集する際に操作する条件編集ボタン55と、条件の設定を解除する際に操作する条件解除ボタン56と、経緯情報51に基づいて登録条件を設定する際に操作する条件設定オブジェクト57と、が含まれる。
【0131】
解除ボタン53に対する入力操作がされると、解除部217は、対象の関連ユーザとの関連付けを解除する。すなわち、ユーザは、解除ボタン53に対する操作をすることにより、手動で関連ユーザとの関連付けを解除することが可能となっている。なお、解除ボタン53が操作された際に、表示制御部114は、関連付けを本当に解除してもよいか確認する確認画面等を表示部18に表示させてもよい。
【0132】
お気に入りボタン54に対する入力操作がされると、関連ユーザ管理部215は、対象の関連ユーザ(換言すると、操作されたお気に入りボタン54に係る関連ユーザ)を、お気に入りとして登録する。お気に入りとして登録された関連ユーザについては、例えば、当該関連ユーザが解除条件を満たす場合であっても、自動での解除ユーザとしての特定または自動での関連付けの解除を行わない。また、お気に入りとして登録された関連ユーザについては、例えば、解除ボタン53に対する操作に基づいて関連付けを解除する場合等に、お気に入りとして登録されていない関連ユーザに比べて解除に必要な手順数(例えば、解除しても良いかの確認の回数等)が増えることとしてもよい。換言すると、関連ユーザ管理部215は、第1ユーザに関連付けられている関連ユーザのうち、第1ユーザが指定した関連ユーザを特別関連ユーザ(換言すると、お気に入り)として登録する。そして、ここで、当該特別関連ユーザは、特別関連ユーザでない関連ユーザ(換言すると、第1ユーザから指定されていない関連ユーザ)に比べ、関連付けの解除についての制限がされてもよい(例えば、自動での解除ユーザとしての特定または解除が行われない、あるいは解除をする際に第1ユーザが行う手順数が多いなど)。
【0133】
なお、関連ユーザのお気に入りとしての登録は、お気に入りボタン54に対する操作に基づくものでなくてもよい。例えば、関連ユーザ管理部215は、ユーザによる入力操作(例えば、テキスト入力による入力あるいはタグ61の選択による入力等)によって経緯情報51が入力された関連ユーザを、自動的にお気に入りとして登録してもよい。
【0134】
条件編集ボタン55に対する入力操作がされると、表示制御部114は、登録条件の編集を行うための編集画面(図示せず)を表示部18に表示させる。編集画面で登録条件の編集(換言すると設定)が行われると、関連付け部216は、編集後の登録条件を満たすユーザを自動で関連付けるようになる。換言すると、本実施形態では、編集画面で登録条件の編集をすることにより、自動で関連付けるユーザの条件を変更することが可能となっている。さらに換言すると、本実施形態では、条件編集ボタン55に対する入力操作に基づいて、関連ユーザの登録条件が編集可能となっている。
【0135】
編集画面では、例えば、対象の関連ユーザの経緯情報51に対応する登録条件の詳細条件を設定することが可能となっていてもよい。具体的には、「試合Xで3回蘇生してくれた」という経緯情報51、すなわち「蘇生をしてくれた」という経緯情報51が付された関連ユーザに係る条件編集ボタン55が操作された場合、編集画面では、「蘇生をしてくれた」という登録条件についての詳細条件として、「何回」蘇生をしてくれた場合に、蘇生行為をしてくれたユーザを関連ユーザとして自動で登録するかが設定可能となっている。換言すると、当該編集画面では、当該詳細条件の設定に関する入力操作が受け付けられるようになっていてもよい。
【0136】
また、編集画面では、例えば、対象の関連ユーザの経緯情報51とは関係のない登録条件についての設定が可能となっていてもよい。具体的には、「蘇生をしてくれた」という経緯情報51が付された関連ユーザに係る条件編集ボタン55が操作された場合に、編集画面では、「蘇生をしてくれた」という登録条件に替え、あるいは追加して、「アイテムをくれた」という登録条件や、「共闘した」という登録条件等を設定可能となっていてもよい。
【0137】
また、本実施形態では、条件設定オブジェクト57に対する入力操作がされると、関連付け部216は、対象の関連ユーザの経緯情報51に基づいて、今後自動で関連付けるために他のユーザが満たすべき条件(すなわち登録条件)を設定する。具体的には、関連ユーザリスト表示画面50においては、各関連ユーザの経緯情報51に基づいて抽出される登録条件が条件設定オブジェクト57として表示される。より具体的には、例えば、関連ユーザに「試合Xで3回蘇生してくれた」という経緯情報51が付されている場合には、当該経緯情報51に基づいて抽出される登録条件として、「蘇生をしてくれた」という登録条件に係る条件設定オブジェクト57が、関連ユーザリスト表示画面50に表示される。そして、ユーザによる当該条件設定オブジェクト57に対する入力操作がされると、関連付け部216は、今後、蘇生をしてくれた他のユーザを自動で関連付けるように「蘇生をしてくれた」という登録条件を設定(換言すると有効化)する。すなわち、本実施形態では、経緯情報51に関連する登録条件が、設定する(換言すると有効化する)登録条件の候補として関連ユーザリスト表示画面50に表示され、ユーザに当該登録条件の設定が提案されるようになっている。なお、条件設定オブジェクト57の表示は、例えば、以下のようにして実現することができる。すなわち、経緯情報51に含まれ得るキーワード(例えば、上述の例においては「蘇生」など)と、登録条件との対応関係を示すテーブルを記憶部220に記憶しておき、経緯情報51に特定のキーワードが含まれる場合には、関連ユーザ管理部215が、当該特定のキーワードに対応する登録条件を抽出するとともに、抽出した登録条件に係る条件設定オブジェクト57を表示部18に表示させるための情報を端末装置10に送信することとしてもよい。
【0138】
条件解除ボタン56は、条件設定オブジェクト57として表示される登録条件の設定を解除(換言すると無効化)する際に操作するボタンである。条件解除ボタン56に対する入力操作がされると、関連付け部216は、対象の関連ユーザの条件設定オブジェクト57に係る登録条件を、今後自動で関連付けるために他のユーザが満たすべき条件から除外する。換言すると、条件解除ボタン56に対する入力操作がされると、関連付け部216は、対象の関連ユーザの経緯情報51に基づいて抽出される登録条件を、今後自動で関連付けるために他のユーザが満たすべき条件から除外する。なお、条件解除ボタン56に対する入力操作がされると、関連付け部216は、対象の関連ユーザを自動で関連付ける際に当該関連ユーザが満たした登録条件を、今後自動で関連付けるために他のユーザが満たすべき条件から除外することとしてもよい。なお、条件解除ボタン56に対する入力操作がされ、登録条件の設定が解除されると、条件解除ボタン56が条件設定ボタン(図示せず)に変化し、当該条件設定ボタンに対する入力操作がされると、条件解除ボタン56に対する入力操作に基づいて解除(換言すると無効化)された登録条件が、再度設定(換言すると有効化)されるようになっていてもよい。換言すると、条件設定オブジェクト57は、登録条件を設定(換言すると有効化)する操作を受け付けるオブジェクトではなく、単に所定の登録条件を表示するオブジェクトであってもよい。
【0139】
なお、経緯情報51等の関連ユーザリストの表示に必要な情報は、例えば、サーバ20の記憶部220に記憶されており、関連ユーザリストの表示を行う際に(例えば、操作受付部111に対する所定の入力操作に基づく端末装置10からサーバ20への要求に基づいて)、関連ユーザ管理部215から端末装置10に送信される。なお、関連ユーザリストの表示に必要な情報は、記憶部120に記憶されていてもよい。
【0140】
(分類リスト)
リスト作成部218は、ユーザに関連付けられた複数の関連ユーザを関連ユーザの属性に応じて分類した複数のリスト(以下、「分類リスト」という。)を作成する。また、各ユーザの端末装置10の表示制御部114は、自身に関連付けられた関連ユーザについての分類リストを表示部18に表示させる。分類リストが表示される分類リスト表示画面70の一例を図5に示す。
【0141】
リスト作成部218は、例えば、第1ユーザに関連付けられた関連ユーザを、第1ユーザとの相性に応じて分類した複数の分類リストを作成してもよい。なお、1人の関連ユーザが、複数の分類リストに割り当てられていてもよい。また、1人の関連ユーザが、複数の分類リストに割り当てられること(換言すると、重複して含まれること)はないようになっていてもよい。また、各関連ユーザは、必ずいずれかの分類リストに割り当てられるようになっており、いずれの分類リストにも割り当てられていない関連ユーザが存在しないようになっていてもよい。また、いずれの分類リストにも割り当てられない関連ユーザが存在し得るようになっていてもよい。
【0142】
具体的には、例えば、所定のゲーム(具体的には、ロールプレイングゲームやFPS等)を想定した場合に、リスト作成部218は、関連ユーザを第1ユーザとの相性に応じて分類した分類リストとして、「回復が得意」という属性を有する関連ユーザをまとめた分類リスト(図5(a)参照)と、「攻撃が得意」という属性を有する関連ユーザをまとめた分類リスト(図5(b)参照)とを作成してもよい。ここで、回復が得意か、攻撃が得意かは、例えば、各関連ユーザの使用するキャラクタの属性(例えば職業)に基づいて判断してもよく、各関連ユーザの所有するアイテム等に基づいて判断してもよい。例えば、使用するキャラクタの職業が「回復系魔法使い」、「衛生兵」などの関連ユーザを、回復が得意な関連ユーザの分類リストに含めてもよい。また、例えば、使用するキャラクタの職業が「攻撃系魔法使い」、「剣士」などの関連ユーザを、攻撃が得意な関連ユーザの分類リストに含めてもよい。ここで、使用するキャラクタとは、例えば、そのユーザがもっとも頻繁に(換言すると多く)使用しているキャラクタであってもよく、メインで使用するキャラクタを各ユーザが選択可能なゲーム等においてメインで使用するキャラクタとして設定されているキャラクタであってもよく、よく使用するキャラクタを各ユーザがお気に入りとして登録可能なゲームに等においてお気に入りとして登録されているキャラクタであってもよく、使用回数が所定回数を超えているキャラクタであってもよく、そのキャラクタを使用しての勝利回数が所定回数を越えているキャラクタ等であってもよい。また、例えば、所有する回復アイテムの数が所定個数以上の関連ユーザを、回復が得意な関連ユーザの分類リストに含めてもよい。また、例えば、ゲーム内における最強の銃など、他のユーザが所有する武器(換言するとゲーム内に存在する他の武器)に比べて攻撃性能の高い武器を所有する関連ユーザを、攻撃が得意な関連ユーザの分類リストに含めてもよい。
【0143】
換言すると、リスト作成部218は、関連ユーザを第1ユーザとの相性に応じて分類した分類リストとして、関連ユーザを関連ユーザの使用するキャラクタの属性に応じて分類した分類リストを作成してもよい。リスト作成部218は、例えば、上述のようにキャラクタの職業等によって分類した分類リストを作成してもよく、キャラクタのランク等によって分類した分類リストを作成してもよい。また、リスト作成部218は、例えば、ユーザが使用するキャラクタと被らないキャラクタを使用する関連ユーザをまとめた分類リスト等を作成してもよい。このような、キャラクタの属性に応じて分類した分類リスト等は、第1ユーザが一緒にプレイをしやすい関連ユーザ(例えば、第1ユーザが一緒にプレイしやすい属性のキャラクタを有する関連ユーザや、第1ユーザが一緒にプレイしやすいランク帯の関連ユーザ等)や、一緒にプレイしにくい関連ユーザを探しやすくなるものであり、第1ユーザとの相性に応じて分類した分類リストといえる。
【0144】
また、リスト作成部218は、関連ユーザを第1ユーザとの相性に応じて分類した分類リストとして、第1ユーザと各関連ユーザとの過去のプレイ履歴に基づいて判断される第1ユーザとの相性に応じた分類リストを作成してもよい。具体的には、例えば、所定のゲーム(具体的には、所定の目的の達成を目指すゲーム(例えば対戦ゲーム)等)を想定した場合に、リスト作成部218は、過去に関連ユーザと第1ユーザとが一緒にプレイ(ここで、一緒にとは、仲間としてプレイした場合および敵としてプレイをした場合のどちらであってもよい。)して所定の目的を達成した回数または確率(換言すると、対戦ゲームにおける勝率等)に応じて関連ユーザを分類した分類リストを作成してもよい。また、リスト作成部218は、例えば、第1ユーザと関連ユーザとの一方が他方に対して高評価のリアクションをした回数(例えば、いわゆる「いいね」の数など)に応じて関連ユーザを分類した分類リストを作成してもよい。また、リスト作成部218は、例えば、第1ユーザと関連ユーザとの一方が他方に対して利となる行為を行った回数に応じて関連ユーザを分類した分類リストを作成してもよい。
【0145】
また、例えば、リスト作成部218は、関連ユーザを第1ユーザとの相性に応じて分類した分類リストとして、関連ユーザを各ステージ毎の相性で分類した分類リストを作成してもよい。具体的には、例えば、FPSにおいて第1ステージと第2ステージとを含む複数のステージ(換言するとマップ)が用意されている場合に、リスト作成部218は、第1ステージとの相性が良い関連ユーザをまとめた分類リストと、第2ステージとの相性が良い関連ユーザをまとめた分類リストと、を作成してもよい。ここで、各関連ユーザの各ステージとの相性は、例えば、各関連ユーザの各ステージでの過去の対戦での勝率(例えば、勝率7割以上だと相性が良い、など。)、勝利回数(例えば、累計勝利回数が100回に達していれば相性が良い、など。)あるいは前回の試合で優れた成績を収めたか否か(例えば、その試合で勝利していれば相性がよい、など。)に基づいて判断してもよい。
【0146】
また、リスト作成部218は、例えば、第1ユーザに関連付けられた関連ユーザを、一緒にプレイをする頻度に応じて分類した複数の分類リストを作成してもよい。具体的には、リスト作成部218は、例えば、関連ユーザを所定期間内に一緒にプレイをした回数に応じて分類した複数の分類リストを作成してもよい。
【0147】
また、リスト作成部218は、例えば、第1ユーザに関連付けられた関連ユーザを、関連ユーザに付された経緯情報51に応じて分類した複数の分類リストを作成してもよい。具体的には、リスト作成部218は、例えば、関連ユーザを、関連ユーザに付されたタグ61で分類した複数の分類リストを作成してもよい。
【0148】
また、リスト作成部218は、例えば、第1ユーザに関連付けられた関連ユーザを、サービス内での関連ユーザの行為に基づく属性に応じて分類した複数の分類リストを作成してもよい。具体的には、リスト作成部218は、例えば、第1ユーザに関連付けられた関連ユーザを、第1ユーザと一緒に利用したコンテンツ(例えば、ゲーム)中の関連ユーザの行為に基づく属性に応じて分類した複数の分類リストを作成してもよい。なお、行為に基づく属性とは、行為の結果に関する属性を含む。具体的には、リスト作成部218は、例えば、関連ユーザを、関連ユーザが行った行為(例えば、第1ユーザを回復してくれた、アシスト攻撃してくれた、アイテムをくれた、敵キャラクタを倒した)の種類、特定の行為を行った回数、行為の結果としての特定の結果(例えば、試合で勝利したなど)を得た(換言すると、達成した)回数、得た結果の種類、または特定の結果を得る確率(例えば、勝率など)などに応じて分類した複数の分類リストを作成してもよい。また、リスト作成部218は、第1ユーザに関連付けられた関連ユーザを、サービス内での関連ユーザの行為であって、第1ユーザの利となる行為に基づく属性に応じて分類した複数の分類リストを作成してもよい。具体的には、リスト作成部218は、例えば、関連ユーザを、関連ユーザが行った第1ユーザの利となる行為の種類、利となる特定の行為を行った回数、利となる行為の結果としての特定の結果を得た回数、利となる行為により得られた結果の種類などに応じて分類した複数の分類リストを作成してもよい。
【0149】
リスト作成部218が作成した複数の分類リストは、分類リスト記憶部としてのサーバ20の記憶部220に記憶される。また、記憶部220に記憶された各分類リストは、所定のタイミングで第1ユーザに提示可能(所定のタイミングで第1ユーザの端末装置10に表示させることが可能)となっている。
【0150】
なお、各分類リストに含める関連ユーザの条件は、各ユーザが、自身の端末装置10から設定可能となっていてもよい。換言すると、関連ユーザをどのように分類し、どのような分類リストを作成するかは、各ユーザが、自身の端末装置10から設定可能となっていてもよい。
【0151】
また、上述のように、関連付け部216は、第1ユーザと所定の体験を共有する他のユーザを第1ユーザに自動で関連付けるが、リスト作成部218は、このように自動で関連付けられた関連ユーザを、当該関連ユーザの属性に応じた分類リストに自動的に振り分けてもよい。また、このような自動で関連付けられた関連ユーザを、どの分類リストに振り分けるかは、各ユーザが、自身の端末装置10から手動で選択可能となっていてもよい。
【0152】
また、関連付け部216は、第1ユーザと所定の体験を共有する他のユーザであって、サービス内において第1ユーザと所定の関係性を有する他のユーザを、第1ユーザに自動で関連付けるが、ここで所定の関係性は、「いずれかの分類リストに該当する関係性」であってもよい。すなわち、例えば、第1ユーザの分類リストとして、FPSにおける第1ステージとの相性が良い関連ユーザの分類リストが用意されている場合に、第1ユーザと同じ試合に参加したユーザのうち、第1ステージとの相性が良いユーザを、第1ユーザのフレンド等として自動で登録するなどしてもよい。換言すると、フレンドの分類として複数の分類が記憶部220に記憶されていることとした場合に、関連付け部216は、当該複数の分類のいずれかに該当するユーザを自動で関連付けることとしてもよい。
【0153】
なお、リスト作成部218は、複数の分類リストを作成し、記憶部220に記憶させるが、当該複数の分類リストは、複数の関連ユーザを関連ユーザの属性に応じて分類したものでなくてもよい。例えば、リスト作成部218は、第1ユーザに関連付けられた複数の関連ユーザを、単に複数のリストに分類した分類リストを作成してもよい。また、各分類リストにどの関連ユーザを含めるかは、第1ユーザが自身の端末装置10で選択可能となっていてもよい。換言すると、リスト作成部218は、ユーザの操作に基づいて、各分類リストに含める関連ユーザを決定してもよい。さらに換言すると、記憶部220には、ユーザの操作に基づいて作成された複数の分類リストが記憶可能になっていてもよい。
【0154】
表示部18における分類リストの表示は、例えば、以下のようにしてもよい。すなわち、例えば、図5に示すように、表示部18に表示される、分類リストを表示する分類リスト表示画面70においては、複数の分類リストの中から表示させる分類リストを選択する操作を受け付けるオブジェクト(例えばタブ71)が表示されてもよい。そして、表示制御部114は、ユーザによる当該オブジェクトに対する入力操作により選択された分類リストを表示部18に表示させてもよい。なお、分類リストの表示にあたり必要となる分類リストの情報は、例えば、分類リスト表示画面70の表示開始時等に、端末装置10からの要求に基づいてサーバ20から端末装置10に送られてもよく、表示させる分類リストを選択するユーザの入力操作に基づいて端末装置10からサーバ20へ要求し、サーバ20から端末装置10に送られてもよい。なお、複数の分類リストは端末装置10の記憶部120に記憶されており、表示制御部114は、記憶部120に記憶された分類リストを表示部18に表示させることとしてもよい。また、端末装置10の制御部110がリスト作成部218を備えてもよい。
【0155】
なお、以上のように、本実施形態では、リスト作成部218が複数の分類リストを記憶部に記憶させておき、記憶部に記憶された当該複数の分類リストのうちの各分類リストが端末装置10で表示されるようになっている。すなわち、本実施形態に係る構成は、ユーザに関連付けられた複数の関連ユーザを、当該ユーザが入力した所定の検索条件に基づいて絞り込んだ結果を表示するだけのものや、当該複数の関連ユーザを、当該ユーザが入力した所定の条件に基づいて並べ替えた結果を表示するだけのものとは異なり、複数の分類リストが、関連ユーザのリストの表示がされるよりも前の時点において予め作成され記憶される構成となっている。
【0156】
また、表示制御部114は、分類リストを表示部18に表示させる場合に、ユーザの選択に基づいて決まるサービス内の所定のシチュエーションに適した分類リストを優先的に表示させてもよい。なお、優先的にとは、所定のシチュエーションに適した分類リストのみが表示されるものであってもよく、所定のシチュエーションに適した分類リストの表示上の優先順位が高いもの(例えば、所定のシチュエーションに適した分類リストが初めに表示され、表示させる分類リストを変更する入力操作(例えば上述のタブを選択する操作)に基づいて他の分類リストが表示されるものや、所定のシチュエーションに適した分類リストが他の分類リストに比べて大きく表示されるものなど)であってもよい。ここでは、具体例として、図6(a)に示すように、FPSにおいて、第1ステージおよび第2ステージ等の各種ステージ(換言するとマップ)を選択することができるステージ選択画面75が表示部18に表示されている場合を例に説明する。なお、ステージ選択画面75は、例えば、ステージを選択することで、そのステージでの対戦が開始される画面であってもよく、ステージを選択することで、そのステージについての情報を確認することができる画面であってもよい。ステージ選択画面75において、第1ステージを選択する入力操作がされた場合、表示制御部114は、図6(b)に示すように、第1ステージとの相性が良い関連ユーザの分類リストが表示される分類リスト表示画面70を表示部18に表示させる。一方、ステージ選択画面75において、第2ステージを選択する入力操作がされた場合、表示制御部114は、第2ステージとの相性が良い関連ユーザの分類リストが表示される分類リスト表示画面70を表示部18に表示させる。すなわち、表示制御部114は、複数の分類リストのうち、ユーザの選択に基づいて決まる所定のシチュエーション(換言するとユーザがプレイしようとするステージ)に適した属性を有する関連ユーザの分類リストを表示部18に表示させる。なお、上述のように、ステージ選択画面75は、ステージを選択することで、そのステージでの対戦が開始される画面であってもよい。そして、例えば、ステージ選択画面75において、ステージを選択する入力操作がされ、表示された分類リストの中から、1または複数の関連ユーザを選択する操作がされると、選択したユーザの端末装置10から、選択された関連ユーザの端末装置10へ、サーバ20を介してプレイへの参加に関する招待が送られ、当該関連ユーザが当該招待を承諾する操作を行うことにより、当該ステージでの両者が参加してのプレイが開始されるようになっていてもよい。
【0157】
なお、ユーザの選択に基づいて決まるシチュエーションは、例えば、ユーザが参加しようとするイベント等であってもよい。例えば、ユーザが参加しようとするライブを選択する入力操作を行った場合に、表示制御部114は、当該ライブに一緒に参加するのに適した属性を有する関連ユーザの分類リスト(例えば、参加したイベントの履歴から当該ライブに興味を抱く可能性が高いと判断される関連ユーザの分類リストなど)を優先的に表示させてもよい。
【0158】
なお、ユーザの選択に基づいて決まるシチュエーションは、例えば、ユーザの属性等に関するものであってもよい。具体的には、例えば、ロールプレイングゲームで、ユーザが使用するキャラクタとして回復の得意なキャラクタを選択している場合において、ユーザが関連ユーザのリストを表示させるための所定の入力操作を行った場合に、表示制御部114は、回復の得意なキャラクタでプレイするというシチュエーションに適した属性を有する関連ユーザの分類リストとして、攻撃が得意なキャラクタを使用する関連ユーザの分類リスト(換言すると、ユーザの属性を補完する属性を有する関連ユーザの分類リスト)を優先的に表示させてもよい。
【0159】
なお、ここでは、リスト作成部218は、予め複数の分類リストを作成して記憶部に記憶させておき、表示制御部114は、表示部18に分類リストを表示させる際に、当該複数の分類リストの中から選択される分類リストを表示させることとして説明した。ただし、リスト作成部218は、表示部18への表示を行う際に分類リストを作成するものであってもよい。具体的には、例えば、図6(a)に示すステージ選択画面75において、第1ステージを選択する入力操作がされた場合に、リスト作成部218が第1ステージとの相性が良い関連ユーザの分類リスト(換言するとユーザの選択に基づいて決まるシチュエーションに適した属性を有する関連ユーザのリスト)を作成し、表示制御部114が当該分類リストを表示部18に表示させるなどしてもよい。
【0160】
次に図7~11を参照しながら、システム1が実行する処理の流れについて説明する。なお、ここでは、ゲーム(具体的には、FPS)に本実施形態に係るシステム1を適用した場合を例に説明する。
【0161】
(関連付けに係る処理)
システム1を利用する所定のユーザとしての第1ユーザに、第2ユーザを自動で関連付ける処理について、図7を参照しながら説明する。
【0162】
まず、サーバ20の関連付け部216は、第1ユーザと体験を共有しているユーザを特定する(ステップS101)。具体的には、関連付け部216は、例えば、第1ユーザと同じ試合に参加しているユーザを特定する。
【0163】
次いで、関連付け部216は、第1ユーザと同じ試合に参加しているユーザの中に、第1ユーザに自動で関連付けるための登録条件を満たすユーザがいるか否かを判定する(ステップS102)。ここでは、当該登録条件は、第1ユーザが自身の端末装置10から予め入力し、登録条件記憶部としてのサーバ20の記憶部220に記憶されているものとする。また、ここでは、第1ユーザが入力し設定した当該登録条件は、「1試合の間に3回以上蘇生してくれた」というものであることとする。
【0164】
関連付け部216は、第1ユーザと同じ試合に参加しているユーザの中に、当該登録条件を満たすユーザがいない場合(ステップS102でNO)、第1ユーザに対して他のユーザを自動で関連付ける処理を行わない。具体的には、1試合が終了するまでの間に第1ユーザのことを3回以上蘇生してくれたユーザである第2ユーザがいない場合、関連付け部216は、第1ユーザに対して他のユーザを自動で関連付ける処理を行わない。
【0165】
一方、関連付け部216は、第1ユーザと同じ試合に参加しているユーザの中に、当該登録条件を満たすユーザがいる場合(ステップS102でYES)、第1ユーザに対して他のユーザを関連付けるための所定の処理を自動で行う。具体的には、1試合が終了するまでの間に第1ユーザのことを3回以上蘇生してくれたユーザである第2ユーザがいる場合(ステップS102でYES)、関連付け部216は、第2ユーザに対して、第1ユーザからのフレンド登録の申請を行う(ステップS103)。このとき、関連付け部216は、第1ユーザによる入力操作を要さずに当該申請を自動で行う。具体的には、関連付け部216は、第2ユーザの端末装置10に対して、フレンド登録の申請に係るデータを送信する(ステップS103)。第2ユーザの端末装置10の送受信部112が当該データを受信すると、第2ユーザの端末装置10の表示制御部114は、第1ユーザからのフレンド登録の申請に対する回答を促す画面(以下、「承諾画面」という。)を表示部18に表示させる(ステップS104)。承諾画面においては、第1ユーザからのフレンド登録の申請を承諾するか否か、第2ユーザに確認する表示がされる。換言すると、承諾画面の表示中においては、第2ユーザの端末装置10の操作受付部111は、フレンド登録の申請に対する回答に係る操作としての、フレンド登録の申請を承諾する操作および拒否する操作を受け付ける。
【0166】
第2ユーザの端末装置10において、フレンド登録の申請を承諾する操作または拒否する操作が受け付けられると、フレンド登録の申請を承諾するか否かを示すデータ(換言すると、フレンド登録の申請に対する回答)が端末装置10の送受信部112から関連付け部216に送られる(ステップS105)。
【0167】
関連付け部216は、第2ユーザの端末装置10から送られる、フレンド登録の申請を承諾するか否かを示すデータを受け取ると、当該データに基づいて、フレンド登録の申請が承諾されたか否かを判定する(ステップS106)。すなわち、第2ユーザが、フレンド登録の申請を承諾する操作を行った場合には、フレンド登録の申請が承諾されたと判定する(ステップS106でYES)。一方、第2ユーザが、フレンド登録の申請を拒否する操作を行った場合には、フレンド登録の申請が拒否されたと判定する(ステップS106でNO)。フレンド登録の申請が拒否されたと判定した場合(ステップS106でNO)、関連付け部216は、第1ユーザに対する第2ユーザの関連付けを行わない。
【0168】
フレンド登録の申請が承諾されたと判定した場合(ステップS106でYES)、関連付け部216は、第1ユーザと第2ユーザとを互いに関連付ける(ステップS107)。換言すると、フレンド登録の申請が承諾されたと判定した場合、関連付け部216は、第2ユーザを第1ユーザのフレンドとして登録する。さらに換言すると、フレンド登録の申請が承諾されたと判定した場合、関連付け部216は、第2ユーザが第1ユーザのフレンドであることを示す情報を記憶部220に記憶させる。
【0169】
また、関連付け部216は、第1ユーザと第2ユーザとを互いに関連付けると、第1ユーザの端末装置10に対して、第2ユーザを第1ユーザのフレンドとして登録したことを示すデータを送信する(ステップS108)。換言すると、サーバ20は、第2ユーザを第1ユーザのフレンドとして登録したことを、第1ユーザの端末装置10に対して知らせる。第1ユーザの端末装置10の送受信部112が当該データを受信すると、第1ユーザの端末装置10の表示制御部114は、第2ユーザを第1ユーザのフレンドとして登録したことを第1ユーザに対して報知する登録報知画面を表示部18に表示させる(ステップS109)。
【0170】
なお、第2ユーザの端末装置10では、他のユーザからのフレンド登録の申請があった場合に、当該申請を受信するか否か(換言すると、承諾画面を表示させるか否か)を予め設定しておくことが可能となっていてもよい。また、当該申請の受信を拒否する設定がされている場合、関連付け部216は、フレンド登録の申請が拒否されたと判定(ステップS106でNO)してもよい。また、例えば、第2ユーザの端末装置10では、フレンドになりたいユーザの条件を規定するホワイトリストの設定、あるいはフレンドになりたくないユーザの条件を規定するブラックリストの設定等が可能となっていてもよい。そして、ホワイトリストに設定されている条件を満たすユーザからの申請については受信をするようにしてもよい。また、ブラックリストに設定されている条件を満たすユーザからの申請については受信を拒否するようにしてもよい。
【0171】
なお、ここでは、関連付け部216は、登録条件を満たす場合にフレンド登録の申請を行うものとして説明したが、フレンド申請に代えてフォローの申請をしてもよい。また、例えば、登録条件を満たす場合に、申請を行わずに、フレンド登録あるいはフォローを自動で行ってもよい。換言すると、例えば、ステップS102でYESの場合に、ステップS103~ステップS106の処理を介さずに、ステップS107の処理を行う構成等としてもよい。
【0172】
(関連付けの解除に係る処理)
次に、第1ユーザに関連付けられた関連ユーザについて、第1ユーザへの関連付けを自動で解除する処理について、図8を参照しながら説明する。
【0173】
まず、サーバ20の解除部217は、第1ユーザに関連付けられた関連ユーザの中に、解除条件を満たす関連ユーザがいるか否かを判定する(ステップS201)。ここでは、当該解除条件は、第1ユーザが自身の端末装置10から予め入力し、解除条件記憶部としてのサーバ20の記憶部220に記憶されているものとする。
【0174】
解除条件を満たす関連ユーザがいる場合(ステップS201でYES)、解除部217は、当該関連ユーザを解除ユーザとして特定し、特定した解除ユーザを知らせるデータを第1ユーザの端末装置10に送信する(ステップS202)。第1ユーザの端末装置10の送受信部112が当該データを受信すると、第1ユーザの端末装置10の表示制御部114は、解除ユーザとの関連付けを解除するか否かについての回答を促す解除確認画面を表示部18に表示させる(ステップS203)。解除確認画面の表示中においては、第1ユーザの端末装置10の操作受付部111は、解除ユーザとの関連付けの解除を承諾する操作および拒否する操作を受け付ける。
【0175】
第1ユーザの端末装置10において、解除ユーザとの関連付けの解除を承諾する操作または拒否する操作が受け付けられると、解除ユーザとの関連付けの解除を承諾するか否かを示すデータ(換言すると、解除ユーザとの関連付けの解除についての回答)が端末装置10の送受信部112から解除部217に送られる(ステップS204)。
【0176】
解除部217は、第1ユーザの端末装置10から送られる、解除ユーザとの関連付けの解除を承諾するか否かを示すデータを受け取ると、当該データに基づいて、解除ユーザとの関連付けの解除が承諾されたか否かを判定する(ステップS205)。すなわち、第1ユーザが、解除を承諾する操作を行った場合には、解除ユーザとの関連付けの解除が承諾されたと判定する(ステップS205でYES)。一方、第1ユーザが、解除を拒否する操作を行った場合には、解除ユーザとの関連付けの解除が拒否されたと判定する(ステップS205でNO)。解除が拒否されたと判定した場合(ステップS205でNO)、解除部217は、解除ユーザの第1ユーザへの関連付けを解除しない。
【0177】
解除ユーザとの関連付けの解除が承諾されたと判定した場合(ステップS205でYES)、解除部217は、第1ユーザへの解除ユーザの関連付けを解除する(ステップS206)。
【0178】
(経緯情報の入力に係る処理)
次に、第1ユーザに関連付けられた関連ユーザとしての第2ユーザについての経緯情報51を入力する処理について、図9を参照しながら説明する。
【0179】
まず、経緯情報管理部219は、経緯情報入力画面60に表示させるタグ61を決定する(ステップS301)。ここでは、経緯情報管理部219は、第1ユーザに第2ユーザを関連付けるきっかけとなった試合(換言すると、第2ユーザが第1ユーザが設定した登録条件(ここでは当該登録条件は「1試合の間に3回以上蘇生してくれた」とする。)を満たした試合)での出来事に基づいて、経緯情報入力画面60に表示させるタグ61を決定する。具体的には、例えば、経緯情報管理部219は、この試合において、第2ユーザのキャラクタが第1ユーザのキャラクタを蘇生してくれたことに基づいて、「蘇生してくれた」というタグ61を表示させるタグ61に決定する。また、例えば、この試合において、第2ユーザのキャラクタが第1ユーザのキャラクタが攻撃している相手を一緒に攻撃してくれた場合、「アシスト攻撃してくれた」というタグ61を表示させるタグ61に決定する。また、例えば、この試合において第1ユーザと第2ユーザとが共闘して勝利した場合、「共闘した」というタグ61および「勝利した」というタグ61を表示させるタグ61に決定する。なお、ステップS301の処理については、試合において起こり得る出来事と、表示させるタグ61と、の対応関係を示すテーブルが記憶部220に記憶されており、経緯情報管理部219は、当該テーブルを用いて、試合で実際に起こった出来事に対応するタグ61を抽出し、経緯情報入力画面60に表示させるタグ61として決定することとしてもよい。
【0180】
次いで、経緯情報管理部219は、表示させるタグ61についての情報を含む、経緯情報入力画面60の表示に必要な情報を第1ユーザの端末装置10に送信する(ステップS302)。
【0181】
第1ユーザの端末装置10の送受信部112が当該情報を受信すると、第1ユーザの端末装置10の表示制御部114は、経緯情報入力画面60を表示させる(ステップS303)。この経緯情報入力画面60には、ステップS301において表示させることが決定されたタグ61が表示される。
【0182】
次いで、第1ユーザの端末装置10の操作受付部111は、経緯情報入力画面60に表示されるタグ61のうち、第2ユーザについての経緯情報51として付すタグ61を選択する入力操作を受け付ける(ステップS304)。換言すると経緯情報入力画面60の表示中は、経緯情報51を入力する入力操作が受け付けられる。
【0183】
第1ユーザの端末装置10において、タグ61を選択する入力操作が受け付けられると、選択されたタグ61を示すデータ(換言すると入力された経緯情報に関するデータ)が端末装置10の送受信部112から関連ユーザ管理部215に送られる(ステップS305)。
【0184】
経緯情報管理部219は、選択されたタグ61を示すデータを受信すると、選択されたタグ61を、第2ユーザの経緯情報51として第2ユーザに付して記憶部220に記憶させる(ステップS306)。換言すると、経緯情報管理部219は、端末装置10での入力操作に基づいて、第2ユーザの経緯情報51を登録する。
【0185】
なお、ここで、選択されるタグ61は1つであってもよく、複数であってもよい。
【0186】
(分類リストの表示に係る処理)
次に、第1ユーザに関連付けられた複数の関連ユーザを、関連ユーザの属性に応じて分類した分類リストの作成および表示に係る処理について、図10を参照しながら説明する。
【0187】
まず、リスト作成部218は、第1ユーザに関連付けられている複数の関連ユーザを、関連ユーザの属性毎に分類し、分類リストを作成する(ステップS401)。具体的には、リスト作成部218は、各関連ユーザのユーザ情報223を参照して関連ユーザを分類し、分類リストを作成する。リスト作成部218は、例えば、使用するキャラクタが攻撃が得意なキャラクタである関連ユーザを、攻撃が得意な関連ユーザに分類し、攻撃が得意な関連ユーザをまとめた分類リストを作成する。また、リスト作成部218は、例えば、使用するキャラクタが回復が得意なキャラクタである関連ユーザを、回復が得意な関連ユーザに分類し、回復が得意な関連ユーザをまとめた分類リストを作成する。
【0188】
また、リスト作成部218は、作成した複数の分類リストを分類リスト記憶部としての記憶部220に記憶させる(ステップS402)。
【0189】
分類リストの表示にあたっては、まず、第1ユーザの端末装置10は、分類リストの送信をサーバ20に要求する(ステップS403)。また、関連ユーザ管理部215は、当該要求に基づいて、分類リストを第1ユーザの端末装置10に送信する(ステップS404)。ここでは、攻撃が得意な関連ユーザの分類リストと、回復が得意な関連ユーザの分類リストが送信されるものとする。
【0190】
次いで、第1ユーザの端末装置10の表示制御部114は、表示させる分類リストの選択(例えば、攻撃が得意な関連ユーザの分類リストと、回復が得意な関連ユーザの分類リストとのどちらを表示させるかの選択)を促す画面(例えば、図5に示す分類リスト表示画面70)を表示部18に表示させる(ステップS405)。また、当該画面の表示中においては、操作受付部111は、表示させる分類リストを選択する入力操作を受け付ける。
【0191】
表示させる分類リストを選択する入力操作がされると、表示制御部114は、選択された分類リストを表示部18に表示させる(ステップS406)。
【0192】
なお、リスト作成部218は、端末装置10が有していてもよい。また、分類リストを記憶する分類リスト記憶部(例えば、記憶部120)は端末装置10が有していてもよい。この場合、表示制御部114は、端末装置10に記憶されている複数の分類リストのうち、ユーザが選択した分類リスト(ステップS405,S406)を表示部18に表示させてもよい。
【0193】
(分類リストの表示に係る処理の変形例)
次に、第1ユーザに関連付けられた複数の関連ユーザを、関連ユーザの属性に応じて分類した分類リストの作成および表示に係る処理の変形例について、図11を参照しながら説明する。
【0194】
まず、第1ユーザの端末装置10の表示制御部114は、シチュエーション(例えば、第1ユーザが行おうとするゲームのシチュエーション)の選択を促す画面を表示部18に表示させる(ステップS501)。また、当該画面の表示中においては、操作受付部111は、シチュエーションを選択する入力操作を受け付ける。具体的には、操作受付部111は、当該シチュエーションとしてのステージ(換言するとマップ)を選択する入力操作を受け付ける。
【0195】
次いで、第1ユーザの端末装置10は、選択されたシチュエーション(具体的にはステージ)に適した分類リストの送信をサーバ20に要求する(ステップS502)。また、関連ユーザ管理部215は、当該要求に基づいて、選択されたシチュエーションに適した属性を有する関連ユーザの分類リストを第1ユーザの端末装置10に送信する(ステップS503)。具体的には、例えば、第1ユーザが、第1ステージおよび第2ステージを含む複数のステージの中から第1ステージを選択する入力操作を行った場合、関連ユーザ管理部215は、第1ユーザに関連付けられた複数の関連ユーザのうち、第1ステージでの過去の対戦での勝率が高い関連ユーザをまとめた分類リストを第1ユーザの端末装置10に送信する。なお、ここで関連ユーザ管理部215から端末装置10に送信される分類リストは、当該要求に基づいてリスト作成部218が作成するものであってもよく、予めリスト作成部218が作成し記憶部220に記憶されている複数の分類リストの中から当該要求に基づいて抽出されるものであってもよい。なお、リスト作成部218は、端末装置10が有していてもよい。また、分類リストを記憶する分類リスト記憶部(例えば、記憶部120)は端末装置10が有していてもよい。
【0196】
次いで、第1ユーザの端末装置10の表示制御部114は、サーバ20から送信された、選択されたシチュエーションに適した属性を有する関連ユーザの分類リストを表示部18に表示させる(ステップS504)。
【0197】
なお、本発明は、上述した実施形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変形して実施できる。本発明はその発明の範囲内において、各構成要素の自由な組み合わせ、任意の構成要素の変形、または任意の構成要素の省略等が可能である。また、本明細書において説明した処理の流れはあくまで一例であり、各処理の順序や構成は異なるものであってもよい。
【0198】
<付記>
以上の実施形態で説明した事項は、以下の付記のようにも記載され得る。
【0199】
(付記1)
コンピュータを、
所定のサービス内で第1ユーザと所定の体験を共有決定後、共有中、または共有後の第2ユーザと、前記第1ユーザと、を自動的に互いに関連付ける関連付け手段(例えば、関連付け部216)として機能させる
プログラム。
このような構成によれば、ゲーム等の所定のサービスにおいて他のユーザとフレンドとなる際に通常必要となる、相手方へフレンド登録の申請をする操作や、相手方での当該申請に対する承諾をする操作等が不要となる。したがって、フレンドが作りやすくなる。
【0200】
(付記2)
前記第2ユーザは、前記所定のサービス内の所定のコンテンツを前記第1ユーザと一緒に利用すること決定後、利用中、または利用後のユーザである
付記1に記載のプログラム。
このような構成によれば、一緒にコンテンツを利用した他のユーザと容易にフレンドとなることができ、再び一緒にコンテンツを利用すること等が可能となる。
【0201】
(付記3)
コンピュータを、
所定のサービス内で第1ユーザと所定の体験を共有決定後、共有中、または共有後の第2ユーザと、前記第1ユーザと、を互いに関連付ける処理を、前記第1ユーザによる当該関連付けを指示する操作、および前記第2ユーザによる当該関連付けを指示する操作を介さずに行う関連付け手段(例えば、関連付け部216)として機能させる
プログラム。
このような構成によれば、ゲーム等の所定のサービスにおいて他のユーザとフレンドとなる際に通常必要となる、関連付けを指示する操作が不要となる。したがって、フレンドが作りやすくなる。
【0202】
(付記4)
前記第2ユーザと前記第1ユーザとを互いに関連付けるとは、互いをフレンドとして登録することである
付記1~3のいずれか1つに記載のプログラム。
【0203】
(付記5)
前記フレンドとなっているユーザとの間では、前記フレンドとなっていないユーザとの間では使用できない前記所定のサービス内の所定の機能を使用可能な
付記4に記載のプログラム。
このような構成によれば、フレンドとなった場合に所定の機能が使用可能となる上、本構成はフレンドの作りやすい構成であるため、当該所定の機能を使用する機会を増やすことができる。
【0204】
(付記6)
前記第2ユーザは、前記所定のサービス内で前記第1ユーザと所定の関係性を有するユーザである
付記1~3のいずれか1つに記載のプログラム。
このような構成によれば、所定の体験を共有するユーザのうち、所定の関係性を有するユーザを自動でフレンドとして登録することが可能となり、自動でフレンドとなるユーザに制限を加えることが可能となる。
【0205】
(付記7)
前記所定の関係性は、前記第1ユーザが設定した、他のユーザと前記第1ユーザとを自動的に互いに関連付けるための条件を満たす関係性である
付記6に記載のプログラム。
このような構成によれば、各ユーザは、自動でフレンドとして登録したいユーザの条件を設定することが可能となる。
【0206】
(付記8)
前記条件の設定に応じて決まる前記所定の関係性には、少なくとも一方のユーザの属性に基づいて決まる関係性が特定の関係性という関係性が含まれる
付記7に記載のプログラム。
このような構成によれば、各ユーザは、少なくとも一方のユーザの属性に基づいて決まる関係性が特定の関係性となる他のユーザについて自動でフレンドとして登録するように、自動でフレンドとして登録するユーザの条件を設定することが可能となる。
【0207】
(付記9)
前記条件の設定に応じて決まる前記所定の関係性には、一方のユーザに関する所定の属性と、他方のユーザに関する前記所定の属性とが共通するという関係性が含まれる
付記7に記載のプログラム。
このような構成によれば、各ユーザは、一方のユーザに関する所定の属性と、他方のユーザに関する前記所定の属性とが共通するという関係性を有する他のユーザについて自動でフレンドとして登録するように、自動でフレンドとして登録するユーザの条件を設定することが可能となる。したがって、所定の属性が共通するフレンドを増やすことが容易となる。
【0208】
(付記10)
前記条件の設定に応じて決まる前記所定の関係性には、一方のユーザの属性を、他方のユーザの属性が補完するという関係性が含まれる
付記7に記載のプログラム。
このような構成によれば、各ユーザは、一方のユーザの属性を、他方のユーザの属性が補完するという関係性を有する他のユーザについて自動でフレンドとして登録するように、自動でフレンドとして登録するユーザの条件を設定することが可能となる。したがって、自身の属性を補完する属性を有するフレンドを増やすことが容易となる。
【0209】
(付記11)
所定のサービス内で第1ユーザと所定の体験を共有決定後、共有中、または共有後の第2ユーザと、前記第1ユーザと、を自動的に互いに関連付ける関連付け手段(例えば、関連付け部216)を備える
情報処理装置。
このような構成によれば、付記1に記載のプログラムと同様の作用効果を奏することができる。
【符号の説明】
【0210】
1 システム、10 端末装置、11 プロセッサ、12 メモリ、13 ストレージ、16 タッチスクリーン、17 入力部、18 表示部、20 サーバ、21 プロセッサ、22 メモリ、23 ストレージ、50 関連ユーザリスト表示画面、51 経緯情報、60 経緯情報入力画面、61 タグ、70 分類リスト表示画面、75 ステージ選択画面、110 制御部、111 操作受付部、112 送受信部、113 進行部、114 表示制御部、120 記憶部、210 制御部、211 送受信部、212 サーバ処理部、214 同期処理部、215 関連ユーザ管理部、216関連付け部、217 解除部、218 リスト作成部、219 経緯情報管理部、220 記憶部
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11