JP2014021696A - 管理装置、サービス提供システム、管理装置の制御方法、及び、管理装置のプログラム - Google Patents

Abstract

【課題】あるサービスに係る所定のアクティビティのレベルをグループごとに算出する。
【解決手段】外部管理サーバによって提供される第２サービスの利用者であって、管理サーバにより提供される第１サービスの利用者の勤務先の情報を外部管理サーバから取得として記憶する。また、第１サービスの利用者の第１サービスにおけるアクティビティのレベルを所定の指標に基づいて算出する。算出した第１サービスの利用者のアクティビティのレベルを勤務先ごとに集計する。
【選択図】図１

Description

本発明は、特定のサービスに係る利用者の行動を管理する技術に関する。

近年、インターネット上で提供するサービスが急速に普及している。この種のサービスの一つとして、ＳＮＳ（Ｓocial Ｎetworking Ｓervice）を提供するウェブサイトが知られている。このウェブサイトでは、利用者同士のコミュニケーションを図るため、友達関係を構築できるようになっている。そして、友達同士で投稿、チャット、メールといったコミュニケーションのツールが提供として提供する手段が利用されている。特許文献１には、例えばジョギングにおける総走行距離を参加者同士で競い合うために、アバターの位置などで参加者の順位をわかり易く表示する技術が開示されている。

特表２０１１−５１８３６０号公報

特許文献１において表示される順位などの成績は、あくまでも各参加者のジョギング等の運動に基づく成績であり、ジョギング等の運動に対する各参加者のモチベーションを高めるという効果を期待し得る。
しかしながら、スポーツや娯楽等の中には、個人で行うものばかりでなく、所定のグループ単位で参加して、グループ間で競い合うものがある。このようなグループ単位で参加する運動や娯楽等における成績や熱中度などの所定のアクティビティのレベルをＳＮＳにおいて算出するということは行われていなかった。
本発明は、この点に鑑みてなされたものであり、あるサービスに係る所定のアクティビティのレベルをグループごとに算出することなどを解決課題とする。

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

上述した課題を解決するため、本発明に係る管理装置（１）は、所定のサービスを提供し、当該サービスを受ける利用者の端末装置（２）と通信可能な管理装置（１）であって、少なくとも前記利用者を一意に識別する識別情報と、前記利用者が属するグループに関する情報とを記憶可能な記憶部（１５）と、前記サービスにおける前記利用者の所定のアクティビティのレベルを所定の指標に基づいて算出する算出部（１４）と、前記利用者の前記アクティビティのレベルをグループごとに集計する集計部（１６）とを備えることを特徴とする。
この発明において、グループは所属企業、出身大学、所属大学、所属団体等を含む概念である。また、アクティビティはスポーツや娯楽における平均の成績、スポーツや娯楽を行う頻度、スポーツや娯楽についての報告を行った回数、所定のサービスの利用者数、結束率、所定のサービスを利用度合い等を含む概念である。

上述した課題を解決するため、本発明に係る管理装置（１）は、第１サービスの提供を受ける第１利用者を含む第２利用者に対して第２サービスを提供すると共に、少なくとも前記第２利用者を一意に識別する第２識別情報と、前記第２利用者が属するグループに関する情報とを管理する外部管理装置（３）と通信可能で、かつ、前記第１利用者の端末装置（１）と通信可能な管理装置（２）であって、少なくとも前記第１利用者を一意に識別する第１識別情報を記憶可能な記憶部（１５）と、前記第１サービスにおける前記第１利用者の所定のアクティビティのレベルを所定の指標に基づいて算出する算出部（１４）と、前記第１利用者の前記アクティビティのレベルをグループごとに集計する集計部（１６）とを備える。
この発明において、グループは所属企業、出身大学、所属大学、所属団体等を含む概念である。また、アクティビティはスポーツや娯楽における平均の成績、スポーツや娯楽を行う頻度、スポーツや娯楽についての報告を行った回数、所定のサービスの利用者数、結束率、所定のサービスを利用度合い等を含む概念である。

上述した管理装置（１）において、前記集計部（１６）により集計した前記グループごとの前記アクティビティのレベルに基づいて、前記グループをランキング表示させるための情報を前記端末装置（２）に送信可能な表示制御部（１７）を更に備えるようにしてもよい。

上述した管理装置（１）において、前記表示制御部（１７）は、前記ランキング表示させた前記グループのうちの少なくとも２つのグループの前記アクティビティのレベルを前記アクティビティの要素ごとに比較表示させることができる情報を前記端末装置（２）に送信可能としてもよい。

上述した管理装置（１）において、前記表示制御部（１７）は、前記グループに対応する画像を表示させ、前記グループごとの前記アクティビティのレベルに対応させて当該画像を変化させることができる情報を前記端末装置（２）に送信可能としてもよい。

上述した課題を解決するため、本発明に係るサービス提供システムは、利用者にサービスを提供する管理装置（１）と、当該管理装置（１）と通信可能な当該利用者の端末装置（２）とを備えるサービス提供システムであって、前記管理装置（１）は、少なくとも前記利用者を一意に識別する識別情報と、前記利用者が属するグループに関する情報とを記憶可能な記憶部（１５）と、前記サービスにおける前記利用者の所定のアクティビティのレベルを所定の指標に基づいて算出する算出部（１４）と、前記利用者の前記アクティビティのレベルをグループごとに集計する集計部（１６）とを備え、前記端末装置（２）は、前記利用者のアクティビティに関する情報を前記管理装置（１）に通知する通知部（２２）を少なくとも備えることを特徴とする。

上述した課題を解決するため、本発明に係るサービス提供システムは、第１サービスの提供を受ける第１利用者を含む第２利用者に対して第２サービスを提供すると共に、少なくとも前記第２利用者を一意に識別する第２識別情報と、前記第２利用者が属するグループに関する情報とを管理する外部管理装置（３）と通信可能な管理装置（１）と、当該管理装置（１）と通信可能な前記第１利用者の端末装置（２）とを備えるサービス提供システムであって、前記管理装置（１）は、少なくとも前記第１利用者を一意に識別する第１識別情報を記憶可能な記憶部（１５）と、前記第１サービスにおける前記第１利用者の所定のアクティビティのレベルを所定の指標に基づいて算出する算出部（１４）と、前記第１利用者の前記アクティビティのレベルをグループごとに集計する集計部（１６）とを備え、前記端末装置（２）は、前記利用者のアクティビティに関する情報を前記管理装置（１）に通知する通知部（２２）を少なくとも備えることを特徴とする。

上述した課題を解決するため、本発明に係る管理装置（１）の制御方法は、所定のサービスを提供し、当該サービスを受ける利用者の端末装置（２）と通信可能な管理装置（１）の制御方法であって、少なくとも前記利用者を一意に識別する識別情報と、前記利用者が属するグループに関する情報とを記憶し、前記識別情報を読み出し、前記サービスにおける前記利用者の所定のアクティビティのレベルを所定の指標に基づいて算出し、前記利用者の前記アクティビティのレベルをグループごとに集計することを特徴とする。

上述した課題を解決するため、本発明に係る管理装置（１）の制御方法は、第１サービスの提供を受ける第１利用者を含む第２利用者に対して第２サービスを提供すると共に、少なくとも前記第２利用者を一意に識別する第２識別情報と、前記第２利用者が属するグループに関する情報とを管理する外部管理装置（３）と通信可能で、かつ、前記第１利用者の端末装置（２）と通信可能な管理装置（１）の制御方法であって、少なくとも前記第１利用者を一意に識別する第１識別情報を記憶し、前記第１識別情報を読み出し、前記第１サービスにおける前記第１利用者の所定のアクティビティのレベルを所定の指標に基づいて算出し、前記第１利用者の前記アクティビティのレベルをグループごとに集計することを特徴とする。

上述した課題を解決するため、本発明に係る管理装置（１）のプログラムは、所定のサービスを提供し、当該サービスを受ける利用者の端末装置（２）と通信可能でコンピュータを備える管理装置（１）のプログラムであって、前記コンピュータを、少なくとも前記利用者を一意に識別する識別情報と、前記利用者が属するグループに関する情報とを記憶可能な記憶部（１５）と、前記サービスにおける前記利用者の所定のアクティビティのレベルを所定の指標に基づいて算出する算出部（１４）と、前記利用者の前記アクティビティのレベルをグループごとに集計する集計部（１６）として機能させることを特徴とする。

上述した課題を解決するため、本発明に係る管理装置（１）のプログラムは、第１サービスの提供を受ける第１利用者を含む第２利用者に対して第２サービスを提供すると共に、少なくとも前記第２利用者を一意に識別する第２識別情報と、前記第２利用者が属するグループに関する情報とを管理する外部管理装置（３）と通信可能で、かつ、前記第１利用者の端末装置（２）と通信可能でコンピュータを備える管理装置（１）のプログラムであって、前記コンピュータを、少なくとも前記第１利用者を一意に識別する第１識別情報を記憶可能な記憶部（１５）と、前記第１サービスにおける前記第１利用者の所定のアクティビティのレベルを所定の指標に基づいて算出する算出部（１４）と、前記第１利用者の前記アクティビティのレベルをグループごとに集計する集計部（１６）として機能させることを特徴とする。

本発明の第１実施形態に係るサービス提供システムのブロック図である。 ＳＮＳ利用者とゴルフ利用者の関係を示す説明図である。 ゴルフ利用者情報テーブルのデータ構造の一例を示す説明図である。 企業テーブルのデータ構造の一例を示す説明図である。 スコアテーブルのデータ構造の一例を示す説明図である。 ラウンド頻度ーブルのデータ構造の一例を示す説明図である。 ＳＮＳ利用者情報テーブルのデータ構造の一例を示す説明図である。 ＳＮＳ友達情報テーブルのデータ構造の一例を示す説明図である。 管理サーバの構成を示すブロック図である。 端末装置の構成を示すブロック図である。 表示処理に関するサービス提供システムの動作シーケンスを示すシーケンス図である。 表示処理に関するサービス提供システムの動作シーケンスを示すシーケンス図である。 本人と友達関係にあるＳＮＳ友達を特定する処理を示す説明図である。 ＳＮＳ友達のＳＮＳ友達を特定する処理を示す説明図である。 「ゴルフ友達」と「ゴルフ友達のゴルフ友達」の配置を説明するための説明図である。 端末装置の表示画面の一例を示す説明図である。 企業ＩＤの登録処理に関するサービス提供システムの動作シーケンスを示すシーケンス図である。 企業ＩＤの登録処理に関するサービス提供システムの動作シーケンスを示すシーケンス図である。 ラウンド報告を行う際の画面の一例を示す説明図である。 利用者ログ管理テーブルのデータ構造の一例を示す説明図である。 利用者ログ管理テーブルのデータ構造の一例を示す説明図である。 利用者ログ管理テーブルのデータ構造の一例を示す説明図である。 アクティビティテーブルのデータ構造の一例を示す説明図である。 企業ゴルフ熱算出処理に関するサービス提供システムの動作シーケンスを示すシーケンス図である。 所属人数算出処理に関するサービス提供システムの動作シーケンスを示すシーケンス図である。 ラウンドプレー指数算出処理に関するサービス提供システムの動作シーケンスを示すシーケンス図である。 結束力指数算出処理に関するサービス提供システムの動作シーケンスを示すシーケンス図である。 アクティブ指数算出処理に関するサービス提供システムの動作シーケンスを示すシーケンス図である。 企業ゴルフ熱ランキング決定処理に関するサービス提供システムの動作シーケンスを示すシーケンス図である。 週マスタテーブルのデータ構造の一例を示す説明図である。 週次ポイントテーブルのデータ構造の一例を示す説明図である。 週次ポイントテーブルのデータ構造の一例を示す説明図である。 ランキングテーブルのデータ構造の一例を示す説明図である。 全体のランキング表示画面の一例を示す説明図である。 注目企業のランキング表示画面の一例を示す説明図である。 注目企業テーブルのデータ構造の一例を示す説明図である。 ウォール表示画面の一例を示す説明図である。 企業データ比較画面の一例を示す説明図である。 企業データ画面の一例を示す説明図である。 企業データ画面の一例を示す説明図である。 第２実施形態に係る管理サーバのブロック図である。 ゴルフ友達情報テーブルのデータ構造の一例を示す説明図である。 第２実施形態に係る招待処理に関するサービス提供システムの動作シーケンスを示すシーケンス図である。 ＳＮＳ友達のＳＮＳ友達を特定する処理を示す説明図である。 ゴルフ友達を特定する処理を示す説明図である。 ゴルフ友達のゴルフ友達を特定する処理を示す説明図である。 第３実施形態に係るサービス提供システムのブロック図である。 企業ゴルフ熱に応じたビルアイコンの一例を示す説明図である。 企業ゴルフ熱に応じたビルアイコンの一例を示す説明図である。 企業ゴルフ熱に応じたビルアイコンの一例を示す説明図である。 利用者マスターテーブルのデータ構造の一例を示す説明図である。 平均年齢マスターテーブルのデータ構造の一例を示す説明図である。

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

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

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

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

図１を参照して、管理サーバ１の機能を説明する。管理サーバ１は、ゴルフ利用者情報テーブルＴＢＬ１１、利用者ログ管理テーブルＴＢＬ１３、設定値管理マスターテーブルＴＢＬ１５、週次ポイントテーブルＴＢＬ１７、ランキングテーブルＴＢＬ１８、及び、注目企業テーブルＴＢＬ１９を記憶した記憶部１５を備える。また、記憶部１５には、管理サーバ１を制御するプログラムが記憶されている。ゴルフ利用者情報テーブルＴＢＬ１１には、ゴルフ利用者を一意に識別する識別情報ＵＩＤなどが格納されている。利用者ログ管理テーブルＴＢＬ１３には、ゴルフ利用者のゴルフ情報アプリケーションの利用履歴が記録される。設定値管理マスターテーブルＴＢＬ１５（ＴＢＬ１５ａ，ＴＢＬ１５ｂ，ＴＢＬ１５ｃ，ＴＢＬ１５ｄ，ＴＢＬ１５ｅ）には、各種設定値が記録されている。週次ポイントテーブルＴＢＬ１７には、１週間ごとの企業ゴルフ熱などが記録される。企業ゴルフ熱については後述する。ランキングテーブルＴＢＬ１８には、企業ゴルフ熱に基づく企業の順位などが録される。注目企業テーブルＴＢＬ１９には、注目企業のみのランキング表示を行うためのフラグなどが記録される。

