Processing

Please wait...

Settings

Settings

Goto Application

1. WO2016136626 - USER MANAGEMENT SERVER, TERMINAL, INFORMATION DISPLAY SYSTEM, USER MANAGEMENT METHOD, INFORMATION DISPLAY METHOD, PROGRAM, AND INFORMATION STORAGE MEDIUM

Document

明 細 書

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

技術分野

0001  

背景技術

0002   0003  

先行技術文献

特許文献

0004  

発明の概要

発明が解決しようとする課題

0005   0006  

課題を解決するための手段

0007   0008   0009   0010   0011   0012   0013   0014   0015  

図面の簡単な説明

0016  

発明を実施するための形態

0017   0018   0019   0020   0021   0022   0023   0024   0025   0026   0027   0028   0029   0030   0031   0032   0033   0034   0035   0036   0037   0038   0039   0040   0041   0042   0043   0044   0045   0046   0047   0048   0049   0050   0051   0052   0053   0054   0055   0056   0057   0058   0059   0060   0061   0062   0063   0064   0065   0066   0067   0068   0069   0070   0071   0072   0073   0074   0075   0076   0077   0078   0079   0080   0081   0082   0083   0084   0085   0086   0087   0088   0089   0090   0091   0092   0093   0094   0095   0096   0097   0098   0099   0100   0101   0102   0103   0104   0105   0106   0107   0108   0109   0110   0111   0112   0113   0114   0115   0116   0117   0118   0119   0120   0121   0122   0123   0124   0125   0126   0127   0128   0129   0130   0131   0132   0133   0134   0135   0136   0137   0138   0139   0140   0141   0142   0143   0144   0145   0146   0147   0148   0149   0150   0151   0152   0153   0154   0155   0156   0157   0158   0159   0160   0161   0162   0163   0164   0165   0166   0167   0168   0169   0170   0171   0172   0173   0174   0175   0176   0177   0178   0179   0180   0181   0182   0183   0184   0185   0186   0187   0188   0189   0190   0191   0192   0193   0194   0195   0196  

請求の範囲

1   2   3   4   5   6   7   8  

図面

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23   24   25   26   27   28   29   30   31  

明 細 書

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

技術分野

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

背景技術

[0002]
 近年、複数のユーザがネットワークを介して互いにメッセージをやりとりしたり、一緒にゲームをプレイしたりすることのできるソーシャルネットワーク型のオンラインサービスが登場している(例えば特許文献1参照)。このようなサービスでは、他のユーザを自分のフレンド(友人)として登録することで、登録されたフレンドとコミュニケーションをとることができることとなる。
[0003]
 上述したサービスでは、自分のフレンドとして登録されるユーザには、多様な関係性の人物が含まれうる。例えば、ネットワーク上で知り合っただけの人物と、実社会で元々知り合いである人物の双方がフレンドとして登録される場合がある。このような場合に、関係の強いユーザには実名を公開してもよいが、関係の薄いユーザには実名を公開したくない、など自分自身を他者が識別する名称そのものについても、相手との関係によって使い分けたいというニーズがある。このようなニーズを満たすため、特許文献1には、ユーザ間で公開される自身の名称を制御できる技術が開示されている。

先行技術文献

特許文献

[0004]
特許文献1 : 国際公開第2014/128836号

発明の概要

発明が解決しようとする課題

[0005]
 しかし特許文献1に記載の技術では、実名を公開するユーザを登録するためには、その登録操作の前に実名を公開しないフレンドとして当該ユーザを登録する操作を行う必要があり、ユーザは手間がかかっていた。
[0006]
 本発明は上記実情に鑑みてなされたものであって、その目的の一つは、実名を公開するユーザを登録する際のユーザの手間が従来技術よりも低減されるユーザ管理サーバ、端末、情報表示システム、ユーザ管理方法、情報表示方法、プログラム及び情報記憶媒体を提供することにある。

課題を解決するための手段

[0007]
 上記課題を解決するために、本発明に係るユーザ管理サーバは、ユーザを指定する第1の操作に応じて、当該ユーザをニックネームが開示される第1の関係にあるユーザとして登録する第1登録部と、前記第1の関係にあるユーザとして登録されているユーザを指定する第2の操作に応じて、当該ユーザをさらに実名も開示される第2の関係にあるユーザとして登録する第2登録部と、前記第1の関係にあるユーザとして登録されていないユーザを指定する第3の操作に応じて、当該ユーザを前記第1の関係及び前記第2の関係にあるユーザとして登録する第3登録部と、を含む。
[0008]
 また、本発明に係る端末は、ユーザをニックネームが開示される第1の関係にあるユーザとして指定する第1の操作を受け付ける第1受付部と、前記第1の操作によって指定されたユーザをさらに実名も開示される第2の関係にあるユーザとして指定する第2の操作を受け付ける第2受付部と、前記第1の操作によって指定されていないユーザを前記第1の関係及び前記第2の関係にあるユーザとして指定する第3の操作を受け付ける第3受付部と、前記第2の関係にあるユーザの実名が含まれる、前記第1の関係にあるユーザに関する情報の一覧を表示させる表示処理部と、を含む。
[0009]
 また、本発明に係る情報表示システムは、ユーザを指定する第1の操作に応じて、当該ユーザをニックネームが開示される第1の関係にあるユーザとして登録する第1登録部と、前記第1の関係にあるユーザとして登録されているユーザを指定する第2の操作に応じて、当該ユーザをさらに実名も開示される第2の関係にあるユーザとして登録する第2登録部と、前記第1の関係にあるユーザとして登録されていないユーザを指定する第3の操作に応じて、当該ユーザを前記第1の関係及び前記第2の関係にあるユーザとして登録する第3登録部と、前記第2の関係にあるユーザとして登録されているユーザの実名が含まれる、前記第1の関係にあるユーザに関する情報の一覧を表示させる表示処理部と、を含む。
[0010]
 また、本発明に係るユーザ管理方法は、ユーザを指定する第1の操作に応じて、当該ユーザをニックネームが開示される第1の関係にあるユーザとして登録するステップと、前記第1の関係にあるユーザとして登録されているユーザを指定する第2の操作に応じて、当該ユーザをさらに実名も開示される第2の関係にあるユーザとして登録するステップと、前記第1の関係にあるユーザとして登録されていないユーザを指定する第3の操作に応じて、当該ユーザを前記第1の関係及び前記第2の関係にあるユーザとして登録するステップと、を含む。
[0011]
 また、本発明に係る情報表示方法は、ユーザをニックネームが開示される第1の関係にあるユーザとして指定する第1の操作を受け付けるステップと、前記第1の操作によって指定されたユーザをさらに実名も開示される第2の関係にあるユーザとして指定する第2の操作を受け付けるステップと、前記第1の操作によって指定されていないユーザを前記第1の関係及び前記第2の関係にあるユーザとして指定する第3の操作を受け付けるステップと、前記第2の関係にあるユーザの実名が含まれる、前記第1の関係にあるユーザに関する情報の一覧を表示させるステップと、を含む。
[0012]
 また、本発明に係るプログラムは、ユーザをニックネームが開示される第1の関係にあるユーザとして指定する第1の操作を受け付ける手順、前記第1の操作によって指定されたユーザをさらに実名も開示される第2の関係にあるユーザとして指定する第2の操作を受け付ける手順、前記第1の操作によって指定されていないユーザを前記第1の関係及び前記第2の関係にあるユーザとして指定する第3の操作を受け付ける手順、前記第2の関係にあるユーザの実名が含まれる、前記第1の関係にあるユーザに関する情報の一覧を表示させる手順、をコンピュータに実行させる。
[0013]
 なお上述のプログラムは、コンピュータ読み取り可能な情報記憶媒体に記憶されてもよい。
[0014]
 本発明の一態様では、前記第3登録部は、実名が表示されているユーザを指定する操作に応じて、当該ユーザを前記第1の関係及び前記第2の関係にあるユーザとして登録する。
[0015]
 また、本発明の一態様では、前記第1登録部は、前記第1の関係にあるユーザの候補に関する情報の一覧において実名が表示されていないユーザを指定する操作に応じて、当該ユーザを前記第1の関係にあるユーザとして登録し、前記第3登録部は、前記候補に関する情報の一覧において実名が表示されているユーザを指定する操作に応じて、当該ユーザを前記第1の関係及び前記第2の関係にあるユーザとして登録する。

図面の簡単な説明

[0016]
[図1] 本発明の一実施形態に係る情報処理システムの全体構成の一例を示す図である。
[図2] ユーザ管理データの一例を示す図である。
[図3] フレンド管理データの一例を示す図である。
[図4] 検索ページの一例を示す図である。
[図5] プロファイルページの一例を示す図である。
[図6] フレンドリクエスト送信ページの一例を示す図である。
[図7] 通知ページの一例を示す図である。
[図8] リクエスト一覧ページの一例を示す図である。
[図9] フレンド管理データの一例を示す図である。
[図10] フレンド一覧ページの一例を示す図である。
[図11] プロファイルページの一例を示す図である。
[図12] 実名リクエスト送信ページの一例を示す図である。
[図13] 通知ページの一例を示す図である。
[図14] リクエスト一覧ページの一例を示す図である。
[図15] フレンド管理データの一例を示す図である。
[図16] プロファイルページの一例を示す図である。
[図17] 親友リクエスト送信ページの一例を示す図である。
[図18] 通知ページの一例を示す図である。
[図19] リクエスト一覧ページの一例を示す図である。
[図20] フレンド管理データの一例を示す図である。
[図21] FoF(Friend of Friend)ページの一例を示す図である。
[図22] YMK(You May Know)ページの一例を示す図である。
[図23] SNS(Social Networking Service)フレンド発見ページの一例を示す図である。
[図24] 親友リクエスト送信ページの一例を示す図である。
[図25] 本発明の一実施形態に係る情報処理システムで実装される機能の一例を示す機能ブロック図である。
[図26] 関係リクエスト管理データの一例を示す図である。
[図27] 本実施形態に係る情報処理システムで行われる処理の流れの一例を示すフロー図である。
[図28] 本実施形態に係る情報処理システムで行われる処理の流れの一例を示すフロー図である。
[図29] 本実施形態に係る情報処理システムで行われる処理の流れの一例を示すフロー図である。
[図30] 関係リクエスト管理データの一例を示す図である。
[図31] 本実施形態に係る情報処理システムで行われる処理の流れの一例を示すフロー図である。

発明を実施するための形態

[0017]
 以下、本発明の一実施形態について、図面を参照しながら説明する。
[0018]
[構成]
 図1は、本発明の一実施形態に係る情報処理システム1の全体構成の一例を示す図である。図1に示すように、本実施形態に係る情報処理システム1は、いずれもコンピュータを中心に構成されたユーザ管理サーバ10と複数のクライアント12とを含んでいる。ユーザ管理サーバ10、クライアント12は、インターネットなどのコンピュータネットワーク14に接続されている。そして、ユーザ管理サーバ10、クライアント12は、互いに通信可能になっている。
[0019]
 本実施形態に係る情報処理システム1は、例えば複数のユーザが参加して一緒にプレイできるオンラインゲームサービスなどといった、複数のユーザに対するソーシャルネットワーク型のオンラインサービスを提供する。
[0020]
 ユーザ管理サーバ10は、本実施形態に係るオンラインサービスを利用するユーザに関する情報を管理するサーバコンピュータである。図1に示すように、本実施形態に係るユーザ管理サーバ10は、例えば、制御部10a、記憶部10b、通信部10c、を含む。制御部10aは、例えばCPU等のプログラム制御デバイスであって、記憶部10bに記憶されたプログラムに従って各種の情報処理を実行する。記憶部10bは、例えばROMやRAM等の記憶素子やハードディスクドライブなどである。通信部10cは、例えばコンピュータネットワーク14を介してクライアント12との間でデータを授受するための通信インタフェースである。ユーザ管理サーバ10は、通信部10cを経由して各クライアント12との間で情報の送受信を行う。
