特許 5802143 サーバ、制御方法およびプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5802143

(24)【登録日】2015年9月4日

(45)【発行日】2015年10月28日

(54)【発明の名称】サーバ、制御方法およびプログラム

(51)【国際特許分類】

   G06Q 50/10 20120101AFI20151008BHJP

   A63B 71/06 20060101ALI20151008BHJP

   G06Q 30/02 20120101ALI20151008BHJP

【ＦＩ】

   G06Q50/10

   A63B71/06 U

   A63B71/06 F

   G06Q30/02 130

   G06Q50/10 160

【請求項の数】10

【全頁数】31

(21)【出願番号】特願2012-24450(P2012-24450)

(22)【出願日】2012年2月7日

(65)【公開番号】特開2013-161366(P2013-161366A)

(43)【公開日】2013年8月19日

【審査請求日】2013年12月2日

(73)【特許権者】

【識別番号】506113602

【氏名又は名称】株式会社コナミデジタルエンタテインメント

(74)【代理人】

【識別番号】100125689

【弁理士】

【氏名又は名称】大林 章

(72)【発明者】

【氏名】夏目 恭行

(72)【発明者】

【氏名】篠田 健吾

(72)【発明者】

【氏名】橋本 卓也

【審査官】 山本 雅士

(56)【参考文献】

【文献】 特開平０５−１３７８２５（ＪＰ，Ａ）

【文献】 特開２００６−３３４０３２（ＪＰ，Ａ）

【文献】 特開２００２−０２４４６６（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｑ １０／００ − ５０／３４

Ａ６３Ｂ ７１／０６

(57)【特許請求の範囲】

【請求項1】

スポーツ施設でスポーツをプレイした利用者のプレイ結果と、プレイした日を示す日付情報とを含むプレイ情報を管理し、当該プレイ情報を利用者が操作する端末に提供するサーバであって、
前記利用者のプレイ情報および前記利用者がプレイしたスポーツ施設を示す施設情報を、前記利用者を識別する第１の利用者識別情報と関連付けて管理する管理部と、
前記管理部が管理する情報の中から、前記端末から指定されたプレイ情報に関連付けられている第１の利用者識別情報および施設情報を特定する特定部と、
前記特定部が特定した第１の利用者識別情報で特定される利用者の個人情報を取得する第１取得部と、
前記特定部が特定した施設情報が示すスポーツ施設での各利用者の前記プレイ情報および個人情報を当該利用者を識別する第２の利用者識別情報と関連付けて管理する管理装置にアクセスし、前記第１取得部が取得した個人情報と、前記指定されたプレイ情報に含まれる前記日付情報または前記端末から入力されたプレイ日を示す日時情報とに適合する前記第２の利用者識別情報を取得する第２取得部と、
前記指定されたプレイ情報と前記第２取得部が取得した第２の利用者識別情報とを前記管理装置に送信する送信部と、
を備えることを特徴とするサーバ。

【請求項2】

前記管理部は、前記第２取得部が取得した第２の利用者識別情報を、前記特定部が特定した第１の利用者識別情報および施設情報と関連付けて管理し、
前記第２取得部は、
前記特定部が特定した第１の利用者識別情報および施設情報と関連付けて前記管理部に第２の利用者識別情報が管理されている場合は、当該第２の利用者識別情報を前記管理部から取得し、
前記特定部が特定した第１の利用者識別情報および施設情報と関連付けて前記管理部に第２の利用者識別情報が管理されていない場合は、前記管理装置にアクセスし、前記第１取得部が取得した個人情報と、前記指定されたプレイ情報に含まれる前記日付情報または前記端末から入力されたプレイ日を示す日時情報とに適合する第２の利用者識別情報を取得する
ことを特徴とする請求項１に記載のサーバ。

【請求項3】

前記第１取得部は、前記端末から第１の利用者識別情報および施設情報が指定されると、指定された第１の利用者識別情報で特定される利用者の個人情報を取得し、
前記第２取得部は、前記指定された施設情報に対応する前記管理装置にアクセスし、前記第１取得部が取得した個人情報に適合する第２の利用者識別情報と、当該第２の利用者識別情報と関連付けられているプレイ情報とを取得し、
前記管理部は、前記第２取得部が取得したプレイ情報を、前記指定された第１の利用者識別情報および施設情報と関連付けて管理する
ことを特徴とする請求項１に記載のサーバ。

【請求項4】

前記管理部は、前記第２取得部が取得した第２の利用者識別情報を、前記指定された第１の利用者識別情報および施設情報と関連付けて管理し、
前記第２取得部は、
前記指定された第１の利用者識別情報および施設情報と関連付けて前記管理部に第２の利用者識別情報が管理されている場合は、当該第２の利用者識別情報と関連付けられているプレイ情報を前記管理装置から取得し、
前記指定された第１の利用者識別情報および施設情報と関連付けて前記管理部に第２の利用者識別情報が管理されていない場合は、前記管理装置にアクセスし、前記第１取得部が取得した個人情報に適合する第２の利用者識別情報と、当該第２の利用者識別情報と関連付けられているプレイ情報とを取得する
ことを特徴とする請求項３に記載のサーバ。

【請求項5】

前記第２取得部は、前記第２の利用者識別情報と関連付けられているプレイ情報のうち、前記管理部が管理していないプレイ情報を取得する
ことを特徴とする請求項３または４に記載のサーバ。

【請求項6】

前記端末からプレイ情報の閲覧が要求されると、閲覧が要求されたプレイ情報と、当該プレイ情報に関連付けられている施設情報とを前記管理部から取得して前記端末に送信する閲覧制御部をさらに備える
ことを特徴とする請求項１乃至５のうちいずれか１項に記載のサーバ。

【請求項7】

前記管理部は、一緒にプレイした複数の利用者の各々のプレイ情報に対し、同伴プレイ識別情報として同じ識別情報を関連付けて管理し、
前記閲覧制御部は、閲覧が要求されたプレイ情報に前記同伴プレイ識別情報が関連付けられている場合は、当該同伴プレイ識別情報が関連付けられている複数のプレイ情報を前記管理部から取得して前記端末に送信する
ことを特徴とする請求項６に記載のサーバ。

【請求項8】

一緒にプレイした複数の利用者の各々のプレイ情報を前記端末から受信する受信部と、
前記受信部が受信した複数のプレイ情報の各々に対し、前記同伴プレイ識別情報を付与する付与部と、をさらに備える
ことを特徴とする請求項７に記載のサーバ。

【請求項9】

スポーツ施設でスポーツをプレイした利用者のプレイ結果と、プレイした日を示す日付情報とを含むプレイ情報を管理し、当該プレイ情報を利用者が操作する端末に提供するサーバの制御方法であって、
前記利用者のプレイ情報および前記利用者がプレイしたスポーツ施設を示す施設情報を、前記利用者を識別する第１の利用者識別情報と関連付けて管理し、
管理する情報の中から、前記端末から指定されたプレイ情報に関連付けられている第１の利用者識別情報および施設情報を特定し、
特定した第１の利用者識別情報で特定される利用者の個人情報を取得し、
特定した施設情報が示すスポーツ施設での各利用者の前記プレイ情報および個人情報を当該利用者を識別する第２の利用者識別情報と関連付けて管理する管理装置にアクセスし、前記取得した個人情報と、前記指定されたプレイ情報に含まれる前記日付情報または前記端末から入力されたプレイ日を示す日時情報とに適合する前記第２の利用者識別情報を取得し、
前記指定されたプレイ情報と取得した第２の利用者識別情報とを前記管理装置に送信する、
ことを特徴とするサーバの制御方法。

【請求項10】

スポーツ施設でスポーツをプレイした利用者のプレイ結果と、プレイした日を示す日付情報とを含むプレイ情報を管理し、当該プレイ情報を利用者が操作する端末に提供するコンピュータを、
前記利用者のプレイ情報および前記利用者がプレイしたスポーツ施設を示す施設情報を、前記利用者を識別する第１の利用者識別情報と関連付けて管理する管理部、
前記管理部が管理する情報の中から、前記端末から指定されたプレイ情報に関連付けられている第１の利用者識別情報および施設情報を特定する特定部、
前記特定部が特定した第１の利用者識別情報で特定される利用者の個人情報を取得する第１取得部、
前記特定部が特定した施設情報が示すスポーツ施設での各利用者の前記プレイ情報および個人情報を当該利用者を識別する第２の利用者識別情報と関連付けて管理する管理装置にアクセスし、前記第１取得部が取得した個人情報と、前記指定されたプレイ情報に含まれる前記日付情報または前記端末から入力されたプレイ日を示す日時情報とに適合する前記第２の利用者識別情報を取得する第２取得部、および
前記指定されたプレイ情報と前記第２取得部が取得した第２の利用者識別情報とを前記管理装置に送信する送信部、
として機能させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、スポーツ施設でスポーツをプレイした利用者のプレイ情報（プレイ結果やプレイ日等）を管理する技術に関する。

【背景技術】

【0002】

例えば、特許文献１には、ゴルフ場の会員に対し、スコアの管理サービスを提供するゴルフ場管理装置が記載されている。また、特許文献２，３には、複数のゴルフ場でゴルフをプレイしたユーザのスコアをサーバで一元管理することが記載されている。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２００４−１１３５３５号公報

【特許文献2】特開２００４−２４６８５８号公報

【特許文献3】特開２００４−０７８４９２号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

ところで、利用者のスコアを一元管理するサーバとゴルフ場管理装置とは別個のシステムであるため、各々独自に利用者ＩＤを付与して各利用者のスコアデータを管理している。つまり、同じ利用者であっても、サーバで付与される利用者ＩＤと、ゴルフ場管理装置で付与される利用者ＩＤとは異なる。このようにサーバで使用される利用者ＩＤと、ゴルフ場管理装置で使用される利用者ＩＤとは異なるため、サーバとゴルフ場管理装置との間でスコアデータの受け渡しを行うことができないという問題があった。

【0005】

本発明は、上述した事情に鑑みてなされたものであり、サーバと管理装置が各々独自の利用者識別情報を使用して各利用者のプレイ情報を管理している場合であっても、両者の間でプレイ情報の受け渡しができるようにすることを解決課題とする。

【課題を解決するための手段】

【0006】

以上の課題を解決するため本発明が採用する手段を以下に説明する。なお、本発明の理解を容易にするため添付図面の参照符号を括弧書きにて付記するが、それにより本発明が図示の態様に限定されるものではない。

【0007】

本発明に係るサーバ（１０）は、スポーツ施設（Ｇ）でスポーツをプレイした利用者のプレイ結果を含むプレイ情報を管理し、当該プレイ情報を利用者が操作する端末（５０）に提供するサーバ（１０）であって、前記利用者のプレイ情報および前記利用者がプレイしたスポーツ施設（Ｇ）を示す施設情報を、前記利用者を識別する第１の利用者識別情報と関連付けて管理する管理部（１１０，１５０）と、前記管理部（１１０，１５０）が管理する情報の中から、前記端末（５０）から指定されたプレイ情報に関連付けられている第１の利用者識別情報および施設情報を特定する特定部（１１０）と、前記特定部（１１０）が特定した第１の利用者識別情報で特定される利用者の個人情報を取得する第１取得部（１１０）と、前記特定部（１１０）が特定した施設情報が示すスポーツ施設（Ｇ）での各利用者のプレイ情報および個人情報を当該利用者を識別する第２の利用者識別情報と関連付けて管理する管理装置（２０）にアクセスし、前記第１取得部（１１０）が取得した個人情報に適合する前記第２の利用者識別情報を取得する第２取得部（１１０，１４０）と、前記指定されたプレイ情報と前記第２取得部（１１０，１４０）が取得した第２の利用者識別情報とを前記管理装置（２０）に送信する送信部（１１０，１４０）と、を備えることを特徴とする。

【0008】

以上の構成によれば、サーバは、例えば、スポーツ施設Ａでの利用者Ｘのプレイ情報をスポーツ施設Ａの管理装置に送信する場合に、スポーツ施設Ａの管理装置から利用者Ｘの個人情報に適合する第２の利用者識別情報を取得し、取得した第２の利用者識別情報と利用者Ｘのプレイ情報とをスポーツ施設Ａの管理装置に送信する。このようにスポーツ施設Ａの管理装置から利用者Ｘの個人情報に適合する第２の利用者識別情報を取得することで、利用者Ｘに対してスポーツ施設Ａの管理装置が付与した第２の利用者識別情報を取得することができる。したがって、サーバと管理装置が各々独自の利用者識別情報を使用して各利用者のプレイ情報を管理している場合であっても、サーバが使用している第１の利用者識別情報と、管理装置が使用している第２の利用者識別情報との不整合を解消し、サーバから送信した利用者Ｘのプレイ情報を、スポーツ施設Ａの管理装置でも利用者Ｘのプレイ情報として登録することが可能になる。

【0009】

