JP2014035586A - イベント管理装置、イベント管理装置の制御方法、イベント管理装置のプログラム - Google Patents

Abstract

【課題】コミュニケーションを活性化する。
【解決手段】管理サーバ１は、友達情報を参照可能な関係情報参照部１３と、所定のゴルフ利用者の端末装置２から要求を受信すると、所定のゴルフ利用者と友達関係を有するゴルフ友達を特定可能な第１特定部１４と、記憶部１２を参照して、ゴルフ友達について実行可能日を取得可能な取得部１６と、所定のゴルフ利用者の端末装置２から要求を受信すると、当該端末装置２に対して、ゴルフ友達について実行可能日を表示させるための表示情報を出力可能な出力部１７と、所定のゴルフ利用者の端末装置２において、ゴルフ友達の実行可能日が選択された場合、所定のイベントについて当該ゴルフ友達を勧誘するための入力を受け付け可能とする勧誘受付部１８とを備える。
【選択図】図１

Description

本発明は、あるサービスで特定の関係になった特定利用者を所定のイベントへ勧誘する行為を行い易くする技術に関する。

近年、インターネット上で提供するサービスが急速に普及している。この種のサービスの一つとして、ＳＮＳ（Ｓocial Ｎetworking Ｓervice）を提供するウェブサイトが知られている。このウェブサイトでは、利用者同士のコミュニケーションを図るため、友達関係を構築できるようになっている。そして、友達同士で投稿、チャット、メールといったコミュニケーションのツールが提供として提供する手段が利用されている（例えば、特許文献１）。
このような友達関係を活用したイベント機能では、主催者が希望者を募り、それに応じた利用者が集まってくる形式が一般的である。

特表２００９−５２０２７６号公報

しかしながら、ＳＮＳの利用者の全てが、イベントに対して能動的に動けるわけではない。そのようなやや消極的な利用者は、自らが他の利用者をイベントに誘うことには抵抗がある一方、他の利用者とイベントに参加したいと考える者が多い。
本発明は、上述した事情に鑑みてなされたものであり、イベントに参加したいという意思を事前に発信し、他の利用者からイベントに誘われ易くして、コミュニケーションの活性化を図ることなどを解決課題とする。

以上の課題を解決するために本発明が採用する手段を以下に説明する。なお、本発明の理解を容易にするために以下では図面の参照符号を便宜的に括弧書で付記するが、本発明を図示の形態に限定する趣旨ではない。

上述した課題を解決するため、本発明に係るイベント管理装置は、複数の第１利用者の端末装置（２）と通信可能なイベント管理装置（１Ａ）であって、所定のイベントの実行が可能な実行可能日を第１利用者から受け付け可能な実行可能日受付部（１１）と、前記実行可能日受付部によって受け付けられた前記実行可能日を、当該第１利用者を一意に識別する識別情報と関連付けて記憶可能な記憶部（１２）と、前記複数の第１利用者のうち所定の第１利用者と特定の関係を有する第１の特定利用者を特定可能な第１特定部（１４）と、前記記憶部を参照して、前記第１の特定利用者について前記実行可能日を取得可能な取得部（１６）と、前記所定の第１利用者の端末装置の操作に応じて、当該端末装置に対して、前記第１の特定利用者について前記実行可能日を表示させるための表示情報を出力可能な出力部（１７）と、前記所定の第１利用者の端末装置において、前記第１の特定利用者について前記実行可能日が選択された場合、前記所定のイベントについて当該第１の特定利用者を勧誘するための入力を受け付け可能とする勧誘受付部（１８）と、を備える。

この発明によれば、イベント管理装置は、第１利用者からイベントの実行が可能な実行可能日を受け付けて記憶する。イベントに勧誘しようとする第１利用者は、当該第１利用者と特定の関係を有する第１の特定利用者が登録した実行可能日を閲覧可能である。そして、当該第１利用者が第１の特定利用者の実行可能日を選択すると、イベント管理装置は、第１の特定利用者を勧誘するための入力を受け付ける。この結果、自らが他の第１利用者をイベントに誘うことには抵抗がある第１利用者であっても、事前に実行可能日を公開することによって、他の第１利用者から誘って貰い易くできる。よって、コミュニケーションの活性化を図ることができる。
なお、勧誘受付部は、「所定のイベントについて当該第１の特定利用者を勧誘するための入力を受け付け可能とする」が、その具体的な態様には、第１態様と第２態様を含む。第１態様は、第１利用者の端末装置で実行可能日が選択されたら、選択された情報をイベント管理装置が受信し、勧誘画面を端末に送信し、端末で勧誘入力を行い、その入力結果を受け付けるものである。第２態様は、端末装置に実行可能日を送信する際、実行可能日が選択された場合に備えて勧誘画面も同時に送っておき、第１利用者が実行可能日を選択すると、イベント管理装置に送信することなく勧誘画面に切り替わり、勧誘入力があると入力結果をイベント管理装置が受け付けるものである。

また、本発明に係るイベント管理装置は、第１利用者に所定の対象に関する第１サービスを提供し、前記第１利用者を含む第２利用者に対して第２サービスを提供すると共に前記第２利用者同士の特定の関係を示す特定関係情報を管理する外部管理装置（３）及び前記第１利用者の端末装置（２）と通信可能なイベント管理装置（１）であって、所定のイベントの実行が可能な実行可能日を前記第１利用者から受け付け可能な実行可能日受付部（１１）と、前記第１利用者を一意に識別する識別情報を記憶すると共に、前記実行可能日受付部によって受け付けられた前記実行可能日を、当該第１利用者の前記識別情報と関連付けて記憶可能な記憶部（１２）と、所定の第１利用者の識別情報に基づいて、前記外部管理装置で管理する前記所定の第１利用者の前記特定関係情報を参照可能な関係情報参照部（１３）と、前記所定の第１利用者の端末装置（２）から要求を受信すると、前記記憶部に記憶されている前記第１利用者の前記識別情報及び前記関係情報参照部を用いて参照した前記特定関係情報に基づいて、前記所定の第１利用者と前記特定の関係を有する第２利用者のうち、前記第１利用者に該当する第１の特定利用者を特定可能な第１特定部（１４）と、前記記憶部を参照して、前記第１の特定利用者について前記実行可能日を取得可能な取得部（１６）と、前記所定の第１利用者の端末装置から要求を受信すると、当該端末装置に対して、前記前記第１の特定利用者について前記実行可能日を表示させるための表示情報を出力可能な出力部（１７）と、前記所定の第１利用者の端末装置において、前記第１の特定利用者についての前記実行可能日が選択された場合、前記所定のイベントについて当該第１の特定利用者を勧誘するための入力を受け付け可能とする勧誘受付部（１８）と、を備える。

この発明によれば、第１サービスの提供を受ける第１利用者は第２サービスの提供を受ける第２利用者に含まれる。したがって、第２サービスのプラットフォームを利用して第１サービスを提供することが可能となる。特定の関係は第２サービスで管理しており、第１サービスではこれを利用する。したがって、イベント管理装置の処理負荷を軽減できる。また、イベント管理装置は、第１利用者からイベントの実行が可能な実行可能日を受け付けて記憶する。イベントに勧誘しようとする第１利用者は、当該第１利用者と特定の関係を有する第１の特定利用者が登録した実行可能日を閲覧可能である。そして、当該第１利用者が第１の特定利用者の実行可能日を選択すると、イベント管理装置は、第１の特定利用者を勧誘するための入力を受け付ける。この結果、自らが他の第１利用者をイベントに誘うことには抵抗がある第１利用者であっても、事前に実行可能日を公開することによって、他の第１利用者から誘って貰い易くできる。よって、コミュニケーションの活性化を図ることができる。
なお、勧誘受付部は、「所定のイベントについて当該第１の特定利用者を勧誘するための入力を受け付け可能とする」が、その具体的な態様に、上述した第１態様と第２態様とが含まれる点は、上述した発明と同様である。

上述したイベント管理装置において、前記関係情報参照部（１３）は、前記第１の特定利用者の識別情報に基づいて、前記外部管理装置で管理する前記第１の特定利用者の前記特定関係情報を参照可能であり、前記第１特定部（１４）は更に、前記記憶部（１２）に記憶されている前記第１利用者の前記識別情報及び前記関係情報参照部を用いて参照した前記第１の特定利用者の前記特定関係情報に基づいて、前記第１の特定利用者と前記特定の関係を有する第２利用者のうち、前記第１利用者に該当する第２の特定利用者を特定可能であり、前記取得部（１６）は更に、前記記憶部を参照して、前記第２の特定利用者についての前記実行可能日を取得可能であり、前記出力部（１７）は更に、当該端末装置に対して、前記第２の特定利用者についての前記実行可能日を表示させるための表示情報を出力可能であり、前記勧誘受付部（１８）は更に、前記所定の第１利用者の端末装置において、前記第２の特定利用者についての前記実行可能日が選択された場合、前記所定のイベントについて選択された利用者を勧誘するための入力を受け付け可能とする。
この発明によれば、第２の特定利用者（例えば、ゴルフ友達のゴルフ友達）についても、実行可能日を閲覧して、イベントに勧誘することが可能となる。この結果、より一層、イベントに誘われ易い環境を提供でき、コミュニケーションを活性化することができる。

上述したイベント管理装置において、前記関係情報参照部（１３）は、前記第１の特定利用者の識別情報に基づいて、前記外部管理装置で管理する前記第１の特定利用者の前記特定関係情報を参照可能であり、前記第１特定部（１４）は更に、前記記憶部（１２）に記憶されている前記第１利用者の前記識別情報及び前記関係情報参照部を用いて参照した前記第１の特定利用者の前記特定関係情報に基づいて、前記第１の特定利用者と前記特定の関係を有する第２利用者のうち、前記第１利用者に該当する第２の特定利用者を特定可能であり、前記取得部（１６）は更に、前記記憶部を参照して、前記第２の特定利用者についての前記実行可能日を取得可能であり、前記出力部（１７）は更に、当該端末装置に対して、前記第２の特定利用者についての前記実行可能日を表示させるための表示情報を出力可能であり、前記所定の第１利用者の端末装置（２）において、前記第２の特定利用者についての前記実行可能日が選択された場合、前記所定の第１利用者と特定の関係を有しており、且つ当該第２の特定利用者と前記特定の関係を有している前記第１の特定利用者を特定可能である第２特定部（１５）を更に備える。
この発明によれば、所定の第１利用者と特定の関係を有しており、且つ当該第２の特定利用者と特定の関係を有している第１の特定利用者を特定するこができる。

また、上述したイベント管理装置において、前記第２特定部によって特定された前記第１の特定利用者が前記所定の第１利用者によって選択された場合、前記出力部は、当該所定の第１利用者と前記第２の特定利用者との仲介を当該第１の特定利用者に対して送信するための入力を受け付け可能な表示情報を出力することが好ましい。この発明によれば、本人と第２の特定利用者（例えば、ゴルフ友達のゴルフ友達）とに共通の第１の特定利用者（例えば、ゴルフ友達）に仲介を依頼することが可能となる。この場合、共通の第１の特定利用者には仲介を依頼するが、必ずしもイベントの勧誘の対象に含まれるとは限らない。

また、上述したイベント管理装置において、前記実行可能日受付部が、前記実行可能日を前記第１利用者から受け付けると、外部装置に対して、当該第１利用者の識別情報と前記実行可能日とを送信する送信部を備えることが好ましい。この発明によれば、実行可能日をエクスポートできるので、他の外部装置で実行可能日を公開することが可能となる。