管理サーバ１は、本人（所定のゴルフ利用者の一例）の端末装置２から本人の友達関係を表示する要求を受信すると、記憶部１５に記憶された本人の識別情報ＵＩＤに基づいて、外部管理サーバ３で管理する友達情報及び所属する企業情報を取得可能な取得部１１と、記憶部１５に記憶されているゴルフ利用者の識別情報ＵＩＤ及び取得部１１により取得した友達情報に基づいて、本人と友達関係を有するＳＮＳ利用者のうちゴルフ利用者に該当する者をゴルフ友達（第１特定利用者の一例）として抽出すると共に、本人と友達関係を有するＳＮＳ利用者と更に友達関係を有するＳＮＳ利用者（ＳＮＳ友達のＳＮＳ友達）のうちゴルフ利用者に該当する者をゴルフ友達のゴルフ友達（第２特定利用者の一例）として抽出する第１抽出部１２と、記憶部１５に記憶されているゴルフ利用者の識別情報ＵＩＤ及び所属する企業情報等から、企業ごとにゴルフ利用者の識別情報ＵＩＤ等を抽出する第２抽出部１３と、企業ごとのゴルフに対する関心の高さ等を示す企業ゴルフ熱を所定の指標に基づいて算出する算出部１４と、ゴルフ利用者のゴルフ熱を企業ごとに集計する集計部１６と、第１抽出部１２で特定したゴルフ友達及びゴルフ友達のゴルフ友達の関連性を示す関係図を表示するために必要な情報、及び後述するゴルフ友達のゴルフ友達と本人とに共通のゴルフ友達を表示するために必要な情報を含む応答を本人の端末装置２に送信すると共に、企業のランキングに関する情報、企業ゴルフ熱に関する情報等を表示するために必要な情報を含む応答を本人の端末装置２に送信する表示制御部１７とを備える。

図１を参照して、端末装置２の機能を説明する。端末装置２は、入力部２１と、通知部２２と、表示部２３とを備える。

入力部２１は、ゴルフ利用者のプロフィール情報の入力、ゴルフに行ってきた時のスコア等のラウンド報告、ゴルフ情報アプリケーションにおけるメッセージやコメントの入力等を行うことができる。
通知部２２は、前記入力部２１において入力されたゴルフ利用者のプロフィール情報、ゴルフに行ってきた時のスコア等のラウンド報告等、ゴルフ情報アプリケーションにおける各種のアクティビティに関する情報を管理サーバ１に通知することができる。
表示部２３は、管理サーバ１の表示制御部１７から送信されるゴルフ友達及びゴルフ友達のゴルフ友達の関連性を示す関係図、管理サーバ１よって抽出された企業に関する情報等を表示するために必要な情報等を表示することができる。

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

プロフィール情報は、性別、年齢、及びメールアドレスを含む。また、ラウンド履歴情報は、自己申告による平均スコア、ゴルフ頻度等を含む。企業名は、外部管理サーバ３が備えるＳＮＳ利用者情報テーブルＴＢＬ３１に記録されている勤務先の情報と一致するという対応関係を有している。図７に外部管理サーバ３が備えるＳＮＳ利用者情報テーブルＴＢＬ３１の一例を示す。図７に示すように、ＳＮＳ利用者情報テーブルＴＢＬ３１には、ＳＮＳ利用者ごとに勤務先や識別情報ＵＩＤ等が記録されている。そこで、外部管理サーバ３から識別情報ＵＩＤを取得する際に、同時に勤務先の情報を企業名として取得する。そして、図４に示す企業テーブルＴＢＬ１５ａを参照して、取得した企業名に対応する企業ＩＤを読み取り、ゴルフ利用者情報テーブルＴＢＬ１１に記録する。詳しくは後述する。
平均スコアは、図５に示すスコアテーブルＴＢＬ１５ｂを参照して、０から５までのランクの値が記録される。ゴルフ頻度は、図６に示すラウンド頻度テーブルＴＢＬ１５ｃを参照して、０から５までのランクの値が記録される。

なお、ゴルフ利用者情報テーブルＴＢＬ１１のレコードには、その他の情報を記録してもよい。また、ゴルフ利用者情報テーブルＴＢＬ１１に記憶すべき情報として、ゴルフ利用者の識別情報ＵＩＤ、企業名、企業ＩＤは必須であるが、その他の情報は省略してもよい。さらに、ゴルフ利用者情報テーブルＴＢＬ１１をキーとなる情報（例えば、識別情報ＵＩＤ）で紐づけた複数のテーブルで構成し、リレーショナルデータベースとしてもよい。

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

管理サーバ１は、各ゴルフ利用者に対してマイページを提供する。マイページには、各種のゴルフに関する情報が集約されて表示される。図１５にマイページの一例を示す。同図に示すように領域Ｘ１には、本人のプロフィール画像が表示され、領域Ｙ１には、本人のゴルフ友達を示す画像が表示され、さらに、領域Ｙ２には、ゴルフ友達のゴルフ友達を示す画像が表示される。このように、ゴルフ友達と、ゴルフ友達のゴルフ友達とが、異なる領域Ｙ１及びＹ２に表示されるので、本人は、階層的な友達関係を容易に把握することが可能となる。なお、領域Ｙ１及びＹ２にゴルフ友達及びゴルフ友達のゴルフ友達を表示する際には、親密度を算出し、親密度の高い順に手前側から表示している。なお、親密度の算出は、ゴルフ情報アプリケーション内における交流の頻度や、共通のゴルフ友達の数等によって算出するようにすればよい。

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

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

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

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

図１０に端末装置２の構成を示す。端末装置２は、装置全体を制御するＣＰＵ４０、ＣＰＵ４０の作業領域として機能するＲＡＭ４１、ブートプログラムなどを記憶したＲＯＭ４２、各種のプログラムやデータを記憶する記憶装置４３、テンキーなどを含む入力部４４、画像を表示するディスプレイ４５、及び通信網ＮＥＴを介して外部の装置と通信を行う通信インターフェース４６を備える。なお、入力部がタッチパネルである場合は、ディスプレイ４５がタッチパネルである入力部４４を兼ねることとなる。入力部４４は単一のデバイスで構成しても、複数のデバイスを組み合わせて構成しても良い。

＜２．サービス提供システムの動作＞
本実施形態のサービス提供システム１００では、ゴルフ利用者の端末装置２において、ゴルフ友達の階層構造を示す関係図を表示させることができ、また、ゴルフ利用者が所属する企業ごとのゴルフに対する関心の高さを示す企業ゴルフ熱等を表示させることができる。以下、関係図を表示させる表示処理と、ゴルフ友達のゴルフ友達と一緒にゴルフに行くことについての仲介を依頼する仲介依頼処理について説明する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

説明を図１２に戻す。次に、管理サーバ１は、企業ＩＤの更新処理を行う（Ｓ１１０）。具体的には、外部管理サーバ３から取得したＳＮＳ利用者情報に含まれる企業名と、ゴルフ利用者情報テーブルＴＢＬ１１に記録されている企業名とが一致しているかどうかを確認する。一致していない場合には、図４に示す企業テーブルＴＢＬ１５ａを参照して企業ＩＤを読み取り、ゴルフ利用者情報テーブルＴＢＬ１１に記録する。この時、一致する企業ＩＤが存在しない場合には、新たに企業ＩＤを生成するようにしてもよい。なお、企業ＩＤの更新処理の詳細については後述する。
次に、管理サーバ１は、表示情報を含むマイページ閲覧応答を端末装置２に送信する（Ｓ１１０）。端末装置２がマイページ閲覧応答を受信すると、ＣＰＵ４０はディスプレイ４５に「ゴルフ友達」と「ゴルフ友達のゴルフ友達」とを配置した関係図を表示する（Ｓ１９９）。本実施形態では、図１４及び図１５に示すように「ゴルフ友達」が手前に配置され、「ゴルフ友達のゴルフ友達」が「ゴルフ友達」より奥に配置されるので、ゴルフ利用者は、ゴルフ友達の階層関係を容易に把握することができる。さらに、本人とより関係の深い「ゴルフ友達」は「ゴルフ友達のゴルフ友達」よりも大きなアイコンで表示されるので、両者の階層関係を一見して把握することができる。加えて、「ゴルフ友達のゴルフ友達」は、本人のゴルフ友達のそれぞれに対して友達関係があるので、「ゴルフ友達」よりも人数が多いのが通常である。「ゴルフ友達のゴルフ友達」のアイコンを「ゴルフ友達」のアイコンよりも小さくすることによって、効率の良い表示が可能となる。

＜２−２：企業名と企業ＩＤの登録処理及び更新処理＞
次に、本実施形態におけるゴルフ利用者が所属する企業名と企業ＩＤの登録処理及び更新処理について説明する。本実施形態においては、ゴルフ利用者が所属する企業名と企業ＩＤの登録は、ＳＮＳ利用者がゴルフ情報アプリケーションを利用するゴルフ利用者として最初に利用者登録する際に行われる。また、ゴルフ利用者が所属する企業名と企業ＩＤの更新処理は、ゴルフ利用者がゴルフ情報アプリケーションにログインする度に行われる。

まず、図１６を参照して、ゴルフ利用者が所属する企業名と企業ＩＤの登録処理について説明する。外部管理サーバ３において提供されるＳＮＳにおいては、ＳＮＳ利用者の勤務先をＳＮＳ上のプロフィール情報として登録可能になっている。そこで、本実施形態では、ＳＮＳ利用者がゴルフ情報アプリケーションを利用するゴルフ利用者として最初に利用者登録する際に、ＳＮＳにおいて登録されているＳＮＳ利用者の勤務先情報を管理サーバ１によって取得し、管理サーバ１によってゴルフ利用者の所属する企業名として登録する。また、企業名に企業ＩＤを対応させて登録する。つまり、図１６は、ＳＮＳ利用者がゴルフ情報アプリケーションを利用するゴルフ利用者として最初に利用者登録する際に実行される処理を示している。
本実施形態では、ゴルフ情報アプリケーションへの利用者登録は、ＳＮＳにログインした状態でゴルフ情報アプリケーションへアクセスしたときに行われるため、ＳＮＳ利用者本人の識別情報ＵＩＤは外部管理サーバ３において認識されている。そこで、外部管理サーバ３のＣＰＵは、認識しているＳＮＳ利用者本人の識別情報ＵＩＤを管理サーバ１に送信する（Ｓ３１０）。なお、ＳＮＳ利用者がゴルフ利用者としてゴルフ情報アプリケーションに最初に利用者登録を行う際、所定の許諾を要求する画面を端末装置２のディスプレイ４５に表示させることとしてもよい。その場合、ＳＮＳ利用者から許諾する旨の操作を受け付けると、外部管理サーバ３から管理サーバ１に対してＳＮＳ利用者本人の識別情報ＵＩＤが送信される。
管理サーバ１のＣＰＵ３０は、受信した識別情報ＵＩＤを、ゴルフ利用者の識別情報ＵＩＤとしてゴルフ利用者情報テーブルＴＢＬ１１に登録する。そして、当該ゴルフ利用者の識別情報ＵＩＤと共に、当該ゴルフ利用者の勤務先情報を外部管理サーバ３に対して要求する（Ｓ１３１）。この要求を受信した外部管理サーバ３は、識別情報ＵＩＤに基づいてプロフィール情報を参照し、プロフィール情報として登録されている勤務先の情報を抽出する（Ｓ３１１）。勤務先情報としては、本実施形態においては勤務先の企業名が登録されているものとする。勤務先の情報の登録は任意なので、実際に勤務していても勤務先情報が登録されていないことがある。また、学生や働いていない利用者についても勤務先情報は登録されていない。このような場合には、勤務先が登録されていない旨の情報が抽出されることになる。外部管理サーバ３のＣＰＵは、抽出した勤務先情報または勤務先が登録されていない旨の情報を管理サーバ１に送信する。
勤務先情報を受信した管理サーバ１のＣＰＵ３０は、この勤務先情報をゴルフ利用者の所属する企業名として取得する（Ｓ１３２）。次に、管理サーバ１のＣＰＵ３０は、取得した企業名が、図４に示す企業テーブルＴＢＬ１５ａに登録されている企業名と一致するかどうかを判定する（Ｓ１３３）。本実施形態においては、企業テーブルＴＢＬ１５ａには既にいくつかの企業名と、その企業名に対応する企業ＩＤが登録されているものとする。取得した企業名が企業テーブルＴＢＬ１５ａに登録されている企業名と一致しない場合には（Ｓ１３３；ＮＯ）、当該企業名を企業テーブルＴＢＬ１５ａに新たに登録し、当該企業名に対応する企業ＩＤを割り当てて企業テーブルＴＢＬ１５ａに登録する（Ｓ１３４）。例えば、企業ＩＤはシリアル番号形式にして＋１ずつ増やして行ってもよいし、重複しないようにランダムに生成するようにしてもよい。
また、取得した企業名が企業テーブルＴＢＬ１５ａに登録されている企業名と一致した場合には（Ｓ１３３；ＹＥＳ）、一致した企業名に対応する企業ＩＤを取得する（Ｓ１３５）。新たに企業ＩＤを割り当てた場合にも（Ｓ１３３；ＮＯ、Ｓ１３４）、その企業ＩＤを取得する（Ｓ１３５）。そして、管理サーバ１のＣＰＵ３０は、取得した企業ＩＤを当該ゴルフ利用者の識別情報ＵＩＤと関連付けてゴルフ利用者情報テーブルＴＢＬ１１に登録する（Ｓ１３６）。

次に、図１７を参照して、ゴルフ利用者が所属する企業名と企業ＩＤの更新処理について説明する。ＳＮＳ利用者は、ＳＮＳの利用開始時にはプロフィール情報に勤務先を登録していなくても、後から勤務先を登録する場合がある。また、学生が新たに勤務した場合にも同様である。さらに、勤務先が変わった場合には、プロフィール情報の勤務先を更新することがある。そこで、本実施形態では、上述のようにゴルフ情報アプリケーションの利用登録時に企業名と企業ＩＤの登録処理を行うが、勤務先情報が更新された場合を考慮して、ゴルフ利用者がゴルフ情報アプリケーションにログインする度に、あるいは、毎日深夜０時などにゴルフ利用者が所属する企業名と企業ＩＤの更新処理を行っている。つまり、図１７は、ゴルフ利用者がゴルフ情報アプリケーションにログインする度に、または、毎日深夜０時などに実行される処理を示している。
図１７に示すように、管理サーバ１のＣＰＵ３０は、ゴルフ利用者本人の識別情報ＵＩＤ及びゴルフ利用者本人の勤務先情報の要求を外部管理サーバ３に送信する（Ｓ１４０）。識別情報ＵＩＤを受信した外部管理サーバ３のＣＰＵは、識別情報ＵＩＤに基づいてプロフィール情報を参照し、プロフィール情報として登録されている勤務先の情報を抽出する（Ｓ３２０）。そして、外部管理サーバ３のＣＰＵは、抽出した勤務先情報または勤務先が登録されていない旨の情報を管理サーバ１に送信する。
勤務先情報を受信した管理サーバ１のＣＰＵ３０は、この勤務先情報をゴルフ利用者の所属する企業名として取得する（Ｓ１４１）。次に、管理サーバ１のＣＰＵ３０は、取得した企業名が、図３に示すゴルフ利用者情報テーブルＴＢＬ１１に登録されている当該ゴルフ利用者の企業名と一致するかどうかを判定する（Ｓ１４２）。一致する場合には（Ｓ１４２；ＹＥＳ）、ゴルフ利用者情報テーブルＴＢＬ１１の登録情報を更新する必要がないので、処理を終了する。
しかし、一致しない場合には（Ｓ１４２；ＮＯ）、図４に示す企業テーブルＴＢＬ１５ａに登録されている企業名と、取得した企業名とが一致するかどうかを判定する（Ｓ１４３）。取得した企業名が企業テーブルＴＢＬ１５ａに登録されている企業名と一致しない場合には（Ｓ１４３；ＮＯ）、当該企業名を企業テーブルＴＢＬ１５ａに新たに登録し、当該企業名に対応する企業ＩＤを割り当てて企業テーブルＴＢＬ１５ａに登録する（Ｓ１４４）。
また、取得した企業名が企業テーブルＴＢＬ１５ａに登録されている企業名と一致した場合には（Ｓ１４３；ＹＥＳ）、一致した企業名に対応する企業ＩＤを取得する（Ｓ１４５）。新たに企業ＩＤを割り当てた場合にも（Ｓ１４３；ＮＯ、Ｓ１４４）、その企業ＩＤを取得する（Ｓ１４５）。そして、管理サーバ１のＣＰＵ３０は、取得した企業ＩＤを当該ゴルフ利用者の識別情報ＵＩＤと関連付けてゴルフ利用者情報テーブルＴＢＬ１１に上書きして登録し、更新処理を行う（Ｓ１４６）。

