JP2015072559A - サーバシステム、サーバ装置、情報処理プログラム、およびサーバシステムにおける情報処理方法 - Google Patents

Abstract

【課題】他のユーザからの申請を承認するか否かの判断によるユーザの負担を軽減する。
【解決手段】サーバは、あるユーザに関する所定の情報を、他のユーザに対して閲覧可能とするサービスを提供する。第１のユーザの端末装置から、第２のユーザに対する登録ユーザとして第１のユーザを登録する旨の申請がサーバにおいて受信される。サーバは、第２のユーザに対して行われた申請を承認する権限を有する承認者として、第２のユーザとは別の承認者を特定する。サーバは、申請の承認に関する問合せを承認者の端末装置へ送信し、承認者の端末装置から問合せに関する回答を受信し、受信された回答に基づいて、第１のユーザによる申請を承認するか否かの判定を行う。第１のユーザによる申請を承認すると判定した場合、サーバは、第２のユーザに対する登録ユーザとして第１のユーザの識別情報を記憶装置に記憶する。
【選択図】図４

Description

本発明は、保存されたユーザの情報を他のユーザに閲覧させるサービスを提供するためのサーバシステム、サーバ装置、情報処理プログラム、およびサーバシステムにおける情報処理方法に関する。

従来、いわゆるＳＮＳ（ｓｏｃｉａｌ ｎｅｔｗｏｒｋｉｎｇ ｓｅｒｖｉｃｅ）においては、ユーザが自己の情報（プロフィールや日記や写真等）をサーバに保存し、他のユーザに閲覧させることが行われている（例えば、特許文献１参照）。また、保存されている一部の情報については閲覧に制限を設け、フレンドとして登録された他のユーザにのみ閲覧を可能とすることが行われている。ユーザは他のユーザに対してフレンド申請（友達申請）を行うことができ、当該他のユーザが申請を承認した場合には、申請したユーザが承認したユーザのフレンドとして登録される。これによって、申請したユーザは、承認したユーザに関するより多くの情報が閲覧可能となる。

特開２００７−２８７１３１号公報

ＳＮＳまたは同種のサービスにおいては、現実世界では知人でない他のユーザからフレンド申請があった場合に、申請を承認するか否かの判断がユーザにとって難しいことがある。

それ故、本発明の目的は、他のユーザからの申請を承認するか否かの判断によるユーザの負担を軽減することができるサーバシステム、サーバ装置、情報処理プログラム、およびサーバシステムにおける情報処理方法を提供することである。

上記の課題を解決すべく、本発明は、以下の（１）〜（２１）の構成を採用した。

（１）
本発明の一例は、複数のユーザに関する情報を保存し、あるユーザに関する所定の情報を他のユーザに対して提供するサーバシステムである。サーバシステムは、登録記憶手段と、申請受信手段と、承認者特定手段と、第１問合せ手段と、承認判定手段とを備える。
登録記憶手段は、ユーザに関する情報に対する所定の権限が付与された他のユーザとして登録される登録ユーザの識別情報をユーザ毎に記憶部に記憶する。申請受信手段は、第１のユーザの端末装置から、第２のユーザに対する登録ユーザとして第１のユーザを登録する旨の申請を受信する。承認者特定手段は、第２のユーザに対して行われた申請を承認する権限を有する承認者として、第２のユーザとは別の承認者を特定する。第１問合せ手段は、申請の承認に関する問合せを承認者の端末装置へ送信し、承認者の端末装置から問合せに関する回答を受信する。承認判定手段は、受信された回答に基づいて、第１のユーザによる申請を承認するか否かの判定を行う。
登録記憶手段は、承認判定手段によって第１のユーザによる申請を承認すると判定された場合、第２のユーザに対する登録ユーザとして第１のユーザの識別情報を記憶部に記憶する。

上記（１）の構成によれば、第２のユーザは、自身に対する申請に関する承認を承認者に依頼することができるので、申請を承認するか否かの判断による第２のユーザの負担を軽減することができる。

（２）
サーバシステムは、少なくとも１のユーザについて、そのユーザに対して行われた申請を承認する権限を有する承認者の情報を申請の前に予め記憶部に記憶する承認者記憶手段をさらに備えていてもよい。承認者特定手段は、記憶部に記憶されている承認者の情報に基づいて承認者を特定してもよい。

上記（２）の構成によれば、第２のユーザは、申請の度に承認者を選択する必要が無いので、承認者の設定が容易になる。

（３）
サーバシステムは、申請の承認に関する問合せを第２のユーザの端末装置へ送信し、第２のユーザの端末装置から問合せに関する回答を受信する第２問合せ手段をさらに備えていてもよい。承認判定手段は、承認者の回答と第２のユーザの回答とに基づいて判定を行ってもよい。

上記（３）の構成によれば、第２のユーザ自身が承認するか否かの判断を行えるとともに、承認者による承認にも基づいて承認するか否かが判定されるので、第２のユーザの判断負担を軽減することができる。

（４）
第１問合せ手段は、第２問合せ手段によって受信された回答が申請を承認する旨を示す場合、申請の承認に関する問合せを承認者の端末装置へ送信し、当該回答が申請を承認しない旨を示す場合、当該問合せを承認者の端末装置へ送信しないようにしてもよい。承認判定手段は、第２のユーザの回答および承認者の回答が共に申請を承認する旨を示す場合、第１のユーザによる申請を承認すると判定してもよい。

上記（４）の構成によれば、第２のユーザが承認しない場合には承認者には問合せが行われないので、承認者は、必要がない場合には問合せに対する回答を行わなくてもよい。これによって、承認者の作業負担を軽減することができる。

（５）
サーバシステムは、第１問合せ手段によって受信された回答が申請を承認する旨を示す場合に、第１のユーザから第２のユーザに対して申請が行われたことを当該第２のユーザの端末装置へ通知する通知手段をさらに備えていてもよい。

上記（５）の構成によれば、承認者によって承認されなかった申請については第２のユーザに対する通知が行われないので、第２のユーザの確認の手間を省くことができる。

（６）
サーバシステムは、第１問合せ手段が問合せを承認者の端末装置へ送信する前に、第１のユーザから第２のユーザに対して申請が行われたことを当該第２のユーザの端末装置へ通知する通知手段をさらに備えていてもよい。

上記（６）の構成によれば、承認者が承認を行う場合であっても、申請があったことを第２のユーザへ事前に通知することができる。

（７）
サーバシステムは、第２のユーザの端末装置から承認者を設定するか否かに関する情報を受信し、受信した情報に基づいて、承認者を設定するか否かを判定する承認者判定手段をさらに備えていてもよい。承認者特定手段は、承認者を設定すると判定された場合に承認者を特定してもよい。

上記（７）の構成によれば、承認者を設定するか否かを第２のユーザに選択させるので、第２のユーザは、申請の承認の判断を自身で行うこともできるし、他の者に承認を依頼することもできる。これによって、第２のユーザの承認判断による負担を軽減することができるとともに、（承認の依頼を不要と判断した場合には）第１のユーザを容易に登録ユーザとすることができる。

（８）
サーバシステムは、申請が申請受信手段によって受信された場合、当該申請に関する承認者を選択するための問合せを第２のユーザの端末装置へ送信し、第２のユーザの端末装置から、選択された承認者を示す情報を受信する承認者問合せ手段をさらに備えていてもよい。承認者特定手段は、受信された承認者を示す情報に基づいて承認者を特定してもよい。

上記（８）の構成によれば、第２のユーザは申請毎に承認者を設定することができるので、申請に応じた適切な承認者を選択することができる。

（９）
サーバシステムは、許可者特定手段と、許可問合せ手段と、申請判定手段とをさらに備えていてもよい。許可者特定手段は、申請が申請受信手段によって受信された場合、第１のユーザが申請を行うことを許可する権限を有する申請許可者として、第１のユーザとは別の申請許可者を特定する。許可問合せ手段は、申請受信手段によって申請が受信された場合、申請を許可することに関する問合せを申請許可者の端末へ送信し、申請許可者の端末装置から問合せに関する回答を受信する。申請判定手段は、許可問合せ手段によって受信された回答が申請を許可する旨を示す場合、第１のユーザによる申請を有効とし、許可問合せ手段によって受信された回答が申請を許可しない旨を示す場合、第１のユーザによる申請を無効とする。このとき、第１問合せ手段は、申請が有効とされた場合、申請の承認に関する問合せを承認者の端末装置へ送信してもよい。

上記（９）の構成によれば、第１のユーザが申請を行うことを他の申請許可者によって制限することができる。これによって、第１のユーザが、正当であることが疑わしいユーザに対して申請を行ってしまうことを防止することができる。

（１０）
第１問合せ手段は、問合せに対する回答を行うためのウェブページにアクセスするためのリンク情報を含む情報を承認者の端末装置へ送信し、当該ウェブページ上で承認者の端末装置によって行われた回答を取得してもよい。

上記（１０）の構成によれば、サーバシステムが付与するアカウントを持たない者を承認者にすることができる。また、アカウントが付与されない承認者は、アカウントを取得するための登録作業を承認のために行う必要がないので、承認者の手間を省くことができる。

（１１）
許可問合せ手段は、問合せに関する回答を行うためのウェブページにアクセスするためのリンク情報を含む情報を申請許可者の端末装置へ送信し、当該ウェブページ上で申請許可者の端末装置によって行われた回答を取得してもよい。

上記（１１）の構成によれば、サーバシステムが付与するアカウントを持たない者を申請許可者にすることができる。また、アカウントが付与されない申請許可者は、アカウントを取得するための登録作業を申請の許可のために行う必要がないので、申請許可者の手間を省くことができる。

（１２）
第１問合せ手段は、申請の承認に関する問合せを承認者の端末装置へ送信する場合、第１のユーザに関して保存されるプロフィール情報のうちの少なくとも一部の情報または当該プロフィール情報にアクセスするためのリンク情報を当該問合せと共に送信してもよい。

上記（１２）の構成によれば、承認者は、プロフィールの情報を参照することで、承認するか否かの判断を行いやすくなる。

（１３）
承認判定手段は、第１問合せ手段による問合せが行われてから所定期間内に当該問合せに対する回答が受信されない場合、当該問合せに対する回答は、第１のユーザによる申請を承認しない旨を示すと判定してもよい。

上記（１３）の構成によれば、サーバシステムは、承認者からの回答が受信されない場合でも、申請を承認するか否かの判定を実行することができる。

（１４）
本発明の他の一例は、複数のユーザに関する情報を保存し、あるユーザに関する所定の情報を他のユーザに対して提供するサーバシステムである。サーバシステムは、登録記憶手段と、申請受信手段と、評価者特定手段と、評価問合せ手段と、承認問合せ手段と、承認判定手段とを備える。
登録記憶手段は、ユーザに関する情報に対する所定の権限が付与された他のユーザとして登録される登録ユーザの識別情報をユーザ毎に記憶部に記憶する。申請受信手段は、第１のユーザの端末装置から、第２のユーザに対する登録ユーザとして第１のユーザを登録する旨の申請を受信する。評価者特定手段は、第２のユーザに対して行われた申請を評価する権限を有する評価者として、第２のユーザとは別の評価者を特定する。評価問合せ手段は、申請を行った第１のユーザに対する評価に関する問合せを評価者の端末装置へ送信し、評価者の端末装置から問合せに関する回答を受信する。承認問合せ手段は、評価問合せ手段によって受信された回答に基づいて得られる評価情報と申請の承認に関する問合せとを第２のユーザの端末装置へ送信し、第２のユーザの端末装置から問合せに関する回答を受信する。承認判定手段は、承認問合せ手段によって受信された回答に基づいて、第１のユーザによる申請を承認するか否かの判定を行う。また、登録記憶手段は、第１のユーザによる申請を承認すると判定された場合、第２のユーザに対する登録ユーザとして第１のユーザの識別情報を記憶装置に記憶する。

