(57)【要約】  管理サーバ（１）は、ゴルフ利用者に対してゴルフ情報サービスを提供する。管理サーバ（１）は、ログインしたゴルフ利用者と友達関係を有するゴルフ友達を特定する特定部（１１）と、特定したゴルフ友達の各々について、所定の判定タイミングにおいて、ゴルフ情報サービスを所定期間以上利用していない休眠利用者であるか否かを判定する判定部（１２）と、特定したゴルフ友達が休眠利用者である場合、所定の条件を充足すると、ログインしたゴルフ利用者に対して休眠利用者にゴルフ情報サービスの利用を促すメッセージを送信するように依頼する依頼部（１３）とを備える。
2014024597.tif 000002
【特許請求の範囲】
【請求項１】
利用者に対してサービスを提供する管理装置において、
所定の利用者と特定の関係を有する特定利用者を特定する特定部と、
特定した特定利用者の各々について、所定の判定タイミングにおいて、サービスを所定期間以上利用していない休眠利用者であるか否かを判定する判定部と、
特定した特定利用者が前記休眠利用者である場合、所定の条件を充足すると、前記所定の利用者に対して前記休眠利用者にサービスの利用を促すメッセージを送信するように依頼する依頼部とを備え、
前記所定の条件は、前記休眠利用者と特定の関係を有する利用者から成る特定グループに属する利用者から前記休眠利用者に対して所定期間内に送信した前記メッセージの総数が前記特定グループ全体として所定数を超えないことを含む、
ことを特徴とする管理装置。
【請求項２】
前記依頼部において、前記所定の条件は、前記所定の利用者に前記メッセージの送信を所定期間内に依頼していないことを含むことを特徴とする請求項１に記載の管理装置。
【請求項３】
前記所定の利用者は、サービスにログインした利用者であり、
前記特定部は、前記所定の利用者がログインする際に、当該所定の利用者と特定の関係を有する特定利用者を特定する、
ことを特徴とする請求項１又は２に記載の管理装置。
【請求項４】
前記所定の利用者を一意に識別する利用者識別情報と当該所定の利用者と特定の関係を有する特定利用者の前記利用者識別情報とを対応づけて記憶した特定関係テーブルと、
前記利用者識別情報と当該利用者識別情報を有する利用者の最終ログイン時刻とを対応づけて記憶する利用者情報テーブルとを備え、
前記特定部は、前記特定関係テーブルを参照して、ログインした前記所定の利用者の利用者識別情報と対応づけて記憶されている前記特定利用者の利用者識別情報を特定することによって、ログインした前記所定の利用者と特定の関係を有する特定利用者を特定し、
前記判定部は、前記利用者情報テーブルを参照して、特定した前記特定利用者の最終ログイン時刻から前記所定期間が経過した時刻が前記所定の判定タイミングよりも前である場合に、前記特定利用者を前記休眠利用者であると判定する、
ことを特徴とする請求項３に記載の管理装置。
【請求項５】
利用者に対してサービスを提供する管理装置の制御方法であって、
所定の利用者と特定の関係を有する特定利用者を特定し、
特定した特定利用者の各々について、所定の判定タイミングにおいて、サービスを所定期間以上利用していない休眠利用者であるか否かを判定し、
特定した特定利用者が前記休眠利用者である場合、所定の条件を充足すると、前記所定の利用者に対して前記休眠利用者にサービスの利用を促すメッセージを送信するように依頼し、
前記所定の条件は、前記休眠利用者と特定の関係を有する利用者から成る特定グループに属する利用者から前記休眠利用者に対して所定期間内に送信した前記メッセージの総数が前記特定グループ全体として所定数を超えないことを含む、
ことを特徴とする管理装置の制御方法。
【請求項６】
コンピュータを備え、利用者に対してサービスを提供する管理装置のプログラムであって、
前記コンピュータを、
所定の利用者と特定の関係を有する特定利用者を特定する特定部と、
特定した特定利用者の各々について、所定の判定タイミングにおいて、サービスを所定期間以上利用していない休眠利用者であるか否かを判定する判定部と、
特定した特定利用者が前記休眠利用者である場合、所定の条件を充足すると、前記所定の利用者に対して前記休眠利用者にサービスの利用を促すメッセージを送信するように依頼する依頼部として、
機能させ、
前記所定の条件は、前記休眠利用者と特定の関係を有する利用者から成る特定グループに属する利用者から前記休眠利用者に対して所定期間内に送信した前記メッセージの総数が前記特定グループ全体として所定数を超えないことを含む、
ことを特徴とする管理装置のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一定期間、サービスを利用していない利用者にサービスの利用を促す技術に関する。
【背景技術】
【０００２】
近年、インターネット上で提供するサービスが急速に普及している。この種のサービスは、利用者は管理サーバに一定の情報を登録して、サービスの提供が開始されるのが一般的である。利用者によっては、登録した直後にはサービスを頻繁に利用していても、次第に利用頻度が低下し、殆ど利用しなくなることもある。このように、所定期間、サービスを利用しない利用者は休眠利用者と呼ばれる。
オンラインゲームでは、休眠利用者を減らすために復帰キャンペーンが行われる。復帰キャンペーンでは、休眠利用者がオンラインゲームを再開すると、所定期間、無料でゲームをプレイできる権利が付与されることがある（非特許文献１参照）。かかる復帰キャンペーンの他にも、ゲーム内で休眠利用者に対して別の利用者から、復帰を促すメッセージを送信してもらい、メッセージを送信した利用者には、送信メッセージ数など所定の条件を充足することで特典を付与するタイプのものが存在する。
【先行技術文献】
【非特許文献】
【０００３】
【非特許文献１】石田賀津男、"NCJ、WIN「The Tower of AION」、「リネージュ2」新規・休眠ユーザーに21日間の無料プレイ権を提供"、［online］、2010年12月14日、［平成25年6月4日検索］、GAME Watch インターネット〈URL:http://game.watch.impress.co.jp/docs/news/20101214_414133.html〉
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、従来の復帰キャンペーンは、システム側から休眠利用者に対して何らかのインセンティブを付与することによってサービスに復帰させようとするものである。上述した例では、ゲームの無料期間が終了してしまうと、再び休眠利用者に戻ってしまう可能性が高い。また、ゲーム内で別の利用者からメッセージが送られてくる場合、休眠利用者は複数の者から何通も復帰を促すメッセージを受け取ることとなり、不快に思うこともあり得る。
本発明は、上述した事情に鑑みてなされたものであり、休眠利用者にサービスの利用を促すことなどを解決課題とする。
【課題を解決するための手段】
【０００５】
以上の課題を解決するために本発明が採用する手段を以下に説明する。なお、本発明の理解を容易にするために以下では図面の参照符号を便宜的に括弧書で付記するが、本発明を図示の形態に限定する趣旨ではない。【０００６】
上述した課題を解決するため、本発明に係る管理装置は、利用者に対してサービスを提供するものであって、所定の利用者と特定の関係を有する特定利用者を特定する特定部（１１）と、特定した特定利用者の各々について、所定の判定タイミングにおいて、サービスを所定期間以上利用していない休眠利用者であるか否かを判定する判定部（１２）と、特定した特定利用者が前記休眠利用者である場合、所定の条件を充足すると、前記所定の利用者に対して前記休眠利用者にサービスの利用を促すメッセージを送信するように依頼する依頼部（１３）とを備え、前記所定の条件は、前記休眠利用者と特定の関係を有する利用者から成る特定グループに属する利用者から前記休眠利用者に対して所定期間内に送信した前記メッセージの総数が前記特定グループ全体として所定数を超えないことを含む、ことを特徴とする。【０００７】
上述した管理装置において、前記依頼部（１３）において、前記所定の条件は、前記所定の利用者に前記メッセージの送信を所定期間内に依頼していないことを含むことが好ましい。【０００８】
上述した管理装置において、前記所定の利用者は、サービスにログインした利用者であり、前記特定部は、前記利用者がログインする際に、当該利用者と特定の関係を有する特定利用者を特定することが好ましい。【０００９】
上述した管理装置において、前記所定の利用者を一意に識別する利用者識別情報と当該所定の利用者と特定の関係を有する特定利用者の前記利用者識別情報とを対応づけて記憶した特定関係テーブル（ＴＢＬ１２）と、前記利用者識別情報と当該利用者識別情報を有する利用者の最終ログイン時刻とを対応づけて記憶する利用者情報テーブル（ＴＢＬ１１）とを備え、前記特定部は、前記特定関係テーブルを参照して、ログインした前記所定の利用者の利用者識別情報と対応づけて記憶されている前記特定利用者の利用者識別情報を特定することによって、ログインした前記所定の利用者と特定の関係を有する特定利用者を特定し、前記判定部は、前記利用者情報テーブルを参照して、特定した前記特定利用者の最終ログイン時刻から前記所定期間が経過した時刻が前記所定の判定タイミングよりも前である場合に、前記特定利用者を前記休眠利用者であると判定する、ことが好ましい。【００１０】
次に、本発明に係る管理装置の制御方法は、利用者に対してサービスを提供する管理装置の制御方法であって、所定の利用者と特定の関係を有する特定利用者を特定し、特定した特定利用者の各々について、所定の判定タイミングにおいて、サービスを所定期間以上利用していない休眠利用者であるか否かを判定し、特定した特定利用者が前記休眠利用者である場合、所定の条件を充足すると、前記所定の利用者に対して前記休眠利用者にサービスの利用を促すメッセージを送信するように依頼し、前記所定の条件は、前記休眠利用者と特定の関係を有する利用者から成る特定グループに属する利用者から前記休眠利用者に対して所定期間内に送信した前記メッセージの総数が前記特定グループ全体として所定数を超えないことを含む、ことを特徴とする。【００１１】
次に、本発明に係る管理装置のプログラムは、コンピュータを備え、利用者に対してサービスを提供する管理装置を制御するものであって、前記コンピュータ（３０）を、所定の利用者と特定の関係を有する特定利用者を特定する特定部（１１）と、特定した特定利用者の各々について、所定の判定タイミングにおいて、サービスを所定期間以上利用していない休眠利用者であるか否かを判定する判定部（１２）と、特定した特定利用者が前記休眠利用者である場合、所定の条件を充足すると、前記所定の利用者に対して前記休眠利用者にサービスの利用を促すメッセージを送信するように依頼する依頼部（１３）として、機能させ、前記所定の条件は、前記休眠利用者と特定の関係を有する利用者から成る特定グループに属する利用者から前記休眠利用者に対して所定期間内に送信した前記メッセージの総数が前記特定グループ全体として所定数を超えないことを含む、ことを特徴とする。
【図面の簡単な説明】
【００１２】
【図１】本発明の第１実施形態に係るサービス提供システムのブロック図である。
【図２】ＳＮＳ利用者とゴルフ利用者の関係を示す説明図である。
【図３】依頼部の復帰メッセージの依頼について説明するための説明図である。
【図４】ゴルフ利用者情報テーブルのデータ構造の一例を示す説明図である。
【図５】ゴルフ友達情報テーブルのデータ構造の一例を示す説明図である。
【図６】ＳＮＳ利用者情報テーブルのデータ構造の一例を示す説明図である。
【図７】ＳＮＳ友達情報テーブルのデータ構造の一例を示す説明図である。
【図８】管理サーバの構成を示すブロック図である。
【図９】端末装置の構成を示すブロック図である。
【図１０】メッセージ送信選択処理の処理内容を示すフローチャートである。
【図１１】メッセージ送信選択処理の処理内容を示すフローチャートである。
【図１２】復帰メッセージの送信依頼の画面例である。
【図１３】休眠処理の処理内容を示すフローチャートである。
【図１４】有効期限処理の処理内容を示すフローチャートである。
【図１５】本発明の第２実施形態に係るサービス提供システムのブロック図である。
【発明を実施するための形態】
【００１３】
以下、実施形態として、本発明に係る管理サーバを用いたサービス提供システムについて、図面を参照しつつ説明する。
＜第１実施形態＞
＜１．サービス提供システムの構成＞
図１は、本発明の実施形態に係るサービス提供システム１００のブロック図である。このサービス提供システム１００は、インターネットなどの通信網ＮＥＴを介して、ゴルフ情報サービスやコミュニティサービス等（以下、単に「ゴルフ情報サービス」と称する。）を提供する管理サーバ１、利用者の端末装置２、ＳＮＳサイトを提供する外部管理サーバ３を備える。以下の説明では、管理サーバ１のゴルフ情報サービスを利用する利用者をゴルフ利用者、外部管理サーバ３のＳＮＳの利用者をＳＮＳ利用者と称する。
外部管理サーバ３が提供するＳＮＳサイトは、利用者同士のコミュニケーションツール（すなわち、利用者の間で行われるメッセージ管理情報の授受。例えば、掲示板への投稿、メール、チャット等）を提供する。また、ＳＮＳサイトにおいて、友達関係は、アクション元のＳＮＳ利用者が友達申請を行い、これをアクション先のＳＮＳ利用者が承認することによって構築される。外部管理サーバ３は、ＳＮＳ利用者同士の特定の関係であるＳＮＳ友達関係を示す友達情報を管理する。
【００１４】
利用者の端末装置２は、通信網ＮＥＴを介した通信が可能であり、例えば、パーソナルコンピュータ、携帯電話機、スマートフォン、タブレット端末などが該当する。なお、以降の説明における「クリック」等の用語は、入力部としてタッチパネルを備える端末装置２にあっては「タッチ」を意味するものとする。
管理サーバ１は、特定のサービスを提供する。本実施形態の管理サーバ１は、ゴルフ情報サービスをゴルフ利用者に提供する。本実施形態では、ゴルフ情報サービスの提供を一例として説明するが、管理サーバ１は、ゲームなどのアプリケーションの提供サービス、ホテルの予約などを含む旅行情報の提供サービス、コンサート情報その他の各種情報の提供サービスなどを行うものであってもよい。すなわち、管理サーバ１は、利用者に所定の対象についてサービスを提供するものである。
【００１５】
外部管理サーバ３が提供するＳＮＳにおいては、掲示板、メール、チャット等を利用することができるだけでなく、ゲームや実用的なツールなどのソーシャルアプリケーションを利用することができる。このソーシャルアプリケーションは、ＳＮＳの提供者以外の提供者によっても提供されることがあり、ソーシャルアプリケーションを利用するか否か、あるいは、どのソーシャルアプリケーションを利用するかは、ＳＮＳ利用者が任意に決定できるようになっている。ＳＮＳ利用者がソーシャルアプリケーションの利用を希望する場合には、当該ソーシャルアプリケーションが当該ＳＮＳ利用者のプロフィール情報やＳＮＳ上の友達情報にアクセスする機能や、当該ソーシャルアプリケーションが当該ＳＮＳ利用者の代わりに掲示板等に投稿する機能等についての許可を求める場合がある。ソーシャルアプリケーションによっては、ＳＮＳ利用者がこれらの機能について許可したことを以て、当該ソーシャルアプリケーションの利用者になる場合がある。このようなソーシャルアプリケーションは、一般に、ＳＮＳサイト内に当該ソーシャルアプリケーションの画面が表示されるため、ＳＮＳ利用者にとっては、あたかもＳＮＳのサービスの一つを利用しているような感覚で、ソーシャルアプリケーションを利用することになる。
【００１６】
本実施形態の管理サーバ１によって提供されるゴルフ情報サービスは、一例として、上述のようなソーシャルアプリケーションにより提供されるサービスである。本実施形態においては、ＳＮＳ利用者がゴルフ情報アプリケーションの利用者であるゴルフ利用者になるためには、ゴルフ情報アプリケーションが当該ＳＮＳ利用者のプロフィール情報やＳＮＳ上の友達情報にアクセスする機能や、ゴルフ情報アプリケーションが当該ＳＮＳ利用者の代わりに掲示板等に投稿する機能等についての承認を行うようになっている。ＳＮＳ利用者がこの承認を行うことにより、当該ＳＮＳ利用者はゴルフ利用者となる。
【００１７】
ゴルフ利用者は、図２に示すようにＳＮＳ利用者に含まれる。換言すれば、管理サーバ１は、ゴルフ利用者にゴルフ情報サービスを提供し、外部管理サーバ３のＳＮＳ利用者に限って、管理サーバ１のゴルフ利用者として登録する。一方、外部管理サーバ３は、ゴルフ利用者を含むＳＮＳ利用者に対してＳＮＳを提供する。このように、ゴルフ利用者はＳＮＳ利用者に含まれるため、第１実施形態の管理サーバ１は、ゴルフ利用者の友達関係をＳＮＳ利用者の友達関係を用いて管理する。即ち、図２に示すように、本人とＳＮＳ友達であり、且つゴルフ利用者をゴルフ友達とし、ＳＮＳ友達のＳＮＳ友達であり、且つゴルフ利用者をゴルフ友達のゴルフ友達として管理する。また、ＳＮＳ友達であり、且つゴルフ利用者でない者を第１の外部特定利用者として管理し、ＳＮＳ友達のＳＮＳ友達であり、且つゴルフ利用者でない者を第２の外部特定利用者として管理する。
【００１８】
図１を参照して、管理サーバ１の機能を説明する。管理サーバ１は、ゴルフ利用者情報テーブルＴＢＬ１１と、ゴルフ友達情報テーブルＴＢＬ１２と、登録情報テーブルＴＢＬａ及び利用者ログ管理テーブルＴＢＬｂを含む活動データベースＤＢと、管理サーバ１を制御するプログラムとを記憶した記憶部１７を備える。
ゴルフ利用者情報テーブルＴＢＬ１１には、ゴルフ利用者を一意に識別する識別情報ＵＩＤなどが格納されている。活動データベースＤＢには、ゴルフ（所定の対象の一例）に関する活動を示す活動情報が記録されている。活動情報は、ゴルフの活動についてゴルフ利用者が管理サーバ１に登録した登録情報と、ゴルフ利用者のサービスの利用内容を示す利用情報とが含まれる。
登録情報テーブルＴＢＬａには登録情報がゴルフ利用者の識別情報ＵＩＤと対応づけて記録されている。登録情報には、ラウンド頻度、練習頻度、及び所有クラブなどが含まれる。
【００１９】
利用者ログ管理テーブルＴＢＬｂには、利用情報が記憶されている。ゴルフ利用者のサービスの利用内容には、様々なものが含まれる。例えば、あるゴルフ利用者がゴルフに行ってきたことやクラブの購入などをゴルフ報告として投稿したり、あるゴルフ利用者が他のゴルフ利用者の投稿に対してコメントしたり、あるいは、ゴルフニュースに対してコメントする場合、さらには、あるゴルフ利用者が他のゴルフ利用者をゴルフに誘うといったアクションがある。本実施形態では、各種のアクションの主体となるゴルフ利用者の識別情報ＵＩＤをアクション元識別情報UID_Fromと称し、アクションの相手方のゴルフ利用者の識別情報ＵＩＤをアクション先識別情報UID_Toと称する。利用者ログ管理テーブルＴＢＬｂには、アクション元識別情報UID_From、アクション先識別情報UID_To、及びアクションの内容を示す情報などが対応付けられて記録されている。なお、利用者ログ管理テーブルＴＢＬｂに記憶される各種の情報は、所定の保持期間（例えば、１２０日）を経過した後、削除してもよい。
ゴルフ利用者情報テーブルＴＢＬ１１及びゴルフ友達情報テーブルＴＢＬ１２については、後段で詳述する。
【００２０】
また、管理サーバ１は、所定のゴルフ利用者（例えば、ログインした利用者）と友達関係（特定の関係の一例）を有するゴルフ友達（特定利用者の一例）を特定する特定部１１を備える。所定のゴルフ利用者に対して複数のゴルフ友達がいることがある。
【００２１】
また、管理サーバ１は、判定部１２を備える。この判定部１２は、特定部１１で特定したゴルフ友達の各々について、所定の判定タイミングにおいて、サービスを所定期間以上利用していない休眠利用者であるか否かを判定する。より具体的には、全てのゴルフ利用者について、所定の判定タイミング（例えば、深夜等に行うバッチ処理）において、休眠利用者に該当するか否かを予め判定しておくことが好ましい。
【００２２】
また、管理サーバ１は、依頼部１３を備える。この依頼部１３は、特定したゴルフ友達が休眠利用者である場合、所定の条件を充足すると、所定の利用者に対して休眠利用者にサービスの利用を促すメッセージ（復帰メッセージ）を送信するように依頼する。これにより、休眠利用者に対して、システムからではなく、友達関係がある利用者からサービスの利用に復帰するように働きかけることができる。
ここで、所定の条件は、休眠利用者と友達関係を有する利用者から成る特定グループに属する利用者から当該休眠利用者に対して所定期間内に送信した、利用を促すメッセージの総数が特定グループ全体として所定数を超えないことを含む。
【００２３】
例えば、図３に示すようにゴルフ情報サービスにログインした所定のゴルフ利用者Ｕａには、ゴルフ友達ＧＦ１、ＧＦ２、及びＧＦ３がいるものとし、このうち、ゴルフ友達ＧＦ１は休眠利用者であるとする。
ゴルフ友達ＧＦ１、ＧＦ２、及びＧＦ３の各々には、ゴルフ友達が存在し、特定グループＧ１、Ｇ２及びＧ３が形成されている。特定グループＧ１は、休眠利用者であるゴルフ友達ＧＦ１を中心として、所定のゴルフ利用者Ｕａ、ゴルフ利用者Ｕｂ、及びゴルフ利用者Ｕｃが属している。
【００２４】
ここで、依頼部１３が、所定のゴルフ利用者Ｕａへ、休眠利用者ＧＦ１にゴルフ情報サービスの利用を促すメッセージを送信するように依頼する所定の条件は、特定グループＧ１に属するゴルフ利用者Ｕａ、Ｕｂ、及びＵｃが、休眠利用者ＧＦ１に対して所定期間内に利用を促すメッセージを送信していないことである。
【００２５】
ゴルフ情報サービスに限らず、何らかの情報を登録して提供されるサービスにおいては、サービスを利用しなくなった休眠利用者を復帰させるために、様々な対策が行われる。例えば、ゲームアプリケーションの提供サービスでは、休眠利用者がログインするとゲームに用いるアイテムを付与することが期間限定で行われることがある。また、このような復帰対策の一つとして、休眠利用者の友達が、休眠利用者に対して復帰を促すメッセージ（以下、「復帰メッセージ」と称する）を送ることも考えられる。
【００２６】
しかしながら、休眠利用者はサービスの提供を受けておらず、提供されるサービスに対して消極的である。一方、休眠利用者に多数の友達がいる場合、管理装置１において、復帰メッセージを送信するように休眠利用者の友達に依頼すると、休眠利用者は、同じような復帰メッセージを多数の友達から短期間に受け取ることがある。何らかの理由でサービスに消極的な休眠利用者にとって、短期間に多数の復帰メッセージを受け取ると、かえって興味が無くなることもある。
【００２７】
そこで、本実施形態においては、休眠利用者にとって復帰メッセージを受け取ることが負担にならず、且つ、確実に復帰を促せるように、特定グループに属するいずれかのゴルフ利用者が復帰メッセージを既に休眠利用者に送信している場合には、重ねて復帰メッセージを送信しないようにし、誰も復帰メッセージを送信していない場合に、システムから所定のゴルフ利用者に復帰メッセージの送信を依頼するようにした。これにより、休眠利用者が所定期間中に受け取る復帰メッセージは所定数（この例では１件）に制限されるので、休眠利用者の負担を軽減しつつ、サービスへの復帰を促すことができる。つまり、休眠利用者は、友達から誘われると、これが端緒となってサービスの利用を再開することがある一方、あまりに多数のメッセージを受け取ると、サービスに復帰する意欲が減退することが考えられる。しかし、本発明によれば、休眠利用者へのメッセージの送信と、メッセージを受け取ることによる休眠利用者の迷惑をバランスさせることが可能となる。
【００２８】
ところで、ログインした所定のゴルフ利用者に複数のゴルフ友達がいる場合、休眠利用者が多数いることもあり得る。このような場合、所定のゴルフ利用者に対して何度も復帰メッセージを依頼する可能性がある。所定のゴルフ利用者は、ゴルフ情報サービスを利用するためにログインするのであって、復帰メッセージを送信するのは本来の目的ではない。あまりに依頼が多いと、ゴルフ友達を作ることを躊躇するようになってしまう。このため、所定のゴルフ利用者の負担を軽減する観点から、復帰メッセージの送信依頼を制限する必要がある。そこで、依頼部１３において、所定の条件は、所定のゴルフ利用者に復帰メッセージの送信を所定期間内に依頼していないことを含むことが好ましい。この場合には、ログインした所定のゴルフ利用者が、所定期間内に復帰メッセージを休眠利用者のいずれかに送信していれば、所定期間内は同じゴルフ利用者に対して復帰メッセージの送信を依頼しないので、所定のゴルフ利用者の負担を軽減することができる。
【００２９】
図４にゴルフ利用者情報テーブルＴＢＬ１１のデータ構造を示す。ゴルフ利用者情報テーブルＴＢＬ１１には複数のレコードが記録されている。１つのレコードは、ゴルフ利用者を一意に識別する識別情報ＵＩＤ、受信フラグ、休眠フラグ、有効期限、処理日時、及び最終ログインを含む。なお、レコードは、これら以外の項目を含んでもよいことは勿論である。
本実施形態では、ゴルフ利用者の識別情報ＵＩＤは、ＳＮＳ利用者の識別情報ＵＩＤと一致する。但し、ＳＮＳ利用者の識別情報とゴルフ利用者の識別情報とは必ずしも一致する必要はなく、相違していてもよい。この場合は、ゴルフ利用者情報テーブルＴＢＬ１１のレコードにＳＮＳ利用者の識別情報とゴルフ利用者の識別情報とを対応づけて記録すればよい。
【００３０】
受信フラグは、識別情報ＵＩＤで特定されるゴルフ利用者が休眠利用者である場合において、所定期間内にゴルフ友達の誰かから復帰メッセージが送信された場合にＯＮ（＝１）となり、それ以外の場合にＯＦＦ（＝０）となる。従って、受信フラグを参照することによって、所定期間内に休眠利用者に復帰メッセージが送信されたか否か知ることが可能となる。
【００３１】
休眠フラグは、識別情報ＵＩＤで特定されるゴルフ利用者が、休眠利用者である場合にＯＮ（＝１）にセットされ、休眠利用者でない場合にＯＦＦ（＝０）にリセットされる。従って、休眠フラグを参照することによって、識別情報ＵＩＤで特定されるゴルフ利用者が、休眠利用者であるか否かを知ることができる。休眠フラグをオンに設定するかの判定は、後述の休眠処理で実行される。
【００３２】
次に、有効期限は、受信フラグ及び後述する処理フラグを有効とする期限を示す。本実施形態では、短期間に多数の復帰メッセージが休眠利用者に送信されるのを防止するため、受信フラグなどを参照して、復帰メッセージの送信依頼を行う。休眠利用者は、短期間に多数の復帰メッセージを受信すると辟易してしまうが、ある程度間隔が空けば、復帰メッセージを繰り返し受け取っても問題にならないと考えられる。そこで、本実施形態では、受信フラグ及び処理フラグを有効とする有効期限を設定し、有効期限が到来すると、受信フラグ及び処理フラグをＯＦＦにリセットしている。
【００３３】
次に、処理日時は、依頼部１３があるゴルフ利用者に対して復帰メッセージの送信を依頼した日時を示す。ゴルフ利用者は、送信依頼を受諾して休眠利用者に復帰メッセージを送信することもできるし、送信依頼を拒絶して休眠利用者に復帰メッセージを送信しないことも可能である。処理日時は、復帰メッセージの送信とは無関係である。処理日時を参照することによって、当該ゴルフ利用者に復帰メッセージを依頼した最新の日時を知ることができる。
【００３４】
次に、最終ログイン時刻は、ゴルフ利用者がゴルフ情報サービスにログインした最新の時刻を示している。最終ログイン時刻から現在時刻（所定の判定タイミングにおける時刻）までの期間に基づいて、当該ゴルフ利用者を休眠利用者と認定するか否かを判断することが可能となる。すなわち、ゴルフ利用者情報テーブルＴＢＬ１１は、識別情報ＵＩＤ（利用者識別情報の一例）と当該識別情報ＵＩＤを有するゴルフ利用者の最終ログイン時刻とを対応づけて記憶する。
【００３５】
図５にゴルフ友達情報テーブルＴＢＬ１２のデータ構造を示す。ゴルフ友達情報テーブルＴＢＬ１２には複数のレコードが記録されている。１つのレコードは、ゴルフ利用者の識別情報ＵＩＤと、当該ゴルフ利用者を中心とする特定グループに属するゴルフ友達の各々についての識別情報ＵＩＤと処理フラグとの組を対応づけている。
すなわち、ゴルフ友達情報テーブルＴＢＬ１２は、所定のゴルフ利用者を一意に識別する識別情報ＵＩＤ（利用者識別情報の一例）と当該所定のゴルフ利用者と友達関係（特定の関係の一例）を有するゴルフ友達（特定利用者の一例）の識別情報ＵＩＤとを対応づけて記憶する。
ここで、処理フラグは、依頼部３が、休眠利用者に対して復帰メッセージの送信を依頼するとＯＮ（＝１）にセットされる。処理フラグがＯＦＦ（＝０）にリセットされた状態は、当該休眠利用者に復帰メッセージの送信依頼がゴルフ友達に対してなされていないことを意味する。
【００３６】
次に、外部管理サーバ３が備えるＳＮＳ利用者情報テーブルＴＢＬ３１とＳＮＳ友達情報テーブルＴＢＬ３２について説明する。図６にＳＮＳ利用者情報テーブルＴＢＬ３１のデータ構造を示し、図７にＳＮＳ友達情報テーブルＴＢＬ３２のデータ構造を示す。ＳＮＳ利用者情報テーブルＴＢＬ３１には複数のレコードが記録されている。１つのレコードは、氏名、性別、住所、勤務先、趣味、ＳＮＳ利用者を一意に識別する識別情報ＵＩＤ（当該ＳＮＳにおいてアカウントとして機能する）、及びメールアドレスを含む。識別情報ＵＩＤ以外のこれらの情報は、ＳＮＳ利用者が登録した個人情報である。ＳＮＳ利用者情報テーブルＴＢＬ３１を参照することによって、例えば、「浜市子」の趣味は「ゴルフ」であることが分かる。ＳＮＳ利用者情報テーブルＴＢＬ３１に記録される個人情報は、ＳＮＳ利用者が外部管理サーバ３に対して提供した提供情報に該当する。
【００３７】
次に、ＳＮＳ友達情報テーブルＴＢＬ３２には複数のレコードが記録されている。１つのレコードは、アクション元の識別情報、アクション先の識別情報、ステータス、及び申請日時を含む。アクション元は、友達申請を行ったＳＮＳ利用者であり、アクション先は、友達申請されたＳＮＳ利用者である。ステータスは、友達申請の状態を示し、申請中が「０」、承諾が「１」、拒否が「２」、タイムアウトが「３」で表される。タイムアウトとは、申請日時から所定期間が経過しても、アクション先のＳＮＳ利用者が、友達申請を承諾するか拒否するかを明らかにしない場合である。図７に示す例では、ＵＩＤが「0zz99x999」のＳＮＳ利用者は、ＵＩＤが「6zz99x999」のＳＮＳ利用者に友達申請を行い、承諾されている。
【００３８】
友達関係を記憶する場合に、アクション元（申請元）とアクション先（申請先）を分けて記憶したのは、記憶容量を削減する利点がある。仮に、あるＳＮＳ利用者の識別情報ＵＩＤと当該ＳＮＳ利用者と友達関係にある全てのＳＮＳ利用者の識別情報ＵＩＤとを対応づけて記憶したとすると、２倍の記憶容量が必要となる。例えば、ＳＮＳ利用者ａがアクション元でありＳＮＳ利用者ｂがアクション先であるとする。各ＳＮＳ利用者ごとに友達関係にあるＳＮＳ利用者の識別情報を記憶する場合には、利用者ａについて利用者ｂが友達関係にあることを記憶し、さらに、利用者ｂについて利用者ａが友達関係にあることを記憶する必要がある。これに対して、本実施形態では、アクション先の識別情報とアクション元の識別情報とを対応づけて１つのレコードに記憶するので記憶容量を半分にすることができる。また、ステータスを更新する場合でも半分の処理となる。
【００３９】
図８に管理サーバ１の構成を示す。この図に示すように、管理サーバ１は、装置全体を制御するＣＰＵ（Central Processing Unit）３０、ＣＰＵ３０の作業領域として機能するＲＡＭ（Random Access Memory）３１、ブートプログラムなどを記憶したＲＯＭ（Read Only Memory）３２、各種のプログラムやデータを記憶するハードディスク３３、キーボードやマウスなどを含む入力部３４、画像を表示するディスプレイ３５、通信網ＮＥＴを介して外部の装置と通信を行う通信インターフェース３６、及びコンパクトディスクなどの情報記録媒体を読み取る読取装置３７を備える。ハードディスク３３は、上述した記憶部１７に相当し、ゴルフ利用者情報テーブルＴＢＬ１１、ゴルフ友達情報テーブルＴＢＬ１２、活動データベースＤＢの他、管理サーバ１全体を制御するプログラムを格納する。ＣＰＵ３０は、上述した特定部１１、判定部１２、及び依頼部１３として機能する。
なお、外部管理サーバ３も管理サーバ１と同様に構成されている。但し、外部管理サーバ３のハードディスク３３には、ＳＮＳ利用者情報テーブルＴＢＬ３１及びＳＮＳ友達情報テーブルＴＢＬ３２が格納される。
【００４０】
図９に端末装置２の構成を示す。端末装置２は、装置全体を制御するＣＰＵ２０、ＣＰＵ２０の作業領域として機能するＲＡＭ２１、ブートプログラムや装置全体を制御する制御プログラムなどを記憶したＲＯＭ２２、各種のプログラムやデータを記憶する記憶装置２３、テンキーなどを含む入力部２４、画像を表示するディスプレイ２５、及び通信網ＮＥＴを介して外部の装置と通信を行う通信インターフェース２６を備える。
【００４１】
＜２．サービス提供システムの動作＞
サービス提供システム１００において、休眠利用者を復帰させるための各種について説明する。このような処理としては、メッセージ送信選択処理、休眠処理、及び有効期限処理がある。
【００４２】
＜２−１．メッセージ送信選択処理＞
メッセージ送信選択処理は、ゴルフ利用者がゴルフ情報サービスにログインする度に実行される。図１０及び図１１にメッセージ送信選択処理の処理内容を示す。
まず、ゴルフ利用者が端末装置２を用いて、ゴルフ情報サービスにアクセスすると、管理装置１のＣＰＵ３０は、ログイン処理を実行する（Ｓ１００）。具体的には、ＣＰＵ３０はパスワードなどの認証を行う。アクセスした者が正当なゴルフ利用者である場合、ＣＰＵ３０は当該ゴルフ利用者の識別情報ＵＩＤを取得する。
【００４３】
この後、ＣＰＵ３０は、当該ゴルフ利用者について、現在時刻が処理日時から所定期間が経過したか否かを判定する（Ｓ１１０）。具体的には、ＣＰＵ３０は、ゴルフ利用者情報テーブルＴＢＬ１を参照して、ログインしたゴルフ利用者の識別情報ＵＩＤに対応する処理日時を取得し、処理日時から所定期間が経過しているか否かを判定する。所定期間は、例えば、１日である。処理日時から所定期間が経過していない場合、ステップＳ１１０の判定結果は「ＮＯ」となり、ＣＰＵ３０はメッセージ送信選択処理を終了させる。一方、所定日時から所定期間が経過している場合、ステップＳ１１０の判定結果は「ＹＥＳ」となり、ＣＰＵ３０は処理をステップＳ１２０に進める。
【００４４】
ここで、処理日時は、前述したように依頼部１３が復帰メッセージの送信を当該ゴルフ利用者に依頼した日時である。処理日時から所定期間が経過していない場合には、メッセージ送信選択処理を終了させるので、ログインしたゴルフ利用者は、システムから復帰メッセージの送信依頼があると、それから所定期間を経過するまでは、再度の復帰メッセージの送信依頼はないので、同じゴルフ利用者に対して繰り返し送信依頼を行うことを防止できる。
【００４５】
ＣＰＵ３０は、ステップＳ１２０において、ログインしたゴルフ利用者の休眠フラグがＯＮであるか否かを判定する。具体的には、ＣＰＵ３０は、ゴルフ利用者情報テーブルＴＢＬ１１を参照し、ログインしたゴルフ利用者の識別情報ＵＩＤと対応づけて記憶されている休眠フラグを読み出して判定を行う。休眠フラグがＯＮである場合には（Ｓ１２０：ＹＥＳ）、休眠フラグをＯＦＦにリセットする（Ｓ１３０）。
【００４６】
一方、休眠フラグがＯＦＦの場合（Ｓ１２０：ＮＯ）、ＣＰＵ３０は変数ｎを「０」に設定し（Ｓ１４０）、ログインしたゴルフ利用者のゴルフ友達を特定する（Ｓ１５０）。上述したように、ゴルフ友達情報テーブルＴＢＬ１２（特定関係テーブルの一例）には、各ゴルフ利用者（所定の利用者の一例）の識別情報ＵＩＤ（利用者識別情報の一例）と友達関係（特定の関係の一例）にあるゴルフ友達（特定利用者の一例）の識別情報ＵＩＤなどが記憶されている。ゴルフ友達の特定は、ＣＰＵ３０がゴルフ友達情報テーブルＴＢＬ１２を参照することにより行う。
すなわち、特定部１１による特定処理の対象となるゴルフ利用者は、サービスにログインした利用者であり、ＣＰＵ３０は、ゴルフ利用者がログインする際に、当該ゴルフ利用者とゴルフ情報サービスにおける友達関係を有するゴルフ友達を特定する特定部１１として機能する。具体的には、ゴルフ友達情報テーブルＴＢＬ１２を参照して、ログインしたゴルフ利用者の識別情報ＵＩＤと対応づけて記憶されているゴルフ友達の識別情報ＵＩＤを特定することによって、ログインしたゴルフ利用者と友達関係を有するゴルフ友達を特定する特定部１１として機能する。
【００４７】
管理サーバ１では、特定部１１におけるゴルフ友達の特定→判定部１２における休眠利用者の判定→所定の条件を充足→依頼部１３におけるメッセージ依頼といった処理を実行する。すなわち、これらの一連の処理の開始は、特定部１１におけるゴルフ友達の特定であるところ、本実施形態によれば、全てのゴルフ利用者について、ログイン時にゴルフ友達を特定して、休眠利用者への復帰を促すメッセージの送信依頼を当該ゴルフ利用者に対して行うか否かを決定する。ログイン中にゴルフ利用者に対して送信を依頼する方がログインしていないゴルフ利用者に対して送信を依頼するよりも効率が良い。さらに、休眠利用者と友達関係にあるゴルフ友達が複数いる場合、各ゴルフ友達のログイン時に一連の処理を実行することによって、休眠利用者に対して迅速にメッセージを送信することが可能となる。
【００４８】
ここで、ゴルフ友達数を「ｘ」とすると、ＣＰＵ３０は、変数ｎにゴルフ友達数ｘを設定し、ゴルフ友達の一人を特定する（Ｓ１６０）。この後、ＣＰＵ３０は、特定したゴルフ友達の休眠フラグがＯＮであるか否かを判定する（Ｓ１７０）。具体的には、ＣＰＵ３０は、ゴルフ利用者情報テーブルＴＢＬ１１を参照して、ゴルフ友達の識別情報ＵＩＤに対応する休眠フラグを読み出す。休眠フラグがＯＦＦである場合には（Ｓ１７０：ＮＯ）、当該ゴルフ友達には復帰メッセージを送信する必要がないので、ＣＰＵ３０は、ステップＳ１８０〜Ｓ２５０の処理を飛ばして処理をステップＳ２６０に進める。
【００４９】
休眠フラグが「ＯＮ」である場合、すなわち、ログインしたゴルフ利用者のゴルフ友達が休眠利用者である場合、Ｓ１７０の判定結果は「ＹＥＳ」となり、ＣＰＵ３０は、ゴルフ友達の受信フラグが「ＯＮ」であるか否かを判定する（Ｓ１８０）。具体的には、ＣＰＵ３０は、ゴルフ利用者情報テーブルＴＢＬ１１を参照して、ゴルフ友達の識別情報ＵＩＤに対応する受信フラグを読み出す。ゴルフ友達の受信フラグは、休眠利用者であり、且つ、所定期間以内にゴルフ友達から復帰メッセージが送信された場合に「ＯＮ」となる。ゴルフ友達の受信フラグが「ＯＮ」である場合は（Ｓ１８０：ＹＥＳ）、既に、復帰メッセージが当該ゴルフ友達に送信されているので、当該ゴルフ友達に復帰メッセージを送信する必要がない。そこで、ＣＰＵ３０は、ステップＳ１９０〜Ｓ２５０の処理を飛ばして処理をステップＳ２６０に進める。
【００５０】
ゴルフ友達の受信フラグが「ＯＦＦ」である場合（Ｓ１８０：ＮＯ）、ＣＰＵ３０は、当該ゴルフ友達についてログインしたゴルフ利用者の処理フラグがＯＮであるか否かを判定する（Ｓ１９０）。具体的には、ＣＰＵ３０は、ゴルフ友達情報テーブルＴＢＬ１２を参照して、特定したゴルフ友達（休眠利用者）の識別情報ＵＩＤと一致するゴルフ利用者の識別情報ＵＩＤのレコードを特定する。そして、ＣＰＵ３０は、当該レコードの特定グループを構成するゴルフ友達の識別情報ＵＩＤのうち、ログインしたゴルフ利用者の識別情報ＵＩＤと一致するものを特定し、特定したゴルフ友達識別情報ＵＩＤと組になっている処理フラグを読み出す。処理フラグがＯＮの場合には（Ｓ１９０：ＹＥＳ）、ログインしたゴルフ利用者が、ゴルフ友達である休眠利用者に対して復帰メッセージの送信を所定期間内に既に依頼されている場合である。この場合は、ログインしたゴルフ利用者に再度の依頼とならないように、ＣＰＵ３０は、ステップＳ２００〜Ｓ２５０の処理を飛ばして処理をステップＳ２６０に進める。
【００５１】
一方、ログインしたゴルフ利用者の処理フラグがＯＦＦである場合には（Ｓ１９０：ＮＯ）、ＣＰＵ３０は復帰メッセージを送信するようにゴルフ利用者に依頼する（Ｓ２００）。具体的には、ＣＰＵ３０は、例えば、ログインしたゴルフ利用者の端末装置２のディスプレイに、図１２に示す画面を表示させる表示情報を生成し、当該端末装置２に送信する。この場合、ゴルフ利用者がボタンＢ１をクリックすれば、コメント欄Ａ１に記載された復帰を促す復帰メッセージが休眠利用者に対して送信される。一方、ボタンＢ２がクリックされると、復帰メッセージは送信されない。なお、メッセージはメールであってもよいし、休眠利用者のＳＮＳのマイページへの投稿であってもよい。
【００５２】
この後、ＣＰＵ３０は選択受付処理を実行する（Ｓ２１０）。すなわち、依頼に対するログインしたゴルフ利用者の対応を受け付ける。上述した例では、ボタンＢ１又はボタンＢ２のクリックである。次に、ＣＰＵ３０は、送信依頼したゴルフ利用者が復帰メッセージを送信したか否かを判定する（Ｓ２２０）。復帰メッセージを送信しなかった場合（Ｓ２２０：ＮＯ）、処理はステップＳ２４０に進む。
一方、復帰メッセージを送信した場合（Ｓ２２０：ＹＥＳ）、ＣＰＵ３０は、復帰メッセージが送信先である休眠利用者の受信フラグをオンにセットする（Ｓ２３０）。具体的には、ＣＰＵ３０は、ゴルフ利用者情報テーブルＴＢＬ１１において、休眠利用者であるゴルフ友達の識別情報ＵＩＤを有するレコードを特定し、当該レコードに記録される受信フラグをＯＮにセットする。
【００５３】
次に、ＣＰＵ３０は、処理日時をゴルフ利用者情報テーブルＴＢＬ１１に記憶する（Ｓ２４０）。具体的には、ＣＰＵ３０は、ゴルフ利用者情報テーブルＴＢＬ１１において、復帰メッセージの送信依頼をしたゴルフ利用者の識別情報ＵＩＤに対応づけて現在時刻を処理日時として記憶する。なお、処理日時は、復帰メッセージの送信の有無にかかわらず、送信依頼した場合に記録される。
【００５４】
次に、ＣＰＵ３０は、処理フラグをＯＮにセットする（Ｓ２５０）。具体的には、ゴルフ友達情報テーブルＴＢＬ１２において、休眠利用者のレコードの特定グループに属するゴルフ友達識別情報ＵＩＤのうち、送信を依頼したゴルフ利用者の識別情報ＵＩＤと一致するゴルフ友達識別情報ＵＩＤを特定し、当該ゴルフ友達識別情報ＵＩＤと組になる処理フラグをＯＮにセットする。
【００５５】
次に、ＣＰＵ３０は、変数ｎを「１」だけデクリメントし（Ｓ２６０）、変数ｎが０より大きいか判定する（Ｓ２７０）。変数ｎが１以上であり０より大きい場合には（Ｓ２７０：ＹＥＳ）、ＣＰＵ３０は、次のゴルフ友達を特定し（Ｓ２８０）、処理をステップＳ１７０に戻す。一方、変数ｎが０の場合には（Ｓ２７０：ＮＯ）、メッセージ送信選択処理を終了する。
【００５６】
＜２−２．休眠処理＞
休眠処理は、所定タイングで実行されるバッチ処理である。例えば、午前３時といったゴルフ情報サービスの利用が少ない時間帯に実行される。図１３に休眠処理の処理内容を示す。
まず、ＣＰＵ３０は変数ｎを「０」に設定し（Ｓ３００）、全てのゴルフ利用者の数を計数する（Ｓ３１０）。具体的には、ＣＰＵ３０は、ゴルフ利用者情報テーブルＴＢＬ１１を参照し、ゴルフ利用者数を計数する。ここで、ゴルフ利用者数を「ｙ」とすると、ＣＰＵ３０は、変数ｎにゴルフ利用者数ｙを設定し、ゴルフ利用者の一人を特定する（Ｓ３２０）。
【００５７】
この後、ＣＰＵ３０は、特定したゴルフ利用者の休眠フラグがＯＮであるか否かを判定する（Ｓ３３０）。具体的には、ＣＰＵ３０は、ゴルフ利用者情報テーブルＴＢＬ１１を参照して、特定したゴルフ利用者の識別情報ＵＩＤに対応する休眠フラグを読み出す。休眠フラグがＯＮである場合には（Ｓ３３０：ＹＥＳ）、休眠フラグをＯＮに設定するための判定を実行する必要はないのでステップＳ３４０〜Ｓ３６０の処理を省略し、処理をＳ３７０に進める。
【００５８】
休眠フラグが「ＯＦＦ」である場合、Ｓ３３０の判定結果は「ＮＯ」となり、ＣＰＵ３０は、当該ゴルフ利用者の最終ログイン時刻から所定期間が経過したか否かを判定する（Ｓ３４０）。具体的には、ＣＰＵ３０は、ゴルフ利用者情報テーブルＴＢＬ１１（利用者情報テーブルの一例）を参照して、ゴルフ利用者の識別情報ＵＩＤに対応する最終ログイン時刻を読み出し、現在時刻（所定の判定タイミングの一例）が最終ログイン時刻から所定期間経過したか否かを判定する（Ｓ３４０）。休眠判定の基準となる所定期間は、例えば３カ月である。所定期間が経過している場合、判定結果は「ＹＥＳ」となる。
すなわち、ＣＰＵ３０は、ゴルフ利用者情報テーブルＴＢＬ１１を参照して、最終ログイン時刻から所定期間が経過した時刻が現在時刻よりも前である場合に、休眠利用者であると判定する判定部１２として機能する。つまり、判定部１２は、最終ログイン時刻から所定期間が経過した利用者を休眠利用者として取り扱う。
【００５９】
この場合（Ｓ３４０：ＹＥＳ）、ＣＰＵ３０は特定したゴルフ利用者の休眠フラグをＯＮに設定し（Ｓ３５０）、更に、有効期限を設定して（Ｓ３６０）、ゴルフ利用者情報テーブルＴＢＬ１１を更新する。ここで、有効期限は、セットされた受信フラグ及び処理フラグをリセットする期限を定めたものであり、有効期限が到来するまでは受信フラグ及び処理フラグは有効とされる。例えば、現在時刻に２週間を加えた日時を有効期限としてもよい。
所定期間が経過していない場合、ステップＳ３４０の判定結果は「ＮＯ」となり、処理はステップＳ３７０に進む。
【００６０】
次に、ＣＰＵ３０は、変数ｎを「１」だけデクリメントし（Ｓ３７０）、変数ｎが０より大きいか判定する（Ｓ３８０）。変数ｎが１以上であり０より大きい場合には（Ｓ３８０：ＹＥＳ）、ＣＰＵ３０は、次のゴルフ利用者を特定し（Ｓ３９０）、処理をステップＳ３３０に戻す。一方、変数ｎが０の場合には（Ｓ３８０：ＮＯ）、休眠処理を終了する。
【００６１】
＜２−３．有効期限処理＞
有効期限処理は、所定タイングで実行されるバッチ処理である。例えば、休眠処理と同様に、午前３時といったゴルフ情報サービスの利用が少ない時間帯に実行される。図１４に有効期限処理の処理内容を示す。
まず、ＣＰＵ３０は、ゴルフ利用者情報テーブルＴＢＬ１１を参照して、休眠フラグがＯＮに設定されているゴルフ利用者を抽出する（Ｓ４００）。この後、ＣＰＵ３０は休眠利用者の数を計数する（Ｓ４１０）。
【００６２】
次に、ＣＰＵ３０は、変数ｎに休眠利用者数ｚを設定し、休眠利用者の一人を特定する（Ｓ４２０）。この後、ＣＰＵ３０は、特定した休眠利用者の有効期限が到来したか否かを判定する（Ｓ４３０）。具体的には、ＣＰＵ３０は、ゴルフ利用者情報テーブルＴＢＬ１１を参照して、休眠利用者の識別情報ＵＩＤに対応する有効期限を読み出す。現在時刻が読み出した有効期限を経過していない場合には（Ｓ４３０：ＮＯ）には、処理はステップＳ４６０に進む。
【００６３】
一方、現在時刻が読み出した有効期限を経過している場合には（Ｓ４３０：ＹＥＳ）、受信フラグと処理フラグを「ＯＦＦ」にリセットする（Ｓ４４０）。具体的には、ＣＰＵ３０は、ゴルフ利用者情報テーブルＴＢＬ１１を参照して、休眠利用者の識別情報ＵＩＤに対応する受信フラグをＯＦＦにリセットする。また、ＣＰＵ３０は、ゴルフ友達情報テーブルＴＢＬ１１を参照して、休眠利用者の識別情報ＵＩＤに対応する特定グループに属する処理フラグを全てＯＦＦにリセットする。次に、ＣＰＵ３０は、新有効期限を設定する（Ｓ４５０）。すなわち、新有効期限が設定された以降に「オン」となった受信フラグ又は処理フラグは、当該新有効期限が経過するとＯＦＦにリセットされることとなる。
【００６４】
次に、ＣＰＵ３０は、変数ｎを「１」だけデクリメントし（Ｓ４６０）、変数ｎが０より大きいか判定する（Ｓ４７０）。変数ｎが１以上であり０より大きい場合には、ＣＰＵ３０は、次の休眠利用者を特定し（Ｓ４８０）、処理をステップＳ４３０に戻す。一方、変数ｎが０の場合には、有効期限処理を終了する。
【００６５】
以上のようなサービス提供システム１００とすることにより、休眠利用者に対して、友達関係にあるゴルフ友達からサービスの利用に復帰するように働きかけることができる。
また、休眠利用者のゴルフ友達のいずれもが、所定期間内に休眠利用者に対してサービスの利用を促すメッセージを送信していない場合に限って、一のゴルフ友達にメッセージの送信を依頼することとしたため、休眠利用者のゴルフ友達のいずれかが、所定期間内に復帰を促すメッセージを休眠利用者に送信すると、当該所定期間内においてシステムは、休眠利用者の他のゴルフ友達のいずれにもメッセージの送信を依頼しないので、休眠利用者が短期間に多数のメッセージを受け取ることを防止できる。これにより、休眠利用者へのメッセージの送信を可能としつつ、メッセージを受け取る休眠利用者があまり多くのメッセージを受信して困惑しないよう、バランスを取ることが可能となる。
【００６６】
＜第２実施形態＞
上述した第１実施形態のサービス提供システム１００には、ＳＮＳを提供する外部管理サーバ３が用いられた。これに対して、図１５に示す第２実施形態のサービス提供システム２００では、外部管理サーバ３を用いない。
即ち、このサービス提供システム２００では、管理サーバ１が、ゴルフ情報サービスの提供を行う。この場合、ゴルフ友達は、ゴルフ利用者が友達の申請を承諾することによって成立する。
【００６７】
また、管理サーバ１の依頼部１３は、復帰メッセージを一般的なメールを用いて休眠利用者に送信するようにゴルフ利用者に依頼する。休眠利用者は、ゴルフ情報サービスに、長期間ログインしていないので、休眠利用者がログインしなければ使用できないコミュニッケーションツールによって復帰メッセージを送信しても、休眠利用者が気付かないからである。
【００６８】
なお、管理サーバ１がゴルフ情報サービスの他に、またはゴルフ情報サービスの代わりに、複数種類のゲームアプリケーションを提供するものであってもよい。この場合には、利用者同士のコミュニケーションを図る手段としてＳＮＳを管理サーバ１が提供してもよい。そのような場合には、ＳＮＳ上の投稿やメールを用いて復帰メッセージを休眠利用者に送信するように依頼すればよい。
【００６９】
＜変形例＞
本発明は、上述した各実施形態に限定されるものではなく、例えば、以下に述べる各種の変形が可能である。
（１）上述した各実施形態では、受信フラグは特定グループに属する休眠利用者のいずれかが復帰メッセージを送信したら、ＯＦＦからＯＮに変更したが、本発明はこれに限定されるものではなく、所定数の復帰メッセージが送信されたら、受信フラグをＯＦＦからＯＮに変更してもよい。
すなわち、依頼部１３が所定のゴルフ利用者（所定の利用者の一例）に対して休眠利用者にサービスの利用を促すメッセージを送信するように依頼するために充足すべき所定の条件は、休眠利用者と友達関係を有するゴルフ利用者から成る特定グループに属するゴルフ利用者から休眠利用者に対して所定期間内に送信した、利用を促すメッセージの総数が特定グループ全体として所定数を超えないことを含む、
【００７０】
（２）上述した各実施形態では、初回の有効期限は、休眠フラグがＯＮに設定された日を基準として所定期間が経過した日に設定したが、本発明はこれに限定されるものではなく、受信フラグがＯＮに設定された日を基準として所定期間が経過した日に設定してもよい。
【００７１】
（３）上述した各実施形態では、休眠フラグの判定をバッチ処理で実行したが、本発明はこれに限定されるものではなく、所定の判定タイングで実行すればよい。例えば、ゴルフ利用者がログインする度に、ログインしたゴルフ利用者と友達関係にあるゴルフ友達について休眠フラグの判定を行ってもよい。
すなわち、ＣＰＵ３０は、ゴルフ利用者情報テーブルＴＢＬ１１（利用者情報テーブルの一例）を参照して、特定したゴルフ友達（特定利用者の一例）の最終ログイン時刻から所定期間が経過した時刻がゴルフ利用者（所定の利用者の一例）のログイン時刻（所定の判定タイミングの一例）よりも前である場合に、当該ゴルフ友達を休眠利用者であると判定する判定部１２として機能する、ようにしてもよい。
【００７２】
なお、本発明における機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することとしてもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。また、「コンピュータシステム」は、インターネットやＷＡＮ、ＬＡＮ、専用回線等の通信回線を含むネットワークを介して接続された複数のコンピュータ装置を含んでもよい。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、ネットワークを介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（ＲＡＭ）のように、一定時間プログラムを保持しているものも含むものとする。また、上記プログラムは、上述した機能の一部を実現するためのものであってもよい。さらに、上述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であってもよい。
【００７３】
また、上述した機能の一部または全部を、ＬＳＩ（Ｌａｒｇｅ  Ｓｃａｌｅ  Ｉｎｔｅｇｒａｔｉｏｎ）等の集積回路として実現してもよい。上述した各機能は個別にプロセッサ化してもよいし、一部、または全部を集積してプロセッサ化してもよい。また、集積回路化の手法はＬＳＩに限らず専用回路、または汎用プロセッサで実現してもよい。また、半導体技術の進歩によりＬＳＩに代替する集積回路化の技術が出現した場合、当該技術による集積回路を用いてもよい。
【００７４】
（４）本発明は、上述した実施形態に限定されるものではなく、発明の趣旨の範囲内での変更は本発明に含まれるものである。
【符号の説明】
【００７５】
ＮＥＴ……通信網、１……管理サーバ、２……端末装置、３……外部管理サーバ、１１…特定部、１２……判定部、１３……依頼部、１７……記憶部、３０……ＣＰＵ、ＴＢＬ１１……ゴルフ利用者情報テーブル、ＴＢＬ１２……ゴルフ友達情報テーブル。
【図１】
2014024597.tif 000003
【図２】
2014024597.tif 000004
【図３】
2014024597.tif 000005
【図４】
2014024597.tif 000006
【図５】
2014024597.tif 000007
【図６】
2014024597.tif 000008
【図７】
2014024597.tif 000009
【図８】
2014024597.tif 000010
【図９】
2014024597.tif 000011
【図１０】
2014024597.tif 000012
【図１１】
2014024597.tif 000013
【図１２】
2014024597.tif 000014
【図１３】
2014024597.tif 000015
【図１４】
2014024597.tif 000016
【図１５】
2014024597.tif 000017
【国際調査報告】
2014024597.tif 000018
2014024597.tif 000019
2014024597.tif 000020
2014024597.tif 000021