以上のように、本実施形態においては、ゴルフ利用者がＳＮＳにおいてプロフィール情報に勤務先を登録している場合には、その勤務先をゴルフ利用者の所属する企業名及び当該企業名に対応する企業ＩＤとしてゴルフ利用者情報テーブルＴＢＬ１１に登録し、随時更新している。したがって、後述するように、企業ごとにゴルフに対する関心の高さを示す企業ゴルフ熱を算出することができる。

＜２−３：ラウンド報告＞
本実施形態では、上述したようにゴルフ利用者情報テーブルＴＢＬ１１において、各ゴルフ利用者の所属する企業名及び当該企業名に対応する企業ＩＤと、各ゴルフ利用者の識別情報ＵＩＤとを関連付けて記憶しているので、ゴルフ情報アプリケーションにおける各ゴルフ利用者のアクティビティのレベルや各ゴルフ利用者のプロフィール情報を企業ごとに集計し、それを基にして企業のランキングを表示したり、企業間のデータ比較を行うことができる。
ゴルフ情報アプリケーションにおける各ゴルフ利用者のアクティビティには様々なものがあるが、以下、図１５及び図１８を参照して、ゴルフ情報アプリケーションにおけるアクティビティの一つであるラウンド報告について説明する。

図１５に示すマイページにおいて、鉛筆を形取った鉛筆アイコンＸ２を押下すると、図１８に示すように近況報告画面Ｐ１がポップアップ表示される。近況報告画面Ｐ１には、最上部の位置にプルダウンメニューＣ１が表示されており、プルダウンメニューＣ１の矢印ボタンを押下すると、近況報告の項目である「誘う」、「プレーした」、「練習した」、「近況」、「ゴルフに行きたい」、及び、「ゴルフ用品の近況」が一覧表示されるので、これらの項目の中のいずれにカーソルを合わせることにより、近況報告の項目の選択を行うことができる。図１７に示す画面では、「プレーした」が選択された例を示している。「プレーした」という項目は、実際にゴルフのラウンドを行ったことの報告を行うラウンド報告の際に選択される。
なお、「誘う」はゴルフ友達をラウンドに誘う場合に選択され、「練習した」はゴルフ練習の報告の際に選択される。また、「近況」は自由に現在の状況等を投稿する際に選択され、「ゴルフに行きたい」はゴルフに行きたいという気持ちをゴルフ友達にアピールする際に選択される。また、「ゴルフ用品の近況」は、例えば新しいゴルフクラブ等の購入の報告等の際に選択される。
プルダウンメニューＣ１で「プレーした」を選択すると、図１８に示すようにラウンド報告の画面が表示される。ラウンド報告の画面には、スコア欄Ｃ２、ＦＲＯＮＴ９スコア入力欄Ｃ３、ＢＡＣＫ９スコア入力欄Ｃ４、ゴルフ場名入力欄Ｃ５、感触入力欄Ｃ６-Ｃ９、コメント入力欄Ｃ１０、同伴者選択ボタンＣ１１、投稿ボタンＣ１２が表示される。
ＦＲＯＮＴ９スコア入力欄Ｃ３にはアウトの９ホールのスコアを記入し、ＢＡＣＫ９スコア入力欄Ｃ４にはインの９ホールのスコアを入力する。また、スコア入力欄Ｃ２にはそのラウンドのトータルのスコア、すなわちＦＲＯＮＴ９スコア入力欄Ｃ３に入力された値と、ＢＡＣＫ９スコア入力欄Ｃ４に入力された値との合計値が表示される。
ゴルフ場名入力欄Ｃ５にはラウンドしたゴルフ場の名前を、例えばテキストで入力する。但し、予めいくつかのゴルフ場の名前をプルダウンメニューとして用意しておき、その中から選択するようにしてもよい。ゴルフ場の名前の入力は任意である。
感触入力欄Ｃ６-Ｃ９は、「いい感じ」に対応する入力欄Ｃ６、「まあまあ」に対応する入力欄Ｃ７、「いまいち」に対応する入力欄Ｃ８、「全然ダメ」に対応する入力欄Ｃ９から成る。ラウンド報告を投稿すると、ゴルフ情報アプリケーションのマイページやタイムラインに表示されるが、その際に、感触入力欄Ｃ６-Ｃ９で入力した感触に対応させたアイコンを表示するようにしてもよい。
コメント入力欄Ｃ１０には、ゴルフ利用者が自由にコメントを入力することができる。ここで入力したコメントは、ラウンド報告がマイページやタイムラインに表示される際にも表示され、このコメントに対してゴルフ友達がコメントすることもできる。
同伴者選択ボタンＣ１１を選択すると、「同じ企業」、「ゴルフ友達」、及び、「その他」のいずれかを選択する画面が表示される。「同じ企業」を選択した場合には、同じ企業に所属するゴルフ利用者がリスト表示される。この同じ企業に所属するゴルフ利用者は、本人のゴルフ友達でない者も含まれる。この「同じ企業」が選択された場合、当該本人についての企業ＩＤと同一の企業ＩＤが登録されているゴルフ利用者の識別情報ＵＩＤをゴルフ情報利用者テーブルＴＢＬ１１から抽出し、抽出された識別情報ＵＩＤに係る氏名情報を外部管理サーバ３に要求して取得する。「ゴルフ友達」を選択した場合には、本人のゴルフ友達がリスト表示される。このゴルフ友達のリストには、本人と同じ企業に所属するゴルフ利用者がいれば、そのゴルフ利用者も含まれる。したがって、いずれかのゴルフ利用者と一緒にラウンドした場合には、リスト表示された中から同伴者を選択することができる。なお、同伴者がいずれにも属さない場合には、「その他」を選択すると、同伴者の名前の入力欄が表示されるので、この入力欄に同伴者の名前をテキスト入力すればよい。
投稿ボタンＣ１２を押下すると、入力した情報と共に、ラウンド報告の投稿要求が端末装置２から管理サーバ１に通知され、この情報と要求とを受信した管理サーバ１は、ゴルフ情報アプリケーションのタイムライン、及び当該ゴルフ利用者本人のマイページにラウンド報告として表示させる。

以上のようなラウンド報告を行うと、当該報告を行った事実及び投稿した内容が利用者ログ管理テーブルＴＢＬ１３に記録される。また、ラウンド報告以外にも、プルダウンメニューＣ１の矢印ボタンを押下すると、近況報告の項目である「誘う」、「プレーした」、「練習した」、「近況」、「ゴルフに行きたい」、及び、「ゴルフ用品の近況」を選択して投稿した場合にも、当該投稿を行った事実及び投稿した内容が利用者ログ管理テーブルＴＢＬ１３に記録される。さらに、他人の報告を閲覧したり、他人の報告にいいねボタンを押下したり、あるいは、他人の報告にコメントを投稿した場合にも、これらの事実が利用者ログ管理テーブルＴＢＬ１３に記録される。以下、図１９Ａ、図１９Ｂ、図１９Ｃ、及び図２０を参照して、利用者ログ管理テーブルＴＢＬ１３について説明する。

利用者ログ管理テーブルＴＢＬ１３は、図１９Ａに示すフィールドＦ１から図１９Ｃに示すフィールドＦ１８まで多くのフィールドを有しているため、図１９Ａ、図１９Ｂ、及び、図１９Ｃに分けて記載している。
図１９Ａに示すフィールドＦ１は、「from（誰から）」のフィールドであり、ラウンド報告などのアクティビティを行ったゴルフ利用者の識別情報ＵＩＤが記録される。
フィールドＦ２は、「to（誰に）」のフィールドであり、ゴルフの誘いやコメント等を送った相手の識別情報ＵＩＤが記録される。例えば、ラウンド報告の場合には特定の相手がいないので、「to（誰に）」のフィールドにnullが記録される。また、図１９Ａに示す２番目のレコードのように、ゴルフに誘うアクティビティの場合には「to（誰に）」のフィールドに誘った相手の識別情報ＵＩＤが記録される。
フィールドＦ３は「kind（どんな）」のフィールドであり、アクティビティの種類が記録される。図２０のアクティビティテーブルＴＢＬ１５ｄに示すように、利用者ログ管理テーブルＴＢＬ１３に記録されるアクティビティは９種類であり、指標「１」は「ゴルフに誘う」、指標「２」は「ゴルフ報告」、指標「３」は「練習報告」、指標「４」は「近況報告」、指標「５」は「ゴルフに行きたい」、指標「６」は「ゴルフ用品の近況」、指標「７」は「他人の報告を閲覧」、指標「８」は「いいねボタンを押下」、「９」は「コメントを投稿」にそれぞれ対応している。図１８に示すようなラウンド報告を行った場合には、「kind（どんな）」のフィールドには「２」が記録される。

フィールドＦ４は「date（いつ）」のフィールドであり、投稿などのアクティビティを行った日付が記録される。
フィールドＦ５は「コメントＩＤ」のフィールドであり、他のゴルフ利用者からのコメントの投稿が可能なラウンド報告や近況報告等には、各ラウンド報告や近況報告等を一意に識別可能なコメントＩＤが記録される。例えば、図１９Ａに示す１番目のレコードは、ラウンド報告についてログであり、このラウンド報告には「xxxx９」というコメントＩＤが割り当てられ、「コメントＩＤ」のフィールドに記録される。そして、図１９Ａに示す３番目のレコードは、コメントＩＤが「xxxx９」のラウンド報告に対してコメントを投稿している例であり、この場合には、どの投稿に対してコメントを送信しているのかを特定するために、前記ラウンド報告と同じコメントＩＤが「xxxx９」が「コメントＩＤ」のフィールドに記録される。
フィールドＦ６は「コメント有無」のフィールドであり、コメント入力欄にコメントの入力がある場合には「１」が記録され、コメントの入力が無い場合には「０」が記録される。
フィールドＦ７は「コメント」のフィールドであり、コメント入力欄に入力されたコメントがそのまま記録される。コメントの入力が無い場合にはnullが記録される。

図１９Ｂに示すフィールドＦ８は「ｎｅｗｓＩＤ」のフィールドであり、タイムラインに表示されるゴルフに関するニュースについていいねボタンを押下した場合等には、この「ｎｅｗｓＩＤ」のフィールドに当該ニュースを特定するｎｅｗｓＩＤが記録されることになる。したがって、利用者ログ管理テーブルＴＢＬ１３において、同一のｎｅｗｓＩＤにいいねボタンを押下しているゴルフ利用者が複数居たとすれば、これらのゴルフ利用者には興味が共通していると判断することもできる。
フィールドＦ９は「スコア有無」のフィールドであり、ラウンド報告の際に、スコア入力欄にスコアの入力があった場合には「１」が記録され、スコアの入力が無い場合には「０」が記録される。
フィールドＦ１０は「スコア」のフィールドであり、ＦＲＯＮＴ９の入力欄とＢＡＣＫ９の入力欄とに入力された値の合計値がそのまま記録される。なお、他の実施形態においては、フィールドＦ１０は設けなくてもよい。
フィールドＦ１１は「ＦＲＯＮＴ９」のフィールドであり、ラウンド報告の際に、ＦＲＯＮＴ９スコア入力欄にアウトの９ホールのスコアの入力があった場合には、そのスコアの値がそのまま記録される。スコアの入力が無い場合にはnullが記録される。
フィールドＦ１２は「ＢＡＣＫ９」のフィールドであり、ラウンド報告の際に、ＢＡＣＫ９スコア入力欄にインの９ホールのスコアの入力があった場合には、そのスコアの値がそのまま記録される。スコアの入力が無い場合にはnullが記録される。
フィールドＦ１３は「場名有無」のフィールドであり、ラウンド報告の際に、ゴルフ場名入力欄にゴルフ場名の入力があった場合には「１」が記録され、ゴルフ場名の入力が無かった場合には「０」が記録される。
フィールドＦ１４は「ゴルフ場名」のフィールドであり、ラウンド報告の際に、ゴルフ場名入力欄にゴルフ場名の入力があった場合には、そのゴルフ場名がそのまま記録される。ゴルフ場名の入力が無かった場合にはnullが記録される。

図１９Ｃに示すフィールドＦ１５は「同伴者１」のフィールド、フィールドＦ１６は「同伴者２」のフィールド、フィールドＦ１６は「同伴者３」のフィールドである。ラウンド報告の際に、同伴者の選択が行われた場合には、同伴者の識別情報ＵＩＤが記録される。同伴者の選択が行われなかった場合、あるいは、ラウンド報告とは関係のないアクティビティの場合には、nullが記録される。
フィールドＦ１８は、「コメント２」のフィールドであり、同伴者がゴルフ利用者ではない場合には、同伴者名をテキスト入力してラウンド報告を行うようになっている。このような場合には、入力された同伴者名をそのまま「コメント２」のフィールドに記録する。同伴者名の入力が行われなかった場合、あるいは、ラウンド報告とは関係のないアクティビティの場合には、nullが記録される。