なお、上記において、サーバシステムは、評価情報と問合せとを第２のユーザの端末装置へ同時に送信してもよいし、別々に送信してもよい。

上記（１４）の構成によれば、第２のユーザは、自身に対する申請に関する評価を評価者（評価ユーザ）に依頼することができ、評価者による評価を参考に、申請を承認するか否かを判断することができる。これによって、申請を承認するか否かの判断による第２のユーザの負担を軽減することができる。

（１５）
サーバシステムは、少なくとも１のユーザについて、そのユーザに対して行われた申請を評価する権限を有する評価者識別情報を申請の前に予め記憶部に記憶する評価者記憶手段をさらに備えていてもよい。評価者特定手段は、記憶部に記憶されている評価者の識別情報に基づいて評価者を特定してもよい。

上記（１５）の構成によれば、第２のユーザは、申請の度に評価ユーザを選択する必要が無いので、評価ユーザの設定が容易になる。

（１６）
サーバシステムは、第２のユーザの端末装置から評価ユーザを設定するか否かに関する情報を受信し、受信した情報に基づいて、評価者を設定するか否かを判定する評価者判定手段をさらに備えていてもよい。評価者特定手段は、評価者を設定すると判定された場合に評価者を特定してもよい。

上記（１６）の構成によれば、第２のユーザの承認判断による負担を軽減することができるとともに、（評価の依頼を不要と判断した場合には）第１のユーザを容易に登録ユーザとすることができる。

（１７）
サーバシステムは、申請が申請受信手段によって受信された場合、当該申請に関する評価者を選択するための問合せを第２のユーザの端末装置へ送信し、第２のユーザの端末装置から、選択された評価者を示す情報を受信する評価者問合せ手段をさらに備えていてもよい。評価者特定手段は、受信された評価者を示す情報に基づいて評価者を特定してもよい。

上記（１７）の構成によれば、第２のユーザは申請毎に評価ユーザを設定することができ、申請を行った第１のユーザに応じた適切な評価ユーザを選択することができる。

（１８）
サーバシステムは、許可者特定手段と、許可問合せ手段と、申請判定手段とを備えていてもよい。許可者特定手段は、申請が申請受信手段によって受信された場合、第１のユーザが申請を行うことを許可する権限を有する申請許可者として、第１のユーザとは別の申請許可者を特定する。許可問合せ手段は、申請受信手段によって申請が受信された場合、申請を許可することに関する問合せを申請許可者の端末へ送信し、申請許可者の端末から問合せに関する回答を受信する。申請判定手段は、許可問合せ手段によって受信された回答が申請を許可する旨を示す場合、第１のユーザによる申請を有効とし、許可問合せ手段によって受信された回答が申請を許可しない旨を示す場合、第１のユーザによる申請を無効とする。このとき、評価問合せ手段は、申請が有効とされた場合、申請の承認に関する問合せを評価者の端末装置へ送信してもよい。

上記（１８）の構成によれば、第１のユーザが申請を行うことを他の申請許可者によって制限することができる。これによって、第１のユーザが、正当であることが疑わしいユーザに対して申請を行ってしまうことを防止することができる。

（１９）
評価問合せ手段は、申請を行った第１のユーザに対する評価に関する問合せを評価ユーザの端末装置へ送信する場合、第１のユーザに関して保存されるプロフィール情報のうちの少なくとも一部の情報または当該プロフィール情報にアクセスするためのリンク情報を当該問合せと共に送信してもよい。

上記（１９）の構成によれば、評価ユーザは、プロフィールの情報を参照することで評価を行いやすくなる。

（２０）
評価ユーザ特定手段は、複数の評価者を特定してもよい。評価問合せ手段は、特定された複数の評価者それぞれの端末装置へ問合せを送信するとともに、各端末装置から回答を受信してもよい。承認問合せ手段は、受信された各回答から、評価の指標を示すパラメータを算出し、算出されたパラメータと申請の承認に関する問合せを第２のユーザの端末装置へ送信してもよい。

上記（２０）の構成によれば、複数の評価ユーザが設定される場合に、評価結果をわかりやすく第２のユーザに提示することができる。これによって、第２のユーザは、承認するか否かの判断を行いやすくなる。

（２１）
第２ユーザに関する情報に対する所定の権限は、当該第２ユーザに関する情報であって、登録ユーザでない他のユーザが閲覧不可能な情報を閲覧する権限であってもよい。

上記（２１）の構成によれば、登録ユーザでないユーザでは閲覧することができない情報を登録ユーザが閲覧することができるＳＮＳを提供するサーバシステムにおいて、申請を承認するか否かの判断によるユーザの負担を軽減することができる。

なお、本発明の別の一例は、上記（１）〜（２１）のサーバシステムを含む情報処理システムであってもよいし、上記（１）〜（２１）のサーバシステムにおける各手段と同等の手段として情報処理装置のコンピュータを機能させる情報処理プログラムであってもよい。また、本発明の別の一例は、上記（１）〜（２１）のサーバシステムにおいて実行される、情報処理方法（ユーザの登録方法）であってもよい。

本発明によれば、他のユーザからの申請を承認するか否かの判断によるユーザの負担を軽減することができる。

情報処理システムの一例の構成を示すブロック図 ユーザ情報の一例を示す図 フレンド登録が行われる場合における動作の流れを大略的に示す図 第１の実施形態におけるフレンド登録処理の流れを示すタイミングチャート 被申請端末３ｂにおいて表示される問合せ画面の一例を示す図 第１の実施形態においてサーバ２（制御部１２）が実行する情報処理の流れの一例を示すフローチャート 第２の実施形態におけるフレンド登録処理の流れを示すタイミングチャート 申請通知時に被申請端末３ｂに表示される回答画面の一例を示す図 第２の実施形態においてサーバ２（制御部１２）が実行する情報処理の流れの一例を示すフローチャート 第３の実施形態においてフレンド登録が行われる場合における動作の流れを大略的に示す図 第３の実施形態におけるフレンド登録処理の流れを示すタイミングチャート 第３の実施形態における問合せ画面の一例を示す図 第３の実施形態においてサーバ２（制御部１２）が実行する情報処理の流れの一例を示すフローチャート 第１の実施形態における変形例において、フレンド申請が行われる場合における動作の流れを大略的に示す図 図１４に示す変形例におけるフレンド申請処理の流れを示すタイミングチャート

以下、本実施形態に係るサーバシステム（サーバ装置）、情報処理システム、情報処理プログラム、および情報処理方法の一例として、いくつかの実施形態および変形例について説明する。

＜第１の実施形態＞
［１．第１の実施形態における情報処理システムの構成］
以下、第１の実施形態に係るサーバシステム、情報処理システム、情報処理プログラム、および、サーバシステムで実行される情報処理方法について説明する。図１は、第１の実施形態における情報処理システムの一例の構成を示すブロック図である。図１に示すように、情報処理システム１は、サーバ（サーバシステム）２と、複数の端末装置３と、ネットワーク４とを含む。サーバ２は、ネットワーク４を介して端末装置３と通信可能である。

図１において、サーバ２は、ＳＮＳを提供するサーバである。すなわち、サーバ２は、サーバ２に対してアクセスする端末装置３に対して、ＳＮＳのウェブサイトを提供する。サーバ２が提供するＳＮＳの内容は任意であるが、本実施形態においては、サーバ２は、ＳＮＳのユーザに関する情報（プロフィールや日記や写真等）を保存し、保存している情報を他のユーザに対して閲覧可能に提供する。なお、ＳＮＳにおいては、他のユーザが情報を閲覧できる機能に限らず、例えば、ユーザ間でメッセージを送ったり、特定のユーザ間で利用可能な掲示板にメッセージを書き込んだりする機能が提供されてもよい。

サーバ２は、１以上の情報処理装置（サーバ装置）で構成される。本明細書では、「サーバ」とは、１つの情報処理装置（サーバ装置）を指す他、サーバが複数のサーバ装置によって構成される場合にはサーバ装置群（サーバシステム）全体を指す意味である。

端末装置３は、サーバ２が提供するＳＮＳを利用する各ユーザによって操作される情報処理装置の一例である。端末装置３は、パーソナルコンピュータ、携帯端末、スマートフォン、ゲーム装置等、ネットワーク４を介してサーバ２と通信可能な任意の形態の情報処理装置であってよい。なお、ネットワーク４は、例えばインターネット等であるが、任意のネットワークでよい。

サーバ２は、各種の情報処理を実行する制御部１２を備える。また、サーバ２は、サーバ２において実行される情報処理プログラムを記憶するプログラム記憶部１３を備える。制御部１２は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）およびメモリを有し、ＣＰＵがメモリを用いて、上記情報処理プログラムを実行することによって上記各種の情報処理が実行される。また、サーバ２は、ネットワーク４を介して端末装置３とデータの送受信を行う通信部１１を備える。通信部１１は、制御部１２の指示により、上記情報処理の実行に応じた適宜のタイミングで端末装置３との間でデータの送受信を行う。

また、サーバ２は、ＳＮＳを提供するための各種のデータが記憶されるデータ記憶部１４を備える。なお、各記憶部１３および１４は、サーバ２が備える任意の記憶装置（記憶媒体）である。データ記憶部１４には、上記各種のデータの１つとして、ＳＮＳのユーザに関する情報（ユーザ情報）が記憶される。

図２は、ユーザ情報の一例を示す図である。なお、図２においては、１人のユーザに関して記憶（保存）される情報を示している。つまり、データ記憶部１４には、図２に示すユーザ情報２１が、ＳＮＳのユーザ毎に記憶されている。

図２に示すように、ユーザ情報２１には識別情報２２が含まれる。識別情報２２は、例えば、ユーザ（ユーザに付与されたアカウント）のＩＤや名前等である。識別情報２２には、ユーザがＳＮＳのウェブサイトにログインするために必要となるパスワードが含まれていてもよい。

また、ユーザ情報２１には、ＳＮＳのウェブサイトにおいて閲覧されるための閲覧情報２３が含まれる。ここで、本実施形態においては、ユーザに対して他のユーザをフレンド登録することができ、当該ユーザの閲覧情報のうち所定の情報については、フレンド登録された他のユーザが閲覧することができ、フレンド登録されていない他のユーザは閲覧することができない。つまり、フレンド登録されたユーザとは、上記所定の情報を閲覧する権限が付与されたユーザである。

具体的には、閲覧情報２３は、制限情報２４と非制限情報２５とを含む（つまり、閲覧情報２３は、制限情報２４と非制限情報２５とに分けることができる）。制限情報２４は、フレンド登録されたユーザのみが閲覧可能な（フレンド登録されていないユーザは閲覧不可能な）情報である。また、非制限情報２５は、（フレンド登録されているか否かにかかわらず）任意のユーザが閲覧可能な情報である。例えば、名前や趣味等の簡単なプロフィール情報は非制限情報２５として保存され、日記や家族の写真等、不特定のユーザには見られたくない情報は制限情報２４として保存されてもよい。

なお、閲覧情報に含まれる各情報が制限情報２４に設定されるか非制限情報２５に設定されるかは、ユーザが個別に設定できるようにしてもよい。また、例えば、ユーザの名前は非制限情報２５として設定される等、制限情報２４に設定されるか非制限情報２５に設定されるかは情報の種類（項目）毎に予め設定されていてもよい。

ユーザ情報２１には、フレンド情報２６が含まれる。フレンド情報２６は、ユーザ情報２１に対応するユーザに対してフレンド登録されている他のユーザの識別情報を示す。つまり、フレンド情報２６によって示される他のユーザは、制限情報２４を閲覧可能である。詳細は後述するが、本実施形態においては、ユーザは、他のユーザに対してフレンド申請（友達申請）を行うことができ、申請が承認された場合、当該他のユーザに対して申請を行ったユーザがフレンド登録される。