[0021]
 クライアント12は、本実施形態に係るオンラインサービスを利用する各ユーザが利用する情報処理端末であって、例えばパーソナルコンピュータ、ゲームコンソール、テレビ受像機、携帯型ゲーム装置、スマートフォン、タブレット端末、などである。図1に示すように、本実施形態に係るクライアント12は、例えば、制御部12a、記憶部12b、通信部12c、出力部12d、入力部12e、を含む。制御部12aは、例えばCPU等のプログラム制御デバイスであって、記憶部12bに記憶されたプログラムに従って各種の情報処理を実行する。本実施形態に係る制御部12aには、CPUから供給されるグラフィックスコマンドやデータに基づいてフレームバッファに画像を描画するGPU(Graphics Processing Unit)も含まれている。記憶部12bは、例えばROMやRAM等の記憶素子やハードディスクドライブなどである。記憶部12bには、制御部12aによって実行されるプログラムなどが記憶される。また、本実施形態に係る記憶部12bには、GPUにより画像が描画されるフレームバッファの領域が確保されている。通信部12cは、例えばコンピュータネットワーク14を介してユーザ管理サーバ10との間でデータを授受するための通信インタフェースである。クライアント12は、通信部12cを経由してユーザ管理サーバ10や他のクライアント12との間で情報の送受信を行う。出力部12dは、例えば制御部12aから入力される指示に従って情報を表示出力するディスプレイや音声出力するスピーカ等である。入力部12eは、例えばユーザが行った操作の内容を制御部12aに出力するゲームコントローラ、タッチパッド、マウス、キーボード、マイク等である。
[0022]
[ユーザ管理データ]
 本実施形態では、ユーザ管理サーバ10においてユーザやユーザ間の関係に関する情報が管理される。図2は、本実施形態に係るオンラインサービスを利用するユーザに関する情報を管理するためのユーザ管理データの一例を示す図である。本実施形態では例えば、ユーザが本実施形態に係るオンラインサービスの利用を開始する際に当該ユーザによって当該ユーザのユーザ管理データが登録されるようになっている。
[0023]
 図2に示すように、本実施形態に係るユーザ管理データには、例えば、ユーザID、実名データ、アイコンファイル名データ、写真画像ファイル名データ、端末ID、実名公開ページID、が含まれている。
[0024]
 ユーザ管理データに含まれるユーザIDは、当該オンラインサービスを利用するユーザを一意に識別する識別名称である。本実施形態に係るオンラインサービスでは、当該オンラインサービスを利用するユーザは、当該ユーザのニックネームをユーザIDとして登録することが想定されている。そのため本実施形態では、ユーザ管理データと当該オンラインサービスを利用するユーザとは1対1で対応付けられることとなる。
[0025]
 ユーザ管理データに含まれる実名データは、当該ユーザ管理データに対応付けられるユーザによって登録された名称を示すデータである。本実施形態に係るオンラインサービスでは、当該オンラインサービスを利用するユーザは、当該ユーザの実名を実名データの値として登録することが想定されている。なおクライアント12によっては実名を登録する機能を有さないものがある。このようなクライアント12を利用するユーザについては、図2に示されている、ユーザIDが「iii010」であるユーザ管理データのように、実名データの値は登録されないこととなる。
[0026]
 ユーザ管理データに含まれるアイコンファイル名データは、当該ユーザ管理データに対応付けられるユーザの第1のプロファイル画像であるアイコン画像I1(図4等参照)のファイル名を示すデータである。アイコン画像I1は例えば情報処理システム1において予め用意されたアイコンの画像などである。
[0027]
 ユーザ管理データに含まれる写真画像ファイル名データは、当該ユーザ管理データに対応付けられるユーザの第2のプロファイル画像である写真画像I2(図4等参照)のファイル名を示すデータである。写真画像I2は、ユーザがアップロードして登録した画像であって、ユーザ自身を撮影した写真であることが想定されている。
[0028]
 ユーザ管理データに含まれる端末IDは、当該ユーザ管理データに対応付けられるユーザが利用するクライアント12を識別する識別情報である。図2に示すように、本実施形態では、1のユーザが、1のクライアント12を利用する場合も複数のクライアント12(例えばゲームコンソール及びスマートフォン)を利用する場合も想定されている。
[0029]
 ユーザ管理データに含まれる実名公開ページIDは、当該ユーザ管理データに対応付けられるユーザが、当該ユーザ管理データに含まれる実名データが示す名称をすべてのユーザに公開することを許可するページを識別する識別情報である。本実施形態では、実名公開ページIDによって識別されるページでは、当該ユーザの実名データが示す名称は、すべてのユーザが閲覧可能となる。図2に示すように本実施形態では複数の実名公開ページIDを設定することができるようになっている。
[0030]
 例えば、ユーザ管理データに含まれる実名公開ページIDに「1」が設定されていることとする。この場合は、本実施形態では例えば、当該ユーザ管理データに対応付けられるユーザの実名データが示す名称は、後述する検索ページ20(図4参照)ですべてのユーザが閲覧可能となる。また当該ユーザの実名データの値は、検索ページ20におけるユーザの検索での検索結果になり得ることとなる。
[0031]
 また例えば、ユーザ管理データに含まれる実名公開ページIDに「2」が設定されていることとする。この場合は、本実施形態では例えば、当該ユーザ管理データに対応付けられるユーザの実名データが示す名称は、後述するFoF(Friend of Friend)ページ36(図21参照)ですべてのユーザが閲覧可能となる。
[0032]
 また例えば、ユーザ管理データに含まれる実名公開ページIDに「3」が設定されていることとする。この場合は、本実施形態では例えば、当該ユーザ管理データに対応付けられるユーザの実名データが示す名称は、後述するYMK(You May Know)ページ38(図22参照)ですべてのユーザが閲覧可能となる。
[0033]
 また例えば、ユーザ管理データに含まれる実名公開ページIDに「4」が設定されていることとする。この場合は、本実施形態では例えば、当該ユーザ管理データに対応付けられるユーザの実名データが示す名称は、後述るSNS(Social Networking Service)フレンド発見ページ40(図23参照)ですべてのユーザが閲覧可能となる。
[0034]
[フレンド管理データ]
 また本実施形態では、ユーザ管理データが登録されているユーザは、他のユーザをフレンド(友人)として登録できるようになっている。本実施形態では、ユーザによって登録されたフレンドは、図3に示すフレンド管理データによって管理されることとなる。
[0035]
 図3に示すように、本実施形態に係るフレンド管理データには、例えば、ユーザID、フレンドユーザID、実名公開ユーザID、が含まれる。
[0036]
 フレンド管理データに含まれるユーザIDは、当該オンラインサービスを利用するユーザを一意に識別する識別名称である。そのため本実施形態では、フレンド管理データと当該オンラインサービスを利用するユーザとは1対1で対応付けられることとなる。また本実施形態では、ユーザ管理データに含まれるユーザIDとフレンド管理データに含まれるユーザIDによってユーザ管理データとフレンド管理データとは関連付けられることとなる。
[0037]
 フレンド管理データに含まれるフレンドユーザIDは、当該フレンド管理データに含まれるユーザIDによって識別されるユーザによってフレンドとして登録されたユーザのユーザIDである。以下、フレンド管理データにおいてフレンドとして登録されたユーザを、フレンドユーザと呼ぶこととする。図3に示すように本実施形態では、複数のユーザIDをフレンドユーザIDとして登録できるようになっている。
[0038]
 フレンド管理データに含まれる実名公開ユーザIDは、当該フレンド管理データに含まれるユーザIDによって識別されるユーザによって実名データが示す名称を互いに公開するユーザとして登録されたユーザのユーザIDである。以下、フレンド管理データにおいて実名データが示す名称を互いに公開するユーザとして登録されたユーザを、実名公開ユーザと呼ぶこととする。本実施形態では、ユーザと、当該ユーザの実名公開ユーザとの間では、上述した実名公開ページIDにより識別されるページであるか否かを問わず実名データが示す名称が互いに公開されることとなる。図3に示すように本実施形態では、複数のユーザIDを実名公開ユーザIDとして登録できるようになっている。また本実施形態では、実名公開ユーザは、フレンドユーザとして必ず登録されていることとする。すなわちフレンド管理データにおいて実名公開ユーザIDとして登録されているユーザIDは、必ずフレンドユーザIDとしても登録されていることとする。
[0039]
 なお本実施形態に係るユーザ管理データやフレンド管理データは、ユーザ管理サーバ10の記憶部10bに記憶される。
[0040]
[関係リクエストの概要]
 本実施形態では、ユーザは、当該ユーザのフレンドユーザではないユーザに対して、フレンドとしての登録の申込を行えるようになっている。そして、フレンドとしての登録の申込を受けたユーザが当該申込を承諾した場合には、申込を行ったユーザと承諾を行ったユーザとは互いにフレンドユーザとして関連付けられることとなる。本実施形態では例えば、申込を行ったユーザのフレンド管理データのフレンドユーザIDとして、承諾を行ったユーザのユーザIDが登録される。また、承諾を行ったユーザのフレンド管理データのフレンドユーザIDとして、申込を行ったユーザのユーザIDが登録される。
[0041]
 また本実施形態では、ユーザは、当該ユーザのフレンドユーザではあるが実名公開ユーザではないユーザに対して、実名公開の申込を行えるようになっている。実名公開の申込を受けたユーザが当該申込を承諾した場合には、申込を行ったユーザと承諾を行ったユーザとは互いに実名公開ユーザとして関連付けられることとなる。本実施形態では例えば、申込を行ったユーザのフレンド管理データの実名公開ユーザIDとして、承諾を行ったユーザのユーザIDが登録される。また、承諾を行ったユーザのフレンド管理データの実名公開ユーザIDとして、申込を行ったユーザのユーザIDが登録される。
[0042]
 また本実施形態では、ユーザは、当該ユーザのフレンドユーザではないユーザに対して、親友としての登録の申込を行えるようになっている。親友としての登録の申込を受けたユーザが当該申込を承諾した場合には、申込を行ったユーザと承諾を行ったユーザとは互いにフレンドユーザとして関連付けられるとともに実名公開ユーザとしても関連付けられる。本実施形態では例えば、申込を行ったユーザのフレンド管理データのフレンドユーザID及び実名公開ユーザIDとして、承諾を行ったユーザのユーザIDが登録される。また、承諾を行ったユーザのフレンド管理データのフレンドユーザID及び実名公開ユーザIDとして、申込を行ったユーザのユーザIDが登録される。
[0043]
 このように本実施形態に係るフレンド管理データにおいては、実名公開の申込と承諾が行われたユーザ間の関係と親友としての登録の申込と承諾が行われたユーザ間の関係とは同等に取り扱われることとなる。
[0044]
 以下、フレンドとしての登録の申込、実名公開の申込、又は、親友としての登録の申込を行うユーザを申込ユーザと呼び、当該申込を承諾するユーザを承諾ユーザと呼ぶこととする。そして本実施形態では、申込ユーザがフレンドとしての登録の申込操作を行った場合に、申込ユーザのクライアント12から承諾ユーザのクライアント12に宛ててリクエストが送信される。以下、当該リクエストをフレンドリクエストと呼ぶこととする。また本実施形態では、申込ユーザが実名公開の申込操作を行った場合に、申込ユーザのクライアント12から承諾ユーザのクライアント12に宛ててリクエストが送信される。以下、当該リクエストを実名リクエストと呼ぶこととする。また本実施形態では、申込ユーザが親友としての登録の申込操作を行った場合に、申込ユーザのクライアント12から承諾ユーザのクライアント12に宛ててリクエストが送信される。以下、当該リクエストを親友リクエストと呼ぶこととする。そして、フレンドリクエスト、実名リクエスト、親友リクエストを総称して、以下、関係リクエストと呼ぶこととする。
[0045]
[フレンドとしての登録の申込と承諾]
 ここで、ユーザIDが「aaa001」であるユーザが申込ユーザであり、ユーザIDが「geo007」であるユーザが承諾ユーザである場合における、フレンドとしての登録の申込と承諾の一例について説明する。なお、当該申込及び当該承諾が行われる前においては、図3に例示するフレンド管理データがユーザ管理サーバ10の記憶部10bに記憶されていることとする。