次に、本発明に係るイベント管理装置の制御方法は、第１利用者に所定の対象に関する第１サービスを提供し、前記第１利用者を含む第２利用者に対して第２サービスを提供すると共に前記第２利用者同士の特定の関係を示す特定関係情報を管理する外部管理装置及び前記第１利用者の端末装置と通信可能であって、前記第１利用者を一意に識別する識別情報を記憶する記憶部を備えたイベント管理装置を制御する方法であって、所定のイベントの実行が可能な実行可能日を前記第１利用者から受け付け、受け付けられた前記実行可能日を、当該第１利用者の前記識別情報と関連付けて前記記憶部に記憶し（Ｓ５１０）、所定の第１利用者の識別情報に基づいて、前記外部管理装置で管理する前記所定の第１利用者の前記特定関係情報を参照し、前記所定の第１利用者の端末装置から要求を受信すると、前記記憶部に記憶されている前記第１利用者の前記識別情報及び参照した前記特定関係情報に基づいて、前記所定の第１利用者と前記特定の関係を有する第２利用者のうち、前記第１利用者に該当する第１の特定利用者を特定し（Ｓ６０１）、前記記憶部を参照して、前記第１の特定利用者について前記実行可能日を取得し、前記所定の第１利用者の端末装置から要求を受信すると、当該端末装置に対して、前記前記第１の特定利用者について前記実行可能日を表示させるための表示情報を出力し（Ｓ６０３、Ｓ６０６）、前記所定の第１利用者の端末装置において、前記第１の特定利用者について前記実行可能日が選択された場合、前記所定のイベントについて当該第１の特定利用者を勧誘するための入力を受け付ける（Ｓ７０２）、ことを特徴とする。

次に、本発明に係るイベント管理装置のプログラムは、第１利用者に所定の対象に関する第１サービスを提供し、前記第１利用者を含む第２利用者に対して第２サービスを提供すると共に前記第２利用者同士の特定の関係を示す特定関係情報を管理する外部管理装置及び前記第１利用者の端末装置と通信可能であって、前記第１利用者を一意に識別する識別情報を記憶する記憶部及びコンピュータを備えたイベント管理装置のプログラムであって、前記コンピュータ（３０）を、所定のイベントの実行が可能な実行可能日を前記第１利用者から受け付け可能な実行可能日受付部（１１）と、前記実行可能日受付部によって受け付けられた前記実行可能日を、当該第１利用者の前記識別情報と関連付けて記憶部に記憶させる制御部（３０）と、所定の第１利用者の識別情報に基づいて、前記外部管理装置で管理する前記所定の第１利用者の前記特定関係情報を参照可能な関係情報参照部（１３）と、前記所定の第１利用者の端末装置から要求を受信すると、前記記憶部に記憶されている前記第１利用者の前記識別情報及び前記関係情報参照部を用いて参照した前記特定関係情報に基づいて、前記所定の第１利用者と前記特定の関係を有する第２利用者のうち、前記第１利用者に該当する第１の特定利用者を特定する第１特定部（１４）と、前記記憶部を参照して、前記第１の特定利用者について前記実行可能日を取得可能な取得部（１６）と、前記所定の第１利用者の端末装置から要求を受信すると、当該端末装置に対して、前記前記第１の特定利用者について前記実行可能日を表示させるための表示情報を出力可能な出力部（１７）と、前記所定の第１利用者の端末装置において、前記第１の特定利用者について前記実行可能日が選択された場合、前記所定のイベントについて当該第１の特定利用者を勧誘するための入力を受け付け可能とする勧誘受付部（１８）として、機能させることを特徴とする。

本発明の第１実施形態に係るサービス提供システムのブロック図である。 ＳＮＳ利用者とゴルフ利用者の関係を示す説明図である。 端末装置の表示画面の一例を示す説明図である。 ゴルフ利用者情報テーブルのデータ構造の一例を示す説明図である。 登録データテーブルのデータ構造の一例を示す説明図である。 ＳＮＳ利用者情報テーブルのデータ構造の一例を示す説明図である。 ＳＮＳ友達情報テーブルのデータ構造の一例を示す説明図である。 管理サーバの構成を示すブロック図である。 端末装置の構成を示すブロック図である。 表示処理に関するサービス提供システムの動作シーケンスを示すシーケンス図である。 表示処理に関するサービス提供システムの動作シーケンスを示すシーケンス図である。 本人と友達関係にあるＳＮＳ友達を特定する処理を示す説明図である。 ＳＮＳ友達のＳＮＳ友達を特定する処理を示す説明図である。 「ゴルフ友達」と「ゴルフ友達のゴルフ友達」の配置を説明するための説明図である。 登録処理の処理内容を示すフローチャートである。 実行可能日を登録する際の画面の一例を示す説明図である。 実行可能日を登録する際の画面の一例を示す説明図である。 カレンダー表示による実行可能日を登録する際の画面の一例を示す説明図である。 リスト表示による実行可能日を登録する際の画面の一例を示す説明図である。 月を選択した場合の実行可能日を登録する際の画面の一例を示す説明図である。 実行可能日表示処理の処理内容を示すフローチャートである。 ゴルフスケジュールのカレンダー表示の画面の一例を示す説明図である。 ゴルフスケジュールのリスト表示の画面の一例を示す説明図である。 イベント勧誘処理の処理内容を示すフローチャートである。 イベント勧誘ページの画面の一例を示す説明図である。 本発明の第２実施形態に係るサービス提供システムのブロック図である。 週単位の登録を含むゴルフスケジュールのカレンダー表示の画面の一例を示す説明図である。 月単位の登録を含むゴルフスケジュールのカレンダー表示の画面の一例を示す説明図である。 共通ゴルフ友達を表示する画面の一例を示す説明図である。 メッセージを書き込む画面の一例を示す説明図である。 メッセージ送信の確認画面の一例を示す説明図である。 メッセージ送信の完了を示す画面の一例を示す説明図である。

以下、実施形態として、本発明に係る管理サーバを用いたサービス提供システムについて、図面を参照しつつ説明する。
＜第１実施形態＞
＜１．サービス提供システムの構成＞
図１は、本発明の実施形態に係るサービス提供システム１００のブロック図である。このサービス提供システム１００は、インターネットなどの通信網ＮＥＴを介して、ゴルフ情報アプリケーション（第１サービスの一例）を提供する管理サーバ１、利用者の端末装置２、ＳＮＳサイトを提供する外部管理サーバ３を備える。以下の説明では、管理サーバ１のゴルフ情報アプリケーションを利用する利用者をゴルフ利用者（第１利用者の一例）、外部管理サーバ３のＳＮＳの利用者をＳＮＳ利用者（第２利用者の一例）と称する。
外部管理サーバ３が提供するＳＮＳサイトは、利用者同士のコミュニケーションツール（すなわち、利用者の間で行われるメッセージ管理情報の授受。例えば、掲示板、メール、チャット等）を提供する。また、ＳＮＳサイトにおいて、友達関係は、アクション元のＳＮＳ利用者が友達申請を行い、これをアクション先のＳＮＳ利用者が承認することによって構築される。外部管理サーバ３は、ＳＮＳ利用者同士の特定の関係であるＳＮＳ友達関係を示す友達情報（特定関係情報の一例）を管理する。

利用者の端末装置２は、通信網ＮＥＴを介した通信が可能であり、例えば、パーソナルコンピュータ、携帯電話機、スマートフォン、タブレット端末などが該当する。
管理サーバ１は、特定のサービスを提供する。本実施形態の管理サーバ１は、ゴルフ情報アプリケーションをゴルフ利用者に提供する。本実施形態では、ゴルフ情報アプリケーションの提供を一例として説明するが、管理サーバ１は、ゲームなどのアプリケーションの提供、ホテルの予約などを含む旅行情報の提供、コンサート情報の提供を行うものであってもよい。

外部管理サーバ３が提供するＳＮＳ（第２サービスの一例）においては、掲示板、メール、チャット等を利用することができるだけでなく、ゲームや実用的なツールなどのソーシャルアプリケーションを利用することができる。このソーシャルアプリケーションは、前記ＳＮＳの提供者以外の提供者によっても提供されることがあり、ソーシャルアプリケーションを利用するか否か、あるいは、どのソーシャルアプリケーションを利用するかは、ＳＮＳ利用者が任意に決定できるようになっている。ＳＮＳ利用者がソーシャルアプリケーションの利用を希望する場合には、当該ソーシャルアプリケーションが当該ＳＮＳ利用者のプロフィール情報やＳＮＳ上の前記友達情報にアクセスする機能や、当該ソーシャルアプリケーションが当該ＳＮＳ利用者の代わりに掲示板等に投稿する機能等についての許可を求める場合がある。ソーシャルアプリケーションによっては、ＳＮＳ利用者がこれらの機能について許可したことを以て、当該ソーシャルアプリケーションの利用者になる場合がある。このようなソーシャルアプリケーションは、一般に、ＳＮＳサイト内に当該ソーシャルアプリケーションの画面が表示されるため、ＳＮＳ利用者にとっては、あたかもＳＮＳのサービスの一つを利用しているような感覚で、ソーシャルアプリケーションを利用することになる。
本実施形態の管理サーバ１によって提供されるゴルフ情報アプリケーションは、一例として、上述のようなソーシャルアプリケーションにより提供されるサービスである。本実施形態においては、ＳＮＳ利用者がゴルフ情報アプリケーションの利用者であるゴルフ利用者になるためには、ゴルフ情報アプリケーションが当該ＳＮＳ利用者のプロフィール情報やＳＮＳ上の前記友達情報にアクセスする機能や、ゴルフ情報アプリケーションが当該ＳＮＳ利用者の代わりに掲示板等に投稿する機能等についての承認を行うようになっている。ＳＮＳ利用者がこの承認を行うことにより、当該ＳＮＳ利用者はゴルフ利用者となる。

つまり、ゴルフ利用者は、図２に示すようにＳＮＳ利用者に含まれる。換言すれば、管理サーバ１は、ゴルフ利用者にゴルフ情報アプリケーションを提供し、外部管理サーバ３のＳＮＳ利用者に限って、ゴルフ情報アプリケーションのゴルフ利用者として登録する。一方、外部管理サーバ３は、ゴルフ利用者を含むＳＮＳ利用者に対してＳＮＳを提供する。このように、ゴルフ利用者はＳＮＳ利用者に含まれ、しかも、上述のようにゴルフ情報アプリケーションがＳＮＳ利用者のプロフィール情報やＳＮＳ上の友達情報にアクセスする機能や、ゴルフ情報アプリケーションがＳＮＳ利用者の代わりに掲示板等に投稿する機能等について、ＳＮＳ利用者の承認を得ている。したがって、第１実施形態の管理サーバ２は、ゴルフ利用者の友達関係をＳＮＳ利用者の友達関係を用いて管理する。即ち、図２に示すように、本人とＳＮＳ友達であり、且つゴルフ利用者をゴルフ友達とし、ＳＮＳ友達のＳＮＳ友達であり、且つゴルフ利用者をゴルフ友達のゴルフ友達として管理する。

図１を参照して、管理サーバ１の機能を説明する。管理サーバ１は、ゴルフ利用者情報テーブルＴＢＬ１１、利用者ログ管理テーブルＴＢＬ１３、及び登録日データテーブルＴＢＬ１５を記憶した記憶部１２を備える。また、記憶部１２には、管理サーバ１を制御するプログラムが記憶されている。ゴルフ利用者情報テーブルＴＢＬ１１には、ゴルフ利用者を一意に識別する識別情報ＵＩＤなどが格納されている。利用者ログ管理テーブルＴＢＬ１３には、ゴルフ利用者のゴルフ情報アプリケーションの利用履歴が記録される。登録日データテーブルＴＢＬ１５には、ゴルフ利用者が登録したゴルフに行きたい日が識別情報ＵＩＤごとに記録されている。

管理サーバ１は、所定のイベントの実行が可能な実行可能日をゴルフ利用者から受け付け可能な実行可能日受付部１１を備える。
所定のイベントは、例えば、ゴルフのラウンドが該当する。ゴルフ利用者が端末装置２を操作して、ゴルフのラウンドを実行可能な日を入力すると、当該端末装置２から管理サーバ１に実行可能日を含む登録要求が送信される。実行可能日受付部１１は、登録要求を受信すると実行可能日を受け付け、ゴルフ利用者の識別情報ＵＩＤと対応付けて実行可能日が記憶される。