なお、「スポーツ施設」とは、例えば、ゴルフ場、ボーリング場、テニス場、スポーツジム、スイミングクラブ、陸上競技場等である。また、バーチャルゴルフマシンが設置されたゴルフバーも「スポーツ施設」に含まれる。また、ここから明らかとなるように「スポーツ」には、例えば、ゴルフ、ボーリング、テニス、水泳、各種の陸上競技等が含まれる。「プレイ結果」は、例えば、スコア、勝敗、順位、タイム等である。「プレイ情報」には、プレイ結果の他に、例えば、プレイ日、天候、一緒にプレイした利用者に関する情報等が含まれてもよい。「施設情報」は、スポーツ施設を一意に識別する施設識別情報の他、施設名や、施設名とその所在地の名称とを組み合わせた情報等を使用することができる。「個人情報」は、例えば、氏名、生年月日、住所、電話番号（自宅または携帯電話機）、メールアドレスのいずれか１以上である。「第１の利用者識別情報」は、サーバでプレイ情報等の管理に用いる利用者識別情報であり、「第２の利用者識別情報」は、管理装置でプレイ情報等の管理に用いる利用者識別情報である。管理部が管理する情報は、サーバ内に記憶されていてもよいし、サーバとは別の装置に記憶されていてもよい。つまり、「プレイ情報」、「施設情報」および「第１の利用者識別情報」を関連付けて格納するデータベースは、サーバに備わる記憶部に記憶されていてもよいし、サーバとは別の装置に備わる記憶部に記憶されていてもよい。第１取得部は、利用者の個人情報を、サーバ内から取得してもよいし、サーバとは別の装置から取得してもよい。つまり、利用者の個人情報についても、サーバに備わる記憶部に記憶されていてもよいし、サーバとは別の装置に備わる記憶部に記憶されていてもよい。

【0010】

また、管理装置が管理する情報も、管理装置内に記憶されていてもよいし、管理装置とは別の装置に記憶されていてもよい。つまり、「プレイ情報」、「個人情報」および「第２の利用者識別情報」を関連付けて格納するデータベースは、管理装置に備わる記憶部に記憶されていてもよいし、管理装置とは別の装置に備わる記憶部に記憶されていてもよい。また、このデータベースは、「プレイ情報」と「第２の利用者識別情報」とを関連付けて格納する第１のデータベースと、「個人情報」と「第２の利用者識別情報」とを関連付けて格納する第２のデータベースとに分かれていてもよい。また、管理装置は、プレイ情報を第２の利用者識別情報と関連付けて管理可能な構成であればよく、必ずしもプレイ情報を保持している必要はない。また、管理装置は、例えば、「プレイ情報」と「第２の利用者識別情報」とを関連付けて管理する第１の管理サーバと、「個人情報」と「第２の利用者識別情報」とを関連付けて管理する第２の管理サーバとで構成されてもよい。サーバで管理される「プレイ情報」と、管理装置で管理される「プレイ情報」は、データ構成が異なってもよい。例えば、サーバで管理される「プレイ情報」は、プレイ結果、プレイ日および天候で構成される一方、管理装置で管理される「プレイ情報」は、プレイ結果およびプレイ日で構成されてもよい。また、両者のデータフォーマット（データ記録形式）が異なってもよい。送信部は、管理装置に対し、「プレイ情報」と「第２の利用者識別情報」を一緒に送信しなくてもよい。例えば、送信部は、まず「プレイ情報」を送信し、管理装置から利用者に関する問い合わせがあると、この問い合わせに応じて「第２の利用者識別情報」を送信してもよい。

【0011】

また、上述したサーバ（１０）において、前記管理部（１１０，１５０）は、前記第２取得部（１１０，１４０）が取得した第２の利用者識別情報を、前記特定部（１１０）が特定した第１の利用者識別情報および施設情報と関連付けて管理し、前記第２取得部（１１０，１４０）は、前記特定部（１１０）が特定した第１の利用者識別情報および施設情報と関連付けて前記管理部（１１０，１５０）に第２の利用者識別情報が管理されている場合は、当該第２の利用者識別情報を前記管理部（１１０，１５０）から取得し、前記特定部（１１０）が特定した第１の利用者識別情報および施設情報と関連付けて前記管理部（１１０，１５０）に第２の利用者識別情報が管理されていない場合は、前記管理装置（２０）にアクセスし、前記第１取得部（１１０）が取得した個人情報に適合する第２の利用者識別情報を取得してもよい。

【0012】

この場合、過去に一度でもプレイ情報を送信したことのある「利用者」と「管理装置」の組み合わせについては、次回以降、プレイ情報を送信する場合に、第１取得部による処理と第２取得部による処理を省略することができる。このためプレイ情報の送信に要する処理を簡素化し、処理時間を短縮することができる。なお、この場合も、第２取得部が取得した「第２の利用者識別情報」と、特定部が特定した「第１の利用者識別情報」および「施設情報」とを関連付けて格納するデータベースは、サーバに備わる記憶部に記憶されてもよいし、サーバとは別の装置に備わる記憶部に記憶されてもよい。

【0013】

また、上述したサーバ（１０）において、前記プレイ情報には、プレイした日を示す日付情報がさらに含まれ、前記第２取得部（１１０，１４０）は、前記管理装置（２０）にアクセスし、前記第１取得部（１１０）が取得した個人情報と、前記指定されたプレイ情報に含まれる前記日付情報または前記端末（５０）から入力されたプレイ日を示す日時情報とに適合する第２の利用者識別情報を取得してもよい。

【0014】

例えば、個人情報として氏名を用いて第２の利用者識別情報を取得した場合、同姓同名の人がいる可能性があるので、第２の利用者識別情報を１つに絞りきれないことがある。また、個人情報として自宅の住所や自宅の電話番号を用いて第２の利用者識別情報を取得した場合も、家族内に同じスポーツ施設の利用者が複数存在する可能があるので、第２の利用者識別情報を１つに絞りきれないことがある。管理装置には、「第２の利用者識別情報」と関連付けて「個人情報」の他に「プレイ情報」が管理されており、この「プレイ情報」にはプレイ日の情報が含まれている。また、管理装置には、プレイ結果は未登録であっても、スポーツ施設の利用予約や、プレイ日の当日に利用者がスポーツ施設のフロントで受付を済ましたことに応じて、第２の利用者識別情報とプレイ日の日付情報が登録されるケースが多々ある。したがって、個人情報の他に、送信するプレイ情報に含まれるプレイ日の日付情報、または端末の利用者が入力した過去のプレイ日の日付情報を用いて第２の利用者識別情報を取得することで、第２の利用者識別情報の取得精度を高めることができる。なお、プレイ日の日付情報には、プレイした時刻の情報が含まれてもよい。

【0015】

また、上述したサーバ（１０）において、前記第２取得部（１１０，１４０）は、前記第１取得部（１１０）が取得した個人情報に適合する第２の利用者識別情報が複数ある場合、当該複数の第２の利用者識別情報の各々に関連付けられている個人情報を前記管理装置（２０）から取得して前記端末（５０）に送信し、送信した個人情報のうち前記端末（５０）から指定された個人情報に関連付けられている第２の利用者識別情報を、前記指定されたプレイ情報と関連付けて前記管理装置（２０）に送信する第２の利用者識別情報に決定してもよい。
この構成によれば、第２の利用者識別情報を１つに絞りきれなかった場合に、複数の候補者の個人情報を端末の利用者に提示し、最終的な選択を端末の利用者に行わせることができる。

【0016】

また、上述したサーバ（１０）において、前記第１取得部（１１０）は、前記端末（５０）から第１の利用者識別情報および施設情報が指定されると、指定された第１の利用者識別情報で特定される利用者の個人情報を取得し、前記第２取得部（１１０，１４０）は、前記指定された施設情報に対応する前記管理装置（２０）にアクセスし、前記第１取得部（１１０）が取得した個人情報に適合する第２の利用者識別情報と、当該第２の利用者識別情報と関連付けられているプレイ情報とを取得し、前記管理部（１１０，１５０）は、前記第２取得部（１１０，１４０）が取得したプレイ情報を、前記指定された第１の利用者識別情報および施設情報と関連付けて管理してもよい。

【0017】

以上の構成によれば、サーバは、例えば、利用者Ｘのプレイ情報をスポーツ施設Ａの管理装置から取得する場合に、スポーツ施設Ａの管理装置から利用者Ｘの個人情報に適合する第２の利用者識別情報を取得することで、利用者Ｘに対してスポーツ施設Ａの管理装置が付与した第２の利用者識別情報を取得することができるから、この第２の利用者識別情報に関連付けられているプレイ情報をスポーツ施設Ａの管理装置から取得することで、利用者Ｘのプレイ情報を取得することが可能になる。したがって、サーバと管理装置が各々独自の利用者識別情報を使用して各利用者のプレイ情報を管理している場合であっても、サーバが使用している第１の利用者識別情報と、管理装置が使用している第２の利用者識別情報との不整合を解消し、スポーツ施設Ａの管理装置から利用者Ｘのプレイ情報を取得し、これをサーバでも利用者Ｘのプレイ情報として管理することができる。また、利用者Ｘのプレイ情報を各管理装置から取得してサーバで管理することが可能になるので、利用者Ｘのプレイ情報をサーバで一元管理することができる。

【0018】

また、上述したサーバ（１０）において、前記管理部（１１０，１５０）は、前記第２取得部（１１０，１４０）が取得した第２の利用者識別情報を、前記指定された第１の利用者識別情報および施設情報と関連付けて管理し、前記第２取得部（１１０，１４０）は、前記指定された第１の利用者識別情報および施設情報と関連付けて前記管理部（１１０，１５０）に第２の利用者識別情報が管理されている場合は、当該第２の利用者識別情報と関連付けられているプレイ情報を前記管理装置（２０）から取得し、前記指定された第１の利用者識別情報および施設情報と関連付けて前記管理部（１１０，１５０）に第２の利用者識別情報が管理されていない場合は、前記管理装置（２０）にアクセスし、前記第１取得部（１１０）が取得した個人情報に適合する第２の利用者識別情報と、当該第２の利用者識別情報と関連付けられているプレイ情報とを取得してもよい。

【0019】

この場合、過去に一度でもプレイ情報を送信または取得したことのある「利用者」と「管理装置」の組み合わせについては、次回以降、プレイ情報を取得する場合に、個人情報を取得する処理と、取得した個人情報に適合する第２の利用者識別情報を管理装置から取得する処理とを省略することができる。このためプレイ情報の送信に要する処理を簡素化し、処理時間を短縮することができる。

【0020】

また、上述したサーバ（１０）において、前記第２取得部（１１０，１４０）は、前記第２の利用者識別情報と関連付けられているプレイ情報のうち、前記管理部（１１０，１５０）が管理していないプレイ情報を取得してもよい。
この場合、既にサーバで管理しているプレイ情報については管理装置からの取得を控えることができるので、無駄なデータの取得を行わずに済む。

【0021】

また、上述したサーバ（１０）において、前記端末（５０）からプレイ情報の閲覧が要求されると、閲覧が要求されたプレイ情報と、当該プレイ情報に関連付けられている施設情報とを前記管理部（１１０，１５０）から取得して前記端末（５０）に送信する閲覧制御部（１１０，１４０）をさらに備えてもよい。
この場合、プレイ情報と施設情報を端末で閲覧することができる。

【0022】

また、上述したサーバ（１０）において、前記管理部（１１０，１５０）は、一緒にプレイした複数の利用者の各々のプレイ情報に対し、同伴プレイ識別情報として同じ識別情報を関連付けて管理し、前記閲覧制御部（１１０，１４０）は、閲覧が要求されたプレイ情報に前記同伴プレイ識別情報が関連付けられている場合は、当該同伴プレイ識別情報が関連付けられている複数のプレイ情報を前記管理部（１１０，１５０）から取得して前記端末（５０）に送信してもよい。
この場合、一緒にプレイした利用者のプレイ情報についても端末で閲覧することが可能になる。

【0023】

また、上述したサーバ（１０）において、一緒にプレイした複数の利用者の各々のプレイ情報を前記端末（５０）から受信する受信部（１１０，１４０）と、前記受信部（１１０，１４０）が受信した複数のプレイ情報の各々に対し、前記同伴プレイ識別情報を付与する付与部（１１０）と、をさらに備えてもよい。
この場合、同伴プレイ識別情報をサーバで付与することができる。

【0024】

本発明は、サーバの制御方法としても捉えることができる。この場合、本発明に係るサーバ（１０）の制御方法は、スポーツ施設（Ｇ）でスポーツをプレイした利用者のプレイ結果を含むプレイ情報を管理し、当該プレイ情報を利用者が操作する端末（５０）に提供するサーバ（１０）の制御方法であって、前記利用者のプレイ情報および前記利用者がプレイしたスポーツ施設（Ｇ）を示す施設情報を、前記利用者を識別する第１の利用者識別情報と関連付けて管理し、管理する情報の中から、前記端末（５０）から指定されたプレイ情報に関連付けられている第１の利用者識別情報および施設情報を特定し、特定した第１の利用者識別情報で特定される利用者の個人情報を取得し、特定した施設情報が示すスポーツ施設（Ｇ）での各利用者のプレイ情報および個人情報を当該利用者を識別する第２の利用者識別情報と関連付けて管理する管理装置（２０）にアクセスし、取得した個人情報に適合する前記第２の利用者識別情報を取得し、前記指定されたプレイ情報と取得した第２の利用者識別情報とを前記管理装置（２０）に送信することを特徴とする。
以上の構成によれば、本発明のサーバ（１０）と同様の効果を奏する。

【0025】

