【文献】
坂本 寛,facebookを100倍活用する本,日本,株式会社アスペクト 高比良 公成,2011年 4月 4日,第1版,p.24〜27
(58)【調査した分野】(Int.Cl.,DB名)
利用者のサービスの利用内容を示す利用情報及び前記所定の対象について利用者によって当該管理装置に登録された登録情報のうち少なくとも一方を管理する情報管理部を備え、
前記活動情報には、前記利用情報と前記登録情報との少なくとも一方が含まれ、
前記評価部は、前記利用情報と前記登録情報との少なくとも一方に基づいて、前記第1の特定利用者について前記所定の対象に関する活動を評価する、
ことを特徴とする請求項2乃至5のうちいずれか1項に記載の管理装置。
【発明を実施するための形態】
【0026】
以下、実施形態として、本発明に係る管理サーバを用いたサービス提供システムについて、図面を参照しつつ説明する。
<第1実施形態>
<1.サービス提供システムの構成>
図1は、本発明の実施形態に係るサービス提供システム100のブロック図である。このサービス提供システム100は、インターネットなどの通信網NETを介して、ゴルフ情報サービスやコミュニティサービス等(以下、単に「ゴルフ情報サービス」と称する。)を提供する管理サーバ(管理装置)1、利用者の端末装置2、SNSサイトを提供する外部管理サーバ(外部管理装置)3を備える。以下の説明では、管理サーバ1の提供するゴルフ情報サービスを利用する者をゴルフ利用者(第1サービス利用者)、外部管理サーバ3のSNSの利用者をSNS利用者(第2サービス利用者)と称する。
外部管理サーバ3が提供するSNSサイトは、利用者同士のコミュニケーションツール(すなわち、利用者の間で行われるメッセージ管理情報の授受システム。例えば、掲示板、メール、チャット等)を提供する。また、SNSサイトにおいて、友達関係は、アクション元のSNS利用者が友達申請を行い、これをアクション先のSNS利用者が承認することによって構築される。外部管理サーバ3は、SNS利用者同士の特定の関係であるSNS友達関係を示すSNS友達情報(特定関係情報,第2特定関係情報)を管理する。
【0027】
利用者の端末装置2は、通信網NETを介した通信が可能であり、例えば、パーソナルコンピュータ、携帯電話機、スマートフォン、タブレット端末などが該当する。
管理サーバ1は、特定のサービスを提供する。本実施形態の管理サーバ1は、ゴルフ情報サービスをゴルフ利用者に提供する。ここでは、本実施形態では、ゴルフ情報サービスの提供を一例と説明するが、管理サーバ1は、ゲームなどのアプリケーションの提供、ホテルの予約などを含む旅行情報の提供、コンサート情報の提供、物品の販売等の各種サービスを提供するものであってもよい。すなわち、管理サーバ1は、利用者に所定の対象についてサービスを提供するものである。
【0028】
外部管理サーバ3が提供するSNS(第2サービス)においては、掲示板、メール、チャット等を利用することができるだけでなく、ゲームや実用的なツールなどのソーシャルアプリケーションを利用することができる。このソーシャルアプリケーションは、前記SNSの提供者以外の提供者によっても提供されることがあり、ソーシャルアプリケーションを利用するか否か、あるいは、どのソーシャルアプリケーションを利用するかは、SNS利用者が任意に決定できるようになっている。SNS利用者がソーシャルアプリケーションの利用を希望する場合には、当該ソーシャルアプリケーションが当該SNS利用者のプロフィール情報やSNS上の前記友達情報にアクセスする機能や、当該ソーシャルアプリケーションが当該SNS利用者の代わりに掲示板等に投稿する機能等についての許可を求める場合がある。ソーシャルアプリケーションによっては、SNS利用者がこれらの機能について許可したことを以って、当該ソーシャルアプリケーションの利用者になる場合がある。このようなソーシャルアプリケーションは、一般に、SNSサイト内に当該ソーシャルアプリケーションの画面が表示されるため、SNS利用者にとっては、あたかもSNS(第2サービス)のサービスの一つを利用しているような感覚で、ソーシャルアプリケーションを利用することになる。
【0029】
本実施形態の管理サーバ1によって提供されるゴルフ情報サービス(第1サービス)は、一例として、上述のようなソーシャルアプリケーションにより提供されるサービスである。本実施形態においては、SNS利用者がゴルフ情報サービスの利用者であるゴルフ利用者になるためには、ゴルフ情報アプリケーションが当該SNS利用者のプロフィール情報やSNS上の前記友達情報にアクセスする機能や、ゴルフ情報アプリケーションが当該SNS利用者の代わりに掲示板等に投稿する機能等についての承認を行うようになっている。SNS利用者がこの承認を行うことにより、当該SNS利用者はゴルフ利用者となる。
【0030】
ゴルフ利用者は、
図2に示すようにSNS利用者に含まれる。換言すれば、管理サーバ1は、ゴルフ利用者にゴルフ情報サービス(第1サービス)を提供し、外部管理サーバ3のSNS利用者に限って、管理サーバ1のゴルフ利用者として登録する。一方、外部管理サーバ3は、ゴルフ利用者を含むSNS利用者に対してSNS(第2サービス)を提供する。つまり、ゴルフ利用者は常にSNS利用者であるが、SNS利用者の中にはゴルフ利用者でない者もいる。言い換えれば、ゴルフ利用者の集合はSNS利用者の集合に含まれるため、第1実施形態の管理サーバ1は、ゴルフ利用者の友達関係をSNS利用者の友達関係を用いて管理する。
ここで、所定のゴルフ利用者(所定の利用者)とSNS上の友達関係にある者を「直接SNS友達Uf1」と称する。また、直接SNS友達Uf1とSNS上で友達関係にある者を「間接SNS友達Uf2」と称する。ただし間接SNS友達には、所定のゴルフ利用者及び所定のゴルフ利用者の直接SNS友達に該当する者は含まないものとする。
また、直接SNS友達Uf1であってゴルフ利用者である者を「直接ゴルフ友達Ug1(第1の特定利用者)」と称し、間接SNS友達Uf2であってゴルフ利用者である者を「間接ゴルフ友達Ug2(第2の特定利用者)」と称する。
【0031】
そして
図2に示すように、管理サーバ1は直接ゴルフ友達Ug1及び間接ゴルフ友達Ug2を管理する。なお、本実施形態において「管理する」とは、SNS利用者に関するSNS利用者情報、ゴルフ利用者に関するゴルフ利用者情報、SNS利用者の友達関係を示すSNS友達情報その他のゴルフ利用者の友達関係を管理するために必要な情報のすべてを、外部の管理サーバ装置等の装置に記憶させておき、当該装置と通信して上記情報を要求(参照)することによりゴルフ利用者の友達関係を把握(特定)可能とすることを意味する。後に詳述するが、本実施形態では、管理サーバ1は、ゴルフ利用者情報テーブルTBL11を記憶しており、外部管理サーバ3が記憶するSNS利用者情報テーブルTBL31及びSNS友達情報テーブルTBL32を参照することにより、直接ゴルフ友達Ug1及び間接ゴルフ友達Ug2を特定する。ただし、他の実施形態において「管理する」とは、SNS利用者に関するSNS利用者情報、ゴルフ利用者に関するゴルフ利用者情報、SNS利用者の友達関係を示すSNS友達情報その他のゴルフ利用者の友達関係を管理するために必要な情報のすべてを自己の記憶部に保持しておき、当該記憶部から上記情報を呼び出すことによりゴルフ利用者の友達関係を把握(特定)可能とすることであってもよい。
【0032】
図1を参照して、管理サーバ1の機能を説明する。管理サーバ1は、ゴルフ利用者情報テーブルTBL11、表示基準情報Gref、活動データベースDB、第1個別ログファイルFL1、第2個別ログファイルFL2、ポイントテーブルTBLp、係数テーブルTBLk及び管理サーバ1を制御するプログラムを記憶した記憶部17を備える。
ゴルフ利用者情報テーブルTBL11には、ゴルフ利用者を一意に識別する識別情報UIDなどが格納されている。活動データベースDBには、ゴルフ(所定の対象)に関する活動を示す活動情報が記録されている。活動情報は、ゴルフ利用者のサービスの利用内容を示す利用情報とゴルフの活動についてゴルフ利用者が管理サーバ1に登録した登録情報とが含まれる。登録情報には、ラウンド頻度、練習頻度、及び所有クラブなどが含まれる。登録情報テーブルTBLaには登録情報がゴルフ利用者の識別情報UIDと対応づけて記録されている。
【0033】
ゴルフ利用者のサービスの利用内容には、様々なものが含まれる。例えば、あるゴルフ利用者がゴルフに行ってきたことやクラブの購入などをゴルフ報告として投稿したり、あるゴルフ利用者が他のゴルフ利用者の投稿に対してコメントしたり、あるいは、ゴルフニュースに対してコメントする場合、さらには、あるゴルフ利用者が他のゴルフ利用者をゴルフに誘うといったアクションがある。本実施形態では、各種のアクションの主体となるゴルフ利用者の識別情報UIDをアクション元識別情報UID_Fromと称し、アクションの相手方のゴルフ利用者の識別情報UIDをアクション先識別情報UID_Toと称する。利用者ログ管理テーブルTBLbには、アクション元識別情報UID_From、アクション先識別情報UID_To、及びアクションの内容を示す情報などが対応付けられて記録されている。なお、利用者ログ管理テーブルTBLbに記憶される各種の情報は、一定の保持期間(例えば、120日)を経過した後、削除してもよい。
【0034】
次に、第1個別ログファイルFL1は、アクション元識別情報UID_Fromをキーとして利用者ログ管理テーブルTBLbの記憶内容をソートし、ゴルフ利用者ごとに生成される。同様に、第2個別ログファイルFL2は、アクション先識別情報UID_Toをキーとして利用者ログ管理テーブルTBLbの記憶内容をソートし、ゴルフ利用者ごとに生成される。
本実施形態では、ゴルフ利用者が端末装置2を操作して、管理サーバ1が提供するサイトにアクセスすると、端末装置2の表示部には、直接ゴルフ友達Ug1や間接ゴルフ友達Ug2が表示される。この際、上述した活動情報に基づいて、直接ゴルフ友達Ug1や間接ゴルフ友達Ug2のゴルフに関する活動を、上述した活動情報に基づいて評価する。本実施形態における評価は、以下に示す項目1〜項目6について行う。
【0035】
項目1は、実際にゴルフに誘った、あるいは誘われたかである。項目2は、管理サーバ1が提供するアプリケーションにおける所定のゴルフ利用者との交流頻度である。項目3は、管理サーバ1が提供するアプリケーションにおける活動頻度である。項目4は、所定のゴルフ利用者との住んでいる地域の近接の程度である。項目5は、所定のゴルフ利用者との年齢の近接の程度である。項目6は、ゴルフに行く頻度である。
【0036】
ポイントテーブルTBLpには、各項目についてゴルフに関する活動を評価するための基準が記憶されており、ポイントテーブルTBLpを参照することによって、直接ゴルフ友達Ug1や間接ゴルフ友達Ug2の活動が、ポイントに変換される。係数テーブルTBLkには各項目に対応する係数が格納されている。各項目に対応するポイントに所定の係数を乗算し、乗算結果を加算して評価値Hを得る。係数は適宜定めることができるが、本実施形態では、項目1が最も係数が大きく、項目2、項目3、項目4、項目5、項目6の順に係数が小さくなってゆく。
表示基準情報Grefは、評価値に基づいて、これらの友達を画面のどの位置に表示するかを決定するための規則を示す情報である。
【0037】
また、管理サーバ1は、所定の利用者(所定のゴルフ利用者)の端末装置2から所定の利用者の友達関係を表示する要求を受信すると、所定の利用者の識別情報UIDを取得する取得部11と、取得部11で取得した識別情報UIDに基づいて、外部管理サーバ3で管理するSNS友達情報を参照する参照部12と、記憶部17に記憶されているゴルフ利用者の識別情報UID及びSNS友達情報に基づいて、所定の利用者と友達関係を有するSNS利用者のうちゴルフ利用者に該当する者を直接ゴルフ友達Ug1(第1の特定利用者)として特定し、所定の利用者と友達関係を有するSNS利用者と更に友達関係を有するSNS利用者(間接SNS友達Uf2)のうちゴルフ利用者に該当する者を間接ゴルフ友達Ug2(第2の特定利用者)として特定する特定部13と、特定部13で特定した直接ゴルフ友達Ug1及び間接ゴルフ友達Ug2について、ゴルフ(所定の対象)に関する活動を示す活動情報に基づいて、ゴルフに関する活動を評価する評価部14と、評価部14の評価結果に基づいて、端末装置2の表示部の画面上に表示される直接ゴルフ友達Ug1及び間接ゴルフ友達Ug2の位置を決定する決定部15と、決定部15で決定された画面上の位置に直接ゴルフ友達Ug1及び間接ゴルフ友達Ug2を配置した画面を所定の利用者の端末装置2に表示させる表示制御部16とを備える。具体的には、表示制御部16は、決定部15で決定された画面上の位置に直接ゴルフ友達Ug1及び間接ゴルフ友達Ug2を表示するために必要な情報を生成し、当該情報を含む表示応答を所定の利用者の端末装置2に送信する。
本実施形態では、評価の対象を直接ゴルフ友達Ug1及び間接ゴルフ友達Ug2としたが、その一部を評価の対象としてもよく、例えば、直接ゴルフ友達Ug1にのみ着目してもよいし、あるいは、現在から所定時間前までの期間に投稿などの何らかのアクションを行った者のみを評価の対象としてもよい。
【0038】
外部管理サーバ3は、SNS利用者を一意に識別する識別情報、SNS利用者の氏名、及びプロフィール画像のリンク先を示すリンク情報など格納されたSNS利用者情報テーブルTBL31と、SNS利用者の友達関係を示す友達情報が格納されたSNS友達情報テーブルTBL32を備える。このSNS友達情報テーブルTBL32は、SNS(第2サービス)内における友達関係を構築するためのSNS利用者の活動を示したものである。さらに、外部管理サーバ3は、各種のAPI(Application Program Interface)を実行可能であり、管理サーバ1からのパラメータを含む要求を受信すると、SNS利用者情報テーブルTBL31又はSNS友達情報テーブルTBL32から所定の情報を抽出して管理サーバ1に返信するようになっている。
【0039】
管理サーバ1は、各ゴルフ利用者に対してマイページを提供する。マイページには、各種のゴルフに関する情報が集約されて表示される。
図3にマイページの一例を示す。同図に示すように領域Xには、所定の利用者(本人)のプロフィール画像が表示され、領域Y1には、所定の利用者の直接ゴルフ友達Ug1のプロフィール画像が表示され、さらに、領域Y2には、間接ゴルフ友達Ug2のプロフィール画像が表示される。このように、直接ゴルフ友達Ug1と、間接ゴルフ友達Ug2とが、異なる領域Y1及びY2に表示されるので、所定の利用者は、階層的な友達関係を容易に把握することが可能となる。このように、階層的な友達関係を示す関係図をゴルフフレンドマップと称する。
【0040】
この例では、領域Y1に直接ゴルフ友達Ug1(ゴルフ友達GF1〜GF5)が表示されるが、その表示位置は、活動情報に基づいて決定される。すなわち、ゴルフに関する活動を評価し、評価結果が高い直接ゴルフ友達Ug1ほど、領域Y1において領域Xに表示される所定の利用者と最も近い辺りに近づくように表示される。これにより、直接ゴルフ友達Ug1のうち誰がゴルフに熱心であるかを一見して知ることができる。また、領域Y2に表示される間接ゴルフ友達Ug2も、領域Y1に表示されるゴルフ友達と同様に、ゴルフに関する活動を評価し、評価結果に基づいて表示位置が決定される。
【0041】
図4にゴルフ利用者情報テーブルTBL11のデータ構造を示す。ゴルフ利用者情報テーブルTBL11には複数のレコードが記録されている。1つのレコードは、ゴルフ利用者を一意に識別する識別情報UID、登録日、プロフィール情報、及びラウンド履歴情報を含む。本実施形態では、ゴルフ利用者の識別情報UIDは、SNS利用者の識別情報UIDと一致する。但し、SNS利用者の識別情報とゴルフ利用者の識別情報とは必ずしも一致する必要はなく、相違していてもよい。この場合は、ゴルフ利用者情報テーブルTBL11のレコードにSNS利用者の識別情報とゴルフ利用者の識別情報とを対応づけて記録すればよい。
【0042】
プロフィール情報は、性別、年齢、及びメールアドレスを含む。また、ラウンド履歴情報は、プレイしたゴルフ場名、スコア、及びラウンド日を含む。レコードに、その他の情報を記録してもよい。また、ゴルフ利用者情報テーブルTBL11に記憶すべき情報として、ゴルフ利用者の識別情報UIDは必須であるが、その他の情報は省略してもよい。さらに、ゴルフ利用者情報テーブルTBL11をキーとなる情報(例えば、識別情報UID)で紐づけた複数のテーブルで構成し、リレーショナルデータベースとしてもよい。
【0043】
図5に登録情報テーブルTBLaのデータ構造を示す。登録情報テーブルTBLaには複数のレコードが記録されている。1つのレコードは、ゴルフ利用者を一意に識別する識別情報UID、ラウンド頻度、練習頻度、ラウンド経験のあるゴルフ場、及び使用クラブを含む。ここで、ラウンド頻度及び練習頻度は、ランクで示される。
これらの登録情報は、ゴルフ利用者が管理サーバ1に対して登録を行うことによって登録情報テーブルTBLaに記録される。
図6は、端末装置2の表示部に表示される登録画面である。この登録ページは管理サーバ1によって提供される。この例では、ゴルフ場は入力ボックスb1に入力し、ラウンド頻度と練習頻度はプルダウンメニューの項目を選択することにより入力し、クラブは入力ボックスb2に入力することによって登録される。
図7にラウンド頻度及び練習頻度の選択肢1及び選択肢2とランクの関係を示す。例えば、選択肢1が「月に」で選択肢2が「5回以上」の場合、ランクは「6」となり、これがラウンド頻度又は練習頻度として登録情報テーブルTBLaに記録される。
【0044】
図8に利用者ログ管理テーブルTBLbのデータ構造を示す。利用者ログ管理テーブルTBLbには複数のレコードが記録されている。1つのレコードは、レコードを一意に識別するレコードID、各種のアクションの主体となるゴルフ利用者のアクション元識別情報UID_From、アクションの相手方のゴルフ利用者のアクション先識別情報UID_To、アクションの日時を示すタイムスタンプ、アクションの種別を示すアクション種別情報kind、ゴルフ利用者が書き込んだコメント、及びニュースを特定するニュースIDが対応付けられて記録されている。利用者ログ管理テーブルTBLbを参照することによって、誰が(アクション元識別情報UID_From)、誰に(アクション先識別情報UID_To、ニュースID)、いつ(タイムスタンプ)、どんなアクション(アクション種別情報、コメント)を起こしたかを知ることができる。
【0045】
アクション種別情報kindは、以下のように記録される。第1に、ゴルフに誘うボタンを使用して他のゴルフ利用者をゴルフに誘った場合にkind=1が記録される。第2に、報告ボタンを使用してゴルフ報告を投稿した場合にkind=2が記録される。第3に、他のゴルフ利用者のゴルフ報告に対していいねボタンを使用して意思表示をした場合にkind=3が記録される。第4に、他のゴルフ利用者のゴルフ報告に対してコメントボタンを使用してコメントを投稿した場合にkind=4が記録される。第5に、ログインした場合にkind=5が記録される。第6に、ニュースに対していいねボタンを使用して意思表示をした場合にkind=6が記録される。第7に、ニュースに対してコメントボタンを使用してニュースにコメントを投稿した場合にkind=7が記録される。第8に、行きたいボタンを使用してゴルフに行きたいことを意思表示した場合にkind=8が記録される。
なお、ゴルフ報告のアクションやニュースに対するアクションは他のゴルフ利用者に対するものではないので、アクション先識別情報UID_Toは記録されない。
【0046】
本実施形態では、ゴルフ利用者がゴルフに関するコメントを自由に書き込めるようになっており、書き込んだコメントは、ゴルフ報告として所定の利用者(本人)のマイページや、ゴルフ友達のマイページに投稿されるようになっている。
【0047】
図9に端末装置2の表示部に表示されるゴルフ報告の入力画面も一例を示す。アイコンA1とクリックすると、ゴルフ報告の入力ボックスb3が表示される。アイコンA1は上述したゴルフ報告ボタンとして機能するほか、コメントボタンとしても機能する。
入力ボックスb3にコメントを入力して、送信ボタンB6をクリックすると、アクション元識別情報UID_From、アクション種別情報kind、コメント、及びコメント日時が管理サーバ1に送信される。なお、アクション種別情報kindは、管理サーバ1のCPU30が生成してもよい。また、CPU30が利用者ログ管理テーブルTBLbにレコードを追加する際にタイムスタンプを発行してもよく、この場合は、コメント日時を端末装置2から送信しなくてもよい。
【0048】
そして、ゴルフ報告がなされると、所定期間、ゴルフ友達のアイコンに近接して当該ゴルフ友達がゴルフ報告を行ったことを示すアイコンa1が表示される。
図9に示す例では、ゴルフ友達GF2が最近、ゴルフ報告を投稿したことを示している。また、アイコンA2は、「ゴルフに行きたい」といった意思表示をゴルフ友達に伝えるために用いられる。アイコンA2をクリックすると、所定期間、
図9に示すようにゴルフ友達のアイコンに近接して当該ゴルフ友達がゴルフに行きたいことを示すアイコンa2が表示される。この例では、ゴルフ友達GF1が最近、ゴルフに行きたいと希望していることが分かる。アイコンA2は、上述した、行きたいボタンとして機能する。
【0049】
本実施形態では、ゴルフ利用者が自己の意思を表示するためのアイコンをクリックすることも、利用情報に含めて管理する。例えば、ゴルフ友達GF1の識別情報UIDが「2zz99x999」であるとすると、ゴルフ友達GF1がアイコンA2をクリックすると、
図8に示すレコードID=000005に示すレコードが記録される。このレコードには、アクション種別情報kindとして「8」が記録される。なお、この例では、他の投稿と同じ形式でアイコンA2のクリックを管理したが、クリックしたことを示すフラグとクリックした日時を対応づけて利用者ログ管理テーブルTBLbに記録してもよいし、別のテーブルに記録して管理してもよい。
【0050】
図10に、ニュースに対してコメントを投稿するための入力画面の一例を示す。アイコンA3をクリックすると、画面の左側にニュースやゴルフ報告などがタイムラインで表示される。そして、表示された複数のニュースのうち一つを選択すると、同図に示すようにニュースの詳細とコメントの入力ボックスb4が表示される。入力ボックスb4にコメントを入力して、送信ボタンB6をクリックすると、アクション元識別情報UID_From、ニュースID、及びコメントが管理サーバ1に送信される。管理サーバ1は、端末装置2から送信された情報に基づいて、利用者ログ管理テーブルTBLbにレコードを追加する。例えば、アクション元識別情報UID_Fromが「5zz99x999」、ニュースIDが「NEWS0001」であるとすれば、
図8に示すレコードID=000003のレコードが追加される。このレコードには、アクション種別情報kindとして「7」が記録される。また、
図10に示すいいねボタンB10をクリックすると、
図8に示すレコードID=000007のレコードが追加される。このレコードには、アクション種別情報kindとして「6」が記録される。
【0051】
次に、ゴルフに誘うについて説明する。例えば、所定のゴルフ利用者Xが、
図3に示す直接ゴルフ友達Ug1のアイコンGF3をクリックすると、
図11に示すようにアイコンGF3に対応するゴルフ友達をゴルフに誘うための画面がポップアップされる。この例では、領域C1に当該ゴルフ友達のアイコンが表示され、領域C2に当該ゴルフ友達の名前である「佐藤浩一」で表示される。領域C3は、当該ゴルフ友達の投稿があればその内容が表示される。この例では、投稿が無い場合を示している。そして、キャンセルボタンB12をクリックすると、ポップアップ画面がキャンセルされ、
図3に示すゴルフフレンドマップに戻る。
【0052】
一方、ゴルフに誘うボタンB11をクリックすると、
図12に示す画面が表示される。領域C6には「佐藤浩一さんと一緒にゴルフに誘う人を選んでください。」と表示され、さらに、領域C7には、
図3に示すゴルフフレンドマップに表示された直接ゴルフ友達Ug1及び間接ゴルフ友達Ug2のアイコンが表示される。これにより、さらにゴルフに誘うゴルフ利用者を選択するように促される。
【0053】
この後、直接ゴルフ友達Ug1及び間接ゴルフ友達Ug2のアイコンをクリックすると、例えば、
図13に示す画面が表示される。この例では、領域C7に表示されるゴルフ利用者のうち3人が選択される。選択されたゴルフ利用者のアイコンの右上にはチェックマークが表示される。この状態でキャンセルボタンB14をクリックすると、ゴルフに誘うは実行されず、
図3に示すゴルフフレンドマップに戻る。
【0054】
一方、決定ボタンB13をクリックすると、端末装置2のゴルフ利用者の識別情報UIDをアクション元識別情報UID_Fromとし、選択した4人の識別情報UIDをアクション先識別情報UID_Toとし、アクション種別情報kindを「1」とする通知が、端末装置2から管理サーバ3に送信される。管理サーバ3は、当該通知を受信すると、レコードを追加する。例えば、端末装置2のゴルフ利用者(所定のゴルフ利用者)の識別情報UIDを「6zz99x999」とし、佐藤浩一の識別情報を「7zz99x999」とすると、
図8に示すレコードIDが「000010」に対応するレコードが、利用者ログ管理テーブルTBLbに記録される。
【0055】
次に、第1個別ログファイルFL1と第2個別ログファイルFL2について説明する。
第1個別ログファイルFL1は、アクション元識別情報UID_Fromをキーとして利用者ログ管理テーブルTBLbをソートしたものであり、第2個別ログファイルFL2は、アクション先識別情報UID_Toをキーとして利用者ログ管理テーブルTBLbをソートしたものである。例えば、アクション元識別情報UID_Fromが「6zz99x999」であるとすれば、第1個別ログファイルFL1は
図14Aに示すものとなり、アクション先識別情報UID_Toが「2zz99x999」であるとすれば、第2個別ログファイルFL2は
図14Bに示すものとなる。
【0056】
次に、ポイントテーブルTBLpについて説明する。ポイントテーブルTBLpは、ポイントテーブルTBLp1〜TBLp9から構成される。ポイントテーブルTBLp1は、実際にゴルフに誘った、あるいは誘われたかを評価する項目1のポイントと判定基準とを対応づけて記憶している。
図15にポイントテーブルTBLp1の記憶内容を示す。具体的には、ゴルフに誘った日又はゴルフに誘われた日から現在日までの差分日Z1とポイントとの関係がポイントテーブルTBLp1に記憶されている。例えば、差分日Z1が40日であれば、ポイントは「15」となる。
【0057】
項目1のポイントを特定する処理においては、第1に、表示対象とするゴルフ利用者の識別情報UIDとアクション元識別情報UID_Fromとが一致するレコードを第1個別ログファイルFL1から抽出し、対象とするゴルフ利用者の識別情報UIDとアクション元識別情報UID_Toとが一致するレコードを第2個別ログファイルFL2から抽出する。第2に、抽出したレコードのうちアクション種別情報kindに「1」が記録されているレコードを特定する。第3に、特定したレコードに記録されているタイムスタンプと現在日とに基づいて差分日Z1を特定する。第4に、特定した差分日Z1に対応するポイントを、ポイントテーブルTBLp1を参照して特定する。第5に、特定したポイントの合計を算出し、項目1のポイントP1とする。
【0058】
この例では、表示対象とするゴルフ利用者がゴルフに誘った場合と、ゴルフに誘われた場合とで同じポイントを付与したが、ゴルフに誘った場合と、ゴルフに誘われた場合とで異なるポイントを付与してもよい。例えば、表示対象とするゴルフ利用者がゴルフに誘った場合には、
図16に示すポイントテーブルTBLp1aを参照して、特定した差分日Z1に対応するポイントを特定し、表示対象とするゴルフ利用者がゴルフに誘われた場合には、
図16に示すポイントテーブルTBLp1bを参照して、特定した差分日Z1に対応するポイントを特定してもよい。具体的には、第1個別ログファイルFL1から抽出されたレコードは、ポイントテーブルTBLp1aを参照してポイントを特定し、第2個別ログファイルFL2から抽出されたレコードは、ポイントテーブルTBLp1bを参照してポイントを特定すればよい。
【0059】
次に、ポイントテーブルTBLp2は、管理サーバ1が提供するアプリケーションにおける所定のゴルフ利用者との交流頻度である項目2のポイントと判定基準とを対応づけて記憶している。
図17にポイントテーブルTBLp2の記憶内容を示す。具体的には、アクション種別情報kind、判定基準及びポイントを対応づけて記憶している。本実施形態では所定のゴルフ利用者と表示対象となるゴルフ利用者との間の交流として、所定のゴルフ利用者の投稿に対する表示対象となるゴルフ利用者の「いいね」及びコメントがある。ここで、所定のゴルフ利用者の投稿には、ゴルフ報告やニュースに対するコメントの投稿が含まれる。
ポイントテーブルTBLp2のアクション種別情報kindが「3」のレコードは、「いいね」の実行回数Z2とポイントとの関係を記録している。また、アクション種別情報kindが「4」のレコードは、コメントの投稿回数Z3とポイントとの関係を記録している。
【0060】
項目2のポイントを特定する処理は、「いいね」に関するポイントを特定する処理とコメントに関するポイントを特定する処理とに大別される。まず、「いいね」に関するポイントを特定する処理については、第1に、所定のゴルフ利用者の第1個別ログファイルFL1及び第2個別ログファイルFL2を特定する。第2に、第1個別ログファイルFL1及び第2個別ログファイルFL2からアクション種別情報kindが「3」となるレコードを抽出する。第3に、第1個別ログファイルFL1から抽出したレコードについて、表示対象とするゴルフ利用者の識別情報UIDとアクション先識別情報UID_Toとが一致するレコードを抽出する。第4に、第2個別ログファイルFL2から抽出したレコードについて、表示対象とするゴルフ利用者の識別情報UIDとアクション元識別情報UID_Fromとが一致するレコードを抽出する。第5に、タイムススタンプを参照し、現在日から所定期間内(例えば、90日)のレコードを更に絞り込む。第6に、絞り込んだレコードの数をカウントして実行回数Z2とする。第7に、実行回数Z2に対応するポイントを、ポイントテーブルTBLp2を参照して特定する。
【0061】
次に、コメントに関するポイントを特定する処理では、第1に、所定のゴルフ利用者の第1個別ログファイルFL1及び第2個別ログファイルFL2を特定する。第2に、第1個別ログファイルFL1及び第2個別ログファイルFL2からアクション種別情報kindが「4」となるレコードを抽出する。第3に、第1個別ログファイルFL1から抽出したレコードについて、表示対象とするゴルフ利用者の識別情報UIDとアクション先識別情報UID_Toとが一致するレコードを抽出する。第4に、第2個別ログファイルFL2から抽出したレコードについて、表示対象とするゴルフ利用者の識別情報UIDとアクション元識別情報UID_Fromとが一致するレコードを抽出する。第5に、タイムススタンプを参照し、現在日から所定期間内(例えば、90日)のレコードを更に絞り込む。第6に、絞り込んだレコードの数をカウントしてコメントの投稿回数Z3とする。第7に、コメントの投稿回数Z3に対応するポイントを、ポイントテーブルTBLp2を参照して特定する。
そして、「いいね」に関するポイントを特定する処理で得られたポイントとコメントに関するポイントを特定する処理で得られたポイントの合計を項目2のポイントP2として算出する。
なお、所定のゴルフ利用者が表示対象となるゴルフ利用者に対して「いいね」やコメントしたアクションの場合と、表示対象となるゴルフ利用者が所定のゴルフ利用者に対して「いいね」やコメントしたアクションの場合とで異なるポイントを設定してもよい。
【0062】
次に、ポイントテーブルTBLp3は、管理サーバ1が提供するアプリケーションにおける活動頻度である項目3のポイントと判定基準とを対応づけて記憶している。
図18にポイントテーブルTBLp3の記憶内容を示す。本実施形態のアプリケーションにおける活動の評価では、ゴルフ報告の回数、ニュースへの「いいね」の実行回数、ニュースへのコメント回数、及びログイン回数を評価の対象とする。具体的には、ポイントテーブルTBLp3は、各評価対象の回数Z4とポイントとを対応づけて記憶している。
【0063】
項目3のポイントを特定する処理は、第1に、表示対象のゴルフ利用者の第1個別ログファイルFL1を特定する。第2に、第1個別ログファイルFL1からアクション種別情報kindがゴルフ報告を示す「2」、ニュースへの「いいね」を示す「6」、ニュースへのコメントを示す「7」、ログインを示す「5」となるレコードを各々抽出する。第3に、アクション種別情報kindごとにレコードの数をカウントする。カウント結果は回数Z4となる。第4に、アクション種別情報kindごとに回数Z4に対応するポイントを、ポイントテーブルTBLp3を参照して特定する。第5に、特定したポイントの合計を算出し、項目3のポイントP3とする。
【0064】
なお、利用者ログ管理テーブルTBLbは、上述したように保持期間を経過するとレコードを削除するが、それよりも短い所定期間(例えば、30日)の活動に基づいて項目3のポイントを算出するようにしてもよい。また、ゴルフ報告とニュースへの「いいね」とで個別のポイントテーブルを持ち、異なるポイントを付与してもよい。くわえて、ログイン回数のみ別のポイントテーブルを用いて、異なるポイントを付与してもよい。
【0065】
次に、ポイントテーブルTBLp4は、所定のゴルフ利用者と表示対象のゴルフ利用者が住んでいる地域の近接の程度とをポイントと対応づけて記憶している。
図19にポイントテーブルTBLp4の記憶内容を示す。
図19において指標Z5は、近接の程度を示すものであって、Z5=0は、所定のゴルフ利用者と表示対象のゴルフ利用者が同一の都道府県であることを示し、Z5=1は、所定のゴルフ利用者と表示対象のゴルフ利用者が近隣の都道府県であることを示し、Z5=2は、所定のゴルフ利用者と表示対象のゴルフ利用者が同一又は近隣の都道府県でないことを示す。
また、同一、近隣、その他の都道府県は、例えば、
図20に示すポイントテーブルTBLp5を参照して判定する。あるいは、
図21に示すポイントテーブルTBLp6を参照して判定してもよい。
【0066】
項目4のポイントを特定する処理は、第1に、ゴルフ利用者情報テーブルTBL11を参照して、所定のゴルフ利用者の住所の都道府県及び表示対象となるゴルフ利用者の住所の都道府県を特定する。なお、ゴルフ利用者情報テーブルTBL11に記録される住所は、外部管理サーバ3から取得したものであってもよいし、管理サーバ1に登録されたものであってもよい。また、住所が未入力である場合、あるいは非公開とされている場合には項目4のポイントを「0」にする。第2に、ポイントテーブルTBLp5を参照して、所定のゴルフ利用者の住所の都道府県及び表示対象となるゴルフ利用者の住所の都道府県に対応する指標Z5を特定する。第3に、ポイントテーブルTBLp4を参照して、指標Z5に対応するポイントP4を取得する。
【0067】
次に、ポイントテーブルTBLp7は、所定のゴルフ利用者と表示対象のゴルフ利用者との年齢の近接の程度とをポイントと対応づけて記憶している。
図22にポイントテーブルTBLp5の記憶内容を示す。
図22において指標Z6は、表示対象のゴルフ利用者の年齢から所定のゴルフ利用者の年齢を減算した結果を示している。Z6=0は、所定のゴルフ利用者と表示対象のゴルフ利用者との年齢が同じである場合である。指標Z6が負の場合は、表示対象のゴルフ利用者が所定のゴルフ利用者より年下であり、指標Z6が正の場合は、表示対象のゴルフ利用者が所定のゴルフ利用者より年上である。この例では、表示対象のゴルフ利用者が同い年→年下差3歳未満→年上差3歳未満→年下5歳未満→年上5歳未満→年下5歳以上→年上5歳以上の順にポイントを高く設定してある。これは、表示の優先順位において、ゴルフに誘った場合に承諾する可能性を考慮したものである。すなわち、同じ年齢であれば話題が共通するので、最もゴルフに誘った場合に承諾する可能性が高く、年齢差がある場合には、年上よりも年下の方が承諾する可能性が高いと考える場合があることを考慮したものである。
【0068】
項目5のポイントを特定する処理は、第1に、ゴルフ利用者情報テーブルTBL11を参照して、所定のゴルフ利用者の誕生日から年齢を特定するとともに、表示対象となるゴルフ利用者の誕生日から年齢を特定する。なお、ゴルフ利用者情報テーブルTBL11に記録される誕生日は、外部管理サーバ3から取得したものであってもよいし、管理サーバ1に登録されたものであってもよい。また、誕生日が未入力である場合、あるいは非公開とされている場合には項目5のポイントを「0」にする。第2に、現在日と誕生日に基づいて、所定のゴルフ利用者の年齢と表示対象となるゴルフ利用者の年齢を特定する。第3に、指標Z6(=表示対象のゴルフ利用者の年齢−所定のゴルフ利用者の年齢)を算出する。第4に、ポイントテーブルTBLp7を参照して、指標Z6に対応するポイントP5を取得する。
【0069】
ポイントテーブルTBLp7は、所定のゴルフ利用者の性別及び表示対象となるゴルフ利用者の性別を考慮していなかったが、これを考慮して項目5を評価してもよい。すなわち、例えば所定のゴルフ利用者が男性である場合には、年上女性より年下女性のほうがゴルフに誘いやすく、同性であれば年齢が近いほうが、かつ年下のほうがゴルフに誘いやすいと考える場合があることを考慮したものである。また、所定のゴルフ利用者が女性である場合には、年下男性より年上男性のほうが誘いやすく、同性であれば年齢が近いほうが誘いやすいと考える場合があることを考慮したものである。
性別を考慮する場合には、ポイントテーブルTBLp7の代わりに
図23に示すポイントテーブルTBLp8を用いればよい。
【0070】
次に、ポイントテーブルTBLp9は、表示対象のゴルフ利用者のラウンド頻度及び練習頻度とポイントとを対応づけて記憶している。
図24にポイントテーブルTBLp9の記憶内容を示す。
図24において指標Z7は、表示対象のゴルフ利用者のラウンド頻度のランクから所定のゴルフ利用者のラウンド頻度のランクを減算した結果を示している。また、指標Z8は、表示対象のゴルフ利用者の練習頻度のランクから所定のゴルフ利用者の練習頻度のランクを減算した結果を示している。本実施形態ではラウンド頻度及び練習頻度のランクが近い程、付与されるポイントが高くなるように設定されている。これは、ゴルフに対する熱意が所定のゴルフ利用者と近いゴルフ利用者を優先して表示させるためである。
【0071】
項目6のポイントを特定する処理は、第1に、登録情報テーブルTBLaを参照して、所定のゴルフ利用者及び表示対象のゴルフ利用者について、ラウンド頻度のランク及び練習頻度のランクを取得する。第2に、指標Z7及び指標Z8を算出する。第3に、ポイントテーブルTBLp9を参照して、算出した指標Z7及び指標Z8に対応するポイントを各々特定する。第4に特定したポイントの合計を項目6のポイントP6として算出する。
【0072】
CPU30は、上述した項目1〜項目6のポイントP1〜P6を算出した後、
図25に示す係数テーブルTBLkを参照して、係数k1〜k6を取得する。そして、以下の式に従って、評価値Hを算出する。H=k1*P1+k2*P2+k3*P3+k4*P4+k5*P5+k6*P6
そして、表示対象のゴルフ利用者を評価値Hの順にソートし、表示基準情報Grefに従って、ゴルフフレンドマップに直接ゴルフ友達Ug1及び間接ゴルフ友達Ug2を配置する。本実施形態の表示基準情報Grefは、
図3に示す領域Y1に直接ゴルフ友達Ug1を評価値Hの高い順に予め定められた位置に配置し、領域Y2に間接ゴルフ友達Ug2を評価値Hの高い順に予め定められた位置に配置するように定められている。
このように、直接ゴルフ友達Ug1と間接ゴルフ友達Ug2とを独立して異なる領域に配置し、しかも活動情報を評価し、評価結果に基づいて配置したので、所定のゴルフ利用者と関係性の深いゴルフ利用者を把握し易い態様でゴルフフレンドマップに配置することが可能となる。
【0073】
次に、外部管理サーバ3が備えるSNS利用者情報テーブルTBL31とSNS友達情報テーブルTBL32について説明する。
図26にSNS利用者情報テーブルTBL31のデータ構造を示す。SNS利用者情報テーブルTBL31には複数のレコードが記録されている。1つのレコードは、氏名、性別、住所、勤務先、SNS利用者を一意に識別する識別情報UID(アカウントとして機能する)、及びメールアドレスを含む。これらの情報は、SNS利用者が登録した個人情報である。
【0074】
図27にSNS友達情報テーブルTBL32のデータ構造を示す。SNS友達情報テーブルTBL32には複数のレコードが記録されている。1つのレコードは、アクション元の識別情報、アクション先の識別情報、ステータス、及び申請日時を含む。アクション元は、友達申請を送信したSNS利用者であり、アクション先は、友達申請を受信したSNS利用者である。ステータスは、友達申請の状態を示し、申請中が「0」、承諾が「1」で表される。
図27に示す例では、UIDが「0zz99x999」のSNS利用者は、UIDが「6zz99x999」のSNS利用者に友達申請を送信し、承諾されている。
【0075】
友達関係を記憶する場合に、アクション元(友達申請送信者)とアクション先(友達申請先)を分けて記憶したのは、記憶容量を削減する利点がある。仮に、あるSNS利用者の識別情報UIDと当該SNS利用者と友達関係にある全てのSNS利用者の識別情報UIDとを対応づけて記憶したとすると、2倍の記憶容量が必要となる。例えば、SNS利用者U1がアクション元でありSNS利用者U2がアクション先であるとする。各SNS利用者ごとに友達関係にあるSNS利用者の識別情報を記憶する場合には、利用者U1について利用者U2が友達関係にあることを記憶し、さらに、利用者U2について利用者U1が友達関係にあることを記憶する必要がある。これに対して、本実施形態では、アクション先の識別情報とアクション元の識別情報とを対応づけて1つのレコードに記憶するので記憶容量を半分にすることができる。また、ステータスを更新する場合でも半分の処理となる。
【0076】
図28に管理サーバ1の構成を示す。この図に示すように、管理サーバ1は、装置全体を制御するCPU(Central Processing Unit)30、CPU30の作業領域として機能するRAM(Random Access Memory)31、ブートプログラムなどを記憶したROM(Read Only Memory)32、各種のプログラムやデータを記憶するハードディスクドライブ33、キーボードやマウスなどを含む入力部34、画像を表示するディスプレイ35、通信網NETを介して外部の装置と通信を行う通信インターフェース36、及びコンパクトディスクなどの情報記録媒体を読み取る読取装置37を備える。ハードディスクドライブ33は、上述した記憶部17に相当し、ゴルフ利用者情報テーブルTBL11、活動データベースDB、表示基準情報Grefの他、管理サーバ1全体を制御するプログラムを格納する。但し、管理サーバ1はディスプレイ35、入力部34は備えていなくてもよい。
なお、外部管理サーバ3も管理サーバ1と同様に構成されている。但し、外部管理サーバ3のハードディスクドライブ33には、SNS利用者情報テーブルTBL31と、SNS友達情報テーブルTBL32とが格納される。
【0077】
図29に端末装置2の構成を示す。端末装置2は、装置全体を制御するCPU20、CPU20の作業領域として機能するRAM21、ブートプログラムや装置全体を制御する制御プログラムなどを記憶したROM22、各種のプログラムやデータを記憶する記憶装置23、テンキーなどを含む入力部24、画像を表示するディスプレイ25(表示部)、及び通信網NETを介して外部の装置と通信を行う通信インターフェース26を備える。
【0078】
<2.サービス提供システムの動作>
サービス提供システム100では、ゴルフ利用者の端末装置2において、ゴルフ友達の階層構造を示す関係図を表示させることができ、また、ゴルフ利用者は、ゴルフ利用者とSNSにおいて友達関係にあるSNS利用者をゴルフ情報サービスへの参加に招待することができる。以下、関係図を表示させる表示処理と、ゴルフ情報サービスへの参加に招待する招待処理について説明する。
【0079】
<2−1:表示処理>
図30及び
図31に表示処理に関するサービス提供システムの動作シーケンスを示す。端末装置2のSNS利用者(ゴルフ利用者でもある)が、ウェブブラウザ上で動作したり、端末装置2にインストールされて動作するアプリケーションを起動して、SNSサイトにアクセスすると、端末装置2のディスプレイ25には、ログイン画面が表示される。このログイン画面には、識別情報UIDとパスワードとを入力する入力ボックスが表示される。利用者が、入力ボックスに入力して送信ボタンを押すと、端末装置2は、入力した識別情報UID及びパスワードを含むログイン要求を外部管理サーバ3に送信する。
【0080】
ログイン要求を外部管理サーバ3が受信すると、外部管理サーバ3は認証処理を実行する(S300)。具体的には、外部管理サーバ3のCPUは、識別情報UIDとパスワードとの組が記憶されているか否かを判定し、判定条件を充足する場合にはログインを許可し、判定条件が充足されない場合にはログインを拒絶する。そして、CPUは判定結果を示すログイン応答を端末装置2に対して送信させる。なお、
図30に示す例では、ログインが許可されたものとする。一度、端末装置2で入力された識別情報UIDとパスワードとの組は、端末装置2に所定期間記憶されて、当該所定期間内であればログインを省略可能としてもよい。また、管理サーバ1は外部管理サーバ3で発行されるトークンを用いて、外部管理サーバ3にアクセス可能とするOauth認証を採用してもよい。この場合は、所定の利用者の識別情報UIDに対応するトークンを用いて外部管理サーバ3にアクセスすればよい。
【0081】
この後、所定の利用者がSNSのメニューの中からゴルフアプリケーションを選択すると(S200)、端末装置2は、マイページ閲覧要求を管理サーバ1に送信する。管理サーバ1はマイページ閲覧要求を受信すると、マイページ閲覧要求に含まれる所定の利用者の識別情報UIDを取得し、所定の利用者の識別情報UIDを外部管理サーバ3に送信する(S100)。
【0082】
外部管理サーバ3が、所定の利用者の識別情報UIDを含む要求受信すると、外部管理サーバ3のCPUは、SNS友達情報テーブルTBL32にアクセスし、当該識別情報UIDがアクション元又はアクション先として記録されているレコードを抽出する(S301)。さらに、CPUは、これらのレコードにアクション元又はアクション先として記録されている識別情報UIDをキーとしてSNS利用者情報テーブルTBL31からSNS利用者情報を抽出する(S301)。この後、外部管理サーバ3は、抽出したSNS友達情報及びSNS利用者情報を含む友達リストを管理サーバ1に送信する。
【0083】
管理サーバ1が、友達リストを受信して、SNS友達情報及びSNS利用者情報を取得すると(S101)、管理サーバ1は、所定の利用者の直接SNS友達Uf1の識別情報UIDを特定する(S102)。具体的には、SNS友達情報のレコードにおいてアクション元又はアクション先として記録されている識別情報UIDのうち、所定の利用者の識別情報UID及び重複する識別情報UIDを除いた識別情報UIDを所定の利用者の直接SNS友達Uf1の識別情報UIDとして特定する。この結果、
図32に示すように所定の利用者と友達関係にある直接SNS友達Uf1を特定することができる。この後、管理サーバ1は、直接SNS友達Uf1の識別情報UIDを外部管理サーバ3に送信する(S103)。
【0084】
外部管理サーバ3が、直接SNS友達Uf1の識別情報UIDを含む要求を受信すると、外部管理サーバ3のCPUは、SNS友達情報テーブルTBL32にアクセスし、当該識別情報UIDがアクション元又はアクション先として記録されているレコードを抽出する(S302)。この後、外部管理サーバ3は、抽出したSNS友達情報を含む友達リストを管理サーバ1に送信する。この友達リストは、直接SNS友達Uf1のSNS友達、すなわち、間接SNS友達Uf2のリストである。
【0085】
管理サーバ1が、友達リストを受信して、間接SNS友達Uf2について友達情報を取得すると(S104)、管理サーバ1は、間接SNS友達Uf2について識別情報UIDを特定する(S105)。具体的には、SNS友達情報のレコードにおいてアクション元又はアクション先として記録されている識別情報UIDのうち、直接SNS友達Uf1の識別情報UIDと重複する識別情報UIDを除いた識別情報UIDを間接SNS友達Uf2の識別情報UIDとして特定する。この結果、
図33に示すように所定の利用者と友達関係にある直接SNS友達Uf1及び間接SNS友達Uf2を特定することができる。この後、管理サーバ1は、間接SNS友達Uf2の識別情報UIDを外部管理サーバ3に送信する(S106)。
【0086】
外部管理サーバ3が、間接SNS友達Uf2の識別情報UIDを含む要求を受信すると、外部管理サーバ3のCPUは、SNS利用者情報テーブルTBL31にアクセスし、当該識別情報UIDが記録されているレコードを抽出する(S303)。この後、外部管理サーバ3は、抽出したSNS利用者情報を管理サーバ1に送信する。
【0087】
管理サーバ1が、間接SNS友達Uf2のSNS利用者情報を受信すると(S107)、
図31に示すように、管理サーバ1のCPU30は、直接SNS友達Uf1の識別情報UIDと、及び間接SNS友達Uf2の識別情報UIDと、ゴルフ利用者の識別情報UIDとに基づいて直接ゴルフ友達Ug1及び間接ゴルフ友達Ug2を特定する(S108)。具体的には、ゴルフ利用者情報テーブルTBL11を参照することにより、S102で特定した直接SNS友達Uf1の識別情報UIDのうちゴルフ利用者の識別情報UIDと一致するものを、直接ゴルフ友達Ug1の識別情報UIDとする。また、ゴルフ利用者情報テーブルTBL11を参照することにより、S105で特定した間接SNS友達Uf2の識別情報UIDのうち、ゴルフ利用者の識別情報UIDと一致するものを、間接ゴルフ友達Ug2の識別情報UIDとする。このようにして
図2に示すように直接ゴルフ友達Ug1及び間接ゴルフ友達Ug2が特定される。
【0088】
次に、管理サーバ1のCPU30は、関係図を表示させる表示情報を生成し(S109)、当該表示情報を含むマイページ閲覧応答を所定の利用者の端末装置2に送信する(S110)。ここで、CPU30は、ゴルフ利用者のプロフィール画像を画面に配置する表示情報を生成する。送信データ量を削減するため、プロフィール画像は、画像データのアドレスを示すリンク情報として与えられる。なお、リンク情報の代わりにプロフィール画像データを表示情報に含ませてもよい。
【0089】
まず、CPU30は、直接ゴルフ友達Ug1と間接ゴルフ友達Ug2に大別し、仮想的な画面に全ての直接ゴルフ友達Ug1のプロフィール画像と間接ゴルフ友達Ug2のプロフィール画像とを配置した関係図を生成する。
直接ゴルフ友達Ug1のプロフィール画像のアイコンは、間接ゴルフ友達Ug2のプロフィール画像のアイコンよりも大きくする。表示すべき人数が多い場合には、仮想的に画面の大きさは端末装置2のディスプレイ25で表示される画面より大きくなる。この場合には、端末装置2において、仮想的な画面を表示可能な大きさに切り出してディスプレイ25に表示することになる。
【0090】
CPU30は、直接ゴルフ友達Ug1のプロフィール画像を仮想的な画面の一番手前から埋め、その後、その奥に、間接ゴルフ友達Ug2のプロフィール画像を埋めていく。例えば、全ての直接ゴルフ友達Ug1と間接ゴルフ友達Ug2とを配置した画面が
図34に示す画面Wであるとする。直接ゴルフ友達Ug1のプロフィール画像を一番手前の画面に配置し、直接ゴルフ友達Ug1の配置が完了した後、間接ゴルフ友達Ug2のプロフィール画像をその奥に配置する。この場合、CPU30は、領域r1→領域r2→領域r3…の順に直接ゴルフ友達Ug1のプロフィール画像と間接ゴルフ友達Ug2のプロフィール画像とを配置する。なお、1つの領域に表示可能な人数は予め設定で決められているが、任意の人数に変更可能としても良い。ここで、直接ゴルフ友達Ug1を表示する領域を第1表示領域と称し、間接ゴルフ友達Ug2を表示する領域を第2表示領域と称する。
【0091】
端末装置2のディスプレイ25において最初に表示されるのが画面領域R1である。この場合、領域r1は
図3に示す表示領域Y1(第1表示領域)に相当し、領域r2は表示領域Y2(第2表示領域)に相当する。
図3に示すボタンB2をクリックすると、ディスプレイ25に画面領域R2が表示される。この場合、領域r2は
図3に示す表示領域Y1(第1表示領域)に相当し、領域r3は表示領域Y2(第2表示領域)に相当する。つまり、表示される画面領域R1又はR2に応じて、領域r2は第2表示領域又は第1表示領域に相当するものとなる。この状態で、ボタンB1をクリックすると、ディスプレイ25に画面領域R1が表示される。
【0092】
即ち、端末装置2のディスプレイ25は、画面を所定の方向にスライドして画面サイズよりも大きなサイズの関係図を表示できるようになっている。管理サーバ1のCPU30は、ディスプレイ25の画面サイズに相当する領域に直接ゴルフ友達Ug1のプロフィール画像と間接ゴルフ友達Ug2のプロフィール画像を全て配置できない場合、画面サイズよりも大きな領域に直接ゴルフ友達Ug1のプロフィール画像と間接ゴルフ友達Ug2のプロフィール画像とを配置した関係図を表示するために必要な表示情報を生成する。
【0093】
CPU30は、ゴルフ友達の配置において、記憶部17に記憶されている表示基準情報Grefに従って、ゴルフ友達を所定パラメータに従って評価し、評価結果に基づいて表示優先度が高いと判断されたものから順に、予め定められた領域に表示する処理を行う。
表示基準情報Grefによって指定され評価の基準となるパラメータとしては、利用情報(項目1〜項目3)と登録情報(項目4〜項目6)とがある。これらに基づく評価値Hの算出は、
図15〜
図24を参照して説明した通りである。
図3に示す例では、領域Y1の下辺に近い程、表示優先度が高い。即ち、ゴルフ友達GF1→GF2→GF3→GF4→GF5の順に評価値Hが大きい。
【0094】
説明を
図10に戻す。次に、管理サーバ1は、表示情報を含むマイページ閲覧応答を所定の利用者の端末装置2に送信する(S110)。端末装置2がマイページ閲覧応答を受信すると、CPU20はディスプレイ25に直接ゴルフ友達Ug1のプロフィール画像と間接ゴルフ友達Ug2のプロフィール画像とを配置した関係図(ゴルフフレンドマップ)を表示する。すなわち、管理サーバ1のCPU30は、所定の利用者の端末装置2のディスプレイ25に上記関係図を表示させる。
本実施形態では、
図3及び
図27に示すように直接ゴルフ友達Ug1のプロフィール画像が手前に配置され、間接ゴルフ友達Ug2のプロフィール画像が直接ゴルフ友達Ug1のプロフィール画像より奥に配置されるので、ゴルフ利用者は、ゴルフ友達の階層関係を容易に把握することができる。さらに、所定の利用者とより関係の深い直接ゴルフ友達Ug1のプロフィール画像は間接ゴルフ友達Ug2のプロフィール画像よりも大きなアイコンで表示されるので、両者の階層関係を一見して把握することができる。加えて、間接ゴルフ友達Ug2は、所定の利用者の直接ゴルフ友達Ug1のそれぞれに対して友達関係があるので、直接ゴルフ友達Ug1よりも人数が多いのが通常である。間接ゴルフ友達Ug2のアイコンを直接ゴルフ友達Ug1のアイコンよりも小さくすることによって、効率の良い表示が可能となる。
【0095】
<2−2:招待処理>
図35A及び35Bに招待処理に関するサービス提供システムの動作シーケンスを示す。この例では、アクション元のゴルフ利用者の端末装置を端末装置2f、アクション先のSNS利用者の端末装置を端末装置2tと称する。
まず、アクション元である端末装置2fのゴルフ利用者(所定の利用者)が、
図3に示すマイページにおいてアイコンA4をクリックして「ゴルフ友達を増やす」を選択すると、端末装置2fは、友達申請ページ要求を管理サーバ1に送信する。管理サーバ1は友達申請ページ要求を受信すると、所定の利用者の識別情報UIDを取得し、所定の利用者の識別情報UIDを外部管理サーバ3に送信する(S120)。
【0096】
外部管理サーバ3が、所定の利用者の識別情報UIDを含む要求を受信すると、外部管理サーバ3のCPUは、SNS友達情報テーブルTBL32にアクセスし、当該識別情報UIDがアクション元又はアクション先として記録されているレコードを抽出する(S320)。さらに、CPUは、これらのレコードにアクション元又はアクション先として記録されている識別情報UIDをキーとしてSNS利用者情報テーブルTBL31からSNS利用者情報を抽出する(S321)。この後、外部管理サーバ3は、抽出したSNS友達情報及びSNS利用者情報を含む友達リストを管理サーバ1に送信する。
【0097】
管理サーバ1が、友達リストを受信して、SNS友達情報及びSNS利用者情報を取得すると(S121)、管理サーバ1のCPU30は、SNS友達であり且つゴルフ利用者でない者を抽出し、友達申請ページを生成する(S122)。
より具体的には、第1に、CPU30は、友達情報のステータスが承諾のレコードにアクション元又はアクション先として記録されている識別情報UIDのうち、所定の利用者の識別情報UID及び重複する識別情報UIDを除いた識別情報UIDを所定の利用者の直接SNS友達Uf1の識別情報UIDとして特定する。
第2に、CPU30は、ゴルフ利用者情報テーブルTBL11を参照して、ゴルフ利用者の識別情報UIDを取得する。
第3に、CPU30は、直接SNS友達Uf1の識別情報UIDからゴルフ利用者の識別情報UIDを除いた者の識別情報UIDを招待候補者として特定する。
第4に、CPU30は、招待候補者の識別情報UIDに対応するSNS利用者情報を用いて、友達申請ページを生成する。
【0098】
この後、管理サーバ1は、友達申請ページ応答を端末装置2fに送信する。友達申請ページ応答を受信した端末装置2fは、ディスプレイ25に友達申請ページを表示する(S221)。
図36に友達申請ページの一例を示す。この例では、領域Cに招待候補者のアイコンが表示される。招待候補者のアイコンは、ボタンB3をクリックすると左方向にスクロールし、ボタンB4をクリックすると右方向にスクロールする。そして、招待候補者のアイコンを所定の領域(この例では、グリーン)にドラッグすると、
図37に示すように確認画面が表示される。この例では、「山田一郎」をゴルフ情報サービスへの参加に招待するか否かが確認される。キャンセルボタンB5がクリックされると、アイコンDは領域Cの元の位置に戻される。一方、送信ボタンB6がクリックされると、
図35Aに示すように端末装置2fはゴルフ友達申請要求を管理サーバ1に送信する。ゴルフ友達申請要求にはアクション元(友達申請元)の識別情報UIDとアクション先(友達申請先)の識別情報UIDとが含まれている。
【0099】
管理サーバ1がゴルフ友達申請要求を受信すると、管理サーバ1はゴルフ友達申請処理を実行する(S123)。ゴルフ友達申請処理では、管理サーバ1のCPU30は、アクション元とアクション先の識別情報UIDを含むゴルフ友達申請通知を外部管理サーバ3に送信する。外部管理サーバ3はゴルフ友達申請通知を受信すると、アクション先の識別情報UIDと関連付けて、アクション元であるSNS友達からゴルフ情報サービスへの参加の招待があったことを示す招待情報をSNS利用者情報テーブルTBL31に記憶する(S320)。
【0100】
図35Bに示すように、この後、アクション先のSNS利用者が、端末装置2tにおいてSNSサイトにログインすると、当該SNS利用者のマイページにアクション元のゴルフ利用者からゴルフ情報サービスへの参加に招待する旨のメッセージと共に管理サーバ1が管理する登録ページへジャンプするボタンが表示される(S230)。アクション先のSNS利用者がボタンをクリックして登録を選択すると(S231)、登録ページ要求が管理サーバ1に送信される。管理サーバ1が登録ページを含む登録ページ応答を端末装置2tに送信すると、端末装置2tのディスプレイ25には登録ページが表示される(S232)。端末装置2tにおいてSNS利用者が所定事項を入力して登録ページに表示される登録ボタンをクリックすると、端末装置2tは登録要求を管理サーバ1に送信する。
【0101】
管理サーバ1が登録要求を受信すると、CPU30はゴルフ利用者情報テーブルTBL11を更新する。この際、ゴルフ利用者情報テーブルTBL11には、アクション先のSNS利用者の識別情報UIDが追加されると共に、アクション元のゴルフ利用者の識別情報UIDに関連付けて登録メッセージが記録される。
この後、アクション元のゴルフ利用者が管理サーバ1にログインすると、管理サーバ1は、登録メッセージを含むマイページを端末装置2fに送信する。マイページを受信した端末装置2fのCPU20は、ディスプレイ25にマイページを表示する(S240)。
図38に登録メッセージを含むマイページの一例を示す。この例では、領域Dにゴルフ情報サービスへの参加の招待を受諾したSNS利用者のプロフィール画像と共に「誘ってくれてありがとう!ゴルフに行こう!」という登録メッセージが表示される。
このように、直接ゴルフ友達Ug1が増加すると、間接ゴルフ友達Ug2も増加するので、マイページに表示される友達の人数が急激に増加し、マイページが賑やかになり、ゴルフに関するコミュニケーションを活性化することができる。
【0102】
なお、招待の通知の態様としては、マイページにおける招待の投稿に対して、賛同を表明するボタン(例えば、「いいね!」ボタン)のクリックや、メールの本文記載のURLからのアクセスであってもよい。この場合、賛同を表明するボタンやメールの本文記載のURLにアクション元の識別情報UIDが対応づけられていることが好ましい。
また、上述の態様では、招待候補者は、直接SNS友達Uf1であったが、間接SNS友達Uf2を招待候補者に含めてもよい。この場合、管理サーバ1の取得部11は、直接SNS友達Uf1の識別情報UIDを外部管理サーバ3に送信し、間接SNS友達Uf2のSNS利用者情報を取得すればよい。
【0103】
<第2実施形態>
上述した第1実施形態のサービス提供システム100は、外部管理サーバ3においてSNS利用者の友達情報を管理し、管理サーバ1ではいかなる友達情報をも独自に管理していなかった。これに対して、第2実施形態のサービス提供システム100は、管理サーバ1の代わりに管理サーバ1Aを用いる点を除いて、
図1に示す第1実施形態のサービス提供システム100と同様である。
【0104】
図39に管理サーバ1Aのブロック図を示す。管理サーバ1Aは、記憶部17にゴルフ友達情報テーブルTBL12を備える点で、管理サーバ1と相違する。
図40にゴルフ友達情報テーブルTBL12のデータ構造を示す。ゴルフ友達情報テーブルTBL12には複数のレコードが記録されている。1つのレコードは、アクション元の識別情報、アクション先の識別情報、ステータス、及び申請日時を含む。アクション元は、ゴルフ友達申請を送信したゴルフ利用者であり、アクション先は、ゴルフ友達申請を受信したSNS利用者である。ステータスは、ゴルフ友達申請の状態を示し、申請中が「0」、承諾が「1」で表される。
【0105】
次に、第2実施形態に係る表示処理について説明する。第2実施形態では、
図9を参照して説明した第1実施形態と同様に、外部管理サーバ3から、所定の利用者の直接SNS友達Uf1及び間接SNS友達Uf2について識別情報UIDとSNS利用者情報を取得する。
【0106】
表示処理では、まず、
図42に示すように所定の利用者の直接SNS友達Uf1と間接SNS友達Uf2とが特定される。
図41に管理サーバ1AのCPU30が実行する表示情報生成処理の内容を示す。
【0107】
CPU30は、直接SNS友達Uf1又は間接SNS友達Uf2、且つ直接ゴルフ友達Ug1である者を抽出する(S130)。具体的には、第1に、CPU30は、所定の利用者の識別情報UIDをキーとして、当該識別情報UIDがアクション元又はアクション先となるレコードをゴルフ友達情報テーブルTBL12から抽出し、直接ゴルフ友達Ug1の識別情報UIDを特定する。第2に、CPU30は、直接SNS友達Uf1の識別情報UID又は間接SNS友達Uf2の識別情報UIDと、直接ゴルフ友達Ug1の識別情報UIDとが一致するものを抽出し、抽出された識別情報UIDを表示対象のゴルフ友達とする。このようにゴルフ友達を、SNS友達でフィルタリングするのは、ゴルフの友達関係はSNSの友達関係を前提とするからである。例えば、ある時点で所定の利用者とSNS友達であったゴルフ友達について、時間が経過した後、所定の利用者とSNS上での友達関係が解消されたとする。この場合、ゴルフの友達関係が必ずしも解消されているとは限らない。そこで、ゴルフ友達をSNS友達でフィルタリングしたのである。この結果、
図43に示すように表示対象となる直接ゴルフ友達Ug1が特定される。なお、この直接ゴルフ友達Ug1のうち、同図に示す部分Fxのゴルフ友達は、間接SNS友達Uf2でもある。これは、間接SNS友達Uf2であり、ゴルフ利用者ではないSNS利用者をゴルフ情報サービスへの参加に招待することによって、所定の利用者と直接のゴルフ友達となることがあるからである。
【0108】
この後、CPU30は、直接SNS友達Uf1又は間接SNS友達Uf2、且つ間接ゴルフ友達Ug2である者を抽出する(S131)。具体的には、第1に、CPU30は、直接ゴルフ友達Ug1の識別情報UIDをキーとして、当該識別情報UIDがアクション元又はアクション先となるレコードをゴルフ友達情報テーブルTBL12から抽出し、間接ゴルフ友達Ug2の識別情報UIDを特定する。第2に、CPU30は、直接SNS友達Uf1の識別情報UID又は間接SNS友達Uf2の識別情報UIDと、間接ゴルフ友達Ug2の識別情報UIDとが一致するものを抽出し、抽出された識別情報UIDを表示対象の間接ゴルフ友達Ug2とする。この結果、
図44に示すように表示対象となる間接ゴルフ友達Ug2が特定される。なお、この間接ゴルフ友達Ug2のうち、同図に示す部分Fyの間接ゴルフ友達Ug2は、直接SNS友達Uf1でもある。これは、直接ゴルフ友達Ug1と友達関係にある間接ゴルフ友達Ug2には、直接のSNS友達が含まれるからである。
このようにCPU30は、S130及びS131を実行することにより、記憶部17から読み出したゴルフ友達情報(第1特定関係情報)と参照部12で参照したSNS友達情報(第2特定関係情報)とに基づいて、所定の利用者と友達関係(特定の関係)を有するSNS利用者(第2サービス利用者)である直接SNS友達Uf1、及び当該直接SNS友達Uf1と更に友達関係を有するSNS利用者である間接SNS友達Uf2を特定SNS利用者としたとき、所定の利用者と友達関係を有するゴルフ利用者(第1サービス利用者)であり、且つ特定SNS利用者である者を直接ゴルフ友達Ug1(第1の特定利用者)として特定し、直接ゴルフ友達Ug1と友達関係を有するゴルフ利用者であり、且つ特定SNS利用者である者を間接ゴルフ友達Ug2(第2の特定利用者)として特定する特定部13として機能する。
【0109】
次に、CPU30は、関係図を表示させる表示情報を生成し(S132)、表示情報を端末装置2に送信する(S133)。表示情報の生成は、
図31を参照して説明したS109の処理と同様である。この結果、第2実施形態においても第1実施形態と同様に、
図3及び
図34に示すマイページを端末装置2のディスプレイ25に表示させることができ、ゴルフ利用者は、ゴルフ友達の階層関係を容易に把握することが可能となる。
【0110】
<第3実施形態>
上述した第3実施形態のサービス提供システム100Aは、第2実施形態のサービス提供システム100Aから外部管理サーバ3を除いたものである。
図45に第3実施形態に係るサービス提供システム100Aのブロック図を示す。サービス提供システム100Aでは、第1実施形態及び第2実施形態のようにゴルフ利用者の集合がSNS利用者の集合に含まれるといった関係はない。
管理サーバ1Aは、ゴルフ利用者情報テーブルTBL11とゴルフ友達情報テーブルTBL12を記憶した記憶部17を備える。また、記憶部17には、管理サーバ1Aを制御するプログラムが記憶されている。管理サーバ1Aは、所定の利用者(所定の第1サービス利用者)の端末装置2から所定の利用者の友達関係を表示する要求を受信すると、所定の利用者の識別情報UIDを取得する取得部11と、取得部11で取得した識別情報UIDに基づいて、ゴルフ利用者同士の友達関係を示すゴルフ友達情報を参照する参照部12と、ゴルフ友達情報に基づいて、所定の利用者と友達関係を有する直接ゴルフ友達Ug1(第1の特定利用者)を特定する特定部13と、特定部13で特定した直接ゴルフ友達Ug1について、ゴルフ(所定の対象)に関する活動を示す活動情報に基づいて、ゴルフに関する活動を評価する評価部14と、評価部14の評価結果に基づいて、端末装置2の表示部の画面上に表示されるゴルフ友達の位置を決定する決定部13と、決定部13で決定された画面上の位置にゴルフ友達を配置した画面を所定の利用者の端末装置2に表示させる表示制御部16とを備える。具体的には、表示制御部16は、上記画面を表示するために必要な情報を生成し、当該情報を含む表示応答を所定の利用者の端末装置2に送信する。
この場合、参照部12はゴルフ友達情報テーブルTBL12に記憶されているゴルフ友達情報を参照すればよい。また、活動情報は、登録情報テーブルTBLaに記録されている登録情報と、利用者ログ管理テーブルTBLbに記録されている利用情報との少なくとも一方を含む。この管理サーバ1Aによれば、ゴルフ友達をゴルフに関する活動が活発な順に配置して表示させることができるので、多数のゴルフ友達がいる場合には、ゴルフに熱心なゴルフ友達を優先して表示させることが可能となる。
【0111】
また、上述した管理サーバ1Aにおいて、直接ゴルフ友達Ug1及び間接ゴルフ友達Ug2を考慮すると、以下のように構成することが好ましい。参照部12は、直接ゴルフ友達Ug1の識別情報UIDに基づいて、直接ゴルフ友達Ug1と友達関係を示すゴルフ友達情報を参照可能である(友達関係を示すゴルフ友達情報はゴルフ友達情報テーブルTBL12に記憶されている)。特定部13は、ゴルフ友達について友達関係を示すゴルフ友達情報に基づいて、直接ゴルフ友達Ug1と友達関係を有する間接ゴルフ友達Ug2を特定する。評価部14は、特定部13で特定した直接ゴルフ友達Ug1及び間接ゴルフ友達Ug2について、ゴルフに関する活動を示す活動情報に基づいて、ゴルフに関する活動を評価する。
決定部15は、評価部14の評価結果に基づいて、端末装置2の表示部の画面上に表示される直接ゴルフ友達Ug1及び間接ゴルフ友達Ug2の位置を決定する。表示制御部16は、決定部15で決定された画面上の位置に直接ゴルフ友達Ug1及び間接ゴルフ友達Ug2を表示するために必要な情報を生成し、当該情報を含む表示応答を所定の利用者の端末装置2に送信する。
この管理サーバ1Aによれば、間接ゴルフ友達Ug2についてもゴルフに関する活動に応じて表示位置を定めることができる。間接ゴルフ友達Ug2の人数は、直接ゴルフ友達Ug1の人数よりも多いのが一般的であるが、本実施形態によれば、間接ゴルフ友達Ug2についても、ゴルフに関する活動が活発な順に間接ゴルフ友達Ug2を優先して表示させることが可能となる。
【0112】
<第4実施形態>
上述した第3実施形態のサービス提供システム100Aは、管理サーバ1Aにおいて、取得部11、参照部12、特定部13、評価部14、決定部15及び表示制御部16を備え、表示情報を生成した。これに対して、第4実施形態では、これらの機能を端末装置2Aで備える。端末装置2Aは、所有者の識別情報UIDは記憶するが、ゴルフ友達情報やゴルフ利用者情報は記憶しておらず、これらは管理サーバ1Aに問い合わせることによって取得する。
図46に第4実施形態のサービス提供システム100Aに用いる端末装置2Aの機能ブロック図を示す。端末装置2Aは、ゴルフ友達情報を管理する管理サーバ1Aと通信可能であり、当該端末装置2Aのゴルフ利用者の識別情報UIDを記憶する記憶部205と、記憶部205から所定の利用者の識別情報UIDを取得する取得部201と、取得部201で取得した所定の利用者の識別情報UIDに基づいて、管理サーバ1Aで管理するゴルフ友達情報(特定関係情報)を参照する参照部202と、ゴルフ友達情報に基づいて、所定の利用者と友達関係を有する直接ゴルフ友達Ug1(第1の特定利用者)を特定する特定部203と、表示部208と、特定部203で特定した直接ゴルフ友達Ug1について、ゴルフ(所定の対象)に関する活動を示す活動情報に基づいて、ゴルフに関する活動を評価する評価部204と、評価部204の評価結果に基づいて表示部208の画面上に表示されるゴルフ友達の位置を決定する決定部205と、決定部205で決定された画面上の位置にゴルフ友達を配置した画面を表示部208に表示させる表示制御部206とを備える。また、記憶部205には、端末装置2Aを制御するプログラムが記憶されている。
この結果、第4実施形態においても第3実施形態と同様に、
図3及び
図34に示すゴルフフレンドマップを備えたマイページを端末装置2のディスプレイ25に表示させることができ、ゴルフ利用者は、ゴルフ友達の階層関係を容易に把握することが可能となる。
また、端末装置2Aにおいて、直接ゴルフ友達Ug1及び間接ゴルフ友達Ug2を考慮すると、以下のように構成することが好ましい。参照部202は、直接ゴルフ友達Ug1が特定されると、当該直接ゴルフ友達Ug1の識別情報UIDに基づいて、ゴルフ友達情報を参照する。なお、友達関係を示すゴルフ友達情報は管理サーバ1Aのゴルフ友達情報テーブルTBL12に記憶されている。特定部203は、直接ゴルフ友達Ug1と友達関係を有する間接ゴルフ友達Ug2を特定する。評価部204は、直接ゴルフ友達Ug1及び間接ゴルフ友達Ug2について、ゴルフに関する活動を示す活動情報に基づいて、ゴルフに関する活動を評価する。活動情報は、管理サーバ1Aに記憶されている、登録情報テーブルTBLaに記録されている登録情報と、利用者ログ管理テーブルTBLbに記録されている利用情報との少なくとも一方を含む。決定部205は、評価部204の評価結果に基づいて、表示部208の画面上に表示される直接ゴルフ友達Ug1及び間接ゴルフ友達Ug2の位置を決定する。表示制御部206は、決定部205で決定された画面上の位置に直接ゴルフ友達Ug1及び間接ゴルフ友達Ug2を表示するために必要な情報を生成し、表示部208に表示させる。
【0113】
<変形例>
本発明は、上述した各実施形態に限定されるものではなく、以下に述べる各種の変形が可能である。また、各変形例及び各実施形態は、適宜、組み合わせてもよいことは勿論である。
(1)上述した端末装置2又は2Aでは、
図3に示すようなゴルフ友達の階層関係を示す関係図をディスプレイ25に表示させたが、本発明はこれに限定されるものではなく、
図47に示すように、直接ゴルフ友達Ug1と友達関係にある間接ゴルフ友達Ug2との間を線(以下、関係線と称する)で結んでもよい。この場合、人物アイコンをクリックしたり、マウスカーソルを人物アイコンに重ねること(オンマウス)で関係線を表示させてもよい。ゴルフ友達同士で友達関係がある場合にも関係線で結んでもよい。加えて、ゴルフ友達同士と、直接ゴルフ友達Ug1と間接ゴルフ友達Ug2との関係性は関係線の種類や色を変えることで識別可能としても良い。このような関係線を表示させることで、直接ゴルフ友達Ug1と間接ゴルフ友達Ug2との関係や、直接ゴルフ友達Ug1同士の関係をより容易に把握可能とすることができる。
【0114】
(2)上述した端末装置2又は2Aのディスプレイ25に表示させる画面では、
図34に示すように上下方向に画面をスライド可能としたが、本発明はこれに限定されるものではなく、
図48に示すように左右方向にスライドさせて、広いマップを表示可能としても良い。
また、所定の利用者のゴルフ友達のアイコンをグループ別に分類できるようにしても良い。例えば「同じ会社」や「サークル仲間」など、予め区分を登録する。そして、SNS利用者情報やゴルフ利用者情報を参照して、ゴルフ友達を分類してそれを表示させても良い。
また、所定の利用者のパラメータに近い人を自動判別して表示させるようにしても良い。例えば、住所が近い、年齢が近い、ゴルフ歴が近い、などのパラメータをシステム側で自動検索し、所定の換算方法で数値化し、数値の高い者から順に、所定の利用者のアイコンに近い位置に配置して表示させてもよい。具体的には、外部管理サーバ3で管理するSNS利用者情報に含まれる誕生日や住所などの属性情報を参照してパラメータを取得してもよいし、これらの属性情報を管理サーバ1又は1Aで管理しても良い。即ち、CPU30は、ゴルフ友達についてゴルフに関する活動を示す活動情報に基づいてゴルフに関する活動を評価する処理と、所定の利用者の属性情報とゴルフ友達に関する属性情報とに基づいて、所定の利用者とゴルフ友達の属性が親和する程度を評価する処理とのうち、少なくとも一方を実行すればよい。また、間接ゴルフ友達Ug2についても同様である。
また、人数が多いようであれば、各グループごとに各ホールの背景として、各グループのアイコンを表示させるようにしても良い。この場合、アイコンはあるホールと別のホールで重複する人が存在していても良い。例えば、第3ホールは会社の同僚、第18ホールは地元の友達、などとし、第3ホールと第18ホールで同じメンバーが入っていても良い。
【0115】
(3)上述した各実施形態及び各変形例では、関係図において、直接ゴルフ友達Ug1と間接ゴルフ友達Ug2に該当する者を表示しているが、SNS友達であってゴルフ友達でないSNS利用者も併せて表示させるようにしてもよい。この場合、例えば、関係図の両脇や空の部分にSNS友達であってゴルフ友達でないSNS利用者を配置したり、アイコンやその枠の色を変更したり、あるいは、関係線の色や種類を変えるなどして、ゴルフ友達と区別可能にしても良い。
【0116】
より具体的には、上述した第1実施形態の管理サーバ1において(
図1参照)、特定部13は、所定の利用者と友達関係(特定の関係)を有するSNS利用者(第2サービス利用者)のうちゴルフ利用者(第1サービス利用者)に該当しないSNS利用者と、直接ゴルフ友達Ug1(第1の特定利用者)と友達関係を有するSNS利用者のうちゴルフ利用者に該当しないSNS利用者との少なくとも一方を外部利用者として特定する。ここで、所定の利用者と友達関係を有するSNS利用者のうちゴルフ利用者に該当しない者は、
図49に示すSNS利用者K1であり、直接ゴルフ友達Ug1と友達関係を有するSNS利用者のうちゴルフ利用者に該当しないSNS利用者は、同図に示すSNS利用者K2である。
そして、表示制御部16は、直接ゴルフ友達Ug1(第1の特定利用者)及び間接ゴルフ友達Ug2(第2の特定利用者)と外部利用者とを区別できる関係図を端末装置2の表示部に表示させる。例えば、
図51に示すように領域Y3にSNS利用者K1を表示し、領域Y4にSNS利用者K2を表示させても良い。
【0117】
また、上述した第2実施形態の管理サーバ1Aにおいて(
図39参照)、CPU30は直接SNS友達Uf1及び間接SNS友達Uf2を特定関係のSNS友達(特定関係第2サービス利用者)としたとき、SNS友達情報及びゴルフ友達情報に基づいて、関係するSNS友達のうち、直接ゴルフ友達Ug1(第1の特定利用者)又は間接ゴルフ友達Ug2(第2の特定利用者)に該当しない者の一部又は全部を外部利用者として特定する特定部13として機能する。
ここで、特定関係のSNS利用者のうち、直接ゴルフ友達Ug1又は間接ゴルフ友達Ug2のいずれにも該当しない者は
図50に示すSNS利用者Jであり、表示対象の外部利用者はその一部又は全部である。
そして、表示制御部16は、直接ゴルフ友達Ug1(第1の特定利用者)及び間接ゴルフ友達Ug2(第2の特定利用者)と外部利用者とを区別できる関係図を端末装置2の表示部に表示させる。例えば、
図51に示す領域Y3や領域Y4等に外部利用者を表示させても良い。
【0118】
(4)上述した第2実施形態では、間接SNS友達Uf2をゴルフ情報サービスへの参加に招待することによって、所定の利用者の直接のゴルフ友達となる場合があることを、
図44を参照して説明した(部分Fx)。この場合、管理サーバ1Aの特定部13は(
図39参照)、直接ゴルフ友達Ug1(第1の特定利用者)のうち、所定の利用者(所定の利用者)と友達関係があるSNS利用者(第2サービス利用者)と更に友達関係がある者を特定ゴルフ友達Ug3(第3の特定利用者:
図44の部分Fx)として特定し、表示制御部16は、特定ゴルフ友達Ug3を他のゴルフ友達と区別できる関係図又は特定ゴルフ友達Ug3を間接ゴルフ友達Ug2に含ませる関係図を端末装置2の表示部に表示させるようにしてもよい。
【0119】
より具体的には、特定ゴルフ友達Ug3を他のゴルフ友達と区別できる関係図としては、例えば、特定ゴルフ友達Ug3のアイコンを他のゴルフ友達のアイコンと、大きさ、色、又は枠の少なくとも一つが異なるように表示すればよい。また、特定ゴルフ友達Ug3を間接ゴルフ友達Ug2に含ませる関係図では、特定ゴルフ友達Ug3のアイコンを他の間接ゴルフ友達Ug2アイコンと、大きさ、色、又は枠の少なくとも一つが異なるように表示すればよい。
図52に示す例では、特定ゴルフ友達のアイコンVが、間接ゴルフ友達Ug2を表示する領域Y2に配置され、他の間接ゴルフ友達Ug2のアイコンと区別できるように、アイコンの大きさが相対的に大きくなっている。
【0120】
(5)上述した各実施形態及び各変形例では、招待処理において、既にゴルフ利用者となっているSNS利用者は、招待候補者から除く処理が実行されたが(
図35のS122参照)、本発明はこれに限定されるものではなく、既にゴルフ利用者となっている者を含めてもよい。この場合は、ゴルフ利用者でない候補者と識別できる態様でゴルフ利用者を表示すればよい。例えば、登録済みのゴルフ利用者には登録済みであることを示す印を付加して、リスト後方に表示させるようにしても良い。
【0121】
更に、管理サーバ1において、招待について、アクション元の識別情報UID、アクション先の識別情報UID、及びステータスを対応づけて記憶する招待テーブルを記憶部17に格納してもよい。ステータスを参照することによって、承諾、申請中の状態が識別可能となる。特定部13は、招待テーブルを参照して、招待申請中のSNS利用者を特定する。そして、招待申請中の招待候補者を他の招待候補者と識別できるように表示させてもよい。例えば、招待申請中の招待候補者には招待済みであることを示す印などを付加してリスト後方に表示させても良いし、あるいは、招待申請中のSNS利用者は招待候補者から除いて非表示としても良い。
【0122】
また、招待テーブルを追加するのではなく、ゴルフ利用者情報テーブルTBL11に招待のアクション元であるゴルフ利用者の識別情報UIDに対応づけて、アクション先であるSNS利用者の識別情報UIDと招待申請中であることを示すステータスを記録しても良い。この場合は、アクション先であるSNS利用者が、ゴルフ利用者として登録すれば、ステータスを変更すればよい。さらに、招待申請日時も記録しておき、所定期間経過しても登録されずステータスに変動がなければ、自動的にステータスをタイムアウト等としたり、SNS利用者の識別情報UIDとステータスを消去しても良い。
【0123】
(6)上述した各実施形態及び各変形例では、直接SNS友達Uf1及び間接SNS友達Uf2をゴルフ情報サービスへの参加の招待の対象としたが、本発明はこれに限定されるものではなく、SNS上でのSNS利用者の活動内容に応じて招待候補者を絞り込んでもよい。
具体的には、直接SNS友達Uf1及び間接SNS友達Uf2が管理するマイページにおいて、これらの者が参照しているニュースなどの記事に、「ゴルフ」や「ラウンド」などの所定のキーワードがあり、且つ未だゴルフ友達になっておらず、招待した履歴もないSNS利用者を特定部13で抽出し、招待候補者に表示するようにしても良い。
直接SNS友達Uf1及び間接SNS友達Uf2のマイページにおいて、特定の情報欄(例えば趣味(好きなもの)欄)に、「ゴルフ」等の所定のキーワードがあり、且つ未だゴルフ友達になっておらず、招待した履歴もないSNS利用者を特定部13で抽出し、招待候補者に表示するようにしても良い。
これらの抽出処理を実行するためのキーワードは、管理サーバ1又は1Aの記憶部17に記憶しておけば良い。
加えて、抽出処理で抽出した特定招待候補者と、直接SNS友達Uf1及び間接SNS友達Uf2を混在させて招待候補者としても良い。この場合には、特定招待候補者を招待候補者と識別可能な態様で表示させることが好ましい。例えば、特定招待候補者のアイコンに特定招待候補者であることを示す印を付加しても良い。
更に、
図53に示すように、友達リストを表示するとともに招待リストを表示し、招待したい友達の帯をドラッグし、友達リストから招待リストにドロップすることで招待リストに表示されるようにしても良い。
【0124】
(7)上述した各実施形態及び各変形例では、管理サーバ1又は1Aが提供するサービスとして、ゴルフ情報サービスを一例として説明したが、本発明はこれに限定されるものではなく、管理サーバ1又は1Aはどのようなサービスを提供するものであってもよい。例えば、利用者同士の共通のテーマに基づいて、アプリケーション上で特定の関係を構築するすべてのものに適用できる。共通のテーマは、マラソン、バドミントン等のスポーツや、将棋、ゲームなどの趣味的なものであってもよいし、ビジネスに関するものあってもよい。また、特定の関係は、友達関係に限定されない。例えば、上司と部下の関係であってもよいし、問屋と小売の関係であってもよい。要は、一定の規則に基づいて構築される関係であればどのようなものであってもよい。
【0125】
(8)上述した各実施形態及び各変形例では、利用者(ゴルフ利用者)に所定の対象についてサービスを提供するために用いられる装置として、管理サーバ1又は1A、及び端末装置2Aを一例として説明したが、本発明はこれに限定されるものではなく、パーソナルコンピュータなどの情報処理装置であってもよい。そのような情報処理装置は、
図37に示す端末装置2Aと類似する。
図46に示す端末装置2Aの構成要素と同一の構成要素に同一の符号を付すとすれば、情報処理装置は、以下のように構成される。
【0126】
情報処理装置は、利用者(ゴルフ利用者)を一意に識別する識別情報のうち所定の利用者の識別情報を取得する取得部201と、取得部201で取得した識別情報に基づいて、利用者同士の特定の関係を示す特定関係情報を参照する参照部202と、参照部202で参照した特定関係情報に基づいて、所定の利用者と特定の関係を有する特定利用者を特定する特定部203と、特定部203で特定した特定利用者について、所定の対象に関する活動を示す活動情報に基づいて、所定の対象に関する活動を評価する評価部204と、評価部204の評価結果に基づいて、特定利用者を配置した画面を表示部208に表示させる表示制御部206とを備える。なお、情報処理装置においては、外付けのディスプレイに画像を表示させることもあり得るので、表示部は必須の構成要素ではない。また、特定関係情報は、外部の装置から取得してもよい。
【0127】
(9)上述した実施形態及び変形例では、
図3に示すゴルフフレンドマップをマイページの一例として説明したが、本発明はこれに限定されるものではない。例えば、
図54及び
図55に示すようにゴルフ友達GF1〜GF5のアイコンを、評価部14の評価結果に応じて所定の利用者Sのアイコンからの距離を定めてもよい。この例では、評価部14は、表示の優先順位を直接ゴルフ友達Ug1であるゴルフ友達GF1→GF2→GF3→GF4→GF5の順に定めている。そして、ゴルフ友達を表示する領域としては、最も優先順位の高いゴルフ友達を領域P1に、次に優先順位の高いゴルフ友達を領域P2に、次に優先順位の高いゴルフ友達を領域P3、次に優先順位の高いゴルフ友達を領域P3に、次に優先順位の高いゴルフ友達を領域P4に、次に優先順位の高いゴルフ友達を領域P5に表示する。
ゴルフ友達GF1〜GF5と間接ゴルフ友達Ug2とは、
図54及び
図55に示すように線分で結んでもよい。これにより、階層的な友達関係をより明確に把握するこが可能となる。
【0128】
(10)上述した実施形態及び変形例では、活動データベースDBは、登録情報テーブルTBLaと利用者ログ管理テーブルTBLbとを備え、登録情報と利用情報とを管理する情報管理部として機能したが、本発明はこれに限定されるものではなく、登録情報と利用情報とのうち少なくとも一方を活動データベースDB(情報管理部)が管理してもよい。
この場合、活動情報には、利用情報と登録情報との少なくとも一方が含まれる。そして、評価部14(204)は、情報管理部で管理する利用情報と登録情報との少なくとも一方に基づいて、直接ゴルフ友達Ug1及び間接ゴルフ友達Ug2の一部又は全部について、ゴルフに関する活動を評価してもよい。
【0129】
(11)上述した実施形態及び変形例では、アクション種別情報kindは、各種の専用ボタンがクリックされることによって特定されていた。しかしながら、本発明はこれに限定されるものではなく、メッセージの送付によってアクション種別情報kindを特定してもよい。例えば、
図56に示す入力フォームを表示させ、カテゴリのプルダウンメニューにおける表示項目のいずれかを選択するようにしてもよい。この場合には、プルダウンメニューの項目の選択によってアクション種別情報kindが決定される。
図56の例では、プルダウンメニューに、ゴルフに誘う、ゴルフ報告、及びギア報告の3つの選択肢が表示される。ギア報告とは、「クラブ買ったぞ!」や「XXXドライバーよかった!」などのクラブに関する投稿を行う場合に用いられる。
【0130】
(12)上述した実施形態及び変形例では、ゴルフ利用者ごとに第1個別ログファイルFL1及び第2個別ログファイルFL2を生成したが、本発明はこれに限定されるものではなく、評価値Hを生成する際に利用者ログ管理テーブルTBLbから必要な情報を抽出するようにしてもよい。また、活動データベースDBをアクション種別情報kindごとに分けられた複数の個別テーブルで構成し、複数の個別テーブルの各々について、ゴルフ利用者ごとの個別ログファイルを生成してもよい。この場合、個別ログファイルごとに更新タイミングを設定することができる。例えば、ゴルフ報告に関する個別ログファイルの更新頻度を高くすると、ゴルフ報告を行ったゴルフ利用者については、表示優先順位を高くすることができる。
【0131】
(13)上述した実施形態及び変形例では、項目1〜項目6に基づいて評価値Hを算出したが、これらの項目1〜項目6の少なくとも一つに基づいて評価値Hを算出してもよい。例えば、項目1のみ基づいて評価値Hを算出してもよいし、項目1及び項目3に基づいて評価値Hを算出してもよい。
さらに、アクションの日時に基づいて表示優先順位を決定してもよい。この場合、第1にCPU30は、利用者ログ管理テーブルTBLbを参照して、表示対象となるゴルフ利用者の識別情報UIDとアクション元識別情報UID_Fromが一致するレコードを抽出する。第2に、CPU30は、タイムスタンプが最新のレコードを抽出する。第3に、これを全ての表示対象となるゴルフ利用者について実行し、抽出した最新のレコードを記録日時が新しい順にソートして、表示優先順位を決定する。なお、CPU30は、抽出した最新のレコードをタイムスタンプが新しい順にソートする代わりに、記録日時と現在時刻との差分を算出し、差分の時間が小さい順にレコードをソートしてもよい。
【0132】
また、利用情報及び登録情報に基づいて表示優先順位を決定する態様は以下の態様であってもよい。この場合、登録情報テーブルTBLbに記録されるラウンド頻度は、ランクではなく、ラウンドの頻度を日数に換算した換算日が記録される。
図6に示すプルダウンメニューによってラウンド頻度が入力された場合、例えば、
図57に示すテーブルによって日数に換算される。
第1に、CPU30は、登録情報テーブルTBLaを参照して、表示対象となるゴルフ利用者の識別情報UIDと一致するレコードを抽出し、抽出したレコードのラウンド情報を特定する。第2にCPU30は、利用者ログ管理テーブルTBLbを参照して、アクション種別情報kindがゴルフ報告を示すレコードのうち、表示対象となるゴルフ利用者の識別情報UIDとアクション元識別情報UID_Fromとが一致するレコードを抽出する。第3にCPU30は、これを全ての表示対象となるゴルフ利用者について実行し、アクション元識別情報UID_Fromごとにタイムスタンプが最新のレコードを抽出する。第4にCPU30は、抽出した最新のレコードの記録日と現在日との差分を経過日を算出する。例えば、現在日が2012年3月29日でゴルフに行ってきた場合に記録するゴルフ報告の記録日が2012年1月15日の場合、経過日は74日となる。
【0133】
第5にCPU30は、抽出した最新のレコードのそれぞれについて、経過日とラウンド頻度の換算日との差分を差分日として算出する。例えば、経過日が74日で、ラウンド頻度の換算日が30日の場合、差分日は−44日となる。差分日が負の値であれば、ラウンド頻度を考慮すると、ゴルフ利用者がゴルフに行きたくなるタイミングである。そして、差分日が小さい程、ゴルフに行きたくなる程度が高いと推定することができる。第6にCPU30は、差分日が小さい順にレコードをソートする。第7に、CPU30は、ソートされたレコードの順に表示優先順位を決定する。これにより、ゴルフに行きたい程度の順にゴルフ利用者がマイページのゴルフフレンドマップ上に配置されるので、ゴルフ利用者は、ゴルフに誘うと賛同する可能性の高いゴルフ友達をゴルフフレンドマップ上で一見して知ることができるといった利点がある。
【0134】
(14)なお、本発明における機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することとしてもよい。なお、ここでいう「コンピュータシステム」とは、OSや周辺機器等のハードウェアを含むものとする。また、「コンピュータシステム」は、インターネットやWAN、LAN、専用回線等の通信回線を含むネットワークを介して接続された複数のコンピュータ装置を含んでもよい。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ROM、CD−ROM等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、ネットワークを介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ(RAM)のように、一定時間プログラムを保持しているものも含むものとする。また、上記プログラムは、上述した機能の一部を実現するためのものであってもよい。さらに、上述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル(差分プログラム)であってもよい。また、本発明における機能またはその一部を実現するためのプログラムを配信する配信サーバ及び当該配信サーバに備えられた記憶媒体、及び当該配信サーバの外部に存在し、当該プログラムを前記配信サーバにより配信するために記憶している記憶媒体も、本発明の範囲に含まれる。
【0135】
また、上述した機能の一部または全部を、LSI(Large Scale Integration)等の集積回路として実現してもよい。上述した各機能は個別にプロセッサ化してもよいし、一部、または全部を集積してプロセッサ化してもよい。また、集積回路化の手法はLSIに限らず専用回路、または汎用プロセッサで実現してもよい。また、半導体技術の進歩によりLSIに代替する集積回路化の技術が出現した場合、当該技術による集積回路を用いてもよい。
【0136】
(15)本発明は上述の各実施形態及び変形例に限定されるものではなく、本発明の趣旨の範囲内での変更は本発明に含まれるものである。