次に、管理サーバ１は、所定のゴルフ利用者の識別情報ＵＩＤに基づいて、外部管理サーバ３で管理する所定のゴルフ利用者の友達情報を参照可能な関係情報参照部１３と、所定のゴルフ利用者の端末装置２から要求を受信すると、記憶部１２に記憶されているゴルフ利用者の識別情報ＵＩＤ及び関係情報参照部１３を用いて参照した友達情報に基づいて、所定のゴルフ利用者と友達関係を有するＳＮＳ利用者のうち、ゴルフ利用者に対応するゴルフ友達（第１の特定利用者の一例）を特定可能な第１特定部１４と、記憶部１２を参照して、ゴルフ友達について実行可能日を取得可能な取得部１６と、所定のゴルフ利用者の端末装置２から要求を受信すると、当該端末装置２に対して、ゴルフ友達について実行可能日を表示させるための表示情報を出力可能な出力部１７と、所定のゴルフ利用者の端末装置において、ゴルフ友達についての実行可能日が選択された場合、所定のイベントについて当該ゴルフ友達を勧誘するための入力を受け付け可能とする勧誘受付部１８とを備える。

本実施形態によれば、各ゴルフ利用者が実行可能日を入力することにより、管理サーバ１において、実行可能日を一元的に管理する。そして、管理サーバ１は、ゴルフ利用者からの要求に応じて、当該ゴルフ利用者のゴルフ友達の実行可能日を表示するための表示情報を生成して端末装置２に送信出力する。更に、当該ゴルフ利用者によって実行可能日が選択された場合、管理サーバ１はゴルフ友達の勧誘を可能とする。この結果、ゴルフ友達に問い合わせなくても、ゴルフ友達がゴルフに行きたいと考えている実行可能日を知ることができ、ゴルフ友達の都合の良い日にゴルフに誘うことが可能となるので、サービス提供システム１００によれば、ゴルフのコミュニケーションを活性化することができる。

また、本実施形態では、ゴルフ利用者のゴルフ友達のゴルフ友達についても、当該ゴルフ利用者の実行可能日をゴルフ利用者の端末装置２において表示できるようになっている。このため、関係情報参照部１３は、ゴルフ利用者の識別情報ＵＩＤに基づいて、外部管理サーバ３で管理するゴルフ友達の友達情報を参照可能である。また、第１特定部１４は、 記憶部１２（ゴルフ利用者情報テーブルＴＢＬ１１）に記憶されているゴルフ利用者の識別情報ＵＩＤ及び関係情報参照部１３を用いて参照したゴルフ友達の友達情報に基づいて、ゴルフ友達と友達関係を有するＳＮＳ利用者のうち、ゴルフ利用者に該当するゴルフ友達のゴルフ友達（第２の特定利用者の一例）を特定可能である。

この場合、取得部１６は、記憶部１２を参照して、ゴルフ友達のゴルフ友達についての実行可能日を取得可能である。また、出力部１７は、端末装置２に対して、ゴルフ友達のゴルフ友達についての実行可能日を表示させるための表示情報を出力可能である。更に、勧誘受付部１８は、所定のゴルフ利用者の端末装置２において、ゴルフ友達のゴルフ友達についての実行可能日が選択された場合、所定のイベントについて選択された利用者を勧誘するための入力を受け付け可能とする。これによって、ゴルフ利用者はゴルフ友達のみならず、ゴルフ友達のゴルフ友達の実行可能日も知ることができるので、ゴルフに誘う対象を拡げることが可能となる。

加えて、管理サーバ１は、所定のゴルフ利用者の端末装置２において、ゴルフ友達のゴルフ友達についての実行可能日が選択された場合、所定のゴルフ利用者と友達関係を有しており、且つ当該ゴルフ友達のゴルフ友達と友達関係を有しているゴルフ友達を特定する第２特定部１５を備える。すなわち、第２特定部１５は、所定のゴルフ利用者とゴルフ友達のゴルフ友達と共通のゴルフ友達を特定する。出力部１７は、第２特定部１５によって特定されたゴルフ友達が所定のゴルフ利用者によって選択された場合、当該所定のゴルフ利用者とゴルフ友達のゴルフ友達との仲介を当該ゴルフ友達に対して送信するための入力を受け付け可能な表示情報を出力する。所定のゴルフ利用者から見ると、ゴルフ友達のゴルフ友達は、直接のゴルフ友達ではない。このため、ゴルフ友達のゴルフ友達をゴルフに誘うことをためらうことが多い。一方、ゴルフ友達のゴルフ友達から見ると、知らないゴルフ利用者からゴルフに誘われても躊躇することが多い。本実施形態によれば、共通のゴルフ友達を介してゴルフに誘うことができるので、ゴルフ友達のゴルフ友達であってもゴルフに誘い易い環境を作ることができる。

図４にゴルフ利用者情報テーブルＴＢＬ１１のデータ構造を示す。ゴルフ利用者情報テーブルＴＢＬ１１には登録情報として複数のレコードが記録されている。１つのレコードは、ゴルフ利用者を一意に識別する識別情報ＵＩＤ、登録日、プロフィール情報、及びラウンド履歴情報を含む。本実施形態では、ゴルフ利用者の識別情報ＵＩＤは、ＳＮＳ利用者の識別情報ＵＩＤと一致するという対応関係を有している。但し、ＳＮＳ利用者の識別情報とゴルフ利用者の識別情報とは必ずしも一致する必要はなく、相違していてもよい。この場合は、ゴルフ利用者情報テーブルＴＢＬ１１のレコードにＳＮＳ利用者の識別情報とゴルフ利用者の識別情報とを対応づけて記録すればよい。

プロフィール情報は、性別、年齢、及びメールアドレスを含む。また、ラウンド履歴情報は、プレイしたゴルフ場名、スコア、及びラウンド日を含む。レコードに、その他の情報を記録してもよい。また、ゴルフ利用者情報テーブルＴＢＬ１１に記憶すべき情報として、ゴルフ利用者の識別情報ＵＩＤは必須であるが、その他の情報は省略してもよい。さらに、ゴルフ利用者情報テーブルＴＢＬ１１をキーとなる情報（例えば、識別情報ＵＩＤ）で紐づけた複数のテーブルで構成し、リレーショナルデータベースとしてもよい。なお、プロフィール情報は管理サーバ１で管理せず、外部管理サーバ３で管理することとしてもよい。

説明を図１に戻す。外部管理サーバ３は、ＳＮＳ利用者を一意に識別する識別情報、ＳＮＳ利用者の氏名、及びプロフィール画像のリンク先を示すリンク情報など格納されたＳＮＳ利用者情報テーブルＴＢＬ３１と、ＳＮＳ利用者の友達関係を示す友達情報が格納されたＳＮＳ友達情報テーブルＴＢＬ３２を備える。さらに、外部管理サーバ３は、各種のＡＰＩ（Application Program Interface）を実行可能であり、管理サーバ１からのパラメータを含む要求を受信すると、ＳＮＳ利用者情報テーブルＴＢＬ３１又はＳＮＳ友達情報テーブルＴＢＬ３２から所定の情報を抽出して管理サーバ１に返信するようになっている。

管理サーバ１は、各ゴルフ利用者に対してマイページを提供する。マイページには、各種のゴルフに関する情報が集約されて表示される。図３にマイページの一例を示す。同図に示すように領域Ｘ１には、本人のプロフィール画像が表示され、領域Ｙ１には、本人のゴルフ友達のプロフィール画像が表示され、さらに、領域Ｙ２には、ゴルフ友達のゴルフ友達のプロフィール画像が表示される。このように、ゴルフ友達と、ゴルフ友達のゴルフ友達とが、異なる領域Ｙ１及びＹ２に表示されるので、本人は、階層的な友達関係を容易に把握することが可能となる。なお、領域Ｙ１及びＹ２にゴルフ友達及びゴルフ友達のゴルフ友達を表示する際には、ランダムに表示してもよいし、あるいは、親密度を算出し、親密度の高い順に手前側から表示してもよい。

次に、図５に登録日データテーブルＴＢＬ１５のデータ構造を示す。登録日データテーブルＴＢＬ１５には、ゴルフ利用者の識別情報ＵＩＤと、当該ゴルフ利用者がゴルフに行きたい日として登録した実行可能日が対応付けられて記憶されている。この登録日データテーブルＴＢＬ１５を参照することによって、各ゴルフ利用者が登録した実行可能日を知ることができる。

次に、外部管理サーバ３が備えるＳＮＳ利用者情報テーブルＴＢＬ３１とＳＮＳ友達情報テーブルＴＢＬ３２について説明する。図６にＳＮＳ利用者情報テーブルＴＢＬ３１のデータ構造を示す。ＳＮＳ利用者情報テーブルＴＢＬ３１には複数のレコードが記録されている。１つのレコードは、氏名、性別、住所、勤務先、ＳＮＳ利用者を一意に識別する識別情報ＵＩＤ（アカウントとして機能する）、及びメールアドレスを含む。これらの情報は、ＳＮＳ利用者が登録した個人情報である。

図７にＳＮＳ友達情報テーブルＴＢＬ３２のデータ構造を示す。ＳＮＳ友達情報テーブルＴＢＬ３２には複数のレコードが記録されている。１つのレコードは、アクション元の識別情報、アクション先の識別情報、ステータス、及び申請日時を含む。アクション元は、友達申請を行ったＳＮＳ利用者であり、アクション先は、友達申請されたＳＮＳ利用者である。ステータスは、友達申請の状態を示し、申請中が「０」、承諾が「１」、タイムアウトが「２」で表される。タイムアウトとは、申請日時から所定期間が経過しても、アクション先のＳＮＳ利用者が、友達申請を承諾するか拒否するかを明らかにしない場合である。図７に示す例では、ＵＩＤが「0zz99x999」のＳＮＳ利用者は、ＵＩＤが「6zz99x999」のＳＮＳ利用者に友達申請を行い、承諾されている。

友達関係を記憶する場合に、アクション元（申請元）とアクション先（申請先）を分けて記憶したのは、記憶容量を削減する利点がある。仮に、あるＳＮＳ利用者の識別情報ＵＩＤと当該ＳＮＳ利用者と友達関係にある全てのＳＮＳ利用者の識別情報ＵＩＤとを対応づけて記憶したとすると、２倍の記憶容量が必要となる。例えば、ＳＮＳ利用者ａがアクション元でありＳＮＳ利用者ｂがアクション先であるとする。各ＳＮＳ利用者ごとに友達関係にあるＳＮＳ利用者の識別情報を記憶する場合には、利用者ａについて利用者ｂが友達関係にあることを記憶し、さらに、利用者ｂについて利用者ａが友達関係にあることを記憶する必要がある。これに対して、本実施形態では、アクション先の識別情報とアクション元の識別情報とを対応づけて１つのレコードに記憶するので記憶容量を半分にすることができる。また、ステータスを更新する場合でも半分の処理となる。

図８に管理サーバ１の構成を示す。この図に示すように、管理サーバ１は、装置全体を制御するＣＰＵ（Central Processing Unit）３０、ＣＰＵ３０の作業領域として機能するＲＡＭ（Random Access Memory）３１、ブートプログラムなどを記憶したＲＯＭ（Read Only Memory）３２、各種のプログラムやデータを記憶するハードディスク３３、キーボードやマウスなどを含む入力部３４、画像を表示するディスプレイ３５、通信網ＮＥＴを介して外部の装置と通信を行う通信インターフェース３６、及びコンパクトディスクなどの情報記録媒体を読み取る読取装置３７を備える。ハードディスク３３は、上述した記憶部１５に相当し、ゴルフ利用者情報テーブルＴＢＬ１１、利用者ログ管理テーブルＴＢＬ１３、設定値管理マスターテーブルＴＢＬ１５、及び個別ログファイルＦＬ１０を格納する。なお、外部管理サーバ３も管理サーバ１と同様に構成されている。但し、ハードディスク３３には、ＳＮＳ利用者情報テーブルＴＢＬ３１と、ＳＮＳ友達情報テーブルＴＢＬ３２とが格納される。

図９に端末装置２の構成を示す。端末装置２は、装置全体を制御するＣＰＵ４０、ＣＰＵ４０の作業領域として機能するＲＡＭ４１、ブートプログラムなどを記憶したＲＯＭ４２、各種のプログラムやデータを記憶する記憶装置４３、テンキーなどを含む入力部４４、画像を表示するディスプレイ４５、及び通信網ＮＥＴを介して外部の装置と通信を行う通信インターフェース４６を備える。