また、本発明は、上述したサーバ（１０）としてコンピュータを機能させるためのプログラムとしても特定される。この場合、本発明に係るプログラムは、スポーツ施設（Ｇ）でスポーツをプレイした利用者のプレイ結果を含むプレイ情報を管理し、当該プレイ情報を利用者が操作する端末（５０）に提供するコンピュータ（１０）を、前記利用者のプレイ情報および前記利用者がプレイしたスポーツ施設（Ｇ）を示す施設情報を、前記利用者を識別する第１の利用者識別情報と関連付けて管理する管理部（１１０，１５０）、前記管理部（１１０，１５０）が管理する情報の中から、前記端末（５０）から指定されたプレイ情報に関連付けられている第１の利用者識別情報および施設情報を特定する特定部（１１０）、前記特定部（１１０）が特定した第１の利用者識別情報で特定される利用者の個人情報を取得する第１取得部（１１０）、前記特定部（１１０）が特定した施設情報が示すスポーツ施設（Ｇ）での各利用者のプレイ情報および個人情報を当該利用者を識別する第２の利用者識別情報と関連付けて管理する管理装置（２０）にアクセスし、前記第１取得部（１１０）が取得した個人情報に適合する前記第２の利用者識別情報を取得する第２取得部（１１０，１４０）、および前記指定されたプレイ情報と前記第２取得部（１１０，１４０）が取得した第２の利用者識別情報とを前記管理装置（２０）に送信する送信部（１１０，１４０）、として機能させる。
以上の構成によれば、本発明のサーバ（１０）と同様の効果を奏する。なお、本発明のプログラムは、例えば、コンピュータが読取可能な記録媒体に記録された形態で管理者等に提供されてコンピュータにインストールされる他、通信網を介した配信の形態で提供されてコンピュータにインストールされる。記録媒体には、例えばＣＤ−ＲＯＭやＵＳＢメモリ等が含まれる。

【発明の効果】

【0026】

本発明によれば、サーバと管理装置が各々独自の利用者識別情報を使用して各利用者のプレイ情報を管理している場合であっても、両者の間でプレイ情報の受け渡しを行うことができる。

【図面の簡単な説明】

【0027】

【図1】管理システムの全体構成を例示するブロック図である。

【図2】ゴルフ場サーバの利用者管理ＤＢのデータ構造を例示する図である。

【図3】ゴルフ場サーバのプレイ情報管理ＤＢのデータ構造を例示する図である。

【図4】ＳＮＳサーバのハードウェア構成を例示するブロック図である。

【図5】プロフィール管理ＤＢのデータ構造を例示する図である。

【図6】ゴルフ場管理ＤＢのデータ構造を例示する図である。

【図7】プレイ情報管理ＤＢのデータ構造を例示する図である。

【図8】利用者ＩＤ登録ＤＢのデータ構造を例示する図である。

【図9】ラウンド前処理の流れを例示するフローチャートである。

【図10】プレイ情報記録テーブルのデータ構造を例示する図である。

【図11】閲覧処理の流れを例示するシーケンスチャートである。

【図12】スマートフォンの画面表示例を示す図である。

【図13】プレイ情報の送信処理の流れを例示するシーケンスチャートである。

【図14】スマートフォンの画面表示例を示す図である。

【図15】スマートフォンの画面表示例を示す図である。

【図16】プレイ情報の取得処理の流れを例示するシーケンスチャートである。

【図17】送信処理の変形例を示すシーケンスチャートである。

【発明を実施するための形態】

【0028】

以下、図面を参照して本発明の実施の形態を説明する。
＜１．実施形態＞
図１は、管理システム１の全体構成を例示するブロック図である。
同図に示す管理システム１は、ゴルフ場でゴルフをプレイした利用者のプレイ情報（スコアやプレイ日等）を管理するシステムである。例えば、管理システム１は、ＳＮＳ（Social Networking Service）サーバ１０と、ゴルフ場Ｇ_１，Ｇ_２，…Ｇ_ｍに対応して設けられたｍ台のゴルフ場サーバ２０_１，２０_２，…２０_ｍと、インターネット３０と、移動体通信網４０と、ｎ台のスマートフォン５０_１，５０_２，…５０_ｎとを備える。なお、ｍ，ｎは、いずれも２以上の整数である。また、移動体通信網４０は、図示を省略しているが基地局，交換局，ゲートウェイサーバ等を備える。ＳＮＳサーバ１０は、インターネット３０および移動体通信網４０を介してスマートフォン５０_１，５０_２，…５０_ｎの各々とパケット通信を行うことができる。また、ＳＮＳサーバ１０は、インターネット３０を介してゴルフ場サーバ２０_１，２０_２，…２０_ｍの各々ともパケット通信を行うことができる。

【0029】

以降、本明細書では、特に区別をする必要がない限り、ゴルフ場Ｇ_１，Ｇ_２，…Ｇ_ｍの各々を「ゴルフ場Ｇ」と記載し、ゴルフ場サーバ２０_１，２０_２，…２０_ｍの各々を「ゴルフ場サーバ２０」と記載し、スマートフォン５０_１，５０_２，…５０_ｎの各々を「スマートフォン５０」と記載する。

【0030】

ＳＮＳサーバ１０は、会員制のサイトであって、会員同士の間で、趣味や嗜好，居住地域，出身校等といったつながりを通じて新たな人間関係を構築したり、友人との交流を深めたりするコミュニケーションの場を提供する。例えば、ＳＮＳサーバ１０が提供する機能には、自分のプロフィールを他の会員に公開する機能、会員同士の間でメッセージを交換する機能、友人やサークル仲間（共に会員）を登録しておくアドレス帳の機能、趣味や地域などテーマを決めて掲示板を作り、同じ趣味を持つ会員や同じ地域に住む会員と交流する機能等がある。これらの機能により、例えば、ＳＮＳサーバ１０を介してゴルフを趣味に持つ会員同士で情報交換を行ったり、一緒にゴルフをプレイするメンバーを募ったりすることができる。

【0031】

また、ＳＮＳサーバ１０は、ゴルフ場Ｇでゴルフをプレイした会員のプレイ情報（スコアやプレイ日等）を管理する機能を備える。会員は、自身のスマートフォン５０を操作してＳＮＳサーバ１０にアクセスし、ＳＮＳサーバ１０で管理されているプレイ情報を閲覧することができる。また、ＳＮＳサーバ１０は、ＳＮＳサーバ１０で管理している会員のプレイ情報をゴルフ場サーバ２０に送信する機能や、会員の過去のプレイ情報をゴルフ場サーバ２０から取得する機能を備える。

【0032】

ゴルフ場サーバ２０は、例えばゴルフ場Ｇ毎に設けられ、ゴルフ場Ｇの利用者に対し、スコアやプレイ日等のプレイ情報の管理サービスや、ゴルフ場Ｇの利用予約サービスを提供する。なお、ゴルフ場Ｇの利用者には、ゴルフ場Ｇの会員権を有するメンバーの他に、メンバー以外のビジターが含まれる。例えば図１に示すように、ゴルフ場Ｇ_１に対してゴルフ場サーバ２０_１が設けられ、ゴルフ場Ｇ_２に対してゴルフ場サーバ２０_２が設けられ、…ゴルフ場Ｇ_ｍに対してゴルフ場サーバ２０_ｍが設けられている場合、ゴルフ場サーバ２０_１には、ゴルフ場Ｇ_１の利用者の個人情報を管理する利用者管理ＤＢ（DataBase）２１_１と、ゴルフ場Ｇ_１の利用者のプレイ情報を管理するプレイ情報管理ＤＢ２２_１とが記憶される。また、ゴルフ場サーバ２０_２には、ゴルフ場Ｇ_２用の利用者管理ＤＢ２１_２およびプレイ情報管理ＤＢ２２_２が記憶され、ゴルフ場サーバ２０_ｍには、ゴルフ場Ｇ_ｍ用の利用者管理ＤＢ２１_ｍおよびプレイ情報管理ＤＢ２２_ｍが記憶される。

【0033】

なお、ゴルフ場サーバ２０は、ゴルフ場Ｇ毎に設けられる態様に限らない。例えば、１台のゴルフ場サーバ２０で複数のゴルフ場Ｇを管理してもよい。また、ゴルフ場サーバ２０の設置場所は、ゴルフ場Ｇ内であってもよいし、ゴルフ場Ｇの外であってもよい。また、各ゴルフ場サーバ２０は、各々独自に利用者ＩＤ（IDentification）を付与して利用者の個人情報やプレイ情報を管理しており、各ゴルフ場サーバ２０は、管理している利用者の個人情報やプレイ情報が異なることに加え、使用している利用者ＩＤも異なる。以降、本明細書では、特に区別をする必要がない限り、利用者管理ＤＢ２１_１，２１_２，…２１_ｍの各々を「利用者管理ＤＢ２１」と記載し、プレイ情報管理ＤＢ２２_１，２２_２，…２２_ｍの各々を「プレイ情報管理ＤＢ２２」と記載する。

【0034】

スマートフォン５０は、携帯電話機の機能を兼ね備えた小型のコンピュータである。例えば、スマートフォン５０は、音声通話機能、ウェブ閲覧機能、電子メールの送受信機能、ＧＰＳ（Global Positioning System）による測位機能等を備える。会員は、自身のスマートフォン５０を操作してＳＮＳサーバ１０にアクセスし、ＳＮＳサーバ１０が提供する各種のサービスを享受することができる。また、スマートフォン５０のストレージ（補助記憶装置）には、ＧＰＳ機能を利用してゴルフのプレイを支援するゴルフナビゲーション用のアプリケーション５１（以下、「ゴルフナビアプリ５１」と記載する）がインストールされている。

【0035】

ゴルフナビアプリ５１は、例えば、スマートフォン５０を携帯してゴルフをプレイしている利用者の現在位置を測定し、プレイしているゴルフ場Ｇやホールを特定する機能、プレイしているホールのコースレイアウトを表示する機能、プレイしているホールの攻略方法をアドバイスする機能、グリーン，ハザード，ピン位置までの距離やショットの飛距離を算出して通知する機能等を備える。また、ゴルフナビアプリ５１は、スコア等のプレイ情報を入力する機能、入力されたプレイ情報をＳＮＳサーバ１０にアップロードする機能、ＳＮＳサーバ１０で管理されているプレイ情報を閲覧する機能、ゴルフ場Ｇの利用予約を行う機能等を備える。

【0036】

図２は、ゴルフ場サーバ２０_１のハードディスクに記憶されている利用者管理ＤＢ２１_１のデータ構造を例示する図である。利用者管理ＤＢ２１_１には、ゴルフ場Ｇ_１の利用者毎に、利用者ＩＤと、利用者の個人情報（氏名、生年月日、住所および電話番号）とが関連付けて格納される。利用者ＩＤは、ゴルフ場Ｇ_１の利用者を一意に識別する識別情報である。例えば、ゴルフ場サーバ２０_１は、ゴルフ場Ｇ_１の新規の利用者に対して新たな利用者ＩＤを付与し、付与した利用者ＩＤを、利用者の個人情報と関連付けて利用者管理ＤＢ２１_１に登録する。なお、利用者管理ＤＢ２１_１には、利用者の個人情報として、性別，年齢，職業，メールアドレス，勤務先等の情報がさらに格納されてもよい。

【0037】

図３は、ゴルフ場サーバ２０_１のハードディスクに記憶されているプレイ情報管理ＤＢ２２_１のデータ構造を例示する図である。プレイ情報管理ＤＢ２２_１には、ゴルフ場Ｇ_１の利用者のプレイ情報（プレイ日およびスコア）が利用者ＩＤと関連付けて格納される。プレイ日は、ゴルフをプレイした年月日を示す日付情報である。また、本実施形態では、プレイ情報としてプレイ日およびスコアを管理する場合について説明するが、スコアには、１８ホールでのトータルの打数の他、ホール毎の打数やアゲインストパー等の情報が含まれる。なお、“ＮＵＬＬ”は、スコアが登録されていない空の状態を示す。つまり、スコアの項目が“ＮＵＬＬ”の場合は、スコアが未登録であることを意味する。

【0038】

例えば、利用者がゴルフ場Ｇ_１でゴルフをプレイした後、フロントにスコアカードを提出した場合や、利用者がスマートフォン５０を操作してＳＮＳサーバ１０からゴルフ場サーバ２０_１にプレイ情報の送信を指示した場合に、利用者ＩＤおよびプレイ情報がプレイ情報管理ＤＢ２２_１に登録される。また、利用者がスマートフォン５０を操作してゴルフ場Ｇ_１の利用予約を行った場合や、利用者がプレイ日の当日にゴルフ場Ｇ_１のフロントで受付を済ましたことに応じて、スコアを除く利用者ＩＤおよびプレイ日がプレイ情報管理ＤＢ２２_１に登録されることもある。

【0039】

なお、図２および図３には、ゴルフ場サーバ２０_１に記憶されている利用者管理ＤＢ２１_１とプレイ情報管理ＤＢ２２_１を例示したが、ゴルフ場サーバ２０_１以外の各ゴルフ場サーバ２０に記憶されている利用者管理ＤＢ２１とプレイ情報管理ＤＢ２２についても、概ね同様のデータ構造を有する。但し、前述したように各ゴルフ場サーバ２０は各々独自に利用者ＩＤを付与しているので、同じ利用者であっても各ゴルフ場サーバ２０で付与される利用者ＩＤは異なる。

【0040】