[0046]
 図4は、申込ユーザが利用するクライアント12のディスプレイに表示される検索ページ20の一例を示す図である。当該検索ページ20では、オンスクリーンキーボードKを介して検索条件となる文字列を検索条件入力フォームF1に入力できるようになっている。そして検索条件である文字列が入力されると、ユーザIDが示す文字列が検索条件である文字列と部分一致又は完全一致するユーザに関する情報が検索結果情報RIとして検索ページ20内に配置される。このようにして本実施形態では、検索ページ20には検索結果情報RIの一覧が配置されることとなる。
[0047]
 また本実施形態では、実名公開ユーザ、及び、ユーザ管理データに含まれる実名公開ページIDに「1」が設定されているユーザについては、ユーザIDに加え、実名データが示す名称も検索対象となる。そのためこのようなユーザについては、実名データが示す文字列が検索条件である文字列と部分一致又は完全一致する場合についても、当該ユーザに関する情報が検索結果情報RIとして検索ページ20内に配置されることとなる。
[0048]
 本実施形態では、実名データが示す名称が検索対象とならないユーザについては、検索結果情報RIaとして、当該ユーザのユーザIDを表す文字列S1、及び、アイコン画像I1が配置される。また本実施形態では、実名データが示す名称も検索対象となるユーザについては、検索結果情報RIbとして、当該ユーザのユーザIDを表す文字列S1、当該ユーザの実名データが示す名称を表す文字列S2、及び、写真画像I2が配置される。
[0049]
 本実施形態では、申込ユーザは、検索ページ20に配置されたカーソルCを移動させる操作を行うことにより、検索結果情報RIの選択を行えるようになっている。本実施形態では、図4に示すように、選択対象である検索結果情報RIの周囲にはカーソルCが表示される。ここで申込ユーザが所定の決定操作を行うと、カーソルCによって囲まれている検索結果情報RIが選択された検索結果情報RIとして決定される。ここでは例えばユーザIDが「geo007」である承諾ユーザの検索結果情報RIaが選択されたこととする。すると、選択された検索結果情報RIaに対応付けられるユーザのプロファイル情報が配置された、図5に例示するプロファイルページ22が、申込ユーザが利用するクライアント12のディスプレイに表示される。
[0050]
 本実施形態では、実名データが示す名称を表す文字列S2が配置されていない検索結果情報RIaが選択された場合には、当該検索結果情報RIaに配置されている文字列S1及びアイコン画像I1が配置されたプロファイルページ22が表示される。そのため、図5に例示するプロファイルページ22には、選択された検索結果情報RIaに対応付けられるユーザのユーザIDを表す文字列S1及びアイコン画像I1が配置されることとなる。
[0051]
 また本実施形態では、選択された検索結果情報RIaに文字列S2が配置されておらず、また当該検索結果情報RIaに対応付けられるユーザがフレンドユーザではない場合には、フレンドリクエストボタンB1が配置されたプロファイルページ22が表示される。そのため、図5に例示するプロファイルページ22には、フレンドリクエストボタンB1が配置されることとなる。
[0052]
 以上で説明したように、本実施形態では、ユーザ管理データに含まれる実名公開ページIDの設定によって、当該ユーザの実名データが示す名称をすべてのユーザに検索対象として公開するか否かが制御できることとなる。また実名公開ページIDの設定によって、当該ユーザの写真画像I2をすべてのユーザに公開するか否かも制御できることとなる。
[0053]
 またユーザは、当該ユーザの実名公開ユーザのユーザIDを覚えていなくても実名は覚えているものと思われる。本実施形態では、実名公開ユーザについては実名データが示す名称によるユーザの検索が可能であるので、ユーザは、実名公開ユーザの検索を容易に行えることとなる。また実名公開ユーザについては写真画像I2が検索結果情報RIbとして配置されるので、検索結果情報RIの一覧のなかから所望の実名公開ユーザを見つけることが容易となる。
[0054]
 図5に例示するプロファイルページ22が表示されている際に申込ユーザがフレンドリクエストボタンB1を選択する操作を行うと、図6に例示するフレンドリクエスト送信ページ24が、申込ユーザが利用するクライアント12のディスプレイに表示される。図6に例示するフレンドリクエスト送信ページ24には、選択された検索結果情報RIaに対応付けられるユーザのユーザIDを表す文字列S1、及び、アイコン画像I1が配置される。また当該フレンドリクエスト送信ページ24には、メッセージ入力フォームF2、及び、送信ボタンB2も配置される。メッセージ入力フォームF2には、デフォルトのメッセージが予め入力されており、ユーザは当該メッセージを編集することができるようになっている。
[0055]
 ここで申込ユーザが送信ボタンB2を選択する操作を行うと、ユーザIDが「geo007」であるユーザに宛ててフレンドリクエストが送信される。本実施形態では、当該フレンドリクエストの送信が、上述した、フレンドとしての登録の申込に相当する。以下、フレンドとしての登録の申込に相当する操作を、フレンド登録申込操作と呼ぶこととする。
[0056]
 すると承諾ユーザが利用するクライアント12には、当該承諾ユーザ宛てのデータが送信された旨がプッシュ通知される。そして承諾ユーザが所定の操作を行うと、承諾ユーザが利用するクライアント12のディスプレイに図7に例示する通知ページ26が表示される。
[0057]
 図7に例示する通知ページ26には、承諾ユーザ宛てのデータの種類に対応付けられる通知情報が配置されている。図7の例では、当該承諾ユーザ宛ての最新のメッセージに対応付けられる通知情報N1と、当該承諾ユーザ宛ての最新の関係リクエストに対応付けられる通知情報N2が配置されている。図7に示す通知情報N2には、当該承諾ユーザ宛ての最新の関係リクエストがフレンドリクエストであることが示されている。
[0058]
 ここで承諾ユーザが、図7に示す通知ページ26において、カーソルCを操作することで通知情報N2を選択する操作を行うと、承諾ユーザが利用するクライアント12のディスプレイに、図8に例示するリクエスト一覧ページ28が表示される。リクエスト一覧ページ28には、受信した関係リクエストに対応付けられた受信リクエスト情報RRと、送信した関係リクエストに対応付けられる送信リクエスト情報SRと、が配置されている。以下、受信リクエスト情報RRと送信リクエスト情報SRを総称してリクエスト情報と呼ぶこととする。
[0059]
 受信リクエスト情報RRには、関係リクエストの送信元のユーザのアイコン画像I1や当該ユーザのユーザIDを表す文字列S1が配置されている。また受信リクエスト情報RRには、関係リクエストの種類を表す文字列S3、関係リクエストの送信タイミングを表す情報T、及び、メッセージ入力フォームF2に入力されたメッセージMが配置されている。なおここでは、関係リクエストの種類を表す文字列S3として、当該関係リクエストがフレンドリクエストであることを示す情報を表す文字列S3が配置されている。送信リクエスト情報SRには、関係リクエストの送信先のユーザのアイコン画像I1や当該ユーザのユーザIDを表す文字列S1が配置されている。
[0060]
 また、図8に示すリクエスト一覧ページ28には、受信リクエスト情報RRに対応付けられた承諾ボタンB3が配置されている。ここで承諾ユーザが承諾ボタンB3を選択する操作を行うと、上述したように、申込ユーザと承諾ユーザとは互いにフレンドユーザとして関連付けられることとなる。以下、このように申込ユーザによる申込を承諾する操作を、承諾操作と呼ぶこととする。この場合、当該受信リクエスト情報RRはリクエスト一覧ページ28から消去される。本実施形態では例えば、当該関連付けが行われることによって、ユーザ管理サーバ10の記憶部10bに記憶されているフレンド管理データは、図3に示すものから図9に示すものに更新される。図9に示す、ユーザIDが「aaa001」であるフレンド管理データには、フレンドユーザIDとして「geo007」が追加されている。また、図9に示す、ユーザIDが「geo007」であるフレンド管理データには、フレンドユーザIDとして「aaa001」が追加されている。
[0061]
 また承諾ユーザは、図8に示すリクエスト一覧ページ28に配置されたカーソルCを移動させる操作を行うことにより、リクエスト情報の選択を行えるようになっている。本実施形態では、図8に示すように、選択対象であるリクエスト情報の周囲にはカーソルCが表示される。ここで承諾ユーザが所定の決定操作を行うと、カーソルCによって囲まれているリクエスト情報が、選択されたリクエスト情報として決定される。そして、選択されたリクエスト情報に対応付けられるプロファイルページ22が、承諾ユーザが利用するクライアント12のディスプレイに表示される。ここで、受信リクエスト情報RRが選択された場合には、関係リクエストの送信元のユーザのプロファイルページ22が表示される。また、送信リクエスト情報SRが選択された場合には、関係リクエストの送信先のユーザのプロファイルページ22が表示される。また本実施形態では、プロファイルページ22を介して、受信した関係リクエストに対応付けられる申込の承諾操作や、受信又は送信した関係リクエストの削除操作を行えるようになっている。
[0062]
 なおリクエスト一覧ページ28には、複数の受信リクエスト情報RRが配置されてもよい。この場合には、それぞれの受信リクエスト情報RRに対応付けて承諾ボタンB3が配置されることとなる。
[0063]
[実名公開の申込と承諾]
 次に、ユーザIDが「aaa001」であるユーザが申込ユーザであり、ユーザIDが「geo007」であるユーザが承諾ユーザである場合における、実名公開の申込と承諾の一例について説明する。なお、当該申込及び当該承諾が行われる前においては、図9に例示するフレンド管理データがユーザ管理サーバ10の記憶部10bに記憶されていることとする。すなわち、上述のようにして、ユーザIDが「aaa001」であるユーザとユーザIDが「geo007」であるユーザとは既に互いにフレンドユーザとなっていることとする。
[0064]
 図10は、申込ユーザが利用するクライアント12のディスプレイに表示されるフレンド一覧ページ30の一例を示す図である。当該フレンド一覧ページ30には、申込ユーザのフレンドユーザに対応付けられるフレンド情報FIが配置されている。このようにしてフレンド一覧ページ30にはフレンド情報FIの一覧が配置される。
[0065]
 本実施形態では、実名公開ユーザではないフレンドユーザに対応付けられるフレンド情報FIaには、当該フレンドユーザのユーザIDを表す文字列S1、及び、アイコン画像I1が配置される。また、実名公開ユーザでもあるフレンドユーザに対応付けられるフレンド情報FIbには、当該フレンドユーザのユーザIDを表す文字列S1、当該フレンドユーザの実名データが示す名称が表す文字列S2、及び、写真画像I2が配置される。
[0066]
 本実施形態では、申込ユーザは、フレンド一覧ページ30に配置されたカーソルCを移動させる操作を行うことにより、フレンド情報FIの選択を行えるようになっている。本実施形態では、図10に示すように、選択対象であるフレンド情報FIの周囲にはカーソルCが表示される。ここで申込ユーザが所定の決定操作を行うと、カーソルCによって囲まれているフレンド情報FIが選択されたフレンド情報FIとして決定される。ここでは例えばユーザIDが「geo007」である承諾ユーザのフレンド情報FIaが選択されたこととする。すると、選択されたフレンド情報FIaに対応付けられるユーザのプロファイル情報が配置された、図11に例示するプロファイルページ22が、申込ユーザが利用するクライアント12のディスプレイに表示される。
[0067]
 本実施形態では、実名データが示す名称を表す文字列S2が配置されていないフレンド情報FIaが選択された場合には、当該フレンド情報FIaに配置されている文字列S1及びアイコン画像I1が配置されたプロファイルページ22が表示される。そのため、図11に例示するプロファイルページ22には、選択されたフレンド情報FIaに対応付けられるユーザのユーザIDを表す文字列S1及びアイコン画像I1が配置されることとなる。
[0068]
 また本実施形態では、選択されたフレンド情報FIaに文字列S2が配置されておらず、また当該フレンド情報FIaに対応付けられるユーザが実名公開ユーザではない場合には、実名リクエストボタンB4が配置されたプロファイルページ22が表示される。そのため、図11に例示するプロファイルページ22には、実名リクエストボタンB4が配置されることとなる。