＜２．サービス提供システムの動作＞
本実施形態のサービス提供システム１００では、ゴルフ利用者の端末装置２において、ゴルフ友達の階層構造を示す関係図を表示させることができる。さらに、ゴルフ利用者は、ゴルフに行きたい日あるいはゴルフに行くことができる日を実行可能日として登録することができる。この実行可能日はゴルフ友達やゴルフ友達のゴルフ友達は閲覧することができる。各ゴルフ利用者は、自分の実行可能日の他に、ゴルフ友達の実行可能日、及びゴルフ友達のゴルフ友達の実行可能日をカレンダー表示させることができる。
以下、関係図を表示させるフレンドマップ表示処理、実行可能日を登録する登録処理、実行可能日を表示する実行可能日表示処理、及びゴルフ友達などをゴルフに誘うイベント勧誘処理について説明する。

＜２−１：フレンドマップ表示処理＞
図１０及び図１１に表示処理に関するサービス提供システムの動作シーケンスを示す。端末装置２のＳＮＳ利用者（ゴルフ利用者でもある）が、ウェブブラウザ上で動作したり、端末装置２にインストールされて動作するアプリケーションを起動して、ＳＮＳサイトにアクセスすると、端末装置２のディスプレイ４５には、ログイン画面が表示される。このログイン画面には、識別情報ＵＩＤとパスワードとを入力する入力ボックスが表示される。利用者が、入力ボックスに入力して送信ボタンを押すと、端末装置２は、入力した識別情報ＵＩＤ及びパスワードを含むログイン要求を外部管理サーバ３に送信する。

ログイン要求を外部管理サーバ３が受信すると、外部管理サーバ３は認証処理を実行する（Ｓ３００）。具体的には、外部管理サーバ３のＣＰＵは、識別情報ＵＩＤとパスワードとの組みが記憶されているか否かを判定し、判定条件を充足する場合にはログインを許可し、判定条件が充足されない場合にはログインを拒絶する。そして、ＣＰＵは判定結果を示すログイン応答を端末装置２に送信させる。なお、図１０に示す例では、ログインが許可されたものとする。一度、端末装置２で入力された識別情報ＵＩＤとパスワードとの組みは、端末装置２に所定期間記憶されて、当該所定期間内であればログインを省略可能としてもよい。

この後、ＳＮＳ利用者がメニューの中からゴルフ情報アプリケーションを選択すると（Ｓ２００）、端末装置２は、マイページ閲覧要求を管理サーバ１に送信する。管理サーバ１はマイページ閲覧要求を受信すると、マイページ閲覧要求に含まれる本人の識別情報ＵＩＤを取得し、本人の識別情報ＵＩＤを外部管理サーバ３に送信する（Ｓ１００）。

外部管理サーバ３が、本人の識別情報ＵＩＤを受信すると、外部管理サーバ３のＣＰＵは、友達情報テーブルＴＢＬにアクセスし、当該識別情報ＵＩＤがアクション元又はアクション先として記録されているレコードを抽出する（Ｓ３０１）。さらに、ＣＰＵは、これらのレコードにアクション元又はアクション先として記録されている識別情報ＵＩＤをキーとしてＳＮＳ利用者情報テーブルＴＢＬ３１からＳＮＳ利用者情報を抽出する（Ｓ３０１）。この後、外部管理サーバ３は、抽出したＳＮＳの友達情報及びＳＮＳ利用者情報を含む友達リストを管理サーバ１に送信する。

管理サーバ１が、友達リストを受信して、ＳＮＳの友達情報及びＳＮＳ利用者情報を取得すると（Ｓ１０１）、管理サーバ１は、本人のＳＮＳ友達の識別情報ＵＩＤを特定する（Ｓ１０２）。具体的には、友達情報のレコードにおいてアクション元又はアクション先として記録されている識別情報ＵＩＤのうち、本人の識別情報ＵＩＤ及び重複する識別情報ＵＩＤを除いた識別情報ＵＩＤを本人のＳＮＳ友達の識別情報ＵＩＤとして特定する。この結果、図１２に示すように本人と友達関係にあるＳＮＳ友達を特定することができる。この後、管理サーバ１は、ＳＮＳ友達の識別情報ＵＩＤを外部管理サーバ３に送信する（Ｓ１０３）。

外部管理サーバ３が、ＳＮＳ友達の識別情報ＵＩＤを受信すると、外部管理サーバ３のＣＰＵは、ＳＮＳ友達情報テーブルＴＢＬ３２にアクセスし、当該識別情報ＵＩＤがアクション元又はアクション先として記録されているレコードを抽出する（Ｓ３０２）。この後、外部管理サーバ３は、抽出したＳＮＳの友達情報を含む友達リストを管理サーバ１に送信する。

管理サーバ１が、友達リストを受信して、ＳＮＳ友達のＳＮＳ友達について友達情報を取得すると（Ｓ１０４）、管理サーバ１は、ＳＮＳ友達のＳＮＳ友達について識別情報ＵＩＤを特定する（Ｓ１０５）。具体的には、友達情報のレコードにおいてアクション元又はアクション先として記録されている識別情報ＵＩＤのうち、重複する識別情報ＵＩＤを除いた識別情報ＵＩＤをＳＮＳ友達のＳＮＳ友達の識別情報ＵＩＤとして特定する。この結果、図１３に示すように本人と友達関係にあるＳＮＳ友達及びＳＮＳ友達のＳＮＳ友達を特定することができる。この後、管理サーバ１は、ＳＮＳ友達のＳＮＳ友達の識別情報ＵＩＤを外部管理サーバ３に送信する（Ｓ１０６）。

外部管理サーバ３が、ＳＮＳ友達のＳＮＳ友達の識別情報ＵＩＤを受信すると、外部管理サーバ３のＣＰＵは、ＳＮＳ利用者情報テーブルＴＢＬ３１にアクセスし、当該識別情報ＵＩＤが記録されているレコードを抽出する（Ｓ３０３）。この後、外部管理サーバ３は、抽出したＳＮＳ利用者情報を管理サーバ１に送信する。

管理サーバ１が、ＳＮＳ利用者情報を受信すると（Ｓ１０７）、図１１に示すように、管理サーバ１のＣＰＵ３０は、ＳＮＳ友達及びＳＮＳ友達のＳＮＳ友達の識別情報ＵＩＤとゴルフ利用者の識別情報ＵＩＤに基づいてゴルフ友達及びゴルフ友達のゴルフ友達を特定する（Ｓ１０８）。具体的には、Ｓ１０２で特定したＳＮＳ友達の識別情報ＵＩＤのうち、ゴルフ利用者の識別情報ＵＩＤと一致するものを、ゴルフ友達の識別情報ＵＩＤとする。また、Ｓ１０５で特定したＳＮＳ友達のＳＮＳ友達の識別情報ＵＩＤのうち、ゴルフ利用者の識別情報ＵＩＤと一致するものを、ゴルフ友達のゴルフ友達の識別情報ＵＩＤとする。このようにして図２示すようにゴルフ友達及びゴルフ友達のゴルフ友達が特定される。

次に、管理サーバ１のＣＰＵ３０は、関係図を表示させる表示情報を生成する（Ｓ１０９）。ここで、ＣＰＵ３０は、ゴルフ利用者のプロフィール画像を画面に配置する表示情報を生成する。送信データ量を削減するため、プロフィール画像は、画像データのアドレスを示すリンク情報として与えられる。なお、リンク情報の替わりにプロフィール画像データを表示情報に含ませてもよい。

まず、ＣＰＵ３０は、「ゴルフ友達」と「ゴルフ友達のゴルフ友達」に大別し、仮想的な画面に全ての「ゴルフ友達」と「ゴルフ友達のゴルフ友達」とを配置した関係図を生成する。ここで、複数のゴルフ友達がいる場合、それをどのように配置するかにについては、各種の方法がある。例えば、ランダムに配置してもよいし、あるいは、本人とゴルフ友達との親密度を算出し、親密度が高いゴルフ友達ほど、本人の近くに配置するようにしてもよい。本実施形態では、親密度が高いゴルフ友達ほど手前側に表示している。
また、本実施形態では、「ゴルフ友達」のプロフィール画像のアイコンは、「ゴルフ友達のゴルフ友達」のプロフィール画像のアイコンよりも大きくする。表示すべき人数が多い場合には、仮想的に画面の大きさは端末装置２のディスプレイ４５で表示される画面より大きくなる。この場合には、端末装置２において、仮想的な画面を表示可能な大きさに切り出してディスプレイ４５に表示することになる。

ＣＰＵ３０は、「ゴルフ友達」を仮想的な画面の一番手前から埋め、その後、「ゴルフ友達のゴルフ友達」を埋めていく。例えば、全ての「ゴルフ友達」と「ゴルフ友達のゴルフ友達」とを配置した画面が図１２に示す画面Ｗであるとする。「ゴルフ友達」を一番手前の画面に配置し、「ゴルフ友達」の配置が完了した後、「ゴルフ友達のゴルフ友達」を配置する。この場合、ＣＰＵ３０は、領域ｒ１→領域ｒ２→領域ｒ３…の順に「ゴルフ友達」と「ゴルフ友達のゴルフ友達」とを配置する。なお、１つの領域に表示可能な人数は予め設定で決められているが、任意の人数に変更可能としても良い。

端末装置２のディスプレイ４５において最初に表示されるのが画面領域Ｒ１である。この場合、領域ｒ１は図３に示す表示領域Ｙ１に相当し、領域ｒ２は表示領域Ｙ２に相当する。図３に示すボタンＢ２をクリックすると、ディスプレイ４５に画面領域Ｒ２が表示される。この場合、領域ｒ２は図３に示す表示領域Ｙ１に相当し、領域ｒ３は表示領域Ｙ２に相当する。この状態で、ボタンＢ２をクリックすると、ディスプレイ４５に画面領域Ｒ１が表示される。

即ち、端末装置２のディスプレイ４５は、画面を所定の方向にスライドして画面サイズよりも大きなサイズの関係図を表示できるようになっている。管理サーバ１のＣＰＵ３０は、ディスプレイ４５の画面サイズに「ゴルフ友達」と「ゴルフ友達のゴルフ友達」を配置できない場合、画面サイズよりも大きな領域に「ゴルフ友達」と「ゴルフ友達のゴルフ友達」とを配置した関係図を表示するために必要な表示情報を生成する。

説明を図１１に戻す。次に、管理サーバ１は、表示情報を含むマイページ閲覧応答を端末装置２に送信する（Ｓ１１０）。端末装置２がマイページ閲覧応答を受信すると、ＣＰＵ２０はディスプレイ４５に「ゴルフ友達」と「ゴルフ友達のゴルフ友達」とを配置した関係図を表示する。本実施形態では、図３及び図１４に示すように「ゴルフ友達」が手前に配置され、「ゴルフ友達のゴルフ友達」が「ゴルフ友達」より奥に配置されるので、ゴルフ利用者は、ゴルフ友達の階層関係を容易に把握することができる。さらに、本人とより関係の深い「ゴルフ友達」は「ゴルフ友達のゴルフ友達」よりも大きなアイコンで表示されるので、両者の階層関係を一見して把握することができる。加えて、「ゴルフ友達のゴルフ友達」は、本人のゴルフ友達のそれぞれに対して友達関係があるので、「ゴルフ友達」よりも人数が多いのが通常である。「ゴルフ友達のゴルフ友達」のアイコンを「ゴルフ友達」のアイコンよりも小さくすることによって、効率の良い表示が可能となる。

＜２−２：登録処理＞
次に、本実施形態における登録処理について説明する。図１５に登録処理におけるＣＰＵ３０の動作を示す。まず、ＣＰＵ３０は近況報告が選択されるまで、ステップＳ５０１の判定を繰り返す。具体的には、図３に示すマイページにおいてゴルフ利用者が近況報告ボタンＢ３をクリックすると、端末装置２は、近況報告ページ要求を管理サーバ１に送信する。管理サーバ１のＣＰＵ３０は、近況報告ページ要求を受信すると、ゴルフ利用者が近況報告を選択したと判断し、近況報告ページを生成する（Ｓ５０２）。この後、ＣＰＵ３０は近況報告ページを含む近況報告ページ応答を端末装置２に送信する。