＜２−４：企業ゴルフ熱の算出処理＞
本実施形態においては、ゴルフ利用者情報テーブルＴＢＬ１１に登録されているゴルフ利用者を、企業ＩＤごとに抽出し、一の企業ＩＤに関連付けられている個々のゴルフ利用者のアクティビティのレベルやプロフィール等に基づいて、当該一の企業ＩＤに対応する企業のゴルフに対する関心の高さあるいは熱中度を表す企業ゴルフ熱を算出している。以下、図２１乃至図２５を参照して、企業ごとのゴルフ熱の算出処理について説明する。
本実施形態においては、図２１に示すように、一例として１週間ごとに、所属人数指数の算出（Ｓ１５０）、ラウンドプレー指数の算出（Ｓ１５１）、結束力指数の算出（Ｓ１５２）、及び、アクティブ指数の算出（Ｓ１５３）を行い、それぞれの指数を合計することにより、企業ゴルフ熱を算出する（Ｓ１５４）。以下、それぞれの指数の算出処理について説明する。

＜２−４−１：所属人数指数＞
所属人数指数は、同一の企業に所属するゴルフ利用者の人数に基づく指数である。ゴルフ利用者の人数が多いほど、その企業のゴルフに対する関心度、つまり企業ゴルフ熱が高いと考えられる。
図２２に示すように、所属人数指数を算出するには、まず最初に図４に示す企業テーブルＴＢＬ１５ａから一つの企業ＩＤを読み取る（Ｓ１６０）。次に、読み取った企業ＩＤを含むレコードをゴルフ利用者情報テーブルＴＢＬ１１から検索し、当該企業ＩＤに関連付けられたゴルフ利用者を抽出する（Ｓ１６１）。そして、抽出したゴルフ利用者の人数を算出し、一の企業ＩＤに関連付けられたゴルフ利用者数、つまり、当該一の企業ＩＤに対応する企業の所属人数を算出する（Ｓ１６２）。所属人数の算出が終了すると、全ての企業ＩＤの読み取りが終了したかどうかを確認する（Ｓ１６３）。全ての企業ＩＤの読み取りが終了していない場合には（Ｓ１６３；ＮＯ）、上述した処理を繰り返して行う。
全ての企業ＩＤの読み取りが終了した場合には（Ｓ１６３；ＹＥＳ）、各企業ＩＤに対応する企業の所属人数について、最大所属者企業比人数倍率の算出を行う（Ｓ１６４）。最大所属者企業比人数倍率とは、一の企業の所属人数に対する、最大の所属人数の企業における当該所属者数の倍率である。例えば、一の企業の所属人数が５００名で、全ての企業の所属人数の中で最大であったとする。このとき、所定の企業の所属人数が３００名である場合を考えると、この所定の企業の最大所属者企業比人数倍率は、５００／３００で、１．７となる。つまり、最大の所属人数の企業の当該所属人数は、当該所定の企業の所属人数の１．７倍であることが分かる。
このように最大所属者企業比人数倍率を求めるのは、企業間における所属人数の差が大き過ぎると、ゴルフ熱についての公平な判定ができなくなるためである。例えば、所属人数に基づく所属人数指数もゴルフ熱算出のためのパラメータの一つであるが、所属人数指数は所属人数が多いほど高い値となる。したがって、所属人数が５０人の企業と、所属人数が５００人の企業とでは、所属人数指数にも大きな差が出てしまう。また後述する所定のアクティビティに基づく指数についても、所属人数が少ないほど不利な値になってしまう。そこで、最大所属者企業比人数倍率を求め、各指数を算出する際に最大所属者企業比人数倍率を考慮することにより、企業間の公平性を保っている。
次に、各企業について、所属人数にポイントを掛け合わせて獲得ポイントを算出する。この獲得ポイントが所属人数指数となる（Ｓ１６５）。一例として、所属人数一人当たりのポイントを１ポイントとすると、所属人数が３００名である企業の所属人数指数は、３００人×１ポイントで３００ポイントとなる。この所属人数指数はいわばベースポイントとなる指数である。
また、上述のようにして算出した所属人数指数と、所属人数は、週次ポイントテーブルＴＢＬ１７に記録される。
本実施形態では、管理サーバ１の記憶部１５に図２７に示すような週マスターテーブルＴＢＬ１５ｅが記憶されている。週マスターテーブルＴＢＬ１５ｅには、特定の週を一意に識別する週ＩＤと、それぞれの週の開始日時及び終了日時とが記録される。
また、管理サーバ１の記憶部１５には、図２８Ａ及び図２８Ｂに示すような週次ポイントテーブルＴＢＬ１７が記憶されている。週次ポイントテーブルＴＢＬ１７には多くのフィールドを備えているので、図２８Ａ及び図２８Ｂに分けて記載している。
企業ゴルフ熱の算出は、一例として１週間ごとに行われるので、図２８Ａに示すように週次ポイントテーブルＴＢＬ１７には、企業ゴルフ熱の算出を行った週の週ＩＤと、当該企業の企業ＩＤと、企業ゴルフ熱の算出の基礎となる前記所属人数指数とが記録される。
また、後述するように、企業データ比較画面に所属人数を表示する際、あいるは、所属人数の増減を判定する際に使用するための所属人数についても週次ポイントテーブルＴＢＬ１７に記録される。
さらに、週次ポイントテーブルＴＢＬ１７には、図２８Ａ及び図２８Ｂに示すように、ラウンドプレー指数、平均スコア、結束力指数、アクティブ指数、ログイン数、近況報告数、リアクション数、及び、企業ゴルフ熱が記録される。それぞれの指数の内容については後述する。

＜２−４−２：ラウンドプレー指数＞
ラウンドプレー指数は、同一の企業に所属するゴルフ利用者によるラウンド報告の件数、スコア、同伴者に含まれる同一の企業に所属するゴルフ利用者の人数に基づく指数である。実際のゴルフのラウンドを行った人数が多いほど、その企業のゴルフに対する関心度、つまり企業ゴルフ熱が高いと考えられる。本実施形態では、一例として１週間ごとにラウンドプレー指数を算出する。
図２３に示すように、ラウンドプレー指数を算出するには、まず最初に利用者ログ管理テーブルＴＢＬ１３から近況のラウンド報告のレコードを抽出する（Ｓ１７０）。具体的には、図１９Ａに示す利用者ログ管理テーブルＴＢＬ１３のフィールドＦ２（kind）に「２」が記録されているレコードであって、近況のものを抽出する。一例としては、最近一週間のレコードの中から、フィールドＦ３（kind）に「２」が記録されているレコードを抽出する。
次に、読み取ったレコードのフィールドＦ１（from）に記載された識別情報ＵＩＤが、一の企業に所属するゴルフ利用者の識別情報ＵＩＤに一致する場合には、そのレコードを抽出する。つまり、この処理により、同一の企業に所属するゴルフ利用者によるラウンド報告を抽出する（Ｓ１７１）。
そして、抽出したラウンド報告に該当するレコードの件数、当該レコードのうち図１９Ｂに示すフィールドＦ１０に記録されているスコア、また、当該レコードのうち図１９Ｃに示すフィールドＦ１５−Ｆ１７に同伴者の識別情報ＵＩＤが記録されている場合には、当該同伴者の中に含まれる当該一の企業に所属するゴルフ利用者の人数を読み取り、一旦記憶しておく（Ｓ１７２）。
以上の処理を全企業分行ったかどうかを判定し（Ｓ１７３）、終了していない場合には（Ｓ１７３；ＮＯ）、他の企業についてラウンド報告に該当するレコードの抽出からの処理を繰り返す（Ｓ１７１、Ｓ１７２）。
以上の処理を全企業分行った場合には（Ｓ１７３；ＹＥＳ）、読み取った各企業ごとのラウンド報告に該当するレコードの件数に、一例として１０ポイントを掛け合わせ、各企業ごとの基本ラウンドプレーポイントを算出する（Ｓ１７４）。例えば、ある企業では、７５件のラウンド報告に該当するレコードが抽出されたとすると、基本ラウンドプレーポイントは、７５件×１０ポイントで７５０ポイントとなる。
次に、読み取った各企業ごとのラウンド報告に該当するレコードに記録されたスコア（ＦＲＯＮＴ９の入力欄に入力された値とＢＡＣＫ９の入力欄に入力された値の合計値）に基づいて、各企業ごとにスコアボーナスポイントを算出する（Ｓ１７５）。例えば、スコアが７０を切った場合には、ボーナスポイントとして一人につき４ポイント付与する。また、スコアが８０を切った場合には、ボーナスポイントとして一人につき３ポイント付与する。さらに、スコアが９０を切った場合には、ボーナスポイントとして一人につき２ポイント付与する。そして、スコアが１００を切った場合には、ボーナスポイントとして一人につき１ポイント付与する。
例えば、ある企業では、スコアが７０を切った人数が１人だとすると、ボーナスポイントは、１×４ポイントで、４ポイントとなる。また、スコアが８０を切った人数が４人だとすると、ボーナスポイントは、４×３ポイントで、１２ポイントとなる。さらに、スコアが９０を切った人数が１８人だとすると、ボーナスポイントは、１８×２ポイントで、３６ポイントとなる。そして、スコアが１００を切った人数が２４人だとすると、ボーナスポイントは、２４×１ポイントで、２４ポイントとなる。したがって、この例の場合には、スコアボーナスポイントの合計は、７６ポイントとなる。以上のようなスコアボーナスポイントの算出処理を各企業ごとに行う。
次に、読み取った各企業ごとのラウンド報告に該当するレコードに記録された同伴者の中における同一企業に所属するゴルフ利用者の人数に基づいて同伴者ボーナスポイントの算出処理を行う（Ｓ１７６）。
具体的には、１件のラウンド報告に該当するレコードごとに、
（同伴者の中の同じ企業に所属するゴルフ利用者の人数）×ポイント数（一例として５ポイント）×（当該企業に所属する全ゴルフ利用者の人数に対する、同伴者の中の同じ企業に所属するゴルフ利用者の人数の割合）×１００×最大所属者企業比人数倍率
を計算し、これを合計して、ラウンド報告に該当するレコードの件数の合計で割るようにする。
あるいは、１件のラウンド報告に該当するレコードごとに計算するのではなく、同伴者の中の同じ企業に所属するゴルフ利用者の人数の合計を、ラウンド報告に該当するレコードの件数の合計で割って、１ラウンド当たりの同じ企業に所属する同伴者の平均の人数を算出し、
（１ラウンド当たりの同じ企業に所属する同伴者の平均の人数）×ポイント数（一例として５ポイント）×（当該企業に所属する全ゴルフ利用者の人数に対する、１ラウンド当たりの同じ企業に所属する同伴者の平均の人数の割合）×１００×最大所属者企業比人数倍率
を算出するようにしてもよい。
例えば、１ラウンド当たりの同じ企業に所属する同伴者の平均の人数が３人で、当該企業に所属する全ゴルフ利用者の人数が３００人だとすると、
３×５ポイント×１％×１００×１．７＝２５．５ポイントとなる。
以上のような同伴者ボーナスポイント算出処理を各企業ごとに行う。
次に、基本ラウンドプレーポイントと、スコアボーナスポイントと、同伴者ボーナスポイントとを各企業ごとに合計し、ラウンドプレー指数を各企業ごとに算出する（Ｓ１７７）。
例えば、基本ラウンドプレーポイントが３７５、スコアボーナスポイントが７６、同伴者ボーナスポイントが２５．５の場合には、
７５０＋７６＋２５．５＝８５２ポイント（小数点以下四捨五入）となる。
以上のようなラウンドプレー指数の算出処理を全ての企業について行う。また、算出したラウンドプレー指数は、図２８Ａに示す週次ポイントテーブルＴＢＬ１７に記録される。また、本実施形態においては、各企業に所属するゴルフ利用者について、ゴルフ利用者情報テーブルＴＢＬ１１のラウンド履歴情報を参照して、ゴルフ利用者によって入力された平均スコアに応じてランクとして記録されている値を合計し、この合計値を各企業に所属するゴルフ利用者の人数で除し、スコアレベルを算出する。当該スコアレベルについても図２８Ａに示す週次ポイントテーブルＴＢＬ１７に記録される。週次ポイントテーブルＴＢＬ１７に記録されたラウンドプレー指数は、企業ゴルフ熱の算出の際に用いられると共に、週次ポイントテーブルＴＢＬ１７に記録されたラウンドプレー指数及びスコアレベルは、後述する企業データ比較を行う際に用いられる。なお、スコアレベルの算出の基礎となる平均スコアが入力されていない場合は合算を行わず、人数へのカウントも行わない。