ユーザ情報２１には、承認者情報２７が含まれる。ここで、詳細は後述するが、本実施形態においては、あるユーザからフレンド申請があった場合、ユーザは、他のユーザ（例えば保護者や友人）に承認を依頼する（承認を代理してもらう）ことができる。承認者情報２７は、ユーザに対するフレンド申請を承認する権限を有する他のユーザ（「承認ユーザ」と呼ぶ）の識別情報を示す。承認者情報２７は、ユーザが承認を他のユーザに依頼する場合に設定される。つまり、ユーザ情報２１内に承認者情報２７が設定される場合、ユーザ情報２１に対応するユーザに対するフレンド申請は、承認者情報２７により示される承認ユーザによって承認が行われる（詳細は後述する）。

ユーザ情報２１には、通知情報２８が含まれる。通知情報２８は、サーバ２からユーザに対する通知（問合せ等を含む）の有無を示し、通知がある場合には、当該通知において送信すべき情報（「送信情報」と呼ぶ）を含む。詳細は後述するが、例えば、あるユーザに対してフレンド申請があった場合、サーバ２は、当該あるユーザのユーザ情報２１の通知情報２８として、フレンド申請があった旨の通知を示す情報と、通知の際に当該あるユーザの端末装置３へ送信する送信情報（例えば、フレンド申請を行ったユーザのプロフィール情報等）とを記憶する。なお、上記通知および送信情報は、当該あるユーザの端末装置３が次にサーバ２にアクセスしてＳＮＳのウェブサイトにログインしたことに応じて、当該端末装置３へ送信される。

［２．情報処理システムにおいて実行される処理の概要］
以下、図３〜図５を参照して、第１の実施形態における情報処理システム１において実行されるフレンド登録処理の概要について説明する。図３は、フレンド登録が行われる場合における動作の流れを大略的に示す図である。以下では、図３に示すように、あるユーザ（「申請ユーザ」と呼ぶ）が他のユーザ（「被申請ユーザ」と呼ぶ）に対してフレンド申請を行い（図３に示す（１））、被申請ユーザが承認ユーザに承認を依頼し（図３に示す（２））、承認ユーザが承認／不承認を行う（図３に示す（３））場合における、情報処理システム１における処理について説明する。

なお、第１の実施形態では、被申請ユーザに対して承認ユーザが予め定められているものとし、サーバ２が記憶する被申請ユーザのユーザ情報２１には、承認ユーザを示す承認者情報２７が含まれているものとする。なお、一例としては、被申請ユーザが子供であり、その親（保護者）が承認ユーザとして予め登録されている場合が考えられる。つまり、第１の実施形態は、子供に対して知らない他人からフレンド申請があった場合に、親が承認を行うような状況において用いられることが考えられる。

また、以下では、申請ユーザがＳＮＳを利用するために用いる端末装置３を、申請端末３ａと呼び、被申請ユーザがＳＮＳを利用するために用いる端末装置３を、被申請端末３ｂと呼び、承認ユーザがＳＮＳを利用するために用いる端末装置３を、承認端末３ｃと呼ぶ。第１の実施形態では、各端末３ａ〜３ｃはそれぞれ別の端末装置であるとするが、ユーザがサーバ２へアクセスするために用いる端末装置は任意であり、例えば、被申請端末３ｂと承認端末３ｃとして同じ（１つの）端末装置が用いられてもよい。

図４は、第１の実施形態におけるフレンド登録処理の流れを示すタイミングチャートである。まず、申請ユーザは、申請端末３ａを用いてＳＮＳにおけるフレンド申請の入力を行う（ステップＳ１）。すなわち、申請端末３ａは、ＳＮＳのウェブサイト内における、フレンド申請を行うためのウェブページを表示装置に表示し、フレンド申請のための入力を申請ユーザから受け付ける。申請ユーザは、被申請ユーザを特定可能な情報（名前、識別情報等）を入力する。このとき、被申請ユーザへのメッセージが入力されてもよい。また、サーバ２は、申請ユーザによって入力された検索条件に基づいてユーザの検索を行い、検索結果が申請端末３ａにおいて提示されてもよい。このとき、申請ユーザは、検索結果として提示されたユーザから被申請ユーザを選択してもよい。

フレンド申請のための情報が入力されると、申請端末３ａは、サーバ２へフレンド申請を行い、サーバ２は、フレンド申請を受け付ける（ステップＳ２）。具体的には、申請端末３ａは、フレンド申請のために入力された情報と、申請ユーザの識別情報とを含む申請情報をサーバ２へ送信する。

申請端末３ａからの申請情報を受信すると、サーバ２は、フレンド申請の申請先である被申請ユーザを特定する（ステップＳ３）。すなわち、サーバ２は、上記申請情報に含まれる、被申請ユーザを特定可能な情報に基づいて、被申請ユーザを特定する。

ここで、第１の実施形態においては、フレンド申請があった場合、サーバ２はまず被申請ユーザに対して、フレンド申請を承認するか否かを問い合わせる。そして、被申請ユーザがフレンド申請を承認しないと回答した場合には、サーバ２はフレンド申請が承認されなかったと判断する。一方、被申請ユーザがフレンド申請を承認すると回答した場合には、サーバ２は、被申請ユーザの承認ユーザに対してさらに、フレンド申請を承認するか否かを問い合わせる。なお、他の実施形態においては、被申請ユーザおよび承認ユーザに問合せを送信するタイミングは任意であり、サーバ２は、承認ユーザに対して被申請ユーザよりも先に問合せを行ってもよい。また、サーバ２は、被申請ユーザおよび承認ユーザに対して同時に問合せを行ってもよい。

具体的には、上記ステップＳ３において被申請ユーザを特定した場合、サーバ２は、被申請ユーザの端末である被申請端末３ｂへ、フレンド申請に対する問合せを行う（ステップＳ４）。この問合せでは、被申請ユーザが申請を承認するか否かの問い合わせが行われる。

ここで、サーバ２からユーザへの通知（問合せを含む）は、通知が発生した時点でまず、通知に関する通知情報２８がサーバ２に記憶され、その後、ユーザの端末装置３がＳＮＳを利用した（ＳＮＳにログインした）ことに応じて、通知情報２８に含まれる送信情報がサーバ２から端末装置３へ送信されることによって行われる。すなわち、上記ステップＳ４においては、サーバ２は、まず、問合せを行う旨を示す情報と、問合せ時に送信する送信情報とを、被申請ユーザのユーザ情報２１における通知情報２８として記憶しておく。そして、被申請ユーザが被申請端末３ｂを用いてサーバ２にアクセスし、ＳＮＳにログインした場合、サーバ２は、被申請ユーザのユーザ情報２１に含まれる通知情報２８を参照し、被申請ユーザに対する通知（問合せ）の有無を判定する。通知があると判定した場合、サーバ２は、通知情報２８に含まれる送信情報を被申請端末３ｂへ送信する。なお、他の実施形態においては、サーバ２から端末装置３への通知が発生した場合、サーバ２は、通知が発生したことを電子メール等によって（ユーザがＳＮＳにログインする前に）通知するようにしてもよい。

上記ステップＳ４では、送信情報として、被申請端末３ｂにおいて問合せ画面を表示するための情報が送信される。具体的には、この送信情報は、申請ユーザの名前（アカウント名）と、閲覧情報の一部であるプロフィール情報を含む。また、被申請ユーザに承認ユーザが設定されている場合には、送信情報は承認ユーザの名前（アカウント名）を含む。被申請端末３ｂにおいてサーバ２からの送信情報が受信されると、被申請端末３ｂは、上記問合せ画面を表示装置に表示する。

図５は、被申請端末３ｂにおいて表示される問合せ画面の一例を示す図である。図５に示すように、問合せ画面には、申請ユーザからフレンド申請があったことを示すメッセージ３１、フレンド申請を承認するか否かを被申請ユーザが回答するための画像（ボタン画像３２および３３）、および、申請ユーザのプロフィール３５が含まれる。また、本実施形態においては、問合せ画面には、被申請ユーザが承認する旨の回答を行った場合には承認ユーザに承認の依頼が行われる旨を通知するメッセージ３４が含まれる。

なお、他の実施形態においては、上記ステップＳ４において、サーバ２は、申請ユーザのユーザ情報２１に基づいて、申請ユーザの登録済みのフレンドであるユーザを特定し、特定したユーザの情報（名前等）を被申請端末３ｂに送信してもよい。このとき、被申請端末３ｂには、プロフィールに代えて（またはプロフィールとともに）申請ユーザの登録済みのフレンドであるユーザの情報が表示されてもよい。被申請ユーザは、申請ユーザの登録済みフレンドを知ることによって、申請ユーザが信頼できるか否かを判断することができる。例えば、申請ユーザの登録済みフレンドに被申請ユーザの知人（フレンド）がいる場合には、申請ユーザが信頼できると判断することができる。また、申請ユーザが被申請ユーザの知人であるにもかかわらず、申請ユーザの登録済みフレンドに被申請ユーザの知人（フレンド）が全くいない場合には、申請ユーザはなりすましによる別人であることを疑うことができ、信頼できないと判断することができる。

被申請端末３ｂにおいて上記問合せ画面が表示された場合、被申請ユーザは、問合せ画面に対して入力を行うことによって、フレンド申請を承認するか否かの回答を入力する（ステップＳ５）。例えば、被申請ユーザが、タッチパネルやマウス等の入力装置を用いて、「承認する」を表すボタン画像３２または「承認しない」を表すボタン画像３３のいずれかを指定することで、承認するか否かの回答が行われる。入力が行われたことに応じて、被申請端末３ｂは、回答結果（承認または不承認）を示す情報をサーバ２へ送信する（ステップＳ６）。回答には、被申請ユーザの識別情報と、フレンド申請の承認または不承認を示す回答結果の情報とが含まれる。

サーバ２は、被申請端末３ｂから送信されてくる被申請ユーザの回答を受信する。受信された被申請ユーザの回答が承認を示す場合、サーバ２は、被申請ユーザの承認ユーザを特定する（ステップＳ７）。承認ユーザの特定は、被申請ユーザのユーザ情報２１の承認者情報２７を参照することによって行うことができる。次に、サーバ２は、承認ユーザの端末である承認端末３ｃへフレンド申請に対する問合せを行う（ステップＳ８）。この問合せでは、上記ステップＳ４における問合せ処理と同様、承認ユーザが申請を承認するか否かの問合せが行われる。具体的には、上記ステップＳ４と同様、サーバ２は、問合せに関する通知情報２８を承認ユーザのユーザ情報２１に含めて記憶しておき、その後、承認ユーザがＳＮＳを利用した（ＳＮＳにログインした）ことに応じて、通知情報２８に含まれる送信情報がサーバ２から承認端末３ｃへ送信される。なお、送信情報の内容は、ステップＳ４における送信情報と同様の問合せ画面を表示するための情報でよい。

承認端末３ｃにおいてサーバ２からの送信情報が受信されると、承認端末３ｃは、上記問合せ画面を表示装置に表示し、承認ユーザからの回答の入力を受け付ける。このとき、問合せ画面には申請ユーザのプロフィールが表示されるので、承認ユーザは、申請ユーザに関する情報を得ることができ、承認するか否かの判断に役立てることができる。承認端末３ｃにおいて上記問合せ画面が表示された場合、承認ユーザは、問合せ画面に対して入力を行うことによって、フレンド申請を承認するか否かの回答を入力する（ステップＳ９）。入力が行われたことに応じて、承認端末３ｃは、回答結果（承認または不承認）を示す情報をサーバ２へ送信する（ステップＳ１０）。回答には、フレンド申請の承認または不承認を示す回答結果の情報が含まれる。

サーバ２は、承認端末３ｃから送信されてくる回答を受信し、フレンド申請を承認するか否かの判定を回答に基づいて行う（ステップＳ１１）。このとき、フレンド申請を承認すると判定した場合、サーバ２は、申請ユーザを被申請ユーザのフレンドとして登録する（ステップＳ１２）。具体的には、申請ユーザのユーザ情報２１内のフレンド情報２６を、被申請ユーザの識別情報を含むように更新するとともに、被申請ユーザのユーザ情報２１内のフレンド情報２６を、申請ユーザの識別情報を含むように更新する。

