WO2016136626A1

WO2016136626A1 - ユーザ管理サーバ、端末、情報表示システム、ユーザ管理方法、情報表示方法、プログラム及び情報記憶媒体

Info

Publication number: WO2016136626A1
Application number: PCT/JP2016/054889
Authority: WO
Inventors: 祐志中村; 史明久松; 亮斉藤; 壮志浦川; 達弥後藤
Original assignee: Sony Interactive Entertainment Inc; Sony Corp
Current assignee: Sony Interactive Entertainment Inc; Sony Corp
Priority date: 2015-02-27
Filing date: 2016-02-19
Publication date: 2016-09-01
Anticipated expiration: 2017-08-27
Also published as: US10905961B2; US20180043266A1; JP6474483B2; JPWO2016136626A1

Abstract

　実名を公開するユーザを登録する際のユーザの手間が従来技術よりも低減されるユーザ管理サーバ、端末、情報表示システム、ユーザ管理方法、情報表示方法、プログラム及び情報記憶媒体を提供する。フレンド管理データ登録部（７２）は、ユーザを指定する第１の操作に応じて、ユーザをニックネームが開示される第１の関係にあるユーザとして登録する。フレンド管理データ登録部（７２）は、第１の関係にあるユーザとして登録されているユーザを指定する第２の操作に応じて、ユーザをさらに実名も開示される第２の関係にあるユーザとして登録する。フレンド管理データ登録部（７２）は、第１の関係にあるユーザとして登録されていないユーザを指定する第３の操作に応じて、ユーザを第１の関係及び第２の関係にあるユーザとして登録する。

Description

ユーザ管理サーバ、端末、情報表示システム、ユーザ管理方法、情報表示方法、プログラム及び情報記憶媒体

　本発明は、ユーザ管理サーバ、端末、情報表示システム、ユーザ管理方法、情報表示方法、プログラム及び情報記憶媒体に関する。

　近年、複数のユーザがネットワークを介して互いにメッセージをやりとりしたり、一緒にゲームをプレイしたりすることのできるソーシャルネットワーク型のオンラインサービスが登場している（例えば特許文献１参照）。このようなサービスでは、他のユーザを自分のフレンド（友人）として登録することで、登録されたフレンドとコミュニケーションをとることができることとなる。

　上述したサービスでは、自分のフレンドとして登録されるユーザには、多様な関係性の人物が含まれうる。例えば、ネットワーク上で知り合っただけの人物と、実社会で元々知り合いである人物の双方がフレンドとして登録される場合がある。このような場合に、関係の強いユーザには実名を公開してもよいが、関係の薄いユーザには実名を公開したくない、など自分自身を他者が識別する名称そのものについても、相手との関係によって使い分けたいというニーズがある。このようなニーズを満たすため、特許文献１には、ユーザ間で公開される自身の名称を制御できる技術が開示されている。

国際公開第２０１４／１２８８３６号

　しかし特許文献１に記載の技術では、実名を公開するユーザを登録するためには、その登録操作の前に実名を公開しないフレンドとして当該ユーザを登録する操作を行う必要があり、ユーザは手間がかかっていた。

　本発明は上記実情に鑑みてなされたものであって、その目的の一つは、実名を公開するユーザを登録する際のユーザの手間が従来技術よりも低減されるユーザ管理サーバ、端末、情報表示システム、ユーザ管理方法、情報表示方法、プログラム及び情報記憶媒体を提供することにある。

　上記課題を解決するために、本発明に係るユーザ管理サーバは、ユーザを指定する第１の操作に応じて、当該ユーザをニックネームが開示される第１の関係にあるユーザとして登録する第１登録部と、前記第１の関係にあるユーザとして登録されているユーザを指定する第２の操作に応じて、当該ユーザをさらに実名も開示される第２の関係にあるユーザとして登録する第２登録部と、前記第１の関係にあるユーザとして登録されていないユーザを指定する第３の操作に応じて、当該ユーザを前記第１の関係及び前記第２の関係にあるユーザとして登録する第３登録部と、を含む。

　また、本発明に係る端末は、ユーザをニックネームが開示される第１の関係にあるユーザとして指定する第１の操作を受け付ける第１受付部と、前記第１の操作によって指定されたユーザをさらに実名も開示される第２の関係にあるユーザとして指定する第２の操作を受け付ける第２受付部と、前記第１の操作によって指定されていないユーザを前記第１の関係及び前記第２の関係にあるユーザとして指定する第３の操作を受け付ける第３受付部と、前記第２の関係にあるユーザの実名が含まれる、前記第１の関係にあるユーザに関する情報の一覧を表示させる表示処理部と、を含む。

　また、本発明に係る情報表示システムは、ユーザを指定する第１の操作に応じて、当該ユーザをニックネームが開示される第１の関係にあるユーザとして登録する第１登録部と、前記第１の関係にあるユーザとして登録されているユーザを指定する第２の操作に応じて、当該ユーザをさらに実名も開示される第２の関係にあるユーザとして登録する第２登録部と、前記第１の関係にあるユーザとして登録されていないユーザを指定する第３の操作に応じて、当該ユーザを前記第１の関係及び前記第２の関係にあるユーザとして登録する第３登録部と、前記第２の関係にあるユーザとして登録されているユーザの実名が含まれる、前記第１の関係にあるユーザに関する情報の一覧を表示させる表示処理部と、を含む。

　また、本発明に係るユーザ管理方法は、ユーザを指定する第１の操作に応じて、当該ユーザをニックネームが開示される第１の関係にあるユーザとして登録するステップと、前記第１の関係にあるユーザとして登録されているユーザを指定する第２の操作に応じて、当該ユーザをさらに実名も開示される第２の関係にあるユーザとして登録するステップと、前記第１の関係にあるユーザとして登録されていないユーザを指定する第３の操作に応じて、当該ユーザを前記第１の関係及び前記第２の関係にあるユーザとして登録するステップと、を含む。

　また、本発明に係る情報表示方法は、ユーザをニックネームが開示される第１の関係にあるユーザとして指定する第１の操作を受け付けるステップと、前記第１の操作によって指定されたユーザをさらに実名も開示される第２の関係にあるユーザとして指定する第２の操作を受け付けるステップと、前記第１の操作によって指定されていないユーザを前記第１の関係及び前記第２の関係にあるユーザとして指定する第３の操作を受け付けるステップと、前記第２の関係にあるユーザの実名が含まれる、前記第１の関係にあるユーザに関する情報の一覧を表示させるステップと、を含む。

　また、本発明に係るプログラムは、ユーザをニックネームが開示される第１の関係にあるユーザとして指定する第１の操作を受け付ける手順、前記第１の操作によって指定されたユーザをさらに実名も開示される第２の関係にあるユーザとして指定する第２の操作を受け付ける手順、前記第１の操作によって指定されていないユーザを前記第１の関係及び前記第２の関係にあるユーザとして指定する第３の操作を受け付ける手順、前記第２の関係にあるユーザの実名が含まれる、前記第１の関係にあるユーザに関する情報の一覧を表示させる手順、をコンピュータに実行させる。

　なお上述のプログラムは、コンピュータ読み取り可能な情報記憶媒体に記憶されてもよい。

　本発明の一態様では、前記第３登録部は、実名が表示されているユーザを指定する操作に応じて、当該ユーザを前記第１の関係及び前記第２の関係にあるユーザとして登録する。

　また、本発明の一態様では、前記第１登録部は、前記第１の関係にあるユーザの候補に関する情報の一覧において実名が表示されていないユーザを指定する操作に応じて、当該ユーザを前記第１の関係にあるユーザとして登録し、前記第３登録部は、前記候補に関する情報の一覧において実名が表示されているユーザを指定する操作に応じて、当該ユーザを前記第１の関係及び前記第２の関係にあるユーザとして登録する。

本発明の一実施形態に係る情報処理システムの全体構成の一例を示す図である。ユーザ管理データの一例を示す図である。フレンド管理データの一例を示す図である。検索ページの一例を示す図である。プロファイルページの一例を示す図である。フレンドリクエスト送信ページの一例を示す図である。通知ページの一例を示す図である。リクエスト一覧ページの一例を示す図である。フレンド管理データの一例を示す図である。フレンド一覧ページの一例を示す図である。プロファイルページの一例を示す図である。実名リクエスト送信ページの一例を示す図である。通知ページの一例を示す図である。リクエスト一覧ページの一例を示す図である。フレンド管理データの一例を示す図である。プロファイルページの一例を示す図である。親友リクエスト送信ページの一例を示す図である。通知ページの一例を示す図である。リクエスト一覧ページの一例を示す図である。フレンド管理データの一例を示す図である。ＦｏＦ（Friend of Friend）ページの一例を示す図である。ＹＭＫ（You May Know）ページの一例を示す図である。ＳＮＳ（Social Networking Service）フレンド発見ページの一例を示す図である。親友リクエスト送信ページの一例を示す図である。本発明の一実施形態に係る情報処理システムで実装される機能の一例を示す機能ブロック図である。関係リクエスト管理データの一例を示す図である。本実施形態に係る情報処理システムで行われる処理の流れの一例を示すフロー図である。本実施形態に係る情報処理システムで行われる処理の流れの一例を示すフロー図である。本実施形態に係る情報処理システムで行われる処理の流れの一例を示すフロー図である。関係リクエスト管理データの一例を示す図である。本実施形態に係る情報処理システムで行われる処理の流れの一例を示すフロー図である。

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

［構成］
　図１は、本発明の一実施形態に係る情報処理システム１の全体構成の一例を示す図である。図１に示すように、本実施形態に係る情報処理システム１は、いずれもコンピュータを中心に構成されたユーザ管理サーバ１０と複数のクライアント１２とを含んでいる。ユーザ管理サーバ１０、クライアント１２は、インターネットなどのコンピュータネットワーク１４に接続されている。そして、ユーザ管理サーバ１０、クライアント１２は、互いに通信可能になっている。

　本実施形態に係る情報処理システム１は、例えば複数のユーザが参加して一緒にプレイできるオンラインゲームサービスなどといった、複数のユーザに対するソーシャルネットワーク型のオンラインサービスを提供する。

　ユーザ管理サーバ１０は、本実施形態に係るオンラインサービスを利用するユーザに関する情報を管理するサーバコンピュータである。図１に示すように、本実施形態に係るユーザ管理サーバ１０は、例えば、制御部１０ａ、記憶部１０ｂ、通信部１０ｃ、を含む。制御部１０ａは、例えばＣＰＵ等のプログラム制御デバイスであって、記憶部１０ｂに記憶されたプログラムに従って各種の情報処理を実行する。記憶部１０ｂは、例えばＲＯＭやＲＡＭ等の記憶素子やハードディスクドライブなどである。通信部１０ｃは、例えばコンピュータネットワーク１４を介してクライアント１２との間でデータを授受するための通信インタフェースである。ユーザ管理サーバ１０は、通信部１０ｃを経由して各クライアント１２との間で情報の送受信を行う。

　クライアント１２は、本実施形態に係るオンラインサービスを利用する各ユーザが利用する情報処理端末であって、例えばパーソナルコンピュータ、ゲームコンソール、テレビ受像機、携帯型ゲーム装置、スマートフォン、タブレット端末、などである。図１に示すように、本実施形態に係るクライアント１２は、例えば、制御部１２ａ、記憶部１２ｂ、通信部１２ｃ、出力部１２ｄ、入力部１２ｅ、を含む。制御部１２ａは、例えばＣＰＵ等のプログラム制御デバイスであって、記憶部１２ｂに記憶されたプログラムに従って各種の情報処理を実行する。本実施形態に係る制御部１２ａには、ＣＰＵから供給されるグラフィックスコマンドやデータに基づいてフレームバッファに画像を描画するＧＰＵ（Graphics Processing Unit）も含まれている。記憶部１２ｂは、例えばＲＯＭやＲＡＭ等の記憶素子やハードディスクドライブなどである。記憶部１２ｂには、制御部１２ａによって実行されるプログラムなどが記憶される。また、本実施形態に係る記憶部１２ｂには、ＧＰＵにより画像が描画されるフレームバッファの領域が確保されている。通信部１２ｃは、例えばコンピュータネットワーク１４を介してユーザ管理サーバ１０との間でデータを授受するための通信インタフェースである。クライアント１２は、通信部１２ｃを経由してユーザ管理サーバ１０や他のクライアント１２との間で情報の送受信を行う。出力部１２ｄは、例えば制御部１２ａから入力される指示に従って情報を表示出力するディスプレイや音声出力するスピーカ等である。入力部１２ｅは、例えばユーザが行った操作の内容を制御部１２ａに出力するゲームコントローラ、タッチパッド、マウス、キーボード、マイク等である。

［ユーザ管理データ］
　本実施形態では、ユーザ管理サーバ１０においてユーザやユーザ間の関係に関する情報が管理される。図２は、本実施形態に係るオンラインサービスを利用するユーザに関する情報を管理するためのユーザ管理データの一例を示す図である。本実施形態では例えば、ユーザが本実施形態に係るオンラインサービスの利用を開始する際に当該ユーザによって当該ユーザのユーザ管理データが登録されるようになっている。

　図２に示すように、本実施形態に係るユーザ管理データには、例えば、ユーザＩＤ、実名データ、アイコンファイル名データ、写真画像ファイル名データ、端末ＩＤ、実名公開ページＩＤ、が含まれている。