端末装置２は、近況報告ページ応答を受信すると、例えば、図１６に示す近況報告ページをディスプレイ４５に表示する。この画面には、「日を決める」に対応する日決定ボタンＢ３、コメントするに対応するコメントボタンＢ４、キャンセルに対応するキャンセルボタンＢ５が表示される。ここで、ゴルフ利用者が日決定ボタンＢ３をクリックして、「日を決める」を選択すると、登録ページ要求が端末装置２から管理サーバ１に送信される。

管理サーバ１のＣＰＵ３０は、ゴルフ利用者が「日を決める」を選択したか否かを判定する（Ｓ５０３）。登録ページ要求を受信すると、ＣＰＵ３０は、「日を決める」を選択したと判断し、登録ページを生成する（Ｓ５０４）。この後、ＣＰＵ３０は、登録ページを含む登録ページ応答を端末装置２に送信する。端末装置２は、登録ページ応答を受信すると、例えば、図１７に示す登録ページをディスプレイ４５に表示する。この画面には、月で選択に対応する月選択ボタンＢ６、週又は日で選択に対応する週日選択ボタンＢ７、キャンセルに対応するキャンセルボタンＢ８が表示される。

この後、管理サーバ１のＣＰＵ３０は、週・日が選択されたか否かを判定する(Ｓ５０５)。端末装置２においてゴルフ利用者が週日選択ボタンＢ７をクリックすると、端末装置２はカレンダー表示要求を管理サーバ１に送信する。ＣＰＵ３０は、カレンダー表示要求を受信した場合に、ゴルフ利用者がカレンダー表示を選択したと判定し、カレンダー登録ページを生成し（Ｓ５０６）、カレンダー登録ページを含むカレンダー表示応答を端末装置２に送信する。

端末装置２は、カレンダー表示応答を受信すると、例えば、図１８に示すカレンダー登録ページをディスプレイ４５に表示する。この画面には、表示を切り替えるための切替ボタンＢ９、登録を確定させるための登録ボタンＢ１０、キャンセルに対応するキャンセルボタンＢ１１が表示される。また、画面中央にはカレンダー部ＣＬが表示される。カレンダーの各日付はチェックボックスになっており、ゴルフ利用者はゴルフに行きたい日（実行可能日の一例）にチェックを入れて登録ボタンＢ１０をクリックすることによって、ゴルフに行きたい日の登録を確定させる。なお、ゴルフ利用者が切替ボタンＢ９をクリックすると、カレンダー表示からリスト表示に切り替わり、ゴルフ利用者がキャンセルボタンＢ１１をクリックすると、図１７に示す登録ページに戻るようになっている。

説明を図１５に戻す。ＣＰＵ３０はカレンダー登録ページを生成すると（Ｓ５０６）、ゴルフ利用者が切替を選択したか否かを判定する（Ｓ５０７）。端末装置２は、ゴルフ利用者が切替ボタンＢ９をクリックすると切替要求を管理サーバ１に送信する。ＣＰＵ３０は切替要求を受信したか否かによってゴルフ利用者が切替を選択したか否かを判定する。

ゴルフ利用者が切替を選択していない場合、Ｓ５０７の判定結果はＮＯとなり、ＣＰＵ３０は処理をステップＳ５０８に進めて、ゴルフ利用者がキャンセルを選択したか否かを判定する。端末装置２は、ゴルフ利用者がキャンセルボタンＢ１１をクリックすると、キャンセル要求を管理サーバ１に送信する。ＣＰＵ３０はキャンセル要求を受信したか否かによってゴルフ利用者がキャンセルを選択したか否かを判定する。ゴルフ利用者がキャンセルを選択した場合、Ｓ５０８の判定結果はＹＥＳとなり、ＣＰＵ３０は処理をステップＳ５０４に戻す。

一方、ゴルフ利用者がキャンセルを選択していない場合、Ｓ５０８の判定結果はＮＯとなり、ＣＰＵ３０は処理をステップＳ５０９に進めて、ゴルフ利用者が実行可能日を入力したか否かを判定する。端末装置２では、ゴルフ利用者が登録ボタンＢ１０をクリックすると、ゴルフ利用者が入力した実行可能日を確認するための確認画面が表示される。そして、ゴルフ利用者が当該画面の送信ボタンをクリックすると、端末装置２は登録要求を管理サーバ１に送信する。登録要求には、カレンダー表示をした範囲において、ゴルフ利用者が指定した実行可能日が含まれている。なお、ゴルフ利用者は、登録した実行可能日を削除するため、カレンダー表示をした範囲において、実行可能日を指定せずに送信ボタンをクリックすることもできる。この場合は、登録要求に実行可能日は含まれていない。
ＣＰＵ３０は登録要求を受信したか否かによってゴルフ利用者が実行可能日を入力したか否かを判定する。ゴルフ利用者が実行可能日を入力していなかった場合、Ｓ５０９の判定結果はＮＯとなり、ＣＰＵ３０は処理をステップＳ５０７に戻す。

一方、ゴルフ利用者が実行可能日を入力した場合、Ｓ５０９の判定結果はＹＥＳとなり、ＣＰＵ３０は、処理をステップＳ５１０に進め、登録日データテーブルＴＢＬ１５を更新する。具体的には、ＣＰＵ３０は、登録要求に含まれる実行可能日と登録要求を送信したゴルフ利用者の識別情報ＵＩＤとを対応づけて登録データテーブルＴＢＬ１５に記憶する。

次に、カレンダー表示において、ゴルフ利用者が切替を選択すると、Ｓ５０７の判定結果はＹＥＳとなり、ＣＰＵ３０は処理をＳ５１１に進めリストページを生成し、リストページを含む切替応答を端末装置２に送信する。端末装置２は切替応答を受信すると、ディスプレイ４５にリストページを表示させる。図１９にリストページの一例を示す。リストページには、日付とチェックボックスを備えたリスト部Ｌ１が表示される。リスト部Ｌ１は、上下にスクロールできるようになっており、ゴルフ利用者は各日付に対応するチェックボックスにチェックを入れることが可能である。さらに、リストページには、カレンダー登録ページ（図１８参照）と同様に、切替ボタンＢ９、登録ボタンＢ１０、及びキャンセルボタンＢ１１が配置されている。

説明を図１５に戻す。ＣＰＵ３０はリストページを生成した後、ゴルフ利用者が切替を選択したか否かを判定する（Ｓ５１２）。ゴルフ利用者が切替を選択した場合、ＣＰＵ３０は処理をＳ５０６に戻し、リスト表示からカレンダー表示に切り替える。
一方、ゴルフ利用者が切替を選択しなかった場合、ＣＰＵ３０は、ゴルフ利用者がキャンセルを選択したか否かを判定する（Ｓ５１３）。キャンセルを選択した場合には、ＣＰＵ３０は処理をＳ５０４に戻す。
一方、キャンセルを選択しなかった場合には、ＣＰＵ３０は、ゴルフ利用者が実行可能日を入力したか否かを判定する（Ｓ５１４）。図１９に示すリスト表示ページにおいて、ゴルフ利用者が登録ボタンＢ１０をクリックすると、ゴルフ利用者が入力した実行可能日を確認するための確認画面が表示される。そして、ゴルフ利用者が当該画面の送信ボタンをクリックすると、端末装置２は登録要求を管理サーバ１に送信する。登録要求には、ゴルフ利用者が指定したリスト表示の範囲において、ゴルフ利用者が指定した実行可能日が含まれている。ＣＰＵ３０は、Ｓ５１４の処理において、登録要求を端末装置２から受信したか否かによって、実行可能日の入力があったか否かを判定する。
実行可能日が入力されていない場合、ＣＰＵ３０は処理をＳ５１２に戻す。一方、実行可能日が入力された場合には、ＣＰＵ３０は処理を上述したＳ５１０に進め、登録日データテーブルＴＢＬ１５の更新を実行する。

次に、登録ページにおいて週・日が選択されなかった場合、Ｓ５０５の判定結果はＮＯとなり、ＣＰＵ３０は処理をＳ５１５に進め、ゴルフ利用者が月を選択したか否かを判定する。図１７に示す登録ページにおいて、ゴルフ利用者が月選択ボタンＢ６をクリックすると、端末装置２は、月登録要求を管理サーバ１に送信する。ＣＰＵ３０は月登録要求を受信したか否かによって、ゴルフ利用者が月を選択したか否かを判定する。

ゴルフ利用者が月を選択した場合、ＣＰＵ３０は入力ページを生成し（Ｓ５１６）、入力ページを含む月登録応答を端末装置２に送信する。端末装置２は月登録応答を受信すると、入力ページを端末装置２のディスプレイ４５に表示する。
図２０に入力ページの一例を示す。入力ページには年を表示する表示欄Ｗ１が設けられており、ボタンＢ１２をクリックすると年がプルダウン表示される。また、表示欄Ｗ２には月が表示され、表示欄Ｗ３には日が表示される。ボタンＢ１３をクリックすると月がプルダウン表示される。また、ボタンＢ１４をスライドさせることによって、表示欄Ｗ３に表示させる日を変更することができる。ゴルフ利用者は、年及び月を設定し、所望の日をクリックすることによって、実行可能日を指定することができる。そして、ゴルフ利用者は登録ボタンＢ１０をクリックすることによって指定した実行可能日を確定させる。また、チェックボックスＱ１にチェックを入れると、表示欄Ｗ２に表示される月について、土日祝日が全て実行可能日として指定される。

説明を図１５に戻す。ＣＰＵ３０は、入力ページを生成した後、キャンセルを選択したか否かを判定する（Ｓ５１７）。入力ページにおいて、ゴルフ利用者がキャンセルボタンＢ１１をクリックすると、Ｓ５１７の判定結果はＹＥＳとなり、ＣＰＵ３０は処理をＳ５０４に戻す。一方、キャンセルが選択されていない場合、Ｓ５１７の判定結果はＮＯとなり、ＣＰＵ３０は処理をＳ５１８に進め、実行可能日の入力があったか否かを判定する。
図２０に示す入力ページにおいて、ゴルフ利用者が登録ボタンＢ１０をクリックすると、ゴルフ利用者が入力した実行可能日を確認するための確認画面が表示される。そして、ゴルフ利用者が当該画面の送信ボタンをクリックすると、端末装置２は登録要求を管理サーバ１に送信する。登録要求には、ゴルフ利用者が指定した月の範囲において、ゴルフ利用者が指定した実行可能日が含まれている。ＣＰＵ３０は、Ｓ５１８の処理において、登録要求を端末装置２から受信したか否かによって、実行可能日の入力があったか否かを判定する。入力があった場合、ＣＰＵ３０は登録日データテーブルを更新する（Ｓ５１０）。一方、実行可能日の入力がなかった場合は処理をＳ５１７に戻す。

次に、Ｓ５１７の判定結果がＮＯの場合、すなわち、登録ページ（図１７参照）において月選択ボタンＢ６及び週日選択ボタンＢ７がクリックされなかった場合、ＣＰＵ３０は、キャンセルが選択されたか否かを判定する（Ｓ５１９）。ゴルフ利用者が登録ページにおいてキャンセルボタンＢ８をクリックした場合、ＣＰＵ３０は処理をＳ５０２に戻す。一方、キャンセルボタンＢ８がクリックされていない場合、ＣＰＵ３０は処理をＳ５０５に戻す。

このようにして、ゴルフ利用者は、実行可能日を登録することができる。そして、各利用者が端末装置２を操作して入力することによって、実行可能日を一元的に管理することができる。