[0069]
 図11に例示するプロファイルページ22が表示されている際に申込ユーザが実名リクエストボタンB4を選択する操作を行うと、図12に例示する実名リクエスト送信ページ32が、申込ユーザが利用するクライアント12のディスプレイに表示される。図12に例示する実名リクエスト送信ページ32には、選択されたフレンド情報FIaに対応付けられるユーザのユーザIDを表す文字列S1、及び、アイコン画像I1が配置される。また当該実名リクエスト送信ページ32には、メッセージ入力フォームF2、及び、送信ボタンB2も配置される。メッセージ入力フォームF2には、デフォルトのメッセージが予め入力されている。そしてユーザは当該メッセージを編集することができるようになっている。本実施形態では、図12に例示する実名リクエスト送信ページ32に表示されるデフォルトのメッセージには、図6に示すフレンドリクエスト送信ページ24とは異なり、申込ユーザの実名データが示す名称を表す文字列S4が含まれている。
[0070]
 ここで申込ユーザが送信ボタンB2を選択する操作を行うと、ユーザIDが「geo007」であるユーザに宛てて実名リクエストが送信される。本実施形態では、当該実名リクエストの送信が、上述した、実名公開の申込に相当する。このような、実名公開の申込に相当する操作を、以下、実名公開申込操作と呼ぶこととする。
[0071]
 すると承諾ユーザが利用するクライアント12には、当該承諾ユーザ宛てのデータが送信された旨がプッシュ通知される。そして承諾ユーザが所定の操作を行うと、承諾ユーザが利用するクライアント12のディスプレイに図13に例示する通知ページ26が表示される。
[0072]
 図13に例示する通知ページ26には、承諾ユーザ宛てのデータの種類に対応付けられる通知情報が配置されている。図13に示す通知情報N2には、当該承諾ユーザ宛ての最新の関係リクエストが実名リクエストであることが示されている。
[0073]
 ここで承諾ユーザが、図13に示す通知ページ26において、カーソルCを操作することで通知情報N2を選択する操作を行うと、承諾ユーザが利用するクライアント12のディスプレイに、図14に例示するリクエスト一覧ページ28が表示される。リクエスト一覧ページ28には、図8に示すリクエスト一覧ページ28と同様、リクエスト情報が配置されている。
[0074]
 図14に例示する受信リクエスト情報RRには、図8と同様、アイコン画像I1、文字列S1、文字列S3、情報T、及び、メッセージMが配置されている。なおここでは文字列S3として、当該関係リクエストが実名リクエストであることを示す情報を表す文字列S3が配置されている。送信リクエスト情報SRには、図8と同様、アイコン画像I1や文字列S1が配置されている。
[0075]
 ここでメッセージMに申込ユーザの実名データが示す名称を表す文字列S4が含まれていれば、承諾ユーザは実名リクエストを送信したユーザの実名を知ることができる。
[0076]
 また、図14に示すリクエスト一覧ページ28には、図8と同様、受信リクエスト情報RRに対応付けられた承諾ボタンB3が配置されている。ここで承諾ユーザが承諾操作、ここでは例えば承諾ボタンB3を選択する操作を行うと、上述したように、申込ユーザと承諾ユーザとは互いに実名公開ユーザとして関連付けられることとなる。この場合、当該受信リクエスト情報RRはリクエスト一覧ページ28から消去される。本実施形態では例えば、当該関連付けが行われることによって、ユーザ管理サーバ10の記憶部10bに記憶されているフレンド管理データは、図9に示すものから図15に示すものに更新される。図15に示す、ユーザIDが「aaa001」であるフレンド管理データには、実名公開ユーザIDとして「geo007」が追加されている。また、図15に示す、ユーザIDが「geo007」であるフレンド管理データには、実名公開ユーザIDとして「aaa001」が追加されている。
[0077]
 また、図8と同様、承諾ユーザは、図14に示すリクエスト一覧ページ28においてカーソルCを移動させる操作により選択されたリクエスト情報に対応付けられるプロファイルページ22を表示させることができる。そして承諾ユーザは、当該プロファイルページ22を介して、受信した関係リクエストに対応付けられる申込の承諾操作や、受信又は送信した関係リクエストの削除操作を行えるようになっている。
[0078]
[親友としての登録の申込と承諾]
 次に、ユーザIDが「aaa001」であるユーザが申込ユーザであり、ユーザIDが「bbb002」であるユーザが承諾ユーザである場合における、親友としての登録の申込と承諾の一例について説明する。なお、当該申込及び当該承諾が行われる前においては、図3に例示するフレンド管理データがユーザ管理サーバ10の記憶部10bに記憶されていることとする。すなわち、ユーザIDが「aaa001」であるユーザとユーザIDが「geo007」であるユーザとは互いにフレンドユーザとはなっていないこととする。
[0079]
 例えば、図4に示す検索ページ20において、ユーザIDが「bbb002」である承諾ユーザの検索結果情報RIbが選択されたこととする。すると、選択された検索結果情報RIbに対応付けられるユーザのプロファイル情報が配置された、図16に例示するプロファイルページ22が、申込ユーザが利用するクライアント12のディスプレイに表示される。
[0080]
 本実施形態では、実名データが示す名称を表す文字列S2が配置されている検索結果情報RIbが選択された場合には、当該検索結果情報RIbに配置されている文字列S1、文字列S2及び写真画像I2が配置されたプロファイルページ22が表示される。そのため、図16に例示するプロファイルページ22には、選択された検索結果情報RIbに対応付けられるユーザのユーザIDを表す文字列S1、当該ユーザの実名データが示す名称を表す文字列S2、及び写真画像I2が配置されることとなる。
[0081]
 また本実施形態では、選択された検索結果情報RIbに文字列S2が配置されており、また当該検索結果情報RIbに対応付けられるユーザがフレンドユーザではない場合には、親友リクエストボタンB5が配置されたプロファイルページ22が表示される。そのため、図16に例示するプロファイルページ22には、親友リクエストボタンB2が配置されることとなる。
[0082]
 図16に例示するプロファイルページ22が表示されている際に申込ユーザが親友リクエストボタンB5を選択する操作を行うと、図17に例示する親友リクエスト送信ページ34が、申込ユーザが利用するクライアント12のディスプレイに表示される。図17に例示する親友リクエスト送信ページ34には、選択された検索結果情報RIbに対応付けられるユーザのユーザIDを表す文字列S1、当該ユーザの実名データが示す名称を表す文字列S2、及び、写真画像I2が配置される。また、当該親友リクエスト送信ページ34には、メッセージ入力フォームF2、及び、送信ボタンB2も配置される。メッセージ入力フォームF2には、デフォルトのメッセージが予め入力されており、ユーザは当該メッセージを編集することができるようになっている。本実施形態では、図17に例示する親友リクエスト送信ページ34に表示されるデフォルトのメッセージには、図6に示すフレンドリクエスト送信ページ24とは異なり、申込ユーザの実名データが示す名称を表す文字列S4が含まれている。
[0083]
 ここで申込ユーザが送信ボタンB2を選択する操作を行うと、ユーザIDが「bbb002」であるユーザに宛てて親友リクエストが送信される。本実施形態では、当該親友リクエストの送信が、上述した、親友としての登録の申込に相当する。このような、親友としての登録の申込に相当する操作を、以下、親友登録申込操作と呼ぶこととする。
[0084]
 すると承諾ユーザが利用するクライアント12には、当該承諾ユーザ宛てのデータが送信された旨がプッシュ通知される。そして承諾ユーザが所定の操作を行うと、承諾ユーザが利用するクライアント12のディスプレイに図18に例示する通知ページ26が表示される。
[0085]
 図18に例示する通知ページ26には、承諾ユーザ宛てのデータの種類に対応付けられる通知情報が配置されている。図18に示す通知情報N2には、当該承諾ユーザ宛ての最新の関係リクエストが親友リクエストであることが示されている。
[0086]
 ここで承諾ユーザが、図18に示す通知ページ26において通知情報N2を選択する操作を行うと、承諾ユーザが利用するクライアント12のディスプレイに、図19に例示するリクエスト一覧ページ28が表示される。リクエスト一覧ページ28には、図8及び図14に示すリクエスト一覧ページ28と同様、リクエスト情報が配置されている。
[0087]
 図19に例示する受信リクエスト情報RRには、図8及び図14と同様、アイコン画像I1、文字列S1、文字列S3、情報T、及び、メッセージMが配置されている。なおここでは文字列S3として、当該関係リクエストが親友リクエストであることを示す情報を表す文字列S3が配置されている。送信リクエスト情報SRには、図8及び図14と同様、アイコン画像I1や文字列S1が配置されている。
[0088]
 ここでメッセージMに申込ユーザの実名データが示す名称を表す文字列S4が含まれていれば、承諾ユーザは親友リクエストを送信したユーザの実名を知ることができる。
[0089]
 なお、図19に例示する受信リクエスト情報RRに、文字列S2や写真画像I2が配置されても構わない。
[0090]
 また、図19に示すリクエスト一覧ページ28には、図8及び図14と同様、受信リクエスト情報RRに対応付けられた承諾ボタンB3が配置されている。ここで承諾ユーザが承諾操作、ここでは例えば承諾ボタンB3を選択する操作を行うと、上述したように、申込ユーザと承諾ユーザとは互いにフレンドユーザとしても関連付けられ、また、実名公開ユーザとしても関連付けられることとなる。この場合、当該受信リクエスト情報RRはリクエスト一覧ページ28から消去される。本実施形態では例えば、当該関連付けが行われることによって、ユーザ管理サーバ10の記憶部10bに記憶されているフレンド管理データは、図3に示すものから図20に示すものに更新される。図20に示す、ユーザIDが「aaa001」であるフレンド管理データには、フレンドユーザIDとして「bbb002」が追加されている。また、図20に示す、ユーザIDが「aaa001」であるフレンド管理データには、実名公開ユーザIDとして「bbb002」が追加されている。また、図20に示す、ユーザIDが「bbb002」であるフレンド管理データには、フレンドユーザIDとして「aaa001」が追加されている。また、図20に示す、ユーザIDが「bbb002」であるフレンド管理データには、実名公開ユーザIDとして「aaa001」が追加されている。
[0091]
 また、図8及び図14と同様、承諾ユーザは、図19に示すリクエスト一覧ページ28においてカーソルCを移動させる操作により選択されたリクエスト情報に対応付けられるプロファイルページ22を表示させることができる。そして承諾ユーザは、当該プロファイルページ22を介して、受信した関係リクエストに対応付けられる申込の承諾操作や、受信又は送信した関係リクエストの削除操作を行えるようになっている。
[0092]
 以上のようにして、本実施形態によれば、申込ユーザは、フレンド登録申込操作及び実名公開申込操作という2段階の操作を行うことなく、親友登録申込操作を行うだけで、承諾ユーザとフレンドユーザとしても実名公開ユーザとしても関連付けられることとなる。そのため、本実施形態では、実名を公開するユーザを登録する際のユーザの手間が従来技術よりも低減されることとなる。
[0093]
 例えば、実名データが示す名称を表す文字列S2が表示されているユーザであっても、当該ユーザに対してフレンドとしての登録の申込しかできないと仮定する。この場合には、当該ユーザがフレンドユーザとして登録されても、フレンド一覧ページ30は配置される当該ユーザのフレンド情報FIaには実名データが示す名称を表す文字列S2が配置されない。そのため、フレンド一覧ページ30に配置されているフレンド情報FIの一覧のなかから、当該ユーザのフレンド情報FIaを特定することは困難となる。一方本実施形態では、実名データが示す名称を表す文字列S2が表示されているユーザに親友としての登録の申込ができる。そして、当該申込が承諾されることによって、フレンド一覧ページ30には当該ユーザの実名データが示す名称を表す文字列S2を含むフレンド情報FIbが配置される。このようにして、本実施形態によれば、フレンド一覧ページ30に配置されているフレンド情報FIの一覧のなかから、当該ユーザのフレンド情報FIbを容易に特定することができることとなる。
[0094]
 なお本実施形態における画面遷移は上述のものに限定されない。例えば、検索ページ20における検索結果情報RIの選択操作に応じて、フレンドリクエスト送信ページ24や親友リクエスト送信ページ34が表示されてもよい。また例えば、検索ページ20における検索結果情報RIの選択操作に応じて、関係リクエストの送信が行われてもよい。この場合には検索結果情報RIの選択操作がフレンド登録申込操作や親友登録申込操作に相当することとなる。