図４は、ＳＮＳサーバ１０のハードウェア構成を例示するブロック図である。
ＳＮＳサーバ１０は、ＣＰＵ（Central Processing Unit）１１０と、ＲＯＭ（Read Only Memory）１２０と、ＲＡＭ（Random Access Memory）１３０と、通信ＩＦ（InterFace）１４０と、ハードディスク１５０とを備える。なお、ＳＮＳサーバ１０は、キーボードやマウス等の入力部や、液晶ディスプレイ等の表示部をさらに備えてもよい。ＣＰＵ１１０は、ＲＯＭ１２０やハードディスク１５０に記憶されている各種のプログラムを実行することでＳＮＳサーバ１０の各部を制御する。ＲＯＭ１２０には、ＳＮＳサーバ１０の各部の基本制御を司るプログラム等が記憶されている。ＲＡＭ１３０は、ＣＰＵ１１０のワークエリアとして用いられる。通信ＩＦ１４０は、ＣＰＵ１１０の制御の下、スマートフォン５０やゴルフ場サーバ２０との間で行われるパケット通信を制御する。ハードディスク１５０には、例えば、後述するプレイ情報の送信処理（図１３）や取得処理（図１６）のうちＳＮＳサーバ１０で行われる処理を制御するためのプログラムの他、プロフィール管理ＤＢ１５１、ゴルフ場管理ＤＢ１５２、プレイ情報管理ＤＢ１５３および利用者ＩＤ登録ＤＢ１５４が記憶されている。

【0041】

図５は、プロフィール管理ＤＢ１５１のデータ構造を例示する図である。
プロフィール管理ＤＢ１５１には、ＳＮＳサーバ１０の会員毎に、会員ＩＤと、会員のプロフィール情報（氏名、生年月日および電話番号）とが関連付けて格納される。会員ＩＤは、ＳＮＳサーバ１０の会員を一意に識別する識別情報である。例えば、ＳＮＳサーバ１０は、会員登録を行った新規の会員に対して新たな会員ＩＤを付与し、付与した会員ＩＤを、会員登録の際に入力された会員のプロフィール情報と関連付けてプロフィール管理ＤＢ１５１に登録する。なお、会員ＩＤは、ＳＮＳサーバ１０によって付与される識別情報であるので、各ゴルフ場サーバ２０で使用される利用者ＩＤとは異なる。つまり、ＳＮＳサーバ１０で使用される会員ＩＤと、各ゴルフ場サーバ２０で使用される利用者ＩＤとは異なる。また、プロフィール管理ＤＢ１５１には、会員のプロフィール情報として、住所，性別，年齢，職業，メールアドレス，自宅の電話番号，勤務先等の情報や、顔写真の画像データがさらに格納されてもよい。また、会員ＩＤとして、例えば、会員のメールアドレスや、会員が所有するスマートフォン５０の電話番号を使用することもできる。

【0042】

図６は、ゴルフ場管理ＤＢ１５２のデータ構造を例示する図である。
ゴルフ場管理ＤＢ１５２には、ゴルフ場Ｇ毎に、ゴルフ場ＩＤ、ゴルフ場名およびアクセス方法が関連付けて格納される。ゴルフ場ＩＤは、ゴルフ場Ｇを一意に識別する識別情報であり、ＳＮＳサーバ１０によって付与される。なお、ゴルフ場サーバ２０がゴルフ場Ｇ毎に設けられている場合、ゴルフ場ＩＤは、ゴルフ場Ｇだけでなくゴルフ場サーバ２０を一意に識別する識別情報でもある。アクセス方法の項目には、例えば、同図に示す“Ａカントリークラブ”の場合であれば、“Ａカントリークラブ”のゴルフ場サーバ２０のＵＲＬ（Uniform Resource Locator）と、“Ａカントリークラブ”のゴルフ場サーバ２０との間でプレイ情報の受け渡しや後述するプロフィールマッチングを行う際の通信手順等を規定したＡＰＩ（Application Program Interface）とが登録される。

【0043】

ＳＮＳサーバ１０の運営者は、予め全てのゴルフ場Ｇについて、ゴルフ場名およびアクセス方法（ＵＲＬおよびＡＰＩ）を調べ、これらをゴルフ場ＩＤと関連付けてゴルフ場管理ＤＢ１５２に登録しておく。また、新たなゴルフ場Ｇがオープンした場合、ＳＮＳサーバ１０の運営者は、新たにオープンしたゴルフ場Ｇについて、ゴルフ場名およびアクセス方法を調べ、ＳＮＳサーバ１０によって新たに付与されたゴルフ場ＩＤと関連付けてゴルフ場管理ＤＢ１５２に登録する。なお、ゴルフ場ＩＤとして、例えば、ゴルフ場名や、ゴルフ場名とその所在地の名称とを組み合わせた文字列を使用することもできる。

【0044】

図７は、プレイ情報管理ＤＢ１５３のデータ構造を例示する図である。
プレイ情報管理ＤＢ１５３には、会員のプレイ情報（プレイ日およびスコア）が、会員ＩＤ、ゴルフ場ＩＤおよびラウンドＩＤと関連付けて格納される。なお、本実施形態では、プレイ情報管理ＤＢ１５３（ＳＮＳサーバ１０）で管理されるプレイ情報と、プレイ情報管理ＤＢ２２（ゴルフ場サーバ２０）で管理されるプレイ情報とが同じであり、スコアには、前述したように１８ホールでのトータルの打数の他、ホール毎の打数やアゲインストパー等の情報が含まれる。ラウンドＩＤは、パーティ（一緒にラウンドする３〜４人の組）毎に固有の識別情報であり、例えばＳＮＳサーバ１０によって付与される。このラウンドＩＤは、同伴競技者を特定するために使用される。例えば、同図に示すプレイ情報管理ＤＢ１５３において、会員ＩＤが“M00000001”〜“M00000003”および“M00000698”の計４人は、いずれもラウンドＩＤが“R00000001”であるので、一緒にゴルフをプレイしたメンバーであることがわかる。

【0045】

ＳＮＳサーバ１０は、スマートフォン５０からアップロードされた会員のプレイ情報をプレイ情報管理ＤＢ１５３に登録する。また、ＳＮＳサーバ１０は、会員の過去のプレイ情報をゴルフ場サーバ２０から取得してプレイ情報管理ＤＢ１５３に登録することもできる。なお、プレイ情報管理ＤＢ１５３には、１つのプレイ情報を登録するにつき、１つのレコードが追加される。例えば、ある会員のプレイ情報として、３つのプレイ情報をプレイ情報管理ＤＢ１５３に登録する場合、３つのプレイ情報の各々は、それぞれ別のレコードとしてプレイ情報管理ＤＢ１５３に格納される。このようにプレイ情報管理ＤＢ１５３には、複数のプレイ情報がそれぞれ別のレコードとして登録される。したがって、ＣＰＵ１１０は、例えば、会員ＩＤ“M00000001”を検索キーとしてプレイ情報管理ＤＢ１５３を検索することで、会員ＩＤが“M00000001”の会員のプレイ情報を抽出することができる。また、ＣＰＵ１１０は、例えば、ゴルフ場ＩＤ“G00001”を検索キーとしてプレイ情報管理ＤＢ１５３を検索することで、ゴルフ場ＩＤが“G00001”のゴルフ場Ｇにおける各会員のプレイ情報を抽出することができる。

【0046】

図８は、利用者ＩＤ登録ＤＢ１５４のデータ構造を例示する図である。
前述したように各ゴルフ場サーバ２０は、各々独自に利用者ＩＤを付与して利用者のプレイ情報等を管理しており、使用している利用者ＩＤが異なる。また、ＳＮＳサーバ１０で使用している会員ＩＤも、各ゴルフ場サーバ２０で使用している利用者ＩＤとは異なる。例えば、同図に示す利用者ＩＤ登録ＤＢ１５４からも明らかとなるように、会員ＩＤが“M00000001”の会員に対し、ゴルフ場ＩＤが“G00001”のゴルフ場サーバ２０では利用者ＩＤ“001612”を付与しており、ゴルフ場ＩＤが“G00732”のゴルフ場サーバ２０では利用者ＩＤ“YA-0001-1235”を付与しており、ゴルフ場ＩＤが“G00112”のゴルフ場サーバ２０では利用者ＩＤ“GM0033361”を付与している。したがって、ＳＮＳサーバ１０と各ゴルフ場サーバ２０との間でプレイ情報の受け渡しを行うためには、会員ＩＤと利用者ＩＤとの不整合を解消する必要がある。このためＳＮＳサーバ１０は、プレイ情報の受け渡しを行うゴルフ場サーバ２０との間でプロフィール情報（個人情報）を用いたプロフィールマッチングを行う。

【0047】

例えば、図７に示したプレイ情報管理ＤＢ１５３において、レコード番号が“１”のプレイ情報は、会員ＩＤが“M00000001”の会員が、ゴルフ場ＩＤが“G00001”のゴルフ場Ｇでゴルフをプレイしたときのプレイ日やスコアを示す情報である。このプレイ情報をゴルフ場ＩＤが“G00001”のゴルフ場サーバ２０（例えばゴルフ場サーバ２０_１）に送信する場合、ＳＮＳサーバ１０は、会員ＩＤが“M00000001”の会員に対してゴルフ場サーバ２０_１が付与した利用者ＩＤを特定する必要がある。このため詳細については後述するが、ＳＮＳサーバ１０は、ゴルフ場サーバ２０_１にアクセスし、会員ＩＤが“M00000001”の会員の個人情報（例えば氏名や電話番号等）を用いたプロフィールマッチングを行い、この会員の利用者ＩＤが“001612”であることを特定する。また、ＳＮＳサーバ１０は、プロフィールマッチングによって特定した利用者ＩＤ“001612”を、会員ＩＤ“M00000001”およびゴルフ場ＩＤ“G00001”と関連付けて利用者ＩＤ登録ＤＢ１５４に登録する（図８のレコード番号“１”）。

【0048】

このように利用者ＩＤ登録ＤＢ１５４には、プロフィールマッチングによって特定された利用者ＩＤが、対応する会員ＩＤおよびゴルフ場ＩＤと関連付けて登録される。なお、同じ会員であっても利用者ＩＤはゴルフ場サーバ２０毎に異なるので、プロフィールマッチングで特定された利用者ＩＤは、会員ＩＤおよびゴルフ場ＩＤの組と関連付けて利用者ＩＤ登録ＤＢ１５４に登録しておく必要がある。

【0049】

図９は、スマートフォン５０において実行されるラウンド前処理の流れを示すフローチャートである。ＳＮＳサーバ１０の会員は、ＳＮＳサーバ１０の掲示板機能等を利用して一緒にゴルフをプレイするメンバーを募ることができる。また、一緒にゴルフをプレイする会員のうちいずれか１人（代表者）がスマートフォン５０を携帯してゴルフをプレイすることになるが、代表者は、例えば、プレイ日の当日にゴルフ場Ｇに到着すると、プレイを開始する前にスマートフォン５０を操作してゴルフナビアプリ５１を起動し、ラウンド前処理の実行を指示する。

【0050】

ラウンド前処理が開始されると、まず、スマートフォン５０は、プレイするゴルフ場Ｇの選択処理を行う（ステップＳ１０１）。例えば、スマートフォン５０は、ゴルフ場Ｇの一覧リストを画面に表示し、その中から代表者にゴルフ場Ｇを選択させることができる。また、スマートフォン５０は、ＧＰＳ機能を利用して測位した現在位置からゴルフ場Ｇを特定し、特定したゴルフ場Ｇの名称を画面に表示して代表者に確認を求めてもよい。また、スマートフォン５０は、プレイするゴルフ場Ｇの名称を代表者に直接入力させてもよい。なお、ゴルフナビアプリ５１は、ゴルフ場Ｇ毎に、ゴルフ場ＩＤとゴルフ場名とゴルフ場Ｇの位置情報とを関連付けて記録したデータベースを有しており、スマートフォン５０は、プレイするゴルフ場Ｇが選択されると、このデータベースを参照して対応するゴルフ場ＩＤを特定する。

【0051】

次に、スマートフォン５０は、プレイ日の入力処理を行う（ステップＳ１０２）。例えば、スマートフォン５０は、プレイ日（年月日）を代表者に直接入力させてもよいし、カレンダー機能を利用して現在日の情報を取得し、これをプレイ日としてもよい。なお、スマートフォン５０は、プレイの開始を指示するプレイ開始ボタンを画面に表示し、プレイ開始ボタンがタッチ操作されると、カレンダー機能を利用して現在日の情報を取得し、これをプレイ日としてもよい。また、同じゴルフ場Ｇで１日に複数回ラウンドすることもあるので、プレイ日の代わりにプレイ開始時刻を含むプレイ日時情報（年月日時分）を使用してもよい。

【0052】

次に、スマートフォン５０は、同伴競技者の選択処理を行う（ステップＳ１０３）。一緒にゴルフをプレイするメンバーが全てＳＮＳサーバ１０の会員である場合、同伴競技者は、ＳＮＳサーバ１０において代表者のアドレス帳（例えば、お友達リストやゴルフ仲間リスト）に登録されていることが多い。したがって、スマートフォン５０は、ＳＮＳサーバ１０にログインして代表者のアドレス帳を画面に表示し、その中から代表者に同伴競技者を選択させる。例えば、代表者によって３人の同伴競技者が選択された場合、ＳＮＳサーバ１０は、プロフィール管理ＤＢ１５１（図５）を参照して、代表者と同伴競技者の計４人の会員の会員ＩＤおよび氏名を特定し、特定した情報をスマートフォン５０に送信する。なお、代表者や同伴競技者の情報として、会員ＩＤや氏名の他に顔写真の画像データを取得してもよい。