さらに、サーバ２は、判定結果を申請ユーザおよび被申請ユーザへ通知する（ステップＳ１３）。この通知も上記ステップＳ４およびＳ８の問合せと同様、通知情報２８を用いて行われる。すなわち、サーバ２は、通知に関する通知情報２８を申請ユーザおよび被申請ユーザのユーザ情報２１に含めて記憶しておき、その後、申請ユーザまたは被申請ユーザがＳＮＳにログインしたことに応じて、通知情報２８に含まれる送信情報がサーバ２から申請端末３ａまたは被申請端末３ｂへ送信される。なお、ステップＳ１３の通知処理に関して、他の実施形態においては、ステップＳ１１の判定においてフレンド申請を承認すると判定した場合、サーバ２は、申請ユーザ（および被申請ユーザ）に対して通知を行わないようにしてもよい。

以上のように、本実施形態においては、被申請ユーザに対してフレンド申請があった場合、サーバ２は、被申請ユーザに対して行われた申請を承認する権限を有する承認者として、被申請ユーザとは別の承認ユーザを特定する（ステップＳ３）。そして、サーバ２は、申請の承認に関する問合せを承認ユーザの端末装置（承認端末３ｃ）へ送信し、承認ユーザの端末装置から問合せに関する回答を受信する（ステップＳ１０）。さらに、サーバ２は、受信された回答に基づいて、申請ユーザによる申請を承認するか否かの判定を行い（ステップＳ１１）、申請ユーザによる申請を承認すると判定された場合、被申請ユーザに対する登録ユーザ（フレンド）として申請ユーザの識別情報を記憶する（ステップＳ１２）。以上によれば、被申請ユーザは、自身に対するフレンド申請に関する承認を承認者（承認ユーザ）に依頼することができるので、申請を承認するか否かの判断による被申請ユーザの負担を軽減することができる。

例えば、ユーザが子供である場合には、知らない他人のユーザからのフレンド申請を安易に承認してしまったり、他人が被申請ユーザの知人になりすまして行ったフレンド申請を（なりすましであることを見抜けずに）承認してしまったりする結果、何らかの被害にあう可能性がある。このような場合を想定して、サーバ２は、例えば、子供のユーザに対して親のユーザを承認ユーザとして登録しておくことによって、不正なフレンド申請が子供のユーザによって承認されてフレンド登録されてしまうことを防止することができる。このように、本実施形態によれば、ＳＮＳにおいて、子供のユーザに対するフレンド申請についてのペアレンタルコントロール機能を提供することができる。

また、第１の実施形態においては、サーバ２は、少なくとも１のユーザについて、そのユーザに対して行われたフレンド申請を承認する権限を有する承認ユーザを示す承認者情報２７をフレンド申請の前に予めデータ記憶部１４に記憶しておく（図２）。そして、サーバ２は、（フレンド申請があった場合、）データ記憶部１４に記憶されている承認者情報２７に基づいて承認ユーザを特定する。これによれば、被申請ユーザは、フレンド申請の度に承認ユーザを選択する必要が無いので、簡単に承認ユーザを設定することができる。なお、他の実施形態においては、例えば後述する第２の実施形態のように、フレンド申請がある度に被申請ユーザが承認ユーザを設定するようにしてもよい。

また、第１の実施形態においては、サーバ２は、フレンド申請の承認に関する問合せを被申請ユーザの端末装置（被申請端末３ｂ）へ送信し、被申請端末３ｂから問合せに関する回答を受信する（ステップＳ６）。そして、サーバ２は、承認ユーザの回答と被申請ユーザの回答とに基づいて判定を行う。つまり、承認ユーザおよび被申請ユーザの両方が申請を承認した場合に、フレンド申請が承認されたと判定する。これによれば、被申請ユーザ自身が承認するか否かの判断を行えるとともに、承認ユーザによる承認にも基づいて承認するか否かが判定されるので、被申請ユーザの判断負担を軽減することができる。

なお、他の実施形態においては、サーバ２は、被申請ユーザに対して（フレンド申請を承認するか否かの）問合せを行わず、承認ユーザに対して（のみ）問合せを行うようにしてもよい。すなわち、サーバ２は、上記ステップＳ４〜Ｓ６の処理を実行せずに、ステップＳ７〜Ｓ１１の処理を実行してもよい。これによれば、被申請ユーザは承認するか否かの回答を行わなくてもよいので、被申請ユーザの負担や手間をより軽減することができる。

なお、第１の実施形態では、サーバ２は、被申請端末３ｂから受信した被申請ユーザの回答が申請を承認する旨を示す場合、申請の承認に関する問合せを承認端末３ｃへ送信し、当該回答が申請を承認しない旨を示す場合、当該問合せを承認端末３ｃへ送信しない。これによれば、被申請ユーザが承認しない場合には承認ユーザには問合せが行われないことから、承認ユーザは必要がない場合には問合せに対する回答を行わなくてもよいので、承認ユーザの作業負担を軽減することができる。

また、第１の実施形態（後述する第２の実施形態においても同様）においては、サーバ２は、問合せを承認ユーザの端末装置（承認端末３ｃ）へ送信する前に、被申請ユーザに対して申請の問合せを行っている（ステップＳ４）。つまり、サーバ２は、問合せを承認端末３ｃへ送信する前に、申請ユーザから被申請ユーザに対して申請があったことを被申請端末３ｂへ通知している。これによれば、承認ユーザが承認を行う場合であっても、サーバ２は、申請があったことを被申請ユーザへ事前に通知することができる。例えば、申請人が被申請人の実際の友人である場合等、フレンド申請が不正なものでないことが明らかであり、承認するか否かを被申請人自身が正しく判断することができる場合もある。このような場合、フレンド申請があったことが事前に（つまり、承認ユーザへ問合せが行われるよりも前に）被申請ユーザへ通知されるので、被申請ユーザは、フレンド申請に対して承認するように承認ユーザに対して予め伝えておくことができる。したがって、フレンド申請が承認ユーザによって誤って不承認とされてしまうおそれを低減することができる。

なお、他の実施形態においては、サーバ２は、フレンド申請があった場合、被申請端末３ｂへ通知を行う前に承認端末３ｃに対して問合せを行い、承認端末３ｃから受信された承認ユーザの回答が申請を承認する旨を示す場合に（のみ）、被申請端末３ｂへ当該通知（例えば、申請が行われたことの通知や、申請が承認されたことの通知）を行うようにしてもよい。これによれば、承認されなかったフレンド申請については被申請ユーザに対する通知が行われないので、被申請ユーザの確認の手間を省くことができる。

また、第１の実施形態（後述する第２の実施形態においても同様）においては、サーバ２は、フレンド申請の承認に関する問合せを承認端末３ｃへ送信する場合、申請ユーザに関して保存されるプロフィール情報（閲覧情報２３）のうちの少なくとも一部の情報を当該問合せと共に送信する。これによれば、承認ユーザは、プロフィールの情報を参照することで、承認するか否かの判断を行いやすくなる。なお、サーバ２は、他の実施形態においては、プロフィール情報を送信することに代えて、プロフィール情報を閲覧可能なウェブページにアクセスするためのリンク情報を送信してもよい。

（ユーザ情報を閲覧する処理）
次に、ＳＮＳにおいてユーザが他のユーザの情報（上記閲覧情報等）を閲覧する場合の処理について説明する。本実施形態においては、サーバ２は、ＳＮＳの各ユーザについて、閲覧情報等のユーザに関する情報を表示するためのウェブページのデータをデータ記憶部１４に保存している。ユーザは、ＳＮＳのウェブサイトのうち、所望の他のユーザのウェブページにアクセスすることで、ウェブページを端末装置に表示し、当該他のユーザに関する情報を閲覧することができる。

具体的には、閲覧を行うユーザ（閲覧ユーザ）が、所望の他のユーザ（被閲覧ユーザ）のウェブページを閲覧する場合、当該ウェブページに対するアクセス要求をサーバ２に対して行う。すなわち、閲覧ユーザの端末装置３は、閲覧ユーザの指示に応じて、アクセス要求をサーバ２へ送信する。

サーバ２は、上記アクセス要求を受信した場合、アクセス要求を行った閲覧ユーザが、被閲覧ユーザのフレンドであるか（被閲覧ユーザに関して閲覧ユーザがフレンド登録されているか）否かを判定する。この判定は、被閲覧ユーザのユーザ情報２１に含まれるフレンド情報２６と、アクセス要求に含まれる閲覧ユーザの識別情報とに基づいて行われる。すなわち、閲覧ユーザの識別情報がフレンド情報２６に含まれている場合、閲覧ユーザはフレンド登録されていると判定され、閲覧ユーザの識別情報がフレンド情報２６に含まれていない場合、閲覧ユーザはフレンド登録されていないと判定される。

閲覧ユーザがフレンド登録されていないと判定した場合、サーバ２は、被閲覧ユーザのユーザ情報２１内の閲覧情報２３のうち、非制限情報２５を含み、制限情報２４を含まないウェブページのデータを閲覧ユーザの端末装置３へ送信する。一方、閲覧ユーザがフレンド登録されていると判定した場合、サーバ２は、被閲覧ユーザのユーザ情報２１内の閲覧情報２３のうち、制限情報２４および非制限情報２５を含むウェブページのデータを閲覧ユーザの端末装置３へ送信する。これによって、閲覧ユーザの端末装置３では、閲覧ユーザがフレンド登録されている場合にのみ、被閲覧ユーザの制限情報２４を含むウェブページを取得することができ、この場合にのみ閲覧ユーザは被閲覧ユーザの制限情報２４を閲覧することができる。

なお、ＳＮＳにおいてユーザが他のユーザの情報を閲覧するための方法（例えば、フレンド登録がされている場合にのみ制限情報の閲覧を可能とする方法）は任意であり、従来と同様の方法が用いられてもよい。

［３．サーバ２における処理の具体例］
以下、図６を参照して、第１の実施形態におけるサーバ２において実行されるフレンド登録処理の具体例について説明する。図６は、本実施形態においてサーバ２（制御部１２）が実行する情報処理の流れの一例を示すフローチャートである。本実施形態においては、図６に示す一連の処理は、制御部１２のＣＰＵが、プログラム記憶部１３に記憶される情報処理プログラムを実行することによって行われる。なお、図６においては、フレンド登録に関する処理について示し、サーバ２において実行される他の処理（例えば、ユーザが他のユーザの情報を閲覧するための処理等）については、従来と同様であってもよいため、説明を省略する。

なお、本出願において、図面に示すフローチャートにおける各ステップの処理は、単なる一例に過ぎず、同様の結果が得られるのであれば、各ステップの処理順序を入れ替えてもよいし、各ステップの処理に加えて（または代えて）別の処理が実行されてもよい。また、本明細書では、上記フローチャートの各ステップの処理をＣＰＵが実行するものとして説明するが、上記フローチャートにおける一部のステップの処理を、ＣＰＵ以外のプロセッサや専用回路が実行するようにしてもよい。なお、図６に示す情報処理が開始されるタイミングは任意である。

図６に示す処理においては、まずステップＳ２１において、ＣＰＵは、各端末装置３から送信されてくるデータ（情報）を受信する。すなわち、ＣＰＵは、通信部１１を介して受信される、フレンド申請の申請情報のデータ、および／または、サーバ２からの問合せに対する端末装置３からの回答のデータを取得する。

