(58)【調査した分野】(Int.Cl.,DB名)
少なくとも1のユーザについて、そのユーザに対して行われた申請を承認する権限を有する承認者の情報を前記申請の前に予め記憶部に記憶する承認者記憶手段をさらに備え、
前記承認者特定手段は、前記記憶部に記憶されている前記承認者の情報に基づいて承認者を特定する、請求項1から請求項5のいずれか1項に記載のサーバシステム。
前記第1問合せ手段は、前記第2問合せ手段によって受信された回答が申請を承認する旨を示す場合、前記申請の承認に関する問合せを前記承認者の端末装置へ送信し、当該回答が申請を承認しない旨を示す場合、当該問合せを前記承認者の端末装置へ送信せず、
前記承認判定手段は、前記第2のユーザの回答および前記承認者の回答が共に申請を承認する旨を示す場合、前記第1のユーザによる申請を承認すると判定する、請求項7に記載のサーバシステム。
前記第1問合せ手段によって受信された回答が申請を承認する旨を示す場合に、前記第1のユーザから前記第2のユーザに対して申請が行われたことを当該第2のユーザの端末装置へ通知する通知手段をさらに備える、請求項3から請求項5のいずれか1項に記載のサーバシステム。
前記第1問合せ手段が問合せを前記承認者の端末装置へ送信する前に、前記第1のユーザから前記第2のユーザに対して申請が行われたことを当該第2のユーザの端末装置へ通知する通知手段をさらに備える、請求項1、および、請求項3から請求項5のいずれか1項に記載のサーバシステム。
前記第2のユーザの端末装置から前記承認者を設定するか否かに関する情報を受信し、受信した情報に基づいて、前記承認者を設定するか否かを判定する承認者判定手段をさらに備え、
前記承認者特定手段は、前記承認者を設定すると判定された場合に承認者を特定する、請求項1、請求項2、請求項4、および、請求項5のいずれか1項に記載のサーバシステム。
前記申請が前記申請受信手段によって受信された場合、当該申請に関する承認者を選択するための問合せを前記第2のユーザの端末装置へ送信し、前記第2のユーザの端末装置から、選択された承認者を示す情報を受信する承認者問合せ手段をさらに備え、
前記承認者特定手段は、受信された承認者を示す情報に基づいて承認者を特定する、請求項1から請求項3、および、請求項5のいずれか1項に記載のサーバシステム。
前記申請が前記申請受信手段によって受信された場合、前記第1のユーザが申請を行うことを許可する権限を有する申請許可者として、前記第1のユーザとは別の申請許可者を特定する許可者特定手段と、
前記申請受信手段によって前記申請が受信された場合、申請を許可することに関する問合せを前記申請許可者の端末へ送信し、前記申請許可者の端末装置から問合せに関する回答を受信する許可問合せ手段と、
前記許可問合せ手段によって受信された回答が申請を許可する旨を示す場合、前記第1のユーザによる申請を有効とし、前記許可問合せ手段によって受信された回答が申請を許可しない旨を示す場合、前記第1のユーザによる申請を無効とする申請判定手段とを備え、
前記第1問合せ手段は、前記申請が有効とされた場合、前記申請の承認に関する問合せを前記承認者の端末装置へ送信する、請求項1から請求項12のいずれか1項に記載のサーバシステム。
前記第1問合せ手段は、問合せに対する回答を行うためのウェブページにアクセスするためのリンク情報を含む情報を前記承認者の端末装置へ送信し、当該ウェブページ上で前記承認者の端末装置によって行われた回答を取得する、請求項1から請求項13のいずれか1項に記載のサーバシステム。
前記許可問合せ手段は、問合せに関する回答を行うためのウェブページにアクセスするためのリンク情報を含む情報を前記申請許可者の端末装置へ送信し、当該ウェブページ上で前記申請許可者の端末装置によって行われた回答を取得する、請求項13に記載のサーバシステム。
前記第1問合せ手段は、前記申請の承認に関する問合せを前記承認者の端末装置へ送信する場合、前記第1のユーザに関して保存されるプロフィール情報のうちの少なくとも一部の情報または当該プロフィール情報にアクセスするためのリンク情報を当該問合せと共に送信する、請求項1から請求項15のいずれか1項に記載のサーバシステム。
前記承認判定手段は、前記第1問合せ手段による問合せが行われてから所定期間内に当該問合せに対する回答が受信されない場合、当該問合せに対する回答は、前記第1のユーザによる申請を承認しない旨を示すと判定する、請求項1から請求項16のいずれか1項に記載のサーバシステム。
少なくとも1のユーザについて、そのユーザに対して行われた申請を評価する権限を有する評価者識別情報を前記申請の前に予め記憶部に記憶する評価者記憶手段をさらに備え、
前記評価者特定手段は、前記記憶部に記憶されている前記評価者の識別情報に基づいて評価者を特定する、請求項18から請求項20のいずれか1項に記載のサーバシステム。
前記第2のユーザの端末装置から前記評価者を設定するか否かに関する情報を受信し、受信した情報に基づいて、前記評価者を設定するか否かを判定する評価者判定手段をさらに備え、
前記評価者特定手段は、前記評価者を設定すると判定された場合に評価者を特定する、請求項19または請求項20に記載のサーバシステム。
前記申請が前記申請受信手段によって受信された場合、当該申請に関する評価者を選択するための問合せを前記第2のユーザの端末装置へ送信し、前記第2のユーザの端末装置から、選択された評価者を示す情報を受信する評価者問合せ手段をさらに備え、
前記評価者特定手段は、受信された評価者を示す情報に基づいて評価者を特定する、請求項18または請求項20に記載のサーバシステム。
前記申請が前記申請受信手段によって受信された場合、前記第1のユーザが申請を行うことを許可する権限を有する申請許可者として、前記第1のユーザとは別の申請許可者を特定する許可者特定手段と、
前記申請受信手段によって前記申請が受信された場合、申請を許可することに関する問合せを前記申請許可者の端末へ送信し、前記申請許可者の端末から問合せに関する回答を受信する許可問合せ手段と、
前記許可問合せ手段によって受信された回答が申請を許可する旨を示す場合、前記第1のユーザによる申請を有効とし、前記許可問合せ手段によって受信された回答が申請を許可しない旨を示す場合、前記第1のユーザによる申請を無効とする申請判定手段とを備え、
前記評価問合せ手段は、前記申請が有効とされた場合、前記申請の承認に関する問合せを前記評価者の端末装置へ送信する、請求項18から請求項23のいずれか1項に記載のサーバシステム。
前記評価問合せ手段は、前記申請を行った第1のユーザに対する評価に関する問合せを前記評価者の端末装置へ送信する場合、前記第1のユーザに関して保存されるプロフィール情報のうちの少なくとも一部の情報または当該プロフィール情報にアクセスするためのリンク情報を当該問合せと共に送信する、請求項18から請求項24のいずれか1項に記載のサーバシステム。
前記第2のユーザに関する情報に対する前記所定の権限は、当該第2のユーザに関する情報であって、登録ユーザでない他のユーザが閲覧不可能な情報を閲覧する権限である、請求項1から26のいずれか1項に記載のサーバシステム。
複数のユーザに関する情報を保存し、あるユーザに関する所定の情報を他のユーザに対して提供するサーバシステムのコンピュータにおいて実行される情報処理プログラムであって、
ユーザに関する情報を閲覧する権限が付与された他のユーザとして登録される登録ユーザの識別情報をユーザ毎に前記サーバシステムの記憶部に記憶する登録記憶手段と、
第1のユーザの端末装置から、第2のユーザに対する登録ユーザとして第1のユーザを登録する旨の申請を受信する申請受信手段と、
前記第2のユーザに対して行われた申請を承認する権限を有する承認者として、前記第2のユーザとは別の承認者を特定する承認者特定手段と、
前記申請の承認に関する問合せを前記承認者の端末装置へ送信し、前記承認者の端末装置から問合せに関する回答を受信する第1問合せ手段と、
受信された回答に基づいて、前記第1のユーザによる申請を承認するか否かの判定を行う承認判定手段として前記コンピュータを機能させ、
前記登録記憶手段は、前記承認判定手段によって前記第1のユーザによる申請を承認すると判定された場合、前記第2のユーザに対する登録ユーザとして前記第1のユーザの識別情報を前記記憶部に記憶し、
前記情報処理プログラムは、前記申請の承認に関する問合せを前記第2のユーザの端末装置へ送信し、前記第2のユーザの端末装置から問合せに関する回答を受信する第2問合せ手段として前記コンピュータをさらに機能させ、
前記承認判定手段は、前記承認者の回答と前記第2のユーザの回答とに基づいて判定を行い、
前記第1問合せ手段は、前記第2問合せ手段によって受信された回答が申請を承認する旨を示す場合、前記申請の承認に関する問合せを前記承認者の端末装置へ送信し、当該回答が申請を承認しない旨を示す場合、当該問合せを前記承認者の端末装置へ送信せず、
前記承認判定手段は、前記第2のユーザの回答および前記承認者の回答が共に申請を承認する旨を示す場合、前記第1のユーザによる申請を承認すると判定する、情報処理プログラム。
複数のユーザに関する情報を保存し、あるユーザに関する所定の情報を、権限が付与された他のユーザに対して提供するサーバシステムのコンピュータにおいて実行される情報処理プログラムであって、
ユーザに関する情報に対する所定の権限が付与された他のユーザとして登録される登録ユーザの識別情報をユーザ毎に前記サーバシステムの記憶部に記憶する登録記憶手段と、
第1のユーザの端末装置から、第2のユーザに対する登録ユーザとして第1のユーザを登録する旨の申請を受信する申請受信手段と、
前記第2のユーザに対して行われた申請を評価する権限を有する評価者として、前記第2のユーザとは別の評価者を特定する評価者特定手段と、
前記申請を行った第1のユーザに対する評価に関する問合せを前記評価者の端末装置へ送信し、前記評価者の端末装置から問合せに関する回答を受信する評価問合せ手段と、
前記評価問合せ手段によって受信された回答に基づいて得られる評価情報と前記申請の承認に関する問合せとを前記第2のユーザの端末装置へ送信し、前記第2のユーザの端末装置から問合せに関する回答を受信する承認問合せ手段と、
前記承認問合せ手段によって受信された回答に基づいて、前記第1のユーザによる申請を承認するか否かの判定を行う承認判定手段として前記コンピュータを機能させ、
前記登録記憶手段は、前記第1のユーザによる申請を承認すると判定された場合、前記第2のユーザに対する登録ユーザとして前記第1のユーザの識別情報を前記記憶部に記憶し、
前記情報処理プログラムは、前記第2のユーザの端末装置から前記評価者を設定するか否かに関する情報を受信し、受信した情報に基づいて、前記評価者を設定するか否かを判定する評価者判定手段として前記コンピュータをさらに機能させ、
前記評価者特定手段は、前記評価者を設定すると判定された場合に評価者を特定する、情報処理プログラム。
【発明の概要】
【発明が解決しようとする課題】
【0004】
SNSまたは同種のサービスにおいては、現実世界では知人でない他のユーザからフレンド申請があった場合に、申請を承認するか否かの判断がユーザにとって難しいことがある。
【0005】
それ故、本発明の目的は、他のユーザからの申請を承認するか否かの判断によるユーザの負担を軽減することができるサーバシステム、サーバ装置、情報処理プログラム、およびサーバシステムにおける情報処理方法を提供することである。
【課題を解決するための手段】
【0006】
上記の課題を解決すべく、本発明は、以下の(1)〜(21)の構成を採用した。
【0007】
(1)
本発明の一例は、複数のユーザに関する情報を保存し、あるユーザに関する所定の情報を他のユーザに対して提供するサーバシステムである。サーバシステムは、登録記憶手段と、申請受信手段と、承認者特定手段と、第1問合せ手段と、承認判定手段とを備える。
登録記憶手段は、ユーザに関する情報に対する所定の権限が付与された他のユーザとして登録される登録ユーザの識別情報をユーザ毎に記憶部に記憶する。申請受信手段は、第1のユーザの端末装置から、第2のユーザに対する登録ユーザとして第1のユーザを登録する旨の申請を受信する。承認者特定手段は、第2のユーザに対して行われた申請を承認する権限を有する承認者として、第2のユーザとは別の承認者を特定する。第1問合せ手段は、申請の承認に関する問合せを承認者の端末装置へ送信し、承認者の端末装置から問合せに関する回答を受信する。承認判定手段は、受信された回答に基づいて、第1のユーザによる申請を承認するか否かの判定を行う。
登録記憶手段は、承認判定手段によって第1のユーザによる申請を承認すると判定された場合、第2のユーザに対する登録ユーザとして第1のユーザの識別情報を記憶部に記憶する。
【0008】
上記(1)の構成によれば、第2のユーザは、自身に対する申請に関する承認を承認者に依頼することができるので、申請を承認するか否かの判断による第2のユーザの負担を軽減することができる。
【0009】
(2)
サーバシステムは、少なくとも1のユーザについて、そのユーザに対して行われた申請を承認する権限を有する承認者の情報を申請の前に予め記憶部に記憶する承認者記憶手段をさらに備えていてもよい。承認者特定手段は、記憶部に記憶されている承認者の情報に基づいて承認者を特定してもよい。
【0010】
上記(2)の構成によれば、第2のユーザは、申請の度に承認者を選択する必要が無いので、承認者の設定が容易になる。
【0011】
(3)
サーバシステムは、申請の承認に関する問合せを第2のユーザの端末装置へ送信し、第2のユーザの端末装置から問合せに関する回答を受信する第2問合せ手段をさらに備えていてもよい。承認判定手段は、承認者の回答と第2のユーザの回答とに基づいて判定を行ってもよい。
【0012】
上記(3)の構成によれば、第2のユーザ自身が承認するか否かの判断を行えるとともに、承認者による承認にも基づいて承認するか否かが判定されるので、第2のユーザの判断負担を軽減することができる。
【0013】
(4)
第1問合せ手段は、第2問合せ手段によって受信された回答が申請を承認する旨を示す場合、申請の承認に関する問合せを承認者の端末装置へ送信し、当該回答が申請を承認しない旨を示す場合、当該問合せを承認者の端末装置へ送信しないようにしてもよい。承認判定手段は、第2のユーザの回答および承認者の回答が共に申請を承認する旨を示す場合、第1のユーザによる申請を承認すると判定してもよい。
【0014】
上記(4)の構成によれば、第2のユーザが承認しない場合には承認者には問合せが行われないので、承認者は、必要がない場合には問合せに対する回答を行わなくてもよい。これによって、承認者の作業負担を軽減することができる。
【0015】
(5)
サーバシステムは、第1問合せ手段によって受信された回答が申請を承認する旨を示す場合に、第1のユーザから第2のユーザに対して申請が行われたことを当該第2のユーザの端末装置へ通知する通知手段をさらに備えていてもよい。
【0016】
上記(5)の構成によれば、承認者によって承認されなかった申請については第2のユーザに対する通知が行われないので、第2のユーザの確認の手間を省くことができる。
【0017】
(6)
サーバシステムは、第1問合せ手段が問合せを承認者の端末装置へ送信する前に、第1のユーザから第2のユーザに対して申請が行われたことを当該第2のユーザの端末装置へ通知する通知手段をさらに備えていてもよい。
【0018】
上記(6)の構成によれば、承認者が承認を行う場合であっても、申請があったことを第2のユーザへ事前に通知することができる。
【0019】
(7)
サーバシステムは、第2のユーザの端末装置から承認者を設定するか否かに関する情報を受信し、受信した情報に基づいて、承認者を設定するか否かを判定する承認者判定手段をさらに備えていてもよい。承認者特定手段は、承認者を設定すると判定された場合に承認者を特定してもよい。
【0020】
上記(7)の構成によれば、承認者を設定するか否かを第2のユーザに選択させるので、第2のユーザは、申請の承認の判断を自身で行うこともできるし、他の者に承認を依頼することもできる。これによって、第2のユーザの承認判断による負担を軽減することができるとともに、(承認の依頼を不要と判断した場合には)第1のユーザを容易に登録ユーザとすることができる。
【0021】
(8)
サーバシステムは、申請が申請受信手段によって受信された場合、当該申請に関する承認者を選択するための問合せを第2のユーザの端末装置へ送信し、第2のユーザの端末装置から、選択された承認者を示す情報を受信する承認者問合せ手段をさらに備えていてもよい。承認者特定手段は、受信された承認者を示す情報に基づいて承認者を特定してもよい。
【0022】
上記(8)の構成によれば、第2のユーザは申請毎に承認者を設定することができるので、申請に応じた適切な承認者を選択することができる。
【0023】
(9)
サーバシステムは、許可者特定手段と、許可問合せ手段と、申請判定手段とをさらに備えていてもよい。許可者特定手段は、申請が申請受信手段によって受信された場合、第1のユーザが申請を行うことを許可する権限を有する申請許可者として、第1のユーザとは別の申請許可者を特定する。許可問合せ手段は、申請受信手段によって申請が受信された場合、申請を許可することに関する問合せを申請許可者の端末へ送信し、申請許可者の端末装置から問合せに関する回答を受信する。申請判定手段は、許可問合せ手段によって受信された回答が申請を許可する旨を示す場合、第1のユーザによる申請を有効とし、許可問合せ手段によって受信された回答が申請を許可しない旨を示す場合、第1のユーザによる申請を無効とする。このとき、第1問合せ手段は、申請が有効とされた場合、申請の承認に関する問合せを承認者の端末装置へ送信してもよい。
【0024】
上記(9)の構成によれば、第1のユーザが申請を行うことを他の申請許可者によって制限することができる。これによって、第1のユーザが、正当であることが疑わしいユーザに対して申請を行ってしまうことを防止することができる。
【0025】
(10)
第1問合せ手段は、問合せに対する回答を行うためのウェブページにアクセスするためのリンク情報を含む情報を承認者の端末装置へ送信し、当該ウェブページ上で承認者の端末装置によって行われた回答を取得してもよい。
【0026】
上記(10)の構成によれば、サーバシステムが付与するアカウントを持たない者を承認者にすることができる。また、アカウントが付与されない承認者は、アカウントを取得するための登録作業を承認のために行う必要がないので、承認者の手間を省くことができる。
【0027】
(11)
許可問合せ手段は、問合せに関する回答を行うためのウェブページにアクセスするためのリンク情報を含む情報を申請許可者の端末装置へ送信し、当該ウェブページ上で申請許可者の端末装置によって行われた回答を取得してもよい。
【0028】
上記(11)の構成によれば、サーバシステムが付与するアカウントを持たない者を申請許可者にすることができる。また、アカウントが付与されない申請許可者は、アカウントを取得するための登録作業を申請の許可のために行う必要がないので、申請許可者の手間を省くことができる。
【0029】
(12)
第1問合せ手段は、申請の承認に関する問合せを承認者の端末装置へ送信する場合、第1のユーザに関して保存されるプロフィール情報のうちの少なくとも一部の情報または当該プロフィール情報にアクセスするためのリンク情報を当該問合せと共に送信してもよい。
【0030】
上記(12)の構成によれば、承認者は、プロフィールの情報を参照することで、承認するか否かの判断を行いやすくなる。
【0031】
(13)
承認判定手段は、第1問合せ手段による問合せが行われてから所定期間内に当該問合せに対する回答が受信されない場合、当該問合せに対する回答は、第1のユーザによる申請を承認しない旨を示すと判定してもよい。
【0032】
上記(13)の構成によれば、サーバシステムは、承認者からの回答が受信されない場合でも、申請を承認するか否かの判定を実行することができる。
【0033】
(14)
本発明の他の一例は、複数のユーザに関する情報を保存し、あるユーザに関する所定の情報を他のユーザに対して提供するサーバシステムである。サーバシステムは、登録記憶手段と、申請受信手段と、評価者特定手段と、評価問合せ手段と、承認問合せ手段と、承認判定手段とを備える。
登録記憶手段は、ユーザに関する情報に対する所定の権限が付与された他のユーザとして登録される登録ユーザの識別情報をユーザ毎に記憶部に記憶する。申請受信手段は、第1のユーザの端末装置から、第2のユーザに対する登録ユーザとして第1のユーザを登録する旨の申請を受信する。評価者特定手段は、第2のユーザに対して行われた申請を評価する権限を有する評価者として、第2のユーザとは別の評価者を特定する。評価問合せ手段は、申請を行った第1のユーザに対する評価に関する問合せを評価者の端末装置へ送信し、評価者の端末装置から問合せに関する回答を受信する。承認問合せ手段は、評価問合せ手段によって受信された回答に基づいて得られる評価情報と申請の承認に関する問合せとを第2のユーザの端末装置へ送信し、第2のユーザの端末装置から問合せに関する回答を受信する。承認判定手段は、承認問合せ手段によって受信された回答に基づいて、第1のユーザによる申請を承認するか否かの判定を行う。また、登録記憶手段は、第1のユーザによる申請を承認すると判定された場合、第2のユーザに対する登録ユーザとして第1のユーザの識別情報を記憶装置に記憶する。
【0034】
なお、上記において、サーバシステムは、評価情報と問合せとを第2のユーザの端末装置へ同時に送信してもよいし、別々に送信してもよい。
【0035】
上記(14)の構成によれば、第2のユーザは、自身に対する申請に関する評価を評価者(評価ユーザ)に依頼することができ、評価者による評価を参考に、申請を承認するか否かを判断することができる。これによって、申請を承認するか否かの判断による第2のユーザの負担を軽減することができる。
【0036】
(15)
サーバシステムは、少なくとも1のユーザについて、そのユーザに対して行われた申請を評価する権限を有する評価者識別情報を申請の前に予め記憶部に記憶する評価者記憶手段をさらに備えていてもよい。評価者特定手段は、記憶部に記憶されている評価者の識別情報に基づいて評価者を特定してもよい。
【0037】
上記(15)の構成によれば、第2のユーザは、申請の度に評価ユーザを選択する必要が無いので、評価ユーザの設定が容易になる。
【0038】
(16)
サーバシステムは、第2のユーザの端末装置から評価ユーザを設定するか否かに関する情報を受信し、受信した情報に基づいて、評価者を設定するか否かを判定する評価者判定手段をさらに備えていてもよい。評価者特定手段は、評価者を設定すると判定された場合に評価者を特定してもよい。
【0039】
上記(16)の構成によれば、第2のユーザの承認判断による負担を軽減することができるとともに、(評価の依頼を不要と判断した場合には)第1のユーザを容易に登録ユーザとすることができる。
【0040】
(17)
サーバシステムは、申請が申請受信手段によって受信された場合、当該申請に関する評価者を選択するための問合せを第2のユーザの端末装置へ送信し、第2のユーザの端末装置から、選択された評価者を示す情報を受信する評価者問合せ手段をさらに備えていてもよい。評価者特定手段は、受信された評価者を示す情報に基づいて評価者を特定してもよい。
【0041】
上記(17)の構成によれば、第2のユーザは申請毎に評価ユーザを設定することができ、申請を行った第1のユーザに応じた適切な評価ユーザを選択することができる。
【0042】
(18)
サーバシステムは、許可者特定手段と、許可問合せ手段と、申請判定手段とを備えていてもよい。許可者特定手段は、申請が申請受信手段によって受信された場合、第1のユーザが申請を行うことを許可する権限を有する申請許可者として、第1のユーザとは別の申請許可者を特定する。許可問合せ手段は、申請受信手段によって申請が受信された場合、申請を許可することに関する問合せを申請許可者の端末へ送信し、申請許可者の端末から問合せに関する回答を受信する。申請判定手段は、許可問合せ手段によって受信された回答が申請を許可する旨を示す場合、第1のユーザによる申請を有効とし、許可問合せ手段によって受信された回答が申請を許可しない旨を示す場合、第1のユーザによる申請を無効とする。このとき、評価問合せ手段は、申請が有効とされた場合、申請の承認に関する問合せを評価者の端末装置へ送信してもよい。
【0043】
上記(18)の構成によれば、第1のユーザが申請を行うことを他の申請許可者によって制限することができる。これによって、第1のユーザが、正当であることが疑わしいユーザに対して申請を行ってしまうことを防止することができる。
【0044】
(19)
評価問合せ手段は、申請を行った第1のユーザに対する評価に関する問合せを評価ユーザの端末装置へ送信する場合、第1のユーザに関して保存されるプロフィール情報のうちの少なくとも一部の情報または当該プロフィール情報にアクセスするためのリンク情報を当該問合せと共に送信してもよい。
【0045】
上記(19)の構成によれば、評価ユーザは、プロフィールの情報を参照することで評価を行いやすくなる。
【0046】
(20)
評価ユーザ特定手段は、複数の評価者を特定してもよい。評価問合せ手段は、特定された複数の評価者それぞれの端末装置へ問合せを送信するとともに、各端末装置から回答を受信してもよい。承認問合せ手段は、受信された各回答から、評価の指標を示すパラメータを算出し、算出されたパラメータと申請の承認に関する問合せを第2のユーザの端末装置へ送信してもよい。
【0047】
上記(20)の構成によれば、複数の評価ユーザが設定される場合に、評価結果をわかりやすく第2のユーザに提示することができる。これによって、第2のユーザは、承認するか否かの判断を行いやすくなる。
【0048】
(21)
第2ユーザに関する情報に対する所定の権限は、当該第2ユーザに関する情報であって、登録ユーザでない他のユーザが閲覧不可能な情報を閲覧する権限であってもよい。
【0049】
上記(21)の構成によれば、登録ユーザでないユーザでは閲覧することができない情報を登録ユーザが閲覧することができるSNSを提供するサーバシステムにおいて、申請を承認するか否かの判断によるユーザの負担を軽減することができる。
【0050】
なお、本発明の別の一例は、上記(1)〜(21)のサーバシステムを含む情報処理システムであってもよいし、上記(1)〜(21)のサーバシステムにおける各手段と同等の手段として情報処理装置のコンピュータを機能させる情報処理プログラムであってもよい。また、本発明の別の一例は、上記(1)〜(21)のサーバシステムにおいて実行される、情報処理方法(ユーザの登録方法)であってもよい。
【発明の効果】
【0051】
本発明によれば、他のユーザからの申請を承認するか否かの判断によるユーザの負担を軽減することができる。
【発明を実施するための形態】
【0053】
以下、本実施形態に係るサーバシステム(サーバ装置)、情報処理システム、情報処理プログラム、および情報処理方法の一例として、いくつかの実施形態および変形例について説明する。
【0054】
<第1の実施形態>
[1.第1の実施形態における情報処理システムの構成]
以下、第1の実施形態に係るサーバシステム、情報処理システム、情報処理プログラム、および、サーバシステムで実行される情報処理方法について説明する。
図1は、第1の実施形態における情報処理システムの一例の構成を示すブロック図である。
図1に示すように、情報処理システム1は、サーバ(サーバシステム)2と、複数の端末装置3と、ネットワーク4とを含む。サーバ2は、ネットワーク4を介して端末装置3と通信可能である。
【0055】
図1において、サーバ2は、SNSを提供するサーバである。すなわち、サーバ2は、サーバ2に対してアクセスする端末装置3に対して、SNSのウェブサイトを提供する。サーバ2が提供するSNSの内容は任意であるが、本実施形態においては、サーバ2は、SNSのユーザに関する情報(プロフィールや日記や写真等)を保存し、保存している情報を他のユーザに対して閲覧可能に提供する。なお、SNSにおいては、他のユーザが情報を閲覧できる機能に限らず、例えば、ユーザ間でメッセージを送ったり、特定のユーザ間で利用可能な掲示板にメッセージを書き込んだりする機能が提供されてもよい。
【0056】
サーバ2は、1以上の情報処理装置(サーバ装置)で構成される。本明細書では、「サーバ」とは、1つの情報処理装置(サーバ装置)を指す他、サーバが複数のサーバ装置によって構成される場合にはサーバ装置群(サーバシステム)全体を指す意味である。
【0057】
端末装置3は、サーバ2が提供するSNSを利用する各ユーザによって操作される情報処理装置の一例である。端末装置3は、パーソナルコンピュータ、携帯端末、スマートフォン、ゲーム装置等、ネットワーク4を介してサーバ2と通信可能な任意の形態の情報処理装置であってよい。なお、ネットワーク4は、例えばインターネット等であるが、任意のネットワークでよい。
【0058】
サーバ2は、各種の情報処理を実行する制御部12を備える。また、サーバ2は、サーバ2において実行される情報処理プログラムを記憶するプログラム記憶部13を備える。制御部12は、CPU(Central Processing Unit)およびメモリを有し、CPUがメモリを用いて、上記情報処理プログラムを実行することによって上記各種の情報処理が実行される。また、サーバ2は、ネットワーク4を介して端末装置3とデータの送受信を行う通信部11を備える。通信部11は、制御部12の指示により、上記情報処理の実行に応じた適宜のタイミングで端末装置3との間でデータの送受信を行う。
【0059】
また、サーバ2は、SNSを提供するための各種のデータが記憶されるデータ記憶部14を備える。なお、各記憶部13および14は、サーバ2が備える任意の記憶装置(記憶媒体)である。データ記憶部14には、上記各種のデータの1つとして、SNSのユーザに関する情報(ユーザ情報)が記憶される。
【0060】
図2は、ユーザ情報の一例を示す図である。なお、
図2においては、1人のユーザに関して記憶(保存)される情報を示している。つまり、データ記憶部14には、
図2に示すユーザ情報21が、SNSのユーザ毎に記憶されている。
【0061】
図2に示すように、ユーザ情報21には識別情報22が含まれる。識別情報22は、例えば、ユーザ(ユーザに付与されたアカウント)のIDや名前等である。識別情報22には、ユーザがSNSのウェブサイトにログインするために必要となるパスワードが含まれていてもよい。
【0062】
また、ユーザ情報21には、SNSのウェブサイトにおいて閲覧されるための閲覧情報23が含まれる。ここで、本実施形態においては、ユーザに対して他のユーザをフレンド登録することができ、当該ユーザの閲覧情報のうち所定の情報については、フレンド登録された他のユーザが閲覧することができ、フレンド登録されていない他のユーザは閲覧することができない。つまり、フレンド登録されたユーザとは、上記所定の情報を閲覧する権限が付与されたユーザである。
【0063】
具体的には、閲覧情報23は、制限情報24と非制限情報25とを含む(つまり、閲覧情報23は、制限情報24と非制限情報25とに分けることができる)。制限情報24は、フレンド登録されたユーザのみが閲覧可能な(フレンド登録されていないユーザは閲覧不可能な)情報である。また、非制限情報25は、(フレンド登録されているか否かにかかわらず)任意のユーザが閲覧可能な情報である。例えば、名前や趣味等の簡単なプロフィール情報は非制限情報25として保存され、日記や家族の写真等、不特定のユーザには見られたくない情報は制限情報24として保存されてもよい。
【0064】
なお、閲覧情報に含まれる各情報が制限情報24に設定されるか非制限情報25に設定されるかは、ユーザが個別に設定できるようにしてもよい。また、例えば、ユーザの名前は非制限情報25として設定される等、制限情報24に設定されるか非制限情報25に設定されるかは情報の種類(項目)毎に予め設定されていてもよい。
【0065】
ユーザ情報21には、フレンド情報26が含まれる。フレンド情報26は、ユーザ情報21に対応するユーザに対してフレンド登録されている他のユーザの識別情報を示す。つまり、フレンド情報26によって示される他のユーザは、制限情報24を閲覧可能である。詳細は後述するが、本実施形態においては、ユーザは、他のユーザに対してフレンド申請(友達申請)を行うことができ、申請が承認された場合、当該他のユーザに対して申請を行ったユーザがフレンド登録される。
【0066】
ユーザ情報21には、承認者情報27が含まれる。ここで、詳細は後述するが、本実施形態においては、あるユーザからフレンド申請があった場合、ユーザは、他のユーザ(例えば保護者や友人)に承認を依頼する(承認を代理してもらう)ことができる。承認者情報27は、ユーザに対するフレンド申請を承認する権限を有する他のユーザ(「承認ユーザ」と呼ぶ)の識別情報を示す。承認者情報27は、ユーザが承認を他のユーザに依頼する場合に設定される。つまり、ユーザ情報21内に承認者情報27が設定される場合、ユーザ情報21に対応するユーザに対するフレンド申請は、承認者情報27により示される承認ユーザによって承認が行われる(詳細は後述する)。
【0067】
ユーザ情報21には、通知情報28が含まれる。通知情報28は、サーバ2からユーザに対する通知(問合せ等を含む)の有無を示し、通知がある場合には、当該通知において送信すべき情報(「送信情報」と呼ぶ)を含む。詳細は後述するが、例えば、あるユーザに対してフレンド申請があった場合、サーバ2は、当該あるユーザのユーザ情報21の通知情報28として、フレンド申請があった旨の通知を示す情報と、通知の際に当該あるユーザの端末装置3へ送信する送信情報(例えば、フレンド申請を行ったユーザのプロフィール情報等)とを記憶する。なお、上記通知および送信情報は、当該あるユーザの端末装置3が次にサーバ2にアクセスしてSNSのウェブサイトにログインしたことに応じて、当該端末装置3へ送信される。
【0068】
[2.情報処理システムにおいて実行される処理の概要]
以下、
図3〜
図5を参照して、第1の実施形態における情報処理システム1において実行されるフレンド登録処理の概要について説明する。
図3は、フレンド登録が行われる場合における動作の流れを大略的に示す図である。以下では、
図3に示すように、あるユーザ(「申請ユーザ」と呼ぶ)が他のユーザ(「被申請ユーザ」と呼ぶ)に対してフレンド申請を行い(
図3に示す(1))、被申請ユーザが承認ユーザに承認を依頼し(
図3に示す(2))、承認ユーザが承認/不承認を行う(
図3に示す(3))場合における、情報処理システム1における処理について説明する。
【0069】
なお、第1の実施形態では、被申請ユーザに対して承認ユーザが予め定められているものとし、サーバ2が記憶する被申請ユーザのユーザ情報21には、承認ユーザを示す承認者情報27が含まれているものとする。なお、一例としては、被申請ユーザが子供であり、その親(保護者)が承認ユーザとして予め登録されている場合が考えられる。つまり、第1の実施形態は、子供に対して知らない他人からフレンド申請があった場合に、親が承認を行うような状況において用いられることが考えられる。
【0070】
また、以下では、申請ユーザがSNSを利用するために用いる端末装置3を、申請端末3aと呼び、被申請ユーザがSNSを利用するために用いる端末装置3を、被申請端末3bと呼び、承認ユーザがSNSを利用するために用いる端末装置3を、承認端末3cと呼ぶ。第1の実施形態では、各端末3a〜3cはそれぞれ別の端末装置であるとするが、ユーザがサーバ2へアクセスするために用いる端末装置は任意であり、例えば、被申請端末3bと承認端末3cとして同じ(1つの)端末装置が用いられてもよい。
【0071】
図4は、第1の実施形態におけるフレンド登録処理の流れを示すタイミングチャートである。まず、申請ユーザは、申請端末3aを用いてSNSにおけるフレンド申請の入力を行う(ステップS1)。すなわち、申請端末3aは、SNSのウェブサイト内における、フレンド申請を行うためのウェブページを表示装置に表示し、フレンド申請のための入力を申請ユーザから受け付ける。申請ユーザは、被申請ユーザを特定可能な情報(名前、識別情報等)を入力する。このとき、被申請ユーザへのメッセージが入力されてもよい。また、サーバ2は、申請ユーザによって入力された検索条件に基づいてユーザの検索を行い、検索結果が申請端末3aにおいて提示されてもよい。このとき、申請ユーザは、検索結果として提示されたユーザから被申請ユーザを選択してもよい。
【0072】
フレンド申請のための情報が入力されると、申請端末3aは、サーバ2へフレンド申請を行い、サーバ2は、フレンド申請を受け付ける(ステップS2)。具体的には、申請端末3aは、フレンド申請のために入力された情報と、申請ユーザの識別情報とを含む申請情報をサーバ2へ送信する。
【0073】
申請端末3aからの申請情報を受信すると、サーバ2は、フレンド申請の申請先である被申請ユーザを特定する(ステップS3)。すなわち、サーバ2は、上記申請情報に含まれる、被申請ユーザを特定可能な情報に基づいて、被申請ユーザを特定する。
【0074】
ここで、第1の実施形態においては、フレンド申請があった場合、サーバ2はまず被申請ユーザに対して、フレンド申請を承認するか否かを問い合わせる。そして、被申請ユーザがフレンド申請を承認しないと回答した場合には、サーバ2はフレンド申請が承認されなかったと判断する。一方、被申請ユーザがフレンド申請を承認すると回答した場合には、サーバ2は、被申請ユーザの承認ユーザに対してさらに、フレンド申請を承認するか否かを問い合わせる。なお、他の実施形態においては、被申請ユーザおよび承認ユーザに問合せを送信するタイミングは任意であり、サーバ2は、承認ユーザに対して被申請ユーザよりも先に問合せを行ってもよい。また、サーバ2は、被申請ユーザおよび承認ユーザに対して同時に問合せを行ってもよい。
【0075】
具体的には、上記ステップS3において被申請ユーザを特定した場合、サーバ2は、被申請ユーザの端末である被申請端末3bへ、フレンド申請に対する問合せを行う(ステップS4)。この問合せでは、被申請ユーザが申請を承認するか否かの問い合わせが行われる。
【0076】
ここで、サーバ2からユーザへの通知(問合せを含む)は、通知が発生した時点でまず、通知に関する通知情報28がサーバ2に記憶され、その後、ユーザの端末装置3がSNSを利用した(SNSにログインした)ことに応じて、通知情報28に含まれる送信情報がサーバ2から端末装置3へ送信されることによって行われる。すなわち、上記ステップS4においては、サーバ2は、まず、問合せを行う旨を示す情報と、問合せ時に送信する送信情報とを、被申請ユーザのユーザ情報21における通知情報28として記憶しておく。そして、被申請ユーザが被申請端末3bを用いてサーバ2にアクセスし、SNSにログインした場合、サーバ2は、被申請ユーザのユーザ情報21に含まれる通知情報28を参照し、被申請ユーザに対する通知(問合せ)の有無を判定する。通知があると判定した場合、サーバ2は、通知情報28に含まれる送信情報を被申請端末3bへ送信する。なお、他の実施形態においては、サーバ2から端末装置3への通知が発生した場合、サーバ2は、通知が発生したことを電子メール等によって(ユーザがSNSにログインする前に)通知するようにしてもよい。
【0077】
上記ステップS4では、送信情報として、被申請端末3bにおいて問合せ画面を表示するための情報が送信される。具体的には、この送信情報は、申請ユーザの名前(アカウント名)と、閲覧情報の一部であるプロフィール情報を含む。また、被申請ユーザに承認ユーザが設定されている場合には、送信情報は承認ユーザの名前(アカウント名)を含む。被申請端末3bにおいてサーバ2からの送信情報が受信されると、被申請端末3bは、上記問合せ画面を表示装置に表示する。
【0078】
図5は、被申請端末3bにおいて表示される問合せ画面の一例を示す図である。
図5に示すように、問合せ画面には、申請ユーザからフレンド申請があったことを示すメッセージ31、フレンド申請を承認するか否かを被申請ユーザが回答するための画像(ボタン画像32および33)、および、申請ユーザのプロフィール35が含まれる。また、本実施形態においては、問合せ画面には、被申請ユーザが承認する旨の回答を行った場合には承認ユーザに承認の依頼が行われる旨を通知するメッセージ34が含まれる。
【0079】
なお、他の実施形態においては、上記ステップS4において、サーバ2は、申請ユーザのユーザ情報21に基づいて、申請ユーザの登録済みのフレンドであるユーザを特定し、特定したユーザの情報(名前等)を被申請端末3bに送信してもよい。このとき、被申請端末3bには、プロフィールに代えて(またはプロフィールとともに)申請ユーザの登録済みのフレンドであるユーザの情報が表示されてもよい。被申請ユーザは、申請ユーザの登録済みフレンドを知ることによって、申請ユーザが信頼できるか否かを判断することができる。例えば、申請ユーザの登録済みフレンドに被申請ユーザの知人(フレンド)がいる場合には、申請ユーザが信頼できると判断することができる。また、申請ユーザが被申請ユーザの知人であるにもかかわらず、申請ユーザの登録済みフレンドに被申請ユーザの知人(フレンド)が全くいない場合には、申請ユーザはなりすましによる別人であることを疑うことができ、信頼できないと判断することができる。
【0080】
被申請端末3bにおいて上記問合せ画面が表示された場合、被申請ユーザは、問合せ画面に対して入力を行うことによって、フレンド申請を承認するか否かの回答を入力する(ステップS5)。例えば、被申請ユーザが、タッチパネルやマウス等の入力装置を用いて、「承認する」を表すボタン画像32または「承認しない」を表すボタン画像33のいずれかを指定することで、承認するか否かの回答が行われる。入力が行われたことに応じて、被申請端末3bは、回答結果(承認または不承認)を示す情報をサーバ2へ送信する(ステップS6)。回答には、被申請ユーザの識別情報と、フレンド申請の承認または不承認を示す回答結果の情報とが含まれる。
【0081】
サーバ2は、被申請端末3bから送信されてくる被申請ユーザの回答を受信する。受信された被申請ユーザの回答が承認を示す場合、サーバ2は、被申請ユーザの承認ユーザを特定する(ステップS7)。承認ユーザの特定は、被申請ユーザのユーザ情報21の承認者情報27を参照することによって行うことができる。次に、サーバ2は、承認ユーザの端末である承認端末3cへフレンド申請に対する問合せを行う(ステップS8)。この問合せでは、上記ステップS4における問合せ処理と同様、承認ユーザが申請を承認するか否かの問合せが行われる。具体的には、上記ステップS4と同様、サーバ2は、問合せに関する通知情報28を承認ユーザのユーザ情報21に含めて記憶しておき、その後、承認ユーザがSNSを利用した(SNSにログインした)ことに応じて、通知情報28に含まれる送信情報がサーバ2から承認端末3cへ送信される。なお、送信情報の内容は、ステップS4における送信情報と同様の問合せ画面を表示するための情報でよい。
【0082】
承認端末3cにおいてサーバ2からの送信情報が受信されると、承認端末3cは、上記問合せ画面を表示装置に表示し、承認ユーザからの回答の入力を受け付ける。このとき、問合せ画面には申請ユーザのプロフィールが表示されるので、承認ユーザは、申請ユーザに関する情報を得ることができ、承認するか否かの判断に役立てることができる。承認端末3cにおいて上記問合せ画面が表示された場合、承認ユーザは、問合せ画面に対して入力を行うことによって、フレンド申請を承認するか否かの回答を入力する(ステップS9)。入力が行われたことに応じて、承認端末3cは、回答結果(承認または不承認)を示す情報をサーバ2へ送信する(ステップS10)。回答には、フレンド申請の承認または不承認を示す回答結果の情報が含まれる。
【0083】
サーバ2は、承認端末3cから送信されてくる回答を受信し、フレンド申請を承認するか否かの判定を回答に基づいて行う(ステップS11)。このとき、フレンド申請を承認すると判定した場合、サーバ2は、申請ユーザを被申請ユーザのフレンドとして登録する(ステップS12)。具体的には、申請ユーザのユーザ情報21内のフレンド情報26を、被申請ユーザの識別情報を含むように更新するとともに、被申請ユーザのユーザ情報21内のフレンド情報26を、申請ユーザの識別情報を含むように更新する。
【0084】
さらに、サーバ2は、判定結果を申請ユーザおよび被申請ユーザへ通知する(ステップS13)。この通知も上記ステップS4およびS8の問合せと同様、通知情報28を用いて行われる。すなわち、サーバ2は、通知に関する通知情報28を申請ユーザおよび被申請ユーザのユーザ情報21に含めて記憶しておき、その後、申請ユーザまたは被申請ユーザがSNSにログインしたことに応じて、通知情報28に含まれる送信情報がサーバ2から申請端末3aまたは被申請端末3bへ送信される。なお、ステップS13の通知処理に関して、他の実施形態においては、ステップS11の判定においてフレンド申請を承認すると判定した場合、サーバ2は、申請ユーザ(および被申請ユーザ)に対して通知を行わないようにしてもよい。
【0085】
以上のように、本実施形態においては、被申請ユーザに対してフレンド申請があった場合、サーバ2は、被申請ユーザに対して行われた申請を承認する権限を有する承認者として、被申請ユーザとは別の承認ユーザを特定する(ステップS3)。そして、サーバ2は、申請の承認に関する問合せを承認ユーザの端末装置(承認端末3c)へ送信し、承認ユーザの端末装置から問合せに関する回答を受信する(ステップS10)。さらに、サーバ2は、受信された回答に基づいて、申請ユーザによる申請を承認するか否かの判定を行い(ステップS11)、申請ユーザによる申請を承認すると判定された場合、被申請ユーザに対する登録ユーザ(フレンド)として申請ユーザの識別情報を記憶する(ステップS12)。以上によれば、被申請ユーザは、自身に対するフレンド申請に関する承認を承認者(承認ユーザ)に依頼することができるので、申請を承認するか否かの判断による被申請ユーザの負担を軽減することができる。
【0086】
例えば、ユーザが子供である場合には、知らない他人のユーザからのフレンド申請を安易に承認してしまったり、他人が被申請ユーザの知人になりすまして行ったフレンド申請を(なりすましであることを見抜けずに)承認してしまったりする結果、何らかの被害にあう可能性がある。このような場合を想定して、サーバ2は、例えば、子供のユーザに対して親のユーザを承認ユーザとして登録しておくことによって、不正なフレンド申請が子供のユーザによって承認されてフレンド登録されてしまうことを防止することができる。このように、本実施形態によれば、SNSにおいて、子供のユーザに対するフレンド申請についてのペアレンタルコントロール機能を提供することができる。
【0087】
また、第1の実施形態においては、サーバ2は、少なくとも1のユーザについて、そのユーザに対して行われたフレンド申請を承認する権限を有する承認ユーザを示す承認者情報27をフレンド申請の前に予めデータ記憶部14に記憶しておく(
図2)。そして、サーバ2は、(フレンド申請があった場合、)データ記憶部14に記憶されている承認者情報27に基づいて承認ユーザを特定する。これによれば、被申請ユーザは、フレンド申請の度に承認ユーザを選択する必要が無いので、簡単に承認ユーザを設定することができる。なお、他の実施形態においては、例えば後述する第2の実施形態のように、フレンド申請がある度に被申請ユーザが承認ユーザを設定するようにしてもよい。
【0088】
また、第1の実施形態においては、サーバ2は、フレンド申請の承認に関する問合せを被申請ユーザの端末装置(被申請端末3b)へ送信し、被申請端末3bから問合せに関する回答を受信する(ステップS6)。そして、サーバ2は、承認ユーザの回答と被申請ユーザの回答とに基づいて判定を行う。つまり、承認ユーザおよび被申請ユーザの両方が申請を承認した場合に、フレンド申請が承認されたと判定する。これによれば、被申請ユーザ自身が承認するか否かの判断を行えるとともに、承認ユーザによる承認にも基づいて承認するか否かが判定されるので、被申請ユーザの判断負担を軽減することができる。
【0089】
なお、他の実施形態においては、サーバ2は、被申請ユーザに対して(フレンド申請を承認するか否かの)問合せを行わず、承認ユーザに対して(のみ)問合せを行うようにしてもよい。すなわち、サーバ2は、上記ステップS4〜S6の処理を実行せずに、ステップS7〜S11の処理を実行してもよい。これによれば、被申請ユーザは承認するか否かの回答を行わなくてもよいので、被申請ユーザの負担や手間をより軽減することができる。
【0090】
なお、第1の実施形態では、サーバ2は、被申請端末3bから受信した被申請ユーザの回答が申請を承認する旨を示す場合、申請の承認に関する問合せを承認端末3cへ送信し、当該回答が申請を承認しない旨を示す場合、当該問合せを承認端末3cへ送信しない。これによれば、被申請ユーザが承認しない場合には承認ユーザには問合せが行われないことから、承認ユーザは必要がない場合には問合せに対する回答を行わなくてもよいので、承認ユーザの作業負担を軽減することができる。
【0091】
また、第1の実施形態(後述する第2の実施形態においても同様)においては、サーバ2は、問合せを承認ユーザの端末装置(承認端末3c)へ送信する前に、被申請ユーザに対して申請の問合せを行っている(ステップS4)。つまり、サーバ2は、問合せを承認端末3cへ送信する前に、申請ユーザから被申請ユーザに対して申請があったことを被申請端末3bへ通知している。これによれば、承認ユーザが承認を行う場合であっても、サーバ2は、申請があったことを被申請ユーザへ事前に通知することができる。例えば、申請人が被申請人の実際の友人である場合等、フレンド申請が不正なものでないことが明らかであり、承認するか否かを被申請人自身が正しく判断することができる場合もある。このような場合、フレンド申請があったことが事前に(つまり、承認ユーザへ問合せが行われるよりも前に)被申請ユーザへ通知されるので、被申請ユーザは、フレンド申請に対して承認するように承認ユーザに対して予め伝えておくことができる。したがって、フレンド申請が承認ユーザによって誤って不承認とされてしまうおそれを低減することができる。
【0092】
なお、他の実施形態においては、サーバ2は、フレンド申請があった場合、被申請端末3bへ通知を行う前に承認端末3cに対して問合せを行い、承認端末3cから受信された承認ユーザの回答が申請を承認する旨を示す場合に(のみ)、被申請端末3bへ当該通知(例えば、申請が行われたことの通知や、申請が承認されたことの通知)を行うようにしてもよい。これによれば、承認されなかったフレンド申請については被申請ユーザに対する通知が行われないので、被申請ユーザの確認の手間を省くことができる。
【0093】
また、第1の実施形態(後述する第2の実施形態においても同様)においては、サーバ2は、フレンド申請の承認に関する問合せを承認端末3cへ送信する場合、申請ユーザに関して保存されるプロフィール情報(閲覧情報23)のうちの少なくとも一部の情報を当該問合せと共に送信する。これによれば、承認ユーザは、プロフィールの情報を参照することで、承認するか否かの判断を行いやすくなる。なお、サーバ2は、他の実施形態においては、プロフィール情報を送信することに代えて、プロフィール情報を閲覧可能なウェブページにアクセスするためのリンク情報を送信してもよい。
【0094】
(ユーザ情報を閲覧する処理)
次に、SNSにおいてユーザが他のユーザの情報(上記閲覧情報等)を閲覧する場合の処理について説明する。本実施形態においては、サーバ2は、SNSの各ユーザについて、閲覧情報等のユーザに関する情報を表示するためのウェブページのデータをデータ記憶部14に保存している。ユーザは、SNSのウェブサイトのうち、所望の他のユーザのウェブページにアクセスすることで、ウェブページを端末装置に表示し、当該他のユーザに関する情報を閲覧することができる。
【0095】
具体的には、閲覧を行うユーザ(閲覧ユーザ)が、所望の他のユーザ(被閲覧ユーザ)のウェブページを閲覧する場合、当該ウェブページに対するアクセス要求をサーバ2に対して行う。すなわち、閲覧ユーザの端末装置3は、閲覧ユーザの指示に応じて、アクセス要求をサーバ2へ送信する。
【0096】
サーバ2は、上記アクセス要求を受信した場合、アクセス要求を行った閲覧ユーザが、被閲覧ユーザのフレンドであるか(被閲覧ユーザに関して閲覧ユーザがフレンド登録されているか)否かを判定する。この判定は、被閲覧ユーザのユーザ情報21に含まれるフレンド情報26と、アクセス要求に含まれる閲覧ユーザの識別情報とに基づいて行われる。すなわち、閲覧ユーザの識別情報がフレンド情報26に含まれている場合、閲覧ユーザはフレンド登録されていると判定され、閲覧ユーザの識別情報がフレンド情報26に含まれていない場合、閲覧ユーザはフレンド登録されていないと判定される。
【0097】
閲覧ユーザがフレンド登録されていないと判定した場合、サーバ2は、被閲覧ユーザのユーザ情報21内の閲覧情報23のうち、非制限情報25を含み、制限情報24を含まないウェブページのデータを閲覧ユーザの端末装置3へ送信する。一方、閲覧ユーザがフレンド登録されていると判定した場合、サーバ2は、被閲覧ユーザのユーザ情報21内の閲覧情報23のうち、制限情報24および非制限情報25を含むウェブページのデータを閲覧ユーザの端末装置3へ送信する。これによって、閲覧ユーザの端末装置3では、閲覧ユーザがフレンド登録されている場合にのみ、被閲覧ユーザの制限情報24を含むウェブページを取得することができ、この場合にのみ閲覧ユーザは被閲覧ユーザの制限情報24を閲覧することができる。
【0098】
なお、SNSにおいてユーザが他のユーザの情報を閲覧するための方法(例えば、フレンド登録がされている場合にのみ制限情報の閲覧を可能とする方法)は任意であり、従来と同様の方法が用いられてもよい。
【0099】
[3.サーバ2における処理の具体例]
以下、
図6を参照して、第1の実施形態におけるサーバ2において実行されるフレンド登録処理の具体例について説明する。
図6は、本実施形態においてサーバ2(制御部12)が実行する情報処理の流れの一例を示すフローチャートである。本実施形態においては、
図6に示す一連の処理は、制御部12のCPUが、プログラム記憶部13に記憶される情報処理プログラムを実行することによって行われる。なお、
図6においては、フレンド登録に関する処理について示し、サーバ2において実行される他の処理(例えば、ユーザが他のユーザの情報を閲覧するための処理等)については、従来と同様であってもよいため、説明を省略する。
【0100】
なお、本出願において、図面に示すフローチャートにおける各ステップの処理は、単なる一例に過ぎず、同様の結果が得られるのであれば、各ステップの処理順序を入れ替えてもよいし、各ステップの処理に加えて(または代えて)別の処理が実行されてもよい。また、本明細書では、上記フローチャートの各ステップの処理をCPUが実行するものとして説明するが、上記フローチャートにおける一部のステップの処理を、CPU以外のプロセッサや専用回路が実行するようにしてもよい。なお、
図6に示す情報処理が開始されるタイミングは任意である。
【0101】
図6に示す処理においては、まずステップS21において、CPUは、各端末装置3から送信されてくるデータ(情報)を受信する。すなわち、CPUは、通信部11を介して受信される、フレンド申請の申請情報のデータ、および/または、サーバ2からの問合せに対する端末装置3からの回答のデータを取得する。
【0102】
ステップS22において、CPUは、フレンド申請があったか否か、すなわち、ステップS21の受信処理においてフレンド申請を受信したか否かを判定する。ステップS22の判定結果が肯定である場合、ステップS23において、CPUは、受信したフレンド申請に係る被申請ユーザを特定し(ステップS3参照)、特定した被申請ユーザ(被申請端末3b)へフレンド申請に対する問合せを行う(ステップS4参照)。上述のように、この問合せに応じて、被申請端末3bから回答が送信される(ステップS6参照)。その結果、上記ステップS21の処理によって、回答がサーバ2において受信される。
【0103】
ステップS24において、CPUは、被申請ユーザから回答があったか否か、すなわち、ステップS21において被申請端末3bからの回答を受信したか否かを判定する。ステップS24の判定結果が肯定である場合、ステップS25において、CPUは、受信した被申請ユーザの回答が、申請を承認する旨を示すか否かを判定する。ステップS25の判定結果が否定である場合、ステップS26において、CPUは、フレンド申請が承認されなかったと判定し、申請ユーザ(及び被申請ユーザ)に対してフレンド申請が拒否された(承認されなかった)ことの通知を行う。この通知処理は、上記ステップS13の処理と同様である。
【0104】
一方、ステップS25の判定結果が肯定である場合、ステップS27において、CPUは、被申請ユーザのユーザ情報21の承認者情報27に基づいて、被申請ユーザの承認ユーザを特定する(ステップS7参照)。続くステップS28において、CPUは、被申請ユーザの承認ユーザが設定されているか否かを判定する。すなわち、CPUは、上記ステップS27の処理によって承認ユーザが特定されたか否かを判定する。具体的には、被申請ユーザのユーザ情報21において承認者情報27が含まれている場合には、承認ユーザが特定されたと判定され、承認者情報27が含まれていない場合には、承認ユーザが特定されないと判定される。
【0105】
ステップS28の判定結果が否定である場合、ステップS29において、CPUは、申請ユーザを被申請ユーザのフレンドとするフレンド登録を行い、申請ユーザおよび被申請ユーザに対して、フレンド申請が承認されたことの通知を行う。ステップS29の処理は、上記ステップS12およびS13の処理と同様である。
【0106】
一方、ステップS28の判定結果が肯定である場合、ステップS30において、CPUは、特定された承認ユーザへ問合せを行う(ステップS8参照)。上述のように、この問合せに応じて、承認端末3cから回答が送信される(ステップS10参照)。そして、上記ステップS21の処理によって、回答がサーバ2において受信される。
【0107】
以上のように、本実施形態においては、被申請ユーザがフレンド申請を承認しなかった場合(ステップS25:No)には、承認ユーザに対する問合せが行われることなく、フレンド申請が承認されなかったと判断される(ステップS26)。また、被申請ユーザがフレンド申請を承認した場合(ステップS25:Yes)で、かつ、被申請ユーザに承認ユーザが設定されていない場合(ステップS28:No)には、承認ユーザに対する問合せが行われることなく、フレンド申請が承認されたと判断される(ステップS29)。
【0108】
ステップS31において、CPUは、承認ユーザから回答があったか否か、すなわち、ステップS21において承認端末3cから回答を受信したか否かを判定する。ステップS31の判定結果が肯定である場合、ステップS32において、CPUは、受信した承認ユーザの回答が、申請を承認する旨を示すか否かを判定する。ステップS32の判定結果が肯定である場合、ステップS33において、CPUは、申請ユーザを被申請ユーザのフレンドとするフレンド登録を行い(ステップS12参照)、申請ユーザおよび被申請ユーザに対して、フレンド申請が承認されたことの通知を行う(ステップS13参照)。一方、ステップS32の判定結果が否定である場合、ステップS34において、CPUは、ステップS26と同様に、申請ユーザ(及び被申請ユーザ)に対して、フレンド申請が拒否されたことの通知を行う。
【0109】
サーバ2のCPUが上記S21〜S31の処理を繰り返し実行することによって、
図4に示すサーバ2の処理が実行されることになる。
【0110】
<第2の実施形態>
次に、
図7〜
図9を参照して、第2の実施形態に係る情報処理システムにおいて実行される処理について説明する。第1の実施形態においては、被申請ユーザについての承認ユーザが予め定められており、フレンド申請があった場合には、予め定められた承認ユーザに対して問合せが行われた。これに対して、第2の実施形態においては、被申請ユーザは、フレンド申請毎に承認ユーザを選択するものとする。第2の実施形態は、例えば、正当なものであることが疑わしいフレンド申請が被申請ユーザに対して行われた場合に、被申請ユーザが(すでに登録済みである)フレンドのユーザに対して承認を依頼するケースに適用することができる。
【0111】
なお、第2の実施形態においては、第1の実施形態との相違点を中心に説明を行い、第1の実施形態と同じ構成又は動作(処理)については説明を省略することがある。また、以下において、第1の実施形態と同じ構成要素又は処理については、第1の実施形態と同じ参照符号又はステップ番号を付し、詳細な説明を省略することがある。
【0112】
[1.第2の実施形態における処理の概要]
第2の実施形態における情報処理システムの構成は、第1の実施形態と同様である(
図1参照)。ただし、サーバ2において記憶されている、被申請ユーザのユーザ情報21には、フレンド情報26は予め設定されていないものとする。また、以下では、承認ユーザとして2人のユーザが設定され、各承認ユーザがそれぞれ別の端末装置(
図7に示す承認端末3cおよび承認端末3d)を用いる場合を例として処理を説明する。
【0113】
図7は、第2の実施形態におけるフレンド登録処理の流れを示すタイミングチャートである。第2の実施形態においては、被申請ユーザを特定した(ステップS3)場合、サーバ2は、被申請端末3bへ、フレンド申請があった旨の通知(申請通知)を送信する(ステップS41)。すなわち、サーバ2は、申請通知に関する通知情報28を被申請ユーザのユーザ情報21に含めるように当該ユーザ情報21を更新する。ここで、申請通知は、フレンド申請を承認するか否かの回答と、承認ユーザの選択とのいずれかを被申請ユーザに行わせるための通知である。したがって、通知情報28には、申請通知時に送信される送信情報として、フレンド申請に対する承認の問合せに対する回答と承認ユーザの選択とを被申請ユーザに行わせるための回答画面(
図8参照)の情報が含まれる。その後、被申請ユーザが被申請端末3bを用いてサーバ2にアクセスし、SNSにログインした場合、送信情報がサーバ2から被申請端末3bへ送信され、回答画面が被申請端末3bの表示装置に表示される。
【0114】
図8は、申請通知時に被申請端末3bに表示される回答画面の一例を示す図である。
図8に示すように、回答画面には、第1の実施形態において示した問合せ画面と同様の、メッセージ31とボタン画像32および33とが含まれる。なお、
図8においては図示されないが、回答画面には、申請ユーザのプロフィール等の情報が含まれていてもよい。
【0115】
また、
図8に示すように、回答画面には、フレンド申請の承認を依頼する場合に承認ユーザを選択することを通知するメッセージ36と、承認ユーザの候補リスト37と、承認を依頼する指示を行うための画像(ボタン画像)38とが含まれる。候補リスト37は、承認ユーザとなる候補のユーザの名前(アカウント名)37aと、各ユーザが選択されているか否かを表すチェックボックス37bとを含む。被申請ユーザは、上記入力装置を用いて候補リスト35内のユーザから承認ユーザを選択し、「承認を依頼」と示されたボタン画像38を指定することで承認ユーザを決定する。
【0116】
なお、本実施形態においては、承認ユーザの候補として候補リスト37に含められるユーザは、被申請ユーザの登録済みのフレンド(被申請ユーザについてすでにフレンド登録されているユーザ)である。すなわち、サーバ2は、上記ステップS41において、被申請ユーザに関するユーザ情報21内のフレンド情報26に基づいて、被申請ユーザの登録済みのフレンドであるユーザを特定する。そして、特定されたユーザを含む候補リスト37を作成して、通知情報28内の送信情報に候補リストを含めて記憶しておく。候補リストには、承認ユーザの候補となるユーザの識別情報および/または名前の情報が含まれる。
【0117】
なお、承認ユーザの候補となるユーザの特定方法は任意である。例えば他の実施形態においては、サーバ2は、被申請ユーザの登録済みのフレンドに加えて(または代えて)申請ユーザの登録済みのフレンドを候補としてもよい。また例えば、サーバ2は、被申請ユーザの登録済みのフレンドであり、かつ、申請ユーザの登録済みのフレンドであるユーザを候補としてもよい。また例えば、SNSの運営者側で承認ユーザを用意しておき、用意された承認ユーザを候補に加えるようにしてもよい。
【0118】
申請通知に対して、被申請ユーザは、フレンド申請に対して承認するか否かを回答するか、または、承認ユーザを選択して承認を依頼するかのいずれかの入力を行う。
図7においては、承認ユーザを選択して承認を依頼する入力が行われた(ステップS42)場合を示しており、この場合、被申請端末3bは、サーバ2に対して選択された承認ユーザを通知する(ステップS43)。この通知には、選択された承認ユーザを特定する情報(識別情報や名前等)が含まれる。
【0119】
選択された承認ユーザの情報が被申請端末3bからサーバ2へ通知される場合、サーバ2は、受信した通知に基づいて承認ユーザを特定する(ステップS44)。このとき、特定された承認ユーザの識別情報は、被申請ユーザのユーザ情報21内の承認者情報27としてデータ記憶部14に記憶される。
【0120】
特定された承認ユーザに対してサーバ2から承認端末へ問合せを行い、承認端末において問合せに対する回答が入力され、回答結果を承認端末からサーバ2へ送信する動作は、第1の実施形態におけるステップS8〜S10における動作と同様である。ただし、第2の実施形態においては、ステップS8〜S10における動作がサーバ2と複数の承認端末との間で行われることがある(
図7参照)。
【0121】
サーバ2は、問合せを行った全ての承認端末3cおよび3dから回答結果を受信すると、回答結果を集計し、集計結果に基づいてフレンド申請を承認するか否かを判定する(ステップS45)。承認ユーザが複数である場合、サーバ2は、複数の回答結果が所定の条件を満たすか否かによって上記判定を行う。上記所定の条件の内容は任意であるが、例えば、回答結果の多数決(承認する旨の回答が承認しない旨の回答より多いか)であってもよいし、承認する旨の回答が所定数以上であることであってもよい。
【0122】
また、他の実施形態においては、サーバ2は、フレンド申請を承認するか否かの回答を承認端末から受信することに代えて、フレンド申請の承認に関する回答として、承認を支持する度合いを示す指標(得点等)を承認端末から受信するようにしてもよい。そして、各承認端末から受信した指標の集計結果である数値が所定の条件を満たすか否かによってフレンド申請を承認するかを判定してもよい。例えば、サーバ2は、承認端末から回答として得点の情報を受信し、受信された得点の合計値(または平均値)が所定以上であることを条件として、フレンド申請を承認するようにしてもよい。
【0123】
フレンド申請を承認するか否かを判定した後におけるサーバ2の処理は、第1の実施形態と同様である。すなわち、フレンド申請を承認すると判定した場合には、申請ユーザを被申請ユーザのフレンドとして登録する(ステップS12)。また、サーバ2は、(判定結果がいずれの場合でも)判定結果を申請ユーザおよび被申請ユーザへ通知する(ステップS13)。第2の実施形態においては、このとき、サーバ2は、ステップS44でデータ記憶部14に記憶した承認者情報27を削除する。
【0124】
[2.第2の実施形態におけるサーバ2の処理の具体例]
以下、
図9を参照して、第2の実施形態におけるサーバ2において実行されるフレンド登録処理の具体例について説明する。
図9は、第2の実施形態においてサーバ2(制御部12)が実行する情報処理の流れの一例を示すフローチャートである。なお、
図9においては、第1の実施形態との相違点を中心に処理の流れを示しており、第1の実施形態における処理(
図6)と同じ処理については同じステップ番号を付し、詳細な説明を省略する。
【0125】
第2の実施形態においては、ステップS22の判定結果が肯定であった場合、ステップS51において、CPUは、受信したフレンド申請に係る被申請ユーザを特定し(上記ステップS3参照)、特定した被申請ユーザ(被申請端末3b)へ上述の申請通知を送信する(ステップS41参照)。上述のように、この申請通知に応じて、フレンド申請を承認するか否かの回答と、選択された承認ユーザの通知とのいずれかが被申請端末3bから送信される(ステップS43参照)。そして、上記ステップS21の処理によって、上記の回答または通知がサーバ2において受信される。
【0126】
第2の実施形態においては、ステップS22の判定結果が否定であった場合、または、ステップS51の処理に続いて、上述のステップS24の処理が実行される。すなわち、ステップS24において、CPUは、被申請ユーザから回答があったか否かを判定する。ステップS24の判定結果が肯定である場合、ステップS25において、受信した被申請ユーザの回答が、申請を承認する旨を示すか否かを判定する。ステップS25の判定結果が肯定である場合、ステップS33の処理が実行され、ステップS25の判定結果が否定である場合、ステップS34の処理が実行される。つまり、被申請ユーザから回答に従ってフレンド申請を承認するか否かが判定され、判定に応じた処理が実行される。
【0127】
一方、ステップS24の判定結果が否定である場合、ステップS52において、CPUは、被申請ユーザが選択した承認ユーザの通知があったか否か、すなわち、ステップS21において被申請端末3bから当該通知を受信したか否かを判定する。ステップS52の判定結果が肯定である場合、ステップS53において、CPUは、被申請ユーザからの通知に基づいて承認ユーザを特定し(ステップS44参照)、特定した承認ユーザに対してサーバ2から承認端末へ問合せを行う(ステップS8参照)。上述のように、この問合せに応じて、承認端末から回答が送信される(ステップS10参照)。そして、上記ステップS21の処理によって、回答がサーバ2において受信される。本実施形態においては、CPUは、受信した回答を制御部12内のメモリまたはデータ記憶部14に記憶しておく。
【0128】
ステップS54において、CPUは、被申請ユーザによって選択された全ての承認ユーザから回答を受信したか否かを判定する。ステップS54の判定結果が肯定である場合、ステップS55において、CPUは、承認ユーザの回答結果を集計する。例えば、CPUは、集計結果として、承認する旨を示す回答結果の数、および、承認しない旨を示す回答結果の数を算出し、メモリに記憶する。続くステップS56において、CPUは、メモリに記憶されている集計結果を読み出し、集計結果に基づいて、フレンド申請を承認するか否かを判定する(ステップS45参照)。この判定は、例えば、承認する旨を示す回答結果の数が、承認しない旨を示す回答結果の数を上回ったか否かによって行われる。
【0129】
ステップS56の判定結果が肯定である場合、第1の実施形態と同様のステップS33の処理が実行され、ステップS56の判定結果が否定である場合、第1の実施形態と同様のステップS34の処理が実行される。
【0130】
以上のように、第2の実施形態においては、サーバ2は、フレンド申請が受信された場合、当該フレンド申請に関する承認者(承認ユーザ)を選択するための問合せ(申請通知)を被申請端末3bへ送信し(ステップS41)、被申請端末3bから、選択された承認ユーザを示す情報を受信する(ステップS43)。そして、サーバ2は、受信された承認ユーザを示す情報に基づいて承認者を特定する(ステップS44)。したがって、第2の実施形態によれば、被申請ユーザはフレンド申請毎に承認ユーザを設定することができ、申請ユーザに応じた適切な承認ユーザを選択することができる。例えば、被申請ユーザは、申請ユーザが被申請ユーザの勤め先の同僚である場合には、同じ同僚である登録済みのフレンドを承認ユーザとしたり、申請ユーザが被申請ユーザと同じ学校の卒業生である場合には、同じ学校の卒業生である登録済みのフレンドを承認ユーザとしたりすることができる。
【0131】
また、第1および第2の実施形態においては、サーバ2は、被申請ユーザの端末装置から承認ユーザを設定するか否かに関する情報を受信し、受信した情報に基づいて、承認ユーザを設定するか否かを判定する。そして、サーバ2は、承認ユーザを設定すると判定された場合に承認ユーザを特定する(ステップS44)。このように、第2の実施形態によれば、承認ユーザを設定するか否かを被申請ユーザに選択させるので、被申請ユーザは、フレンド申請の承認の判断を自身で行うこともできるし、他のユーザに承認を依頼することもできる。これによって、被申請ユーザの承認判断による負担を軽減することができるとともに、(承認の依頼を不要と判断した場合には)申請ユーザを容易にフレンドとして登録することができる。
【0132】
また、第2の実施形態においては、サーバ2は、複数の承認ユーザを特定してもよい(
図7参照)。このとき、サーバ2は、特定された複数の承認ユーザそれぞれの端末装置へ問合せを送信するとともに、各端末装置から回答を受信する。サーバ2は、受信された各回答から、承認を支持する度合いを示す数値(例えば、承認する旨を回答した承認ユーザの数。承認を支持しない度合いを示す数値とも言える。)を算出し、算出された数値が所定の条件を満たすか否かによって、申請を承認するか否かを判定する。これによれば、複数の承認ユーザが設定される場合に、承認するか否かを容易に判断することができる。
【0133】
<第3の実施形態>
次に、
図10〜
図13を参照して、第3の実施形態に係る情報処理システムにおいて実行される処理について説明する。第1および第2の実施形態においては、被申請ユーザは、他のユーザに対してフレンド申請の承認を依頼した。これに対して、第3の実施形態においては、被申請ユーザは、自身がフレンド申請の承認を判断する上での参考とするために、他のユーザに対してフレンド申請(つまり申請ユーザ)の評価を依頼する。第3の実施形態は、例えば、正当なものであることが疑わしいフレンド申請が被申請ユーザに対して行われた場合に、被申請ユーザが(すでに登録済みである)フレンドのユーザに対して評価を依頼するケースに適用することができる。
【0134】
なお、第3の実施形態においては、第1および第2の実施形態との相違点を中心に説明を行い、第1および第2の実施形態と同じ構成又は動作(処理)については説明を省略することがある。また、以下において、第1および第2の実施形態と同じ構成要素又は処理については、第1および第2の実施形態と同じ参照符号又はステップ番号を付し、詳細な説明を省略することがある。
【0135】
[1.第3の実施形態における処理の概要]
以下、
図10〜
図12を参照して、第3の実施形態における情報処理システム1において実行されるフレンド登録処理の概要について説明する。
図10は、フレンド登録が行われる場合における動作の流れを大略的に示す図である。以下では、
図10に示すように、申請ユーザが被申請ユーザに対してフレンド申請を行い(
図10に示す(1))、被申請ユーザが評価ユーザに承認を依頼し(
図10に示す(2))、評価ユーザが申請ユーザに対する評価を被申請ユーザに通知し(
図10に示す(3))、その評価を参考に被申請ユーザが承認/不承認を行う(
図10に示す(4))場合における、情報処理システム1における処理について説明する。また、以下では、評価ユーザとして2人のユーザが設定され、各評価ユーザがそれぞれ別の端末装置(
図7に示す評価端末3eおよび評価端末3f)を用いる場合を例として処理を説明する。
【0136】
第3の実施形態における情報処理システムの構成は、第1の実施形態と同様である(
図1参照)。ただし、サーバ2において記憶されている、被申請ユーザのユーザ情報21の内容は第1の実施形態と相違する。すなわち、第3の実施形態においては、承認者情報27に代えて評価者情報がユーザ情報21に含まれる。評価者情報は、ユーザに対するフレンド申請を評価する(申請ユーザを評価するとも言える)権限を有する他のユーザ(評価ユーザ)の識別情報を示す。つまり、評価者情報は、ユーザがフレンド申請の評価を他のユーザに依頼する場合に設定される。ユーザ情報21内に評価者情報が設定される場合、ユーザ情報21に対応するユーザに対するフレンド申請は、評価者情報により示される評価ユーザによって評価が行われる(詳細は後述する)。
【0137】
図11は、第3の実施形態におけるフレンド登録処理の流れを示すタイミングチャートである。なお、
図11では図示しないが、申請端末3aにおいてフレンド申請が入力されてサーバ2へ送信され、サーバ2において被申請ユーザが特定される処理(ステップS1〜S3)は、第1の実施形態と同様である。
【0138】
第3の実施形態においては、被申請ユーザを特定した場合、サーバ2は、被申請端末3bへ、フレンド申請があった旨の通知(申請通知)を送信する(ステップS61)。この申請通知は、第2の実施形態では承認ユーザの選択を行わせるのに対して、第3の実施形態では評価ユーザの選択を行わせるかという点で異なる他は、第2の実施形態におけるステップS41と同様である。また、回答画面において被申請ユーザに提示される評価ユーザの候補となるユーザの決定方法も、第2の実施形態と同様である。
【0139】
申請通知に対して、被申請ユーザは、フレンド申請に対して承認するか否かを回答するか、または、評価ユーザを選択して評価を依頼するかのいずれかの入力を行う。
図11においては、評価ユーザを選択して評価を依頼する入力が行われた(ステップS62)場合を示しており、この場合、被申請端末3bは、サーバ2に対して選択された評価ユーザを通知する(ステップS63)。この通知には、選択された評価ユーザを特定する情報(識別情報や名前等)が含まれる。
【0140】
選択された評価ユーザの情報が被申請端末3bからサーバ2へ通知される場合、サーバ2は、受信した通知に基づいて評価ユーザを特定する(ステップS64)。また、サーバ2は、特定された評価ユーザに対してサーバ2から評価端末3eおよび3fへ問合せを行う(ステップS65)。各評価端末3eおよび3fにおいては、この問合せに対する回答(フレンド申請に対する評価)が入力される(ステップS66)。回答が入力されると、各評価端末3eおよび3fは、回答結果をサーバ2へ送信する(ステップS67)。ステップS65〜S67の処理は、評価端末において入力される回答が、フレンド申請に対する評価である点を除いて、第1および第2の実施形態におけるステップS8〜S10の処理と同様である。
【0141】
ここで、第3の実施形態において、評価端末において入力される回答(評価)は、フレンド申請に対する評価を表すものであればどのようなものであってもよい。例えば、承認を支持する度合いを示す数値が回答として入力されてもよいし、第1および第2の実施形態と同様、承認するか否かを示す回答が入力されてもよい。また、評価ユーザによるコメント(メッセージ)が回答として入力されてもよい。
【0142】
サーバ2は、問合せを行った全ての評価端末3eおよび3fから回答結果を受信すると、回答結果を集計する(ステップS68)。例えば、回答結果が、承認を支持する度合いを示す数値である場合には、各数値の合計値または平均値が集計結果として算出されてもよい。また例えば、回答結果が、承認するか否かを示す情報である場合には、承認する旨の回答の数、および/または、承認しない旨の回答の数が集計結果として算出されてもよい。なお、他の実施形態においては、集計結果を算出する処理は実行されなくてもよく、後述するステップS69においてサーバ2は評価端末からの回答結果(評価結果)をそのまま被申請端末3bへ送信してもよい。
【0143】
集計結果を算出すると、サーバ2は、集計結果を含めて、フレンド申請を承認するか否かの問合せを被申請端末3bへ送信する(ステップS69)。集計結果を含む問合せを被申請端末3bへ送信する方法は、上記ステップS4において問合せを送信する方法と同様である。具体的には、第3の実施形態においては、集計結果を提示するとともに、フレンド申請に対する回答(承認/不承認)の回答を入力するための画像を含む問合せ画面を表示するための情報がサーバ2から被申請端末3bへ送信され、当該問合せ画面が被申請端末3bに表示される。
【0144】
図12は、第3の実施形態における問合せ画面の一例を示す図である。
図12に示すように、問合せ画面には、承認ユーザによる評価があったことを示すメッセージ39と、評価の集計結果を示す画像40とが含まれる。また、問合せ画面には、第1の実施形態と同様のボタン画像32および33と、申請ユーザのプロフィール35とが含まれる。被申請ユーザは、画像40により示される集計結果(およびプロフィール35)を参考に、ボタン画像32および33を用いて、フレンド申請を承認するか否かの回答を入力する。入力が行われたことに応じて、被申請端末3bは、第1の実施形態におけるステップS6と同様、回答結果(承認または不承認)を示す情報をサーバ2へ送信する(ステップS71)。
【0145】
サーバ2は、被申請端末3bから送信されてくる回答を受信し、フレンド申請を承認するか否かの判定を回答に基づいて行う(ステップS72)。そして、フレンド申請を承認すると判定した場合には、第1および第2の実施形態と同様、申請ユーザが被申請ユーザのフレンドとして登録される(ステップS12)。さらに、サーバ2は、第1および第2の実施形態と同様、判定結果を申請ユーザおよび被申請ユーザへ通知する(ステップS13)。
【0146】
[2.第3の実施形態におけるサーバ2の処理の具体例]
以下、
図13を参照して、第3の実施形態におけるサーバ2において実行されるフレンド登録処理の具体例について説明する。
図13は、第3の実施形態においてサーバ2(制御部12)が実行する情報処理の流れの一例を示すフローチャートである。なお、
図13においては、第1および第2の実施形態との相違点を中心に処理の流れを示しており、第1の実施形態における処理(
図6)と同じ処理については同じステップ番号を付し、詳細な説明を省略する。
【0147】
第3の実施形態においては、第2の実施形態におけるステップS51〜S54の処理に代えてステップS81〜S84の処理が実行される。ステップS81〜S84の処理は、承認ユーザに関する処理であるか評価ユーザに関する処理であるかで異なる他は、ステップS51〜S54の処理と同様である。
【0148】
第3の実施形態においては、ステップS84の判定結果が肯定である場合、ステップS85の処理が実行される。ステップS85において、CPUは、評価ユーザから受信した回答結果(評価結果)を集計する。ステップS85に続くステップS86において、CPUは、集計結果を被申請ユーザ(被申請端末3b)へ通知する。上述のように、この通知に応じて、フレンド申請を承認するか否かの回答が被申請端末3bから送信される(上記ステップS71参照)。この回答は、上記ステップS21の処理によってサーバ2において受信されると、ステップS24の判定結果が肯定となり、ステップS25においてフレンド申請を承認するか否かの判定がサーバ2において行われる。
【0149】
以上のように、第3の実施形態においては、サーバ2は、被申請ユーザに対して行われた申請を評価する権限を有する評価者(評価ユーザ)として、被申請ユーザとは別のユーザを特定する(ステップS64,S81)。そして、サーバ2は、申請ユーザに対する評価に関する問合せを評価端末3eおよび3fへ送信し(ステップS65,S81)、評価端末3eおよび3fから問合せに関する回答を受信する(ステップS67)。サーバ2は、受信された回答に基づいて得られる評価情報(集計結果)とともにフレンド申請の承認に関する問合せを被申請端末3bへ送信し(ステップS69)、被申請端末3bから問合せに関する回答を受信する(ステップS71)。さらに、サーバ2は、被申請端末3bから受信された回答に基づいて、フレンド申請を承認するか否かの判定を行い(ステップS72)、フレンド申請を承認すると判定した場合、被申請ユーザに対する登録ユーザ(フレンド)として申請ユーザの識別情報を記憶する。以上によれば、被申請ユーザは、自身に対するフレンド申請に関する評価を評価者(評価ユーザ)に依頼することができ、評価者による評価を参考に、フレンド申請を承認するか否かを判断することができる。これによって、フレンド申請を承認するか否かの判断による被申請ユーザの負担を軽減することができる。
【0150】
また、第3の実施形態においては、フレンド申請がある度に被申請ユーザが評価ユーザを設定する。すなわち、サーバ2は、フレンド申請があった場合、当該フレンド申請に関する評価ユーザを選択するための問合せを被申請端末3bへ送信し(ステップS61)、被申請端末3bから、選択された評価ユーザを示す情報を受信する(ステップS63)。そして、サーバ2は、受信された評価ユーザを示す情報に基づいて評価ユーザを特定する(ステップS64)。これによれば、被申請ユーザはフレンド申請毎に評価ユーザを設定することができ、申請ユーザに応じた適切な評価ユーザを選択することができる。
【0151】
また、第3の実施形態においては、評価ユーザを設定するか否かをフレンド申請がある度に被申請ユーザが選択する。すなわち、サーバ2は、評価ユーザを設定するか否かの問合せを被申請端末3bへ送信し(ステップS61,S81)、被申請端末3bからの回答に基づいて、評価ユーザを設定するか否かを判定する(ステップS24,S82)。そして、サーバ2は、評価ユーザを設定すると判定された場合に評価ユーザを特定する(ステップS83)。これによれば、被申請ユーザの承認判断による負担を軽減することができるとともに、(評価の依頼を不要と判断した場合には)申請ユーザを容易にフレンドとして登録することができる。
【0152】
なお、他の実施形態においては、第1の実施形態における承認ユーザの設定方法と同様に、サーバ2は、少なくとも1のユーザについて、そのユーザに対して行われたフレンド申請を評価する権限を有する評価ユーザの識別情報をフレンド申請の前に予め記憶装置に記憶しておくようにしてもよい。そして、サーバ2は、記憶装置に記憶されている評価ユーザの識別情報に基づいて評価ユーザを特定してもよい。これによれば、被申請ユーザは、フレンド申請の度に評価ユーザを選択する必要が無いので、簡単に評価ユーザを設定することができる。
【0153】
また、第3の実施形態においては、サーバ2は、申請ユーザに対する評価に関する問合せを評価端末へ送信する場合、申請ユーザに関して保存されるプロフィール情報(閲覧情報23)のうちの少なくとも一部の情報を当該問合せと共に送信する。これによれば、評価ユーザは、プロフィールの情報を参照することで評価を行いやすくなる。
【0154】
また、第3の実施形態においては、サーバ2は、複数の評価ユーザを特定してもよい(
図10参照)。このとき、サーバ2は、特定された複数の評価ユーザそれぞれの端末装置へ問合せを送信するとともに、各端末装置から回答を受信する。サーバ2は、受信された各回答から、評価の指標を示すパラメータ(集計結果)を算出し、算出されたパラメータとともにフレンド申請の承認に関する問合せを被申請端末3bへ送信する。これによれば、複数の評価ユーザが設定される場合に、評価結果をわかりやすく被申請ユーザに提示することができ、被申請ユーザは、承認するか否かの判断を行いやすくなる。
【0155】
<変形例>
(申請ユーザに申請許可ユーザが設定される変形例)
上記第1〜第3の実施形態における変形例においては、フレンド申請を行うことを許可する権限を有する申請許可者として、申請ユーザとは別の許可ユーザが設定されてもよい。
図14は、第1の実施形態における変形例において、フレンド申請が行われる場合における動作の流れを大略的に示す図である。
図14に示すように、本変形例においては、ある申請ユーザが他の被申請ユーザに対してフレンド申請を行った場合(
図14に示す(1))、当該フレンド申請に対して許可ユーザが許可するか否かを判断し(
図14に示す(2))、許可された場合に、被申請ユーザに対してフレンド申請が通知される(
図14に示す(3))。なお、
図14では、申請ユーザが用いる申請端末3aと、許可ユーザが用いる許可端末3gとはそれぞれ別の端末装置であるとするが、これらの端末として同じ(1つの)情報処理装置が用いられてもよい。
【0156】
図15は、
図14に示す変形例におけるフレンド申請処理の流れを示すタイミングチャートである。まず、申請ユーザが申請端末3aを用いてフレンド申請の入力を行い(ステップS1)、フレンド申請が申請端末3aからサーバ2へ送信される(ステップS2)点は、第1の実施形態と同様である。
【0157】
本変形例においては、申請端末3aからフレンド申請を受信すると、サーバ2は、申請ユーザに設定される許可ユーザを特定する(ステップS91)。許可ユーザの特定は、上記被申請ユーザに設定される承認ユーザを特定する方法と同様の方法で行うことができる。すなわち、サーバ2は、申請ユーザに設定される許可ユーザを特定可能な情報(識別情報等)を許可者情報としてユーザ情報21に含めて記憶しておく。フレンド申請があった場合、サーバ2は、申請ユーザのユーザ情報21内の許可者情報を参照することによって、許可ユーザを特定する。なお、申請ユーザに対して許可ユーザが設定されていない場合、サーバ2は、第1の実施形態と同様に、被申請ユーザを特定して被申請端末3bへフレンド申請に対する問合せを行う。
【0158】
許可ユーザを特定した場合、サーバ2は、許可ユーザの端末である許可端末3gへ、フレンド申請を許可するか否かの問合せを行う(ステップS92)。この問合せを許可端末3gへ送信する方法は、上記ステップS4において問合せを被申請端末3bへ送信する方法と同様である。ステップS92では、送信情報として、許可端末3gにおいて問合せ画面を表示するための情報が送信される。
【0159】
許可端末3gにおいてサーバ2からの送信情報が受信されると、許可端末3gは、上記問合せ画面を表示装置に表示する。この問合せ画面には、申請ユーザによるフレンド申請を許可するか否かを回答するための画像が含まれる。また、サーバ2は、問合せの際に被申請ユーザの名前および/またはプロフィールの情報を送信し、問合せ画面には、被申請ユーザの名前および/またはプロフィールが含まれていてもよい。
【0160】
許可端末3gにおいて上記問合せ画面が表示された場合、許可ユーザは、問合せ画面に対して入力を行うことによって、フレンド申請を許可するか否かの回答を入力する(ステップS93)。入力が行われたことに応じて、許可端末3gは、回答結果(許可または不許可)を示す情報をサーバ2へ送信する(ステップS94)。回答には、申請ユーザの識別情報と、フレンド申請の許可または不許可を示す回答結果の情報とが含まれる。
【0161】
許可端末3gから送信されてくる許可ユーザの回答を受信すると、サーバ2は、フレンド申請を行う(被申請ユーザにフレンド申請を通知する)か否か、換言すれば、フレンド申請が有効か否かを判定する(ステップS95)。受信された許可ユーザの回答が許可を示す場合、サーバ2は、フレンド申請を行うと判定し、図示しないが、上記第1の実施形態と同様に、被申請端末3bへフレンド申請に対する問合せを行う(上記ステップS4参照)。その後、被申請ユーザが承認ユーザに承認を依頼した場合には、第1の実施形態と同様、フレンド申請を承認するか否かの問合せが承認ユーザに対して行われる(ステップS8参照)。
【0162】
一方、受信された許可ユーザの回答が不許可を示す場合、サーバ2は、フレンド申請を行わないと判定し、図示しないが、申請ユーザへフレンド申請を行わない旨を通知する。
【0163】
以上のように、上記変形例においては、サーバ2は、フレンド申請を受信した場合、フレンド申請を行うことを許可する権限を有する申請許可者として、申請ユーザとは別の許可ユーザを特定する(ステップS91)。そして、サーバ2は、フレンド申請を許可することに関する問合せを許可端末3gへ送信し、許可端末3gから問合せに関する回答を受信する(ステップS94)。受信された回答がフレンド申請を許可する旨を示す場合、サーバ2は、申請ユーザによるフレンド申請を有効とみなし、一方、受信された回答がフレンド申請を許可しない旨を示す場合、申請ユーザによる申請を無効とする(却下する)。フレンド申請が有効とみなされた場合、フレンド申請の承認に関する問合せが承認端末へ送信される。以上によれば、申請ユーザがフレンド申請を行うことを他の許可ユーザによって制限することができる。例えば、申請ユーザが子供である場合には、正当であることが疑わしいユーザに対してフレンド申請を行ってしまう結果、正当でないユーザをフレンド登録してしまうおそれがある。これに対して、上記変形例によれば、申請ユーザに対して親(保護者)を許可ユーザに設定しておくことで、疑わしいユーザに対して子供がフレンド申請を行ってしまうことを防止することができる。
【0164】
なお、上記においては、上記変形例を第1の実施形態に適用する場合を例として説明したが、本変形例は、第2および第3の実施形態に適用することも可能である。
【0165】
(承認者がユーザ登録されていない場合における変形例)
上記第1の実施形態においては、承認ユーザがSNSのユーザとして登録されている場合を例として説明した。ここで、他の実施形態においては、SNSのユーザでない者を承認者として設定するようにしてもよい。以下、上記第1の実施形態の変形例として、承認者がユーザ登録されていない場合における情報処理システム1の処理について説明する。
【0166】
本変形例では、承認者は、SNSについてユーザ登録を行っておらず(そのため、識別情報が付されていない)、サーバ2と通信可能な所定の情報処理装置を用いるものとする。ここで、本変形例においては、承認者情報27として、承認者が用いる情報処理装置(承認装置)と通信を行うための通信情報(例えばメールアドレス等)がデータ記憶部14に記憶される。
【0167】
承認者に問合せを行う場合、サーバ2は、上記通信情報を用いて承認装置と通信を行うことによって、問合せに関する送信情報を承認装置へ送信する。例えば、承認装置のメールアドレスを用いて送信情報を電子メールで送信する。送信情報の具体的な内容は任意であるが、例えば、サーバ2は、上述の問合せ画面と同様のウェブページを用意しておき、当該ウェブページにアクセスするための情報(リンク情報)を送信情報として送信してもよい。このウェブページ(問合せ画面)には、上記第1の実施形態と同様、申請ユーザのプロフィールが含まれていてもよい。承認装置が問合せを受信した場合、承認者は、上記ウェブページにアクセスして、回答を入力する。サーバ2は、ウェブページ上で行われた回答を取得し、取得した回答に基づいてフレンド申請を承認するか否かを判定する(上記ステップS11参照)。
【0168】
上記変形例によれば、サーバ2は、アカウントが付与されたユーザに関してユーザ情報21を保存する一方、アカウントが付与されない承認者に対して問合せを送信する。ここで、サーバ2は、アカウントが付与されない承認者に対して問合せを送信する場合、当該問合せに対する回答を行うためのウェブページにアクセスするためのリンク情報を含む情報を承認者の情報処理装置へ送信し、当該ウェブページ上で承認者の情報処理装置によって行われた回答を取得する。これによれば、SNSのアカウントを持たない者を承認者にすることができる。SNSを利用しない承認者は、承認を行うためにユーザ登録を行う必要がないので、SNSを利用しない承認者の手間を省くことができる。なお、他の実施形態においては、アカウントが付与されない承認者だけでなく、アカウントが付与された承認者(上記第1および第2の実施形態における承認ユーザ)に対しても、上記変形例における方法で承認者から回答を取得してもよい。この場合でも、上記変形例と同様の効果を得ることができる。
【0169】
なお、上記変形例は、第1の実施形態に限らず、第2の実施形態において承認者を設定する場合にも適用することができる。また、第3の実施形態において評価者を設定する場合、および、上述した申請許可者を設定する場合にも上記変形例を適用することができる。
【0170】
(承認ユーザからの回答がない場合における変形例)
上記第1および第2の実施形態においては、サーバ2は、(全ての)承認ユーザからの回答を受信したことに応じて、フレンド申請を承認するか否かを判定した(ステップS31,S54参照)。ここで、他の実施形態においては、サーバ2は、承認ユーザに対する問合せが行われてから所定期間内に当該問合せに対する回答が(承認端末から)受信されない場合、当該問合せに対する回答はフレンド申請を承認しない旨を示すと判定してもよい。例えば、承認ユーザが1人である場合に、問合せが行われてから所定期間が経過しても当該問合せに対する回答が受信されなければ、サーバ2は、フレンド申請を承認しないと判定してもよい。また例えば、承認ユーザが複数である場合に、問合せが行われてから所定期間が経過しても一部の承認ユーザから当該問合せに対する回答が受信されなければ、サーバ2は、当該一部の承認ユーザの回答はフレンド申請を承認しない旨を示すと判定してもよい。そして、所定期間が経過した時点で、各承認ユーザからの回答に基づいて、フレンド申請を承認するか否かを判定してもよい。以上によれば、サーバ2は、承認ユーザからの回答が受信されない場合でも、フレンド申請を承認するか否かの判定を実行することができる。
【0171】
(承認ユーザによってフレンド申請が追認される変形例)
他の実施形態においては、サーバ2は、フレンド申請を被申請ユーザが承認したことに応じて、申請ユーザを被申請ユーザのフレンドとして仮登録してもよい。このとき、所定期間内に承認ユーザによってフレンド申請が承認(追認)された場合、サーバ2は、申請ユーザを被申請ユーザのフレンドとして本登録し、所定期間内に承認ユーザによってフレンド申請が承認(追認)されなかった場合、サーバ2は、仮登録を解消し、フレンド申請を承認しないようにしてもよい。これによれば、被申請ユーザの承認によってフレンド登録を迅速に行うことができるとともに、承認ユーザの承認結果を考慮したフレンド登録を行うことができる。
【0172】
(フレンド申請および承認を行うユーザの名義に関する変形例)
上記実施形態および変形例においては、フレンド申請はフレンド申請を行った申請ユーザ自身の名義で行われた。つまり、サーバ2は、被申請ユーザに対して、申請ユーザからフレンド申請があったことを通知した(
図6参照)。また、フレンド申請の承認は、フレンド申請を受けた被申請ユーザの名義で行われた。ここで、他の実施形態においては、申請ユーザに許可ユーザが設定される場合、当該申請ユーザによるフレンド申請は、許可ユーザの名義で行われたものとして被申請ユーザに対して通知されてもよい。また、被申請ユーザに承認ユーザが設定される場合、承認ユーザによる承認は、承認ユーザの名義で行われたものとして申請ユーザに通知されてもよい。
【0173】
(上記実施形態の組み合わせに関する変形例)
上記実施形態においては、承認ユーザが予め設定されているユーザの例(第1の実施形態)、フレンド申請毎に承認ユーザが設定されるユーザの例(第2の実施形態)、および、評価ユーザが設定されるユーザの例(第3の実施形態)について説明した。他の実施形態においては、単一のSNSにおいて、これらのユーザが混在していてもよい。さらに、上記変形例で説明した許可ユーザが設定されるユーザが含まれていてもよい。このとき、サーバは、ユーザ情報に承認者情報、評価者情報、および許可者情報を必要に応じて含めて記憶する。そして、被申請ユーザのユーザ情報に承認者情報および評価者情報が設定されていない場合、サーバは、フレンド申請があったことを通知する際に、被申請ユーザ自身が承認を行うか、他のユーザに承認を依頼するか、他のユーザに評価を依頼するかを被申請ユーザに選択させるようにしてもよい。
【0174】
(フレンドのレベルに関する変形例)
上記実施形態においては、サーバ2は、フレンド登録が行われているユーザであるかフレンド登録が行われていないユーザであるかによって、閲覧情報23のうちで閲覧可能な情報に差を付けるようにした。ここで、他の実施形態においては、サーバ2は、フレンド登録に複数のレベルを設定し、閲覧するユーザのレベルに応じて、閲覧情報23のうちで閲覧可能な情報に差を付けるようにしてもよい。この場合、フレンド申請はレベル毎に行われる。
【0175】
(登録されたユーザに付与される権限に関する変形例)
上記実施形態においては、あるユーザに対して登録(フレンド登録)された他のユーザに対して、当該あるユーザに関する所定の情報を閲覧する権限を付与する場合を例として説明を行った。ここで、他の実施形態においては、登録された他のユーザに対して付与される権限の内容は任意である。あるユーザについて登録された他のユーザに対して付与される権限は、例えば、当該あるユーザに対して情報(例えば、当該あるユーザが書き込んだ日記等の情報に対するコメントやメッセージ等)を送信する権限であってもよいし、当該あるユーザのデータ(動画データや音楽データ等)を共有することができる権限であってもよい。
【0176】
また、他の実施形態においては、サーバは、複数のユーザに関する情報を保存し、あるユーザに関する所定の情報を他のユーザに対して提供する任意のサーバ(サーバシステム)であってよい。例えば、サーバは、オンラインゲームやソーシャルゲーム等の種類のゲームを提供するゲームサーバであってもよい。この場合、登録された他のユーザに対して付与される権限としては、フレンド登録されたユーザ(プレイヤ)同士でゲームをプレイする権限や、フレンド登録されたユーザ同士でデータ交換を行う権限が考えられる。