【0053】

次に、スマートフォン５０は、プレイ情報記録テーブルの作成処理を行う（ステップＳ１０４）。ここでは、ステップＳ１０１〜Ｓ１０３で得られた情報を用いて、例えば図１０に示すプレイ情報記録テーブルＴＢＬ１を作成する。同図に示すようにプレイ情報記録テーブルＴＢＬ１には、一緒にゴルフをプレイする各会員のプレイ情報（プレイ日およびスコア）が、ゴルフ場名、ゴルフ場ＩＤ、会員ＩＤおよび氏名と関連付けて記録される。なお、図１０には、スコアの項目データが既に記録されているプレイ情報記録テーブルＴＢＬ１を例示しているが、ステップＳ１０４でプレイ情報記録テーブルＴＢＬ１を作成している段階では、スコアの項目データは未登録である。また、図１０に示すプレイ情報記録テーブルＴＢＬ１において、「ゴルフ場名」および「氏名」の項目はなくてもよい。例えば、プレイ情報記録テーブルＴＢＬ１に「ゴルフ場名」が記憶されていなくても「ゴルフ場ＩＤ」が記憶されていれば、プレイ情報記録テーブルＴＢＬ１がアップロードされたＳＮＳサーバ１０では、ゴルフ場管理ＤＢ１５２を参照して対応する「ゴルフ場名」を取得することができる。同様に、プレイ情報記録テーブルＴＢＬ１に「氏名」が記憶されていなくても「会員ＩＤ」が記憶されていれば、ＳＮＳサーバ１０は、プロフィール管理ＤＢ１５１を参照して対応する「氏名」を取得することができる。

【0054】

以上説明したラウンド前処理は、プレイ日に限らず、プレイ日の前日等に行うことが可能である。また、ラウンド前処理を実行する場所もゴルフ場Ｇに限らない。例えば、自宅やゴルフ場Ｇに向う車中等でラウンド前処理を行ってもよい。また、一緒にゴルフをプレイするメンバーが全てＳＮＳサーバ１０の会員である必要もない。

【0055】

ラウンド前処理を行った後、ゴルフのプレイを開始すると、代表者は、スマートフォン５０を携帯してコースを回り、１ホール毎に自分と各同伴競技者のスコアをスマートフォン５０に入力する。入力されたスコアは、プレイ情報記録テーブルＴＢＬ１に記録される。また、代表者は、ゴルフのプレイを終えると、スマートフォン５０を操作してプレイ情報記録テーブルＴＢＬ１に記録された各会員のプレイ情報をＳＮＳサーバ１０にアップロードする。アップロードの際には、例えば、図１０に示したプレイ情報記録テーブルＴＢＬ１のうち、ゴルフ場名と氏名を除く各項目のデータが送信される。また、アップロードされるデータには、図１０に示したプレイ情報記録テーブルＴＢＬ１の場合であれば、このプレイ情報記録テーブルＴＢＬ１に記録されている４人の会員が一緒にゴルフをプレイしたメンバーであることを示す同伴ラウンド情報が付与される。

【0056】

ＳＮＳサーバ１０のＣＰＵ１１０は、スマートフォン５０からアップロードされたデータを通信ＩＦ１４０を介して受信すると、受信したデータをプレイ情報管理ＤＢ１５３（図７）に登録する。この際、ＣＰＵ１１０は、アップロードされたデータに同伴ラウンド情報が付与されている場合は、ラウンドＩＤを発行し、発行したラウンドＩＤを、受信した各会員のプレイ情報と関連付けてプレイ情報管理ＤＢ１５３に登録する。例えば、図１０に示したプレイ情報記録テーブルＴＢＬ１に記録されているデータをアップロードすると、プレイ情報管理ＤＢ１５３には、図７のレコード番号“１”〜“４”に示すようにデータが登録される。

【0057】

なお、プレイ情報は、ラウンド後に一括してアップロードするのではなく、１ホール終了毎に逐次アップロードしてもよい。また、ラウンドＩＤは、スマートフォン５０で発行することも可能である。この場合、スマートフォン５０は、例えば、電話番号やメールアドレス等、スマートフォン５０毎に固有の端末ＩＤと、タイムスタンプとを組み合わせてラウンドＩＤを生成し、生成したラウンドＩＤを、アップロードするデータと共にＳＮＳサーバ１０に送信する。

【0058】

また、例えば、一緒にゴルフをプレイする４人の会員の全てがスマートフォン５０を携帯し、各々自分のプレイ情報のみを自身のスマートフォン５０に入力してＳＮＳサーバ１０にアップロードする態様が考えられる。この場合、各会員が前述したラウンド前処理で、ゴルフ場Ｇとプレイ日と同伴競技者の情報を設定していれば、ＳＮＳサーバ１０では、４人の会員が異なるタイミングで各々自分のプレイ情報のみを自身のスマートフォン５０からアップロードした場合であっても、ゴルフ場Ｇとプレイ日と同伴競技者の情報に基づいて、これら４人の会員のプレイ情報に対し、同一のラウンドＩＤを付与してプレイ情報管理ＤＢ１５３に登録することができる。

【0059】

図１１は、閲覧処理の流れを例示するシーケンスチャートである。
会員は、スマートフォン５０を操作してＳＮＳサーバ１０にログインし、自身のマイページで自分や同伴競技者のスコア等を閲覧することができる。例えば、会員がスマートフォン５０を操作してマイページのうちゴルフのスコアを閲覧するスコア閲覧ページに移行すると、スマートフォン５０は、この会員の会員ＩＤを含む閲覧要求をＳＮＳサーバ１０に送信する（ステップＳ２０１）。例えば、会員ＩＤとして“M00000001”が付与された会員がスマートフォン５０を操作してスコア閲覧ページに移行すると、スマートフォン５０は、会員ＩＤ“M00000001”を含む閲覧要求をＳＮＳサーバ１０に送信する。

【0060】

ＳＮＳサーバ１０のＣＰＵ１１０は、スマートフォン５０から閲覧要求を受信すると、受信した閲覧要求に含まれる会員ＩＤを検索キーとしてプレイ情報管理ＤＢ１５３（図７）を検索し、該当する１以上のレコードデータを特定する（ステップＳ２０２）。ここで特定されるのは、閲覧を要求した会員のレコードデータである。例えば、ＣＰＵ１１０は、受信した閲覧要求に会員ＩＤ“M00000001”が含まれていた場合、会員ＩＤ“M00000001”を検索キーとして図７に示したプレイ情報管理ＤＢ１５３を検索し、レコード番号が“１”のレコードデータを特定する。

【0061】

次に、ＣＰＵ１１０は、特定したレコードデータ毎に、レコードデータに含まれるラウンドＩＤを有する他のレコードデータを特定する（ステップＳ２０３）。ここで特定されるのは、同伴競技者のレコードデータである。例えば、上述したステップＳ２０２で特定したレコードデータが図７に示したプレイ情報管理ＤＢ１５３のレコード番号“１”であった場合、このレコードデータに含まれるラウンドＩＤは“R00000001”である。したがって、ＣＰＵ１１０は、ラウンドＩＤ“R00000001”を有する他のレコードデータとして、プレイ情報管理ＤＢ１５３（図７）の中からレコード番号が“２”〜“４”の３つのレコードデータを特定する。なお、ステップＳ２０２で特定したレコードデータが複数ある場合は、特定したレコードデータ毎に同伴競技者のレコードデータが特定される。

【0062】

次に、ＣＰＵ１１０は、閲覧用データを取得する（ステップＳ２０４）。例えば、ＣＰＵ１１０は、閲覧用データとして、ステップＳ２０２，Ｓ２０３で特定した各レコードデータのうち会員ＩＤ以外の項目データを取得する。また、ＣＰＵ１１０は、閲覧用データとして、閲覧を要求した会員とその同伴競技者の氏名や顔写真の画像データをプロフィール管理ＤＢ１５１（図５）から取得する。この後、ＣＰＵ１１０は、ステップＳ２０４で取得した閲覧用データをスマートフォン５０に返信する（ステップＳ２０５）。

【0063】

スマートフォン５０は、ＳＮＳサーバ１０から閲覧用データを受信すると、受信した閲覧用データに基づいて、閲覧を要求した会員とその同伴競技者のスコア一覧を画面に表示する（ステップＳ２０６）。なお、閲覧用データには、ゴルフ場名ではなくゴルフ場ＩＤが含まれているが、前述したようにゴルフナビアプリ５１は、ゴルフ場ＩＤとゴルフ場名との対応関係を記録したデータベースを有しているので、スマートフォン５０では、このデータベースを参照することで、ゴルフ場ＩＤに対応するゴルフ場名を特定することができる。勿論、ＳＮＳサーバ１０は、ゴルフ場ＩＤの代わりにゴルフ場名を閲覧用データに含めてスマートフォン５０に送信することもできる。この場合、ＳＮＳサーバ１０は、ゴルフ場ＩＤに対応するゴルフ場名をゴルフ場管理ＤＢ１５２（図６）から取得すればよい。また、閲覧用データにはラウンドＩＤが含まれているが、ラウンドＩＤは、閲覧を要求した会員のスコアが複数あった場合に、個々のスコア毎に同伴競技者とそのスコアを特定するために用いられる。

【0064】

図１２は、スマートフォン５０の画面表示例を示す図である。
同図に示すように、会員は、自身のスコア閲覧ページで自分と同伴競技者のスコアの履歴を閲覧することができる。また、スコア一覧には、ゴルフ場名やプレイ日の情報も表示される。なお、同図において“ＡＰ”はアゲインストパーである。また、同図においてアンダーラインはリンクを示す。例えば、同図において“Ａカントリークラブ”の部分をタッチ操作すると、“Ａカントリークラブ”のみについての“鈴木太朗”のスコア一覧を表示することができる。また、同図において“佐藤一郎”のＡＰの項目データ“Ｅ”の部分をタッチ操作すると、“佐藤一郎”についてホール毎のスコア（１８ホール分）を表示することができる。また、同図において“高橋花子”の部分をタッチ操作すると、“高橋花子”のスコア閲覧ページに移行し、“高橋花子”のスコア一覧を閲覧することができる。

【0065】

このようにＳＮＳサーバ１０では、自分のスコアだけでなく同伴競技者のスコアも閲覧することができる。また、ＳＮＳサーバ１０では、同伴競技者以外の他の会員のスコアも閲覧することが可能である。但し、会員は、自分のスコアを誰が閲覧してもよいか、閲覧を許可する相手（自分のスコアの公開範囲）を任意に設定することができる。例えば、会員は、自分のスコアの公開範囲を、「ＳＮＳサーバ１０の全会員」、「一緒にゴルフをプレイした会員」、「アドレス帳に友達として登録している会員」、「アドレス帳にゴルフ仲間として登録している会員」、「自分のみ（非公開）」のいずれか設定することができる。なお、スコアの閲覧を許可した場合は、ゴルフ場名やプレイ日の情報もスコアと共に公開される。また、スコア毎に公開範囲や非公開を設定することや、「同伴競技者の個人情報やスコアは公開しない」、「プレイ日の情報は公開しない」、「同伴競技者として一緒にゴルフをプレイした会員のスコア一覧に自分のスコア等が公開されることは許可するが、自分のスコア一覧を他人が閲覧することは禁止する」等といった設定を行うことも可能である。

【0066】

例えば、“高橋花子”が自分のスコアの公開範囲を「同伴競技者として一緒にゴルフをプレイした会員のスコア一覧に自分のスコア等が公開されることは許可するが、自分のスコア一覧を他人が閲覧することは禁止する」に設定していた場合、図１２において“高橋花子”の部分をタッチ操作しても、“高橋花子”のスコア一覧は表示されず、閲覧が禁止されている旨のメッセージが表示される。なお、以上の閲覧処理では、自分のスコアを同伴競技者のスコアと共に表示する場合について説明したが、自分のスコアのみの一覧を表示することも可能である。

【0067】

図１３は、プレイ情報の送信処理の流れを例示するシーケンスチャートである。
ＳＮＳサーバ１０は、プレイ情報管理ＤＢ１５３（図７）に登録されている会員のプレイ情報（スコアやプレイ日）を、対応するゴルフ場サーバ２０に送信する機能を備える。なお、プレイ情報を対応するゴルフ場サーバ２０に送信するとは、例えば、ゴルフ場Ｇ_１でゴルフをプレイした結果得られたプレイ情報であればゴルフ場サーバ２０_１に送信し、ゴルフ場Ｇ_２でゴルフをプレイした結果得られたプレイ情報であればゴルフ場サーバ２０_２に送信することを意味する。

【0068】

例えば、図１４（Ａ）に示すように、スコア一覧をスマートフォン５０の画面に表示した際に、自分のスコアの右脇には、このプレイ情報をまだゴルフ場サーバ２０に送信していない場合は、プレイ情報をゴルフ場サーバ２０に送信することを指示する表示ボタンＢＮ１が表示される。会員は、プレイ情報をゴルフ場サーバ２０に送信する場合、表示ボタンＢＮ１をタッチ操作する。なお、プレイ情報が既に送信済みの場合は、図１４（Ｂ）に示すように送信済みであることを示す表示ボタンＢＮ２が表示される。