ステップＳ２２において、ＣＰＵは、フレンド申請があったか否か、すなわち、ステップＳ２１の受信処理においてフレンド申請を受信したか否かを判定する。ステップＳ２２の判定結果が肯定である場合、ステップＳ２３において、ＣＰＵは、受信したフレンド申請に係る被申請ユーザを特定し（ステップＳ３参照）、特定した被申請ユーザ（被申請端末３ｂ）へフレンド申請に対する問合せを行う（ステップＳ４参照）。上述のように、この問合せに応じて、被申請端末３ｂから回答が送信される（ステップＳ６参照）。その結果、上記ステップＳ２１の処理によって、回答がサーバ２において受信される。

ステップＳ２４において、ＣＰＵは、被申請ユーザから回答があったか否か、すなわち、ステップＳ２１において被申請端末３ｂからの回答を受信したか否かを判定する。ステップＳ２４の判定結果が肯定である場合、ステップＳ２５において、ＣＰＵは、受信した被申請ユーザの回答が、申請を承認する旨を示すか否かを判定する。ステップＳ２５の判定結果が否定である場合、ステップＳ２６において、ＣＰＵは、フレンド申請が承認されなかったと判定し、申請ユーザ（及び被申請ユーザ）に対してフレンド申請が拒否された（承認されなかった）ことの通知を行う。この通知処理は、上記ステップＳ１３の処理と同様である。

一方、ステップＳ２５の判定結果が肯定である場合、ステップＳ２７において、ＣＰＵは、被申請ユーザのユーザ情報２１の承認者情報２７に基づいて、被申請ユーザの承認ユーザを特定する（ステップＳ７参照）。続くステップＳ２８において、ＣＰＵは、被申請ユーザの承認ユーザが設定されているか否かを判定する。すなわち、ＣＰＵは、上記ステップＳ２７の処理によって承認ユーザが特定されたか否かを判定する。具体的には、被申請ユーザのユーザ情報２１において承認者情報２７が含まれている場合には、承認ユーザが特定されたと判定され、承認者情報２７が含まれていない場合には、承認ユーザが特定されないと判定される。

ステップＳ２８の判定結果が否定である場合、ステップＳ２９において、ＣＰＵは、申請ユーザを被申請ユーザのフレンドとするフレンド登録を行い、申請ユーザおよび被申請ユーザに対して、フレンド申請が承認されたことの通知を行う。ステップＳ２９の処理は、上記ステップＳ１２およびＳ１３の処理と同様である。

一方、ステップＳ２８の判定結果が肯定である場合、ステップＳ３０において、ＣＰＵは、特定された承認ユーザへ問合せを行う（ステップＳ８参照）。上述のように、この問合せに応じて、承認端末３ｃから回答が送信される（ステップＳ１０参照）。そして、上記ステップＳ２１の処理によって、回答がサーバ２において受信される。

以上のように、本実施形態においては、被申請ユーザがフレンド申請を承認しなかった場合（ステップＳ２５：Ｎｏ）には、承認ユーザに対する問合せが行われることなく、フレンド申請が承認されなかったと判断される（ステップＳ２６）。また、被申請ユーザがフレンド申請を承認した場合（ステップＳ２５：Ｙｅｓ）で、かつ、被申請ユーザに承認ユーザが設定されていない場合（ステップＳ２８：Ｎｏ）には、承認ユーザに対する問合せが行われることなく、フレンド申請が承認されたと判断される（ステップＳ２９）。

ステップＳ３１において、ＣＰＵは、承認ユーザから回答があったか否か、すなわち、ステップＳ２１において承認端末３ｃから回答を受信したか否かを判定する。ステップＳ３１の判定結果が肯定である場合、ステップＳ３２において、ＣＰＵは、受信した承認ユーザの回答が、申請を承認する旨を示すか否かを判定する。ステップＳ３２の判定結果が肯定である場合、ステップＳ３３において、ＣＰＵは、申請ユーザを被申請ユーザのフレンドとするフレンド登録を行い（ステップＳ１２参照）、申請ユーザおよび被申請ユーザに対して、フレンド申請が承認されたことの通知を行う（ステップＳ１３参照）。一方、ステップＳ３２の判定結果が否定である場合、ステップＳ３４において、ＣＰＵは、ステップＳ２６と同様に、申請ユーザ（及び被申請ユーザ）に対して、フレンド申請が拒否されたことの通知を行う。

サーバ２のＣＰＵが上記Ｓ２１〜Ｓ３１の処理を繰り返し実行することによって、図４に示すサーバ２の処理が実行されることになる。

＜第２の実施形態＞
次に、図７〜図９を参照して、第２の実施形態に係る情報処理システムにおいて実行される処理について説明する。第１の実施形態においては、被申請ユーザについての承認ユーザが予め定められており、フレンド申請があった場合には、予め定められた承認ユーザに対して問合せが行われた。これに対して、第２の実施形態においては、被申請ユーザは、フレンド申請毎に承認ユーザを選択するものとする。第２の実施形態は、例えば、正当なものであることが疑わしいフレンド申請が被申請ユーザに対して行われた場合に、被申請ユーザが（すでに登録済みである）フレンドのユーザに対して承認を依頼するケースに適用することができる。

なお、第２の実施形態においては、第１の実施形態との相違点を中心に説明を行い、第１の実施形態と同じ構成又は動作（処理）については説明を省略することがある。また、以下において、第１の実施形態と同じ構成要素又は処理については、第１の実施形態と同じ参照符号又はステップ番号を付し、詳細な説明を省略することがある。

［１．第２の実施形態における処理の概要］
第２の実施形態における情報処理システムの構成は、第１の実施形態と同様である（図１参照）。ただし、サーバ２において記憶されている、被申請ユーザのユーザ情報２１には、フレンド情報２６は予め設定されていないものとする。また、以下では、承認ユーザとして２人のユーザが設定され、各承認ユーザがそれぞれ別の端末装置（図７に示す承認端末３ｃおよび承認端末３ｄ）を用いる場合を例として処理を説明する。

図７は、第２の実施形態におけるフレンド登録処理の流れを示すタイミングチャートである。第２の実施形態においては、被申請ユーザを特定した（ステップＳ３）場合、サーバ２は、被申請端末３ｂへ、フレンド申請があった旨の通知（申請通知）を送信する（ステップＳ４１）。すなわち、サーバ２は、申請通知に関する通知情報２８を被申請ユーザのユーザ情報２１に含めるように当該ユーザ情報２１を更新する。ここで、申請通知は、フレンド申請を承認するか否かの回答と、承認ユーザの選択とのいずれかを被申請ユーザに行わせるための通知である。したがって、通知情報２８には、申請通知時に送信される送信情報として、フレンド申請に対する承認の問合せに対する回答と承認ユーザの選択とを被申請ユーザに行わせるための回答画面（図８参照）の情報が含まれる。その後、被申請ユーザが被申請端末３ｂを用いてサーバ２にアクセスし、ＳＮＳにログインした場合、送信情報がサーバ２から被申請端末３ｂへ送信され、回答画面が被申請端末３ｂの表示装置に表示される。

図８は、申請通知時に被申請端末３ｂに表示される回答画面の一例を示す図である。図８に示すように、回答画面には、第１の実施形態において示した問合せ画面と同様の、メッセージ３１とボタン画像３２および３３とが含まれる。なお、図８においては図示されないが、回答画面には、申請ユーザのプロフィール等の情報が含まれていてもよい。

また、図８に示すように、回答画面には、フレンド申請の承認を依頼する場合に承認ユーザを選択することを通知するメッセージ３６と、承認ユーザの候補リスト３７と、承認を依頼する指示を行うための画像（ボタン画像）３８とが含まれる。候補リスト３７は、承認ユーザとなる候補のユーザの名前（アカウント名）３７ａと、各ユーザが選択されているか否かを表すチェックボックス３７ｂとを含む。被申請ユーザは、上記入力装置を用いて候補リスト３５内のユーザから承認ユーザを選択し、「承認を依頼」と示されたボタン画像３８を指定することで承認ユーザを決定する。

なお、本実施形態においては、承認ユーザの候補として候補リスト３７に含められるユーザは、被申請ユーザの登録済みのフレンド（被申請ユーザについてすでにフレンド登録されているユーザ）である。すなわち、サーバ２は、上記ステップＳ４１において、被申請ユーザに関するユーザ情報２１内のフレンド情報２６に基づいて、被申請ユーザの登録済みのフレンドであるユーザを特定する。そして、特定されたユーザを含む候補リスト３７を作成して、通知情報２８内の送信情報に候補リストを含めて記憶しておく。候補リストには、承認ユーザの候補となるユーザの識別情報および／または名前の情報が含まれる。

なお、承認ユーザの候補となるユーザの特定方法は任意である。例えば他の実施形態においては、サーバ２は、被申請ユーザの登録済みのフレンドに加えて（または代えて）申請ユーザの登録済みのフレンドを候補としてもよい。また例えば、サーバ２は、被申請ユーザの登録済みのフレンドであり、かつ、申請ユーザの登録済みのフレンドであるユーザを候補としてもよい。また例えば、ＳＮＳの運営者側で承認ユーザを用意しておき、用意された承認ユーザを候補に加えるようにしてもよい。

申請通知に対して、被申請ユーザは、フレンド申請に対して承認するか否かを回答するか、または、承認ユーザを選択して承認を依頼するかのいずれかの入力を行う。図７においては、承認ユーザを選択して承認を依頼する入力が行われた（ステップＳ４２）場合を示しており、この場合、被申請端末３ｂは、サーバ２に対して選択された承認ユーザを通知する（ステップＳ４３）。この通知には、選択された承認ユーザを特定する情報（識別情報や名前等）が含まれる。

選択された承認ユーザの情報が被申請端末３ｂからサーバ２へ通知される場合、サーバ２は、受信した通知に基づいて承認ユーザを特定する（ステップＳ４４）。このとき、特定された承認ユーザの識別情報は、被申請ユーザのユーザ情報２１内の承認者情報２７としてデータ記憶部１４に記憶される。

特定された承認ユーザに対してサーバ２から承認端末へ問合せを行い、承認端末において問合せに対する回答が入力され、回答結果を承認端末からサーバ２へ送信する動作は、第１の実施形態におけるステップＳ８〜Ｓ１０における動作と同様である。ただし、第２の実施形態においては、ステップＳ８〜Ｓ１０における動作がサーバ２と複数の承認端末との間で行われることがある（図７参照）。

サーバ２は、問合せを行った全ての承認端末３ｃおよび３ｄから回答結果を受信すると、回答結果を集計し、集計結果に基づいてフレンド申請を承認するか否かを判定する（ステップＳ４５）。承認ユーザが複数である場合、サーバ２は、複数の回答結果が所定の条件を満たすか否かによって上記判定を行う。上記所定の条件の内容は任意であるが、例えば、回答結果の多数決（承認する旨の回答が承認しない旨の回答より多いか）であってもよいし、承認する旨の回答が所定数以上であることであってもよい。

また、他の実施形態においては、サーバ２は、フレンド申請を承認するか否かの回答を承認端末から受信することに代えて、フレンド申請の承認に関する回答として、承認を支持する度合いを示す指標（得点等）を承認端末から受信するようにしてもよい。そして、各承認端末から受信した指標の集計結果である数値が所定の条件を満たすか否かによってフレンド申請を承認するかを判定してもよい。例えば、サーバ２は、承認端末から回答として得点の情報を受信し、受信された得点の合計値（または平均値）が所定以上であることを条件として、フレンド申請を承認するようにしてもよい。

フレンド申請を承認するか否かを判定した後におけるサーバ２の処理は、第１の実施形態と同様である。すなわち、フレンド申請を承認すると判定した場合には、申請ユーザを被申請ユーザのフレンドとして登録する（ステップＳ１２）。また、サーバ２は、（判定結果がいずれの場合でも）判定結果を申請ユーザおよび被申請ユーザへ通知する（ステップＳ１３）。第２の実施形態においては、このとき、サーバ２は、ステップＳ４４でデータ記憶部１４に記憶した承認者情報２７を削除する。