　ユーザ管理データに含まれるユーザＩＤは、当該オンラインサービスを利用するユーザを一意に識別する識別名称である。本実施形態に係るオンラインサービスでは、当該オンラインサービスを利用するユーザは、当該ユーザのニックネームをユーザＩＤとして登録することが想定されている。そのため本実施形態では、ユーザ管理データと当該オンラインサービスを利用するユーザとは１対１で対応付けられることとなる。

　ユーザ管理データに含まれる実名データは、当該ユーザ管理データに対応付けられるユーザによって登録された名称を示すデータである。本実施形態に係るオンラインサービスでは、当該オンラインサービスを利用するユーザは、当該ユーザの実名を実名データの値として登録することが想定されている。なおクライアント１２によっては実名を登録する機能を有さないものがある。このようなクライアント１２を利用するユーザについては、図２に示されている、ユーザＩＤが「ｉｉｉ０１０」であるユーザ管理データのように、実名データの値は登録されないこととなる。

　ユーザ管理データに含まれるアイコンファイル名データは、当該ユーザ管理データに対応付けられるユーザの第１のプロファイル画像であるアイコン画像Ｉ１（図４等参照）のファイル名を示すデータである。アイコン画像Ｉ１は例えば情報処理システム１において予め用意されたアイコンの画像などである。

　ユーザ管理データに含まれる写真画像ファイル名データは、当該ユーザ管理データに対応付けられるユーザの第２のプロファイル画像である写真画像Ｉ２（図４等参照）のファイル名を示すデータである。写真画像Ｉ２は、ユーザがアップロードして登録した画像であって、ユーザ自身を撮影した写真であることが想定されている。

　ユーザ管理データに含まれる端末ＩＤは、当該ユーザ管理データに対応付けられるユーザが利用するクライアント１２を識別する識別情報である。図２に示すように、本実施形態では、１のユーザが、１のクライアント１２を利用する場合も複数のクライアント１２（例えばゲームコンソール及びスマートフォン）を利用する場合も想定されている。

　ユーザ管理データに含まれる実名公開ページＩＤは、当該ユーザ管理データに対応付けられるユーザが、当該ユーザ管理データに含まれる実名データが示す名称をすべてのユーザに公開することを許可するページを識別する識別情報である。本実施形態では、実名公開ページＩＤによって識別されるページでは、当該ユーザの実名データが示す名称は、すべてのユーザが閲覧可能となる。図２に示すように本実施形態では複数の実名公開ページＩＤを設定することができるようになっている。

　例えば、ユーザ管理データに含まれる実名公開ページＩＤに「１」が設定されていることとする。この場合は、本実施形態では例えば、当該ユーザ管理データに対応付けられるユーザの実名データが示す名称は、後述する検索ページ２０（図４参照）ですべてのユーザが閲覧可能となる。また当該ユーザの実名データの値は、検索ページ２０におけるユーザの検索での検索結果になり得ることとなる。

　また例えば、ユーザ管理データに含まれる実名公開ページＩＤに「２」が設定されていることとする。この場合は、本実施形態では例えば、当該ユーザ管理データに対応付けられるユーザの実名データが示す名称は、後述するＦｏＦ（Friend of Friend）ページ３６（図２１参照）ですべてのユーザが閲覧可能となる。

　また例えば、ユーザ管理データに含まれる実名公開ページＩＤに「３」が設定されていることとする。この場合は、本実施形態では例えば、当該ユーザ管理データに対応付けられるユーザの実名データが示す名称は、後述するＹＭＫ（You May Know）ページ３８（図２２参照）ですべてのユーザが閲覧可能となる。

　また例えば、ユーザ管理データに含まれる実名公開ページＩＤに「４」が設定されていることとする。この場合は、本実施形態では例えば、当該ユーザ管理データに対応付けられるユーザの実名データが示す名称は、後述るＳＮＳ（Social Networking Service）フレンド発見ページ４０（図２３参照）ですべてのユーザが閲覧可能となる。

［フレンド管理データ］
　また本実施形態では、ユーザ管理データが登録されているユーザは、他のユーザをフレンド（友人）として登録できるようになっている。本実施形態では、ユーザによって登録されたフレンドは、図３に示すフレンド管理データによって管理されることとなる。

　図３に示すように、本実施形態に係るフレンド管理データには、例えば、ユーザＩＤ、フレンドユーザＩＤ、実名公開ユーザＩＤ、が含まれる。

　フレンド管理データに含まれるユーザＩＤは、当該オンラインサービスを利用するユーザを一意に識別する識別名称である。そのため本実施形態では、フレンド管理データと当該オンラインサービスを利用するユーザとは１対１で対応付けられることとなる。また本実施形態では、ユーザ管理データに含まれるユーザＩＤとフレンド管理データに含まれるユーザＩＤによってユーザ管理データとフレンド管理データとは関連付けられることとなる。

　フレンド管理データに含まれるフレンドユーザＩＤは、当該フレンド管理データに含まれるユーザＩＤによって識別されるユーザによってフレンドとして登録されたユーザのユーザＩＤである。以下、フレンド管理データにおいてフレンドとして登録されたユーザを、フレンドユーザと呼ぶこととする。図３に示すように本実施形態では、複数のユーザＩＤをフレンドユーザＩＤとして登録できるようになっている。

　フレンド管理データに含まれる実名公開ユーザＩＤは、当該フレンド管理データに含まれるユーザＩＤによって識別されるユーザによって実名データが示す名称を互いに公開するユーザとして登録されたユーザのユーザＩＤである。以下、フレンド管理データにおいて実名データが示す名称を互いに公開するユーザとして登録されたユーザを、実名公開ユーザと呼ぶこととする。本実施形態では、ユーザと、当該ユーザの実名公開ユーザとの間では、上述した実名公開ページＩＤにより識別されるページであるか否かを問わず実名データが示す名称が互いに公開されることとなる。図３に示すように本実施形態では、複数のユーザＩＤを実名公開ユーザＩＤとして登録できるようになっている。また本実施形態では、実名公開ユーザは、フレンドユーザとして必ず登録されていることとする。すなわちフレンド管理データにおいて実名公開ユーザＩＤとして登録されているユーザＩＤは、必ずフレンドユーザＩＤとしても登録されていることとする。

　なお本実施形態に係るユーザ管理データやフレンド管理データは、ユーザ管理サーバ１０の記憶部１０ｂに記憶される。

［関係リクエストの概要］
　本実施形態では、ユーザは、当該ユーザのフレンドユーザではないユーザに対して、フレンドとしての登録の申込を行えるようになっている。そして、フレンドとしての登録の申込を受けたユーザが当該申込を承諾した場合には、申込を行ったユーザと承諾を行ったユーザとは互いにフレンドユーザとして関連付けられることとなる。本実施形態では例えば、申込を行ったユーザのフレンド管理データのフレンドユーザＩＤとして、承諾を行ったユーザのユーザＩＤが登録される。また、承諾を行ったユーザのフレンド管理データのフレンドユーザＩＤとして、申込を行ったユーザのユーザＩＤが登録される。

　また本実施形態では、ユーザは、当該ユーザのフレンドユーザではあるが実名公開ユーザではないユーザに対して、実名公開の申込を行えるようになっている。実名公開の申込を受けたユーザが当該申込を承諾した場合には、申込を行ったユーザと承諾を行ったユーザとは互いに実名公開ユーザとして関連付けられることとなる。本実施形態では例えば、申込を行ったユーザのフレンド管理データの実名公開ユーザＩＤとして、承諾を行ったユーザのユーザＩＤが登録される。また、承諾を行ったユーザのフレンド管理データの実名公開ユーザＩＤとして、申込を行ったユーザのユーザＩＤが登録される。

　また本実施形態では、ユーザは、当該ユーザのフレンドユーザではないユーザに対して、親友としての登録の申込を行えるようになっている。親友としての登録の申込を受けたユーザが当該申込を承諾した場合には、申込を行ったユーザと承諾を行ったユーザとは互いにフレンドユーザとして関連付けられるとともに実名公開ユーザとしても関連付けられる。本実施形態では例えば、申込を行ったユーザのフレンド管理データのフレンドユーザＩＤ及び実名公開ユーザＩＤとして、承諾を行ったユーザのユーザＩＤが登録される。また、承諾を行ったユーザのフレンド管理データのフレンドユーザＩＤ及び実名公開ユーザＩＤとして、申込を行ったユーザのユーザＩＤが登録される。

　このように本実施形態に係るフレンド管理データにおいては、実名公開の申込と承諾が行われたユーザ間の関係と親友としての登録の申込と承諾が行われたユーザ間の関係とは同等に取り扱われることとなる。

　以下、フレンドとしての登録の申込、実名公開の申込、又は、親友としての登録の申込を行うユーザを申込ユーザと呼び、当該申込を承諾するユーザを承諾ユーザと呼ぶこととする。そして本実施形態では、申込ユーザがフレンドとしての登録の申込操作を行った場合に、申込ユーザのクライアント１２から承諾ユーザのクライアント１２に宛ててリクエストが送信される。以下、当該リクエストをフレンドリクエストと呼ぶこととする。また本実施形態では、申込ユーザが実名公開の申込操作を行った場合に、申込ユーザのクライアント１２から承諾ユーザのクライアント１２に宛ててリクエストが送信される。以下、当該リクエストを実名リクエストと呼ぶこととする。また本実施形態では、申込ユーザが親友としての登録の申込操作を行った場合に、申込ユーザのクライアント１２から承諾ユーザのクライアント１２に宛ててリクエストが送信される。以下、当該リクエストを親友リクエストと呼ぶこととする。そして、フレンドリクエスト、実名リクエスト、親友リクエストを総称して、以下、関係リクエストと呼ぶこととする。

［フレンドとしての登録の申込と承諾］
　ここで、ユーザＩＤが「ａａａ００１」であるユーザが申込ユーザであり、ユーザＩＤが「ｇｅｏ００７」であるユーザが承諾ユーザである場合における、フレンドとしての登録の申込と承諾の一例について説明する。なお、当該申込及び当該承諾が行われる前においては、図３に例示するフレンド管理データがユーザ管理サーバ１０の記憶部１０ｂに記憶されていることとする。

　図４は、申込ユーザが利用するクライアント１２のディスプレイに表示される検索ページ２０の一例を示す図である。当該検索ページ２０では、オンスクリーンキーボードＫを介して検索条件となる文字列を検索条件入力フォームＦ１に入力できるようになっている。そして検索条件である文字列が入力されると、ユーザＩＤが示す文字列が検索条件である文字列と部分一致又は完全一致するユーザに関する情報が検索結果情報ＲＩとして検索ページ２０内に配置される。このようにして本実施形態では、検索ページ２０には検索結果情報ＲＩの一覧が配置されることとなる。

　また本実施形態では、実名公開ユーザ、及び、ユーザ管理データに含まれる実名公開ページＩＤに「１」が設定されているユーザについては、ユーザＩＤに加え、実名データが示す名称も検索対象となる。そのためこのようなユーザについては、実名データが示す文字列が検索条件である文字列と部分一致又は完全一致する場合についても、当該ユーザに関する情報が検索結果情報ＲＩとして検索ページ２０内に配置されることとなる。

　本実施形態では、実名データが示す名称が検索対象とならないユーザについては、検索結果情報ＲＩａとして、当該ユーザのユーザＩＤを表す文字列Ｓ１、及び、アイコン画像Ｉ１が配置される。また本実施形態では、実名データが示す名称も検索対象となるユーザについては、検索結果情報ＲＩｂとして、当該ユーザのユーザＩＤを表す文字列Ｓ１、当該ユーザの実名データが示す名称を表す文字列Ｓ２、及び、写真画像Ｉ２が配置される。

　本実施形態では、申込ユーザは、検索ページ２０に配置されたカーソルＣを移動させる操作を行うことにより、検索結果情報ＲＩの選択を行えるようになっている。本実施形態では、図４に示すように、選択対象である検索結果情報ＲＩの周囲にはカーソルＣが表示される。ここで申込ユーザが所定の決定操作を行うと、カーソルＣによって囲まれている検索結果情報ＲＩが選択された検索結果情報ＲＩとして決定される。ここでは例えばユーザＩＤが「ｇｅｏ００７」である承諾ユーザの検索結果情報ＲＩａが選択されたこととする。すると、選択された検索結果情報ＲＩａに対応付けられるユーザのプロファイル情報が配置された、図５に例示するプロファイルページ２２が、申込ユーザが利用するクライアント１２のディスプレイに表示される。

　本実施形態では、実名データが示す名称を表す文字列Ｓ２が配置されていない検索結果情報ＲＩａが選択された場合には、当該検索結果情報ＲＩａに配置されている文字列Ｓ１及びアイコン画像Ｉ１が配置されたプロファイルページ２２が表示される。そのため、図５に例示するプロファイルページ２２には、選択された検索結果情報ＲＩａに対応付けられるユーザのユーザＩＤを表す文字列Ｓ１及びアイコン画像Ｉ１が配置されることとなる。

　また本実施形態では、選択された検索結果情報ＲＩａに文字列Ｓ２が配置されておらず、また当該検索結果情報ＲＩａに対応付けられるユーザがフレンドユーザではない場合には、フレンドリクエストボタンＢ１が配置されたプロファイルページ２２が表示される。そのため、図５に例示するプロファイルページ２２には、フレンドリクエストボタンＢ１が配置されることとなる。