＜２−３：実行可能日表示処理＞
次に、実行可能日表示処理について説明する。図２１に実行可能日表示処理におけるＣＰＵ３０の動作を示す。ＣＰＵ３０は、ゴルフ利用者がゴルフスケジュールを選択するまで、ステップＳ６０１の判定を繰り返す。具体的には、図３に示すマイページにおいてゴルフ利用者がスケジュールボタンＢｓをクリックすると、端末装置２は、スケジュールページ要求を管理サーバ１に送信する。管理サーバ１のＣＰＵ３０は、スケジュールページ要求を受信すると、ゴルフ利用者がゴルフスケジュールを選択したと判定し、処理をＳ６０２に進める。

ＣＰＵ３０は、Ｓ６０２において、ゴルフ利用者、そのゴルフ友達、及びゴルフ友達のゴルフ友達を特定する。具体的には、これらの者の識別情報ＵＩＤを取得する。本実施形態では、マイページにおいてゴルフフレンドマップを表示するが、その際に、ＣＰＵ３０は、ゴルフ利用者、そのゴルフ友達、及びゴルフ友達のゴルフ友達の識別情報ＵＩＤを取得している（図１０及び図１１参照）。Ｓ６０２では、ゴルフフレンドマップの表示で用いた識別情報ＵＩＤを用いればよい。

この後、ＣＰＵ３０はゴルフスケジュールをカレンダーで表示するカレンダー表示ページを生成する（Ｓ６０３）。具体的には、ＣＰＵ３０は、登録日データテーブルＴＢＬ１５を参照して、ゴルフ利用者の識別情報ＵＩＤに対応する実行可能日を取得し、ゴルフ友達の識別情報ＵＩＤに対応する実行可能日を取得し、ゴルフ友達のゴルフ友達に対応する実行可能日を取得する。そして、取得した実行可能日を識別情報ＵＩＤごとに区別してカレンダーに配置したカレンダー表示ページを生成する。そして、ＣＰＵ３０はカレンダー表示ページを含むスケジュールページ応答を端末装置２に送信する。スケジュールページ応答を受信した端末装置２は、ディスプレイ４５にカレンダー表示ページを表示させる。図２２にカレンダー表示ページの一例を示す。この図に示すカレンダー部ＣＬには、ゴルフ利用者の実行可能日が画鋲のアイコンで示され、ゴルフ友達のアイコンが「Ａさん」で表示され、ゴルフ友達のゴルフ友達のアイコンが「Ｂさん」で表示されている。
このように、自分だけなく、ゴルフ友達、あるいはゴルフ友達のゴルフ友達まで、カレンダー表示ページに実行可能日を表示するので、ゴルフ利用者は一見して関係者がゴルフに行きたいと考えている日を知ることができ、ゴルフに誘い易い環境を提供することができる。また、自らが積極的にゴルフ友達などをゴルフに誘うことに躊躇してしまうゴルフ利用者は、実行可能日を登録することによって、ゴルフ友達から誘われ易くなる。

説明を図２１に戻す。次に、カレンダーでのスケジュール表示において、ゴルフ利用者が切替を選択すると、Ｓ６０４の判定結果はＹＥＳとなり、ＣＰＵ３０は処理をＳ６０６に進めスケジュールのリストページを生成し、リストページを含む切替応答を端末装置２に送信する。端末装置２は切替応答を受信すると、ディスプレイ４５にスケジュールのリストページを表示させる。図２３にリストページの一例を示す。リストページには、日付と登録者を備えたリスト部Ｌ２が表示される。リスト部Ｌ２は、上下にスクロールできるようになっている。さらに、リストページには、カレンダー表示（図２１参照）と同様に、切替ボタンＢ９及びキャンセルボタンＢ１１が配置されている。

説明を図２１に戻す。ＣＰＵ３０はリストページを生成した後、ゴルフ利用者が切替を選択したか否かを判定する（Ｓ６０７）。ゴルフ利用者が切替を選択した場合、ＣＰＵ３０は処理をＳ６０３に戻し、リスト表示からカレンダー表示に切り替える。
一方、ゴルフ利用者が切替を選択しなかった場合、ＣＰＵ３０は、ゴルフ利用者がキャンセルを選択したか否かを判定する（Ｓ６０８）。キャンセルを選択した場合には、ＣＰＵ３０はスケジュールを削除したページを生成し、当該ページを端末装置２に送信して処理を終える（Ｓ６０９）。この点は、カレンダー表示において切替が選択されず、Ｓ６０５の判定結果がＮＯとなり、Ｓ６０５の判定結果がＮＯ、即ちキャンセルが選択されない場合も同様である。

＜２−４：イベント勧誘処理＞
次に、イベント勧誘処理について説明する。上述した実行可能日表示処理では、カレンダー表示又はリスト表示にて、本人、そのゴルフ友達、及びゴルフ友達のゴルフ友達について、実行可能日を本人の端末装置２に表示できるようにした。イベント勧誘処理は、ゴルフスケジュールを表示した状態で、ゴルフ友達又はゴルフ友達のゴルフ友達を選択すると、ゴルフの勧誘を行う処理である。

図２４にゴルフ勧誘処理の処理内容を示す。まず、ＣＰＵ３０はゴルフスケジュールにおいて、ゴルフ利用者本人が、他のゴルフ利用者を選択したか否かを判定し（Ｓ７０１）、
選択を行うまで処理を繰り返す。本実施形態では、図２２に示すゴルフスケジュールのカレンダー表示又は図２３に示すゴルフスケジュールのリスト表示において、ゴルフ友達又はゴルフ友達のゴルフ友達をクリックすると、端末装置２は、勧誘ページ要求を管理サーバ１に送信する。勧誘ページ要求には、本人の識別情報、クリックされたゴルフ利用者の識別情報、クリックされた日付情報が含まれている。管理サーバ１のＣＰＵ３０は、勧誘ページ要求を受信したか否かによって、Ｓ７０１の判定を実行している。

この後、ＣＰＵ３０は、イベント勧誘ページを生成し（Ｓ７０２）、当該イベント勧誘ページを含む勧誘ページ応答を端末装置２に送信する。端末装置２は、勧誘ページ応答を受信すると、イベント勧誘ページをディスプレイ４５に表示させる。ここで、図２２に示すゴルフスケジュールにおいて、６月２３日に配置されたＡさんのアイコンを、ゴルフ利用者本人がクリックしたとすると、図２５に示すイベント勧誘ページがディスプレイ４５に表示される。ＣＰＵ３０は、勧誘ページ要求に含まれるクリックされたゴルフ利用者の識別情報及びクリックされた日付情報に基づいて、イベント勧誘ページの表示欄Ｗ４には、誰を何時誘うかが表示される。また、表示欄Ｗ４の下部には、クリックされたゴルフ利用者のプロフィール画像が表示される。

また、クリックされた日付けにおいて、他のゴルフ利用者が実行可能日（図２５における「ゴルフ日」）を登録している場合には、選択された実行可能日を登録している他のゴルフ利用者も勧誘することの問い合わせが表示欄Ｗ５に表示される。さらに、他のゴルフ利用者のプロフィール画像とチェックボックスＺ１が表示される。くわえて、イベント勧誘ページには、勧誘することを確定させる勧誘ボタンＢ１２及びキャンセルボタンＢ１３が表示される。

説明を図２４に戻す。次に、ＣＰＵ３０はゴルフ利用者がキャンセルを選択したか否かを判定する（Ｓ７０３）。ゴルフ利用者がキャンセルボタンＢ１３をクリックした場合は、Ｓ７０３の判定結果はＹＥＳとなり、ＣＰＵ３０はゴルフ勧誘処理を終了させる。一方、ゴルフ利用者がキャンセルボタンＢ１３をクリックしていない場合は、Ｓ７０３の判定結果はＮＯとなり、確定を選択したか否かを判定する。ゴルフ利用者が勧誘ボタンＢ１２をクリックした場合には、ゴルフ勧誘が確定してゴルフ勧誘要求が端末装置２から管理サーバ１に送信される。一方、確定が選択されなかった場合には、ＣＰＵ３０は処理をＳ７０３に戻す。

ゴルフ勧誘要求には、勧誘の対象となるゴルフ利用者の識別情報ＵＩＤ及びゴルフに誘う日付情報が含まれている。ＣＰＵ３０は端末装置２からゴルフ勧誘要求を受信すると、ゴルフ勧誘が確定したと判定し、処理をステップＳ７０５に進め、イベント勧誘通知を実行する（Ｓ７０５）。例えば、図２５に示すイベント勧誘ページにおいて、ゴルフ利用者がチェックボックスＺ１にチェックを入れて、勧誘ボタンＢ１２をクリックすると、ＣＰＵ３０は、Ａさんの識別情報ＵＩＤとＢさんの識別情報ＵＩＤに基づいて、当該ゴルフ利用者からＡさんとＢさんに、６月２３日のゴルフへ誘う旨のメッセージを通知する。メッセージの通知はメールであってもよいし、あるいは、Ａさん及びＢさんのマイページやＳＮＳのウォール等への投稿であってもよい。

このように本実施形態では、ゴルフ利用者のスケジュールをゴルフ友達のスケジュールあるいはゴルフ友達のゴルフ友達のスケジュールと関連付けて表示することによって、一見して他のゴルフ利用者のスケジュールを把握することができる。この結果、自らゴルフ友達をゴルフ（イベント）に誘うほどの積極性がないゴルフ利用者にとって、気軽にゴルフ（イベント）に行きたいという意思を発信可能となる。したがって、積極的にイベントに参加する手続きを行わず、誘いを待つだけでよい。また、誰かをゴルフに誘おうとするゴルフ利用者にとっては、ゴルフ友達のゴルフに行きたい日を容易に把握可能となる。したがって、簡単にゴルフに誘うことができる。

＜第２実施形態＞
図２６を参照して第２実施形態のサービス提供システム１００Ａについて説明する。第２実施形態のサービス提供システム１００Ａは、第１実施形態のサービス提供システム１００から外部管理サーバ３を除いたものである。図２６に第２実施形態に係るサービス提供システム１００Ａのブロック図を示す。サービス提供システム１００Ａでは、第１実施形態のようにゴルフ利用者はＳＮＳ利用者に含まれるといった関係はない。

管理サーバ１Ａは、ゴルフ利用者情報テーブルＴＢＬ１１と、ゴルフ友達情報テーブルＴＢＬ１２と、利用者ログ管理テーブルＴＢＬ１３と、登録日データテーブルＴＢＬ１５とを記憶した記憶部１２を備える。また、記憶部１２には、管理サーバ１Ａを制御するプログラムが記憶されている。
ゴルフ友達情報テーブルＴＢＬ１２には、各ゴルフ利用者の識別情報ＵＩＤと、当該ゴルフ利用者のゴルフ友達の識別情報ＵＩＤとが対応付けられて記憶されている。したがって、ゴルフ友達情報テーブルＴＢＬ１２を参照することによって、本人と友達関係にあるゴルフ友達、更に、ゴルフ友達と友達関係にあるゴルフ友達のゴルフ友達を特定することが可能となる。
上述した第１実施形態においては、実行可能日表示処理及びイベント勧誘処理になどにおいて、ゴルフ友達やゴルフ友達のゴルフ友達を特定したが、本実施形態では、特定の際にゴルフ友達情報テーブルＴＢＬ１２を参照すればよく、その他の処理内容は第１実施形態と同様である。

＜変形例＞
本発明は、上述した各実施形態に限定されるものではなく、以下に述べる各種の変形が可能である。また、各変形例及び各実施形態は、適宜、組み合わせてもよいことは勿論である。

（１）上述した各実施形態では、カレンダー表示又はリスト表示において実行可能日を登録したが、本発明はこれに限定されるものではなく、どのような方法で実行可能日を入力してもよい。例えば、直接、実行可能日をテキストで入力してもよい。あるいは、端末装置２において音声で入力してもよい。

（２）上述した各実施形態では、ゴルフ友達のゴルフ友達についても、ゴルフスケジュールの表示対象としたが、本発明は、これに限定されるものではなく、ゴルフ友達のみをゴルフスケジュールの表示対象としてもよい。