［２．第２の実施形態におけるサーバ２の処理の具体例］
以下、図９を参照して、第２の実施形態におけるサーバ２において実行されるフレンド登録処理の具体例について説明する。図９は、第２の実施形態においてサーバ２（制御部１２）が実行する情報処理の流れの一例を示すフローチャートである。なお、図９においては、第１の実施形態との相違点を中心に処理の流れを示しており、第１の実施形態における処理（図６）と同じ処理については同じステップ番号を付し、詳細な説明を省略する。

第２の実施形態においては、ステップＳ２２の判定結果が肯定であった場合、ステップＳ５１において、ＣＰＵは、受信したフレンド申請に係る被申請ユーザを特定し（上記ステップＳ３参照）、特定した被申請ユーザ（被申請端末３ｂ）へ上述の申請通知を送信する（ステップＳ４１参照）。上述のように、この申請通知に応じて、フレンド申請を承認するか否かの回答と、選択された承認ユーザの通知とのいずれかが被申請端末３ｂから送信される（ステップＳ４３参照）。そして、上記ステップＳ２１の処理によって、上記の回答または通知がサーバ２において受信される。

第２の実施形態においては、ステップＳ２２の判定結果が否定であった場合、または、ステップＳ５１の処理に続いて、上述のステップＳ２４の処理が実行される。すなわち、ステップＳ２４において、ＣＰＵは、被申請ユーザから回答があったか否かを判定する。ステップＳ２４の判定結果が肯定である場合、ステップＳ２５において、受信した被申請ユーザの回答が、申請を承認する旨を示すか否かを判定する。ステップＳ２５の判定結果が肯定である場合、ステップＳ３３の処理が実行され、ステップＳ２５の判定結果が否定である場合、ステップＳ３４の処理が実行される。つまり、被申請ユーザから回答に従ってフレンド申請を承認するか否かが判定され、判定に応じた処理が実行される。

一方、ステップＳ２４の判定結果が否定である場合、ステップＳ５２において、ＣＰＵは、被申請ユーザが選択した承認ユーザの通知があったか否か、すなわち、ステップＳ２１において被申請端末３ｂから当該通知を受信したか否かを判定する。ステップＳ５２の判定結果が肯定である場合、ステップＳ５３において、ＣＰＵは、被申請ユーザからの通知に基づいて承認ユーザを特定し（ステップＳ４４参照）、特定した承認ユーザに対してサーバ２から承認端末へ問合せを行う（ステップＳ８参照）。上述のように、この問合せに応じて、承認端末から回答が送信される（ステップＳ１０参照）。そして、上記ステップＳ２１の処理によって、回答がサーバ２において受信される。本実施形態においては、ＣＰＵは、受信した回答を制御部１２内のメモリまたはデータ記憶部１４に記憶しておく。

ステップＳ５４において、ＣＰＵは、被申請ユーザによって選択された全ての承認ユーザから回答を受信したか否かを判定する。ステップＳ５４の判定結果が肯定である場合、ステップＳ５５において、ＣＰＵは、承認ユーザの回答結果を集計する。例えば、ＣＰＵは、集計結果として、承認する旨を示す回答結果の数、および、承認しない旨を示す回答結果の数を算出し、メモリに記憶する。続くステップＳ５６において、ＣＰＵは、メモリに記憶されている集計結果を読み出し、集計結果に基づいて、フレンド申請を承認するか否かを判定する（ステップＳ４５参照）。この判定は、例えば、承認する旨を示す回答結果の数が、承認しない旨を示す回答結果の数を上回ったか否かによって行われる。

ステップＳ５６の判定結果が肯定である場合、第１の実施形態と同様のステップＳ３３の処理が実行され、ステップＳ５６の判定結果が否定である場合、第１の実施形態と同様のステップＳ３４の処理が実行される。

以上のように、第２の実施形態においては、サーバ２は、フレンド申請が受信された場合、当該フレンド申請に関する承認者（承認ユーザ）を選択するための問合せ（申請通知）を被申請端末３ｂへ送信し（ステップＳ４１）、被申請端末３ｂから、選択された承認ユーザを示す情報を受信する（ステップＳ４３）。そして、サーバ２は、受信された承認ユーザを示す情報に基づいて承認者を特定する（ステップＳ４４）。したがって、第２の実施形態によれば、被申請ユーザはフレンド申請毎に承認ユーザを設定することができ、申請ユーザに応じた適切な承認ユーザを選択することができる。例えば、被申請ユーザは、申請ユーザが被申請ユーザの勤め先の同僚である場合には、同じ同僚である登録済みのフレンドを承認ユーザとしたり、申請ユーザが被申請ユーザと同じ学校の卒業生である場合には、同じ学校の卒業生である登録済みのフレンドを承認ユーザとしたりすることができる。

また、第１および第２の実施形態においては、サーバ２は、被申請ユーザの端末装置から承認ユーザを設定するか否かに関する情報を受信し、受信した情報に基づいて、承認ユーザを設定するか否かを判定する。そして、サーバ２は、承認ユーザを設定すると判定された場合に承認ユーザを特定する（ステップＳ４４）。このように、第２の実施形態によれば、承認ユーザを設定するか否かを被申請ユーザに選択させるので、被申請ユーザは、フレンド申請の承認の判断を自身で行うこともできるし、他のユーザに承認を依頼することもできる。これによって、被申請ユーザの承認判断による負担を軽減することができるとともに、（承認の依頼を不要と判断した場合には）申請ユーザを容易にフレンドとして登録することができる。

また、第２の実施形態においては、サーバ２は、複数の承認ユーザを特定してもよい（図７参照）。このとき、サーバ２は、特定された複数の承認ユーザそれぞれの端末装置へ問合せを送信するとともに、各端末装置から回答を受信する。サーバ２は、受信された各回答から、承認を支持する度合いを示す数値（例えば、承認する旨を回答した承認ユーザの数。承認を支持しない度合いを示す数値とも言える。）を算出し、算出された数値が所定の条件を満たすか否かによって、申請を承認するか否かを判定する。これによれば、複数の承認ユーザが設定される場合に、承認するか否かを容易に判断することができる。

＜第３の実施形態＞
次に、図１０〜図１３を参照して、第３の実施形態に係る情報処理システムにおいて実行される処理について説明する。第１および第２の実施形態においては、被申請ユーザは、他のユーザに対してフレンド申請の承認を依頼した。これに対して、第３の実施形態においては、被申請ユーザは、自身がフレンド申請の承認を判断する上での参考とするために、他のユーザに対してフレンド申請（つまり申請ユーザ）の評価を依頼する。第３の実施形態は、例えば、正当なものであることが疑わしいフレンド申請が被申請ユーザに対して行われた場合に、被申請ユーザが（すでに登録済みである）フレンドのユーザに対して評価を依頼するケースに適用することができる。

なお、第３の実施形態においては、第１および第２の実施形態との相違点を中心に説明を行い、第１および第２の実施形態と同じ構成又は動作（処理）については説明を省略することがある。また、以下において、第１および第２の実施形態と同じ構成要素又は処理については、第１および第２の実施形態と同じ参照符号又はステップ番号を付し、詳細な説明を省略することがある。

［１．第３の実施形態における処理の概要］
以下、図１０〜図１２を参照して、第３の実施形態における情報処理システム１において実行されるフレンド登録処理の概要について説明する。図１０は、フレンド登録が行われる場合における動作の流れを大略的に示す図である。以下では、図１０に示すように、申請ユーザが被申請ユーザに対してフレンド申請を行い（図１０に示す（１））、被申請ユーザが評価ユーザに承認を依頼し（図１０に示す（２））、評価ユーザが申請ユーザに対する評価を被申請ユーザに通知し（図１０に示す（３））、その評価を参考に被申請ユーザが承認／不承認を行う（図１０に示す（４））場合における、情報処理システム１における処理について説明する。また、以下では、評価ユーザとして２人のユーザが設定され、各評価ユーザがそれぞれ別の端末装置（図７に示す評価端末３ｅおよび評価端末３ｆ）を用いる場合を例として処理を説明する。

第３の実施形態における情報処理システムの構成は、第１の実施形態と同様である（図１参照）。ただし、サーバ２において記憶されている、被申請ユーザのユーザ情報２１の内容は第１の実施形態と相違する。すなわち、第３の実施形態においては、承認者情報２７に代えて評価者情報がユーザ情報２１に含まれる。評価者情報は、ユーザに対するフレンド申請を評価する（申請ユーザを評価するとも言える）権限を有する他のユーザ（評価ユーザ）の識別情報を示す。つまり、評価者情報は、ユーザがフレンド申請の評価を他のユーザに依頼する場合に設定される。ユーザ情報２１内に評価者情報が設定される場合、ユーザ情報２１に対応するユーザに対するフレンド申請は、評価者情報により示される評価ユーザによって評価が行われる（詳細は後述する）。

図１１は、第３の実施形態におけるフレンド登録処理の流れを示すタイミングチャートである。なお、図１１では図示しないが、申請端末３ａにおいてフレンド申請が入力されてサーバ２へ送信され、サーバ２において被申請ユーザが特定される処理（ステップＳ１〜Ｓ３）は、第１の実施形態と同様である。

第３の実施形態においては、被申請ユーザを特定した場合、サーバ２は、被申請端末３ｂへ、フレンド申請があった旨の通知（申請通知）を送信する（ステップＳ６１）。この申請通知は、第２の実施形態では承認ユーザの選択を行わせるのに対して、第３の実施形態では評価ユーザの選択を行わせるかという点で異なる他は、第２の実施形態におけるステップＳ４１と同様である。また、回答画面において被申請ユーザに提示される評価ユーザの候補となるユーザの決定方法も、第２の実施形態と同様である。

申請通知に対して、被申請ユーザは、フレンド申請に対して承認するか否かを回答するか、または、評価ユーザを選択して評価を依頼するかのいずれかの入力を行う。図１１においては、評価ユーザを選択して評価を依頼する入力が行われた（ステップＳ６２）場合を示しており、この場合、被申請端末３ｂは、サーバ２に対して選択された評価ユーザを通知する（ステップＳ６３）。この通知には、選択された評価ユーザを特定する情報（識別情報や名前等）が含まれる。

選択された評価ユーザの情報が被申請端末３ｂからサーバ２へ通知される場合、サーバ２は、受信した通知に基づいて評価ユーザを特定する（ステップＳ６４）。また、サーバ２は、特定された評価ユーザに対してサーバ２から評価端末３ｅおよび３ｆへ問合せを行う（ステップＳ６５）。各評価端末３ｅおよび３ｆにおいては、この問合せに対する回答（フレンド申請に対する評価）が入力される（ステップＳ６６）。回答が入力されると、各評価端末３ｅおよび３ｆは、回答結果をサーバ２へ送信する（ステップＳ６７）。ステップＳ６５〜Ｓ６７の処理は、評価端末において入力される回答が、フレンド申請に対する評価である点を除いて、第１および第２の実施形態におけるステップＳ８〜Ｓ１０の処理と同様である。

ここで、第３の実施形態において、評価端末において入力される回答（評価）は、フレンド申請に対する評価を表すものであればどのようなものであってもよい。例えば、承認を支持する度合いを示す数値が回答として入力されてもよいし、第１および第２の実施形態と同様、承認するか否かを示す回答が入力されてもよい。また、評価ユーザによるコメント（メッセージ）が回答として入力されてもよい。

サーバ２は、問合せを行った全ての評価端末３ｅおよび３ｆから回答結果を受信すると、回答結果を集計する（ステップＳ６８）。例えば、回答結果が、承認を支持する度合いを示す数値である場合には、各数値の合計値または平均値が集計結果として算出されてもよい。また例えば、回答結果が、承認するか否かを示す情報である場合には、承認する旨の回答の数、および／または、承認しない旨の回答の数が集計結果として算出されてもよい。なお、他の実施形態においては、集計結果を算出する処理は実行されなくてもよく、後述するステップＳ６９においてサーバ２は評価端末からの回答結果（評価結果）をそのまま被申請端末３ｂへ送信してもよい。