　以上で説明したように、本実施形態では、ユーザ管理データに含まれる実名公開ページＩＤの設定によって、当該ユーザの実名データが示す名称をすべてのユーザに検索対象として公開するか否かが制御できることとなる。また実名公開ページＩＤの設定によって、当該ユーザの写真画像Ｉ２をすべてのユーザに公開するか否かも制御できることとなる。

　またユーザは、当該ユーザの実名公開ユーザのユーザＩＤを覚えていなくても実名は覚えているものと思われる。本実施形態では、実名公開ユーザについては実名データが示す名称によるユーザの検索が可能であるので、ユーザは、実名公開ユーザの検索を容易に行えることとなる。また実名公開ユーザについては写真画像Ｉ２が検索結果情報ＲＩｂとして配置されるので、検索結果情報ＲＩの一覧のなかから所望の実名公開ユーザを見つけることが容易となる。

　図５に例示するプロファイルページ２２が表示されている際に申込ユーザがフレンドリクエストボタンＢ１を選択する操作を行うと、図６に例示するフレンドリクエスト送信ページ２４が、申込ユーザが利用するクライアント１２のディスプレイに表示される。図６に例示するフレンドリクエスト送信ページ２４には、選択された検索結果情報ＲＩａに対応付けられるユーザのユーザＩＤを表す文字列Ｓ１、及び、アイコン画像Ｉ１が配置される。また当該フレンドリクエスト送信ページ２４には、メッセージ入力フォームＦ２、及び、送信ボタンＢ２も配置される。メッセージ入力フォームＦ２には、デフォルトのメッセージが予め入力されており、ユーザは当該メッセージを編集することができるようになっている。

　ここで申込ユーザが送信ボタンＢ２を選択する操作を行うと、ユーザＩＤが「ｇｅｏ００７」であるユーザに宛ててフレンドリクエストが送信される。本実施形態では、当該フレンドリクエストの送信が、上述した、フレンドとしての登録の申込に相当する。以下、フレンドとしての登録の申込に相当する操作を、フレンド登録申込操作と呼ぶこととする。

　すると承諾ユーザが利用するクライアント１２には、当該承諾ユーザ宛てのデータが送信された旨がプッシュ通知される。そして承諾ユーザが所定の操作を行うと、承諾ユーザが利用するクライアント１２のディスプレイに図７に例示する通知ページ２６が表示される。

　図７に例示する通知ページ２６には、承諾ユーザ宛てのデータの種類に対応付けられる通知情報が配置されている。図７の例では、当該承諾ユーザ宛ての最新のメッセージに対応付けられる通知情報Ｎ１と、当該承諾ユーザ宛ての最新の関係リクエストに対応付けられる通知情報Ｎ２が配置されている。図７に示す通知情報Ｎ２には、当該承諾ユーザ宛ての最新の関係リクエストがフレンドリクエストであることが示されている。

　ここで承諾ユーザが、図７に示す通知ページ２６において、カーソルＣを操作することで通知情報Ｎ２を選択する操作を行うと、承諾ユーザが利用するクライアント１２のディスプレイに、図８に例示するリクエスト一覧ページ２８が表示される。リクエスト一覧ページ２８には、受信した関係リクエストに対応付けられた受信リクエスト情報ＲＲと、送信した関係リクエストに対応付けられる送信リクエスト情報ＳＲと、が配置されている。以下、受信リクエスト情報ＲＲと送信リクエスト情報ＳＲを総称してリクエスト情報と呼ぶこととする。

　受信リクエスト情報ＲＲには、関係リクエストの送信元のユーザのアイコン画像Ｉ１や当該ユーザのユーザＩＤを表す文字列Ｓ１が配置されている。また受信リクエスト情報ＲＲには、関係リクエストの種類を表す文字列Ｓ３、関係リクエストの送信タイミングを表す情報Ｔ、及び、メッセージ入力フォームＦ２に入力されたメッセージＭが配置されている。なおここでは、関係リクエストの種類を表す文字列Ｓ３として、当該関係リクエストがフレンドリクエストであることを示す情報を表す文字列Ｓ３が配置されている。送信リクエスト情報ＳＲには、関係リクエストの送信先のユーザのアイコン画像Ｉ１や当該ユーザのユーザＩＤを表す文字列Ｓ１が配置されている。

　また、図８に示すリクエスト一覧ページ２８には、受信リクエスト情報ＲＲに対応付けられた承諾ボタンＢ３が配置されている。ここで承諾ユーザが承諾ボタンＢ３を選択する操作を行うと、上述したように、申込ユーザと承諾ユーザとは互いにフレンドユーザとして関連付けられることとなる。以下、このように申込ユーザによる申込を承諾する操作を、承諾操作と呼ぶこととする。この場合、当該受信リクエスト情報ＲＲはリクエスト一覧ページ２８から消去される。本実施形態では例えば、当該関連付けが行われることによって、ユーザ管理サーバ１０の記憶部１０ｂに記憶されているフレンド管理データは、図３に示すものから図９に示すものに更新される。図９に示す、ユーザＩＤが「ａａａ００１」であるフレンド管理データには、フレンドユーザＩＤとして「ｇｅｏ００７」が追加されている。また、図９に示す、ユーザＩＤが「ｇｅｏ００７」であるフレンド管理データには、フレンドユーザＩＤとして「ａａａ００１」が追加されている。

　また承諾ユーザは、図８に示すリクエスト一覧ページ２８に配置されたカーソルＣを移動させる操作を行うことにより、リクエスト情報の選択を行えるようになっている。本実施形態では、図８に示すように、選択対象であるリクエスト情報の周囲にはカーソルＣが表示される。ここで承諾ユーザが所定の決定操作を行うと、カーソルＣによって囲まれているリクエスト情報が、選択されたリクエスト情報として決定される。そして、選択されたリクエスト情報に対応付けられるプロファイルページ２２が、承諾ユーザが利用するクライアント１２のディスプレイに表示される。ここで、受信リクエスト情報ＲＲが選択された場合には、関係リクエストの送信元のユーザのプロファイルページ２２が表示される。また、送信リクエスト情報ＳＲが選択された場合には、関係リクエストの送信先のユーザのプロファイルページ２２が表示される。また本実施形態では、プロファイルページ２２を介して、受信した関係リクエストに対応付けられる申込の承諾操作や、受信又は送信した関係リクエストの削除操作を行えるようになっている。

　なおリクエスト一覧ページ２８には、複数の受信リクエスト情報ＲＲが配置されてもよい。この場合には、それぞれの受信リクエスト情報ＲＲに対応付けて承諾ボタンＢ３が配置されることとなる。

［実名公開の申込と承諾］
　次に、ユーザＩＤが「ａａａ００１」であるユーザが申込ユーザであり、ユーザＩＤが「ｇｅｏ００７」であるユーザが承諾ユーザである場合における、実名公開の申込と承諾の一例について説明する。なお、当該申込及び当該承諾が行われる前においては、図９に例示するフレンド管理データがユーザ管理サーバ１０の記憶部１０ｂに記憶されていることとする。すなわち、上述のようにして、ユーザＩＤが「ａａａ００１」であるユーザとユーザＩＤが「ｇｅｏ００７」であるユーザとは既に互いにフレンドユーザとなっていることとする。

　図１０は、申込ユーザが利用するクライアント１２のディスプレイに表示されるフレンド一覧ページ３０の一例を示す図である。当該フレンド一覧ページ３０には、申込ユーザのフレンドユーザに対応付けられるフレンド情報ＦＩが配置されている。このようにしてフレンド一覧ページ３０にはフレンド情報ＦＩの一覧が配置される。

　本実施形態では、実名公開ユーザではないフレンドユーザに対応付けられるフレンド情報ＦＩａには、当該フレンドユーザのユーザＩＤを表す文字列Ｓ１、及び、アイコン画像Ｉ１が配置される。また、実名公開ユーザでもあるフレンドユーザに対応付けられるフレンド情報ＦＩｂには、当該フレンドユーザのユーザＩＤを表す文字列Ｓ１、当該フレンドユーザの実名データが示す名称が表す文字列Ｓ２、及び、写真画像Ｉ２が配置される。

　本実施形態では、申込ユーザは、フレンド一覧ページ３０に配置されたカーソルＣを移動させる操作を行うことにより、フレンド情報ＦＩの選択を行えるようになっている。本実施形態では、図１０に示すように、選択対象であるフレンド情報ＦＩの周囲にはカーソルＣが表示される。ここで申込ユーザが所定の決定操作を行うと、カーソルＣによって囲まれているフレンド情報ＦＩが選択されたフレンド情報ＦＩとして決定される。ここでは例えばユーザＩＤが「ｇｅｏ００７」である承諾ユーザのフレンド情報ＦＩａが選択されたこととする。すると、選択されたフレンド情報ＦＩａに対応付けられるユーザのプロファイル情報が配置された、図１１に例示するプロファイルページ２２が、申込ユーザが利用するクライアント１２のディスプレイに表示される。

　本実施形態では、実名データが示す名称を表す文字列Ｓ２が配置されていないフレンド情報ＦＩａが選択された場合には、当該フレンド情報ＦＩａに配置されている文字列Ｓ１及びアイコン画像Ｉ１が配置されたプロファイルページ２２が表示される。そのため、図１１に例示するプロファイルページ２２には、選択されたフレンド情報ＦＩａに対応付けられるユーザのユーザＩＤを表す文字列Ｓ１及びアイコン画像Ｉ１が配置されることとなる。

　また本実施形態では、選択されたフレンド情報ＦＩａに文字列Ｓ２が配置されておらず、また当該フレンド情報ＦＩａに対応付けられるユーザが実名公開ユーザではない場合には、実名リクエストボタンＢ４が配置されたプロファイルページ２２が表示される。そのため、図１１に例示するプロファイルページ２２には、実名リクエストボタンＢ４が配置されることとなる。

　図１１に例示するプロファイルページ２２が表示されている際に申込ユーザが実名リクエストボタンＢ４を選択する操作を行うと、図１２に例示する実名リクエスト送信ページ３２が、申込ユーザが利用するクライアント１２のディスプレイに表示される。図１２に例示する実名リクエスト送信ページ３２には、選択されたフレンド情報ＦＩａに対応付けられるユーザのユーザＩＤを表す文字列Ｓ１、及び、アイコン画像Ｉ１が配置される。また当該実名リクエスト送信ページ３２には、メッセージ入力フォームＦ２、及び、送信ボタンＢ２も配置される。メッセージ入力フォームＦ２には、デフォルトのメッセージが予め入力されている。そしてユーザは当該メッセージを編集することができるようになっている。本実施形態では、図１２に例示する実名リクエスト送信ページ３２に表示されるデフォルトのメッセージには、図６に示すフレンドリクエスト送信ページ２４とは異なり、申込ユーザの実名データが示す名称を表す文字列Ｓ４が含まれている。

　ここで申込ユーザが送信ボタンＢ２を選択する操作を行うと、ユーザＩＤが「ｇｅｏ００７」であるユーザに宛てて実名リクエストが送信される。本実施形態では、当該実名リクエストの送信が、上述した、実名公開の申込に相当する。このような、実名公開の申込に相当する操作を、以下、実名公開申込操作と呼ぶこととする。

　すると承諾ユーザが利用するクライアント１２には、当該承諾ユーザ宛てのデータが送信された旨がプッシュ通知される。そして承諾ユーザが所定の操作を行うと、承諾ユーザが利用するクライアント１２のディスプレイに図１３に例示する通知ページ２６が表示される。

　図１３に例示する通知ページ２６には、承諾ユーザ宛てのデータの種類に対応付けられる通知情報が配置されている。図１３に示す通知情報Ｎ２には、当該承諾ユーザ宛ての最新の関係リクエストが実名リクエストであることが示されている。

　ここで承諾ユーザが、図１３に示す通知ページ２６において、カーソルＣを操作することで通知情報Ｎ２を選択する操作を行うと、承諾ユーザが利用するクライアント１２のディスプレイに、図１４に例示するリクエスト一覧ページ２８が表示される。リクエスト一覧ページ２８には、図８に示すリクエスト一覧ページ２８と同様、リクエスト情報が配置されている。

　図１４に例示する受信リクエスト情報ＲＲには、図８と同様、アイコン画像Ｉ１、文字列Ｓ１、文字列Ｓ３、情報Ｔ、及び、メッセージＭが配置されている。なおここでは文字列Ｓ３として、当該関係リクエストが実名リクエストであることを示す情報を表す文字列Ｓ３が配置されている。送信リクエスト情報ＳＲには、図８と同様、アイコン画像Ｉ１や文字列Ｓ１が配置されている。

　ここでメッセージＭに申込ユーザの実名データが示す名称を表す文字列Ｓ４が含まれていれば、承諾ユーザは実名リクエストを送信したユーザの実名を知ることができる。

　また、図１４に示すリクエスト一覧ページ２８には、図８と同様、受信リクエスト情報ＲＲに対応付けられた承諾ボタンＢ３が配置されている。ここで承諾ユーザが承諾操作、ここでは例えば承諾ボタンＢ３を選択する操作を行うと、上述したように、申込ユーザと承諾ユーザとは互いに実名公開ユーザとして関連付けられることとなる。この場合、当該受信リクエスト情報ＲＲはリクエスト一覧ページ２８から消去される。本実施形態では例えば、当該関連付けが行われることによって、ユーザ管理サーバ１０の記憶部１０ｂに記憶されているフレンド管理データは、図９に示すものから図１５に示すものに更新される。図１５に示す、ユーザＩＤが「ａａａ００１」であるフレンド管理データには、実名公開ユーザＩＤとして「ｇｅｏ００７」が追加されている。また、図１５に示す、ユーザＩＤが「ｇｅｏ００７」であるフレンド管理データには、実名公開ユーザＩＤとして「ａａａ００１」が追加されている。