【0069】

スマートフォン５０は、表示ボタンＢＮ１がタッチ操作されたことを検知すると、送信するプレイ情報を指定するプレイ情報指定データを含む送信要求をＳＮＳサーバ１０に送信する（ステップＳ３０１）。なお、プレイ情報指定データは、例えば、会員ＩＤとプレイ日で構成されてもよいし、会員ＩＤとプレイ日とスコアで構成されてもよいし、会員ＩＤとゴルフ場ＩＤとプレイ日とスコアで構成されもよい。また、プレイ情報指定データは、プレイ情報管理ＤＢ１５３におけるレコード番号を指定する情報であってもよい。

【0070】

ＳＮＳサーバ１０のＣＰＵ１１０は、スマートフォン５０から送信要求を受信すると、プレイ情報管理ＤＢ１５３（図７）を参照し、受信した送信要求に含まれるプレイ情報指定データで指定されるプレイ情報と同じレコードに含まれる会員ＩＤおよびゴルフ場ＩＤを特定する（ステップＳ３０２）。例えば、プレイ情報指定データで指定されるプレイ情報が図７のレコード番号“１”に含まれるプレイ情報であった場合、ＣＰＵ１１０は、会員ＩＤ“M00000001”およびゴルフ場ＩＤ“G00001”を特定する。次に、ＣＰＵ１１０は、ゴルフ場管理ＤＢ１５２（図６）を参照し、ステップＳ３０２で特定したゴルフ場ＩＤに対応するアクセス方法（ＵＲＬおよびＡＰＩ）を特定する（ステップＳ３０３）。例えば、ステップＳ３０２で特定したゴルフ場ＩＤが“G00001”であった場合、ＣＰＵ１１０は、“Ａカントリークラブ”のゴルフ場サーバ２０へのアクセス方法を特定する。

【0071】

この後、ＣＰＵ１１０は、利用者ＩＤが取得済みであるか否かを判定する（ステップＳ３０４）。ここでは、利用者ＩＤ登録ＤＢ１５４を参照し、ステップＳ３０２で特定した会員ＩＤおよびゴルフ場ＩＤの組と関連付けて利用者ＩＤが登録されているか否かを調べることで、利用者ＩＤが登録されていれば利用者ＩＤが取得済みであると判定し（ステップＳ３０４：ＹＥＳ）、利用者ＩＤが登録されていなければ利用者ＩＤが取得済みでないと判定する（ステップＳ３０４：ＮＯ）。例えば、ステップＳ３０２で会員ＩＤ“M00000001”およびゴルフ場ＩＤ“G00001”が特定された場合、図８に示した利用者ＩＤ登録ＤＢ１５４には、会員ＩＤ“M00000001”およびゴルフ場ＩＤ“G00001”の組と関連付けて利用者ＩＤ“001612”が登録されているので（レコード番号“１”）、ステップＳ３０４では利用者ＩＤが取得済みであると判定される。

【0072】

ＣＰＵ１１０は、ステップＳ３０４の判定結果がＹＥＳの場合、ステップＳ３０８に進む。一方、ステップＳ３０４の判定結果がＮＯの場合、ＣＰＵ１１０は、プロフィール管理ＤＢ１５１（図５）を参照し、ステップＳ３０２で特定した会員ＩＤに対応するプロフィール情報の一部または全部を取得する（ステップＳ３０５）。例えば、ステップＳ３０２で特定した会員ＩＤが“M00000001”であった場合、ＣＰＵ１１０は、図５に示したプロフィール管理ＤＢ１５１から、プロフィール情報として、“鈴木太朗（氏名）”、“1969/05/23（生年月日）”および“090-1111-1111（電話番号）”のいずれか1以上を取得する。

【0073】

次に、ＣＰＵ１１０は、プレイ情報の送信先となるゴルフ場サーバ２０との間でプロフィールマッチングを行う（ステップＳ３０６）。ＣＰＵ１１０は、まず、ステップＳ３０３で特定したＵＲＬが示すゴルフ場サーバ２０にアクセスする。また、ＣＰＵ１１０は、ステップＳ３０３で特定したＡＰＩを使用してゴルフ場サーバ２０との通信を行う。そして、ＣＰＵ１１０は、ステップＳ３０５で取得したプロフィール情報をゴルフ場サーバ２０に通知し、通知したプロフィール情報に一致する利用者ＩＤを問い合わせる。なお、全てのゴルフ場サーバ２０との通信を行うために必要となるＡＰＩの種類が少ない場合は、ゴルフ場管理ＤＢ１５２（図６）に各ＡＰＩを登録するのではなく、ＳＮＳサーバ１０用の制御プログラム中に各ＡＰＩをサブルーチンやモジュールとして組み込んでもよい。

【0074】

ゴルフ場サーバ２０は、ＳＮＳサーバ１０からプロフィール情報を受信すると、利用者管理ＤＢ２１（図２）を参照し、受信したプロフィール情報（個人情報）に一致する利用者ＩＤを特定する。また、ゴルフ場サーバ２０は、特定した利用者ＩＤをＳＮＳサーバ１０に返信する。例えば、プレイ情報の送信先となる、ゴルフ場ＩＤが“G00001”のゴルフ場サーバ２０（例えばゴルフ場サーバ２０_１）は、ＳＮＳサーバ１０から受信したプロフィール情報が“鈴木太朗”であった場合、図２に示した利用者管理ＤＢ２１_１を参照して“鈴木太朗”に一致する利用者ＩＤ“001612”を取得し、これをＳＮＳサーバ１０に返信する。これによりＳＮＳサーバ１０は、会員ＩＤが“M00000001”の会員（鈴木太朗）に対してゴルフ場サーバ２０_１が付与した利用者ＩＤ“001612”を取得することができる。

【0075】

なお、プロフィールマッチングで使用する個人情報は、例えば、氏名，自宅の住所，メールアドレス，所有するスマートフォン５０の電話番号，自宅の電話番号のいずれかを単独で用いることができる。但し、氏名の場合は、同姓同名の人がいる可能性がある。また、自宅の住所や自宅の電話番号の場合は、家族内に同じゴルフ場Ｇの利用者が複数存在する可能がある。このため氏名，自宅の住所，自宅の電話番号のいずれかを単独で使用した場合、プロフィールマッチングで利用者ＩＤを１つに絞りきれないことがある。したがって、プロフィール情報（個人情報）のうちいずれか１つを単独で使用する場合は、メールアドレスやスマートフォン５０の電話番号を用いることがマッチングの精度を高める上で好適である。

【0076】

但し、この場合も、ゴルフ場サーバ２０の中には、昔から利用者管理ＤＢ２１が更新されておらず、利用者の個人情報として、メールアドレスやスマートフォン５０の電話番号が登録されていない場合がある。このためメールアドレスやスマートフォン５０の電話番号を単独で使用した場合、プロフィールマッチングで利用者ＩＤを特定できないことがある。以上のようなことから、例えば、メールアドレスやスマートフォン５０の電話番号によるプロフィールマッチングで利用者ＩＤが特定できなかった場合は、氏名や自宅の住所や自宅の電話番号によるプロフィールマッチングを行うようにしてもよい。また、氏名や自宅の住所や自宅の電話番号によるプロフィールマッチングで利用者ＩＤを１つに絞りきれなかった場合は、さらに性別，年齢，生年月日，職業，勤務先等の情報を適宜組み合わせてプロフィールマッチングを行うようにしてもよい。このように氏名，自宅の住所，メールアドレス，所有するスマートフォン５０の電話番号，自宅の電話番号，性別，年齢，生年月日，職業，勤務先等のうちの２以上を適宜組み合わせてプロフィールマッチングを行うことで、マッチングの精度を高めることができる。なお、プロフィールマッチングで用いる利用者の個人情報の組み合わせを利用者自身が任意に設定できるようにしてもよい。

【0077】

次に、ＣＰＵ１１０は、プロフィールマッチングで特定した利用者ＩＤを、ステップＳ３０２で特定した会員ＩＤおよびゴルフ場ＩＤの組と関連付けて利用者ＩＤ登録ＤＢ１５４に登録する（ステップＳ３０７）。例えば、プロフィールマッチングで特定した利用者ＩＤが“001612”であって、ステップＳ３０２で会員ＩＤ“M00000001”およびゴルフ場ＩＤ“G00001”を特定した場合、ＣＰＵ１１０は、利用者ＩＤ“001612”を、会員ＩＤ“M00000001”およびゴルフ場ＩＤ“G00001”の組と関連付けて利用者ＩＤ登録ＤＢ１５４に登録する（図８のレコード番号“１”）。

【0078】

また、上述したステップＳ３０４の判定結果がＹＥＳの場合、ＣＰＵ１１０は、利用者ＩＤ登録ＤＢ１５４を参照し、ステップＳ３０２で特定した会員ＩＤおよびゴルフ場ＩＤの組と関連付けて登録されている利用者ＩＤを取得して（ステップＳ３０８）、ステップＳ３０９に進む。ここで、会員が過去に一度でもプレイ情報を送信したことのあるゴルフ場サーバ２０については、ステップＳ３０４の判定結果がＹＥＳとなって、プロフィールマッチングを含むステップＳ３０５〜Ｓ３０７までの処理を実行せずとも、利用者ＩＤ登録ＤＢ１５４から利用者ＩＤを取得することができる。よって、プレイ情報の送信処理を簡素化し、処理時間を短縮することができる。

【0079】

この後、ＣＰＵ１１０は、ステップＳ３０４の判定結果がＮＯの場合は、ステップＳ３０６で行われたプロフィールマッチングで特定した利用者ＩＤと、プレイ情報指定データで指定されるプレイ情報（スコアおよびプレイ日）とを通信ＩＦ１４０を介してゴルフ場サーバ２０に送信し、ステップＳ３０４の判定結果がＹＥＳの場合は、ステップＳ３０８で利用者ＩＤ登録ＤＢ１５４から取得した利用者ＩＤと、プレイ情報指定データで指定されるプレイ情報とをゴルフ場サーバ２０に送信する（ステップＳ３０９）。なお、ステップＳ３０９においてＳＮＳサーバ１０は、ゴルフ場サーバ２０に対して利用者ＩＤとプレイ情報を同時（一緒）に送信しなくてもよい。例えば、ＳＮＳサーバ１０は、まず、プレイ情報を送信し、ゴルフ場サーバ２０から利用者についての問い合わせがあると、この問い合わせに応じて利用者ＩＤを送信してもよい。

【0080】

ゴルフ場サーバ２０は、ＳＮＳサーバ１０から利用者ＩＤおよびプレイ情報を受信すると、受信した利用者ＩＤおよびプレイ情報を関連付けてプレイ情報管理ＤＢ２２（図３）に登録する（ステップＳ３１０）。例えば、スマートフォン５０からＳＮＳサーバ１０に対して、図７に示したプレイ情報管理ＤＢ１５３のうちレコード番号が“１”のレコードデータに含まれるプレイ情報、すなわち会員ＩＤが“M00000001”の会員のプレイ情報（スコア“71”およびプレイ日“20011/10/09”）の送信が指示された場合、このプレイ情報と、プロフィールマッチングによって取得された利用者ＩＤ“001612”とがゴルフ場ＩＤ“G00001”のゴルフ場サーバ２０_１に送信され、図３に示すプレイ情報管理ＤＢ２２_１に登録される。

【0081】

ここで、プロフィール管理ＤＢ１５１（図５）と利用者管理ＤＢ２１（図２）を参照すると明らかとなるように、会員ＩＤ“M00000001”と利用者ＩＤ“001612”は、いずれも“鈴木太朗”に対して付与されたものである。したがって、ＳＮＳサーバ１０で管理している“鈴木太朗”のプレイ情報を、ゴルフ場サーバ２０_１でも“鈴木太朗”のプレイ情報としてプレイ情報管理ＤＢ２２_１に登録することができる。なお、ゴルフ場Ｇの利用予約や、利用者がプレイ日の当日にゴルフ場Ｇのフロントで受付を済ましたことに応じて、既にプレイ情報管理ＤＢ２２にスコアを除く利用者ＩＤおよびプレイ日が登録されている場合は、未登録になっているスコアの項目データのみが登録される。

【0082】

この後、ゴルフ場サーバ２０は、プレイ情報の登録が完了したことを示す完了通知をＳＮＳサーバ１０に送信する（ステップＳ３１１）。ＳＮＳサーバ１０は、ゴルフ場サーバ２０から完了通知を受信すると、プレイ情報の送信処理が完了したことを示す完了通知をスマートフォン５０に送信する（ステップＳ３１２）。

【0083】

なお、プロフィールマッチングは、以上説明したプレイ情報の送信処理とは別個の処理として任意のタイミングで行うことができる。この場合、例えば、図１５（Ａ）に示すように、スコア一覧をスマートフォン５０の画面に表示した際に、自分のスコアの右脇には、プレイ情報の送信先となるゴルフ場サーバ２０から利用者ＩＤを取得していない場合は、プロフィールマッチングの実行を指示する表示ボタンＢＮ３が表示される。会員は、プロフィールマッチングを行う場合、表示ボタンＢＮ３をタッチ操作する。プレイ情報の送信先となるゴルフ場サーバ２０から既に利用者ＩＤを取得済みの場合は、図１５（Ｂ）に示すようにマッチング済みであることを示す表示ボタンＢＮ４が表示される。