集計結果を算出すると、サーバ２は、集計結果を含めて、フレンド申請を承認するか否かの問合せを被申請端末３ｂへ送信する（ステップＳ６９）。集計結果を含む問合せを被申請端末３ｂへ送信する方法は、上記ステップＳ４において問合せを送信する方法と同様である。具体的には、第３の実施形態においては、集計結果を提示するとともに、フレンド申請に対する回答（承認／不承認）の回答を入力するための画像を含む問合せ画面を表示するための情報がサーバ２から被申請端末３ｂへ送信され、当該問合せ画面が被申請端末３ｂに表示される。

図１２は、第３の実施形態における問合せ画面の一例を示す図である。図１２に示すように、問合せ画面には、承認ユーザによる評価があったことを示すメッセージ３９と、評価の集計結果を示す画像４０とが含まれる。また、問合せ画面には、第１の実施形態と同様のボタン画像３２および３３と、申請ユーザのプロフィール３５とが含まれる。被申請ユーザは、画像４０により示される集計結果（およびプロフィール３５）を参考に、ボタン画像３２および３３を用いて、フレンド申請を承認するか否かの回答を入力する。入力が行われたことに応じて、被申請端末３ｂは、第１の実施形態におけるステップＳ６と同様、回答結果（承認または不承認）を示す情報をサーバ２へ送信する（ステップＳ７１）。

サーバ２は、被申請端末３ｂから送信されてくる回答を受信し、フレンド申請を承認するか否かの判定を回答に基づいて行う（ステップＳ７２）。そして、フレンド申請を承認すると判定した場合には、第１および第２の実施形態と同様、申請ユーザが被申請ユーザのフレンドとして登録される（ステップＳ１２）。さらに、サーバ２は、第１および第２の実施形態と同様、判定結果を申請ユーザおよび被申請ユーザへ通知する（ステップＳ１３）。

［２．第３の実施形態におけるサーバ２の処理の具体例］
以下、図１３を参照して、第３の実施形態におけるサーバ２において実行されるフレンド登録処理の具体例について説明する。図１３は、第３の実施形態においてサーバ２（制御部１２）が実行する情報処理の流れの一例を示すフローチャートである。なお、図１３においては、第１および第２の実施形態との相違点を中心に処理の流れを示しており、第１の実施形態における処理（図６）と同じ処理については同じステップ番号を付し、詳細な説明を省略する。

第３の実施形態においては、第２の実施形態におけるステップＳ５１〜Ｓ５４の処理に代えてステップＳ８１〜Ｓ８４の処理が実行される。ステップＳ８１〜Ｓ８４の処理は、承認ユーザに関する処理であるか評価ユーザに関する処理であるかで異なる他は、ステップＳ５１〜Ｓ５４の処理と同様である。

第３の実施形態においては、ステップＳ８４の判定結果が肯定である場合、ステップＳ８５の処理が実行される。ステップＳ８５において、ＣＰＵは、評価ユーザから受信した回答結果（評価結果）を集計する。ステップＳ８５に続くステップＳ８６において、ＣＰＵは、集計結果を被申請ユーザ（被申請端末３ｂ）へ通知する。上述のように、この通知に応じて、フレンド申請を承認するか否かの回答が被申請端末３ｂから送信される（上記ステップＳ７１参照）。この回答は、上記ステップＳ２１の処理によってサーバ２において受信されると、ステップＳ２４の判定結果が肯定となり、ステップＳ２５においてフレンド申請を承認するか否かの判定がサーバ２において行われる。

以上のように、第３の実施形態においては、サーバ２は、被申請ユーザに対して行われた申請を評価する権限を有する評価者（評価ユーザ）として、被申請ユーザとは別のユーザを特定する（ステップＳ６４，Ｓ８１）。そして、サーバ２は、申請ユーザに対する評価に関する問合せを評価端末３ｅおよび３ｆへ送信し（ステップＳ６５，Ｓ８１）、評価端末３ｅおよび３ｆから問合せに関する回答を受信する（ステップＳ６７）。サーバ２は、受信された回答に基づいて得られる評価情報（集計結果）とともにフレンド申請の承認に関する問合せを被申請端末３ｂへ送信し（ステップＳ６９）、被申請端末３ｂから問合せに関する回答を受信する（ステップＳ７１）。さらに、サーバ２は、被申請端末３ｂから受信された回答に基づいて、フレンド申請を承認するか否かの判定を行い（ステップＳ７２）、フレンド申請を承認すると判定した場合、被申請ユーザに対する登録ユーザ（フレンド）として申請ユーザの識別情報を記憶する。以上によれば、被申請ユーザは、自身に対するフレンド申請に関する評価を評価者（評価ユーザ）に依頼することができ、評価者による評価を参考に、フレンド申請を承認するか否かを判断することができる。これによって、フレンド申請を承認するか否かの判断による被申請ユーザの負担を軽減することができる。

また、第３の実施形態においては、フレンド申請がある度に被申請ユーザが評価ユーザを設定する。すなわち、サーバ２は、フレンド申請があった場合、当該フレンド申請に関する評価ユーザを選択するための問合せを被申請端末３ｂへ送信し（ステップＳ６１）、被申請端末３ｂから、選択された評価ユーザを示す情報を受信する（ステップＳ６３）。そして、サーバ２は、受信された評価ユーザを示す情報に基づいて評価ユーザを特定する（ステップＳ６４）。これによれば、被申請ユーザはフレンド申請毎に評価ユーザを設定することができ、申請ユーザに応じた適切な評価ユーザを選択することができる。

また、第３の実施形態においては、評価ユーザを設定するか否かをフレンド申請がある度に被申請ユーザが選択する。すなわち、サーバ２は、評価ユーザを設定するか否かの問合せを被申請端末３ｂへ送信し（ステップＳ６１，Ｓ８１）、被申請端末３ｂからの回答に基づいて、評価ユーザを設定するか否かを判定する（ステップＳ２４，Ｓ８２）。そして、サーバ２は、評価ユーザを設定すると判定された場合に評価ユーザを特定する（ステップＳ８３）。これによれば、被申請ユーザの承認判断による負担を軽減することができるとともに、（評価の依頼を不要と判断した場合には）申請ユーザを容易にフレンドとして登録することができる。

なお、他の実施形態においては、第１の実施形態における承認ユーザの設定方法と同様に、サーバ２は、少なくとも１のユーザについて、そのユーザに対して行われたフレンド申請を評価する権限を有する評価ユーザの識別情報をフレンド申請の前に予め記憶装置に記憶しておくようにしてもよい。そして、サーバ２は、記憶装置に記憶されている評価ユーザの識別情報に基づいて評価ユーザを特定してもよい。これによれば、被申請ユーザは、フレンド申請の度に評価ユーザを選択する必要が無いので、簡単に評価ユーザを設定することができる。

また、第３の実施形態においては、サーバ２は、申請ユーザに対する評価に関する問合せを評価端末へ送信する場合、申請ユーザに関して保存されるプロフィール情報（閲覧情報２３）のうちの少なくとも一部の情報を当該問合せと共に送信する。これによれば、評価ユーザは、プロフィールの情報を参照することで評価を行いやすくなる。

また、第３の実施形態においては、サーバ２は、複数の評価ユーザを特定してもよい（図１０参照）。このとき、サーバ２は、特定された複数の評価ユーザそれぞれの端末装置へ問合せを送信するとともに、各端末装置から回答を受信する。サーバ２は、受信された各回答から、評価の指標を示すパラメータ（集計結果）を算出し、算出されたパラメータとともにフレンド申請の承認に関する問合せを被申請端末３ｂへ送信する。これによれば、複数の評価ユーザが設定される場合に、評価結果をわかりやすく被申請ユーザに提示することができ、被申請ユーザは、承認するか否かの判断を行いやすくなる。

＜変形例＞
（申請ユーザに申請許可ユーザが設定される変形例）
上記第１〜第３の実施形態における変形例においては、フレンド申請を行うことを許可する権限を有する申請許可者として、申請ユーザとは別の許可ユーザが設定されてもよい。図１４は、第１の実施形態における変形例において、フレンド申請が行われる場合における動作の流れを大略的に示す図である。図１４に示すように、本変形例においては、ある申請ユーザが他の被申請ユーザに対してフレンド申請を行った場合（図１４に示す（１））、当該フレンド申請に対して許可ユーザが許可するか否かを判断し（図１４に示す（２））、許可された場合に、被申請ユーザに対してフレンド申請が通知される（図１４に示す（３））。なお、図１４では、申請ユーザが用いる申請端末３ａと、許可ユーザが用いる許可端末３ｇとはそれぞれ別の端末装置であるとするが、これらの端末として同じ（１つの）情報処理装置が用いられてもよい。

図１５は、図１４に示す変形例におけるフレンド申請処理の流れを示すタイミングチャートである。まず、申請ユーザが申請端末３ａを用いてフレンド申請の入力を行い（ステップＳ１）、フレンド申請が申請端末３ａからサーバ２へ送信される（ステップＳ２）点は、第１の実施形態と同様である。

本変形例においては、申請端末３ａからフレンド申請を受信すると、サーバ２は、申請ユーザに設定される許可ユーザを特定する（ステップＳ９１）。許可ユーザの特定は、上記被申請ユーザに設定される承認ユーザを特定する方法と同様の方法で行うことができる。すなわち、サーバ２は、申請ユーザに設定される許可ユーザを特定可能な情報（識別情報等）を許可者情報としてユーザ情報２１に含めて記憶しておく。フレンド申請があった場合、サーバ２は、申請ユーザのユーザ情報２１内の許可者情報を参照することによって、許可ユーザを特定する。なお、申請ユーザに対して許可ユーザが設定されていない場合、サーバ２は、第１の実施形態と同様に、被申請ユーザを特定して被申請端末３ｂへフレンド申請に対する問合せを行う。

許可ユーザを特定した場合、サーバ２は、許可ユーザの端末である許可端末３ｇへ、フレンド申請を許可するか否かの問合せを行う（ステップＳ９２）。この問合せを許可端末３ｇへ送信する方法は、上記ステップＳ４において問合せを被申請端末３ｂへ送信する方法と同様である。ステップＳ９２では、送信情報として、許可端末３ｇにおいて問合せ画面を表示するための情報が送信される。

許可端末３ｇにおいてサーバ２からの送信情報が受信されると、許可端末３ｇは、上記問合せ画面を表示装置に表示する。この問合せ画面には、申請ユーザによるフレンド申請を許可するか否かを回答するための画像が含まれる。また、サーバ２は、問合せの際に被申請ユーザの名前および／またはプロフィールの情報を送信し、問合せ画面には、被申請ユーザの名前および／またはプロフィールが含まれていてもよい。

許可端末３ｇにおいて上記問合せ画面が表示された場合、許可ユーザは、問合せ画面に対して入力を行うことによって、フレンド申請を許可するか否かの回答を入力する（ステップＳ９３）。入力が行われたことに応じて、許可端末３ｇは、回答結果（許可または不許可）を示す情報をサーバ２へ送信する（ステップＳ９４）。回答には、申請ユーザの識別情報と、フレンド申請の許可または不許可を示す回答結果の情報とが含まれる。

許可端末３ｇから送信されてくる許可ユーザの回答を受信すると、サーバ２は、フレンド申請を行う（被申請ユーザにフレンド申請を通知する）か否か、換言すれば、フレンド申請が有効か否かを判定する（ステップＳ９５）。受信された許可ユーザの回答が許可を示す場合、サーバ２は、フレンド申請を行うと判定し、図示しないが、上記第１の実施形態と同様に、被申請端末３ｂへフレンド申請に対する問合せを行う（上記ステップＳ４参照）。その後、被申請ユーザが承認ユーザに承認を依頼した場合には、第１の実施形態と同様、フレンド申請を承認するか否かの問合せが承認ユーザに対して行われる（ステップＳ８参照）。