[0095]
 また例えば、検索結果情報RIbやフレンド情報FIbを介して表示されるプロファイルページ22に実名データが示す名称が表す文字列S2が配置されていなくてもよい。
[0096]
 また例えば、親友登録申込操作が行えるページにおいて、フレンド登録申込操作及び親友登録申込操作のいずれもが行えても構わない。
[0097]
[検索ページやフレンド一覧ページ以外のページを介した申込と承諾]
 以上の説明では、フレンド登録申込操作及び親友登録申込操作は検索ページ20を介して行われ、実名公開申込操作はフレンド一覧ページ30を介して行われた。しかし、これらの操作が以上で説明したページ以外のページを介して行われても構わない。
[0098]
 図21は、ユーザIDが「aaa001」である申込ユーザが利用するクライアント12のディスプレイに表示されるFoFページ36の一例を示す図である。本実施形態に係るFoFページ36とは、特定のフレンドのフレンドユーザに対応付けられるフレンド情報FIが配置されるページである。図21の例では、ユーザIDが「hhh009」であるユーザのフレンドユーザのフレンド情報FIが配置されている。このようにしてFoFページ36にはフレンド情報FIの一覧が配置される。本実施形態では、申込ユーザの実名公開ユーザに対応付けられるフレンド情報FIbには、当該ユーザのユーザIDを表す文字列S1、当該ユーザの実名データが示す名称が表す文字列S2、及び、写真画像I2が配置される。またユーザ管理データに含まれる実名公開ページIDに「2」が設定されているユーザに対応付けられるフレンド情報FIbにも、文字列S1、文字列S2、及び、写真画像I2が配置される。一方いずれでもないユーザに対応付けられるフレンド情報FIaには、当該ユーザのユーザIDを表す文字列S1、及び、アイコン画像I1が配置される。
[0099]
 また、FoFページ36に配置されているフレンド情報FIのうち、申込ユーザのフレンドユーザのフレンド情報FIには、申込ユーザのフレンドユーザであることを表す画像I3が配置される。
[0100]
 本実施形態では、申込ユーザは、図10同様、FoFページ36に配置されたフレンド情報FIの選択を行えるようになっている。ここで実名データが示す名称を表す文字列S2も画像I3も配置されていないフレンド情報FIaが選択された場合には、図5と同様のプロファイルページ22が表示される。当該プロファイルページ22には、図5と同様にフレンドリクエストボタンB1が配置されている。ここで申込ユーザがフレンドリクエストボタンB1を選択する操作を行い、以降、上記の操作と同様の操作を行うことで、申込ユーザと承諾ユーザとは互いにフレンドユーザとして関連付けられることとなる。
[0101]
 一方、実名データが示す名称を表す文字列S2は配置されているが画像I3が配置されていない配置されていないフレンド情報FIaが選択された場合には、図11と同様のプロファイルページ22が表示される。当該プロファイルページ22には、図11と同様に実名リクエストボタンB4が配置されている。ここで申込ユーザが実名リクエストボタンB4を選択する操作を行い、以降、上記の操作と同様の操作を行うことで、申込ユーザと承諾ユーザとは互いにフレンドユーザとしても実名公開ユーザとしても関連付けられることとなる。
[0102]
 図22は、ユーザIDが「aaa001」である申込ユーザが利用するクライアント12のディスプレイに表示されるYMKページ38の一例を示す図である。本実施形態に係るYMKページ38とは、公知技術により、申込ユーザに親友としての登録を推薦するユーザとして特定されるユーザに関する情報Infoを一覧で表示するページである。図22の例では、申込ユーザのフレンドのフレンドであるユーザに関する情報Infoが配置されている。なお本実施形態では、YMKページ38に配置される情報Infoは、ユーザ管理データに含まれる実名公開ページIDに「3」が設定されているユーザに関する情報Infoに限定される。そしてユーザに関する情報Infoには、当該ユーザのユーザIDを表す文字列S1、当該ユーザの実名データが示す名称を表す文字列S2、及び、写真画像I2が配置される。
[0103]
 そして本実施形態に係るYMKページ38では、情報Infoに対応付けて親友リクエストボタンB5が配置されている。ここで申込ユーザが親友リクエストボタンB5を選択する操作を行うと、当該親友リクエストボタンB5に対応付けられるユーザについての、図17と同様の親友リクエスト送信ページ34が、申込ユーザが利用するクライアント12のディスプレイに表示される。以降、上記の操作と同様の操作を行うことで、申込ユーザと承諾ユーザとは互いにフレンドユーザとしても実名公開ユーザとしても関連付けられることとなる。
[0104]
 なお、ユーザ管理データに含まれる実名公開ページIDに「3」が設定されていないユーザに関する情報InfoがYMKページ38に配置されてもよい。この場合、当該ユーザに関する情報Infoには、当該ユーザのユーザIDを表す文字列S1、及び、アイコン画像I1が配置されてもよい。また当該情報Infoに対応付けてフレンドリクエストボタンB1が配置されていてもよい。そして申込ユーザがフレンドリクエストボタンB1を選択する操作を行うと、当該フレンドリクエストボタンB1に対応付けられるユーザについての、図6と同様のフレンドリクエスト送信ページ24が表示されてもよい。以降、上記の操作と同様の操作を行うことで、申込ユーザと承諾ユーザとは互いにフレンドユーザとして関連付けられるようにしてもよい。また、YMKページ38においてユーザを選択する操作が行われた際に、当該ユーザのプロファイルページ22が表示されてもよい。
[0105]
 図23は、ユーザIDが「aaa001」である申込ユーザが利用するクライアント12のディスプレイに表示されるSNSフレンド発見ページ40の一例を示す図である。本実施形態に係るSNSフレンド発見ページ40とは、外部のSNSにおいてフレンドとして登録されているユーザに関する情報Infoを一覧で表示するページである。当該ユーザに関する情報Infoには、当該ユーザのユーザIDを表す文字列S1、当該ユーザの実名データが示す名称を表す文字列S2、及び、写真画像I2が配置される。また当該ユーザに関する情報Infoには、外部のSNSにおいて使用されている当該ユーザの写真画像I4及び当該外部のSNSにおける当該ユーザの識別情報を表す文字列S5が配置される。
[0106]
 SNSフレンド発見ページ40では、チェックボックスChにより、情報Infoを複数選択できるようになっている。また、申込ユーザが全選択ボタンB6を選択する操作を行うとすべての情報Infoが選択状態となる。一方、申込ユーザが全解除ボタンB7を選択する操作を行うとすべての情報Infoの選択状態が解除される。ここで申込ユーザが画面遷移ボタンB8を選択する操作を行うと、図24に例示する親友リクエスト送信ページ34が、申込ユーザが利用するクライアント12のディスプレイに表示される。ここで申込ユーザが送信ボタンB2を選択する操作を行うと、SNSフレンド発見ページ40で選択状態となったユーザのそれぞれに宛てて親友リクエストが送信されることとなる。この場合には、一度の親友登録申込操作で複数のユーザに対して親友としての登録の申込が行えることとなる。なお同様にして、一度のフレンド登録申込操作で複数のユーザに対してフレンドとしての登録の申込が行えてもよい。また一度の実名公開申込操作で複数のユーザに対して実名公開の申込が行えてもよい。
[0107]
[機能]
 以下、上述した申込と承諾を中心に、本実施形態に係る情報処理システム1の機能並びに本実施形態に係る情報処理システム1で実行される処理についてさらに説明する。
[0108]
 図25は、本実施形態に係る情報処理システム1で実装される機能の一例を示す機能ブロック図である。なお、本実施形態に係る情報処理システム1で、図25に示す機能のすべてが実装される必要はなく、また、図25に示す機能以外の機能が実装されていても構わない。
[0109]
 図25に示すように、本実施形態に係るユーザ管理サーバ10は、機能的には例えば、ユーザ管理データ記憶部50、フレンド管理データ記憶部52、関係リクエスト管理データ記憶部54、ユーザ管理データ登録要求受信部56、ユーザ管理データ登録部58、関係リクエスト受信部60、関係リクエスト管理データ登録部62、通知部64、ページ生成部66、ページ送信部68、承諾受信部70、フレンド管理データ登録部72、を含む。ユーザ管理データ記憶部50、フレンド管理データ記憶部52、関係リクエスト管理データ記憶部54は、記憶部10bを主として実装される。ユーザ管理データ登録要求受信部56、関係リクエスト受信部60、通知部64、ページ送信部68、承諾受信部70は、通信部10cを主として実装される。ユーザ管理データ登録部58、関係リクエスト管理データ登録部62、ページ生成部66、フレンド管理データ登録部72は、制御部10aを主として実装される。
[0110]
 そして、以上の機能は、コンピュータであるユーザ管理サーバ10にインストールされた、以上の機能に対応する指令を含むプログラムを制御部10aで実行することにより実装されている。このプログラムは、例えば、光ディスク、磁気ディスク、磁気テープ、光磁気ディスク、フラッシュメモリ等のコンピュータ読み取り可能な情報記憶媒体を介して、あるいは、インターネットなどを介してユーザ管理サーバ10に供給される。
[0111]
 また図25に示すように、本実施形態に係るクライアント12は、機能的には例えば、ユーザ管理データ登録要求部80、ページ要求部82、ページ受信部84、表示処理部86、操作受付部88、関係リクエスト送信部90、通知受信部92、承諾送信部94、削除要求送信部96、を含む。ユーザ管理データ登録要求部80、ページ要求部82、ページ受信部84、関係リクエスト送信部90、通知受信部92、承諾送信部94、削除要求送信部96は、通信部12cを主として実装される。表示処理部86は、制御部12a及び出力部12dを主として実装される。操作受付部88は、制御部12a及び入力部12eを主として実装される。
[0112]
 そして、以上の機能は、コンピュータであるクライアント12にインストールされた、以上の機能に対応する指令を含むプログラムを制御部12aで実行することにより実装されている。このプログラムは、例えば、光ディスク、磁気ディスク、磁気テープ、光磁気ディスク、フラッシュメモリ等のコンピュータ読み取り可能な情報記憶媒体を介して、あるいは、インターネットなどを介してクライアント12に供給される。
[0113]
 ユーザ管理データ記憶部50は、本実施形態では例えば、図2に例示するユーザ管理データを記憶する。
[0114]
 フレンド管理データ記憶部52は、本実施形態では例えば、図3、図9、及び、図15に例示するフレンド管理データを記憶する。
[0115]
 関係リクエスト管理データ記憶部54は、本実施形態では例えば、図26に例示する、申込ユーザが利用するクライアント12から送信される関係リクエストを管理するための関係リクエスト管理データを記憶する。図26に例示するように、関係リクエスト管理データには、送信元ユーザID、送信先ユーザID、リクエスト種類データ、送信日時データ、メッセージデータ、が含まれる。送信元ユーザIDは、関係リクエストを送信するクライアント12を利用する申込ユーザのユーザIDである。送信先ユーザIDは、関係リクエストの送信先となるクライアント12を利用する承諾ユーザのユーザIDである。リクエスト種類データは、当該関係リクエストの種類を示すデータである。リクエスト種類データが示す関係リクエストの種類については後述する。送信日時データは、関係リクエストの送信日時を示すデータである。メッセージデータは、上述のメッセージ入力フォームF2に入力されたメッセージを示すデータである。ユーザIDが「aaa001」である申込ユーザによる、ユーザIDが「bbb002」である承諾ユーザに対する親友としての登録の申込が行われた際には、例えば図26の最も上及び上から2番目に示されている関係リクエスト管理データが記憶される。またユーザIDが「aaa001」である申込ユーザによる、ユーザIDが「geo007」である承諾ユーザに対するフレンドとしての登録の申込が行われた際には、例えば図26の最も下に示されている関係リクエスト管理データが記憶される。
[0116]
 ユーザ管理サーバ10のユーザ管理データ登録要求受信部56は、本実施形態では例えば、クライアント12から受け付けるユーザ管理データの登録要求を受け付ける。ユーザ管理データ登録要求受信部56は、本実施形態では例えば、ユーザ管理データの追加要求、削除要求、又は、更新要求を受け付ける。