　また、図８と同様、承諾ユーザは、図１４に示すリクエスト一覧ページ２８においてカーソルＣを移動させる操作により選択されたリクエスト情報に対応付けられるプロファイルページ２２を表示させることができる。そして承諾ユーザは、当該プロファイルページ２２を介して、受信した関係リクエストに対応付けられる申込の承諾操作や、受信又は送信した関係リクエストの削除操作を行えるようになっている。

［親友としての登録の申込と承諾］
　次に、ユーザＩＤが「ａａａ００１」であるユーザが申込ユーザであり、ユーザＩＤが「ｂｂｂ００２」であるユーザが承諾ユーザである場合における、親友としての登録の申込と承諾の一例について説明する。なお、当該申込及び当該承諾が行われる前においては、図３に例示するフレンド管理データがユーザ管理サーバ１０の記憶部１０ｂに記憶されていることとする。すなわち、ユーザＩＤが「ａａａ００１」であるユーザとユーザＩＤが「ｇｅｏ００７」であるユーザとは互いにフレンドユーザとはなっていないこととする。

　例えば、図４に示す検索ページ２０において、ユーザＩＤが「ｂｂｂ００２」である承諾ユーザの検索結果情報ＲＩｂが選択されたこととする。すると、選択された検索結果情報ＲＩｂに対応付けられるユーザのプロファイル情報が配置された、図１６に例示するプロファイルページ２２が、申込ユーザが利用するクライアント１２のディスプレイに表示される。

　本実施形態では、実名データが示す名称を表す文字列Ｓ２が配置されている検索結果情報ＲＩｂが選択された場合には、当該検索結果情報ＲＩｂに配置されている文字列Ｓ１、文字列Ｓ２及び写真画像Ｉ２が配置されたプロファイルページ２２が表示される。そのため、図１６に例示するプロファイルページ２２には、選択された検索結果情報ＲＩｂに対応付けられるユーザのユーザＩＤを表す文字列Ｓ１、当該ユーザの実名データが示す名称を表す文字列Ｓ２、及び写真画像Ｉ２が配置されることとなる。

　また本実施形態では、選択された検索結果情報ＲＩｂに文字列Ｓ２が配置されており、また当該検索結果情報ＲＩｂに対応付けられるユーザがフレンドユーザではない場合には、親友リクエストボタンＢ５が配置されたプロファイルページ２２が表示される。そのため、図１６に例示するプロファイルページ２２には、親友リクエストボタンＢ２が配置されることとなる。

　図１６に例示するプロファイルページ２２が表示されている際に申込ユーザが親友リクエストボタンＢ５を選択する操作を行うと、図１７に例示する親友リクエスト送信ページ３４が、申込ユーザが利用するクライアント１２のディスプレイに表示される。図１７に例示する親友リクエスト送信ページ３４には、選択された検索結果情報ＲＩｂに対応付けられるユーザのユーザＩＤを表す文字列Ｓ１、当該ユーザの実名データが示す名称を表す文字列Ｓ２、及び、写真画像Ｉ２が配置される。また、当該親友リクエスト送信ページ３４には、メッセージ入力フォームＦ２、及び、送信ボタンＢ２も配置される。メッセージ入力フォームＦ２には、デフォルトのメッセージが予め入力されており、ユーザは当該メッセージを編集することができるようになっている。本実施形態では、図１７に例示する親友リクエスト送信ページ３４に表示されるデフォルトのメッセージには、図６に示すフレンドリクエスト送信ページ２４とは異なり、申込ユーザの実名データが示す名称を表す文字列Ｓ４が含まれている。

　ここで申込ユーザが送信ボタンＢ２を選択する操作を行うと、ユーザＩＤが「ｂｂｂ００２」であるユーザに宛てて親友リクエストが送信される。本実施形態では、当該親友リクエストの送信が、上述した、親友としての登録の申込に相当する。このような、親友としての登録の申込に相当する操作を、以下、親友登録申込操作と呼ぶこととする。

　すると承諾ユーザが利用するクライアント１２には、当該承諾ユーザ宛てのデータが送信された旨がプッシュ通知される。そして承諾ユーザが所定の操作を行うと、承諾ユーザが利用するクライアント１２のディスプレイに図１８に例示する通知ページ２６が表示される。

　図１８に例示する通知ページ２６には、承諾ユーザ宛てのデータの種類に対応付けられる通知情報が配置されている。図１８に示す通知情報Ｎ２には、当該承諾ユーザ宛ての最新の関係リクエストが親友リクエストであることが示されている。

　ここで承諾ユーザが、図１８に示す通知ページ２６において通知情報Ｎ２を選択する操作を行うと、承諾ユーザが利用するクライアント１２のディスプレイに、図１９に例示するリクエスト一覧ページ２８が表示される。リクエスト一覧ページ２８には、図８及び図１４に示すリクエスト一覧ページ２８と同様、リクエスト情報が配置されている。

　図１９に例示する受信リクエスト情報ＲＲには、図８及び図１４と同様、アイコン画像Ｉ１、文字列Ｓ１、文字列Ｓ３、情報Ｔ、及び、メッセージＭが配置されている。なおここでは文字列Ｓ３として、当該関係リクエストが親友リクエストであることを示す情報を表す文字列Ｓ３が配置されている。送信リクエスト情報ＳＲには、図８及び図１４と同様、アイコン画像Ｉ１や文字列Ｓ１が配置されている。

　ここでメッセージＭに申込ユーザの実名データが示す名称を表す文字列Ｓ４が含まれていれば、承諾ユーザは親友リクエストを送信したユーザの実名を知ることができる。

　なお、図１９に例示する受信リクエスト情報ＲＲに、文字列Ｓ２や写真画像Ｉ２が配置されても構わない。

　また、図１９に示すリクエスト一覧ページ２８には、図８及び図１４と同様、受信リクエスト情報ＲＲに対応付けられた承諾ボタンＢ３が配置されている。ここで承諾ユーザが承諾操作、ここでは例えば承諾ボタンＢ３を選択する操作を行うと、上述したように、申込ユーザと承諾ユーザとは互いにフレンドユーザとしても関連付けられ、また、実名公開ユーザとしても関連付けられることとなる。この場合、当該受信リクエスト情報ＲＲはリクエスト一覧ページ２８から消去される。本実施形態では例えば、当該関連付けが行われることによって、ユーザ管理サーバ１０の記憶部１０ｂに記憶されているフレンド管理データは、図３に示すものから図２０に示すものに更新される。図２０に示す、ユーザＩＤが「ａａａ００１」であるフレンド管理データには、フレンドユーザＩＤとして「ｂｂｂ００２」が追加されている。また、図２０に示す、ユーザＩＤが「ａａａ００１」であるフレンド管理データには、実名公開ユーザＩＤとして「ｂｂｂ００２」が追加されている。また、図２０に示す、ユーザＩＤが「ｂｂｂ００２」であるフレンド管理データには、フレンドユーザＩＤとして「ａａａ００１」が追加されている。また、図２０に示す、ユーザＩＤが「ｂｂｂ００２」であるフレンド管理データには、実名公開ユーザＩＤとして「ａａａ００１」が追加されている。

　また、図８及び図１４と同様、承諾ユーザは、図１９に示すリクエスト一覧ページ２８においてカーソルＣを移動させる操作により選択されたリクエスト情報に対応付けられるプロファイルページ２２を表示させることができる。そして承諾ユーザは、当該プロファイルページ２２を介して、受信した関係リクエストに対応付けられる申込の承諾操作や、受信又は送信した関係リクエストの削除操作を行えるようになっている。

　以上のようにして、本実施形態によれば、申込ユーザは、フレンド登録申込操作及び実名公開申込操作という２段階の操作を行うことなく、親友登録申込操作を行うだけで、承諾ユーザとフレンドユーザとしても実名公開ユーザとしても関連付けられることとなる。そのため、本実施形態では、実名を公開するユーザを登録する際のユーザの手間が従来技術よりも低減されることとなる。

　例えば、実名データが示す名称を表す文字列Ｓ２が表示されているユーザであっても、当該ユーザに対してフレンドとしての登録の申込しかできないと仮定する。この場合には、当該ユーザがフレンドユーザとして登録されても、フレンド一覧ページ３０は配置される当該ユーザのフレンド情報ＦＩａには実名データが示す名称を表す文字列Ｓ２が配置されない。そのため、フレンド一覧ページ３０に配置されているフレンド情報ＦＩの一覧のなかから、当該ユーザのフレンド情報ＦＩａを特定することは困難となる。一方本実施形態では、実名データが示す名称を表す文字列Ｓ２が表示されているユーザに親友としての登録の申込ができる。そして、当該申込が承諾されることによって、フレンド一覧ページ３０には当該ユーザの実名データが示す名称を表す文字列Ｓ２を含むフレンド情報ＦＩｂが配置される。このようにして、本実施形態によれば、フレンド一覧ページ３０に配置されているフレンド情報ＦＩの一覧のなかから、当該ユーザのフレンド情報ＦＩｂを容易に特定することができることとなる。

　なお本実施形態における画面遷移は上述のものに限定されない。例えば、検索ページ２０における検索結果情報ＲＩの選択操作に応じて、フレンドリクエスト送信ページ２４や親友リクエスト送信ページ３４が表示されてもよい。また例えば、検索ページ２０における検索結果情報ＲＩの選択操作に応じて、関係リクエストの送信が行われてもよい。この場合には検索結果情報ＲＩの選択操作がフレンド登録申込操作や親友登録申込操作に相当することとなる。

　また例えば、検索結果情報ＲＩｂやフレンド情報ＦＩｂを介して表示されるプロファイルページ２２に実名データが示す名称が表す文字列Ｓ２が配置されていなくてもよい。

　また例えば、親友登録申込操作が行えるページにおいて、フレンド登録申込操作及び親友登録申込操作のいずれもが行えても構わない。

［検索ページやフレンド一覧ページ以外のページを介した申込と承諾］
　以上の説明では、フレンド登録申込操作及び親友登録申込操作は検索ページ２０を介して行われ、実名公開申込操作はフレンド一覧ページ３０を介して行われた。しかし、これらの操作が以上で説明したページ以外のページを介して行われても構わない。

　図２１は、ユーザＩＤが「ａａａ００１」である申込ユーザが利用するクライアント１２のディスプレイに表示されるＦｏＦページ３６の一例を示す図である。本実施形態に係るＦｏＦページ３６とは、特定のフレンドのフレンドユーザに対応付けられるフレンド情報ＦＩが配置されるページである。図２１の例では、ユーザＩＤが「ｈｈｈ００９」であるユーザのフレンドユーザのフレンド情報ＦＩが配置されている。このようにしてＦｏＦページ３６にはフレンド情報ＦＩの一覧が配置される。本実施形態では、申込ユーザの実名公開ユーザに対応付けられるフレンド情報ＦＩｂには、当該ユーザのユーザＩＤを表す文字列Ｓ１、当該ユーザの実名データが示す名称が表す文字列Ｓ２、及び、写真画像Ｉ２が配置される。またユーザ管理データに含まれる実名公開ページＩＤに「２」が設定されているユーザに対応付けられるフレンド情報ＦＩｂにも、文字列Ｓ１、文字列Ｓ２、及び、写真画像Ｉ２が配置される。一方いずれでもないユーザに対応付けられるフレンド情報ＦＩａには、当該ユーザのユーザＩＤを表す文字列Ｓ１、及び、アイコン画像Ｉ１が配置される。

　また、ＦｏＦページ３６に配置されているフレンド情報ＦＩのうち、申込ユーザのフレンドユーザのフレンド情報ＦＩには、申込ユーザのフレンドユーザであることを表す画像Ｉ３が配置される。

　本実施形態では、申込ユーザは、図１０同様、ＦｏＦページ３６に配置されたフレンド情報ＦＩの選択を行えるようになっている。ここで実名データが示す名称を表す文字列Ｓ２も画像Ｉ３も配置されていないフレンド情報ＦＩａが選択された場合には、図５と同様のプロファイルページ２２が表示される。当該プロファイルページ２２には、図５と同様にフレンドリクエストボタンＢ１が配置されている。ここで申込ユーザがフレンドリクエストボタンＢ１を選択する操作を行い、以降、上記の操作と同様の操作を行うことで、申込ユーザと承諾ユーザとは互いにフレンドユーザとして関連付けられることとなる。

　一方、実名データが示す名称を表す文字列Ｓ２は配置されているが画像Ｉ３が配置されていない配置されていないフレンド情報ＦＩａが選択された場合には、図１１と同様のプロファイルページ２２が表示される。当該プロファイルページ２２には、図１１と同様に実名リクエストボタンＢ４が配置されている。ここで申込ユーザが実名リクエストボタンＢ４を選択する操作を行い、以降、上記の操作と同様の操作を行うことで、申込ユーザと承諾ユーザとは互いにフレンドユーザとしても実名公開ユーザとしても関連付けられることとなる。