（３）上述した各実施形態では、本人であるゴルフ利用者のゴルフ友達とゴルフ友達のゴルフ友達との全てについて、本人とともにゴルフスケジュールを表示することとしたが、本発明はこれに限定されるものではなく、本人であるゴルフ利用者が指定するゴルフ友達及びゴルフ友達のゴルフ友達についてゴルフスケジュールを表示するようにしてもよい。
例えば、本人であるゴルフ利用者がゴルフ友達のマイページにアクセスして、ゴルフスケジュールを参照すると、本人及びゴルフ友達のスケジュールが本人の端末装置２で表示されるものであってもよい。

（４）上述した各実施形態では、実行可能日の登録は日単位であったが、本発明はこれに限定されるものではなく、週単位や月単位で実行可能日を登録できるようにしてもよい。例えば、Ｆさんが７月の第３週を指定して実行可能日を登録した場合、図２７に示すように、カレンダー表示がなされる。また、例えば、Ｅさんが８月を指定して実行可能日を登録した場合、図２８に示すように、カレンダー表示がなされる。

（５）上述した各実施形態において、ゴルフスケジュールの表示画面において本人のスケジュールを削除できるようにしてもよい。具体的には、図２２に示すカレンダー表示や図２３に示すリスト表示のページにおいて、登録ボタンを設け、本人の実行可能日を変更できるようにしてもよい。削除した場合は、画鋲のアイコンを右クリックして当該実行可能日を削除し、追加したい場合には、日付を右クリックして画鋲のアイコンを追加してもよい。そして、変更内容を確定させたい場合に登録ボタンをクリックするようにしてもよい。この場合、登録ボタンをクリックする本人の実行可能日を指定する日付情報を含む登録要求が端末装置２から管理サーバ１に送信される。管理サーバ１のＣＰＵ３０は、登録要求に含まれる本人の識別情報ＵＩＤと実行可能日とを対応づけて登録日データテーブルＴＢＬ１５の内容を更新する。
なお、登録された実行可能日に対応する有効フラグを用いて管理してもよい。この場合には、同じ日を再度登録する場合に有効フラグのオン・オフのみで管理できるので、処理を簡素化できる。
なお、本人がゴルフ友達のマイページを閲覧中に、当該ゴルフ友達がゴルフ日を解除した場合、それが本人のカレンダーに反映されるのは更新したときやセッションを張り直したときとなる。

（６）上述した各実施形態において、イベント勧誘処理でゴルフ友達のゴルフ友達をゴルフに誘う場合、本人が直接誘うこととして説明したが、本発明はこれに限定されるものではなく、本人とゴルフ友達のゴルフ友達とに共通のゴルフ友達に仲介を依頼できるようにしてもよい。すなわち、ゴルフ友達のゴルフ友達をゴルフに誘う場合には、必ず仲介依頼処理を実行するようにしてもよいし、あるいは、本人の希望によって仲介依頼処理を実行するようにしてもよい。
例えば、本人がイベント勧誘処理においてゴルフ友達のゴルフ友達を選択した場合、端末装置２は、本人の識別番号ＵＩＤ及び当該ゴルフ友達のゴルフ友達の識別情報ＵＩＤとを含む共通友達ページ要求を管理サーバ１に送信する。管理サーバ１のＣＰＵ３０は共通友達ページ要求とを受信すると、受信した本人の識別情報ＵＩＤと前記ゴルフ友達のゴルフ友達の識別情報ＵＩＤを外部管理サーバ３に送信する。

外部管理サーバ３が、前記ゴルフ友達のゴルフ友達の識別情報ＵＩＤを受信すると、外部管理サーバ３のＣＰＵは、友達情報テーブルＴＢＬ３２にアクセスし、当該識別情報ＵＩＤがアクション元又はアクション先として記録されているレコードを抽出する。さらに、ＣＰＵは、これらのレコードにアクション元又はアクション先として記録されている識別情報ＵＩＤをキーとしてＳＮＳ利用者情報テーブルＴＢＬ３１からＳＮＳ利用者情報を抽出する。また同様に、外部管理サーバ３が、本人の識別情報ＵＩＤを受信すると、外部管理サーバ３のＣＰＵは、友達情報テーブルＴＢＬ３２にアクセスし、当該識別情報ＵＩＤがアクション元又はアクション先として記録されているレコードを抽出する。さらに、ＣＰＵは、これらのレコードにアクション元又はアクション先として記録されている識別情報ＵＩＤをキーとしてＳＮＳ利用者情報テーブルＴＢＬ３１からＳＮＳ利用者情報を抽出する。この後、外部管理サーバ３は、前記ゴルフ友達のゴルフ友達について抽出したＳＮＳの友達情報及びＳＮＳ利用者情報を含む友達リストと、本人について抽出したＳＮＳの友達情報及びＳＮＳ利用者情報を含む友達リストとを管理サーバ１に送信する。

管理サーバ１のＣＰＵ３０が、これらの友達リストを受信して、前記ゴルフ友達のゴルフ友達についてのＳＮＳの友達情報及びＳＮＳ利用者情報、並びに、本人についてのＳＮＳの友達情報及びＳＮＳ利用者情報を取得すると、管理サーバ１のＣＰＵ３０は、ゴルフ利用者情報テーブルＴＢＬ１１を参照し、前記抽出したＳＮＳ友達の中からゴルフ利用者であるゴルフ友達を特定する。さらに、管理サーバ１のＣＰＵ３０は、前記ゴルフ友達のゴルフ友達と本人とに共通するゴルフ友達である共通ゴルフ友達を抽出し、共通ゴルフ友達ページを生成する。

具体的には、第１に、ＣＰＵ３０は、友達情報のステータスが承諾のレコードにアクション元又はアクション先として記録されている識別情報ＵＩＤのうち、前記ゴルフ友達のゴルフ友達の識別情報ＵＩＤ及び重複する識別情報ＵＩＤを除いた識別情報ＵＩＤを前記ゴルフ友達のゴルフ友達のＳＮＳ友達の識別情報ＵＩＤとして特定する。
第２に、ＣＰＵ３０は、ゴルフ利用者情報テーブルＴＢＬ１１を参照して、ゴルフ利用者の識別情報ＵＩＤを取得する。
第３に、ＣＰＵ３０は、前記ゴルフ友達のゴルフ友達のＳＮＳ友達の識別情報ＵＩＤと一致するゴルフ利用者の識別情報ＵＩＤを、第１のゴルフ友達の識別情報ＵＩＤとして特定する。

第４に、ＣＰＵ３０は、友達情報のステータスが承諾のレコードにアクション元又はアクション先として記録されている識別情報ＵＩＤのうち、本人の識別情報ＵＩＤ及び重複する識別情報ＵＩＤを除いた識別情報ＵＩＤを本人のＳＮＳ友達の識別情報ＵＩＤとして特定する。
第５に、ＣＰＵ３０は、ゴルフ利用者情報テーブルＴＢＬ１１を参照して、ゴルフ利用者の識別情報ＵＩＤを取得する。
第６に、ＣＰＵ３０は、ＳＮＳ友達の識別情報ＵＩＤと一致するゴルフ利用者の識別情報ＵＩＤを、第２のゴルフ友達の識別情報ＵＩＤとして特定する。

第７に、ＣＰＵ３０は、第１のゴルフ友達の識別情報ＵＩＤと、第２のゴルフ友達の識別情報ＵＩＤとを比較して、一致する識別情報ＵＩＤを特定し、前記ゴルフ友達のゴルフ友達と本人とに共通する共通ゴルフ友達の識別情報ＵＩＤを抽出する。
第８に、ＣＰＵ３０は、共通ゴルフ友達の識別情報ＵＩＤに対応するＳＮＳ利用者情報を用いて、共通ゴルフ友達ページを生成する。

この後、管理サーバ１は、共通ゴルフ友達ページ応答を端末装置２に送信する。共通ゴルフ友達ページ応答を受信した端末装置２は、ディスプレイ４５に共通ゴルフ友達ページを表示する。図３６に共通ゴルフ友達ページの一例を示す。この例では、図３に示すマイページ上にポップアップ表示の形式で共通ゴルフ友達ページＰ１が表示される。共通ゴルフ友達ページＰ１の最上段の領域Ｃ１には、「あなたと山田洋子さんの共通のゴルフ友達」というタイトルが表示される。本実施形態では、ゴルフ友達のゴルフ友達の名前が「山田洋子」である場合を示している。つまり、領域Ｃ１に表示されるタイトルには、本人が選択したゴルフ友達のゴルフ友達の名前が含まれる。領域Ｃ１の左下の領域Ｃ２には本人のアイコンが表示され、その右隣の領域Ｃ３には、本人が選択したゴルフ友達のゴルフ友達のアイコンが表示される。

共通ゴルフ友達ページＰ１の中央部の領域Ｃ８及びその下に続く領域Ｃ９と領域Ｃ１０には、共通ゴルフ友達のアイコンが表示される。図２９に示す例では、共通ゴルフ友達のアイコンは領域Ｃ８にしか表示されていないが、抽出された共通ゴルフ友達の数に応じて領域Ｃ９や領域Ｃ１０にも表示される。領域Ｃ８、領域Ｃ９及び領域Ｃ１０の右端及び左端、あるいは、領域Ｃ１０の下部にボタンを表示させ、ボタンのクリックに応じて、さらに多くの共通ゴルフ友達が表示されるように、表示をスクロールするようにしてもよい。
以上のような共通ゴルフ友達ページＰ１を表示した状態で、共通ゴルフ友達ページＰ１の領域Ｃ８〜領域Ｃ１０に表示されたゴルフ友達の中から、本人が選択したゴルフ友達のゴルフ友達と一緒にゴルフに行くことについての仲介を依頼するゴルフ友達を選択する）。図２９に示す例では、アイコンＡ２で表示されるゴルフ友達を選択したとすると、図３０に示すように、アイコンＡ２に重ねてメッセージページＰ２がポップアップ表示される。

メッセージページＰ２の左上の領域Ｄ１には、選択したゴルフ友達のアイコンが表示される。図３０に示す例では、アイコンＡ２と同じアイコンが表示される。領域Ｄ１の右隣の領域Ｄ２には、「この人に仲介を頼みますか？」と記載された実行ボタンが表示される。メッセージページＰ２の右上の領域Ｄ３には、メッセージページＰ２を閉じるためのボタンが表示される。メッセージページＰ２の中央部の領域Ｄ４には、仲介依頼のメッセージを記入するメッセージ記入欄が表示される。メッセージページＰ２の右下の領域Ｄ５には、画像や動画を添付するためのボタンが表示される。中央部の領域Ｄ４の下方の領域Ｄ６には、メッセージの投稿日時が表示される。

メッセージ記入欄には、例えば、「山田洋子さんと一緒にゴルフに行ってみたいです。セッティングをお願いします。」等のようにメッセージを記入する。そして、領域Ｄ２に表示された「この人に仲介を頼みますか？」と記載された実行ボタンをクリックして仲介依頼を選択すると、図３１に示すようなリクエスト送信確認ダイアログＰ３が表示される。リクエスト送信確認ダイアログＰ３の左上の領域Ｅ１には、例えば、「リクエスト送信確認ダイアログ」のようなタイトルが表示される。領域Ｅ１の下方の領域Ｅ２には、例えば、「田中一郎さんに、この人とゴルフに行ってみたい！と伝えてみますか？」のような表示がされる。図３１に示す例では、アイコンＡ２で表示されるゴルフ友達の名前が田中一郎である場合を示している。つまり、領域Ｅ２には、仲介を依頼するゴルフ友達の名前が表示されることになる。領域Ｅ２の下方の領域Ｅ３には送信ボタンが表示され、その右隣の領域Ｅ４にはキャンセルボタンが表示される。領域Ｅ４に表示されるキャンセルボタンをクリックすると、図３１に示すリクエスト送信確認ダイアログＰ３が表示される一つ前の表示の状態に戻る。一方、領域Ｅ３に表示される送信ボタンをクリックして送信を選択すると、端末装置２のＣＰＵ４０から管理サーバ１に対して、本人の識別情報ＵＩＤ、仲介を依頼するゴルフ友達の識別情報ＵＩＤ、メッセージの内容等と共に、メッセージの送信要求が送信される。本人の識別情報ＵＩＤ、仲介を依頼するゴルフ友達の識別情報ＵＩＤ、メッセージの内容等、及びメッセージの送信要求を受信した管理サーバ１のＣＰＵ３０は、本人から仲介を依頼するゴルフ友達宛のメッセージを当該内容で送信するように外部管理サーバ３に対して送信依頼処理を行う。送信依頼を受信した外部管理サーバ３は、本人から仲介を依頼するゴルフ友達宛に、当該内容のメッセージを送信する。端末装置２においては、図３２に示すような送信完了メッセージＰ４の表示が行われる。