[0117]
 ユーザ管理サーバ10のユーザ管理データ登録部58は、本実施形態では例えば、ユーザ管理データ登録要求受信部56が受け付ける登録要求に基づいて、ユーザ管理データの登録を行う。ユーザ管理データ登録部58は、本実施形態では例えば、ユーザ管理データの追加、削除、又は、更新を行う。
[0118]
 ユーザ管理サーバ10の関係リクエスト受信部60は、本実施形態では例えば、申込ユーザが利用するクライアント12から送信される関係リクエストを受信する。
[0119]
 ユーザ管理サーバ10の関係リクエスト管理データ登録部62は、本実施形態では例えば、関係リクエスト管理データの登録を行う。関係リクエスト管理データ登録部62は、本実施形態では例えば、関係リクエスト管理データの追加、削除、更新を行う。
[0120]
 ユーザ管理サーバ10の通知部64は、本実施形態では例えば、関係リクエストの受信に応じて、承諾ユーザに宛てた関係リクエストが送信されたことを通知する。通知部64は、本実施形態では例えば、承諾ユーザのクライアント12へのプッシュ通知を行う。通知部64は、本実施形態では例えば、承諾ユーザのユーザ管理データに含まれる端末IDによって識別されるクライアント12に関係リクエストが送信されたことを通知する。なお本実施形態では上述のように、承諾ユーザが複数のクライアント12を利用してもよい。この場合は、複数のクライアント12に関係リクエストが送信されたことを示す通知が送信されることとなる。
[0121]
 ユーザ管理サーバ10のページ生成部66は、本実施形態では例えば、上述した図4~図8、図10~図14、図16~図19、図21~図24に示す各種ページを表すデータを生成する。
[0122]
 ユーザ管理サーバ10のページ送信部68は、本実施形態では例えば、ページ生成部66が生成するデータをクライアント12に送信する。
[0123]
 ユーザ管理サーバ10の承諾受信部70は、本実施形態では例えば、申込ユーザによる申込に対する承諾ユーザによる承諾に応じて、承諾ユーザが利用するクライアント12が送信する承諾通知を受信する。
[0124]
 ユーザ管理サーバ10のフレンド管理データ登録部72は、本実施形態では例えば、フレンド管理データの登録を行う。フレンド管理データ登録部72は、本実施形態では例えば、フレンド管理データの追加、削除、更新を行う。
[0125]
 本実施形態に係るフレンド管理データ登録部72は、例えば、ユーザを指定する第1の操作に応じて、当該ユーザをニックネームが開示される第1の関係にあるユーザとして登録する。具体的には例えば、申込ユーザによる承諾ユーザを指定するフレンド登録申込操作に応じて、承諾ユーザは申込ユーザとフレンドの関係にあるユーザとして登録されることとなる。
[0126]
 また本実施形態に係るフレンド管理データ登録部72は、例えば、第1の関係にあるユーザを指定する第2の操作に応じて、当該ユーザをさらに実名も開示される第2の関係にあるユーザとして登録する。具体的には例えば、申込ユーザとフレンドの関係にあるユーザを承諾ユーザとして指定する実名公開申込操作に応じて、当該承諾ユーザが、申込ユーザの実名を公開する関係にあるユーザとして登録されることとなる。
[0127]
 また本実施形態に係るフレンド管理データ登録部72は、例えば、第1の関係にあるユーザとして登録されていないユーザを指定する第3の操作に応じて、当該ユーザを第1の関係及び第2の関係にあるユーザとして登録する。具体的には例えば、申込ユーザとフレンドの関係にあるユーザとして登録されていない承諾ユーザを指定する親友登録申込操作に応じて、承諾ユーザが、申込ユーザとフレンドの関係にあり、かつ、実名を公開する関係にあるユーザとして登録されることとなる。
[0128]
 またフレンド管理データ登録部72は、上述したように、検索ページ20などに実名が表示されているユーザを指定する操作に応じて、当該ユーザを第1の関係及び第2の関係にあるユーザとして登録するようにしてもよい。またフレンド管理データ登録部72は、検索ページ20などといった、第1の関係にあるユーザの候補に関する情報の一覧において実名が表示されていないユーザを指定する操作に応じて、当該ユーザを第1の関係にあるユーザとして登録してもよい。そしてフレンド管理データ登録部72は、当該一覧において実名が表示されているユーザを指定する操作に応じて、当該ユーザを第1の関係及び第2の関係にあるユーザとして登録してもよい。
[0129]
 クライアント12のユーザ管理データ登録要求部80は、ユーザ管理データの登録要求をユーザ管理サーバ10に送信する。ユーザ管理データ登録要求部80は、本実施形態では、ユーザ管理データの追加要求、削除要求、更新要求をユーザ管理サーバ10に送信する。本実施形態では、ユーザ管理データ登録要求部80が送信する登録要求に応じて、ユーザ管理データの登録が行われる。なお本実施形態では、新規のユーザ管理データの追加要求に応じて、当該新規のユーザ管理データの生成、及び、当該新規のユーザ管理データのユーザIDを含む新規のフレンド管理データの生成が行われる。
[0130]
 クライアント12のページ要求部82は、上述した各種ページの送信要求をユーザ管理サーバ10に送信する。ユーザ管理サーバ10のページ生成部66は、当該送信要求に応じて要求されたページを生成することとなる。
[0131]
 クライアント12のページ受信部84は、ユーザ管理サーバ10のページ送信部68が送信する、ページを表すデータを受信する。
[0132]
 クライアント12の表示処理部86は、ページ受信部84が受信する、ページを表すデータに基づいて当該ページを生成してディスプレイに表示させる。また表示処理部86は、本実施形態では例えば、第2の関係にあるユーザとして登録されているユーザの実名が含まれる、第1の関係にあるユーザに関する情報の一覧を表示させる。表示処理部86は、具体的には例えば、実名を公開する関係にあるユーザとして登録されているユーザの実名が含まれる、フレンドの関係にあるユーザに関する一覧である、図10に例示するフレンド一覧ページ30を表示させる。
[0133]
 クライアント12の操作受付部88は、ユーザがクライアント12に対して行う各種の操作を受け付ける。本実施形態に係る操作受付部88が受け付ける操作としては、例えば、上述のフレンド登録申込操作、実名公開申込操作、親友登録申込操作、承諾操作、関係リクエストの削除操作などが挙げられる。
[0134]
 クライアント12の関係リクエスト送信部90は、操作受付部88が受け付ける操作に応じた関係リクエストをユーザ管理サーバ10に送信する。
[0135]
 クライアント12の通知受信部92は、ユーザ管理サーバ10の通知部64が送信する通知を受信する。
[0136]
 クライアント12の承諾送信部94は、操作受付部88が承諾操作を受け付けた場合に、当該承諾操作に対応付けられる承諾通知をユーザ管理サーバ10に送信する。
[0137]
 クライアント12の削除要求送信部96は、操作受付部88が関係リクエストの削除操作を受け付けた際に当該関係リクエストの削除要求をユーザ管理サーバ10に送信する。ユーザ管理サーバ10の関係リクエスト管理データ登録部62は、当該削除要求の受信に応じて、削除要求の対象となった関係リクエスト管理データを関係リクエスト管理データ記憶部54から削除する。
[0138]
[処理フロー]
 ここで、本実施形態に係る情報処理システム1で行われる、申込ユーザと承諾ユーザとを互いにフレンドとして登録する処理の流れの一例を、図27に例示するフロー図を参照しながら説明する。
[0139]
 まず、申込ユーザが承諾ユーザを指定するフレンド登録申込操作を行うと、申込ユーザが利用するクライアント12の操作受付部88が、当該フレンド登録申込操作を受け付ける(S101)。すると、申込ユーザが利用するクライアント12の関係リクエスト送信部90が、当該承諾ユーザに対するフレンドリクエストをユーザ管理サーバ10に送信する。するとユーザ管理サーバ10の関係リクエスト受信部60が当該フレンドリクエストを受信する(S102)。
[0140]
 当該フレンドリクエストは、本実施形態では例えば、値が「Friend Request」であるリクエスト種類データが関連付けられた関係リクエストとして実装される。また本実施形態に係る関係リクエストには、送信元ユーザID及び送信先ユーザIDが関連付けられている。ここでは例えば、申込ユーザのユーザIDが送信元ユーザIDとして関連付けられ、承諾ユーザのユーザIDが送信先ユーザIDとして関連付けられる。また当該関係リクエストには、当該関係リクエストの送信日時を示す値、及び、上述したフレンドリクエスト送信ページ24のメッセージ入力フォームF2に入力されたメッセージが関連付けられる。
[0141]
 するとユーザ管理サーバ10の関係リクエスト管理データ登録部62が、S102に示す処理で受信したフレンドリクエストに対応付けられる関係リクエスト管理データを生成して、関係リクエスト管理データ記憶部54に記憶させる(S103)。ここで生成される関係リクエスト管理データの送信元ユーザIDとして、S102に示す処理で受信したフレンドリクエストに関連付けられている送信元ユーザIDが設定される。また生成される関係リクエスト管理データの送信先ユーザIDとして、S102に示す処理で受信したフレンドリクエストに関連付けられている送信先ユーザIDが設定される。また生成される関係リクエスト管理データのリクエスト種類データの値として、S102に示す処理で受信したフレンドリクエストに関連付けられているリクエスト種類データの値が設定される。ここでは生成される関係リクエスト管理データのリクエスト種類データの値として「Friend Request」が設定されることとなる。また生成される関係リクエスト管理データの送信日時データの値として、S102に示す処理で受信したフレンドリクエストに関連付けられている送信日時を示す値が設定される。また生成される関係リクエスト管理データのメッセージデータの値として、S102に示す処理で受信したフレンドリクエストに関連付けられているメッセージが設定される。
[0142]
 そしてユーザ管理サーバ10の通知部64が、承諾ユーザのユーザ管理データに含まれる端末IDによって識別されるクライアント12に、当該承諾ユーザに宛てた関係リクエストが送信されたことを通知する。すると、当該クライアント12の通知受信部92が当該通知を受信する(S104)。
[0143]
 その後、承諾ユーザが、当該フレンドリクエストの承諾操作を行うと、承諾ユーザが利用するクライアント12の操作受付部88が当該承諾操作を受け付ける(S105)。すると、承諾ユーザが利用するクライアント12の承諾送信部94が、当該フレンドリクエストの承諾通知をユーザ管理サーバ10に送信する。すると、ユーザ管理サーバ10の承諾受信部70が当該承諾通知を受信する(S106)。本実施形態では、当該承諾通知には、承諾操作の対象となったフレンドリクエストに関連付けられた送信元ユーザID、送信先ユーザID、及び、リクエスト種類データの値が関連付けられている。
[0144]
 すると、ユーザ管理サーバ10のフレンド管理データ登録部72は、S102に示す処理で受信したフレンドリクエストに基づくフレンド管理データの更新を行う(S107)。S107に示す処理では、フレンド管理データ登録部72は、例えば、当該承諾通知に関連付けられている送信元ユーザIDをユーザIDとして含むフレンド管理データを特定する。そしてフレンド管理データ登録部72は、特定されたフレンド管理データのフレンドユーザIDとして、当該承諾通知に関連付けられている送信先ユーザIDを追加する。またフレンド管理データ登録部72は、当該承諾通知に関連付けられている送信先ユーザIDをユーザIDとして含むフレンド管理データを特定する。そしてフレンド管理データ登録部72は、特定されたフレンド管理データのフレンドユーザIDとして、当該承諾通知に関連付けられている送信元ユーザIDを追加する。
[0145]
 そして、ユーザ管理サーバ10の関係リクエスト管理データ登録部62が、S102に示す処理で受信したフレンドリクエストに対応付けられる関係リクエスト管理データを関係リクエスト管理データ記憶部54から削除する(S108)。そして、本処理例に示す処理は終了される。
[0146]
 このようにして、申込ユーザと承諾ユーザとを互いにフレンドとして登録されることとなる。
[0147]
 次に、本実施形態に係る情報処理システム1で行われる、互いにフレンドとして登録されている申込ユーザと承諾ユーザの実名を互いに公開する処理の流れの一例を、図28に例示するフロー図を参照しながら説明する。