　図２２は、ユーザＩＤが「ａａａ００１」である申込ユーザが利用するクライアント１２のディスプレイに表示されるＹＭＫページ３８の一例を示す図である。本実施形態に係るＹＭＫページ３８とは、公知技術により、申込ユーザに親友としての登録を推薦するユーザとして特定されるユーザに関する情報Ｉｎｆｏを一覧で表示するページである。図２２の例では、申込ユーザのフレンドのフレンドであるユーザに関する情報Ｉｎｆｏが配置されている。なお本実施形態では、ＹＭＫページ３８に配置される情報Ｉｎｆｏは、ユーザ管理データに含まれる実名公開ページＩＤに「３」が設定されているユーザに関する情報Ｉｎｆｏに限定される。そしてユーザに関する情報Ｉｎｆｏには、当該ユーザのユーザＩＤを表す文字列Ｓ１、当該ユーザの実名データが示す名称を表す文字列Ｓ２、及び、写真画像Ｉ２が配置される。

　そして本実施形態に係るＹＭＫページ３８では、情報Ｉｎｆｏに対応付けて親友リクエストボタンＢ５が配置されている。ここで申込ユーザが親友リクエストボタンＢ５を選択する操作を行うと、当該親友リクエストボタンＢ５に対応付けられるユーザについての、図１７と同様の親友リクエスト送信ページ３４が、申込ユーザが利用するクライアント１２のディスプレイに表示される。以降、上記の操作と同様の操作を行うことで、申込ユーザと承諾ユーザとは互いにフレンドユーザとしても実名公開ユーザとしても関連付けられることとなる。

　なお、ユーザ管理データに含まれる実名公開ページＩＤに「３」が設定されていないユーザに関する情報ＩｎｆｏがＹＭＫページ３８に配置されてもよい。この場合、当該ユーザに関する情報Ｉｎｆｏには、当該ユーザのユーザＩＤを表す文字列Ｓ１、及び、アイコン画像Ｉ１が配置されてもよい。また当該情報Ｉｎｆｏに対応付けてフレンドリクエストボタンＢ１が配置されていてもよい。そして申込ユーザがフレンドリクエストボタンＢ１を選択する操作を行うと、当該フレンドリクエストボタンＢ１に対応付けられるユーザについての、図６と同様のフレンドリクエスト送信ページ２４が表示されてもよい。以降、上記の操作と同様の操作を行うことで、申込ユーザと承諾ユーザとは互いにフレンドユーザとして関連付けられるようにしてもよい。また、ＹＭＫページ３８においてユーザを選択する操作が行われた際に、当該ユーザのプロファイルページ２２が表示されてもよい。

　図２３は、ユーザＩＤが「ａａａ００１」である申込ユーザが利用するクライアント１２のディスプレイに表示されるＳＮＳフレンド発見ページ４０の一例を示す図である。本実施形態に係るＳＮＳフレンド発見ページ４０とは、外部のＳＮＳにおいてフレンドとして登録されているユーザに関する情報Ｉｎｆｏを一覧で表示するページである。当該ユーザに関する情報Ｉｎｆｏには、当該ユーザのユーザＩＤを表す文字列Ｓ１、当該ユーザの実名データが示す名称を表す文字列Ｓ２、及び、写真画像Ｉ２が配置される。また当該ユーザに関する情報Ｉｎｆｏには、外部のＳＮＳにおいて使用されている当該ユーザの写真画像Ｉ４及び当該外部のＳＮＳにおける当該ユーザの識別情報を表す文字列Ｓ５が配置される。

　ＳＮＳフレンド発見ページ４０では、チェックボックスＣｈにより、情報Ｉｎｆｏを複数選択できるようになっている。また、申込ユーザが全選択ボタンＢ６を選択する操作を行うとすべての情報Ｉｎｆｏが選択状態となる。一方、申込ユーザが全解除ボタンＢ７を選択する操作を行うとすべての情報Ｉｎｆｏの選択状態が解除される。ここで申込ユーザが画面遷移ボタンＢ８を選択する操作を行うと、図２４に例示する親友リクエスト送信ページ３４が、申込ユーザが利用するクライアント１２のディスプレイに表示される。ここで申込ユーザが送信ボタンＢ２を選択する操作を行うと、ＳＮＳフレンド発見ページ４０で選択状態となったユーザのそれぞれに宛てて親友リクエストが送信されることとなる。この場合には、一度の親友登録申込操作で複数のユーザに対して親友としての登録の申込が行えることとなる。なお同様にして、一度のフレンド登録申込操作で複数のユーザに対してフレンドとしての登録の申込が行えてもよい。また一度の実名公開申込操作で複数のユーザに対して実名公開の申込が行えてもよい。

［機能］
　以下、上述した申込と承諾を中心に、本実施形態に係る情報処理システム１の機能並びに本実施形態に係る情報処理システム１で実行される処理についてさらに説明する。

　図２５は、本実施形態に係る情報処理システム１で実装される機能の一例を示す機能ブロック図である。なお、本実施形態に係る情報処理システム１で、図２５に示す機能のすべてが実装される必要はなく、また、図２５に示す機能以外の機能が実装されていても構わない。

　図２５に示すように、本実施形態に係るユーザ管理サーバ１０は、機能的には例えば、ユーザ管理データ記憶部５０、フレンド管理データ記憶部５２、関係リクエスト管理データ記憶部５４、ユーザ管理データ登録要求受信部５６、ユーザ管理データ登録部５８、関係リクエスト受信部６０、関係リクエスト管理データ登録部６２、通知部６４、ページ生成部６６、ページ送信部６８、承諾受信部７０、フレンド管理データ登録部７２、を含む。ユーザ管理データ記憶部５０、フレンド管理データ記憶部５２、関係リクエスト管理データ記憶部５４は、記憶部１０ｂを主として実装される。ユーザ管理データ登録要求受信部５６、関係リクエスト受信部６０、通知部６４、ページ送信部６８、承諾受信部７０は、通信部１０ｃを主として実装される。ユーザ管理データ登録部５８、関係リクエスト管理データ登録部６２、ページ生成部６６、フレンド管理データ登録部７２は、制御部１０ａを主として実装される。

　そして、以上の機能は、コンピュータであるユーザ管理サーバ１０にインストールされた、以上の機能に対応する指令を含むプログラムを制御部１０ａで実行することにより実装されている。このプログラムは、例えば、光ディスク、磁気ディスク、磁気テープ、光磁気ディスク、フラッシュメモリ等のコンピュータ読み取り可能な情報記憶媒体を介して、あるいは、インターネットなどを介してユーザ管理サーバ１０に供給される。

　また図２５に示すように、本実施形態に係るクライアント１２は、機能的には例えば、ユーザ管理データ登録要求部８０、ページ要求部８２、ページ受信部８４、表示処理部８６、操作受付部８８、関係リクエスト送信部９０、通知受信部９２、承諾送信部９４、削除要求送信部９６、を含む。ユーザ管理データ登録要求部８０、ページ要求部８２、ページ受信部８４、関係リクエスト送信部９０、通知受信部９２、承諾送信部９４、削除要求送信部９６は、通信部１２ｃを主として実装される。表示処理部８６は、制御部１２ａ及び出力部１２ｄを主として実装される。操作受付部８８は、制御部１２ａ及び入力部１２ｅを主として実装される。

　そして、以上の機能は、コンピュータであるクライアント１２にインストールされた、以上の機能に対応する指令を含むプログラムを制御部１２ａで実行することにより実装されている。このプログラムは、例えば、光ディスク、磁気ディスク、磁気テープ、光磁気ディスク、フラッシュメモリ等のコンピュータ読み取り可能な情報記憶媒体を介して、あるいは、インターネットなどを介してクライアント１２に供給される。

　ユーザ管理データ記憶部５０は、本実施形態では例えば、図２に例示するユーザ管理データを記憶する。

　フレンド管理データ記憶部５２は、本実施形態では例えば、図３、図９、及び、図１５に例示するフレンド管理データを記憶する。

　関係リクエスト管理データ記憶部５４は、本実施形態では例えば、図２６に例示する、申込ユーザが利用するクライアント１２から送信される関係リクエストを管理するための関係リクエスト管理データを記憶する。図２６に例示するように、関係リクエスト管理データには、送信元ユーザＩＤ、送信先ユーザＩＤ、リクエスト種類データ、送信日時データ、メッセージデータ、が含まれる。送信元ユーザＩＤは、関係リクエストを送信するクライアント１２を利用する申込ユーザのユーザＩＤである。送信先ユーザＩＤは、関係リクエストの送信先となるクライアント１２を利用する承諾ユーザのユーザＩＤである。リクエスト種類データは、当該関係リクエストの種類を示すデータである。リクエスト種類データが示す関係リクエストの種類については後述する。送信日時データは、関係リクエストの送信日時を示すデータである。メッセージデータは、上述のメッセージ入力フォームＦ２に入力されたメッセージを示すデータである。ユーザＩＤが「ａａａ００１」である申込ユーザによる、ユーザＩＤが「ｂｂｂ００２」である承諾ユーザに対する親友としての登録の申込が行われた際には、例えば図２６の最も上及び上から２番目に示されている関係リクエスト管理データが記憶される。またユーザＩＤが「ａａａ００１」である申込ユーザによる、ユーザＩＤが「ｇｅｏ００７」である承諾ユーザに対するフレンドとしての登録の申込が行われた際には、例えば図２６の最も下に示されている関係リクエスト管理データが記憶される。

　ユーザ管理サーバ１０のユーザ管理データ登録要求受信部５６は、本実施形態では例えば、クライアント１２から受け付けるユーザ管理データの登録要求を受け付ける。ユーザ管理データ登録要求受信部５６は、本実施形態では例えば、ユーザ管理データの追加要求、削除要求、又は、更新要求を受け付ける。

　ユーザ管理サーバ１０のユーザ管理データ登録部５８は、本実施形態では例えば、ユーザ管理データ登録要求受信部５６が受け付ける登録要求に基づいて、ユーザ管理データの登録を行う。ユーザ管理データ登録部５８は、本実施形態では例えば、ユーザ管理データの追加、削除、又は、更新を行う。

　ユーザ管理サーバ１０の関係リクエスト受信部６０は、本実施形態では例えば、申込ユーザが利用するクライアント１２から送信される関係リクエストを受信する。

　ユーザ管理サーバ１０の関係リクエスト管理データ登録部６２は、本実施形態では例えば、関係リクエスト管理データの登録を行う。関係リクエスト管理データ登録部６２は、本実施形態では例えば、関係リクエスト管理データの追加、削除、更新を行う。

　ユーザ管理サーバ１０の通知部６４は、本実施形態では例えば、関係リクエストの受信に応じて、承諾ユーザに宛てた関係リクエストが送信されたことを通知する。通知部６４は、本実施形態では例えば、承諾ユーザのクライアント１２へのプッシュ通知を行う。通知部６４は、本実施形態では例えば、承諾ユーザのユーザ管理データに含まれる端末ＩＤによって識別されるクライアント１２に関係リクエストが送信されたことを通知する。なお本実施形態では上述のように、承諾ユーザが複数のクライアント１２を利用してもよい。この場合は、複数のクライアント１２に関係リクエストが送信されたことを示す通知が送信されることとなる。

　ユーザ管理サーバ１０のページ生成部６６は、本実施形態では例えば、上述した図４～図８、図１０～図１４、図１６～図１９、図２１～図２４に示す各種ページを表すデータを生成する。

　ユーザ管理サーバ１０のページ送信部６８は、本実施形態では例えば、ページ生成部６６が生成するデータをクライアント１２に送信する。

　ユーザ管理サーバ１０の承諾受信部７０は、本実施形態では例えば、申込ユーザによる申込に対する承諾ユーザによる承諾に応じて、承諾ユーザが利用するクライアント１２が送信する承諾通知を受信する。

　ユーザ管理サーバ１０のフレンド管理データ登録部７２は、本実施形態では例えば、フレンド管理データの登録を行う。フレンド管理データ登録部７２は、本実施形態では例えば、フレンド管理データの追加、削除、更新を行う。

　本実施形態に係るフレンド管理データ登録部７２は、例えば、ユーザを指定する第１の操作に応じて、当該ユーザをニックネームが開示される第１の関係にあるユーザとして登録する。具体的には例えば、申込ユーザによる承諾ユーザを指定するフレンド登録申込操作に応じて、承諾ユーザは申込ユーザとフレンドの関係にあるユーザとして登録されることとなる。

　また本実施形態に係るフレンド管理データ登録部７２は、例えば、第１の関係にあるユーザを指定する第２の操作に応じて、当該ユーザをさらに実名も開示される第２の関係にあるユーザとして登録する。具体的には例えば、申込ユーザとフレンドの関係にあるユーザを承諾ユーザとして指定する実名公開申込操作に応じて、当該承諾ユーザが、申込ユーザの実名を公開する関係にあるユーザとして登録されることとなる。

　また本実施形態に係るフレンド管理データ登録部７２は、例えば、第１の関係にあるユーザとして登録されていないユーザを指定する第３の操作に応じて、当該ユーザを第１の関係及び第２の関係にあるユーザとして登録する。具体的には例えば、申込ユーザとフレンドの関係にあるユーザとして登録されていない承諾ユーザを指定する親友登録申込操作に応じて、承諾ユーザが、申込ユーザとフレンドの関係にあり、かつ、実名を公開する関係にあるユーザとして登録されることとなる。