＜２−４−３：結束力指数＞
結束力指数は、同一の企業に所属するゴルフ利用者間でどれだけゴルフ友達の関係にあり、また、お互いにどれだけ交流しているかを示す指数である。企業内での交流の度合いが高いほど、その企業のゴルフに対する関心度、つまり企業ゴルフ熱が高いと考えられる。本実施形態では、一例として１週間ごとに結束力指数を算出する。
図２３に示すように、結束力指数を算出するには、まず最初に結束率を算出する（Ｓ１８０）。結束率とは、同一の企業に所属するゴルフ利用者間でどれだけゴルフ友達の関係になっているのかを示す指数である。具体的には、ある企業に所属しているゴルフ利用者の総数をＭとすると、当該ゴルフ利用者の中のある一人のゴルフ利用者は、最大で(Ｍ−１)人とゴルフ友達になることができる。したがって、前記ある企業に所属しているゴルフ利用者全体では、最大でＭ×(Ｍ−１)人のゴルフ友達関係が存在し得る。そこで、Ｍ×(Ｍ−１)人を最大関係数として、当該最大関係数に対する実際のゴルフ友達の延べ人数を結束率とする。つまり、ある企業に所属しているゴルフ利用者の総数をＭとすると、結束率は、
結束率＝（Ｍ人分の実際の企業内ゴルフ友達の延べ人数）／Ｍ×(Ｍ−１)
となる。
例えば、ある企業のゴルフ利用者の総数が１００人（Ｍ＝１００）で、この企業に属するあるゴルフ利用者Ａ１のゴルフ友達が５人、別のゴルフ利用者Ａ２のゴルフ友達が４５人、その他の９８人のゴルフ利用者はゴルフ友達が１人だとすると、結束率は、
(５人(Ａ１)＋４５人(Ａ２)＋１人×９８(その他全員))／１００×９９＝０．０１４９４９５
となる。これをパーセントで表すと、１．４９４９５％になる。小数点第二位を四捨五入して、結束率は１．５％となる。この結束率を各企業ごとに算出する。
次に、図２４に示すように、利用者ログ管理テーブルＴＢＬ１３からコメントのレコードを抽出する（Ｓ１８１）。具体的には、図１９Ａに示す利用者ログ管理テーブルＴＢＬ１３のフィールドＦ３（kind）に「９」が記録されているレコードを抽出する。
次に、読み取ったレコードのフィールドＦ１（from）に記載された識別情報ＵＩＤと、フィールドＦ２（to）に記載された識別情報ＵＩＤとが、双方ともに一の企業に所属するゴルフ利用者の識別情報ＵＩＤに一致する場合には、そのレコードを抽出する。つまり、この処理により、同一の企業に所属するゴルフ利用者宛のコメントに該当するレコードを抽出する（Ｓ１８２）。そして、抽出したコメントに該当するレコードの件数を算出し、一旦記憶しておく（Ｓ１８３）。
以上の処理を全企業分行ったかどうかを判定し（Ｓ１８４）、終了していない場合には（Ｓ１８４；ＮＯ）、他の企業についてコメントに該当するレコードの抽出からの処理を繰り返す（Ｓ１８２、Ｓ１８３）。
以上の処理を全企業分行った場合には（Ｓ１８４；ＹＥＳ）、利用者ログ管理テーブルＴＢＬ１３からいいねのレコードを抽出する（Ｓ１８５）。具体的には、図１９Ａに示す利用者ログ管理テーブルＴＢＬ１３のフィールドＦ３（kind）に「８」が記録されているレコードを抽出する。
次に、読み取ったレコードのフィールドＦ１（from）に記載された識別情報ＵＩＤと、フィールドＦ２（to）に記載された識別情報ＵＩＤとが、双方ともに一の企業に所属するゴルフ利用者の識別情報ＵＩＤに一致する場合には、そのレコードを抽出する。つまり、この処理により、同一の企業に所属するゴルフ利用者宛のいいねに該当するレコードを抽出する（Ｓ１８６）。そして、抽出したいいねに該当するレコードの件数を算出し、一旦記憶しておく（Ｓ１８７）。
以上の処理を全企業分行ったかどうかを判定し（Ｓ１８８）、終了していない場合には（Ｓ１８８；ＮＯ）、他の企業についてコメントに該当するレコードの抽出からの処理を繰り返す（Ｓ１８６、Ｓ１８７）。
次に、上述のようにして算出した結束率、同一企業内のコメントの件数、同一企業内のいいねの件数に基づいて、結束力ポイント、交流ポイント１、及び、交流ポイント２の算出を行う。
まず、結束力ポイントは、以下のようにして算出する（Ｓ１８９）。
結束力ポイント＝結束率×１００×ポイント×最大所属者企業比人数倍率
例えば、結束率が２０％、ポイントが１０ポイント、最大所属者企業比人数倍率が１．７だとすると、
０．２×１００×１０×１．７＝３４０ポイントとなる。
以上のような結束力ポイント算出処理を全企業分行う。
次に、交流ポイント１は、以下のようにして算出する（Ｓ１９０）。
交流ポイント１＝同一企業内のコメントの件数×ポイント×結束率×１００
例えば、同一企業内のコメントの件数が３０件、ポイントが１ポイント、結束率が２０％だとすると、
３０×１×０．２×１００＝６００ポイントとなる。
以上のような結束力ポイント算出処理を全企業分行う。
次に、交流ポイント２は、以下のようにして算出する（Ｓ１９１）。
交流ポイント２＝同一企業内のいいねの件数×ポイント×結束率×１００
例えば、同一企業内のいいねの件数が６０件、ポイントが０．５ポイント、結束率が２０％だとすると、
６０×０．５×０．２×１００＝６００ポイントとなる。
結束力ポイント、交流ポイント１、及び、交流ポイント２を算出した後、これらのポイントを合計して、結束力指数を算出する（Ｓ１９２）。つまり、結束力指数は以下のようにして算出される。
結束力指数＝結束力ポイント＋交流ポイント１＋交流ポイント２
上述した例では、結束力ポイントが１７，０００ポイント、交流ポイント１が１２，０００ポイント、交流ポイント２が１２，０００ポイントなので、結束力指数は、
３４０＋６００＋６００＝１、５４０ポイント
となる。
以上のような結束力指数の算出処理を全ての企業について行う。また、算出した結束力指数は、図２８Ａに示す週次ポイントテーブルＴＢＬ１７に記録される。週次ポイントテーブルＴＢＬ１７に記録された結束力指数は、企業ゴルフ熱算出処理に用いられると共に、後述する企業データ比較を行う際に用いられる。

＜２−４−４：アクティブ指数＞
アクティブ指数は、同一の企業に所属するゴルフ利用者がどれだけゴルフ情報アプリケーションを利用しているかを示す指数である。企業に所属するゴルフ利用者がゴルフ情報アプリケーションを利用している度合いが高いほど、その企業のゴルフに対する関心度、つまり企業ゴルフ熱が高いと考えられる。本実施形態では、一例として１週間ごとにアクティブ指数を算出する。
図２５に示すように、アクティブ指数を算出するには、まず最初に同一の企業に所属するゴルフ利用者の最近のログイン回数を算出する（Ｓ２００）。管理サーバ１の記憶部１５には、個々のゴルフ利用者のアクティビティに関するログを管理するために、個人ログファイルが記憶されている。ログイン回数は、各ゴルフ利用者がログインするために、この個人ログファイルに記録される。したがって、同一の企業に所属するゴルフ利用者のログイン回数を算出するには、同一の企業に所属するゴルフ利用者の個人ログファイルにおけるログイン回数を集計すればよい。期間としては一例として最近の１週間におけるログイン回数を集計する。そして、この処理を全ての企業について実行する。
次に、同一の企業に所属するゴルフ利用者の最近の近況報告の件数の算出処理を行う。この処理を行うためには、図２５に示すように、利用者ログ管理テーブルＴＢＬ１３から最近の近況報告のレコードを抽出する（Ｓ２０１）。具体的には、図１９Ａに示す利用者ログ管理テーブルＴＢＬ１３のフィールドＦ３（kind）に「４」が記録されているレコードを抽出する。
次に、読み取ったレコードのフィールドＦ１（from）に記載された識別情報ＵＩＤと、一の企業に所属するゴルフ利用者の識別情報ＵＩＤとが一致するレコードを抽出する。期間としては一例として、最近の１週間におけるレコードを集計する。つまり、この処理により、同一の企業に所属するゴルフ利用者の最近の１週間の近況報告に該当するレコードを抽出する（Ｓ２０２）。そして、抽出した近況報告に該当するレコードの件数を算出し、一旦記憶しておく（Ｓ２０３）。
以上の処理を全企業分行ったかどうかを判定し（Ｓ２０４）、終了していない場合には（Ｓ２０４；ＮＯ）、他の企業について近況報告に該当するレコードの抽出からの処理を繰り返す（Ｓ２０２、Ｓ２０３）。
以上の処理を全企業分行った場合には（Ｓ２０４；ＹＥＳ）、利用者ログ管理テーブルＴＢＬ１３から前記抽出した近況報告に対するいいねのレコードを抽出する（Ｓ２０５）。具体的には、まず、図１９Ａに示す利用者ログ管理テーブルＴＢＬ１３のフィールドＦ３（kind）に「８」が記録されているレコードを抽出する。次に、抽出した近況報告と同じコメントＩＤが記録されているレコードを抽出する。近況報告が投稿されると、図１９Ａに示す利用者ログ管理テーブルＴＢＬ１３のフィールドＦ５（コメントＩＤ）には、当該近況報告を一意に識別するコメントＩＤが割り当てられる。そして、当該近況報告に対していいねボタンが押下された場合にも、図１９Ａに示す利用者ログ管理テーブルＴＢＬ１３のフィールドＦ３（kind）に「８」が記録されているレコードのフィールドＦ５（コメントＩＤ）には、当該近況報告に割り当てられたコメントＩＤと同じコメントＩＤが記録されている。したがって、図１９Ａに示す利用者ログ管理テーブルＴＢＬ１３のフィールドＦ３（kind）に「８」が記録されているレコードを抽出した後に、抽出したレコードに記録されているコメントＩＤと、既に抽出してある近況報告のコメントＩＤとが一致するレコードを抽出すれば、前記抽出した近況報告に対するいいねを抽出することができる。このようにして前記抽出した近況報告に対するいいねを抽出し、その件数を算出する（Ｓ２０８）。
以上の処理を全企業分行ったかどうかを判定し（Ｓ２０７）、終了していない場合には（Ｓ２０７；ＮＯ）、他の企業について近況報告に対するいいねに該当するレコードの抽出からの処理を繰り返す（Ｓ２０５、Ｓ２０６）。
以上の処理を全企業分行った場合には（Ｓ２０７；ＹＥＳ）、利用者ログ管理テーブルＴＢＬ１３から前記抽出した近況報告に対するコメントのレコードを抽出する（Ｓ２０８）。具体的には、まず、図１９Ａに示す利用者ログ管理テーブルＴＢＬ１３のフィールドＦ３（kind）に「９」が記録されているレコードを抽出する。次に、抽出した近況報告と同じコメントＩＤが記録されているレコードを抽出する。このようにして前記抽出した近況報告に対するコメントを抽出し、その件数を算出する（Ｓ２０９）。
以上の処理を全企業分行ったかどうかを判定し（Ｓ２１０）、終了していない場合には（Ｓ２１０；ＮＯ）、他の企業について近況報告に対するコメントに該当するレコードの抽出からの処理を繰り返す（Ｓ２０８、Ｓ２０９）。
以上の処理を全企業分行った場合には（Ｓ２１０；ＹＥＳ）、次に、上述のようにして算出したログイン回数、近況報告の件数、近況報告に対するいいねの件数、近況報告に対するコメントの件数に基づいて、ログインポイント、近況報告ポイント、近況報告いいねポイント、及び、近況報告コメントポイントの算出を行う。
まず、ログインポイントは、以下のようにして算出する（Ｓ２１１）。
ログインポイント＝ログイン回数×ポイント
例えば、最近１週間のログイン回数が１，５００回、ポイントが０．２ポイントだとすると、
１，５００×０．２＝３００ポイントとなる。
以上のようなログインポイント算出処理を全企業分行う。
次に、近況報告ポイントは、以下のようにして算出する（Ｓ２１２）。
近況報告ポイント＝近況報告の件数×ポイント
例えば、同一企業内のコメントの件数が２１０件、ポイントが１ポイントだとすると、
２１００×１＝２１０ポイントとなる。
以上のような近況報告ポイント算出処理を全企業分行う。
次に、近況報告いいねポイントは、以下のようにして算出する（Ｓ２１３）。
近況報告いいねポイント＝近況報告に対するいいねの件数×ポイント
例えば、近況報告に対するいいねの件数が１，０００件、ポイントが０．１ポイントだとすると、
１，０００×０．１＝１００ポイントとなる。
以上のような近況報告ポイント算出処理を全企業分行う。
次に、近況報告コメントポイントは、以下のようにして算出する（Ｓ２１４）。
近況報告コメントポイント＝近況報告に対するコメントの件数×ポイント
例えば、近況報告に対するいいねの件数が４２０件、ポイントが１ポイントだとすると、
４２０×１＝４２０ポイントとなる。
以上のような近況報告ポイント算出処理を全企業分行う。
ログインポイント、近況報告ポイント、近況報告いいねポイント、及び、近況報告コメントポイントを算出した後、これらのポイントを合計して、アクティブ指数を算出する（Ｓ２１５）。つまり、アクティブ指数は以下のようにして算出される。
アクティブ指数＝ログインポイント＋近況報告ポイント＋近況報告いいねポイント＋近況報告コメントポイント
上述した例では、ログインポイントが３００ポイント、近況報告ポイントが２１０ポイント、近況報告いいねポイントが１００ポイント、近況報告コメントポイントが４２０ポイントなので、アクティブ指数は、
３００＋２１０＋１００＋４２０＝１、０３０ポイント
となる。
以上のようなアクティブ指数の算出処理を全ての企業について行う。また、算出したアクティブ指数は、図２８Ｂに示す週次ポイントテーブルＴＢＬ１７に記録される。週次ポイントテーブルＴＢＬ１７に記録されたアクティブ指数は、企業ゴルフ熱算出処理に用いられると共に、後述する企業データ比較を行う際に用いられる。また、本実施形態においては、ログイン数についても図２８Ｂに示す週次ポイントテーブルＴＢＬ１７に記録される。週次ポイントテーブルＴＢＬ１７に記録されるログイン数は、延べ数である。このログイン数は、後述する企業データ画面を表示する際に用いられる。
また、本実施形態においては、近況報告に対するいいねの件数と、近況報告に対するコメントの件数の合計をリアクション数として図２８Ｂに示す週次ポイントテーブルＴＢＬ１７に記録する。リアクション数は、後述する企業データ画面を表示する際に用いられる。

＜２−４−５：指数合計処理＞
本実施形態においては、図２１に示すように、所属人数指数の算出（Ｓ１５０）、ラウンドプレー指数の算出（Ｓ１５１）、結束力指数の算出（Ｓ１５２）、及び、アクティブ指数の算出（Ｓ１５３）を行い、それぞれの指数を合計することにより、企業ゴルフ熱を算出する（Ｓ１５４）。
上述した例では、所属人数指数が３００ポイント、ラウンドプレー指数が８５２ポイント、結束力指数が１，５４０ポイント、アクティブ指数が１，０３０ポイントなので、この企業の企業ゴルフ熱は、
３００＋８５２＋１，５４０＋１，０３０＝３，７２２ポイント
となる。
以上のような指数合計処理を全ての企業について行い、全ての企業の企業ゴルフ熱を算出する。算出した企業ゴルフ熱は、図２８Ｂに示す週次ポイントテーブルＴＢＬ１７に記録される。