[0148]
 まず、申込ユーザが承諾ユーザを指定する実名公開申込操作を行うと、申込ユーザが利用するクライアント12の操作受付部88が、当該実名公開申込操作を受け付ける(S201)。すると、申込ユーザが利用するクライアント12の関係リクエスト送信部90が、当該承諾ユーザに対する実名リクエストをユーザ管理サーバ10に送信する。するとユーザ管理サーバ10の関係リクエスト受信部60が当該実名リクエストを受信する(S202)。
[0149]
 当該実名リクエストは、本実施形態では例えば、値が「Real Name Request」であるリクエスト種類データが関連付けられた関係リクエストとして実装される。また本実施形態に係る関係リクエストには、送信元ユーザID及び送信先ユーザIDが関連付けられている。ここでは例えば、申込ユーザのユーザIDが送信元ユーザIDとして関連付けられ、承諾ユーザのユーザIDが送信先ユーザIDとして関連付けられる。また当該関係リクエストには、当該関係リクエストの送信日時を示す値、及び、上述した実名リクエスト送信ページ32のメッセージ入力フォームF2に入力されたメッセージが関連付けられる。
[0150]
 するとユーザ管理サーバ10の関係リクエスト管理データ登録部62が、S202に示す処理で受信した実名リクエストに対応付けられる関係リクエスト管理データを生成して、関係リクエスト管理データ記憶部54に記憶させる(S203)。ここで生成される関係リクエスト管理データの送信元ユーザIDとして、S202に示す処理で受信した実名リクエストに関連付けられている送信元ユーザIDが設定される。また生成される関係リクエスト管理データの送信先ユーザIDとして、S202に示す処理で受信した実名リクエストに関連付けられている送信先ユーザIDが設定される。また生成される関係リクエスト管理データのリクエスト種類データの値として、S202に示す処理で受信した実名リクエストに関連付けられているリクエスト種類データの値が設定される。ここでは生成される関係リクエスト管理データのリクエスト種類データの値として「Real Name Request」が設定されることとなる。また生成される関係リクエスト管理データの送信日時データの値として、S202に示す処理で受信した実名リクエストに関連付けられている送信日時を示す値が設定される。また生成される関係リクエスト管理データのメッセージデータの値として、S202に示す処理で受信したフレンドリクエストに関連付けられているメッセージが設定される。
[0151]
 そしてユーザ管理サーバ10の通知部64が、承諾ユーザのユーザ管理データに含まれる端末IDによって識別されるクライアント12に、当該承諾ユーザに宛てた関係リクエストが送信されたことを通知する。すると、当該クライアント12の通知受信部92が当該通知を受信する(S204)。
[0152]
 その後、承諾ユーザが、当該実名リクエストの承諾操作を行うと、承諾ユーザが利用するクライアント12の操作受付部88が当該承諾操作を受け付ける(S205)。すると、承諾ユーザが利用するクライアント12の承諾送信部94が、当該実名リクエストの承諾通知をユーザ管理サーバ10に送信する。すると、ユーザ管理サーバ10の承諾受信部70が当該承諾通知を受信する(S206)。本実施形態では、当該承諾通知には、承諾操作の対象となった実名リクエストに関連付けられた送信元ユーザID、送信先ユーザID、及び、リクエスト種類データの値が関連付けられている。
[0153]
 すると、ユーザ管理サーバ10のフレンド管理データ登録部72は、S202に示す処理で受信した実名リクエストに基づくフレンド管理データの更新を行う(S207)。S207に示す処理では、フレンド管理データ登録部72は、例えば、当該承諾通知に関連付けられている送信元ユーザIDをユーザIDとして含むフレンド管理データを特定する。そしてフレンド管理データ登録部72は、特定されたフレンド管理データの実名公開ユーザIDとして、当該承諾通知に関連付けられている送信先ユーザIDを追加する。またフレンド管理データ登録部72は、当該承諾通知に関連付けられている送信先ユーザIDをユーザIDとして含むフレンド管理データを特定する。そしてフレンド管理データ登録部72は、特定されたフレンド管理データの実名公開ユーザIDとして、当該承諾通知に関連付けられている送信元ユーザIDを追加する。
[0154]
 そして、ユーザ管理サーバ10の関係リクエスト管理データ登録部62が、S202に示す処理で受信した実名リクエストに対応付けられる関係リクエスト管理データを関係リクエスト管理データ記憶部54から削除する(S208)。そして、本処理例に示す処理は終了される。
[0155]
 このようにして、互いにフレンドとして登録されている申込ユーザと承諾ユーザの実名を互いに公開されることとなる。
[0156]
 本実施形態では例えば、ページ生成部66は、関係リクエスト管理データ記憶部54に記憶されている関係リクエスト管理データに基づいて、リクエスト一覧ページ28を生成する。ここでページ生成部66は、例えば、送信元ユーザIDとして受諾ユーザのユーザIDを含む関係リクエスト管理データに基づいて、送信リクエスト情報SRを生成する。またページ生成部66は、例えば送信先ユーザIDとして受諾ユーザのユーザIDを含む関係リクエスト管理データに基づいて、受信リクエスト情報RRを生成する。
[0157]
 またページ生成部66は、受信リクエスト情報RRに対応付けられる承諾ボタンB3には、当該受信リクエスト情報RRに対応付けられる関係リクエスト管理データに含まれる送信元ユーザID、送信先ユーザID、及び、リクエスト種類データの値を関連付ける。
[0158]
 そのため承諾送信部94は、承諾ユーザに選択された承諾ボタンB3に関連付けられた送信元ユーザID、送信先ユーザID、及び、リクエスト種類データの値を承諾通知に関連付けてユーザ管理サーバ10に送信できることとなる。
[0159]
 次に、本実施形態に係る情報処理システム1で行われる、申込ユーザと承諾ユーザとを互いに親友として登録する処理の流れの一例を、図29に例示するフロー図を参照しながら説明する。
[0160]
 まず、申込ユーザが承諾ユーザを指定する親友登録申込操作を行うと、申込ユーザが利用するクライアント12の操作受付部88が、当該親友登録申込操作を受け付ける(S301)。すると、申込ユーザが利用するクライアント12の関係リクエスト送信部90が、当該承諾ユーザに対する親友リクエストをユーザ管理サーバ10に送信する。するとユーザ管理サーバ10の関係リクエスト受信部60が当該親友リクエストを受信する(S302)。
[0161]
 当該親友リクエストは、本実施形態では例えば、2つの関係リクエストとして実装される。ここで第1の関係リクエストは、例えば、値が「Friend Request」であるリクエスト種類データが関連付けられた関係リクエストとして実装される。そして第2の関係リクエストは、例えば、値が「Real Name Request」であるリクエスト種類データが関連付けられた関係リクエストとして実装される。そして例えば、第1の関係リクエストにも第2の関係リクエストにも送信元ユーザID及び送信先ユーザIDが関連付けられる。ここでは例えば、申込ユーザのユーザIDが送信元ユーザIDとして関連付けられ、承諾ユーザのユーザIDが送信先ユーザIDとして関連付けられる。また本実施形態では、第1の関係リクエストには、当該関係リクエストの送信日時を示す値、及び、上述した親友リクエスト送信ページ34のメッセージ入力フォームF2に入力されたメッセージが関連付けられる。なお、第2の関係リクエストにも、送信日時を示す値やメッセージが関連付けられていてもよい。
[0162]
 するとユーザ管理サーバ10の関係リクエスト管理データ登録部62が、S302に示す処理で受信したフレンドリクエストに対応付けられる関係リクエスト管理データを生成して、関係リクエスト管理データ記憶部54に記憶させる(S303)。ここでは2つの関係リクエストのそれぞれに対応付けられる関係リクエスト管理データが生成されることとなる。生成される第1の関係リクエスト管理データの送信元ユーザIDとして、S302に示す処理で受信した第1の関係リクエストに関連付けられている送信元ユーザIDが設定される。生成される第1の関係リクエスト管理データの送信先ユーザIDとして、S302に示す処理で受信した第1の関係リクエストに関連付けられている送信先ユーザIDが設定される。生成される第1の関係リクエスト管理データのリクエスト種類データの値として、S302に示す処理で受信した第1の関係リクエストに関連付けられているリクエスト種類データの値が設定される。ここでは生成される第1の関係リクエスト管理データのリクエスト種類データの値として「Friend Request」が設定されることとなる。また生成される第1の関係リクエスト管理データの送信日時データの値として、S302に示す処理で受信した第1の関係リクエストに関連付けられている送信日時を示す値が設定される。また生成される関係リクエスト管理データのメッセージデータの値として、S302に示す処理で受信した第1の関係リクエストに関連付けられているメッセージが設定される。
[0163]
 また、生成される第2の関係リクエスト管理データの送信元ユーザIDとして、S302に示す処理で受信した第2の関係リクエストに関連付けられている送信元ユーザIDが設定される。生成される第2の関係リクエスト管理データの送信先ユーザIDとして、S302に示す処理で受信した第2の関係リクエストに関連付けられている送信先ユーザIDが設定される。生成される第2の関係リクエスト管理データのリクエスト種類データの値として、S302に示す処理で受信した第2の関係リクエストに関連付けられているリクエスト種類データの値が設定される。ここでは生成される第2の関係リクエスト管理データのリクエスト種類データの値として「Real Name Request」が設定されることとなる。なお、生成される第2の関係リクエスト管理データの送信日時データの値として、S302に示す処理で受信した第2の関係リクエストに関連付けられている送信日時を示す値が設定されてもよい。また生成される関係リクエスト管理データのメッセージデータの値として、S302に示す処理で受信した第2の関係リクエストに関連付けられているメッセージが設定されてもよい。
[0164]
 図26の最も上及び上から2番目には、親友リクエストの送信に基づいて生成される2つの関係リクエスト管理データの一例が示されている。例えば、申込ユーザのユーザIDが「aaa001」であり承諾ユーザのユーザIDが「bbb002」である親友リクエストの送信に基づいて当該2つの関係リクエスト管理データが生成されることとなる。
[0165]
 そしてユーザ管理サーバ10の通知部64が、承諾ユーザのユーザ管理データに含まれる端末IDによって識別されるクライアント12に、当該承諾ユーザに宛てた関係リクエストが送信されたことを通知する。すると、当該クライアント12の通知受信部92が当該通知を受信する(S304)。
[0166]
 その後、承諾ユーザが、当該親友リクエストの承諾操作を行うと、承諾ユーザが利用するクライアント12の操作受付部88が当該承諾操作を受け付ける(S305)。すると、承諾ユーザが利用するクライアント12の承諾送信部94が、当該親友リクエストの承諾通知をユーザ管理サーバ10に送信する。すると、ユーザ管理サーバ10の承諾受信部70が当該承諾通知を受信する(S306)。本実施形態では、親友リクエストの承諾通知は、2つの通知によって実装されている。ここで例えば、第1の承諾通知には、承諾操作の対象となった親友リクエストに関連付けられた送信元ユーザID、送信先ユーザID、及び、値が「Friend Request」であるリクエスト種類データが関連付けられている。また第2の承諾通知には、承諾操作の対象となった親友リクエストに関連付けられた送信元ユーザID、送信先ユーザID、及び、値が「Real Name Request」であるリクエスト種類データが関連付けられている。
[0167]
 すると、ユーザ管理サーバ10のフレンド管理データ登録部72は、S302に示す処理で受信した親友リクエストに基づくフレンド管理データの更新を行う(S307)。
[0168]
 S307に示す処理では、フレンド管理データ登録部72は、例えば、第1の承諾通知の受信に応じて、当該第1の承諾通知に関連付けられている送信元ユーザIDをユーザIDとして含むフレンド管理データを特定する。そしてフレンド管理データ登録部72は、特定されたフレンド管理データのフレンドユーザIDとして、当該第1の承諾通知に関連付けられている送信先ユーザIDを追加する。またフレンド管理データ登録部72は、当該第1の承諾通知に関連付けられている送信先ユーザIDをユーザIDとして含むフレンド管理データを特定する。そしてフレンド管理データ登録部72は、特定されたフレンド管理データのフレンドユーザIDとして、当該第1の承諾通知に関連付けられている送信元ユーザIDを追加する。