　またフレンド管理データ登録部７２は、上述したように、検索ページ２０などに実名が表示されているユーザを指定する操作に応じて、当該ユーザを第１の関係及び第２の関係にあるユーザとして登録するようにしてもよい。またフレンド管理データ登録部７２は、検索ページ２０などといった、第１の関係にあるユーザの候補に関する情報の一覧において実名が表示されていないユーザを指定する操作に応じて、当該ユーザを第１の関係にあるユーザとして登録してもよい。そしてフレンド管理データ登録部７２は、当該一覧において実名が表示されているユーザを指定する操作に応じて、当該ユーザを第１の関係及び第２の関係にあるユーザとして登録してもよい。

　クライアント１２のユーザ管理データ登録要求部８０は、ユーザ管理データの登録要求をユーザ管理サーバ１０に送信する。ユーザ管理データ登録要求部８０は、本実施形態では、ユーザ管理データの追加要求、削除要求、更新要求をユーザ管理サーバ１０に送信する。本実施形態では、ユーザ管理データ登録要求部８０が送信する登録要求に応じて、ユーザ管理データの登録が行われる。なお本実施形態では、新規のユーザ管理データの追加要求に応じて、当該新規のユーザ管理データの生成、及び、当該新規のユーザ管理データのユーザＩＤを含む新規のフレンド管理データの生成が行われる。

　クライアント１２のページ要求部８２は、上述した各種ページの送信要求をユーザ管理サーバ１０に送信する。ユーザ管理サーバ１０のページ生成部６６は、当該送信要求に応じて要求されたページを生成することとなる。

　クライアント１２のページ受信部８４は、ユーザ管理サーバ１０のページ送信部６８が送信する、ページを表すデータを受信する。

　クライアント１２の表示処理部８６は、ページ受信部８４が受信する、ページを表すデータに基づいて当該ページを生成してディスプレイに表示させる。また表示処理部８６は、本実施形態では例えば、第２の関係にあるユーザとして登録されているユーザの実名が含まれる、第１の関係にあるユーザに関する情報の一覧を表示させる。表示処理部８６は、具体的には例えば、実名を公開する関係にあるユーザとして登録されているユーザの実名が含まれる、フレンドの関係にあるユーザに関する一覧である、図１０に例示するフレンド一覧ページ３０を表示させる。

　クライアント１２の操作受付部８８は、ユーザがクライアント１２に対して行う各種の操作を受け付ける。本実施形態に係る操作受付部８８が受け付ける操作としては、例えば、上述のフレンド登録申込操作、実名公開申込操作、親友登録申込操作、承諾操作、関係リクエストの削除操作などが挙げられる。

　クライアント１２の関係リクエスト送信部９０は、操作受付部８８が受け付ける操作に応じた関係リクエストをユーザ管理サーバ１０に送信する。

　クライアント１２の通知受信部９２は、ユーザ管理サーバ１０の通知部６４が送信する通知を受信する。

　クライアント１２の承諾送信部９４は、操作受付部８８が承諾操作を受け付けた場合に、当該承諾操作に対応付けられる承諾通知をユーザ管理サーバ１０に送信する。

　クライアント１２の削除要求送信部９６は、操作受付部８８が関係リクエストの削除操作を受け付けた際に当該関係リクエストの削除要求をユーザ管理サーバ１０に送信する。ユーザ管理サーバ１０の関係リクエスト管理データ登録部６２は、当該削除要求の受信に応じて、削除要求の対象となった関係リクエスト管理データを関係リクエスト管理データ記憶部５４から削除する。

［処理フロー］
　ここで、本実施形態に係る情報処理システム１で行われる、申込ユーザと承諾ユーザとを互いにフレンドとして登録する処理の流れの一例を、図２７に例示するフロー図を参照しながら説明する。

　まず、申込ユーザが承諾ユーザを指定するフレンド登録申込操作を行うと、申込ユーザが利用するクライアント１２の操作受付部８８が、当該フレンド登録申込操作を受け付ける（Ｓ１０１）。すると、申込ユーザが利用するクライアント１２の関係リクエスト送信部９０が、当該承諾ユーザに対するフレンドリクエストをユーザ管理サーバ１０に送信する。するとユーザ管理サーバ１０の関係リクエスト受信部６０が当該フレンドリクエストを受信する（Ｓ１０２）。

　当該フレンドリクエストは、本実施形態では例えば、値が「Ｆｒｉｅｎｄ　Ｒｅｑｕｅｓｔ」であるリクエスト種類データが関連付けられた関係リクエストとして実装される。また本実施形態に係る関係リクエストには、送信元ユーザＩＤ及び送信先ユーザＩＤが関連付けられている。ここでは例えば、申込ユーザのユーザＩＤが送信元ユーザＩＤとして関連付けられ、承諾ユーザのユーザＩＤが送信先ユーザＩＤとして関連付けられる。また当該関係リクエストには、当該関係リクエストの送信日時を示す値、及び、上述したフレンドリクエスト送信ページ２４のメッセージ入力フォームＦ２に入力されたメッセージが関連付けられる。

　するとユーザ管理サーバ１０の関係リクエスト管理データ登録部６２が、Ｓ１０２に示す処理で受信したフレンドリクエストに対応付けられる関係リクエスト管理データを生成して、関係リクエスト管理データ記憶部５４に記憶させる（Ｓ１０３）。ここで生成される関係リクエスト管理データの送信元ユーザＩＤとして、Ｓ１０２に示す処理で受信したフレンドリクエストに関連付けられている送信元ユーザＩＤが設定される。また生成される関係リクエスト管理データの送信先ユーザＩＤとして、Ｓ１０２に示す処理で受信したフレンドリクエストに関連付けられている送信先ユーザＩＤが設定される。また生成される関係リクエスト管理データのリクエスト種類データの値として、Ｓ１０２に示す処理で受信したフレンドリクエストに関連付けられているリクエスト種類データの値が設定される。ここでは生成される関係リクエスト管理データのリクエスト種類データの値として「Ｆｒｉｅｎｄ　Ｒｅｑｕｅｓｔ」が設定されることとなる。また生成される関係リクエスト管理データの送信日時データの値として、Ｓ１０２に示す処理で受信したフレンドリクエストに関連付けられている送信日時を示す値が設定される。また生成される関係リクエスト管理データのメッセージデータの値として、Ｓ１０２に示す処理で受信したフレンドリクエストに関連付けられているメッセージが設定される。

　そしてユーザ管理サーバ１０の通知部６４が、承諾ユーザのユーザ管理データに含まれる端末ＩＤによって識別されるクライアント１２に、当該承諾ユーザに宛てた関係リクエストが送信されたことを通知する。すると、当該クライアント１２の通知受信部９２が当該通知を受信する（Ｓ１０４）。

　その後、承諾ユーザが、当該フレンドリクエストの承諾操作を行うと、承諾ユーザが利用するクライアント１２の操作受付部８８が当該承諾操作を受け付ける（Ｓ１０５）。すると、承諾ユーザが利用するクライアント１２の承諾送信部９４が、当該フレンドリクエストの承諾通知をユーザ管理サーバ１０に送信する。すると、ユーザ管理サーバ１０の承諾受信部７０が当該承諾通知を受信する（Ｓ１０６）。本実施形態では、当該承諾通知には、承諾操作の対象となったフレンドリクエストに関連付けられた送信元ユーザＩＤ、送信先ユーザＩＤ、及び、リクエスト種類データの値が関連付けられている。

　すると、ユーザ管理サーバ１０のフレンド管理データ登録部７２は、Ｓ１０２に示す処理で受信したフレンドリクエストに基づくフレンド管理データの更新を行う（Ｓ１０７）。Ｓ１０７に示す処理では、フレンド管理データ登録部７２は、例えば、当該承諾通知に関連付けられている送信元ユーザＩＤをユーザＩＤとして含むフレンド管理データを特定する。そしてフレンド管理データ登録部７２は、特定されたフレンド管理データのフレンドユーザＩＤとして、当該承諾通知に関連付けられている送信先ユーザＩＤを追加する。またフレンド管理データ登録部７２は、当該承諾通知に関連付けられている送信先ユーザＩＤをユーザＩＤとして含むフレンド管理データを特定する。そしてフレンド管理データ登録部７２は、特定されたフレンド管理データのフレンドユーザＩＤとして、当該承諾通知に関連付けられている送信元ユーザＩＤを追加する。

　そして、ユーザ管理サーバ１０の関係リクエスト管理データ登録部６２が、Ｓ１０２に示す処理で受信したフレンドリクエストに対応付けられる関係リクエスト管理データを関係リクエスト管理データ記憶部５４から削除する（Ｓ１０８）。そして、本処理例に示す処理は終了される。

　このようにして、申込ユーザと承諾ユーザとを互いにフレンドとして登録されることとなる。

　次に、本実施形態に係る情報処理システム１で行われる、互いにフレンドとして登録されている申込ユーザと承諾ユーザの実名を互いに公開する処理の流れの一例を、図２８に例示するフロー図を参照しながら説明する。

　まず、申込ユーザが承諾ユーザを指定する実名公開申込操作を行うと、申込ユーザが利用するクライアント１２の操作受付部８８が、当該実名公開申込操作を受け付ける（Ｓ２０１）。すると、申込ユーザが利用するクライアント１２の関係リクエスト送信部９０が、当該承諾ユーザに対する実名リクエストをユーザ管理サーバ１０に送信する。するとユーザ管理サーバ１０の関係リクエスト受信部６０が当該実名リクエストを受信する（Ｓ２０２）。

　当該実名リクエストは、本実施形態では例えば、値が「Ｒｅａｌ　Ｎａｍｅ　Ｒｅｑｕｅｓｔ」であるリクエスト種類データが関連付けられた関係リクエストとして実装される。また本実施形態に係る関係リクエストには、送信元ユーザＩＤ及び送信先ユーザＩＤが関連付けられている。ここでは例えば、申込ユーザのユーザＩＤが送信元ユーザＩＤとして関連付けられ、承諾ユーザのユーザＩＤが送信先ユーザＩＤとして関連付けられる。また当該関係リクエストには、当該関係リクエストの送信日時を示す値、及び、上述した実名リクエスト送信ページ３２のメッセージ入力フォームＦ２に入力されたメッセージが関連付けられる。

　するとユーザ管理サーバ１０の関係リクエスト管理データ登録部６２が、Ｓ２０２に示す処理で受信した実名リクエストに対応付けられる関係リクエスト管理データを生成して、関係リクエスト管理データ記憶部５４に記憶させる（Ｓ２０３）。ここで生成される関係リクエスト管理データの送信元ユーザＩＤとして、Ｓ２０２に示す処理で受信した実名リクエストに関連付けられている送信元ユーザＩＤが設定される。また生成される関係リクエスト管理データの送信先ユーザＩＤとして、Ｓ２０２に示す処理で受信した実名リクエストに関連付けられている送信先ユーザＩＤが設定される。また生成される関係リクエスト管理データのリクエスト種類データの値として、Ｓ２０２に示す処理で受信した実名リクエストに関連付けられているリクエスト種類データの値が設定される。ここでは生成される関係リクエスト管理データのリクエスト種類データの値として「Ｒｅａｌ　Ｎａｍｅ　Ｒｅｑｕｅｓｔ」が設定されることとなる。また生成される関係リクエスト管理データの送信日時データの値として、Ｓ２０２に示す処理で受信した実名リクエストに関連付けられている送信日時を示す値が設定される。また生成される関係リクエスト管理データのメッセージデータの値として、Ｓ２０２に示す処理で受信したフレンドリクエストに関連付けられているメッセージが設定される。

　そしてユーザ管理サーバ１０の通知部６４が、承諾ユーザのユーザ管理データに含まれる端末ＩＤによって識別されるクライアント１２に、当該承諾ユーザに宛てた関係リクエストが送信されたことを通知する。すると、当該クライアント１２の通知受信部９２が当該通知を受信する（Ｓ２０４）。

　その後、承諾ユーザが、当該実名リクエストの承諾操作を行うと、承諾ユーザが利用するクライアント１２の操作受付部８８が当該承諾操作を受け付ける（Ｓ２０５）。すると、承諾ユーザが利用するクライアント１２の承諾送信部９４が、当該実名リクエストの承諾通知をユーザ管理サーバ１０に送信する。すると、ユーザ管理サーバ１０の承諾受信部７０が当該承諾通知を受信する（Ｓ２０６）。本実施形態では、当該承諾通知には、承諾操作の対象となった実名リクエストに関連付けられた送信元ユーザＩＤ、送信先ユーザＩＤ、及び、リクエスト種類データの値が関連付けられている。

　すると、ユーザ管理サーバ１０のフレンド管理データ登録部７２は、Ｓ２０２に示す処理で受信した実名リクエストに基づくフレンド管理データの更新を行う（Ｓ２０７）。Ｓ２０７に示す処理では、フレンド管理データ登録部７２は、例えば、当該承諾通知に関連付けられている送信元ユーザＩＤをユーザＩＤとして含むフレンド管理データを特定する。そしてフレンド管理データ登録部７２は、特定されたフレンド管理データの実名公開ユーザＩＤとして、当該承諾通知に関連付けられている送信先ユーザＩＤを追加する。またフレンド管理データ登録部７２は、当該承諾通知に関連付けられている送信先ユーザＩＤをユーザＩＤとして含むフレンド管理データを特定する。そしてフレンド管理データ登録部７２は、特定されたフレンド管理データの実名公開ユーザＩＤとして、当該承諾通知に関連付けられている送信元ユーザＩＤを追加する。