【0084】

また、プロフィールマッチングや、ゴルフ場サーバ２０に対してプレイ情報を送信する処理は、基本的に会員毎に行われる処理であり、例えば、会員Ａが会員Ｂのプロフィールマッチングを行うことや、会員Ａが会員Ｂのプレイ情報の送信を指示することは基本的に禁止されている。しかしながら、他の会員のプレイ情報の送信を指示することについては、これを禁止せずに許可する構成としてもよい。この場合、例えば、一緒にゴルフをプレイしたメンバー全員が既にプロフィールマッチングを済ませていれば、メンバーの代表者がメンバー全員のプレイ情報をまとめて送信することができる。例えば、図１５（Ｃ）に示すように、スコア一覧をスマートフォン５０の画面に表示した際に、一緒にゴルフをプレイしたメンバー全員が既にプロフィールマッチングを済ませている場合は、メンバー全員のスコアの右脇に、全員のプレイ情報をゴルフ場サーバに送信することを指示する表示ボタンＢＮ５が表示される。メンバーの代表者は、全員のプレイ情報をゴルフ場サーバ２０に送信する場合、表示ボタンＢＮ５をタッチ操作する。

【0085】

なお、他の会員によって自分のプレイ情報の送信が指示されることを禁止する設定を設けてもよい。この場合、メンバーの代表者が表示ボタンＢＮ５をタッチ操作すると、禁止設定を有効にしていないメンバーのプレイ情報のみがゴルフ場サーバ２０に送信され、禁止設定を有効にしているメンバーのプレイ情報については、ゴルフ場サーバ２０への送信がキャンセルされる。また、プレイ情報の送信処理を終えた後、例えば「会員Ａさんについては送信禁止設定によりゴルフ場サーバ２０にプレイ情報を送信することができませんでした」等といったメッセージが表示される。

【0086】

図１６は、プレイ情報の取得処理の流れを例示するシーケンスチャートである。
ＳＮＳサーバ１０は、会員の過去のプレイ情報をゴルフ場サーバ２０から取得する機能を備える。なお、以下の動作説明において、図１３に示したプレイ情報の送信処理と同様の処理を行う部分については、説明を適宜簡略化している。

【0087】

例えば、会員がスマートフォン５０を操作して、自分のプレイ情報を取得するゴルフ場Ｇをゴルフ場リストの中から選択すると、スマートフォン５０は、ゴルフ場名とゴルフ場ＩＤとの対応関係を記録したデータベースを参照し、会員が選択したゴルフ場Ｇに対応するゴルフ場ＩＤを特定する。また、スマートフォン５０は、この会員の会員ＩＤと、特定したゴルフ場ＩＤとを含む取得要求をＳＮＳサーバ１０に送信する（ステップＳ４０１）。例えば、会員ＩＤとして“M00000001”が付与された会員が自分のプレイ情報を“Ａカントリークラブ”のゴルフ場サーバ２０から取得することを指示すると、スマートフォン５０は、会員ＩＤ“M00000001”とゴルフ場ＩＤ“G00001”とを含む取得要求をＳＮＳサーバ１０に送信する。

【0088】

ＳＮＳサーバ１０のＣＰＵ１１０は、スマートフォン５０から取得要求を受信すると、ゴルフ場管理ＤＢ１５２（図６）を参照し、受信した取得要求に含まれるゴルフ場ＩＤに対応するアクセス方法（ＵＲＬおよびＡＰＩ）を特定する（ステップＳ４０２）。例えば、取得要求に含まれているゴルフ場ＩＤが“G00001”であった場合、ＣＰＵ１１０は、“Ａカントリークラブ”のゴルフ場サーバ２０へのアクセス方法を特定する。

【0089】

次に、ＣＰＵ１１０は、利用者ＩＤが取得済みであるか否かを判定する（ステップＳ４０３）。ここでは、利用者ＩＤ登録ＤＢ１５４（図８）を参照し、ステップＳ４０１で受信した取得要求に含まれる会員ＩＤおよびゴルフ場ＩＤの組と関連付けて利用者ＩＤが登録されているか否かを調べることで、利用者ＩＤが登録されていれば利用者ＩＤが取得済みであると判定し（ステップＳ４０３：ＹＥＳ）、利用者ＩＤが登録されていなければ利用者ＩＤが取得済みでないと判定する（ステップＳ４０３：ＮＯ）。例えば、取得要求に会員ＩＤ“M00000001”およびゴルフ場ＩＤ“G00001”が含まれていた場合、図８に示した利用者ＩＤ登録ＤＢ１５４には、会員ＩＤ“M00000001”およびゴルフ場ＩＤ“G00001”の組と関連付けて利用者ＩＤ“001612”が登録されているので（レコード番号“１”）、ステップＳ４０３では利用者ＩＤが取得済みであると判定される。

【0090】

ＣＰＵ１１０は、ステップＳ４０３の判定結果がＹＥＳの場合、ステップＳ４０７に進む。一方、ステップＳ４０３の判定結果がＮＯの場合、ＣＰＵ１１０は、プロフィール管理ＤＢ１５１（図５）を参照し、ステップＳ４０１で受信した取得要求に含まれる会員ＩＤに対応するプロフィール情報の一部または全部を取得する（ステップＳ４０４）。例えば、取得要求に含まれている会員ＩＤが“M00000001”であった場合、ＣＰＵ１１０は、図５に示したプロフィール管理ＤＢ１５１から、プロフィール情報として、“鈴木太朗（氏名）”、“1969/05/23（生年月日）”および“090-1111-1111（電話番号）”のいずれか1以上を取得する。

【0091】

次に、ＣＰＵ１１０は、プレイ情報の取得先となるゴルフ場サーバ２０との間でプロフィールマッチングを行う（ステップＳ４０５）。ＣＰＵ１１０は、まず、ステップＳ４０２で特定したＵＲＬが示すゴルフ場サーバ２０にアクセスする。また、ＣＰＵ１１０は、ステップＳ４０２で特定したＡＰＩを使用してゴルフ場サーバ２０との通信を行う。そして、ＣＰＵ１１０は、ステップＳ４０４で取得したプロフィール情報をゴルフ場サーバ２０に通知し、通知したプロフィール情報に一致する利用者ＩＤを問い合わせる。

【0092】

ゴルフ場サーバ２０は、ＳＮＳサーバ１０からプロフィール情報を受信すると、利用者管理ＤＢ２１（図２）を参照し、受信したプロフィール情報（個人情報）に一致する利用者ＩＤを特定する。また、ゴルフ場サーバ２０は、特定した利用者ＩＤをＳＮＳサーバ１０に返信する。例えば、プレイ情報の取得先となる、ゴルフ場ＩＤが“G00001”のゴルフ場サーバ２０（例えばゴルフ場サーバ２０_１）は、ＳＮＳサーバ１０から受信したプロフィール情報が“鈴木太朗”であった場合、図２に示した利用者管理ＤＢ２１_１を参照して“鈴木太朗”に一致する利用者ＩＤ“001612”を取得し、これをＳＮＳサーバ１０に返信する。これによりＳＮＳサーバ１０は、会員ＩＤが“M00000001”の会員（鈴木太朗）に対してゴルフ場サーバ２０_１が付与した利用者ＩＤ“001612”を取得することができる。なお、プロフィールマッチングで使用する個人情報については、上述したプレイ情報の送信処理で説明した通りである。

【0093】

次に、ＣＰＵ１１０は、プロフィールマッチングで特定した利用者ＩＤを、ステップＳ４０１で受信した取得要求に含まれる会員ＩＤおよびゴルフ場ＩＤの組と関連付けて利用者ＩＤ登録ＤＢ１５４に登録する（ステップＳ４０６）。例えば、プロフィールマッチングで特定した利用者ＩＤが“001612”であって、取得要求に会員ＩＤ“M00000001”およびゴルフ場ＩＤ“G00001”が含まれていた場合、ＣＰＵ１１０は、利用者ＩＤ“001612”を、会員ＩＤ“M00000001”およびゴルフ場ＩＤ“G00001”の組と関連付けて利用者ＩＤ登録ＤＢ１５４に登録する（図８のレコード番号“１”）。

【0094】

また、上述したステップＳ４０３の判定結果がＹＥＳの場合、ＣＰＵ１１０は、利用者ＩＤ登録ＤＢ１５４を参照し、ステップＳ４０１で受信した取得要求に含まれる会員ＩＤおよびゴルフ場ＩＤの組と関連付けて登録されている利用者ＩＤを取得する（ステップＳ４０７）。ここで、会員が過去に一度でもプレイ情報を送信または取得したことのあるゴルフ場サーバ２０については、ステップＳ４０３の判定結果がＹＥＳとなって、プロフィールマッチングを含むステップＳ４０４〜Ｓ４０６までの処理を実行せずとも、利用者ＩＤ登録ＤＢ１５４から利用者ＩＤを取得することができる。よって、プレイ情報の取得処理を簡素化し、処理時間を短縮することができる。

【0095】

この後、ＣＰＵ１１０は、ステップＳ４０３の判定結果がＮＯの場合は、ステップＳ４０５で行われたプロフィールマッチングで特定した利用者ＩＤを含む取得要求を通信ＩＦ１４０を介してゴルフ場サーバ２０に送信し、ステップＳ４０３の判定結果がＹＥＳの場合は、ステップＳ４０７で利用者ＩＤ登録ＤＢ１５４から取得した利用者ＩＤを含む取得要求をゴルフ場サーバ２０に送信する（ステップＳ４０８）。

【0096】

ゴルフ場サーバ２０は、ＳＮＳサーバ１０から取得要求を受信すると、プレイ情報管理ＤＢ２２（図３）を参照し、受信した取得要求に含まれる利用者ＩＤに対応する１以上のプレイ情報を特定する（ステップＳ４０９）。例えば、プレイ情報の取得先となる、ゴルフ場ＩＤが“G00001”のゴルフ場サーバ２０（例えばゴルフ場サーバ２０_１）は、ＳＮＳサーバ１０から受信した取得要求に含まれている利用者ＩＤが“001612”であった場合、図３に示したプレイ情報管理ＤＢ２２_１を参照して利用者ＩＤ“001612”に対応するプレイ情報（スコア“ＮＵＬＬ”およびプレイ日“20011/10/09”）を特定する。

【0097】

次に、ゴルフ場サーバ２０は、ステップＳ４０９で特定したプレイ情報をＳＮＳサーバ１０に返信する（ステップＳ４１０）。ＳＮＳサーバ１０のＣＰＵ１１０は、ゴルフ場サーバ２０からプレイ情報を受信すると、受信したプレイ情報を、ステップＳ４０１で受信した取得要求に含まれる会員ＩＤおよびゴルフ場ＩＤと関連付けてプレイ情報管理ＤＢ１５３（図７）に登録する（ステップＳ４１１）。この後、ＣＰＵ１１０は、プレイ情報の取得処理が完了したことを示す完了通知をスマートフォン５０に送信する（ステップＳ４１２）。例えば、ゴルフ場サーバ２０_１から受信したプレイ情報がスコア“ＮＵＬＬ”およびプレイ日“20011/10/09”であって、取得要求に会員ＩＤ“M00000001”およびゴルフ場ＩＤ“G00001”が含まれていた場合、ＳＮＳサーバ１０は、プレイ情報（スコア“ＮＵＬＬ”およびプレイ日“20011/10/09”）を、会員ＩＤ“M00000001”およびゴルフ場ＩＤ“G00001”と関連付けてプレイ情報管理ＤＢ１５３に登録する。

【0098】

なお、ゴルフ場サーバ２０から取得したプレイ情報は、スコアが未登録の場合もあるが、その場合でもプレイ日の情報を取得することができるので、会員が個人的に自分の過去のスコアを管理している場合は、スマートフォン５０を操作してＳＮＳサーバ１０にアクセスし、未登録のスコアを入力することが可能である。また、ＳＮＳサーバ１０のＣＰＵ１１０は、ステップＳ４１０でゴルフ場サーバ２０からプレイ情報を受信するにあたり、特にプレイ情報が複数ある場合は、既にプレイ情報管理ＤＢ１５３に登録されているプレイ情報については受信を控え、プレイ情報管理ＤＢ１５３に登録されていないプレイ情報のみを受信するようにしてもよい。この場合、ＳＮＳサーバ１０は無駄なプレイ情報の受信を行わずに済む。

【0099】

以上説明したプレイ情報の取得処理によれば、例えば、ゴルフ場サーバ２０から“鈴木太朗”のプレイ情報を取得し、これをＳＮＳサーバ１０でも“鈴木太朗”のプレイ情報としてプレイ情報管理ＤＢ１５３に登録することができる。また、会員は、必要に応じて各ゴルフ場サーバ２０から自分の過去のプレイ情報を取得してＳＮＳサーバ１０のプレイ情報管理ＤＢ１５３に登録することができるから、各地のゴルフ場Ｇでゴルフをプレイした会員のプレイ情報をＳＮＳサーバ１０で一元管理することが可能になる。

【0100】