一方、受信された許可ユーザの回答が不許可を示す場合、サーバ２は、フレンド申請を行わないと判定し、図示しないが、申請ユーザへフレンド申請を行わない旨を通知する。

以上のように、上記変形例においては、サーバ２は、フレンド申請を受信した場合、フレンド申請を行うことを許可する権限を有する申請許可者として、申請ユーザとは別の許可ユーザを特定する（ステップＳ９１）。そして、サーバ２は、フレンド申請を許可することに関する問合せを許可端末３ｇへ送信し、許可端末３ｇから問合せに関する回答を受信する（ステップＳ９４）。受信された回答がフレンド申請を許可する旨を示す場合、サーバ２は、申請ユーザによるフレンド申請を有効とみなし、一方、受信された回答がフレンド申請を許可しない旨を示す場合、申請ユーザによる申請を無効とする（却下する）。フレンド申請が有効とみなされた場合、フレンド申請の承認に関する問合せが承認端末へ送信される。以上によれば、申請ユーザがフレンド申請を行うことを他の許可ユーザによって制限することができる。例えば、申請ユーザが子供である場合には、正当であることが疑わしいユーザに対してフレンド申請を行ってしまう結果、正当でないユーザをフレンド登録してしまうおそれがある。これに対して、上記変形例によれば、申請ユーザに対して親（保護者）を許可ユーザに設定しておくことで、疑わしいユーザに対して子供がフレンド申請を行ってしまうことを防止することができる。

なお、上記においては、上記変形例を第１の実施形態に適用する場合を例として説明したが、本変形例は、第２および第３の実施形態に適用することも可能である。

（承認者がユーザ登録されていない場合における変形例）
上記第１の実施形態においては、承認ユーザがＳＮＳのユーザとして登録されている場合を例として説明した。ここで、他の実施形態においては、ＳＮＳのユーザでない者を承認者として設定するようにしてもよい。以下、上記第１の実施形態の変形例として、承認者がユーザ登録されていない場合における情報処理システム１の処理について説明する。

本変形例では、承認者は、ＳＮＳについてユーザ登録を行っておらず（そのため、識別情報が付されていない）、サーバ２と通信可能な所定の情報処理装置を用いるものとする。ここで、本変形例においては、承認者情報２７として、承認者が用いる情報処理装置（承認装置）と通信を行うための通信情報（例えばメールアドレス等）がデータ記憶部１４に記憶される。

承認者に問合せを行う場合、サーバ２は、上記通信情報を用いて承認装置と通信を行うことによって、問合せに関する送信情報を承認装置へ送信する。例えば、承認装置のメールアドレスを用いて送信情報を電子メールで送信する。送信情報の具体的な内容は任意であるが、例えば、サーバ２は、上述の問合せ画面と同様のウェブページを用意しておき、当該ウェブページにアクセスするための情報（リンク情報）を送信情報として送信してもよい。このウェブページ（問合せ画面）には、上記第１の実施形態と同様、申請ユーザのプロフィールが含まれていてもよい。承認装置が問合せを受信した場合、承認者は、上記ウェブページにアクセスして、回答を入力する。サーバ２は、ウェブページ上で行われた回答を取得し、取得した回答に基づいてフレンド申請を承認するか否かを判定する（上記ステップＳ１１参照）。

上記変形例によれば、サーバ２は、アカウントが付与されたユーザに関してユーザ情報２１を保存する一方、アカウントが付与されない承認者に対して問合せを送信する。ここで、サーバ２は、アカウントが付与されない承認者に対して問合せを送信する場合、当該問合せに対する回答を行うためのウェブページにアクセスするためのリンク情報を含む情報を承認者の情報処理装置へ送信し、当該ウェブページ上で承認者の情報処理装置によって行われた回答を取得する。これによれば、ＳＮＳのアカウントを持たない者を承認者にすることができる。ＳＮＳを利用しない承認者は、承認を行うためにユーザ登録を行う必要がないので、ＳＮＳを利用しない承認者の手間を省くことができる。なお、他の実施形態においては、アカウントが付与されない承認者だけでなく、アカウントが付与された承認者（上記第１および第２の実施形態における承認ユーザ）に対しても、上記変形例における方法で承認者から回答を取得してもよい。この場合でも、上記変形例と同様の効果を得ることができる。

なお、上記変形例は、第１の実施形態に限らず、第２の実施形態において承認者を設定する場合にも適用することができる。また、第３の実施形態において評価者を設定する場合、および、上述した申請許可者を設定する場合にも上記変形例を適用することができる。

（承認ユーザからの回答がない場合における変形例）
上記第１および第２の実施形態においては、サーバ２は、（全ての）承認ユーザからの回答を受信したことに応じて、フレンド申請を承認するか否かを判定した（ステップＳ３１，Ｓ５４参照）。ここで、他の実施形態においては、サーバ２は、承認ユーザに対する問合せが行われてから所定期間内に当該問合せに対する回答が（承認端末から）受信されない場合、当該問合せに対する回答はフレンド申請を承認しない旨を示すと判定してもよい。例えば、承認ユーザが１人である場合に、問合せが行われてから所定期間が経過しても当該問合せに対する回答が受信されなければ、サーバ２は、フレンド申請を承認しないと判定してもよい。また例えば、承認ユーザが複数である場合に、問合せが行われてから所定期間が経過しても一部の承認ユーザから当該問合せに対する回答が受信されなければ、サーバ２は、当該一部の承認ユーザの回答はフレンド申請を承認しない旨を示すと判定してもよい。そして、所定期間が経過した時点で、各承認ユーザからの回答に基づいて、フレンド申請を承認するか否かを判定してもよい。以上によれば、サーバ２は、承認ユーザからの回答が受信されない場合でも、フレンド申請を承認するか否かの判定を実行することができる。

（承認ユーザによってフレンド申請が追認される変形例）
他の実施形態においては、サーバ２は、フレンド申請を被申請ユーザが承認したことに応じて、申請ユーザを被申請ユーザのフレンドとして仮登録してもよい。このとき、所定期間内に承認ユーザによってフレンド申請が承認（追認）された場合、サーバ２は、申請ユーザを被申請ユーザのフレンドとして本登録し、所定期間内に承認ユーザによってフレンド申請が承認（追認）されなかった場合、サーバ２は、仮登録を解消し、フレンド申請を承認しないようにしてもよい。これによれば、被申請ユーザの承認によってフレンド登録を迅速に行うことができるとともに、承認ユーザの承認結果を考慮したフレンド登録を行うことができる。

（フレンド申請および承認を行うユーザの名義に関する変形例）
上記実施形態および変形例においては、フレンド申請はフレンド申請を行った申請ユーザ自身の名義で行われた。つまり、サーバ２は、被申請ユーザに対して、申請ユーザからフレンド申請があったことを通知した（図６参照）。また、フレンド申請の承認は、フレンド申請を受けた被申請ユーザの名義で行われた。ここで、他の実施形態においては、申請ユーザに許可ユーザが設定される場合、当該申請ユーザによるフレンド申請は、許可ユーザの名義で行われたものとして被申請ユーザに対して通知されてもよい。また、被申請ユーザに承認ユーザが設定される場合、承認ユーザによる承認は、承認ユーザの名義で行われたものとして申請ユーザに通知されてもよい。

（上記実施形態の組み合わせに関する変形例）
上記実施形態においては、承認ユーザが予め設定されているユーザの例（第１の実施形態）、フレンド申請毎に承認ユーザが設定されるユーザの例（第２の実施形態）、および、評価ユーザが設定されるユーザの例（第３の実施形態）について説明した。他の実施形態においては、単一のＳＮＳにおいて、これらのユーザが混在していてもよい。さらに、上記変形例で説明した許可ユーザが設定されるユーザが含まれていてもよい。このとき、サーバは、ユーザ情報に承認者情報、評価者情報、および許可者情報を必要に応じて含めて記憶する。そして、被申請ユーザのユーザ情報に承認者情報および評価者情報が設定されていない場合、サーバは、フレンド申請があったことを通知する際に、被申請ユーザ自身が承認を行うか、他のユーザに承認を依頼するか、他のユーザに評価を依頼するかを被申請ユーザに選択させるようにしてもよい。

（フレンドのレベルに関する変形例）
上記実施形態においては、サーバ２は、フレンド登録が行われているユーザであるかフレンド登録が行われていないユーザであるかによって、閲覧情報２３のうちで閲覧可能な情報に差を付けるようにした。ここで、他の実施形態においては、サーバ２は、フレンド登録に複数のレベルを設定し、閲覧するユーザのレベルに応じて、閲覧情報２３のうちで閲覧可能な情報に差を付けるようにしてもよい。この場合、フレンド申請はレベル毎に行われる。

（登録されたユーザに付与される権限に関する変形例）
上記実施形態においては、あるユーザに対して登録（フレンド登録）された他のユーザに対して、当該あるユーザに関する所定の情報を閲覧する権限を付与する場合を例として説明を行った。ここで、他の実施形態においては、登録された他のユーザに対して付与される権限の内容は任意である。あるユーザについて登録された他のユーザに対して付与される権限は、例えば、当該あるユーザに対して情報（例えば、当該あるユーザが書き込んだ日記等の情報に対するコメントやメッセージ等）を送信する権限であってもよいし、当該あるユーザのデータ（動画データや音楽データ等）を共有することができる権限であってもよい。

また、他の実施形態においては、サーバは、複数のユーザに関する情報を保存し、あるユーザに関する所定の情報を他のユーザに対して提供する任意のサーバ（サーバシステム）であってよい。例えば、サーバは、オンラインゲームやソーシャルゲーム等の種類のゲームを提供するゲームサーバであってもよい。この場合、登録された他のユーザに対して付与される権限としては、フレンド登録されたユーザ（プレイヤ）同士でゲームをプレイする権限や、フレンド登録されたユーザ同士でデータ交換を行う権限が考えられる。

上記実施形態および変形例は、他のユーザからの申請を承認するか否かの判断によるユーザの負担を軽減すること等を目的として、例えばＳＮＳを提供するサーバシステムとして利用することができる。

１ 情報処理システム
２ サーバ
３ 端末装置
１１ 通信部
１２ 制御部
１３ プログラム記憶部
１４ データ記憶部
２１ ユーザ情報
２２ 識別情報
２３ 閲覧情報
２４ 制限情報
２５ 非制限情報
２６ フレンド情報
２７ 承認者情報
２８ 通知情報

Claims (27)

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. 複数のユーザに関する情報を保存し、あるユーザに関する所定の情報を、権限が付与された他のユーザに対して提供するサーバシステムにおいて実行される方法であって、
    前記サーバシステムは、ユーザに関する情報に対する所定の権限が付与された他のユーザとして登録される登録ユーザの識別情報をユーザ毎に記憶装置に記憶しており、
    第１のユーザの端末装置から、第２のユーザに対する登録ユーザとして第１のユーザを登録する旨の申請を受信する申請受信ステップと、
    前記第２のユーザに対して行われた申請を評価する権限を有する評価者として、前記第２のユーザとは別の評価者を特定する評価者特定ステップと、
    前記申請を行った第１のユーザに対する評価に関する問合せを前記評価者の端末装置へ送信し、前記評価者の端末装置から問合せに関する回答を受信する評価問合せステップと、
    前記評価問合せステップにおいて受信された回答に基づいて得られる評価情報と前記申請の承認に関する問合せとを前記第２のユーザの端末装置へ送信し、前記第２のユーザの端末装置から問合せに関する回答を受信する承認回答受信ステップと、
    前記承認問合せステップにおいて受信された回答に基づいて、前記第１のユーザによる申請を承認するか否かの判定を行う承認判定ステップと、
    前記第１のユーザによる申請を承認すると判定された場合、前記第２のユーザに対する登録ユーザとして前記第１のユーザの識別情報を前記記憶部に記憶する記憶制御ステップとを含む、情報処理方法。
    

Images