　そして、ユーザ管理サーバ１０の関係リクエスト管理データ登録部６２が、Ｓ２０２に示す処理で受信した実名リクエストに対応付けられる関係リクエスト管理データを関係リクエスト管理データ記憶部５４から削除する（Ｓ２０８）。そして、本処理例に示す処理は終了される。

　このようにして、互いにフレンドとして登録されている申込ユーザと承諾ユーザの実名を互いに公開されることとなる。

　本実施形態では例えば、ページ生成部６６は、関係リクエスト管理データ記憶部５４に記憶されている関係リクエスト管理データに基づいて、リクエスト一覧ページ２８を生成する。ここでページ生成部６６は、例えば、送信元ユーザＩＤとして受諾ユーザのユーザＩＤを含む関係リクエスト管理データに基づいて、送信リクエスト情報ＳＲを生成する。またページ生成部６６は、例えば送信先ユーザＩＤとして受諾ユーザのユーザＩＤを含む関係リクエスト管理データに基づいて、受信リクエスト情報ＲＲを生成する。

　またページ生成部６６は、受信リクエスト情報ＲＲに対応付けられる承諾ボタンＢ３には、当該受信リクエスト情報ＲＲに対応付けられる関係リクエスト管理データに含まれる送信元ユーザＩＤ、送信先ユーザＩＤ、及び、リクエスト種類データの値を関連付ける。

　そのため承諾送信部９４は、承諾ユーザに選択された承諾ボタンＢ３に関連付けられた送信元ユーザＩＤ、送信先ユーザＩＤ、及び、リクエスト種類データの値を承諾通知に関連付けてユーザ管理サーバ１０に送信できることとなる。

　次に、本実施形態に係る情報処理システム１で行われる、申込ユーザと承諾ユーザとを互いに親友として登録する処理の流れの一例を、図２９に例示するフロー図を参照しながら説明する。

　まず、申込ユーザが承諾ユーザを指定する親友登録申込操作を行うと、申込ユーザが利用するクライアント１２の操作受付部８８が、当該親友登録申込操作を受け付ける（Ｓ３０１）。すると、申込ユーザが利用するクライアント１２の関係リクエスト送信部９０が、当該承諾ユーザに対する親友リクエストをユーザ管理サーバ１０に送信する。するとユーザ管理サーバ１０の関係リクエスト受信部６０が当該親友リクエストを受信する（Ｓ３０２）。

　当該親友リクエストは、本実施形態では例えば、２つの関係リクエストとして実装される。ここで第１の関係リクエストは、例えば、値が「Ｆｒｉｅｎｄ　Ｒｅｑｕｅｓｔ」であるリクエスト種類データが関連付けられた関係リクエストとして実装される。そして第２の関係リクエストは、例えば、値が「Ｒｅａｌ　Ｎａｍｅ　Ｒｅｑｕｅｓｔ」であるリクエスト種類データが関連付けられた関係リクエストとして実装される。そして例えば、第１の関係リクエストにも第２の関係リクエストにも送信元ユーザＩＤ及び送信先ユーザＩＤが関連付けられる。ここでは例えば、申込ユーザのユーザＩＤが送信元ユーザＩＤとして関連付けられ、承諾ユーザのユーザＩＤが送信先ユーザＩＤとして関連付けられる。また本実施形態では、第１の関係リクエストには、当該関係リクエストの送信日時を示す値、及び、上述した親友リクエスト送信ページ３４のメッセージ入力フォームＦ２に入力されたメッセージが関連付けられる。なお、第２の関係リクエストにも、送信日時を示す値やメッセージが関連付けられていてもよい。

　するとユーザ管理サーバ１０の関係リクエスト管理データ登録部６２が、Ｓ３０２に示す処理で受信したフレンドリクエストに対応付けられる関係リクエスト管理データを生成して、関係リクエスト管理データ記憶部５４に記憶させる（Ｓ３０３）。ここでは２つの関係リクエストのそれぞれに対応付けられる関係リクエスト管理データが生成されることとなる。生成される第１の関係リクエスト管理データの送信元ユーザＩＤとして、Ｓ３０２に示す処理で受信した第１の関係リクエストに関連付けられている送信元ユーザＩＤが設定される。生成される第１の関係リクエスト管理データの送信先ユーザＩＤとして、Ｓ３０２に示す処理で受信した第１の関係リクエストに関連付けられている送信先ユーザＩＤが設定される。生成される第１の関係リクエスト管理データのリクエスト種類データの値として、Ｓ３０２に示す処理で受信した第１の関係リクエストに関連付けられているリクエスト種類データの値が設定される。ここでは生成される第１の関係リクエスト管理データのリクエスト種類データの値として「Ｆｒｉｅｎｄ　Ｒｅｑｕｅｓｔ」が設定されることとなる。また生成される第１の関係リクエスト管理データの送信日時データの値として、Ｓ３０２に示す処理で受信した第１の関係リクエストに関連付けられている送信日時を示す値が設定される。また生成される関係リクエスト管理データのメッセージデータの値として、Ｓ３０２に示す処理で受信した第１の関係リクエストに関連付けられているメッセージが設定される。

　また、生成される第２の関係リクエスト管理データの送信元ユーザＩＤとして、Ｓ３０２に示す処理で受信した第２の関係リクエストに関連付けられている送信元ユーザＩＤが設定される。生成される第２の関係リクエスト管理データの送信先ユーザＩＤとして、Ｓ３０２に示す処理で受信した第２の関係リクエストに関連付けられている送信先ユーザＩＤが設定される。生成される第２の関係リクエスト管理データのリクエスト種類データの値として、Ｓ３０２に示す処理で受信した第２の関係リクエストに関連付けられているリクエスト種類データの値が設定される。ここでは生成される第２の関係リクエスト管理データのリクエスト種類データの値として「Ｒｅａｌ　Ｎａｍｅ　Ｒｅｑｕｅｓｔ」が設定されることとなる。なお、生成される第２の関係リクエスト管理データの送信日時データの値として、Ｓ３０２に示す処理で受信した第２の関係リクエストに関連付けられている送信日時を示す値が設定されてもよい。また生成される関係リクエスト管理データのメッセージデータの値として、Ｓ３０２に示す処理で受信した第２の関係リクエストに関連付けられているメッセージが設定されてもよい。

　図２６の最も上及び上から２番目には、親友リクエストの送信に基づいて生成される２つの関係リクエスト管理データの一例が示されている。例えば、申込ユーザのユーザＩＤが「ａａａ００１」であり承諾ユーザのユーザＩＤが「ｂｂｂ００２」である親友リクエストの送信に基づいて当該２つの関係リクエスト管理データが生成されることとなる。

　そしてユーザ管理サーバ１０の通知部６４が、承諾ユーザのユーザ管理データに含まれる端末ＩＤによって識別されるクライアント１２に、当該承諾ユーザに宛てた関係リクエストが送信されたことを通知する。すると、当該クライアント１２の通知受信部９２が当該通知を受信する（Ｓ３０４）。

　その後、承諾ユーザが、当該親友リクエストの承諾操作を行うと、承諾ユーザが利用するクライアント１２の操作受付部８８が当該承諾操作を受け付ける（Ｓ３０５）。すると、承諾ユーザが利用するクライアント１２の承諾送信部９４が、当該親友リクエストの承諾通知をユーザ管理サーバ１０に送信する。すると、ユーザ管理サーバ１０の承諾受信部７０が当該承諾通知を受信する（Ｓ３０６）。本実施形態では、親友リクエストの承諾通知は、２つの通知によって実装されている。ここで例えば、第１の承諾通知には、承諾操作の対象となった親友リクエストに関連付けられた送信元ユーザＩＤ、送信先ユーザＩＤ、及び、値が「Ｆｒｉｅｎｄ　Ｒｅｑｕｅｓｔ」であるリクエスト種類データが関連付けられている。また第２の承諾通知には、承諾操作の対象となった親友リクエストに関連付けられた送信元ユーザＩＤ、送信先ユーザＩＤ、及び、値が「Ｒｅａｌ　Ｎａｍｅ　Ｒｅｑｕｅｓｔ」であるリクエスト種類データが関連付けられている。

　すると、ユーザ管理サーバ１０のフレンド管理データ登録部７２は、Ｓ３０２に示す処理で受信した親友リクエストに基づくフレンド管理データの更新を行う（Ｓ３０７）。

　Ｓ３０７に示す処理では、フレンド管理データ登録部７２は、例えば、第１の承諾通知の受信に応じて、当該第１の承諾通知に関連付けられている送信元ユーザＩＤをユーザＩＤとして含むフレンド管理データを特定する。そしてフレンド管理データ登録部７２は、特定されたフレンド管理データのフレンドユーザＩＤとして、当該第１の承諾通知に関連付けられている送信先ユーザＩＤを追加する。またフレンド管理データ登録部７２は、当該第１の承諾通知に関連付けられている送信先ユーザＩＤをユーザＩＤとして含むフレンド管理データを特定する。そしてフレンド管理データ登録部７２は、特定されたフレンド管理データのフレンドユーザＩＤとして、当該第１の承諾通知に関連付けられている送信元ユーザＩＤを追加する。

　そしてフレンド管理データ登録部７２は、例えば、第２の承諾通知の受信に応じて、当該第２の承諾通知に関連付けられている送信元ユーザＩＤをユーザＩＤとして含むフレンド管理データを特定する。そしてフレンド管理データ登録部７２は、特定されたフレンド管理データの実名公開ユーザＩＤとして、当該第２の承諾通知に関連付けられている送信先ユーザＩＤを追加する。またフレンド管理データ登録部７２は、当該第２の承諾通知に関連付けられている送信先ユーザＩＤを特定する。そしてフレンド管理データ登録部７２は、特定された送信先ユーザＩＤをユーザＩＤとして含むフレンド管理データの実名公開ユーザＩＤとして、当該第２の承諾通知に関連付けられている送信元ユーザＩＤを追加する。

　そして、ユーザ管理サーバ１０の関係リクエスト管理データ登録部６２が、Ｓ３０２に示す処理で受信した親友リクエストに対応付けられる関係リクエスト管理データを関係リクエスト管理データ記憶部５４から削除する（Ｓ３０８）。そして、本処理例に示す処理は終了される。Ｓ３０８に示す処理では、本実施形態では例えば、２つの関係リクエスト管理データが削除されることとなる。

　このようにして、申込ユーザと承諾ユーザとを互いに親友として登録されることとなる。

　なお上述のＳ３０２に示す処理でクライアント１２から送信される２つの関係リクエストは１つのパケットにより実装されても２つのパケットにより実装されても構わない。そして２つのパケットにより当該２つの関係リクエストが実装される場合には、上述のＳ３０３に示す処理では、パケットの受信の度に当該パケットに対応付けられる関係リクエスト管理データが生成されて記憶されても構わない。

　なお親友リクエストの実装は上述のものに限定されない。例えば、親友リクエストが、値が「Ｃｌｏｓｅ　Ｆｒｉｅｎｄ　Ｒｅｑｕｅｓｔ」であるリクエスト種類データが関連付けられた１つの関係リクエストとして実装されてもよい。この場合は上述のＳ３０２に示す処理において１つの関係リクエストが送信されることとなる。

　また上述のＳ３０３に示す処理で、図３０に示すような、リクエスト種類データの値として「Ｃｌｏｓｅ　Ｆｒｉｅｎｄ　Ｒｅｑｕｅｓｔ」が設定された関係リクエスト管理データが生成されても構わない。この場合、ユーザＩＤが「ａａａ００１」である申込ユーザによる、ユーザＩＤが「ｂｂｂ００２」である承諾ユーザに対する親友としての登録の申込が行われた際には、例えば図３０の最も上に示されている関係リクエスト管理データが記憶されることとなる。

　また上述のＳ３０６に示す処理でクライアント１２から送信される２つの承諾通知の代わりに、値が「Ｃｌｏｓｅ　Ｆｒｉｅｎｄ　Ｒｅｑｕｅｓｔ」であるリクエスト種類データが関連付けられた１つの承諾通知がクライアント１２から送信されるようにしてもよい。

　また本実施形態では例えば、承諾ユーザが行う所定の操作に応じて承諾ユーザが利用するクライアント１２のページ要求部８２がリクエスト一覧ページ２８の送信要求をユーザ管理サーバ１０に送信する。するとユーザ管理サーバ１０のページ生成部６６は、例えば当該送信要求に応じて承諾ユーザが利用するクライアント１２のディスプレイに表示されるリクエスト一覧ページ２８を表すデータを生成する。

　ここでページ生成部６６は、例えば、関係リクエスト管理データ記憶部５４に記憶されている、図２６に示す関係リクエスト管理データに基づいて、承諾ユーザが利用するクライアント１２のディスプレイに表示されるリクエスト一覧ページ２８を生成する。当該リクエスト一覧ページ２８には、例えば、承諾ユーザのユーザＩＤを送信元ユーザＩＤとして含む関係リクエスト管理データに対応付けられる送信リクエスト情報ＳＲが配置される。また当該リクエスト一覧ページ２８には、例えば、承諾ユーザのユーザＩＤを送信先ユーザＩＤとして含む関係リクエスト管理データに対応付けられる受信リクエスト情報ＲＲが配置される。

