以下、本発明の実施形態について、図面に基づき詳細に説明する。
図1は、本発明の一実施形態に係る情報処理システム1の構成図である。同図に示すように、情報処理システム1は、ユーザー管理サーバ2と、複数のクライアント装置3と、ゲームサーバ4と、を含んで構成されている。情報処理システム1は、複数のユーザーにソーシャルネットワーク型のオンラインサービスを提供する。特に本実施形態では、情報処理システム1は複数のユーザーが参加して一緒にプレイすることのできるオンラインゲームサービスを提供する。
クライアント装置3は、当該情報処理システム1で実現されるオンラインサービスを利用する各ユーザーが使用する端末装置であって、例えば家庭用ゲーム機や携帯ゲーム機、スマートフォン、パーソナルコンピュータ等であってよい。各クライアント装置3は、ユーザーが操作入力に使用する操作デバイスと、各種の情報を表示する表示画面と、を備えている。
ユーザー管理サーバ2は、本実施形態のオンラインサービスを利用するユーザーの情報を管理する。ユーザー管理サーバ2は、図1に示すように、制御部11と、記憶部12と、通信部13と、を含んで構成されている。
制御部11は、CPU等であって、記憶部12に格納されたプログラムに従って各種の情報処理を行う。制御部11が実行する処理の具体例については、後述する。記憶部12は、RAM等のメモリ素子を含んで構成され、制御部11が実行するプログラム、及び当該プログラムが処理対象とするデータを記憶する。記憶部12が記憶するデータには、後述する各ユーザーの情報が含まれる。
通信部13は、LANカード等の通信インタフェースであって、通信部13を介してユーザー管理サーバ2は複数のクライアント装置3、及びゲームサーバ4のそれぞれとデータの送受信を行う。
ゲームサーバ4は、本実施形態のオンラインサービスで提供されるゲームの情報を管理する。また、当該ゲームそのものの処理を実行してもよい。ゲームサーバ4は、本サービスで提供されるゲームの種類毎に互いに独立に用意されてもよい。
以下、本実施形態に係る情報処理システム1が実現する機能について、説明する。図2に示すように、情報処理システム1は、機能的に、ユーザー情報記憶部21と、ユーザー情報登録部22と、ユーザー情報要求受付部23と、ユーザー情報送信部24と、アプリケーション実行部25と、ユーザー情報要求部26と、を含んで構成されている。これらの機能のうち、ユーザー情報記憶部21はユーザー管理サーバ2の記憶部12によって実現される。ユーザー情報登録部22、ユーザー情報要求受付部23、及びユーザー情報送信部24は、ユーザー管理サーバ2の制御部11が記憶部12に格納されたプログラムを実行することにより実現される。このプログラムは、光ディスク等の各種の情報記憶媒体に記憶されてユーザー管理サーバ2に提供されてよい。また、インターネット等の通信ネットワークを介して提供されてもよい。アプリケーション実行部25及びユーザー情報要求部26は、クライアント装置3が内蔵されたメモリに記憶されたプログラムを実行することにより実現される。
ユーザー情報記憶部21は、本実施形態のサービスを利用するユーザーの情報を記憶する。具体的に、ユーザー情報記憶部21は、各ユーザーについて、当該ユーザーの名称情報、当該ユーザーのプロフィール画像のデータ、及び当該ユーザーの友人として登録されたユーザー(以下、フレンドユーザーという)を特定する情報を記憶している。図3は、ユーザー情報記憶部21が記憶する情報の一例を示している。
特にユーザー情報記憶部21は、各ユーザーの名称情報として、識別名称N1と公開制限名称N2の2種類の名称を記憶している。識別名称N1は、情報処理システム1が各ユーザーを一意に識別するために用いられる名称であって、システム内で互いに重複することが許されない。つまり、ユーザーは既に使用されているものと同じ識別名称N1を使用することができず、自分の使用したい名称を識別名称N1として使用できない場合も生じる。特に登録ユーザーの数が増大してくると、後から登録するユーザーは自分の識別名称N1として自分が希望する名称を使用することが困難になり、人の目には一見して分かりにくい複雑な名称や長い名称を使用せざるを得なくなる傾向がある。なお、識別名称N1の公開は特に制限されず、他のユーザーから参照可能になっている。
公開制限名称N2は、識別名称N1と異なり複数ユーザー間で重複することが許され、各ユーザーが任意に登録することのできる名称である。本サービスでは、公開制限名称N2として各ユーザーの実名を登録することが想定されている。実名は、たとえフレンドユーザーに対してであっても公開したくない場合があり得る。そのため本実施形態では、公開制限名称N2の公開は制限され、その参照は、フレンドユーザーの中でも限られた特定のユーザー(以下、公開対象ユーザーという)に対してのみ許可される。なお、ユーザー情報記憶部21は、各ユーザーのフレンドユーザーを特定する情報だけでなく、フレンドユーザーのうちどのユーザーが公開対象ユーザーであるかを特定する情報も記憶している(図3参照)。
名称情報に対応して、ユーザー情報記憶部21は各ユーザーのプロフィール画像についても2種類の画像データを記憶する。すなわち、アバター画像等の第1画像(以下、アイコン画像I1という)とユーザーが登録した第2画像(以下、写真画像I2という)である。アイコン画像I1は、予めシステムで用意された候補画像の中からユーザーが選択した画像であって、他のユーザーと重複する可能性もある。なお、情報処理システム1はアイコン画像I1そのものを候補画像として用意するのではなく、アイコン画像I1に含まれるキャラクターのパーツ(顔や髪、服、背景など)を予め選択肢として用意しておいてもよい。この場合各ユーザーは、これらのパーツを選択し、組み合わせて自身のアイコン画像I1を生成する。あるいは、アイコン画像I1はユーザーがアップロードした画像であってもよい。
一方で写真画像I2は、ユーザーがアップロードして登録した画像データであって、ユーザー自身を撮影した写真であることが想定されている。そのため写真画像I2は、公開制限名称N2と同様に公開対象ユーザーに対してのみ公開される。なお、アイコン画像I1と写真画像I2とは、同じサイズ、及びフォーマットの画像データであることが望ましい。
ユーザー情報登録部22は、ユーザー情報記憶部21が記憶する情報の登録を受け付ける。具体的に、ユーザーが最初に本サービスの利用を開始する場合には、自身が所持するクライアント装置3を操作して、ユーザー管理サーバ2のユーザー情報登録部22に対してユーザー登録の要求を行う。このときユーザーは、まず自身の識別名称N1を入力し、ユーザー管理サーバ2に送信する。また、新規ユーザー登録の際、あるいはその後任意のタイミングで、自身の公開制限名称N2、アイコン画像I1、及び写真画像I2についても登録する。これらユーザーが登録した情報が、ユーザー情報記憶部21に記憶される。
さらにユーザー情報登録部22は、各クライアント装置3からの要求に応じて、ユーザー間のフレンドとしての関係を示す情報についても登録する。具体例として、ユーザーU1がユーザーU2に対してフレンドとしての登録を申し込む場合、ユーザーU1の使用するクライアント装置3は、ユーザーU1の指示操作に応じてフレンド登録申請のメッセージをユーザーU2のクライアント装置3に対して送信する。これに対してユーザーU2がフレンド登録を了承する操作を行うと、その内容がユーザー管理サーバ2に通知される。これを受けてユーザー情報登録部22は、ユーザーU1とユーザーU2とがフレンドとなった旨をユーザー情報記憶部21に記憶する。なお、フレンド登録申請のメッセージは直接クライアント装置3間で送受信されてもよいし、ユーザー管理サーバ2、又はその他のメッセージ中継サーバを経由して相手先のクライアント装置3に送信されてもよい。
公開対象ユーザーとしての登録についても、フレンド登録と同様にして行われる。具体例として、ユーザーU1がユーザーU2の公開対象ユーザーとなることを希望する場合、ユーザーU1が操作するクライアント装置3は、ユーザーU2のクライアント装置3に対して、公開対象ユーザー登録を申請するメッセージを送信する。ユーザーU2がこれを了承する操作を行うと、その内容がユーザー管理サーバ2に対して通知される。これを受けてユーザー情報登録部22は、ユーザーU1の公開対象ユーザーにユーザーU2を加えるとともに、ユーザーU2の公開対象ユーザーにユーザーU1を加える登録処理を実行する。なお、ここでは公開対象ユーザーとしての登録は複数ユーザー間で相互にセットで行うこととしている。つまり、ユーザーU1がユーザーU2の公開対象ユーザーとなる場合、必ずユーザーU2もユーザーU1の公開対象ユーザーとなることとしている。しかしながらこれに限らず、一個の申請では一方のユーザーだけが他方のユーザーの公開対象ユーザーとして登録され、その逆の登録を行うためには別途の申請が必要であることとしてもよい。なお、本実施形態では前述の通り、公開対象ユーザーとしての登録は既にフレンドユーザーとして登録されたユーザーでなければ行えないこととしている。また、公開対象ユーザー登録申請のメッセージは、フレンド登録申請のメッセージと同様に、直接クライアント装置3間で送受信されてもよいし、ユーザー管理サーバ2、又はその他のメッセージ中継サーバを経由して相手先のクライアント装置3に送信されてもよい。
さらにユーザー情報登録部22は、各ユーザーの公開制限名称N2や写真画像I2を含むプロフィール情報を、外部のソーシャルネットワーキングサービス(以下、外部SNSという)から取得してもよい。外部SNSの中には、インターネット等の通信ネットワークを介して自身が管理する情報を提供するためのインタフェースを備えるものがある。このようなインタフェースを利用することによって、ユーザー情報登録部22は、各ユーザーにわざわざ写真画像I2等の登録操作を行わせずとも、外部SNSに既に登録された情報を取得して本システムにおけるユーザー情報として登録することができる。この場合ユーザーは、外部SNSのユーザーIDやパスワード等の認証情報を入力することにより、ユーザー情報登録部22に対して外部SNSから情報を取得するよう指示する。これを受けてユーザー情報登録部22は、外部SNSにアクセスし、ユーザーが指示する情報の提供を要求する。特に実名での利用が前提とされている外部SNSにアクセスすることによって、ユーザー情報登録部22は、ユーザーの公開制限名称N2や写真画像I2等の情報を取得することができる。
また、ユーザー情報登録部22は、フレンドユーザーとして登録すべきユーザーの情報を外部SNSから取得してもよい。一般に外部SNS内では、そのサービスを利用しているユーザー間で既にフレンド登録が行われている。そして、あるユーザーが許可すれば、そのユーザーのフレンドとして登録されているユーザーの情報を提供するためのインタフェースを備えている場合がある。この場合ユーザー情報登録部22は、外部SNSのアカウント情報と本システムのユーザー識別名称N1とを関連づけて記憶するとともに、ユーザーの許諾に基づいて外部SNS内でフレンド登録されたユーザーの情報を取得する。これによりユーザー情報登録部22は、あるユーザーから許諾があった場合に、外部SNS内で当該ユーザーのフレンドとして登録され、かつ、本サービスを既に利用しているユーザーを検索し、本サービス内におけるフレンドユーザーとして登録することができる。
この場合の処理例について、図4のフロー図を用いて説明する。この例では、ユーザーU1とユーザーU2とが外部SNS内でフレンド登録されており、ユーザーU1は自身の外部SNSにおけるアカウントと本システムのアカウントとを既に紐付けているものとする。ここでユーザーU2が自身のクライアント装置3を操作して新たに本システムに対してユーザー登録を行い(S1)、かつ外部SNSのアカウント情報を入力して外部SNSでフレンド登録されたユーザーの情報を取得するよう指示したとする(S2)。この場合ユーザー情報登録部22は、外部SNSに問い合わせを行って、ユーザーU2のフレンドとして登録されたユーザーのアカウント情報を取得する(S3)。その中には、ユーザーU1のアカウント情報も含まれている。さらにユーザー情報登録部22は、取得した外部SNSのアカウント情報が既に本システムのユーザーに紐付けて登録されているか否かを検索する(S4)。ここではユーザーU1について外部SNSのアカウント情報が登録されているので、ユーザー情報登録部22はユーザーU1をユーザーU2のフレンドとして抽出し、ユーザーU1とユーザーU2とを本サービスにおけるフレンドとして登録する(S5)。
さらに、このようにしてフレンド登録を行った場合、ユーザー情報登録部22は、外部SNSに対する問い合わせに基づいてフレンド登録されたユーザーを、自動的に公開対象ユーザーとして登録することとしてもよい。前述したように、外部SNSの中には実名での利用を前提としたものがあり、このような外部SNSにおいて互いにフレンドとして登録されたユーザー同士は、お互いに自分の実名や顔写真を相手に公開することに同意していると考えられる。そのため、このような特定の外部SNSから取得したフレンド情報に基づいて本システム内でフレンド登録されたユーザー同士については、自動的にお互いを公開対象ユーザーとして登録することとする(S6)。こうすれば、わざわざユーザー同士で公開対象ユーザーとしての登録申請、及びその承認といった操作を行わずに、公開対象ユーザーとしての登録を行うことができる。
ユーザー情報要求受付部23は、各クライアント装置3のユーザー情報要求部26から、ユーザー情報の提供要求を受け付ける。ここでユーザー情報の提供要求には、送信元のユーザー(以下、要求ユーザーという)を特定する情報、及び提供要求の対象となるユーザー(以下、要求対象ユーザーという)を特定する情報が含まれている。本実施形態では、各クライアント装置3のアプリケーション実行部25は、ゲーム等のアプリケーションプログラムを実行し、その実行中にフレンドユーザーの情報を表示する。例えばユーザーU1がユーザーU2と一緒にオンラインゲームをプレイする場合、ユーザーU1のクライアント装置3には、ユーザーU2が操作するキャラクターに付随して、ユーザーU2の名称とプロフィール画像とが表示される。このような表示を実現するために、ユーザーU1が使用するクライアント装置3のユーザー情報要求部26は、アプリケーション実行部25からの指示に応じて、ユーザー情報要求受付部23に対してユーザーU2の名称及びプロフィール画像の提供要求を送信する。
ユーザー情報送信部24は、ユーザー情報要求受付部23が受け付けたユーザー情報の提供要求に応じて、要求対象ユーザーの情報を要求元のクライアント装置3に対して送信する。このときユーザー情報送信部24は、要求ユーザーと要求対象ユーザーとの間の関係に応じて、提供するユーザー情報の種類を変更する。
具体的に、要求ユーザーから要求対象ユーザーの名称情報の提供要求があった場合、ユーザー情報送信部24は、要求対象ユーザーが要求ユーザーの公開対象ユーザーとしてユーザー情報記憶部21に登録されているか否かを判定する。公開対象ユーザーとして登録されていれば、ユーザー情報送信部24は、名称情報の提供要求に対して公開制限名称N2を送信する。一方、要求対象ユーザーが要求ユーザーの公開対象ユーザーとして登録されていない場合、ユーザー情報要求送信部24は、名称情報の提供要求に対して識別名称N1を送信する。これにより、要求対象ユーザーの公開制限名称N2が、公開対象ユーザーとして登録されていない要求ユーザーに公開されてしまわないようにすることができる。要求ユーザーから要求対象ユーザーのプロフィール画像の提供要求があった場合にも、ユーザー情報送信部24は同様の判定を行う。そして、要求対象ユーザーが要求ユーザーの公開対象ユーザーとして登録されていれば、ユーザー情報送信部24はプロフィール画像の提供要求に対して写真画像I2を送信する。一方、公開対象ユーザーとして登録されていなければ、プロフィール画像の提供要求に対してアイコン画像I1を送信する。
特に本実施形態では、ユーザー情報送信部24は、名称及びプロフィール画像の提供要求に対して、必ず識別名称N1とアイコン画像I1の組み合わせか、又は公開制限名称N2と写真画像I2の組み合わせか、のいずれかを送信することとする。そのため、仮に要求対象ユーザーの写真画像I2が登録されていない場合であっても、公開対象ユーザーからの提供要求に対して公開制限名称N2とともにアイコン画像I1を送信することはしない。このような制御を行うのは、以下のような理由による。公開制限名称N2は他のユーザーと重複が可能であり、アイコン画像I1も予め用意された画像、又は予め用意されたパーツの組み合わせによって生成される画像であるため、他のユーザーと重複する可能性がある。そのため、このような組み合わせでの提供を許してしまうと、他のユーザーへのなりすましが容易にできてしまうおそれがある。そこで本実施形態では、上述したような名称とプロフィール画像の組み合わせでユーザー情報を提供することとしている。なお、ユーザーが写真画像I2の登録を行っていない場合には、ユーザー情報送信部24は、公開対象ユーザーからの情報提供要求に対しては公開制限名称N2とともに写真画像I2が存在しない旨を送信する。これを受けてクライアント装置3は、要求対象ユーザーのプロフィール画像の代わりに予め用意されたデフォルト画像Id(例えばシルエット画像)を表示する。
クライアント装置3のアプリケーション実行部25は、アプリケーションプログラムを実行し、その実行結果を示す画像を表示画面に表示する。特に本実施形態では、アプリケーション実行部25は、ゲームやメッセージ交換等のアプリケーションプログラムを実行し、その実行結果としてフレンドユーザーのユーザー情報(名称情報及びプロフィール画像)を含む画像を表示画面に表示する。このときアプリケーション実行部25は、表示すべきユーザー情報の取得を、ユーザー情報要求部26に指示する。
ユーザー情報要求部26は、アプリケーション実行部25からの指示に応じて、ユーザー情報の取得要求をユーザー管理サーバ2のユーザー情報要求受付部23に対して送信する。その際にユーザー情報要求部26は、当該クライアント装置3を使用するユーザー(すなわち、要求ユーザー)を特定する情報とともに取得要求を送信する。そして、この取得要求に対する応答としてユーザー情報送信部24から送信されてきたユーザー情報を、アプリケーション実行部25に対して提供する。これによりアプリケーション実行部25は、ユーザー管理サーバ2が提供する識別名称N1及び公開制限名称N2のいずれかの名称情報を含む画像を表示画面に表示する。
以下、クライアント装置3のアプリケーション実行部25が生成、表示するユーザー情報の具体例について、図5のフロー図及び図6の表示例を用いて説明する。図6は、ユーザーU3のクライアント装置3の表示画面に表示されるゲーム画像の一例を示している。ここではユーザーU1、U2及びU3の3人が一緒にレースゲームをプレイしており、ゲーム画像内にはそれぞれユーザーU1及びU2が操縦するレースカーC1及びC2が表示されている。また、レースカーC1及びC2のそれぞれに対して、そのレースカーを操縦するユーザーの名称情報と画像とを含むユーザー情報P1及びP2が表示されている。ここで、ユーザーU1及びU2はいずれもユーザーU3のフレンドユーザーであるが、ユーザーU3はユーザーU1の公開対象ユーザーとして登録されている一方で、ユーザーU2の公開対象ユーザーとしては登録されていないものとする。
この例では、ユーザーU3のクライアント装置3において、まずアプリケーション実行部25がユーザーU1及びユーザーU2を要求対象ユーザーとしてユーザー情報の取得をユーザー情報要求部26に対して指示する(S11)。これに応じてユーザー情報要求部26は、要求ユーザーであるユーザーU3を特定する情報とともに、ユーザーU1及びユーザーU2を要求対象ユーザーとして指定したユーザー情報の提供要求をユーザー管理サーバ2のユーザー情報要求受付部23に対して送信する(S12)。これに対してユーザー情報送信部24は、要求対象ユーザーであるユーザーU1及びユーザーU2のそれぞれについて、ユーザーU3が公開対象ユーザーとして登録されているか否か判定する(S13)。ここではユーザーU1のみがユーザーU3を公開対象ユーザーとしているので、ユーザー情報送信部24は、ユーザーU3の提供要求に対してユーザーU1の公開制限名称N2及び写真画像I2を送信する(S14)。逆にユーザーU2についてはユーザーU3を公開対象ユーザーとしていないので、ユーザー情報送信部24は、ユーザーU2の識別名称N1とアイコン画像I1を送信する(S15)。ユーザーU3のクライアント装置3において、ユーザー情報要求部26は、ユーザー情報送信部24からS14及びS15で送信されるユーザー情報の提供を受け付けて、その内容をアプリケーション実行部25に対して出力する(S16)。アプリケーション実行部25は、提供されたユーザー情報を含むゲーム画像を生成し、表示画面に表示する(S17)。なお、クライアント装置3は、ユーザー情報送信部24から提供された名称情報が公開制限名称N2か識別名称N1かを区別する必要はなく、提供された名称の文字列情報をそのまま画面に表示すればよい。同様に、ユーザーのプロフィール画像についても、それが写真画像I2かアイコン画像I1かを区別する必要はなく、提供された画像を所与のサイズに変換して画面に表示する。これにより図6に示すように、ユーザーU3に対して公開制限名称N2及び写真画像I2の公開が許可されているユーザーU1については、それらの情報がゲーム画像内に表示される。そのためユーザーU3は、一目でレースカーC1を操縦しているのが自分の知人であるユーザーU1であることを把握できる。
別の例として、図7は、フレンド一覧の表示画面の一例を示している。このような表示画面は、アプリケーション実行部25がフレンドユーザーを管理するアプリケーションプログラムを実行することにより表示される。この図の例は、ユーザーU3のクライアント装置3が表示するフレンド一覧を示しており、ユーザーU3のフレンドユーザーとして、ユーザーU1、ユーザーU2、及びユーザーU4のユーザー情報P1、P2及びP4が並んで表示されている。これらのフレンドユーザーのうち、ユーザーU1及びU4がユーザーU3を公開対象ユーザーとしており、ユーザーU2はユーザーU3を公開対象ユーザーとしていないものとする。同図に示されるように、ユーザーU2についてはユーザー情報P2として識別名称N1及びアイコン画像I1のみが表示され、ユーザーU1については、識別名称N1及びアイコン画像I1だけでなく、公開制限名称N2及び写真画像I2も併せて表示されている。また、ユーザーU4については、写真画像I2が登録されていないために、写真画像I2が表示されるべき位置にデフォルト画像Idが表示されている。特にこの図の例では、ユーザーU2の識別名称N1とユーザーU1及びU4の公開制限名称N2とが縦方向に同じ位置に並んで表示され、同様にユーザーU2のアイコン画像I1、ユーザーU1の写真画像I2、及びユーザーU4についてのデフォルト画像Idとが同じ位置に同じサイズで並んで表示される。そして、ユーザーU1及びU4の識別名称N1及びアイコン画像I1については、付随的に公開制限名称N2や写真画像I2よりも小さなサイズで表示されている。これは、ユーザーU3を公開対象ユーザーとしているユーザーU1及びU4については、識別名称N1及びアイコン画像I1に代わる情報として公開制限名称N2及び写真画像I2が用いられていることを示している。
また、ユーザー管理サーバ2は、特定のユーザーのユーザー情報を、当該ユーザーと一緒にゲームをプレイしているフレンドユーザーに限らず、不特定の要求ユーザーに対して提供してもよい。さらにこのような場合には、要求ユーザーが要求対象ユーザーの公開対象ユーザーであるか否かにかかわらず、公開制限名称N2を提供してもよい。このような場合に提供される名称情報は、特定の個人と結びつかないと考えられるからである。あるいは、ユーザー情報送信部24は、不特定の要求ユーザーから要求対象ユーザーの名称情報の取得要求があった場合、公開制限名称N2の一部分だけを提供してもよい。具体的には、ファーストネーム、及びファミリーネームから構成される公開制限名称N2について、そのファーストネームだけを提供する、ファミリーネームだけを提供する、ファーストネーム及びファミリーネームそれぞれの頭文字だけを提供する、ファーストネーム及びファミリーネームの一方の頭文字と他方のフルネームの組み合わせを提供する、などの処理を行ってもよい。こうすれば、個人が一意に特定されにくい態様で特定のユーザーの公開制限名称N2に関する情報を提供できる。このような制御の一例として、ゲーム内に登場する特殊なモンスターやアイテムについて、その名前としてゲーム内で最初に発見したユーザー(発見者)の名称を付けるケースが考えられる。このような名前は固有名詞として機能するので、発見者の公開対象ユーザーとして登録されているユーザーと登録されていないユーザーとで名前が異なってしまうのは好ましくない。かといって、公開対象ユーザーとして登録されていないユーザーに対して公開制限名称N2の全体を公開してしまうことも不都合が生じる可能性がある。そこでこのような場合には、公開制限名称N2の一部分だけを提供することとする。
一例として、ユーザーU1がゲーム内で特定のモンスターを最初に発見した場合、当該ユーザーU1を特定する情報がゲームサーバ4に送信される。ゲームサーバ4は、ユーザー管理サーバ2のユーザー情報要求受付部23に対して、ユーザーU1の名称情報の取得要求を送信する。ゲームサーバ4からユーザー情報の取得要求が行われた場合、要求ユーザーが特定されていないので、ユーザー情報送信部24は、公開対象ユーザーか否かの判断を行うことなく要求対象ユーザー(ここではユーザーU1)の公開制限名称N2を加工し、その一部分だけをゲームサーバ4に対して送信する。公開制限名称N2の一部分の情報を取得したゲームサーバ4は、ユーザーU1が発見したモンスターに対して、取得した公開制限名称N2の部分を含む名称を決定し、各クライアント装置3に対して送信する。
また、別の例として、ゲームで特定の成績を残したユーザーの情報を、各クライアント装置3の表示画面に表示することが考えられる。具体例として、ユーザーU1がレースゲームにおいて、あるコースの特定のコーナーで優れた成績を残したものとする。このとき、このコーナーに関連づけて、ユーザーU1の名称を表示する(図6のX)。この場合、ユーザーU1の公開対象ユーザーが使用するクライアント装置3では、ユーザーU1の公開制限名称N2が表示され、それ以外のユーザーが使用するクライアント装置3では、公開制限名称N2の代わりにユーザーU1の識別名称N1が表示されることとしてもよい。このような制御を実現するためには、コーナーに表示すべきユーザーを特定する情報(当該ユーザーの識別名称N1)を、ゲームサーバ4が保持しておく。そして、各クライアント装置3のアプリケーション実行部25は、当該コーナーをゲーム画像内に表示する場合、表示すべきユーザーを特定する情報をまずゲームサーバ4に対して問い合わせて取得する。その後、特定されたユーザーの名称情報の取得を、前述したようにユーザー情報要求部26に指示する。そして、この指示に応じて取得された識別名称N1及び公開制限名称N2のいずれかを、当該コーナーに表示する。
また、クライアント装置3のアプリケーション実行部25がアドベンチャーゲームのように複数の選択肢からユーザーがいずれかの選択肢を選択することによってストーリーが進行するゲームのアプリケーションプログラムを実行する場合、アプリケーション実行部25は、当該クライアント装置3を使用するユーザーのフレンドユーザーが選んだ選択肢の情報をゲーム画面内に表示してもよい。図8はこの場合のゲーム画面の一例を示している。この図の例では、選択肢A及びBのいずれかを選ぶようユーザーに促す画面が表示されており、二つの選択肢のうち選択肢Aを選んだユーザーが何人いるかを示す情報とともに、そのうちのフレンドユーザーについて、その名称情報及びプロフィール画像が表示されている。この場合にアプリケーション実行部25は、当該クライアント装置3のユーザーがそのフレンドユーザーの公開対象ユーザーに設定されていれば公開制限名称N2及び写真画像I2を、設定されていなければ識別名称N1及びアイコン画像I1を、それぞれ取得して表示する。
また、ユーザー情報送信部24は、要求ユーザーが要求対象ユーザーの公開対象ユーザーに設定されているか否かだけでなく、要求元のアプリケーション実行部25で実行されているアプリケーションプログラムに応じて、提供する名称情報やプロフィール画像を切り替えてもよい。具体例として、例えばオンライン対戦型のFPS(First Person Shooting)ゲームのような特定の種類のゲームでは、対戦相手となる他のユーザーが操作するゲームキャラクターを攻撃したり、そのゲームキャラクターから攻撃を受けたりすることがある。このような場合、対戦相手の表示画面に表示される自分のゲームキャラクターに対して、自分の実名や顔写真が併せて表示されることを望まないユーザーもいると考えられる。そこで各ユーザーは、自分の公開制限名称N2や写真画像I2を公開対象とするユーザーだけでなく、公開対象とするアプリケーションプログラムについても指定できるようにする。
図9は、この場合においてユーザー情報記憶部21が記憶する情報の一例を示す図である。この図の例は、図3の例と比較して、各ユーザーに関連づけて公開対象プログラムの情報がさらに記憶されている点で異なっている。公開対象プログラムの指定の方法としては、アプリケーションプログラムの種類(例えばゲームプログラム全体、あるいは特定ジャンルのゲームプログラムなど)ごとに指定する方法や、個々のプログラムごと(例えばゲームタイトルごと)に指定する方法がある。例えば各ユーザーは、全てのゲームプログラムに対して公開制限名称N2及び写真画像I2の公開を制限してもよい。図9ではユーザーU2がこのような指定をしている。この場合、フレンド一覧やメッセージ交換アプリケーションでは相手に対して自分の公開制限名称N2や写真画像I2が公開されるが、ゲーム内ではこのような情報が公開されず、代わりに識別名称N1やアイコン画像I1が表示されることになる。また、各ユーザーは、個別のゲームタイトルごとに公開を制限/許可してもよい。図9では、ユーザーU3がゲームタイトルA及びゲームタイトルBという2種類のゲームタイトルについても公開を許可しており、その他のアプリケーションプログラムについては公開を制限している。逆にユーザーU4は、ゲームタイトルAだけを公開制限の対象としており、その他のアプリケーションプログラムについては公開を許可している。あるいは各ユーザーは、特定のジャンル(例えばFPS)に属するゲームプログラムを対象として公開を制限/許可してもよい。
このような制御を実現するために、クライアント装置3のユーザー情報要求部26は、アプリケーション実行部25からユーザー情報の取得指示を受け付けた場合に、当該取得指示を行ったアプリケーションプログラムに関する情報を含んだユーザー情報の取得要求をユーザー管理サーバ2に対して送信する。ここでアプリケーションプログラムに関する情報は、アプリケーションプログラムのプログラム名や、アプリケーションプログラムの種別(ゲームプログラム、システムプログラムなど)を特定する情報などを含んでよい。ユーザー情報要求受付部23がこの取得要求を受け付けると、ユーザー情報送信部24は、まず前述したように要求ユーザーと要求対象ユーザーとの関係性に基づいて要求ユーザーが要求対象ユーザーの公開対象ユーザーに設定されているか否かを判定する。公開対象ユーザーに設定されていなければ、識別名称N1及びアイコン画像I1を要求元のクライアント装置3に対して送信する。一方、要求ユーザーが要求対象ユーザーの公開対象ユーザーに設定されている場合、さらにユーザー情報送信部24は、取得要求に含まれるアプリケーションプログラムに関する情報と、図9に示す公開対象プログラムの情報とを比較して、取得要求を行ったアプリケーションプログラムが公開対象プログラムに該当するか否かを判定する。判定の結果、公開対象プログラムに該当する場合、ユーザー情報送信部24は、要求対象ユーザーの公開制限名称N2及び写真画像I2をユーザー情報として送信する。一方、公開対象プログラムに該当しない場合、ユーザー情報送信部24は、要求対象ユーザーが公開対象ユーザーに該当しない場合と同様に、要求対象ユーザーの識別名称N1及びアイコン画像I1をユーザー情報として送信する。
また、本実施形態においてクライアント装置3は、アプリケーション実行部25が公開制限された情報(公開制限名称N2及び写真画像I2)を表示画面に表示中か否かを管理する機能を備えてもよい。近年では、クライアント装置3の表示画面に表示されるゲーム画面等を、静止画像や動画像として記録、公開することが行われるようになってきている。そうすると、特定の公開対象ユーザーだけに公開するつもりだった自分の公開制限名称N2や写真画像I2を不特定の第三者に公開されてしまうリスクも生じることになる。そこで本実施形態では、ユーザー管理サーバ2のユーザー情報送信部24がクライアント装置3に対してユーザー情報を送信する際に、そのユーザー情報が公開制限された情報であるか否かを示すフラグ情報を含めることとし、アプリケーション実行部25が表示中の画像を記録する際には、そのフラグ情報の内容に応じて記録処理の内容を制御してもよい。具体例として、クライアント装置3は、公開制限されたユーザー情報をアプリケーション実行部25が表示中の場合、表示画面の静止画像(スクリーンショット)や動画像を記録するプログラムの動作そのものを制限し、記録できないようにしてもよい。あるいは、記録の際にユーザーに対して警告メッセージを出力してもよい。また、公開制限されたユーザー情報を表示中に表示画面の画像を記録した場合、クライアント装置3は、記録した画像に対して公開制限されたユーザー情報が含まれる旨のフラグ情報を付与することとしてもよい。こうすれば、後に多数の画像の中から公開制限されたユーザー情報が含まれる画像を検索、抽出し、削除したり公開を制限したりすることが可能となる。
なお、本発明は以上説明したものに限られない。例えば以上の説明では名称情報とプロフィール画像だけをユーザー管理サーバ2による提供対象としたが、その他の各種のプロフィール情報についても、要求ユーザーが要求対象ユーザーの公開対象ユーザーか否かに応じて異なる種類の情報を提供してもよい。また、クライアント装置3においてユーザー情報を表示するアプリケーションプログラムは、ゲームやメッセージ交換アプリケーションに限られず、各種のものであってよい。
また、以上の説明では各クライアント装置3はユーザー管理サーバ2に対して直接ユーザー情報の取得要求を送信することとしたが、このような要求をゲームサーバ3経由でユーザー管理サーバ2に対して送信してもよい。また、以上の説明ではユーザー管理サーバ2のユーザー情報送信部24は、名称情報の取得要求に対して要求対象ユーザーの識別名称N1及び公開制限名称N2のいずれかを送信することとしたが、識別名称N1は必ずしも送信せずともよい。なぜなら、以上説明した実施形態では識別名称N1はユーザーの識別に用いられる情報であるため、要求対象ユーザーの名称情報を取得しようとするクライアント装置3にとって既知の情報であるからである。この場合、ユーザー情報送信部24は、要求ユーザーが要求対象ユーザーの公開対象ユーザーであるか否かを判定し、公開対象ユーザーであると判定される場合にのみ、要求対象ユーザーの公開制限名称N2を送信する。そして、要求ユーザーが要求対象ユーザーの公開対象ユーザーでない場合には、その旨を示す情報(すなわち、公開制限名称N2が送信できないことを示す情報)を名称情報の代わりに要求元のクライアント装置3に送信する。この情報を受けて要求元のクライアント装置3のユーザー情報要求部26は、要求対象ユーザーの名称情報として、取得要求の送信時に取得要求に含めた要求対象ユーザーの識別名称N1をアプリケーション実行部25に対して出力する。この場合にもアプリケーション実行部25は、要求ユーザーが要求対象ユーザーの公開対象ユーザーであれば公開制限名称N2を表示し、公開対象ユーザーでなければ公開制限名称N2の代わりにユーザーの名称情報として識別名称N1を表示画面に表示することができる。