なお、ステップＳ４０５で行われるプロフィールマッチングについても、プレイ情報の取得処理とは別個の処理として任意のタイミングで行うことができる。また、ゴルフ場サーバ２０からプレイ情報を取得する処理も、基本的に会員毎に行われる処理であり、例えば、会員Ａが会員Ｂのプレイ情報の取得を指示することは基本的に禁止されている。しかしながら、他の会員のプレイ情報の取得を指示することを禁止せずに許可する構成としてもよいし、他の会員によって自分のプレイ情報の取得が指示されることを禁止する設定を設けてもよい。

【0101】

＜２．変形例＞
本発明は上述した実施形態に限定されるものではなく、例えば以下の変形が可能である。また、以下に示す２以上の変形を適宜組み合わせることもできる。

【0102】

［変形例１］
図１３に示した送信処理でプロフィールマッチング（ステップＳ３０６）を行う場合に、個人情報に加えてプレイ日の情報を使用してもよい。前述したようにゴルフ場サーバ２０のプレイ情報管理ＤＢ２２には、ゴルフ場Ｇの利用予約等に応じて、スコアを除く利用者ＩＤおよびプレイ日が登録されることが多々ある。したがって、個人情報の他に、送信するプレイ情報に含まれるプレイ日の情報、または会員が覚えている過去のプレイ日の情報を利用してプロフィールマッチングを行うことで、マッチングの精度を高めることができる。

【0103】

この場合、ＳＮＳサーバ１０は、ステップＳ３０６でプロフィールマッチングを開始する場合に、ステップＳ３０５で取得したプロフィール情報に加え、プレイ情報指定データで指定されるプレイ日の情報、または会員がスマートフォン５０を操作して入力した過去のプレイ日の情報をゴルフ場サーバ２０に通知する。ゴルフ場サーバ２０は、ＳＮＳサーバ１０からプロフィール情報およびプレイ日の情報を受信すると、例えば、利用者管理ＤＢ２１（図２）を参照しても、受信したプロフィール情報に一致する利用者ＩＤが１つに絞りきれなかった場合に、プレイ情報管理ＤＢ２２（図３）を参照し、受信したプレイ日の情報に一致する利用者ＩＤを特定する。次に、ゴルフ場サーバ２０は、プロフィール情報に一致する複数の利用者ＩＤと、プレイ日の情報に一致する１以上の利用者ＩＤとのＡＮＤをとって利用者ＩＤを特定し、特定した利用者ＩＤをＳＮＳサーバ１０に送信する。

【0104】

なお、プロフールマッチングで使用するプレイ日の情報は、１つに限らず複数であってもよい。プレイ日の情報を複数使用した方がマッチングの精度をより高めることができる。また、図１６に示した取得処理でプロフィールマッチング（ステップＳ４０５）を行う場合についても、個人情報に加えてプレイ日の情報を使用してもよい。

【0105】

［変形例２］
図１７は、図１３に示した送信処理の変形例を示すシーケンスチャートである。
同図に示す処理は、プロフィールマッチング（図１３のステップＳ３０６）で、ゴルフ場サーバ２０がスマートフォン５０から受信したプロフィール情報（個人情報）に一致する利用者ＩＤを特定すると開始される。

【0106】

ゴルフ場サーバ２０は、まず、プロフィールマッチングによって特定した利用者ＩＤが複数あるか否かを判定する（ステップＳ５０１）。ステップＳ５０１の判定結果がＮＯの場合は、図１３に示したステップＳ３０７に移行する。また、ゴルフ場サーバ２０は、ステップＳ５０１の判定結果がＹＥＳの場合、すなわちプロフィールマッチングによって利用者ＩＤを１つに絞りきれなかった場合は、利用者管理ＤＢ２１（図２）を参照し、特定した複数の利用者ＩＤの各々に対応する個人情報（例えば、氏名，生年月日，住所，電話番号）を取得する（ステップＳ５０２）。次に、ゴルフ場サーバ２０は、特定した利用者ＩＤ毎に、利用者ＩＤと、この利用者ＩＤに対応する個人情報との組を生成する。また、ゴルフ場サーバ２０は、生成した利用者ＩＤと個人情報の組（複数）をＳＮＳサーバ１０に送信する（ステップＳ５０３）。

【0107】

ＳＮＳサーバ１０は、ゴルフ場サーバ２０から利用者ＩＤと個人情報の組（複数）を受信すると、これをＲＡＭ１３０に記憶すると共に、受信した複数人分の個人情報をスマートフォン５０に送信する（ステップＳ５０４）。スマートフォン５０は、ＳＮＳサーバ１０から個人情報（複数人分）を受信すると、受信した複数人分の個人情報を画面に表示する（ステップＳ５０５）。また、スマートフォン５０は、例えば「マッチングによって利用者ＩＤを１つに絞りきれませんでした。複数の候補が見つかりましたので選択してください」等といったメッセージを表示し、会員に対して選択を促す。これに応じて会員がスマートフォン５０を操作して画面に表示された複数人分の個人情報の中からいずれかを選択すると、スマートフォン５０は、会員が選択した個人情報を指定する選択情報をＳＮＳサーバ１０に送信する（ステップＳ５０６）。ＳＮＳサーバ１０は、スマートフォン５０から選択情報を受信すると、ＲＡＭ１３０に記憶した情報の中から、受信した選択情報が指定する個人情報と同じ組の利用者ＩＤを特定し、特定した利用者ＩＤをプロフィールマッチングによって得られた最終的な利用者ＩＤとして決定する（ステップＳ５０７）。

【0108】

以上説明したようにプロフィールマッチングによって利用者ＩＤを１つに絞りきれなかった場合に、最終的な選択を利用者に行わせるようにしてもよい。なお、本変形例の内容は、図１６に示した取得処理で行われるプロフィールマッチング（ステップＳ４０５）に対しても同様に適用可能である。

【0109】

［変形例３］
上述したプレイ情報の送信処理（図１３）では、プロフィールマッチングで特定した利用者ＩＤを、ステップＳ３０２で特定した会員ＩＤおよびゴルフ場ＩＤの組と関連付けて利用者ＩＤ登録ＤＢ１５４（図８）に登録する場合について説明したが（ステップＳ３０７）、ステップＳ３０４，Ｓ３０７，Ｓ３０８を削除すると共に利用者ＩＤ登録ＤＢ１５４（図８）を備えない構成とし、ＳＮＳサーバ１０は、プレイ情報の送信が指示される都度、プロフィールマッチングを行うようにしてもよい。これはプレイ情報の取得処理（図１６）についても同様である。すなわち、ステップＳ４０３，Ｓ４０６，Ｓ４０７を削除すると共に利用者ＩＤ登録ＤＢ１５４（図８）を備えない構成とし、ＳＮＳサーバ１０は、プレイ情報の取得が指示される都度、プロフィールマッチングを行うようにしてもよい。

【0110】

［変形例４］
ＳＮＳサーバ１０や各ゴルフ場サーバ２０で管理しているプレイ情報には、プレイ日およびスコアの他、ハンディキャップ、天候、風速、一緒にラウンドしたメンバーに関する情報等が含まれてもよい。また、プレイ情報は、プレイ日を含まずスコアのみであってもよい。また、スコアには、ホール毎のパット数、全ホールでの平均パット数、一緒にラウンドしたメンバー間での順位等の情報が含まれてもよい。ＳＮＳサーバ１０で管理しているプレイ情報と、各ゴルフ場サーバ２０で管理しているプレイ情報は、データ構成が異なってもよい。例えば、ＳＮＳサーバ１０で管理しているプレイ情報は、プレイ日、スコアおよび天候で構成される一方、各ゴルフ場サーバ２０で管理しているプレイ情報は、プレイ日およびスコアで構成されてもよい。この場合、ＳＮＳサーバ１０からゴルフ場サーバ２０にプレイ情報を送信するときは、天候を除くプレイ日およびスコアがＳＮＳサーバ１０から送信される。また、ゴルフ場サーバ２０からプレイ情報を取得するときは、プレイ日およびスコアがゴルフ場サーバ２０から取得され、天候の項目は“ＮＵＬＬ”となる。また、例えば、プレーンテキストフォーマットとリッチテキストフォーマット等、ＳＮＳサーバ１０と各ゴルフ場サーバ２０とでプレイ情報のデータ記録形式が異なってもよい。この場合、ＳＮＳサーバ１０にデータ記録形式を変換する機能を持たせればよい。

【0111】

［変形例５］
利用者管理ＤＢ２１には、利用者の個人情報として、例えば、氏名，生年月日，住所，電話番号，メールアドレスのうち少なくともいずれか１項目が設けられていればよい。同様にプロフィール管理ＤＢ１５１についても、会員のプロフィール情報として、例えば、氏名，生年月日，住所，電話番号，メールアドレスのうち少なくともいずれか１項目が設けられていればよい。但し、プロフィールマッチングを行うので、利用者管理ＤＢ２１に格納される個人情報と、プロフィール管理ＤＢ１５１に格納されるプロフィール情報とは、少なくとも１項目以上が同じである必要がある。

【0112】

［変形例６］
プロフィール管理ＤＢ１５１は、ＳＮＳサーバとは別に設けられた会員管理サーバに記憶されていてもよい。この場合、ＳＮＳサーバ１０は、会員管理サーバに問い合わせを行なってプロフィールマッチングの対象となる会員のプロフィール情報を取得する。また、プレイ情報管理ＤＢ１５３においてラウンドＩＤの項目はなくてもよい。

【0113】

［変形例７］
プロフィール管理ＤＢ１５１、ゴルフ場管理ＤＢ１５２、プレイ情報管理ＤＢ１５３および利用者ＩＤ登録ＤＢ１５４は、ＳＮＳサーバ１０とは別の装置（例えば情報蓄積サーバ）に記憶されていてもよい。この場合、ＳＮＳサーバ１０は、必要に応じて情報蓄積サーバにアクセスし、情報の取得や新たな情報の蓄積を行う。同様に利用者管理ＤＢ２１およびプレイ情報管理ＤＢ２２についても、ゴルフ場サーバ２０とは別の装置（例えば情報蓄積サーバ）に記憶され、ゴルフ場サーバ２０は、必要に応じて情報蓄積サーバにアクセスし、情報の取得や新たな情報の蓄積を行う構成であってもよい。また、ゴルフ場サーバ２０は、利用者管理ＤＢ２１を記憶する利用者管理サーバと、プレイ情報管理ＤＢ２２を記憶するプレイ情報管理サーバとで構成されてもよい。

【0114】

［変形例８］
端末は、スマートフォンに限らず、例えば、ウェブ閲覧機能を備えた携帯電話機、無線通信機能を備えたタブレットコンピュータ、ＧＰＳゴルフナビゲーション用の専用端末等であってもよい。また、端末は、ＧＰＳを利用したゴルフのナビゲーション機能を備えていなくてもよい。また、端末は、ＳＮＳサーバ１０で管理しているプレイ情報の閲覧や、ＳＮＳサーバ１０に対してプレイ情報の送信や取得を指示することができればよいから、携帯型の通信装置に限らず、例えば据置型のパーソナルコンピュータ等であってもよい。

【0115】

［変形例９］
スポーツ施設は、ゴルフ場以外に、例えば、１または複数のバーチャルゴルフマシンが設置されたゴルフバーであってもよい。この場合、ゴルフバーでバーチャルゴルフをプレイした日やそのスコアがプレイ情報として管理される。また、本発明は、ゴルフ以外のスポーツにも適用可能であり、スポーツ施設は、ゴルフ場やゴルフバー以外に、例えば、ボーリング場、テニス場、スポーツジム、スイミングクラブ、陸上競技場等であってもよい。例えば、ボーリング場の場合、ボーリング場でボーリングをプレイした日やそのスコアがプレイ情報として管理される。また、プレイ情報として管理されるスポーツのプレイ結果は、スコア以外に、勝敗、順位、タイム等であってもよい。

【0116】

［変形例１０］
本発明に係るサーバはＳＮＳサーバに限定されない。すなわちサーバは、会員制のサーバや、ソーシャルネットワークサービスを主要なサービスとするサーバに限らず、１以上のスポーツ施設の管理装置と通信を行って、スポーツ施設の利用者のプレイ情報を管理することが可能なサーバであればよい。また、サーバと端末との間に介在するネットワークは、インターネットや移動体通信網に限らず、ＷＡＮ（Wide Area Network）やＬＡＮ（Local Area Network）等であってもよい。

【符号の説明】

【0117】

１…管理システム、１０…ＳＮＳサーバ、Ｇ，Ｇ_１〜Ｇ_ｍ…ゴルフ場、２０，２０_１〜２０_ｍ…ゴルフ場サーバ、２１，２１_１〜２１_ｍ…利用者管理ＤＢ、２２，２２_１〜２２_ｍ…プレイ情報管理ＤＢ、３０…インターネット、４０…移動体通信網、５０，５０_１〜５０_ｎ…スマートフォン、５１…ゴルフナビアプリ、１１０…ＣＰＵ、１２０…ＲＯＭ、１３０…ＲＡＭ、１４０…通信ＩＦ、１５０…ハードディスク、１５１…プロフィール管理ＤＢ、１５２…ゴルフ場管理ＤＢ、１５３…プレイ情報管理ＤＢ、１５４…利用者ＩＤ登録ＤＢ、ＴＢＬ１…プレイ情報記録テーブル、ＢＮ１〜ＢＮ５…表示ボタン。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】