この後、仲介を依頼したゴルフ友達がＳＮＳサイトにログインすると、本人からの前記メッセージを読むことができる。その結果、このメッセージを読んだゴルフ友達が、選択したゴルフ友達のゴルフ友達に対して、本人とゴルフに行くことの仲介をしてくれることが期待される。このように、直接には関わりのないゴルフ友達のゴルフ友達であっても、ゴルフ友達に仲介を依頼することにより、一緒にゴルフに行ける可能性が高まることになる。

（７）上述した各実施形態において、さらに、ゴルフスケジュールを外部サーバが管理するＳＮＳサイトでのカレンダー機能においても表示可能としても良い。この場合、管理サーバ１は、ゴルフスケジュールに関する情報をエクスポートし、これを外部サーバに送信する。すなわち、実行可能日受付部１１は、実行可能日をゴルフ利用者から受け付けると、外部サーバに対して、当該ゴルフ利用者の識別情報ＵＩＤと実行可能日とを送信する送信部を備える。エクスポートするデータは、実行可能日をゴルフ利用者ごとに示す日付データ、画像を表示するための画像データ又は画像の格納先のアドレスを示すリンクデータが少なくとも含まれる。エクスポートデータは、更に、表示画像がクリックされたときにジャンプ先のリンクデータがあればなおよい。このジャンプ先はゴルフ情報アプケーションのカレンダーであることが好ましい。

（８）上述した第1実施形態において、本人の実行可能日が登録されたことをゴルフ情報アプリケーション内でゴルフ友達に、或いはＳＮＳ友達や自分のマイページに自動投稿するようにしてもよい。
また、上述した各実施形態では、イベントの一例としてゴルフを取り上げ説明したが、本発明はこれに限定されるものではなく、複数の人で行うイベントであれば、どのようなイベントに適用してもよい。例えば、旅行、食事、釣り、あるいはコンサートなどであってもよい。
また、上述した実施形態では、ゴルフの勧誘について説明したが、ゴルフなどのイベントの勧誘が成立した場合、または、イベントに勧誘する際に、ゴルフ場などのイベントの予約サイトに移動できるようにしてもよい。

（９）なお、本発明は上述の各実施形態及び変形例に限定されるものではなく、本発明の趣旨の範囲内での変更は本発明に含まれるものである。

ＮＥＴ……通信網、１，１Ａ……管理サーバ、２……端末装置、３……外部管理サーバ、１１……実行可能日受付部、１１ａ……送信部、１２……記憶部、１３……関係情報参照部、１４……第１特定部、１５……第２特定部、１６……取得部、１７……出力部、１８……勧誘受付部。

Claims (8)

1. 複数の第１利用者の端末装置と通信可能なイベント管理装置であって、
   所定のイベントの実行が可能な実行可能日を第１利用者から受け付け可能な実行可能日受付部と、
   前記実行可能日受付部によって受け付けられた前記実行可能日を、当該第１利用者を一意に識別する識別情報と関連付けて記憶可能な記憶部と、
   前記複数の第１利用者のうち所定の第１利用者と特定の関係を有する第１の特定利用者を特定可能な第１特定部と、
   前記記憶部を参照して、前記第１の特定利用者について前記実行可能日を取得可能な取得部と、
   前記所定の第１利用者の端末装置の操作に応じて、当該端末装置に対して、前記第１の特定利用者について前記実行可能日を表示させるための表示情報を出力可能な出力部と、
   前記所定の第１利用者の端末装置において、前記第１の特定利用者について前記実行可能日が選択された場合、前記所定のイベントについて当該第１の特定利用者を勧誘するための入力を受け付け可能とする勧誘受付部と、
   を備えるイベント管理装置。
2. 第１利用者に所定の対象に関する第１サービスを提供し、前記第１利用者を含む第２利用者に対して第２サービスを提供すると共に前記第２利用者同士の特定の関係を示す特定関係情報を管理する外部管理装置及び前記第１利用者の端末装置と通信可能なイベント管理装置であって、
   所定のイベントの実行が可能な実行可能日を前記第１利用者から受け付け可能な実行可能日受付部と、
   前記第１利用者を一意に識別する識別情報を記憶すると共に、前記実行可能日受付部によって受け付けられた前記実行可能日を、当該第１利用者の前記識別情報と関連付けて記憶可能な記憶部と、
   所定の第１利用者の識別情報に基づいて、前記外部管理装置で管理する前記所定の第１利用者の前記特定関係情報を参照可能な関係情報参照部と、
   前記所定の第１利用者の端末装置から要求を受信すると、前記記憶部に記憶されている前記第１利用者の前記識別情報及び前記関係情報参照部を用いて参照した前記特定関係情報に基づいて、前記所定の第１利用者と前記特定の関係を有する第２利用者のうち、前記第１利用者に該当する第１の特定利用者を特定可能な第１特定部と、
   前記記憶部を参照して、前記第１の特定利用者について前記実行可能日を取得可能な取得部と、
   前記所定の第１利用者の端末装置から要求を受信すると、当該端末装置に対して、前記前記第１の特定利用者について前記実行可能日を表示させるための表示情報を出力可能な出力部と、
   前記所定の第１利用者の端末装置において、前記第１の特定利用者についての前記実行可能日が選択された場合、前記所定のイベントについて当該第１の特定利用者を勧誘するための入力を受け付け可能とする勧誘受付部と、
   を備えるイベント管理装置。
3. 前記関係情報参照部は、前記第１の特定利用者の識別情報に基づいて、前記外部管理装置で管理する前記第１の特定利用者の前記特定関係情報を参照可能であり、
   前記第１特定部は更に、
   前記記憶部に記憶されている前記第１利用者の前記識別情報及び前記関係情報参照部を用いて参照した前記第１の特定利用者の前記特定関係情報に基づいて、前記第１の特定利用者と前記特定の関係を有する第２利用者のうち、前記第１利用者に該当する第２の特定利用者を特定可能であり、
   前記取得部は更に、前記記憶部を参照して、前記第２の特定利用者についての前記実行可能日を取得可能であり、
   前記出力部は更に、当該端末装置に対して、前記第２の特定利用者についての前記実行可能日を表示させるための表示情報を出力可能であり、
   前記勧誘受付部は更に、前記所定の第１利用者の端末装置において、前記第２の特定利用者についての前記実行可能日が選択された場合、前記所定のイベントについて選択された利用者を勧誘するための入力を受け付け可能とする、
   ことを特徴とする請求項２に記載のイベント管理装置。
4. 前記関係情報参照部は、前記第１の特定利用者の識別情報に基づいて、前記外部管理装置で管理する前記第１の特定利用者の前記特定関係情報を参照可能であり、
   前記第１特定部は更に、 前記記憶部に記憶されている前記第１利用者の前記識別情報及び前記関係情報参照部を用いて参照した前記第１の特定利用者の前記特定関係情報に基づいて、前記第１の特定利用者と前記特定の関係を有する第２利用者のうち、前記第１利用者に該当する第２の特定利用者を特定可能であり、
   前記取得部は更に、前記記憶部を参照して、前記第２の特定利用者についての前記実行可能日を取得可能であり、
   前記出力部は更に、当該端末装置に対して、前記第２の特定利用者についての前記実行可能日を表示させるための表示情報を出力可能であり、
   前記所定の第１利用者の端末装置において、前記第２の特定利用者についての前記実行可能日が選択された場合、前記所定の第１利用者と特定の関係を有しており、且つ当該第２の特定利用者と前記特定の関係を有している前記第１の特定利用者を特定可能である第２特定部を更に備えることを特徴とする、請求項２に記載のイベント管理装置。
5. 前記第２特定部によって特定された前記第１の特定利用者が前記所定の第１利用者によって選択された場合、前記出力部は、当該所定の第１利用者と前記第２の特定利用者との仲介を当該第１の特定利用者に対して送信するための入力を受け付け可能な表示情報を出力することを特徴とする請求項４に記載のイベント管理装置。
6. 前記実行可能日受付部が、前記実行可能日を前記第１利用者から受け付けると、外部装置に対して、当該第１利用者の識別情報と前記実行可能日とを送信する送信部を備えることを特徴とする請求項２乃至５のうちいずれか１項に記載のイベント管理装置。
7. 第１利用者に所定の対象に関する第１サービスを提供し、前記第１利用者を含む第２利用者に対して第２サービスを提供すると共に前記第２利用者同士の特定の関係を示す特定関係情報を管理する外部管理装置及び前記第１利用者の端末装置と通信可能であって、前記第１利用者を一意に識別する識別情報を記憶する記憶部を備えたイベント管理装置の制御方法であって、
   所定のイベントの実行が可能な実行可能日を前記第１利用者から受け付け、
   受け付けられた前記実行可能日を、当該第１利用者の前記識別情報と関連付けて前記記憶部に記憶し、
   所定の第１利用者の識別情報に基づいて、前記外部管理装置で管理する前記所定の第１利用者の前記特定関係情報を参照し、
   前記所定の第１利用者の端末装置から要求を受信すると、前記記憶部に記憶されている前記第１利用者の前記識別情報及び参照した前記特定関係情報に基づいて、前記所定の第１利用者と前記特定の関係を有する第２利用者のうち、前記第１利用者に該当する第１の特定利用者を特定し、
   前記記憶部を参照して、前記第１の特定利用者について前記実行可能日を取得し、
   前記所定の第１利用者の端末装置から要求を受信すると、当該端末装置に対して、前記前記第１の特定利用者について前記実行可能日を表示させるための表示情報を出力し、
   前記所定の第１利用者の端末装置において、前記第１の特定利用者について前記実行可能日が選択された場合、前記所定のイベントについて当該第１の特定利用者を勧誘するための入力を受け付ける、
   ことを特徴とするイベント管理装置の制御方法。
8. 第１利用者に所定の対象に関する第１サービスを提供し、前記第１利用者を含む第２利用者に対して第２サービスを提供すると共に前記第２利用者同士の特定の関係を示す特定関係情報を管理する外部管理装置及び前記第１利用者の端末装置と通信可能であって、前記第１利用者を一意に識別する識別情報を記憶する記憶部及びコンピュータを備えたイベント管理装置のプログラムであって、
   前記コンピュータを、
   所定のイベントの実行が可能な実行可能日を前記第１利用者から受け付け可能な実行可能日受付部と、
   前記実行可能日受付部によって受け付けられた前記実行可能日を、当該第１利用者の前記識別情報と関連付けて記憶部に記憶させる制御部と、
   所定の第１利用者の識別情報に基づいて、前記外部管理装置で管理する前記所定の第１利用者の前記特定関係情報を参照可能な関係情報参照部と、
   前記所定の第１利用者の端末装置から要求を受信すると、前記記憶部に記憶されている前記第１利用者の前記識別情報及び前記関係情報参照部を用いて参照した前記特定関係情報に基づいて、前記所定の第１利用者と前記特定の関係を有する第２利用者のうち、前記第１利用者に該当する第１の特定利用者を特定する第１特定部と、
   前記記憶部を参照して、前記第１の特定利用者について前記実行可能日を取得可能な取得部と、
   前記所定の第１利用者の端末装置から要求を受信すると、当該端末装置に対して、前記前記第１の特定利用者について前記実行可能日を表示させるための表示情報を出力可能な出力部と、
   前記所定の第１利用者の端末装置において、前記第１の特定利用者について前記実行可能日が選択された場合、前記所定のイベントについて当該第１の特定利用者を勧誘するための入力を受け付け可能とする勧誘受付部として、
   機能させるイベント管理装置のプログラム。

Images