＜２−５：ランキング表示＞
本実施形態においては、図２６に示すように、１週間ごとに上述した企業ゴルフ熱の算出処理を行い（Ｓ２２０）、図２８Ｂに示す週次ポイントテーブルＴＢＬ１７に記録する。そして、当該週から過去１２週分の企業ゴルフ熱を週次ポイントテーブルＴＢＬ１７から抽出し、抽出した企業ゴルフ熱を１２週分集計することにより、所定の企業の企業ゴルフ熱を算出する（Ｓ２２１）。この処理を全企業について行う。
次に、算出した企業ゴルフ熱に、一例として４週間ごとに決められた影響度を掛けて合計値を算出する（Ｓ２２２）。例えば、過去１〜４週間については影響度を１００％、過去５〜８週間にはついて影響度を７０％、過去９〜１２週間にはついて影響度を３０％とする。
以上のようにして各企業の１２週間分の企業ゴルフ熱を合計し、ポイントの高い順にランキングを決定する（Ｓ２２３）。
前記企業ゴルフ熱及び順位は、ランキングテーブルＴＢＬ１８に記録される。本実施形態においては、管理サーバ１の記憶部１５に、図２９に示すようなランキングテーブルＴＢＬ１８が記憶されている。ランキングテーブルＴＢＬ１８には、当該週の週ＩＤ、企業ＩＤ、企業ゴルフ熱、及び今回の順位が記録される。また、各企業について先週分の順位を確認し、前回の順位としてランキングテーブルＴＢＬ１８に記録する。
ランキングの表示は、図１５に示すマイページの画面において、企業アイコンＸ３を押下することにより行う。図１５のマイページの画面で企業アイコンＸ３を押下すると、ランキングテーブルＴＢＬ１８に記録されているデータが参照され、図３０に示すようなランキング表示画面Ｐ２がポップアップ表示される。
ランキング表示画面Ｐ２においては、ゴルフ情報アプリケーションにログインしている本人が所属する企業に関する情報の表示領域が最上部に設けられる。企業に関する情報の表示領域は、企業アイコンの表示領域Ｄ１、企業名表示領域Ｄ２、企業ランキング表示領域Ｄ３を備えている。
企業アイコンの表示領域Ｄ１には、企業アイコンＸ４が表示される。企業アイコンＸ４はゴルフ利用者が登録できるようになっている。企業名表示領域Ｄ２には企業名が表示され、企業ランキング表示領域Ｄ３には、上述のようにして決定される当該企業のランキング順位が表示される。企業名表示領域Ｄ２に表示される企業名または企業ランキング表示領域Ｄ３に表示されるランキング順位を押下することにより、本人が所属する企業の情報を表示する画面に切り替わるようになっている。当該画面の詳細ついては後述する。
なお、本人がＳＮＳにおいて勤務先を登録していない場合には、企業名表示領域Ｄ２及び企業ランキング表示領域Ｄ３において、例えば、「ＳＮＳプロフィールの勤務先が未設定です。設定するとあなたの勤務先が企業ゴルフランキングに表示されます。」のような表示を行うようにすればよい。そして、この表示を押下すると、勤務先設定ページをポップアップ表示させるようにしてもよい。
ランキング表示画面Ｐ２の中心部には、企業ランキング表示領域が設けられる。企業ランキング表示領域は、「すべて」と表示されたタブＤ４と、「注目企業」と表示されたタブＤ５のいずれかを押下することにより全ての企業のランキング表示と、注目企業として設定した企業のランキング表示に切り替えることができる。図３０に示す例では、「すべて」と記載されたタブＤ４が選択された状態であり、全ての企業のランキング表示が行われる。図２９に示す例では、１４位の企業までしか表示されていないが、右端に表示されているスクロールバーＤ１５を押下しながら移動させることにより、ランキング表示される範囲を変更することが可能になっている。
ランキング表示領域は、順位表示領域Ｄ８、順位変動表示領域Ｄ９、注目企業設定ボタン表示領域Ｄ１０、企業名表示領域Ｄ１１、データ比較ボタン表示領域Ｄ１２、企業ゴルフ熱表示領域Ｄ１３、今週分の企業ゴルフ熱表示領域Ｄ１４を備えている。また、ランキング表示領域の右上には、ランキングトップの位置に表示を移動させるための「トップへ」と表示されたボタンＤ６と、本人が所属している企業に関する情報を表示させるための「所属企業へ」と表示されたボタンＤ７が表示されている。
順位変動表示領域Ｄ９には、企業の順位の変動に応じて矢印アイコンＸ５が表示される。また、新たにランキング入りした企業については、「ＮＥＷ」と表示されたアイコンＸ１０が表示される。なお、順位変動の管理処理の詳細については後述する。
注目企業設定ボタン表示領域Ｄ１０には、星形アイコンＸ６が表示されており、星形アイコンＸ６を押下すると星形アイコンＸ６の色が変化してその企業を注目企業として選択することができる。図３０に示す例では、１位、３位、５位、９位、１１位、１４位の企業が注目企業として選択されている。なお、星形アイコンＸ６を再度押下することにより、注目企業としての選択を解除することができる。
企業名表示領域Ｄ１１には、企業名Ｘ７が表示される。企業名Ｘ７を押下することにより、当該企業の情報を表示する画面に切り替わるようになっている。企業情報の画面の詳細については後述する。
データ比較ボタン表示領域Ｄ１２には、データ比較ボタンＸ８が表示される。所定の企業のデータ比較ボタンＸ８を押下することにより、本人が所属する企業と、当該所定の企業とのデータを比較する画面が表示されるようになっている。データ比較画面の詳細については後述する。
企業ゴルフ熱表示領域Ｄ１３には、最新１２週分の企業ゴルフ熱が表示される。また、今週分の企業ゴルフ熱表示領域Ｄ１４には、今週分の企業ゴルフ熱が表示される。また、今週分の企業ゴルフ熱表示領域Ｄ１４には、ゲージＸ９が表示される。ゲージＸ９は、その企業の今週分の企業ゴルフ熱が、今週分の企業ゴルフ熱の最高ポイントに対して、どのくらいの割合であるかを示している。つまり、今週分の企業ゴルフ熱の最高ポイントを１００％とした場合に、その企業の今週分の企業ゴルフ熱が何％であるかを示している。本実施形態では、今週分の企業ゴルフ熱には所属人数指数を反映させていないが、他の実施形態においては所属人数指数を反映させた今週分の指数（ポイント）を表示したり、ゲージＸ９の表示としたりしてもよい。なお、ゲージＸ９は、静的に表示してもよいし、ゲージの長さが変化するように動的に表示してもよい。

＜２−６：注目企業の選択及び表示処理＞
注目企業の表示処理について説明する。上述したように、注目企業設定ボタン表示領域Ｄ１０に表示される星形アイコンＸ６が押下されると星形アイコンＸ６の色を例えば白色から黄色に変化させる。また、図３２に示すような注目企業テーブルＴＢＬ１６を用意しておき、星形アイコンＸ６を押下した本人の識別情報ＵＩＤ、当該星形アイコンＸ６に対応する企業の企業ＩＤ、当該企業の企業名を記録すると共に、有効フラグを「０」から「１」に変化させる。
また、前記星形アイコンＸ６が再度押下されると、当該星形アイコンＸ６の色を例えば黄色から白色に変化させる。そして、注目企業テーブルＴＢＬ１６における該当するレコードの有効フラグを「１」から「０」に変化させる。
所定の企業を初めて注目企業として選択する場合には、注目企業テーブルＴＢＬ１６には該当するレコードがないので、注目企業テーブルＴＢＬ１６に新たに登録すればよい。
なお、所定の企業を注目企業として選択した後に、星形アイコンＸ６を再度押下して注目企業としての選択を解除する場合には、該当するレコード自体を削除するようにしてもよい。
以上のようにして注目企業を選択した状態で、「注目企業」と表示されたタブＤ５を押下すると、図３１に示すように、注目企業として選択した企業のみのランキングが表示される。なお、この注目企業のランキング表示には、本人が所属する企業の表示領域Ｅ１が設けられる。本人が所属する企業の表示領域Ｅ１は、実際の順位に応じた位置であってもよいし、一番最後あるいは最初に表示するようにしてもよい。

＜２−７：順位変動の管理処理＞
本実施形態では、ランキングテーブルＴＢＬ１８には、図２９に示すように、ランキングを決定した週の週ＩＤ、企業ＩＤ、企業ゴルフ熱、今回の順位、前回の順位が記録される。
ランキング表示を行う際には、ランキングテーブルＴＢＬ１８に記録された今回の順位を参照するが、さらに、今回の順位と前回の順位とを比較することにより、順位変動の管理を行っている。
具体的には、前回よりも順位が上昇した場合には、上向きの矢印アイコンＸ５を表示させ、前回よりも順位が下降した場合には、下向きの矢印アイコンＸ５を表示させる。また、順位の変動がない時には、横向きの矢印アイコンＸ５を表示させる。
また、本実施形態においては、企業ゴルフ熱の順位の変動があった場合には、ゴルフ情報アプリケーションのウォール画面に書き込まれるようになっている。図３３にそのようなウォール画面の一例を示す。図３３に示すように、マイページの左下の部分には、ウォールアイコンＸ２０が表示されている。このウォールアイコンＸ２０を押下すると、図３３に示すようなウォール画面Ｐ４がポップアップ表示される。
ウォール画面Ｐ４には、ゴルフ友達のアクティビティについてのお知らせ欄Ｅ２の他、企業ゴルフ熱の変動があった場合には、企業ゴルフ熱のお知らせ欄Ｅ３が表示され、この企業ゴルフ熱のお知らせ欄Ｅ３にどのような順位変動があったのが書き込まれる。
図３３に示す例では、企業ゴルフ熱の変動があった企業名、抜いた企業の数または抜かれた企業の数、順位、抜いた企業または抜かれた企業の企業名、及び、順位リストの一部が表示される。さらに、順位変動のお知らせ文には、変動の要因になったパラメータについての表示が行われる。図３３に示す例では、要因として「結束力」が挙げられている。
また、企業ゴルフ熱のお知らせ欄Ｅ３には、いいねボタンＢ１９とコメントボタンＢ２０が表示されており、いいねボタンＢ１９またはコメントボタンＢ２０を押下することにより、ＳＮＳのマイページやタイムラインに、企業ゴルフ熱の変動のお知らせに対していいねを押下したこと、またはコメントを投稿したことが通知されるようになっている。

＜２−８：他企業とのデータ比較処理＞
図３０に示すランキング表示画面Ｐ２において、所定の企業のデータ比較ボタンＸ８を押下すると、図３４に示す企業データ比較画面Ｐ５がポップアップ表示される。
企業データ比較画面Ｐ５は、本人が所属する企業の企業名表示領域Ｅ４、当該企業のアイコン表示領域Ｅ５、当該企業のランキング表示領域Ｅ８、比較対象の企業の企業名表示領域Ｅ６、比較対象の企業のアイコン表示領域Ｅ７、比較対象の企業のランキング表示領域Ｅ９、及び、グラフ表示領域Ｅ１０を備えている。
グラフ表示領域Ｅ１０は、それぞれの企業のデータのうち、登録人数、結束力指数、ラウンド指数、スコアレベル、及び、アクティブ指数について最高値を５として、各企業の比率を計算し、それぞれの計算値を五角形のエリアにプロットした後、それぞれを結んだグラフが表示される。図３４に示す例では、グラフＥ１１が本人が所属する企業のグラフで、グラフＥ１２が比較対象の企業のグラフである。
登録人数、結束力指数、ラウンド指数、スコアレベル、及び、アクティブ指数については、図２８Ａ及び図２８Ｂに示す週次ポイントテーブルＴＢＬ１７を参照する。具体的には、まず、本人の所属する企業の企業ＩＤで週次ポイントテーブルＴＢＬ１７をソートし、そこから過去１２週分のデータを抽出して、登録人数、結束力指数、ラウンド指数、スコアレベル、及び、アクティブ指数のそれぞれを集計する。同様の処理を比較対象の企業についても行う。なお、スコアレベルは、週次ポイントテーブルＴＢＬ１７にスコアレベルとして記録されているデータを用いる。なお、登録人数は、週次ポイントテーブルＴＢＬ１７の所属人数のデータを用いる。
本実施形態の企業データ比較画面Ｐ５では、本人が所属する企業と比較対象の企業における所属人数、結束力指数、ラウンド指数、スコアレベル、及び、アクティブ指数を、グラフの形式で比較表示するので、比較対象の企業に対して優れている要素、または、劣っている要素がどの要素なのかを容易に把握することができる。