　ここで例えば、送信元ユーザＩＤと送信先ユーザＩＤとの組み合わせが同一であり、リクエスト種類データの値がそれぞれ「Ｆｒｉｅｎｄ　Ｒｅｑｕｅｓｔ」、「Ｒｅａｌ　Ｎａｍｅ　Ｒｅｑｕｅｓｔ」である２つの関係リクエスト管理データが記憶されているとする。この場合に、図１９に例示するように、当該２つの関係リクエスト管理データに対応付けられる１つの受信リクエスト情報ＲＲがリクエスト一覧ページ２８に配置されてもよい。そしてリクエスト一覧ページ２８の関係リクエストの種類を表す文字列Ｓ３として「Ｃｌｏｓｅ　Ｆｒｉｅｎｄ　Ｒｅｑｕｅｓｔ」が配置されてもよい。

　なおクライアント１２が親友リクエストの承諾機能を有していなくてもよい。この場合、上述の２つの関係リクエスト管理データが記憶されていても、リクエスト種類データの値が「Ｆｒｉｅｎｄ　Ｒｅｑｕｅｓｔ」である関係リクエスト管理データに対応付けられる受信リクエスト情報ＲＲがリクエスト一覧ページ２８に配置されてもよい。そして当該受信リクエスト情報ＲＲに対応付けられる承諾ボタンＢ３を選択する承諾操作が行われた際に、上述のＳ１０５～Ｓ１０８に示す処理と同様の処理が実行されてもよい。

　そしてその後、クライアント１２に、承諾ユーザに宛てた関係リクエストが送信されたことが通知されてもよい。そしてリクエスト種類データの値が「Ｒｅａｌ　Ｎａｍｅ　Ｒｅｑｕｅｓｔ」である関係リクエスト管理データに対応付けられる受信リクエスト情報ＲＲがリクエスト一覧ページ２８に配置されてもよい。そして当該受信リクエスト情報ＲＲに対応付けられる承諾ボタンＢ３を選択する承諾操作が行われた際に、上述のＳ２０５～Ｓ２０８に示す処理と同様の処理が実行されてもよい。

　なお実名リクエストの承諾機能を有していないクライアント１２については、上述のＳ１０５～Ｓ１０８に示す処理が実行された後に、クライアント１２に、承諾ユーザに宛てた関係リクエストが送信されたことが通知されなくてもよい。またリクエスト種類データの値が「Ｒｅａｌ　Ｎａｍｅ　Ｒｅｑｕｅｓｔ」である関係リクエスト管理データに対応付けられる受信リクエスト情報ＲＲがリクエスト一覧ページ２８に配置されなくてもよい。

　関係リクエスト管理データに含まれるリクエスト種類データの値として「Ｃｌｏｓｅ　Ｆｒｉｅｎｄ　Ｒｅｑｕｅｓｔ」が設定できるようにすると、親友登録申込操作に対応付けられる関係リクエスト管理データが２つ記憶される場合よりも記憶量が節約できる。また値が「Ｃｌｏｓｅ　Ｆｒｉｅｎｄ　Ｒｅｑｕｅｓｔ」であるリクエスト種類データが関連付けられた１つの関係リクエストとして親友リクエストが実装される場合は、親友リクエストが２つの関係リクエストとして実装される場合よりも通信量が節約できる。

　一方、親友登録申込操作に応じて２つの関係リクエスト管理データが記憶されるようにすると、上述したように親友リクエストや実名リクエストの承諾機能を有していないクライアント１２が存在しても互換性が保たれることとなる。また、親友登録申込操作に応じて２つの関係リクエスト管理データが記憶されるようにすると、リクエスト種類データの値として「Ｃｌｏｓｅ　Ｆｒｉｅｎｄ　Ｒｅｑｕｅｓｔ」が設定されないので、リクエスト種類データがとり得る値の数を節約することができる。

　本実施形態では例えば、申込ユーザが行う所定の操作に応じて申込ユーザが利用するクライアント１２のページ要求部８２が当該申込ユーザのフレンド一覧ページ３０の送信要求をユーザ管理サーバ１０に送信する。するとユーザ管理サーバ１０のページ生成部６６は、例えば当該送信要求に応じて申込ユーザが利用するクライアント１２のディスプレイに表示されるフレンド一覧ページ３０を表すデータを生成する。ここで本実施形態に係るユーザ管理サーバ１０で行われる、フレンド一覧ページ３０を表すデータの生成処理の流れの一例を図３１に示すフロー図を参照しながら説明する。

　まずページ生成部６６は、申込ユーザのユーザＩＤを含むフレンド管理データを特定する（Ｓ４０１）。そしてページ生成部６６は、Ｓ４０１に示す処理で特定されたフレンド管理データのフレンドユーザＩＤとして設定されているユーザＩＤのうち、下記のＳ４０３～Ｓ４０５に示す処理がまだ実行されていないものを１つ特定する（Ｓ４０２）。

　そしてページ生成部６６は、Ｓ４０２に示す処理で特定されたユーザＩＤが、Ｓ４０１に示す処理で特定されたフレンド管理データの実名公開ユーザＩＤとして設定されているか否かを確認する（Ｓ４０３）。設定されていることが確認された場合は（Ｓ４０３：Ｙ）、ページ生成部６６は、当該ユーザについてはフレンド情報ＦＩｂを生成することを決定する（Ｓ４０４）。Ｓ４０４に示す処理では例えば、フレンド情報ＦＩｂに当該ユーザのユーザＩＤを表す文字列Ｓ１、当該ユーザの実名データが示す名称を表す文字列Ｓ２、及び、写真画像Ｉ２が配置されることが決定される。

　一方、Ｓ４０３に示す処理で設定されていないことが確認された場合は（Ｓ４０３：Ｎ）、ページ生成部６６は、当該ユーザについてはフレンド情報ＦＩａを生成することを決定する（Ｓ４０５）。Ｓ４０５に示す処理では例えば、フレンド情報ＦＩａに当該ユーザのユーザＩＤを表す文字列Ｓ１、及び、アイコン画像Ｉ１が配置されることが決定される。

　そしてページ生成部６６は、Ｓ４０１に示す処理で特定されたフレンド管理データのフレンドユーザＩＤとして設定されているユーザＩＤのうち、Ｓ４０３～Ｓ４０５に示す処理が実行されていないものがあるか否かを確認する（Ｓ４０６）。あることが確認された場合は（Ｓ４０６：Ｙ）、ページ生成部６６は、Ｓ４０２以降の処理を再度実行する。

　一方、ないことが確認された場合は（Ｓ４０６：Ｎ）、上記の処理による決定に従ってフレンド情報ＦＩａやフレンド情報ＦＩｂが配置されたフレンド一覧ページ３０を表すデータを生成する（Ｓ４０７）。そして、本処理例に示す処理は終了される。

　ページ送信部６８は、このようにして生成されたフレンド一覧ページ３０を表すデータを、申込ユーザのクライアント１２に送信する。すると申込ユーザのクライアント１２のページ受信部８４は、当該データを受信する。そして申込ユーザのクライアント１２の表示処理部８６は、当該データを表すページをディスプレイに表示させる。

［変形例］
　なお、本発明は上述の実施形態に限定されるものではない。

　例えばフレンド管理データにフレンドユーザＩＤや実名公開ユーザＩＤとは別に親友ＩＤが設定可能であっても構わない。そしてフレンドとしての登録の申込がされたユーザが当該申込を承諾した場合に、申込を行ったユーザのフレンド管理データの親友ＩＤとして、承諾を行ったユーザのユーザＩＤが登録されてもよい。また、承諾を行ったユーザのフレンド管理データの親友ＩＤとして、申込を行ったユーザのユーザＩＤが登録されてもよい。こうすれば、フレンドとしての登録を経て実名公開ユーザとしての登録がされたユーザと親友としての登録がされたユーザとを別に管理することが可能となる。

　また例えば、ユーザ管理データに住所、生年月日、年齢などといった他の個人情報が設定できても構わない。そして、フレンド管理データに、これらの個人情報のそれぞれに対応付けられた、当該個人情報を互いに公開するユーザＩＤを設定できても構わない。そして例えば申込ユーザが行う、特定の個人情報の公開の申込操作を、承諾ユーザが承諾した場合には、申込ユーザと承諾ユーザとの間で互いに当該個人情報が公開されてもよい。

　またユーザ管理データに設定される個人情報毎に機密度を設定できても構わない。そして、フレンド管理データに、互いに公開する個人情報の機密度の範囲に対応付けられたユーザＩＤを設定できても構わない。そして例えば申込ユーザが行う、ある機密度よりも機密度が小さな個人情報の公開の申込操作を、承諾ユーザが承諾した場合には、申込ユーザと承諾ユーザとの間で互いに当該機密度よりも小さな個人情報が公開されてもよい。

　また、ユーザ管理サーバ１０とクライアント１２の役割分担は上述のものに限定されない。また、ユーザ管理サーバ１０やクライアント１２が複数の筐体から構成されていてもよい。

　また、上記の具体的な文字列や図面中の具体的な文字列は例示であり、これらの文字列には限定されない。

Claims

　ユーザを指定する第１の操作に応じて、当該ユーザをニックネームが開示される第１の関係にあるユーザとして登録する第１登録部と、
　前記第１の関係にあるユーザとして登録されているユーザを指定する第２の操作に応じて、当該ユーザをさらに実名も開示される第２の関係にあるユーザとして登録する第２登録部と、
　前記第１の関係にあるユーザとして登録されていないユーザを指定する第３の操作に応じて、当該ユーザを前記第１の関係及び前記第２の関係にあるユーザとして登録する第３登録部と、
　を含むことを特徴とするユーザ管理サーバ。
　前記第３登録部は、実名が表示されているユーザを指定する操作に応じて、当該ユーザを前記第１の関係及び前記第２の関係にあるユーザとして登録する、
　ことを特徴とする請求項１に記載のユーザ管理サーバ。
　前記第１登録部は、前記第１の関係にあるユーザの候補に関する情報の一覧において実名が表示されていないユーザを指定する操作に応じて、当該ユーザを前記第１の関係にあるユーザとして登録し、
　前記第３登録部は、前記候補に関する情報の一覧において実名が表示されているユーザを指定する操作に応じて、当該ユーザを前記第１の関係及び前記第２の関係にあるユーザとして登録する、
　ことを特徴とする請求項１に記載のユーザ管理サーバ。
　ユーザをニックネームが開示される第１の関係にあるユーザとして指定する第１の操作を受け付ける第１受付部と、
　前記第１の操作によって指定されたユーザをさらに実名も開示される第２の関係にあるユーザとして指定する第２の操作を受け付ける第２受付部と、
　前記第１の操作によって指定されていないユーザを前記第１の関係及び前記第２の関係にあるユーザとして指定する第３の操作を受け付ける第３受付部と、
　前記第２の関係にあるユーザの実名が含まれる、前記第１の関係にあるユーザに関する情報の一覧を表示させる表示処理部と、
　を含むことを特徴とする端末。
　ユーザを指定する第１の操作に応じて、当該ユーザをニックネームが開示される第１の関係にあるユーザとして登録する第１登録部と、
　前記第１の関係にあるユーザとして登録されているユーザを指定する第２の操作に応じて、当該ユーザをさらに実名も開示される第２の関係にあるユーザとして登録する第２登録部と、
　前記第１の関係にあるユーザとして登録されていないユーザを指定する第３の操作に応じて、当該ユーザを前記第１の関係及び前記第２の関係にあるユーザとして登録する第３登録部と、
　前記第２の関係にあるユーザとして登録されているユーザの実名が含まれる、前記第１の関係にあるユーザに関する情報の一覧を表示させる表示処理部と、
　を含むことを特徴とする情報表示システム。
　ユーザを指定する第１の操作に応じて、当該ユーザをニックネームが開示される第１の関係にあるユーザとして登録するステップと、
　前記第１の関係にあるユーザとして登録されているユーザを指定する第２の操作に応じて、当該ユーザをさらに実名も開示される第２の関係にあるユーザとして登録するステップと、
　前記第１の関係にあるユーザとして登録されていないユーザを指定する第３の操作に応じて、当該ユーザを前記第１の関係及び前記第２の関係にあるユーザとして登録するステップと、
　を含むことを特徴とするユーザ管理方法。
　ユーザをニックネームが開示される第１の関係にあるユーザとして指定する第１の操作を受け付けるステップと、
　前記第１の操作によって指定されたユーザをさらに実名も開示される第２の関係にあるユーザとして指定する第２の操作を受け付けるステップと、
　前記第１の操作によって指定されていないユーザを前記第１の関係及び前記第２の関係にあるユーザとして指定する第３の操作を受け付けるステップと、
　前記第２の関係にあるユーザの実名が含まれる、前記第１の関係にあるユーザに関する情報の一覧を表示させるステップと、
　を含むことを特徴とする情報表示方法。
　ユーザをニックネームが開示される第１の関係にあるユーザとして指定する第１の操作を受け付ける手順、
　前記第１の操作によって指定されたユーザをさらに実名も開示される第２の関係にあるユーザとして指定する第２の操作を受け付ける手順、
　前記第１の操作によって指定されていないユーザを前記第１の関係及び前記第２の関係にあるユーザとして指定する第３の操作を受け付ける手順、
　前記第２の関係にあるユーザの実名が含まれる、前記第１の関係にあるユーザに関する情報の一覧を表示させる手順、
　をコンピュータに実行させることを特徴とするプログラム。