[0169]
 そしてフレンド管理データ登録部72は、例えば、第2の承諾通知の受信に応じて、当該第2の承諾通知に関連付けられている送信元ユーザIDをユーザIDとして含むフレンド管理データを特定する。そしてフレンド管理データ登録部72は、特定されたフレンド管理データの実名公開ユーザIDとして、当該第2の承諾通知に関連付けられている送信先ユーザIDを追加する。またフレンド管理データ登録部72は、当該第2の承諾通知に関連付けられている送信先ユーザIDを特定する。そしてフレンド管理データ登録部72は、特定された送信先ユーザIDをユーザIDとして含むフレンド管理データの実名公開ユーザIDとして、当該第2の承諾通知に関連付けられている送信元ユーザIDを追加する。
[0170]
 そして、ユーザ管理サーバ10の関係リクエスト管理データ登録部62が、S302に示す処理で受信した親友リクエストに対応付けられる関係リクエスト管理データを関係リクエスト管理データ記憶部54から削除する(S308)。そして、本処理例に示す処理は終了される。S308に示す処理では、本実施形態では例えば、2つの関係リクエスト管理データが削除されることとなる。
[0171]
 このようにして、申込ユーザと承諾ユーザとを互いに親友として登録されることとなる。
[0172]
 なお上述のS302に示す処理でクライアント12から送信される2つの関係リクエストは1つのパケットにより実装されても2つのパケットにより実装されても構わない。そして2つのパケットにより当該2つの関係リクエストが実装される場合には、上述のS303に示す処理では、パケットの受信の度に当該パケットに対応付けられる関係リクエスト管理データが生成されて記憶されても構わない。
[0173]
 なお親友リクエストの実装は上述のものに限定されない。例えば、親友リクエストが、値が「Close Friend Request」であるリクエスト種類データが関連付けられた1つの関係リクエストとして実装されてもよい。この場合は上述のS302に示す処理において1つの関係リクエストが送信されることとなる。
[0174]
 また上述のS303に示す処理で、図30に示すような、リクエスト種類データの値として「Close Friend Request」が設定された関係リクエスト管理データが生成されても構わない。この場合、ユーザIDが「aaa001」である申込ユーザによる、ユーザIDが「bbb002」である承諾ユーザに対する親友としての登録の申込が行われた際には、例えば図30の最も上に示されている関係リクエスト管理データが記憶されることとなる。
[0175]
 また上述のS306に示す処理でクライアント12から送信される2つの承諾通知の代わりに、値が「Close Friend Request」であるリクエスト種類データが関連付けられた1つの承諾通知がクライアント12から送信されるようにしてもよい。
[0176]
 また本実施形態では例えば、承諾ユーザが行う所定の操作に応じて承諾ユーザが利用するクライアント12のページ要求部82がリクエスト一覧ページ28の送信要求をユーザ管理サーバ10に送信する。するとユーザ管理サーバ10のページ生成部66は、例えば当該送信要求に応じて承諾ユーザが利用するクライアント12のディスプレイに表示されるリクエスト一覧ページ28を表すデータを生成する。
[0177]
 ここでページ生成部66は、例えば、関係リクエスト管理データ記憶部54に記憶されている、図26に示す関係リクエスト管理データに基づいて、承諾ユーザが利用するクライアント12のディスプレイに表示されるリクエスト一覧ページ28を生成する。当該リクエスト一覧ページ28には、例えば、承諾ユーザのユーザIDを送信元ユーザIDとして含む関係リクエスト管理データに対応付けられる送信リクエスト情報SRが配置される。また当該リクエスト一覧ページ28には、例えば、承諾ユーザのユーザIDを送信先ユーザIDとして含む関係リクエスト管理データに対応付けられる受信リクエスト情報RRが配置される。
[0178]
 ここで例えば、送信元ユーザIDと送信先ユーザIDとの組み合わせが同一であり、リクエスト種類データの値がそれぞれ「Friend Request」、「Real Name Request」である2つの関係リクエスト管理データが記憶されているとする。この場合に、図19に例示するように、当該2つの関係リクエスト管理データに対応付けられる1つの受信リクエスト情報RRがリクエスト一覧ページ28に配置されてもよい。そしてリクエスト一覧ページ28の関係リクエストの種類を表す文字列S3として「Close Friend Request」が配置されてもよい。
[0179]
 なおクライアント12が親友リクエストの承諾機能を有していなくてもよい。この場合、上述の2つの関係リクエスト管理データが記憶されていても、リクエスト種類データの値が「Friend Request」である関係リクエスト管理データに対応付けられる受信リクエスト情報RRがリクエスト一覧ページ28に配置されてもよい。そして当該受信リクエスト情報RRに対応付けられる承諾ボタンB3を選択する承諾操作が行われた際に、上述のS105~S108に示す処理と同様の処理が実行されてもよい。
[0180]
 そしてその後、クライアント12に、承諾ユーザに宛てた関係リクエストが送信されたことが通知されてもよい。そしてリクエスト種類データの値が「Real Name Request」である関係リクエスト管理データに対応付けられる受信リクエスト情報RRがリクエスト一覧ページ28に配置されてもよい。そして当該受信リクエスト情報RRに対応付けられる承諾ボタンB3を選択する承諾操作が行われた際に、上述のS205~S208に示す処理と同様の処理が実行されてもよい。
[0181]
 なお実名リクエストの承諾機能を有していないクライアント12については、上述のS105~S108に示す処理が実行された後に、クライアント12に、承諾ユーザに宛てた関係リクエストが送信されたことが通知されなくてもよい。またリクエスト種類データの値が「Real Name Request」である関係リクエスト管理データに対応付けられる受信リクエスト情報RRがリクエスト一覧ページ28に配置されなくてもよい。
[0182]
 関係リクエスト管理データに含まれるリクエスト種類データの値として「Close Friend Request」が設定できるようにすると、親友登録申込操作に対応付けられる関係リクエスト管理データが2つ記憶される場合よりも記憶量が節約できる。また値が「Close Friend Request」であるリクエスト種類データが関連付けられた1つの関係リクエストとして親友リクエストが実装される場合は、親友リクエストが2つの関係リクエストとして実装される場合よりも通信量が節約できる。
[0183]
 一方、親友登録申込操作に応じて2つの関係リクエスト管理データが記憶されるようにすると、上述したように親友リクエストや実名リクエストの承諾機能を有していないクライアント12が存在しても互換性が保たれることとなる。また、親友登録申込操作に応じて2つの関係リクエスト管理データが記憶されるようにすると、リクエスト種類データの値として「Close Friend Request」が設定されないので、リクエスト種類データがとり得る値の数を節約することができる。
[0184]
 本実施形態では例えば、申込ユーザが行う所定の操作に応じて申込ユーザが利用するクライアント12のページ要求部82が当該申込ユーザのフレンド一覧ページ30の送信要求をユーザ管理サーバ10に送信する。するとユーザ管理サーバ10のページ生成部66は、例えば当該送信要求に応じて申込ユーザが利用するクライアント12のディスプレイに表示されるフレンド一覧ページ30を表すデータを生成する。ここで本実施形態に係るユーザ管理サーバ10で行われる、フレンド一覧ページ30を表すデータの生成処理の流れの一例を図31に示すフロー図を参照しながら説明する。
[0185]
 まずページ生成部66は、申込ユーザのユーザIDを含むフレンド管理データを特定する(S401)。そしてページ生成部66は、S401に示す処理で特定されたフレンド管理データのフレンドユーザIDとして設定されているユーザIDのうち、下記のS403~S405に示す処理がまだ実行されていないものを1つ特定する(S402)。
[0186]
 そしてページ生成部66は、S402に示す処理で特定されたユーザIDが、S401に示す処理で特定されたフレンド管理データの実名公開ユーザIDとして設定されているか否かを確認する(S403)。設定されていることが確認された場合は(S403:Y)、ページ生成部66は、当該ユーザについてはフレンド情報FIbを生成することを決定する(S404)。S404に示す処理では例えば、フレンド情報FIbに当該ユーザのユーザIDを表す文字列S1、当該ユーザの実名データが示す名称を表す文字列S2、及び、写真画像I2が配置されることが決定される。
[0187]
 一方、S403に示す処理で設定されていないことが確認された場合は(S403:N)、ページ生成部66は、当該ユーザについてはフレンド情報FIaを生成することを決定する(S405)。S405に示す処理では例えば、フレンド情報FIaに当該ユーザのユーザIDを表す文字列S1、及び、アイコン画像I1が配置されることが決定される。
[0188]
 そしてページ生成部66は、S401に示す処理で特定されたフレンド管理データのフレンドユーザIDとして設定されているユーザIDのうち、S403~S405に示す処理が実行されていないものがあるか否かを確認する(S406)。あることが確認された場合は(S406:Y)、ページ生成部66は、S402以降の処理を再度実行する。
[0189]
 一方、ないことが確認された場合は(S406:N)、上記の処理による決定に従ってフレンド情報FIaやフレンド情報FIbが配置されたフレンド一覧ページ30を表すデータを生成する(S407)。そして、本処理例に示す処理は終了される。
[0190]
 ページ送信部68は、このようにして生成されたフレンド一覧ページ30を表すデータを、申込ユーザのクライアント12に送信する。すると申込ユーザのクライアント12のページ受信部84は、当該データを受信する。そして申込ユーザのクライアント12の表示処理部86は、当該データを表すページをディスプレイに表示させる。
[0191]
[変形例]
 なお、本発明は上述の実施形態に限定されるものではない。
[0192]
 例えばフレンド管理データにフレンドユーザIDや実名公開ユーザIDとは別に親友IDが設定可能であっても構わない。そしてフレンドとしての登録の申込がされたユーザが当該申込を承諾した場合に、申込を行ったユーザのフレンド管理データの親友IDとして、承諾を行ったユーザのユーザIDが登録されてもよい。また、承諾を行ったユーザのフレンド管理データの親友IDとして、申込を行ったユーザのユーザIDが登録されてもよい。こうすれば、フレンドとしての登録を経て実名公開ユーザとしての登録がされたユーザと親友としての登録がされたユーザとを別に管理することが可能となる。
[0193]
 また例えば、ユーザ管理データに住所、生年月日、年齢などといった他の個人情報が設定できても構わない。そして、フレンド管理データに、これらの個人情報のそれぞれに対応付けられた、当該個人情報を互いに公開するユーザIDを設定できても構わない。そして例えば申込ユーザが行う、特定の個人情報の公開の申込操作を、承諾ユーザが承諾した場合には、申込ユーザと承諾ユーザとの間で互いに当該個人情報が公開されてもよい。
[0194]
 またユーザ管理データに設定される個人情報毎に機密度を設定できても構わない。そして、フレンド管理データに、互いに公開する個人情報の機密度の範囲に対応付けられたユーザIDを設定できても構わない。そして例えば申込ユーザが行う、ある機密度よりも機密度が小さな個人情報の公開の申込操作を、承諾ユーザが承諾した場合には、申込ユーザと承諾ユーザとの間で互いに当該機密度よりも小さな個人情報が公開されてもよい。
[0195]
 また、ユーザ管理サーバ10とクライアント12の役割分担は上述のものに限定されない。また、ユーザ管理サーバ10やクライアント12が複数の筐体から構成されていてもよい。
[0196]
 また、上記の具体的な文字列や図面中の具体的な文字列は例示であり、これらの文字列には限定されない。

請求の範囲

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

図面

[ 図 1]

[ 図 2]

[ 図 3]

[ 図 4]

[ 図 5]

[ 図 6]

[ 図 7]

[ 図 8]

[ 図 9]

[ 図 10]

[ 図 11]

[ 図 12]

[ 図 13]

[ 図 14]

[ 図 15]

[ 図 16]

[ 図 17]

[ 図 18]

[ 図 19]

[ 図 20]

[ 図 21]

[ 図 22]

[ 図 23]

[ 図 24]

[ 図 25]

[ 図 26]

[ 図 27]

[ 図 28]

[ 図 29]

[ 図 30]

[ 図 31]