＜２−９：企業データ画面表示処理＞
本実施形態においては、図３０に示す全体のランキング表示画面、図３１に示す注目企業のランキング表示画面、及び、図３４に示す企業データ比較画面において、企業名または企業アイコンを押下すると、図３５に示す企業データ画面Ｐ６がポップアップ表示される。
企業データ画面Ｐ６は、企業名表示領域Ｅ１３、当該企業のアイコン表示領域Ｅ１４、登録人数表示領域Ｅ１３、ランキング表示領域Ｅ１４、企業データタブＥ１５、所属メンバータブＥ１６、メニューボタンＥ１７、ログインユーザー数表示領域Ｅ１８、近況報告数表示領域Ｅ１９、リアクション数表示領域Ｅ２０、及び、新規登録者数表示領域Ｅ２１を備えている。
登録人数表示領域Ｅ１３には、当該企業に所属しているゴルフ利用者の人数を表示する。具体的には、週次ポイントテーブルＴＢＬ１７を当該企業の企業ＩＤでソートした後、現在の週の週ＩＤのレコードを抽出し、そのレコードに記録されている所属人数を参照して表示を行う。
ランキング表示領域Ｅ１４には、当該企業の企業ゴルフ熱の順位を表示する。具体的には、ランキングテーブルＴＢＬ１８を企業ＩＤでソートした後、現在の週の週ＩＤのレコードを抽出し、今回の順位として記録されている順位を表示する。
メニューボタンＥ１７は、「今週の活動力」、「企業ゴルフ熱」、「年齢分布」、「性別分布」、「ラウンド頻度分布」、「平均スコア分布」、及び、「ゴルフ友達数分布」の７種類のボタンを備えている。図３５は「今週の活動力」のボタンが選択されている状態を示している。
ログインユーザー数表示領域Ｅ１８には、当該企業に所属しているゴルフ利用者のうち、当該週にログインしたゴルフ利用者の人数が表示される。具体的には、週次ポイントテーブルＴＢＬ１７を当該企業の企業ＩＤでソートした後、当該週の週ＩＤのレコードを抽出し、そのレコードに記録されているログイン数を参照して表示を行う。
近況報告数表示領域Ｅ１９には、当該企業に所属しているゴルフ利用者によって、当該週に近況報告を投稿した人数が延べ数で表示される。具体的には、週次ポイントテーブルＴＢＬ１７を当該企業の企業ＩＤでソートした後、当該週の週ＩＤのレコードを抽出し、そのレコードに記録されている近況報告数を参照して表示を行う。
リアクション数表示領域Ｅ２０には、当該週において、前記近況報告に対していいねを投稿した人数と、前記近況報告に対してコメントを投稿した人数の合計がリアクション数として表示される。具体的には、週次ポイントテーブルＴＢＬ１７を当該企業の企業ＩＤでソートした後、当該週の週ＩＤのレコードを抽出し、そのレコードに記録されているリアクション数を参照して表示を行う。
また、メニューボタンＥ１７の「企業ゴルフ熱」のボタンが押下された場合には、図３６に示すように企業ゴルフ熱の算出の基礎となった要素がゲージの形式で表示される。具体的には、ラウンドプレー指数表示領域Ｅ１８にラウンドプレー指数が表示され、結束力指数表示領域Ｅ１９に結束力指数が表示され、アクティブ指数表示領域Ｅ２０にアクティブ指数が表示される。
これら指数は、週次ポイントテーブルＴＢＬ１７を当該企業の企業ＩＤでソートした後、過去１２週分の週ＩＤのレコードを抽出し、ラウンドプレー指数、結束力指数、アクティブ指数をそれぞれ１２週分集計し、当該週において最高の値を記録した企業の値を１００として、それに対する割合として表示する。
なお、メニューボタンＥ１７の「年齢分布」のボタンが押下された場合には、当該企業に所属するゴルフ利用者の年齢分布を、例えば、２０代以下、３０代、４０代、５０代、６０代、７０代、８０代に分けて表示する。表示の形式としては、円グラフ等を用いることができる。年齢分布を算出する場合には、ゴルフ利用者情報テーブルＴＢＬ１１の中から、当該企業に所属するゴルフ利用者のレコードを抽出し、プロフィール情報として記録されている年齢の情報を参照すればよい。年齢分布の表示画面については図示を省略する。
メニューボタンＥ１７の「性別分布」のボタンが押下された場合には、当該企業に所属するゴルフ利用者の性別分布を、男性、女性、未定に分けて表示する。表示の形式としては、円グラフ等を用いることができる。性別分布を算出する場合には、ゴルフ利用者情報テーブルＴＢＬ１１の中から、当該企業に所属するゴルフ利用者のレコードを抽出し、プロフィール情報として記録されている性別の情報を参照すればよい。年齢分布の表示画面については図示を省略する。
メニューボタンＥ１７の「ラウンド頻度分布」のボタンが押下された場合には、当該企業に所属するゴルフ利用者のラウンド頻度分布を、例えば、年に２０回以上、１０回以上、５回以上、２・３回、１回、殆どないに分けて表示する。表示の形式としては、円グラフ等を用いることができる。ラウンド頻度分布を算出する場合には、ゴルフ利用者情報テーブルＴＢＬ１１の中から、当該企業に所属するゴルフ利用者のレコードを抽出し、ラウンド履歴情報として記録されているラウンド頻度の情報を参照すればよい。なお、ラウンド頻度の情報はランクで表示されているので、図６に示すラウンド頻度テーブルＴＢＬ１５ｃを参照すればよい。ラウンド頻度分布の表示画面については図示を省略する。
メニューボタンＥ１７の「平均スコア分布」のボタンが押下された場合には、当該企業に所属するゴルフ利用者の平均スコア分布を、例えば、６０〜８０、８１〜９０、９１〜１００、１０１〜１１０、１１１以上、未定に分けて表示する。表示の形式としては、円グラフ等を用いることができる。平均スコア分布を算出する場合には、ゴルフ利用者情報テーブルＴＢＬ１１の中から、当該企業に所属するゴルフ利用者のレコードを抽出し、ラウンド履歴情報として記録されている平均スコアの情報を参照すればよい。なお、平均スコアの情報はランクで表示されているので、図５に示す平均スコアテーブルＴＢＬ１５ｂを参照すればよい。平均スコア分布の表示画面については図示を省略する。
メニューボタンＥ１７の「ゴルフ友達数分布」のボタンが押下された場合には、当該企業に所属するゴルフ利用者のゴルフ友達数を算出し、その友達数の分布を、例えば、１０人未満、２０人未満、３０人未満、５０人未満、１００人未満、２００人未満、５００人未満、５０１人以上に分けて表示する。表示の形式としては、円グラフ等を用いることができる。当該企業に所属するゴルフ利用者のゴルフ友達数を算出する場合には、当該企業に所属するゴルフ利用者の識別情報ＵＩＤに基づいて、外部管理サーバ３に友達情報テーブルＴＢＬ３２の送信を要求し、受信した友達情報テーブルＴＢＬ３２から、前記識別情報ＵＩＤがアクション元又はアクション先として記録されているレコードを抽出し、ステータスとして「１」の承認が記録されているレコードをさらに抽出することにより前記ゴルフ利用者のＳＮＳ友達の識別情報ＵＩＤを取得することができる。そして、このようにして取得したＳＮＳ友達の識別情報ＵＩＤと、管理サーバ１の記憶部１５に記憶されているゴルフ利用者情報テーブルに登録されている識別情報ＵＩＤとが一致するレコードを抽出することにより、前記ゴルフ利用者のゴルフ友達の数を算出できる。
したがって、このような処理を、当該企業に所属する全てのゴルフ利用者について行うことにより、当該企業に所属するゴルフ利用者のゴルフ友達数分布を得ることができる。ゴルフ友達数分布については図示を省略する。

以上のように、本発明によれば、現実のゴルフを目的として集まっているゴルフ情報アプリケーションのゴルフ利用者に、企業ゴルフ熱によるランキング算出というゲーム要素を提供することができ、ゴルフ情報アプリケーション自体の興趣を高め、ゴルフ情報アプリケーションの利用を促進することかできる。
さらに、所属企業が同一の者であれば、ゴルフ友達になっていない者とも容易に交流することができ、積極的に交流を支援するサービスを提供することができる。

＜第２実施形態＞
上述した第１実施形態のサービス提供システム１００は、外部管理サーバ３においてＳＮＳ利用者の友達情報を管理し、管理サーバ１では友達情報を独自に管理していなかった。これに対して、第２実施形態のサービス提供システム１００は、管理サーバ１の代わりに管理サーバ１Ａを用いる点を除いて、図１に示す第１実施形態のサービス提供システム１００と同様である。

図３７に管理サーバ１Ａのブロック図を示す。管理サーバ１Ａは、記憶部１５にゴルフ友達情報テーブルＴＢＬ１２を備える点で、管理サーバ１と相違する。図３８にゴルフ友達情報テーブルＴＢＬ１２のデータ構造を示す。ゴルフ友達情報テーブルＴＢＬ１２には複数のレコードが記録されている。１つのレコードは、アクション元の識別情報、アクション先の識別情報、ステータス、及び申請日時を含む。アクション元は、ゴルフ友達申請を行ったゴルフ利用者であり、アクション先は、ゴルフ友達申請されたＳＮＳ利用者である。ステータスは、ゴルフ友達申請の状態を示し、申請中が「０」、承諾が「１」、タイムアウトが「２」で表される。

次に、第２実施形態に係る表示処理について説明する。第２実施形態では、図１１を参照して説明した第１実施形態と同様に、外部管理サーバ３から、本人のＳＮＳ友達及びＳＮＳ友達のＳＮＳ友達について識別情報ＵＩＤとＳＮＳ利用者情報を取得する。

管理サーバ１Ａは、所定のタイミングで、図１１に示すようにして取得した本人、本人のＳＮＳ友達、及びＳＮＳ友達のＳＮＳ友達についての識別情報ＵＩＤとＳＮＳ利用者情報、並びに、記憶部１５に記憶したゴルフ利用者情報テーブルＴＢＬ１１とに基づいて、ゴルフ友達情報テーブルＴＢＬ１２を作成し、記憶部１５に記憶する。
表示処理では、まず、図４０Ａに示すように本人のＳＮＳ友達とＳＮＳ友達のＳＮＳ友達とが特定される。図３９に管理サーバ１ＡのＣＰＵ３０が実行する表示情報生成処理の内容を示す。

ＣＰＵ３０は、ＳＮＳ友達又はＳＮＳ友達のＳＮＳ友達、且つゴルフ友達を抽出する（Ｓ２４０）。具体的には、第１に、ＣＰＵ３０は、本人の識別情報ＵＩＤをキーとして、当該識別情報ＵＩＤがアクション元又はアクション先となるレコードをゴルフ友達情報テーブルＴＢＬ１２から抽出し、ゴルフ友達の識別情報ＵＩＤを特定する。第２に、ＣＰＵ３０は、図１１に示すように外部管理サーバ３からＳＮＳ友達の識別情報ＵＩＤ又はＳＮＳ友達のＳＮＳ友達の識別情報ＵＩＤを取得し、取得したＳＮＳ友達の識別情報ＵＩＤ又はＳＮＳ友達のＳＮＳ友達の識別情報ＵＩＤと、ゴルフ友達の識別情報ＵＩＤとが一致するものを抽出し、抽出された識別情報ＵＩＤを表示対象のゴルフ友達とする。このように管理サーバ１Ａで管理するゴルフ友達を、外部管理サーバ３で管理するＳＮＳ友達でフィルタリングするのは、ゴルフの友達関係はＳＮＳの友達関係を前提するからである。例えば、ある時点で本人とＳＮＳ友達であったゴルフ友達について、時間が経過した後、本人とＳＮＳ上での友達関係が解消されたとする。この場合、ゴルフの友達関係が必ずしも解消されているとは限らない。そこで、ゴルフ友達をＳＮＳ友達でフィルタリングしたのである。この結果、図４０Ｂに示すように表示対象となるゴルフ友達が特定される。なお、同図に示す部分Ｆｘのゴルフ友達は、ＳＮＳ友達のＳＮＳ友達でもある。これは、ＳＮＳ友達のＳＮＳ友達であり、ゴルフ利用者に該当しないＳＮＳ利用者をゴルフ情報アプリケーションに招待することによって、本人と直接のゴルフ友達となることがあるからである。

この後、ＣＰＵ３０は、ＳＮＳ友達又はＳＮＳ友達のＳＮＳ友達、且つゴルフ友達のゴルフ友達を抽出する（Ｓ２４１）。具体的には、第１に、ＣＰＵ３０は、ゴルフ友達の識別情報ＵＩＤをキーとして、当該識別情報ＵＩＤがアクション元又はアクション先となるレコードをゴルフ友達情報テーブルＴＢＬ１２から抽出し、ゴルフ友達のゴルフ友達の識別情報ＵＩＤを特定する。第２に、ＣＰＵ３０は、図１１に示すように外部管理サーバ３からＳＮＳ友達の識別情報ＵＩＤ又はＳＮＳ友達のＳＮＳ友達の識別情報ＵＩＤを取得し、取得したＳＮＳ友達の識別情報ＵＩＤ又はＳＮＳ友達のＳＮＳ友達の識別情報ＵＩＤと、ゴルフ友達のゴルフ友達の識別情報ＵＩＤとが一致するものを抽出し、抽出された識別情報ＵＩＤを表示対象のゴルフ友達のゴルフ友達とする。この結果、図４０Ｃに示すように表示対象となるゴルフ友達のゴルフ友達が特定される。なお、同図に示す部分Ｆｙのゴルフ友達のゴルフ友達は、ＳＮＳ友達でもある。これは、ゴルフ友達と友達関係にあるゴルフ友達には、ＳＮＳ友達が含まれるからである。

このようにＣＰＵ３０は、Ｓ２４０及びＳ２４１を実行することにより、記憶部１５から読み出したゴルフ友達情報（第１特定関係情報の一例）と取得部１１で取得したＳＮＳ友達情報（第２特定関係情報の一例）とに基づいて、本人（所定の利用者の一例）と友達関係（特定の関係の一例）を有するＳＮＳ利用者（第２利用者の一例）であるＳＮＳ友達、及び当該ＳＮＳ利用者と更に友達関係を有するＳＮＳ利用者であるＳＮＳ友達のＳＮＳ友達を特定ＳＮＳ利用者としたとき、本人と友達関係を有するゴルフ利用者であり、且つ特定ＳＮＳ利用者である者をゴルフ友達（第１の特定利用者の一例）として特定し、ゴルフ友達と友達関係を有するゴルフ利用者であり、且つ特定ＳＮＳ利用者である者をゴルフ友達のゴルフ友達（第２の特定利用者の一例）として特定する特定部として機能する。

次に、ＣＰＵ３０は、関係図を表示させる表示情報を生成し（Ｓ２４２）、表示情報を端末装置２に送信する（Ｓ２４３）。表示情報の生成は、図１２を参照して説明したＳ１０９の処理と同様である。この結果、第２実施形態においても第１実施形態と同様に、図１４及び図１５に示すマイページを端末装置２のディスプレイ４５に表示させることができ、ゴルフ利用者は、ゴルフ友達の階層関係を容易に把握することが可能となる。

また、図３５に示すような企業データ表示画面において、「ゴルフ友達数分布」のボタンが押下された場合には、所定の企業に所属するゴルフ利用者の友達情報の送信を外部管理サーバ３に要求し、所定の企業に所属するゴルフ利用者のゴルフ友達を把握するが、このようにして把握した所定の企業に所属するゴルフ利用者のゴルフ友達をゴルフ友達情報テーブルＴＢＬ１２に記録させるようにしてもよい。

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

管理サーバ１Ａは、ゴルフ利用者情報テーブルＴＢＬ１１と、ゴルフ友達情報テーブルＴＢＬ１２と、利用者ログ管理テーブルＴＢＬ１３と、設定値管理マスターテーブルＴＢＬ１５と、週次ポイントテーブルＴＢＬ１７と、ランキングテーブルＴＢＬ１８と、注目企業テーブル１９とを記憶した記憶部１５を備える。また、記憶部１５には、管理サーバ１Ａを制御するプログラムが記憶されている。
管理サーバ１Ａは、本人（所定のゴルフ利用者）の端末装置２から本人の友達関係を表示する要求を受信すると、ゴルフ友達情報に基づいて、本人と友達関係を有するゴルフ友達（第１の特定利用者の一例）を抽出し、ゴルフ友達と友達関係を有するゴルフ友達のゴルフ友達（第２の特定利用者の一例）を抽出する第１抽出部１２と、記憶部１５に記憶されているゴルフ利用者の識別情報ＵＩＤ及び所属する企業情報等から、企業ごとにゴルフ利用者の識別情報ＵＩＤ等を抽出する第２抽出部１３と、第１抽出部１２で特定したゴルフ友達及びゴルフ友達のゴルフ友達の関連性を示す関係図を表示するために必要な情報、及び後述するゴルフ友達のゴルフ友達と本人とに共通のゴルフ友達を表示するために必要な情報を含む応答を本人の端末装置２に送信すると共に、企業のランキングに関する情報、企業ゴルフ熱に関する情報等を表示するために必要な情報を含む応答を本人の端末装置２に送信する表示制御部１７とを備える。
第１抽出部１２は、記憶部１５に記憶されているゴルフ利用者情報テーブルＴＢＬ１１及びゴルフ友達情報テーブルＴＢＬ１２を参照する。
この場合においても、管理サーバ１Ａは、第１実施形態において図１１を参照して説明したＳ１０９と同様に表示情報を生成する。この結果、第３実施形態においても第１実施形態と同様に、図１４及び図１５に示すマイページを端末装置２のディスプレイ２５に表示させることができ、ゴルフ利用者は、ゴルフ友達の階層関係を容易に把握することが可能となる。

また、本実施形態の場合には、ゴルフ利用者情報テーブルＴＢＬ１１に、ゴルフ利用者の所属する企業名を登録し、さらに企業名の登録の際に企業ＩＤを割り当てて登録するようにしてもよい。
企業名の入力の際には、人によって入力の仕方が異なる場合があるので、ゴルフ利用者が木企業名を入力している途中の段階で、企業データベースを検索し、一致または部分一致するものがあれば、その候補を入力欄の下にプルダウン表示し、そこから選択させるようにしてもよい。このように構成すれば入力される企業名をなるべく統一することができ、便宜である。

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

上述した実施形態では、ＳＮＳにログインした状態でゴルフ情報アプリケーションへ利用者登録を行おうとすると、外部管理サーバ３からＳＮＳ利用者本人の識別情報ＵＩＤを送信することとしているが、この送信の前に、管理サーバ１から外部管理サーバ３に対して、ＳＮＳ利用者本人の識別情報ＵＩＤを要求する信号を送信することとしてもよい。また、第１実施形態では、ＳＮＳにログインした状態でゴルフ情報アプリケーションへの利用者登録を行う場合を説明しているが、ＳＮＳにログインしていない状態でゴルフ情報アプリケーションへの利用者登録を可能とする場合は、例えばゴルフ情報アプリケーションのトップページでＳＮＳへのログインを要求するように構成することができる。

また、当該企業に属する新規登録者（新規ゴルフ利用者）が増えた場合には、図３３に示すようなウォール画面Ｐ４内に、例えば、「あなたの所属企業に、新たなゴルフ仲間が増えました！」のように表示させるようにしてもよい。また、図３３に示すようないいねボタンとコメントボタンを表示させ、いいねボタンまたはコメントボタンが押下されると、ＳＮＳのマイページやタイムラインに、新規登録者の増加のお知らせに対していいねを押下したこと、またはコメントを投稿したことが通知されるようにしてもよい。

また、上述した実施形態では、企業データの今週の活動力の項目の１つであるログインユーザ数については、週次ポイントテーブルＴＢＬ１７に記録されるログイン数（延べログイン数）を用いているが、当該週においてログインした人数を算出するように構成してもよい。具体的には、アクティビティテーブルＴＢＬ１５ｄにおいて、ログインを示す指標を設け、利用者ログ管理テーブルＴＢＬ１３においてゴルフ利用者のログインのログを管理する。そして利用者ログ管理テーブルＴＢＬ１３において、日時を示すフィールドＦ４の値が当該週に該当し、且つログインを示す指標がフィールドＦ３に記録されているレコードを抽出し、当該レコードのうち発信元を示すフィールドＦ１に記録されている識別情報ＵＩＤが重複している場合は重複分を削除する。更に残ったレコードについて、識別情報ＵＩＤに基づいてゴルフ利用者情報テーブルＴＢＬ１１を参照して企業ＩＤを特定し、企業ＩＤごとにログインを行った人数をカウントする。

また、上述した実施形態では、勤務先が未設定の場合に、図３０に示すランキング表示画面において本人の所属する企業の情報表示領域に、勤務先の登録を促す表示を行う例について説明したが、本発明はこのような例に限定されるものではない。例えば、ランキング表示画面を最初に表示させた時に、ＳＮＳにおいて勤務先の登録を行うことにより、本人の所属する企業がランキング表示される旨を伝える、勤務先の登録を促す表示をポップアップ表示などにより行うようにしてもよい。この場合には、勤務先設定ボタンを表示させ、本人が勤務先設定ボタンを押下すると、ＳＮＳの勤務先設定画面にジャンプするようにしてもよい。

図３５に示す企業データ表示画面Ｐ６において、所属メンバータブＥ１６が表示される例について説明したが、所属メンバータブＥ１６が押下された場合には、当該企業に所属するゴルフ利用者の一覧を表示させる所属メンバーリスト画面を表示させるようにしてもよい。この所属メンバーリスト画面においては、所属メンバーの名前とアイコンが一覧表示され、本人とゴルフ友達関係にあるかどうかについて表示するようにしてもよい。まだゴルフ友達ではない場合には、友達になるボタンを表示させて、ゴルフ友達の申請を送信できるようにしてもよい。また、所属メンバーのログ情報、ゴルフ友達関係、あるいは、プロフィールを表示させるようにしてもよい。

上述した実施形態では、１週間ごとに企業ゴルフ熱を算出して週次ポイントテーブルに記録する例について説明したが、ゴルフ利用者のアクティビティが行われる度にリアルタイムで週次ポイントテーブルへの記録を行うようにしてもよい。

また、企業データ比較画面では、登録人数、結束力指数、ラウンド指数、スコアレベル、及び、アクティブ指数について最高値を５として、各企業の比率を計算してグラフに表す相対評価を行う例について説明したが、絶対評価としてもよい。具体的には、各指数に複数の基準値を設け、最初の基準値を超えれば１、次の基準値を超えれば２のようにして５段階等の絶対評価としてもよい。

上述した実施形態では、企業ゴルフ熱を数値で表すようにしたが、画像で表すようにしてもよい。例えば、図４２Ａ、図４２Ｂ、図４２Ｃに示すように、企業ゴルフ熱の数値が大きくなるにしたがって、ビルの形状のアイコンが図４２Ａに示すアイコンＸ３０、図４２Ｂに示すアイコンＸ３１、そして、図４２Ｃに示すアイコンＸ３２のようにビルが成長するように表現してもよい。
また、企業ゴルフ熱のランキングを示すには、図３０のようなリスト形式のランキング表示に限られない。例えば、図４２Ａ、図４２Ｂ、図４２Ｃに示すようなビルのアイコンを、マップ状に配置して、他の企業のビルの高さの比較を画像として把握できるようにしてもよい。

また、上述した実施形態では、ゴルフ利用者を企業というグループごとに分類して、企業間のゴルフ熱を算出するようにしたが、例えば、出身大学というグループごとに分類して、出身大学間のゴルフ熱を算出するようにしてもよい。
さらに、上述した実施形態では、企業に所属するゴルフ利用者の人数の値を、週次ポイントテーブルに記録する例について説明したが、図４３に示すような利用者マスターテーブルＴＢＬ１５ｆを用いてランクを記録するようにしてもよい。

企業ゴルフ熱を算出する際には、性別や年齢に応じて企業ゴルフ熱に所定の係数を掛けるようにしてもよい。例えば、所定の企業に所属しているゴルフ利用者の女性比率がｘ％以上の場合には、企業ゴルフ熱を１．２倍にしたり、あるいは、女性のゴルフ利用者がｙ人以上だと企業ゴルフ熱を１．１倍にするようにしてもよい。さらに、図４４に示すような平均年齢のマスターテーブルＴＢＬ１５ｇを用意しておき、所定の企業に所属しているゴルフ利用者の平均年齢に応じた係数を企業ゴルフ熱に掛けるようにしてもよい。

ランキングを作成する際には、企業に所属するゴルフ利用者の人数に応じてランキングを分けて表示するようにしてもよい。例えば、所属人数が１００人以上、５１〜９９人、２６〜５０人、１１〜２５人、１０人以下の企業グループに分け、企業グループごとにランキングを表示するようにしてもよい。

上述した実施形態では、所属人数指数、ラウンドプレー指数、結束力指数、アクティブ指数の４つの要素に基づいて企業ゴルフ熱を算出するようにしたが、これらの要素のいずれか１つまたは２つ、あるいは３つを用いて企業ゴルフ熱を算出するようにしてもよい。

上述した実施形態では、アクティブ指数を算出する際に、ログイン回数、近況報告の件数、いいねの回数、コメントの回数を参照するようにしたが、これ以外にもゴルフに誘うというアクティビティの回数を参照するようにしてもよい。

また、企業ゴルフ熱を算出する際に、所属するゴルフ利用者の成長指数を参照するようにしてもよい。所属するゴルフ利用者の成長指数としては、所定期間におけるゴルフ利用者の増加率、所定期間においてログインするアクティブなゴルフ利用者の増加率等が考えられる。例えば、月ごとのゴルフ利用者の増加率は、次のようにして求められる。
（所定企業に所属するゴルフ利用者の月末の人数−所定企業に所属するゴルフ利用者の月初の人数）／所定企業に所属するゴルフ利用者の月末の人数×１００
また、アクティブなゴルフ利用者の増加率は、次のようにして求められる。
（所定企業に所属するゴルフ利用者の前月延べログイン回数−所定企業に所属するゴルフ利用者の前々月延べログイン回数）／所定企業に所属するゴルフ利用者の前月延べログイン回数×１００

また、上述した各実施形態では、管理サーバ１又は１Ａが提供するサービスとして、ゴルフ情報の提供サービスを一例として説明したが、本発明はこれに限定されるものではなく、管理サーバ１又は１Ａはどのようなサービスを提供するものであってもよい。例えば、利用者同士の共通のテーマに基づいて、アプリケーション上で特定の関係を構築するすべてのものに適用できる。共通のテーマは、マラソン、バドミントン等のスポーツ、将棋、ゲームや、将棋、ゲームなどの趣味的なものであってもよいし、ビジネスに関するものあってもよい。また、特定の関係は、友達関係に限定されない。例えば、上司と部下の関係であってもよいし、問屋と小売の関係であってもよい。要は、一定の規則に基づいて構築される関係であればどのようなものであってもよい。

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

ＮＥＴ……通信網、１，１Ａ……管理サーバ、２……端末装置、３……外部管理サーバ、１１……取得部、１２……第１抽出部、１３……第２抽出部、１４……算出部、１５……記憶部、１６……集計部、１７……表示制御部、２１……入力部、２２……通知部、２３……表示部。

Claims (11)

1. 所定のサービスを提供し、当該サービスを受ける利用者の端末装置と通信可能な管理装置であって、
   少なくとも前記利用者を一意に識別する識別情報と、前記利用者が属するグループに関する情報とを記憶可能な記憶部と、
   前記サービスにおける前記利用者の所定のアクティビティのレベルを所定の指標に基づいて算出する算出部と、
   前記利用者の前記アクティビティのレベルをグループごとに集計する集計部とを備える
   ことを特徴とする管理装置。
2. 第１サービスの提供を受ける第１利用者を含む第２利用者に対して第２サービスを提供すると共に、少なくとも前記第２利用者を一意に識別する第２識別情報と、前記第２利用者が属するグループに関する情報とを管理する外部管理装置と通信可能で、かつ、前記第１利用者の端末装置と通信可能な管理装置であって、
   少なくとも前記第１利用者を一意に識別する第１識別情報を記憶可能な記憶部と、
   前記第１サービスにおける前記第１利用者の所定のアクティビティのレベルを所定の指標に基づいて算出する算出部と、
   前記第１利用者の前記アクティビティのレベルをグループごとに集計する集計部とを備える
   ことを特徴とする管理装置。
3. 前記集計部により集計した前記グループごとの前記アクティビティのレベルに基づいて、前記グループをランキング表示させるための情報を前記端末装置に送信可能な表示制御部を更に備えることを特徴とする請求項１または請求項２に記載の管理装置。
4. 前記表示制御部は、前記ランキング表示させた前記グループのうちの少なくとも２つのグループの前記アクティビティのレベルを前記アクティビティの要素ごとに比較表示させることができる情報を前記端末装置に送信可能であることを特徴とする請求項３に記載の管理装置。
5. 前記表示制御部は、前記グループに対応する画像を表示させ、前記グループごとの前記アクティビティのレベルに対応させて当該画像を変化させることができる情報を前記端末装置に送信可能であることを特徴とする請求項３または請求項４に記載の管理装置。
6. 利用者にサービスを提供する管理装置と、当該管理装置と通信可能な当該利用者の端末装置とを備えるサービス提供システムであって、
   前記管理装置は、
   少なくとも前記利用者を一意に識別する識別情報と、前記利用者が属するグループに関する情報とを記憶可能な記憶部と、
   前記サービスにおける前記利用者の所定のアクティビティのレベルを所定の指標に基づいて算出する算出部と、
   前記利用者の前記アクティビティのレベルをグループごとに集計する集計部とを備え、
   前記端末装置は、
   前記利用者のアクティビティに関する情報を前記管理装置に通知する通知部を少なくとも備える
   ことを特徴とするサービス提供システム。
7. 第１サービスの提供を受ける第１利用者を含む第２利用者に対して第２サービスを提供すると共に、少なくとも前記第２利用者を一意に識別する第２識別情報と、前記第２利用者が属するグループに関する情報とを管理する外部管理装置と通信可能な管理装置と、当該管理装置と通信可能な前記第１利用者の端末装置とを備えるサービス提供システムであって、
   前記管理装置は、
   少なくとも前記第１利用者を一意に識別する第１識別情報を記憶可能な記憶部と、
   前記第１サービスにおける前記第１利用者の所定のアクティビティのレベルを所定の指標に基づいて算出する算出部と、
   前記第１利用者の前記アクティビティのレベルをグループごとに集計する集計部とを備え、
   前記端末装置は、
   前記利用者のアクティビティに関する情報を前記管理装置に通知する通知部を少なくとも備える
   ことを特徴とするサービス提供システム。
8. 所定のサービスを提供し、当該サービスを受ける利用者の端末装置と通信可能な管理装置の制御方法であって、
   少なくとも前記利用者を一意に識別する識別情報と、前記利用者が属するグループに関する情報とを記憶し、
   前記識別情報を読み出し、
   前記サービスにおける前記利用者の所定のアクティビティのレベルを所定の指標に基づいて算出し、
   前記利用者の前記アクティビティのレベルをグループごとに集計する、
   ことを特徴とする管理装置の制御方法。
9. 第１サービスの提供を受ける第１利用者を含む第２利用者に対して第２サービスを提供すると共に、少なくとも前記第２利用者を一意に識別する第２識別情報と、前記第２利用者が属するグループに関する情報とを管理する外部管理装置と通信可能で、かつ、前記第１利用者の端末装置と通信可能な管理装置の制御方法であって、
   少なくとも前記第１利用者を一意に識別する第１識別情報を記憶し、
   前記第１識別情報を読み出し、
   前記第１サービスにおける前記第１利用者の所定のアクティビティのレベルを所定の指標に基づいて算出し、
   前記第１利用者の前記アクティビティのレベルをグループごとに集計する、
   ことを特徴とする管理装置の制御方法。
10. 所定のサービスを提供し、当該サービスを受ける利用者の端末装置と通信可能でコンピュータを備える管理装置のプログラムであって、
    前記コンピュータを、
    少なくとも前記利用者を一意に識別する識別情報と、前記利用者が属するグループに関する情報とを記憶可能な記憶部と、
    前記サービスにおける前記利用者の所定のアクティビティのレベルを所定の指標に基づいて算出する算出部と、
    前記利用者の前記アクティビティのレベルをグループごとに集計する集計部として機能させる
    ことを特徴とする管理装置のプログラム。
11. 第１サービスの提供を受ける第１利用者を含む第２利用者に対して第２サービスを提供すると共に、少なくとも前記第２利用者を一意に識別する第２識別情報と、前記第２利用者が属するグループに関する情報とを管理する外部管理装置と通信可能で、かつ、前記第１利用者の端末装置と通信可能でコンピュータを備える管理装置のプログラムであって、
    前記コンピュータを、
    少なくとも前記第１利用者を一意に識別する第１識別情報を記憶可能な記憶部と、
    前記第１サービスにおける前記第１利用者の所定のアクティビティのレベルを所定の指標に基づいて算出する算出部と、
    前記第１利用者の前記アクティビティのレベルをグループごとに集計する集計部として機能させる
    ことを特徴とする管理装置のプログラム。

Images